Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Felli]

@manuelg

Mahlzeit 👋🏼

Freut mich sehr zu hören, das dir die Regelung gefällt. Die Rampen sind mit dem neuen EMA-Filter eigentlich fast überflüssig, habe sie bei mir mittels 0 einfach abgeschaltet. Lasse die Funktion aber drin, weil sie nicht weh tut und falls jemand mit EMA 1.0 fährt also ohne Filter, kann er die Rampen wieder rein nehmen.

Habe gerade eben noch eine neue Version released, bei der man eine Hysterese auch bei SOC nutzen kann, damit der Solarflow nicht Up and down geht wie ein Lemming 🤣

Danke für Deine Rückmeldung 👍🏼

[nograx]

@manuelg Es gibt im Objektbaum "connectionMode", da steht drin wie die Kommunikation verwendet wird.

[Murphy 0]

@felli
Es würde mich interessieren ob dein Regelung auch bei nicht zenSDK Geräten wie z.B.: meinem Hyper funktioniert?
Dies wäre interessant um einen Vergleich mit meinem eigenen Blockly zu machen.

So schaut das Ergebniss meiner Regelung momentan aus:

[Felli]

Probiere es aus, lässt sich der Hyper denn mit dem Datenpunkt setDeviceAutomationInOutLimit steuern? Falls ja, kannst du es direkt probieren. Ich gehe ja nicht direkt ans Gerät, die Kommunikation geht über Peters Adapter intern. Wie das Gerät am Ende an den Adapter angebunden ist, spielt dabei keine Rolle.

Die Regelung basiert auf einem klassischen I-Regler mit ein paar Zusätzen. Wenn man es brutal und schnell will, alle Sicherheiten entfernen und Go. Wenn man auf Sicherheit steht, entsprechend konfigurieren. Bin gespannt 😵‍💫😜

[Murphy 0]

Danke für die Rückmeldung.

Steuere komplett über setDeviceAutomationInOutLimit.
Update das System komplett, dann mache ich eine Test mit einer Sicherungskopie 😉

[manuelg]

@nograx sagte:

@manuelg Es gibt im Objektbaum "connectionMode", da steht drin wie die Kommunikation verwendet wird.

Danke für deine Antwort, bei mir wird der als "null" angezeigt. Läuft dann bei mir etwas nicht richtig?

[Murphy 0]

@Felli sagte:

Probiere es aus, lässt sich der Hyper denn mit dem Datenpunkt setDeviceAutomationInOutLimit steuern? Falls ja, kannst du es direkt probieren. Ich gehe ja nicht direkt ans Gerät, die Kommunikation geht über Peters Adapter intern. Wie das Gerät am Ende an den Adapter angebunden ist, spielt dabei keine Rolle.

Die Regelung basiert auf einem klassischen I-Regler mit ein paar Zusätzen. Wenn man es brutal und schnell will, alle Sicherheiten entfernen und Go. Wenn man auf Sicherheit steht, entsprechend konfigurieren. Bin gespannt 😵‍💫😜

Das Updates des Systems ist erst mal schief gegangen. Ich habe wohl zu lange nicht upgedatet. Verschieden Adapter im ioBroker laufen nicht mehr. Deine Adapter wurde dennoch ohne Fehler installiert, reagiert aber nicht. Der Objekt Ordner bleibt leer.
So macht das keinen Sinn. Ich muss wohl mal bei Gelegenheit ein neues sauberes System aufsetzten.
Den Versuch habe ich auf SD Karte gemacht, die m.2 SSD ist wieder aktiv und läuft. 😤

[Felli]

@Murphy-0 Huppala

Okay, je nachdem wie alt der admin ist, kann das natürlich knallen. Gut ich kann da mal schauen ob ich es abwärts besser kompatibel bekomme aber vermute eher das der Fehler in Deinem System liegt. Habe das hier auf Haupt und Testinstanz probiert und lief.

Meld Dich gerne nochmal zurück und viel Erfolg!!!

LG
Sven

[Murphy 0]

@felli
Leider habe ich momentan kein Testsystem. Wird von Docker mit Solectrus, nextcloud und paperless-ngx belegt.
Seit meine Steuerung mit Blockly so schön rund läuft ist mit langweilig geworden und ein Blick über den Tellerrand angesagt.
Wie sagt man so schön: Stillstand ist Rückschritt.

[Felli]

@Murphy-0

Absolut, immer nach vorne ;)

Wenn ich einen Tipp geben darf, ich würde jedem zu einem kleinen tiny PC und Proxmox raten. Da kommt in meinen Augen nichts anderes dran und es ist wirklich easy going, vor allem was Backups der Container usw angeht. Da kann man auch mal was nach allen Regeln der Kunst "kaputt" spielen und einfach zurück rollen

[TiCiPieIPi]

@nograx
Außerhalb des Kontextes hier:
Ich habe die Version 3.6.0 installiert und nutze eine SolarFlow 800 Pro. Die Anbindung erfolgt über Cloud Authorization. Beim ersten Start wurde der Objektbaum erzeugt. Der Adapter läuft. Allerdings erhalte ich täglich 00:00 Uhr Protokolleinträge, dass der Objektzweig .calculations und alle darin enthaltenen Objekte fehlen. (Protokoll stufe warn).
Müsste der Objektzweig vorhanden sein? Oder sind die Meldungen veraltet? Wie kann ich den Fehler ggf. beheben. Hab bisher nichts passendes gefunden.

Vielen Dank

[nograx]

@TiCiPieIPi Danke für die Info. Wenn du "Kalkulationen vom Adapter nutzen" nicht aktiviert hast sollte die Meldung nicht erscheinen, da scheint meine Abfrage nicht korrekt sein. Schaue ich mir mal an.

[nograx]

@Murphy-0 Kann dir hier auch nur die Empfehlung geben einen Mini-PC zu kaufen und mit Proxmox zu arbeiten. Wenn man eine gewisse Ahnung hat was eine virtuelle Maschine ist wird einem das sehr viel bringen. Nur daran denken bei der Auslegung nicht zu geizig zu sein, denn wenn man da erstmal eine Sache am laufen hat hat man da plötzliche etliche Maschinen... :D

[Felli]

@nograx kann ich so bestätigen... Nutze 12 LXC und eine VM mittlerweile 😵‍💫🤣🤣 Richtig gut und vor allem stabil!

[TiCiPieIPi]

@nograx

Berechnungen sind nicht eingeschaltet.

[Murphy 0]

Mir ist folgendes Verhalten beim Laden des Hyper2000 mit 2x AB2000s aufgefallen.
Ab 90% SOC wird die Ladeleistung scheinbar vom BMS zurück genommen wenn genug Strom vom Dach kommt und eigentlich 1200 Watt angesteuert werden. Ab da beobachte ich ein ständiges auf und ab bis die eingestellte Zellspannung erreicht ist.

Vertraut ihr da dem BMS und lasst das machen oder steuert ihr irgendwann die Ladung herunter um den Akku zu schonen. An der Temperatur des Hyper oder der Akkus hat es nicht gelegen. Hyper wird gekühlt und lag bei 38 Grad Akkus lagen bei 32 Grad.

Heute nun die Laderegelung so eingestellt, dass ab 90 % SOC mit 1000 Watt, ab 98% mit 800 Watt und ab 99% mit 600 Watt geladen wird. So sind keine Sprünge met feststellbar.
Wie macht ihr das und falls ihr runter regelt würden mich die Werte interessieren.

Nicht wundern, nachdem der Zendure fertig geladen hat wird automatisch das eAuto geladen, deshalb bleibt die Solarleistung ohne etwas einzuspeisen.

[Felli]

@Murphy-0

Kann man denke ich ignorieren. Bei einem DC gekoppelten System wie einem HUB oder Modulen am Hyper, kann man ja auch nichts machen. Die Platten liefern und die Hardware macht damit was sie kann. Also ich maße mir nicht an, alles was Zendure tut in Frage zu stellen, dann müsste ich die Klötze gleich an die Straße stellen 😵‍💫🤣

Spaß bei Seite, beim HUB mit Modulen war es exakt das gleiche, die Hardware hat die Leistung beim laden so beschnitten, das es zum Ladeende passt. Vermute wenn man da von außen eingreift, macht man mehr falsch wie richtig. Der SF1600 pumpt zum Ende auch, regelt runter und wieder rauf, bis die Zellen darauf reagieren und sich einordnen.

Fazit, ich würde einfach die Leistung freigeben die verfügbar ist und Go!

LG
Sven

[maxclaudi]

@Murphy-0 sagte:

Vertraut ihr da dem BMS und lasst das machen oder steuert ihr irgendwann die Ladung herunter...

Ich lade bei PV-Überschuss zusätzlich aus dem Netz.
Dazu überwache ich gridInputPower (manchmal auch als gridPower bezeichnet).
Wenn der gridInputPower-Wert zu stark abweicht bzw. x W niedriger ist als die eingestellte Netzladeleistung (inputLimit), dann verringert mein Skript langsam das inputLimit, bis beide Werte einigermaßen zueinander passen.
Es schaltet ab, wenn es keinen Sinn mehr macht – spätestens bei x minVol oder ca. 98 % aufgeladenen Batterien.

Das Driften tritt auf, wenn es:

• kurz vor der Ladeschlussspannung ist,
• nahe dem eingestellten socSet oder 100 % liegt,
• damit kurz vor dem Bypass ist oder
• kurz vor bzw. beim Überschreiten der Grenze der maximal möglichen Lade-Gesamtleistung (PV+Netz) des Geräts ist.

Das ist nur meine Vorgehensweise; ob es sein muss? Das kann jeder für sich entscheiden.