Apologies if it was already discussed elsewhere but I couldn’t find anything relevant after some googling.
Currently I’m running Homeassistant Core on a dedicated Ubuntu machine, and OZW beta on another. They connect via secure MQTT and it all works with very little maintenance.
Is my understanding correct that if I migrate to ZWave-JS, I am forced to have a ZWave-JS server which exposes the network via unencrypted websocket on port 3000 and without any authentication support?
Documentation for the ZWave-JS integration says that instead of the ZWave-JS server one can use zwavejs2mqtt, but the zwavejs2mqtt also seems to be relying on the same unencrypted and unprotected ZWaveJS-server, and discourages the alternative use of MQTT discovery because “HASS updates often break it”.
Is there really no official way to have ZWave-js and HASS on two different dedicated machines? Looking for some ideas to work it around.
I think the better question is “Is there really no official way to have ZWave-js and HASS communicate securely between two different dedicated machines?”
As of now, securing the websocket connection has not been considered a priority. If you run both on one machine in containers (or using HA OS), you can isolate the connectivity between those two containers, or you can use MQTT with zwavejs2mqtt. I’m curious as to how often HASS updates break MQTT discovery, I know there were some recent breaking changes but I don’t think that’s normal. You can, of course, also not rely on discovery and configure MQTT manually but depending on the number of nodes in your network that would be quite painful.
With all due respect, unencrypted communication shouldn’t be an officially recommended solution I understand that it is not relevant when both apps run in containers on the same host, but exposing to unknown participants on the network is of course entirely different.
If anyone tried to set up zwave-js with MQTT discovery or manual MQTT configuration - can you please share your experience?
Fair, and also to be fair, I don’t think anyone is explicitly recommending that approach. Perhaps something worth opening a GitHub issue for to give the other devs more visibility into this, but the average users smart home installation assumes that their private network is secure, which is a bad assumption, but it’s the reality and at least one reason why this hasn’t been prioritized
I set up a small test zwave network running zwavejs2mqtt originally running from MQTT and I didn’t have any issues.
There was some talk of needing to restart zwavejs2mqtt after a restart of the mqtt broker (which many people run in a HA add-on - I don’t) because the container wouldn’t automatically reconnect. I don’t know if that has been addressed yet, tho.
I’ve switched to using the WS connection and away from MQTT (one less failure point) so I don’t have any recent experience with it to share.
I run zwavejs2mqtt in a docker on a separate machine from HAOS. In HAOS enter the IP address of the other machine in the Zwave-js integration and you’re good to go.
I originally ran using MQTT from the other machine before the HAOS adoption of zwavejs; discovery was just fine for the devices on my network. Now I have MQTT turned off because I don’t use any other MQTT services and rely on the websocket connection instead while retaining the UI functionality of zwavejs2mqtt . I don’t care about having its communications encrypted, there’s no personal information being sent just a bunch of discreet equipment states.
I have have zwavejs2mqtt running on a separate PI 3, not using the MQTT Home Assistant Discovery., instead using the ZwaveJS integration. It’s all runnning on a local network and works fine. I like this setup as it allows me to put the PI 3 in a location that has better coverage than where my HA server is located and when restarting HA it doesn’t have to restart the Zwave Network.
Why don’t you just use a combination of an ssh tunnel and firewall rules to secure it? End-to-end encrypted port forwarding is what it was built to do.
I understand that it is not relevant when both apps run in containers on the same host, but exposing to unknown participants on the network is of course entirely different.