Die Version 2.0.x des Zigbee Adapters ist inzwischen im Latest veröffentlicht. Sie bringt eine grosse Zahl von Neuerungen in den Zigbee-Adapter.

1.10.x -> 2.0.1
Die Entscheidende Neuerung ist der Wechsel auf den Zigbee-Herdsman 3.5 und die Zigbee-Herdsman-Converter 21.x, sowie der Wechsel weg von den im Adapter definierten Gerätebeschreibungen. Daraus resultiert das sich für eine Vielzahl von Geräten die Datenpunkte ändern. Betroffen sind ca. 200 Gerätetypen - wobei es durchaus sein kann das einzelne Nutzer wenig bis gar nicht betroffen sind. Eine Liste von Geräten findet sich in dieser Diskussion auf Github. Es ist nicht auszuschliessen das auch Gerätetypen betroffen sind die sich nicht auf dieser Liste befinden.

Trennung von Adapter-Konfiguration und Adapter GUI:
ab 2.0.1 ist die Benutzeroberfläche des Adapters in 2 explizit getrennte Teile gespalten. Die Adapter-Konfiguration, die von der 'Instanzen' Seite aufgerufen wird und das GUI, welches über den Button in der Seitenleiste aufgerufen wird. Die Trennung ist wie folgt gedacht:

• GUI: Funktionen zur Bedienung des Adapters. Alles was hier ausgelöst werden kann wird ohne Neustart des Adapters aktiv. (Tabs Geräte, Netzwerkkarte, Binding, Debug (ab 2.0.3))
• Konfiguration: Funktionen zur Konfiguration des Instanz-Verhaltens. Wenn hier Änderungen vorgenommen werden kann ein Adapter-Neustart erforderlich werden. Aus Bequemlichkeit ist die Geräte-Ansicht in GUY und Konfiguration identisch und hat auch die gleiche Funktionalität. (Tabs Einstellungen, Geräte, Legacy Overrides, Entwickler)

Der Adapter zeigt dabei sowohl im Adapter-UI als auch im Objektbaum an das entsprechend verwaiste Datenpunkte existieren. Im Adapter UI zeigt die Schaltfläche zum State Cleanup an das sich im Objektbaum verwaiste Datenpunkte befinden. Nachdem diese alle gelöscht wurden wird die Schaltfläche nach einem Neustart des Adapters entfernt.

Im Objektbaum werden die verwaisten Datenpunkte in Orange eingefärbt, so das offensichtlich ist, welche Datenpunkte in Skripten, Aliasen und Visualisierungen angepasst werden müssen.

des Weiteren unterdrückt der Adapter widerkehrende Meldungen über die Verletzung der Wertebereichsgrenzen bei numerischen Datenpunkten. Die entsprechenden Meldungen werden pro Neustart 1x pro Datenpunkt als Fehler ausgegeben, und in der Folge unterdrückt. Im UI des Adapters zeigt eine Schaltfläche an das es unterdrückte Meldungen gibt. Ein Click auf diese Schaltfläche zeigt diese Meldungen im UI an.

Die Netzwerkkarte wird ab 2.0.1 nicht mehr automatisch beim Start sondern erst auf Anforderung durch den Nutzer generiert. Dabei wird nach Erzeugung der Karte eine Auflistung der dabei entstandenen Meldungen gezeigt. Dieses lässt sich über die Konfiguration der Netzwerkkarte selber unterbinden.

Die Konfiguration kann über den orangenen Button oben links geöffnet werden, das Erstellen der Karte erfolgt nach Betätigen des blauen Button unten rechts.

Die Erzeugung der Netzwerkkarte wurde dabei parallelisiert so das insbesondere bei grossen Netzen die Karte schneller aufgebaut werden kann. Dieses erzeugt allerdings eine signifikante Last im Zigbee-Netzwerk weswegen diese nicht direkt nach dem Start des Adapters automatisch generiert wird.

Die Verwaltung der Bilder für die Geräte wurde aktualisiert. Insbesondere nach einer Neuinstallation kann es dazu kommen das die Bilder der Geräte noch nicht herunter geladen sind. Diese werden beim ersten Start nach der Installation herunter geladen und im Admin hinterlegt, so das ggf. in den ersten 120 sekunden nach dem ersten Start nach einer Neuinstallation des Adapters nicht alle Bilder verfügbar sind. Dieses kann aber alleine durch Neu-Laden der Adapterseite behoben werden, sofern für das Gerät ein Bild verfügbar ist.

Auch die Erhaltung von Gerätenamen wurde umgestellt - die Datei dev_names.json wird nicht weiter verwendet. Einzig beim ersten Start der 2.0.1er Version wird diese Datei geladen um bereits gemachte Einstellungen zu erhalten. Die Geräte und Modellspezifischen Einstellungen werden in der Datei LocalOverrides.json abgelegt und sind damit automatisch im Backup der Adapterdaten enthalten. In diesem Zusammenhang wurde auch der Kanal zigbee.x.exposes aufgegeben. Dieser ist weiterhin vorhanden, hat aber keine Funktion mehr.

Zusätzlich ist es inzwischen möglich eigene Bilder für Geräte, Gerätetypen oder Gruppen zu definieren. Diese müssen als PNG < 100 kb im Datenverzeichnis des Zigbee-Adapters (oder einem Unterverzeichnis davon) abgelegt werden damit sie über die Gerätekachel ausgewählt werden können.

Dazu zeigt die Gerätekachel auf der Rückseite weitere Schaltflächen. Auch die Farben / Zuordnungen der Schaltflächen wurde angepasst. In der Reihenfolge von Links nach Rechts haben die Schaltflächen die folgenden Bedeutungen:
Geräte Informationen (i), Debug An/Aus, Gerät Aktiv/Deaktiv, Rekonfiguration, Bild/Name Anpassen, Name/Gruppen anpassen, Gerät Löschen

• Geräte Informationen (i) zeigt die alt bekannte Ansicht mit den Hardware-Details des Gerätes
• Debug An/Aus aktiviert / deaktiviert die Debug Meldungen im Log (äquivalent zur Nutzung des Datenpunktes zigbee.x.info.debugmessages)
• Gerät An/Aus aktiviert/deaktivert das Gerät. Deaktivierte Geräte werden mit rotem Hintergrund dargestellt. Ihre Datenpunkte werden weder überwacht noch vom Adapter aktualisiert. Deaktivierte Geräte werden in der Netzwerkkarte nicht dargestellt.
• Reconfiguration löst einen Versuch der Konfiguration des Gerätes aus (wie bisher). wichtig Eine Rekonfiguration kann nur erfolgreich sein wenn das Gerät erreichbar und wach ist. Ansonsten wird eine Fehlermeldung ausgegeben.
• Bild/Name anpassen: öffnet den folgenden Dialog:
  
  Sofern keine weiteren Bilder bereitgestellt wurden bietet der Dialog 2 oder 3 Bilder zur Auswahl an:
  -- current: das ist das aktuell eingestellte Bild. Wenn dieses Ausgewählt bleibt wird das Bild nicht verändert
  -- default: das ist das Standard-Bild welches vom System vorgegeben wird.
  -- legacy: Falls vorhanden, ist dies das alte vom Zigbee-Adapter verwendete Bild
  Alle weiteren Bilder werden mit ihrem Dateinamen angegeben.
  Der Dialog bietet über die Checkbox 'Apply to Model' die Option die Einstellungen für alle Geräte dieses Types zu übernehmen. Dabei gilt die die Prioritat wie folgt: Höchste Priorität haben die 'pro Gerät' Einstellungen, danach die 'pro Modell' Einstellungen. Nur wenn beide leer sind (Standard) werden die vorgaben genutzt. Um Sicher zu dem vom System vorgegebenen Bild zurück zu kehren muss daher einmal 'pro Modell' und 'pro Gerät' das Bild default ausgewählt werden. Beim Namen wird nur dann zur Vorgabe zurück gekehrt wenn das Feld Name leer ist.
  Diese Einstellungen sind sowohl für Geräte als auch für Gruppen verfügbar
• Name/Gruppen anpassen: Diese Schaltfläche öffnet den Dialog zum ändern von Name und/oder Gruppeneinstellungen. Dabei gibt es 3 Möglichkeiten:
  -- Geräte mit gruppierbaren Endpunkten - Hier kann für jeden Endpunkt ausgewählt werden in welchen Gruppen dieser Mitglied sein soll
  -- Geräte ohne gruppierbarkeit - es wird keine Einstellung zu den Gruppen vorgegeben
  -- Gruppen - hier können Mitglieder durch Abwahl von Geräten / Endpunkten aus der Gruppe entfernt werden

Weiterhin hat es weitreichende Anpassungen im Adapter gegeben die sowohl der Stabilität als auch der Kompatibilität mit dem neuen Herdsman 3.x dienen. Auch die Kompatibilität mit externen Konvertern wurde verbessert. Dieses zu beschreiben sprengt den Rahmen dieses Posts.

Als letztes hat es signifikante Anpassungen bei der Ansteuerung von Farb-Leuchtmitteln gegeben:

• Immer vorhanden ist der Datenpunkt color. Dieser nimmt auf:
  -- #rrggbb
  -- Benannte Farben aus dieser Liste (ggf. muss die css3 Namenstabelle geöffnet werden)
  -- alle bei zigbee2mqtt.io für die entsprechenden Geräte vorgegebenen payloads.
• Nur bei Bedarf vorhanden sind die Kanäle
  -- color_xy mit den Datenpunkten x und y
  -- color_hs mit den Datenpunkten hue und saturation
  -- color_rgb mit den Datenpunkten r, g, b
  Diese Datenpunkte sind nicht direkt mit dem Gerät verbunden Vielmehr wird automatisch 500 ms nach einer Änderung basierend auf den Datenpunkten eines der Kanäle der Datenpunkt color mit dem entsprechenden Payload befüllt um das Gerät zu steuern. Bei Anpassung aus dem Admin wird statt 500 ms 5 sekunden gewartet bis dieses Stattfindet, damit genügend Zeit vorhanden ist um alle Datenpunkte eines Kanals anzupassen.
  In diesem Zusammenhang ist es jetzt auch möglich die Farbe eines Leuchtmittels aus der Gerätekachel einzustellen - durch Wahl der geeigneten benannten Farbe.
  

-> 2.0.2

• Zusätzlicher Datenpunkt action bei Fernbedienungen / Wandschaltern : Ein zusätzlicher Datenpunkt der in einem Eventartigen Datenpunkt die Änderung von allen Schaltelementen abbildet. Dabei wird der Wert des Datenpunkt für 300 ms auf den Bezeichner eines Events gesetzt. nach 300 ms wird der Wert auf '' zurück gesetzt. Eine Liste der möglichen Bezeichner ist in den Objektdaten hinterlegt und kann da ausgelesen werden (Siehe Bild)
  
• Wiederkehrende Nachrichten über Werte-Überschreitungen bei numerischen States werden abgefangen und tauchen pro Adapter-Start nur 1x im Log auf. Über eine entsprechende Schaltfläche (nur sichtbar wenn Daten vorhanden sind) kann eine Liste dieser Meldungen angezeigt werden. Dieses funktioniert für die meisten derartiger Meldungen, aber ggf. noch nicht für alle - die Funktionalität wird aber in der Zukunft erweitert wenn sie als Hilfreich angesehen wird.
• press/hold/release handling. Sofern ein Gerät (Wandschalter, Fernbedienung, etc.) Nachrichtenpaare der Form <prefix>press<postfix und <prefix>release<postfix> sendet, so werden diese zu einem State <prefix><postfix> zusammengefasst, der bei press mit wahr und bei release mit false aktualisiert wird. Das gleiche gilt für hold/release Paare.
• Bugfixes gegenüber 2.0.1

Bekannte Bugs: (Ja, gibt es leider )

• Bestimmte Fernbedienungen (insbesondere Ikea) verweigern eine Konfiguration. Dieses ist auf eine Anpassung an den Zigbee-Herdsman-Converters zurück zu führen und wird in der Zwischenzeit untersucht und in der näheren Zukunft behoben sein In 2.0.2 gefixed
• Es har vereinzelt Effekte gegeben bei denen die Anzeige des Paring-Modes nicht sauber intiailisert. Das Netzwerk wird aber dennoch geöffnet so das ein Pairing möglich ist. Ein Reload im WebBrowser löst das üblicherweise
• Es gibt ein Problem mit dem OTA Update. Ein Fix ist in Arbeit in 2.0.2 gefixed
• Es gibt Auffälligkeiten beim Zurücksetzen bestimmter event-States, z.Bsp. Ikea Fernbedienungen. Dieses wird untersucht. in 2.0.2 gefixed, siehe press/hold/release
• Anpassung der Fehlermeldung beim Device-Configure - die Fehlermeldung suggeriert das das System automatisch bis zu 10 mal versucht die Konfiguration durchzuführen. Das funktioniert aktuell so leider nicht (in 2.0.5 gefixed)
• Der Device-Detektor erkennt farbige Leuchten / Leuchtmittel nicht mehr, da die 'Kanäle' im Device dieses verhindern (2.0.1. - 2.0.5)

Über Tests und Berichte würde ich mich freuen - auch über Anregungen / Kommentare zu den neuen Funktionalitäten.

Wichtg Die 'breaking changes' werden von Entwicklerseite nicht zurück gedreht. Es besteht die Möglichkeit das Personen die die entsprechenden Geräte haben die 'alten' Datenpunkte wieder aktivieren und deren Funktionalität auch mit dem aktuellen Herdsman gewährleisten. Wir werden dabei durchaus unterstützen - die Haupt-Arbeit muss aber von den Nutzern dieser Geräte geleistet werden: Wir geben Hinweise und Anhaltspunkte wo Anpassungen notwendig sind und wie man an die notwendigen Informationen heran kommt, die Anwender müssen sich um die Programmierung und den Test, bis hin zu einem PR auf den Adapter kümmern. Das können wir aktuell nicht leisten.

A.

@meister-mopper sagte in IoBroker --> Rahmenlehrplan Elektromeister:

@guergen
Und wie jetzt weiter?

Und was heisst 'und wie jetzt weiter'.

Es ist eine Information, das in einem Rahmenlehrplan das Projekt ioBroker und seine Fähigkeiten zur Visualisierung von gebäudetechnischen Systemen) gelistet ist. Sprich - es it den verantwortlichen nicht entgangen wie gut das mit dem ioBroker geht. Finde ich toll. Danke für diese Information.

A.

@markus84

Ich sehe die Situation durchaus kritisch.

Auf der einen Seite sind Kosten die der Entwickler hat. Als Mitentwickler an einem Hardwarenahen Adapter kann ich das nachvollziehen. Hardware zum Testen kostet Geld. Testen auf fremder Hardware kostet Zeit, Nerven und letztendlich auch irgendwo Geld.

Jeder der in irgend einer Form hardwarenah entwickelt und das nicht nur auf/mit der bei ihm selber eingesetzten Hardware tut hat also Kosten zu tragen.

Leider ist der ioBroker bisher in der Position das selbst lokale Hardwarehersteller wie z.Bsp. Dresden Elektronik (DeConz) einer interoperabilität wenn überhaupt neutral gegenüber stehen - schön wenn es geht, aber Rücksicht drauf nehmen das es in Zukunft auch geht: eher nicht. Auch die Organisationen die sich um Standards (KNX Association, Zigbee Alliance) sind für die meisten ioBroker Entwickler unzugänglich. Dazu kommt das es selbst bei den Standards verschiedene Auslegungen gibt, so das eine Interoperabilität selbst bei vollständiger Compliance mit den Standards nicht garantiert ist.

All das sind Probleme mit denen sich die Entwickler herumschlagen müssen wenn sie den Adapter auf Stand halten wollen.

Solange das nur für die vom Entwickler selber eingesetzte Hardware gemacht wird ist testen und verifizieren verhältnismässig einfach und die eingesetzte Zeit kann direkt als Investition in ein funktionierendes smartes Eigenheim gesehen werden. In dem Moment wo auch andere Konfigurationen laufen sollen nimmt der Aufwand (Zeit und Geld) massiv zu.

Auf der anderen Seite sind die Anwender. Das nicht jeder bereit ist monatlich für eine Funktion zu zahlen kann ich nachvollziehen - insbesondere wenn damit keine Funktionsgarantie einher geht. Das ein Entwickler der das nebenher als Hobby macht diese Garantie geben kann halte ich für unrealistisch.

Auf der anderen Seite halte ich die im zur Grunde liegenden Beispiel aufgerufenen "Lifetime" Kosten für deutlich zu hoch angesetzt. Lifetime = 10 Jahre ohne "Rabatt" für die Jahre anzusetzen müsste damit einher gehen das sichergestellt ist das der Adapter auch 10 Jahre zu betreiben ist (Anpassungen an neue NodeJS Versionen etc. vorausgesetzt). Ob das der Fall ist ist aber auf jeden Fall Kritisch.

Jetzt noch 3 Punkte zur Diskussion am Ende:

• Es ist - wie Ingo bereits geschrieben hat - nicht die erste kostenpflichtige Option für den ioBroker. Auch im ioBroker selber gibt es Anwendungen die nur eingeschränkt kostenlos nutzbar sind. Die Nutzung der IOT und/oder Alexa Funktionalität sowie des ioBroker.link Adapters ist nicht kostenfrei.
• Ich persönlich lehne im übrigen alle Abo Modelle für Software die ich "as is" nutze prinzipiell ab. Nur bei Diensten bei denen neben der Software selber auch noch eine andauernde Dienstleistung erbracht wird bzw. wenn eine Bezahlung nach effektiver Nutzung einer extra erbrachten Dienstleistung erfolgt bin ich bereit dieses zu akzeptieren. Bisher ist es mir gelungen bei jeder von mir verwendeten Software entweder auf eine Kauf-Option zu Wechseln oder eine alternative Software zu finden.
  Der vorliegende Fall wäre - wenn ich KNX denn einsetzen würde - einer der Fälle wo ich mich um eine alternative Implementierung bemühen müsste, weil ich die aufgestellten Kostenmodelle so nicht akzeptieren wollen würde.
• Eine Unterscheidung zwischen kommerzieller und privater Nutzung halte ich nur bedingt für angebracht. Soweit ich das einschätzen kann gibt es 2 Arten von gewerblicher Nutzung: Nutzung des ioBroker in einem Gewerbebetrieb - dieses ist 1:1 mit einer Nutzung im Smart-Home vergleichbar und Nutzung als Gewerbe, bei dem über Installation, Konfiguration und Support von ioBroker Installationen Umsatz generiert wird. In beiden Fällen muss die Leistung (das am laufen halten der ioBroker installation) vom "Nutzer" erbracht werden.

A.

p.s. Während ich diesen Text geschrieben hat kam die "offizielle" Stellungnahme von Ingo herein, deswegen ein paar Edits.

Kurzes Update:

Vielen Dank an @hugo1217 - mit ihm zusammen war es mir möglich die Probleme damit das der Zigbee Adapter 1.10.10 oder neuer geräte steuert bis zu Aufrufe an den benutzten Bibliotheken zurück zu führen. Jetzt bin ich dabei das ganze mit den Maintainern der Bibliotheken durchzugehen - was ggf. Ursache und Abhilfemassnahme sein kann.

Das wird aber noch ein paar Tage dauern. Bis da hin bräuchte ich von jedem der das Problem hat (Adapter startet, Daten von den Geräten kommen am Adapter an, aber der Adapter kann keine Geräte steuern) genauere Informationen zur Hardware:

• Welcher Stick wird benutzt
• mit welcher Firmware
• auf welcher NodeJS Version

Die Firmware des Stick lässt sich direkt im Zigbee Adapter ablesen:

des Weiteren wäre ich daran interessiert ob irgend jemand die 1.10.10 oder neuer mit einem CC2531 Stick laufen hat.

A.

Hallo,

nachdem die Tests mit der 1.11.x Version wenig erfolgversprechend waren haben wir (die Zigbee-Entwickler) uns dazu entschlossen eine neue Version mit einer grösseren Zahl an 'breaking changes' fertig zu machen. Diese läuft aktuell Immer noch unter 1.11, wird aber wahrscheinlich als Version 2.0 veröffentlicht werden.

Für diese Version werden Tester gesucht. Folgendes wird sich ändern:

• Alle Geräte werden auf Basis der von Zigbee2mqtt.io vorgegebenen Exposes im ioBroker implementiert. (Bereits aktiv - bitte testen, kommentieren)
• Es soll möglich sein für einzelne Gerätetypen auf die 'alten' Definitionen aus dem Zigbee Adapter v1.10.x zurück zu greifen - dazu gibt es den Tab 'Legacy Devices'. Geräte die hier eingetragen sind werden die alten Definitionen nutzen. Das kann dazu führen das bestimmte Funktionen nicht mehr gegeben sind, wenn die alten Definitionen nicht mit den aktuellen Zigbee-herdsman-convertern zusammen spielen. Dieses wird von uns zunächst nicht aktualisiert. Anpassungen können auf Basis von (noch zu erzeugenden) Log-Meldungen als PR's am Adapter eingereicht werden (ohne die Meldungen auch gerne jetzt schon) (Bereits aktiv, bitte testen, kommentieren). Nach dem Anpassen der Legacy Overrides muss der Adapter neu gestartet und ein State-Cleanup durchgeführt werden um die Anpassungen zu sehen.
• Es soll möglich sein für einzelne Geräte (später auch Gerätetypen) eigene Bilder zu definieren. (Bereits aktiv - bitte testen, kommentieren) Das passiert in 3 Schritten:
  -- Schritt 1: das Gewünschte Bild als PNG (Grösse < 100 kb) in das Datenverzeichnis des Zigbee Adapters (oder ein Unterverzeichnis davon) kopieren (/opt/iobroker/iobroker-data/zigbee_x , wobei x die Instanz-Nummer ist.
  -- Schritt 2: auf der umgedrehten Kachel das neue Bild auswählen
  -- Schritt 3: ein Upload des Zigbee Adapters durchführen.
  Erst nachdem alle 3 Schritte erfolgreich durchgeführt wurden wird das neue Bild im Adapter genutzt.
• es soll möglich sein (analog zu den externen Konvertern) externe Device-Definitionen machen zu können. (aktuell nicht implementiert)
• die Optionen zum verwalten der Gruppen sollen verbessert werden, so das Geräte von der Gruppen-Kachel aus der Gruppe entfernt werden können. (aktuell nicht implementiert)

Wichtig Diese Adapter-Version ist im Alpha-Stadium. Nicht weil sie besonders oft abstürzt, sondern weil sich bei der Erstellung der States aus den Exposes noch Anpassungen ergeben werden. Eine Nutzung als Produktiv-Adapter ist daher nicht empfohlen

Zum testen muss der aktuelle Test-branch von meinem GitHub installiert werden. (Link: https://github.com/asgothian/ioBroker.zigbee/tarball/1.11).

An Vorschlägen wie einzelne Funktionalitäten angepasst / verbessert werden können bin ich interessiert.

Edit: Auch wenn der Adapter offiziell noch unter Node 18+ läuft habe ich festgestellt das die verwendeten Bibliotheken auf Node 20 angewiesen sind!
A.
Nachtrag: Nochmal ganz deutlich - wer diesen Adapter auf seinem aktiven ioBroker nutzt riskiert das er bei jeder neuen Version weitere Anpassungen am Umfeld (Skripte, Visualisierungen) durchführen muss. Auch ist der Adapter aktuell nur mit wenigen Koordinatoren getestet - auch da können Auffälligkeiten auftreten. Installation auf eigene Gefahr !!!

Es gibt eine neue Version im Latest - 2.0.3.

Diese beinhaltet primär bugfixes, wie z.Bsp. die Spannung bei batteriebetriebenen Geräten, die jetzt die korrekte Einheit (mV) meldet. Ich habe mich dagegen entschieden den Zahlenwert anzupassen, da dieses die Werte bei allen Sensoren geändert hatte. Parallel dazu wurde auf die neueren Zigbee-Herdsman-Converters (23.1.1) gewechselt.

Des Weiteren gibt es eine Anpassung bei der Gerätekonfiguration. Diese wird auf der einen Seite jetzt korrekt in der Geräteinformation angezeigt - wobei die Anzeige nur zeigen kann ob der Adapter der Meinung ist das das Gerät konfiguriert wurde. Der Adapter bekommt es weiterhin nicht mit wenn ein Gerät die Konfiguration verliert. Zum anderen wird die Konfiguration unter Umständen automatisch wiederholt. Wenn bei der Konfiguration eine Zeitüberschreitung auftritt geht der Adapter davon aus das das Gerät nicht wach war und deswegen nicht geantwortet hat. Sobald ein Event vom Gerät empfangen wurde wird die Konfiguration erneut gestartet. Dadurch sollte es einfacher sein batteriebetriebene Geräte zu konfigurieren.

Die letzte grosse Anpassung betrifft den Debug-Tab, der inzwischen aktiv ist. Dieser ist zusammen mit dem von der Gerätekachel einzustellenden Debug Modus für Geräte zu nutzen. Eine detaillierte Beschreibung ist in Arbeit.

Der Tab zeigt die eingehenden und ausgehenden Meldungen je Gerät untereinander an. Dabei werden nicht alle Nachrichten aus dem Log angezeigt - man kann aber an Hand der Anzeige erkennen an welcher Stelle eine Kommunikation abgebrochen wurde. Siehe als Beispiel die beiden folgenden Screenshots:

Eingehende Meldungen

Ausgehende Meldungen

Die Darstellung aktualisiert sich nicht automatisch damit während der Analyse keine neuen Nachrichten erscheinen. Eine manuelle Aktualisierung ist über den grünen Button möglich. Dabei aktualisieren alle grünen Buttons immer alle nachrichten.

Die blauen Buttons dienen der Anpassung der Anzeige. Dabei wirken die Buttons oben auf der Seite auf alle Nachrichten, während die an den Eingehenden / Ausgehenden Nachrichten verankerten Buttons sich nur auf die jeweilige Sektion auswirken.

Mit diesem Button lassen sich Meldungen ein/ausblenden.Dabei wird jeweils der gesamte Block ausgeblendet (Alle eingehenden oder ausgehenden Nachrichten eines Gerätes)

Mit diesem button lassen sich die Meldungen filtern. Dabei versucht das System automatisch gleichartige Nachrichten zu erkennen und auf jeweils eine dargestellte Zeile zu reduzieren.

A.

Auf Github ist die version 3.1.0 des Zigbee Adapters vorhanden. Dafür benötige ich freiwillige zum Testen. Da es eine massive Anpassung war gibt es durchaus ein Risiko von Abstürzen. Allerdings sind die Änderungen gegenüber 3.0.5 gering, so das ein zurückspielen der 3.0.5 immer gehen wird.

Installation via Github vom ioBroker repository.

Folgendes ist neu:
Synchronisation für Gruppen / Mitglieder

• Änderung eines Gruppen States (ack = false) => der Adapter versucht den Status der Mitglieder zu lesen. (Wichtig: Nur der in der Gruppe angepasste state wird gelesen - wichtig bei Gruppen von Leuchten, wenn via brightness eingeschaltet wird. (Hier kann es ggf. noch Timing-Probleme geben)

• Änderung eines Mitglieder States (ack = false) => der Adapter bewertet den Status aller Mitglieder und setzt den Gruppenstatus entsprechend (mit ack=true) Ansteuerung über den State stateupdate. Gültige Werte sind: 'off' - keine Synchronisation (default), 'mat' - match -> der Gruppenstatus ändert sich wenn alle Mitglieder den gleichen Status haben. 'avg' der Gruppenstatus wird auf den durchschnittlichen Status aller Mitglieder gesetzt, wobei bei true/false intern true=1, false=0 gerechnet wird, und beim setzen gilt true = avg>4.9999999, 'min' - Der Gruppenstatus entspricht dem 'geringsten' Mitgliederstatus. 'max' - Der Gruppenstatus entspricht dem 'höchsten' Mitgliederstatus

• Optional: automatisch ein device_query wenn ein Gerät sich neu am Netz meldet (und als 'pingable' gilt - Konfigurierbar über die Einstellungen)

• Optional: automatisch beim Start für alle 'pingable' Geräte ein Device-query absetzen (incl. Timeout in sekunden, min 0.5 sekunden, max 10 sekunden, default 1 Sekunde. - konfigurierbar über die Einstellungen / an/aus, timeout)

Improved device_query - Device_query liest jetzt mehr Werte, und wirft weniger Fehler
ZH 5.0.3

Admin: Wird das Pairing vom Tab aus gestartet, so kann es angehalten oder verlängert werden.
Admin: Die Funktionen 'firmware update', 'touchlink reset', 'pairing with code', 'gruppe erzeugen' sind nur noch im Zigbee-Tab zugänglich
Admin: Die Karte des Koordinators wird immer dargestellt wenn der Adapter gestartet wurde - auch wenn das Zigbee-Subsystem nicht läuft (mit begrenzter Info)
Admin: Die Koordinator-Karte zeigt die ZH/ZHC und Adapter version

ToDo:

• (Prio 2) optimierung bei den nicht unterstützten Gruppenstates
• (Prio 4) Umgang mit den 'color' states bei memberupdate und stateupdate
• 'no converter for' Meldungen beim anpassen von memberuptate und stateupdate Fixed 11.9.
• (Prio 3) Deaktivierte Geräte die in Gruppen sind werden aktuell nicht vom Leseversuch der States ausgenommen
• Lesen der States asynchron gestalten, sowie mit einer einstellbaren Verzögerung ausstatten Asynchron: done 11.9. Einstellbare Verzögerung - unnötig
• Bindings: Bindings aus dem Zigbee-Herdsman holen und damit synchronisieren
• (Prio 7) Umstieg zu Z2M: Export für Gruppen und Bindings, damit diese vor einem Umstieg nicht zwangsweise gelöscht werden müssen
• (Prio 1) Timing-Auffälligkeiten bei der Konfiguration von neuen Geräten.
• (Prio 6) Recall Map data Option
• (Prio 7) save map Data as png option

Über rege Mithilfe würde ich mich freuen.

Version 3.1.3: Es gibt weitere Neuigkeiten:

• Deaktivierte Geräte sind jetzt in den Objekten erkennbar:

Im Tab:

Im Objektbaum:

Debug Interface verbesserungen:

• Mehr Meldungen im Log
• Links um sich die Log Meldungen zu bestimmten events gezielt anschauen zu können (die blauen Icons links)
  
• Anzeige so das sie direkt kopiert und mit code tags und allem im Forum gepostet werden können
  

Da rauskopiert, hier einkopiert sieht das dann so aus:

I01: Zigbee Event of Type readResponse from device 0x00be44fffeab0b87, incoming event: {"type":"readResponse","data":{},"linkquality":163,"groupID":0,"cluster":"seMetering","meta":{"rawData":{"type":"Buffer","data":[8,14,1,1,0,134]},"zclTransactionSequenceNumber":14,"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0}},"endpoint_id":1}
I02: 1 converter available for 'E2206' '00be44fffeab0b87' with cluster 'seMetering' and type 'readResponse'
I03: message received '{"linkquality":163}' from device 00be44fffeab0b87 type 'E2206'
I04: value generated '163' from device 00be44fffeab0b87 for 'Link quality'
I02.1a: data: {} options: {} meta:{"deviceIEEE":"0x00be44fffeab0b87","logger":"StatesController","state":{"state":""}} result:{}
I02.1b: converter 1 : Cluster seMetering => payload : {}
I03-1: message received '{}' from device 00be44fffeab0b87 type 'E2206'
NOVAL: No value published for device 00be44fffeab0b87

A.

@Homoran - machst du den 3.0 Tester thread bitte zu ?

Nachtrag: Es gibt inzwischen eine 3.1.1, die die ZHC 25 integriert. Alle die die 3.1 installiert haben bitte ich auf die 3.1.1 zu aktualisieren. ! Es gibt inzwischen eine 3.1.2 - auch die nutzt ZHC25 und ZH 6, besitzt aber auch einen Fix für den Pairing bug.

Hallo zusammen,

nachdem die 3.1.5 erfolgreich im Stable gelandet ist (und die 3.1.6 im latest) habe ich die 3.2.0 als 3.2.0-alpha.0 fertig gemacht. Jetzt brauche ich dafür Tester:

Wichtig - die Version ist so weit das ich den kurzfristig bis ins latest bringen will. Ich brauche aber vorher noch ein paar mehr Leute die den testen, damit das nicht zu Chaos führt.

Die Anpassungen in der 3.2.1 sind primär kosmetisch, intern und bugfixes.

Folgendes hat sich geändert / wurde verbessert. (Einiges davon geht auch schon in 3.1.6, aber ohne doku etc.)

UI:

• Anpassungen auf der Gerätekachel:
  -- dieses Icon ist entfallen:
  -- Die Funktion davon wurde in den edit Dialog integriert
  -- dieses Icon ist neu - und nur bei Geräten verfügbar die Gruppen hinzugefügt werden können. Es dient ausschliesslich dazu, die Mitgliedschaft in Gruppen zu verwalten. Man kann damit nicht den Namen des Gerätes ändern.
  -- Der Edit Dialog wurde angepasst. Er erlaubt jetzt neben dem Anpassen des Namens auch die Auswahl des Bildes und die Auswahl von Gerätespezifischen Optionen - so wie sie bei Z2M angegeben sind. Es werden auch immer nur die Optionen angeboten die von den ZHC gemeldet werden: . Eine Überprüfung der Werte für die Optionen findet aktuell nur bedingt statt, und die Optionen werden in der 'LocalOverrides.json' gespeichert - sie überleben also ein Löschen und neu anlernen des Gerätes. Allerdings können sie hier ausschliesslich auf device Ebene vergeben werden. Die Möglichkeit diese global zu definieren ist an eine andere Stelle gewandert.
  -- die Zuordnung zu Räumen ist gewandert - aus der Fusszeile mit den Icons auf die Kachel selber. Dies wurde Notwendig weil sich die Anzahl der Buttons erhöht hat:
  -- Das vorhanden sein von unbekannten Geräten wird im Log nur noch 1x bei Adapter-Start geloggt, und in der Folge in die interne Fehlerliste (sichtbar über diesen Button, der nur existiert wenn die Liste nicht leer ist) geschrieben.
  -- es gibt ein weiteres Icon auf der Kachel, welches darüber informiert wenn ein Gerät nicht vollständig interviewed werden konnte. Dies kann in seltenen Fällen passieren und führt dazu das das Gerät nur teilweise funktioniert. Solche Geräte sollten gelöscht und neu Verbunden werden.
  -- es gibt noch ein weiteres Icon welches ausschliesslich am Koordinator auftauchen kann: . Das Orangene Pause Symbol weist darauf hin das dieser Haken nicht gesetzt ist.

Konfiguration

• der Tab Local Overrides ist entfallen. Die Funktionalität ist in den Tab Local Data gewandert
• Der Tab Local Data ist neu - er listet die vorhandenen Devices gruppiert nach Modell auf, und erlaubt:
  -- das Löschen von Geräten
  -- das Einstellen von Optionen auf Model Ebene (Global für alle Geräte dieses Typs - incl. eines Default Namens !)
  -- das Aktivieren und deaktivieren von einzelnen Devices
  -- das 'vollständige' Löschen eines Gerätes (incl. der eingestellten Optionen, des Namens und der Bildzuordnung) (noch nicht zu 100% implementiert)
  
  Hier sind neben den vom ZHC vorgegebenen Optionen noch weitere Einstellungen möglich. So können custom Optionen vergeben werden (die z.Bsp. in externen Convertern verarbeitet werden)
  Zusätzlich kann bei Geräten für die es eine Legacy Implementation gibt diese aktiviert werden. Die Option dazu heisst 'Legacy', und ist im Beispiel nicht vorhanden weil das Gerät diese nicht besitzt.
  wichtig das Feld 'Name' Ist explizit leer, damit der Name nicht umdefiniert wird.
  

Bugfixes und Anpassungen:

• das Pairing am Router ist jetzt nochmal verbessert worden - es sollte funktionieren.
• die Erkennung von Routern ist verbessert worden - nur Router sollten das Pairing am Router anbieten.
• Auf der Kachel gibt es neben dem Pairing button auch einen 'device_query' button um die States auszulesen (sollte schon ab 3.1.5 vorhanden gewesen sein, auch wenn der erst ab 3.2.0 geplant war.
• Weniger Meldungen wegen standard-Aktionen
• Nutzung des neusten ZHC
• Restore aus dem Adapter internen Backup über die Oberfläche mit diesem Button

Weitere geplante Anpassungen:

• Umstellung der Bindings auf die bei den Gruppen verwendete Methode
• Erweiterung der Bindings auf 'freie Binding Wahl' um erweiterte Zigbee Funktionen möglich zu machen, z.Bsp. Binden eines Temperatursensors an einen Thermostat als externe Quelle für die gemessene Temperatur
• Weitere Verbesserung bei den Optionen (Überprüfung von mehr Werten sofern diese von den ZHC vorgegeben werden
• verbessertes Handling von komplexen Exposes (Bsp. Zeitpläne bei Thermostaten, etc)

wichtig : Bei Nutzern mit externen Konvertern kann es in der 3.1.5 und 3.1.6 zu Problemen mit diesen führen wenn ZHC > 25.38.0 installiert sind, da in den ZHC (mal wieder) plötzlich aufgeräumt wurde. Erst in der 3.2.0 ist code vorhanden, der diese Auffälligkeit beseitigt. Mehr Details dazu gibt es in [diesem Post](Link Adresse) (Forum Link)

A.

@thisoft sagte in Phillosophie und was sein darf oder auch nicht:

Beschweren sich hier ernsthaft Leute die die Kohle haben ihr "Häuschen" mit KNX-Hardware auszustatten, dass 14 Euro im Jahr zu viel Geld wären und sie deshalb zu einer (noch) kostenloseren Software wechseln "müssten"????

Ich fürchte da missverstehst du etwas.

Wenn ich auch die Kommentare zu den kostenpflichtigen Adaptern mit einbeziehe dann geht es nur wenig um die 14 Euro KNX, sondern um die Frage was passiert wenn auch andere Entwickler auf ein Abo-Modell für den Adapter umsteigen.
Dieses beträfe dann auch Leute die sich weder ein "Häuschen" noch KNX-Hardware leisten (können oder wollen). 2 Euro pro Monat für KNX ist das eine, je 2 Euro pro Monat für jeden Eingesetzen Adapter kann schon schnell ins Geld gehen. Das sich Leute da Gedanken machen kann ich verstehen.

A.

@codierknecht sagte in Your system is booting into "graphical.target":

@mickym sagte in Your system is booting into "graphical.target":

Es gibt auch Leute, die nutzen einen Monitor mit einem Dashboard an einem Server. Man kann das durchaus differenzieren

Wie viele? 1%? Oder sogar weniger?

wäre es nur mal ganz schön, wenn man nicht immer mit dieser absoluten - ich habe die Wahrheit gepachtet - Dogmen in die Welt posaunt

Habe ich nicht.
Ein mitgeschleppter Desktop ist aber mit verdächtiger Häufigkeit Ursache von Problemen, die man ohne mit ziemlicher Sicherheit nicht hätte.

Das wage ich deutlich zu bezweifeln.

Es mag einen Zusammenhang geben zwischen Installationen mit Desktop und anderen ‚Unsauberkeiten‘ die zu Problemen führen, aber alleine das vorhanden sein eines Desktop führt (abgesehen von dessen Speichernutzung) eher selten zu Problemen.

Ein Warnhinweis im Diag Skript ist dementsprechend gut. Die Forderung den direkt als erstes abzuschalten ist aber überzogen, und eine Automatisierung behindern der Fixer das direkt macht ist dann eher störend.

Zum Thema Dogmen wiederholen - genau das passiert meiner Meinung nach, da gebetsmühlenartig immer wieder geschrieben wird „ein Desktop hat auf einem Server nichts zu suchen“. Das ist aber (inzwischen) nicht mehr zwingend richtig. Richtig ist: ein Server mit Desktop sollte nicht als „arbeitsystem“ genutzt werden.

Wenn das benutzte System die Ressourcen dafür hat spricht durchaus einiges dafür die Administration eines Servers direkt über die GUI des Servers zu machen anstatt alles über die kommandozeile machen zu müssen. Unter anderem gibt es dazu oft deutlich mehr Hilfestellung im Netz. Als Beispiel kann da dienen wie man einem System eine feste IP zuweist - auf dem System und nicht über den DHCP Server. 75% der Antworten verweisen inzwischen auf die GUI Tools während die Erklärungen zur kommandozeile insbesondere für linux-Neulinge schwer verdaubar sind.

A.

@jb_sullivan sagte in Sonoff (tasmota) aktualisiert Zustands DP&#x60;s nicht mehr:

Wie gesagt, ioBroker oder der Sonoff Adapter bekommen es nicht mehr mit, wenn das Gerät über Extern eingeschaltet wurde.
Hat jemand eine Idee dazu? Ggf. ein (bekanntes) Adapter Problem?

was passiert am Gerät wenn du den DP 'POWER' schaltest, an Stelle des DP 'POWER1' ?

A.

@legro sagte in YAHKA & BackItUp:

Jetzt war ich natürlich zwischenzeitlich auch fleißig. Ich fand ..

.. dass man den Ordner yahka.X.hapdata aus dem alten System an dieselbe Stelle im neuen System kopieren sollte.

Dieses sollte das Backup von Yakha via Backitup erledigt haben.

A.

@legro sagte in YAHKA & BackItUp:

@asgothian

Vielen Dank für deinen Hinweis.

Wenn ich das Ganze nun richtig verstehe, muss ich alles neu einrichten. D.h.: Die Sicherung von BackItUp ist beim Umzug auf neue Hardware völlig wertlos.

Nein

die Sicherung von Backitup sorgt dafür das die Freigabe von ioBroker Datenpunkten zu Homekit erhalten bleibt.

Die Prinzipielle Funktion ist also gegeben. Was du ggf. machen musst ist in Homekit die Raumzuordnung neu machen.

Ohne das Backup müsstest du die gesamte Konfiguration in Yahka neu machen.

A.

@legro Wenn ich das richtig erinnere musst du die Bridge auf aus Homekit entfernen und neu hinzufügen wenn sich die Hardware ändert. Dabei geht dann die Zuordnung der Geräte zu den Räumen und zu den Automatisierungen verloren.

A.

@volker3-0 sagte in Zigbee verliert alle paar Tage alle Fensterkontakte:

Hallo,
ich habe ein Problem mit meinen Zigbee Fensterkontakten ( Ikea) dass diese alle paar Tage keine Verbindung mehr haben zum iOBroker über den Sonoff-Stick.

Woran kann das liegen?

Gruß Volker

Fangen wir vorne an:

• bist du sicher das die die Verbindung verloren haben ? Sprich - wenn du die Fenster öffnest, reagieren dann die Datenpunkte ?
• Das Bild der Netzwerkkarte ist bei batterie betriebenen Geräten nicht aussagekräftig.
• Der Adapter grün heisst nur das der Adapter das Zigbee Netz aufgemacht hat.
• wie passen WLan (2.4 GHz Kanal) und Zigbee Kanal zusammen ?
• wie weit sind die Sensoren vom Sonoff stick weg, und was ist da an 'hardware' dazwischen (Wände, Stahlbeton, Pflanzen, Wasserleitungen, und. so. weiter

A.

@sigi234 Klar doch Denkfehler

Du musst den 'code' Teil auch irgendwo als Skript hinterlegen. Gerne hinter dem was du als 'aufruf' als Skript gemacht hast. Besser nicht in einem externen Skript.

A.

@george_best sagte in iob fix und iob diag ohne Reaktion:

ich bin da jetzt etwas lost. Was könnte ich löschen?

schau mal nach den Log Dateien, bzw. den Dateien der Adapter unter /opt/iobroker/log und /opt/iobroker/iobroker-data/... Da sollte es einiges altes geben.

Insbesondere backitup kann da viel daten ablegen.

A.

@cash sagte in Error in callback: TypeError: axios is not a function:

Nach dem Update vom JavaScript Adapter habe ich auf einmal Fehler bei Scripten wo ich axios nutze. Was muss ich ändern damit es wieder läuft?

Hier ein Teil vom Script welches das Problem ist. Variablen wie z. B. pushover_acknowledged ist weiter oben im Script deklariert.

//Pushover muss bestätigt werden
            if(pushover_acknowledged){
                pushover_acknowledged = false;
                const axios = require('axios');
                var URL = 'https://api.pushover.net/1/receipts/cancel_by_tag/'+pushover_tag +'.json';         
                            
                axios({
                    method: 'post',
[...snip]

Hmm.. nach der Axios doku kann das so eigentlich nicht gelaufen sein. Hast du da am Skript was getan (request gegen Axios getauscht ? )

Unsinn - ich hab an der falschen Stelle geschaut.

A.

@karsten sagte in Gelöst(Conbee 3: Das erste Mal ärgere ich mich ..):

Ich dachte tauschen und gut. War nix !

Hattest du das hier gelesen:

https://phoscon.de/de/conbee3/upgrade

Mal eben den Stick umstecken und glauben das dann das Phoscon Netz übernommen wird ist nicht.

A.

Nachtrag:

Deine Logs zeigen recht deutlich das die Phoscon Software den ConbeeIII durchaus sieht, aber nicht mit ihm arbeiten kann:

Auszug von den beiden Logs:
DiskStation:

|__usb1          1d6b:0002:0404 09  2.00  480MBit/s 0mA 1IF  (Linux 4.4.180+ xhci-hcd xHCI Host Controller 0000:00:15.0) hub
  |__1-1         0403:6015:1000 00  2.00   12MBit/s 90mA 1IF  (dresden elektronik ConBee III DE03309818)

Docker:

11:37:01:205 COM: /dev/ttyUSB0 / serialno: DE03309818, ConBee     

Der Stick ist also sauber durchgereicht.

@thomas-braun sagte in ioBroker ohne nodejs...:

Wer kommt drauf?

echad@chet:/opt/iobroker $ iob status
iobroker is running on this host.


Objects type: jsonl
States  type: jsonl
echad@chet:/opt/iobroker $ apt policy nodejs
nodejs:
  Installed: (none)
[...]
echad@chet:/opt/iobroker $ node -v
v24.11.0
echad@chet:/opt/iobroker $ node -vv
v6.0.2
echad@chet:/opt/iobroker $ 

manuell übersetzt oder nicht als Paketquelle via apt install installiert.

A.