Fibaro FGSS-001 smoke sensor

[FhemOnSynology]

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 Erweitern

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 Erweitern

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 Erweitern

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 Erweitern

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]

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 Erweitern

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 Erweitern

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]

Battery: Er sendet hier tatsächlich 0 %

Code Auswählen Erweitern


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]

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

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

Ü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]

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 Erweitern

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 Erweitern

wakeupReport: interval 300 target 1

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

Code Auswählen Erweitern

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]

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]

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]

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]

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]

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]

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]

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

Das "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]

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 Erweitern

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]

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 Erweitern

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]

Ich verstehe folgendes:

ZW_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 Erweitern

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

und nochmal probieren?

[FhemOnSynology]

Korrekt, mit dem Drücken des Tasters wird das "ZW_APPLICATION_UPDATE" empfangen und jetzt auch das Reading "CMD" gesetzt (das ist neu). Aber das dazugehörige Event wird es später generiert.
Ich habe keine "event-*" Attribute gesetzt.

Habe die gewünschten Zeilen ersetzt bzw. ergänzt. Es kommen beim Drücken des Tasters keine Log 1 Ausgaben im fhem.log.
Muss ich FHEM neu starten nach der Änderung?

[rudolfkoenig]

Ja, oder "reload 10_ZWave.pm" durchfuehren

[FhemOnSynology]

Ok jetzt erscheinen die zusätzlichen Debugausgaben aber das Event erscheint nicht im Event monitor (den ich während des Drückens offen hatte) und im Gerätelog erst mit dem nächsten wakeup und dann gleich 3x.

fhem.log:

Code Auswählen Erweitern

2014.03.05 11:50:16.360 5: ZWDongle/RAW: /0117004984091104a1029c31867270858e7a738b91568480f9
2014.03.05 11:50:16.361 5: SW: 06
2014.03.05 11:50:16.369 5: ZWDongle_Read ZWDongle_0: 004984091104a1029c31867270858e7a738b91568480
2014.03.05 11:50:16.369 5: ZWDongle_0 dispatch 004984091104a1029c31867270858e7a738b91568480
2014.03.05 11:50:16.370 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:09 ARG:1104a1029c31867270858e7a738b91568480
2014.03.05 11:50:16.371 1: Before rSU
2014.03.05 11:50:16.372 1: After rSU
2014.03.05 11:50:32.187 4: Connection closed for FHEMWEB:192.168.138.230:53656

Geräte.log:

Code Auswählen Erweitern

2014-03-05_08:55:19 EG_KU_RM_FGSS_9 wakeup: notification
2014-03-05_08:55:20 EG_KU_RM_FGSS_9 battery: 100 %
2014-03-05_12:54:31 EG_KU_RM_FGSS_9 CMD: ZW_APPLICATION_UPDATE
2014-03-05_12:54:31 EG_KU_RM_FGSS_9 CMD: ZW_APPLICATION_UPDATE
2014-03-05_12:54:31 EG_KU_RM_FGSS_9 CMD: ZW_APPLICATION_UPDATE
2014-03-05_12:54:31 EG_KU_RM_FGSS_9 wakeup: notification
2014-03-05_12:54:32 EG_KU_RM_FGSS_9 battery: 100 %

[rudolfkoenig]

Habs hoffentlich gefixed und eingecheckt, update ab morgen.

[FhemOnSynology]

Habs hoffentlich gefixed und eingecheckt, update ab morgen.

Besten Dank, jetzt funktioniert es!

Event monitor:

Code Auswählen Erweitern

Events:
2014-03-07 20:54:32 ZWave EG_KU_RM_FGSS_9 CMD: ZW_APPLICATION_UPDATE

Habe vom Fibaro-Support bzgl. meiner Anfrage zu diesem Thema leider keine Rückmeldung erhalten...

[fhem-me]

habe am Wochenende auch dieses Teil bei mir in Betrieb genommen.
Autocreate hat funktioniert. wakeupReport steht (manuell) auf interval 14400 target 1.
Den Controller habe ich in die Association Group 3 aufgenommen.
Einziges Problem: der Z-Wave range test (Anleitung Kapitel XV) schlägt fehl. Bei (fast) jedem Poll und bei Auslesen der Temperatur ertönt ein kurzer Alarmton (Anleitung Kapitel VIII).
Beim Range-Test selbst blinkt es grün - gelb - violet - zeigt kurz rot um danach wieder von vorne zu beginnen.

Liegt hinter dem Range-Test möglicherweise ein komplexeres Protokoll?

Während des Range Tests bekomme ich im Event-Log viele BasicReport Nachrichten:

Code Auswählen Erweitern

2014-03-30_21:35:58 ZWave_a1_15 basicReport:
Im Logfile sieht ein BasicReport so aus:

Code Auswählen Erweitern


2014.03.30 21:35:58 5: ZWDongle/RAW: /01080004000f022002dc
2014.03.30 21:35:58 5: SW: 06
2014.03.30 21:35:58 5: ZWDongle_Read ZWDongle_0: 0004000f022002
2014.03.30 21:35:58 5: ZWDongle_0 dispatch 0004000f022002
2014.03.30 21:35:58 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:022002

Ein ZW_APPLICATION_UPDATE habe ich noch nicht im Log gefunden ...
Als Workaround habe ich Config 80 auf 0 gesetzt und hoffe das der regelmäßige Range-Test damit auch abgeschaltet ist und der nervige Alarmton ausbleibt.

[FhemOnSynology]

Wenn ich den Z-Wave Range Test manuell ausführe, wie es in der Bedienungsanleitung unter XV. beschrieben ist, dann habe ich genau das gleiche Verhalten (die LED blinkt in der beschriebenen Folge). Ich sehe ebenfalls die beschriebenen BasicReport-Nachrichten während des manuellen Tests und vermute ebenfalls, dass der FGSS-001 eine Antwort des Controllers erwartet. Allerdings habe ich im "normalen" Betrieb kein Problem mit Warntönen. Der Parameter 80 steht bei mir auf 1 (default).

[moe232]

Hallo,

wie kann der Fibaro Rauchmelder testweise oder als Alarmanlage ausgelöst werden? Ein set AlarmOn (wie bei HomeMatic) funktioniert bei mir nicht. Falls die Antwort "geht nicht" lautet, wäre die zweite Frage: wenn der Melder andere auslösen kann, warum können wir das nicht?

Vielen Dank
Marcus

[hanske]

Im Batteriebetrieb halte ich das für ausgeschlossen.
Er empfängt dann ja nur Events, wenn er gerade im WakeUp ist.
Eventuell geht das aber bei externer Stromversorgung.
Dann ist er ja ständig empfangsbereit
Wenn man dann temporär z.B. den Temperaturschwellwert auf 2°C setzt, löst er vielleicht einen Temperaturalarm aus.
Ein direktes "SetAlarm on" gibt es wohl nicht.

[moe232]

Prinzipiell verstehe ich das aber wie macht das HomeMatic? Da kann man setAlarm on ausführen, wenn ich das richtig verstanden habe. Und im Brandfall lösen sich die Melder ja auch gegenseitig aus.

[snickers2k]

Das würde mich auch mal Interessieren.
Es muss ja eine Art "AlarmOn" geben, wenn die Rauchmelder sich gegenseitig einen AlarmOn schicken ?!

[krikan]

wenn die Rauchmelder sich gegenseitig einen AlarmOn schicken ?!

Ist denn überhaupt gesichert, dass sie das machen? Ich kann dazu nichts finden. Die Zentrale (Controller/FHEM) wird zwar informiert, aber eine Vernetzung zwischen den Rauchmeldern kann ich nicht erlesen.
Gruß, Christian

[snickers2k]

Naja, irgendwie werden ja die anderen Rauchmelder im Alarmfall mitausgelöst, oder ? Schließlich ist das ja der Sinn.
Wenn die Geräte das also untereinander können, wieso sollte FHEM das nicht können?

Aber ich habe sowieso meine Probleme mit ZWave. An einer ZWave Steckdose kommen Befehle oft nur sehr verspätet an. Regelmäßige Verbindungsprobleme. Gleiches mit den Rauchmeldern. Dazu immer TRANSMIT_NO_ACK oder NO_ACK. Nehmen keine Kommandos an, oder geben sie nicht vernünftig in Zwave aus. Eine association untereinander habe ich jedenfalls nicht zum laufen bekommen. Werde das ganze zwar mal auf Werkseinstellungen zurück setzen und schauen, was passiert. Aber im großen und ganzen habe ich so langsam meine Zweifel an Zwave. Auch dass nicht vorhandene manuelle auslösen der Rauchmelder ist ein absolutes No-Go (auch wenn vermutlich Geräte spezifisch).. Eig waren die Dinger als Teil meiner Alarmanlage gedacht. Aber das würde dann ja auch wegfallen.
Am Ende sind die dinger zwar Schick anzusehen, aber das war es dann leider auch schon :/

Solche Probleme habe ich mit Homematic, Zigbee, Max! & Harmony mit FHEM nicht .. Auch wenn ich noch neu in der Materie bin.

[krikan]

Naja, irgendwie werden ja die anderen Rauchmelder im Alarmfall mitausgelöst, oder ?

Das ist Dein Wunsch, den ich aber weder aus der Anleitung noch den Infos im Netz als Feature des batteriebetriebenen Fibaro finden kann. Nirgendwo gibt es die Info, dass die batteriebetrieben Rauchmelder im Alarmfall untereinander funkvernetzt sind. Daher wird im Alarmfall mMn nur der entdeckende Melder anschlagen und die anderen Melder bleiben stumm. Das deckt sich auch mit meinem Verständnis von ZWave-Wakeup-Geräten, was hanske oben auch schon anführte.

Wenn die Geräte das also untereinander können, wieso sollte FHEM das nicht können?

FHEM könnte das, wenn die Geräte die Funktion hätten. Haben sie aber mMn eben nicht. Vergleiche es mal mit der Beschreibung der Popp Rauchmelder. Die werden explizit als funkvernetzt im Alarmfall und als Sirene (=externe Alarmauslösung) beworben.

Solche Probleme habe ich mit Homematic, Zigbee, Max! & Harmony mit FHEM nicht .. Auch wenn ich noch neu in der Materie bin.

ZWave braucht meiner Meinung nach deutlich mehr Einarbeitung in die Technik als die obigen Systeme. Falsche (insb. veraltete) Geräte und Mißverständnisse führen schneller zu Problemen.
Wenn Du Hilfe bei den ZWave Problemen brauchst, dann mache einfach einen neuen Thread auf und hier wird man versuchen es zu lösen....

Gruß, Christian

[hanske]

Ja, das was Krikan sagt ist richtig.
Der Fibaro Rauchmelder wacht, genau wie die anderen herkömmlichen batteriebetriebenen ZWave Geräte, nur zu bestimmten Zeiten auf um in der Zentrale gespeicherte Nachrichten abzurufen.
Du kannst ihm daher nicht so etwas wie "set AlarmOn" senden und eine sofortige Reaktion erwarten.
Es sind halt nur Sensoren.
Es gibt bisher auch nur wenige batteriebetriebene ZWave Geräte die das können. Stichwort "FLIRS" und "Beam".
Bei Homematic können das fast alle.

[jeep]

Hallo zusammen,

habe auch den FGSD-002 der aber doch fast identisch mit dem FGSS-001 ist. Am  letzteren kann man eine eine externe Stromversorgung anschließen und ihn an einen externen Alarm-Hub koppeln.
Es ist klar das ein Melder keinen anderen a la Homematic ansteuern kann.
Ich habe beide Anleitungen gelesen und verstehe folgendes (korrigiert mich wenn ich falsch liege):
Was aber beide Geräte können ist folgendes. Stellt man im Parameter 13 den Wert auf 1 oder 3 verschickt  er Alarme als Broadcast ( also nicht geroutet) an alle in Reichweite befindlichen Geräte.

Beim FGSS-001 kann man in der assocGroup_1 5 Geräte angeben die im Alarmfall angesprochen werden können.
Beim FGSD-002 kann man in der assocGroup_2 und assocGroup_4 je 5 Geräte angeben an denen dann Alarmframes gesendet werden, also Dimmer, Wallplugs, Relay Switch, Sirenen etc.

Damit sollte man doch eine ziemlich sichere Alarmierung hinbekommen, so das ich nicht unbedingt die Notwendigkeit der Vernetzung der Rauchsensoren brauche. Wie gesagt, liege ich mit meinen Vermutungen falsch lasse ich mich gern vom Gegenteil überzeugen.  Ich werde nächstes Jahr noch 2 FGSD-002 bestellen und intensive Test damit machen. Möchte jetzt die weihnachtliche Ruhe nicht durch Sirenengeheul stören.

Grüße,
Josef

[snickers2k]

Vielen Dank für die Antworten.
Ouh man... Dann habe ich da ja mal grundlegend was falsch verstanden. Nachdem Ei-Elektronics, Gira usw. bereits Funkrauchmelder hatten, bevor es welche von Zwave gab - und diese alle untereinander Auslösen, war es für mich völlig klar, dass die Zwave Rauchmelder es genau so machen - ohne weiter nachzuforschen.
Nun gut, dann gehen die Teile also zurück.

Dann also nochmal recherchieren. Vllt werden es dann ja die Popp. Obwohl teurer und vom Design einfach völlig veraltet

Nochmals danke.

[krikan]

@jeep / Josef
Verstehe es aus der Anleitung genauso wie Du. Unsicher bin ich nur bei Auswirkungen Parameter 13: Dann nur per Broadcast oder auch als Broadcast; vermutlich leider aber erstes.
Gruß, Christian

[flurin]

@krikan & @jeep
Unter Parameter 13: Note: Operating in Z-Wave network security mode automatically disables sending alarms in broadcast mode.

Es wird vermutlich nicht gehen, da der Sensor die SECURITY CLASS unterstützt. Wie es mit dem security mode geht, weiss ich nicht; ich habe mich noch nicht damit beschäftigt

[krikan]

@krikan & @jeep
Unter Parameter 13: Note: Operating in Z-Wave network security mode automatically disables sending alarms in broadcast mode.

Es wird vermutlich nicht gehen, da der Sensor die SECURITY CLASS unterstützt. Wie es mit dem security mode geht, weiss ich nicht; ich habe mich noch nicht damit beschäftigt

Aber doch nur, wenn der mit secure inkludiert (addNode on sec) wird!?
Bei einer normalen Inklusion ohne Nutzung der SECURITY CLASS tritt das Problem mMn nicht auf und Broadcast sollte funktionieren. Also im Endeffekt wahlweise. Mir ist aber persönlich auch nicht wirklich verständlich, warum ich bei Rauchmeldern mit SECURITY einbinden sollte.

[flurin]

Js, stimmt. Ich muss mich mal damit beschäftigen.

Übrigens welches Reading nimmt man am besten für den Alarm?

Bei Alarm steht bei mir:

Code Auswählen Erweitern


Smoke: unknown event 00, arg 0103


Zurzeit verwende ich ein UserReadings:

Code Auswählen Erweitern


smoke-alarm {ReadingsVal("smoke_living","alarm","") =~/event 00/ ? 0 : 1}


[krikan]

Übrigens welches Reading nimmt man am besten für den Alarm?

Bei Alarm steht bei mir:

Code Auswählen Erweitern


Smoke: unknown event 00, arg 0103


Das ist ein Event eines FGSD-002? Sieht verdächtig nach Class ALARM aus und die hat der FGSS-001 laut pepper1 nicht.
Der FGSD-002 nutzt laut pepper1 ALARM V5 und die ist in FHEM nicht explizit eingebaut. Darum auch wohl der seltsame Event. Rudi hatte V4 wegen meines Philio eingebaut.
Zu V5 finde ich keine Infos. Hast Du den gezeigten Event durch einen Testknopf ausgelöst? Evtl. ist das Rohtelegramm ganz interessant um Rückschlüsse auf die Änderungen in V5 zu finden.

[flurin]

Sensor: FIBARO System FGSD002 Smoke Sensor
Version: Lib 3 Prot 4.5 App 3.2 HW 2 FWCounter 1 FW 3.2

Der Alarm wird vom Sensor ausgelöst, also nicht mit dem Button B.
Bei einem Test Alarm (Button B) sieht es so aus:

Code Auswählen Erweitern


Smoke: Alarm Test, arg 00


[krikan]

Hallo Flurin,
das verstehe ich nicht. Testknopf-Auslösung sieht "normal" aus, d.h. so kenne ich Meldungen auch von ALARM V4. Der vorherige "reale" Event ist dann im Aufbau für mich nicht nachvollziehbar.
Gruß, Christian

[flurin]

Hallo Krikan,
Wenn Dir das hilft, hier die logs:

Zuerst mit Test-Knopf und dann mit einem echten Alarm

smoke_living (Sensor):

Code Auswählen Erweitern


2015-12-19_13:08:46 smoke_living alarm: Smoke: Alarm Test, arg 00
2015-12-19_13:08:46 smoke_living smoke-alarm: 1
2015-12-19_13:08:57 smoke_living temperature: 22.1 C
2015-12-19_13:08:57 smoke_living smoke-alarm: 1
2015-12-19_13:08:58 smoke_living alarm: Smoke: unknown event 00, arg 0103
2015-12-19_13:08:58 smoke_living smoke-alarm: 0
2015-12-19_13:09:57 smoke_living alarm: Smoke: detected, Unknown Location, arg 00
2015-12-19_13:09:57 smoke_living smoke-alarm: 1
2015-12-19_13:09:57 smoke_living alarm_type_01: level ff node 0c seconds 0
2015-12-19_13:09:57 smoke_living smoke-alarm: 1
2015-12-19_13:09:57 smoke_living alarm_type_01: level ff node 0c seconds 0
2015-12-19_13:09:57 smoke_living smoke-alarm: 1
2015-12-19_13:10:20 smoke_living temperature: 22.8 C
2015-12-19_13:10:20 smoke_living smoke-alarm: 1
2015-12-19_13:10:24 smoke_living wakeup: notification
2015-12-19_13:10:24 smoke_living smoke-alarm: 1
2015-12-19_13:10:27 smoke_living wakeup: notification
2015-12-19_13:10:27 smoke_living smoke-alarm: 1
2015-12-19_13:10:44 smoke_living temperature: 23.4 C
2015-12-19_13:10:44 smoke_living smoke-alarm: 1
2015-12-19_13:10:49 smoke_living alarm: Smoke: unknown event 00, arg 0102
2015-12-19_13:10:49 smoke_living smoke-alarm: 0
2015-12-19_13:10:49 smoke_living alarm_type_01: level 00 node 0c seconds 0
2015-12-19_13:10:49 smoke_living smoke-alarm: 0
2015-12-19_13:10:49 smoke_living alarm_type_01: level 00 node 0c seconds 0
2015-12-19_13:10:49 smoke_living smoke-alarm: 0
2015-12-19_13:13:37 smoke_living temperature: 22.9 C
2015-12-19_13:13:37 smoke_living smoke-alarm: 0
2015-12-19_13:17:07 smoke_living temperature: 22.4 C
2015-12-19_13:17:07 smoke_living smoke-alarm: 0


ZME_UZB1 (verbose 5):

Code Auswählen Erweitern


2015.12.19 13:08:46 5: SW: 06
2015.12.19 13:08:46 5: ZME_UZB1 dispatch 0004000c097105000000ff010300
2015.12.19 13:08:46 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:097105000000ff010300
2015.12.19 13:08:57 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c063105012200dd
2015.12.19 13:08:57 5: SW: 06
2015.12.19 13:08:57 5: ZME_UZB1 dispatch 0004000c063105012200dd
2015.12.19 13:08:57 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:063105012200dd
2015.12.19 13:08:58 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c0a7105000000ff01000103
2015.12.19 13:08:58 5: SW: 06
2015.12.19 13:08:58 5: ZME_UZB1 dispatch 0004000c0a7105000000ff01000103
2015.12.19 13:08:58 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:0a7105000000ff01000103
2015.12.19 13:09:57 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c097105000000ff010200
2015.12.19 13:09:57 5: SW: 06
2015.12.19 13:09:57 5: ZME_UZB1 dispatch 0004000c097105000000ff010200
2015.12.19 13:09:57 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:097105000000ff010200
2015.12.19 13:09:57 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004080c079c020c01ff0000
2015.12.19 13:09:57 5: SW: 06
2015.12.19 13:09:57 5: ZME_UZB1 dispatch 0004080c079c020c01ff0000
2015.12.19 13:09:57 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:079c020c01ff0000
2015.12.19 13:09:57 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c079c020c01ff0000
2015.12.19 13:09:57 5: SW: 06
2015.12.19 13:09:57 5: ZME_UZB1 dispatch 0004000c079c020c01ff0000
2015.12.19 13:09:57 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:079c020c01ff0000
2015.12.19 13:10:20 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c063105012200e4
2015.12.19 13:10:20 5: SW: 06
2015.12.19 13:10:20 5: ZME_UZB1 dispatch 0004000c063105012200e4
2015.12.19 13:10:20 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:063105012200e4
2015.12.19 13:10:24 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c028407
2015.12.19 13:10:24 5: SW: 06
2015.12.19 13:10:24 5: ZME_UZB1 dispatch 0004000c028407
2015.12.19 13:10:24 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:028407
2015.12.19 13:10:26 5: ZWDongle_Write 00130c028408250c (f3339ac2)
2015.12.19 13:10:26 5: SW: 010900130c028408250c4e
2015.12.19 13:10:26 5: ACK received, WaitForAck=>2 for 010900130c028408250c4e
2015.12.19 13:10:26 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 011301
2015.12.19 13:10:26 5: SW: 06
2015.12.19 13:10:26 5: ZME_UZB1 dispatch 011301
2015.12.19 13:10:26 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 00130c000003
2015.12.19 13:10:26 5: SW: 06
2015.12.19 13:10:26 5: device ack reveived, removing 010900130c028408250c4e from dongle sendstack
2015.12.19 13:10:26 5: ZME_UZB1 dispatch 00130c000003
2015.12.19 13:10:26 4: ZME_UZB1 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.19 13:10:26 4: ZME_UZB1 transmit OK for 0c
2015.12.19 13:10:27 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c028407
2015.12.19 13:10:27 5: SW: 06
2015.12.19 13:10:27 5: ZME_UZB1 dispatch 0004000c028407
2015.12.19 13:10:27 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:028407
2015.12.19 13:10:29 5: ZWDongle_Write 00130c028408250c (f3339ac2)
2015.12.19 13:10:29 5: SW: 010900130c028408250c4e
2015.12.19 13:10:29 5: ACK received, WaitForAck=>2 for 010900130c028408250c4e
2015.12.19 13:10:29 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 011301
2015.12.19 13:10:29 5: SW: 06
2015.12.19 13:10:29 5: ZME_UZB1 dispatch 011301
2015.12.19 13:10:29 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 00130c000002
2015.12.19 13:10:29 5: SW: 06
2015.12.19 13:10:29 5: device ack reveived, removing 010900130c028408250c4e from dongle sendstack
2015.12.19 13:10:29 5: ZME_UZB1 dispatch 00130c000002
2015.12.19 13:10:29 4: ZME_UZB1 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.12.19 13:10:29 4: ZME_UZB1 transmit OK for 0c
2015.12.19 13:10:44 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c063105012200ea
2015.12.19 13:10:44 5: SW: 06
2015.12.19 13:10:44 5: ZME_UZB1 dispatch 0004000c063105012200ea
2015.12.19 13:10:44 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:063105012200ea
2015.12.19 13:10:49 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c0a7105000000ff01000102
2015.12.19 13:10:49 5: SW: 06
2015.12.19 13:10:49 5: ZME_UZB1 dispatch 0004000c0a7105000000ff01000102
2015.12.19 13:10:49 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:0a7105000000ff01000102
2015.12.19 13:10:49 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004080c079c020c01000000
2015.12.19 13:10:49 5: SW: 06
2015.12.19 13:10:49 5: ZME_UZB1 dispatch 0004080c079c020c01000000
2015.12.19 13:10:49 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:079c020c01000000
2015.12.19 13:10:49 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 0004000c079c020c01000000
2015.12.19 13:10:49 5: SW: 06
2015.12.19 13:10:49 5: ZME_UZB1 dispatch 0004000c079c020c01000000
2015.12.19 13:10:49 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:079c020c01000000
2015.12.19 13:11:30 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 000400050c600d03033105014400000821
2015.12.19 13:11:30 5: SW: 06
2015.12.19 13:11:30 5: ZME_UZB1 dispatch 000400050c600d03033105014400000821
2015.12.19 13:11:30 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:0c600d03033105014400000821
2015.12.19 13:11:30 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 000400050c600d04043105014400000885
2015.12.19 13:11:30 5: SW: 06
2015.12.19 13:11:30 5: ZME_UZB1 dispatch 000400050c600d04043105014400000885
2015.12.19 13:11:30 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:0c600d04043105014400000885
2015.12.19 13:11:30 4: ZWDongle_Read ZME_UZB1: sending ACK, processing 000400050c600d05053105014400000e9f
2015.12.19 13:11:30 5: SW: 06
2015.12.19 13:11:30 5: ZME_UZB1 dispatch 000400050c600d05053105014400000e9f
2015.12.19 13:11:30 4: ZME_UZB1 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:0c600d05053105014400000e9f


Edit: für meine Auswertung habe ich wie oben beschrieben ein UserReadings definiert, das ist für mich OK.