Just got the new pi 3b+ running Hass.io. Any ideas on what I could use the spare pi 3b for? maybe take the load off the main Pi…
Presence detection using Bluetooth?
1 Like
Ideas #1:
Main Pi for running “Critical” services… turning on/off lamps, presence detection and etc.
Secondary Pi for running “non-critical” services, eg. Web scraping, personal automations (“bin night reminder”).
Idea #2:
Secondary Pi dedicated to securing your home network. eg: SNORT, NGINX, PiHole, maybe OpenWRT to set it up as a firewall/router?
Idea #3:
Secondary Pi as a sandpit/testing environment to test out new feature and tinkering with UI.
Idea #4:
Dedicated MQTT server.
1 Like
Idea #5:
Use docker and create a swarm with both Pis?
I have a an old Tablet PC with a broken screen I use to run Nextcloud and influxdb. I use Nexcloud with the caldav component of HA to maintain a private calendar.
Unrelated to HA, it also has ttrss, gerbera and gpodder running.
Ohhhh what’s that? Sounds intriguing…
check this out:
This has been bugging me for ages and ages. I really want a development environment on a separate Pi. Not least because of the interminable wait times for HA (hassio) to restart.
But, I could never get my head around how this could be setup. How do you have a second instance for development which won’t interfere with the actual devices around your home and hence cause potential issues with the ‘production’ environment??? One obvious issue would be timed automations both trying to run at the same time and if that automation included a ‘toggle’ of any kind, results would be unpredictable (and wrong).
I’m happy to be shown to have missed something obvious… 
I think I would probably use “demo” platforms, but replicating your prod environment like for like would most likely be impossible.
Interesting… Can you expand a little please?
What does the Home Assistant Server Pi actually have on it, specifically in respect to HASSIO? And how does it interact with the HASSOS Automation Server, or if they are completely separate instances of HA doesn’t that require some duplication of code so how do you manage that?
I like the look of this but can’t quite work out how these two elements hang together. How for example does the Automations Server know about the Sensors on the HA Server?
There are several ways to go about this I mainly use Node-RED as it can use the entities from any connected HA Instance. This way you don’t need to duplicate code across the systems, on my main instance the top one I keep all my non essential sensors the ones doing polling, scraping etc and anything I need to be snappy and responsive like automation’s for lighting I have running off the automation’s Pi. I did this because just walking past a pir to activate a light by motion could take up to 30-50 sec to activate since moving over to this system everything happens instantly. The last Pi is just used for my database only when I need my separate HA Instances to know the states of the others I use the mqtt statestream component which posts topics to your mqtt broker about the states of all of your entities or you can filter it to just give the states of the entities you wish to know about.
Just to be clear 
Are you using mqtt_eventstrem to connect the two HA? I guess you have to, to make an useable UI?
Are you having Node-Red on your database server or the automation server? I understood from your writing it is on the automation server.
So just for an example
You have your sensors on the server, and the ‘actionable’ entities on the automation. You then have node-red listening to the server and performing the action on the automation server?
Very interesting! And maybe something I would look in to.
Yes so to have the one UI I use mqtt_eventstream which keeps any actions that happen with an automation to show in the UI.
I have Node-RED installed on the Add-Ons Pi along with grafana and inluxdb, the only thing installed on the automations server is hassos and the entities I need for my automations.
Before I went down this route my RPi 3b resources were struggling, with the pure amount of polling, pinging and general background activities I would commonly see cpu spike above 70%. With the new 3b+ running HassOS its never really goes above 4%, the original still is heavy on resources but I don’t notice anymore as its no longer impacting my automations.
I have some of this up on my repo I maintain both yaml and node-red based automations just for anyone that isn’t using node-red however about 90% of my automations are in node-red now as well as things that used to require scripts and complex templating.
I can do up a write up of my process if anyone is interested, my documentation is mostly up to date on my repo but there are a few flows I need to get up on there just need the right work/family/tinkerer balance.
I would externalize MQTT on the spare Pi…