Closed Christoph-87 closed 2 months ago
Sorry, no docker support...
Der Grund des Schließend für mich nicht nachvollziehbar.. Der Ersteller scheint ein Problem mit einer unterstützen Wallbox zu haben.. das evcc unter Docker läuft ist hier nicht das Problem, obgleich die Logauschnitte sehr wirr sind und am Ende zumindest evcc lauffähig ist.. Wenn nicht bereits geschehen beide Wallboxen vor dem Starten von evcc von Hand in den "manual"-Mode zu stellen. Was für ein Fw-Update läuft denn? Vielleicht ist dies nicht mehr kompatibel zur evcc-Implementierung..
Sind denn die beiden Wallboxen aus dem Docker-Container heraus erreichbar?
NOTE if you're using HomeAssistant or Docker we ask you to reproduce the problem on plain Linux or Windows first.
@mdkeil super nett wenn Du es auch trotz Docker unterstützen kannst/willst 👍🏻
Vielen Dank für die Rückmeldung.
Beide Wallboxen stehen auf "Manuell".
Die Einstellungen von Wallbox 1:
eCB1 Seriennummer 75654059 Firmware V1.73 Type PV OS Version 0.99 OS Component 78000001 MAC-LAN 00:D0:93:31:14:93 LAN IP-Adresse 192.168.2.8 Netzwerkmaske 255.255.255.0 Gateway 192.168.2.1
Die Einstellungen von Wallbox 2:
eCB1 Seriennummer 75658705 Firmware V1.73 Type PV OS Version 0.99 OS Component 78000001 MAC-LAN 00:D0:93:31:19:36 LAN IP-Adresse 192.168.2.9 Netzwerkmaske 255.255.255.0 Gateway 192.168.2.1
Aus dem Container heraus kann ich beide Wallboxen anpingen:
/app # ping 192.168.2.8 PING 192.168.2.8 (192.168.2.8): 56 data bytes 64 bytes from 192.168.2.8: seq=0 ttl=63 time=3.003 ms 64 bytes from 192.168.2.8: seq=1 ttl=63 time=1.554 ms ^C --- 192.168.2.8 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 1.554/2.278/3.003 ms /app # ping 192.168.2.9 PING 192.168.2.9 (192.168.2.9): 56 data bytes 64 bytes from 192.168.2.9: seq=0 ttl=63 time=3.481 ms 64 bytes from 192.168.2.9: seq=1 ttl=63 time=2.881 ms 64 bytes from 192.168.2.9: seq=2 ttl=63 time=6.572 ms ^C --- 192.168.2.9 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 2.881/4.311/6.572 ms /app #
Gibt es denn sonst Details die hilfreich sind?
Hier in dem Screenshot habe ich zunächst EVCC gestartet und dann den Fehler für die Garage bekommen. Dann habe ich aus der Konfiguration die Wallbox "Garage" herausgenommen und das gleiche Ergebnis für die Wallbox im Carport erhalten.
Den folgenden Fehler erhalte ich nicht mehr, nachdem ich das Switch neu gestartet habe:
[main ] FATAL 2024/09/11 17:15:35 cannot create charger 'carport': cannot create charger type 'template': cannot create charger type 'hardybarth-ecb1': Post "http://192.168.2.8/api/v1/chargecontrols/1/mode": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Stattdessen bekomme ich ausschließlich den 404-Fehler. Gibt es denn eine Möglichkeit herauszufinden, welche URL aufgerufen wird?
Gibt es denn eine Möglichkeit herauszufinden, welche URL aufgerufen wird?
also maßgeblich muss die Seite http://<IP>/api/v1
Daten lieferb - alle weiteren Abfragen z.B. /chargecontrols, /meters bauen darauf auf.. die kompletten Abfragen finden sich natürlich auch in der hardybarth-ecb1.go wieder, wenn man ein wenig code lesen und verstehen kann.
Ich schau mal, ob ich in der aktuellen Anleitung von deiner WB was finden kann.. ggfs. hat sich ja die API geändert..
Edit: muss die Api vielleicht in der Konfiguration erst noch aktiviert werden? Edit2: welcher Charge-Controller ist denn ausgewählt?
Eventuell ist das das Problem?
Folgende API wurde implementiert.. V1.3 // glaube aber die V1.4 sollte aber abwärtskompatibel sein http://apidoc.ecb1.de/
Welcher Charge-Controller ist denn in der Konfiguration ausgewählt?
Probiere z.B. mal
http://<IP>/api/v1/meters/0
http://<IP>/api/v1/meters/1
http://<IP>/api/v1/chargecontrols/0
http://<IP>/api/v1/chargecontrols/1
Rückgabe von
http://<IP>/api/v1/meters/0
:
{"meter": {"id": 0, "function": "main", "data": {"lgwb": -1333.5, "1-0:1.4.0": 1333.5, "1-0:61.4.0": 0.0, "1-0:41.4.0": 1542.6, "1-0:22.8.0": 3498.9362, "1-0:2.8.0": 5469.1449, "1-0:1.8.0": 14091.1822, "1-0:32.4.0": 230.524, "1-0:73.4.0": 0.924, "1-0:61.8.0": 5813.6346999999988, "1-0:71.4.0": 0.72400000000000012, "1-0:62.4.0": 141.5, "1-0:41.8.0": 9676.2732, "1-0:72.4.0": 229.22099999999994, "1-0:21.4.0": 0.0, "1-0:22.4.0": 67.6, "1-0:52.4.0": 228.488, "1-0:62.8.0": 6609.9287000000012, "1-0:2.4.0": 0.0, "1-0:21.8.0": 6090.6473, "1-0:31.4.0": 1.1379999999999999, "1-0:51.4.0": 6.9620000000000012, "1-0:53.4.0": 0.988, "1-0:42.8.0": 2849.6529999999994, "1-0:42.4.0": 0.0, "1-0:13.4.0": 0.947, "1-0:33.4.0": 0.412}, "type": "Energymeter", "name": "SMA Energy Meter", "ipaddress": "239.12.255.254", "vendor": "SMA", "serial": 3009885828}, "protocol-version": "1.4"}
Rückgabe von http://<IP>/api/v1/meters/1
{"meter": {"id": 1, "function": "socket", "data": {"lgwb": -4.3, "1-0:1.4.0": 4.3, "1-0:61.4.0": 0.0, "1-0:41.4.0": 0.0, "1-0:22.8.0": 0.0, "1-0:2.8.0": 0.0, "1-0:1.8.0": 0.0914, "1-0:32.4.0": 230.442, "1-0:73.4.0": 0.0, "1-0:61.8.0": 0.0, "1-0:71.4.0": 0.0, "1-0:62.4.0": 0.0, "1-0:41.8.0": 0.0, "1-0:72.4.0": 229.055, "1-0:21.4.0": 4.3, "1-0:22.4.0": 0.0, "1-0:52.4.0": 228.22, "1-0:62.8.0": 0.0, "1-0:2.4.0": 0.0, "1-0:21.8.0": 0.0914, "1-0:31.4.0": 0.017999999999999994, "1-0:51.4.0": 0.0, "1-0:53.4.0": 0.0, "1-0:42.8.0": 0.0, "1-0:42.4.0": 0.0, "1-0:13.4.0": 0.99900000000000012, "1-0:33.4.0": 0.99900000000000012}, "type": "eCB1 intern", "name": "Carport Wallbox", "ipaddress": "127.0.0.1", "vendor": "eCHARGE", "serial": 75654059}, "protocol-version": "1.4"}
Bei http://<IP>/api/v1/chargecontrols/0
{"protocol-version": "1.4", "errors": {"message": "EV-ChargingController Not Found", "id": 0}}
Bei http://<IP>/api/v1/chargecontrols/1
{"protocol-version": "1.4", "errors": {"message": "EV-ChargingController Not Found", "id": 1}}
Zusätzlich bei http://192.168.2.8/api/v1/chargecontrols
:
{"chargecontrols": [], "protocol-version": "1.4"}
Das habe ich vermutet, dass kein chargecontroller in der WB-Konfiguration eingestellt ist.. Das bitte mal nachholen. Gerne einen Screenshot machen, was zu Auswahl steht :)
mit docker exec -it <evcc containerid> evcc charger
auf der conssole kannst Du auch außerhalb des Containers direkt die charger-config überprüfen.
Da erhalte ich leider die gleiche Fehlermeldung:
Wenn Du in der WB-Konfiguration noch nichts geändert hast, ist das nicht verwunderlich.. Was ist denn nun in der bei deiner WB in der Konfiguration (nicht in der evcc-config) unter Charge Controller / EVCC eingestellt?
Aktuell ist das hier die Einstellung? Das muss wie im Screenshot umgestellt werden?
ja, das wäre mein Ansatzpunkt.. welche Auswahl steht denn sonst noch zur Verfügung?
Meine Auswahl ist:
Ich würde beginnend mit Phoenix-RTU testen und wenn es das gleiche Fehlerbild ist auf Phoenix-ETH wechseln.. sollte es dann immer noch nicht funktionieren, gehen mir die Ideen aus.
Die Fehlermeldung bei Phoenix (RTU) ist nun anders (bei Bus ID habe ich 0 und 1 versucht).
Es erscheint nicht mehr der 404-Fehler. Stattdessen erhalte ich folgenden Fehler:
[main ] FATAL 2024/09/13 15:11:29 cannot create charger 'garage': cannot create charger type 'template': cannot create charger type 'hardybarth-ecb1': Post "http://192.168.2.9/api/v1/chargecontrols/1/mode": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Unter Werte wird bei mir nun auch folgendes angezeigt:
Bei Phoenix (RTU) Bus 0:
Garage Wallbox | Energie | -4.0 W |
---|---|---|
Zählerstand | 0.18 kWh | |
L1 | 0.02 A | |
L2 | 0.00 A | |
L3 | 0.00 A | |
EVCC | Status | -1 |
PWM | 0 |
Bei Phoenix (RTU) Bus 1: Garage Wallbox | Energie | -4.0 W |
---|---|---|
Zählerstand | 0.18 kWh | |
L1 | 0.02 A | |
L2 | 0.00 A | |
L3 | 0.00 A | |
EVCC | Status | 0 |
PWM | 0 |
Wenn ich im Browser http://192.168.2.9/api/v1/chargecontrols/1/mode aufrufe, dann erhalte ich folgende Rückmeldung:
{"protocol-version": "1.4", "mode": "manual"}
Beim Probieren ist mir allerdings aufgefallen, dass mein Fritz Repeater mit IP 192.168.2.63 in der Garage nicht zuverlässig ist:
Request timeout for icmp_seq 271
Request timeout for icmp_seq 272
Request timeout for icmp_seq 273
Request timeout for icmp_seq 274
Request timeout for icmp_seq 275
Request timeout for icmp_seq 276
Request timeout for icmp_seq 277
Request timeout for icmp_seq 278
64 bytes from 192.168.2.63: icmp_seq=274 ttl=64 time=5175.450 ms
64 bytes from 192.168.2.63: icmp_seq=275 ttl=64 time=4174.402 ms
64 bytes from 192.168.2.63: icmp_seq=276 ttl=64 time=3170.209 ms
64 bytes from 192.168.2.63: icmp_seq=277 ttl=64 time=2168.421 ms
64 bytes from 192.168.2.63: icmp_seq=278 ttl=64 time=1754.892 ms
64 bytes from 192.168.2.63: icmp_seq=279 ttl=64 time=754.941 ms
Request timeout for icmp_seq 285
Request timeout for icmp_seq 286
Request timeout for icmp_seq 287
Request timeout for icmp_seq 288
Ich denke, dass das meine aktuelle Meldung erklärt:
[main ] FATAL 2024/09/13 15:11:29 cannot create charger 'garage': cannot create charger type 'template': cannot create charger type 'hardybarth-ecb1': Post "http://192.168.2.9/api/v1/chargecontrols/1/mode": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
ich denke Phoenix-RTU mit ID 1 wird vermutlich korrekt sein. Das Folgeproblem hängt ggfs. wirklich mit dem Repeater zusammen.
Danke - nach einer Neukonfiguration vom Repeater habe ich es nun geschafft EVCC zumindest mit einem Gerät zu starten - beide gleichzeitig scheint bei mir nicht zu funktionieren. Ich erhalte dann wieder den folgenden Fehler, obwohl das Gerät pingbar ist. Das Gerät wird genau dann nicht mehr ansprechbar, wenn ich EVCC starte.
[main ] FATAL 2024/09/13 15:11:29 cannot create charger 'garage': cannot create charger type 'template': cannot create charger type 'hardybarth-ecb1': Post "http://192.168.2.9/api/v1/chargecontrols/1/mode": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Das Gerät verhält sich nach dem Start von EVCC wie folgt:
PS /Users/christoph> ping 192.168.2.62
PING 192.168.2.62 (192.168.2.62): 56 data bytes
64 bytes from 192.168.2.62: icmp_seq=0 ttl=64 time=24.693 ms
64 bytes from 192.168.2.62: icmp_seq=1 ttl=64 time=16.933 ms
^C
--- 192.168.2.62 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 16.933/20.813/24.693/3.880 ms
PS /Users/christoph> nc -zv 192.168.2.62 80
Connection to 192.168.2.62 port 80 [tcp/http] succeeded!
PS /Users/christoph> curl 192.168.2.62
Bei curl kommt kein Ergebnis. Auch mit dem Browser kann ich die URL nicht mehr aufrufen. Die Wallbox ist erst wieder erreichbar, wenn ich die Sicherung trenne und wieder verbinde. Dann ist die Wallbox so lange erreichbar, bis ich EVCC starte.
Die IP der Wallbox hat sich verändert, weil ich die Netzwerkeinstellung auf "DHCP" geändert habe, um zu probieren, ob es an den Netzwerkeinstellungen der Wallbox liegt.
Kann das weitere Problem daran liegen, dass beide Wallboxen die Bus ID 1 haben?
hmm.. beide Wallboxen gleich konfiguriert..? also mit Phoenix-RTU und ID 1?
ja, beide mit Phoenix-RTU und ID 1. Ich habe eine der Wallboxen aufgeschraubt und bei Bus leuchtet es auch grün.
Kann das weitere Problem daran liegen, dass beide Wallboxen die Bus ID 1 haben?
nö, sind doch zwei eigenständige Geräte.. oder sind beide Geräte noch untereinander irgendwie verdrahtet?
funktioniert es mit der WB, wenn diese als einzige in der Konfiguration aktiv ist?
Ja, sind zwei eigenständige Geräte und nicht verdrahtet. Ich habe nun gemerkt, dass die Geräte auch ohne Zutun von EVCC nach einer Weile nicht mehr über das Web-Frontend reagieren. Deswegen habe ich den Support von Hardy Barth nun angeschrieben. Falls sich daraus etwas ergibt, melde ich mich hier.
Der Support von Hardy Barth konnte mir helfen - es lag an der Wallbox oder dem Netzwerk. Ich bin nicht sicher was letztendlich der Grund war, aber nun kann ich EVCC wieder ohne Probleme starten.
Describe the bug
I try to connect EVCC with two Hardy Barth eCB1 Wallboxes via the template.
Unfortunately while loading EVCC, I receive the following error:
Later I also received:
I can access the web frontend of the hard barth wallboxes via the IPs from my laptop.
I run EVCC with docker. The compose file is: version: "3.8"
In addition I have traefik running and it did run until last week.
Steps to reproduce
Unfortunately I am not sure how to reproduce this. It appears now every time I try to start EVCC.
Configuration details
Log details
What type of operating system are you running?
Linux
Nightly build
Version
/app # evcc -v evcc version 0.130.8