Test Adapter VW Connect für VW, ID, Audi, Seat, Skoda
-
@tomtom
es scheint wieder zu funktionieren. Getestet mit der release Version also keine Github Version. -
@tt-tom läuft bei mir auch wieder. ohne Update.
-
Blöde Frage: welcher DP zeigt an ob die Tür geöffnet ist? Habe es getestet: die WeConnectID App zeigt die geöffnete Tür, an den DP ändert sich nichts. Sollte „c“ sein, richtig? ID4 SW 3.0
-
@mading Ich denke, der relevante Datenpunkt ist nicht das Thema sondern, wann er zuletzt aktualsiert wurde. Bin mir nicht sicher, aber mir scheint es, dass c geschrieben wird, wenn die Tür geschlossen ist und o, wenn die Tür offen ist. Aber da sind dann o und c immer. Je nachdem, welcher der beiden die letzte Änderung (state.lc) hat, gilt dieser Wert.
Für die Frage, ob das Fahrzeug verriegelt ist, gibt es ja zusätzlich den Datenpunkt vw-connect.0.WVWZZZE1ZMPnnnnnn.status.accessStatus.doorLockStatus oder mit der neuen Version auf github einen logischen Schalter vw-connect.0.WVWZZZE1ZMPnnnnnn.status.isCarLocked.
-
@sneak-l8 Hi, danke für den Tipp. Oh mann das ist kompliziert. Ich teste das mal und versuche ein Blockly zu bauen, das mit eigenen DP den geöffnet/ geschlossen Status anzeigt - oder hat das schon jemand umgesetzt?
-
ich habe mal testweise die Fahrerseite geöffnet (frontLeft - müsste ja stimmen), um zu sehen was in den Datenpunkten ankommt. Leider bestätigt es sich nicht, dass der Timestamp desjenigen DP neuer sein muss, welcher gilt - im Gegenteil: der Zeitstempel ändert sich dauernd, mal ist c eine ms früher, mal o.
-
@mading Hm, dann war meine Theorie wohl nicht korrekt.
Ich habe gerade wegen der Parkposition weiter experimentiert und mir mal ein bisschen das Debug-Log angeschaut. Da scheint aber alles richtig anzukommen. Hier mal ein Ausschnitt:{"access":{"accessStatus":{"value":{"overallStatus":"safe","carCapturedTimestamp":"2023-01-06T12:56:08.595Z","doors":[{"name":"bonnet","status":["closed"]},{"name":"trunk","status":["closed","locked"]},{"name":"rearRight","status":["closed","locked"]},{"name":"rearLeft","status":["closed","locked"]},{"name":"frontRight","status":["closed","locked"]},{"name":"frontLeft","status":["closed","locked"]}],"windows":[{"name":"sunRoof","status":["unsupported"]},{"name":"roofCover","status":["unsupported"]},{"name":"sunRoofRear","status":["unsupported"]},{"name":"frontLeft","status":["closed"]},{"name":"frontRight","status":["closed"]},{"name":"rearLeft","status":["closed"]},{"name":"rearRight","status":["closed"]}],"doorLockStatus":"locked"}}}@tombox das was in den Datenpunkten ankommt sieht dann aber ganz anders aus. Wird da evtl. was falsch "übersetzt"?
-
@sneak-l8 Ja das ist ein unglückliches format. Man müsste jetzt vorher den status löschen damit immer der aktuelle reflektiert sonst ist es nur eine Ansammlung von bisher sichtbaren statuse
-
@tombox Hm, das Löschen von Sate führt natürlich dann auch dazu, dass die History-Werte (oder SQL-Daten) gelöscht werden.
Ich hab gesehen, dass die extractArray()-Methode bei einer Array-Liste einfach den ersten Buchstaben als "Index" für die Werte nutzt.
Wäre es eine Option stattdessen, die Werte durchzuzählen? Am Ende schaut man dann solange noch, ob es einen weiteren State mit n+1 gibt, der einen Wert aufweist und setzt den auf blank zurück.
Dann würde da
0 = open
1 = unlocked
oder
0 = closed
1 = locked
etc. drinstehen. Es gäbe immer nur eine begrenzte Anzahl States und wenn es mal mehr als drei Werte gab, dann steht später auch mal
0 = closed
1 = locked
2 = (leer)
drin.P.S. Für die ermittlung der Parkposition habe ich noch mal optimiert. Jetzt werden lat/lon getrennt bearbeitet und immer nach latitudeConv und longitudeConv geschrieben. Weiterhin wird geprüft, ob es eine Veränderung des Wertes gab (state.ts !== state.ls), um dann den Geohash und die Adresse zu bestimmen.
D.h. sowohl bei einer Änderung von latitiude als auch longitude wird das ausgeführt. Damit dann aber keine unsinnigen Adressen bestimmt werden, weil in der Millisekunde bisher nur latitude aber noch nicht longitude geändert wurde, muss die Änderung i nden letzten drei Sekunden liegen.
Hab es in meinem Fork geändert und schau mal, ob die Logik funktioniert, wenn ich morgen unterwegs war.
Dann hab ich vielleicht auch ein paar Infos zum Thema: Fahrzeug unterwegs/geparkt, um diese Info ebenfalls für ID.-Modelle bereitzustellen. Dann gibt's wieder einen PR. -
Hey,
ich nutze den Adapter seit ich einen neuen Skoda habe (20.12.) und er ließ sich sofort einrichten.
Bei mir ist es wie auch bei vielen hier, zum Abbruch der Verbindung gekommen und seit dem ist kein Login mehr möglich.
Hier und da ist zu lesen dass es bei einigen wieder geht. Ich habe den Adapter deinstalliert und danach neu installiert (Vers.0.0.56) leider keine Besserung.
Bei meinem anderem System (anderes Haus) habe ich mit dem Adapter keine Probleme.Kann es sein, das ich mir etwas in meinem IObroker eingefangen habe?
Eine Änderung des System habe ich bis dahin nicht vorgenommen.
Gruß GH
-
@günni1955 Wichtig sind hier immer logs
-
@tombox
Es hat mir keine Ruhe gelassen und ich habe an meinem Zweitsystem eine 2. Instanz installiert und siehe da… da war der Fehler gleich.
Also habe die My Skoda App im Handy abgemeldet.
neu angemeldet mit Pw vergessen. das gleiche Pw eingegeben und APP damit neu gestartet.
15 min später hatte sich der Adapter in meinem Erstsystem automatisch angemeldet und alles is gut.Vielen dank für´s schnelle reagieren.
gruß Gh
-
Ich habe den Adapter nun auch erfolgreich mit unserem E-Up verbunden. Da ich Tibber nutze, möchte ich gerne den Ladevorgang über den Adpater steuern. Leider konnte ich keinen Datenpunkt finden, worüber dies möglich ist. Kann mir jemand einen Tipp geben ?
Viele Grüße
Wauzzi
-
@wauzzi unter dem remote Ordner gibt es bei mir (ID4) einen charging DP, allerdings steht der bei mir auf true obwohl der ID nicht lädt. Hast du einen remote Ordner? GGf. wäre es sinnvoller, das über die Wallbox zu steuern, wenn du kannst
-
@tombox Guten Morgen, ich habe den Adapter jetzt soweit unter https://github.com/Sneak-L8/ioBroker.vw-connect angepast, dass bei ID.-Modellen die Parkposition in die üblichen States (parking.latitudeConv/position.longitudeConv/parking.geohash geschrieben wird und die Parkposition als lesbare Adresse unter parking.address.displayName angelegt wird.
Allerdings werden geohash und displayName immer erst mit 10 Minuten Versatz (also erst mit der nächsten Abfrage) aktualisiert. Die ...Conv-Werte werden immer synchron zu den Original-Werten von WeConnect angepasst.Ich habe schon mit await auf das korrekte Setzen der Werte in den States gewartet, damit auch die neusten Werte verarbeitet werden, aber es hilft nichts.
Kannst Du (oder jemand anderes) mal einen Blick auf den Code (ab Zeile 5113 in main,js) schauen? Hat jemand eine Idee, warum die Aktualisierung immer nur zeitversetzt klappt? Danach könnte ich einen PR machen, damit alle was davon haben. -
@sneak-l8 Das habe ich auch schon bemerkt.
Es ist kein Beinbruch, weil man das ja leicht per Script kompensieren kann.
Wichtig wäre, dass es dokumentiert ist.
Das war bei mir ein Trial and Error und hat zu viel Zeit gekostet, bis ich da hingefummelt hatte. -
@sneak-l8 Bitte erstell ein PR
-
@tombox ist erstellt
-
@sneak-l8 Habe noch Anpassung gemacht vielleicht hat es was gebracht
-
@tombox War nicht ganz einfach, die eigentlichen Änderungen im Commit zu sehen, weil der neue Linter einiges anders formatiert, aber ja, der eine oder andere await und der setStateAsync könnten was helfen. Ich werde es nachher prüfen, wenn ich unterwegs bin. Danke.
