Thanks - I didn’t mean to sound negative either… I’ve tried to write the ZigBee binding so that it is able to detect the channels itself. It’s what the ZWave binding should do, but when I wrote the OH2 ZWave binding, ESH didn’t support that feature. When I find time, I might have to rewrite it…
If we need to add static definitions to get features that aren’t otherwise available, then we can do that. What I want to avoid is doing this for every device and then making a maintenance nightmare. I appreciate that you appreciate that .
Kim, I believe what Chris is saying is that there is no easy way to tell if the binding is reporting channels that the device is not going to utilize.
Further, it makes sense that manufacturers may use one firmware for multiple devices and have support built into the firmware for channels a particular device may not use.
Chris, I believe Kim might be frustrated by trying to tell which channels should be working from those that are unused. I believe Kim may be trying to make a statement rather than to elicit information
The bottom line is that I try to interpret what the device reports that it supports, and provide the appropriate channels based on this. Above and beyond that, short of me buying the device to try and work stuff out myself (which I do quite a lot anyway) there’s not much more I can do.
You say the channels are determined from the device, right? I understand that.
What I fail to understand is, if this is correct (the device report the channels), then where did the batterylevel go? I didn´t change device. I changed (updated) the binding…
Not exactly.
I´m trying to figure why channels changes for the very same device, when I change the binding, based on, Chris say, the device reports the channels.
I´m used to channels beeing reported but not working. But I´m not used to channels changing because of the binding, (except for z-wave devices, but thats when the database changes as far as I know).
When the binding starts, it inspects the device to find out what services it supports. Based on what it sees, it creates the channels. If some of these “inspections” fail, let’s say because the device is a battery device and isn’t listening, then it may not detect all services. This will mean you don’t see all possible channels that are really available.
You did… I just didnt realise… Probably because I have restarted the binding about a zillion of times (due to other problems), and have not seen the BatteryLevel channel since using the old 2.4 binding with 1.1.2 lib.
Insted I get this BatteryAlarm switch channel each time.
Hi Chris - I’ve noticed over time that (i believe restricted to my two newer bulbs that used to detect CT in reverse… or perhaps just ahead of their time as its now the way it goes ) my bulbs dont respond to the ‘ON’ command properly. I’ve observed that an ON command does absolutely nothing … then if you send an off command the bulb will flash on and then go off. This can be avoided by sending a dimmer percentage to the bulb (as long as it isn’t 100. That too seems to do nothing). Once any non zero, non 100 number is sent I can then send the bulb to 100 no problem. I’ve attached an excerpt of the logs that show this. Hopefully this can help you find something. Thank you and happy new year!
(my gift to you is a log file thats less than 2 mb )
This looks fine. The report that is received shows that the bulb is on (in theory!) - attribute 0 in cluster 6 is the OnOff state, and it is true.
All the other such events, either OnOff, or Level commands all look fine. The commands are being sent ok (apparently on time) and I can see reports coming back to say that they are On.
If you can provide a specific time and bulb when you actually observe this, I can look more closely at that specific event.
The only thing I will say though is that the log shows the times the commands get queued, not when they are sent, so if there is queuing for any reason, then there could be a short delay. If I look at the log above, clearly that didn’t happen though as the response from the bulb is close to the time of the command, so it was obviously sent quickly, but some other commands that’s not the case. I can see 1 or two commands where there may be a short delay of 1 or 2 seconds - it’s hard to be sure without a sniffer though. In any case, the commands seem to be sent ok.
The Bulb in question is F0D1B800000228D1 - the raw logs have some extra script logging that shows when the commands were sent as well but yeah - I was wondering if any of the log actually showed anything useful. From the looks of your screenshots you just load our logs in wireshare right? Or is there something else? I’ve got a sniffer board on the way (wish me luck that I can get it working when it does come ) I’ll try to do some extra research on my end to see if I can get more info to you. Don’t want to distract you from that QOS / packet queuing update you are working on
Is it somehow possible to “force” the channels for a given device ?
I have 4 new Xiaomi Aqara Sensors. They are discovered by my system but somehow with my current setup I cannot get them to “enumerate” their channels (I always get a timeout for both the NodeDescriptorRequest as well as the ManagementLqiRequest). I have another sensor that I had discovered earlier on my setup and for this one the “channel enumeration” was successful. I have the impression that this is more a leftover from a previous configuration and the enumeration did not really take place and the information was already available.
My question is then: Where do I get this information and how do I “copy it over” to the newly discovered devices ?
Not really - at least not from the user. It is possible to create a static definition file and add that to the binding - there are already some included for Xiaomi devices, but this does require you to update the binding itself.
Hi there! I bought couple of Ikea Tradfi Motion sensors today. I hope I read this tread before buying. Based on the tread Tradfi motion sensors are not working with Zigbee binding at the moment, right? I understand this is due to their non standard behaviour.
Are there any plans to get support for them somehow?
Hello, I have a zigbee fan controller from Hampton Bay (King of Fans) and the light successfully shows up as a level control channel (although doesn’t seem to update openhab when controlled from the remote, but that’s for another day). However the fan control doesn’t show up. I turned on debug and can see that discovery shows FAN_CONTROL in the inputClusterList but channel doesn’t show up, nor do debug/trace when the fan turns on/off.
I did a little digging and it looks like this cluster isn’t included in the binding, is this why the fan events for the cluster aren’t logged ? If this is the case, is there any documentation/guidance on how to add a cluster to the binding that I could follow to implement it ? From what I could tell from the smart things implementation of this device, it does use the expected cluster value and attribute range from the spec, even if it bends the way it uses the attribute values as it has four instead of three speed settings
.
) my bulbs dont respond to the ‘ON’ command properly. I’ve observed that an ON command does absolutely nothing … then if you send an off command the bulb will flash on and then go off. This can be avoided by sending a dimmer percentage to the bulb (as long as it isn’t 100. That too seems to do nothing). Once any non zero, non 100 number is sent I can then send the bulb to 100 no problem. I’ve attached an excerpt of the logs that show this. Hopefully this can help you find something. Thank you and happy new year!
)
) I’ll try to do some extra research on my end to see if I can get more info to you. Don’t want to distract you from that QOS / packet queuing update you are working on 
