Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

maxclaudi

PS @paul53: ...könntest du mir bei der Gelegenheit kurz bestätigen, ob bei deinem Modell die Seriennummer physisch auf dem Gehäuse/Typenschild ablesbar ist? Wie gesagt, ich will die Nummer nicht wissen, nur ob sie bei dir draufklebt. Danke!

Beispiele:

HAB5MCADH280002
FED3MCDHA320002

paul53

@maxclaudi [sagte]: Seriennummer physisch auf dem Gehäuse/Typenschild ablesbar ist?

Ja. Wozu ist das wichtig?

maxclaudi

@paul53 sagte:
Ja.

Dankeschön.

Wozu ist das wichtig?

Für meine Software.

Wenn jemand mehrere Geräte im Haus hat, muss man beim Starten des Tools natürlich das richtige Gerät auswählen können.

Zwar wird beim Bluetooth-Scan die BT-MAC-Adresse und der Bluetooth-Name des Geräts angezeigt – als Entwickler weiß man damit schnell, was zu wählen ist.
Für den normalen Anwender ist das aber oft kryptisch.

Die Software soll eine sichere, einfache und für jeden verständliche Möglichkeit bieten, das gewünschte Gerät anhand der Seriennummer eindeutig zu identifizieren, bevor man es umschreibt.

paul53

@maxclaudi sagte: Falsch berechnet wird von der Firmware nichts.

Das kann ich nicht bestätigen.
Ich betreibe den SF 800 Pro 2 ohne PV als reine Notstromlösung. In diesem Fall ist die Berechnung des SoC "völlig daneben".
Folgende Werte des BMS sind ab ca. 16 Stunden nach 100-%-Kalibrierung etwa 3 Tage lang konstant:

Danach sinkt die Spannung langsam, aber der SoC bleibt weiterhin auf 100 %. Die Batterie wird mit etwa 0,2 A entladen (Selbstentladung / BMS?). Die folgenden DP-Werte passen nicht:

state: Müsste 2 oder 0 sein, da die Batterie nicht geladen, sondern entladen wird, wie man an der Spannung sieht.
batcur: Das Vorzeichen müsste negativ sein

"socLevel" wird anscheinend mittels "batCur" berechnet, was erklärt, dass nach Beendigung der Ladung mit "socSet" = 85 % der SoC weiter um jeweils 1 % alle 2 Stunden steigt anstatt mit dieser Rate zu sinken.

Anmerkung: Ich habe den SF per Router vom Internet abgekoppelt.

maxclaudi

@paul53
Bin bei SoC kein Erbsenzähler ;-)
Der SoC (State of Charge) ist letztlich immer ein Schätzwert und funktioniert bei keinem PV-System perfekt.

Zudem muss man die Zellen regelmäßig vollpacken "grillen" – also auf 100 % laden –, damit das BMS die Zellen balancieren kann.

Selbst in diesem Bereich schützt einen Zendure recht gut, da die angezeigten 100 % in der Realität nicht die absoluten Belastungsgrenzen der Zellen sind.

Das lässt sich recht gut an der Spannung (Voltage) ablesen – vorausgesetzt, die Messwerte stimmen.
Jedenfalls sind reale Messwerte immer noch genauer als reine SoC-Schätzungen.

Um die Anzeige wirklich zu kalibrieren, müsste man das System eigentlich regelmäßig so tief wie möglich entladen und wieder komplett vollmachen.

Nur so passen die SoC-Werte "halbwegs".

Soweit ich gelesen habe und meine mich erinnern zu können, betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.
Das ist für die Lebensdauer der Zellen absolut top!
Allerdings bedeutet das im Umkehrschluss leider auch, dass du den angezeigten SoC-Werten in diesem Korridor noch weniger vertrauen kannst.

PS:
Dass die Werte konstant bleiben und viel schief geht liegt vermutlich daran, dass keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Es wird am Ende zu alle xx sek versucht den Broker zu erreichen. Gibt es keinen...

maxclaudi

doppelpost -sorry bin am arbeiten

paul53

@maxclaudi [sagte]: keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.

Wie kommst du darauf?
In den ersten Wochen bestand eine Internet-Verbindung. Das Verhalten war gleich.

@maxclaudi sagte:

betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.

Das mache ich aufgrund der falschen SoC-Berechnung nicht mehr.
Per Skript schalte ich bei Erreichen von "minVol" <= 3,28 V den "acMode" auf Entladen. Wenn dann der SoC auf 96 % gefallen ist, schalte ich wieder um auf Laden mit "socSet" = 100 %. So sieht das im Chart aus:

Das Skript:

const idNetz = 'alias.0.USV.Netz'/*gridState - Stromnetz*/;
const idSoc  = 'alias.0.USV.SOC'/*electricLevel - SoC*/;
const idMinV = 'alias.0.USV.minVol'/*Min cell voltage*/;
const idDown = 'alias.0.USV.shutdown'/*PVE runter fahren*/;
const idMode = 'alias.0.USV.acMode'/*acMode - 1: in charge, 2: out discharge*/;

function shutdown(text) {
    if(!getState(idNetz).val) {
        sendTo('email', {
            subject: 'ioBroker PVE',
            text: text + '. PVE wird runter gefahren!'
        });
        setState(idDown, true); // PVE runter fahren   
    }
}

on(idSoc, function(dp) { // electricLevel
    if(dp.state.val < 30 && dp.oldState.val >= 30 ) {
         shutdown('SoC < 30 %');
    }
    if(dp.state.val <= 96  && getState(idMode).val == 2) {
        setState(idMode, 1); // Laden
    }
});

on(idMinV, function(dp) { // minVol
    if(dp.state.val < 3.2 && dp.oldState.val >= 3.2) {
        shutdown('min. Zellspannung < 3,2 V');
    }
    if(dp.state.val <= 3.28 && dp.oldState.val > 3.28 && getState(idNetz).val) {
        setState(idMode, 2); // Entladen
        sendTo('email', {
            subject: 'ioBroker USV',
            text: 'min. Zellspannung <= 3,28 V. Batterie wird entladen bis SoC 96 %.'
        });
    }    
});

on(idNetz, function(dp) {
    sendTo('email', {
        subject: 'ioBroker Stromnetz',
        text: 'Netz ' + (dp.state.val ? 'wieder vorhanden' : 'ausgefallen!')
    });    
});

Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.

Die Firmware hat auch einen internen Tiefentladeschutz. Das habe ich beim Entladen beobachtet, als der SoC abrupt von 75 % auf 5 % fiel. Das anschließende Laden zeigte, dass die Batterie tatsächlich entladen war.

maxclaudi

@paul53 sagte:
Wie kommst du darauf?

tcpdump, wireshark, Analyse, Erfahrung.
Gut, wenn es bei Deiner Firmware nicht so ist.

Per Skript schalte ich bei Erreichen von "minVol" <= 3,28 V den "acMode" auf Entladen. Wenn dann der SoC auf 96 % gefallen ist, schalte ich wieder um auf Laden mit "socSet" = 100 %.

?
Sorry keine Zeit, muss weiter analysieren, prog. und testen... solange ich noch vor Ort bin.

PS: ich (ent-)lade ausschließlich anhand von Messwerten. Limits werden auch nicht von SoC bestimmt nur Volt.

@paul53 sagte
Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.

bei meinen Batterien und Geräten nicht: 3,4xV.

Bernd1967

@paul53 sagte
Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.

@maxclaudi sagte:
bei meinen Batterien und Geräten nicht: 3,4xV.

Bei meinen Hyper2000 und 800Pro2 hab ich Werte von 3.4xV bis 3.6xV, also immer verschieden.Habe als Typ AB2000S, AB2000X und AB2000L.
Ich meine mal gelesen zu haben das Zendure die Ladespannung und die Kapazität überwacht.
So ne Art Mischkalkulation, je nachdem was zuerst eintritt wird die Ladung gestoppt.

Daniel 8

@maxclaudi sagte:

@Daniel-8 sagte:
Also noch schneller per ZenSDk wenn er von der cloud getrennt ist?

Ja, man kann aussuchen, ob man zenSDK verwendet oder reines MQTT. Wobei MQTT zu bevorzugen wäre, weil die Daten sofort und nur wenn nötig automatisch vom Gerät published werden.

Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.

Die Firmware selbst ist m. M. n. gut genug und reagiert selbstständig auf z. B. kritische Wärme.

Ja das denke ich auch das die Firmwar selbst gut genug ist. Es könnte ja auch mal die Cloud ausfallen und dann müssen die Geräte ja auch reagieren bevor etwas passiert

maxclaudi

@Daniel-8 sagte:
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.

In dem Fall würde ich das zenSDK-Script zur MQTT-Steuerung anpassen.
Habe ich schon für einen HUB2000.
Einfach konfigurieren, Struktur und Datenpunkte bleiben identisch bzw. werden noch mehr und zusätzlich automatisch neu angelegt.

Triggern statt HTTP GET pollen. Statt POST leicht verändertes JSON erzeugen und an Datenpunkte des MQTT-Adapters übergeben.

PS: Es geht beides.
In meinen Tests läuft zenSDK weiter mit dem 1600AC+
Man sieht hier dass es der Cloud möglich wäre localAPI aus- oder einuschalten:

Community Forum

NEWS

Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

Support us

488

33.0k

83.6k

1.3m