Koenkk / zigbee2mqtt

Zigbee šŸ to MQTT bridge šŸŒ‰, get rid of your proprietary Zigbee bridges šŸ”Ø
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.81k stars 1.64k forks source link

SPM02V2 Spamming Data and maybe let the Gateway crash and Z2M #22236

Open HobboRobin opened 5 months ago

HobboRobin commented 5 months ago

What happened?

I got for Power Measurment 20 of those [SPM02V2] and they are sending uncontrolled data in the network. Five of them are working without any problem. But when i add moore the network getting slower and crash every few hours.

What did you expect to happen?

Maybe some Kind of controll how often the data get send. Same like the [A1Z]

How to reproduce it (minimal and precise)

Just add the SPM02v2

Zigbee2MQTT version

1.36.1

Adapter firmware version

20230507

Adapter

UZG-01

Setup

Unraid Docker

Debug log

The Log is not showing any data except Timeout after 6000ms when adapter already crashed

mrmaximas commented 5 months ago

Try to flash 20240316 CC1352P7_coordinator_20240316.hex from https://github.com/Koenkk/Z-Stack-firmware/discussions/496 if yours USG-01 with the CC2652P7 It's works! Screenshot 2024-04-17 at 13 56 43

DanielNagy commented 2 months ago

FYI, although i don't have zigbee network crashing, My energy metrics was going screwy. Upon further investigations I noted that this SPM02V2 was flooding requests of like 10 times a second, blowing out the homeassistant statistics database.

I ended up configuring the following debounce setting on this device so the mqtt updates are not as frequent.

I reduces mqtt updates to between 8 and 30 seconds. (I only care about energy for graphs. however i added power and ac_frequency as ignore debounces as well because without them, no values update unless the energy consumed updated, so power/voltage/current etc all flatline)

image

I still imagine this is flooding the physical zigbee network. Wish there was a way to reduce the zigbee reporting period of this device.

HobboRobin commented 1 month ago

I managed to get it not crashing anymoore with moore than 5 Router also in the Network. But it is still making the network from zigbee really slow and laggy. (+- 20 seconds) @Koenkk do you have any solution for this ? I tried also flashing the newest Firmware for my Coordinator but i cant stop the flooding.

DanielNagy commented 1 month ago

I managed to get it not crashing anymoore with moore than 5 Router also in the Network.

But it is still making the network from zigbee really slow and laggy. (+- 20 seconds)

@Koenkk do you have any solution for this ?

I tried also flashing the newest Firmware for my Coordinator but i cant stop the flooding.

They have poor firmware in them. The SPM01V2 has a newer firmware which reduces the reporting rate to every 15 seconds, but you need a Tuya hub to update it. (It doesn't appear to follow zigbee OTA specs)

There is still no new firmware update for the SPM02V2 when I checked the other day to reduce the report rate from flooding the zigbee network.

My SPM01 and SPM02 devices were randomly sending erroneous data. Is yours doing that? Ie something like 40000volts randomly?

image

I've ended initiating a return of all of mine for a refund.

Boertie310 commented 3 weeks ago

Same problem here with the SPM02V2 (and with TS0225 presence sensors, also tuya). You can see it when it updates at the last seen epoch that has waves of many updates in a very short time.

DanielNagy commented 3 weeks ago

@Boertie310 does yours also report random values randomly? like my screenshot above?

Boertie310 commented 3 weeks ago

No i cant find it yet, only the spamming of data. As i take a simple plug i can set some COV Values and min/max sendtimes. But this device seems not to have that.

Koenkk commented 3 weeks ago

AFAIK there is no way to reduce the spamming of this device.

DanielNagy commented 3 weeks ago

AFAIK there is no way to reduce the spamming of this device.

The SPM01 has a firmware update (via Tuya hub) which fixes the reporting to 15 seconds. When I last checked there was no update to the spm02.

I did wireshark to see the OTA process, but it seemed to be using some proprietary update method, instead of the standard zigbee OTA I've seen before.
I did manage to get the download the firmware, but do you know anything about the way the Tuya update works when it's updating the vendors mcu, rather than the Tuya mcu? I assume zigbee2mqtt does not support the non standard OTA Tuya used in this instance.

mrmaximas commented 3 weeks ago

I did manage to get the download the firmware, but do you know anything about the way the Tuya update works when it's updating the vendors mcu, rather than the Tuya mcu? I assume zigbee2mqtt does not support the non standard OTA Tuya used in this instance.

Have you tried mitm for retrieve new SPM01 firmware url? What appVersion do you see for your SPM01 in z2m database.db?

DanielNagy commented 3 weeks ago

Have you tried mitm for retrieve new SPM01 firmware url?

mine was 3.1.1 prior to this update via tuya hub / tuya smartlife app. it then updated to the following

      "url": "https://images.tuyaeu.com/smart/firmware/upgrade/ay1553162414592ZG6Kk/17211854247e38bd26c81.bin",
      "version": "3.1.3"

What appVersion do you see for your SPM01 in z2m database.db?

"appVersion":68,

Not sure thats relavant as both my spm02 and spm01 show the same version.. Seems like the version of the Tuya Module, not the MCU version.

DanielNagy commented 3 weeks ago

Attached is wireshark of SPM01 joining / doing MCU OTA / leaving tuya hub.

set wireshark filter to (wpan.dst16 == 0x720f ) || (wpan.src16 == 0x720f)

@Koenkk, You can probably confirm this isnt a OTA method supported by Zigbee2mqtt. Around packet 1795 is where it starts.

SPM01V2 join, ota, leave.zip

DanielNagy commented 3 weeks ago

Start of MCU firmware file image

Wireshark pcap packet 1975 confirms the same first line of data image

The immediate 2 or 3 (or 4) bytes before the data seem to be the offset address, as that increases by 0x30 bytes each message.

Anyways. I'm fairly confident this is tuya custom ota to upgrade the vendors mcu, rather than the tuya zigbee module itself. @Koenkk will likely confirm this also.

Means you'll need to source a cheap Tuya zigbee hub to firmware update the spm01 to latest firmware that doesnt flood the zigbee network. Unsure if the SPM02 has the same firmware update yet.

didi3r commented 3 weeks ago

I have 8 of these devices to measure the power consumption of my home. When I initially set them they flooded my network and took it down. I had to set up another zigbee network (another z2m instance) and left them there so they do not affect my other zigbee devices.

After I read the above message about there is a new firmware that increases the reporting time to 15 seconds I went ahead and bought a cheap tuya gateway. I can confirm the new firmware let you set a custom reporting interval from 5s to 1hr.

image

After you upgrade the firmware and set the new reporting interval you can pair them back with z2m and the reporting interval will persist. I have set them to report each minute and I was able to pair them to my main zigbee newtwork and it's been working great for the past 2 days.

EDIT: As of today, there is no option to change the reporting time interval in z2m as you would in the Tuya app.

DanielNagy commented 3 weeks ago

After I read the above message about there is a new firmware that increases the reporting time to 15 seconds I went ahead and bought a cheap tuya gateway. I can confirm the new firmware let you set a custom reporting interval from 5s to 1hr.

Is this SPM02? Update wasnt available when I upgraded the SPM01's

Do you have random values reported by any of these? look here for examples i'm seeing. https://github.com/Koenkk/zigbee2mqtt/issues/23291

Zemismart/BituoTechnick are telling me they are unable to reproduce it.

didi3r commented 3 weeks ago

@DanielNagy Oh sorry, no they are SPM01V2.

I have seen spikes in the values on mines but when I investigated it seemed it was because they stopped reporting for a while and when they reported back they reported the accumulated value. I always assumed it was because the zigbee network was so flooded that packages were lost and values never reached z2m. Now that there is no flooding any more I havenā€™t seen any spikeā€¦ but Iā€™ll keep an eye and let you know.

DanielNagy commented 3 weeks ago

@DanielNagy Oh sorry, no they are SPM01V2.

I have seen spikes in the values on mines but when I investigated it seemed it was because they stopped reporting for a while and when they reported back they reported the accumulated value. I always assumed it was because the zigbee network was so flooded that packages were lost and values never reached z2m. Now that there is no flooding any more I havenā€™t seen any spikeā€¦ but Iā€™ll keep an eye and let you know.

Accumilated values on kWh Energy yes.. But, look at my example graphs here.. https://github.com/Koenkk/zigbee2mqtt/issues/23291#issuecomment-2267993147 image

~65000 Volts. Its not a accumilation error. Looking at the debug logs, its a parsing error.

But given you dont see this, Can i confirm what zigbee coordinator you are using? Is it EFR or TI/CC based?

didi3r commented 3 weeks ago

Itā€™s a Zonoff Zigbee Dongle P (CC2652P).

DanielNagy commented 3 weeks ago

Itā€™s a Zonoff Zigbee Dongle P (CC2652P).

Hrm. Are you able to confirm what coordinator revision you are using? Zigbee2mqtt -> Settings (cog icon) -> about tab. image

Really trying to work out why no one else is reporting issues like mine is in that other issue i posted

didi3r commented 3 weeks ago

@DanielNagy I forgot I changed my coordinator 3 months ago to a SMLIGHT SLZB-06 (same CC2652P chip) when trying to figure out why my zigbee network was crashing (which at the end it rurned out to be these energy meters flooding the network) and I never switched back to the Zonoff Zigbee Dongle P.

In case it's helpful here is the revision of this coordinator:

image

DanielNagy commented 3 weeks ago

@DanielNagy I forgot I changed my coordinator 3 months ago to a SMLIGHT SLZB-06 (same CC2652P chip) when trying to figure out why my zigbee network was crashing (which at the end it rurned out to be these energy meters flooding the network) and I never switched back to the Zonoff Zigbee Dongle P.

In case it's helpful here is the revision of this coordinator:

image

Thanks. I'm trying to eliminate potential issues as to why I'm seeing random values daily. I had hoped maybe it was an issue related to the cc2652p chip, but it doesn't appear to be as yours isn't reporting any random values. I had even tried that coord firmware too. I had ordered a efr based coord and hoped maybe that would solve my problems. Back to the drawing board it seems.

DanielNagy commented 2 weeks ago

Ok update. In regard to my erratic values as shown by the screenshot, it was fixed by upgrading the esp32/esphome firmware for my tubesZB Ethernet coordinator. It's been rock solid for over 24 hours now with no erratic values.

DanielNagy commented 2 weeks ago

I have official word from Bituo saying there will be NO OTA fix for the spm02v2 to reduce the flooding reporting period like the recent OTA fix for the spm01v2 due to complications with the Tuya DP point change, and needing some users to press the button to re-pair the device as they experienced two weeks ago with the Tuya wifi version OTA.

They have also said there will be a SPM02V3 which will have the updated firmware.