Except for the logs entries, why do you care if it turns on (or off) every 7 minutes? You could use a private Boolean to ignore an ON command if the heater is always ON
or
You could add a simple condition something like "if on don't turn on" or similar logic.
Fair point. In general, I like my rules to be as clean as possible and not lead to unnecessary overhead. It didnāt freeze last night, so I didnāt get to test it.
If the hose is insulated and I assume kind of small, do you need the heating tape on 100% of the time when @ low temp? Not knowing the tape wattage, would it be worth the time to have the tape go on and off at some slow rate?
I'm assuming, since it works, that the sequence of evaluation is not what I was thinking. I may be wrong here but it seems the "Required Expression" would have to be evaluated BEFORE the trigger, such that it represents the "old" temp (in this case).
If this is the case, what controls the evaluation of the "Required Expression"?
I think it would be more helpful to think of the required expression evaluation at the moment just before triggering as being what matters. This makes it useful to capture specific state changes -- and was the very reason it was introduced, as with the modes example in the docs (not a device, but same idea: different event values for the same thing). The rule above is the same, capturing the transition from >= 34 to < 34 (rather than all readings below 34 as it would without the required expression; as with the example in the docs, this use of required expression captures one particular state change). If it didn't work this way, the very use case that prompted the addition of this feature would not be applicable.
As a consequence of this, you can also think of it this way: if the required expression and trigger event refer to the same attribute/event, the resulting value from the trigger event is not yet taken into account in the evaluation of the required expression. Of course, there is no reason a trigger event and required expression need to have anything in common, and some users do just use required expression more generally to restrict triggering of rules under whatever unrelated conditions. In this case, while the above is still true, it doesn't really matter since there are no overlapping concerns.
Good thought. Iād need a lot of data to answer that question: āwhat is the volume and temperature of water that transits the pipe every minute, and how does that temperature change with the tape on.ā However the time below 34 degrees where I live is on average 3 hours A YEAR. Assuming a worst case scenario, we are talking about 5.4 kW per year. So very little energy overall even running it constantly.
I don't have any experience with heat tape, but you don't want any fires, etc. Are they rated for constant duty? Did it come with a built in thermostat controller?
Again, I don't have any experience with heat tape.
Update: Rule is working. I'm still getting some "wobble." The only way I can get the device to work is to set it as a dimmer. Not sure why it gives a command to "set to 29" or "70" instead of just "on." Also the PB doesn't seem to be protecting the rule while it's running.
You'd have to post a screenshot of the current version of the rule so we could try to figure out why the PB isn't stopping the rule from re-firing. You do have the PB in the required expression?
What device driver is being used for the Ice Maker Drain Hose Deice device? It's odd that it's acting as a dimmer. I just assumed you had something plugged into a smart outlet.
I still think the rule format that I posted above makes this simpler. Get rid of the PB (which can get stuck in the wrong state, causing your rule NOT to fire when it should) and just use "under House Z Wave ice maker drain hose deice switch = OFF" as your required expression. The rule will run, turn the switch on, and then not trigger again until the switch is turned off.
Thank you. Old rule is the first screen shot which resulted in the previous logs. Second Screen shot is rule rewritten as you suggested. It's supposed to freeze again tonight, so I'll post new logs if the rule triggers.
I mentioned further up the post - the PB wasnāt actually needed, it was something Iād added to one of my own rules (for a reason I canāt remember). Just removing it from the required expression and actions is all that was needed as I showed in a later post.
As always with RM there are multiple ways to achieve the same end and the method you're trying now will also work. It's probably a bit 'safer' as if somehow the de-ice was switched off accidentally, it'll be checked at the next temperature report (whereas in my example there would be no re-trigger until the temperature had risen again to satisfy the required expression)
Rule appears to be running very well. The log is showing the power going up because the device is listed as a dimmer. When I put the device on the network, it came in as a dimmer and any attempts I have made to change it to a switch made it not work. Thoughts?
I also got this warning yesterday which I've never gotten before. It has not since repeated.
