#zwave-js-ui addon is no longer responding since upgrade from 26.3.4 to 26.4.1 and 7.0.0 to 7.1.0

1 messages · Page 1 of 1 (latest)

foggy apex Apr 4, 2026, 10:04 PM

I just updated my HA to latest, 26.4.1 and 7.1.0 and it seems that the zwave-js-ui addon is no longer responding to the websocket port 3000. The ws-server toggle is turned on (I turned it off and on again)..

Curl from the HA shell is showing nothing listening there any longer:

~ # curl -v a0d7b954-zwavejs2mqtt:3000
* Host a0d7b954-zwavejs2mqtt:3000 was resolved.
* IPv6: (none)
* IPv4: 172.30.33.0
*   Trying 172.30.33.0:3000...
* connect to 172.30.33.0 port 3000 from 172.30.32.1 port 44140 failed: Connection refused
* Failed to connect to a0d7b954-zwavejs2mqtt port 3000 after 0 ms: Could not connect to server
* closing connection #0
curl: (7) Failed to connect to a0d7b954-zwavejs2mqtt port 3000 after 0 ms: Could not connect to server

Continuing...

When I exec into the docker container, it's definitely listening:

root@a0d7b954-zwavejs2mqtt:/$ netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:8099            0.0.0.0:*               LISTEN      191/nginx: master p
tcp        0      0 127.0.0.11:38427        0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:55214         127.0.0.1:8099          TIME_WAIT   -
tcp        0      0 127.0.0.1:47314         127.0.0.1:44920         TIME_WAIT   -
tcp        0      0 127.0.0.1:40826         127.0.0.1:8099          TIME_WAIT   -
tcp        0      0 127.0.0.1:42458         127.0.0.1:44920         TIME_WAIT   -
tcp        0      0 :::44920                :::*                    LISTEN      153/node
tcp        0      0 :::3000                 :::*                    LISTEN      153/node
udp        0      0 127.0.0.11:53849        0.0.0.0:*                           -
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           153/node
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           153/node
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
unix  3      [ ]         STREAM     CONNECTED     13802601 191/nginx: master p 
unix  3      [ ]         STREAM     CONNECTED     13802600 191/nginx: master p 
unix  2      [ ACC ]     STREAM     LISTENING     13799948 40/s6-ipcserverd    s

The docker outside does not indicate that there is anything listening on that port... I can't see a docker proxy or anything. I've looked at the code but can't really see anything relevant, unless the fairly recent update to the alpine base image may have changed a firewall setting?

I have identified the problem. For some reason, the IP address above is incorrect - I'm guessing that something inside the HAOS docker setup is caching a bad IP address... How to fix?

The DNS is correctly resolving the IP address:


; <<>> DiG 9.20.22 <<>> @172.30.32.3 a0d7b954-zwavejs2mqtt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60614
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 35447636a9565d9f (echoed)
;; QUESTION SECTION:
;a0d7b954-zwavejs2mqtt.         IN      A

;; ANSWER SECTION:
a0d7b954-zwavejs2mqtt.  3577    IN      A       172.30.33.5

;; Query time: 0 msec
;; SERVER: 172.30.32.3#53(172.30.32.3) (UDP)
;; WHEN: Sat Apr 04 18:15:24 EDT 2026
;; MSG SIZE  rcvd: 99

however, curl is seeing something else:

18:16:10.701687 [0-x] * [MULTI] [INIT] added to multi, mid=1, running=1, total=2
18:16:10.701749 [0-x] * [MULTI] [INIT] multi_wait(fds=1, timeout=0) tinternal=0
18:16:10.701815 [0-x] * [MULTI] [INIT] -> [SETUP]
18:16:10.701852 [0-x] * [MULTI] [SETUP] -> [CONNECT]
18:16:10.701889 [0-x] * [READ] client_reset, clear readers
18:16:10.701946 [0-0] * [MULTI] [CONNECT] [CPOOL] added connection 0. The cache now contains 1 members
18:16:10.702084 [0-0] * [DNS] asyn-ares: servers=172.30.32.3:53
18:16:10.702121 [0-0] * [DNS] asyn-ares: fire off getaddrinfo for A+AAAA
18:16:10.702256 [0-0] * [MULTI] [CONNECT] -> [RESOLVING]
18:16:10.702307 [0-0] * [TIMER] [ASYNC_NAME] set for 4999000ns
18:16:10.702348 [0-0] * [MULTI] [RESOLVING] multi_wait pollset[fd=4 IN], timeouts=1
18:16:10.702403 [0-0] * [TIMER] [ASYNC_NAME] expires in 4998903ns
18:16:10.702445 [0-0] * [TIMER] [ASYNC_NAME] gives multi timeout in 5000ms
18:16:10.702505 [0-0] * [MULTI] [RESOLVING] multi_wait(fds=2, timeout=1000) tinternal=5000
18:16:10.702610 [0-0] * [DNS] ares: addrinfo done, query status=0, overall status=0, pending=0, addr=found
18:16:10.702678 [0-0] * [MULTI] [RESOLVING] Curl_multi_will_close fd=4
18:16:10.702736 [0-0] * [DNS] is_resolved() result=0, dns=found
18:16:10.702768 [0-0] * Host a0d7b954-zwavejs2mqtt:3000 was resolved.
18:16:10.702798 [0-0] * IPv6: (none)
18:16:10.702814 [0-0] * IPv4: 172.30.33.0
18:16:10.702839 [0-0] * [DNS] Curl_resolv_check() -> 0, found

Things I have tried to resolve the problem:
[x] Run the ha supervisor repair command
[x] Restart the ha supervisor
[x] Restart the entire HAOS VM

Update: restarting the entire VM seems to have cleared the broken cached IP address and zwave is now working again

solemn patrol Apr 4, 2026, 10:25 PM

Sorry I don't have any idea how to help but you seem to know more on how to troubleshoot it then me but do you think it might be related to the issue I'm having?
https://discord.com/channels/330944238910963714/1490078639625211914
I tried to reconfigure mine after it stopped working but also can't get a response on a0d7b954-zwavejs2mqtt:3000
Restarting has not helped for me

foggy apex Apr 4, 2026, 10:27 PM

you need to restart the entire host or VM that runs the entire home assistant.

that's what just fixed it for me.

note that I had a weirdly stale IP address somehow cached in my instance. see the curl command above. to fix it, i had to restart the entire VM, because you have no other means to access the external system to clear the broken DNS cache (a real downfall of the HAOS model)

do note that the a0d7b954 may well be specific to my instance - that's a hash of somekind. you'll need to find out what yours is.

solemn patrol Apr 4, 2026, 10:30 PM

I'm running it all on a HA green and I tried both restarting the "app" and the entire device and it didn't work.
But just after writing to you i tried to reconfigure one last time (like the 6th time) and it just worked. Same address as before. Hadn't touched it for like 2h because i got stuck and now it just worked.

foggy apex Apr 4, 2026, 10:30 PM

sounds like it was a dns caching issue. they will tend to clear up after the cache goes stale. the default config in HAOS seems to be an hour or two.