Monatsrückblick Oktober 2026 ist online!

[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

[Holger76]

Kurze Rückmeldung, dass der Adapter nach einem Tag wieder online ging - einen Grund konnte ich leider nicht erfahren. Ich hatte höchstens auf die Batterie getippt, welche allerdings noch 59% anzeigte. Außerdem lief es ja mit dem HAM Adapter und über Handy, also eigentlich unlogisch.

Es bleibt mir also nur die Frage, was bedeutet diese Fehlermeldung und wieso blieb der Adapter grün, obwohl er nicht funktionierte..?!

[ke.spring]

Hallo,

der Adapter ist super und läuft 1A.

Ich hätte eine Frage zu der Tedee Tastatur. Kann man diese als Gerät via Api hinzufügen und so einen Status abfragen lassen, ob ein gültiger Pin eingegeben wurde oder nicht?

Ist eigentlich das einzige was ich etwas vermisse, da es für weitere Abfragen und Möglichkeiten könnte genutzt werden, wäre genial, wenn man dies dem Adapter könnte hinzufügen.

Besten Dank an den Programmierer, der hier einfach eine tolle Leistung hinlegt und geniale ADAPTER programmiert.

Allen ein tolles neues Jahr ;-)

[tombox]

@ke-spring
Hier kannst du alle Events sehen die unterstützt werden.
https://docs.tedee.com/bridge-api#tag/Webhook-events

Wenn was von Tedee hinzugefügt werden sollen bitte anfragen ob sie zusätzliche Events für die Bridge API hinzufügen können
support@tedee.com

[ke.spring]

@tombox
Okey danke, dann schreib ich doch mal dem Support, fragen kostet ja nichts

[Schimi]

@tombox, habe dir eine PM geschickt

[Schimi]

Hallo zusammen,

die Version 0.4.0 vom tedee-Adapter ist seit heute auf npm und sollte in den nächsten Stunden im latest-Repository auftauchen (Admin im Expertenmodus, Repository "Beta (latest)").

Ich habe in den letzten Tagen zusammen mit @tombox einiges umgebaut und getestet, mit meinem Lock PRO, Keypad PRO und der Bridge (FW 2.2.48155)…

Neu:

• PIN-Verwaltung für die Keypad-PINs (anzeigen, anlegen, ändern, löschen), per States und per sendTo, auch ein Blockly-Beispiel ist in der Readme
• Kanal lastAction: zeigt, wer und wie das Schloss bedient wurde (App, Knopf, Keypad mit PIN-Name, Fingerabdruck)
• optionale Einstellung "Callback-Host" für die Webhooks (Docker, mehrere Netzwerkkarten, IPv6)
• Einstellungsseite überarbeitet (Tabs, Hilfetexte, Übersetzungen)

Behoben:

• Webhooks werden mit der IP statt mit dem Hostnamen registriert (bei mir liegt die Bridge in einem eigenen IoT-VLAN, ohne lokales DNS kam vorher nichts an)
• Webhooks von anderen Systemen (z. B. Home Assistant) werden nicht mehr gelöscht
• Schließbefehle werden bei Fehlern nicht mehr wiederholt (vorher konnte "unlock" mehrfach rausgehen) und laufen nicht mehr in ECONNRESET
• sauberes Beenden, der Adapter wurde beim Stoppen "gekillt"

Voraussetzung sind jetzt Node.js 22, js-controller 6.0.11 und Admin 7.8.23.

Die PIN-Verwaltung ist standardmäßig aus und muss in den Einstellungen im Tab "PIN-Verwaltung" eingeschaltet werden. Die Anleitung steht in der Readme im Abschnitt "PIN management": https://github.com/TA2k/ioBroker.tedee#pin-management

Ich würde mich über Rückmeldungen freuen, vor allem zu den PINs (andere Keypad-Modelle, viele PINs, Zeitfenster/Wochentage) und zum Callback-Host bei Docker-Installationen… Fehler gerne als Issue auf GitHub: https://github.com/TA2k/ioBroker.tedee/issues

Wenn es ein paar Tage ohne Probleme läuft, beantrage ich das Update auf 0.4.0 für Stable.

Beste Grüße

[Schimi]

Kurzes Update: die Version 1.0.0 ist raus (npm, latest folgt).

Achtung, eine Änderung ist nicht kompatibel… remote.lock gibt es nicht mehr, dafür remote.open mit der ioBroker-Rolle switch.lock:

• false = verriegeln
• true = entriegeln

Das ist genau umgekehrt wie vorher. Deshalb wird remote.lock beim ersten Start gelöscht (mit Warnung im Log), damit kein Skript die Tür aus Versehen falsch herum bedient. Skripte und VIS bitte auf remote.open umstellen.

Dafür haben jetzt alle Datenpunkte richtige Rollen, Einheiten und Namen (Batterie in %, Signal in dBm, erreichbar, blockiert, Firmware …), 0/1 sind jetzt true/false und das Schloss wird von Alexa, HomeKit und Material als Schloss erkannt. remote.pull und remote.refresh sind Buttons.

Die komplette Tabelle steht in der Readme unter „Changes in 1.0.0“: https://github.com/TA2k/ioBroker.tedee#changes-in-100

Rückmeldungen gerne hier oder als Issue.

[Schimi]

Kurze Info: die Version 1.0.1 ist jetzt im Stable-Repository.

Wer bisher 0.3.2 (Stable) genutzt hat, bekommt das Update in den nächsten Stunden im Admin angeboten.

Bitte vor dem Update beachten… remote.lock gibt es nicht mehr. Stattdessen remote.open:

• false = verriegeln
• true = entriegeln

remote.lock wird beim ersten Start gelöscht (mit Warnung im Log). Skripte, Blockly und VIS, die remote.lock nutzen, bitte umstellen, sonst passiert beim Schließen einfach nichts.

Neu seit 0.3.2 unter anderem: PIN-Verwaltung fürs Keypad, lastAction (wer hat die Tür wie geöffnet), richtige Rollen für Alexa, HomeKit und Material, Statusänderungen kommen sofort per Webhook. Die Readme ist jetzt auch für Einsteiger geschrieben: https://github.com/TA2k/ioBroker.tedee

Rückmeldungen gerne hier oder als Issue.

[JohGre]

Wollte nur mal Rückmeldung geben. Nutze den Adapter mit 2 Tedee PRO mit 2 KEYPAD PRO und 2 Door-Sensoren und 2 BRIDGE und er funktioniert problemlos. Danke mal dafür

[Schimi]

Die Info mit den Door-Sensoren ist viel wert... ich habe keine und konnte das somit nicht testen... Danke!

[JohGre]

Edit: Hat sich erübrigt, IP hatte sich geändert - hab nun auf fixe umgestellt

habs mich wohl etwas zu früh gefreut. Bekomme seit gestern dauernd diese Fehler. Das Einzige was geändert wurde war, dass ich das PIN Management aktiviert habe, mittlerweile wieder deaktiviert. Downgrade der Version habe ich noch nicht versucht.
Irgendeine Idee? Liegts am Adapter oder wo anders

2026-11-12 07:33:51.385 - debug: tedee.0 (54231) Redis Objects: Use Redis connection: 127.0.0.1:9001
2026-11-12 07:33:51.396 - debug: tedee.0 (54231) Objects client ready ... initialize now
2026-11-12 07:33:51.397 - debug: tedee.0 (54231) Objects create System PubSub Client
2026-11-12 07:33:51.397 - debug: tedee.0 (54231) Objects create User PubSub Client
2026-11-12 07:33:51.405 - debug: tedee.0 (54231) Objects client initialize lua scripts
2026-11-12 07:33:51.408 - debug: tedee.0 (54231) Objects connected to redis: 127.0.0.1:9001
2026-11-12 07:33:51.409 - silly: tedee.0 (54231) redis psubscribe cfg.o.system.user.*
2026-11-12 07:33:51.413 - silly: tedee.0 (54231) redis psubscribe cfg.o.enum.*
2026-11-12 07:33:51.414 - silly: tedee.0 (54231) objectDB connected
2026-11-12 07:33:51.415 - debug: tedee.0 (54231) Redis States: Use Redis connection: 127.0.0.1:9000
2026-11-12 07:33:51.418 - debug: tedee.0 (54231) States create System PubSub Client
2026-11-12 07:33:51.418 - debug: tedee.0 (54231) States create User PubSub Client
2026-11-12 07:33:51.465 - debug: tedee.0 (54231) States connected to redis: 127.0.0.1:9000
2026-11-12 07:33:51.465 - silly: tedee.0 (54231) statesDB connected
2026-11-12 07:33:51.475 - debug: tedee.0 (54231) Plugin sentry Do not initialize Plugin (enabled=false)
2026-11-12 07:33:51.517 - info: tedee.0 (54231) starting. Version 1.0.2 in /opt/iobroker/node_modules/iobroker.tedee, node: v22.23.4, js-controller: 7.2.5
2026-11-12 07:33:51.530 - silly: tedee.0 (54231) States system redis pmessage system.adapter.tedee.0.logLevel/system.adapter.tedee.0.logLevel:{"val":"silly","ack":true,"ts":1794465231514,"q":0,"from":"system.adapter.tedee.0","lc":1794465231514}
2026-11-12 07:33:51.625 - info: tedee.0 (54231) Getting devices from bridge 192.168.178.225
2026-11-12 07:33:51.827 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/bridge after ECONNREFUSED
2026-11-12 07:33:52.135 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/bridge after ECONNREFUSED
2026-11-12 07:33:52.648 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/bridge after ECONNREFUSED
2026-11-12 07:33:53.584 - error: tedee.0 (54231) Error: connect ECONNREFUSED 192.168.178.225:80
2026-11-12 07:33:53.588 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/lock after ECONNREFUSED
2026-11-12 07:33:53.810 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/lock after ECONNREFUSED
2026-11-12 07:33:54.280 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/lock after ECONNREFUSED
2026-11-12 07:33:55.168 - error: tedee.0 (54231) Error: connect ECONNREFUSED 192.168.178.225:80
2026-11-12 07:33:56.673 - info: tedee.0 (54231) Webhooks listening on port 29170 (IPv4 + IPv6)
2026-11-12 07:33:56.676 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/callback after ECONNREFUSED
2026-11-12 07:33:56.946 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/callback after ECONNREFUSED
2026-11-12 07:33:57.456 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/callback after ECONNREFUSED
2026-11-12 07:33:58.378 - error: tedee.0 (54231) Error: connect ECONNREFUSED 192.168.178.225:80
2026-11-12 07:33:59.879 - info: tedee.0 (54231) Registering webhook http://192.168.178.75:29170/webhook
2026-11-12 07:33:59.884 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/callback after ECONNREFUSED
2026-11-12 07:34:00.128 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/callback after ECONNREFUSED
2026-11-12 07:34:00.548 - warn: tedee.0 (54231) Retrying request to http://192.168.178.225/v1.0/callback after ECONNREFUSED
2026-11-12 07:34:01.396 - error: tedee.0 (54231) Couldn't register webhook. Please try to restart the adapter.
2026-11-12 07:34:01.397 - error: tedee.0 (54231) Error: connect ECONNREFUSED 192.168.178.225:80