Hallo zusammen,
Ich habe zu Hause zwei FHEM-Instanzen laufen:
- Eine in der Mitte des Hauses auf einem Raspi3. Das ist meine Haupt-Instanz und da hängen alle Funk-Sender dran.
- Auf meinem Server im Keller eine zweite Instanz für alle IP-basierten Aktivitäten, die evtl. auch mal etwas mehr Last produzieren, sowie den Funk im Keller.
Die Kommunikation erfolgt mit HMLAND, FHEM2FHEM, RFEHM etc..
Aktuell laufen Projekte mit DbLog und DbConfig, die aber die Informationen nicht wirklich in einem strukturierten Datenmodell ablegen. Und nun meine Idee:
- FHEM wird so umgebaut, dass es eine zentrale Datenbank nutzen kann.
- Die Informationen werden Multi-Instanz-fähig abgelegt, d.h. alle vorhandenen FHEM-Instanzen können dieselbe Datenbank nutzen.
- Die fhem.cfg wird strukturiert in der Datenbank abgelegt inkl. Angabe der Node die diese nutzt.
- Die Logs werden - inkl. Angabe der erstellenden Instanz - in diese gemeinsame DB geschrieben.
- Events/Notifies kann ich Cross-Instanz auswerten, indem ich in der RegEx Instanz/Device/Reading/Status angeben kann.
Also mir würd's helfen, weil sich die inter-Instanz-Kommunikation vereinfacht. Wenn's für zwei geht, geht's auch für n Instanzen.
Habt Ihr evtl. auch den Bedarf nach einer derarteigen "Enterprise"-Lösung?
Der Umbau von FHEM wäre wahrscheinlcih umfangreich, aber fragen kostet ja nix.
Ciao,
plin
So eine DB ist ein Single Point of Failure und kann auch schnell zu einem Leistung-Nadelohr werden. Man muss schon etwas Ahnung haben, um so etwas betreiben zu können. Nichts für einen Durchschnittsbenutzer. Damit wird sich IMHO so ein gravierender FHEM-Umbau niemals lohnen.
Es gibt natürlich auch andere Ansätze, mehrere FHEM-Instanzen zu betreiben. Ich nutze dafür MQTT. Derzeit noch eher im Testbetrieb, aber es funktioniert schon sehr gut. Ich habe zwei Rechner (Cubietruch und Raspberry Pi 3) auf denen jeweils mehrere FHEM-Instanzen laufen (und werden durch Watchdog-Scripte überwacht und ggf. neu gestartet). So kann ich meine GUI, Logik, HM und EnOcean schön voneinander trennen. Alles wird etwas schneller und stabiler.
Klar, MQTT-Server ist ein eine zentrale Stelle, diese ist jedoch beim Ausfall innerhalb von Minuten neu eingerichtet, es muss keine Backups zurückgespielt werden etc. Auch leistungstechnisch gibt es keine Probleme - MQTT ist ein sehr leichtgewichtiges Protokoll.
Wenn ich mich Recht erinnere lässt doch Udo so ein paar von seinen FHEM Servern laufen. Alles über eine DB mit unterschiedlichen Schemas/Instanzen. Kann mich da bereits auch irren und das war mal was anderes.
Nein, Du irrst Dich nicht.
configDB kann tatsächlich als zentrale Datenbank genutzt werden und die Konfigurationsdaten für mehrere FHEM Installationen verwalten.
Zu DbLog kann ich nichts sagen, aber die Ablage des hostname, der die Daten dort ablegt, war jedenfalls vor langer Zeit schonmal im Geapräch.
Die grundsätzliche Idee ist also alles andere als "neu".
Zitat von: hexenmeister am 10 Juli 2017, 21:29:40
So eine DB ist ein Single Point of Failure und kann auch schnell zu einem Leistung-Nadelohr werden. Man muss schon etwas Ahnung haben, um so etwas betreiben zu können. Nichts für einen Durchschnittsbenutzer.
Genau das ist der Grund, warum ich dieses Feature von configDB nicht aktiv bewerbe. Das liesse sich hier im Forum nicht mehr vernünftig supporten. Denn mit sqlite sollte man so ein Vorhaben nicht unbedingt umsetzen und an der Einrichtung einer anderen Datenbank scheitern viele Benutzer ja schon bei einer einzigen Instanz.
wenn es 'nur' um remote angebundene funk ios geht kann man die meisten auch einfach per ser2net an fhem anbinden. ohne zweite fhem installation und fhem2fhem.
Ich habe drei FHEM-Instanzen produktiv laufen.
1. Auf jedem sind die beiden anderen per FHEM2FHEM angebunden, z.B. auf der 90er Maschine die beiden F2F_193 und F2F_194
2. Jede der beiden FHEM2FHEM-Instanzen auf der 90er Maschine hat in der Definition gesetzt "LOG:.*(Task_90).*"
3. Auf den beiden anderen Maschinen gibt es jeweils ein Dummy "Task_90"
4. Auf der 90er-Maschine läuft ferner ein notify, das auf "Task_90" triggert und den Inhalt ausführt.
Insgesamt also 6x FHEM2FHEM, 6x Dummy, 3x notify.
Resultat: Alles, was z.B., auf der 193er Maschine in die Dummy-Variable "Task_90" geschrieben wird, kommt auf der 90er Maschine zur Ausführung.
Bevor das alles sauber eingerichtet (und in den Ausführungsprozeduren noch ein wenig gesichert) war, hatte ich auch schon mal FHEM-Befehle, die im Kreis herumgeschickt wurden. Seit langer Zeit aber ist das vollkommen fehlerfrei, sehr performant und stabil.
LG
pah