literally means its not saved on the local machine. after it says downloading.
Basically, “I cant find this docker image locally so Imma go download it from the web”
zwavejsui, not zwavejs, should install just fine now
Just FYI. HA versions tend to be tied to zwavejsui version. So if you update HA you should expect to update zwavejsui. I set up an automation that tells me when HA does not communicate with my remote zwavejsui install. If it doesnt connect to it is is not a big deal as the entities just grey out and when its able to connect they just come back without any intervention required.
use websocket and not mqtt also. theres a toggle in settings of zwavejsui for both
I basically just look at the status of one of the nodes.
Not sure why I used the status of a specific device and not the status of the actual usb controller but it works well. The only issue i had was sd card on pi dying. I turned off HA logging and replaced sd card and 4yrs latter still OK
alias: Notify_ZwaveDown
description: ""
mode: single
triggers:
- entity_id:
- sensor.gate_switch_node_status
from: alive
for:
hours: 0
minutes: 0
seconds: 20
trigger: state
conditions: []
actions:
- data:
data:
tag: error
message: Z-Wave down from gate
action: notify.mobile_myphone
version: '3.7'
services:
zwave-js-ui:
container_name: zwave-js-ui
image: zwavejs/zwave-js-ui:latest
restart: always
tty: true
stop_signal: SIGINT
environment:
- SESSION_SECRET=xxxxxxxxxxxxxxxx
# Uncomment if you want logs time and dates to match your timezone instead of UTC
# Available at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
- TZ=America/New_York
networks:
- zwave
devices:
# Do not use /dev/ttyUSBX serial devices, as those mappings can change over time.
# Instead, use the /dev/serial/by-id/X serial device for your Z-Wave stick.
- '/dev/ttyACM0:/dev/ttyACM0'
volumes:
- zwave-config:/usr/src/app/store
ports:
- '8091:8091' # port for web interface
- '3000:3000' # port for Z-Wave JS websocket server
networks:
zwave:
volumes:
zwave-config:
name: zwave-config
I see the USB dongle is connected using lsusb -v:
Bus 001 Device 004: ID 1a86:55d4 QinHeng Electronics 800 Z-Wave Stick
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1a86 QinHeng Electronics
idProduct 0x55d4
bcdDevice 4.43
iManufacturer 1 Zooz
iProduct 2 800 Z-Wave Stick
iSerial 3 533D004242
I am as yet unable to get to the interface at [IP]:8091, so I’m not sure where I’m going wrong. I’ve added the stick and rebooted a couple of times. Is the device path correct? Would this prevent me from opening the UI?
“SESSION_SECRET” is a series of randomly-generated upper- and lower-case letters.
Additional device info:
x@xxxxxxxxx:/dev $ cd /serial
-bash: cd: /serial: No such file or directory
x@xxxxxxxxx:/dev $ cd serial
x@xxxxxxxxx:/dev/serial $ ls
by-id by-path
x@xxxxxxxxx:/dev/serial $ cd by-id
x@xxxxxxxxx:/dev/serial/by-id $ ls
usb-Zooz_800_Z-Wave_Stick_533D004242-if00
x@xxxxxxxxx:/dev/serial/by-id $
Your docker-compose.yml is likely wrong as you apparently haven’t identified your device but copied someone else’s config.
You can see why z-wave-js ui isn’t starting by leaving off the -d in the command you use to start it. It will log it’s output to the terminal you run it in. Maybe you copied “fancy quotes” into the yaml?
To identify your device correctly, run
dmesg -w
Then unplug the usb stick and plug it back in. dmesg will indicate the device path in it’s output. Once you have the device name you should be able to convert to the /dev/serial-by-id path.
Sorry, didn’t see your response as I was typing. /dev/serial/by-id/usb-Zooz_800_Z-Wave_Stick_533D004242-if00 is the correct path. You need to change both sides of the config in docker-compose.
You still need to run the z-wave-js-ui app interactively to see what it doesn’t like about your docker-compose file.
Thank you - here’s the updated docker-compose.yml:
version: '3.7'
services:
zwave-js-ui:
container_name: zwave-js-ui
image: zwavejs/zwave-js-ui:latest
restart: always
tty: true
stop_signal: SIGINT
environment:
- SESSION_SECRET=pTnbxvTZQHnW
# Uncomment if you want logs time and dates to match your timezone instead of UTC
# Available at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
- TZ=America/New_York
networks:
- zwave
devices:
# Do not use /dev/ttyUSBX serial devices, as those mappings can change over time.
# Instead, use the /dev/serial/by-id/X serial device for your Z-Wave stick.
- '/dev/serial/by-id/usb-Zooz_800_Z-Wave_Stick_533D004242-if00:/dev/serial/by-id/usb-Zooz_800_Z-Wave_Stick_533D004242-if00'
volumes:
- zwave-config:/usr/src/app/store
ports:
- '8091:8091' # port for web interface
- '3000:3000' # port for Z-Wave JS websocket server
networks:
zwave:
volumes:
zwave-config:
name: zwave-config
I’m not sure what you mean by that. It ought to restart on reboot, correct?
With the above docker-compose.yml & after a reboot… still no dice with seeing the UI.
I saw one reference to disabling Bluetooth in the config.txt file… is that required?
I add the serial port, then generate the security keys and save… and it just grinds away. Eventually I lose my SSH connection and can’t ping the RPi. Rebooted twice… same issue. WTF.
I’ve been working to rebuild a prior Z-Wave setup since October. Probably went from like 20 nodes to 95 nodes
Eventually I got to a point where the network became unstable as it grew. Then one night I said screw it and migrated everything that could support LR over to it.
Encountered some nodes that would drop, individually (with the old setup it often was multiple nodes).
From then on, The step that actually fixed the frequent disconnect issues more often than anything else was to actually rewire the switch. A few times I did see either wires not in all the way, other times bare ground wire ends that I rescraped the paint off of (why do painters paint the ground wires so sloppy). So many times after the rewiring, the disconnect issues went away entirely.
I suggest you try that as well especially since it sounds like these are fairly new.
Btw in general migrating everything I could to Z-Wave LR was a massive improvement, and is definitely something I recommend. One immediate benefit is a noticeable reduction in latency. Also Iirc LR adds additional bandwidth that gets used separately from the traditional z-wave stuff. Also I don’t get the cascading failures nearly as often when a particular device acts up. I’m 70 LR nodes and 24 traditional z-wave nodes now.
I prefer running my containers rootless. Each container has a unique UID (basically just I reuse the container name to match the username). In addition to being security best practice, running rootless further isolates them. With running rootless the container won’t have visibility to a device (eg z-wave stick) unless you explicitly pass the path in the devices declaration. So this is one way you can give a container exclusive access to a device at least at the container level).
It’s actually entirely unchanged from the one I posted above.
How would I find that out? I figured I was covering my bases by looking for the device with lsusb, etc… but I get that doesn’t mean anything to the container. I used sudo for all commands.
I don’t know if this is of any value; but I see this warning when running docker compose up -d:
WARN[0000] /home/josh/zwavejsui/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion
unable to get image 'zwavejs/zwave-js-ui:latest': permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.47/images/zwavejs/zwave-js-ui:latest/json": dial unix /var/run/docker.sock: connect: permission denied
Just for kicks, I changed the docker-compose.yml entry for the device to ‘/dev/ttyACM0:/devttyACM0’ and then added that path to the UI Z-Wave setup screen. It actually saves successfully, but gives me this error:
Makes sense, I suppose… but the behavior is markedly different when I use the correct path /dev/serial/by-id/usb-Zooz_800_Z-Wave_Stick_533D004242-if00. Saving with that entry results in a very hot RPi, SSH connection dropping, and having to hard reboot to get it to respond again.
I wasn’t sure until I went back to this post above. Yes, I did.
One thing I realized I had wrong was the device mapping in my docker-compose.yml file above. In the advice above, I read “you need to change both sides” of the config as meaning this:
so sloppy). So many times after the rewiring, the disconnect issues went away entirely.
