I have one GE Link acting differently than the rest. It won't show status updates of on or off. If I re-add it to the hub with a full reset of the bulb, it works for a short while then stops.
The On/Off commands still work, but since status won't update, automations leave it stuck on, or off. Motion Lighting doesn't seem to just send the command, it's checks status first.
Can this be disabled, or are there any steps I can take to fix the issue?
I've joined each GE Link and Cree bulb that I have with the new driver, one at a time right next to the hub, with all others powered down, so none should be using a repeater.
Sounds like it just isnāt pairing properly or potentially malfunctioning. Did this bulb pair and work correctly on anything else before Hubitat? If so, was it removed from that system fully?
The odd thing about the Ge Link and Cree bulbs is they are ZLL first and ZHA second (we use ZHA). ZLL allows a much different creation of a āmeshā than how ZHA coordinates the mesh.
If you paired it with Hue Bridge or ST, it could still have itās ZLL configuration. Reseting the bulb isnāt going to clear out those associations with the other hubs/bridgesā¦
Not saying this is the issue, but could be a contributing factor.
How many repeaters might this be going through to get to the Hubitat hub (I know, I wish we had better tools to answer this )? Is it close enough to connect directly? Any difference if you move it to a different location?
Iāve had a GE Link bulb go bad, just started flashingā¦ A couple of my Creeās did the same thingā¦ In the interest of full disclosure, I personally have all my bulbs on Hue Bridges (hopefully weāll get the Hue integration released soon!)ā¦
Itās literally the closest zigbee device to the hub. About 5 feet line of site, through a single pane wood door where my Hubitat and ST hub are located.
I was joined to ST before, and I didnāt remove any of these lights from ST. I just reset them and joined them to Hubitat. If I rejoin to ST and properly remove, will it clear the possible ZLL config?
Itās right next to an identical bulb thatās working fine, but who knows, maybe itās repeating through that.
Does RM have a feature to force the commands? I know that was in CoRE but canāt recall if Iād ever seen it in RM. If I can just force it to send the command regardless of state, that would solve this issue.
Simple and easy test. Just unplug ST and remove batteries for a about 20 minutes and see if the bulb acts any different. Just want to rule out the ZLL config getting the messages and not Hubitat.
Also, just to eliminate a routing issue with the bulb next to it. Try unscrewing that working bulb and see if things change.
Is the Rule Machine Rule using a trigger? Triggers behave a bit differently and I donāt think require a status update.
Not ruling out something on our end, but with other bulbs working, its got to be a routing or device issue at this point or worst case a bad or incomplete join (probably due to routing).
Thanks for trying to sort this out with us. It can be very frustrating when these things should ājust workāā¦ I had a bank of 5 smart bulbs over a vanity when they first came outā¦ 9 times out of 10, one of the bulbs wouldnāt turn onā¦ Turns out these things do not like to be clustered close togetherā¦ Wenāt back to dumb ledās and a wall dimmer and moved those smart bulbs to other fixtures, never had a problemā¦
Iāll give that a shot, I want to say that already happened a few weeks back but canāt recall clearly.
I am planning on eventually replacing the bulbs with dimmers, but right now I canāt bring myself to dump more money into the few issues I have with them.
Once I see $20 dimmerās maybeā¦
I certainly donāt believe itās an issue with your end, I was just thinking maybe with the driver and that specific bulb.
Stupid question, the on/off for debug logging, which is on? The lights show log entries when off is displayed, but to me, the non grayed out black ON would be the onā¦
Black is onā¦ No stupid questionsā¦ If the bulb is doing something different then the rest, we might be able to address it in the driver, but have to figure out how to get another bulb to do it (or not) and see what we could then address in the driver.
I had a somewhat similar issue with 2 Sylvania zigbee bulbs. With the Generic Zigbee Bulb Driver, it started out updating status fine, but then each command would have to be sent twice for it to update the state, or a refresh called after each command. Theyāre probably both on repeaters since thereās a few Zigbee devices in-between. Your case is different though where itās not reporting status at all. I initially tried porting a DTH from SmartThings but had some issues with setLevel and fade. I tried out the ZigBee White Color Temperature Bulb driver and itās worked perfectly since. I only use on, off and set level. I havenāt tried any of the unsupported commands though for fear of burning a hole in my ceiling
I just tested one of my GE Link Bulbs and noticed it was no longer updating its status either. I changed the driver to the āVirtual Dimmerā to make sure that would change the switch state correctly. Of course, that worked. So I then changed it back to the āGeneric Zigbee Bulbā driver, and now it is updating its status correctly again. It could be a coincidenceā¦so having another use test it would be helpful. Tagging @mike.maxwell to see if he has any ideas?
if I sequentially switch them (via Mqtt), their status does not always get updated. However, if the switching is done through a virtual dimmer (either via mqtt or Simple Lighting app), the status is always correct.
I updated the hub firmware to the latest 1.0.3.704 version yesterday; donāt know if I can say that Iāve noticed improvements from the previous versions
Meanwhile, I added 100ms pauses after each sequence step. Itās working better now; but I am not sure the problem is completely solved.
)? Is it close enough to connect directly? Any difference if you move it to a different location?
