maximum of 1000 setState during boot

[Wildbill]

@djmarc75 Gibt es einen Grund, warum logikverarbeitende Adapter da als Erstes gestartet werden? Es gibt ja doch einige Adapter, bei denen zum Start eben nicht alle Werte der „Wahrheit“ entsprechen. Die Logik da als Letztes zu starten erscheint mir da eher „logisch“. Oder gibt es gute Gründe, die ich gar nicht sehe?

Gruss, Jürgen

[DJMarc75]

@wildbill sagte in maximum of 1000 setState during boot:

warum logikverarbeitende Adapter da als Erstes gestartet werden?

kann ich Dir leider nicht beantworten, habe mich damit noch nicht beschäftigt.

[mcm1957]

@wildbill
Einer der Gründe ist (wahrscheinlich) dass man sicherstellen will, dass eine Logik anspricht wenn der Adapter einen (neuen) Wert schreibt. Wird der javascript erst noch dem Adapterstart gestartet dann kann er ev auf das Setzen eines Zustands (via subscription) nicht mehr reagieren weil er das Setzen gar nicht mitbekommt.

Bezüglich device-watcher rege ich an da einen Feature Request beim Adapter zu erstellen. Es erscheint mir sinnvoll wenn der Devicewatcher selbst eine gewisse Zeit nach seinem Start wartet bevor er prüft / alamiert.

Und ja man kann die Startsequenz im grob einstellen. Es gibt 3 Tiers die in der Reihenfolge 1 - 2 - 3 gestartet werden. Aller Adapter innerhalb einers Tiers werden in nicht festgelegter Reihenfolge gestartet. Diese Einstellung kann vom User vorgenommen werden wobei es wahrscheinlich weniger Sinn macht eine vis in Tier 1 zu legen :-).

[Wildbill]

@mcm57 Danke für die Erläuterungen. Issue bzw. feature request habe ich bei device watcher mal erstellt.

Bezüglich JavascriptAdapter. Genau deshalb beende ich ihn ja vorab manuell. Gewisse Adapter bzw. Geräte haben die Angewohnheit, beim Start kurz mal auf 0 zu springen und dann erst wieder auf den korrekten Wert. Ich meine, bei Homematic-Zwischensteckern mit Strommessung war das bei mir so bei aktueller Leistung und kumuliertem Wert. Das hat eben Scripte dann falsch ausgelöst und beim Sourceanalytix jedesmal die Meldung gebracht, der Wert hätte sich resettet. Da war/ist es mir lieber, bei Systemstart erstmal quasi die erste Änderung nicht mitzubekommen und dann eben erst, wenn sich alle "beruhigt" hat und die Werte "stabil" sind.
Vielleicht mache ich bei Gelegenheit nochmal einen Test und beende keinen Adapter manuell und schaue, wie es sich mittlerweile verhält. Denn ich mache das bestimmt schon seit 1-2 Jahren so (problemlos).

Gruss, Jürgen

[mcm1957]

@wildbill
Ich glaub es wird schwierig da eine für alle System passende Lösung zu finden. Wenn es aber Adapter gibt die beim Start den Wert mal so auf 0 setzen, dann kann man da ruhig auch ein Issue erstellen damit der Maintainer schaut ob es dafür einen technischen Grund gibt oder ob nur irgendwo eine an sich unnötige Initialisierung erfolgt.

@peterfido
Ev. check mal ob ev. beim Start von ioBroker im Zuge eine Bootvorgangs die Systemzeit (noch) nicht stimmt (RTC ev defekt / verstellt?) und diese dann erst zeitnahe aktualisisert wird z.B. durch NTP Daemon. Ist aber nur so mal ein Idee ohne dass ich sowas schon mal erlebt hätte.

[haus-automatisierung]

@hschief sagte in maximum of 1000 setState during boot:

auch die Information, dass der Fehler bei euch nicht reproduziert werden kann, Ich werde das Issue in GitHub erstmal schliessen und weiter forschen um das Problem einzugrenzen. Ich berichte was sich weiter ergibt.

Habs noch nicht probiert zu reproduzieren. Lass gerne offen und teile weitere Erkenntnisse im Issue

[peterfido]

@mcm57 ich habe da keine Probleme mit der Uhrzeit. Alle VMs nutzen die RTC vom Proxmox-Host.

Mir kam nur die Idee, ob es evtl. beim TO da Probleme geben könnte.

[hschief]

@peterfido

Solved: In der Tat war der NTP beim boot zu langsam und die Zeit nicht richtig gesetzt. Als Lösung habe ich das Startscript vom IOBroker im systemd deaktiviert. Anschließend dann im /etc/local.rc sichergestellt das die Uhrzeit mittels ntpdate gesetzt wird und danach wird der IObroker gestart.

Vielen Dank für eure Unterstützung!!!!!!!

[haus-automatisierung]

@hschief Und dann wird die Zeit korrigiert und alle „verpassten“ Schedule-Events in der Zeitdifferenz ausgelöst? Das wäre ja auch nicht so schön bzw. ein Bug aus meiner Sicht.

[mcm1957]

@haus-automatisierung said in maximum of 1000 setState during boot:

@hschief Und dann wird die Zeit korrigiert und alle „verpassten“ Schedule-Events in der Zeitdifferenz ausgelöst? Das wäre ja auch nicht so schön bzw. ein Bug aus meiner Sicht.

Müsste man genauer ansehen.
Kann gut seind ass der ntp daemon keinen Sprung macht sondern die Zeit "schneller" in kleineren Schritten vorsetzt. Dann hätte der scheduler keine Chance.

Aber im Prinzip könnten "man" das ja testen indem man manuell die Zeit umsetzt. Wär aber dann ja was was im O/S oder node zu fixen wäre.

[Thomas Braun]

@mcm57 sagte in maximum of 1000 setState during boot:

Kann gut seind ass der ntp daemon keinen Sprung macht sondern die Zeit "schneller" in kleineren Schritten vorsetzt.

Ja, genau das macht der ntp im Normalfall. Die Zeit wird gestaucht oder gedehnt, bis irgendwann das Delta zwischen der Zeit vom ntp-Server und der lokal geführten Uhrzeit minimal ist. Das kann u. U. auch mehrere Tage dauern. Der Prozess läuft dauernd im Hintergrund und 'groovt' sich auf die gemessenen Abweichungen ein. Je ungenauer die Lokale Eieruhr tickt desto länger dauert das auch.
Harte Zeitsprünge sind zu vermeiden.

[hschief]

@haus-automatisierung Hi, ich setzt direkt nach dem booten die Zeit,

# set the clock before iobroker is start
# wait 20s for network
/usr/bin/sleep 20
/usr/sbin/service ntp stop
/usr/sbin/ntpdate -s x.x.x.x
/usr/sbin/service ntp start

somit gibt es zu diesem Zeitpunkt noch keine Events die recorded werden. Nachdem die Zeit aktualisiert ist, starte ich den iobroker:

/usr/sbin/service iobroker start

Ab diesem Zeitpunkt laufen die events dann in die states und werden durch die scripte sauber verarbeitet.

Ich war bisher der Meinung, dass der ntp service beim booten die Zeit auch direkt richtig setzt, ich habe in diesem Fall gelernt, dass dies mal bis zu 5 Minuten dauern kann.

[Homoran]

@mcm57 sagte in maximum of 1000 setState during boot:

Müsste man genauer ansehen.
Kann gut seind ass der ntp daemon keinen Sprung macht sondern die Zeit "schneller" in kleineren Schritten vorsetzt. Dann hätte der scheduler keine Chance.

das sieht man doch immer wieder in logs nach/während des Neustarts.
Da springt dann wirlich die Zeit

[mcm1957]

@homoran
OK, dann hat der Scheduler damit ein Problem ...

Keine Ahnugn ob das ein node Modul ist, ein npm Modul eines anderen Entwicklers oder ioB Eigenbau. Dementsprechend ev. an der passenden Stelle ein Issue anlegen.