Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Marty56]

Ich habe vor 4 Jahren mit iobroker begonnen und intensiv alle möglichen Use Cases und Szenarien implementiert, Hardware gekauft und viele Themen auch wieder verworfen. Diese "Sturm und Drang" Zeit hat ca. 1 Jahr gedauert und ist jetzt definitiv vorbei.

Mittlerweile ist für mich klar, dass Heimautomation eine (beschränkte) Anwendung für mich hat, aber ich sehe auch, dass es sehr viele grundsätzlich Beschränkungen gibt, die in den nächsten Jahren nicht überwunden werden. Ich denke fortgeschrittene Robotik, ...

Mehr und mehr stelle ich fest, dass ich keine neuen Dinge mehr implementiere, sondern vermehrt damit beschäftigt bin, meine Installationen zu warten und mir dabei wieder irgendwelche Migrationsprobleme einhandele, die zu unerwarteten Fehlfunktionen führen.

Diese Fummel kostet zu viel Zeit, bringt (vordergründig) keinen Nutzen und vor allen Dingen lerne auch nichts wirklich Interessantes, was meinen Horizont erweitern würde. Spricht es nervt nur noch!

Am liebsten hätte ich ein System, das ich nicht mehr anfassen muss und das sich ohne mein Zutun updatet, solange es aus Sicherheitsgründen notwendig ist.
Auf Funktionserweiterung verzichtet ich dankend, denn ich bin ja zufrieden.
Wenn ich jetzt schon wieder an die Nerverei mit der Umstellung auf Node.js 14 denke, wird mir jetzt schon schlecht.

Was mir also fehlt, wäre eine Strategie für faule Nutzer.
Was sollte ich unterlassen, wenn ich nichts ändern will.

Mir ist klar, dass das Thema Security Updates benötigt.
Mir ist auch klar, dass Security Internet Konnektivität sich bedingen. Ich habe deshalb versucht, sowenig Online Funktionen wie es eben geht zu nutzen. Dennoch sehe ich diverse Adapter, die zwangsweise Online gehen, die ich verwenden muss und die wenig transparent sind, bzgl. dessen was sie da eigentlich machen.

Bitte um Eure Meinung und Vorschläge.
An Polemik, Beleidigungen und Hinweise auf meine Inkompetenz habe ich kein Interesse.

[Thomas Braun]

@marty56

Stell deine Paketquellen auf stable. Und halte das System damit aktuell.

Wenn ich jetzt schon wieder an der Gewese mit der Umstellung auf Node.js 14 denke, wird mir jetzt schon schlecht.

Was für ein Gewese? Quelle auf 14 umstellen, ioBroker stoppen, Upgrade, ioBroker starten.

[Marty56]

@thomas-braun wenn es so einfach wäre. Das ich mein System auf stable habe, ist selbstredend.

[Thomas Braun]

@marty56 sagte in Ich bin zufrieden ...:

wenn es so einfach wäre.

Ist es. Alles andere ist jedenfalls keine Option.

[Marty56]

@thomas-braun
"alles andere ist keine Option".

Vielleicht bin ich dann wirklich reif für die Homeautomation Ansätze für Dummies von Apple oder Amazon. Was natürlich sehr schade wäre.

[Thomas Braun]

@marty56
Da bekommst du die Updates halt zwangsweise vom Anbieter. Meine Echos haben auch schon nach einem Update merkwürdig reagiert. Nur konnte ich da gar nicht sagen, ob und wann da was genau geändert wurde. Beim ioBroker ist das wesentlich einfacher möglich. Da sehe ich viel besser welche Komponenten angepackt wurden.

Ich verstehe auch die Schnappatmung nicht, wenn nodeJS angepackt werden soll. Ich springe hier öfters von einer auf eine andere Version. Rauf wie runter. Hat eigentlich immer funktioniert.

[Jan1]

@marty56
Dafür, dass Du so lange dabei bist, hast das Prinzip von IObroker wohl noch nicht wirklich verstanden.
IOBroker verbindet lediglich bestehende Homeautomation Ansätze verschiedener Anbieter miteinander und ist in dem Sinn kein eigenes Gesamtsystem ;)

Genau da liegt aber auch das Problem, da sich die eingebundenen Dinge schnell weiter entwickeln und darauf reagiert werden muss und das erfordert dann die Updates.

[Asgothian]

@thomas-braun sagte in Ich bin zufrieden ...:

@marty56 sagte in Ich bin zufrieden ...:

wenn es so einfach wäre.

Ist es. Alles andere ist jedenfalls keine Option.

Ist es nicht. Es gibt immer wieder

• Auffälligkeiten beim Update von Adaptern
• Adapter die mit "Breaking Changes" ins Stable gehen (absichtlich)
• Breaking changes im JS Controller die ins Stable gehen (absichtlich)
• Inkompatibilitäten von bestehenden Adapterversionen mit neuen NodeJS Versionen.

Letztendlich wirst Du dich meiner Meinung nach für einen von 3 Wegen entscheiden müssen:

• Weg 1: Keinerlei Updates. Das System einfrieren und so lassen wie es ist. Das wird so lange gut gehen wie du keinen Zugriff von/nach Aussen hast und sich an den Schnittstellen nichts ändert. Dieser Weg erfordert eine gewisse Abschottung des ioBroker Systems sowohl nach innen als auch nach aussen.
• Weg 2: Du besorgst Dir für Schlüsselhardware Dubletten, so das du an einem Zweitsystem ein Update testen kannst um zu sehen ob es Auffälligkeiten / Probleme gibt. Einspielen des Updates im Produktivsystem nur wenn es keine Auffälligkeiten gibt. In diesem Fall kannst Du relativ gelassen alle 1 bis 3 Monate schauen ob du Probleme bekommst und ein Update einspielen - ausgehend davon das die meisten updates zunächst erst mal keine Probleme machen.
• Weg 3: Du riskierst es so und machst in regelmässigen Abständen updates aus dem Stable Kanal. Dafür musst du dann aber eine gewisse Zeit einplanen. Ich würde dabei die Updatehäufigkeit irgendwo zwischen 6 und 12 Monaten sehen. Updates dazwischen nur wenn Du über Sicherheitsrelevante Probleme informiert wurdest.

A.

[Thomas Braun]

@asgothian

'Breaking changes' haben ja einen Hintergrund.
'Regressions' sollten im Beta-Bereich ausgemerzt worden sein.
Auch Inkompatibilitäten zu neuen NodeJS-Versionen sollten im Beta-Testing auffallen. Das ist natürlich bei weit verbreiteten Adaptern eher zu erwarten als bei irgendwelchen Nischen-Adaptern, die dann vielleicht auch abandoned sind. Da sollte man dann auch mal prüfen, ob man diese Exoten wirklich im System haben muss. Wenn ich einen Adapter nicht verwende, fliegt der auch aus meinem stabilen-System raus. Bzw. der wandert erst gar nicht vom Test-System rüber.

Updateintervalle von >6 Monate sind erfahrunggemäß auch eher komplexer in der Handhabung. Da kommt dann zuviel neuer/anderer Code auf einmal rein. Das könnte ich dann auch nicht mehr genauer eingrenzen, wo es ggf. klemmt. Insbesondere wenn man dann auch noch sein Betriebssystem in der selben Tour auf Stand bringt.

[Asgothian]

@thomas-braun

Klar, Breaking changes haben einen Hintergrund. Ob der aber für alle Nutzer und Use Cases relevant oder vorteilhaft ist darf getrost bezweifelt werden.

Bei Hardware spezifischen Adaptern ist es fast ausgeschlossen das alle ‘regressions’ im beta Bereich ausgemerzt wurden. Dazu wäre es nötig das alle relevanten Hardwarekombinationen im Beta Bereich getestet werden.

Lange Update Intervalle sind aufwändig - da hast du vollkommen recht. Wenn man aber ohne Testsystem das produktiv System blockieren muss sollte man sich gut überlegen wie oft man es tut.

A.

[Marty56]

@jan1 Genau solche Klugsch ... Antworten wollte ich nicht hören. Das hatte ich doch explizit geschrieben. Hast meine Post wahrscheinlich nicht zu Ende gelesen.

[Thomas Braun]

@marty56
Wenn man öffentlich eine Frage stellt kann man im Vorfeld auch keine Antworten ausschließen. Ist halt das Wesen von Foren.

[Jan1]

@marty56
Nein hast nicht, sonst hätte ich es nicht geschrieben.

[Homoran]

@marty56 sagte in Ich bin zufrieden ...:

@jan1 Genau solche Klugsch ... Antworten wollte ich nicht hören. Das hatte ich doch explizit geschrieben. Hast meine Post wahrscheinlich nicht zu Ende gelesen.

Bitte bleibe such du sachlich!

Um dir einen "Rat" geben zu können muss man auch sicher sein, dass du alle Parameter auch wirklich bis zu Ende gedacht hast.
Nicht dass es später heisst: "Ihr habt aber doch gesagt...."

Also:
Offline-Lizenz für vis kaufen, alles aus dem Internet nehmen und vor sich hin laufen lassen

Ist es das was du hören willst?

[Asgothian]

@marty56 sagte in Ich bin zufrieden ...:

Am liebsten hätte ich ein System, das ich nicht mehr anfassen muss und das sich ohne mein Zutun updatet, solange es aus Sicherheitsgründen notwendig ist.
Auf Funktionserweiterung verzichtet ich dankend, denn ich bin ja zufrieden.
Wenn ich jetzt schon wieder an die Nerverei mit der Umstellung auf Node.js 14 denke, wird mir jetzt schon schlecht.
Was mir also fehlt, wäre eine Strategie für faule Nutzer.
Was sollte ich unterlassen, wenn ich nichts ändern will.

Um das vielleicht noch einmal zu 100% klar zu machen:

• Eine Trennung zwischen "Security" und "Funktions" updates gibt es in der ioBroker Welt nicht (und beim Rest der Software wird das auch inzwischen Selten)
• Automatische Updates ohne Dein Zutun werden nicht funktionieren. Die Erfahrung bei PC/Mobiltelefon/Konsole/... zeigt das bei jedem update eine nicht zu vernachlässigende Anzahl von Verwendern damit Probleme bekommen. Selten alle - Nie keiner.
• Selbst wenn sich am ioBroker nichts ändert heisst das nicht das durch externe Einflüsse Dinge irgendwann einmal nicht mehr gehen. Das betrifft
  -- alle Dienste die irgendwie online laufen (ob vom ioBroker oder von extern)
  -- alle Adapter die direkt mit hardware kommunizieren - Hardware geht kaputt, Ersatz wird ggf. nicht mit den dann eingesetzten Adaptern kompatibel sein. (Beispiel: Zigbee Aqara Tür/Fenster Sensoren)
  -- Kompatibilität mit der eingesetzten IT Platform (Proxxmoxx, RPi, etc.) Der Entwicklungszyklus auf diesem Gebiet ist so schnell das nicht garantiert werden kann das Deine aktuelle Umgebung auf neuerer Hardware laufen wird, sollte Deine aktuelle Hardware aufgeben.
• Eine Strategie bei der Du dich zu 100% nicht drum kümmern musst und alles auf die kommenden x Jahre problemlos weiter geht gibt es nicht.

A.

[Thomas Braun]

@asgothian sagte in Ich bin zufrieden ...:

Eine Trennung zwischen "Security" und "Funktions" updates gibt es in der ioBroker Welt nicht (und beim Rest der Software wird das auch inzwischen Selten)

Deswegen präferiere ich als Server-System Debian, da wird nichts neues mehr released in einem einmal veröffentlichten stable-Release. Höchstens gezielte Backports bei Sicherheitsdingen.

[Asgothian]

@thomas-braun sagte in Ich bin zufrieden ...:

@asgothian sagte in Ich bin zufrieden ...:

Eine Trennung zwischen "Security" und "Funktions" updates gibt es in der ioBroker Welt nicht (und beim Rest der Software wird das auch inzwischen Selten)

Deswegen präferiere ich als Server-System Debian, da wird nichts neues mehr released in einem einmal veröffentlichten stable-Release. Höchstens gezielte Backports bei Sicherheitsdingen.

Nachvollziehbar - aber nur gefühlt 30% der sicherheitsrelevanten Updates stammen aus dem Betriebssystem selber. Bei ioBroker kommt der Rest über NodeJS sowie die im ioBroker verwendeten Pakete.

Seit ich mit dem ioBroker angefangen habe (noch mit Node 8 ) musste ich da 2 mal ran (auf 12, demnächst dann 14). Und mir kann keiner Sagen das Node 8 zu Node 10 zu Node 12 zu Node 14 nur Sicherheitsupdates waren.

A.

[Thomas Braun]

@asgothian sagte in Ich bin zufrieden ...:

Und mir kann keiner Sagen das Node 8 zu Node 10 zu Node 12 zu Node 14 nur Sicherheitsupdates waren.

Nein, natürlich nicht. Deswegen ja auch die höheren Versionsnummern...

[Homoran]

@asgothian sagte in Ich bin zufrieden ...:

noch mit Node 8

Spätzünder ;-)
bei mir war es 0.10

[Jey Cee]

@marty56 sei schlau, richte es ein das es Stabil läuft und Aktualisiere einmal im Jahr dein ganzes System. Kostet dich wenn es schlecht Läuft, einen ganzen Tag weil du alles neu auf setzen musst.

Du kannst dir aber auch einen Dienstleister suchen der dir die Arbeit abnimmt.

Wenn du dennoch vor hast es zu Automatisieren hast du ein neues groß Projekt. Ich hab das mal auf Betriebssystemebene gemacht.
Das geht eigentlich ganz einfach, gibt auch genug Anleitungen.
Was nicht einfach ist, manche Updates benötigen ein Neustart vom System und das kann schon mal dazu führen das nichts mehr läuft.
Und genau da fängt die Arbeit an.

Für ioBroker und Nodejs kann man ein bash script schreiben um es Automatisiert zu Aktualisieren.