Konfiguration SOC-Modul: Generelle Test-Möglichkeit?

[rleidner]

Beim Konfigurieren eines SOC-Moduls in owb 2.x mit 2-FA und PIN via Email ist aktuell mehrfaches Wechseln zwischen Konfiguration und Dashboard nötig:
1 - Konfiguration: SOC-Username, VIN, Intervalle eintragen, Speichern
2 - Dashboard: SOC-Abruf (Kreispfeil) starten
3 - Email Programm PIN -> COPY
4 - Konfiguration: PASTE -> PIN, Speichern
5 - Dashboard: SOC-Abruf (Kreispfeil) starten

Man könnte natürlich 2 Browser-Windows/Tabs öffnen um das zu machen.

Besser fände ich auf der Fahrzeug-SOC-Modul-Seite generell einen Test-Button und eine Status-Ausgabe zu haben:
- Test Button sendet true auf Topic openWB/set/vehicle/<vehicle>/get/force_soc_update.
- Status zeigt dasselbe wie der Fahrzeugteil im Status: Ladestand, Reichweite, Letzter Zeitstempel

Damit ließe sich der obige Ablauf nur in Konfiguration und Email bewerkstelligen und der Anwender könnte im Status nach kurzer Wartezeit sehen ob die Konfiguration ein Ergebnis liefert.

Ich denke das wäre ein sinnvolles Feature für alle SOC-Module (außer Manuell und MQTT).

[LutzB]

Die Voraussetzung dafür steht auf unserer ToDo-Liste: Befehle direkt an Module im Backend senden. Mangels Entwicklungskapazitäten wurde damit aber noch nicht angefangen.

[mrinas]

Ich weißt jetzt nicht genau wie der Abruf des SoC aus dem Haupt-UI heraus getriggert wird. Läuft das über command.py? Dann wäre das eher einfach: Ich sende aus der Konfigurationsseite des OneDrive Moduls bereits Befehle ans Backend. In meinem Fall wird die MSAL Library angesprochen um einen Auth Code zu erzeugen und diesen dann wieder in der UI darzustellen.

Das liesse sich sicher vergleichsweise einfach übertragen - sofern fürs Triggern des SoC auch den Weg über command.py nutzt.

[LutzB]

Prinzipiell läuft das so. Wir möchten nur den Code von den Modulen möglichst aus den Kernkomponenten raushalten, damit nicht immer die commands.py aufgebläht wird und man später auch richtige "Plugns" hat.