emailing me when it snows?

[oppedahl]

Okay I'd like to set up my Meteobridge so that it emails me when it snows.

The trigger would I suppose be something like ... there has been another tenth of a millimeter of precipitation since the last email that the device sent to me on this subject.

Well and the temperature is below some threshold. I don't want it sending me emails during the warm weather months, only in winter.

So what I came up with was:

As you can see I picked "incremental alarm" rather than "one-time". Figuring that hopefully this gives me another email every time another tenth of a millimeter of precipitation happens. But I am not really very clear on the difference between "sumday" and "sum24h". Oh, okay, sumday resets every day at midnight, and sum24h counts up everything that has happened in the past 24 hours.

I guess the problem with using "sum24h" is that if another 0.1 mm falls right now, and 24 hours ago 0.1 mm happened to fall, then the incremental alarm will not fire. So in some ways "sumday" is better. Except that if it's just past midnight, I might lose an interesting event because 0.09 mm of precipitation happened just before midnight.

I guess I am not enough of a C++ programmer to know when to use && and when to use &. Did I get that right?

But I don't think I did it right. I see this:
which does not look right. I am seeing only one & when the expression I programmed was &&. And the overall expression is evaluating as "true" and I think it should be false since it is not the case that 0.1 mm of precipitation happened so far today.

Then on another page I see:

It says "error in raise alarm condition". What exactly does this mean?

[admin]

"&&" and "&" are both a logical "and", so you can't do it wrong here.

But, result of a logical "and" is 0 or 1, so your threshold value will be
overwritten with 0 or 1 when doing the logical operation.
Incremental alarms are not working good with logical operators

Another question is, if you have a heated rain sensor, otherwise the
snow will not be measured until it melts.

[oppedahl]

Yes I have a heated rain sensor.

[oppedahl]

But, result of a logical "and" is 0 or 1, so your threshold value will be
overwritten with 0 or 1 when doing the logical operation.
Incremental alarms are not working good with logical operators

Okay so how do I make it so that I only get notified when the temperature is cold?

[oppedahl]

I wonder if this works ...

( (( th0temp-hmin < 3 ) & [rain0total-sumday]) - 0.1 )

[admin]

you could do that with clear condition:

send mail on every increase of at least 1mm during the day
raise: [rain0total-sumday.1:0]

don't send when temp above 0 degrees and reset on midnight (0:00 - 0:05)
clear: ([th0temp-act.1:0] > 0) || ([hh] == 0 && [mm] < 5))

May be there is still an error in it, but you might have got the idea...

[oppedahl]

How does this approach keep the email from getting sent in warm weather? It seems to me that on a rainy day in summer, the "raise" condition will be satisfied and the email will get sent. After that, the "clear" condition would get evaluated and the event would get cleared.

Or are you telling me that the "clear" condition gets evaluated mere nanoseconds after the "raise" condition is satisfied ... and this quick evaluation of the "clear" condition somehow happens so fast that the email never gets sent?

[admin]

Not exactly. Clear condition is evaluated first. if met, no event is triggered, even when raise condition matches as well.

[oppedahl]

How odd. Is that behavior ("clear" condition is evaluated before "raise" condition) documented anywhere? I would never have guessed such a thing.

Also, I was hoping to hear what is wrong with this approach:

Code: Select all

( (( th0temp-hmin < 3 ) & [rain0total-sumday]) - 0.1 )

[admin]

I am happy to learn how expression evaluation with live and historical weather data can be done more easy with keeping the full flexibility... Unfortunately, there is no solution implemented in ANY of the other weather software, that can handle a fraction of functionality provided here. But may be I am wrong.

Regarding your example.
1) It is incomplete. What are raise and clear conditions? You just provide one line.
2) Problem with logical operators has already been mentioned, but I can of course repeat... The logical "and" will result into 0 or 1. So, if the temp has dropped below 3 degrees during the current hour and there has been some rainfall today, then result of your clause is 0.9, otherwiser -0.1.
When used as raise condition in an incremental alarm scenario, no incremental alarms will happen as an increase of values of raintotal are not surviving the logical "and", that only returns 0 or 1.
3) Not to trigger an event, when raise and clear condition are both met is rather obvious (instead of odd). All other alternatives (triggering an event and then immediately clearing it again) would be rather unwanted, imho.

I doubt that formally describing the evaluation rules will help a lot in understanding what happens. Doing more examples and explaining behavior of that, might be a better way. And this is what we are just doing here.

[LAWx]

Not exactly. Clear condition is evaluated first. if met, no event is triggered, even when raise condition matches as well.

Interesting. I would have thought that Meteobridge's alarms were stateful, meaning Meteobridge knows the state of each alarm. In implementing similar functionality I would have done something like create a variable for each rule's state (e.g., rule1state == 1 or rule1state == 0, where 1 is 'fired' and '0' is cleared). Of course it could be a property of the alarm object if that's how Meteobridge is programmed (e.g., alarm1.state == 0).

Every time a raise or clear condition is met, the flag is set accordingly. Then, when a raise condition is true I would check the state and only trigger the configured action if the state was equal to zero.

[admin]

Alarms are stateful, but when raise and clear condition are both met, you have a conflict. Should you first do the clearing and then trigger a new alarm as raise condition is also true? I decided to give clearing priority. So when clear condition is met no alarm will be sent and alarm status will will cleared to allow a new triggering, next time raise condition is true and clear is not true.