Adapter: fritzdect

[Jan-Stefan Janetzky]

hübsches binding. ich vermisse eigentlich nur den "fenster offen" modus bei fritz dect 300 und 301
(kann man über das openhab binding setzen)
https://community.openhab.org/t/avm-fritz-binding-does-not-recognize-radiator-mode-window-open/70265/11

hier meine kleine regel in iobroker:

const actor = "fritzdect.0.Comet_099950537836.mode";
const provider = "deconz.0.Sensors.12.open";

on(provider, ({state: {val: open}}) => {
    setState(actor, open ? 1 : 0);
});

on({id: actor, valNe: 1}, async () => {
    const {val: open} = await getStateAsync(provider);
    if (open) setState(actor, 1);
});

[foxthefox]

@Jan-Stefan-Janetzky
windowopenactive kann mit der Version > 1.1.2 aus iobroker heraus gesetzt werden.
dazu ist noch eine Zeit (derzeitig 5min voreingestellt) mitzugeben, wie lange das Fenster als OFFEN betrachtet werden soll.
Die Fritzbox macht dann daraus den Rest.

[root_]

Hab heute auf die 2.1.1 geupdatet. Seit dem bleibt der Adapter gelb. Die Verbindung zu den Comet DECT Reglern die ich eingebunden habe, funktioniert aber. Kann alle Werte auslesen und auch steuern.

[foxthefox]

@root_
ich schmeiß die info.connection raus

Habe eine 2.1.2 ohne gelb erstellt

[Jan1]

@foxthefox
Ist jetzt aber nicht war, dass ich hier extra VIS installieren muss?

	error	startInstance system.adapter.fritzdect.0: required adapter "vis" not found!

[foxthefox]

@Jan1
eigentlich hast du recht, der adapter liefert zwar ein widget mit, braucht aber nicht zwingend ein vis Umgebung
Ich erstelle eine 2.1.4

EDIT bitte mit 2.1.4 testen

[root_]

@foxthefox
bin auf die 2.1.4 aber der Adapter bleibt gelb (funktioniert aber nach wie vor).

[foxthefox]

@root_

dann sind noch alte Datenpunkte drin.
Instanz fritzdect.0 löschen und neu anlegen hilft.

[root_]

@foxthefox thx, läuft 1a.

[Jan1]

@foxthefox
Sind hier Login Probleme bekannt?
Hab jetzt den IOBroker komplett restoren müssen, damit sich der Adapter wieder mit Version 1.1.4 in der Fritz einlogt. Die Fritz hatte das Login vorher wegen angeblich falschen Passwort abgelehnt. Hatte dann das Passwort noch mal manuell im Adapter eingetragen, was genau so wenig geholfen hatte wie ein neuer Benutzer samt Passwort für den Adapter in der Fritz anzulegen.

Der Adapter war allerdings grün und mir ist es auch nur aufgefallen, weil ich damit die Heizung steuere und es recht frisch geworden ist.

So, noch mal auf 2.1.5 und wieder loggt sich der Adapter nicht mehr ein.

$ ./iobroker url "https://github.com/foxthefox/ioBroker.fritzdect/tarball/master" fritzdect
install https://github.com/foxthefox/ioBroker.fritzdect/tarball/master
NPM version: 6.14.10
npm install https://github.com/foxthefox/ioBroker.fritzdect/tarball/master --loglevel error --prefix "/opt/iobroker" (System call)
prebuild-install info begin Prebuild-install version 5.3.6
prebuild-install info looking for cached prebuild @ /home/iobroker/.npm/_prebuilds/91abd0-usb-v1.6.3-node-v83-linux-x64.tar.gz
prebuild-install http request GET https://github.com/tessel/node-usb/releases/download/v1.6.3/usb-v1.6.3-node-v83-linux-x64.tar.gz
prebuild-install http 404 https://github.com/tessel/node-usb/releases/download/v1.6.3/usb-v1.6.3-node-v83-linux-x64.tar.gz
prebuild-install
 
WARN install No prebuilt binaries found (target=14.15.3 runtime=node arch=x64 libc= platform=linux)
../libusb/libusb/os/linux_udev.c:40:10: fatal error: libudev.h: Datei oder Verzeichnis nicht gefunden #include <libudev.h>          ^~~~~~~~~~~compilation terminated.
make: *** [libusb.target.mk:150: Release/obj.target/libusb/libusb/libusb/os/linux_udev.o] Fehler 1
gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)gyp ERR! stack     at ChildProcess.emit (events.js:315:20)gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)
gyp ERR! System Linux 5.9.0-0.bpo.2-amd64gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"gyp ERR! cwd /opt/iobroker/node_modules/usbgyp ERR! node -v v14.15.3gyp ERR! node-gyp -v v5.1.0gyp ERR! not ok 
upload [5] fritzdect.admin /opt/iobroker/node_modules/iobroker.fritzdect/admin/words.js words.js application/javascript
upload [4] fritzdect.admin /opt/iobroker/node_modules/iobroker.fritzdect/admin/tsconfig.json tsconfig.json application/json
upload [3] fritzdect.admin /opt/iobroker/node_modules/iobroker.fritzdect/admin/style.css style.css text/css
upload [2] fritzdect.admin /opt/iobroker/node_modules/iobroker.fritzdect/admin/index_m.html index_m.html text/html
upload [1] fritzdect.admin /opt/iobroker/node_modules/iobroker.fritzdect/admin/fritzdect_logo.png fritzdect_logo.png image/png
upload [0] fritzdect.admin /opt/iobroker/node_modules/iobroker.fritzdect/admin/admin.d.ts admin.d.ts video/mp2t
Update "system.adapter.fritzdect.0"
process exited with code 0

fritzdect.0	2021-01-04 20:02:59.017	error	(89808) no response part in returned message
fritzdect.0	2021-01-04 20:02:59.016	error	(89808) fritzbox returned this {"msg":"failed to login, wrong user name or password","function":"send_response","error":"0000000000000000"}
fritzdect.0	2021-01-04 20:02:26.543	error	(89808) no response part in returned message
fritzdect.0	2021-01-04 20:02:26.542	error	(89808) fritzbox returned this {"msg":"failed to login, wrong user name or password","function":"send_response","error":"0000000000000000"}

Diesmal hat ein Downgrade auf 1.1.4 gereicht und er logt sich wieder an der Fritz ein. Fritz ist übrigens ne 7590 mit 07.24-84940 BETA

fritzdect.0	2021-01-04 20:07:12.246	info	(96999) setting up Switch/DECT2xx object Kamera
fritzdect.0	2021-01-04 20:07:12.233	info	(96999) setting up Thermostat/DECT3xx object Heizung Bad
fritzdect.0	2021-01-04 20:07:12.204	info	(96999) setting up Thermostat/DECT3xx object Heizung Wohnzimmer
fritzdect.0	2021-01-04 20:07:12.200	info	(96999) create Devices 3
fritzdect.0	2021-01-04 20:07:09.371	info	(96999) entered ready
fritzdect.0	2021-01-04 20:07:09.348	info	(96999) starting. Version 1.1.4 in /opt/iobroker/node_modules/iobroker.fritzdect, node: v14.15.3, js-controller: 3.1.6
host.Beelink	2021-01-04 20:07:07.992	info	instance system.adapter.fritzdect.0 started with pid 96999

[foxthefox]

@Jan1

auf GitHub bin ich gerade am gleichen Problem dran.
Ab FB Version 7.25 gibt es einen neuen login Mechanismus mit anderer Verschlüsselung und deswegen habe ich es auch neu aufgesetzt. Das trifft wohl auch schon auf die Laborversion 7.24 zu.
Da scheint etwas mit dem hashing nicht richtig zu laufen und der fallback zu md5 klappt nicht, weil die fritzbox schon mit etwas neuen antwortet.

Bin dran, rauszufinden an was das liegt.

[Jan1]

@foxthefox
OK, dann warte ich eben. Dachte nur weil,ich irgendwo was gelesen hatte, dass für die neue Adapter Version für eine Funktion 7.24 vorausgesetzt wird, dass es laufen muss. Wobei die alte Adapter Version ja mit dem Login auf der 7.24 Labor kein Problem hat

Ich bin eh recht entspannt, wenn mal was nicht läuft, hab ja ein Backup und 20 Minuten später wieder ein sauberes System. Hatte mich nur gewundert, dass eben beim ersten Versuch der Downgrade nicht gereicht hatte.

[foxthefox]

@Jan1
auf GitHub wurde berichtet, daß es mit Version 2.1.6 auch mit FW 7.24 geht.
War ein größerer Akt rauszufinden, was wie zu hashen ist. Aber nun geht es wohl und der Adapter ist vorbereitet auf das offizielle 7.25

[Jan1]

@foxthefox
Wieder später getestet und berichtet

[Jan1]

@foxthefox
Oh je, Du hast Die IDs geändert. kannst da nicht einfach bei den selben Namen bleiben? So muss ich mein sehr komplexes Heizungsscript anpassen.

[foxthefox]

@Jan1
Ja, die Datenstruktur ist nun universell und version 2.x ist dahingehend ein breaking change.
Jetzt ist es einheitlich DECT_ ohne dem Versuch es auf das erste Gerät welches es mal gab zu projizieren. Auch bei den DECT210 steht ja heute schon DECT200 drin.

Übrigens gibt es parallel ein Thread zum Test der neuen Version 2.1.x

[Jens Lattwesen]

Moin,

seit dem letzten Update des Adapters (2.1.7) bekomme ich im Log folgende Fehler:

[foxthefox]

@Jens-Lattwesen
Laut der Rückmeldung ist die Verbindung in der FB abrupt zurückgesetzt worden. FB mag also keine Zugriffe mehr.
Ich denke die benötigt ein reboot.

Ansonsten schau dir das Abfrageintervall an, mit dem du den Adapter eingestellt hast. Hier liegt in den meisten Fällen die Ursache für viele Zugriffe in kurzer Zeit.
Ebenso können sehr viele Kommandos wegen falscher Skripte ein Feuerwerk an Kommunikation verursachen. Und dann ggf. noch andere Instanzen aus IOB oder anderen Systemen, die alle auf die FB zugreifen wollen.

Wenn der Adapter nach dem Starten und ein "entered ready" noch Geräte anlegt, steht prinzipiell die Verbindung alles weitere ist dann ggf. auch im debug-Modus anzuschauen.

[Jens Lattwesen]

@foxthefox Vielen Dank!

Habe im ersten Schritt den Abfrageintervall (Stand auf "0") auf 60 hochgesetzt.

Bislang scheint das zu helfen, beobachte das heute und starte die FB nachher nochmal neu.

[Jan1]

@jens-lattwesen
normal steht der auf 300