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.

@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.

Hallo zusammen,

nachdem die 2.0. erfolgreich im Stable gelandet ist (als 2.0.5) hat @arteck für mich die 3.0 zusammengebaut und ins Latest verfrachtet (nochmal Danke dafür). Jetzt brauche ich dafür Tester:

Changelog:

• Breaking change: Start of zigbee subsystem requires configuration entry !!!
• Hardware configuration panel
• Update for external converter - detect /dist/ subfolder
• Update device image: use of icons defined in external converter (beta)
• Updated Adapter documentation

Die Version beinhaltet wieder einen breaking change - aber deutlich kleiner als zuvor. Wird die Version installiert und dann neu gestartet wird das Zigbee-Subsystem nicht automatisch gestartet. Der Adapter läuft dann zwar, bleibt aber gelb und es lassen sich keine Zigbee-Geräte ansteuern. Das ist kein bug, sondern by design.

In der Konfiguration des Adapters gibt es ein neues Tab Hardware. Auf diesem sind alle Hardware-Relevanten Einstellungen zu machen - und man kann sie damit auch gleich testen. Genau diese Funktionalität hätte ich gerne getestet. Damit das entsprechend einfach geht habe ich die Doku (Deutsch/ Englisch) angepasst. Da ist dann beschrieben wie eine neue Instanz eingerichtet werden soll.

Für die die nur kurz installieren und später testen wollen - damit der Adapter das Zigbee-Subsystem automatisch startet, muss der Haken bei G in der Konfiguration gesetzt werden.

Diese Änderung war notwendig weil es immer wieder Probleme bei Anfängern gab den Adapter sauber aufzusetzen. Eine automatische Trennung zwischen 'konfiguriert' und 'nicht konfiguriert' ist mir nicht gelungen, deswegen die Notwendigkeit für eine manuelle Einstellung.

Erklärung zum Configure in 3.0:
Bei Adapterstart wird im System geprüft ob das System eine erneute Konfiguration anfragt. Dazu gibt es Daten im ZHC / State. Wenn das System eine Konfiguration für notwendig erachtet wird versucht das Gerät zu konfigurieren. Dabei gibt es 3 mögliche Ergebnisse:

• Erfolg - Die Konfiguration wird eingetragen - solange das Gerät nicht bei jedem Neustart eine Neukonfiguration fordert wird es nicht wieder konfiguriert, egal wie oft der Adapter neu startet
• Zeitüberschreitung: Das Gerät hat nicht geantwortet: Dieses Gerät kommt in die 'configure_on_message' Struktur. (siehe unten)
• Miserfolg - Die Konfiguration konnte nicht durchgeführt werden. Das Gerät wird beim nächsten Start erneut einen Konfigurationsversuch erleben.

configure_on_message:
Diese Methode dient dazu das insbesondere batteriebetriebene Geräte einfacher zu konfigurieren sind. Ein Gerät welches hier eingetragen wird wird in dem Moment konfiguriert wo der Adapter eine Nachricht des Gerätes erhält - ausgehend von der Annahme das das Gerät dann wach ist und die Konfiguration erfolgreich sein wird. Dieses wird

• max 5 mal probiert
• max alle 5 Sekunden probiert, egal wie viele Meldungen in der Zwischenzeit eintreffen.
  Aktuell erzeugt es noch viele Info-Meldungen. Diese werden mit der Zeit auf eine Sinnvolle Anzahl reduziert.

Update 26.04.2025:
Die 3.0.1 ist im Latest. Änderungen:

• Verschiedene Bugfixes.
• Icons statt Text auf den Knöpfen im Hardware-Tab
• Begrenzung der auf den Kacheln sichtbaren Datenpunkte (Ausschluss von Enums mit genau 1 Option und beschreibbaren DP ohne UI Element)
• Eingabemöglichkeit von 'pro device' Optionen. (siehe hier)

Hinweis Nutzer von externen Konverter bei denen ein /dist/ in den Include Pfaden mit angegeben ist müssen dieses entfernen. Der Adapter erkennt selbstständig ob die verwendete ZHC Version dieses benötigt oder nicht und fügt es automatisch hinzu.

A.

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

Was dann hier wohl für eine große Anzahl von Anwendern gilt.
Damit meine ich vor allem die nicht gerade kleine Gruppen von Anwendern, die ihren ioBroker ausschließlich produktiv und dabei oft auf einem Pi laufen haben.
In den allermeisten Fällen ist der Desktop dabei "versehentlich" und unwissentlich aktiv.

An dieser Stelle widersprichst Du dir selber. (oder wir schreiben aneinander vorbei)

Wenn der Desktop 'versehentlich' noch aktiv ist weil den niemand ausgeschaltet hat, dann wird er gerade nicht als Arbeitssystem benutzt - sprich niemals loggt sich da regelmässig per GUI ein und nutzt den zum Browsen im Web oder um Texte zu Schreiben - , und hat neben der Ressourcenverschwendung eher ein geringes Fehlerpotential.

Gerade in diesem Fall ist es eher wenig relevant ob das System mit oder ohne Desktop läuft - und dann sind wir wieder bei den Dogmen.

Ich habe mich schon mehrfach dazu in verschiedenen Beiträgen geäussert, wo auf explizite Probleme mit bestimmten Funktionalitäten vom Ersteller zunächst einmal ein vollständiges Gerade-ziehen des Grundsystems erwartet wird, während auf die eigentliche Ursache des Fehlers nicht eingegangen wird - sprich initial hat der Fragende erst einmal viel Arbeit (bis zu kompletten Neu-Installationen) die seine Probleme dann aber nicht lösen, da die Ursache überhaupt nicht untersucht wurde. Ob das der beste weg ist bezweifle ich. Und genau in diese Schiene gehört die Aussage 'mach den Desktop weg' - prinzipiell meistens sinnvoll, aber für das aktuelle Problem trotzdem selten relevant.

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

Wer weiß was er da tut und entsprechende Rechenpower zur Verfügung hat: Nur zu.

Ich würde das eher anders ausdrücken:

Wer weiß was er da tut oder entsprechende Rechenpower zur Verfügung hat: Nur zu.

Gerade die für die Linux Neuland ist und die mit Windows > 2000 groß geworden sind ist die Kommandozeile eher ungewohnt - eine Konfiguration des Systems über 'clicki-bunti' also eher gewünscht.

A.

@bertderkleine sagte in Fortschrittsbalken mit variabler Wert-Farbe:

Hallo,
ich möchte gernen einen Fortschrittsbalken in s/w anzeigen und darauf mittig den aktuellen Wert als %-Zahl.
Mein Problem ist, dass je nachdem, wie weit der schwarze balken reicht, eine Textfarbe des Wertes in weiss oder schwarz falsch/nicht zu lesen ist, weil z.B. wenn der Balken kurz ist und in der Mitte der Wert angezeigt wird, dieser gut zu lesen ist, wenn ich schwarze Schrift wähle (da der schwarze Balken nicht drunter liegt). Falls der Balken aber 100% lang ist, gibt's schwarz auf schwarz.
Besonder tricky ist der Fall, dass der Balken genau bei 50% steht, also halb hinter dem Text des Wertes liegt.

Ideen, wie ich das lösen könnte?

die übliche Lösung ist die Schriftfarbe bei 128,128,128 zu setzen (grau) - das hat dann etwas weniger Kontrast als schwarz oder weiss, aber hinreichend das man es immer lesen kann.

A.

@el-lutschi sagte in Zigbee Koordinator wechseln:

2025-07-16 17:59:38.704 - warn: zigbee.0 (2800) Network parameters in Config : panID=6753 channel=25 extendedPanID=dededededededede                                                                                                                                                                            
2025-07-16 17:59:38.704 - warn: zigbee.0 (2800) Network parameters on Coordinator: panID=65534 channel=0 extendedPanID=dddddddddddddddd                                                                                                                                                                           
2025-07-16 17:59:38.719 - error: zigbee.0 (2800) Starting zigbee-herdsman problem : network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby

Da steht warum es nicht geht.

Du hast das Problem das du mit veralteten Standard-Einstellungen (dddddddddddddd als ExtPanId) arbeitest. Das geht schief.

Du musst die Konfguration gerade ziehen, und dann schauen ob der 'comissioning timeout' weiter kommt. Wenn ja, dann musst du die Antenne des Koordinators mit Alufolie umwickeln um den Adapter zu starten, und dann - wenn er läuft - dieses entfernen und dem Netz 24 h geben sich zu stabilisieren.

A.

@haselchen sagte in Tester Zigbee Adapter 3.x gesucht:

Alles mit jedem verbunden , ebenso mit dem Coordinator.

Jein. Die Plug 01 werden als Nachbarn von anderen Geräten mit grünen Linien verbunden, aber:

Den Plug-01 fehlt die blaue Linie. Blende mal in der ansicht der Karte die Nachbarn aus, dann siehst du nur welche 'aktiven' routen exisiteren. Dabei wird auffallen das die Plug 01 eben gerade keine Verbindung gemeldet haben.

A.

@el-lutschi Mehr details bitte:

• was kommt an Meldungen beim Start ?
• was hast du an Parametern im Zigbee Adapter eingetragen ?
• Welche Adapter-Version nutzt du ?
• Befinden sich der alte und der neue Koordinator in etwa am gleichen Platz ?

A.
Nachtrag: Ich mach diese Art von Wechsel bei der Entwicklung so ca. alle 2 Tage. Das geht wenn man es richtig macht ohne Probleme.

Nachtrag 2: Log ausgaben bitte als Text in Code Tags (mit diesem button) posten !!!

@itoss sagte in Smart-Home mit ioBroker – Zigbee, Z-Wave, DECT, Matter?:

Asgothian, vielen Dank für die ausführlichen Infos, jetzt ist einiges klarer! Die Sache mit den Subscriptions hatte ich verstanden.

MQTT ist quasi nur eine weite Möglichkeit nicht proprietäre Zigbee Geräte ohne HA, ioBroker und co steuern zu können.

Wahrscheinlich ist der Sonoff Adapter nicht mit alle ZigBee Geräte kompatibel?

Der Sonoff Adapter nutzt Zigbee nicht, auch nicht für Sonoff Geräte, sondern ausschliesslich Kommunikation über TCP/IP (meines Wissens nach entweder MQTT oder COAP)

• "Das ist zumindest bei Zigbee nicht korrekt."
• [...] ei Nutzung von MQTT zusätzlich auch noch manuelles Anlegen der zum Steuern der Zigbee-Geräte notwendigen Datenpunkte.
• [...] Zigbee Adapter (ioBroker.Zigbee) für die Umwandlung von Werte-Änderung zu Zigbee-Nachricht die gleiche Bibliothek nutzen (Zigbee-Herdsman-Converters).
• [...] bei Nutzung von MQTT zusätzlich auch noch manuelles Anlegen der zum Steuern der Zigbee-Geräte notwendigen Datenpunkte.

Ich werde dann erstmal den ZigBee Adapter nutzen, da es scheinbar nicht so große Unterschiede zu Z2M gibt. In Spezialfällen ist das vllt. relevant.

Kann der Koordinator mit 2 Adaptern (Z2M und Standard ZigBee) verbunden werden, falls ich einmal MQTT nutzen muss?

Nein. Der Koordinator muss an genau eine Steuersoftware angebunden werden. Es ist aber möglich, ein Zigbee-Netz von einem System auf das andere zu migrieren, ohne das Netz neu aufbauen zu müssen.

Wenn ein Sonoff/Tasmota Gerät nur mit dem Sonoff Adaper läuft, ein anderes nur mit dem ZigBee und ein drittes benötigt dann Z2M. Können in dem Fall verschiedene ZigBee Adapter parallel betrieben werden?

Wenn ein Gerät it Z2M funktioniert, dann lässt es sich immer auch mit dem Zigbee Adapter betreiben. Bei neuen Geräten kann dafür temporär mehraufwand entstehen, um die neusten Bibliotheken und/oder Converter zu nutzen.

Tasmota Geräte arbeiten nie mit Zigbee.
Sonoff Geräte gibt es mit WLan/Lan (TCP/IP) oder Zigbee. Da muss man wählen.

A.

@meisterq-0 Ja, die Änderung sollte da auch drin sein

@haselchen sagte in Tester Zigbee Adapter 3.x gesucht:

@asgothian

Okay. Die Meldung suggeriert aber , dass etwas nicht geklappt hat. Not Supported ist von der Aussage her ja negativ behaftet.
Weil , in der Map dann selber alles korrekt angezeigt wird.
Alle Striche grün und alle Geräte verbunden.
Da würde ich als User durch die Nachricht einfach nur (unnötig) verunsichert werden.

Das siehst du falsch. In der Map wird es gerade nicht korrekt dargestellt. Es fehlen die meisten Linien die von den Plug_01 ausgehen - in den meisten fällen scheinen diese nicht einmal mit dem Koordinator verbunden zu sein, wenn du die 'nachbarn' ausblendest.

Es geht also nicht darum das Linien nicht grün sind. Es geht darum das Linien vollständig fehlen !

A.

Nachtrag: Es wird möglicherweise eine Option geben diese Meldung zu unterdrücken, bzw. die Meldung automatisch auszublenden. Das ist aber noch nicht konkret, und wenn es kommt wird es etwas sein was der Nutzer aktiv wird einschalten müssen.

@haselchen sagte in Tester Zigbee Adapter 3.x gesucht:

Lustig, seitdem ich die Versionen hin und herswitche, kommt diese Meldung bei der Karte.
Hatte ich vorher nicht.

Diese Meldung kommt ab 2.0 wenn beim Aufbau der Karte fehler auftreten. Das ist absicht - damit die Nutzer wissen welche Randbedingungen für die Karte gelten. Das z.Bsp. deine Osram Dosen keine Routing informationen liefern, obwohl sie das eigentlich müssten.

A.

@meisterq-0 sagte in Tester Zigbee Adapter 3.x gesucht:

@asgothian said in Tester Zigbee Adapter 3.x gesucht:

@haselchen denkbar - ist halt nicht getestet kannst du da mal näher ran zoomen - was da steht, und was da so abgebildet wird ?

Hast du von meinem Post weiter oben gesehen, dass der Adapter immer beim Pairing von Unbekannten Geräten crashed?

Ja, hab ich. Kann ich aber frühestens in 6 Wochen ran gehen.

A.

@haselchen denkbar - ist halt nicht getestet kannst du da mal näher ran zoomen - was da steht, und was da so abgebildet wird ?