Red Series Dimmer loaded with V1.47.otz and V1.47.bin. I’ve been noticing in the log file that I’m getting bursts of Energy reports like the ones below. In this case its 7 reports all within a second and all with the same value. Parameter 20 is set to the default of 10 which should mean a 10% change in energy value is needed before sending a new report. Why are there so many all in succession and all the same?
2020-08-22 06:39:59.631 pm [info]Fireplace light: Energy report received with value of 0.541 kWh
2020-08-22 06:39:59.562 pm [info]Fireplace light: Energy report received with value of 0.541 kWh
2020-08-22 06:39:59.516 pm [info]Fireplace light: Energy report received with value of 0.541 kWh
2020-08-22 06:39:59.160 pm [info]Fireplace light: Energy report received with value of 0.541 kWh
2020-08-22 06:39:59.029 pm [info]Fireplace light: Energy report received with value of 0.541 kWh
2020-08-22 06:39:58.828 pm [info]Fireplace light: Energy report received with value of 0.541 kWh
2020-08-22 06:39:58.823 pm [info]Fireplace light: Energy report received with value of 0.541 kWh
Adding to the thread that its not just Energy (kWh) reports but also Power (W) reports. Should only be reporting if the value changes 10% but I always seem to get these in bursts. In this case I got 14 duplicate power reports all within 5 seconds. Seems like this is overly chatty and excessively consuming z-wave bandwidth. Shouldn’t Parameters 18-20 be limiting these so they don’t bog down the system?
2020-08-23 11:22:19.922 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:19.835 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:19.667 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:19.664 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:19.659 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:17.785 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:17.680 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:17.594 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:17.532 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:17.409 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:17.109 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:14.900 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:14.803 am info Dining light: Power report received with value of 0.0 W
2020-08-23 11:22:14.753 am info Dining light: Power report received with value of 0.0 W
I think a couple things might be going on here. First of all can you verify that you are setting the value to 1? That would actually be a 1% change which would result in more reports. 10 (10%) is the default.
The other thing is that I have seen Hubitat not respond quickly enough via an ACK packet resulting in the switch sending multiple reports. This is part of the Z-Wave SDK to counter packets being lost. So if an ACK is not received in time, another exact report is sent.
Also, what load is on the device and what other settings are there? For example bulb specs, 3-way settings, neutral vs non, etc. I can try to replicate what you are seeing.
Sorry that was a typo in my original post. Param 20 is set to 10 (not 1) and verified in the Hubitat Device report.
All my loads are LED lights but they vary in style depending on the fixture (Fireplace Light is a LED can and Dining Light is LED candelabras). All my inovelli switches are neutral wired and have AC Power Type set to “neutral”. Some are 3-way with dumb switch (“3-way toggle”) others are Load only. I don’t yet have any that are “3-way momentary”
After I originally posted (a few weeks ago) my HE hub has been updated to v2.2.3.145 and it seems to have eliminated (or reduced drastically) these multiple energy reports . So it does seem like there was something going on with the hub not sending ACK’s quickly enough. But still, shouldn’t parameters 18-20 have been stopping all the duplicates and throttle the rate at which they were sent?
I may have spoke too soon. The multiple energy reports are back. When I noticed this, I rebooted the Hub to start fresh and still seeing these bursts of reports.
2020-09-11 08:30:47.440 am info Front Porch Light 2: Power report received with value of 0.0 W
2020-09-11 08:30:47.320 am info Front Porch Light 2: Power report received with value of 0.0 W
2020-09-11 08:30:47.212 am info Front Porch Light 2: Power report received with value of 0.0 W
2020-09-11 08:30:46.950 am info Front Porch Light 2: Power report received with value of 0.0 W
2020-09-11 08:30:46.646 am info Front Porch Light 2: Energy report received with value of 10.210 kWh
2020-09-11 08:30:46.617 am info Front Porch Light 2: Energy report received with value of 10.210 kWh
2020-09-11 08:30:46.596 am info Front Porch Light 2: Energy report received with value of 10.210 kWh
2020-09-11 08:30:46.523 am info Front Porch Light 2: Switch Multilevel report received with value of off (0)
2020-09-11 08:30:46.512 am info Front Porch Light 2: Switch Multilevel report received with value of off (0)
2020-09-11 08:30:43.842 am info Front Porch Light 2: Switch Multilevel report received with value of off (0)
2020-09-11 08:30:43.784 am info Front Porch Light 2: Switch Multilevel report received with value of off (0)
2020-09-11 08:30:43.774 am info Front Porch Light 2: Switch Multilevel report received with value of off (0)
2020-09-11 08:30:43.768 am info Front Porch Light 2: Switch Multilevel report received with value of off (0)
2020-09-11 08:30:40.100 am info Front Porch Light 2: Switch Multilevel report received with value of off (0)
It definitely seems like the reports are being sent via the SDK as part of the Z-wave protocol. In your second post though it looks like it is a combination of two issues. The ACK issue mentioned and the internal report suppression that firmware 1.47 should be stopping. I have a couple theories. First, I wonder if the bin file got flashed fully. There isn’t a way to verify it as of right now, but did you use the Hubitat Z-Wave firmware updater? You might want to try the flash again.
Second, I have done most of my upgrades via the Z-Wave PC controller software. Because of this I have had to exclude and include resulting in a factory reset. I wonder if a factory reset on the device would fix the issue. Can you try that on one of the devices to see if that makes a difference?
Prior to my original posting, I used the Z-Wave PC controller to update all my Inovelli Red Series to 1.47.otz and 1.47.bin I went through the pain of excluding them from Hubitat, Including them to the Z-wave PC Controller (as its own primary) and updating both targets. I’m aware of the .bin flash sometime not working. The failed update can be seen on the Z-Wave PC Controller as it returns immediately without copying data blocks and showing a progress percentage. I watched that pretty closely when I sat down on the mission to update all my switches. I did about 25 switches all in succession, so its possible I didn’t catch a .bin failure in one or two cases, but very unlikely that applies to all of them and they all seem to do it. (although not all the time as it appears to be exacerbated by something with the hub). In all cases, a factory reset was done on all switches.
I do not really want to exclude/reset/reload/include again at this time since I went through that pain recently and I don’t want to rebuild all my rules…again…not just yet anyway. I can try using bcopelands firmware updater to reflash the .bin on one of them and see if it makes any difference. Its slow and doesn’t give good progress status, but it shouldn’t break my existing rules so it should be a relatively painless test.