Monatsrückblick Oktober 2026 ist online!

[tippy88]

Aktuelle Test Version	0.7.0
Veröffentlichungsdatum	13.07.206
Github Link	https://github.com/tipp88/ioBroker.octopus-energy-monitor

Hallo zusammen,

der Adapter ioBroker.octopus-energy-monitor wurde frisch im Latest (Beta) Repository veröffentlicht und sollte dort innerhalb der nächsten 24 Stunden auftauchen.

Dieser Adapter wurde entwickelt, um die täglichen Stromverbrauchsdaten und Tarife von Octopus Energy (über die Kraken-GraphQL-API) abzurufen, Kosten zu kalkulieren und im ioBroker bereitzustellen. Optional kann der Adapter auch mit Inexogy (über die Discovergy/Statistics-API) verbunden werden, um Messunterschiede zwischen deinem physischen Smart Meter und der Abrechnung des Anbieters abzugleichen.

ℹ️ Der Adapter läuft vollständig Standalone mit Octopus Energy! Ein Inexogy-Smartmeter ist nicht erforderlich.

🌟 Hauptfeatures:

• Kraken GraphQL API-Support: Abruf präziser Verbrauchsdaten direkt über deinen Octopus-Account.
  Tarif- & Slot-Erkennung: Automatische Ermittlung deines aktiven Tarifs (z. B. Intelligent Octopus Go) und der dazugehörigen Zeitfenster ohne manuelle Konfiguration.
• Kostenberechnung: Automatische Berechnung der täglichen, monatlichen und jährlichen Stromkosten in Euro (€) basierend auf deinen tatsächlichen Slot-Tarifen.
• Steuerung für Smart Charging: Direktes Ein- und Ausschalten des Smart Charging (Suspend/Resume) für kompatible Geräte (E-Autos/Ladestationen).
• §14a EnWG Preisberechnung (Optional): Berücksichtigung reduzierter Netzentgelte für steuerbare Verbrauchseinrichtungen (NT/HT/ST-Zeiten).
• Benutzerdefinierte Abrechnungszeiträume: Zusammenfassung des Verbrauchs nach dem individuellen Abrechnungszeitraum (z. B. ab dem 18. eines Monats).
• Messdaten-Abgleich (Optional mit Inexogy): Automatischer nächtlicher Vergleich zwischen Octopus- und Inexogy-Daten mit konfigurierbarem Schwellenwert zur Erkennung von Abrechnungsfehlern.

🛠️ Voraussetzungen & Installation:
Node.js: >= 22
Admin-Adapter: >= 7.8.23
Installation: Sobald der Adapter im Repository sichtbar ist, einfach über die normale Adaptersuche installieren (aktives Latest-Repository vorausgesetzt). Alternativ kann er direkt über GitHub/NPM installiert werden

📝 Feedback erwünscht:
Ich freue mich über jedes Feedback und Tests von euch! Besonders interessieren mich:

Funktioniert die automatische Tarif- und Slot-Erkennung bei euch fehlerfrei?
Werden die Stromkosten korrekt berechnet?
Läuft die Smart Charging-Steuerung reibungslos?
Falls ihr Inexogy nutzt: Werden die Abweichungen korrekt abgeglichen?
Gibt es Darstellungsfehler in den angelegten Objekten?

Vielen Dank im Voraus für eure Unterstützung beim Testen!

Viele Grüße,
tippy88

[tippy88]

Aktuelle Test Version	1.0.0
Veröffentlichungsdatum	27.08.206
Github Link	https://github.com/tipp88/ioBroker.octopus-energy-monitor

Adapter ist jetzt auf 1.0.0 und wird demnächst auf das Stable repo beantragt.
Leider bisher kein Feedback von Testern, läuft aber bei mir seit Monaten stabil.

[lesiflo]

Hi, hab den Adapter installiert und läuft soweit. Allerdings bekomme ich Meldungen im Log:

Octopus usage API GraphQL error for 2026-09-09: KT-CT-1199: There were too many requests. Please try again later. Further Octopus requests are skipped until the next synchronization.

Einstellungen sind wie folgt:

§14A ist nicht aktiv.
Version ist v1.1.0

Kann das eventuell mit evcc zusammenhängen? Dort ist habe ich auch Octopus Energy Deutschland als Tarif hinterlegt. Sind das dann zu viele Anfragen ?

[tippy88]

@lesiflo sagte:

Hi, hab den Adapter installiert und läuft soweit. Allerdings bekomme ich Meldungen im Log:

Octopus usage API GraphQL error for 2026-09-09: KT-CT-1199: There were too many requests. Please try again later. Further Octopus requests are skipped until the next synchronization.

Einstellungen sind wie folgt:

§14A ist nicht aktiv.
Version ist v1.1.0

Kann das eventuell mit evcc zusammenhängen? Dort ist habe ich auch Octopus Energy Deutschland als Tarif hinterlegt. Sind das dann zu viele Anfragen ?

Die Meldung im Log ist Normal beim ersten Adapterlauf. Er versucht die letzten 30 Tage zu Synchronisieren und läuft nach ca 15 Tagen in das dynamische Quota Limit.
Octopus Energy hat das kürzlich eingeführt, nennt aber keine harte Quota Grenze sondern dynamisch. Im Standardbetrieb nachdem alle rückwirkenden Tage synchronisiert sind sollte die Warnung verschwinden.
Gemäß deinen Einstellungen sollte nach 1-2h alles normal laufen und die Warnung nicht mehr kommen. Der Adapter ruft automatisch nur fehlende Tage ab.

[lesiflo]

Ok, der Adapter läuft seit gestern. Es sind auch einige Daten reingekommen. Der Tarif wurde gestern freigeschaltet, im Octopus Portal sind mehr Daten sichtbar.

[lesiflo]

Hi,
woher kommt dieser Wert?

Wenn ich die Grundgebühr von 13,90€ und den Verbrauch von 1,63€ nehme passt das nicht.

[tippy88]

@lesiflo sagte:

im Octopus Portal sind mehr Daten sichtbar.

Was fehlt dir?

@lesiflo sagte:

Wenn ich die Grundgebühr von 13,90€ und den Verbrauch von 1,63€ nehme passt das nicht.

Was hat der Adapter denn unter Info.Rates abgerufen und was steht unter info.monthlyStandingCharge ?
Der Adapter berechnet nur Tage wo Werte vorliegen. Du schreibst am 30.Sept, damit ist der Tag nicht abgeschlossen und es liegt kein Verbrauch für den 30. vor. 13,90€/30*29=13,44 + 1,63 = 15,07 was du in dem DP siehst.

[binarie]

Hallo All,
Tarifname : Octopus Heat
Tarifzeiten:
const ZEITEN_NIEDRIG = [2, 3, 4, 5, 12, 13, 14, 15];
const ZEITEN_HOCH = [18, 19, 20]; // Rest = Zeiten_Standard
Preis Tarife : wird vom Adapter richtig angezeigt

Um die Daten des Adapter zu vergleichen, habe ich mir mit Hilfe der KI ein kleines Script erstellt, das nur die History Daten downloadet. Dabei sind mir zwei Fehler bei der Verarbeitung der History-Daten (historyJson) gestoßen:

1. Falsche Zuordnung der Tarifzeiten (Berechnungsfehler):
   Der Adapter berechnet die Zeiten für meine Tarife falsch. Anstatt der tatsächlichen 8 Stunden für den Niedrigtarif (02:00 - 06:00 und 12:00 - 16:00 Uhr) wertet der Adapter insgesamt 15 Stunden als Niedrigtarif (00:00 - 06:00, 12:00 - 18:00 und 21:00 - 24:00 Uhr). Die Standard-Zeiten am Nachmittag und in der Nacht werden fälschlicherweise dem Niedrigtarif zugeschlagen. Dadurch sind die berechneten Kosten ('totalCost') zu niedrig und der Verbrauch für den Niedrigtarif massiv überhöht.

2. Fehlende Tage in der History werden nicht nachgetragen:
   Wenn der Netzbetreiber die Daten noch nicht geliefert hat, speichert der Adapter für diesen Tag Nullen im Array. Wenn die Daten ein oder zwei Tage später in der API verfügbar sind, überschreibt der Adapter diese fehlerhaften Null-Einträge nicht mehr. Außerdem gibt es keine Möglichkeit, die History für fehlende Tage manuell neu abzurufen.

Vielleicht liegt der Fehler aber auch an meinen Einstellungen. Ich habe alle Standardeinstellung übernommen und nur meine Persönlichen Daten eingegeben. Da mein Tarif auch richtig angezeigt wird, gehe ich von einem Berechnungsfehler aus.

Hier ein Beispiel 1-3 November:

Meine erstellten Daten per Script:
{"date":"2026-11-01","timestamp":1793487600000,"total":21,"totalCost":4.66,"niedrig":11.024,"niedrigCost":2.08,"hoch":0.072,"hochCost":0.02,"standard":9.904,"standardCost":2.56},{"date":"2026-11-02","timestamp":1793574000000,"total":38.144,"totalCost":8.13,"niedrig":24.683,"niedrigCost":4.65,"hoch":0.12,"hochCost":0.04,"standard":13.341,"standardCost":3.44},{"date":"2026-11-03","timestamp":1793660400000,"total":26.701,"totalCost":5.67,"niedrig":17.603,"niedrigCost":3.31,"hoch":0.118,"hochCost":0.04,"standard":8.98,"standardCost":2.32},

Adapter:
{"date":"2026-11-01","timestamp":1793487600000,"total":21,"totalCost":3.99,"niedrig":20.556,"niedrigCost":3.87,"hoch":0.072,"hochCost":0.02,"standard":0.372,"standardCost":0.1},{"date":"2026-11-02","timestamp":1793574000000,"total":38.144,"totalCost":7.22,"niedrig":37.701,"niedrigCost":7.1,"hoch":0.12,"hochCost":0.04,"standard":0.323,"standardCost":0.08},{"date":"2026-11-03","timestamp":1793660400000,"total":26.701,"totalCost":5.07,"niedrig":26.142,"niedrigCost":4.92,"hoch":0.118,"hochCost":0.04,"standard":0.441,"standardCost":0.11},

Bei Bedarf kann ich gerne Log-Auszüge oder Testdaten zur Verfügung stellen.

tschüss B.

[tippy88]

@binarie Danke für die genaue Beschreibung und die Vergleichswerte.

Den Fehler bei der Tarifzuordnung konnte ich nachvollziehen. Bisher wurde pro Tarif nur das erste Zeitfenster berücksichtigt. Nicht zugeordnete Zeiten wurden anschließend dem ersten Tarif zugeschlagen. Daher die falsche Aufteilung und die zu niedrigen Kosten bei Octopus Heat.
Der Fix ist jetzt im Master-Branch auf GitHub verfügbar. Bitte installiere zum Testen die aktuelle GitHub-Version, nicht die Version aus Stable/Latest. Die Versionsnummer ist weiterhin 1.1.0.

Betroffene Tage werden innerhalb des eingestellten Synchronisations- und Aufbewahrungszeitraums einmalig neu berechnet. Den Objektbaum musst du nicht löschen. Bei einem API-Limit wird die Korrektur im nächsten Sync fortgesetzt.

Zu den fehlenden Tagen: Tage ohne Werte oder mit Gesamtverbrauch 0 werden bereits erneut abgefragt, solange sie im Synchronisationszeitraum liegen. Sollten sie weiterhin leer bleiben, schick bitte den eingestellten Synchronisationszeitraum und einen Debug-Log mit einem betroffenen Datum. Zugangsdaten und persönliche Angaben bitte entfernen. Außerdem ein Screenshot aus der Octopus App der für den betroffenen Tag tatsächlich andere Werte als der Adapter zeigt.

Gib bitte Rückmeldung, ob Tarifaufteilung und Kosten danach zu deinen Vergleichswerten passen. Für mich lässt sich das schwer testen, da ich nur den Intelligent Go Tarif habe und andere Tarife nur simulieren kann.

[tippy88]

Aktuelle Test Version	1.2.0
Veröffentlichungsdatum	09.11.206
Github Link	https://github.com/tipp88/ioBroker.octopus-energy-monitor

Hallo zusammen,

mit Version 1.2.0 über das Iobroker Beta/Latest Repository gibt es einige Neuerungen und Korrekturen für den Octopus Energy Monitor. Ich würde mich freuen, wenn ihr den neuen Release testet und hier Rückmeldung gebt.

Was ist neu?

• Historische Preise: Verbrauchskosten und Grundpreise werden anhand der zum jeweiligen Zeitpunkt gültigen Vertrags- und Preisdaten berechnet. Fehlen eindeutige Preise, bleibt der Verbrauch erhalten; die Kosten werden als nicht verfügbar gekennzeichnet.
• Optionale Neuberechnung: Bereits gespeicherte Tage können über eine neue Einstellung mit historischen Preisen neu berechnet werden, ohne ihre vorhandenen Intervalle erneut nach InfluxDB zu exportieren.
• Robustere API-Abfragen: Verbesserungen bei Token-Erneuerung, Rate-Limits, Wiederholungen und dem Abruf mehrseitiger Antworten.
• Neue Diagnose-Datenpunkte: Sync-Status, API-Fehler und die Vollständigkeit der Viertelstundenwerte werden sichtbar.
• Zeitfenster und Zeitumstellung: Korrekturen bei mehreren Tarifzeitfenstern sowie Tagen mit 23 oder 25 Stunden.
• Weniger Discrepancy-Warnungen: Unveränderte Abweichungen werden nicht ständig erneut gemeldet. Tage mit 0 Verbrauch bleiben vom Vergleich ausgeschlossen und werden weiterhin erneut abgefragt.

Außerdem können die zeitabhängigen §14a-Netzentgelte für Modul 3 optional direkt von Octopus abgerufen werden. Bei nicht nutzbaren Daten bleiben die manuellen Einstellungen aktiv. Die API-Antwort und der konkrete Fallback-Grund lassen sich unter info.api.gridFees prüfen.

Besonders gesucht sind Tester mit tatsächlich aktiviertem Modul 3. Bei meinem Anschluss liefert Octopus zwar NT/ST/HT-Netzentgelte, meldet aber weiterhin MODULE_1. Abruf und Fallback konnte ich damit prüfen, die automatische Modul-3-Berechnung noch nicht vollständig.

Bitte testet den neuesten Release 1.2.0 auch im normalen Octopus-, Inexogy- oder Kombibetrieb. Interessant sind insbesondere Tarifwechsel, Abrechnungsperioden und die EnWG-Berechnung.

Bei Problemen bitte Betriebsart, relevante Einstellungen und Logs dazuschreiben – Zugangsdaten und persönliche Angaben vorher entfernen.

Danke fürs Testen!