This is part 2 of my homeassistant migration.
Here I’m showing how to put all the containers into one “stack” and how you can tackle specific things like the Shelly integration and notifications.
At a later stage I’ll also share some of my automation blueprints.
Homessistant normally only persists a few days of log data. To be able to really trace back events or use the internal graph engine (or grafana) for your dashboards, you probably want influxDB.
This is how you configure your instance connection:
With these snippets, you can now create a complete “stack” for homeassistant, so it’s easier manageable. As you can see, a few of the services have to be in the host network or e.g. deCONZ won’t be able to send its values correctly to HA. Complete docker-compose file:
And the according .env:
As you have seen in the docker-compose file, deCONZ is on the host network. It makes it substantially easier with the webservice communication. Since deCONZ or more precisely, the Phoscon app, stores its configuration internally, this should be relatively seamless.
For security reasons, best create a config backup before you switch. For me, it proved best, to first plug in the ConBee II stick while the Pi was powered down.
After booting, it was correctly found - and the container could pick it up correctly.
Note: The device that’s handed through to the container is /dev/ttyACM0 by default.
If all went well, you should see all your previous devices within the Phoscon app. And as soon as you enabled the integration in homeassistant, all devices will be also available there.
Also here: Name your devices in a sensible manner!
If you have a lot of Shelly devices like me, make sure, all have the latest firmware or they won’t all show up.
Also it is important for older devices that you check that
Internet & Security -> Advanced Developer-Settings -> CoIoT protocol
is enabled. Otherwise the devices might also not show up for integration.
Afterwards, if activated, the Shelly integration offers you all devices that are available on the network. You still need to configure each one separately and I strongly suggest to name them while adding or you’ll lose track pretty fast.
Overview of my current integrations
As you can see in the picture below, I have quite a collection of devices. So it is very important to keep naming things consistently.
Pushing alerts or messages
For me it’s normally pushover, since the API is quite nice (token based auth, direct https requests) and I am already using it all over the place with a bash wrapper.
So, imagine you want to know if someone opened/closed your front door, or movement in your kitchen while you are gone and nobody is supposed to be home.
How to integrate Pushover is extensively documented here and it works absolutely fine.
I’ll later add some implementation scenarios together with my lighting triggers in Part 3. A general usage for the “notify” service can be found here.
This is a short example for your local config, including also slack:
Will continue in part 3 :-)