Fibaro FGSS-001 smoke sensor

FhemOnSynology · 01 März 2014, 16:48:21

Figaro hat einen interessanten und optisch sehr ansprechenden Rauchmelder auf den Markt gebracht: http://www.fibaro.com/en/system-fibaro/smoke-sensor-en
Nachdem ich mit den Fibaro FGWP011 Steckdosen gute Erfahrungen gemacht habe dachte ich mir ich versuche es mal mit dem FGSS-001.

Ergebnis:
Nach der Inclusion wurde der FGSS-001 von FHEM erkannt und autocreate hat das Gerät als "ZWave_a1_9" angelegt.
Auszug aus der FHEM.log:

Code Auswählen

2014.02.27 10:24:53.128 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem?cmd={ReadingsVal(%22ZWDongle_0%22,%22addNode%22,%22%22)}&XHR=1
2014.02.27 10:24:53.129 5: Cmd: >{ReadingsVal("ZWDongle_0","addNode","")}<
2014.02.27 10:24:53.137 4: /fhem?cmd={ReadingsVal(%22ZWDongle_0%22,%22addNode%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:24:53.141 4: HTTP FHEMWEB:192.168.138.230:55542 GET /fhem?cmd={AttrVal(%22ZWDongle_0%22,%22room%22,%22%22)}&XHR=1
2014.02.27 10:24:53.142 5: Cmd: >{AttrVal("ZWDongle_0","room","")}<
2014.02.27 10:24:53.152 4: /fhem?cmd={AttrVal(%22ZWDongle_0%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:24:53.273 4: HTTP FHEMWEB:192.168.138.230:55542 GET /fhem?XHR=1&inform=type=status;filter=ZWDongle_0×tamp=1393493093269
2014.02.27 10:24:59.258 4: Connection closed for FHEMWEB:192.168.138.230:55542
2014.02.27 10:24:59.303 4: HTTP FHEMWEB:192.168.138.230:55545 GET /fhem&detail=ZWDongle_0&detail=ZWDongle_0&dev.setZWDongle_0=ZWDongle_0&cmd.setZWDongle_0=set&arg.setZWDongle_0=addNode&val.setZWDongle_0=on
2014.02.27 10:24:59.304 5: Cmd: >set ZWDongle_0 addNode on<
2014.02.27 10:24:59.305 5: SW: 0105004a810332
2014.02.27 10:24:59.309 5: Triggering ZWDongle_0 (1 changes)
2014.02.27 10:24:59.310 5: Notify loop for ZWDongle_0 addNode on
2014.02.27 10:24:59.314 5: ZWDongle/RAW: /060107004a03010000b0
2014.02.27 10:24:59.314 5: SW: 06
2014.02.27 10:24:59.318 5: ZWDongle_Read ZWDongle_0: 004a03010000
2014.02.27 10:24:59.319 5: ZWDongle_0 dispatch 004a03010000
2014.02.27 10:24:59.319 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000
2014.02.27 10:24:59.320 5: Triggering ZWDongle_0 (1 changes)
2014.02.27 10:24:59.320 5: Notify loop for ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2014.02.27 10:24:59.321 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2014.02.27 10:24:59.325 4: HTTP FHEMWEB:192.168.138.230:55545 GET /fhem?detail=ZWDongle_0
2014.02.27 10:24:59.360 4: /fhem?detail=ZWDongle_0 / RL:2351 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:24:59.416 4: HTTP FHEMWEB:192.168.138.230:55545 GET /fhem/pgm2/style.css
2014.02.27 10:24:59.423 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem/pgm2/fhemweb.js
2014.02.27 10:24:59.426 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem/pgm2/svg.js
2014.02.27 10:24:59.428 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.02.27 10:24:59.466 4: Connection accepted from FHEMWEB:192.168.138.230:55609
2014.02.27 10:24:59.469 4: HTTP FHEMWEB:192.168.138.230:55601 GET /fhem/pgm2/fhemweb_noArg.js
2014.02.27 10:24:59.472 4: HTTP FHEMWEB:192.168.138.230:55545 GET /fhem/pgm2/fhemweb_svg.js
2014.02.27 10:24:59.476 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem/pgm2/fhemweb_textField.js
2014.02.27 10:24:59.478 4: HTTP FHEMWEB:192.168.138.230:55609 GET /fhem/pgm2/fhemweb_slider.js
2014.02.27 10:24:59.481 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem/pgm2/fhemweb_time.js
2014.02.27 10:24:59.484 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem/pgm2/dashboard_style.css
2014.02.27 10:24:59.514 4: HTTP FHEMWEB:192.168.138.230:55545 GET /fhem/images/default/fhemicon.png
2014.02.27 10:24:59.518 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem/images/default/icoEverything.png
2014.02.27 10:24:59.523 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem?cmd={ReadingsVal(%22ZWDongle_0%22,%22addNode%22,%22%22)}&XHR=1
2014.02.27 10:24:59.524 5: Cmd: >{ReadingsVal("ZWDongle_0","addNode","")}<
2014.02.27 10:24:59.533 4: /fhem?cmd={ReadingsVal(%22ZWDongle_0%22,%22addNode%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:24:59.536 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem?cmd={AttrVal(%22ZWDongle_0%22,%22room%22,%22%22)}&XHR=1
2014.02.27 10:24:59.537 5: Cmd: >{AttrVal("ZWDongle_0","room","")}<
2014.02.27 10:24:59.545 4: /fhem?cmd={AttrVal(%22ZWDongle_0%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:24:59.652 4: HTTP FHEMWEB:192.168.138.230:55545 GET /fhem?XHR=1&inform=type=status;filter=ZWDongle_0×tamp=1393493099649
2014.02.27 10:25:02.859 5: ZWDongle/RAW: /0107004a03020000b3
2014.02.27 10:25:02.859 5: SW: 06
2014.02.27 10:25:02.868 5: ZWDongle_Read ZWDongle_0: 004a03020000
2014.02.27 10:25:02.869 5: ZWDongle_0 dispatch 004a03020000
2014.02.27 10:25:02.869 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:0000
2014.02.27 10:25:02.870 5: Triggering ZWDongle_0 (1 changes)
2014.02.27 10:25:02.870 5: Notify loop for ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2014.02.27 10:25:02.874 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2014.02.27 10:25:02.979 5: ZWDongle/RAW: /0118004a0303091104a1029c31867270858e7a738b9156848071
2014.02.27 10:25:02.979 5: SW: 06
2014.02.27 10:25:02.988 5: ZWDongle_Read ZWDongle_0: 004a0303091104a1029c31867270858e7a738b91568480
2014.02.27 10:25:02.989 5: ZWDongle_0 dispatch 004a0303091104a1029c31867270858e7a738b91568480
2014.02.27 10:25:02.989 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:03 ARG:091104a1029c31867270858e7a738b91568480
2014.02.27 10:25:02.990 5: Triggering global (1 changes)
2014.02.27 10:25:02.990 5: Notify loop for global UNDEFINED ZWave_a1_9 ZWave 0161ec85 9 9c31867270858e7a738b91568480
2014.02.27 10:25:02.991 2: autocreate: define ZWave_a1_9 ZWave 0161ec85 9 9c31867270858e7a738b91568480
2014.02.27 10:25:02.994 1: Adding the controller 01 to association group 1
2014.02.27 10:25:02.995 5: SW: 010a00130a04850101010569
2014.02.27 10:25:02.998 5: Triggering global (2 changes)
2014.02.27 10:25:03.000 2: autocreate: define FileLog_ZWave_a1_9 FileLog /usr/local/FHEM/var/log/ZWave_a1_9-%Y.log ZWave_a1_9
2014.02.27 10:25:03.002 5: Triggering global (3 changes)
2014.02.27 10:25:03.002 5: Triggering global (4 changes)
2014.02.27 10:25:03.096 5: ZWDongle/RAW: /060104011301e8
2014.02.27 10:25:03.097 5: SW: 06
2014.02.27 10:25:03.108 5: ZWDongle_Read ZWDongle_0: 011301
2014.02.27 10:25:03.109 5: ZWDongle_0 dispatch 011301
2014.02.27 10:25:03.699 5: ZWDongle/RAW: /0107004a03050900bd
2014.02.27 10:25:03.699 5: SW: 06
2014.02.27 10:25:03.709 5: ZWDongle_Read ZWDongle_0: 004a03050900
2014.02.27 10:25:03.710 5: ZWDongle_0 dispatch 004a03050900
2014.02.27 10:25:03.710 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0900
2014.02.27 10:25:03.711 4: ZWDongle_0 unhandled command ZW_ADD_NODE_TO_NETWORK
2014.02.27 10:25:12.887 4: Connection closed for FHEMWEB:192.168.138.230:55545
2014.02.27 10:25:12.929 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem&detail=ZWDongle_0&detail=ZWDongle_0&dev.setZWDongle_0=ZWDongle_0&cmd.setZWDongle_0=set&arg.setZWDongle_0=addNode&val.setZWDongle_0=off
2014.02.27 10:25:12.930 5: Cmd: >set ZWDongle_0 addNode off<
2014.02.27 10:25:12.931 5: SW: 0105004a0504b1
2014.02.27 10:25:12.938 5: Triggering ZWDongle_0 (1 changes)
2014.02.27 10:25:12.938 5: Notify loop for ZWDongle_0 addNode off
2014.02.27 10:25:12.943 5: ZWDongle/RAW: /06
2014.02.27 10:25:12.952 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem?detail=ZWDongle_0
2014.02.27 10:25:12.991 4: /fhem?detail=ZWDongle_0 / RL:2360 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:25:12.993 5: ZWDongle/RAW: /0107004a04060900b9
2014.02.27 10:25:12.994 5: SW: 06
2014.02.27 10:25:12.998 5: ZWDongle_Read ZWDongle_0: 004a04060900
2014.02.27 10:25:12.998 5: ZWDongle_0 dispatch 004a04060900
2014.02.27 10:25:12.999 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:06 ARG:0900
2014.02.27 10:25:12.999 5: Triggering ZWDongle_0 (1 changes)
2014.02.27 10:25:13.000 5: Notify loop for ZWDongle_0 ZW_ADD_NODE_TO_NETWORK done
2014.02.27 10:25:13.001 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK done
2014.02.27 10:25:13.052 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem/pgm2/style.css
2014.02.27 10:25:13.057 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem/pgm2/svg.js
2014.02.27 10:25:13.062 4: HTTP FHEMWEB:192.168.138.230:55601 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.02.27 10:25:13.064 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem/pgm2/fhemweb.js
2014.02.27 10:25:13.067 4: HTTP FHEMWEB:192.168.138.230:55609 GET /fhem/pgm2/fhemweb_noArg.js
2014.02.27 10:25:13.093 4: Connection accepted from FHEMWEB:192.168.138.230:55625
2014.02.27 10:25:13.096 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem/pgm2/fhemweb_svg.js
2014.02.27 10:25:13.100 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem/pgm2/fhemweb_textField.js
2014.02.27 10:25:13.102 4: HTTP FHEMWEB:192.168.138.230:55601 GET /fhem/pgm2/dashboard_style.css
2014.02.27 10:25:13.105 4: HTTP FHEMWEB:192.168.138.230:55625 GET /fhem/pgm2/fhemweb_slider.js
2014.02.27 10:25:13.108 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem/pgm2/fhemweb_time.js
2014.02.27 10:25:13.136 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem/images/default/fhemicon.png
2014.02.27 10:25:13.145 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem/images/default/icoEverything.png
2014.02.27 10:25:13.149 4: HTTP FHEMWEB:192.168.138.230:55601 GET /fhem?cmd={AttrVal(%22ZWDongle_0%22,%22room%22,%22%22)}&XHR=1
2014.02.27 10:25:13.150 5: Cmd: >{AttrVal("ZWDongle_0","room","")}<
2014.02.27 10:25:13.159 4: /fhem?cmd={AttrVal(%22ZWDongle_0%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:25:13.161 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem?cmd={ReadingsVal(%22ZWDongle_0%22,%22addNode%22,%22%22)}&XHR=1
2014.02.27 10:25:13.162 5: Cmd: >{ReadingsVal("ZWDongle_0","addNode","")}<
2014.02.27 10:25:13.172 4: /fhem?cmd={ReadingsVal(%22ZWDongle_0%22,%22addNode%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:25:13.283 4: HTTP FHEMWEB:192.168.138.230:55552 GET /fhem?XHR=1&inform=type=status;filter=ZWDongle_0×tamp=1393493113280
2014.02.27 10:25:15.798 4: Connection closed for FHEMWEB:192.168.138.230:55552
2014.02.27 10:25:15.803 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem?room=Unsorted
2014.02.27 10:25:15.848 4: /fhem?room=Unsorted / RL:1313 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2014.02.27 10:25:15.906 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem/pgm2/style.css
2014.02.27 10:25:15.911 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem/pgm2/svg.js
2014.02.27 10:25:15.914 4: HTTP FHEMWEB:192.168.138.230:55601 GET /fhem/pgm2/fhemweb.js
2014.02.27 10:25:15.920 4: HTTP FHEMWEB:192.168.138.230:55609 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.02.27 10:25:15.922 4: HTTP FHEMWEB:192.168.138.230:55625 GET /fhem/pgm2/fhemweb_noArg.js
2014.02.27 10:25:15.925 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem/pgm2/fhemweb_svg.js
2014.02.27 10:25:15.952 4: Connection accepted from FHEMWEB:192.168.138.230:55629
2014.02.27 10:25:15.956 4: HTTP FHEMWEB:192.168.138.230:55601 GET /fhem/pgm2/fhemweb_time.js
2014.02.27 10:25:15.958 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem/pgm2/fhemweb_textField.js
2014.02.27 10:25:15.961 4: HTTP FHEMWEB:192.168.138.230:55629 GET /fhem/pgm2/fhemweb_slider.js
2014.02.27 10:25:15.964 4: HTTP FHEMWEB:192.168.138.230:55609 GET /fhem/pgm2/dashboard_style.css
2014.02.27 10:25:15.999 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem/images/default/fhemicon.png
2014.02.27 10:25:16.004 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem/images/default/icoEverything.png
2014.02.27 10:25:16.129 4: HTTP FHEMWEB:192.168.138.230:55592 GET /fhem?XHR=1&inform=type=status;filter=room=Unsorted×tamp=1393493116124
2014.02.27 10:25:17.314 4: Connection closed for FHEMWEB:192.168.138.230:55592
2014.02.27 10:25:17.319 4: HTTP FHEMWEB:192.168.138.230:55595 GET /fhem/FileLog_logWrapper&dev=Logfile&type=text&file=fhem-2014-02.log

Folgende Klassen wurden erkannt:

Code Auswählen

SENSOR_ALARM
SENSOR_MULTILEVEL
VERSION
MANUFACTURER_SPECIFIC
CONFIGURATION
ASSOCIATION
MULTI_CHANNEL_ASSOCIATION
FIRMWARE_UPDATE_MD
POWERLEVEL
TIME_PARAMETERS
MANUFACTURER_PROPRIETARY
UNKNOWN_56
WAKE_UP
BATTERY

1. Auffälligkeit:
Die Klasse "BASIC" wird nicht erkannt. Laut Bedienungsanleitung sendet der FGSS-001 aber im Alarmfall per default einen "BASIC_SET command frame" (siehe Parameter 5).
Tatsächlich wird im Alarmfall auch folgendes berichtet:

Code Auswählen

basicReport: ff

Frage 1: Sollte also nicht auch die Klasse "BASIC" enthalten sein?

Die Klassen "POWERLEVEL", "MULTI_CHANNEL_ASSOCIATION" und "TIME_PARAMETERS" kennt FHEM laut commandref nicht... Verstehe auch nicht, was deren Sinn ist.

2. Auffälligkeit:
Der FGSS-001 erwartet, dass der main controller in der Association Group 3 eingetragen wird.
Das macht autocreate nicht automatisch, so dass man zunächst keinerlei Statusmeldungen vom Rauchmelder erhält. Ich dachte Anfangs, dass die Kommunikation nicht funktioniert...

Problem/Bug:
Der FGSS-001, als batteriebetriebenes Geräte, wacht per default alle 4 Stunden auf.
Leider bekomme ich aber, im Gegensatz zu meinen Everspring ST814 Temperatur/Feuchtigkeitsmessern, keine wakeup.notification.
Wenn ich den FGSS-001 mit dem B-button manuell aufwecke, dann sehe ich im FHEM.log folgendes:

Code Auswählen

2014.03.01 16:41:26.273 5: ZWDongle/RAW: /0117004984091104a1029c31867270858e7a738b91568480f9
2014.03.01 16:41:26.274 5: SW: 06
2014.03.01 16:41:26.283 5: ZWDongle_Read ZWDongle_0: 004984091104a1029c31867270858e7a738b91568480
2014.03.01 16:41:26.283 5: ZWDongle_0 dispatch 004984091104a1029c31867270858e7a738b91568480
2014.03.01 16:41:26.284 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:09 ARG:1104a1029c31867270858e7a738b91568480

Ein zuvor gesendetes get (z.B. eine get battery) wird daraufhin auch brav ausgeliefert (nicht im log oben enthalten).

Frage 2: Könnte ein Entwickler hierfür bitte eine Anpassung machen?

FhemOnSynology · 01 März 2014, 17:02:07

Es gibt noch ein weiteres Problem mit dem FGSS-001:

Wenn ich ein get battery absetze, dann wird das ja für den nächsten wakeup zwischengespeichert.
Der FGSS-001 berichtet, unabhängig vom regulären wakeup Zyklus, eine Temperatur, wenn sich diese um >2 Grad geändert hat.
Kommt nun nach dem Zwischenspeichern des "get battery" ein Temperatur-Event rein, dann wird zwar das "get battery" ausgeliefert, die Antwort ist jedoch falsch (0% anstatt 100%).

Und so sieht der fhem.log aus (Fehlerfall):

Code Auswählen

2014.03.01 16:48:46.694 5: ZWDongle/RAW: /010c00040009063105012200c728
2014.03.01 16:48:46.695 5: SW: 06
2014.03.01 16:48:46.704 5: ZWDongle_Read ZWDongle_0: 00040009063105012200c7
2014.03.01 16:48:46.704 5: ZWDongle_0 dispatch 00040009063105012200c7
2014.03.01 16:48:46.705 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:063105012200c7
2014.03.01 16:48:46.707 5: SW: 01080013090280020568
2014.03.01 16:48:46.715 5: Triggering EG_KU_RM_FGSS_9 (1 changes)
2014.03.01 16:48:46.715 5: Notify loop for EG_KU_RM_FGSS_9 temperature: 19.9 C
2014.03.01 16:48:46.719 5: Triggering Notify_EG_KU_RM_FGSS_9
2014.03.01 16:48:46.759 3: Debug: EG_KU_RM_FGSS_9: Event=temperature: 19.9 C
2014.03.01 16:48:46.761 5: ZWDongle/RAW: /060104011301e8
2014.03.01 16:48:46.762 5: SW: 06
2014.03.01 16:48:46.774 5: ZWDongle_Read ZWDongle_0: 011301
2014.03.01 16:48:46.774 5: ZWDongle_0 dispatch 011301
2014.03.01 16:48:46.776 5: ZWDongle/RAW: /010500130500ec
2014.03.01 16:48:46.776 5: SW: 06
2014.03.01 16:48:46.784 5: ZWDongle_Read ZWDongle_0: 00130500
2014.03.01 16:48:46.784 5: ZWDongle_0 dispatch 00130500
2014.03.01 16:48:46.785 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2014.03.01 16:48:46.786 5: ZWDongle/RAW: /010900040009038003007b
2014.03.01 16:48:46.786 5: SW: 06
2014.03.01 16:48:46.794 5: ZWDongle_Read ZWDongle_0: 0004000903800300
2014.03.01 16:48:46.794 5: ZWDongle_0 dispatch 0004000903800300
2014.03.01 16:48:46.795 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:03800300
2014.03.01 16:48:46.797 5: Triggering EG_KU_RM_FGSS_9 (1 changes)
2014.03.01 16:48:46.797 5: Notify loop for EG_KU_RM_FGSS_9 battery: 0 %
2014.03.01 16:48:46.799 5: Triggering Notify_EG_KU_RM_FGSS_9

Zum Vergleich (Erfolgsfall):
Wenn ich ein "get battery" absetze und dann den FGSS-001 manuell mit dem B-button aufwecke, dann bekomme ich die korrekte Antwort (100%):

Code Auswählen

2014.03.01 16:57:11.934 5: ZWDongle/RAW: /0117004984091104a1029c31867270858e7a738b91568480f9
2014.03.01 16:57:11.934 5: SW: 06
2014.03.01 16:57:11.943 5: ZWDongle_Read ZWDongle_0: 004984091104a1029c31867270858e7a738b91568480
2014.03.01 16:57:11.944 5: ZWDongle_0 dispatch 004984091104a1029c31867270858e7a738b91568480
2014.03.01 16:57:11.944 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:09 ARG:1104a1029c31867270858e7a738b91568480
2014.03.01 16:57:11.946 5: SW: 01080013090280020568
2014.03.01 16:57:11.954 5: ZWDongle/RAW: /060104011301e8
2014.03.01 16:57:11.955 5: SW: 06
2014.03.01 16:57:11.963 5: ZWDongle_Read ZWDongle_0: 011301
2014.03.01 16:57:11.964 5: ZWDongle_0 dispatch 011301
2014.03.01 16:57:11.966 5: ZWDongle/RAW: /010500130500ec
2014.03.01 16:57:11.966 5: SW: 06
2014.03.01 16:57:11.974 5: ZWDongle_Read ZWDongle_0: 00130500
2014.03.01 16:57:11.975 5: ZWDongle_0 dispatch 00130500
2014.03.01 16:57:11.975 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2014.03.01 16:57:11.977 5: ZWDongle/RAW: /010900040009038003641f
2014.03.01 16:57:11.977 5: SW: 06
2014.03.01 16:57:11.983 5: ZWDongle_Read ZWDongle_0: 0004000903800364
2014.03.01 16:57:11.984 5: ZWDongle_0 dispatch 0004000903800364
2014.03.01 16:57:11.985 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:03800364
2014.03.01 16:57:11.986 5: Triggering EG_KU_RM_FGSS_9 (1 changes)
2014.03.01 16:57:11.987 5: Notify loop for EG_KU_RM_FGSS_9 battery: 100 %
2014.03.01 16:57:11.990 5: Triggering Notify_EG_KU_RM_FGSS_9

FHEM oder FGSS-001 Bug?

Mx112 · 01 März 2014, 19:56:12

Battery: Er sendet hier tatsächlich 0 %

Code Auswählen


03800364 => 64 = 100 %
03800300 => 00 = 0 %

Die wakeup notification sieht komisch aus. Müsste eingentlich 028407 sein.

Übrigens: Er erfüllt nicht die für Rauchmelder verpflichtende Norm DIN EN 14604.

FhemOnSynology · 01 März 2014, 20:54:03

Zitat von: Mx112 am 01 März 2014, 19:56:12
Battery: Er sendet hier tatsächlich 0 %
Code Auswählen Erweitern
03800364 => 64 = 100 % 03800300 => 00 = 0 %

Ok. Dann werde ich dazu mal den Figaro Support kontaktieren.
Ich würde jedoch das Abfragen des Batteriezustandes nach einem Wakeup bevorzugen. Das kann ich aber derzeit nicht mangels wakeup notification...

Zitat von: Mx112 am 01 März 2014, 19:56:12
Die wakeup notification sieht komisch aus. Müsste eingentlich 028407 sein.

Hier wäre es hilfreich, wenn Rudolf oder ein anderer Entwickler/Admin Feedback geben könnte ob der String interpretierbar ist oder nicht. Dann könnte ich den Figaro Support hierzu ebenfalls befragen...
UPDATE: Habe eben folgenden Thread gefunden: http://forum.fhem.de/index.php/topic,19147.msg130985.html#msg130985
Anscheinend sendet der Fibaro FGSS-001 mittels ZW_APPLICATION_UPDATE seine unterstützten Z-Wave Klassen, wenn er aufwacht. Zumindest, wenn er manuell über den B-Knopf aufgeweckt wird...

Zitat von: Mx112 am 01 März 2014, 19:56:12
Übrigens: Er erfüllt nicht die für Rauchmelder verpflichtende Norm DIN EN 14604.

Es gibt dazu eine lange Diskussion im Fibaro Forum:
http://forum.fibaro.com/viewtopic.php?t=3475

Zusammenfassung: Die EN 14604 ist für autarke Rauchmelder, also ohne Verbindung zu einer Zentrale, gedacht. Die von Fibaro erfüllten Normen EN 54-5 und EN 54-7 gelten für vernetzte Rauchmelder. Wesentlicher Unterschied: Die EN 54-x fordert keine 85db Lautstärke des eingebauten Lautsprechers in 3m Entfernung. Man sollte also eine zusätzliche Sirene installieren. Welche Auswirkungen das erfüllen oder nicht erfüllen dieser Standards auf Gebäudeversicherungen hat ist individuell zu prüfen. In der Regel haben aber Rauchmelder keinen Einfluss auf private Policen. Mir reicht der Fibaro für meinen Einsatzzweck daher aus.

FhemOnSynology · 01 März 2014, 21:51:28

Ich habe mir jetzt die Kommunikation noch einmal im Detail angesehen und mir ist folgendes aufgefallen:

Per default ist der FGSS-001 auf ein wakeupInterval von 14400 (=4h) und eine traget ID von 255 gesetzt:

Code Auswählen

wakeupReport: interval 14400 target 255

Ich hatte mich über die target ID von 255 nicht besonders gewundert und dachte, dass eben alle Nodes, die in den Association Groups hinterlegt sind über den Wakeup informiert werden. Dem ist aber anscheinend nicht so.

Nach der Diskussion hier habe ich einfach mal ein "set wakeupInterval 300 1" versucht:

Code Auswählen

wakeupReport: interval 300 target 1

Und siehe da, jetzt kommt beim automatischen wakeup auch die korrekte wakeup notification:

Code Auswählen

wakeup: notification

Wahnsinn, auf was man alles kommen muss

Kann mir jemand die Traget ID beim set wakeupInterval erklären? Steht 255 für "inaktiv"?

Meiner Meinung nach wäre es aber trotzdem gut, wenn das Melden der Geräteklassen ohne Aufforderung als wakeup interpretiert werden würde. Dann wäre das Verhalten zwischen dem automatischen und dem manuellen Wakeup per Knopfdruck auch identisch...

Mx112 · 01 März 2014, 22:00:16

Nein, ich hab hier ein Mix aus 1 und 255. Alle kommen an. Der Wert steht für das Device das reagieren soll und 255 bedeutet vermutlich "egal". Was hast Du für ein Dongle? Ggf. ignoriert der 255.
Ist der Smoke Sensor Dein einziges Batterie Device?

Schön das es jetzt klappt.

Sent from my iPad using Tapatalk

FhemOnSynology · 01 März 2014, 22:31:54

Ich nutze einen Aeon Labs Z-Stick V2 (siehe auch meine Signatur).

Habe eben meine Everspring ST814 überprüft. Diese hatten per default eine target ID von 1. Daher ist dieses Problem nicht aufgetreten.
Damit ist bewiesen, dass der Aeon Z-Stick ein Problem mit den 255 hat...

Bleibt noch das unterschiedliche Verhalten des manuellen wake ups (kein wakeup notification).

Mx112 · 02 März 2014, 01:03:57

Das ist wohl normal. Sowohl mein Fibaro Door/Window Sensor als auch der Philio 3in1 senden bei eigen ausgelösten Aktionen die Antworten auf gesammelte Anfragen mit. Wakeup Notification schicken sie nur wenn sie von allein "aufwachen", es also sich tatsächlich um eine wakeup notification handelt.

Andere Z-Wave Implementierungen verhalten sich noch strikter als FHEM. OpenZwave z.B. schickt gesammelte Anfragen gar nicht an Battery devices wenn die Bewegung, Tempereatur, etc. von sich aus melden. Es wird stur auf wakeup notification gewartet.

Everspring Komponenten hab ich noch nicht im Einsatz. Meine Battreie Sensoren haben bisher alle 255 als wakeup target per default gehabt: Fibaro, Philio, NorthQ.

rudolfkoenig · 02 März 2014, 09:06:45

Ich habe diese Diskussion zwar gerade duchtgelesen, bin aber nicht sicher ob, und wenn ja was ich machen soll.
Auch fuer andere FGSS-001 Besitzer waere eine kurze Zusammenfassung sinnvoll.

Mx112 · 02 März 2014, 12:04:40

Ich denke nicht das es ein Todo für Dich gibt. Ich habe jetzt einen Wiki Zugang angefordert und werde die Infos dort zusammentragen.

Im Endffekt waren die Lösungen hier generisch (assoziation, wakup target). Weiterhin scheint der FGSS-001 einen Bug zu haben und außerhalb der regulären wakeup notification einen falschen Wert für Battery zu senden.

FhemOnSynology · 02 März 2014, 17:48:55

Zusammenfassung meinerseits:

Der FGSS-001 erwartet, dass der main controller in der 3. Assoziationsgruppe aufgenommen wird. Vorher erhält man keine Statusmeldungen. Dazu ist ein "set associationAdd 3 1" auszuführen.
Potentielles Todo FHEM: Dieses set könnte autocreate evtl. automatisch senden.
Der FGSS-001 hat als Werkseinstellung ein Wakeup-Interval von 14400 (4h) mit Traget-ID 255. In Verbindung mit meinem Aeon Labs Z-Stick 2 führt das dazu, dass keine wakeup notifications empfangen werden. Ein "set wakeupInterval 14400 1" hat das Problem behoben.
Der FGSS-001 sendet per default im Alarmfall einen basicReport mit dem Argument "ff". FHEM empfängt diesen problemlos, obwohl die Klasse "BASIC" nicht für den FGSS-001 erkannt wird.
Potentielles Todo FHEM: Meldet der FGSS-001 tatsächlich keine Klasse BASIC? Kann diese aufgenommen werden?
Der FGSS-001 sendet nach einem manuellen wakeup durch dreimaliges Drücken des Tasters am Gerät keine wakeup notification sondern ein "ZW_APPLICATION_UPDATE" mit dem die unterstützen Klassen gemeldet werden. Das wird mit dem global verbose 3 nicht in den Logs angezeigt, so dass nicht ersichtlich ist, ob der FGSS-001 aufgewacht ist.
Potentielles Todo FHEM: Das "ZW_APPLICATION_UPDATE" bzw. ein Hinweis auf den wake up als Log 3 eintragen (nicht jeder denkt an den verbose 5, wenn er durch 3-faches Drücken testen möchte ob der FGSS-001 verbunden ist). Frage: Wie kann man sich auf das "ZW_APPLICATION_UPDATE" mit einem notify notifizieren?
Der FGSS-001 hat einen Bug, so dass ein "get battery" das mittels eines notify direkt nach dem Empfang eines Temperaturwertes gesendet wird, einen falschen Wert liefert.

rudolfkoenig · 03 März 2014, 09:29:07

ZitatMeldet der FGSS-001 tatsächlich keine Klasse BASIC? Kann diese aufgenommen werden?

FHEM schreibt alle gemeldeten Klassen (auch die fuer FHEM unbekannte), in das Attribut classes. Dies kann vom Benutzer geaendert werden, und wird von FHEM als Grundlage fuer die angeboteten Befehle verwendet. Achtung: dieses Attribut wird bei einem ZW_APPLICATION_UPDATE ueberschrieben. Hier muesste man ueberlegen, wie man das sinnvoll fixen kann. Es wuerde mich auch interessieren, wozu man ZW_APPLICATION_UPDATE eigentlich im Protokoll vorgesehen hat.

ZitatDas "ZW_APPLICATION_UPDATE" bzw. ein Hinweis auf den wake up als Log 3 eintragen

Ab sofort wird dafuer ein Event generiert (CMD: ZW_APPLICATION_UPDATE)

FhemOnSynology · 04 März 2014, 20:12:53

Zitat von: rudolfkoenig am 03 März 2014, 09:29:07
Ab sofort wird dafuer ein Event generiert (CMD: ZW_APPLICATION_UPDATE)

Habe heute ein update gemacht und auch FHEM neu gestartet.
Leider wird immer noch kein Event generiert.

fhem.log:

Code Auswählen

2014.03.04 20:08:03.448 5: ZWDongle/RAW: /0117004984091104a1029c31867270858e7a738b91568480f9
2014.03.04 20:08:03.449 5: SW: 06
2014.03.04 20:08:03.457 5: ZWDongle_Read ZWDongle_0: 004984091104a1029c31867270858e7a738b91568480
2014.03.04 20:08:03.457 5: ZWDongle_0 dispatch 004984091104a1029c31867270858e7a738b91568480
2014.03.04 20:08:03.458 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:09 ARG:1104a1029c31867270858e7a738b91568480
2014.03.04 20:08:15.311 4: Connection closed for FHEMWEB:192.168.138.230:60542
2014.03.04 20:08:15.337 4: HTTP FHEMWEB:192.168.138.230:60556 GET /fhem/FileLog_logWrapper&dev=Logfile&type=text&file=fhem-2014-03.log

FhemOnSynology · 05 März 2014, 09:52:01

Nach dem ich heute noch einmal in die Logs geschaut habe kann ich den Fehler "Event CMD: ZW_APPLICATION_UPDATE funktioniert nicht" etwas eingrenzen.

Ich hatte den Button am Rauchmelder um 19:54:56 (noch vor dem FHEM Update) und um 20:08:03 (nach dem FHEM update und Restart) gedrückt, was auch als Log 5 im fhem.log sichtbar war (siehe vorheriger Post).
Das Event "CMD: ZW_APPLICATION_UPDATE" wurde jedoch nicht angezeigt.

Heute habe ich gesehen, dass das bzw. die beiden Events erst später generiert wurde, als der Rauchmelder einen regulären wakeup um 20:57 hatte. Hier das dazugehörige Log:

Code Auswählen

2014-03-04_20:57:46 EG_KU_RM_FGSS_9 CMD: ZW_APPLICATION_UPDATE
2014-03-04_20:57:46 EG_KU_RM_FGSS_9 CMD: ZW_APPLICATION_UPDATE
2014-03-04_20:57:46 EG_KU_RM_FGSS_9 wakeup: notification
2014-03-04_20:57:47 EG_KU_RM_FGSS_9 battery: 100 %

Das Event "CMD: ZW_APPLICATION_UPDATE" wird also sehr wohl generiert, allerdings erst beim nächsten wakeup...

rudolfkoenig · 05 März 2014, 09:59:53

Ich verstehe folgendes:

ZitatZW_APPLICATION_UPDATE wird zwar Empfangen, dazugehoerige Events werden aber spaeter generiert.

Hast Du fuer dieses Geraet irgendwelche event-* Attribute gesetzt?
Sonst kann ich das Verhalten nicht nachvollziehen.
Kannst Du bitte in 10_ZWave.pm die Zeile, die mit # forum:20884 markiert ist, mit folgenden ersetzen:

Code Auswählen

    Log 1, "Before rSU";
    readingsSingleUpdate($hash, "CMD", $cmd, 1); # forum:20884
    Log 1, "After rSU";

und nochmal probieren?

Fibaro FGSS-001 smoke sensor

FhemOnSynology

FhemOnSynology

FhemOnSynology

FhemOnSynology

FhemOnSynology

FhemOnSynology

FhemOnSynology

FhemOnSynology