Erkennung Ursache unavailable

Rat und Tat rings um Home Assistant Automationen.


Antworten
tag
Beiträge: 48
Registriert: Mi 2. Nov 2022, 17:50
1
Wohnort: Karlsruhe
Has thanked: 30 times
Kontaktdaten:

Erkennung Ursache unavailable

Beitrag von tag »

Einige meiner smarten Birnen/Lampen (die meisten sogar) befinden sich hinter einem Stromschalter. Macht man das Licht per Software aus, so schaltet der Schalter den Strom aus, aber das Licht ist ja bereits aus. Schaltet man das Licht wieder an, so hängt es vom Verhalten der Birne ab: Ist sie komplett weiß an? Merkt sie sich den letzten Zustand und stellt den wieder her? Manche stellen auch den letzten eingeschalteten Zustand wieder her.

Ich möchte, dass man das Licht mit dem Schalter einschalten kann. Daher habe ich bei den Zigbee-Lampen, die sich den Zustand "ausgeschaltet" merken, eine Automatisierung "Wenn an dann an" erstellt, die aktiv wird, wenn der Zustand von Unavailable auf irgendetwas andere wechselt. Bedingung ist, dass die Lampe aus ist - wenn ja wird sie eingeschaltet.

Das ganze funktioniert prima und genau wie ich es will. Ausnahme: Neustart des Home Assistant. Diie ZHA wird neu geladen, der Zustand wechselt von Unavailable - und schon wird das Licht eingeschaltet.

Wie kann ich abfragen, ob die Integration neu geladen wurde? Ich würde einen Helfer erstellen, der beim Neustart zurückgesetzt wird. Sobald das Gerät mal Available war, wird er gesetzt, und ab da gilt die "Wenn an - dann an"-Logik.

Wie setze ich einen Helfer bei Neustart zurück, gibt es einen passenden Trigger?

Oder gibt es für mein Problem eine elegantere Lösung? Kann man bei Zigbee-Geräten das Startverhalten einstellen? Wenn ja, wo geht das?

Benutzeravatar
Osorkon
Administrator
Beiträge: 1953
Registriert: Sa 17. Jul 2021, 16:53
2
Wohnort: Langenargen
Has thanked: 61 times
Been thanked: 530 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von Osorkon »

SmartHome Regel Nr.1

  • ZigBee Lampen werden nicht stromlos geschaltet!! ;)

Lass mal bitte Deine Automatisierung sehen, ggf. lässt sich da was im Ablauf was optimieren.

Ansonsten, wenn Du eh alle Lampen mit einem Schalter stromlos schalten und wieder einschalten tust.
Dann ändere doch das Verhalten nach Stromausfall auf "Einschalten"
Nutze leider ZHA nicht, sondern ZigBee2MQTT. Aber irgendwo in den Geräte Einstellungen wird das zu finden sein.
Allerdings besitzen nicht alle Leuchtmittel diese Einstellmöglichkeit.

Zum Thema Helfer, wäre der Uptime Sensor wohl das richtige.
Nach dem Motto: Ausführen nur, wenn uptime größer X.

Gruß
Osorkon

Einer muss ja für Ordnung sorgen. :D
tag
Beiträge: 48
Registriert: Mi 2. Nov 2022, 17:50
1
Wohnort: Karlsruhe
Has thanked: 30 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von tag »

  • Nicht stromlos

Mein Gedanke war, dass man alles wie bisher steuern können soll und smarte Funktionen nur zusätzlich sind. Aber ich habe auch gemerkt, dass das nicht immer so toll ist.

Gerne würde ich umstellen, die ZigBee Lampen nicht stromlos zu schalten. Wie mache ich das so, dass die bisherigen Schalter weiter verwendet werden können? Es ist ja ein Altbau.

Bei einer ZigBee Lampe für den Alibert von Ikea brummt der Trafo, wenn sie Strom hat. Je dunkler, desto lauter. Ist sie aus, ist es am lautesten. Der ist hinter einem Shelly, der ihr den Strom klaut und den ich nur brauche, weil die Lampe so laut brummt ... Aber gut, wenn es nur die Aliberts in den Bädern wären, könnte das ja als Ausnahme so bleiben.

  • ZigBee

Das Problem mit ZigBee ist, dass der USB-Stick ConBee II an dem Synology NAS nicht mehr mit der Home Assistant VM verbunden ist, wenn ich den Home Assistant neu starte.

Hier bin ich an einer Lösung, aber leider funktioniert virsh attach-device zum Verbinden des Sticks am Host mit der Home Assistant VM nicht. Es meldet Vollzug, aber es funktioniert nicht ...

Also sind alle Geräte in ZigBee nicht verfügbar, wenn der Home Assistant neu startet, bis ich manuell auf der Synology DSM -Oberfläche eingreife.

Den Uptime Sensor habe ich auch schon entdeckt und eingebaut in die Automation als Abfrage, aber wie lange ich benötige um ZigBee zu reparieren kann halt unterschiedlich sein.

Deshalb habe ich es deaktiviert, der Teil mit Uptime ist seit gestern drin, aber noch nicht getestet. Siehe Screenshot. Sonst ist es unverändert.

Die Einstellung für Geräte Startup-Verhalten suche ich noch Mal. Ich wollte eh bei Gelegenheit auf ZigBee2MQTT umstellen, scheue aber noch den Aufwand. Aber dann könnte der Host oder ein anderes Gerät sich um den Stick kümmern und es per MQTT liefern, dann würde sich das Problem mit dem Stick an USB geben.

Danke für die wie immer wertvollen Anregungen!

Dateianhänge
Screenshot_2024-01-28-12-25-08-440_io.homeassistant.companion.android.jpg
Screenshot_2024-01-28-12-25-08-440_io.homeassistant.companion.android.jpg (312.11 KiB) 591 mal betrachtet
Benutzeravatar
Osorkon
Administrator
Beiträge: 1953
Registriert: Sa 17. Jul 2021, 16:53
2
Wohnort: Langenargen
Has thanked: 61 times
Been thanked: 530 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von Osorkon »

tag hat geschrieben: So 28. Jan 2024, 12:38

Gerne würde ich umstellen, die ZigBee Lampen nicht stromlos zu schalten. Wie mache ich das so, dass die bisherigen Schalter weiter verwendet werden können? Es ist ja ein Altbau.

Idealerweise verbaust Du für Deine Hauptbeleuchtung keine smarten Leuchtmittel, sondern ausschließlich dumme Leuchtmittel, dimmbar oder nicht, je nach dem was Du benötigst. Diese dumme Leuchtmittel werden dann über Smarte Up-Module, hinter dem eigentlichen Lichtschalter verbaut, versmartet.

Ich setze ZigBee Leuchtmittel ausschließlich für Ambiente Beleuchtung ein, die nie stromlos geschaltet werden. Diese werden dann über zusätzliche Mobile Funkschalter gesteuert. Ein; Aus, Szenenauswahl, etc.

Alle ZigBee Leuchtmittel einzeln oder als Gruppe sind zusätzlich mit einem ZigBee Schalter gepaart, bei ZigBee2MQTT nennt sich das Binding. Auf diese Weise kann ich die Lichter immer Schalten, egal oben Home Assistant läuft oder nicht, oder gar der ZigBee Koordinator ausfällt.

tag hat geschrieben: So 28. Jan 2024, 12:38

Das Problem mit ZigBee ist, dass der USB-Stick ConBee II an dem Synology NAS nicht mehr mit der Home Assistant VM verbunden ist, wenn ich den Home Assistant neu starte.

Das Problem lässt sich ja schnell beheben, wenn Du Home Assistant OS nicht auf der Synology laufen lässt.
Hatte ich auch mal zeitlang als Test-System laufen. Aber schnell erkannt dass es ein Murks ist, vor allem wegen der USB Geschichte.

Es gibt ja so viele Hardware Möglichkeiten, die viel besser für Home Assistant geeignet sind. Egal ob ein Raspberry Pi, Odroid, mini PC, NUC, ZimbaBoard, ZimaBlade, etc.

Bezüglich Deiner Automatisierung. Screenshots aus der GUI sind zwar schön anzusehen, leider für eine Analyse/ Fehlersuche völlig ungeeignet.
Der YAML code, wäre hier von Interesse.

Gruß
Osorkon

Einer muss ja für Ordnung sorgen. :D
tag
Beiträge: 48
Registriert: Mi 2. Nov 2022, 17:50
1
Wohnort: Karlsruhe
Has thanked: 30 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von tag »

Nach Möglichkeit habe ich überall ZigBee, meist Livarno E27, weil ich es toll finde, überall RGB zur Verfügung zu haben. Das würde nicht gehen. Und günstig sind die bunten Birnen mit 10 Euro auch.

Ein in der Firma ausgemustertes Notebook mit SSD sollte eigentlich gut passen für den Home Assistant. Da würde ich Ubuntu installieren und die VM mit Home Assistant laufen lassen, eventuell kann ich das sogar von Synology exportieren und direkt importieren. Der Rechner kann dann auch andere Aufgaben übernehmen.

Abgesehen vom USB Zeug war ich mit der Synology VM auf der DS218+ mit 10 GB RAM bisher eigentlich hochzufrieden. Sogar mit einem parallel installieren Ubuntu, das gelegentlich auch noch was tut. Nur dass die Platten permanent arbeiten und quasi nie ruhig sind finde ich doof. Reaktionszeiten waren aber nie ein Problem.

Hier das yaml:

Code: Alles auswählen

alias: Wenn an dann an Levon Deckenlampe
description: ""
trigger:
  - entity_id:
      - light.licht_levon_licht
    platform: state
    from: unavailable
condition:
  - condition: state
    entity_id: light.licht_levon_licht
    state: "off"
  - condition: numeric_state
    entity_id: sensor.uptime
    above: 120
action:
  - type: turn_on
    device_id: 20735576a58a889aad4be618e52e4fb9
    entity_id: 3673b5f3dbc567b67e8172a130def56d
    domain: light
mode: single
Jim_OS

Re: Erkennung Ursache unavailable

Beitrag von Jim_OS »

tag hat geschrieben: So 28. Jan 2024, 12:38

Das Problem mit ZigBee ist, dass der USB-Stick ConBee II an dem Synology NAS nicht mehr mit der Home Assistant VM verbunden ist, wenn ich den Home Assistant neu starte.

Moin

Ich hatte Dir dazu ja schon etwas in einem anderen Forum geschrieben, ;) aber bevor es hier ggf. zu falschen Einschätzungen bzgl. eines Betriebes von HA als VM mit einem Synology NAS kommt: :) Das Problem ist weniger das Synology NAS, sondern irgendwelche von Zeit zu Zeit auftauchende "Eigenheiten" des Conbee II. Andere (Zigbee) USB-Dongle - wie ja z.B. auch Dein Z-Wave-Stick - haben/machen diese Probleme mit einer HA VM auf einem Synology NAS nicht. Wenn aktuell keine der div. im I-Net herumschwirrenden Lösungsansätze für den Conbee II bei Dir funktionieren dann könnte man ggf. auf einen anderen USB-Dongle (z.B. Sonoff Dongle-P) wechseln, oder man muss halt - wie Osorkon bereits vorgeschlagen hat - eine andere Basis für den HA Host nutzen. Ein Conbee II der nach einem Neustart der HA VM nicht eingebunden ist ist natürlich ein NoGo und geht gar nicht.

Hier läuft u.a. eine HA VM auf einer DS720+ in Verbindung mit einem Sonoff Dongle-P jetzt seit ca. 6 Monaten 24/7, ohne das es irgendwelche Probleme mit dem Dongle gibt wenn HA und/oder die HA VM neu gestartet/gebootet wird.

VG Jim

tag
Beiträge: 48
Registriert: Mi 2. Nov 2022, 17:50
1
Wohnort: Karlsruhe
Has thanked: 30 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von tag »

Also ich kann das Startup Verhalten wohl setzen für die Birne, müsste nur wissen was da für ein Wert rein muss. Siehe Screenshot.

Dateianhänge
Screenshot_2024-01-28-14-03-33-599_io.homeassistant.companion.android.jpg
Screenshot_2024-01-28-14-03-33-599_io.homeassistant.companion.android.jpg (227.74 KiB) 569 mal betrachtet
Benutzeravatar
Osorkon
Administrator
Beiträge: 1953
Registriert: Sa 17. Jul 2021, 16:53
2
Wohnort: Langenargen
Has thanked: 61 times
Been thanked: 530 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von Osorkon »

tag hat geschrieben: So 28. Jan 2024, 14:06

Also ich kann das Startup Verhalten wohl setzen für die Birne, müsste nur wissen was da für ein Wert rein muss. Siehe Screenshot.

Würde mal schwer vermuten on, wenn die Birnen nach Stromausfall eingeschaltet werden soll.

tag hat geschrieben: So 28. Jan 2024, 13:42

Ein in der Firma ausgemustertes Notebook mit SSD sollte eigentlich gut passen für den Home Assistant.

Dachte Du wolltest Dich verbessern und einen Rückschritt machen!? ;)

Ein Notebook wäre das letzte was ich für Home Assistant nutzen würde. Außer vielleicht zu Test Zwecken oder zum spielen.

Gruß
Osorkon

Einer muss ja für Ordnung sorgen. :D
tag
Beiträge: 48
Registriert: Mi 2. Nov 2022, 17:50
1
Wohnort: Karlsruhe
Has thanked: 30 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von tag »

In dieser Diskussion wurden für StartUpOnOff als Werte 0 aus, 1 an und 2 gemerkter Zustand angegeben. Angeblich funktioniert das Schreiben des Werts, egal ob ich On, on oder 1 angebe. Allerdings steht da nach "Attribut lesen" wieder "None".

Was ist an einem Notebook für den Zweck denn schlecht? Es würde natürlich einen festen Platz neben dem NAS haben und dort 24/7 laufen. Display aus, nur per Remote Zugriff benutzt. Der Akku wird immer voll sein und mittelfristig eventuell etwas leiden, aber das wäre unwichtig (notfalls rausnehmen, kenne dass das gehen kann). Halbwegs stromsparend sollten Notebooks ja sein. Ich lasse mich gerne davon überzeugen dass es ein Rückschritt wäre, wenn ich die Gründe kenne.

Benutzeravatar
Osorkon
Administrator
Beiträge: 1953
Registriert: Sa 17. Jul 2021, 16:53
2
Wohnort: Langenargen
Has thanked: 61 times
Been thanked: 530 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von Osorkon »

Osorkon hat geschrieben: So 28. Jan 2024, 14:17

Ich lasse mich gerne davon überzeugen dass es ein Rückschritt wäre, wenn ich die Gründe kenne.

Alleine schon die Größe und dann noch der Stromverbrauch.

Meine Home Assistant Hosts, die hier so einsetze, brauchen so um die 4,5 bis 7 Watt.

  • ZimaBoard: 4,5 W - Proxmox Home Assistant OS VM
  • Odroid M1: 4,8 W - Home Assistant OS
  • Raspberry Pi4: 7 W - Home Assistant OS.

Beim Pi ist es wohl der Lüfter der noch das einn oder andere Watt benötigt, die anderen zwei sind passiv gekühlt.

Herkömmliche Notebooks sind nicht für den 24/7 Betrieb ausgelegt.
Das fängt schon bei der Festplatte an und hört bei dem Lüfter auf.

Gruß
Osorkon

Einer muss ja für Ordnung sorgen. :D
Dampf
Beiträge: 286
Registriert: So 22. Jan 2023, 10:06
1
Has thanked: 97 times
Been thanked: 50 times

Re: Erkennung Ursache unavailable

Beitrag von Dampf »

Für Zigbee Lampen und Leuchten gibt’s ne super Lösung hinter den Lichtschalter - vorausgesetzt es ist genug Platz in der Unterputzdose.

NEXENTRO Tasterschnittstelle (kann auch für Schalter konfiguriert werden).

Die klingt auch so gut wie Zigbee Netzwerk ein, wird aber über die eigebe Bluetooth App konfiguriert. Sie stellt eine direkte Verbindung zu Lampe oder Leuchte her. Dadurch ist das Ganze ausfallsicher und trotzdem weiter über den Zigbee Gateway steuerbar.

Gibt also keinen Grund mehr auch für die Hauptbeleuchtung auf smarte Leuchtmittel und Leuchten zu verzichten ;)

HA OS auf Beelink SEi12 Mini PC, i5-1235U,16GB RAM, Zigbee2mqtt mit SONOFF Zigbee 3.0 USB Dongle Plus

tag
Beiträge: 48
Registriert: Mi 2. Nov 2022, 17:50
1
Wohnort: Karlsruhe
Has thanked: 30 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von tag »

Dampf hat geschrieben: So 28. Jan 2024, 20:36

, wird aber über die eigebe Bluetooth App konfiguriert.

Tut mir leid, aber damit ist es raus. Ich benutze auch bei Shellys nicht die Shelly App, sondern die Weboberfläche. Die Nutzung einer App, bei der ich keine Ahnung habe was sie wohin übermittelt, die eventuell nur mit einer Registrierung nutzbar ist oder bei der das nachträglich möglicherweise noch eingeführt wird (siehe Avox Smart App/Eglo - war lange frei nutzbar ohne Registrierung, dann gesperrt, oder TP-Link genauso, oder Philips Hue) ist keine Option für mich. Das widerspricht meiner Cloudidee.

Dampf
Beiträge: 286
Registriert: So 22. Jan 2023, 10:06
1
Has thanked: 97 times
Been thanked: 50 times

Re: Erkennung Ursache unavailable

Beitrag von Dampf »

Grundsätzlich gebe ich dir recht.
Die Nexentro App ist eine App zur Konfiguration. Das ist kein Vergleich mit Hue und Co.. Die Bluetooth Verbindung wird nur beim Konfigurieren hergestellt, danach kann man sie löschen.

Wenn Du Zigbee2mqtt nutzt kannst es auch anders lösen.
Es gibt eine Tasterschnittstelle von Ubisys. In Z2M kannst du Taster oder Schalter, die daran angeschlossen sind, direkt mit den Leuchten/Leuchtmitteln koppeln. Da brauchst du aber einen Nullleiter am Schalter.

Oder du könntest batteriebetriebene Zigbee 3.0 Schalter nutzen, die du direkt mit den Leuchten(-mitteln) koppelst. Den alten Schalter raus, die Birne auf Dauerstrom klemmen und den Zigbee Schalter auf die Unterputzdose geschraubt.

HA OS auf Beelink SEi12 Mini PC, i5-1235U,16GB RAM, Zigbee2mqtt mit SONOFF Zigbee 3.0 USB Dongle Plus

Benutzeravatar
Osorkon
Administrator
Beiträge: 1953
Registriert: Sa 17. Jul 2021, 16:53
2
Wohnort: Langenargen
Has thanked: 61 times
Been thanked: 530 times
Kontaktdaten:

Re: Erkennung Ursache unavailable

Beitrag von Osorkon »

Dampf hat geschrieben: So 28. Jan 2024, 20:36

Für Zigbee Lampen und Leuchten gibt’s ne super Lösung hinter den Lichtschalter - vorausgesetzt es ist genug Platz in der Unterputzdose.

NEXENTRO Tasterschnittstelle (kann auch für Schalter konfiguriert werden).

Es gibt ja mehr als genug ZigBee UP-Module. Der alte Schalter bleibt, das Licht wird kurzgeschlossen und vom Schalter entkoppelt.
Nachteil, man muss mit Automatisierungen arbeiten um dann bei betätigen des Schalters die ZigBee Leuchten zu schalten. Setzt natürlich voraus, dass man in der Dose Platz hat um ein UP-Modul zusätzlich zum Schalter einbauen zu können.

Oder mann setzt auf Funkschalter, wie die Friends of Hue Schalter. Der alte Schalter wird ersetzt, oder der Friend of Hue Schalter wird zusätzlich angebracht.
Man Schaltet dann nur noch über den Funkschalter. Vorteil von den Friends of Hue Schalter, diesen arbeiten ohne Batterie.

Es gibt aber noch weitere Funkschalter, die sich in die gängigen Schalter Rahmen integrieren lassen. Allerdings dann mit Batterie.

Ein Zwitter ist das Philips Hue Wand Schalter Modul, welches exakt für das hier beschrieben Problem entwickelt wurde. Es macht den Konventionellen Schalter Smart und die ZigBee Lampen bleiben am Dauerstrom.

Gruß
Osorkon

Einer muss ja für Ordnung sorgen. :D
Antworten