soc_vwid/VWEUDA: improve ending thread when no longer configured#3577
soc_vwid/VWEUDA: improve ending thread when no longer configured#3577rleidner wants to merge 1 commit into
Conversation
LKuemmel
left a comment
There was a problem hiding this comment.
Was ist der Vorteil, innerhalb des Threads noch eine asyncio-Eventloop zu nutzen?
| _active = True | ||
| while _active: | ||
| _type = await self.get_module_type(vehicle) | ||
| _LOGGER.info(f"thread loop: ev{vehicle} module type={_type}") | ||
| if _type != MODULE_TYPE: |
There was a problem hiding this comment.
Die Logik, dass der Thread dauerhaft läuft und über die Broker-Config beendet wird, bleibt so erhalten.
Was spricht dagegen, die Abfrage über das übliche SoC-Intervall zu starten und dann max 15 Minuten auf Daten zu warten und beim Erhalt von Daten den Thread zu beenden?
There was a problem hiding this comment.
Das Portal stellt alle 15 min Daten zur Verfügung, die das Modul abholen sollte.
Manche der Datensets sind auch mal unvollständig oder mit älterem Zeitstempel als frühere Daten.
Das SoC-Modul soll alle Daten auswerten und im CarState den sinnvollsten Status melden.
Wenn nur im Abfrage-Intervall am Portal abgefragt wird, kann es passieren daß immer mal wieder so ein "schlechtes" Datenset als letztes genommen würde.
Deshalb soll asynchrone PollingThread laufen solange das Modul aktiv/konfiguriert ist.
Das entspricht auch dem Vorgehen im Homeassistant, dort wird auch ständig abgefragt.
There was a problem hiding this comment.
Dann kann der Thread 15 Min laufen und dann das sinnvollste Datenpaket nehmen, was er in dieser Zeit bekommen hat?
Homeassistant hat eine komplett andere Software-Architektur als openWB.
There was a problem hiding this comment.
Das Portal hat noch viele erratische Verhaltensweisen, die ich mit dem asynchronen Vorgehen so gut wie möglich ausbügeln kann, vor allem wird die gesamte Historie der von Portal bereitgestellten Daten benutzt.
Ich habe beim Portal-Support ca. 8 Tickets offen, die verschiedene Probleme ansprechen, leider bisher ohne Reaktion.
Ich würde daher den aktuellen Ansatz erst mal so lassen.
Das Modul wird voraussichtlich etlichen Support-Aufwand generieren, wenn mehr Benutzer das Modul nutzen würden, das die Probleme des Portals erst mal bei jedem hochkochen werden.
Das ist schlecht wegen der vielen Rückfragen und gut weil man die Benutzer an den Portal-Support verweisen kann.
Vielleicht erzeugt das dann genug Druck bei VW/Cariad, das Portal zu verbessern.
Wenn es für eine Freigabe in eine openWB (Patch-) Release nicht geeignet sein sollte, ist das für mich auch OK.
Vielleicht findet sich ja auch jemand, der das noch anpassen will.
@LKuemmel : as discussed