Triggers misbehaving & possible documentation issue

[pmk.72q04]

I am using a WeMos D1 R2 with a custom shield to communicate with a Hiking DDS238-2 ZN/S electricity meter via RS485 MODBUS RTU.

In plain English, that just means that the electricity meter is attached to the house mains and is continuously sensing instantaneous values like voltage, current and frequency. The WeMos D1 R2 is polling the meter at regular intervals via a MAX485 module to retrieve the values, after which they are transmitted whenever CAYENNE_OUT_DEFAULT() is called.

This has all been working perfectly since April 2018 so the data is getting to Cayenne OK.

Some time ago I set up a trigger to send me an email if the grid voltage exceeded 253.0 volts AC. This is the theoretical upper limit of the nominal 240V supply in the part of Australia where I live. I realise that the previous sentence is off-topic but I did not want anyone who lives in a 110V jurisdiction to assume that 253V was a ridiculous value.

If memory serves, I set up this trigger using the web interface to Cayenne. Since it was set up, the trigger has fired 1054 times so (a) it is definitely working and (b) I have plenty of data to show that it fires precisely according to its definition of “over 253.0”.

Today, I decided to create two more triggers, this time on the grid frequency. The nominal frequency is 50Hz and the limits of normal behaviour are 49.85Hz and 50.15Hz. Thus the first trigger should fire if the frequency falls below 49.85 and the second trigger should fire if the frequency rises above 50.15.

The web UI for a new trigger has four associated controls: min, step, value, max. Unless I’m looking in the wrong place (Cayenne docs, Features, Triggers, Setting up triggers), the Cayenne documentation does not seem to show this arrangement so this is probably a documentation error (BUG #1).

I cancelled the first new trigger I was intending to create and revisited the voltage trigger I created some time ago. The values it showed me in the UI were min=0, step=1, value=20, max=20 which obviously had nothing to do with 253V.

I wondered if my memory was faulty and if I had created the voltage trigger via the iOS app but when I went into the app on my iPad, it did not want to show me any triggers at all, despite the fact that the voltage trigger has fired many times.

I went back to the web interface and this time forged ahead to create a “below” trigger with the values min=0, step=1, value=49.85, max=60; plus an “above” trigger with the values min=0, step=1, value=50.15, max=60.

Those seemed to “stick” in the sense that they were accepted but when I re-opened each definition, the UI showed me min=0, step=1, value=20, max=20.

Having created the two new triggers via the web, I went back to the iOS app. It still would not show me any triggers at all, and that’s when I decided to start writing this bug report.

Then, while re-tracing my steps, the iOS app “came good” and started to show me all three triggers. What is interesting is that the iOS UI has fields for “min” and “max” plus an unnamed field that corresponds with “value” but no field for “step”.

I have no idea what the “step” field is meant to do. If it is a supported parameter then it should be documented and added to the iOS app. If it is an unsupported parameter that has somehow crept into the web UI then it should probably be removed. (BUG #2)

Given that the iOS app ultimately proved capable of showing the actual values of the trigger parameters, while the web app will only ever show 0/1/20/20, it seems to me that the web UI is deficient in this regard and should be fixed. (BUG #3)

Why the iOS app was initially unable to show me the voltage trigger (created ages ago), then was unable to show me the newly-created frequency triggers, then was able to show me all three triggers is a bit of a mystery but I’m assuming it was a transient problem. For the record, the iOS app is version 2.3. It was not running the first time I went into it today but I did force-quit and re-launch before re-checking whether it would show me the triggers.

I’m attaching screen shots from both the web and iOS user interfaces.

[shramik_salgaonkar]

welcome to the cayenne community @pmk.72q04

@pmk.72q04

If memory serves, I set up this trigger using the web interface to Cayenne. Since it was set up, the trigger has fired 1054 times so (a) it is definitely working and (b) I have plenty of data to show that it fires precisely according to its definition of “over 253.0”.

this huge number is because you are having the true condition for a longer time duration, try to write a code so that this condition is achieved only once, thus avoiding trigger flooding.

@pmk.72q04

Today, I decided to create two more triggers, this time on the grid frequency. The nominal frequency is 50Hz and the limits of normal behaviour are 49.85Hz and 50.15Hz. Thus the first trigger should fire if the frequency falls below 49.85 and the second trigger should fire if the frequency rises above 50.15.

this kind of trigger is not allowed and won’t work. Because you are having two Then condition for one If.

@pmk.72q04

I cancelled the first new trigger I was intending to create and revisited the voltage trigger I created some time ago. The values it showed me in the UI were min=0, step=1, value=20, max=20 which obviously had nothing to do with 253V.

you can type in the value in you want directly in the box provided and it will set accordingly.

@pmk.72q04

Having created the two new triggers via the web, I went back to the iOS app. It still would not show me any triggers at all, and that’s when I decided to start writing this bug report.

Then, while re-tracing my steps, the iOS app “came good” and started to show me all three triggers. What is interesting is that the iOS UI has fields for “min” and “max” plus an unnamed field that corresponds with “value” but no field for “step”.

I have no idea what the “step” field is meant to do. If it is a supported parameter then it should be documented and added to the iOS app. If it is an unsupported parameter that has somehow crept into the web UI then it should probably be removed. ( BUG #2 )

Given that the iOS app ultimately proved capable of showing the actual values of the trigger parameters, while the web app will only ever show 0/1/20/20, it seems to me that the web UI is deficient in this regard and should be fixed. ( BUG #3 )

we have a new relaese of app in upcoming days and it should solve most of this bugs.

[pmk.72q04]

shramiksalgaonkar
Community Manager

    June 21

welcome to the cayenne community @pmk.72q04

pmk.72q04:
If memory serves, I set up this trigger using the web interface to Cayenne. Since it was set up, the trigger has fired 1054 times so (a) it is definitely working and (b) I have plenty of data to show that it fires precisely according to its definition of “over 253.0”.

this huge number is because you are having the true condition for a longer time duration, try to write a code so that this condition is achieved only once, thus avoiding trigger flooding.

Sorry - I did not make it sufficiently clear what I meant by “1054 times”.

I was not complaining about the number of times the trigger has fired. The amount of time voltage is over 253V is less than 1% (around 0.86%).

We are talking about 1054 events during a ~90-day period. This is an average of one trigger event every two hours. This is not what I think of as a flood.

What I was trying to communicate was that the 253V trigger had been working, reliably, for a long time. I explained that because I did not want anyone to think I had only created the 253V trigger in the last few days.

pmk.72q04:
Today, I decided to create two more triggers, this time on the grid frequency. The nominal frequency is 50Hz and the limits of normal behaviour are 49.85Hz and 50.15Hz. Thus the first trigger should fire if the frequency falls below 49.85 and the second trigger should fire if the frequency rises above 50.15.

this kind of trigger is not allowed and won’t work. Because you are having two Then condition for one If.

I understood that. If you look at my screen shots, you will see that I have two separate triggers, one to detect “below 49.85” and the other to detect “above 50.15”.

pmk.72q04:
I cancelled the first new trigger I was intending to create and revisited the voltage trigger I created some time ago. The values it showed me in the UI were min=0, step=1, value=20, max=20 which obviously had nothing to do with 253V.

you can type in the value in you want directly in the box provided and it will set accordingly.

When I display a trigger in the iOS app, it shows me the actual threshold values (253 for the voltage trigger, and 49.85 and 50.15 for the two frequency triggers).

That is the expected behaviour. You give a system a value. The system stores it, acts on it, and shows it to you in the UI when you inspect the control.

Conversely, when I display a trigger using the Cayenne web interface, it shows me 0/1/20/20 regardless of the actual values.

That is unexpected behaviour.

On the server side, Cayenne has obviously stored the settings correctly. I can say this because the voltage trigger fires when expected and because the iOS app displays the settings correctly.

It is the web user interface that is not showing the stored values correctly when you try to inspect an existing trigger’s settings.

Does what I am saying make sense?

Also, please don’t forget that the meaning of “step” is not documented anywhere. It would be helpful to understand what it means.

pmk.72q04:
Having created the two new triggers via the web, I went back to the iOS app. It still would not show me any triggers at all, and that’s when I decided to start writing this bug report.

Then, while re-tracing my steps, the iOS app “came good” and started to show me all three triggers. What is interesting is that the iOS UI has fields for “min” and “max” plus an unnamed field that corresponds with “value” but no field for “step”.

I have no idea what the “step” field is meant to do. If it is a supported parameter then it should be documented and added to the iOS app. If it is an unsupported parameter that has somehow crept into the web UI then it should probably be removed. ( BUG #2 )

Given that the iOS app ultimately proved capable of showing the actual values of the trigger parameters, while the web app will only ever show 0/1/20/20, it seems to me that the web UI is deficient in this regard and should be fixed. ( BUG #3 )

we have a new relaese of app in upcoming days and it should solve most of this bugs.

Great! I look forward to it.

[shramik_salgaonkar]

@pmk.72q04

I understood that. If you look at my screen shots, you will see that I have two separate triggers, one to detect “below 49.85” and the other to detect “above 50.15”.

I know you have two trigger setup but both are setup for single IF condition, which is not acceptable.

@pmk.72q04

Conversely, when I display a trigger using the Cayenne web interface, it shows me 0/1/20/20 regardless of the actual values.
That is unexpected behaviour.

On the server side, Cayenne has obviously stored the settings correctly. I can say this because the voltage trigger fires when expected and because the iOS app displays the settings correctly.

It is the web user interface that is not showing the stored values correctly when you try to inspect an existing trigger’s settings.

you can set any value by typing in the box provided.

i know that the web dashboard and app are not in sync, we are working on it currently and should have a fix soon.

@pmk.72q04

Also, please don’t forget that the meaning of “step” is not documented anywhere. It would be helpful to understand what it means.

there seems to be a bug with steps, it meant to increase the set value of trigger by steps. i have put this forward to the team, once i get an update i will inform you.
p.s. steps are to move the slider. when you set steps for 30, the slider will move in 30 steps.

[pmk.72q04]

I am sorry but I do not understand your first point. As far as I can see, I can not create a single trigger which has the effect of:

if (frequency < 49.85) or (frequency > 50.15) then sendEmail();

The only way I can see to implement this is to use two triggers, one for the “below 49.85” and another for “above 50.15”.

If you are trying to tell me that it will not work to define two separate triggers, I can say that two separate triggers are most definitely working. Please see the attachment which shows a clipping from two separate emails I have received today.

Can I also say that I would prefer it if I could create a single trigger with boolean logic for all the conditions I am interested in. Creating multiple triggers is sub-optimal. I just can’t see any way around that.

[shramik_salgaonkar]

@pmk.72q04

I am sorry but I do not understand your first point. As far as I can see, I can not create a single trigger which has the effect of:

if (frequency < 49.85) or (frequency > 50.15) then sendEmail();

The only way I can see to implement this is to use two triggers, one for the “below 49.85” and another for “above 50.15”.

If you are trying to tell me that it will not work to define two separate triggers, I can say that two separate triggers are most definitely working. Please see the attachment which shows a clipping from two separate emails I have received today.

sorry for the above reply i made. glad to hear that it is working as you want. Had some bugs with previous such encounter.

@pmk.72q04

Can I also say that I would prefer it if I could create a single trigger with boolean logic for all the conditions I am interested in. Creating multiple triggers is sub-optimal. I just can’t see any way around that

Yes, we are working on having a boolean logic trigger.