Hallo,
ich habe hier einen ZWave USB-Stick AEON Labs Z-Stick Series 2
Internals:
CFGFN /opt/fhem/MyFHEM/ZWave.cfg
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyUSB0@115200
DeviceName /dev/ttyUSB0@115200
FD 10
NAME ZWave_01
NR 100
PARTIAL
RAWMSG 0004000206310504220029
ReadTime 1422862906.42922
STATE Initialized
TYPE ZWDongle
ZWave_01_MSGCNT 648
ZWave_01_TIME 2015-02-02 08:41:46
homeId 0184e88b
nrNAck 0
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1422770691.69502
VALUE CONNECTED
Matchlist:
1:ZWave .*
Readings:
2015-02-01 07:04:51 homeId HomeId:0184e88b CtrlNodeId:01
2015-02-01 07:04:51 state opened
SendStack:
Attributes:
group Management
icon cul_868@darkblue
room Z-HA-fhem
verbose 5
und einen Zwischenstecker Fibaro FGWPF-101 in erster Linie zur Reichweitenerweiterung
Internals:
CFGFN /opt/fhem/MyFHEM/ZWave.cfg
DEF 0184e88b 2
IODev ZWave_01
LASTInputDev ZWave_01
MSGCNT 641
NAME ZWSteckdose
NR 101
STATE on
TYPE ZWave
ZWave_01_MSGCNT 641
ZWave_01_RAWMSG 000400020a320221440000005b0000
ZWave_01_TIME 2015-02-02 08:42:22
homeId 0184e88b
id 02
lastMsgTimestamp 1422862942.4175
CHANGETIME:
Helper:
Dblog:
Energy:
Mydblog:
TIME 1422862942.42373
VALUE 0.91 kWh
Power:
Mydblog:
TIME 1422862906.46688
VALUE 4.1 W
Readings:
2015-02-02 08:42:22 energy 0.91 kWh
2015-02-02 08:41:46 power 4.1 W
2015-01-31 16:57:05 reportedState on
2015-01-31 16:57:05 state on
2015-01-31 14:36:59 version Lib 3 Prot 3.52 App 25.25
Attributes:
IODev ZWave_01
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD MARK SWITCH_BINARY METER SENSOR_MULTILEVEL
icon message_socket@darkblue
room ZWave
und dann noch den FGS221 Double Relay Switch 2x1.5kW
Internals:
CFGFN /opt/fhem/MyFHEM/ZWave.cfg
DEF 0184e88b 3
IODev ZWave_01
NAME ZWSchalter
NR 106
STATE -
TYPE ZWave
homeId 0184e88b
id 03
Readings:
2015-01-31 16:54:27 mcEndpoints total 2, identical
2015-01-31 16:53:59 reportedState off
2015-01-31 16:53:59 state off
2015-01-31 16:54:39 swa on off
Attributes:
IODev ZWave_01
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL SWITCH_BINARY SWITCH_ALL FIRMWARE_UPDATE_MD POWERLEVEL MARK SWITCH_BINARY MULTI_CHANNEL
devStateIcon .*:rc_BLANC
icon taster_ch@darkblue
room ZWave
stateFormat -
webCmd :
Der Schalter ist seit Tagen ohne Strom, also offline. Wenn ich über fhem on/off schalte, dann sollte ich der Hinweis kommen, dass der Schalter nicht erreicht werden kann. Dem ist aber nicht so. fhem zeigt einen erfolgreichen Schaltvorgang an (Lampen-Icon).
Im Log steht folgendes
2015.02.02 08:48:25 2: ZWave set ZWSchalter_01 on
2015.02.02 08:48:25 5: SW: 010d00130307600d01012501FF0556
2015.02.02 08:48:25 5: ZWDongle/RAW: /060104011301e8
2015.02.02 08:48:25 5: SW: 06
2015.02.02 08:48:25 5: ZWDongle_Read ZWave_01: 011301
2015.02.02 08:48:25 5: ZWave_01 dispatch 011301
Sollte das wirklich so sein?
Danke und ciao
walter
Das ist so korrekt.
Fhem ändert den Status des Icons bei Ausführung des set-Befehls. Es findet keine Auswertung und Kontrolle eines Bestätigungstelegramms des Aktors statt. In Deinem Log sieht man nur, dass der Befehl vom Dongle korrekt verschickt wurde.
Hallo krikan,
das mag bzgl des Sendens so korrekt sein, aber ist es auch sinnvoll?!?!?. Hebe eben zur Sicherheit gegoogelt - ZWave ist ja ein bidirektionales Protokoll. Meinem Verständnis nach sollte doch dann der Aktor bestätigen, dass er den Befehl erhalten und erfolgreich/nicht erfolgreich durchgeführt hat. Geschweige, dass der Sender erkennt er kann den Aktor gar nicht erreichen und dies meldet.
Habe ich hier ein falsches Verständnis?
Danke und ciao
walter
Nein, Du hast kein falsches Verständnis.
Denke, dass das eher eine Design-Entscheidung für Zwave von Rudi ist. In Fhem hat Homematic die bidi-Rücktelegrammauswertung implementiert. EnOcean kann es seit kurzem bei expliziter Anforderung an einzelne Devices auch. Näheres kann Dir vermutlich Rudi schreiben.
Hatte bzgl. batteriebtriebenen Devices mal versucht die Rückantwort mit einzuarbeiten; bin dort aber mangels Programmierkenntnissen noch nicht wirklich zum Ergebnis gekommen.
Ich war bis gerade der Ansicht, dass beim Eintreffen einer Fehlermeldung vom Dongle (NO_ACK, etc) der Status entsrechend gesetzt wird. Ist vermutlich nicht so, und muesste gefixt werden.
@Rudi
Es müsste dann doch eine Überwachung der Rückantworten der Devices geben. Die nimmt aber Fhem nach meinem Verständnis eben nicht vor. Es wird nur geprüft, ob Dongle Befehl korrekt verarbeitet und verschickt hat. Das Problem hatten wir nach meiner Erinnerung im wakeup-Device-Thread schon einmal diskutiert: Verschickte und nicht beantwortete Befehle werden nicht erneut verschickt. Bisher laufen nur bestimmte Abfragen auf ein Timeout. Oder irre ich mich oder verwechsel etwas?
ZitatEs müsste dann doch eine Überwachung der Rückantworten der Devices geben
Das ist zu schwammig formuliert. Wenn der Dongle meint, dass es nicht geht, dann muesste das sichtbar sein (Status und Event). Ein erneutes Versenden sehe ich nicht als Aufgabe des Moduls, aus diversen Grunden. Der Benutzer kann natuerlich auf Events reagieren, und selbst erneut versuchen.
Ok, versuche es mal konkreter:
Wenn ich einen vom Strom abgeklemmten Aktor (hier FGRM222) schalte (set xy up oder down) , erhalte ich das folgende Log:
2015.02.02 17:42:56 5: SW: 01090013040325010005c3
2015.02.02 17:42:56 5: ZWDongle/RAW: /060104011301e8
2015.02.02 17:42:56 5: SW: 06
2015.02.02 17:42:56 5: ZWDongle_Read ZWDongle_0: 011301
2015.02.02 17:42:56 5: ZWDongle_0 dispatch 011301
Es gibt keine Fehlermeldung im Log, dass der Aktor nicht erreicht wird. Das Dongle erwartet also kein ACK durch den Aktor. Für Fhem sieht es so aus, als wäre der Befehl korrekt verarbeitet; ist er aber nicht. Dass der Aktor im Erfolgsfall ein Telegramm mit dem Status zurückmeldet, wird von Fhem meines Wissens nach nicht kontrolliert. Also keine Reaktion als Event/State.
Anders ist dies bei Get-Befehlen. Hier erhalte ich folgendes Log:
2015.02.02 17:37:28 5: SW: 010800130402320105d4
2015.02.02 17:37:28 5: ZWDongle/RAW: /06
2015.02.02 17:37:28 5: ZWDongle/RAW: /0104011301e8
2015.02.02 17:37:28 5: SW: 06
2015.02.02 17:37:28 5: ZWDongle_Read ZWDongle_0: 011301
2015.02.02 17:37:28 5: ZWDongle_0 dispatch 011301
2015.02.02 17:37:28 5: ZWDongle/RAW: /010500130501ed
2015.02.02 17:37:28 5: SW: 06
2015.02.02 17:37:28 5: ZWDongle_Read ZWDongle_0: 00130501
2015.02.02 17:37:28 5: ZWDongle_0 dispatch 00130501
2015.02.02 17:37:28 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:
2015.02.02 17:37:28 2: ZWDongle_0 ERROR: SEND_DATA returned 01 - UNKOWN_ERROR
Fhem liefert mir in Fhemweb eine Timeout-Fehlermeldung und im Log sehe ich ebenfalls einen ERROR. Anscheinend wartet also Fhem auf eine Antwort und auch das Dongle erwartet eine Antwort.
Die fehlende Kontrolle einer Aktor-Antwort auf set-Befehle kenne ich bei Zwave-Fhem nicht anders (nutze Zwave aber noch nicht so lange). Hatte es darauf zurückgeführt, dass Fhem fehlende Rückantworten auf set-Befehle nicht eigenständig kontrolliert/überwacht und das Dongle nicht wissen kann, ob der Status automatisch gemeldet wird oder gepollt werden muss. Darum habe ich nicht verstanden, wie das gefixt werden kann.
Jetzt der Bogen zu den wakeup-Devices: Dort hatten wir vor der Änderung genau das Problem, dass set-Befehle verschickt, aber nie beantwortet/verarbeitet wurden. Eine Fehlermeldung war auch nie im Log vorhanden.
So bin jetzt auch in ZWave eingestiegen - u.a. wg. Mesh und den vielen verfügbaren Devices...
Bei ersten Tests mit nur einem FGWPF-101 Plug (kein MESH) an einem ZME_UZB1 USB-Stick bin ich unerwartet schnell an die Reichweitengrenze gestoßen. Ich war etwas überrascht, dass bereits unter 10m Schluss war - keine Steinwände im Haus. Mit Homematic an einem HMLAN erreiche ich problemlos alle Positionen im Haus...
Dass der Plug dann manchmal nicht geschaltet hatte, habe ich erst gesehen, als ich öfter was mit GET zurücklesen wollte, was oft ging, da ich an wohl gerade an der Grenze war. Leider funktioniert der "range detection" Test mit FHEM nicht, der im FGWPF-101 eingebaut ist. Der Ausbau auf Mesh bringt dann sicher mehr Robustness, aber ohne Fehlerbehandlung auch keine Sicherheit. Bin jetzt etwas ratlos, ob das ein generelles FHEM-Thema ist.
Lt. ZWave Protocol Punkt 5 TRANSFER LAYER wird die Übertragung mit einem ACK gesichert:
Singlecast frames are always transmitted to one specific node, and the frame is acknowledged so the
transmitter knows that the frame has been received.
und
The singlecast frame can optionally be used without acknowledgement in a system where reliable
communication isn't required.
Ich fände es sehr wünschenswert, wenn ein fehlendes ACK in FHEM auch bei den SET-Befehlen sichtbar gemacht wird, sofern das möglich ist. Liefern die Controller (USB Sticks etc.) denn keine Fehlermeldung? Oder wird die Übertragung (SET-Befehl) ohne explizites ACK gestartet?
Siehe meine Antwort #4. Ich habs auf der TODO Liste.
super. Danke.
Ich habe fuer set an nicht batteriebetriebenen Geraete ACK-Meldungen aktiviert: es hat die Callback gefehlt, ohne diesen Byte gibt es keine Rueckmeldung, trotz spezifizierten Optionen.
Falls die Uebertragung klappt, dann wird das Reading transmit ohne Event auf OK gesetzt. Sonst wird state auf TRANSMIT_NO_ACK und transmit auf NO_ACK gesetzt, beide mit Event. Bitte testen, koennte Nebenwirkungen haben.
Falls keine mehr da sind, dann koennen wir pruefen, ob das fuer Batteriebetriebene auch eine gute Idee ist.
Ab morgen per update.
Danke! Funktioniert hier so wie beschrieben bei ACK und NO_ACK. Bisher in meiner Zwave-Kleinumgebung ohne Nebenwirkungen.
Dass dies so "einfach" ist und mit so wenig Code auskommt; was habe ich mir da bei meinen Versuchen schon zurechtgebastelt. :-[.
hab es gerade ausprobiert - klappt super. Und wenn der Node wieder verfügbar wird, dann wird das auch richtig erkannt und im GUI automatsch mit dem dann aktiven Status angezeigt.
Ich fände es gut wenn anstatt der Anzeige "TRANSMIT_NO_ACK" auch ein default icon dafür angezeigt wird - WLAN_Status.0.png finde ich ganz passend oder das setoff / seton mit dem eingebauten Ausrufezeichen, dann weiss man sogar welcher Schaltvorgang (an oder aus) schief ging. Ich glaube das hatte ich bei HomeMatic mal nach einer fehlerhaften Übertragung gesehen.
Hab jetzt mal das WLAN_Staus.0 gesetzt mit
attr Geraet devStateIcon TRANSMIT_NO_ACK:WLAN_Status.0
Wie müsste ich die Datei WLAN_Status.0.png kopieren/umbenennen, damit es automatisch verwendet wird ? - siehe S.35 (Heimautomatisierung mit fhem - für Einsteiger Version 4.0 )
Und dann möchte ich noch einen watchdog einrichten - zumindest für die Geräte, die am Netz hängen, um regelmässig Informationen über Ausfälle zu bekommen. Diese Informationen müsste doch auch der Controller parat haben. Der führt ja auch eine Liste zu den "failed devices". Wie könnte man sowas möglichst geschickt in FHEM realisieren - oder gibt es das vielleicht schon?
ZitatWie müsste ich die Datei WLAN_Status.0.png kopieren/umbenennen, damit es automatisch verwendet wird ?
Am besten die Datei fhem/www/images/*/iconalias.txt bearbeiten (default gibts noch nicht, aber fhemSVG und openautomation), und da ein Synonym eintragen.