Wall Plug Alarm

[Jackson]

Hallo,

der Wall Plug kann ja auf bestimmte Alarme in ZWave-Netzwerk reagieren.

Code Auswählen Erweitern


Parameter Nr. 34 – Reaktion auf Alarme:
Der Parameter legt Z-Wave-Alarmtypen fest, auf welche der Wall
Plug reagieren wird.
Standardwert: 63
Mögliche Werte: 0-63.
- Wert 1 - allgemeiner Alarm,
- Wert 2 - Rauchalarm,
- Wert 4 - CO-Alarm,
- Wert 8 - CO2-Alarm,
- Wert 16 - Übertemperaturalarm,
- Wert 32 - Überflutungsalarm
- Wert 63 - das Gerät reagiert auf alle Arten von Alarmframes


http://manuals.fibaro.com/content/manuals/de/FGWPx-102/FGWPx-102-DE-A-v1.00.pdf

Jetzt nehme mal an, dass hier ausschließlich das Z-Wave Netzwerk gemeint ist. Gibt es dennoch die Möglichkeit den Alarm z.B "63"  manuell auszulösen?

z.B über

Code Auswählen Erweitern

set <name> configByte <Parameternummer> <Parameterwert>

Denn gerade wenn man z.B. einen Rauchmelder im Netzwerk hat, möchte man ja vllt. die Alarmmeldung testen (ich will nur Wall Plug testen, einen Rauchmelder habe ich nicht ).

Tante Google als auch das Wiki zu ZWave habe ich bemüht aber nichts gefunden. Kann mir da jemand weiterhelfen?

[rudolfkoenig]

FHEM kann kein ALARM-Report versenden (wenn man das Senden von Roh-Nachrichten nicht dazuzaehlt). Sinnvoll finde ich so eine Funktion in FHEM auch nicht unbedingt, da man fuer ein funktionierendes System sicher sein muss, dass der Ausloeser auch richtig konfiguriert ist (Alarmtyp und -klasse, Association).

Schalten kann FHEM den Wall-Plug natuerlich auch direkt, d.h Teilfunktionalitaet kann man mit FHEM ohne Weiteres testen.

[A.Harrenberg]

Hi,

wie Rudi schon schrieb geht das so ohne weiteres nicht. Falls Du das dennoch testen möchtest müsstest Du Dir die Nachricht selber "zusammenbauen" und vom ZWave-Dongle per "get raw" verschicken. Das ist dann aber schon sehr umständlich, die Nachricht kann ich Dir auch nicht so ohne weiteres aus dem Ärmel schütteln...

Die Funktion ist ja nur sinnvoll mit entsprechenden ZWave Geräten und direkter Assoziation, dann funktioniert das auch ohne FHEM. Wenn Du keinen ZWave-Rauchmelder hast und das nur simulieren willst ist es wohl wirklich einfacher den Farbring und Ein-/Aus einfach von FHEM aus zu setzen...

Gruß,
Andreas.

[Jackson]

Hi,

wie Rudi schon schrieb geht das so ohne weiteres nicht. Falls Du das dennoch testen möchtest müsstest Du Dir die Nachricht selber "zusammenbauen" und vom ZWave-Dongle per "get raw" verschicken. Das ist dann aber schon sehr umständlich, die Nachricht kann ich Dir auch nicht so ohne weiteres aus dem Ärmel schütteln...

Die Funktion ist ja nur sinnvoll mit entsprechenden ZWave Geräten und direkter Assoziation, dann funktioniert das auch ohne FHEM. Wenn Du keinen ZWave-Rauchmelder hast und das nur simulieren willst ist es wohl wirklich einfacher den Farbring und Ein-/Aus einfach von FHEM aus zu setzen...

Gruß,
Andreas.

Ok.. danke für die Info. Das hier eher der Dongle die 'raw Data' verschicken sollte anstatt der Wall Plug... da hätte ich auch drauf kommen können.

Ich hab's jetzt mal über den Farbring simuliert - quick und dirty  .

Code Auswählen Erweitern


d1:on {

fhem("set ZWave_SWITCH_BINARY_2 configLEDRingIlluminationColourWhen61 BlueIllumination");
fhem("sleep 0.5;set ZWave_SWITCH_BINARY_2 configLEDRingIlluminationColourWhen61 RedIllumination");
fhem("sleep 1;set ZWave_SWITCH_BINARY_2 configLEDRingIlluminationColourWhen61 WhiteIllumination");

}


[gamauf]

Hallo!
@ Rudi & Andreas:
Was spricht eigentlich dagegen FHEM (ich nehme an es ist) die ALARM Klasse beizubringen?
Man könnte damit mit wenig Funkverkehr alle (entsprechend konfigurierten) Geräte gleichzeitig "tanzen" lassen!
Ich glaube schon, dass es dafür einige Anwendungsfälle gäbe.

LG
Rainer

[rudolfkoenig]

Was spricht eigentlich dagegen FHEM (ich nehme an es ist) die ALARM Klasse beizubringen?

Na dann her mit dem Patch.

[krikan]

Hallo Rainer!
Abgesehen vom Patch, verstehe ich den Sinn noch nicht:
Warum kann man dann nicht mit den vorhandenen on/off oder sonstigen Befehlen arbeiten?
Wie soll dadurch weniger Funkverkehr verursacht werden?
Oder ist das ein WallPluf-Special?
Gruß, Christian

[gamauf]

Meine Frage war auf diese Aussage bezogen:

.... Sinnvoll finde ich so eine Funktion in FHEM auch nicht unbedingt...

Es sollte keine (unhöfliche) Aufforderung sein das Einzubauen; wollt nur wissen warum ihr das nicht als sinnvoll erachtet.

Ich bin (leider) nicht tief genug in den Z-Wave Klassen und in der Perl Programmieung drinnen um so einen Pach einfach so aus dem Ärmel zu schütteln. Auch fehlt mir die Zeit dazu bzw. ist mein Bedarf dafür nicht groß genug um sie mir zu nehmen.

@Chistian:
Aus der Tatache, dass (manche) Sensoren die Option haben Alarm Broadcasts zu senden, aber keine Option den Empfänger eines solchen anzugeben und (manche) Aktoren config Parameter haben ob und wie sie auf Alarm Broadcasts reagieren, schließe ich dass ein Alarm nur einmal an alle (die zuhören) gesendet wird und die Empfänger entscheiden ob und wie sie darauf reagieren.
Es also nicht an jeden Empfänger einzeln eine Nachricht geschickt wird die mit einem acknowledge beantwortet werden muß.
Bei 10 Aktoren die auf einen Alarm-Broadcast reagieren muss ein Funktelegramm verschickt werden.
Bei 10 Empfängern via Assotiationsgruppen wären es 20 Funktelegramme.

Oder hab ich da etwas fasch verstanden?

LG
Rainer

[rudolfkoenig]

...wollt nur wissen warum ihr das nicht als sinnvoll erachtet.

Stand doch in meiner Antwort, direkt hinter dem zitierten Text.

Ich bin (leider) nicht tief genug in den Z-Wave Klassen und in der Perl Programmieung drinnen um so einen Pach einfach so aus dem Ärmel zu schütteln.

Diese Ausrede ist hier recht ueblich, aber: keiner von uns ist mit diesem Wissen auf die Welt gekommen. Das ZWave-Modul ist so gebaut, dass man in vielen Faellen ohne Programmierkenntnisse nach Zwave-Klassen-Doku-Lesen einen Patch erstellen kann.

[krikan]

Aus der Tatache, dass (manche) Sensoren die Option haben Alarm Broadcasts zu senden, aber keine Option den Empfänger eines solchen anzugeben und (manche) Aktoren config Parameter haben ob und wie sie auf Alarm Broadcasts reagieren, schließe ich dass ein Alarm nur einmal an alle (die zuhören) gesendet wird und die Empfänger entscheiden ob und wie sie darauf reagieren.
Es also nicht an jeden Empfänger einzeln eine Nachricht geschickt wird die mit einem acknowledge beantwortet werden muß.
Bei 10 Aktoren die auf einen Alarm-Broadcast reagieren muss ein Funktelegramm verschickt werden.
Bei 10 Empfängern via Assotiationsgruppen wären es 20 Funktelegramme.

Das geht über den Einbau der Class ALARM hinaus. Broadcast-Senden ist bisher nicht vorgesehen.

Bin mir sehr unsicher, ob das wie gewünscht funktionieren wird. Broadcast-Nachrichten in ZWave sind "speziell". Die Geraete müssen sie auch empfangen (=hören) können. Bei den Broadcast-Nachrichten ist aber mWn nicht sichergestellt, dass die Nachricht wegen Einschaenkungen beim Routing an alle Geraete im Netz gelangt. Automatische Wiederholungen von Broadcast-Nachrichten gibt es bspw. wegen fehlendem ACK auch nicht.

Die erhöhte Funklast bei Nutzung von singlecast-Nachrichten mit ACK halte ich für unwichtig (1% interessieren bei ZWave nicht). Die gewonnene Betriebsstabilitaet im Vergleich zu Broadcast ist für mich das entscheidende Argument.

Persönlich würde ich Broadcast nicht nutzen. Kenne auch keine andere Software, die ZWave-Nachrichten Broadcast verschickt. Aus Supportsicht auch verstaendlich: Wie will man erklaeren, warum bei Broadcast nicht alle Geraete reagieren und bei diffusen Anfragen die Ursachen finden.

[A.Harrenberg]

Hi,

nach meinem Verständnis werden BroadCast Nachrichten GAR NICHT geroutet, was in einem größeren Netz, welches auf Routing angewiesen ist, eine Katastrophe darstellt...

Und was die Anzahl der Nachrichten angeht muss ich Christian zustimmen, die paar Nachrichten machen da nicht viel aus, im Schnitt "dauert" eine Msg was in der Größenordnung um 20-40 ms, d.h. selbst bei 20 Nachrichten wäre das noch locker unter 1 Sekunde Sendezeit.

Der Fibaro ist jetzt aber auch das erste Gerät wo mir eine Empfangsmöglichkeit für eine Alarmmeldung begegnet ist, die Idee dahinter finde ich auch gar nicht mal so dumm.

Wenn ich mal ein wenig Zeit finde schaue ich mir den ALARM REPORT noch mal an.

Gruß,
Andreas.

[krikan]

nach meinem Verständnis werden BroadCast Nachrichten GAR NICHT geroutet, was in einem größeren Netz, welches auf Routing angewiesen ist, eine Katastrophe darstellt...

Hallo Andreas!
Genau der Meinung war ich bis vorgestern auch. Habe dann aber noch mal in INS* nachgelesen und bekam dann Zweifel: Wenn als Zielnode bei ZW_SendData BROADCAST angegeben ist, dann wird die Nachricht an alle zugewiesen return Routen verschickt!? Aus welcher Sicht (Controller, Endgerät) ist das unter anderem zu sehen?
Gruß, Christian

[A.Harrenberg]

Hi Christian,

bisher habe ich die INS* Documente immer aus Sicht einer NODE verstanden.

Wenn die geroutet werden müsste es aber einen Mechanismus geben das eine identische Nachricht die bereits geroutet wurde nicht noch einmal verschickt. In einem gut vernetzen System würde dann eine Node aber immer noch mehrere gleiche Nachrichten erhalten, nämlich von JEDEM seiner "Nachbarn"... Das wäre dann doch irgendwie Schneeball- oder Lawinenprinzip...

Kannst Du mir mal die Stelle nennen wo Du genau Du das gelesen hast? Dann schau ich da bei Gelegenheit auch mal drauf ob ich das auch so verstehe...

Gruß,
Andreas.

[krikan]

Bei der Internetrecherche habe ich noch das Dokument "INS10799-4 - Routing Algo.pdf" aus 2010 gefunden. Auf Anhieb habe ich zwar nichts zu Broadcast gefunden, aber einiges zum Routing.