You can.
I have the same.
The device is live. It works on the Shelly app. It has an IP you can access. Home assistant says it is unavaialble.
I have 78 Shelly devices. A few are now not working since the update.
2 Likes
You prove my point, thanks 
1 Like
I’ve encountered the same problem after updating from 2024.4 to 2024.5.2. Spikes up and down appeared.
In my case my virtual sensors created by doing math on 3 measures from a real sensor (a 3 clamp meter) imported from zigbee2mqtt. Their yaml are like this:
template:
- sensor:
- name: "power_ac"
unique_id: '0a7476cc-d6c1-40ba-8ae1-606518c3497'
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: "{{ (states('sensor.pc321_power_l2') | float(0) + states('sensor.pc321_power_l3') | float(0) - states('sensor.pc321_power_l1') | float(0)) | round(0) }}"
Real sensors are not showing this issue. Values in zigbee2mqtt for the real sensor look ok.
My RGBW LED modules from Fibaro are now shown as covers after updating to 2024.5.2, therefore they are not usable.
Is this a known issue of HA or from zwavejs2mqtt?
Not 100% sure, but the root cause might indeed be the same. My suspect is that, starting with 2024.5, values reported by some sensors have micro-delays, sufficient to mess up operations like yours and mine.
In your specific case, it seems that the value of pc321_power_l1 is getting subtracted slightly before or after the expected timing compared to the other two sensors, causing those unexpected peaks in the chart.
1 Like
Same here, some shellys show unavailable after a HA reboot, not always the same devices.
If you go directly to their ip to manage them, after using them (turn off&on for example) and reloading in HA they usually become available again.
Could be related to ECO mode.
1 Like
It was working correctly till 23:15 when i updated HA.
The clamp sensor had debounce set to 5 in zigbee2mqtt because it sends multiple messages for refresh, usually 3 (for the 3phases/clamps i think)
ECO mode of what?
Shelly devices have an eco mode.
1 Like
Having the same issue. Not sure if related to a Synology or HA update
I think you could negate this issue if you added the availability key to your yaml to ensure the calculation only happens when all contributing sensors are available.
1 Like
I don’t think that’s enough.
If he’s hitting the same issue I see, all sensor are available, the problem is simply that those values are not always in-sync like it used to be before 2024.5, but now come with a micro-delay which is enough to mess up all calculations.
My temporary workaround for this is to add an extra line to filter away unreasonable values.
I’m also experiencing some slowness with this release (2024.5.1).
I have motion sensors that integrates with MQTT, for which I have automations to turn on lights. These automations used to be fast (near instant), but now there is a 1-2 seconds delay from when the event is posted on MQTT until the automation is triggered.
I thought it was MQTT but I have Tasmota devices that are slow as well.
What does “Bumped <something> to <version>” actually mean? Is this just a way to avoid documenting the actual bugfix or change that was implemented? It suggests a mere recompile of binaries in the new release, but if that (implicitly) introduces a change in functionality then that change should be mentioned. Or the guys that do make the effort should stop providing additional detail and we just standardize on the Bump thing.
In sub-release 2024.5.3 you get the following:
- “Bump Yolink api to 0.4.4”
But in the referenced github page “Bugfix” is checked, and it mentions: “This PR is related to issue: YoLink Plug status change not working in Core 2024.5.1 #116799” - “Bump rokuecp to 0.19.3”
But in the referenced github page “Bugfix” is checked, and it mentions: “This PR fixes or closes issue: fixes Roku Progress Bar #107702” - “Bump pyenphase to 1.20.3”
But in the referenced github page “Bugfix” is checked, and it mentions: “This PR fixes or closes issue: fixes Enphase Envoy integration is not showing the readings of the production CT's #114862” - “Bump goodwe to 0.3.5”
In the referenced github page it mentions: “This PR fixes or closes issue: fixes No values from GoodWe Inverter after Update to HA 2024.5.1 #116919” - “Bump pytrydan to 0.6.0”
In the referenced github page it mentions: “The release of a new firmware version (2.1.7) has triggered some new errors (corrected in the upstream library)” and also “This PR fixes or closes issue: fixes V2C #117053” - “Bump deebot-client to 7.2.0”
In the referenced github page it mentions "breaking change, but no checkboxes other than “Dependency upgrade” are checked, and in the additional info it states: “This PR fixes or closes issue: fixes Ecovacs Integration: Ecovacs deebot x2 not available #116922 fixes Ecovacs GOAT G1 (Class: 77atlz) not working #116678 fixes Ecovacs Integration: Ecovacs Goat G1-800 Map not available #116838”
10 Likes
Yep, the release notes inception 
This has come up before. I spent a long time in the IT field, and from my perspective “bump” is short for “I don’t feel like documenting it.” Yeah, I know. These are unpaid volunteers. It’s hard to force them to document anything. But there’s a sense of pride in doing a job right, paid or unpaid.
9 Likes
Agree. But it would suggest that the person responsible for publishing the release has the same lack of interest/pride in what he/she does, because he allows it to happen. We don’t talk about hours of documentation, it took me 10 minutes to click on the links in the sub-release and copy the detail from the respective github pages.
6 Likes
It’s also about signalling what type of work it is, it is much quicker to get a review of a library bump than of feature PR, because it’s much smaller and simpler in nature. Typically there are references to fixes within the PR itself.
4 Likes