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
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.
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?
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.
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)
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.
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 :)
[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.
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?
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:
1
esphome:
2
name: esphome-web-8bf1d4
3
friendly_name: equiva Controller
4
esp32:
5
board: esp32dev
6
framework:
7
type: esp-idf
8
9
# Enable logging
10
logger:
11
12
# Enable Home Assistant API
13
api:
14
encryption:
15
key: "V/xx="
16
services:
17
- service: settings
18
variables:
19
turn_left: bool
20
key_horizontal: bool
21
lock_turns: int
22
then:
23
- eqiva_key_ble.settings:
24
turn_left: !lambda 'return turn_left;'
25
key_horizontal: !lambda 'return key_horizontal;'
26
lock_turns: !lambda 'return lock_turns;'
27
- service: connect
28
variables:
29
# mac_address: string // Unable to pass a mac_address via lambda :?
30
user_id: int
31
user_key: string
32
then:
33
- eqiva_key_ble.connect:
34
mac_address: 32:20:50:56:42:88
35
# mac_address: !lambda 'return mac_address;'
36
user_id: !lambda 'return user_id;'
37
user_key: !lambda 'return user_key;'
38
- service: disconnect
39
then:
40
- eqiva_key_ble.disconnect:
41
- service: pair
42
variables:
43
card_key: string
44
then:
45
- eqiva_key_ble.pair:
46
card_key: !lambda 'return card_key;'
47
- service: lock
48
then:
49
- eqiva_key_ble.lock:
50
- service: unlock
51
then:
52
- eqiva_key_ble.unlock:
53
- service: open
54
then:
55
- eqiva_key_ble.open:
56
- service: status
57
then:
58
- eqiva_key_ble.status:
59
ota:
60
61
wifi:
62
ssid: FNetz
63
password: paass
64
65
# Enable fallback hotspot (captive portal) in case wifi connection fails
66
ap:
67
ssid: "Esphome-Web-8Bf1D4"
68
password: "paaas"
69
70
web_server:
71
include_internal: true
72
local: true
73
port: 80
74
75
76
captive_portal:
77
78
external_components:
79
source: github://digaus/esphome-components-eqiva
80
# use refresh when you do not get latest version
81
refresh: 0s
82
83
esp32_ble_tracker:
84
# scan_parameters:
85
# window: 300ms
86
87
eqiva_ble:
88
89
eqiva_key_ble:
90
id: key_ble
91
# Below are optional and can be passed via new connect service
92
mac_address: 32:20:50:18:a6:96 # Hintertür
93
user_id: 1
94
user_key: 9872987492873492837492837492374
95
96
#Schuppen:
97
#mac_address: 32:20:50:0a:6e:7c # Schuppen
98
#user_id: 1
99
#user_key: 9283749283749237498729874928734
100
101
102
text_sensor:
103
- platform: eqiva_key_ble
104
mac_address:
105
name: "Mac Address"
106
id: mac_address
107
lock_status:
108
name: "Lock Status"
109
id: lock_status
110
low_battery:
111
name: "Low Battery"
112
lock_ble_state:
113
name: "Lock BLE State"
114
user_id:
115
name: "User ID"
116
user_key:
117
name: "User Key"
118
# on_raw_value:
119
# then: Do stuff on state change (!lambda "return x")
120
121
122
lock:
123
- platform: template
124
name: "Lock 1"
125
lambda: |-
126
if (id(mac_address).state != "32:20:50:18:a6:96") {
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") {
da hab ich mich unklar ausgedrückt.
Ich hatte zwei Fragen:
Kann ich für den Lock Status so, wie ich das in dem Code-Block geschrieben habe einen anderen Sensor nutzen
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?
1
lock_action:
2
- eqiva_key_ble.connect:
3
mac_address: 11:12:34:56:42:88
4
user_id: 1
5
user_key: 1234567891234567897234696139787E
6
- eqiva_key_ble.lock:
7
- 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?
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?
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.
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::<anonymous>.esphome::sensor::Sensor::state', which is of non-class type 'float'
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::<anonymous>.esphome::sensor::Sensor::state',
which is of non-class type 'float'
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üß
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
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:
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
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
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
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?
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.
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.
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
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)
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
B: Die Entität mac_address unter text sensor kann nicht den gleichen Namen unter text haben
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.
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
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)
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
B: Die Entität mac_address unter text sensor kann nicht den gleichen
Namen unter text haben
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.
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)
Ist ein Bug des web_server -> "local: false" setzen
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 .
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:
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?
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
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
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?
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?
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
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
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
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
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
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.
Versuche ist es so zu programmieren, dass es immer disconnected ist und nur bei Bedarf, connected.
Bei Start habe ich es so
1
wifi:
2
ssid:!secretwifi_ssid_salon
3
password:!secretwifi_password
4
on_connect:
5
-eqiva_key_ble.connect:
6
mac_address:00:1a:22:18:3c:76
7
user_id:1
8
user_key:601dde3b2904999e289f1b1079c258fe
9
-esp32_ble_tracker.start_scan:
10
continuous:true
11
-delay:30s
12
-eqiva_key_ble.disconnect:
13
on_disconnect:
14
-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?
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.
1
lock_action:
2
-eqiva_key_ble.connect:
3
mac_address:00:x#Schuppen
4
user_id:1
5
user_key:x
6
-eqiva_key_ble.lock:
7
#- eqiva_key_ble.disconnect:
Aber das alleine kann es ja nicht sein, denn es wurde lange vorher nicht gelockt.
Darüber hinaus habe ich
1
time:
2
-platform:sntp
3
timezone:Europe/Berlin
4
servers:
5
-0.pool.ntp.org
6
-1.pool.ntp.org
7
-2.pool.ntp.org
8
on_time:
9
# Every 4 minutes get Status, to ensure quick reaction
10
-cron:'00/421-23***'
11
then:
12
-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?
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.
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:
ich brauche den Status eigentlich nicht. Kann das dann nicht raus?
war es nicht so, dass die Verbindung ca 4 minuten aufgebaut bleibt?
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:
ich brauche den Status eigentlich nicht. Kann das dann nicht raus?
war es nicht so, dass die Verbindung ca 4 minuten aufgebaut bleibt?
Gruß,
Hendrik
Das zweite Lock sollte nur von deiner yaml kommen. Am besten mal auf github die readme anschauen
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.
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.
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
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?
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.
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?
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.
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?
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?
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)
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?
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.
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
@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?
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.
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.
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:
1
# WiFi disabled
2
*** get state ***
3
# Nonce exchange
4
# Searching ...
5
# Found device: 00:1a:22:0a:6c:9b
6
# RSSI: -61
7
# Connecting in tick
8
# Connecting...
9
# Connected in tick
10
Guru Meditation Error: Core 0 panic'ed (Unhandled debug exception).
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?
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.
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.
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^^
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.
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?
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:437
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:437:13)
at Characteristic.on_data_received (/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:553: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:498
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:498: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:506:4)
at async Key_Ble.send_message (/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:530:3)
at async Key_Ble.ensure_nonces_exchanged (/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:575:3)
at async Key_Ble.send_message (/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:513:4)
at async Key_Ble.send_command (/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:405:3)
at async Key_Ble.open (/usr/local/lib/node_modules/keyble-mqtt/node_modules/keyble/keyble.js:399: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.
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.
Ich habe auf Basis des nodejs codes einen python-port erstellt. Läuft bei mir aktuell seit zwei tagen zuverlässig. In einem docker-container auf einer rpi zero 2. 🥳
Aktuell verbindet es ein Schloss und hat keine Option zum Halten der Verbindung, wohl aber einen Timer um periodisch abzufragen.
Da ich noch viel am herumbasteln damit bin (also alles andere als fertig) die frage: hat jemand interesse und was soll es alles können?
Außer einem reporting per http des status habe ich noch nichts eingebaut, ich denke mqtt ist notwendig? Welche topics, sind leicht in homeassistant oder ähnlichem zu integrieren?
Ich habe inzwischen die GUI überarbeitet, fehlende Features von der APP nachgezogen und nun ist es ein kompletter ersatz für die App geworden, von der registrierung (per QR-scan) bis zum komplett funktionierenden Usermanagement.
Ich habe MQTT eingebaut (das ist ungetestet), das "Stay Connected" funktioniert auch mit mehreren Schlössern parallel. Der Verbindungsaufbau ist inzwischen auch ein vielfaches schneller und zuverlässig geworden, sodass das eigentlich nicht mehr notwendig ist.
Vielleicht mache ich mir die Mühe und probiere es auf ESP32 zu portieren, aktuell bin ich mit dem Docker-container mit Bluetooth auf einem RPI1zero allerdings sehr zufrieden.
Wow, das klingt super.
Ich nutze ja den ESPHome-Port und dabei die permanente Verbindung. Da ist toll, dass alles sehr schnell geht, aber es nervt etwas, dass die Batterie nicht so lange hält (1-3 Monate).
Was hast du gemacht, um die Verbindung zu beschleunigen und wie lange dauert es bei dir aktuell von "Not connected" bis "Schloss reagiert"?
von "not connected" bis "fertig" dauert es bei mir zwischen 5 und 7 Sekunden, und da ist die eine Umdrehung beim sperren schon inkludiert (im Log unten zwischen :16 und :20 die Zeit braucht der Motor zum drehen).
am meisten hat beim connect ausgemacht, dass man nicht wartet. das schloss scheint hier nicht nach dem BT-standard zu arbeiten, und liefert nach dem connect keine Meldung dass man mit weiteren Befehlen loslegen könnte. Damit läuft das in ein timeout, es machen die BT-libraries aber erst nach 10sec Timeout (oder höher) weiter.
Das ausschlaggebende war dann der lib mitzugeben dass man keinen Response erwartet, explizit beim connect.
1
12:51:14 [INFO] keyble: HTTP POST /api/lock/Garagentuere/command/unlock 200
2
12:51:14 [DEBUG] keyble: Cleared BlueZ state for 00:1a:22:18:ce:94
3
12:51:14 [DEBUG] keyble: Connection attempt 1 for 00:1a:22:18:ce:94
4
12:51:16 [INFO] keyble: BLE connected (RECV=0x0421 SEND=0x0411)
Hallo zusammen,
kurz zu mir: Ich bin schon einige Jahre Rentner und meine Freizeitbeschäftigung sind Schaltungen fürs Haus und Messen mit den Arduino und IO-Broker..
An meiner alten Haustür hatte ca. 5 Jahreich einen Servo als Stellmoor mit einen schicken, gedruckten Gehäuse. Von außen mit Schip und innen mit Taster gesteuert.
Jetzt habe ich eine neue Haustür bekommen. Da ich Eq-3 und Vorgänger schon viele Jahre ohne Probleme benutze, habe ich das EQ-3 Eqiva Türschloss verbaut, funktioniert super mit der AP.
Den Arduino BLE wollte ich weiter benutzen um auch mit dem Chipleser das EQ-3 zu bewegen, ohne Erfolg.
Es gibt im Internet unzählige Infos, um mit MQTT und Bluetooth BLE das EQ-3 zu benutzen. Leider finde ich in den vielen Veröffentlichungen nicht die Zeilen für den BLE, um Daten zum Schloss zu senden.
Mac-Adresse, User-ID und Code (M001…) habe ich.
Wenn ich hier richtig bin, kann mir jemand helfen?
Beste Grüße aus Mühlhausen
Der Code existiert seit gestern in einem privaten github repository. Wenn du willst kann ich schauen ob ich dir das freigeben kann für deinen github user. Ich will den Code erst veröffentlichen wenn ich mir sicher sein kann, dass nicht sofort am ersten Tag 20 Leute probleme damit haben.
Das connect verbessern: das ist leider library abhängig. ZB python bleak unterstützt den "auf keine Antwort warten" modus nicht. Deshalb hatte meine erste implementation das selbe Problem wie Viele andere: beim connect musste man auf das konfigurierten timeout warten. Je nach Schloss und verbindungsqualität braucht man aber auch mal 10 bis 15 Sekunden.
Das bei mir jetzt verwendete Bluez kann das, und deshalb gelingt's schnell
Wie und ob das ganze auf esp32 geht kann ich aktuell weder Hilfe noch sinnvollen Diskussionsbeitrag leisten.
Du kannst inzwischen deinen rpi zero 1 mit dem aktuellsten raspbian installieren, musst dann aber docker mit den bullseye release in die sources.list geben, da das aktuelle Trixie auf armv6 von docker nicht mehr unterstützt wird. Mit den bullseye sources hast du dann die letzte unterstützte armv6 Version auf einem aktuell gewarteten OS.
Danke für die schnellen Antworten, ich glaube ich bin hier richtig.
Da ich die Handy-AP benutze, will ich nicht über IOB noch einen Taster auf mein Handy haben.
Den Chipleser und eventuell mal einen Fingerprint will ich nicht mit W-Lan betreiben.
Ein Mini-Kästchen mit dem Arduino ist noch von der alten Benutzung über der Tür montiert.
Es soll nur die Tür aufgeschlossen und im zweiten Schritt geöffnet werden, da ich keinen Summer mehr habe. Mit dem Chip mit Band am Hals war es schön mit vollen Taschen in der Hand die Tür zu öffnen.
Wenn etwas in Vorbereitung ist, habe ich natürlich Geduld.
Nur hatte ich im Januar einen mehrfachen Sprunggelenk-Bruch. Mein Handicap zwingt mich ständig zur Pause und dann kommen viele keine Projekte in den Kopf.
Jedenfalls besser als TV.
@cyber83: Könntest du vorab den Code posten, der die Verbesserung gebracht hat? Ich möchte prüfen, wie das auf dem ESP32 geht.
@kaffee: so out of the box gibt es dafür keine Lösung. Wenn das Standalone gehen soll, würde ich glaube ich ESPHome nutzen. Da kannst du per YAML konfiguration einerseits das Lock konfigurieren, andererseits MQTT (für IOBroker) und Kartenleser, Codelock und ähnliches. Da müsstest du dich aber einlesen, oder auf KI vertrauen.
Könntest du vorab den Code posten, der die Verbesserung gebracht hat?
Ich möchte prüfen, wie das auf dem ESP32 geht.
Das wird dir nichts bringen, da der Code spezifisch mit bluez funktioniert. Andere bluetooth-api (was bei esp erzwungenermaßen der Fall ist) und du musst den Code portieren, schauen was die api mit dem Code macht, nachimplementieren was die esp32 library anders macht, etc.
Deshalb auch docker. Ich will das ding später (wenn fertig) mit docker pull von einem fertig generierten image aus starten. Da muss man sich dann nicht um die installierte python 3.17 am host kümmern, die library ging vielleicht nur auf 3.16 (und unterstützt spezifisch das antwortlose weitersenden da nicht mehr), also Code anpassen wenn der rpi in 5 jahren dann kreiert und wieder "von vorne" anfangen. Nein danke.
Ein mal docker pull, container starten, Applikation rennt. Unabhängig vom host. Und auch in 10 jahren noch, wenn die handyapp nicht mehr funktioniert...
