Strompreismodul(e) Schweiz

[electron]

In der Schweiz werden ab 2026 aufgrund einer Gesetzesänderung vermehrt dynamische Strompreise angeboten werden. Ich arbeite an einem Modul für die EKZ (E-Werke Kanton Zürich). In diesem Zusammenhang drei Fragen:

- Die Schweiz hat eine andere Währung, die Einheit im UI muss Rappen statt Cent sein. Es wäre wahrscheinlich sinnvoll, bei allen Stromtarifen ein Währungs-Attribut mitzuführen. Oder das Länder-Attribut, das bisher schon bei einigen Tarifen verwendet wird, verpflichtend machen. Dann lässt sich die Währung aufgrund des Landes bestimmen. (Initial würde ich das Währung-Attribut nur bei den Schweizer Tarifen führen und als default ct im UI anzeigen)

- Es sieht so aus, als würde jeder Energieversorger seine eigene Lösung implementieren, d.h. über kurz oder lang wird die Liste der Strompreismodule sehr lang werden. Eventuell sollte über eine Strukturierung, z.B. nach Land, nachgedacht werden

- EKZ liefert die Strompreise im 15-Minuten-Rhythmus. Kann die openWB das verarbeiten, oder sollte es auf 1h-Abstände hochgerechnet werden?

[aiole]

Das sollte auch schon in DE eingeführt werden, wurde jedoch kurzfristig verschoben.
Also die Zukunft arbeitet mit 15min-Intervall.
https://www.iphone-ticker.de/dynamische ... et-262714/

[electron]

Dann gehe ich mal davon aus, dass der Eco-Modus damit umgehen kann.

Das sollte auch schon in DE eingeführt werden, wurde jedoch kurzfristig verschoben.
Also die Zukunft arbeitet mit 15min-Intervall.
https://www.iphone-ticker.de/dynamische ... et-262714/

[LutzB]

- Die Schweiz hat eine andere Währung, die Einheit im UI muss Rappen statt Cent sein. Es wäre wahrscheinlich sinnvoll, bei allen Stromtarifen ein Währungs-Attribut mitzuführen. Oder das Länder-Attribut, das bisher schon bei einigen Tarifen verwendet wird, verpflichtend machen. Dann lässt sich die Währung aufgrund des Landes bestimmen. (Initial würde ich das Währung-Attribut nur bei den Schweizer Tarifen führen und als default ct im UI anzeigen)

Die Währung seheh ich unabhängig vom Tarifmodell als globale Einstellung. Eine openWB ist normalerweise an einen Standort gebunden und sollte somit auch übergreifend nur eine Währung verwenden. Das Thema Internationalisierung (Währung, Format von Datum, Zeit und allgemeinen Zahlen sowie landesspezifische Texte) ist aktuell noch gar nicht bedacht geschweige denn geplant. Eventuell könnte man die Währung losgelöst davon schon vorziehen, sodass sie zumindest im UI an allen Stellen verwendet wird.

- Es sieht so aus, als würde jeder Energieversorger seine eigene Lösung implementieren, d.h. über kurz oder lang wird die Liste der Strompreismodule sehr lang werden. Eventuell sollte über eine Strukturierung, z.B. nach Land, nachgedacht werden

Wo wären dann Anbieter einzuordnen, die in mehreren Ländern aktiv sind?
Wenn wir das Konzept mit der globalen Ländereinstellung weiterverfolgen, dann könnten die Tarife um eine Liste mit Landeskürzeln erweitert werden. Die Anzeige wird dann auf die Tarife beschränkt, welche zu der globalen Einstellung passen. So bleibt die Liste hoffentlich übersichtlich und man bekommt nur Anbieter für den aktuellen Standort angezeigt.

- EKZ liefert die Strompreise im 15-Minuten-Rhythmus. Kann die openWB das verarbeiten, oder sollte es auf 1h-Abstände hochgerechnet werden?

Aktuell wird von 1-Stunden-Intervallen ausgegangen. Eine Erweiterung auf flexible Intervalle sollte aber mit überschaubarem Aufwand umzusetzen sein.

[Johnny79]

Aktuell wird von 1-Stunden-Intervallen ausgegangen. Eine Erweiterung auf flexible Intervalle sollte aber mit überschaubarem Aufwand umzusetzen sein.

Der Regelenergiemarkt im europäischen Verbundnetz sieht 15-Minuten Blöcke vor, daher ist es sehr wahrscheinlich dass dies auch bei dynamischen Strompreisen kommen wird.

Anbieter welche bereits am Markt sind bestätigen das auch z.B. octopus energy.

[electron]

Danke für die ausführliche Antwort! Das klingt nach einem überzeugenden Plan. Dann lasse ich aktuell mal die Währungen unangetastet und warte, bis Landes- oder Währungscode von der OpenWB kommen. Die Preise aggregiere ich einstweilen auf Stunden hoch. Das lässt sich ja schnell wieder ändern.

Die dynamischen Tarife gehen ohnehin erst im Januar live. Das Tarif-API existiert aber schon, sodass genug Zeit zum Testen bleibt.

- Die Schweiz hat eine andere Währung, die Einheit im UI muss Rappen statt Cent sein. Es wäre wahrscheinlich sinnvoll, bei allen Stromtarifen ein Währungs-Attribut mitzuführen. Oder das Länder-Attribut, das bisher schon bei einigen Tarifen verwendet wird, verpflichtend machen. Dann lässt sich die Währung aufgrund des Landes bestimmen. (Initial würde ich das Währung-Attribut nur bei den Schweizer Tarifen führen und als default ct im UI anzeigen)

Die Währung seheh ich unabhängig vom Tarifmodell als globale Einstellung. Eine openWB ist normalerweise an einen Standort gebunden und sollte somit auch übergreifend nur eine Währung verwenden. Das Thema Internationalisierung (Währung, Format von Datum, Zeit und allgemeinen Zahlen sowie landesspezifische Texte) ist aktuell noch gar nicht bedacht geschweige denn geplant. Eventuell könnte man die Währung losgelöst davon schon vorziehen, sodass sie zumindest im UI an allen Stellen verwendet wird.

- Es sieht so aus, als würde jeder Energieversorger seine eigene Lösung implementieren, d.h. über kurz oder lang wird die Liste der Strompreismodule sehr lang werden. Eventuell sollte über eine Strukturierung, z.B. nach Land, nachgedacht werden

Wo wären dann Anbieter einzuordnen, die in mehreren Ländern aktiv sind?
Wenn wir das Konzept mit der globalen Ländereinstellung weiterverfolgen, dann könnten die Tarife um eine Liste mit Landeskürzeln erweitert werden. Die Anzeige wird dann auf die Tarife beschränkt, welche zu der globalen Einstellung passen. So bleibt die Liste hoffentlich übersichtlich und man bekommt nur Anbieter für den aktuellen Standort angezeigt.

- EKZ liefert die Strompreise im 15-Minuten-Rhythmus. Kann die openWB das verarbeiten, oder sollte es auf 1h-Abstände hochgerechnet werden?

Aktuell wird von 1-Stunden-Intervallen ausgegangen. Eine Erweiterung auf flexible Intervalle sollte aber mit überschaubarem Aufwand umzusetzen sein.