I upgraded earlier this evening and just noticed that the wait statement seems to alter the %device% and %value%
My RM included:
And my pushover message came through as
I guess I will need to copy the device and value to LV before the wait??
Note: I am using the modified pushover driver that allows for priority, titles, and sounds. Maybe I should try the official driver.
I will also add log messages to see the values. Maybe I posted too early.
Yup. Just verified that the wait statement now updates the %device% to ‘wait’
And the %value% gets blanked out.
Just want to make sure this is an intentional change?
I believe that was actually the stated intent.
Previously, there was no way to tell if a "Wait" ended due to timeout or due to the wait condition being satisfied.
This now allows that distinction to be made clearly.
I ran into cases where the Wait condition was satisfied but, due to "race conditions", the devices actually tested false unless I put a delay (1 sec) between the wait and the "If (xxxx) then" test. The problem with the 1 sec delay is that the proper condition might be satisfied for the Wait--but change to unsatisfied a second later, etc.
This solves those issues by creating a "definitive" test (it reflects "timeout" if the Wait times out).
It also provides information about what device ended the wait, if it does not time out.
Awesome. Thanks for confirming.
Reread the release notes.
Was not nearly descriptive enough to know what it meant.
This is partially my fault. I raised the issue when I had an odd event.
I'd put the 1 sec delay in for the race conditions--then got into another case where a delay in the first event caused the "door opened" and "door closed" events to appear to happen in about 1/2 second--I certainly can't open the door, enter, and close it that fast!
That was def something that could use a solution--and this was the solution.
So, the response to my concern gave me a bit more background.
And, I'm very glad for the change! Although "breaking" changes are always rough.
Yes I agree that it’s a good change.
I can also see where it will be nice for debugging.
Now with the possibility that more than one wait can be added into the wait logic with 4.1 (something I have been waiting for) it would have also been nice if it would have identified the “wait” item that triggered it. Maybe that what value is used for it there is more than one wait item.
Need to play with 4.1
The worst part is I don’t know how many rules are broken right now.
Download the Hubitat app
