Inconsistent presence / distance values after leaving motion sensor area

[glecoz]

Hi,

I bought 3 items of ZY-M100-24GV2 (wall mount) bought on your store a few days ago (early April 2024), devices firmware are shown as up to date in Tuya app.

However, on 2 of them, after leaving the motion sensor area, the sensor returns a fake/ghost short distance value and state=presence to Z2M (Zigbee2MQTT), so my linked lights remain on endlessly after leaving.

When leaving the area, the sensor switch back to move as expected, then when I leave further, the sensor reverts back to a short distance state = presence with sth like distance value < 0.12 on Z2M, whatever the sensitivity / presence levels set, which is inconsistent.

I've registered your last 3 JS files as converters in Z2M, just in case :

On these same faulty items, I don't have this residual ghost presence while connected to a Tuya gateway, the sensors behave perfectly and always return proper away/move/presence status on a Tuya / MOES app when someone is moving.

So, I guess there's still sth wrong or to be improved in your Zigbee2MQTT JS converter files, unable to suggest anything, if you could just compare more deeply the behavior on 2 identical devices on both Tuya and Z2M you will probably reproduce the issue described above.

Unable to describe why 1 out of my 3 items still behaves properly on Z2M, with no residual ghost presence. 🤷‍♂️

[wzwenzhi]

Thank you very much for your email. This is a strange phenomenon indeed. We will feed back to the engineer for confirmation. If there is an update to the js file, we will upload the update and let you know by email.

发自我的iPhone

------------------ Original ------------------ From: glecoz @.> Date: Thu,Apr 4,2024 7:40 PM To: wzwenzhi/Wenzhi-ZigBee2mqtt @.> Cc: Subscribed @.***> Subject: Re: [wzwenzhi/Wenzhi-ZigBee2mqtt] Inconsistent presence / distance valuesafter leaving motion sensor area (Issue #4)

Hi,

I bought 3 items of ZY-M100-24GV2 (wall mount) bought on your store a few days ago (early April 2024), devices firmware are shown as up to date in Tuya app.

However, on 2 of them, after leaving the motion sensor area, the sensor returns a fake/ghost short distance value and state=presence to Z2M (Zigbee2MQTT), so my linked lights remain on endlessly after leaving.

When leaving the area, the sensor switch back to move as expected, then when I leave further, the sensor reverts back to a short distance state = presence with sth like distance value < 0.12 on Z2M, which is inconsistent.

I've registered your last 3 JS files as converters in Z2M, just in case :

image.png (view on web)

On these same faulty items, I don't have this residual ghost presence while connected to a Tuya gateway, the sensors behave perfectly and always return proper away/move/presence status on a Tuya / MOES app when someone is moving.

So, I guess there's still sth wrong or to be improved in your Zigbee2MQTT JS converter files, unable to suggest anything, if you could just compare more deeply the behavior on 2 identical devices on both Tuya and Z2M you will probably reproduce the issue described above.

Unable to describe why 1 out of my 3 items still behaves properly on Z2M, with no residual ghost presence. 🤷‍♂️

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[glecoz]

The main reason is that each of these sensors (at least mine) publish a payload of 10 values every single second to the MQTT broker ! 😱 as perfectly described here.

So on a Raspberry Pì with 8 GB RAM and decent CPU and Z2M + MQTT in Docker for home automation, even with only 3 motion sensors, the MQTT broker is getting heavy traffic spam, thus all the services connected to the broker (such as Node.js services triggering a Philips Hue API for lightning from a local gateway) get huge latency from a flooded MQTT broker.

The only way I found to partly reduce this flood is by setting a debounce = 5 on each of these sensors on Zigbee2MQTT, but then we get the initial weird sensor behavior described above.

So, I think it's just an emergency to provide a firmware update if possible.

As for any motion sensor or multi-sensor, only the state and presence values must be sent immediately to the broker (only when their values change), all other values must be sent only periodically (every 5 minutes at most, even if they don't change), including illuminance, to avoid MQTT flooding during highly variating lux levels, due to broken clouds outside.

Please let me know if an update from your team is available any soon, but in their current state, your ZY-M100-24GV2 are just unusable for me, and a huge loss of time spent on a useless fine-tuning that simply doesn't work.

[wzwenzhi]

Hello, as you mentioned, we are already developing a new version of the firmware. In order to allow users to customize the reporting frequency.

------------------ 原始邮件 ------------------ 发件人: "wzwenzhi/Wenzhi-ZigBee2mqtt" @.>; 发送时间: 2024年4月5日(星期五) 凌晨3:23 @.>; @.**@.>; 主题: Re: [wzwenzhi/Wenzhi-ZigBee2mqtt] Inconsistent presence / distance values after leaving motion sensor area (Issue #4)

The main reason is that each of these sensors (at least mine) publish a payload of 10 values every single second to the MQTT broker ! 😱 as perfectly described here.

So on a Raspberry Pì with 8 GB RAM and decent CPU and Z2M + MQTT in Docker for home automation, even with only 3 motion sensors, the MQTT broker is getting heavy traffic spam, thus all the services connected to the broker (such as Node.js services triggering a Philips Hue API for lightning from a local gateway) get huge latency from a flooded MQTT broker.

The only way I found to partly reduce this flood is by setting a debounce = 5 on each of these sensors on Zigbee2MQTT, but then we get the initial weird sensor behavior described above.

So, I think it's just an emergency to provide a firmware update if possible.

As for any motion sensor or multi-sensor, only the state and presence values must be sent immediately to the broker (only when their values change), all other values must be sent only periodically (every 5 minutes at most, even if they don't change), including illuminance, to avoid MQTT flooding during highly variating lux levels, due to broken clouds outside.

Please let me know if an update from your team is available any soon, but in their current state, your ZY-M100-24GV2 are just unusable for me, and a huge loss of time spent on a useless fine-tuning that simply doesn't work.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[kingunlim]

hello when will the fw update be released? i cant use my sensors because it floods my zigbee network atm!

[kingunlim]

and is there a way to update the firmware without a tuya gateway. i bought one one month before to update the firmware but it was already on the newest that floods my network :( so i sold it afterwards

[kkossev]

@wzwenzhi, while working on the spammy distance reports configuration, please check whether the illuminance reports can also be configured - a threshold value or minimum time between the lux reports.

[wzwenzhi]

Hello, which model of product did you update the firmware for? Can you send it to us for confirmation?

------------------ 原始邮件 ------------------ 发件人: "wzwenzhi/Wenzhi-ZigBee2mqtt" @.>; 发送时间: 2024年4月25日(星期四) 凌晨2:02 @.>; @.**@.>; 主题: Re: [wzwenzhi/Wenzhi-ZigBee2mqtt] Inconsistent presence / distance values after leaving motion sensor area (Issue #4)

and is there a way to update the firmware without a tuya gateway. i bought one one month before to update the firmware but it was already on the newest that floods my network :( so i sold it afterwards

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[kingunlim]

is there a time frame for the fw update? @wzwenzhi

[BandBxx]

Hello, as you mentioned, we are already developing a new version of the firmware. In order to allow users to customize the reporting frequency. … ------------------ 原始邮件 ------------------ 发件人: "wzwenzhi/Wenzhi-ZigBee2mqtt" @.>; 发送时间: 2024年4月5日(星期五) 凌晨3:23 @.>; @.**@.>; 主题: Re: [wzwenzhi/Wenzhi-ZigBee2mqtt] Inconsistent presence / distance values after leaving motion sensor area (Issue #4) The main reason is that each of these sensors (at least mine) publish a payload of 10 values every single second to the MQTT broker ! 😱 as perfectly described here. So on a Raspberry Pì with 8 GB RAM and decent CPU and Z2M + MQTT in Docker for home automation, even with only 3 motion sensors, the MQTT broker is getting heavy traffic spam, thus all the services connected to the broker (such as Node.js services triggering a Philips Hue API for lightning from a local gateway) get huge latency from a flooded MQTT broker. The only way I found to partly reduce this flood is by setting a debounce = 5 on each of these sensors on Zigbee2MQTT, but then we get the initial weird sensor behavior described above. So, I think it's just an emergency to provide a firmware update if possible. As for any motion sensor or multi-sensor, only the state and presence values must be sent immediately to the broker (only when their values change), all other values must be sent only periodically (every 5 minutes at most, even if they don't change), including illuminance, to avoid MQTT flooding during highly variating lux levels, due to broken clouds outside. Please let me know if an update from your team is available any soon, but in their current state, your ZY-M100-24GV2 are just unusable for me, and a huge loss of time spent on a useless fine-tuning that simply doesn't work. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

We are all very much waiting!

[kingunlim]

@wzwenzhi can you give an aswer when a fw update will come????

[LeeWiu]

Please release fw update to stop flood.

[KoKolaj]

Please, is there a new firmware for testing?

[Jaber7]

Update please

[seoeaa]

When will the update be?

[iktjallingk]

Any news about this?

[mariusvr]

Any updates? This device is also flooding my zigbee network and makes it crash. Where can we get the firware?

[MaximillianC]

+1 - Please update us on an ETA for the updates firmware, to allow configurable reporting thresholds and/or intervals. These sensors are honestly awesome, except for the spammy reporting, which is a BIG problem. I use both the 5GHz and the 24GHz with Zigbee2MQTT, and unfortunately the 24GHz ones aren't quite working right... but the 5GHz work great except for the constant reporting flooding my Zigbee networks, which eventually causes other devices to stop responding.