The instructions will rely as heavily as possible on graphical interfaces. Just make sure Docker is installed and running, and we should only need to touch the command line to build Portainer for the entry level guide. There will be plenty of opportunities to write code to configure and automate the devices after the install is complete. There will also be a method to pull configurations off of a Home Assistant install on a Raspberry Pi and migrate it over to the container. That is how the decision was made to start this particular blog. The Home Assistant install on my Raspberry Pi Model 1B is not as reliable as I would like it to be, so it is time to build a much more reliable container.
More computing power than Sputnik
I have covered the Portainer install in another entry, but we are going to go over how to make that container available immediately on reboot, in case you end up with a power failure or just need to patch. The typical method of doing this to the containers started in Portainer is to change the "Restart policy". But, you can't really do this from Portainer to the Portainer container, at least not in the versions I've used. This doesn't really matter, because we can issue a command for the setting. When executing the docker command to start Portainer, we can add the restart flag. I always choose "unless-stopped" so there is a lower risk of having a failed container stuck in a loop of attempted starts and failures.
Aggregate 1
Basic Portainer install instructions
In previous examples, the command to issue was:
docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer
The new example should be:
docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data --restart unless-stopped portainer/portainer
You can then setup log in using the IP of your docker host with the port specified in the command, port 9000.
A fresh new install
If this is a typical home hobby user, and the system is going to remain on the internal network only, there isn't much to do for administrative configuration. You can add a new administrative user, and maybe set up a group. The biggest thing that will need to be done is adding the volumes to the environment while we prepare to add Home Assistant. This is where the advanced users can play around a little. I have a discontinued device, so my instructions for adding a Z-wave/Zigbee USB dongle will need to be modified based on the settings for the device purchased. This is not a required configuration, but it does allow a home grown Z-wave or Zigbee network if you want to play around with one.
Recently discontinued dongle
A neat trick that you can pull off with containers is adding a flag to bind a file to the container. Since Linux treats everything like a file, that means we can bind the Nortek (or your device) to the container. First thing we need to do is create a file for persistent storage of the Home Assistant configuration. So, go to the Volumes section of Portainer and add a volume called hassconfig. Since Home Assistant is on Dockerhub, we don't need to pull the image prior to running it. Go to the Container section and select "Add container". We will give the container a name we remember, Home_Assistant is a good choice. In the image configuration we will give it the name homeassistant/home-assistant so that it pulls the latest image. Set the restart policy to "unless-stopped". We will want to set the "Network" to host so we can scan for devices. We will add the volumes as hassconfig -> /config, and then bind /etc/localtime as a read only mount for /etc/localtime. If you have a Z-Wave/Zigbee device, bind the device to the matching location (/dev/ttyUSBx -> /dev/ttyUSBx or /dev/zigbee -> /dev/zigbee) under the Runtime & Resources tab, and flip the switch to Privileged mode.
Once the configuration is complete, you should be able to reach the Home Assistant web interface by going to http://dockerhost-ip-address:8123
This is also considered an alternative install, so we will need to modify the configuration file when we want to add things. My recommendation is to look through the Available components and go through the steps outlined for the components you choose to add. You should have a functioning system ready for configuration, and capable of being a smart home hub if you follow the instructions properly.
Aggregate 2
As a final note on how to configure the Z-Wave and Zigbee devices, I'll refer to them as Z* from here on. There may be issues when you perform a kernel update or accidentally unplug and replug the devices in. The Z* standards have the devices show up as COM ports, like an old serial cable connection. This serial connection is part of the reason that the old IBM communication standard of MQTT is used for communication between Z* devices. As a best practice, it is a good idea to make sure that the devices show up correctly and consistently when you boot the system. I've added to my own system the rules to have the devices show up as /dev/zigbee and /dev/zwave by configuring /etc/udev/rules.d/ 99-usb-serial.rules with the lines:
SUBSYSTEM=="tty", ATTRS{interface}=="HubZ ZigBee Com Port", SYMLINK+="zigbee"
You can then bind the /dev/zigbee and /dev/zwave without worrying about the devices being reconfigured.
Coming soon, posts about creating containers from scratch and communicating across MQTT.
No comments:
Post a Comment