I'm trying to set up a notification to alert me when it starts to rain using a Wittboy weather station. The only option for triggering is wet or dry in the notification app or RM. I tried using wet, but it does not trigger when it starts raining. How do you use the 'rain rate' value as a trigger? Or is there some other way to trigger it? Im using the built in Ecowitt driver, with the Ecowitt RF Sensor child device.
use the custom attribute.. in rule machine and any one of the rain attributes changed or incresed probably rainevent..
there is no built in ecowitt driver so not sure what one you are using?
2 Likes
3 Likes
This works. I do something similar to set a boolean hub variable "RainingNow" that's used in other rules. Works fine. The "stays that way" addition is interesting and I might consider that, since I do get a fair amount of bouncing now.
2 Likes
Thanks, i did not even think to look in custom attribute. I have it set up now.
One thing, though. Will this spam me with notifications if rain starts/stops a bunch of times in a short period? I wonder if rain event would be better...
So if it is raining you basically get an update on rainfall every hour with your rule? That would work for me.
You can also get alerts from Ecowitt, though I haven't tried that.
1 Like
or you can download and use the app i modified/ported color cast weather that gets weather reports and alerts by flashing lights for different weather conditions.. current or upcoming in x number of hours..
but thats not through ecowitt.
1 Like
My rule is notifying me correctly, but it is retriggering every 45 seconds. Im trying to understand why. Doesnt a 'wait for event' pause the rule until the desired even happens?
I'm pretty sure it a retrigger will cancel the wait ... But I could be wrong.... Might be best to use a private boolean and a required expression. Either the pb or maybe see what you can do with the raining variable, even if you have to convert it to a HV
1 Like
Yes, I think you are correct. I searched in other threads and learned that muliple instances of a running rule are possible when a wait or delay are involved. I rewrote the rule using an if-then condition. Let me know what you think. I think it will work.
2 Likes
Hmmm...
On the surface that seems ok, and ultimately it is probably just worth running with it and seeing if it works.
Just a couple of questions I still have... Without any answers 
If your rule was previously re-triggering, does that mean you have the EcoWitt Gateway / display setup to sync data with HE more frequently than 45 seconds? If you don't that introduces two questions, why was it re-triggering and would mean the "is that way for 45 seconds" in the trigger would not be useful, as the attribute would not change in that timeframe.
If you are syncing data more frequently, the next question would be.... (and I don't know the answer for this), would a change to the rain rate value cause the rule to re-trigger? I hope not with the use of the >=.... If it is the case, this could pose two problems, potentially.... If the rule re-triggers on a change in the value you would delay the notification of it starting to rain, plus it could mean you get into a situation where the Raining local variable has been set and then just left, never getting turned off because the if condition at the top of the rule would be false.
This could all be completely incorrect and irrelevant, which is why I suggest simply waiting to see how it performs and if it works as you need it. If that happens, then that would effectively disprove my concerns.
1 Like
I'm scratching my head on this. My rule triggered and fired, but never went past the wait for no rainrate part. The private boolean stayed true (it's raining), so subsequent rain events never got past the if-then.
I removed the 'stays that way' time in the trigger so I can mist it with water for testing.
The only thing I can think of is that when another trigger happens, it is stopping the instance of the rule that was waiting for the rain to stop, therby never resetting the boolean back to false.
This is what the app log looks like.
Yes, looks like you might be right. I suspect the retrigger is cancelling the wait.
I'm going to try as you suggested and use a required expression so it does not even trigger unless it's not currently raining.
1 Like
Yes, I think the second rain reading 4 minutes later, taking it from 0.38 to 0.43 is what did it. Hopefully the required expression will do the trick.
1 Like
Here is my latest version using a hub variable (being false) as a required expression. I tested it and it seems to be working. I shortened the wait because there seems to be some delay from the time the rain stops and the time Ecowitt reports it.
I also made a rule that sets the hub variable to false upon hub reboot, in case of an update or something unexpected during the rule wait.
Thanks everone for the help.
1 Like
This rule has been working great except once in a while I notice it is raining and the rule never triggered. If i go to the rule machine section it says Required Expression False next to the rule name. It seems opening the rule and then clicking 'DONE' at the bottom removes the Required Expression False tag. The rule log shows that the False tag gets added for some unknown reason at the end of the rule. Is this a broken rule or something? Maybe I need to delete it and redo?
You're right, that last log entry (at the top) does not look right, given the final action puts the variable back into a state where the required expression should then be true.
It's a bit of a shot in the dark, but you could try putting a 5 second delay at the end of the rule to see if the required expression evaluation happens at the very end of the rule or not, and whether there could be some kind of delay in the variable update being applied, meaning the required expression may be re-evaluated too quickly.
On a side note.... Personally it is a little confusing to me having the variable value being the opposite to the outcome of the required expression. I normally wouldn't like to include a logical element to a variable name, but you may want to name the variable NotRaining.... Just my 2c, ultimately whatever makes it easy for you....
1 Like
Another alternative could be to use the private boolean for the rule, instead or in addition to the variable. Can't remember if we covered this in earlier discussion or not.
