Beiträge von Der_Dscho

    Ich habe noch nirgends gesehen dass man Shelly-SCRIPTE in HA direkt editieren könnte. Da ich auch bisweilen noch keine virtuellen Komponenten verwende hab ich auch die von dir erwähnten Button200 & Button201 noch nirgends gesehen.

    Das sieht bei mir so aus (s. Anhang).

    In der Shelly App ist das ein richtiger Button, welcher ein Script starten kann, das auf einem Shelly Plus S Gen3 läuft. Auf dem Plug S ist der wie im Anhang dargestellt angelegt

    Ich habe mir gedacht, das funktioniert bestimmt nicht und habe auf "Abwesenheit alles Aus" in HA draufgeklickt. Hat aber funktioniert und als ich dann abends in den Trockner geschaut habe, war der gem. Script abgeschaltet und die Wäsche noch nass :-D

    Guten Morgen zusammen,

    nach einigen Tagen mit Home Assistant, der bei mir in Docker-Containern auf einem QNAP-NAS läuft, habe ich inzwischen diverse Geräte unterschiedlicher Hersteller eingebunden. Meines Erachtens wird nun alles korrekt in HA angezeigt.

    Positiv überrascht war ich, dass auch Button200 und Button201 sauber in HA integriert wurden und ich die auf den Shellys hinterlegten Skripte direkt aus HA ausführen kann – ohne ein Pro-Abo für virtuelle Buttons abschließen zu müssen.

    Parallel habe ich mich intensiv mit dem Thema Backup beschäftigt und dabei folgende Erfahrungen gemacht:

    Backup – aktueller Stand

    • Interne HA-Backuplösung
      Funktioniert bei mir nicht, da ich die benötigten Rechte für HA auf dem QNAP nicht sauber setzen konnte.
    • QNAP Snapshot
      Der Snapshot selbst funktioniert, die Wiederherstellung jedoch nicht zuverlässig (trotz gestoppter Container). Es gibt immer wieder Dateien, die nicht zurückgesichert werden können. Zudem erscheint mir das insgesamt recht „fummelig“. Da Snapshots ohnehin kein echtes Backup ersetzen, habe ich das Thema für mich erst einmal verworfen.
    • HBS3-Backup (aktuell im Einsatz)
      • 1× monatlich: kompletter Container
      • täglich: der Config-Ordner von Home Assistant (für jeweils die letzten 3 Tage)
        Ziel ist: Wenn ich mir etwas „zerschieße“, möchte ich kurzfristig wieder auf einen funktionierenden Stand zurück können.

    Meine Fragen

    1. Reicht das Backup des Config-Ordners wirklich aus?

    Ich habe testweise eine HBS-Rücksicherung gemacht. Dabei ist mir aufgefallen (evtl. auch wegen einer fehlerhaften Rücksicherung):

    • Benachrichtigungen, die ich vor dem Backup gelöscht hatte, tauchten nach der Rücksicherung nicht wieder auf.
    • Ein Gerät, das ich kurz vor dem Backup auf „deaktiviert“ gesetzt hatte, war nach der Rücksicherung nicht wieder aktiviert – ich hätte aber erwartet, dass genau dieser Zustand zurückkommt.

    Daher konkret:

    • Reicht es für meinen Zweck wirklich, nur den Config-Ordner zu sichern?
    • Sind dort zu 100 % alle relevanten Daten enthalten (Automationen, Integrationen, Gerätestatus, etc.)?
    • Oder brauche ich zusätzlich zwingend regelmäßige Container-Backups – und wenn ja, warum?

    2. Szenarien aus der Shelly App

    Was nicht übernommen wurde, sind die in der Shelly App angelegten Szenarien.
    Ich gehe davon aus, dass ich diese in HA selbst nachbauen kann (z. B. „Gefrierschrank > -16 °C → Push-Alarm aufs Handy“).
    Seht Ihr hier irgendwelche Nachteile oder Fallstricke, die ich übersehe?


    3. Zeitpläne (Schedules) für Heizung / Schaltzeiten

    Ebenfalls nicht übernommen wurden die Zeitpläne (z. B. Heizung an/aus). Diese sind bei mir essenziell, da sie über Button200/201 bei Abwesenheit bzw. Anwesenheit aktiviert/deaktiviert werden.

    Wichtig für mich:
    Ich kann die Zeitpläne nur dann sinnvoll in HA abbilden, wenn sie auch direkt auf den Geräten (Shelly Plus S Gen3, Shelly Plus 1PM etc.) entsprechend geändert werden. Es darf auf keinen Fall passieren, dass:

    • in der Shelly App ein Zeitplan aktiv ist,
    • in HA derselbe Zeitplan aber deaktiviert wäre (oder umgekehrt).

    Wie geht Ihr mit diesem Thema um? Nutzt Ihr die Zeitpläne ausschließlich in HA und lasst die Shelly-internen Schedules komplett leer?


    Vielen Dank vorab für Eure Einschätzungen und Erfahrungen!

    Mit der KI ist es wie mit den E-Bikes. Viele fahren jetzt E-Bike, die früher nie ein Fahrrad angefasst haben. Seit es eine brauchbare KI gibt, traue ich mich nun an so etwas Interessantes wie Homeautomation.

    Glücklicherweise gibt es Euch. Denn die KI schreibt auch nur irgendwo ab, reimt sich Sachen zusammen. Ob das am Ende dann stimmt ist fraglich. Bei einer Programmierung macht das nichts - dann gebe ich den Fehler aus und die KI wurschtelt weiter. Aber bei einer Kaufberatung braucht es schon echte Anwender wie Euch.

    Daher

    HERZLICHEN DANK an alle, die sich hier gemeldet haben!

    Die KI sagt:

    Für Home Assistant auf einem HP T620 Thin Client sind folgende RAM-Größen praxisgerecht und bewährt:

    Mindestanforderung

    • 4 GB RAM
      Funktioniert für:
      • Home Assistant OS oder HA Supervised
      • wenige Integrationen
      • geringe Automatisierungs-Komplexität
        → Läuft stabil, aber kaum Reserven. Bei Datenbank-Wachstum oder Add-ons schnell am Limit.

    Empfohlene Ausstattung (Best Practice)

    • 8 GB RAM
      Sinnvoll für:
      • Home Assistant OS inkl. Add-ons (Node-RED, MQTT, Zigbee2MQTT, InfluxDB light, etc.)
      • mehrere Integrationen (Shelly, EnOcean, DoorBird, etc.)
      • langfristigen 24/7-Betrieb
        → Sehr guter Sweet Spot aus Kosten, Stabilität und Zukunftssicherheit.

    Komfort / Reserve

    • 16 GB RAM
      Nur nötig, wenn:
      • Virtualisierung (z. B. Proxmox + HA als VM)
      • zusätzliche Container/Services parallel
      • große Datenbanken, umfangreiche Historie, Statistik-Add-ons
        → Für reinen Home-Assistant-Betrieb meist überdimensioniert.

    Konkrete Empfehlung für deinen Anwendungsfall

    Da du:

    • Home Assistant ernsthaft und dauerhaft betreiben willst,
    • Node-RED in Betracht ziehst,
    • perspektivisch DoorBird / Video / mehr Integrationen nicht ausschließt,
    • gleichzeitig Wert auf Energieeffizienz legst,

    ist 8 GB RAM klar zu empfehlen.

    Bei dem Programmieren der Scripte auf den Shelly Geräten stellte die KI fest (sorry ich muss das alles die KI machen lassen, weil ich zu dumm bin und die Schaltungen Anwesenheit und Abwesenheit auch sehr komplex):

    Architektur & Ablauf

    • Alle Geräteaktionen müssen über eine serielle Queue laufen
    • Es dürfen niemals parallele RPC-Aufrufe stattfinden
    • Zwischen Queue-Einträgen muss ein konfigurierbarer Delay liegen

    Dir ist klar, dass der Green nur sehr langsame und nicht erweiterbare 32GB hat?

    Ja, danke nochmal für den Hinweis. Langsam wäre jetzt kein Problem. Ich musste in den Shelly Scripten immer Delays einfügen, weil die Shelly Aktoren mit der Schnelligkeit meiner Wünsche überfordert waren. Nicht erweiterbar bedeutet aber Folgekosten, wenn das System an seine Grenzen stößt. Ggf. setze ich dann 100 EUR in den Sand.

    Also ihr Lieben, erst einmal vielen Dank für eure Ideen und Tipps.

    Aktuell läuft bei mir noch alles über die Shelly Cloud. Die ca. 300 EUR für eine EnOcean-Integration hatte ich bereits befürchtet. Ich habe das Thema mehrfach überlegt und dann wieder verworfen. Ein grundlegendes Problem ist aus meiner Sicht, dass viele EnOcean-Komponenten unidirektional arbeiten. Weder Home Assistant noch ein anderes System weiß dann sicher, ob ein Licht tatsächlich an oder aus ist, sondern lediglich, dass ein entsprechendes Signal gesendet wurde.

    Hinzu kommt, dass meine EnOcean-Schalter nicht immer zuverlässig sind: Teilweise muss man mehrfach drücken, teilweise löst sogar ein Gewitter einen Impuls aus und Lichter gehen ungewollt an. Die Aktoren sitzen alle UP, teils hinter Alu-Schaltern – insgesamt also keine optimalen Bedingungen für Funk, insbeondere wenn HA und ioBroker das Signal empfangen aber der Aktor nicht.

    Aus euren Rückmeldungen haben sich für mich drei Ansätze ergeben, die ich weiterverfolgen werde:

    1. NAS weiter nutzen:
      Wenn ich mein NAS insgesamt energiesparender konfigurieren kann, wäre es eine Option, dort ioBroker oder Home Assistant laufen zu lassen. Ein Vorteil wäre, dass ich später – falls eine DoorBird installiert wird – auch Videostreams aufzeichnen könnte.
    2. Home Assistant Green + Node-RED:
      Alternativ könnte ich mir einen Home Assistant Green zulegen und Node-RED einsetzen. Das scheint für Einsteiger etwas zugänglicher zu sein. Beim Green müsste man sich zudem um vergleichsweise wenig kümmern, da das System wohl weitgehend „out of the box“ läuft.
    3. HA oder ioBroker mit EnOcean-Integration:
      Sowohl Home Assistant als auch ioBroker bieten grundsätzlich die Möglichkeit, EnOcean und die anderen Geräte einzubinden. EnOcean ist dabei allerdings teuer und – wie oben beschrieben – aus meiner Sicht auch nicht besonders zuverlässig. Welches System ich letztlich einsetze, ist noch offen. Home Assistant wirkt zwar etwas fummeliger, hat aber eine deutlich größere Verbreitung. Außerdem soll sich die Oberfläche im letzten Jahr spürbar verbessert haben. Die englische Dokumentation von HA wäre für mich kein Hinderungsgrund.

      Die KI gibt mir hier die folgenden Vor- und Nachteile:

    Home Assistant und ioBroker sind beide beliebte Open-Source-Systeme für Smart-Home-Automatisierung, mit Home Assistant als modernerem Einstieg und ioBroker als flexiblerer Lösung für Fortgeschrittene.

    Vorteile Home Assistant

    Home Assistant bietet eine einfache Installation über ein dediziertes Operating System und moderne, mobil-optimierte Visualisierungen mit App-Unterstützung. Es integriert Features wie GeoFencing und Energiemanagement standardmäßig und profitiert von einer großen internationalen Community mit schneller Weiterentwicklung.

    Nachteile Home Assistant

    Updates erfordern oft Neustarts, besonders bei YAML-Konfigurationen, und es gibt eine steile Lernkurve für komplexe Anpassungen. Die Dokumentation ist primär englischsprachig, und einige Integrationen sind cloud-abhängig.

    Vorteile ioBroker

    ioBroker ist hochgradig modular mit unabhängigen Adapter-Updates ohne vollständige System-Neustarts und bietet grafische Konfigurationsoberflächen sowie Blockly für Logik ohne YAML. Die deutschsprachige Community ist stark, und Adapter erlauben tiefe Anpassungen sowie Skalierbarkeit.

    Nachteile ioBroker

    Die Installation ist komplizierter, Visualisierungen zeitaufwendig und weniger mobil-freundlich, mit komplexen Updates via NodeJS. Dokumentation kann veraltet sein, und die internationale Präsenz ist geringer.

    AspektHome AssistantioBroker
    EinfachheitSchnell einzurichten, App modern Flexibel, aber technischer
    FlexibilitätGrenzen bei DetailsHöher, modular
    CommunityInternational groß Deutsch stark
    Mobile NutzungExzellent Begrenzt

    Stimmt das aus Eurer Sicht so im Großen und Ganzen?

    Ich habe eine VM auf dem NAS.
    In der VM läuft Home Assistant mit dem Node Red AddOn (statt ioBrocker).

    Ja ich denke HA muss ich auch mit Node Red AddOn nutze, da ich nicht so viel vom Programmieren und Einstellen in Config-Dateien verstehe. Ich dachte der HA Green ist da sehr anfängerfreundlich, verbrauche wenig Energie und kann easy 24/7 laufen. Mein NAS möchte ich aus den vorher genannten Gründen lieber nicht nehmen.

    Hä?

    Das ist doch ein "Server", der 24/7 laufen muss!

    Und mein "Server" ist besagter HP T620, der mit seinen 7,5 W ganze 19 € im Jahr an Strom kostet.

    Davon abgesehen sind deine Anforderungen mit beiden Systemen zu lösen, sofern die betreffenden Geräte im Netz sind.

    Ich hatte geplant, den Home Assistant Green als Server zu verwenden und meinen relativ hochgerüsteten QNAP TS-677 über Nacht auszuschalten. Der QNAP-Server hatte früher die Aufgabe, umfangreiche Renderjobs über Nacht auszuführen und verbraucht inzwischen für reine Sicherungsaufgaben unverhältnismäßig viel Energie – obwohl ich Multimedia Station und ähnliche Dienste bereits deaktiviert habe.

    Aus diesem Grund habe ich alle Backup-Jobs so konfiguriert, dass das NAS nur noch etwa einen halben Tag laufen muss. Aktuell würde ich es daher nur ungern zusätzlich für die Hausautomation einsetzen.

    Die Scripte können ja erstmal wie gehabt offline weiterlaufen. Wenn dann die gewünschte Stabilität der HA-Installation erreicht ist kann man bei Bedarf dies erweitern/ersetzen durch eine Kombination aus HA-Sensoren (WLAN-Connection der Handy's, BT-Detection, usw....)

    Vielen Dank, borstiO, für die ausführlichen Informationen.

    Ich bin schon etwas älter und suche daher vor allem eine Lösung, die zukunftssicher ist und möglichst wenig laufenden Aufwand verursacht. In Bezug auf Automationen benötige ich keinen großen Funktionsumfang – im Wesentlichen reichen mir folgende Szenarien:

    • Benachrichtigung, wenn die Temperatur im Gefrierschrank oder Kühlschrank zu hoch oder zu niedrig ist
    • Überwachung des Stromverbrauchs aller Shelly Plug S und automatisches Abschalten von Geräten mit stromintensivem Standby
    • Absenkung der AVM-Heizkörperthermostate, wenn ein Fenster geöffnet wird
    • Abwesenheitsschaltung, wenn ich länger als einen Tag außer Haus bin, sowie eine entsprechende Rückkehrschaltung (per Shelly Script nach tagelanger Arbeit nun realisiert)
    • Schalten der alten Heizungsanlage inkl. Warmwasser zu definierten Zeiten über Shelly (wie bisher)
    • Alarm, wenn ein Wassersensor Wasser detektiert (perspektivisch auch automatisches Absperren der Wasserzufuhr)
    • Push-Benachrichtigung aufs Handy, wenn Abwesenheit aktiv ist und die (bestellten) Shelly-Bewegungsmelder eine Bewegung erkennen oder Türen/Fenster geöffnet werden

    All das konnte ich bislang mit der Shelly Cloud umsetzen – mit einer Einschränkung:
    Ein virtueller Button zur komfortablen Umschaltung zwischen Abwesenheits- und Anwesenheitsmodus lässt sich in der gewünschten Form nur mit Shelly Premium realisieren.

    An dieser Stelle kam Home Assistant ins Spiel. Der große Vorteil für mich wäre, zusätzlich Velux, Samsung, Onecta/Daikin, Solakon Balkonkraftwerk und AVM integrieren zu können. Ich habe dabei gar nicht den Anspruch, alles logisch miteinander zu verknüpfen – eine zentrale App zur Bedienung aller Systeme wäre für mich bereits ein großer Gewinn.

    Ein Sonderfall sind die alten EnOcean-Aktoren (z. B. FSR61NP-230V, gekauft ca. 2013–2015). Diese lassen sich aktuell über keine App steuern. Gerade wegen der größeren Anzahl wäre es für mich sehr interessant, wenn sich diese Komponenten ebenfalls in ein zentrales System integrieren ließen.

    Das Gesamtsystem soll möglichst einfach bleiben. Wenn zukünftig noch eine Türsprechanlage hinzukommt, sollte auch diese eingebunden werden können. Es ist schlicht unkomfortabel, für jedes System eine eigene App zu benötigen – und für EnOcean derzeit gar keine zu haben.

    ioBroker war mir bisher kein Begriff. Home Assistant Green finde ich insbesondere deshalb interessant, weil dafür kein zusätzlicher PC oder Server notwendig ist. Der vorhandene Server ist für diesen Zweck deutlich überdimensioniert und verursacht einen Energieverbrauch von rund 400 EUR pro Jahr. Ich möchte ihn daher künftig nur noch tagsüber betreiben – für ein Smart-Home-System ist das allerdings ungeeignet.


    IOBroker ist für Anfänger, gerade was das simple Programmieren mit Blockly angeht, MEINER MEINUNG NACH besser geeignet. Ich bin mit dem "yaml-Gedöns" nie warm geworden ...

    Ich schaue mir mal IOBroker an und Vergleiche auf YT. Danke!

    Wie meinst du das?

    Irgendein System muss aber 24/7 laufen.

    Mein NAS ist etwas überdimensioniert. Verbrauch bin ich noch am Messen aber liegt eher bei dem 10fachen. Den habe ich daher abends und nachts abgeschaltet. Daher kam ich auf HA green. Bisher nutze ich nur die Shelly Cloud.