Fibaro FGSD-002

[krikan]

Im Thread zum FGSS-001, der ja ähnlich ist, steht, dass man den Controller in Associationgroup 3 eintragen muss?
Kann das hier auch so sein?

Der Controller gehört bei dem ZwavePlus-Melder laut Doku in Associationgroup 1 (Lifeline). Selbstverständlich kannst Du den auch noch in die anderen Groups aufnehmen, wenn Du lieber die dort gesendeten Nachrichten zusätzlich haben möchtest.

Andererseits kommt ja ein Alarm an. Allerdings scheint er nur so halb ausgewertet zu werden. Ich weiß nicht so recht, was ich machen soll..

Wenn Du die Bedeutung der Aarmnachrichten kennst, kann man entsprechend darauf mit notify/DOIF reagieren. Für eine "bessere" textliche Darstellung in den Readings bräuchte man die genaue Bedeutung der Argumente in Version 5 der Class NOTIFICATION/ALARM. Die hat aber noch niemand verraten/gefunden oder kennst Du Infos?

[Carsten]

Hallo,

Wenn Du die Bedeutung der Aarmnachrichten kennst, kann man entsprechend darauf mit notify/DOIF reagieren. Für eine "bessere" textliche Darstellung in den Readings bräuchte man die genaue Bedeutung der Argumente in Version 5 der Class NOTIFICATION/ALARM. Die hat aber noch niemand verraten/gefunden oder kennst Du Infos?

Es wird dich sicher nicht überraschen zu hören, dass ich auch nicht mehr dazu weiß.  Sind die Classes geheim? Das war mir nicht bewußt.

Ich könnte auf das Alarm-Reading reagieren, aber meine Sorge ist, dass FHEM da besser wird, ohne dass ich es merke.
Wenn ich jetzt auf "alarm: Smoke: detected, Unknown Location, arg 00" oder auch nur auf "alarm: Smoke: detected" checke und morgen gibt es ein Update, dass das Protokoll besser versteht und dadurch ändert sich der Text, dann merke ich das erst, wenn der Rauchmelder das nächste Mal auslöst ( und das notify nicht ).
Wenn eine Steckdose nicht mehr funktioniert, merke ich das irgendwann wenn ich sie schalten will und kann mich auf die Suche machen, aber bei einem Rauchmelder ist das schon etwas problematischer. 
Ein Reading gibt es für die Rawmessage ja auch nicht, oder kann man die Internal-Werte auch als Reading ansprechen?

[krikan]

Sind die Classes geheim?

Ja. Man bekommt genaue Infos nur gegen viel Geld und NDA; geht also nicht und wäre auch total langweilig. Also sind wir auf Analyse und öffentlich zugängliche Infos angewiesen.

Ich könnte auf das Alarm-Reading reagieren, aber meine Sorge ist, dass FHEM da besser wird, ohne dass ich es merke.

"besser wird" hoffe und weiß ich, "ohne dass" liegt an Dir. 

Ein Reading gibt es für die Rawmessage ja auch nicht, oder kann man die Internal-Werte auch als Reading ansprechen?

Wüsste nicht wie.

[Carsten]

Ja. Man bekommt genaue Infos nur gegen viel Geld und NDA; geht also nicht und wäre auch total langweilig.

Ich dachte der Witz an Z-Wave wäre, dass das Protokoll weitgehend offen ist, damit sich alle Teilnehmer verstehen

"ohne dass" liegt an Dir. 

Ich kann ja nicht nach jedem Update die Bude anzünden. 

[krikan]

Ich dachte der Witz an Z-Wave wäre, dass das Protokoll weitgehend offen ist, damit sich alle Teilnehmer verstehen

Jetzt ist die Frage, wie man offen definiert und welche Teile wie offen sind.
Das SDK und die Infos dazu kann jeder kaufen und kompatible Geräte herstellen. So wie es die Hersteller wohl machen. Aber verraten dürfen die vom SDK eben fast nichts.

Ich kann ja nicht nach jedem Update die Bude anzünden.

Brauchst Du nicht.
Du könntest nach einem Update deinen gespeicherten raw-Code per {Dispatch()} in der Kommandozeile auswerten lassen und schauen, wie die Readings/Events dann aussehen. Bsp hatten wir gerade hier: http://forum.fhem.de/index.php/topic,49165.msg412085.html#msg412085 ff.
Bessere Idee habe ich nicht.

[rudolfkoenig]

Ein Reading gibt es für die Rawmessage ja auch nicht, oder kann man die Internal-Werte auch als Reading ansprechen?

Aud Internal Werte kann man natuerlich mit $defs{NAME}{InternalName} in Perl Code zugreifen (siehe {}), wuesste aber nicht, wie das in diesem Fall helfen soll. Ich habe ein neues ZWave Attribut fuer Paranoiker eingefuehrt:

eventForRaw
Generate an an additional event for the RAW message.  Can be used if someone fears that critical notifies wont work, if FHEM changes the event text after an update.

[Carsten]

Ich habe ein neues ZWave Attribut fuer Paranoiker eingefuehrt:

Ich weiß noch nicht, ob ich mich geehrt oder beleidigt fühlen soll, aber vielen Dank! 

Ich werde testen

[Carsten]

Hallo nochmal,

ich weiß nicht, ob ich beim Herunterladen einen Fehler mache, oder die Datei einen Fehler hat. In Zeile 3801 ( bzw. 3789, wenn man die Datei im Repo-Browser anschaut ), steht folgendes:

Code Auswählen Erweitern

  my ($baseHash, $baseId, $ep) = ("",$id,"");
               056008 00  0200
  if($arg =~ /^..6006(..)(.*)/) { # MULTI_CHANNEL CMD_ENCAP, V1, Forum #36126

Das knallt aber beim Laden. Ich weiß auch nicht sog genau, was das da machen soll. Habs auskommentiert, dann läuft ( soweit ich das bisher sehen kann ) wieder alles sauber.

[rudolfkoenig]

Danke fuer den Hinweis, ist trotz Test und svn diff irgendwie reingerutscht. Habs entfernt und eingecheckt.

[Carsten]

Danke!
Mit dem Rawmsg-Reading komme ich klar, denke ich.
Hab mal ausprobiert. Die Events sind auf beiden Rauchmeldern identisch:

Code Auswählen Erweitern


Rauchalarm: 097105000000ff010200
Rauch-Ende: 0a7105000000ff01000102
Probealarm: 097105000000ff010300
Probe-Ende: 0a7105000000ff01000103
Coveralarm: 097105000000ff070300
Cover-Ende: 0a7105000000ff07000103


Soweit glaube ich die Meldungen nun verstanden zu haben:

Code Auswählen Erweitern


Byte 01 (09) Payload-Länge in Byte
Byte 02 (71) Command-Class ( 0x71 = Alarm )
Byte 03 (05) Command-Class-Version
Byte 04 (00) ??
Byte 05 (00) ??
Byte 06 (00) ??
Byte 07 (ff) ??
Byte 08 (01) Alarm-Type ( 0x01 = Smoke )
Byte 09 (02) Event-Type ( 0x02 = echter Alarm )
Byte 10 (00) ?? (scheinbar 00 bei Alarm und 01 bei Entwarnung)
Byte 11 (--) scheinbar letzter Event-Type bei Entwarnung


Alarmtypes ( lt. http://razberry.z-wave.me/docs/zwayDev.pdf S. 66 ):

Code Auswählen Erweitern


0x01: Smoke
0x02: CO
0x03: CO2
0x04: Heat
0x05: Water
0x06: Access Control
0x07: Burglar
0x08: Power Management
0x09: System
0x0A: Emergency
0x0B: Clock


Bekannte Event-Types für den FGSD-002 ( lt. http://www.siio.de/sicherheitalarm/razberry-und-der-fibaro-rauchmelder-eine-kleine-odyssee/ ).

Code Auswählen Erweitern


In Klammern zugehöriger Alarmtype
(0x01)0x02 Rauch
(0x01)0x03 Probealarm
(0x04)0x02 Temperature Treshold überschritten
(0x07)0x03 Abdeckung
(0x08)0x0A Batterie schwach
(0x09)0x01 Fehlfunktion

0x00 scheint kein Event / Entwarnung zu bedeuten


Batterie-, Fehlfunktion- und Temperaturalam habe ich nicht getestet. Will den Melder nicht kochen. 

[rudolfkoenig]

Siehe auch fhem/FHEM/10_ZWave.pm, ZWave_alarmParse().
Patches sind willkommen.

[Carsten]

Sorry,
dann hab ich offenbar das Problem nicht verstanden.

[mike3436]

Hallo,
ich habe mir auch mal 3 FGSD-002 zugelegt und ZWAVE über einen ZME_UZB1 am Raspberry installiert.
Die Installation und Erkennung ging auch super einfach - gute Arbeit Rudolf!
Der Stick hat ein bischen rumgezickt, aber nach dem ich ein USB Verlängerungskabel dazwischen gesetzt habe, lief der dann problemlos.

Jetzt läuft das ganze eine Woche, und ich habe mit erschrecken festgestellt, das der Batteriestatus fast täglich abfällt.
Hier ein Auszug aus dem log

Code Auswählen Erweitern

2016-02-20_14:46:55 ZWave_Rauchmelder_Buero battery: 90 %
2016-02-21_02:50:53 ZWave_Rauchmelder_Buero battery: 80 %
2016-02-21_20:57:40 ZWave_Rauchmelder_Buero battery: 75 %
2016-02-23_09:11:01 ZWave_Rauchmelder_Buero battery: 70 %

2016-02-20_07:50:46 ZWave_Rauchmelder_Schlafzimmer battery: 90 %
2016-02-21_01:52:19 ZWave_Rauchmelder_Schlafzimmer battery: 80 %
2016-02-22_01:54:58 ZWave_Rauchmelder_Schlafzimmer battery: 75 %
2016-02-25_14:01:54 ZWave_Rauchmelder_Schlafzimmer battery: 65 %


Ansonsten stehen in den Logs immer so 10-15 Telegramme pro Tag, meist mit Wakeup oder Temperaturänderung

Code Auswählen Erweitern


2016-02-22_21:06:36 ZWave_Rauchmelder_Buero wakeup: notification
2016-02-22_21:07:36 ZWave_Rauchmelder_Buero UNPARSED: MANUFACTURER_PROPRIETARY 1b91010fff0400040a07d0010600000a001500150015001500150015
2016-02-22_23:35:16 ZWave_Rauchmelder_Buero temperature: 21.5 C

Kennt jemand das Problem, oder habe ich nur schlappe Batterien geliefert bekommen!?

[krikan]

2016-02-22_21:07:36 ZWave_Rauchmelder_Buero UNPARSED: MANUFACTURER_PROPRIETARY 1b91010fff0400040a07d0010600000a001500150015001500150015

Das ist eine hersteller- und auch produktspezifische Nachricht, die nicht im offiziellen ZWave-Standard enthalten ist. Du müsstest herausfinden/analysieren, was die Nachrichten bedeuten. Wenn der Nachrichtenaufbau und Bedeutung geklärt ist, könnte man das in FHEM einbauen.

[Carsten]

Hi Mike,

ich hab bisher zwei von den Rauchmeldern im Betrieb. Beide seit ca. zwei Wochen.

Der eine (Nr.1) ist bei 100%, der andere (Nr.2) bei 60%, aber seit einer Woche unverändert.

Nr. 1 habe ich im November bei einem deutschen Marketplace-Händler gekauft, aber erst vor zwei Wochen ausgepackt.  Nr. 2 kam über Marketplace aus Frankreich.
Nr. 1 ist Manufactured OCT 15, Nr. 2 JAN 15.

Ich hab mehrere Vermutungen, warum Nr. 2 weiter runter ist:

• er ( und damit die Batterie ) ist 9 Monate älter
• er musste am Anfang für einige Funktionstests herhalten, die natürlich auch Strom brauchten
• Ich hatte bei Inbetriebnahme noch eine älter FHEM-Version. Dadurch wurde FHEM in 2 zusäzliche Associatongroups aufgenommen. ( und als Garagensensor erkannt) Evtl. musste er deshalb mehr arbeiten
• eine Kombination von allem

Auf 60 % ist Nr. 2 innerhalb von 2-3 Tagen gefallen. Seitdem hält er sich da. Evtl. war die Kapazität von Anfang an auf 60% runter, aber der Melder brauchte etwas, um das korrekt zu messen. Ich hab die Batterie zwischendurch mal raus gehabt, danach wurde kurzzeitig wieder ein höherer Stand gemeldet.

Fürs erste gehe ich jedenfalls davon aus, dass die Batterie schuld ist.