Improvements to Tuya ZY-M100-24G ('_TZE204_ijxvkhd0')

[magicus]

The Tuya mm-wave radar model ZY-M100-24G is supported in ZHC, but the support is a bit lacking. I have added the m unit to the distance sensor, replaced presence with occupancy to better align with the terminology used in Home Assistance (I have found no obvious distinction when searching for this for other entities, but HA treats "presence" as "being at home" while "occupancy" is treated as "person detected", and that is good enough for me as a norm).

I am also marking the configuration settings as being of the config category.

This is coupled with this PR for Z2M which adds corresponding HA metadata.

[Koenkk]

Thanks!

[Dillton]

Hi @magicus @Koenkk.
I believe this totally destroyed the sensitivity settings.
@magicus did you really tested all the changes properly? Changing values to raw causing that values are decimals and logs are spammed with that.

I am afraid the devices will not behave correctly.

[magicus]

@Dillton You seem to be correct. I apologize. :-(

I thought I had tested this well enough (through a local external converter) but I admit I did not check the logs, but only verified that the values did not jump randomly when changing alternatively between HA and the Z2M GUI. I also thought I saw a difference in sensitivity level from the sensor, but it is not so clear-cut, so that might have been just me fooling myself.

The log spamming is bad, but it was also the case that the value did not work properly before, so a better solution than a complete revert need to be found. I'll look into it.

[ippo112]

Hi,
I detect same error,

---

Registratore: homeassistant.components.mqtt.number
Fonte: components/mqtt/number.py:182
Integrazione: MQTT (documentazione, problemi)
Prima occorrenza: 00:00:32 (531 occorrenze)
Ultima registrazione: 06:53:41

Invalid value for number.presence_24ghz_occupancy_sensitivity: 20 (range 1.0 - 10.0)
Invalid value for number.presence_24ghz_occupancy_sensitivity: 80 (range 1.0 - 10.0)
Invalid value for number.presence_24ghz_motion_sensitivity: 30 (range 1.0 - 10.0)
Invalid value for number.presence_24ghz_motion_sensitivity: 100 (range 1.0 - 10.0)
Invalid value for number.presence_24ghz_occupancy_sensitivity: 100 (range 1.0 - 10.0)

---

Adapter
SONOFF Zigbee 3.0 USB Dongle Plus-P
Versione Zigbee2MQTT
[1.41.0]

[Dillton]

@Dillton You seem to be correct. I apologize. :-(

I thought I had tested this well enough (through a local external converter) but I admit I did not check the logs, but only verified that the values did not jump randomly when changing alternatively between HA and the Z2M GUI. I also thought I saw a difference in sensitivity level from the sensor, but it is not so clear-cut, so that might have been just me fooling myself.

The log spamming is bad, but it was also the case that the value did not work properly before, so a better solution than a complete revert need to be found. I'll look into it.

Mistakes are made all the time.

I was able to test the overall device functionality and luckily everything is working only the log is spammed.
I also created ext. converter based on current lines in released code and I changed only tuya.valueConverter.raw to tuya.valueConverter.divideBy10. Since then no more log spam about invalid values but the values are jumping back to previous states so this is a no go.

Then I tried to revert back to tuya.valueConverter.divideBy10FromOnly as it was before the changes and there is another log spam only when changing the values not like with latest changes where spam never stops. I have to say I saw in this case from 10 to 20 occurrences per device and then it stabilized. Also the values are kept and not reverting. So this could be considered as a hotfix but for sure a better solution is needed to avoid the log spam completely.

Another possibility would be to just filter out such logs on HA side as the devices are working just fine until better solution is found for Z2M.

There is also created issue for this as I didn't know where the reaction would be first so we can move the discussion there or stay here. Koenkk/zigbee2mqtt#24593

[ippo112]

@Dillton
please can you explain and share the fix to the [release 1.41.0].
I understand that it's necessary to creat an external converter with "tuya.valueConverter.divideBy10FromOnly " , is it correct?
thanks

[Dillton]

I have set the converter like this only change is in the tuya.valueConverter for sesitivity options.
When you change the values then you will see a little log spam but it should stop after a minute or so.

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const modernExtend = require('zigbee-herdsman-converters/lib/modernExtend');
const e = exposes.presets;
const ea = exposes.access;
const tuya = require('zigbee-herdsman-converters/lib/tuya');

const definition = {
    fingerprint: tuya.fingerprint('TS0601', ['_TZE204_ijxvkhd0']),
        model: 'ZY-M100-24G',
        vendor: 'Tuya',
        description: '24G MmWave radar human presence motion sensor',
        fromZigbee: [tuya.fz.datapoints],
        toZigbee: [tuya.tz.datapoints],
        configure: tuya.configureMagicPacket,
        exposes: [
            e.enum('state', ea.STATE, ['none', 'presence', 'move']).withDescription('Presence state'),
            e.occupancy(),
            e.numeric('distance', ea.STATE).withUnit('m').withDescription('Target distance'),
            e.illuminance_lux(),
            e
                .numeric('motion_sensitivity', ea.STATE_SET)
                .withValueMin(1)
                .withValueMax(10)
                .withValueStep(1)
                .withCategory('config')
                .withDescription('Motion sensitivity'),
            e
                .numeric('occupancy_sensitivity', ea.STATE_SET)
                .withValueMin(1)
                .withValueMax(10)
                .withValueStep(1)
                .withCategory('config')
                .withDescription('Occupancy sensitivity'),
            e
                .numeric('max_range', ea.STATE_SET)
                .withValueMin(1.5)
                .withValueMax(5.5)
                .withValueStep(1)
                .withUnit('m')
                .withCategory('config')
                .withDescription('Maximum range'),
            e
                .numeric('occupancy_timeout', ea.STATE_SET)
                .withValueMin(1)
                .withValueMax(1500)
                .withValueStep(1)
                .withUnit('s')
                .withDescription('Occupancy timeout'),
        ],
        meta: {
            multiEndpoint: true,
            tuyaDatapoints: [
                [112, 'occupancy', tuya.valueConverter.trueFalse1],
                [106, 'motion_sensitivity', tuya.valueConverter.divideBy10FromOnly],
                [111, 'occupancy_sensitivity', tuya.valueConverter.divideBy10FromOnly],
                [107, 'max_range', tuya.valueConverter.divideBy100],
                [109, 'distance', tuya.valueConverter.divideBy100],
                [110, 'occupancy_timeout', tuya.valueConverter.raw],
                [104, 'illuminance_lux', tuya.valueConverter.raw],
                [102, 'illuminance_treshold_max', tuya.valueConverter.raw],
                [103, 'illuminance_treshold_min', tuya.valueConverter.raw],
                [105, 'state', tuya.valueConverterBasic.lookup({none: 0, presence: 1, move: 2})],
            ],
        },
    };

module.exports = definition;

[ippo112]

thanks!
it seems to work well.
only when you change the values, there are warnings in the logs,
for example if you set the Sensitivity value = 9, for a few seconds the value becomes 0.9 (and here the warnings are generated) and then goes back to 9 and everything is ok.

[Dillton]

Yes exactly.

[magicus]

I've posted a PR with a revert of the two sensitivity values in #8272.

[rodrigogbs]

This sensor works with PRESENCE not OCCUPANCY, this change broke all my entities and automations...

We have lots of variations on this sensor: 5G / 24G / ceiling mount / wall mount, and now just this version (24G ceiling mount) is different, so, I strongly suggest to revert to the original configuration OR to map and change ALL OF THEM together, otherwise (as it is happening with me) it will became a completely mess to manage.

[magicus]

This sensor works with PRESENCE not OCCUPANCY

It is not particularly clear at all what the difference is. What is the difference, for you, that makes you consider what this sensor detect as "presence" and not "occupancy"?

I searched a lot around the web, trying to find a definition, or a guiding principle, without any results. For ZHC, it seems rather arbitrarily implemented in different devices.

The one guiding principle I found was how this is implemented in Home Assistance:
https://www.home-assistant.io/integrations/binary_sensor/#device-class

In HA, "Presence" is represented as the binary pair "Home" <-> "Away", while "Occupancy" is represented as the pair "Detected" <-> "Clear". This makes it clear (no pun intended!) that a sensor like this is an "occupancy" sensor, while e.g. a wifi detection of a mobile phone is a "presence" sensor.

Given the track record of the Home Assistance project and community to find good community-wide solutions to home automation problems, I thought their definition was as good as one could reasonably hope to find.

I agree that it would make sense to verify that all radar sensors publish their data as "occupancy" and not "presence". I unfortunately only own this model, so I cannot test any other hardware.

[rodrigogbs]

This sensor works with PRESENCE not OCCUPANCY

It is not particularly clear at all what the difference is. What is the difference, for you, that makes you consider what this sensor detect as "presence" and not "occupancy"?

I searched a lot around the web, trying to find a definition, or a guiding principle, without any results. For ZHC, it seems rather arbitrarily implemented in different devices.

The one guiding principle I found was how this is implemented in Home Assistance: https://www.home-assistant.io/integrations/binary_sensor/#device-class

In HA, "Presence" is represented as the binary pair "Home" <-> "Away", while "Occupancy" is represented as the pair "Detected" <-> "Clear". This makes it clear (no pun intended!) that a sensor like this is an "occupancy" sensor, while e.g. a wifi detection of a mobile phone is a "presence" sensor.

Given the track record of the Home Assistance project and community to find good community-wide solutions to home automation problems, I thought their definition was as good as one could reasonably hope to find.

I agree that it would make sense to verify that all radar sensors publish their data as "occupancy" and not "presence". I unfortunately only own this model, so I cannot test any other hardware.

There are lots of presence sensors, including Aqara ones, that exposes PRESENCE instead of OCCUPANCY, in my understanding, if a pattern is necessary, it must be a pattern for everyone, not just for the one that you own, imagine if each one decide the new pattern that the sensor must have?

As we can see, OCCUPANCY is currently more related to motion, and PRESENCE for a static presence:

supported OCCUPANCY sensors (all related to motion): https://www.zigbee2mqtt.io/supported-devices/#e=occupancy

supported PRESENCE sensors (all related to static presence): https://www.zigbee2mqtt.io/supported-devices/#e=presence

Finally, in my opinion, a change on it must be a breaking change, considering that it changes the type and name of the entity.

@Koenkk what do you think about?

[magicus]

What I see from the two links you sent is that there is 174 devices supporting "occupancy", but only 38 devices supporting "presence" (and from the looks of it, many of these seems to be variations on the very same Tuya device). That even goes for the 8 or so devices that has "presence" in their title, but still reports "occupancy".

If anything, I think this points to "presence" being a mistake, which should never have been included in the "vocabulary".

[rodrigogbs]

What I see from the two links you sent is that there is 174 devices supporting "occupancy", but only 38 devices supporting "presence" (and from the looks of it, many of these seems to be variations on the very same Tuya device). That even goes for the 8 or so devices that has "presence" in their title, but still reports "occupancy".

If anything, I think this points to "presence" being a mistake, which should never have been included in the "vocabulary".

Again, this must be a breaking change affecting all of the sensor, not just that one that you own...

This way Z2M database will turn into a completely mess...

[Koenkk]

It seems to be presence indeed, we can expose both now, presence and occupancy to prevent a breaking change and remove occupancy with z2m 2.0.0

[rodrigogbs]

It seems to be presence indeed, we can expose both now, presence and occupancy to prevent a breaking change and remove occupancy with z2m 2.0.0

Amazing!

Will you put it into a new release for the current version?

Thanks!

[Koenkk]

I've added it directly to the 2.0.0 release for now.