From where, I can get Debug log
Please check the ZigBee binding documentation.
It means that the serial port can’t be opened. The driver is not missing or the binding would not run at all.
This should fix one of the
UNSUPPORTED_ATTRIBUTE entries you see in your logs…
Can I use @5iver´s script to update the binding, or is it not ready yet?
No, it’s not merged yet… Give it a day or two…
Thank you chris,
So, how can I open serial port.
I will take a look at this next week. You other option is to use 6.3.4.
Hope - it is correct to continue the zigbee discussion here rather than make a new post.
Yesterday I ran into an issue with a newly paired bulb that I can’t tell if the discovery caused the incorrect operation or if its something with the bulb attributes. (This new bulb was a warranty replacement of a sylvania lightify bulb that was 1+ years old/was first discovered into openhab on an earlier testing release of 2.4 openhab. (this new bulb identified as a ledvance bulb)
Anyway - the issue that i’ve run into is that the color temperature channel seems to be reversed. On all of my 10+ existing bulbs the color temperature is a scale of 1 (warm white) to 100 (cool white). This new bulb, however, is the exact reverse. 1 equates to cool white and 100 to warm white. My questions are - is this supposed to be standardized in the binding or is this a problem of the bulb? I did have some odd issues getting this bulb to pair properly - some of the recent unstable builds would throw an info message about being unable to determine if the bulb supported RGB and therefore it was assuming it was HSB compatible. One last difference I noticed is that this bulb shows an _1_channeltype discovery rather than a _2_channeltype as the other bulbs have.
Let me know if you think i should switch to the testing build - i did see that m4 had a recent build date of just a few days ago. Any advice you might have would be greatly appreciated!
The reversal of the color temperature is something that was raised recently, and can happen under specific circumstances with some bulbs. Can you tell me exactly what bulb you have (preferably with an EU link) and I might look to get one to test this issue.
I know this isn’t an EU sale link but my hope is that this can guide you in the correct direction? The model number is 73693 - hopefully that can assist you. I find these bulbs to be quite affordable and reliable compared to many of the other bulbs out there. (approx 30$ usd for tuneable white/full color) They have been fairly reliable with openhab/ my ember coordinator as well.
Regarding the change in color temperature - I was thinking it may be that. I’m not opposed to removing and re-joining all of my bulbs if I can get them to regain the color temp direction in a uniform manner. I know I did try to remove and rejoin one other bulb but it seems to have kept the old setting. Is there an extra karaf command/json file I may be able to clear out to force a full redetection? I have another spare telegesis zigbee coordinator that I can use on a non-prod openhabian install if you need me to check joining one of the old bulbs to a fresh install on new code- to see which direction the CT channel works.
I know in the past i’ve run into phantom ‘persistance’ on things that are a mystery - despite bindings and configs being removed. (ie zwave nodeid’s somehow incrementing despite seemingly clearing everything - or the persistence service remembering which items had created table entries already and not recreating them if they were deleted from the database directly).
Thanks so much for your prompt reply!
Hi, Chris! I have a TRADFRI wireless dimmer, which isn’t working. Your binding only reports a “Switch” channel (and maybe a battery channel, I don’t remember, and have removed it from my config), which isn’t actually doing anything. Looking through the XML file of my installation, I find a cluster named “LEVEL_CONTROL”, which seems to read the values of the dimmer data. Any chance to have this implemented as a dimmer? What would you need from me? Full debug log, or simply the XML data?
I’m also seeing this with my Philips Hue Dimmer switch. There’re LEVEL_CONTROL clusters in the Hue XML node too. I’d be very grateful if you’d look at that too, if you decide to look into dimmer switches.
I have updated the logfile above. I have lost communication to the Philips Hue Dimmer Switch. Maybe this log can tell you whats going on. I cant tell when it happened, as I just discovered it.
The decive is zigbee:device:4beca465:001788011032a21b:
In this log the device does not respond to any requests, but it is alive as we are receiving announce messages periodically. These announce messages are normally sent when the device looses contact with the controller, and then re-establishes this contact.
I guess guess that maybe the link is not good and the bulb is not always able to receive the coordinator - but that’s a guess based solely on the fact that as best as I can tell we are sending data to the device and given it doesn’t respond, we can assume that it probably doesn’t receive these messages.
Have you set the dongle mode to boost and high power? These are reasonably new configuration options, but it might be worth a try.
First of all. It is the Philips Hue Dimmer Switch, a battery switch device. Not a bulb.
I believe it´s normal for such devices to go into some kind of “sleep mode” and then wake up when button is pushed. At least this is how I can see it works, when it works. It even gets a state of beeing “offline” after some minutes. And when it worked, I notice it changed to “online” and worked fine.
But it seems like after going offline/online a few days, it no longer goes online.
I tried moving the switch very close to the coordinator, just a few cm, (the Elabs Rpi Shield). But it doesnt change anything. The coordinator is set up using boost as well as high power.