I’m thinking of a strategy to use an endpoint (eg endpoint_email_model) to call on several devices “thing.call_endpoint” that are from different clients.
The question: How to link an email address on each device to send the email to the correct address?
What I thought:
1 - Create an “endpoint_email_model” with template/default text. And in the field “Destination Addresses” put a variable {{email_client}}
2 - Link the email address (email_client: xxxxxxx@.com.br) of each customer in the properties of the respective device.
3 - When the device connects to the Thinger Server, it will store the address in memory (email_client).
4 - When the device calls “thing.call_endpoint”, it will include the “email_client” to be filled in the field “Destination Addresses”{{email_client}}.
I’m still testing, but I think it will work. I’ve already used variables in the “Subject” field of the endpoint and it worked.
I would associate the email address and/or other metadata to a device property. On node-red, then you can easily fetch the device property, i.e., based on an endpoint call to a virtual endpoint with the device id, and then, call the email endpoint with device email, or other metadata.
I’m looking forward to the “Alerts manager” feature being made available.
Will it help with the above problem?
Features I would like in the “Alerts manager” feature:
Possibility to evaluate a bucket value and perform an action (eg trigger an endpoint - email, http…) for a specific recipient (eg email: “client_specific@gmail.com”; sms: +551189456123). This would require a link between the bucket and the device sending the data, as the email address or phone number would be in the device’s properties.
Configure the interval between alarms (eg every 20 min); a maximum amount for a given period (eg, up to 10 activations of the same alarm in a 24-hour period. This option aims to restrict alerts that cost money, such as sending SMS messages); Mechanism to pause the alarm (eg: Pause the alarm for 60 minutes); Mechanism to interrupt the alarm (eg, disable the alarm).
I know that NodeRed can help in many cases, but the tool’s learning curve creates obstacles for this kind of task.
An example I wouldn’t know how to do in NodeRED:
Read a bucket that has received a record.
If the temperature variable is above 35ºC, activate the “endpoint_email” and send the email to a specific address.
(@alvarolb )In the example above, how would NodeRED be able to identify which device writes data to the bucket and then get the specific email address in the device properties?
The example below is a “server event → Write Bucket”, how can I get the name of the device that sent the data to the bucket?
Without the device name, I can’t get its properties. Without the properties, I don’t know what email address it should send an alert/endpoint to (email, sms, http…).
Is there a way to get the device name with “server event → Write Bucket” and then get the device properties to send the email to the specific address (specific_client@.com.br)?
Any suggestion (@alvarolb@jaimebs )?
Read write events in bucket with ‘Asset Type’ marked with “temperature_sensor”;
Analyze if the variable “Temperature” is greater than a fixed value “35” (or if it is greater than another variable in the bucket, or if it is greater than a device property value. In the latter case, it would be necessary to know the name of the device and obtain the property data, as indicated in the routine of item 3);
If true, identify the name of the device that recorded the data in the bucket. Then read the device property (eg "metadata_client) and get the email address and phone number.
Send an email to the default endpoint/template “endpoint_email_temperatura”, replacing the endpoint variables with the device and bucket property variables.
Field:
4.1) Destination Addresses: {{client_email}} (registered in device properties)
4.2) In the body of the email: {{value_temperatura}} (recorded in the bucket)
Send an sms to the Send an email to the default endpoint/model “endpoint_sms_temperatura” (eg an HTTP):
5.1) Phone number: {{client_sms}} (registered in device properties)
5.2) In the text of the sms: {{value_temperatura}} (recorded in the bucket)
If it is feasible to do this with the current version of NodeRED, that would be very good. But I believe it is not easy.
However, there are still features that may not be possible with NodeRED(or are difficult to implement), for example:
Configure the interval between alarms (eg every 20 min);
Set a maximum number of triggers for a given period (eg up to 10 triggers of the same alarm in a 24-hour period. This option aims to restrict alerts that cost money, such as sending SMS messages);
Mechanism to pause the alarm (eg, pause the alarm for 60 minutes), through a link in the email;
Mechanism to stop the alarm (eg deactivate the alarm), through a link in the email;
Just to give you some ideas in case you need them. Both of this could be done the same way, by reading the data in a set interval (using the Inject node) or by receiving the events associated (Server Event node) and treating the information with a Switch node, which is essentially an if.
This information can be retrieved if the bucket is configured with a device resource/stream. If the bucket is populated from a device write call, the only way to get the device_id would be to send it alongside the resource that is written.
For the former, the steps would be:
Receive the write bucket event
Set the property msg.asset_filter to the value of msg.payload.bucket of the event received.
Save msg.payload or the necessary information in a different property (Ex. msg.event) using the change node.
With and asset iterator node, configure the ‘asset’ field to ‘bucket’.
When the message is received, the last node will give you all the information regarding the bucket. You’ll find the device in the property msg.payload.config.device.
Regarding your routine, I believe it is possible to do it with the current version of the Node-RED plugin. It’s true that the learning curve may seem steep and at first the flows may seem complex and cumbersome, but once you get the handle of it you’ll find endless possibilities to be exploited.
Let me give you some ideas on the last features you need:
If this means to group messages and send only one alarm every 20 minutes, you may use the nodes group and delay (include with the Node-RED core) to handle this. Another idea would be to launch the flows every 20 minutes, with the node Inject, and read the last 20 minutes of data from the buckets, instead of handling each write event.
It could be possible using and accumulator as a context variable. You would have the following flows:
Every 24 hours set the variable (alarms_sent) to 0
In the main flow, there would be a control like the following: if alarms_sent < 10; send alarm and alarms_sent + 1
Both of this are kind of specific, but I bet there are ways to achieve them. I would say that the link in the email is a call to and endpoint in Thinger.io, that you could receive in Node-RED.
For the first, I would say it could be handled with a context variable in the flow were the stop time would be set and checked before sending the next alarm, and another flow that could check if the stop time is > 60 minutes in order to reset it.
For the second, the endpoint call could trigger a flow that would disable the endpoint in Thinger.io, so no alarms would be sent. Currently there isn’t a specific node that can handle this (would you find this useful?) but could be easily achievable executing a request against the API.
I encourage you to give it a try and let us know if we can help you with anything or you find missing operations that would be useful for you and the rest of the community.
By using Node-RED you could delegate the logic to the server, and any requirement change could be done without affecting the microcontrollers.
