Hi *,
I want to have a redundant HassIo system. Thus, I am planning to have two Rpi s with the exact same software and config image.
It is mandatory for my idea, to have to RPi s with the exact same MAC Address.
Can I use e.g. ‘ethtool’ from inside Hassio to do that?
Could anyone tell me how or which different approach I have to use?
BR,
Ck
Maybe you could try spoofing your MAC address as described here:
I’m interested in your project, could you tell me a bit more about how you want to achieve this?
One problem I would imagine would be if you have a Z-Wave or ZigBee stick, as the devices can only be connected to one stick and not easily transferred to another stick, so you would need something like a separate device with USB-over-IP for these sticks but then you have another single point of failure.
Well, the idea is as follows:
2* RPi3b+, 1* Arduino Nano with W5500 Ethernet shield.
Both RPis have the exact same software state, sharing the image via ‘dd’. The config is stored on a network storage.
They shall have the same MAC address.
The Arduino simply pings the primary RPi. As soon as there is no response, it send a magic packet (wol) to the secondary RPi, which then boots and takes over “seamlessly”, since it receives the same IP via DHCP due to its cloned MAC. The both RPi do not interfere, since the primary has crasht and does not responde to network traffic anymore.
This is not a perfect redundancy, but it should prevent the most common RPi failure I experienced: Death of the SD card.
I do not know if it will work yet, but I am optimistic.
How can I install ‘macclone’, as proposed in the post you linked, from inside the hassio SSH shell?
As to ZigBee, I am not familiar with it, but if you have peering with the hardware address of the zigbee dongle, the only way I see is to clone its MAC address in firmware somehow…
I’m really interested in this. Have you tried to see if it possible to reserve the same IP for both Mac addresses in your router. Or make both have static IP addresses.
It’s theorie until now.
But assigning the same IP address to different MAC addresses will be problematic. It can cause errors that are very hard to track.
Static IPs for both servers would require a proxy between the two static IPs and the attached services/devices… The proxy would have to choose the currently working one…
Static IP’s could work if the redundant pi was powered off until it is needed. The recorder database/mqtt would be out of date when it took over but it’s better than complete failure.
but you would have to reconfigure the server ip in the HA client/webbrowser…
It qould take you 30 sec or so to realize, to address the secondary ip…
not “seamless” 
I only used the first method from this link and not in connection with home assistant. I don’t know what your base OS is, but I assume you need to do this in the base OS and not in hass.io. As far as I understand the SSH into hass.io is an SSH into the docker container, but I’m not really sure.
yes, that’s exactly my problem. I installed the 64bit RPi Image.
The usual access with pi login does not work…
You mention hassbian in your title, yet talk about hassio. These are 2 separate things.
Hassio doesn’t have a pi user and isn’t a general Linux OS
Thank you for the clarification! I knew there was a difference, but didn’t know the details so far.
Ok, I found the missing piece. https://home-assistant.io/developers/hassio/debugging/
I will try this and report back…
Well, and there it happened.
The SD card holding hassio died yesterday.
The failover did not work. On the one hand my redundancy concept did not work.
But on the other hand, it doesn’t have to and that is very nice!
After the SD card died (obviously I didn’t notice it right away), Hass was still running with most functionality accessible, except for the Supervisor and the Configurator. Makes sense to me, since the “automation functionality” seems to be held entirely in RAM and doesn’t require to be accessed from the SD card during runtime.
This means that a dead SD card doesn’t break down the runtime, which leaves time to restore the backup image on a new SD card. Thus, the down time takes no longer then booting up the system.
Best
Ck