|
From: Brian M <mis...@si...> - 2025-07-26 17:31:45
|
TL;DR: Giles described implementing fail-over. Brian describes diskless
booting, need for replication, and split-brain issues.
----
Good to hear from you.
I changed the subject to aid others in finding this topic later, because
I think you've got some really good information in your post (below)
regarding MH reliability and redundancy. I think you've got a great
set-up, and as a result of your post I may head in the same direction.
Thank you!
I have two critical RPis doing separate tasks, but really either one
could handle both workloads. I could reconfigure them as primary and
back-up along the lines of your set-up.
Diskless
Personally, I've always worried about the SD card failing. As a result,
I've configured my two RPis to be diskless. They each PXE boot from a
central server that runs mdadm-style RAIDed disks. Root, /var, MH's
home, and everything else are provided via NFS.
Replication
One nuisance issue I see with your set-up is that you need to make sure
that MH's home directory is kept in sync between the two systems. A bug
fix on one side needs to be applied to the other side, too. Presumably
you're doing some automatic Rsync's or something to handle this. In my
situation, I have another solution...
My MH home lives on a separate NFS share on the central server.
Combining my set-up with what you've done, I wouldn't even need to
replicate MH configuration and code data between the two RPi's data. The
two RPis would still need separate /, /var, etc. to maintain their
separate configurations, but either system could mount the MH home share
whenever that system became the active system. The newly active system
would have the latest, up-to-the-moment, MH data, right down to the log
files. This same technique could be applied to my OpenHab system, or any
other app I wanted to share.
Split-brain
The other issue that fail-over set-ups have classically run into is the
"split-brain" situation, where some network issue makes the backup think
the main system is down when it's not, and now you have two active
systems trying to run the world. The DRBD project (ref:
https://linbit.com/drbd/) recommends an alternate communication channel
(another NIC, maybe some sort of usb-to-usb link, even just a couple of
wires between GPIO pins) solely to allow the backup to confirm the main
system is really out of service. MQTT's LWT ("last will and testament")
function might fill this role, too, if it doesn't live in one of the RPIs.
Split-brain is not going to be a day-to-day issue, but will probably
happen to everyone with a failover set-up sooner or later. Have you run
into this, and how have you handled it?
Home Assistant
Re HA: I went with OpenHab because I perceived HA to have a "My way or
the highway" attitude, and their installation models didn't match my use
case. OpenHab has a smaller community, to be sure, but I'm pleased. I
never used HA, so I don't know the reality of HA and I can't really
compare them.
---
Some day I'll learn to write a short post, but apparently not today. :-/
Thanks again for your post. Great stuff there.
-Brian M.
On 7/26/25 03:14, Giles Godart-Brown wrote:
> Hello Brian
>
> Long time.
>
> I don't think I can answer your question, but I have now changed the
> way I use Misterhouse to increase reliability as follows;
>
> * Complex logic - keep in Misterhouse
> * Simple logic (like timers and pirs switching lights) - use
> Tasmota's rules wherever possible
> * Comms protocol - Mostly MQTT via mosquitto
> * UI - Home Assistant
> * Interface to difficult devices (like tuya) - Home Assistant
> * Voice commands - Alexa - to HA - to MH
>
> I've also discovered the pi keepalive daemon
> (https://github.com/justinknguyen/Pi-Guide/blob/main/Pi-Guide/keepalived.md)
> which allows me to run Misterhouse (and other services) on a pair of
> Pis that automatically look after each other and switch if one fails
> but keeps a common IP address.
> For example I was worried about mosquitto being a really important
> single point of failure, now I have two pis, the master is on
> 192.168.100.23 and the backup on 192.168.100.24 but the common address
> 192.168.100.25 is automatically associated with the currently running
> server. All I have to do is set all my devices to look for
> 192.168.100.25 and keepalived looks after the routing.
> I use the same for Wireguard VPN and Misterhouse.
> Unfortunately Home Assistant is dropping support for native Pi OS
> installs, and only concentrating on HA OS which means I cannot use
> keepalived. For now I'm thinking I will just have to have a cold
> backup machine on standby with a remote power switch so I can power it
> up manually if the master fails.
> Regards
> Giles
>
>
> On 26/07/2025 08:11, Brian M wrote:
>> I'm diving into so-called voice commands for the first time, though
>> I'm really just using mhsend to send a command from another computer.
>> The basics work fine, but in one case I'd like to pass an arbitrary
>> file name, and have my code receive that file name. Something like
>> "play file <filename>" and have my code be able to retrieve whatever
>> was specified for <filename>. Can that be done, and if so, what's the
>> syntax to define the voice command with an arbitrary string?
>>
>> -Brian M.
>>
>>
>>
>> ________________________________________________________
>> To unsubscribe from this list, go to:
>> https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>
|