[gelöst] Solaredge ModBus TCP funktioniert nicht mehr nach OS Update

[dron72]

Hallo zusammen,

vorweg: ich nutze ein selbst installierte OpenWB (openWB Version: 1.9.244) auf einem Raspi4 in Verbindung mit einem Solaredge WR (SE17K) + AC gekoppelter Batterie. (EDIT: + go-E-Charger)
Hat bisher alles sehr gut funktioniert - gestern ist mir aufgefallen, dass die PV/EVU Werte nicht mehr dargestellt und berücksichtigt werden.

Nach ein wenig Fehlersuche stellt sich raus, dass ich wohl "Läuse und Flöhe" habe.
Läuse: Die DHCP IP des Wechselrichters hat sich geändert - hatte wohl vergessen, meiner Fritz!Box zu sagen, dass der immer dieselbe IP bekommen soll.
Also wieder auf einen festen Wert gesetzt und gut ist.

Flöhe: Geht trotzdem nicht - und hier vermute ich meine UpdateWut rund um den Jahreswechsel als schuldigen - ich habe da meinen Raspi4 auf das aktuelle Buster aktualisiert und in dem Rahmen vermutlich auch irgendwie an den Python Installationen gebastelt. Es laufen noch ein paar andere Dinge auf dem Raspi.

So, nun zu den Fakten.
Modbus TCP läuft auf Port 502 - ist per nmap geprüft offen.

Code: Alles auswählen

pi@raspi4:~ $ nmap 192.168.178.105 -p 502
Starting Nmap 7.70 ( https://nmap.org ) at 2022-02-14 17:09 CET
Nmap scan report for SolarEdgeWechselrichter17K.fritz.box (192.168.178.105)
Host is up (0.0018s latency).

PORT    STATE SERVICE
502/tcp open  mbap

Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds

Python habe ich 2 Versionen installiert: Python 2.7 und Python 3.7.

Wenn python standard 3.7 ist, steht im log:

Code: Alles auswählen

Traceback (most recent call last):
  File "/var/www/html/openWB/modules/bezug_solaredge/solaredge.py", line 7, in <module>
    import ConfigParser
ModuleNotFoundError: No module named 'ConfigParser'

Wenn python standard 2.7 ist, steht im log:

Code: Alles auswählen

2022-02-14 14:50:01: ##### cron5min.sh started ##### (LV0)
/var/www/html/openWB/runs/evsecheck: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or di
rectory
2022-02-14 14:50:03: ##### cron5min.sh finished ##### (LV0)

obwohl:

Code: Alles auswählen

pi@raspi4:~ $ ldconfig -p | grep libpython
	libpython3.7m.so.1.0 (libc6,AArch64) => /usr/lib/aarch64-linux-gnu/libpython3.7m.so.1.0
	libpython3.7m.so (libc6,AArch64) => /usr/lib/aarch64-linux-gnu/libpython3.7m.so
	libpython2.7.so.1.0 (libc6,AArch64) => /usr/lib/aarch64-linux-gnu/libpython2.7.so.1.0
	libpython2.7.so (libc6,AArch64) => /usr/lib/aarch64-linux-gnu/libpython2.7.so

und es findet sich auch ganz oft:

Code: Alles auswählen

AttributeError: 'ModbusIOException' object has no attribute 'registers'
Traceback (most recent call last):
  File "/var/www/html/openWB/modules/wr_solaredge/solaredgeall.py", line 39, in <module>
    raw = struct.pack('>HH', rr.getRegister(1), rr.getRegister(0))
AttributeError: 'ModbusIOException' object has no attribute 'getRegister'
Traceback (most recent call last):
  File "/var/www/html/openWB/modules/bezug_solaredge/solaredge.py", line 17, in <module>
    value1 = resp.registers[0] 

Jetzt bin ich erstmal am Ende - hat noch irgendwer eine Idee, wie ich stück für Stück eingrenzen könnte?
Welche Python Version braucht OpenWB? Liegt das überhaupt daran, oder habe ich noch ein anderes Problem?

Nächster Schritt wäre für mich, irgendwie ein mini Python Script zu basteln um mal Testweise Modbus Kommunikation mit dem Wechselrichter durchzuführen - oder alternativ den Raspi neu aufzusetzen.

[derNeueDet]

OpenWB verwendet Python2 und Python3. Standard sollte sein, dass Python --> Python2 zeigt und Python3 mit python3 aufgerufen wird.
Da du eine selbst installierte openWB auf einem Raspi OHNE EVSE betreibst, muss ja eigentlich evsecheck schief gehen. Ich würde mal sagen, deine Ladepunkt Konfiguration ist daneben.

Holst Du Daten aus dem Solaredge noch über andere Devices IOBroker, HomeAssistant .... ab? Solaredge mag es nicht, wenn mehrere Clients am Modbus nuckeln.

VG
Det

[derNeueDet]

Evtl. Kommt bei dir auch noch das ins Spiel:
viewtopic.php?p=57708#p57708

VG
Det

[dron72]

Danke für die Ideen.

Ich habe noch einen goE Charger angebunden - der funktioniert auch - auch jetzt noch. Zumindest was an/aus, Laden bis Ladelimit, Regelung des Ladestroms etc. angeht.

Am Modbus "nuckelt" eigentlich nur OpenWB - habe um das auszuschließen auch die IP geändert - die ich vorher genutzt habe.

Ein Telnet auf Port 502 bei der Wechselrichter IP scheitert, solange der OpenWB Raspi läuft - geht aber, wenn der runter gefahren ist.
Vermutlich macht also OpenWB einen erfolgreichen Connect auf den Modbus Port und blockiert diesen. (Kann ich das irgendwie prüfen).

Oder verschiedene OpenWB Komponenten blockieren sich bei mir gegenseitig? Falsche Konfiguration? Wobei ich da bewusst nichts geändert habe (außer eben der IP Adresse...)
Das hier auch noch gefunden im openwb.log

Code: Alles auswählen

Traceback (most recent call last):
  File "/var/www/html/openWB/modules/wr_solaredge/solaredgeall.py", line 38, in <module>
    rr = client.read_holding_registers(62852, 2, unit=slave1id)
  File "/usr/local/lib/python2.7/dist-packages/pymodbus/client/common.py", line 114, in read_holding_registers
    return self.execute(request)
  File "/usr/local/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 108, in execute
    raise ConnectionException("Failed to connect[%s]" % (self.__str__()))
pymodbus.exceptions.ConnectionException: Modbus Error: [Connection] Failed to connect[ModbusTcpClient(192.168.178.105:502)]
Traceback (most recent call last):
  File "/var/www/html/openWB/modules/wr_solaredge/solaredgeall.py", line 39, in <module>
    raw = struct.pack('>HH', rr.getRegister(1), rr.getRegister(0))
AttributeError: 'ModbusIOException' object has no attribute 'getRegister'
Traceback (most recent call last):
  File "/var/www/html/openWB/modules/bezug_solaredge/solaredge.py", line 16, in <module>
    resp= client.read_holding_registers(40206,5,unit=slaveid)
  File "/usr/local/lib/python2.7/dist-packages/pymodbus/client/common.py", line 114, in read_holding_registers
    return self.execute(request)
  File "/usr/local/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 108, in execute
    raise ConnectionException("Failed to connect[%s]" % (self.__str__()))
pymodbus.exceptions.ConnectionException: Modbus Error: [Connection] Failed to connect[ModbusTcpClient(192.168.178.105:502)]

EDIT:
Gerade mal getestet - IP auf eine falsche Adresse gestellt - bei jedem Call Fehlermeldung, dass Connect nicht möglich ist.
IP wieder auf die .105 (=richtige) zurückgesetzt, dann kommen "nur noch" die bekannten Meldungen:

Code: Alles auswählen

AttributeError: 'ModbusIOException' object has no attribute 'getRegister'
Traceback (most recent call last):
  File "/var/www/html/openWB/modules/bezug_solaredge/solaredge.py", line 17, in <module>
    value1 = resp.registers[0] 
AttributeError: 'ModbusIOException' object has no attribute 'registers'
Traceback (most recent call last):
  File "/var/www/html/openWB/modules/wr_solaredge/solaredgeall.py", line 39, in <module>
    raw = struct.pack('>HH', rr.getRegister(1), rr.getRegister(0))
AttributeError: 'ModbusIOException' object has no attribute 'getRegister'
Traceback (most recent call last):
  File "/var/www/html/openWB/modules/bezug_solaredge/solaredge.py", line 17, in <module>
    value1 = resp.registers[0] 

Der Wechselrichter ist auch per LAN angeschlossen - hat aber die aktuellste Firmware drauf.

Also irgendwie klemmts und ich würde gerne ein wenig besser die Zusammenhänge verstehen, um mich Stück für Stück durchzuwuseln.
Vielleicht versuche ich mal mit anderer Software die Modbus Schnittstelle rudimentär auszulesen (um zu schauen, ob der WR "sauberes" Modbus spricht). Gibts dafür Vorschläge?

Und bzgl. Python 2 - nur um sicher zu gehen: Python 2.7 ist für OpenWB ok? Oder wird ein Python 2.4 erwartet?

[derNeueDet]

Nee, 2.7 passt.

Aber du bist noch auf Buster oder hast du durch den Update unbewusst oder absichtlich auf Bullseye aktualisiert?

VG
Det

[dron72]

Warum er die Lib nicht lädt weiß ich inzwischen. Ich bin auf einem 64Bit System

Code: Alles auswählen

pi@raspi4:/usr/lib $ file /lib/systemd/systemd
/lib/systemd/systemd: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=18ce50ef03a7482735416b991ab1dd7a5fc93997, stripped

Aber evsecheck ist ein ELF 32-bit LSB executable.

Code: Alles auswählen

pi@raspi4:/usr/lib $ file /var/www/html/openWB/runs/evsecheck 
/var/www/html/openWB/runs/evsecheck: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=4e80bdf8e7edeb2b2470db1c69fd2fbc891dd37c, not stripped

Ob ich irgendwie 32bit Python Libs installieren kann muss ich mal recherchieren.

Die installierten sind jedenfalls 64 Bit:

Code: Alles auswählen

pi@raspi4:/usr/lib $ file /usr/lib/aarch64-linux-gnu/libpython2.7.so.1.0
/usr/lib/aarch64-linux-gnu/libpython2.7.so.1.0: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=9575700a6d2110199562cb9cc40233b421715e7c, stripped

Und ja, ich denke, ich bin auf buster:

Code: Alles auswählen

pi@raspi4:/usr/lib $ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Code: Alles auswählen

pi@raspi4:/usr/lib $ uname -a
Linux raspi4 5.10.63-v8+ #1496 SMP PREEMPT Wed Dec 1 15:59:46 GMT 2021 aarch64 GNU/Linux

Code: Alles auswählen

pi@raspi4:/usr/lib $ cat /etc/apt/sources.list
deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free
deb http://deb.debian.org/debian buster-updates main contrib non-free

[derNeueDet]

Du bist auf ei em Raspi?

Buster als 64 Bit kenne ich nicht.

Bullseye gibt es seit ein paar Tagen als 64-Bit Stable.

Ich glaub da hast du dir irgendwie was wildes zusammen gepatcht.

Da musst du alleine durch.

VG
Der

[dron72]

Danke für Deine Mühen und Deinen Input.

Raspian/RaspberrypiOS gibt es für den 64Bit Raspi4 schon ne Weile auch als Buster und wenn ich nicht total daneben liege, hatte ich schon immer ein 64Bit OS auf der Kiste.

Ich wusele mich da schon irgendwie durch. Zur Not halt reinstall.

Die fehlende Library konnte ich problemlos mit

Code: Alles auswählen

sudo apt-get install libpython2.7:armhf

nachinstallieren - jetzt meckert evsecheck nicht mehr - im strace sieht man aber, dass ihm noch weiter 32Bit Python Libs/module fehlen. Vielleicht ist das ein Ansatzpunkt.

BTW: Kann man OpenWB irgendwie geordnet stoppen - ohne den Computer runterzufahren? Alle Cronjobs rauszunehmen und die gestarteten Tasks abzuschießen fühlt sich nicht so richtig gut an

[derNeueDet]

Nimm die Cronjobs aus der crontab und warte ein bisschen, dann sollten die Prozesse sich von alleine beenden.
Die Regel.sh Prozesse Loipen nicht sondern beenden nach dem Durchlauf, daher werden sie jede Minute (im 10s Takt) neu angestoßen.

VG
Det

[yankee]

Gerade mal getestet - IP auf eine falsche Adresse gestellt - bei jedem Call Fehlermeldung, dass Connect nicht möglich ist.
IP wieder auf die .105 (=richtige) zurückgesetzt, dann kommen "nur noch" die bekannten Meldungen:

Code: Alles auswählen

AttributeError: 'ModbusIOException' object has no attribute 'getRegister'
[..]

In der aktuellen Nightly ist das SolarEdge-Modul komplett überarbeitet. Es ist zwar unwahrscheinlich, dass das dein Problem löst, aber du müsstest zumindest eine aussagekräftigere Fehlermeldung bekommen.