NEWS
E3DC Hauskraftwerk steuern
-
Ich habe jetzt mal einen zusätzlichen Versuch gemacht und in den Astro-Einstellungen einen Versatz von 120 min im Sonnenaufgang und Sonnenuntergang eingestellt (siehe Screenshot).
Nach Neustart vom JS-Adapter und des Skripts werden im CC unverändert Regelzeit: 07:21 Uhr - 13:36 Uhr und
Ladeende: 14:34 Uhr angezeigt. Oder muss ich zum Test tatsächlich bis morgen warten?PS:
und hier sind mal die Astro-Zeiten in den Objekten des JS-Adapters.
Da steht für solarNoon eine Zeit von 10:51 Uhr. Wenn die im Skript verwendet wird und ich davon 3:30 h offset abziehe, lande ich bei 7:21 Uhr, das was auch angezeigt wird für den Regelbeginn.
Eigentlich müsste er doch aber die Ortszeit von solarNoon als Bezug nehmen, also 12:51 Uhr.
Und das Ganze erklärt für mich nicht, warum dann auf die richtigen Werte geregelt wird, also auf die angezeigten Werte 2 Stunden draufgeschlagen werden.Oder ist es schlicht einfach so, dass nur UTC-Zeiten angezeigt werden, ansonsten aber auf die Ortszeiten gereget wird? Doch warum war das vor ein paar Tagen anders?
-
@bluebean sagte in E3DC Hauskraftwerk steuern:
Ich habe jetzt mal einen zusätzlichen Versuch gemacht und in den Astro-Einstellungen einen Versatz von 120 min im Sonnenaufgang und Sonnenuntergang eingestellt (siehe Screenshot).
Nach Neustart vom JS-Adapter und des Skripts werden im CC unverändert Regelzeit: 07:21 Uhr - 13:36 Uhr und
Ladeende: 14:34 Uhr angezeigt. Oder muss ich zum Test tatsächlich bis morgen warten?Hier kannst du nichts an den Astro Zeiten ändern und haben nur bedingt was damit zu tun.
Diese Einstellungen sind so viel ich weiß für die Variable javascript.0.variables.isDayTime und javascript.0.variables.isDaylightSaving. Da ich diese nicht verwende, kann ich dir aber auch nicht mehr darüber sagen.und hier sind mal die Astro-Zeiten in den Objekten des JS-Adapters.
Da steht für solarNoon eine Zeit von 10:51 Uhr. Wenn die im Skript verwendet wird und ich davon 3:30 h offset abziehe, lande ich bei 7:21 Uhr, das was auch angezeigt wird für den Regelbeginn.
Eigentlich müsste er doch aber die Ortszeit von solarNoon als Bezug nehmen, also 12:51 Uhr.
Und das Ganze erklärt für mich nicht, warum dann auf die richtigen Werte geregelt wird, also auf die angezeigten Werte 2 Stunden draufgeschlagen werden.Die Astro-Zeiten in den Objekten des JS-Adapters sind die, was ich auch verwende.
solarNoon 10:51 Uhr minus offset Regelbeginn 3:30 = 07:21 Uhr, was ja auch mit der Anzeige stimmt.
Da ich da nichts geändert habe, ist das eigentlich schon immer so.
Wie bereits weiter oben geschrieben rechne ich im Script nicht mit den lokalen Zeiten, sondern werden generell alle Zeiten in Millisekunden seit dem 1. Januar 1970, 00:00:00 UTC umgewandelt, um die gleiche Zeitbasis zu haben. Ob die Astrozeiten UTC sind und jetzt MEZ Zeiten oder umgekehrt spielt für die Berechnungen im Script keine Rolle. Die Anzeige in vis sollte eigentlich die lokale Zeit anzeigen.
Ich schaue mir das mal an, ob sich da was geändert hat. -
@bluebean sagte in E3DC Hauskraftwerk steuern:
solarNoon
Also bei mir wird alles in der lokalen Zeit richtig angezeigt:
Was hast du bei deinen Adaptereinstellungen den alles geändert?
Nachtrag:
Kannst du mal folgende Änderung bei dir testen, ob es dann richtig angezeigt wird.
Ab der Zeile 1686 in der Funktion MEZ_Regelzeiten() gleich am Anfang diese Änderung vornehmen:RB_AstroSolarNoon = new Date(getAstroDate("solarNoon")); RE_AstroSolarNoon = new Date(getAstroDate("solarNoon")); LE_AstroSunset = new Date(getAstroDate("sunset"));
-
@ArnoD
Hab glaub ich den Fehler gefunden, warum bei mir der Notstrom nicht nachgeladen wird.
Der Schalter aus VIS stimmt mit der Variablen unter Objekte nicht überein.Im Script wird folgendes erzeugt:
const sID_NotstromAusNetz =`${instanz}.${PfadEbene1}.${PfadEbene2[1]}.bNotstromAusNetz`; // Vorwahl in VIS true = Notstrom aus Netz nachladen
Das b bei NotstromAusNetz ist falsch und stimmt nicht mit VIS überein.
-
@arnod said in E3DC Hauskraftwerk steuern:
Also bei mir wird alles in der lokalen Zeit richtig angezeigt:
Welche JS-Adapterversion hast Du? Wird Dir in den Astro-Einstellungen bei den Tageszeiteinstellungen auch die UTC- und Ortszeit angegeben (siehe meine Screenshots)?
Was hast du bei deinen Adaptereinstellungen den alles geändert?
Gar nichts. Systemeinstellungen für den Ort übernehmen ist eingestellt, "Erstelle Zustände für alle Astrozeiten" ist aktiviert. Und die allgemeinen Einstellungen sehen so aus:
Kannst du mal folgende Änderung bei dir testen, ob es dann richtig angezeigt wird.
Ab der Zeile 1686 in der Funktion MEZ_Regelzeiten() gleich am Anfang diese Änderung vornehmen:RB_AstroSolarNoon = new Date(getAstroDate("solarNoon")); RE_AstroSolarNoon = new Date(getAstroDate("solarNoon")); LE_AstroSunset = new Date(getAstroDate("sunset"));
Macht keinen Unterschied.
-
@psrelax said in E3DC Hauskraftwerk steuern:
Das b bei NotstromAusNetz ist falsch und stimmt nicht mit VIS überein.
Das 'b' im Skript erscheint mir schon richtig, ich denke hier muss man das 'b' beim Schalter im VIS ergänzen. Hab's bei mir gerade gemacht, damit wird dann das Objekt korrekt auf true gesetzt (vorher war es auf fals). Das Objekt NotstromAusNetz scheint mir überflüssig zu sein.
-
@bluebean
Ist mir schon klar, dass ich es in Vis ändern kann. Das b scheint mir nur unlogisch. Ich denke das ist im Script einmal falsch eingesetzt worden, da es ja mal ohne b war.
Wieso denkst du, es ist überflüssig? -
@psrelax said in E3DC Hauskraftwerk steuern:
Das b scheint mir nur unlogisch. Ich denke das ist im Script einmal falsch eingesetzt worden, da es ja mal ohne b war.
Schau mal im Skript ab Zeile 146, das werden diverse Boolsche Variablen deklariert - das 'b' ist demzufolge kein einmaliger Verschreiber (auch wenn das b nicht durchgängig für alle entsprechenden Variablen benutzt ist).
-
@arnod said in E3DC Hauskraftwerk steuern:
Also bei mir wird alles in der lokalen Zeit richtig angezeigt:
Ich verstehe zwei Dinge nicht:
- Warum werden in den Objekten bei Dir lokale Zeiten angegeben und bei mir UTC?
- Und warum wird bei mir - trotz UTC Zeiten in den Objekten - von Deinem Skript trotzdem auf die lokalen Zeiten geregelt, wie man im Screenshot von heute sieht?
Hilft eventuell das noch weiter? https://forum.iobroker.net/topic/26029/astro-zeit-stimmt-nicht
-
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. -
@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.
-
@bluebean
OK, das erklärt auch, warum new Date() keinen Unterschied macht, wenn deine Systemzeit auf UTC eingestellt war. -
Jaja, die Zeit, die liebe Zeit...
Weil das so wichtig ist gibt es dafür z. B. iniob diag
eine eigene Sektion. Und auch im
iob fix
wird eine Änderung vorgeschlagen, wenn es da Hinweise auf eine falsche Konfiguration gibt.
-
@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 ). 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. -
@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.
-
@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.
-
@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.
-
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.
- Fehler Objekt ID
-
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.
-
@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