Neue Versionen und Support zum Modbus-Modul

Begonnen von StefanStrobel, 20 August 2017, 12:11:08

Vorheriges Thema - Nächstes Thema

McBasil

Hallo Stefan,

bei der Definition von Datenpunkten eines Modbusgerätes besteht ja die Möglichkeit, den ausgelesenen Registerwerten über das Attribut map den ausgelesenen Code in verständliche Sprache zu konvertieren. Bei Status- oder Störmeldungen wird die map so umfangreich, dass, wenn alles in einer Zeile untergebracht werden soll, die Übersicht verloren geht. Aus meiner Sicht ist es wünschenswert jede Paarung Schlüssel : Text, in eine neue Zeile schreiben zu können. Das führt jetzt aber zu unschönen Effekten bei der Konvertierung der Codes in Text.
Die Steuerzeuchen \t \n ect. ,die die Lesbarkeit  im Definitionsfile ermöglichen, werden zum Bestandteil der map. Stehen die Steuerzeichen bei den codes, dann werden diese nicht gematched oder die Steuerzeichen sind Bestandteil der Texte geworden, dann sieht deren Darstellung auf dem Bildschirm unmöglich aus.

Hier ein Beispiel der Datenpunktdefinition mit den möglichen vorgegebenen Sperrursachen:

'h104' => { reading => 'wp_dis_Waermepumpe_Sperre',
name => 'Waermepumpe Sperre',
unpack => 'n',
                    map => '0:keine Sperre,
2:Volumenstrom,
5:Funktionskontrolle,
6:Einsatzgrenze HT,
7:Systemkontrolle,
8:Verzögerung Umschaltung Kühlen,
9:Pumpenvorlauf,
10:Mindeststandzeit,
11:Netzbelastung,
12:Schaltspielsperre,
13:Warmwasser Nacherwärmung,
14:Regenerativ,
15:EVU-Sperre,
16:Sanftanlasser,
17:Durchfluss,
18:Einsatzgrenze Wärmepumpe,
19:Hochdruck,
20:Niederdruck,
21:Einsatzgrenze Wärmequelle,
23:System Grenze,
24:Last Primärkreis,
25:Sperre Extern,
33:EvD Initialisierung,
34:2.Wärmeerzeuger freigegeben,
35:Störung,
36:Pumpenvorlauf,
37:Mindeststandzeit,
38:Netzbelastung,
39:Schaltspielsperre,
40:Einsatzgrenze Wärmequelle,
41:Sperre Extern,
42:2.Wärmeerzeuger freigegeben,
43:Störung',
poll => 1,
},



Durch Einfügen von     $map =~ s/\s+/ /g;       in 98_Modbus.pm sind diese Effekte verschwunden:

.......
sub Modbus_MapConvert($$$;$)
{
    my ($hash, $map, $val, $reverse) = @_;
    my $name = $hash->{NAME};

    $map =~ s/\s+/ /g; # substitute all \t \n etc. by one space only
   
    if ($reverse) {
        $map =~ s/([^, ][^,\$]*):([^,][^,\$]*),? */$2:$1, /g;   # reverse map
    }
    # spaces in words allowed, separator is ',' or ':'
......


Kannst Du Dir vorstellen, diese Änderung ins 98_Modbus.pm zu implementieren?

Gruß Basil

StefanStrobel

Hallo Basil,

ich habe es mal in MapConvert und MapToHint eingebaut und hoffe, dass es keine Seiteneffekte hat.
Eigentlich sollte bisher niemand mit Maps, die mehrere aufeinanderfolgende Whitespaces enthalten, arbeiten müssen ...

Teste doch mal ob es bei Dir so passt, dann riskiere ich den check in :-)

Gruss
   Stefan

Rudy

Versuche gerade das Modbus-Modul im Zusammenhang mit dem Modul ModbusSDM630M zu nutzen. Das Einbinden funktioniert grundsätzlich auch. Daten vom Stromzähler kommen grundsätzlich in FHEM beim SDM630-Modul an. Sobald ich aber meinen SDM630-Stromzähler mit Fhem verbinde wechselt das Modbus-Modul ständig (alle 2 Sekunden) in den Status disconnected und wieder zurück.

Die Verbindung zwischen dem SDM630 und meinem FHEM-Raspi erfolgt über den Digitus DA-70157 USB-to-Serial-RS485-Converter. Das Kabel ist ein 4-adriges Telefonkabel (von welchem nur zwei Adern und Ground genutzt werden) mit 6,5 m Länge. An beiden Enden habe ich bei jedem Kabel (außer Ground) einen 120-Ohm-Widerstand eingelötet.

Kann mir jemand einen Tipp geben, woran es liegen könnte? Ich vermute, dass noch weitere Angaben meinerseits fehlen. Da ich aber nicht sicher weiß welche, einfach bescheid sagen und ich liefere die selbstverständlich gerne nach.

McBasil

#303
Hallo Stefan,

die Änderung im MapConvert läuft bei mir schon seit einer Woche und verursacht keine Probleme. 

Gruß Basil

McBasil

#304
Hallo Stefan,

Mit MapToHint ist wohl nicht die Hintliste sondern wahrscheinlich diese Konstruktion gemeint?:

'h131' => { reading => 'Sprache',
name => 'Sprache',
unpack => 'n',
                    map => '0:Deutsch,
1:English,
2:Francais,
3:Italiano,
4:Nederland,
5:Portugues,
6:Polski,
7:Svenska,
8:Slovensko,
9:Espanol,
10:Cesky,
11:Suomi,
12:Norsk,
13:Dansk',
poll => 1,
polldelay => 60,
set => 1,
},

Die Liste wird korrekt umgesetzt und erscheint als Klappmenu. Nach Auswahl einer Sprache und anschließendem set erscheint die gewählte Sprache.

Gruß Basil

StefanStrobel

Hallo Rudy,

Bitte setze doch verbose für beide Devices auf 5 und poste das Log, so dass man sieht was wirklich passiert.

Zitat von: Rudy am 12 Mai 2019, 12:37:25
Die Verbindung zwischen dem SDM630 und meinem FHEM-Raspi erfolgt über den Digitus DA-70157 USB-to-Serial-RS485-Converter. Das Kabel ist ein 4-adriges Telefonkabel (von welchem nur zwei Adern und Ground genutzt werden) mit 6,5 m Länge. An beiden Enden habe ich bei jedem Kabel (außer Ground) einen 120-Ohm-Widerstand eingelötet.

Das klingt nicht gut. Wie genau hast Du die Widerstände eingelötet?
Kannst Du einen Verdrahtungsplan posten?

Gruß
    Stefan

Rudy

Hallo Stefan.
Zitat von: StefanStrobel am 15 Mai 2019, 10:49:23
Bitte setze doch verbose für beide Devices auf 5 und poste das Log, so dass man sieht was wirklich passiert.

Das klingt nicht gut. Wie genau hast Du die Widerstände eingelötet?
Kannst Du einen Verdrahtungsplan posten?
Nach meinem Post hatte ich das Modbus Gateway wegen der ständigen disconnects von meinem FHEM-Pi getrennt. Um jetzt die gewünschten Daten liefern zu können habe gestern ich die Verbindung wieder hergestellt und nun gab keine disconnects des Modbus-Moduls mehr. Keine Ahnung woran das nun gelegen haben mag. Vielleicht hat ein zwischenzeitlicher Neustart des ganzen Systems da für Besserung gesorgt.

Ganz in Ordnung ist die Verbindung aber noch nicht. So gibt es im Log noch einige Timouts. Nachfolgend einige Beispiele.

2019.05.17 16:59:56 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 10, len 10 for device Stromzaehler reading System_Type (getUpdate), queued 8.01 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 16:59:58 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 36, len 8 for device Stromzaehler reading System_Power__W (getUpdate), queued 10.01 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:00 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 0, len 10 for device Stromzaehler reading Demand_Time__minutes (getUpdate), queued 12.02 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:02 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 40, len 40 for device Stromzaehler reading CosPhi_L3__grd (getUpdate), queued 14.03 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:04 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 0, len 40 for device Stromzaehler reading Voltage_L1__V (getUpdate), queued 16.03 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:06 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 334, len 30 for device Stromzaehler reading THD_Voltage_L1_L2__prz (getUpdate), queued 18.04 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:08 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 240, len 30 for device Stromzaehler reading THD_Current_L1__prz (getUpdate), queued 20.05 secs ago, sent 2.01 secs ago, read buffer empty
und
2019.05.17 17:09:21 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 334, len 30 for device Stromzaehler reading THD_Voltage_L1_L2__prz (getUpdate), queued 11.45 secs ago, sent 2.14 secs ago, read buffer empty
2019.05.17 17:09:23 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 0, len 10 for device Stromzaehler reading Demand_Time__minutes (getUpdate), queued 13.61 secs ago, sent 2.03 secs ago, read buffer empty
2019.05.17 17:09:25 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 200, len 40 for device Stromzaehler reading Voltage_L1_to_L2__V (getUpdate), queued 15.71 secs ago, sent 2.09 secs ago, read buffer empty
2019.05.17 17:09:27 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 0, len 40 for device Stromzaehler reading Voltage_L1__V (getUpdate), queued 17.72 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:09:29 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 20, len 10 for device Stromzaehler reading Modbus_Node_adr (getUpdate), queued 19.72 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:09:31 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 88, len 2 for device Stromzaehler reading Relay2_Energy_Type (getUpdate), queued 21.73 secs ago, sent 2.01 secs ago, read buffer empty

Und nachdem ich mich nun heute zurückmelden wollte und die Verbindung zum SDM630 erneut hergestellt habe kommen aktuell garkeine neuen Daten mehr an. Stattdessen gibt es reihenweise Timeouts wie schon oben geposted.

Die Verkabelung und wie ich die Widerstände eingelötet habe, habe ich versucht in dem von dir gewünschten Verdrahtungsplan darzustellen (s. Anhang). Ich hoffe, das entspricht deinen Vorstellungen. Ist das erste mal, dass ich so ein Programm zur Erstellung genutzt habe.

Ist es evtl. sinnvoller, nur an einer Seite die Widerstände zu verwenden?

Gruß Rudy

StefanStrobel

Hallo Rudy,

das mit dem Abschlusswiderstand hast Du falsch verstanden.
Der muss zwischen A und B.

Schau mal z.B. diese Diskussion an:
https://www.sps-forum.de/feldbusse/44809-abschlusswiderstaende-fuer-modbus-rs485.html
oder
https://www.janitza.de/kommunikation-ueber-die-rs485-schnittstelle.html

Viele USB-RS485-Adapter haben den schon drin. Durch zusätzliche Parallelschaltungen kann dann ggf. gar nichts mehr übertragen werden.

Gruss
    Stefan

ahermann86

#308
Hallo,

ich wusste nicht so Recht wohin damit aber es geht um den Modbus:

Ich habe vor kurzem ein FHEM Update ausgeführt und nun wird mein Log damit gefüllt:


2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request temperature
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request humidity
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Abluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Abluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request temperature
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request humidity
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Zuluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Zuluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 23.1 to temperature
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 45.1 to humidity
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request temperature
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request humidity
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Abluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Abluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request temperature
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request humidity
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Zuluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Zuluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 44.8 to humidity
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 23.2 to temperature
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: ParseObj assigns value 47 to humidity
2019.07.03 09:23:49 4: Mod_Lueftung_Sensor_Zuluft: ParseObj assigns value 20.5 to temperature
2019.07.03 09:28:29 1: Das diBMode hat ausgeloest. Sommer mode 0 ueberschuss 490.181516
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request temperature
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request humidity
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Abluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Abluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request temperature
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request humidity
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Zuluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Zuluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 23.2 to temperature
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 45.1 to humidity
2019.07.03 09:33:50 4: Mod_Lueftung_Sensor_Zuluft: ParseObj assigns value 45.8 to humidity


Die Modbus Sensoren (TYPE: ModbusAttr) werden alle 10 Minuten gepollt (INTERVAL: 600).
Das Verbose in global steht auf 3. Das Verbose in dem jeweiligen ModbusAttr Device steht auf 4... Werte aus den jeweils gelesenen zwei Registern kommen an. Was ist hier das Problem?


Gruß
Axel

Wzut

Zitat von: ahermann86 am 03 Juli 2019, 09:40:49
Das Verbose in dem jeweiligen ModbusAttr Device steht auf 4
das ist dein Problem :) , gehe runter auf 3 und es wird Ruhe sein ....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

pejonp

LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Nestor

I receive following warning upon startup:
PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_Modbus.pm line 2956, <$fh> line 1444.


I suppose there are some comment markers missing in the source:
--- - 2019-07-31 20:48:23.650336998 +0200
+++ /srv/fhem/FHEM/98_Modbus.pm 2019-07-31 20:46:11.724671421 +0200
@@ -2953,8 +2953,8 @@
     my $qlen   = ($ioHash->{QUEUE} ? scalar(@{$ioHash->{QUEUE}}) : 0);
     
     #Log3 $name, 4, "$name: DoRequest called from " . Modbus_Caller() . " with $type$adr, objLen $objLen / reqLen " .
-        ($reqLen ? $reqLen : "-") . " to id $devId, op $op, qlen $qlen" .
-        ((defined($v1) && $op eq 'write') ? ", value hex " . unpack ('H*', $v1) : "");
+        #($reqLen ? $reqLen : "-") . " to id $devId, op $op, qlen $qlen" .
+        #((defined($v1) && $op eq 'write') ? ", value hex " . unpack ('H*', $v1) : "");
     $reqLen = $objLen if (!$reqLen);            # combined reqLen from GetUpdate or scans

     return if (ModbusLD_CheckDisable($hash));   # returns if there is no io device


laserrichi

Hallo, mal eine Frage zu lesen und schreiben von 2 Registern.

Ich habe im Gerät 2 aufeinanderfolgende Register.
0x3312 Total Generated energy L     KWH
0x3313 Total Generated energy H
angenommen ich lese die mit  len 2  ohne das ich noch weitere Parameter wie revRegs mitgebe, wäre dann das ganze richtig ?
ohne das 2te Register habe ich ja schon alles, da ich noch nicht so viele kWh  habe.
In der Beschreibung steht als Beispiel folgendes:

For the data with the length of 32 bits, such as power, using the L and H registers represent the low andhigh 16 bits value,respectively. e.g.The charging input rated power is actually 3000W, multiples of 100 times,then the value of 0x3002 register is 0x93E0 and value of 0x3003 is 0x0004


mein Aktueller code sieht so aus:
attr Solarlader obj-i13074-expr $val=($val/100)." kWh"
attr Solarlader obj-i13074-len 2
attr Solarlader obj-i13074-poll 1
attr Solarlader obj-i13074-reading EnergieGewinnTotal


Dann wäre da noch ein 3fach Register mit Datum und Uhrzeit was ich bisher einzeln wie folgt auslese:

attr Solarlader obj-h36883-expr (( sprintf("Minute:%02d Sekunde:%02d", (( $val >> 8 )),(( $val & 0xff )) ) ))
attr Solarlader obj-h36883-poll 1
attr Solarlader obj-h36883-reading clock1
attr Solarlader obj-h36883-set 1
attr Solarlader obj-h36884-expr (( sprintf("Stunde:%02d Tag:%02d", (( $val & 0xff )),(( $val >> 8 )) ) ))
attr Solarlader obj-h36884-poll 1
attr Solarlader obj-h36884-reading clock2
attr Solarlader obj-h36884-set 1
attr Solarlader obj-h36885-expr (( sprintf("Monat:%02d Jahr:%02d", (( $val & 0xff )),(( $val >> 8 )) ) ))
attr Solarlader obj-h36885-poll 1
attr Solarlader obj-h36885-reading clock3
attr Solarlader obj-h36885-set 1


Am liebsten wäre mir das mit len 3 z.b. zu lesen, so das man auch Datum und Uhrzeit setzen kann, denn leider läuft die Uhr ganz schön auseinander.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Wzut

Zitat von: laserrichi am 30 August 2019, 16:41:47
Ich habe im Gerät 2 aufeinanderfolgende Register.
0x3312 Total Generated energy L     KWH
0x3313 Total Generated energy H
angenommen ich lese die mit  len 2  ohne das ich noch weitere Parameter wie revRegs mitgebe, wäre dann das ganze richtig ?
IMHO ja, bei meinem WR belegen fast alle Werte zwei Register. Um da viel Tipparbeit zu sparen habe ich gleich oben

attr 8000TL dev-h-defExpr $val & 0x1FFFFFFF
attr 8000TL dev-h-defLen 2
attr 8000TL dev-h-defPoll 1
attr 8000TL dev-h-defUnpack N

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

noname41

Hallo  zusammen,

ich versuche gerade meinen ETA-Heizkessel per Modbus/TCP einzubinden.

Ich habe hierzu das Modul ModbusAttr verwendet. Er zeigt auch "opened" als Status an. Leider bekomme ich aber keine Werte.
Register ist als 1000 festgelegt. Gefunden habe ich hierzu folgende Anleitungen (leider nur für die Loxone)
https://www.loxforum.com/forum/hardware-zubeh%C3%B6r-sensorik/60229-miniserver-go-modbus-tcp

hier meine Einstellungen:

defmod etamod ModbusAttr 1 60 192.168.XX.XX:502 TCP
attr etamod userattr IODev obj-h1000-poll obj-h1000-reading obj-h1000-type obj-i1000-len
attr etamod obj-h1000-poll 1
attr etamod obj-h1000-reading Ladezustand
attr etamod obj-i1000-len 2
attr etamod verbose 5


kann mir da jemand einen Tipp geben?

Danke!
LG