Die Downloadzahlen sind für mich kein Kriterium. Hausautomation ist meist simple WENN-DANN-Logik und benötigt von vornherein keine objektorientierte hochkomplexe Sprache. Beweis: es geht grundsätzlich auch mit den sehr eingeschränkten Möglichkeiten eines HAP (mit einer CCU ist natürlich mehr möglich). Anders ist es. wenn man die CCU mit Dingen beschäftigen will, für die sie nicht vorgesehen ist (z.B. Aufbereitung von Daten für Visualisierungen etc.). Komplexe Dinge kann man ja m.M. auslagern, aber grundlegende Steuerungen müssen autark (Direktverknüpfungen) oder eben mit simpelster Logik (CCU) funktionieren. Datenbanken, Visualisierungen, Einbindungen von Fremdsystemen sind besser auf potenterer Hardware aufgehoben.Henke hat geschrieben: ↑03.12.2022, 23:27Klar, ich setze mich mit dem Hersteller auseinander, um die Lücken in einem veraltetem System zu flicken.
Oder ich nutze die Möglichkeit objektorientiert mit Java/Javascript zu programmieren auf einem System mit grob 30.000 Downloads in der Woche.
Ich nehme, leider zu spät, B.
Betreibt jemand ein Bastelhome mit Gerätschaften verschiedenster Hersteller und unterschiedlichster Protokolle und Kommunikationswege, ist das Kind sowieso schon im Brunnen. Dann kommt es darauf auch nicht mehr an. Ich betrachte Hausautomation neben dem Nutzen als Komfortverbesserung auch als Hobby, aber ich möchte mich mit dem System nicht auseinandersetzen müssen. Ich möchte mich auseinandersetzen wollen und wenn ich keine Zeit habe oder sich meine Prioritäten verschieben, möchte ich damit nichts zu tun haben müssen. Es soll einfach nur tun, was es soll, möglichst ausfallsicher und wenig zusätzlicher Infrastruktur angewiesen sein und im Falle eines Defektes mit einfachsten Mitteln wiederherstellbar sein. Es soll nicht notwendig sein, mich in Sachen wieder eindenken zu müssen, die ich vor Jahren mal umgesetzt habe. An dieser Stelle meine ich jetzt nicht die CCU-Logik, sondern die Einbindung von irgendwelchen Fremdsystemen. Ist wie bei den jugendlichen Autobastlern. Wenn man mal auf das Fahrzeug angewiesen ist, um seine Brötchen zu verdienen (Arbeitsweg) oder als Familienkutsche, dann verlieren sich die Prioritäten auf dicke Felgen und Spoiler und Chiptuning ganz schnell. Ich möchte mich z.B. einfach in mein Auto reinsetzen können und losfahren, was von vornherein irgendwelche getunten und verbastelten alten Kisten ausschließt. Und bei modernen Autos geht ja nicht mehr wirklich viel.
Was aber meist an Programmierfehlern liegt, die auch bei anderer Programmierung auftreten kann, wenn man sich nicht an die "Regeln" hält (oder eben durch häufiges Editieren verursacht ist). Für mich immer noch kein Grund, den Komplexitätsgrad des Systems über die Notwendigkeit hinaus zu erhöhen. Dazu gehört für mich z.B. auch der aktuell gerade hippe Trend zu Virtualisierung. Kann man machen - funktioniert auch, aber für mich gehört Hausautomation inzwischen zur essenziellen Lebensführung (ist halt eine Komfortfrage), auch wenn ich überall eine Rückfallebene durch eine lokale manuelle Bedienmöglichkeit (für den Fall der Fälle) habe. Und statistisch erhöht nun mal eine Vergrößerung des Komplexitätsgrades (zum Beispiel durch eine zweite zustätzliche, nicht zwingend notwendige Logikebene oder eine Virtualisierung) die Ausfallwahrscheinlichkeit signifikant. Und die Host-OS solcher Systeme müssen häufig geupdatet werden. Ich würde weniger die Downtimes bemängeln, als dass es sich durch Updates ggf. Funktionseinschränkungen ergeben. Meine alte CCU2 hatte teils Uptimes von mehr als einem Jahr. Ich bin gewiss kein Uptime-Junkie, aber ich möchte mich um solche Systeme kümmern wollen und nicht müssen. Sprich, sie müssen ggf. auch lange ohne mein Eingreifen einfach nur ihren Dienst tun können, wenn sich die Prioritäten mal verschieben.
Weil es eben eine zusätzliche, nicht zwingend notwendige zweite Logikebene ist. Stichwort: Komplexitätsgrad
Daran liegt es nicht. Ich verfolge das KISS-Prinzip. Mit der Raspberrymatic habe ich mich zwar auch für ein Projekt einer One-Man-Show entschieden (ohne jetzt das irgendwie negativ werten zu wollen, ich setze es gern ein), aber es ist nahe genug am Original dran, dass ein Rücksprung auf das "Orignal" relativ problemlos mit wenigen Einschränkungen möglich ist, sollte der Maintainer sich mal aus dem Projekt zurückziehen. Ich habe um das Thema "Hausautomation" schon viele OMS-Projekte kommen und gehen sehen. Das hat meine Meinung bestärkt, nicht auf jede noch so "moderne" Lösung aufspringen zu müssen. Nun ist NodeRed nicht gerade ein OMS, aber Redmatic ist nach meinem Empfinden auch eher tot. Und zusätzliche externe Systeme sind für mich ein NoGo (außer für verzichtbare Dinge wie z.B. Historian, der bei mir in einem Container auf einem NAS läuft, aber für die Funktionalität nicht zwingend erforderlich ist, oder ggf. eine Visualisierung). Aber so hat jeder seine Prioritäten. Meine Meinung ist auch absolut nicht maßgebend, soll aber nur mal anregen, auch einen Gedanken an Ausfallsicherheit zu verschwenden und Mitleser zur Überlegung anzuregen, ob es wirklich sinnvoll ist, jedem ach so hippen neuen Trend hinterherzujagen, nur weil man ein paar Videos bei YT dazu gesehen hat. Und Smarthomeprogrammierung ist keine Angelegenheit, die man mal so nebenbei an ein, zwei Abenden macht (wenn man etwas höhere Automatisierungsbedürfnisse hat) und schon gar nicht Plug and Play. Und der Weg dazu ist eine längerfristige Entscheidung und kurzfristige Trends sind da eher eine Fußangel.
Gruß Xel66
).