Quelltext der Seite Maximal nutzbare SlowRF Geräte

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. 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 ==

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 [[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:

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.&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.

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]]


[[Kategorie:FS20 Components]]
[[Kategorie:FHT Components]]