@haselchen Danke, ja, nach der ersten Einträge hatte ich das verworfen, du hast aer recht, ist der gleiche Fehler. Dann biete ich in dem anderen Tread mal an auf meinen System zu suchen wenn das hilft.

@arteck
.. ja, gerne ein Beispiel... ich habe einen Datenpunkt der liefert im Sekundenbereich Telegramme von den Kollektoren, da möchte ich überhaupt nicht im Sekundenbereich Aktoren steuern sondern eher gleitend regeln. Zb. im Minutenbereich.. Bei PID Reglern wäre dies dann die einstellbare Delta-T Regelung.

Ich sehe mir im nächsten Schritt gerne das mit dem Node-JS upgrade an.. generell finde ich es aber interessant wie Diskussionen von der eigentlichen Fragestellung abdrifften ... denn dies war ja ... warum verhalten sich die Schedule Jobs beim Boot falsch.

@mcm57 Ich habe das dort als Issue auf deinen Rat hin aufgenommen, ich hoffe dies war vom Ablauf ok,

@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.

@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 Vielen Dank für die tollen Antworten und 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.

@homoran ich hatte die Version ja auf anraten hochgezogen, mir ist aber gestern bei der Erstellung des Issues im Debug Log folgendes aufgefallen, was auch durch dein Log hier nochmals bestätigt wird:

Mein Log fängt direkt mit den Meldungen der Function an und nicht mit der Initialisierung des Javascript Adapters. Jetzt kann es natürlich sein, dass Meldungen auf meinem System nur einfach zeitlich vorher in den Log kommen. Ich vermute aber eher, dass der Adapter aus irgendeinem Grund noch nicht vollständig gestartet ist,

Shutdown at 13:55:35 -> Boot at 13:59:24
2024-04-17 13:55:35.534 - ^[[32minfo^[[39m: javascript.0 (2626) terminating
2024-04-17 13:59:24.355 - ^[[31merror^[[39m: javascript.0 (953) script.js.Technik.Heizung.BootTestScript: In Function
2024-04-17 13:59:24.410 - ^[[31merror^[[39m: javascript.0 (953) script.js.Technik.Heizung.BootTestScript: In Function
2024-04-17 13:59:24.441 - ^[[31merror^[[39m: javascript.0 (953) script.js.Technik.Heizung.BootTestScript: In Function
2024-04-17 13:59:24.475 - ^[[31merror^[[39m: javascript.0 (953) script.js.Technik.Heizung.BootTestScript: In Function
2024-04-17 13:59:24.492 - ^[[31merror^[[39m: javascript.0 (953) script.js.Technik.Heizung.BootTestScript: In Function

Vielen Dank fürs testen, somit scheint es kein allgemeiner Fehler sondern eher eine ganz spezielles Zusammenspiel beim booten zu sein. Kann man irgendwo die Reihenfolge der Adapter beim Starten vorgeben?

@mcm57 Ich habe das dort als Issue auf deinen Rat hin aufgenommen, ich hoffe dies war vom Ablauf ok,

@mcm57 ich folge mal deinem Rat und mache dies unter dem Adapter als Issue auf.

Ich habe eben noch folgenden Test gemacht:

function Test1() {
    log('In Function','error');
    setState('0_userdata.0.Allgemein.TestBoot', 'test', false);
};


log('Script Test1 gestartet:','error');


setTimeout(function(){schedule("*/10 * * * * *", Test1 )},50000);

Hier müsste beim Boot im Log ja als erstes der Log mit dem Text: "Script Test1 gestartet" erscheinen und dann deutlich später die Meldung: "In Function" alle 10s.

Das Ergebnis beim Boot sieht aber wie Folgt aus: 12:51:32 ... letzte Meldung vor dem Shutdown und dann um 12:55:26.076 direkt die Meldung "In Function" ... sieht so aus als würde die schedule Anweisung komplett ignoriert.

2024-04-17 12:51:32.643 - ^[[32minfo^[[39m: nina.0 (903) terminating
2024-04-17 12:55:26.076 - ^[[31merror^[[39m: javascript.0 (954) script.js.Technik.Heizung.BootTestScript: In Function
2024-04-17 12:55:26.140 - ^[[31merror^[[39m: javascript.0 (954) script.js.Technik.Heizung.BootTestScript: In Function
2024-04-17 12:55:26.184 - ^[[31merror^[[39m: javascript.0 (954) script.js.Technik.Heizung.BootTestScript: In Function

Vielen, Vielen Dank für die Tipps und Ideen!

@thomas-braun said in maximum of 1000 setState during boot:

iob nodejs-update

Update durchgeführt, aktuelle Version ist jetzt: v.18.20.2, Fehler ist aber auch nach dem Update da.

Noch eine zusätzliche Info, wenn ich nach dem start des IOBrokers ein
iobroker restart javascript.0 läuft alles sauber.

Evtl. braucht der JavaScript Adapter andere Dienste die zu diesem Zeitpunkt noch nicht verfügbar sind ... nur eine Idee.

@asgothian
Hi, nun zu der Fehlermeldung ... sorry, ja dies ist im Text missvertständlich ausgedrückt. Ich hatte ein kleines Testscript gebaut, bei dem einfach nur alle 10s über die LogDirective die Meldung: in Function ausgegeben wird.

Es gibt leider keine Fehlermeldung ausser maximum 1000 setstate reached. Die Meldungen die zu sehen sind, sind die Ausgaben des Scripts, die eigentlich ja nur 6x Minute erscheinen dürfen.

@djmarc75 easy to explain.... more english speaker the German speaker ... to reach a bigger audience. Thx. for the hint ... doesn't help anything for the question

@arteck
.. ja, gerne ein Beispiel... ich habe einen Datenpunkt der liefert im Sekundenbereich Telegramme von den Kollektoren, da möchte ich überhaupt nicht im Sekundenbereich Aktoren steuern sondern eher gleitend regeln. Zb. im Minutenbereich.. Bei PID Reglern wäre dies dann die einstellbare Delta-T Regelung.

Ich sehe mir im nächsten Schritt gerne das mit dem Node-JS upgrade an.. generell finde ich es aber interessant wie Diskussionen von der eigentlichen Fragestellung abdrifften ... denn dies war ja ... warum verhalten sich die Schedule Jobs beim Boot falsch.