Secondary an EVCC

[schariwari]

Hallo,

ich hab einige Fragen zu meiner Konfiguration:
- Original OpenWB 2+ Hardware (ausgeliefert ursprünglich mit 1.9) MIT Zusatzboard für 1p/3p-Umschaltung
- Software 2.1.2 Patch2, Stand Master vom 05.01.24
- Installiert als Softwarepaket laut https://github.com/openWB/core (aus verschiedenen Gründen kann ich das fertige Image nicht nehmen)
- EVCC in der aktuellsten Version 0.123.5
- Der vorhandene Fronius Symo Gen24 wird von EVCC (korrekt) ausgelesen.

Folgendes konfiguriert:
- OpenWB ist Secondary mit Modbus-Steuerung

Was geht:
Die Ansteuerung über EVCC funktioniert an sich; d.h. PV-Laden und Sofort-Laden im EVCC eingestellt geht direkt durch und arbeitet per se korrekt, im EVCC zeigt er korrekte und sinnvolle Werte an. Die Modus-Anbindung steht also sauber.

1. FRAGE: Was nicht geht und ich nicht zu laufen kriege, ist die Umschaltung auf 3 Phasen. Und zwar weder, wenn ich das in EVCC konfiguriere, noch, wenn ich die OpenWB umkonfiguriert (und mit einem virtuellem Zähler versehe) an der Box selber. Er versucht das wohl, ist also anscheinend richtig konfiguriert, aber er kriegt nicht geregelt. (Fehlermeldung im Screenshot OHNE EVCC.)

Ich habe testweise eine weitere SD-Karte mit dem Original-IMG bespielt, und siehe da: Beides, sowohl Stand-Alone-Box als auch als Secondary mit EVCC kann die Phasenumschaltung durchführen. Nur kann und muss ich auf den Raspi in der Box zugreifen, was mit dem Original-IMG nicht geht. (Der Support kann das nimmer freigeben, das ist nimmer User/pwd, sondern mit Zertifikaten geschützt).
---> Ich vermute, das bei der "händischen Installation" des OpenWB-Core noch die Zusatzplatine irgendwie mit eingebunden werden muss, habe aber dazu nichts gefunden. Kann mir hier bitte irgendwer einen Tip geben??


2.FRAGE: hängt eigentlich mehr oder weniger mit der Konstellation oben direkt zusammen (ist aber nur ein Nebenkriegs-Schauplatz): Wenn eine OpenWB mit Display als Secondary konfiguriert ist, holt sich das Display anscheinend die Konfiguration von der Primary. Nur gibts die eben in meinem Falle nicht, weil das das EVCC macht. Der Screen zeigt also einen Browser-Fehler an. Kann man das irgendwie (und wenn ja wie) konfigurieren, was das Display anzeigen soll?? Ideal wäre einfach die EVCC-Oberfläche.

[schariwari]

Der Vollständigkeit halber, das Log des internen Ladepunkt bei Ansteuerung via EVCC:

Code: Alles auswählen

2024-01-06 13:26:41,923 - {asyncio:59} - {DEBUG:Internal Chargepoint} - Using selector: EpollSelector
2024-01-06 13:26:41,926 - {modules.internal_chargepoint_handler.rfid:121} - {DEBUG:Internal Chargepoint} - reading events from: /dev/input/event0
2024-01-06 13:26:44,056 - {modules.internal_chargepoint_handler.clients:107} - {ERROR:Internal Chargepoint} - LP0 Device: /dev/ttyUSB0
2024-01-06 13:26:44,244 - {modules.internal_chargepoint_handler.clients:53} - {ERROR:Internal Chargepoint} - Modbus-ID der EVSE an LP0: 1
2024-01-06 13:26:45,315 - {modules.internal_chargepoint_handler.clients:67} - {ERROR:Internal Chargepoint} - Verbauter Zähler: <class 'modules.common.sdm.Sdm630'> mit Modbus-ID: 105
2024-01-06 13:26:45,682 - {modules.internal_chargepoint_handler.chargepoint_module:45} - {DEBUG:Internal Chargepoint} - Firmware-Version der EVSE: 18
2024-01-06 13:26:45,842 - {modules.common.evse:62} - {DEBUG:Internal Chargepoint} - Angabe der Ströme in 0,01A-Schritten ist aktiviert.
2024-01-06 13:26:46,002 - {modules.common.evse:62} - {DEBUG:Internal Chargepoint} - Angabe der Ströme in 0,01A-Schritten ist aktiviert.
2024-01-06 13:26:46,024 - {modules.common.fault_state:49} - {ERROR:Internal Chargepoint} - Interner Ladepunkt 1: FaultState FaultStateLevel.ERROR, FaultStr <class 'RuntimeError'> ('No access to /dev/mem.  Try running as root!',), Traceback: 
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/internal_chargepoint_handler/internal_chargepoint_handler.py", line 168, in __init__
    self.init_gpio()
  File "/var/www/html/openWB/packages/modules/internal_chargepoint_handler/internal_chargepoint_handler.py", line 173, in init_gpio
    GPIO.setup(37, GPIO.OUT)
RuntimeError: No access to /dev/mem.  Try running as root!

2024-01-06 13:26:48,042 - {modules.internal_chargepoint_handler.clients:107} - {ERROR:Internal Chargepoint} - LP0 Device: /dev/ttyUSB0
2024-01-06 13:26:48,205 - {modules.internal_chargepoint_handler.clients:53} - {ERROR:Internal Chargepoint} - Modbus-ID der EVSE an LP0: 1
2024-01-06 13:26:49,274 - {modules.internal_chargepoint_handler.clients:67} - {ERROR:Internal Chargepoint} - Verbauter Zähler: <class 'modules.common.sdm.Sdm630'> mit Modbus-ID: 105
2024-01-06 13:26:49,642 - {modules.internal_chargepoint_handler.chargepoint_module:45} - {DEBUG:Internal Chargepoint} - Firmware-Version der EVSE: 18
2024-01-06 13:26:49,802 - {modules.common.evse:62} - {DEBUG:Internal Chargepoint} - Angabe der Ströme in 0,01A-Schritten ist aktiviert.
2024-01-06 13:26:49,961 - {modules.common.evse:62} - {DEBUG:Internal Chargepoint} - Angabe der Ströme in 0,01A-Schritten ist aktiviert.
2024-01-06 13:26:49,969 - {modules.common.fault_state:49} - {ERROR:Internal Chargepoint} - Interner Ladepunkt 1: FaultState FaultStateLevel.ERROR, FaultStr <class 'RuntimeError'> ('No access to /dev/mem.  Try running as root!',), Traceback: 
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/internal_chargepoint_handler/internal_chargepoint_handler.py", line 168, in __init__
    self.init_gpio()
  File "/var/www/html/openWB/packages/modules/internal_chargepoint_handler/internal_chargepoint_handler.py", line 173, in init_gpio
    GPIO.setup(37, GPIO.OUT)
RuntimeError: No access to /dev/mem.  Try running as root!

[aiole]

1. Hast Du 1p3p original bestellt oder nur das addon? Nur addon reicht nicht.
2. Du verwendest eine Fremdsteuerung. Das heißt, dass sich diese zu 100% um alles kümmern muss. Ich denke deshalb, dass openWB den EVCC-Screen nicht anzeigen kann, außer Du strickst Dir da etwas selbst. Aber ev. könnte openWB zumindest Allgemeindaten der Ladung anzeigen. Müsste sich die openWB-SW-Abteilung mal ansehen.

Update
Irgendwelche Zugriffsprobleme aus deiner Eigeninstallation liegen noch vor.

[schariwari]

1.) Ich hab die "Series2 Standard+", da ist alles drin (soweit ich das verstanden hab). Und wenn das Original--Image drinsteckt von der V2.x (oder auch die v1.9), dann kann Sie ja umschalten. Müsste alles notwendige da sein.

2.) Mir klar, das ich da selber was basteln muss (was ich ja auch kann, weil ich Zugriff hätte). Bräuchte nur einen Tip, wo ich zu suchen anfangen muss.

zu Update: Ja, ich sehe auch, das im Log Meldungen sind

Code: Alles auswählen

No access to /dev/mem.  Try running as root!

und er wohl versucht auf den GPIO zuzugreifen

Code: Alles auswählen

 File "/var/www/html/openWB/packages/modules/internal_chargepoint_handler/internal_chargepoint_handler.py", line 168, in __init__
    self.init_gpio()
  File "/var/www/html/openWB/packages/modules/internal_chargepoint_handler/internal_chargepoint_handler.py", line 173, in init_gpio
    GPIO.setup(37, GPIO.OUT)

Nur was tue ich?? Ich hab´s installiert wie angegeben.

[aiole]

1. Ja - dann hast Du die 1p3p-Funktionalität.
2. sry - bei Code bin ich weitgehend raus, aber da gibt es sicher noch Hilfe von anderen.

[derNeueDet]

Hoffe du hast selbst nichts an der openWB verändert, auch wenn du Zugriff hast. Vermutlich bist du auf der V1.9.

Ich hab das folgende gefunden:

Re: RPi.GPIO: RuntimeError: No access to /dev/mem. Try running as root!
Thu Jan 10, 2019 10:48 am

Ok, I finally found the problem: a bug was introduced in the RPi.GPIO library v0.6.4, and subsequently fixed in 0.6.5, see https://github.com/RPi-Distro/python-gp ... issues/687 Removing the version shipped by Raspbian and installing via pip pulled in 0.6.5 and the issue went away.

https://forums.raspberrypi.com/viewtopic.php?t=230761

Hier wird davon gesprochen, dass es nur in der Version 0.6.4 vorhanden ist.

meine Original openWB V1.9 spuckt die Version 0.6.3 aus.

Code: Alles auswählen

pi@openWB:~ $ pip list |grep -i gpio
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
Adafruit-GPIO (1.0.3)
gpiozero (1.4.1)
pigpio (1.38)
RPi.GPIO (0.6.3)
pi@openWB:~ $ pip3 list |grep -i gpio
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
gpiozero (1.4.1)
pigpio (1.38)
RPi.GPIO (0.6.3)

Ich würde fast tippen, dass das Problem bereits in der 0.6.3 drin war. Mit der openWB V2.x würdest du das vermutlich umgehen, da die auf einer aktuelleren Raspbian Distro aufsetzt und da dann auch die GPIO Lib aktueller ist.

VG
Det

[schariwari]

a) Nein, NOCH hab ich nichts verändert
b) Nein, ich bin, wie oben schon gesagt auf V2.1.2
c) das Rasbian ist ein bullseye, aktuell gepatcht.

Die Fehlermeldungen im Log hab ich tatsächlich rausgekriegt, das lag daran, das das Setup-Script wohl den User "openwb" nicht in die GPIO-Gruppe legt. Mit

Code: Alles auswählen

sudo usermod -G gpio -a openwb

kriegt man das geregelt.

Danke für den "Denk-Anstubser"

LEIDER löst das das Umschalt-Problem NICHT.

Zur Info:

Code: Alles auswählen

as@OpenWB:~ $ pip list |grep -i gpio
gpiozero      1.6.2
RPi.GPIO      0.7.0
as@OpenWB:~ $ pip3 list |grep -i gpio
gpiozero      1.6.2
RPi.GPIO      0.7.0

und

Code: Alles auswählen

2024-01-06 14:21:33,144 - {asyncio:59} - {DEBUG:Internal Chargepoint} - Using selector: EpollSelector
2024-01-06 14:21:35,271 - {modules.internal_chargepoint_handler.clients:107} - {ERROR:Internal Chargepoint} - LP0 Device: /dev/ttyUSB0
2024-01-06 14:21:35,424 - {modules.internal_chargepoint_handler.clients:53} - {ERROR:Internal Chargepoint} - Modbus-ID der EVSE an LP0: 1
2024-01-06 14:21:36,493 - {modules.internal_chargepoint_handler.clients:67} - {ERROR:Internal Chargepoint} - Verbauter Zähler: <class 'modules.common.sdm.Sdm630'> mit Modbus-ID: 105
2024-01-06 14:21:36,846 - {modules.internal_chargepoint_handler.chargepoint_module:45} - {DEBUG:Internal Chargepoint} - Firmware-Version der EVSE: 18
2024-01-06 14:21:37,005 - {modules.common.evse:62} - {DEBUG:Internal Chargepoint} - Angabe der Ströme in 0,01A-Schritten ist aktiviert.
2024-01-06 14:21:37,164 - {modules.common.evse:62} - {DEBUG:Internal Chargepoint} - Angabe der Ströme in 0,01A-Schritten ist aktiviert.
2024-01-06 14:21:39,183 - {modules.internal_chargepoint_handler.clients:107} - {ERROR:Internal Chargepoint} - LP0 Device: /dev/ttyUSB0
2024-01-06 14:21:39,336 - {modules.internal_chargepoint_handler.clients:53} - {ERROR:Internal Chargepoint} - Modbus-ID der EVSE an LP0: 1
2024-01-06 14:21:40,405 - {modules.internal_chargepoint_handler.clients:67} - {ERROR:Internal Chargepoint} - Verbauter Zähler: <class 'modules.common.sdm.Sdm630'> mit Modbus-ID: 105
2024-01-06 14:21:40,772 - {modules.internal_chargepoint_handler.chargepoint_module:45} - {DEBUG:Internal Chargepoint} - Firmware-Version der EVSE: 18
2024-01-06 14:21:40,932 - {modules.common.evse:62} - {DEBUG:Internal Chargepoint} - Angabe der Ströme in 0,01A-Schritten ist aktiviert.
2024-01-06 14:21:41,092 - {modules.common.evse:62} - {DEBUG:Internal Chargepoint} - Angabe der Ströme in 0,01A-Schritten ist aktiviert.

[derNeueDet]

Upps, zu schnell gelesen mit der Version.

Zum Umschalt Problem kann ich nichts beitragen, vermute mal, dass das von EVCC entsprechend initiiert werden muss. Ist ja nur noch ein "dummer" Ladepunkt.

VG
Det

[aiole]

Mal manuell mit den Modbus-Registern der sw2 getestet?
https://openwb.de/main/wp-content/uploa ... -Pro-1.pdf
EVCC hat sw2 m.E. drin.

[schariwari]

Wie oben ja schon geschrieben: Wenn ich statt der selbst-installierten SD die mit dem original-Image reinstecke, dann KANN EVCC umschalten, also gehen ich davon aus, das es eben nicht an EVCC liegt.
Ausserdem kann die selbst-installierte auch nicht selber umschalten, wenn als "primary" konfiguriert ist. Siehe Screen shot oben. Also ist mein Schluss daraus: Es liegt auch nicht an der Modbus-Steuerung.

Mein logischer Schluss aus dem obigen: In dem Installationsscript ist irgendwas nicht drin, was im fertigen Image drin ist.