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

[lesiflo]

@the_stig Der Stop bewirkt das, sobald der Wert wieder über 0 ist, die Ausführenzeit wieder auf 0 gesetzt wird und von vorne zählt.

[The_Stig]

@lesiflo Sag mal, bei mir läuft das jetzt alles seit ein paar Tagen. Funktioniert mit ein paar individuellen Anpassungen auch gut. Einzig bei wechselhaften Wetter springt halt ständig der AC Mode hin und her. Irgendeine Idee, wie man da ggf. einen Stopp einbauen kann, also irgendwas wie "wenn in den letzten 15 Minuten x-mal Wechsel zwischen Input/Output, dann keine Umschaltung"? Oder ist das dem Hyper letztlich egal, wie oft er die Modi schaltet (beim Hub war das mit dem Standby ja ein Problem, wenn zu oft geschaltet)

[lesiflo]

@the_stig

Moin,
du kannst z.B. einen zusätzlichen Timer einbauen. Der sorgt dafür, dass erst nach 30 Sekunden in den Lademodus umgeschaltet wird

[The_Stig]

@lesiflo Danke - das habe ich schon - bei mir sogar auf 10 Minuten gesetzt. Aber trotzdem überlege ich, ob das so sinnvoll ist. Dauert ja immer auch eine Weile, bevor er nach dem Schalten dann auch mit der Einspeisung beginnt.

[lesiflo]

@the_stig Du kannst ja die Timer für Laden/Entladen unterschiedlich lang machen.

[The_Stig]

@lesiflo vielleicht habe ich mich da noch nicht so ganz klar ausgedrückt. Mir gehts um solche Wetterphasen wo ständig zwischen bewölkt und sonnig der Wechsel ist. Dann schaltet das Skript mehr oder weniger immer wenn der Timeout abgelaufen ist, wieder um. Kann ja auch sein, dass das für den Hyper unproblematisch ist, aber so weit ich das jetzt in den wenigen Tagen beobachten konnte, ist das halt inhaltlich wenig sinnig, da es ja auch gerade beim AC Input Mode immer einiges an Zeit dauert, bis er dann mit dem Einspeisen des Überschusses überhaupt anfängt.
Da dachte ich halt an irgendwas wie wenn in den letzten X Minuten X mal umgeschaltet, dann bleibe bei AC Output Mode. Aber vielleicht bin ich da schon wieder zu steuerungsverliebt und sollte es einfach gut sein lassen :-)

[Murphy 0]

@lesiflo
Ich benutze dein Skript zum ACseitigen Laden seit einigen Monaten sowohl in der Cloud wie auch jetzt offline.
Nun habe ich versucht mit dem Adapter 2.01 auf setDeviceAutomationInOutLimit umzustellen aber leider bisher ohne Erfolg.
Ich habe die einzustellende Eingangsleistung sowie die einzustellende Ausgangsleistung auf den Punkt setDeviceAutomationInOutLimit umgestellt.

Automodel ändert sich dan automatisch auf SmartCT im Adapter aber mehr passiert nicht.

Wäre super wenn du mir weiter helfen könntest.

Das ist deine bisher funktionierende Version:

[lesiflo]

@murphy-0 Ich denke du musst überall da wo aktuell noch Ausgangsleistung und Eingangsleistung steht jetzt das Objekt
setDeviceAutomationInOutLimit verwenden und entsprechend mit + oder - arbeiten. Ich selber nutze das nicht mehr und bin mittlerweile auf Java-Script umgestiegen.

[Murphy 0]

@lesiflo

Danke Dir.

Mein Problem war das Laden des Akkus.
Wegen dem benötigten Minuswert hatte ich einige Anpassungsprobleme 🤪

Ich stelle das geänderte Blockly mal hier rein, falls es von sonst jemandem benutz wird.
Hoffe das ist für dich in Ordnung.

Funktion wie folgt:

Reines Laden über AC
Tagsüber nur Überschuss laden, kein Entladen.
Nachts nur Bedarf entladen.

Passt für mich weil wenn der Akku voll ist lädt das Auto.

[paul53]

@murphy-0 sagte: das geänderte Blockly

Den beiden "stop" ist eine falsche Variable zugewiesen.

[Murphy 0]

@paul53

timeout4 ?

[paul53]

@murphy-0 sagte: timeout4 ?

Ja, das ist die einzige Timer-Variable im gezeigten Skript.

EDIT: Um sicher zu gehen, dass die Stop auch funktionieren, würde ich eine Timer-Sperre ergänzen:

[Murphy 0]

@paul53

Ja, die ist doch den beiden Stop zugewiesen.

[paul53]

@murphy-0 sagte: die ist doch den beiden Stop zugewiesen.

output ist die falsche Variable!

[Murphy 0]

@paul53
Ok, wie wäre es richtig?

Wegen der Trennung auf Tag und Nacht braucht es ja eigentlich keine Umschaltpause?

[Murphy 0]

@paul53 said in Script zum Laden/Entladen von Zendure Solarflow:

@murphy-0 sagte: timeout4 ?

Ja, das ist die einzige Timer-Variable im gezeigten Skript.

EDIT: Um sicher zu gehen, dass die Stop auch funktionieren, würde ich eine Timer-Sperre ergänzen:

Ok, zu spät gesehen!

[cordobadb]

@lesiflo : Vielen Dank für deine Arbeit und deine geteilten Erfahrungen!
Ich beginne auch gerade mich mit der Steuerung des Hypers zu befassen. Als Basis hätte ich gerne deinen Ansatz verwendet.
In Blockly müsste ich mich einarbeiten, was bestimmt geht, bin aber eher der Fan von Codezeilen. Wärst du vielleicht bereit dein neuesten Java-Script Code mit uns zu teilen?

Vielen Dank!

[lesiflo]

@cordobadb Kann ich gerne machen. Mein Script geht aber weit über das Blockly hinaus. Ich kann es ja mal einstellen und kurz beschreiben. Was du dann davon verwenden kannst must du schauen.

[Murphy 0]

Als absoluter Anfänger in iobroker habe ich eine Möglichkeit gesucht Einstellungen im Skript zu ändern und Überblick über die wichtigsten Hperdaten am Handy zu bekommen.
Quasi als Ersatz für die Zendure App.

Das habe ich nun mit Iqontrol für meine Bedürfnisse umgesetzt.

Lade und Entladegrenzen, Zeitfenster für Laden und Einspeisen habe ich damit umgesetzt.

Alle Auswertungen rund um Photovoltaik und Hyper2000 mache ich mit openhab. Da bin ich halt schon länger dabei.

[lesiflo]

@cordobadb Moin, hier mal das Script. Ist aber sehr stark an meine Bedürfnisse angepasst und auch noch nicht ganz fehlerfrei.

hems.txt

Das ioBroker-JavaScript ist eine komplexe und intelligente Steuerung für zwei Zendure Hyper-Batteriespeicher (Hyper1 und Hyper2). Es berücksichtigt:

• PV-Produktion
• Strompreis (Tibber)
• Hausverbrauch
• SOC der Akkus
• Sonnenauf- und -untergang
• Auto-Ladevorgang
• VIS-Log-Ausgabe für visuelle Rückmeldung

Zentrale Aufgaben & Ziele des Skripts

1. Optimale Ladung/Entladung der Akkus
   Priorisiert PV-Überschuss-Laden.
   Nutzt günstigen Strompreis für zusätzliches Laden.
   Verhindert Entladen bei günstigen Strompreisen oder Vorrang fürs Auto.
   Erlaubt Entladung bei teurem Strompreis.

2. Speicher-Priorisierung:
   Wenn der Speicher lädt und sein SOC unter einer definierten Schwelle ist, haben Speicher-Ladevorgänge Vorrang.

3. Strompreis-Integration (Tibber):
   Laden bei günstigem Preis (aggressiv oder konservativ je nach Einstellung).
   Entladen bei teurem Preis.

4. PV-Forecast-Nutzung:
   Verwendet pvforecast-Daten für Tages- und Restprognose.

5. Nachtbedarf-Absicherung (AmountHours):
   Nutzt SOC und Sonnenuntergangs-/aufgangszeit zur Berechnung von Tibber’s AmountHours.
   Stellt sicher, dass genug Akkuenergie für die Nacht verbleibt.

6. Leistungsaufteilung zwischen Hyper1 und Hyper2:
   Dynamisch je nach SOC-Differenz.
   Leistung ist begrenzt auf xxx W je Gerät.

7. Hysterese und Modusverzögerung:
   Verhindert zu schnelles Umschalten zwischen Lade- und Entlademodus (20s Delay).

8. VIS-kompatibles Logging:
   Ausgabe der Vorgänge (PV, SOC, Ladeleistung, Preisstatus etc.) in einem HTML-Log-Table im VIS