I'm having trouble with my living room Motion Lighting. If we sit still for a while watching TV or such, the lights turn off. Fair enough, no motion was detected. But then I can stand up, walk around, wave my arms, and cluck like a chicken, and motion lighting won't turn my lights back on.
(What's that?
Motion Lighting only detects Quacks, not Clucks? Alright, hang on, I'll try that...
Ow!
I was just hopping around and quacking, and stepped on a lego that I didn't see. Because it was still dark.)
Here's a copy of the logs for the last few minutes. Can anyone tell me why Motion Lighting might think that my lights are already on?
(And for that matter, why is it not logging quack detections? Nevermind, I'll figure that out another day. )
The big question would be: does Hubitat think that the light Motion Lighting is turning on is already on? Check the device page for that light in Hubitat to be sure, or check its event history if it's too late. It looks like Living Room 1, 2, and East (presumably the bulbs you're turning on) were indeed already turned on--but Motion Lighting didn't do it. Can you see in your logs if some other app/automation may have? Also, what kind of bulbs/switches are these?
The bulbs are sylvania bulbs, connected to a secondary HE using hubconnect.
While I concur that HE seems to think the lights were turned on, I can assure you that they were not.
I wonder if this might be something going wrong in the process of HubConnect communicating between the two HEs. In that screenshot, it shows that it's turning off the "Living Room Lights" group at 20:50:20. The next 3 entries say it turned bulbs on, when it was actually turning them off. Then it shows turning the group ON, and again says all 3 bulbs were turned on. Hmm...
HubConnect is a 'reflector' and much like Dashboard, 90% of the debugging gets done against the 'real device'. If, for example, the real device is misbehaving, then Dashboard and HubConnect will simply reflect that misbehaving.
On the Hub where the real device is located, does Motion Lighting match? Motion = light on? no Motion = Light off (perhaps after a delay) ?
If not you will want to focus on getting that to work because every thing else is simply 'parroting'
( yea, mixed metaphor - reflections then parroting. )
I'm not quite sure what you're asking. The screenshot in the OP is from the Server Hub (HUB1). The post form 20 minutes ago shows logs from the remote hub (HUB2).
The motion lighting app and groups app are on HUB1. The only thing on the HUB2 is hubconnect and zigbee bulbs.
As a test just now, I went into the Bulb 1 device on HUB1 and controlled it using the On and Off buttons in the device page. Looking at the events for that device, I see something odd -
If the bulb is OFF and I click the ON button, the physical bulb turns on and an event is logged showing that the bulb was turned ON. So far so good...
If the bulb is ON and I click the OFF button, the physical bulb turns OFF, as expected. However, the event log says the bulb was turned ON.
If the bulb is OFF and I click OFF, the bulb stays OFF, and the event log shows that the bulb was turned OFF.
I was able to reproduce this a few times. Here's a snip of the last few log entries. The bulb was ON to start. I clicked the OFF button 3 times. The bulb did turn off the first time I clicked it, but that's not what the log says...
The duplicate events coming off the websocket may be causing issues with your rules. There's a patch in (EDIT: HubConnect) thread that could fix it, but the easiest troubleshooting step is just to switch to http.
1.6 is coming out on Saturday (or Sunday) which fixes that. If the switch to http fixes things, you'll be able to switch to websockets after the upgrade.
I was just going back reading recent posts on the hubconnect thread, and see that you've spent the last few days investigating similar behavior. I should have read that first I guess, but my initial thought was that this was a motion lighting issue, and not a hubconnect issue.
