Nodejs 10 Kompatibilität

[rrdd]

Ich habe versucht keyble mit einem aktuellen debian buster unter raspberry zum laufen zubringen. Leider kann man nodejs 8 gar nicht mehr darauf installieren. Er bügelt immer gleich die 10 drauf.

Hast du vielleicht nochmal die Zeit und Lust das ganze auf nodej10 kompatibel zu bauen? Das tool ist wirklich super. War kurz davor die Alexa via Skill anzukoppeln :-/

Danke im voraus

[bhuebschen]

Hast du vielleicht nochmal die Zeit und Lust das ganze auf nodej10 kompatibel zu bauen? Das tool ist wirklich super. War kurz davor die Alexa via Skill anzukoppeln :-/

Daran wäre ich interessiert ;)

[oyooyo]

Ich war mir ehrlich gesagt gar nicht (mehr?) bewusst, dass es unter Node 10 nicht funktioniert. Danke für den Hinweis! Wenn es mit neueren Node-Version grundsätzlich nicht mehr funktioniert, dann sollte ich mir das definitiv anschauen.

Allerdings werde ich wohl nicht speziell auf Kompatibilität mit Node 10 achten, sondern nur auf Kompatibilität mit der aktuellen LTS-Version, Node 12.

[oyooyo]

Kleines Status-Update: Ich habe angefangen, den gesamten Code neu zu schreiben. Zum einen, um statt CoffeeScript direkt JavaScript/ECMAscript zu verwenden. Bei der Gelegenheit will ich den Code auch etwas modernisieren, indem ich neue ECMAscript-Features wie async/await oder async generators nutze. Und dann soll der Code auch mit JSDoc und allgemein etwas ausführlicher dokumentiert und übersichtlicher werden.

Bei weit über 1000 Zeilen Code ist das allerdings doch ein gutes Stück Arbeit. Den grössten Teil habe ich aber bereits geschafft, ich denke, spätestens nächste Woche wird es eine neue Version mit der überarbeiteten Code-Basis geben.

Wäre nett, wenn einer von Euch die dann mal testen könnte. Zum Einen wird sich beim Umstellen vermutlich noch der eine oder andere Bug eingeschlichen haben.

Zum Anderen wäre halt interessant, ob es mit Node 10 funktioniert. Mit Node 8 wird die neue Version wohl definitiv nicht mehr kompatibel sein, weil ich gesehen habe, dass eines der Features die ich jetzt verwende wohl erst ab Node 10 verfügbar ist. Sicher kompatibel wird die neue Version nur mit Node 12 sein, weil das halt die Version ist, die ich aktuell verwende. Aber sofern das keine allzu grossen Probleme macht werde ich versuchen, dass es auch noch mit Node 10 funktioniert, wenn das bei den üblichen Raspberry Pi-Distros die aktuelle Version ist.

[marcelkordek]

Hallo oyooyo,

Viele Dank für die schnelle Anpassung. Ich teste gerne.

Habe Keyble seit Anfang an am laufen. Mit ein paar kleinen Änderungen und eigenen MQTT-Service. Es läuft einwandfrei, außer das ich ab und an Fehler bekomme -> Simble findet dann keine Services: Cannot read property 'services' of null.

Nach einem Neustart funktioniert es dann wieder :)

[oyooyo]

Hallo,

ich habe eben eine erste Version 0.2.0. mit dem neu geschriebenen Sourcecode hochgeladen. Da ist noch einiges zu tun, bislang ist hauptsächlich der Sourcecode auf Javascript umgestellt und der Code ein wenig umstrukturiert worden.

Da sind definitiv noch einige Fehler drin, die noch gefunden und ausgemerzt werden müssen. Wer dabei helfen und sie schon mal testen will (Danke für das Angebot @marcelkordek !) möchte: Die neue Version kann mit npm install keyble@beta installiert werden. Also wie in der Anleitung beschrieben, nur mit keyble@beta statt keyble. Interessant wäre auch, ob es mit Node 10 oder Node 14 auch noch funktioniert, ich verwende aktuell halt nur Node 12.

Ein Fehler, den ich selbst bereits entdeckt habe, und den ihr daher nicht extra erwähnen müsst: Der "continuous-Mode" funktioniert noch nicht richtig. Wenn keyble nach der per --auto_disconnect_time festgelegten Zeit die Verbindung zum Smart Lock wegen Inaktivität trennt, und man danach einen neuen Befehl eingibt, kommt eine Fehlermeldung, die Verbindung wird nicht wieder aufgebaut.

[marcelkordek]

Hallo oyooyo,

nach erstem Test mit Node v10.0.0 auf einem Pi Zero funktioniert soweit alles. Allerdings bekomme ich von Zeit zu Zeit, selbst mit "auto_disconnect_time: 0" folgenden Fehler (Das ist dir ja bereits bekannt):

TypeError: Cannot read property 'connect' of null at Promise (simble/simble.js:492:27)

Bei mir läuft das ganze auch im"continuous-Mode". Ansonsten konnte ich noch nichts negatives Feststellen ;)

[rrdd]

node -v v10.21.0

Das registrieren klappte leider nicht via

keyble-registeruser -n PC -q *****

Press and hold "Unlock" button until the yellow light flashes in order to enter pairing mode (node:4620) DeprecationWarning: _ActionsContainer.addArgument() is renamed to _ActionsContainer.add_argument() (node:4620) DeprecationWarning: add_argument(): following options are renamed: 'defaultValue' -> 'default' (node:4620) DeprecationWarning: use add_argument('--user_name', '-n', {...}) instead of add_argument([ '--user_name', '-n' ], { ... }) (node:4620) DeprecationWarning: ArgumentParser.parseArgs() is renamed to ArgumentParser.parse_args() (node:4620) DeprecationWarning: use {type:"str"} or {type:String} instead of {type:"string"}

TypeError: command_line_input_strings.filter is not a function at generate_input_strings (/usr/local/lib/node_modules/keyble/cli.js:31:58) at generate_input_strings.next () at register_users_then_exit `(/usr/local/lib/node_modules/keyble/register_user.js:61:39)

[oyooyo]

Allerdings bekomme ich von Zeit zu Zeit, selbst mit "auto_disconnect_time: 0" folgenden Fehler (Das ist dir ja bereits bekannt):

TypeError: Cannot read property 'connect' of null at Promise (simble/simble.js:492:27)

Danke für die Meldung @marcelkordek . Das ist in der Tat genau der Fehler, der bei mir auch kam.

Danke auch an Dich, @rrdd. Das umgeschriebene registeruser-Script habe ich bislang noch gar nicht getestet, weil ich zum Löschen der so angelegten User dann erst mal wieder die Android-App suchen und installieren müsste.

Ich habe eben mal Version 0.2.2 hochgeladen, in der hoffentlich beide Bugs behoben sind. Der erste Bug ist hoffentlich weg, den zweiten bei registeruser habe ich versucht zu beheben, aber wie gesagt nicht getestet. Kann wieder via npm install keyble@beta installiert werden.

[marcelkordek]

Hallo, der reconnect Fehler scheint behoben. Läuft jetzt seit Stunden ohne Fehler und Neustart durch 👍 Die einzige Änderung die ich bei mir am laufen habe ist das Keyble den Status immer sendet (auch wenn sich der Wert nicht ändert) und das er mir im Status auch den Batterie-Status mitschickt.

[rrdd]

Hallo, bei mir kommt jetzt bei register folg fehler. nutze nodejs 10

ReferenceError: hex_string_to_byte_array is not defined at Object.parse_key_card_data [as parse] (/usr/local/lib/node_modules/keyble/keyble.js:514:12) at register_user (/usr/local/lib/node_modules/keyble/register_user.js:38:58) at register_users_then_exit (/usr/local/lib/node_modules/keyble/register_user.js:62:10)

[oyooyo]

Hallo, der reconnect Fehler scheint behoben. Läuft jetzt seit Stunden ohne Fehler und Neustart durch +1 Die einzige Änderung die ich bei mir am laufen habe ist das Keyble den Status immer sendet (auch wenn sich der Wert nicht ändert) und das er mir im Status auch den Batterie-Status mitschickt.

Ah, warst Du das, der das damals herausgefunden hatte, wo der Batterie-Zustand gespeichert wird? So oder so, sag doch mal, wo diese Information enthalten ist. Irgendwer hatte mir das schon mal genannt, und ich dachte ich hätte das dann entsprechend geändert, war aber offenbar doch nicht so. Ich denke es macht Sinn, diese Information tatsächlich immer mit auszugeben. Ich überlege daher gerade, die Ausgabe des sendcommand-Skripts dahingehend zu ändern, dass nicht einfach nur OPENED/CLOSED etc. ausgegeben wird, sondern ein komplettes JSON-Objekt, also z.B.

{"lock_status": "OPENED", "lock_status_id":2, "battery_level": 76}

Wäre zwar eine rückwärtsinkompatible Änderung, macht aber denke ich Sinn.

Dass man Wählen kann, ob der Status immer oder nur bei Änderung ausgegeben wird, werde ich wohl auch noch als optionales Kommandozeilen-Flag hinzufügen.

[marcelkordek]

Nicht direkt, hatte ich glaube ich auch hier gelesen. Ist unter "Status_Info_Message" property e. Dieser gibt allerdings nur True oder False aus. Sprich Batterie leer oder nicht. Hat bei mir immer funktioniert. Werde mir die anderen Werte aber nochmal alle mit ausgeben lassen um zu vergleichen.

Die Status Änderung auswählbar zu machen finde ich auch sehr gut. Je nach Anwendungsgebiet kann man dann wählen.

[marcelkordek]

Also folgender Fehler kommt zwischendurch noch:

simble/simble.js:448 if (this.noble_peripheral.services) { ^ TypeError: Cannot read property 'services' of null at Peripheral.update_services (simble/simble.js:448:29)

Der reconnect Fehler ist dafür aber behoben.

[oyooyo]

simble/simble.js:448 if (this.noble_peripheral.services) { ^ TypeError: Cannot read property 'services' of null at Peripheral.update_services (simble/simble.js:448:29)

Ist Dir irgendein Muster aufgefallen, wann das auftritt? Damit ich mal versuchen kann, das zu reproduzieren.

Es gibt jetzt eine neue Beta-Version 0.2.4. Die angekündigten Veränderungen (Status-Ausgabe als JSON und wählbar, ob Status immer oder nur bei Änderung ausgegeben wird) sind darin enthalten.

Das Registrieren eines neues Benutzers via keyble-registeruser sollte jetzt auch funktionieren. Aus irgendeinem Grund funktioniert das anschliessende Setzen des Benutzernamens allerdings noch nicht. Da man den aber auch über die App setzen kann, ist das vorerst nicht so wild.

In einer der nächsten Beta-Versionen wird übrigens vermutlich noch die Möglichkeit hinzukommen, das Türschloss umzukonfigurieren. (Schloss links/rechts, Neutralposition horizontal/vertikal, Anzahl Umdrehungen).

[rrdd]

Hallo,

das registrieren klappt leider nicht bei mir.

keyble-registeruser -n PC -q **** Nach dem ausführen, kommt das script nach Ausgabe von Press and hold "Unlock" button until the yellow light flashes in order to enter pairing mode Registering user on Smart Lock with address "00:****", card key "****" and serial "*****"...

nie wieder zurück bzw beendet sich. :-(

[oyooyo]

@rrdd Ok, Danke für den Hinweis. Ich schlage vor, Du schaltest mal die Debug-Ausgaben ein, indem Du DEBUG=simble:*,keyble:* vor das keyble-registeruser stellst, also

DEBUG=simble:*,keyble:* keyble-registeruser -n PC -q ...

und schaust, an welcher Stelle er hängt.

[rrdd]

Hallo,

er hängt hier

keyble:event Event: disconnected +0ms

[oyooyo]

Schade, das ist leider doch noch zu wenig aussagekräftig. Probier's nochmal mit

DEBUG=* keyble-registeruser -n PC -q ...

um auch die noble-Debug-Nachrichten anzeigen zu lassen.

[rrdd]

da kommt jetzt viel output. wie kann ich dir den sicher übermitteln bzw was davon kann man posten btw benötigst du? richtig auffällig ist da nichts.

[rrdd]

Hier mal die kurze Version vollständig: simble:info Starting to scan for peripheral... +0ms

[rrdd]

nutze einen raspberry pi 4 und vermute mal liegt an https://github.com/abandonware/noble/issues/99 ? was meinst du?

[oyooyo]

da kommt jetzt viel output. wie kann ich dir den sicher übermitteln bzw was davon kann man posten btw benötigst du? richtig auffällig ist da nichts.

So richtig sensibel sind eigentlich nur die Keys - also der von der Key Card zum Registrieren neuer Benutzer, und der beim Registrieren von Benutzern erzeugte user_key. Die Bluetooth-Kommunikation selbst ist von eQ-3 mit diversen Massnahmen meinem Eindruck nach gut abgesichert. Sprich, die haben darauf geachtet, dass ein imaginärer Angreifer, der die Bluetooth-Kommunikation zwischen Deinem Smartphone/RPi und dem Türschlossantrieb belauschen/mitschneiden würde, keine Gefahr darstellt. Von daher kann man die simble: und noble: debug-Meldungen im Grunde ruhigen Gewissens posten - alles was auf diesen beiden Ebenen passiert, würde der imaginäre Angreifer, der heimlich die Bluetooth-Kommunikation mit dem Türschloss belauscht/mitschneidet, ebenfalls erfahren. Allerdings wären da immer noch MAC-Adressen enthalten, die zwar jetzt nicht sooo sensibel sind, aber die man vielleicht trotzdem nicht öffentlich posten will. Wirklich sensibel können daher eigentlich nur keyble: Debug-Meldungen sein. Wobei sowas wie die "Nonces" auch unbedenklich ist, denn die werden quasi zufällig erzeugt und sind nur bis zum nächsten disconnect gültig.

Du hast mich da aber gerade auf einen Gedanken gebracht: Ich schätze, ich sollte bei Gelegenheit mal eine Option einbauen, durch die man verhindern kann dass die Ausgabe sensible Informationen enthält.

Ob Dein Problem mit dem von Dir geposteten noble-issue zusammenhängt... Schwer zu sagen. Kann sein, aber wenn ich raten müsste, würde ich eher auf nein tippen. Von daher, dass bei vielen Leuten die in dem verlinkten issue gepostet haben offenbar lediglich ein Problem mit den Berechtigungen vorlag. Seit der vor ein paar Wochen veröffentlichten noble-Version 1.9.2-9 (?) dürfte dieses Problem aber kaum noch auftreten, weil noble seitdem eigentlich wieder gross und fett darauf hinweisen sollte, wenn diesbezüglich ein Problem vorliegt.

Bis dieses Feature existiert, kannst Du mir alternativ auch eine private eMail mit dem Log an oyooyo@users.noreply.github.com schicken.

[rrdd]

habs dir gemailt. danke

[marcelkordek]

Hi,

Ist Dir irgendein Muster aufgefallen, wann das auftritt? Damit ich mal versuchen kann, das zu reproduzieren.

Nein ein Muster ist mir nicht direkt aufgefallen. Scheint random zu sein. Ich werde jetzt aber heute Nacht nochmal die Logs aufzeichnen. Vielleicht erkennt man etwas.

Ps: 0.2.4 mit JSON und status_update läuft ohne Probleme. Mittlerweile teste ich mit Node 10.22.1.

[oyooyo]

@rrdd

habs dir gemailt. danke

Sorry, hat nicht funktioniert. Offenbar habe ich da was falsch verstanden und man kann gar nichts an diese eMail-Adresse schicken. Meine richtige möchte ich wegen Spam etc. hier aber auch nicht unbedingt öffentlich posten...

Ich werde mal meinen eigenen Raspberry Pi auspacken und schauen, ob ich das Problem da reproduzieren kann. Allerdings ist das ein Raspberry Pi 3 mit Raspbian, eventuell tritt das Problem da gar nicht auf.

[rrdd]

habe einen externen usb bt adapter bestellt. ich teste morgen mal damit. muss ich dem system irgendwie sagen, welchen adapter ich nutzen will?

[oyooyo]

@rrdd Über eine Umgebungsvariable kann man noble mitteilen, welchen Adapter er verwenden soll: https://github.com/abandonware/noble#multiple-adapters-linux-specific In der Regel ist das wohl nicht nötig, hier aber vielleicht doch mal nen Versuch wert.

Ich habe eben mal auf meinem Raspberry Pi 3B+ (mit Raspbian und Node v12) versucht, keyble zum Laufen zu bringen, und bin auch auf Probleme gestossen: Obwohl der RPi 3 Bluetooth-Hardware verbaut hat, wurde diese irgendwie nicht richtig erkannt. Mit einem externen USB-Bluetooth-Dongle hingegen hat es dann auf Anhieb geklappt.

Allerdings scheint Dein Problem ja anders gelagert zu sein, denn zumindest bis zum Verbindungsaufbau funktioniert es bei Dir ja offenbar.

[oyooyo]

@rrdd Meine Raspbian /Raspberry Pi OS Installation war scheinbar ein wenig veraltet. Habe den Pi mal plattgemacht und die aktuellste Version aufgespielt. Das Problem aus meinem letzten Posting scheint damit behoben zu sein, das interne Bluetooth-Gerät wird nun anstandlos erkannt.

Habe dann die aktuellste Version von Node 10 installiert und dann keyble. Und siehe da, ich kann Dein Problem reproduzieren. Dem ersten Anschein nach hat das Problem allerdings nichts mit Node 10 zu tun, als ich danach Node 12 installierte kam genau das gleiche Phänomen.

UPDATE: Mit dem externen USB-Bluetooth-Dongle hat es bei beiden Node-Versionen problemlos geklappt. Das ursprüngliche Problem scheint also nicht mit Node 10 zu tun zu haben und auch nicht in keyble zu stecken, sondern wohl wirklich irgendwo in noble.

[oyooyo]

@rrdd Ich glaube mittlerweile Du hattest tatsächlich recht, dass der von Dir verlinkte issue 99 das zugrundeliegende Problem ist.

[rrdd]

mit einem logilink usb bt stick funktioniert es

[marcelkordek]

Habe jetzt folgendes herausgefunden:

Keyble läuft als Service und prüft alle 15 Minuten den Status (status_update_time: 900). auto_disconnect_time steht auf 30. Es läuft stundenlang ohne Probleme. Sobald ich nun den Befehl 'öffnen' oder 'schließen' sende besteht eine 50:50 Chance das es funktioniert oder Keyble mit der bekannten Meldung abstürzt:

/usr/local/lib/node_modules/keyble-mqtt/node_modules/simble/simble.js:448 if (this.noble_peripheral.services) { ^ TypeError: Cannot read property 'services' of null at Peripheral.update_services (/usr/local/lib/node_modules/keyble-mqtt/node_modules/simble/simble.js:448:29) at noble_peripheral.discoverAllServicesAndCharacteristics (/usr/local/lib/node_modules/keyble-mqtt/node_modules/simble/simble.js:535:13) at service.discoverCharacteristics (/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble/lib/peripheral.js:119:13) at Service.once.characteristics (/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble/lib/service.js:56:7) at Object.onceWrapper (events.js:286:20) at Service.emit (events.js:203:15) at Noble.onCharacteristicsDiscover (/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble/lib/noble.js:398:13) at NobleBindings.emit (events.js:198:13) at NobleBindings.onCharacteristicsDiscovered (/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble/lib/hci-socket/bindings.js:368:8) at Gatt.emit (events.js:198:13)

Selbst wenn ich auto_disconnect_time auf 0 stelle habe ich dieses Phänomen. Mein MQTT-Service startet neu und probiert den letzten Befehl (vor Absturz) zu senden und es funktioniert einwandfrei.

[LilithWittmann]

Für mich hat es auf einem pi4 funktioniert, nachdem ich abandonware/noble#99 genutzt, bluetooth aktiviert und entblocked habe:

sudo bluetoothctl power on
rfkill unblock all

Und scheint mit der aktuellen beta soweit gut zu funktionieren. Danke!

[corgan2222]

Moin,

hab das Tool grade getestet.

Raspi 4, 4gb host_os | Raspbian GNU/Linux 10 (buster) installation_type | Home Assistant Supervised os_name | Linux os_version | 4.19.97-v7l+ python_version | 3.8.5 supervisor | 249 Node.js v12.16.2.

Bei der Installation gabs einige Fehler https://knaak.org/screens/MobaXterm_HyIsh4ZbPC.png

Ich habe das Schloss dann resettet und danach klappte es. Leider brauchen die Befehle zwischen 10 und 20 Sekunden. Manchmal gibt es aber auch einen Timeout.

`keyble-sendcommand --address 00:1A:22:13:6F:D2 --user_id 0 --user_key xxxxxxxxxxxxxxxxxx --command open

{"battery_low":false,"lock_status":"MOVING","lock_status_id":1,"pairing_allowed":true}

[ 'Error: ', '' ] Error: Promise did not resolve within 30000 milliseconds at Timeout._onTimeout (/usr/lib/node_modules/keyble/utils.js:258:11) at listOnTimeout (internal/timers.js:549:17) at processTimers (internal/timers.js:492:7) `

Wie verhällt sich eigentlich das Bluethoth auf dem Raspi? Ich frage auf dem Raspi noch 4 BT Pflanzensensoren ab die manchmal wegen der Entfernung schon in einen Timeout laufen und es läuft https://github.com/mKeRix/hassio-repo für die presence detection. Kann man das BT Geschehen irgendwie debuggen um das zu checken?

tnxs und Grüße

[oyooyo]

@corgan2222 , danke für Deinen Bericht. Bevor ich aber auf den eigentlichen Inhalt eingehe, ein ganz dringender Ratschlag: Lösche den zweiten Screenshot ganz schnell! Der Screenshot enthält den Inhalt Deiner "Key Card", die sensibelste Information überhaupt.

[corgan2222]

argh fck done.. #kopftisch

[oyooyo]

@corgan2222 Nun zu Deinem eigentlichen Bericht. Die Installation sieht relativ normal aus. Während die "noble"-Abhängigkeit installiert wird, werden meiner Erfahrung nach immer irgendwelche Compiler-Warnings etc. ausgespuckt, die einen erst einmal vermuten lassen, dass beim Installieren irgendwelche Fehler aufgetreten sind. Im Endeffekt funktioniert es dann aber trotzdem.

In Deinem Fall wird neben den nicht weiter ungewöhnlichen Warnings aber auch noch ein echter Error angezeigt, von wegen dass libudev.h nicht gefunden wurde. Ich glaube, die noble-library funktioniert zwar auch ohne libudev, aber besser wäre wahrscheinlich, die benötigten Libraries zu installieren. Hier steht was zu tun ist, kurz gesagt:

sudo apt-get install bluetooth bluez libbluetooth-dev libudev-dev

...ausführen, bevor man keyble installiert. Eventuell solltest Du keyble also nochmal komplett deinstallieren, libudev etc. über den obigen Befehl installieren, und keyble dann nochmal neu installieren.

Was den zweiten Screenshot anbelangt: Beim Registrieren des User-Accounts werden da irgendwelche Fehler angezeigt, die mir so erst einmal nicht bekannt vorkommen ("noble warning unknown handle 64 disconnected", "noble unknown peripheral .... connected!"). Scheint aber trotzdem irgendwie funktionert zu haben, ausser dass vermutlich der Benutzername nicht gesetzt wurde, das ist noch ein bereits bekanntes Problem.

Ansonsten würde ich vermuten, dass Deine Probleme vielleicht wirklich damit zu tun haben, dass Du Bluetooth für mehrere Sachen gleichzeitig benutzt. Ich meine mich zu erinnern, dass die noble-Library, die keyble für die Bluetooth-Kommunikation verwendet, Probleme damit hat, wenn gleichzeitig auch noch andere Software auf die Bluetooth-Hardware zugreift. Und der interne Bluetooth-Adapter des Raspberry Pi macht ja offenbar eh gewisse Probleme.

Diese Timeouts nach 30 Sekunden sind aber schon irgendwie merkwürdig. Ich schätze, ich sollte die Zeit mal ein bisschen erhöhen, ich dachte bislang 30 Sekunden wären mehr als genug. Debug-Output kannst Du einschalten, indem Du DEBUG=* vor den eigentlichen Befehl schreibst, also z.B.

DEBUG=* keyble-sendcommand ....

Wäre im Falle der Timeouts wirklich mal interessant.

[lala-rob]

Hallo,

das Problem mit dem Timeout hab ich auch. Bei mir kommt es immer beim Unlock Befehl.

Raspi 4, 4gb Raspbian GNU/Linux 10 (buster) Node.js v10.21.0

pi@raspberrypi:~ $ keyble-sendcommand --address 00:1A:22:13:6D:4C --user_id 4 --user_key AAAAA --command unlock {"battery_low":false,"lock_status":"MOVING","lock_status_id":1,"pairing_allowed":true} {"battery_low":false,"lock_status":"UNLOCKED","lock_status_id":2,"pairing_allowed":true} pi@raspberrypi:~ $ keyble-sendcommand --address 00:1A:22:13:6D:4C --user_id 4 --user_key AAAAA --command lock {"battery_low":false,"lock_status":"MOVING","lock_status_id":1,"pairing_allowed":true} {"battery_low":false,"lock_status":"UNKNOWN","lock_status_id":0,"pairing_allowed":true} [ 'Error: ', '' ] Error: Promise did not resolve within 30000 milliseconds at Timeout.setTimeout [as _onTimeout] (/home/pi/keyble/node_modules/keyble/utils.js:258:11) at ontimeout (timers.js:436:11) at tryOnTimeout (timers.js:300:5) at listOnTimeout (timers.js:263:5) at Timer.processTimers (timers.js:223:10)

[oyooyo]

das Problem mit dem Timeout hab ich auch. Bei mir kommt es immer beim Unlock Befehl.

Du meinst beim Lock-Befehl, oder? Zumindest suggeriert das das von Dir gepostete Log.

pi@raspberrypi:~ $ keyble-sendcommand --address 00:1A:22:13:6D:4C --user_id 4 --user_key AAAAA --command unlock {"battery_low":false,"lock_status":"MOVING","lock_status_id":1,"pairing_allowed":true} {"battery_low":false,"lock_status":"UNLOCKED","lock_status_id":2,"pairing_allowed":true} pi@raspberrypi:~ $ keyble-sendcommand --address 00:1A:22:13:6D:4C --user_id 4 --user_key AAAAA --command lock {"battery_low":false,"lock_status":"MOVING","lock_status_id":1,"pairing_allowed":true} {"battery_low":false,"lock_status":"UNKNOWN","lock_status_id":0,"pairing_allowed":true} [ 'Error: ', '' ] Error: Promise did not resolve within 30000 milliseconds

Ich interpretiere diese Ausgabe so, dass Dein Schloss aus irgendeinem Grund den "LOCKED"-Zustand nicht erkennt, und den Zustand daher irgendwann auf "UNKNOWN" setzt. keyble scheint sich da auf den ersten Blick korrekt zu verhalten: wenn man ein "lock"-Kommando sendet, dann wartet keyble darauf, dass als Zustand "LOCKED" gemeldet wird, erst in diesem Moment gilt das Kommando für keyble als erfolgreich ausgeführt. Wenn das binnen 30 Sekunden nicht passiert, geht keyble davon aus, dass da irgendein Problem vorliegt.

Die eigentliche Frage scheint mir daher zu sein, warum Dein Türschlossantrieb nicht in den LOCKED, sondern in den UNKNOWN-Zustand wechselt. Hast Du das Schloss über die Hersteller-App korrekt konfiguriert (An welcher Seite ist das Schloss, wie viele Umdrehungen, Neutralposition horizontal/vertikal etc.)?

[corgan2222]

Danke erstmal für die Tipps. Ich habe alles nochmal runtergeschmissen und mit der Installation der Bluetooth Apts angefangen. Danach konnte keyble auch libudev ohne Fehler installieren.

Da ich noch auf das richtige Schloss warte (das aktuelle ist zu kurz) dreht das Dingen total frei. Denke daher spinnt der gerade noch und läuft in nen Timeout.

Wenn ich morgen das richtige Schloss eingebaut habe, werde ich nochmal berichten.

Hast Du das Schloss über die Hersteller-App korrekt konfiguriert

Ich hatte das Schloss komplett resettet. Muss/kann/soll ich die Einrichtung nochmal über die App machen?

[oyooyo]

Da ich noch auf das richtige Schloss warte (das aktuelle ist zu kurz) dreht das Dingen total frei. Denke daher spinnt der gerade noch und läuft in nen Timeout.

Gut möglich. Der Türschlossantrieb erwartet glaube ich, dass da irgendwann ein Widerstand kommt. Wenn der nicht kommt sondern er immer weiter drehen kann, dann geht er irgendwann zurecht davon aus, dass da irgendetwas nicht stimmt.

Wenn ich morgen das richtige Schloss eingebaut habe, werde ich nochmal berichten.

Hast Du das Schloss über die Hersteller-App korrekt konfiguriert

Ich hatte das Schloss komplett resettet. Muss/kann/soll ich die Einrichtung nochmal über die App machen?

Leider ja. Irgendwann soll es zwar die Möglichkeit geben, die initiale Konfiguration direkt per Keyble vornehmen zu können, aber bislang ist dafür die App nötig. Letztlich geht es wirklich nur darum, die Eigenschaften des Schlosses einzustellen - hauptsächlich, ob das Schloss auf der linken oder der rechten Seite ist, bei den anderen beiden Einstellungen ist die Standardeinstellung normalerweise okay.

[lala-rob]

@oyooyo Danke für die Info. Ich hatte mein Schloss auf eine Umdrehung gestellt obwohl zwei möglich sind. Hab es angepasst und jetzt passt es:)

[oyooyo]

@lala-rob Freut mich zu hören!

Mal was ganz Anderes, rein aus Neugier eine kleine Mini-Umfrage: Ich habe gesehen, dass der eqiva Türschlossantrieb vor Kurzem von Stiftung Warentest getestet wurde und wohl sogar auf den ersten Platz kam. Ist jemand von euch dadurch auf den Türschlossantrieb aufmerksam geworden, oder habt ihr den schon länger?

[LilithWittmann]

@oyooyo witzigerweise bin ich durch Deine Library darauf aufmerksam geworden. Ich suchte nach einem günstigen Schlossmotor, der sich halbwegs gut ansteuern lässt und bei dem die Crypto OK wirkt. Vielen Dank für deine Arbeit! ❤️

[corgan2222]

@LilithWittmann dem kann ich mich nur anschließen. Ich habe schon lange nach einem smarten Schloss für die innere Haustür gesucht, dass keine 300€ kostet aber trotzdem halbwegs sicher ist. Tatsächlich bin ich über einen Thread im Home Assistant Forum auf das Projekt hier aufmerksam geworden und hab dann direkt das Schloss gekauft.

Ich hoffe ich bekomme das morgen "Frauentauglich" hin. Die Dame beschwert sich jetzt schon, dass sie 2-3sek vor der äußeren Haustür stehen muss, bis ihr Gesicht erkannt wird und die Tür aufgeht. Wenn sie jetzt ewig auf die innere Haustür warten muss, kann ich das Ding gleich wieder zurückschicken. :) #firstworldproblems

[marcelkordek]

Ging mir auch so, bin 2018 im mikrocontroller.net Forum auf dein Projekt aufmerksam geworden. Seit dem läuft es bei mir sehr zuverlässig :)

@corgan2222 Interessanter Punkt mit der Gesichtserkennung. Wie hast du das gelöst? Komplett DIY? Ps: Meine schließen und öffnen Automationen in HomeKit werden innerhalb von 1-2 Sekunden vom Schloss ausgeführt.

@oyooyo Ich habe bei mir die UpdateServices Funktion in simble angepasst (try catch Block). Seit dem sind die Cannot read property 'services' of null Fehler behoben. Vll könnte man an dieser Stelle überprüfen ob Services gefunden wurden und wenn nicht einfach nochmal suchen.

Vielen Dank für deine bisherigen Bemühungen und Updates 👍

[oyooyo]

@oyooyo Ich habe bei mir die UpdateServices Funktion in simble angepasst (try catch Block). Seit dem sind die Cannot read property 'services' of null Fehler behoben. Vll könnte man an dieser Stelle überprüfen ob Services gefunden wurden und wenn nicht einfach nochmal suchen.

Früher oder später will ich simble eigentlich eh ausmustern, weil noble mittlerweile von Haus aus Javascript Promises bzw. async/await unterstützt, und der Hauptgrund für die Verwendung von simble damit weggefallen ist.

Aber bis es soweit ist, sollte ich den Fehler in simble beheben. Kannst Du mir etwas ausführlicher schreiben, was genau Du in welcher Zeile verändert hast? Oder alternativ direkt einen entsprechenden PR einreichen?

[frodo777]

@oyooyo ich kann mich nicht komplett am Schloss registrieren Setting user name to "Schloss"... da bleib ich stehen und es passiert nichts mehr

[oyooyo]

@frodo777 Dieses Problem ist bekannt, aber noch nicht gefixt. Es betrifft allerdings auch nur das Setzen des Benutzernamens. Der Benutzer an sich sollte an dieser Stelle bereits registriert sein: vor dieser Fehlermeldung sollte bereits die User-ID und der User-Key angezeigt worden sein. Als temporären Workaround kann man den Benutzernamen des neu registrierten Benutzers stattdessen über die Benutzerverwaltung der Smartphone-App verändern. Der Benutzername ist m.W.n. aber eh nur relevant, wenn man sich über die App das Aktivitäts-Log anschaut.

[frodo777]

@oyooyo Ok ich habe mal die keyble-sendcommand Befehle Versucht und siehe da das Schloss bewegt sich (sehr schön). Mein Fehler war wohl das ich den Adapter in iobroker zum Steuern benutzt habe. Der scheint bei mir nicht zu funktionieren. Der Adapter verbindet sich und wird auch grün nur bedienen lässt sich das Schloss nicht und der Status wird auch nicht aktualisiert. Mein iobroker läuft auf einen Raspi 4 und keyble läuft auf einem Raspi 3 . Gibt es eine Möglichkeit Dir eine kleine Spende zukommen zu lassen für die viele Arbeit? Ich freue mich das die Software noch weiterentwickelt wird , hatte mein Schloss jetzt ein Jahr nicht mehr in Gebrauch wegen der Nodejs Version. Wie bekomme ich die Befehle von dem einen Raspi zum Anderen. Am besten vom iobroker. Hast Du da einen Tipp für mich

[oyooyo]

@frodo777 Zu ioBroker kann ich leider wenig sagen, da ich es nicht verwende und lediglich mal ganz kurz installiert hatte, um mich an einem Adapter für keyble zu versuchen, weil das irgendwer angefragt hatte. Bin aber nicht weit gekommen, und habe die Arbeit daran mangels Eigeninteresse kurz darauf auch schon wieder eingestellt. Was grundsätzlich irgendwie funktionieren dürfte: Dass Du den Türschlossantrieb über MQTT steuerst (wie z.B. hier beschrieben). Gibt in ioBroker ja bestimmt irgendeinen allgemeinen MQTT-Adapter. Aber das ist halt schon umständlich und keine sonderlich schöne Lösung. Etwas besseres fällt mir auf Anhieb aber leider auch nicht ein, dazu müsste ich ioBroker besser kennen.

Wenn die neue keyble-Version erst einmal fertig ist und stabil läuft, werde ich vielleicht selbst noch ein paar "Adapter" entwickeln, um es deutlich einfach zu machen, keyble per MQTT, Node Red, ioBroker o.Ä. zu steuern, mal schauen.

Dass Du mir eine kleine Spende zukommen lassen willst, hat mich fast ein wenig gerührt. Ist aber wirklich nicht nötig, trotzdem habe ich mich über die durch das Angebot ausgedrückte Wertschätzung sehr gefreut, vielen Dank!