The Future of Z-Wave in HA - QT-OpenZWave

This thread’s title needs to be renamed. Clearly, OZW is not the future of Z-wave in HA.

4 Likes

Maybe good to keep it for historical sake. Haha

Very exciting news! Thanks for sharing!

Well, I guess that’s that then.

A while back I posted on here about how maybe it was better to use a dedicated ZWave hub to separate the ZWave domain. At the time, I changed my mind and chose to implement ozw on a separate HA instance located in a better place (RF-wise).

I love MQTT and use it for a stack of other tasks in the house. It IS my communications platform of choice. Consequently, I have a resilient MQTT infrastructure to cope with the occasional vagaries of the network.

The only problems I have are caused by ozw’s restriction to use qos=0 (which I asked about in a separate thread here.

I’m not convinced that changing the ZWave implementaion again is a good choice for me. The Pros/Cons for changing highlight the single-developer issue that has affected ozw development (no reflection on @Fishwaldo), and there’s no guarantee this won’t re-occur. Given the critical status of ZWave in my house, therefore I am thinking again of swapping to a commercial ZWave hub

1 Like

The likely hood of this occuring is much lower because the codebase is more widely known. OpenZwave is written in C++ where as Zwave2jsmqtt is written in JS. Pretty much anyone who contributes to HA will be able to contribute to Zwave2jsmqtt because the frontend is written in JS/TS.

1 Like

I hope you’re right.

We already have 7 collaborators.

2 Likes

HA is using the driver ZwaveJS directly to make their own implementation and not Zwavejs2mqtt. However, zjs2mqtt would be a good alternative to @Guff666 :slight_smile:

I’m excited about two things, thats on the roadmap: OTA updates and S2 security (which should speed up communication?).

1 Like

Yes, I was simplifying it for people who don’t understand the difference. When official name comes out, then we’ll call it that :wink:

Ah, ok, but might also confuse as the HA implementation won’t use MQTT. :slight_smile:

1 Like

:sweat_smile::v: Haha okei, but i guess that’s zwave-js-server :wink:

I believe it’s going to be called “Z-Wave JS”

Whatever is good, as long as it works. :innocent:

it’s programmed to turn your lights on at midnight or when sleeping

3 Likes

It amazes me how quickly… the HA community has adapted to the feedback and produced an alternative to its Z-Wave integration. More importantly I think what I see in the HA community is a willingness to look at improvements instead of dwelling on “flaws”.

But okay. I guess HA is over… this thread as quickly as it began and is moving forward.

Awesome!

2 Likes

For those of you not following the other thread about switching paths:

Just an update for everyone. I’m in the process of importing every single certified zwave device into Zwavejs2mqtt and node-zwave-js (the new server backend). I’m about 98% finished and working on bugs now so confident it’ll work. It’s a few hundred additions and revisions to around 1,000 device files representing devices from all over the world (after accounting for model changes…its 4,700 entries total). In talking with the maintainer, our goal is to have it auto-PR newly added devices each week or so. At the moment the database even includes pre-release devices so hopefully device file issues become a thing of the past.

From switches to bulbs to thermostats to mousers and graters (whatever the hell they are…the Russians have some interesting devices), we’ll have device files for it all.

10 Likes

Are you telling me the Russians have worked out automating their cheese graters? And here I am, still grating my cheeses with my hands, like a peasant!

1 Like

This is also amazing news, really looking forward to testing it out!

Given you’ve been going through config so much, maybe you could answer a question for me? When devices are added with security, does it change what config is used to identify them?

I’ve just installed a Aeotec Dual Nano Switch and two single Nano Switches, and when I securely add them to my dockerised Z-Wave JS controller (using a Z-Stick gen5+) once the interview stages have completed, they show up as “unknown device”, but they work fine with all features when insecurely added. On the other hand, my Multisensor 6 adds securely and still shows up all properly identified…
Would that be resolved once the config database is complete, or am I barking up the wrong tree?

No but I believe some issues with this were recently fixed. Make sure you’re on the dev image. If you are and this persists open an issue.