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
Vor der selben Aufgabe stehe ich auch gerade, ich habe 2 Inverter mit Batterie und Power Meter mit der Huawei Solar Integration von @wlcrs 
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 
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
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 
No, that is completely out of scope for a HA integration.
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
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
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 
Großartig DANKE
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
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.
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
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.
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.
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.
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.
Auf der 192.168.178.84 läuft bei dir Home Assistant, richtig?
Wie lautet die IP des Wechselrichters? Und wo hast du die eingetragen?
Mit deiner Frage werde ich jetzt ganz konfus:
192.168.178.56 Home Assistant
192.168.178.67 Solvis Wärmepumpe
192.168.178.84 Sungrow WR Lan für Modbus
(192.168.178.83 Sungrow WR Dongel für Cloud)
So wie du das oben beschrieben hast, wäre die 84 die Upstream-IP, oder?
In:
EVCC.yaml 84:503
Sungrow.yaml 84:503, wenn scharf
Modbus.yaml 67.502, wenn scharf
56 für HA würde hier ja niergends auftauchen.
Wo ist jetzt mein Denkfehler?
Der Denkfehler ist, dass du auf das falsche Gerät zugreifst. Das hatte ich bei deinem Log oben schon vermutet.
Der ModBus Proxy läuft doch als AddOn in Home Assistant. Also hat der Proxy auch die IP von Home Assistant. Also 192.168.178.56:503.
ALLE Geräte müssen auf diese IP zugreifen:
- Home Assistant selbst (um die Daten auf dem Dashboard einzubinden)
- EVCC (für die Wallbox-Steuerung)
- deine Solvis Wärmepumpe (wenn die wirklich Daten vom Wechselrichter direkt abgreifen soll. Ich lese das bei Dir eher so, dass du die Wärmepumpe per ModBus in HA einbinden willst… oder? Dann wäre die Wärmepumpe hier völlig irrelevant, weil HA die Daten auch direkt von der WP holen könnte)
Nur der ModBus Proxy selbst greift auf den Wechselrichter zu. Also auf die 192.168.178.84:502.
Heureka
Deine Erläuterung hat es gebracht! Danke für deine Geduld.
Ich habe zig Forenbeiträge gelesen und auch einige Fragen gestellt, so habe ich das nie verstanden.
Zum Schluss habe ich mir selbst ein Bein gestellt. IP und Port habe ich als Secret definiert. Das mag EVCC nicht,
Ich bin übrigens dadurch auch der Empfehlung des Modul-Autors gefolgt und habe die Ports wieder auf den Standard-Port 502 gestellt.
Also nochmals 1000 Dank
Jürgen
1 Like