Verständnisfragen zum Duty Cycle
Moderatoren: jmaus, Co-Administratoren
-
- Beiträge: 488
- Registriert: 11.12.2014, 23:40
- Hat sich bedankt: 6 Mal
- Danksagung erhalten: 2 Mal
Verständnisfragen zum Duty Cycle
Hallo,
ich hab grad festgestellt, dass man sich bei größeren Installationen auch mal Gedanken über den Duty Cycle machen sollte.
Dazu habe ich jetzt ein paar Verständnisfragen:
1. Wenn ich alle meine Programme mit dem Trigger "bei Änderung auslösen" starte, reduziere ich den Duty Cycle, weil es nur Funkkontakt gibt wenn sich bei den Sensoren was tut (z.B. Bewegungsmelder) ?
2. Ich hole mir z.B. Energieverbrauchswerte (von 5 Mess-Steckdosen) im Minutentakt mittels HTTP-Request über z.B.: 'http://10.0.2.99:8181/egal.exe?ganzegal ... ER").Value()'
Wird dabei der Wert direkt vom Sensor gelesen (in meinem Fall eine Mess-Steckdose) oder bekomme ich einfach den letzten Wert den die CCU vom Sensor erhalten hat ?
Bringt es etwas eine Systemvariable mittels "bei Änderung auslösen" zu beschreiben und dann deren Wert zu lesen anstatt auf den Sensor zuzugreifen ?
3. Ab wann wird der Duty-Cycle kritisch ? Während ich diesen Post schreibe ist er von 25 auf 42 hochgeklettert. Ab wann sollte man aufpassen ?
lG
Gawan
ich hab grad festgestellt, dass man sich bei größeren Installationen auch mal Gedanken über den Duty Cycle machen sollte.
Dazu habe ich jetzt ein paar Verständnisfragen:
1. Wenn ich alle meine Programme mit dem Trigger "bei Änderung auslösen" starte, reduziere ich den Duty Cycle, weil es nur Funkkontakt gibt wenn sich bei den Sensoren was tut (z.B. Bewegungsmelder) ?
2. Ich hole mir z.B. Energieverbrauchswerte (von 5 Mess-Steckdosen) im Minutentakt mittels HTTP-Request über z.B.: 'http://10.0.2.99:8181/egal.exe?ganzegal ... ER").Value()'
Wird dabei der Wert direkt vom Sensor gelesen (in meinem Fall eine Mess-Steckdose) oder bekomme ich einfach den letzten Wert den die CCU vom Sensor erhalten hat ?
Bringt es etwas eine Systemvariable mittels "bei Änderung auslösen" zu beschreiben und dann deren Wert zu lesen anstatt auf den Sensor zuzugreifen ?
3. Ab wann wird der Duty-Cycle kritisch ? Während ich diesen Post schreibe ist er von 25 auf 42 hochgeklettert. Ab wann sollte man aufpassen ?
lG
Gawan
-
- Beiträge: 340
- Registriert: 18.11.2016, 22:36
- Wohnort: ziemlich weit unten
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 1 Mal
Re: Verständnisfragen zum Duty Cycle
Richtig, besser als Aktualisierung
Zu zweitens : wenn du die IP der CCU als Ziel abfragen tust, dann kommt der Wert von der CCU.
Das erklärt den hohen DC.
Wenn du temporär die Werte deiner Steckdose abfragst, ist 45% okay. Allerdings für den Ruhezustand sollte es höchstens 10% sein.
Dazu steht aber hier schon sehr viel geschrieben..
Vg Torsten
Zu zweitens : wenn du die IP der CCU als Ziel abfragen tust, dann kommt der Wert von der CCU.
Das erklärt den hohen DC.
Wenn du temporär die Werte deiner Steckdose abfragst, ist 45% okay. Allerdings für den Ruhezustand sollte es höchstens 10% sein.
Dazu steht aber hier schon sehr viel geschrieben..
Vg Torsten
Raspberry Matic RP3, iobroker & Node-Red auf orangePi
HM Lan GW
--- HM-RF, HmIP-RF und knx Komponenten ---
Visualisierung auf Android 10" Tablett
HM Lan GW
--- HM-RF, HmIP-RF und knx Komponenten ---
Visualisierung auf Android 10" Tablett
-
- Beiträge: 488
- Registriert: 11.12.2014, 23:40
- Hat sich bedankt: 6 Mal
- Danksagung erhalten: 2 Mal
Re: Verständnisfragen zum Duty Cycle
Ich hol mir die Daten 24/7 im Minutentakt und leg sie auf einem SQL-Server ab.
D.h. Wenn ich bei Änderung in eine Systemvariable schreibe und diese von der CCU auslese erhöht das meinen DC gar nicht ?
Lg
RW
D.h. Wenn ich bei Änderung in eine Systemvariable schreibe und diese von der CCU auslese erhöht das meinen DC gar nicht ?
Lg
RW
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 34 Mal
Re: Verständnisfragen zum Duty Cycle
Hi,
auch hier gilt, es gibt einen Unterschied zwischen .State() und .Value()
Ich kann es mir nicht merken, aber zieh einfach mal die Steckdose für 5 min. raus, bekommst du dann schon Kom-Errors für die Messsteckdose, dann nutzt du die falsche Methode.
Der Familienvater
Gesendet von meinem Nexus 6 mit Tapatalk
auch hier gilt, es gibt einen Unterschied zwischen .State() und .Value()
Ich kann es mir nicht merken, aber zieh einfach mal die Steckdose für 5 min. raus, bekommst du dann schon Kom-Errors für die Messsteckdose, dann nutzt du die falsche Methode.
Der Familienvater
Gesendet von meinem Nexus 6 mit Tapatalk
- Roland M.
- Beiträge: 9806
- Registriert: 08.12.2012, 15:53
- System: CCU
- Wohnort: Graz, Österreich
- Hat sich bedankt: 252 Mal
- Danksagung erhalten: 1381 Mal
Re: Verständnisfragen zum Duty Cycle
Hallo!
Mit dem Trigger beeinflusst du nur die Anzahl der Programmauslösungen, und das auch nur wenn das auslösende Gerät periodisch sendet (z.B. Temperatursensoren alle ~3 min, oder TFK nach 1 bzw. 24 h). Was das Programm dann macht, hängt von den Programmierkünsten des Users ab.
Was soll eine SV bringen, wenn du Messwerte ermitteln willst?
Einfach unnötigen Funkverkehr vermeiden.
Roland
Nicht zwangsweise.Gawan hat geschrieben:1. Wenn ich alle meine Programme mit dem Trigger "bei Änderung auslösen" starte, reduziere ich den Duty Cycle, weil es nur Funkkontakt gibt wenn sich bei den Sensoren was tut (z.B. Bewegungsmelder) ?
Mit dem Trigger beeinflusst du nur die Anzahl der Programmauslösungen, und das auch nur wenn das auslösende Gerät periodisch sendet (z.B. Temperatursensoren alle ~3 min, oder TFK nach 1 bzw. 24 h). Was das Programm dann macht, hängt von den Programmierkünsten des Users ab.
Hier verwendest du .Value(), was den zwischengespeicherten Wert der CCU verwendet. Im Gegensatz dazu kannst du mit .State() den aktuellen Wert vom Gerät holen, das belastet natürlich den DC. Vor allem, wenn periodisch die Werte abgefragt werden, ohne dass sie sich vielleicht verändert haben.2. Ich hole mir z.B. Energieverbrauchswerte (von 5 Mess-Steckdosen) im Minutentakt mittels HTTP-Request über z.B.: 'http://10.0.2.99:8181/egal.exe?ganzegal ... ER").Value()'
Das hängt von der entsprechenden Aufgabe ab und kann nicht pauschal beantwortet werden.Bringt es etwas eine Systemvariable mittels "bei Änderung auslösen" zu beschreiben und dann deren Wert zu lesen anstatt auf den Sensor zuzugreifen ?
Was soll eine SV bringen, wenn du Messwerte ermitteln willst?
Von Anfang an!Während ich diesen Post schreibe ist er von 25 auf 42 hochgeklettert. Ab wann sollte man aufpassen ?
Einfach unnötigen Funkverkehr vermeiden.
Roland
Zur leichteren Hilfestellung bitte unbedingt beachten:
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
- Bezeichnung (HM-... bzw. HmIP-...) der betroffenen Geräte angeben (nicht Artikelnummer)
- Kurzbeschreibung des Soll-Zustandes (Was soll erreicht werden?)
- Kurzbeschreibung des Ist-Zustandes (Was funktioniert nicht?)
- Fehlermeldungen genau abschreiben, besser noch...
- Screenshots von Programmen, Geräteeinstellungen und Fehlermeldungen (direkt als jpg/png) einstellen!
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
-
- Beiträge: 488
- Registriert: 11.12.2014, 23:40
- Hat sich bedankt: 6 Mal
- Danksagung erhalten: 2 Mal
Re: Verständnisfragen zum Duty Cycle
Hallo,
im Moment bin ich konstant über 80 - keine Ahnung wieso.
Das einzige wirklich "aufwändige" sind die minütlichen Abfragen von 5 Schalt-Messdosen-Verbrauchsdaten, aber da hole ich mir die Werte mittels .Value(), d.h. es dürfte keinen Einfluss auf den DC haben.
Was soll eine SV bringen ?
Meine Idee war, dass ich jedesmal wenn der Sensor seinen Wert aktualisiert diesen in der SV unterbringe und dann mein externes Programm über LAN diese SV abfragt - dadurch wäre der DC für diesen Sensor auf 0 reduziert. Wenn das aber über den .Value() Aufruf sowieso passiert, dann hab ich keine Ahnung wo der ganze Verkehr herkommt
im Moment bin ich konstant über 80 - keine Ahnung wieso.
Das einzige wirklich "aufwändige" sind die minütlichen Abfragen von 5 Schalt-Messdosen-Verbrauchsdaten, aber da hole ich mir die Werte mittels .Value(), d.h. es dürfte keinen Einfluss auf den DC haben.
Was soll eine SV bringen ?
Meine Idee war, dass ich jedesmal wenn der Sensor seinen Wert aktualisiert diesen in der SV unterbringe und dann mein externes Programm über LAN diese SV abfragt - dadurch wäre der DC für diesen Sensor auf 0 reduziert. Wenn das aber über den .Value() Aufruf sowieso passiert, dann hab ich keine Ahnung wo der ganze Verkehr herkommt
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 34 Mal
Re: Verständnisfragen zum Duty Cycle
Hi,
das ist so leider nicht ganz richtig, es hängt auch von der Konfiguration des Aktors selbst ab, wie dieser bei Änderungen der Spannung/Strom/Leistung/Frequenz Extra Sendungen machen soll.
Ein HM-Energiemessaktor sendet zyklisch ca. alle 90 Sekunden seine aktuellen Daten, das kostet nur Sendezeit des Aktors, weil die Daten als "Broadcast" gesendet werden, muss die Zentrale absolut nichts tun.
Ist der Sensor "schlecht" Konfiguriert, sendet der z.B. bei einer Änderung der Spannung von 1 Volt ein "spontanes" Datenpaket an die Zentrale, dieses muss von der Zentrale quittiert werden, kostet also auf beiden Seiten Sendezeit. Je nach "Sinnlosigkeit" der Konfiguration des Messaktors sendet dieser alle 8 oder 16 Sekunden ein spontanes Energieevent, was die Zentrale quittieren muss, und glaube mir, das kostet richtig Sendezeit. Wenn man es braucht, und weiß, was man tut, ist es OK...
Der Familienvater
das ist so leider nicht ganz richtig, es hängt auch von der Konfiguration des Aktors selbst ab, wie dieser bei Änderungen der Spannung/Strom/Leistung/Frequenz Extra Sendungen machen soll.
Ein HM-Energiemessaktor sendet zyklisch ca. alle 90 Sekunden seine aktuellen Daten, das kostet nur Sendezeit des Aktors, weil die Daten als "Broadcast" gesendet werden, muss die Zentrale absolut nichts tun.
Ist der Sensor "schlecht" Konfiguriert, sendet der z.B. bei einer Änderung der Spannung von 1 Volt ein "spontanes" Datenpaket an die Zentrale, dieses muss von der Zentrale quittiert werden, kostet also auf beiden Seiten Sendezeit. Je nach "Sinnlosigkeit" der Konfiguration des Messaktors sendet dieser alle 8 oder 16 Sekunden ein spontanes Energieevent, was die Zentrale quittieren muss, und glaube mir, das kostet richtig Sendezeit. Wenn man es braucht, und weiß, was man tut, ist es OK...
Der Familienvater
-
- Beiträge: 488
- Registriert: 11.12.2014, 23:40
- Hat sich bedankt: 6 Mal
- Danksagung erhalten: 2 Mal
Re: Verständnisfragen zum Duty Cycle
Ich hab den Aktor einmalig angelernt, die Kanäle umbenannt, die Übertragung gesichert und sonst absolut nichts mehr verändert.
Wie und wo kann ich einen Aktor entsprechend konfigurieren bzw. wieder korrigieren ?
Programme die damit arbeiten gibt es in meinem Fall nicht
lG
Wie und wo kann ich einen Aktor entsprechend konfigurieren bzw. wieder korrigieren ?
Programme die damit arbeiten gibt es in meinem Fall nicht
lG
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 34 Mal
Re: Verständnisfragen zum Duty Cycle
Hi,
dazu fällt mir absolut nichts mehr ein. Muss an Karneval liegen, das nur noch Jecken hier unterwegs sind.
Energiemesswerte sind so wichtig, das man die gesicherte Übertragung aktivieren muss, damit einem ja keiner nachgemachte, oder gefälschte Energiewerte unterjubbeln kann (mit gesicherter Übertragung steigt die Sendeziet nicht um 50%, aber es wird für jedes Quittierungspflichtige Datenpaket ein extra Hin- und Hergefunke notwendig).
Das man Geräte auch Konfigurieren kann/muss ist Dir nicht geläufig (ja nee, iss klar, wird ja im SQL-Server nicht angezeigt....)?
Erstmal wie alle anderen auch die Basics lernen, WebUI-Handbuch lesen und verstehen (!), und als allerletzten Schritt, wenn einem HM-Script echt nicht in die Birne geht, dann vielleicht anfangen, das System mit (den richtigen) Methoden extern steuern, in genau dieser Reihenfolge....
Der Familienvater
dazu fällt mir absolut nichts mehr ein. Muss an Karneval liegen, das nur noch Jecken hier unterwegs sind.
Energiemesswerte sind so wichtig, das man die gesicherte Übertragung aktivieren muss, damit einem ja keiner nachgemachte, oder gefälschte Energiewerte unterjubbeln kann (mit gesicherter Übertragung steigt die Sendeziet nicht um 50%, aber es wird für jedes Quittierungspflichtige Datenpaket ein extra Hin- und Hergefunke notwendig).
Das man Geräte auch Konfigurieren kann/muss ist Dir nicht geläufig (ja nee, iss klar, wird ja im SQL-Server nicht angezeigt....)?
Erstmal wie alle anderen auch die Basics lernen, WebUI-Handbuch lesen und verstehen (!), und als allerletzten Schritt, wenn einem HM-Script echt nicht in die Birne geht, dann vielleicht anfangen, das System mit (den richtigen) Methoden extern steuern, in genau dieser Reihenfolge....
Der Familienvater