[OH3] MQTT Homeassistant discovered Aquara Window Contact not working


First of all thanks for incredibly helpful postings in this community, they really helped me getting started with OH3 when I decided to start from scratch after quite some years running FHEM.

I have a working dockerized system running OH3, Mosquitto and zigbee2mqtt. Zigbee2mqtt is setup in a “conservative” way, i.e. with the homeassistant feature for auto-discovery enabled and the output being json-format. I’m well aware of the Zigbee2mqtt revisited post from late 2019,

but decided to go with auto-discovery for now to avoid the pitfalls of a noob editing config files.

As a first test for Zigbee devices, I decided to integrate an Aquara Window/Door contact sensor (MCCGQ11LM) into the system and gave it a nicer name (aq_fenster_1) on the zigbee2mqtt side. It works flawlessly on the zigbee and mqtt side, I get both the regular mqtt messages when opening/closing the contact

aq_fenster_1 = {"battery":100,"contact":false,"linkquality":0,"voltage":3055}
aq_fenster_1 = {"battery":100,"contact":true,"linkquality":0,"voltage":3055}

as well as the homeassistant config message (example for the contact channel):

  "availability": [
      "topic": "zb2mqtt/bridge/state"
  "device": {
    "identifiers": [
    "manufacturer": "Xiaomi",
    "model": "Aqara door & window contact sensor (MCCGQ11LM)",
    "name": "aq_fenster_1",
    "sw_version": "Zigbee2MQTT 1.17.0"
  "device_class": "door",
  "json_attributes_topic": "zb2mqtt/aq_fenster_1",
  "name": "aq_fenster_1_contact",
  "payload_off": true,
  "payload_on": false,
  "state_topic": "zb2mqtt/aq_fenster_1",
  "unique_id": "0x00158d0005225ede_contact_zb2mqtt",
  "value_template": "{{ value_json.contact }}"

The trouble starts when I save the automagically discovered thing and try to link the channel contact to an item / add it as an equipement/point to my model. The least annoying issue is that the thing’s status is “Unknown”, despite the homeassistant config setting the “availability” channel correctly (see above: "topic": "zb2mqtt/bridge/state").

More importabtly, none of the channels show any data or changes in state. I tried JS and JSONPath transformations as suggested in some older posts, but that didn’t work. It seems like the auto-discovered thing doesn’t get the mqtt messages it should, given that the state_topic is set correctly in the config message (see above: "state_topic": "zb2mqtt/aq_fenster_1").

I verified that OH3 and the JSONPath transformation work for the messages sent for this device by creating a Generic MQTT thing that listens to the contact sensor’s messages:

UID: mqtt:topic:a0cfdd024e:8a543aff65
label: FL_WindowContact1
thingTypeUID: mqtt:topic
  availabilityTopic: zb2mqtt/bridge/state
  payloadAvailable: online
bridgeUID: mqtt:broker:a0cfdd024e
  - id: FL_Fenster1_Contact
    channelTypeUID: mqtt:contact
    label: Contact
    description: ""
      stateTopic: zb2mqtt/aq_fenster_1
      transformationPattern: JSONPATH:$.contact
      off: "true"
      on: "false"

I get a nice open/closed status reading that updates in real time. Loooong story short, is there anything or any steps I’m missing with regard to the homeassistant auto-discovered thing? Or does that binding just not (yet) work with this device, despite the configuration data looking OK?

Thank you in advance for your help or any hints you may be able to give me!

I have nothing helpful to add other than to check: make sure you also have the JINJA Transformation Service installed!

Thank you for the quick reply!

I did not have that transformation installed, and it solved some of the problems, namely the “unknown”-status (now switches to online when the contact is opened/closed) plus the battery and link quality readings.

The actual contact status, however, still remains at “NULL”. I added {{ value_json.contact }} as a JINJA-Template to the channel transformation (which is also the “value_template” advertised in the homeassistant config message, but the item/point still does not show the correct values…

Now that you have the jinja installed remove any things and start from scratch setting them up, seems to make a difference if they were created without that installled.

There is a GitHub issue / PR in limbo on this at the moment.

Same result, unfortunately. Battery/link quality work fine, contact stays NULL. It sounds a bit like the issue described in the post you linked in your PR

where a state change didn’t get propagated to OH3. I’ll reboot the box and try with a fresh container later tonight/tomorrow and will keep this thread updated…

…and thanks to the magic of containers, I was able to test a fresh install (stable + snapshot) fairly easily but the results stayed the same.

I am using the same sensor with zigbee2mqtt and autodiscovery.

I think you have to clear the channel-transformation, because value_json.contact expects OPEN/CLOSE as values and the sensor is reporting ON/OFF instead.

Thanks! I somehow had the Item Type set to contact instead of switch, and while I had tried to set the channel-transformation to (No Profile), it reverted back to JINJA/JSONPath upon saving.

Once I set it to Standard, it now shows ON/OFF in real time. No luck converting those values to the more appropriate OPEN/CLOSED via a simple map file, but hey, for logic purposes it should work.

Thank you all for your help on this!

Yes I tried to map it, and failed, too.
As far as I know mapping is on the roadmap to include into the UI.

I’ve been trying to use the MQTT HomeAssistant Discovery too, with disappointing results.

I guess in this instance my question is why is the contact property recognised as a SwitchItem rather than a ContactItem.

I guess in this instance my question is why is the contact property recognised as a SwitchItem rather than a ContactItem .

The delivered values from zigbee2mqtt are ON/OFF like a SwitchItem and not OPEN/CLOSE like it should be for a ContactItem. Maybe it depends on your Zigbee-Gateway how this values are sent.

Before my switch to zigbee2mqtt I used the Xiaomi Gateway and the corresponding binding, and there the Items were correct interpreted as ContactItem with OPEN/CLOSE states.

The only thing OpenHAB can do better at this place, is to allow other mappings with the delivered values. This is maybe already possible, but has still to be done in text-files. (GUI for that is on the roadmap, AFAIK)

@danielwalters86 Which zigbee-solution do you use?

@Christian_Brosius I use zigbee2mqtt as well, primarily because I have a lot of Aqara/Xiaomi sensors that don’t work well with the OH Zigbee binding.

This is in fact incorrect, the values returned from zigbee2mqtt for a contact sensor are true or false, which OH is interpreting as ON or OFF, presumably due to the fact the HA Discovery maps binary_sensor to a SwitchItem.

I have also noticed other issues when the HA Discovery tries to create an OH thing for my white tunable bulbs too.