NEWS
Tester für Zigbee Adapter 2.0.x gesucht
-
@arteck
Okay, aber die DP in der Kachel und bei Objekten korrelieren nicht damit... -
@thomas-maul hast du die Doku dazu gelesen ?
Da steht drin wie das zusammen hängt. Auch wie aus den states die datenpunkte werden. Sobald du das Gerät als “Legacy override” eingetragen hast wird das genutzt.
Du musst jetzt “nur” noch die states so definieren (um definieren) das du auf die richtigen Meldungen reagierst.
A.
Nachtrag: es gibt “Standard” datenpunkte, die nicht Geräte spezifisch definiert sind und trotzdem immer angelegt werden: linkquality, msg_from_zigbee, “device_query”, “send_payload”. Es kann noch mehr sein - ich hab nicht alles im Kopf. -
Zu den Umbenennungen (in orange) habe ich nochmal eine Frage. Bei mir sieht es Beispielsweise so aus:
Wenn ich dich richtig verstanden habe, sollen die orangenen weg, aber die sind ja aktuell gefüllt, die "neuen" noch nicht. Kommt das erst, wenn die alten DP gelöscht sind? -
@dirkhe Die Antwort auf diese Frage ist einfach:
Die neuen Datenpunkte werden gefüllt, wenn sie benutzt werden. Bei Datenpunkten, die vom Gerät gefüllt werden, ist dazu eine Nachricht vom Gerät erforderlich. Bei Datenpunkten, die zum steuern des Gerätes gefüllt werden, ist dafür ein Eintrag eines Wertes durch den Benutzer erforderlich.Die orangenen Datenpunkte werden vom Adapter nicht aktualisiert wenn das Gerät eine Nachricht sendet, und nicht überwacht, wenn der Benutzer diese Datenpunkte ändert.
A.
-
Update: folgender Beitrag hat sich erledigt
@asgothian ja ich sehe mittlerweile schon, dass die orangenen nicht mehr aktualisiert werden, allerdings die neuen auch nicht mehr. Auch wenn ich etwas "schreiben" möchte, scheint das nicht mehr zu funktionieren. Da scheint dann die original libraray, olso die herdsmann buggy zu sein, vermute ich..zigbee.0 2025-02-28 11:21:18.327 warn ELEVATED I02: value generated '20' from device cc86ecfffec3a92f for 'Temperature setpoint' zigbee.0 2025-02-28 11:21:18.326 warn ELEVATED I01: message received '{"current_heating_setpoint":20}' from device cc86ecfffec3a92f type 'SEA801-Zigbee/SEA802-Zigbee' zigbee.0 2025-02-28 11:21:18.325 warn ELEVATED I02: value generated '91' from device cc86ecfffec3a92f for 'Link quality' zigbee.0 2025-02-28 11:21:18.325 warn ELEVATED I01: message received '{"linkquality":91}' from device cc86ecfffec3a92f type 'SEA801-Zigbee/SEA802-Zigbee' zigbee.0 2025-02-28 11:21:18.318 warn ELEVATED I00: Zigbee Event of Type commandDataReport from device "0xcc86ecfffec3a92f", incoming event: {"type":"commandDataReport","device":"0xcc86ecfffec3a92f","endpoint":1,"data":{"seq":1,"dpValues":[{"dp":103,"datatype":2,"data":{"type":"Buffer","data":[0,0,0,200]}}]},"linkquality":91,"groupID":0,"cluster":"manuSpecificTuya"} zigbee.0 2025-02-28 11:21:16.211 error ELEVATED OE2: Error convert result for current_heating_setpoint with 20 is undefined on device 0xcc86ecfffec3a92f. zigbee.0 2025-02-28 11:21:16.210 warn ELEVATED O05: convert result undefined for device 0xcc86ecfffec3a92f zigbee.0 2025-02-28 11:21:16.190 warn ELEVATED O04: convert current_heating_setpoint, 20, {} for device 0xcc86ecfffec3a92f with Endpoint current_heating_setpoint zigbee.0 2025-02-28 11:21:16.186 warn ELEVATED O04.0: Setting' converter to converter with key(s)'["current_heating_setpoint"]} zigbee.0 2025-02-28 11:21:16.182 warn ELEVATED O03: Publishing to 0xcc86ecfffec3a92f of model SEA801-Zigbee/SEA802-Zigbee zigbee.0 2025-02-28 11:21:16.180 warn ELEVATED O02: Change state 'current_heating_setpoint' at device 0xcc86ecfffec3a92f type 'SEA801-Zigbee/SEA802-Zigbee' zigbee.0 2025-02-28 11:21:16.176 warn ELEVATED O01: User state change of state zigbee.0.cc86ecfffec3a92f.current_heating_setpoint with value 20 (ack: false) from system.adapter.admin.0 zigbee.0 2025-02-28 11:20:31.972 info debug devices set to ["cc86ecfffec3a92f"]
wie man im log sieht, scheint auch der neue Endpunkt zum Setzten der Temperatur undefined zu sein? Irgendwas scheint da noch nicht zu passen.
Liegt übrigens nicht an den Geräten, weil alle das gleiche Verhalten zeigen und vor dem Upodate noch sauber funktioniert hatten
Der letzte Eintrag scheint sogar zu suggerieren, dass der adapter das bekommen hat, aber der Baum wird nicht geupdatet.
Am Thermostat ist das übrigens auch angekommenEdit Das Problem schien der Admin Adapter gewesen zu sein. Ich hatte zwar mehrfach den Datenpunkt Baum versucht zu aktualisieren, aber anscheinend ist die Verbindung abgebrochen, er hat zwar den die States neu gezeichnet, aber nicht mit den korrokten Werten. Ich hatte jetzt den Browser neu geladen und dann werden die Daten auch angezeigt.
Also sorry für die Falschmeldung -
@asgothian said in Tester für Zigbee Adapter 2.0.1 gesucht:
Du musst jetzt “nur” noch die states so definieren (um definieren) das du auf die richtigen Meldungen reagierst.
Hi,
ich muss zugeben, dass ich da jetzt aussteige.
Ich habe mir das repository forked und dann in meinen (gerade installierten) lokalen github client lokal synchronisiert.
Aber ehrlich, wer sich nicht mit git und co auskennt, ist doch verloren. Zumindest habe ich Respekt davor, irgendwas kaputt zu machen, da ich nicht mal weiß, was ich wie wo und womit bearbeiten muss.Aktuell dachte ich, "einfach" die states in das device.js mit einem Editor zu übertragen. Aber keine Ahnung, was da noch so alles rein muss, gerade wenn ich mir die Log Einträge nach den einzelnen actions anschaue.
Sorry, aber zumindest ich bin da überfordert und gebe auf
Eine letzte Frage noch: kann ich einfach die vorherige Version des Adapters installieren, oder geht das aus irgendwelchen Gründen nicht?
EDIT: bin jetzt zurück auf 1.10.14, meine Datenpunkte sind wieder im Objektbaum und funktionieren. Natürlich sind alle neuen jetzt orange und noch da
Und die Kachel zeigt die auch... Aber das ist eher kosmetischer Natur.
-
@thomas-maul sagte in Tester für Zigbee Adapter 2.0.1 gesucht:
@asgothian said in Tester für Zigbee Adapter 2.0.1 gesucht:
Du musst jetzt “nur” noch die states so definieren (um definieren) das du auf die richtigen Meldungen reagierst.
Hi,
ich muss zugeben, dass ich da jetzt aussteige.
Ich habe mir das repository forked und dann in meinen (gerade installierten) lokalen github client lokal synchronisiert.
Aber ehrlich, wer sich nicht mit git und co auskennt, ist doch verloren. Zumindest habe ich Respekt davor, irgendwas kaputt zu machen, da ich nicht mal weiß, was ich wie wo und womit bearbeiten muss.Aktuell dachte ich, "einfach" die states in das device.js mit einem Editor zu übertragen. Aber keine Ahnung, was da noch so alles rein muss, gerade wenn ich mir die Log Einträge nach den einzelnen actions anschaue.
Sorry, aber zumindest ich bin da überfordert und gebe auf
Eine letzte Frage noch: kann ich einfach die vorherige Version des Adapters installieren, oder geht das aus irgendwelchen Gründen nicht?
EDIT: bin jetzt zurück auf 1.10.14, meine Datenpunkte sind wieder im Objektbaum und funktionieren. Natürlich sind alle neuen jetzt orange und noch da
Und die Kachel zeigt die auch... Aber das ist eher kosmetischer Natur.
Initial muss man mit Github erst einmal überhaupt nichts machen. Man kann einfach direkt unter node_modules/iobroker.zigbee/lib/devices.js und node_modules/iobroker.zigbee/lib/states.js dinge Ändern. Sollte man dabei was kaputt machen kann das "einfach" durch eine reinstallation des Adapters "behoben" werden.
Trotzdem kann ich verstehen das das ganze nicht unbedingt trivial ist, und das Du da Respekt vor hast. Das führt aber dennoch nicht dazu das ich das wieder 'übernehmen' mag. Ich hab das Gerät nicht, und müsste da richtig viel Zeit rein stecken Dir die ganzen Test-Geschichten zur Verfügung zu stellen. Nicht unbedingt trivial. Du kannst ja mal in diesen Issue wie so etwas dann ablaufen müsste - da musste ich das machen da ich das Gerät nicht habe aber die Fehlfunktion auf einen Bug im Adapter zurück geht den ich loswerden will.
Die GitHub Geschichte ist am Ende, wenn man den Code entsprechend angepasst hat wichtig. So richtig 'kaputt' machen (unwiederbringlich) geht kaum.
Ansonsten kannst du natürlich auf der 1.10.14 bleiben - bist aber damit von der Unterstützung von neuen Geräten abgeschnitten. Geräte die gehen gehen weiter. Geräte die nicht gehen lassen sich auch nicht mal ebene gängig machen.
In dem Fall empfehle ich Dir die orangenen States alle zu löschen (via dem alten 'state cleanup' button). Dann sind die weg und irritieren dich nicht mehr.
A.
-
@dirkhe sagte in Tester für Zigbee Adapter 2.0.1 gesucht:
Update: folgender Beitrag hat sich erledigt
Fein.
Ich muss meinen Kommentar allerdings trotzdem noch anpassen:
@asgothian sagte in Tester für Zigbee Adapter 2.0.1 gesucht:
Die orangenen Datenpunkte werden vom Adapter nicht aktualisiert wenn das Gerät eine Nachricht sendet, und nicht überwacht, wenn der Benutzer diese Datenpunkte ändert.
Diese Aussage ist nicht unbedingt korrekt. Insbesondere kann es sein das der Adapter weiterhin auf eine State-Änderung reagiert und auch versucht diese an das Gerät zu senden. in 99% der Fälle geht das aber in die Wüste.
-
Ich habe gerade den Versionssprung gewagt, von daher auch von mir ein kurzes Feedback. Bisher läuft alles problemlos (Coordinator SMLIGHT SLZB-06M mit knapp 70 verbundenen Zigbee-Geräten). Ein paar wenige States haben sich wie beschrieben geändert, die zugehörigen Aliase waren aber fix angepasst. Ansonsten laufen alle Zigbee-Geräte wie auch zuvor schon butterweich und reagieren zügig auf Befehle.
Danke für die tolle Arbeit und Pflege des Adapters!
-
@asgothian
Hab die 2.0.1 jetzt auch schon seit 2 Tagen ein wenig testen können. Bin von der 2.0 gekommen, falls das für ein "Fehlerbild" interessant sein sollte.
Die eingefärbten States haben es einfach gemacht die Aliase anzupassen bzw. für die kleinen Tradfris (https://www.zigbee2mqtt.io/devices/E1743.html) die geänderten Datenpunkte in nem MiniSkript abzufangen. Super hilfreich!
Grundsätzlich funktionieren alle Geräte wie sie sollen (und gefühlt auch schneller). An der- Eine alte OSRAM Lampe die vor dem Update durchgehend erreichbar war steigt jetzt öfters aus. Da OSRAM eh etwas wankelmutig ist fliegt die wohl eh raus.
- Firmwareupdates gehen nicht, bzw. können nicht abgerufen werden. Bei allen Geräten die OTA-fähig sind erscheint
Failed to check if update available for '0x84b4dbfffe96xxx' device.mapped.ota.isUpdateAvailable is not a function
-
Die Trektat Steckdose (https://www.zigbee2mqtt.io/devices/E2204.html) hat kein Bild mehr. Sie wird in der Kachel als E22X4 angezeigt. Der Link führt dann auch ins Leere. (Keine Ahnung ob das am Adapter oder am Herdsmann liegt) Das passende Bild für die E2204 liegt auch im Adapterverzeichnis, aber ich kann kein Bild auswählen. Auch ein umbenanntes identisches PNG kann ich nicht auswählen. Mir wird nur das angeboten:
-
Über das GUI sind die Kacheln wie gewohnt im Raster zu sehen, in der Instanz nur in einer Reihe
-
@asgothian said in Tester für Zigbee Adapter 2.0.1 gesucht:
Trotzdem kann ich verstehen das das ganze nicht unbedingt trivial ist, und das Du da Respekt vor hast. Das führt aber dennoch nicht dazu das ich das wieder 'übernehmen' mag. Ich hab das Gerät nicht, und müsste da richtig viel Zeit rein stecken Dir die ganzen Test-Geschichten zur Verfügung zu stellen. Nicht unbedingt trivial.
Hi, passt für mich und wir können den Austausch zu meinem Schalter beenden
Ich habe insbesondere an der Stelle aufgegeben, an der ich die States in der devices.js gesehen habe und nachher keinen Plan hatte, was ich genau wie in der states.js eintragen muss. Beide haben (für mich) mit dem Log vom Adapter nichts zu schaffen, der auch unerwartete Signale sendet, weil alle Tasten zweifach belegt sind
Und später noch wie auf "meiner Version" lokal testen... und dann noch einen PR... Das allein geht ohne jegliche Vorkenntnisse kaum.
Ich erwarte hier auch keine Nachhilfe dazu und will niemanden Zeit stehlen... Von daher hast Du mein Verständnis.
Glücklicherweise sind es ja nur ein paar Schalter, die ich ggf. später rauswerfe oder wenn ich einen besseren Plan habe, dann doch "transferiere".
-
@bommel_030 sagte in Tester für Zigbee Adapter 2.0.1 gesucht:
- Eine alte OSRAM Lampe die vor dem Update durchgehend erreichbar war steigt jetzt öfters aus. Da OSRAM eh etwas wankelmutig ist fliegt die wohl eh raus.
- Firmwareupdates gehen nicht, bzw. können nicht abgerufen werden. Bei allen Geräten die OTA-fähig sind erscheint
Failed to check if update available for '0x84b4dbfffe96xxx' device.mapped.ota.isUpdateAvailable is not a function
Das muss ich mir anschauen
- Die Trektat Steckdose (https://www.zigbee2mqtt.io/devices/E2204.html) hat kein Bild mehr. Sie wird in der Kachel als E22X4 angezeigt. Der Link führt dann auch ins Leere. (Keine Ahnung ob das am Adapter oder am Herdsmann liegt) Das passende Bild für die E2204 liegt auch im Adapterverzeichnis, aber ich kann kein Bild auswählen. Auch ein umbenanntes identisches PNG kann ich nicht auswählen. Mir wird nur das angeboten:
Hier sind 3 Dinge zu beachten:
-
andere Bilder werden nur vorgeschlagen wenn du auch Bilder zur Verfügung stellst, bzw. wenn es ein gerät mit der Bezeichnung in den legacy_devices gibt. Die von Dir zur Verfügung gestellten Bilder sollten sich nicht im Adapter-Code sondern im Adapter-Datenverzeichnis (oder einem Unterverzeichnis davon) befinden. Das ist wo sich die shepherd.db befindet.
-
Die geänderte Bezeichnung wird durch den Herdsman vergeben und kommt aus den zigbee-herdsman-converters.
-
um zu erkennen was da vor sich geht musst du die info-Anzeige des Gerätes zeigen.
- Über das GUI sind die Kacheln wie gewohnt im Raster zu sehen, in der Instanz nur in einer Reihe
Das liegt daran das zur Erzeugung der Ansicht die Ansicht nicht gerendert ist. Ein verändern der Fenstergrösse aktualisiert die Ansicht. Das sie hier überhaupt sichtbar sind ist ein Zugeständnis an die Möglichkeit die Einstellungen zu prüfen - sie soll nicht genutzt werden.
A.
-
Das mit dem
Failed to check if update available for '0x804b50fffea8bebd' device.mapped.ota.isUpdateAvailable is not a function
Kann ich bestätigen. Bekomme ich bei allen Geräten.
-
@david-g sagte in Tester für Zigbee Adapter 2.0.1 gesucht:
Das mit dem
Failed to check if update available for '0x804b50fffea8bebd' device.mapped.ota.isUpdateAvailable is not a function
Kann ich bestätigen. Bekomme ich bei allen Geräten.
Ist ein Bug, es gibt bereits eine Test-Version die den gefixed hat. Kommt die Tage in die 2.0.2
A.
-
@asgothian
Hier die Infokachel:
Ok, wenn ich die Bilder zur shepherd kopiere bekomme ich sie zur Auswahl. Leider ohne Inhalt. (Upload und Adpater restart haben nichts gebracht.)
Neu pairen werd ich am WE mal versuchen.Die Instanzeinstellung soll nicht genutzt werden, sondern die GUI, werde ich mir merken.
-
@bommel_030 bist du sicher das das png Bilder sind, nicht jpg's oder was anderes ?
Wie gross sind die Bilder ?
Die Bilder für die Listen-Darstellung werden eigentlich als base64-kodierte Daten geschickt - wenn da das Format nicht stimmt gibt es salatA.
-
@asgothian
Ja, es einmal das aus dem IMG Verzeichnis des Adapters, das andere ist von der zigbee2mqtt Geräteseite. -
- Welchen Web-browser nutzt du ?
- kannst du die Seite ohne cache erzwungen neu laden ?
Bei meiner Testumgebung geht das Bild - getestet mit Firefox, Arc und Safari
A.
-
@david-g sagte in Tester für Zigbee Adapter 2.0.1 gesucht:
@bommel_030Es gibt eine Test version der 2.0.2, die ihr (wenn ihr wollt) installieren und testen könnt. Installation von GitHub aus diesem Repository:
https://github.com/asgothian/ioBroker.zigbee/tarball/1.11Installation auf eigene Gefahr. Nach installation bitte testen:
- geht das OTA ?
- funktionieren die ggf. vorhandenen Fernbedienungen / Wandschalter wie erwartet
Bei Problemen könnt ihr direkt zurück auf die 2.0.1 aus dem Latest.
In diesem Bereich hat es Anpassungen gegeben. Sofern bei den Tests keine Auffälligkeiten auftreten kommen diese Anfang kommender Woche ins Latest.
A.
-
@asgothian
Hab es mit Chrome und Edge getestet, gleiches Ergebnis. Das Bild ist auf jeden Fall ok, zumindest wird es direkt angezeigt wenn ich es über Datei-Tab vom Admin hochlade.
Die 2.0.2 werd ich erst morgen testen können.