Testsystem und Devices: welcher Ansatz ?

[Uef]

Nachdem mein FHEM-System weiter wächst und komplexer wird, denke ich jetzt auch über ein Testsystem nach, um Updates und eigene neue Funktionen vorher verproben zu können.

Ich habe auch schon andere Threads dazu gelesen (https://forum.fhem.de/index.php/topic,96454.msg894909.html#msg894909 und https://forum.fhem.de/index.php/topic,96229.45.html).
Da wird aber mehr das Aufsetzen der 2. Instanz erörtert.

Meine Frage ist: wie macht Ihr das mit all den Devices, d.h. Sensoren und Aktoren, die ja für das Verproben und den Ablauf fast aller Module die Voraussetzung sind:

• Habt Ihr die doppelt ?
• Oder kann man die irgendwie "sharen" (zum Beispiel mit FHEM2FHEM ? damit habe ich mich mangels einer zweiten Instanz noch nicht näher beschäftigt)

Natürlich könnte man für einige Devices auch dummies als Ersatz anlegen, aber dann werden die Unterschiede zwischen den Systemen einfach zu groß und wirklich handhabbar ist das vermutlich eh nicht.

Aktuell denke ich darüber nach, FHEM auf Docker umzuziehen, dann wäre das mit der zweiten Instanz eher kein wirkliches Problem, aber die Frage der Sensoren etc. bleibt ja trotzdem.

Würde mich über Feedback und Eure Ideen sehr freuen.
Uwe

[juemuc]

Hallo Uwe,

ich nutze in einer VM ein Ubuntu-System als Testumgebung. Dort greife ich auf die gleiche HM-CCU wie das produktive System zu. Also ein zentrales System für die Sensoren und zwei "FHEM"-Systeme 

Viele Grüße
Jürgen

[Uef]

Hallo Jürgen,

vielen Dank.
Ich nutze ja keine CCU für HM, sondern nur den LAN-Adapter. Daher kann ich jetzt nicht einschätzen, in wieweit eine FHEM-Instanz die Steuerung da übernimmt, so dass sich 2 Instanzen gegenseitig stören würden.
Da die CCU auch stand-alone läuft, hat sie sicher genug Eigenintelligenz, so dass die Kommunikation mit FHEM auf einer höheren Protokollebene stattfindet (eher so im Sinne von Client-Server). Dann sollte das vermutlich kein Problem sein.

Beim LAN-Adapter bin ich mir da schon nicht mehr so sicher und habe noch größere Zweifel bzgl. z.B. eines USB-1wire-Adapters, der am Host hängen und von 2 FHEM-Instanzen angesteuert würde.
Gleiches gilt vermutlich für meinen MAX-CUL (ist ebenfalls via USB angeschlossen).

Wie kann man das einrichten ?
Oder geht das nur mit jeweils zusätzlichen Adaptern ?

[MadMax-FHEM]

Hallo Uwe,

zu CUL_MAX kann ich wenig sagen (denke aber im Prinzip gilt ähnliches wie bei CUL_HM)...

Ich habe ja (wie du sehen kannst) 2 Testsysteme (und bei Bedarf adhoc auch mal weitere   ).

Allerdings sind es Testsysteme! Keine Backup-Systeme!

D.h. klar habe ich/versuche ich gleiche/ähnliche Geräte/Devices zu haben...
Bzw. eben Module zu nutzen...

D.h. ich habe an allen 2 Testsystemen HM-Funkmodule. Aber hier ist es wieder Test. Ich habe ein HMOD-PCB direkt stecken und eines per USB. Das als Test für den Fall, dass mein HM-USB-CFG (den es nicht mehr gibt) einen Ersatz zu haben...

Ich habe auch einige Homematic Devices damit verbunden, welche die ich halt "mal so" gekauft habe (aber nicht [mehr] nutze) oder halt ein paar "billige" (Fenstersensor-Bausatz: 20EUR) damit "was dran hängt"...

Ich habe auch ein weiteres (bei Bedarf) ZigBee (deCONZ) Gateway...
Das ist ähnlich der CCU, d.h. ich kann/könnte auch das Test-deCONZ mit meinem Hauptsystem verbinden aber ich nutze das nur als Testplattform.
Also neue Geräte (angebl. HUE-kompatibel   ) erst mal auf's Testsystem mit Test-deCONZ, da dann testen, ob es wirklich geht (erkannt wird) und funktioniert wie ich mir das wünsche.
Wenn nicht: tja, dann halt umsonst gekauft     ABER: mein Hauptsystem ist sauber. Ich muss ja nichts "zurückbauen"...

Aber eigentlich nutze ich meine Testsysteme wirklich zum Testen.
Also neue (evtl. noch nicht über fhem update verfügbare) Module ausprobieren: wie ist die Installation (was ist nötig), wie stabil laufen diese, verursachen sie "Hänger", haben sie "Speicher-Lecks", sind sie wirklich "nützlich", ...
EDIT: aktuelle "Geschichte". Bislang hatte ich mit mqtt nix am Hut. Aber bevor ich das einfach mal auf's Hauptsystem werfe, dachte ich mir erst mal testen. Weil ich wollte/brauchte eine Steckdose mit schaltbarem USB. Gibt's mit WIFI und kann man Tasmota drauf machen und per mqtt einbinden. Also geflasht (OTA, war sehr einfach) und ins Testsystem integriert. Gut hat (nat.) nicht sofort geklappt aber nach etwas rumprobieren (und mitnotieren was ich so gemacht habe) ging's dann. Dann gelöscht und noch mal sauber auf dem Testsystem mit den Schritten wo ich dachte: so das sollte es sein. Ging   Dann ein wenig getestet. Jetzt läuft die Steckdose (wie geplant) auf dem Hauptsystem   Da 2 in dem Pack waren hängt die andere halt (bis ich andere Verwendung habe) am Testsystem. Gleiches mit Shelly RGBW2 den ich mir kürzlich gekauft habe... Usw.

Wenn die dann alle "Tests" bestanden haben, kommen neue Module u.U. auf das Hauptsystem.
Ich habe dann ja ein Bild von den Modulen und u.U. auch Installations-Orgien (die manchmal nötig sind) hinter mir und zwar auf dem TESTSYSTEM
D.h. wenn da was schief geht: unschön aber unkritisch...

Dadurch läuft mein Hauptsystem stabil.

Klar update (OS/fhem) erst mal auf den Testsystemen.
Ja klar da sind nicht immer alle Module/Devices (in voller Ausprägung) vorhanden aber es ist schon mal ein erster Test...
EDIT: wenn der gut geht. Dann eben u.U. auch das Hauptsystem. Geht da was schief werde ich nat. den Teufel tun und mein Hauptsystem updaten


Bei CUL_HM bzw. bei deiner Konstellation (mit LAN-Adapter) kannst du nat. relativ "schmerzfrei" (zum Test) einfach mal den LAN-Adapter bei einem fhem disablen und dann beim anderen enablen.

Devices kannst du ja entweder per fhem-Backup aufs Testsystem oder per RwaDef (plus Beachtung bzgl. model usw.) übertragen.

Aber das wäre dann ja fast eher ein "Backup-System" denn ein Testsystem...

Ansonsten kannst du nat. ein weiteres Funkmodul "spendieren" und dem dieselbe HMID geben und "mitlesen" (theoretisch/praktisch auch steuern aber dann ist bestimmt "Konfusion" angesagt )...
Meine Systeme haben UNTERSCHIEDLICHE HMIDs, bewusst. Ich will ja keine "Konflikte" etc.
EDIT: dann empfiehlt sich überall eine vccu einzurichten (sollte/kann man aber eh haben   )... https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU


Neue Funktionen, also notify oder myUtils-Subs teste ich auch erst mal auf dem Testsystem. Das geht für grobe Tests auch mal mit dummy...
EDIT: nat. nicht jedes notify etc. sondern schon eher "kompliziertere Konstrukte"... Bevor dann mein Hauptsystem danieder liegt während ich so vor mich hinprogrammiere...

Dummy: wenn du fhem2fhem vorhast (geht sicher auch, damit sich "was bewegt" auf den Testsystemen [ich kann mittlerweile auch ohne "Leben" testen   ] ) das wären dann auch "nur" dummy-Devices...
EDIT: es gibt auch die Möglichkeit mittels mqtt 2 fhem zu verbinden und auch was mit einem node-js Modul (fällt grad der Name nicht ein)...

Viel Spaß, Joachim

[Uef]

Hallo Joachim,

vielen Dank für Deine sehr ausführliche Antwort.

Ja, die Abgrenzung zwischen Testsystem und Backup ist ein guter Punkt.
Mein Ziel war zwar nicht direkt Backup, aber schon möglichst identisch zur Produktion, um alles im Zusammenspiel testen zu können.
Das wird man aber vermutlich so gar nicht machen (können), weil es eine ziemliche Menge an Testfällen wäre (bzw. eine lange Zeit in denen man das System einfach beobachtet, wenn man die Testfälle nicht aktiv triggern will).

Und vermutlich hängt es wirklich einfach auch am Typ des I/O-Devices bzw. Protokoll:
einen USB-Adapater sharen zu können, ist eher unwahrscheinlich, HM-Adapter fraglich.
MQTT nutze ich ebenfalls mit Shelly (auf Tasmota) und einem Interface zu OpenTherm (Heizung) und da ist das sicher kein Problem, denn da hat man ja einen eigenständigen Server (ist eh nur Software), den man problemlos aus zwei Richtungen ansprechen kann (im Grunde die von Dir erwähnte FHEM-Koppelung via MQTT - wenn man das mit Blick auf die Trennung von Test und Produktion überhaupt will).

Beim HM-CFG-LAN-Adapter habe ich mir aber wegen des eingestellten Produktes ähnlich wie Du einen Backup angeschafft, der sich derzeit langweilt; aber auch der benötigt ein paar dedizierte Aktoren und Sensoren. VCCU schaue ich mir noch genauer an.
Für 1wire sind die Kosten für einen zusätzlichen Adpater natürlich auch überschaubar.

Fazit für mich bisher:
ich denke erst nochmal über die genaue Zielsetzung für mein Testsystem nach. Mit einer begrenzten Auswahl an Devices bleibt halt das Risiko, dass nicht alle Änderungen, die mit einem Update reinkommen und in der Produktion genutzt werden, geprüft werden können. 
Aber letztendlich wäre das ein Abnahme- und kein Testsystem. Die sinnvolle Lösung liegt sicher wieder irgendwo dazwischen und ist recht individuell ...
Und nicht zuletzt hängt zumindest bei mir kein AKW hintendran 


Was mit verschiedenen Devices möglich ist, werde ich beizeiten ggf. mal testen, wenn meine beiden Instanzen laufen (erstmal steht der Umzug nach Docker an)

Danke und Gruss
Uwe