Maximal nutzbare SlowRF Geräte: Unterschied zwischen den Versionen
K (Soulman verschob Seite Maximal nutzbare SlowRF Geräte nach Maximal nutzbare Geräte, ohne dabei eine Weiterleitung anzulegen: zurück verschieben) |
K (Soulman verschob Seite Maximal nutzbare Geräte nach Maximal nutzbare SlowRF Geräte: So, hoffentlich stimmt jetzt alles.) |
Version vom 22. Mai 2013, 13:32 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 Devices kennt; durch Nutzung von Dummy-Devices 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.
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ärend die einzelnen Devices wie FS20 Aktoren 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. Das FHT/FS20 Funkprotokoll ("SlowRF") ist Gegensatz zum HomeMatic Protokoll relativ langsam, sodass eine Befehl siginifikante 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 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.
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 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.
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.