Einbindung von Modbus TCP

[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.

[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

[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.

[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]

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?

[ivande]

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

[fuppy]

Hey Jungs, was ist den daraus geworden?

Maexle


Sorry ich bin nur noch selten hier:

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

[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'

[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

[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]

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]

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.

[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

[Tom Bombadil]

'I_AC_Power' : 40083, # 40084: AC Power Value, int16
'I_AC_Power_SF' : 40084, # 40085: AC Power Scale Factor, int16

Result = Value + ScaleFaktor

Ja, in dem Fall dann wohl sowas hier:

'I_AC_Power_SF':
   type: num

'I_AC_Power':
    type: num

'I_AC_Power_final':
    type: num
    eval: ..I_AC_Power_SF() * ..I_AC_Power()
    eval_trigger: ..I_AC_Power_SF, ..I_AC_Power

Wenn das häufiger vorkommt, kann man z.B. im Trovis-Plugin auch einfach eine Spezialbehandlung für diese 'Sonderlocken' definieren.

/tom

[ivande]

die kosalmodbus und ksemmodbus sind bereit recht universell aufgebaut, und man könnte mit dem selben Prinzip andere Gerätschaften adaptiert. Für das solaredge - Plugin geht das leider nicht so ganz universell, da dort einige Werte aus zwei Registern berechnet werden müssen: in einem Register steht der Wert und im anderen der Scale-Faktor. (dies könnte natürlich dann über die SH-Items mit eval,.. verrechnet werden)

'I_AC_Power' : 40083, # 40084: AC Power Value, int16
'I_AC_Power_SF' : 40084, # 40085: AC Power Scale Factor, int16

Result = Value + ScaleFaktor