NEWS
Zigbee-Adapter 1.0.2 Danalock
-
@jan1 Unlackiert ist mal was neues. ;)
Und nein, das kann ich aktuell nicht ohne weiteres umstellen. Der Test den ich oben beschrieben habe ist wichtig, da wir den Zigbee Adapter schritt für schritt auf eine neue Methode der State-Erstellung umstellen wollen. Ich möchte lieber diese Methode vollständig nutzbar machen als eine weitere von uns zu behandelnde Sonderlocke einzubauen.
A.
@asgothian
Bin am Handy und nicht zu Hause, deshalb auch die lustige Autokorrektur. Schau ich mir morgen mal an. Kann man auch so lassen, wobei ich jedesmal überlegen muss, ob true jetzt offen oder zu ist. -
@jan1 Unlackiert ist mal was neues. ;)
Und nein, das kann ich aktuell nicht ohne weiteres umstellen. Der Test den ich oben beschrieben habe ist wichtig, da wir den Zigbee Adapter schritt für schritt auf eine neue Methode der State-Erstellung umstellen wollen. Ich möchte lieber diese Methode vollständig nutzbar machen als eine weitere von uns zu behandelnde Sonderlocke einzubauen.
A.
@asgothian
Sieht nach der Aktion so aus:
Hätte wohl noch ein Screenshot vorher machen sollen, denn da war eigentlich alles ausgefüllt und da ich gestern durch ne Bastelei alles neu anlernen durfte, wundert es mich nun, dass da nix mehr steht.
Lässt sich aber noch voll bedienen.
-
@asgothian
Sieht nach der Aktion so aus:
Hätte wohl noch ein Screenshot vorher machen sollen, denn da war eigentlich alles ausgefüllt und da ich gestern durch ne Bastelei alles neu anlernen durfte, wundert es mich nun, dass da nix mehr steht.
Lässt sich aber noch voll bedienen.
-
@jan1 füllt es denn die states auch sauber und ist die Steuerung aus dem ioBroker so wie du sie erwartest ?
A.
@asgothian
Ja das klappt einwandfrei nur eben, dass nicht mehr alle States drin stehen. Im Moment sieht es so aus:
Also nur die DP für avalibale, link_quality und state of lock (mit dem ich auch steuere) sind aktiv. Der Rest wird zwar angelegt, aber da tut sich nix.
Ist zwar nicht wirklich störend, nur bin ich mir recht sicher, dass die bevor ich die gewünschte Aktion durchgeführt habe auch aktiv waren. Hab den Adapter jetzt schon mehrfach neugestartet und Coordinator neu gesteckt, ändert aber nichts an der Situation. Könnte mal neu pairen, denn das hatte ich ja gestern tun müssen, nach dem ich gebastelt hatte.Hier noch ein paar Infos aus dem Log:
zigbee.0 2021-06-18 10:04:18.693 info 0x000b57fffe59d1f6 (addr 9620): V3-BTZB/V3-BTZBE - Danalock BT/ZB smartlock (EndDevice) zigbee.0 2021-06-18 10:04:18.575 info Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20210120}} zigbee.0 2021-06-18 10:04:13.503 info Installed Version: iobroker.zigbee@1.5.6 zigbee.0 2021-06-18 10:04:13.228 info Starting Zigbee npm ... zigbee.0 2021-06-18 10:04:13.101 info starting. Version 1.5.6 in /opt/iobroker/node_modules/iobroker.zigbee, node: v16.3.0, js-controller: 3.3.12und ja, es läuft Node 16 mit NPM 7. Das war auch der Grund warum ich gebastelt habe, da lediglich der Zigbee Adapter nach dem Update der Node nicht mehr lief und ich ihn deshalb neu installiert habe, was auch der Grund dafür ist, dass ich alle Geräte neu pairen musste.
Unterm Strich kommt mit das mit Node16 aufgeräumter in den Logs vor als vorher mit 14 :) -
@asgothian
Ja das klappt einwandfrei nur eben, dass nicht mehr alle States drin stehen. Im Moment sieht es so aus:
Also nur die DP für avalibale, link_quality und state of lock (mit dem ich auch steuere) sind aktiv. Der Rest wird zwar angelegt, aber da tut sich nix.
Ist zwar nicht wirklich störend, nur bin ich mir recht sicher, dass die bevor ich die gewünschte Aktion durchgeführt habe auch aktiv waren. Hab den Adapter jetzt schon mehrfach neugestartet und Coordinator neu gesteckt, ändert aber nichts an der Situation. Könnte mal neu pairen, denn das hatte ich ja gestern tun müssen, nach dem ich gebastelt hatte.Hier noch ein paar Infos aus dem Log:
zigbee.0 2021-06-18 10:04:18.693 info 0x000b57fffe59d1f6 (addr 9620): V3-BTZB/V3-BTZBE - Danalock BT/ZB smartlock (EndDevice) zigbee.0 2021-06-18 10:04:18.575 info Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20210120}} zigbee.0 2021-06-18 10:04:13.503 info Installed Version: iobroker.zigbee@1.5.6 zigbee.0 2021-06-18 10:04:13.228 info Starting Zigbee npm ... zigbee.0 2021-06-18 10:04:13.101 info starting. Version 1.5.6 in /opt/iobroker/node_modules/iobroker.zigbee, node: v16.3.0, js-controller: 3.3.12und ja, es läuft Node 16 mit NPM 7. Das war auch der Grund warum ich gebastelt habe, da lediglich der Zigbee Adapter nach dem Update der Node nicht mehr lief und ich ihn deshalb neu installiert habe, was auch der Grund dafür ist, dass ich alle Geräte neu pairen musste.
Unterm Strich kommt mit das mit Node16 aufgeräumter in den Logs vor als vorher mit 14 :)@jan1 sagte in Zigbee-Adapter 1.0.2 Danalock:
@asgothian
Ja das klappt einwandfrei nur eben, dass nicht mehr alle States drin stehen. Im Moment sieht es so aus:
Also nur die DP für avalibale, link_quality und state of lock (mit dem ich auch steuere) sind aktiv. Der Rest wird zwar angelegt, aber da tut sich nix.
Ist zwar nicht wirklich störend, nur bin ich mir recht sicher, dass die bevor ich die gewünschte Aktion durchgeführt habe auch aktiv waren. Hab den Adapter jetzt schon mehrfach neugestartet und Coordinator neu gesteckt, ändert aber nichts an der Situation. Könnte mal neu pairen, denn das hatte ich ja gestern tun müssen, nach dem ich gebastelt hatte.Hier noch ein paar Infos aus dem Log:
zigbee.0 2021-06-18 10:04:18.693 info 0x000b57fffe59d1f6 (addr 9620): V3-BTZB/V3-BTZBE - Danalock BT/ZB smartlock (EndDevice) zigbee.0 2021-06-18 10:04:18.575 info Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20210120}} zigbee.0 2021-06-18 10:04:13.503 info Installed Version: iobroker.zigbee@1.5.6 zigbee.0 2021-06-18 10:04:13.228 info Starting Zigbee npm ... zigbee.0 2021-06-18 10:04:13.101 info starting. Version 1.5.6 in /opt/iobroker/node_modules/iobroker.zigbee, node: v16.3.0, js-controller: 3.3.12und ja, es läuft Node 16 mit NPM 7. Das war auch der Grund warum ich gebastelt habe, da lediglich der Zigbee Adapter nach dem Update der Node nicht mehr lief und ich ihn deshalb neu installiert habe, was auch der Grund dafür ist, dass ich alle Geräte neu pairen musste.
Unterm Strich kommt mit das mit Node16 aufgeräumter in den Logs vor als vorher mit 14 :)npm 7 ist ein Risiko - das das geht ist Zufall. Node 16 sollte kein Problem sein.
Kannst du mal bitte
- die IEEE deines Danalocks (000b57fffe59d1f6) in den State zigbee.0.info.debugmessages eintragen
- das Schloss vom ioBroker und mit dem Schlüssel schalten
- Im log nach "WARN" Nachrichten mit dem Schlüsselwort "ELEVATED" schauen und diese hier posten, zusammen mit einer Reihenfolge der Aktionen ?
Danke.
A.
-
@jan1 sagte in Zigbee-Adapter 1.0.2 Danalock:
@asgothian
Ja das klappt einwandfrei nur eben, dass nicht mehr alle States drin stehen. Im Moment sieht es so aus:
Also nur die DP für avalibale, link_quality und state of lock (mit dem ich auch steuere) sind aktiv. Der Rest wird zwar angelegt, aber da tut sich nix.
Ist zwar nicht wirklich störend, nur bin ich mir recht sicher, dass die bevor ich die gewünschte Aktion durchgeführt habe auch aktiv waren. Hab den Adapter jetzt schon mehrfach neugestartet und Coordinator neu gesteckt, ändert aber nichts an der Situation. Könnte mal neu pairen, denn das hatte ich ja gestern tun müssen, nach dem ich gebastelt hatte.Hier noch ein paar Infos aus dem Log:
zigbee.0 2021-06-18 10:04:18.693 info 0x000b57fffe59d1f6 (addr 9620): V3-BTZB/V3-BTZBE - Danalock BT/ZB smartlock (EndDevice) zigbee.0 2021-06-18 10:04:18.575 info Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20210120}} zigbee.0 2021-06-18 10:04:13.503 info Installed Version: iobroker.zigbee@1.5.6 zigbee.0 2021-06-18 10:04:13.228 info Starting Zigbee npm ... zigbee.0 2021-06-18 10:04:13.101 info starting. Version 1.5.6 in /opt/iobroker/node_modules/iobroker.zigbee, node: v16.3.0, js-controller: 3.3.12und ja, es läuft Node 16 mit NPM 7. Das war auch der Grund warum ich gebastelt habe, da lediglich der Zigbee Adapter nach dem Update der Node nicht mehr lief und ich ihn deshalb neu installiert habe, was auch der Grund dafür ist, dass ich alle Geräte neu pairen musste.
Unterm Strich kommt mit das mit Node16 aufgeräumter in den Logs vor als vorher mit 14 :)npm 7 ist ein Risiko - das das geht ist Zufall. Node 16 sollte kein Problem sein.
Kannst du mal bitte
- die IEEE deines Danalocks (000b57fffe59d1f6) in den State zigbee.0.info.debugmessages eintragen
- das Schloss vom ioBroker und mit dem Schlüssel schalten
- Im log nach "WARN" Nachrichten mit dem Schlüsselwort "ELEVATED" schauen und diese hier posten, zusammen mit einer Reihenfolge der Aktionen ?
Danke.
A.
@asgothian
Wenn ich zu Hause bin und Frau nichts anderes für mich geplant hat. Ansonsten wohl erst morgen.
NPM 7 ist klar. Bis jetzt läuft ja alles und nur der Zigbee hatte das Update nicht ohne Neuinstallation geschluckt. Node 16 bringt NPM 7 mit und Thomas hatte was angedeutet, dass er manuell kein NPM 6 in Node 16 bringen konnte. Wenn er das nicht schafft, wer sonst :)
Werd ich aber mal in Angriff nehmen. -
@jan1 sagte in Zigbee-Adapter 1.0.2 Danalock:
@asgothian
Ja das klappt einwandfrei nur eben, dass nicht mehr alle States drin stehen. Im Moment sieht es so aus:
Also nur die DP für avalibale, link_quality und state of lock (mit dem ich auch steuere) sind aktiv. Der Rest wird zwar angelegt, aber da tut sich nix.
Ist zwar nicht wirklich störend, nur bin ich mir recht sicher, dass die bevor ich die gewünschte Aktion durchgeführt habe auch aktiv waren. Hab den Adapter jetzt schon mehrfach neugestartet und Coordinator neu gesteckt, ändert aber nichts an der Situation. Könnte mal neu pairen, denn das hatte ich ja gestern tun müssen, nach dem ich gebastelt hatte.Hier noch ein paar Infos aus dem Log:
zigbee.0 2021-06-18 10:04:18.693 info 0x000b57fffe59d1f6 (addr 9620): V3-BTZB/V3-BTZBE - Danalock BT/ZB smartlock (EndDevice) zigbee.0 2021-06-18 10:04:18.575 info Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20210120}} zigbee.0 2021-06-18 10:04:13.503 info Installed Version: iobroker.zigbee@1.5.6 zigbee.0 2021-06-18 10:04:13.228 info Starting Zigbee npm ... zigbee.0 2021-06-18 10:04:13.101 info starting. Version 1.5.6 in /opt/iobroker/node_modules/iobroker.zigbee, node: v16.3.0, js-controller: 3.3.12und ja, es läuft Node 16 mit NPM 7. Das war auch der Grund warum ich gebastelt habe, da lediglich der Zigbee Adapter nach dem Update der Node nicht mehr lief und ich ihn deshalb neu installiert habe, was auch der Grund dafür ist, dass ich alle Geräte neu pairen musste.
Unterm Strich kommt mit das mit Node16 aufgeräumter in den Logs vor als vorher mit 14 :)npm 7 ist ein Risiko - das das geht ist Zufall. Node 16 sollte kein Problem sein.
Kannst du mal bitte
- die IEEE deines Danalocks (000b57fffe59d1f6) in den State zigbee.0.info.debugmessages eintragen
- das Schloss vom ioBroker und mit dem Schlüssel schalten
- Im log nach "WARN" Nachrichten mit dem Schlüsselwort "ELEVATED" schauen und diese hier posten, zusammen mit einer Reihenfolge der Aktionen ?
Danke.
A.
@Asgothian
Hier wie gewünscht die Log Einträge.auf und abschließen über DP im IOBroker:
zigbee.0 2021-06-19 08:30:01.577 warn ELEVATED Change state 'state' at device 0x000b57fffe59d1f6 type 'V3-BTZB/V3-BTZBE' zigbee.0 2021-06-19 08:30:01.566 warn ELEVATED: User stateChange zigbee.0.000b57fffe59d1f6.state {"val":false,"ack":false,"ts":1624084201562,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1624084201562} zigbee.0 2021-06-19 08:29:21.238 warn ELEVATED Change state 'state' at device 0x000b57fffe59d1f6 type 'V3-BTZB/V3-BTZBE' zigbee.0 2021-06-19 08:29:21.224 warn ELEVATED: User stateChange zigbee.0.000b57fffe59d1f6.state {"val":true,"ack":false,"ts":1624084161218,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1624084161218}Direkt am Schloss passiert im Log nichts.
der JS Adpapter spuckt jetzt noch das aus:javascript.0 2021-06-19 08:30:13.496 warn getState "zigbee.0.ccccccfffee04e28.state" not found (3) -
@asgothian
Ja das klappt einwandfrei nur eben, dass nicht mehr alle States drin stehen. Im Moment sieht es so aus:
Also nur die DP für avalibale, link_quality und state of lock (mit dem ich auch steuere) sind aktiv. Der Rest wird zwar angelegt, aber da tut sich nix.
Ist zwar nicht wirklich störend, nur bin ich mir recht sicher, dass die bevor ich die gewünschte Aktion durchgeführt habe auch aktiv waren. Hab den Adapter jetzt schon mehrfach neugestartet und Coordinator neu gesteckt, ändert aber nichts an der Situation. Könnte mal neu pairen, denn das hatte ich ja gestern tun müssen, nach dem ich gebastelt hatte.Hier noch ein paar Infos aus dem Log:
zigbee.0 2021-06-18 10:04:18.693 info 0x000b57fffe59d1f6 (addr 9620): V3-BTZB/V3-BTZBE - Danalock BT/ZB smartlock (EndDevice) zigbee.0 2021-06-18 10:04:18.575 info Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20210120}} zigbee.0 2021-06-18 10:04:13.503 info Installed Version: iobroker.zigbee@1.5.6 zigbee.0 2021-06-18 10:04:13.228 info Starting Zigbee npm ... zigbee.0 2021-06-18 10:04:13.101 info starting. Version 1.5.6 in /opt/iobroker/node_modules/iobroker.zigbee, node: v16.3.0, js-controller: 3.3.12und ja, es läuft Node 16 mit NPM 7. Das war auch der Grund warum ich gebastelt habe, da lediglich der Zigbee Adapter nach dem Update der Node nicht mehr lief und ich ihn deshalb neu installiert habe, was auch der Grund dafür ist, dass ich alle Geräte neu pairen musste.
Unterm Strich kommt mit das mit Node16 aufgeräumter in den Logs vor als vorher mit 14 :) -
@jan1 Ich hab noch eine Frage:
Was passiert im Log wenn du den "device_query" state mit "true" füllst ?
A.
-
@asgothian
Das stand wohl auf true und wurde nur nicht angezeigt. Ein Wechsel hin und her bringt keine Log Einträge. -
@jan1 Bist du sicher ? Wenn du es zwei mal mit wahr belegst sollte eine Meldung kommen. Dazu muss es nicht zwischendurch falsch werden.
A.
-
@asgothian
Habe jetzt mal auf debug gestellt und zweimal true gesetzt, dann kaommt das im Log:
Ohne Debug kommt nix im Log.@jan1 sagte in Zigbee-Adapter 1.0.2 Danalock:
2021-06-20 11:35:16.871 - warn: zigbee.0 (45269) Device query for '0x000b57fffe59d1f6' blockedSeltsam. Diese Meldung hätte auch ohne Debug auftauchen müssen.
Ist auch egal - das Schloss hat offensichtlich keine Option den Status auszulesen - zumindest nicht über den Herdsman.
Was übrig bleibt ist zu versuchen das reporting wieder zu aktivieren.
A.
-
@jan1 sagte in Zigbee-Adapter 1.0.2 Danalock:
2021-06-20 11:35:16.871 - warn: zigbee.0 (45269) Device query for '0x000b57fffe59d1f6' blockedSeltsam. Diese Meldung hätte auch ohne Debug auftauchen müssen.
Ist auch egal - das Schloss hat offensichtlich keine Option den Status auszulesen - zumindest nicht über den Herdsman.
Was übrig bleibt ist zu versuchen das reporting wieder zu aktivieren.
A.
-
@asgothian
Wie geschrieben, es funktioniert wie es soll, die paar nice to have Infos die fehlen stören nicht wirklich. Wenn Du das trotzdem wieder zum Laufen bekommst, wäre natürlich das Sahnehäubchen ;)@jan1 Ich werde da auf Deine Hilfe angewiesen sein - ausgehend davon das @smarthomegirl zwar den Fehler gemeldet hat (auch auf Github) sich aber ansonsten nicht an der Lösung beteiligt hat.
Ich selber habe kein Schloss und kann deswegen nur bedingt ohne Hilfe daran arbeiten.
A.
-
@jan1 Ich werde da auf Deine Hilfe angewiesen sein - ausgehend davon das @smarthomegirl zwar den Fehler gemeldet hat (auch auf Github) sich aber ansonsten nicht an der Lösung beteiligt hat.
Ich selber habe kein Schloss und kann deswegen nur bedingt ohne Hilfe daran arbeiten.
A.
-
@asgothian
ich bin dabei, was brauchst alles?@jan1 Ich werde da auf Deine Hilfe angewiesen sein - ausgehend davon das @smarthome
Noch nix. Ich muss mir die Code-Basis erst einmal anschauen. Dann müsstest Du einen Test-Branch von mir installieren bei dem wir versuchen das Schloss zum "reporting" zu überreden. Das kann (auch wegen der Temperaturen) und wegen Besuch kommendes Wochenende ein paar Tage dauern.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@jan1 Ich werde da auf Deine Hilfe angewiesen sein - ausgehend davon das @smarthome
Noch nix. Ich muss mir die Code-Basis erst einmal anschauen. Dann müsstest Du einen Test-Branch von mir installieren bei dem wir versuchen das Schloss zum "reporting" zu überreden. Das kann (auch wegen der Temperaturen) und wegen Besuch kommendes Wochenende ein paar Tage dauern.
A.
@asgothian
lass Dir Zeit und kein Stress ;) -
@jan1 Ich werde da auf Deine Hilfe angewiesen sein - ausgehend davon das @smarthome
Noch nix. Ich muss mir die Code-Basis erst einmal anschauen. Dann müsstest Du einen Test-Branch von mir installieren bei dem wir versuchen das Schloss zum "reporting" zu überreden. Das kann (auch wegen der Temperaturen) und wegen Besuch kommendes Wochenende ein paar Tage dauern.
A.
@asgothian hallo, hoffe ich störe nicht.
habe seit geraumer Zeit das Problem das der Status sich nicht verändert lock_state (Actual state of the lock).
Ich kann leider nicht sagen seit wann dieses Problem besteht. (nehme an seit dem neuem Dashboard da ich alles in meinen scripten anpassen musste)
Ein neues Pairing brachte kurz Erfolge (am 27.06.2021 letzter automatischer Eintrag), aber jetzt ist das Problem wieder da.Wenn jetzt das Schloss auf oder zu geschlossen wird, ändert sich aber der das lock_state nicht mehr.
Über Entwickler lässt sich der Status manuell auslesen.
Da mein SmartHome auf diesen lock_state reagiert (da auch manuelles betätigen mit Schlüssel funktionierte), frage ich hiermit was ich machen kann das dies wieder funktioniert. -
@asgothian hallo, hoffe ich störe nicht.
habe seit geraumer Zeit das Problem das der Status sich nicht verändert lock_state (Actual state of the lock).
Ich kann leider nicht sagen seit wann dieses Problem besteht. (nehme an seit dem neuem Dashboard da ich alles in meinen scripten anpassen musste)
Ein neues Pairing brachte kurz Erfolge (am 27.06.2021 letzter automatischer Eintrag), aber jetzt ist das Problem wieder da.Wenn jetzt das Schloss auf oder zu geschlossen wird, ändert sich aber der das lock_state nicht mehr.
Über Entwickler lässt sich der Status manuell auslesen.
Da mein SmartHome auf diesen lock_state reagiert (da auch manuelles betätigen mit Schlüssel funktionierte), frage ich hiermit was ich machen kann das dies wieder funktioniert.@jan-puchta sagte in Zigbee-Adapter 1.0.2 Danalock:
habe seit geraumer Zeit das Problem das der Status sich nicht verändert lock_state (Actual state of the lock).
Ich kann leider nicht sagen seit wann dieses Problem besteht. (nehme an seit dem neuem Dashboard da ich alles in meinen scripten anpassen musste)
Ein neues Pairing brachte kurz Erfolge (am 27.06.2021 letzter automatischer Eintrag), aber jetzt ist das Problem wieder da.Welche Adapter version setzt du aktuell ein ?
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@jan-puchta sagte in Zigbee-Adapter 1.0.2 Danalock:
habe seit geraumer Zeit das Problem das der Status sich nicht verändert lock_state (Actual state of the lock).
Ich kann leider nicht sagen seit wann dieses Problem besteht. (nehme an seit dem neuem Dashboard da ich alles in meinen scripten anpassen musste)
Ein neues Pairing brachte kurz Erfolge (am 27.06.2021 letzter automatischer Eintrag), aber jetzt ist das Problem wieder da.Welche Adapter version setzt du aktuell ein ?
@asgothian sorry für die späte antwort, es war die 1.5.6 version. habe wieder auf 1.4.4 zurück gewechselt
470
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge