Sendpool

Sendpool ist ein Attribut der Devices (Interfaces) CUL / CUR / CUNO, das die zeitliche Abfolge von Befehlen über mehrere Funkschnittstellen regelt.

Einführung, Problematik

FHEM unterstützt mehrere Funkschnittstellen, z.b. mehrere CULs oder mehrere CUNOs. Mehrere Schnittstellen können dazu dienen, mehrere Funkprotokolle abzudecken, die nicht zugleich auf einer Schnittstelle aktiviert werden können, also z. B. einen CUL zum Betrieb mit SlowRF Geräten wie FS20 oder FHT, und eine weiteres CUL zum Betrieb mit HomeMatic oder MAX!

Denkbar ist aber auch, mehrere Funkschnittstellen des selben RF-Modes zu verwenden, um die Reichweite zu erhöhen. So könnte z. B. ein CUNO im Keller (zur Abdeckung der unteren Etagen eines Hauses) und ein weiterer CUNO im Obergeschoss (für die oberen Etagen) installiert sein, wenn ein CUNO für die Funkabdeckung eines ganzen Hauses mangels Reichweite nicht genügt.

Mittels des Deviceattributes "IODev" wird für jeden Aktor einzeln bestimmt, über welche Schnittstelle ein Befehl für den Aktor gesendet werden soll. Im Beispiel oben muss also ermittelt werden, von welchem CUNO eine Aktor mit guter Leistung erreichbar ist, dieser wird dem Aktor dann per z. B.:

attr Lamp1 IOdev CUNO_OG

zugeordnet.

Ohne das Setzen eines IODevices wird grundsätzlich die in der fhem.cfg zuletzt konfigurierte passende Schnittstelle verwendet.

Problematisch kann bei einer solchen Konfiguration mit verteilten IODevices aber sein, dass Befehle an Aktoren die durch verschiedene Funkschnittstellen gesendet werden zugleich abgesetzt werden und sich so gegenseitig stören, wenn die Funkreichweiten der Schnittstellen sich überlappen.

Angenommen es gäbe zwei Lampen:

lamp1 und lamp2

Diese werden auf die Funkschnittstellen CUNO_EG und CUNO_OG verteilt:

attr Lamp1 IOdev CUNO_OG

attr Lamp2 IOdev CUNO_EG

und anschliessend werden beide Lampen mittels z. B.

set Lamp1,Lamp2 on

geschaltet, dann werden sowohl CUNO_EG als auch CUNO_OG den jeweiligen Befehl für ihre Lampe nahezu zugleich absenden. Dies ist kein Problem, solange die Funkreichweite der CUNOs tatsächlich nicht bis zum anderen Aktor reicht. In der Praxis gibt es aber mehr oder weniger grosse Bereiche, in denen die Sendestärke beider CUNOs ähnlich gross ist, in denen die Funkreichweiten der Schnittstellen sich also überlappen. Hier würden sich die beiden Befehle gegenseitig überlagern und stören und so einen sauberen Empfang im Aktor erschweren oder gar unmöglich machen. Die beiden Lampen des Beispiels könnten dann nicht mehr zugleich geschaltet werden.

Funktion von Sendpool

In solchen Fällen können die fraglichen Schnittstellen durch "sendpool" in eine zeitliche Abfolge gebracht werden. Mittels des Attributes

sendpool schnittstelle1,schnittstelle2,...schnittstelleN

kann festgelegt werden, in welcher Reihenfolge die Befehle an die Schnittstellen gesendet werden, um eine gleichzeitige Aussendung zu vermeiden.

Im konkreten Beispiel könnte also definiert werden:

attr CUNO_OG sendpool CUNO_OG,CUNO_EG

attr CUNO_EG sendpool CUNO_OG,CUNO_EG

Dadurch wird zum Einen festgelegt, welche Schnittstellen einem Sendpool angehören und zum Anderen, in welcher Reihenfolge die Funkbefehle gesendet werden. Im konkreten Beispiel wird zunächst der Befehl an CUNO_OG und mit minimaler Verzögerung erst an CUNO_EG übermittelt. Dazu muss die Reihenfolge in allen Sendpoolattributen eines Sendpools gleich sein.

Was Sendpool nicht macht

Verschiedentlich wird angenommen, dass Sendpool (auch) andere Funktionen habe:

• Es wird vermutet, dass Sendpool dazu führe, dass ein Befehl über alle Funkschnittstellen (zugleich) abgesetzt werde, man also eine Zuordnung von Aktoren mittels IODev sparen könne. Dies ist nicht der Fall. Im Gegenteil: wenn man das Attribut IODev nicht setzt, hat Sendpool keine Funktion, da dann alle Befehle über die in der fhem.cfg zuletzt definierte Schnittstelle des passenden RFtyps gesendet werden. Bei nur einer Schnittstelle sorgt FHEM (und auch die CULfw) ohnehin dafür, dass die Kommandos sequentiell abgearbeitet werden.
• Ferner wird angenommen, dass Sendpool dafür sorge, dass bei Ausfall einer Funkschnittstelle ein Befehl der per IODev über die ausgefallene Schnittstelle abgesetzt würde, nun automatisch über eine andere Schnittstelle des Sendpools abgesetzt wird. Auch das ist nicht der Fall. Wenn eine Schnittstelle ausfällt, können Befehle zu daran per IODev gebundenen Aktoren nicht mehr abgesetzt werden. Es ist aber möglich, ein Device zweimal anzulegen mit an sich identischen Daten aber abweichenden Namen und abweichenden IODevs und an diese zugleich zu senden. Dann würde der Befehl auch bei Ausfall einer Schnittstelle noch über die andere übermittelt, gleichzeitig wird aber der Funkverkehr verdoppelt.

Wo Sendpool nicht sinnvoll ist

Sendpool löst vor allem das Problem, dass Schnittstellen gleichen Typs, die gleich angebunden sind, eine ähnliche Reaktionszeit haben und daher übermittelte Befehle in ähnlichen Zeiträumen absetzen. Es ist daher fraglich, ob beim gemischten Einsatz von CUL und CUNO (also USB-Anbindung und Netzwerkanbindung) ein Sendpool gebildet werden muss. In jedem Fall unnötig ist ein Sendpool bei Nutzung eines RFR-CUL, da die Kommunikation mit dem RFR ohnehin nur in SlowRF Sendepausen erfolgt und sich dadurch von alleine eine zeitliche Entzerrung ergibt. Sendpool ist auch nicht erforderlich, wenn sich verschiedene Schnittstellen in der Funkreichweite garantiert nicht überlappen.

Fazit

Sendpool regelt nur die zeitliche Abfolge der Aussendung von Befehlen beim Einsatz mehrerer Funkschnittstellen. Es beeinflusst nicht, über welche Schnittstelle eine Befehl gesendet wird.

Links

• Commandref zu CUL