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

[Joachim S. (oyo)]

Ich habe eine Sammlung kleiner Kommandozeilen-Tools namens "keyble" 
entwickelt und auf GitHub veröffentlicht, um den "eqiva eQ-3 Bluetooth 
Smart Lock"-Türschlossantrieb von einem PC aus steuern zu können:
https://github.com/oyooyo/keyble

Der eqiva eQ-3 Bluetooth-Türschlossantrieb 
(https://www.amazon.de/Eqiva-Bluetooth%C2%AE-Smart-T%C3%BCrschlossantrieb-142950A0/dp/B01GVZ771W/) 
bietet zu einem Preis ab ca. 55 Euro ein sehr gutes 
Preis-/Leistungsverhältnis. Bislang war es allerdings lediglich möglich, 
den Türschlossantrieb mit der offiziellen Hersteller-Smartphone-App zu 
steuern. Eine Integration in bestehende Smart Home-Systeme war so nicht 
möglich; mit dieser Tool-Sammlung soll sich das ändern.

keyble ist noch in einem sehr frühen Alpha-Stadium, es gibt noch etliche 
Bugs, und bislang ist lediglich die absolute Minimal-Funktionalität 
implementiert:
- Registrieren neuer User
- Öffen/Abschliessen/Aufschliessen des Schliesszylinders

Es wäre schön, wenn Leute die diesen Türschlossantrieb besitzen das 
dennoch mal ausprobieren und mir Feedback geben würden.

Die Software ist in Node.js geschrieben, und sollte theoretisch sowohl 
unter Linux, OSX als auch Windows laufen. Testen konnte ich es 
allerdings nur unter Linux; auch die Instruktionen zum Installatieren 
bezieht sich in erster Linie auf Linux. Vielleicht kann ein Benutzer 
eines anderen Betriebssystems das mal testen und angepasste 
Instruktionen zum Installieren nennen.
Neben Node.js wird noch Bluetooth 4.x-fähige Hardware, z.B. ein 
Bluetooth 4.0-USB-Dongle benötigt.

p.s.:
Dies hier ist gewissermassen eine Fortsetzung des Threads 
Beitrag "Entwurf Schaltung für Erweiterung Türschlossantrieb"
In bisherigen Thread ging es ursprünglich darum, diesen 
Türschlossantrieb per Hardware-Modifikation nutzbar zu machen; daher 
fand ich es sinnvoller jetzt einen neuen Thread zu starten.

[Joachim S. (oyo)]

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:

$ 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.

$ 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)

[Andre J. (andrexp)]

Sogar vor dem Zeitplan ;)

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

:)

[Andre J. (andrexp)]

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!

[Joachim S. (oyo)]

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.

$ 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!

[Andre J. (andrexp)]

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.
>
>

> $ 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=*"

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.

[Joachim S. (oyo)]

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...

[Andre J. (andrexp)]

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)

ensure_connected() {
//...
simble.scan_for_peripheral(simble.filter.address(this.address))
//...

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

scan_for_peripheral = function(peripheral_filter) {
//...
noble.on('stateChange', function(state) {
if (state === 'poweredOn') {
//...

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.

[Jörg E. (jackfritt)]

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

[Joachim S. (oyo)]

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:

$ 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)
>
>

> ensure_connected() {
> //...
> simble.scan_for_peripheral(simble.filter.address(this.address))
> //...
>

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

> scan_for_peripheral = function(peripheral_filter) {
> //...
> noble.on('stateChange', function(state) {
> if (state === 'poweredOn') {
> //...
>

>
> 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! :-)

[Joachim S. (oyo)]

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. :-(

[Jörg E. (jackfritt)]

Ich probier es mal mit Node 9

[Andre J. (andrexp)]

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...

[Andre J. (andrexp)]

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.

[Andre J. (andrexp)]

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.

[Joachim S. (oyo)]

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.

[Joachim S. (oyo)]

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

Zum updaten:

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

[Andre J. (andrexp)]

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... :-)

[Joachim S. (oyo)]

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.

[Joachim S. (oyo)]

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:

$ 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.

[Markus B. (rusticus)]

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

[Joachim S. (oyo)]

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.

[Markus B. (rusticus)]

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

[Joachim S. (oyo)]

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.

[Thomas (type0n)]

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

[Andre J. (andrexp)]

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 
:-)

[Joachim S. (oyo)]

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.

[Thomas (type0n)]

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

[Andre J. (andrexp)]

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...

[Joachim S. (oyo)]

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.

[Thomas (type0n)]

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

[Joachim S. (oyo)]

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

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.

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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 
:)

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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. :-(

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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

DEBUG="simble:*,keyble:*"

zu setzen, also z.B.

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

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

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

Moin,

hier die ganze Ausgabe:

DEBUG="simble:*,keyble:*" keyble-sendcommand --address 00:xx:xx:0a:6f:0d --user_id 2 --user_key xxx --command open
  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "connected" +0ms
  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "discovered" +495ms
  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
  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
  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +613ms
  keyble:events Event: received:fragment +0ms
  keyble:events Event: received:message +1ms
  keyble:events Event: received:message:CONNECTION_INFO +0ms
  keyble:events Event: nonces_exchanged +1ms
  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
  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
  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +89ms
  keyble:events Event: received:fragment +87ms
  keyble:events Event: received:message +1ms
  keyble:events Event: status_update +0ms
  keyble:events Event: status:active +1ms
  keyble:events Event: status_change +0ms
active
  keyble:events Event: received:message:STATUS_INFO +1ms
  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
  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +4s
  keyble:events Event: received:fragment +4s
  keyble:events Event: received:message +0ms
  keyble:events Event: received:message:STATUS_CHANGED_NOTIFICATION +1ms
  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
  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
  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +44ms
  keyble:events Event: received:fragment +44ms
  keyble:events Event: received:message +1ms
  keyble:events Event: status_update +0ms
  keyble:events Event: status:unlocked +0ms
  keyble:events Event: status_change +0ms
unlocked
  keyble:events Event: received:message:STATUS_INFO +1ms
  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "disconnected" +15s
  keyble:events Event: disconnected +15s
  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "connected" +10m
  keyble:events Event: connected +10m
  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "discovered" +495ms
  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
  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
  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +45ms
  keyble:events Event: received:fragment +540ms
  keyble:events Event: received:message +0ms
  keyble:events Event: received:message:CONNECTION_INFO +0ms
  keyble:events Event: nonces_exchanged +0ms
  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
  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
  simble:event Characteristic 359d4820-15xx-11xx-82bd-0002a5d5c51b : Event "data_received" +60ms
  keyble:events Event: received:fragment +60ms
  keyble:events Event: received:message +1ms
  keyble:events Event: status_update +1ms
  keyble:events Event: received:message:STATUS_INFO +0ms
  simble:event Peripheral 00:xx:xx:0a:6f:0d : Event "disconnected" +15s
  keyble:events Event: disconnected +15s

Bei Android komme ich erstmal nicht weiter.

Gruß,
Hendrik

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

Hallo,

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

Gruß,
Hendrik

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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?

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

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

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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.

[Joachim S. (oyo)]

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!

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

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 ;-)

[Hendrik F. (henfri)]

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:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
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
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


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
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

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

Ok, gute Reise!

[Hendrik F. (henfri)]

Hallo,

funktioniert jetzt.
Ich habe den PR aktualisiert.

Gruß,
Hendrik

[Joachim S. (oyo)]

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)?

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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?

[Hendrik Friedel (Gast)]

Hallo,

willkommen zurück ;-)
Ja, leider habe ich das Problem immernoch.
Du nutzt das Lock noch nicht produktiv, oder?

Gruß,
Hendrik

[Jörg E. (jackfritt)]

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?

[Joachim S. (oyo)]

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 (Gast)]

Hallo,

ja genau. Es kommt letztlich die Meldung:

  simble:event Peripheral 00:1a:22:0a:6f:0d : Event "connected" +0ms
Error: Promise did not resolve within 45000 milliseconds

Gruß,
Hendrik

[Joachim S. (oyo)]

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

  simble:event Peripheral 00:1a:22:0a:6f:0d : Event "connected" 
> +0ms
> Error: Promise did not resolve within 45000 milliseconds
>

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.

[Hendrik Friedel (Gast)]

Hallo Joachim,

ja, das fand ich auch. Mehr debug-Ausgaben würden vielleicht helfen. Ich 
habe keine Idee, was das Verhalten geändert haben könnte.

Gruß,
Hendrik

[Tobias P. (bulbur)]

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

[Marius S. (lauch42)]

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

[Joachim S. (oyo)]

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! :-)

[Al O. (cyber83)]

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 (Gast)]

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 ?

Registering user on Smart Lock with address "00:1a:22:xx:xx:xx", card key "xxxxx" and serial "NEQ10xxxx"...
  simble:event Peripheral 00:1a:22:xx:xx:xx : Event "connected" +0ms
  simble:event Peripheral 00:1a:22:xx:xx:xx : Event "discovered" +901ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send "80 02 ff 58 07 91 65 9e 05 e7 82 00 00 00 00 00" +0ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Receive "80 03 ff 00 4b a5 e7 c7 f4 8a 98 00 10 17 00 00" +76ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Event "data_received" +698ms
  keyble:events Event: received:fragment +0ms
  keyble:events Event: received:message +18ms
  keyble:events Event: received:message:CONNECTION_INFO +8ms
  keyble:events Event: nonces_exchanged +9ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send "81 04 ff e5 4c 10 34 e1 a6 ec 24 12 9d 09 ba 57" +279ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Receive "80 00 81 00 00 00 00 00 00 00 00 00 00 00 00 00" +58ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Event "data_received" +338ms
  keyble:events Event: received:fragment +296ms
  keyble:events Event: received:message +7ms
  keyble:events Event: received:message:FRAGMENT_ACK +4ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send "00 be 31 0c 00 00 00 00 00 00 00 01 01 85 cf d2" +34ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Receive "80 01 81 00 00 00 00 00 00 00 00 00 00 00 00 00" +54ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Event "data_received" +86ms
  keyble:events Event: received:fragment +75ms
  keyble:events Event: received:message +6ms
  keyble:events Event: received:message:ANSWER_WITHOUT_SECURITY +6ms
  simble:event Peripheral 00:1a:22:xx:xx:xx : Event "disconnected" +812ms
  keyble:events Event: disconnected +827ms

[Joachim S. (oyo)]

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 (Gast)]

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?

>> 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.

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

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.

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

[Joachim S. (oyo)]

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 (Gast)]

> 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!

> 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?

Danke für deine Antwort :)

[Michi (Gast)]

Kurze Info dazu:

> 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)

[Joachim S. (oyo)]

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 (Gast)]

> 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

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

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

Bluetooth version am Raspi ist 5.43
Node version am Raspi ist v8.9.0
Und alle updates wurden gestern schon installiert.


> 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.

> 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.

Aha, verstehe, aber das Gerät befindet sich im Pairing-Modus, da es 
orange blinkt, klappt aber trotzdem nicht.

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

[Joachim S. (oyo)]

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:

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

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

[Michi (Gast)]

> 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.

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

Ich kann ja paar Leute aus dem Schloss rauskicken und dann weiteres 
ausprobieren, wenn es nicht anders geht.

> 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.

Hab ich auch mit neuen Benutzern getestet, mich habe ich auch gelöscht 
und neu hinzugefügt - somit ist es doch möglich neue Benutzer zu 
registrieren.

> 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 :)

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...

[Joachim S. (oyo)]

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

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:

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.

[Hendrik F. (henfri)]

Bei mir ging es ohne Cam und ohne Pipe

[Joachim S. (oyo)]

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... :-(

[Mike J. (linuxmint_user)]

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?

[Michi (Gast)]

Guten Morgen an alle ;)

> 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.

Kann ich gute verstehen, ich wollte mich mit dem nicht beschäftigen, da 
es wirklich viel Zeit in Anspruch nimmt, aber vielen Dank für deine 
Recherche :)

Nun hat es bei mir endlich geklappt!
Das Problem lag bei der Useranzahl, obwohl es nur 7 Benutzer waren, 
wollte der Raspi sich nicht mit dem SmartLock verbinden, danach habe ich 
mich entschieden den Smartlock zu resetten und es hat perfekt 
funktioniert.

So ist es möglich den Benutzer-limit umzugehen ;)

Nochmals vielen Dank an Joachim S!

[Al O. (cyber83)]

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

[Joachim S. (oyo)]

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?

[Al O. (cyber83)]

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 (Gast)]

> Ja, den leeren batteriestatus abfragen wäre super

Da bin ich auch dabei, wenn es möglich wäre, wäre es natürlich super

> 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?

Lustigerweise rennt bei mir ein Webserver mit Nodejs und er macht auch 
die tür mit einem Befehl auf, aber eine 100% CPU-Activity hätte ich 
jetzt nicht gesehen, vlt hast du was im Code drinnen?

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?

[Joachim S. (oyo)]

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:

open
  simble:event Peripheral 00:1a:22:0a:65:af : Event "connected" +0ms
  simble:event Peripheral 00:1a:22:0a:65:af : Event "discovered" +477ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send "80 02 XX XX XX XX XX" +0ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Receive "80 03 XX XX XX XX XX" +42ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Event "data_received" +598ms
  keyble:events Event: received:fragment +0ms
  keyble:events Event: received:message +1ms
  keyble:events Event: received:message:CONNECTION_INFO +0ms
  keyble:events Event: nonces_exchanged +1ms
  simble:data Characteristic 3141dd40-15db-11e6-a24b-0002a5d5c51b : Send "80 87 XX XX XX XX XX" +18ms
  simble:data Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Receive "80 83 XX XX XX XX XX" +71ms
  simble:event Characteristic 359d4820-15db-11e6-82bd-0002a5d5c51b : Event "data_received" +89ms
  keyble:events Event: received:fragment +85ms
  keyble:events Event: received:message +2ms
  keyble:events Event: status_update +1ms
  keyble:events Event: status:active +0ms
  keyble:events Event: status_change +0ms
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 (Gast)]

Hallo,

ich versuche nun seit einigen Tagen leider erfolglos das Lock über nen 
Raspi 3 anzusprechen jedoch erhalte ich bei der Eingabe des Befehls:

sudo keyble-registeruser -n Raspi -q XXXXXXXXQR-CODEXXXXXXXXXXXXX

folgende Antwort:

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)

mach ich irgendwas falsch? Bin hier irgendwie ratlos.

Gruß Daniel

[Joachim S. (oyo)]

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. (Gast)]

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?

[Joachim S. (oyo)]

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...

[Andre J. (andrexp)]

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.

[Daniel (Gast)]

@Andre
Das Lock hat die Firmware 1.7 BLE Chip: 1.5


Bei der Eingabe dieses Befehls:

sudo keyble-registeruser -n Raspi -q 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Kommt zuerst folgende Ausgabe:

Press and hold "Unlock" button until the yellow light flashes in order 
to enter pairing mode

Und nach dem Einschalten des Pairing Mode am Lock kommt folgende 
Ausgabe:

Registering user on Smart Lock with address "00:1a:22:0a:6d:5b", card 
key "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" and serial "NEQ1062572"...

Dann stürzt das Terminal ab und es ist nicht mehr möglich etwas 
einzugeben. Trotzdem wurde kein weiterer User auf dem Lock eingerichtet.

Gruß

Daniel

[Hendrik Friedel (Gast)]

Hallo,

ich würde gerne noch einmal hierauf zurück kommen:

"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";

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".

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

Gruß,
Hendrik

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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

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

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

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

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

[Hendrik F. (henfri)]

Hallo,

die Dokumentation habe ich jetzt auch als PR geschickt.

Gruß,
Hendrik

[Joachim S. (oyo)]

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... :-(

[Hendrik F. (henfri)]

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

[Hendrik F. (henfri)]

Ü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

[Hendrik F. (henfri)]

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

[Michi (Gast)]

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 :)

gibt es eine möglichkeit statt status wie OPENED/LOCKED den json 
response zu bekommen?

[Hendrik F. (henfri)]

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 (Gast)]

Hi an alle,

falls sich jemand gefragt hat, wie man den batterie status auslesen 
kann:

bei jedem befehl kriegt man mit einem debug STATUS_INFO.

keyble:communication Received message of type STATUS_INFO, data bytes 
<71 01 0a 00 10 16 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":22}

wenn die batterien OK sind - "e":false
nicht OK - "e":true

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

Hallo,

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

Gruß,
Hendrik

[Joachim S. (oyo)]

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.

[Michi (Gast)]

> 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.

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


p.s. bei mir dauert die verbindung vom raspi zum keyble noch immer ca 8 
sekunden, bis er was tut und ca 10-11 bis man einen response erhielt.
ist es bei allen so?

[Joachim S. (oyo)]

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?

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

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 (Gast)]

> 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.

Das ist ja logisch, dass es unmöglich ist 2 Geräte gleichzeitig zu 
verbinden.
Es reicht wenn die EQIVA App nicht komplett geschlossen ist, sondern nur 
im Hintergrund ist, da die automatisch die Verbindung zum Schloss trennt 
(auf iOS und Android getestet)


> 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.

> Also ich habe ebenfalls FW 1.7 und ble 1.5.
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 :)

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

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

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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

--status_update_time <Zeit in Sekunden>

und

--auto_disconnect_time <Zeit in Sekunden>

Am konkreten Beispiel: Bei

--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.

[Hendrik F. (henfri)]

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

[Joachim S. (oyo)]

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 (Gast)]

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.

[Joachim S. (oyo)]

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.

[Andre J. (andrexp)]

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!

[Michi (Gast)]

Hi,

> 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?

Hier hast du recht gehabt, ich habe den Befehl immer neu aufgerufen.
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?

> 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.

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?


Danke für die Antwort ;)

[Joachim S. (oyo)]

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.

[Joachim S. (oyo)]

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.

[Hendrik F. (henfri)]

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 (Gast)]

> 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.

Immer gerne, die Probleme liegen meistens beim Layer 8 ;))

> 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

Ook, klingt logisch, werde mal ausprobieren.

> 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

Ich werds mal machen und danach berichten, wird aber eine Weile dauern 
;)

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 :)

[Michi (Gast)]

Ach ja, was ich vergessen habe - beim neuen Schloss habe ich die 1.6 FW 
version gehabt, dachte aber, dass es 1.7 ist und es gibt ein Update, 
aber nein, zurzeit gibts noch nichts von eqiva bez. updates :)

[Joachim S. (oyo)]

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

sudo apt-get install mosquitto mosquitto-clients

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

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:

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.

[Michi (Gast)]

> 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".

Bin nicht so der Fan von MQTT, aber die Lösung mit der Portfreigabe ist 
genau das, was ich gesucht habe. Danke ;)

[Joachim S. (oyo)]

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...

[Al O. (cyber83)]

Also, einen esp8266 hab ich schon im gehäuse selber drinnen, ist ein 
wemos d1 mini, der hat platz. Ich wollte ursprünglich mit den gpios die 
taster ansprechen und den status vom schloss, also von den schlossleds 
auswerten. Aber keyble ist doch um einiges einfacher.

Wenn jemand kann und lust hat, den vorhandenen equiva antrieb behalten 
und nur die platine mit einer eigen kreierten ersätzen wäre eine idee. 
Da passen die beiden taster, eine statusled aber auch ein esp(32 statt 
8266) drauf um das ganze mit BT, wlan und direkter Kontrolle zu haben.

Die vorhandene app geht dann natürlich nicht mehr. Und garantie gibts 
auch keine mehr...

[Philipp C. (e61_phil)]

Die vorhandene Platine zu ersetzen klingt gut.

Ich würde die Taster auch gerne deaktivieren können (kleine Kinder). 
Auch fände ich ein optionales drahtgebundenes Interface toll. ZB einfach 
UART oder so an den ohnehin daneben sitzenden RPi.

[Marius S. (lauch42)]

Hallo,

mein Port von keyble für den esp32 liegt nun unter 
https://github.com/MariusSchiffer/esp32-keyble

Leider funktioniert diese noch nicht zuverlässig, wer Lust hat, kann 
diese ja mal ausprobieren.

Falls Hilfe beim kompilieren benötigt wird, mich einfach anschreiben.

Gruß,
Marius

[Hendrik F. (henfri)]

Hallo,

keyble-mqtt wäre natürlich super.

Zum Code Beispiel:
Ich habe zuhause KNX und nutze https://www.smarthomeng.de/.
In der zugehörigen Visualisierung habe ich einen Button "öffnen" und 
einen "schließen".
Im der Konfiguration sieht das so aus:
  Hintertuer:
    Schloss:
      Locked:
          type: bool
          eval: "0 if (sh...Status_in() =='UNLOCKED' or sh...Status_in() 
=='OPENED') else 1"
          eval_trigger: ..Status_in()
          enforce_updates: true
      Status_in:
          type: str
          mqtt_topic_in: SmartlockHintertuer/status
          enforce_updates: true
      Lock:
          type: bool
          enforce_updates: true
      Action_out:
          type: str
          mqtt_topic_out: SmartlockHintertuer/action
          eval: "'unlock' if sh...Lock() ==0 else 'lock'"
          eval_trigger: ..Lock()
          enforce_updates: true

Ich habe also vier Items:
2 Items die lock/unlock bzw. UNLOCKED/OPENED vom MQTT erhalten bzw. 
senden
2 Items die daraus ein boolean machen (mit dem "eval")

Verstünde keyble-mqtt direkt die 0 für unlock(ed) und die 1 für lock, so 
bräuchte ich die Hilfsitems nicht.
Ich habe das Problem für mich ja gelöst.. Aber ich denke, dieses Problem 
hat dann jeder, der das Schloss über MQTT nutzt.

Und ja, ich differenziere hier nicht zwischen Unlocked und Opened.... 
Das ist der Kompromiss, den ich eingehe. Bei MQTT kann man ja mehrere 
Topics erzeugen.
Das eine ist dann eben eins, welches nur boolean ist. Das andere kann 
Status 0/1/2 und das dritte gibt den Batteriestatus usw.

> 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...

120s war ja ein Extrembeispiel. Wobei man im Falle ja auch noch die 
5-10s für die Kommunikation mit dem Schloss draufaddieren muss...
Aber für mich ist der Anwendungsfall, dass ich das Smartlock verwende 
eben nicht wenn ich vor der Tür stehe. Daher ist es nicht 
zeitkritisch.
Das mag für andere anders sein, v.a. wenn man das Schloss nutzen möchte, 
um Gästen die Tür zu öffnen.

@Marius: Danke für den Code.
Ich hatte per Mail Kontakt zu Marius und er schrieb mir, dass es vor 
allem (aber nicht ausschließlich) problematisch ist, BT und WLAN 
gleichzeitig zu nutzen.
Das ist wohl ein verbreitetes Problem beim ESP32 (shared Radio) für das 
es aber Workarounds gibt. Marius meint aber, dass es daran nicht liegen 
sollte, da ja ohnehin selten gleichzeitig gesendet wird.

Gruß,
Hendrik

[Hendrik F. (henfri)]

P.S: @Marius: Welches ESP32 Board nutzt du/kannst du empfehlen?

Gruß,
Hendrik

[Marius S. (lauch42)]

Hi Hendrik,

ist komplett egal. Ich nutze im Moment ein ESP32-Dev Board (mit einem 
ESP-WROOM-32 drauf) von Aliexpress.
Hauptsache microUSB dabei, das macht das Flashen und testen einfacher. 
Ansonsten unterscheiden die sich nicht stark, bis auf unterschiedliche 
Headerpinzahl.

Ich werde die Bibliothek in den nächsten Wochen noch etwas testen, wenn 
ich Zeit habe, und mal auf ein anderes Framework umschreiben, vielleicht 
klappt es dann ja besser.

Gruß,
Marius

[Joachim S. (oyo)]

Mindestens 2-3 Andere könnten sich also offenbar vorstellen, zwar die 
Türschlossantrieb-Mechanik, Gehäuse etc. zu behalten, aber die verbaute 
Platine/Elektronik gegen eine Eigenentwicklung mit eigener Firmware 
auszutauschen (oder zumindest zu erweitern).

Ich selbst spiele zwar immer noch mit dem Gedanken, auch 
Gehäuse/Mechanik/Motor selbst zu entwickeln (zum grossen Teil vermutlich 
einfach deshalb, weil ich gerade einen neuen 3D-Drucker gekauft und 
momentan Gefallen daran habe, irgendwelche 3D-Objekte zu entwerfen und 
zu drucken).
Aber richtig gemacht könnten diese beiden unterschiedlichen Ansätze ja 
wunderbar koexistieren:

In beiden Fällen müsste ja eine eigene Türschlossantrieb-Firmware 
entwickelt werden, und das wäre wohl eh der Löwenanteil des Aufwands. 
Wenn man diese Firmware von Anfang an bewusst so programmiert, dass sie 
auf einer dünnen Hardware-Abstraktions-Schicht aufsetzt, dann könnte die 
gleiche Firmware auf unterschiedlicher Hardware laufen, indem man für 
unterschiedliche Hardware-Plattformen nur die Implementierung der 
Hardware-Abstraktions-Schicht austauscht.

In meinen Augen wäre das die ideale, weil vielseitigste Lösung: Eine 
Smart Lock-Firmware, die mit geringen Anpassungen für unterschiedliche 
Türschlossantrieb-Hardware/-Mechaniken geeignet ist.

[Hendrik F. (henfri)]

Hallo,

<<In beiden Fällen müsste ja eine eigene Türschlossantrieb-Firmware
entwickelt werden, und das wäre wohl eh der Löwenanteil des Aufwands.
Wenn man diese Firmware von Anfang an bewusst so programmiert, dass sie
auf einer dünnen Hardware-Abstraktions-Schicht aufsetzt, dann könnte die
gleiche Firmware auf unterschiedlicher Hardware laufen, indem man für
unterschiedliche Hardware-Plattformen nur die Implementierung der
Hardware-Abstraktions-Schicht austauscht.>>

Aber immernoch würde es jemanden brauchen, der sich mit der Adaption der 
existierenden Hardware, sowie der Adaption der Software auf die Hardware 
kümmert.


Ich verstehe ja den "weil es geht"-Antrieb. Aber ehrlich gesagt 
funktioniert aktuell doch alles recht gut -außer bei mir mit den zwei 
Schlössern.
Ich muss ehrlich sagen, dass ich den Aufwand scheue.

Gruß,
Hendrik

[Joachim S. (oyo)]

Ich habe gestern zum ersten Mal selbst merkwürdige Bluetooth-Probleme 
erlebt:
Während keyble oder meine ähnliche Software zum Steuern des eqiva 
Heizungsthermostats aktiv ist, funktioniert Web Bluetooth in meinem 
Chrome-Webbrowser nicht mehr richtig. Beim Versuch, dort über Web 
Bluetooth auf ein gänzlich anderes Bluetooth-Gerät zuzugreifen, kam es 
zu merkwürdigen Fehlern - u.A. auch die Meldung, dass er den gewünschten 
Bluetooth-Service nicht finden kann. Die fast gleiche Fehlermeldung 
hatte ja schon mal ein anderer berichtet. Kaum beende ich keyble, klappt 
es wieder.

Damit sind die Probleme zwar noch nicht gelöst, aber es ist schon mal 
gut, dass ich gewisse Bluetooth-Probleme jetzt auch selbst reproduzieren 
und auf den Grund gehen kann.

[Philipp C. (e61_phil)]

Bei mir läuft nun auch keyble. Eine wirklich tolle Anleitung für den Pi! 
Vielen Dank!

[Michi (Gast)]

Hi,

> 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 habe ich endlich ein Szenario für dich, wo der Status immer nötig 
wäre.
PS: Bei mir rennt keyble-command ohne Unterbrechungen schon paar Tage 
lang :)

Aber! Wenn ich beim Eqiva die Batterien wechseln will, dann erkennt 
keyble nicht wirklich, dass die Verbindung unterbrochen wäre und es wäre 
halt toll wenn man immer einen Status zürückbekommt, so wäre es möglich 
und einfacher die Verbindung zu checken.

[Michi (Gast)]

Vielleicht muss so eine Option nicht released werden, who knows.
Aber für diejenige, die immer einen response sehen wollen - kann man 
keyble.js anpassen:

case Status_Info_Message:
        lock_status_id = message.data.lock_status;
        lock_status_string = {
          0: 'UNKNOWN',
          1: 'MOVING',
          2: 'UNLOCKED',
          3: 'LOCKED',
          4: 'OPENED'
        }[lock_status_id];
        this.emit('status_update', lock_status_id, lock_status_string);
        //if (this.lock_status_id !== lock_status_id) {
        this.lock_status_id = lock_status_id;
        this.emit(`status:${lock_status_string}`, lock_status_id, 
lock_status_string);
        this.emit('status_change', lock_status_id, lock_status_string);
        //}
        this.set_status_update_timer();
        break;

sprich den  "if (this.lock_status_id !== lock_status_id) " 
auskommentieren :)

[Joachim S. (oyo)]

Michi schrieb:
> Hi,
>
>> 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 habe ich endlich ein Szenario für dich, wo der Status immer nötig
> wäre.
> PS: Bei mir rennt keyble-command ohne Unterbrechungen schon paar Tage
> lang :)
>
> Aber! Wenn ich beim Eqiva die Batterien wechseln will, dann erkennt
> keyble nicht wirklich, dass die Verbindung unterbrochen wäre und es wäre
> halt toll wenn man immer einen Status zürückbekommt, so wäre es möglich
> und einfacher die Verbindung zu checken.

Hallo Michi,

ich bin mir nicht sicher, ob ich wirklich verstanden habe, was das in 
diesem Szenario für einen Vorteil bringen sollte. Bzw. ob ich Dein 
Szenario überhaupt richtig verstanden habe.

Rein durch das Wechseln der Batterien ändert sich der Zustand des 
Türschlossantriebs bzw. des Türschlosses 
('UNKNOWN'/'MOVING'/'UNLOCKED'/'LOCKED'/'OPENED') ja nicht.
Zumal: Der Batteriewechsel dauert üblicherweise vermutlich ein paar 
Sekunden; die Wahrscheinlichkeit, dass keyble während dieser Zeit 
überhaupt gerade mit dem Türschlossantrieb verbunden ist und somit die 
Verbindung unterbrochen würde, ist zumindest bei Verwendung der 
Standardeinstellungen recht gering.

@ All:
Ich war diese Woche unterwegs, und bin so gut wie gar nicht dazu 
gekommen, etwas an keyble zu machen. Dennoch habe ich mir die 
merkwürdigen Probleme mit anderen Bluetooth-Geräten, während keyble 
läuft, zumindest kurz anschauen können, und habe eine seeehr starke 
Vermutung, wo das Problem liegt.
Die Chancen liegen ziemlich gut, dass ich das zugrundeliegende Problem 
im Laufe der nächsten 1-2 Wochen beheben kann.

[Joachim S. (oyo)]

Schlechte Nachrichten:
Das Problem mit den mehreren Bluetooth-Verbindungen konnte ich leider 
doch nicht lösen. Ich konnte zwar ein kleines Problem beheben, welches 
vermutlich ebenfalls Probleme verursacht hätte, wenn mehrere Prozesse 
Bluetooth LE nutzen wollen. Wie sich herausstellte, war das aber 
zumindest nicht das einzige Problem: Die noble-Library, die keyble für 
die Bluetooth-Kommunikation benutzt, scheint diesbezüglich einfach 
irgendeinen Bug zu haben.

Somit liegt das Problem momentan leider ausserhalb meines 
Einflussbereichs.
Ich habe den Entwickler der noble-Library aber auch mal auf das Problem 
hingewiesen:
https://github.com/noble/noble/issues/835#issuecomment-454143991

[Michi (Gast)]

Hallo Joachim,

> Somit liegt das Problem momentan leider ausserhalb meines
Einflussbereichs.

Na dann warten wir bis ein update kommt :)

Sag mal, wäre es möglich die Konfiguration des Smart-Locks über keyble 
zu bearbeiten? z.B. pairing-modus aktivieren/deaktivieren, Drehrichtung 
auswählen usw.
Plannst du es zu realisieren?

[Joachim S. (oyo)]

Michi schrieb:
> Sag mal, wäre es möglich die Konfiguration des Smart-Locks über keyble
> zu bearbeiten? z.B. pairing-modus aktivieren/deaktivieren, Drehrichtung
> auswählen usw.
> Plannst du es zu realisieren?

Möglich wäre es - das gehört aber zu den Features, die ich grundsätzlich 
zwar gerne unterstützen würde, die derzeit aber so niedrige Priorität 
für mich haben, dass ich sie in der nächsten Zeit vermutlich eher nicht 
implementieren werde.

[Michi (Gast)]

> Möglich wäre es - das gehört aber zu den Features, die ich grundsätzlich
> zwar gerne unterstützen würde, die derzeit aber so niedrige Priorität
> für mich haben, dass ich sie in der nächsten Zeit vermutlich eher nicht
> implementieren werde.

Geht klar, dann gib bescheid sobald du damit beginnst :)
Und falls du die Android-App schon debugged hast - kannst du mir da die 
infos senden? Vielleicht werde ich ja diese Features implementieren 
können.

P.S. ich wollte unbedingt ausrechnen wie lange die Batterien leben 
werden, habe aber keine Infos dazu gefunden und habe eqiva direkt 
angeschrieben.

Die meinten, dass die Batterie-Warnung erscheinen wird, sobald die 
Batterien 1,2V erreichen. Die Lebensdauer die auf der Homepage steht (1J 
lang) wurde so berechnet:
4 x pro Tag wurde der Schloss bewegt
Somit können wir ausrechnen, dass die Batterien für 1460 
sperr/entsperrungen ausreichen werden.
Es kommt natürlich drauf an wie Schwer ist den Schlüssel zu drehen und 
ob es über keyble eine dauerhafte Verbindung zu Schloss hergestellt 
wurde.

Meine Batterie sollte ca. 5 Monate lang halten, danach kann ich mal 
sagen, ob es  mit den Berechnungen gestimmt hat oder nicht :)

[Al O. (cyber83)]

ich hab mein schloss nicht 4x am tag bewegt (im schnitt sicher nicht 
mehr als 2x pro tag!), den ersten satz batterien nur mit den tastern 
bedient (also ohne bluetooth) und es sind ca. 6 Monate geworden.
also, mit den 1460 Zyklen pro Satz batterien besser nicht kalkulieren.

[Michi (Gast)]

> ich hab mein schloss nicht 4x am tag bewegt (im schnitt sicher nicht
> mehr als 2x pro tag!), den ersten satz batterien nur mit den tastern
> bedient (also ohne bluetooth) und es sind ca. 6 Monate geworden.
> also, mit den 1460 Zyklen pro Satz batterien besser nicht kalkulieren.

Danke für die Info. Hast du den Schloss mit keyble angesteuert oder 
nicht? Falls ja, hast du eine dauerhafte Verbindung zum Schloss 
hergestellt?

[Michi (Gast)]

Achso, sorry, hab nur jetzt gecheckt, dass du den Schloss überhaupt ohne 
Bluetooth verwendet hast.
Schlecht, dann stimmen die Berechnungen von Eqiva nicht.

[Martin B. (Gast)]

Hallo alle zusammen...

habe seit gestern auch das "eqiva eQ-3 Bluetooth Smart Lock"
Ich steuer das ganze z.Z über ein altes Handy/Autoremote/Autoinput und 
(mini) Handsender am Schlüsselbunt (Intertechno)

Da ich fast alles mit openHAB und MQTT steuern kann, würde ich das 
Schloss darüber steuern können und damit der umweg über das Handy 
entfällt.

Leider hab ich überhaubt keine Ahnung wo ich da anfangen soll.
Gibt es vieleicht eine Step by Step Anleitung.
Hardware ist soweit vorhanden. (BT Stick 4.0 / Server WINDOWS )

Vielen Dank

[Hendrik Friedel (Gast)]

Steht doch in der Readme

[Michi (Gast)]

Meine Batterie hat nur 3,5 Monate lang gehalten, aber da war keyble 
verbindung immer aktiv, damit der Schloss schneller reagiert und pro 
Woche wurde der Schloss ca. 250-300 mal verwendet. d.h. ca. 14 Wochen 
hat er gut überlebt :)

Btw. Joachim, gibts was neues in deiner Library?

[Joachim S. (oyo)]

Michi schrieb:
> Meine Batterie hat nur 3,5 Monate lang gehalten, aber da war keyble
> verbindung immer aktiv, damit der Schloss schneller reagiert und pro
> Woche wurde der Schloss ca. 250-300 mal verwendet. d.h. ca. 14 Wochen
> hat er gut überlebt :)

Wirklich? Das ist viel länger, als ich jetzt erwartet hätte...

> Btw. Joachim, gibts was neues in deiner Library?

Nicht wirklich. Ich bin derzeit mehr mit anderen Sachen beschäftigt, und 
das einzige gravierende Problem, das keyble noch hat, ist meiner Meinung 
nach, dass es Probleme mit anderen Programmen gibt, die Bluetooth 
benutzen (bzw. das man nicht mehrere Instanzen von keyble starten kann). 
Daran scheine ich aber derzeit auch nichts ändern zu können, weil das 
offenbar ein Problem der verwendeten Bluetooth-Library ist...

[Michi (Gast)]

> Wirklich? Das ist viel länger, als ich jetzt erwartet hätte...

Jap, ich habe mir relativ teuere batterien gekauft, vlt liegts an dem

> Nicht wirklich. Ich bin derzeit mehr mit anderen Sachen beschäftigt, und
> das einzige gravierende Problem, das keyble noch hat, ist meiner Meinung
> nach, dass es Probleme mit anderen Programmen gibt, die Bluetooth
> benutzen (bzw. das man nicht mehrere Instanzen von keyble starten kann).
> Daran scheine ich aber derzeit auch nichts ändern zu können, weil das
> offenbar ein Problem der verwendeten Bluetooth-Library ist...

Ah na gut, gib mal bescheid falls sich was ändert :)

[Al O. (cyber83)]

Ich habe jetzt auch seit kurzem das monitoring und schließen / öffnen 
über mqtt.
Ich frage 5-minütlich per mqtt den status ab. Um auch immer den status 
gepusht zu bekommen hab ich auch (wie weiter oben) den if-block 
auskommentieren müssen. ;)
Grund: ich will wirklich auf jeden statusrequest per mqtt einen 
response. Der response wird mit timestamp in eine datenbank eingetragen. 
Ist der timestamp älter als 10 minuten ist 2x was schiefgegangen und ich 
visualisiere dass da was nicht stimmt.
Was mir noch abgeht ist irgend eine möglichkeit ein low battery 
auszulesen (damit ich das auch anzeigen kann).
Ich warte auch gerade noch auf einen wifi-türsensor:
https://s.click.aliexpress.com/e/cp7AEl21
Soviel ich gesehen hab kann man den auch ohne cloud verwenden. :-)

Lg

[Al O. (cyber83)]

irgendwas ist bei mir kaputtgegangen:
/usr/local/bin/keyble-sendcommand --address XXXX --user_id 1 --user_key 
XXXXXX--command status
module.js:549
    throw err;
    ^

Error: Cannot find module 'simble'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> 
(/usr/local/lib/node_modules/keyble/keyble.js:624:10)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)



npm install simble schreibt:
123 verbose about to build /root/node_modules/simble
124 verbose node_modules/simble unbuild
125 info preuninstall simble@0.2.5
126 info uninstall simble@0.2.5
127 verbose true,/root/node_modules,/root/node_modules unbuild 
simble@0.2.5
128 info postuninstall simble@0.2.5
129 error Error: Method Not Allowed
129 error     at errorResponse 
(/usr/share/npm/lib/cache/add-named.js:260:10)
129 error     at /usr/share/npm/lib/cache/add-named.js:203:12
129 error     at saved 
(/usr/share/npm/node_modules/npm-registry-client/lib/get.js:167:7)
129 error     at FSReqWrap.oncomplete (fs.js:135:15)
130 error If you need help, you may report this entire log,
130 error including the npm and node versions, at:
130 error     <http://github.com/npm/npm/issues>;
131 error System Linux 4.14.98+
132 error command "/usr/bin/node" "/usr/bin/npm" "install" "simble"
133 error cwd /root
134 error node -v v8.11.1
135 error npm -v 1.4.21
136 error code E405
137 verbose exit [ 1, true ]


kennt das jemand oder weiß was zu tun ist?

Danke!

[Hendrik (Gast)]

Hallo,
Im Noble git wurde zuletzt vor 11 Monaten committed. Auf den issue hat 
bisher kein Maintainer geantwortet.

Da fürchte ich, wird nix mehr kommen.

Siehst du einen Workaround für mich mit meinen zwei Schlössern, außer 
zwei Rapis zu verwenden?

Gruß,
Hendrik

[Al O. (cyber83)]

hendrik, falls es dir hilft: es genügt ein raspi zero w (er hat BT und 
wifi, kein lan!), der kostet als platine knapp über 10€.
also, man braucht keinen rpi3 kaufen. ;)

LG

[Al O. (cyber83)]

so, mit nodejs komplett neu installieren gehts jetzt bei mir wieder. da 
hab ich mit apt-get irgend was upgedated, danach wars kaputt. :-(
es hat bei nodejs aber auch ein komplettes manuelles löschen von 
node_modules-verzeichnis und dem cache-directory ".npm" gebraucht, dass 
da was funktionierendes wieder rausgeschaut hat.
tja, never change a running system ... o_O

[Al O. (cyber83)]

kann jemand mit dem fehler "Error: TypeError: Cannot read property 
'connect' of null" was anfangen?

das passiert bei mir mit "--auto_disconnect_time 10" und erholt sich 
auch nicht mehr, bis ich neu starte.

gepaart mit "status_update_time" kommt auch gleich noch etwas mehr an 
fehler.

ich werd's mal vorerst mit "--auto_disconnect_time 0" betreiben und 
schauen ob ich dann verlässlich statusmeldungen bekomme. das ist nämlich 
mein problem, dass ich nach einer gewissen zeit keine antworten mehr auf 
die MQTT requests bekomme ... also weder status noch lock noch unlock.

danke und LG!

hier mit DEBUG=keyble:

~DEBUG=keyble:* keyble-sendcommand --address YYYY --user_id 1 --user_key 
XXX --auto_disconnect_time 10 --status_update_time 20
status
  keyble:communication Sending message of type CONNECTION_REQUEST, data 
bytes <01 9f a9 2a a9 24 87 
2c af>, data 
{"user_id":1,"local_session_nonce":[159,169,42,169,36,135,44,175]} +0ms
  keyble:events Event: received:fragment +0ms
  keyble:communication Received message of type CONNECTION_INFO, data 
bytes <01 48 74 c2 a1 6b b1 4a 
80 00 10 17 00 00>, data 
{"user_id":1,"remote_session_nonce":[72,116,194,161,107,177,74,128],"boo 
tl 
oader_version":16,"application_version":23} +128ms
  keyble:events Event: received:message +17ms
  keyble:events Event: received:message:CONNECTION_INFO +2ms
  keyble:events Event: nonces_exchanged +6ms
  keyble:communication Sending message of type STATUS_REQUEST, data 
bytes <13 04 14 14 24 13>, data 
{"date":"2019-04-20T19:36:19.000Z"} +15ms
  keyble:events Event: received:fragment +164ms
  keyble:communication Received message of type STATUS_INFO, data bytes 
<71 00 2b 00 10 17 00 00>, d 
ata 
{"a":true,"user_right_type":3,"e":false,"f":false,"g":false,"h":true,"i" 
:false,"j":true,"lock_st 
atus":3,"l":16,"m":23} +183ms
  keyble:events Event: received:message +26ms
  keyble:events Event: received:message:STATUS_INFO +3ms
  keyble:events Event: status_update +3ms
  keyble:events Event: status:LOCKED +3ms
  keyble:events Event: status_change +3ms
LOCKED
  keyble:events Event: disconnected +10s
status
Error: TypeError: Cannot read property 'connect' of null
(node:22399) UnhandledPromiseRejectionWarning: TypeError: Cannot read 
property 'connect' of null
    at Promise 
(/usr/local/lib/node_modules/keyble/node_modules/simble/simble.js:549:33 
)
    at new Promise (<anonymous>)
    at _Class.ensure_connected 
(/usr/local/lib/node_modules/keyble/node_modules/simble/simble.js:544:14 
)
    at _Class.ensure_discovered 
(/usr/local/lib/node_modules/keyble/node_modules/simble/simble.js:582:19 
)
    at ensure_peripheral.then 
(/usr/local/lib/node_modules/keyble/keyble.js:888:85)
    at <anonymous>
(node:22399) UnhandledPromiseRejectionWarning: Unhandled promise 
rejection. This error originated either by throwing inside of an async 
function without a catch block, or by rejecting a promise which was not 
handled with .catch(). (rejection id: 5)
(node:22399) [DEP0018] DeprecationWarning: Unhandled promise rejections 
are deprecated. In the future, promise rejections that are not handled 
will terminate the Node.js process with a non-zero exit code.
connect
Error: Unknown command "connect"

[Al O. (cyber83)]

nachdem ich jetzt den gesamten rpi mit neuem image, node, etc 
ausgestattet habe und es noch immer nicht mehr geht bin ich auf der 
suche, was da dafür verantwortlich ist.

vielleicht kann jemand mit einem funktionierendem setup mit die ausgabe 
der versionen zur verfügung stellen, dass ich probieren kann?

npm list -g : https://pastebin.com/UwqYQLDJ
dpkg -l | grep blue : https://pastebin.com/reh9ywZj
dpkg -l | grep kernel : https://pastebin.com/KhFVW3vG

symptom: es schaut für mich so aus wie wenn der reconnect zum türschloss 
nicht mehr funktioniert, sobald ein mal (wegen was auch immer) die 
verbindung unterbrochen wurde. es hilft bei mir keine 
auto_disconnect_time (irgendwann scheints dann doch immer neu zu 
connecten), aber dafür dann immer ein neustart von keyble_sendcomand - 
bis zum nächsten disconnect. :-(

Danke!

LG

[Al O. (cyber83)]

kleines enhancement gemacht: batteriestatus.

keyble.js zeile 334: aus "e: function()" ein "battery_low: function()" 
machen:
...
    333     },
    334     battery_low: function() {
    335       return bit_is_set(this.data_bytes[1], 7);
    336     },
    337     f: function() {
...

keyble.js zeile 802 bis 804 hinzugefügt:
...
    800           4: 'OPENED'
    801         }[lock_status_id];
    802         if (message.data.battery_low) {
    803           lock_status_string = lock_status_string + ' 
LOW_BATTERY';
    804         }
    805         this.emit('status_update', lock_status_id, 
lock_status_string);
...

damit bekommt man zu jeder statusausgabe (MOVING  LOCKED  UNLOCKED / 
...) ein " LOW_BATTERY" mit angehängt.

Joachim, falls das in deinem Sinne ist fühle dich so frei und nimms in 
deinen code mit auf. ;)

LG

[Michi (Gast)]

>> keyble.js zeile 334: aus "e: function()" ein "battery_low: function()"
machen

Habe genau das gleiche gemacht, ist ziemlich praktisch, als den Batterie 
Status immer abzufragen ;)

Bezüglich deinen Fehler:
Du kannst mir mal auf Telegram (@Mishenka) schreiben, dann kann ich dir 
meine funktionierende libs zusenden, da ich den rpi schon seit dezember 
nicht upgedated habe und alles funktioniert bei mir fehlerhaft :)

[Al O. (cyber83)]

Hi Michi,
ich hab leider kein Telegram.
kannst mir das bitte per mail an madloisae (at) gmx . net schicken?
Danke! :-)

[Al O. (cyber83)]

ziemlich ruhig hier geworden. :-(

[Joachim S. (oyo)]

Hallo Al, sorry, dass ich erst jetzt antworte. Ich war die letzten 
Wochen mit anderem beschäftigt und hier nicht aktiv.

Leider kann ich auf Anhieb auch erst einmal nur wenig zu Deinem Problem 
sagen. :-(
Da die von keyble verwendete Bluetooth-Library "noble" ja offenbar nicht 
mehr weiterentwickelt wird, habe ich auf Wunsch Ende Februar zu einem 
Fork von "noble" gewechselt, der weiterentwickelt wird. Möglicherweise 
hat Dein Problem irgendwie mit diesem Wechsel zu tun - denn das war die 
einzige Änderung, die es in den letzten Monaten überhaupt gab, und ich 
habe diesen Fork bislang nicht einmal selbst ausprobiert.

Die vorgeschlagenen Ideen, um den Batterie-Status anzuzeigen zu lassen 
oder den aktuellen Zustand bei jedem Request anzeigen zu lassen, finde 
ich aber gut und sinnvoll. Ich bin gerade nur noch nicht ganz sicher, 
wie man das am sinnvollsten umsetzt, denn wenn eine neue keyble-Version 
plötzlich ein "LOW_BATTERY" an die Statusausgabe anhängen würde, dann 
würde das ja möglicherweise zu Problemen/Fehlern führen bei Leuten, die 
die Ausgabe irgendwie weiterverarbeiten und mit dieser Änderung an der 
Ausgabe nicht rechnen. Daher tendiere ich momentan dazu, dass man eine 
solche rückwärtsinkompatible Änderung der Ausgabe durch ein 
Kommandozeilen-Flag explizit aktivieren muss. Wäre das ok?

[Al O. (cyber83)]

Hi Joachim,

ich habe keyble 0.1.14 im Einsatz, ich denke nicht dass deine software 
was anders macht, sondern dass irgend etwas anderes upgedated hat.
mir wäre sehr geholfen wenn ich die versionen die funktionieren gepastet 
bekomme (siehe weiter oben einen post von mir die commands zum 
abgleichen).

batteriestatus optional (sprich mit cli-flag) und ein force für's pushen 
(auch mir cli) ist natürlich in ordnung.
Es ist auch so wie es jetzt ist in ordnung, man kann sich's ja sehr 
einfach selber anpassen.

danke für deine Mühe.

LG Alois

[Jonas B. (jibi)]

Ohje, wenn ich npm und Türschloss in einem Satz lese. Hast du dir mal 
die Pakete / Quellen angeschaut die da so bei einem kleinen Paket 
installiert werden?

[Joachim S. (oyo)]

Jonas B. schrieb:
> Ohje, wenn ich npm und Türschloss in einem Satz lese. Hast du dir mal
> die Pakete / Quellen angeschaut die da so bei einem kleinen Paket
> installiert werden?

Ja, durch die zur Bluetooth LE-Kommunikation verwendete noble-Library 
installiert man zwangsläufig einige dutzend npm-Pakete als 
Abhängigkeiten.

Und ja, schön finde auch ich das nicht, aber so ist es eben. Und 
andererseits ist es ja auch so, dass die meisten dieser npm-Pakete 
winzig sind und nur lokal in einem Unterverzeichnis von keyble 
installiert werden, und daher kaum stören.
Ich habe meine ersten Erfahrungen mit Bluetooth LE-Programmierung halt 
mit dieser Library gemacht, weil das damals einfach eine der am 
weitesten entwickelten und einfachsten Bluetooth LE-Libraries war. Und 
bin für Bluetooth LE-Programmierung bislang immer bei dieser Library 
geblieben, und auch heute noch scheint mir das Angebot an guten und mit 
allen wichtigen Betriebssysteme kompatiblen Bluetooth LE-Libraries noch 
sehr mager zu sein.
Für Python bspw. ist da offenbar "bluepy" am populärsten, aber das ist 
bislang auch wieder nur für Linux verfügbar.

Gut, da die meisten keyble offenbar eh auf einem Linux-PC (und in den 
meisten Fällen wohl einem Raspberry Pi) benutzen, wäre es in der Praxis 
wohl kein Problem, auf die Plattformunabhängigkeit einfach zu scheissen 
und irgendeine andere Bluetooth-Library und Programmiersprache zu 
nehmen, womit keyble dann halt nur unter Linux lauffähig wäre.

Aber das darf gerne ein anderer übernehmen. Mein Ansporn für keyble war 
damals primär die Hacker-mässige Herausforderung, diesen 
Türschlossantrieb bzw. die verschlüsselte Kommunikation soweit zu 
reverse engineeren, dass man die wichtigsten Funktionen mit einer 
alternativen Software steuern bzw. in eine Heimautomatisierungssysteme 
integrieren kann. Einfach weil das bis dato noch niemand geschafft oder 
getan hat.
Diesen wichtigen ersten Schritt habe ich geschafft; den Aufwand, das auf 
andere Programmiersprachen oder Libraries zu portieren oder umfangreiche 
Erweiterungen vorzunehmen, werde ich selbst aber wohl nicht mehr machen.

[Btstack (Gast)]

Ich habe mich mal auf der Suche nach möglichen BTLE Libs für C++ 
gemacht, da ja hier schon jemand eine ESP32 Portierung in C++ angefangen 
hatte.

Nur Linux:
https://github.com/edrosten/
Nutzt den Kernel Bluetooth-Stack ohne Dbus-Api

Verschiedene OS (auch Linux und Windows):
BTstack

Mehr Open-Source in C++ hab ich nicht gefunden, das nutzbar erscheint.

[Hendrik F. (henfri)]

Hallo Joachim,

das verstehe ich.
Könntest du denn die Kommunikation/das Protokoll dokumentieren, so dass 
man nicht zunächst js lernen muss, um das nach python zu portieren?

Gruß,
Hendrik

[Joachim S. (oyo)]

Hendrik F. schrieb:
> Hallo Joachim,
>
> das verstehe ich.
> Könntest du denn die Kommunikation/das Protokoll dokumentieren, so dass
> man nicht zunächst js lernen muss, um das nach python zu portieren?

Das Problem ist, dass ich mich sogar selbst nur noch grob an das 
Protokoll erinnere. Die Zeit, als ich mich wirklich intensiv mit dem 
reverse engineering des Protokolls beschäftigt habe, ist mittlerweile 
ziemlich genau 1 Jahr her. Seitdem habe ich die meisten Details schon 
wieder vergessen; ich weiss noch, dass mit AES-128-Verschlüsselung 
gearbeitet wurde, dass irgendwelche "Nonces" berechnet und angehängt 
wurden usw. usw., aber viel mehr auch nicht; wenn ich wissen will, wie 
irgendetwas genau funktioniert hat, muss auch ich mir den Sourcecode 
anschauen und versuchen nachzuvollziehen, was da genau gemacht wird. Und 
leider habe ich den Sourcecode auch nur sehr knapp kommentiert, was es 
nicht gerade leichter macht... :-(

Was vielleicht Sinn machen würde: Dass ich versuche wenigstens die 
Verschlüsselung zu dokumentieren/erklären. Denn die dürfte vermutlich 
die grösste Hürde sein.

[Hendrik Friedel (Gast)]

Hallo,

ich nutze jetzt mqtt-launcher (https://github.com/jpmens/mqtt-launcher), 
um keyble bei Bedarf zu starten. Dadurch läuft keyble nicht mehr 
dauernd, und das Öffnen/Schließen dauert länger, aber dafür kommen die 
zwei Instanzen sich nicht in die Quere.

Gruß,
Hendrik

[Joachim S. (oyo)]

Was ich schon länger befürchtet habe, scheint mittlerweile eingetreten 
zu sein:
eqiva scheint den Türschlossantrieb gar nicht mehr herzustellen/zu 
verkaufen.

Laut der Preisvergleichsseite "Geizhals" ist der Türschlossantrieb nur 
noch auf Amazon Marketplace zu haben:
https://geizhals.de/eq-3-eqiva-bluetooth-smart-tuerschlossantrieb-142950a0-a1558657.html
Da gibt es noch genau zwei Exemplare, ein neues für irrwitzige 242 Euro, 
und ein gebrauchtes für 100 Euro. Auf eBay gibt es auch nur noch ein 
paar wenige Exemplare, zu ähnlichen Mondpreisen zwischen 139 und 332 
Euro.

Vergleichbare Türschlossantriebe in einer ähnlich günstigen Preislage 
konnte ich auf die Schnelle nicht finden. Wer an einem günstigen 
Türschlossantrieb interessiert ist aber bislang noch keinen eqiva eq-3 
Türschlossantrieb hat, der hat derzeit also im Grunde gelitten.

Vielleicht sollte man langfristig doch mal überlegen, ob nicht ein paar 
Leute zusammen einen Open Source/Open Hardware-Türschlossantrieb mit 
3D-gedruckten Teilen entwickeln.

[pino47 (Gast)]

Kann mir jemand weiterhelfen mein Schloß dreht immer in die falsche 
Richtung.
lock und unlock kann man ja über command 1 oder 0 ändern aber das open 
nicht.

also wie am besten?
mfg

[Michi (Gast)]

pino47 schrieb:
> Kann mir jemand weiterhelfen mein Schloß dreht immer in die
> falsche
> Richtung.
> lock und unlock kann man ja über command 1 oder 0 ändern aber das open
> nicht.
>
> also wie am besten?
> mfg

Schaue bitte deine Einstellungen in der Eqiva App am Handy an, dort kann 
man die Drehrichtung anpassen.

[Pino47 (Gast)]

Ja das weiß ich kann aber nur die keyble benutzen da ich sonst wieder 
alles neu einrichten muss. Wir ja  bestimmt auch eine andere Lösung 
geben.

[Hendrik (Gast)]

Schloss auf die andere Seite der Tür ;-)

Aber im Ernst: Einrichten ist doch kein großer Aufwand.
Und App und keyble lassen sich parallel nutzen.

[pino47 (Gast)]

also bei mir entweder app oder keyble, hab immer nur ein benutzer

[Al O. (cyber83)]

schon gesehen dass es jetzt den türschlossantrieb in kombination mit 
einem fingerprint reader von ekey uno gibt? zu finden auf amazon unter 
"ekey uno Fingerprint mit Akku und Funk inkl. eqiva BLUETOOTH® Smart 
Türschlossantrieb - Akkubetriebenes Nachrüst-Set für alle gängigen 
Türen"

da kostet's um einiges mehr ... vielleicht probiert das jemand mit der 
software hier auf kompatiblität?

bei mir ist das ganze wirklich problemlos mit software und PHP-MQTT 
scripte die ich inzwischen als systemd eingerichtet hab.

hier das damals zusammengestöpselte script: 
https://pastebin.com/JZJnXq0d

LG

[Herbert (Gast)]

Al O. schrieb:

> schon gesehen ...

https://www.amazon.de/Duden-Rechtschreibung-umfassende-Standardwerk-Grundlage/dp/3411040173/ref=sr_1_1

[Joachim S. (oyo)]

Al O. schrieb:
> schon gesehen dass es jetzt den türschlossantrieb in kombination mit
> einem fingerprint reader von ekey uno gibt? zu finden auf amazon unter
> "ekey uno Fingerprint mit Akku und Funk inkl. eqiva BLUETOOTH® Smart
> Türschlossantrieb - Akkubetriebenes Nachrüst-Set für alle gängigen
> Türen"

Das hatte ich neulich auch schon entdeckt, ja.

Ist irgendwie schon merkwürdig, das Ganze: Eqiva bzw. eq-3 selbst 
verkauft den Türschlossantrieb offenbar gar nicht mehr - trotzdem bietet 
stattdessen plötzlich eine ganz andere Firma ein Bundle damit an, für 
stolze 300 Euro mehr?

https://www.ekey-shop.com/ekey-uno-wlan-bluetooth-fingerscanner-smart-home-nachruestloesung-tuer/

[Michi (Gast)]

Servus Joachim S.,

ich benutze noch immer seit Dezember 2018 deine keyble Lösung und bin 
zufrieden, danke dir :) Hast du zufällig hierfür was neues entwickelt, 
vielleicht die Steuerung für die Thermostate, oder bist du vom Eqiva 
Schloss auf was anderes umgestiegen?

Ach ja, bei noble-Library hat sich leider nichts getan, aber was solls, 
ein Raspberry kostet nur 10€, so könnte man den noble bug umgehen, was 
ich bis jetzt auch mache :)

[Joachim S. (oyo)]

Michi schrieb:
> Hast du zufällig hierfür was neues entwickelt,
> vielleicht die Steuerung für die Thermostate, oder bist du vom Eqiva
> Schloss auf was anderes umgestiegen?

Hallo Michi,

nein, ich habe an keyble seitdem nichts mehr weiterentwickelt, u.A. weil 
es den eqiva-Türschlossantrieb ja offenbar eh nicht mehr zu kaufen gibt.

Eine keyble-ähnliche Lösung für die günstigen 
eqiva-Bluetooth-Thermostate habe ich schon damals veröffentlicht:
https://github.com/oyooyo/nixfilter-rtble
Funktioniert grundsätzlich genau wie keyble, im Sinne von: Es ist darauf 
ausgelegt als "Filter" benutzt zu werden, also per "Pipe" hinter ein 
anderes Programm wie z.B. mosquitto_sub gehängt zu werden.
Ist allerdings absolut minimalistisch - man kann lediglich die 
Ziel-Temperatur einstellen und abfragen, das war's.

Aufgrund der verwendeten noble-Library Probleme geben könnte, keyble und 
die Software für die Thermostate parallel zu verwenden. Sobald zwei 
Prozesse gleichzeitig versuchen, die noble-Library zu verwenden, gibt es 
wohl Probleme, die man wohl nur durch Verwendung eines weiteren 
Bluetooth-Adapters umgehen kann:
https://github.com/abandonware/noble/issues/26

[Uwe F. (ufe)]

Den Antrieb gibt es wieder zu kaufen. (Reichelt, Amazon, Eqiva ...)
Kostet überall 79 Euro.

[Joachim S. (oyo)]

Uwe F. schrieb:
> Den Antrieb gibt es wieder zu kaufen. (Reichelt, Amazon, Eqiva ...)
> Kostet überall 79 Euro.

Interessant, das war mir bis eben nicht bewusst.

Ich wüsste ja gerne mal, warum es das Gerät dann so lange nicht mehr zu 
kaufen gab (bzw. nur noch im Set mit dem teuren 
Ekey-Fingerabdruckscanner), und jetzt plötzlich doch wieder.
Ob sich ausser der Preiserhöhung um ca. 20-30 Euro sonst noch etwas 
geändert hat, z.B. das Protokoll?

[Florian M. (Gast)]

@oyo
ich würde mir gernen so einen Antrieb zulegen, wenn deine Software das 
aber nicht mehr supported, will ich das Ding nicht haben.

Schwierig...

[Joachim (Gast)]

Florian M. schrieb:
> @oyo
> ich würde mir gernen so einen Antrieb zulegen, wenn deine Software das
> aber nicht mehr supported, will ich das Ding nicht haben.

Ob eqiva bei den aktuell vertriebenen Türschlossantrieben irgendwas am 
Protokoll geändert hat, wodurch meine Software nicht mehr kompatibel 
wäre, kann ich mangels eines entsprechenden Gerätes zwar nicht mit 
allerletzter Sicherheit sagen.

Aber ich sehe ein sehr starkes und ein etwas weniger starkes Indiz 
dafür, dass meine Software auch mit den aktuellen Geräten noch 
funktionieren müsste:

1) Das sehr starke Indiz: Die offizielle Android-App von eqiva zur 
Steuerung des Türschlossantriebs wurde seit 2017 nicht mehr 
aktualisiert:
https://play.google.com/store/apps/details?id=de.eq3.ble.key.android&hl=de
Wenn sich das Protokoll in der jüngeren Vergangenheit geändert hätte, 
hätte es aber auch Änderungen an der Android-App geben müssen.

2) Das weniger starke Indiz: Weder hier noch auf Github wurden mir 
bislang Probleme gemeldet, dass jemand ein aktuelles Gerät gekauft hat 
und meine Software damit nicht funktioniert.

Meiner Einschätzung nach sollten die aktuell vertriebenen Exemplare mit 
an Sicherheit grenzender Wahrscheinlichkeit kein anderes Protokoll 
benutzen, und daher weiterhin zu meiner Software kompatibel sein.

[tcsmaxx (Gast)]

Hallo zus.,

hat jemand zufällig mal analysiert, wo man auf der Platine ein Signal 
abgreifen kann, wann das schloss schließt bzw. öffnet?

Ich habe das Schloss mit einen ESP laufen, der die Taster Auf/Zu 
'betätigt'. Ich wüsste jetzt gern noch, wann jemand das Schloss manuell 
mit dem Schlüssel dreht.

Beste Grüße
Maxx

[Hendrik (Gast)]

Hallo Maxx,

leider weiß ich das auch nicht.
Ich hatte das auch mal so wie du versucht. Bin aber gescheitert:
https://knx-user-forum.de/forum/öffentlicher-bereich/gebäudetechnik-ohne-knx-eib/1236022-erster-erfolg-günstiges-smartlock-eq3-eqiva-fernsteuern?p=1238418#post1238418

Wie hast du das Problem gelöst?

Gruß,
Hendrik

[Joachim S. (oyo)]

tcsmaxx schrieb:
> hat jemand zufällig mal analysiert, wo man auf der Platine ein Signal
> abgreifen kann, wann das schloss schließt bzw. öffnet?

Bin nicht 100%ig sicher, ob ich Deine Frage richtig interpretiere, aber 
vielleicht hilft Dir das:
In dem Gerät sind zwei Taster verbaut, über die die Elektronik grob 
weiss, wie der auf der Innenseite steckende Schlüssel, den das Smart 
Lock dreht, gerade steht. Also ungefähr so:

Taster 1 | Taster 2 | Stellung
0        |0         | 0°
0        |1         | 90°
1        |1         | 180°
1        |0         | 270°

Wenn Du an die Kontakte dieser beiden Taster ein Kabel anlötest, sie mit 
zwei Input Pins des ESP verbindet und den Zustand dieser beiden Input 
Pins überwachst, dürftest Du manuelle Drehungen erkennen können, 
zumindest wenn die Drehung über 90° beträgt.
Aber das gilt halt nur für Drehungen an der Türinnenseite, wenn jemand 
das Schloss von aussen öffnet/schliesst, dann dürfte es keine 
Möglichkeit geben, das zu erkennen.

p.s.: Wenn Du einen ESP verwendest - wie versorgst Du den mit Strom?

[tcsmaxx (Gast)]

Hallo Hendrik,

ich habe diese Code dafür:

void SetDoorState(String state) {
  if (state == "1") { // OPEN
    Serial.println("open");
    pinMode(openLock, OUTPUT);
    digitalWrite(openLock, LOW);
    delay(200);
    pinMode(openLock, INPUT);
    mqttClient.publish(doorTopic, "open");
  }
  if (state == "0") { // CLOSE
    Serial.println("close");
    pinMode(closeLock, OUTPUT);
    digitalWrite(closeLock, LOW);
    delay(200);
    pinMode(closeLock, INPUT);
    mqttClient.publish(doorTopic, "close");
  }
}

An den GPIO's habe ich jew. einen 4k7 Widerstand dran.

VG Maxx

[tcsmaxx (Gast)]

Hallo Joachim,

vielen Dank für deine Ausführungen! Das werde ich mir mal ansehen :)
Ich verwende ein 5V Netzteil und versorge damit gleich das Schloss.

VG,
Maxx

[Mirko W. (Gast)]

Ist jemand von euch schon auf dieses Projekt gestoßen? Hier werden die 
Thermostate inkl. Ventilstellung ausgelesen und die ganzen Modi gesetzt:

https://github.com/Heckie75/eQ-3-radiator-thermostat/blob/master/eq-3-radiator-thermostat-api.md

Kann es sein, dass sich hinter dem 'unknown' mode eine Ansteuerung per 
Ventilstellung versteckt?
Ich würd es gerne testen, hab mir die Thermostate aber gerade erst 
bestellt.

[Joachim S. (oyo)]

Mirko W. schrieb:
> Kann es sein, dass sich hinter dem 'unknown' mode eine Ansteuerung per
> Ventilstellung versteckt?

Halte ich für äusserst unwahrscheinlich. Das "Mode"-Byte von dem Du 
redest, wo etwas von "unknown" steht - das scheinen lediglich 8 Flags zu 
sein, die etwas über den aktuellen Zustand des Thermostats aussagen. Wie 
eben z.B. das höchstwertige Bit, das anzeigt, ob die Batterie leer ist. 
Oder "dst", das vermutlich anzeigt, ob die Uhr auf Sommer-/Winterzeit 
eingestellt ist.

Mir wäre nicht bekannt, dass man bei dem Thermostat das Ventil direkt 
steuern kann. Auch in der Hersteller-App gibt es ja keine derartige 
Option.

> Ich würd es gerne testen, hab mir die Thermostate aber gerade erst
> bestellt.

Preislich sind die Thermostate echt top. Sie haben aber auch einen 
gravierenden Nachteil: Sie haben quasi keinerlei 
Sicherheitsvorkehrungen. Jeder, der in Funkreichweite des Thermostats 
ist, könnte einem das Thermostat theoretisch nach Belieben verstellen. 
Die Hersteller-App täuscht da zwar eine gewisse Sicherheit in Form einer 
PIN vor, aber das ist vereinfacht gesagt reine Verasche.

Anyway: Eigentlich ist das hier der falsche Thread, hier geht es nicht 
um das Heizungsthermostat, sondern um den Türschlossantrieb der gleichen 
Firma.

[tcsmaxx (Gast)]

Hallo oyo,

habe dein keyble-Tool auf dem RASPi installiert und muss sagen, super 
Arbeit - es funktioniert alles perfekt!!

Ich hatte bisher immer einen ESP verwendet, der mir die Taster am 
Türschlossantrieb 'betätigt'. Das reicht mit aber jetzt nicht mehr aus, 
da ich weitere Geräte an Türen installiert habe, an den ein Knauf sitzt 
und jetzt auch die Türfalle mit eingezogen werden muss.

Kennst du die Portierung deines Codes von Marius Schiffer für den ESP32?

https://github.com/MariusSchiffer/esp32-keyble

Der Entwickler führt das Projekt nicht mehr fort, da er diesen 
Schlossantrieb nicht mehr verwendet.

Ich habe mir den Port mal auf einen ESP32-Cam geflasht und getestet. 
Prinzipiell funktioniert es, aber nicht zuverlässig und der Status des 
Schloss wir immer mit '1' angegeben. Was mir auch noch aufgefallen ist, 
nach jeder Aktion resettet der ESP.

Da du das Protokoll ja selbst komplett Reverse engineered hast, könntest 
du vielleicht mal schauen wo der Bug liegt? :)

Hier mein forked Repository:

https://github.com/tc-maxx/esp32-keyble

BG
MaXX

[Joachim S. (oyo)]

Hallo,

tcsmaxx schrieb:
> Kennst du die Portierung deines Codes von Marius Schiffer für den ESP32?
>
> https://github.com/MariusSchiffer/esp32-keyble

Kenne ich leider nur in dem Sinne, dass ich um die Existenz des Projekts 
weiss. Näher damit beschäftigt habe ich mich nie, weil ich keine 
persönliche Verwendung dafür hatte.

> Da du das Protokoll ja selbst komplett Reverse engineered hast, könntest
> du vielleicht mal schauen wo der Bug liegt? :)

Meine C/C++-Kenntnisse sind leider minimal. Dass ich die wichtigsten 
Teile des Protokolls mal reverse engineered habe, bringt mir an der 
Stelle vermutlich auch wenig. Das Resetten des ESP nach jeder Aktion 
dürfte ja auch eher nichts mit dem Protokoll zu tun haben.
Ich fürchte, ich würde mehrere Stunden damit verschwenden, recht planlos 
irgendwas herumprobieren, aber das Problem nicht beheben können. :-(

Aktuell verfolge ich nebenbei meinen alten Plan etwas weiter, einen 
eigenen günstigen 3D-druckbaren Türschlossantrieb zu entwickeln, der 
über ZigBee und BLE gesteuert werden kann. Wenn ich das weiter 
durchziehe, muss ich mich demnächst eh tiefer in C/C++ einarbeiten. 
Eventuell würde ich mir esp32-keyble dann nochmal anschauen, aber auch 
das will ich nicht versprechen.

[Hendrik Friedel (Gast)]

Hallo,

ich kenne das Projekt von Marius, habe es ausprobiert und war in der 
Vergangenheit mit ihm in Kontakt.
Ein Problem ist, dass der der ESP32 wenn er mit der Arduino Umgebung 
genutzt wird nicht BT und WLan gleichzeitig nutzen kann.
Marius wollte das lösen, indem er die Software auf "nativ" ESP32 
portiert. Mein Vorschlag wäre einfach pragmatisch gewesen:
WLAN an - Lauschen bis Kommando
WLAN aus
BT an Kommando per BT absetzen, reaktion abwarten
BT aus
WLAN an, lauschen was über MQTT so gekommen ist und Status über MQTT 
absenden.

Ich denke, mein Ansatz wäre schnell umgesetzt - wenn man sich besser als 
ich auskennt.

Wieviel Aufwand die Portierung ist (und ob es dann funktioniert) weiß 
ich nicht.

Dennoch finde ich die Lösung über einen ESP32 charmanter, da man kein 
Dateisystem auf SD-Karte, keine Software-Updates, kein nix hat.

Gruß,
Hendrik

[Max M. (tcsmaxx)]

Hallo Hendrik,

ich glaube das funktioniert. Ich habe noch ein paar andere Sachen 
angepasst und jetzt wird nicht mehr resettet und der Lock-Status wird 
auch korrekt ermittelt.

Ich aktualisiere dann mal mein Repository

VG Maxx

[Hendrik F. (henfri)]

Max M. schrieb:

> ich glaube das funktioniert. Ich habe noch ein paar andere Sachen
> angepasst und jetzt wird nicht mehr resettet und der Lock-Status wird
> auch korrekt ermittelt.
>
> Ich aktualisiere dann mal mein Repository

Hey cool.

Berichte Mal wir es läuft, dann steige ich auch um.

Gruß,
Hendrik

[Max M. (tcsmaxx)]

Hi, es funktioniert. Ich hab's hochgeladen.

[Hendrik Friedel (Gast)]

Hallo Max,

ich habe es getestet. Funktioniert - und zwar deutlich schneller als mit 
dem Raspi.

Dann habe ich einige Änderungen vorgenommen:
1) statt numerischer Kommandos habe ich "lock/unlock/open" implementiert
2) Geheimes in eine secrets.h ausgelagert
3) Support für zwei Locks hinzugefügt

Seit (3) funktioniert es nicht mehr.
Magst du dir das mal ansehen?

https://github.com/henfri/esp32-keyble

Gruß,
Hendrik

[Hendrik Friedel (Gast)]

P.S: hier der Output:

 # Mit MQTT-Broker verbinden...  verbunden!
# Nachricht empfangen: lock
# Topic: SmartlockHintertuer/command
# Lock Number: 1
Schließen
# WiFi detiviert
# Erhalte Semaphore für Sendekommando
# Nonces austauschen
# Suche ...
# Semaphore abgeben
# WiFi aktiviert
# WiFi getrennt, wiederverbinden...
# WIFI: verbinde...
# WIFI: Verbindung wiederhergestellt: SSiD: FriedelNetz
# WIFI: Signalqualität: 96%
# WIFI: IP-Adresse: 192.168.177.63

[Rop09 (Gast)]

Hallo zusammen,

ich habe mit einem Raspi4 folgendes Problem (siehe Code unten). Die 
connection funktioniert grundsätzlich, aber nicht sehr zuverlässig.

Mit dem Smartphone kann ich auch aus noch weiterer Entfernung problemlos 
auf das Schloss zugreifen, mit dem Raspi aber ist es sehr unzuverlässig.

Wie man unten sieht gibts im Fehlerfall immer einen Disconnected event 
(nach einem Connect), nachdem rein gar nichts mehr passiert und die SW 
in den Timeout läuft, egal wie lange ich ihn stelle.

Wenn es funzt dann meistens sehr schnell nach <5 Sekunden.  Die 
Entfernung vom BLE 4.0 USB Stick (extern, nicht der interne vom RPi4) 
beträgt etwa 7m + ein Wandstück bzw Glastür mit Wandanteil.
Würde ein BLE 5.0 Stick hier verbesserung bringen?
Ist so ein verhalten bekannt?

att 00:1a:22:13:6f:77: write: 020001 +0ms
  hci push to acl queue: 024700070003000400020001 +8ms
  hci flush - pending: 0 queue length: 1 +2ms
  hci write acl data packet - writing: 024700070003000400020001 +2ms
  simble:event Peripheral 00:1a:22:13:6f:77 : Event "connected" +0ms
  simble:info Connected to peripheral 00:1a:22:13:6f:77 +1s
  simble:info Discovering peripheral 00:1a:22:13:6f:77... +2ms
  hci onSocketData: 011620024700 +8ms
  hci   event type = 1 +1ms
  hci           cmd = 8214 +0ms
  hci           data len = 2 +1ms
  hci onSocketData: 040f0400011620 +0ms
  hci   event type = 4 +1ms
  hci   sub event type = 15 +0ms
  hci           status = 0 +0ms
  hci           cmd = 8214 +0ms
  hci onSocketData: 043e0c043e47000000000000000000 +1ms
  hci   event type = 4 +0ms
  hci   sub event type = 62 +0ms
  hci           LE meta event type = 4 +1ms
  hci           LE meta event status = 62 +0ms
  hci           LE meta event data = 47000000000000000000 +0ms
  hci onSocketData: 0405040047003e +31ms
  hci   event type = 4 +0ms
  hci   sub event type = 5 +0ms
  hci           handle = 71 +0ms
  hci           reason = 62 +0ms
  hci flush - pending: 0 queue length: 0 +1ms
  simble:event Peripheral 00:1a:22:13:6f:77 : Event "disconnected" +44ms
  hci onSocketData: 0119040af8c4eff90ff802000000 +16s
  hci   event type = 1 +0ms
  hci           cmd = 1049 +0ms
  hci           data len = 10 +0ms
  hci onSocketData: 040f0400011904 +14ms
  hci   event type = 4 +0ms
  hci   sub event type = 15 +0ms
  hci           status = 0 +0ms
  hci           cmd = 1049 +0ms
Error: Promise did not resolve within 30000 milliseconds
  hci set scan enabled - writing: 010c20020001 +12s

[Joachim S. (oyo)]

Rop09 schrieb:
> Wie man unten sieht gibts im Fehlerfall immer einen Disconnected event
> (nach einem Connect), nachdem rein gar nichts mehr passiert und die SW
> in den Timeout läuft, egal wie lange ich ihn stelle.
>
> Wenn es funzt dann meistens sehr schnell nach <5 Sekunden.  Die
> Entfernung vom BLE 4.0 USB Stick (extern, nicht der interne vom RPi4)
> beträgt etwa 7m + ein Wandstück bzw Glastür mit Wandanteil.
> Würde ein BLE 5.0 Stick hier verbesserung bringen?
> Ist so ein verhalten bekannt?

Ich kann in dem Debug-Log auf Anhieb leider keine Hinweise finden, was 
der konkrete Grund für den Disconnect sein könnte, mir ist das bislang 
auch nicht als häufig auftretendes Problem bekannt. Ich kann Dir daher 
aktuell leider nicht wirklich helfen, sondern nur zwei Sachen sagen, die 
Du mal probieren könntest um mögliche Problemquellen auszuschliessen:

Die interne BLE-Hardware des RPi scheint häufig merkwürdige Probleme zu 
verursachen, aber da Du ja einen externen Stick nimmst, sollte es daran 
ja eigentlich nicht liegen - es sei denn, die Software würde statt des 
externen Sticks in Wahrheit die interne BLE-Hardware verwenden. Du 
könntest also zum einen mal überprüfen, ob auch ganz sicher der externe 
Stick verwendet wird, z.B. weil beim Verbindungsaufbau irgendeine 
Aktivitäts-LED am externen BLE-Stick aufleuchtet oder so.

Ansonsten würde ich den Türschlossantrieb testweise mal vom Schloss 
abmontieren und in unmittelbarer Nähe des RPi platzierst, um eine 
schlechte Funkverbindung als Problemquellen ausschliessen zu können.

[Rop09 (Gast)]

Danke für die Antwort!
Am internen RPi BT kanns eigentlich nicht liegen, dass ist aufgrund 
einer falschen Config nicht aktiv (hciconfig zeigt auch nur ein Device 
hci0 an, was der externe Stick ist).

Ich werds mal mit näher rangehen versuchen, hab jetzt mal als Workaround 
erstmal einen sehr kurzem 10sec Timeout eingestellt und lasse dann beim 
Fehlschlag sofort wiederholen, das geht einigermassen, kann aber auch 
mal 10 Versuche brauchen bis die Verbindung steht.

[Rop09 (Gast)]

War leider nicht erfolgreich, auch mit extra bestelltem neuem BLE5 Stick 
und dem Schloss 1m daneben genau das gleiche.
Hier nochmal ein kompletter Log vom Fehlerfall:#

hci setting filter to: 1600000020c10800000000400000 +0ms
  hci set event mask - writing: 01010c08fffffbff07f8bf3d +7ms
  hci set le event mask - writing: 010120081f00000000000000 +0ms
  hci read local version - writing: 01011000 +1ms
  hci write LE host supported - writing: 016d0c020100 +0ms
  hci read LE host supported - writing: 016c0c00 +1ms
  hci le read buffer size - writing: 01022000 +0ms
  hci read bd addr - writing: 01091000 +0ms
  hci onSocketData: 040e0402010c00 +6ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +1ms
  hci           cmd = 3073 +0ms
  hci           status = 0 +0ms
  hci           result =  +0ms
  hci onSocketData: 040e0402012000 +1ms
  hci   event type = 4 +1ms
  hci   sub event type = 14 +0ms
  hci           cmd = 8193 +0ms
  hci           status = 0 +0ms
  hci           result =  +0ms
  hci onSocketData: 040e0c020110000a7b090a5d0043ec +0ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 4097 +1ms
  hci           status = 0 +0ms
  hci           result = 0a7b090a5d0043ec +0ms
  hci set scan enabled - writing: 010c20020001 +0ms
  hci set scan parameters - writing: 010b200701100010000000 +1ms
  hci onSocketData: 040e04026d0c00 +0ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 3181 +1ms
  hci           status = 0 +0ms
  hci           result =  +0ms
  hci onSocketData: 040e06026c0c000100 +0ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 3180 +0ms
  hci           status = 0 +0ms
  hci           result = 0100 +0ms
  hci                   le = 1 +1ms
  hci                   simul = 0 +0ms
  hci onSocketData: 040e07020220001b0008 +1ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 8194 +0ms
  hci           status = 0 +0ms
  hci           result = 1b0008 +0ms
  hci le buffer size: length = 27, num = 8 +0ms
  hci onSocketData: 040e0a02091000fbafacbb0144 +3ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 4105 +0ms
  hci           status = 0 +0ms
  hci           result = fbafacbb0144 +0ms
  hci address = 44:01:bb:ac:af:fb +1ms
  noble addressChange 44:01:bb:ac:af:fb +0ms
  hci onSocketData: 040e04020c2000 +2ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 8204 +0ms
  hci           status = 0 +0ms
  hci           result =  +0ms
  hci onSocketData: 040e04020b2000 +2ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 8203 +0ms
  hci           status = 0 +0ms
  hci           result =  +0ms
  noble stateChange poweredOn +5ms
  noble scanParametersSet +1ms
  simble:info Starting to scan for peripheral... +0ms
  hci set scan enabled - writing: 010c20020001 +3ms
  hci set scan parameters - writing: 010b200701100010000000 +0ms
  hci set scan enabled - writing: 010c20020101 +0ms
  hci onSocketData: 040e04020c2000 +2ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 8204 +0ms
  hci           status = 0 +0ms
  hci           result =  +0ms
  noble scanStart +4ms
  hci onSocketData: 040e04020b2000 +3ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 8203 +0ms
  hci           status = 0 +0ms
  hci           result =  +0ms
  noble scanParametersSet +2ms
  hci onSocketData: 040e04020c2000 +2ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +0ms
  hci           cmd = 8204 +0ms
  hci           status = 0 +0ms
  hci           result =  +0ms
  hci onSocketData: 043e1d02010400776f13221a001108094b45592d424c4507ff001a22136f77bb +8s
  hci   event type = 4 +0ms
  hci   sub event type = 62 +1ms
  hci           LE meta event type = 2 +0ms
  hci           LE meta event status = 1 +0ms
  hci           LE meta event data = 0400776f13221a001108094b45592d424c4507ff001a22136f77bb +1ms
  hci                   type = 4 +1ms
  hci                   address = 00:1a:22:13:6f:77 +0ms
  hci                   address type = public +1ms
  hci                   eir = 08094b45592d424c4507ff001a22136f77 +0ms
  hci                   rssi = -69 +1ms
  gap advertisement = {"localName":"KEY-BLE","manufacturerData":{"type":"Buffer","data":[0,26,34,19,111,119]},"serviceData":[],"serviceUuids":[],"solicitationServiceUuids":[]} +0ms
  simble:info   Scanned peripheral 00:1a:22:13:6f:77 (Name:"KEY-BLE", advertised services:[]) +8s
  simble:info Peripheral 00:1a:22:13:6f:77 matches filters, stopping scanning +1ms
  hci set scan enabled - writing: 010c20020001 +10ms
  simble:info Connecting to peripheral 00:1a:22:13:6f:77... +3ms
  hci create le conn - writing: 010d2019600030000000776f13221a000006000c000000c80004000600 +6ms
  hci onSocketData: 040e04020c2000 +1ms
  hci   event type = 4 +0ms
  hci   sub event type = 14 +1ms
  hci           cmd = 8204 +0ms
  hci           status = 0 +1ms
  hci           result =  +0ms
  noble scanStop +8s
  hci onSocketData: 040f0400020d20 +1ms
  hci   event type = 4 +1ms
  hci   sub event type = 15 +0ms
  hci           status = 0 +0ms
  hci           cmd = 8205 +1ms
  hci onSocketData: 043e13010010000000776f13221a000c000000c80000 +1s
  hci   event type = 4 +0ms
  hci   sub event type = 62 +1ms
  hci           LE meta event type = 1 +0ms
  hci           LE meta event status = 0 +0ms
  hci           LE meta event data = 10000000776f13221a000c000000c80000 +0ms
  hci                   handle = 16 +1ms
  hci                   role = 0 +0ms
  hci                   address type = public +0ms
  hci                   address = 00:1a:22:13:6f:77 +0ms
  hci                   interval = 15 +0ms
  hci                   latency = 0 +0ms
  hci                   supervision timeout = 2000 +0ms
  hci                   master clock accuracy = 0 +0ms
  att 00:1a:22:13:6f:77: write: 020001 +0ms
  hci push to acl queue: 021000070003000400020001 +4ms
  hci flush - pending: 0 queue length: 1 +1ms
  hci write acl data packet - writing: 021000070003000400020001 +0ms
  simble:event Peripheral 00:1a:22:13:6f:77 : Event "connected" +0ms
  simble:info Connected to peripheral 00:1a:22:13:6f:77 +1s
  simble:info Discovering peripheral 00:1a:22:13:6f:77... +1ms
  hci onSocketData: 011620021000 +3ms
  hci   event type = 1 +0ms
  hci           cmd = 8214 +1ms
  hci           data len = 2 +0ms
  hci onSocketData: 040f0400021620 +0ms
  hci   event type = 4 +0ms
  hci   sub event type = 15 +0ms
  hci           status = 0 +0ms
  hci           cmd = 8214 +0ms
  hci onSocketData: 0405040010003e +1ms
  hci   event type = 4 +0ms
  hci   sub event type = 5 +0ms
  hci           handle = 16 +0ms
  hci           reason = 62 +0ms
  hci flush - pending: 0 queue length: 0 +0ms
  simble:event Peripheral 00:1a:22:13:6f:77 : Event "disconnected" +6ms
Error: Promise did not resolve within 35000 milliseconds
  hci set scan enabled - writing: 010c20020001 +26s

[Hendrik (Gast)]

Du könntest Mal die esp32 Variante ausprobieren.

[Rop09 (Gast)]

Hendrik schrieb:
> Du könntest Mal die esp32 Variante ausprobieren.

hab ich mir jetzt auch mal installiert (leicht abgeändert), funktioniert 
aber leider nicht viel besser.

Im Gegenteil, der ESP hängt sich auch oft einfach auf wenn er versucht 
die Verbindung aufzubauen (im eQ3 Teil).

[Joachim S. (oyo)]

Rop09 schrieb:
> War leider nicht erfolgreich, auch mit extra bestelltem neuem BLE5 Stick
> und dem Schloss 1m daneben genau das gleiche.

Tut mir leid Rop09, damit bin ich jetzt gerade mit meinem Latein 
ziemlich am Ende.
Wobei mich irgendwie verwirrt, dass die ESP32-Version ähnliche Probleme 
zu haben scheint, und auch ungefähr an der gleichen Stelle. Denn ich 
hätte jetzt tendenziell getippt, dass das Problem "unterhalb" von keyble 
steckt, in der für die Bluetooth-Kommunikation zuständigen 
"noble"-Library. Dass die ESP32-Version, die diese Library nicht nutzt, 
ähnliche Probleme an der gleichen Stelle hat, spricht da eher dagegen...

Die letzte Sache, die mir aktuell noch einfällt, bei der ich es aber 
trotzdem für ziemlich unwahrscheinlich halte, dass es etwas an dem 
Problem ändert:
Du könntest testweise mal versuchen, die neue keyble-Codebasis 0.3 zu 
verwenden, weil da ein bisschen was verändert wurde und eine neuere 
Version der "noble"-Library verwendet wird.
Ist allerdings mehr so im Alpha/Beta-Stadium, noch nicht richtig 
dokumentiert, bislang nur per MQTT zu nutzen usw.:

https://github.com/oyooyo/keyble-mqtt

[Rop09 (Gast)]

Danke, ist dann der nächste Versuch!

Wobei ich beim ESP32 noch nicht ganz sicher bin obs wirklich so schlecht 
ist. Hatte heute mal die Situation dass ganz hervorragend gut 
funktioniert hat, quasi nur 1-2 Sekunden gedauert hat bis das Lock 
reagiert hat und zwar jedesmal!

Nachdem ich dann den ESP wegen ner kleinen Änderung neu geflasht hatte 
wars wieder dann nicht mehr so toll. Gefühlt ist es oft so dass die 
allererste Connection länger dauert, und es danach schnell geht (obwohl 
ja der ESP die BT Connection immer wieder trennt), fast so als ob das 
Schloss meint es wäre noch verbunden...

[Rop09 (Gast)]

Gerade mal probiert, aber auch nicht erfolgreich:

a) ohne Root ausgeführt:

  mqttjs:client _handlePublish: qos 0 +0ms
(node:6469) UnhandledPromiseRejectionWarning: Error: noble did not change to the "poweredOn" state within 5000 milliseconds. This usually indicates that either no Bluetooth hardware is available, or that you do not have sufficient permissions for accessing the Bluetooth hardware.
    at Timeout.setTimeout [as _onTimeout] (/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/utils.js:254:11)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10)
(node:6469) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
^C  hci set scan enabled - writing: 010c20020001 +42s
  hci onSocketError: EPERM, Operation not permitted +0ms

und daher

b) mit root, aber:

/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:544
                        receive_characteristic.off('data', on_data_received);
                        ^

ReferenceError: receive_characteristic is not defined
    at Peripheral.peripheral.once (/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:544:4)
    at Object.onceWrapper (events.js:277:13)
    at Peripheral.emit (events.js:189:13)
    at Noble.onDisconnect (/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble/lib/noble.js:245:16)
    at NobleBindings.emit (events.js:189:13)
    at NobleBindings.onDisconnComplete (/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble/lib/hci-socket/bindings.js:280:10)
    at Hci.emit (events.js:189:13)
    at Hci.onSocketData (/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble/lib/hci-socket/hci.js:557:12)
    at BluetoothHciSocket.emit (events.js:189:13)

[Rop09 (Gast)]

Mal noch was anderes - ich hab den ESP32 jetzt soweit modifiziert dass 
er recht zuverlässig läuft, und gebe mir zusätzlich noch die RAW Daten 
über MWQTT aus wenn ich den Status abfrage, z.B.:

72 01 0A 00 10 17 00 00

Irgendwo hatte ich gelesen dass da auch die Info über den Batteriestatus 
drin steckt, kanns aber nicht mehr finden welches Bit das war, weiss das 
jemand?

[Hendrik (Gast)]

Hallo,

Was hast du denn modifiziert?

Magst du nen Pull Request erstellen, damit die Entwicklung weiter geht?

Gruß,
Hendrik

[Rop09 (Gast)]

Hallo,

ich habs mal gezipped und auf git hochgeladen (bin leider nicht mit der 
Vorgehensweise da vertraut ;)

Was ich geändert habe:

- Wifi reconnect abfolge geändert, ESP reset wenn länger fehl schlägt, 
andere Interfaces verwendet
- MQTT reconnect geändert, weil ich dort den Verdacht habe dass er da 
den Stack zumüllt wenn der Reconnect nicht geht (bei mir wird Nachts 
immer das WLAN unterbrochen für einige Zeit, denk das ist der Zeitpunkt 
wo er sich aufgehängt hat deswegen).
- Scanning parameter geändert, hier bin ich aber noch am probieren
- eQ3 lib, Mutex timeout auf 10s (nicht sicher ob das was bringt, aber 
vorher wars so dass sich der ESP öfter mal im BLE Teil verannt hatte
- Status command über MQTT zur Schlossstatus Abfrage
- Timeout handling falls Schloss nicht antwortet (mit timeout error 
Rückgabe über MQTT)
- RAW data ausgabe über MQTT
Denke das wars soweit, war ziemlich viel Trial&Error anfangs weil der 
ESP sich über nacht immer aufgehängt hatte, macht er damit jedenfalls 
nicht mehr.

Was noch fehtl ist die Batteriezustandsausgabe über MQTT und die 
Scanning parameter setting über MQTT umd da etwas zu experimentieren.

Ist alles nicht sehr schön gemacht, nur funktional ;)

Der ganze Vorgang (MQTT kommando empfange -> BLE connection, Kommando 
ausführen und wieder WLAN verbinden und Status senden) zwischen 7 und 25 
Sekunden, sehr unterschiedlich lange.

Vereinzelt gibts auch noch BLE timeouts (35sec), das liegt denk ich an 
der Platzierung, wobei er andererseits auch durch 3 Wände hindurch mit 
10m Abstand zum Schloss funktioniert...

[Hendrik Friedel (Gast)]

Hallo,

zippen und Hochladen ist nicht gut...
Die Idee hinter git ist ja, dass die Änderungen nachvollziehbar sind. 
Daher ist es auch am Besten für jede Verbesserung einen Commit 
("Upload") zu machen.

Wenn du dich mit git schwer tust, dann nutz einfach das Web-Interface 
auf github: Du kannst jede Datei "editieren". Es öffnet sich ein Editor 
im Browser. Nachdem du mit einem Problem, welches du behoben hast fertig 
bist (das kann durchaus mehrere Dateien beinhalten, die du ändern 
musst), dann machst du einen Pull-Request. Damit bittest du den 
ursprünglichen Autor deine Änderungen zu prüfen und bei sich zu 
übernehmen.

Ich hoffe, das ist einigermaßen verständlich. Es wäre echt super, wenn 
du dich da reinarbeitest.
Vielleicht mag @tcsmaxx deine Änderungen ja auch manuell aus der Zip 
übernehmen (hast du mal einen Link?).

Gruß,
Hendrik

[Hendrik Friedel (Gast)]

Hallo,

wo hast du die Zip denn hochgeladen?
Ich wollt mir das gerade mal ansehen.

Gruß,
Hendrik

[Max M. (tcsmaxx)]

Hi@all,

ich habe die Änderungen ungetestet bei mir im Repository committed.

https://github.com/tc-maxx/esp32-keyble

[Hendrik Friedel (Gast)]

Hallo,

vielen Dank.
Für die Zukunft wäre es allerdings wünschenswert, wenn alle mit git 
arbeiten und Änderungen in kleinen Happen kommitten, so dass man sehen 
kann, was miteinander zusammenhängt und welchen Zweck hat.

Gruß,
Hendrik

[Adrian K. (adriankan)]

Hallo tcsmaxx,

sehr interesannte Ansatz.
Das habe ich gleich ausprobiert mit wemos mini32, leider ohne Erfolg.
Woran merke ich es ob der ESP mit der EQ3 verbunden ist?
Des weiteren weiss nicht was man hie richtige einträgt:
#define ADDRESS "xxx"
#define USER_KEY "xxxx"
#define USER_ID 2
#define CARD_KEY "M001A2213XXXXXXXXXXXXX"
Eine Erklärung im Netz habe ich leider nicht gefunden.
Aus dem IObroker / npn Forum ein paar Ansetze, aber??

LG

[Al O. (cyber83)]

Da gehören user, mac und key, den du mit keyble beim registrieren mit 
dem schloss aushandelst, hinein.

[Max M. (tcsmaxx)]

@adriankan,
hier ist dazu alles erklärt: https://github.com/oyooyo/keyble

[Adrian K. (adriankan)]

danke,
 habe die Anleitung verfolgt.
auch NPN und das System geupdatet.
aber, nach dem :
keyble-registeruser -n ABC-q XXXXXXXXXX
bekomme ich nur die Infos:
Registering user on Smart Lock with address "00:1a:YX:13:XX:a9", card 
key "1576b7256401XXXXXXXXXfc97a36" and serial "QEQ0XXX2"...

und weiter nichts
da fehlt noch:
User registered. Use arguments: --address 01:XX:XX:67:89:ab --user_id 1 
--user_key ca78aXXXXX31414359e5e7cecfd7f9e
Setting user name to "ABC"..

wie kann das Problem lösen.
aktuell habe ich Node.js v12.22.1  // bei 14 ging da gar nicht

was fehlt da noch?

[Joachim S. (oyo)]

Adrian K. schrieb:
> danke,
>  habe die Anleitung verfolgt.
> auch NPN und das System geupdatet.
> aber, nach dem :
> keyble-registeruser -n ABC-q XXXXXXXXXX
> bekomme ich nur die Infos:
> Registering user on Smart Lock with address "00:1a:YX:13:XX:a9", card
> key "1576b7256401XXXXXXXXXfc97a36" and serial "QEQ0XXX2"...
>
> und weiter nichts
> da fehlt noch:
> User registered. Use arguments: --address 01:XX:XX:67:89:ab --user_id 1
> --user_key ca78aXXXXX31414359e5e7cecfd7f9e
> Setting user name to "ABC"..

Schalte mal die Debug-Ausgabe ein, indem Du vor den 
"keyble-registeruser"-Befehl noch ein "DEBUG=* " davorsetzt. keyble 
liefert leider so gut wie keine Fehlermeldungen, wenn etwas nicht wie 
erwartet funktioniert.

[Adrian K. (adriankan)]

Hallo,

habe jetzt den Fehler, glaube ich, gefunden.

Der EQ3 soll sich weniger als 0,5m entfernt vom Raspi befinden.

Danke noch mal für Untestüzung.

[John L. (johnli)]

Ist eine Video-Demo verfügbar?

[Thomas (type0n)]

Hi,

ich habe mal mit der ESP32 Umsetzung von tscmaxx/Rop09 rumgespielt.

Hier findet Ihr was dabei herausgekommen ist:

https://github.com/lumokitho/esp32-keyble

- AP Mode zum Konfigurieren der WLAN Verbindung (AutoConnect)
- Webinterface zum hinterlegen der MQTT Zugangsdaten und der 
Schlossparamter
- RSSI Signalstärke des Schlossantriebs
- Battery Status
- Toggle Funktion
- Weitere MQTT Endpunkte (Batterie/Zustand/Signalstärke)
- Boot Button des ESP32 toggelt das Schloss
- Partitionsatabelle angepasst
- OTA Update via BIN upload
- Hardkodierte Zugangsdaten entfernt
- Einheitliche Ausgaben über Serial

Eine Anleitung findet Ihr bei GIT. Gucked mal drüber, ob man damit etwas 
anfangen kann.

Schönen Abend!

[Hendrik (Gast)]

Wow Danke!

Ich hatte Mal versucht, zwei Schlösser zu unterstützen. Dabei bin ich 
gescheitert - hab ich weiter oben etwas zu geschrieben.
Du scheinst dich gut auszukennen :-)
Hast du eine Idee?

Ich werde deine Variante Mal probieren.

Gruß,
Hendrik

[Thomas (type0n)]

Hi Hendrik,

ich denke, dass es möglich ist mehrere Schlösser nacheinander 
anzusprechen.
Dazu müssten halt die Daten für die weiterern Schlössern hinterlegt 
werden und entsprechend weitere Topics.  Fraglich ist hierbei die 
Koordination von aussen und aus meiner Sicht auch die Reichweite des 
ESP. Bei einer Investition von rund 5€ für den ESP, weiter 5€ für ein 
Netzteil und einem USB Kabel/Adapter, kommt man so auf rund 10€ für eine 
BLEtoWiFi Bridge pro Schlossantrieb. Bestellt man in China ist man mit 
nur 5€ dabei.
Falls hier tatsächlich Bedarf besteht guck mir das mal an.

Ich warte mal auf euer feedback.

Was mir definitiv noch fehlt ist, das Registieren eines Benutzers, damit 
die Bridge völlig eigenständig arbeiten kann. Das hat bei mir momentan 
höhere Priorität.

Schönen Gruß
Thomas

[Joachim S. (oyo)]

Thomas F. schrieb:
> - AP Mode zum Konfigurieren der WLAN Verbindung (AutoConnect)
> - Webinterface zum hinterlegen der MQTT Zugangsdaten und der
> Schlossparamter
> - RSSI Signalstärke des Schlossantriebs
> - Battery Status
> - Toggle Funktion
> - Weitere MQTT Endpunkte (Batterie/Zustand/Signalstärke)
> - Boot Button des ESP32 toggelt das Schloss
> - Partitionsatabelle angepasst
> - OTA Update via BIN upload
> - Hardkodierte Zugangsdaten entfernt
> - Einheitliche Ausgaben über Serial

Hut ab - was Du da an Features auflistest, das klingt verdammt 
vielversprechend!

Mir ist gerade aufgefallen, dass ich die diversen ESP32-Ports in der 
keyble-Dokumentation bislang gar nicht erwähnt habe. Wenn ich das 
nächste Mal was committe, werde ich da mal einen entsprechenden 
Abschnitt einfügen und dann vermutlich ganz besonders Deinen Fork 
empfehlen, weil der auf den ersten Blick am ausgereiftesten und 
einsteigerfreundlichsten klingt.

Einen grossen Teil der Vorarbeit haben ja andere geleistet, die daher 
ebenfalls erwähnt werden sollten. Da ich mich mit den ESP32-Ports 
bislang nicht selbst wirklich befasst habe, fehlt mir gerade so ein 
bisschen der Überblick, wer da alles beteiligt war: gibt es ausser
MariusSchiffer, tcs-maxx und lumokitho noch jemanden, der nennenswert 
zur Entwicklung der ESP32-Version beigetragen hat und daher erwähnt 
werden sollte?

[Thomas (type0n)]

Hallo Joachim,

der Stand mit dem ich gestartet bin war der von RoP09 welcher, als Zip 
von tc-maxx in seinen Fork hochgeladen wurde. Somit ist RoP09 als Quelle 
zu nennen. Er hat zwar nun wohl eine GIT account, aber der ist leider 
leer.

Ich hatte mich schon vor Deinem Ansatz mit den Antrieben beschäftigt 
(ganz weit oben in Thread) mittels Tasker auf einem Android Telefon. 
Dann ruhte das eine Weile und ich habe mich mit Deiner letzten Umsetzung 
vor dem Umbau beschäftigt. Diese habe ich auf meine Bedürfnisse 
angepasst (mehrer Schlösser gleichzetig über mehrere BLE USB Sticks, zur 
Zeit 5) und auf einem Pi Zero laufen. Dazu musste ich auch an simble 
einige wenige Änderungen durchführen. Mittlerweile recht stabil. Sobald 
ich das mal "aufgeräumt" habe lade ich auch diese Version mal bei GIT 
hoch.

Angefixt wurde ich durch tc-maxx, als dieser eine recht stabile ESP32 
Version herausgebracht hat. Ich finde den Ansatz mit einer Bridge pro 
Schloss doch schon sehr charmant. Da wird die Lücke zum viel teureren 
NUKI schon etwas kleiner. Hauptsächlich deshalb, weil alles lokal läuft.

Nochmal großen Dank an alle, die so gute Vorarbeit geleistet haben!

Gruß
Thomas

[Hendrik (Gast)]

Hallo,

das mit den mehreren Locks hat keine Priorität. Natürlich sind die ESP 
preiswert. Aber ich habe das Problem, sie unterzubringen. Da mein 
Raspi-Zero es geschafft hat, zwei Locks zu bedienen (Reichweite OK will 
ich damit sagen), hatte ich die Hoffnung auch nur einen ESP unterbringen 
zu müssen - und da hätte ich in einer Taster-Dose / UP Dose Platz für 
einen ESP32. Zur Not könnte man zwei nackte ESP32 (d.h. nicht auf so 
einem Dev-Board) unterkriegen. Aber da weiß ich nicht, wie ich sie 
flashe. Da müsste ich mich mal erkundigen.

Ich müsste auch erstmal prüfen, ob der Empfang in der UP Dose noch 
ausreichend ist.

Ich habe gerade mal deine Firmware geflasht. Sie hat mich dann auch 
gleich mit ihrem Web-Interface begrüßt (ich hatte leider vergessen den 
Flash zu löschen, daher waren die Credentials noch da).
Nach dem Konfigurieren der MQTT und Schloss-Einstellungen war aber dann 
Schicht:
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
[E][Preferences.cpp:49] begin(): nvs_open failed: NOT_FOUND
[E][WiFiSTA.cpp:221] begin(): connect failed!

Woran kann das liegen?

Gruß,
Hendrik

[Hendrik (Gast)]

vielleicht dies?
https://github.com/espressif/arduino-esp32/issues/3421#issuecomment-650845237

[Thomas (type0n)]

Hallo Hendrik,

versuch mal bitte den Flash zu löschen. Dein ESP wird eine andere 
Partitionierung haben. Durch die Erweiterungen die ich eingebaut haben 
war es nötig, die Partitionierung zu ändern. Also Flash vollständig 
löschen, dann sollte das klappen.

Schönen Gruß
Thomas

[Al O. (cyber83)]

Hallo Thomas,

gibts auch die Möglichkeit per json HTTP stati abzufragen?
Ich wollte gerade auf github dazu eine frage aufmachen, aber ich denke 
das hast bei deinem projekt leider nicht aktiv?

So wie ich es im code sehe wird wifi disconnected beim connecten zum 
schloss - gibts dafür keine Alternative? :-/

LG Alois

[Hendrik Friedel (Gast)]

Hallo,

ich habe es jetzt soweit geschafft das Gerät zu konfigurieren. Es ist im 
WLAN und spricht mit dem MQTT Broker.
Ein Verbesserungsvorschlag: Den Port hatte ich unter MQTT freigelassen, 
annehmend, dass dann der Default genommen wird. Das hat zu einer 
Endlosschleife (connection refused) geführt und ich musste neu flashen, 
da das Webinterface nicht erreichbar war.

Das Schloss habe ich aber noch nicht schalten können:
SmartlockHintertuer/task working
SmartlockHintertuer/state timeout
SmartlockHintertuer/task waiting
SmartlockHintertuer/rssi 107
SmartlockSchuppen/action lock
SmartlockHintertuer/task lock
SmartlockHintertuer/task unlock
SmartlockHintertuer/task 0
SmartlockHintertuer/task 1
SmartlockHintertuer/task close
SmartlockHintertuer/task 3
SmartlockHintertuer/task 3
SmartlockHintertuer/task 3
SmartlockHintertuer/task 2


Wie du siehst, wusste ich zunächst nicht, welche Payloads ich senden 
musste. Das habe ich dann hoffentlich dem Sourcecode richtig entnommen.

Das Schloss hat sich aber nicht bewegt.

Der Rssi vom Lock wird ja angezeigt. Was können wir daraus schließen? 
Nur dass eine Verbindung besteht, oder auch dass die Credentials ok 
sind?
Ich bin eigentlich recht sicher, dass die Stimmen, da ich sie auf dem 
Raspi so verwendet habe...

Gruß,
Hendrik

[Thomas (type0n)]

Hallo Alois,

eine Kommunikation über http ist nicht vorgesehen, alles wird über MQTT 
gesteuert. Via Arduino ist mir keine Möglichkeit bekannt WiFi und BLE 
gleichzeitig stabil zu betreiben. Hier müsste man auf Espressif-IDF 
portieren, da bin ich aber nicht im Thema. Daher der Wechsel von WiFi zu 
BLE und zurück. Daran habe ich nichts verändert, das ist so geblieben 
wie bei RoP09.

Schönen Gruß
Thomas

[Thomas (type0n)]

Hallo Hendrik,
kurz zum Port. Ich halte nichts von default Ports, jede Netzwerkumgebung 
ist anders, daher ist die Porteingabe nötig. Mal gucken, ob ich das als 
Pflichfeld behandeln kann.

Num zum ansprechen der Bridge.

das Bridge published auf:
- "DeinTopic"/battery
- "DeinTopic"/rssi
- "DeinTopic"/status
- "DeinTopic"/task

Die Bridge subscribed auf:
- "DeinTopic"/command

Du musst also mit einem MQTT Client der mit deinem Broker (identisch mit 
dem in der Bridge hinterlegten) vebunden ist auf:

"DeinTopic"/command/X publishen

Zur Zeit gehen folgende Werte
- 1 zur Statusabfrage
- 2 zum Aufschließen
- 3 zum Abschließen
- 4 zum Öffnen (Aufschließen und Falle wird gezogen)
- 5 zum Umschalten (bei abgeschlossen auf und bei aufgeschlossen zu)

Willst Du also aufschließen sendest Du:
"DeinTopic"/command/1

Guck mal im GIT Readme, da ist das erklärt.

Falls Dein ESP einen Boot Button hat, kannst Du damit testen, ob eine 
Verbindung besteht, weil dadurch umgeschaltet wird.

Der RSSI deutet darauf hin, wie gut die BLE Verbindung ist. Bei 107 ist 
das Schloss entweder sehr weit entfernt, es gibt Störquellen in der Nähe 
(z.B. WiFI/Bluetooth/BLE/ZigBee/Z-Wave/MiWi/Loxone Air etc. alles im 
2,4GHz Band), oder Hindernisse (Gipskarton/Metall/Beton/Naturstein ect.) 
zwischen Bridge und Lock. Aus meiner Erfahrung ist alles was Wasser 
speichern kann tödliche für Funkverbindungen! Eine 20cm Bentonwand 
funktioniert besser als eine einzige Lage Gipskarton.

Schönen Gruß
Thomas

[Hendrik (Gast)]

Hallo,

danke, ich habe jetzt schalten können!
Ich habe das in der Readme übersehen, sorry.
Zwischendurch hatte ich nochmal das Problem, dass er die WLAN 
Credentials wieder vergessen hat... Keine Ahnung woran das nun lag.

Gruß,
Hendrik

[Hendrik (Gast)]

Hallo,

ich hatte den ESP jetzt einen Tag nicht angeschlossen. Jetzt hab ich ihn 
heute wieder eingesteckt und er meldet sich nicht über mqtt.
Also den seriellen Monitor dran:

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded

[E][WiFiSTA.cpp:221] begin(): connect failed!

Empfang ist (hier, wo ich jetzt den seriellen Monitor hab) aber top. Es 
kann durchaus sein, dass der Empfang am Einbauort nicht gut war.
Vergisst er dann die Credentials wieder?

Ich hab mich dann mit dem AP verbunden:
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[E][WebServer.cpp:633] _handleRequest(): request handler not found
# WIFI: connected to SSiD: XNetz
# WIFI: connected!
# WIFI: signalquality: 78%
# WiFi connected to IP: 192.168.177.27
# Connect to MQTT-Broker...
# Connected!
# published SmartlockHintertuer/task/working
# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...

Die Lock und MQTT-Settings hatte er noch.

Gruß,
Hendrik

[Thomas (type0n)]

Hi Hendrik,

ich gehe mal von mehreren Punkten aus, die hier zusammenkommen.

Ist die Spannungsversorgung vom ESP stabil und ausreichend? Wenn der ESP 
mit einem "schlechten" Netzteil verbunden ist, kommt es zu 
unvorhersehbarem Verhalten. Ich habe beim testen ähnliches Verhalten 
festgestellt, bei mir lag es an zu wenig Saft für den ESP. Also aktiven 
Hub benutzen.

Wie weit ist das Schloss entfernt?

Was kommt beim Broker an?

Bist Du 1:1 der Anleitung bei GIT gefolgt?
Zur Zeit gibt es so gut wie kein Errorhandling.

Wie sieht deine Netzwerkstruktur aus?
Ein Router, mehrere Router, APs etc.

Laut dem Seriallog, gehe ich von falschen Zugangsdaten aus. Tückisch 
sind hier die Passwortfelder, hier muss jedes mal das Kennwort 
eingetragen werden. Wie geschrieben, noch keine Fehlerbehandlung im 
Programm.

Ich schlage mal vor, das Du wie folgt vorgehst:

ESP vollständig löschen.
Browsercache leeren, alternativ über Inkognito/Privaten Modus verbinden.

KeyBLEBridge Netzwerk löschen, ich gehe mal davon aus, dass Du mit 
Windows unterwegs bist?

Erneut flashen. Nutzt Du Platformio?

Den ESP dort in Betrieb nehmen, wo er auch später eingesetzt werden 
soll. Falls das Verhalten mit z.B. mehreren Netzen mit gleichem Namen 
zusammenhängt.

Im Bestfall alles mit Seriallog.

Zum AP verbinden.
Zugang zum eigenen Netz eintragen, mit fester IP, also DHCP aus!
Netzmaske und DNS nicht vergessen, DNS1 sollte Dein Router sein, als 
DNS2 kannst Du z.B. google nehmen 8.8.8.8

Vorab checken, ob die IP tatsächlich frei ist, nicht das sich 2 Geräte 
die IP teilen.

Reboot ESP.

Verbindung über die von Dir gewählte IP herstellen.

KeyBLE und MQTT Daten eintragen, speichern und dann Reset ausführen.

Prüfen, ob weiterhin ein AP aufgespannt wird, bzw. ob der ESP mit dem 
Netz verbunden ist.

Am Broker prüfen, ob und wann die letzten Nachrichten eingegangen sind.

Über den Boot Button einen toggle ausführen.

Ping mal das Modul dauerhaft an, um zu sehen, ob es zu Netzabbrüchen 
kommt, bzw. ob überhaupt eine Antwort kommt.

Was Für ein ESP Modul benutzt Du eigentlich?

Ich denke, dass sind schon mal viele Punkte die Du bitte prüfen kannst.

Schönen Gruß
Thomas

[Hendrik (Gast)]

Hallo Thomas,

danke für deine ausführliche Antwort.

> Ist die Spannungsversorgung vom ESP stabil und ausreichend?
Am PC hatte ich das Problem bisher nicht. Das Netzteil schafft 2A. Das 
sollte ja reichen.

> Wie weit ist das Schloss entfernt?
Ca. 2-3m, aber auch ein wenig Beton dazwischen.

> Was kommt beim Broker an?
Wenn das Problem besteht: Gar nix. Aber ansonsten:
SmartlockHintertuer/command 2
SmartlockHintertuer/command 3
SmartlockHintertuer/command 4
SmartlockHintertuer/task working
SmartlockHintertuer/state unknown
SmartlockHintertuer/task waiting
SmartlockHintertuer/battery true
SmartlockHintertuer/rssi -82
SmartlockHintertuer/command 3
SmartlockHintertuer/task working
SmartlockHintertuer/state locked
SmartlockHintertuer/task waiting
SmartlockHintertuer/battery true
SmartlockHintertuer/rssi -77
SmartlockHintertuer/command 2
SmartlockHintertuer/task working
SmartlockHintertuer/state unknown
SmartlockHintertuer/task waiting
SmartlockHintertuer/battery true
SmartlockHintertuer/rssi -72
SmartlockHintertuer/task working
SmartlockHintertuer/state timeout
SmartlockHintertuer/task waiting
SmartlockHintertuer/rssi 0
SmartlockHintertuer/task working
SmartlockHintertuer/state unknown
SmartlockHintertuer/task waiting
SmartlockHintertuer/battery true
SmartlockHintertuer/rssi -79
SmartlockHintertuer/command 3
SmartlockHintertuer/task working
SmartlockHintertuer/command 3
SmartlockHintertuer/command 3
SmartlockHintertuer/command 3


> Bist Du 1:1 der Anleitung bei GIT gefolgt?
Gerade nochmal gecheckt. Ja. Ich habe mal mit und mal ohne DHCP 
probiert.


> Wie sieht deine Netzwerkstruktur aus?
Mehrere APs (Unifi) und ein Router (FritzBox).

> Laut dem Seriallog, gehe ich von falschen Zugangsdaten aus. Tückisch
> sind hier die Passwortfelder, hier muss jedes mal das Kennwort

Das kann sein, aber dann liegt es nicht in meiner Verantwortung: Es hat 
alles funktioniert. Dann habe ich den ESP eine Nacht nicht verwendet und 
dann funktioniert es nicht mehr.
Ich könnte mir höchstens vorstellen, dass die Daten kurrumpiert wurden.
Ein print der keyble.json nach dem Start wäre gut.


> KeyBLEBridge Netzwerk löschen, ich gehe mal davon aus, dass Du mit
> Windows unterwegs bist?

Den AP hab ich immer in Android konfiguriert. Und da ist übrigens das 
Wlan Passwort im Autocomplete. Einen Tippfehler kann ich auch deshalb 
ausschließen.

> Erneut flashen. Nutzt Du Platformio?
Ja.

> Den ESP dort in Betrieb nehmen, wo er auch später eingesetzt werden
> soll. Falls das Verhalten mit z.B. mehreren Netzen mit gleichem Namen

Das kann ich machen. Das waren tatsächlich unterschiedliche APs.

Im Bestfall alles mit Seriallog.

> DNS2 kannst Du z.B. google nehmen 8.8.8.8

Genau den hatte ich tatsächlich genommen.

> Vorab checken, ob die IP tatsächlich frei ist, nicht das sich 2 Geräte
> die IP teilen.

Die FritzBox hat die .27 jetzt für den ESP reserviert.


> Was Für ein ESP Modul benutzt Du eigentlich?
NodeMCU

Gruß,
Hendrik

[Hendrik (Gast)]

Hallo,

ich hab den ESP jetzt mal an seinen Zielort gepackt --> keine Verbindung 
mehr.
Ich hab mich dann mit dem AP verbunden und bin auf SSID gegangen. Da 
wurde mir mein Netz angezeigt, allerdings mit Signalstärke N/A. Etwas 
später mit der Signalstärke 16%.
Ich hab ihn dann nochmal an den Rechner angeschlossen und bin dann an 
den Zielort gegangen:
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
# WIFI: connected to SSiD: X
# WIFI: connected!
# WIFI: signalquality: 76%
# WiFi connected to IP: 192.168.177.27
# Connect to MQTT-Broker...
# Connected!
# published SmartlockHintertuer/task/working
# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...
!!! Lockstatus -1 - timeout !!!
# Done!
# WiFi enabled
# WiFi disconnected, reconnect...

Es kann also durchaus an der Signalstärke liegen.

ABER: Ich hatte das Problem auch schon in Blickverbindung mit dem AP.
Ich habe das Gefühl, dass er nach der Situation oben die Credentials 
gerne vergisst.

Zudem: Ich sitze jetzt in Sichtweite des AP und sehe weiter:
# WiFi enabled
# WiFi disconnected, reconnect...

Gruß,
Hendrik

[Hendrik (Gast)]

So, ich habe jetzt 15 min gewartet und es tat sich nix (kein 
Re-Connect).
Dann ein Reset
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
[E][WiFiSTA.cpp:221] begin(): connect failed!


Wenn ich mich mit dem AP verbinde, sagt er "Please click on gear to 
setup WiFi"
Mein Netz findet er. 58%
Er fragt NICHT nach dem Wlan Passwort.
Er hat die anderen Einstellungen noch (IP, KeyBLE)

Komisch...

Gruß,
Hendrik

[Thomas (type0n)]

Hi Hendrik,

hier muss ich mal näher forschen, woran das was Du beschreibst liegt. 
Bis jetzt kann ich das hier nicht nachstellen.

Erneut, Passwörter müssen jedesmal neu eingegeben werden. Es gibt kein 
Errohandling und keine Prüfung der Eingaben. Es wird also zur Zeit an 
keiner Stelle nach etwas gefragt.

Im Bedarfsfall sende ich dir mal eine fertige BIN zum Upload via OTA.

Geh mal bitte in die AutoConnectDefs.h und entferne die Kommentierung 
von
#define AC_DEBUG
Das aktiviert serielles Debuging von AutoConnect.

Gleiches machst Du bitte mal in der PageBuilder.h mit #define PB_DEBUG

Das aktiviert serielles Debuging von PageBuilder.

Damit kommen über Serial Debug Infos von AutoConect und PageBuilder.
Mal gucken ob man das damit eingrenzen kann.

Schönen Gruß
Thomas

P.S. Ich danke dir für Deinen Testeinsatz! Sei aber bitte so nachsichtig 
und betrachte das, was zur Zeit da ist nicht als fertiges Produkt, 
sondern frühe Alpha. Hier spielen sehr viele Faktoren zusammen.

[Thomas (type0n)]

Hi Hendrik,
hier mal ein Beispiel log von eine vorher geeerten ESP nach Anleitung 
bei GIT und eingeschaltetem Debuging:

---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
[AC] Element<style> not registered
[AC] style<7> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] style<7> of /keyble_setting loaded
[AC] Element<MqttServerName> not registered
[AC] MqttServerName<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttServerName<4> of /keyble_setting loaded
[AC] Element<MqttPort> not registered
[AC] MqttPort<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttPort<4> of /keyble_setting loaded
[AC] Element<MqttUserName> not registered
[AC] MqttUserName<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttUserName<4> of /keyble_setting loaded
[AC] Element<MqttUserPass> not registered
[AC] MqttUserPass<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttUserPass<4> of /keyble_setting loaded
[AC] Element<MqttTopic> not registered
[AC] MqttTopic<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttTopic<4> of /keyble_setting loaded
[AC] Element<KeyBleMac> not registered
[AC] KeyBleMac<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] KeyBleMac<4> of /keyble_setting loaded
[AC] Element<KeyBleUserKey> not registered
[AC] KeyBleUserKey<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] KeyBleUserKey<4> of /keyble_setting loaded
[AC] Element<KeyBleUserId> not registered
[AC] KeyBleUserId<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] KeyBleUserId<4> of /keyble_setting loaded
[AC] Element<save> not registered
[AC] save<8> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] save<8> of /keyble_setting loaded
[AC] Element<discard> not registered
[AC] discard<8> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] discard<8> of /keyble_setting loaded
[AC] /keyble_setting on hands
[AC] Element<caption> not registered
[AC] caption<9> of /keyble_save created
[AC] *noname placed on /keyble_save
[AC] caption<9> of /keyble_save loaded
[AC] Element<parameters> not registered
[AC] parameters<9> of /keyble_save created
[AC] *noname placed on /keyble_save
[AC] parameters<9> of /keyble_save loaded
[AC] Element<clear> not registered
[AC] clear<8> of /keyble_save created
[AC] *noname placed on /keyble_save
[AC] clear<8> of /keyble_save loaded
[AC] /keyble_save on hands
[AC] Deserialize:EmptyInput
# /keyble.json failed to load
[AC] Current:
[E][Preferences.cpp:49] begin(): nvs_open failed: NOT_FOUND
[AC] Preferences begin failed to import AC_CREDT
[AC] WiFi.config(IP=0.0.0.0, Gateway=0.0.0.0, Subnetmask=0.0.0.0, DNS1=0.0.0.0, DNS2=0.0.0.0)
[E][WiFiSTA.cpp:221] begin(): connect failed!
[AC] WiFi.begin() failed
[AC] SoftAP configure 192.168.4.1, 192.168.4.1, 255.255.255.0 
[AC] SoftAP KeyBLEBridge/eqivalock Ch(1) IP:192.168.4.1 
[AC] http server started
[AC] DNS server started
[AC] s_rc placed on /_ac/update
[AC] cap placed on /_ac/update
[AC] bin placed on /_ac/update
[AC] update placed on /_ac/update
[AC] js placed on /_ac/update
[AC] bin placed on /_ac/update_act
[AC] result placed on /_ac/update_act
[AC] dvo placed on /_ac/update_act
[AC] rc placed on /_ac/update_act
[AC] dvc placed on /_ac/update_act
[AC] /_ac/update on hands
[AC] /_ac/update_act on hands
[AC] Host:,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:192.168.4.1,/_ac,generated:/_ac, allocated
[PB] HTTP_GET /_ac
[AC] Host:192.168.4.1,/_ac,already allocated
[PB] Chunked, HEAD CSS_BASE CSS_TABLE blk:1270 CSS_LUXBAR blk:1270 blk:1270 MENU_PRE blk:1270 MENU_AUX MENU_POST ESTAB_SSID WIFI_MODE WIFI_STATUS LOCAL_IP GATEWAY NETMASK SOFTAP_IP AP_MAC STA_MAC CHANNEL DBM CHIP_ID CPU_FREQ FLASH_SIZE FREE_HEAP blk:1153
[AC] Host:192.168.4.1,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/_ac/config,generated:/_ac/config, allocated
[PB] HTTP_GET /_ac/config
[AC] Host:192.168.4.1,/_ac/config,already allocated
[PB] Chunked, HEAD CSS_BASE CSS_ICON_LOCK blk:1270 CSS_UL CSS_INPUT_BUTTON blk:1270 CSS_INPUT_TEXT blk:1270 CSS_LUXBAR blk:1270 blk:1270 MENU_PRE MENU_AUX MENU_POST blk:1270 LIST_SSID [AC] 4 network(s) found, 769 buf
SSID_COUNT HIDDEN_COUNT blk:1270 CONFIG_IP blk:1270 blk:238 
[AC] Host:192.168.4.1,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 0.0.0.0
[AC] Host:www.msftconnecttest.com,/_ac/connect,generated:/_ac/connect, allocated
[PB] HTTP_POST /_ac/connect
[AC] Host:192.168.4.1,/_ac/connect,already allocated
[PB] Chunked, REQ [AC] Queried SSID:LuMoKiTho24
HEAD CSS_BASE CSS_SPINNER blk:1270 CSS_LUXBAR blk:1270 blk:1270 MENU_PRE blk:1270 MENU_POST CUR_SSID blk:648 
[AC] WiFi.config(IP=192.168.1.55, Gateway=192.168.1.1, Subnetmask=255.255.255.0, DNS1=192.168.1.1, DNS2=8.8.8.8)
[AC] WiFi.begin(LuMoKiTho24,KENNWORT) ch(13)....................established IP:192.168.1.55
[AC] DNS server stopped
[AC] Maintain SoftAP
[E][Preferences.cpp:49] begin(): nvs_open failed: NOT_FOUND
[AC] Preferences begin failed to import AC_CREDT
[AC] LuMoKiTho24 credential saved

Ab hier sind die WLAN Zugangsdaten eingetragen

[AC] Event<17> handler registered
# WIFI: connected to SSiD: LuMoKiTho24
# WIFI: connected!
# WIFI: signalquality: 100%
# WiFi connected to IP: 192.168.1.55
# Please fill in MQTT and KeyBLE credentials first!
[AC] STA lost connection:63
[AC] STA connection restored
[AC] Host:192.168.4.1,/connecttest.txt,ignored
[E][WebServer.cpp:633] _handleRequest(): request handler not found
[AC] Detected application, www.msftconnecttest.com, 192.168.1.55
[AC] Host:www.msftconnecttest.com,/_ac/result,generated:/_ac/result, allocated
[PB] HTTP_GET /_ac/result
[AC] Host:192.168.4.1,/_ac/result,already allocated
[PB] Chunked, RESULT [AC] Redirect to http://192.168.4.1
[AC] Leaves:5[ms]
[PB] Send canceled
[AC] Host:192.168.4.1,/_ac/success,generated:/_ac/success, allocated
[PB] HTTP_GET /_ac/success
[AC] Host:192.168.4.1,/_ac/success,already allocated      
[PB] Chunked, HEAD CSS_BASE CSS_TABLE blk:1270 CSS_LUXBAR blk:1270 blk:1270 MENU_PRE blk:1270 MENU_AUX MENU_POST ESTAB_SSID WIFI_MODE WIFI_STATUS LOCAL_IP GATEWAY NETMASK CHANNEL DBM blk:859 
[AC] Host:192.168.1.55,/keyble_setting,generated:/keyble_setting, allocated

Ab hier wird zu den MQTT und KeyBLE Zugangsdaten gewechselt

[PB] HTTP_GET /keyble_setting
[AC] Host:192.168.1.55,/keyble_setting,already allocated
[PB] Chunked, HEAD AUX_TITLE CSS_BASE CSS_UL blk:1270 CSS_INPUT_BUTTON CSS_INPUT_TEXT blk:1270 CSS_LUXBAR blk:1270 blk:1270 AUX_CSS MENU_PRE blk:1270 MENU_AUX MENU_POST ENC_TYPE AUX_ELEMENT [AC] CB in AHEAD /keyble_setting
[AC] Deserialize:EmptyInput
# /keyble.json failed to load
blk:1270 AUX_URI blk:1122 
[AC] Host:192.168.1.55,/keyble_save,generated:/keyble_save, allocated
[PB] HTTP_POST /keyble_save
[AC] Host:192.168.1.55,/keyble_save,already allocated
[PB] Chunked, HEAD AUX_TITLE CSS_BASE CSS_UL blk:1270 CSS_INPUT_BUTTON CSS_INPUT_TEXT blk:1270 CSS_LUXBAR blk:1270 blk:1270 AUX_CSS MENU_PRE blk:1270 MENU_AUX MENU_POST ENC_TYPE AUX_ELEMENT [AC] fetch /keyble_setting,elements stored
[AC] CB in AHEAD /keyble_save
[AC] JSON buffer size:1952
blk:1270 AUX_URI blk:249 
[AC] Host:192.168.1.55,/keyble_setting,generated:/keyble_setting, allocated
[PB] HTTP_POST /keyble_setting
[AC] Host:192.168.1.55,/keyble_setting,already allocated

Ab hier werden die Zugangsdaten gespeichert

[PB] Chunked, HEAD AUX_TITLE CSS_BASE CSS_UL blk:1270 CSS_INPUT_BUTTON CSS_INPUT_TEXT blk:1270 CSS_LUXBAR blk:1270 blk:1270 AUX_CSS MENU_PRE blk:1270 MENU_AUX MENU_POST ENC_TYPE AUX_ELEMENT [AC] fetch /keyble_save,elements stored
[AC] CB in AHEAD /keyble_setting
[AC] MqttServerName<4> of /keyble_setting loaded
[AC] MqttPort<4> of /keyble_setting loaded      
[AC] MqttUserName<4> of /keyble_setting loaded  
[AC] MqttUserPass<4> of /keyble_setting loaded  
[AC] MqttTopic<4> of /keyble_setting loaded     
[AC] KeyBleMac<4> of /keyble_setting loaded     
[AC] KeyBleUserKey<4> of /keyble_setting loaded
[AC] KeyBleUserId<4> of /keyble_setting loaded 
# /keyble.json loaded
blk:1270 AUX_URI blk:1270 blk:24 
[AC] Host:192.168.1.55,/keyble_save,generated:/keyble_save, allocated
[PB] HTTP_POST /keyble_save
[AC] Host:192.168.1.55,/keyble_save,already allocated
[PB] Chunked, HEAD AUX_TITLE CSS_BASE CSS_UL blk:1270 CSS_INPUT_BUTTON CSS_INPUT_TEXT blk:1270 CSS_LUXBAR blk:1270 blk:1270 AUX_CSS MENU_PRE blk:1270 MENU_AUX MENU_POST ENC_TYPE AUX_ELEMENT [AC] fetch /keyble_setting,elements stored
[AC] CB in AHEAD /keyble_save
[AC] JSON buffer size:1952
blk:1270 AUX_URI blk:249 
[AC] Host:192.168.1.55,/keyble_setting,generated:/keyble_setting, allocated
[PB] HTTP_POST /keyble_setting
[AC] Host:192.168.1.55,/keyble_setting,already allocated
[PB] Chunked, HEAD AUX_TITLE CSS_BASE CSS_UL blk:1270 CSS_INPUT_BUTTON CSS_INPUT_TEXT blk:1270 CSS_LUXBAR blk:1270 blk:1270 AUX_CSS MENU_PRE blk:1270 MENU_AUX MENU_POST ENC_TYPE AUX_ELEMENT [AC] fetch /keyble_save,elements stored
[AC] CB in AHEAD /keyble_setting
[AC] MqttServerName<4> of /keyble_setting loaded
[AC] MqttPort<4> of /keyble_setting loaded
[AC] MqttUserName<4> of /keyble_setting loaded
[AC] MqttUserPass<4> of /keyble_setting loaded
[AC] MqttTopic<4> of /keyble_setting loaded
[AC] KeyBleMac<4> of /keyble_setting loaded
[AC] KeyBleUserKey<4> of /keyble_setting loaded
[AC] KeyBleUserId<4> of /keyble_setting loaded
# /keyble.json loaded

Ab hier werden die Zugangdaten verwendet und ein Reset durchgeführt

blk:1270 AUX_URI blk:1270 blk:24 
[AC] Host:192.168.1.55,/_ac/reset,generated:/_ac/reset, allocated
[PB] HTTP_GET /_ac/reset
[AC] Host:192.168.1.55,/_ac/reset,already allocated
[PB] Chunked, HEAD UPTIME BOOTURI RESET UPTIME blk:551
[AC] Event<17> handler released
[AC] Portal stopped
[AC] Reset
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
[AC] Element<style> not registered
[AC] style<7> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] style<7> of /keyble_setting loaded
[AC] Element<MqttServerName> not registered
[AC] MqttServerName<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttServerName<4> of /keyble_setting loaded
[AC] Element<MqttPort> not registered
[AC] MqttPort<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttPort<4> of /keyble_setting loaded
[AC] Element<MqttUserName> not registered
[AC] MqttUserName<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttUserName<4> of /keyble_setting loaded
[AC] Element<MqttUserPass> not registered
[AC] MqttUserPass<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttUserPass<4> of /keyble_setting loaded
[AC] Element<MqttTopic> not registered
[AC] MqttTopic<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] MqttTopic<4> of /keyble_setting loaded
[AC] Element<KeyBleMac> not registered
[AC] KeyBleMac<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] KeyBleMac<4> of /keyble_setting loaded
[AC] Element<KeyBleUserKey> not registered
[AC] KeyBleUserKey<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] KeyBleUserKey<4> of /keyble_setting loaded
[AC] Element<KeyBleUserId> not registered
[AC] KeyBleUserId<4> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] KeyBleUserId<4> of /keyble_setting loaded
[AC] Element<save> not registered
[AC] save<8> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] save<8> of /keyble_setting loaded
[AC] Element<discard> not registered
[AC] discard<8> of /keyble_setting created
[AC] *noname placed on /keyble_setting
[AC] discard<8> of /keyble_setting loaded
[AC] /keyble_setting on hands
[AC] Element<caption> not registered
[AC] caption<9> of /keyble_save created
[AC] *noname placed on /keyble_save
[AC] caption<9> of /keyble_save loaded
[AC] Element<parameters> not registered
[AC] parameters<9> of /keyble_save created
[AC] *noname placed on /keyble_save
[AC] parameters<9> of /keyble_save loaded
[AC] Element<clear> not registered
[AC] clear<8> of /keyble_save created
[AC] *noname placed on /keyble_save
[AC] clear<8> of /keyble_save loaded
[AC] /keyble_save on hands
[AC] MqttServerName<4> of /keyble_setting loaded
[AC] MqttPort<4> of /keyble_setting loaded
[AC] MqttUserName<4> of /keyble_setting loaded
[AC] MqttUserPass<4> of /keyble_setting loaded
[AC] MqttTopic<4> of /keyble_setting loaded
[AC] KeyBleMac<4> of /keyble_setting loaded
[AC] KeyBleUserKey<4> of /keyble_setting loaded
[AC] KeyBleUserId<4> of /keyble_setting loaded
# /keyble.json loaded
[AC] Current:LuMoKiTho24
[AC] WiFi.config(IP=192.168.1.55, Gateway=192.168.1.1, Subnetmask=255.255.255.0, DNS1=192.168.1.1, DNS2=8.8.8.8)
[AC] WiFi.begin()........established IP:192.168.1.55
[AC] http server started
# WIFI: connected to SSiD: LuMoKiTho24
# WIFI: connected!
# WIFI: signalquality: 96%
# WiFi connected to IP: 192.168.1.55
# Connect to MQTT-Broker...
# Connected!
[AC] s_rc placed on /_ac/update
[AC] cap placed on /_ac/update
[AC] bin placed on /_ac/update
[AC] update placed on /_ac/update
[AC] js placed on /_ac/update
[AC] bin placed on /_ac/update_act
[AC] result placed on /_ac/update_act
[AC] dvo placed on /_ac/update_act
[AC] rc placed on /_ac/update_act
[AC] dvc placed on /_ac/update_act
[AC] /_ac/update on hands
[AC] /_ac/update_act on hands

MQTT und WLAN Verbindungen sind aufgebaut

# published SmartLock/task/working
# WiFi disabled
Hier wir die initiale Abfrage des Schlossantriebes gestartet

*** get state ***
# Nonce exchange
# Searching ...
# Found device: 00:1a:22:09:8d:70
# RSSI: -80
# Connecting in tick
# Connecting...
# Connected in tick
[E][BLERemoteCharacteristic.cpp:287] retrieveDescriptors(): esp_ble_gattc_get_all_descr: Unknown
# sendMessage end.
# Sending actual fragment: 800201221CF8203B28B5BB0000000000
# Fragment Data: 800301D5D897E95A2BF1E80010170000
# Nonce exchanged
# sendMessage called again...
# Cryptdata length: 8
# Cryptdata length: 8
# Authentifizierungswert berechnen...
# fertig...
# sendMessage end.
# Sending actual fragment: 808247E03D6DF455510B00017C61AB9F
# Fragment Data: 80834CBA7BDDB10097B50001880AE019
# Auth value: 880AE019
# Cryptdata length: 8
# Crypted data: 4CBA7BDDB10097B5
# Authentifizierungswert berechnen...
# fertig...
# Decrypted: 71010A0010170000
# New state: 2
# Done!

Ab hier wird BLE getrennt und WLAN aufgebaut

# Disconnected!
# WiFi enabled
# WiFi disconnected, reconnect...
[AC] Current:LuMoKiTho24
[AC] WiFi.config(IP=192.168.1.55, Gateway=192.168.1.1, Subnetmask=255.255.255.0, DNS1=192.168.1.1, DNS2=8.8.8.8)
[AC] WiFi.begin()......established IP:192.168.1.55
# WIFI: connected to SSiD: LuMoKiTho24
# WIFI: connected!
# WIFI: signalquality: 98%
# WiFi connected to IP: 192.168.1.55
# MQTT disconnected, reconnect...
# Connect to MQTT-Broker... 
# Connected!

WLAN und MQTT vebunden
Rückgabe vom Schloss veröffentlichen

# published SmartLock/state/unlocked
# published SmartLock/task/waiting
# published SmartLock/battery/1
# published SmartLock/rssi/-80
# waiting for command...

In diesem Status verbleibt der ESP bis er von außen über 
"DeinTopic/command" getriggert wird.

[Hendrik (Gast)]

Hi Thomas,

danke, das probiere ich morgen.

> P.S. Ich danke dir für Deinen Testeinsatz! Sei aber bitte so nachsichtig
> und betrachte das, was zur Zeit da ist nicht als fertiges Produkt,
> sondern frühe Alpha. Hier spielen sehr viele Faktoren zusammen.

der Dank liegt auf meiner Seite!
Bisher übererfüllt das Alle Erwartungen ;-)

[Hendrik (Gast)]

Hallo Thomas,

ich habe die Logs jetzt erzeugt.
Darin sind ja auch sensitive Daten enthalten. Kann ich sie dir per Mail 
schicken?
Du erreichst mich unter 
[erste_drei_buchstaben_meines_Vorname][e-mail].

Viele Grüße,
Hendrik

[Thomas (type0n)]

Hi Hendrik,

ich habe dir eine E-Mail gesendet.

Gruß
Thomas

[Max M. (tcsmaxx)]

Hi Thomas,

gute Arbeit :) Das Web Frontend kommt sehr geschmeidig ;)

Ich habe es mal kurz ohne erreichbares Schloss in der Nähe getestet und 
nach dem ich alles konfiguriert habe läuft der Connect zum  MQTT-Broker 
in der Dauerschleife. Ohne Schloss sollte ja normalerweise nicht 
vorkommen, aber vielleicht doch mal, wenn die Batterie leer ist. Kannst 
du das auch nachvollziehen?

# WIFI: connected to SSiD: tcM
# WIFI: connected!
# WIFI: signalquality: 90%
# WiFi connected to IP: 192.168.88.59
# Connect to MQTT-Broker...
# Connected!
# published SmartLock/task/working
# WiFi disabled
# Nonce exchange
# Searching ...
!!! Lockstatus -1 - timeout !!!
# Done!
# WiFi enabled
# WiFi disconnected, reconnect...
# WIFI: connected to SSiD: tcM
# WIFI: connected!
# WIFI: signalquality: 88%
# WiFi connected to IP: 192.168.88.59
# MQTT disconnected, reconnect...
# Connect to MQTT-Broker...
# Connected!
# published SmartLock/state/timeout
# published SmartLock/task/waiting
# published SmartLock/rssi/0
# waiting for command...
# MQTT disconnected, reconnect...
# Connect to MQTT-Broker...
# Connected!
# MQTT disconnected, reconnect...
# Connect to MQTT-Broker...
# Connected!
# MQTT disconnected, reconnect...
# Connect to MQTT-Broker...
# Connected!
# MQTT disconnected, reconnect...
# Connect to MQTT-Broker...
# Connected!
# MQTT disconnected, reconnect...
# Connect to MQTT-Broker...
# Connected!
...

[Thomas (type0n)]

Hallo Max,

ich danke Dir für deinen Hinweis, bis jetzt gibt es noch kein 
Errorhandling.
Bei mir haben sich nun unregelmäßige reboots gezeigt. Nur kann ich noch 
nicht genau sagen woher die kommen. Ich spiele hier zur Zeit mit dem 
Espressif Debugger herum, mal gucken, ob ich das eingrenzen kann. Bis 
jetzt ist mein Verdacht, dass es an der nicht richtig abgebauten BLE 
Verbindung zum Schloss liegt. Hierzu befinden sich ja in Deinem/RoP09s 
Repo noch einige todos. Ziel ist es zwar mittelfristig eine stabile 
Version zu bekommen, ich bin aber weitehin auch an eine Coexistence 
Variant dran, wo nicht mehr zwischen WiFi und BLE gewechselt werden 
muss. Da habe doch noch einige Ideen, was man machen könnte. Wenn das 
Wetter mal schlechter ist, setzte ich mich dran.

Schönen Gruß
Thomas

[Hendrik (Gast)]

Hallo,

so, zur hellen Jahreszeit hatte ich wenig Lust mich dem Schloss zu 
widmen.
Wie ist denn eure Erfahrung mit der Software von Thomas bisher?

Mein RasPi hat das Zeitliche gesegnet und jetzt überlege ich, ob ich den 
repariere, oder zwei ESPs nehme...
Beim ESP war bisher aber auch der WLAN Empfang nicht gut und (dadurch?) 
crashte er regelmäßig.

Gruß,
Hendrik

[Hendrik (Gast)]

P.S: Hat jemand Erfahrungen mit ESP32 mit externer WLAN Antenne? Bringt 
das was?

[Al O. (cyber83)]

Hendrik schrieb:
> P.S: Hat jemand Erfahrungen mit ESP32 mit externer WLAN Antenne? Bringt
> das was?

Ich hab einem esp8266 eine externe antenne verpasst. Nur so ein kleines 
stumpel mit ca. 10cm, ohne irgendwelche dbi angaben. Hat von vorher -92 
(mit glück) auf -75 gehoben.

[Diginix (Gast)]

Hallo Joachim @oyo, hallo Thomas @type0n, halle Max @tcsmaxx

hat einer von euch eine Ahnung was das Problem mit keyble in Verbindung 
mit nodeJS 14 sein könnte?
https://github.com/oyooyo/keyble/issues/37

Danke und Gruß
Thomas

[TiTo (Gast)]

Hallo,

ich bin zwar ein absoluter Noob was das Thema EQ-3 Türschlossantrieb 
KeyBLE angeht.
Aber hat schon jemand versucht ein ESP8266 D1 mini direckt mit dem 
Platine des Türschlosses zu verbinden?
Es gibt ja diese HomeKit ESP8266 Firmware für dieses.
So würde man nicht den Weg über die Bluetoothschnittstelle gehen, diese 
aber auch nicht kaputt machen oder zerstören, sondern man könnte diese 
weiter nutzen wenn man mag.

Das Schloss würde so gesehen ein Update (WiFi-Funktion) bekommen und 
direkt mit HomeKit verbunden werden können. Der ESP8266 D1 mini könnte 
sogar im Gehäuse selber untergebracht werden und wäre somit unsichtbar. 
Das Borad kann sogar so verstaut werden, das man mit einer 
Nadel/Büroklammer oder ähnliches an den RESET Button und mit einer 
kleinen Ausfräsung an der Rückseite an den Micro-USB-Port zum 
programieren zu kommen kann.

Ich weiß ich bin nicht der überflieger was die Arduino IDE angeht, aber 
ich habe die ESP8266 HomeKit Firmware schon soweit gebracht das diese 
mit meiner Schaltzentrale (HomeKit) keinen Fehler mehr anzeigt.

Ich habe nur leider ein paar probleme was den Bedienknöpfe in der 
Home-App angeht. Diese Sollen in drei Stellungen Fix sein. Stand jetzt 
ist leider, dass ich dort einen Balken von 0-100% habe, was mir nicht 
weiter hilft!

Ich muss noch folgendes einstellen bzw. programmieren:

-DeepSleep Modus

-HomeKit Bedienung

-die Datenverbindung zwischen dem ESP8266 D1 mini und der 
KeyBLE-Platine,
 dazu muss ich noch die richtigen Befehle herraus finden damit das 
Schloss
 die einfachsten dinge wie: Schließen, Entriegeln und Öffnen der Tür 
tut.

vielleicht kann mir bei meinen Vorhaben einer unter die Arme greifen

Einen schönen Abend noch.

TiTo

[Hendrik Friedel (Gast)]

Ja, das hat schon jemand geschafft. Ich bin aber gescheitert.
Meinen Versuch und die Quelle zu dem, der es geschafft hat habe ich im 
knx-user-forum.de dokumentiert.

Ich weiß nicht, was an der Bluetooth Schnittstelle kaputt gehen sollte.

Gruß,
Hendrik

[TiTo (Gast)]

Hallo,

danke das Du dich meldest. Meinst du diesen Beitrag wo jemand die 
Druckschalter mit dem ESP8266 verbunden hatte um so das Schloss auf und 
zu zusperren?
Diesen Beitrag hatte ich mir voller Erwartung durchgelesen.
Aber da ich nicht bereit bin, ein Kabel zur Tür zu ziehen, um so eine 
Strom Versorgung zu realisieren, schied dieser Weg für mich aus.
Meine Vorstellung ging eher dahin das ESP8266 direkt an den Datenport 
des Türschlosses anzulöten um dort direkt die Befehle zu geben und Strom 
zu bekommen. Deswegen muss das ESP unbedingt auch in den DeepSleep mode 
um Akku Kapazität zu sparen.
Weil alles was direkt am Schloss passiert "sollte es" nicht 
verschlüsselt sein, denke ich zumindest.... kann aber auch etwas naiv 
von mir gedacht sein....

[TiTo (Gast)]

Hallo,
leider ist mein vorhaben gescheitert. Das ist leider was die direkte 
integration angeht schade, aber leider nicht zu ändern.
Was mir allerdings während der ganzen Spielereien aufgefallen ist, ist 
das dass Türschloss immer nur den ersten Befehl ausführt, dann noch eine 
gewisse Zeit ansprechbar ist.
Wenn man jetzt allerdings eine Zeit lang wartet und zum Beispiel vom 
Einkaufen wieder Heim kommt (ca. eine Stunde), die Tür soll öffnen, tut 
es aber nicht. Wenn ich aber bei Haus verlassen die Homebridge neu 
starte und dann Heim kehre, öffnet Sie ohne Probleme die Tür.
Wäre es machbar  diese Funktionen "timeout" und/oder 
"auto_disconnect_time" in die Homebridge zu integrieren? So dass man der 
Bridge sagen kann das Sie die Verbindung nach der eingestellten Zeit 
trennen soll und nicht wartet bis das Schloss die Verbindung trennt?
Oder wäre es sogar möglich dem Plugin nach dem die Verbindung getrennt 
wurde einen internen Neustart oder ähnliches zu integrieren?
Wenn man die Homebridge manuell neu startet, dann steht dort 
"cashclear",
soll wohl das Plugin aus dem Arbeitsspeicher löschen um diverse Fehler 
aus zu Märzen, könnte man diese Funktion vielleicht nutzen um das nach 
jedem gesendeten Befehl zu machen?

Hoffe das hier jemand der Mitwirkenden vielleicht noch aktiv ist.
Ich selber kann leider Plugins nicht Programmieren!
Das sind nur Sachen die mir nach dem ganzen herum spielen mit dem 
ESP8266 aufgefallen waren.

TiTo

[Daniel (Gast)]

Liebe Leute,

ich weiß, der Beitrag ist etwas älter, aber dennoch gibt es aktuell noch 
keine sinnvollen (Preis/Leistung) Alternativen.
Aber hier gibt es eine ziemlich schöne Lösung. Mit ein wenig 
Bastelerfahrung
absolut umsetzbar.

https://ingenier.wordpress.com/2018/02/17/eqiva-key-ble-eq-3-bluetooth-mit-wlan-nachruesten/

Liebe Grüße,
Daniel

[Hendrik (Gast)]

Hallo,

ich habe ein Schloss, dessen Drehrichtung nicht dem Default entspricht. 
In der App habe ich das natürlich entsprechend eingestellt, aber leider 
vergisst das Schloss diese Einstellung recht häufig.
Kennt jemand das Problem?

Joachim S. schrieb:
>> Sag mal, wäre es möglich die Konfiguration des Smart-Locks über keyble
>> zu bearbeiten? z.B. pairing-modus aktivieren/deaktivieren, Drehrichtung
>> auswählen usw.
>> Plannst du es zu realisieren?
>
> Möglich wäre es - das gehört aber zu den Features, die ich grundsätzlich
> zwar gerne unterstützen würde, die derzeit aber so niedrige Priorität
> für mich haben, dass ich sie in der nächsten Zeit vermutlich eher nicht
> implementieren werde.

Ich wäre dir sehr dankbar, wenn man die Drehrichtung konfigurieren 
könnte.
Dann könnte ich diese Einstellung einmal am Tag ans Schloss senden...

Gruß,
Hendrik

[earlmanni (Gast)]

Registriert euch bei Nuki und werbt 10 Freunde, dann bekommt Ihr das 
Nuki für 49,- und habt noch einen Haufen Zubehör gratis. Ich ein Ihr 
nicht alles an Zubehör braucht verkauft es und das Smart Lock wäre sogar 
gratis.

[earlmanni (Gast)]

Registriert euch bei Nuki und werbt 10 Freunde, dann bekommt Ihr das 
Nuki für 49,- und habt noch einen Haufen Zubehör gratis. Wenn Ihr nicht 
alles an Zubehör braucht verkauft es und das Smart Lock wäre sogar 
gratis.

[OmmyT (Gast)]

@oyo
Vielen, vielen Dank für Deine Arbeit.
keyble hat mir und meiner "Bastel-Home-Automation" ein großes Stück 
weitergeholfen!

Ich (Jahrgang 74 und 8- und 16Bit erfahren ;-)) bin selbst 
Software-Entwickler (aber nur auf .NET- und php-Basis) und weiß somit 
Deine Arbeit durchaus zu schätzen.

[Diginix (Gast)]

Thomas F. schrieb:
> https://github.com/lumokitho/esp32-keyble

Hi @type0n Da keyble direkt unter nodeJS 14 bei mir fast gar nicht mehr 
funktioniert, würde ich gern deine ESP32 Lösung testen.
Wie bzw. mit was wird der ESP denn mit deinem Code geflasht?
Bisher hatte ich nur mit .bin Dateien zu tun. Brauche ich 
Arduino/platformio?
Was gebe ich der Software von deinem Git Projekt?

Danke und Gruß
Thomas

[Adrian K. (Gast)]

Hallo,
ich habe es im letzten Jahr erfolgreich den eq3 Antrieb in der 
Kombination mit einem Fingerprint R503 installiert und im Betrieb 
genommen.
Da wo ich die WIFI Verbindung dauerhaft behalten wollte habe ich für den 
eq3 lock einen separaten ESP32 spendiert, der wiederum per UART vom 
andern ESP mit R503 mit befehlen versorgt.
Eine letzte Anpassung des Codes habe ich Ende Februar durchgeführt.
Dann im April wollte ich es ein Update verpassen, mit ein paar 
Verbessunrungen.
Leider ist es mir nicht gelungen, habe ständig beim kompilieren 
Fehlermeldung bekommen.
error: static assertion failed: portGET_ARGUMENT_COUNT() result does not 
match for 0 arguments
ringbuf_type_t' has not been declared

Dann habe ich mit vor Versionen versucht, das gleiche Ergebnis. VSC neu 
installiert -- negativ
Direkt vom Github runtergeladen -- negativ
Eine ältere Version vom Platformio (vom letztem Jahr) -- negativ.
Auf einem anderem Rechner neu installiert  -- negativ

Was hat sich geändert?
Ein Fehlerprotokoll habe ich angehängt.
Vielen Dank für Eure Unterstuzung

[tomg1970 (Gast)]

Habt ihr einen Tipp wie ich das Türschloss in Home Assistant nutzen 
könnte

[Hendrik (Gast)]

Keyble und mqtt

[tomg1970 (Gast)]

Habt ihr einen Tipp wie ich das eqiva Türschloss in Home Assistant 
nutzen kann

[Tom (tomg1970)]

Habt ihr einen Tipp wie ich das eqiva Türschloss in Home Assistant 
nutzen kann?

[Steamengine (Gast)]

Hallo zusammen,
ich habe es vielleicht überlesen oder was auch immer.
Die KeyBLE Credentials, also KeyBLE UserKey und User ID muss ich bei der 
ESP32 Version oder dieser hier eingeben. Doch woher nehme ich diese 
Information?

Für Hilfe diesbezüglich wäre ich sehr dankbar...... hilfe.....

[Steamengine (Gast)]

Hallo nochmal. Ich habe jetzt einige weitere Informationen gefunden.
Den "KeyBLE User Key" muss man durch die mitgelieferte Karte ermitteln. 
Die Karte zum Beispiel mit ZBAR --> ZBarimg scannen und den mittleren 
Teil (Von hinten nach dem Abschneiden der im Klartext auf der Karte 
befindlichen Seriennummer 32 Zeichen) als Key verwenden. Ich habe dann 
noch die Buchstaben in lowercase geändert. Die KeyBLE User ID sollte 
wahrscheinlich die nächste freie sein. Bei Zero (0) wird angefangen zu 
zählen.
Dann muss ich wohl den ESP32 nach dem Speichern neu starten während das 
Schloss im Paring-Mode ist....

[Udo (Gast)]

Hallo

ich habe mir einen Eqiva Antrieb gekauft und den node Installiert finde 
den
in nodered nicht .

node red sagt auch "Installiert" kann ihn aber nicht finden ,für eine 
schnelle Rückmeldung wäre ich Dir Dankbar ,ansonsten schicke ich den 
Antrieb zurück.



Gruß

Udo

[Michi (Gast)]

Servus alle zusammen,

gibt es eine moeglichkeit keyble auf eine arduino/raspberry pi pico zu 
starten?
Oder auf einem ESP32? Ich habe den githublink gefunden aber habe keine 
Ahnung wie ich es umsetzen kann.

Kann mir jemand weiterhelfen?

[Hendrik (Gast)]

Für den ESP ist hier im Thread eine eigene Software verlinkt (nicht 
keyble)

[Michi (Gast)]

ich kriege folgende fehlermeldung beim kompilieren, weiss jemand wo das 
problem liegt?
platformio und esp32

*** [.pio/build/esp32dev/lib749/ESP32 BLE 
Arduino/BLEAdvertisedDevice.cpp.o] Error 1
*** [.pio/build/esp32dev/lib749/ESP32 BLE Arduino/BLEAdvertising.cpp.o] 
Error 1
In file included from .pio/libdeps/esp32dev/ESP32 BLE 
Arduino/src/BLEDescriptor.h:16,
                 from .pio/libdeps/esp32dev/ESP32 BLE 
Arduino/src/BLECharacteristic.h:17,
                 from .pio/libdeps/esp32dev/ESP32 BLE 
Arduino/src/BLECharacteristic.cpp:15:
.pio/libdeps/esp32dev/ESP32 BLE Arduino/src/FreeRTOS.h:61:28: error: 
'ringbuf_type_t' has not been declared
  Ringbuffer(size_t length, ringbuf_type_t type = RINGBUF_TYPE_NOSPLIT);
                            ^~~~~~~~~~~~~~
In file included from .pio/libdeps/esp32dev/ESP32 BLE 
Arduino/src/BLERemoteDescriptor.h:18,
                 from .pio/libdeps/esp32dev/ESP32 BLE 
Arduino/src/BLERemoteCharacteristic.h:18,
                 from .pio/libdeps/esp32dev/ESP32 BLE 
Arduino/src/BLERemoteService.h:16,
                 from .pio/libdeps/esp32dev/ESP32 BLE 
Arduino/src/BLEClient.h:19,
                 from .pio/libdeps/esp32dev/ESP32 BLE 
Arduino/src/BLEScan.h:17,
                 from lib/eQ3/eQ3.h:4,
                 from src/main.cpp:6:
.pio/libdeps/esp32dev/ESP32 BLE Arduino/src/FreeRTOS.h:61:28: error: 
'ringbuf_type_t' has not been declared
  Ringbuffer(size_t length, ringbuf_type_t type = RINGBUF_TYPE_NOSPLIT);
                            ^~~~~~~~~~~~~~
*** [.pio/build/esp32dev/lib749/ESP32 BLE 
Arduino/BLECharacteristic.cpp.o] Error 1
*** [.pio/build/esp32dev/src/main.cpp.o] Error 1
======================================= [FAILED] Took 2.44 seconds 
=======================================

 *  The terminal process "platformio 'run', '--target', 'upload', 
'--target', 'monitor', '--environment', 'esp32dev'" terminated with exit 
code: 1.
 *  Terminal will be reused by tasks, press any key to close it.

[Michi (Gast)]

Gibt es vielleicht eine schritt fuer schritt installationsanleitung fuer 
den esp32?

[Michi (Gast)]

Ich habe nun die richtige versionen von den bibliotheken finden koennen 
und kriege jetzt folgende fehlermeldung:
Building in release mode
Retrieving maximum program size .pio/build/esp32dev/firmware.elf
Checking size .pio/build/esp32dev/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project 
Inspect"
Error: The program size (2026637 bytes) is greater than maximum allowed 
(1966080 bytes)
RAM:   [==        ]  19.7% (used 64692 bytes from 327680 bytes)
Flash: [======*** [checkprogsize] Explicit exit, status 1
====]  103.1% (used 2026637 bytes from 1966080 bytes)

platformio.ini schaut bei mir so aus:
[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200
lib_ldf_mode = deep
lib_deps =
  ESP32 BLE Arduino @ 2.0.0
  AutoConnect @ 1.3.4
  PageBuilder @ 1.5.3
  PubSubClient
board_build.partitions = partitions_ble.csv

Hat jemand eine idee wie es weitergehen soll? Waere sehr dankbar fuer 
die antwort

[Patrick (dahype)]

Hallo

Ich versuche nun seit 2 Wochen meinen extra gekauften ESP32 zu flashen, 
bekomme es nicht hin.
Im Platformio erhalte ich ständig nur Fehlermeldungen.
Nur Erase klappt, aber kein Build usw.. bzw er startet zu Compilieren 
und wirft dann Fehlermeldungen aus.

Hoffe mir kann jemand helfen, bin echt schon am verweifeln! Nächte 
schlage ich mir um die Ohren mit probieren :-(

[Patrick (dahype)]

Hendrik schrieb:
> Für den ESP ist hier im Thread eine eigene Software verlinkt (nicht
> keyble)

Für den ESP32? Das wäre Klasse. Finde leider nichts.
Nur Keyble und das lässt sich mit Platformio nicht installieren :-(

Vielen Dank

[Patrick (dahype)]

Thomas F. schrieb:
> Hi,
>
> ich habe mal mit der ESP32 Umsetzung von tscmaxx/Rop09 rumgespielt.
>
> Hier findet Ihr was dabei herausgekommen ist:
>
> https://github.com/lumokitho/esp32-keyble


Wie lässt sich das Projekt auf den ESP32 flashen ohne Platformio (Denn 
damit klappt es nicht)? Vielen vielen Dank für Hilfe.

[Hendrik F. (hendrik_f)]

Doch, mit platformio klappt es.

Gruß,
Hendrik

[Patrick (dahype)]

Hendrik F. schrieb:
> Doch, mit platformio klappt es.
>
> Gruß,
> Hendrik

Ich erhalte beim Build immer zahlreiche Fehler.
Auf GIT gibt es auch andere User welche seit Ende 2022 mit Platformio 
nicht mehr flashen können :-(

Eine Idee an was es liegen könnte?

Danke

lib/eQ3/eQ3_util.cpp:1:10: fatal error: hwcrypto/aes.h: No such file or 
directory
 #include <hwcrypto/aes.h>
          ^~~~~~~~~~~~~~~~
compilation terminated.
Compiling .pio\build\esp32dev\FrameworkArduino\Esp.cpp.o
*** [.pio\build\esp32dev\lib05b\eQ3\eQ3_util.cpp.o] Error 1
======================================================================== 
=================  [FAILED]

[Patrick (dahype)]

Hendrik F. schrieb:

Wäre dir für einen Tipp dankbar, woran es bei mir hakt.
Habe heute ganze Nacht durchprobiert, komm immer zum gleichen Fehler :-(

[Marius S. (lauch42)]

Die AES-Funktionen sind Teil von mbedtls geworden.
Einfach hwcrypto/aes.h durch mbedtls/aes.h ersetzen.

Damit und mit Entfernen der mittlerweile in der Core-Arduino Library 
inkludierten BLE Library klappt es (also den Eintrag in platformio.ini 
entfernen).

Interessant wäre, ob man die Library in ESPHome einbinden könnte. Ich 
denke das wäre auch mit Abstand am einfachsten zu benutzen, und 
Home-Assistant ist ja dafür nicht zwingend erforderlich.
Da ich nach Umzug den Antrieb wieder in Benutzung habe, könnte ich das 
auch ganz gut gebrauchen, da müsste ich mich aber erstmal wieder 
einlesen.
Von meinem Code wurde ja garnicht soviel geändert :-)

[Patrick (dahype)]

Ich habe nun auf GIT von Marius den entscheidenden TIPP erhalten!
Konnte nun erfolgreich compilieren.

Die Platformio.ini musste ich noch abändern

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200
lib_ldf_mode = deep
lib_deps =
  ESP32 BLE Arduino @ 2.0.0
  AutoConnect @ 1.3.4
  PageBuilder @ 1.5.3
  PubSubClient
board_upload.flash_size = 8MB
board_upload.maximum_size = 8388608
board_build.partitions = default_8MB.csv

Die hwcrypto/aes.h muss durch mbedtls/aes.h ersetzt werden!


Konnte nun erfolgreich flashen.

Jedoch bekomme ich den ESP32 nicht im Wlan angezeigt.
Hätte ich da noch wo Anpassungen vorm Build durchführen müssen?

[Patrick (dahype)]

Wrote 2032576 bytes (1252792 compressed) at 0x00010000 in 30.0 seconds 
(effective 542.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
======================================================================== 
=================  [SUCCESS]

Build erfolgreich auf den ESP32 geflashed, aber es erscheint kein AP, 
daher kein Wifi das lautet " KeyBLEBridge "

Wo kann hier das Problem liegen?

Danke für Hilfe

[Hendrik F. (hendrik_f)]

Ausgabe an der seriellen Konsole?

[Patrick (dahype)]

Hendrik F. schrieb:
> Ausgabe an der seriellen Konsole?

Ich habs. Danke. Ich musste

board_build.partitions = no_ota.csv

in der ini einfügen :-)

[Patrick (dahype)]

Marius S. schrieb:
> Die AES-Funktionen sind Teil von mbedtls geworden.
> Einfach hwcrypto/aes.h durch mbedtls/aes.h ersetzen.
>
> Damit und mit Entfernen der mittlerweile in der Core-Arduino Library
> inkludierten BLE Library klappt es (also den Eintrag in platformio.ini
> entfernen).
>
> Interessant wäre, ob man die Library in ESPHome einbinden könnte. Ich
> denke das wäre auch mit Abstand am einfachsten zu benutzen, und
> Home-Assistant ist ja dafür nicht zwingend erforderlich.
> Da ich nach Umzug den Antrieb wieder in Benutzung habe, könnte ich das
> auch ganz gut gebrauchen, da müsste ich mich aber erstmal wieder
> einlesen.
> Von meinem Code wurde ja garnicht soviel geändert :-)

Besten Dank. Es wäre Klasse wenn du dich wieder näher damit beschäftigen 
könntest.
Ich kann zwar das Schloss über den Boot Button des ESP32 nun steuern, 
aber bekomme die Daten nichts in MQTT des Home Assistant. Zufällig eine 
Idee?

Im Webinterface bekomme ich die Daten eingelesen.

Ich habe mir 4 Schlösser gekauft und möchte die gerne in HAS einbinden.
Nutze auch einen Wasserzaehler Al on the Edge sowie einen Stromzähler 
ebenfalls per MQTT Broker. Beides kein Problem.

Besten Dank für einen Tipp!

[Hendrik F. (hendrik_f)]

Kann die Software mehrere schlösser?
Oder planst du vier esps?

Mit den Informationen wird dir keiner helfen können.
Guck Mal, was an debug Infos in der Konsole kommen.

[Patrick (dahype)]

Ich plane schon 4 einzelne ESP32. Zuerst habe ich mir aber eben nur 
einen geholt um das ganze mal zu testen. Für mich ist/war Platformio 
neuland, musste mich erst einlesen. Aber Schlussendlich habe ich es nun 
wenigstens hinbekommen. Für einen Newbie in der Sache schon mal ein 
Erfolg. Mit Tasmota und co, kenne ich mich schon eher aus. Auch am PI 
habe ich von PiHole bis zu Nas Server im Einsatz. 90 Smart Home Devices 
hab ich schon in Home Assistant eingebunden mit Shellys und co.

Aber hier stehe ich an was die MQTT Daten betrifft. Sie kommen im HAS 
einfach nicht an.

Weiteres Problem ist das wenn ich auf das Zahnrad Klicke um eine 
Einstellung zu ändern, sich der ESP32 aufhängt und nicht mehr 
ansprechbar ist (Im DHCP Modus). Hier hilft dann nur neu flashen. Dies 
tritt auf wenn der ESP32 auf DHCP gesetzt ist.
Solange man hier nichts ändert oder ändern möchte nach der 
Ersteinrichtung bleibt der ESP32 online und ich kann auch über den Boot 
Point das Schloss triggern. Sobald man aber im WebIF aufs Zahnrad kickt, 
hängt er sich auf ist aber weiterhin mit der IP Online und sendet 
offensichtlich laut Router auch Daten, reagiert aber auch nicht mehr 
aufs manuelle triggern des Boot Points.

Ebenfalls verliert er wenn ich den AP auf Statisch Setze nach paar 
minuten den AP und hängt wieder im Einrichtungs AP SSID  "KeyBLEBridge" 
und ich muss den AP wieder neu konfigurieren. Jedoch bei Statisch kann 
ich zumindest die ersten minuten bis er die Verbindung verliert, 
jederzeit die Config im WebIF ändern..

Daher belasse ich ihn im DHCP Modus. Hier bleibt er zumindest Online. 
Port ist freigegeben und auch sonst habe ich mit der Fritzbox den ESP32 
erstmal auf eine Fixe IP gesetzt.

Hauptproblem ist aber eben das die Daten nicht im MQTT Broker ankommen.
In neuen HAS Versionen braucht man ja angeblich nach FAQ keine YAML 
Config mehr. Hab trotzdem testweise eine gesetzt. Aber auch hier, 
Fehlanzeige.

Wie könnte ich nun an die Debug Infos über die IP kommen?
Ohne den ESP32 an den PC an stecken zu müssen. Denn sobald ich ihn vom 
Strom  nehme, komm ich nicht mehr aufs WebIF. Daher gleiches Verhalten 
wie oben erwähnt im DHCP Modus.

[Hendrik F. (hendrik_f)]

Wie gesagt: Guck Mal debug Infos übers USB Kabel.

Und wegen Mqtt Guck Mal nach einem Windows Mqtt Monitor.

[Patrick (dahype)]

---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
# WIFI: connected to SSiD: DaHype xxxxxx
# WIFI: connected!
# WIFI: signalquality: 100%
# WiFi connected to IP: 192.168.1.178
# Connect to MQTT-Broker...
# Connected!
# published keyble/task/working
# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...
# Found device: 00:1a:xxxxxx
# RSSI: -75
# Connecting in tick
# Connecting...
# Connected in tick
[ 21431][E][BLERemoteCharacteristic.cpp:289] retrieveDescriptors(): 
esp_ble_gattc_get_all_descr: Unknown
# sendMessage end.
# Sending actual fragment: 800200E4E86CDFF4D365C90000000000
# Fragment Data: 80030079DCCF457CABD09E0010170000
# Nonce exchanged
# sendMessage called again...
# Cryptdata length: 8
# Cryptdata length: 8
# Authentifizierungswert berechnen...
# fertig...
# sendMessage end.
# Sending actual fragment: 8082B918C35B2DA98318000139EC7AD2
# Fragment Data: 80837F8008CC1C5ABB260001FC2C28A9
# Auth value: FC2C28A9
# Cryptdata length: 8
# Crypted data: 7F8008CC1C5ABB26
# Authentifizierungswert berechnen...
# fertig...
# Decrypted: 70010B0010170000
# New state: 3
# Done!


Im MQTT Explorer unter Windows wenn ich mich mit dem HAS verbinde., 
erscheint der ESP32 als Topic keyble.
Wenn ich manuell triggere über den Boot Point, ändert sich auch der 
Status im MQTT Explorer. Daher hier ist alles korrekt.
Nur im HAS selbst ist keinerlei Spur von einer Entität :-(

[Hendrik F. (hendrik_f)]

Dann ist das ein Has Problem.
Da kenne ich mich nicht aus.

[Patrick (dahype)]

Da es mit HAS aktuell nicht klappt, wäre es möglich das man Lock und 
unlock in das Web Interface einbaut? Wäre für mich eine alternative, da 
ich per dyndns darauf zugreifen könnte von unterwegs. Ist dies funktion 
einzubauen mit großem Aufwand verbunden? Die Schlösser werden momentan 
wohl wieder vermehrt gekauft und es wäre echt toll wenn jemand da 
Projekt weiter Entwickeln kann...

[Hendrik F. (hendrik_f)]

Du willst dein Schloss ohne Passwort ins Internet stellen?

Das HAS Problem sollte doch lösbar sein.

[Patrick (dahype)]

Naja ist ja nicht direkt öffentlich zugänglich. Nur mit meinen Login 
Daten, und selbst dann müsste jemand davon vor Ort wissen bzw vor Ort 
sein wenn er Kriminelle Absichten hätte. Und selbst in dem Fall, erhalte 
ich von der Kamera und vom Kontaktschalter der Alarmanlage sofort eine 
Benachrichtigung oder je nach Uhrzeit wird sogar ein Alarm ausgelöst.

Ich hoffe das sich das mit HAS lösen lässt, muss aber erst jemanden 
finden der Ahnung davon hat. Denn anscheinend findet der Broker 
"selbstgemachte" Lösungen nicht mehr automatisch und die Einbindung in 
die yaml wurde in HAS auch vor paar Versionen geändert und passt nun 
nicht mehr wie auf git beschrieben. Somit scheitert es wohl am richtigen 
Sensor Eintrag in der yaml.
Auch abgesehen von DNS, wäre es super wenn man im Web Interface das 
Schloss triggern könnte.

[Patrick (dahype)]

Habe für MQTT Hilfe erhalten! Es lag bzw liegt daran, das der Broker wie 
vermutet die Entitäten nicht automatisch findet. Noch dazu wurde wie man 
den Sensor in die YAML einbindet, vor kurzem in HAS geändert. Daher es 
ist ein neues Format nutwendig. Nun wird der Sensor gefunden und ich 
kann über HAS öffnen und schließen. Aber sehr unzuverlässig. Hin und 
wieder klappts, dann wieder nicht.

Das Problem ist, das sich der ESP32 nach kurzer Zeit immer wieder 
aufhängt. Daher ich komme nicht mehr auf die IP weder Statisch noch 
DHCP. Er sendet aber weiter, macht aber Timeouts im HAS und manuell 
triggern über den Boot Knopf klappt dann auch nicht mehr. Nach ein und 
ausstecken erfängt er sich hin und wieder. Oft verliert er aber auch 
einfach meine AP Einstellungen. Daher er hängt wieder im Einrichtungs AP 
fest.

Jemand dazu eine Idee was ich in der Main Config ändern könnte, damit 
dies nicht mehr der Fall ist?
Im Log sehe ich bei den Problemen nur das er ständig Wifi trennt, 
verbindet...

Habe 100% WLAN Signal. Daran kanns also nicht liegen. AP schon 
getauscht, auch daran liegts nicht.

[Hendrik F. (hendrik_f)]

Zeig mal das log

[Patrick (dahype)]

Ich hab derzeit extra einen anderen Router als Test AP eingerichtet. 
Tritt aber wie geschrieben auch auf anderen Access Points auf.

P192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
# WIFI: connected to SSiD: Test
# WIFI: connected!
# WIFI: signalquality: 62%
# WiFi connected to IP: 192.168.1.178
# Connect to MQTT-Broker...
# Connected!
# published keyble/task/working
# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...
# Found device: 00:1a:xxxxxx
# RSSI: -79
# Connecting in tick
# Connecting...
# Connected in tick
[  6795][E][BLERemoteCharacteristic.cpp:289] retrieveDescriptors(): 
esp_ble_gattc_get_all_descr: Unknown
# sendMessage end.
# Sending actual fragment: 80020010ADB4781142787A0000000000
# Fragment Data: 8003007558BC13BE9A3A2D0010170000
# Nonce exchanged
# sendMessage called again...
# Cryptdata length: 8
# Cryptdata length: 8
# Authentifizierungswert berechnen...
# fertig...
# sendMessage end.

assert failed: xQueueGenericSend queue.c:832 (pxQueue->pcHead != ((void 
*)0) || pxQueue->u.xSemaphore.xMutexHolder == ((void *)0) || 
pxQueue->u.xSemaphore.xMutexHolder == xTaskGetCurrentTaskHandle())


Backtrace: 0x4008380d:0x3ffe7bb0 0x40094f29:0x3ffe7bd0 
0x4009a539:0x3ffe7bf0 0x400959de:0x3ffe7d20 0x400feb65:0x3ffe7d60 
0x400fee1d:0x3ffe7f40 0x4023cb22:0x3ffe7f60 0x400d6b6d:0x3ffe7f80 
0x400d755d:0x3ffe7fd0 0x400d5975:0x3ffe7ff0 0x400d6519:0x3ffe80a0 
0x40131f76:0x3ffe80f0 0x4013271d:0x3ffe8110 0x4015aaa1:0x3ffe8160 
0x4015cc13:0x3ffe8180




ELF file SHA256: c92c274d1e0b063c

Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13104
load:0x40080400,len:3036
entry 0x400805e4
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
# WIFI: connected to SSiD: Test
# WIFI: connected!
# WIFI: signalquality: 64%
# WiFi connected to IP: 192.168.1.178
# Connect to MQTT-Broker...
# Connected!
# published keyble/task/working
# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...
*** toggle ***
# Found device: 00:1a:xxxxxxxxxx
# RSSI: -64
# Connecting in tick
# Connecting...
# Connected in tick
[ 16079][E][BLERemoteCharacteristic.cpp:289] retrieveDescriptors(): 
esp_ble_gattc_get_all_descr: Unknown
# sendMessage end.
# Sending actual fragment: 800200D60CAA4E16F4EC6E0000000000
# Fragment Data: 800300A2A851F6FD66A7840010170000
# Nonce exchanged
# sendMessage called again...
# Cryptdata length: 8
# Cryptdata length: 8
# Authentifizierungswert berechnen...
# fertig...
# sendMessage end.

assert failed: xQueueGenericSend queue.c:832 (pxQueue->pcHead != ((void 
*)0) || pxQueue->u.xSemaphore.xMutexHolder == ((void *)0) || 
pxQueue->u.xSemaphore.xMutexHolder == xTaskGetCurrentTaskHandle())


Backtrace: 0x4008380d:0x3ffe7b50 0x40094f29:0x3ffe7b70 
0x4009a539:0x3ffe7b90 0x400959de:0x3ffe7cc0 0x400feb65:0x3ffe7d00 
0x400fee1d:0x3ffe7ee0 0x4023cb22:0x3ffe7f00 0x400d6b6d:0x3ffe7f20 
0x400d755d:0x3ffe7f70 0x400d5975:0x3ffe7f90 0x400d6519:0x3ffe8040 
0x40131f76:0x3ffe8090 0x4013271d:0x3ffe80b0 0x4015aaa1:0x3ffe8100 
0x4015cc13:0x3ffe8120




ELF file SHA256: c92c274d1e0b063c

Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13104
load:0x40080400,len:3036
entry 0x400805e4
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
# WIFI: connected to SSiD: Test
# WIFI: connected!
# WIFI: signalquality: 68%
# WiFi connected to IP: 192.168.1.178
# Connect to MQTT-Broker...
# Connected!
# published keyble/task/working
# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...
*** toggle ***
# Found device: 00:1a:xxxxxxxxxxx
# RSSI: -64
# Connecting in tick
# Connecting...
# Connected in tick
[ 10112][E][BLERemoteCharacteristic.cpp:289] retrieveDescriptors(): 
esp_ble_gattc_get_all_descr: Unknown
# sendMessage end.
# Sending actual fragment: 800200F447832CC7D801190000000000
# Fragment Data: 800300BFD75A591D61E2B00010170000
# Nonce exchanged
# sendMessage called again...
# Cryptdata length: 8
# Cryptdata length: 8
# Authentifizierungswert berechnen...
# fertig...
# sendMessage end.
# Sending actual fragment: 80827B62F6539C1F1A7600013C0DD8ED
# Fragment Data: 808386410CAA559A8E1F000110127DFE
# Auth value: 10127DFE
# Cryptdata length: 8
# Crypted data: 86410CAA559A8E1F
# Authentifizierungswert berechnen...
# fertig...
# Decrypted: 70010A0010170000
# New state: 2
# Done!
# Disconnected!
# WiFi enabled
# WiFi disconnected, reconnect...
Rebooting...
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13104
load:0x40080400,len:3036
entry 0x400805e4
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
[  1490][E][WiFiSTA.cpp:317] begin(): connect failed! 0x300a


Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13104
load:0x40080400,len:3036
entry 0x400805e4
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
# WIFI: connected to SSiD: DaHype SmartHome Devices
# WIFI: connected!
# WIFI: signalquality: 100%
# WiFi connected to IP: 192.168.1.178
# Connect to MQTT-Broker...
# Connected!
# published keyble/task/working
# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...
*** toggle ***
# Found device: 00:1a:xxxxx
# RSSI: -63
# Connecting in tick
# Connecting...
# Connected in tick
[ 17150][E][BLERemoteCharacteristic.cpp:289] retrieveDescriptors(): 
esp_ble_gattc_get_all_descr: Unknown
# sendMessage end.
# Sending actual fragment: 800200BAAA0BB643C2ED2F0000000000
# Fragment Data: 8003005DA1CF162EFB4DCD0010170000
# Nonce exchanged
# sendMessage called again...
# Cryptdata length: 8
# Cryptdata length: 8
# Authentifizierungswert berechnen...
# fertig...
# sendMessage end.

assert failed: xQueueGenericSend queue.c:832 (pxQueue->pcHead != ((void 
*)0) || pxQueue->u.xSemaphore.xMutexHolder == ((void *)0) || 
pxQueue->u.xSemaphore.xMutexHolder == xTaskGetCurrentTaskHandle())


Backtrace: 0x4008380d:0x3ffe84d0 0x40094f29:0x3ffe84f0 
0x4009a539:0x3ffe8510 0x400959de:0x3ffe8640 0x400feb65:0x3ffe8680 
0x400fee1d:0x3ffe8860 0x4023cb22:0x3ffe8880 0x400d6b6d:0x3ffe88a0 
0x400d755d:0x3ffe88f0 0x400d5975:0x3ffe8910 0x400d6519:0x3ffe89c0 
0x40131f76:0x3ffe8a10 0x4013271d:0x3ffe8a30 0x4015aaa1:0x3ffe8a80 
0x4015cc13:0x3ffe8aa0




ELF file SHA256: c92c274d1e0b063c

Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13104
load:0x40080400,len:3036
entry 0x400805e4
---Starting up...---
---AP Settings---
---AP IP: 192.168.4.1---
---AP SSID: KeyBLEBridge---
# /keyble.json loaded
# WIFI: connected to SSiD: DaHype SmartHome Devices
# WIFI: connected!
# WIFI: signalquality: 100%
# WiFi connected to IP: 192.168.1.178
# Connect to MQTT-Broker...
# Connected!
# published keyble/task/working
# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...
*** toggle ***
# Found device: 00:1a:xxxxxx
# RSSI: -68
# Connecting in tick
lld_pdu_get_tx_flush_nb HCI packet count mismatch (0, 1)
# Connecting...
# Connected in tick
[ 11088][E][BLERemoteCharacteristic.cpp:289] retrieveDescriptors(): 
esp_ble_gattc_get_all_descr: Unknown
# sendMessage end.
# Sending actual fragment: 800200EC1E777431B1A0170000000000
# Fragment Data: 80030063C6BE2CBF99B96F0010170000
# Nonce exchanged
# sendMessage called again...
# Cryptdata length: 8
# Cryptdata length: 8
# Authentifizierungswert berechnen...
# fertig...
# sendMessage end.
# Sending actual fragment: 8082E2063A5720E78301000190625CFE
# Fragment Data: 808377C30FFADA660F3F0001C1218916
# Auth value: C1218916
# Cryptdata length: 8
# Crypted data: 77C30FFADA660F3F
# Authentifizierungswert berechnen...
# fertig...
# Decrypted: 70010A0010170000
# New state: 2
# Done!
# Disconnected!
# WiFi enabled
# WiFi disconnected, reconnect...
# WIFI: connected to SSiD: DaHype SmartHome Devices
# WIFI: connected!
# WIFI: signalquality: 100%
# WiFi connected to IP: 192.168.1.178
# published keyble/task/working
# WiFi disabled
*** toggle ***
!!! Lockstatus -1 - timeout !!!
# Done!
# WiFi enabled
# WiFi disconnected, reconnect...
# WIFI: connected to SSiD: DaHype SmartHome Devices
# WIFI: connected!
# WIFI: signalquality: 100%
# WiFi connected to IP: 192.168.1.178
# MQTT disconnected, reconnect...
# Connect to MQTT-Broker...
# Connected!
# published keyble/state/timeout
# published keyble/task/waiting
# published keyble/battery/1
# published keyble/rssi/-68
# waiting for command...
# published keyble/task/working
# WiFi disabled
*** toggle ***

[Hendrik F. (hendrik_f)]

Rebooting... ets Jul 29 2019 12:21:46 rst:0xc (SW_CPU_RESET),boot:0x13

Versuch Mal eine bessere Stromversorgung (Kabel und Netzteil)

Sonst vielleicht den Flash auf 40 MHz stellen

https://github.com/espressif/arduino-esp32/issues/3510

[Patrick (dahype)]

Danke. Das war auch gestern schon mein Gedanke wegen der 
Stromversorgung.
Ich habe schon 4 Netzteile durchprobiert. Unter anderem ein PI 4 
Netzteil mit 3A und 5,1V. Sowie auch andere. Verhalten überall gleich.

Mit den 40Mhz werde ich gleich mal versuchen. Danke

[Hendrik F. (hendrik_f)]

Auch mal das Kabel tauschen...

Hier gibt's mehr dazu

https://www.esp32.com/viewtopic.php?f=12&t=11439&start=30

[Patrick (dahype)]

Kabel und Netzteil sind OK. Es schaut nun gut aus!
Der entscheidende Tipp von dir mit 40Mhz war wohl das ausschlaggebende.
Bleibt noch etwas abzuwarten, aber derweil schaut es vielversprechend 
aus.

; set frequency to 40MHz
board_build.f_flash = 40000000L

[Hendrik F. (hendrik_f)]

Super!

Vielleicht machst du nen Pull Requests mit deinen Änderungen.

[Patrick (dahype)]

Hendrik F. schrieb:
> Super!
>
> Vielleicht machst du nen Pull Requests mit deinen Änderungen.

Ich hab noch ein paar Änderungen durchgeführt welche User in den Issue 
beschrieben hatten. Werde es aber erstmal paar Tage laufen lassen und 
wenn es wie gewünscht funktioniert, werd ich das bei git mitteilen.

Danke dir jedenfalls für den Entscheidenden Tipp. Auf das wäre ich nie 
gekommen. Vorher hätte ich noch den ESP32 aus dem Fenster geworfen.

Wenns gut läuft, werd ich mir noch 3 Stk holen bzw eventuell sogar noch 
ein weiteres Schloss für die Gartenhütte. Somit würde ich dann 4 Stk 
extra ansteuern mit je einem ESP32.

Da die Schlösser derzeit im Warehouse Deal günstig zu bekommen sind, 
hätte ich dann für 4Stk inkl ESP und Netzteil 250€ investiert! Quasi 
nicht mal der Preis was ein Nuki ohne Bridge kosten würde....

[Patrick (dahype)]

So. Nun melde ich mich nochmals. 14 Stunden lief alles völlig 
problemlos. Dann wie aus dem Nichts lieferte keine Daten mehr und war 
wieder im KeyBLEBridge. Musste also den AP wieder manuell setzen.

Wie könnte ich den Problem auf die schliche kommen? Im Log ist nichts 
großartiges zu sehen. Nur das disconnect steht und danach Connected 
KeybleBridge. Also der Einrichtungs AP.

Mit dem WLAN ist und war definitv alles ok.

Jetzt würde ich gerne probieren meine AP direkt zu setzen in der config. 
Also hardcoding wie ich gelesen habe, nur weiß ich nicht wo und was ich 
in der Main Datei einfügen muss. Hoffe das kann mir jemand beantworten.

Danke

[Hendrik F. (hendrik_f)]

Zeig mal das log vom Zeitpunkt wo das Problem entstand.

[Patrick (dahype)]

Mit den Verbesserungen von corgan auf git, scheint es nun zu laufen.
Bin da immer noch etwas vorsichtig und stellt sich erst in paar Tagen 
heraus. Aber es schaut gut aus :-)

https://github.com/lumokitho/esp32-keyble/pull/7/files/b71b3d9ecf78a8fab9e15a74550d66f0782be88b

[Michi O. (michi_o)]

Hi alles zusammen, ich kriege folgende fehlermeldung mit platformio

Building FS image from 'data' directory to 
.pio/build/esp32dev/spiffs.bin
error: can't read source directory
*** [.pio/build/esp32dev/spiffs.bin] Error 1

Hat da wer ideen?

[Michi O. (michi_o)]

Wenn ich aber einfach auf kompilieren und hochladen klicke - startet der 
esp nicht
ELF file SHA256: f4d36c5aec79c1e9

E (830) esp_core_dump_flash: Core dump flash config is corrupted! 
CRC=0x7bd5c66f instead of 0x0
Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13104
load:0x40080400,len:3036
entry 0x400805e4

[Hendrik F. (hendrik_f)]

Klingt, als fehlen beim Kompilieren Daten.
Source komplett heruntergeladen?

[Michi O. (michi_o)]

Ja, komplett

https://github.com/lumokitho/esp32-keyble

[Michi O. (michi_o)]

Habe nun auf einem anderen PC Platformio installiert und kriege die 
gleiche fehlermeldung wenn ich Build Filesystem Image anklicke

Building FS image from 'data' directory to
.pio/build/esp32dev/spiffs.bin
error: can't read source directory
*** [.pio/build/esp32dev/spiffs.bin] Error 1

[Patrick (dahype)]

Michi O. schrieb:
> Habe nun auf einem anderen PC Platformio installiert und kriege die
> gleiche fehlermeldung wenn ich Build Filesystem Image anklicke
>
> Building FS image from 'data' directory to
> .pio/build/esp32dev/spiffs.bin
> error: can't read source directory
> *** [.pio/build/esp32dev/spiffs.bin] Error 1

Du brauchst nur einen leeren Ordner anlegen der data heißt.
Oder du ladest die keyble zip von git, entpackst sie, und erstellst dort 
gleich den Data Ordner, bevor du das Projekt in Platformio öffnest.

Dann klappts einwandfrei. Habe selbst lange nach einer Lösung gesucht 
als ich Anfangs immer die Fehlermeldung hatte.

LG

[Patrick (dahype)]

data Ordner erstellen. Danach läufts ohne spiffs fehler.

[Hendrik F. (hendrik_f)]

Es wäre echt super, wenn ihr die Änderungen und Vorschläge, die ihr habt 
als pull request auf github stellt.
Sonst sucht sich der nächste doof.

[Al O. (cyber83)]

nach 5 Jahren ist bei mir nun das erste Smartlock kaputt.
Aber nicht kaputt-kaputt, sondern so, dass ich fast daran verrückt 
geworden wäre.
Ich nehme an, dass die kontaktschalter, die die umdrehungen des 
schlüssels reistrieren und messen, am kaputtwerden sind bzw. zumindest 
einer davon sehr unzuverlässig ist.
das hat zur auswirkung, dass das schloss zB statt aufzusperren eine 
runde zuviel dreht, folglich dann die falle zurückzieht, bis der 
drehmomentschutz des schlosses "stopp" sagt.
damit vergisst das schloss aber in welcher position es sich gerade 
befindet. wenn man nun sperren drückt wird eine halbe runde zu wenig 
gedreht. daraus resultierend wurde bei mir dann nicht abgesperrt.

ich dachte zuerst an konfigurationsfehler, dann an softwarefehler (ja, 
immer wenn man vor dem schloss steht funktioniert es richtig!), aber 
schlussendlich kann ich beides absschließen, da das neue schloss das 
alte, richtige verhalten zeigt.
Mechanischen defekt kann ich ausschließen, das schloss innen ist sauber, 
leichtgängig, auch der schlüssel.

ich werde beizeiten (vermutlich kommenden winter erst, das sind typische 
winterprojekte bei mir) die platine auslöten und dann die beiden 
Kontakttaster durchmessen bzw. tauschen versuchen.

falls jemand das gleiche problem bekommt. ersatzschloss anschaffen.
ich hatte hier grob geschätzt von februar bis november täglich 2 bis 3 
öffnen / schließzyklen. macht ca. 600 bis 900 pro jahr, rechnen wir mit 
700 (wochenende, urlaub, ...) und ca. 5 jahre sind 3500 
schlossbewegungen. die Kontakttaster bekommen 4 impulse pro runde, also 
10.000 bis 12.000 als lebensdauer - klingt nach einem plausiblen wert.

LG

[Christian E. (emron)]

Hallo,

ich hab mal eine Frage bezüglich des keyble-Scripts 
(https://github.com/oyooyo/keyble). Ich probiere dies auf einem 
Raspberry zu installieren.

Jedoch bei der Eingabe von:
npm install --update --global --unsafe-perm keyble

geht der Ladebalken bis ganz nach hinten, es wird aber keine 
Fertigmeldung gegeben und der Raspberry wird voll ausgelastet, sodass 
man den Prozess mit STRG+C (hab bis zu 15 Mins gewartet) abbrechen muss.

Ich habe es mit einem Raspberry 3+, Raspberry 4 und Raspberry Zero 2 
getestet, jedes mal das gleiche Problem.

Ist das Problem bekannt bzw. was könnte den Fehler verursachen?

Viele Grüße
Christian

[Patrick (dahype)]

Ich suche täglich seit Monaten nach einer Lösung warum der ESP32 nach 
ein paar Stunden die Verbindung verliert und dann wieder im AP des 
keyble hängt. Wenn ich den AP dann neu einwähle, läuft es wieder für 
paar Stunden völlig Problemlos. Daher der Auto Connect zum Wifi Netzwerk 
funktioniert nicht.

Ich möchte daher die Wifi Daten von meinem AP direkt integrieren damit 
der ESP32 sich immer damit verbindet.

Leider kann oder will mir niemand in anderen Foren helfen. Bin da echt 
am verweifeln, da ich täglich 3x die Daten neu eingeben muss damit das 
Schloss paar Stunden funktioniert!

Hoffe das ihr mir hier sagen könnt wie ich das sogenannte Hardcoding  in 
der Maindatei? eintragen kann?

// 
---[SetupWiFi]---------------------------------------------------------- 
-----
void SetupWifi()
{
  digitalWrite(LED_GPIO,LOW);

  if (Portal.begin())
  {
   if (WiFi.status() == WL_CONNECTED)
   {
     Serial.println("# WIFI: connected to SSiD: " + WiFi.SSID());
     digitalWrite(LED_GPIO,HIGH);
   }
   int maxWait=100;
   while (WiFi.status() != WL_CONNECTED) {
    Serial.println("# WIFI: checking SSiD: " + WiFi.SSID());
    delay(500);

    if (maxWait <= 0)
        ESP.restart();
      maxWait--;
  }
  Serial.println("# WIFI: connected!");
  Serial.println("# WIFI: signalquality: " + 
String(GetWifiSignalQuality()) + "%");
  Serial.println("# WiFi connected to IP: " + 
WiFi.localIP().toString());
  digitalWrite(LED_GPIO,HIGH);
  }
}

[Hendrik F. (henfri)]

Lass dochmal einen Rechner am USB Port und Guck, was auf der seriellen 
Schnittstelle geloggt wird.

Der Codeblock von dir gibt nur Infos raus.

[Patrick (dahype)]

Eben nicht wirklich was. Nur das disconnect steht sobald er die 
Verbindung zum AP verliert. Der Auto Connect funktioniert also nicht. 
Gehe ich manuell aufs Web Interface von keyble und wähle mich neu in den 
AP ein, ist wieder alles OK für paar Stunden.

Daher möchte ich den AP von Keyble entfernen und meine Daten von meinem 
AP eintragen damit er sich automatisch mit diesen verbindet.

Ein User im Git hat vor monaten mal geschrieben das er es beheben konnte 
mit Hardcoding.

"I made it work by hardcoding credentials under Portal.begin(SSID,PASS)"

Hätte diesen schon mehrmals versucht zu erreichen, aber leider keine 
Antwort oder Reaktion.

Dies würde ich eben gerne umsetzen, nur scheittert es hier an meinen 
Fähigkeiten und in Foren bekam ich dazu leider auch keine Hilfe wo/was 
in der main einzutragen ist :-(

[Hendrik F. (henfri)]

Ein komplettes Log würde schon helfen...
Ich vermute, der ESP startet neu. Das würde man sehen...

schick Mal nen Link zu deinem code

[Artur K. (artur_k638)]

Marius S. schrieb:
> Die AES-Funktionen sind Teil von mbedtls geworden.
> Einfach hwcrypto/aes.h durch mbedtls/aes.h ersetzen.
>
> Damit und mit Entfernen der mittlerweile in der Core-Arduino Library
> inkludierten BLE Library klappt es (also den Eintrag in platformio.ini
> entfernen).
>
> Interessant wäre, ob man die Library in ESPHome einbinden könnte. Ich
> denke das wäre auch mit Abstand am einfachsten zu benutzen, und
> Home-Assistant ist ja dafür nicht zwingend erforderlich.
> Da ich nach Umzug den Antrieb wieder in Benutzung habe, könnte ich das
> auch ganz gut gebrauchen, da müsste ich mich aber erstmal wieder
> einlesen.
> Von meinem Code wurde ja garnicht soviel geändert :-)
Hi,
Gibt es was neue bezüglich esphome?
Hast du dich schon damit befaßt?
Grüß

[Dirk (digaus)]

Danke schonmal an alle die diese großartige Vorarbeit geleistet haben.

Habe eine erste Version für esphome geschrieben auf Basis der ESP32 
Version.

Diese findet ihr hier:

https://github.com/digaus/esphome-components-eqiva


Aktuell funktioniert die Ansteuerung via Services.

Initiales Pairing, um den User Key zu bekommen, ist ebenfalls möglich. 
Weiterleiten des aktuellen Status habe ich noch nicht umgesetzt.

Diese Version hier ist als alpha zu sehen und wurde lediglich am 
Schreibtisch getestet.

Mein Ziel ist es mein HMIP Schloss durch dieses zu ersetzen und direkt 
mit einem ESP32 anzusteuern welcher an einen Fingerprint angeschlossen 
und in meiner Klingel integriert ist.

Hierfür habe ich eigens ein ESP32-Board entwickelt, welches direkt mit 
dem Fingerprint in eine Klingel integriert werden kann.

[Philipp C. (e61_phil)]

Dirk schrieb:
> Habe eine erste Version für esphome geschrieben auf Basis der ESP32
> Version.

Das klingt ja super!

Kannst Du ganz knapp beschreiben wie man das Pairing machen muss?

[Dirk (digaus)]

Philipp C. schrieb:
> Dirk schrieb:
>> Habe eine erste Version für esphome geschrieben auf Basis der ESP32
>> Version.
>
> Das klingt ja super!
>
> Kannst Du ganz knapp beschreiben wie man das Pairing machen muss?

Einfach den Pair Service aufrufen und dort den Card Key eintragen, den 
man bekommt wenn man den QR Code scannt. (Zuvor natürlich warten, bis 
das Schloss verbunden ist und dann noch 5 Sekunden den öffnen Knopf 
gedrückt halten um das Pairing zu aktivieren)

Gleichzeitig die Logs vom ESP anzeigen. Dort wird dann der user_key und 
die user_id geloggt.

[Artur K. (artur_k638)]

Hi, danke für dein Projekt.
Habe es ausprobiert, aber iwie startet mein esp32 nicht richtig nach dem 
Flaschen. Iwas mache ich falsch!?

[Hendrik F. (henfri)]

Ja bestimmt.

[Dirk (digaus)]

Artur K. schrieb:
> Hi, danke für dein Projekt.
> Habe es ausprobiert, aber iwie startet mein esp32 nicht richtig nach dem
> Flaschen. Iwas mache ich falsch!?

Welchen ESP32 hast du denn?

[Artur K. (artur_k638)]

Welche Version von esphome benutzt ihr?

[Artur K. (artur_k638)]

Dirk schrieb:
> Artur K. schrieb:
>> Hi, danke für dein Projekt.
>> Habe es ausprobiert, aber iwie startet mein esp32 nicht richtig nach dem
>> Flaschen. Iwas mache ich falsch!?
>
> Welchen ESP32 hast du denn?

AZDelivery ESP32 D1 Mini

Hatte eine mit ble proxy, habe da code Teile von dem Projekt 
hinzugefügt. Nach dem Flaschen startet er nicht, bzw zeigt was komisches 
im log, also nicht was normalerweise in log von esphome ist.
Versuche es noch mal exakt das was bei dir ist. Mal sehen.

[Hendrik F. (henfri)]

Artur K. schrieb:
> startet er nicht, bzw zeigt was komisches im log,

Und ist das geheim?

[Artur K. (artur_k638)]

Hendrik F. schrieb:
> Artur K. schrieb:
>> startet er nicht, bzw zeigt was komisches im log,
>
> Und ist das geheim?

Natürlich nicht. Habe gerade es nicht zu Hand. Wenn ich es später noch 
mal probiere, poste ich es sofort.

[Artur K. (artur_k638)]

Also, noch mal versucht, alles sauber geschrieben, hats geklappt. nur 
wenn ich bluetooth_proxy:
  active: true
einfüge, sag er mir
RAM:   [==        ]  17.9% (used 58652 bytes from 327680 bytes)
Flash: [==========]  100.9% (used 1851057 bytes from 1835008 bytes)
Error: The program size (1851057 bytes) is greater than maximum allowed 
(1835008 bytes)
*** [checkprogsize] Explicit exit, status 1

obwohl
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
werden nur 2mb benutzt? es sind doch knapp 1,8mb. verstehe ich was 
falsch?

[Philipp C. (e61_phil)]

Artur K. schrieb:
> Also, noch mal versucht, alles sauber geschrieben, hats geklappt.

Ich musste bei mir auf dem ESP32 auch alles was ich davor laufen hatte 
rauswerfen, damit es drauf passt.

Dann hat es aber super geklappt. Vielen Dank!

Wäre es auch möglich mehr als einen dieser Antriebe an einem ESP32 zu 
betreiben?

[Dirk (digaus)]

Philipp C. schrieb:
> Artur K. schrieb:
>> Also, noch mal versucht, alles sauber geschrieben, hats geklappt.
>
> Ich musste bei mir auf dem ESP32 auch alles was ich davor laufen hatte
> rauswerfen, damit es drauf passt.
> Dann hat es aber super geklappt. Vielen Dank!
> Wäre es auch möglich mehr als einen dieser Antriebe an einem ESP32 zu
> betreiben?

Benutze als Basis den esp_32_ble_client von esphome. Der kann soweit ich 
das sehe nur eine Verbindung gleichzeitig.

Man könnte das natürlich alles noch selber programmieren. Halte ich aber 
für nicht so sinnvoll ^^


Ich hab leider aktuell das Problem, dass mein ESP32-C3 beim Verschlüssen 
abschmiert :/

Bin am überlegen, ob ich es Mal mit dem esp-idf Framework probiere 
anstelle des Arduino.

[Philipp C. (e61_phil)]

Dirk schrieb:
> Benutze als Basis den esp_32_ble_client von esphome. Der kann soweit ich
> das sehe nur eine Verbindung gleichzeitig.

Man kann dann ja einfach einen weiteren ESP32 verwenden.

Dirk schrieb:
> Ich hab leider aktuell das Problem, dass mein ESP32-C3 beim Verschlüssen
> abschmiert :/

Auf dem Tisch (ohne Schloss am Motor) funktioniert es bei mir mit einem 
D1.

[Hendrik F. (henfri)]

Hallo,

ich fänd es auch super, wenn mehrere Schlösser möglich wären.
Ich verstehe die Limitierung auf eine Verbindung gleichzeitig, aber war 
es nicht so, dass man ohnehin die Verbindung nur kurz aufbauen sollte, 
um die Batterien des Schloss zu schonen?

Wenn man dann mehrere Schlösser hat muss man doch nur die Verbindung zu 
dem gerade gewählten Schloss aufbauen.

Gruß,
Hendrik

[Dirk (digaus)]

Philipp C. schrieb:
> Dirk schrieb:
>> Benutze als Basis den esp_32_ble_client von esphome. Der kann soweit ich
>> das sehe nur eine Verbindung gleichzeitig.
>
> Man kann dann ja einfach einen weiteren ESP32 verwenden.
> Dirk schrieb:
>> Ich hab leider aktuell das Problem, dass mein ESP32-C3 beim Verschlüssen
>> abschmiert :/
>
> Auf dem Tisch (ohne Schloss am Motor) funktioniert es bei mir mit einem
> D1.

Jo mit nen normalen ESP32 klappt es bei mir ja auch :)

Der ESP32-C3 hat aber ne RISC-V CPU und keine XTensa wie der normale

Dafür kann unterstützt er nativ USB und ist kompakter :)

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
>
> ich fänd es auch super, wenn mehrere Schlösser möglich wären.
> Ich verstehe die Limitierung auf eine Verbindung gleichzeitig, aber war
> es nicht so, dass man ohnehin die Verbindung nur kurz aufbauen sollte,
> um die Batterien des Schloss zu schonen?
>
> Wenn man dann mehrere Schlösser hat muss man doch nur die Verbindung zu
> dem gerade gewählten Schloss aufbauen.
>
> Gruß,
> Hendrik

Wollte eine möglichst schnelle Reaktion haben. Deshalb aktuell die 
dauerhafte Verbindung.

Du hast mich aber zum Nachdenken gebracht.

Man könnte es ja so umsetzen, dass man einstellen kann, wann eine 
dauerhafte Verbindung erfolgen soll.

So könnte man die Verbindung z.B. trennen, wenn alle Personen zu Hause 
sind allgemeiner einfach Nachts.

Dies würde dann ja auch Energie sparen. Wenn ich das dann umsetze kann 
ich auch einen Service definieren, der die aktuell festen Parameter 
übernimmt.

So könnte man dann auch zwei Schlösser steuern via Home Assistant.


Hab es jetzt auch mit einem ESP32-C3 am laufen und die flash size 
nochmal verkleinert.

[Dirk (digaus)]

Hab die Änderungen einmal gepushed.

Wer Speicher sparen möchte kann das Framework auf esp-idf ändern. 
Dadurch spart man ca. 20%

ESP lief bei mir jetzt 6 Stunden durch ohne Verbindungsverlust.

Zwischendurch auch immer wieder Finger scannen lassen ohne Probleme.

Lediglich gerade eben hat er einige Sekunden gebraucht bis das Schloss 
reagiert hat. Könnte aber natürlich auch am Schloss gelegen haben, da 
beide Befehle nach einigen Sekunden doch ausgeführt wurden obwohl ich 
keine Message queue eingebaut habe.

[Artur K. (artur_k638)]

Dirk schrieb:
> Hab die Änderungen einmal gepushed.
>
> Wer Speicher sparen möchte kann das Framework auf esp-idf ändern.
> Dadurch spart man ca. 20%
>
> ESP lief bei mir jetzt 6 Stunden durch ohne Verbindungsverlust.
>
> Zwischendurch auch immer wieder Finger scannen lassen ohne Probleme.
>
> Lediglich gerade eben hat er einige Sekunden gebraucht bis das Schloss
> reagiert hat. Könnte aber natürlich auch am Schloss gelegen haben, da
> beide Befehle nach einigen Sekunden doch ausgeführt wurden obwohl ich
> keine Message queue eingebaut habe.

Was ist das für ein fingerscanner?

[Philipp C. (e61_phil)]

Dirk schrieb:
> Wollte eine möglichst schnelle Reaktion haben. Deshalb aktuell die
> dauerhafte Verbindung.

Das finde ich auch gerade richtig klasse. Bei der ursprünglichen Lösung 
mit dem Pi war es immer etwas irritierend, wenn man den Pin am 
Tastenfeld eingeben hat und erst einmal nichts passierte.
Dafür wechsel ich gern öfter die Batterie ;)

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Hab die Änderungen einmal gepushed.
>> Wer Speicher sparen möchte kann das Framework auf esp-idf ändern.
>> Dadurch spart man ca. 20%
>> ESP lief bei mir jetzt 6 Stunden durch ohne Verbindungsverlust.
>> Zwischendurch auch immer wieder Finger scannen lassen ohne Probleme.
>> Lediglich gerade eben hat er einige Sekunden gebraucht bis das Schloss
>> reagiert hat. Könnte aber natürlich auch am Schloss gelegen haben, da
>> beide Befehle nach einigen Sekunden doch ausgeführt wurden obwohl ich
>> keine Message queue eingebaut habe.
>
> Was ist das für ein fingerscanner?

Grow R503 den ich auseinander gebaut habe :)
Gibt's auch bei Amazon, falls man nicht auf AliExpress warten kann ;)

Kombiniert am Ende in einer Klingel

[Artur K. (artur_k638)]

Dirk schrieb:
> Grow R503 den ich auseinander gebaut habe :)
> Gibt's auch bei Amazon, falls man nicht auf AliExpress warten kann ;)
>
> Kombiniert am Ende in einer Klingel
Danke, möchte meine fingerabdruckleser in Doorbird (ekey) ersetzen. Da 
kann man bißchen testen. Wie zuverlässig ist der?

[Artur K. (artur_k638)]

Dirk schrieb:
> Hab die Änderungen einmal gepushed.
>
> Wer Speicher sparen möchte kann das Framework auf esp-idf ändern.
> Dadurch spart man ca. 20%
>
> ESP lief bei mir jetzt 6 Stunden durch ohne Verbindungsverlust.
>
> Zwischendurch auch immer wieder Finger scannen lassen ohne Probleme.
>
> Lediglich gerade eben hat er einige Sekunden gebraucht bis das Schloss
> reagiert hat. Könnte aber natürlich auch am Schloss gelegen haben, da
> beide Befehle nach einigen Sekunden doch ausgeführt wurden obwohl ich
> keine Message queue eingebaut habe.

Hi, heisst dass es jetzt immer Verbindung getrennt wird? Und ich habe 
gesehen dass du
external_components:
  source:
geändert hast, wenn ich es jetzt richtig verstehe, muss ich immer 
aktuellen Ordner von Github lokal kopieren?
Framework kann ich ja Arduino lassen, weil will nicht neu flashen, will 
nur als OTA machen.
Grüß

[Artur K. (artur_k638)]

Batterie als sensor wäre noch sehr gut, ich bin noch nicht gut in 
esphome, ich sehe es in Log aber wie man es rausholt, habe noch nicht 
rausgefunden.

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Hab die Änderungen einmal gepushed.
>> Wer Speicher sparen möchte kann das Framework auf esp-idf ändern.
>> Dadurch spart man ca. 20%
>> ESP lief bei mir jetzt 6 Stunden durch ohne Verbindungsverlust.
>> Zwischendurch auch immer wieder Finger scannen lassen ohne Probleme.
>> Lediglich gerade eben hat er einige Sekunden gebraucht bis das Schloss
>> reagiert hat. Könnte aber natürlich auch am Schloss gelegen haben, da
>> beide Befehle nach einigen Sekunden doch ausgeführt wurden obwohl ich
>> keine Message queue eingebaut habe.
>
> Hi, heisst dass es jetzt immer Verbindung getrennt wird? Und ich habe
> gesehen dass du
> external_components:
> source:
> geändert hast, wenn ich es jetzt richtig verstehe, muss ich immer
> aktuellen Ordner von Github lokal kopieren?
> Framework kann ich ja Arduino lassen, weil will nicht neu flashen, will
> nur als OTA machen.
> Grüß

ah sorry Pfad muss der alte dein von GitHub.

Lokal zeige ich auf den lokalen pfad damit ich nicht immer pushen muss 
um was zu testen.

Aktuell behält er noch die Verbindung. Ich werde aber noch einbauen, 
dass man diese trennen kann.


Bzgl Batterie wird es auch noch eingebaut. Lock Status ist ja auch noch 
nicht drin in HA. Packe da dann noch Rssi, Batterie und Status rein.

[Artur K. (artur_k638)]

Dirk schrieb:
>
> ah sorry Pfad muss der alte dein von GitHub.
>
> Lokal zeige ich auf den lokalen pfad damit ich nicht immer pushen muss
> um was zu testen.
>
> Aktuell behält er noch die Verbindung. Ich werde aber noch einbauen,
> dass man diese trennen kann.
>
>
> Bzgl Batterie wird es auch noch eingebaut. Lock Status ist ja auch noch
> nicht drin in HA. Packe da dann noch Rssi, Batterie und Status rein.

das habe ich mir gedacht, habe ich noch gelassen.
wegen Batterie, wie geht es überhaupt? frage nur weil ich es für mich 
persönlich interessant finde.

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Hab die Änderungen einmal gepushed.
>> Wer Speicher sparen möchte kann das Framework auf esp-idf ändern.
>> Dadurch spart man ca. 20%
>> ESP lief bei mir jetzt 6 Stunden durch ohne Verbindungsverlust.
>> Zwischendurch auch immer wieder Finger scannen lassen ohne Probleme.
>> Lediglich gerade eben hat er einige Sekunden gebraucht bis das Schloss
>> reagiert hat. Könnte aber natürlich auch am Schloss gelegen haben, da
>> beide Befehle nach einigen Sekunden doch ausgeführt wurden obwohl ich
>> keine Message queue eingebaut habe.
>
> Hi, heisst dass es jetzt immer Verbindung getrennt wird? Und ich habe
> gesehen dass du
> external_components:
> source:
> geändert hast, wenn ich es jetzt richtig verstehe, muss ich immer
> aktuellen Ordner von Github lokal kopieren?
> Framework kann ich ja Arduino lassen, weil will nicht neu flashen, will
> nur als OTA machen.
> Grüß

Habe soeben lokal die connect Funktion implementiert.

Braucht dann doch recht lange bis er sich verbunden und den Befehl 
ausgeführt hat. Sind so 12 Sekunden.


Damit sollte man aber auch verschiedene Schlösser ansprechen  können.

Denke für mich werde ich es so umsetzen, dass falls alle daheim sind der 
ESP die Verbindung trennt.

Sobald die Tür geöffnet wird oder eine Person nicht zu Hause ist der ESP 
eine Verbindung herstellt.

Artur K. schrieb:
> Dirk schrieb:
>> ah sorry Pfad muss der alte dein von GitHub.
>> Lokal zeige ich auf den lokalen pfad damit ich nicht immer pushen muss
>> um was zu testen.
>> Aktuell behält er noch die Verbindung. Ich werde aber noch einbauen,
>> dass man diese trennen kann.
>> Bzgl Batterie wird es auch noch eingebaut. Lock Status ist ja auch noch
>> nicht drin in HA. Packe da dann noch Rssi, Batterie und Status rein.
>
> das habe ich mir gedacht, habe ich noch gelassen.
> wegen Batterie, wie geht es überhaupt? frage nur weil ich es für mich
> persönlich interessant finde.

Habe ich mir noch nicht angeschaut ^^
Gibt leider wenig bis gar keine Doku. Ich schaue immer in anderen 
Komponenten nach, wie diese das umgesetzt haben 😅

[Artur K. (artur_k638)]

Dirk schrieb:
>
Ja das stimmt, konnte auch nichts finden. Für mich wäre nur akkustand 
wichtig.
Eine dauerhafte Verbindung waren in meinen Fall von Vorteil. Könnte man 
dann später auswählen ob man trennen möchte oder nicht?

[Thomas (type0n)]

Hey @digaus!

Schön das sich hier erneut etwas bewegt!

Deine Umsetzung setzt ja auf Home Assistant auf. Sowohl damit, als auch 
mit ESPHome habe ich leider keine/kaum Erfahrung.

Soweit ich deinen Code überblicke, könnte man den API Teil von HA 
rausnehmen und durch einen MQTT Broker ersetzte. Nun frage ich mich, ob 
man die von dir in HA genutzen/bereitgestellten Services des 
Schlossantriebs ohne die API über eine eingehende MQTT Nachricht 
aufrufen bzw. den Status via MQTT veröfftlichen könnte?

Damit könnte man dann auch ohne HA das Schloss ansprechen.

Hättest Du da bitte eine Tipp für mich?

Schönen Gruß
type0n

[Dirk (digaus)]

Thomas schrieb:
> Hey @digaus!
> Schön das sich hier erneut etwas bewegt!
> Deine Umsetzung setzt ja auf Home Assistant auf. Sowohl damit, als auch
> mit ESPHome habe ich leider keine/kaum Erfahrung.
> Soweit ich deinen Code überblicke, könnte man den API Teil von HA
> rausnehmen und durch einen MQTT Broker ersetzte. Nun frage ich mich, ob
> man die von dir in HA genutzen/bereitgestellten Services des
> Schlossantriebs ohne die API über eine eingehende MQTT Nachricht
> aufrufen bzw. den Status via MQTT veröfftlichen könnte?
> Damit könnte man dann auch ohne HA das Schloss ansprechen.
> Hättest Du da bitte eine Tipp für mich?
> Schönen Gruß
> type0n

Esphome funktioniert auch standalone.


MQTT kann einfach mit dem MQTT Client eingebunden werden:

https://esphome.io/components/mqtt.html#on-message-trigger

Hab die Version auf GitHub mit der connect und disconnect Funktion 
aktualisiert.

Mac Adresse kann man leider nicht via template weitergeben. Man muss 
also mehrere Connect services definieren wenn man mehrere Schlösser 
verwenden möchte.

[Thomas (type0n)]

Hallo nochmal!

Ich habe mal etwas herumprobiert und konnte den API Teil gegen eine MQTT 
Broker Verbindung ersetzen (yaml ist völlig neu für mich).

Den Aufruf der Service Funktionen habe ich auch hinbekommen.
Durch einen MQTT Subscriber Sensor bekomme ich externe Befehle zum ESP 
und kann damit bis jetzt lock/unlock/open/status auslösen.

Jetzt fehlen nur noch Pairing und Batteriestatus, dann wäre diese Lösung 
für mich schon fast voll einsatzfähig!

Am Broker sehe ich nun mehrere Topics. Ohne die, die ich eingefügt habe 
published der ESP das Topic status und debug.

Via debug kommt alles an, was auch über den Logger geht.
Darin sind dann auch aktueller Status und Batteriestatus enthalten.

Wenn der Status bei jeder Änderung gepublished werde könnten, könnte man 
auch die manuelle Bedienung erkennen.

Wenn dabei auch noch der Batteriestatus kommt, optimal!

Hat da jemend eine Idee wie man das realsieren/wo man da ansetzen 
könnte?

Schönen Gruß
type0n

[Dirk (digaus)]

Thomas schrieb:
> Hallo nochmal!
> Ich habe mal etwas herumprobiert und konnte den API Teil gegen eine MQTT
> Broker Verbindung ersetzen (yaml ist völlig neu für mich).
> Den Aufruf der Service Funktionen habe ich auch hinbekommen.
> Durch einen MQTT Subscriber Sensor bekomme ich externe Befehle zum ESP
> und kann damit bis jetzt lock/unlock/open/status auslösen.
> Jetzt fehlen nur noch Pairing und Batteriestatus, dann wäre diese Lösung
> für mich schon fast voll einsatzfähig!
> Am Broker sehe ich nun mehrere Topics. Ohne die, die ich eingefügt habe
> published der ESP das Topic status und debug.
> Via debug kommt alles an, was auch über den Logger geht.
> Darin sind dann auch aktueller Status und Batteriestatus enthalten.
> Wenn der Status bei jeder Änderung gepublished werde könnten, könnte man
> auch die manuelle Bedienung erkennen.
> Wenn dabei auch noch der Batteriestatus kommt, optimal!
> Hat da jemend eine Idee wie man das realsieren/wo man da ansetzen
> könnte?
> Schönen Gruß
> type0n

Nicht so eilig, kommt alles noch 😉

Pairing geht aber schon. Gibt dafür den pair Service. Kannst du dir aus 
der yaml abschauen.

[Dirk (digaus)]

Thomas schrieb:

> Wenn der Status bei jeder Änderung gepublished werde könnten, könnte man
> auch die manuelle Bedienung erkennen.
> Wenn dabei auch noch der Batteriestatus kommt, optimal!
> Hat da jemend eine Idee wie man das realsieren/wo man da ansetzen
> könnte?
> Schönen Gruß
> type0n

Habe es so eben aktualisiert. Status und Batteriezustand werden jetzt 
über die Sensor Komponente ausgegeben.

Werde da wahrscheinlich noch die User ID und den User Key vom Pairing 
Prozess mit ausgeben

Beispiel steht in der yaml :)

[Dirk (digaus)]

Hat hier noch jemand das Problem, dass das Schloss beim öffnen nicht von 
alleine stoppt? Hört sich dann richtig brutal an wie er versucht immer 
weiter zu drehen obwohl es nicht mehr geht.

Muss dann die Batterie entfernen ...

Hab das Schloss nämlich soeben das erste mal montiert. Getestet mit der 
iOS App...

Ist es vllt einfach Pech und ich habe ein defektes erwischt?

[Artur K. (artur_k638)]

Dirk schrieb:
>
> Habe es so eben aktualisiert. Status und Batteriezustand werden jetzt
> über die Sensor Komponente ausgegeben.
>
> Werde da wahrscheinlich noch die User ID und den User Key vom Pairing
> Prozess mit ausgeben
>
> Beispiel steht in der yaml :)
in Zeile 35 schimpft er wegen number "Unknown value 'number', valid 
options are 'bool', 'int', 'float', 'string', 'bool[]', 'int[]', 
'float[]', 'string[]'."

und ist es richtig, dass es 2 mal service: connect gibt?

passt nicht in esp32 4mb

Error: The program size (1836437 bytes) is greater than maximum allowed 
(1835008 bytes)
*** [checkprogsize] Explicit exit, status 1

[Artur K. (artur_k638)]

Wer kann mir sagen was das bedeuten soll?
Log:
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:6608
load:0x40078000,len:15060
ho 0 tail 12 room 4
load:0x40080400,len:3816
entry 0x40080698
I (29) boot: ESP-IDF 4.4.5 2nd stage bootloader
I (29) boot: compile time 19:23:39
I (29) boot: chip revision: v3.1
I (32) boot.esp32: SPI Speed      : 40MHz
I (37) boot.esp32: SPI Mode       : DIO
I (41) boot.esp32: SPI Flash Size : 4MB
I (46) boot: Enabling RNG early entropy source...
I (51) boot: Partition Table:
I (55) boot: ## Label            Usage          Type ST Offset   Length
I (62) boot:  0 otadata          OTA data         01 00 00009000 
00002000
I (70) boot:  1 phy_init         RF data          01 01 0000b000 
00001000
I (77) boot:  2 app0             OTA app          00 10 00010000 
001c0000
I (85) boot:  3 app1             OTA app          00 11 001d0000 
001c0000
I (92) boot:  4 nvs              WiFi data        01 02 00390000 
0006d000
I (100) boot: End of partition table
I (104) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=44fe4h 
(282596) map
I (215) esp_image: segment 1: paddr=0005500c vaddr=3ffbdb60 size=04c64h 
( 19556) load
I (222) esp_image: segment 2: paddr=00059c78 vaddr=40080000 size=063a0h 
( 25504) load
I (233) esp_image: segment 3: paddr=00060020 vaddr=400d0020 size=105fc4h 
(1073092) map
I (622) esp_image: segment 4: paddr=00165fec vaddr=400863a0 size=16e98h 
( 93848) load
I (675) boot: Loaded app from partition at offset 0x10000
I (675) boot: Disabling RNG early entropy source...
I (686) cpu_start: Pro cpu up.
I (687) cpu_start: Starting app cpu, entry point is 0x40082180
I (0) cpu_start: App cpu up.
I (703) cpu_start: Pro cpu start user code
I (703) cpu_start: cpu freq: 160000000
I (703) cpu_start: Application information:
I (707) cpu_start: Project name:     eqiva-lock
I (713) cpu_start: App version:      2023.11.6
I (718) cpu_start: Compile time:     Dec  4 2023 19:22:45
I (724) cpu_start: ELF file SHA256:  7f5fa95f0b16a391...
I (730) cpu_start: ESP-IDF:          4.4.5
I (735) cpu_start: Min chip rev:     v0.0
I (739) cpu_start: Max chip rev:     v3.99
I (744) cpu_start: Chip rev:         v3.1
I (749) heap_init: Initializing. RAM available for dynamic allocation:
I (756) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (762) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (768) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (774) heap_init: At 3FFCB9F0 len 00014610 (81 KiB): DRAM
I (780) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (787) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (793) heap_init: At 4009D238 len 00002DC8 (11 KiB): IRAM
I (801) spi_flash: detected chip: generic
I (804) spi_flash: flash io: dio
I (810) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Habe es so eben aktualisiert. Status und Batteriezustand werden jetzt
>> über die Sensor Komponente ausgegeben.
>> Werde da wahrscheinlich noch die User ID und den User Key vom Pairing
>> Prozess mit ausgeben
>> Beispiel steht in der yaml :)
>
> in Zeile 35 schimpft er wegen number "Unknown value 'number', valid
> options are 'bool', 'int', 'float', 'string', 'bool[]', 'int[]',
> 'float[]', 'string[]'."
> und ist es richtig, dass es 2 mal service: connect gibt?
> passt nicht in esp32 4mb
> Error: The program size (1836437 bytes) is greater than maximum allowed
> (1835008 bytes)
> *** [checkprogsize] Explicit exit, status 1

Jap zweiten Service entfernen. Hab's auch angepasst.

Bzgl Code size lässt sich nicht viel machen. Der BLE Stack verbraucht 
hier sehr viel Speicher. Da hilft es nur das Framework auf esp-idf 
umzustellen so wie es auch in der Beispiel yaml ist.

Damit verbraucht er nur 81% des Speichers.

[Artur K. (artur_k638)]

Dirk schrieb:
> Bzgl Code size lässt sich nicht viel machen. Der BLE Stack verbraucht
> hier sehr viel Speicher. Da hilft es nur das Framework auf esp-idf
> umzustellen so wie es auch in der Beispiel yaml ist.

ok dann muss ich wohl mit Kabel flashen. Danke

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Bzgl Code size lässt sich nicht viel machen. Der BLE Stack verbraucht
>> hier sehr viel Speicher. Da hilft es nur das Framework auf esp-idf
>> umzustellen so wie es auch in der Beispiel yaml ist.
>
> ok dann muss ich wohl mit Kabel flashen. Danke

Warum? Geht doch auch ganz normal via OTA?

[Artur K. (artur_k638)]

Dirk schrieb:
> Warum? Geht doch auch ganz normal via OTA?

Oooo habe mal gelesen, dass wenn man framework ändert, muss man komplett 
neu flashen. Gut zu wissen, Danke

[Artur K. (artur_k638)]

Dirk schrieb:
Könnte man nicht bei battery Status statt 1 und 0, true und false 
benutzen?

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
> Könnte man nicht bei battery Status statt 1 und 0, true und false
> benutzen?

Hab's jetzt generell auf text_sensor umgestellt. So ist es auch 
sprechender. Zusätzlich zum Lock Status und Batterie wird jetzt auch 
noch der BLE Status mit angezeigt/ausgegebenen

[Philipp C. (e61_phil)]

Nachdem es beim ersten Test so gut lief habe ich mir noch so ein Schloss 
besorgt.

Leider funktioniert es bei mir in der aktuellsten Version gar nicht 
mehr.

Der ESP32 scheint immer wieder zu crashen:

WARNING esphome-web-350990: Connection error occurred: [Errno 104] 
Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for 
esphome-web-350990
WARNING Disconnected from API
WARNING Can't connect to ESPHome API for esphome-web-350990: Error 
connecting to ('192.168.2.66', 6053): [Errno 111] Connect call failed 
('192.168.2.66', 6053) (SocketAPIError)
INFO Trying to connect to esphome-web-350990 in the background

[Dirk (digaus)]

Philipp C. schrieb:
> Nachdem es beim ersten Test so gut lief habe ich mir noch so ein
> Schloss besorgt.
> Leider funktioniert es bei mir in der aktuellsten Version gar nicht
> mehr.
> Der ESP32 scheint immer wieder zu crashen:
> WARNING esphome-web-350990: Connection error occurred: [Errno 104]
> Connection reset by peer
> INFO Processing unexpected disconnect from ESPHome API for
> esphome-web-350990
> WARNING Disconnected from API
> WARNING Can't connect to ESPHome API for esphome-web-350990: Error
> connecting to ('192.168.2.66', 6053): [Errno 111] Connect call failed
> ('192.168.2.66', 6053) (SocketAPIError)
> INFO Trying to connect to esphome-web-350990 in the background

Nutzt du esp-idf?

Ansonsten nimm mal "scan_parameter" raus.

[Philipp C. (e61_phil)]

Dirk schrieb:
> Nutzt du esp-idf?
>
> Ansonsten nimm mal "scan_parameter" raus.

Der erste Versuch war noch mit Android, aber das scheint nun nicht mehr 
zu passen und ich bin auf esp-idf gegangen.

Ich probiere es mal ohne scan_parameter

Edit: Das hat nichts gebracht. Es sieht so aus, als würde der Aufruf des 
pair services zuverlässig den crash auslösen.

[Dirk (digaus)]

Philipp C. schrieb:
> Dirk schrieb:
>> Nutzt du esp-idf?
>> Ansonsten nimm mal "scan_parameter" raus.
>
> Der erste Versuch war noch mit Android, aber das scheint nun nicht mehr
> zu passen und ich bin auf esp-idf gegangen.
> Ich probiere es mal ohne scan_parameter
> Edit: Das hat nichts gebracht. Es sieht so aus, als würde der Aufruf des
> pair services zuverlässig den crash auslösen.

Jo sorry pair hab ich kaputt gemacht.

Funktioniert in der neusten Version wieder. 🙃

Wichtig, keine user_id bzw user_key mitgegeben wenn man pairen möchte.

Diese werden jetzt auch mit zurück geliefert und man sich diese in der 
Weboberfläche anzeigen lassen beim pairen :)

[Artur K. (artur_k638)]

Dirk schrieb:
> Hab's jetzt generell auf text_sensor umgestellt. So ist es auch
> sprechender. Zusätzlich zum Lock Status und Batterie wird jetzt auch
> noch der BLE Status mit angezeigt/ausgegebenen

Wie pushe ich neue Komponenten? Der zeigt mir Platform not found: 
'text_sensor.eqiva_key_ble'.

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Hab's jetzt generell auf text_sensor umgestellt. So ist es auch
>> sprechender. Zusätzlich zum Lock Status und Batterie wird jetzt auch
>> noch der BLE Status mit angezeigt/ausgegebenen
>
> Wie pushe ich neue Komponenten? Der zeigt mir Platform not found:
> 'text_sensor.eqiva_key_ble'.

https://esphome.io/components/external_components.html#external-components-refresh

[Artur K. (artur_k638)]

Dirk schrieb:
> 
https://esphome.io/components/external_components.html#external-components-refresh

Oh stimmmt, darauf noch nicht gekommen, danke

Hätte einen Vorschlag, möchtest du nicht einen lock component einbauen?

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>>
> 
https://esphome.io/components/external_components.html#external-components-refresh
>
> Oh stimmmt, darauf noch nicht gekommen, danke
> Hätte einen Vorschlag, möchtest du nicht einen lock component einbauen?

Ja definitiv :)

Bin gerade noch dabei die Einstellungen zu implementieren. Dann bräuchte 
man die App nicht mehr ;)

Edit: und Einstellungen erfolgreich getestet :)

Man kann jetzt Drehrichtung, Schlüsselposition und Anzahl Drehung 
einstellen.

Mache eben noch nen Service dann pushe ich das 🙃

[Hendrik F. (henfri)]

Unglaublich, wie es voran geht.

Funktionieren schon zwei Schlösser? Dann könnte ich meinen Raspi Zero in 
Rente schicken.

[Dirk (digaus)]

Hendrik F. schrieb:
> Unglaublich, wie es voran geht.
> Funktionieren schon zwei Schlösser? Dann könnte ich meinen Raspi Zero in
> Rente schicken.

Sollte möglich sein indem du erst disconnect und dann connect mit den 
passenden Parametern aufrufst.

D.h. gesteuert wird immer das aktuell verbundene Schloss.


Habe das Anpassen der Einstellungen jetzt auch veröffentlicht (muss hier 
die lock_turns noch validieren, nicht dass einer was anderes als 1-4 
einträgt)

[Hendrik F. (henfri)]

Hm, planst du denn noch meherere Schlösser voll zu integrieren?

So wie es jetzt ist, wäre ja immer nur ein Schloss - und dessen Status - 
im Gui sichtbar, oder?

Wünschenswert wäre, wenn mehrere Schlösser hinsichtlich ihres Status - 
und auch aktuierbar - wären und wenn diese in einem konfigurierbaren 
Zyklus abgefragt würden (z.B. Status update alle 300s sowie unmittelbar 
nach jedem Kommando).

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hm, planst du denn noch meherere Schlösser voll zu integrieren?
> So wie es jetzt ist, wäre ja immer nur ein Schloss - und dessen Status -
> im Gui sichtbar, oder?
> Wünschenswert wäre, wenn mehrere Schlösser hinsichtlich ihres Status -
> und auch aktuierbar - wären und wenn diese in einem konfigurierbaren
> Zyklus abgefragt würden (z.B. Status update alle 300s sowie unmittelbar
> nach jedem Kommando).
> Gruß,
> Hendrik

Was ist denn dein Ziel? Möchtest du nur die Stati der Schlösser sehen 
oder möchtest du diese auch ansteuern?

Wenn ansteuern wie sieht da der Usecase aus? Ist das zeitkritisch?


Man könnte es so anpassen, dass man eine Liste an mac/user_id/user_key 
mit gibt und dann bei jedem Aufruf nen Parameter hinzufügen mit der Mac 
Adresse.

Wäre ziemlicher Aufwand das so zu programmieren.

Würde da wahrscheinlich eher auf einen zweiten ESP gehen, auch in Bezug 
auf die BLE Reichweite.

[Hendrik F. (henfri)]

Hallo,

der Usecase ist, dass ich zwei Schlösser in unmittelbarer Nähe habe, so 
dass beide leicht von einem ESP ansteuerbar sind.
Ich bin da so wie ich das oben lese nicht der Einzige.
Ich verstehe aber, wenn das zu viel Aufwand ist.

Ich hatte es mir so vorgestellt, dass der ESP wirklich zwei/N Schlösser 
in HA darstellt, so dass HA gar nicht merkt, dass ein ESP zwei Schlösser 
ansteuert - und v.a. meine Frau nicht :-)

Das bedeutet natürlich, dass der ESP eine Kommunkiationsqueue braucht 
für die Funk-Kommandos.

Das Ansteuern ist nicht so zeitkritisch - wir nutzen es v.a. um die 
Schlösser abzuschließen wenn wir es vergessen haben. Wenn du aber eine 
so gute Arbeit machst, dass man die App nicht mehr nutzt, kann ich mir 
vorstellen, dass man auch HA zum aufschließen nutzt. Dann wäre es 
natürlich blöd, wenn es lange dauert - mit der App dauert es aber auch 
mehrere Sekunden.

> Man könnte es so anpassen, dass man eine Liste an mac/user_id/user_key
> mit gibt und dann bei jedem Aufruf nen Parameter hinzufügen mit der Mac
> Adresse.

Siehe oben: Ich hätte gedacht, dass man einfach mehere Schlösser 
"emuliert".

Übrigens: Der Status ist in meinen Augen nicht besonders wichtig, da er 
eh unzuverlässig ist: Wenn die Tür nicht zu ist, und das Schloss aber 
"abschließt" dann bringt das garnix. Deshalb habe ich einen Taster im 
Türrahmen, der vom Riegel gedrückt wird.

Gruß,
Hendrik

[Hendrik F. (henfri)]

Hallo,

beim Installieren bekomme ich einen Fehler:

> Failed config
>
>eqiva_key_ble: [source /config/esphome/esphome-web-8bf1d4.yaml:96]
>
>  value must be at most 8.
>  id: key_ble

Habe ich da etwas falsch verstanden?

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> beim Installieren bekomme ich einen Fehler:
>> Failed config
>> eqiva_key_ble: [source /config/esphome/esphome-web-8bf1d4.yaml:96]
>> value must be at most 8.
>> id: key_ble
>
> Habe ich da etwas falsch verstanden?
> Gruß,
> Hendrik

Poste mal deine yaml

Die max 8 habe ich bei user_id hinterlegt aber nicht bei der id


Edit: ok du lässt die user\id weg das sollte auch möglich sein

Schaue es mir an

[Artur K. (artur_k638)]

Hi, wie ist es eigentlich momentan. Besteht dauerhafte Verbindung? Wenn 
nicht wich lasse ich es dauerhaft verbunden?

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> beim Installieren bekomme ich einen Fehler:
>> Failed config
>> eqiva_key_ble: [source /config/esphome/esphome-web-8bf1d4.yaml:96]
>> value must be at most 8.
>> id: key_ble
>
> Habe ich da etwas falsch verstanden?
> Gruß,
> Hendrik

Hab's gefixed


Übrigens könntest du dir die beiden Schlösser in der yaml definieren mit 
nem Lock Template (siehe Foto)

[Dirk (digaus)]

Artur K. schrieb:
> Hi, wie ist es eigentlich momentan. Besteht dauerhafte Verbindung?
> Wenn nicht wich lasse ich es dauerhaft verbunden?

Ja ist dauerhaft verbunden.

Hab auch vergessen beim manuellen disconnect die Daten rausschmeißen. 
Dadurch verbindet er sich denke ich immer wieder mit dem zuletzt 
verbundenen.

[Hendrik F. (henfri)]

Hallo,

der Fix funktioniert.
Mir fehlt jetzt noch etwas Dokumentation. Ich weiß nicht, wie ich jetzt 
die Bedienung mache (ich finde das Gerät nicht unter meinen Entitäten).

> Übrigens könntest du dir die beiden Schlösser in der yaml definieren mit
> nem Lock Template (siehe Foto)

D.h. ich würde den Part aus deinem Screenshot zweimal einfügen (mit 
unterschiedlichem Namen)?

Und dann gäbe es zwei Entitäten für das Schloss?

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> der Fix funktioniert.
> Mir fehlt jetzt noch etwas Dokumentation. Ich weiß nicht, wie ich jetzt
> die Bedienung mache (ich finde das Gerät nicht unter meinen Entitäten).
>> Übrigens könntest du dir die beiden Schlösser in der yaml definieren mit
>> nem Lock Template (siehe Foto)
>
> D.h. ich würde den Part aus deinem Screenshot zweimal einfügen (mit
> unterschiedlichem Namen)?
> Und dann gäbe es zwei Entitäten für das Schloss?
> Gruß,
> Hendrik

Hab ein Beispiel hochgeladen und den Code nochmal aktualisiert.

Kann es natürlich nicht testen, da ich nur ein Schloss habe.

Mit den beiden Lock Templates sollten aber beide Schlösser in HA 
auftauchen


Für schneller Verbindung kannst du die scan window auf 300ms setzen

Aber bedenke, gleichzeitig ausführen wird zu Problemem führen :)

[Philipp C. (e61_phil)]

Hier geht es ja ab :) Bei jedem Install gibt es eine neue Version

Leider startet mein ESP seit der letzten offenbar gar nicht mehr. Es 
geht nicht mehr bis zum logger :(

[Dirk (digaus)]

Philipp C. schrieb:
> Hier geht es ja ab :) Bei jedem Install gibt es eine neue Version
> Leider startet mein ESP seit der letzten offenbar gar nicht mehr. Es
> geht nicht mehr bis zum logger :(

esp-idf?

[Philipp C. (e61_phil)]

Dirk schrieb:
> esp-idf?

Ja, aber ich habe nun noch mal das aktuelle yaml kopiert. Passte meins 
ggf. nicht mehr zum Rest? Ich hatte refresh auf 0s stehen. Pairing ging, 
dann wollte ich ein neues install machen mit Key und ID und damit kam er 
nicht mehr hoch.

Nun habe ich Key und ID wieder raus und versuche es mit dem Connect 
Service. Gemeldet hat er sich schon mal wieder

[Hendrik F. (henfri)]

Dirk schrieb:

> Hab ein Beispiel hochgeladen und den Code nochmal aktualisiert.

Danke!
Verwirrend ist, dass die MAC von dem einen Schloss außerhalb des 
Template definiert wird.

eqiva_key_ble:
  id: key_ble
  # Below are optional and can be passed via new connect service
  mac_address: 00:12:34:56:42:88
  user_id: 0
  user_key: 12345678636F6763386A726E33746F35

Vom zweiten aber nur im Template.

Wo wird denn vom zweiten Lock User und key definiert?

> Für schneller Verbindung kannst du die scan window auf 300ms setzen
>
> Aber bedenke, gleichzeitig ausführen wird zu Problemem führen :)

Definiere "gleichzeitig" :-)

Kann man eigentlich in der yaml "Platzhalter" definieren, um die sich 
wiederholenden Mac-Adressen zu vermeiden? Nihct aus Faulheit, sondern 
weil es Fehlerträchtig ist.

Gruß,
Hendrik

[Philipp C. (e61_phil)]

Philipp C. schrieb:
> Nun habe ich Key und ID wieder raus und versuche es mit dem Connect
> Service. Gemeldet hat er sich schon mal wieder

hmm, das ging nun auch. Wohl eher ein Fehler auf meiner Seite.

Wie ist es mit dem Key und der ID denn gedacht? Man scheint den connect 
Service ja nicht zu benötigen, wenn man hier alles einträgt:

eqiva_key_ble:
  id: key_ble
  # Below are optional and can be passed via new connect service
  mac_address: 00:1A:xxx
  user_id: 4
  user_key: xxxxx

Wird man die ganzen User IDs von den Pairing Versuchen eigentlich 
irgendwie wieder los?

Echt super, dass man dieses Schloss nun so zügig ansprechen kann.

[Hendrik F. (henfri)]

Hallo,

hab jetzt verstanden, wie das zweite Lock definiert wird.

Aber kann das dann nicht weg?

>eqiva_key_ble:
>  id: key_ble
>  # Below are optional and can be passed via new connect service
>  mac_address: 00:1a:...
>  user_id: 1
>  user_key: xxx

Es kompiliert leider aktuell nicht:
https://pastebin.com/vdeGGEtq

Könntest du da einmal gucken, bitte?

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> hab jetzt verstanden, wie das zweite Lock definiert wird.
> Aber kann das dann nicht weg?
>> eqiva_key_ble:
>> id: key_ble
>> Below are optional and can be passed via new connect service
>> mac_address: 00:1a:...
>> user_id: 1
>> user_key: xxx
>
> Es kompiliert leider aktuell nicht:
> https://pastebin.com/vdeGGEtq
> Könntest du da einmal gucken, bitte?
> Gruß,
> Hendrik

Zwei Schlösser gehen wenn du die Parameter via connect mitgiebts. Dann 
solltest du es nicht in der Initialen config mitgeben.

Wenn man nur ein Schloss dauerhaft verbunden haben möchte nutzt man 
einfach die config. Dann braucht man die connect/disconnect Funktion 
nicht.

[Hendrik F. (henfri)]

Verstanden.

Hast du eine Idee, warum er nicht kompiliert (siehe mein pastebin)?

Gruß und danke für die tolle Entwicklung,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Verstanden.
> Hast du eine Idee, warum er nicht kompiliert (siehe mein pastebin)?
> Gruß und danke für die tolle Entwicklung,
> Hendrik

Joa einmal die Build Files clearen
(In der Übersicht auf die drei Punkte klicken)

[Dirk (digaus)]

Hab in die yaml noch ne Time Komponente gepackt die alle 4 Minuten den 
Status abruft. Hab im Log nämlich festgestellt, dass nach ~5min 
Inaktivität das Schloss wohl die Verbindung abbricht?

Konntet ihr das auch beobachten?

[Philipp C. (e61_phil)]

Dirk schrieb:
> Hab in die yaml noch ne Time Komponente gepackt die alle 4 Minuten den
> Status abruft. Hab im Log nämlich festgestellt, dass nach ~5min
> Inaktivität das Schloss wohl die Verbindung abbricht?
>
> Konntet ihr das auch beobachten?

Ja, siehe Anhang. Mein ESP scheint dabei dann auch die Verbindung zum 
logger zu verlieren.

Zudem habe ich gerade festgestellt, dass der unlock service bei mir gar 
nicht funktioniert. Ich hatte bisher nur mit lock und open gespielt. Da 
ist alles ok. Bei unlock passiert jedoch gar nichts.

[Hendrik F. (henfri)]

Hallo,

ich habe nie eine dauerhafte Verbindung gehabt.
Aber mit dem originalen keyble kannst du das gegentesten um 
auszuschließen, dass es am ESP liegt. Du musst --auto_disconnect_time 0 
wählen.

Ich habe jetzt erfolgreich kompiliert und meine zwei Locks im 
HomeAssistant.
Eins habe ich auch schon zum Aufschließen bekommen.
Danach war aber auf einmal das Lock (und auch die Firmware-Entität) 
"nicht verfügbar"

Im "Logbuch" sieht man auch
equiva Controller Firmware ausgeschaltet
equiva Controller nicht mehr verfügbar
(immer wieder)

Der Ping sieht aber gut aus.

Ping-Statistik für 192.168.177.1:
    Pakete: Gesendet = 29796, Empfangen = 29707, Verloren = 89
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 3700ms, Mittelwert = 7ms

In der Seriellen Konsole sieht auch alles gut aus. Außer gelegentliche
[I][wifi:286]: WiFi Connecting to 'FriedelNetz'...
[W][wifi_esp32:458]: Event: Disconnected ssid='FNetz' 
bssid=aa:22:bb:24:DE:F1 reason='Auth Expired'
[W][wifi:604]: Error while connecting to network.
[W][wifi:640]: Restarting WiFi adapter...
[I][wifi:286]: WiFi Connecting to 'FriedelNetz'...
[W][wifi_esp32:458]: Event: Disconnected ssid='FNetz' 
bssid=aa:22:bb:24:DE:F1 reason='Auth Expired'
[W][wifi:604]: Error while connecting to network.
[W][wifi:640]: Restarting WiFi adapter...

Aber z.B. jetzt gerade sind die Elemente vom ESP in HA nicht verfügbar 
(grau) obwohl in der seriellen Konsole
[I][wifi:286]: WiFi Connecting to 'FNetz'...
[I][wifi:573]: WiFi Connected!
[C][wifi:391]:   Local MAC: aa:71:bb:8B:F1:D4
[C][wifi:396]:   SSID: 'FriedelNetz'

steht (beachte: die MAC ist eine andere; vermutlich ein anderer AP)


Hast du eine Idee?

Gruß,
Hendrik

[Dirk (digaus)]

Philipp C. schrieb:
> Dirk schrieb:
>> Hab in die yaml noch ne Time Komponente gepackt die alle 4 Minuten den
>> Status abruft. Hab im Log nämlich festgestellt, dass nach ~5min
>> Inaktivität das Schloss wohl die Verbindung abbricht?
>> Konntet ihr das auch beobachten?
>
> Ja, siehe Anhang. Mein ESP scheint dabei dann auch die Verbindung zum
> logger zu verlieren.
> Zudem habe ich gerade festgestellt, dass der unlock service bei mir gar
> nicht funktioniert. Ich hatte bisher nur mit lock und open gespielt. Da
> ist alles ok. Bei unlock passiert jedoch gar nichts.

Einmal neuste Version verwenden. Der hatte noch beim reconnect 
gecrashed.

D.h. WiFi sollte trotzdem verbunden bleiben, nur BLE verliert die 
Verbindung.


Das mit dem unlock habe ich auch schon festgestellt.

Dachte es liegt vllt am Schloss Weil ich es noch nicht montiert habe. 
Geht das unlock denn mit der nodejs Version oder der anderen ESP32 
Version?

Befehl wird nämlich korrekt abgesendet so wie ich das sehe.

[Hendrik F. (henfri)]

Hallo,

hast du auch eine Idee für mein Problem?

Gruß,
Hendrik

[Philipp C. (e61_phil)]

Dirk schrieb:
> Das mit dem unlock habe ich auch schon festgestellt.
>
> Dachte es liegt vllt am Schloss Weil ich es noch nicht montiert habe.
> Geht das unlock denn mit der nodejs Version oder der anderen ESP32
> Version?
>
> Befehl wird nämlich korrekt abgesendet so wie ich das sehe.

Das scheint tatsächlich das Problem zu sein. Ich habe es mal an die Tür 
angebaut und da tut sich was. Nun zeigt er noch "JAMMED" an, wenn ich 
abschließe, aber das ist wohl ein anderes Problem und hat weniger mit 
der ESP Software zu tun :)

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> hast du auch eine Idee für mein Problem?
> Gruß,
> Hendrik

Welchen ESP hast du? Neueste Version vom Code? Clean Build gemacht?

[Hendrik F. (henfri)]

Clean Build = vorher die Daten gelöscht? Ja (vorher ging der Build ja 
nicht).
Version vom Code: Von heute morgen. Ich baue aber nochmal.
Das ESP Modul ist dieses 
https://codedocu.de/Sonstiges/Hardware/Arduino/ESP32-Board--von-AZDelivery-unter-ESP32-NodeMCU-Development-Kit?3091

Ich glaube, der ESP crasht beim betätigen von "Lock":

Error reading from serial device


ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13132
load:0x40080400,len:3036
entry 0x400805e4

[I][logger:326]: Log initialized
[C][ota:473]: There have been 1 suspected unsuccessful boot attempts.

Das komische ist, dass danach im Log alles normal aussieht. Aber der 
ESP/das Schloss bleibt grau. Es wurde erst nach einem erneuten 
Kompilieren wieder nutzbar - mag Zufall sein.

Gruß,
Hendrik

[Hendrik F. (henfri)]

Hallo,

ich habe jetzt mal zurückgerüstet auf ein Lock und kann jetzt auch die 
Kommunikation zum Lock im Log sehen.
Allerdings fehlen mir die Steuerelemente um das Schloss zu bedienen. 
Woran kann das liegen?

Gruß,
Hendrik

[Philipp C. (e61_phil)]

Hendrik F. schrieb:
> Allerdings fehlen mir die Steuerelemente um das Schloss zu bedienen.
> Woran kann das liegen?

Die kommen eigentlich, wenn Du so ein Template Lock anlegst. Wie sieht 
denn dein yaml aktuell aus?

[Hendrik F. (henfri)]

Hallo,

oh, ich dachte das lock-template wäre nur bei zwei Schlössern nötig.
Ich habe das jetzt wieder hinzugefügt und damit funktioniert es jetzt - 
einigermaßen.

Was mir nicht klar ist: Wo soll ich das Schloss im Schloss-Popup 
bedienen? Am vertikalen "Slider", oder auf dem Knopf darunter?
Ich habe das Schloss bedienen können, aber es reagiert nicht immer. 
Zudem wird der Status nicht aktualisiert. Der Slider bleibt rot und der 
Text-Status bleibt "aufgeschlossen".

Hier meine Konfiguration:

esphome:
  name: esphome-web-8bf1d4
  friendly_name: equiva Controller
esp32:
  board: esp32dev
  framework:
    type: esp-idf

# Enable logging
logger:
  
# Enable Home Assistant API
api:
  encryption:
    key: "V/xx="
  services:
  - service: settings
    variables:
      turn_left: bool
      key_horizontal: bool
      lock_turns: int
    then:
      - eqiva_key_ble.settings:
          turn_left: !lambda 'return turn_left;'
          key_horizontal: !lambda 'return key_horizontal;'
          lock_turns: !lambda 'return lock_turns;'
  - service: connect
    variables:
      # mac_address: string // Unable to pass a mac_address via lambda :?
      user_id: int
      user_key: string
    then:
      - eqiva_key_ble.connect:
          mac_address: 32:20:50:56:42:88
          # mac_address: !lambda 'return mac_address;'
          user_id: !lambda 'return user_id;'
          user_key: !lambda 'return user_key;'
  - service: disconnect
    then:
      - eqiva_key_ble.disconnect:
  - service: pair
    variables:
      card_key: string
    then:
      - eqiva_key_ble.pair:
          card_key: !lambda 'return card_key;'
  - service: lock
    then:
      - eqiva_key_ble.lock:
  - service: unlock
    then:
      - eqiva_key_ble.unlock:
  - service: open
    then:
      - eqiva_key_ble.open:
  - service: status
    then:
      - eqiva_key_ble.status:
ota:

wifi:
  ssid: FNetz
  password: paass

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Web-8Bf1D4"
    password: "paaas"

web_server:
  include_internal: true
  local: true
  port: 80


captive_portal:
    
external_components:
  source: github://digaus/esphome-components-eqiva
  # use refresh when you do not get latest version
  refresh: 0s

esp32_ble_tracker:
  # scan_parameters:
  #  window: 300ms

eqiva_ble:

eqiva_key_ble:
  id: key_ble 
  # Below are optional and can be passed via new connect service
  mac_address: 32:20:50:18:a6:96  # Hintertür
  user_id: 1
  user_key: 9872987492873492837492837492374
  
  #Schuppen:
  #mac_address: 32:20:50:0a:6e:7c # Schuppen
  #user_id: 1
  #user_key: 9283749283749237498729874928734  


text_sensor: 
  - platform: eqiva_key_ble
    mac_address: 
      name: "Mac Address"
      id: mac_address
    lock_status: 
      name: "Lock Status"
      id: lock_status
    low_battery:
      name: "Low Battery"
    lock_ble_state:
      name: "Lock BLE State"
    user_id:
      name: "User ID"
    user_key:
      name: "User Key"
    # on_raw_value:
            # then:   Do stuff on state change (!lambda "return x") 


lock:
  - platform: template
    name: "Lock 1"
    lambda: |-
      if (id(mac_address).state != "32:20:50:18:a6:96") {
        return {};
      }
      if (id(lock_status).state == "LOCKED") {
        return LOCK_STATE_LOCKED;
      } else if (id(lock_status).state == "UNLOCKED" || id(lock_status).state == "OPENED") {
        return LOCK_STATE_UNLOCKED;
      } else if (id(lock_status).state == "UNKNOWN") {
        return LOCK_STATE_JAMMED;
      } else {
        return LOCK_STATE_LOCKED;
      }
    lock_action:
      - eqiva_key_ble.connect:
          mac_address: 32:20:50:18:a6:96  # Hintertür
          user_id: 1
          user_key: 9872987492873492837492837492374
      - eqiva_key_ble.lock:
    unlock_action:
      - eqiva_key_ble.connect:
          mac_address: 32:20:50:18:a6:96  # Hintertür
          user_id: 1
          user_key: 9872987492873492837492837492374
      - eqiva_key_ble.unlock:
    open_action:
      - eqiva_key_ble.connect:
          mac_address: 32:20:50:18:a6:96  # Hintertür
          user_id: 1
          user_key: 9872987492873492837492837492374
      - eqiva_key_ble.open:

Gruß,
Hendrik

[Hendrik F. (henfri)]

Hallo,

es funktioniert jetzt - genau wie oben gepostet - mit zwei Locks.
Super!

Ich weiß aber nicht, warum es vorher nicht ging.

Verbleibende Fragen:
- Wie kann ich die dauerhafte Verbindung deaktivieren - oder noch 
besser: Zeitgesteuert machen (es gibt bei uns "Stoßzeiten")?
- Wie kann ich noch den Status vom zweiten Lock (Batterie etc) bekommen?
- Kann ich für "Locked" auch einen anderen Sensor (meinen Riegel-Taster, 
siehe oben) nutzen?

    lambda: |-
      if (id(mac_address).state != "xxxxx:0a:6e:7c") {
        return {};
      }
      if (binary_sensor.schuppen_riegelkontakt == "1") {
        return LOCK_STATE_LOCKED;
      } else if (id(lock_status).state == "UNLOCKED" || id(lock_status).state == "OPENED") || (binary_sensor.schuppen_riegelkontakt == "0") {
        return LOCK_STATE_UNLOCKED;
      } else if (id(lock_status).state == "UNKNOWN") {
        return LOCK_STATE_JAMMED;
      }

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> es funktioniert jetzt - genau wie oben gepostet - mit zwei Locks.
> Super!
> Ich weiß aber nicht, warum es vorher nicht ging.
> Verbleibende Fragen:
>
> Wie kann ich die dauerhafte Verbindung deaktivieren - oder noch besser:
> Zeitgesteuert machen (es gibt bei uns "Stoßzeiten")?
> Wie kann ich noch den Status vom zweiten Lock (Batterie etc) bekommen?
> Kann ich für "Locked" auch einen anderen Sensor (meinen Riegel-Taster,
> siehe oben) nutzen?
>
> 1
>     lambda: |-
>
> 2
>       if (id(mac_address).state != "xxxxx:0a:6e:7c") {
>
> 3
>         return {};
>
> 4
>       }
>
> 5
>       if (binary_sensor.schuppen_riegelkontakt == "1") {
>
> 6
>         return LOCK_STATE_LOCKED;
>
> 7
>       } else if (id(lock_status).state == "UNLOCKED" ||
> id(lock_status).state == "OPENED") ||
> (binary_sensor.schuppen_riegelkontakt == "0") {
>
> 8
>         return LOCK_STATE_UNLOCKED;
>
> 9
>       } else if (id(lock_status).state == "UNKNOWN") {
>
> 10
>         return LOCK_STATE_JAMMED;
>
> 11
>       }
>
> Gruß,
> Hendrik

Status solltest du beim zweiten Lock genau so bekommen wie beim ersten.

Einfach auf im Lambda auf die Mac Adresse prüfen.



Zeitsteuerung kannst du mit der Time Komponente machen. Hab da ja schon 
alle 4 min einem Status Aufruf gemacht.

Damit könntet du dann auch nach einiger Zeit disconnect aufrufen bzw. 
Connect

[Hendrik F. (henfri)]

Hallo,

da hab ich mich unklar ausgedrückt.
Ich hatte zwei Fragen:

1) Kann ich für den Lock Status so, wie ich das in dem Code-Block 
geschrieben habe einen anderen Sensor nutzen
2) Kann ich für das zweite Lock den *Batterie*-Status ermitteln?

Zur Zeit noch:
Aktuell ist im Lock-Template kein Disconnect. Das müsste ich dann noch 
einbauen, oder?

    lock_action:
      - eqiva_key_ble.connect:
            mac_address: 11:12:34:56:42:88
            user_id: 1
            user_key: 1234567891234567897234696139787E
      - eqiva_key_ble.lock:
      - eqiva_key_ble.disconnect:

Was macht denn der Code intern aktuell, wenn ich Lock bei dem einen und 
dann bei dem anderen Lock ausführe? Weiß er, dass er ein Disconnect 
machen muß, bevor er das Connect macht?

Gruß,

Hendrik

[Artur K. (artur_k638)]

Hey, bei mit wird Lock 1 immer als geöffnet angezeigt. Habe alles aus 
git kopiert.
Wahrscheinlich springt er immer in else.

[Hendrik F. (henfri)]

Hallo,

ich habe auch das Problem mit dem Status. Allerdings verwende ich auch 
meinen Riegelkontakt als Input für den Status.

# make external sensors available
sensor:
  - platform: homeassistant
    name: "Hintertuer"
    entity_id: binary_sensor.eg_flur_reed_hintertuer_geschlossen
    id: Hintertuer_status
  - platform: homeassistant
    name: "Schuppen"
    entity_id: binary_sensor.haustechnik_schuppen_neu_schloss_geschlossen
    id: Schuppen_status

lock:
  - platform: template
    name: "Hintertür"
    lambda: |-
      if (id(mac_address).state != "00:1a:22:01:62:72") {
        return {};
      }
      if (id(Hintertuer_status).state) {
        return LOCK_STATE_LOCKED;
      } else  {
        return LOCK_STATE_UNLOCKED;
      }

  - platform: template
    name: "Schuppen"
    lambda: |-
      if (id(mac_address).state != "00:1a:22:01:62:71") {
        return {};
      }
      if (id(Schuppen_status).state) {
        return LOCK_STATE_LOCKED;
      } else  {
        return LOCK_STATE_UNLOCKED;
      }

Das Schloss lasse ich nun nur zu bestimmten Zeiten verbunden:
time:
  - platform: sntp
    timezone: Europe/Berlin
    servers:
     - 0.pool.ntp.org
     - 1.pool.ntp.org
     - 2.pool.ntp.org
    on_time:
      # Every 4 minutes get Status, to ensure quick reaction
      - cron: '00 /4 21-23 * * *'
        then:
          - eqiva_key_ble.status:

Hier der ganze Code https://pastebin.com/AidTEfph

Siehst du da einen Fehler?

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> ich habe auch das Problem mit dem Status. Allerdings verwende ich auch
> meinen Riegelkontakt als Input für den Status.


Für deine Lock states kannst ja die Prüfung auf die Mac Adresse weg 
lassen.

Hast ja extra zwei separate Sensoren.

Bei mir wird der Lock state mit dem "neuen" Austausch-Schloss vernünftig 
dargestellt (schloss ist 6 Monate alt und hat noch alte Logs/user...)


Habe die yaml Mal aktualisiert.

[Dirk (digaus)]

Werde die yaml auch noch so anpassen, dass man alles über die Web 
Oberfläche konfigurieren kann.

[Dirk (digaus)]

Ein Problem könnte es noch mit dem Session counter geben, wenn die 
Verbindung dauerhaft bestehen bleibt.

In der original Implementierung wird ein uint8 verwenden , das wären max 
255

Also was passiert wenn man diese Grenze erreicht? Muss man das Schloss 
dann neu verbinden? Oder fängt er von vorne an zu zählen?

Ich teste das mal heute Abend aus.

🤔

[Hendrik F. (henfri)]

Hallo,

also der Status funktioniert bei mir noch nicht. Ich benutze dabei ja 
meinen eigenen Sensor, siehe template oben.
Die if Abfrage mit der MAC-Adresse habe ich jetzt noch nicht gelöscht, 
aber ich denke daran soll es ja nicht liegen.

Der Status ist bei mir immer aufgeschlossen.

Jetzt würde ich erwarten, dass er bei einem Druck auf das Schloss dann 
auch immer abschliesst. Das macht er allerdings nicht. Das ist auch 
komisch, oder?

Verwendet er zum entscheiden, ob er auf oder abschliesst einfach immer 
den internen Status?

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> also der Status funktioniert bei mir noch nicht. Ich benutze dabei ja
> meinen eigenen Sensor, siehe template oben.
> Die if Abfrage mit der MAC-Adresse habe ich jetzt noch nicht gelöscht,
> aber ich denke daran soll es ja nicht liegen.
> Der Status ist bei mir immer aufgeschlossen.
> Jetzt würde ich erwarten, dass er bei einem Druck auf das Schloss dann
> auch immer abschliesst. Das macht er allerdings nicht. Das ist auch
> komisch, oder?
> Verwendet er zum entscheiden, ob er auf oder abschliesst einfach immer
> den internen Status?

Entferne doch einfach Mal den Filter auf die Mac Adresse.

[Hendrik F. (henfri)]

Habe ich entfernt - gleiches Ergebnis.

Der Vergleich == 1 scheint immer False zu sein.

Der Vergleich if (id(Hintertuer_status).state == "on") kompiliert nicht.
Der Vergleich if (id(Hintertuer_status).state.is_on()) kompiliert auch 
nicht:

User
/config/esphome/esphome-web-8bf1d4.yaml:151:36: error: request for member 'is_on' in 'Hintertuer_status->esphome::homeassistant::HomeassistantSensor::<anonymous>.esphome::sensor::Sensor::state', which is of non-class type 'float'
       if (id(Hintertuer_status).state.is_on()) {
                                    ^~~~~

Aber warum ist state ein float?

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Habe ich entfernt - gleiches Ergebnis.
> Der Vergleich == 1 scheint immer False zu sein.
> Der Vergleich if (id(Hintertuer_status).state == "on") kompiliert nicht.
> Der Vergleich if (id(Hintertuer_status).state.is_on()) kompiliert auch
> nicht:
>
> 1
> User
>
> 2
> /config/esphome/esphome-web-8bf1d4.yaml:151:36: error: request for
> member 'is_on' in
> 'Hintertuer_status->esphome::homeassistant::HomeassistantSensor::<anonym 
ous>.esphome::sensor::Sensor::state',
> which is of non-class type 'float'
>
> 3
>        if (id(Hintertuer_status).state.is_on()) {
>
> 4
>                                     ^~~~~
>
> Aber warum ist state ein float?
> Gruß,
> Hendrik

Ist dein Sensor der wohl nen float liefert.

Log die Werte doch mal.

[Hendrik F. (henfri)]

Wie kann ein Binary Sensor float liefern... Ich hab jetzt

      if (id(Schuppen_status).state)

probiert. (https://esphome.io/components/sensor/template.html)

Da steht im log:

[16:51:04][W][homeassistant.sensor:015]: 'binary_sensor.haustechnik_schuppen_neu_schloss_geschlossen': Can't convert 'on' to number!
[16:51:04][D][sensor:094]: 'Schuppen': Sending state nan  with 1 decimals of accuracy
[16:51:07][W][homeassistant.sensor:015]: 'binary_sensor.haustechnik_schuppen_neu_schloss_geschlossen': Can't convert 'off' to number!

Das sieht nicht nach einem float aus...

Aber warum denkt der Compiler, dass es ein float wäre?
Kann ich einfach mit str() einen String erzwingen?

    ESP_LOGD("custom", "Hintertuer_status state: %f", 
static_cast<float>(id(Hintertuer_status).state)); sagt mir 
"Hintertuer_status state: nan"

Gruß,
Hendrik

[Artur K. (artur_k638)]

Hendrik F. schrieb:
>
Wird es nicht vll einfacher den Schloß mit Kontakt direkt in 
Homeassistant zu es stellen? Das habe ich zumindest so. Finde ich 
persönlich einfacher, kann man immer was ändern ohne neuzuflashen.
Grüß

[Hendrik F. (henfri)]

Hallo,

das Problem habe ich gelöst.
Ich habe den Sensor aus HomeAssistant in esphome als

sensor:
  - platform: homeassistant
    name: "Hintertuer"
    entity_id: binary_sensor.xyz
    id: Hintertuer_status

Importiert. Somit ist es ein sensor. Kein binary sensor
So funktioniert es

binary_sensor:
  - platform: homeassistant
    name: "Hintertuer"
    entity_id: binary_sensor.xyz
    id: Hintertuer_status

Und dann:

  - platform: template
    name: "Schuppen"
    lambda: |-
      if (id(Schuppen_status).state) {
        return LOCK_STATE_LOCKED;
      } else  {
        return LOCK_STATE_UNLOCKED;
      }

@Artur:
Wenn ich das lock in HA definiere, kennt er dann eqiva_key_ble.connect: 
und co?
Kannst du ein Beispiel posten?

Gruß,
Hendrik

[Artur K. (artur_k638)]

Hast du mehrer Schlösser?

[Artur K. (artur_k638)]

Iwas komisches ist passiert. In esphome ist meine esp online, wenn ich 
log drücke, verbindet er nicht. Alle Entitäten in ha sind normal 
verfügbar. Nur reagiert auf nichts

[Hendrik F. (henfri)]

Ja, ich habe mehrere Schlösser.

Noch eine Frage: Wenn ich immer ein Disconnect will, um Batterie zu 
sparen, reicht dann das:

    unlock_action:
      - eqiva_key_ble.connect:
          mac_address: 00:1c  # Hintertür
          user_id: 1
          user_key: x
      - eqiva_key_ble.unlock:
      - eqiva_key_ble.disconnect:

(die letzte Zeile habe ich hinzugefügt)?

Gruß,
Hendrik

[Artur K. (artur_k638)]

Bei 2 Schlössern kann man service connect hinzufügen, aber da wird nicht 
mac übergeben, schon vergessen warum. Alternativ könnte man in esphome 2 
services für connect schreiben?

[Artur K. (artur_k638)]

@Dirk
Hast du noch nicht rausgefunden wieso man mac nicht via template 
weitergeben kann?

[Artur K. (artur_k638)]

Hendrik F. schrieb:
> @Artur:
> Wenn ich das lock in HA definiere, kennt er dann eqiva_key_ble.connect:
> und co?
> Kannst du ein Beispiel posten?
Zum Beispiel so. Aber dann in esphome service: 
esphome.eqiva_lock_connect für den zweiten Schloß service connect 2 
schreiben
  lock:
    - platform: template
      name: Salontur
      unique_id: salontur
      value_template: "{{ 
is_state('binary_sensor.reed_turschloss_salon', 'off') }}"
      lock:
        service: esphome.eqiva_lock_connect
        service: esphome.eqiva_lock_lock
        service: esphome.eqiva_lock_disconnect
      unlock:
        service: esphome.eqiva_lock_connect
        service: esphome.eqiva_lock_unlock
        service: esphome.eqiva_lock_disconnect

[Dirk (digaus)]

Artur K. schrieb:
> @Dirk
> Hast du noch nicht rausgefunden wieso man mac nicht via template
> weitergeben kann?

Weil es über das Template nen string ist, es aber als Typ Mac erwartet 
wird. Müsste im Code dann selber die Konvertierung/Validierung machen

[Artur K. (artur_k638)]

Dirk schrieb:
> Artur K. schrieb:
>> @Dirk
>> Hast du noch nicht rausgefunden wieso man mac nicht via template
>> weitergeben kann?
>
> Weil es über das Template nen string ist, es aber als Typ Mac erwartet
> wird. Müsste im Code dann selber die Konvertierung/Validierung machen

Meinst du im cpp oder h? Oder direkt in yaml?

[Artur K. (artur_k638)]

Artur K. schrieb:
> lock:
> - platform: template
> name: Salontur
> unique_id: salontur
> value_template: "{{ is_state('binary_sensor.reed_turschloss_salon',
> 'off') }}"
> lock:
> service: esphome.eqiva_lock_connect
> service: esphome.eqiva_lock_lock
> service: esphome.eqiva_lock_disconnect
> unlock:
> service: esphome.eqiva_lock_connect
> service: esphome.eqiva_lock_unlock
> service: esphome.eqiva_lock_disconnect

Sorry, service connect kann man jetzt templaten. Also muss man nicht 
zweiten schreiben

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Artur K. schrieb:
>>> @Dirk
>>> Hast du noch nicht rausgefunden wieso man mac nicht via template
>>> weitergeben kann?
>>
>> Weil es über das Template nen string ist, es aber als Typ Mac erwartet
>> wird. Müsste im Code dann selber die Konvertierung/Validierung machen
>
> Meinst du im cpp oder h? Oder direkt in yaml?

Bin schon dabei.

Wollte ja alles über die Weboberfläche einstellbar machen.

[Artur K. (artur_k638)]

Dirk schrieb:
> Artur K. schrieb:
>> Dirk schrieb:
>>> Artur K. schrieb:
>>>> @Dirk
>>>> Hast du noch nicht rausgefunden wieso man mac nicht via template
>>>> weitergeben kann?
>>>
>>> Weil es über das Template nen string ist, es aber als Typ Mac erwartet
>>> wird. Müsste im Code dann selber die Konvertierung/Validierung machen
>>
>> Meinst du im cpp oder h? Oder direkt in yaml?
>
> Bin schon dabei.
>
> Wollte ja alles über die Weboberfläche einstellbar machen.

Das ist super.
Eine frage, wenn ich disconnect mache und dann versucht er sofort zu 
connecten aber mit id 4, meine id ist 1, verbindet sich such und zeigt 
established

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Artur K. schrieb:
>>> Dirk schrieb:
>>>> Artur K. schrieb:
>>>>> @Dirk
>>>>> Hast du noch nicht rausgefunden wieso man mac nicht via template
>>>>> weitergeben kann?
>>>>
>>>> Weil es über das Template nen string ist, es aber als Typ Mac erwartet
>>>> wird. Müsste im Code dann selber die Konvertierung/Validierung machen
>>>
>>> Meinst du im cpp oder h? Oder direkt in yaml?
>>
>> Bin schon dabei.
>> Wollte ja alles über die Weboberfläche einstellbar machen.
>
> Das ist super.
> Eine frage, wenn ich disconnect mache und dann versucht er sofort zu
> connecten aber mit id 4, meine id ist 1, verbindet sich such und zeigt
> established

Jo hab ich auch gefixed.

Er hat die Mac nicht gecleared. ID und User Key aber schon. Dadurch 
generiert er sich ne neue beim nonce austauschen

[Dirk (digaus)]

Hab's aktualisiert. Jetzt kann man Mac auch bei Connect via template 
string mitgeben

Hab auch Beispiel für UI Eingabe eingebaut

[Hendrik F. (henfri)]

Klasse!

[Artur K. (artur_k638)]

Heute Abend kam ich nach Hause und konnte Schloß nicht ansprechen, web 
Oberfläche war nicht abrufbar, obwohl es nicht als nicht verfügbar war, 
war online. Wie konnte ich die Ursache finden?

[Artur K. (artur_k638)]

Sehe oft das im log
[20:48:29][W][component:214]: Component esp32_ble took a long time for 
an operation (0.08 s).
[20:48:29][W][component:215]: Components should block for at most 
20-30ms.

[Dirk (digaus)]

Artur K. schrieb:
> Sehe oft das im log
> [20:48:29][W][component:214]: Component esp32_ble took a long time for
> an operation (0.08 s).
> [20:48:29][W][component:215]: Components should block for at most
> 20-30ms.

Liegt entweder am  write_value also senden der BT Message oder am 
Verschlüssen.

Aber tritt wohl häufig auf:

https://github.com/esphome/issues/issues/4717


Wüsste nicht was ich da optimieren könnte.


Bzgl. Webserver nicht erreichbar, hast du local: true dort stehen? Wenn 
nicht gab's vllt Internet Probleme?

[Artur K. (artur_k638)]

Dirk schrieb:
> Bzgl. Webserver nicht erreichbar, hast du local: true dort stehen? Wenn
> nicht gab's vllt Internet Probleme?

Ja habs true stehen. Wegen Internet nicht das ich wussten. Konnte nur 
Schloß nicht ansprechen, liegt vllt am esp, werde ich mal ersetzen. Aber 
da lief sehr lange andere Version, wo der Schloß per mqtt angesteuert 
wird, ohne Probleme, sehr komisch

[Artur K. (artur_k638)]

Wenn ich aktuelle Version von git nehme, kommt das:
Failed config

text_sensor.eqiva_key_ble: [source /config/esphome/eqiva-lock.yaml:198]
  platform: eqiva_key_ble
  mac_address:
    name: Mac Address

    ID mac_address redefined! Check text->0->id.
    id: mac_address
    disabled_by_default: False
    entity_category: ''

ist es nicht weil in text template id mac_address verwendet wird und 
auch in text_sensor id mac_address?

[Antonello M. (antonello_m)]

Danke Dirk für die schöne Arbeit.
Ich möchte auf ein paar Probleme hinweisen, die dein Projekt unbrauchbar 
machen (Stand heute, 9. Dezember)
1. Die letzte Version hat zwei Probleme im Code (leicht zu lösen):
A: Dieser Teil des Codes ist innerhalb der ap-Funktion eingerückt, 
sollte aber einfach unter wifi stehen
  # Use below to apply saved input parameters on boot
    on_connect:
      - eqiva_key_ble.connect:
          mac_address: !lambda 'return id(mac_address).state;'
          user_id: !lambda 'return id(user_id).state;'
          user_key: !lambda 'return id(user_key).state;'
B: Die Entität mac_address unter text sensor kann nicht den gleichen 
Namen unter text haben

2. Die zuletzt geladene Version erlaubt es nicht, die Benutzerkennung 
und den Schlüssel über die Webschnittstelle einzugeben (Sie müssten 
entweder das Pairing erneut durchführen oder die Daten in die Firmware 
eingeben.

3. Bei der Erstinstallation funktioniert der Code perfekt, aber beim 
ersten Neustart, wenn der API-Teil gestartet wird, zeigen das Protokoll 
und das Gerät an, dass alles eingeschaltet ist, aber es geht nicht an 
(ich vermute, dass die "keyble"-Bibliothek nicht geladen wird).

Ein letzter Vorschlag: Da der esp32 vor den 5 Minuten ein Signal sendet, 
um die Bluetooth-Verbindung aktiv zu halten, würde ich eine 
Schaltereinheit einfügen, die die Aufrechterhaltung der Verbindung 
aktiviert und deaktiviert.
Zu guter Letzt würde ich auch einen Schalter einfügen, der es 
ermöglicht, den esp32 im Falle von Problemen vom Home-Assistenten aus 
neu zu starten.

Wenn ich Sie beim esphome-Teil unterstützen kann, stehe ich Ihnen gerne 
zur Verfügung (ich bin Italiener).
Vielen Dank

Übersetzt mit DeepL.com (kostenlose Version)

[Dirk (digaus)]

Antonello M. schrieb:
> Danke Dirk für die schöne Arbeit.
> Ich möchte auf ein paar Probleme hinweisen, die dein Projekt unbrauchbar
> machen (Stand heute, 9. Dezember)
> 1. Die letzte Version hat zwei Probleme im Code (leicht zu lösen):
> A: Dieser Teil des Codes ist innerhalb der ap-Funktion eingerückt,
> sollte aber einfach unter wifi stehen
>   # Use below to apply saved input parameters on boot
>     on_connect:
>       - eqiva_key_ble.connect:
>           mac_address: !lambda 'return id(mac_address).state;'
>           user_id: !lambda 'return id(user_id).state;'
>           user_key: !lambda 'return id(user_key).state;'
> B: Die Entität mac_address unter text sensor kann nicht den gleichen
> Namen unter text haben
>
> 2. Die zuletzt geladene Version erlaubt es nicht, die Benutzerkennung
> und den Schlüssel über die Webschnittstelle einzugeben (Sie müssten
> entweder das Pairing erneut durchführen oder die Daten in die Firmware
> eingeben.
>
> 3. Bei der Erstinstallation funktioniert der Code perfekt, aber beim
> ersten Neustart, wenn der API-Teil gestartet wird, zeigen das Protokoll
> und das Gerät an, dass alles eingeschaltet ist, aber es geht nicht an
> (ich vermute, dass die "keyble"-Bibliothek nicht geladen wird).
>
> Ein letzter Vorschlag: Da der esp32 vor den 5 Minuten ein Signal sendet,
> um die Bluetooth-Verbindung aktiv zu halten, würde ich eine
> Schaltereinheit einfügen, die die Aufrechterhaltung der Verbindung
> aktiviert und deaktiviert.
> Zu guter Letzt würde ich auch einen Schalter einfügen, der es
> ermöglicht, den esp32 im Falle von Problemen vom Home-Assistenten aus
> neu zu starten.
>
> Wenn ich Sie beim esphome-Teil unterstützen kann, stehe ich Ihnen gerne
> zur Verfügung (ich bin Italiener).
> Vielen Dank
>
> Übersetzt mit DeepL.com (kostenlose Version)

2. Ist ein Bug des web_server -> "local: false" setzen

3. Es wird kein keyble Lib geladen. Code sollte funktionieren. Am besten 
einmal yaml Posten zum Prüfen



Das Intervall zum abfragen des Status ist lediglich ein Beispiel. Wie 
genau man es machen möchte ist hier dem Nutzer überlassen. Die yaml kann 
ja jeder anpassen wie er möchte .

[Artur K. (artur_k638)]

Kann eigentliche hier ohne Probleme auch bluetooth proxy verwendet 
werden?

[Artur K. (artur_k638)]

Moin, eine Frage, würde so was nicht funktionieren? klappt iwie nicht 
wie es mir vorstelle

lock_action:
      - eqiva_key_ble.connect:
          mac_address: 00:12:34:56:42:88
          user_id: 1
          user_key: 12345678636F6763386A726E33746F35
      - eqiva_key_ble.lock:
      - eqiva_key_ble.disconnect:

bei mir spinnt es iwie allgemein, ich würde gerne Dauer Verbindung 
lassen, aber ich merke dass es morgens nicht ansprechbar ist, Verbindung 
wird iwie verloren oder so. weiss nicht genau

oder wie kann ich es am besten machen, wenn ich die Verbindung immer 
trenne, aber dann wenn ich in HA den Lock schließe oder öffne, dass es 
dann zuerst connected und zum Schluss disconnected? Automation ist klar, 
aber ohne geht es iwie? zB direkt in esphome?

[Antonello M. (antonello_m)]

Ich werde Ihnen meine Konfiguration mitteilen und die yaml-Datei 
anhängen:

ESP32 Modell AZ-Delivery
https://docs.platformio.org/en/latest/boards/espressif32/az-delivery-devkit-v4.html

Wie ich schon sagte, funktioniert das Gerät am Ende der 
Firmware-Installation perfekt. Aber sobald Sie es neu starten oder ab- 
und wieder anstecken, funktioniert es nicht mehr.
Das Gerät wird auf EspHome als verbunden angezeigt, ist aber nicht über 
das Webportal erreichbar und die Entitäten sind nicht über den Home 
Assistant erreichbar. Es kann jedoch über Wireless mit EspHome geflasht 
werden.

Ich füge mein yaml und unten die Protokolldatei bei.

INFO ESPHome 2023.11.6
INFO Reading configuration /config/esphome/esphome-web-aa79f0.yaml...
INFO Detected timezone 'Europe/Rome'
INFO Starting log output from esphome-web-aa79f0.local using esphome API
INFO Successfully connected to esphome-web-aa79f0 in 0.574s
INFO Successful handshake with esphome-web-aa79f0 in 0.107s
[02:32:29][I][app:102]: ESPHome version 2023.11.6 compiled on Dec  8 
2023, 11:10:43
[02:32:29][C][wifi:559]: WiFi:
[02:32:29][C][wifi:391]:   Local MAC: 08:3A:F2:AA:79:F0
[02:32:29][C][wifi:396]:   SSID: 'CasaMesserangeli'[redacted]
[02:32:29][C][wifi:397]:   IP Address: 192.168.178.117
[02:32:29][C][wifi:399]:   BSSID: 3C:37:12:05:C1:85[redacted]
[02:32:29][C][wifi:400]:   Hostname: 'esphome-web-aa79f0'
[02:32:29][C][wifi:402]:   Signal strength: -51 dB ▂▄▆█
[02:32:29][C][wifi:406]:   Channel: 1
[02:32:29][C][wifi:407]:   Subnet: 255.255.255.0
[02:32:29][C][wifi:408]:   Gateway: 192.168.178.1
[02:32:29][C][wifi:409]:   DNS1: 192.168.178.1
[02:32:29][C][wifi:410]:   DNS2: 0.0.0.0
[02:32:29][C][logger:416]: Logger:
[02:32:29][C][logger:417]:   Level: DEBUG
[02:32:29][C][logger:418]:   Log Baud Rate: 115200
[02:32:29][C][logger:420]:   Hardware UART: UART0
[02:32:29][C][captive_portal:088]: Captive Portal:
[02:32:29][C][mdns:115]: mDNS:
[02:32:29][C][mdns:116]:   Hostname: esphome-web-aa79f0
[02:32:29][C][ota:097]: Over-The-Air Updates:
[02:32:29][C][ota:098]:   Address: esphome-web-aa79f0.local:3232
[02:32:29][W][ota:107]: Last Boot was an unhandled reset, will proceed 
to safe mode in 8 restarts
[02:32:29][C][api:139]: API Server:
[02:32:29][C][api:140]:   Address: esphome-web-aa79f0.local:6053
[02:32:29][C][api:142]:   Using noise encryption: YES
WARNING esphome-web-aa79f0: Connection error occurred: [Errno 104] 
Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for 
esphome-web-aa79f0
WARNING Disconnected from API
INFO Successfully connected to esphome-web-aa79f0 in 0.454s
INFO Successful handshake with esphome-web-aa79f0 in 0.113s
[02:37:27][D][api:102]: Accepted 192.168.178.200
[02:37:27][W][component:214]: Component api took a long time for an 
operation (0.05 s).
[02:37:27][W][component:215]: Components should block for at most 
20-30ms.
[02:37:28][D][api.connection:1089]: Home Assistant 2023.12.1 
(192.168.178.200): Connected successfully
[02:41:49][I][ota:117]: Boot seems successful, resetting boot loop 
counter.
[02:41:49][D][esp32.preferences:114]: Saving 1 preferences to flash...
[02:41:49][D][esp32.preferences:143]: Saving 1 preferences to flash: 0 
cached, 1 written, 0 failed

[Dirk (digaus)]

Artur K. schrieb:
> Moin, eine Frage, würde so was nicht funktionieren? klappt iwie
> nicht wie es mir vorstelle
>
> 1
> lock_action:
>
> 2
>       - eqiva_key_ble.connect:
>
> 3
>           mac_address: 00:12:34:56:42:88
>
> 4
>           user_id: 1
>
> 5
>           user_key: 12345678636F6763386A726E33746F35
>
> 6
>       - eqiva_key_ble.lock:
>
> 7
>       - eqiva_key_ble.disconnect:
> [...]
> aber ohne geht es iwie? zB direkt in esphome?

Disconnect kommt zu früh. müsstest erst machen nachdem sich der Lock 
Status geändert hat oder einfach nach nem 30 Sekunden delay.

Evtl auch einbauen, dass er erst BT Scan macht wenn er mit dem WiFi 
verbunden ist und bei disconnect wieder Scan deaktivieren

[Artur K. (artur_k638)]

Dirk schrieb:
> Evtl auch einbauen, dass er erst BT Scan macht wenn er mit dem WiFi
> verbunden ist und bei disconnect wieder Scan deaktivieren

Wie mache ich das mit scan genau, oder bzw link wo ich das nachlesen 
kann.

Habe momentan auch bluetooth proxy eingebaut. Aber Probleme nach x 
Stunden kamen auch ohne bluetooth proxy. Eventuell esp restarten noch 24 
Stunden

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Evtl auch einbauen, dass er erst BT Scan macht wenn er mit dem WiFi
>> verbunden ist und bei disconnect wieder Scan deaktivieren
>
> Wie mache ich das mit scan genau, oder bzw link wo ich das nachlesen
> kann.
> Habe momentan auch bluetooth proxy eingebaut. Aber Probleme nach x
> Stunden kamen auch ohne bluetooth proxy. Eventuell esp restarten noch 24
> Stunden

Steht in der Beispiel yaml. WLAN onconnet/disconnect und beim starten 
Initial nicht aktivieren

[Antonello M. (antonello_m)]

Problem gelöst.
Alles befand sich im esp32-Speicher.

Ich flashed eine andere Firmware (tasmota Fabrik) und löschte den 
gesamten Blitz.

Ich habe dann neu geflasht die kompilierte Firmware mit NodeMCU 
PyFlasher und jetzt sogar Neustart das Gerät bootet korrekt.

Ich danke Ihnen für Ihre Geduld und Verfügbarkeit.

[Artur K. (artur_k638)]

Heute morgen wieder passiert, steht ESTABLISHED, Schloß hatte ich Manuel 
aufgemacht, auf lock unlock reagierte nicht, Status aufgerufen, auch 
nichts passiert, stand die ganze Zeile Status Locked. Disconnect 
Funktionierte, auch connect klappte. Einmal neugestartet und geht alles. 
Ich kann natürlich es mal Nachts Neustart lassen. Aber möchte trotzdem 
rausfinden warum das so passiert.
Betreibt hier jemanden es auch mit Dauerverbindung?

[Dirk (digaus)]

Artur K. schrieb:
> Heute morgen wieder passiert, steht ESTABLISHED, Schloß hatte ich
> Manuel aufgemacht, auf lock unlock reagierte nicht, Status aufgerufen,
> auch nichts passiert, stand die ganze Zeile Status Locked. Disconnect
> Funktionierte, auch connect klappte. Einmal neugestartet und geht alles.
> Ich kann natürlich es mal Nachts Neustart lassen. Aber möchte trotzdem
> rausfinden warum das so passiert.
> Betreibt hier jemanden es auch mit Dauerverbindung?

Ja ich, hatte bisher nicht das Problem.

Wie lange lief er ohne Probleme? In welchem Intervall aktualisierst du 
den Status?

[Artur K. (artur_k638)]

Dirk schrieb:
> Ja ich, hatte bisher nicht das Problem.
> Wie lange lief er ohne Probleme? In welchem Intervall aktualisierst du
> den Status?

Habe genau nicht beobachtet, werde ich mal machen, ich aktualisiere es 
so wir bei dir in yaml steht, jede 4 Minuten.

[Artur K. (artur_k638)]

Dirk schrieb:
> WLAN onconnet/disconnect und beim starten Initial nicht aktivieren

Noch mal dazu, bei wlan habe ich on_connect gesehen. Aber Initial nicht 
aktivieren, das habe ich nicht wirklich verstanden.

[Artur K. (artur_k638)]

Also um 13 Uhr neugestartet, und jetzt kam ich nach Hause und konnte 
nicht mehr aufmachen. Vllt bluetooth proxy ist das Problem, werde ich 
rausnehmen

[Philipp C. (e61_phil)]

Hallo,

ich war nun einige Tage mit anderen Dingen beschäftigt, aber es läuft 
bei uns nun schon eine Weile wie es soll.

Das letzte mal geflasht habe ich wohl am 7.12. danach musste ich einmal 
den ESP neu starten, aber seitdem war es zuverlässig.

Das 4min Interval habe ich aus dem Beispiel kopiert. Ich kann das 
Schloss aktuell schließen.

Viele Grüße
Philipp

PS: Sollte ich die SW noch einmal aktualisieren?

[Artur K. (artur_k638)]

Philipp C. schrieb:
> Das letzte mal geflasht habe ich wohl am 7.12. danach musste ich einmal
> den ESP neu starten, aber seitdem war es zuverlässig.
>
> Das 4min Interval habe ich aus dem Beispiel kopiert. Ich kann das
> Schloss aktuell schließen.
Welche esp32 hast du?

[Artur K. (artur_k638)]

Also, gerade wieder passier, nach 5 Stunden, wenn ich lock oder unlock 
drücke

 kommt in log [eqiva_key_ble:358]  
Waiting for connection...

Eine Idee? Liegt vll am Schloß oder esp32?

Erst gerade aufgefallen

 [eqiva_key_ble:073]  
ESP_GATTC_WRITE_DESCR_EVT
21:16:35  [D]  [esp-idf:000]  
[0;31mE (17830464) BT_APPL: service change write ccc failed
21:16:45  [I]  [eqiva_key_ble:358]  
Waiting for connection..

[Dirk (digaus)]

Artur K. schrieb:
> Also, gerade wieder passier, nach 5 Stunden, wenn ich lock oder
> unlock drücke
>
> 1
>  kommt in log [eqiva_key_ble:358]
>
> 2
> Waiting for connection...
>
> Eine Idee? Liegt vll am Schloß oder esp32?
> Erst gerade aufgefallen
>
> 1
>  [eqiva_key_ble:073]
>
> 2
> ESP_GATTC_WRITE_DESCR_EVT
>
> 3
> 21:16:35  [D]  [esp-idf:000]
>
> 4
> [0;31mE (17830464) BT_APPL: service change write ccc failed
>
> 5
> 21:16:45  [I]  [eqiva_key_ble:358]
>
> 6
> Waiting for connection..

Waiting for connection heist er ist noch nicht verbunden oder hat die 
nonce noch nicht ausgetauscht.

Poste mal deine yaml.

Den write ccc error bekomme ich auch immer. Das scheint normal zu sein.

[Artur K. (artur_k638)]

esphome:
  name: eqiva-lock
  friendly_name: Eqiva Lock

esp32:
  board: wemos_d1_mini32
  framework:
    type: esp-idf 

logger:

api:
  encryption:
    key: !secret api_encryption_key
  services:
  - service: settings
    variables:
      turn_left: bool
      key_horizontal: bool
      lock_turns: int
    then:
      - eqiva_key_ble.settings:
          turn_left: !lambda 'return turn_left;'
          key_horizontal: !lambda 'return key_horizontal;'
          lock_turns: !lambda 'return lock_turns;'

  - service: fastconnect
    then:
      - eqiva_key_ble.connect:
          mac_address: 00:1a:22:18:3c:76
          user_id: 1
          user_key: 601dde3b2904999e289f1b1079c258fe

  - service: connect
    variables:
      mac_address: string
      user_id: int
      user_key: string
    then:
      - eqiva_key_ble.connect:
          mac_address: !lambda 'return mac_address;'
          user_id: !lambda 'return user_id;'
          user_key: !lambda 'return user_key;'
  - service: disconnect
    then:
      - eqiva_key_ble.disconnect:
  - service: pair
    variables:
      card_key: string
    then:
      - eqiva_key_ble.pair:
          card_key: !lambda 'return card_key;'
  - service: lock
    then:
      - eqiva_key_ble.lock:
  - service: unlock
    then:
      - eqiva_key_ble.unlock:
  - service: open
    then:
      - eqiva_key_ble.open:
  - service: status
    then:
      - eqiva_key_ble.status:

ota:
  password: !secret esphome_api_password

wifi:
  ssid: !secret wifi_ssid_salon
  password: !secret wifi_password
  ap:
    ssid: "key-ble Fallback Hotspot"
    password: "hvkiA8QRZbD8"
  # Use below to apply saved input parameters on boot
  on_connect:
    - eqiva_key_ble.connect:
          mac_address: 00:1a:22:18:3c:76
          user_id: 1
          user_key: 601dde3b2904999e289f1b1079c258fe
        #mac_address: !lambda 'return id(mac_address).state;' 
        #user_id: !lambda 'return id(user_id).state;'
        #user_key: !lambda 'return id(user_key).state;'
      

#button, number and text input for pairing and setting mac/user_id/user-key via UI
button:
  - platform: restart
    name: "Eqiva Lock Restart"
  - platform: safe_mode
    name: "Eqiava Lock Restart (Safe Mode)"  
  - platform: template
    id: ble_fastconnect
    name: "Fast Connect"
    icon: "mdi:bluetooth-connect"
    on_press:
      - eqiva_key_ble.connect:
          mac_address: 00:1a:22:18:3c:76
          user_id: 1
          user_key: 601dde3b2904999e289f1b1079c258fe
  - platform: template
    id: ble_lock_lock
    name: "Lock lock"
    icon: "mdi:lock"
    on_press:
      - eqiva_key_ble.lock:
  - platform: template
    id: ble_lock_unlock
    name: "Lock unlock"
    icon: "mdi:lock-open"
    on_press:
      - eqiva_key_ble.unlock:
  - platform: template
    id: ble_settings
    name: BLE Settings _Save_
    icon: "mdi:content-save"
    disabled_by_default: true
    on_press:
      - eqiva_key_ble.connect:
          mac_address: !lambda 'return id(mac_address).state;' 
          user_id: !lambda 'return id(user_id).state;'
          user_key: !lambda 'return id(user_key).state;'
  
  - platform: template
    id: ble_disconnect
    name: Disconnect
    icon: "mdi:bluetooth-off"
    on_press:
      - eqiva_key_ble.disconnect:
  - platform: template
    id: ble_pair
    name: BLE Pair _Start_
    icon: "mdi:check-underline"
    disabled_by_default: true
    on_press:
      - eqiva_key_ble.pair:
          card_key: !lambda 'return id(card_key).state;' 

  - platform: template
    id: lock_settings
    name: Lock Settings _Apply_
    icon: "mdi:check-underline"
    on_press:
      - eqiva_key_ble.settings:
          turn_left: !lambda 'return id(direction).state == "Left";' 
          key_horizontal: !lambda 'return id(position).state == "Horizontal";'
          lock_turns: !lambda 'return atoi(id(turns).state.c_str());'
    disabled_by_default: true
  - platform: template
    id: ble_status
    name: Status
    icon: "mdi:bluetooth"
    on_press:
      - eqiva_key_ble.status:
          
number:
  - platform: template
    mode: box
    name: BLE Settings User ID
    id: user_id
    max_value: 7
    min_value: 0
    step: 1
    optimistic: true
    restore_value: true
    disabled_by_default: true

text:
  - platform: template
    mode: text
    name: BLE Settings Mac Address
    id: mac_addr
    optimistic: true
    restore_value: true
    disabled_by_default: true
  - platform: template
    mode: text
    name: BLE Settings User Key
    id: user_key
    optimistic: true
    restore_value: true
    disabled_by_default: true
  - platform: template
    mode: text
    name: BLE Pair Card Key
    id: card_key
    optimistic: true
    disabled_by_default: true

select:
  - platform: template
    name: Lock Settings Close Direction
    id: direction
    options:
     - "Left"
     - "Right"
    optimistic: true
    disabled_by_default: true
  - platform: template
    name: Lock Settings Key Position
    id: position
    options:
     - "Vertical"
     - "Horizontal"
    optimistic: true
    disabled_by_default: true
  - platform: template
    name: Lock Settings Turns
    id: turns
    options:
     - "1"
     - "2"
     - "3"
     - "4"
    optimistic: true
    disabled_by_default: true

captive_portal:

esp32_ble_tracker:
  scan_parameters:
    window: 300ms

#bluetooth_proxy:
  #active: true   

#binary_sensor:
  #- platform: ble_presence
    #ibeacon_uuid: '5058f82a-fca1-419b-827b-a18dcae463b9'
    #name: "Artur S23U Garage"

web_server:
  include_internal: true
  local: false
  port: 80

external_components:
  source: github://digaus/esphome-components-eqiva
  refresh: 0s

eqiva_ble:

eqiva_key_ble:
  id: key_ble
  mac_address: 00:1a:22:18:3c:76
  user_id: 1
  user_key: 601dde3b2904999e289f1b1079c258fe

text_sensor: 
  - platform: eqiva_key_ble
    mac_address: 
      name: "Mac Address"
      id: mac_address
    lock_status: 
      name: "Lock Status"
      id: lock_status
    low_battery:
      name: "Low Battery"
    lock_ble_state:
      name: "Lock BLE State"
    user_id:
      name: "User ID"
    user_key:
      name: "User Key"
    # on_raw_value:
            # then:   Do stuff on state change (!lambda "return x") 
time:
  - platform: sntp
    # ...
    on_time:
      # Every 5 minutes
      - seconds: 0
        minutes: /4
        then:
          - eqiva_key_ble.status:

lock:
  - platform: template
    name: "Lock"
    lambda: |-
      if (id(lock_status).state == "LOCKED") {
        return LOCK_STATE_LOCKED;
      } else if (id(lock_status).state == "UNLOCKED" || id(lock_status).state == "OPENED") {
        return LOCK_STATE_UNLOCKED;
      } else if(id(lock_status).state == "MOVING") {
        return {};
      } else if (id(lock_status).state == "UNKNOWN") {
        return LOCK_STATE_JAMMED;
      } 
      return LOCK_STATE_LOCKED;
    lock_action:
      #- eqiva_key_ble.connect:
          #mac_address: 00:1a:22:18:3c:76
          #user_id: 1
          #user_key: 601dde3b2904999e289f1b1079c258fe
      - eqiva_key_ble.lock:
      #- eqiva_key_ble.disconnect:
    unlock_action:
      #- eqiva_key_ble.connect:
          #mac_address: 00:1a:22:18:3c:76
          #user_id: 1
          #user_key: 601dde3b2904999e289f1b1079c258fe
      - eqiva_key_ble.unlock:
      #- eqiva_key_ble.disconnect:
    open_action:
      #- eqiva_key_ble.connect:
          #mac_address: 00:1a:22:18:3c:76
          #user_id: 1
          #user_key: 601dde3b2904999e289f1b1079c258fe
      - eqiva_key_ble.open:
      #- eqiva_key_ble.disconnect:

board gerade geändert, hatte esp32dev obs daran liegt? Habe esp32 d1 
mini von azdelivery

[Dirk (digaus)]

Möglich.

Aber ich würde noch die Parameter bei eqiva_key_ble weglassen.

Und bei WLAN bei ondisconnect den disconnect service aufrufen .

Dann sollten ble Scan und WiFi Scan nie gleichzeitig laufen.

[Artur K. (artur_k638)]

Dieses Fehler kommt immer nach Status Lock oder Unlock

Ok werde ich versuchen, danke

[Artur K. (artur_k638)]

Bericht. Board geänderten und das mit wifi was du meintest. Heute morgen 
istv noch alles gut.

[Philipp C. (e61_phil)]

Artur K. schrieb:
> Philipp C. schrieb:
>> Das letzte mal geflasht habe ich wohl am 7.12. danach musste ich einmal
>> den ESP neu starten, aber seitdem war es zuverlässig.
>>
>> Das 4min Interval habe ich aus dem Beispiel kopiert. Ich kann das
>> Schloss aktuell schließen.
> Welche esp32 hast du?

Einen D1 Mini.

Das mit dem WLAN sollte ich wohl auch noch übernehmen.

[Dirk (digaus)]

Nicht vergessen continues: false beim tracker einzubauen damit er beim 
Starten nicht direkt los scannt

[Artur K. (artur_k638)]

Dirk schrieb:
> Nicht vergessen continues: false beim tracker einzubauen damit er beim
> Starten nicht direkt los scannt

Hat das Auswirkung auf bluetooth proxy?

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Nicht vergessen continues: false beim tracker einzubauen damit er beim
>> Starten nicht direkt los scannt
>
> Hat das Auswirkung auf bluetooth proxy?

Ne wird ja beim onconnect wieder auf true gesetzt

[Artur K. (artur_k638)]

Artur K. schrieb:
> Bericht. Board geänderten und das mit wifi was du meintest. Heute morgen
> istv noch alles gut.
Bericht, Nach der Arbeit die gleiche Geschichte. Daa mit continues: 
false hatte ich noch nicht.

[Dirk (digaus)]

Artur K. schrieb:
> Artur K. schrieb:
>> Bericht. Board geänderten und das mit wifi was du meintest. Heute morgen
>> istv noch alles gut.
>
> Bericht, Nach der Arbeit die gleiche Geschichte. Daa mit continues:
> false hatte ich noch nicht.

Und vllt mal den Uptime sensor einbauen. Dann siehst du ob er neu 
gestartet hat:
https://esphome.io/components/sensor/uptime.html

[Artur K. (artur_k638)]

Dirk schrieb:
> Und vllt mal den Uptime sensor einbauen. Dann siehst du ob er neu
> gestartet hat:

Er startet ja nicht neu, reagiert nicht, wenn man lock oder unlock 
macht, oder Status, kommt im log warten auf Verbindung

[Artur K. (artur_k638)]

Dirk schrieb:
> Ne wird ja beim onconnect wieder auf true gesetzt

bei onconnect von Wifi? sehe ich nicht im yaml, und habe jetzt 
continues: false gesetzt, bei esp32_ble_tracker richtig? und es wollte 
nicht mit Schloss sich verbinden, stand die ganze zeit waiting for 
connection

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Ne wird ja beim onconnect wieder auf true gesetzt
>
> bei onconnect von Wifi? sehe ich nicht im yaml, und habe jetzt
> continues: false gesetzt, bei esp32_ble_tracker richtig? und es wollte
> nicht mit Schloss sich verbinden, stand die ganze zeit waiting for
> connection

Ja bei onconnect muss du das continues: true setzen

[Dirk (digaus)]

Steht auch in der Beispiel yaml

Wenn du das nicht drin hattest ist klar, dass es nicht funktioniert hat. 
Dann hat er sich beim WiFi Verlust disconnected und nicht wieder neu 
verbunden

[Artur K. (artur_k638)]

Dirk schrieb:
> Steht auch in der Beispiel yaml
>
> Wenn du das nicht drin hattest ist klar, dass es nicht funktioniert hat.
> Dann hat er sich beim WiFi Verlust disconnected und nicht wieder neu
> verbunden

oh sorry, die ganze Zeit falsch geguckt, dachte zuerst es betrifft nur 
ESP32 C3

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Steht auch in der Beispiel yaml
>> Wenn du das nicht drin hattest ist klar, dass es nicht funktioniert hat.
>> Dann hat er sich beim WiFi Verlust disconnected und nicht wieder neu
>> verbunden
>
> oh sorry, die ganze Zeit falsch geguckt, dachte zuerst es betrifft nur
> ESP32 C3

Beim C3 geht's ohne auf jeden Fall nicht, bei den anderen Boards 
wahrscheinlich auch sinnvoll

[Artur K. (artur_k638)]

Uptime 5 Stunden, esp läuft wie gewohnt weiter, nur öffnen schließen tut 
nicht. Waiting for connection obwohl established. Wenn ich zuhause bin 
versuche ich direkt mit app mich verbinden und öffnen. Sonst muss ich 
wohl auf dauer Verbindung verzichten. Hane schon mir 2 Buttons erstellt 
die korrekt connecten öffnen/schließen und disconnecten.

[Dirk (digaus)]

Poste mal deine aktuelle yaml

[Artur K. (artur_k638)]

Dirk schrieb:
> Poste mal deine aktuelle yaml

 esphome:
  name: eqiva-bridge
  friendly_name: Eqiva Bridge

esp32:
  board: wemos_d1_mini32
  framework:
    type: esp-idf

logger:

api:
  encryption:
    key: !secret api_encryption_key
  services:
  - service: settings
    variables:
      turn_left: bool
      key_horizontal: bool
      lock_turns: int
    then:
      - eqiva_key_ble.settings:
          turn_left: !lambda 'return turn_left;'
          key_horizontal: !lambda 'return key_horizontal;'
          lock_turns: !lambda 'return lock_turns;'

  - service: fastconnect
    then:
      - eqiva_key_ble.connect:
          mac_address: 00:1a:22:18:3c:76
          user_id: 1
          user_key: 601dde3b2904999e289f1b1079c258fe

  - service: connect
    variables:
      mac_address: string
      user_id: int
      user_key: string
    then:
      - eqiva_key_ble.connect:
          mac_address: !lambda 'return mac_address;'
          user_id: !lambda 'return user_id;'
          user_key: !lambda 'return user_key;'
  - service: disconnect
    then:
      - eqiva_key_ble.disconnect:
  - service: pair
    variables:
      card_key: string
    then:
      - eqiva_key_ble.pair:
          card_key: !lambda 'return card_key;'
  - service: lock
    then:
      - eqiva_key_ble.lock:
  - service: unlock
    then:
      - eqiva_key_ble.unlock:
  - service: open
    then:
      - eqiva_key_ble.open:
  - service: status
    then:
      - eqiva_key_ble.status:

ota:
  password: !secret esphome_api_password

wifi:
  ssid: !secret wifi_ssid_salon
  password: !secret wifi_password
  ap:
    ssid: "key-ble Fallback Hotspot"
    password: "hvkiA8QRZbD8"
  # Use below to apply saved input parameters on boot
  on_connect:
    - eqiva_key_ble.connect:
        mac_address: 00:1a:22:18:3c:76
        user_id: 1
        user_key: 601dde3b2904999e289f1b1079c258fe
        #mac_address: !lambda 'return id(mac_address).state;' 
        #user_id: !lambda 'return id(user_id).state;'
        #user_key: !lambda 'return id(user_key).state;'
    - esp32_ble_tracker.start_scan:
        continuous: true
  on_disconnect:
     - esp32_ble_tracker.stop_scan:
      

#button, number and text input for pairing and setting mac/user_id/user-key via UI
button:
  - platform: restart
    name: "Eqiva Lock Restart"
  - platform: safe_mode
    name: "Eqiava Lock Restart (Safe Mode)"  
  - platform: template
    id: ble_fastconnect
    name: "Fast Connect"
    icon: "mdi:bluetooth-connect"
    on_press:
      - eqiva_key_ble.connect:
          mac_address: 00:1a:22:18:3c:76
          user_id: 1
          user_key: 601dde3b2904999e289f1b1079c258fe
  - platform: template
    id: ble_lock_lock
    name: "Lock lock"
    icon: "mdi:lock"
    on_press:
      - eqiva_key_ble.lock:
  - platform: template
    id: ble_lock_unlock
    name: "Lock unlock"
    icon: "mdi:lock-open"
    on_press:
      - eqiva_key_ble.unlock:
  - platform: template
    id: lock_disconnect
    name: "lock"
    icon: "mdi:lock"
    on_press:
      - eqiva_key_ble.connect:
          mac_address: 00:1a:22:18:3c:76
          user_id: 1
          user_key: 601dde3b2904999e289f1b1079c258fe
      - wait_until:
          condition:
            text_sensor.state:
              id: lock_ble_state
              state: 'ESTABLISHED'
      - eqiva_key_ble.lock:
      - wait_until:
          condition:
            text_sensor.state:
              id: lock_status
              state: 'LOCKED'
      - eqiva_key_ble.disconnect:
  - platform: template
    id: unlock_disconnect
    name: "unlock"
    icon: "mdi:lock-open"
    on_press:
      - eqiva_key_ble.connect:
          mac_address: 00:1a:22:18:3c:76
          user_id: 1
          user_key: 601dde3b2904999e289f1b1079c258fe
      - wait_until:
          condition:
            text_sensor.state:
              id: lock_ble_state
              state: 'ESTABLISHED'
      - eqiva_key_ble.unlock:
      - wait_until:
          condition:
            text_sensor.state:
              id: lock_status
              state: 'UNLOCKED'
      - eqiva_key_ble.disconnect:
  - platform: template
    id: ble_settings
    name: BLE Settings _Save_
    icon: "mdi:content-save"
    disabled_by_default: true
    on_press:
      - eqiva_key_ble.connect:
          mac_address: !lambda 'return id(mac_address).state;' 
          user_id: !lambda 'return id(user_id).state;'
          user_key: !lambda 'return id(user_key).state;'
  
  - platform: template
    id: ble_disconnect
    name: Disconnect
    icon: "mdi:bluetooth-off"
    on_press:
      - eqiva_key_ble.disconnect:
  - platform: template
    id: ble_pair
    name: BLE Pair _Start_
    icon: "mdi:check-underline"
    disabled_by_default: true
    on_press:
      - eqiva_key_ble.pair:
          card_key: !lambda 'return id(card_key).state;' 

  - platform: template
    id: lock_settings
    name: Lock Settings _Apply_
    icon: "mdi:check-underline"
    on_press:
      - eqiva_key_ble.settings:
          turn_left: !lambda 'return id(direction).state == "Left";' 
          key_horizontal: !lambda 'return id(position).state == "Horizontal";'
          lock_turns: !lambda 'return atoi(id(turns).state.c_str());'
    disabled_by_default: true
  - platform: template
    id: ble_status
    name: Status
    icon: "mdi:bluetooth"
    on_press:
      - eqiva_key_ble.status:
          
number:
  - platform: template
    mode: box
    name: BLE Settings User ID
    id: user_id
    max_value: 7
    min_value: 0
    step: 1
    optimistic: true
    restore_value: true
    disabled_by_default: true

text:
  - platform: template
    mode: text
    name: BLE Settings Mac Address
    id: mac_addr
    optimistic: true
    restore_value: true
    disabled_by_default: true
  - platform: template
    mode: text
    name: BLE Settings User Key
    id: user_key
    optimistic: true
    restore_value: true
    disabled_by_default: true
  - platform: template
    mode: text
    name: BLE Pair Card Key
    id: card_key
    optimistic: true
    disabled_by_default: true

select:
  - platform: template
    name: Lock Settings Close Direction
    id: direction
    options:
     - "Left"
     - "Right"
    optimistic: true
    disabled_by_default: true
  - platform: template
    name: Lock Settings Key Position
    id: position
    options:
     - "Vertical"
     - "Horizontal"
    optimistic: true
    disabled_by_default: true
  - platform: template
    name: Lock Settings Turns
    id: turns
    options:
     - "1"
     - "2"
     - "3"
     - "4"
    optimistic: true
    disabled_by_default: true

sensor:
  - platform: uptime
    name: Uptime Sensor

captive_portal:

esp32_ble_tracker:
  scan_parameters:
    continuous: false
    window: 300ms

bluetooth_proxy:
  active: true   

binary_sensor:
  - platform: ble_presence
    ibeacon_uuid: '5058f82a-fca1-419b-827b-a18dcae463b9'
    name: "Artur S23U Garage"

web_server:
  include_internal: true
  local: false
  port: 80

external_components:
  source: github://digaus/esphome-components-eqiva
  refresh: 0s

eqiva_ble:

eqiva_key_ble:
  #id: key_ble
  #mac_address: 00:1a:22:18:3c:76
  #user_id: 1
  #user_key: 601dde3b2904999e289f1b1079c258fe

text_sensor: 
  - platform: eqiva_key_ble
    mac_address: 
      name: "Mac Address"
      id: mac_address
    lock_status: 
      name: "Lock Status"
      id: lock_status
    low_battery:
      name: "Low Battery"
    lock_ble_state:
      name: "Lock BLE State"
      id: lock_ble_state
    user_id:
      name: "User ID"
    user_key:
      name: "User Key"
    # on_raw_value:
            # then:   Do stuff on state change (!lambda "return x") 
time:
  - platform: sntp
    # ...
    on_time:
      # Every 5 minutes
      - seconds: 0
        minutes: /4
        then:
          - eqiva_key_ble.status:

lock:
  - platform: template
    name: "Lock"
    lambda: |-
      if (id(lock_status).state == "LOCKED") {
        return LOCK_STATE_LOCKED;
      } else if (id(lock_status).state == "UNLOCKED" || id(lock_status).state == "OPENED") {
        return LOCK_STATE_UNLOCKED;
      } else if(id(lock_status).state == "MOVING") {
        return {};
      } else if (id(lock_status).state == "UNKNOWN") {
        return LOCK_STATE_JAMMED;
      } 
      return LOCK_STATE_LOCKED;
    lock_action:
      #- eqiva_key_ble.connect:
          #mac_address: 00:1a:22:18:3c:76
          #user_id: 1
          #user_key: 601dde3b2904999e289f1b1079c258fe
      #- wait_until:
          #condition:
            #text_sensor.state:
              #id: lock_ble_state
              #state: 'ESTABLISHED'
      - eqiva_key_ble.lock:
      #- wait_until:
          #condition:
            #text_sensor.state:
              #id: lock_status
              #state: 'LOCKED'
      #- eqiva_key_ble.disconnect:
    unlock_action:
      #- eqiva_key_ble.connect:
          #mac_address: 00:1a:22:18:3c:76
          #user_id: 1
          #user_key: 601dde3b2904999e289f1b1079c258fe
      #- wait_until:
          #condition:
            #text_sensor.state:
              #id: lock_ble_state
              #state: 'ESTABLISHED'
      - eqiva_key_ble.unlock:
      #- wait_until:
          #condition:
            #text_sensor.state:
              #id: lock_status
              #state: 'UNLOCKED'
      #- eqiva_key_ble.disconnect:

[Dirk (digaus)]

Was mir nur auffällt ist, dass du die ID auskommentiert hast. Evlt. 
liegt es daran? Hast du mal ohne den bluetooth proxy probiert?

Hab mal den log erweitert, dann können wir sehen warum er in "Waiting 
for connection..." reingeht

[Artur K. (artur_k638)]

Dirk schrieb:
> Was mir nur auffällt ist, dass du die ID auskommentiert hast. Evlt.
> liegt es daran? Hast du mal ohne den bluetooth proxy probiert?
>
> Hab mal den log erweitert, dann können wir sehen warum er in "Waiting
> for connection..." reingeht
Ohne proxy war das selbe. Wegen ID wo meinst du genau?

[Artur K. (artur_k638)]

Also gerade getestet, über esp konnte nicht aufmachen. Über app geht, 
liegt dann an esp, habe aber gestern einen andere geflasht

[Artur K. (artur_k638)]

Fehler beim ota

src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp:358:21: error: format '%s' expects a matching 'char*' argument [-Werror=format=]
       ESP_LOGI(TAG, "Waiting for connection... (sendingNonce: %s) (remoteSessionNonce: %s) (remoteSessionNonce: %s) (clientStateEstablished: %s)", sendingNonce ? 'true' : 'false', clientState.remote_session_nonce.length() > 0 ? 'true' : 'false', this->state() == espbt::ClientState::ESTABLISHED ? 'true' : 'false');
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/esphome/core/log.h:72:36: note: in definition of macro 'ESPHOME_LOG_FORMAT'
 #define ESPHOME_LOG_FORMAT(format) format
                                    ^~~~~~
src/esphome/core/log.h:151:28: note: in expansion of macro 'esph_log_i'
 #define ESP_LOGI(tag, ...) esph_log_i(tag, __VA_ARGS__)
                            ^~~~~~~~~~
src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp:358:7: note: in expansion of macro 'ESP_LOGI'
       ESP_LOGI(TAG, "Waiting for connection... (sendingNonce: %s) (remoteSessionNonce: %s) (remoteSessionNonce: %s) (clientStateEstablished: %s)", sendingNonce ? 'true' : 'false', clientState.remote_session_nonce.length() > 0 ? 'true' : 'false', this->state() == espbt::ClientState::ESTABLISHED ? 'true' : 'false');
       ^~~~~~~~
Compiling .pioenvs/eqiva-bridge/src/esphome/components/json/json_util.o
cc1plus: some warnings being treated as errors
*** [.pioenvs/eqiva-bridge/src/esphome/components/eqiva_key_ble/eqiva_key_ble.o] Error 1
========================== [FAILED] Took 4.87 seconds ==========================

[Dirk (digaus)]

Artur K. schrieb:
> Fehler beim ota
>

Probier mal nochmal.

Bzgl ID einmal nach id: key-ble suchen

[Artur K. (artur_k638)]

Dirk schrieb:
> Artur K. schrieb:
>> Fehler beim ota
>>
>
> Probier mal nochmal.
>
> Bzgl ID einmal nach id: key-ble suchen

Klappt trotzdem nicht

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Artur K. schrieb:
>>> Fehler beim ota
>>
>> Probier mal nochmal.
>> Bzgl ID einmal nach id: key-ble suchen
>
> Klappt trotzdem nicht

Installieren? Bei mir schon. Mal nen Clean build Files machen?

[Artur K. (artur_k638)]

Dirk schrieb:
> Installieren? Bei mir schon. Mal nen Clean build Files machen?

Jap clean gemacht, komisch, starte mal esp neu und probiere noch mal

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Installieren? Bei mir schon. Mal nen Clean build Files machen?
>
> Jap clean gemacht, komisch, starte mal esp neu und probiere noch mal

refresh: 0s drin stehen?

[Artur K. (artur_k638)]

Dirk schrieb:
> refresh: 0s drin stehen?

Ja natürlich

[Artur K. (artur_k638)]

In file included from src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp:2:
src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp: In member function 'bool esphome::eqiva_key_ble::EqivaKeyBle::sendMessage(eQ3Message::Message*, bool)':
src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp:358:21: error: format '%s' expects a matching 'char*' argument [-Werror=format=]
       ESP_LOGI(TAG, "Waiting for connection... (sendingNonce: %s) (remoteSessionNonce: %s) (remoteSessionNonce: %s) (clientStateEstablished: %s)", sendingNonce ? "true" : "false", clientState.remote_session_nonce.length() > 0 ? "true" : "false", this->state() == espbt::ClientState::ESTABLISHED ? "true" : "false");
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/esphome/core/log.h:72:36: note: in definition of macro 'ESPHOME_LOG_FORMAT'
 #define ESPHOME_LOG_FORMAT(format) format
                                    ^~~~~~
src/esphome/core/log.h:151:28: note: in expansion of macro 'esph_log_i'
 #define ESP_LOGI(tag, ...) esph_log_i(tag, __VA_ARGS__)
                            ^~~~~~~~~~
src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp:358:7: note: in expansion of macro 'ESP_LOGI'
       ESP_LOGI(TAG, "Waiting for connection... (sendingNonce: %s) (remoteSessionNonce: %s) (remoteSessionNonce: %s) (clientStateEstablished: %s)", sendingNonce ? "true" : "false", clientState.remote_session_nonce.length() > 0 ? "true" : "false", this->state() == espbt::ClientState::ESTABLISHED ? "true" : "false");
       ^~~~~~~~
Compiling .pioenvs/eqiva-bridge/src/esphome/components/esp32_ble/ble_uuid.o
cc1plus: some warnings being treated as errors
Compiling .pioenvs/eqiva-bridge/src/esphome/components/esp32_ble_client/ble_characteristic.o
*** [.pioenvs/eqiva-bridge/src/esphome/components/eqiva_key_ble/eqiva_key_ble.o] Error 1
========================= [FAILED] Took 21.68 seconds =========================

[Dirk (digaus)]

Komisch dass er bei mir nicht meckert.

Probier es jetzt mal

[Artur K. (artur_k638)]

Leider nein, sehr komisch wieso er bei mir meckert

[Dirk (digaus)]

Artur K. schrieb:
> Leider nein, sehr komisch wieso er bei mir meckert

Was meckert er denn jetzt?

Clean Build Files gemacht?

[Artur K. (artur_k638)]

Dirk schrieb:
> Was meckert er denn jetzt?
> Clean Build Files gemacht?

Das selbe immer noch, und ja

[Dirk (digaus)]

Artur K. schrieb:
> Dirk schrieb:
>> Was meckert er denn jetzt?
>> Clean Build Files gemacht?
>
> Das selbe immer noch, und ja

Hab's auf %d geändert. Er sollte also nicht mehr den selben Fehler haben 
.?

[Artur K. (artur_k638)]

In file included from 
src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp:2:
src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp: In member 
function 'bool 
esphome::eqiva_key_ble::EqivaKeyBle::sendMessage(eQ3Message::Message*, 
bool)':
src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp:358:21: error: 
format '%d' expects a matching 'int' argument [-Werror=format=]
       ESP_LOGI(TAG, "Waiting for connection... (sendingNonce: %d) 
(remoteSessionNonce: %d) (remoteSessionNonce: %d) 
(clientStateEstablished: %d)", sendingNonce, 
clientState.remote_session_nonce.length() > 0, this->state() == 
espbt::ClientState::ESTABLISHED);
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/esphome/core/log.h:72:36: note: in definition of macro 
'ESPHOME_LOG_FORMAT'
 #define ESPHOME_LOG_FORMAT(format) format
                                    ^~~~~~
src/esphome/core/log.h:151:28: note: in expansion of macro 'esph_log_i'
 #define ESP_LOGI(tag, ...) esph_log_i(tag, _VA_ARGS_)
                            ^~~~~~~~~~
src/esphome/components/eqiva_key_ble/eqiva_key_ble.cpp:358:7: note: in 
expansion of macro 'ESP_LOGI'
       ESP_LOGI(TAG, "Waiting for connection... (sendingNonce: %d) 
(remoteSessionNonce: %d) (remoteSessionNonce: %d) 
(clientStateEstablished: %d)", sendingNonce, 
clientState.remote_session_nonce.length() > 0, this->state() == 
espbt::ClientState::ESTABLISHED);
       ^~~~~~~~
Compiling 
.pioenvs/eqiva-bridge/src/esphome/components/esp32_ble/ble_uuid.o
cc1plus: some warnings being treated as errors
*** 
[.pioenvs/eqiva-bridge/src/esphome/components/eqiva_key_ble/eqiva_key_bl 
e.o]  Error 1
========================= [FAILED] Took 17.12 seconds 
=========================

[Dirk (digaus)]

Sehr seltsam.

Bei mir funktioniert es ohne Probleme ...

[Artur K. (artur_k638)]

Dirk schrieb:
> Sehr seltsam.
> Bei mir funktioniert es ohne Probleme ...

Ich versuche morgen ein neues Projekt anlegen und mit Kabel Flashen

[Artur K. (artur_k638)]

Habe testweise einfach neues Projekt erstattet, Stumpf den Code aus git 
kopiert. Und kommt auch dieses error

[Dirk (digaus)]

Artur K. schrieb:
> Habe testweise einfach neues Projekt erstattet, Stumpf den Code
> aus git kopiert. Und kommt auch dieses error

Hab den log jetzt raus genommen. Geht's jetzt wieder?

[Artur K. (artur_k638)]

Jap, jetzt geht's

[Artur K. (artur_k638)]

Versuche ist es so zu programmieren, dass es immer disconnected ist und 
nur bei Bedarf, connected.
Bei Start habe ich es so

wifi:
  ssid: !secret wifi_ssid_salon
  password: !secret wifi_password
  on_connect:
    - eqiva_key_ble.connect:
        mac_address: 00:1a:22:18:3c:76
        user_id: 1
        user_key: 601dde3b2904999e289f1b1079c258fe
    - esp32_ble_tracker.start_scan:
        continuous: true
    - delay: 30s
    - eqiva_key_ble.disconnect:
  on_disconnect:
     - esp32_ble_tracker.stop_scan:

Wollte statt delay wait intil einbauen, aber nicht geschaft, wollte auch 
Status Unknown prüfen bei lock_status.
Nur wenn Schloss nicht verbunden ist, scannt wr immer nach dem Schoss, 
ist das kein Problem? Oder soll ich da was machen?

[Hendrik F. (henfri)]

Hallo,

eine kurze Rückmeldung zur esphome Version:
Das ganze läuft jetzt seit einigen Tagen stabil. Ich habe keine Probleme 
mit Abstürzen oder Verbindungsproblemen.

Allerdings rief mich mein Sohn gestern an und kam mit der App nicht ins 
Haus. Vermutlich hatte esphome gerade eine Verbindung.

Was muss ich machen, damit nicht permanent eine Verbindung besteht?
Ich vermute, unten ist das .disconnect zu aktivieren.

    lock_action:
      - eqiva_key_ble.connect:
          mac_address: 00:x # Schuppen
          user_id: 1
          user_key: x
      - eqiva_key_ble.lock:
      #- eqiva_key_ble.disconnect:

Aber das alleine kann es ja nicht sein, denn es wurde lange vorher nicht 
gelockt.

Darüber hinaus habe ich

time:
  - platform: sntp
    timezone: Europe/Berlin
    servers:
     - 0.pool.ntp.org
     - 1.pool.ntp.org
     - 2.pool.ntp.org
    on_time:
      # Every 4 minutes get Status, to ensure quick reaction
      - cron: '00 /4 21-23 * * *'
        then:
          - eqiva_key_ble.status:

Ich vermute, dass dies die Verbindung aufrecht hält und ich auch hier 
ein .disconnect hinzufügen muss. Richtig?

Noch eine Frage
Jetzt habe ich den Controller in einer Automatisierung genutzt. 
Funktioniert auch wunderbar.
Was mich allerdings gewundert hat: Es werden mehrere Services angeboten, 
siehe Anhang.
Warum gibt es da Lock 1 und Lock 2?

Gruß,
Hendrik

[Dirk (digaus)]

Bzgl. der Locks war das lediglich ein Beispiel wie man zwei Schlösser 
ansteuern könnte.

An dem time Part müsstest du nichts ändern.

Das disconnect darfst du erst nach 15s Verzögerung machen. (siehe ein 
Post vor dir) dann sollte es klappen.

Allerdings musst du beachten, dass dann über den ESP die Ansteuerung ca. 
12 Sekunden dauern kann.

Alternativ könntest du ja den benötigten Personen auch via HA App einen 
Zugriff gewähren und könntest so den ESP dauerhaft verbunden lassen.

Eine andere Möglichkeit wäre mit dem ESP auch einen BLE Controller zu 
erstellen und sich damit zu verbinden. Quasi dann als Bridge. So könnte 
man auch ein Schloss simulieren.

Aber das wäre nochmal ordentlich Aufwand.

[Hendrik F. (henfri)]

Hallo,

> Bzgl. der Locks war das lediglich ein Beispiel wie man zwei Schlösser
ansteuern könnte.

Das heißt, das ist hart-kodiert und nicht irgendwie durch meine Yaml 
erzeugt?
Ist aber (noch?) nicht vollständig implementiert?

> Das disconnect darfst du erst nach 15s Verzögerung machen. (siehe ein
Post vor dir) dann sollte es klappen.
> Allerdings musst du beachten, dass dann über den ESP die Ansteuerung ca.
12 Sekunden dauern kann.

D.h. wenn ich beide Locks bedienen will, muss ich den Delay wie lange 
machen?
15s ist natürlich recht unschön. Bei uns ist der Usecase, dass wir einen 
"Alles-Aus" taster haben. Da will man natürlich nicht 15s warten, ob die 
Tür zu ging (vielleicht steht sie ja auf).

Siehst du eine Möglichkeit, das noch zu verbessern?

> An dem time Part müsstest du nichts ändern.
Dazu zwei Fragen:
1) ich brauche den Status eigentlich nicht. Kann das dann nicht raus?
2) war es nicht so, dass die Verbindung ca 4 minuten aufgebaut bleibt?


Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
>
>> Bzgl. der Locks war das lediglich ein Beispiel wie man zwei Schlösser
> ansteuern könnte.
>
> Das heißt, das ist hart-kodiert und nicht irgendwie durch meine Yaml
> erzeugt?
> Ist aber (noch?) nicht vollständig implementiert?
>
>> Das disconnect darfst du erst nach 15s Verzögerung machen. (siehe ein
> Post vor dir) dann sollte es klappen.
>> Allerdings musst du beachten, dass dann über den ESP die Ansteuerung ca.
> 12 Sekunden dauern kann.
>
> D.h. wenn ich beide Locks bedienen will, muss ich den Delay wie lange
> machen?
> 15s ist natürlich recht unschön. Bei uns ist der Usecase, dass wir einen
> "Alles-Aus" taster haben. Da will man natürlich nicht 15s warten, ob die
> Tür zu ging (vielleicht steht sie ja auf).
>
> Siehst du eine Möglichkeit, das noch zu verbessern?
>
>> An dem time Part müsstest du nichts ändern.
> Dazu zwei Fragen:
> 1) ich brauche den Status eigentlich nicht. Kann das dann nicht raus?
> 2) war es nicht so, dass die Verbindung ca 4 minuten aufgebaut bleibt?
>
> Gruß,
> Hendrik

1. Das zweite Lock sollte nur von deiner yaml kommen. Am besten mal auf 
github die readme anschauen

2. Von "nicht verbunden" bis "verbunden und Befehl abgesendet" dauert es 
ca. 12 Sekunden. Schneller schafft der ESP das anscheinend nicht. 
Deshalb der Disconnect nach 15 Sekunden, da sonst der Befehl nicht 
durchgeht.

3. Status kann raus wenn du ihn nicht brauchst.

[Hendrik F. (henfri)]

Verstehe.
In meiner Logik muss ich aber dann etwas mehr als 15s verwenden, oder?
Ich habe in der Yaml jetzt ein Disconnect nach 15s und in der Logik 
einen Abstand zwischen den Beiden Lock Befehlen von 20s.

Das Ganze ist ok für eine Logik. Aber was passiert, wenn meine 
Mitbewohnerin ungeduldig ist und die einzelnen Lock-Knöpfe in der App zu 
schnell hintereinander drückt?


> Das zweite Lock sollte nur von deiner yaml kommen. Am besten mal auf
github die readme anschauen

Ich meine das "Sperre Lock 2". Das kommt nicht aus der YAML. In der YAML 
heißen sie Hintertür und Schuppen.



Gruß,
Hendrik

[Hendrik F. (henfri)]

Hallo,

der Wlan-Empfang ist recht schlecht und ich würde mal einen ESP mit 
externer Antenne probieren.
Hier gibt es mehrere:
https://de.aliexpress.com/item/4000090521976.html
ESP32-32U CP2102
ESP32-32U CH9102X

https://de.aliexpress.com/item/1005005727605631.html
ESP-WROOM-32S CH340

Die zweite Bezeichnung ist ja nur der USB-Adapber. Ich denke, das ist 
nicht besonders relevant.

Aber 32U oder 32S?

Was ist zu empfehlen?

Gruß,
Hendrik

[Hendrik F. (henfri)]

Hallo,

ich habe jetzt zwei neue ESPs (mit externen Antennen) - einer pro Lock.
Jetzt würde ich gerne das Pairing aus dem ESP heraus ausprobieren.

Was ist denn der "Pair Card Key"?
a) das was unter dem QR Code steht
b) der dekodierte QR Code

Ich habe jetzt leider im Key-Feld zu viel stehen (es war sehr klein, ich 
habe da den Key (a) reinkopiert, nachdem (a) drin steht.
Außerdem habe ich einen User_id eingegeben, obwohl der vom Lock vergeben 
werden soll. Wie kann ich diese Werte zurücksetzen?

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo,
> ich habe jetzt zwei neue ESPs (mit externen Antennen) - einer pro Lock.
> Jetzt würde ich gerne das Pairing aus dem ESP heraus ausprobieren.
> Was ist denn der "Pair Card Key"?
> a) das was unter dem QR Code steht
> b) der dekodierte QR Code
> Ich habe jetzt leider im Key-Feld zu viel stehen (es war sehr klein, ich
> habe da den Key (a) reinkopiert, nachdem (a) drin steht.
> Außerdem habe ich einen User_id eingegeben, obwohl der vom Lock vergeben
> werden soll. Wie kann ich diese Werte zurücksetzen?
> Gruß,
> Hendrik

Card Key ist der QR-Code. Abscannen und einfügen. Danach auf Pair 
drücken (nachdem das Schloss verbunden ist und sich im pair Modus 
befindet)

Dabei sollte egal sein ob schon was in user_id drin steht.

[Hendrik F. (henfri)]

Das wären geschätzt 50 Stellen, beginnend mit m001?

[Dirk (digaus)]

Hendrik F. schrieb:
> Das wären geschätzt 50 Stellen, beginnend mit m001?

Ja

[Hendrik F. (henfri)]

Hallo,

danke für deine Antworten.
Das klappt leider nicht:

15:05:52  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:05:53  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:05:55  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:05:57  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:05:59  [D]  [button:010]  
'BLE Pair _Start_' Pressed.
15:05:59  [I]  [eqiva_key_ble:272]  
CardKey: 43axxxf04
15:05:59  [I]  [eqiva_key_ble:273]  
Please press and hold open button for 5 seconds to enter pairing mode
15:05:59  [I]  [eqiva_key_ble:274]  
Trying to pair...
15:05:59  [I]  [eqiva_key_ble:358]  
Waiting for connection...
15:05:59  [I]  [eqiva_key_ble:360]  
Reason: exchanging nonce
15:05:59  [I]  [eqiva_key_ble:363]  
Reason: no remote session
15:05:59  [I]  [eqiva_key_ble:366]  
Reason: lock not connected
15:06:00  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:06:02  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:06:03  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:06:04  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:06:07  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:06:12  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A:xx:xx:A6:96) (UUID): 0x1A00  (Name): KEY-BLE
15:06:15  [I]  [eqiva_ble:015]  
Found Eqiva device (MAC: 00:1A

Anbei auch ein Screenshot der Einstellungen.

Siehst du (m)einen Fehler?

Gruß,
Hendrik

[Dirk (digaus)]

Hendrik F. schrieb:
> Hallo...

Befindet sich das Schloss im Pairing Modus?

[Hendrik F. (henfri)]

Ja, leuchtet gelb. 5s gedrückt.

[Dirk (digaus)]

Hendrik F. schrieb:
> Ja, leuchtet gelb. 5s gedrückt.

Probier es mal öfter. Manchmal hat's bei mir auch nicht geklappt.

Ansonsten Mal 255 bei User ID eintragen.

[Ömer B. (mer_b)]

Hallo. zunächst einmal vielen Dank für die tolle Arbeit. Darf ich 
freundlicherweise eine Frage stellen? Um ESP32 mit Ethernet in Ihrem 
Projekt zu verwenden, reicht es aus, die WLAN-Konfiguration aus der 
Yaml-Datei zu entfernen und die erforderliche Ethernet-Konfiguration 
hinzuzufügen? Und wenn wir den WiFi-Bereich entfernen, wo sollten wir 
die Ereignisse „esp32_ble_tracker.start_scan“ und 
„esp32_ble_tracker.stop_scan“ hinzufügen?

[Dirk (digaus)]

Ömer B. schrieb:
> Hallo. zunächst einmal vielen Dank für die tolle Arbeit. Darf ich
> freundlicherweise eine Frage stellen? Um ESP32 mit Ethernet in Ihrem
> Projekt zu verwenden, reicht es aus, die WLAN-Konfiguration aus der
> Yaml-Datei zu entfernen und die erforderliche Ethernet-Konfiguration
> hinzuzufügen? Und wenn wir den WiFi-Bereich entfernen, wo sollten wir
> die Ereignisse „esp32_ble_tracker.start_scan“ und
> „esp32_ble_tracker.stop_scan“ hinzufügen?

Korrekt, kannst dann einfach beim esp32_ble_tracker das continuous: 
false rausnehmen.

Dann startet er automatisch.

[Hendrik F. (henfri)]

Hallo,
>> Ja, leuchtet gelb. 5s gedrückt.
>
> Probier es mal öfter. Manchmal hat's bei mir auch nicht geklappt.
>
> Ansonsten Mal 255 bei User ID eintragen.

17:13:08  [D]  [number:054]  
'BLE Settings User ID' - Setting number value
17:13:08  [W]  [number:109]  
'BLE Settings User ID' - Value 255.000000 must not be greater than maximum 7.000000

Das wird abgelehnt.
Ich probiere es einfach noch ein paar mal. (Edit: Hat geklappt. 
Vielleicht nimmst du diesen "Trick" in die Readme auf).
Kann ich sonst in HomeAssistant, oder dem UI von EspHome auf dem 
Controller die UserID und den UserKey eingeben?

Habe ich ja noch aus der keyble instanz.

Gruß,
Hendrik

[Ömer B. (mer_b)]

Können wir durch den Einsatz des Ethernet-Moduls dauerhafte Verbindungen 
für zwei Schlösser gleichzeitig aufrechterhalten?

[Dirk (digaus)]

Ömer B. schrieb:
> Können wir durch den Einsatz des Ethernet-Moduls dauerhafte
> Verbindungen für zwei Schlösser gleichzeitig aufrechterhalten?

Wahrscheinlich kann man das auch noch via Wifi hinkriegen, aber bei mir 
läuft's super und ich hab aktuell nicht die Zeit da weiter zu machen^^

[Ömer B. (mer_b)]

Es tut mir leid, aber ich versuche stundenlang herauszufinden, wie man 
zwei Schlösser konfiguriert. Kann jemand eine Beispiel-YAML-Datei für 
zwei Schlösser teilen?

[Hendrik F. (henfri)]

Such mal in meinen Beiträgen weiter oben.
Ansonsten suche ich es morgen für dich raus.

Aber im Prinzip hier
https://github.com/digaus/esphome-components-eqiva/blob/f4d2a60f7a19bb7046d3d6498e1ab43e8050336a/example.yaml
Ab Zeile 142 halt alles noch ein zweites Mal mit den Daten des zweiten 
Lock.


Aber du musst dann der Familie erklären nach der Bedienung des ersten 
Lock 15s zu warten, bevor das Zweite bedient wird.

[Hendrik F. (henfri)]

Hallo,

das Pairing hatte ja eigentlich funktioniert, aber das Schloss reagiert 
nicht (mehr? ich kann mich nicht erinnern, ob ich es probiert hatte).
Im UI sehe ich, dass kein Key mehr eingetragen ist.

Im Log sehe ich:
17:55:35  [E]  [eqiva_key_ble:239]
User Error: (Key: , ID:  6)

Siehe auch Bild im Anhang.

Woran kann das liegen?

Gruß,
Hendrik

[Hendrik F. (henfri)]

Hallo,

hast du eine Idee für mich?
Ansonsten habe ich ja User-ID und Key aus einer manuellen Kopplung.
Gibt es eine Möglichkeit sie in der YAML einzubinden, ohne sie immer 
wieder zu wiederholen?

Gruß,
Hendrik

[Ömer B. (mer_b)]

Kann mir jemand den Code für das Hinzufügen von zwei Schlössern nennen?
Soweit ich das nach example.yaml verstehe, muss ich die folgenden Zeilen 
für die zweite Schlössern hinzufügen?

Wie wird das zweite Schloss gesteuert? Es gibt keine MAC-Adresse oder 
etwas anderes, das die Verbindung zwischen dem Code und dem Schloss 
herstellen kann.

lock:
  - platform: template
    name: "Lock 1"
    lambda: |-
      if (id(lock_status).state == "LOCKED") {
        return LOCK_STATE_LOCKED;
      } else if (id(lock_status).state == "UNLOCKED" || id(lock_status).state == "OPENED") {
        return LOCK_STATE_UNLOCKED;
      } else if(id(lock_status).state == "MOVING") {
        return {};
      } else if (id(lock_status).state == "UNKNOWN") {
        return LOCK_STATE_JAMMED;
      } 
      return LOCK_STATE_LOCKED;
    lock_action:
      - eqiva_key_ble.lock:
    unlock_action:
      - eqiva_key_ble.unlock:
    open_action:    
      - eqiva_key_ble.open:
  - platform: template
    name: "Lock 2"
    lambda: |-
      if (id(lock_status).state == "LOCKED") {
        return LOCK_STATE_LOCKED;
      } else if (id(lock_status).state == "UNLOCKED" || id(lock_status).state == "OPENED") {
        return LOCK_STATE_UNLOCKED;
      } else if(id(lock_status).state == "MOVING") {
        return {};
      } else if (id(lock_status).state == "UNKNOWN") {
        return LOCK_STATE_JAMMED;
      } 
      return LOCK_STATE_LOCKED;
    lock_action:
      - eqiva_key_ble.lock:
    unlock_action:
      - eqiva_key_ble.unlock:
    open_action:    
      - eqiva_key_ble.open:

[Hendrik F. (henfri)]

Hab ich ein Stück weiter oben verlinkt.

[Hendrik F. (henfri)]

Hallo,

ich habe jetzt zwei Controller für meine zwei Locks.
Ich verwende die Yaml von Github weitgehend unverändert - ich verwende 
lediglich einen eigenen Sensor um den Status des Locks zu ermitteln

Bei dem einen Lock funktioniert das wunderbar.
Beim zweiten Lock funktioniert der Status, aber das Kommandieren nicht.
Könntest du einmal auf die Logs schauen?
https://pastebin.com/GcNLgjbx

Gruß,
Hendrik

[Hendrik F. (henfri)]

Hallo,

ich habe nun rausgefunden, dass das eine Schloss dann wieder reagiert, 
wenn ich einmal "open" statt lock oder unlock mache.

Ich habe ja die Besonderheit, dass ich für den Status einen externen 
Sensor in der Schloss-Falle nutze.

Kann das damit zusammenhängen? Ich meine:
Gibt es eine Überprüfung, dass kein "Unlock" gesendet wird, wenn der 
interne Status schon "Unlocked" ist?

Anbei ein Vergleich der beiden Schlösser im Log


Gruß,
Hendrik

[Artur K. (artur_k638)]

@digaus
Hi,
ich hätte eine Frage. In Eqiva App kann man machen dass das Schloss 
automatisch schlisst. Kann man diese Zeiten in Esphome auslesen, bzw 
einstellen?

[Dirk (digaus)]

Bestimmt,

gibt auch noch ein Protokoll. Allerdings habe ich das nicht 
ausprobiert/implementiert da ich lieber eine besser Lösung mit einem 
Shelly Türkontakt und Automation löse.

[Artur K. (artur_k638)]

Dirk schrieb:
> Bestimmt,
>
> gibt auch noch ein Protokoll. Allerdings habe ich das nicht
> ausprobiert/implementiert da ich lieber eine besser Lösung mit einem
> Shelly Türkontakt und Automation löse.

Könnte ich auch, nur mein Gedanke war, dass wenn es lokal in dem Schloss 
passiert ist besser, weil wenn HA zB aus irgendeinen Grund nicht läuft, 
Schloss wird trotzdem schliessen.

[Dirk (digaus)]

Kannst ja auch direkt via ESP ne Automation machen ohne HA

[Artur K. (artur_k638)]

Dirk schrieb:
> Kannst ja auch direkt via ESP ne Automation machen ohne HA

Ja das auch, wäre es viel Aufwand für dich es zu implementieren?

[Holger (loetbadender)]

Hallo zusammen,
ich habe gerade versucht https://github.com/tc-maxx/esp32-keyble zum 
laufen zu bringen.
Leider gibt es Probleme beim aufbauen der BLE Verbindung. Der ESP32 
Startet wegen einer Exception neu. Hat zufällig jemand Erfahrung damit?
Serielle Ausgabe:

# WiFi disabled
*** get state ***
# Nonce exchange
# Searching ...
# Found device: 00:1a:22:0a:6c:9b
# RSSI: -61
# Connecting in tick
# Connecting...
# Connected in tick
Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception). 
Debug exception reason: Stack canary watchpoint triggered (BTU_TASK) 
Core  0 register dump:
PC      : 0x40097a47  PS      : 0x00060836  A0      : 0x8009748b  A1      : 0x3ffe46e0  
A2      : 0x3ffbf348  A3      : 0xb33fffff  A4      : 0x0000abab  A5      : 0x0000cdcd  
A6      : 0x00060823  A7      : 0x00060823  A8      : 0xb33fffff  A9      : 0xffffffff  
A10     : 0x3ffd6ecc  A11     : 0x3ffd1c78  A12     : 0x00000001  A13     : 0x00000000  
A14     : 0x003fffff  A15     : 0x3ffe482c  SAR     : 0x0000001a  EXCCAUSE: 0x00000001  
EXCVADDR: 0x00000000  LBEG    : 0x40091458  LEND    : 0x4009146e  LCOUNT  : 0x00000000  


Backtrace: 0x40097a44:0x3ffe46e0 0x40097488:0x3ffe4720 0x40095d57:0x3ffe4740 0x4014a2d1:0x3ffe4780 0x40149afe:0x3ffe47a0 0x4013e21d:0x3ffe47c0 0x4013d12b:0x3ffe47e0 0x40162635:0x3ffe4810 0x40162783:0x3ffe4830 0x401628c6:0x3ffe4850 0x401350a5:0x3ffe4890 0x401344da:0x3ffe4b20 0x4014e566:0x3ffe4b40 0x4014e6ac:0x3ffe4b80 0x4014eaba:0x3ffe4ba0 0x4014eb42:0x3ffe4e30 0x4014ecca:0x3ffe4e50 0x40139e41:0x3ffe4e70 0x401350e2:0x3ffe5110 0x40135595:0x3ffe53a0 0x40135f4d:0x3ffe5400 0x401372b0:0x3ffe5440 0x401372e6:0x3ffe5460 0x4014217d:0x3ffe5480 0x40133108:0x3ffe5610 0x4014a3d4:0x3ffe5630

ELF file SHA256: 0000000000000000

Rebooting...

[Al O. (cyber83)]

Hendrik F. schrieb:
> Hallo,
>
> ich habe nun rausgefunden, dass das eine Schloss dann wieder reagiert,
> wenn ich einmal "open" statt lock oder unlock mache.
>
>
> Gruß,
> Hendrik

Hendrik, das hat bei mir auch so angefangen und war dann ein 
hardwaredefekt.
siehe 
Beitrag "Re: Software zum Steuern des Türschlossantrieb "eqiva eQ-3 Bluetooth Smart Lock""

nicht dass du wegen dem gleichen problem gleich lange wie ich 
herummurkst ...

[Holger (loetbadender)]

Danke für deine Antwort. Das kann gut sein, das würde auch erklären 
warum mein Schloss seit einiger Zeit nur noch aufsperrt (egal welche 
Taste man drückt)
Es fängt auf jeden Fall an zu spinnen. Wenn man die Batterien wechselt 
funktioniert es wieder einige Zeit.

Ich habe noch zwei Schlösser ohne Key von eBay hier herumliegen, dann 
muss ich wohl an die Taster anlöten und extern steuern... Ich nehme an 
den Key kann man nicht auslesen?

[Artur K. (artur_k638)]

Moin zusammen,
wollte heute was in dem Code ändern, hatte aber auch esphome 
aktualisiert, und seit dem Verbindet es nicht mehr. Kann nicht 
herausfinden woran es liegt, Code habe ich jetzt zurück geändert, 
trotzdem funktioniert nicht, weiß aber nicht mehr welche Version von 
Esphome es vorher war.

[Dirk (digaus)]

Artur K. schrieb:
> Moin zusammen,
> wollte heute was in dem Code ändern, hatte aber auch esphome
> aktualisiert, und seit dem Verbindet es nicht mehr. Kann nicht
> herausfinden woran es liegt, Code habe ich jetzt zurück geändert,
> trotzdem funktioniert nicht, weiß aber nicht mehr welche Version von
> Esphome es vorher war.

Aktuell kann man diesen workaround nutzen: 
https://github.com/digaus/esphome-components-eqiva/issues/11#issuecomment-1965232328

Muss noch Anpassungen machen für die neue esphome Version sobald ich 
Zeit finde.

[Artur K. (artur_k638)]

oh danke sehr

[Dirk (digaus)]

Artur K. schrieb im Beitrag #7641524:
> Wäre es möglich Status locking unlocking hinzufugen? hat das
> jemand gemacht?

Denke ist möglich indem du den aktuellen Status des Locks vergleichst 
und sofern der Status von Eqiva BLE Lock "MOVING" ist und der aktuelle 
Status z.b. "LOCKED" dann würde er ja gerade aufschließen.

Kann sein, dass diese stati in Homekit nicht funktionieren weshalb ich 
sie nicht als Beispiel abgebildet hatte. Oder dir gab's noch nicht 
immer^^

[Christian (tramcs)]

Hallo, ich bin Anfänger in Sachen Home Assistant, bin aber trotzdem 
technikaffin. Ich habe mir den ganzen Thread durchgelesen und bin mir 
trotzdem in einigen Sachen noch sehr unsicher.
Könnte sich jemand eventuell bei mir melden per PM und mir ein paar 
Dinge kurz erklären, am besten die Anbindung des hier besprochenen eqiva 
Türschlossantriebes und die Anbindung an Home Assistant.
Das würde mich sehr freuen.

Vielen Dank im Voraus
Christian

[Hendrik F. (henfri)]

Hallo,

meine Tochter war gestern leider ausgesperrt:
Ich hab ja zwei ESPs (ESP-Home Version) mit zwei Schlössern. Beide waren 
in HomeAssistant "nicht verfügbar". Aber auch mit der Eqiva App ging es 
nicht - es scheint also, als wäre der esp noch mit dem Lock verbunden 
gewesen.
Ich habe später die ESPs kurz vom Strom getrennt und wieder verbunden; 
Dann ging es wieder.

Mögliche Fehlerquellen sind:
-WLAN
-"Schluckauf des ESP"

Kann man es irgendwie erreichen, dass der ESP sich vom Lock trennt, wenn 
kein Kontakt zum HomeAssistant besteht, damit es dann wenigstens mit der 
App geht?

Gruß,
Hendrik

[Daniel A. (dxme)]

Hallo zusammen,

ich grabe mal diesen Thread aus. Lasst mich wissen, ob es einen besseren 
Ort gibt.

Ich habe ein Key-BLE und ein Homeassistant und würde den 
Türschlossantrieb gerne verwenden. Wie ist denn da die beste 
Möglichkeit?

Bisher habe ich keyble-mqtt ausprobiert, aber das läuft bei mir nicht 
zuverlässig. Es gibt zwei Probleme:
 - die Verbindung wird nicht zuverlässig gehalten.
 - Ein OPEN-Request wird teilweise viel später (Minuten!) ausgeführt. 
Zum Beispiel auch nach einem Neustart von keyble-mqtt. Das passiert 
immer nach einem Abriss der Verbindung. Das ist so natürlich schlecht, 
weil dann die Tür aufginge, wenn ich schon lange wieder weg bin...

Ich habe keyble-mqtt angepasst, so dass die auto-disconnect-time auf 0 
gesetzt werden sollte, das brachte aber keine Verbesserung.

Ich habe zusätzlich einen Timer eingebaut, der jede Sekunde checkt, ob 
eine Verbindung da ist, und falls nicht sie ensure_connected() aufruft. 
Das scheint jetzt so halb zu funktionieren.

Wie betreibt ihr das Teil?

Ich stolpere über zwei Fehler. Erstens:
/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:43 
7
                                        throw (new Error('Received 
message contains invalid authentication value'));
                                        ^
Error: Received message contains invalid authentication value
    at Key_Ble.on_message_fragment_received 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:4 
37:13)
    at Characteristic.on_data_received 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:5 
53:9)
    at Characteristic.emit (node:events:517:28)
    at Noble.onRead 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble 
/lib/noble.js:442:20)
    at NobleBindings.emit (node:events:517:28)
    at NobleBindings.onNotification 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble 
/lib/hci-socket/bindings.js:621:8)
    at Gatt.emit (node:events:517:28)
    at Gatt.onAclStreamData 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble 
/lib/hci-socket/gatt.js:123:16)
    at AclStream.emit (node:events:529:35)
    at AclStream.push 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/@abandonware/noble 
/lib/hci-socket/acl-stream.js:33:10)

Node.js v18.19.1


Zweitens:



  keyble:communication Sending message of type CONNECTION_REQUEST, data 
bytes <00 11 22 33 44 fa ke fa ke>, data 
{"user_id":0,"local_session_nonce":[123,123,fake,fake,fake]} +4d
/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:49 
8
                this.send_characteristic.write(Buffer.from(message_fragment.uint8array)) 
; 
^

TypeError: Cannot read properties of null (reading 'write')
    at Key_Ble.send_message_fragment 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:4 
98:28)
    at process.processTicksAndRejections 
(node:internal/process/task_queues:95:5)
    at async Key_Ble.send_message_fragments 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:5 
06:4)
    at async Key_Ble.send_message 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:5 
30:3)
    at async Key_Ble.ensure_nonces_exchanged 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:5 
75:3)
    at async Key_Ble.send_message 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:5 
13:4)
    at async Key_Ble.send_command 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:4 
05:3)
    at async Key_Ble.open 
(/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:3 
99:3)
    at async MqttClient.<anonymous> 
(/usr/local/lib/node_modules/keyble-mqtt/keyble-mqtt.js:166:7)

Node.js v18.19.1

In diesen Fällen "hängt" das Schloss und der OPEN-Request wird auch 
wieder stark verzögert ausgeführt.

[Dirk (digaus)]

https://github.com/digaus/esphome-components-eqiva

Am besten mein esphome Plugin verwenden mit nen ESP32 🙂

[Daniel A. (dxme)]

Dirk schrieb:
> https://github.com/digaus/esphome-components-eqiva
>
> Am besten mein esphome Plugin verwenden mit nen ESP32 🙂

Das hatte ich gesehen, aber nicht verstanden, ob ich das haben will. Ich 
habe schon Bluetooth an Homeassistant und prinzipiell läuft es ja.

Für dein ESPHome-Plugin bräuchte ich einen dedizierten ESP nur für das 
Schloss, oder?

[Hendrik F. (henfri)]

Hallo,

ich habe zunächst keyble (ohne -mqtt aber nem anderen Tool für die 
Verbindung zu mqtt) genutzt. Das lief zuverlässig, aber oft mit nem ganz 
schönen delay, da es (das war meine Entscheidung) die Verbindung nicht 
hielt, sondern nur für Aktionen aufgebaut hat.

Ich habe dann die ESP32 Standalone Version ausprobiert, aber die mochte 
mein schlechtes WLAN nicht und ist abgestürzt.

Dann bin ich auf die ESP-home Komponente von Dirk umgestiegen. Zunächst 
auch mit direktem Disconnect nach Aktionen, jetzt aber mit permanenter 
Verbindung.
Das ist echt super, da stabil und sehr, sehr "responsiv".

So ein ESP32 kostet ja auch keine 4€. Aber ja, du brauchst einen pro 
Schloss.

Gruß,
Hendrik

[Dirk (digaus)]

Man kann auch einen Shelly Mini nehmen und den irgendwo in der Nähe 
hinter die Steckdose setzen.

Dann hat man direkt ne Stromversorgung und er ist schön versteckt. So 
habe ich es im Schuppen gemacht.

Alternativ gibt's natürlich auch ESP32 im USB Stick Format.