Closed swa72 closed 2 months ago
Bei mir funktioniert das Verwenden des commandProxy nicht zuverlässig.
Hier fehlt die Fehlerbeschreibung.
Danke für den Kommentar. Mein Fehler lautet: Nutzung von commandProxy
konfiguriert, dennoch wird tesla.evcc.io
verwendet.
Was heisst "not reliably" vs. "wird tesla.evcc.io verwendet"? Geht gar nicht? Nur manchmal? Was sagt:
cat /config/evcc.yaml | grep --context=3 commandProxy
Beim cat
Befehl mag er den context nicht.
➜ ~ cat /config/evcc.yaml | grep commandProxy
commandProxy: http://192.168.178.78:8080
commandProxy: http://192.168.178.78:8080
Zur Vollständigkeit noch einmal das jüngste Log evcc-20240805-134653-trace.log
Ich wünschte, dass ich das Verhalten besser eingrenzen kann, aber bei einem Tesla nimmt es den Proxy, beim anderen ggw. nicht. Leider enthält der letzte Satz auch einen Weichmacher, denn es hat bereits für den anderen Tesla auch funktioniert. Die Konfiguration ist identisch und ich habe das HA-addon bereits häufig durchgestartet.
vehicles:
# - name: T1 # no spaces or special characters
# type: template
# template: tesla-command
# accessToken: XXX
# refreshToken: XXX
# vin: XXX7002
# no spaces or special characters in the next line
- name: R1
type: template
template: tesla
accessToken: XXX
refreshToken: XXX
vin: XXX000
commandProxy: http://192.168.178.78:8080
# no spaces or special characters in the next line
- name: T1
type: template
template: tesla
accessToken: XXX
refreshToken: XXX
vin: XXX7002
commandProxy: http://192.168.178.78:8080
aber bei einem Tesla nimmt es den Proxy, beim anderen ggw. nicht.
Und nochmal ein neuer Informationshappen. Es ist eigentlich fast unmöglich, dass das passiert (tm). Könntest Du deine vollständige Config bitte an info@evcc.io schicken?
Config confirmed working.
Hallo Miteinander,
habe eine aehnliche Konfiguration - auch mit zwei Teslas, auch beide via commandProxy und sehe im Log fehlerhafte calls via tesla.evcc.io
Falls der Fehler bei swa72 an der Config lag habe ich moeglicherweise denselben?
Da ich gerade beide Autos zur Verfuegung haette koennte ich bei bedarf auch weitere tests machen. Sg, Alex
[lp-2 ] DEBUG 2024/08/08 17:18:45 charge power: 0W [lp-2 ] DEBUG 2024/08/08 17:18:45 charge currents: [0 0.3 0.2]A [lp-3 ] DEBUG 2024/08/08 17:18:45 charge power: 0W [site ] DEBUG 2024/08/08 17:18:45 pv power: 6359W [site ] DEBUG 2024/08/08 17:18:45 grid meter: -144W [site ] DEBUG 2024/08/08 17:18:45 site power: -144W [lp-2 ] DEBUG 2024/08/08 17:18:45 charge voltages: [4.7 0 0]V [lp-2 ] DEBUG 2024/08/08 17:18:45 !! session: chargeRater.chargedEnergy=14.7 - chargedAtStartup=0.0 [lp-2 ] DEBUG 2024/08/08 17:18:45 charger status: B [lp-2 ] DEBUG 2024/08/08 17:18:45 !! active phases: 3p = min(3p measured 0p vehicle 3p physical 0p charger) [lp-2 ] DEBUG 2024/08/08 17:18:45 pv charge current: 0.209A = 0A + 0.209A (-144W @ 3p) [tesla ] TRACE 2024/08/08 17:18:45 POST https://tesla.evcc.io/api/1/vehicles/<***VIN***>/command/set_charging_amps [tesla ] TRACE 2024/08/08 17:18:45 {"charging_amps": 3} -- Retry in 31275 seconds [lp-2 ] ERROR 2024/08/08 17:18:45 max charge current 3A: 429 Too Many Requests [site ] TRACE 2024/08/08 17:18:45 telemetry: charge: Δ72/72Wh @ 4347W [site ] TRACE 2024/08/08 17:18:45 POST https://api.evcc.io/v1/charge [site ] TRACE 2024/08/08 17:18:45 {"instanceId":"3d2348bb34f019b6bf756c117a8d0bc3b5028d8a22150d4fb5791b0b57f9587f","chargePower":4347.469999999999,"greenPower":4347.469999999999,"chargeEnergy":0.07189999999999985,"greenEnergy":0.07189999999999985} -- {"status":"ok"} [mqtt ] TRACE 2024/08/08 17:18:50 recv pvdataevcc/sensor/pv01_power_meter_active_power: '1608.0' [mqtt ] TRACE 2024/08/08 17:18:50 recv pvdataevcc/sensor/pv02_power_meter_active_power: '5365' [mqtt ] TRACE 2024/08/08 17:18:50 recv pvdataevcc/sensor/grid_power_consumption_ac_power: '480'
Log unleserlich. Die Config funktionierte im Fall oben reproduzierbar. Was sagt bei Dir
evcc charger --log trace --enable
...und wie sieht die Config dazu aus?
Hoffe dieses mal funktioniert das einruecken
die config:
vehicles:
- type: template template: tesla title: Egon accessToken: refreshToken: vin: XP7YGCEK6P*****2 capacity: 76.8 name: egon commandProxy: http://172.16.80.77:8080
anbei der trace:
/app # evcc charger --log trace --enable [main ] INFO 2024/08/08 21:24:46 evcc 0.129.0 [main ] INFO 2024/08/08 21:24:46 using config file: /etc/evcc.yaml [db ] INFO 2024/08/08 21:24:46 using sqlite database: /root/.evcc/evcc.db [db ] TRACE 2024/08/08 21:24:46 SELECT count() FROM sqlite_master WHERE type='table' AND name="settings" -1
[db ] TRACE 2024/08/08 21:24:46 SELECT sql FROM sqlite_master WHERE type IN ("table","index") AND tbl_name = "settings" AND sql IS NOT NULL order by type = "table" desc 1 FROM[db ] TRACE 2024/08/08 21:24:46 SELECT settings
LIMIT 1 -1[db ] TRACE 2024/08/08 21:24:46 SELECT FROM settings
54[mqtt ] INFO 2024/08/08 21:24:46 connecting evcc-4204597 at tcp://172.16.120.245:1883 [mqtt ] DEBUG 2024/08/08 21:24:46 tcp://172.16.120.245:1883 connected [db ] TRACE 2024/08/08 21:24:46 SELECT count( ) FROM sqlite_master WHERE type='table' AND name="devices" -1[db ] TRACE 2024/08/08 21:24:46 SELECT count() FROM sqlite_master WHERE type='table' AND name="device_details" -1 [db ] TRACE 2024/08/08 21:24:46 SELECT count( ) FROM sqlite_master WHERE type='table' AND name="configs" -1[db ] TRACE 2024/08/08 21:24:46 SELECT sql FROM sqlite_master WHERE type IN ("table","index") AND tbl_name = "configs" AND sql IS NOT NULL order by type = "table" desc 1 [db ] TRACE 2024/08/08 21:24:46 SELECT FROM configs
LIMIT 1 -1[db ] TRACE 2024/08/08 21:24:46 SELECT count( ) FROM sqlite_master WHERE type='table' AND name="config_details" -1[db ] TRACE 2024/08/08 21:24:46 SELECT sql FROM sqlite_master WHERE type IN ("table","index") AND tbl_name = "config_details" AND sql IS NOT NULL order by type = "table" desc 2 [db ] TRACE 2024/08/08 21:24:46 SELECT FROM config_details
LIMIT 1 -1[db ] TRACE 2024/08/08 21:24:46 SELECT count( ) FROM sqlite_master WHERE type = "table" AND tbl_name = "config_details" AND (sql LIKE "%CONSTRAINT ""fk_configs_details"" %" OR sql LIKE "%CONSTRAINT fk_configs_details %" OR sql LIKE "%CONSTRAINTfk_configs_details
%" OR sql LIKE "%CONSTRAINT [fk_configs_details]%" OR sql LIKE "%CONSTRAINT fk_configs_details %") -1[db ] TRACE 2024/08/08 21:24:46 SELECT count() FROM sqlite_master WHERE type = "index" AND tbl_name = "config_details" AND name = "idx_unique" -1 [db ] TRACE 2024/08/08 21:24:46 SELECT count( ) FROM sqlite_master WHERE type = "table" AND tbl_name = "config_details" AND (sql LIKE "%CONSTRAINT ""fk_devices_details"" %" OR sql LIKE "%CONSTRAINT fk_devices_details %" OR sql LIKE "%CONSTRAINTfk_devices_details
%" OR sql LIKE "%CONSTRAINT [fk_devices_details]%" OR sql LIKE "%CONSTRAINT fk_devices_details %") -1[db ] TRACE 2024/08/08 21:24:46 SELECT count() FROM sqlite_master WHERE type = "table" AND tbl_name = "config_details" AND (sql LIKE "%""device_id"" %" OR sql LIKE "%device_id %" OR sql LIKE "% device_id
%" OR sql LIKE "%[device_id]%" OR sql LIKE "% device_id %") -1[db ] TRACE 2024/08/08 21:24:46 SELECT FROMconfigs
WHEREconfigs
.class
= 1 ORDER BY id 0[tasmota] TRACE 2024/08/08 21:24:46 GET http://172.16.90.73/cm?cmnd=Status+0&password=&user= [tasmota] TRACE 2024/08/08 21:24:47 {"Status":{"Module":46,"DeviceName":"tm-wasserboiler","FriendlyName":["Boiler"],"Topic":"tasmota_555694","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0,"StatusRetain":0},"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://172.16.120.245:8080/13_tasmota-minimal.bin.gz","RestartReason":"Exception","Uptime":"2T08:46:16","StartupUTC":"","Sleep":50,"CfgHolder":4617,"BootCount":94,"BCResetTime":"1970-01-01T00:00:00","SaveCount":1468,"SaveAddress":"F8000"},"StatusFWR":{"Version":"13.2.0.1(tasmota)","BuildDateTime":"2023-10-28T14:22:40","Boot":31,"Core":"2_7_4_9","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"387/699"},"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["SuperMQTT",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C80001000600003C5A0A192800000000","00000080","00006000","00004000","00000000"]},"StatusMEM":{"ProgramSize":636,"Free":364,"Heap":20,"ProgramFlashSize":1024,"FlashSize":2048,"FlashChipId":"1540EF","FlashFrequency":40,"FlashMode":"DOUT","Features":["00000809","8F9AC787","04368001","000000CF","010013C0","C000F981","00004004","00001000","54000020","00000080"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,27,29,30,35,37,45,62,68","Sensors":"1,2,3,4,5,6","I2CDriver":"7"},"StatusNET":{"Hostname":"tm-wasserboiler","IPAddress":"172.16.90.73","Gateway":"172.16.90.254","Subnetmask":"255.255.255.0","DNSServer1":"172.16.90.254","DNSServer2":"0.0.0.0","Mac":"B4:E6:2D:55:56:94","Webserver":2,"HTTP_API":1,"WifiConfig":4,"WifiPower":17.0},"StatusMQT":{"MqttHost":"172.16.120.245","MqttPort":1883,"MqttClientMask":"tm-wasserboiler","MqttClient":"tm-wasserboiler","MqttUser":"mqtt","MqttCount":134,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4},"StatusTIM":{"UTC":"1970-01-03T08:46:40","Local":"1970-01-03T08:46:40","StartDST":"1970-01-01T00:00:00","EndDST":"1970-01-01T00:00:00","Timezone":"+00:00","Sunrise":"20:13","Sunset":"05:47"},"StatusSNS":{"Time":"1970-01-03T08:46:40","Switch1":"OFF"},"StatusSTS":{"Time":"1970-01-03T08:46:40","Uptime":"2T08:46:16","UptimeSec":204376,"Heap":20,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":134,"POWER":"OFF","Wifi":{"AP":1,"SSId":"SuperMQTT","BSSId":"02:EC:DA:FD:86:BD","Channel":11,"Mode":"11n","RSSI":64,"Signal":-68,"LinkCount":1,"Downtime":"0T00:00:03"}},"StatusSTK":{"Exception":0,"Reason":"Exception","EPC":["40238120","00000000","00000000"],"EXCVADDR":"00000000","DEPC":"00000000","CallChain":["40238120","40101c5b","40244b25","4024f674","4022307c","402530a2","40253100","401000e1","402230b4","4024f11d","4022a74e","401012c2","4022a867","40254280","40244173","4022aa3a","4022aa8d","401012c2","402207b4","40222c2f","40240504","402405b0","40100b38","402502c4","40101f51"]}} [main ] ERROR 2024/08/08 21:24:47 enable: loadpoint not initialized [main ] ERROR 2024/08/08 21:24:47 enable: loadpoint not initialized [tasmota] TRACE 2024/08/08 21:24:47 GET http://172.16.90.73/cm?cmnd=Power1+on&password=&user= [tasmota] TRACE 2024/08/08 21:24:47 {"POWER":"ON"}
hier noch ein auszug aus dem log: fuer einen Tesla schickt er sauber an den proxy wie hier z.b.
tesla ] TRACE 2024/08/08 17:12:15 POST http://172.16.80.77:8080/api/1/vehicles/XP7YGCE*****1/command/set_charging_amps [tesla ] TRACE 2024/08/08 17:12:15 {"charging_amps": 5} -- {"response":{"result":true,"reason":"The command was successfully received and will be processed in diesem falle jetzt fuer den zweiten an die tesla api. [tesla ] TRACE 2024/08/08 17:18:45 POST https://tesla.evcc.io/api/1/vehicles/XP7YGCE*****2/command/set_charging_amps [tesla ] TRACE 2024/08/08 17:18:45 {"charging_amps": 3} -- Retry in 31275 seconds [lp-2 ] ERROR 2024/08/08 17:18:45 max charge current 3A: 429 Too Many Requests
Manchmal ist es auch umgekehrt und calls fuer den 2 werden lokal abgearbeitet und 1 gehen richtung tesla api. Manuelle calls an das gateway funktionieren fuer beide.
[main ] ERROR 2024/08/08 21:24:47 enable: loadpoint not initialized
Schade, das kann man so nicht testen. Bitte nochmal:
evcc vehicle --log trace --start
fuer einen Tesla schickt er sauber an den proxy wie hier z.b.
Wenn das passiert- ab Start falsch? Oder zwischendrin? Korrigiert es sich auch irgendwann wieder? Verwendest Du HA? Passiert das auch mit nur einem Auto?
Wenn das passiert- ab Start falsch? Oder zwischendrin? Verwendest Du HA?
auffallen tut es am abend. Auto wird angesteckt und laedt dann los anstatt zu stoppen. Habe gerade nochmal evcc neu gestartet. Der eine Tesla kann problemlos gesteuert werden und die commands kommen am proxy auch an. Fuer den anderen hagelt es nur fehler von der tesla api.
Gut moeglich, dass er nach einem evcc neustart auch den ersten Wagen mit dem er interagiert richtung proxy schickt und den zweiten nicht.
evcc laeuft im Docker-container und bekommt die meisten daten (PV, Meter) via mqtt
Kann auch gerne das ganze docker trace-log zur Verfuegung stellen und per mail senden wenn benoetigt.
Sg, Alex
Ich hatte das add-on von HA im Einsatz und dort die kuriose Situation, dass ein Ändern der Reihenfolg in der evcc.yaml
einen Einfluss darauf hatte, ob EVCC den Proxy nimmt oder nicht. Erklären konnte ich mir das nicht - mal funktionierte die Konfiguration, mal nicht. Ich habe dann verzweifelt aufgegeben.
Mittlerweile habe ich EVCC von HA getrennt (separate VM auf Proxmox) und es läuft stabil (noch).
Es gibt keinen Grund, dass evcc zur Laufzeit die Config wechseln sollte. Es braucht weiter ein Log ab Start, ohne HA, das ein Problem zeigt.
Konnte nun einen testlauf machen. 10:21 erstes auto (Rennate) angesteckt 10:22 zweites auto (Egon) angesteckt 10:25 Hausecke (Rennate) auf off 10:26 Garage (Egon) off dann: Hausecke (Rennate) auf Fast (ging ueber tesla api) Garage (Egon) auf Fast (ueber Proxy) Hausecke (Rennate) auf Off (wieder tesla) Garage (Egon) Off (wieder ueber Proxy)
Das Tracelog: https://gist.github.com/laenglea/4ab47ecc5f58059d2bf3bec3911d172c
eventuell hilft das
Das sagt leider nichts über Deine Config. Einfache Diagnose: Rennate steht auf Tesla API.
Das sagt leider nichts über Deine Config. Einfache Diagnose: Rennate steht auf Tesla API.
Leider nicht. Anbei die config: https://gist.github.com/laenglea/9c386a32b2c9bd536aef90ae6641db9f
Sagst Du ;) Ab morgen wird im nightly der Proxy ausgegeben, dann sehen wir weiter.
In 15min gibts neues Nightly, gerne auch heute testen.
https://gist.github.com/laenglea/08c3274203da8df8178db62858b447cf
16:27 erstes auto (Rennate) angesteckt 16:29 zweites auto (Egon) angesteckt 16:30 Hausecke (Rennate) auf off 16:31 Garage (Egon) off
dann: Hausecke (Rennate) auf Fast Garage (Egon) auf Fast Hausecke (Rennate) auf Off Garage (Egon) Off
…und? Kann von unterwegs nicht rein schauen, bin aber neugierig 🧐
oben steht jetzt: [tesla ] INFO 2024/08/10 16:25:25 !! tesla proxy for Rennate: http://172.16.80.77:8080 [tesla ] INFO 2024/08/10 16:25:25 !! tesla proxy for Egon: http://172.16.80.77:8080 jedoch immer noch calls via api [site ] TRACE 2024/08/10 16:33:00 POST https://api.evcc.io/v1/charge braucht es diese calls?
hier noch eines von heute abend: https://gist.github.com/laenglea/847aadce378aa8d50e79fcc40636b162
22:06 erstes auto (Rennate) angesteckt 22:08 zweites auto (Egon) angesteckt 22:09 Hausecke (Rennate) auf off 22:10 Garage (Egon) off (laedt weiter)
dann: Hausecke (Rennate) auf Fast Garage (Egon) auf Fast Hausecke (Rennate) auf Off Garage (Egon) Off
Mir fehlt leider die Zeit das alles durchzuwühlen. Gibts denn noch ein Problem?
Mir fehlt leider die Zeit das alles durchzuwühlen. Gibts denn noch ein Problem?
Ja! eines der beiden Autos geht trotz eingestelltem proxy ueber die tesla-api und hat damit probleme mit dem api-call limit.
bei den ersten beiden traces war es Rennate, beim dritten Egon.
Das fuehrt in meinem Fall (teilweise) dazu dass ein auto sich nicht sauber steuert und auch am abend die Ladung im PV Modus nicht abdreht und dann in der Nacht laedt.
Zielladungen funktionieren dadurch auch nicht zwingend - vorallem jene am abend wenn das api-limit schon erreicht wurde.
Wo sehe ich das im Log?
Das ist nur die Folge davon wie in #14226 beschrieben. Da wir gerade urlaub haben und die Autos relativ voll sind und meist genug ueberschuss vorhanden ist kann ich das so nicht nachstellen.
Wuerden die commands beider Autos sauber ueber den Proxy laufen wuerde ich den Tesla fleet API error 429 ja niemals bekommen.
Habe den Bluetooth Proxy ja genau deswegen hier.
Im log sehen wir nur post-calls welche anstatt an den proxy an die api gehen. Bei Log1 und Log2 fuer Rennate und bei Log3 fuer Egon ohne dass sich an der evcc.yaml was geaendert hat
Wo sehe ich das im Log?
Du beschreibst einen vermeintlichen Fehler. Bei welchem Timestamp?
Musste gerade suchen da die Fehler nicht sofort nach start auftreten. https://gist.github.com/laenglea/af6ab8ccd193d3319e85d655fe1dc11b das ist das Log von gestern 10:19 nur etwas laenger
Hier sind ein paar fehler mit drauf. z.b. [lp-1 ] ERROR 2024/08/10 13:14:18 charger disable: Post "https://tesla.evcc.io/api/1/vehicles/VIN_Rennate/command/charge_stop": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Ich frag mich manchmal, ob das so eine Art Versteckspiel ist. In dem ganzen Log sehe ich keine Ausgabe von !! tesla proxy
. Wo ist die hin? Eben gabs die noch... Was sagt mir das also über Deine verwendete Config? Gar nichts :(
Es hilft auch nicht, wenn Du lustig Versionen durcheinander testest ohne dazu zu schreiben, was was ist...
die Teslaproxy ausgabe gibt es ja erst seit gestern mittag in der nightly. Das Log ist von davor.
Du wolltest ja sehen wie er in das api-timeout rennt. die config ist immer dieselbe. Anbei die config: https://gist.github.com/laenglea/9c386a32b2c9bd536aef90ae6641db9f
Bitte sag mir was ich wie testen soll und ich werde es machen. Gerne schicke ich die logs auch ohne sie immer anonymisieren zu muessen.
Fuer mich als user schaut es aus als ob commandProxy bei zwei Fahrzeugen einfach nicht alles ueber command proxy schickt und das fuehrt zu problemen.
Wie kann ich dich bei der Fehlersuche unterstuetzen?
Ich frag mich manchmal, ob das so eine Art Versteckspiel ist. definitiv nicht
die Teslaproxy ausgabe gibt es ja erst seit gestern mittag in der nightly. Das Log ist von davor.
Das nutzt halt nix wenn wir Zusatzlogging zur Diagnose einbauen ;)
Das Problem ist unverändert. Es braucht ein aktuelles Log in dem nachvollziehbar wäre, dass a) die Config beim Start korrekt ist (Log Ausgabe) und dennoch b) falsche Requests gemacht werden. Bisher habe ich das noch nicht gesehen.
vielleicht hilft dieser. Habe den container mehrmals neu gestartet https://gist.github.com/laenglea/a0f51d9478780778951f3db2ec4601d4
docker-compose logs -f | grep 'tesla proxy' [tesla ] INFO 2024/08/11 14:52:09 !! tesla proxy for Egon: http://172.16.80.77:8080 [tesla ] INFO 2024/08/11 14:52:09 !! tesla proxy for Rennate: https://tesla.evcc.io/ [tesla ] INFO 2024/08/11 14:52:41 !! tesla proxy for Egon: https://tesla.evcc.io/ [tesla ] INFO 2024/08/11 14:52:41 !! tesla proxy for Rennate: http://172.16.80.77:8080 [tesla ] INFO 2024/08/11 14:52:57 !! tesla proxy for Egon: http://172.16.80.77:8080 [tesla ] INFO 2024/08/11 14:52:57 !! tesla proxy for Rennate: http://172.16.80.77:8080 [tesla ] INFO 2024/08/11 14:53:14 !! tesla proxy for Rennate: https://tesla.evcc.io/ [tesla ] INFO 2024/08/11 14:53:14 !! tesla proxy for Egon: https://tesla.evcc.io/ [tesla ] INFO 2024/08/11 14:53:30 !! tesla proxy for Egon: https://tesla.evcc.io/ [tesla ] INFO 2024/08/11 14:53:30 !! tesla proxy for Rennate: https://tesla.evcc.io/ [tesla ] INFO 2024/08/11 14:53:48 !! tesla proxy for Rennate: https://tesla.evcc.io/ [tesla ] INFO 2024/08/11 14:53:48 !! tesla proxy for Egon: http://172.16.80.77:8080
Ohne ins Log zu schauen: die Ausgabe beweist, dass die Config zum Start schon falsch ist, alternierend je Fahrzeug. Das ist tatsächlich sehr merkwürdig. Könntest Du bitte Deine komplette Config (und DB) mal an info@evcc.io schicken?
Kannst Du das Verhalten auch ohne Docker nachvollziehen?
Hurra! Ich kann den Fehler jetzt nachvollziehen:
vehicles:
- name: t1
type: template
template: tesla
commandproxy: http://foo
- name: t2
type: template
template: tesla
commandproxy: http://foo
- name: t3
type: template
template: tesla
commandproxy: http://foo
- name: t4
type: template
template: tesla
commandproxy: http://foo
gibt
[main ] INFO 2024/08/11 15:34:48 evcc 0.0.0
[main ] INFO 2024/08/11 15:34:48 using config file: cmd/demo.yaml
https://tesla.evcc.io/
[main ] ERROR 2024/08/11 15:34:49 creating vehicle t3 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla': init
http://foo
[main ] ERROR 2024/08/11 15:34:49 creating vehicle t4 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla': init
http://foo
[main ] ERROR 2024/08/11 15:34:49 creating vehicle t2 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla': init
https://tesla.evcc.io/
[main ] ERROR 2024/08/11 15:34:49 creating vehicle t1 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla': init
...und das ist falsch.
Ich blicke es nicht. Liegt es an der Konfiguration (mir fehlen accessToken, refreshToken und vin - zudem dachte ich dass es case sensitive sei "commandProxy") oder ist es die Anzahl der Fahrzeuge oder ist es der Code von EVCC? Oder einfach "tesla-command " statt "tesla" Ich würde ja gerne selber testen, bin aber mit dem Auto für ein paar Tage unterwegs...
Am So., 11. Aug. 2024 um 15:36 Uhr schrieb andig @.***>:
Hurra! Ich kann den Fehler jetzt nachvollziehen:
vehicles:
- name: t1 type: template template: tesla commandproxy: http://foo
- name: t2 type: template template: tesla commandproxy: http://foo
- name: t3 type: template template: tesla commandproxy: http://foo
- name: t4 type: template template: tesla commandproxy: http://foo
gibt
[main ] INFO 2024/08/11 15:34:48 evcc 0.0.0 [main ] INFO 2024/08/11 15:34:48 using config file: cmd/demo.yamlhttps://tesla.evcc.io/ [main ] ERROR 2024/08/11 15:34:49 creating vehicle t3 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla': inithttp://foo [main ] ERROR 2024/08/11 15:34:49 creating vehicle t4 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla': inithttp://foo [main ] ERROR 2024/08/11 15:34:49 creating vehicle t2 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla': inithttps://tesla.evcc.io/ [main ] ERROR 2024/08/11 15:34:49 creating vehicle t1 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla': init
...und das ist falsch.
— Reply to this email directly, view it on GitHub https://github.com/evcc-io/evcc/issues/15250#issuecomment-2282763799, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEGI2EZ42GMD44GNNZXTP53ZQ5SFBAVCNFSM6AAAAABL74VGVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBSG43DGNZZHE . You are receiving this because you authored the thread.Message ID: @.***>
-- Stefan Waldherr Phone +49-151-1131-6967
Lass mich mal schauen. Repro ist der erste Schritt, der Rest findet sich. PS. Case sensitive: ist yaml nicht!
Danke für den wunderbaren, tief in evcc versteckten Fehler und Eure Geduld! Mit etwas Glück ist das Problem morgen im Nightly gelöst.
Vielen Dank auch für deine Geduld und den superschnellen fix ❤️
Describe the bug
Bei mir funktioniert das Verwenden des commandProxy nicht zuverlässig. Ähnliches Verhalten wie der ein oder andere schon unter https://github.com/evcc-io/evcc/pull/14616 beschrieben hat.
Super wäre, wenn es irgendwo eine Beschreibung von
commandProxy
gäbe. Trotz Suchens habe ich in den Docs nichts gefunden.Config siehe https://github.com/swa72/home-assistant/blob/main/evcc-sanitized.yaml
Steps to reproduce
Configuration details
Log details
Das Log mit
trace
fürtesla