Lights on when device is off

[vctgomes]

I have some automations to turn off my group lights when no presence, however sometimes the light stuck on, even with status being showed as off on HomeKit or Habitat.

As you can see on these grouped devices, the switch is technically off, however on groupState that's allOn.

Is there a way to fix that and prevent the broken automation?

[jtp10181]

Post a screenshot of the rule.

What sorts of devices are in this group? Have you checked the events for the individual devices, they should be getting a command to turn off from the groups app.

[vctgomes]

Hi

I'm using simple automations to turn lights on or off, when the presence sensor detect presence or not.

It doesn't have any complexity, but even that the lights stuck on sometimes.

Including, it happened again right now

[jtp10181]

Turn on logging for the group device and the actual devices in that group. Then get a screenshot of the logs when it happens. That will show more of where the break is.

[vctgomes]

I tried to enable Logging on group app, but it doesn't show any relevant information.

Only the info that light is off. Including, the last 21:15:20 is being showed as off, when the lights are actually on.

I also turned on the log from the grouped device:

And also no relevant info. The off command looks to be sent, but lights continue on.

This is the log from one of the grouped devices:

[jtp10181]

On the physical device, the event log would be more useful since you can see the commands. Seems like you think the command is being sent but the device does not respond?

There are a couple of way you could work around this. If you converted your group to room lighting there is an option that I think would make the group state switch back to on if the devices do not turn off.

Also, on your rule you could add a second off command with a delay of a few seconds. A lot of times stubborn devices like this will respond if you send a second command.

[vctgomes]

@jtp10181

On the physical device, the event log would be more useful since you can see the commands. Seems like you think the command is being sent but the device does not respond?

Yep. That's exactly what's happening. The command looks to be sent, but lights doesn't received it.

@jtp10181

There are a couple of way you could work around this. If you converted your group to room lighting there is an option that think would make the group state switch back to on if the devices do not turn off.

I was using Room Lighting before with this feature, however habitat seems to think the light is already off, because the status is off, so I think it won't work.

Isn't there a way to make Group light check the light status again after the command? It'd be welcome.

@jtp10181

Also, on your rule you could add a second off command with a delay of a few seconds. A lot of times stubborn devices like this will respond if you send a second command.

But I'll try it too.

[jtp10181]

@vctgomes

I was using Room Lighting before with this feature, however habitat seems to think the light is already off, because the status is off, so I think it won't work.

Don't add the existing group to room lighting, re-create the group in room lighting using the individual devices. Room lighting was designed to replace groups.

[user837]

Hello,

Before I can provide any additional comments can you provide me with:

Device type & manufacturer or more of the device specifics lower in the device display. I gather it is some type of bulb but I don't have would like to know more device specifics.

Does it rely solely on drivers within Hubitat or does it also relay on an additional Hub like Philips Hue, Lutron, etc, Answering the above will most likely address this.

Thanks,
Don

[vctgomes]

@jtp10181

Don't add the existing group to room lighting, re-create the group in room lighting using the individual devices. Room lighting was designed to replace groups

Is it possible to use Room Lightning and Zigbee group messaging? I'm using it on Group Devices.

[vctgomes]

@user837

Device type & manufacturer or more of the device specifics lower in the device display. I gather it is some type of bulb but I don't have would like to know more device specifics

That's the Moes GU10 lamps, with Zigbee.

I'm using it with Tuya Advanced Zigbee RGBW Bulb from kkossev

@user837

Does it rely solely on drivers within Hubitat or does it also relay on an additional Hub like Philips Hue, Lutron, etc, Answering the above will most likely address this.

I tested it on Zemismart ZHA-1 hub. No problem, but it doesn't support Zigbee Group messaging as Habitat does, so the performance isn't good when turning off/on multiple lamps.

[jtp10181]

@vctgomes

Is it possible to use Room Lightning and Zigbee group messaging?

Yes

Zigbee Group Messaging in Room Lights

Room Lights supports Zigbee Group Messaging (ZGM). This allows multiple Zigbee lights to activated by a single command on the Zigbee network. Doing so both cuts down on network traffic, but also causes the lights to respond all at the same instant. However, there are limitations to this feature, and understanding exactly how it works sheds light on these. ZGM is tied to an Activator Device. When the Activator device is commanded, all of the lights in the ZGM group are commanded in exactly t…

[user837]

Sorry for the delayed response and thanks to bravenel; as always, for his in-depth and insightful responses.

I have seen in two scenarios myself whereby the state shown on the device attributes were different than the actual operating state of the device.

In both of my situations two hubs were involved. HE and the hubs hosting the devices. One situation involved a Lutron hub and the other involved a BroadLink hub.

My first approach was to repeat the command with a delay like that suggested by jtp10181. It did help but did it not provide the 100% consistency needed. After multiple tests It appeared to me that:

1. HE was consistently sending the request to the 2nd hubs.

2. The 2nd hubs were acknowledging the execution of the commands but the devices were not changing states.

It was like in "IP network terms" the packets / payload from the 2nd hubs were never reaching the devices and were simply being "dropped." This failed state change was never making it back to the device attribute in HE.

By moving the 2nd hubs closer to their end device to help ensure connectivity in both cases resolve both issues. I don't know how; if at all, if this can relate to this situation since I don't have any experience with these devices specifically. Although sometimes as much as things change they still have similarities. Maybe something here might help. If not my apologies for rambling for nothing :-(.

Don