HMCCU - Stört ein iODev wechsel das Modul? - Redundanz der CCU

[chris1284]

Hallo Zap,

ich habe folgendes Szenario im Kopf:
-CCU1 Master: alle Geräte dort angelernt, per IP an HMCCU/FHEM gebunden
-CCU2 Slave: selbe Config wie CCU1, immer aktuelles Backup der CCU1 drauf, Netzwerk gleich konfiguriert (und bei funktionierender CCU1 immer offline, ganz wichtig)
-FHEM mit einem CUL/HM-RPI-MOD und 2 paired (CUL_HM) Funksteckdosen
-Presence auf CCU1 mit timer wie lange nicht erreichbar (um restarts nicht als CCU offline zu deuten)

Wenn CCU1 im Netzwerk nicht erreichbar schaltet FHEM die zur CCU1 gehörige Steckdose ab. Die Steckdose von CCU2 wird eingeschaltet, CCU2 bootet selbstständig. Dies kann alles ohne eine an FHEM gebundene CCU geschehen, da die Steckdosen an FHEM per CUL/HM-RPI-MOD hängen. Durch Abschalten CCU1 wird ein Adresskonflikt verhindert, auch das Wiedereinschalten. Nach Ablauf eines Timers sollte CCU2 erreichbar sein, durch set rpcserver off und on  sollte nun die Verbindung zur 2. CCU hergestellt werden.

Nun die Frage: hätte HMCCU ein Problem mit der 2. CCU? EIgentlich ja nicht da sie per selber IP angesprochen wird und 1:1 das Abbild von CCU1 ist. Ich habe noch keine2. und würde das gerne vorher möglichst sicherstellen.

Da man ccu Backups auch in YAHM einspielen kann wäre evtl sogar ein redundantes FHEM+CCU auf pi denkbar
->FHEM1 per CCU1-Skript abfragen, wenn offline fhem auf Backup-Pi starten
->FHEM1 prüft CCU1, wenn nicht erreichbar YAHM Container auf Backup-Pi  starten
->CCU2 prüft FHEM1 und kann ggf. FHEM2 starten womit dann ein volles umswitchen von FHEM-SRV sowie CCU erledigt wäre.
Wobei das schon sehr übertrieben wäre. Wichtig ist eine/die CCU läuft.
Da hier alles (CCU, FHEM-SRV,Switch und zuküntig BackupPI/BackupCCU ) an einer USV hängen könnte man Fehlauslöser wie Strom weg, Netzwerk weg ausschließen.

[zap]

Variante 1:

Ich habe noch nie das Backup von einer CCU auf einer anderen CCU eingespielt. Das solltest Du mal googeln, ob da wirklich alles 1:1 übernommen wird und ohne weiteren Eingriff läuft (Stichwort HMID der CCU).
Wenn die 2. CCU wirklich identisch mit der 1. ist, dürfte sich das FHEM seitig auf den Neustart des RPC-Servers bzw. das erneute Registrieren bei der CCU beschränken. Garantieren kann ich Dir das nicht, da noch nie getestet.
Beim Einsatz von Switchen oder auch bei Namensauflösung per Internet-Router im lokalen Netz könnte es einige Minuten dauern, bis die neue MAC-Addresse zur alten IP gelernt wurde.

Variante 2:

Das erscheint mir die elegantere Lösung zu sein. 2 Raspberries mit FHEM und Software-CCU. Auf dem zweiten werden alle Services gestoppt. Du lässt ein Script laufen, das prüft, ob der 1. PI noch da ist und bei Ausfall die Dienste auf dem Backup-Rechner startet.
Vom 1. PI aus synchronisierst du per Cronjob und rsync den 2. PI. Du musst nur aufpassen, dass Du den 1. PI nicht aus Versehen wieder hoch fährst. Könnte man grundsätzlich in den Startscripts abfangen. Prüfen ob der jeweils andere PI aktiv ist und wenn ja, FHEM und CCU nicht starten.