I’m thinking of deploying Home Assistant in the following setup:
Home Assistant instance at home doing all the local automation
Dashboard available online that does not use the home HA instance directly. I don’t want to open a port at home to access Home Assistant remotely.
Ability to send events/run services remotely.
My idea is:
Set up a second instance of HA on a VM in the cloud.
Set up MQTT at home and on the cloud VM, sychronizing topics with each other.
Set up mqtt_eventstream on both Home Assistant instances
Set up a dashboard against the cloud hass instance
Does this sound reasonable? Am I missing something? Is there a different way to do it?
I expect I’ll be able to see all the states in the cloud hass instance. But am I going to be able to run services on the home hass instance by sending requests to the cloud hass API?
The main attraction of HASS is that it is not dependant on external cloud services, I am not sure which is worse, opening a port to internet or making your data available to a cloud service provider where we have less/no control over what happens to it.
Just a thought.
anilet, I definitely do not want to depend on any cloud services to run Home Assistant and I agree that it’s a big benefit of HASS. However, there are reasons why I prefer to serve my dashboards from a cloud VM. A web page or service served by a cloud VM is much faster and snappier than one served by a Raspberry Pi from my home. I’m also much less worried about putting my data in the cloud than opening up my home network. I have much more to lose if someone breaks into my home network.
I created a setup as described in the original post:
HA at home ←→ MQTT ←→ remote HA
It almost does what I want:
I can connect to the remote HA with the API
I can receive events through this API (e.g. sensor value changed)
I can send requests to run a service to the remote HA and my home HA will run this service (e.g. turn on the light)
What I cannot do is get all the states from my home HA through the remote HA (apart from listening to state change events and reconstructing the state). The /api/states API returns only states stored in the remote HA.
Is there a setting where the remote HA would update its own state based on received state change events?
I do have mqtt_eventstream set up but the state of one instance isn’t updated with the state changes happening in the other instance. In other words, state change events coming from mqtt don’t update the state.
I ended up making a nodejs script that reads local mqtt eventstream, and publishes the device information to another mqtt broker, transforming the json { value1=1 value2=5 entity_id=x} to mqtt messages:
topic: /device/x/value1 payload:1 retain: true
topic: /device/x/value5 payload:2 retain: true
I am planning to having 5 PI’s with zwave switcks controlling smaller zwave networks.
I haven’t gotten to the part that reads that data from the main home assistant but it should be fairly simple with template switches or something like that.
The pi with the stick has a local broker, nodejs, pm2 (nodejs process message installed). Once pm2 starts the nodejs process, it subscribes to local mqtt server, uses a api call to get all states (so it has on startup all the current state of the whole hass instance, not just what’s published).
The script is not finished, just proof-of-concept working, I’m trying to finish it up this week then publish on github.
I managed to get my setup working.
This is what I now have:
Home Assistant running at home with bidirectional mqtt eventstream enabled
Mosquitto MQTT broker running at home
A small script (suggested by @quasar66) that reads the MQTT stream of HA events and publishes states back to the same MQTT broker but in separate mqtt topics with retain=true
Mosquitto MQTT broker on a cloud VM exposing:
SSL-enabled port for the home MQTT broker to establish a bidirectional bridge
SSL-enabled Websocket port for web dashboards
Javascript code that connects to MQTT with Websockets and can
Listen on specific states (or all using mqtt wildcards) and update the UI when something changes
Send events back to Home Assistant through the same channel to run services
Advantages:
My home is behind NAT without a public IP and ports exposed
All external traffic is encrypted: remote MQTT broker has SSL, dashboards served via http
Dashboards are served from a fast VM over a fast network
Even when my home Internet connection is slow or flaky, the dashboards show up quickly
Data is pushed from Home Assistant to dashboards (there is no polling) so the data is as fresh as possible
Disadvantages:
I have to write my own dashboards instead of using the Home Assistant UI (I would still do it anyway)
I have to maintain a cloud VM (I do so anyway)
If anyone is interested, I can publish some code snippets to help set this up.
Based on what the script generates and re-publishes, can’t you re-generate dinamicaly the yaml for the remote instance?
Right now I’m working on generating yaml’s dynamically based on “raw” devices in home assistant. For example: I get all the zwave.* devices then based on some conditions (since I have a limited number of type of devices, I generate the config files).
It seems to be a lot more work upfront but much less in the future when I add devices. If I add a switch, it will dinamicaly appear everywhere it needs to - a nodejs script monitors the mqtt stream and the http api for home assistant for new devices and saves new config files into a svn repository. I have a script that checks every 10 minutes for updates there (in a sub-folder per instance) and if anything is new it runs svn update and hass-restart.
After i re-connect to mqtt to the slave, i also do a http://:8123/api/states and polulate missing data (events that haven’t been caught from mqtt) so that i don’t have to wait for eech device to appear in the event stream to update it.
Generating the yaml files sounds interesting. Maybe instead you could set the states in your using the /api/states/<entity_id> POST API. It doesn’t require the yaml definitions.
I’m not really interested in setting up the remote Home Assistant instance anymore so I’ll stick to just reading and writing mqtt.
Hi there I am trying to accomplish the same thing. So far you have the best approach for what I am struggling with.
In my case I can’t use forwarding ports with my ISP. So I was wondering if you can detail the steps you took, especially
the dashboards. I tried hadashboard with appdaemon but there is no way to password protect. For me this is “No go”
Hi @PeWu have you been developing this further or have you found a better alternative?
Like most people, I’m starting on a raspberry pi 3 and feeling the limitations of the system. The natural progression is to get better hardware. However, I’m exploring some options like running home assistant on a VM (or container) in the cloud and having local communication between some on premise hardware to handle the presence detection and other “local” activities.
I’m curious if you found a better way or just went with better local hardware
home assistant on a VM in the cloud has 1 advantage: you can have a fast web ui.
but running homeassistant completely on the cloud would be a bad idea. internet down, and all automations stop working.
@ReneTode yes I understand the concern – I realize this setup is not for everyone. My apartment has pretty stable internet, as do most cloud providers that would be running the VM. I imagine if I had a house and relied more on automations (irrigation systems, garage doors, door sensors, locks, etc) I would be more hesitant. I mostly just use lights and sensors.
I probably have more system resets due to the Pi resources getting low (and having to pull the plug) than I would have the complete internet going down at my house or at a major cloud provider.
What I’m wondering is: what is the best way to connect a VM instance running in a cloud provider while being able to scan the network for presence detection and connect to my esp8266’s running a BRUH multi-sensor and other esp8266 sensors like that.
Is it just having a local MQTT server (running on a Pi) that the VM can connect to, to get all the sensor data?
Also VirtuallyHere looks like a great way for people to connect local USB devices on a Pi (server) and connect them to a cloud VM (client). I don’t use Z-Wave USB sticks but it’s good to know that is an option.