Open seblu opened 1 year ago
Great solution! Can you send me more info about how to do the retro fit?
Thanks in advance
Cheers
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
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... 🤷♂️
I just bought a new device Tuya ZG-205Z/A and as you can see the spam messages are still but less "stormy"
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.
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
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.
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.
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 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
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.
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
Weird, I'm barely getting any data in the z2mqtt log page.
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
Folks, the Last Seen configuration in Zigbee2MQTT has no impact on the Zigbee layer of your setup. This a dead end.
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.
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.
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.
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.
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
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?
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.
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.
@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 :)
@fillwe What is the current firmware version?
Do you remember the previous version?
@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 😕
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? 🫤
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.
Wait a sec, I have the ZY-M100-S2, will this work for them as well?
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.
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?
Yes I believe so, but not 100% certain.
@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.
I’ve disabled this device for now due to the annoying report. Looking forward to the OTA update for this feature!!!
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
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
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.
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?
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.
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?
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
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?
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.
@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.
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)?
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.
If the device is still connected to tuya gateway, check manually if v1.0.5 or newer update it's available.
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
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
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?
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.
I guess so, mine was updated in about 24 hours after providing ID
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
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?
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.
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:
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