Neue Versionen und Support zum Modbus-Modul

[eisler]

Hallo Stefan,

Aus dem Datenblatt: https://download.beckhoff.com/download/document/io/bus-terminals/bk9000de.pdf

"Der Watchdog ist im Auslieferungszustand aktiviert. Nach dem ersten Schreibtelegramm wird der Watchdog scharf geschaltet und bei jedem empfangenden Telegramm dieses Teilnehmers getriggert. Andere Teilnehmer haben auf den Watchdog keinen Einfluss. Eine zweite Möglichkeit, die eine schärfere Bedingung des Watchdogs darstellt, ist, dass der Watchdog nur nach jedem Schreibtelegramm getriggert wird."

Bei Watchdog Fehler werden nicht nur die Ausgänge auf Null gesetzt. Der BK9000 bleibt einfach stehen und ich muss ihn neu booten um ihn anzusprechen.

Grüße
Stephan

[McBasil]

Guten Abend Stefan,

ganz herzlichen Dank für das Update. Jetzt laufen die Zugriffe auf meine Wärmepumpe mit der von Dir vorgeschlagenen Definition, die übermittelten Werte erscheinen plausibel.
Solltest Du am Logfile interessiert sein, kann ich es gerne nachreichen.

Wäre für Dich ein Test Deines Modbus im passiven Modus mit einem iobroker als Master von Interesse? Ich wäre gerne bereit diesen durchzuführen.

Gruß Basil

[StefanStrobel]

Hallo Basil,

Du bist da offenbar über einen Bug gestolpert, der schon lange im Modul ist und nur normalerweise nicht auffällt, da DevIO von sehr vielen anderen Modulen genutzt wird und in der Regel schon geladen ist. In Deiner Konstellation wurde DevIO aber zu spät geladen.

Wenn Du den passiven Modus testen könntest wäre das hilfreich. Ich vermute dass den außer mir mir noch kaum jemand getestet hat.

Gruss
   Stefan

[pejonp]

Hallo Stefan,

wie kann ich am besten in einem Modul verschieden Modbus-Wechselrichter (SunSpec ?)  abfragen, da doch einige Unterschiede sind.

SolarEdge SE5K -> https://forum.fhem.de/index.php/topic,80767.msg853967.html#msg853967
KACO -> https://forum.fhem.de/index.php/topic,98581.msg919950.html#msg919950
Kostal Plenticore plus  -> https://forum.fhem.de/index.php/topic,92281.0.html

Sollte erst der ganze Block ausgelesen werden und später aufgeteilt werden (ExprMppt).

Code Auswählen Erweitern


"h40020" =>  {       'reading' => 'Block_C_Model',
                                  'type' => 'VT_String',
                                  'expr' => 'ExprMppt($hash,$name,"C_Model",$val[0],0,0,0,0)', # conversion of raw value to visible value


Oder kann man beim "_Initialize" eine Auswahl/Abfrage einbauen. Vorher muss das Model festlegen oder mit übergeben werden.
z.B.
SEdge SunSpecWR 3 60 192.168.0.23:502 RTU  SolarEdge

KACO SunSpecWR 3 60 192.168.0.23:502 RTU  KACO

Kostal SunSpecWR 3 60 192.168.0.23:502 RTU  Kostal

Code Auswählen Erweitern


sub
SolarEdge_Initialize($)
{
    my ($hash) = @_;

  require "$attr{global}{modpath}/FHEM/98_Modbus.pm";
    require "$attr{global}{modpath}/FHEM/DevIo.pm";

$hash->{DefFn}     = "SolarEdge_Define";
$hash->{AttrFn} = "SolarEdge_Attr";

...Abfrage (MODEL)

$hash->{parseInfo}  = \%SolarEdgeparseInfoM0; # defines registers for this Modbus Defive
$hash->{deviceInfo} = \%SolarEdgedeviceInfoM0; # defines properties of the device like

...(MODEL1)

$hash->{parseInfo}  = \%SolarEdgeparseInfoM1; # defines registers for this Modbus Defive
$hash->{deviceInfo} = \%SolarEdgedeviceInfoM1; # defines properties of the device like

... END-Auswahl

  ModbusLD_Initialize($hash); # Generic function of the Modbus module does the rest



Vielleicht hast du ja eine Idee. Vielen Dank.

Jörg

[StefanStrobel]

Hallo Jörg,

Initialize wird beim Laden des Moduls aufgerufen. Da hast Du noch keine Informationen aus dem Define oder aus Attributen.
Das ist also der falsche Platz.
Ein weiteres Problem ist dass der parseInfo-Hash ja im Modul-Hash steht und deshalb für alle Geräte eines Moduls identisch ist.

Ich könnte das Basis-Modul so erweitern, dass der parseInfo Hash auch im Geräte-Hash stehen kann und nicht nur im Modul-Hash. Der Geräte-Hash hätte dann Priorität. Dann könnte man im Define einen zusätzlichen optionalen Parameter einbauen, der dann eine von mehreren parseInfo-Vorlagen aus dem Modul-Hash in den Geräte-Hash kopiert.

Oder man könnte das auch dynamisch zur Laufzeit setzen, nachdem die Geräte-Spezifikation aus einem immer gleichen Register geladen wurde. Dafür müsste ich aber auch eine Art Setup-Funktion im Modul vorsehen, die vor allen anderen Abfragen erst mal den Geräte-Typ ermittelt und dann parseInfo setzt. Das müsste aber auch wieder asynchron erfolgen  ...

Vielleicht komme ich in den nächsten Tagen mal dazu beide Features im Basis-Modul einzubauen.

Gruss
   Stefan

[StefanStrobel]

Hallo,

anbei eine neue Version des Modbus-Basis-Moduls zum Testen.
Die Änderungen sind sind nur für Autoren von eigenen Modulen auf Basis von Modbus relevant:

1)  Die Hashes für die Definition der Modbus-Objekte (parseInfo und deviceInfo) können jetzt auch in den Device-Hash gelegt werden. Dort haben sie dann Priorität gegenüber den Daten im Modul-Hash. Damit kann ein Modul mehrere Varianten eines Geräts mit abweichender Register-Belegung unterstützen und die passende Definition zur Laufzeit festlegen.

Beispiel aus einer Funktion oder Expression heraus:

Code Auswählen Erweitern


if (!$logHash->{ModelChosen}) {
# select model and correct parseInfo
$logHash->{parseInfo} = \%SET10parseInfo2;
$logHash->{ModelChosen} = 1;
$logHash->{".updateSetGet"} = 1;
Log3 $name, 3, "$name: ModbusReadingsFn set model to XY";
}


2) Man kann eine "ModbusReadingsFn" Funktion einklinken, die immer aufgerufen wird, bevor das Basis-Modul die aus einer Modbus-Response extrahierten Werte in Readings schreibt. Diese Funktion wird mit dem Device-Hash, dem Namen des Readings und dem Wert aufgerufen.
Wenn die Funktion 1 zurückgibt, wird danach vom Basis-Modul kein readingsBulkUpdate aufgerufen.

Beispiel:

Code Auswählen Erweitern


#####################################
sub ModbusSET_Initialize($)
{
    my ($modHash) = @_;
    require "$attr{global}{modpath}/FHEM/98_Modbus.pm";

    $modHash->{parseInfo}  = \%SET10parseInfo;  # defines registers, inputs, coils etc. for this Modbus Defive   
    $modHash->{deviceInfo} = \%SET10deviceInfo; # defines properties of the device like defaults and supported function codes

    ModbusLD_Initialize($modHash);                        # Generic function of the Modbus module does the rest
    $modHash->{ModbusReadingsFn} = "ModbusSET_Reading";    # to be called before a reading is set
   
    $modHash->{AttrList} = $modHash->{AttrList} . " " .     # Standard Attributes like IODEv etc
        $modHash->{ObjAttrList} . " " .                     # Attributes to add or overwrite parseInfo definitions
        $modHash->{DevAttrList} . " " .                     # Attributes to add or overwrite devInfo definitions
        "poll-.* " .                                                     # overwrite poll with poll-ReadingName
        "polldelay-.* ";                                              # overwrite polldelay with polldelay-ReadingName
}


In 98_Modbus-pm sieht das folgendermaßen aus:

Code Auswählen Erweitern


# Try to call a user defined function if defined
#################################################
sub Modbus_TryCall($$$$)
{
    my ($hash, $fName, $reading, $val) = @_;
    my $name = $hash->{NAME};
my $modHash = $modules{$hash->{TYPE}};
if ($modHash->{$fName}) {
my $func = $modHash->{$fName};
Log3 $name, 5, "$name: calling $fName for reading $reading and val $val";
no strict "refs";     
my $ret = eval { &{$func}($hash,$reading,$val) };
if( $@ ) {         
Log3 $name, 3, "$name: error calling $fName: $@";
return;
}                   
use strict "refs";
return $ret
}
return;
}

...

if (!Modbus_TryCall($logHash, 'ModbusReadingsFn', $reading, $val)) {
Log3 $name, 4, "$name: ParseObj assigns value $val to $reading";
readingsBulkUpdate($logHash, $reading, $val);
}



Gruss
    Stefan

[pejonp]

Hallo Stefan,

Werde ich mal testen. Kann aber nicht sagen wann ich dazu komme.

Jörg

[McBasil]

Hallo Stefan,

jetzt bin ich auch dazu gekommen den passiven Modus zu testen, leider erfolglos. Es ist mir nicht gelungen mein Modbus/TCP Gateway als benutzbares Gerät zu vermitteln. Nachfolgend findest Du die relevanten Logfileeinträge, die zugehörigen "defines ..." habe ich als Komentar eingefügt.

Dass der passive Empfang grundsätzlich funktioniert ist aus dem letzten Beispiel ersichtlich, da ist DimplexWWP über das  protocol RTU im mode master mit  ECS-AP:8899 verbunden. Gleichzeitig besteht auch eine Verbindung zwischen iobrokerServer und der Wärmepumpe. Die Antworten auf die Anfragen des iobrokerServers werden in fhem erkannt und im logfile wird notiert, dass Nachrichten vom slave kamen obwohl keine Anfragen gestellt wurden.

Hier der Auszug aus dem Logfile

Code Auswählen Erweitern

2019.04.28 01:59:02 1: Including fhem.cfg
2019.04.28 01:59:02 3: telnetPort: port 7072 opened
2019.04.28 01:59:03 3: WEB: port 8083 opened
2019.04.28 01:59:03 3: WEBphone: port 8084 opened
2019.04.28 01:59:03 3: WEBtablet: port 8085 opened
2019.04.28 01:59:03 2: eventTypes: loaded 395 events from ./log/eventTypes.txt

#define DimplexWWP ModbusRTUDimplexWWP 1 passive RTU

2019.04.28 01:59:03 1: Including FHEM/Wi18TU.cfg
2019.04.28 01:59:03 3: DimplexWWP: defined with id 1, protocol RTU, mode passive
2019.04.28 01:59:03 1: Including ./log/fhem.save
2019.04.28 01:59:03 3: DimplexWWP: SetIODev found no usable physical modbus device
2019.04.28 01:59:03 3: DimplexWWP: Notify / Init: no IODev for communication
2019.04.28 01:59:03 0: Featurelevel: 5.9
2019.04.28 01:59:03 0: Server started with 12 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:24412)
2019.04.28 02:01:48 0: Server shutdown



2019.04.28 02:01:50 1: Including fhem.cfg
2019.04.28 02:01:50 3: telnetPort: port 7072 opened
2019.04.28 02:01:50 3: WEB: port 8083 opened
2019.04.28 02:01:51 3: WEBphone: port 8084 opened
2019.04.28 02:01:51 3: WEBtablet: port 8085 opened
2019.04.28 02:01:51 2: eventTypes: loaded 395 events from ./log/eventTypes.txt

#define DimplexWWP ModbusRTUDimplexWWP 1 passive ECS-AP:8899 RTU

2019.04.28 02:01:51 1: Including FHEM/Wi18TU.cfg
2019.04.28 02:01:51 3: DimplexWWP: define as passive is only possible for serial connections, not with a defined host:port
2019.04.28 02:01:51 1: define DimplexWWP ModbusRTUDimplexWWP 1 passive ECS-AP:8899 RTU: Define as passive is only possible for serial connections, not with a defined host:port
2019.04.28 02:01:51 1: Including ./log/fhem.save
Define as passive is only possible for serial connections, not with a defined host:port
./log/fhem.save: Please define DimplexWWP first
2019.04.28 02:01:51 0: Featurelevel: 5.9
2019.04.28 02:01:51 0: Server started with 11 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:24455)
2019.04.28 02:04:07 0: Server shutdown



2019.04.28 02:04:09 1: Including fhem.cfg
2019.04.28 02:04:09 3: telnetPort: port 7072 opened
2019.04.28 02:04:09 3: WEB: port 8083 opened
2019.04.28 02:04:10 3: WEBphone: port 8084 opened
2019.04.28 02:04:10 3: WEBtablet: port 8085 opened
2019.04.28 02:04:10 2: eventTypes: loaded 395 events from ./log/eventTypes.txt

#define RS485 Modbus ECS-AP:8899 RTU
#define DimplexWWP ModbusRTUDimplexWWP 1 passive RTU
#attr DimplexWWP IODev RS485

2019.04.28 02:04:10 1: Including FHEM/Wi18TU.cfg
2019.04.28 02:04:10 1: define RS485 Modbus ECS-AP:8899 RTU: wrong syntax: define <name> Modbus [tty-devicename|none]
2019.04.28 02:04:10 3: DimplexWWP: defined with id 1, protocol RTU, mode passive
2019.04.28 02:04:10 3: DimplexWWP: SetIODev from DimplexWWP to RS485 but RS485 does not exist (yet?)
2019.04.28 02:04:10 3: DimplexWWP: SetIODev found no usable physical modbus device
2019.04.28 02:04:10 1: Including ./log/fhem.save
2019.04.28 02:04:10 3: No I/O device found for DimplexWWP
wrong syntax: define <name> Modbus [tty-devicename|none]
2019.04.28 02:04:10 3: DimplexWWP: SetIODev from DimplexWWP to RS485 but RS485 does not exist (yet?)
2019.04.28 02:04:10 3: DimplexWWP: SetIODev found no usable physical modbus device
2019.04.28 02:04:10 3: DimplexWWP: Notify / Init: no IODev for communication
2019.04.28 02:04:10 0: Featurelevel: 5.9
2019.04.28 02:04:10 0: Server started with 12 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:24460)
2019.04.28 02:08:11 0: Server shutdown



2019.04.28 16:51:18 1: Including fhem.cfg
2019.04.28 16:51:18 3: telnetPort: port 7072 opened
2019.04.28 16:51:18 3: WEB: port 8083 opened
2019.04.28 16:51:18 3: WEBphone: port 8084 opened
2019.04.28 16:51:18 3: WEBtablet: port 8085 opened
2019.04.28 16:51:19 2: eventTypes: loaded 395 events from ./log/eventTypes.txt

#define DimplexWWP ModbusRTUDimplexWWP 1 1 ECS-AP:8899 RTU

2019.04.28 16:51:19 1: Including FHEM/Wi18TU.cfg
2019.04.28 16:51:19 3: DimplexWWP: defined with id 1, interval 1, protocol RTU, mode master, connection to ECS-AP:8899
2019.04.28 16:51:19 1: Including ./log/fhem.save
2019.04.28 16:51:19 3: Opening DimplexWWP device ECS-AP:8899
2019.04.28 16:51:19 0: Featurelevel: 5.9
2019.04.28 16:51:19 0: Server started with 12 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:31861)
2019.04.28 16:51:19 3: DimplexWWP device opened
2019.04.29 00:44:33 3: DimplexWWP: read got new data while idle, drop buffer 01020200fe3838
2019.04.29 00:44:33 3: DimplexWWP: read got new data while idle, drop buffer 01010200fe387c


Was kann/muss ich tun um den passiven Modus richtig zu aktivieren?

Gruß Basil

[StefanStrobel]

Hallo Basil,

der passive Modus ist dafür gedacht auf einer seriellen Leitung (RS232 oder RS485) mitzulesen wenn zwei andere Geräte darüber per Modbus RTU oder ASCII kommunizieren und aus den dabei übertragenen Inhalten Readings zu machen.
Du brauchst also z.B. eine Wärmepumpe mit Modbus RTU per RS485, die von einem anderen Master oder Gateway abgefragt wird.

Da es um serielle Kommunikation geht, muss also zunächst ein IODev erzeugt werden, z.B.:

Code Auswählen Erweitern


define ModbusRS232 Modbus /dev/dualser0@9600


Danach muss ein passives ModbusAttr-Gerät (oder ein anderes Modul auf Basis von Modbus wie ModbusSET oder ModbusSDM630M) erzeugt werden, welches das zuvor definierte IODev benutzt, z.B.:

Code Auswählen Erweitern


define WP ModbusAttr 1 passive


Bei ModbusAttr muss man dann natürlich noch Attribute angeben, damit klar ist, wie die Inhalte zu interpretieren sind (Länge der Objekte, Unpack-Code / Format etc.)

Wenn Du beim Define eine Portnummer wie :8899 angibst, dann geht das Modul davon aus, das Du keine serielle sondern eine TCP basierte Kommunikation haben möchtest. Dafür ist ein Mitlesen nicht implementiert (sonst müsste Fhem das Ethernet-Interface in den Promicious-Mode bringen und erst mal den TCP-Stream reassemblieren ...).

Gruss
   Stefan

[klaus.schauer]

Danach muss ein passives ModbusAttr-Gerät (oder ein anderes Modul auf Basis von Modbus wie ModbusSET oder ModbusSDM630M) erzeugt werden, welches das zuvor definierte IODev benutzt, z.B.:

Code Auswählen Erweitern


define WP ModbusAttr 1 passive


Wäre es also z. B. beim dem neuen Modul ModbusElsnerWS so möglich, mit zusätzlichen passiven Devices auf dem gleichen Fhem oder auf einem weiteren Fhem-Gerät mitzulesen, falls die weiteren Devices mit "passive" definiert werden:

Aktives Device

Code Auswählen Erweitern


define modbus Modbus /dev/ttyUSB1@19200,8,E,1
define WS_active ModbusElsnerWS id=1 interval=1


Passives Device auf weiterer Fhem-Installation

Code Auswählen Erweitern


define modbus Modbus /dev/ttyUSB1@19200,8,E,1
define WS_passive ModbusElsnerWS id=1 interval=passive

Das wäre durchaus praktisch, da man dann die Auswertung der Wetterstationsdaten noch individueller für die Steuerung mehrerer Gruppen von Rollos festlegen könnte. Das würde ich dann direkt in die commandref des Moduls aufnehmen.

[StefanStrobel]

Hallo Klaus,

eigentlich sollte es so funktionieren.
Nur leider hat es noch kaum jemand ausser mir selbst getestet

Gruss
   Stefan

[klaus.schauer]

eigentlich sollte es so funktionieren.
Nur leider hat es noch kaum jemand ausser mir selbst getestet

Ich probiere das bei Gelegenheit aus.

[klaus.schauer]

Leider funktioniert ein Passiv-Device parallel zu einem Master-Device auf einem Fhem-System nicht:

Code Auswählen Erweitern


define modbus Modbus /dev/ttyUSB1@19200,8,E,1
define WS ModbusElsnerWS id=1 interval=1
define WS_passive ModbusElsnerWS id=1 interval=passive

Internals:
   .getList   
   .setList   reconnect:noArg saveAsModule
   .updateSetGet 0
   DEF        id=1 interval=passive
   FUUID      5ccdbe65-f33f-9749-6ec3-30d1a2d40a0c30ad
   MODBUSID   1
   MODE       passive
   MODULEVERSION Modbus 4.1.2 - 17.4.2019
   NAME       WS_passive
   NOTIFYDEV  global
   NR         129
   NTFY_ORDER 50-WS_passive
   PROTOCOL   RTU
   STATE      disconnected
   TYPE       ModbusElsnerWS
   .attraggr:
   .attrminint:
   READINGS:
     2019-05-04 18:47:50   state           disconnected
Attributes:
   enableControlSet 1
   room       ElsnerWS
   verbose    5


Folgende Fehlermeldungen kommen beim Restart:

Code Auswählen Erweitern


...
2019.05.04 18:47:50 3: WS: RegisterAtIODev called from SetIODev registers WS at modbus with id 1, MODE master, PROTOCOL RTU
2019.05.04 18:47:50 3: WS: Notify / Init: using modbus for communication
2019.05.04 18:47:50 5: WS_passive: UnregAtIODev called from Notify
2019.05.04 18:47:50 4: WS_passive: GetIOHash (called from Notify) didn't find valid IODev hash key, calling SetIODev now
2019.05.04 18:47:50 5: WS_passive: SetIODev called from GetIOHash
2019.05.04 18:47:50 5: WS_passive: CheckIOCompat (called from SetIODev) for WS_passive and modbus: modbus is locked to mode master by WS
2019.05.04 18:47:50 5: WS_passive: UnregAtIODev called from SetIODev
2019.05.04 18:47:50 3: WS_passive: SetIODev found no usable physical modbus device
2019.05.04 18:47:50 4: WS_passive: GetIOHash didn't find IODev attribute or matching physical serial Modbus device
2019.05.04 18:47:50 3: WS_passive: Notify / Init: no IODev for communication
...
2019.05.04 18:47:59 3: Opening modbus device /dev/ttyUSB1
2019.05.04 18:47:59 3: Setting modbus serial parameters to 19200,8,E,1
2019.05.04 18:47:59 3: modbus device opened
2019.05.04 18:47:59 0: Featurelevel: 5.9
2019.05.04 18:47:59 0: Server started with 94 defined entities (fhem.pl:19265/2019-04-26 perl:5.024001 os:linux user:fhem pid:6383)


Setzt man ein set WS_passive reconnect ab, so kommt die Fehlermeldung:

Code Auswählen Erweitern


Unknown argument HASH(0x42704e0), choose one of reconnect saveAsModule


Vielleicht liegt es auch an meinem neuen Modul. Ich musste insbesondere ein paar Routinen wie _Initialize, _Define etwas umbiegen, siehe Moduldatei.

P. S. Die Hash-Fehlermeldung hat sich geklärt. Ich hatte die neue Parse-Funktion mit

Code Auswählen Erweitern


$hash->{parseParams}      = 1;

aktiviert und nur in _Define die Übergabeparaneter an das Modbus-Modul wieder "zurückgewandelt".

[StefanStrobel]

Hallo Klaus,

auf einem Fhem-System kann man über ein gemeinsames serielles Interface nur eine Art von logischem Modbus-Device haben (Master, Slave oder Passive).
Wenn der Master auf dem selben Fhem läuft, muss man ja auch nicht passiv mitlesen sondern kann direkt auf die Readings des Master zugreifen.

Du müsstest es deshalb auf einer zusätzlichen Fhem-Installation testen.
Der typische Anwendungsfall ist ja dass ein anderer Master bereits am Bus hängt. (z.B. Wechselrichter / Solar-Steuerung, die einen Modbus-Stromzähler abfragt).
Da Modbus nur einen Master am Bus vorsieht, ist der passive Modus eine Möglichkeit, trotzdem die Daten des Slaves lesen und verarbeiten zu können.

Beim Programmieren hatte ich mir lange überlegt, ob ich den Aufwand treiben und es ermöglichen soll, dass sowohl ein Master als auch ein Slave o.ä. im gleichen Fhem auf dem gleichen Interface laufen kann. Das hätte einige Komplikationen beim Parsen mit sich gebracht. Unterm Strich habe ich dann aber gedacht dass das eher von akademischem Interesse wäre und in der Praxis keine Anwendung dafür existiert. Deshalb wird beim ersten Define eines logischen Modbus-Geräts das zugehörige serielle Device per "Lock" auf einen Mode (Master, Slave, Passive oder Relay) und ein Protokoll (RTU / ASCII) gesetzt.

Sorry falls ich das nicht deutlich genug geschrieben habe.

Gruss
   Stefan

[klaus.schauer]

Passt schon so. Ein zweites passives Device neben dem Master ist wirklich nur ein Luxusproblem.