2023.4: Custom template macros, and many more new entity dialogs!

There is, I was just reading them. 2023.4: Custom template macros, and many more new entity dialogs! - Home Assistant

After py-spy installation to HassOS OdroidC4 it seems not to work.
py-spy commands end with error:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: PosOverflow }', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-maps-0.2.1/src/linux_maps.rs:81:65
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: receiving on a closed channel

Looks like it’s a bug in py spy. They could probably use another trace

In the mean time start with just the callgrind

I think the only way to get in front of these accessibility issues is for someone like you to join the HA beta channel to try to catch some of them before they go live.

1 Like

here the same, upd to 23.4.6 works but manual restart:
Configuration invalid!

Platform error sensor.solaredge_local - Exception importing homeassistant.components.solaredge_local.sensor

solar edge API and modbus seem still to work

Anyone have Tibber Pulse still working after 4.6 upgrade?

Rolled back to 4.5

Shame, your logs would have been useful.

We are now on the 6th dot release over a period of less than 20 days. How on earth can anyone have confidence in the stability of HA and the possibility that another breaking change isn’t going to sneak in?

I run my HA instance under Proxmox, which is really lucky because I do a Proxmox backup of the VM before trying any upgrade. I had to roll this back after a couple of hours. I am not going to try again until we have at least a 2 week gap between dot releases.

Isn’t about time the HA developers introduced an LTS cycle?

Why this? Just stay one month behind the current monthly release and you are fine with your requirements.

Why should other users, who are waiting for fixes have to wait longer, because on the one hand side you want to use the newest release but want less updates?

4 Likes

Minor updates are bug-fix only. No breaking changes.

2 Likes

Without concrete information or saying where you need help makes it just a rant.

A breaking change is a planned thing.

The dot releases are typically all bug fixes.

Breaking changes are mentioned in the release notes.

Of course there could be new bugs. Nobody breaks things here deliberately to annoy users.

1 Like

Well, I read many people HA got broken anyway. So, it’s all depends. Personally, I might be okay, I will make VM snapshot before trying to update. This should be relatively easy to restore.

Also picking up @arganto’s point, HA users are on a spectrum. Perhaps a large group always wants to be on the ‘bleeding edge’, but I would suggest that most want to stay reasonably current but want the HA system to be stable.

This majority should not prevent those who want to stay at the edge, but at least the system should facilitate and support them properly. Most Linux distros address this by having some form of Long Term Support (LTS) release cycle or equivalent. The HA GUI only offers an upgrade to the latest current dot release, through I agree that there is the facility buried in the Common OS Tasks to use the --revision option on the CLI upgrade command. Even so, it is very difficult to work out what is a good stable recent release to upgrade to.

Moving to a Proxmox VM has been a major boon for me as the Rollback now takes under a minute. On the two previous occasions that I’ve had to do this rollback using HA Restore, the entire recovery process took about 4 and 2 hours resp, because in the first of these the system wouldn’t even get to the CLI prompt being available, so I had to do a clean install followed by recovery.

Why on earth does it take you 4 hours to do a clean install?

As already mentioned above no one is forcing you to update. Hang back a major version to the last dot release if you want.

2 Likes

I am lucky enough to be a reasonably experienced Sysadmin who uses HA for home use. I initially used a dedicated RPi4 headless with SSD boot. After attempting to do a routine GUI-based upgrade of core+OS one time, I ended up with a bricked system with no kernel SSH. This 4 hrs was partly my fault as I moved the RPi from my rack to my dev office and did some forensics with a view to analysing to raise a case and perhaps repairing, but in the end I decided that a total rebuild was the simplest approach – hence I had to do two installs: i) a clean install from SD card then migrate to SSD, then ii) once I confirmed that I had a bootable clean HA system,I then restored the last working backup which did a complete reinstall again, this time of my home system. The RPi4 is a lot slower than a decent AMD64 VM. That restore involves not only the HA core but building over a dozen add-on Docker containers.

Yes, some of the elapse was trawling through forum posts and documentation on how to resolve stumbling blocks. On the second failed upgrade, I was familiar with this tedious process so it was a lot more fire and forgot, and it was more a case of then researching what was breaking my system to work out what fixes would be required before doing the upgrade again.

I am not sure how your more typical HA user would have coped with this. Still this experience in my case was a major factor in my deciding to add a Proxmox host to my home system and to my migrating to a HA VM because of its decent backup and recovery capabilities.

I feel that you are looking at this from the perspective of an HA expert. Of course everything is easy if you are deeply involved with the internals or a system. Yes, no one is forcing me to upgrade, but are you implying that the correct choice for the typical HA user is not to upgrade? All of my professional experience tells me that systems should be kept up to date, if not bleeding edge. Two friends who are also HA users haven’t upgraded for well over a year because of this sort of issue and fear of breaking changes.

If as a “typical” user I want to upgrade say to the last dot release of the previous monthly release, then I need to have SSH access; be familiar with the CLI interface; navigate to the release notes documentation; choose the previous month and find the last dot release., then do the CLI upgrade.

This would all be a lot easier if you had a dropdown on the Upgrades-> Core to allow the user to pick the last latest dot release.

5 Likes

Which upgrade caused the issue, the OS upgrade or core upgrade?

You can’t do both at the same time.

Generally OS upgrades can be more problematic.

Attaching a monitor and keyboard to the system may have enabled you to do a simple downgrade of the OS. Alternatively rebooting three times forces a roll-back to the previous version.

No, just you.

3 Likes

@tom_l, It bricked on the OS upgrade, IIRC, the first time – which is why I ended up doing a full rebuild. Also the reason that I moved by RPi out to my dev workstation was to attach a monitor and keyboard to see why it was dying. The latest RO OS image seemed to be corrupted, but your point is apt: there does seem to be a need to attach a physical kbd + monitor to do any low level diagnostics in this case, as the startup didn’t even get to mounting hassos-overlay and hence SSH wasn’t an option here. The second time was a core upgrade, which didn’t get to starting up the supervisor etc. so no GUI was available, and diagnostics had to be through CLI. So yes, after poking around and going through the system logs, it was still easier to restore that last good backup. (And 2 × ha host reboot before the system started cleanly,) I then waited a few months in the hope that whatever caused the upgrade to stall had been fixed.

My HA PRi installation seemed to be fragile. (I had already moved to SSD because I had previously had a decent microSD card based system die on me.) I have only ever had one other RPi4 fail on me because it’s SSD died. The Promox VM install seems more stable and easy to manage: proper remote console access and decent snapshot-based backup and restore.

I am not sure why you say that I am the only user that shouldn’t upgrade. I have a pretty vanilla HA setup with standard community add-ons with things like ZHA, Tasmota and Node-RED integration. Anyway, no need to reply to me on this one further. My suggestion to add a simple GUI-based method to upgrade to last final patch level is there anyway.

Thanks for the “reboot three times” hint. I can’t recall that being documented anywhere.

The easy method to always upgrade to the last stable patch release of the month is to systematically upgrade a few days before the first wednesday of the month.

BUT if a significant number of people start doing that, then most bugs will be discovered much later and we would still have continuous instability.

In my view HA has a too aggresive release cycle. Beta one week before release and releases that are sent out with known severe defects. It would be better to have a much longer time between beta and production. At least 4 weeks.

One could think the Debian route with complely separate stable and unstable releases but home automation is developing in a rapid pace and we all scream to have the latest gadget we just bought supported. I would not want to buy a new Philips Hue bulb a wait a year before it is supported. But a month might be OK

The big problem I have with betas is that there is no way going back without pain. If you run HA in production and try a beta, you cannot roll back without losing data because the storage files and the databases are not backwards compatible. And us that track energy hate to lose weeks of data. The only way to run a beta is an additional installation. But then that does not work well either with both Zigbee and Zwave not being able to have multiple coordinators. So a beta ends up being a subset where you can test mainly UI. And there are many problems running the two at the same time causing automations to cause chaos and a spouse that does not share my hobby to go grumpy. It is hard to be a beta tester. I do it occationally but cannot do it every month.

@nickrout I had a forked version of a custom minecraft component - here: GitHub - amaisano/minecraft-home-assistant: Fork of Home Assistant's Minecraft Integration which I used because the official one didn’t work for our server.

I removed and deleted it from the custom components, and the upgrade went perfectly. Thanks so much for the tips.

1 Like

Then again I am super excited to see that 2023.5.0b0 is released.

1 Like