Aqara E1 Zigbee Door/Window Sensor is discovered, online, and otherwise not working

  • Platform information:
    • openHAB version: 3.2M4

I ordered this sensor from
AFAIK, it is Zigbee 3.0 compliant.

I intended to use this with my OH3 zigbee stick.

Discovery worked on the first try, OH Thing goes online. I link all the channels to items.

Thereafter it does not report anything, no events or status.

In my previous house I had a Xiaomi hub that I had setup with OH. I had several Mejia and Aqara Door Sensors and everything was working fine.

Anything I can check in Zigbee logs that might tell me something useful?

Any advise about firing up my Xiaomi hub and adding it to my new house OH3?

I just received this Aqara sensor from Amazon
Looks the same but is not the same
Discovers with just one Switch channel

Unfortunately same problems.
Discovers, goes online, but nothing else happens

Maybe I should just abandon using Aqara sensors and go with Shelly

I run a ton of aqara sensors (motion, window/door, temp etc.) and all work just fine with OH.
My setup goes through zigbee2mqtt and then into the mqtt binding in OH though.

Do you have any log entries? Maybe if you look into the debug log?
Also, your configurations (thing, channels, items) would be good to see.

The Aquara sensors are generally not zigbee compliant and work a little differently. Many hubs have issues with them, and they need to be kept awake for a few seconds (or more) when they are being discovered and configured. I think there are some references about this in the binding docs.

They do work though and many people here are using them, but they just can be a bit more touchy to get working initially.

I heard that too, whereas I never had issues with aqara sensors (or any other Xiaomi sensors for that matter besides the below).
They always connected in a matter of ms to my z2mqtt USB stick.
I had though issues with the Xiaomi smoke detector which required another Xiaomi device (which is active, i.e. power plug) as “bridge” to connect the first time.
But again, slightly different setup.

ok… I tried re-adding the sensors
The sensor from Amazon is now working
The sensor from Banggood is online but not working

They look identical but they are not.

The Amazon sensor (No model) has only one Switch channel.

00158D0007BDDB5E.xml (21.9 KB)

The Banggood sensor (Model E1) has 4 different channels

54EF44100027DA39.xml (47.4 KB)

The Amazon sensor apparently does not report battery status

An update
I attached the Amazon sensor to a closet door.
The Thing eventually reported offline
I opened and closed the door and my rule fired
The Thing reported as online

Aqara sensors are goofy

Sounds more like something is not working out either with your setup or the binding, or they are faulty sensors.
I got multiple sensors running (MCCGQ01LM and MCCGQ11LM) and they show up just fine in z2mqtt as coordinator as well as then in OH:

Your sensor sounds more like it is the Aqara T1 MCCGQ12LM which only gives contact/battery/voltage/link quality though.

Maybe that one is not yet supported fully by the OH zigbee binding?

The Amazon Aqara sensor model number is MCCGQ11LM
The Banggood Aqara sensor model number is MCCGQ14LM

@chris , any thoughts on why I only get a single Switch channel and @chrismast coordinator has a Status(Contact) channel as well as a Battery channel and others?

@chrismast unfortunately my zigbee stick the HUSBZB-1 Ember chip is “experimental” in the Zigbee2MQTT project

Not really. I don’t know these devices, and it seems that there are a few different ones. The binding will try to detect what the device supports - this normally works well for zigbee devices that follow the standards, but these cheap Chinese devices don’t.

We can create a manual thing definition that can fix some issues with non-standard devices, and this is done quite a lot for these devices, but not this one at the moment.

The Zigbee binding will never add channels to the coordinator. @chrismast is using mgtt so they presumably manage channels differently, but conceptually adding channels to the coordinator doesn’t make any sense.

Likewise some channels I see above like link quality are not added as channels by the binding - they are properties - different bindings will simply do different things.

Again though I simply don’t know what this device does and probably they are not following the standards when reporting the door sensor state so the binding can’t detect this channel (that’s my guess anyway).

Yes you are correct, I do use MQTT via zigbee2mqtt.
The above channels though are all auto-discovered in zigbee2mqtt, in MQTT (OH) I only connect to those then as with any other device. This works across the range of my zigbee devices (IKEA, Xiaomi, Tuya, self-designed ESP etc.).
You might be able to understand the config etc. by looking at the z2mqtt db files though as it allows to connect to any zigbee devices (even if not officially supported); it should have an entry for the xiaomi once already which might point to why its not working as well with the OH zigbee binding?

@chris I’m looking at augmenting the discovered zigbee Thing with a “closetDoor.things” file to expose the properties mentioned in Xiaomi MCCGQ11LM control via MQTT | Zigbee2MQTT
I am inspecting the zigbee xml file 00158D0007BDDB5E.xml (22.2 KB) and was wondering if there is any guidance you might be able to direct me too?
I see:


Thank you for any guidance

To be honest, I’m not really sure. From the XML, this device doesn’t seem to support many standard functions. My guess is that everything is covered through their own implementation rather than the zigbee standard.

I know there are some (maybe all) Xiaomi devices that support a non-standard reporting frame, and probably that is what is required here, but at the moment that is not implemented in the zigbee binding.

I just hate paying 25 to 50 bucks for a stupid reed switch. I guess I just have to swallow hard and accept that unless I build my own sensors, I need to pay for standard sensors. Thanks for trying to educate me.

1 Like