Suche optimalen ioBroker Systemaufbau mittels RaspberryPi

[mickym]

@da_woody sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

@mickym sorry, aber speicherplatz auf einer windose ist heutzutage IMHO keine ausrede mehr...
ich mein, mir ist auch noch keine SD gestorben. und ich kenn da bei meinen 3d-druckern keine gnade. da wird nix runtergefahren, raspi wird stromlos gemacht, genauso, wie der rp4 hin und wieder wegen undervoltage mekkert. noch nie ein reboot. (hängen an SP112 USB, der drucker an der schuko) einzig verweigert octoprint ein update von plugins.

Also das sehe ich einfach anders. Es geht mir auch nicht darum, dass eine SD Karte crasht, als vielmehr hier verschiedene Zustände zu sichern, die sind sonst nur mit viel Zeitaufwand wiederherzustellen sind. Und Speicherplatz ist in dem Fall schon ein Thema. Wenn ich trotz 1,5 TB ca. 20 Images von 2 PI s gespeichert habe, dann sind das 320 GB, statt 740 GB. Wenn ich dann noch bedenke, dass ich bei 16 GB und meiner Systemgröße noch 30% zur Verfügung habe, wären das bei 32 GB ca. 400 GB verschwendeter Speicherplatz und das ist sehr wohl ein Argument, wenn man keine lärmendes NAS oder keinen Desktop in seiner Wohnung betreiben will.
Vom Zeit und Energieaufwand ganz zu schweigen. Was das Schreiben und ggf. Wiederherstellen von SD Karten über Images an Zeit kostet habe ich ja unten schon beschrieben und meine ca 1,3 TB auf externen Platten zu sichern kostet mich ca. 6 Std. . Mal abgesehen davon, dass ich dann auf die Hälfte der Images verzichten müsste, meine Platten mehr als voll sind, ist das doch schnell dahin gesagt, dass heute Speicherplatz kein Thema ist.
Trotz aller technischer Weiterentwicklung davon zu reden, dass 400 GB unnütz verbrauchter Speicherplatz kein Thema oder Ausrede ist, halte ich dann auch heutzutage für fraglich bzw. falsch.

Und glaub mir, es gibt so einige „Updates“, die Du nicht mehr so schnell rückgängig bekommst, wo Du froh bist, das System schnell wiederzuhaben. Unabhängig vom iobroker, aber ein neues System aufzubauen und auch nur eine Wiederherstellung aus einer backitup Sicherung dauert ein Vielfaches der Zeit, als ein Image zurückzuspielen.

[Jan1]

@mickym
Du hast recht, wenn Du von ganzen Images der SD Karte ausgehst, aber genau das ist doch das was eigentlich schon overkill ist
Eine komplett Sicherung ist eben etwas viel wenn man bedenkt wie lange das Sichern und wiederherstellen dauert. In der Zeit setzt ich Dir ein sauberes Buster im aktuellsten Zustand auf, bügel das IOBroker Backup drauf und schau Dir bei nem Bierchen bei Deine Restor Versuch zu

[mickym]

@jan1 sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

@mickym
Du hast recht, wenn Du von ganzen Images der SD Karte ausgehst, aber genau das ist doch das was eigentlich schon overkill ist
Eine komplett Sicherung ist eben etwas viel wenn man bedenkt wie lange das Sichern und wiederherstellen dauert. In der Zeit setzt ich Dir ein sauberes Buster im aktuellsten Zustand auf, bügel das IOBroker Backup drauf und schau Dir bei nem Bierchen bei Deine Restor Versuch zu

Mal abgesehen, dass eine Wiederherstellung mit dem iobroker Backup, was ich so lese auch mal mehr als 1 Kasten Bier dauern kann ist ja wie ich geschrieben habe nicht nur der ioBroker und das System auf der Karte. Und im Moment heb ich halt verschiedene Zustände auf.

Egal jeder soll das so machen, wie er oder sie es für richtig hält. Allerdings ist mir bei der erhöhten Stabilität der SD Karten hier noch kein wirkliches Argument begegnet, warum ich auf größere SD Karten umsteigen müsste. So wenig sind 16 GB auch nicht, insbesondere auf einem Linuxsystem ohne GUI. Vielleicht sollte ich noch paar Adapter installieren

Wahrscheinlich werde oder bin ich einfach alt🤪

[Jan1]

@mickym
Eben, nur muss man auch sehen was nötig ist und was nicht. Du vertrittst recht hartnäckig die Image Variante (hatte ich zu Beginn auch), aber das ist eben in den meisten Fällen etwas zu viel des Guten.
Ich mach ab und an mal ein komplett IOBroker Restor, einfach um sauber zu sein, wobei das recht flott geht obwohl ich recht viel laufen habe (was für ein Pi eh zu viel wäre um den es hier geht).

Das Argument für ne größere SD habe ich oben schon deutlich beschrieben. Kostet nicht mehr und ich hatte noch nie ein Problem mit ner 32er. OK, davon ein Image ziehen dauert eben wirklich etwas länger. Genau deshalb ist diese Methode auch overkill

[loverz]

@mickym sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

@homoran Na bei einem Bierchen bin ich immer dabei -

und ja ich nutze den Win32Diskimager und habe bislang noch nie ein Problem gehabt, ein Image wieder zurückzuspielen.

Dabei fällt mir aber noch ein Vorteil für die kleineren Karten ein. Ich würde ja sonst doppelt soviel Platz auf meiner Windows Maschine verbrauchen, wenn ich größere Images hätte.

hier empfehle ich das usbimagetool, welches die images als guip-file speichert. Diese sind dann nur noch in etwa so groß wie die Belegung der Karten. Das zippen dauert natürlich, funktioniert aber einwandfrei!

[da_Woody]

@mickym kein problem, jeder wie er mag! allerdings sind IMHO 10 images pro pi auch etwas overkill?
nebenbei, welche NAS kennst du? bei mir steht eins 2m neben dem bett. unhörbar. das 2. steht im büro meiner frau. ok, da läuft ein frequentierter FTP drauf. das kann man hören manchmal. ich sitze jetzt gerade in meinem werkstatt büro, 1m weg von meinem mini-itx fürs smarthome und daneben einem pi. der kleine venti vom pi ist deutlich zu hören, vom itx hör ich absolut nichts. is ja auch unausgelastet. dein energieaufwand geht ins leere, der itx braucht nicht mehr als deine 2 pi's.
400GB unnütz verbraucht? dann säuber mal deine windose von grund auf! du wirst staunen, was an platz bei einer nackten win10 install verschwendet wird!
wenn ich meinen ganzen speicherplatz zusammen rechne (exl. ~30TB gespiegelt) bin ich bei 50TB. da kosten mit 400BG ein müdes llächeln...
klar, ein image ist schneller, allerdings bist du sicher , daß nicht dort schon eine ferkelei drinnen ist?
aber wie gesagt, jeder wie er will!

[Jan1]

@da_woody sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

daß nicht dort schon eine ferkelei drinnen ist?

Genau der Grund warum ich das auch mal gelassen habe. Man schleppt da oft verborgene Fehler mit und sammelt weitere.

[ostseereiter]

@mickym
Ja dann machen wir mal hier weiter. Na klar das ist halt jeden seine Sache.Ich bin auch dafür falls mal was schief geht und man hat ja nicht immer Zeit gleich alles wieder gerade zu biegen dann ist so ein Image halt Gold wert. Da ich SSD habe benutze ich sowas hier ein Kopfdruck
genügt und und in 10 Minuten ist alles gesichert

[Jan1]

@ostseereiter
Es ist nie ein Fehler, wenn man das ganze Medium klont, hat aber immer den Nachteil, dass das in der Regel lange dauert und man das nie regelmäßig macht. Das Teil aus Deinem Link ist nicht schlecht, hat aber noch den zusätzlichen Nachteil, dass man dazu auch noch die HW ausbauen muss.

Was gegen die Klonerei spricht, ist die Tatsache, dass das OS selbst durch wildes Basteln am IOBroker seltenst in Mitleidenschaft gezogen wird, warum also den Aufwand, das gleich mit zu sichern

[mickym]

@ostseereiter Na das sieht doch super aus. Aber bei mir ist es ja nur eine popelige SD Card und die habe ich auch in 5 Minuten gesichert - allerdings sind das nur 16GB und wahrscheinlich nicht soviel wie bei Dir.
Jedenfalls war ich auch froh, dass ich vor dem Zigbee Update gestern noch ein Image gezogen habe - sonst wäre ich gestern teilweise im Dunkeln gestanden.

[ostseereiter]

@jan1
ja ich habe so ein HP Client da bekommt man die SSD ohne schrauben raus zwei Handgriffe und sie ist raus.Das klonen mit dem Ding dauert 5-10 minuten

[Jan1]

@mickym
Ich habe die Probleme mit Zigbee immer noch nicht so ganz verstanden. OK, der Backitup hat hier ein paar Probleme wegen den neuen Abhängigkeiten des Zigbee das sauber wieder rückgängig zu machen und genau da hört bei mir das Verständnis für das Problem auf, weil der aktuelle Zigbee bei mir super läuft.

@ostseereiter
ich habe meine Sicherungs- HDD als Wechselrahmen im PC, muss nur ein Knopf am Wechselrahmen drücken um ein Backup anzustoßen und mach das nicht regelmäßig. Somit sind die Backups immer recht alt und hier ist das Problem. Wenn ich dann eins brauchen würde, dauert es recht lange den alten Zustand aktuell zu bekommen, was unterm Strich nicht wesentlich schneller geht als alles neu und sauber zu machen. Jetzt verstanden warum ich nicht so begeistert davon bin?
Hier spielt wieder viel Theorie und Praxis ne Rolle. Theoretisch ist das super und die Idee die dahinter steckt ebenfalls, nur in der Praxis sitzt eben noch einer davor, der das dann auch tun muss und das ist hier eben der Schwachpunkt

Ich mach das ganze nur, weil es in meinem Bekanntenkreis jetzt schon einige erwischt hat, die Ihr System von so nem Spinner verschlüsselt bekommen haben, der dann Geld fürs Entschlüsseln will. Ok, das passierte bei allen, weil sie den Anhang von einem Mail geöffnet hatten, aber die Mails sind mittlerweile eben nicht mehr so plump gestrickt, dass man sofort sieht, dass das nix ist was man klicken sollte.
Wenn mir das passiert, kommt meine Sicherung drauf.

[mickym]

@jan1 Da hast Du sicher Recht - wahrscheinlich ist es wie oft im Leben - die goldene Mitte. Sprich vielleicht sollte man sein System hin und wieder komplett neu aufbauen, um dann wieder ein neues Image zu ziehen.

Und nein bei mir tut der aktuelle Zigbee es nicht. Er hat dann ein Kommunikationsproblem mit dem USB Zugriff.
Das hat aber mit meinem System nichts zu tun, wenn es 5 Minuten vor dem Update mit der alten Version noch wie ein Glöckerl lief.
Und nachdem ich nun nur durch dieses Update nicht suchen will, meine Hardware nicht rausschmeißen will, weil ich nicht glaube, dass es irgendwas am System ist und es auch nicht an dem Stick liegen kann, sonst hätte dieser nach Zurückspielen des Image nicht wieder sofort alle Geräte erkannt.

Und als Ergängung:
Das Update lief ohne Probleme durch rc=0.
Ich habe alles versucht - mindestens 5-10 mal neu gestartet .Stick abgezogen und wieder drangehängt. Sprich mit dieser Adapterversion ist mein Zigbee einfach tot.

[Jan1]

@mickym
Mir geht es weder gegen die Backups noch gegen irgendwelche Adapter Versionen. Ich lese nur derzeit viel von Zigbee Problemen wegen dem Update und habe die eben nicht. Glück für mich bis jetzt, nur würde ich eben gerne mal verstehen was da los ist, damit ich nicht erst wenn das Problem bei mir auch aufschlägt danach suchen muss

Ich bin bei jeder alpha Version dabei am Testen und das auf dem Produktivsystem, weil ich wenn mal was schief lief mit dem Backitup Adapter sehr schnell wieder trocken war. Wobei für das viele Basteln verdammt wenig schief läuft (ist das langweilig).

[mickym]

@jan1 Hast mich erwischt - mit dem Image zurückspielen.- sind natürlich auch meine ganzen Logs weg und ich hab sie vorher nicht weggesichert. Aber im Prinzip ist es zu 100% das Gleiche wie in dem offenen Issue:

https://github.com/ioBroker/ioBroker.zigbee/issues/1105

Error: Error while opening serialport 'Error: Error Resource temporarily unavailable Cannot lock port' at Znp.<anonymous> (/opt/iobroker/node_modules/iobroker.zigbee/node_modules/zigbee-herd

Damit startet es.

Und ich hatte schon mal das Problem - da war der Zigbee Stick tatsächlich kaputt, das ist er dieses Mal aber definitiv nicht, da er ja mit der alten Version läuft.

Ein anderes Mal hatte ich ein Problem mit dem Zigbee ein Problem - weil er am USB Hub hing. Nur wenn der Adapter nicht mit dem Stick kommuniziert dann ist das Log auch im Debug Mode nicht sehr aussagekräftig. Habe ich alles hier schon mal durch: https://github.com/ioBroker/ioBroker.zigbee/issues/792

Und darauf habe ich ehrlich gesagt keinen Bock - das nun wieder mitlaufen zu lassen um dann MB LogFiles - diese Analyse zu bekommen:

Looks like problems with USB port...

Es scheint einfach die USB Kommunikation mit dem Adapter generell sehr empfindlich zu sein - um es vorsichtig auszudrücken.

Worüber ich einfach etwas angefressen bin, dass sowas halt im stable landet. Die Version 1.5 ist gerade mal 6 Wochen alt und die 1.5.5 wohl erst 1 Woche. Kann man denn nicht wenigstens mal die GitHub Issues lösen bzw. das mal ein paar Wochen beobachten, dass da keine Fehler auftauchen bevor das im Stable auftaucht?

Den Zigbee Thread gibts nun seit 15.4. und seit dem 5 kleine Updates - und immer wieder die USB Probleme dazwischen.
Wie gesagt ich helfe mit und teste gerne, aber freiwillig. Ansonsten ist mein System aber auf Stable, wenn ich nicht testen will, sondern einfach nur ein funktionierendes System haben will und mich um meine Flows kümmern will.

Zumindest solange der Admin Adapter 5 nicht im stable ist, wird mein Zigbee nicht mehr angefasst - und bis es soweit ist hoffe ich dann auf eine Version 1.6, die dann hoffentlich die USB Kommunikation zumindest wieder so stabil bei mir ist, wie unter 1.4.4.

1N4148 created this issue in ioBroker/ioBroker.zigbee

closed Adapter not starting after 1.5.5 update #1105

mickym2 created this issue in ioBroker/ioBroker.zigbee

closed Version 1.2.x is not stable #792

[Muchul]

@Matzeit

Ich habe seinerzeit meinen RPI3! über einen USB Stick betrieben, eine alte 1 GB SD karte war im Slot, damit der Pi schneller bootet, war aber auch nicht zwingend nötig.

Aber selbst wenn die sd Karte zum Booten benötigt wird:

Meine Anregung:
Nimm 3 USB Sticks (32 GB) richte den ersten einmal komplett neu ein. Installiere alles sauber, richte iobroker ein und kopiere den 2 Mal.
Nach Updates, die erfolgreich und zu deiner Zufriedenheit laufen, kopierst du den Stick wieder.
Wenn etwas passiert braucht deine bessere Hälfte nur den Pi ausschalten den Stick tauschen und einschalten.

Durch die Rotation der sticks beim Update, hast du immer zwei ältere Versionen von denen du weißt dass sie funktionieren.

Nur so ein Vorschlag.