This is probably not the device - it’s probably the binding. The binding adds a temporary thing initially to indicate that a new device has been found - it may then update that later once it knows the device information. This used to work ok, and it might still work ok, but in the past few weeks ESH removed some of the functionality that bindings use to do this, so it’s also possible it’s not working as well any more.
I seem to recall we looked at this in the past, and it did not work with all devices (or it didn’t work with mine at least). If I remember correctly, my device didn’t support this attribute.
@chris
What determines which channels a device supports?
I use to have a batterylevel for the Trust motion sensor. But now it´s a switch for Battery Alarm, and it seems to work in opposite way, when the switch is ON, the value is OFF.
the binding looks for the services that the device reports - if these requests don’t get a response, then the binding doesn’t know the service exists. Maybe sometimes the device responds, and other times it doesn’t - this results in different services being reported.
A new channel was recently added for the battery alarm - we didn’t remove the old channels so these can still be available.
I was just wondering how to get the batterylevel channel back… Also the Tampering channel as well as the Motion Intrusion doesn´t really make sense cause they dont seem to work. So I wonder how/why they appear.
I have not removed and re-added the sensor, after I updated the binding the other day. I dont know if this is needed. But the binding has been restartet quite a few times since, (due to other issues I have on my system atm).
I believe its been stated a number of times that the binding simple adds the channels the device itself reports and that some of them might not work. Not sure if its something that can be easily changed in the bindings so my method has been to ignore them and also don’t link any items to them
The only way to change this is to add static definitions for every device. This isn’t something I want to do unless it’s really necessary as it’s quite a bind to have to maintain these every time anything changes - especially as the number grows (in ZWave for instance, we have around 850 devices and I had to write a large management system to maintain that, and it still takes me hours every week to look after!).
Sorry Chris, I almost added a note in my post that it probably wasn’t necessary and does not seem to me to be necessary. I was actually trying to save you the trouble of having to reply to yet another post asking why there are channels that don’t seem to do anything because thru 1779 posts and counting, you have worked so hard to support your binding.
Again… Thank you so much for you hard and tireless work
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!
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).
.
