Hyundai Bluelink wieder kein SoC???

[StubbeA]

Und Achtung:

Der Intervall ist Fehlerhaft:
Zumindest bei Hyundai und Kia ergeben 60min Intervall ziemlich genau NUR 10min in Realität.

2021-04-07 16:12:13: LP1: Next update: 650.0 minutes (3900 ticks)
2021-04-07 16:12:13: LP1: Kia SoC Module starting
... ...
2021-04-07 15:55:34: LP1: Next update: 750.0 minutes (4500 ticks)
2021-04-07 15:55:33: LP1: Kia SoC Module starting

100min werden derzeit zu ca. 17min

Ich hatte bei einem Fahrzeug nach einem Test vergessen, dass ich auf 20min gestellt hatte. Nun war heute früh am KIA mal eben
die Batterie komplett tot und brauchte erste Hilfe.
Kona Batterie war noch gerade so knapp bei 11,9 Volt.

Erstmal die Batterien geladen und den Intervall auf 800 gestellt.

(Und nein, es ist kein Fehler von den Fahrzeugen. Die haben bei uns alle schon Deutsche Batteriehersteller und seit dem für knapp ein Jahr nie mehr Probleme gehabt.)

[StubbeA]

Ich denke der Log beinhaltet immer nur die letzten 1000 Zeilen, ältere Zeilen werden verworfen. Das ist aber SoC-unabhängig on der OpenWB gemanaged.

Deshalb war ja meine Idee, bei Debug=0 immerhin eine Info bei der Abfrage (erfolgreich/Timeout/etc) auszugeben, dann könnte man im Normalzustand durch Aufruf des Logs genau sehen, wie die Abfragen über den Tag gelaufen sind. Bei Debug=1 ist ja alles paar Sekunden der Timer-Eintrag, dadurch kommt man so schnell auf die 1000 Zeilen und kann nie mal über ein paar Stunden sehen, wie viele der Regel-Abfragen erfolgreich waren.

Meine Zugangsdaten müssen ja stimmen, denn mindestens 3mal wurde seit gestern erfolgreich der SoC abgerufen.

Steht das Auto evtl. ungünstig bzgl. Empfangsleistung?
Bei uns laufen drei Fahrzeuge (Bluelink/UVO)

[gorthon]

Steht das Auto evtl. ungünstig bzgl. Empfangsleistung?
Bei uns laufen drei Fahrzeuge (Bluelink/UVO)

Der Empfang in der Einzelgarage ist sicher nicht der beste, aber auch nicht so schlecht, dass das erklären würde, warum die Abfrage per openWB nur selten erfolgreich ist, per App jedoch fast immer.

Daher ja meine Bitte, den Timeout mal zu verdoppeln.

[Flocki]

Das mit dem Intervall schaue ich mir nochmal an.

Da war vorher ein Bug drinnen, dass die Intervallänge abhängig von der Regelungsgeschwindigkeit der Box falsch war. Evtl. ist mir bei der Korrektur noch was durchgegangen...

[StubbeA]

Das mit dem Intervall schaue ich mir nochmal an.

Da war vorher ein Bug drinnen, dass die Intervallänge abhängig von der Regelungsgeschwindigkeit der Box falsch war. Evtl. ist mir bei der Korrektur noch was durchgegangen...

Ja ich weiß.
Evtl. kann man das ja wirklich per Uhrzeit errechnen und somit unabhängig von der Regelgeschwindigkeit?

[Flocki]

Mir scheint, dass auf der Einstellung "Sehr langsam" die komplette Regelungsschleife fehlerhafterweise alle 10 Sekunden statt alle 60 Sekunden ausgeführt wird.

Falls dem so ist, mache ich im SoC-Modul keine Änderung, sondern ein Ticket auf, um das grundlegende Problem zu lösen.

[Flocki]

Es scheint wirklich so, dass mit Absicht das SoC-Modul bei "Normal" und "Sehr Langsam" alle 10 Sekunden, bei "Langsam" alle 20 Sekunden aufgerufen wird. Das war mir so nicht klar.

[Flocki]

Ich habe nochmal einen Pull-Request aufgemacht mit folgenden Änderungen:

Abruf-Intervall für Regelung "Sehr Langsam" gefixt
Timeouts angepasst (auf 60 Sekunden bei der Anfrage ans Auto, 10 Sekunden bei Anfragen an den Server)
Minimales Logging bei Debug Level 0
Wenn die Statusabfrage des Autos auf Timeout läuft, gibt es nach 60 Sekunden automatisch einen zweiten Versuch.

[gorthon]

Sehr cool, vielen Dank! Werde ich gleich testen wenn es in der nightly ist.

[StubbeA]

Ich habe nochmal einen Pull-Request aufgemacht mit folgenden Änderungen:

Abruf-Intervall für Regelung "Sehr Langsam" gefixt
Timeouts angepasst (auf 60 Sekunden bei der Anfrage ans Auto, 10 Sekunden bei Anfragen an den Server)
Minimales Logging bei Debug Level 0
Wenn die Statusabfrage des Autos auf Timeout läuft, gibt es nach 60 Sekunden automatisch einen zweiten Versuch.

Spitzenleistung - Danke!