FGS221 Double Relay Switch 2x1.5kW offline, fhem schaltet erfolgreich

[wkarl]

Hallo,

ich habe hier einen ZWave USB-Stick AEON Labs Z-Stick Series 2

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[krikan]

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.

[wkarl]

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

[krikan]

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.

[rudolfkoenig]

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.

[krikan]

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

[rudolfkoenig]

Es 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.

[krikan]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.

[moritzthecat]

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?

[rudolfkoenig]

Siehe meine Antwort #4. Ich habs auf der TODO Liste.

[moritzthecat]

super. Danke.

[rudolfkoenig]

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.

[krikan]

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.  .

[moritzthecat]

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?

[rudolfkoenig]

Wie 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.