Test Adapter VW Connect für VW, ID, Audi, Seat, Skoda
-
@tombox sagte in Test Adapter VW Connect für VW, ID, Audi, Seat, Skoda:
@nik82 Ja kann bestätigen VW hat das Problem für VW und Seat behoben
Vielleicht haben die auch was geändert. Bei mir kommt nun phoneNumbers als Objekt. Hier werden wohl die Userdaten nicht geparsed. Kann mir das ja mal anschauen...
vw-connect.0 2023-01-02 13:30:42.455 info State value to set for "vw-connect.0.personal.phoneNumbers" has to be one of type "string", "number", "boolean" but received type "object""{\"firstName\":\"Ich\",\"lastName\":\"bins\",\"salutation\":\"SALUTATION:MR\",\"dateOfBirth\":\"da-hab-ich-geburtstag\",\"preferredContactChannel\":\"MARKETING_BLOCKADES:EMAIL\",\"nickname\":\"Lucky\",\"businessIdentifierType\":\"BUSINESS_IDENTIFIER_TYPE:MBB_ID\",\"businessIdentifierValue\":\"ident\",\"phoneNumbers\":[{\"uuid\":\"uuid\",\"type\":\"PHONE_CONTACT_TYPE:MOBILE_GENERAL\",\"number\":\"meinenummer\",\"primary\":true,\"_updated\":\"2020-03-12T14:35:50.114Z\"}],\"userIsPrivateIndicator\":true,\"preferredLanguage\":\"de\"}"Gruß//Lucky
-
@lucky_esa habe mal in GitHub das parsing angepasst
-
Es ging bei mir seit 1.1. mittags nicht mehr. Ich habe keine neuere Github Version installiert, nun geht es auch so wieder. Auto: Skoda Enyaq.
Lieben Dank für den tollen Adapter!
Frohes Neues, Tim -
@tombox sagte in Test Adapter VW Connect für VW, ID, Audi, Seat, Skoda:
@lucky_esa habe mal in GitHub das parsing angepasst
Jetzt passt es. Die uuid wird für den Channel verwendet was allerdings egal ist ob der jetzt uuid oder phonenumbers heißt...Sieht für mich aber nicht wirklich fertig aus. Vielleicht kommt da noch eine Änderung von VW.
Gruß//Lucky
-
bei mir geht es auch wieder
-
@jb_sullivan, @tombox
Seit gestern Mittag konnte sich der Adapter bei mir ebenfalls nicht auf dem Skoda Server einloggen. Nun geht es wieder. Ohne Neustart des Adapters
-
@tombox Hab jetzt gleich noch einen PR gemacht für das Triggern des Abrufs der Adresse über longitude anstelle latitude. Hab immer schön gesehen, dass die falsche Adresse exakt auf derselben Höhe der korrekten lag. Also war latitude schon neu, aber longitude noch alt. Jetzt sollte es besser klappen (betrifft eigentlich alle Fahrzeuge, bei denen die Adresse abgerufen wird)
-
@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
