I have a project where a sensor will trigger an email endpoint when it detects an abnormal condition, this email then contains a https address of the dashboard so that the user can review the sensor readings and, if necessary, reset the email trigger. This is all currently working OK, my sensor F/W is calling the email endpoint OK and I have created a Thinger “pson out” variable which contains the https address which is then included in the email endpoint call.
However, I want to avoid having to update the F/W if I deploy another sensor with a separate dashboard. Is there another way of setting an email endpoint to include the dashboard https address that is maybe taken from a device property, or some other method?
OK, its taken me a few hours but I have found a solution that works for me, although it may be a bit ‘clunky’.
Step 1 - Create a new token on thinger.io to give access to ALL dashboards and create an email endpoint (in this example the endpoint is called “Alert”).
Step 2 - Create a dashboard with the same ID as the Device.
Step 2 - Create a few String variables to define email endpoint name, device ID and split up the https address into sections
e.g. #define EMAIL_ENDPOINT “Alert” #define DEVICE_ID “CSPi012345” //Thinger Device and dashboard ID, this could also act as the device serial number.
String Email-1 = “Device warning email, see dashboard…”;
String Email-2 = “https://console.thinger.io/#!/dashboards/”;
String Email-3 = “?authorization=”;
String Token = “eyJhbGciOiJI…”; //this is the token that was created on thinger.io
String Email; //this will eventually hold the entire concatenated string
Step 3 - Create thinger variable in the setup section of the code and concatenate the entire email string e.g.
Email = Email1 + Email2 + DEVICE_ID + Email3 + Token;
thing[“EmailText”] >> [] (pson& out){
out = Email;
};
Step 4 - Add some code that will trigger the email endpoint when a specific condition is met. e.g.
if(Value > 0){
thing.call_endpoint( EMAIL_ENDPOINT,“EmailText”); //Trigger Thinger email alert endpoint
}
I hope this makes sense and might be useful to someone else. (I apologise if I haven’t added the code in the correct format)
It makes totally sense, it is a way to give the specific dashboard to a device.
For the email trigger reseting I like to use a kind of histeresis, let me explain myself, ie if we are measuring a water tank and the level drops below 10% send email “water is running out, level below 10%”, but if it raises above 20% it sends another email saying “water level is above 20%” so by this way the device will send always the alert when the water drops below 10% without the user intervention to reset the alarm status.
It is not recommendable to set the histeresis values so close, 10 for lower and 10.1 for higher for example, because the water ripple (or any efect) may trigger the up and botton level email, so be careful with this to avoid a bunch of calls in a short time period.
your approach is valid but I would use a different way of sending the email. I mean, you are currently generating the full email body in the device, which can be improved a lot by using placeholders on the endpoints.
By using placeholders you can define your email body in the endpoint, including the access token with the authorization, and then, the device is responsible of transmiting only its identifier, which is replaced by the placeholder. For example…
Having an endpoint template with:
Device warning email, see dashboard...
https://console.thinger.io/#!/dashboards/....{{device}}?authorization=eyJhbGciOiJI…
Notice that the endpoint has the placeholder {{device}} and the device is sending the device field in its output, so, it is automatically replaced when calling the endpoint. This way you can even enrich your email, sending the actual level, or any other parameter you consider.
Benefits on this approach:
You can change your email body, authorization, when you want, for all the devices, including HTML body, etc., without having to reflash your devices.
Your device does not require to know the token, which can be insecure.
Your device does not require to stream the email body, only its device id, which saves bandwidth and processing, and left you more space for your program.