LOVF: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K (Typos/Spelling) |
||
(2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
LOVF = Limit Overflow meldet, dass die [[1% Regel]] überschritten ist. | LOVF = Limit Overflow meldet, dass die [[1% Regel]] überschritten ist. | ||
Praktisch umgesetzt ist das 1% Sendelimit z.b. im [[CUL]] so, das pro Sekunde 10ms Sendezeit "gutgeschrieben" wird. Die Anzahl der noch zur Verfügung stehenden 10ms Sendeeinheiten kann mittels "get cul raw X" abgefragt werden (zweite Zahl = Anzahl noch verfügbarer Einheiten), eine Aussendung, die wegen erreichter | Praktisch umgesetzt ist das 1% Sendelimit z.b. im [[CUL]] so, das pro Sekunde 10ms Sendezeit "gutgeschrieben" wird. Die Anzahl der noch zur Verfügung stehenden 10ms Sendeeinheiten kann mittels "get cul raw X" abgefragt werden (zweite Zahl = Anzahl noch verfügbarer Einheiten), eine Aussendung, die wegen erreichter maximaler Frequenzbelegungsdauer nicht gesendet werden kann quittiert das CUL mit der Meldung LOVF (= limit-overflow). Eine FS20 Übertragung benötigt ca. 220ms also ca. 22 Sendeeinheiten. Ist die maximale Frequenzbelegungsdauer erreicht, dauert es also mindestens 22 Sekunden, bis erstmals wieder gesendet werden kann. | ||
Daraus | Daraus ergibt sich, das maximal 163 FS20 Kommandos pro Stunde gesendet werden können. Wird dieser Wert überschritten, meldet FHEM zusätzlich zu LOVF '''CUL TRANSMIT LIMIT EXCEEDED'''. Eine weitere Schaltung von FS20 Komponenten ist dann nicht mehr möglich. Daher ist es z.B. ungünstig, blinkende Lampen oder ähnliches per Schaltbefehl zu realisieren. Eine mit 1 Hz blinkende Lampe hat das gesamte FS20 Funkkontingent einer Stunde nach weniger als 3 Minuten Blinken aufgebraucht (und dies auch nur, weil mit FS20 der "on-for-timer 1" Befehl verwendet werden kann). | ||
Gefährlich sind auch Bewegungsmelder mit kurzen Meldeintervallen aber regelmässiger Auslösung. Der FS20 PIRI oder PIRA gestattet z.b. als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist das | Gefährlich sind auch Bewegungsmelder mit kurzen Meldeintervallen aber regelmässiger Auslösung. Der [[FS20 PIRA Infrarot-Bewegungsmelder|FS20 PIRI oder PIRA]] gestattet z.b. als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist das Sendekontingent des PIRA/PIRI nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder nicht mehr senden. Schlimmer noch: Wird in FHEM durch jede dieser Bewegungen eine Aktion ausgelöst, die FHEM dazu veranlasst, einen oder gar mehrere Sendebefehle abzusetzen, so kann die Funkschnittstelle von FHEM (z.b. eine CUL) ebenso schnell oder gar schneller ihr Sendelimit erreichen. | ||
Daher sollte bei Bewegungsmeldern immer ein möglichst langer Sendeabstand eingestellt werden. | |||
Auch [[FHT80b]]s bzw. alle im SlowRF Modus ansprechbaren Geräte belasten das Sendelimit. | Auch [[FHT80b]]s bzw. alle im SlowRF Modus ansprechbaren Geräte belasten das Sendelimit. | ||
Zeile 12: | Zeile 13: | ||
Weiterführende Informationen über den Problembereich sind im Artikel [[Kommunikationsprobleme mit FHT]] zusammengestellt. | Weiterführende Informationen über den Problembereich sind im Artikel [[Kommunikationsprobleme mit FHT]] zusammengestellt. | ||
Wegen der höheren Datenrate und | Wegen der höheren Datenrate und der daher deutlich kürzeren Sendedauer von Befehlen kommt es bei HomeMatic seltener zu Limit Overflows. | ||
[[Kategorie:Glossary]] | [[Kategorie:Glossary]] |
Aktuelle Version vom 17. Februar 2019, 20:12 Uhr
LOVF = Limit Overflow meldet, dass die 1% Regel überschritten ist.
Praktisch umgesetzt ist das 1% Sendelimit z.b. im CUL so, das pro Sekunde 10ms Sendezeit "gutgeschrieben" wird. Die Anzahl der noch zur Verfügung stehenden 10ms Sendeeinheiten kann mittels "get cul raw X" abgefragt werden (zweite Zahl = Anzahl noch verfügbarer Einheiten), eine Aussendung, die wegen erreichter maximaler Frequenzbelegungsdauer nicht gesendet werden kann quittiert das CUL mit der Meldung LOVF (= limit-overflow). Eine FS20 Übertragung benötigt ca. 220ms also ca. 22 Sendeeinheiten. Ist die maximale Frequenzbelegungsdauer erreicht, dauert es also mindestens 22 Sekunden, bis erstmals wieder gesendet werden kann.
Daraus ergibt sich, das maximal 163 FS20 Kommandos pro Stunde gesendet werden können. Wird dieser Wert überschritten, meldet FHEM zusätzlich zu LOVF CUL TRANSMIT LIMIT EXCEEDED. Eine weitere Schaltung von FS20 Komponenten ist dann nicht mehr möglich. Daher ist es z.B. ungünstig, blinkende Lampen oder ähnliches per Schaltbefehl zu realisieren. Eine mit 1 Hz blinkende Lampe hat das gesamte FS20 Funkkontingent einer Stunde nach weniger als 3 Minuten Blinken aufgebraucht (und dies auch nur, weil mit FS20 der "on-for-timer 1" Befehl verwendet werden kann). Gefährlich sind auch Bewegungsmelder mit kurzen Meldeintervallen aber regelmässiger Auslösung. Der FS20 PIRI oder PIRA gestattet z.b. als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist das Sendekontingent des PIRA/PIRI nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder nicht mehr senden. Schlimmer noch: Wird in FHEM durch jede dieser Bewegungen eine Aktion ausgelöst, die FHEM dazu veranlasst, einen oder gar mehrere Sendebefehle abzusetzen, so kann die Funkschnittstelle von FHEM (z.b. eine CUL) ebenso schnell oder gar schneller ihr Sendelimit erreichen. Daher sollte bei Bewegungsmeldern immer ein möglichst langer Sendeabstand eingestellt werden.
Auch FHT80bs bzw. alle im SlowRF Modus ansprechbaren Geräte belasten das Sendelimit.
Insbesondere die alle 15 Minuten stattfindende bidirektionale Kommunikation mit FHT80bs sorgt dafür, dass die Anzahl Maximal nutzbare Geräte relativ eingeschränkt ist.
Weiterführende Informationen über den Problembereich sind im Artikel Kommunikationsprobleme mit FHT zusammengestellt.
Wegen der höheren Datenrate und der daher deutlich kürzeren Sendedauer von Befehlen kommt es bei HomeMatic seltener zu Limit Overflows.