Hi, wow!! i am pretty excited that I caught your attention. Right now i am up to my eyeballs with trying to upgrade from Sonoff-basics to the Tasmota-hubitat on 18 Teckin SP10 plugs so i can't divert right now (WAF #s woudl go way down!!)
But this was the original situation i got into when thinking that i should have recoded my RM with a state variable. Originally when i purchased my leak sensors i gave the HSM a go. I really didn't spend enough time with it but it did alert me to a leak sensor & then never again. Since leak sensors are pretty important to me, i didn't want to chance it to code that was hidden & i could not debug. long story short is this is my RM. I use contact switches that trigger alexa warning and those contacts get reopened by another rule.
I did have Alexa TTS installed, but the cookie thing makes it unreliable for something like this. My next project will be the Echo Speaks, but so far I have only been reading & not implementing.
You are absolutely right, with out limiting the inputs being looked at at each state, you can inadvertently have your code follow the wrong path at unintended time. With states, you can say - ok, this is what i am considering inputs/events/whatever at this time and all other conditions are ignored. it's all about the KISS principle !!
Maybe you would like to take discussion right now off the main thread, and i would hope that by early next week i will have time to devote to this.
Feature request: Could something be added to make it easy to replace devices used in rules?
I have had to change some sensors around recently, and am finding that Rule Machine does not allow me to easily change the sensor used in a conditional expression. I instead have to re-do all conditions using the new sensor and delete the old one. This change would make a great addition, if it is something that can be done...
I did a quick search (research / finding these things is NOT one of my strengths )but didn't find this as a request or an available work around other than re-creating the condition.
This isn't necessary. On the Actions page at the bottom is the section to Manage Conditions. Edit the Condition that you want to change the device in, and it will allow you to deselect the sensor that is there, and select a different one.
Ah! This is great! I never realized I could do that... Only a couple months in using Hubitat and still a lot to learn! Thank you so much for this info!
It broke when I was trying to add a statement before the first on1(). I accidentally pressed END-REP, however I hadn't pressed the "done" yet so I pressed "cancel action" but then it broke the whole thing. Anyway to fix without redoing the whole thing?
Ok.. I guess I'll just rebuild it. Whilst we are on this I think there are some issues with repeating actions. In the last day I have made a few rules with repeats and I have seen some odd errors:
java.util.NoSuchElementException: Cannot pop() an empty List on line 6320 (doRepeatR) - gets thrown in the logs with one of my rules during the time that it is repeating.. although as far as I can tell at the moment.. the rule is working as intended
In 2 cases the statement "Stop repeating actions" does not do what it is supposed to.. as in, the rule just keeps repeating anyway - I've checked that nothing else is re-triggering these rules. To get around this problem I added "exit rule" after the stop repeating statement and that appears to work at the moment.
The "cannot pop()" error is due to simultaneous instances of the app running. This usually is a sign of it being over triggered. You need to turn on logging, and demonstrate a failure in the logs. Without logs, there is no way to know what is going on.
Ironically those 2 cases do not have the pop issue - and I have checked with logging on and they are not being over triggered.. the stop repeating actions just doesn't seem to stop it repeating, but exit rule seems to work
The pop issue is separate and affects only one rule
id put it at the beginning and once, (before the 1st IF)
also the delay need to be cancelable (toggle in the action)
only other thing (might need to test) i didnt think (mode asleep) you would need the on command, the set color and level might turn it on by default
)but didn't find this as a request or an available work around other than re-creating the condition.
