neue Nissan Leaf API aktualisiert sich nicht #488
Comments
|
Issue-Label Bot is automatically applying the label Links: app homepage, dashboard and code for this bot. |
Tja.
Das ist der Fall. Die Konfiguration wäre interessant, ist im Ticket aber leider zerschossen. Ebenso Logfile. Vermutung: das Nissan API liefert kein Update, daher kann evcc auch nichts sehen. |
|
Hier das yaml File. Wo finde ich das Logfile? |
./evcc --log trace |
|
Wie startest Du‘s denn? Systemd? Docker? Ohne die notwendigen Informationen ist das ein Suchspiel... |
|
Ich starte auf ein Raspberry per systemctl. sudo nano /etc/systemd/system/evcc.service |
|
@martinez81 der Hinweis mit dem Logfile hat etwas in die Irre geführt. Was wir bräuchten wäre ein Logfile das zu dem Vorgang oben passt (genau der Zeitpunkt). Wenn Du systemd nutzt solltest Du an das Log mit |
|
Also über journalctl kommt meiner Meinung nach nichts sinnvolles. Tut mir leid.
Reproduzieren kann man das immer. |
|
@martinez81 wenn ich dich richtig verstehe, geht es hier nicht darum, dass es ein Problem mit mehreren Fahrzeugen gibt, sondern dass das Nissan api nicht aktualisiert? Trifft das auf dartnissanconnect dann auch zu? Dann hab ich leider keine Idee 😫 |
|
@andig, @martinez81: |
|
Dass sich Vehicle-API komisch verhalten und unzuverlässig funktionieren gehört offensichtlich zum guten Ton bei den Fahrzeugherstellern. 🙄 |
Soweit ich das erkenne ziel das auf das Carwings API ab. Hier gehts um das "neue" Kamereon API das wir aus https://github.com/Tobiaswk/dartnissanconnect portiert haben. Die mögen durchaus unterschiedlich funktionieren. Allerdings gut möglich, dass sie sich eine gemeinsame Infrastruktur teilen die dann auch gerne mal ausfallen darf... OT @Alex-ander-s magst Dich mal bei Slack melden? Dein Feedback war interessant ;) |
Ja, die Nissan API funktioniert nicht wie erwartet. |
Ok, in dem Fall kann ich nichts tun :(. Du könntest nur beobachten, ob das ein temporäres Problem ist (gut) oder ein prinzipielles (schlecht). In letzterem Falle bliebe wieder nur rauszufinden wie die Nissan App dieses Problem eigentlich umgeht... (decompile, unpin certificates, trace...) |
Hallo, Das Ergebnis (state) ist in der Tat das, was nach der letzten, vorhergehenden Abfrage mit der Hersteller-App oder alternativ MyLeaf vom Fahrzeug abgerufen wurde. Offenbar wird das in der Nissan-Cloud gecached und das Neueinlesen vom Fahrzeug muss gesondert getriggert werden. Dafür spricht auch der Zeitablauf:
Das ganze ist langwierig, aber ich habe bisher nicht bewusst erlebt, dass von den Nissan-Servern keine Daten kamen. Ich vermute, dass das Auslesen aktueller Daten aus dem Fahrzeug gesondert getriggert und das Ergebnis geduldig abgewartet werden muss. Soweit erstmal, Gunnar |
|
Danke @junibart das hilft! Bei https://gitlab.com/tobiaswkjeldsen/carwingsflutter findet sich: Damit ist auch klar, wie die Aktualisierung anzustossen ist. Da der Vorgang arg lange dauert würde ich das mal so einbauen, dass wir das Update im Hintergrund anstossen und später (d.h. nach Ablauf des Caches) den neuen Wert bekommen. Geht sicher auch eleganter, wäre aber erstmal einfach zu machen. Damit hängen wir immer 5min hinterher. Jetzt die spannende Frage: wie oft darf man das aufrufen, ohne dass Nissan das als Abuse betrachtet? Wirklich alle 5min?! |
|
Könnt ihr den PR mal probieren? Wenn die Cachezeit (5min) abgelaufen ist, wird ein Update vom Server angefordert und im Anschluss der Cache gelöscht. In meinen Tests kommt die Updateanforderung allerdings immer sehr schnell zurück- ich bin nicht sicher ob da auch schon der richtige Wert im API zur Verfügung steht? |
|
Bzgl. der Abfrage: |
Das Verhalten ist immer identisch. Abgefragt wird wenn das Fahrzeug verbunden ist. Woher soll evcc wissen, dass der Zustand nur während des Ladens abgefragt werden soll? Wie finden wir dann raus ob überhaupt geladen werden sollte (minSoC etc)? Du kannst aber jederzeit der cache Wert erhöhen. Die Frage ist also: was ist sinnvoll/ gewünscht und funktioniert für alle Fahrzeuge? |
Vorschlagen würde ich folgende Logik: Ich kann vom Model 3 sprechen. Meine Erfahrung entnehme ich aus Teslamate. Damit logge ich das Model 3. Ob z.B. der Leaf oder andere E-Autos ähnlich reagieren weiß ich nicht. VG |
|
Damit würden wir leider nie erfahren ob z.b. der minSoc unterschritten ist und wir einschalten müssten. Es fehlt also noch eine weitere Regel, wie oft im Status B abgefragt werden sollte. |
Meinst du damit: wenn das Auto ein paar Wochen am Lader hängt und dann irgendwann unter den minSOC fällt? Oder verstehe ich den minSOC falsch? |
|
Nachtrag: |
Hallo, hab den PR installiert und getestet. Die Ausgabe des Kommandos kommt wie bisher nach ca. 6 Sekunden. Die erste Ausgabe zeigt den SoC, der irgendwann vorher vom Fahrzeug abgerufen wurde. Der PR funktioniert also grundsätzlich. Zur derzeit diskutierten Thematik "Häufigkeit SoC-Abruf" wäre mein Standpunkt: Beim Anstecken des Fahrzeugs einmalig, und während des Ladens nur alle 15 Minuten. Wenn nicht geladen wird, gar nicht. |
|
Hier muss man jetzt nur noch gucken wie man insbesondere das initiale Delay so handhabt, dass auch wirklich "aktiv" bzw. mit schnellem Polling auf das Eintreffen des aktuellen Status nach dem Verbinden gewartet wird und diese Meldung nicht dann erst nach 15 Minuten eintrudelt. |
Finde ich gut. |
Ja, genau in diesen Zuständen ist das Auto sowieso wach, hier kann und sollte der SOC abgefragt werden. |
Mit der neuen Logik aus #505 werde ich das so umbauen, dass die Aktualisierung dann "inline" erfolgt, das wird sich also nochmal ändern.
@junibart So stehts in #505, ist darüber hinaus aber noch konfigurierbar. |
Ich gehe davon aus, dass es nicht ausreicht direkt nach dem lokalen Event die API abzufragen da das Fahrzeug im schlimmsten Fall auch erstmal aufwachen und dann seinen aktualisierten Zustand übermitteln muss. Diese Zeitspanne ist wohl nicht vorhersehbar. Nicht nur beim Leaf. |
|
Das Problem können wir immer noch lösen wenn es eintritt. Bis dahin gilt KISS. |
|
Naja, es tritt heute schon ein. Daher musste ich das Intervall ja bislang generell auf Minimum reduzieren. |
|
PR ist so aktualisiert, dass die Aktualisierung jetzt "inline" erfolgt. In Anbetracht von #505 würde ich dennoch erst mergen wenn die Gefahr der API/Batterieüberlastung gebannt ist. |
|
Ich hab jetzt mal alles gemerged. Wenn es nicht funktioniert bitte hier melden, dann mach ich wieder auf. |
|
Hallo, habe auch ein Problem beim Abrufen von SOC, ERROR 2022/11/18 22:15:17 vehicle soc: vehicle not available: cannot create vehicle 'template': cannot create vehicle 'carwings': login failed: Post "https://gdcportalgw.its-mo.com/api_v200413_NE/gdc/InitialApp_v2.php": dial tcp: lookup gdcportalgw.its-mo.com on 1.1.0.1:53: read udp 10.0.0.91:47365->1.1.0.1:53: i/o timeout Bei der Konfiguration waren die Login Daten bei der Prüfung ok und es gab keine Fehlermeldung. |
|
Du verwendest Docker und hast vmtl. /etc gemounted; damit ist DNS kaputt. Hat nichts mit Nissan zu tun. |
Describe the bug
Der SOC und der Status vom Auto aktualisiert sich nicht von selbst.
Erst wenn man die App (vom Smartphone) vom Auto öffnet und diese aktualisiert, wird auch der SOC und der Status in EVCC aktualisiert.
Im konkreten Fall war der Leaf nicht angesteckt. Das Model 3 wurde geladen. Da EVCC aber beim Leaf den Status B erkannt hat, war laut EVCC der Leaf angesteckt. Dies wurde auch auf der Webseite angezeigt.
Expected behavior
Wenn das Auto an die Wallbox angesteckt wird sollte das SOC und der Status ca. alle 5 Min neu vom Auto übertragen werden.
EVCC details:
Show output of
evcc -v:Show evcc configuration file
evcc.yaml:type: sma
serial: 300613xxxx
type: modbus
model: sunspec
uri: 192.168.0.165:502
id: 126
charger definitions
name can be freely chosen and is used as reference when assigning charger to vehicle
for examples see https://github.com/andig/evcc-config#chargers
chargers:
type: go-e # Go-e charger
uri: http://192.168.0.131
vehicle definitions
name can be freely chosen and is used as reference when assigning vehicle to loadpoint
for examples see https://github.com/andig/evcc-config#vehicles
vehicles:
name: tesla
type: tesla
title: Model 3
capacity: 79
clientid: xxx
clientsecret: xxx
user: xxx # your email address used on Tesla website
password: xxx # your password used on Tesla website password
vin: xxx # the VIN of you car (can be obtained from Tesla website)
cache: 5m
name: nissan
type: nissan
title: Leaf # display name for UI
capacity: 40 # kWh
user: xxx # user
password: xxx # password
region: DE # carwings region, leave empty for Europe
cache: 5m # cache API response
site describes the EVU connection, PV and home battery
site:
title: xxx # display name for UI
meters:
grid: sma-grid # grid meter
pv: sma-pv # pv meter
battery: battery # battery meter
prioritySoC: 60 # give home battery priority up to this soc (0 to disable)
loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
charger: GO-eCharger # charger
meters:
charge: charge # charge meter
vehicle: audi
vehicles: # use if multiple vehicles allowed to charge on this loadpoint
- nissan
mode: now
soc:
min: 0 # immediately charge to 0% regardless of mode unless "off" (disabled)
target: 80 # always charge to 100%
alwaysUpdate: false # set true to update vehicle soc even when disconnected
estimate: false # set true to interpolate between api updates
levels: # target soc levels for UI
- 30
- 50
- 80
- 100
onDisconnect: # set defaults when vehicle disconnects
mode: now # switch back to pv mode
targetSoC: 80 # charge to 100%
phases: 3 # ev phases (default 3)
sensitivity: 1 # current raise/lower step size (default 10A)
enable: # pv mode enable behavior
delay: 1m # threshold must be exceeded for this long
threshold: 0 # minimum export power (W). If zero, export must exceed minimum charge power to enable
disable: # pv mode disable behavior
delay: 5m # threshold must be exceeded for this long
threshold: 500 # maximum import power (W)
guardduration: 10m # switch charger contactor not more often than this (default 10m)
mincurrent: 6 # minimum charge current (default 6A)
maxcurrent: 16 # maximum charge current (default 16A)
EVCC can integrate itself with Home Energy Management Systems.
At this time, the SMA Home Manager (SHM) is the only supported
system. To enable add
hems:
type: sma
mqtt message broker
mqtt:
broker: localhost:1883
topic: evcc # root topic for publishing, set empty to disable
user:
password:
influx database
influx:
url: http://localhost:8086
database: evcc
user:
password:
push messages
messaging:
events:
start: # charge start event
title: Charge started
msg: Started charging in "${mode}" mode
stop: # charge stop event
title: Charge finished
msg: Finished charging ${chargedEnergy:%.1fk}kWh in ${chargeDuration}.
connect: # vehicle connect event
title: Car connected
msg: "Car connected at ${pvPower:%.1fk}kW PV"
disconnect: # vehicle connected event
title: Car disconnected
msg: Car disconnected after ${connectedDuration}
services:
- type: pushover
app: # app id
recipients:
- # list of recipient ids
- type: telegram
token: # bot id
chats:
- # list of chat ids
- type: email
uri: smtp://:@:/?fromAddress=&toAddresses=
Kann ich noch irgend welche Daten liefern?
Gruß
Martin
The text was updated successfully, but these errors were encountered: