I had already rebuilt it before your response. This time I cloned it, and then went into the action and changed the wait for condition on the humidity from 57 to 56.77, and as soon as I click done I get the same error.
Now perhaps it persists because there's no other option but to go back or to the app list, but it first comes up when I use a decimal. Although not in these screenshots the initial trigger does take a decimal (it did during my first attempt I didn't want to risk it this time), so are you saying that that's decimal but the wait for action is number?
Not sure what all the sets are for. My rule for this looks like:
I have another rule that will capture into the Master_Bath_Humidity global variable the humidity when the bathroom light turns on if the fan is not already running. Then this rule will turn the fan on if the humidity is 2% over that reading and the light is on. It will turn off once the light is off and the humidity falls back to 5% above the initial reading. Plus there is a 3rd catch all rule for my bathroom fans that will turn any of them off after they have been running for 20 minutes if the light is off in the bathroom. That way if they are turned on via any rule or by hand they will go off eventually.
If you are going to all that effort, I think that is exactly the math that the Smart Humidity app does.
2 Likes
Just didn't want another app. 
And it helps me learn.
@tivomaniac
The sets were because I want to measure how long the fan stays on. If I used time type variables, there was no way that I could see to find the difference in times. Found a different there's where I saw if I set as a number type, I could set as current time in seconds and then find the delta seconds. Then I used variable math to convert to minutes and seconds and made a string %mins%:%secs% (language not specific, time math always sucks).
My RM differs in that the sensor sends humidity already (every 1% humidity change -haven't understood yet what humidity offset does). So you are grabbing a value when your light goes on, but I'm reading the values (I think - this is why I'm testing) every time it updates.
@neonturbo - I also did mine in RM so that I could learn first.
@bravenel - if you look at my screenshots above - should the humidity wait for condition allow decimal like the similar humidity trigger does?
I will have to check -- but they both use the same code.
UPDATE: No, humidity is supposed to be an integer. Range should be 0..100 for humidity itself and -100..100 for an offset.
1 Like
Thanks Bruce (right?). By the time I made that screenshot I had already presumed that it must be an integer, so I didn't have the one that showed that the "trigger" actually will take a decimal. However, it does do that with no error. But the "wait for condition" does not (and apparently shouldn't).
As someone who is learning is the indicator on whether the value is acceptable the brief red underlining that I was seeing when I was entering that static value? Is Rule Manager using that visual as a way to tell whether the value is acceptable?
Almost all numbers are supposed to be integers for device values. The exceptions are thermostat values, temperature, power meter, and energy meter -- those accept decimal values.
1 Like
Ok. So perhaps you may want to look at the humidity > (or <) trigger because it takes this as decimal:
What driver are you using?
Ummm... This is where my being a noob will show more. For the sensor?? It's a Zooz ZSE40. So is that the Zooz 4-in-1 Sensor?
This is a bug in the driver. It is supposed to report humidity as an integer. This bug has been reported to engineering, and will be fixed soon.
1 Like
Erm...glad I could help, then 
All kidding aside – thank you all. I did get the rule to work (the duration the fan stayed on too) once I got past this variable type issue.
Edit: I really felt there were multiple solutions, but could only choose one. So, I went with the one closest to what I used.
1 Like
