4 ms·

The only negative thing I can say about HASS is that getting it running in Kubernetes with a USB Zigbee/Zwave adapter is a real pain. I've got a local cluster a

by tibbon 3y ago

The only negative thing I can say about HASS is that getting it running in Kubernetes with a USB Zigbee/Zwave adapter is a real pain. I've got a local cluster and had it working once, but had to rebuild everything for some unrelated reason, and haven't been able to get it consistently working since. There are too many in-built assumptions about how you're running it and the USB access. Documentation assumes that _maybe_ you're using an old version with some Helm chart. I'm normally pretty good at getting anything running in k8s quickly, but this is difficult! I'm going to say "screw it" and just run it bare on a Pi soon instead.

fnordpiglet 3y ago
What benefit would running it in k8s have? I’ve been running it on a bare pi for years without issue and have never once thought I needed abstractions upon abstractions… is this more a “because I can” sort of thing?
- NortySpock 3y ago
  High availability, I assume. I'm running HA in docker-compose (no USB device needs in my use case) , but being able to have docker-compose be the default tool that handles all of the external settings means I get something pretty close to Infrastructure-as-code, and that is nice for piece of mind and simplifying how the backup-and-restore process will work. Plus I can be very deliberate about the pace at which I upgrade HA versions.
- tibbon 3y ago
  Having one way to deploy software is great. If I want to run 10 different home services (Pihole, Minecraft server, Plex, whatever), I'd prefer to not need different ways of updating/backing up/provisioning each. Ideally K8s w/Flux is pretty great for this, as I can just make a change in SCM and then let it rip. Hardware dies? Drop in a new one and keep going. Backups handled by the larger system, instead of individual computers. Additionally, my VPN/DNS and other networking setups with CloudFlare zero trust and MetalLB make it really easy to securely access it from anywhere for whatever service I need, with minimal fuss. But... getting the USB parts working with K8s is so annoying, as their assumptions around using Docker or Containderd are pretty fixed. Obviously I need to set an affinity/requirement of the node having the USB device, but even after that it just doesn't seem happy. I can see the device in HA, but it never connects.
TheFuzzball 3y ago
Helm is an absolute mess in my experience. I'm using zigbee2mqtt in K8s and just pinning the deployment to a node and mapping the device as a volume: https://github.com/LukeChannings/kube-config/blob/3b61c7607c5559db8c5f040a312134f14a975e8c/apps/smart-home/zigbee2mqtt/deployment.yaml#L62C30-L62C30 https://github.com/LukeChannings/kube-config/blob/3b61c7607c... Should work the same for Home Assistant, but I don't use HA for Zigbee directly, instead using z2m -> MQTT -> HA, which I've found to be very robust. I'm waiting for a new K8s cluster (based on CM4) and when I re-implement all of this I'll get a network-based PoE Zigbee device (https://smlight.tech/manual/slzb-06/ https://smlight.tech/manual/slzb-06/), that way I can un-pin the deployment and look at high availability Zigbee via MQTT (something Home Assistant doesn't support)

by tibbon 3y ago

fnordpiglet 3y ago

What benefit would running it in k8s have? I’ve been running it on a bare pi for years without issue and have never once thought I needed abstractions upon abstractions… is this more a “because I can” sort of thing?

NortySpock 3y ago
High availability, I assume. I'm running HA in docker-compose (no USB device needs in my use case) , but being able to have docker-compose be the default tool that handles all of the external settings means I get something pretty close to Infrastructure-as-code, and that is nice for piece of mind and simplifying how the backup-and-restore process will work. Plus I can be very deliberate about the pace at which I upgrade HA versions.
tibbon 3y ago
Having one way to deploy software is great. If I want to run 10 different home services (Pihole, Minecraft server, Plex, whatever), I'd prefer to not need different ways of updating/backing up/provisioning each. Ideally K8s w/Flux is pretty great for this, as I can just make a change in SCM and then let it rip. Hardware dies? Drop in a new one and keep going. Backups handled by the larger system, instead of individual computers. Additionally, my VPN/DNS and other networking setups with CloudFlare zero trust and MetalLB make it really easy to securely access it from anywhere for whatever service I need, with minimal fuss. But... getting the USB parts working with K8s is so annoying, as their assumptions around using Docker or Containderd are pretty fixed. Obviously I need to set an affinity/requirement of the node having the USB device, but even after that it just doesn't seem happy. I can see the device in HA, but it never connects.

TheFuzzball 3y ago

Helm is an absolute mess in my experience. I'm using zigbee2mqtt in K8s and just pinning the deployment to a node and mapping the device as a volume: https://github.com/LukeChannings/kube-config/blob/3b61c7607c5559db8c5f040a312134f14a975e8c/apps/smart-home/zigbee2mqtt/deployment.yaml#L62C30-L62C30 https://github.com/LukeChannings/kube-config/blob/3b61c7607c... Should work the same for Home Assistant, but I don't use HA for Zigbee directly, instead using z2m -> MQTT -> HA, which I've found to be very robust. I'm waiting for a new K8s cluster (based on CM4) and when I re-implement all of this I'll get a network-based PoE Zigbee device (https://smlight.tech/manual/slzb-06/ https://smlight.tech/manual/slzb-06/), that way I can un-pin the deployment and look at high availability Zigbee via MQTT (something Home Assistant doesn't support)