Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[maxclaudi]

@Daniel-8 sagte:
Von wieviel Mehrertrag reden wir denn da? Macht das wirklich soviel aus?

Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

Meine bisherigen Beobachtungen dazu:
Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

Die Hoymiles-Wechselrichter starten im Vergleich deutlich schneller. Sie speisen selbst bei minimalen Wattwerten bereits ein.
Laut Datenblatt liegt die Einschaltspannung des HM-1200 und HM-400 bei gerade einmal 22 V, während der eigentliche Betriebsspannungsbereich sogar schon ab 16 V beginnt.
Gerade zum Abend hin speisen die Hoymiles dadurch noch absolut zuverlässig Kleinstmengen ein (z. B. 6 W), wenn die Trägheit der Zendure-Regelung schon längst im Standby wäre.
Das MPPT-Tracking der Hoymiles arbeitet meiner Meinung nach um Welten präziser und „holt einfach mehr raus“ – und das jeden Tag aufs Neue.

Wenn das Zendure-Gerät per Skript also ausschließlich über AC geladen und entladen wird, fängt die exzellente Latenz der Hoymiles die theoretischen Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) in der Realität locker wieder auf.

Da kommen über das Jahr gerechnet definitiv einige Kilowattstunden zusammen!

Ich möchte und werde Zendure hier keineswegs schlecht reden.
Es ist schlicht meine persönliche Erfahrung bei meinem spezifischen Setup und Standort.
Gerade im Frühjahr, Herbst und Winter habe ich hier durch ein höheres Nachbarhaus und den tieferen Stand der Sonne mit schwierigen Verschattungen zu kämpfen.
Aber insgesamt sind die Wechselrichter von Hoymiles und deren MPPT-Regelung meiner Meinung nach in solchen Szenarien einfach überlegen.

[Daniel 8]

@maxclaudi sagte:

Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

Meine bisherigen Beobachtungen dazu:
Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

Vielen Dank für deine Meinung.
Da ich aber keinen zur Hand habe und erst einen kaufen müsste, muss man viele kw einsparen bis dieser bezahlt ist.

Zudem müsste ich ja um das ganze dann per ac zu laden auch einen größeren nehmen als die erlaubten 800 watt. Sonst würde mir ja das ganze auch nichts bringen.

[maxclaudi]

@Daniel-8 sagte:
Da ich aber keinen zur Hand habe und erst einen kaufen müsste, muss man viele kw einsparen bis dieser bezahlt ist.

Völlig richtig, das steht außer Frage.
Es war ja auch lediglich die Beschreibung meines spezifischen Setups, da bei mir die Hoymiles-Wechselrichter ohnehin schon vorhanden waren.
Wenn man alles neu kaufen muss, sieht die Rechnung natürlich anders aus.

Zudem müsste ich ja um das ganze dann per ac zu laden auch einen größeren nehmen als die erlaubten 800 watt. Sonst würde mir ja das ganze auch nichts bringen.

Das verstehe ich ehrlich gesagt nicht ganz, denn es gibt ja verschiedene Kombinationsmöglichkeiten.

Ein AC-Laden mit konstanter, gleichmäßiger Leistung ist oft wesentlich effizienter, energetisch stabiler und materialschonender, als die Batterie über PV-DC bei ständig wechselnder Bewölkung und permanent schwankenden Wattwerten zu füttern.
Genau aus diesem Grund integriert man in sinnvolle Steuerungen ja auch Parameter wie eine Mindestdauer für den acMode (Relais-Schutz).

Zudem könnte man das System ja auch als Hybrid betreiben:
Einige wenige PV-Module, die z. B. „Problemkinder“ sind (geringere Leistung haben oder öfter verschattet werden), können oder bleiben einfach an den reinen DC-PV-Eingängen des SolarFlow angeschlossen.
Die starken, unverschatteten Module laufen parallel über den Hoymiles.

Der SolarFlow 800 Pro kann kontinuierlich mit bis zu 1000 W AC geladen werden – das ist für ein herkömmliches Balkonkraftwerk mehr als genug.
Die maximale Ausgangsleistung ist gesetzlich ohnehin auf 800 W begrenzt.

In meiner Praxis speise ich – abgesehen von kurzzeitigen Lastspitzen im criticalMode – eigentlich fast wie nie mehr als ca. ~500 W gleichzeitig ein.
Das hängt am Ende natürlich immer vom individuellen Grundverbrauch und der Personenanzahl im Haushalt ab.

Ein E-Auto-Lademanagement rechnet sich bei so kleinen Systemen aber im Regelfall sowieso fast nie.

Letzten Endes hängt – wie immer – alles vom einzelnen, spezifischen Setup, den vorhandenen, realen Gegebenheiten und den persönlichen Anforderungen ab.
Eine generelle Empfehlung ist deshalb nie möglich – nur Ratschläge und Ideen, was wie funktionieren könnte.

[T-147]

@Daniel-8 sagte:

Seit heute Nacht gibt es die Version 2
0.5 Kann man die bedenkenlos installieren oder sollte man lieber noch ein bisschen abwarten?

Nachdem ich bei Firmware 2.0.2 immer wieder den Fehler 33 bekam (wurde mittlerweile vom Zendure-Support als Firmware-Fehler bestätigt) kam mir das Update gestern morgen sehr gelegen.
Ich nehm zwar ungern immer direkt die neueste Firmware, aber hier bleib mir nicht viel anderes übrig.
Wenn man mit der installierten Firmware keine Probleme hat oder nicht unbedingt ein neues Feature erwartet/benötigt, sollte man mMn immer etwas mit dem Update warten.

Bislang läuft mein SF800 Pro2 mit 2.0.5 ohne Auffälligkeiten und Probleme, auch mit dem ZenSDK-Script und der Nulleinspeisung von Maxclaudi (aktuell noch nicht die neueste Version, die mach ich heute erst bereit)

[T-147]

@maxclaudi sagte:
Meine bisherigen Beobachtungen dazu:
Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

Ich hab hier den SF800 Pro2, der fängt morgens schon ab 10W Gesamtleistung (über alle 4 Panels/MPPT) an zu laden. In meinem Fall und Setuo scheint sich die deutlich niedrigere Start-Spannung von Zendure im Vergleich zu meinem HMS-1000 auszuzahlen.
Vor allem, da meine 4 Panels in SO und SW ausgerichtet sind und ich wie Du (in SO-Richtung) in der dunkleren Jahreshälfte mit Verschattung durchs Nachbarhaus zu kämpfen hab.
Den HMS-1000 werd ich jetzt mit einem zusätzlichen Panel in Richtung S an die Offgrid-Dose hängen. Mal sehen, was das über den Winter an Mehrertrag bringt.

Leider lassen sich die Geräte von Zendure nicht so detailliert auslesen, wie die Hoymiles über eine OpenDTU zB, daher kann ich leider aus meinen Daten keine echten, direkten Vergleich herstellen.

[maxclaudi]

@T-147 sagte:
Ich hab hier den SF800 Pro2, der fängt morgens schon ab 10W Gesamtleistung (über alle 4 Panels/MPPT) an zu laden. In meinem Fall und Setuo scheint sich die deutlich niedrigere Start-Spannung von Zendure im Vergleich zu meinem HMS-1000 auszuzahlen.

Meiner Meinung nach sitzt du da leider einem kleinen Mess- bzw. Anzeigefehler auf, was die realen physikalischen Abläufe angeht.

Die SolarFlow 800er-Pro-Serie hat die Steuerelektronik, die 4 MPPT-Regler und den Wechselrichter komplett in einem Gehäuse integriert.
Dieses Gesamtsystem (inklusive ESP32-Chip, WLAN, Bluetooth und Batterie-Management-System) hat einen permanenten, spürbaren Eigenverbrauch für den reinen Betrieb.

Wenn dir die App am Morgen anzeigt, dass mit "10 W" geladen wird, bedeutet das rein physikalisch folgendes:
Deine PV-Module müssen zu diesem Zeitpunkt bereits den kompletten internen Grundverbrauch des Geräts (für CPU, WLAN, BMS-Aktivierung etc.) gedeckt haben. Erst die Leistung, die darüber hinausgeht, bleibt netto übrig und wandert als die von dir gesehenen 10 W in die Batterie.

Man darf hier die reine Startspannung der MPPT-Tracker (die beim Pro 2 erfreulicherweise schon ab 14 V liegt) nicht mit der notwendigen Mindestleistung für den Systembetrieb verwechseln.
Ohne dass die PV-Leistung die interne Grundlast des Speichers vorab komplett kompensiert, kann das Gerät weder einspeisen noch laden.
Die Solarmodule müssen real also schon deutlich mehr als 10 W liefern, damit das System überhaupt aus dem Standby erwacht.

[T-147]

@maxclaudi
Klingt plausibel.
Danke für den Hinweis, soweit hab ich natürlich nicht gedacht.

[maxclaudi]

15.10.2026; 16:00h Weiterer Bericht zum Betrieb über MQTT-Port 1883 und zenSDK

Fortsetzung von:

Da es dazu weltweit quasi null Infos gibt, dachte ich, ich teile meine bisherigen Erkenntnisse mal auszugsweise als kleinen Bericht mit euch.

Wer möchte kann den Bericht im spoiler lesen, für alle anderen ist der Beitrag dann kürzer und kann ignoriert werden

Spoiler

MQTT-Port 1883: Verbindung mit neuen Zendure-Geräten und zenSDK

Wenn das Zendure-Gerät über den unverschlüsselten MQTT-Port 1883 gekoppelt ist, läuft das lokale zenSDK-Skript über HTTP spürbar stabiler und reagiert subjektiv deutlich schneller.
In meinen Testreihen war ein HTTP-Polling im 3000-ms-Takt absolut problemlos und lückenlos möglich.

Im produktiven Betrieb ist ein so schnelles Intervall allerdings sinnfrei.
Es ist besser, das Polling bei ≥ 4000 ms zu belassen.
Das schont das Netzwerk (Traffic), die Netzwerk-Ressourcen des ESP32 und verhindert das hardwarebedingte Empfangen von identischen Altwerten.

Bei meinem aktuellen Test wird keine MQTT-Steuerung/Regelung verwendet. Die gesamte Steuerung erfolgt exklusiv über das zenSDK mittels HTTP-Befehlen aus dem Skript dieses Threads.

Über die unverschlüsselte MQTT-Schnittstelle (Port 1883) sende ich lediglich in einem festen Intervall eine minimale Abfrage, um die MQTT-Verbindung im Hintergrund aktiv zu halten.
Realisiert durch ein Mini-Skript (ein kleines Blockly ist auch kein Problem), das im festen Intervall den MQTT-Adapter-Datenpunkt mit der stets gleichen Abfrage senden lässt.

Für meine eigenen Testreihen habe ich das Skript lediglich um ein paar zusätzliche Helper-Funktionen zum Debuggen erweitert.

Genialer Nebeneffekt:
Über das zenSDK lassen sich plötzlich auch die erweiterten Limits für minSoc (0–95 %) und socSet (6–100 %) völlig frei einstellen und stabil nutzen.
Im herkömmlichen Normalbetrieb über TLS auf Port 8883 sperrt sich die Firmware hier bekanntlich strikt; Werte für socSet unter 70 % sind dort gar nicht möglich.

Es sollte aber zwingend darauf geachtet werden, dass der eingestellte minSoc-Wert stets kleiner ist als der socSet-Wert.

Ich werde wohl das Skript für mich noch um eine integrierte Schutzlogik erweitern:
Sollte diese Bedingung nicht erfüllt sein, wird der Schreibbefehl blockiert.
Zudem möchte ich, dass z. B. socSet immer mindestens 2 % höher liegen soll als minSoc, um unlogische Hystereseschleifen der Hardware zu vermeiden.

Durch ein niedrigeres socSet funktioniert auch weiterhin alles stabil, wie die Erkennung von socLimit und dass der Bypass (pass) mit socSet indirekt gesteuert werden kann – z. B. dass der Bypass automatisch früher ein- oder ausgeschaltet wird.

Befund:
Der allseits bekannte und nervige energyLevel- bzw. SoC-Bug (plötzliche Sprünge oder Einfrieren der Prozentwerte) tritt in diesem unverschlüsselten Setup bei mir bisher nicht auf.

Es ist möglich, über MQTT, das HTTP-zenSDK und Bluetooth-Properties zu regeln.
Alle drei Steuerungsmöglichkeiten sind bzw. wären sogar simultan möglich.

MQTT bietet mehr bzw. alle Möglichkeiten, die aber eigentlich nicht für den normalen, lokalen Betrieb nötig sind.

Richtet man den Broker zusätzlich als Bridge zur Cloud ein, kann die App weiter verwendet werden.
HEMS ist bei mir (bis jetzt) dauerhaft deaktiviert.
Außer für eine Zeitsynchronisation hat die Cloud bisher nicht in das System eingegriffen.

edit 21.10.2026; 10:45 erledigt
PS: Ich suche immer noch [1 Tester]

Wer sich bedanken möchte, weiß ja, wo der Voting-Button ist. Ein extra Post dafür muss nicht sein. ;-)

[T-147]

@maxclaudi

Das neue Java-Script lief gestern ohne erkennbare Probleme und hat die Batteriesperre sauber gesetzt und auch dann aufgehört einzuspeisen.

Was mich nur grad ein wenig stört ist die Tatsache, dass das Einspeisen schon bei 24% SoC beendet wurde, weil die minVol von 3,16V erreicht wurde. So weit über dem MinSoC find ich schon viel. Macht jetzt im Herbst/Winter nicht so viel aus, aber im Sommer würde da schon einiges verschenkt.
Ich weiß, SoC ist (deutlich) ungenauer, aber so viel Unterschied ist schon krass.

Aber das ist ja kein Problem Deiner Skripte, sondern ein generelles Elektronik-/Akku-Thema.

Das mit dem CriticalOutputLimit muss ich über das Wochenende nochmal beobachten. Heute Nachmittag kommt das Kind von der Klassenfahrt zurück, dann steigt der Stromverbauch wieder deutlich

[maxclaudi]

@T-147 sagte:
Das neue Java-Script lief gestern ohne erkennbare Probleme und hat die Batteriesperre sauber gesetzt und auch dann aufgehört einzuspeisen.

Was mich nur grad ein wenig stört ist die Tatsache, dass das Einspeisen schon bei 24% SoC beendet wurde, weil die minVol von 3,16V erreicht wurde. So weit über dem MinSoC find ich schon viel.

Schön zu hören, dass das Skript an sich erst einmal sauber läuft!

Zu dem frühen Stopp bei 24% SoC: Das ist bei LFP-Zellen (wie den 15S-Akkus von Zendure) unter Last völlig normal.

Die LFP-Spannungskurve ist extrem flach, und unter aktiver Entladung bricht die Spannung durch den Innenwiderstand der Zellen künstlich ein (sogenannter Voltage Sag).
Eine Zelle, die laut BMS-Schätzung noch bei 24% steht, kann unter Last also kurzfristig unter die 3,16 V rutschen.
Sobald die Last weg ist, erholt sich die Spannung wieder.
Zudem neigt der angezeigte SoC zum "Driften", wenn länger nicht voll- und tiefer entladen wurde.

Als reiner Erfahrungswert (ausdrücklich KEINE allgemeine Empfehlung!):
Meine Batterien stehen im unbeheizten Innenbereich (nie unter 10°C).
Bei meinem Setup fahre ich im Normalbetrieb hiermit sehr gut:

let batteryLockMinCellVoltage   = 3.14; // Entladesperre normal (entspricht unter Last ca. 8-12% realem Rest-SoC)

Wenn es draußen richtig kalt wird (0°C oder Minusgrade), passe ich es an, da Kälte den Spannungsabfall unter Last noch verstärkt:

let batteryLockMinCellVoltage   = 3.16; // Entladesperre bei Kälte

Allgemein empfehlen möchte ich das aber nicht, da jedes Setup anders reagiert. Bei mir hat das System dieses Jahr bisher nur zweimal komplett abgeschaltet. Die normalen Ladevorgänge finden meistens statt, bevor es so weit runtergeht.

Um die SoC-Berechnung des BMS wieder zu kalibrieren, lasse ich die Akkus 1x monatlich komplett auf 100% aufladen – und zusätzlich immer dann, wenn die minVol doch mal häufiger erreicht wurden bzw. erreicht werden sollten.

Vielleicht hilft Dir das ein wenig weiter.

[T-147]

@maxclaudi sagte:
Zu dem frühen Stopp bei 24% SoC: Das ist bei LFP-Zellen (wie den 15S-Akkus von Zendure) unter Last völlig normal.

Die LFP-Spannungskurve ist extrem flach, und unter aktiver Entladung bricht die Spannung durch den Innenwiderstand der Zellen künstlich ein (sogenannter Voltage Sag).
Eine Zelle, die laut BMS-Schätzung noch bei 24% steht, kann unter Last also kurzfristig unter die 3,16 V rutschen.
Sobald die Last weg ist, erholt sich die Spannung wieder.
Zudem neigt der angezeigte SoC zum "Driften", wenn länger nicht voll- und tiefer entladen wurde.

Genau das meinte ich mit "Elektronik-/Akku-Thema"

Als reiner Erfahrungswert (ausdrücklich KEINE allgemeine Empfehlung!):
Meine Batterien stehen im unbeheizten Innenbereich (nie unter 10°C).
Bei meinem Setup fahre ich im Normalbetrieb hiermit sehr gut:

let batteryLockMinCellVoltage   = 3.14; // Entladesperre normal (entspricht unter Last ca. 8-12% realem Rest-SoC)

Wenn es draußen richtig kalt wird (0°C oder Minusgrade), passe ich es an, da Kälte den Spannungsabfall unter Last noch verstärkt:

let batteryLockMinCellVoltage   = 3.16; // Entladesperre bei Kälte

Ich habe hier ähnliche Bedingungen: ungeheizter Dachboden, auch im Winter nie unter 10° gewesen. Ich werde mich mal ganz langsam rantasten.

Um die SoC-Berechnung des BMS wieder zu kalibrieren, lasse ich die Akkus 1x monatlich komplett auf 100% aufladen – und zusätzlich immer dann, wenn die minVol doch mal häufiger erreicht wurden bzw. erreicht werden sollten.

Vielleicht hilft Dir das ein wenig weiter.

Wie machst du die Kalibrierung? Schaltest du die DPL-Regelung einfach solange ab, machst du das über ein separates Script als CronJob oder sowas? Einfach manuell auf volle Last Aufladen stellen geht ja nicht, dann schaltet die Regelung das direkt wieder ab.
Oder setzt Zendure beim Kalibrieren irgendwo ein Flag, was man für eine automatische Steuerung nutzen könnte, oder sowas?
Hab gestern auf nem Screenshot der App was von Zwangskalibrierung gelesen und dass die Steuerung derzeit blockiert ist und nach der Kalibrierung wieder automatisch freigegeben wird.

Und nur nochmal zur Info:
Mein SF800 Pro 2 arbeitet mit der neuen FW 2.0.5 bisher ohne Auffälligkeiten, auch mit den ZenSDK- und DPL-Scripten.

[maxclaudi]

@T-147 sagte:

@maxclaudi sagte:
Zu dem frühen Stopp bei 24% SoC: Das ist bei LFP-Zellen (wie den 15S-Akkus von Zendure) unter Last völlig normal.

Genau das meinte ich mit "Elektronik-/Akku-Thema"

Unter plötzlicher großer Last oder im criticalMode kann die Spannung auch nur kurzzeitig einbrechen.
Um das sauber abzufangen, habe ich die Logik im Skript erweitert.

Neu bzw. Änderungen zum bisherigen JS-Script Post #610:

• Frühes Abschalten durch kurze Lastspitzen wird verhindert:
  Das Skript wurde um eine gefahrlose Pufferzeit erweitert.
  Wenn die schwächste Zelle die batteryLockMinCellVoltage (z. B. 3,14 V) erreicht, passiert erst einmal nichts.
  Erst wenn die Spannung nach Ablauf der Pufferzeit immer noch dauerhaft bei oder unter dem Grenzwert liegt, schaltet das Skript die Entladung ab.
  Das überbrückt das typische Taktungsverhalten von Großverbrauchern (wie dem Herd) perfekt.
  Da eine echte Tiefentladung bei LFP-Zellen erst etwas unter 2,50 V beginnt, besteht bei 3,14 V für wenige Minuten absolut kein Risiko für die Hardware.

• Einfache und verständliche Umsetzung: Die Verzögerung wurde auch diesmal sehr einfach gelöst – komplett ohne komplizierte Schleifen, Timeouts oder Ähnliches.
  Es bleibt für Einsteiger leicht verständlich und ist im Code ausreichend kommentiert.

• Keine neuen Parameter nötig:
  Die Logik nutzt einfach die bereits vorhandene Variable batteryRecoveryStartSec, um sich den Beginn des Spannungseinbruchs zu merken.
  Für die Dauer der Pufferzeit (z. B. 5 Minuten) wird auch der Wert aus der bestehenden Konfigurationsvariable batteryRecoveryTimeSec verwendet.

Vielleicht ist das Skript in dieser Form noch hilfreicher für Dich bzw. Euch! ;-)

// ZENDURE einfache NULLEINSPEISUNG - ioBroker JavaScript-Adapter
// Wahlweise 1 bis 6 Batterien. Keine Schleifen, einfach zu lesen für Einsteiger
// Für alle Geräte ab 2025/2026, die zenSDK unterstützen, wie z. B.:
// SF800, SF800 PLUS, 800Pro (2), 1600AC, SF2400AC(+) usw.
// (c) maxclaudi 16.10.2026_12:30h für das ioBroker-Forum
//
// EIN WORT IN EIGENER SACHE:.
// In der Vergangenheit wurden meine Erkenntnisse oft ohne Erwähnung in andere Projekte übernommen.
// Ich teile diesen Code gerne. 
// Wer diese(n) Code/Logik in öffentliche Adapter integriert oder anderweitig - auch Auszugsweise verwenden möchte,
// ist herzlich eingeladen – ich bitte jedoch um die Fairness, die Quelle zu nennen. 
// Das ist der "Lohn" für meine Zeit und Forschung.
// ======================================================================================
 
//KONFIGURATION: HIER PFADE UND DATENPUNKTE und Anzahl der Batterien ANPASSEN

// Trigger-Datenpunkt (Stromzähler / Smart Meter, Netzbezug in Watt)
const DP_GRID_METER_TRIGGER = '0_userdata.0.Datenpunkte.zendureSolarFlow.user.ZaehlerTrigger_easy_shelly';
 
// Haupt-Verzeichnis des Zendure-Datenpunkte-Scripts (muss identisch sein), bitte kein "+", keine Sonderzeichen und keine Umlaute verwendnen!
const folderZendureApi = '0_userdata.0.zendure.' + "2400ACproZENsdk";
 
// Wie viele Batterien hast du? Mögliche Werte: 1, 2, 3, 4, 5 oder 6
const vorhandeneBatAnz = 1;
 
// Seriennummern der Batterien.
// Nur die Seriennummer eintragen (ohne ".minVol"), nicht benötigte Zeilen einfach so lassen.
const akku1sn = "Cxxxxxxxxxxxxx1"; // z.B.: const akku1sn = "JO2AEP1P0605193";
const akku2sn = "Cxxxxxxxxxxxxx2";
const akku3sn = "Cxxxxxxxxxxxxx3";
const akku4sn = "Cxxxxxxxxxxxxx4";
const akku5sn = "Cxxxxxxxxxxxxx5";
const akku6sn = "Cxxxxxxxxxxxxx6";
 
 
// REGEL-PARAMETER (die Standardwerte müssten für die meisten Zendure-Geräte passen)
//---------------------------------------------------------------------------------------
let intervalSec_outputLimit = 15; // Entladen frühestens nach X Sekunden. Standard: 15 s
let intervalSec_inputLimit  = 20; // Laden frühestens nach X Sekunden. Standard: 20 s
let chargingStep            = 50; // Schritte AC-Laden (z.B. 50 W, 100 W). Standard: 50 W
let dischargeStep           = 10; // Schritte Entladen, wird aufgerundet. Standard: 10 W
let wattChangeThreshold     = 30; // Hysterese: Änderungen erst ab X Watt Abweichung. Standard: 30 W
let safetyReserve           = 20; // Sicherheitsreserve gegen Netzbezug beim Laden. Standard: 20 W
 
let criticalGridPower        = 600;  // Ab wie viel Watt Netzbezug gilt es als hoher Leistungsabruf. Standard: 600 W
let criticalOutputLimit      = 1600; // Maximale Entladeleistung im Critical-Mode (nicht größer als dein Gerät: 800, 1000, 2400 W)
let intervalSec_criticalMode = 45;   // So lange wird die Spitze gehalten (taktende Großverbraucher: Herd, Klima, Durchlauferhitzer)
 
let intervalSec_change_acModeAllowed = 45; // Relais-Schutz: Sperrzeit nach einem Moduswechsel in Sekunden, bitte nicht zu kurz
 
let batteryLockMinCellVoltage   = 3.16; // Entladesperre bei dieser Zellspannung: 3.16 bis 3.20 V
let batteryUnlockMinCellVoltage = 3.25; // Freigabe nach der Sperre ab dieser Zellspannung. Standard: 3.25 V
let batteryRecoveryTimeSec      = 300;  // Beruhigungszeit/Verzögerungszeit der Zellen in Sekunden. Standard: 300 s (5 min)

//---------------------------------------------------------------------------------------
// AB HIER NICHTS VERÄNDERN!
//---------------------------------------------------------------------------------------
 
// Anzahl Batterien sichern (nur 1 bis 6 erlaubt)
let batAnz = Math.round(vorhandeneBatAnz);
if (!(batAnz >= 1)) batAnz = 1;
if (batAnz > 6) batAnz = 6;
 
// Basis-Pfade zu Zendure-Eigenschaften
const BASE_PATH_PROPERTIES = folderZendureApi + '.properties.';
const BASE_PATH_CONTROL    = folderZendureApi + '.control.';
const BASE_PATH_PACKDATA   = folderZendureApi + '.packData.';
 
// Zellspannungs-Datenpunkt einer Batterie zusetzen
// (ein versehentlich mit eingetragenes ".minVol" wird automatisch entfernt)
function packDp(sn) {
    return BASE_PATH_PACKDATA + String(sn).replace('.minVol', '') + '.minVol';
}
 
const DP_MIN_VOL_PACK1 = packDp(akku1sn);
const DP_MIN_VOL_PACK2 = packDp(akku2sn);
const DP_MIN_VOL_PACK3 = packDp(akku3sn);
const DP_MIN_VOL_PACK4 = packDp(akku4sn);
const DP_MIN_VOL_PACK5 = packDp(akku5sn);
const DP_MIN_VOL_PACK6 = packDp(akku6sn);
 
// Spezifische Datenpunkte (automatisch zusammengesetzt)
const DP_AUTO_IN_OUT_LIMIT = BASE_PATH_CONTROL + 'auto_in_out_Limit';
const DP_SMART_MODE        = BASE_PATH_CONTROL + 'smartMode';
 
const DP_INVERSE_MAX_POWER = BASE_PATH_PROPERTIES + 'inverseMaxPower';
const DP_CHARGE_MAX_LIMIT  = BASE_PATH_PROPERTIES + 'chargeMaxLimit';
const DP_GRID_INPUT_POWER  = BASE_PATH_PROPERTIES + 'gridInputPower';
const DP_OUTPUT_HOME_POWER = BASE_PATH_PROPERTIES + 'outputHomePower';
const DP_INPUT_LIMIT       = BASE_PATH_PROPERTIES + 'inputLimit';
const DP_OUTPUT_LIMIT      = BASE_PATH_PROPERTIES + 'outputLimit';
const DP_AC_MODE           = BASE_PATH_PROPERTIES + 'acMode';
const DP_PASS              = BASE_PATH_PROPERTIES + 'pass';
const DP_SOC_LIMIT         = BASE_PATH_PROPERTIES + 'socLimit';
const DP_PACK_STATE        = BASE_PATH_PROPERTIES + 'packState';
const DP_ELECTRIC_LEVEL    = BASE_PATH_PROPERTIES + 'electricLevel';
const DP_MIN_SOC           = BASE_PATH_PROPERTIES + 'minSoc';
const DP_SOC_SET           = BASE_PATH_PROPERTIES + 'socSet';
 
// Merker-Variablen
let dplAktiv = true;
let lastSec_outputLimit_auto_in_out_Limit = 0;
let lastSec_inputLimit_auto_in_out_Limit = 0;
let lastSec_criticalMode = 0;
let lastSec_change_acModeAllowed = 0;
let batteryRecoveryStartSec = 0;
 
let batteryLock = false;
let batteryRecoveryPending = 0;
 
// NEU: Zeitstempel für Beginn des Spannungseinbruchs (0 = alles ok)
let batteryVoltageDropStartSec = 0; 
 
// aktuelle Sekunden
function getNowSec() {
    return Math.floor(Date.now() / 1000);
}
 
// sicherer getState mit Fallback, verhindert Abstürze bei fehlenden Datenpunkten
function getSafeVal(dpId, fallback) {
    if (fallback === undefined) fallback = 0;
    let state = getState(dpId);
    if (state && state.val !== undefined && state.val !== null) {
        return state.val;
    }
    return fallback;
}
 
// konfiguration prüfen und ggf. auf Standardwerte zurücksetzen
if (chargingStep < 10 || chargingStep > 100) chargingStep = 50;
if (dischargeStep < 10 || dischargeStep > 60) dischargeStep = 10;
if (wattChangeThreshold < 6 || wattChangeThreshold > 60) wattChangeThreshold = 30;
if (safetyReserve < 0 || safetyReserve > 60) safetyReserve = 20;
 
// Hardware-Maxima aus den Geräte-Eigenschaften lesen (mit Absturzsicherung)
let maxHardwareOutput = getSafeVal(DP_INVERSE_MAX_POWER, 800);
let maxHardwareCharge = getSafeVal(DP_CHARGE_MAX_LIMIT, 800);
 
let max_outputLimit = maxHardwareOutput;
let max_inputLimit  = maxHardwareCharge;
if (criticalOutputLimit > maxHardwareOutput) criticalOutputLimit = maxHardwareOutput;
 
if (batteryLockMinCellVoltage < 3.0 || batteryLockMinCellVoltage > 3.4 || batteryLockMinCellVoltage >= batteryUnlockMinCellVoltage) {
    batteryLockMinCellVoltage = 3.16;
}
if (batteryUnlockMinCellVoltage < 3.2 || batteryUnlockMinCellVoltage > 3.4 || batteryUnlockMinCellVoltage <= batteryLockMinCellVoltage) {
    batteryUnlockMinCellVoltage = 3.25;
}
if (batteryRecoveryTimeSec < 60 || batteryRecoveryTimeSec > 1800) batteryRecoveryTimeSec = 300;
 
console.info('Nulleinspeisung gestartet. Batterien: ' + batAnz);
 
// RELAIS-SCHUTZ: Zeitpunkt des letzten Moduswechsels (Laden <-> Entladen) merken
on({ id: DP_AC_MODE, change: 'ne' }, function () {
    lastSec_change_acModeAllowed = getNowSec();
});
 
// MAIN TRIGGER: reagiert auf den Stromzähler
on({ id: DP_GRID_METER_TRIGGER, change: 'ne' }, function (obj) {
    let gridMeterValue = Math.ceil(obj.state.val || 0);
    let nowSec = getNowSec();
 
    // ZELLSPANNUNGEN UND GERÄTE-WERTE AUSLESEN
    // Es wird die niedrigste Zellspannung aller vorhandenen Batterien verwendet; Fallback 3.30V
    let minCell = getSafeVal(DP_MIN_VOL_PACK1, 3.3);
    if (batAnz >= 2) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK2, 3.3));
    if (batAnz >= 3) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK3, 3.3));
    if (batAnz >= 4) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK4, 3.3));
    if (batAnz >= 5) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK5, 3.3));
    if (batAnz >= 6) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK6, 3.3));
 
    let socLimitState = getSafeVal(DP_SOC_LIMIT, 0);
    let packState     = getSafeVal(DP_PACK_STATE, 0);
    let currentSoc    = getSafeVal(DP_ELECTRIC_LEVEL, 0);
    let minSocLimit   = getSafeVal(DP_MIN_SOC, 10);
    let maxSocLimit   = getSafeVal(DP_SOC_SET, 100);

    // BATTERIE-ENTLADESCHUTZ (Erweitert um verzögerten Zellschutz unter Last)
    if (socLimitState === 2) {
        // Sofortiger Stopp bei hartem SoC-Limit der App
        if (!batteryLock) {
            batteryLock = true;
            console.info('Zellschutz AKTIVIERT. SoC-Limit der App erreicht.');
        }
    } else if (minCell <= batteryLockMinCellVoltage && packState !== 1) {
        // Spannung unterschritten, aber Gerät lädt nicht aktiv
        if (batteryVoltageDropStartSec === 0) {
            // Der Spannungseinbruch fängt gerade erst an -> Zeitpunkt merken
            batteryVoltageDropStartSec = nowSec;
            console.info('Mindestspannung unterschritten (' + minCell + ' V). Pufferzeit von ' + batteryRecoveryTimeSec + ' Sekunden läuft...');
        } else if (nowSec - batteryVoltageDropStartSec >= batteryRecoveryTimeSec) {
            // Die Pufferzeit (z.B. 5 Min) ist abgelaufen und die Spannung ist immer noch zu niedrig
            if (!batteryLock) {
                batteryLock = true;
                console.info('Zellschutz AKTIVIERT. Mindestspannung nach Ablauf der Pufferzeit dauerhaft unterschritten.');
            }
        }
    } else {
        // Spannung ist wieder über dem Grenzwert -> Timer zurücksetzen
        batteryVoltageDropStartSec = 0;
    }
 
    // Freigabe nach der Sperre (erst nach Beruhigungszeit)
    if (minCell >= batteryUnlockMinCellVoltage && batteryLock && batteryRecoveryPending === 0 && socLimitState !== 2) {
        batteryRecoveryPending = 1;
        batteryRecoveryStartSec = nowSec;
    }
 
    if (batteryRecoveryPending === 1 && socLimitState !== 2 && (nowSec - batteryRecoveryStartSec >= batteryRecoveryTimeSec)) {
        if (minCell < batteryUnlockMinCellVoltage) {
            batteryRecoveryPending = 0; // Zellen wieder eingebrochen, Abbruch
        } else {
            batteryLock = false;
            batteryRecoveryPending = 0;
            batteryVoltageDropStartSec = 0; // Komplett zurücksetzen
            console.info('Zellschutz ERFOLGREICH DEAKTIVIERT. Batterien wieder stabil.');
        }
    }
 
    // true = Entladen ist gesperrt
    let protectionActive = (batteryLock || socLimitState === 2);
 
	// aktuellen Hausverbrauch (ohne Bat) berechnen
    // positiv = Verbrauch / Netzbezug, negativ = Überschuss
    let netPowerWithoutBattery = (gridMeterValue - getSafeVal(DP_GRID_INPUT_POWER)) + getSafeVal(DP_OUTPUT_HOME_POWER);
 
	// hoher Leistungsbedarf (criticalMode)
    // Darf NUR laufen, wenn KEIN Batterieschutz greift
    if (!protectionActive && gridMeterValue >= criticalGridPower && dplAktiv && (nowSec - lastSec_criticalMode > intervalSec_criticalMode)) {
        // criticalMode starten
        dplAktiv = false;
        let critLimit = Math.min(Math.ceil(Math.max(netPowerWithoutBattery, 0)), criticalOutputLimit);
 
        setState(DP_AUTO_IN_OUT_LIMIT, critLimit);
        console.info('Critical Mode AN: auto_in_out_Limit gesetzt auf: ' + critLimit + ' W');
 
        lastSec_criticalMode = nowSec;
        lastSec_outputLimit_auto_in_out_Limit = nowSec;
 
    } else if (!dplAktiv && (protectionActive || (nowSec - lastSec_criticalMode > intervalSec_criticalMode))) {
        // criticalMode läuft: verlängern oder beenden
        if (gridMeterValue >= criticalGridPower && !protectionActive) {
            let critLimit = Math.min(Math.ceil(Math.max(netPowerWithoutBattery, 0)), criticalOutputLimit);
            if (critLimit !== getSafeVal(DP_OUTPUT_LIMIT)) {
                setState(DP_AUTO_IN_OUT_LIMIT, critLimit);
                console.info('Critical Mode VERLÄNGERT: auto_in_out_Limit angepasst auf: ' + critLimit + ' W');
            }
            lastSec_criticalMode = nowSec;
            lastSec_outputLimit_auto_in_out_Limit = nowSec;
        } else {
            // Lastspitze vorbei ODER Batterieschutz, dann criticalMode beenden, normale Regelung wieder freigeben
            lastSec_outputLimit_auto_in_out_Limit = 0;
            lastSec_inputLimit_auto_in_out_Limit = 0;
            dplAktiv = true;
            lastSec_criticalMode = nowSec;
            console.info('Critical Mode AUS: Zurück zur normalen Regelung.');
        }
    }
 
	// normale Regelung Nulleinspeisung & Laderegelung
    if (dplAktiv) {
        // Sichern, dass Zendure im SmartMode (1) läuft
        if (getSafeVal(DP_SMART_MODE) === 0) {
            setState(DP_SMART_MODE, 1);
        }
 
        let newLimit = 0;
        let currentAcMode = getSafeVal(DP_AC_MODE);
        let acModeTimeOk = (nowSec - lastSec_change_acModeAllowed >= intervalSec_change_acModeAllowed);
 
        // Aktuell gesetzten Wert ermitteln (Laden negativ, Entladen positiv)
        let currentActiveLimit = 0;
        if (getSafeVal(DP_INPUT_LIMIT) > 0) {
            currentActiveLimit = getSafeVal(DP_INPUT_LIMIT) * -1;
        } else if (getSafeVal(DP_OUTPUT_LIMIT) > 0) {
            currentActiveLimit = getSafeVal(DP_OUTPUT_LIMIT);
        }
 
        // Hysterese: bei kleiner Abweichung wird nichts geändert
        let difference = Math.abs(netPowerWithoutBattery - currentActiveLimit);
        let hysteresisHold = (difference < wattChangeThreshold);
        if (hysteresisHold) {
            newLimit = currentActiveLimit;
        }
 
        // FALL A: Überschuss vorhanden, dann Ladeleistung berechnen (Wert wird negativ)
        if (!hysteresisHold && netPowerWithoutBattery <= -100 - safetyReserve) {
            let safeSurplus = netPowerWithoutBattery + safetyReserve;
            let steppedLimit = Math.ceil(safeSurplus / chargingStep) * chargingStep;
 
            newLimit = steppedLimit > -100 ? 0 : steppedLimit;
 
            if (newLimit <= (max_inputLimit * -1)) {
                newLimit = max_inputLimit * -1;
            }
        }
 
        // FALL D: NOTABSCHALTUNG bei Batterieschutz oder leerem Akku
        if ((protectionActive || currentSoc <= minSocLimit) && getSafeVal(DP_OUTPUT_LIMIT) > 0) {
            setState(DP_AUTO_IN_OUT_LIMIT, 0);
            console.info('auto_in_out_Limit 0: Entladen gesperrt (Batterieschutz aktiv / MinSoC erreicht)');
            lastSec_outputLimit_auto_in_out_Limit = nowSec;
 
        // FALL B: Netzbezug vorhanden, dann aus Akku entladen (Wert ist positiv)
        } else if (!protectionActive && currentSoc > minSocLimit && netPowerWithoutBattery > 0 && !hysteresisHold && (nowSec - lastSec_outputLimit_auto_in_out_Limit >= intervalSec_outputLimit)) {
            let targetDemand = Math.ceil(netPowerWithoutBattery);
 
            if (targetDemand <= 30) {
                newLimit = 30;
            } else if (targetDemand <= 60) {
                newLimit = 60;
            } else if (targetDemand <= 90) {
                newLimit = 90;
            } else if (targetDemand <= 100) {
                newLimit = 100;
            } else {
                newLimit = Math.ceil(targetDemand / dischargeStep) * dischargeStep;
            }
 
            if (newLimit >= max_outputLimit) {
                newLimit = max_outputLimit;
            }
 
            // Senden... Relais-Schutz: Wechsel vom Lade- in Entlade-Modus nur nach der Sperrzeit
            if (newLimit !== getSafeVal(DP_OUTPUT_LIMIT)) {
                if (currentAcMode !== 1 || acModeTimeOk) {
                    setState(DP_AUTO_IN_OUT_LIMIT, newLimit);
                    console.info('Entladen: auto_in_out_Limit gesetzt auf ' + newLimit + ' W');
                    lastSec_outputLimit_auto_in_out_Limit = nowSec;
                }
            }
 
        // FALL C: Überschuss oder kein Verbrauch, dann Laden bzw. Entladen beenden
        } else if (netPowerWithoutBattery <= 0 && (nowSec - lastSec_inputLimit_auto_in_out_Limit >= intervalSec_inputLimit)) {
            let currentPassMode = getSafeVal(DP_PASS);
 
            // Ladegrenze erreicht oder Gerät im Pass-Modus -> nicht laden
            let chargeBlocked = (socLimitState === 1 || currentSoc >= maxSocLimit || currentPassMode === 2);
            if (chargeBlocked && newLimit < 0) {
                newLimit = 0;
            }
 
            if (newLimit !== currentActiveLimit) {
                // Relais-Schutz: Wechsel vom Entlade- ins Lade-Modus nur nach der Sperrzeit (Stoppen ist immer erlaubt)
                if (newLimit === 0 || currentAcMode !== 2 || acModeTimeOk) {
                    setState(DP_AUTO_IN_OUT_LIMIT, newLimit);
                    console.info('auto_in_out_Limit gesetzt auf ' + newLimit + ' W (negativ = Laden, 0 = Aus)');
                    lastSec_inputLimit_auto_in_out_Limit = nowSec;
                    if (newLimit === 0) {
                        lastSec_outputLimit_auto_in_out_Limit = nowSec;
                    }
                }
            }
        }
    }
});

[maxclaudi]

@T-147 sagte:
Wie machst du die Kalibrierung? Schaltest du die DPL-Regelung einfach solange ab, machst du das über ein separates Script als CronJob oder sowas? Einfach manuell auf volle Last Aufladen stellen geht ja nicht, dann schaltet die Regelung das direkt wieder ab.

Richtig: Wenn die normale Regelung aktiv ist, funkt sie natürlich dazwischen und regelt die AC-Ladeleistung sofort wieder weg.
Das lässt sich im Skript elegant über einen eigenen Software-Schalter lösen.

Ich mache das über eine einfache Erweiterung des Skripts durch einen zusätzlichen Boolean-Datenpunkt (z. B. 0_userdata.0...batteryCalibrationActive).

Das Prinzip ist denkbar einfach:

• Wenn true (Wert 1): Das Skript läuft im ganz normalen Alltagsmodus (Nulleinspeisung/CriticalMode)

• Wenn false (Wert 0): Die komplette normale Regelung und der Entladeschutz werden vollständig deaktiviert. Stattdessen wird eine separate Ladefunktion aufgerufen.

Wie läuft meine "sanfte" Kalibrierungs-Funktion ab?

1. Sanftes Laden per AC: Die Batterie wird zu einer bestimmten Zeit (vorzugsweise nachts bei günstigem Strom oder geringer Netzlast) materialschonend aufgeladen.

2. Drosselung ab 80 %: Sobald ein SoC von 80 % erreicht wird, drosselt die Funktion die AC-Ladeleistung automatisch herunter, um den Zellen im oberen Bereich Zeit zum Ausgleichen (Balancing) zu geben, und lädt sie so behutsam auf echte 100 % voll.

3. Die wichtige Ruhephase: Ist die Batterie voll, schaltet das Laden ab und es folgt eine programmierte Ruhephase (bei mir von 20 Minuten).
   In dieser Zeit können sich die Zellchemie und die Spannungen setzen.

4. Nachladen & Freigabe: Nach den 20 Minuten prüft die Funktion noch einmal die Spannungen.
   Ist eine Zelle wieder leicht abgesackt, wird kurz nachgeladen. Ist der Akku final stabil, setzt die Funktion den Boolean-Datenpunkt automatisch wieder auf true (1).
   Ab diesem Moment übernimmt sofort wieder die normale Nulleinspeisung.

Hinweis: Ich triggere diesen Datenpunkt ganz bewusst nur manuell, wenn ich merke, dass es Zeit für die Kalibrierung ist oder der monatliche Turnus ansteht.
Vollautomatisch möchte ich das nicht laufen lassen.
Die Funktion sorgt dann selbstständig dafür, dass das Ganze sauber in der Nacht durchgezogen wird.
Die zeitliche Steuerung (wann es nachts losgeht) kann sich dann ja jeder so anpassen, wie es zum eigenen Setup passt.

Hab gestern auf nem Screenshot der App was von Zwangskalibrierung gelesen und dass die Steuerung derzeit blockiert ist und nach der Kalibrierung wieder automatisch freigegeben wird.

Das würde doch dazu passen:

Was mich nur grad ein wenig stört ist die Tatsache, dass das Einspeisen schon bei 24% SoC beendet wurde, weil die minVol von 3,16V erreicht wurde.

[maxclaudi]

update 16.10.26 21:00h
batCalTime zusätzliche Type-Prüfung; fallback 01:00h / control.socCompSwitch ohne Funktion, entfernt

Wer bisher das Script bereits nutzt: Bitte vor Ausführung des Scripts den Datenpunkt:

control.socCompSwitch

löschen.

Alternativ gesamtes Verzeichnis mit allen Datenpunkten (inkl. dp properties etc.) löschen, für zusätzliche Beschreibungen.

Zum aktuellen Skript: HIER KLICKEN

[maxclaudi]

@T-147 sagte:

Oder setzt Zendure beim Kalibrieren irgendwo ein Flag, was man für eine automatische Steuerung nutzen könnte, oder sowas?

Zu deiner Frage mit den Flags von Zendure:
Ja, die gibt es. Man kann dazu zwei spezifische Datenpunkte (Keys) verwenden. Ich habe das bisher allerdings noch nicht im Live-Betrieb getestet und weiß nicht, wie gut die Firmware das handhabt oder ob die Cloud auch eine Rolle spielt.

1. Kalibrierungs-Flag (socStatus)
   Zendure bietet ein Info-Flag, das den aktuellen Zustand ausgibt:

socStatus - SOC calibration Info, 0: No Calibrating / 1: Calibrating

Wenn die Kalibrierung aktiv angelaufen ist, steht der Wert auf 1. Solange sie nur geplant ist und auf den Start wartet, bleibt der Status vermutlich auf 0.

2. Die Startzeit festlegen (control.batCalTime)
   Wenn das System eine Kalibrierung als notwendig erachtet, kann man den Startzeitpunkt beeinflussen.

batCalTime

Du kannst die Startzeit im gewohnten Uhrzeitformat von 00:00 bis 23:59 eingeben. Mein Skript fängt Fehleingaben ab: Wenn ein ungültiger Wert eingegeben wird, setzt das Skript automatisch 01:00 Uhr als Fallback.
Wichtig bei der Eingabe: Uhrzeiten vor 10:00 Uhr müssen mit einer führenden Null eingetragen werden, also zum Beispiel:

04:00

Erlaubte Werte: 00:00 bis 23:59

Könnte man im Regelungsscript einbauen, habe ich aber bisher im zenSDK-Steuerungs-Script nicht getestet. Weder mit noch ohne Cloud.

PS: Falls noch jemand Popcorn übrig hat: Ich hoffe, meine kleinen Monologe hier im Thread bieten zumindest guten Lesestoff für den Drink am Abend! ;-)

[MP_Trixi]

@maxclaudi
Hi. Wie oben geschrieben habe ich sowohl die FW als auch das Script auf Stand gebracht. Dazu noch die Max AC Ladeleistung auf 1000W gesetzt. Zwei Dinge sind mir aufgefallen:
wenn ich in 0_userdata.0.zendure.SolarFlow800Pro2.control.auto_in_out_Limit 0 schreibe war es so, dass nichts von AC geladen, nichts eingespeist aber von den Modulen die Batterien geladen wurden (glaube ich zumindest, kann auch sein dass es sich vorher so verhalten hat weil z.B. meine max. AC Ladeleistung auf 0 war). Jetzt sieht es komisch aus. In der App hat er „keinen Modus“, also weder Netzeingang noch Netzausgang. Die 0 scheint er aber zu registrieren aber faktisch arbeitet er mit dem letzten Modus und eingestellten Wert weiter.

[maxclaudi]

@MP_Trixi

Bitte stoppe das zenSDK-Steuerungsscript.
Lösche danach am besten den kompletten Pfad mit allen Datenpunkten.
Ersetze das bisherige zenSDK-Steuerungs-JS-Script mit der aktuellen Version und passe die Konfig an:

maxclaudi sagte:

update 16.10.26 21:00h
batCalTime zusätzliche Type-Prüfung; fallback 01:00h / control.socCompSwitch ohne Funktion, entfernt

Wer bisher das Script bereits nutzt: Bitte vor Ausführung des Scripts den Datenpunkt:

control.socCompSwitch

löschen.

Alternativ gesamtes Verzeichnis mit allen Datenpunkten (inkl. dp properties etc.) löschen, für zusätzliche Beschreibungen.

Zum aktuellen Skript: HIER KLICKEN

[MP_Trixi]

@maxclaudi
Ok. Ich habe einige aliase gesetzt. Sind die danach wieder da oder reicht es wie in deinen Post oben geschrieben nur control.socCompSwitch zu löschen?

[maxclaudi]

@MP_Trixi
Es reicht auch nur control.socCompSwitch zu löschen.

[MP_Trixi]

@maxclaudi
danke für deinen Input - habe ich gemacht (altes Script gestoppt, control.socComSwitch gelöscht, neues Script gestartet). Ich werde testen