I dont disagree on that.
What made me react was that you said they are working (as well as the doc´s tells). Then I got the impression that … hmm well, they are working 
But I guess they´re still the same impossible damns beasts to include which they used to be, at least to me.
They are working.
So now I am confused. Two answers before, you said there are problems. Now you say it is working.
We agreed, that there is a problem to keep the Aqara sensors awake.
I figured out, the following steps are pretty reliable to add the Aqara temperature/humidity/pressure sensor. Perhaps it’s helpful for the window/door sensors.
- Start Zigbee Discovery
- Reset the Aqara device by pressing the button until the led blinks.
- Press the button of the Aqara device every second.
- When it shows up in PaperUI, add the device
Most of the times the device isn’t discovered completely, so - Start Zigbee Discovery again
- Press the button of the Aqara device every second.
Now it should be discovered completely. If not (which isn’t the case often), start again.
I said these devices, in general, are difficult to use and get working properly. That goes for pretty much all systems that use them - including openHAB and including zigbee2mqtt, and SmartThings…
However, they do work and I don’t think there’s a lot that can be done to improve them in general. Maybe there are some specific issues with some devices that can be improved, but you are not reporting such specific issues, so we are talking generally.
Maybe I used the wrong term?
The square Aqara temperature/humidity/pressure devices are advertised in PaperUI as Generic ZigBee Device, while the round Mijia devices are advertised in PaperUI as Xiaomi Temperature and Humidity Sensor. So my suggestion was, that happens because of the static thing definition. (https://github.com/openhab/org.openhab.binding.zigbee/blob/master/org.openhab.binding.zigbee/src/main/resources/ESH-INF/thing/xiaomi/lumisensorht.xml)
So I was just surprised, that you wrote, for the Mijia temperature/humidity sensors have to be defined a thing definition.
I think we are talking about different things here…
-
pairing of a device
-
stable operation of a device
The pairing of zigbee devices in general is (for me) quite painful and Xiaomi sensors are even worse. This has indeed nothing to do with the binding.
But after successfully pairing a device it should be operating stable. That’s the case for my Xiaomi devices using zigbee2mqtt. I never tried the official openHAB zigbee binding, so I can’t say anything about that.
I’m not sure I understand what you’re getting at, but let me repeat the rational here…
Where possible, we do not define static thing types, so most devices will be listed as a generic zigbee device. This is perfectly normal and does not mean that the device is not supported.
If the device doesn’t report its services correctly, or uses some sort of non-standard clusters/attributes etc, then we need to define this in a static thing type since the binding cannot detect the services itself due to device issues.
Ok, but others can. Other people have tested these devices and they do work. There are still issues with them in that the do not fully respect the zigbee rejoin procedure, and don’t seem to work well if there are multiple hops in the network - this is not something the binding can do anything about though.
The binding documentation to say that these devices was not updated by me - it was added by people who are using these devices!
I totally understand. Maybe we just talk at cross-purposes.
My point was: There is a static thing definition for the Mijia temperature/humidity devices (at least I think so). And because of that, I was surprised, that you wrote, that for the Mijia temperature/humidity devices has to be defined a static thing definition.
This is what I have tried about a zillion times with my xiaomi door/window sensors. I have not been able to succeed.
Sorry - I deal with hundreds of devices and I don’t remember all the names. There are also different temperature/humidity devices out there I think…
Had problem with OpenHab 2.4, initailizing Agara square temperature and humidity sensor.
It was detected, but not initailized.
After reading a bit, upgraded to OpenHab 2.5M5 testing release.
After 5 minutes - sensor become online.
No changes, nothing. Update was done remotely, i’m not even at home.
Zigbee binding, Ember EM35x Coordinator (Bitron USB stick), virtual Ubuntu LTS hosted on WMVare 6,7…
2 Likes
I follow this topic very carefully and try to shorten it.
What Christoph wants to say and that’s my experience, the Zigbee2Mqtt solution is currently working very stably. For me, XIAOMI’s, Aqara’s, Osram’s, Müller Licht, etc. work very well. However, a piece of external software is required in addition to the USB stick and an MQTT server.
I also ask myself why OH leave this field to others and not implement it with an own binding, as the Openhab philosophy provides.
My last information was (v2.4) that a lot of the above Zigbee products don’t work. The reasons were discussed extensively here. What Christoph’s question was about, that others obviously managed to solve the known problems and obstacles. It should also be possible to operate the products without MQTT.
The aim should be, to be able to use as many Zigbee products as possible via the binding, in order to be able to optimally use the Openhab ecosystem.
I would always integrate reliable manufacturers such as Philips HUE, IKEA Tradfi, etc. via the gateway. I would not use a XIAOMI Bridge. I would like to use these products directly via a binding.
Disadvantage of products without a gateway:
If I integrated all HUE lights without a bridge, I would not be able to use updates. I cannot reset the lights without the bridge. So it has advantages and disadvantages.
Nevertheless, the OpenHab Zigbee Binding should be able to integrate Zigbee products, even if they do not meet the standard. Because obviously others can too.
This is of course the aim - I have to focus my efforts on the majority of course. You are also able to contribute if you want to help.
Why? Does Hue not provide their software updates other than through their own hub (that’s a shame).
In general this is true, but you need to be careful here - a ZigBee product is NOT a ZigBee product if it does not meet the standard. I try to support as many products as possible - however - if a device doesn’t support the standards, then it needs extra effort to support. Are you providing this support? I suspect not - what you are saying is that I should provide this support?
Agreed - it’s only a matter of time - nothing else. If you want to contribute to help support these devices, then please do so.
You’re quite right. The main problem is the time we all don’t have much of. So, great respect for your work. Everyone looks over your shoulder and knows everything better 
It was an appeal to all to support the Openhab phylosophy. Many would support you if they knew how. I am a network guy, not a programmer. I can read and analyze data packets and protocols, but I can’t write software.
One person alone cannot buy all products, but many other users have many other products. If you could just tell us how we could provide you with input, I’m sure many would agree.
I am also sure that many problems arise from the combination of different hard-/software. That is why I would like to have an overview under which hard-/software has been tested and under which problems arise. Where I can help I would help.
There is a section in the binding doc called something like “what to do when things don’t go right”. This provides information on low to configure logs which can provide information - sometimes. The problem is that with ZigBee, if a device doesn’t join, then there will be nothing in the log and a sniffer log is required and this requires more hardware. I am in the process of putting together a dongle that provides all this in one to try and make this easier.
Sometimes it’s just better and easier if I buy devices - although it’s more expensive for me (I’ve spent around £100 this week alone on devices to support others).
We try to capture this in the binding doc - this tries to provide an overview of devices people have tested but there are a lot of possibilities.
For dongles, most of the testing gets done with an Ember dongle, and most commercial users are using Ember dongles, so this is always my recommendation.
Hi all, thanks for great work on zigbee binding, I have working some temp aqara sensors.
Do you have anybody working magic cube switch? Should I buy it? Thanks
Hi @all
I’m trying to use the aqara door sensor in Openhab via Conbee Stick and Phoscon. I got the sensor online in phoscon and online in openhab, but in openhab the status never changes when I open the window. It just stays “CLOSED”. In Phoscon the sensor got the right status “OPEN”. Anybody know what to do? Thanks a lot