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

[maxclaudi]

setOutputLimit des Adapters
ist identisch mit den Einstellmöglichkeiten der App.

if (limit < 100 && limit != 90 && limit != 60 && limit != 30 && limit != 0) {
          if (limit < 100 && limit > 90 && !(productName == null ? void 0 : productName.includes("hyper"))) {
            limit = 90;
          } else if (limit > 60 && limit < 90 && !(productName == null ? void 0 : productName.includes("hyper"))) {
            limit = 60;
          } else if (limit > 30 && limit < 60 && !(productName == null ? void 0 : productName.includes("hyper"))) {
            limit = 30;
          } else if (limit < 30) {
            limit = 30;
          }
        }
        if (limit > 1200) {
          limit = 1200;
		  }

---

setInputLimit
ist nicht identisch mit der App.

if (limit < 0) {
      limit = 0;
    } else if (limit > 0 && limit <= 30) {
      limit = 30;
    } else if (limit > maxLimit) {
      limit = maxLimit;
    }

Funktioniert das?
In der App sind nur die Werte 0, 100-900 (100er steps) möglich.
Zumindest bei mir mit Hub2000 und ACE1500.
Beschränkt nur die App die Einstellmöglichkeiten und die Hardware gibt mehr her?

---

in createControlStates.js chargeLimit

adapter == null ? void 0 : adapter.subscribeStates(`${productKey}.${deviceKey}.control.autoModel`);
    await (adapter == null ? void 0 : adapter.extendObject(
      `${productKey}.${deviceKey}.control.chargeLimit`,
      {
        type: "state",
        common: {
          name: {
            de: "Setzen des Lade-Limits",
            en: "Control of the charge limit"
          },
          type: "number",
          desc: "chargeLimit",
          role: "value.battery",
          read: true,
          write: true,
          min: 40,
          max: 100,
          unit: "%"
        },
        native: {}
      }
    ));
    adapter == null ? void 0 : adapter.subscribeStates(`${productKey}.${deviceKey}.control.chargeLimit`);
    await (adapter == null ? void 0 : adapter.extendObject(
      `${productKey}.${deviceKey}.control.dischargeLimit`,
      {
        type: "state",
        common: {
          name: {
            de: "Setzen des Entlade-Limits",
            en: "Control of the discharge limit"
          },
          type: "number",
          desc: "dischargeLimit",
          role: "value.battery",
          read: true,
          write: true,
          min: 0,
          max: 50,
          unit: "%"
        },
        native: {}
      }
    ));

Auch hier: Ist die App der Limiter?
Adapter lässt 40% chargeLimit zu.
App: ab 70-100%

Halte mich an die App, damit alles sicher funktioniert.

Speziell beim outputLimit <60 zickt(e) der Hoymiles und funktioniert(e) nicht stabil.

[The_Stig]

@nograx Jetzt habe ich den Case wieder und tatsächlich: LowVoltageBlock ist auf true. Aber: alle drei Batterien liegen bei 46,8V. Wie passt das denn nun zusammen?

[nograx]

@the_stig sagte in Test Adapter Zendure Solarflow:

@nograx Jetzt habe ich den Case wieder und tatsächlich: LowVoltageBlock ist auf true. Aber: alle drei Batterien liegen bei 46,8V. Wie passt das denn nun zusammen?

Wenn keine Leistung mehr von den Batterien kommt "erholt" sich die Spannung und steigt dann wieder leicht an. Das ist normal. Ich kann dir nur empfehlen mal mit dem History Adapter oder einer Datenbank die Werte tracken und die Spannungskurve zu visualisieren... dann sieht man das ganz schön.

[The_Stig]

@nograx die Protokollierung habe ich seit gestern laufen. Ergebnis: gegen 0 Uhr war eine Batterie tatsächlich bei 46,0V. Damit passt das ja mit dem Stoppen des Entladens. Aber: SOC war noch bei 15% zu dem Zeitpunkt, obwohl die letzte Kalibrierung (100% Ladung) erst am 2.5. war...naja, scheint dann wohl der Drift zu sein, mit dem ich leben muss.
In jedem Fall greift dann deine geplante Akkuschonung!

[Arne Dieckmann]

Moin!

Das mit dem Spannungseinbruch und der Erholung am unteren Ende, wenn nichts mehr aus dem Akku kommt, kann ich bestätigen.

Jetzt zu meiner Frage. Ich laufe seit ca. 4 Wochen im lokalen Modus mit eigenem MQTT Server etc.
Im Betrieb sind HUB2000, ACE1500 und 3 AB2000(S) und ein HMS-800-2T mit openDTU. Funktioniert alles einwandfrei.

Normalerweise ist mein System immer zwischen 10% und 90% eingestellt und alle 6 Tage wird der maxSOC auf 100% angehoben, um die Kalibrierung nach oben zu bekommen. Danach wieder 10/90 und alles läuft ohne Probleme.

Nur heute Morgen war mein minSOC auf 5% gestellt. Ein manuelles Ändern auf 10% über den Adapter hat kurzzeitig funktioniert, aber nach ein paar Minuten war er wieder auf 5%.

Gibt es da eine Erklärung für? Macht das der Adapter? Oder hat das mit der "automatischen" Kalibrierung des Zendure Systems zu tun?

Danke vorab!

[nograx]

@arne-dieckmann sagte in Test Adapter Zendure Solarflow:

Moin!

Das mit dem Spannungseinbruch und der Erholung am unteren Ende, wenn nichts mehr aus dem Akku kommt, kann ich bestätigen.

Jetzt zu meiner Frage. Ich laufe seit ca. 4 Wochen im lokalen Modus mit eigenem MQTT Server etc.
Im Betrieb sind HUB2000, ACE1500 und 3 AB2000(S) und ein HMS-800-2T mit openDTU. Funktioniert alles einwandfrei.

Normalerweise ist mein System immer zwischen 10% und 90% eingestellt und alle 6 Tage wird der maxSOC auf 100% angehoben, um die Kalibrierung nach oben zu bekommen. Danach wieder 10/90 und alles läuft ohne Probleme.

Nur heute Morgen war mein minSOC auf 5% gestellt. Ein manuelles Ändern auf 10% über den Adapter hat kurzzeitig funktioniert, aber nach ein paar Minuten war er wieder auf 5%.

Gibt es da eine Erklärung für? Macht das der Adapter? Oder hat das mit der "automatischen" Kalibrierung des Zendure Systems zu tun?

Danke vorab!

Schau mal was du in den Adapter Einstellungen hier hinterlegt hast:

[nograx]

@the_stig sagte in Test Adapter Zendure Solarflow:

@nograx die Protokollierung habe ich seit gestern laufen. Ergebnis: gegen 0 Uhr war eine Batterie tatsächlich bei 46,0V. Damit passt das ja mit dem Stoppen des Entladens. Aber: SOC war noch bei 15% zu dem Zeitpunkt, obwohl die letzte Kalibrierung (100% Ladung) erst am 2.5. war...naja, scheint dann wohl der Drift zu sein, mit dem ich leben muss.
In jedem Fall greift dann deine geplante Akkuschonung!

Naja vermutete 5% (46V) zu 15% ist ja noch human... im Winter habe ich teilweise Abweichungen von über 50%...

[Arne Dieckmann]

@nograx said in Test Adapter Zendure Solarflow:

Schau mal was du in den Adapter Einstellungen hier hinterlegt hast:

Die Funktion der Spannungsüberwachung habe ich bewusst nicht gesetzt, da ich "meine" untere Grenze von 10% (im Winter 20%) selber fest setzen möchte. Ich monitore meine Akkus sehr genau, dank des Adapters und greife entsprechend ein, wenn etwas aus dem Ruder läuft.

:man-shrugging:

[lesiflo]

@nograx
Hi, ich habe ja immer mal wieder diese Einbrüche:

Bibt es eine Möglichkeit das zu unterbinden oder Timer einbauen ?

Die einkommenden Daten gehen immer mal wieder auf 0.

Das bringt jedesmal meine Regelung durcheinander.
Ich bin noch auf der Cloud über den EU Server.

[Murphy 0]

@lesiflo
ich glaube nicht dass es am EU Server liegt.
Bin seit ca. 2 Monaten mit dem Adapter auf dem EU Server und habe keinerlei Einbrüche.
Mein Hyper lädt AC seitig und steht 2 m neben dem Router im Keller.

[lesiflo]

@murphy-0 Die Einbrüche habe ich auch nur bei der PV Leistung. Alles andere kommt sauber an.

[Murphy 0]

@lesiflo
Was mir auffällt, die Zeitsprünge in deiner Timestamp sind unterschiedlich lang. Die 5W Werte kommen meist sehr schnell.
Kann es damit zu tun haben dass da irgend etwas nicht „synchron“ läuft und einfach die Werte noch nicht aktualisiert wurden?

Wie ist die Prozessorlast bei deinem Raspi, oder welche Hardware nutzt du.

Ich hatte Anfangs mit meinem Raspi auf dem ein Python Skript zur Steuerung der Microwechselrichter, Pihole, iobroker und Openhab läuft auch Probleme wegen enormen Schwankungen beim Laden und Entladen vom Hyper.
Habe dann alles neu installiert und seit dem keine Probleme mehr.

[lesiflo]

@murphy-0 An der Performance kann es nicht liegen. Läuft bei mir auf einem Mini-PC unter Proxmox. Bei den anderen Werten wie z.B. Lade oder Entladeleistung habe ich diese Einbrüche nicht.

[Murphy 0]

@lesiflo
Dann kann es am internen Microwechselrichter des Hyper liegen.
Wechselrichter versuchen ja ständig die Leistung zu optimieren.
Vielleicht liegt es hier am Zusammenspiel Module und Hyper.

[lesiflo]

@murphy-0 Das ist auch meine Vermutung. Ich versuche mal das über das Script anzufangen.

[Felli]

@murphy-0
Diese MPTT Drops sind aber viel kleiner. Seit ich das Gerät offline habe, stimmen die Kurven eigentlich perfekt und es gibt solche Phänomene nicht mehr. Probiert es mal per DNS dann seht ihr ja was passiert ohne was hartes zu verändern. Ich tippe auf Server. Die Solarleistung wechselt ja von allen werten am häufigsten da kommt es dann denke ich auch am häufigsten zu Aussetzern. Nur eine Vermutung.

Edit: hier ein Screenshot von heute. Die kleinen Einbrüche vor dem Bypass das ist der MPTT die später waren Wolken die durchzogen.

[maxclaudi]

@felli sagte in Test Adapter Zendure Solarflow:

Diese MPTT Drops sind aber viel kleiner.

:+1: @felli
deckt sich vollständig mit meinen Beobachtungen.

edit:
@lesiflo
Ok, bei mir ist ein Hoymiles am HUB2000.
Es könnte, wie von Dir vermutet, auch am Hyper-Wechselrichter liegen :man-shrugging:

[lesiflo]

@lesiflo sagte in Test Adapter Zendure Solarflow:

@nograx
Hi, ich habe ja immer mal wieder diese Einbrüche:

Bibt es eine Möglichkeit das zu unterbinden oder Timer einbauen ?

Die einkommenden Daten gehen immer mal wieder auf 0.

Das bringt jedesmal meine Regelung durcheinander.
Ich bin noch auf der Cloud über den EU Server.

Ich hab mir jetzt eine zusätzliche Abfrage eingebaut welche mir den max Wert der letzten 5 PV-Werte liefert.
Bin noch am experimentieren ob der median besser passt.

[maxclaudi]

@lesiflo
solarInput_korrigiert: selbst erzeugter Datenpunkt.
"steuere" solarInput_korrigiert durch "aktualisiere" ersetzen(?).

[lesiflo]

@maxclaudi sagte in Test Adapter Zendure Solarflow:

solarInput_korrigiert: selbst erzeugter Datenpunkt.
"steuere" solarInput_korrigiert durch "aktualisiere" ersetzen(?).

solarInput_korrigiert: selbst erzeugter Datenpunkt. -> Ja.
Zwischen "wurde geändert" und "aktualisiere" macht hier keinen Unterschied. Bei "aktualisiere" wird nur öfter getriggert und zwar immer dann wenn der Datenpunkt einen neuen Zeitstempel bekommt, unabhängig davon ob sich der Wert geändert hat oder nicht. Daher nehme ich immer "wurde geändert".