UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Mabbi]

@maxclaudi

Dafür müsste das hier doch schon reichen oder ?

Ich schreinbe extra mal ne -1 in den set vorab, weil bei mir bleibt da manchmal eine 1 drin obwohl es ja eigentlich immer durch dein script auf -1 gesetzt wird.

Update:

Nun noch etwas verfeinert, beim Starten des scripts werden beide einmal gecheckt, danach nur noch wenn einer der trigger auslöst:

Und das Ergbnis: Sir, yes Sir

[maxclaudi]

-1 muss nicht manuell gesetzt werden, das müsste nach einmaligen setzen automatisch auf -1 gestzt werden.
Bei "falls" würde ich den "Wert" vom trigger-Baustein verwenden.

[Mabbi]

@maxclaudi

So ?

Zur -1, wenn der Zendure das mal selber gemacht hat steht im Set auch gerne mal eine 1 bei mir, warum auch immer.
Kann aber auch daran liegen, dass ich dein script oft neu starte, wenn ich mal wieder einen der Akkus durch 'Übertaktung' beim Testen eingefroren habe....

Ich mach mal ein screeny, wenn es mal wieder passiert. Dann können wir beide darüber grübeln, warum das so ist....eigentlich weiss ich nicht präzise, wo es herkommt.

Da Du (afaik) aber auf Change triggerst, nützt es nicht mit diesem kleine script eine 1 auf eine 1 zu schreiben.
Deswegen die -1, und dann mit Verzögerung die 1. Könnte man halt noch schöner mit einer Logik machen, ist imho aber hier wirklich zu viel Schönbauerei.

[maxclaudi]

@Mabbi
ja so, was den Trigger-Wert betrifft.

edit: Finde Deine Lösung etwas zu "umfangreich" kompliziert.
Ein Trigger für beide Akkus gleichzeitig würde auch reichen und im Trigger-Block arbeiten. Für was extra "Uebergabe_1" und 2 usw.
Wie Du möchtest, wenn's funktioniert.

[Mabbi]

@maxclaudi

Da gebe ich Dir recht.

Mir ist in den Blocklys einfach immer noch nicht klar, wann eine Variable local (z.B. in einer function) oder global ist.
Deswegen trenne ich die aus Prinzip immer auf.

Das Bild zeigt das js zum Blockly mit getrennten Variablen oder mit einer Variable.

Beides taucht oben und somit global(?) auf.

Ich habe mal irgendwo gelesen, dass nichts in js parallel laufen kann, aber mir widerstrebt es rein aus technischer Sicht, es so zu machen. Nenn es eine Berufskrankheit.

[maxclaudi]

@Mabbi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi

Da gebe ich Dir recht.

Mir ist in den Blocklys einfach immer noch nicht klar, wann eine Variable local (z.B. in einer function) oder global ist.
Deswegen trenne ich die aus Prinzip immer auf.

Das Bild zeigt das js zum Blockly mit getrennten Variablen oder mit einer Variable.

Beides taucht oben und somit global(?) auf.

Ja.
Alles, was du in Blockly als Variable ohne lokalen Blockscope anlegst, landet im generierten JS oben im Script und ist damit global innerhalb dieses Scripts.
Nicht global systemweit – nur im eigenen Script.

Ich habe mal irgendwo gelesen, dass nichts in js parallel laufen kann, aber mir widerstrebt es rein aus technischer Sicht, es so zu machen. Nenn es eine Berufskrankheit.

JS läuft immer single-threaded, aber in der ioBroker-Sandbox ist fast alles asynchron. Es läuft also nicht parallel – es wird nur über die Event-Loop nacheinander abgearbeitet.

[Daniel 8]

@maxclaudi

Vielen Dank für das ausführliche oben beschriebene Verhalten von smartMode.

Es gibt wirklich keine konstante wann er umschaltet. Hatte erst mal.4 Tage ohne umschalten und dann kann sein das er 3 mal am tag umschaltet

[Mabbi]

Hi,

ich habe mal eine sql Archivierung auf 0_userdata.0.zendure.HOAXXXXXXXXXXXXXXX.zendureSmartMode.smartModeInfo gepackt.
Ist schon ernüchternd, wie oft das script ihn wieder auf Smartmode 1 zurückholt:

Jeder senkrechte Strich ist ein drop von 1 auf 0 und dann recover durch mein kleines script.
Es scheint total random zu passieren btw, in der REgel aber ca. 3-4x pro Tag.

Die Ansteuerung des Akku läuft derweil gut:

[maxclaudi]

@Mabbi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi
Zur -1, wenn der Zendure das mal selber gemacht hat steht im Set auch gerne mal eine 1 bei mir, warum auch immer.

Ist eigentlich nicht möglich. Zendure oder API ändert den dpSet nicht.

Kann aber auch daran liegen, dass ich dein script oft neu starte, wenn ich mal wieder einen der Akkus durch 'Übertaktung' beim Testen eingefroren habe....

Das wird es sein.
Der Datenpunkt kann nur über Dich bzw. Dein(e) Script(s) geändert werden.

Ich mach mal ein screeny, wenn es mal wieder passiert. Dann können wir beide darüber grübeln, warum das so ist....eigentlich weiss ich nicht präzise, wo es herkommt.

Nicht nötig. Mir ist das mögliche Fehlverhalten bewusst.

Der Datenpunkt wird, wenn nicht schon vorhanden, bei Scriptstart automatisch angelegt und mit "-1" initialisiert.
Existiert der Datenpunkt schon, dann wird er iob-typisch nicht neu erstellt und somit auch nicht bei scriptstart mit "-1" initalisiert.
Wurde nun zuvor eine 1 (oder 0) gesetzt und es kam zu einem vorzeitigem Abbruch des Scripts, dann "könnte" der letzte Wert gesetzt bleiben.
Danke für Dein Feedback.

Update 26.11.2025 12:20h– Neues Script
im Eingangspost.

Bisher:

• Bei Script-Start wird wenn dpSet nicht vorhanden ist: dpSet erstellt und mit -1 initalisiert.
  Wenn schon vorhanden: keine -1 Initialisierung.
• Jeder Wert wird nach SET und aufgerufenem POST auf -1 zurückgesetzt. Unabhängig ob POST erfolgreich war oder nicht.

Neu/zusätzlich:

• Bei Script-Start wird immer mit -1 initalisiert.
• alle dpSet-Werte werden spätestens beim nächsten GET wieder auf -1 gesetzt

Durch Queue sind Race Conditions ausgeschlossen.

Damit ist ein manuelles setzen von "-1" nicht nötig und (war auch) nicht vorgesehen.

[maxclaudi]

@Daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi

Vielen Dank für das ausführliche oben beschriebene Verhalten von smartMode.

Es gibt wirklich keine konstante wann er umschaltet. Hatte erst mal.4 Tage ohne umschalten und dann kann sein das er 3 mal am tag umschaltet

Die Umschaltung von SmartMode passiert tatsächlich von Cloud UND Firmware.
Das ist nicht ohne weiteres von Zendure zu lösen.
Dafür müsste Firmware angepasst und ausgerollt werden.
SmartMode war/ist für eine bestimmte Zeit der Steuerung für bestimmte Ereignisse gedacht und nicht als stetiger Flag.
Wenn auch von uns so gewünscht.
Macht nichts, solange es so funktioniert und tatsächlich in RAM geschrieben wird.