Zigbee binding

Tags: #<Tag:0x00007f01479ee748> #<Tag:0x00007f01479ee608>

(Kim Andersen) #1787

I know. But…
The device report two channels which it isn´t using (or they´re not working… How am I suppose to tell the difference). And the battery level channel seems to be missing…

I would assume a device reports the same channels each time, and not depending on the binding. Thats why i asked!

(Chris Jackson) #1788

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 :slight_smile: .

(Andrew Rowe) #1789

good point

(Chris Jackson) #1790

And how am I supposed to tell the difference?

(Kim Andersen) #1791

I dont know… Thats why I asked!

(Chris Jackson) #1792

Sorry - I’m not sure what you’re asking then? :confused:

(Andrew Rowe) #1793

Sorry but this is more then a little amusing :rofl:

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

(Chris Jackson) #1794

Sure - I appreciate that.

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.

(Kim Andersen) #1795

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…

(Kim Andersen) #1796

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).

This is why I asked in the first place.

(Chris Jackson) #1797

I have explained this above.

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.

(Kim Andersen) #1798

Ahh… So this can even change for the same device, each time the binding restarts?
Now it makes sense. Sorry i didnt get that before.

(Chris Jackson) #1799

Yes - that’s what I said when you asked this an hour ago :slight_smile:

(Kim Andersen) #1800

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.

(Jared Frank) #1801

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 :laughing: ) 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 :smiley: )

(Chris Jackson) #1802

Thanks for the gift of a fast loading log :slight_smile:

Can you tell me when to look in the log, and what nodes to look at?

If I pick one ON command -:

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.

(Jared Frank) #1803

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 :sweat_smile: ) 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 :wink: :wink: :stuck_out_tongue:

(Valentin Longchamp) #1804

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 ?

(Chris Jackson) #1805

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.

(Jaakko Rautanen) #1806

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?