Nachdem es ja immer mal wieder Überraschungen nach einem Update gibt, hat mir jemand geraten, sowas erst auf dem Produktivsystem einzuspielen, wenn man es auf einem "Bastelsystem" ausprobiert hat.
So weit so gut. Einen zweiten Raspi habe ich dafür. Aber, selbst wenn ich einen zweiten CUL hätte und gesetzt den Fall, dass der HMLAN-Adapter mit zwei FHEMs umgehen kann, woher nehme ich ein zweites Haus?! ::)
Versteht Ihr, was ich meine? Wie kann ich meine Installation auf einem Bastelserver testen, ohne die Hauptinstallation zu stören?
Eine Zweite SD-Karte reicht doch dafür aus.
Karte 1 für Test,
Karte 2 für Prod.
Im Falle eines neuen release testest du eben mit Karte 1 alles durch.
Funktioniert das, kannst du auf Karte 2 das update machen und das produktiv nehmen.
Falls nicht, einfach so Karte 2 weiter nutzen und warten bis die Sachen die nicht funktionieren gefixt sind.
Die andere Frage ist, warum überhaupt ein update machen, wenn alles tut?!
Grüße
Owel
Die Idee ist natürlich gut mit zwei SD-Karten ;)
Ich habe einen zweiten Raspberry, um noch andere Dinge ausprobieren zu können. Ich mache eigentlich jedes Update, denn es kommen ja fast regelmäßig neue Module und Funktionen hinzu. Bei mir gab es bisher nach Updates keine Probleme. Zudem wird automatisch ein Backup erstellt...
Ok, das ist die Methode Backup. So mache ich das jetzt tatsächlich auch. Es liegt ohnehin immer ein Raspi mit einer Klon-Karte parat, falls man mal gerade keine Zeit hat und was abschmiert. FHEM liegt sowieso auf einem externen Stick und wird von meiner Synology regelmäßig gesichert. Die Logs täglich und das FHEM-Verzeichnis wöchentlich, beides mit einer Rotation von 8 Versionen.
Ich sehe es eigentlich auch so, dass man ein tadelloses System so beläßt. Aber manchmal braucht man doch die aktuellen Funktionen. Und richtig fehlerfrei kann eigentlich keine Version sein.
Bestes Beispiel ist bei mir die CUL-FW 1.58. Hier scheint niemand Probleme damit zu haben. Aber ich hatte die schon zwei mal drauf gehabt, immer gab es danach Unzuverlässigkeiten mit meinen IT-Dosen und den Lott-Rolladenantrieben. Deshalb fahre ich da immer noch die 1.55.
Was man jedenfalls machen kann ist ganz neue Module auf einem weiterem System testen. Mit Sonos und XBMC hab ich mir da schon eine Menge unmut der Familie zugezogen und erst wenn das 1a läuft auf das Hauptsystem umziehen.
Ein Grund für Updates können einfach auch neue Komponenten sein. Bei Homematic gab es einiges an neuer "Hardware" im letzten Jahr.
Eine weile lang benutzte ich einen extra raum Develop um dort einstellungen neuer geräte usw. zu testen. Der Develop raum war nicht vom Tablet aus sichtbar - die update problematik ist dadurch aber nicht abgefangen...
Zur zeit richte ich ein "zweit" System auf dem CubieTruck ein mit Sonos Dreambox und anderen Entertainment geräten.
Das Produktivsystem läuft ohne mucken und erfüllt seinen zweck, hier werden einfach keine updates mehr gemacht - irgendwann ziehen teile des Produktivsystems noch auf den Truck um - wenn alles läuft wird auch dort kein update mehr stattfinden...
Ein 'Zwischenweg' könnte eine zweite FHEM-Installation auf der selben Hardware sein. Mit einer Weiche im Startscript. Ist nicht so sicher, wie eine getrennte Karte/System aber doch weitgehend autark.
Dafür gibt es keinen Kampf um die Hardware we CUL-Sticks etc. Man muss lediglich dafür sorgen, dass nicht beides gemeinsam läuft.
Log-Verzeichnisse würde ich dabei eher gemeinsam legen. Und das ganze mit Hin- und Her-Übernehmescripten noch bequemmer machen.
Nachteil bei solchen Lösungen, wie 2 SD Karten und 2 Installationen auf der selben Hardware ist, dass man für's Testen das Produktivsystem außer Betrieb setzen muss. Das ist, meiner Ansicht nach, nicht wirklich Sinn der Sache, wenn ich mir schon ein Testsystem aufsetze.
Zitatdass man für's Testen das Produktivsystem außer Betrieb setzen muss.
Schon, aber, wenn man wirklich auch die Hardware-Steuerung testen will, wird es schwierig prallel zum Prod-System.
Man müsste dann fast alles doppelt haben (teuer). Oder nut die Sende-Empfangseinheiten (auch nicht billig) und auch das ist wegen der Wechselwirkungen mit PROD nicht empfehlenswert.
Am bestem, man baut daneben eine exacte Kopie des ganzen Hauses. Mit der gleichen Ausrichtung bezüglich der Himmelsrichtungen versteht sich 8)
Wenn man schon eine separate 2. Platform hat wäre zum reinen Testen noch FHEM2FHEM eine Möglichkeit, sich ein zweites Haus zu "beschaffen". Schöne Grüße, John
Gesendet von meinem iPhone mit Tapatalk
Homematic IOs kann man nicht über FHEM2FHEM anbinden.
Man muss für sich entscheiden, wieviel Sicherheit man haben will (und sich leisten kann).
Wie hoch die Verfügbarkeit sein soll? Was ist der Anwendungsfalldes Hauptsystems?
Und auch, was der Zweck des Zweitsystems ist.
Nur ein 'Smoketest'? => Da reicht ein zweiter Raspi ohne (oder mit rudimentären) Schnittstelleneinheiten.
Oder ein kompletter Stabilitäts- und Last-Lauf? => Ein zweites Haus wird wohl unverzichtbar.
Oder doch etwas dazwischen? Da muss sich jeder selbst entscheiden.
Zitat von: joshi04 am 18 Juni 2014, 16:34:45
Wenn man schon eine separate 2. Platform hat wäre zum reinen Testen noch FHEM2FHEM eine Möglichkeit, sich ein zweites Haus zu "beschaffen".
Ich denke nicht, dass das reicht. Viel Aufwand mit wenig Nutzen.
@ hexenmeister,
wie Du schon sagtest, es kommt darauf an. Für jeden Bedarf gibt es eine Lösung mit den individuell kleinsten Kompromissen.
@ marvin78,
zwar habe ich kein HM. Ich stelle mir aber vor, dass ich den HMLAN natürlich direkt ansprechen kann. So passiert es zumindest mit FBAHA und HUEBridge möglich.
edit: siehe Hinweis nachfolgender Post. Danke für die Richtigstellung.
Aber wie gesagt, das ist nur eine weitere Alternative und jeder mag selbst entscheiden, was für Ihn am Besten passt. Ich denke fast, die Möglichkeiten sind fast unbegrenzt.
Wenn man z.B. nur neue Module ausprobieren möchte, könnte man auch mit der Verwendung von configDB arbeiten bzw. über zwei unterschiedliche Startscripte steuern, eines mit, eines ohne. Ok, ich gebe zu, das deckt nicht die ursprüngliche Problematik beim Updates ab.
Was beim Curie sehr einfach funktioniert, ich habe das Produktivsystem auf einer SSD, das über den Eintrag auf der ersten Partition vom nand gestartet wird. Stecke ich eine microsd rein, wird davon gebootet. Und zur Sicherheit liegt auf der 2. Partition von nand noch eine Kopie des Produktivsystems. Und sollte irgend etwas passieren gibt es keinen Mangel an microsd-karten, mit der man den Eintrag auf der ersten Partition vom nand auch auf die 2. Partition zeigen lassen kann.
Nur so, damit uns die Möglichkeiten nicht ausgehen. ;)
Nein mit nem HMLAN geht das leider nicht, da er permanent mit seinem Meister verbunden ist..... Martin hat das irgendwo mal genauer erklärt.
Ist es nicht am einfachsten, ein Backup auf dem Pi zurückzuspielen, wenn was nicht geht?
Gesendet von meinem iPhone mit Tapatalk