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

@bertderkleine
Ja, stimmt, ich tast mich mal langsam ran und vielleicht hilft auch der Mittelweg. Erstmal habe ich dein Script heute zum laufen gebracht. Ich habe die Logik zwar noch nicht ganz verstande, aber ich taste mich mal ran.
Folgende Änderungen habe ich mal reingebracht:

1. Zwei weitere Datenpunkte:
   const NetzLaden = '0_userdata.0.Technik.Strom.Speicher.MSA-280024340941.NetzLadung';
   const Entladen = '0_userdata.0.Technik.Strom.Speicher.MSA-280024340941.Entladung';

Wenn der erste auf True ist, dann wird zwangsweise vom Netz geladen
Wenn der zweite auf True ist, dann wird der Akku entladen. Mit diesem kann ich in einem ersten Schritt das Entladen am Tage blockieren und die Entladung zu einem späteren Zeitpunkt starten (Wenn der Preis oben ist)

In einem anderen Script habe ich nun zB. die Idee, die Tibberpreiskurve auszuwerten und zB. 2h vor dem max Preis && nach 18:00Uhr die Entladung zu starten. In der Regel ist der Akku dann durch den Verbrauch am Abend bis 24:00 Uhr leer.

Den Code habe ich wie folgt angepasst. Wenn du magst, kannst du das natürlich übernehmen oder an eine bessere Stelle überführen.

Zusätzlich habe ich was eingebaut, dass der Ladestrom reduziert wird, wenn die obere Ladegrenze erreicht ist. Ich meine, dies beobachtet zu haben, dass Hoymiles selber reduziert wenn es an die obere Grenze geht.

Ich berichte von meinen weiteren Versuchen

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

@bertderkleine
Ja, stimmt, ich tast mich mal langsam ran und vielleicht hilft auch der Mittelweg. Erstmal habe ich dein Script heute zum laufen gebracht. Ich habe die Logik zwar noch nicht ganz verstande, aber ich taste mich mal ran.
Folgende Änderungen habe ich mal reingebracht:

1. Zwei weitere Datenpunkte:
   const NetzLaden = '0_userdata.0.Technik.Strom.Speicher.MSA-280024340941.NetzLadung';
   const Entladen = '0_userdata.0.Technik.Strom.Speicher.MSA-280024340941.Entladung';

Wenn der erste auf True ist, dann wird zwangsweise vom Netz geladen
Wenn der zweite auf True ist, dann wird der Akku entladen. Mit diesem kann ich in einem ersten Schritt das Entladen am Tage blockieren und die Entladung zu einem späteren Zeitpunkt starten (Wenn der Preis oben ist)

In einem anderen Script habe ich nun zB. die Idee, die Tibberpreiskurve auszuwerten und zB. 2h vor dem max Preis && nach 18:00Uhr die Entladung zu starten. In der Regel ist der Akku dann durch den Verbrauch am Abend bis 24:00 Uhr leer.

Den Code habe ich wie folgt angepasst. Wenn du magst, kannst du das natürlich übernehmen oder an eine bessere Stelle überführen.

Zusätzlich habe ich was eingebaut, dass der Ladestrom reduziert wird, wenn die obere Ladegrenze erreicht ist. Ich meine, dies beobachtet zu haben, dass Hoymiles selber reduziert wenn es an die obere Grenze geht.

Ich berichte von meinen weiteren Versuchen

@bertderkleine danke für dein tolles Script, ich werde dies mal ausprobieren und im nächsten Schritt erweitern. Ich bin zwar weit nicht so gut in der Programmierung, aber wird schon klappen.
Da ich einen dynamischen Tarif habe, würde ich folgende Funktion noch reinbringen.

1. Entladung zu einem Zeitpunk wo der Bezugspreis am maximal ist (meist Abends & Morgens)
2. Netzladung bei niedrigen Preisen

Ich kann ja berichten, wird aber ein paar Tage dauern.
Liebe Grüße
Helmut

@mcm1957
Hi, bist du mit dem MS A2 schon weitergekommen? Ich wollte mir in den nächsten Wochen ebenfalls eine Box kaufen, brauche aber, wahrscheinlich wie du eine externe Steuerungsmöglichkeit.

Ich habe im Netz schon eine Möglichkeit gefunden, wie ich anstatt des Shelly meinen SMA Energy Meter nutzen kann um die Werte für eine mögliche Nulleinspeisung zu senden.
Da ich den Tibber Adapter nutze, müsste man der Box über eine API, OpenDTU, MQTT oder ähnliches, einfache Befehle wie
Jetzt laden mit einer Watt Zahl und jetzt entladen mit einer Watt Zahl senden können. Somit könnte man an den beiden Niedrigpreis Zonen (meist Nachts/Mittags) in Abstimmung mit der Solarladung, die Box optimal nutzen.

Somit könnte man die teureren Zone Morgens und Abends optimal reduzieren und kämme auf 2 Ladungen/Entladung je Tag. Dies dürfte zu einem schnellen ROI beitragen.

Ich wollte nachher auch mal Kontakt zu Hoymils aufnehmen und mal sehen was der Support dort anbietet, vielleicht geht es ja über die DTU.
Viele Grüße
Helmut

Liebes Forum,
vielleicht hat jemand von euch eine Idee. Ich habe den I2C Adapter installiert, ein Bus ist auf den Standard GPIO2/3 des PI4 angeschlossen, einen zweiten Bus habe ich auf GPIO22/23 angeschlossen.
In der Config.txt ist folgende Zeile:
dtparam=i2c_arm=on
dtoverlay=i2c-gpio,bus=2,i2c_gpio_sda=22,i2c_gpio_scl=23

i2cdetected findet:
i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- 23 -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

i2cdetect -y 2

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Somit auf Bus 1 ein Device auf Adresse 23 und an Bus 2 ein Device auf 44.

Im IOBroker habe ich nun einen I2C Adapter (Instanz 0), dieser findet bei Scan auf Bus 1, das Device auf 23 - soweit so gut.
Weiterhin habe ich eine 2te Instanz installiert (habe ich im Forum gelesen), dieser findet bei einem Scan auf Bus2 aber nun nicht das Device mit der 44 sondern nur wieder das Device mit der 23.

Für mich sieht es so aus, als das immer nur BUS 1 gescant wird. Hat dazu jemand evtl. eine Idee?
Liebe Grüße
Helmut

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