• 1 Post
  • 14 Comments
Joined 2 years ago
cake
Cake day: June 8th, 2023

help-circle


  • I was about to order a SLZB-06, but they were out of Stock. That one looks exactly what I want. I never really looked into NodeRed, but normalizing everything before using it makes sense. The SLZB-06 makes the Zigbee Network connections independent from any Servers and making everything going through MQTT makes you independent from any Software that has to communicate with the Devices. Sounds like a lot of flexibility and independence.


  • Matter and whether external connections are needed or not will be interesting to follow. My HA instance is internal only too, since it does nothing that needs me to access it over the internet. And Owntracks delivers to a separate MQTT instance that will have no internal devices. So my HA is shut off from the internet and I will pay attention to everything Smart Home I will buy, that it does not require an Internet connection too.




  • May I ask what Gateway / Dongle you use? Oh and that weather station sounds interesting, if you happen to have a Manufacturer / Model for me I would like to read up on that too :-)

    I am leaning towards MQTT too because of other solutions that already integrate into that. It looks like a great way to throw different Data into a single pool to make them accessible in the same way, no matter if it is a switch, temp sensor, Camera, GPS Data etc.


  • I am leaning more towards something that might be complex to set up, but has broader support and is future proof. And the latter one seems something that is not really clear for any of the current protocols. Maybe in 10 years things will have settled and everyone uses the same protocol, but who knows what it will be :-) I am leaning towards Zigbee2MQTT for now since my impression is that you are very flexible to do with MQTT. I already use MQTT for Frigate and Owntracks and if other devices put their stuff into MQTT I will I have a pretty open pool for all the data / actions, even if I switch from HA to something else in the future. I feel MQTT is here to stay for a while, but well… that could all be wrong, Haha!


  • Thanks for your input! MQTT is not an issue, I have Mosquitto running on both my installs (one with HA + Frigate on a remote location, the other one HA for me which is also used by Owntracks), so MQTT is not a problem. I will even set up a second one and connect them together to have 2 Brokers for the setup where I need Internet access (Owntracks) to MQTT and I do not want to share this MQTT instance with the devices for my home.

    My impression about Matter was too that it is not “done” yet and device support is poor. On the other hand you read at every corner that it will be the future. This is why the SkyConnect Adapter looked very interesting to me at first, but since most of the features I would use now (Z2M probably, Docker compatibility) do not seem to work yet, or at least not reliably.


  • To be honest, I might have mixed something up reading up on all those standards. After researching a topic, my browser usually ends up having a hundred Tabs “just in case I need that information again” and honestly… in all that information I can not find it specifically. My consensus reading all that information was: “Make sure for each device you buy that it works with your specific gateway, even if it says it works with protocol X”.


  • Thank you very much, that was very helpful! I am leaning towards Zigbee2MQTT and it seems to be a good choice.

    ZHA is out of question now, since how often I have to restart HA for updates, I am sure it would be annoying to me. My Mosquitto Instance however does not receive updates as frequent, so Z2M might be the better choice for me.

    Could you tell me what kind of Bridge / Device / Dongle you use? I often read Conbee II**, but this is not on the recommended list for Z2M. On the other hand I am thinking about getting a Network only Gateway (there are some on the recommended list too), so I do not rely on a USB connection that needs to be mapped to a Docker Container. Having pure Network connections and independent devices sounds like a more stable solution. Also I assume having a Networked Gateway instead of a USB connected one would be independent of restarts from my Containers or even the host.

    **Edit: It IS on the Recommended list, I just got confused because it is not listed on the USB section, but under Other :-)





  • As others mentioned, you probably do not need VMs. If you thought about VMs because of isolation, then yes. that might be a good idea.

    In an ideal world, if I had the budget / hardware, I would have a Server with multiple NICs (Network Interface Cards) connected to different ports on my Firewall for LAN and DMZ. Then I would create VMs for LAN and DMZ and on those the Docker Containers needed for that zone. Everything that is accessible from the Internet gets into the DMZ, the rest in the LAN. I could further lock it down by creating 2 DMZ zones and only put let´s say NGINX or Traefik into the Zone that gets exposed and the services behind the Reverse Proxy in the 2nd DMZ zone, which will still be isolated from LAN.

    But since I only have a small box with 1 NIC, instead I created VLANs on my Router and created a Docker Network for each VLAN. Every single service I run is a docker container and in one of the VLANs, appropriate to their level of exposure. I have one VLAN called LAN that obviously is connected to my LAN and 2 other VLANs where I basically do what I described above. One holds Traefik and has exposed ports to the Internet and the other VLAN hosts the Services which are accissible through traefik. With that setup you at least isolate network traffic and it is something I would look into if you plan to expose any of your services to the internet. Usually when you start with Docker, you probably would just expose Ports from the Containers, which get mapped to the IP of your host… and so all those Containers will have access to your LAN. At least try to separate that.

    The next thing I wanted to do, is run my Containers rootless, which means that no container has root permissions if in case something within the container decides to let the docker service do something malicious on the host, it should not be able to run as root. The caveat here is, that docker does not support VLANs in rootless mode. I spend half a day converting everything to Podman, because people where praising podman left and right if you want to run rootless, but then I found out that Podman does not support VLANs in rootless mode either :->

    Using VMs as described above would make the “I can not use docker rootless” problem less of a problem, but I decided against VMs because of Resources / Budget.

    What I can recommend when you start, do not try to make things too complicated until you are familiar with Docker and understand what you are doing. As you get better, you might want more and learn more stuff as you go.

    You could just install a Linux Distribution you are familiar with (I use Ubuntu Server LTS 22), install Docker and just play around with it a bit to see how everyting works. Only start exposing Services to the Internet if you know what you are doing.

    Maybe a few tips or keywords for you of stuff I went through step by step for later usage.

    • If you expose Services to the Internet, use a Reverse Proxy you think you will understand (NGINX, Traefik, Caddy…)
    • Try to segment your network if your Hard- / Software allows it to separate LAN Services from Services exposed in the Internet
    • Start documenting your setup from the beginning! If you are like me, everything is clear as you do it… but when I come back a month later I wonder how I set up the VLANs or what each Environment Setting does for a specific container etc ;-)
    • Instead of using Docker Volumes, think about redirecting Container directories to directories on the host instead. All my containers have their data under /opt/<container> and all my docker-compose files are in another, separate directory.
    • Implement a Backup solution early on (I use kopia, which backs up my compose directory and /opt, which should be everything I need to set up everything again on a new host)
    • Once you have a few containers up and running and think you are familiar how they work, start use docker-compose. Having a compose file for each container makes updating and maintaining them super easy. There is an updated image for a container? Just run docker-compose up -d and you are done. You need a variation of a container for testing? Copy the compose file, make adjustments and run it.
    • I use watchtower to automatically check if new docker images are available. I use it in monitoring mode. It will check and download for new images, but will not restart the containers. Instead I receive an E-Mail from watchtower. I can then check if the update is for a container exposed to the internet and then will let kopia do another backup run and just do a docker-compose up -d to restart / update the respective container, check if it still does what it does and am done.
    • Did I mention that you should document everything you do? If you are like me and have a memory like an earthworm, you should document your setup from the beginning ;-)

    All in all: Do not rush it, do not feel the pressure to do everything I wrote. You might even come up with other, much better fitting solutions for you than what I or others here are doing. The most important things? Have fun and think twice what and how you expose a service to the public :-)