Closed cgarwood closed 2 years ago
Yes, this is actually already done and reported in the release notes for 2021.2.0.
I don't think that we should remove zwave
from the codebase but just leave it "lingering". We should set config_flow: false
so that it will no longer show up in the UI. Users can then set it up by using the YAML config which will be imported.
I think at some point it makes sense to clean up and remove, but definitely shouldn't be immediate.
We should not remove the zwave integration from the codebase until:
I would also add:
* The Z-Wave JS integration supports some polling mechanism for legacy devices
https://github.com/zwave-js/node-zwave-js/blob/master/CHANGELOG.md#features
Z-Wave JS receives support for node/scene events
Does that refer to node-zwave-js or your integration?
Just our integration
Does that refer to node-zwave-js or your integration?
The HA integration - that's why I phrased it that way
I don't think that we should remove
zwave
from the codebase but just leave it "lingering".
maybe not right now, but we should. Not sure how long we could distribute it for future python version. The build of the package is horrible.
Just putting my 10 cents in; I still run the original zwave integration because from my perspective the OZW integration hadn't met parity with it yet. Between stability issues I saw people having, missing Lovelace configuration tools and hints that a migration tool might be coming (to help syncing the entity names). Unless this is really necessary (ie, the zwave integration is actually BROKEN by other changes), I'd vote for keeping it until the newest integration at least gets closer to parity. Otherwise, I'll have to migrate twice...once to OZW, then again to zwave-js when they get garage doors, device parameters, etc. working.
I would hope that an actual removal would a) be massively communicated at leat several weeks (better months) in advance so people with large networks can start the move to js-server (hopefully without going through MQTT before) and b) happen only if the new js-server based integration does not lack significant features that the ozw 1.4 based zwave integration has.
talking about the architecture of both core Z-wave integrations, (the now deprecated and the new JS) from a user perspective one of the main huge changes in features is the loss of the zwave
domain, and no way to check the 'modules' from that domain in the Frontend/ States
Is this something the team is working on? If not, please allow me to bring it to your attention here. The Modules we're a great way of seeing what was happening in the Z-Wave network, and be able to interact, heal, check etc etc.
Fully aware this is a brand spanking new integration/add-on, and fully appreciative of its current operability and flawless update, for which I applaud all contributors! So not (yet) a feature request, merely trying to help in this architectural exchange of thoughts.
can we deprecate ozw
? Analytics show ozw
usage at ~ 1/3 of the zwave
integration. Seems to me like it's better to deprecate sooner rather than later.
FYI, PR https://github.com/home-assistant/core/pull/56159 looks to want to make these related changes but no migration from ozw
to zwave_js
as of yet:
Proposed change
- Add migration support for legacy Z-Wave to Z-Wave JS integration.
- Remove migration support for Z-Wave to OpenZWave integration.
- Migration mapping is limited to values we can resolve in both Z-Wave and Z-Wave JS. Eg we can not resolve two values in Z-Wave JS which have the same property name but different property key name since there's nothing on the Z-Wave side to map to property key name on the Z-Wave JS side.
- If we find more information to help resolution we can improve this in the future.
There are however community guides for switching from OpenZwave (beta) to Z-Wave JS / ZwaveJS2MQTT (Websockets / MQTT)
https://community.home-assistant.io/t/switching-from-openzwave-beta-to-zwave-js/276723
https://community.home-assistant.io/t/switching-from-openzwave-beta-to-zwavejs2mqtt/276724
I have been migrating ~ 1/3 of my nodes to a different RasPi / Controller running Z-WaveJStoMTT connected via Z-Wave JS integration / Websockets (no MQTT) and would say, that at least that seems to be mostly stable / ready as the figures above suggest. I plan to switch over the rest sometime in October.
As this can be quite some manual work (depending on how the migration support works...) it would appear sensible to announce the deprecation with the next release and then remove support with 2022.1 - giving everybody 3 months to do the transition.
I find it fascinating that only ~12% of installations use Z-Wave at all - my guess would have been in the range of 30-40%.
And with the deprecation and removal in 2022.4, I think it's safe to say this can be closed.
Context
The original
zwave
integration is based on OpenZWave 1.4, which hasn't been maintained since OpenZWave 1.6 was released in May 2019. The integration is also based on a python library that hasn't been maintained in an even longer amount of time. As such, it is lacking support for a number of new Z-Wave devices and features.We now have 3 core Z-Wave integrations:
zwave
,ozw
, andzwave_js
Proposal
I recommend officially deprecating the original
zwave
integration. Update the docs to mention that it is legacy, update its "friendly name" fromZ-Wave
toZ-Wave (Legacy)
. Update the config flow so if someone adds it we add an extra step that suggests thezwave_js
integration instead (as support forozw
is also questionable now).We should not remove the
zwave
integration from the codebase until:zwave
tozwave_js
and a larger than usual number of releases have passed.Consequences
Better user experience, as people starting out won't start out with an integration that hasn't been updated in 2 years. Allows us to simplify the documentation, and eliminates a number of the questions on Discord and the forums about which integration is best/why doesn't device
x
work/etc.