...
info 2022-03-09 21:56:49: zigbee-herdsman started (resumed)
info 2022-03-09 21:56:49: Coordinator firmware version: '{"meta":{"maintrel":0,"majorrel":38,"minorrel":88,"product":0,"revision":"0x26580700","transportrev":0},"type":"ConBee2/RaspBee2"}'
debug 2022-03-09 21:57:01: Zigbee network parameters: {"channel":11,"extendedPanID":"0xdddddddddddddddd","panID":6754}
info 2022-03-09 21:57:01: Currently 0 devices are joined:
info 2022-03-09 21:57:01: Zigbee: disabling joining new devices.
info 2022-03-09 21:57:01: Connecting to MQTT server at mqtt://10.79.1.33
debug 2022-03-09 21:57:01: Using MQTT anonymous login
info 2022-03-09 21:57:02: Connected to MQTT server
info 2022-03-09 21:57:02: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'
info 2022-03-09 21:57:02: Started frontend on port 0.0.0.0:8092
info 2022-03-09 21:57:02: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'
Ok, so I’ve added all my zigbee devices and renamed them in the zigbee2mqtt interface, and HA magically knows about them now (I have no idea how).
However, homeassistant doesn’t stay running. It starts up… stays running for a minute or two, and then dies with:
Mar 9 14:20:43 gluster2 systemd[1164]: Starting Home Assistant Container...
Mar 9 14:20:43 gluster2 podman[4914]: ae01f99733a14661e15d72f9e74421aea32330e1c81c84e02e908005db094a34
Mar 9 14:20:44 gluster2 systemd[1164]: Started libcrun container.
Mar 9 14:20:44 gluster2 podman[4978]: cc99a6d9d7c4efe6998f5192fb76b897ae2c12de28c500eada971e3650d80dbf
Mar 9 14:22:13 gluster2 systemd[1164]: container-homeassistant.service: start operation timed out. Terminating.
Mar 9 14:22:13 gluster2 systemd[1164]: libpod-cc99a6d9d7c4efe6998f5192fb76b897ae2c12de28c500eada971e3650d80dbf.scope: Consumed 21.486s CPU time.
Mar 9 14:22:15 gluster2 systemd[1164]: container-homeassistant.service: Main process exited, code=exited, status=111/n/a
Mar 9 14:22:15 gluster2 systemd[1164]: container-homeassistant.service: Failed with result 'timeout'.
2022-03-09 23:26:14 WARNING (Recorder) [homeassistant.components.recorder.util] The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly
2022-03-09 23:26:14 WARNING (Recorder) [homeassistant.components.recorder.util] Ended unfinished session (id=75 from 2022-03-09 23:24:14.615788)
2022-03-09 23:26:25 ERROR (SyncWorker_0) [homeassistant.components.dhcp] Cannot watch for dhcp packets: [Errno 1] Operation not permitted
The warnings are just because of the previous crash.
DHCI ended up disabling the DHCP integration in the config (done by removing the default_config: line and listing everything you do want manually. According to DHCP Discovery - Operation not permitted · Issue #62188 · home-assistant/core · GitHub, adding --cap-add=CAP_NET_RAW should fix that. (But note that there have been security vulnerabilities that use this capability to break out of containers in the past. Theoretically shouldn’t happen… but DHCP discovery doesn’t really add much in my opinion, so I just left it disabled.)
I wonder if it’s just taking longer to start on the RPi than systemd defaults to? Try putting something like TimeoutStartSec=600 in the systemd config (on the line above TimeoutStopSec).
For sdnotify/conmon: without the watchdog, those options should look just like those for the Zwave, Mosquitto, and Zigbee containers. Basically the whole podman command line down to --nameshould be identical.
Ooh, I was going to say “this is getting into general setup questions”, but actually there is something key which is important to my setup! It’s actually the recommended approach (from others on this forum), but is a little surprising — despite the name “zwavejs2mqtt”, the setup doesn’t actually use MQTT for Zwave
Instead, it uses a dedicated websockets connection on port 3000. (See -p 3000:3000 in the config — and note that it doesn’t require the mosquitto container or enable connections to the container localhost network with --network=slirp4netns:allow_host_loopback=true as the zigbee container config does.)
So, whatcha want to do here is: in the Settings GUI for zwave, find “Home Assistant”, and make sure WS Server is On, and set to port 3000. Optionally, you can disable MQTT Gateway — because we don’t have the network set up for it, that’s not working anyway, and despite what it says about “use only as control panel”, the Home Assistant websockets server takes care of that.
Once you have done that, go back to Home Assistant and enable the Z-Wave JS integration. That should make everything work.
Great will give it a try tomorrow. Yeah once everything is being seen in home assistant then I’m good with the rest of setup. I just don’t really have any understanding of how the containers fit together.
Is it possible to use MQTT on the zwave stuff? I kinda like the idea of having one interface for all the devices
Does the app work for you? When I run it I get a 400 Bad Request error. Similar to:
This seems to be because I have a proxy on my network and even though I list “lan” in the proxy exceptions domains somehow the app is using the proxy anyway.
adding this to my configuration.yaml fixed this issue:
If you’re using the ngnix config from above, what’s happening is:
for rootless containers, podman uses slirp4netns to set up a VPN-like network
Within that network, 10.0.2.2 is the “virtual router” — it’s an oversimplification, but for most practical purposes you can treat this like the 127.0.0.1 local-loopback address on a regular machine.
Correspondingly, you can see that the nginx.conf redirects incoming requests (via proxy_pass) to http://10.0.2.2:8123 — that’s the port that Home Assistant is running on
you can, in the above setup without a firewall, connect from an external system to either the ngnix proxy or to Home Assistant diectly — the former on https://hostname:8443 and the latter on http://hostname:8123. This is useful for debugging, but the idea is to a) forward 443 to 8443 with the firewall, and b) block all external connections to ports in the 8000 range. That way, nginx is the only way in from the outside
The packges coming to Home Assistant from outside are given their “real” source address’. But the ones that come from the Ngnix proxy appear to come from the container router interface — that 10.0.2.2 “loopback”.
That can cause confusion, which is why:
trusted_proxies:
- 10.0.2.2
which is why the others should matter.
Note that if you have 10.0.2.x as a possible address range outside of your container setup (like, if you have 10.0.0.0/8 as your local network!), you’ll want change the podman network config to use something else. (And I’m not sure offhand how to do that.)
Nah, I don’t have the Nginx part at all. I just have a squid proxy on my home network to enforce various policies for my kids. Home-assistant is not available externally, I use a wireguard VPN to access the HA instance externally if needed (almost never needed).
Minor update: edited the config for the certbot container so the secret certbot-creds are mounted in with permission 0400. (Read by root only.) Somewhere in April the certbot container started checking for that and bailing out.
