This is how I do it.
That's triggering at only one level. That isn't what the OP asked for.
So the action for FALSE won't run when the temp drops below 50? What does that last box do? It's been too cold here to see if it works.
Read the original post again. He want the fan to start at one temp and turn off at a different temp.
1 Like
I keep seeing this acronym used throughout this thread but I don't see any reference to what it stands for or where to find it... What is the WATO app? is it something built into HE or is it some community built add on?
-Jeremy
WATO = When any Attribute Then this cmd Otherwise that cmd.
Kind of like making rules in RM, but you can specify any attribute (without making intermediate virtual devices, etc) and execute any command (without making custom commands).
It also has the ability to do math on inputs for the trigger, more than just >, <, =... Like the rising and falling triggers mentioned above.
I use RM for most of my things, but WATO scratches a couple of very specific itches for me that would be possible in RM - but with a lot more work/rules.
1 Like
Thanks, that's really cool.
Perhaps I could piggy back this thread for a somewhat similar use case I have:
I built a dog food scale using a SparkFun OpenScale and some off the shelf load cells attached to a wooden base I built. We have a dog food dispenser that allows the dogs to eat whenever they want: https://www.amazon.com/gp/product/B00IA5I97S/
I wrote a driver in Hubitat that uses telnet to access the weight (and temperature) of the food on the scale. Since it can hold 50 lbs of food, and we generally buy food in 40 lb bags: It makes sense to be notified to buy more food when it drops below about 15 lbs, and then get notified to add more food once it drops below 10 lbs.
Side note: Has anyone noticed there's no "weight" capability in the driver system? I guess no-one ever thought that someone would use a scale as part of a home automation system. 
I had to just expose the weight as a generic attribute.
What I've been trying to figure out is the most elegant way to achieve:
1.) When weight falls below 15 lbs: Send a Pushover notification that it's time to buy more dog food.
2.) When the weight falls below 10 lbs: Send a pushover notification that it's time to re-fill the dog food dispenser.
3.) Don't re-send either notification until the weight on the scale goes above 20 lbs to "reset" the scale notifications.
The challenge is that the scales reported weight can "drift" a bit up and down even when the weight stays constant. This is very similar to a thermostat problem when you might set the fan to come on at 72 but you don't want it to shut off at 72.1. Likewise on the scale it could drop to 14.9 causing a Pushover notification and then 30 minutes later go back up to 15.2 then an hour later fall back to 14.9 again and fire off the pushover notification once again.
I know I could do this in Rule Machine with several rules and a bunch of private booleans, but I was curious if something like WATO might offer a simpler solution?
-Jeremy
Would probably need RM, as there isn't really a good way of doing the set/reset on the alert in WATO right now.
Whereas in RM you could turn off the private boolean after triggered the 1st time, and not turn private boolean back on until > 20 lbs. It will just take more rules (3 I think?), but should be doable in RM.
@Ryan780 I'm going to give your method a try first as I'd like to understand RM a bit more (I've only used it for simple lighting related things). If this doesn't work I'll try the WATO example.
Bear with me, but I don't entirely understand how the rules you gave as an example are working (a little confused by the PB's). I'm assuming the 4 triggers should be separate rules (not all 4 triggers in one rule). Let me know if I'm understanding this correctly:
Trigger 1 turns the fan on when my sensor hits 90 or above (bricks are cold, so this temp increase has to be from the radiant heat of a new, hot, fire). It also sets it's PB to false (I'm assuming that means this rule will not work again until something sets it to true which is when get back to room temp by trigger 4).
Trigger 2 turns the fan off when the temp is less than 110 and then disables the rule so the fan won't turn off again until the temp hits at least 130(easy to accomplish by a hot fire) by trigger 3.
What I don't understand is how rule 1 and 2 dont cancel each other out in this scenario. If the fire starts to get hot and hits 91 Trigger 1 turns the fan on, wouldn't trigger 2 immediately turn the fan off since its <110?
They will the first time the temp goes up... But after that they won't. This is what happens:
At room temp, trigger 1 is PB true but trigger 2 if PB false. As temp goes above 90, the fan turns on and PB goes false for #1 and still false for #2. When the temp gets above
130 PB goes true for #2 but is still false for #1. When the temp gets below 110, the fan turns off and PB is false for 2 and still false for 1. Once it gets to room, #1 PB goes true again getting ready for the next fire.
Basically, until the temp gets on the other side of the trigger, the rules PB is false, preventing it from firing.
@Ryan780 Ok, I think I get it now. I didn't think about the fact that Trigger 2 would be false since it's technically already triggered! Just looked in the logs and see that the PB is set to false right now.
Now to start a fire and test this out. Thank you!
2 Likes
Good luck! Let us know if it works.
Looks like we have partial success - one full cycle of the fan turning on and off. Turning on was set for 80 and it didn't actually turn on until it hit 110 which seems a little strange (110 is set to only trigger an off condition). It did meet my upper limit (130) and when it came back down to 110 it did turn off.
Is there any way to see the current state of a PB outside of the logs? That would make troubleshooting this a little easier.
Unfortunately no. What is your trigger value for setting Trigger #1's PB back to True?
I believe that if you check the rule’s settings page, the current PB state is reflected in parentheses next to the toggle switch for “enable/disable with PB.” Below are screenshots from the restrictions sections of two rules that I use to control two portable humidifier setpoints. I use PB to ensure that only one of them is active at a given time.
Here are my 4 rules to try and make this work:
when the temperature reaches 85 I can hear the outlet cycle on and off every degree change until it hits 110 and kicks on and stays on:
Am I missing something?
What is the current Rule Boolean state for Triggers 1 and 2? I told you that you would have to go through one cycle to get the rule boolean correct for both of them and that it wouldn't work the first time.
Do you have the restriction turned on to enable disable by Private Boolean? You have to enable that, it's not on by default. Its under "restrictions".
I can't see the Boolean state. It doesn't show up anywhere.
I do not have the restriction turned on to enable/disable with private boolean. I'll turn that on for rules 1 and 2
EDIT- after turning the restriction on I can see the PB status.
Rule 1 - False
Rule 2 - True
And you have to go through one sequence of the fan turning on to get the PB correct after turning on the restriction. You still are in the setup phase.
We have success! Turning the restrictions on for these triggers fixed my on/off rules. Everything works now. Thank you all for your help!
1 Like
