Ok - this is totally unrelated so will make no difference at all.
Okay… Whats the option for then?
Btw… did you see my screenshots of the properties?
It updates the mesh information in the properties - it doesn’t actually update routing as that is done on the fly.
Yes, but as I said, in your case I don’t think it’s going to be very useful as you are moving things around.
It looks the same for the Orsram plug socket, even when I dont move it.
The Hue bulb I just added does seem to have an route info though.
I use this binding with linux, xbee-stick and ubisys devices for months now without any problem: thanks very, very much chris!!! (are you still thinking about integrating an update mechanism for the firmware of the devices?)
I would like to add vibration sensors for doors and windows. Following the informations given on the binding page the smartthings sensor offers that detection but only in the version of 2015. The 2018 version doesn’t show a “vibration” channel.
Does anyone have experience with vibration sensors, perhaps even combined with contact sensors?
The binding already supports OTA upgrades - I added this about 18 months ago (although I did get a report recently that it’s not working on some devices due to a timeout with the final handshake).
What isn’t available is a firmware provider - this is something that was planned for ESH, but there is no public implementation available. Without this, it doesn’t work.
Hi chris,
just came back home from work and you already answered - really great “service”
Hi @chris
I´m not sure if anyone actually have reported this.
Today I bought an Aqara door/window sensor just to test. To my understanding Aqara things are Xiaomi 2.edition zigbee stuff… I have given up trying to get the 1. edition door/window sensor to work. It can add, but it doesnt change state.
Anyway, the Aqara sensor added just fine. But it only apply a switch channel. It does seem to work fine though.
Unfortunaly this sensor report state is ON and OFF , which doesnt really make any sense, for a door/window sensor, which in my opinion should be a contact and state OPEN/CLOSED.
Second, its state is OFF when the magnet is put together, and ON when it´s apart. This is strange as well, I think. But again, ON/OFF is strange in itself.
Third, there is no kind of battery channel what so ever… This is not good at all. A door/window battery sensor without a battery channel/report just isn´t a great idea, specially if it´s used for security/alarm.
I wonder if this is due to the binding not fully support the device?
The sensor reports contact, battery, voltage and link quality. I am using two of the Aqara door/window sensors with zigbee2mqtt. Currently this seems to be the best solution for openHAB users that want to connect their Xiaomi stuff.
What does that mean exactly? I’m not sure that any Xiaomi devices are actually ZigBee compliant, but I might be wrong. I don’t know what “2.edition zigbee” means though?
Then you should use transformations to change this - it’s not something that can easily be done in the binding - if the device reports as a switch rather than a door sensor, then that’s how the binding will present it. I don’t think it’s that hard to manage this?
I don’t know what the device supports, so it’s hard for me to comment on this. Again, the binding checks for known functions to report battery - if the device supports them, then battery will be displayed - if it doesn’t support it, then it wont. If the device is using a non-standard feature, then it probably won’t work.
Hmm, thats odd. I tried add it three times, all three times discovery went fine, however only a switch channel is recognized…
As said, It´s my understanding. It may be wrong. But Xiaomi have the Mi series (which doesnt work with a zigbee coordinator) and then Xiaomi has the Aqara series. The physical look is slightly different for the two door/window devices.
This is the Mi sensor:
And this is the Aqara sensor:
According to rumors and others, Aqara series devices are known to be “more” zigbee compliant.
Of couse if thats what the sensor reports, then thats how it´s suppose to be, and should be fixed by transformation… But my concern is/was wether the report is wrong. As you can see from Manuel above, his sensor report a contact and even battery voltage and link quality… I guess this means something went wrong during the discovery anyway or??
I know you cant comment on devices you dont know, and I dont expect you to either. But according to Manuel above, this device support contact, battery voltage and link quality… I´m not quite sure if there is any differences between zigbee2mqtt and “ordinary” zigbee… I thought it was the same. Maybe thats the issue here?
Ah yes, the well know “more zigbee compliant” level of compliance to the standards 
. I know that they are using some parts of ZigBee, but what does that mean? We also know that there are non-compliances - again - it doesn’t really help. Unless devices stick to the standards, don’t expect them to work fully in a ZigBee environment.
We know that these devices don’t work well in a mesh system - this has been documented in many places. Maybe they have or will improve this, but please don’t think that “more zigbee complaint” means anything. It’s like telling the police that speeding at 20km over the speed limit is “more legal” than speeding at 30km over the speed limit - it’s still not compliant with the law.
zigbee2mqtt uses parts from zigbee-shepherd (an open-source ZigBee gateway) to translate from manufacturer-specific zigbee to something “common”. This is what some other zigbee implementations (for example in ioBroker) do as well.
In order to do this sort of “translation” - it requires someone who has the device, and I personally don’t.
This was not meant as criticism. I just wanted to explain why some non-standard devices are working with zigbee2mqtt.
Sure and some are also working with the binding. This isn’t necessarily difficult - my point is simply that if devices don’t follow the standard, then they won’t work out of the box and more work is required.
I dont… thats why I tested the device, and came up with the results while asking if its a binding issue.
As far as I understand, its impossible to know. One just have to take a chance and test the device, (which is what I did). And since it was disovered allright and added, though it seem to lack a few channels, I had to ask.
But how can I answer this question - you’ve not provided any real information, so it’s really hard to make any real comment - sorry. All I can do is buy the device for testing - my main focus is on devices that support the standard - other devices will always need more work - it’s just a fact of life I’m afraid.
There isnt any “real” information. So I had to test the device, notice the outcome, and then ask. I dont expect you to answer something you dont know. But how am I suppose to know what you know, other than asking?
Anyway, I believe I got an answer. This device probably dont follow the standard either, which probably is the reason for the outcome. Next case!
There should be more information - logs, sniffer logs, network XML files. Just the usual things I normally ask for 