Also had to revert to 2022.12.19, both 2023.1.1 and 2023.1.2 breaks the DSMR integration over here
2023.1.3 is out according to GitHub and the website, but no one seems to get them:
{
“channel”: “stable”,
“supervisor”: “2022.12.1”,
“homeassistant”: {
“default”: “2023.1.2”,
“qemux86”: “2023.1.2”,
“qemux86-64”: “2023.1.2”,
“qemuarm”: “2023.1.2”,
“qemuarm-64”: “2023.1.2”,
“generic-x86-64”: “2023.1.2”,
“intel-nuc”: “2023.1.2”,
“khadas-vim3”: “2023.1.2”,
“raspberrypi”: “2023.1.2”,
“raspberrypi2”: “2023.1.2”,
“raspberrypi3”: “2023.1.2”,
“raspberrypi3-64”: “2023.1.2”,
“raspberrypi4”: “2023.1.2”,
“raspberrypi4-64”: “2023.1.2”,
“yellow”: “2023.1.2”,
“tinker”: “2023.1.2”,
“odroid-c2”: “2023.1.2”,
“odroid-c4”: “2023.1.2”,
“odroid-n2”: “2023.1.2”,
“odroid-xu”: “2023.1.2”
},
Am I the only weirdo wondering why? 
4 Likes
2 Likes
For us newbies this ”disable polling at system settings and then just set an update entity automation” seems about as stupid as it gets. Previously it took a second to set the interval to what ever I wanted (4 times a day) but now I had to browse through all of the Settings > System looking for something about ”polling”— and then spend 10 minutes googling that the right place is actually behind the three dots of that entity(!). Setting up automation then took just a few more minutes, trying to find an action with something about ”update”. Then I still had to learn a little about time patterns to know that I need ”/” symbol to the hour setting or else it would run just once a day.
And the reward to all this time wasted (well I learned a little in the process)? This whole thing does not even seem to work anymore! I mean, what is wrong with this? (even tried adding the entities there but no help)
Incredibly frustrating!
alias: SpeedTest
description:
trigger:
- platform: time_pattern
hours: /6
condition: []
action:
- service: homeassistant.update_entity
data: {}
target:
device_id: f30b10b8d751c44fe9d700f95931e243
entity_id:
- sensor.speedtest_download
- sensor.speedtest_ping
mode: single
Edit:
I can see this in the logs. No idea what ”extra keys” it is talking about. I suppose the ID should be correct as it’s added by UI. Even tried adding the device again (deleting the entities)
Stopped because an error was encountered at 11.1.2023 18.27.49 (runtime: 0.01 seconds)
extra keys not allowed @ data[‘device_id’]
7 Likes
Try this.
action:
service: homeassistant.update_entity
data:
entity_id: sensor.speedtest_ping
Copied from Central Command - 6th Jan.
The clue is in the name - update_entity not update_device.
1 Like
Having just encountered this myself, it would be useful to allow specifying a device to mean “update all entities for this device”, as it isn’t at all obvious that updating sensor.speedtest_ping will also cause sensor.speedtest_upload and sensor.speedtest_download to be updated also, or if you need to specify each entity individually, or…
(Well, I mean, it’s obvious to me, since I know how Speedtest works. It’s not obvious to the modal user.)
This has been dealt with by @CentralCommand elsewhere in the thread.
Basically see if all entities in a device update at the same time. You can see that on the device page in the logbook. If they all update simultaneously, it is likely you only have to update one entity to do them all.
1 Like
Does anyone else suffer from HACS not showing updates?
I found out about it when I restarted HA and there were like 5 updates waiting in HACS, nothing showing during proper usage. This wasn’t an issue before 2023.1.x
No issues with HACS updates here. Running 2023.1.2
Not sure what you’re talking about here. Hac’s has never shown updates from the main page, you always have had to go into the community tab. Can you elaborate on what you mean?
I am not talking about showing them from the main page. I mean in the “community tab”.
Clicking on the HACS icon in sidebar. There are no updates. From 2023.1.x I need to restart HA to HACS show me there is an update.
HACS only checks once and a while, a restart triggers the check. It’s always been like this
IIRC it’s every 6 hours? I can’t remember. It’s not often though.
1 Like
Yes I’ve noticed this too (anecdotally anyway)…updates are/seem slower to present as ready to update if they show up at all.
I’ve created an automation to reload HACS periodically and this circumvents the issue for me as updates appear once HACS is reloaded…
Just spoke with the HACs dev. He changed the update frequency, so this is unrelated to 2023.1
Edit: HACS checks every 48 hours now.
6 Likes
You probably shouldn’t do this if you want HACS to continue to exist. The reason the update cycle was slowed was because github itself complained:
If people speed it up again then they may shut it down or put it new limits/checks that cause breakages for everyone.
8 Likes
And really, who needs to sit there all day waiting for custom integration updates…
3 Likes
Would guess it’s the same cohort who wait around this forum to post marginally helpful/relevant comments…all human life is here so who knows 
@CentralCommand thanks for that…automation was only firing once per day but will disable and let nature take its course 
2 Likes
after the update my RPI 3b+ is in a loop of lost connection, it happened in every update. 2023.1,2023.2,2023.3, what is the problem, tried 2 RPI 3b+, using SSD.