Software zum Steuern des Türschlossantrieb "eqiva eQ-3 Bluetooth Smart Lock"

Hier noch ein etwas ausführlichere Erklärung zum zentralen Tool 
"keyble-sendcommand".

keyble-sendcommand kann in zweierlei Form benutzt werden:

1. Als einmaliges Kommando, das nur kurz den gewünschten Befehl 
(öffen/abschliessen/aufschliessen) sendet und sich danach sofort wieder 
beendet.

Dazu übergibt man das auszuführende Kommando direkt auf der 
Kommandozeile über den --command/-c Parameter:

1

$ keyble-sendcommand --address 01:23:56:67:89:ab --user_id 1 --user_key ca78ad9b96131414359e5e7cecfd7f9e --command open

2. Als eine Art "Filter", der beliebig viele auszuführende Kommandos als 
Eingabezeilen von der Standard-Eingabe einliest, und so lange ausgeführt 
wird, wie der Standard-Eingabe-Stream geöffnet ist.

Dieser Modus soll es ermöglichen, den Türschlossantrieb durch die 
Ausgabe eines anderen Programms zu steuern, das per "Pipe" mit 
keyble-sendcommand verknüpft wird.

Weil das mglw. etwas abstrakt klingt, nachfolgend ein Beispiel. Das 
Programm "mosquitto_sub" aus den "mosquitto-clients" ermöglicht es, auf 
eine bestimmte MQTT-Topic zu subscriben, und alle auf dieser Topic 
eingehenden Nachrichten auszugeben.

1

$ mosquitto_sub -h 192.168.0.2 -t "door_lock/action" | keyble-sendcommand -a 01:23:56:67:89:ab -u 1 -k ca78ad9b96131414359e5e7cecfd7f9e

Obige Kommandozeile geht davon aus, dass es einen MQTT-Broker mit der IP 
192.168.0.2 gibt, und dass der Türschlossantrieb über die MQTT-Topic 
"door_lock/action" gesteuert werden soll.
Wird nun "open", "lock" oder "unlock" an diese MQTT-Topic gesendet, so 
sollte kurz darauf der Türschlossantrieb die entsprechende Aktion 
ausführen.

(Leider steckt genau hier allerdings noch ein Bug, wie ich erst nach dem 
Veröffentlichen festgestellt habe - bislang funktioniert das nur beim 
ersten Mal. In den nächsten Tagen sollte dieser Bug hoffentlich behoben 
werden)

Sogar vor dem Zeitplan ;)

Schaue ich mir heute Abend gleich an. Bin sehr gespannt!

:)

Hallo Joachim,

etwas später als von mir geplant, aber besser als nie. Lag etwas daran, 
dass ich anscheinend zu blöd bin, den npm zu bedienen. Nachdem ich dann 
endlich alle Pakete, die erforderlich waren installiert habe, (ms und 
bluetooth-hci-socket hatte er aus irgendeinem Grund nicht automatisch in 
den "node_modules" mitinstalliert) konnte ich die Scripte ausführen.

Bei der Einrichtung (keyble-registeruser) und auch im späteren Verlauf 
(keyble-sendcommand) ist mir ein Fehler aufgefallen, den ich bisher 
nicht reproduzieren konnte: Wenn man ein Kommando gesendet hat kam z.B. 
'Sending command "lock"' und es passierte nichts. Ich habe noch nicht im 
Code nachgesehen - wollte erstmal ein erste Feedback geben. Nachdem ich 
das ganze dann ein oder zwei mal wiederholt habe ging es dann - bis 
jetzt.

An dieser Stelle: Super Arbeit bisher und auch ganz prima zu bedienen. 
Vorausgesetzt man kennt sich etwas mit Nodejs und dem npm aus... ;-)

Schönen Abend!

Hallo Andre,

> Lag etwas daran, dass ich anscheinend
> zu blöd bin, den npm zu bedienen. Nachdem ich dann endlich alle Pakete,
> die erforderlich waren installiert habe, (ms und bluetooth-hci-socket
> hatte er aus irgendeinem Grund nicht automatisch in den "node_modules"
> mitinstalliert) konnte ich die Scripte ausführen.

Interessant, dieses Problem ist bei mir nicht aufgetreten. Kann mir 
momentan allerdings auch keinen Reim darauf machen, woran das gelegen 
haben könnte.
Daher wäre es nett von Dir, wenn Du mir sagen könntest,
- welches Betriebssystem
- welche Version von Node.js und
- welche Version von npm
Du benutzt. Vielleicht kann man auf die Weise dahinter kommen, wo da 
genau das Problem steckt, z.B. falls noch Andere das gleiche Problem 
haben.

> Bei der Einrichtung (keyble-registeruser) und auch im späteren Verlauf
> (keyble-sendcommand) ist mir ein Fehler aufgefallen, den ich bisher
> nicht reproduzieren konnte: Wenn man ein Kommando gesendet hat kam z.B.
> 'Sending command "lock"' und es passierte nichts. Ich habe noch nicht im
> Code nachgesehen - wollte erstmal ein erste Feedback geben. Nachdem ich
> das ganze dann ein oder zwei mal wiederholt habe ging es dann - bis
> jetzt.

Die Tools sind leider bislang wirklich so programmiert, dass sie mehr 
oder weniger einfach davon ausgehen, dass schon alles funktionieren 
wird. Wenn dem nicht der Fall ist, ist es bislang leider wirklich 
wahrscheinlich, dass dann einfach gar keine, oder keine hilfreiche 
Fehlermeldung kommt. :-(

So tendenziell würde ich vermuten, dass da irgendwie der 
Bluetooth-Verbindungsaufbau nicht geklappt hat. Habe z.B. festgestellt, 
dass offenbar immer nur ein Gerät verbunden sein kann - falls man also 
parallel gerade auf dem Smartphone die Hersteller-App offen hat, kann 
sich die PC-Software nicht verbinden und anders herum...

Was man übrigens machen kann:
vor dem eigentlichen Kommando "DEBUG=keyble:*" schreiben, also z.B.

1

$ DEBUG=keyble:* keyble-sendcommand --address 01:23:56:67:89:ab --user_id 1 --user_key ca78ad9b96131414359e5e7cecfd7f9e --command open

oder, falls man auch Debug-Ausgaben aller von keyble verwendeten 
Abhängigkeiten sehen will, "DEBUG=*"

Allerdings ist fraglich, ob das in diesem Fall irgendetwas etwas 
gebracht hätte, um das von Dir beschriebene Problem zu lokalisieren - 
bislang ist das fast nur hilfreich um zu sehen was an Daten 
gesendet/empfangen wird.

> An dieser Stelle: Super Arbeit bisher und auch ganz prima zu bedienen.

Danke :)

Interessehalber noch ne kleine Umfrage: Welche Features vermisst Du 
noch, bzw. würdest Du sehr begrüssen, die z.B. gegenüber der 
Smartphone-App noch fehlen?

Ansonsten: Vielen Dank für das wertvolle Feedback!

Joachim S. schrieb:

> Daher wäre es nett von Dir, wenn Du mir sagen könntest,
> - welches Betriebssystem
> - welche Version von Node.js und
> - welche Version von npm

Ich nutze einen NanoPi (Duo) mit Ubuntu 16.04.5 LTS
Node.js v8.11.4
npm Version 5.6.0

Ist aber wie gesagt auch mehr oder weniger eine Premiere meinerseits 
gewesen. Sicherlich habe ich etwas falsch gemacht...


> Was man übrigens machen kann:
> vor dem eigentlichen Kommando "DEBUG=keyble:*" schreiben, also z.B.
>
>

1

> $ DEBUG=keyble:* keyble-sendcommand --address 01:23:56:67:89:ab 

2

> --user_id 1 --user_key ca78ad9b96131414359e5e7cecfd7f9e --command open

3

>

>
> oder, falls man auch Debug-Ausgaben aller von keyble verwendeten
> Abhängigkeiten sehen will, "DEBUG=*"

Interessanter Hinweis! Das probiere ich gleich mal...

> Interessehalber noch ne kleine Umfrage: Welche Features vermisst Du
> noch, bzw. würdest Du sehr begrüssen, die z.B. gegenüber der
> Smartphone-App noch fehlen?

Es wäre top, wenn es noch eine Möglichkeit gäbe den aktuellen Zustand 
(geöffnet/geschlossen) abzufragen. Es gibt ja auch die Möglichkeit das 
Schloss per Hand zu schließen oder auf die Taster am Antrieb zu drücken. 
Gerade in Bezug auf MQTT wäre das ein muss. So würde der korrekte Status 
im Falle des Falles publisht - bislang könnte man sich ja nur merken, 
was man selbst geschickt hat.

Andre J. schrieb:
> Ich nutze einen NanoPi (Duo) mit Ubuntu 16.04.5 LTS
> Node.js v8.11.4
> npm Version 5.6.0

Ok, Danke für die Info.

> Ist aber wie gesagt auch mehr oder weniger eine Premiere meinerseits
> gewesen. Sicherlich habe ich etwas falsch gemacht...

Neee, das glaube ich nicht gar nicht mal. "noble", die von keyble 
benutzte Bluetooth LE-Library, ist zwar grundsätzlich super, hat aber 
seinerseits zahllose Abhängigkeiten, und beim Installieren treten häufig 
irgendwelche Probleme auf, wie man im Issue-Tracker auf GitHub sieht. 
Selbst wenn ich noble erfolgreich installiere, werden während der 
Installation via npm zahlreiche Fehler angezeigt.

> Es wäre top, wenn es noch eine Möglichkeit gäbe den aktuellen Zustand
> (geöffnet/geschlossen) abzufragen. Es gibt ja auch die Möglichkeit das
> Schloss per Hand zu schließen oder auf die Taster am Antrieb zu drücken.
> Gerade in Bezug auf MQTT wäre das ein muss. So würde der korrekte Status
> im Falle des Falles publisht - bislang könnte man sich ja nur merken,
> was man selbst geschickt hat.

Stimmt, das wäre eine wichtiges Feature. Gute Idee.

Potentielles Problem, das ich dabei allerdings sehe: Am besten wäre ja, 
wenn  das Tool sofort mitbekommen würde, wenn sich etwas am Zustand 
verändert, und das dann bspw. direkt via MQTT publishen würde.
Dafür müsste die Software allerdings dauerhaft mit dem Türschlossantrieb 
via Bluetooth verbunden sein - und das würde erstens den 
Batterieverbrauch des Türschlossantriebs in die Höhe treiben, und 
zweitens könnte sich dann kein anderes Gerät mehr mit dem 
Türschlossantrieb verbinden, man könnte also bspw. auch die 
Smartphone-App nicht mehr benutzen.

Eigentlich könnte man es also nur so lösen, dass sich das Tool in 
einstellbaren Zeitabständen (z.B. alle 5 Minuten) regelmässig kurz mit 
dem Schloss verbindet, den aktuellen Zustand abfragt, und die Verbindung 
dann sofort wieder trennt...

Joachim S. schrieb:

> Eigentlich könnte man es also nur so lösen, dass sich das Tool in
> einstellbaren Zeitabständen (z.B. alle 5 Minuten) regelmässig kurz mit
> dem Schloss verbindet, den aktuellen Zustand abfragt, und die Verbindung
> dann sofort wieder trennt...

So hätte ich es auch gedacht. Das schlimmste/nervigste wäre bestimmt der 
Batterieverbrauch!

Das gestern beschriebene Problem hat mich heute Nacht übrigens nicht in 
Ruhe gelassen. So habe ich dahingehend noch etwas weiter geforscht und 
kann folgende Neuigkeiten geben:

Um Aktionen auszuführen habe ich beide Methoden der 
keyble-sendcommand-Funktion (die continuous-Variante ohne Übergabe des 
"-c"-Parameters und die einmalige mit der übergabe von "-c 
lock/unlock...") genutzt.

Bei der 1. Variante habe ich festgestellt, dass nur die erste Aktion 
ausgeführt wird (aber auch nicht immer). Aber mit ziemlicher Sicherheit 
die zweite und jede folgende nicht (es steht dann nur "Sending..." aber 
nicht "Command ... sent"). Ich habe mir dann einige Ausgaben in den Code 
eingefügt, um zu sehen, wo das Programm nicht weiter kommt. Es scheint 
hier so zu sein, dass (in keyble.js)

1

ensure_connected() {

2

//...

3

simble.scan_for_peripheral(simble.filter.address(this.address))

4

//...

kein gültiges Element zurück gibt. Folglich auch nichts weiter passieren 
kann. Tiefer betrachtet übrigens in simble.js

1

scan_for_peripheral = function(peripheral_filter) {

2

//...

3

noble.on('stateChange', function(state) {

4

if (state === 'poweredOn') {

5

//...

NICHT zutrifft (state = 0). Vielleicht wird die letzte Verbindung nicht 
richtig beendet?

Bei der 2. Variante habe ich festgestellt, dass häufig das erstmalige 
Senden eines Kommandos nichts bewirkt. Sobald ich allerdings den befehl 
ein zweites Mal absende, klappt es...

Soweit zu den Erkenntnissen - bei Dir ist das wahrscheinlich nicht so? 
Es kann natürlich auch noch an meiner Hardware liegen. Ich nutze einen 
USB Bluetooth 4.0 Dongle (Rocketek USB Bluetooth 4.0 Low Energy USB 
Adapter) von Amazon (laut lsusb ProductID steckt ein CSR8510 A10 drin, 
den es lt. Google auch bei anderen Anbietern geben soll).

Ich werde natürlich weiter forschen. Da ich allerdings auch mit Node.js 
erstmal warm werden muss, sind meine Möglichkeiten beschränkt.

Unter Debian Stretch und Node 10 läuft das noch nicht?
Oder sitzt das Problem wie immer vorm Bildschirm?

Andre J. schrieb:
> Joachim S. schrieb:
>
>> Eigentlich könnte man es also nur so lösen, dass sich das Tool in
>> einstellbaren Zeitabständen (z.B. alle 5 Minuten) regelmässig kurz mit
>> dem Schloss verbindet, den aktuellen Zustand abfragt, und die Verbindung
>> dann sofort wieder trennt...
>
> So hätte ich es auch gedacht. Das schlimmste/nervigste wäre bestimmt der
> Batterieverbrauch!

Okay, also der erste Ansatz, der mir instinktiv einfällt wie man das 
umsetzen könnte, wäre folgender:
keyble-sendcommand kann bei Verwendung in der "Continuous-Variante" ein 
Parameter a la "--status_refresh_time" übergeben werden, durch den man 
einstellen kann, alle wieviele Sekunden er den Status aktualisieren soll 
(und sich, falls dazu nötig, vorher mit dem Smart Lock verbinden). 
Zusätzlich vielleicht noch ein Parameter, durch den man festlegt, nach 
wieviel Sekunden Inaktivität keyble eine bestehende Verbindung trennen 
soll.

Weiterhin gibt keyble-sendcommand nur noch beim Feststellen von 
Status-Änderungen etwas aus, und zwar ausschliesslich den letzten Status 
("locked","unlocked","opened").

Auf diese Weise könnte man dann z.B. eine Pipeline ähnlich der folgenden 
bauen:

1

$ mosquitto_sub -t "door_lock/action" | keyble-sendcommand | mosquitto_pub -t "door_lock/status" -l -r

Mit dieser Befehlszeile könnte man gleichzeitig über Nachrichten an die 
MQTT-Topic "door_lock/action" den Türschlossantrieb steuern, während die 
MQTT-Topic "door_lock/status" den aktuellen Zustand der 
Türschlossantriebs als retained-Nachricht wiedergeben/speichern würde.

Was hältst Du davon? Gut, oder fällt Dir ein besserer Vorschlag ein?

> Das gestern beschriebene Problem hat mich heute Nacht übrigens nicht in
> Ruhe gelassen. So habe ich dahingehend noch etwas weiter geforscht und
> kann folgende Neuigkeiten geben:
>
> Um Aktionen auszuführen habe ich beide Methoden der
> keyble-sendcommand-Funktion (die continuous-Variante ohne Übergabe des
> "-c"-Parameters und die einmalige mit der übergabe von "-c
> lock/unlock...") genutzt.
>
> Bei der 1. Variante habe ich festgestellt, dass nur die erste Aktion
> ausgeführt wird (aber auch nicht immer). Aber mit ziemlicher Sicherheit
> die zweite und jede folgende nicht (es steht dann nur "Sending..." aber
> nicht "Command ... sent").

Genau dieses Problem ist mir direkt nach dem Veröffentlichen auch 
aufgefallen. Steht momentan ganz oben auf der Prioritäten-Liste, aber 
bislang hatte ich mich noch nicht damit beschäftigt, das 
zugrundeliegende Problem zu suchen.

Von daher...

> Ich habe mir dann einige Ausgaben in den Code
> eingefügt, um zu sehen, wo das Programm nicht weiter kommt. Es scheint
> hier so zu sein, dass (in keyble.js)
>
>

1

> ensure_connected() {

2

> //...

3

> simble.scan_for_peripheral(simble.filter.address(this.address))

4

> //...

5

>

>
> kein gültiges Element zurück gibt. Folglich auch nichts weiter passieren
> kann. Tiefer betrachtet übrigens in simble.js
>
>

1

> scan_for_peripheral = function(peripheral_filter) {

2

> //...

3

> noble.on('stateChange', function(state) {

4

> if (state === 'poweredOn') {

5

> //...

6

>

>
> NICHT zutrifft (state = 0). Vielleicht wird die letzte Verbindung nicht
> richtig beendet?

...vielen Dank, das Du das gleich für mich übernommen hast! :-)

Klingt für mich im ersten Moment absolut plausibel, dass das Problem mit 
dieser "poweredOn"-Abfrage zu tun hat, dass die nur beim ersten Mal 
funktioniert, weil es nur direkt beim Start ein "stateChange"-Event 
gibt. Werde ich spätestens morgen fixen.

> Bei der 2. Variante habe ich festgestellt, dass häufig das erstmalige
> Senden eines Kommandos nichts bewirkt. Sobald ich allerdings den befehl
> ein zweites Mal absende, klappt es...

Da kann ich mir auf Anhieb jetzt noch keinen Reim drauf machen.

> Soweit zu den Erkenntnissen - bei Dir ist das wahrscheinlich nicht so?

Also beim letztgenannten Problem könnte ich mich jetzt zumindest nicht 
erinnern, dass ich das schon mal gehabt hätte - aber das muss nix 
heissen.

Evtl. könnte es da wirklich helfen, das Programm mal mit "DEBUG=*"  zu 
starten, und wenn es nicht funktioniert, dann mal das Ende des 
Bluetooth-Logs anzuschauen, wo er da gerade hängt.

> Es kann natürlich auch noch an meiner Hardware liegen. Ich nutze einen
> USB Bluetooth 4.0 Dongle (Rocketek USB Bluetooth 4.0 Low Energy USB
> Adapter) von Amazon (laut lsusb ProductID steckt ein CSR8510 A10 drin,
> den es lt. Google auch bei anderen Anbietern geben soll).

Habe eben mal nachgeschaut - mein Bluetooth-Dongle verwendet exakt den 
gleichen CSR8510 A10. Eher unwahrscheinlich, dass es daran liegt, dürfte 
eher ein Software-Problem sein.

> Ich werde natürlich weiter forschen. Da ich allerdings auch mit Node.js
> erstmal warm werden muss, sind meine Möglichkeiten beschränkt.

Och, Du hast wie es scheint ja sofort auf Anhieb den Fehler lokalisiert 
- alleine dafür schon mal Danke und Hut ab! :-)

Jörg E. schrieb:
> Unter Debian Stretch und Node 10 läuft das noch nicht?

Ich selbst habe es bislang nur unter Ubuntu 18.04 mit Node 8 getestet. 
Nur allzu gut möglich, dass es unter anderen Betriebssystem und 
Node-Versionen noch Probleme gibt.

Ich wollte es am Wochenende mal auf einem Raspberry Pi 3+ ausprobieren, 
weil mir das als die naheliegendste Plattform erscheint. Dann werde ich 
auch mal gezielt Node 10 ausprobieren, würde instinktiv tippen dass es 
damit zu tun hat.

EDIT: Scheint ein bereits bekanntes Problem zu sein, dass tatsächlich 
mit Node 10 zu tun hat. Hier beschrieben:
https://github.com/noble/noble/issues/805
aber der eigentliche Fehler scheint hier zu liegen:
https://github.com/noble/node-bluetooth-hci-socket/issues/84

Es gibt offenbar bereits einen Patch/PR für das Problem, aber der 
Maintainer von node-bluetooth-hci-socket hat ihn offenbar noch nicht 
integriert. :-(

Ich probier es mal mit Node 9

Jörg E. schrieb:
> Ich probier es mal mit Node 9

Habe es auch am Anfang mit Node 10 probiert. Hat bei mir auch nicht 
geklappt! Kann jetzt aber auch nicht mehr genau sagen, woran es lag. Ich 
glaube eine Funktion war deprecated...

Joachim S. schrieb:

> Was hältst Du davon? Gut, oder fällt Dir ein besserer Vorschlag ein?

Das ist gut so. Man könnte es sicherlich nur noch verfeinern, indem man 
(ich weiß nicht ob es sowas für Node.js gibt) eine mqtt-library 
includet, die dann die Kommunikation direkt weiter gibt. Das würde einem 
das ewig lange Kommando ersparen. Zugangsdaten (in Datei) ablegen und 
alles wird publisht.

> ...vielen Dank, das Du das gleich für mich übernommen hast! :-)

Kein Problem. Ich weiß aber wie gesagt nicht, wie repräsentativ das ist. 
Ich bin dann noch Mal weiter eingestiegen bis in die noble-lib. Dort 
habe ich festgestellt, dass das "onStateChange"-Event nicht gefeuert 
wird. Das habe ich kurzer Hand gegoogelt und einige weitere mit dem 
selben Problem gefunden. Aber leider nichts wirklich hilfreiches.

> Evtl. könnte es da wirklich helfen, das Programm mal mit "DEBUG=*"  zu
> starten, und wenn es nicht funktioniert, dann mal das Ende des
> Bluetooth-Logs anzuschauen, wo er da gerade hängt.

Habe ich probiert. Bislang bekomme ich da nur Ausgaben, wenn auch die 
Kommunikation klappt (man am keyble angemeldet ist). Das scheint ja in 
den meisten Fällen bei mir nicht zu gehen.

> Habe eben mal nachgeschaut - mein Bluetooth-Dongle verwendet exakt den
> gleichen CSR8510 A10. Eher unwahrscheinlich, dass es daran liegt, dürfte
> eher ein Software-Problem sein.

Das ist schon Mal gut zu wissen! Ich schaue Mal, dass ich es auch noch 
schaffe weiter zu bohren.

Joachim S. schrieb:

> Klingt für mich im ersten Moment absolut plausibel, dass das Problem mit
> dieser "poweredOn"-Abfrage zu tun hat, dass die nur beim ersten Mal
> funktioniert, weil es nur direkt beim Start ein "stateChange"-Event
> gibt. Werde ich spätestens morgen fixen.

Sorry, gerade gesehen. Das habe ich überlesen... Dann sieht das ja gut 
aus, dass es daran liegt.

Andre J. schrieb:
> Joachim S. schrieb:
>
>> Was hältst Du davon? Gut, oder fällt Dir ein besserer Vorschlag ein?
>
> Das ist gut so. Man könnte es sicherlich nur noch verfeinern, indem man
> (ich weiß nicht ob es sowas für Node.js gibt) eine mqtt-library
> includet, die dann die Kommunikation direkt weiter gibt. Das würde einem
> das ewig lange Kommando ersparen. Zugangsdaten (in Datei) ablegen und
> alles wird publisht.

MQTT-Unterstützung direkt einzubauen wäre zwar kein Problem - aber 
solange es keinen zwingenden Grund dafür gibt, bevorzuge ich 
grundsätzlich den Ansatz, sich gar nicht erst auf ein bestimmtes 
Kommunikationsprotokoll festzulegen, sondern der "UNIX-Philosophie" 
gemäss nur über STDIN und STDOUT zu kommunizieren, und die eigentliche 
Kommunikation ein anderes Programm übernehmen zu lassen.

Das ewig lange Kommando sehe ich jetzt eher nicht als Problem - im 
"Regelbetrieb" würde man das ja eh nicht jedes Mal neu eintippen, 
sondern einmalig in einem BASH-Script o.Ä. eintragen, welches beim 
Booten automatisch gestartet wird.

>> ...vielen Dank, das Du das gleich für mich übernommen hast! :-)
>
> Kein Problem. Ich weiß aber wie gesagt nicht, wie repräsentativ das ist.
> Ich bin dann noch Mal weiter eingestiegen bis in die noble-lib. Dort
> habe ich festgestellt, dass das "onStateChange"-Event nicht gefeuert
> wird. Das habe ich kurzer Hand gegoogelt und einige weitere mit dem
> selben Problem gefunden. Aber leider nichts wirklich hilfreiches.
>> Klingt für mich im ersten Moment absolut plausibel, dass das Problem mit
>> dieser "poweredOn"-Abfrage zu tun hat, dass die nur beim ersten Mal
>> funktioniert, weil es nur direkt beim Start ein "stateChange"-Event
>> gibt. Werde ich spätestens morgen fixen.
>
> Sorry, gerade gesehen. Das habe ich überlesen... Dann sieht das ja gut
> aus, dass es daran liegt.

Das von Dir festgestellte Problem mit dem onStateChange-Event habe ich 
am Wochenende übrigens gefixt (glaube ich zumindest) - allerdings zeigte 
sich, dass das scheinbar nicht das einzige Problem war. :-(
Ich hoffe heute noch dazu zu kommen, das zu fixen.

Habe eben Version 0.1.13 veröffentlicht, in der das Problem mit dem 
"Filter-" bzw "Continuous-" Mode behoben sein sollte.

Zum updaten:

1

sudo npm install --update -g --unsafe-perm keyble

Joachim S. schrieb:

> solange es keinen zwingenden Grund dafür gibt, bevorzuge ich
> grundsätzlich den Ansatz, sich gar nicht erst auf ein bestimmtes
> Kommunikationsprotokoll festzulegen, sondern der "UNIX-Philosophie"
> gemäss nur über STDIN und STDOUT zu kommunizieren, und die eigentliche
> Kommunikation ein anderes Programm übernehmen zu lassen.

Berechtigte Strategie. War ja im Prinzip auch nur ein weiterer 
Vorschlag.

> allerdings zeigte
> sich, dass das scheinbar nicht das einzige Problem war. :-(
> Ich hoffe heute noch dazu zu kommen, das zu fixen.

Joachim S. schrieb:
> Habe eben Version 0.1.13 veröffentlicht, in der das Problem mit dem
> "Filter-" bzw "Continuous-" Mode behoben sein sollte.

Sind damit auch die Fehler gemeint, die du beim fixen des 
onStateChange-Fehlers gefunden hast? Oder kann ich noch was helfen? 
Bislang sieht es bei mir gut aus... :-)

Andre J. schrieb:
> Joachim S. schrieb:
>> Habe eben Version 0.1.13 veröffentlicht, in der das Problem mit dem
>> "Filter-" bzw "Continuous-" Mode behoben sein sollte.
>
> Sind damit auch die Fehler gemeint, die du beim fixen des
> onStateChange-Fehlers gefunden hast? Oder kann ich noch was helfen?
> Bislang sieht es bei mir gut aus... :-)

Es sollten alle Fehler behoben sein, die ein Wieder-Verbinden mit dem 
Türschlossantrieb (nach einem Trennen der Verbindung) verhindert haben. 
Das war zum einen das von Dir gefundene Problem mit dem 
onStateChange-Event; wie ich dann festgestellt habe, gab es aber noch 
1-2 andere Problem, die das verhindert haben.

Und noch ein kleiner Hinweis, weil es mglw. Jemanden interessieren 
könnte:
Ich habe eben noch ein weiteres Tool veröffentlicht, das quasi genauso 
wie keyble funktioniert, aber für das eQ-3 eqiva Bluetooth Smart 
Heizkörperthermostat 
(https://www.eq-3.de/produkte/eqiva/bluetooth-smart-heizkoerperthermostat.html) 
des gleichen Herstellers gedacht ist, das bei einem Preis von ca. 16 
Euro ebenfalls ein absolutes Schnäppchen ist (meines Wissens nach das 
günstigste per Bluetooth steuerbare Heizkörper-Thermostat am Markt).

https://github.com/oyooyo/nixfilter-rtble

Auch dieses Tool ist dazu gedacht, als Teil einer "Pipeline" verwendet 
zu werden, z.B. folgendermassen:

1

$ mosquitto_sub -t "thermostat/temperature/set" | nixfilter-rtble-temperature --status_update_time 300 | mosquitto_pub -l -r -t "thermostat/temperature"

Mit obigem Befehl kann man die Ziel-Temperatur des 
Heizkörper-Thermostats einstellen, indem man eine Nachricht mit der 
Temperatur (z.B. "23.5") an die MQTT-Topic "thermostat/temperature/set" 
sendet. Die eingestellte Zieltemperatur wird als retained-Nachricht auf 
die Topic "thermostat/temperature" gepublisht; manuelle Änderungen 
direkt am Gerät werden dabei ebenfalls erfasst und gepublisht, indem 
alle 300 Sekunden der Status abgefragt wird.

Hallo,

erst einmal vielen Dank für die bereits geleistete Arbeit! Das erspart 
mir so einiges an Arbeit und auch Geld, da ich nicht auf einen teuren 
Nuki angewiesen bin.

Funktionen die für mich wirklich noch sehr interessant wären, wäre das 
auslesen des Status und das auslesen der Historie, also wer hat die Tür 
wann geöffnet (falls das möglich ist und nicht nur in der App passiert).

Kann man dich bei diesen Projekt noch irgendwie unterstützen?

Gruß,
Markus

Hallo Markus,

Markus B. schrieb:
> Funktionen die für mich wirklich noch sehr interessant wären, wäre das
> auslesen des Status und das auslesen der Historie, also wer hat die Tür
> wann geöffnet (falls das möglich ist und nicht nur in der App passiert).

Beides wäre grundsätzlich durchaus möglich, auch die Historie wird im 
Smartlock gespeichert und kann abgefragt werden.

Was das Abfragen des aktuellen Status betrifft:
Die typische Art und Weise das Kommandozeilen-Tool zu benutzen sehe ich 
ja darin, dass die Kommandos per MQTT empfangen werden und der aktuelle 
Zustand des Türschlossantriebs ebenfalls per MQTT versendet wird, als 
"Retained"-Nachricht. Um den aktuellen Status des Türschlossantriebs 
abzufragen würde es in diesem Szenario im Grunde genügen, kurz die 
MQTT-Topic abzufragen, auf die die Status-Meldungen geschickt werden.

Momentan ist das allerdings nur bedingt möglich, weil bspw. ein 
manuelles Öffnen des Türschlosses derzeit noch nicht erfasst werden 
würde. Was das betrifft, so plane ich, das so wie bei meiner Software 
für das eqiva-Heizungsthermostat zu lösen, dass sich die Software in 
einstellbaren Zeitabständen automatisch kurz mit dem Türschlossantrieb 
verbindet und den aktuellen Status abfragt/ausgibt.

Ein solches Feature ist bereits geplant, mglw. würde Dir das ja bereits 
genügen?

Was das Abfragen der Historie betrifft: Momentan plane ich nicht, das zu 
implementieren. Das ist zwar definitiv ein nützliches Feature, aber da 
es bislang jetzt nicht sooo viel Interesse an der Software gibt und ich 
selbst auf dieses Feature verzichten kann, plane ich vorerst nicht, 
das zu implementieren.

Hallo

die Möglichkeit den Status über die Kommando-Zeile, dh über MQTT 
abzufragen ist genau das was ich mir vorgestellt habe, allerdings wäre 
mir ein reines "retained" zu wenig, da eben, wie du schon erwähnt hast, 
ein manuelles Öffnen der Tür nicht erfasst wird.

Ich würde das Intervall auch nicht in der Software verwalten sondern 
extern, alle externen Lösungen wie ioBroker oder FHEM bieten hier schon 
alles an um nach einen Zeitinterval eine MQTT-Message zu schicken.

DIe Historie ist schade aber kann ich nachvollziehen, eventuell ist es 
ja möglich es selbst noch zu implementieren.

Gruß,
Markus

Markus B. schrieb:
> die Möglichkeit den Status über die Kommando-Zeile, dh über MQTT
> abzufragen ist genau das was ich mir vorgestellt habe, allerdings wäre
> mir ein reines "retained" zu wenig, da eben, wie du schon erwähnt hast,
> ein manuelles Öffnen der Tür nicht erfasst wird.

Wenn das geplante "automatische Status-Abfrage alle soundsoviel 
Sekunden" implementiert ist, würde manuelles Öffnen/Schliessen wie 
gesagt eh erfasst und dann auch in MQTT reflektiert werden.

> Ich würde das Intervall auch nicht in der Software verwalten sondern
> extern, alle externen Lösungen wie ioBroker oder FHEM bieten hier schon
> alles an um nach einen Zeitinterval eine MQTT-Message zu schicken.

Wenn ich dich richtig verstehe, bist Du also gegen eine automatische 
Status-Abfrage in regelmässigen Intervallen, und bist stattdessen quasi 
für ein manuelles Triggern der Status-Abfrage durch ein Signal von 
aussen (wie z.B. eine entsprechende MQTT-Nachricht)?
Falls ja, so ist mir gerade nicht ganz klar, welchen potentiellen 
Vorteil Du darin siehst - kannst Du das kurz erklären?

p.s., kleiner Tipp für Interessenten: Bei Amazon kostet der 
Türschlossantrieb derzeit nur 40 Euro - ein absolutes Schnäppchen, sonst 
zahlt man überall mindestens 20 Euro mehr.

Hallo!

Vorab, super Lösung!

Ich setzte zur Zeit 4 Schlossantriebe bei mir ein und steuere diese über 
ein altes Android Telefon via Tasker. Dieses melden über UDP den Status 
der Antriebe an eine Loxone Hausautomation, von welcher auch die 
Schlösser geöffnet/verschlossen/abgefragt werden können. Mein Ansatz 
läuft allerdings nicht sehr zuverlässig.

Ich überlege nun ob ein Pi Zero W mit deinen Programmen nicht einen 
besseren Dienst erweisen könnte.
Ist es zur Zeit schon möglich mehrere Antriebe anzusteuern?

Auch gingen meine Gedanken in die Richtung eines ESP32, mit diesem oder 
einem Pi Zero könnte man ja einen Art Bridge BT zu WiFi aufbauen, 
ähnlich der Nuki Bridge.

Schönen Gruß
Thomas

Thomas F. schrieb:

> Ich überlege nun ob ein Pi Zero W mit deinen Programmen nicht einen
> besseren Dienst erweisen könnte.
> Ist es zur Zeit schon möglich mehrere Antriebe anzusteuern?

Du übergibst bei dem Aufruf der Funktion zur Kontrolle der Öffnen- und 
Schließoperation die ID des Antriebs, den du ansprechen willst. Mit 
einem Befehl für jeden Antrieb kannst du natürlich mehrere Antriebe 
bedienen.

Nicht getestet (habe nur einen) aber sollte (natürlich) funktionieren 
:-)

Andre J. schrieb:
> Thomas F. schrieb:
>
>> Ich überlege nun ob ein Pi Zero W mit deinen Programmen nicht einen
>> besseren Dienst erweisen könnte.
>> Ist es zur Zeit schon möglich mehrere Antriebe anzusteuern?
>
> Du übergibst bei dem Aufruf der Funktion zur Kontrolle der Öffnen- und
> Schließoperation die ID des Antriebs, den du ansprechen willst. Mit
> einem Befehl für jeden Antrieb kannst du natürlich mehrere Antriebe
> bedienen.
>
> Nicht getestet (habe nur einen) aber sollte (natürlich) funktionieren
> :-)

So würde ich das auch einschätzen. Grundsätzlich spricht da nichts 
dagegen, aber man müsste halt vier Instanzen des Programms parallel 
starten und laufen lassen, mit entsprechend höherem Speicherbedarf.

Ansonsten fällt mir auf Anhieb nur ein potentielles Problem ein: Dass 
Bluetooth oder die von mir verwendete Bluetooth-Library möglicherweise 
ein Problem haben könnte, wenn vier Programm gleichzeitig Bluetooth 
nutzen wollen. Müsste man mal ausprobieren, habe ich selbst keine 
Erfahrung mit.

Hallo,

ich bedanke mich für die flotte Rückmeldung!

Im Detail habe ich mich noch nicht damit beschäftigt, ich bin erst heute 
auf den Beitrag aufmerksam geworden. Ich habe sobeben mal einen Pi Zero 
W bestellt und werde dann mal testen wie zuverlässig das läuft. Eine 
Statusabfrage ist dann das einzige was mir hier noch fehlt. Auf das 
auslessen des Protokolls kann man nach meiner Meinung verzichten, das 
bildet mann besser extern ab. Schon alleine um die Batterien zu schonen.

Bzgl. der Bluetoothnutzung habe ich auch bedenken, 2 Geräte sollten zwar 
gleichzeitig gehen, ich denke eine Verbindung nach der anderen ist aber 
sinnvoller.
In meiner Android/Tasker Lösung behelfe ich mir mit einem Trennen der BT 
Verbindung vor dem Wechsel des Abzufragenden Antriebs. Dies hatte ich 
vorher nicht berücksichtigt und führte dann zu recht großen 
Verzögerungen (60s) bei der Abfrage.

Schönen Gruß
Thomas

Joachim S. schrieb:
> man müsste halt vier Instanzen des Programms parallel
> starten und laufen lassen, mit entsprechend höherem Speicherbedarf.
>
> Ansonsten fällt mir auf Anhieb nur ein potentielles Problem ein: Dass
> Bluetooth oder die von mir verwendete Bluetooth-Library möglicherweise
> ein Problem haben könnte, wenn vier Programm gleichzeitig Bluetooth
> nutzen wollen. Müsste man mal ausprobieren, habe ich selbst keine
> Erfahrung mit.

Hier würde sich ein "manuelles Triggern" zur (zukünftigen) 
Statusabfrage, wie auch schon vom Vorredner beschrieben anbieten. So 
würden sich die Instanzen nicht gegenseitig stören. Zum Öffnen/Schließen 
ein kurzer Befehl und zur Abfrage der Status. Die Ansteuerung müsste 
natürlich dann entsprechend vorher synchronisiert/eingereiht werden. 
Oder verstehe ich das falsch?

Thomas F. schrieb:

> Bzgl. der Bluetoothnutzung habe ich auch bedenken, 2 Geräte sollten zwar
> gleichzeitig gehen, ich denke eine Verbindung nach der anderen ist aber
> sinnvoller.

So dachte ich mir das auch...

Andre J. schrieb:
> Hier würde sich ein "manuelles Triggern" zur (zukünftigen)
> Statusabfrage, wie auch schon vom Vorredner beschrieben anbieten. So
> würden sich die Instanzen nicht gegenseitig stören. Zum Öffnen/Schließen
> ein kurzer Befehl und zur Abfrage der Status. Die Ansteuerung müsste
> natürlich dann entsprechend vorher synchronisiert/eingereiht werden.

Da hast Du recht - das ist ein Szenario, bei dem ich einsehe, dass ein 
manuelles Triggern sinnvoll sein könnte.

Daher würde ich momentan zu folgendem Ansatz tendieren:
Über den Kommandozeilen-Parameter "--status_update_time" wird man 
zukünftig einstellen können, alle wieviel Sekunden der Status 
automatisch abgefragt wird. Wird dieser Wert auf 0 gesetzt, so ist die 
automatische Status-Abfrage deaktiviert (so habe ich das auch bereits 
bei meinem Tool für das eqiva Bluetooth-Heizungsthermostat 
implementiert).
Und zusätzlich gibt es dann zukünftig einen Befehl a la "requeststatus", 
mit dem man unabhängig davon die Status-Abfrage zu einem beliebigen 
Zeitpunkt triggern kann.

Hallo Joachim,

ich bin wirklich begeistert von deinem Einsatz! Hut ab!

Sobald ich den Zero W bekomme und aufgesetzt habe melde ich mich.

Schönen Gruß
Thomas

Ich habe soeben Version 0.1.6 veröffentlicht.
Zum Installieren/Updaten:

1

sudo npm install --update --global --unsafe-perm keyble

Änderungen:
* keyble-sendcommand hat nun den Kommandozeilen-Parameter 
--status_update_time dem die Anzahl der Sekunden übergeben wird, nach 
denen eine automatische Status-Abfrage initiiert wird (0 zum 
deaktivieren)

* keyble-sendcommand hat nun den Kommandozeilen-Parameter 
--auto_disconnect_time dem die Anzahl der Sekunden Inaktivität übergeben 
wird, nach denen die Verbindung zum Türschlossantrieb automatisch 
getrennt wird (0 zum deaktivieren)

* keyble-sendcommand sollte nun den tatsächlichen Status ausgeben, statt 
wie bislang nur einen Fake-Status. Weiterhin werden auch 
Status-Änderungen erfasst, die auf andere Weise hervorgerufen wurden 
(z.B. durch manuelles Aufschliessen der Tür oder durch andere Benutzer)

* Zusätzlich zu den bisherigen Kommandos "lock", "unlock" und "open" 
gibt es bei keyble-sendcommmand nun das Kommando "status", durch das 
eine manuelle Status-Abfrage getriggert werden kann. Achtung: Der Status 
wird auch bei einer durch "status" getriggerten Status-Abfrage nur dann 
ausgegeben, falls er sich seit der letzten Status-Abfrage GEÄNDERT hat.

* einige Fehler behoben

Ich habe grössere Änderungen vorgenommen und nur ganz oberflächlich 
getest, es ist daher durchaus möglich, dass sich auch irgendwelche neuen 
Fehler eingeschlichen haben, oder manche Features noch nicht richtig 
funktionieren. Wenn jemand die neue Version testet, so wäre es schon, 
wenn er kurz Feedback gibt, ob und wenn ja welche Probleme er bemerkt.

Hallo,

vielen Dank für diese Entwicklung!
Ich habe zwei dieser Schlösser hier und wollte eigentlich per 
Hardware-Modifikation fernsteuern:
https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/geb%C3%A4udetechnik-ohne-knx-eib/1236022-erster-erfolg-g%C3%BCnstiges-smartlock-eq3-eqiva-fernsteuern

Aber ich habe es nicht geschafft, das Schloss zuverlässig schalten zu 
lassen, wenn der ansteuernde ESP aus dem Deep-Sleep kam.

Außerdem habe ich erst an einem gelötet ;-)

Ich hatte mir auch schon einmal die apk vorgenommen, aber aufgegeben.

Heute habe ich zufällig deinen Thread gefunden und möchte keyble 
ausprobieren.
Erstmal aber ein Glückwunsch zu der Leistung!

Welche Hardware (hier genannt wurden ja schon RasPi Zero und Nano Pi) 
könnt ihr empfehlen? V.a. die Bluetoothreichweite und der Stromverbrauch 
sind ja relevant.

Gruß,
Hendrik

Hendrik F. schrieb:
> Welche Hardware (hier genannt wurden ja schon RasPi Zero und Nano Pi)
> könnt ihr empfehlen? V.a. die Bluetoothreichweite und der Stromverbrauch
> sind ja relevant.

Da kann ich zumindest bislang nicht sooo viel dazu sagen.

Die diversen Raspberry Pi-Varianten (und anderen Linux-basierten 
Einplatinen-Computer) sind wohl die naheliegende Standard-Lösung. Da 
dürften grundsätzlich alle geeignet sein, das eine mit etwas höherem, 
das andere mit etwas niedrigerem Stromverbrauch.

Bluetooth-Hardware mit hoher Reichweite ist vermutlich sinnvoll, damit 
man alle Türschlossantriebe von einem einzigen Gerät aus steuern kann.
Wobei ich mir nicht sicher bin, wie viel hohe Reichweite der 
Blueooth-Hardware überhaupt bringt, denn falls die vom Türschlossantrieb 
verwendete Bluetooth-Hardware nicht ebenfalls gute Reichweite hat, 
bringt das vielleicht trotzdem nichts.

Am wichtigsten ist vermutlich einfach eine geschickte Positionierung des 
Gerätes, das die Türschlossantriebe steuert.

Hallo,

Das ideale Gerät wäre doch eigentlich ein Handy Bluetooth und WLAN sind 
eingebaut. Energiesparend, USV eingebaut.
Mit termux lässt sich nodejs auf Android installieren.
Was hältst du davon?

Gruß,
Hendrik

Hendrik F. schrieb:
> Hallo,
>
> Das ideale Gerät wäre doch eigentlich ein Handy Bluetooth und WLAN sind
> eingebaut. Energiesparend, USV eingebaut.

Ja, andererseits: Wenn man das permanent am Netzkabel hängen lässt, 
macht man sich schnell den Akku kaputt. Von daher würde ich persönlich 
das vermutlich nur tun, wenn ich das Smartphone partout nicht mehr 
brauche, oder sich der Akku ausbauen lässt-

> Mit termux lässt sich nodejs auf Android installieren.
> Was hältst du davon?

Ich könnte mir gut vorstellen, dass es da mglw. Probleme gibt. z.B. weil 
das evtl. keine offizielle Node.js-Plattform ist oder so, und dann 
irgendwelche Fehler/Probleme mit irgendwelchen benötigten 
Node.js-Modulen auftreten, die nativen Code benutzen oder so.

Aber das ist zugebenermassen reine Spekulation, ich habe keinerlei 
Ahnung von diesem termux. Probier es gerne einfach mal aus und berichte 
:)

Hallo nochmal,

ich kann ersten Erfolg (aber noch unter Ubuntu) vermelden.
Das Registrieren hat geklappt.
Allerdings hing keyble-registeruser bei
"Setting username to PC"

keyble-sendcommand hat aber funktioniert.
Aber auch sendcommand hat sich nicht beendet, sondern gab die Ausgabe:
active
unlocked

und blieb da stehen.
Ist das normal?

>wenn ich das Smartphone partout nicht mehr
brauche, oder sich der Akku ausbauen lässt-

Wer von uns hat kein Smartphone rumliegen, was er nicht mehr braucht..

>Probier es gerne einfach mal aus und berichte
Ja gerne. Allerdings installiert termux erstmal nodejs10 und da 
schriebst du ja von Problemen.

edit:
Es gibt npm:
https://wiki.termux.com/wiki/Node.js
Allerdings:
Unsupportet platform for noble@1.9.1

Geht es auch ohne noble?

Gruß,
Hendrik

Hendrik F. schrieb:
> Hallo nochmal,
>
> ich kann ersten Erfolg (aber noch unter Ubuntu) vermelden.
> Das Registrieren hat geklappt.
> Allerdings hing keyble-registeruser bei
> "Setting username to PC"

Kann ich mir so erst einmal keinen Reim drauf machen...

>
> keyble-sendcommand hat aber funktioniert.
> Aber auch sendcommand hat sich nicht beendet, sondern gab die Ausgabe:
> active
> unlocked
>
> und blieb da stehen.
> Ist das normal?

Eigentlich nicht. Was für einen Befehl hast Du da angegeben?

> edit:
> Es gibt npm:
> https://wiki.termux.com/wiki/Node.js
> Allerdings:
> Unsupportet platform for noble@1.9.1
>
> Geht es auch ohne noble?

Nein. Noble ist die zugrundeliegende Bluetooth-Library, auf der alles 
aufbaut. Genau so ein Problem ("unsupportet platform") habe ich 
befürchtet. :-(

Hallo,

kannst du mir eine Liste von Dependencies geben, die keyble braucht (nur 
die direkten. Die indirekten löst npm ja auf)?
Dann würde ich mal probieren, was sonst so fehlt.
Noble scheint machbar:
https://github.com/noble/noble/issues/571

> Was für einen Befehl hast Du da angegeben?
Der erste war
keyble-registeruser --qr_code_data ...

Der hat auch funktioniert und
User registered. Use Arguments --address XXX --userid 2 --user_key xx
Setting user name to "PC"...

zurück gegeben. Da hing das Kommando aber. (ctrl-C zum beenden 
eingegeben.)

Danach habe ich keyble-sendcommand --address XXX --userid 2 --user_key 
xx  ..command open
ausgeführt.
Output:
active
unlocked

Da hing es dann.

Gruß,
Hendrik

Hendrik F. schrieb:
> Hallo,
>
> kannst du mir eine Liste von Dependencies geben, die keyble braucht (nur
> die direkten. Die indirekten löst npm ja auf)?
> Dann würde ich mal probieren, was sonst so fehlt.
> Noble scheint machbar:
> https://github.com/noble/noble/issues/571

Die direkten Abhängigkeiten von keyble sind:
    "aes-js": "^3.1.1",
    "argparse": "^1.0.10",
    "debug": "^4.0.1",
    "simble": "^0.2.1"
Bei aes-js, argparse und debug würde ich vermuten, dass die unter diesem 
"termux" keine Probleme machen, diese Module sind glaube ich alle in 
Javascript geschrieben, ohne nativen Code und allzu viele 
Abhängigkeiten.

"simble" ist ein Node.js-Modul von mir selbst, ist aber im Grunde nur 
ein kleiner Wrapper für die "noble"-Bluetooth-Library, und hat folgende 
Abhängigkeiten:
    "debug": "^4.0.0",
    "noble": "^1.9.1"

Kurz gesagt, ich würde vermuten: wenn Du es tatsächlich schaffst "noble" 
unter diesem "termux" zu installieren bzw. zum Laufen zu kriegen, dann 
dürfte der Rest vermutlich auch funktionieren.

>> Was für einen Befehl hast Du da angegeben?
> Der erste war
> keyble-registeruser --qr_code_data ...
>
> Der hat auch funktioniert und
> User registered. Use Arguments --address XXX --userid 2 --user_key xx
> Setting user name to "PC"...
>
> zurück gegeben. Da hing das Kommando aber. (ctrl-C zum beenden
> eingegeben.)
>
> Danach habe ich keyble-sendcommand --address XXX --userid 2 --user_key
> xx  ..command open
> ausgeführt.
> Output:
> active
> unlocked
>
> Da hing es dann.

Kann ich mir momentan keinen Reim drauf machen, was da das Problem ist.
Benutzt Du von keyble die neueste Version 0.1.8, die ich gestern 
veröffentlicht habe? In älteren Versionen gab es gewisse Probleme in 
dieser Richtung, bei der neuesten hatte ich gehofft dass sie dort 
behoben sind.

Ansonsten:
Was evtl. helfen kann, ist: Beim Aufruf vor das eigentliche Kommando

1

DEBUG="simble:*,keyble:*"

zu setzen, also z.B.

1

DEBUG="simble:*,keyble:*" keyble-sendcommand ...

Dann werden zusätzliche Debug-Infos angezeigt, die evtl. helfen können.

Hallo,

da bekomme ich jetzt einige Debug-Ausgaben.
Ist da etwas dabei, was ich schwärzen sollte?

Die letzten zwei Kommandos sind:
Event: status:unlocked
Event: status_change
Event: received:message:STATUS_INFO
EVENT: disconnected

Alle in kurzer Abfolge.  Disconnected aber erst nach +15s.

Bezüglich noble:
https://github.com/noble/noble/issues/571

Ich bleib da mal dran.

Gruß,
Hendrik

Hendrik F. schrieb:
> da bekomme ich jetzt einige Debug-Ausgaben.
> Ist da etwas dabei, was ich schwärzen sollte?

Auf Anhieb fällt mir da jetzt zumindest nichts ein, was man unbedingt 
schwärzen müsste. In den Debug-Ausgaben wird zwar die gesamte 
Kommunikation geloggt, aber man erfährt keine Informationen, die nicht 
bspw. auch ein hypothetischer Angreifer erfahren würde, der Deine 
Bluetooth-Kommunikation belauscht. Das Protokoll ist aber durch 
Verschlüsselung und andere Sicherheitsmerkmale gegen solche 
Angreifer/Lauscher geschützt. Wichtig ist eigentlich eh nur, dass der 
AES-Schlüssel zum registrieren und Dein persönlicher 
Benutzer-AES-Schlüssel geheim bleiben, und die sind in den 
Debug-Ausgaben nicht zu finden.
Die MAC-Adresse Deines Türschlossantriebs ist bspw. in den 
Debug-Ausgaben zu finden, falls Dich das stört.

> Die letzten zwei Kommandos sind:
> Event: status:unlocked
> Event: status_change
> Event: received:message:STATUS_INFO
> EVENT: disconnected
>
> Alle in kurzer Abfolge.  Disconnected aber erst nach +15s.

In diesem Fall wäre der Teil davor interessant gewesen.

Moin,

hier die ganze Ausgabe:

1

DEBUG="simble:*,keyble:*" keyble-sendcommand --address 00:xx:xx:0a:6f:0d --user_id 2 --user_key xxx --command open

2

  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "connected" +0ms

3

  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "discovered" +495ms

4

  simble:data Characteristic 3141dd40-15xx-11xx-a24b-0002a5d5c51b : Send "80 02 02 79 51 6d be d8 8d 25 46 00 00 00 00 00" +0ms

5

  simble:data Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Receive "80 03 02 8d 63 29 97 51 28 e1 4d 00 10 17 00 00" +43ms

6

  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +613ms

7

  keyble:events Event: received:fragment +0ms

8

  keyble:events Event: received:message +1ms

9

  keyble:events Event: received:message:CONNECTION_INFO +0ms

10

  keyble:events Event: nonces_exchanged +1ms

11

  simble:data Characteristic 3141dd40-15xx-11xx-a24b-0002a5d5c51b : Send "80 87 b4 b2 bd 4d 90 65 b9 cc 00 01 ff 21 09 43" +14ms

12

  simble:data Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Receive "80 83 9f 04 c9 c4 6d 45 49 17 00 01 3f 8b fc cd" +75ms

13

  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +89ms

14

  keyble:events Event: received:fragment +87ms

15

  keyble:events Event: received:message +1ms

16

  keyble:events Event: status_update +0ms

17

  keyble:events Event: status:active +1ms

18

  keyble:events Event: status_change +0ms

19

active

20

  keyble:events Event: received:message:STATUS_INFO +1ms

21

  simble:data Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Receive "80 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00" +4s

22

  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +4s

23

  keyble:events Event: received:fragment +4s

24

  keyble:events Event: received:message +0ms

25

  keyble:events Event: received:message:STATUS_CHANGED_NOTIFICATION +1ms

26

  simble:data Characteristic 3141dd40-15xx-11xx-a24b-0002a5d5c51b : Send "80 82 d9 af a9 a3 1c e9 22 f4 00 02 bd 0f cf b4" +4ms

27

  simble:data Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Receive "80 83 e0 84 40 1d a7 a0 d7 9c 00 02 21 c6 7f a4" +41ms

28

  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +44ms

29

  keyble:events Event: received:fragment +44ms

30

  keyble:events Event: received:message +1ms

31

  keyble:events Event: status_update +0ms

32

  keyble:events Event: status:unlocked +0ms

33

  keyble:events Event: status_change +0ms

34

unlocked

35

  keyble:events Event: received:message:STATUS_INFO +1ms

36

  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "disconnected" +15s

37

  keyble:events Event: disconnected +15s

38

  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "connected" +10m

39

  keyble:events Event: connected +10m

40

  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "discovered" +495ms

41

  simble:data Characteristic 3141dd40-15xx-11xx-a24b-0002a5d5c51b : Send "80 02 02 4f 85 08 1e 72 b4 11 d5 00 00 00 00 00" +10m

42

  simble:data Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Receive "80 03 02 5a 19 5f 82 e5 14 15 2b 00 10 17 00 00" +45ms

43

  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +45ms

44

  keyble:events Event: received:fragment +540ms

45

  keyble:events Event: received:message +0ms

46

  keyble:events Event: received:message:CONNECTION_INFO +0ms

47

  keyble:events Event: nonces_exchanged +0ms

48

  simble:data Characteristic 3141dd40-15xx-11xx-a24b-0002a5d5c51b : Send "80 82 42 c8 00 f1 6e bc 16 3f 00 01 5a dd 44 c4" +2ms

49

  simble:data Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Receive "80 83 f6 0d 3f 06 61 c3 c7 eb 00 01 a8 c1 03 19" +58ms

50

  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +60ms

51

  keyble:events Event: received:fragment +60ms

52

  keyble:events Event: received:message +1ms

53

  keyble:events Event: status_update +1ms

54

  keyble:events Event: received:message:STATUS_INFO +0ms

55

  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "disconnected" +15s

56

  keyble:events Event: disconnected +15s

Bei Android komme ich erstmal nicht weiter.

Gruß,
Hendrik

Danke für den Log-Auszug. Das ist interessant - und ich gerade etwas 
verwirrt.

Offenbar meldet Dein Türschlossantrieb das Erreichen den "Open"-Zustands 
nicht, der bei mir kurzzeitig gemeldet wird, bevor er kurz danach dann 
wieder in den "Unlocked"-Zustand wechselt. Weil dieser "Open"-Zustand 
bei Dir nicht gemeldet wird, wartet und wartet keyble-sendcommand 
vergeblich darauf, dass das passiert.

Die Frage ist, warum sich Dein Türschlossantrieb da anders verhält. 
Lustigerweise habe ich mich genau zu diesem Thema in der letzten Woche 
mit Jemandem unterhalten, der eine Software zum Steuern des 
"Homematic"-Türschlossantriebs des gleichen Herstellers geschrieben hat. 
Weil die Hardware etc. ziemlich ähnlich ist, hat er aufgrund seiner 
Erfahrung prognostiziert, dass es beim eqiva-Türschlossantrieb gar 
keinen "Open"-Zustand gibt, bzw. der nicht gemeldet wird.

Jetzt kann ich erst einmal nur spekulieren, warum sich Dein 
Türschlossantrieb da anders verhält als meiner. Auf Anhieb fallen mir 
zwei Möglichkeiten ein:

1. Du hast eine andere Firmware- oder Hardware-Version, daher verhält 
sich Dein Antrieb leicht anders. Was wird bei Dir in der App angezeigt?

2. Der Unterschied liegt darin, dass Dein Türschlossantrieb tatsächlich 
an einer Tür installiert ist, meiner hingegen nicht: So lange ich noch 
an der Steuerungs-Software entwickle, liegt der Türschlossantrieb direkt 
neben mir auf dem Schreibtisch; das Verhalten eines echten 
Schliesszylinders versuche ich durch Entgegenhalten mit der Hand am 
Drehrad zu simulieren.

Vielleicht macht genau das eben doch genau den Unterschied aus, dass 
sich ein echter Schliesszylinder eben doch leicht anders verhält...

Wie auch immer, Ich habe das jetzt erst einmal so gelöst, dass beim 
"Open"-Kommando nicht auf den "Open"-Zustand gewartet wird, sondern auf 
den "Unlocked"-Status, der auf jeden Fall kommt.

Habe eben die Version 0.1.9 veröffentlicht, in der dieses Problem 
behoben sein sollte - wäre schön, wenn Du es mal ausprobieren und 
Feedback geben könntest.

Vielen Dank jedenfalls nochmal für das Log, Du hast mich auf ein 
wichtiges Problem aufmerksam gemacht!

p.s.: Falls Du oder ein anderer nochmal ein Log veröffentlicht: Bei den 
UUIDs der Charakteristiken ("3141dd40-15db-11e6-a24b-0002a5d5c51b" und 
"359d4820-15db-11e6-82bd-0002a5d5c51b") muss man nichts schwärzen, die 
sind eh bei jedem Türschlossantrieb identisch.

Hallo,

ich verstehe jetzt, woran es liegt:
Ich habe (dieses) Schloss auch auf dem Schreibtisch.
Ich habe es aber nicht manuell blockiert, sondern einen der Knöpfe 
gedrückt um es zu stoppen.

Daher kommt wohl nur Unlocked und nicht Open.

Dennoch führt deine Änderung sicherlich zu einem robusteren Design.

Mein RasPi müsste die nächsten Tage kommen. Dann probiere ich es.

Gruß&Danke,
Hendrik

Hendrik F. schrieb:
> Hallo,
>
> ich verstehe jetzt, woran es liegt:
> Ich habe (dieses) Schloss auch auf dem Schreibtisch.
> Ich habe es aber nicht manuell blockiert, sondern einen der Knöpfe
> gedrückt um es zu stoppen.
>
> Daher kommt wohl nur Unlocked und nicht Open.

Das ist in der Tat eine plausible und mögliche Erklärung. Wäre sehr 
nett, wenn Du das mal ausprobieren könntest, indem Du nicht den Knopf 
drückst, sondern auch am Drehrad entgegenhältst/blockierst, und schaust 
ob dann bei Dir der "Open"-Status gemeldet wird.

Hallo,

ich habe das gerade ausprobiert und kann es bestätigen.
Das Programm (noch nicht aktualisiert) beendet sich dann auch.

Gruß,
Hendrik

Hallo,

hast du mal darüber nachgedacht, die Nuki-HTTP-API zu implementieren?
https://nuki.io/wp-content/uploads/2018/04/20180330-Bridge-API-v1.7.pdf

Dann wäre man gleich mit einer ganzen Scharr von Smarthome-Welten 
kompatibel.

Gruß,
Hendrik

Hendrik F. schrieb:
> ich habe das gerade ausprobiert und kann es bestätigen.
> Das Programm (noch nicht aktualisiert) beendet sich dann auch.

Sorry, bin gerade nicht 100% sicher, ob ich Dich richtig interpretiere, 
daher frage ich zur Sicherheit lieber nochmal nach:
Wenn Du den Türschlossantrieb am Drehrad mit der Hand blockierst, dann 
wird doch der "open"-Status gesendet?

Hendrik F. schrieb:
> hast du mal darüber nachgedacht, die Nuki-HTTP-API zu implementieren?
> https://nuki.io/wp-content/uploads/2018/04/20180330-Bridge-API-v1.7.pdf
>
> Dann wäre man gleich mit einer ganzen Scharr von Smarthome-Welten
> kompatibel.

Grundsätzlich eine gute Idee. Nach derzeitigem Stand werde ich 
allerdings in Kürze, evtl. schon nächste Woche, für ca. 6 Wochen im 
Ausland sein, und in dieser Zeit werde ich wohl gar nicht zum 
Programmieren kommen.

Vorher werde ich dafür auch definitiv keine Zeit mehr finden, daher wird 
damit zumindest in den nächsten zwei Monaten definitiv nichts werden.

Hallo,

ja, der open Status wurde gesendet. Du hast mich richtig interpretiert.

Dann wünsche ich dir viel Spaß und alles Gute im Ausland!

Gruß,
Hendrik

Hallo,

ich habe gerade erfolgreich mein Schloss via mqtt gesteuert! Danke 
nochmal!

Eine Frage aber noch: Es gibt noch keine Möglichkeit den Status vom 
Schloss über MQTT zu erhalten, oder?
Edit: Ich sehe dass es in der neuen Version das Kommando "status" gibt.
Damit kann ich natürlich jede Minute das Kommando:
mosquitto_pub -h server -t "door_lock/status" -m $(keyble-sendcommand 
.... --command status)" abfragen.

Wäre es nicht besser, wenn es ein
keyble-status gibt, welches dann mosquitto triggert? Oder würde 
keyble-status auch aktiv 'pollen' statt eine Verbindung aufrecht zu 
erhalten?

P.S.: Unter welcher Lizenz steht keyble eigentlich? Solltest du auf 
github vielleicht noch hinzufügen.

Gruß,
Hendrik

Hendrik F. schrieb:
> Eine Frage aber noch: Es gibt noch keine Möglichkeit den Status vom
> Schloss über MQTT zu erhalten, oder?
> Edit: Ich sehe dass es in der neuen Version das Kommando "status" gibt.
> Damit kann ich natürlich jede Minute das Kommando:
> mosquitto_pub -h server -t "door_lock/status" -m $(keyble-sendcommand
> .... --command status)" abfragen.
>
> Wäre es nicht besser, wenn es ein
> keyble-status gibt, welches dann mosquitto triggert? Oder würde
> keyble-status auch aktiv 'pollen' statt eine Verbindung aufrecht zu
> erhalten?

Danke - Du hast mich da gerade auf etwas wichtiges aufmerksam gemacht.

Die Möglichkeit, auch den Status via MQTT zu sehen, ist nämlich bereits 
enthalten - und ich dachte bis eben, ich hätte das in der Anleitung auf 
GitHub auch längst beschrieben, was dazu zu tun ist. Hatte ich aber gar 
nicht...

Das Prinzip, den Status via MQTT zu veröffentlichen, ist genau das 
gleiche Prinzip, mit dem man den Türschlossantrieb via MQTT steuert:
keyble-sendcommand gibt ganz bewusst lediglich Status-Änderungen aus, 
jeweils als einzelne Zeilen. Daher kann man die Ausgabe von 
keyble-sendcommand einfach in ein anderes Kommandozeilen-Tool wie bspw. 
"mosquitto_pub" "pipen", so dass jede Status-Änderung als MQTT-Nachricht 
auf einer festgelegten Topic gepublisht wird.

Ich habe die README diesbezüglich eben aktualisiert:
https://github.com/oyooyo/keyble#piping-data-into-keyble-sendcommand

Eine Status-Abfrage über das "status"-Kommando manuell zu triggern, ist 
dazu übrigens gar nicht nötig. Mit dem Kommandozeilen-Parameter 
--status_update_time legt man die Zeit in Sekunden fest, nach der sich 
keyble-sendcommand automatisch kurz mit dem Türschlossantrieb verbindet 
und den Status abfragt. Standard ist 600, also 10 Minuten. Nach 
--auto_disconnect_time Sekunden (Standard: 30 Sekunden) wird die 
Verbindung dann wieder automatisch getrennt.
Standardmässig verbindet sich keyble-sendcommand also alle 10 Minuten 
für 30 Sekunden mit dem Türschlossantrieb, um eventuelle 
Status-Änderungen (die auf andere Weise ausgelöst wurden) zu erkennen 
und auszugeben.

Hallo Hendrik - habe erst direkt nach dem Verfassen meines letzten 
Beitrags die GitHub-Nachricht über den Pull-Request gelesen - und 
festgestellt, dass der ja offenbar von Dir ist!

Weil ich die README aufgrund Deines Hinweises in der letzten Nachricht 
hier im Thread bereits dahin gehend aktualisiert habe, macht es wenig 
Sinn, den Pull-Request jetzt noch zu mergen; zumal Deine Variante wegen 
des Missverständnisses bzgl. der Status-Abfragen ja auch komplizierter 
als nötig ist. Ich werde Deinen Pull-Request also erst einmal schliessen 
- dennoch vielen Dank, dass Du mir auf diese Weise gleich die Arbeit 
abnehmen und Dich einbringen wolltest!

Moin,

ah! ich hatte in der Readme diesen Teil nicht gesehen:
| mosquitto_pub -h 192.168.0.2 -l -r -t "door_lock/status"


Jetzt muss nur der RasPi mal kommen ;-)

Gruß,
Hendrik

Hendrik F. schrieb:
> ah! ich hatte in der Readme diesen Teil nicht gesehen:
> | mosquitto_pub -h 192.168.0.2 -l -r -t "door_lock/status"

Konntest Du auch nicht - den gibt es halt erst seit wenigen Minuten, 
nachdem Du mich darauf aufmerksam gemacht hast, dass das noch fehlt... 
;-)

> Jetzt muss nur der RasPi mal kommen ;-)

Ich hoffe, bei Dir klappt alles. Aus irgendeinem Grund habe ich selbst 
seit kurzem nämlich Probleme, dass keyble nicht mehr richtig auf meinem 
Raspberry Pi 3 funktioniert. Da scheint es irgendein Problem in der 
verwendeten Bluetooth-Library auf dem Raspberry Pi 3 zu geben.

Ah ja. Das habe ich auch gerade gesehen ;-)

Das ist ja blöd, dass du Ärger auf dem Raspi hast... Ich werde das mal 
gegenprüfen.

Danke für die Danksagung ;-)

Hallo,

ich habe gerade ein Pullrequest für ein Startskript gestellt.
Leider funktioniert das noch nicht.
Es besteht aus einem Bash-Skript welches mosquitto_pub, mosquitto_sub 
und key_ble-sendcommand startet und einem SystemD.service
Wenn ich das Skript manuell starte, kann ich das Schloss ber MQTT 
steuern.
Startet es via Systemd, so funktioniert das nicht.
In ps -aux sehe ich einen Unterschied:

1

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

2

root      6616  0.0  0.7   4644  3344 ?        S    17:31   0:00 /usr/bin/mosquitto_sub -h 192.168.177.3 -t SmartlockSchuppen/action

3

root      6618  0.0  0.7  13860  3388 ?        Sl   17:31   0:00 /usr/bin/mosquitto_pub -h 192.168.177.3 -l -r -t SmartlockSchuppen/status

4

5

6

root      8632  0.0  0.7   4644  3496 pts/2    S+   17:34   0:00 /usr/bin/mosquitto_sub -h 192.168.177.3 -t SmartlockSchuppen/action

7

root      8634  0.0  0.7  13860  3376 pts/2    Sl+  17:34   0:00 /usr/bin/mosquitto_pub -h 192.168.177.3 -l -r -t SmartlockSchuppen/status

Man sieht, dass im zweiten -funktionierendem/manuellen- Fall ein TTY 
zugeordnet ist. Im ersten nicht. Andere Unterschiede sehe ich nicht.

Woran kann es noch liegen?

Gibt es eine Möglichkeit key_ble in dieser Konstellation log-ausgaben 
irgendwohin senden zu lassen?

Gruß,
Hendrik

Hallo Hendrik,
Danke für den Hinweis, dass da etwas noch nicht klappt.

Ich selbst benutze systemd zwar, habe mit dem Erstellen von 
systemd-Services etc. aber bislang auch keine Erfahrung, bin da also 
keine wirkliche Hilfe. :-(

Da da offenbar noch ein Bug drin ist, werde ich Deinen pull-Request vor 
meiner Abfahrt in's Ausland morgen früh wohl nicht mehr mergen. Falls Du 
den Fehler bis dahin nicht gefunden hast, schaue ich mir das nach meiner 
Rückkehr  nochmal genauer an.

Nach aktuellem Stand werde ich übrigens voraussichtlich doch nur ca. 3 
Wochen fort sein. Da ich in der Zeit wohl nicht im µc-Forum aktiv sein 
werde, verabschiede ich mich hiermit auch mal bis dahin.

Ok, gute Reise!

Hallo,

funktioniert jetzt.
Ich habe den PR aktualisiert.

Gruß,
Hendrik

Hi Hendrik,

schön, dass Du es so schnell hinbekommen hast!

Man müsste das Ganze allerdings auch noch dokumentieren/erklären, nur 
die Dateien einzufügen ist denke ich nicht genug.
Also in der README.md einen neuen Abschnitt einfügen und dort 
beschreiben, wo welche Datei hinkopiert werden muss, was an den Dateien 
evtl. angepasst werden muss etc.

Da der eigentliche Inhalt der beiden Dateien ja eh sehr kurz ist, frage 
ich mich ehrlich gesagt gerade, ob es nicht sogar sinnvoller wäre, die 
beiden Dateien einfach wegzulassen, und ihren Inhalt direkt in der 
Dokumentation aufzulisten, quasi als Vorlage oder Vorschlag, bei dem man 
dann direkt erklärt, was man noch anpassen muss etc.
So ähnlich wie das bspw. in der Dokumentation zu uwsgi gemacht wird:
https://uwsgi-docs.readthedocs.io/en/latest/Systemd.html

Würdest Du das auch noch übernehmen (eilt nicht, hast wie gesagt ca. 3 
Wochen Zeit)?

Hallo,

ja, ich mache das gerne.
momentan funktioniert es aber nicht. Auch wenn ich manuell 
keyble-sendcommand aufrufe, erhalte ich:
  simble:event Peripheral 00:1a:22:0a:6e:7c : Event "connected" +0ms
Error: Promise did not resolve within 45000 milliseconds



Hast du eine Idee, woran das liegen kann?
Ich habe natürlich nichts geändert.

Gruß,
Hendrik

Wollte kurz Bescheid sagen, dass ich jetzt wieder zurück/zuhause bin.

@Hendrik: Nein, auf Anhieb kann ich mir da gerade keinen Reim drauf 
machen.
Dein betreffendes Posting ist ja bereits einen Monat her - hat sich 
seitdem irgendwas geändert?

Ich nutze die ios App täglich und regelmässig wird das schloss nicht 
gefunden. Ich muss dann die app mehrmals neu starten bzw. Nach der 
Meldung „Schloss nicht gefunden“ auf „verbinden wiederholen“ klicken. 
Nach ein paar mal geht es dann. Evtl ein Problem vom Schloss selbst?

Hendrik Friedel schrieb:
> Ja, leider habe ich das Problem immernoch.

Ok. Verstehe ich das richtig, dass keyble momentan bei Dir also gar 
nicht funktioniert? Du hast Debug-Ausgaben eingeschaltet, und denen 
zufolge verbindet sich die Software zwar, aber danach passiert einfach 
gar nichts mehr?

> Du nutzt das Lock noch nicht produktiv, oder?

Richtig, mein Lock liegt bislang immer noch neben mir auf dem 
Schreibtisch, weil ich so leichter entwickeln und potentielle 
Störfaktoren (z.B. Probleme durch schlechte Funkverbindung) 
ausschliessen kann.

Hendrik Friedel schrieb:
> Hallo,
>
> ja genau. Es kommt letztlich die Meldung:
>

1

  simble:event Peripheral 00:1a:22:0a:6f:0d : Event "connected" 

2

> +0ms

3

> Error: Promise did not resolve within 45000 milliseconds

4

>

Hmm, darauf kann ich mir auf Anhieb keinen Reim machen, was da jetzt das 
Problem sein könnte. Wirklich aussagekräftig ist die obige Ausgabe ja 
nicht, vermutlich sollte ich bei Gelegenheit mal noch ein paar mehr 
Debug-Ausgaben hinzufügen.

Hallo zusammen,

erstmal vielen Dank für die tolle Arbeit!
Ich habe mir nach dem Durchforsten dieses Threads auch das Lock geholt 
und gerade auf meinem Raspberry 3 B+ nach den Anweisungen im Github 
verbunden.

Einen Schritt habe ich allerdings weggelassen: das Hinzufügen des 
Repositories vor dem Installieren von NodeJS.
wget -qO- https://deb.nodesource.com/setup_8.x | sudo -E bash -

Bei meinem frisch installierten Raspbian Stretch ist die NodeJS Version 
8.11.1 in den offiziellen Repos enthalten. Das es mit Version 10 ein 
Problem gibt, hatte ich gelesen, aber stimmt mit 8.11.1 auch etwas 
nicht?

Ich hoffe ich habe es nicht überlesen, aber ich konnte keine Angaben 
finden, wie lange es bei euch dauert, bis ein Kommando ausgeführt wird. 
Ich frage, da es bei mir ca 10 Sekunden dauert bis sich etwas tut. Ist 
das bei euch auch so?

Viele Grüße
Tobi

Hallo,

bei mir braucht der Pi 3 zwischen 3 und 6 Sekunden zum Verbinden und 
Kommando senden, vermutlich je nachdem wann das Gerät das letzte mal 
angesprochen wurde.
Wie weit ist das Schloss denn vom Sender entfernt?

Den gleichen Fehler wie Hendrik kann ich auch reproduzieren. Nachdem ich 
den bluetooth Service (und evtl hciuart.service, oder alternativ das 
ganze System) neugestartet habe, geht es aber wieder.
Bei mir wurde das Schloss von der App (Android) immer zuverlässig 
gefunden, allerdings dauert es manchmal bis zu 30 Sekunden.


Ich bin gerade dabei, eine Portierung von keyble für den ESP32 bzw. als 
Bibliothek in C++ zu schreiben, da mein Pi leider etwas zu weit weg von 
der Tür ist.

Diese funktioniert auch schon, ich werde den Code nächste Woche auch bei 
Github veröffentlichen, wenn dieser etwas lesbarer geworden ist und ich 
eine Setup-Weboberfläche hinzugefügt habe.

Gruß,
Marius

Marius S. schrieb:
> Den gleichen Fehler wie Hendrik kann ich auch reproduzieren. Nachdem ich
> den bluetooth Service (und evtl hciuart.service, oder alternativ das
> ganze System) neugestartet habe, geht es aber wieder.

Kannst Du mir etwas genauer erklären, wie ich dieses Problem evtl. auch 
bei mir reproduzieren könnte? Wenn ich Dich richtig verstehe, 
funktioniert keyble grundsätzlich, bspw. direkt nachdem das System neu 
gestartet wurde, ja schon noch. Wie kann ich dann herbeiführen, dass 
keyble nicht mehr funktioniert?

> Ich bin gerade dabei, eine Portierung von keyble für den ESP32 bzw. als
> Bibliothek in C++ zu schreiben, da mein Pi leider etwas zu weit weg von
> der Tür ist.
>
> Diese funktioniert auch schon, ich werde den Code nächste Woche auch bei
> Github veröffentlichen, wenn dieser etwas lesbarer geworden ist und ich
> eine Setup-Weboberfläche hinzugefügt habe.

Sehr schön - super Idee, gefällt mir! :-)

Hi,

na das ist ja toll. ich komme von 
https://knx-user-forum.de/forum/öffentlicher-bereich/gebäudetechnik-ohne-knx-eib/1222419-smartes-türschloss-mit-schließstatusabfrage 
und könnte so ohne bastelarbeit an dem Einsteckschloss Abfragen ... :-)
Eigentlich wollte ich ursprünglich so wie Joachim reverse engineering 
machen, hab das aber nicht geschafft. hut ab für deine tolle arbeit und 
auch für die idee mit den debugmeldungen mittels apktool einbauen!

ich werd in den nächsten Tagen einen RPI fitmachen und mittesten. Werd 
sicher was dazu beitragen.
Da schon das Problem Batterieverbrauch aufgekommen ist. Mein equiva hat 
mit 3 standard AA jetzt 7 Monate durchgehalten. Jetzt hab ich Kentli 
1.5V LI-ION akkus drinnen. findet man auf aliexpress, die kann ich 
bisher (von anderen Anwendungen) sehr empfehlen.

Grundsätzlich bin ich inzwischen mehr ESPxx begeistert als RPI, da 
kleiner und mit weniger Aufwand ersetzbar wenn kaputt. bei meinen RPIs 
machen regelmäßig die SD-Karten schlapp, das ist dann ärgerlich und 
zeitaufwändig, bis das wieder alles läuft. beim ESP kann einer in der 
Schublade mit dem gleichen Code auf den Ausfall warten ... :D

LG

Michi schrieb:
> Hi, ich kann mich zu dem Smart Lock nicht verbinden..hat jemand eine
> idee wieso es so ist? Was bedeutet
> received:message:ANSWER_WITHOUT_SECURITY ?

Der Umstand, dass eine Nachricht des Typs "ANSWER_WITHOUT_SECURITY" 
zurückgeliefert wird, besagt in diesem Fall, dass irgendetwas bei der 
Benutzerregistrierung nicht geklappt hat.

Ich weiss gar nicht, ob als Teil dieser Meldung ein Fehlercode 
zurückgeliefert wird, über den man herausfinden könnte, was genau das 
Problem war, daher kann ich nur spekulieren, wo das Problem gelegen 
haben könnte. Ein paar mögliche Fehlerquellen, die mir auf Anhieb 
einfallen, wären:
- dummer Fehler, der mir aber auch mehrfach passiert ist: Man hat 
schlicht vergessen, vorher den "Unlock"-Button so lange zu drücken, bis 
die gelbe LED blinkt
- ebenso dummer Fehler: man hat über die Smartphone-App selbst 
eingestellt, dass keine neuen bzw. weiteren Benutzer registriert werden 
können
- die Daten von der Key Card wurden fehlerhaft übertragen; das ist 
allerdings unwahrscheinlich bis unmöglich, falls Du die Daten der Key 
Card per zbarcam einliest, wie es in der Anleitung vorgeschlagen wird
- es ist bereits die maximale Anzahl an Benutzern registriert

Michi schrieb:
> Vielen Dank für eine schnelle Antwort.
>
>>> es ist bereits die maximale Anzahl an Benutzern registriert
>
> Weisst du wie viel Benutzer hier maximal erlaubt sind?

Habe eben mal auf deren Homepage nachgeschaut: Laut deren Aussage bis zu 
8. Ist also wohl eher unwahrscheinlich, dass da das Problem liegt.

>>> die Daten von der Key Card wurden fehlerhaft übertragen; das ist
> allerdings unwahrscheinlich bis unmöglich, falls Du die Daten der Key
> Card per zbarcam einliest, wie es in der Anleitung vorgeschlagen wird
>
> Na ja per zbarcam habe ich nichts eingelesen, einfach nur den Code mit
> einer iPhone Kamera ausgelesen und somit sollte es eh passen, zumindest
> stimmt die Seriennummer im Code.

Die Seriennummer ist nur ein paar Zeichen lang und wird in der Praxis eh 
gar nicht genutzt. Höchst problematisch wäre es hingegen, wenn sich 
bspw. in den 32-stelligen AES-Schlüssel, der Teil der im QR-Code 
kodierten Daten ist, irgendein winziger Fehler/Vertipper eingeschlichen 
hätte.

Von daher würde ich an Deiner Stelle nochmal ganz genau überprüfen, dass 
sich beim Übertragen der QR-Code-Daten auf den PC nicht irgendwo ein 
Fehler/Vertipper eingeschlichen hat. Vermutlich nicht, aber rein zur 
Sicherheit solltest Du es trotzdem tun, weil es eine potentielle 
Fehlerquelle ist, die man ganz schnell überprüfen/ausschliessen kann.

> Ich verwende eigentlich einen Raspberry Pi (ganz erste Generation) mit
> eine USB Bluetooth 4.0 dongle, kann sein, dass hier ein Problem ist?

Kann ich mir nicht vorstellen; das von Dir gepostete Log suggeriert, 
dass die Bluetooth-Kommunikation mit dem Lock problemlos funktioniert.

> Ich wollte eigentlich einfach einen Benutzer registrieren (übers Handy)
> dann die MAC-Adresse des Bluetooth Adapters kopieren und in den
> Raspberry eintragen, somit konnte ich die Registrierung übergehen, was
> aber nicht viel gebracht hat.

Dieser Ansatz kann leider per se nicht funktionieren. Zum Steuern des 
Türschlossantriebs benötigt man zwingend den 128-Bit langen 
AES-Schlüssel, der für jeden Benutzer unterschiedlich ist und bei der 
Benutzerregistrierung festgelegt wird. Über die Smartphone-App kannst Du 
zwar Benutzer registrieren, aber die Smartphone-App bietet keinerlei 
Möglichkeit, den benutzerspezifischen AES-Schlüssel anzeigen zu lassen.
Somit ist es nicht möglich, einen per Smartphone-App registrierten 
Benutzeraccount mit keyble zu benutzen, weil man nicht an den 
zugeordneten AES-Schlüssel herankommt. Die einmalige Registrierung eines 
neuen Benutzers per keyble-registeruser ist daher zwingend erforderlich, 
weil man nur so an den erforderten AES-Schlüssel kommt.

> Ich werde es mal mit einem neuen Raspi testen müssen..

Das kannst Du vermutlich sparen; das Problem liegt aller 
Wahrscheinlichkeit nicht am verwendeten Raspi.

Michi schrieb:
>> Habe eben mal auf deren Homepage nachgeschaut: Laut deren Aussage bis zu
>> 8. Ist also wohl eher unwahrscheinlich, dass da das Problem liegt.
>
> Dies kann ebenso ein Problem sein, da ich mehrere Leute im Büro habe,
> deswegen werde ich es mal überprüfen, danke für die Info!

Ah, ok, dann solltest Du das nur um sicher zu gehen wirklich überprüfen.

Also, überprüfe mal in der App unter "Einstellungen" alle folgenden 
Sachen:
- Ist der "Pairingsmodus aktiv"-Schalter eingeschaltet?
- Welche Versionsnummern werden Dir unter "Firmware" angezeigt? (Sowohl 
für "Firmware" als auch für "BLE-Chip")
- Wie viele Benutzer werden in der "Benutzerverwaltung" angezeigt?


>> Die Seriennummer ist nur ein paar Zeichen lang und wird in der Praxis eh
>> gar nicht genutzt. Höchst problematisch wäre es hingegen, wenn sich
>> bspw. in den 32-stelligen AES-Schlüssel, der Teil der im QR-Code
>> kodierten Daten ist, irgendein winziger Fehler/Vertipper eingeschlichen
>> hätte.
>
> Aha, okay, hast du einen Vorschlag wie man den AES-Schlüssel genauer
> auslesen kann, ohne eine Webcam zu verwenden?

Ich denke, wenn Du einfach nochmal gründlich und Zeichen für Zeichen 
überprüfst, ob die vom QR-Code-Reader Deines iPhones angezeigten 56 
Zeichen exakt übereinstimmen mit den Daten, die Du dem 
keyble-registeruser-Kommando übergeben hast, dann sollte das eigentlich 
genügen.

Michi schrieb:
>> dummer Fehler, der mir aber auch mehrfach passiert ist: Man hat
>> schlicht vergessen, vorher den "Unlock"-Button so lange zu drücken, bis
>> die gelbe LED blinkt
>
> ich bekomme die gleiche Fehlermeldung mit ANSWER_WITHOUT_SECURITY sogar
> wenn die gelbe Led nicht blinkt (Pairing modus nicht aktiv)

Habe ich vielleicht ungeschickt formuliert, denn genau das meinte ich:
FALLS man vergisst den Pairing-Modus zu aktivieren (die gelbe Led also 
nicht blinkt, während keyble-registeruser ausgeführt wird), dann kommt 
auf jeden Fall die ANSWER_WITHOUT_SECURITY-Nachricht, denn dann kann die 
Benutzerregistrierung (also das "Pairing") ja sowieso nicht klappen.

Michi schrieb:
>> Ah, ok, dann solltest Du das nur um sicher zu gehen wirklich überprüfen.
> Der Raspi wäre der 8te Benutzer, somit sollte es kein Problem sein

Eigentlich nicht, da hast Du Recht. Dennoch würde ich nicht 100%ig 
ausschliessen, dass es nicht doch iiirgendwie damit zu tun hat.

Wenn ich Dich richtig verstehe, wird der Türschlossantrieb bei Dir ja 
bereits von mehreren Leuten aktiv genutzt - das Gerät auf Werkszustand 
zurück zu setzen kommt also vermutlich nicht in Frage, nehme ich an?

Ansonsten könntest Du theoretisch z.B. noch probieren, einen weiteren 
Benutzer per Smartphone-App zu registrieren, um zu checken, ob das 
überhaupt auf diesem Weg erfolgreich funktioniert.

>> Ist der "Pairingsmodus aktiv"-Schalter eingeschaltet?
> Ja, hab den Pairmodus sogar ein-/ausgeschaltet.

Okay.

>> Welche Versionsnummern werden Dir unter "Firmware" angezeigt? (Sowohl
> für "Firmware" als auch für "BLE-Chip")
> Firmware 1.7
> BLE-Chip 1.5

Gut, das passt auch schon mal.

>> Ich denke, wenn Du einfach nochmal gründlich und Zeichen für Zeichen
>> überprüfst, ob die vom QR-Code-Reader Deines iPhones angezeigten 56
>> Zeichen exakt übereinstimmen mit den Daten, die Du dem
>> keyble-registeruser-Kommando übergeben hast, dann sollte das eigentlich
>> genügen.
>
> Erledigt, keinen Fehler hier entdeckt.

Okay, dann kann man das wohl auch das ausschliessen.

> Bekomme genau die gleichen debug-logs zurück, wurscht ob Pairing aktiv
> ist oder nicht..kann es hier der Timeout sein?

Meiner Einschätzung nach dürfte das nix mit Timeouts zu tun haben; laut 
Log schickst Du einen "PAIRING_REQUEST"-Befehl an den Türschlossantrieb, 
und bekommst von diesem auch eine Antwort darauf: Statt einer 
"ANSWER_WITH_SECURITY"-Nachricht (die Du bekommen würdest, wenn die 
Benutzerregistrierung erfolgreich wäre) bekommst Du allerdings eine 
"ANSWER_WITHOUT_SECURITY"-Nachricht, was zeigt, dass die 
Benutzerregistrierung (bzw. das "Pairing") aus irgendeinem Grund 
fehlgeschlagen ist bzw. vom Türschlossantrieb verweigert wurde.

Hmm, mir fällt gerade ein: Es gab mal irgendwann das Problem, dass die 
Registrierung nicht geklappt hat, wenn man die QR-Code-Daten per 
Kommandozeilen-Parameter übergeben hat, es hat damals nur funktioniert, 
wenn die QR-Code-Daten in keyble-registeruser "gepiped" hat; wie es eben 
der Fall ist, wenn man es wie in der Anleitung beschrieben per zbarcam 
macht.

Ich dachte eigentlich, dass ich dieses Problem behoben habe, aber ganz 
sicher bin ich mir jetzt plötzlich doch nicht mehr. Von daher könntest 
Du testweise mal noch probieren, keyble-registeruser so auszuführen:

1

echo "<QR-Code-Daten>" | DEBUG=simble:*,keyble:* keyble-registeruser

Ansonsten gehen mir jetzt die Ideen aus, an was es noch liegen könnte...

Michi schrieb:
>> Wenn ich Dich richtig verstehe, wird der Türschlossantrieb bei Dir ja
>> bereits von mehreren Leuten aktiv genutzt - das Gerät auf Werkszustand
>> zurück zu setzen kommt also vermutlich nicht in Frage, nehme ich an?
>
> Ganz genau, dies wäre nur die letzte mögliche Option, oder ich kann den
> Reset nur dann durchführen, wenn ich mir sicher bin, dass die
> Kommunikation zwischen Raspi und Eqiva funktionieren wird.

Kann ich gut nachvollziehen.

>> Hmm, mir fällt gerade ein: Es gab mal irgendwann das Problem, dass die
>> Registrierung nicht geklappt hat, wenn man die QR-Code-Daten per
>> Kommandozeilen-Parameter übergeben hat, es hat damals nur funktioniert,
>> wenn die QR-Code-Daten in keyble-registeruser "gepiped" hat; wie es eben
>> der Fall ist, wenn man es wie in der Anleitung beschrieben per zbarcam
>> macht.
>
> Okay, dann werde ich mal mit der Webcam und echo am Abend testen und
> mich wieder melden.
> Hoffentlich wird es klappen :)

Ja, probiere das mal aus. Wobei mir gerade einfällt: Falls es 
tatsächlich mit diesem Problem zusammenhängt, das es zumindest in einer 
früheren keyble-Version mal gab, dann könnte die Variante mit

1

echo "..." | keyble-registeruser

möglicherweise auch nicht funktionieren, weil dann der 
Eingabe-Datenstrom sofort geschlossen wird.

Ich glaube zwar tendenziell, dass das Problem eh nicht damit 
zusammenhängt, aber um auf Nummer zu gehen, wäre die beste Möglichkeit 
immer noch die in der Anleitung beschriebene Methode mit Webcam und 
zbarcam:

1

zbarcam --raw | keyble-registeruser

Das ist letztlich die sicherste Variante, denn in der Praxis habe ich 
nur die wirklich getestet.

> Die Software am Türschloss sollte eh aktuell sein oder?
> Hast du eigentlich die Protokollbeschreibung von dem Gerät?
> Vielleicht hat er ja einen anderen Chip und der empfängt andere Daten...

Du hast genau die gleichen Versionsnummern, die auch mein 
Türschlossantrieb meldet. Daran sollte es also nicht liegen, es dürfte 
auch die gleiche Hardware verbaut sein etc.

Eine Protokollbeschreibung habe ich leider nicht, eqiva will die 
Entwicklung alternativer Software offenbar nicht unterstützen (auch wenn 
sie das nicht exakt so formulieren). Offizielle Dokumentation gibt es 
daher nicht; das wenige, was ich über das Protokoll glaube zu wissen, 
habe ich recht mühsam durch reverse engineering etc. geschlussfolgert.

Bei mir ging es ohne Cam und ohne Pipe

Hendrik F. schrieb:
> Bei mir ging es ohne Cam und ohne Pipe

Danke für die Info. Dann habe ich mich wohl richtig erinnert, dass das 
Problem, das es da in einer früheren Version mal gab, mittlerweile 
behoben ist.

Allerdings bin ich dann jetzt auch wirklich am Ende meines Lateins, an 
was es mglw. liegen könnte, dass die Benutzerregistrierung bei Michi 
einfach nicht funktionieren will... :-(

Andre J. schrieb:
> Ich nutze einen NanoPi (Duo) mit Ubuntu 16.04.5 LTS

Wie hat das mit dem Versand bei dir funktioniert?
Hattest du Probleme wegen der Kapitalbereitstellungsprovision bei DHL 
oder wurde der NanoPi einfach per Post (China Post ausgewählt?) 
geliefert?

Musstest du beim Zoll etwas bezahlen?

so, hab das auf anhieb mit einem rpi zero w zum laufen bekommen.
meine vorherigen versuche mit einem rpi2 und eine rpi1 wurden von einer 
weiteren defekten SD-karte und zwei inkompatiblen BT-adaptern (ein mal 
definitiv nur BT2 und einer eigentlich mit BT4 aber doch nicht 
funktionierend) zunichte gemacht.

ich habe auch mit abgetippten QR-code ohne webcam registriert, nur das 
userumbenennen musste ich dann am handy machen, registrieren hat sofort 
funktioniert.

was mir aufgefallen ist: die scripte rödeln bei mi zwischen 12 und 20 
sekunden bis was passiert. in dieser zeit ist "node" mit 100% CPU dran. 
gibts bei nodejs eine möglichkeit, wie bei python, das kompilieren nicht 
jedes mal neu zu machen sondern das zu cachen?

ich habe schon sehr schwache batterien hier herumliegen, mit denen man 
den "schwache batterie" status noch abgreifen könnte. kann ich hierzu 
was an logs liefern? :-)

LG

Al O. schrieb:
> was mir aufgefallen ist: die scripte rödeln bei mi zwischen 12 und 20
> sekunden bis was passiert. in dieser zeit ist "node" mit 100% CPU dran.
> gibts bei nodejs eine möglichkeit, wie bei python, das kompilieren nicht
> jedes mal neu zu machen sondern das zu cachen?

Verstehe ich Dich richtig, bei Dir auf dem rpi Zero dauert es ca. 12-20 
Sekunden Start-up-time, bis keyble überhaupt anfängt, was zu tun? Und Du 
denkst, dass das vor allem daher kommt, dass node bis dahin so Sachen 
macht wie den Javascript-Code just-in-time zu kompilieren, weshalb Du 
Dich fragst, ob es bei Node nicht auch sowas wie die .pyc-Dateien von 
Python gibt, um das Ganze zu beschleunigen?

Wenn ja: Da ist mir jetzt keine Möglichkeit bekannt; das muss allerdings 
nix heissen, ich habe jetzt nicht sooo viel Ahnung von Node.

Eine Möglichkeit dieses Problem zu umgehen wäre aber evtl., 
keyble-sendcommand nicht immer wieder neu aufzurufen, sondern dauerhaft 
laufen zu lassen. So wie es bspw. in der README im Abschnitt "Piping 
data into keyble-sendcommand" am Beispiel der MQTT-Integration getan 
wird:
https://github.com/oyooyo/keyble#piping-data-into-keyble-sendcommand

> ich habe schon sehr schwache batterien hier herumliegen, mit denen man
> den "schwache batterie" status noch abgreifen könnte. kann ich hierzu
> was an logs liefern? :-)

Das ist eigentlich nicht nötig, an schwachen Batterien mangelt es bei 
mir nicht... ;-) Aber im Ernst: Fremde Logs würden da momentan 
vermutlich gar nichts bringen, denn bislang gibt der Log-Output die 
empfangenen Nachrichten ja nur im verschlüsselten Rohzustand aus. Falls 
der Batteriezustand also in einer verschlüsselten Nachricht übermittelt 
wird, dann würde mir Dein Log ohne Deinen zugehörigen geheimen 
Benutzer-Schlüssel gar nichts bringen...

Das hat mich allerdings darauf gebracht, dass ich eben mal zusätzlichen 
Debug-Output in keyble eingebaut habe, durch den gesendete und 
empfangene Nachrichten im unverschlüsselten Zustand als 
"keyble:communication"-Debug-Meldungen angezeigt werden können. Das 
sollte es auch Allen leichter machen, die das Protokoll selbst weiter 
analysieren wollen. Habe es als Version 0.1.13 veröffentlicht, 
allerdings nicht getestet.

Anyway, Du hättest also gerne eine Möglichkeit in keyble, den 
Batterie-Status abzufragen oder wie?

Ich weiß natürlich nicht, ob die bt kommunikation inkl. 
Verbindungsaufbau so lange braucht, aber nachdem ich im top "node" auf 
100% sehe denke ich eher dsssü dssü kompilieren süo lange dauert. Die 12 
bis 20 sec habe ich mit "time keyble-sendcommand ..." gemessen.

Ich werd heut das piping anschauen. Jetzt verteh uch auch für was man 
das verbindungs-idle-timeout setzen kann. :-)

Ja, den leeren batteriestatus abfragen wäre super. Ich will den status 
des schlosses mit auf einem display in der küche visualisieren, alle 5 
minuten den schließstatus abfragen (bin neugierig wie sich das auf die 
batterien auswirkt) und remote (ohne handy) auf- und zusperren können. 
Aber eben auch wissen ob die batterien am leerwerden sind.

Lg Alois

Michi schrieb:
> By the way, die Kommunikation zwischen Raspi und dem KeyBLE dauert mind.
> 10 sec. bis der Smart Lock eine Anfrage bekommt, aber bist jetzt weiss
> ich noch nicht wieso so lange, ich nehme an, dass der Raspi zuerst mal
> die Verbindung aufbauen muss, und bis er ein Response bekommt - dauert
> es halt.
> Die Verbindung aktiv zu halten wäre eine Möglichkeit, aber falls sich
> der Raspi aufhängt und die Verbindung zum Lock aktiv ist - dann kommst
> du nicht mal mit der Eqiva App rein.
>
> Joachim, sag mal, gibt es eine Möglichkeit die Antwort vom SmartLock
> schlneller zu bekommen?

Da sehe ich auf Anhieb leider nicht sooo viel Optimierungspotential.
Wenn keyble-sendcommand mit Debug-Output starte (DEBUG=keyble:*,simble:* 
keyble-sendcommand ...) und dann den "open" Befehl sende, erhalte ich 
folgende Ausgabe:

1

open

2

  simble:event Peripheral 00:1a:22:0a:65:af : Event "connected" +0ms

3

  simble:event Peripheral 00:1a:22:0a:65:af : Event "discovered" +477ms

4

  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send "80 02 XX XX XX XX XX" +0ms

5

  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Receive "80 03 XX XX XX XX XX" +42ms

6

  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Event "data_received" +598ms

7

  keyble:events Event: received:fragment +0ms

8

  keyble:events Event: received:message +1ms

9

  keyble:events Event: received:message:CONNECTION_INFO +0ms

10

  keyble:events Event: nonces_exchanged +1ms

11

  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send "80 87 XX XX XX XX XX" +18ms

12

  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Receive "80 83 XX XX XX XX XX" +71ms

13

  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Event "data_received" +89ms

14

  keyble:events Event: received:fragment +85ms

15

  keyble:events Event: received:message +2ms

16

  keyble:events Event: status_update +1ms

17

  keyble:events Event: status:active +0ms

18

  keyble:events Event: status_change +0ms

19

active

Daraus schlussfolgere ich: Nachdem die Bluetooth-Verbindung aufgebaut 
wurde, dauert es ca. 0.5 Sekunden (477ms), um die Services und 
Charakteristiken zu discovern. Hier liessen sich vielleicht noch ein 
paar ms einsparen, weil einfach alle Services und Charakteristiken 
discovert werden, statt nur die wirklich benötigten.
Danach dauert es nochmal ca. 0.6 Sekunden (598ms), um die 
Bluetooth-Verbindung abzusichern/zu verschlüsseln, und dann nochmal ca. 
0.1 Sekunden (89ms), bis sich der Türschlossantrieb in Bewegung setzt 
("active").

Nachdem die Bluetooth-Verbindung erst einmal aufgebaut wurde, dauert es 
bei mir also "nur" ca. 1.2 Sekunden, bis sich der Türschlossantrieb in 
Bewegung setzt. Die meiste Zeit scheint also drauf zu gehen, um die 
Bluetooth-Verbindung zum Türschlossantrieb erst einmal aufzubauen; und 
da wüsste ich momentan nicht, wie ich das beschleunigen könnte.

Die Verbindung zum Türschlossantrieb dauerhaft aufrecht zu erhalten, 
wäre natürlich eine Möglichkeit, um die Zeitspanne bis zum aktiv werden 
massiv zu verkürzen. Allerdings gibt es da halt wirklich zwei Probleme:
- kein anderes Gerät könnte sich mehr mit dem Türschlossantrieb 
verbinden
- der Energieverbrauch des Türschlossantriebs würde bei einer 
dauerhaften Bluetooth-Verbindung vermutlich stark ansteigen, die 
Batterien also viel schneller leer werden.

Wer es trotzdem mal testweise ausprobieren will, dass die 
Bluetooth-Verbindung dauerhaft aufrecht erhalten bleibt, der kann 
keyble-sendcommand mit dem Kommandozeilenparameter 
"--auto_disconnect_time 0" starten.

Daniel schrieb:
> TypeError: Cannot read property 'get_discovered_characteristic' of
> undefined
>     at simble.scan_for_peripheral.then.then
> (/usr/lib/node_modules/keyble/keyble.js:820:56)

Nach kurzem Blick auf den Code an der entsprechenden Stelle würde ich 
das so interpretieren, dass sich keyble erfolgreich mit dem 
Türschlossantrieb verbindet, dann aber aus irgendeinem Grund den zur 
Kommunikation mit dem Lock erforderlichen Bluetooth-Service nicht 
findet.

Das verblüfft mich, darauf kann ich mir auf Anhieb keinen Reim machen. 
Ich versuche in den nächsten Tagen mal noch mehr Debug-Output 
einzubauen, mit dem man diesem Problem hoffentlich mehr auf den Grund 
gehen kann.

Mirko W. schrieb:
> Hallo,
> ist schon wer im Protokoll für die Thermostaten auf die aktuelle
> Ventilstellung gestoßen? Falls die von außen les-/schreibbar wäre,
> könnte man so seine eigene Regelung oder zumindest Modellbildung
> vornehmen, aber die Chancen stehen vermutlich eher schlecht, oder?

Ich zumindest konnte in den Protokollen nichts dergleichen entdecken.
Ich konnte nicht einmal eine Möglichkeit finden, die vom Thermostat 
gemessene "Ist-Temperatur" abzufragen...

Joachim S. schrieb:
> Nach kurzem Blick auf den Code an der entsprechenden Stelle würde ich
> das so interpretieren, dass sich keyble erfolgreich mit dem
> Türschlossantrieb verbindet, dann aber aus irgendeinem Grund den zur
> Kommunikation mit dem Lock erforderlichen Bluetooth-Service nicht
> findet.

Kanns im Moment nicht prüfen, aber vielleicht gibt's ne neue 
Software-Version vom Lock? Wäre Mal interessant zu wissen, welche bei 
dir installiert ist @Daniel.

Hallo,

zu diesem Punkt
"keyble-sendcommand aufrufe, erhalte ich:
  simble:event Peripheral 00:1a:22:0a:6e:7c : Event "connected" +0ms
Error: Promise did not resolve within 45000 milliseconds"

leider hat sich da nichts getan. Interessant ist, dass es mit dem 
anderen Smartlock (ich habe zwei) wunderbar funktioniert.

Hast du schon zusätzliche Debug-Infos hinzugefügt, damit wir der Sache 
auf den Grund gehen können?

Gruß&Danke,
Hendrik

Hendrik F. schrieb:
> Hast du schon zusätzliche Debug-Infos hinzugefügt, damit wir der Sache
> auf den Grund gehen können?

Ich habe eben zwei neue Versionen von keyble und simble (Wrapper für die 
verwendete Bluetooth-Library "noble") veröffentlicht.

Das einzige, was sich geändert hat, ist, dass es etwas mehr Debug-Output 
gibt.
Wer keine Probleme mit keyble hat, muss also nicht unbedingt updaten.
Wer Probleme hat, bekommt nach dem Updaten mit

1

DEBUG=simble:*,keyble:* keyble-...

jetzt etwas mehr Output, das eventuell helfen könnte, das Problem besser 
nachvollziehen zu können.

Hallo Hendrik,

Hendrik Friedel schrieb:
> Genau deshalb habe ich es als PR gemacht. Ich habe ja nicht einfach die
> Dateien erzeugt, sondern auch die Verzeichnisstruktur. Mit einem
> git-pull bekommt man also direkt die richtige Verzeichnisstruktur.
> Das ist in meinen Augen deutlich besser/nutzerfreundlich als "kopiere
> dies hier hin/das dahin".

Ich bin mir ehrlich gesagt gerade nicht ganz sicher, ob ich diesen 
Abschnitt 100%ig richtig verstanden habe. Was vielleicht damit 
zusammenhängt, dass ich noch ziemlich viele Wissenslücken habe, was 
"Pull Requests" und Git im Allgemeinen betrifft.
Speziell den Teil mit der "richtigen Verzeichnisstruktur" habe ich 
irgendwie nicht ganz verstanden.

> Mir ist aber beides Recht. Sag an, und ich mache es entsprechen fertig.

Ich bin momentan immer noch unschlüssig (auch weil ich den obigen 
Abschnitt halt eventuell nicht richtig verstanden habe).

Da dafür aber so oder so dafür noch Dokumentation eingefügt und erklärt 
werden muss, wie man die Dateien anpassen muss, würde ich Dich bitten, 
zunächst einmal noch einen weiteren PR einzureichen, in dem Du in der 
Datei README.md am Ende einen Abschnitt a la "Automatically starting 
keyble on boot" hinzufügst, in dem Du erklärst, was zu tun ist, damit 
keyble beim Booten automatisch startet. Füge den Inhalt der beiden 
Dateien (.service und .sh) als Vorlage direkt in die Dokumentation ein, 
und beschreibe, welche Abschnitte dieser Dateien noch wie angepasst 
werden müssen.

Wenn Du mir das weiter oben nochmal etwas ausführlicher erklärst und ich 
dann ebenfalls einen Vorteil darin sehe, die Dateien zusätzlich auch 
direkt als Dateien dem Repository hinzuzufügen, dann kann man das im 
zweiten Schritt immer noch tun.

Hallo,

ich habe jetzt keyble aktualisiert.
Danach funktionierte mein Problemschloss erstmal und ich dachte, ich 
hätte hier einen typischen Vorführeffekt.



 DEBUG=simble:*,keyble:* /usr/local/bin/keyble-sendcommand  --address 
xx:xx:xx:xx:xx:xx --user_id 1 --user_key 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --command unlock
  simble:info Starting to scan for peripheral... +0ms
  simble:info   Scanned peripheral 00:1a:22:0a:6f:0d (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +104ms
  simble:info   Scanned peripheral xx:xx:xx:xx:xx:xx (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +18ms
  simble:info Peripheral xx:xx:xx:xx:xx:xx matches filters, stopping 
scanning +3ms
  simble:info Connecting to peripheral xx:xx:xx:xx:xx:xx... +10ms
  simble:event Peripheral xx:xx:xx:xx:xx:xx : Event "connected" +0ms
  simble:info Connected to peripheral xx:xx:xx:xx:xx:xx +2s
  simble:info Discovering peripheral xx:xx:xx:xx:xx:xx... +7ms
  simble:info Peripheral xx:xx:xx:xx:xx:xx discovered: +505ms
  simble:info   Service 00001800-1000-8000-0080-5f9b34fb +2ms
  simble:info     Characteristic 00002a00-1000-8000-0080-5f9b34fb (read) 
+2ms
  simble:info     Characteristic 00002a01-1000-8000-0080-5f9b34fb (read) 
+3ms
  simble:info     Characteristic 00002a02-1000-8000-0080-5f9b34fb (read) 
+3ms
  simble:info     Characteristic 00002a03-1000-8000-0080-5f9b34fb 
(write) +2ms
  simble:info     Characteristic 00002a04-1000-8000-0080-5f9b34fb (read) 
+4ms
  simble:info   Service 00001801-1000-8000-0080-5f9b34fb +2ms
  simble:info     Characteristic 00002a05-1000-8000-0080-5f9b34fb (read, 
indicate) +4ms
  simble:info   Service 0000180a-1000-8000-0080-5f9b34fb +3ms
  simble:info     Characteristic 00002a29-1000-8000-0080-5f9b34fb (read) 
+3ms
  simble:info     Characteristic 00002a24-1000-8000-0080-5f9b34fb (read) 
+3ms
  simble:info   Service 58e06900-15d8-11e6-b737-0002a5d5c51b +3ms
  simble:info     Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b 
(read, write) +3ms
  simble:info     Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b 
(read, write, notify) +3ms
  simble:info   Service 3aee5da0-15db-11e6-a29b-0002a5d5c51b +3ms
  simble:info     Characteristic 3f623280-15db-11e6-afc6-0002a5d5c51b 
(write, notify, indicate) +3ms
  simble:info     Characteristic 43639680-15db-11e6-9b99-0002a5d5c51b 
(writeWithoutResponse, write) +3ms
  simble:info     Characteristic 4747fca0-15db-11e6-9dd6-0002a5d5c51b 
(read) +2ms
  simble:event Peripheral xx:xx:xx:xx:xx:xx : Event "discovered" +579ms
  keyble:communication Sending message of type CONNECTION_REQUEST, data 
bytes <01 9a 4b b4 bb 4e 60 f3 fc>, data 
{"user_id":1,"local_session_nonce":[154,75,180,187,78,96,243,252]} +0ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send 
"80 02 01 9a 4b b4 bb 4e 60 f3 fc 00 00 00 00 00" +0ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Receive "80 03 01 cc 33 42 50 89 38 da e9 00 10 17 00 00" +67ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Event "data_received" +705ms
  keyble:events Event: received:fragment +0ms
  keyble:communication Received message of type CONNECTION_INFO, data 
bytes <01 cc 33 42 50 89 38 da e9 00 10 17 00 00>, data 
{"user_id":1,"remote_session_nonce":[204,51,66,80,137,56,218,233],"bootl 
oader_version":16,"application_version":23}  +129ms
  keyble:events Event: received:message +20ms
  keyble:events Event: received:message:CONNECTION_INFO +2ms
  keyble:events Event: nonces_exchanged +5ms
  keyble:communication Sending message of type COMMAND, data bytes <01>, 
data {"command_id":1} +13ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send 
"80 87 bf 0b 32 49 55 9f 35 60 00 01 34 0d 95 94" +198ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Receive "80 83 c2 e9 0f 8f a0 6f ae 33 00 01 88 bb b0 14" +79ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Event "data_received" +275ms
  keyble:events Event: received:fragment +239ms
  keyble:communication Received message of type STATUS_INFO, data bytes 
<71 01 09 00 10 17 00 00>, data 
{"a":true,"user_right_type":3,"e":false,"f":false,"g":true,"h":false,"i" 
:false,"j":true,"lock_status":1,"l":16,"m":23}  +262ms
  keyble:events Event: received:message +29ms
  keyble:events Event: received:message:STATUS_INFO +2ms
  keyble:events Event: status_update +3ms
  keyble:events Event: status:MOVING +2ms
  keyble:events Event: status_change +3ms
MOVING
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Receive "80 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00" +4s
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Event "data_received" +4s
  keyble:events Event: received:fragment +4s
  keyble:communication Received message of type 
STATUS_CHANGED_NOTIFICATION, data bytes <00 00 00 00 00 00 00 00 00 00 
00 00 00 00>, data {} +4s
  keyble:events Event: received:message +9ms
  keyble:events Event: received:message:STATUS_CHANGED_NOTIFICATION +3ms
  keyble:communication Sending message of type STATUS_REQUEST, data 
bytes <12 0c 1c 09 3a 18>, data {"date":"2018-12-28T09:58:24.000Z"} 
+20ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send 
"80 82 56 54 fb b4 31 f3 2d 73 00 02 be 68 b0 96" +59ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Receive "80 83 97 fd 96 a4 73 15 f2 75 00 02 54 4b a3 dc" +46ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Event "data_received" +106ms
  keyble:events Event: received:fragment +93ms
  keyble:communication Received message of type STATUS_INFO, data bytes 
<71 01 0a 00 10 17 00 00>, data 
{"a":true,"user_right_type":3,"e":false,"f":false,"g":true,"h":false,"i" 
:false,"j":true,"lock_status":2,"l":16,"m":23}  +102ms
  keyble:events Event: received:message +25ms
  keyble:events Event: received:message:STATUS_INFO +2ms
  keyble:events Event: status_update +3ms
  keyble:events Event: status:UNLOCKED +3ms
  keyble:events Event: status_change +2ms
UNLOCKED




Ich habe dann meine mosquitto -> keyble -> mosquitto Kette wieder 
gestartet und über MQTT ein Kommando geschickt.

Mein Problemschloss ging wieder nicht. Gleichzeitig funktionierte das 
andere Schloss über MQTT.

Also dachte ich kurz an ein Problem in meinem Kommando -könnte ja ein 
Tippfehler sein und habe das Kommando nochmal an der Kommandozeile 
eingegeben.


root@raspberrypi:~# DEBUG=simble:*,keyble:* 
/usr/local/bin/keyble-sendcommand  --address xx:xx:xx:xx:xx:xx --user_id 
1 --user_key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --command lock
^Ap  simble:info Starting to scan for peripheral... +0ms
  simble:info   Scanned peripheral 00:1a:22:0a:6f:0d (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +932ms
Error: Promise did not resolve within 45000 milliseconds
root@raspberrypi:~# DEBUG=simble:*,keyble:* 
/usr/local/bin/keyble-sendcommand  --address xx:xx:xx:xx:xx:xx --user_id 
1 --user_key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --command lock
  simble:info Starting to scan for peripheral... +0ms
  simble:info   Scanned peripheral 00:1a:22:0a:6f:0d (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +1s
  simble:info   Scanned peripheral xx:xx:xx:xx:xx:xx (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +29s
  simble:info Peripheral xx:xx:xx:xx:xx:xx matches filters, stopping 
scanning +14ms
  simble:info Connecting to peripheral xx:xx:xx:xx:xx:xx... +61ms
noble warning: unknown handle 65 disconnected!
  simble:event Peripheral xx:xx:xx:xx:xx:xx : Event "connected" +0ms
  simble:info Connected to peripheral xx:xx:xx:xx:xx:xx +1s
  simble:info Discovering peripheral xx:xx:xx:xx:xx:xx... +7ms
Error: Promise did not resolve within 45000 milliseconds


DEBUG=simble:*,keyble:* /usr/local/bin/keyble-sendcommand  --address 
xx:xx:xx:xx:xx:xx --user_id 1 --user_key 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --command lock
  simble:info Starting to scan for peripheral... +0ms
  simble:info   Scanned peripheral 00:1a:22:0a:6f:0d (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +126ms
  simble:info   Scanned peripheral xx:xx:xx:xx:xx:xx (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +483ms
  simble:info Peripheral xx:xx:xx:xx:xx:xx matches filters, stopping 
scanning +3ms
  simble:info Connecting to peripheral xx:xx:xx:xx:xx:xx... +10ms
  simble:event Peripheral xx:xx:xx:xx:xx:xx : Event "connected" +0ms
  simble:info Connected to peripheral xx:xx:xx:xx:xx:xx +3s
  simble:info Discovering peripheral xx:xx:xx:xx:xx:xx... +10ms
  simble:info Peripheral xx:xx:xx:xx:xx:xx discovered: +511ms
  simble:info   Service 00001800-1000-8000-0080-5f9b34fb +2ms
  simble:info     Characteristic 00002a00-1000-8000-0080-5f9b34fb (read) 
+3ms
  simble:info     Characteristic 00002a01-1000-8000-0080-5f9b34fb (read) 
+3ms
  simble:info     Characteristic 00002a02-1000-8000-0080-5f9b34fb (read) 
+2ms
  simble:info     Characteristic 00002a03-1000-8000-0080-5f9b34fb 
(write) +3ms
  simble:info     Characteristic 00002a04-1000-8000-0080-5f9b34fb (read) 
+2ms
  simble:info   Service 00001801-1000-8000-0080-5f9b34fb +2ms
  simble:info     Characteristic 00002a05-1000-8000-0080-5f9b34fb (read, 
indicate) +2ms
  simble:info   Service 0000180a-1000-8000-0080-5f9b34fb +3ms
  simble:info     Characteristic 00002a29-1000-8000-0080-5f9b34fb (read) 
+2ms
  simble:info     Characteristic 00002a24-1000-8000-0080-5f9b34fb (read) 
+2ms
  simble:info   Service 58e06900-15d8-11e6-b737-0002a5d5c51b +2ms
  simble:info     Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b 
(read, write) +2ms
  simble:info     Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b 
(read, write, notify) +2ms
  simble:info   Service 3aee5da0-15db-11e6-a29b-0002a5d5c51b +1ms
  simble:info     Characteristic 3f623280-15db-11e6-afc6-0002a5d5c51b 
(write, notify, indicate) +2ms
  simble:info     Characteristic 43639680-15db-11e6-9b99-0002a5d5c51b 
(writeWithoutResponse, write) +2ms
  simble:info     Characteristic 4747fca0-15db-11e6-9dd6-0002a5d5c51b 
(read) +5ms
  simble:event Peripheral xx:xx:xx:xx:xx:xx : Event "discovered" +582ms
  keyble:communication Sending message of type CONNECTION_REQUEST, data 
bytes <01 c7 4d b1 2d d1 a7 2b b5>, data 
{"user_id":1,"local_session_nonce":[199,77,177,45,209,167,43,181]} +0ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send 
"80 02 01 c7 4d b1 2d d1 a7 2b b5 00 00 00 00 00" +0ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Receive "80 03 01 ff 85 a5 7a 90 b6 5e 4c 00 10 17 00 00" +65ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Event "data_received" +696ms
  keyble:events Event: received:fragment +0ms
  keyble:communication Received message of type CONNECTION_INFO, data 
bytes <01 ff 85 a5 7a 90 b6 5e 4c 00 10 17 00 00>, data 
{"user_id":1,"remote_session_nonce":[255,133,165,122,144,182,94,76],"boo 
tloader_version":16,"application_version":23}  +116ms
  keyble:events Event: received:message +15ms
  keyble:events Event: received:message:CONNECTION_INFO +2ms
  keyble:events Event: nonces_exchanged +5ms
  keyble:communication Sending message of type COMMAND, data bytes <00>, 
data {"command_id":0} +12ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send 
"80 87 20 7c 8d ee 88 a7 9b a6 00 01 d3 ba 39 d4" +187ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Receive "80 83 19 30 b4 c9 6e 9a ee 65 00 01 bb 50 e9 e7" +78ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Event "data_received" +264ms
  keyble:events Event: received:fragment +238ms
  keyble:communication Received message of type STATUS_INFO, data bytes 
<71 01 09 00 10 17 00 00>, data 
{"a":true,"user_right_type":3,"e":false,"f":false,"g":true,"h":false,"i" 
:false,"j":true,"lock_status":1,"l":16,"m":23}  +262ms
  keyble:events Event: received:message +29ms
  keyble:events Event: received:message:STATUS_INFO +3ms
  keyble:events Event: status_update +2ms
  keyble:events Event: status:MOVING +3ms
  keyble:events Event: status_change +3ms
MOVING
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Receive "80 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00" +4s
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Event "data_received" +4s
  keyble:events Event: received:fragment +3s
  keyble:communication Received message of type 
STATUS_CHANGED_NOTIFICATION, data bytes <00 00 00 00 00 00 00 00 00 00 
00 00 00 00>, data {} +4s
  keyble:events Event: received:message +10ms
  keyble:events Event: received:message:STATUS_CHANGED_NOTIFICATION +3ms
  keyble:communication Sending message of type STATUS_REQUEST, data 
bytes <12 0c 1c 09 3a 2f>, data {"date":"2018-12-28T09:58:47.000Z"} 
+19ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send 
"80 82 2a 94 6f 2c 40 57 17 50 00 02 4d d0 7d 6e" +59ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Receive "80 83 ae 61 ae 51 0c fd 6e b7 00 02 07 db bb 7d" +46ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : 
Event "data_received" +104ms
  keyble:events Event: received:fragment +90ms
  keyble:communication Received message of type STATUS_INFO, data bytes 
<71 01 0b 00 10 17 00 00>, data 
{"a":true,"user_right_type":3,"e":false,"f":false,"g":true,"h":false,"i" 
:false,"j":true,"lock_status":3,"l":16,"m":23}  +93ms
  keyble:events Event: received:message +18ms
  keyble:events Event: received:message:STATUS_INFO +2ms
  keyble:events Event: status_update +3ms
  keyble:events Event: status:LOCKED +3ms
  keyble:events Event: status_change +2ms
LOCKED


Kannst du am Log erkennen, woran es liegt?

Gruß,
Hendrik

Hallo,

die Dokumentation habe ich jetzt auch als PR geschickt.

Gruß,
Hendrik

Hendrik F. schrieb:
>   simble:info   Scanned peripheral xx:xx:xx:xx:xx:xx (Name:"KEY-BLE",
> advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +29s
>   simble:info Peripheral xx:xx:xx:xx:xx:xx matches filters, stopping
> scanning +14ms
>   simble:info Connecting to peripheral xx:xx:xx:xx:xx:xx... +61ms
> noble warning: unknown handle 65 disconnected!
>   simble:event Peripheral xx:xx:xx:xx:xx:xx : Event "connected" +0ms
>   simble:info Connected to peripheral xx:xx:xx:xx:xx:xx +1s
>   simble:info Discovering peripheral xx:xx:xx:xx:xx:xx... +7ms
> Error: Promise did not resolve within 45000 milliseconds
> [...]
> Kannst du am Log erkennen, woran es liegt?

Das Log lässt vermuten, dass das Problem irgendwie mit dieser 
Fehlermeldung zu tun hat:
> noble warning: unknown handle 65 disconnected!

Leider sagt mir diese Fehlermeldung nichts, und als ich eben mal danach 
gesucht habe, bin ich auch nicht so richtig schlau geworden. Man findet 
bspw. mehrere offene Issues von anderen Github-Projekten die die 
"noble"-Library verwenden, und wo Leute diese Fehlermeldung (mit einer 
anderen Handle-Nummer) nennen, ohne dass es eine Lösung dafür gibt.

Eventuell könnte es helfen, auch noch die "noble"-Debug-Meldungen 
einzuschalten, also statt "DEBUG=simble:*,keyble:*" einfach "DEBUG=*" zu 
verwenden. Wobei dennoch ziemlich fraglich ist, ob ich aus den 
zusätzlichen noble-Debug-Meldungen irgendwie schlauer werde... :-(

Hallo,

danke für das Mergen des PR.

das handle - disconnected habe ich in diesem Log nicht mehr:
DEBUG="*" /usr/local/bin/keyble-sendcommand  --address xx:xx:xx:xx:xx:xx 
--user_id 3 --user_key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --command 
unlock
  hci setting filter to: 1600000020c10000000000400000 +0ms
  hci set event mask - writing: 01010c08fffffbff07f8bf3d +56ms
  hci set le event mask - writing: 010120081f00000000000000 +8ms
  hci read local version - writing: 01011000 +5ms
  hci write LE host supported - writing: 016d0c020100 +5ms
  hci read LE host supported - writing: 016c0c00 +5ms
  hci read bd addr - writing: 01091000 +5ms
  hci onSocketData: 040e0401010c00 +41ms
  hci   event type = 4 +4ms
  hci   sub event type = 14 +3ms
  hci           cmd = 3073 +6ms
  hci           status = 0 +3ms
  hci           result =  +2ms
  hci onSocketData: 040e0401012000 +8ms
  hci   event type = 4 +2ms
  hci   sub event type = 14 +2ms
  hci           cmd = 8193 +3ms
  hci           status = 0 +3ms
  hci           result =  +2ms
  hci onSocketData: 040e0c01011000076801070f000922 +4ms
  hci   event type = 4 +1ms
  hci   sub event type = 14 +2ms
  hci           cmd = 4097 +4ms
  hci           status = 0 +2ms
  hci           result = 076801070f000922 +2ms
  hci set scan enabled - writing: 010c20020001 +7ms
  hci set scan parameters - writing: 010b200701100010000000 +5ms
  hci onSocketData: 040e04016d0c00 +4ms
  hci   event type = 4 +2ms
  hci   sub event type = 14 +3ms
  hci           cmd = 3181 +2ms
  hci           status = 0 +2ms
  hci           result =  +3ms
  hci onSocketData: 040e06016c0c000100 +4ms
  hci   event type = 4 +2ms
  hci   sub event type = 14 +2ms
  hci           cmd = 3180 +4ms
  hci           status = 0 +2ms
  hci           result = 0100 +3ms
  hci                   le = 1 +2ms
  hci                   simul = 0 +2ms
  hci onSocketData: 040e0a01091000aa93c1eb27b8 +2ms
  hci   event type = 4 +2ms
  hci   sub event type = 14 +2ms
  hci           cmd = 4105 +2ms
  hci           status = 0 +3ms
  hci           result = aa93c1eb27b8 +2ms
  hci address = b8:27:eb:c1:93:aa +5ms
  noble addressChange b8:27:eb:c1:93:aa +4ms
  hci onSocketData: 040e04010c200c +5ms
  hci   event type = 4 +2ms
  hci   sub event type = 14 +3ms
  hci           cmd = 8204 +2ms
  hci           status = 12 +2ms
  hci           result =  +3ms
  hci onSocketData: 040e04010b2000 +5ms
  hci   event type = 4 +1ms
  hci   sub event type = 14 +2ms
  hci           cmd = 8203 +3ms
  hci           status = 0 +3ms
  hci           result =  +3ms
  noble stateChange poweredOn +6ms
  simble:info Starting to scan for peripheral... +0ms
  hci set scan enabled - writing: 010c20020001 +25ms
  hci set scan parameters - writing: 010b200701100010000000 +3ms
  hci set scan enabled - writing: 010c20020101 +3ms
  hci onSocketData: 040e04010c200c +4ms
  hci   event type = 4 +2ms
  hci   sub event type = 14 +2ms
  hci           cmd = 8204 +2ms
  hci           status = 12 +3ms
  hci           result =  +2ms
  hci onSocketData: 040e04010b2000 +3ms
  hci   event type = 4 +2ms
  hci   sub event type = 14 +2ms
  hci           cmd = 8203 +2ms
  hci           status = 0 +3ms
  hci           result =  +2ms
  hci onSocketData: 040e04010c2000 +3ms
  hci   event type = 4 +1ms
  hci   sub event type = 14 +2ms
  hci           cmd = 8204 +2ms
  hci           status = 0 +3ms
  hci           result =  +2ms
  noble scanStart +3ms
  hci onSocketData: 
043e2a020100007c6e0a221a001e02010511071bc5d5a5020037b7e611d8150069e05808 
094b45592d424c45c4  +488ms
  hci   event type = 4 +2ms
  hci   sub event type = 62 +2ms
  hci           LE meta event type = 2 +2ms
  hci           LE meta event status = 1 +2ms
  hci           LE meta event data = 
00007c6e0a221a001e02010511071bc5d5a5020037b7e611d8150069e05808094b45592d 
424c45c4  +3ms
  hci                   type = 0 +6ms
  hci                   address = 00:1a:22:0a:6e:7c +3ms
  hci                   address type = public +3ms
  hci                   eir = 
02010511071bc5d5a5020037b7e611d8150069e05808094b45592d424c45 +2ms
  hci                   rssi = -60 +2ms
  gap advertisement = 
{"localName":"KEY-BLE","serviceData":[],"serviceUuids":["58e0690015d811e 
6b7370002a5d5c51b"],"solicitationServiceUuids":[],"serviceSolicitationUu 
ids":[]}  +13ms
  hci onSocketData: 
043e1d020104007c6e0a221a001108094b45592d424c4507ff001a220a6e7cc2 +4ms
  hci   event type = 4 +2ms
  hci   sub event type = 62 +2ms
  hci           LE meta event type = 2 +2ms
  hci           LE meta event status = 1 +3ms
  hci           LE meta event data = 
04007c6e0a221a001108094b45592d424c4507ff001a220a6e7cc2 +2ms
  hci                   type = 4 +3ms
  hci                   address = 00:1a:22:0a:6e:7c +3ms
  hci                   address type = public +3ms
  hci                   eir = 08094b45592d424c4507ff001a220a6e7c +2ms
  hci                   rssi = -62 +2ms
  gap advertisement = 
{"localName":"KEY-BLE","manufacturerData":{"type":"Buffer","data":[0,26, 
34,10,110,124]},"serviceData":[],"serviceUuids":["58e0690015d811e6b73700 
02a5d5c51b"],"solicitationServiceUuids":[],"serviceSolicitationUuids":[] 
}  +4ms
  simble:info   Scanned peripheral 00:1a:22:0a:6e:7c (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +652ms
  hci onSocketData: 
043e2a020100000d6f0a221a001e02010511071bc5d5a5020037b7e611d8150069e05808 
094b45592d424c45b4  +406ms
  hci   event type = 4 +2ms
  hci   sub event type = 62 +2ms
  hci           LE meta event type = 2 +5ms
  hci           LE meta event status = 1 +3ms
  hci           LE meta event data = 
00000d6f0a221a001e02010511071bc5d5a5020037b7e611d8150069e05808094b45592d 
424c45b4  +2ms
  hci                   type = 0 +3ms
  hci                   address = xx:xx:xx:xx:xx:xx +6ms
  hci                   address type = public +2ms
  hci                   eir = 
02010511071bc5d5a5020037b7e611d8150069e05808094b45592d424c45 +6ms
  hci                   rssi = -76 +3ms
  gap advertisement = 
{"localName":"KEY-BLE","serviceData":[],"serviceUuids":["58e0690015d811e 
6b7370002a5d5c51b"],"solicitationServiceUuids":[],"serviceSolicitationUu 
ids":[]}  +5ms
  hci onSocketData: 
043e1d020104000d6f0a221a001108094b45592d424c4507ff001a220a6f0db5 +5ms
  hci   event type = 4 +2ms
  hci   sub event type = 62 +2ms
  hci           LE meta event type = 2 +4ms
  hci           LE meta event status = 1 +3ms
  hci           LE meta event data = 
04000d6f0a221a001108094b45592d424c4507ff001a220a6f0db5 +3ms
  hci                   type = 4 +3ms
  hci                   address = xx:xx:xx:xx:xx:xx +3ms
  hci                   address type = public +2ms
  hci                   eir = 08094b45592d424c4507ff001a220a6f0d +3ms
  hci                   rssi = -75 +2ms
  gap advertisement = 
{"localName":"KEY-BLE","manufacturerData":{"type":"Buffer","data":[0,26, 
34,10,111,13]},"serviceData":[],"serviceUuids":["58e0690015d811e6b737000 
2a5d5c51b"],"solicitationServiceUuids":[],"serviceSolicitationUuids":[]} 
+4ms
  simble:info   Scanned peripheral xx:xx:xx:xx:xx:xx (Name:"KEY-BLE", 
advertised services:[58e06900-15d8-11e6-b737-0002a5d5c51b]) +464ms
  simble:info Peripheral xx:xx:xx:xx:xx:xx matches filters, stopping 
scanning +3ms
  hci set scan enabled - writing: 010c20020001 +17ms
  simble:info Connecting to peripheral xx:xx:xx:xx:xx:xx... +18ms
  hci create le conn - writing: 
010d20196000300000000d6f0a221a000006000c000000c80004000600 +30ms
  hci onSocketData: 040e04010c2000 +3ms
  hci   event type = 4 +2ms
  hci   sub event type = 14 +2ms
  hci           cmd = 8204 +2ms
  hci           status = 0 +2ms
  hci           result =  +3ms
  noble scanStop +3ms
  hci onSocketData: 040f0400010d20 +3ms
  hci   event type = 4 +1ms
  hci   sub event type = 15 +2ms
  hci           status = 0 +3ms
  hci           cmd = 8205 +2ms
  hci onSocketData: 043e130100400000000d6f0a221a000c000000c80000 +3s
  hci   event type = 4 +2ms
  hci   sub event type = 62 +3ms
  hci           LE meta event type = 1 +4ms
  hci           LE meta event status = 0 +3ms
  hci           LE meta event data = 400000000d6f0a221a000c000000c80000 
+2ms
  hci                   handle = 64 +7ms
  hci                   role = 0 +7ms
  hci                   address type = public +4ms
  hci                   address = xx:xx:xx:xx:xx:xx +3ms
  hci                   interval = 15 +2ms
  hci                   latency = 0 +3ms
  hci                   supervision timeout = 2000 +2ms
  hci                   master clock accuracy = 0 +4ms
  att xx:xx:xx:xx:xx:xx: write: 020001 +37ms
  hci write acl data pkt - writing: 024000070003000400020001 +5ms
  simble:event Peripheral xx:xx:xx:xx:xx:xx : Event "connected" +0ms
  simble:info Connected to peripheral xx:xx:xx:xx:xx:xx +3s
  simble:info Discovering peripheral xx:xx:xx:xx:xx:xx... +8ms
  hci onSocketData: 011620024000 +43ms
  hci   event type = 1 +2ms
  hci           cmd = 8214 +3ms
  hci           data len = 2 +4ms
  hci onSocketData: 040f0400011620 +5ms
  hci   event type = 4 +3ms
  hci   sub event type = 15 +2ms
  hci           status = 0 +3ms
  hci           cmd = 8214 +2ms
  hci onSocketData: 024000070003000400020001 +2ms
  hci   event type = 2 +2ms
  hci onSocketData: 043e0c040040000100000000000000 +3ms
  hci   event type = 4 +2ms
  hci   sub event type = 62 +2ms
  hci           LE meta event type = 4 +3ms
  hci           LE meta event status = 0 +3ms
  hci           LE meta event data = 40000100000000000000 +3ms
  hci onSocketData: 024020070003000400031700 +4ms
  hci   event type = 2 +2ms
  hci           cid = 4 +2ms
  hci           handle = 64 +2ms
  hci           data = 031700 +4ms
  att xx:xx:xx:xx:xx:xx: read: 031700 +13ms
  att xx:xx:xx:xx:xx:xx: new MTU is 23 +4ms
  att xx:xx:xx:xx:xx:xx: write: 100100ffff0028 +3ms
  hci write acl data pkt - writing: 0240000b0007000400100100ffff0028 
+3ms
  hci onSocketData: 024020070003000400031700 +9ms
  hci   event type = 2 +2ms
  hci           cid = 4 +3ms
  hci           handle = 64 +3ms
  hci           data = 031700 +3ms
  att xx:xx:xx:xx:xx:xx: read: 031700 +4ms
  hci onSocketData: 
0240201800140004001106000151010018000220020118000321030a18 +14ms
  hci   event type = 2 +3ms
  hci           cid = 4 +3ms
  hci           handle = 64 +3ms
  hci           data = 1106000151010018000220020118000321030a18 +5ms
  att xx:xx:xx:xx:xx:xx: uh oh, no current command +2ms
Error: Promise did not resolve within 45000 milliseconds
  hci set scan enabled - writing: 010c20020001 +40s
  hci disconnect - writing: 01060403400013 +7ms



Gruß,
Hendrik

Übrigens: Das log oben war jetzt vom 'guten' Schloss (habe ich 
versehentlich genutzt). D.h. da habe ich das Problem auch.
Das Problem besteht augenscheinlich nicht immer.

Kann es sein, dass das Problem besteht, wenn zwei keyble Instanzen auf 
das gleiche Schloss zugreifen?
Ich habe ja meinen Service im Hintergrund laufen...

Den Gedanken hatte ich gestern schon einmal, aber ich habe den dann 
wieder verworfen, da ich das Problem auch hatte, nachdem ich den Service 
gestoppt habe. Aber vielleicht brauchte das Schloss auch noch einen 
Moment bevor es eine neue Verbindung aufnehmen konnte.

Gruß,
Hendrik

Hallo,

ich habe den Service jetzt beendet und wieder gestartet.
Jetzt funktionieren beide Schlösser -auch während der Service läuft mit 
einem manuellen sendcommand.

Ich verstehe das nicht...

Gruß,
Hendrik

Hallo,

@Michi: Das weiß ich leider auch nicht.
Ich habe jetzt mal einen erfolgreichen mit einem nicht erfolgreichen 
Versuch verglichen.

Was mir auffällt:
1) im nicht funktionierenden Versuch findet keyble zuerst das andere 
Schloss, dann aber das richtige (kann es sein, dass es sich mit dem 
falschen verbindet?)

Dann kommt:
  simble:info Peripheral xx:xx:xx:xx:xx:xx matches filters, stopping 
scanning +3ms
  hci set scan enabled - writing: 010c20020001 +17ms
  simble:info Connecting to peripheral xx:xx:xx:xx:xx:xx... +18ms
  hci create le conn - writing: 
010d20196000300000000d6f0a221a000006000c000000c80004000600 +30ms


Im funktionierenden versuch kommt hier statt dem
010d20196000300000000d6f0a221a...
010d20196000300000007c6e0a221a...


2) ein ganzes stück weiter kommt:
  hci onSocketData: 024020070003000400031700 +9ms
  hci   event type = 2 +2ms
  hci           cid = 4 +3ms
  hci           handle = 64 +3ms
  hci           data = 031700 +3ms
  att xx:xx:xx:xx:xx:xx: read: 031700 +4ms
  hci onSocketData:
0240201800140004001106000151010018000220020118000321030a18 +14ms
  hci   event type = 2 +3ms
  hci           cid = 4 +3ms
  hci           handle = 64 +3ms
  hci           data = 1106000151010018000220020118000321030a18 +5ms
  att xx:xx:xx:xx:xx:xx: uh oh, no current command +2ms
Error: Promise did not resolve within 45000 milliseconds
  hci set scan enabled - writing: 010c20020001 +40s
  hci disconnect - writing: 01060403400013 +7ms


wenn es nicht funktioniert und
  hci onSocketData: 
0240201800140004001106000151010018000220020118000321030a18 +29ms
  hci   event type = 2 +2ms
  hci           cid = 4 +3ms
  hci           handle = 64 +3ms
  hci           data = 1106000151010018000220020118000321030a18 +3ms
  att xx:xx:xx:xx:xx:xx: read: 1106000151010018000220020118000321030a18 
+3ms
  att xx:xx:xx:xx:xx:xx: write: 102203ffff0028 +6ms
  hci write acl data pkt - writing: 0240000b0007000400102203ffff0028 
+2ms
  hci onSocketData: 
0240201a00160004001114000430041bc5d5a5020037b7e611d8150069e058 +23ms
  hci   event type = 2 +2ms
  hci           cid = 4 +3ms
  hci           handle = 64 +4ms
  hci           data = 1114000430041bc5d5a5020037b7e611d8150069e058 +2ms
  att xx:xx:xx:xx:xx:xx: read: 
1114000430041bc5d5a5020037b7e611d8150069e058 +2ms
  att xx:xx:xx:xx:xx:xx: write: 103104ffff0028 +3ms
  hci write acl data pkt - writing: 0240000b0007000400103104ffff0028 
+3ms
  hci onSocketData: 
0240201a0016000400111400ff07ff1bc5d5a502009ba2e611db15a05dee3a +26ms
  hci   event type = 2 +2ms
  hci           cid = 4 +3ms
  hci           handle = 64 +3ms
  hci           data = 111400ff07ff1bc5d5a502009ba2e611db15a05dee3a +3ms
  att xx:xx:xx:xx:xx:xx: read: 
111400ff07ff1bc5d5a502009ba2e611db15a05dee3a +2ms
  att xx:xx:xx:xx:xx:xx: write: 1008ffffff0028 +2ms
  hci write acl data pkt - writing: 0240000b00070004001008ffffff0028 
+2ms
  hci onSocketData: 024020090005000400011008ff0a +27ms
  hci   event type = 2 +2ms
  hci           cid = 4 +4ms
  hci           handle = 64 +3ms
  hci           data = 011008ff0a +2ms
  att xx:xx:xx:xx:xx:xx: read: 011008ff0a +3ms
  att xx:xx:xx:xx:xx:xx: write: 08000151010328 +23ms
  hci write acl data pkt - writing: 0240000b000700040008000151010328 
+3ms
  hci onSocketData: 
0240201b001700040009071001021101002a2001022101012a3001023101022a +21ms
  hci   event type = 2 +2ms
  hci           cid = 4 +3ms
  hci           handle = 64 +3ms
  hci           data = 09071001021101002a2001022101012a3001023101022a 
+3ms
  att xx:xx:xx:xx:xx:xx: read: 
09071001021101002a2001022101012a3001023101022a +2ms
  att xx:xx:xx:xx:xx:xx: write: 08000220020328 +7ms
  hci write acl data pkt - writing: 0240000b000700040008000220020328 
+3ms
  hci onSocketData: 0240200d000900040009071002221102052a +21ms
  hci   event type = 2 +2ms
.....
wenn es funktioniert.

Hilft das weiter?

Viele Grüße,
Hendrik

Michi schrieb:
> Halihallo,
>
> kann mir da jemand erklären was der output von keyble da bedeutet?
>
> data
> {"a":true,"user_right_type":3,"e":false,"f":false,"g":true,"h":true,"i": 
false,"j":true,"lock_status":2,"l":16,"m":22}
>
> für was steht e, f g, h, i, j?
> a ist mal für administrator :)

Die Buchstaben habe ich einfach so aus der disassemblierten Java-Klasse 
übernommen, die in der Smartphone-App diesen Nachrichten-Typ 
repräsentiert (de.eq3.ble.key.android.a.a.af).
Da der Java-Code der Smartphone-App aber grossteils "obfuscated" wurde, 
stehen dort leider einfach Buchstaben statt aussagekräftiger Namen; der 
konkrete Buchstabe ist auch rein zufällig und keinerlei Abkürzung oder 
so. Bisher habe ich mir nicht die Mühe gemacht herauszufinden, für was 
die einzelnen Buchstaben bzw. Felder stehen könnten, nur bei 
"lock_status" und "user_right_type" hat sich das zufällig ergeben.

Deshalb habe ich erst einmal einfach die Buchstaben übernommen. Wenn Du 
aber sicher bist, dass bspw. "e" für "battery low" steht, dann werde ich 
das gerne ändern.
Und auch wenn ein anderer das mal genauer analysiert und glaubt, die 
Bedeutung eines dieser Felder verstanden zu haben: bitte kurz Bescheid 
geben.

Hallo,

@Joachim: Hast du meinen Post und meine Mail gesehen?
Hast du eine Idee?

Gruß,
Hendrik

Hendrik F. schrieb:
> Hallo,
>
> @Joachim: Hast du meinen Post und meine Mail gesehen?
> Hast du eine Idee?

Hi,

ich habe mir eben mal den Screenshot angeschaut, den Du in Deiner Mail 
verlinkt hast, mit dem Vergleich der beiden Protokolle.

Was Du da blau eingekringelt hast, scheint mir zum einen Teile (bzw. die 
letzten Stellen) der MAC-Adresse zu sein, zum anderen der RSSI-Wert.
Von daher ist es ganz normal, dass sich bei zwei unterschiedlichen 
Schlössern die Logs an dieser Stelle unterscheiden. Ich konnte da jetzt 
nichts erkennen.

Jemand hat mich übrigens gebeten in der Dokumentation darauf 
hinzuweisen, dass keyble nicht funktioniert bzw. es zu merkwürdigen 
Fehlern kommt, wenn auf dem Smartphone die zugehörige App läuft. Und 
dass man daher bei Problemen sicherstellen soll, dass die Smartphone-App 
in diesem Moment wirklich geschlossen ist.

Ganz explizit hat diese Person in dem Zusammenhang Timeouts und Probleme 
beim Registrieren von Benutzern erwähnt.
Da es ja auch hier Leute gab, die genau solche Probleme erwähnt hatten:
Könnte es bei den Personen, die derartige Probleme haben, möglicherweise 
damit zu tun gehabt haben?

Michi schrieb:
>> Deshalb habe ich erst einmal einfach die Buchstaben übernommen. Wenn Du
>> aber sicher bist, dass bspw. "e" für "battery low" steht, dann werde ich
>> das gerne ändern.
>
> genau,
> e - steht für battery_low true/false
> a - für administrator mit true/false
>
> was ich da noch bemerkt habe:
> wenn g=true und h,i=false - normalbetrieb,
> wenn g,h=true und i=false - automatisch schliessen,
> wenn g,i=true und h=false - dauerhaft schliessen.

Demnach also:
h -> automatisch schliessen
i -> Dauerhaft schliessen
Fragezeichen?

> was mich noch interessiert, wer hat die letzte version von eqiva auf den
> smart lock installiert und getestet?
> zurzeit habe ich mit FW 1.7 und 1.6 getestet, ble FW ist aber 1.5

Also ich habe ebenfalls FW 1.7 und ble 1.5.

Hallo,

> Ich konnte da jetzt nichts erkennen.
dann sind die zwei Teile soweit klar.

Aber danach (Zeile 110 bis 134 im rechten Teil des Bildes) unterscheidet 
sich die Kommunikation auch. Danach ist sie erstmal wieder gleich.

Mir ist gerade noch ein weiterer Unterschied aufgefallen. Den schicke 
ich dir nochmal per Mail (möchte ich hier nicht anhängen, da darin 
sensitive Daten enthalten sein können).

Gruß,
Hendrik

Michi schrieb:
>> Demnach also:
>> h -> automatisch schliessen
>> i -> Dauerhaft schliessen
>> Fragezeichen?
>
> Eher jein, hier muss man auf alle 3 Variablen schauen, damit man den
> richtigen case erwischt
>
> G H I
> 1 0 0 - Normalbetrieb
> 1 1 0 - Autoschliessen
> 1 0 1 - Dauerhaft
>
> Der rest, wie z.B. (000, 111) bleibt nicht unbekannt, spricht dies habe
> ich in meiner Software nicht gebraucht.

Was mich ein bisschen verwirrt ist, dass ich den Algorithmus hinter g, h 
& i 1:1 von der Smartphone-App übernommen habe, und g,h & i auch dort 
eben als boolean-Werte verwendet werden.
Wenn g,h & i nur dafür verwendet werden, zusammen den aktuellen 
Betriebs-Zustand zu kodieren, dann hätte ich eher erwartet, dass g,h & i 
nicht als drei separate booleans, sondern als einzelner 
3-Bit-Integer-Wert ausgeführt ist, wie dies bspw. bei "user_right_type" 
oder "lock_status" der Fall ist...

> Die neueste Version ist ja 1.8 im Moment, habe micht aber nicht getraut
> zu testen, aber da ich den Schloss gestern gekauft habe, könnte ich den
> mal mit der neuen FW testen und zurückgeben, wenn dein Tool mit der FW
> 1.8 nicht mehr funktioniert :)

Interessant, ich wusste bis eben gar nicht, dass es bereits ein v1.8 
gibt.
Woher hast Du die? Ich dachte bis eben, dass bei Verfügbarkeit einer 
neuen Firmware-Version in der App automatisch angezeigt und die 
Möglichkeit angeboten wird, diese zu installieren. Aber bei mir sehe ich 
nichts diesbezüglich.
Anyway, wenn Du diese Version 1.8 mal testen würdest, wäre es natürlich 
super. Ich kann aber auch Deine Bedenken gut verstehen - da ich nur 
einen einzigen Türschlossantrieb habe und den auch nicht mehr 
zurückgeben kann, hätte ich auch Angst, eine ungetestete neue Version zu 
installieren.

Hallo,

ich dachte schon, dass ich hier Erfolg vermelden kann, da beide 
Schlösser mehrfach richtig reagierten.

Aber jetzt reagieren beide nicht mehr.
Auch kommen keine Nachrichten mehr an, wenn ich das Schloss manuell 
bediene.

Fragen dazu:
1) benutzt jemand keyble schon produktiv und kann berichten, dass es 
zuverlässig funktioniert?
2) wenn ja: benutzt es jemand auch via mqtt?
3) benutzt es jemand auch während andere Schlösser in Reichweite sind?
4) oder andere Bluetooth-Low Energy-Geräte

Mein Verdacht ist momentan
a) Es wird sich mit dem falschen Gerät verbunden
b) Die Instanzen von keyble-sendcommand kommen sich in die Quere

Es ist auffällig, dass es -wenn es mal nicht funktioniert- es lange 
nicht funktioniert. Auch mehrere Versuche scheitern dann.

Gruß,
Hendrik

Hallo nochmal,


bei diesem Kommando
mosquitto_sub -h 192.168.0.2 -t "door_lock/action" | keyble-sendcommand 
-a 01:23:56:67:89:ab -u 1 -k ca78ad9b96131414359e5e7cecfd7f9e | 
mosquitto_pub -h 192.168.0.2 -l -r -t "door_lock/status"

läuft keyble-sendcommand doch die ganze Zeit, oder?

Wie wird gesteuert, wann keyble-sendcommand eine Verbindung zum Schloss 
aufbaut? Können zwei Verbindungen kollidieren?

Gruß,
Hendrik

Hendrik F. schrieb:
> bei diesem Kommando
> mosquitto_sub -h 192.168.0.2 -t "door_lock/action" | keyble-sendcommand
> -a 01:23:56:67:89:ab -u 1 -k ca78ad9b96131414359e5e7cecfd7f9e |
> mosquitto_pub -h 192.168.0.2 -l -r -t "door_lock/status"
>
> läuft keyble-sendcommand doch die ganze Zeit, oder?

Ja.

> Wie wird gesteuert, wann keyble-sendcommand eine Verbindung zum Schloss
> aufbaut?

Über die Kommandozeilen-Parameter

1

--status_update_time <Zeit in Sekunden>

und

1

--auto_disconnect_time <Zeit in Sekunden>

Am konkreten Beispiel: Bei

1

--status_update_time 300 --auto_disconnect_time 10

sollte sich keyble so verhalten:
- Wenn keyble mit dem Türschlossantrieb verbunden ist, soll die 
Verbindung nach 10 Sekunden Inaktivität automatisch getrennt werden (in 
erster Linie: um Strom zu sparen)
- Wenn keyble mindestens 5 Minuten = 300 Sekunden lang nicht mit dem 
Türschlossantrieb verbunden war, soll es sich mit dem Türschlossantrieb 
verbinden (in erster Linie: um eventuelle Status-Änderungen zu erfahren, 
die in dieser Zeit passiert sein könnten)
- Wann immer keyble eine Aktion ausführen soll (lock/unlock/open), 
verbindet es sich sofort mit dem Türschlossantrieb, sofern es in dem 
Moment nicht eh bereits verbunden ist

> Können zwei Verbindungen kollidieren?

Sie sollten es natürlich nicht, aber ich würde nicht ausschliessen, dass 
es diesbezüglich irgendeinen Bug gibt, in keyble selbst oder den 
verwendeten Bluetooth-Libraries. Getestet habe ich das nie.

Hallo,

vielen Dank.
Ich bin da mit meinem Latein am Ende. Ich deaktiviere jetzt erstmal das 
eine Schloss und lass nur das andere aktiv.
Mal sehen, ob das besser funktioniert.

Gruß,
Hendrik

Mal ne allgemeine Anfrage:

Ich frage mich, ob es nicht Sinn macht, langfristig einen eigenen "eqiva 
Smart Lock"/"nuki"-ähnlichen Türschlossantrieb auf Open Source/Open 
Hardware-Basis zu entwickeln. Mit einem ESP32-Microcontroller als 
Herzstück. Bei einer kurzen Google-Suche konnte ich auf Anhieb nichts 
dergleichen finden, was bereits existieren würde.

Der Hardware-Aufwand erscheint mir äusserst überschaubar:
- ein kleiner aber vglw. kräftiger Gleichstrom-Motor mit Getriebe
- eine H-Brücke zum Steuern des Motors, z.B. ein einfacher L293
- ein ESP32-WROOM-32 Modul
- 2-4 Mikroschalter
- ein paar Kondensatoren, Widerstände etc.
- ein paar 3D-gedruckte Bauteile, als Gehäuse etc.

Einerseits würde ein solcher Türschlossantrieb nur einen Bruchteil 
dessen kosten, was die erhältlichen kommerziellen Dinger kosten (reine 
Bauteilkosten unter 10 Euro?); der Hauptvorteil läge meiner Meinung nach 
aber vielmehr darin, dass man eine viel bessere Firmware entwickeln 
könnte, mit Features wie:

- einstellbares BTLE-Advertising-Intervall bzw. allgemein optimierte 
Bluetooth-Einstellungen etc., damit die Zeit bis zum tatsächlichen 
Ausführen der Aktionen auf das Minimum verkürzt werden kann. Vermutlich 
könnte man es sogar so einrichten, dass man nicht einmal zwingend eine 
Bluetooth-Verbindung mit dem Türschlossantrieb aufbauen muss, um ihn zu 
steuern

- einstellbare Bluetooth-Sende-Leistung, damit der Türschlossantrieb 
auch über grössere Entfernungen gesteuert werden kann

- wenn bspw. eine Stromquelle in der Nähe ist: Option, den 
Türschlossantrieb alternativ über WLAN statt über  Bluetooth LE 
anzubinden, mit möglichen Features wie Option zur Steuerung per HTTP, 
oder direkt integrierte Unterstützung für MQTT oder beliebte Smart 
Home-Systeme, ohne ein zusätzliches Gateway zu benötigen

Da fast jeder hier vermutlich bereits einen eqiva Türschlossantrieb 
besitzt und daher eigentlich keinen Türschlossantrieb mehr braucht, ist 
es vermutlich etwas unglücklich ausgerechnet hier zu fragen. Dennoch 
frage ich einfach mal nach ehrlichen Meinungen, was ihr von der Idee 
haltet:
Schnapsidee? Gibt's doch schon? Interesse?

Falls sich ein paar andere Leute finden würden, die Interesse hätten, so 
etwas mitzuentwickeln: Die nötigen 3D-gedruckten Bauteile würde ich den 
Leuten gegen reine Porto-Erstattung zuschicken.

Michi schrieb:
> Hi an alle,
>
> wie schaut es mit der Verbindungszeit aus?
> Bis jetzt alles ausprobiert, aber die Kommunikation dauert trotzdem ca
> 10-12 sekunden bis der Schloss überhaupt was tut.

Wenn möglich, dann probiere doch mal aus, ob es das bessert, wenn der 
Türschlossantrieb direkt neben dem Raspberry Pi steht.

Bei mir dauert es nämlich deutlich kürzer, bis sich das Schloss in 
Bewegung setzt. Ich habe es eben ca. 10 Mal ausprobiert: Das kürzeste 
waren etwas über zwei, das längste etwas unter 4 Sekunden; Median ca. 
2,6 Sekunden.
Also sehr viel kürzer als die 10-12 Sekunden, die Du berichtest. Oder 
gar 20 Sekunden, von denen ein anderer mal gesprochen hat.
Und die einzige Erklärung, die mir auf Anhieb einfällt, ist, dass bei 
Dir evtl. wegen grösserer Entfernung und entsprechend schlechterer 
Funkverbindung  alles viel länger dauert.

Wobei, mir kommt da gerade eine andere mögliche Erklärung in den Sinn:
Kann es sein, dass Du keyble NICHT im "Filter-/Pipe-Modus" benutzt? Dass 
keyble bei Dir also nicht dauerhaft läuft, sondern Du für jede 
auszuführende Aktion keyble-sendcommand mit dem Kommandozeilen-Parameter 
--command bzw. -c neu aufrufst?

Falls ja, liegt das Problem vermutlich genau daran. Immer wenn man 
keyble-sendcommand aufrufst, dauert es erst einmal eine kurze Zeit, bis 
das Programm überhaupt ausgeführt wird, weil Node.js vorher erst einmal 
unzählige Module laden muss usw. usw. Das dauert schon auf einem 
schnellen PC kurze Zeit, und auf einem vglw. langsamen Raspberry Pi 
nochmal deutlich länger.
An keyble selbst kann man diesbezüglich wenig optimieren; falls das das 
Problem ist, bleiben eigentlich nur zwei Möglichkeiten:
- keyble im "Filter-" bzw. "Pipe-Modus" dauerhaft laufen lassen, statt 
es für jede Aktion neu zu starten
- Warten, bis es eine bessere Alternative zu keyble gibt. Vor einigen 
Tagen hatte hier ja jemand berichtet, dass er eine C oder 
C++-Implementierung entwickelt hat, die bereits lauffähig ist und die er 
einige Tage später bei GitHub veröffentlichen wollte. Eine in C/C++ 
geschriebene keyble-Alternative dürfte in der Hinsicht dramatisch besser 
abschneiden.

(Ich schätze, ich sollte das auch gleich mal in der Dokumentation 
erwähnen, dass die Variante mit Aktion per Kommandozeilenparameter 
diesbezüglich sehr gravierende Nachteile hat.)

p.s.:
Setze doch mal "DEBUG=simble:info" vor Deinen 
"keyble-sendcommand"-Befehl. Dann kannst Du ablesen, wie lange 
keyble-sendcommand braucht, wenn es erst einmal mit der 
Programmausführung beginnt - und das ist auch die Zeitspanne, auf die Du 
keyble-sendcommand drücken könntest, wenn es dauerhaft laufen würde.

Hi Joachim!

Joachim S. schrieb:
> Mal ne allgemeine Anfrage:
>
> Ich frage mich, ob es nicht Sinn macht, langfristig einen eigenen "eqiva
> Smart Lock"/"nuki"-ähnlichen Türschlossantrieb auf Open Source/Open
> Hardware-Basis zu entwickeln.

Ich verfolge das Projekt wirklich schon seit den frühen Anfängen und bin 
bis jetzt mehr als begeistert. Genau das hatte ich immer gesucht. Einen 
günstigen Antrieb einfach in mein Smarthome zu integrieren. Auch die 
Batterielaufzeit ist bis jetzt nach anfänglicher Skepsis als sehr gut zu 
betrachten.

Da der eqiva-Antrieb vglw. günstig ist, würde ich spontan sagen, lohnt 
die Entwicklung nicht. Da der momentane Funktionsumfang alle nötigen 
Bereiche Abdeckt, wäre die Neuentwicklung ein zu großer Aufwand für 
einige (wie ich finde) Detailverbesserungen - abgesehen vielleicht vom 
(etwas) günstigeren Preis und höherer Reichweite. Ich sage absichtlich 
"etwas", da man immer noch Handlingkosten dazu rechnen muss. Wenn man 
nicht gerade vor hat das Ding in Serie zu produzieren, so hat man Kosten 
für die Bauteile (plus Versand), Kosten für einen 3D-Druck plus Versand 
(sofern man keinen eigenen besitzt). RuckZuck steigen die Kosten doch 
über 30-40€ und dann kann man sich auch gleich den eqiva-Antrieb zulegen 
und hat ein schönes Formguss-Gehäuse.

> Schnapsidee? Gibt's doch schon? Interesse?

Interesse? Ja! Falls sich wider Erwarten mehrere zu diesem Projekt 
bekennen würde ich trotzdem gerne auf dem Laufenden bleiben ggf. je nach 
Zeit etwas übernehmen.

An dieser Stelle noch Mal großes Lob an alle die geholfen haben und für 
den super Support von dir in diesem Forum!

Andre J. schrieb:
> Da der eqiva-Antrieb vglw. günstig ist, würde ich spontan sagen, lohnt
> die Entwicklung nicht. Da der momentane Funktionsumfang alle nötigen
> Bereiche Abdeckt, wäre die Neuentwicklung ein zu großer Aufwand für
> einige (wie ich finde) Detailverbesserungen - abgesehen vielleicht vom
> (etwas) günstigeren Preis und höherer Reichweite. Ich sage absichtlich
> "etwas", da man immer noch Handlingkosten dazu rechnen muss. Wenn man
> nicht gerade vor hat das Ding in Serie zu produzieren, so hat man Kosten
> für die Bauteile (plus Versand), Kosten für einen 3D-Druck plus Versand
> (sofern man keinen eigenen besitzt). RuckZuck steigen die Kosten doch
> über 30-40€ und dann kann man sich auch gleich den eqiva-Antrieb zulegen
> und hat ein schönes Formguss-Gehäuse.
>
>> Schnapsidee? Gibt's doch schon? Interesse?
>
> Interesse? Ja! Falls sich wider Erwarten mehrere zu diesem Projekt
> bekennen würde ich trotzdem gerne auf dem Laufenden bleiben ggf. je nach
> Zeit etwas übernehmen.
>
> An dieser Stelle noch Mal großes Lob an alle die geholfen haben und für
> den super Support von dir in diesem Forum!

Hallo Andre,

vielen Dank für Deine ehrliche Meinung. Du hast schon Recht: Rein aus 
Kostenersparnis-Gründen macht ein Selbstbau wenig Sinn. Die meisten 
Leute brauchen wohl eh nur einen einzigen für die Wohnungstür, da lohnt 
sich der Aufwand für den Selbstbau nicht, wenn man für 60 Euro einen 
fertigen Türschlossantrieb mit Spritzgussgehäuse bekommt.

Von daher würde ich potentielle Vorteile grundsätzlich eher im Bereich 
der Software/Firmware/möglichen Features sehen. Und auch ein wenig in 
der Zukunftssicherheit: Man müsste keine Sorgen haben, dass eqiva den 
Bluetooth Türschlossantrieb irgendwann
- durch Firmware-Updates verhindert oder zumindest erschwert, dass man 
sie mit anderer Software steuern kann
- vom Markt nimmt, weil er die Verkäufe des deutlich teureren 
"Homematic"-Türschlossantriebs aus dem gleichen Haus kannibalisiert
- deutlich teurer macht

Aber auch das sind vermutlich eher theoretische als wirklich handfeste 
Gefahren und Vorteile. Der Haupt-Grund, warum ich die Entwicklung eines 
Open Hardware-/Open Source-Türschlosses in Betracht ziehe, ist letztlich 
vermutlich einfach der Reiz bzw. die Herausforderung, etwas zu 
entwickeln, was es bisher so nicht gibt. Ähnlich, wie es mich bei der 
Entwicklung von keyble wohl vor Allem die Herausforderung gereizt hat, 
das Protokoll zu reverse engineeren und eine alternative Software zum 
Steuern zu entwickeln.

Anyway, wirklich vielen Dank für Deine ehrliche Meinung. Ich sehe jetzt 
ein: Einen eigenen Türschlossantrieb zu entwickeln macht vermutlich mehr 
als persönliche Herausforderung Sinn, das Interesse von Anderen an einem 
Selbstbau wird sich hingegen wohl eher in Grenzen halten.

Michi schrieb:
> Hier hast du recht gehabt, ich habe den Befehl immer neu aufgerufen.

Ah, Danke für die Rückmeldung. Gut zu wissen, dass es einfach daran lag. 
Wann immer Leute von so extrem langen Zeiten bis zum Ausführen der 
Aktion berichtet haben, habe ich mich immer gefragt, woran das wohl 
liegen könnte, bin aber nicht darauf gekommen. Jetzt verstehe ich es 
endlich, und dabei war die Lösung eigentlich ganz einfach und 
naheliegend.

> Jetzt habe ich mal keyble im Pipe-Modus gestartet, lustigerweise wird
> der erste Befehl korrekt ausgeführt und liefert ein Status zurück, beim
> 2ten Befehl kommt keine Antwort mehr, man sieht nur status_info message:
>
> keyble:events Event: received:fragment +10s
>   keyble:communication Received message of type STATUS_INFO, data bytes
> <71 00 0b 00 10 17 00 00>, data
> {"a":true,"user_right_type":3,"e":false,"f":false,"g":false,"h":false,"i 
":false,"j":true,"lock_status":3,"l":16,"m":23}
> +99ms
>   keyble:events Event: received:message +39ms
>   keyble:events Event: received:message:STATUS_INFO +4ms
>   keyble:events Event: status_update +4ms
>
> im vergleich zu der 1 Antwort:
>
> keyble:communication Received message of type STATUS_INFO, data bytes
> <71 00 0b 00 10 17 00 00>, data
> {"a":true,"user_right_type":3,"e":false,"f":false,"g":false,"h":false,"i 
":false,"j":true,"lock_status":3,"l":16,"m":23}
> +332ms
>   keyble:events Event: received:message +50ms
>   keyble:events Event: received:message:STATUS_INFO +3ms
>   keyble:events Event: status_update +6ms
>   keyble:events Event: status:LOCKEDfalse +5ms
>   keyble:events Event: status_change +4ms
> LOCKED
>
> ist da was falsch?

Nein, zumindest in diesem Fall gilt: It's not a bug, it's a feature. 
Denn derzeit benutzt keyble für die Ausgabe des Status folgende Logik: 
Der Status wird nur dann ausgegeben...
- bei der allerersten Abfrage, nachdem keyble gestartet wurde
- wenn er sich ändert

Da der Status bei der zweiten Abfrage immer noch "3" = "locked" war, 
genau wie bei der ersten Status-Info-Message, wurde beim zweiten Mal 
nichts ausgegeben.
Bislang erschien mir diese Logik, den Status nur beim Änderungen 
auszugeben, naheliegend und sogar ratsam. Falls Du mir aber ein Szenario 
nennst, in dem es sinnvoll wäre, den Status bei jeder 
Status-Info-Message auszugeben, würde ich das vielleicht als alternative 
Möglichkeit einbauen.

> Jetzt funktioniert es wesentlich schneller, aber da keyble ständig mit
> dem Schloss verbunden ist - wird ja die Batterielaufzeit geringer und
> die Möglichkeit mit der App die Tür aufzusperren (falls RasPi spinnt)
> ist ja auch weg..oder?

Jain. Genau dafür sind die Kommandozeilen-Optionen 
"--status_update_time" und "--auto_disconnect_time" da, die nur im 
"Filter-/Pipe-Modus" überhaupt Sinn machen.
Um die Batterie des Türschlossantriebs zu schonen und den 
Türschlossantrieb auch weiterhin noch über die App steuern zu können, 
bleibt keyble standardmässig nicht dauerhaft mit dem Türschlossantrieb 
verbunden, sondern verbindet sich nur in regelmässigen Intervallen mit 
dem Türschlossantrieb, um kurz den Status abzufragen 
(--status_update_time - standardmässig mit Wert 600, also alle 60*10 
Sekunden=10 Minuten). Nach ein paar Sekunden wird die Verbindung dann 
sofort wieder getrennt (--auto_disconnect_time - standardmässig 30 
Sekunden; wird in der nächsten Version auf vermutlich 6 Sekunden 
verringert).
Somit besteht die Bluetooth-Verbindung zwischen keyble und dem 
Türschlossantrieb im Filter-/Pipe-Modus standardmässig nur etwa 5% (in 
der nächsten Version: 1%) der Zeit.

Wobei es mal interessant wäre, zu testen, wie viel höher der 
Batterieverbrauch bei einer dauerhaften Verbindung überhaupt wäre 
(--auto_disconnect_time 0). Gut möglich, dass er kaum höher wäre. Und 
bei einer dauerhaften Verbindung müssten die Aktionen eigentlich 
wirklich sofort, also binnen vielleicht einer Zehntelsekunde, ausgeführt 
werden. Die Möglichkeit, zusätzlich auch die App zu nutzen, würde dann 
aber halt leider entfallen.

Hallo,

zum Selbstbau:
Ich denke, man wird die Mechanik und das Gehäuse selbst nicht besser 
hinbekommen.
Was ich daher eher überlegen würde wäre:
a) die Software auf dem eingebauten Controller zu ersetzen
b) Nur die Mechanik und das Gehäuse behalten und die Elektronik zu 
ersetzen.

Wenn ich darüber nachdenke, was mir aktuell nicht gefällt, dann ist es:
1) Ich brauche einen Computer in der Nähe (lieber wäre mir garnix, d.h. 
das Schloss soll direkt MQTT können oder ein Micro-Controller (keine 
Admin-Sorgen, kein Platz))
2) Mit zwei Schlössern funktioniert es bei mir noch nicht zuverlässig
3) Es wäre schön, wenn keyble direkt MQTT könnte
4) Es wäre schön, wenn keyble 'maschinenlesbare' Inputs/Outputs hätte. 
Aktuell muss ich noch true/false auf lock/unlock mappen

Ich denke, dass man einen ESP im Gehäuse unterbringen kann - selbst ohne 
die existierende Eletkronik heraus zu werfen.
Ich denke auch, dass man eine Kommunikation direkt über WLAN 
energieeffizient erreichen kann, indem man auf Echtzeit verzichtet: Dann 
schläft der ESP die meiste Zeit und wacht z.B. alle 120s auf um per MQTT 
nach Kommandos zu fragen (der MQTT Broker speichert die ja) und den 
Status zu setzen.

Wenn du also eine Herausforderung suchst ;-) dann schau doch, ob du 
einen ESP derart einbauen kannst.

Dabei gibt es zwei Varianten:
a) der ESP sendet die Kommandos an die Motorsteuerung über die GPIOs 
oder die serielle Schnittstelle
b) der ESP sendet die Kommandos per Bluetooth. Dazu hat Marius ja schon 
einiges gemacht.

Gruß,
Hendrik

Michi schrieb:
> Ich hätte da eine Frage, wie kann ich den keyble am Raspberry starten
> damit er von woanders die Befehle annimmt? Deswegen habe ich ja den
> send-command Befehl immer neu versendet :)

Als die Standard-Möglichkeit dafür betrachte ich MQTT. Im Grunde genau 
die Option, die hier beschrieben wird:
https://github.com/oyooyo/keyble#piping-data-into-keyble-sendcommand

MQTT ist imho derzeit DER Standard für IoT. Gewisser kleiner Nachteil an 
MQTT ist aber: Man braucht einen MQTT-Broker, üblicherweise die 
Open-Source-Software "mosquitto". Dieser MQTT-Broker kann aber auch 
direkt ebenfalls auf dem Raspberry Pi laufen, von daher ist das jetzt 
nicht viel Zusatzaufwand. Und installiert ist MQTT bzw. mosquitto auf 
dem Raspberry Pi ebenfalls sehr schnell, dazu genügt üblicherweise ein 
kurzer

1

sudo apt-get install mosquitto mosquitto-clients

Befehl, und das war's. keyble würde man dann bspw. so starten:

1

mosquitto_sub -h localhost -t "door_lock/action" | keyble-sendcommand -a 01:23:56:67:89:ab -u 1 -k ca78ad9b96131414359e5e7cecfd7f9e | mosquitto_pub -h localhost -l -r -t "door_lock/status"

Alternativ könnte man aber auch auf diverse andere Arten eine 
Schnittstelle nach aussen bereitstellen:

1

nc -l 5000 | keyble-sendcommand -a 01:23:56:67:89:ab -u 1 -k ca78ad9b96131414359e5e7cecfd7f9e

Bspw. würde keyble-sendcommand so starten, dass der Raspberry Pi auf 
Port 5000 die zu sendenden Befehle entgegennimmt und dann ausführt.

Hendrik F. schrieb:
> 3) Es wäre schön, wenn keyble direkt MQTT könnte

Wird es in keyble selbst vermutlich nicht geben, weil keyble dann für 
die MQTT-Unterstützung zwangsweise weitere dutzende Node.js-Module als 
Abhängigkeiten mitinstallieren müsste, die nicht jeder braucht. (Schon 
die ca. 70-80 Node.js-Module, die die Verwendung der "noble"-Library 
zwingend nach sich zieht, sind mir irgendwo ein Graus).

Die Idee ist grundsätzlich aber natürlich trotzdem gut und sinnvoll, 
sollte imho nur anders gelöst werden: Als zusätzliches Node.js-Modul 
(z.B. "keyble-mqtt" oder so, das keyble nur als Library nutzt. Werde ich 
demnächst vermutlich wirklich mal veröffentlichen.

Vermutlich wäre es sogar sinnvoll, dass keyble selbst nur die Library 
enthält, und sogar die Kommandozeilen-Tools in ein zusätzliches 
Node.js-Modul (z.B. "keyble-cli") ausgelagert werden.

> 4) Es wäre schön, wenn keyble 'maschinenlesbare' Inputs/Outputs hätte.
> Aktuell muss ich noch true/false auf lock/unlock mappen

Schick mir diesbezüglich doch mal ein Code-Beispiel, welches das Problem 
verdeutlicht. So ganz verstehe ich das Problem nämlich gerade nicht, 
denn sowohl für den Eingang bzw. die Aktion, also auch für den Ausgang 
bzw. den Status benötigt man doch eh mehr als zwei Zustände - ein 
einziger boolean-Wert langt also doch eigentlich eh nicht?

> Ich denke auch, dass man eine Kommunikation direkt über WLAN
> energieeffizient erreichen kann, indem man auf Echtzeit verzichtet: Dann
> schläft der ESP die meiste Zeit und wacht z.B. alle 120s auf um per MQTT
> nach Kommandos zu fragen (der MQTT Broker speichert die ja) und den
> Status zu setzen.

Selbst wenn das tatsächlich energieeffizient möglich wäre, erscheint mir 
das irgendwie nicht praxisnah. Denn wenn man die Tür öffnen will, will 
man ja nicht erst 120 Sekunden (im worst case) warten...