@rabittn - the latest official Z-WaveJS-MQTT 0.4.1 addon now supports tcp://ip:port designations for the serial port. (The non-MQTT version was rejecting it).
I am running ser2net on the RaZberry Pi with the following added to /etc/ser2net.conf
4000:raw:0:/dev/ttyAMA0:115200 8 DATABITS NONE 1 STOPBIT
The addon is configured to connect to tcp:// ipaddr:4000 with the MQTT feature disabled, as it’s not needed. All the control panel functions of this addon do work, and it installs the Z-Wave-server component in its own docker that continues to run when HASS is restarted.
@rafale77 - thanks again for your help. You had asked how I was connecting HASS to Vera before - well, very simply using the standard Vera integration which connects via the Vera Rest API. It works fine for me since I don’t have all that many devices connected, but I want to be prepared for reasons you know all too well.
Ohh I see, I thought you had already nuked the vera. Apparently not. Now I get it. Yes the previous openzwave integration needed socat. I was using it also for zigbee actually which I found out later could be done exactly as @rabittn described since the ZHA component also supports bridging the TCP port directly. I am still using ser2net socat for… z-way as I have my uzb stick on a different machine and location than my z-way-server. As for the original topic, I am very convinced that one could integrate z-way-server very effectively through MQTT albeit requiring some set up:
install an MQTT broker
install the MQTT app in z-way-server and set it up to publish to the MQTT topic
install the MQTT integration on HA and get it to subscribe to the broker with auto discovery.
All in all not too different from ZwaveJS2MQTT. Such a setup would be more efficient than using a polling integration which is was the original request.
A significant disadvantage to a Z-Wave network run by Z-waveJS or an openzwave-based version is that the S2 standard is not supported.
Though it’s on the Z-waveJS roadmap according to it’s homepage’s support the project section (it is/was on the openzwave roadmap too).
(Neither S2 version 1 / 500 series Z-Wave chip nor the S2 version 2 / 700 series Z-Wave chip)
S2 vastly decreases the bandwidth overhead of device communication, and fixes the S0 Key Reset (theft) attacks vulnerability according to the silicon labs security white paper, and which is rather trivial to perform in an automated manner). S2 results in a faster network/ far less latency.
At minimum this requires a S2 capable Z-Wave controller with controller software that utilizes S2 (so not currently a network running Z-waveJS or openzwave) .
Z-Way is a proper Z/IP Gateway with full S2 support.
(I believe also this converts the Z-Wave controller into a bridge controller from a static controller in the process. Currently only static controllers are supported by Z-waveJS or openzwave).
Only problem with Z-Way is that you have to download it’s complete installer closed-sourced form from a private website located in an officially designated Hostile Nation State (from Western POV) known for having cunning cyber attacks as a matter of official state policy.
(Parts of what they say go into their installer is on their GitHub repo)
I don’t download firmware from Chinese websites for that reason, as you never know if the People’s Liberation Army injects advanced and hard to detect malicious components into the code, of which the developer may or may not have any knowledge of, but certainly would be reasonably powerless to object to if he or she wants to stay out of prison and/or stay in business. I don’t download Kapersky security products for that reason either.
That being said, I find myself tempted to consider it worth the risk and just go on hoping for the best (that the state intelligence services haven’t been tempted to terrorize or sleath subvert) out of desperation for something reliable and something that follows the Z-Wave Alliance’s standards and not something that’s both reversed engineered / hacked together and additionally operates without utilizing S2. It would be nice z-way’s downloads at least had SHA256 hashes and even better added GPG key verification for integrity.
The developer and/or chief of z-wave.me’s technical abilities as evident in their products looks pretty damn awesome…that is super obvious.
His video tutorial series or web seminar series and extensive documentation in how to use his products at every available level of depth desired by any user is among the best I’ve ever seen and is extremely impressive to say the least. No assumptions at all or made about what the user’s level of experience is, and that alone makes it an extremely educational product.
It’s immediately clear that their products are among the best out there, and probably the most advanced and reliable option out there for makers and DIY’s who may also be looking to have user data privacy
There’s some sort of HomeKit availability as well.
Competing alternatives to Z-Way (possibly): Aeotec has 700 Series stick and Rasberry Pi hat now, and you can download Z-Ware from Silicon Labs, and create your own Z/IP Gateway, though I have not tried to do so myself, and have not been able to determine if web sockets are supported for speedy tracking of state changes, and other things that gives me the impression that Z-Way is more polished and user ready.
Ezlo’s new hubs with 700 series Z-wave chips looks like they have a good apis for both local and web-based. Data is local, and they claim they’ll add support for any requested device guaranteed.
To date, no Homebridge option for HomeKit, no Home Assistant integration.
I get the impression that Hubitat still can’t get a lot of things straight with Z-Wave and has all kinds of problems still with its latest 700 chip series hub. E.g. Zooz’s website even go so far as recommending pairing many of its devices in unsecure mode, and the user forms gripe about it a lot and blame Zooz, but these problems are not found elsewhere will say the new Ezlo bridge for example. There also seems to be a lot of tinkering required to get devices to work in general, and messing with Groovy code, which is a time investment, it doesn’t seem very efficient or reliable. But that all said I hope Hubitat develops further and becomes highly successful too due to their commitment to user privacy, and non-corporate independence.
Other people have complained about it’s Z-Wave’s range, but that’s impossible to verify.
Also, despite these brands a lot of devices are claimed to be supported, so you will find the user forums are full of people complaining about Z wave devices.
Hubitat does have Homebridge option for HomeKit, and a Home Assistant capability in some form though.
Background to statements made above
Key Reset Attack info; theft of Z-Wave network key
this attack means basically you can extract the encrypted network key by forcing an already paired non-S2 z-wave device into pairing/inclusion mode if the controller itself is not S2 itself, by easily spoofing the S0 controller itself using its transparent MAC address and ordering the target end device into inclusion mode again. The end device the requests for the network key to be sent to it from the real S0 controller, which is encrypted using only a 16 bit string of 0’s according to the S0 inclusion process standard. The attacker then intercepts that encrypted network key, and decrypts it knowing that was only encrypted using a 16 bit string of 0’s, and voila, the attacker has the network key for all of the devices on the Z wave network. Once again, this applies only to a Z-Wave controller that is only S0, and an end device paired to it that is also only S0 (unfortunately including current Z-WavenJS and openzwave, until either or both of those projects support S2). A network with a Z-Wave controller with S2 capability, and controller software that utilizes that S2 capability, is not vulnerable to this key reset/theft attack
(Z-Wave Plus devices without S2 support are S0 devices.)
This whole Key Reset/theft attack has been automated and is trivial to deploy. You can download various peoples versions of it from GitHub repos for example.
See links
S2 having vastly reduced Z-Wave network latency (when all or most devices are S2 capable, and the controller software uses the controller’s S2 ability:
See Silicon Labs S2 security white paper
That’s my 2 cents anyhow at the moment, which of course is subject to change If other information comes to my understanding of things and/or other developments occur.
Possibly. Possibly not though, due to what I described in a comment above, with respect to Home Assistant’s MQTT issues, as related further described in an episode of the Home Assistant podcast wrt MQTT and Z-Wave devices.
Please share the performance results though because I am curious.
It would be nice to know if MQDT is a viable option and the performance issues are no longer a concern.
I am not integrating Z-way to Home Assistant. Actually I don’t use Home Assistant as a controller but rather as a fancy integration bridge. Coming from the vera platform I am actually running openLuup which is a master controller written in lua (in similar way others are using Node Red) to which I have connected both HA and Z-way. I have no performance issues at all running it that way and it is indeed a polling method. The MQTT problem with HA sounds like it is specific to OZW likely reporting every zwave event, including some not so useful ones. I don’t know how Z-way’s MQTT bridge works so I can’t comment.
I would like to test it, does someone have a guide to getting this branch packed up in a docker? (I know how to use dockerfiles, just haven’t packed up HA in one before)
I’m currently running dev branch on my test bench, and would like to test this integration! I will probably move my system to HA, but I have no plans to replace Z-Way…
So, i’ve tested this for a while, and we found some improvements - sorting of entities into devices (now every entity is a device) is a big one that i’m eagerly awaiting.
The developers over at the z-way forum tells me that its already in the latest plugin code update awaiting implementation into HASS.
Is there a roadmap where I can see when this is planned updated/included?
I’m still waiting on porting the rest of my system to HASS until this has been sorted out…
This looks very nice! Coming from Homeseer, I was used to better diagnostics (that actually had correct data) and robust z-wave operation that I miss with zwavejs2mqtt. I found zigbee so much better and have replaced most of my zwave devices, but still have 5 yale locks, and a dome valve controller. The locks are in different places that need repeaters to reach all of them, so still have issues. Zway might be a good answer to this.
Can you tell me if it hands locks over to HA in a way so they appear as normal locks and with the ability to set lock codes etc… as well as lock./unlock, events, etc…?
That’s too bad. I have moved most of my plugs etc… to zigbee, but still have my locks on zwave. It would be nice to have a reliable zwave code implementation that has full function lock support.
with 2022.03 - but you will need a patched Z-Way version (regarding the UUID feature) - or you must wait until it is available.