Aqara Door Sensor Values

[mulu]

I finally got some Aqara door sensors added. However, I see some strange behavior. One of the sensors reports the contact status as "false" or "not false". However, 3 others report the status as "not false" or "" (empty string). All of that info comes by looking at the device properties in HS. It turns out 3 of them show an empty string because when there is a contact then the value of the HS feature is set to 2 rather than 1. Looking at the association table I see that the payload changes between "true" and "false" as expected. One interesting thing is that there are actually two payloads that change simultaneously for just one sensor. See below. When I connect/disconnect ONE sensor there are two payloads coming in. I have a feeling it adds the two so 0+0=0 and 1+1=2. But why would it do that? Note that in HS I have renamed the devices to "Door" and I changed the name of the features to just "Contact", "Temperature", etc and the floor and door to the appropriate values I am using. Hence, I removed that long hex number. I am not sure if it has something to do with that but then why would it work correctly for one of the sensors but not for the others?

[Michael McSharry]

In general looking at MQTT Statistics is not very useful. You want to look at the Zigbee2MQTT topics.

Click on the associated HS device for your sensor true/false status. 2/3 way down is the VSP table. If you hover over the text box it will give you syntax for editing. What you should have there are two rows. The first false with value of 0 and the second true with value of 1. Whatever you put on the Edit tab will be reflected in the HS device.

[mulu]

I included the MQTT just to check the actual "raw data" that is coming in. Both sensors, the one that doesn't have an empty string and the one that does show exactly the same behavior in MQTT statistics and Zigbee2MQTT topics. However, your suggestion looking at the VSP revealed something interesting. They have different mappings. See the screenshot below. I am not sure why and how that happened. I didn't modify anything and these are the same sensor types coming from the same batch (at least I assume so as I bought 6 at the same time). I can fix it by just adding a status 2 in HS but I still wonder where this different behavior is coming from. The one with the 3 states kind of makes sense, i.e. 0 = not closed, 1 = unknown state, 2 = closed. Maybe I just need to somehow exclude the one that only has the 0/1 states and then add it again.

[Michael McSharry]

The plugin creates the "not xxx" entry when it does not find one of the expected pairs. It should have returned true for false and it is not clear to me why it did not. I will look into it.

What you should is edit on mcsMQTT edit tab. Use the Clear Existing VSP button. Enter into Add/Edit text box "off,on" without the quotes. This will produce the desired mappings and HS will be automatically updated.

[mulu]

Ok, I did that but then I ended up with the screenshot below. So I redid this but instead of using off,on I used true,false. Now it seems to work. Thanks for the input. Much appreciated.

[Michael McSharry]

Glad you caught my mistake of on/off vs. true/false.

[ksum]

Just an FYI: I picked up one of the Aqara Door/Window sensors and it seems to send true/false for the contact value. The device created had Status values of 0 and 1, but true has this being set to 2. I have not seen a "not false" value in my MQTT Snooper program, but perhaps that was an initial one when the sensor was first connected to zigbee2MQTT. I simply made a Status setting for 2 for this device, so I am good. But wanted to make sure you are aware of this, Michael McSharry in case you are expecting something different.

MQTT version 5.26.5.4
Mosquitto broker so no compelling need to upgrade to v6. Will, do so soon though.

[ksum]

PS: Here is the message payload being sent out of zigbee2MQTT. Hopefully the battery level comes through at some point.

{"battery":null,"contact":false,"device_temperature":null,"l inkquality":15,"power_outage_count":null,"voltage":null}

[Michael McSharry]

Thank You for the feedback.

I looked at the code and see I had provisions for True/False, TRUE/FALSE, but not true/false. This is why "not false" was a state. Had mcsMQTT observed both "true" and "false" before the association was made then all would have been OK. I updated the code to include true/false and an expected state pair.

The "not xxx" state is not a real state, but a placeholder. What I would do in this situation is clear the VSP definitions in mcsMQTT Edit tab then add in the "false=0;false;false" and "true=1;true;true" as new VSP entries. If you want HS to show "On" rather than "true" then it would be "true=1;On;On"

[ksum]

Thank You for the feedback.

I looked at the code and see I had provisions for True/False, TRUE/FALSE, but not true/false. This is why "not false" was a state. Had mcsMQTT observed both "true" and "false" before the association was made then all would have been OK. I updated the code to include true/false and an expected state pair.

The "not xxx" state is not a real state, but a placeholder. What I would do in this situation is clear the VSP definitions in mcsMQTT Edit tab then add in the "false=0;false;false" and "true=1;true;true" as new VSP entries. If you want HS to show "On" rather than "true" then it would be "true=1;On;On"

Ah. I feel for you on that one. That is why I started forcing all my string checks to use all caps.