search

home-assistant / architecture

Repo to discuss Home Assistant architecture
313 stars 100 forks source link

Move Z-Wave support from OZW to zwave-js #483

Closed marcelveldt closed 3 years ago

marcelveldt commented 3 years ago

Context

Currently a new Z-Wave integration is in the making, based on OpenZwave 1.6, using the "OpenZwave daemon" as intermediate bridge with mqtt as communication protocol.

While development had a flying start we're at a point there are multiple issues why I'm proposing to revisit the choice for OpenZwave(QT):

There's a lot of reason to doubt if we're betting on the right horse with OpenZwave (daemon) for what's supposed to be the "shiny new" Z-wave integration for Home Assistant that should finally make the Z-Wave experience rock-solid.

This leads to frustration both with the devs actively working on it and the community. There must be an evaluation of alternatives and that's where this proposal is all about.

Proposal

For implementing Z-wave there are unfortunately limited options. The only opensource library that ever existed was/is OpenZWave, except that it's python wrapper has gone stale. Really the best option would be to create a Z-wave driver completely written in python but that will require a busload of developers and time to pull off.

Recently a new opensource Z-wave implementation has seen the light: Zwave JS. A driver written from the ground up in javascript/typescript gaining a lot of traction:

While this project is (just like OZW) also primary developed and maintained by a single developer (Al Calzone) it is more likely that others will help out. Even most of the Home Assistant devs/contributors know their way in some javascript/typescript.

A few members of the small team that was/is actively developing the new OZW integration for Home Assistant has explored options the last couple of days and exchanged thoughts with the developers of Zwave-JS. Even though it means that we will have to smash 70% of our work from last year in the trash, we still think we should make the switch (now we still can) to Zwave-JS instead of OpenZwave, how harsh this may be for both Fishwaldo (developer of OZW) and everyone contributing to the new integration.

Consequences

PRO: The actual interaction with the Z-wave stick/device will still be detached from Home Assistant but this is a good thing as this will not restart the Z-wave mesh while Home Assistant is restarted, so that will stay.

PRO: Instead of talking over MQTT to the OpenZwave MQTT daemon, a "ZWave server" will be written which can be fired up in it's own process (as docker image, addon etc.) and it will be the bridge between Z-Wave hardware and Home Assistant. In fact this bridge will serve any client interested in utilizing the Zwave mesh. For example Zwave-to-mqtt and Home Assistant can be used side by side.

PRO: because of the above mentioned an MQTT broker is no longer a hard requirement which reduces the complexity, especially for new (less tech) users. we can manage the entire path automatically.

PRO: As we have the ability to actively work with the developers of Zwave JS and we have knowledge of the upstream code we can actually contribute in fixing stuff upstream.

PRO: Zwave JS has some features that are not supported in OZW such as firmware updates. Also from a first impression it seems to be a bit faster and stable.

PRO: No more instability issues with the zwave daemon that was haunting many users.

CON: Zwave JS is still missing support for a few command classes/devices such as garage doors but this could be easily added by us or any contributor.

CON: A fully automatic migration of legacy/current ZWave in HA to this new implementation will be more complicated because of the fact that the internals are handled differently.

I'm for sure missing a few points here but the bottomline is that the overall feeling by me and a few others is very solid to make the switch.

read all about Zwave JS here:

https://zwave-js.github.io/node-zwave-js/#/README

balloob commented 3 years ago

Starting over is painful. It was painful when we started ozw in 2019 and it will be painful again. But I agree that we're not currently in a good position to continue its development.

A note here that this proposal is about introducing a new integration (domain TBD) maintained by the people working currently on the ozw integration and add-on. The OZW 1.4 integration (zwave) and OZW 1.6 integration (ozw) will not be removed from Home Assistant.

paularmstrong commented 3 years ago

Thank you so much for putting this together! It looks like you captured the main concerns that I and at least a good portion of the community voiced recently.

I have a couple of clarifying questions: I believe I am reading this correctly, but it would be great to be explicit for some of us:

CON: Zwave JS is still missing support for a few command classes/devices such as garage doors but this could be easily added by us or any contributor.

I started looking at the Barrier class last night and while it looked really straightforward at first, I ran into a lot of questions. They're mostly related to lack of knowledge about Z-Wave in general. It might be nice to not throw out blanked statements saying things are "easy" 😄 , as we're all with varying skill levels and knowledge bases.

cgarwood commented 3 years ago

Does this mean not looking at zwavejs2mqtt?

Correct. With the websocket method we eliminate the requirement of an MQTT broker. It still uses the same zwave-js backend as zwavejs2mqtt.

Does this mean running an addon or will it be a core built-in integration that does not require an addon at all? (eg: the zwavejs node process is run by HA core itself)

Will still require an add-on/docker container (as the entire stack isn't python) but the addon will be simpler (since we no longer need to worry about MQTT)

xAPPO commented 3 years ago

Does not using MQTT mean that this is an implementation tied to a single instance of HA ? Or would we be able to have a network wide ZWave capability availability for multiple automation controllers to use and conversely several ZWave controllers could contribute their devices to one bigger pool of devices ? This seemed like one of the big +’s of openZWave and a reason to consider zwavejs2mqtt.

gdt commented 3 years ago

I think it's important to talk about requirements and in particular security. One of the benefits of MQTT is that it supports TLS and user authentication. Another benefit is allowing separating the computer running Home Assistant and the computer running zwave. While I understand the issues around retained topics, that issue is more of an artifact of a design for sharing information over MQTT than an issue that is necessarily tied to MQTT itself. For example, one could treat MQTT as a reliable datagram protocol to exchange messages, more or less making it like RPC -- which is probably exactly what you plan to do with Websockets.

Another issue is portability to different operating systems. Ideally, all of this should rely only on what POSIX guarantees, and it should be possible to run HA and Zwave on different systems. That's not precluded by a websockets approach, but absent stating the requirement it does not seem safe to assume it will be met. The talk of docker is scary; absolutely there should be no requirement to use docker, although of course if people want to and that's the simplest way to run a program that's fine.

As a thought experiment and historical perspective from someone who has been using Unix for more than 10 years before Linux existed, HA running on an illumos x86 box should be able to work with the zwave code running on a BSD RPI3.

So I'd put it as not only OS independence, but whatever the communication channel is from HA to Zwave it must

cgarwood commented 3 years ago

Does not using MQTT mean that this is an implementation tied to a single instance of HA ? Or would we be able to have a network wide ZWave capability availability for multiple automation controllers to use and conversely several ZWave controllers could contribute their devices to one bigger pool of devices ?

Multiple instances on remote devices will still be possible

FreelancerJay commented 3 years ago

I’m wondering a little about modularity with this as well. Should the interface between HomeAssistant and whatever backend ends up being used be designed as service-agnostically as possible, so if the backend has to be changed yet again in the years to come, it won’t be the knock-down-rebuild that was needed first with going from OZW1.4 to qt-OZW, and then again now from qt-OZW to (likely) zwavejs?

Doing so undoubtedly adds some complexity to the planning stage of all this, but could save a lot of pain and re-treading ground in the future, and also provide flexibility down the track for alternate z-wave stacks integrating with HomeAssistant.

(I hope that makes sense to you all. I know what I want to mean but am not sure if I’m conveying the idea as clearly as I intend to)

balloob commented 3 years ago

Authentication is out of scope for Z-Wave JS Server. It will just provide an API over a web socket. It's up to what runs it to secure it. Inside the add-on the communication is limited to come from HA ip and if you want to run it over the internet you can put NGINX in front of it.

marcelveldt commented 3 years ago

@gdt what we have in mind is a small server wrapper that sits on top of Z-Wave JS that can be utilized by us (Home Assistant) but also others, like Zwave 2 MQTT etc. It basically is just a forwarder of messages to clients. So you will have all possibilities. You can even run Zwave 2 MQTT together with the HASS implementation if you still want MQTT.

For a default user the "zwave server" will run with only one consumer which is the HA integration but there can be others.

OnFreund commented 3 years ago

While it's a shame that OZW won't be as actively maintained as it used to be, I believe this is the right direction, and am excited about this. A very tactical question - will polling of legacy devices be handled by the Z-Wave server or by HA?

marcelveldt commented 3 years ago

A very tactical question - will polling of legacy devices be handled by the Z-Wave server or by HA?

Zwave JS does not yet have support for polling but if it will, it will be part of the device definition/specification and thus handled automatically by Zwave JS.

https://github.com/zwave-js/node-zwave-js/issues/1163

xAPPO commented 3 years ago

Does not using MQTT mean that this is an implementation tied to a single instance of HA ? Or would we be able to have a network wide ZWave capability availability for multiple automation controllers to use and conversely several ZWave controllers could contribute their devices to one bigger pool of devices ?

Multiple instances on remote devices will still be possible

Ahh but you're meaning Home Assistant specifically ? I meant allowing a network wide sharing of Z-Wave devices across different brands - as MQTT could provide ? Could zwavejs2mqtt be an optional inclusion ?

marcelveldt commented 3 years ago

Ahh but you're meaning Home Assistant specifically ? I meant allowing a network wide sharing of Z-Wave devices across different brands - as MQTT could provide ? Could zwavejs2mqtt be an optional inclusion ?

As stated a few times already you can/will have both. The Home Assistant integration will talk directly to the Zwave JS Server but you can also enable zwave 2 mqtt or other applications that consume the same server. It's all up to you as in flexibility.

varet80 commented 3 years ago
  • be encrypted and authenticated only -- no plaintext except possibly over localhost (127.0.0.1 and ::1)
  • IPv4 and IPv6 dualstack
  • user authentication so that a paranoid person (not a reasonable person!) would be comfortable running the server over the open internet. It is not ok to assume/require any kind of firewall/LAN.
  • One should be able to restart HA without losing Zwave state
  • Restarting Zwave should result in a working setup without manual intervention
  • configuration and management of the Zwave world should have a good plan, ideally via an API via the same mechanism used to turn things on and off from HA. Often systems assume that they are the most important thing and that users are willing to organize their worlds around the shiny new thing. While I think zwave is important, it should function in a world where it is just one of many, not special, and not demanding special treatment.

I am running Home assistant and other tools (node-red) and an mqtt cluster of 3 local + 2 remote nodes (in a k8s setup). this comes from experience.

Adding on @gdt 's specifications. There is complexity involved in either setup. using MQTT layer there are some pros and some cons which everybody needs to think of. Here are some thoughts on it: Pros MQTT usage:

The cons are:

marcelveldt commented 3 years ago

Oh and to make my answer more complete: you can also decide to leverage zwave 2 mqtt to get your devices into Home Assistant if you may wish.

johntdyer commented 3 years ago

yea.... This pretty much sums up my reactions while reading this thread....

giphy_hill

@marcelveldt thank you for taking the time to open this !!!

nappyjim commented 3 years ago

One question and one comment, coming from a novice user.

Q. Would this Z-Wave implementation support multicasting? From what I've been able to gather from other people open Z-Wave does not support multicasting and that's the main reason I've had such a hard time with random time delays when I've tried to shut off four more Z-Wave light switches at the same time. As a test, purchased a hubitat, which supports multicasting, and time delay issues were gone instantly.

C. I like the inclusion of firmware updates. That's another thing I had to purchase hubitat for. Which is kind of asinine that I had to go to a "competitor" for what I would consider a pretty basic and necessary function in this relatively new smart home arena, where manufacturers are adding in new features that require firmware updates.

cgarwood commented 3 years ago

Q. Would this Z-Wave implementation support multicasting? From what I've been able to gather from other people open Z-Wave does not support multicasting and that's the main reason I've had such a hard time with random time delays when I've tried to shut off four more Z-Wave light switches at the same time. As a test, purchased a hubitat, which supports multicasting, and time delay issues were gone instantly.

We talked about this a bit on Discord, it looks like zwave-js has some multicast support. We'll probably go for feature-parity with the ozw/zwave integrations first, but multicast looks to be something that could be implemented into this integration down the road.

jarrettv commented 3 years ago

on the zwave-js server architecture, is there any potential for re-using the ESPHome strategy of declaring the API via proto file and generating the API code automatically on both sides? Or perhaps even depending on aioesphomeapi python library? I've had very positive experiences with that integration that I hope we can replicate for zwave.

kevinkahn commented 3 years ago

I'm still not sure I understand the answer to the question of whether the zwave driver will be able to easily run on a different system from HA. I do think this is an important capability because the location of the zwave controller can depend upon the physical aspects of the house. HA itself is likely to run in the home server, wherever that is - e.g., in an out of the way or even somewhat shielded closet. The zwave controller my have real difficulties running from such a location for certain home topologies. So I think it is important to keep open the option to have the zwave controller accessed across the network (and it is hard for me to imagine that keeping that option would significantly alter the work of building it).

marcelveldt commented 3 years ago

I'm still not sure I understand the answer to the question of whether the zwave driver will be able to easily run on a different system from HA. I do think this is an important capability because the location of the zwave controller can depend upon the physical aspects of the house. HA itself is likely to run in the home server, wherever that is - e.g., in an out of the way or even somewhat shielded closet. The zwave controller my have real difficulties running from such a location for certain home topologies. So I think it is important to keep open the option to have the zwave controller accessed across the network (and it is hard for me to imagine that keeping that option would significantly alter the work of building it).

The short answer is yes. This will still be possible. The long answer is that we will first focus on covering the basic stuff but the architecture should support his although it might require a bit of tinkering at first.

kevinkahn commented 3 years ago

Thanks for the quick clarification. On another probably more contentious front, you might want to rethink the lack of "device" notion that OZW adopted in its implementation. The problem, as you know, is that there are operations on a switch, specifically the central scene ones, that don't really relate to the entity that the switch nominally controls. Thus you have the current beta situation where you have to extract the node id from a switch entity to figure out what central scene action is hitting you. Device may not be the best abstraction for this, but I do suggest that you think about central scene commands from the outset and make them first class citizens generating easily matched HA events which the current beta doesn't really do.

marcelveldt commented 3 years ago

Thanks for the quick clarification. On another probably more contentious front, you might want to rethink the lack of "device" notion that OZW adopted in its implementation. The problem, as you know, is that there are operations on a switch, specifically the central scene ones, that don't really relate to the entity that the switch nominally controls. Thus you have the current beta situation where you have to extract the node id from a switch entity to figure out what central scene action is hitting you. Device may not be the best abstraction for this, but I do suggest that you think about central scene commands from the outset and make them first class citizens generating easily matched HA events which the current beta doesn't really do.

Ah, yes that will be taken care of ;-) It was already on my TODO list to make device automations for those. Will probably also be after the basic stuff but won't be forgotten.

kevinkahn commented 3 years ago

Great - I know from our interaction in back in the spring how hard you've worked on this so thanks. If early testing is needed as this comes together I'm in again for this version (assuming I actually at this seasonal home where I use zwave).

ve6rah commented 3 years ago

Not being an expert on the developer side, I may not be the right person to ask, however as an end user I have to say that I fully support this change given the reasons listed above. It has been very frustrating seeing the state of z-wave in home assistant when compared to every commercial z-wave hub out there, and I have very much seen that there are barriers to fixing it under the current setup. Having a situation where home assistant developers have the ability (and desire!) to directly fix upstream issues would go a long way to building a sustainable long term solution.

End result is that users don't care who is responsible for what part, or what the underlying architecture looks like, they just want to know that when they have a z-wave device that works on competitor's hubs, it will work on home assistant at least as well. That "just works" result is what should be aimed for, and whatever it takes to get there should be explored.

@balloob I do have one concern however, you state:

A note here that this proposal is about introducing a new integration (domain TBD) maintained by the people working currently on the ozw integration and add-on. The OZW 1.4 integration (zwave) and OZW 1.6 integration (ozw) will not be removed from Home Assistant.

I hope that this is a short term situation only. In the long term having 3 different integrations that all do the same thing is a recipe for confusion. I hope that as the new integration surpasses the old ones in features/functionality that the old ones get deprecated and retired.

datascope11 commented 3 years ago

I hope that this is a short term situation only. In the long term having 3 different integrations that all do the same thing is a recipe for confusion. I hope that as the new integration surpasses the old ones in features/functionality that the old ones get deprecated and retired.

While I agree in the long term, having 1 integration will be less confusing, I feel there must be a seamless migration path before deprecating/retiring anything. I'm running OZW beta with absolutely no issues. As a not-so-super-techie person, and my first step into HA/Zwave - this was no easy achievement. But I am up to a couple dozen devices. The way I look at this - legacy zwave integration doesn't support my devices, OZW beta (announced earlier in 2020 as the "future") is working but not being developed any further. Now a different direction is coming, which is great - BUT, users need an easy migration path. If the instructions for this migration are daunting, I'll stay with OZW beta until it doesn't support my devices any longer.

All this to say, the state of zwave in HA is not great currently. I understand all of the reasons, and appreciate all the efforts and contributions. But with zwave being such an important part of the home automation journey, users experience in migration should really be considered.

PARitter commented 3 years ago

on the zwave-js server architecture, is there any potential for re-using the ESPHome strategy of declaring the API via proto file and generating the API code automatically on both sides? Or perhaps even depending on aioesphomeapi python library? I've had very positive experiences with that integration that I hope we can replicate for zwave.

This. Please. Use Proto files and autogeneration for the API.

Neraud commented 3 years ago

Glad to see news about a more robust and updated Z-Wave integration.

However, I'm a bit puzzled by the PROs and CONs listed here. I'm most probably biased as I'm a DevOps engineer : deploying and configuring a MQTT broker doesn't seem like a CON to me.

As the plan is to have a dedicated Z-Wave server, it's still "more complex" than a native integration for regular users. I feel like having [HA + Z-Wave server] or [HA + Z-Wave server + MQTT broker] is not that much different in that regard.

I also second @gdt 's security requirements. Even if the Z-Wave server shouldn't be publicly exposed, not securing it properly feels wrong. And asking users to handle that through nginx isn't a solution.

TL;DR : is the "drop MQTT" requirement really worth it ?

marcelveldt commented 3 years ago

There seem to be some misunderstandings about the Zwave server. This is actually a nodejs server that will be started serving the api as a socket to HomeAssistant or any other implementation. It's not exposed to the network at all by default. It may if you have an advanced scenario but not by default.

This same server can also be hosted by e.g. zwave2mqtt which serves the Z-wave mesh to MQTT or some custom application you wrote yourself.

incompetentJS commented 3 years ago

I look forward to the next zwave platform in six to tweleve months when this awful zwave platform falls apart.

This is a proposal to replace to an unsupported bad zwave integration supported by a single developer with an unsupported bad zwave integration on a bad platform written in a bad language by bad developers -- excuse me, just a single bad developer -- AGAIN.

👏 👏 👏 👏

marcelveldt commented 3 years ago

I look forward to the next zwave platform in six to tweleve months when this awful zwave platform falls apart.

This is a proposal to replace to an unsupported bad zwave integration supported by a single developer with an unsupported bad zwave integration on a bad platform written in a bad language by bad developers -- excuse me, just a single bad developer -- AGAIN.

👏 👏 👏 👏

Go ahead and write something yourselves perhaps ?

bachya commented 3 years ago

@incompetentJS Your comment is abusive, unwarranted, and toxic. That you joined GitHub 22 minutes ago to post this says everything. Do it again and you'll be banned.

@marcelveldt and others: please do not engage with abusive commentary so that we can keep this proposal focused on its content and easier to consume for truly interested parties. Appreciate your support.

Twanislas commented 3 years ago

Thanks @marcelveldt for starting this much needed conversation. I'm very happy to see progress on this front ! 👍

From a technical point of view, I really LOVE how Zigbee2MQTT works (using special topics designed for Home Assistant discovery and configuration of devices). I would be delighted to see a similar setup for ZWave in the future.

There's already the official Mosquitto broker addon which is really simple to setup and uses HA's internal authentication mechanisms. It was super simple to add the Zigbee2MQTT addon to my setup and I have a nice panel for all my Zwave needs (and it using HA's ingress !).

A similar setup for Zwave would sound perfect to me and would make it consistent.

Cheers from Belgium ! :)

jcam commented 3 years ago

@Twanislas to get that, you might want to try the already-in-progress zwavejs2mqtt. Based on this arch thread, it won't be the official native integration (just as zigbee2mqtt isn't the official native zigbee integration), but it may serve your needs well.

See https://github.com/zwave-js/zwavejs2mqtt/blob/master/docs/guide/homeassistant.md

MwC-Trexx commented 3 years ago

As also a z-wave newbie, would nodes that are already “INCLUDED” to a z-wave dongle under OZW beta be able to be “adopted” under the new zwave-js without having to be excluded/included again?

I have 30+ Nodes, and going through that pain once to migrate from vera to OZW was painful enough.

Even if there was some way to say export the node id, device & entity names via hasscli or jinja template and then re-apply would be less painful than starting from scratch.

FreelancerJay commented 3 years ago

@MwC-Trexx The actual “Inclusion” between the zwave devices and the zwave dongle will still be there, so you won’t need to go around the house resetting and re-including all your devices again. Just make sure to copy the network key from your original configuration to the JS configuration when it’s time to move over. (zwaveJS takes the key as just the numbers, so remove the commas and “0x”s from the OZW formatted key, so “0x2A,0xC1” becomes “2AC1”)

You’ll still need to go through Home Assistant and set all the entity names and areas again though, but that’s less painful than having to rebuild the network from scratch.

I started a ZwaveJS2mqtt docker in place of my qt-ozw docker just to see what state of function it was up to, and all the Node IDs are reported the same, which makes sense since that is logic that is read from the controller hardware, not the software. So if there isn’t a automatic migration by the time this is ready for prime time (or when you need to upgrade, such as to support a new device), then you’ll just need to note which device matches which node ID. Still a bit of a pain for larger networks, but much better than starting from scratch.

Of course this is just anecdotal, not a promise, purely based on its state now. As with anything being actively developed, not to mention so early in development, things may change, though I can’t see a reason you would need to perform zwave excludes/includes if you’re keeping the same controller and network key.

mikedahlgren commented 3 years ago

PRO: Device configs are broken out into files and it is easier to add additional device ID's.

This is huge for me as I found out 3 months ago that my new Yale locks were not in OZW. I am not a developer but put in a patch, submitted it upstream to OZW and still have no idea if or when I will ever see them recognized correctly.

MwC-Trexx commented 3 years ago

@FreelancerJay

I pretty much suspected that all the node information would persist in the dongle since I use that to do FW upgrades on the zwave devices in a separate app. While I am ok with the current ozw method (learned to tolerate it), the lack of base stability of the zwave “hub” itself is frustrating. That and the 1-2 minute “startup” time for it to stabilize and report everything back to online to HA itself (devices/entities/etc.). Also the GUI while functional isn’t anything to right now about in OZW-Admin.

All that being said, I am appreciated of all the work that the maintainers of OZW did as I am sure that is no small feet to support.

LittlePapaJohn commented 3 years ago

Thanks for the open communication on this. I think reading through this threat it is the best way foreword. I was waiting for OpenZwave to be stable enough but it seems this will be very challenging, if possible at all. I want to thank all those people working on trying hard to get it up an running. Too bad this happened but as with all failures I think most of the contributors learned from the experience and thus not a compete waste of time. Hope the new solutions does not take another year though. I struggling with device functionalities that are not present in 1.4 OZW and get irritated by those annoying restarts.

steve28 commented 3 years ago

Although I am not excited about resetting the clock (perhaps another year or more, ugh) I am excited about having an active and maintained z-wave implementation. z-wave is fundamental to home automation, and it needs to be rock solid in HA.

cgarwood commented 3 years ago

Although I am not excited about resetting the clock (perhaps another year or more, ugh)

We’ve actually already managed to get a decent chunk of the core integration put together and have some basic sensor support and working on light support already 😀. Hate to make promises because something could always cause a delay, but there’s a good chance some platform support could be ready for 2021.2

steve28 commented 3 years ago

Let's hope the third time is the charm

Colorado4Wheeler commented 3 years ago

While I know some of the original threads related to this topic have gotten a bit out of control and even somewhat toxic, I'm super excited to see that it wasn't for nothing and that there is some forward momentum on a new Z-Wave integration. It sounds like the potential for the new integration will be amazing, I am anxious to see how this comes together - just multi-casting alone would be a much welcome change.

It's been mentioned that while nobody would have to exclude and re-include all their Z-Wave devices that there would likely be a need to set up names once again and I'm wondering why a migration of the entity names and device names is not possible. Since the naming is stored outside of the Z-Wave hub, wouldn't it be a relatively simple matter to read the existing list of devices for OZW and migrate that to the next platform? Is there some particular key data that changes between integrations that makes a migration such as this impossible?

balloob commented 3 years ago

Going to close this issue as first part of Z-Wave JS has been merged https://github.com/home-assistant/core/pull/45020

Hedda commented 3 years ago

We’ve actually already managed to get a decent chunk of the core integration put together and have some basic sensor support and working on light support already 😀. Hate to make promises because something could always cause a delay, but there’s a good chance some platform support could be ready for 2021.2

Will new integration be called "Z-Wave JS" or something else and will it be available as a public beta like OpenZWave is?

https://rc.home-assistant.io/integrations/

FYI, searching integrations today for "zwave" shows both old and OpenZWave but searching for "z-wave" only shows old.

cgarwood commented 3 years ago

Current work so far has been merged into the dev branch and is available in the nightly builds. It will be also available in the 2021.2 beta and 2021.2 release. Current name for the integration is "Z-Wave JS"

GrizzlyAK commented 3 years ago

It's been mentioned that while nobody would have to exclude and re-include all their Z-Wave devices that there would likely be a need to set up names once again and I'm wondering why a migration of the entity names and device names is not possible. Since the naming is stored outside of the Z-Wave hub, wouldn't it be a relatively simple matter to read the existing list of devices for OZW and migrate that to the next platform? Is there some particular key data that changes between integrations that makes a migration such as this impossible?

I'm super excited about this change in direction, as I'm fully committed to Zwave on my network and v1.4 is getting a little long in the tooth with some new devices (e.g., sound switch). I've been resisting OZW beta simply because of MQTT and having to rebuild from scratch. As @Colorado4Wheeler said above, I would love to see sufficient effort given to a migration path that minimizes disruption, particularly having to rename every entity on the network. I fully realize that this is additional work for the devs, and would delay rollout, but for established systems, it sure would make adoption much easier.

FreelancerJay commented 3 years ago

It's been mentioned that while nobody would have to exclude and re-include all their Z-Wave devices that there would likely be a need to set up names once again and I'm wondering why a migration of the entity names and device names is not possible. Since the naming is stored outside of the Z-Wave hub, wouldn't it be a relatively simple matter to read the existing list of devices for OZW and migrate that to the next platform? Is there some particular key data that changes between integrations that makes a migration such as this impossible?

I'm super excited about this change in direction, as I'm fully committed to Zwave on my network and v1.4 is getting a little long in the tooth with some new devices (e.g., sound switch). I've been resisting OZW beta simply because of MQTT and having to rebuild from scratch. As @Colorado4Wheeler said above, I would love to see sufficient effort given to a migration path that minimizes disruption, particularly having to rename every entity on the network. I fully realize that this is additional work for the devs, and would delay rollout, but for established systems, it sure would make adoption much easier.

Not that it’s a guarantee, but across PR comments and discussions on the forums, I’ve seen a couple of devs currently working on zwaveJS say they’d like to/plan to sort a migration, but the development needs to be a lot further down the track before they can even tell if it can be done or if there is a show stopper that means having to rename everything. So pretty much watch this space and if it CAN be done, it will be, and if it can’t, I imagine there would be a blog post somewhere explaining why at least.

All said, I’m telling you this as an observer, NOT a member of the team or a contributing developer, so 🤷😂

cgarwood commented 3 years ago

Current planning for a migration path: https://github.com/home-assistant-libs/zwave-js-server-python/issues/35