@James - I’m unable to get “Stays” working. Here’s a very simple rule. Why wouldn’t it work?
Table1 is a Hue bulb.
Thanks!
Hey Stan-
Can you share a screenshot of the Rule Log for the period you were testing? Can you please make sure to check the box for Debug in the filters?
What platform is the device in and what does the device event history look like there?
1 Like
I would add that unless the Hue Bulb is connected directly to your hub via ZigBee, most of the hubs use some form of polling for status updates.
So depending on your hubs polling configuration, the rule might not work as expected if it isn’t able to get the events / state at the times you would expect.
You may be able to adjust your hubs Hue Bridge polling rate to account for this (assuming it’s what is impacting you).
I also tried the same thing with a virtual switch. Same thing.
Log from the Hue bulb:
Log from the virtual switch:
What about the events from the hub?
In the SharpTools Rule Logs, when the switch first turns on and you’re using a State Stays trigger, you should see a debug log line that indicates a potential trigger. Then when the state stays condition is complete, you would normally see the normal trigger event occurring.
Since you’re not even seeing the initial potential trigger event in the SharpTools rule logs, it seems like there’s some sort of event problem.
No hub events from today for the Hue bulb.
Only hub event for the virtual switch was at 12;28pm, which is when I created it.
It sounds like solving that is going to be the first step. For the virtual switch, did you try turning it on and back off from the Device Details screen in Hubitat to see if it’s generating events?
1 Like
Turning the virtual switch on/off from hub yields this in Hubitat logs:
And this in SharpTools logs:
I’m completely lost…
Hi @Stan_Silverman, maybe I can help explain why does the log looks like this by focusing on one event sequence. Ex: the switch is turned off at 7:00:24 so the debug log says it can be a potential trigger but it needs to wait for 1 minute based on the state-stay trigger configuration and verify if the value has started off during this minute. Then at 7:01:25, the log says the the rule verified the switch did remain off for the past minute, so the rule is triggered and send the on command to the switch at 7:01:25.
At 7:01:26, the rule received an on event (because we just sent the on command) and it is completely different then then state-stay value (stay off for one minute) so the log can immediately determine this rule did not get triggered by this event.
Does this flow help explain what happened during that time?
2 Likes
Well - I won’t commit to understanding it yet! I would have to study it for a while. Probably a long while…
However - the problem I’m having goes back to the first post in this thread. The event (turning a device on) will not happen if the device (same device or another one) stays off for a minute. Does your explanation cover this situation?
Sorry I’m so dense…
What I think I’m getting from this is that in order to know that something has stayed off for a period the rule must first know that it had been turned off,
1 Like
That’s correct. For a State Stays trigger, the rule basically needs the initial trigger event of the device entering the desired state… then it waits the desired ‘state stays’ duration and checks to make sure it stayed the desired state (eg. it didn’t change to ‘on’ during that ‘state stays’ window)
From your screenshot, it looks like once you manually toggled the Virtual Switch on and off, the rule did successfully run though:
For example, in the highlighted red box, we can see that the switch turned off at 7:03:37 which is associated with the potential trigger debug log line. Then 1 minute later at 7:04:37 we see that the switch stayed off so the rule was triggered and the on() command was sent for the device.
2 Likes
Thanks! Finally got it. Appreciate your help.
2 Likes