NEWS
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 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?
-
@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?
-
@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 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. -
@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?
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!
-
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... -
@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. -
@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 -
@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 -
@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 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?
-
@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 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 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. -
@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).
-
@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
-
@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.
-
@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. -
Erstmals Danke an alle, die an diesem tollen Adapter arbeiten.
Ich habe einen E-Golf 2018. Adapter funktioniert. Ich kann Werte auslesen und in andere Programme via http weitergeben. Leider habe ich ein Problem wenn ich die Ladestromstärke mit einem http Befehl in IoBroker ändern möchte.
wenn ich den folgenden Befehl schicken:http://10.0.0.11:8087/set/vw-connect.0.WVWZZZAXXXXXXXXXX.charger.settings.maxChargeCurrent.content?value=5wird der Wert 5 rot bei den objects eingetragen und Bestätigt: ist false
Wenn von der VW App der Wert geändert wird sieht es wie am nächsten Bild aus und Bestätigt: true
Was muss ich machen, damit der Wert übernommen wird?
Teillösung:
http://10.0.0.11:8087/set/vw-connect.0.WVWZZZAXXXXXXXXXX.charger.settings.maxChargeCurrent.content?value=5&ack=truejetzt wird die Bestätigung mit true übernommen und ist nicht mehr rot.
Der Wert wird aber nicht an das Auto übergeben.
Was muss man machen, dass der Wert an das Auto geht?
Hat das was mit dem Timestamp zu tun, da der sich nicht ändert? -
Erstmals Danke an alle, die an diesem tollen Adapter arbeiten.
Ich habe einen E-Golf 2018. Adapter funktioniert. Ich kann Werte auslesen und in andere Programme via http weitergeben. Leider habe ich ein Problem wenn ich die Ladestromstärke mit einem http Befehl in IoBroker ändern möchte.
wenn ich den folgenden Befehl schicken:http://10.0.0.11:8087/set/vw-connect.0.WVWZZZAXXXXXXXXXX.charger.settings.maxChargeCurrent.content?value=5wird der Wert 5 rot bei den objects eingetragen und Bestätigt: ist false
Wenn von der VW App der Wert geändert wird sieht es wie am nächsten Bild aus und Bestätigt: true
Was muss ich machen, damit der Wert übernommen wird?
Teillösung:
http://10.0.0.11:8087/set/vw-connect.0.WVWZZZAXXXXXXXXXX.charger.settings.maxChargeCurrent.content?value=5&ack=truejetzt wird die Bestätigung mit true übernommen und ist nicht mehr rot.
Der Wert wird aber nicht an das Auto übergeben.
Was muss man machen, dass der Wert an das Auto geht?
Hat das was mit dem Timestamp zu tun, da der sich nicht ändert?So, die Erweiterung des adapters ist soweit mal erfolgt.
Ihr könnt die neue Version über die URL https://github.com/TA2k/ioBroker.vw-connect/tarball/statusId installieren. Die alte Version ist wie gehabt unter https://github.com/TA2k/ioBroker.vw-connect verfügbar. Wenn es keine Fehler/Probleme gibt, dann merge ich die neue Variante in den bestehenden master-Branch, so das ser für alle direkt zugänglich wird.Änderungen:
- Tripdata kann auf 1, 10, 50 oder 100 begrenzt werden (alle ist weiterhin möglich)
- Die Channels für Tripdata wird nun getrennt benannt nach longTerm, shortTerm und Cycle
- Die Channels sind chronologisch absteigend sortiert und dreistellig durchnummeriert
- Der Zeitstempel aus dem Trip ist weiterhin als Beschreibung beim Channel aufgeführt und wird nun bei einer Änderung auch aktualisiert.
- Die status-Channel sind nicht mehr durchnummeriert sondern haben im Namen die interne ID. Dadurch kann sich das Objekt auch bei zusätzlichen/weniger Infos nicht mehr ändern (besonders geschickt beim Loggen über History.0 oder SQL.0)
- Die Channel-Bezeichnung auf Data-Ebene entfällt, da es hier keinen eindeutigen Wert gibt
- Die Channel-Bezeichnung auf Field-Ebene entspricht dem Objekt "textId" und wird auch laufend aktualisiert.
- Die Value-Objekte unter Status haben nun die unter dem Objekt "Unit" angegebene Einheit, zur einfacheren Lesbarkeit
- Es gibt zwei zusätzliche States direkt unter "status". Zum einen einen logischen Schalter, ob das Fahrzeug verriegelt ist und einen mit der aktuellen Außentemperatur in °C. So spart man sich das Umrechnen von dK (Zehntel-Kelvin)
Ich glaube das war's.
-
So, die Erweiterung des adapters ist soweit mal erfolgt.
Ihr könnt die neue Version über die URL https://github.com/TA2k/ioBroker.vw-connect/tarball/statusId installieren. Die alte Version ist wie gehabt unter https://github.com/TA2k/ioBroker.vw-connect verfügbar. Wenn es keine Fehler/Probleme gibt, dann merge ich die neue Variante in den bestehenden master-Branch, so das ser für alle direkt zugänglich wird.Änderungen:
- Tripdata kann auf 1, 10, 50 oder 100 begrenzt werden (alle ist weiterhin möglich)
- Die Channels für Tripdata wird nun getrennt benannt nach longTerm, shortTerm und Cycle
- Die Channels sind chronologisch absteigend sortiert und dreistellig durchnummeriert
- Der Zeitstempel aus dem Trip ist weiterhin als Beschreibung beim Channel aufgeführt und wird nun bei einer Änderung auch aktualisiert.
- Die status-Channel sind nicht mehr durchnummeriert sondern haben im Namen die interne ID. Dadurch kann sich das Objekt auch bei zusätzlichen/weniger Infos nicht mehr ändern (besonders geschickt beim Loggen über History.0 oder SQL.0)
- Die Channel-Bezeichnung auf Data-Ebene entfällt, da es hier keinen eindeutigen Wert gibt
- Die Channel-Bezeichnung auf Field-Ebene entspricht dem Objekt "textId" und wird auch laufend aktualisiert.
- Die Value-Objekte unter Status haben nun die unter dem Objekt "Unit" angegebene Einheit, zur einfacheren Lesbarkeit
- Es gibt zwei zusätzliche States direkt unter "status". Zum einen einen logischen Schalter, ob das Fahrzeug verriegelt ist und einen mit der aktuellen Außentemperatur in °C. So spart man sich das Umrechnen von dK (Zehntel-Kelvin)
Ich glaube das war's.
Support us
451
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge