What version of the Z-Wave JS are you using?
I’m at a loss… sorry! I use a USB stick so it maybe something with the HAT.
Maybe. Thanks for your help.
Figured it out.
The last update must have over written the /boot/config.txt file. It deleted a line that had been added to enable the HAT. This rendered the HAT inoperable.
Thanks again for your help
I had the same issue - I was able to fix it by choosing the device from the drop-down in the Z-Wave JS Add-on configuration. It was unset for me after the update (I did not check if if was set before the update). My update path was 0.1.50 → 0.1.51.
Hope this helps anyone else having the same issue
1 Like
had the same problem started with a aeotec sensor 6 falling off ,
in the end had to reinstall zwave js and zwave 2 mqtt , 8 hrs later still waiting to get my locks and remotec back but the sensor6 is back …
Fix for me was selecting the “emulate hardware” checkbox.
I just started to see this error message (Failed to connect: Cannot connect to host core-zwave-js:3000 ssl:default [Connect call failed (‘172.30.33.0’, 3000)]) when I upgraded HA from 2022.5.5 to 2022.6 so all my Zwave devices are unavailable. My Zwave-JS is at 0.1.60 which seems to be the latest. The device selected in the Zwave configuration is /dev/serial/by-id/usb-Silicon_Labs_Husbz_Smart_Home_Controller_41500EAD-if00-port0. There is a port1 device in the list also but I think that is the Zigbee; I tried changing it to port1 but it wouldn’t stay selected after restarting. I am running in a VM environment; my ZWave/HA had been working fine for well over a year. I have rebooted the host PC with no improvement. Any suggestions?
I’m having this same issue, started yesterday. Trying to see if your fix is what I need, what line needs to be back in that /boot/config.txt file?
I am having the same error since this moring.
Seems to have come after the 2022.6.5 core update
Did you find a solution to the problem? For me it started approx 24 hours after I upgraded to 2022.6.6. Updated zwave_is to 0.1.61, but that didn’t fix it.
Thanks for the link, reverting fixed for me it seems. Looks like the latest zwaveJS update broke it for me.
For anyone else coming along looking for an answer, what ended up solving it for me: I had the zwave stick connected to a USB hub, which worked fine for the old zwave setup, but apparently not for zwavejs. Swapping my zwave stick to be plugged directly into the pi instead of through the hub seems to have fixed it.
2 Likes
I also ended up here after a recent update. Got the same Failed to connect: Cannot connect to host core-zwave-js:3000 ssl:default [Connect call failed ('172.30.33.7', 3000)] error.
When I went into the configuration for the ZWaveJS add-on, in the section “Network” I needed to toggle the “show unused” whatevers. The option for “Change the ports on your host that are exposed by the add-on” was empty, so I just filled it in with “3000” and restarted the add-on. Worked after that.
A bit odd, though, as it implies that 3000 is the default.
Exposing the port makes the Z-Wave server available outside of your HAOS host. The integration doesn’t use the external port. Restarting the add-on was probably what fixed it.
I had done a restart of the add-on prior to that and was still getting the error. Might try turning that option off later and see if it was a red herring.
I would check the add-on logs next time. The integration will fail to connect if there’s an issue with the add-on starting up.
The integration uses the the alias of the add-on (core-zwave-js) to communicate over the internal docker network (where the alias resolves to 172.30.33.7 in your case, an internal IP). It’s explained more at Add-On Communication | Home Assistant Developer Docs. This add-on does not use the host network.
Exposing the port just allows external hosts to talk to the add-on. If you think about it, it wouldn’t make much sense for the add-on to require an exposed port to function with HA, and at the same time disable it by default and not mention anything in the documentation.
I removed it and restarted the add-on, still working just fine.
I did notice while attempting to restart the add-on it was…quirky. Like, clicking “stop” didn’t work out the gate without hard-reloading the page once or twice. I suspect you’re correct about it not having fully/properly restarted, but I think I got hood-winked by the UI glitching out a bit.