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

[maxclaudi]

@daniel-8
Das sind die verschiedenen Energy Plan (Energiepläne), die es in der App zur Auswahl gibt, wie

• Smart CT Mode
• Scheduled/Timer Mode
• Smart Matching Mode
  usw.

[Daniel 8]

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

@daniel-8
Das sind die verschiedenen Energy Plan (Energiepläne), die es in der App zur Auswahl gibt, wie

• Smart CT Mode
• Scheduled/Timer Mode
• Smart Matching Mode
  usw.

Die App ist ja bei mir ohne Funktion, da ich dem solarflow den InternetZugang über die fritzbox gesperrt habe. Und die Pläne gibt es ja nur in hems und das ist schon lange aus. Mache alles über mqtt

[maxclaudi]

@daniel-8
es könnte dennoch damit zusammenhängen.
An Deiner Stelle würde ich den Internetzugang noch mal frei geben.
Die App nutzen und sicherstellen, dass wirklich kein Energieplan in der App zuletzt aktiv war und auch nicht ist.
Ich kann mir nicht vorstellen, dass es nur HEMS gibt?
Es gibt doch CT-Mode oder ähnlich, auch ohne aktives HEMS?
Oder so eine Einstellung mit fester Energieabgabe/Zeitplan usw.
Das würde ich noch einmal prüfen und mich überzeugen, dass wirklich alles deaktiviert ist.

Edit/PS: ich bin komplett offline, ohne App.
Kann bei mir dennoch CT-Modus und andere Modi nutzen, sofern sie keine Cloud-Daten erfordern funktioiert das auch.
Nutze ich nicht.
Es war aber so (ist auch nachvollziehbar), dass die letzten Einstellungen in der Firmware gespeichert sind und genutz werden (wollen).

[Daniel 8]

@maxclaudi

Also ich habe jetzt in Hems den grundlastmodus genommen und alle Zeitpläne gelöscht. Bei den normalen akku Einstellungen gibt es keine Zeitpläne. Was mir auch aufgefallen ist, das in sporadischen Abständen der mqtt von 1 auf 0.geht mit der http Abfrage. Weiß nicht warum er da die Verbindung verliert

Sowas wie ct oder so gibt es bei den neuen Geräten ohne hems nicht.

[maxclaudi]

@daniel-8
Tipp: Du könntest dich an den Support wenden und darauf hinweisen, dass du die zenSDK nutzt und wie empfohlen smartMode:1 gesetzt hast, damit die Parameter ins RAM statt in den Flash geschrieben werden.
Erkläre, dass smartMode:1 immer wieder von allein (Intervall ca.) wieder auf smartMode:0 wechselt.
Frage „warum?“ und bitte um eine Lösung.
Kannst darauf hinweisen, dass Du mehrere Leute mit einem SF2400AC kennst, bei denen smartMode:1 normalerweise dauerhaft gesetzt bleibt.

[Daniel 8]

Hier die Antwort von Zendure.

Sehr geehrter Kunde,

vielen Dank für Ihre Geduld. Wir sind stets bemüht, Ihnen den bestmöglichen Service zu bieten.

Bezüglich Ihres Problems empfiehlt Ihnen unser technisches Team: Bitte posten Sie Ihre Frage im offiziellen GitHub-Forum. Dort wird Ihnen gerne weitergeholfen.

Vielen Dank für Ihr Vertrauen und Ihre Geduld. Wir entschuldigen uns aufrichtig für etwaige Unannehmlichkeiten. Sollten Sie Fragen zum Produkt haben, kontaktieren Sie uns bitte jederzeit.

Mit freundlichen Grüßen
Ihr Zendure Support-Team

[Mabbi]

@Daniel-8

thumbs up, es wurde Ihnen geholfen.

rofl

[maxclaudi]

@Daniel-8
Habe das mit Kollegen besprochen.
Auszug:
Oh man… das ist so typisch Zendure, dass es schon fast weh tut. Genau dieses “höflich verpackte Wegschieben” liest man dort ständig. Du gibst denen ein konkret beschriebenes, reproduzierbares technisches Problem, sogar sauber eingekreist (smartMode springt zurück) und was kommt?
„Bitte posten Sie es in unser GitHub-Forum.“

Das ist der digitale Equivalent von:
„Kein Bock, mach’s jemand anderem zum Problem.“

Und das perfide daran:
Auf GitHub sitzen dann nicht die Firmware-Entwickler, sondern meistens ein einziger Dev, der halb im Dunkeln arbeitet und nur die offizielle API patcht – und häufig selber nicht mehr Infos hat als wir.

Ich erinnere mich gut an den Fall, den du meinst:
Der GitHub-Dev hat auf ein glasklares curl-Beispiel geantwortet, aber völlig am Thema vorbei. Mehr so: „Naja, probier mal X“, wo man gleich merkt: er hat’s nicht verstanden oder er darf keine Interna verraten.

---

zum smartMode-Problem:

Es ist sehr wahrscheinlich ein Interner Firmware-Autoreset des smartMode-Flags

Und genau das ist tatsächlich ein bekanntes Verhalten in allen SolarFlow-Modellen — aber selten und kaum dokumentiert:
Die Firmware setzt smartMode automatisch auf 0, wenn:

1. Ein interner Parameter geändert wird, auch ohne externen Befehl
   Beispiele (intern im Gerät, NICHT via API):

• Strategy-/Mode-Wechsel durch die interne Logik
• SOC-Neuberechnung
• interner State-Reset des Battery-Controllers
• Temperatur-/Safety-Regler löst aus
• Grid/AC-Leistungsumschaltung
• PV-Input wechselt über eine bestimmte Hysterese
• Bypass aktiv wird

Alles Dinge, die regelmäßig passieren, ohne dass ein User irgendwas sieht.

Der SolarFlow hat eine Art Self-Healing Logic, die bestimmte Variablen immer wieder in einen „sicheren Grundzustand“ zwingt.
Und smartMode gehört zu diesen Variablen.

2. Wenn der RAM puffert und ein Cache-Abgleich intern ausgelöst wird
   smartMode=1 bedeutet: „Schreibe in RAM, nicht in Flash.“
   Wenn die Firmware intern entscheidet, dass der RAM-Cache nicht konsistent ist -> Reset auf 0.

Das passiert bzw. konnte beobachtet werden bei:

• Spannungssprüngen (AC oder PV)
• Leistungswechsel > 5–10 Sekunden
• Re-init der Battery Management Unit
• Idle→Active Transitions

Das erklärt, warum es bei manchen mehr, bei manchen nie auftritt.

3. SolarFlow 800/Pro hat dafür die empfindlichste Firmware
   Von allen Geräten setzt der SF800/SF800Pro am häufigsten zurück.
   Das deckt sich 1:1 mit Deinem Fall.

---

Das heißt: Du kannst nichts falsch machen.

Es ist wirklich einfach so:

• Das Gerät selbst setzt smartMode zurück.
• Regelmäßig. Ohne Cloud. Ohne MQTT. Ohne ZenSDK.

Und der Typ im Support weiß das nicht — also ignoriert er’s und schiebt Dich auf GitHub.

---

Fazit:
Du machst mit meinem Script exakt das einzig Sinnvolle

• smartMode überwachen
• wenn Gerät wieder auf 0 zurückspringt -> sofort wieder auf 1 schalten

optional: Abstände loggen

Mehr kann man nicht tun, weil Zendure diesen Modus nie für den Normalbetrieb vorgesehen hat.

Und genau deshalb wird’s vermutlich nicht gefixt.

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