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

[bluebean]

Ok, Astro-Dilemma ist aufgelöst.
Nachdem ich zig Foren durchforstet hatte, hab ich den Hinweis gefunden, mal nach den Timezone-Einstellungen des Hosts zu schauen. Im buanet-Dockercontainer ist die TZ standardmäßig bereits auf Berlin gesetzt - aus welchen Gründen auch immer war das im aktuellen Container aber nicht angekommen. Ich habe den jetzt zwangsaktualisiert, et voilà - die Astro-Objekte sind jetzt wieder so, wie sie sein müssen, und die angezeigten Regelzeiten passen wieder.

[ArnoD]

@psrelax
Das b im Script ist an der Stelle falsch.
Habe gerade gelernt, dass die Funktion "Alle Vorkommen ändern" sehr gefährlich ist. :-)
Eigentlich hatte ich eine lokale Variable umbenannt, um eine einfachere Unterscheidung von Boolsche Variablen umzusetzen, die den gleichen Namen hatte.

Wird in der nächsten Version korrigiert. Danke für den Hinweis und die Fehlersuche.

[ArnoD]

@bluebean
OK, das erklärt auch, warum new Date() keinen Unterschied macht, wenn deine Systemzeit auf UTC eingestellt war.

[Thomas Braun]

@bluebean

Jaja, die Zeit, die liebe Zeit...
Weil das so wichtig ist gibt es dafür z. B. in

iob diag

eine eigene Sektion. Und auch im

iob fix

wird eine Änderung vorgeschlagen, wenn es da Hinweise auf eine falsche Konfiguration gibt.

[bluebean]

@thomas-braun
Den Tipp mit dem iob diag hatte ich auch gefunden (Dein Name tauchte in den Threads, die ich da gefunden hatte, oft auf :blush: ). Hatte ich probiert auszuführen, doch da kam der Hinweis, dass iob diag veraltet sei und aktualisiert werden müsse. War mir aber nicht sicher, ob das bei Verwendung eines Docker-Containers überhaupt geht oder Ärger macht, daher habe ich drauf verzichtet, ebenfalls auch auf iob fix.

[Thomas Braun]

@bluebean sagte in E3DC Hauskraftwerk steuern:

War mir aber nicht sicher, ob das bei Verwendung eines Docker-Containers überhaupt geht oder Ärger macht, daher habe ich drauf verzichtet, ebenfalls auch auf iob fix.

Sollte beides auch auf einem Docker laufen. Halt erst den Fix und dann diag.

[bluebean]

@thomas-braun said in E3DC Hauskraftwerk steuern:

Sollte beides auch auf einem Docker laufen. Halt erst den Fix und dann diag.

Hab das iob fix jetzt mal gestartet, aber da gings mit bash: line 83: timedatectl: command not found schon los... Egal, ist hier im CC-Thread aber auch nicht der richtige Platz.

[Thomas Braun]

@bluebean sagte in E3DC Hauskraftwerk steuern:

Egal, ist hier im CC-Thread aber auch nicht der richtige Platz.

Stimmt.

Da ist ein Abfolge-Fehler im Fixer, der Code sollte auf Dockern nicht ausgeführt werden. Hab ich zur Korrektur vorgemerkt.

[ArnoD]

Neue Version Charge-Control auf GitHub hochgeladen.
Version: 1.5.9
Änderungen:

• Fehler Objekt ID 0_userdata.0.Charge_Control.Allgemein.NotstromAusNetz korrigiert. Danke an psrelax für die Fehlersuche.

[ArnoD]

Neue Version Charge-Control auf GitHub hochgeladen.
Version: 1.5.10
Änderungen:

• Fehler behoben, dass bei einer ungünstigen Konstellation beim Neustart vom Script die PV-Leistungswerte vom aktuellen Monat gelöscht wurden.

[Modulo-N]

@ArnoD: Welchen Lademodus verwendest du eigentlich zum Tibber-Laden? Ich hatte an meiner Wallbox bisher die Modi 2 und 3 verwendet, aber wenn ich mit Modus 3 lade saugt die Wallbox auch in Spitzenpreisphasen die Leitung leer... Gerade eben erlebt: heimgekommen, Wallbox stand auf Modus 3, Spitzenpreislage, Tesla lädt mit 11kW...

Danke für deine Arbeit am Projekt!

Michael

[ArnoD]

@modulo-n
Die Funktion über Freigabe Tibber nur zu günstigen Zeiten zu laden ist im Wallboxskript noch nicht enthalten.
Ich muss erstmal beim Tibber Skript alle Fehler korrigieren, bevor ich mit den Anpassungen im Wallbox Skript weitermache.

[Modulo-N]

@arnod : alles klar...Danke für die schnelle Antwort, Arno!
Ich werde mir behelfsmäßig damit helfen, den Lademodus bei entsprechender Schalterstellung dynamisch handzuhaben, damit ich nicht jedesmal den Schalter an der Wallbox umlegen muss. Dazu werde ich aus den beiden Konstanten einfach Variablen machen, die ich aus neuen Feldern der Useranpassungen lese. Wenn dann eine Spitzenpreislage erkannt wird, ändere einfach dort den Lademodus von 3 auf 2... und wenn die Phase wieder vorbei ist, geht es zurück auf 3. Dank deiner implementierten Logik werden die Werte dann ja automatisch neu gelesen und entsprechend beachtet... Sollte für eine Weile funktionieren...

[psrelax]

@ArnoD

Ich möchte dir keinen Stress mit diesem Thema machen, da du sicherlich wichtigere Themen auf der Agenda hast, somit bitte nur zur Info verstehen. Musst du nicht sofort prüfen.

Ich konnte heute Nacht einmal prüfen, ob das mit der Notstromladung funktioniert.
Die Ladung selbst startet. Allerdings werden 2% mehr geladen als Notstrom eingestellt ist und gleich danach wird anscheinend die Entladesperre aufgehoben, so dass der Speicher komplett entleert wird.
Ich denke das passt nicht, außer meine Einstellung unter Unload ist falsch und von mir falsch verstanden.

[ArnoD]

@psrelax sagte in E3DC Hauskraftwerk steuern:

Die Ladung selbst startet. Allerdings werden 2% mehr geladen als Notstrom eingestellt ist

Das liegt eventuell daran, dass die Werte Batterie SOC beim e3dc-rscp Adapter verzögert aktualisiert werden.
Der TAG TAG_EMS_REQ_BAT_SOC sollte bei den Adaptereinstellungen aus S stehen und als Abfrageintervall sollte < 5 sek. eingetragen werden.
In den neusten Script Version prüfe ich aber diese Einstellungen und du solltest eine Warnung im LOG erhalten.

Ich denke das passt nicht, außer meine Einstellung unter Unload ist falsch und von mir falsch verstanden.

Unload hat nichts mit der Notstromreserve zu tun und ist sicher nicht die Ursache.
Was ist bei dir unter 0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_minWertPrognose_kWh eingetragen? und wurde dieser Wert bei der PV-Prognose erreicht?
Dann wird die Notstromreserve freigegeben zum Entladen.

Am Einfachsten ist, du setzt mal 0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_DebugAusgabeauf true und schickst mir dein LOG File, dann kann ich nachverfolgen, was da nicht passt.

Nachtrag: Wird bei dir 2% mehr geladen, also tatsächlicher Batterie SOC um 2% höher als eingestellter SOC oder nur 2% mehr angezeigt beim eingestellten Notstrom SOC CC ? Das wäre dann normal.

[psrelax]

@arnod sagte in E3DC Hauskraftwerk steuern:

Das liegt eventuell daran, dass die Werte Batterie SOC beim e3dc-rscp Adapter verzögert aktualisiert werden.
Der TAG TAG_EMS_REQ_BAT_SOC sollte bei den Adaptereinstellungen aus S stehen und als Abfrageintervall sollte < 5 sek. eingetragen werden.

Steht auf 2 Sek

In den neusten Script Version prüfe ich aber diese Einstellungen und du solltest eine Warnung im LOG erhalten.

Unload hat nichts mit der Notstromreserve zu tun und ist sicher nicht die Ursache.
Was ist bei dir unter 0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_minWertPrognose_kWh eingetragen? und wurde dieser Wert bei der PV-Prognose erreicht?

Hier ist 0 kWh eingetragen

Dann wird die Notstromreserve freigegeben zum Entladen.
Am Einfachsten ist, du setzt mal 0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_DebugAusgabeauf true und schickst mir dein LOG File, dann kann ich nachverfolgen, was da nicht passt.
Nachtrag: Wird bei dir 2% mehr geladen, also tatsächlicher Batterie SOC um 2% höher als eingestellter SOC oder nur 2% mehr angezeigt beim eingestellten Notstrom SOC CC ? Das wäre dann normal.

Debug hab ich jetzt eingeschaltet, muss aber auf den nächsten Fall warten.
Es wird mehr geladen. Das habe ich im Diagramm von E3DC so stehen.

[ArnoD]

@psrelax sagte in E3DC Hauskraftwerk steuern:

Noch ein Hinweis zu deinen Einstellungen.
Bei deiner Einstellung 2 hast du als Ladeende 50% eingetragen, dieser Wert soll zum Ladeende erreicht werden.
Als Ladeschwelle hast du aber 70% eingetragen, was bedeutet, dass die Batterie bis zu diesem SoC Wert sofort mit der gesamten überschüssigen PV-Leistung geladen wird.

Die Einstellung ist generell kein Problem, aber die 50% haben damit keine Wirkung mehr.

[psrelax]

@arnod
Hast recht. Da war mal 80% drin gestanden. Weiß auch nicht, wie der Wert da rein kommt. Hab ich wohl mal daneben geklickt :-)
Danke für den Hinweis.

[bluebean]

Ich habe parallel zu psrelax auch mal meine Notreserve unterschritten. Sie steht aktuell auf Soll 26%.
Kurz vor Mitternacht habe ist dann auf 22% SOC entladen. Es wurde dann um 1 Uhr (den Zeitpunkt habe ich bei mir eingestellt) die Batterie geladen und auch hier auf einen SOC von 28%, also 2% mehr (als Spitzenwert wird im Home Assistant ganz kurz auch 29% aufgezeichnet, aber das könnte ein Rundungsartefakt sein).
Danach wird dann (siehe Screenshot S10-Portal) auf 26% entladen und gehalten (im CC bzw. HA werden dann 25% angezeigt).

[ArnoD]

@bluebean
Danke fürs Testen, aber ich verstehe nicht, warum genau 2% mehr geladen werden.
Der Code ist eigentlich einfach aufgebaut, while (!(Batterie_SOC_Proz >= nbr_Notstrom_SOC_Proz)) müsste bei Erreichen vom SOC die Schleife beenden. Es wird zwar nur alle 4 sek. abgefragt, aber ich kann mir nicht vorstellen das in 4 sek, der SOC um 2 % steigt.

Ich denke, ich muss es bei mir mal testen, wenn meine Batterie leer ist.

Nachtrag:
Habe es soeben getestet und es funktioniert so wie es soll. Batterie wird auf SOC geladen und dann gehalten. Der Batterie SOC sinkt bei mir nach einer Zeit um 1% und wird aber nicht nachgeladen, sondern gehalten. Was auch so gewollt ist. Jetzt bin ich etwas ratlos, warum es bei euch nicht geht.

Kann einer von euch mal diese log Zeilen in der Funktion einfügen und dann testen was bei euch herauskommt:

// Batterie bis auf Notstrom SOC laden
async function LadeNotstromSOC(){
    const nbr_Notstrom_SOC_Proz = (await getStateAsync(sID_Notstrom_akt)).val                               // Berechneter Notstrom SOC
    Batterie_SOC_Proz = (await getStateAsync(sID_Batterie_SOC)).val;                                        // Aktueller Batterie SOC E3DC 
    while (!(Batterie_SOC_Proz >= nbr_Notstrom_SOC_Proz)) {
        await BatterieLaden();
        await new Promise(resolve => setTimeout(resolve, 4000)); // alle 5 Sekunde wiederholen sonst übernimmt E3DC die Regelung
        Batterie_SOC_Proz = (await getStateAsync(sID_Batterie_SOC)).val;
        log(`Batterie_SOC_Proz = ${Batterie_SOC_Proz} nbr_Notstrom_SOC_Proz = ${nbr_Notstrom_SOC_Proz}`,'warn')
        if ((await getStateAsync(sID_Notrom_Status)).val == 4 || (await getStateAsync(sID_Notrom_Status)).val == 1){break;}
    }
    log(`Ende der Schleife Batterie_SOC_Proz = ${Batterie_SOC_Proz} nbr_Notstrom_SOC_Proz = ${nbr_Notstrom_SOC_Proz}`,'warn')
    bLadenAufNotstromSOC=false
}

Im LOG sollte dann diese Einträge kommen:

javascript.0	17:06:00.029	warn	script.js.Charge-Control.Charge_Control: ##{"from":"Charge-Control", "message":" -==== Batterie wird bis NotstromSOC aus dem Netz geladen ====- "}##
javascript.0	17:06:03.095	warn	script.js.Charge-Control.Charge_Control: ##{"from":"Charge-Control", "message":" -==== EMS Laden/Entladen der Batterie ist eingeschaltet ====- "}##
javascript.0	17:06:04.119	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:08.164	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:12.210	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:16.257	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:20.304	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:24.434	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:28.526	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:32.572	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:36.619	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:40.665	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:44.713	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:48.759	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 19 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:52.809	warn	script.js.Charge-Control.Charge_Control: Batterie_SOC_Proz = 20 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:52.812	warn	script.js.Charge-Control.Charge_Control: Ende der Schleife Batterie_SOC_Proz = 20 nbr_Notstrom_SOC_Proz = 20
javascript.0	17:06:54.096	warn	script.js.Charge-Control.Charge_Control: ##{"from":"Charge-Control", "message":" -==== Notstrom Reserve erreicht, Laden/Entladen der Batterie ist ausgeschaltet ====- "}##