heidanei hat geschrieben: ↑Sa Nov 23, 2024 9:03 am
Vielleicht würde es Sinn machen, den Abfrageintervall auch auf Seiten des openWB-Moduls auf ein sinnvolles Maß zu begrenzen, bspw. nur 1x bei Ladestart und dann nur noch >5 min Abstand (oder nur noch mit Berechung, was bei mir übrigens hervorragend funktioniert!) und ohne Ladung gar nicht mehr oder nur noch mit deutlich größerem Intervall...?
Dir ist bekannt, dass das Abfrageintervall bei 10min liegt, weil es bei Intervallen darunter zu Probleme kommen kann.
Zum Rest: Da hast du dir wohl nen ziemlichen Bären aufbinden lassen von deinem Bekannten.
Ich muss heidanei teilweise zustimmen.
Schließlich bietet BMW auch eine Bezahl-Version seiner API bereit die man offiziell in Drittsystene integrieren kann.
14,025 kWp, SolarEdge Hybrid-WR SE10K-RWS, LG Resu 10
BennyOkee hat geschrieben: ↑Sa Nov 23, 2024 9:17 am
Dir ist bekannt, dass das Abfrageintervall bei 10min liegt, weil es bei Intervallen darunter zu Probleme kommen kann.
In openWB kann man derzeit prinzipiell einen Abfrageintervall von 1min. einstellen, unabhängig ob geladen wird oder nicht:
Das unterbinden die BMW-Server jetzt schon nach relativ kurzer Zeit mit '429 Too Many Requests', aber je weniger Abfragen desto besser. IMO macht <5min. auch während des Ladevorgangs absolut keinen Sinn, zumal die BMW-Server hier auch nur interpolieren. Die Kommunikation zwischen Auto und Server findet (derzeit) auch nur zum Ladestart, Ladeende und 1-2x dazwischen (evtl., bei längeren Ladevorgängen) in größeren Intervallen statt. Daher funktioniert IMO gerade beim Laden mit wechselnder Leisung wie beim PV-Laden, die lokale Berechnung anhand der geladenen Energiemenge sogar besser, da die BMW-Server Schwankungen der Ladestromvorgabe gar nicht mitkriegen.
Aber wer weiß, vielleicht laufe ich ja mit einem Bären auf dem Rücken herum...
Ich habe selbst keinen BMW/Mini und daher keine eigene Erfahrung.
Ich benötige Meinungen zu 2 Fragen:
1 - sollten wir Mindestwerte für die Intervalle vorsehen? Wenn ja, welche?
2 - Momentan wird das Refresh-Token in einer Datei in der Ramdisk gespeichert, d.h. nach jedem Neustart/Update wäre der etwas umständliche Captcha-Prozess notwendig.
Ich überlege, in der neuen Version das Token permanent zu speichern, also entweder in einer Datei außerhalb der ramdisk oder in der Modulkonfiguration in MQTT/mosquitto. Das würde idealerweise die Captcha-Token Eingabe nur einmal erfordern bzw. bis zum Wechsel der SD-Card wenn kein Backup vorhanden ist.
Nachteil: die SD-card wird geringfügig häufiger beschrieben; 1 mal/Tag ca. 160 Byte.
Wäre das erwünscht?
openWB-2 Standard+ | openWB EVU Kit v2 MID| 9,9kWp mit Kostal Plenticore 8.5 plus | VW ID.3, Kia EV6, Smart EQ forfour
rleidner hat geschrieben: ↑Sa Nov 23, 2024 11:23 am
Ich habe selbst keinen BMW/Mini und daher keine eigene Erfahrung.
Ich benötige Meinungen zu 2 Fragen:
1 - sollten wir Mindestwerte für die Intervalle vorsehen? Wenn ja, welche?
2 - Momentan wird das Refresh-Token in einer Datei in der Ramdisk gespeichert, d.h. nach jedem Neustart/Update wäre der etwas umständliche Captcha-Prozess notwendig.
Ich überlege, in der neuen Version das Token permanent zu speichern, also entweder in einer Datei außerhalb der ramdisk oder in der Modulkonfiguration in MQTT/mosquitto. Das würde idealerweise die Captcha-Token Eingabe nur einmal erfordern bzw. bis zum Wechsel der SD-Card wenn kein Backup vorhanden ist.
Nachteil: die SD-card wird geringfügig häufiger beschrieben; 1 mal/Tag ca. 160 Byte.
Wäre das erwünscht?
Also meiner Meinung nach wäre ein erneuter Captcha Prozess nach jedem Neustart sehr kurzer unfreundlich.
14,025 kWp, SolarEdge Hybrid-WR SE10K-RWS, LG Resu 10
rleidner hat geschrieben: ↑Sa Nov 23, 2024 11:23 am
1 - sollten wir Mindestwerte für die Intervalle vorsehen? Wenn ja, welche?
Da der Vorschlag ja eh von mir kam:
- Während des Ladens mindestens 5min (häufiger macht mMn. eh keinen Sinn, siehe oben)
- Während des Nicht-Ladens mindestens 10min, besser 30 - mit Default-Einstellung "gar nicht"...
2 - Momentan wird das Refresh-Token in einer Datei in der Ramdisk gespeichert, d.h. nach jedem Neustart/Update wäre der etwas umständliche Captcha-Prozess notwendig.
[...]
Nachteil: die SD-card wird geringfügig häufiger beschrieben; 1 mal/Tag ca. 160 Byte.
Wäre das erwünscht?
Würde mir auch wünschen dass das Token gespeichert wird, ich denke andere Prozesse schreiben da deutlich mehr/öfters auf die SSD.
Ich gebe heidanei recht: die App interpoliert den Fahrzeug-SoC tatsächlich nur. Das habe ich bei meinem i3 schon häufiger festgestellt. Vermutlich reicht ein Abgleich alle 15 Minuten und dazwischen sollte das Modul selbst interpolieren.
Ich würde während des Nicht-Ladens tatsächlich eher noch höhere Intervalle wählen: 1x pro Stunde oder noch weniger. So viel sollte sich da kaum ändern.
Die Beschränkung der Intervalle ist leider doch nicht möglich, da diese in einem zentralen Teil des UIs liegen, das ich für ein einzelnes Modul nicht ändern kann.
Das muss dann doch vom Anwender "sinnvoll" eingestellt werden.
Ich mache hier ein Update, wenn die PR gemerged sind.
openWB-2 Standard+ | openWB EVU Kit v2 MID| 9,9kWp mit Kostal Plenticore 8.5 plus | VW ID.3, Kia EV6, Smart EQ forfour
BennyOkee hat geschrieben: ↑So Nov 24, 2024 7:36 am
Gibt es eigentlich einen technischen Grund, weshalb die bimmer_connected library nicht in der v1.9 läuft?
Ja, die Python-Version (3.5.3) auf 1.9 ist zu alt. bimmer_connected ist erst ab Python 3.8 getestet.
IIRC habe ich das auch schon mal getestet mit wenig Erfolg.
Aber es sieht auch in 1.9 ganz gut aus: Mein Testsystem läuft bereits mit dem captcha, ich muss aber noch das UI und einige andere Stellen erweitern/anpassen.
In ein paar Tagen sollte es dann ein PR für 1.9 geben.
openWB-2 Standard+ | openWB EVU Kit v2 MID| 9,9kWp mit Kostal Plenticore 8.5 plus | VW ID.3, Kia EV6, Smart EQ forfour
