Einbindung von Modbus TCP

[Maexle]

Ich denke das sind die interessanten Zeilen...


SolarEdge Sunspec Modbus
https://www.solaredge.com/sites/defa...nical-note.pdf


40071 40072 1 I_AC_Current uint16 Amps AC Total Current value Gesamt Strom AC Ampere

40083 40084 1 I_AC_Power int16 Watts AC Power value AC Leistung Watt

40093 40094 2 I_AC_Energy_WH acc32 WattHours AC Lifetime Energy production Gesamt Energie Watt Stunden

40100 40101 1 I_DC_Power int16 Watts DC Power value DC Leistung Watt

40103 40104 1 I_Temp_Sink int16 Degrees C Heat Sink Temperature Temperatur Kühler ° C

40107 40108 1 I_Status uint16 Operating State Betriebszustand

[Maexle]

trovis plugin

modbus master plugin zu generieren, welches universell für viele geräte

Wenn ich das richtig sehe besteht keine Möglichkeit eine IP einzutragen --> oder spielt das keine Rolle da einfach der Port

modbus_port

str

Modbus-Port, über den die Trovis verbunden ist

ausgelesen wird? Aber ich gehe schwer davon aus, dass die IP vom WR angegeben werden muss, da sonst der RasPi nicht weiß wohin mit seiner Anfrage.

[Tom Bombadil]

Die Trovis ist über einen Adapter angebunden, der seriell auf LAN umsetzt - siehe Wiki. Der Adapter hat sehr wohl eine IP - die aber per socat-Unix-Befehl auf Deinem Raspi auf eine virtuelle Schnittstelle /dev/irgendwas gemapped wird. So kann das Plugin über /dev/irgendwas kommunizieren, ohne die spezifische IP des Adapters zu kennen - es muss nur noch der gleiche Port wie im Adapter eingestellt werden, wie von Dir gezeigt.

Wenn Dein Gerät von Hause aus eine Netzwerkschnittstelle hat (und nicht nur seriell, wie die Trovis), mapped socat eben auf diese IP. Fertig.

/tom

[Maexle]

Netzwerkschnittstelle hat

Laut Handbuch ist auf jeden Fall ein RJ45 Anschluss dran

Das Beispiel gibt an "/dev/ttytrovis" --> als Ersatz könnte 192.168.100.85 (oder was der WR hat für eine IP bekommt) eingetragen werden.

[Tom Bombadil]

Laut Handbuch ist auf jeden Fall ein RJ45 Anschluss dran

Ja, an der Trovis auch. Für die serielle Schnittstelle.
Merke: Der Stecker sagt manchmal nichts, aber auch rein garnichts über die Art der Schnittstelle aus.

Ansonsten: /lib/systemd/system/maexle.service

[Install]
WantedBy=default.target

[Unit]
Description=Maexle's neues Perpetuum Mobile
After=network.target
Before=smarthome.service

[Service]
PIDFile=/usr/local/smarthome/var/run/maexle.pid
ExecStart=/usr/bin/socat -s -ly pty,link=/dev/maexle,setuid=root,raw tcp:192.168.100.85:der_verwendete_port
User=root
Restart=always
RestartSec=10
Type=simple

Aktivierung wie im Wiki beschrieben. Schon kannste /dev/maexle benutzen, um auf 192.168.100.85: port zuzugreifen ...
/tom

[ivande]

ich habe ein universelles modbus_tcp-Plugin in meinem Kasten, noch ein paar Test's (mit meinem solaredge -Wechselrichter) dann kann ich es versuchsweise auf Git hochladen. Modbus-Register, DatenType,.. usw. werden über SH-Items konfiguriert:

mydevice:
    geraetename:
        type: str
        value: ''
        modBusAddress: 40030
        modBusUnit: '71'                 #(optional) default: 1  
        modBusDataType: 'string16'        #(optional) default: uint16  
        #modBusFactor: '1'               #(optional) default: 1
        modBusByteOrder: 'Endian.Little'   #(optional) default: 'Endian.Big'
        modBusWordOrder: 'Endian.Little'   #(optional) default: 'Endian.Big'
    leistung_AC:
        type: num
        value: '0'
        modBusAddress: 40048
        modBusUnit: '71'                 #(optional) default: 1  
        #modBusDataType: 'uint16'        #(optional) default: uint16  
        modBusFactor: '0.001'           #(optional) default: 1
        modBusByteOrder: 'Endian.Little'   #(optional) default: 'Endian.Big'
        modBusWordOrder: 'Endian.Little'   #(optional) default: 'Endian.Big'
    leistung_DC:
        type: num
        value: ''
        modBusAddress: 40050
        modBusUnit: '71'                 #(optional) default: 1  
        modBusDataType: 'int16'         #(optional) default: uint16  
        modBusFactor: '0.001'           #(optional) default: 1
        modBusByteOrder: 'Endian.Little'   #(optional) default: 'Endian.Big'
        modBusWordOrder: 'Endian.Little'   #(optional) default: 'Endian.Big'
    temperatur:
        type: num
        value: ''
        modBusAddress: 40052
        modBusUnit: '71'                 #(optional) default: 1  
        modBusDataType: 'float32        #(optional) default: uint16  
        #modBusFactor: '1'               #(optional) default: 1
        modBusByteOrder: 'Endian.Little'   #(optional) default: 'Endian.Big'
        modBusWordOrder: 'Endian.Little'   #(optional) default: 'Endian.Big'

[fuppy]

Hey Jungs, was ist den daraus geworden?

Maexle


Sorry ich bin nur noch selten hier:

https://github.com/chrpuf/smarthomeNG-DimplexWP

[ivande]

und das universelle modbus_tcp - Plugin hat es bereits in die neuen master Plugins (1.9) geschafft.

[tsb2001]

Genial!
Mit einem kleinen Wermutstropfen: Das Plugin unterscheidet nicht nach den ModBusUnits in den Items.

Ich habe hier grade die Fronius-Modbus-Tabellen zurechtgebogen und stoße da nämlich auf ein Problem:

Ich habe hier einen GEN24-Wechselrichter mit einem Smartmeter, welches über Modbus RTU mit dem Wechselrichter verbunden wird.
Der Wechselrichter nimmt die gesammelten (Smartmeter UND Wechselrichter) Daten und gibt die wiederum über Modbus TCP aus auf Port 502 aus.

Daher gibt 2 Tabellen mit ähnlichen Registerinhalten; jedoch einmal fürs Smartmeter und für den Wechselrichter separat.

Die Register vom Wechselrichter und vom Smartmeter sind nummernmäßig ähnlich, das SM hört allerdings auf die Adresse "200", der Wechselrichter hingegen auf die "1". Unterschieden werden diese Daten jedoch über die unterschiedliche ModBusUnit.

Beispiel: (Wechselrichter Modbus intern IP 192.168.178.70 Port 502)
WR Register 40073 mit der Unit 1 gibt den Strom eines Aussenleiters des Wechselrichters (an den Klemmen des WR) aus
WR Register 40073 mit der Unit 200 gibt den Strom eines Aussenleiters des Smartmeters (Netzbezug oder -einspeisung) aus

Wie kann man das lösen?
Baustein mit mehreren Instanzen (Unit 1 und 200) geht nicht, oder?

[Bonze]

Theoretisch müsste man das so machen, diese unit ist ja nix andres wie ne id, ist aber schon ne spezialgeschichte von dem hersteller...
andrerseits wenn man 2instanzen hat, dann kann man bestimmt nicht die gleiche ip nutzen d.h. man müsste noch nen parameter einführen ..

[tsb2001]

Ja, nur leider ist der Hersteller unwahrscheinlich stark am Markt vertreten.
Außerdem hatte ivande offensichtlich schon eine Lösung dafür, denn der hatte in seinem Post #21 auf dieser Seite ja schon Items definiert, die eine

modBusUnit: '71' #(optional) default: 1

als Unit mitgeben.
Daher hatte ich es auch damit versucht, aber leider ohne Erfolg. Scheinbar hat er es irgendwie implementiert; es ist aber scheinbar nicht Bestandteil des aktuellen Plugins.

[ivande]

modBusUnit musste ich leider aus den Items nehmen und in die Plugins-Konfig geben, da die unit-Adresse bereits beim Öffnen der Verbindung mitgegeben wird. Prinzipiell sollte es mit zwei Instanzen des Plugins möglich sein. Die Multiinstanz-Fähigkeit habe ich derzeit im Plugin jedoch nicht implementiert, da ich nur einen Modbus-Client (Wechselrichter) habe.

Derzeit müsste es möglich sein auf beide Units zuzugreifen, jedoch leider nicht gleichzeitig.

slaveUnit:
    type: num
    default: 1
    description:
        de: 'Slave-Addresse der zu lesenden Modbus-Einheit'
        en: 'slave-address of the Modbus-Unit to read'

Ich kann natürlich auf meinem Git-Fork eine Multiinstanz-Fähige Test-Version bereitstellen, damit ihr Multiinstanz testen könnt. Könnte allerdings bei Problemen mit der Ferndiagnose etwas umständlicher werden.

Vielleicht finde ich einen online Modbus-Server um die Multiinstanz zu testen.

Gruß Ivan

[Bonze]

Ich glaube das wird so nicht funktionieren, diese id wird ja irgendwo ins tcp paket reingewurschdelt, d.h. eigentlich müsste es eine default id geben und dann pro item die option ne andre id zu wählen .. da ja gleiche ip/port genutzt wird...

Lt wikipedia

Unit identifier is used with Modbus/TCP devices that are composites of several Modbus devices, e.g. on Modbus/TCP to Modbus RTU gateways. In such case, the unit identifier tells the Server Address of the device behind the gateway. Natively Modbus/TCP-capable devices usually ignore the Unit Identifier.

[tsb2001]

Hier hat das jemand mit Node Red und pymodbus umgesetzt. Leider verstehe ich in python nur Bahnhof:

Hello,
for pymodbus, some code snippets (replace your IP of course):

from pymodbus.client.sync
import ModbusTcpClient as ModbusClient
from pymodbus.payload import BinaryPayloadDecoder
from pymodbus.constants import Endian
client = ModbusClient('your IP address here', port=502)
client.connect()

Note, it shouldn't matter if you go via WLAN or LAN, just as long as your on same subnet.
then the following constants to address the inverter and meter:
(note you must address them in hex. my meter id is 240 and inverter is 1

INVERTER = 0x1 #1 in decimal
METER = 0xf0 #240 in decimal

then an example function:

def show_import_read():
    """ shows import energy count of meter
    register 40138
    2 registers
    value is Wh returns float32 """
    myresponse = client.read_holding_registers(40138-1, 2, unit=METER)
    decoder = BinaryPayloadDecoder.fromRegisters(myresponse.registers,byteorder=Endian.Big)
return decoder.decode_32bit_float()

You'll see that the read holding registers function take a parameter "unit", not the main connect function.
register list was obtained from Fronius website.
The decoder functions made life easier.
it's not easy to display the code neatly.

…nur falls es hilft…

[Bonze]

.. war quatsch, die id muss also per item gespeichert werden und beim auslesen mit genutzt werden, weil tcp eigentlich diese angabe nicht nutzt,.., aber in kombination von Modbus RTU und TCP kann sie genutzt werden , und das is genau hier der fall..