Duty Cycle... nervt
Moderator: Co-Administratoren
Duty Cycle... nervt
Hallo,
meine Anlage läuft eigentlich gut.
Meine Herasuforderung ist "Duty Cycle":
Ab und zu laufen die Fehlermeldungen voll oder ich stehe vor der Tür und bekomme sie nicht auf, weil "Duty Cycle" des Gateways auf fast 100% ist.
Ich bekomme einfach keine saubere Einstellung der Verteilung hin.
Ich habe Raspy und vier Gateways im Einsatz.
Im Normalfall geht das ganz gut.
Nur in besonderen Situationen läuft ein "Duty Cycle" voll und es geht fast nichts mehr (Grafiken in Anlage).
Ich versuche zu ergründen, welche Geräte hier besondern problematisch (sendeintensiv) sind.
Bisher habe ich die Aktor/Sensor Geräte mit Leistungsmessung, die Bewegungsmelder und die Fensterantriebe als Quellen identifiziert.
Mich interessiert eure Erfahrung. Gruß
Sid
meine Anlage läuft eigentlich gut.
Meine Herasuforderung ist "Duty Cycle":
Ab und zu laufen die Fehlermeldungen voll oder ich stehe vor der Tür und bekomme sie nicht auf, weil "Duty Cycle" des Gateways auf fast 100% ist.
Ich bekomme einfach keine saubere Einstellung der Verteilung hin.
Ich habe Raspy und vier Gateways im Einsatz.
Im Normalfall geht das ganz gut.
Nur in besonderen Situationen läuft ein "Duty Cycle" voll und es geht fast nichts mehr (Grafiken in Anlage).
Ich versuche zu ergründen, welche Geräte hier besondern problematisch (sendeintensiv) sind.
Bisher habe ich die Aktor/Sensor Geräte mit Leistungsmessung, die Bewegungsmelder und die Fensterantriebe als Quellen identifiziert.
Mich interessiert eure Erfahrung. Gruß
Sid
Zuletzt geändert von Sid Omsa am 20.09.2018, 09:07, insgesamt 1-mal geändert.
173 Geräte, HM + HM-IP, Raspi 3, HConnect
-
- Beiträge: 380
- Registriert: 05.01.2016, 09:27
- Wohnort: Wien
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 1 Mal
Re: Duty Cicle... nervt
Gerade die Steckdosen mit Leistungsmessung und die Bewegungsmelder sind fast immer vollkommen falsch konfiguriert. Und das treibt den DC in die Höhe.
Dann kommen noch Programme die unnötig oft senden weil sie immer wieder den Status übertragen welcher eh schon vorhanden ist.
Aber ohne eine detaillierte Auflistung (Screenshots) der Programme und Einstellungen geht es hier nicht weiter.
Dann kommen noch Programme die unnötig oft senden weil sie immer wieder den Status übertragen welcher eh schon vorhanden ist.
Aber ohne eine detaillierte Auflistung (Screenshots) der Programme und Einstellungen geht es hier nicht weiter.
- AndiN
- Beiträge: 2621
- Registriert: 10.06.2015, 08:54
- Wohnort: Hennef
- Hat sich bedankt: 10 Mal
- Danksagung erhalten: 28 Mal
Re: Duty Cicle... nervt
Hallo,
genau wie Jeeper schon schrieb.
Mein Duty liegt inzwischen im 24 Stunden Schnitt bei max 2,00. Da war einiges an Srkipt-Optimierung, Programm-Optimierung und auch Konfiugration der Steckodsen notwendig.
Daher kann ich Dir nur den Tipp geben:
1.) Mach mal ein Screenshot von den Steckdosen Geräte-Einstellungen (Bei Dir werden wohl die Bewegungsmelder vielleicht in den Programmen auch eine Rolle spielen... aber die habe ich nicht im Einsatz... Denke aber unter Punkt 2 oder 3 spielt das gerade da eine Rolle)
2.) Wenn Du mit Skripten arbeitest, dann Ausdruck der Programme (also via Browser am Display) und dann nach .State() suchen und schauen, ob Du den Status von Geräten abrufst. Da entsteht auch Funkverkehr. Hier musst du dann umstellen auf .State() (da tut es aber nicht einfach nur .State() durch .Value() ersetzen. Das kann man dann in Ruhe erläutern
3.) In den Programmen schauen, ob Du da was schaltest, obwohl es geschaltet ist. Extrem Beispiel:
WENN DUNKEL (bei Aktualisierung)
DANN Schalte Lampe ein
- Die Lampe wird eingeschaltet
- Bei jeder Aktualisierung von DUNKEL auf DUNKEL (und das passiert bei Nacht eigentlich permanent wird die Lampe eingeschaltt. Sie ist aber schon lagen an, D.h. hier kann man Funkverkehr reduzieren, indem A.) Bei Änderung DUNKEL genommen wird und B.) Der Status der Lampe (PRÜFEN) eingebaut würde.
(Denke DUNKEL könnte bei Dir BEWEGUNG passen... Aber Schuß ins Blaue)
Bin gespannt wie es hier weiter geht und ich hoffe die Tipps helfen ein wenig weiter.
Andi
genau wie Jeeper schon schrieb.
Mein Duty liegt inzwischen im 24 Stunden Schnitt bei max 2,00. Da war einiges an Srkipt-Optimierung, Programm-Optimierung und auch Konfiugration der Steckodsen notwendig.
Daher kann ich Dir nur den Tipp geben:
1.) Mach mal ein Screenshot von den Steckdosen Geräte-Einstellungen (Bei Dir werden wohl die Bewegungsmelder vielleicht in den Programmen auch eine Rolle spielen... aber die habe ich nicht im Einsatz... Denke aber unter Punkt 2 oder 3 spielt das gerade da eine Rolle)
2.) Wenn Du mit Skripten arbeitest, dann Ausdruck der Programme (also via Browser am Display) und dann nach .State() suchen und schauen, ob Du den Status von Geräten abrufst. Da entsteht auch Funkverkehr. Hier musst du dann umstellen auf .State() (da tut es aber nicht einfach nur .State() durch .Value() ersetzen. Das kann man dann in Ruhe erläutern
3.) In den Programmen schauen, ob Du da was schaltest, obwohl es geschaltet ist. Extrem Beispiel:
WENN DUNKEL (bei Aktualisierung)
DANN Schalte Lampe ein
- Die Lampe wird eingeschaltet
- Bei jeder Aktualisierung von DUNKEL auf DUNKEL (und das passiert bei Nacht eigentlich permanent wird die Lampe eingeschaltt. Sie ist aber schon lagen an, D.h. hier kann man Funkverkehr reduzieren, indem A.) Bei Änderung DUNKEL genommen wird und B.) Der Status der Lampe (PRÜFEN) eingebaut würde.
(Denke DUNKEL könnte bei Dir BEWEGUNG passen... Aber Schuß ins Blaue)
Bin gespannt wie es hier weiter geht und ich hoffe die Tipps helfen ein wenig weiter.
Andi
Andi (Greenhorn)
Letzter Reboot: 17.03.24 => FW Update (Uptime:Rekord:153 Tage)
Systeminfos: Raspberry Pi3 Firmware: 3.75.6.20240316 142 Geräte
System angebunden: 3 Roomba 650 - Sprachausgabe via Home24 Media - Pocket Control - Zentrale: Asus TF103 mit Home24 Tablet
Addons: Drucken 2.5 - HQ WebUI 2.5.9 - XML-API 1.22 - CUx-Daemon 2.9.3 - E-Mail 1.7.4 - hm_pdetect 1.11 - VPN cloudmatic
Diverse Links
Letzter Reboot: 17.03.24 => FW Update (Uptime:Rekord:153 Tage)
Systeminfos: Raspberry Pi3 Firmware: 3.75.6.20240316 142 Geräte
System angebunden: 3 Roomba 650 - Sprachausgabe via Home24 Media - Pocket Control - Zentrale: Asus TF103 mit Home24 Tablet
Addons: Drucken 2.5 - HQ WebUI 2.5.9 - XML-API 1.22 - CUx-Daemon 2.9.3 - E-Mail 1.7.4 - hm_pdetect 1.11 - VPN cloudmatic
Diverse Links
- Sammy
- Beiträge: 9172
- Registriert: 09.09.2008, 20:47
- Hat sich bedankt: 15 Mal
- Danksagung erhalten: 174 Mal
Re: Duty Cicle... nervt
Hallo,
bitte den Titel ändern, damit andere den Thread auch über die Suche finden.
Es heißt: Duty Cycle
Gruß Sammy
bitte den Titel ändern, damit andere den Thread auch über die Suche finden.
Es heißt: Duty Cycle
Gruß Sammy
Links: CCU-Logik, Tipps für Anfänger, WebUI-Doku, Expertenparameter, virtuelle Aktorkanäle
Inventur vom 22.01.14: 516 Kanäle in 165 Geräten, 132 Programme, 270 Direkte Verknüpfungen
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
Inventur vom 22.01.14: 516 Kanäle in 165 Geräten, 132 Programme, 270 Direkte Verknüpfungen
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
Re: Duty Cicle... nervt
Bei 4 Gateways und einer Zentrale stehen dumm gesagt 500% DC zur Verfügung!
Wenn diese Menge an Sendezeit regelmäßig durch die Decke geht liegt es wahrscheinlich nur zum Teil an der Konfig der Geräte, die Hauptschuld wird bei extrem DC-nachteiligen Programmen zu suchen sein. Die CCU selbst bietet viele Fallstricke um haufenweise unnötige Funkprotokolle zu senden (z.B. "bei Aktualisierung" als Auslöser). Mindestens ebenso gefährlicher wird es wenn iobroker oder andere externe Lösungen im Spiel sind. Hier programmierte Skripte werden sehr oft ohne Rücksicht auf die "Funkhygiene" eingesetzt. Leider ist es viel zu oft so das aus Unwissenheit irgendwas zusammengeklickt wird, Hauptsache es funktioniert irgendwie, ohne wirklich zu wissen was im Hintergrund passiert.
Realistisch betrachtet sollte Deine Anlage mit 167 Geräten und 5 "Zentralen" nur in Ausnahmefällen einen Gesamt-DC von 30-40% übersteigen.
Wenn diese Menge an Sendezeit regelmäßig durch die Decke geht liegt es wahrscheinlich nur zum Teil an der Konfig der Geräte, die Hauptschuld wird bei extrem DC-nachteiligen Programmen zu suchen sein. Die CCU selbst bietet viele Fallstricke um haufenweise unnötige Funkprotokolle zu senden (z.B. "bei Aktualisierung" als Auslöser). Mindestens ebenso gefährlicher wird es wenn iobroker oder andere externe Lösungen im Spiel sind. Hier programmierte Skripte werden sehr oft ohne Rücksicht auf die "Funkhygiene" eingesetzt. Leider ist es viel zu oft so das aus Unwissenheit irgendwas zusammengeklickt wird, Hauptsache es funktioniert irgendwie, ohne wirklich zu wissen was im Hintergrund passiert.
Realistisch betrachtet sollte Deine Anlage mit 167 Geräten und 5 "Zentralen" nur in Ausnahmefällen einen Gesamt-DC von 30-40% übersteigen.
Viele Grüße!
Jörg
Jörg
-
- Beiträge: 10655
- Registriert: 21.09.2012, 08:09
- System: CCU
- Wohnort: Stuttgart
- Hat sich bedankt: 320 Mal
- Danksagung erhalten: 501 Mal
Re: Duty Cicle... nervt
Wo könnte denn der Grund dafür liegen, dass es bei dir gerade in den Abend- und Nachstunden zu solch einem starken Funkaufkommen kommt?
Wie viele Geräte betreibst du denn insgesamt und wie ist die Verteilung auf die einzelnen Gateways?
Wir haben z.B. bei uns im Haus insgesamt vier Bewegungsmelder und sieben Leistungsmessungen (3 x per Zählersensor-Sendeeinheit HM-ES-TX-WM und 4 x per Schaltsteckdose mit Leistungsmessung HM-ES-PMSw1-Pl bzw. HMIP-PSM) über die CCU3 und ein Funk-LAN-Gateway im Einsatz. Der DC geht eigentlich nie über 25. Meistens bewegt er sich zwischen 0 und 10. Neben den genannten Komponenten sind noch knapp über 100 andere Funk-Komponenten im Betrieb.
Leider beeinflussen sehr viele Faktoren den DC. Da wird man um eine Datailanalyse nicht herum kommen. Und dafür sind die in den Vorpostings erwähnten Screenshots und Skriptlistings erforderlich.
Bis dann,
Thorsten
Wie viele Geräte betreibst du denn insgesamt und wie ist die Verteilung auf die einzelnen Gateways?
Wir haben z.B. bei uns im Haus insgesamt vier Bewegungsmelder und sieben Leistungsmessungen (3 x per Zählersensor-Sendeeinheit HM-ES-TX-WM und 4 x per Schaltsteckdose mit Leistungsmessung HM-ES-PMSw1-Pl bzw. HMIP-PSM) über die CCU3 und ein Funk-LAN-Gateway im Einsatz. Der DC geht eigentlich nie über 25. Meistens bewegt er sich zwischen 0 und 10. Neben den genannten Komponenten sind noch knapp über 100 andere Funk-Komponenten im Betrieb.
Leider beeinflussen sehr viele Faktoren den DC. Da wird man um eine Datailanalyse nicht herum kommen. Und dafür sind die in den Vorpostings erwähnten Screenshots und Skriptlistings erforderlich.
Bis dann,
Thorsten
CCU3 mit stets aktueller FW und den Addons "CUxD" und "Programmedrucken", ioBroker auf Synology DiskStation DS718+ im Docker-Container;
einige Projekte: zentrales Push-Nachrichten-Programm zPNP, DoorPi-Videotürsprechanlage, An- und Abwesenheitsdetektion per Haustürschloss, zentrales Programm zur Steuerung von Beschattungsgeräten zBSP.
einige Projekte: zentrales Push-Nachrichten-Programm zPNP, DoorPi-Videotürsprechanlage, An- und Abwesenheitsdetektion per Haustürschloss, zentrales Programm zur Steuerung von Beschattungsgeräten zBSP.
-
- Beiträge: 3302
- Registriert: 07.01.2015, 23:26
- Wohnort: Scheeßel
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 11 Mal
Re: Duty Cycle... nervt
Abends deutet für mich auf sehr häufig angesprochene/sendende BWM hin.
Tagsüber ist man ja meist unterwegs auf Arbeit.
Tagsüber ist man ja meist unterwegs auf Arbeit.
-
- Beiträge: 14086
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 581 Mal
- Danksagung erhalten: 1492 Mal
Re: Duty Cycle... nervt
Ich habe acht BWM im und ums Haus herum und einstelligen Duty Cycle. In der Standardeinstellung senden BWM max. alle 240 Sekunden. Macht 15 Telegramme pro Stunde pro BWM. Wenn man damit den DC treiben will, muss man schon richtig viele davon einsetzen. Ich denke eher, dass dort eine Messsteckdose an einem TV mit stark schwankendem Stromverbrauch angeschlossen ist. Diese Schwankungen dürften bei zu knapp eingestellter Hysterese eine ständige Übermittlung der Messwerte triggern. Wenn dann noch für diese geheimen Informationen die gesicherte Übertragung aktiviert ist, dann ist das ein Garant für einen hohen DC.
Gruß Xel66
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 34 Mal
Re: Duty Cycle... nervt
Hi,
das sieht nach den bereits erwähnten "Wenn draußen Dunkel und keine Bewegung erkannt, dann Licht Aus"-regelmäßigen Sschaltungen in den längst erreichten Zustand aus.
Bei HmIP gibt es für viele Sensoren die Möglichkeit, die Anzahl der auszulassenden Statusmeldungen zu konfigurieren, auch das kann helfen, DC zu sparen. Bei HmIP weiß ich nicht, ob es auch "Broadcasts" gibt, die nicht quittiert werden müssen, oder ob jedes Funk-Paket quittiert werden muss (und damit jedes empfangene Funkpaket Sendezeit auf der Zentrale kostet, die auch nicht auf Gateways verlagert werden kann).
Grundsätzlich ist wie immer meine Empfehlung, das Syslog des rfd auf "Alles loggen" zu stellen, und diese Syslog zu analysieren, da steht nämlich genau drin, welche Geräte angefunkt werden, und dann kann gezielt die Ursache suchen, wo überall dieses Gerät angesprochen wird.
Der Familienvater
das sieht nach den bereits erwähnten "Wenn draußen Dunkel und keine Bewegung erkannt, dann Licht Aus"-regelmäßigen Sschaltungen in den längst erreichten Zustand aus.
Bei HmIP gibt es für viele Sensoren die Möglichkeit, die Anzahl der auszulassenden Statusmeldungen zu konfigurieren, auch das kann helfen, DC zu sparen. Bei HmIP weiß ich nicht, ob es auch "Broadcasts" gibt, die nicht quittiert werden müssen, oder ob jedes Funk-Paket quittiert werden muss (und damit jedes empfangene Funkpaket Sendezeit auf der Zentrale kostet, die auch nicht auf Gateways verlagert werden kann).
Grundsätzlich ist wie immer meine Empfehlung, das Syslog des rfd auf "Alles loggen" zu stellen, und diese Syslog zu analysieren, da steht nämlich genau drin, welche Geräte angefunkt werden, und dann kann gezielt die Ursache suchen, wo überall dieses Gerät angesprochen wird.
Der Familienvater