I’ve upgraded ESPHome to 2024.2.0 and since then I can’t update my Sonoff Pow R2 anymore because ‘update_interval: 30s’ is suddenly an invalid option while it always was there.
Do I need to change something or is it a bug?
Same problem only with Sonoff S31, if you remove the update_interval and then visit the device it is updating continuously. You can change the state of the relay one time then it will not change again.
I took out the update_interval option and coded throttle_average value in the filter option. Like this … (cut/paste from my device yaml, ignore my calibration and lambda stuff)
power:
name: "Device-Power"
id: power
unit_of_measurement: W
accuracy_decimals: 1
filters:
- skip_initial: 1 # Initial reading Not reliable
# Map from raw sensor -> measured value
- calibrate_linear:
- 0.0 -> 2
- 40.943 -> 77.45
- 257.19 -> 473
- 750.315 -> 1370
- lambda: if (x < 3) return 0; else return (x - 3);
- throttle_average: 20s
Removing it allowed the update / installed, but messed up the visit / web page. I could no longer control the relay with the continuous update of the data. You may want to check the web page i.e. visit the device.
Note: this affects other devices which use CSE7766, such as Athom. I have already commented out update_interval and used throttle average under filters. My devices are working perfectly with these small changes. Documentation has been updated and no longer refers to update_interval
Hello @pzijde according to the documents this is a breaking change and not a bug. It is intentional change and the instructions have been updated. Of course, waiting for later versions of ESPHome is sometimes a good idea; but still need to read breaking changes in the EPHome changelog
While breaking changes can be a pain, I found this one to be quite beneficial.
Being able to set different frequencies for updates to different cse7766 sensors (power, voltage, current) is a lot more flexible for the user than the old ‘update interval’ ‘polling’ process.
I really appreciate this change.
hm…
unless i’m missing something this breaking change was notified in a very non-understandable manner.
Changelog says:
The cse7766 can’t be polled, it sends data constantly. The component was averaging the data over the update interval, but that should be up to the user.
So, there’s no direct warning that “update interval” is removed and “throttle average” is the thing to use. I can’t connect “polling” with update interval, and i’m sure that many of you can’t either.
Beside that, on github of this change “breaking change” is NOT ticked, but it’s rather “bugfix (non-breakable change)”
I did read this, but i didn’t take any importance to it since it was “non-breaking” change ticked.
A bit more clear notification (or, in this case, correct tick) of these changes would be very welcome (unless, as i said, i missed something).
I’ll have to get the pins out and refresh this thing, but I’ll wait until the next update. I’m pretty disappointed in this update with the “breaking change” on the interval. Should our expectation be that we can’t safely update, going forward, or is this a one-time thing?
Yup. That’s the exact same thing that happened to me.
Step 1 - Do the update w/ no changes, and see how the throttling isn’t implemented.
Step 2 - Make the throttling changes, push update.
Step 3 - Device bricked.
I’m not going to try it on new devices until I see that an update fixes things.
Yeah my S31 is down hard. I can’t even get it to turn on a connected device. I can’t tell if it’s truly bricked, or the config for the relay isn’t working. I did flash a new S31 with the latest and a simple config. It seems to work just fine but I barely have anything in the config.
It may work but this is what the developers say themselves here on an upcoming reverting release. So it’s better to NOT (have to) implement the change… and not upgrade to version 2024.2.0 at all… like lucky me.
However, what I noticed yesterday: Athom plug users who link to the yaml at Athoms GitHub in their yaml will pick-up the change to throttle_average as Athom has implemented that there.
#6095 was a breaking change that converted CSE7766 to non-polling, but in the process introduced bugs around how energy was handled, and more subtle bugs around the time period that measurements were taken over.
The subtle change in the timing of measurements made certain downstream calculations (specifically power factor and apparent power) impossible to do accurately.
…
As such, this reverts #6095 to restore the old behavior that could be used for downstream calculations.