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

Hallo,
ich habe auch eine Consori Fritteuse gekauft, die App eingerichtet und dann den Adapter. Dis App funktioniert, der Adapter zeigt im LOG aber die gleiche Fehlermeldung wie bei FoxMulder & MacGyver.
Scheint evtl. bei allen neuen Einrichtungen zu passieren.
Liebe Grüße

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

Hallo,
ich habe auch eine Consori Fritteuse gekauft, die App eingerichtet und dann den Adapter. Dis App funktioniert, der Adapter zeigt im LOG aber die gleiche Fehlermeldung wie bei FoxMulder & MacGyver.
Scheint evtl. bei allen neuen Einrichtungen zu passieren.
Liebe Grüße

Hi,
Ich habe jetzt mal die Idee von Paul getestet und ebenfalls auch mal den Alias DP komplett gelöscht und mit neuem Namen neu angelegt.
Leider bleibt das merkwürdig Verhalten erhalten.
Ich hatte gestern wieder den folgenden Output beim lesen.
2025-08-12 08:02:36.996 - warn: javascript.0 (187304) script.js.Schlafzimmer_Helmut.Taster: Licht =OFF Speaker =start MqttValueTasmota =OFF
2025-08-12 22:09:15.347 - warn: javascript.0 (187304) script.js.Schlafzimmer_Helmut.Taster: Licht =OFF Speaker =stop MqttValueTasmota =OFF
2025-08-12 22:17:17.155 - warn: javascript.0 (187304) script.js.Schlafzimmer_Helmut.Taster: Licht =true Speaker =stop MqttValueTasmota =ON
Zwischen 22:09 und 22:17 habe ich den Alias Datenpunkt über die VIS auf true gesetz -> der write DP sendet dann über MQTT/CMND an Tasmota, Tasmota antwortet über STAT und der Read DP liefert OFF, was dann von dem Alias richtig umgesetzt wird.

Nach einer unbestimmten Zeit oder nach einem unbestimmten Ereignis liefert der Alias dann allerdings wie in dem Log zu sehen Licht=OFF und nicht mehr false obwohl dies entsprechend der Alias Konvertierung gar nicht passieren darf, denn dort steht: read => val=='ON', somit dürfte in diesem Fall nie ein True erscheinen.

{
  "common": {
    "name": "Licht_WC",
    "desc": "Manually created",
    "role": "state",
    "type": "boolean",
    "read": true,
    "write": true,
    "def": false,
    "alias": {
      "id": {
        "read": "0_userdata.0.Schlafzimmer_Helmut.DC4F22803CA2.stat.power1",
        "write": "0_userdata.0.Schlafzimmer_Helmut.DC4F22803CA2.cmnd.power1"
      },
      "read": "val=='ON'",
      "write": "val ? 'ON':'OFF'"
    }
  },
  "type": "state",
  "native": {},
  "_id": "alias.0.SchlafzimmerHelmut.Licht_WC",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.helmut",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.helmut",
  "ts": 1754551409965
}

Gelesen wird wie folgt:

var IstStateLicht = getState(ObjIDLicht).val;
    var IstStateSpeaker = getState(ObjIDSpk).val;
    var IstMqttObject = getState(ObjIDLicht2).val;

    log('Licht =' +IstStateLicht +' Speaker =' +IstStateSpeaker + ' MqttValueTasmota =' +IstMqttObject,'warn');

@paul53 Vielen Dank für die schnelle Antwort, die Prüfung auf "ON" / "on" ist mehr der Sicherheit geschuldet. Ich hatte vorher nur "ON" & "OFF", da war der beschriebe Fehler aber auch da.
Interessant ist ja eigentlich, dass im IOBroker Admin dies richtig dargestellt wird, nur bei dem getState wohl falsch dargestellt wird
Dein Vorschlag wäre: val=='ON' || val=='on'?true : val=='OFF' || val =='off'?false : null
Richtig?

Re: Frage zu Alias
Hi, hat dazu von Euch jemand eine Idee, ich stehe ein wenig auf dem Schlauch.
Ich habe 2 DP, einen für Read, einem für write (Tasmota) beide Datatype String

1. 0_userdata.0.DC4F22803CA2.stat.power1 => MQTTClient ( subscribe stat/DC4F22803CA2/POWER1) changes only, Exactly once
2. 0_userdata.0.DC4F22803CA2.cmnd.power1=> MQTTClient ( publish cmnd/DC4F22803CA2/POWER1) Exactly once, retained

Dazu gibt es einen Alias DP. Datatype boolean

1. Read = link auf 0_userdata.0.DC4F22803CA2.stat.power1 , Read convert function: val=='ON'?true:val=='on'?true:val=='OFF'?false':val=='off'?false:null
2. Write == link auf 0_userdata.0.DC4F22803CA2.cmnd.power1, Write convert function: val?'ON':'OFF'

Nun das Problem. Die Adminoberfläche zeigt zu jedem Zeitpunkt für den Alias DP immer den richtigen Status True/False an. Wenn ich den Alias DP in einem Script auslese

var xxx = getState('aliasDP').val.

erhalte ich in einigen Fällen kein False zurück sonder auch schonmal "OFF" und nicht das Ergebnis des Convert. Hatt dazu vielleicht jemand eine Idee?

Vielen Dank
Helmut

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