Xiaomi door sensors are added to 'lights'

[fi-sch]

Describe the bug

Newly added Xiaomi door sensors are being added additionally as a light in Phoscon. In Home Assistant I can see additional 'light' entity which is being controlled (turned off/on) by sensor itself.

Steps to reproduce the behavior

1. Go to Phoscon -> Sensors
2. Add new sensor –> Others
3. Pair Xiaomi Mija door sensor
4. Push pair button once more
5. "Open" and "close" the sensor.
6. Go to the Phoscon –> Lights

Expected behavior

Sensors shouldn't be added to Lights group, just Sensors. No additional entity should be added in Home Assistant

Screenshots

Environment

• Host system: Intel NUC8 i3
• Running method: Proxmox + HassOS + Home Assistent deCONZ Add-on
• Firmware version: 26580700
• deCONZ version: 2.05.78
• Device: ConBee II
• Do you use an USB extension cable: no

Additional context

No issues with previously (weeks/months ago) added sensors. I struggled with pairing new sensors before (in 2.05.77). However, it seemed that pairing and then immediately opening and closing the window helps with proper pairing.

[Smanar]

It s normal, it s because the device led can be used as light ....

Seriously, that's a funny bug. Can you find and show us the JSON for the light entry ? I think you can find it somewhere in HA or using the API if you know how to do that (with api key ) ?

[fi-sch]

It s normal, it s because the device led can be used as light ....

Seriously, that's a funny bug. Can you find and show us the JSON for the light entry ? I think you can find it somewhere in HA or using the API if you know how to do that (with api key ) ?

Here you go:

"19": {
        "etag": "b3869321f635a4b00fe2734e1902f6a2",
        "hascolor": false,
        "lastannounced": null,
        "lastseen": "2020-07-05T08:34:13Z",
        "manufacturername": "Unknown",
        "modelid": null,
        "name": "Okno Kuchnia",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": true
        },
        "swversion": null,
        "type": "Dimmer switch",
        "uniqueid": "00:15:8d:00:03:e6:f9:93-01"
    }

[fi-sch]

Just in case someone asks about the clusters :)

[SwoopX]

What is the model identifier from basic cluster? Do you have a dimmer switch and was it paired as last device before this one?

The reason why it comes up as light is that it identifies itself as dimmer switch, which is whitelisted for lights.

Could you also please share a screenshot of the node info panel?

[Smanar]

Lot of differences with mines, I haven't OTAU cluster, another model id, and no thoses outputs clusters .... There is definitively something strange.

You only one sensor with this problem ?

[fi-sch]

What is the model identifier from basic cluster? Do you have a dimmer switch and was it paired as last device before this one?

The reason why it comes up as light is that it identifies itself as dimmer switch, which is whitelisted for lights.

Could you also please share a screenshot of the node info panel?

There you go:

No, I do not have any dimmer switch right now. I did pair dimmable light before, but it was quite long time ago (at least two months ago) and I see it in deCONZ reappearing even I tried to delete this node many times.

Lot of differences with mines, I haven't OTAU cluster, another model id, and no thoses outputs clusters .... There is definitively something strange.

You only one sensor with this problem ?

I have this issue for all 4 Xiaomi sensors that I paired yesterday, not only this one.

[fi-sch]

Just to add. Here's a screenshot of Phoscon with 3 identical sensors shown in Lights as 3 different products. All of them were paired yesterday.

[morfei1]

IMHO, it looks like a phoscon related problem.

https://github.com/dresden-elektronik/phoscon-app-beta

[ebaauw]

The door sensor looks like a light because of the server On/Off cluster. In some crooked Xiaomi way, it uses attribute reporting on this cluster to indicate open vs close. Normally, the API shouldn’t create a /lights resource, because the sensor’s Receiver On When Idle is false. Not sure if the API plugin was changed or if a new version of the sensor or sensor firmware has changed the descriptor.

I only have the (square-ish) Aqara sensor, I think this is the round-ish Mi sensor? Are you able to read the Basic cluster attributes, notably Date Code and SW Build ID? Can you sniff the Simple Descriptor Response? And the Device Announce?

[fi-sch]

I only have the (square-ish) Aqara sensor, I think this is the round-ish Mi sensor?

Yes. It's round-ish one.

Are you able to read the Basic cluster attributes, notably Date Code and SW Build ID?

Here you go, it was already posted above:

EDIT: Sorry, I've just noticed that Date Code and SW Build ID are missing. I will try again, maybe with different sensor.

Can you sniff the Simple Descriptor Response? And the Device Announce?

I suppose I can but I don't know how to achieve that :)

[fi-sch]

Here's Basic Cluster with Date Code and SW Build ID:

[ebaauw]

That's a fairly old date.

Looking at the code, the manufacturer code VENDOR_JENNIC (0x1037) has been whitelisted, for the lumi.ctrl_neutral wired switches. That has been the case since years. The device advertises a device type of Dimmer Switch, this has been whitelisted since Feb 2019, in https://github.com/dresden-elektronik/deconz-rest-plugin/commit/d976ed33dfe4f27de33869b248f826de8aff2c10 to support the Sinope.

Not sure how to remedy this in the current code: the /lights resource is created before the Basic cluster has been read (see also the missing values in the resource), so there's no way to distinguish the door sensor from the dimmer switch.

[Smanar]

I don't see the Mac capabilities for the switch on the capture for the sinope (bugged device ?) But one is FFD and the other RFD ?

There is end device with DEV_ID_HA_DIMMER_SWITCH type ?

There is already an ugly hack in void LightNode::setHaEndpoint(const deCONZ::SimpleDescriptor &endpoint) for Xiaomi (to force modelid read before continuing), we can't use the same ?

[fi-sch]

But one is FFD and the other RFD ?

All I can add from my side at this point is that all of those 4 sensors appeared in deCONZ as an end-devices (RFD).

There's one more thing that maybe will give you some clue:

I struggled with pairing 2 Xiaomi door sensors before (under v.2.05.77). (One of those sensors is also 1 of those 4 that are he matter of this topic.) Both sensors were visible in deCONZ without any name and I couldn't make any of them visible in Phoscon. Tried pairing over and over many times. Suddenly, just before an update to 2.05.78, I saw that out of the blue one of those sensors finally appeared in Phoscon – but it DID NOT appear under /lights. Still no luck with the second one. So after a couple of days I've updated deCONZ to 2.05.78 and then tried again pairing this one "waiting" sensor and additional 3 similar guys. (It seemed that pairing and then immediately opening and closing the window helped me with "proper" pairing.) I was able to pair all 4 sensors using that method – but every each on of them DID appear under both /lights and /sensors.

I'm not sure about 2 things:

• If this one sensor that was visible only in deCONZ for a long time before and now got finally paired (in 2.05.78, and is affected by the issue) was also from the same batch of sensors.
• If it isn't just deCONZ issue.

PS I still have a couple of those Xiaomi sensors (brand-new) so I may do some testing.

[ebaauw]

There is already an ugly hack in void LightNode::setHaEndpoint(const deCONZ::SimpleDescriptor &endpoint) for Xiaomi (to force modelid read before continuing), we can't use the same ?

If you have a LightNode, the resource has already been created.

[SwoopX]

I also see no other reason than to change the pairing process to recklessly force a manufacturer and modelId read directly after the simple descriptors. But that's a major.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fi-sch]

It should remain opened as I assume it wasn't fixed yet.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Kristian8606]

With Deconz version .84, this sensor still shows a light switch when paired again

[Smanar]

Pls mùake a try with version 85, from my memory it s repared now.

[SwoopX]

Tbh, I don't think so. Presumably, Manu meant Tuya instead of Xiaomi as I haven't seen any change for Xiaomi

[Smanar]

This PR https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3364

[SwoopX]

Yup

[Smanar]

But this code can works for Xiaomi too ? It will set the device as light for only danalock device, so it will disable the problem for Xiaomi.

[SwoopX]

Had a closer look now and expanded the code of the PR. Yeah, I guess that should prevent light creation. However, I'd expect the device still to be "classified" in light_node.cpp due to the door lock cluster.

[fi-sch]

I think it was solved, so I'm closing this issue.