Koexistenz HA und evcc

Configuration
1

Hallo in die Runde, (english below)

ich suche nach der besten Möglichkeit, beide Systeme zu nutzen. Das Problem stellt mein Wechselrichter dar, den möchte ich per Modbus TCP auslesen, aber es geht halt nur ein Client und ich bräuchte für beide eine Verbindung. Ich habe EVCC am laufen, das funktioniert auch soweit, wenn EVCC die alleinige Verbindung zum Wechslerichter hat. Das ggleiche betrifft HA. Ich habe dort ein schönes Dashboard eingerichtet, dass mir alles Wissenswerte anzeigt. Prinzipiell habe ich ein ziemlich großes Zwave Netzwerk, welches durch Homey gesteuert wird. Zu HA übergebe ich alle Devcies per MQTT. Nun wollte ich MQTT auch für EVCC einrichten. Ich wollte HA weiterhin die Daten auslesen lassen vom Wechselrichter und diese per MQTT übergeben lassen zu EVCC.

Mein Problem ist nun, dass ich nicht weiß, wie ich HA dazu bewegen kann, das Gerät Wechselrichter per MQTT für EVCC bereitzustellen. Ich finde per MQTT Explorer keinen Topic, den ich EVCC übergeben kann. Auch sehe ich in HA die Topics zwar vom Homey, aber nicht von EVCC, aber das ist noch ein anderes Problem.

Hat das jemand schonmal so gebaut oder besser andersrum (Wechselrichter an EVCC und per MQTT an HA übergeben)?

Hello everyone,

I’m looking for the best way to use both systems. The problem is my inverter, which I would like to read out via Modbus TCP, but only one client works and I need a connection for both. I have EVCC running, it also works if EVCC has the sole connection to the inverter. The same applies to HA. I set up a nice dashboard there that shows me everything I need to know. In principle, I have a fairly large Zwave network, which is controlled by Homey. I transfer all devcies to HA via MQTT. Now I wanted to set up MQTT for EVCC as well. I still wanted HA to read the data from the inverter and transfer it to EVCC via MQTT.

My problem now is that I don’t know how to get HA to provide the device inverter via MQTT for EVCC. I can’t find a topic via MQTT Explorer that I can transfer to EVCC. Also in HA I see the topics from Homey, but not from EVCC, but that’s another problem.

Has anyone ever built it like this or, better yet, the other way round (hand over the inverter to EVCC and to HA via MQTT)?

1 Like
2

Moin,

schau dir mal EVCC integration via MQTT (sensor entity config) an.

Beste Grüße
Wolfgang

3

Ich hab das über einen ModBus Proxy gelöst. Der läuft als AddOn bei Home Assistant und fragt alle paar Sekunden die Daten per ModBus beim Wechselrichter ab. HA und EVCC connecten dann beide auf den ModBus Proxy. Funktioniert prima und ist echt simpel einzurichten.

2 Likes
4

Vielen Dank ihr beide,

ich habe zuerst die Lösung über MQTT realisiert und habe die Wechselrichter per Modbus an evcc gebunden und dann mittels MQTT die Werte und auch die Steuerung an HA übergeben. Dadurch brauche ich meiner Frau auch nicht Erklären, wie evcc funktioniert, sondern Sie kann mittels eigenem Dashboard die Ladeleistung ihrer Wallbox selbst einstellen.

Die Möglichkeit mit dem ModBus Proxy will ich allerdings auch probieren, denn die Infos aus den Wechselrichtern waren mehr / besser, als das was ich von evcc bekomme. Danke für die Idee :slight_smile:

5

Hallo Zusammen,
wie bekommen ich die Daten von HA über MQTT in EVCC.
Eine Anleitung wäre nicht schlecht.

Also ich habe einen Wechselrichter der nur in HA ist und möchte diese Daten in den MQTT Broker senden.

Piggy

6

Vor der selben Aufgabe stehe ich auch gerade, ich habe 2 Inverter mit Batterie und Power Meter mit der Huawei Solar Integration von @wlcrs :+1: GitHub - wlcrs/huawei_solar: Home Assistant integration for Huawei Solar inverters via Modbus erfolgreich in HA eingebunden, nun würde ich gerne das ganze noch am besten per MQTT in EVCC bringen.

Falls da jemand schon so etwas hat, wäre das sehr hilfreich :wink:

7

Putting a Modbus Proxy (for example GitHub - Akulatraxas/ha-modbusproxy: Hassio Addon packaging modus-proxy) between the inverter and HA/EVCC should be sufficient to allow both to communicate with the inverter.

I would invite you to document the process on the Wiki of my project for future reference. Thanks in advance!

1 Like
8

Thanks for hint @wlcrs, I’m already running evcc and huawei_solar together with the GitHub - Akulatraxas/ha-modbusproxy: Hassio Addon packaging modus-proxy Addon, but I sometimes recieve timeout messages when both devices try to access the modbus of the S-Dongle via the modbus-proxy at the same time.
Therefore I had considered the alternative with MQTT, but unfortunately it is not so easy to get the right values for evcc and with the mqtt.publish service I do not really get along. Have you ever considered to include a mqtt publish function in your addon ? I could well imagine more useful scenarios for it :innocent:

9

No, that is completely out of scope for a HA integration.

10

Ich habe es nun wie folgt gemacht:

Eine Automation angelegt die alle 5 Sek. die benötigten Werte über den mqtt.publish service veröffentlicht:

alias: PV_Prod to EVCC via MQTT
description: ""
trigger:
  - platform: time_pattern
    seconds: /5
condition: []
action:
  - service: mqtt.publish
    data:
      topic: pvdataevcc/sensor/power_meter_active_power_1
      payload_template: " {{ states('sensor.power_meter_active_power_1') }} "
  - service: mqtt.publish
    data:
      topic: pvdataevcc/sensor/power_meter_consumption_1
      payload_template: " {{ states('sensor.power_meter_consumption_1') }} "
  - service: mqtt.publish
    data:
      topic: pvdataevcc/sensor/inverter_input_power_with_efficiency_loss
      payload_template: " {{ states('sensor.inverter_input_power_with_efficiency_loss') }} "
  - service: mqtt.publish
    data:
      topic: pvdataevcc/sensor/battery_charge_discharge_power_1
      payload_template: " {{ states('sensor.battery_charge_discharge_power_1') }} "
  - service: mqtt.publish
    data:
      topic: pvdataevcc/sensor/battery_state_of_capacity_1
      payload_template: " {{ states('sensor.battery_state_of_capacity_1') }} "
mode: single

Die Huawei Integration läuft bei mir mit einem Updateintervall von 15 Sekunden. Ich habe dazu die Datei /config/custom_components/huawei_solar/const.py angepasst und den UPDATE_INTERVAL von 30 auf 15 geändert

UPDATE_INTERVAL = timedelta(seconds=15)
# optimizer data is only refreshed every 5 minutes by the inverter.
OPTIMIZER_UPDATE_INTERVAL = timedelta(minutes=5)

Im EVCC dann auch mit Regelintervall von 15 Sekunden. Meine EVCC.yaml sieht wie folgt aus:

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

interval: 15s # control cycle interval
sponsortoken: # your token from sponsor.evcc.io

# database configuration for persisting charge sessions and settings
# database:
#   type: sqlite
#   dsn: <path-to-db-file>

# sponsor token enables optional features (request at https://sponsor.evcc.io)
# sponsortoken:

# telemetry enables aggregated statistics
#
# Telemetry allows collecting usage data (grid and green energy, charge power).
# Data is aggregated, no individual charging sessions are tracked. The collected,
# anonymous data can be retrieved using https://api.evcc.io.
#
# See https://github.com/evcc-io/evcc/pull/4343 or details.
#
# For time being, this is only available to sponsors, hence data is associated with
# the sponsor token's identity.
#
# telemetry: true

# log settings
log: info
levels:
  site: debug
  lp-1: debug
  lp-2: debug
  mqtt: debug
  cache: error
  db: error

# modbus proxy for allowing external programs to reuse the evcc modbus connection
# each entry will start a proxy instance at the given port speaking Modbus TCP and
# relaying to the given modbus downstream device (either TCP or RTU, RS485 or TCP)
modbusproxy:
  #  - port: 5200
  #    uri: solar-edge:502
  #    # rtu: true
  #    # readonly: true

# meter definitions
# name can be freely chosen and is used as reference when assigning meters to site and loadpoints
# for documentation see https://docs.evcc.io/docs/devices/meters
meters:
  - name: grid
    type: custom
    power:
      source: mqtt
      broker: 192.168.xxx.xxx:1883
      topic: pvdataevcc/sensor/power_meter_active_power_1
      user: xxx
      password: xxx
      scale: 1
      timeout: 30s
    energy:
      source: mqtt
      broker: 192.168.xxx.xxx:1883
      topic: pvdataevcc/sensor/power_meter_consumption_1
      user: xxx
      password: xxx
      scale: 1
      timeout: 30s
  - name: pv
    type: custom
    power:
      source: mqtt
      broker: 192.168.xxx.xxx:1883
      topic: pvdataevcc/sensor/inverter_input_power_with_efficiency_loss
      user: xxx
      password: xxx
      scale: 1
      timeout: 30s
    energy:
      source: mqtt
      broker: 192.168.xxx.xxx:1883
      topic: pvdataevcc/sensor/power_meter_consumption_1
      user: xxx
      password: xxx
      scale: 1
      timeout: 30s
  - name: battery
    type: custom
    power:
      source: mqtt
      broker: 192.168.xxx.xxx:1883
      topic: pvdataevcc/sensor/battery_charge_discharge_power_1
      user: xxx
      password: xxx
      timeout: 30s
      scale: -1
    soc:
      source: mqtt
      broker: 192.168.xxx.xxx:1883
      topic: pvdataevcc/sensor/battery_state_of_capacity_1
      user: xxx
      password: xxx
      timeout: 30s

# charger definitions
# name can be freely chosen and is used as reference when assigning charger to vehicle
# for documentation see https://docs.evcc.io/docs/devices/chargers
chargers:
  - name: go-eCharger Gemini
    type: template
    template: go-e-v3
    host: 192.168.xxx.xxx # IP-Adresse oder Hostname

# vehicle definitions
# name can be freely chosen and is used as reference when assigning vehicle to loadpoint
# for documentation see https://docs.evcc.io/docs/devices/vehicles
vehicles:
  - name: Tesla Model Y
    type: template
    template: tesla
    title: xxx
    accessToken: 
    refreshToken: 
    vin: LRWXXXXXXXXXXXXX # Erforderlich, wenn mehrere Fahrzeuge des Herstellers vorhanden sind # Optional
    capacity: 75 # Akkukapazität in kWh # Optional

# site describes the EVU connection, PV and home battery
site:
  title: Home
  meters:
    grid: grid
    pvs:
      - pv
    batteries:
      - battery
  bufferSoC: 90 # ignore home battery discharge above soc (empty to disable)
  prioritySoC: 80 # give home battery priority up to this soc (empty to disable)
  residualPower: 100 # additional household usage margin
  #    aux:
  #     - aux # list of auxiliary meters for adjusting grid operating point
  maxGridSupplyWhileBatteryCharging: # ignore battery charging if AC consumption is above this value
  smartCostLimit: # set cost limit for automatic charging in PV mode

# loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
  - title: Carport
    charger: go-eCharger Gemini
    mode: pv
    vehicles:
      - Tesla Model Y
    phases: 0
    mincurrent: 6
    maxcurrent: 16
    resetOnDisconnect: false
    soc:
      estimate: true
    enable: # pv mode enable behavior
      delay: 1m # threshold must be exceeded for this long
      threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
    disable: # pv mode disable behavior
      delay: 3m # threshold must be exceeded for this long
      threshold: 0 # maximum import power (W)
    guardDuration: 5m # switch charger contactor not more often than this (default 5m)

# tariffs are the fixed or variable tariffs
tariffs:
  currency: EUR # three letter ISO-4217 currency code (default EUR)
  grid:
    # either static grid price (or price zones)
    type: fixed
    price: 0.2529 # EUR/kWh
  #    zones:
  #      - days: Mo-Fr
  #        hours: 2-5
  #        price: 0.2 # EUR/kWh
  #      - days: Sa,So
  #        price: 0.15 # EUR/kWh

  # # or variable via tibber
  # type: tibber
  # token: "476c477d8a039529478ebd690d35ddd80e3308ffc49b59c65b142321aee963a4" # access token
  # homeid: "cc83e83e-8cbf-4595-9bf7-c3cf192f7d9c" # optional if multiple homes associated to account

  # # or variable via awattar
  # type: awattar
  # region: de # optional, choose at for Austria
  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.0762 # EUR/kWh
  planner:
    # planner tariff can be used for target charging if not grid tariff is specified
    # GrünStromIndex (Germany only) or ElectricityMaps provide CO2 intensity forecast

    # type: grünstromindex
    # zip: <zip>

    # type: electricitymaps
    # uri: <uri>
    # token: <token>
    # zone: DE

# mqtt message broker
#mqtt:
#  broker: 192.168.xxx.xxx:1883
#  topic: xxx # root topic for publishing, set empty to disable
#  user: xxx
#  password: xxx

# influx database
influx:
  # url: http://localhost:8086
  # database: evcc
  # user:
  # password:

# eebus credentials
eebus:
  # uri: # :4712
  # interfaces: # limit eebus to specific network interfaces
  # - en0
  # certificate: # local signed certificate, required, can be generated via `evcc eebus-cert`
  #   public: # public key
  #   private: # private key

# push messages
messaging:
  events:
    start: # charge start event
      title: Charge started
      msg: Started charging in "${mode}" mode
    stop: # charge stop event
      title: Charge finished
      msg: Finished charging ${chargedEnergy:%.1fk}kWh in ${chargeDuration}.
    connect: # vehicle connect event
      title: Car connected
      msg: "Car connected at ${pvPower:%.1fk}kW PV"
    disconnect: # vehicle connected event
      title: Car disconnected
      msg: Car disconnected after ${connectedDuration}
    soc: # vehicle soc update event
      title: Soc updated
      msg: Battery charged to ${vehicleSoc:%.0f}%
    guest: # vehicle could not be identified
      title: Unknown vehicle
      msg: Unknown vehicle, guest connected?
  services:
    # - type: pushover
    #   app: # app id
    #   recipients:
    #   - # list of recipient ids
    #- type: telegram
    #  token: XXXXXXXXXXXXXXXX # bot id
    #  chats:
    #    - XXXXXXXXXXXX # list of chat ids
  #- type: email
  #  uri: smtp://<user>:<password>@<host>:<port>/?fromAddress=<from>&toAddresses=<to>
  # - type: ntfy
  #   uri: https://<host>/<topics>
  #   priority: <priority>
  #   tags: <tags>

Hoffe das hilft !

3 Likes
11

@a13xde

Anstatt den MQTT Server jedes mal zu wiederholen kannst du auch an einer Stelle

mqtt:
    broker: 192.168.1.1:1883
    user: xxx
    password: xxx

einfügen und dann reicht es

meters:
  - name: grid
    type: custom
    power:
      source: mqtt
      topic: pvdataevcc/sensor/power_meter_active_power_1
      scale: 1
      timeout: 30s

zu benutzen

2 Likes
12

Danke, aber das hatte ich tatsächlich zu erst versucht, leider immer mit dem Ergebnis das EVCC die Werte publisht, aber nicht vom mqtt broker bezogen hat :man_shrugging:

13

Großartig DANKE

14

Hallo
Das liest sich wirklich ganz einfach.
Aber wie schaffe ich es, das meine bisherige direkte Verbindung zum Sungrow ersetzt wird: “HA und EVCC connecten dann beide auf den ModBus Proxy.”
Aktuell wird auf die IP des Sungrow verwiesen.
Danke
Jürgen

15

Inzwischen habe ich an anderer Stelle gelesen, das als upstreamhost die IP des Wechselrichters eingetragen werden muss. Dennoch bekomme ich im Protokoll kein positives Ergebnis, aber es wird auch kein Fehler ausgegeben.

16

hey
ich hoffe, du liest noch mit.
Ich benötige genau diese Lösung. Doch bekomme ich den ModbusProxy nicht dazu, sich mit dem WR zu verbinden. (Ich habe noch eine 2. Modbus-Verbindunf tzr WP) Leider haben die verschiedenen Foren und Versuche nicht geholfen.
Wie bist du genau vorgegangen, um diese Verbindug zu bekommen? Was has dz wie und wann für wie lange runtergefahren?
Danke
Jürgen

17

Hey,

das war bei mir relativ simpel.
Wenn du sagst, dass du noch eine 2. ModBus Verbindung zur WP hast - dann hier gleich die Frage: die WP greift auf den WR per ModBus zu? Falls dem so ist, dann musst du das abstellen. Denn die meisten Wechselrichter lassen nur nur ein Gerät per ModBus auf den WR zu. EVCC sollte auch als Add-On deaktiviert sein, damit NIEMAND auf den WR per ModBus zugreift.

Dann richtest Du ModBus Proxy ein.
Bei Upstream-Host gibst du die IP-Adresse deines Wechselrichters ein. Bei upstreamport den ModBus Port des Wechselrichters (bei meinem SolarEdge ist das 1502).

Bei Listen-Port steht bei mir 502 und unten bei Netzwerk den Port 502, der vom Add-On verfügbar gemacht werden muss. Mehr ist es hier gar nicht.

Dann musst du es folgendermaßen konfigurieren:
In EVCC (und auch bei Deiner Wärmepumpe) musst Du dann nicht mehr auf IPdesWechselrichters:1502 connecten, sondern auf IPvonHomeAssistant:502.

Also Beispiel:
Wechselrichter hat IP 192.168.178.42
Home Assistant läuft auf einem NAS auf 192.168.178.10

Dann würde ModBus Proxy auf 192.168.178.42:1502 als Upstream benutzen. Und alle anderen Anwendungen - Home Assistant selbst, EVCC, deine Wärmepumpe und was sonst noch alles auf den Wechselrichter zugreifen soll, verbindet sich auf ModBus Proxy - also 192.168.178.10:502.

Danach startest du das ModBus Proxy Addon, anschließend kannst du EVCC und die Wärmepumpen-Verbindung wieder starten. Dann sollte alles laufen. Hat bei mir keine 10min gedauert.

18

Hallo
vielen Dank für die ausführliche Antwort, habe aber dennoch ein paar nachfragen. Zuerstnochmals meine Konfig:
HA - WP: Modbus mit Port 502
HA - WR: Modbus mit Port 502
AddOn EVCC - WP : macht die Probleme

  • Wie hast du die Kommunikation HA zum WR lahm gelegt: Aussternen des Links auf die Yaml-Dateien?
  • EVCC stoppen ist klar
  • Vielfach habe ich gelesen, dass der WR (und die WP) vom Strom getrennt werden müssen. Wie ist deine Erfahrung?
  • HA Neustarten notwendig, scheinbar nein?

Ich werde heute abend mit deiner Beschreibung den xten Versuch unternehmen.

19

Du sprichst von einer Kommunikation von HA zum WR. Hast du hier auch eine ModBus Verbindung? Dann wären es ja neben der WP schon zwei ModBus Zugriffe. Wie du das stoppen kannst? Indem du die Integration deaktivierst. Oder - wie du vorgeschlagen hast - die Config vorrübergehend änderst. Danach immer einmal neustarten, dass das auch wirklich greift.

Vom Strom nehmen musste ich nichts. Aber im Zweifel könnte das auch helfen, ja.

20

ja, HA und EVCC greifen auf den WR zu, darum der Proxy.
Dieser lässt mich aber verzweifen. Ich konnte nicht bis heute abend warten. Im Prinzip hat sich en meinen vorherigen Einstellungen nichts geändert, ausser das ich den Listen Port und zweiten Port auf 503 geändert habe.
Zuerst habe ich alle Modbus-Verbindungen auf HA und EVCC gekappt. HA neu gestartet. Den Proxy auf 503 geändert und gestartet.

reparing to run modbus-proxy
Upstream: 192.168.178.84:502
Listen: 503
Timeout: 10
Connection Time: 1
Loglevel: DEBUG
Generated Config
devices:

  • modbus:
    url: 192.168.178.84:502 # device url (mandatory)
    timeout: 10 # communication timeout (s) (optional, default: 10)
    connection_time: 1 # delay after connection (s) (optional, default: 0)
    listen:
    bind: 0:503 # listening address (mandatory)
    logging:
    version: 1
    formatters:
    standard:
    format: “%(asctime)s %(levelname)8s %(name)s: %(message)s”
    handlers:
    console:
    class: logging.StreamHandler
    formatter: standard
    root:
    handlers: [‘console’]
    level: DEBUG
    2023-06-28 17:12:38,640 INFO modbus-proxy: Starting…
    2023-06-28 17:12:38,644 INFO modbus-proxy.ModBus(192.168.178.84:502): Ready to accept requests on 0:503

Zeitstempel stammt von einem Restart mit DEBUG

Nach über einen halben Stunde habe ich dann in EVCC alle Port auf 503 geändert, da

INFO modbus-proxy.ModBus(192.168.178.84:502): Ready to accept requests on 0:503

In der Annahme, es muss ein Requst aus einer Anwendung kommen, aber nichts passiert!?

pv 1 power: read failed: dial tcp 192.168.178.84:503: connect: connection refused

Jetzt bleibt mir nur der Versuch, den WR komplett runterfahren, obwohl auch schon mal versucht.