Das Ikon fehlt bei mir auch, ich dachte aber, das soll so sein. Gibt ja kein Ikon-Zwang. 
Danke.
Ich hab es tatsächlich bisher nicht geschafft, dass das mit dem Icon überhaupt klappt ^^
Irgendwo muss ich das „aufnehmen lassen“ oder so… aber ich hatte dem nicht so hohe Prio zugestanden 
kommt nächste Woche spätestens dran 
Edit:
Das mit dem Logo sollte nun auf den Weg geschickt sein. Ich hab die Integration zur offiziellen Aufnahme im HACS-Store vorgelegt. Damit sollte auch das Logo dann klappen.
Die Warteschlange ist allerdings lang, aktuell ist eine Integration von Mitte März an der Reihe und die gehen nach Einreichungsdatum.
wieder Edit:
das Logo ist bei mir zu sehen. Zwar komisch positioniert und so, aber immerhin schon mal drin 
1 „Gefällt mir“
ich habe heute die 1.1.0 installiert (danke für die coolen Features!), aber es klappt mit BTHome leider nicht:
Soweit sollte es passen, oder? Leider wird der Sensor nicht als offline angezeigt, obwohl er ist Stunden offline ist…
Hast du eine Idee?
1 „Gefällt mir“
Du hast einen Template-Sensor erstellt, nicht einen Template-Binärsensor. Das ist der Fehler. Ich hab nur Binärsensoren berücksichtigt. Aber lies erst mal bis zum Ende:
Was passiert
Mein Coordinator prüft:
going_offline = (new_state.state == "on" ...)
coming_back = (new_state.state == "off" ...)
Ein binary_sensor hat immer die States "on" / "off" — egal wie die UI sie anzeigt (deutsch: „Ein"/„Aus").
Ein sensor-Template gibt aber "True" / "False" zurück. Die Prüfung == "on" schlägt fehl → nichts passiert.
Entweder Du fixt das selbst:
In der configuration.yaml muss es heißen:
template:
- binary_sensor:` *`# ← nicht "sensor:"`*
- name: "Zimmertür Büro offline"
Nach dem Ändern: HA neu starten, die neue Entität bekommt dann die Entity-ID binary_sensor.zimmertur_buro_offline. Label neu zuweisen, fertig.
Oder aber Du wartest auf die v1.1.1
Da nehme ich dann “sensor.” mit auf. Du müsstest dann eigentlich nicht mal mehr tätig werden, damit das greift - das hast Du ja dann quasi schon vorbereitet.
Danke Dir, Du hast, mit einem Teil Deiner Angaben, einen Bug gefunden.
Zum Übersetzungsproblem: einmal HA vollständig neu starten (nicht nur die Integration neu laden) — HA cached Übersetzungsdateien und lädt sie nach einem Update nicht immer automatisch neu.
Zum ValueError im Log: das ist ein harmloser Bug, der im nächsten Update (1.1.1) behoben wird. Er hat aber keinerlei Auswirkungen auf die Funktion. (HA fängt ihn ab und loggt nur eine Warnung)
1 „Gefällt mir“
Nun ja, zu irgendwas muß ich ja auch nutze sein. 
Hatte ich vorhin tatsächlich schon im Sinn, wurde dann aber anderweitig abgelenkt. Mach dann nachher vorm pennen.
Dachte weil da was von “locals” stand, könnte es was mit Sprachdateien zu tun haben.
1 „Gefällt mir“
Danke dir! Ich habe inzwischen die 1.1.2 und zusätzlich einen Binär-Sensor angelegt (mit Tag), aber es ändert leider nichts, der Sensor wird vom Observer weiterhin nicht als Offline erkannt 
Kannst Du mir da Dinge zu schicken?
Von den Settings im Observer, vom Sensor und wie der angelegt ist und vom aktuellen Zustand.
Gerne per DM um es hier nicht voll zu schießen.
Eigentlich sollte das nämlich gehen.
Also ich muss jetzt mal Senf dazugeben
Klasse Integration
4 „Gefällt mir“
Und ich muss persönlich werden:
Cooler Username!
Danke
Danke für diese Integration.
Noch ein Hinweis für Nutzer von Zigbee2MQTT: Der Connection Observer funktioniert nur, wenn Entitäten auf “unavailable” gehen, wenn sie offline sind. Zigbee2MQTT setzt das aber nur, wenn die “Availability”-Prüfung eingeschaltet ist. Defaultmässig ist das ausgeschaltet. Einschalten kann man das direkt im Yaml, oder im UI unter Zigbee2MQTT → Settings → Availability → “enable availability checks” (auf deutsch: Zigbee2MQTT → Einstellungen → Verfügbarkeit → enabled)
2 „Gefällt mir“
Guter Hinweis, Danke!
Es ist richtig: Es wird funktionsbedingt ein “unavailable”-Status gebraucht für den Offlinefall.
Edit: Ich habe die Readme und die Dokus angepasst und vor allem einen Hinweis in der Konfiguration eingebaut, wenn Z2M ausgewählt wird.
Ja, so ist ist korrekt.
1 „Gefällt mir“
Das liegt an der Version — du verwendest noch eine ältere Version (vermutlich vor 1.1.10) mit Bug, bei der Entitäten statt ganzer Geräte ausgeschlossen werden. Wenn ein Gerät mehrere Entitäten hat, reichte es nicht, nur eine davon auszuschließen.
Fix: Auf v1.1.13 aktualisieren (via HACS). Danach wird dein bestehender Ausschluss automatisch auf Geräteebene migriert — du musst nichts neu konfigurieren. Das Gerät „Oventhermometer-Stefan" wird danach komplett ignoriert, egal wie viele Entitäten es hat. Der offene HA-Reparatureintrag wird beim nächsten Laden ebenfalls automatisch bereinigt.
Oder anders: Hab ich in der Zwischenzeit bereits gefixt.
Danke für das Feedback!
Danke für den Hinweis. Hatte mir hacs noch nicht angebote. Habe jetzt upgedatet und es ist Ruhe.
1 „Gefällt mir“
Mal ein praktisches Beispiel von mir selbst, wo mir der Connection Observer heute geholfen hat:
Heute Früh gingen nacheinander alle Philips Hue Lampen offline und wieder online. Eine nach der anderen - hat mir der Observer schön gezeigt.
Vermutlich Updates, das ist mir die einzig schlüssige Erklärung.
Im laufe des Tages gingen aber nur noch einzelne davon immer wieder off und on. Nachdem die Updatephase aber schon durch war.
Offensichtlich haben sie es nach dem Update nicht geschafft sich wieder stabil zu verbinden. Das sollte sich nach einiger Zeit (unter Umständen Tagen) eigentlich von selbst lösen.
Ich hab die betreffenden aber per Hand stromlos geschaltet - ca 30 Sekunden gewartet - und wieder den Strom an. Zack, sie haben wieder eine stabile Verbindung. Edit: Nein hatten sie doch nicht. Am Ende musste ich die Hue Bridge neu starten - das hat es aber gebracht.
Das Ganze wäre mir ohne den Observer vermutlich gar nicht aufgefallen. Höchstens mal im Bedarfsfall, dass die jeweilige Leuchte nicht reagiert bzw off ist, aber das das quasi strukturiert passiert wäre mir kaum aufgefallen oder hätte ewig gedauert.
Ich habe ausschließlich IKEA Birnen als Deckenlicht und einmal im Monat, wenn ich dran denke, mach ich kurz die Lichtsicherung aus und wieder an, ist wie ein Reset und die Verbindungen werden aufgefrischt, gleiches gilt für Zwischenstecker und alles sonstige, was als Router fungiert
Die Teile gehen nach langer Zeit gerne mal offline, sind dann aber noch normal ansprechbar, wie ich hier schon schrieb. Da leiden halt auf so eine Lampe gekoppelte Geräte drunter, die dann eben nicht mehr verfügbar sind.
Vielleicht betrifft das ja auch andere Marken, kommen eh fast alle aus der gleichen Fabrik.
Vielen Dank für den Connection Observer! Mit dieser Integration konnte ich vielen meiner häufigen “Aussteiger” von Shelly´s und anderen WLAN Komponenten endlich auf den Grund gehen.
Die häufigste Ursache waren die TUYA WLAN Fenstersensoren, die sich im Protokoll der Fritzbox meist als “ungenutzte WLAN Komponenten” aufhalten und in undefinierten Abständen zuschlagen und sich dabei irgendeine IP-Adresse “kapern”. Damit geht dann häufig das mit einer festen IP in der Fritzbox hinterlegte Gerät kurz offline und danach irgendwann wieder online.
Mit Connection Observer konnte ich dieses Verhalten sehr gut protokollieren und durch Definition eines abgegrenzten IP-Bereich in meiner Fritzbox für die TUYA Fenster- und Temperatursensoren klar von den anderen Geräten, wie z.B. Shelly´s, Kameras, TUYA Steckdosen, usw. trennen. Seitdem habe ich Ruhe im WLAN, keine unerklärbaren WLAN Abbrüche meiner Geräte mehr und auch die Repeater stellen keine WLAN Störungen mehr fest. Ich hoffe, diese Erfahrung hilft auch anderen, die sich mit den gleichen Problemen herumschlagen.
2 „Gefällt mir“