Heidelberg Energy Control - RS485 to ETH Hutschienenmodul

[rj3n53n]

Guten Abend,
ich habe meine Heidelberg Energy Control über ein RS485 to ETH - Hutschienenmodul von Waveshare angeschlossen.
Die Box habe ich per DIP S2 auf Slave geschaltet. Das Hutschienenmodul ist im LAN erreichbar.
In der Einstellungoberfläche des Hutschienenmoduls habe ich den RS485 auf 19200 Baud, 8 Datenbits und Parity None Stopbits 0 gestellt.

Die Box habe ich in der evcc.yaml folgendermaßen konfiguriert:

chargers:
- name: Wallbox 2
  type: heidelberg
  uri: 192.168.178.182:4196
  baudrate: 19200
  comset: 8E1
  id: 2

Die Daten habe ich mir aus dem Forum zusammengesucht. Ich bin mir keinesfalls sicher, ob das alles so passt.

Wie kann ich nun überprüfen, ob die Wallbox vom EVCC erkannt wird und ansprechbar ist?
Weder auf der Seite, die der RasPi im System bekommen hat, noch mit dem Befehl
evcc -1 debug meter
kann ich eine Veränderung erkennen.

Ich habe bisher noch keinen Sponsor-Token, weil ich noch am Ausprobieren bin und auch noch keinen Liefertermin für's Auto habe. Sollte der aber an dieser Stelle essentiell sein, werde ich ihn natürlich lösen.

Vielen Dank schonmal für die Hilfe.

[premultiply]

Nein, passt nicht. Die seriellen Einstellungen des Konverters müssen exakt zu den Einstellungen der Box passen. Also 19200,8e1.

Die Einstellungen in evcc gelten dann wiederum der Kommunikation mit dem Konverter. Also eher so ungefähr:

chargers:
- name: Wallbox 2
  type: heidelberg
  uri: 192.168.178.182:502
  rtu: true
  id: 1 # configurable (S2/DIP 1)
  # an evcc sponsortoken is required for using this charger

[rj3n53n]

Warum muss ich den Port 502 angeben? Das Hutschienenmodul hört auf dem Port 4196.

[premultiply]

Das war mir nicht bekannt.
502 ist der übliche Standardport für Modbus.

[rj3n53n]

Ach so, dann versuche ich es erstmal weiter mit dem port, der beim Hutschienenmodul angegeben wird.
Danke für Deinen Tipp.

[rj3n53n]

Ich muss meinen Thread nochmal aufgreifen.
Habe nun den Sponsortoken in der evcc.yaml eingepflegt und das Waveshare-Modul dauerhaft verbunden. Die WB ist auf die Nr. 2 eingestellt. Grundsätzlich soll noch eine WB (Nr. 1) hinzukommen. Das wird aber noch eine Weile dauern.
An dieser Stelle sollte sich doch die EVCC-Seite im Browser laden lassen. Das funktioniert jedoch nicht.

Meine Frage ist nun, wie ich die Wallbox nun in der evcc.yaml eingebe. Momentan sieht es so aus.

# Wallboxen
chargers:
  name: Wallbox_2
  type: heidelberg
  uri: 192.168.178.182:4196
  comset: 8E1
  id: 2 # S2/DIP3 on
  rtu: true
  Protocol: None
  CLI: Disabled

Bei der Einstellung des Waveshare-Moduls blicke ich auch nicht so richtig durch.
Hier gibt es zur eingestellten IP den DevicePort: 4196 und den Device Web Port 80.
Als Work-Modes gibt es

• TCP-Server
• TCP-Client
• UDP
• UDP-Group

Ich habe bereits die beiden Ports 4196 und 80 jeweils in Kombination mit allen Work-Modes ausprobiert. Alles mit dem Ergebnis, dass die Seite im Browser nicht startet.

Mir fehlt gerader jeder Plan, wo ich noch weitersuchen kann.

PS: Ich würde gerne noch einen Screenshot der Einstellungsoberfläche des Waveshare-Moduls anhängen. Wie geht das hier?

[rj3n53n]

Ja, das habe ich alles gemacht. Hab alles mehrfach nachgeschaut.
Danke schon mal.

[premultiply]

Und die Box 1 funktioniert aber einwandfrei?

[rj3n53n]

Die ist bisher nur als WB angeschlossen. Also noch keine Verbindung mit dem EVCC. Die Box 1 hängt am Garagenplatz meiner Frau. Die Monteure haben in der Unterverteilung alles so benannt, dass die Box auf meiner Seite die Nr 2 ist das wollte ich jetzt nicht ändern der mischen.

[premultiply]

Probier mal die angeschlossene Box auf ID1 zu stellen und in der Konfig natürlich auch entsprechend.
Fehlereingrenzung.

[rj3n53n]

Okay, das werde ich tun.
Das muss aber leider erstmal bis Dienstag warten. Ich werde berichten.

Noch eine Frage: ich werde aus der Meldung nach
sudo journalctl -u evcc -n 25
nicht ganz schlau:

Apr 03 17:38:16 EVCC systemd[1]: evcc.service: Main process exited, code=exited, status=2/INVALIDARGUMENT Apr 03 17:38:16 EVCC systemd[1]: evcc.service: Failed with result 'exit-code'.

[rj3n53n]

Ich glaube, ich habe es gefunden. Hatte zwei Punke jeweils mit Buchstaben-Drehern geschrieben.
Jetzt startet die GUI.

Hab auf jeden Fall herzlichen Dank für Deine schnelle Hilfe und einen schönen Sonntag Abend.

[guhlandreas]

Hallo Zusammen,
ich bin am verzweifeln mit meinem Home Assistant, EVCC und Waveshare-Adapter.
Habe die Konfigurationen sinngemäß von oben übernommen es funktioniert aber nicht.

chargers:
  name: Wallbox_2
  type: heidelberg
  uri: 192.168.x.134:502
  id: 1 # S4/DIP3 on
  rtu: true

Ich bekomme immer wieder den Fehler:

cannot create charger 'Heidelberg_Wallbox'
cannot create charger 'heidelberg'
read tcp 192.168.x.136:35612->192.168.x.234:502
i/o timeout

Zur Anmerkung oben:

Abschlusswiderstände an beiden Busenden?

Hmm, An der Heidelberg Wallbox habe ich den Widerstand per DIP geschaltet.
Benötige ich auch am Waveshare Adapter einen Widerstand?

Beste Grüße

Andreas

[premultiply]

Möglich.

Ansonsten sind wohl die Einstellungen des Konverters falsch.

[aseliwanow]

@guhlandreas wie hast du das hinbekommen, habe exakt den gleichen Zustand

Hallo Zusammen, ich bin am verzweifeln mit meinem Home Assistant, EVCC und Waveshare-Adapter. Habe die Konfigurationen sinngemäß von oben übernommen es funktioniert aber nicht.

chargers:
  name: Wallbox_2
  type: heidelberg
  uri: 192.168.x.134:502
  id: 1 # S4/DIP3 on
  rtu: true

Ich bekomme immer wieder den Fehler:

cannot create charger 'Heidelberg_Wallbox'
cannot create charger 'heidelberg'
read tcp 192.168.x.136:35612->192.168.x.234:502
i/o timeout

Zur Anmerkung oben:

Abschlusswiderstände an beiden Busenden?

Hmm, An der Heidelberg Wallbox habe ich den Widerstand per DIP geschaltet. Benötige ich auch am Waveshare Adapter einen Widerstand?

Beste Grüße

Andreas

[guhlandreas]

@aseliwanow: Leider habe ich das Problem (noch) nicht gelöst. Ich habe alles in die Ecke gepfeffert und wollte mir das ein anderes Mal mit starken Nerven nochmals ansehen.
An einer Lösung wäre ich aber hochgradig interessiert, notfalls auch mit anderer Hardware ....
Beste Grüße Andreas

[twingo667]

Ich hatte dasselbe Problem wie Du, guhlandreas. Die reine Aktivierung des DIp-Widerstands hat nicht gefruchtet. Ich habe dann noch einen separaten Abschlusswiderstand gesetzt und seitdem läuft es.

[guhlandreas]

@twingo667 Das wäre ja großartig, wenn es daran läge!! Du hast also den DIP-Widerstand wieder ausgeschaltet und einen separaten Abschlusswiderstand am Ende bei der Wallbox gesetzt. Richtig?
Ich habe verschiedene Angaben zum Widerstand gefunden. Wieviel Ohm hast Du benutzt?
Danke für die Hilfe!!!

[guhlandreas]

hallo @premultiply,
Vielen Dank für die schnelle Antwort und auch danke für den Modus-Hinweis.
Da hatte ich heute Nacht noch mit herumgespielt und das verschlimmert.
Waveshare ist jetzt also "none":

Ansonsten habe ich nichts geändert.

Der Fehler sieht nun so aus:
[cache ] TRACE 2023/06/07 14:09:37 fatal: [cannot create charger 'my_charger' cannot create charger 'template' cannot create charger 'heidelberg' read tcp 192.168.7.136:44620->192.168.7.234:2000 i/o timeout]

Zu port 502 bow. 2000 hatte ich ja oben eine Erklärung, warum ich das gemacht habe, oder kann das mit port 2000 nicht gehen?

[guhlandreas]

und umgekehrt, also Waveshare = "Modus TCP Protocol" und EVCC sollte dann laut doc wie folgt aussehen:

chargers:
  - name: my_charger
    type: heidelberg
    uri: 192.168.7.234:2000
    id: 1 

Kommt folgender Fehler:

[main  ] FATAL 2023/06/07 14:56:49 cannot create charger 'my_charger': cannot create charger 'heidelberg': read tcp 192.168.7.136:39448->192.168.7.234:2000: i/o timeout
[cache ] TRACE 2023/06/07 14:56:49 fatal: [cannot create charger 'my_charger' cannot create charger 'heidelberg' read tcp 192.168.7.136:39448->192.168.7.234:2000 i/o timeout]
[main  ] FATAL 2023/06/07 14:56:49 will attempt restart in: 5m0s

[guhlandreas]

und noch ein Nachtrag:
Ich habe nun eine weitere EVCC installation auf meinem Mac Notebook installiert, mit gleicher evcc.yaml.
Der Fehler bleibt der gleiche.
Somit kann ich wohl ausschließen, dass es an der HA und/oder EVCC installation bzw. dem QNAP Server liegt.

Hat noch jemand eine Idee?

[premultiply]

Wie sind die Dip-Switche eingestellt?
Wie genau sieht die Verkabelung aus?

[guhlandreas]

Alle DIP Switche (S2 / S4 / S5 / S6) sind alle "off" nur die Folgenden sind "on":
S2/4
S4/4
S6/2
S1 steht auf "9" und S3 auf "0"

DAs Kabel von der Wallbox zum Gateway ist ein Cat 5 Kabel. Ich habe die beiden Adern blau und blau-weiss genutzt. Am Gateway und an der Wallbox habe ich einen 120 Ohm Widerstand dran.
Das Kabel hatte ich zwischenzeitlich auch getauscht.

[guhlandreas]

Hallo an alle, die das hier gelesen haben und mir Tipps gegeben haben!
Das Problem ist gelöst. Ich habe das Handbuch der WB falsch interpretiert.
Der Switch S2/4 muss auch "off" sein. Und schon läufts.
Dafür haben die nachfolgenden Generationen vielleicht nun eine hübsche Anleitung, wie es anzuschließen ist ;-)

[selbstmacher]

Hi,
ich fasse noch mal zusammen, da mich das wirklich zu Verzweiflung getrieben hat und ich schon dachte die Wallbox ist defekt.
Die Waveshare muss wie folgt konfiguriert sein:

Die Heidelberg muss als erstes immer ausgeschaltet sein beim ändern der DIP's:
Alle DIP Switche (S2 / S4 / S5 / S6) sind alle "off" nur die Folgenden sind "on":
S4/4
S6/2
S1 steht auf "9" und S3 auf "0"

Zusätzlicher Abschlusswiderstand an beide Enden: Wallbox und Waveshare.

hier die Konfiguration aus der evcc.yaml:
chargers:

• name: wallbox4
  type: heidelberg
  uri: 10.81.10.152:502
  id: 1
  Die IP Adressen müssen natürlich dann noch angepasst werden.
  So hat es dann endlich auch bei mir geklappt.
  Ich danke vor allem @guhlandreas für die entscheidenden tipps.

[horstvogel]

Habe es jetzt die Konfiguration geändert von modbus: rs485tcpip (wie es fälschlicherweise in den docs steht) in modbus: tcpip - und schon geht es.

@premultiply Bitte unbedingt in den docs ändern, damit andere nicht auch wie ich stundenlang verzweifeln... :-)

@horstvogel Bei mir ist jetzt der DIP S6/2 an und kein zusätzlicher 120 Ohm Widerstand an der Wallbox. Nur an der Waveshare ist einer dran. (Ob der tatsächlich nötig ist, habe ich jetzt nicht zusätzlich verifiziert. Never change a running system.)

Also auch getestet: mit modbus: tcpip geht das.

Mein Versuchsaufbau in der Werkstatt ;-)

und wenn der DIP S6/2 an ist, dann entspricht das einem 120 Ohm Widerstand. Dann halt nur noch einen 120 Ohm Widerstand beim Waveshare. 120 Ohm zwischen A und B. A und B sind auch A und B bei der Wallbox.

Wallbox auf Modbus IN gehen.

Die Heidelberg muss als erstes immer ausgeschaltet sein beim ändern der DIP's:
Alle DIP Switche (S2 / S4 / S5 / S6) sind alle "off" nur die Folgenden sind "on":
S4/4
S6/2
S1` steht auf "9" und S3 auf "0"

` - name: my_chargertest
type: template
template: heidelberg

modbus: tcpip
id: 1
host: 192.168.56.91 # Hostname
port: 502 # Port`

`

` - title: test # display name for UI
circuit: main

charger: my_chargertest # charger
#

mode: off # set default charge mode, use "off" to disable by default if charger is publicly available

# vehicle: car1 # set default vehicle (disables vehicle detection)
phases: 1 # electrical connection (normal charger: default 3 for 3 phase, 1p3p charger: 0 for "auto" or 1/3 for fixed phases)
minCurrent: 6 # minimum charge current (default 6A)
maxCurrent: 16 # maximum charge current (default 16A)#

remaining settings are experts-only and best left at default values

# remaining settings are experts-only and best left at default values
priority: 0 # relative priority for concurrent charging in PV mode with multiple loadpoints (higher values have higher priority)
soc:
  # polling defines usage of the vehicle APIs
  # Modifying the default settings it NOT recommended. It MAY deplete your vehicle's battery
  # or lead to vehicle manufacturer banning you from API use. USE AT YOUR OWN RISK.
  poll:
    # poll mode defines under which condition the vehicle API is called:
    #   charging: update vehicle ONLY when charging (this is the recommended default)
    #   connected: update vehicle when connected (not only charging), interval defines how often
    #   always: always update vehicle regardless of connection state, interval defines how often (only supported for single vehicle)
    mode: connected
    # poll interval defines how often the vehicle API may be polled if NOT charging
    interval: 60m
  estimate: true # set false to disable interpolating between api updates (not recommended)
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)`

[horstvogel]

Wie fügt man eigentlich einen Code richtig in Github ein, bei mir kommt da immer nur Mist raus.

[stdt]

@premultiply Sorry, dann bin ich doof dazu.

In der Doku steht, dass es zwei Möglichkeiten gibt:

• RS485 via adapter (Modbus RTU) : dazu brauche ich einen seriellen USB-Adapter
• RS485 via TCP/IP (Modbus RTU) : dazu brauche ich was? (Ich bin davon ausgegangen, dass ich eben dazu einen RS485 to ETH Adapter benötige, was eben der Waveshare macht. Und das geht nun mal nicht mit der in der Doku angegebenen Konfig.)

Von daher: Ja, es sollte in der Doku so stehen, dass man es versteht.
Ich schreibe dir gerne einen Absatz, der das beschreibt. :-)

RS485 via TCP/IP (Modbus RTU) mit  RS485 to ETH - Hutschienenmodul (z.B. Waveshare)
    modbus: tcpip
    id: 1
    host: 192.0.2.2 # Hostname des Hutschienenmoduls
    port: 502 # Port

[premultiply]

Wenn du die Modbus-Protokollkonvertierung im Konverter abgeschaltet hättest, dann hätte es auch gleich funktioniert.

Aber ist ja egal, funktioniert ja jetzt auch mit. evcc muss halt nur wissen welche Sprache gesprochen wird.

[premultiply]

Hier stehen auch die entsprechenden Hintergrundinformationen zu Modbus RTU und Modbus TCP:

https://docs.evcc.io/docs/reference/modbus

[Hobbl2]

Hi,
hab das gleiche Projekt vor mir und würde gerne wissen ob ihr das "Waveshare RS485 TO ETH (19625)" oder das "WaveShare Industrial RS232 RS485 to Ethernet Converter" genommen habt.

Hätte noch ein "Waveshare RS485 TO WIFI/ETH" von einem anderen (gescheiterten) Projekt hier liegen, aber die Benutzeroberfläche ist da sowas von wirr durch Wifi und ETH Kombination, dass ich überhaupt nicht mehr durchblicke was ich wo einstellen muss......!!?!

Sollte also jemand das "Waveshare RS485 TO WIFI/ETH" am laufen haben, wäre ich dankbar über eine Bilderstrecke was man wo einstellen muss.
Ansonsten hole ich mir einfach das ohne Wifi welches ihr hier schon am laufen habt.

Danke schon mal vorab

Gruß
Hobbl

[rob-by]

Hallo zusammen,
ich habe leider das gleiche Gerät wie Hobbl2. Könnte hier bitte jemand unterstützen?

Danke im Vorraus :)