I would love a baked in means of running multiple HA instances on different machines and having them seamlessly communicate via API, not MQTT or the like. I certainly hear about a lot of people running several machines.
So my use case is that I would like to have a central instance running on a server with my DB, Influx, and other containers. This is actually running on Proxmox, so I would love to be able to migrate my instance around more easily by removing the hardware connection of USB dongles.
Then the other instance(s) would be just a simple little rPi with HA and a few USB dongles. No logging, recording, etc. Not kludging stuff through MQTT but native HA communication and functionality. So if I need to monkey around with my main HA instance my ZWave, Zigbee, and Insteon networks can just keep chugging along.
In general Iāve had such great success with my Hue hub, Ecobee thermostat, Bond Hub, etc as stand alone devices that do their jobs really, really well. Then HA is serving the purposes of bringing those individual Ecosystems together. HA is quickly catching up to and exceeding the capabilities of some of the hubs out there but I still like the stand alone functionality. Honestly some of this functionality could get spun off into another product, in the same way that youāve been clearly delineating the rest of the stack.
I put my Z-Wave and ZigBee stick on a separate Pi without HA. Z-Wave communicates throug MQTT with the new OZWDaemon integratiom and ZigBee over REST (as far as I know). Works perfectly fine and if I mess around with HA, my zigbee and z-wave network are not affected. There are also solutions like Ser2Net or other USB-over-ip stuff.
Ah, good point on the MQTT. I should add a bit more detail. The hope would be to allow HA to be the sole location for setup and config of those communication stacks. The last I had looked at the MQTT and similar options they still had yet another web page configuration app you needed to use. To be fair, I have the same issue with the products I mentioned like Hue, Ecobee, etc needing their app still in some cases. For things like Zwave I enjoy just having the HA UI to work with. That lack of one extra step to setup and configure would lower the bar for users too.
Yeah, remote-homeassistant seems like the basic concept I had in mind, just built into normal HA.
Other use cases could be needing a second radio to cover a different part of your house or maybe a shed.
So I do know there are ways of getting similar functionality now. As long as weāre putting ideas out I thought it was worth mentioning an intentionally designed multi-HA concept.
Iāve looked into the USB-over-IP stuff at one point but didnāt get many warm and fuzzies, it felt like it was a problem waiting to happen. Plus you still have to take down and then bring back up your Zigbee/Zwave networks.
Yeah, I havenāt gotten into the guts of how HA communicates at the lower levels to know for sure. My suggestion is not to try to create a multi-captain implementation. The other instances would always be a ācrew memberā so to speak. They would be shipping data up to the main instance and responding to commands from that instance. The only UI available from that IP would be allowing you to connect it to the main instance.
Maybe it could work, if you specify if it is in server or client mode, client mode would on pass on sensor data to the server instance.
I could see for example a case where you have raspberry pi zeroās running in the house doing bluetooth presence detection with https://www.home-assistant.io/integrations/bluetooth_tracker/
But also USB dongles like the OP says could be useful, to place them somewhere you have better range.
Interesting. When I looked when that OZW stuff was first coming out you still needed their web interface. I guess it could be worth a second look. It does seem like it was pared down to just a daemon connected to a USB device which is nice.
I guess in general it feels like a large burden to have someone write an integration for HA but then have to go back and implement MQTT to put it on another device. If there were top down planning it would make it easier to break up where stuff physically lives. Though perhaps going forward people would push developers to create something akin to where OZW ended up rather than baking into HA.
If others are reading this thread, do you have other purposes for multiple instances? I feel like one or both of the podcast run two instances. I canāt recall why though.
I use room-assistant.io on pi zero wās distributed around the house for Bluetooth presence detection and itās published to HA through MQTT. No need for any HA functionality for this.
There are other options for this that donāt require any Home Assistant functionality. I showed some methods to do this without needing a second Home Assistant instance.
There may be use cases for multiple instances communicating with each other, however, in my opinion, the use cases that you and @TechRoach5 provided, donāt have a need for second Home Assistant instance. Donāt take this as an offense, just my 2 cents.
We were talking about MQTT in general, not OZW specifically Anyway, regarding OZW, you still may need the web interface for configuration of some advanced features, but since recently there are services in Home Assistant to add/remove nodes, heal network, set config parameters etc.
I shared a guide here on my github repo on how to put an Aeotec Z-Wave stick and a ConBee II ZigBee stick onto a separate Pi, which is not running Home Assistant, and connect them to Home Assistant.
Sorry, I donāt understand this. What do you mean with āhave to go back and implement MQTTā? Who needs to implement MQTT?
I run multiple instances, one for testing, one for production and one for ādevelopmentā. Two of them communicate with each other through the remote-home-assistant component I linked above. I use this so that I can have one instance running all the time and a second instance, that is a copy of this instance where I test out new integrations or Home Assistant updates before I use them on the production instance.
This interests me - the idea that some automations can still keep firing whilst main instances is bought down. Although no idea how someone would code this. Itās almost like running hot/hot instances for some automations.
Whatās the problem with MQTT? Itās a standard communication protocol for smart home stuff. What is native support for you and what communication protocol is native for you? The Home Assistant REST API? There are lots of core integrations, which are communicating over MQTT.
I agree MQTT is a pretty nice and fast protocol that solves (on the latest version) all needs which come upon such a solution. Instead, to focus to reimplement an existing protocol, we should use protocols that were designed for such effort before.
In looking at ZWave on HA, it was first brought in as a full integration. Now it is in the process of being backed out to use MQTT, which is the āre-implementing in MQTTā I was referring to. I am ok with services being setup and communicating via MQTT, it is quite capable of doing the daily data communication.
I guess Iām interested in how do we bring the āadvanced configā stuff into HA. And perhaps the answer always will be it is too hard or best done stand alone for those features. I can just see the continued explosion of new platforms and new protocols coming. Once you have stuff installed in your house youāre likely to leave that there, so you just keep picking up more systems to manage.
Iāve seen MQTT implemented in a commercial environment and it is extremely capable of doing massive amounts of data collection with some level of back channel control. However, it isnāt a replacement for a more advanced API or web interface.
FWIW, the remote-homeassistant youāve linked to is more or less what I had in mind. Just integrated into the core of the app itself. Though Iām maybe not reading how it works as you mention that but then say youāre sending data over MQTT. Isnāt the point of that component to send data using the API and have those devices show up in the main instance like normal?
Ok, I understand now what you mean. But the reason for the change from the current Z-Wave integration to the new OZW Daemon has something to do with the underyling OZW software, Iām sorry I donāt know the details. In my opinion the new OZW Daemon is a way better concept than the old integration, because with the old integration, your Z-Wave network needed to be restarted (which can take quite some time for large systems) on every HA restart, which is quite annoying while you are testing new stuff or changing configuration.
Which āadvanced configā are you talking about? For Home Assistant Supervised, there is an add-on that runs the OZW Daemon for use with Home Assistant and you configure everything through the HA UI (I just donāt use it, because I donāt run Supervised on my production system).
I donāt think you can compare MQTT to a REST API or a web interface, it all depends on use case. What functionality are you missing in MQTT compared to a REST API?
Yeah, Itās a bit confusing as I currently use a mix of both as I try to move away from remote-home-assistant because I want to change my process for testing new stuff before going live. Remote-Home-Assistant doesnāt use any MQTT. In the end I donāt want to feed data from one HA instance to the other HA instance, but rather have all data available for any HA instance (mostly through MQTT).
Having an armada is better than having just one battleship! One main instance at home and multiple secondary instances offsite. All interconnected via the zerotier add-on. It would be awesome!!!
Anyway, regarding OZW, you still may need the web interface for configuration of some advanced features, but since recently there are services in Home Assistant to add/remove nodes, heal network, set config parameters etc.