search

evcc-io / evcc

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

2 x Heidelberg Energy Control Modbus Problem? #2227

Closed chrissooo closed 2 years ago

chrissooo commented 2 years ago

Describe the bug Ich habe 2 Heidelberg Energy Control die ich per Modbus in Reihe laut Angaben des Herstellers angeschlossen habe. Am Raspbarry PI steckt ein USB zu Modbus Stick mit A und B Anschluss.

Die Boxen haben die ID 1 und ID 2 und sind folgendermassen konfiguriert:

chargers:
- type: template
  template: heidelberg
  modbus: rs485serial
  name: wallbox1
  id: 1
  device: /dev/ttyUSB0
  baudrate: 19200
  comset: 8E1
- type: template
  template: heidelberg
  modbus: rs485serial
  name: wallbox2
  id: 2
  device: /dev/ttyUSB0
  baudrate: 19200
  comset: 8E1

Sobald ich eine der Boxen auskommentiere, funktioniert es. Sobald beide laufen sollen, gibt es viele timeout Fehler und charger: invalid status: a ... siehe Logfile

premultiply commented 2 years ago

Da scheint das "serielle Portsharing" offenbar nicht richtig zu funktionieren. Ich glaube das hat vorher noch nie jemand getestet...

chrissooo commented 2 years ago

Hier mal ein logfile wenn nur eine Box dran ist, die mit ID 1 in dem Fal evcc-ok.log l

premultiply commented 2 years ago

"Dran" heisst elektrisch abgeklemmt (oder elektrisch aus) oder aus der aktiven Konfig entfernt?

chrissooo commented 2 years ago

NUr aus aktiven Konfig raus. Die Verkablung ist unverändert beide sind am Strom.

chrissooo commented 2 years ago

Ich habe jetzt noch ein Scenario überprüft. Und zwar wenn ich nur die Box mit ID2 laufen lasse kommen auch fehler, aber nicht alle und nur vereinzelnd. Die Box läuft und funktioniert scheinbar. Im Anhang das Logflie.

Um ein Kabelproblem auszuschließen, habe ich die einzer abgeklemmt und die BUsleitungen direkt zusammengesteckt. Nun kamen auch bei BOX zwei keine Fehler mehr. Liegt also nicht am Kabel. Langt aber wohl dass die inaktive Box 1 mit dran höngt dass die Probleme, zumindest laut Logfile angfangen evcc-teilok-id2.log .

chrissooo commented 2 years ago

DIe Zwei Boxen sind in Reihe ... RaspberryPI <> Box 1 mi ID 1 <> Box 2 mit ID 2

andig commented 2 years ago

Also soweit ich das im Code sehe, wird da nur eine Verbindung aufgemacht die dann von beiden Geräten genutzt wird. Alles korrekt. Kannst Du mal 

delay: 200ms

einstellen? Evtl. sind die ja zickig wenn die ClientID sich ändert. Die SDM Zähler z.B. brauchen da immer eine cool-down Zeit.

andig commented 2 years ago

Wenn das nicht hilft müsste man mal mit handgestricktem Code auf die beiden Boxen ballern und schauen ob es damit ohne Probleme ginge und dann die Unterschiede ergründen bzw. was es bräuchte damit die Probleme weg gehen. Oder beide Boxen an einen/zwei TCP Adapter hängen.

premultiply commented 2 years ago

Hast du am Master, also auf der Raspberry-Pi-Seite den Bus ebenfalls korrekt terminiert? Es muss in jeder Situation immer an beiden Busenden korrekt terminiert sein sonst sind Datenfehler quasi normal.

premultiply commented 2 years ago

Nur um es nochmal sicherzustellen:

Box 1:

S2 alles OFF

S5/2 OFF
S5/3 OFF
S5/4 OFF (Follower mode)

S4/1 OFF
S4/2 OFF
S4/3 OFF
S4/4 ON (ID = 1)

S6/2 OFF (Bus-Terminierung aus)

Box 2:

S2 alles OFF

S5/2 OFF
S5/3 OFF
S5/4 OFF (Follower mode)

S4/1 OFF
S4/2 OFF
S4/3 ON (ID =2)
S4/4 OFF

S6/2 ON (Bus-Terminierung an)
chrissooo commented 2 years ago

Also die Einatełungen an den Wallboxen passen. So wie du beschrieben hast.

Am Raspberry Pi habe ich nichts gemacht, wie kann ich hier terminieren? Das ist so eine USB Stick. Und warum funzt dann eine Box ohne Fehler?

Bin jetzt nicht daheim, prüfe das mit dem deley wenn ich daheim bin. Gerne kann ich euch auch mit openvpn auf die Kiste lassen wenn das nötig sein sollte.

premultiply commented 2 years ago

Einfach einen 120-Ohm-Widerstand zwischen A und B am USB-Adapter grafik

premultiply commented 2 years ago

Und warum funzt dann eine Box ohne Fehler?

Wenn die Terminierung nicht korrekt ist gibt es Reflexionen auf der Leitung und das Timing gerät durcheinander. Dann kann es z. B. passieren dass zwei Geräte am Bus gleichzeitig senden weil irrtümlich der Bus für unbelegt gehalten wird und dann kommt nur noch Datenmüll heraus der vielleicht teilweise überhaupt nicht mehr als Daten erkannt wird. Da gibt es beliebige Zustände. evcc wird da ordentlich Dampf machen wenn es die erste Box abgefragt hat gleich den Request an die Zweite zu schicken. Wenn die erste dann aber noch am Senden ist versteht die Zweite nix mehr. Und umgekehrt. Kurz: Mist.

andig commented 2 years ago

@chrissooo für den Test mit delay brauchst Du https://github.com/evcc-io/evcc/pull/2228

chrissooo commented 2 years ago

@premultiply ok, habe jetzt nichts vorrätig, werde mir aber ein Wierserstand besorgeb.

@andig habe den Bruch gebaut. WO muss ich jetzt den delay merken? zwischen send und resv? Weil da merk ich laut Logfiles nichts ... habe mal auf 2000ms hochgesetzt, da merkt man kein Delay ziwschen send und resv:

[heidel] TRACE 2022/01/06 18:54:27 modbus: send 01 04 00 07 00 01 80 0b [heidel] TRACE 2022/01/06 18:54:27 modbus: recv 01 04 02 00 00 b9 30 [heidel] TRACE 2022/01/06 18:54:27 modbus: send 01 04 00 08 00 01 b0 08 [heidel] TRACE 2022/01/06 18:54:27 modbus: recv 01 04 02 00 00 b9 30

chrissooo commented 2 years ago

@andig also der delay Brunch geht nicht, aber wie gesagt habe ich das gefühl dass es nicht greift? Ich habe vor dem bauen überprüft dass es im code war und mit make build gebaut.

andig commented 2 years ago

Du hast die händische config? Im Template ist das Delay noch nicht drin? Zeig mal bitte.

@DerAndereAndi warum gibts hier keinen Fehler wenn Parameter gesetzt werden, die das Template nicht versteht?

DerAndereAndi commented 2 years ago

Manuelle Config ist unnötig. Einfach den PR bauen und in der momentanen Config delay: 200 hinzufügen

chrissooo commented 2 years ago

So, war beim Elektronikfachmarkt meines Vertrauens und einer WIederstand besorgt. @premultiply, ist jetzt also teminiert, auch am USB Stick.

Leider nachwievor invalid status: a und timeouts ... siehe Logfile

Hier die Config von der gebauten Version, im Template habe ich nichts geändert. chargers:

- type: template
  template: heidelberg
  modbus: rs485serial
  name: wallbox1
  id: 1
  device: /dev/ttyUSB0
  baudrate: 19200
  comset: 8E1
  delay: 200ms
- type: template
  template: heidelberg
  modbus: rs485serial
  name: wallbox2
  id: 2
  device: /dev/ttyUSB0
  baudrate: 19200
  comset: 8E1
  delay: 200ms

Und hier das Logfile: evcc-log-delay200.log

WIe gesagt, wie erkennt man am Logfile wo das delay ist? Hatte mal 2000ms drin, zwischen den Anfragen und den Antworten habe ich keine Verzögerung im Logfile gesehen.

premultiply commented 2 years ago

Probier mal testweise so:

chargers:
- type: heidelberg
  name: wallbox1
  device: /dev/ttyUSB0
  baudrate: 19200
  comset: 8E1
  id: 1
- type: heidelberg
  name: wallbox2
  device: /dev/ttyUSB0
  baudrate: 19200
  comset: 8E1
  id: 2
  delay: 200 #ms
chrissooo commented 2 years ago

Leider nein, mit ms und ohne. Und nur bei wallbox2.

Wie gesagt, ich kann gerne openvpn direkt auf die Kiste anbieten. Golang läuft und man kann compilieren.

premultiply commented 2 years ago

2234 bringt kleine Verbesserung hinsichtlich des merkwürdigen Error-Status-Decoding.

chrissooo commented 2 years ago

Damit neue Logfiles erstellen?

premultiply commented 2 years ago

Nee das nicht unbedingt. Das ist eher kosmetisch.

chrissooo commented 2 years ago

Ok, wenn ich was machen kann ... sagt bescheid. Wie gesagt, ihr könnt gerne auch auf die Kiste drauf falls das etwas vereinfacht.

premultiply commented 2 years ago

Ich hab gerade nochmal ins Protokoll geschaut und hätte da noch eine Idee was da passieren könnte: grafik

premultiply commented 2 years ago

Ok, lass mich wirklich mal schauen was da in den Registern konfiguriert ist. Bei einfach per Slack-PM melden.

andig commented 2 years ago

Nein. Das ist alles Modbus. Meine These: hier liegt irgendein Terminal auf dem Seriellen Port. Warum auch immer. Test: bitte mal ohne den Raspi!

premultiply commented 2 years ago

Ja, diese These hatte ich auch schon. Aber als zu abstrus erstmal verworfen... Ich schaue mir das gerne mal auf dem System direkt an.

premultiply commented 2 years ago

@chrissooo Was sagt denn ps aux | grep tty auf deinem Raspberry?

chrissooo commented 2 years ago

pi@nas:~ $ ps aux | grep tty root 1195 0.0 0.0 4484 932 tty1 Ss+ 21:46 0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux root 1196 0.0 0.0 6648 1224 ? Ss+ 21:46 0:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 ttyAMA0 vt220 pi 9325 0.0 0.0 7468 560 pts/0 S+ 22:59 0:00 grep --color=auto tty

premultiply commented 2 years ago

Ok, zumindest auf den ersten Blick unauffällig...

chrissooo commented 2 years ago

Nein. Das ist alles Modbus. Meine These: hier liegt irgendein Terminal auf dem Seriellen Port. Warum auch immer. Test: bitte mal ohne den Raspi!

Aber dann sollte es doch auch Probleme im Betrieb mit einer Box geben, oder nicht? Hier läuft es rund. Habe heute von ca. 20% auf ca. 80% ohne Fehler geladen mit Box auf ID 1. Die andere auskonfiguriert und stromlos gemacht.

premultiply commented 2 years ago

Die Kommunikationsprobleme treten in gleicher Form auch mit anderer Software auf dem gleichen System und auch auf einem anderen System auf. Getestet z. B. mit mbpoll -a 1,2 -b 19200 -t 4 -r 257 -0 -c 1 /dev/ttyUSB0 Es handelt sich daher um kein evcc Problem. Daher machen wir hier erstmal zu.

premultiply commented 2 years ago

Die Kommunikationsprobleme ließen sich abschließend durch eine andere Verkabelung lösen.

chrissooo commented 2 years ago

Keines Update: Die andere Verkabelung scheint doch nicht die endgültige Lösung zu sein. Leider treten dann im Dauerbetrieb nachwievor, auch wenn viel weniger, Fehler auf. Nur der Dauerbetrieb einer einzelnen Box läuft dann ohne Probleme. Habe mich dann kurzerhand entschlossen, da noch zwei Adern in der Zuleitung frei sind, ein weiteren USB zu Modbus Adapter zu kaufen und die Boxen einzeln anzusteuern. Hiermit sollte ich dann keine Probleme mehr haben

chrissooo commented 2 years ago

Noch ein Nachtrag zur Vollständigkeit, weil ich mir das nochmal angeschaut habe.

mbpoll -a 1,2 -b 19200 -t 4 -r 257 -0 -c 1 /dev/ttyUSB0 bringt keine Fehler mehr, habe es mehrere Minuten laufen lassen.

evcc bringt immer invalid status: a, siehe logfile. evcc-modbus-errors.log

premultiply commented 2 years ago

Status "a" ist nur eine falsche Darstellung für Status F. Im kommenden Release wird es auf "10" korrigiert sein (laut Heidelberg Modbus-Protokollbeschreibung). Wenn deine Wallboxen blinken (Status F) ist etwas verkehrt und undefiniert. Ich hatte dieses Verhalten abgeschaltet (Register 261 auf 60), du wolltest es aber unbedingt wieder angeschaltet haben (Register 261 auf 0). Wir können da nichts tun ausser diesen Zustand zu signalisieren. Status F ist undefiniert.

michirosenbuehl commented 1 year ago

Hallo, ich hänge mich hier mal in dieses Issue mit rein. Ich habe eine ähnliche Modbus-Topologie wie @chrissooo Anstatt des USB/RS485 Adapter habe ich einen Konverter von TCP auf RS485 --> https://www.waveshare.com/wiki/RS485_TO_ETH_(B)

Abschlusswiderstände sind korrekt verbaut.

Ich habe testweise die Modbuskommunikation mit Iobroker getestet. Hier funktioniert alles einwandfrei. D. h. ich kann Register von beiden Wallboxen lesen und die Wallboxen gehen auch nicht in den Fehlerzustand. Deaktiviere ich nun das Modbus-Modul im Iobroker und starte evcc, bekomme ich die besagten timeouts und die Wallboxen gehen in den Fehlerzustand.

Meine Vermutung ist, dass iobroker eine längere Timeout-Überwachung nutzt. grafik

> [main  ] INFO 2022/10/26 20:20:36 evcc 0.105.2
> [main  ] INFO 2022/10/26 20:20:36 using config file: evcc.yaml
> [heidel] TRACE 2022/10/26 20:20:36 modbus: send 00 01 00 00 00 09 01 10 01 02 00 01 02 00 04
> [heidel] TRACE 2022/10/26 20:20:36 modbus: recv 00 01 00 00 00 06 01 10 01 02 00 01
> [heidel] TRACE 2022/10/26 20:20:36 modbus: send 00 02 00 00 00 09 02 10 01 02 00 01 02 00 04
> [heidel] TRACE 2022/10/26 20:20:36 modbus: recv 00 02 00 00 00 06 02 10 01 02 00 01
> wallbox5
> --------
> [heidel] TRACE 2022/10/26 20:20:36 modbus: send 00 03 00 00 00 06 01 04 00 0e 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 04 00 00 00 06 01 04 00 11 00 02
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 04 00 00 00 07 01 04 04 00 00 00 03
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 05 00 00 00 06 01 04 00 06 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 05 00 00 00 05 01 04 02 00 00
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 06 00 00 00 06 01 04 00 07 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 06 00 00 00 05 01 04 02 00 00
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 07 00 00 00 06 01 04 00 08 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 07 00 00 00 05 01 04 02 00 00
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 08 00 00 00 06 01 04 00 05 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 08 00 00 00 05 01 04 02 00 02
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 09 00 00 00 06 01 03 01 05 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 09 00 00 00 05 01 03 02 00 00
> Power:          read tcp 192.168.2.27:40014->192.168.2.155:502: i/o timeout
> Energy:         0.0kWh
> Current L1..L3: 0A 0A 0A
> Charge status:  A
> Enabled:        false
> Diagnostic dump:
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 0a 00 00 00 06 01 04 00 01 00 02
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 0a 00 00 00 07 01 04 04 00 01 00 10
> Firmware:       1.0.16
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 0b 00 00 00 06 01 04 00 09 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 0b 00 00 00 05 01 04 02 01 06
> Temperature:    26.2C
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 0c 00 00 00 06 01 03 01 01 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 0c 00 00 00 05 01 03 02 3a 98
> Timeout:        15000
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 0d 00 00 00 06 01 03 01 02 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 0d 00 00 00 05 01 03 02 00 04
> Standby:        4
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 0e 00 00 00 06 01 03 01 03 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 0e 00 00 00 05 01 03 02 00 01
> Remote Lock:    1
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 0f 00 00 00 06 01 03 01 06 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 0f 00 00 00 05 01 03 02 00 00
> FailSafe:       0
> 
> wallbox7
> --------
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 10 00 00 00 06 02 04 00 0e 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 10 00 00 00 05 02 04 02 00 00
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 11 00 00 00 06 02 04 00 11 00 02
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 11 00 00 00 07 02 04 04 00 00 00 00
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 12 00 00 00 06 02 04 00 06 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 12 00 00 00 05 02 04 02 00 00
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 13 00 00 00 06 02 04 00 07 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 13 00 00 00 05 02 04 02 00 00
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 14 00 00 00 06 02 04 00 08 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 14 00 00 00 05 02 04 02 00 00
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 15 00 00 00 06 02 04 00 05 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 15 00 00 00 05 02 04 02 00 02
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 16 00 00 00 06 02 03 01 05 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 16 00 00 00 05 02 03 02 00 00
> Power:          0W
> Energy:         0.0kWh
> Current L1..L3: 0A 0A 0A
> Charge status:  A
> Enabled:        false
> Diagnostic dump:
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 17 00 00 00 06 02 04 00 01 00 02
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 17 00 00 00 07 02 04 04 00 02 00 10
> Firmware:       2.0.16
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 18 00 00 00 06 02 04 00 09 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 18 00 00 00 05 02 04 02 01 06
> Temperature:    26.2C
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 19 00 00 00 06 02 03 01 01 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 19 00 00 00 05 02 03 02 3a 98
> Timeout:        15000
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 1a 00 00 00 06 02 03 01 02 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 1a 00 00 00 05 02 03 02 00 04
> Standby:        4
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 1b 00 00 00 06 02 03 01 03 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 1b 00 00 00 05 02 03 02 00 01
> Remote Lock:    1
> [heidel] TRACE 2022/10/26 20:20:37 modbus: send 00 1c 00 00 00 06 02 03 01 06 00 01
> [heidel] TRACE 2022/10/26 20:20:37 modbus: recv 00 1c 00 00 00 05 02 03 02 00 00
> FailSafe:       0

Wie kann ich ein Timeout parametrieren kann? Wenn ich den Issue richtig verfolgt habe, muss ich den source ändern und neu kompilieren. Ist mir jetzt noch nicht ganz klar wie hier der Workflow ist...

Es würde mich freuen, wenn wir dieses Thema auflösen könnten.

premultiply commented 1 year ago

Wenn der Konverter das Protokoll übersetzt und evcc auf die falsche Variante konfiguriert ist verstehen Wallboxen und Konverter nicht was evcc will. Also Modbus TCP im Konverter aus und mit rs485tcpip seitens evcc mit Modbus RTU over TCP ansprechen oder Modbus TCP an und dann tcpip verwenden.

michirosenbuehl commented 1 year ago

Ich verwende Modbus TCP. Übrigens hängen noch zwei eastron Zähler drin. Diese lassen sich einwandfrei auslesen.


# open evcc at http://evcc.local:7070
network:
  schema: http
  host: evcc.local # .local suffix announces the hostname on MDNS
  port: 7070

log: trace
levels:
  mqtt: error
  site: error
  lp-1: trace
  cache: error

mqtt:
  broker: localhost:1883
  topic: evcc

# unique installation id
plant:

interval: 5s # control cycle interval

sponsortoken: 

# sponsors can set telemetry: true to enable anonymous data aggregation
# see https://github.com/evcc-io/evcc/discussions/4554
telemetry: false

meters:
- name: grid1
  type: custom
#  usage: grid
  power:    ##Leistungswert aus solarview Umrichter
    source: mqtt
    broker: localhost:1883
    topic: energy/grid/Psum
    scale: 1
  energy:
    source: mqtt
    broker: localhost:1883
    topic: energy/grid/Wsum
    scale: 1
  currents:
    - source: mqtt
      broker: localhost:1883
      topic: energy/grid/I1
      scale: 1
    - source: mqtt
      broker: localhost:1883
      topic: energy/grid/I2
      scale: 1
    - source: mqtt
      broker: localhost:1883
      topic: energy/grid/I3
      scale: 1

- type: template
  template: kostal-piko
  usage: pv
  host: 192.168.2.202
  name: pv2
#- type: template
#  template: kostal-piko
#  usage: battery
#  host: 192.168.2.202
#  name: battery3
- type: template
  template: eastron
  id: 21
  host: 192.168.2.155
  port: 502
  usage: charge
  modbus: tcpip
  name: charge6
- type: template
  template: eastron
  id: 22
  host: 192.168.2.155
  port: 502
  usage: charge
  modbus: tcpip
  name: charge8

chargers:
- type: template
  template: heidelberg
  id: 1
  host: 192.168.2.155
  port: 502
  modbus: tcpip
  name: wallbox5
- type: template
  template: heidelberg
  id: 2
  host: 192.168.2.155
  port: 502
  modbus: tcpip
  name: wallbox7

vehicles:
- type: template
  template: peugeot
  title: 2008e
  user: xxx
  password: test
  vin: test
  capacity: 50
  phases: 3
  cache: 15m
  mode: pv
  minSoC: 30
  targetSoC: 80
  minCurrent: 6
  maxCurrent: 16
  name: ev4

loadpoints:
- title: Carport links
  charger: wallbox5
  meter: charge6
  mode: pv
  phases: 3
  mincurrent: 6
  maxcurrent: 16
  resetOnDisconnect: true
- title: Carport rechts
  charger: wallbox7
  meter: charge8
  mode: pv
  phases: 3
  mincurrent: 6
  maxcurrent: 16
  resetOnDisconnect: true

site:
  title: Mein Zuhause
  meters:
    grid: grid1
    pvs:
    - pv2

grafik

michirosenbuehl commented 1 year ago

Wenn der Konverter das Protokoll übersetzt und evcc auf die falsche Variante konfiguriert ist verstehen Wallboxen und Konverter nicht was evcc will. Also Modbus TCP im Konverter aus und mit rs485tcpip seitens evcc mit Modbus RTU over TCP ansprechen oder Modbus TCP an und dann tcpip verwenden.

ich hab jetzt die andere (von dir vorgeschlagene) Variante probiert - also Modbus TCP im Konverter aus und rs485tcpip seitens evcc aktiviert

--> Fehlerzustand der Wallboxen ebenfalls weg

Vielen dank!

grafik