Sendpool - Versionsgeschichte

AndreasMohr: Typos/Spelling

2018-12-31T18:58:39Z

Typos/Spelling

← Nächstältere Version		Version vom 31. Dezember 2018, 20:58 Uhr
Zeile 39:		Zeile 39:

	* 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 RFmodes gesendet werden. Bei nur einer Schnittstelle sorgt FHEM (und auch die CULfw) ohnehin dafür, dass die Kommandos sequentiell abgearbeitet werden.		* 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 RFmodes 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 bei Protokollen, die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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. Bei HomeMatic kann ~~die~~ diese Funktion durch ~~konfigurieren~~ einer [[Virtueller Controller VCCU\|VCCU]] erreicht 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 bei Protokollen, die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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. Bei HomeMatic kann diese Funktion durch Konfigurieren einer [[Virtueller Controller VCCU\|VCCU]] erreicht werden.

	== Wo Sendpool nicht sinnvoll ist ==		== Wo Sendpool nicht sinnvoll ist ==
Zeile 45:		Zeile 45:

	== Fazit ==		== 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.		Sendpool regelt nur die zeitliche Abfolge der Aussendung von Befehlen beim Einsatz mehrerer Funkschnittstellen. Es beeinflusst nicht, über welche Schnittstelle ein Befehl gesendet wird.

	== Links ==		== Links ==

Baumbuwe: Vorlage Link2CmdRef

2018-01-31T12:34:29Z

Vorlage Link2CmdRef

← Nächstältere Version		Version vom 31. Januar 2018, 14:34 Uhr
Zeile 48:		Zeile 48:

	== Links ==		== Links ==
	* ~~[http://fhem.de/commandref.html#~~CUL ~~Commandref~~ zu CUL]		* {{Link2CmdRef\|Anker=CUL}} zu CUL


	[[Kategorie:Glossary]]		[[Kategorie:Glossary]]

Soulman: /* Was Sendpool nicht macht */

2016-11-12T00:16:57Z

Was Sendpool nicht macht

← Nächstältere Version		Version vom 12. November 2016, 02:16 Uhr
Zeile 39:		Zeile 39:

	* 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 RFmodes gesendet werden. Bei nur einer Schnittstelle sorgt FHEM (und auch die CULfw) ohnehin dafür, dass die Kommandos sequentiell abgearbeitet werden.		* 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 RFmodes 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 bei Protokollen, die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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. Bei HomeMatic kann die diese Funktion durch konfigurieren einer [[VCCU]] erreicht 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 bei Protokollen, die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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. Bei HomeMatic kann die diese Funktion durch konfigurieren einer [[Virtueller Controller VCCU\|VCCU]] erreicht werden.

	== Wo Sendpool nicht sinnvoll ist ==		== Wo Sendpool nicht sinnvoll ist ==

Soulman: /* Was Sendpool nicht macht */

2016-11-12T00:15:58Z

Was Sendpool nicht macht

← Nächstältere Version		Version vom 12. November 2016, 02:15 Uhr
Zeile 39:		Zeile 39:

	* 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 RFmodes gesendet werden. Bei nur einer Schnittstelle sorgt FHEM (und auch die CULfw) ohnehin dafür, dass die Kommandos sequentiell abgearbeitet werden.		* 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 RFmodes 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 bei Protokollen, die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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.		* 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 bei Protokollen, die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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. Bei HomeMatic kann die diese Funktion durch konfigurieren einer [[VCCU]] erreicht werden.

	== Wo Sendpool nicht sinnvoll ist ==		== Wo Sendpool nicht sinnvoll ist ==

Soulman: /* Was Sendpool nicht macht */

2013-11-21T23:57:36Z

Was Sendpool nicht macht

← Nächstältere Version		Version vom 22. November 2013, 01:57 Uhr
Zeile 39:		Zeile 39:

	* 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 RFmodes gesendet werden. Bei nur einer Schnittstelle sorgt FHEM (und auch die CULfw) ohnehin dafür, dass die Kommandos sequentiell abgearbeitet werden.		* 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 RFmodes 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 ~~beo~~ Protokollen die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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.		* 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 bei Protokollen, die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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 ==		== Wo Sendpool nicht sinnvoll ist ==

Soulman: /* Was Sendpool nicht macht */

2013-11-21T23:57:13Z

Was Sendpool nicht macht

← Nächstältere Version		Version vom 22. November 2013, 01:57 Uhr
Zeile 39:		Zeile 39:

	* 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 RFmodes gesendet werden. Bei nur einer Schnittstelle sorgt FHEM (und auch die CULfw) ohnehin dafür, dass die Kommandos sequentiell abgearbeitet werden.		* 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 RFmodes 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.		* 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 beo Protokollen die Geräte nicht mit der Funkschnittstelle pairen (z.B. FS20, aber nicht HomeMatic) 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 ==		== Wo Sendpool nicht sinnvoll ist ==

Soulman: /* Was Sendpool nicht macht */

2013-08-07T09:31:10Z

Was Sendpool nicht macht

← Nächstältere Version		Version vom 7. August 2013, 11:31 Uhr
Zeile 38:		Zeile 38:
	Verschiedentlich wird angenommen, dass Sendpool (auch) andere Funktionen habe:		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.		* 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 RFmodes 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.		* 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.

Soulman: /* Einführung, Problematik */

2013-08-07T09:29:14Z

Einführung, Problematik

← Nächstältere Version		Version vom 7. August 2013, 11:29 Uhr
Zeile 12:		Zeile 12:
	Ohne das Setzen eines IODevices wird grundsätzlich die in der fhem.cfg zuletzt konfigurierte passende Schnittstelle verwendet.		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.		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 würden auf die Funkschnittstellen CUNO_EG und CUNO_OG verteilt:		Angenommen es gäbe zwei Lampen: Lamp1 und Lamp2. Diese würden auf die Funkschnittstellen CUNO_EG und CUNO_OG verteilt:

Soulman: /* Wo Sendpool nicht sinnvoll ist */

2013-08-06T18:58:15Z

Wo Sendpool nicht sinnvoll ist

← Nächstältere Version		Version vom 6. August 2013, 20:58 Uhr
Zeile 42:		Zeile 42:

	== Wo Sendpool nicht sinnvoll ist ==		== 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.		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 ==		== Fazit ==

Soulman: /* Einführung, Problematik */

2013-08-06T18:55:41Z

Einführung, Problematik

← Nächstältere Version		Version vom 6. August 2013, 20:55 Uhr
Zeile 14:		Zeile 14:
	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.		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:		Angenommen es gäbe zwei Lampen: Lamp1 und Lamp2. Diese würden auf die Funkschnittstellen CUNO_EG und CUNO_OG verteilt:
	Lamp1 und Lamp2
	Diese ~~werden~~ auf die Funkschnittstellen CUNO_EG und CUNO_OG verteilt:
	:<code>attr Lamp1 IOdev CUNO_OG</code>		:<code>attr Lamp1 IOdev CUNO_OG</code>
	:<code>attr Lamp2 IOdev CUNO_EG</code>		:<code>attr Lamp2 IOdev CUNO_EG</code>

	und anschliessend ~~werden~~ beide Lampen mittels z. B.		und anschliessend würden beide Lampen mittels z. B.
	:<code>set Lamp1,Lamp2 on</code>		:<code>set Lamp1,Lamp2 on</code>

	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.		geschaltet, dann würden 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 ==		== Funktion von Sendpool ==