Test Adapter VW Connect für VW, ID, Audi, Seat, Skoda
-
@tombox scheint wohl gerade nicht verfügbar zu sein. Daher dachte ich mir, ich erstelle mal einen Fork seines Adapters und schaue mir die States unter "status" mal genauer an. Mein Wunsch ist ja, dass die Werte nicht einfach durchnummeriert werden, weil sich durch Hinzukommen oder Wegfallen von Informationen seitens des We Connect-Systems schnell Verschiebungen ergeben können.
Jetzt habe ich mir mal das JSON genauer angesehen, das von VW kommt und aus dem die Daten in den States erstellt werden:Es zeigt sich, dass der Aufbau auf den ersten Blick klar strukturiert wirkt, auf den zweiten aber ein paar Besonderheiten entstehen:
- Die ersten Stellen der ID (z.B. "id":"0x0101010001" => 0x0101 bzw. 0101) stellen die 1. Ebene der Gruppierung dar, die letzten 6 Stellen die Unter-id des Feldes.
- Ab und an (bei den ersten beiden Gruppen) sind die ersten signifikanten Stellen nicht unterschiedlich (beide male 0101), sonst aber eher eindeutig.
- Die letzten 6 Stellen der Gruppe sind entweder FFFFFF oder identisch mit den Werten der darunterliegenden Felder
- Es gibt innerhalb der Gruppe auch mal zwei Einträge mit der gleichen ID. Diese enthalten dan aber identische (leere) Daten
Ein mögliches vorgehen wäre:
Die bisherigen Gruppierung "data" spielt keine wirkliche Rolle, es werden nur alle Werte darunter "field" ausgewertet. Die dortige id wird zerlegt in die ersten 4 und letzten 6 Stellen (0x zu Beginn wird ignoriert). Dann landen die Werte z.B. bei id = 0x0101010001 nicht mehr unter status.data01.field01 sondern unter status.data0101.field010001. Alternativ kann man auch beide id auswerten und die Statenamen länger ausfallen lassen: status.data0x0101010001.field0x0101010001 oder status.data0x0203FFFFFF.field0x0203010001
Doppelte Werte würden nur zu einem überschrieben des vorherigen Wertes führen (da sie identisch sind hat es keine Auswirkungen).
Damit wäre es möglich, Werte ganz gezielt auszulesen (z.B. status.data0x030101FFFF.0x0301010001 für die Lichter) ohne der Gefahr ausgesetzt zu sein, dass bei einer veränderten Informationsbereitstellung die Daten in einem anderen State suchen zu müssen. Besonders ungeschickt wäre es, wenn die Werte über SQL.0 oder History.0 aufgezeichnet werden sollen. Denn dann muss man mal hier und mal da aufzeichnen. Damit wären die Daten nur sehr bedingt auswertbar...
Was meint Ihr? Wäre eine Speicherung nur unter Berücksichtigng der 2. id mit kurzen state-Namen wie status.data0101.field010001 oder mit Berücksichtigung beider ids wie status.data0x0203FFFFFF.field0x0203010001 besser? -
@Sneak-L8 Ich würde für die Berücksichtigung beider ID's plädieren.
Könnte bei einer Änderung einfacher sein. -
-
@Sneak-L8 ja da stimme ich zu. ich glaube auch das man die längere Version nutzen sollte, da die Datenstruktur nach meiner Meinung übersichtlicher ist.
-
@aba320 @jhg @pfried Danke für Eure Rückmeldungen. Ich habe mir das Coding nun mal angesehen und glaube zu wissen, wo ich ansetzen muss. Werde das zunächst mal in einem separaten Branch machen, dann kann man zunächst ungestört den aktuellen Adapter weiternutzen und bei Bedarf auf die neue Version umswitchen. Wenn dann alles passt, merge ich den Branch in den Master.
Bevor ich jetzt anfange hat sich für mich eine weitere Frage ergeben:
Die tripDatas werden derzeit auch einfach durchnummeriert eingetragen. Dabei werden diese von VW "unsortiert" ausgegeben:Das führt dazu, dass diese zwar als state tripdata<nn> durchnummeriert werden, aber nicht immer chronologisch sortiert sind (sieht man auch gut im Beispiel). Hinzu kommt, dass die Nummerierung nur zweistellig mit Null aufgefüllt wird, so dass nach 10 erstmal 100, 101, ... kommt und dann 11, 110, 111, 112, ... Ich kann jetzt die Nummerierung natürlich dreistellig machen, aber so ganz glücklich bin ich damit nicht.
Ich könnte auch hergehen und die tripID nehmen (analog der id beim Status). Dann wären sie schön chronologisch sortiert. Das führt zum schönen Umstand, dass alle trips des Fahrzeugs immer im ioBroker erhalten bleiben, weil keine trips mehr überschrieben würden, aber auch zu dem unschönen Zustand, dass es immer mehr states im iobroker gibt und dieser ein stückweit "vermüllt" wird. Keine Ahnung, ab wievielen States es da zu Problemen kommt.
Mir fallen jetzt verschiedene Optionen für die tripdata ein:- alles wie bisher, nur die lfd. Nummer dreistellig machen
- alle tripdata mit trapID schreiben, ggfs. eine Löschfunktion für alle Trips vorsehen (Zeitraum z.B. über Konfig einstellbar)
- tripdata auswerten und nur die neusten x (z.B. 10) Trips sortiert unter tripdata 01-10 ablegen.
- eine Kombination aus 2. und 3. mit getrennten Rubriken
Was meint Ihr?
-
@Sneak-L8 Ich würde klar für Variante 2 stimmen.
Dann kann man es einstellen wie man möchte und im Zweifelsfall löschen, wenn es zuviel wird.Danke schon mal vorab für deine Mühe.
Freue mich schon darauf, den Adapter nutzen zu können.
-
@Sneak-L8 hallo Danke erst mal Dass Du dich um den Adapter kümmern willst.
ich habe immer 4 Tripdatawerte. Skoda Scala. der Trip 4 ist der Wert seit dem Tanken. das haben mir vergleiche mit der skoda Connect App gezeigt.
ich würde ebenfalls den vorschlag 2 begrüßen. würde mir aber eine löschfunktion für einzelne Werte wünschen. man kann natürlich auch manuell in die Objects eingreifen und etwas manuell löschen. -
Erstmal danke, dass du den Adapter weiterentwickeln willst. Siehst du eine Möglichkeit die Funktionalität für Audi wiederherzustellen?
Falls du Beta Tester oder rudimentäre Unterstützung beim Coding brauchst, meld dich!
-
@Master-Rudi Zunächst möchte ich mich mit dem Adapter vertraut machen und die o.g. Punkte angehen. Dadurch bekomme ich auch etwas merh Gespür für den Adapter.
Danach will ich mich an an die Authentifizierung wagen. Sofern es genügend Doku gibt, wie die Anmeldung konkret abläuft, wäre das schon mal ein Anfang. Denn bzgl. Netzwrrkkommunikation einer App mitschneiden bin ich jetzt nicht bewandert.
Aber hab ja auch ein Eigenintresse. Hoffe, dass ein Abfallprodukt davon dann die Anmeldung der ID-Serie ist, so dass mein ID.3 auch ausgelesen werden kann, wenn er in ca. 3 wochen kommt... -
@aba320 Welche Art von Tripdata hast du in der Konfig ausgewählt? Davon ist sicherlich abhängig wie umfangreich die Liste ist.
-
@Sneak-L8 Hallo, ich hab "alle Zyklen" augewählt. ich nutze den adapter seit mitte september. und hab in den einstellungen seit dem nicht geändert.
ich hatte immer die 4 tripdatas.
Wie schon erwähnt Skoda scala adapter 0.0.18
ich kann dir auch nötigenfalls meine skoda Connect app Zugangsdaten per mail oder pn senden.
Gruß Achim -
@aba320 hier meine vis mit den angaben
Türen Verriegelung(kleien Griffe leuchten rot) Heckklappe und Standlicht funktionieren bereits . bei Fenstern suche ich noch.... -
@aba320 Hm, dann werden bei Skoda vielleicht weniger Trips gespeichert als bei VW?
Hab mir auch nochmal Gedanken gemacht. Wenn jemand den History- oder SQL-Adapter benutzt, dann braucht er eigentlich nur States für den letzten Trip. Wenn die dann geloggt werden, ergibt sich ganz automatisch eine Liste aller Fahrten in der Historie.
Daher würde ich in der Konfig einen Eintrag machen für die Anzahl der als States zu speichernden Einträge (1, 10, 100, alle). Dann werden dort chronologisch die letzten Trips eingetragen (Nr. 1 ist der neuste, Nr. n ist der älteste).
So gibt es immer die gewüschte Anzahl an Trips und man muss nicht permanent ältere states löschen (sei es manuell oder durch den Adapter). Eine Durchnummerierung würde ich in dem Fall beibehalten (und nicht die tripID als Namen verwenden). So bleibt die Liste der States überschaubar und muss nicht gewartet werden.Ist also entgegen der letzten Meldugen nur ein bisschen 2 mit Abstrichen und geht etwas mehr in Richtung 3. Ich glaube, dass man es so effektiver nutzen kann. Oder spricht etwas klar für rein Nr. 2?
-
@Sneak-L8 hallo, ich nutze history und hab mal alle 4 trips aktiviert. mal sehen was da so aufläuft. scheint so das skoda weniger trip daten meldet. ich hatte nie mehr als die 4.
aber die neue Lösung erscheint mir sinnvoll. -
@aba320 sagte in Test Adapter VW Connect v0.0.x:
ich hatte immer die 4 tripdatas.
Interessant. Bei mir sind die tripTypes "shortTerm" und "longTerm". Bei dir aber "cyclic". Also vermutlich werden dann bei Skode nur (im Roudtrip-Verfahren) vier Werte gespeichert? Spannend.
Ich sehe mal diese drei Arten vor und logge es als Warning, wenn andere Werte kommen sollten. -
@Sneak-L8 Ja alle sind cyclic. sie ändern sich auch über tage nicht groß. trip 4 ist " ab Tanken. bei den anderen vergleiche ich gerade welche Werte dort gezeigt werden. offensichtlich sind sie nicht mit den in der app gezeigten "ab Start" oder "langzeit" nicht identisch. nur 4 stimmt mit "ab Tanken" überein ( ausser es fehlen gerade mal Daten).
-
@aba320 Interessant. Hab mir überlegt, dass ich dann auch programmseitig drei Triparten vorsehe: shortTerm, longTerm und Cyclic. Bei Skoda wirdman dann nur letzteres sehen, bei VW nur die ersten beiden.
-
@Sneak-L8 Hallo,
skoda hat wieder was an der Datenlage geändert. seit heute hab ich im Status ,data3 field 1 und 2 auch die Ölserviceinformationen...
es muß nur der im Field enthaltene Wert in einem skipt mit -1 multipliziert werden.
mal sehen ob ich auch bei den Fenstern mal was zum laufen krieg.bei skoda ist es mit den 4 tripdatas geblieben
-
@aba320 hi, danke für Deine Screenshots. Da sehe ich das was ich gestenr im Code gefunden habe :). Bei Anlage eines Channels (Gruppe) - in diesem Fall tripdata01, ... wird geschaut, ob es eine Beschreibung mit textId gibt oder das letzte Feld in der data-Gruppe eine textId hat oder ein Timestamp. Dann wird dieser bei Neuanlage des Channel als Beschreibung hinterlegt.
D.h. nur bei Neuanlage und später nicht mehr. Sprich: werden die tripdata mit neuen trips gefüllt, bleibt der alte Timestamp in der Beschreibung stehen... Und bei data bleibt eine Beschreibung stehen, selbst wenn sich die data-Gruppen ändern.
Da werde ich schauen, dass die Beschreibung bei jedem Datenauslesen aktualisiert wird. Außerdem schaue ich, ob es bei einem field zum "value" auch eine "unit" gibt und hinterlege diese dann beim state value. Dann kann man den Wert auch besser einschätzen ohne beim State unit nachschauen zu müssen.Genau das angesprochene "was an der Datenlage geändert" ist es, das die aktuelle Speicherung mit data<nn>.field<mm> anfällig macht. Sobald eine zusätzliche Datengruppe kommt (oder eine wegfällt) rutschen die Werte in einen anderen Channel. Das ungeschickte ist, dass die alten states stehen bleiben, wenn die neue Gruppe weniger Felder hat. Das macht die Suche nach Daten immer wieder mal unübersichtlich. Aber ich denke, ich kann in Kürze mal eine neue Version bereitstellen, bei der die Daten besser aufbereitet werden.
-
@Sneak-L8 hallo,
ja die Datenstruktur sollte schnellst möglich auf das neue Format geändert werden. das begrüße ich obwohl das für mich auch Nacharbeiten in den Scripten und der Vis bedeutet. die unangekündigten Ändererungen machen sonst ein Datenchaos vorhersehbar. und dann wären noch mehr Nacharbeiten notwendig. also wenn Du Dich traust bin ich gerne Bereit auch als Betatester mitzuwirken.
