I agree 100%. I wouldn’t have switched from Indigo if there was no Z-Wave and Insteon integration since those are the protocols I use. I think HA probably started out as more of an IoT platform to control the oddball devices (like Wireless Tags, for example) that use REST or some special API call, but it seems to have appealed to far more users, like me, interested in seeing it be their entire home automation brain - in which case supporting the core protocols such as Insteon, Z-Wave and Zigbee seems to be a core requirement.
There are only a few “industry standard” automation protocols, so relying on the community to provide the “oddball” experiences is spot-on, but I would think that the core stuff would be baked in.
Newer HA user here.
I am using the old integration and it works fine for older devices. Had to struggle with a Figaro RGB Controller to get it working.
Should I continue with the old integration or should I move to the new beta one?
For a new user I just want things working and not invest time in anything that will be deprecated.
At the moment, it is a state of flux. I think you would be better off waiting until there is more concrete future for HA / ZWave as outlined by @balloob here :
Dang it. OZW isn’t perfect, but that’s what I started with when I wanted to add Z-wave to my setup and get it off the old Vera. It’s a little quirky with my Kwikset door locks and their status, but everything else I have has been rock solid. I can’t even remember the last time I restarted its Docker container.
I’d switch if I had to, but hopefully it can be salvaged with some more help. It was on the road to being pretty good.
As a brand new user to HomeAssistant, having been on ST hub v2 for the last few years, the way that this has been in flux / in beta for a year definitely left me wondering if I should even attempt switching off of smart things, but I’m sure it’ll work out in the end.
The whole idea behind an open project like this is it allows lots of contributions from lots of different people and places. Maybe one project (OZW) will lose momentum, but there’s a big enough and diverse enough community here that other projects will develop to fill in the gaps.
I’ll be using zwave-js, and if someone else hasn’t gotten to it first I can work on an addon-zwavejs2mqtt to make deploying that library easier.
This thread… wow… the rudeness from some members here is jaw-dropping… i’ve been following this thread a while now, didn’t want to participate at first, but I want to back @petro on this whole escalated situation.
@luma i find the way you describe nabu casa somewhat insulting, even though I’m not an employee there but, has it ever crossed your mind that HA does NOT require an active nabu casa subscription in order to work? HA is entirely FREE and Open Source. The monthly payment you refer to are a few things summed up:
- Secure Remote Access over the servers from nabu casa to your own instance.
Hosting a solution like this and maintaining costs them money too. (hardware/or hardware rental) and time spent to maintain this
- In addition to the above you get easy remote google assistant and alexa integration with your HA instance
- A TTS service provided through nabu casa
- And whats left of that 5 bucks a month is to support those who became employee at nabu casa to have a somewhat stable team that won’t (have to) leave so easily.
This ensures that the CORE is maintained properly.
If you pay for a nabu casa subscription is because you choose to pay for the service described above.
Aside from the fact that he got demotivated due to a rude community, he also got a job promotion. This promotion took away even more of his valueble time which makes it another reason why he’s not able to dedicate (more) time to HA. This can happen to anyone here when they have to contribute in their free/spare time. Eventually less time, or maybe a loss in interest due to various reasons and, shocked by what Fishwaldo says, how rude people can be if it’s not perfect. what the F!
So what I see that @balloob / nabu casa tries to do with the small fee, is make things somewhat easier and more secure for the users (no port forwarding required, DNS and SSL certificate payment/headache, updating systems and ensure compatibility, deprecations of systems etc etc) and most important is a small donation towards a small team where they try to pay someones salary to ensure they have time during the day to work on HA, instead of having to rely peoples free/spare time. These dev’s have bills to pay too. So that other influences (switching jobs, promotions etc etc) don’t get in the way where people eventually have to quit working on HA (integrations) because of lack of time/health/other job etc. This way they ensure that HA always has a small core team that work on continuous growth on the core systems. Also fund projects like the podcasts. People want info… occasional donations to contributors through github when they can. and so forth.
This current team is by far not big enough to cover ALL aspects that HA has grown into providing. Their focus is working on a platform called HA, that the fundamental parts are working good, secure and easy to use. Also by making it user friendlier, they get more people to enjoy the world of automating, like GUI editing instead of writing difficult yaml configs. This platform has grown into such a huge thing thanks to the hundreds of contributors that help improve, add new functionality/features and what not. But not by solely core dev users!
What I’m trying to say is, many people here have (in my opinion) a flawed way of thinking about (this) open source project(s). The user base and thus the expectations/requests have by far outgrow the group of people that can actually maintain it. Like @Fishwaldo said, he build to have his environment work. He can’t be held responsible for the thousands of other zwave products out there. Meaning, other people have to help contribute code to make things even better for everyone, more/bettee compatibility out there for people using zwave.
Instead of only complaining, think in solutions. Try to get people on board that have the knowledge and time that can help contribute with the things you need and get better over time. Post help requests outside HA forums, (reddit, google etc) and lure them in. Maybe try to learn code yourselves? Can’t find what you need in HA, try some other platform (OpenHUB, demoticz etc). You’ll find yourself coming back because HA is in so many ways better than other platforms out there.
People that say their house depends on automation? STOP using open source, pay a company that does automating and use their software. When somethings not right, you have the right to file a complaint and nag. Yet, people that do pay a company for their platform, still switch over to HA because it’s still a lot more than what paid companies out there can/want/will offer.
By all means, @luma, stop your subscription by I encourage you or anyone else with a subscription to not cancel it because it’s what helps (a bit) to keep this huge train moving forwards.
Very interesting proposal. Thanks a lot for this. I think the quick and transparent way this situation is being handled by you guys is highly appreciated by everybody. I certainly do.
I very much like the fact that the new proposed integration will not run over MQTT. That’s a great step in the right direction.
I don’t see anything particularly rude in this thread. It was a good and important discussion about a problematic situation that was only going to get worse if nothing was done. A new proposal was created to address this situation in a very interesting way, while still possible, that may very well pave a clear path forward for ZWave support in HA.
As such, this discussion (and similar ones preceeding it) have been quite productive.
I am fairly new to HA and have had good success with the beta, but must admit I have not tried my doorbell yet.
But to be clear, HA was only in consideration from the get go because it integrated all the core industry techs (wifi, zigbee, zwave etc). If it had not had one of those three I would not be here typing this right now. Your product MUST fully support industry standards for you to be a serious product in the automation scene and I have to admit the fact that something as critical as Zwave has been entrusted to a single person (regardless how good a dev that person might be) is a disaster waiting to happen. It doesn’t matter if it is open source or not…something that important need to have a team of people fully versed on it to make sure what has happened here does not happen.
Real Life is a thing. Burnout is a thing. You should be guarding against these two enemies as hard as you can. They WILL win if you do not
Bravo to the dev who has single handedly produced this fairly stable, complex integration…you deserve all the cheers provided here.
CON: A fully automatic migration of legacy/current ZWave in HA to this new implementation will be hard if not impossible because of the fact that the internals are handled.
In that respect I was wondering whether one of the existing solutions to have z-wave in Home assistant could have an advantage over any of the others in terms of migration path to such a future Zwave JS integration?
I assume zwavejs2mttq doesn’t hold an advantage over for example the existing native integration or z-wave2mttq or qt-openzwave, because despite it being based on zwavejs, it relies on MTTQ as communication layer?
In that respect I was wondering whether one of the existing solutions to have z-wave in Home assistant could have an advantage over any of the others in terms of migration path to such a future Zwave JS integration?
I assume zwavejs2mttq doesn’t hold an advantage over for example the existing native integration or z-wave2mttq or qt-openzwave, because despite it being based on zwavejs, it relies on MTTQ as communication layer?
If we’re able to write a migration it would only be for the existing Z-Wave integrations in core (zwave/ozw), it would be up to the larger community to contribute a possible migration path for zwave2mqtt/zwavejs2mqtt as they’ve never had an actual core integration.
That said, at this time I wouldn’t hold my breath for a migration tool… though that could change.
Thank you, so I deduct that people who are looking at starting to use Home Assistant are best advised to use the current (albeit outdated) native z-wave integration because at least the steps to migrate – even if likely not (fully) automatic – will be described for that migration path.
Out of curiosity, what is the difficulty with a tool that does at least automatic naming of entities? I’ve done this somewhat in the past using python to load core_devices, matching the node to a device id, then going to core_entities, matching the device id to entities, then opening the new ones and applying those same friendly names based on the node/device id and writing out the core_device/core_entity. Obviously that breaks down where zwavejs2mqtt provides more/less entities or different kinds of entities than zwave/ozw provided. Is it just matching up the right entity to the right sensor where multiple are provided, as an example?
I’m not challenging that it is possible, I’m genuinely curious in where the difficulty lies.
This is also the same thing that I’m wondering about. I’ve been watching this issue request for a while and haven’t seen any movement on it. I’d like to know if this project will be using the migrated OZW config files as that will greatly increase support with my devices. I’m worried that starting over from scratch in regards to device configuration will take this project a lot longer to attain the same level of support.
Presently they are using the current openHAB device files, but they are setup to import the ozw 1.6 device configuration files as well. So far the current directory seems as complete or more complete than the ozw one. I think only one of mine was missing and there were a few that were only recently added to qt-ozw.