I purchased 3 of the above “Mi Windows & Door Sensor” devices from Xaomi.
I managed to add it to Zigbee binding and it is discovered as LUMI lumi.sensor_magnet.
It is supposed to be a binary sensor with four channels according to Zigbee2MQTT but it is recognized as a Dimmer.
The Zigbee folder xml file is here: 00158D00042CCD1B.xml (27.9 KB)
This is a filtered log for the MAC address (00158D00042CCD1B) of the DEBUG log. MiJia.log (43.2 KB)
Anyone can help me to use this through my working Telegesis USB stick?
I’ve found this which refers to this. But both do not solve my issue.
The log says
2020-08-24 17:39:09.757 [ERROR] [converter.ZigBeeConverterSwitchLevel] - 00158D00042CCD1B: Error 0xffff setting client binding
probably it is still cannot get supported cluster list from converters (github issue 517). Just guessing…
This makes it totally unusable. Please don’t filter the logs as you will remove all the required data.
I’m not sure why this would be a dimmer, but looking at the xml it does report as supporting on/off and level control clusters - so that’s why it is reporting this way. It’s not supporting any of the normal reporting clusters I would expect from this sort of device.
You simply need to find somewhere to load it to - eg dropbox, or github - there are loads of file sharing systems on the web.
I have no idea what the problem is, so I can’t answer how to fix it… It does seem strange that it is supporting the clusters that it supports, so I’ve no idea how it’s implemented - it doesn’t sound standard.
I managed to separate all 3 zigbee logs to a separate but common file (quite tricky but I solved it).
The file is uploaded at Github.
I had to trip non ASCII data (direct Telegesis Frames) but the command is kept in place. Hope that is OK.
I have a few Philips HUE motion sensors not working right now. Discovering Zigbee devices shows these but disappears from the inbox (Things are online). I planned to reset these later.
Right now the lumi sensor is not recognized. I pressed the button and the zigbee discovery quitte a few times. Only the log showed the name but it not appeared on Paper UI. This might indicated that the discovery is not complete.
Sorry, but as above, I don’t know what the issue is. I don’t have this device to allow me to test and don’t have enough information about it.
This means there was an error sending a command to the device to configure the device to send reports. It is possibly caused by the device being asleep, or maybe the device doesn’t support the command. Without full logs it’s really difficult to provide much support - sorry.
Thank you @chris
I asked @cinadr as he open this thread and apparently I’m suffering the same issue. If he got this solved, probably he could help me too.
The point is: no “magnet” (On/Off) channels are created for that device. Only the dimmer one (which is useless in my case: I only want to know if the door is closed or open).
But I’m not sure where should I put that XML into OpenHAB GUI (or filesystem) just to try if in my case it helps.
So, in summary:
Can anyone point me out to the way to define custom channel for that device? Exists this page: Thing Descriptions | openHAB but I’m not able to figure out where should I put those XML information. I tried putting them into the “Code” tab into the GUI (at Thing section) but it doesn’t like so I assume that’s not the expected place.
You need logs to help here. Where can I get those logs as it seems the information provided at IP:9001 isn’t enough? I’m glad to provide any additional needed log.
The binding documentation provides information on how to configure logging for debug purposes.
The error that you refer to is not related to the issue on github, so I’m a bit confused. The error is normally provided when a channel is trying to be configured and the device is being bound. Clearly there are therefore channels being provided by this device (a level control channel is the one in the error).
It’s probably difficult for me to support this very much as I don’t have this device.
Yes, this is also true and causes some people a lot of problems with these devices. I think newer devices are better, and may even be certified, although they may or may not still work very well outside of their own ecosystem.
If that pull request will get merged, the MiJia Window & Door sensor will work for everyone.
In the meantime, if you have that sensor and you want to get it working, you could build the Zigbee binding by including the modifications that I made in that pull request, and put the binary in the addons directory of your Openhab installation.
It also needs to be enabled by running some commands in the Openhab console that I forgot, basically you need to disable the Zigbee binding that comes bundled with Openhab and enable yours.
I didn’t realise that this was ready for review - sorry. I thought that it was not working properly as teh last message you posted talks about errors and not receiving data.
Ops, sorry @chris , I should have been more clear that it’s working
With the changes currently committed in that PR, the sensor appears as a switch, and does work fine. The switch gets correctly set on and off when you close and open the contact.
What I was trying to do, and that’s not working, is to create a trigger channel as you suggested.
I think you can merge the PR as it is now. Then if somebody manages to make a trigger channel works, that would be a nice improvement. But in the meantime we will at least have the sensor working appearing as a switch.
Ok, thanks for the clarification and sorry for the misunderstanding. I’ll take a look at the PR again, but I think it’s quite simple (mainly just the XML IIRC) so I’ll hopefully get that merged.
I was waiting for some time for the pull request to be merged but I gave up and switched over to Zigbee2MQTT and it is working quite well with OpenHAB, both with version 2 and 3. I have 21 of that devices over my house all working as expected. Pretty hard to get into the network (follow the device description on their page) but after that all working for 3-4 month now (I deployed them between august and october).
@mattibal: Yes, issue is exactly the same you described in both cases. I understand what you are suggesting to me to do but I have zero skills on these topics so I’ll try to learn…
Seen the PR was no merged due a communication problem I guess it will be a chance to get it working sooner than later.
Anyway, @chris: I’ve followed your recommendation and added more information into logs so please find attached what I get: MCCGQ01LM.txt (48.3 KB)
I can see statements like these:
2021-01-07 10:37:51.022 [DEBUG] [er.ZigBeeChannelConverterFactoryImpl] - 00158D00063312E4: Removing channel zigbee:switch_onoff in favor of zigbee:switch_level
2021-01-07 10:37:51.028 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00063312E4: Dynamically created 1 channels
@cinadr: Thank you. I need this working out in a short time due to an emergency so I’ve just moved to HASS. Sensor is working flawlessly even with their own zigbee integration so no need to Zigbee2MQTT.
Anyway, if they work anytime soon I’ll move the installation to OpenHAB (just a sensor and a siren for my parents so I can move back and forth with no pain )
)