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:
You really should make an effort to understand what you are doing and not following instructions blindly without comprehension. 30 minutes on basic docker instruction would go a long way.
/dev/zwave on the right side of the colon would mean that within the container the device name is /dev/zwave. That’s fine, but in the UI settings you then need to use that name.
I’m over here in docker docs (and have been since yesterday) looking at various commands to try and figure out what each does. For starters, Linux is not something I use regularly. At all. So, I get fairly turned around quick.
I get what you’re saying about the device mapping. Makes sense. What I don’t know is whether just making these changes to docker-compose.yml on its own is enough, or whether I need to stop and start the container, re-run docker compose, etc. And, if it’s necessary, how to do that.
This path may be correct. I never used /dev/serial path and always created udev rule for mounting usb and pci devices. In the case of zwave I have udev rule to mount it at /dev/zwave. How you do it makes no difference, the overall requirment is choosing the correct path so just verify it is OK which I believe you did.
The system may heat and lock up specifically because path is good and communication error. Communiction problems with zwave stick can cause system lock. You may want to unplug/plug zwave dongle from usb. I actually had same thing happen to me yesterday when accidently started a second container that tried to connect to same dongle. Locked the dongle up and it stopped working on my system. unplugging/plugging fixed it but that something I hadnt seen in years.
/dev/ACM0 path may not be good path. It will fail quickly on bad path with same error. like I said, verify path is correct.
Try adding yourself to dialout group.
########################
# Add User to Group #
########################
# -a append
# -G group
# -u set uuid of user
# -U create group with users name and add to group
sudo usermod -a -G <group> <user>
groups <user> #to check groups of user
EDIT: sorry put above info with little context
you should run below to add yourself to dialout. I dont remember if this matters or not sudo usermod -a G dialout <yourusernameonhost>
both are correct
ActualNameOnHost:WhatYouWantItCalledInDockerContainer
so sloppy). So many times after the rewiring, the disconnect issues went away entirely.
