Duty Cycle steigt enorm beim Start des Projektes

[Daimler]

Hi allerseits,

wollte die Frage / Behauptung nicht in dem HKT-Fred stellen - daher hier separat.
Meine dort eingeworfene Frage
http://homematic-forum.de/forum/viewtop ... 62#p299126
war nat. nicht unbegründet und ich kann das nachfolgende jederzeit reproduzieren:

HPCL: Einstellungen --> Allgemein:
Aktuelle Werte der ExecEngine speichern / laden: Ja
Keine Hardwarabfrage bei Start der ExecEngine: Ja
Nach Projektübertragung / Programmstart geschieht die 1. 5 Minuten überhaupt nichts, da erst danach ein Schalter gesetzt wird, der die Makros freigibt.
Hardwareabfragen mache ich, wenn überhaupt nur manuell über VusuWin

Die ~ 240 Geräte sind - so gut es die Reichweite zulässt - in etwa gleich auf das Funkmodul und die beiden Gateways 1 und 2 verteilt - GW3 dient i. M. als Reserve, falls das Funkmodul auf dem Yahmi wieder ausfallen sollte.

Beispiel aktuell:
Vor dem Erstellen / Übertragen zur CCU:

Code: Alles auswählen

8.08.2016/21:15:00;V_DC_CCU;1;[11]
18.08.2016/21:15:00;V_DC_GW1;4;[11]
18.08.2016/21:15:00;V_DC_GW2;7;[11]
18.08.2016/21:15:00;V_DC_GW3;0;[11]

Programmstart 21:19:45

Code: Alles auswählen

18.08.2016/21:20:00;V_DC_GW1;4;[11]
18.08.2016/21:20:00;V_DC_GW3;0;[11]
18.08.2016/21:20:00;V_DC_CCU;2;[11]
18.08.2016/21:20:00;V_DC_GW2;7;[11]

18.08.2016/21:25:00;V_DC_GW1;7;[11]
18.08.2016/21:25:00;V_DC_CCU;5;[11]
18.08.2016/21:25:00;V_DC_GW2;8;[11]
18.08.2016/21:25:00;V_DC_GW3;0;[11]

18.08.2016/21:25:00;V_DC_GW1;7;[11]
18.08.2016/21:25:00;V_DC_CCU;5;[11]
18.08.2016/21:25:00;V_DC_GW2;8;[11]
18.08.2016/21:25:00;V_DC_GW3;0;[11]
.....

18.08.2016/21:40:00;V_DC_GW1;13;[11]
18.08.2016/21:40:00;V_DC_CCU;14;[11]
18.08.2016/21:40:00;V_DC_GW2;19;[11]
18.08.2016/21:40:00;V_DC_GW3;0;[11]

Bis es dann ab etwa 1 h später langsam wieder herunter auf Normal zurückgeht:
18.08.2016/22:20:00;V_DC_CCU;13;[11]
18.08.2016/22:20:00;V_DC_GW1;10;[11]
18.08.2016/22:20:00;V_DC_GW2;17;[11]
18.08.2016/22:20:00;V_DC_GW3;0;[11]

18.08.2016/22:30:00;V_DC_CCU;4;[11]
18.08.2016/22:30:00;V_DC_GW1;5;[11]
18.08.2016/22:30:00;V_DC_GW3;0;[11]
18.08.2016/22:30:00;V_DC_GW2;5;[11]

Wohlgemerkt - das ist nur ein HPCL-Projekt-Neustart!
Die CCU blieb / bleibt on!

Was also geschieht da beim Neustart?
Und was hier bei nur einer CCU ohne Gateways geschehen würde, muss ich wohl nicht erwähnen!

[ubecker]

Hallo Günter,
machen wir mal hier weiter.
Das verhält sich schon sehr komisch,

HPCL: Einstellungen --> Allgemein:
Aktuelle Werte der ExecEngine speichern / laden: Ja
Keine Hardwarabfrage bei Start der ExecEngine: Ja
Geräteverteilung von ca. 60 Geräten ca. 60/40 (CCU / GW)
DC CCU 17% / GW 10%

dann
Keine Hardwarabfrage bei Start der ExecEngine: NEIN
DC CCU 10% / GW 16%

immer die gleiche Projektdatei übertragen

schon merkwürdig

Gruß Udo

[Familienvater]

Hi,

das mal das Gateway und mal die CCU im DC steigen kann an "roamenden" Geräten liegen, das Funk-Interface, was die "Statusabfrage" an den Aktor schickt, die belastet ihren Dutycycle mit der Anfrage, und ggf. mit der Quittung auf die Antwort.

Der Familienvater

[Daimler]

Hallo Udo,

machen wir mal hier weiter.

Ja, du hast Recht.

Kann leider erst jetzt antworten, da entgegen der Vorhersage hier 'drüben' absolut geiles Wetter war.
(Hoffentlich erblasst da auf der anderen Seite nicht wieder jemand vor Neid.)

Ich habe dein Beispiel hier gerade einmal versucht, im Testsystem nachzustellen.
Aber no way - da hängen zur Zeit neben Wired gerade einmal 5 abfragbare Aktoren dran.
Auch mit einem 10 fachen Neustart des Projektes bringe ich damit den DC nicht wirklich nach oben.

Und ans Produktivsystem traue ich mich am WE - WAF lässt grüßen - nicht ran.
Muss ich kommende Woche einmal testen.

Aber ob der DC jetzt am Gateway, an der CCU oder beiden steigt, ist eigentlich irrelevant.
Die Grundsatzfrage ist:
Warum wird statt der CCU die Hardware beim Neustart des Projektes abgefragt!

Und da hat unser Urlauber anscheinend auch keine Antwort drauf.

Wenn man die Hilfe zu Grunde legt, ist das Verhalten zwar korrekt - erklärt aber das 'Warum' nicht!
Zumindest, was die 1. Option betrifft - die 2. erklärt nach meinem Verständnis eindeutig - Die Hardware wird nicht abgefragt!
Bei Auswahl der Option Aktuelle Werte der ExecEngine speichern/laden
werden bei Beendigung der ExecEngine alle aktuellen Werte der Objekte und Variablen (also auch die Zustände/Werte von Hardwaremodulen) gespeichert und beim nächsten Start der ExecEngine wieder eingelesen. Ein Neustart mit dieser Option ist erheblich schneller, da vor dem Start des normalen Betriebsmodus nicht gewartet wird bis alle aktuellen Werte der Hrdwaremodule abgefragt wurden. Zudem bleiben die Werte der Module die nicht abgefragt werden können (Batteriesensoren wie z.B. Tür/Fensterkontakte) erhalten.
Es werden aber trotzdem im Hintergrund alle Module für die eine Zustandsabfrage möglich ist abgefragt
während die ExecEngine schon im normalen Betrieb läuft.
Vorraussetzung für die Ausführung dieser Option ist, dass der Name des Projekts sich nicht geändert hat und die gespeicherte Datei nicht älter als eine Stunde ist.

Mit der Option Keine Hardwareabfrage bei Start der ExecEngine
wird die standardmässige Abfrage der Hardware beim Start nicht durchgeführt. Diese Option ist nur in seltenen Fällen sinnvoll, z:B. wenn ein PC als Zentrale benutzt wird und dieser häufiger gebootet wird. Dann kann es passieren, dass beim Start die Werte, die im BodCoS stehen nicht richtig sind und daher besser die Werte aus der Speicherung bei der letzten Beendigung benutzt werden.

[Tobias78]

Bei mir steigt der DC durch "Neustart Ausführung" von 1%/2% auf 4%/6%.
Ich nutze auch die Option aktuelle Werte speichern...
Beim Compilieren passiert dies nicht. Den Anstieg finde ich aber auch nicht sonderlich besorgniserregend. Da könnte ich 20x hintereinander neu starten bevor es kritisch wird.
Gruß, Tobias.

[Daimler]

Hi,

dann steht es ja nun 2:1.

In deiner Sig steht ~ 100 Geräte.
Sind da viele Bat-Geräte, die überhaupt nicht abgefragt werden (können)?
Hast Du nur den Yahmi (mit Funkmodul) oder zusätzliche Gateways im Einsatz?

Bei mir ist es definitiv so: 4-5 * Projekt übertragen und ich kann / muss CCU und Gateways neu starten!
Und bei Udo verm. auch.

Wenn man etwas heraustüftelt, ist die Anzahl der Neustarts u. U. schnell erreicht.
Ob ich das jetzt als 'besorgniserregend' bezeichnen möchte.... sei einmal dahingestellt.

Fakt ist m. M. aber, dass HPCL sich nicht an seine eigene Erklärung hält!

Wobei die Option 'Keine Hardwareabfrage bei Start der ExecEngine ' ja nur aussagt, dass beim Start nicht abgefragt wird - vielleicht zieht danach ja trotzdem Option 'Aktuelle Werte der ExecEngine speichern/laden', bei der dann:
Es werden aber trotzdem im Hintergrund alle Module für die eine Zustandsabfrage möglich ist abgefragt, während die ExecEngine schon im normalen Betrieb läuft.
gilt.

[mikewolf99]

Hallo ich bin derzeit noch auf der Lxccu wollte gerne auf yahm und aktueller fw Upgraden
Aber nachdem ich das hier lese ...
Mit 2 lan gw und knapp 450 Geräten ..
Ein Projekt übertragen und dann ..

Mit freundlichen Grüßen
Mikewolf


Sent from my iPhone 6 plus using Tapatalk

[Daimler]

Hi,

gibt es nicht irgendwo die Lan-Gateways im Sonderangebot?

Ich habe zu dem Thema eine Mail an RK geschrieben - schau'n mer mal.

[Tobias78]

Hallo Daimler,
hab auf Deinen Rat hin ein Lan-Gateway im Einsatz, deshalb die 2 Werte. Wirklich brauchen tue ich es jetzt nicht mehr. Dass der Dienst auf dem RPI instabil war war ein anders Problem. Ist seit der Lösung nicht mehr passiert.
Ich habe ca. 20 Wired Geräte, 20 Strom-betriebene Funk, Rest Batteriebestriebene-Funk.
Beim Compilieren und Übertragen habe ich bisher nicht beobachtet das der DC sonderlich (>1%) ansteigt. Beim Neustart waren es 3-4%. Kann aber sicher an meiner nicht vergleichbaren Installation liegen.
Auf der CCU2 hatte ich oft Probleme mit Verbindungsfehlern nach Neustarts. Hab dann sehr genau geschaut welche Makros nach dem Reboot sofort loslegen und hab in etlichen eine Verzögerung nach Reboot eingestellt. Verbindungsprobleme kamen bei mir in Kombination mit gestccusysvar setccusysvar und getsite aufrufen. Hat natürlich nix mit dem DC zu tun... das Ergebnis waren aber ebenfalls Übertragungsfehler zu Funk-Komponenten im syslog.

@mikewolf: yahm läuft granatenmäßig gut. Die Homeputer Probleme haben auch nichts mit yahm zu tun. Für Homeputer ist yahm einfach ne CCU2.
Gruß, Tobias.

[Daimler]

Hi,

da haben wir die Ursache der Differenz beim DC !:

Bei dir sind es letztendlich '20 Strom-betriebene Funk...', welche den DC beim Projektstart durch Abfrage in die Höhe treiben (können).
Und diese dann verm. noch auf CCU und das sep. Gateway verteilt.
Da kann auch nicht viel geschehen.

Wobei ich das jetzt nicht so ganz verstehe:

Bei mir steigt der DC durch "Neustart Ausführung" von 1%/2% auf 4%/6%......Beim Compilieren passiert dies nicht.

Beim Compilieren und Übertragen habe ich bisher nicht beobachtet das der DC sonderlich (>1%) ansteigt. Beim Neustart waren es 3-4%.

Was meinst du mit "Neustart Ausführung"?

Denn Udo und ich sprechen von 'Compilieren und Übertragen' !

Wirklich brauchen tue ich es jetzt nicht mehr. Dass der Dienst auf dem RPI instabil war war ein anders Problem.

Meins läuft jetzt auch seit exakt einer Woche - allerdings develop.
Auf dem Test-Raspy habe ich die stable, und hier musste ich gestern den Raspy komplett aus- und wieder einschalten, da das Modul nicht mehr hoch kam!
Habe allerdings seit dem letzten WE keine Updates mehr gemacht.

Und auch ich sehe dieses Problem definitiv nicht beim Yahmi, eigentlich auch nicht bei HPCL, sondern in der Kombination neue FW und HPCL.
Bisher ist (mir) dies nicht aufgrund der inkonsequenten Umsetzung des DCs seitens EQ3 in älteren FWs aufgefallen.