In most cases this looks like one of the following:
"/dev/serial/by-id/usb-0658_0200-if00"
"/dev/ttyUSB0"
"/dev/ttyAMA0"
"/dev/ttyACM0"
What would be the /dev syntax for port 333 on the rafale-enanced Vera?
Also, referring back to the OP for Z-Way support - having Zwave-JS server running on a RaZberry/Pi with ZWay support seems like it would be feasible for a nice little external Z-Wave hub for HA.
On the vera (or any remote zwave bearing device) the following is happening:
Zwave chip -> serial port -> IP:port
On the receiving end:
IP:port -> serial port -> serial API client (zwave-JS)
zwave-JS is looking for the serial port (just like HA). Did you setup the bridge? the one typically used is socat. This is exactly the same thing you should have done with the previous setup. The /dev/*** is the serial port address on your linux system where you had setup socat to forward the IP:port to and should be exactly the same as what you used in home assistant if you did not change the socat setup.
Thanks for explaining the need for a socat bridge! This is all new to me, and I only just set up ZWay/RaZBerry image today for testing and just have it communicating with a few test devices. It’s really impressive the management control you have, especially compared to Vera.
I’m still researching my options if I really want to dive into this. I was first trying to find out if anyone has undertaken this before. The HA docs don’t cover it, and says installing the server component is very advanced and “out of scope”.
Option 4: Run the Z-Wave server yourself
This is considered a very advanced use case. In this case you run the Z-Wave JS Server or zwavejs2mqtt NodeJS application directly. Installation and maintaining this is out of scope for this document. See the Z-Wave JS server or zwavejs2mqtt GitHub repository for information.
It seems the path of least resistance is to just get a supported ZWave dongle to plug directly into the HA server running Z-Wave-JS.
it all depends on how large your network is. Arguably it is much easier to setup socat than it is to start inclusion from scratch for 20+ network item. You can search quite easily how you can set this up with the old home assistant component. It is actually completely identical. I don’t quite understand how you managed to have HA work with your vera previously without setting up socat.
As for setting up Z-waveJS, I can’t help very much. It does take a bit of learning I am sure. I am certain that there is a docker container path which people will say is easier. Just not to me and it seems.
@rafale77 and @rabittn This is the first time that I have heard a solution that includes using: socat, ser2net or usbip. I hope that I understand you correctly, I am touching wood right now? You are saying, that I will be able to talk to my USB ZStick over IP via Socat with Z-waveJS in the near future? Or maybe I can even consider doing the conversion to Z-waveJS sooner?
I currently have the following setup running Home Assistant Core with the legacy Z-Wave version, and Socat running as a client configuration on my VM:
If I understand correctly @rafale77 and @rabittn that Z-waveJS runs as a Service and can be configured to use the Socat serial port pipe out to encapsulate the stream of data over IP?
Client (Linux VM) Configuration::
Home Assistant (Service) --> Z-waveJS (running as a Service?) --> Socat (Service)
Server (Raspberry Pi) Configuration:
Socat (service) --> ZStick
@rabittn, hmm interesting are you saying that they are building there own solution to encapsulate the stream of data over IP? You also need a Server Service/Process such as what I have: Socat but on the Server side this time, see above: Server (Raspberry Pi) Configuration.
@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…
with 2022.03 - but you will need a patched Z-Way version (regarding the UUID feature) - or you must wait until it is available.