Sendpool
"Sendpool regelt die zeitliche Abfolge von Befehlen über mehrere Funkschnittstellen"
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 HM oder MAX!
Denkbar ist aber auch, mehrere Funkschnittstellen des selben RF-Modes zu verwenden, um die Reichweite zu erhöhen. So könte 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 Funkabbeckung 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.
Problemtisch kann bei so 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 Funkreichweite der Schnittstellen sich überlappt.
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 Funkreichweite 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 schnttstelle1,schnttstelle2,...schnttstelleN 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 zuerst 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, das 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 Attribute IODev nicht setzt, hat sendpool keine Funktion, da dann alle Befehle über die in der fhem.cfg zuletzt definierten Schnittstelle des passenden RFtypes gesendet werden. Bei nur einer Schnittstelle sorgt FHEM (und auch die CULfw) sowieso 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 2x 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 sowieso 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.