NEWS
SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.
-
@schmetterfliege sagte in SHP-15+Zigbee Adp.: "TS011F" not described in statesMapping.:
Ich hab das allerdings auch im Homefolder ausgeführt, nicht im iob folder.
Dann gammelt das jetzt dort herum. Ich würde auch statt direkt per npm auch immer empfehlen, das so zu machen:
iobroker add zigbeeDas nimmt die Pfade gleich mit.
nimmt das mit dem Befehl dann die Version von Github (1.6.9) oder die, die im IOB gepublished ist (1.6.6)?
Zu dem Adapter der jetzt rumgammelt: Wie deinstalliere ich den denn jetzt ohne meinen eigentlichen Adapter zu deinstallieren?^^
-
nimmt das mit dem Befehl dann die Version von Github (1.6.9) oder die, die im IOB gepublished ist (1.6.6)?
Zu dem Adapter der jetzt rumgammelt: Wie deinstalliere ich den denn jetzt ohne meinen eigentlichen Adapter zu deinstallieren?^^
In der Form aus den Verwahrorten. Github muss man wieder anders installieren.
Wie deinstalliere ich den denn jetzt ohne meinen eigentlichen Adapter zu deinstallieren?
Einfach löschen.
-
In der Form aus den Verwahrorten. Github muss man wieder anders installieren.
Wie deinstalliere ich den denn jetzt ohne meinen eigentlichen Adapter zu deinstallieren?
Einfach löschen.
Einfach löschen ist gut, ich weiß ja nicht mal wo die Installation jetzt zu finden ist^^
-
Einfach löschen ist gut, ich weiß ja nicht mal wo die Installation jetzt zu finden ist^^
@schmetterfliege Bitte keine Screenshots aus der Konsole.
ls -laUnd einen Server betreibt man OHNE Desktop.
-
@schmetterfliege Bitte keine Screenshots aus der Konsole.
ls -laUnd einen Server betreibt man OHNE Desktop.
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 -
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.
329
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge