I wanted to report another potential firmware bug related to the reported energy on a VZM30-SN. I use the switch with HA Z2M. Please see the images below for some sample datasets.
Thank you!
Summary:
Switch’s reported energy is off by several orders of magnitude compared to energy as by the reported instantaneous power signal (8.5kWh vs 324Wh in one example below)
Switch’s reported energy continues to climb by multiple kWh (3kWh over 4 hours in lower example) despite being at idle power draw for the entire duration
I did a crude cross check at my meter and this does not appear to be a real load. I haven’t reopened the wall and measured with my current clamp yet
Switch’s reported energy alternates between climbing at a high rate (~500-1000W) or flattens (expected) during a continuous period of idle power draw
I’m experiencing a problem with the reported power usage, as well.
I installed two VZM30-SN switches yesterday and another two today. I’m running Home Assistant v2025.7.1 with Z2M. In the Energy page of HA, the reported usage of the new switches is definitely wrong. For example, it claims that the switch that powers an LED bulb in the kitchen has used 11.50 kWh today (and climbing). For comparison, the kitchen fridge, which is typically the most power hungry device in my place, has used 1.732 kWh.
This doesn’t seem to be affecting the “Net consumed from the grid” metric, but metrics for “Individual devices detail usage” and “Individual devices total usage” are way off.
Thanks for reporting that you’re seeing the same behavior mcantu! I haven’t installed my other VZM30 switches yet so I wasn’t sure if this issue was isolated to the one I had installed.
In case you’re interested in a workaround, you can add a helper “integral sensor” entity based on the instantaneous power signal reported by the VZM30. That will give you a pretty close approximation of what the switch’s energy signal should be reporting.
@Bengineer@mcantu Thank you for the info and the details! I’ll run this by our engineer to see what is going on. From what I am seeing the power reporting looks fairly accurate (W), but the energy reporting is not right. Is that what you are also seeing?
You bet, happy to help! That’s correct, the instantaneous power (W) signal is about what I would expect but the cumulative energy (Wh) is off by a factor of 20-30x depending on the example.
Just a theory, it almost behaves like the accumulator is assuming the wrong rate or scaling when accumulating the power signal. Presumably the energy is derived off of the instantaneous power + some assumptions about idle consumption.
I’m seeing the same behavior on my two VZM30-SN’s. One for an 18W bathroom fan (7.9kWh after running for ~12 hours), and one for ~150W of garage lighting (112kWh after a few weeks of intermittent usage).
I’m running “raw” zigbee2mqtt with no HA, so I don’t think HA is a possible factor. Unsure whether there’s a conversion issue with how z2m parses the value, or a firmware issue down on the switch.
BTW: curious as to how the accumulator data gets stored on the switch so that it doesn’t wear out the flash/EEPROM with excessive write cycles?
I’m curious about this as well! I would assume (and hope) that it’s either flushed to non-volatile memory at a low frequency (either periodic or based on value meaningfully increasing) or they’re leveraging high endurance non-volatile storage technologies (e.g. MRAM/FRAM). The latter seems less likely.
My concern would be if the flush is triggered off of an energy value threshold, rather than time/frequency. If that’s the case, the non-volatile memory is probably getting hammered at the moment.
I wonder if disabling the energy reporting on the frontend (ActivePowerReports) causes the backend to be disabled as well?
Similarly, I’d wonder if repeatedly toggling e.g. AutoTimerOff 100 times a day (in response to, say, a PID control loop running on a RasPi) would cause fatigue on whatever EEPROM cells are storing that setting. The engineers designed it to be a persistent setting, but in my application I’m constantly toggling it. Presumably every toggle causes another write.
I am using my new VZM30-SN relay switches to build a setup where:
If the fan is off, the user hits the paddle switch and it runs for 15 minutes (ventilation). AutoTimerOff is set to 900 in that case.
My home automation setup sometimes wants to run the fan for extended periods of time to bring in fresh air, so it disables AutoTimerOff until it’s done.
I think 100 times a day is probably not an issue. I send lightbar notifications to blue/red dimmers roughly 70-100 times a days (all of which rewrite memory when the parameters are updated) as well as update the parameter for the turn-on brightness 4x a day. I’ve been doing this since the Blue dimmers came out (~2 years ago) and not had a single switch die yet.
@EricM_Inovelli can probably speak to what the design lifespan is but I would guess that they’ll probably be able to handle that workload for 5+ years.
Many common NOR flash and EEPROM devices are rated for ~100k program/erase cycles. If the firmware is simply rewriting the same block on every parameter change, 100 writes per day would hit the limit in about 3 years.
However, if the logic was designed to spread the wear out across multiple blocks, it could potentially handle millions+ of updates.
If it’s NAND flash, it probably already uses leveling due to the need to work around bad blocks.
(Side note: my Pioneer car stereo puts a read/write ext4 filesystem on raw SPI NOR flash. It writes to this filesystem whenever you change the radio channel or play a new track over Bluetooth. This is an extremely bad and not-recommended design, but so far it’s lasted 7 years and counting. Quite possibly it will outlive the vehicle itself. So YMMV)
Heat is a contributing factor; it’s possible that relay based switches would last longer than triac based.
I spoke with the engineer about storage writing and he anticipates that the storage should last for 10 years or more. This was his statement:
"Data from Silicon Labs indicates that flash data retention can last up to 100 years. Moreover, since flash memory requires both erasure and writing operations, typical flash supports around 100,000 erase cycles. On our switches, flash data storage is implemented with wear-leveling technology to extend the memory’s durability. In theory, it is capable of sustaining tens of millions of on/off state recordings. Under normal usage, flash lifespan should not pose any issue within a 10-year period."
We haven’t had any issues with the VZM31 yet and it has been on the market for almost 4 years now (I think).
I do have a firmware update that fixes the inaccurate energy accumulation. Usually we have a few people test it out before making it publicly available. If you would like to test it please let me know.
Yeah, it is the version but it is in pre-beta right now. Reports are that it doesn’t fix the energy measurement fully, but I still need those that are testing it to try a factory reset and test again.
This bug seems to be fixed in firmware 1.01. You may need to factory reset and re-add (and run “configure” if it doesn’t automatically run). Update should be available in z2m tomorrow.
This switch is configured in smart bulb mode. There is a downstream ceiling fan that is off most of the time, and a smart outlet powering some LED lights that is also off most of the time. Everything was off in the period shown in the second graph above.
What steps should I take to try and get this working properly?
