2024.5.2 is working better here.
2024.5.0 and .1 are running with high CPU and stucks at all so I can’t operate on frontend. With 2024.5.2 it seems OK now, also with some custom integration with debug errors or open necessary adjustments.
Someone else having problems with the crownstone integration?
After the latest update 2024.5.2 the integration broke and reloading it doesn’t solve it.
Version of what?
1 Like
Sorry, typo HomeAssistant 2024.5.2
Yeah, not sure what’s going on with my Shelly 3EM.
When I first installed this, I thought about a defective device; but after some follow-up with Shelly support, it seems it might be due to my electric system. Perhaps my UPS system or maybe induction devices (induction hob, LEDs spread thoughout my house, etc). In the end, I didn’t feel like rewiring the Shelly 3EM to then discover it’s not due to a defective device. So I came up with some smart templates that can report pretty accurately the consumption of my home.
That said, my HA templates have been working flowlessly for more than a year, and only in 2024.5 I’ve started seeing signs of weirdness. Looking more closely at my data yesterday night, it seems that the high number is due to the fact that the division I’m doing (power/power_factor) is using a fresh power but a power_factor which is 1 second older. So, in presence of power edges (when I turn on the induction hob for instance), this gives a spike. I’ve fixed this by adding an extra line to my template that checks if the division gives a negative or unreasonably high number, I just filter that away, and it seems to be working fine now. Hope this suggestion might help other people facing similar issues.
1 Like
The same issues for this custom component are being reported in the forum on the link above.
If you can’t find a solution there, you might want to raise an issue with the author of the custom component on the link below.
the shelly 1 device was actually on the network (i use a linux box to monitor all wireless IPs, and shelly IP never dropped), but ha was not seeing it consistently with 2024.5.1. I rolled back to 2024.4.4 until Core 2024.5.2 and OS 12.3 came out and decided to update both and give it a try. the issue appears to be resolved.
You can’t have it both ways.
1 Like
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
