First time posting here and just recently got into the smart home world.
Just having an odd issue with a 3 Gang light switch not reporting the correct state to openHab.
Seems to report any “OFF” state correctly but not “ON”.
For example, if i turn on Light #1 openHab will show the switch as “ON” for a second or two and then show as “OFF” even though it’s still on. This is when turning on via openHab. Doing this at the switch will not show the “ON” state in openHab but if i trigger the switch on from openHab twice then both will show as “ON” and then if i turn off the light at the switch then both will show as “OFF” which shows that they are communicating states but only for “OFF”.
Assuming because it’s a 3 gang switch that maybe it’s sending commands that the Zigbee binding does not understand?
Can you please provide a debug log - this is described in the binding documentation. Since the devices are clearly communicating it would be worth finding out what that communications actually is…
Also, can you advise what version of the binding you are running?
Can you tell me what the log shows please? i can see reports, and everything looks fine - what I can’t tell is what you did, and what the lights did, and what the problem is.
I turned the light on via habpanel.
What happens is when you turn the light on the icon in habpanel will show as on for a second then display as off. The light is actually still on at this point.
I then hit the button again and now it stays on along with the light.
Turning the light off works as expected.
Also if i was to turn the light on at the actual switch it never reports it’s “ON” state but does for turning the light off.
It’s a bit hard to correlate this exactly with the log since there are quite a few actions in there. It might be good to provide just a log showing this one thing, or, to provide a log showing a number of things, but time them - eg at 01:20:00 I did X, at 01:20:30 I did Y. Sorry - that probably sounds a bit excessive, but it helps me understand what the logs show as this isn’t always the reaility of what you are doing or what you see…
Anyway…
One thing I do see in the logs that might be what you are explaining is this -:
What this shows is that the bulb reports the level as 100, then reports the state as OFF. This is at “exactly” the same time. The binding treats this as OFF - this sort of thing is quite common - a bulb can be off, but the level can be 100%, and this means that if the light is turned on, it will go to 100%. We see this in a lot of switches. You can see that in this case the binding reports the state as OFF.
However, maybe this switch has implemented it differently - I kind of doubt it as sending OFF, but at a level of 100 at exactly the same time does seem strange.
There is 1 issue I see with this switch - it has reported the state as 100 here, but I suspect this is 100%? Most (probably every other one I’ve seen) bulbs/switches use a value of 254 as 100% and scale accordingly - this is the standard way ZigBee calculates the level commands. I think this switch may report in percentage, so that will cause a scaling problem (but that is probably the least of your concerns right now it seems ). I can probably change this if the switch supports some other attributes that allow us to work out the scaling.
If I can find one of these cheaply I might buy one for testing - are you able to point to an international supplier for these?
I would suggest to start a new thread since you are using mqtt and not the Zigbee binding that this discussion has so far been about, so it’s a little confusing…
Sorry - I’m not sure what else I can do to diagnose this. I don’t have this device for testing and don’t currently understand what the logs were showing - hence my unanswered question about what actually happened on the physical device.
I’ve not been able to find a device to purchase in the UK, so can’t really progress this. If you want to send me one, then this could help.
). I can probably change this if the switch supports some other attributes that allow us to work out the scaling.