Skip to content

soc_vwid/VWEUDA: improve ending thread when no longer configured#3577

Open
rleidner wants to merge 1 commit into
openWB:masterfrom
rleidner:soc_vwid_p15
Open

soc_vwid/VWEUDA: improve ending thread when no longer configured#3577
rleidner wants to merge 1 commit into
openWB:masterfrom
rleidner:soc_vwid_p15

Conversation

@rleidner

Copy link
Copy Markdown
Collaborator

@LKuemmel : as discussed

@LKuemmel LKuemmel left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was ist der Vorteil, innerhalb des Threads noch eine asyncio-Eventloop zu nutzen?

Comment on lines +862 to +866
_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:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants