eebus not working on hassio
Closed this issue · 56 comments
Hey, I got the eebus connection working locally on my mac for the evvc.
When I try the same config inside of my hass then I do not get the log:
[eebus ] DEBUG 2024/07/15 13:35:20 incoming connection request from a9cfa5fac0e5631cb87f09ce726103519eXXXXX
I think the the wallbox cannot reach the evvc inside of hass due to the containers.
Logs from a working installation Local on my mac:
jorge@MacBook-Pro-4 ~/Downloads [8:41:56]
> $ evcc -c evcc.yaml
[main ] INFO 2024/07/17 08:42:06 evcc 0.128.2
[main ] INFO 2024/07/17 08:42:06 using config file: evcc.yaml
[db ] INFO 2024/07/17 08:42:06 using sqlite database: /Users/jorge/.evcc/evcc.db
[mqtt ] INFO 2024/07/17 08:42:06 connecting evcc-1236254900 at tcp://homeassistant.local:1883
[mqtt ] DEBUG 2024/07/17 08:42:06 tcp://homeassistant.local:1883 connected
[eebus ] INFO 2024/07/17 08:42:06 Local SKI: 9a46bcb42045efb7a5f449a89482621ca87eb4dc
[eebus ] DEBUG 2024/07/17 08:42:06 starting websocket server on :4712
[eebus ] DEBUG 2024/07/17 08:42:06 mdns: announce
[eebus ] DEBUG 2024/07/17 08:42:06 mdns: using zeroconf
[eebus ] DEBUG 2024/07/17 08:42:06 mdns: start search
[main ] INFO 2024/07/17 08:42:06 listening at :7070
[main ] FATAL 2024/07/17 08:43:36 cannot create charger 'wallbox3': cannot create charger type 'template': cannot create charger type 'eebus': i/o timeout
[main ] FATAL 2024/07/17 08:43:36 will attempt restart in: 15m0s
[eebus ] DEBUG 2024/07/17 08:44:09 ski: a9cfa5fac0e5631cb87f09ce726103519eff0fa6 name: Livo-EVB-500-HIDDEN brand: EVBox model: Livo typ: ChargingStation identifier: EVBox-Livo-EVB-500-HIDDEN register: false host: EVB-500-HIDDEN.local. port: 4712 addresses: [192.168.1.219]
[eebus ] DEBUG 2024/07/17 08:44:09 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-HIDDEN.local.
[eebus ] DEBUG 2024/07/17 08:44:09 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-HIDDEN.local.:4712/ship/
[eebus ] DEBUG 2024/07/17 08:44:16 incoming connection request from a9cfa5fac0e5631cb87f09ce726103519eff0fa6
[eebus ] DEBUG 2024/07/17 08:44:16 Send: read 1 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/17 08:44:17 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:NodeManagement to NodeManagement read 1 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/17 08:44:17 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN reply 2 1 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/17 08:44:17 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:NodeManagement to NodeManagement reply 3 1 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/17 08:44:17 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN call 3 NodeManagementSubscriptionRequestCall
[eebus ] DEBUG 2024/07/17 08:44:17 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN read 4 NodeManagementUseCaseData
[eebus ] DEBUG 2024/07/17 08:44:17 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN read 5 DeviceClassificationManufacturerData
[eebus ] DEBUG 2024/07/17 08:44:17 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN read 6 DeviceDiagnosisStateData
[eebus ] DEBUG 2024/07/17 08:44:17 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:NodeManagement to NodeManagement call 5 NodeManagementSubscriptionRequestCall
[eebus ] DEBUG 2024/07/17 08:44:17 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN result 7 5 ResultData 0
[eebus ] DEBUG 2024/07/17 08:44:17 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:NodeManagement to NodeManagement result 7 3 ResultData 0
[eebus ] DEBUG 2024/07/17 08:44:17 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:NodeManagement to NodeManagement reply 9 4 NodeManagementUseCaseData
[eebus ] DEBUG 2024/07/17 08:44:17 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:NodeManagement to NodeManagement read 13 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/17 08:44:17 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN reply 8 13 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/17 08:44:18 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:NodeManagement to NodeManagement read 15 NodeManagementDestinationListData
[eebus ] DEBUG 2024/07/17 08:44:18 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN reply 9 15 NodeManagementDestinationListData
[eebus ] DEBUG 2024/07/17 08:44:18 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:NodeManagement to NodeManagement read 17 NodeManagementUseCaseData
[eebus ] DEBUG 2024/07/17 08:44:18 Send: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN reply 10 17 NodeManagementUseCaseData
[eebus ] DEBUG 2024/07/17 08:44:18 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:DeviceClassification to DeviceClassification reply 19 5 DeviceClassificationManufacturerData
[eebus ] DEBUG 2024/07/17 08:44:18 Recv: d:_i:47859_EVBox-Livo-EVB-500-HIDDEN:DeviceDiagnosis to DeviceDiagnosis reply 21 6 DeviceDiagnosisStateData
[eebus ] DEBUG 2024/07/17 08:44:19 connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp [fe80::ee5c:84ff:fe21:618a%en0]:4712: i/o timeout
[eebus ] DEBUG 2024/07/17 08:44:19 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219
Logs from HA:
starting evcc: 'EVCC_DATABASE_DSN=/data/evcc.db evcc --config /config/evcc.yaml'
[main ] INFO 2024/07/17 08:49:11 evcc 0.128.2
[main ] INFO 2024/07/17 08:49:11 using config file: /config/evcc.yaml
[db ] INFO 2024/07/17 08:49:11 using sqlite database: /data/evcc.db
[mqtt ] INFO 2024/07/17 08:49:11 connecting evcc-660314251 at tcp://homeassistant.local:1883
[mqtt ] DEBUG 2024/07/17 08:49:11 tcp://homeassistant.local:1883 connected
[eebus ] INFO 2024/07/17 08:49:11 Local SKI: 9a46bcb42045efb7a5f449a89482621ca87eb4dc
[eebus ] DEBUG 2024/07/17 08:49:11 starting websocket server on :4712
[eebus ] DEBUG 2024/07/17 08:49:11 mdns: announce
[eebus ] DEBUG 2024/07/17 08:49:11 mdns: using zeroconf
[eebus ] DEBUG 2024/07/17 08:49:11 mdns: start search
[main ] INFO 2024/07/17 08:49:11 listening at :7070
[eebus ] TRACE 2024/07/17 08:49:11 registering ski: a9cfa5fac0e5631cb87f09ce726103519eff0fa6
[main ] FATAL 2024/07/17 08:50:41 cannot create charger 'wallbox3': cannot create charger type 'template': cannot create charger type 'eebus': i/o timeout
[main ] FATAL 2024/07/17 08:50:41 will attempt restart in: 15m0s
[eebus ] DEBUG 2024/07/17 08:50:52 ski: a9cfa5fac0e5631cb87f09ce726103519eff0fa6 name: Livo-EVB-500-015-503 brand: EVBox model: Livo typ: ChargingStation identifier: EVBox-Livo-EVB-500-015-503 register: false host: EVB-500-015-503.local. port: 4712 addresses: [192.168.1.219]
[eebus ] DEBUG 2024/07/17 08:50:52 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-015-503.local.
[eebus ] DEBUG 2024/07/17 08:50:52 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-015-503.local.:4712/ship/
[eebus ] DEBUG 2024/07/17 08:51:02 connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp 192.168.1.219:4712: i/o timeout
[eebus ] DEBUG 2024/07/17 08:51:02 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219
[eebus ] DEBUG 2024/07/17 08:51:02 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219:4712/ship/
[eebus ] DEBUG 2024/07/17 08:51:12 connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp 192.168.1.219:4712: i/o timeout
[eebus ] DEBUG 2024/07/17 08:51:12 mdns: announce
[eebus ] DEBUG 2024/07/17 08:51:12 mdns: using zeroconf
See the missing line "incoming connection request" on the ha logs ?
I think the the wallbox cannot reach the evvc inside of hass due to the containers
Hmmm, does EEBUS needs any ports additional to the ones we already pipe towards the evcc add-on container?
Lines 30 to 43 in 01046c1
Maybe 4712/tcp?
Ich denke schon das 4712 fehlt.
Weiß nicht ob es tcp ist. Ich werde heute Abend ein Nmap machen auf die lokal Installation dann kann ich dir Bescheid geben.
Also Habe es gestern abend nochmal probiert und dein Repo gefork. Hat nicht geklappt. mdns discovery vielleicht ?
@andig ist aufgefallen, dass der EEBUS Port im Dockerfile auch überhaupt nicht exposed wurde. Somit hilft meine Add-On Config wenig, wenn der Port dennoch nicht herausgereicht wird. Sobald ein neues Release von evcc da ist, bin ich guten Mutes dass das klappt.
Aber im dockerfile sehe ich nicht 4712
Sobald ein neues Release von evcc da ist, bin ich guten Mutes dass das klappt.
Das Dockerfile hat rein informativen Charakter, ändert funktional aber nichts.
Das Dockerfile hat rein informativen Charakter, ändert funktional aber nichts.
Du hast Recht, das EXPOSE ändert funktional gar nichts. Dann ist das nicht das Problem. @jomach würdest du auf deinem Host wo es funktioniert dann vielleicht mal ein Packet Capture laufen lassen und mir zur Verfügung stellen, damit ich sehe was da noch gesprochen wird?
Auf macOS:
❯ networksetup -listallhardwareports
um das richtige Interface herauszufinden
sudo tcpdump -i en0 -n host <IP-Adresse-der-Wallbox> -w trace.pcap
Und dann könntest du evcc auf deinem macOS starten und sobald evcc mit Wallbox gepaired ist das Packet Capture stoppen und das trace.pcap
zur Verfügung stellen.
Mach ich. Ich denke es liegt and das mdns Protokoll der über Udp läuft.
Ich denke es liegt and das mdns Protokoll der über Udp läuft.
Aber mDNS wird doch an den Container durchgereicht:
Line 32 in 01046c1
Du kannst auch über
log: info
levels:
eebus: trace
[...]
noch mal versuchen mehr aus dem Logging rauszukitzeln.
@DerAndereAndi kannst du helfen ? Uns ist nicht 100% klar wie der netzwerk traffic für eebus funktioniert.
mDNS braucht Multicast. In Docker braucht das i.A. den Host Mode. Wie es bei HA ist müsste mit HA geklärt werden.
Der Host Mode ist bereits seit Januar 2023 an, fällt mir grad auf:
https://github.com/evcc-io/hassio-addon/blame/main/evcc/config.json#L26
➜ ~ docker inspect 5dd643b33a60 | jq '.[].NetworkSettings'
{
"Bridge": "",
"SandboxID": "eb58555aa1faf0c9fc648f1351a07613baf7e0b97b6f913e9b0b5a35c8962eab",
"SandboxKey": "/var/run/docker/netns/default",
"Ports": {},
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "",
"Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "",
"IPPrefixLen": 0,
"IPv6Gateway": "",
"MacAddress": "",
"Networks": {
"host": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"MacAddress": "",
"NetworkID": "debcf04ad970548bf689f4c820495ef0358088f5a3e29c72460ce6f000e56c81",
"EndpointID": "63ef54b34eb1ac210beca4d5d1e438e07196633bfac62a7947217cf594b7318b",
"Gateway": "",
"IPAddress": "",
"IPPrefixLen": 0,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DriverOpts": null,
"DNSNames": null
}
}
}
Also liegt es doch an mDNS
Um das noch mal genau aufzudröseln, magst du mal trace Logging für EEBUS in deinem evcc auf HA aktivieren und hier pasten? Damit wir genau sehen, wo es hängt? Und idealerweise als Vergleich das gleiche von deinem macOS auch?
Ein paar Gedanken:
- Auf macOS sieht die Box evcc via mDNS, unter HA nicht. Entweder geht das announcement nicht raus, oder die Box hat einen Bug. Einen ähnlichen gibt es in der Elli Wallbox (auch von EVBox, da half jemandem das WLAN Netzwerkinterface zu aktivieren. (Warum auch immer)
- Auf HA sieht evcc die Box, unter HA auch
- Die Box macht nur einen Verbindungsaufbau wenn sie evcc sieht
- Man kann mit dem Discovery Tool auf dem Mac oder mit avahi in einem Terminal in Linux herausfinden ob das mDNS Announcement sichtbar ist. Discovery starten, evcc im Container starten -> Sichtbar ja/nein? Wenn nein, mögliches Container Konfig Problem.
- evcc macht unter HA einen Verbindungsaufbau, da keiner von der Box initiert wird. Und selbst der scheitert:
connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp 192.168.1.219:4712: i/o timeout
-> Entweder ist die Netzwerkadresse nicht erreichbar oder der Port unter der Netzwerkadresse nicht offen -> Kann ein Problem in der Box oder im Container sein
Vielleicht versuchst es erst mal auf dem Mac korrekt zum Laufen zu bekommen, bevor du den Container nutzt. Da gibt es zu vielen potenzielle Fehlerquellen von der Box selbst und auch von der Container Config.
Another note: the mDNS Entry of the Box is not visible at startup of evcc in both cases. It took multiple minutes. It should be visible at all times -> Problem in the Box?
Ein paar Gedanken:
- Auf macOS sieht die Box evcc via mDNS, unter HA nicht. Entweder geht das announcement nicht raus, oder die Box hat einen Bug. Einen ähnlichen gibt es in der Elli Wallbox (auch von EVBox, da half jemandem das WLAN Netzwerkinterface zu aktivieren. (Warum auch immer)
- Auf HA sieht evcc die Box, unter HA auch
- Die Box macht nur einen Verbindungsaufbau wenn sie evcc sieht
- Man kann mit dem Discovery Tool auf dem Mac oder mit avahi in einem Terminal in Linux herausfinden ob das mDNS Announcement sichtbar ist. Discovery starten, evcc im Container starten -> Sichtbar ja/nein? Wenn nein, mögliches Container Konfig Problem.
- evcc macht unter HA einen Verbindungsaufbau, da keiner von der Box initiert wird. Und selbst der scheitert:
connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp 192.168.1.219:4712: i/o timeout
-> Entweder ist die Netzwerkadresse nicht erreichbar oder der Port unter der Netzwerkadresse nicht offen -> Kann ein Problem in der Box oder im Container seinVielleicht versuchst es erst mal auf dem Mac korrekt zum Laufen zu bekommen, bevor du den Container nutzt. Da gibt es zu vielen potenzielle Fehlerquellen von der Box selbst und auch von der Container Config.
Hi, danke für die Tipps. Also Lokal auf mein Mac klappt alles. Ich sehe es dann in der UI und sehe die anpassung. Die timeouts die du kommentiert hast sind nur einmal danach geht es irgenwie (retry ? ).
nochmal auf mein macbook klappt alles, nur auf hassio nicht. Wie kann ich avahi innerhalb von evcc container in hassio testen ? Weiß jemand ob es überhaupt geht ? Müssen wir mDNS nutzen ?
Die einfachste Methode den Container zugänglich zu machen ist das portainer Addon. Damit lässt sich der Addon Container direkt über den Browser in HA öffnen.
puff ganz schon viel aufwand gerade...
Hi, danke für die Tipps. Also Lokal auf mein Mac klappt alles. Ich sehe es dann in der UI und sehe die anpassung. Die timeouts die du kommentiert hast sind nur einmal danach geht es irgenwie (retry ? ).
nochmal auf mein macbook klappt alles, nur auf hassio nicht. Wie kann ich avahi innerhalb von evcc container in hassio testen ? Weiß jemand ob es überhaupt geht ? Müssen wir mDNS nutzen ?
EEBUS muss mDNS nutzen, ja. Avahi im Container musst du nicht testen. Ob die mDNS Messages in evcc ankommen, siehst du wenn du TRACE logging an eebus anschaltest. Ob evcc mDNS Messages rausschreibt kannst du mit Discovery für macOS https://itunes.apple.com/us/app/discovery-dns-sd-browser/id1381004916?mt=12 testen
Discovery starten, evcc starten und gucken ob die evcc mDNS Einträge in Discovery aufploppen.
@jomach teste bitte mal: https://github.com/evcc-io/hassio-addon/tree/thecem-patch-mDNS-Test
Very similar but I think it now has ipv6 in the mix. Not sure.
starting evcc: 'EVCC_DATABASE_DSN=/data/evcc.db evcc --config /config/evcc.yaml'
[main ] INFO 2024/07/17 20:08:52 evcc 0.128.2
[main ] INFO 2024/07/17 20:08:52 using config file: /config/evcc.yaml
[db ] INFO 2024/07/17 20:08:52 using sqlite database: /data/evcc.db
[mqtt ] INFO 2024/07/17 20:08:52 connecting evcc-935579942 at tcp://homeassistant.local:1883
[mqtt ] DEBUG 2024/07/17 20:08:52 tcp://homeassistant.local:1883 connected
[eebus ] INFO 2024/07/17 20:08:52 Local SKI: 9a46bcb42045efb7a5f449a89482621ca87eb4dc
[eebus ] DEBUG 2024/07/17 20:08:52 starting websocket server on :4712
[eebus ] DEBUG 2024/07/17 20:08:52 mdns: announce
[eebus ] DEBUG 2024/07/17 20:08:52 mdns: using zeroconf
[eebus ] DEBUG 2024/07/17 20:08:52 mdns: start search
[main ] INFO 2024/07/17 20:08:52 listening at :7070
[eebus ] TRACE 2024/07/17 20:08:52 registering ski: a9cfa5fac0e5631cb87f09ce726103519eff0fa6
[eebus ] DEBUG 2024/07/17 20:08:52 ski: a9cfa5fac0e5631cb87f09ce726103519eff0fa6 name: Livo-EVB-500-HIDDEN brand: EVBox model: Livo typ: ChargingStation identifier: EVBox-Livo-EVB-500-HIDDEN register: false host: EVB-500-HIDDEN.local. port: 4712 addresses: [192.168.1.219]
[eebus ] DEBUG 2024/07/17 20:08:52 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-HIDDEN.local.
[eebus ] DEBUG 2024/07/17 20:08:52 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-HIDDEN.local.:4712/ship/
[eebus ] DEBUG 2024/07/17 20:08:52 connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp [fe80::ee5c:84ff:fe21:618a]:4712: connect: invalid argument
[eebus ] DEBUG 2024/07/17 20:08:52 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219
[eebus ] DEBUG 2024/07/17 20:08:52 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219:4712/ship/
[eebus ] DEBUG 2024/07/17 20:09:02 connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp 192.168.1.219:4712: i/o timeout
[eebus ] DEBUG 2024/07/17 20:09:02 mdns: announce
[eebus ] DEBUG 2024/07/17 20:09:02 mdns: using zeroconf
[eebus ] DEBUG 2024/07/17 20:09:49 ski: a9cfa5fac0e5631cb87f09ce726103519eff0fa6 name: Livo-EVB-500-HIDDEN brand: EVBox model: Livo typ: ChargingStation identifier: EVBox-Livo-EVB-500-HIDDEN register: false host: EVB-500-HIDDEN.local. port: 4712 addresses: [192.168.1.219]
[eebus ] DEBUG 2024/07/17 20:09:49 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-HIDDEN.local.
[eebus ] DEBUG 2024/07/17 20:09:49 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-HIDDEN.local.:4712/ship/
[eebus ] DEBUG 2024/07/17 20:09:49 connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp [fe80::ee5c:84ff:fe21:618a]:4712: connect: invalid argument
[eebus ] DEBUG 2024/07/17 20:09:49 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219
[eebus ] DEBUG 2024/07/17 20:09:49 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219:4712/ship/
Could you please try, pls deinstall the Addon an then reinstall, make sure before starting EVCC:
- no other EEBus instance or EVCC is Running
- Restart the Wallbox
Just did. I also restart hassio. No effect
Did you re couple the box with your HA EVCC configuration?
yes. It is Definitely a problem on hassio. The wallbox cannot reach evcc . I would like to know who framework logs this:
[eebus ] DEBUG 2024/07/17 08:44:16 incoming connection request from a9cfa5fac0e5631cb87f09ce726103519eff0fa6
As I do not get this message on hassio, only locally.
It needs to be a webstocket right ?
Which installation Method of HA do you use? HAOS on a dedicated device like x86-64, Raspberry or Odroid?
If so, HAOS takes care to receive the trafic and forward it to the Add-on container (EVCC). The message above is only recognised by EVCC in the docker container. HA could not work with EEBus up to now.
Raspberry Pi
Under Settings → System → Network → Network adapter
make sure to enable any additional network interface you need.
I already installed portainer. I'm going to vacations on Friday for 1 week. So I think I will not very active on this.
@thecem I already added a tcpdump from a working installation above.
thx, the working tcpdump is for me only one part, we need a non working from the HA evcc container.
@thecem here is the tcpdump from evcc running in hassio as container. FYI: When I setup the energy manager on my wallbox I can see the energy manager and it accepts the connection. Only then on refresh it says it is not connected. This happen already before we did changes on the port.
I guess energy manager is an part SW from the UI of the Wallbox?
network:
# schema is the HTTP schema
# setting to `https` does not enable https, it only changes the way URLs are generated
schema: http
# host is the hostname or IP address
# if the host name contains a `.local` suffix, the name will be announced on MDNS
# docker: MDNS announcements don't work. host must be set to the docker host's name.
host: homeassistant.local
# port is the listening port for UI and api
# evcc will listen on all available interfaces
port: 7070
Pls post your config.
you don’t use any kind of DNS (DuckDNS) in HA ?
open evcc at http://evcc.local:7070
network:
schema: http
host: homeassistant.local # .local suffix announces the hostname on MDNS
port: 7070
log: debug
levels:
eebus: trace
cache: error
No DuckDNS
Fact:
- no response from evcc to wallbox via mDNS
- mDNS query from wallbox has not the hostname of ha or even of the configured name in EVCC (assumed the config was right and as described above, while tracing)
- tcpdump to mac evcc conection show the right mdns name.
Assumption:
- no answering since the wallbox is asking the wrong name:
49686a9f-evcc.local: type AAAA, class IN, "QM" question
Name: 49686a9f-evcc.local
[Name Length: 19]
[Label Count: 2]
Type: AAAA (28) (IP6 Address)
.000 0000 0000 0001 = Class: IN (0x0001)
0... .... .... .... = "QU" question: False
-> Should be homeassistant.local
2. The DNS/mDNS name given in Wallbox Energy Manager is wrong or the (m)DNS resolution is wrong.
Solution:
Clarify why the name of the Wallbox mDNS query has the wrong name
Try to use IP-Adresses instead of HostNames
Try to use host-names with suffix .local
Try to use 49686a9f-evcc.local as hostname in HA EVCC config
Try to use 49686a9f-evcc as hostname for HA
Try to use homeassistant as hostname in HA EVCC config
What is the resolve of hostname 49686a9f-evcc.local, homeassistant and homeassistant.local in your network?
The EEBUS Stack in evcc tries all possible variants to connect to the wallbox.
This can be seen in the log:
[eebus ] DEBUG 2024/07/17 20:08:52 ski: a9cfa5fac0e5631cb87f09ce726103519eff0fa6 name: Livo-EVB-500-HIDDEN brand: EVBox model: Livo typ: ChargingStation identifier: EVBox-Livo-EVB-500-HIDDEN register: false host: EVB-500-HIDDEN.local. port: 4712 addresses: [192.168.1.219]
[eebus ] DEBUG 2024/07/17 20:08:52 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-HIDDEN.local.
[eebus ] DEBUG 2024/07/17 20:08:52 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at EVB-500-HIDDEN.local.:4712/ship/
[eebus ] DEBUG 2024/07/17 20:08:52 connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp [fe80::ee5c:84ff:fe21:618a]:4712: connect: invalid argument
[eebus ] DEBUG 2024/07/17 20:08:52 trying to connect to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219
[eebus ] DEBUG 2024/07/17 20:08:52 initiating connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 at 192.168.1.219:4712/ship/
[eebus ] DEBUG 2024/07/17 20:09:02 connection to a9cfa5fac0e5631cb87f09ce726103519eff0fa6 failed: dial tcp 192.168.1.219:4712: i/o timeout
But even the connections via the IPv4 address time out.
@DerAndereAndi:
You assume we have to see the messeages out of the log as mDNS packets in the trace? (from EVCC to Wallbox)
The last trace shows only some TCP Packets from .216 to Wallbox.
@jomach: pls tell your tcpdump command parameter
Just used tcpdump -n -w file.pcap
E.g. if the network is not routable, you might not see anything. The code tries to do a connection and gets a timeout after 10s. See the timestamps.
Connections timeouts I also get running it lokal. But then there seems to be a retry and the connection ist establish.
I looked at the code and I cannot find the "log" statement from incoming connection. Is this on another library and not on evcc?
This is all in the eebus packages, this is not part of evcc. You should not need a retry, this rather also hints at a problem of the wallbox.
I would really recommend getting it to run without a container in the first place. Because you are adding to much complexity and possible error scenarios.
Looking at the log (using macOS) in the first post:
- When starting evcc the wallbox does NOT announce itself via mDNS
- After 90s evcc stopps working as no connection could be established
- After another 30s suddenly the mDNS announcement was published by the wallbox
- The eebus stack tried to initiate a connection, and NONE worked
- At the same time the wallbox initiated a connection, and only that worked
- But as evcc stopped its main code, it does not function properly!
Overall: your setup does not run properly outside of a container as well.
Sorry but it does. I see it charging and with different loads. I tested it by turning devices on and off and I see that the car does not receive so many kWh .
So locally it is definitely working. :/
It is not working as it should be. It should not take 2 minutes to get a connection.
It takes 16 seconds
See the macOS log in the first post here: #99 (comment)
How can I prove that this is a eebus issue on the wallbox side ?
This is all in the eebus packages, this is not part of evcc. You should not need a retry, this rather also hints at a problem of the wallbox.
I would really recommend getting it to run without a container in the first place. Because you are adding to much complexity and possible error scenarios.
Looking at the log (using macOS) in the first post:
When starting evcc the wallbox does NOT announce itself via mDNS
After 90s evcc stopps working as no connection could be established
After another 30s suddenly the mDNS announcement was published by the wallbox
The eebus stack tried to initiate a connection, and NONE worked
At the same time the wallbox initiated a connection, and only that worked
But as evcc stopped its main code, it does not function properly!
Overall: your setup does not run properly outside of a container as well.
Can it be that I need to connect the box via ehternet instead of cable ? It does not make much sense....
This is all in the eebus packages, this is not part of evcc. You should not need a retry, this rather also hints at a problem of the wallbox.
I would really recommend getting it to run without a container in the first place. Because you are adding to much complexity and possible error scenarios.
Looking at the log (using macOS) in the first post:
- When starting evcc the wallbox does NOT announce itself via mDNS
- After 90s evcc stopps working as no connection could be established
- After another 30s suddenly the mDNS announcement was published by the wallbox
- The eebus stack tried to initiate a connection, and NONE worked
- At the same time the wallbox initiated a connection, and only that worked
- But as evcc stopped its main code, it does not function properly!
Overall: your setup does not run properly outside of a container as well.
Hallo @DerAndereAndi, so I tried today with the new version with evcc and eebus in trace mode. I think the failure that you observed on the working instance is normal. The explanation for it is that I first started evcc and then I started the binding process over the wallbox app. Today I did the binding and restarted evcc and here are the logs:
[main ] INFO 2024/07/29 13:46:10 evcc 0.129.0
[main ] INFO 2024/07/29 13:46:10 using config file: evcc.yaml
[db ] INFO 2024/07/29 13:46:10 using sqlite database: /Users/jorge/.evcc/evcc.db
[mqtt ] INFO 2024/07/29 13:46:10 connecting evcc-556441454 at tcp://homeassistant.local:1883
[eebus ] INFO 2024/07/29 13:46:10 Local SKI: 9a46bcb42045efb7a5f449a89482621ca87eb4dc
[mqtt ] DEBUG 2024/07/29 13:46:10 tcp://homeassistant.local:1883 connected
[eebus ] DEBUG 2024/07/29 13:46:11 starting websocket server on :4712
[eebus ] DEBUG 2024/07/29 13:46:11 mdns: announce
[eebus ] DEBUG 2024/07/29 13:46:11 mdns: using zeroconf
[eebus ] DEBUG 2024/07/29 13:46:11 mdns: start search
[main ] INFO 2024/07/29 13:46:11 listening at :7070
[eebus ] DEBUG 2024/07/29 13:46:11 incoming connection request from a9cfa5fac0e5631cb87f09ce726103519eff0fa6
[eebus ] DEBUG 2024/07/29 13:46:11 ski a9cfa5fac0e5631cb87f09ce726103519eff0fa6 connected
[eebus ] DEBUG 2024/07/29 13:46:11 Send: read 1 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/29 13:46:11 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:NodeManagement to NodeManagement read 64 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/29 13:46:11 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 reply 2 64 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/29 13:46:12 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:NodeManagement to NodeManagement reply 66 1 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/29 13:46:12 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 call 3 NodeManagementSubscriptionRequestCall
[eebus ] DEBUG 2024/07/29 13:46:12 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 read 4 NodeManagementUseCaseData
[eebus ] DEBUG 2024/07/29 13:46:12 cs-lpc: 0 DeviceDiagnosis Server found
[eebus ] DEBUG 2024/07/29 13:46:12 cs-lpp: 0 DeviceDiagnosis Server found
[eebus ] DEBUG 2024/07/29 13:46:12 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 read 5 DeviceClassificationManufacturerData
[eebus ] DEBUG 2024/07/29 13:46:12 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 read 6 DeviceDiagnosisStateData
[eebus ] DEBUG 2024/07/29 13:46:12 ski a9cfa5fac0e5631cb87f09ce726103519eff0fa6 event cem-evsecc-EvseConnected
[eebus ] DEBUG 2024/07/29 13:46:12 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:NodeManagement to NodeManagement call 68 NodeManagementSubscriptionRequestCall
[eebus ] DEBUG 2024/07/29 13:46:12 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 result 7 68 ResultData 0
[eebus ] DEBUG 2024/07/29 13:46:12 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:NodeManagement to NodeManagement result 70 3 ResultData 0
[eebus ] DEBUG 2024/07/29 13:46:12 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:NodeManagement to NodeManagement reply 72 4 NodeManagementUseCaseData
[eebus ] DEBUG 2024/07/29 13:46:12 ski a9cfa5fac0e5631cb87f09ce726103519eff0fa6 event cem-evsecc-UseCaseSupportUpdate
[eebus ] DEBUG 2024/07/29 13:46:12 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:NodeManagement to NodeManagement read 76 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/29 13:46:12 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 reply 8 76 NodeManagementDetailedDiscoveryData
[eebus ] DEBUG 2024/07/29 13:46:12 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:NodeManagement to NodeManagement read 78 NodeManagementDestinationListData
[eebus ] DEBUG 2024/07/29 13:46:12 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 reply 9 78 NodeManagementDestinationListData
[eebus ] DEBUG 2024/07/29 13:46:13 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:NodeManagement to NodeManagement read 80 NodeManagementUseCaseData
[eebus ] DEBUG 2024/07/29 13:46:13 Send: d:_i:47859_EVBox-Livo-EVB-500-015-503 reply 10 80 NodeManagementUseCaseData
[eebus ] DEBUG 2024/07/29 13:46:13 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:DeviceClassification to DeviceClassification reply 82 5 DeviceClassificationManufacturerData
[eebus ] DEBUG 2024/07/29 13:46:13 ski a9cfa5fac0e5631cb87f09ce726103519eff0fa6 event cem-evsecc-DataUpdateManufacturerData
[eebus ] DEBUG 2024/07/29 13:46:13 Recv: d:_i:47859_EVBox-Livo-EVB-500-015-503:DeviceDiagnosis to DeviceDiagnosis reply 84 6 DeviceDiagnosisStateData
[eebus ] DEBUG 2024/07/29 13:46:13 ski a9cfa5fac0e5631cb87f09ce726103519eff0fa6 event cem-evsecc-DataUpdateOperatingState
[site ] INFO 2024/07/29 13:46:13 site config:
[site ] INFO 2024/07/29 13:46:13 meters: grid ✓ pv ✓ battery ✗
[site ] INFO 2024/07/29 13:46:13 grid: power ✓ energy ✓ currents ✓
[site ] INFO 2024/07/29 13:46:13 pv 1: power ✓ energy ✓ currents ✓
[site ] INFO 2024/07/29 13:46:13 vehicles:
[site ] INFO 2024/07/29 13:46:13 vehicle 1: range ✓ finish ✓ status ✓ climate ✗ wakeup ✓
[lp-1 ] INFO 2024/07/29 13:46:13 loadpoint 1:
[lp-1 ] INFO 2024/07/29 13:46:13 mode: pv
[lp-1 ] INFO 2024/07/29 13:46:13 charger: power ✓ energy ✗ currents ✓ phases ✗ wakeup ✗
[lp-1 ] INFO 2024/07/29 13:46:13 meters: charge ✓
[lp-1 ] INFO 2024/07/29 13:46:13 charge: power ✓ energy ✗ currents ✓
[lp-1 ] DEBUG 2024/07/29 13:46:13 !! active phases: 3p = min(0p measured 0p vehicle 3p physical 0p charger)
[lp-1 ] DEBUG 2024/07/29 13:46:13 phase timer inactive
[lp-1 ] DEBUG 2024/07/29 13:46:13 pv timer inactive
[lp-1 ] INFO 2024/07/29 13:46:13 vehicle updated: unknown -> MG
[lp-1 ] DEBUG 2024/07/29 13:46:13 set charge mode: pv
[lp-1 ] DEBUG 2024/07/29 13:46:13 !! active phases: 3p = min(0p measured 3p vehicle 3p physical 0p charger)
[site ] DEBUG 2024/07/29 13:46:13 ----
[lp-1 ] DEBUG 2024/07/29 13:46:13 charge power: 0W
[lp-1 ] DEBUG 2024/07/29 13:46:13 charge currents: [0 0 0]A
[site ] DEBUG 2024/07/29 13:46:13 pv power: 8254W
[site ] DEBUG 2024/07/29 13:46:13 grid meter: -8404W
[site ] DEBUG 2024/07/29 13:46:13 grid powers: [-3084 -2688 -2633]W
[site ] DEBUG 2024/07/29 13:46:13 grid currents: [-13.1 -11.3 -10.9]A
[site ] DEBUG 2024/07/29 13:46:13 site power: -8404W
[eebus ] DEBUG 2024/07/29 13:46:15 ski: a9cfa5fac0e5631cb87f09ce726103519eff0fa6 name: Livo-EVB-500-015-503 brand: EVBox model: Livo typ: ChargingStation identifier: EVBox-Livo-EVB-500-015-503 register: false host: EVB-500-015-503.local. port: 4712 addresses: [192.168.1.219]
[site ] DEBUG 2024/07/29 13:46:43 ----
Seems to me everything fine locally. Can it be that on hassio we have a issue with ipv6 ?
After hours of debugging I found the issue. The MDNS was exposing 5 hosts for the same container.
You need to add the following config so that it only advertises one IP
eebus:
URI: 192.168.1.216:4712
interfaces:
- end0
I will add the charger to the docs
Maybe better enrich the documentation for https://docs.evcc.io/docs/reference/configuration/eebus#interfaces
@goebelmeier habe es verbessert mit was ich könnte. Freue mich drauf