Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[psrelax]

@Thomas-Braun

Würde ich ja gerne. Leider wird er nicht wirklich supportet.
Hab schon einen Issue eröffnet, rührt sich aber nix.

Ist der Adapter: https://github.com/DrozmotiX/ioBroker.esphome
Und hier der Issue: https://github.com/DrozmotiX/ioBroker.esphome/issues/340

Eine andere Möglichkeit wie auf MQTT umzusteigen, hab ich nicht hin bekommen.
Aber das ist keine Thema für hier.

[Thomas Braun]

@psrelax

Das hat aber mit der nodejs-Version nix zu tun.

[psrelax]

@Thomas-Braun
Der Fehler ist aber erst aufgetreten, als ich nodejs geupdatet hatte.

[as]

das preisbasierte laden hat vom 31->.1.1.26 nicht so richtig funktioniert
es wurde am 31 nochmal voll geladen obwohl akku bis morgens zum 10cent günstigeren preis gereicht hätte dachte das mehrfach auf optimale zeiten u preise geschaut wird
hat das noch jemand erlebt

[psrelax]

@as
Das hab ich nicht gesehen, da ich Tibber abgeschalten habe aber die Prognose von ChargeControl hatte am 01.01.2026 bei 0 angefangen. Vielleicht hängt das damit zusammen.

[as]

-...............................

[mbosch]

Wenn von der Version 1.4.3 auf die 1.4.4 update bekomme ich diese Logeinträge:

2026-01-18 10:11:17.349 - warn: e3dc-rscp.0 (2087) TAG_EMS_REQ_GET_IDLE_PERIODS_2 has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.349 - warn: e3dc-rscp.0 (2087) TAG_EMS_REQ_DPP_PRICE_BASED_WB_CHARGE_ACTIVE has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.349 - warn: e3dc-rscp.0 (2087) TAG_EMS_REQ_DPP_PRICE_BASED_BATTERY_CHARGE_ACTIVE has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.349 - warn: e3dc-rscp.0 (2087) TAG_EMS_REQ_DPP_PRICE_LIMIT_BATTERY has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.349 - warn: e3dc-rscp.0 (2087) TAG_EMS_REQ_DPP_SOC_BATTERY has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.349 - warn: e3dc-rscp.0 (2087) TAG_EMS_REQ_DPP_MONTHS_ACTIVE has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.349 - warn: e3dc-rscp.0 (2087) TAG_EMS_REQ_DPP_PRICE_BASED_BATTERY_CHARGE_ENABLED has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_I_BAT has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_U_BAT has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_P_BAT has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_I_DCL has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_U_DCL has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_P_DCL has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_FIRMWARE_VERSION has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_FPGA_FIRMWARE has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_SERIAL_NUMBER has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_BOARD_VERSION has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_STATUS has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_STATUS_AS_STRING has no assigned polling interval - assuming 'M' - please check io-package.json
2026-01-18 10:11:17.350 - warn: e3dc-rscp.0 (2087) TAG_DCDC_REQ_DEVICE_STATE has no assigned polling interval - assuming 'M' - please check io-package.json

Hab ich was übersehen beim Update?
Was muss ich tun, damit die Meldungen weg gehen?

[ArnoD]

@as sagte in E3DC Hauskraftwerk steuern:

das preisbasierte laden hat vom 31->.1.1.26 nicht so richtig funktioniert
es wurde am 31 nochmal voll geladen obwohl akku bis morgens zum 10cent günstigeren preis gereicht hätte dachte das mehrfach auf optimale zeiten u preise geschaut wird
hat das noch jemand erlebt

Um da was sagen zu können, benötige ich immer die LOG Einträge.

[ArnoD]

@mbosch
Falsches Forum.
Wenn du mit dem E3DC-rscp Adapter Probleme hast, dann bitte über Github ein Issue eröffnen.
e3dc-rscp Github

[as]

@ArnoD bekomme das log nicht herunter geladen
heute erneut Abweichung vom ideal
Nachts nicht geladen 34c - bis zur peak Zeit 51c entladen - ab peak Zeit entladesperre gesetzt 7:30 bis 8:45
das setzten der entladung während peak wird häufig gesetzt zusammenhang mit sehr großer Abweichung des Preises oder über gewissem Level ?
gibt es andere Versionen (älter) die dieses anders gemacht haben wenn es keine neuere Versionen geben wird

[ArnoD]

@as
ohne LOG Einträge ist es unmöglich zu erraten, warum bei dir was nicht so läuft wie es soll.

gibt es andere Versionen (älter) die dieses anders gemacht haben wenn es keine neuere Versionen geben wird

Dazu müsste ich erst verstehen, was anders gemacht werden soll.

[as]

@ArnoD iobroker.2026-01-20.log.gz

[as]

@ArnoD ist die LadesteuerungTibber anpassbar für zb OctopusHEAT mit festen Zeiten zum Laden oder gar Mittags nachladen?
da diese nacht zu 33c nicht geladen wurde->dadurch zu 39c morgens akku leer war um Mittags zu 32c nachladen zu wollen

[ArnoD]

@as
Ich benötige das LOG mit aktiviertem LogLevel 4 oder 5.
Das Kannst du aktivieren, indem du bei der Objekt-ID 0_userdata.0.TibberSkript.USER_ANPASSUNGEN.LogLevel 4 oder 5 einträgst.

Wenn der Fehler wieder auftritt, dann bitte mir auch die Uhrzeit mitteilen, wo das TibberScript nicht so funktioniert hat, wie du es dir vorstellst.

Wenn du zu festen Zeiten einfach laden willst, kannst du das über VIS indem du das Tibber Skript deaktivierst und Laden aktivierst:

Wenn du das automatisch machen willst, kannst du über ein Script die Objekt-ID`s direkt ändern.

Ich werde das Tibber Skript nicht mehr weiter entwickeln, sondern nur noch Fehler beheben.

[psrelax]

@arnod

Kannst du vielleicht mal das Verhalten bei dir anschauen, ob es bei dir auch so auftritt?
Ich habe Notstrom Sockel und Notstrom min beide fest auf 25% eingestellt inkl. Nachladen in der Nacht.
Nachladen funktioniert einwandfrei aber kurz darauf wird wieder ein paar Prozent entladen. das ist jede Nacht so.

Wie du im Screenshot siehst, wird von 02:00-02:30 auf 25% geladen und von 03:00-03:45 auf ca. 21% entladen.
Hier bleibt es dann den ganzen Tag stabil.
Vielleicht kannst du das Verhalten bei dir auch nachstellen.
Danke schonmal.

Nur so nebenbei.
Ich bin jetzt wieder total glücklich mit meinem neuen Stromanbieter. Nicht mehr auf den Preis schauen zu müssen ist schon eine große Erleichterung :-)
Die Action mit Tibber ist nur "ertragbar", wenn man sich dadurch auch kräftig was sparen könnte. Aber das ist mittlerweile nicht mehr der Fall.

[ArnoD]

@psrelax
Bei mir bleibt der Notstrom SOC stabil.
Das entladen wir nur freigegeben, wenn die PV-Prognose hoch ist, was ja gewollt ist.

[psrelax]

@ArnoD
Ich hab jetzt mal Logging eingeschaltet und das Laden und Entladen einmal nach geprüft.

Eingestellt ist 25% Notstrom.
Geladen wird bis 27% -> für mich wird hier zu spät abgeschaltet
Eine halbe Stunde später wird entladen bis 24%.
Nach dem Entladen fällt für eine weitere Stunde der SOC kontinuierlich auf 20% (rot eingekreist).

Bis auf die letzte kontinuierliche Entladung auf 20% sollte hier noch etwas mit dem Script nicht ganz passen. Zu hoch laden und danach wieder entladen sollte nicht sein.
Was meinst du?
Ich hab dir vorsichtshalber die Log angehängt.
log.zip

[azzkikrboy]

Hallo @arnod,

Kurze Frage zur EVCC Integration.
Seit kurzem wird jetzt endlich die E3/DC Multiconnect II Wallbox von EVCC unterstützt. Im Unterschied zur normal WB wird dieser allerdings über RSCP über das Hauskraftwerk gesteuert, also ist die WB am HKW angemeldet.
In deinem Script gibt es Pfade zur WB die nicht von E3/DC gesteuert werden.

Muss ich dann diesen Pfad verwenden, da die WB ja von EVCC gesteuert wird? Oder wie soll das funktionieren?

[ArnoD]

@psrelax
Danke für die detaillierte Beschreibung.

Kannst du mal bei dir bitte Prüfen was um 2:00 Uhr passiert.
Da wird auf einmal das Laden/Entladen freigeschaltet.
Das kann eigentlich nur sein, wenn die Freigabe Tibber Laden = true ist.

Hast du das Tibber Script noch im Einsatz ??

[ArnoD]

@azzkikrboy

Die ObjektID 10_Path_WallboxLadeLeistung_1 und 2 sind nur zu befüllen, wenn die Leistungswerte der Wallbox im Hausverbrauch enthalten sind und nicht automatisch abgezogen werden.
Das ist dann der Fall, wenn keine Wallbox beim E3DC angemeldet ist und E3DC somit die Leistungswerte der Wallbox nicht mitbekommt.
In deinem Fall werden die Leistungswerte Wallbox ja ganz normal an dein Hauskraftwerk übertragen, also beide ObjektID`s von CC leer lassen.