One of my OSRAM lightify RGB bulbs is acting strange. It is dim, as if the brightness setpoint is divided in half (more like 1/8) most of the time, but then it gets bright sometimes. Depending on what activates it (sensor/automation or flipping hass.io switch), seems to determine if it is bright or not, but eventually it goes to dim. I can’t seem to reliably reproduce the issue on command. I’m running hass.io 0.86.2, but this started happening back around 0.~75.x, same with a white zigbee bulb acting erratic, sometimes dim, and not always responding, but that was fixed with exclusion/inclusion.
It is only one bulb which makes me think hardware, but before I blame my $30 bulb, I was wondering if I could get some debugging pointers. I am a fairly advanced (but not expert) Python programmer dying to use my bus pirate. It just seems like something might be getting scaled weird, or some values for it are set wrong in the zigbee.db somehow. Drawing blanks examining hass.io logs but I may have missed something.
I opened and saw this:
(MAC address redacted slightly on left)
can someone tell me if the values should be identical for identical hardware? This seemed like the ‘configuration’ that could have been corrupted, but it is opening just fine in DB Browser for SQLite.
If it were hardware, I would think it would just die, or flicker or something else maybe. That leaves Home Assistant and the bulb’s firmware going with that assumption. I could just order another from Amazon and do a switcheroo, but what’s the fun in that? I have also tried swapping the bulbs around in my automations (weird one is still weird, it is not noisy wiring or something), and excluding/including with the awesome new ZHA interface!!! No dice.
I skimmed the developer docs, and didn’t seem to find much that could help me with this. How do the devs test their packages for new hardware? Should I just swap them out? I don’t mind diving down this rabbit hole to learn something new, and would like to make my own hardware integrations some day to interface with the robots I’m building
Is the firmware of your bulb up to date?
I’ve one strange acting bulb that randomly turns on, especially when it was switched off short before. The others sometimes refuse to execute a command, for example turn on but don’t change the brightness or color. In my experience this system isn’t very reliable.
Communication with Lightify is based on reverse engineering, there are no official docs from OSRAM and they give no support (they even told me one time that they plan to close the communication port on the hub, fortunately they didn’t until now).
I’m not sure, I have heard they drop support for smartthings or something with recent versions. I am in no hurry to invite more of their closed-source, anti-HA practices into my home but I do wish I could at least compare versions. It also appears I need an officially supported hub (like ST or their Lightify bridge) to activate its OTA updates.
I have had a relatively good experience with this system, and super impressed most of this is done by reverse engineering. I think it keeps the db even when you disconnect, maybe I will try nuking it and see what happens.
Looking at this post:
It seems cluster 8 in the zigbee.db is for level control, I think brightness. Seems to me there should be no difference between that and the other one. They are the same bulb with same min/max light output.
So it appears the zigbee.db is a realtime database of the states of the zigbee devices, not a configuration like I thought. Setting the lights to the same thing still yields different values, and updating the zigbee.db with values I write confirms this, but does little to remedy the problem.
both set to fully bright, then set to warm as possible (with white color still previously selected)
I am surprised the values are not identical still. Does anyone know where the valid values for zigbee.db are decided or stored? doubt nuking will fix this since it changes so often.
