-
Notifications
You must be signed in to change notification settings - Fork 107
Feature/tibber/quarter hourly prices #2801
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/tibber/quarter hourly prices #2801
Conversation
|
Den Diagrammen ist es ziemlich egal, in welchem Abstand die Werte sind. Es wird eine Zeitachse verwendet und darauf die Timestamps abgebildet. Eine Anpassung im Status oder den offiziellen Themes ist daher zu 99% nicht erforderlich. |
aber dafür habe ich das hier auskommentiert: 210 pricelist.remove(price)$
211 # # jetzt prüfen auf Start mit aktueller Stunde und Stundenabstände$
212 # if len(pricelist) > 0:$
213 # timestamp_prev = float(pricelist[0][0]) # erster Listeneintrag$
214 # starttime_utc = _get_utcfromtimestamp(float(pricelist[0][0]))$
215 # if _get_utcfromtimestamp(timestamp_prev) == now_full_hour: # erster Preis ist der von aktueller Stunde $
216 # for index, price in enumerate(pricelist[:]): # über Kopie der Liste iterieren, um das Original zu manipulieren$
217 # if index > 0:$
218 # timestamp = float(price[0])$
219 # secondsdiff = timestamp - timestamp_prev$
220 # timestamp_prev = float(price[0])$
221 # if secondsdiff != 3600.0: # ist Abstand <> 1h dann ab hier Liste löschen$
222 # del pricelist[index:]$
223 # break$
224 # else:$
225 # return []$
226 return pricelist$ |
|
@benderl : muss ich mich wirklich um den timeout-Fehler kümmern? |
|
Welchen Timeout Fehler? Ich sehe aktuell nur einen fehlgeschlagenen Test im Tibber Modul. Da passt das erwartete Ergebnis nicht. |
This comment was marked as resolved.
This comment was marked as resolved.
Hast Du einen besseren Vorschlag? |
Wo soll die Datei liegen? Ich finde die aktuell nicht. |
This comment was marked as outdated.
This comment was marked as outdated.
|
|
Puhhh.. Geschafft... TODO: viertelstündliches Update des MQTT, damit der aktuelle Preis ins Frontend kommt... |
|
Warte bitte erstmal mit weiteren Implmentierungen an deiner Lösung. Mit dieser legst Du dich auf 60 und 15 Min fest. Die Info, ob die Preise alle 15 oder 60 Min übermittelt werden, sollte nur im Stromtarif-Modul relevant sein und keine Abhängigkeit von den Stromtarifmodulen ins Ziel- und Ecoladen ziehen. Die Preise werden mit Timestamps übermittelt und sind bis zum folgenden Timestamp gültig, das sollte als Info ausreichen. |
Im Zielladen (Option.get_loading_hours()) wird die Länge der übermittelten Zeit-Intervalle berechnet und nicht übergeben. da wurde keine neue Abhängigkeit eingefügt. Das neue Property in Die einzige Stelle im Backed, die tatsächlich auf 60/14 Minuten festgelegt ist ist |
packages/helpermodules/timecheck.py
Outdated
| def create_unix_timestamp_current_full_hour() -> int: | ||
| full_hour = datetime.datetime.fromtimestamp(create_timestamp()).strftime("%m/%d/%Y, %H") | ||
| return int(datetime.datetime.strptime(full_hour, "%m/%d/%Y, %H").timestamp()) | ||
|
|
||
|
|
||
| def create_unix_timestamp_current_quarter_hour() -> int: | ||
| def round_to_quarter_hour(current_time: float, quarter_hour: int = 900) -> float: | ||
| log.debug(f"current time: {current_time} => modified: {current_time - (current_time % quarter_hour)}") | ||
| return current_time - (current_time % quarter_hour) | ||
| return int(round_to_quarter_hour(datetime.datetime.today().timestamp())) | ||
|
|
||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LKuemmel was hältst Du davon?
| def __calculate_price_timeslot_length(self, prices: dict[str, int]) -> int: | |
| first_timestamps = sorted(list(prices.keys()))[:2] | |
| return int(first_timestamps[1]) - int(first_timestamps[0]) | |
| def select_unix_timestamp_current_price_slot(prices: dict[str, float]) -> int: | |
| now = int(create_timestamp()) | |
| price_timeslot_seconds = self.__calculate_price_timeslot_length(prices) | |
| return next(iter( [int(timestamp) for timestamp in list(prices.keys()) if ( | |
| int(timestamp) <= now and int(timestamp) >= now - price_timeslot_seconds | |
| )])) |
8ebfdfa to
939a371
Compare
|
Erledigt ist:
|
a60fcde to
3ef43ec
Compare
Dabei ging es mir nicht um den Lademodus, sondern wann der neue Traif, also die Preisliste des neuen Tarifs aktiv wird. |
59b23ac to
81fe394
Compare
LKuemmel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ein paar kleiner Anmerkungen und eine Lösung für die globalen Variablen, die in einem der letzten Commits reingekommen sind.
| ''' | ||
| next_query_time and internal_tariff_state are defined outside of class ConfigurableElectricityTariff because | ||
| for an unknown reason defining them as a class variable does not keep their values. | ||
| ''' | ||
| next_query_time: datetime = datetime.fromtimestamp(1) | ||
| internal_tariff_state: TariffState = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Die globalen Variablen sind ein architektonischer Fallstrick und können da nicht bleiben.
Vorschlag: Die Verantwortlichkeit wird aufgeteilt: ConfigurableElectricityTariff ist nur für das Abfragen und Publishen der Preisliste zuständig, et_get_prices prüft, ob optional eine neue Preisliste braucht und ruft dann die update-Methode auf. et_get_prices hat ohnehin die Information, bis wann die letzte Preisliste geht.
Wenn im Fall einer Warnung die Preisliste nicht aktualisiert werden soll, wird die self.store.update() einfach nicht aufgerufen und die letzte, abgerufene Preisliste bleibt im Broker stehen.
Dann sind die beiden globalen Variablen obsolet und die Entscheidung, wird dort getroffen, wo die Preisliste vorhanden ist und die Daten nicht über den Code verstreut.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dann sind die beiden globalen Variablen obsolet und die Entscheidung, wird dort getroffen, wo die Preisliste vorhanden ist und die Daten nicht über den Code verstreut.
Das sehe ich genau anders herum, denn "wo die Preisliste vorhanden ist" ist ja in den einzelnen ET-Provider-Modulen also muss da jedes ET-Provider Modul selbst das Caching implementieren, und dass bedeutet für mich "über den Code verstreut". Ja, ich bin auch kein Freund von globalen Variablen, aber weil der in anderen Programmiersprachen übliche Weg über Objektvariablen in Python offenbar nicht funktioniert ist das für mich das kleiner Übel.
Wenn das OWB Team aber darauf besteht werde ich das noch ändern, damit dieser PR aber bald möglichst life gehen kann würde ich das in einem neuen PR machen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reden wir von der gleichen Stelle? Ich würde hier prüfen, ob die Preisliste aktualisiert werden muss: https://github.com/tpd-opitz/openwb-core/blob/d9e3006a947d2cf9a64255b5738bb3b5054ba7bb/packages/control/optional.py#L204
Das ist unabhängig vom Provider-Modul und in self.data.et.get.prices ist die letzte Preisliste vorhanden.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reden wir von der gleichen Stelle? Ich würde hier prüfen, ob die Preisliste aktualisiert werden muss: https://github.com/tpd-opitz/openwb-core/blob/d9e3006a947d2cf9a64255b5738bb3b5054ba7bb/packages/control/optional.py#L204 Das ist unabhängig vom Provider-Modul und in self.data.et.get.prices ist die letzte Preisliste vorhanden.
Diese Stelle wird "nur" der Thread zum Update gestartet, wenn der schon existiert passiert nichts. Zudem hätte ich hier das selbe Problem mit den nicht persistenten Objektvariablen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ich habe hier mal einen Entwurf gemacht: #2897
- Co-authored-by: benderl <benderl@users.noreply.github.com>
mock quarter hour timestamp
81fe394 to
0e6f195
Compare
0e6f195 to
d9e3006
Compare

Tibber
alle ET Provider
Backend
Frontend