Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
12.22k stars 1.69k forks source link

ZY-M100-S_1 sensors report every second #19045

Open seblu opened 1 year ago

seblu commented 1 year ago

What happened?

The Tuya ZY-M100-S_1 (_TZE204_sxm7l9xa) is reporting its values every second. This values can or can not changes.

Here is an example with values not changing: Screenshot_20230921_231622

What did you expect to happen?

A delay or minimal value change that can be configured in the Reporting tab.

How to reproduce it (minimal and precise)

Pair the sensor and it starts sending data every second or 2.

Zigbee2MQTT version

1.33.0

Adapter firmware version

20221226

Adapter

Silicon_Labs_Sonoff_Zigbee_3.0_USB_Dongle_Plus_0001

Debug log

debug 2023-09-21 23:20:33: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":6912}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:33: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:33.910Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:35: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":7168}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:35: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:35.506Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:37: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":7424}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:37: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:37.101Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:38: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":7680}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:38: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:38.697Z","linkquality":102,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:40: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":7936}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:40: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:40.293Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:41: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":8192}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:41: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:41.889Z","linkquality":109,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:43: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":8448}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:43: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:43.684Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:45: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":8704}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:45: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:45.081Z","linkquality":102,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:46: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":8960}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:46: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:46.674Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:48: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":9216}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:48: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:48.272Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:49: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":9472}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:49: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:49.866Z","linkquality":109,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:51: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":9728}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:51: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:51.462Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:53: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":9984}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:53: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:53.058Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:54: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":10240}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:54: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:54.653Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:56: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":10496}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:56: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:56.250Z","linkquality":109,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
GerSant commented 8 months ago

Great solution! Can you send me more info about how to do the retro fit?

Thanks in advance

Cheers

mattc157 commented 8 months ago

Great solution! Can you send me more info about how to do the retro fit?

Thanks in advance

Cheers

Hey there, the jist of it is you can buy the sensor new from digikey: https://www.digikey.ca/en/products/detail/dfrobot/SEN0521/18069236 or remove the sensor from an existing ZY-M100 or similar tuya sensor. you will find you can just cut the sensor of the tuya main board and throw away the rest. the sensor has 5 pins +5v, 0v, output, UART RX and TX. select a esp32 that suits you I like the poe olimex or everything smart home poe board or any wifi esp32 devkit will do just fine. the wiring is pretty simple. wire the 5v and 0v, the output goes to an gpio and will trigger the binary sensor, the UART will be wired TX to RX and RX to TX and provides the programming interface to the sensor e.g setting the range. I will attach the esphome config for the POE based esp32 but its easy to change to wifi:

substitutions:
  name: ensuite-presence
  friendly_name: Ensuite Presence
  hidden_ssid: "false"
  factory_reset_disabled: "false"

esphome:
  name: ${name}
  friendly_name: ${friendly_name}

esp32:
  board: esp32-poe
  framework:
    type: esp-idf  
    version: recommended

logger:
#  level: ERROR

api:
  encryption:
    key: "#####"

ota:
  password: "#####"

ethernet:
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO17_OUT
  phy_addr: 0
  power_pin: GPIO12
  manual_ip:
    static_ip: 192.168.1.187
    gateway: 192.168.1.1
    subnet: 255.255.255.0

mqtt:
  broker: 192.168.1.5
  username: esphome
  password: esphome
  client_id: ${name}
  topic_prefix: esphome/${name}
  discovery: false

output:
  - platform: template
    id: mmwave_led_output
    type: binary
    write_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - if:
          condition:
            lambda: !lambda return state;
          then:
            - uart.write: "setLedMode 1 0"
          else:
            - uart.write: "setLedMode 1 1"
      - delay: 1s
      - uart.write: "saveConfig"
      - delay: 3s
      - switch.turn_on: mmwave_sensor

external_components:
  - source:
      type: git
      url: https://github.com/ssieb/custom_components
    components: [ serial ]

uart:
  id: uart_bus
  tx_pin: GPIO4
  rx_pin: GPIO36
  baud_rate: 115200
  debug:
    direction: BOTH
    dummy_receiver: true
    after:
      delimiter: "\n"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

binary_sensor:
  - platform: gpio
    name: mmWave
    id: mmwave
    device_class: occupancy
    pin:
      number: GPIO33
      mode: INPUT_PULLDOWN

  - platform: gpio
    pin:
      number: GPIO32
      mode: INPUT_PULLDOWN
    name: PIR
    id: pir_motion_sensor
    device_class: motion
    filters:
      - delayed_off:  !lambda 'return id(pir_off_latency).state * 1000.0;'

  - platform: template
    name: Occupancy
    id: occupancy
    device_class: occupancy
    filters:
      - delayed_off: !lambda 'return id(occupancy_off_latency).state * 1000.0;'
    lambda: |-
      if ( id(mmwave).state or id(pir_motion_sensor).state) {
        return true;
      } 
      else if (id(mmwave).state == 0 and id(pir_motion_sensor).state == 0) {
        return false;
      } 
      else {
        return id(occupancy).state;
      }

switch:
  - platform: template
    name: mmWave sensor
    id: mmwave_sensor
    disabled_by_default: false
    entity_category: config
    optimistic: true
    restore_mode: RESTORE_DEFAULT_ON
    turn_on_action:
      - uart.write: "sensorStart"
      - delay: 1s
    turn_off_action:
      - uart.write: "sensorStop"
      - delay: 1s

  - platform: template
    name: UART presence output
    id: uart_presence_output
    entity_category: config
    internal: false
    optimistic: true
    turn_on_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: "setUartOutput 1 1"
      - delay: 1s
      - uart.write: "saveConfig"
      - delay: 3s
      - switch.turn_on: mmwave_sensor
    turn_off_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: "setUartOutput 1 0"
      - delay: 1s
      - uart.write: "saveConfig"
      - delay: 3s
      - switch.turn_on: mmwave_sensor

  - platform: template
    name: UART target output
    id: uart_target_output
    entity_category: config
    internal: false
    optimistic: true
    assumed_state: false
    turn_on_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: "setUartOutput 2 1 1 1"
      - delay: 1s
      - uart.write: "saveConfig"
      - delay: 3s
      - switch.turn_on: mmwave_sensor
    turn_off_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: "setUartOutput 2 0"
      - delay: 1s
      - uart.write: "saveConfig"
      - delay: 3s
      - switch.turn_on: mmwave_sensor

number:
  - platform: template
    name: mmWave Start Distance
    icon: mdi:arrow-collapse-left
    entity_category: config
    id: mmwave_start_distance
    min_value: 0
    max_value: 1
    initial_value: 0
    optimistic: true
    step: .1
    restore_value: true
    unit_of_measurement: m
    mode: slider
    set_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: !lambda |-
          std::string mss = "setRange " + to_string(id(mmwave_start_distance).state) + " " + to_string(id(mmwave_stop_distance).state);
          return std::vector<unsigned char>(mss.begin(), mss.end());
      - delay: 3s
      - uart.write: "saveConfig"
      - delay: 2s
      - switch.turn_on: mmwave_sensor

  - platform: template
    name: mmWave Stop Distance
    icon: mdi:arrow-collapse-right
    entity_category: config
    id: mmwave_stop_distance
    min_value: 1
    max_value: 11
    initial_value: 4
    optimistic: true
    step: .5
    restore_value: true
    unit_of_measurement: m
    mode: slider
    set_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: !lambda |-
          std::string mss = "setRange " + to_string(id(mmwave_start_distance).state) + " " + to_string(id(mmwave_stop_distance).state);
          return std::vector<unsigned char>(mss.begin(), mss.end());
      - delay: 3s
      - uart.write: "saveConfig"
      - delay: 2s
      - switch.turn_on: mmwave_sensor

  - platform: template
    name: mmWave off latency
    icon: mdi:clock-end
    entity_category: config
    id: mmwave_off_latency
    min_value: 1
    max_value: 60
    initial_value: 15
    optimistic: true
    step: 1
    restore_value: true
    unit_of_measurement: seconds
    mode: slider
    set_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: !lambda |-
          std::string mss = "setLatency " + to_string(id(mmwave_on_latency).state) + " " + to_string(id(mmwave_off_latency).state);
          return std::vector<unsigned char>(mss.begin(), mss.end());
      - delay: 3s
      - uart.write: "saveConfig"
      - delay: 2s
      - switch.turn_on: mmwave_sensor

  - platform: template
    name: mmWave on latency
    icon: mdi:clock-start
    id: mmwave_on_latency
    entity_category: config
    min_value: 0
    max_value: 60
    initial_value: 0
    optimistic: true
    step: 0.5
    restore_value: true
    unit_of_measurement: seconds
    mode: slider
    set_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: !lambda |-
          std::string mss = "setLatency " + to_string(id(mmwave_on_latency).state) + " " + to_string(id(mmwave_off_latency).state);
          return std::vector<unsigned char>(mss.begin(), mss.end());
      - delay: 3s
      - uart.write: "saveConfig"
      - delay: 2s
      - switch.turn_on: mmwave_sensor

  - platform: template
    name: mmWave sensitivity
    icon: mdi:target-variant
    id: mmwave_sensitivity
    entity_category: config
    min_value: 0
    max_value: 9
    initial_value: 7
    optimistic: true
    step: 1
    restore_value: true
    set_action:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write:
          !lambda std::string mss = "setSensitivity " + to_string((int)x);
          return std::vector<unsigned char>(mss.begin(), mss.end());
      - delay: 1s
      - uart.write: "saveConfig"
      - delay: 1s
      - switch.turn_on: mmwave_sensor

  - platform: template
    name: Occupancy off latency
    icon: mdi:clock-end
    entity_category: config
    id: occupancy_off_latency
    min_value: 1
    max_value: 60
    initial_value: 15
    optimistic: true
    step: 1
    restore_value: true
    unit_of_measurement: seconds
    mode: slider

  - platform: template
    name: PIR off latency
    icon: mdi:clock-end
    entity_category: config
    id: pir_off_latency
    min_value: 1
    max_value: 60
    initial_value: 10
    optimistic: true
    step: 1
    restore_value: true
    unit_of_measurement: seconds
    mode: slider

button:
  - platform: restart
    id: restart_internal
    entity_category: config
    internal: false

  - platform: template
    name: Restart mmWave sensor
    id: restart_mmwave
    entity_category: config
    internal: true
    on_press:
      - uart.write: "resetSystem"

  - platform: template
    name: Restart
    icon: mdi:restart
    entity_category: config
    disabled_by_default: True
    on_press:
      - button.press: restart_mmwave
      - button.press: restart_internal

  - platform: safe_mode
    internal: false
    name: Safe mode
    entity_category: config
    disabled_by_default: false

  - platform: template
    name: Factory reset mmWave
    icon: mdi:cog-counterclockwise
    id: factory_reset_mmwave
    entity_category: config
    on_press:
      - switch.turn_off: mmwave_sensor
      - delay: 1s
      - uart.write: "resetCfg"
      - delay: 3s
      - switch.turn_on: mmwave_sensor
glecoz commented 7 months ago

tbh, after multiple attempts models and firmware versions, I just gave up with those cheap Tuya & alike Mmwave sensors reporting every second, more mature versions will probably come next, but in the meantime I ended up with Aqara FP2, 3x the price, but it just works, map and multi-zone features, lux sensor as well, events triggered only upon relevant changes, and great precision.

Sure, the "wiring" to MQTT and your custom code is a bit weird (Sensor > HASS Homekit integration > HASS MQTT integration) but even so, it triggers my Hue lightning awesomely fast through MQTT and my Node.js code (< 1 second), needs some initial fine-tuning due to its precision, but then it's reliable.

Other current Mmwave sensors I found on benchmarks, Github issues and other end-user feedbacks have either ugly casing or seem just unusable or low-end sensors, for some reason... 🤷‍♂️

GerSant commented 7 months ago
image

I just bought a new device Tuya ZG-205Z/A and as you can see the spam messages are still but less "stormy"

juslex commented 7 months ago
image

I just bought a new device Tuya ZG-205Z/A and as you can see the spam messages are still but less "stormy"

Here I observed the same, however when the presence is false, he does the stormy again, publishing every second.

djcrawleravp commented 7 months ago

Just a word of caution.... MTG275-ZB-RL also has the same problem

https://github.com/Koenkk/zigbee2mqtt/assets/12896341/fabcdfed-c675-458a-ba06-de24d22e305e

elmaswebon commented 7 months ago

Following our discussions on the ZY-M100-S_1 sensor's high reporting frequency, I've come across an alternative sensor, the ZG-205Z, that seems to offer a more balanced reporting interval. Unlike the ZY-M100-S_1, which reports every second or two, the ZG-205Z reports approximately every 5 seconds. This could potentially reduce the network congestion issues we've been experiencing.

For those looking for a solution to the excessive reporting of the ZY-M100-S_1, the ZG-205Z might be worth exploring. I'm interested to hear if anyone else has tried this sensor or found other viable alternatives.

https://www.zigbee2mqtt.io/devices/ZG-205Z_A.html

https://www.aliexpress.com/item/1005005909805375.html?spm=a2g0o.order_detail.order_detail_item.3.1749f19c0fYTok

So, what about this device after almost two months?

I have two ZY-M100-24G plus 35 other Zigbee devices in the same network and starting to have stability problems. I'm thinking about buying two of these if you recommend them.

aslabsalbeh commented 7 months ago

Screenshot 2024-05-02 123844 I might be wrong so please correct me.

I was having this exact issue with the M100-S_1 and M100-S_2 sensors. My log was being flooded every second by both these sensors.

This happened after changing activating the "Last Seen" option under z2mqtt Settings from "Disabled" to "ISO_8601". I wanted to start tracking which devices go offline.

Once I disabled the Last Seen option again, my log was back to normal.

However the point which I might be missing, based on some of the above comments, is that these sensors must be still flooding the zigbee network, even though they're not showing up in the log?

How do I check?

djcrawleravp commented 7 months ago

Screenshot 2024-05-02 123844 I might be wrong so please correct me.

I was having this exact issue with the M100-S_1 and M100-S_2 sensors. My log was being flooded every second by both these sensors.

This happened after changing activating the "Last Seen" option under z2mqtt Settings from "Disabled" to "ISO_8601". I wanted to start tracking which devices go offline.

Once I disabled the Last Seen option again, my log was back to normal.

However the point which I might be missing, based on some of the above comments, is that these sensors must be still flooding the zigbee network, even though they're not showing up in the log?

How do I check?

As far as I know It'll still spamming the network, although disabling the "Last Seen" option will not send that info trough MQTT

Please correct me if I'm wrong

aslabsalbeh commented 7 months ago

How can I tell if the sensors are flooding the network? I don't have anything showing under Logs in Zigbee2MQTT menu in Home Assistant.

djcrawleravp commented 7 months ago

How can I tell if the sensors are flooding the network? I don't have anything showing under Logs in Zigbee2MQTT menu in Home Assistant.

If I go to Logs and filter for "info," I can still see "last_seen" packets being sent through my Zigbee network, even with the option disabled

aslabsalbeh commented 7 months ago

Screenshot 2024-05-02 145931 Weird, I'm barely getting any data in the z2mqtt log page.

djcrawleravp commented 7 months ago

Screenshot 2024-05-02 145931 Weird, I'm barely getting any data in the z2mqtt log page.

On my Case ("last seen" disabled).

Note I have 7 ZY-100 on my network and a total of 60 devices

Screen Shot 2024-05-02 at 19 01 59
adiov commented 7 months ago

Folks, the Last Seen configuration in Zigbee2MQTT has no impact on the Zigbee layer of your setup. This a dead end.

jvdburgt commented 6 months ago

Call me a naive optimist, but why can't Tuya simply fix this with a FW update? It shouldn't be that much work on their side, and it would fix one of their coolest products.

kenni commented 6 months ago

Call me a naive optimist, but why can't Tuya simply fix this with a FW update? It shouldn't be that much work on their side, and it would fix one of their coolest products.

I do not remember if it was earlier in this thread or in another, but someone has already asked Tuya customer service this question, and the answer was something like that it was hardcoded in the Zigbee transceiver module - which was not controllable from their Tuya firmware, so it wasn't possible for them to push out an software update to fix it. I assume they will likely just fix it in some new model with other hardware.

aslabsalbeh commented 6 months ago

Folks, the Last Seen configuration in Zigbee2MQTT has no impact on the Zigbee layer of your setup. This a dead end.

Adi do you mind explaining why I'm not seeing the same behavior on my ZY-M100-S_1 and S_2 ?

Z2mqtt Log is almost empty as shown in the screenshot above.

juslex commented 6 months ago

The new zigbee2mqtt no longer shows the information by default in the front end log. This observation is in this month's update. You need to manually activate it.

djcrawleravp commented 6 months ago

Folks, the Last Seen configuration in Zigbee2MQTT has no impact on the Zigbee layer of your setup. This a dead end.

At least disabling this will not spam the MQTT broker

IZZE2000 commented 6 months ago

Screenshot 2024-05-02 123844 I might be wrong so please correct me.

I was having this exact issue with the M100-S_1 and M100-S_2 sensors. My log was being flooded every second by both these sensors.

This happened after changing activating the "Last Seen" option under z2mqtt Settings from "Disabled" to "ISO_8601". I wanted to start tracking which devices go offline.

Once I disabled the Last Seen option again, my log was back to normal.

However the point which I might be missing, based on some of the above comments, is that these sensors must be still flooding the zigbee network, even though they're not showing up in the log?

How do I check?

I noticed the same. I do have 3 x M100-S_2 and Z2M started to chrash much more frequently when i enabled the Last Seen option. Might be two issues, both on the zigbee layer and then the communication with the MQTT broker?

fillwe commented 4 months ago

Okay so I thought i would write up my experience. I bought 2 M100 from this seller on AliExpress. https://a.aliexpress.com/_EIWxRMx

When I first got them they reported every second, both of them. I contacted the seller, and he said he could have a fix, but I had to have the Smart Life app/gateway so that he could push the update. I got a Tuya gateway from a store nearby, that I unpackaged very carefully so I could return it afterwards. And I provided the device ids to the seller, he pushed the update via Smart Life as well as sent me a link to a a updated external converter for Z2M. https://github.com/wzwenzhi/Wenzhi-ZigBee2mqtt. I used mtg035_radar240701.js.

When i had updated the units, i installed the external gateway. Rebooted Z2M and paired the sensors with Z2M again. No change, still reporting every seconds, but I now saw a toggle to turn off Distance reporting.

IMG_0577

I turned that off and the constant reporting stopped! Now it reports in every 15-30 seconds and instantly when I enter the room. Yeah I’m not getting the distance to the object but that is not important for my use case.

jvdburgt commented 4 months ago

@fillwe : That is awesome, and sounds like the solution we have all been waiting for!

Could you please provide a step-by-step how-to guide, as I don't want to mess up my (currently kinda-working fine) setup accidentally?

Also, as far as I can tell from your post, one of the steps is your seller pushing an update, right? So does that mean we have to plead with your seller if he can please updates ours too, or is there a work-around?

Looking very much forward to your reply :)

walberjunior commented 4 months ago

@fillwe What is the current firmware version?
Do you remember the previous version?

fillwe commented 4 months ago

@fillwe : That is awesome, and sounds like the solution we have all been waiting for!

Could you please provide a step-by-step how-to guide, as I don't want to mess up my (currently kinda-working fine) setup accidentally?

Also, as far as I can tell from your post, one of the steps is your seller pushing an update, right? So does that mean we have to plead with your seller if he can please updates ours too, or is there a work-around?

Looking very much forward to your reply :)

Yeah that’s the negative part of this solution. When I first added the sensors to the Smart Life app it didn’t detect any firmware updates. It was first when my seller pushed the update to my specific Device ids. I can ask if he would be open to push out to more devices if you guys can send me your device ids somehow, don’t know if he will accept though but might be worth a try.

I don’t now if we can get these firmware any other way, maybe I ask the seller if he could send the firmware file? It said in the Smart Life app that I went from MCU version 3.0.0 to 5.0.0 I believe. But not entirely sure, and I have now returned my Smart Life gateway in order to get back the money 😕

jvdburgt commented 4 months ago

Would you mind to maybe ask now, before we go through the process of buying a gateway and removing our sensors from our network? 😬

if the seller is willing to help, we might collect device ID’s here until - say - Sunday midnight, and you can provide the whole list to the seller in one go?

if you would be willing to do this you are an absolute hero in my book! 😎

PS. All that said, why doesn’t Tuya just push this update via the Smartlife app themselves? 🫤

walberjunior commented 4 months ago

I have 4 ZY-M100-L sensors detected as manufacturer _TZE204_ztc6ggyl, 2 of them were purchased from the same seller Wenzhi. I contacted them to see if they could send an update.

jvdburgt commented 4 months ago

Wait a sec, I have the ZY-M100-S2, will this work for them as well?

fillwe commented 4 months ago

Hello guys! I reached out to the seller and he has responded that they can only issue updates to the customers they have sold devices to. So you will need to contact your respective seller on AliExpress unfortunately. The modified firmware is only a fix for Zigbee2mqtt users and therefore not being prioritized as an important Tuya update (and not pushed via the official update channels). I have asked if he could share/upload the firmware file to the GitHub repo with the external converters. I’m thinking that we might find a way to OTA these via Z2M or via your own Tuya Developer account.

juslex commented 4 months ago

I contacted the seller and got the update as mentioned in this topic. I haven't put it back on zigbbe2mqtt yet, do I need any external converter to appear the option distante report on or off? WhatsApp Image 2024-07-15 at 18 12 27 WhatsApp Image 2024-07-15 at 18 12 13

fillwe commented 4 months ago

Yes I believe so, but not 100% certain.

satzmann666 commented 4 months ago

@fillwe So if I understand this correctly the seller (Wenzhi) has access to ota firmware update they probably developed themselves that adds the sought after feature for disabling the distance reporting on these Tuya mmwave sensors, maintains an official GH repo with Z2M converters for this feature, but only pushes the update via Tuya Smartlife gateway to specified device on request? For the amount of work it must have took to modify the firmware and create converters specifically for Z2M I wonder what could be preventing them from simply releasing the ota within the repository.

mickyshey commented 4 months ago

I’ve disabled this device for now due to the annoying report. Looking forward to the OTA update for this feature!!!

tandarra commented 4 months ago

Have posted here to highlight the issue, I encourage others to comment to hopefully speed this up. Almost been 1 year since Seblu first reported

https://www.tuyaos.com/viewtopic.php?t=3484

kkossev commented 4 months ago

Have posted here to highlight the issue, I encourage others to comment to hopefully speed this up. Almost been 1 year since Seblu first reported

https://www.tuyaos.com/viewtopic.php?t=3484

I will start a campaign on Hubitat community forum tomorrow - ask Tuya to make their mmWave sensors less spammy!

Update: the campaign in Hubitat forum was started.

Update: posted in SmartThings forum as well.

tandarra commented 4 months ago

So been having abit of a chat with Wenzhi to figure out what I can do after spending a few hundred dollars on devices that just shut down my system. The latency is so bad I can walk through a room and it doesn't trigger until I have left. I have both M100-24g and M100-5.8g

@fillwe can you explain more about your system? According to Wenzhi you have the MTG275-ZB-RL, which uses a relay to switch lights directly. Are you using this sensor to switch your lights directly and not use it as a trigger for switching on say via Home Assistant? Is it this device?

24fg

It sounds like the previous M100-24g and 5.8g devices are not supported. Due to the new models receiving an updated board processor and I guess this new firmware is configured for this. Only since June are the WZ-M100 5.8g Devices supported and WZ-M100-24g Devices are likely ready at the end of August. However we will not get the option to turn off distance reporting. Only change the frequency they are being reported over zigbee, via a setting called 'Interval Time'. Default will be 10seconds.

distance

I don't quite understand why this can't be implemented into any of the other mmWave products but it sounds like I want what @fillwe has - MTG275-ZB-RL, Not for the relay but for it to trigger my shelly 1pm to switch the light as I only want it to switch lights on when I enter the room, stay on whilst I am there and turn off once I have left. But have Home assistant control the automation and conditions as my current sensors are used in more than one automation, and I have zero use case for knowing the actual distance.

Alternatively anyone know how to and modify tuya development files to suit?

LeeWiu commented 4 months ago

Anyone with old firmware MCU Module v1.0.3 can test disabling Distance Reporting using this converter? https://raw.githubusercontent.com/wzwenzhi/Wenzhi-ZigBee2mqtt/main/mtg035_radar_240701.js I updated firmware to v1.0.5 on my _TZE204_dtzziy1e device and it's all good, thanks to fillwe

jvdburgt commented 4 months ago

Anyone with old firmware MCU Module v1.0.3 can test disabling Distance Reporting using this converter? https://raw.githubusercontent.com/wzwenzhi/Wenzhi-ZigBee2mqtt/main/mtg035_radar_240701.js I updated firmware to v1.0.5 on my _TZE204_dtzziy1e device and it's all good, thanks to fillwe

Will this also work on the ZY-M100-S1 and S2 versions (they're also based on the TZE204)?

If so, how do I install this firmware on the device?

LeeWiu commented 4 months ago

Anyone with old firmware MCU Module v1.0.3 can test disabling Distance Reporting using this converter? https://raw.githubusercontent.com/wzwenzhi/Wenzhi-ZigBee2mqtt/main/mtg035_radar_240701.js I updated firmware to v1.0.5 on my _TZE204_dtzziy1e device and it's all good, thanks to fillwe

Will this also work on the ZY-M100-S1 and S2 versions (they're also based on the TZE204)?

If so, how do I install this firmware on the device?

Ask the seller to push firmware through ota, but first you have to connect device to tuya gateway and provide Virtual ID.

fillwe commented 4 months ago

@tandarra Yes I have the new model with the built in relay but I’m not using it. I have a Shelly switch which the sensor turns on via a Home assistant automation.

jvdburgt commented 4 months ago

Okay, I sent my device ID's for update through the Tuya gateway.

However, I don't fully understand what the next step is. How do I apply the converter? Also, the converter file here appears to be for the MTG035 instead of the ZY-M100. Will this also work for the ZY-M100, and if not, where to find the appropriate one (or how to adapt this one)?

jvdburgt commented 3 months ago

Oh, and do the sensors need to be connected when the vendor pushes his update? In other words: is it a live update, or is it merely put available on your account, to be updated at the user's convenience?

I'm asking since I have a string of these sensors connected now for over a week, doing nothing but congesting the zigbee bandwidth while waiting for the update.

LeeWiu commented 3 months ago

If the device is still connected to tuya gateway, check manually if v1.0.5 or newer update it's available.

jvdburgt commented 3 months ago

If the device is still connected to tuya gateway, check manually if v1.0.5 or newer update it's available.

Connected but no update available. They're still at v1.0.2

pniewiadowski commented 3 months ago

v1.0.5

Is it for MCU or Zigbee Module? I mean I can see in Smart Tuya app: Zigbee Module V1.0.6 and MCU V1.0.2

LeeWiu commented 3 months ago

If the device is still connected to tuya gateway, check manually if v1.0.5 or newer update it's available.

Connected but no update available. They're still at v1.0.2

Did you contacted the seller to send the update?

jvdburgt commented 3 months ago

If the device is still connected to tuya gateway, check manually if v1.0.5 or newer update it's available.

Connected but no update available. They're still at v1.0.2

Did you contacted the seller to send the update?

Yeah, they're working on it, but no timeline yet. Hence my question if my devices should stay online while awaiting the update.

LeeWiu commented 3 months ago

I guess so, mine was updated in about 24 hours after providing ID

itwtds commented 3 months ago

Can any of you with the hub awaiting an OTA make sure to grab the FW file and share it in zigbee-OTA repo? https://www.zigbee2mqtt.io/advanced/more/tuya_xiaomi_ota_url.html

jvdburgt commented 3 months ago

Can any of you with the hub awaiting an OTA make sure to grab the FW file and share it in zigbee-OTA repo? https://www.zigbee2mqtt.io/advanced/more/tuya_xiaomi_ota_url.html

I'm very happy to do this, but I'm a bit confused as to what I should do now. I'm waiting for the FW update to be pushed by the seller, right? And this update will either be installed automatically, or I'll do it via the Smartlife app when it is available. But then what? How does the Zigbee ota-repo fit in to all that? What should I do (and when) step-by-step?

itwtds commented 3 months ago

Can any of you with the hub awaiting an OTA make sure to grab the FW file and share it in zigbee-OTA repo? https://www.zigbee2mqtt.io/advanced/more/tuya_xiaomi_ota_url.html

I'm very happy to do this, but I'm a bit confused as to what I should do now. I'm waiting for the FW update to be pushed by the seller, right? And this update will either be installed automatically, or I'll do it via the Smartlife app when it is available. But then what? How does the Zigbee ota-repo fit in to all that? What should I do (and when) step-by-step?

Great. Have a look at the link I posted above, it'll give you a step by step of what you need to do. Basically you need an emulator with the correct/linked APK installed where you check for updates (through the emulator, not your phone) and then capture the traffic via the mitmproxy.