NEWS
SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.
-
Den Pi benutze ich ja nicht nur für den IOB, sondern auch als Linux Gerät falls ich es denn mal brauchen sollte.
Schaden dürfte der Desktop ja hoffentlich nicht, oder?Soll ich die Ausgabe dann so machen?
pi@raspberrypi:~ $ ls -la total 916 drwxr-xr-x 21 pi pi 4096 Dec 15 19:37 . drwxr-xr-x 4 root root 4096 Dec 1 2020 .. -rw------- 1 pi pi 4607 Dec 15 19:47 .bash_history -rw-r--r-- 1 pi pi 220 Aug 20 2020 .bash_logout -rw-r--r-- 1 pi pi 3716 Dec 15 19:16 .bashrc drwxr-xr-x 2 pi pi 4096 Aug 20 2020 Bookshelf drwxr-xr-x 6 pi pi 4096 Dec 1 2020 .cache drwx------ 7 pi pi 4096 Jan 20 2021 .config drwxr-xr-x 2 pi pi 4096 Dec 1 2020 Desktop -rw-r--r-- 1 pi pi 35 Dec 1 2020 .dmrc drwxr-xr-x 2 pi pi 4096 Dec 1 2020 Documents drwxr-xr-x 2 pi pi 4096 Dec 1 2020 Downloads drwx------ 3 pi pi 4096 Aug 20 2020 .gnupg drwxr-xr-x 2 pi pi 4096 Aug 8 15:02 .iobroker drwxr-xr-x 3 pi pi 4096 Aug 20 2020 .local drwxr-xr-x 2 pi pi 4096 Dec 1 2020 Music drwxr-xr-x 77 pi pi 4096 Dec 15 19:37 node_modules drwxr-xr-x 5 pi pi 4096 Dec 15 19:37 .npm -rw------- 1 pi pi 36 Dec 1 2020 .npmrc -rw-r--r-- 1 pi pi 808689 Dec 15 19:37 package-lock.json drwxr-xr-x 2 pi pi 4096 Dec 1 2020 Pictures drwx------ 3 pi pi 4096 Dec 1 2020 .pp_backup -rw-r--r-- 1 pi pi 807 Aug 20 2020 .profile drwxr-xr-x 2 pi pi 4096 Dec 1 2020 Public drwxr-xr-x 2 pi pi 4096 Dec 1 2020 Templates drwxr-xr-x 8 pi pi 4096 Dec 30 2020 tuya-convert drwxr-xr-x 2 pi pi 4096 Dec 1 2020 Videos drwx------ 3 pi pi 4096 Dec 1 2020 .vnc -rw------- 1 pi pi 161 Jan 20 2021 .Xauthority -rw------- 1 pi pi 2425 Jan 20 2021 .xsession-errors -rw------- 1 pi pi 2425 Jan 18 2021 .xsession-errors.old@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
Schaden dürfte der Desktop ja hoffentlich nicht, oder?
Klar. Frisst Ressourcen und erhöht die Chance auf Abstürze und Sicherheitslöcher. Mehr laufender Code = Mehr Fehler.
Lösch die node_modules und die package-lock.json
rm -rf node_modules rm package-lock.json -
@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
Schaden dürfte der Desktop ja hoffentlich nicht, oder?
Klar. Frisst Ressourcen und erhöht die Chance auf Abstürze und Sicherheitslöcher. Mehr laufender Code = Mehr Fehler.
Lösch die node_modules und die package-lock.json
rm -rf node_modules rm package-lock.json@thomas-braun said in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
Schaden dürfte der Desktop ja hoffentlich nicht, oder?
Klar. Frisst Ressourcen und erhöht die Chance auf Abstürze und Sicherheitslöcher. Mehr laufender Code = Mehr Fehler.
Ressourcenmäßig hab ich da jetzt noch nichts bemerkt, Abstürze hatte ich bisher deshalb auch noch nicht.
Aber klar, mehr Code = größeres Risiko. Ich deinstalliere den bei Gelegenheit mal.Lösch die node_modules und die package-lock.json
rm -rf node_modules rm package-lock.jsonVielen Dank!
Ich muss mir echt mal die Zeit nehmen und mich anständig mit meinem System auseinandersetzen um diese ganzen Unsicherheiten loszuwerden... Den node_modules Folder hatte ich schon gefunden, war mir aber nicht sicher ob das jetzt nur der "ungewollte" zigbee adapter ist, oder ob das von IOB angelegt wurde und ich da jetzt alles kaputt mache^^ -
@thomas-braun said in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
Schaden dürfte der Desktop ja hoffentlich nicht, oder?
Klar. Frisst Ressourcen und erhöht die Chance auf Abstürze und Sicherheitslöcher. Mehr laufender Code = Mehr Fehler.
Ressourcenmäßig hab ich da jetzt noch nichts bemerkt, Abstürze hatte ich bisher deshalb auch noch nicht.
Aber klar, mehr Code = größeres Risiko. Ich deinstalliere den bei Gelegenheit mal.Lösch die node_modules und die package-lock.json
rm -rf node_modules rm package-lock.jsonVielen Dank!
Ich muss mir echt mal die Zeit nehmen und mich anständig mit meinem System auseinandersetzen um diese ganzen Unsicherheiten loszuwerden... Den node_modules Folder hatte ich schon gefunden, war mir aber nicht sicher ob das jetzt nur der "ungewollte" zigbee adapter ist, oder ob das von IOB angelegt wurde und ich da jetzt alles kaputt mache^^@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
oder ob das von IOB angelegt wurde und ich da jetzt alles kaputt mache^^
Der iobroker kann und darf nicht in anderen Verzeichnissen schreiben. Daher muss das dein eigenes Fabrikat sein.
Siehe:
echad@chet:~ $ sudo -u iobroker touch testdatei_als_iobroker touch: cannot touch 'testdatei_als_iobroker': Permission denied -
Update: hab den Adapter jetzt erfolgreich auf 1.6.9 geupdated, aber das selbe Problem nach neu pairen:
@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
Update: hab den Adapter jetzt erfolgreich auf 1.6.9 geupdated, aber das selbe Problem nach neu pairen:
Siehe Kommentar auf GitHub.
A.
-
Hab ich gesehen, vielen Dank für's rausfinden! :)
Sollte ich hierfür einen neuen eigenen Issue machen? -
Kurzes Update:
Nachdem @Asgothian sich die pull requests vom herdsman angeschaut hat, sollte eigentlich seit gestern Abend dieses Device supportet sein.
Was ich gemacht habe: per "Katze" -> "von Github" -> Zigbee ausgewählt und installiert.
Das hat meinen Zigbee Adapter auch geupdated, zumindest wurden einzelne Pakete geupdated.
Anschließend habe ich die beiden "falschen" Plugs gelöscht (force) und einen State cleanup gemacht.
Dann den Adapter neu gestartet und versucht die Plugs nochmal zu pairen.
Leider mit dem selben Ergebnis.Zigbee zu deinstallieren und "von scratch" neu zu installieren habe ich jetzt noch nicht versucht, da ich nicht weiß ob das notwendig ist (würde gerne die 33 Devices die funktionieren nicht alle nochmal anlernen müssen^^).
Für weiteren Input bin ich offen!
-
Update2:
In den herdsman-converters unter tuya.js finde ich aber auch den Converter für genau mein Device (würde ich zumindest anhand der Vendor ID behaupten?)
-
Hab mal noch ein bisschen tiefer gebuddelt...
Unter "/opt/iobroker/node_modules/zigbee-herdsman-converters/devices" gibt es die tuya.js.
Dort fehlt bei mir der entsprechende Fingerprint:fingerprint: [ {modelID: 'TS011F', manufacturerName: '_TZ3000_5f43h46b'}, {modelID: 'TS011F', manufacturerName: '_TZ3000_cphmq0q7'}, {modelID: 'TS011F', manufacturerName: '_TZ3000_dpo1ysak'}, {modelID: 'TS011F', manufacturerName: '_TZ3000_ew3ldmgx'}, {modelID: 'TS011F', manufacturerName: '_TZ3000_jvzvulen'}, {modelID: 'TS011F', manufacturerName: '_TZ3000_mraovvmm'}, {modelID: 'TS011F', manufacturerName: '_TZ3000_nfnmi125'}, {modelID: 'TS011F', manufacturerName: '_TZ3000_ps3dmato'}, {modelID: 'TS011F', manufacturerName: '_TZ3000_w0qqde0g'}, ],Bei mir fehlt der entsprechende Eintrag: {modelID: 'TS011F', manufacturerName: '_TZ3000_u5u4cakc'}
Bedeutet für mich dass ich nicht die aktuellste Version dieser Datei habe.
Abgesehen davon ist der Converter aber exakt gleich, also müsste es theoretisch doch erstmal reichen da den Fingerprint hinzuzufügen.
Frage 1: kann ich das ohne Risiko? Die Datei ist schreibgeschützt, aber mit sudo könnte ich reinschreiben.Frage 2: im Netz habe ich gelesen dass die neueste FW dieser Plugs sie zu reinen Polling Devices macht.
Auch im Commit auf Github, in dem der Fingerprint hinzugefügt wurde, steht der Kommentar dass diese Version polling benötigt. Also gehe ich mal stark davon aus dass meine Plugs mit genau dieser FW ausgeliefert wurden und deshalb auch diesen Fingerprint haben.
Mir ist klar, was Polling generell ist. Aber nur zur Sicherheit für mich:
Bedeutet dass, dass die Plugs mir keine Werte liefern, außer ich polle die immer und immer wieder aktiv?
Bei 10 Stück dürfte das doch ziemlich uncool für meinen Pi sein, oder? -
@alexzi habe glaube ich die Lösung, siehe meinen Kommentar direkt darüber.
Frage 1 habe ich mir selbst beantwortet:
Bleibt Frage 2... wie polle ich das nun?^^
EDIT: Schalten funktioniert. Nur Werte werden tatsächlich nicht geliefert.
-
@alexzi habe glaube ich die Lösung, siehe meinen Kommentar direkt darüber.
Frage 1 habe ich mir selbst beantwortet:
Bleibt Frage 2... wie polle ich das nun?^^
EDIT: Schalten funktioniert. Nur Werte werden tatsächlich nicht geliefert.
@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
EDIT: Schalten funktioniert. Nur Werte werden tatsächlich nicht geliefert.
- Im Objektbaum den State
zigbee.0.info.debugmessagesfinden 84ba20fffe77b200eintragen.- Adapter nicht neu starten
- den State
zigbee.0.84ba20fffe77b200.device_queryfinden und mit "true" oder über den ggf. dargestellten Button triggern. - 90 Sekunden warten
- im Log nach Meldungen mit dem Schlu2sselwort "ELEVATED" schauen ob da Meldungen kommen die Load power, Load voltage oder andere fehlende Informationen beinhalten.
A.
- Im Objektbaum den State
-
@alexzi habe glaube ich die Lösung, siehe meinen Kommentar direkt darüber.
Frage 1 habe ich mir selbst beantwortet:
Bleibt Frage 2... wie polle ich das nun?^^
EDIT: Schalten funktioniert. Nur Werte werden tatsächlich nicht geliefert.
@schmetterfliege
danke schon mal soweit. Was genau hast du jetzt gemacht? den Fingerprint in der tuya.js ergänzt? -
Vielen Dank, werde das in Kürze mal machen! :)
@alexzi ich werde dir in Kürze eine etwas detailliertere "Anleitung" basteln. Aber im Prinzip habe ich nur im Converter (in
tuya.js) den Fingerprint hinzugefügt, ja :) -
Also,
die Debug Messages habe ich ausgeben lassen, die fehlenden Werte finde ich da allerdings nicht.
@Asgothian
Im Herdsman-converters Github sind einige Issues diesbezüglich offen, und da hat jemand einen Converter gebastelt der die Devices dann auch alle 60 sec pollt.
Ich verlinke das mal hier: LINK
Ich habe mir das mal angeschaut, und zumindest alle libraries existieren auf meinem Pi.
Mal unabhängig von den Versionen - kann ich einfach aus meiner Tuya.js den Fingerprint wieder löschen, und stattdessen dieses File auch im selben Ordner ablegen - und er würde dann beim pairen das Gerät finden und alle 60 Sekunden pollen?
Oder kann ich ggfs in Tuya.js einfach einen neuen Converter machen und das von dem User copy-pasten?@alexzi
Zunächst solltest du prüfen, ob dein converter genau so aussieht wie er sollte.
Dazu auf dem Pi (oder was du benutzt) unter /opt/iobroker/node_modules/zigbee-herdsman-converters/devices zb. mit "nano" die Datei Tuya.js öffnen. Dort dann nach "BW-SHP15" suchen, um zu dem entsprechenden Converter zu kommen.
Oben sind die Fingerprints, darunter dann was der Converter macht. Der relevante Teil in der Tuya.js sieht dann so aus:
Bei mir ist der Fingerprint mit{modelID: 'TS011F', manufacturerName: '_TZ3000_u5u4cakc'},bereits nachgetragen, bei dir wird er fehlen. Sollte alles unter dem Fingerprint genau so aussehen wie in meinem Auszug, kannst du einfach den Fingerprint hinzufügen und solltest dann in der Lage sein den Plug erfolgreich zu pairen. Eben aktuell noch mit der Einschränkung, dass:
- keine Werte zurückgeliefert werden (Voltage, Power, etc.)
- schalten am Plug selbst wird nicht im IoBroker reflektiert.
d.h.: wenn du den Knopf am Plug drückst, bekommt das der IoBroker nicht mit. Umgekehrt klappt es aber, also über IoBroker schalten funktioniert tadellos.
-
Fun fact:
Vor ~ 22 Stunden gabs einen Commit im Herdsman-converters (Tuya.js) der den Fingerprint zum plug_3 hinzufügt (der Converter hat polling schon mit drin).
Da hab ich spaßeshalber mal den Fingerprint bei mir ebenfalls hinzugefügt und den Plug neu konfiguriert.EDIT: ich hatte nur den Fingerprint hinzugefügt, nicht aber den Converter gecheckt. Da sind inzwischen auch einige Zeilen anders, die ich jetzt ebenfalls übernommen, und dann das ganze nochmal getestet habe.
Als TS011F_plug_3 funktioniert es jetzt insoweit, dass mein Zigbee Adapter nicht mehr crasht und ich die Dose weiterhin korrekt schalten kann. Nur das polling scheint nix zu tun - jedenfalls bekomme ich keine Werte.
Allerdings weiß ich natürlich nicht, ob das Polling so im Zigbee Adapter überhaupt unterstützt wird!
Falls die Werte jetzt gepollt werden, kommen sie jedenfalls nicht im Zigbee Adapter an.Also noch ist alles eher suboptimal^^
-
das ding sollte gehen hab gerde zur sicherheit nochmal den Converter hochgezogen auf GIT also alle mal JETZT installieren.
onb die Probleme mit der Frimware des sticks zusammenhängen falls dieser nicht erkannt wurde.. dazu kann ich nix sagen .. hab die Dose nicht hier.
-
Fun fact:
Vor ~ 22 Stunden gabs einen Commit im Herdsman-converters (Tuya.js) der den Fingerprint zum plug_3 hinzufügt (der Converter hat polling schon mit drin).
Da hab ich spaßeshalber mal den Fingerprint bei mir ebenfalls hinzugefügt und den Plug neu konfiguriert.EDIT: ich hatte nur den Fingerprint hinzugefügt, nicht aber den Converter gecheckt. Da sind inzwischen auch einige Zeilen anders, die ich jetzt ebenfalls übernommen, und dann das ganze nochmal getestet habe.
Als TS011F_plug_3 funktioniert es jetzt insoweit, dass mein Zigbee Adapter nicht mehr crasht und ich die Dose weiterhin korrekt schalten kann. Nur das polling scheint nix zu tun - jedenfalls bekomme ich keine Werte.
Allerdings weiß ich natürlich nicht, ob das Polling so im Zigbee Adapter überhaupt unterstützt wird!
Falls die Werte jetzt gepollt werden, kommen sie jedenfalls nicht im Zigbee Adapter an.Also noch ist alles eher suboptimal^^
@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
Allerdings weiß ich natürlich nicht, ob das Polling so im Zigbee Adapter überhaupt unterstützt wird!
wenn du daten haben willst musst du diese selbst abholen. per blockly oder script..
den device_query button triggern
-
Spoiler: der letzte Edit ganz unten ist der relevanteste.
@arteck
Vielen Dank für deine Rückmeldung und deine Mühe!
Ich habe über GIT geupdatet (Adapter -> Expertenmodus -> Katze -> von Git -> Zigbee Adapter ausgewählt).
Dann das Device gelöscht (erst Objektbaum, dann im Zigbee Adapter) und neu angelernt.
Er wurde auch als plug_3 erkannt und hinzugefügt, allerdings kann ich ihn nicht steuern.Also im Adapter on/off triggern hat keine Auswirkung. Ebenso nicht wenn ich im Objektbaum den Wert auf true/false setze.
Da sieht er übrigens so aus:
Also es wird quasi gar nichts erkannt.Frage aller Fragen: Wenn ich den Adapter so wie oben beschrieben installiere (was ja dann "nur" ein Update ist), sollte ich davon ausgehen dass meine Files dann alle exakt so sind wie in der aktuellsten Github Version? Oder wären Änderungen die ich vorher manuell gemacht hab (zb Fingerprint hinzufügen) immer noch vorhanden? Falls ja, könnte das ja mein Problem sein :(
Edit: theoretisch updatet das ja "nur" den Zigbee Adapter, und nicht das was ich von herdsman-converter habe.
Oder updatet das dann auch alles was ich unter zigbee-herdsman-converter habe?96 -rw-r--r--+ 1 iobroker iobroker 95465 Oct 26 1985 tuya.jsZumindest diesem ls Eintrag nach wurde die Datei das letzte mal am 26. Oktober modifiziert, oder?
Ich selbst habe die Datei doch heute Mittag schon mal modifiziert, hätte das nicht dieses Datum auf den 18. Dezember setzen müssen?Edit2:
"_from": "zigbee-herdsman-converters@14.0.347", "_id": "zigbee-herdsman-converters@14.0.347",Laut package.json im herdsman-converter Folder hat es zumindest die gleiche Version wie im Zigbee Adapter aufgeführt.
= Alle Dateien dürften dann auch exakt so sein wie in der aktuellen Adapter Version erwartet und meine Änderungen von heute Mittag dürften weg sein?Edit3:
Ich hab mal einen zweiten Plug hinzugefügt. Den kann ich auch wieder schalten.
Wenn ich allerdings versuche den ersten zu schalten, crasht der Zigbee Adapter instant.
Ich hab mal das Debugging für den zweiten Plug (der den Adapter nicht abschießt) eingeschaltet und Device-Query getriggert, das hier ist der Output:
EditDrölfzig:
Hab den ersten Plug, der den Adapter crasht wenn ich ihn schalten will, nochmal gelöscht während er am Strom hängt und dann neu hinzugefügt. Auch den kann ich jetzt wieder über den Adapter schalten und es crasht (zumindest jetzt gerade) nicht mehr den Adapter.
Aber auch bei dem keine Werte wenn ich Device-Query trigger und in der Debug Ausgabe sehe ich auch keinerlei Eintrag zu Watt, Voltage etc. Nur Link Quality und State.
ABER: (EditUnendlich) wenn ich den Plug an seinem Knöpfchen ein/ausschalte und dann Device_Query trigger, dann wird der State tatsächlich im Adapter geupdated. Polling funktioniert also schonmal, aber eben nur für den State, nicht für die anderen Values. -
@Schmetterfliege
erst mal Danke für die vielen Test und Info. Bin trotzdem zu blöd die tuya.js zu aktualisieren, zumindest nicht über die Katze oder sonst wie. Manuell möchte ich eigentlich nicht drin rumfrickeln. Kannst du mir evtl. kurz schreiben wie ich die neue Datei bzw. Dateien bekomme? Merci -
Ich habe tatsächlich einfach nur über die Katze den Zigbee Adapter ausgewählt und dann von Github geupdated.
Alle manuellen Änderungen die ich gemacht habe waren weg, und die verschiedenen Versionen von dependencies waren auch so wie im Repository angegeben. Das Update hat also auch auf jeden Fall geklappt.
An welcher Stelle hängt es denn bei dir?
Hast du über die Katze geupdated und die Devices werden immer noch nicht erkannt?
Falls dem so ist, schaue doch mal in die tuya.js und Kopiere die beiden entsprechenden converter raus (plug_1 und plug_3), damit ich das mal vergleichen kann mit dem was ich habe.Übrigens: Ich stehe in Kontakt mit Tuya und kenne nun zumindest den Grund wieso das Polling nicht geht etc.
Mal schauen ob die ihre Änderungen wieder rückgängig machen - ansonsten gehen die Plugs sofort zurück nach China...
-
Das Problem konnte nun weitestgehend gelöst werden, siehe:
https://github.com/Koenkk/zigbee2mqtt/issues/9057Wäre es möglich diese Änderungen im Zigbee Adapter zu übernehmen?
524
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge