Alarm Issue **solved**

[LAWx]

I have an alarm set to email me when the outside temperature AND the outside dew point are 1°F lower than the indoor temperature and dew point. The rule looks like this:

Code: Select all

([th0dew-avg5=F.1:--]<([thb0dew-avg5=F.1:--]-1)) && ([th0temp-avg5=F.1:--]<([thb0temp-avg5=F.1:--]-1))

I set the clear condition to be whenever the outside temperature and dew point rise to be equal or above the inside temperature OR dew point:

Code: Select all

([th0dew-avg5=F.1:--]>=[thb0dew-avg5=F.1:--]) ||  ([th0temp-avg5=F.1:--]>=[thb0temp-avg5=F.1:--])

The problem I am having is that I am getting repeated emails even though the clear condition has never been met. This led me to set up another rule with this rule's clear condition as the alarm condition, but that alarm is not triggered in between the repeated emails. That means the clear condition is not being met, but the rule continues to cause email to be sent.

[LAWx]

Upon further investigation I really believe that Meteobridge is ignoring the clear condition altogether. I first believed that perhaps the clear condition was evaluating as true for some reason, but I now have two email alarms that are exact opposites of each other (meaning one rule's clear condition is the other rule's raise condition and vice versa). Both rules raise multiple emails without the other rule being raised between. I'm still investigating, but it looks like the alarm is raised every time the sensor's value changes even though the clear condition has not been raised in the interim.

[admin]

some observations...

1) giving "--" as a default when sensor does not have recent data is not making sense, as how should this run through the comparisons you defined? Provide numric defaults that fit to your purpose

2) have you falsely selected "incremental" alarm mode?

[LAWx]

I only changed to "--" after having previously set "999" for values on the high side of the comparison and "0" for values on the low side just in case the numbers were causing issues with the comparison operators. It is definitely not an incremental alarm.



I changed the email template to send the values of the variables and none of them are "--", so I don't think substitution is an issue.

[LAWx]

For example, this morning I received 4 "Alarm 2" emails between 15:03 and 15:21 UTC, and no "Alarm 1" emails in the same time. My SQL data shows the following data for that time period:

Code: Select all

Time        Out Temp        Out Dew        In Temp        In Dew
15:00:05      68.2            42.3           72.9          42.8
15:03:39                                                         <-- Alarm 2 email #1
15:05:07      69.4            42.8           72.9          42.8
15:06:41                                                         <-- Alarm 2 email #2
15:10:00                                                         <-- Alarm 2 email #3
15:10:08      71.1            42.8           72.9          42.8
15:15:11      70.7            43.2           72.9          42.8
15:20:13      70.9            41.9           72.9          42.8
15:21:00                                                         <-- Alarm 2 email #4
15:25:15      71.6            42.4           72.9          42.8

Is it possible in the Meteobridge code that "&&" in the CLEAR field is leading to an "OR" statement in the code, and a "||" is leading to an "AND" statement? Looking at the data here it looks like that may be a possibility. It appears that the RAISE field works correctly.

[admin]

I changed something. Please do a reboot and try again...

[LAWx]

I upgraded to MeteoBridge 2.3 (4891) by reboot a few minutes ago. If I still experience issues I will try to create a better test case.

[LAWx]

I have been waiting a few days to observe Meteobridge behavior, but it's still not behaving as expected. Even when I reduce the rules to simple comparisons I'm still getting multiple alarm 2 notifications without an alarm 1 notification.

The rules used for this test are:

Alarm #01
RAISE

Code: Select all

[th0dew-avg5=F.1:0] < ([thb0dew-avg5=F.1:0] - 1)

CLEAR

Code: Select all

[th0dew-avg5=F.1:0] >= [thb0dew-avg5=F.1:0]

Alarm #02
RAISE

Code: Select all

[th0dew-avg5=F.1:0] >= [thb0dew-avg5=F.1:0]

CLEAR

Code: Select all

[th0dew-avg5=F.1:0] < ([thb0dew-avg5=F.1:0] - 1)

I wish there was a way to have Meteobridge log what the rules are doing, but /var/log/meteobridge.log doesn't seem to have anything.

[LAWx]

Further news: Removing the "-1" seems to make the rules function as expected. Further testing will be required to identify whether the cause is due to a mathematical calculation issue or if there is a general issue with CLEAR conditions that are not the binary opposite of RAISE conditions.

[LAWx]

I give up. I can't figure out what the problem is. It's difficult to investigate without knowing how the code works.

[LAWx]

There is some bug in the way logical operators work in Meteobridge. I'm bumping into this issue repeatedly when constructing complex rules. The latest issue is that the following rule is triggered when the conditions do not evaluate to true:

Code: Select all

([th0temp-avg5=F.1:999]>([thb0temp-avg5=F.1:999]-1)) ||  (([th0dew-avg5=F.1:999]>[thb0dew-avg5=F.1:999]) && ([th0dew-avg5=F.1:999]>40))

I configured the email message with the same string as the RAISE rule, and this is what the email message contains:

Code: Select all

(60.9>(71.8-1)) ||  ((44.0>44.1) && (44.0>40))

This should evaluate to FALSE, but somehow Meteobridge is evaluating it to TRUE:

Code: Select all

FALSE or (FALSE and TRUE)

Meteobridge is evaluating (FALSE AND TRUE) as TRUE, which is incorrect. This can be confirmed by using the same construct in another language like JS and evaluating the expression:

Code: Select all

alert((60.9>(71.8-1)) ||  ((44.0>44.1) && (44.0>40)))

Which will give you a dialog box with "false". You can confirm Meteobridge behavior by creating an alarm with the hard-coded condition:

Code: Select all

(60.9>(71.8-1)) ||  ((44.0>44.1) && (44.0>40))

And Meteobridge will send the email. What's worse than that is it continually sends the emails every five seconds or so, even when the CLEAR condition is set as:

Code: Select all

(60.9>(71.8-1)) ||  ((44.0>44.1) && (44.0>90))

Which should clearly never trigger since all tests are false.

[admin]

I also did some testing on it and it looks like the used expression evaluator needs spaces around the tokens.
I will dig deeper into this, as being that space-dependent is rather error prone, I have to admit.

When I use the following string as raise condition, then no alarm gets raised:

Code: Select all

( 60.9 > ( 71.8 - 1 ) ) ||  ( ( 44.0 > 44.1 ) && ( 44.0 > 40 ) )

But using this one, does fire an alarm:

Code: Select all

( 60.9 > ( 71.8-1 ) ) ||  ( ( 44.0 > 44.1 ) && ( 44.0 > 40 ) )

So for the moment, please put a blank between all variables, operators, brackets.

[LAWx]

It's still not working correctly. The following hard-coded rule raises an alarm:

Code: Select all

( ( 80.1 <= ( 73.1 - 1 ) ) && ( 80.1 > 55.0 ) ) && ( ( 56.1 <= 47.7 ) || ( 56.1 <= 40.0 ) )

That should evaluate to:

Code: Select all

( ( [false] ) ) && ( [true] ) ) && ( ( [false] ) || ( [false] ) )

then

Code: Select all

( [false] ) && ( [false] )

Even putting the simple rules

Code: Select all

RAISE: 1 > 2
CLEAR: 3 < 1

raises the alarm dozens of times per minute.

[admin]

I found a bug in evaluating logical operators "&&" and "||". The just released new version does fix this, and adds an "i" icon to be clicked for checking last evaluations of alarm conditions. This should help understanding what happens. Spaces are no longer needed.

alarm.png (114.82 KiB) Viewed 7554 times

Please be aware that square brackets (indicating use of variables) must be in the condition in order to have the complex themes evaluated. If you want to test with bare numbers please add something like "+ [XYZ:0]" to one of the numbers, as this adds zero but provides the square brackets.

example from former LAWx posting:

Code: Select all

( ( [XYZ:0]+80.1 <= ( 73.1 - 1 ) ) && ( 80.1 > 55.0 ) ) && ( ( 56.1 <= 47.7 ) || ( 56.1 <= 40.0 ) )

[LAWx]

Thank you for investigating. The hard-coded test case was only for debugging a condition constructed of variables. The tooltips are helpful, but in Firefox it doesn't display the comparison operators correctly and the "&&" and "||" are displayed as single characters. I suspect they're not HTML encoded (e.g., <, >, etc)?