Deprecating the original zwave integration

cgarwood commented 3 years ago

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, and zwave_js

Proposal

I recommend officially deprecating the original zwave integration. Update the docs to mention that it is legacy, update its "friendly name" from Z-Wave to Z-Wave (Legacy). Update the config flow so if someone adds it we add an extra step that suggests the zwave_js integration instead (as support for ozw is also questionable now).

We should not remove the zwave integration from the codebase until:

A migration tool has been created to help migrate from zwave to zwave_js and a larger than usual number of releases have passed.
Z-Wave JS allows for modifying node configuration from within Home Assistant
Z-Wave JS receives support for garage door controllers
Z-Wave JS receives support for node/scene events

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.

frenck commented 3 years ago

Yes, this is actually already done and reported in the release notes for 2021.2.0.

balloob commented 3 years ago

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.

cgarwood commented 3 years ago

I think at some point it makes sense to clean up and remove, but definitely shouldn't be immediate.

OnFreund commented 3 years ago

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

AlCalzone commented 3 years ago

* 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?

cgarwood commented 3 years ago

Just our integration

OnFreund commented 3 years ago

Does that refer to node-zwave-js or your integration?

The HA integration - that's why I phrased it that way

pvizeli commented 3 years ago

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.

pfunkmallone commented 3 years ago

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.

TheDK commented 3 years ago

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.

Mariusthvdb commented 3 years ago

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.

raman325 commented 3 years ago

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.

Hedda commented 2 years ago

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

TheDK commented 2 years ago

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%.

cgarwood commented 2 years ago

And with the deprecation and removal in 2022.4, I think it's safe to say this can be closed.

home-assistant / architecture