Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Holger76]

@tombox

Vielen Dank, das sind ja großartige Neuigkeiten :)

Ich habe den Adapter eben kurz getestet, mit encrypted token... lock und unlock funktionieren jedenfalls. Super !

Ich werde das die Tage weiter testen und Rückmeldung geben .

[Schimi]

@tombox SUPERGUT!!!!

[tombox]

@holger76 interessant wäre zu wissen ob die webhooks also das Änderung sofort übertragen werden in proxmox und docker funktionieren

[Schimi]

@tombox in einer nativen iobroker installation... funktionieren die befehle sofort....

[tombox]

@schimi es geht um den Empfang von statusänderung am Schloss. Bzw ob im log kommt

Webhook message received

[Schimi]

@tombox
Hi,
also die änderung in den Objekten wurde direkt angezeigt in meinen tests....

Im Protokoll kam keine Info... aber ich habe es nur auf "Info" stehen...

Ich baue meine Automatismen mal um auf localen zugriff.... sollte aber klappen :-)

Zur info: bei mir läuft es nicht im Docker....

[kBrausew]

Ich benutze Docker ... hab's mal installiert und berichte ob alles funktioniert

[kBrausew]

ok, es scheint als ob alles funktioniert... hab mal nix entdeckt was dagegen spricht.
Woran würde ich den unverkennbar bemerken das Webhook's auf Docker nicht gehen?

... Webhook message received...

... habe ich bis jetzt nirgends im Log gesehen.

[tombox]

@kbrausew Mit der aktuellen GitHub version kommt
"Webhook connected successfully"

Wenn Sich der status der schloss ändert

[Holger76]

ich hatte soeben das Problem, dass der Adapter gelb war "Nicht verbunden mit Gerät oder Dienst". Im Log stand "invalid token". Ich habe in der App gesschaut, der token war der Gleiche wie bei der Einrichtung.
Trotz Adapter Neustart funktionierte es nicht (es gingen natürlich auch keine Schließvorgänge) bis ich den gleichen Token neu eigegeben habe. Nun ist der Adapter wieder grün.

Falls das Problem noch einmal auftritt, was soll ich prüfen / loggen ?

[tombox]

@holger76 Ich vermute es war eine Änderung wie der token gespeichert wurde. Sollte also nie wieder auftreten

[nousefor82]

@tombox

Hallo, bekomme beim Versuch des Speicherns nach der Eingbae von IP und Token folgenden Fehler:

[JsonConfig] Cannot set object: TypeError: window.CryptoJS is undefined

Was muss ich machen? :-)

Viele Grüße

[tombox]

@nousefor82 Welche Admin version verwendest du und arbeitest du auf Windows?

[nousefor82]

@tombox

Servus,

Admin 6.13.3

System läuft unter Linux (Proxmox).

VG

[nousefor82]

@tombox

Servus nochmal,

guter TIPP...

habe den Adapter auf 6.12.9 downgegradet.

Jetzt klappt es.

Danke

[tombox]

@nousefor82 der Fehler wurde mit admin 6.13.5 behoben

[nodoe]

@tombox

Hallo zusammen,

bin gerade erst zum installieren und testen gekommen. Alle unlock-Funktionen laufen.

Bei lock=true bekomme ich folgenden Fehler im log und das Schloss bewegt sich nicht:

tedee.0 788259	2023-12-23 01:23:15.901	error	{"error-code":3,"error-description":"BLE API error"}
tedee.0 788259	2023-12-23 01:23:15.901	error	AxiosError: Request failed with status code 406

Welche Optionen habe ich? Der Admin läuft mit der latest-version 6.12.0.

Beste Grüße.

[tombox]

@nodoe Welche Firmware Version hat die Bridge und das Schloss?
Passiert das auch wenn du 5sek wartest

[nodoe]

@tombox

Das Schloss hat Firmware 2.4.16884, die Bridge 2.2.16924. Die sollten eigentlich aktuell sein.

Unabhängig davon habe ich einen Anhaltspunkt: Bei unlock=unlock(0) öffnet das Schloss, zieht die Falle ein und springt in dieselbe Position zurück wie bei der App-Steuerung. In der App steht dann "offen". Von da aus lässt sich dass schloss auch mit lock=true schließen. Öffne ich das Schloss mit unlock=Force unlock, öffnet das Schloss, dreht beim Einziehen der Falle weiter als mit App bzw. unlock=unlock(0) und springt dann nicht so weit zurück (ca. 30° weiter Richtung "auf" gedreht). In der App steht "eingezogen" (nicht "offen"). Dann schließt das Schloss nicht mit lock=true und es kommt der beschriebene Fehler im log.

Mir ist noch etwas aufgefallen: Ich würde gerne standardmäßig unlock ="Without auto pull spring" einstellen und damit morgens die Tür standardmäßig öffnen, ohne die Falle zu ziehen. Das funktioniert einmalig, anschließend springt unlock auf unlock=unlock(0) zurück. Ist das gewollt? Ich fände es besser, wenn der eingestellte Zustand erhalten bliebe.

Beste Grüße und danke für die tolle Arbeit!

[tombox]

@nodoe Die GitHub version hat das unlock setzen deaktiviert

Ist das verhalten auch so in der App?