[Gelöst] Seit iobroker führt CCU3 Programme verzögert aus

[karlo enzo]

@dondiak Mit dem iobroker im Docker und der Raspberrymatic in einer VM laufen die Prozesse doch schon isoliert in ihrer
eigenen Umgebung. Der Prozessor der DS718 ist damit noch nicht mal zu 10% ausgelastet.

[dondaik]

ist alles richtig ... und dann stirbt das netzteil

[Xel66]

... und dann stirbt das netzteil

... und versorgt als letztes Aufbäumen noch die HDDs mit Überspannung, die dann ihr Leben aus(r/h)auchen. Naja, dann kann man sich auf ein Gerät konzentrieren und muss nicht darüber nachdenken, ob die Hausautomation noch läuft und dafür sorgt, dass das Licht angeht oder die Rollladen hochlaufen. Ach ja, die Heizung liegt auch gleich noch mit auf der Flurplatte, weil ja keine Direktverknüpfungen durch den Einsatz von Geräten unterschiedlichster Generationen und Hersteller möglich waren und alles Mögliche durch die zusätzlichen Logikschichten erledigt wurden. Und Lichtschalter gibt es auch nicht mehr, weil ja diese ganz stylisch durch die Smartphonebedienung und/oder Sprachsteuerung ersetzt waren. Dieses Szenario könnte man noch weiter ausschmücken. Wohl dem, der ein externes Backup hat. SCNR

Gruß Xel66

[karlo enzo]

Das ist ja schon fast ein Totschlag-Argument --- das Argument betrifft aber im gleichen Umfang eine Aufteilung auf 3 Einzelrechner,
die an der Automatisierung beteiligt sind. Für meinen Fall habe ich eine NUC auf gleicher Rechner-Basis wie die DS718
vollinstalliert unter Proxmox als Reserve. --- (z.Z. meine Spielwiese zum Testen von Updates.)

[Xel66]

--- das Argument betrifft aber im gleichen Umfang eine Aufteilung auf 3 Einzelrechner, die an der Automatisierung beteiligt sind.

Nicht ganz. Kommt auf den Ansatz an. Ich bin ein Freund von dedizierter Hardware. Auf einen Rechner, der eine Visu hostet könnte man problemlos verzichten. Auf den Rechner, der die Hausautomation bedient im Grundsatz auch, wenn man viel auf Direktverknüpfungen setzt und noch alternative Bedienmöglichkeiten vorgesehen hat. Hat man allerdings alles Mögliche auf mehrere Rechner verteilt (z.B. die Logikebene wurde auf iobroker ausgelagert) reicht Dir eben ein Rechner nicht mehr aus. Dann müssen zwangsläufig beide Rechner laufen.

Ich persönlich glaube nicht, dass eine Zentralisierung der verschiedenen Aufgabenbereiche auf einen Rechner durch Virtualisierung der richtige Weg ist, weil dieses eben der single point of failure ist, und beobachte diese Entwicklung mit Interesse. Ebenfalls sehe ich die Auslagerung der Logikebene auf andere getrennte Hardware eher kritisch. Ich bleibe bei meiner Aufteilung auf mehrere Geräte und kann z.B. eine defekte CCU3/RM durch vorhandene andere Hardware auch am Wochenende problemlos ersetzen. Irgendein Pi findet sich immer aus einem anderen Projekt oder in der Schublade. Ein Funkmodul habe ich noch in Reserve, Netzteile ebenso. Ich glaube nicht, dass viele der Virtualisierer die notwendige Ersatzhardware (NUC/DS) für den Fall der Fälle in der Hinterhand haben (einige sicherlich).


Gruß Xel66

[dtp]

Wenn ich morgen ins Gras beiße, muss der ganze Mist eh von einem Fachmann entsorgt werden. Egal, ob nun zentral oder auf mehrere Rechner verteilt. Meine Frau wäre da hoffnungslos überfordert.

Machen wir uns nichts vor. Hausautomation ist was für Nerds. In meinem unmittelbaren Freundeskreis beschäftigt sich niemand damit. Ich werde da eher belächelt und meine Frau bemitleidet.

[Xel66]

Machen wir uns nichts vor. Hausautomation ist was für Nerds.

Es gibt hier im Forum schon ein paar Beispiele von geerbten, erworbenen oder erhaltenen Installationen. Ich behaupte mal, dass es einem Interessierten durchaus möglich ist, sich in eine sortenreine, dokumentierre Umgebung reinzudenken. Bei den teils wild zusammengewürfelten repräsentativen "Marktquerschnitten" die über unüberschaubare Winkelzüge zur "Zusammenarbeit überredet" werden, ist das jedoch arg zu bezweifeln. Die sind dann tatsächlich ein Entsorgungsfall. Darum auch mein Ansatz, ausschließlich Komfortfunktionen über Homematic zu realisieren, aber eine manuelle Bedienmöglichkeit vor Ort grundsätzlich vorzusehen und das KISS-Prinzip nicht aus den Augen zu verlieren. Das Haus muss auch bei abgeschalteter Zentrale vollständig nutz- und bewohnbar bleiben. Dazu gehört, das versteckte Aktoren ohne lokale Bedienmöglichkeit ein No-Go sind. Es gab da auch schon mal einen Thread, der sich mit der Nachfolge auf Grund "ungeplanter Unverfügbarkeit" (Krankheit, Tod, Scheidung) des Erbauers einer Anlage beschäftigte.

Bei mir gibt es nur eine einzige "Stolperfalle". Das ist die Ansteuerung der Heizugsdeaktivierung. Die lässt sich aber durch einfaches Steckerziehen in den Originalzustand versetzen, weil ich die Heizugsdeaktivierung über einen Öffnerkontakt realisiert habe. Im Original sind diese Klemmen der Gastherme gerbrückt. Außerdem ist hierfür ein Fallback über ein direktverknüpftes Wandthermostat realisiert (Parallelkontakt). Das würde dann wie ein Führungsthermostat arbeiten. Die "Umschaltung" geschieht auch automatisch.

Ich bin auch der Meinung, dass eine Immobilie mit heterogenem Gerätepark (verbastelte Installation eines Nerds) schwer oder nur unter Wert zu veräussern ist, wobei eine homogene Ausstattung durchaus von einem Erwerber als Wertsteigerung empfunden werde kann, weil er sich auf Grund von vorhandenen Dokumentationen in der Lage sieht, das System zu verstehen oder jemanden damit zu beauftragen. Das dürfte sich ähnlich wie der Automakt verhalten. Dort gibt es auch gut ausgestattete, gepflegte, getunte und verbastelte Autos. Alles wirkt unterschiedlich sich auf den Wert aus.

Gruß Xel66

[manfredh]

Ich persönlich glaube nicht, dass eine Zentralisierung der verschiedenen Aufgabenbereiche auf einen Rechner durch Virtualisierung der richtige Weg ist,...

Sie ist aber der entscheidende Schritt zum wirklich redundanten System: zwei NUCs mit Proxmox im Cluster.

[Black]

Sie ist aber der entscheidende Schritt zum wirklich redundanten System: zwei NUCs mit Proxmox im Cluster.

Zustimmung, wenn.... die funkhardware von beiden Systemen des Clusters erreicht werden kann

Black

[NickHM]

Hallo

um mal wieder zum Thema Fehlersuche zu kommen ...
Ich würde auf der ioBroker Seite alle Adapter ausschalten und nacheinander wieder einschalten. Den für HMIP zuletzt.
Oder (der vermutlich schnellere Weg) - den Adapter deaktivieren, der HMIP abruft.

Wenn der ioBroker komplett mit der Ausnahme HMIP läuft ohne die CCU zu bremsen, dann heisst es nicht mehr "ioBroker bremst" sondern "mit HMIP Abfragen von ioBroker wird die CCU langsam". Das wäre schon mal ein deutlicher Schritt zur Eingrenzung des Problems.