NEWS
Tester für Zigbee Adapter 2.0.x gesucht
-
Danke, ok, kein Problem, dann fang ich das, wo es nervt, in den Scripten ab, ist ja gleich eingebaut.
-
Ich habe es auch gewagt.
Hat (fast) alles geklappt
Nur zwei Dinge:
- die Netzwerkkarte baut sich nicht auf, oder wie lange dauert das erwartungsgemäß?
- ein Schalter (LEDvance Smart+ Schalter) wird als solcher erkannt, mit dem korrekten Bild, nur die Datenpunkte haben eine Bezeichnung, die von einer Lampe stammt... Tasten funktionieren (Pfeil hoch/runter, Circle, jeweils short und long... ) nur das nutzt nix, wenn die Datenpunkte schräg bezeichnet sind. Kann ich das selbst irgendwo einstellen?
-
@thomas-maul sagte in Tester für Zigbee Adapter 2.0.1 gesucht:
Ich habe es auch gewagt.
Hat (fast) alles geklappt
Nur zwei Dinge:
- die Netzwerkkarte baut sich nicht auf, oder wie lange dauert das erwartungsgemäß?
Hast du den Aufbau der Karte angestossen ? Steht im Post oben explizit beschrieben was sich da getan hat.
- ein Schalter (LEDvance Smart+ Schalter) wird als solcher erkannt, mit dem korrekten Bild, nur die Datenpunkte haben eine Bezeichnung, die von einer Lampe stammt... Tasten funktionieren (Pfeil hoch/runter, Circle, jeweils short und long... ) nur das nutzt nix, wenn die Datenpunkte schräg bezeichnet sind. Kann ich das selbst irgendwo einstellen?
Jein. Die Umbenennung ist durch die Anpassung an den Zigbee-Herdsman-Converters gekommen. Auch da habe ich oben drauf hingewiesen.
Du kannst versuchen den Osram über die Legacy-Overrides auf die alten Datenpunkte umstellen - ich gehe aber davon aus das da die alten Datenpunkte nicht aktualisiert werden. Die dazu notwendigen Anpassungen im Adapter an 'devices.js' und 'states.js' müsstest Du dann selber machen und per PR der Allgemeinheit zur Verfügung zu stellen. Wir Entwickler können das nicht leisten - aus Zeitgründen und weil wir die Geräte nicht haben.A.
-
@asgothian said in Tester für Zigbee Adapter 2.0.1 gesucht:
Hast du den Aufbau der Karte angestossen ? Steht im Post oben explizit beschrieben was sich da getan hat.
Sorry, wer lesen kann... Klappt jetzt natürlich, danke!
Die dazu notwendigen Anpassungen im Adapter an 'devices.js' und 'states.js' müsstest Du dann selber machen und per PR der Allgemeinheit zur Verfügung zu stellen.
Okay, daran liegt es. Ich würde das versuchen, bin nur etwas überfordert, was ich wo im Adapter anpassen muss. Wenn ich das Gerät mit den LOCAL OVERRIDES inkludiere, stehen da schon mal andere Datenpunkte, allerdings gibt's (noch) keine Aktion, beim Betätigen.
Oder muss ich direkt an die zwei Dateien ran?
Und was meinst Du mit "per PR zur Verfügung stellen"? Das würde ich bei Erfolg natürlich machen.Tut mir leid, stecke nur nicht so tief im Entwickler Slang... Deshalb danke für die Geduld.
-
@thomas-maul sagte in Tester für Zigbee Adapter 2.0.1 gesucht:
Oder muss ich direkt an die zwei Dateien ran?
Und was meinst Du mit "per PR zur Verfügung stellen"? Das würde ich bei Erfolg natürlich machen.
Tut mir leid, stecke nur nicht so tief im Entwickler Slang... Deshalb danke für die Geduld.Du musst folgendes Tun (mindestens) :
- Identifizieren welche Nachrichten das Gerät sendet wenn Du die einzelnen Funktionen auslöst. (siehe hier)
- Den Adapter nach dieser Dokumentation patchen.
Wenn du das soweit alles fertig gemacht hast, dann solltest du:
- einen Account auf GitHub machen
- den Adapter auf GitHub forken
- deine Anpassungen auf deinem Fork des Adapters einspielen
- das nochmal testen (via Installation von Github aus deinem repositiory)
- wenn es läuft: einen Pull-Request zum haupt-Adapter machen. Den können wir dann freigeben und deine Anpassung wird Teil des Adapters.
Ohne diese Schritte werden alle deine Änderung nach der nächsten Aktualisierung des Adapters weg sein.
A.
-
@asgothian Moin, das wird ja mal ein spannendes Unterfangen... Ich versuche mich mal in den kommenden Tagen da heranzutasten
-
{ models: ['AC0251100NJ/AC0251600NJ/AC0251700NJ'], icon: 'img/lightify-switch.png', states: [states.switch_state, states.switch_circle, states.switch_hold, states.switch_release, states.battery], },
es ist schon alles da
-
@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.