Deprecating the original zwave integration

[cgarwood]

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]

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

[balloob]

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]

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

[OnFreund]

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]

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

Just our integration

[OnFreund]

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

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

[pvizeli]

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]

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]

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.

[raman325]

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]

FYI, PR home-assistant/core#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]

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]

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