Maximal nutzbare SlowRF Geräte: Unterschied zwischen den Versionen

Aktuelle Version vom 28. Dezember 2017, 16:44 Uhr

Maximal nutzbare Geräte im FS20 / FHT System mit FHEM

Die Anzahl der mit FHEM per steuerbaren Geräte ist softwareseitig im Prinzip unbegrenzt.

Es ergeben sich jedoch insbesondere in Funksystemen deutliche Einschränkungen. So ist die Anzahl der praktisch nutzbaren Geräte vor allem durch die 1% Regel eingeschränkt. Theoretisch ist auch der Adressraum eine Beschränkung, da z. B. FS20 256 Adressen für Geräte kennt; durch Nutzung von Dummy-Geräten wird der Adressraum zudem weiter belastet. Sofern (wie z. B. bei FHEM) mehrere Hauscodes frei verwendet werden können (in Abhängigkeit der verwendeten Funkschnittstelle), lässt sich diese Einschränkung allerdings umgehen.

grundsätzliche Überlegungen

Wegen der 1%_Regel dürfen Geräte im FS20 / FHT und ähnlichen Funksystemen basierend auf dem 868 MHz Bereich nur 1% einer Stunde mit Funkbefehlen belegt werden, dies entspricht nur 0,6 Minuten (36 Sekunden).

Während die einzelnen Devices wie FS20 Aktoren (mit Ausnahme von PIR-Sensoren) oder FHT80bs diese Zeiten kaum erreichen, sind die Zentralen wie CUN, CUL oder FHZ stärker betroffen.

Besonders problematisch ist der Einsatz von FHT80b Raumreglern:

1. ist das FHT/FS20 Funkprotokoll ("SlowRF") ist Gegensatz zum HomeMatic Protokoll relativ langsam, sodass ein Befehl signifikante Sendezeit verbraucht.

2. ist die FHT-Kommunikation mit der Zentrale bidirektional und

3. sendet ein FHT80b alle 15 Minuten Statuswerte an eine gepairte Zentrale.

Die Zentrale wird also quasi von aussen gezwungen, Daten an die bekannten (gepairten) FHT80bs zu senden, selbst wenn es eigentlich nichts mitzuteilen gibt. Die dadurch entstehende Funklast ist nicht unerheblich. Rechnerisch verbraucht die Kommunikation mit einer FHT80b ca. 2,1 Sekunden Sendezeit auf Seiten der Zentrale, also etwa 6% der je Stunde zur Verfügung stehenden Sendezeit. Daraus ergibt sich eine Obergrenze von 17 einsetzbaren FHT80bs je Zentrale. In realen Umgebungen wird die Kommunikation aber nicht fehlerfrei ablaufen, es wird also Wiederholungen geben. Ebenso belasten auch die ausgesendeten Telegramme an FS20 Aktoren und Temperaturänderungen an FHT80bs den Funkkanal zusätzlich. Faktisch sind daher circa ein Dutzend FHT80bs sinnvoll einsetzbar.

detailierte Betrachtung

Die bidirektionale Kommunikation kann mit FHEM bei Einsatz eines CUL/CUN(O) mitprotokolliert werden ("set CUL raw X61" vorher nicht vergessen). Hier ein beispielhafter Mitschnitt:

2008-09-28 13:04:18 FHT wz actuator: 0% 
2008-09-28 13:04:18 FHT wz actuator: 0% 
2008-09-28 13:04:18 FHT wz start-xmit: 17 
2008-09-28 13:04:18 FHT wz FHZ:start-xmit: 17 
2008-09-28 13:04:19 FHT wz measured-low: 21.9 (Celsius) 
2008-09-28 13:04:19 FHT wz FHZ:measured-low: 21.9 (Celsius) 
2008-09-28 13:04:19 FHT wz measured-high: 0 
2008-09-28 13:04:19 FHT wz FHZ:measured-high: 0 
2008-09-28 13:04:19 FHT wz ack: 0 
2008-09-28 13:04:20 FHT wz FHZ:ack: 0 
2008-09-28 13:04:20 FHT wz warnings: none 
2008-09-28 13:04:20 FHT wz FHZ:warnings: none 
2008-09-28 13:04:20 FHT wz ack: 0 
2008-09-28 13:04:20 FHT wz FHZ:ack: 0 
2008-09-28 13:04:20 FHT wz end-xmit: 0 
2008-09-28 13:04:20 FHT wz FHZ:end-xmit: 0

Jede Zeile steht für ein Telegramm (und nicht für 3, wie beim FS20).

FHZ:xxx Telegramme wurden von dem FHZ (oder CUN/CUL) gesendet, die anderen vom FHT.

FHEM fasst measured-low und measured-high zu measured-temp zusammen, es werden also im normalen log (telnet: inform timer) 2 Zeilen weniger gemeldet.

17 ist der FHT-ID des protokollierten FHZ. Wenn das FHZ nicht mit dem richtigen FHT-ID antwortet, dann geht die Kommunikation nicht weiter.

Wenn das FHT nicht an dem FHZ angemeldet ist (d.h. das FHT hat nicht die FHT-ID des FHZ gespeichert), werden keine Temperaturdaten uebermittelt. Set Prog:Cent:N/A setzt die FHT-ID des FHT80 auf 100, dann sollte jede FHZ auf "start-xmit" antworten, und das FHT merkt den ersten. Noch besser dem FHT via FHEM was zu senden, dann muss man nicht auf die nächste Temperaturmeldung (bis zu 15 Minuten) warten. Mehr dazu auch hier: FHT mit RFR CUL pairen Falls die Gegenseite nicht wie erwartet antwortet, dann wird nach einem Timeout das Telegramm einmal wiederholt. Falls immer noch keine korrekte Antwort vorliegt, dann wird nach 115+x Sekunden der ganze Vorgang einmal wiederholt.

Jedes Telegramm ist bei 1000Baud ca 75ms lang. Die Temperatur wird pro FHT 4-mal die Stunde gemeldet: 4*7*75ms = 2.1s FHZ-Sendezeit pro FHT und Stunde, und da man wg. 1% 36 Sekunden hat, entspricht das 5.833% pro FHT. Wenn das 1% erschoepft ist, dann versucht das CUL zu antworten, aber es wird bei jedem Versuch LOVF ausgegeben.

Falls die Kommunikation nie abbricht (also fehlerfrei stattfinden kann), und sonst auch nichts gesendet wird, kann man mit einem FHZ 17 FHTs versorgen. Faktisch wird die Menge der einsetzbaren FHTs wesentlich geringer sein. ELV geht als Hersteller offenbar von maximal 10-14 FHTs aus, so unterstützt das Wärmerelais FHT8w maximal 10 Räume, während es in der Bedienungsanleitung der FHZ1000 Standalone Zentrale heisst, es könnten bis zu 15 Räume gesteuert werden. Da die FHZ1000 einen Raum selbst bedient, ist die Kommunikation mit weiteren 14 FHT80b Geräten notwendig.

mögliche Abhilfe

Denkbar ist der Einsatz mehrerer Zentralen, also z. B. mittels Anschluss mehrerer CULs/CUNs oder Nutzung von RFR CULs. Somit könnten Geräte auf die Zentralen verteilt werden, um die jeweilige Last zu senken.

Allerdings kann durchaus diskutiert werden, ob dies überhaupt zulässig wäre: Wenn man den FHEM-Hostrechner und angeschlossene FHZ Zentralen als ein System auffasst, könnte das Gesamtsystem rechtlich der 1% Regel unterworfen sein, auch wenn es technisch möglich ist, 2% zu senden.

Vor allem aber steigt die Wahrscheinlichkeit, dass FS20 oder FHT Nachrichten wegen Kanalbelegung nicht mehr erfolgreich übermittelt werden deutlich an. Insbesondere bei FS20 Aktoren, die in der Regel den jeweiligen Befehl unmittelbar ausführen sollen, kann das System recht unzuverlässig werden.

Sendefehler entstehen je nach Konfiguration sogar zwangsweise: Da wegen dem 115+x (x = 0.5sec * Low-Nibble der FHT-ID) die FHT-Sendeintervalle unterschiedlich sind, "kreuzen" sich zwei FHTs mit der FHT-ID 10 (115s Intervall) und FHT-ID 12 (116s Intervall) alle 115*115sec = 13225sec = 3.67h zwangsweise. Bei mehreren FHTs steigen die Kreuzungsmöglichkeiten.

Da die Zentrale nach der FHT Meldung sofort mit FHT:can-xmit antworten muss, steigt zusätzlich das Risiko, das FHTs mit dem übermitteln der Daten abbrechen, nur weil die FHZ Rückmeldung gestört wurde. D.H der Wiederholungsverkehr steigt vermutlich überproportional an.

Mehrere an einen FHEM Hostrechner angeschlossen Zentralen haben zur besseren Ausleuchtung durchaus ihre Berechtigung, zur Erhöhung der maximal nutzbaren Geräte sind sie aber nur bedingt geeignet, wenn nicht sogar unzulässig.

Todo: hier die irgendwo aufgeführte FHEM-Config-Option (IIRC eine Liste von zu berücksichtigenden Devicenamen) referenzieren/erwähnen, die eine Serialisierung der Aktivitäten mehrerer CUL-Sender durchführt und somit Kollisionsprobleme reduzieren kann

Links

Kommunikationsprobleme_mit_FHT

@@ Zeile 1: / Zeile 1: @@
-Maximal nutzbare Geräte im FS20 / FHT System mit FHEM
+Maximal nutzbare Geräte im [[:Kategorie:FS20_Components|FS20]] / [[:Kategorie:FHT_Components|FHT]] System mit FHEM
 Die Anzahl der mit FHEM per steuerbaren Geräte ist softwareseitig im Prinzip unbegrenzt.
-Es ergeben sich jedoch insbesondere in Funksystemen deutliche Einschränkungen. So ist die Anzahl der praktisch nutzbaren Geräte vor allem durch die [[1% Regel]] eingeschränkt. Theoretisch ist auch der Adressraum eine Beschränkung, da z.&nbsp;B. FS20 256 Adressen für Geräte kennt; durch Nutzung von Dummy-Geräten wird der Adressraum zudem weiter belastet. Soweit wie bei FHEM mehrere Hauscodes frei verwendet werden können (in Abhängigkeit der verwendeten Funkschnittstelle), lässt sich diese Einschränkung allerdings umgehen.
+Es ergeben sich jedoch insbesondere in Funksystemen deutliche Einschränkungen. So ist die Anzahl der praktisch nutzbaren Geräte vor allem durch die [[1% Regel]] eingeschränkt. Theoretisch ist auch der Adressraum eine Beschränkung, da z.&nbsp;B. FS20 256 Adressen für Geräte kennt; durch Nutzung von Dummy-Geräten wird der Adressraum zudem weiter belastet. Sofern (wie z.&nbsp;B. bei FHEM) mehrere Hauscodes frei verwendet werden können (in Abhängigkeit der verwendeten Funkschnittstelle), lässt sich diese Einschränkung allerdings umgehen.
-==grundsätzliche Überlegungen==
+== grundsätzliche Überlegungen ==
-Wegen der 1% Regel dürfen Geräte im FS20 / FHT und ähnlichen Funksystemen basierend auf dem 868 MHz Bereich nur 1% einer Stunde mit Funkbefehlen belegt werden, dies entspricht nur 0,6 Minuten (36 Sekunden).
+Wegen der [[1%_Regel]] dürfen Geräte im FS20 / FHT und ähnlichen Funksystemen basierend auf dem 868 MHz Bereich nur 1% einer Stunde mit Funkbefehlen belegt werden, dies entspricht nur 0,6 Minuten (36 Sekunden).
-Wärend die einzelnen Devices wie FS20 Aktoren (mit Ausnahme von PIR-Sensoren) oder FHT80bs diese Zeiten kaum erreichen, sind die Zentralen wie CUN, CUL oder FHZ stärker betroffen.
+Während die einzelnen Devices wie FS20 Aktoren (mit Ausnahme von PIR-Sensoren) oder [[FHT80b]]s diese Zeiten kaum erreichen, sind die Zentralen wie [[CUN]], [[CUL]] oder [[FHZ 1000|FHZ]] stärker betroffen.
 Besonders problematisch ist der Einsatz von FHT80b Raumreglern:
-. ist das FHT/FS20 Funkprotokoll ("SlowRF") ist Gegensatz zum HomeMatic Protokoll relativ langsam, sodass eine Befehl siginifikante Sendezeit verbraucht.
+. ist das FHT/FS20 Funkprotokoll ("[[SlowRF]]") ist Gegensatz zum [[HomeMatic]] Protokoll relativ langsam, sodass ein Befehl signifikante Sendezeit verbraucht.
 . ist die FHT-Kommunikation mit der Zentrale bidirektional und
-. sendet ein FHT80b alle 15 Minuten Statuswerte an eine gepairte Zentrale.
+. sendet ein [[FHT80b]] alle 15 Minuten Statuswerte an eine gepairte Zentrale.
-Die Zentrale wird also quasi von aussen gezwungen, Daten an die bekannten (gepairten) FHT80bs zu senden, selbst wenn es eigentlich nichts mitzuteilen gibt. Die dadurch entstehende Funklast ist nicht unerheblich. Rechnerisch verbraucht die Kommunikation mit eine FHT80b ca. 2,1 Sekunden Sendezeit auf Seiten der Zentrale, also etwa 6% der je Stunde zur Verfügung stehenden Sendezeit. Daraus ergibt sich eine Obergrenze von 17 einsetzbaren FHT80bs je Zentrale. In realen Umgebungen wird die Kommunikation aber nicht fehlerfrei ablaufen, es wird also Wiederholungen geben. Ebenso belasten auch die ausgesendeten Telegramme an FS20 Aktoren und Temperaturänderungen an FHT80bs den Funkkanal zusätzlich. Faktisch sind daher circa ein Dutzend FHT80bs sinnvoll einsetzbar.
+Die Zentrale wird also quasi von aussen gezwungen, Daten an die bekannten (gepairten) FHT80bs zu senden, selbst wenn es eigentlich nichts mitzuteilen gibt. Die dadurch entstehende Funklast ist nicht unerheblich. Rechnerisch verbraucht die Kommunikation mit einer FHT80b ca. 2,1 Sekunden Sendezeit auf Seiten der Zentrale, also etwa 6% der je Stunde zur Verfügung stehenden Sendezeit. Daraus ergibt sich eine Obergrenze von 17 einsetzbaren FHT80bs je Zentrale. In realen Umgebungen wird die Kommunikation aber nicht fehlerfrei ablaufen, es wird also Wiederholungen geben. Ebenso belasten auch die ausgesendeten Telegramme an FS20 Aktoren und Temperaturänderungen an FHT80bs den Funkkanal zusätzlich. Faktisch sind daher circa ein Dutzend FHT80bs sinnvoll einsetzbar.
-==detailierte Betrachtung==
+== detailierte Betrachtung ==
-Die bidirektionale Kommunikation kann mit FHEM bei Einsatz eines CUL/CUN(O) mitprotokolliert werden ("set CUL raw X61" vorher nicht vergessen). Hier ein beispielhafter Mitschnitt:
+Die bidirektionale Kommunikation kann mit FHEM bei Einsatz eines [[CUL]]/CUN(O) mitprotokolliert werden ("set CUL raw X61" vorher nicht vergessen). Hier ein beispielhafter Mitschnitt:
 -09-28 13:04:18 FHT wz actuator: 0%
@@ Zeile 46: / Zeile 46: @@
 FHZ:xxx Telegramme wurden von dem FHZ (oder CUN/CUL) gesendet, die anderen vom FHT.
-fhem fasst measured-low und measured-high zu measured-temp zusammen, es werden also im normalen log (telnet: inform timer) 2 Zeilen weniger gemeldet.
+FHEM  fasst measured-low und measured-high zu measured-temp zusammen, es werden also im normalen log (telnet: inform timer) 2 Zeilen weniger gemeldet.
 ist der FHT-ID des protokollierten FHZ. Wenn das FHZ nicht mit dem richtigen FHT-ID antwortet, dann geht die Kommunikation nicht weiter.
@@ Zeile 53: / Zeile 53: @@
 Set Prog:Cent:N/A setzt die FHT-ID des FHT80 auf 100, dann sollte jede FHZ auf  "start-xmit" antworten, und das FHT merkt den ersten.  Noch besser dem FHT via FHEM was zu senden, dann muss man nicht auf die nächste Temperaturmeldung (bis zu 15 Minuten) warten.
 Mehr dazu auch hier: [[FHT mit RFR CUL pairen]]
-Falls die Gegenseite nicht wie erwartet antwortet, dann wird es nach einem Timeout das Telegramm einmal wiederholt. Falls immer noch keine korrekte Antwort vorliegt, dann wird es nach 115+x Sekunden das ganze Vorgang einmal wiederholt.
+Falls die Gegenseite nicht wie erwartet antwortet, dann wird nach einem Timeout das Telegramm einmal wiederholt. Falls immer noch keine korrekte Antwort vorliegt, dann wird nach 115+x Sekunden der ganze Vorgang einmal wiederholt.
-Jedes Telegramm ist bei 1000Baud ca 75ms lang. Die Temperatur wird pro FHT 4-mal die Stunde gemeldet: 4*7*75ms = 2.1s FHZ-Sendezeit pro FHT und Stunde, und da man wg. 1% 36 Sekunden hat, entspricht das 5.833% pro FHT. Wenn das 1% erschoepft ist, dann versucht das CUL zu antworten, aber es wird bei jedem Versuch LOVF ausgegeben.
+Jedes Telegramm ist bei 1000Baud ca 75ms lang. Die Temperatur wird pro FHT 4-mal die Stunde gemeldet: 4*7*75ms = 2.1s FHZ-Sendezeit pro FHT und Stunde, und da man wg. 1% 36 Sekunden hat, entspricht das 5.833% pro FHT. Wenn das 1% erschoepft ist, dann versucht das CUL zu antworten, aber es wird bei jedem Versuch [[LOVF]] ausgegeben.
 Falls die Kommunikation nie abbricht (also fehlerfrei stattfinden kann), und sonst auch nichts gesendet wird, kann man mit einem FHZ 17 FHTs versorgen. Faktisch wird die Menge der einsetzbaren FHTs wesentlich geringer sein. ELV geht als Hersteller offenbar von maximal 10-14 FHTs aus, so unterstützt das Wärmerelais FHT8w maximal 10 Räume, während es in der Bedienungsanleitung der FHZ1000 Standalone Zentrale heisst, es könnten bis zu 15 Räume gesteuert werden. Da die FHZ1000 einen Raum selbst bedient, ist die Kommunikation mit weiteren 14 FHT80b Geräten notwendig.
-==mögliche Abhilfe==
+== mögliche Abhilfe ==
 Denkbar ist der Einsatz mehrerer Zentralen, also z.&nbsp;B. mittels Anschluss mehrerer CULs/CUNs oder Nutzung von RFR CULs. Somit könnten Geräte auf die Zentralen verteilt werden, um die jeweilige Last zu senken.
@@ Zeile 73: / Zeile 73: @@
 Mehrere an einen FHEM Hostrechner angeschlossen Zentralen haben zur besseren Ausleuchtung durchaus ihre Berechtigung, zur Erhöhung der maximal nutzbaren Geräte sind sie aber nur bedingt geeignet, wenn nicht sogar unzulässig.
-==Links==
+{{todo|hier die irgendwo aufgeführte FHEM-Config-Option (IIRC eine Liste von zu berücksichtigenden Devicenamen) referenzieren/erwähnen, die eine Serialisierung der Aktivitäten mehrerer CUL-Sender durchführt und somit Kollisionsprobleme reduzieren kann}}
+== Links ==
 [[Kommunikationsprobleme_mit_FHT]]