Open HobboRobin opened 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!
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)
I still imagine this is flooding the physical zigbee network. Wish there was a way to reduce the zigbee reporting period of this device.
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.
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?
I've ended initiating a return of all of mine for a refund.
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.
@Boertie310 does yours also report random values randomly? like my screenshot above?
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.
AFAIK there is no way to reduce the spamming of this device.
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.
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?
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.
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.
Start of MCU firmware file
Wireshark pcap packet 1975 confirms the same first line of data
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.
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.
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.
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.
@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 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
~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?
Itās a Zonoff Zigbee Dongle P (CC2652P).
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.
Really trying to work out why no one else is reporting issues like mine is in that other issue i posted
@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:
@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:
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.
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.
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.
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