Cannot connect to host core-zwave-js:3000 ssl:default

Looks like the same issue reported here

1 Like

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.