I’ve got a battery hooked up to my solar panels and when I was playing with a rule to take advantage of the battery charge I found myself wanting conditional logic in the waiting for conditions function.
The rule I’ve got will trigger on the battery charge reaching 90% and will then turn on a big load in the house. I want the rule to turn off this load again when the battery goes under 80% or at sunset. I can achieve this by introducing conditional logic to the rule and then put it on a periodic trigger or add the triggers for the other events, but for simplicity’s sake (KISS) I wanted to instead have the rule just waiting for either of these conditions to occur.
Hence my feature request. Would it be possible to introduce conditional logic to the wait for conditions function so it will wait for either this or that to occur rather than just the one condition?
I would be very happy if someone could advise on a workaround to the above requirement without resorting to additional triggers. If that is possible, then I wouldn’t need this new feature in the wait for conditions function.
The battery will only be charging while the sun is up, so the battery will only reach 90% before sunset, so the battery level is the only thing I need to trigger on for the “on” event since “before sunset” is implied. But power off should occur at either sunset or when the battery level drops below 80%.
I can easily achieve this with more triggers and conditional logic in the rule, but I’m trying to simply the rule and follow Bruce’s advice to use simpler triggers, less conditional logic and use wait for event or condition instead.
Like i said im not the best. but i think this would do it.
basically you create a condition that it has to be a certain time of day and over a power limit for the private boolean to be true. and while its true the light is on. but if it becomes false the light goes off. you are then not having to wait for two things. SOmeone can probally clean this up but i think this would work.
you may have to add more code to set the boolean false. but i think this is the right path.
Edit: the trigger would then become the power level chaining instead of the => 90%. so that each time it changes it evaluates teh rule.
Thanks @jrobertson50. Yes, something like that would work, but it doesn’t fit in with the simplification mission I’m on. This rule would then trigger at every change of battery level. My mission is to have the rule trigger only once and then wait for the right condition to occur to turn off the load.
What is the benefit. Either way it's evaluations conditions to make a choice. The way I put it's waiting for a condition to change. Your way is waiting for a condition to change but with a different command. What am I missing? Is HE doing something different behind the scenes?
That is one of the things I wish someone would explain better. It is also unclear to me what is happening, which is why I do the old way of writing rules (IF, THEN, ELSE) instead of the new "simpler" and "better" way.
I am presuming that that once triggered by the event, that somehow, something, that is not visible to us subscribes to the opposite event, or a change of event state.
The benefit is that it makes the rule easier to understand and follow by removing complexity and it reduces the load on the hub.
With only one trigger, HE will only run the rule when that trigger occurs which lessens the load on the hub (even if, in the great scheme of things, only by a small amount). If set to trigger on every change, it will run the rule every time the battery level changes and evaluate the IF statement. I only need it to run when the battery level hits 90%, so all other times the rule runs, it’s basically wasting resources. The wait within the rule for the off condition to occur will subscribe to the event or condition I’m waiting for. It will only fire once when that occurs, again reducing the need for extra processing when it’s not required.
If you haven’t already, I’d recommend watching the latest Hubitat Live where Bruce goes through this process of simplifying rules and removing complexity: https://youtu.be/qPrVDyYGGAE
Edit: I’ll just emphasise that what you have suggested would work (so I’m not saying you are wrong or anything), it just doesn’t fit in with what I am personally trying to achieve.
At the moment it cannot, because the wait function cannot be set to wait for one of two different types of sensors to trigger. That's what this feature request is for.
I've got the rule set up the way I want already, but at the moment it only waits for battery to drop to 80% instead of either battery level dropping to 80% or sunset:
That sounds like a good compromise, thank you. However, as I was modifying the rule to incorporate your suggestion, I realised that the wait function has a timeout feature. I'll see if I can use that to replace the requirement for the sunset trigger. I'll post back with the result
Ok, so I think I've got something that might work now. To work around the fact I cannot wait for either of two events to occur, in my case I could use the timeout feature in the wait function as my second event. I was just lucky this time that my second event was a time. What I ended up with was this:
The rule only has one trigger - when the battery level reaches 90% or more.
The first action is to turn on the load. I then want to wait until either sunset or the battery level drops to 80% or below.
Since the wait function has a timeout feature, I reckoned that I could use that as my sunset event. I happened to have a device already which had an attribute for how many minutes there are until sunset so I used that to put in to the local variable "TimeDelay" and then converted it to seconds.
If all goes well, if the battery level is still above 80% at sunset, the timeout on the wait should kick in at sunset and the rule will proceed to turn off the load. If the battery level is lower than 80% at sunset, the wait will already have finished and the rule would have proceeded to turn off the load.
However, had I had a different second event I wanted to wait for, I wouldn't have been able to work around it this way.
@bravenel Bruce, would it be possible to add this to the list of feature requests? It would be useful if the "wait for" functions in RM would be able to use several conditions. An example would be like above: wait for battery level to reach 80% OR time is sunset.
So I'm a networking and video engineer. So I get pretty freaking technical on things. I really would like to know the difference on the back end of why one verse the other makes a difference. If the system is processing all the vents coming into it and matching it against rules. then I would really like to see what the difference is as far as CPU memory etc
It's been requested before. I'll look at it. There is a fair amount of complexity involved, and feature creep.
Note that waiting for multiple conditions might be accomplished by waiting for multiple events (each related to the conditions) followed by an appropriate Conditional Action.
Yeah I requested it recently. Would certainly appreciate it if possible because the work around is such a pain and this would be a much more elegant solution and align with other parts of the code.
I'm not at all inclined to do this. It would introduce a level of complexity that is beyond what I think is prudent. Waits are a complex feature to begin with. IF-THEN is a very complex feature. This would entail multiplying those two with each other.
You could use a separate rule that evaluates the conditions you want to use, and have it set a global variable. Then use Wait For Condition on that GV.
Yes, that did pop in to my mind as well when trying to figure out how to solve the problem above. I was thinking of using a virtual switch instead of a GV. Is there a benefit of using one over the other? A switch could be used and set by other apps, not just RM, but other than that I presume they both use about the same amount of system resources to use?
I appreciate that. However, for my use case I don’t need the whole IF/THEN/ELSE functionality, only the OR/AND functionality. Sorry, I may well not have used the correct wording for the title of this thread. The ability for the wait function to be able to subscribe to multiple different sensors and trigger on either all of them becoming true (AND) or one of them becoming true (OR) is what I’m after.
