UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

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

[nodoe]

@tombox
Sorry, da kann ich Dir wohl nicht folgen. Bei mir ist "Türfalle einziehen" in der App standardmäßig an, meinst Du das? Da dreht das Schloss aber entsprechend der Kaibrierung (Drehwinkel?) nicht so weit wie bei unlock=Force unlock (max. Kraft?). Öffnen/Schließen geht damit problemlos.

Beste Weihnachtsgrüße!

[NinjaTurtle85]

Hallo zusammen,
seid dem Bridge update auf 2.2.19382 bekomme ich keine Verbindung mehr zur Bridge.
API Key habe ich erneuert, aber leider kein Erfolg.
Hat noch jemand das Problem?

[NinjaTurtle85]

Ich habe das Wlan gewechselt und jetzt geht es wieder.
Ich denke ein Stecker ziehen hätte auch gereicht.

[TDCroPower]

eine Frage in die Runde, weil ich noch unschlüssig bin, ob ich mir das tedee Pro hole oder das neue Nuki 4 Pro.
Kann man durch den tedee Adapter das tedee Pro so weiterhin einstellen, dass man das tedee Auto-Unlock mit Unlock+Pull verwendet und zusätzlich per Skript und Adapter eine eigene Möglichkeit baut, das man zum Beispiel um 22:00 die Tür abschließt und um 06:00 morgens wieder aufschließt ohne Pull?
Das geht ja bei beiden System nicht, wenn man Pull aktiviert, da dann beim aufschließen immer auch Pull durchgeführt wird und so die Tür komplett offen steht.

[MAXI885]

@tombox
Hallo,
ich bin gerade dabei vom Nuki auf Tedee umzusteigen, dabei wäre ein Punkt wichtig für mich.
Beim Nuki kann ich entscheiden ob ich per iobroker nur "öffne", also ohne Falle ziehen oder ob ich komplett öffne, inkl. Falle ziehen,
je nach dem was man für eine Zahl an lock_Action schickt.
Ist das hier auch möglich oder muss man sich für eine Variante entscheiden, bzw. wird das fest durch die Einstellung in der App festgelegt ?

Vielen Dank & Grüße

[tombox]

@maxi885
tedee.0.XXXXX.remote.unlock kannst du zwischen 4 unlock modes wählen

[MAXI885]

@tombox
Habe das Tedee pro gut zwei Wochen im Einsatz, alle Funktionen wurden mit NodeRed in Iobroker umgesetzt, das ganze dort mit KNX verknüpft, automatischer Schließplan, Codeschloss und Türsprechanlage steuern das Tedee nun ebefalls an, alles funktioniert einwandfrei, an der Stelle, noch einmal vielen Dank für den Adapter, super Sache !
Ganz allgemein, ich trauere dem Nuki 3.0 pro keine Sekunde nach, alleine was Verarbeitung, Lautstärke und Geschwindigkeit angeht, spielt das Tedee in einer anderen Liga. Natürlich, es kostet auch deutlich mehr.

Vielen Dank & Grüße !

[Holger76]

Hi,

ich nutze den Adaper auch von Anfang an und er verrichtet seinen Dienst super. Vorher lief es über den HAM Adapter - ging auch, nur mit gewisser Latenz.
Allerdings hatte ich eben ein Problem:

Die Tür lies sich nicht öffnen über meine Routine. Ich musste das Handy rausholen und über die Tedee App öffnen. Ich hatte die Routine so eingerichtet, dass wenn der Tedee Adapter online ist, nutze ihn, ansonsten über HAM. Allerdings war der Tedee online, nur hat er im LOG folgende Fehlermeldung ausgespuckt:
error AxiosError: timeout of 47370.775255396315ms exceeded
Das kommt jedes Mal beim aktivieren der Routine, d.h. bei einer Öffnen/Schließen Aktion.
Wenn ich den Adapter neu starte, verbindet er scih nicht mehr.
"Verbunden mit Gerät oder Dienst" = aus

Dann funktioniert allerdings auch meine Routine wieder, da es dann über dem HAM läuft. Es wäre also oberste Priorität, dass bei Problemem der Adapter dann auch wirklich auf Störung geht, was mich ja etwas wundert, da es ja auch eine Fehlermeldung gab.

Die Frage ist jetzt nur, was besagt diese Meldung und warum geht es über HAM.
Ich werde weiter testen und mich melden...

Gruß Holger