My kids bought me one of these lights. It paired as device - I changed it the the generic zigbee driver and it turns on and off and sets level ok.
My issue is when I push off the light turns off but status never updates. If I push off again it then updates the status correctly. Am I using the correct driver?
Have you clicked the CONFIGURE button after changing the driver from the default DEVICE? Doing so sends a message to the bulb telling it how to report its status to the hub.
I donโt have an Osram bulb, so I am not certain if it is the correct driver or not, but that sounds like the correct one.
I'm guessing it's a non-tuneable Osram white bulb with the 'Generic Zigbee Bulb' driver. I see the same problem (though I didn't play with it long enough to discover the level behavior) with the one I recently moved from my ST setup (where it works just fine). If this is indeed the same issue, it was first reported some time ago by another user Alexa not setting switch to off but it isn't really an Alexa issue. It just doesn't seem to play well with that driver. I reported my more recent experience in that thread 4 days ago.
Yes exactly it is the non-tuneable bulb. I knew I remembered seeing a thread with a similar issue but could not locate it in the search. Well at least I am not crazy / alone.
I ported over a DTH from ST and while it updated on off properly it was updating the level in what seemed to be a random way. But it was encouraging to see that getting the state to update is possible.
I wanted to just pair this thing to my Hue hub, but for whatever reason no matter what I do the Hue hub will not see this bulb. I read some stuff on ST about this being common on a newer firmware.
Maybe if a few more people bring it up it can be looked at.
I am thinking of setting up a rule that says if any of the hue lights in the room change status in any way to refresh this bulb. I think this would more or less keep it in sync, lol I am not sure how easy this would be in RM though.
Either these things are very unpopular because they are non-tuneable (I only have one) or they are rare for another reason. I seem to remember way back when I bought this bulb (back in early '16) it was on a special sale at Lowe's. The website showed two Osram model numbers, both of which were non-tuneable white and seemed identical except for their model numbers. Only one was on sale (the one I bought). At least that's how I remember it.
I did update the firmware at least a couple of times; once through the Lightify Gateway and it updated OTA on ST before I moved it over. It worked fine for the couple of years I used it on ST but I wouldn't be shocked to find out that there is something special about it.
Lots of people really like the inexpensive Sengled bulbs. They are NOT Zigbee repeaters, by design. Many people have reported issues with Osram bulbs not properly repeating Zigbee signals, thus causing mesh networking issues.
it is the correct driver. after issuing an off command we wait for 200 ms and request an on/off report.
Perhaps this bulb takes a little longer to actually turn on/off so it's ignoring the report request.
We have this fingerprint in the driver:
fingerprint profileId: "0104", inClusters: "0000,0003,0004,0005,0006,0008,0B04,FC0F", outClusters: "0019", manufacturer: "OSRAM", model: "LIGHTIFY A19 ON/OFF/DIM", deviceJoinName: "OSRAM LIGHTIFY LED Smart Connected Light"
So I'm surprised it paired as a device, it must have a different fingerprint than the above.
I'll bump up the report request delay time to 300ms, that will be out in the next release, hopefully that will help.
This happens when the zigbee driver is is configured to automatically report level changes, so you do a set level on it and it starts reporting all the changes from the start level to the target level with seemingly random intervals.
I find this annoying, so our zigbee bulb drivers have automatic level reporting turned off, and we issue a level report request after .4 + ramp ?: 1 seconds...
Hi Mike. This bulb still shows this behavior. If level 30 or less off updates instantly. Anything higher than 30 and it will not update to off without a second push or refresh
I will try to remove and add later to get the fingerprint ID.
Yeah I'm pretty sure it is an issue with the driver. I tried porting a driver from ST and while the on/off worked OK and updated I had some other issues.
Yeah I am not sure I convinced anyone it was an issue with the driver either. Or maybe just not enough of these devices to devote time investigating. Either I only have one and have no need for it's status to be accurate so I have not raised anymore issues with it.
One issue I have with hubitat that it doesnt display or seam to read the firmware version of devices. In smartthings I was able to do this with ease. it would help a lot when we have issues if we could trace them to firmware issues.. with my cree bulbs i had a major issue that was documented (randomly turning on and off), and i wasnt able to confirm firmware thru hubitat, so cree luckily replaced all my bulbs
Hi. Just adding my experience with these bulbs. I have the same issue everyone has already described. Only difference is I'm coming from Wink where these bulbs worked perfectly. I have a lot to learn on this Hubitat HE.
Since this thread died in January, I'm guessing no one found an answer. I'd box a bulb up and mail it to someone if it would help. I think i will look for a different bulb and move these somewhere they will be less annoying.
Just got my Hubitat and also having issues with these bulbs. Both were detected as โDeviceโ so I switched them to Generic ZigBee bulb but still acting strange
I purchased a bunch of these bulbs cause they were dirt cheap on a sale over a month ago, to play around with. They worked fine on my wink 2, but I am new to Hubitat and am having issues with my test one. Anyone know if issues with this got worked out? Would it be easier for me to avoid a lot of issues by just buying and using the lightify hub and link that to my hubitat? That would also avoid issues with the light bulbs acting as zigbee repeaters since they would only be tied to the lightify hub no?
Definitely some crickets going on in this thread. I have around 50 bulbs using the generic Zigbee CT (dev) driver and they don't correctly update their status. Since 1/2 the bulbs are Sylvania (of different types), and the other 1/2 are Eaton Halo, I'm thinking the culprit may be the driver.
Sylvania seems to have a ramp for the on/off, which may be causing the bulb to not report within the 300ms in the way @mike.maxwell mentioned before since the bulb is still ramping. I really wish something could be done about this since I can't use the bulbs in the way I want due to the inaccuracy of their status.