evcc-io / evcc

Sonne tanken ☀️🚘
https://evcc.io
MIT License
3.61k stars 669 forks source link

Issue using Hardy Barth eCB1 Wallbox #16041

Closed Christoph-87 closed 2 months ago

Christoph-87 commented 2 months ago

Describe the bug

I try to connect EVCC with two Hardy Barth eCB1 Wallboxes via the template.

chargers:
  - name: carport
    type: template
    template: hardybarth-ecb1
    host: 192.168.2.8 # IP-Adresse oder Hostname 
  - name: garage
    type: template
    template: hardybarth-ecb1
    host: 192.168.2.9 # IP-Adresse oder Hostname 

loadpoints:
  - title: Carport
    charger: carport
    mode: pv # Standardmodus zum Laden
    vehicle: kona
  - title: Garage
    charger: garage
    mode: pv # Standardmodus zum Laden

Unfortunately while loading EVCC, I receive the following error:

[main ] INFO 2024/09/11 17:15:22 evcc 0.130.8 [main ] INFO 2024/09/11 17:15:22 using config file: /etc/evcc.yaml [db ] INFO 2024/09/11 17:15:22 using sqlite database: /root/.evcc/evcc.db [mqtt ] INFO 2024/09/11 17:15:22 connecting smart at tcp://192.168.2.2:1883 [mqtt ] DEBUG 2024/09/11 17:15:22 tcp://192.168.2.2:1883 connected [main ] INFO 2024/09/11 17:15:22 listening at :7070 [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) [main ] FATAL 2024/09/11 17:15:35 will attempt restart in: 15m0s

Later I also received:

[main ] INFO 2024/09/11 19:34:51 evcc 0.130.8 [main ] INFO 2024/09/11 19:34:51 using config file: /etc/evcc.yaml [db ] INFO 2024/09/11 19:34:51 using sqlite database: /root/.evcc/evcc.db [mqtt ] INFO 2024/09/11 19:34:51 connecting smart at tcp://192.168.2.2:1883 [mqtt ] DEBUG 2024/09/11 19:34:51 tcp://192.168.2.2:1883 connected [main ] INFO 2024/09/11 19:34:51 listening at :7070 [main ] FATAL 2024/09/11 19:35:03 cannot create charger 'garage': cannot create charger type 'template': cannot create charger type 'hardybarth-ecb1': invalid status: 404 Not Found [main ] FATAL 2024/09/11 19:35:03 will attempt restart in: 15m0s

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"

networks:
    net:
        driver: bridge
        name: docker_net

    evcc:
        depends_on: 
            - traefik
        command:
            - evcc
        container_name: evcc
        image: evcc/evcc:latest
        networks:
            - net
        #network_mode: "host"
        expose:
            - 7070
        #ports:
            # - 7070:7070
            # - 8887:8887/tcp # OCPP charger
            # - 7090:7090/udp KEBA charger# 
            #- 9522:9522/udp # SMA Energy Manager
        volumes:
            - /volume1/docker/evcc/evcc.yaml:/etc/evcc.yaml
            - /volume1/docker/evcc/.evcc:/root/.evcc
        restart: always
        extra_hosts:
            - "xxxxxxx.synology.me:192.168.2.2" #
        labels:
            - "traefik.enable=true"
            - "traefik.compose=nas"
            - "traefik.http.routers.evcc.rule=Host(`xxxxxxx.synology.me`)"
            - "traefik.http.routers.evcc.entrypoints=evcc"
            - "traefik.http.routers.evcc.tls=true"
            - "traefik.http.routers.evcc.middlewares=compress@file"
            - "traefik.http.services.evcc.loadbalancer.server.port=7070" 

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

network:
  schema: http
  host: xxxxxxx.synology.me  # .local suffix announces the hostname on MDNS
  port: 7070

interval: 15s
log: debug

# unique installation id
plant: xxxxxxxx

sponsortoken: xxxxxxxxx  

telemetry: false  

meters:
  - name: my_pv
    type: template
    template: sma-inverter-speedwire
    usage: pv
    host: 192.168.2.81 # IP-Adresse oder Hostname
    password: xxxxxxxxxx
  - name: my_bat
    type: template
    template: sma-si-modbus
    usage: battery
    # Modbus TCP
    modbus: tcpip
    id: 3
    host: 192.168.2.82 # Hostname
    port: 502 # Port    
    capacity: 7.7
#  - name: grid
#    type: template
#    template: sma-home-manager
#    usage: grid
#    host: 192.168.2.72 # IP-Adresse oder Hostname
  - name: grid
    type: template
    template: tibber-pulse
    usage: grid
    token: "xxxxxxx" # access token
    homeid: "xxxxxxxx" # optional if multiple homes associated to account

chargers:
  - name: carport
    type: template
    template: hardybarth-ecb1
    host: 192.168.2.8 # IP-Adresse oder Hostname 
  - name: garage
    type: template
    template: hardybarth-ecb1
    host: 192.168.2.9 # IP-Adresse oder Hostname 

loadpoints:
  - title: Carport
    charger: carport
    mode: pv # Standardmodus zum Laden
    vehicle: kona
  - title: Garage
    charger: garage
    mode: pv # Standardmodus zum Laden

tariffs:
  currency: EUR # (default EUR)
  grid:
    # static grid price
    type: tibber
    token: "xxxxxxxx" # access token
    homeid: "xxxxxxxx" # optional if multiple homes associated to account

  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.0848 # [currency]/kWh

mqtt:
  broker: 192.168.2.2:1883
  topic: evcc
  clientid: smart
  user: smart
  password: xxxxxxxx

site:
  title: SoSi20
  meters:
    grid: grid
    pv: 
      - my_pv
    battery:
      - my_bat
  residualPower: 100 # Netzbezug im PV Modus nicht erlaubt
  #smartCostLimit: 0.17

vehicles:
  - type: template
    template: offline
    title: Hyundai Kona
    name: kona
    capacity: 64 # kWh 

hems:
  type: sma
  allowcontrol: false # set true to allow SHM controlling charger in PV modes  

# push messages
messaging:
  events:
    start:
      title: Ladevorgang gestartet
      msg: Ladevorgang wurde mit Modus "${mode}" gestartet
    stop:
      title: Ladevorgang beendet
      msg: ${chargedEnergy:%.1fk}kWh in ${chargeDuration} geladen
    connect:
      title: Fahrzeug verbunden
      msg: Ladepunkt ${loadpoint}
    disconnect:
      title: Fahrzeug getrennt
      msg: Ladepunkt ${loadpoint} nach ${connectedDuration} getrennt
  services:
    - type: telegram
      token: "xxxxxxx" 
      chats:
        - xxxxxx

Log details

[main  ] INFO 2024/09/11 19:44:59 evcc 0.130.8
[main  ] INFO 2024/09/11 19:44:59 using config file: /etc/evcc.yaml
[db    ] INFO 2024/09/11 19:44:59 using sqlite database: /root/.evcc/evcc.db
[db    ] TRACE 2024/09/11 19:44:59 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="settings" -1 <nil>
[db    ] TRACE 2024/09/11 19:44:59 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 <nil>
[db    ] TRACE 2024/09/11 19:44:59 SELECT * FROM `settings` LIMIT 1 -1 <nil>
[db    ] TRACE 2024/09/11 19:44:59 SELECT * FROM `settings` 30 <nil>
[mqtt  ] INFO 2024/09/11 19:44:59 connecting smart at tcp://192.168.2.2:1883
[mqtt  ] DEBUG 2024/09/11 19:44:59 tcp://192.168.2.2:1883 connected
[db    ] TRACE 2024/09/11 19:44:59 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="devices" -1 <nil>
[db    ] TRACE 2024/09/11 19:44:59 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="device_details" -1 <nil>
[db    ] TRACE 2024/09/11 19:44:59 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="configs" -1 <nil>
[db    ] TRACE 2024/09/11 19:44:59 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 <nil>
[db    ] TRACE 2024/09/11 19:44:59 SELECT * FROM `configs` LIMIT 1 -1 <nil>
[db    ] TRACE 2024/09/11 19:44:59 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="config_details" -1 <nil>
[db    ] TRACE 2024/09/11 19:44:59 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="config_details" -1 <nil>
[main  ] INFO 2024/09/11 19:44:59 listening at :7070
[db    ] TRACE 2024/09/11 19:44:59 SELECT * FROM `configs` WHERE `configs`.`class` = 2 0 <nil>
[pulse ] TRACE 2024/09/11 19:44:59 POST https://api.tibber.com/v1-beta/gql
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 new inverter at 192.168.2.81 - Serial=3008692813
[sma   ] TRACE 2024/09/11 19:44:59 login for 192.168.2.81:9522
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 new inverter at 192.168.2.81 - Serial=3008692813
[sma   ] TRACE 2024/09/11 19:44:59 found device 3008692813 at 192.168.2.81
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5100 0x263F00 0x263FFF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5100 0x295A00 0x295AFF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5100 0x411E00 0x4120FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[pulse ] TRACE 2024/09/11 19:44:59 {"query":"{viewer{websocketSubscriptionUrl}}"}
--
data={"viewer":{"websocketSubscriptionUrl":"wss://websocket-api.tibber.com/v1-beta/gql/subscriptions"}}
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5100 0x464000 0x4642FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5100 0x464800 0x4655FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5100 0x465700 0x4657FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5100 0x491E00 0x495DFF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5180 0x214800 0x2148FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[pulse ] TRACE 2024/09/11 19:44:59 {"type":"connection_init","payload":{"token":"***"}} client
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5180 0x416400 0x4164FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5200 0x237700 0x2377FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[pulse ] TRACE 2024/09/11 19:44:59 {"type":"connection_ack"} server
[pulse ] TRACE 2024/09/11 19:44:59 {"id":"3f6ea68f-0bb9-45f4-bb07-c350f95e90ea","type":"subscribe","payload":{"query":"subscription ($homeId:ID!){liveMeasurement(homeId: $homeId){power,powerProduction,lastMeterConsumption,lastMeterProduction,currentL1,currentL2,currentL3}}","variables":{"homeId":"***"}}} client
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5380 0x251E00 0x251EFF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5380 0x451F00 0x4521FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5400 0x260100 0x2622FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5400 0x462E00 0x462FFF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 send discover package
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5400 0x496700 0x4988FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 requestValues for 192.168.2.81:9522: 0x5800 0x821E00 0x8220FF
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:44:59 logout for 192.168.2.81:9522
[sma   ] TRACE 2024/09/11 19:44:59 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[pulse ] TRACE 2024/09/11 19:44:59 {"id":"3f6ea68f-0bb9-45f4-bb07-c350f95e90ea","type":"next","payload":{"data":{"liveMeasurement":{"power":511,"powerProduction":0,"lastMeterConsumption":14353.7821,"lastMeterProduction":6338.605,"currentL1":null,"currentL2":null,"currentL3":null}}}} server
[db    ] TRACE 2024/09/11 19:44:59 SELECT * FROM `configs` WHERE `configs`.`class` = 1 0 <nil>
[ecb1  ] TRACE 2024/09/11 19:44:59 POST http://192.168.2.8/api/v1/chargecontrols/1/mode
[ecb1  ] TRACE 2024/09/11 19:44:59 POST http://192.168.2.9/api/v1/chargecontrols/1/mode
[ecb1  ] TRACE 2024/09/11 19:45:00 mode=manual
--
protocol-version=1.4 protocol-version=1.4 errors={"id":1,"message":"EV-ChargingController Not Found"}
[sma   ] TRACE 2024/09/11 19:45:00 send discover package
[sma   ] TRACE 2024/09/11 19:45:00 send discover package
[sma   ] TRACE 2024/09/11 19:45:01 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:45:01 send discover package
[sma   ] TRACE 2024/09/11 19:45:01 send discover package
[sma   ] TRACE 2024/09/11 19:45:02 send discover package
[sma   ] TRACE 2024/09/11 19:45:04 login for 192.168.2.81:9522
[sma   ] TRACE 2024/09/11 19:45:04 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:45:04 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:45:04 requestValues for 192.168.2.81:9522: 0x5100 0x263F00 0x263FFF
[sma   ] TRACE 2024/09/11 19:45:04 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:45:05 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:45:05 requestValues for 192.168.2.81:9522: 0x5100 0x295A00 0x295AFF
[sma   ] TRACE 2024/09/11 19:45:05 send 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma   ] TRACE 2024/09/11 19:45:05 recv 192.168.2.81: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]

What type of operating system are you running?

Linux

Nightly build

Version

/app # evcc -v evcc version 0.130.8

andig commented 2 months ago

Sorry, no docker support...

mdkeil commented 2 months ago

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?

andig commented 2 months ago

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 👍🏻

Christoph-87 commented 2 months ago

Vielen Dank für die Rückmeldung.

Beide Wallboxen stehen auf "Manuell".

Bildschirmfoto 2024-09-13 um 10 21 24 Bildschirmfoto 2024-09-13 um 10 21 39

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?

Christoph-87 commented 2 months ago

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.

Bildschirmfoto 2024-09-13 um 10 38 45

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?

mdkeil commented 2 months ago

Gibt es denn eine Möglichkeit herauszufinden, welche URL aufgerufen wird?

https://github.com/evcc-io/evcc/blob/ef6ad884c6b723ff7f16cf77c465dec065d3421b/charger/hardybarth-ecb1.go#L79C2-L79C48

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?

Christoph-87 commented 2 months ago

Eventuell ist das das Problem?

Bildschirmfoto 2024-09-13 um 10 57 51
mdkeil commented 2 months ago

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?

mdkeil commented 2 months ago

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
Christoph-87 commented 2 months ago

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"}

mdkeil commented 2 months ago

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.

Christoph-87 commented 2 months ago

Da erhalte ich leider die gleiche Fehlermeldung:

image
mdkeil commented 2 months ago

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?

Screenshot 2024-09-13 130140

Christoph-87 commented 2 months ago

Aktuell ist das hier die Einstellung? Das muss wie im Screenshot umgestellt werden?

image
mdkeil commented 2 months ago

ja, das wäre mein Ansatzpunkt.. welche Auswahl steht denn sonst noch zur Verfügung?

Christoph-87 commented 2 months ago

Meine Auswahl ist:

image
mdkeil commented 2 months ago

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.

Christoph-87 commented 2 months ago

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)

mdkeil commented 2 months ago

ich denke Phoenix-RTU mit ID 1 wird vermutlich korrekt sein. Das Folgeproblem hängt ggfs. wirklich mit dem Repeater zusammen.

Christoph-87 commented 2 months ago

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?

mdkeil commented 2 months ago

hmm.. beide Wallboxen gleich konfiguriert..? also mit Phoenix-RTU und ID 1?

Christoph-87 commented 2 months ago

ja, beide mit Phoenix-RTU und ID 1. Ich habe eine der Wallboxen aufgeschraubt und bei Bus leuchtet es auch grün.

IMG_8853

mdkeil commented 2 months ago

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?

Christoph-87 commented 2 months ago

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.

Christoph-87 commented 1 month ago

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.