This not exists if you don’t have backup (my case) because of a fresh re-installation.
And for a certain time you don’t have the backup (it expires).
I agree with that and that’s why it is under the responsability of the user. If semver major release have been installed, a user should not go back with a previous major release. Like for all HACS integration and like for all software update generaly speaking.
I think with HAOS it is not possible to do that cause we don’t have access to the addon directory. Am I wrong ?
Version strategies can not be forced.
It is, otherwise I would not mention it.
Look at the add-on dev docs on how to do that.
1 Like
“cannot” means “we don’t want to” or “is not technically possible” ?
Can not, even if the format was forced, there are no way to detect if an author adds breaking changes in a semver patch version
As you bring up HACS, (as the creator of that)I can tell you that adding that possibility there was a big mistake on my part and the data issues I explained above have happened multiple times because of it.
My addons repo was not loaded by SMB. If I add it, I see that it is empty:
Am I missing something ?
Nope, those are your local add-ons.
If you have not added one yet, it is supposed to be empty.
ok. If I install an addon with an old release it will take precedence over the “regular” addon install ?
(like it is the case for custom-components installation which takes precedence over “core integration”).
That is exactly what I needed. Thank for the tips.
I guess we can close this FR if my understanding is right.
It will be a completly seperate add-on
1 Like
This feature save my life so many times (to patch things that the integration team will not patch in core directory). That is not a mistake but a must for me.
I agree this should be done only, at last solution and if you understand what you are doing (and respecting semver at minima).
Thank you for all the explanation, I will try that this week-end.
Have a nice year @ludeeus ! (I love your work on HACS as an integration developper)
1 Like
Hello,
Finally I will not do what is proposed here. Installing an addon in parallel of the official one seems a bad idea in many case. If the addon have some db or some data generally speaking, I suspect it may cause corruption.
So the initial request is still valid: have the possibility to select the release of the addon to be installed.
1 Like
It will cause problems, which is why I specifically mentioned that.
If you really, really, really need a different version and you do not care about the data, you can use any version of any add-on by placing it in the local addon directory with the version modification you want on it.
The same applies to running version x when data is for y as mentioned in the same message Add the possibility to install a previous release of an addon - #4 by ludeeus
I understand but this is the price to pay for having this feature which can “save the life” of the user in some weird cases. Maybe warning the user is necessary for such a feature.
I would like to add this also.
Be able to choose which version of , OS, Core, integration etc. i want to install in Home assistant.
This is most desirable when there are serious bugs in a version that make it impossible to use it fully.
It should be a list of at least 5 of the latest versions.
This is to simplify the way you can roll back to older versions.
1 Like
I think there’s actually two distinct use cases here, one of which may be far less problematic than the other:
- Rollback an add-on to an arbitrary earlier version (e.g. to fix a breaking change)
- Install a newer version that is not the latest version available, but is newer than the current version
I can understand why (1) might be problematic as it’s not always possible to manage arbitrary version rollback, especially for add-ons that hold data. But (2) should be far simpler to achieve as it’s still enforcing a “must be newer than the currently installed version” policy, which would be supported by all addons. It’s just not mandating the very latest version and giving some choice to users.
For me, while (1) would certainly be handy (and I accept could only be achieved with a solid risk of data loss), (2) would allow for a certain conservatism when it comes to add-ons that have a very frequent release cycle, but take an extremely long time / are disruptive to install. (e.g. ESPHome)
I have another use case why I need an older addon version temporarily. I’ve been using z2m for years running natively on a Windows machine using npm for Windows (because reasons beyond this post). That machine has suddenly died. Now I want to migrate my HA+z2m instance to the Virtualization Station on QNAP NAS. Installing HA was easy because I had previous HA instance create weekly backups and auto-upload them to the NAS. But installing z2m addon is a problem now because previous z2m instance on Windows was very old. Z2m does support restoring data from a standalone installation but this requires versions to match. It might work accross versions, but I’m not risking having to re-pair 30+ devices, some of which inaccessible physically. I also might be able to spin up another Windows machine from backup and update npm version there, but previous attempts to run npm update commands on Windows have usually broken something. It would have really be much much easier if I could just select a version of HA addon to install.
Possible change of data structure between versions is exactly the reason why I do need an older version.
It is possible to downgrade a version using this workaround.
Create a partial backup of the add-on you’d like to downgrade.
Untar that backup and edit the addon.json file.
There, you should modify the “version” values (in the case of ESPHome 3 occurrences).
Save the changes, repack the backup, and restore from the modified backup.
Voila! HAOS will redownload the old version and install it, then immediately notify you about a new update.
Of course, test this first in your dev environment, or at least save a full backup. Doing this might ruin your HA install, your host might catch on fire, and your whole neighborhood might explode O.o
1 Like