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.

@accu sagte in Shelly lässt sich nicht mehr Schalten:

ich bin am Verzweifeln. Ich habe irgendwas an meinem Shelly verstellt so dass er sich nicht mehr via ioBroker bzw. Blockly schalten lässt. Der Knopf vom Relay (Switch Datenpunkt) ist plötzlich rot und funktioniert nicht mehr.

Du musst da systematisch vorgehen:

• Kennst du die IP vom Shelly ?
  -- Wenn ja, kannst du den per web-Interface schalten ?
  -- Wenn nein: Finde sie heraus.
• Ist der Shelly als verbunden angezeigt ?
• Mit welchem Adapter gehst Du da ran ?
• Hat er überhaupt Strom ?
• Wie ist er eingebunden ? COAP / MQTT ?
• Hat er die korrekten Zugangsdaten zum ioBroker ?
• Gibt es Log-Einträge (Warnungen / Fehlermeldungen) zu diesem Gerät ?

Und

So

Weiter.

Ansonsten hilft auch wenn du verrätst was du genau am Shelly gemacht hast.

A.

@fernetmenta sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@geesthachter Passiert das auch, wenn du im z2m Adapter den Dummy mqtt Server verwendest, statt mqtt als eigenen Adapter? Ich glaube mich zu erinnern, dass ein Bekannter von mir das gleiche Problem hatte. Eventuall wird da von mehreren Seiten eingewirkt.

guter Hinweis.

Dazu noch testen: Tritt der Effekt wirklich nur bei einem Reboot auf, oder reicht es z2m und ioBroker neu zu starten damit der Effekt auftritt ?

A.

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

nein es sind nicht immer die gleichen Geräte

Wenn es unterschiedliche Geräte sind kann einzig eine Race-Kondition dazu führen das da irgendwas passiert. Wie oben schon geschrieben halte ich es für ausgeschlossen das der Neustart des PI zufällige 2.4 GHz Signale aussendet die von den Geräten als Schaltimpulse verstanden werden.

Was du versuchen kannst, wenn du unbedingt auf dem Reboot bestehst (den ich für unsinnig halte - mein PI5 mit Zigbee hat aktuell eine Uptime von 280 Tagen)

• 75 s vor dem Reboot: MQTT Server anhalten, MQTT Server
• 60 s vor dem Reboot: Zigbee2mqtt anhalten,
• Reboot auslösen

A.

@fpvzaphod sagte in Sonoff Zigbee Brige Pro - Verzweiflung...:

"auf der Bridge laufendem MQTT-Server"

Nein, das war ein Typo: "auf der Bridge laufendem MQTT client"

Ist oben auch behoben.

@fpvzaphod sagte in Sonoff Zigbee Brige Pro - Verzweiflung...:

Wie wäre das eigentlich, wenn ich das so einrichte, und später den Ethernet-Adaper rüberschicke. Wenn im Adapter die PAN gleich bleibt, müssten die Bindung der Sensoren beim Wechsel der Zigbee-Bridge erhalten bleiben?

Da du einen TI basierten Koordinator hast - ja.

Bei einem Umzug von Koordinator mit Chipsatz A zu einem mit Chipsatz B geht das so nicht. (TI-> EZSP oder umgekehrt, oder Conbee -> irgendwas nicht Conbee)

@teletapi sagte in RPI2 Adapter kann nicht installiert werden:

aber der Adaper bricht mit Fehlern ab und sagt "Kann nicht installiert werden."

Vielleicht postest Du mal das Log wo drin steht warum er abbricht ?

A.
p.s. Bitte als Text, in Code tags, nicht als Screenshot.

@crunchip sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Z2m, Stick per LAN. Wenn Verbindung gestört, sprich keine Verbindung zum coordinator, dann geht bei mir ne Osram Birne im WC und ne Innr im Dachboden an.

• welchen Stick ?
• immer die gleichen Geräte ?

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@asgothian sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Sicherstellen das der PI5 nicht im WiFi Aktiv ist (per dtoverlay abschalten)

Ich habe den Raspi 5 tatsächlich per WLA mit meinem Router verbunden.
kann das die Ursache für den Fehler sein?

eher nicht, ist aber systematisch schlecht und sollte vermieden werden.

A.

@fpvzaphod sagte in Sonoff Zigbee Brige Pro - Verzweiflung...:

Okay, ich habe die letzten 3 Tage stundenlang damit verbracht, all das auszuprobieren. Genau so. Jetzt wollte ich heute dafür mal Hilfe suchen, und hab alles nochmal nachgespielt und Screenshots gemacht, um das Scheitern zu dokumentieren. Da es jetzt mehr oder weniger durch Zufall EINE Variante geht, hab ich beschlossen, das ganze doch zu posten. Vielleicht hat jemand die Zeit, mal zu erklären, ob die Gedankengänge soweit richtig waren. Ob diese Variante okay ist und stabil laufen sollte. Warum Ti-ZStack, obwohl eigentlich kein Tutorial dies erwähnt, sondern immer nur EZSP oder EMBER. Ob es damit zusammenhängen könnte, dass ich zum Schluss anstelle des bei Tasmota mitgelieferten SonoffZBPro_coord_20220219.hex versuchsweise die 20240710.hex geflasht habe. Ob zigbee2mqtt vielleicht Vorteile hat, oder ob die Nachteile (funktioniert jede Hardware?) überwiegen?
Ich mag solche Glückstreffer nicht sonderlich, speziell wenn sie 11.000km entfernt laufen sollen. Weil genauso wie man es durch Glück zum laufen bekommt, kann man es durch Glück wieder zerlegen. Ist die Sonoff-Bridge der richtige Weg, oder sollte man besser ein paar Taler in die Hand nehmen, und eine SLZB-06 kaufen? Per POE am Unifi-Switch betrieben, könnte ich die dann auch aus der Ferne kurz stromlos machen, wenn was klemmt. Okay, der Sonoff-Bridge einen Shelly zu spendieren, wäre auch nicht der Aufwand.
Danke für die Geduld, und sorry für das längliche Frustposting.

Zerlegen wir das ganze mal systematisch:

Sonoff hat mehrere zigbee Bridges heraus gebracht. Mehrere davon als Zigbee-Bridge Pro. Die die du gekauft hast (Zigbee-Bridge Pro P) nutzt einen TI Chipsatz, während ältere Zigbee-Bridges den EZSP Chipsatz nutzen.

Daher ist es korrekt das in der von Dir gewählten Variante (Bridge ist 'dumm', Geräte werden via externer Software angelernt) Du auch mit dem entsprechenden Adapter (TI, nicht Ember/EZSP) arbeiten musst.

Generell rare ich eigentlich immer davon ab direkt mit einem auf der Bridge laufenden MQTT Server Client zu arbeiten. In diesem Fall bist du darauf angewiesen das die Firmware der Bridge alle Deine Zigbee-Geräte erkennt und unterstützt - viel Glück damit. Besser ist die jetzt bei Dir laufende Variante wo die Bridge selber 'dumm' ist, und letztendlich nur eine Umsetzung Wifi - Seriell macht, damit der verbaute Zigbee-Chip mit deinem Rechner kommunizieren kann.

Zum Thema SLZB06 oder ähnliches - ich persönlich ziehe diese Variante vor, da sie nicht via WLan kommuniziert, und es damit keine Kollision im 2.4 GHz Funknetz gibt (die Sonoff Bridge macht nur 2.4 GHz WLan, und erzeugt damit direkt am Koordinator Signale die je nach Kanalwahl das Zigbee Netz stören können. Ansonsten sollte das was Du jetzt hast durchaus laufen.

A.
Fehlerbehebung - MQTT Client auf Sonoff gibts, nicht MQTT Server

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@codierknecht sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Tatsächlich nicht? Bei jedem reboot werden auch die Scripte neu gestartet und somit sämtliche Variablen resettet.

die Lampe gehen so früh an, das ich annehme das zu dem Zeitpunkt noch gar kein Script gestartet ist. Vielleicht noch nicht einmal die Adapter, ich vermute das sa irgendwelche Signale beim hochfahren des Raspi 5 dazu führen das die Lampen angehen. Wie schon geschrieben die Datenpunkte bleiben ja auf false aber die Lampen sind an.
eine KI die ich danach befragte schrieb das es mit der Geschwindigkeit des Raspi 5 zu tun hat.

Da ich keine Ahnung davon habe ob das sein kann, frage ich hier halt mal im Forum nach.

Das beweist mal wieder das die KI absoluten Schwachsinn schreiben kann. Es ist eher ausgeschlossen das durch 'zufällige' Effekte genau die Byte-Abfolgen im 2.4 GHz Netz gesendet werden das dadurch Geräte schalten. Es muss also andere Effekte geben.

Dinge die du tun kannst:

• wie @arteck schrieb: auf den regelmässigen Neustart verzichten. Das System ist dafür gemacht durch zu laufen.
• Sicherstellen das der PI5 nicht im WiFi Aktiv ist (per dtoverlay abschalten)
• Sicherstellen das der PI5 nicht via BT aktiv ist (per dtoverlay abschalten)
• LAN-Koordinator für Zigbee nutzen, damit dieser keinen 'power-cycle' parallel zum PI5 macht.

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Könnte das Problem mit der neuen Hardware (Pi 5 vs. Pi 4) zusammenhängen?

Eher nein.

Liegt es möglicherweise an der Umstellung von Zigbee/Sonoff auf MQTT/zigbee2mqtt?

Eher ja.

Gibt es bekannte Timing-Probleme beim Startup dieser Adapter?

Meines Wissens nach nein.

Wie kann ich verhindern, dass während des Boots ungewollte Signale an die Zigbee-Geräte gesendet werden?

Das musst du nicht - während des Boot-Vorgangs werden keine Zigbee Signale ausgesandt. Die werden erst gesandt wenn z2m startet.

A.

@feinfinger poste auch auch den Wert des DP Malala text - nicht als Screenshot - dann kann das auch wer lesen.

A.