[beantwortet] Assoziationen bei ZWave+-Geraeten

[MadMax-FHEM]

Den Controller würde ich nur mir Assogroup 1 assoziieren. Die anderen Assoziationen mit Group 4 und 5 sind in FHEM eigentlich überflüssig und erzeugen unnötige Funklast.

Hallo,

sorry wenn ich mich hier kurz dazwischen hänge...

Ich habe die FIBARO System FGSD002 Smoke Sensor Rauchmelder und die wurden auch so angelegt, also in assocGroup_1, _4 und _5 steht mein zwave_usb.

Ist das bei denen auch unnötig?
Sollte ich das löschen?

Code Auswählen Erweitern

set NAME_RAUCHMELDER associationDel 4 1

Code Auswählen Erweitern

set NAME_RAUCHMELDER associationDel 5 1

Code Auswählen Erweitern

nodeIdHex 01
Sagt doch, dass der zwave_usb die 1 ist!?

Danke und noch mal sorry, Joachim

[krikan]

sorry wenn ich mich hier kurz dazwischen hänge...

Habe das in ein neues Thema ausgelagert.

Ich habe die FIBARO System FGSD002 Smoke Sensor Rauchmelder und die wurden auch so angelegt, also in assocGroup_1, _4 und _5 steht mein zwave_usb.

Ist das bei denen auch unnötig?

Grundsaetzlich genuegt bei den ZWave+-Geraeten die Assoziierung des Controllers mit Assogroup 1 "lifeline". Durch Assoziierung des Controllers mit weiteren Groups werden regelmaeßig die gleichen Infos, die über Assogroup 1 gemeldet werden, zusaetzlich über eine andere Command Class noch einmal gemeldet. Es wird damit eine höhere und mMn unnötige Funklast mit Gefahr von Kollisionen erzeugt. (Bin Verfechter von möglichst wenig Nachrichten!)

Mir ist bisher kein ZWave+-Geraet untergekommen, bei dem Infos von Assogroups >1 nicht auch über 1 gemeldet wurden. Ausschließen kann ich es aber nicht und für den FGSD002 ist es mir unbekannt.

Warum assoziiert FHEM automatisch mit Assogroup >1 ?
Wir übernehmen für die Assoziierung die Infos aus den XMLs von openzwave. openzwave hat -mein letzter Kenntnisstand- die Class ALARM/NOTIFICATION noch nicht in den höheren Versionen eingebaut (FHEM wohl). Assogroup 1 nutzt diese höheren Versionen regelmaeßig. Um dennoch alle Infos verarbeiten zu können, assoziiert openzwave die höheren Groups. Die höheren Groups liefern die Infos immer mit "aelteren" und "einfacheren" Command Classes, die openzwave auf jeden Fall versteht. Für FHEM ist das eigentlich unnötig, aber ich bin zeitlich nicht in der Lage aus den XMLs die ZWave+-Geraete herauszufiltern und in diesen XMLs die Assoziierung mit Assogoups>1  herauszunehmen. Man könnte das zwar auch über eine Erkennung durch FHEM von ZWave+-Geraeten lösen, aber ich hadere noch, ob das insgesamt sinnvoll ist.

Code Auswählen Erweitern

set NAME_RAUCHMELDER associationDel 4 1

Code Auswählen Erweitern

set NAME_RAUCHMELDER associationDel 5 1

Code Auswählen Erweitern

nodeIdHex 01
Sagt doch, dass der zwave_usb die 1 ist!?

Die associationDel-Befehle sind richtig, wenn der Controller die dezimale NodeId 1 hat. Zumeist hat der Controller die Id 1, aber nicht immer..

Bei den ZWave+-Devices würde ich zudem das Attribut extendedAlarmReadings immer auf 1 setzen. Dann hat man für die verschiedenen Alarm-Arten separate Readings.

Gruß, Christian

[MadMax-FHEM]

Hallo Christian,

vielen Dank x2!

Hab mich schon gewundert warum der Thread plötzlich so kurz ist...
...aber richtig gehörte ja auch da nicht wirklich rein aber thematisch ähnliche/gleiche Frage daher hab ich mich mal dran/zwischen rein geworfen...

Da ich auch kein Freund von unnötigen Telegrammen/Funk bin werde ich das mal ausprobieren...

Gruß, Joachim