Please provide the network XML file for your system (from the userdata/zigbee folder) and I will have a look.
Iāve put it here so you can get it, I canāt upload yet
https://drive.google.com/open?id=1wrY0BoXVNy44LiGUK7g1pvD-tncRZq0Z
Thanks. So this device uses a cluster that is not currently supported by the binding, or the libraries the binding uses. I have implemented this cluster in a development version of the library and will look to add support in the near(ish!) future.
Please open an issue to remind meā¦
btw - chris should I open an issue about my active power / total active power channel issue causing that channel to not work?
Yes, please feel free. I donāt really understand why it worked previously given nothing seems to have changed (other than now it doesnāt work! 
) but please collate the information on what cluster/attribute is supported by the device and I can take a look at it.
1 Like
Issue submitted. Thank you! Let me know if you need any further info/testing of a fix.
Hi @Longfield,
What Xiaomi Aqara sensors are you using?
- The weather sensor (square one) should join correcty (several reports around saying it gets disconnected after a while, but in my case it is stable).
- The motion sensor seems to work OK also
- The tempearture and humidity sensor (round one) has a xml file definition already in the binding, so it should be recognized.
But these devices are hard to join: they are ātoo sleepyā and they do not answer to discovery messages unless you keep them awake by pressing the button in the device every second till discovery finishes (in my case, even for several minutesā¦)
So these are a cheap option, but not the most āuser friendlyā one. This is the deviceās fault, anyway, not the bindingās, as they do not seem to be precisely 100% ZigBee compliant.
Pedro
Thanks @chris!
I have updated a week ago, and thus far it has improved my experience with the Elelabs Raspi shield greatly. I was experiencing devices dropping from the network over time, and never coming back. I helped myself with a cron job to restart OH.
With the new libraries, everything is stable. No drops in the last 8 days!
1 Like
For @chris as well.
Using Elelabs Zigbee shield here also.
I did have the same successfull experience as AFromD. Unfortunatly it didnt stay like that. The last coupple of days things has been very bad, eve the Philips Hue sensor, and the Osram plug doesnĀ“t respond. Everything is online, it says. But it does not respond anymore. I have been to busy to get back on this, and havnĀ“t done much to try fix it. Yesterday I tried remove the Trust sensor and add it again. It work for something like 5 minutes, then it stopped responding again.
I cant say if this is cause by a lot of rebooting and retstarting lately. I think it may have.
Please provide the logs and sniffer logs and I will take a look.
Thanks.
I will as soon as I get some time.
Can I suggest (if I havenāt already 
) that you keep the sniffer running. Otherwise, inevitably, you have problems and donāt have logs to allow the issue to be solved. Itās really frustrating when you keep reporting all these problems, but donāt provide the logs that may help me to solve them.
I know, and you did mention it
But since I updated openhab 2.3 to 2.4 I have had a hell getting things to work, specially around Grafana charts, which quite often crashed openhab every time I was rendering two charts.
As a try to finde the cause I had to remove a few things, that included the sniffer as well as the debug logging for Zigbee. (I had to somehow try minimize all kinds of unnecessary memory using).
Status is, I believe IĀ“ve got the fatal problem under controle now. ItĀ“s still not fixed, just controled but openhab (Java) no longer crash. The cause has been tracked to the Rpi 3B IĀ“m using is not suitable for the way IĀ“m using it and was pushing it way above its limits by rendering just a few Grafana charts.
Now IĀ“ve to get the sniffer and debug logging back on track, as well as other things IĀ“d stop. Then I can provide usefull zigbee informations again. Hopefully tomorrow.
1 Like
Thanks Chris, sounds like it is going to be more involved than Id hoped to help with. Iāve open this issue as requested
Thanks. Itās not super involved, but itās also not a 5 minute job as the cluster needs adding first. I will look at this over the coming couple of weeks, but I wouldnāt expect this for may 3 to 5 weeks I guess as Iām off on holiday next week.
Had some spare time this morning to get the debug and sniffer up running again.
Here is some debug log and sniffer loggingā¦
At time 11.34 I removed the Trust motion sensor and re-added it again. It got added fine. But I receive no respond from it.
Seems like my Philips Hue sensor, as well as Dimmer switch do trigger allright. IĀ“m not quite sure about the Osram plug. I have a feeling its defective. I cant hear any relay triggering anymore.
So problems seems to be Trust sensor only, right nowā¦
Sniffer and debug logs.rar.txt (594.1 KB)
PS sorry I had to include two debug logsā¦ But theyĀ“re beeing filled very fast. The logs should cover the re-adding of the Trust sensor, as well as some minutes after (aprox 20 minutes).
Can you explain what this means exactly? It gets added, and it gets configured? Or thereās never any response and itās not configured at all? Or itās added, configured, but no state updates? Or something else?
Another question - with the Trust, exactly what channels do you see?
It gets added (included) fine, I can see 4 channels. ItĀ“s goes ONLINE.
Atm I have all 4 channels linked, cause I feared that something may have gone wrong during inclusion and the channel for motion dectection was changed (or wrong). So to make sure at least something worked, I linked all channels.
These are the channels it has. None of them respond, or openhab does not receive the respond. (Hard for me to tell).
When it worked, it triggered the Motion Presense channel when there is a movement.
Motion Intrusion channel has not done anything for some time now.
It used to have a Battery Level channel, but after updating the binding and the lib itĀ“s gone, (as explained some days ago). This channel āseemā to have been exchanged with a Low Battery channel switch, which I doubt is working. (Not easy to test)
Tamper channel has never done anything. I dont believe there is a sensor for this.