Not really, something major would need to happen in pyd files for it to suddenly fail. To put it into perspective, those files alone haven’t changed in 5 years.
It’s enough that HA will change its API breaking the compatibility. Does depreciation policy ensure updating component code to be up to date with API or compliant with other requirements?
What are you talking about? Who said anything about changing an api? Are you on this forums just to give people grief? Next time you feel like replying to me with nonsense, just move on.
You said
The only way Legacy ZWave (1.4) is getting deprecated is if it stops working. This will only happen at major python releases. When python 3.8 is removed from HA and 3.10 is added, that’s the next barrier. I highly doubt Legacy ZWave (1.4) will stop working then. You most likely have years before that integration stops working.
I’m asking if is it really the only case it might stop working.
Yes, it is. It’s stuck using OpenZwave 1.4, so the pyd files are static because openzwave is static. Everything from that point upwards (the integration) is still being maintained.
Initially I did understood “depreciation” differently. Now it’s clear.
Thanks for answer.
This is a ‘special’ deprecation. Normal deprecations are announced and then axed at a later date. Zwave legacy has no ‘axe’ date and there are no plans for an axe date. When it stops working is when it will be removed. This is the only deprecation like this, mainly because it’s so widely used. The deprecation was not by choice either, it was forced on HA by OpenZwave.
1 Like
I hope that is done as that is how openhab does it. Most users of openhab don’t update the core very often and it just keeps working, should a new integration come along you can keep the stable core and just drop in the new file in and it works. If an integration has a bug you can drop in the older version with whatever core you want. Mix and match to find the winning combo.
Of course that can make supporting a user a huge pain when they don’t just use the latest version. There are times when an integration requires a brand new core feature and it won’t work on the older cores, so yeah it makes things more complex. I have often found HA to fix one bug I needed fixed but that update broke a few new things so it was like rolling the dice trying to get it all to work.
Just about to turn it back on and roll the dice on it again.
4 Likes
Interestingly, tho, unless something has changed, I believe most of the devs don’t actually use HA OS or especially Supervised. My understanding that most use HA Container or Core.
It seems it’s a recommendation that has limitations or every dev/advanced user would be using it.
I was in agreement with you right up to here.
The issue with that approach is that if you don’t update until you have to then you will be forced to deal with every breaking change in your config for every update you skipped.
It’s way easier to fix them a bit at a time instead of fixing all of them at once.
1 Like
I’d imagine the reason for them using Container or Core is most likely because they are mega nerds that do all sorts of other stuff on the same machine, things not possible with HA OS.
No it is because a venv is easiest to develop on, you don’t need to build a new docker container every time you test some new code.
Right.
Limitations. 
1 Like
To be konest, I have been testing HA again after being away to openHAB for 2 years. I am seriously looking at using Container with HACS.
I try to be somewhere in the middle, i will likely wait until middle to late in the release of a version so other can enjoy flushing out the final bugs
Believe me, here are worse options! The following is my personal experience.
I left HA a couple of years ago when both OA and openHAB were in transition, but the OZW based Z-Wave integration did not support my devices without modification after every update. i moved to openHAB and the excellent Z-Wave developer there was a huge help in getting moved.
OH, like HA basically has a BDFL with a few senior developers but it is all volunteer. IMO the BDFL does not pay much attention to end user needs. Also, except for their equivalent of Integrations,the users are expected to write toe documentation on how to use the system. There always seem to be last minute rushes to add new features just before release. This last development cycle, they broke backward compatibility on a system used to update for new Z-Wave devices, especially the 700 series. The BDFL’s official advice was for the user to wait 3 months for the next “stable” release. I contrasted that with the issue here earlier this year when HA Supervised was announced as deprecated. The developers worked with the user community to help achieve the goals without impacting a large number of users.
So, I am back here testing with zwavejs. I have a different user ID because I had the old one banned to avoid getting the form periodic emails. For those who have been here a while, I wrote the ugly 23 step process to migrate from Python 2 to Python 3.
No system is perfect but I think Ha has a good approach, attracting a low of community development & support. I personally do not use Nabu Casa bu I understand its place in the HA ecosystem.
Na, most use HassOS in some form for production. Core or Container for development because it has easier build processes.
Not anymore, dev container is stupid easy with VSCode and you don’t need to configure your IDE. It’s the recommended route.
HassOS has a way to run dev nightly versions of home assistant. Many devs will use HassOS with dev to run the nightly. It’s like running alpha versions of HA. You can update every night and see what breaks on your production machine and it’s close to your development stream.
EDIT: I’m a little behind atm
I have to disagree. For me HA is a tool that is supposed to work quietly in the background, hopefully making my life more convenient. And not a chore you have to do every month to clean up the mess after some developer decided it was a good idea to break something random. I only update when there’s either a feature I really need or want (hasn’t happened in a while *) or if there’s a serious security issue. I don’t use any cloud integrations, so API changes are a non-issue. I prefer to update once or twice a year or so and treat the update as a completely new product install where some breakage is to be expected.
(*) I sometimes do partial updates by applying certain diffs to the HA sources manually, but that’s probably a very niche use.
1 Like
From my point of view, HA should work only with add-ons and not with integrations in the core.
Every time there is a problem with an integration, you have to wait for an update of the core to fix the problem. This forces to update the core too often…
It would be much easier just to update the add-on in case of a bug introduced by an update of the add-on.
Integrations should not be part of the core, there is something wrong with the current architecture.
3 Likes
The downside to not updating is that one day you probably will have to and then you have a blizzard of stuff to either fix or resolve as either it no longer works with that integration or a standard changed and needs to be updated to meet compatibility standards.
1 Like
still it’s a lot more work to update weekly. A looooot more, I can attest. Currently on 2021.11.5… it’s been six months without headaches, breaking changes and whatever. Plus this’ been answered already above, you are 10 months late.
Yes, I did not read all 96 responses.
People have different ways of working. If you have a stable system and your vendors are not changing their APIs then there is no reason to update. If it ain’t broke, don’t fix it. The family will be happy, and the system will keep on working.
OTOH many people like to get the latest developments/innovations and to keep up with the community and the software, or they might have a device/integration that no longer works due to some external entity changing something (look up darksky or anything made by google in the forum). They will update, some of them will test betas.
Each to their own.