Nope, associations are tied to the mode functionality and/or physical switch presses. Nothing can be done about that.
Or maybe I should say the associations follow the switch load.
1 Like
because they can cause the hub to be ignorant about device changes
Talked about this earlier in the thread, but to me, that's a good reason a driver should NOT use what it thinks is the device state.
One of the preferences I saw today (don't recall which device) had an option along the lines of "use device state for optimization". Presumably, a really smart driver that implements some optimization based on device state can be configured NOT to do that.
Anyway, in my case, the latency appears to be in the generation of the motion event and not anything downstream that can be improved.
1 Like
And thatâs exactly what I what I was addressing with putting the device in Occupancy mode, so that the motion sensor didnât need to go through the Hubâs Motion Lighting app to turn the light on. Jason responded by suggesting disabling the light turn off.
Well, I can report that this doesnât seem to work. I am responding here because itâs your thread, and I am addressing this issue of latency you raised.
I put the device in Occupancy mode and disabled the Light Turn Off time on the device page. That gave an error (see above), but Jason said the device was set correctly.
I then removed the Child switch from Motion Lightingâs âLights to turn onâ (the Occupancy mode was handling that), left the switch in âLights to turn offâ for MotionLighting.
Motion Sensor correctly caused the switch to turn on, the device driver saw that, Dashboard state changed to on. However, the switch never turned off, even though the logs said it did in Motion Lighting.
I will test further after the driver is changed, and turn on logging in the driver.
However, the motion sensor turns the child on instantly, no latency whatsoever, when in Occupancy mode, and, according to the logs, Motion Lighting believes it turned the lights off.
Lights never turned off. Note that 1 minute elapsed before turn off. May be a Motion Lighting bug. Worked fine before in Manual mode when the switch was in Lights to turn On. Or, the switch may be ignoring hub commands when on Occupancy mode.
I thought I observed an "instantaneous" turn on of the switch when in occupancy mode too. But yesterday, I think I observed a similar delay in occupancy mode versus configuring in manual mode and using a Basic Rule to turn it on. That's when I gave up on trying to improve the turn on latency.
I'll redo the test now...
Look at my logs. Just a few milliseconds.
Yes, I saw exactly what you see when configured in occupancy mode--imperceptible turn on delay. I saw the instant turn on delay twice
The light does turn off after the 5 minute timeout it is configured for. But, I can't change the light timeout parameter. It stays at 5 minutes.
I tried enabling the basic rule to that turns off other lights when no motion is detected. Motion inactive was detected and the slave lights DID turn off at the delay specified in the rule.
But, now I'm seeing the same (approximately) 1 second delay that I was seeing when the switch was configured in manual mode. At least I saw it two out of two times.
I'll pause the rules and if I still see the delay (while in occupancy mode), I'll take some statistics. Maybe there's an event loop in the switches embedded code that polls. Depending on when the motion occurs in that event loop, delay varies--(just an educated guess).
Turn on delay is still there in occupancy mode, with the basic rules disabled. In fact, Tried it twice. First time it was about a second.
I turned it off manually at the switch and tried walking past again. This time the turn on delay was several seconds. I'm thinking the delay gets much longer if the switch hasn't turned itself off due to lack of motion. I'll have to wait 5 minutes between tests to confirm this-I'll try configuring the motion timeout delay at the switch.
I configured the motion timeout to 5 seconds by pushing and holding the top button on the switch until the blue led blinked once. The driver recognized the new light timeout of 5 seconds.
And, the light turns off about 5 seconds after no motion is detected. I tried a couple of times to check turn on latency--still about 1 second.
That is unless you turn the light off with the switch before the timeout occurs. If you do this, latency is several seconds.
I'd suggest configuring the timeout to 5 seconds at the switch and always waiting for it timeout before trying to assess turn on latency.
Maybe there's an easy way measure the latency so it isn't so subjective. I'd live with the overhead light turning on with motion (instead of just the slave lights) if it would decrease the latency significantly. I thought I was on to something when I saw two instances of near zero latency, but I suspect there's just variability in the motion sense latency. So, I'll probably end up going back to manual mode so I can turn on remote lights with motion (under and over cabinet lights) and have the switches load (overhead light) turn on/off only with the buttons on the switch.
