Nor can we without seeing the entire rule, with trigger events being the most notable omission from your screenshots. Logs would also be helpful.
But here's a guess: it's probably that Wait. I don't think this normally changes the value of device except after a timeout (as opposed to an actual event), but variable waits may work differently, or it's possible something changed. Setting the value of a local (or hub) variable to %device% before any Waits and using that variable instead would avoid this issue.
...if, of course, that is the cause, which the above would help show.
Yes thanks! Sorry. Was trying to keep it simple but yes, I understand.
So I recreated a bare-bones rule but it's doing the same thing: setting %device% to the name of another variable instead of the current device.
If I set a hub variable (sDevice) to %device% before the wait, as soon as the 2nd contact is open but before the repetition for the 1st contact is finished, the %device% changes to the name of the 2nd contact.
If I set the hub variable (sDevice) to %device% AFTER the wait, %device% is correct for the 2 repetitions but after the wait is over, %device% changes to the name of another variable instead of the contact name.
Yes I did. If I set a hub variable (sDevice) to %device% before the wait, as soon as the 2nd contact is open but before the repetition for the 1st contact is finished, the %device% changes to the name of the 2nd contact.
Sure. The idea is not to stop the built-in variable from changing but rather setting and then
The value of this variable will not change unless you do so yourself (even if the variable it was originally set to does change--i.e., think of it as a copy and not a reference).
First, I set sDevice to the %device% that just opened.
Then when another contact opens, I set sDevice to %device% which should be the new contact but it always sets sDevice to the name of a variable instead of the device that just opened. In fact, even %device% becomes the name of a variable instead of an actual device.
This seems to be after the wait, as I mentioned above. You would need to set this value after the trigger but before the wait (or anything else that might change %device%). From your logs, I don't see that happening the second time it's triggered since your expression is true that time and the Wait is reached in that case (I don't see evidence of this happening the first time when it's not).
Yes that is true. Thank you for working through this with me.
I had also tried setting sDevice before the wait and in that case, %sDevice% (and %device%) = 1st contact for only one time and then switches immediately to %sDevice% (and %device%) = 2nd contact before the repetition for the 1st contact is complete.
So instead of sDevice = 1st contact twice and then sDevice = 2nd contact twice it goes:
sDevice = 1st contact once and then sDevice = 2nd contact three times.
After playing with this, I ended up using delay actions by seconds.
Used hub variables (number):
rptTimes
rptSeconds
rptSum
Pretty self-explanatory and LOVE LOVE LOVE the ability to do math in rules. AWESOME!
So then rptSum is used to delay playing the message for the 2nd contact.
All this started because on Christmas, one of my grandsons opened a door at the same time one of my daughters-in-law opened another and, well, my sensor programming was the cause for much laughter and jokes. No more! lol
It seems like the final delay of 2 seconds should be added to rptSum but it works with 3 repeats so I left it that way.
Logs would also be helpful.
