evcc
evcc copied to clipboard
evcc-io
FATAL errors during startup are not reported over mqtt
Is your feature request related to a problem? Please describe. when e.g. the IP address of a configured wall box changes, evcc dies in the startup process with a message like Mar 12 19:43:20 iWattControllerV3 evcc[36822]: [main ] FATAL 2024/03/12 19:43:20 cannot create charger 'OpenWbSeries2-1': cannot create charger type 'template': cannot create charger type 'openwb': error connecting: network Error : dial tcp 192.168.10.31:1883: i/o timeout
Describe the solution you'd like I would like to see fatal errors reported over the mqtt interface, to my service will be able to react and report this further to the user
Describe alternatives you've considered I considered parsing the log file of the evcc process, but this seems like a tedious and solution as we do all the other communication via the mqtt interface
Additional context not using the evcc UI, but our mobile and web app
@thomas-hutterer-tik gibts den nur auf MQTT nicht oder gar nicht (auch nicht /api/state)? Schaust Du unter error oder unter fatal?
das /api/state liefert in dem Fall 404:
pi@raspberrypi:~ $ journalctl -o cat -fu evcc Stopped evcc. evcc.service: Consumed 1min 36.971s CPU time. Started evcc. [main ] INFO 2024/03/13 20:15:06 evcc 0.122.1 [main ] INFO 2024/03/13 20:15:06 using config file: /etc/evcc.yaml [main ] INFO 2024/03/13 20:15:06 starting ui and api at :7070 [db ] INFO 2024/03/13 20:15:07 using sqlite database: /var/lib/evcc/evcc.db [mqtt ] INFO 2024/03/13 20:15:07 connecting evcc-1489565960 at tcp://127.0.0.1:1883 [main ] FATAL 2024/03/13 20:15:08 cannot create charger 'Keba-1': cannot create charger 'template': cannot create charger 'keba-udp': recv timeout [main ] FATAL 2024/03/13 20:15:08 will attempt restart in: 5m0s ^C pi@raspberrypi:~ $ curl localhost:7070/api/state 404 page not found
auf mqtt gibt es eine /site/error topic aber kein /site/fatal
Kann gut sein, dass das Beenden im Fall von fatal schneller geht, als gepublished wird.
wäre fein wenn das geändert wird, damit wir das mit bekommen und eine Fehlermeldung anzeigen können
das /api/state liefert in dem Fall 404: ^C
Naja- nachdem Du den Prozess mit ^C abgeschossen hast läuft natürlich kein Webserver mehr. Du musst also bitte vorher schauen.
ich habe journalctl mit ^C beendet. Der evcc process hat sich zuvor schon selbst beendet.
Meiner Meinung nach ist der Fehler gar nicht unbedingt die fehlende Meldung, sondern der Crash. Eine App wie evcc sollte nur crashen, wenn ihr Core disfunktional ist. Externe Verbindung dürfen niemals zu einem Crash führen.
Leider passiert das sogar während des Betriebs, was evcc sehr unzuverlässig macht.
Ah...
Leider passiert das sogar während des Betriebs, was evcc sehr unzuverlässig macht.
Gibts dafür irgendwelche Belege? Dann bitte Issue.
Gibts dafür irgendwelche Belege? Dann bitte Issue.
Leider schreibt evcc kein verwertbares Log als Addon unter Homeassistant und der Umstand, dass der Fehler mehr oder weniger sofort zu einem Restart führt, der Fehler aber random auftritt, macht es praktisch unmöglich, dies zu beobachten.
Ich habe gestern und heute mehrmals diesen Spass mit meiner Elvi erleben dürfen, was leider auch dazu führt, dass die absolut stabil laufende go-e in Mitleidenschaft gezogen wird. Inzwischen nervt mich das so sehr, dass ich die Elvi aus evcc herausgenommen habe und manuell steuere. Schade, aber leider nicht anders machbar, da mir die Zuverlässigkeit wichtiger ist, als eine gesteuerte Gästewallbox.
Die Lösung: kein HA nutzen in diesem Fall bis der Fehler gefunden ist.
Bitte dieses provokative, nicht zielführende Mantra ablegen. Ich verstehe nicht, warum hier ständig auf HA rumgedroschen wird, obwohl der Fehler ganz klar bei evcc liegt. Das ist unseriös.