Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Hallo,

das SDM230M-Modul und alle anderen Module, die auf 98_Modbus.pm basieren, verstehen auch alle Optionen beim Define und alle Attribute von ModbusAttr.
Du kannst also auch damit RTU über TCP machen!

Gruß
   Stefan

[pejonp]

Hallo Guzzi-Charlie,

wenn du ein USR-TCP232-T24 (siehe Bild) im Einsatz hast must du das Modul z.B. so definieren. RS485 muss aktiv sein. Vielleicht hilft es weiter.

Code Auswählen Erweitern


define PWP ModbusAttr 3 60 192.168.2.7:20108 RTU


Ich sehe bei einem Adapter jetzt nicht ob es RS485 kann bzw. aktiviert werden kann.

pejonp

[Guzzi-Charlie]

Hallo zusammen,

wenn ich gewußt hätte das es so einfach sein kann.....

Also, ich habe mein modifiziertes SDM220M-Modul (mit angepaßten Registern) genommen, die IP-Adresse des RS485-TCP Gateways und "RTU" angehängt und schon hat es funktioniert. Mit dem allgemeinen ModbusAtt-Modul bekomme ich das zwar immer noch nicht hin, aber das soll mir jetzt mal egal sein.

@Stefan
Vielen Dank für die Erläuterungen.


Ich hab noch eine andere Frage:
Da ich mich mit Perl absolut nicht auskenne habe ich natürlich auch noch kein Modul selbst programmiert, sondern nur (z.B.) das vorhandene SDM220M modifiziert. Jetzt hatte ich ein wenig zu einfach gedacht (wie es scheint). Da ich ja das originale SDM220 abgeändert habe würde das dann allerdings beim nächsten Update wieder überschrieben. Deshalb hatte ich das Modul einfach kopiert und ihm einen anderen Namen gegeben. Als ich dann damit ein neues Gerät (Zähler) definieren wollte bekam ich allerdings die Meldung "kann Modul nicht laden", oder so ähnlich. FHEM "Shutdown restart" hatte ich vorher durchgeführt.

Was müßte ich denn tun damit er mein umbenanntes Modul akzeptiert?

Gruß

[Wzut]

wenn du ein Modul unter einem neuen Namen führen willst (ich mach das öfters) dann schau ins Modul und ersetze dort überall den Orignal Namen gegen deinen Neuen.
I.d.R tragen fast alle subs den Modulnamen in sich aber ein guter Editor macht das via suchen & ersetzen recht schnell. 

[Guzzi-Charlie]

OK, Danke.

Wenn das alles sein sollte, dann wäre das ja schnell eledigt. Werd ich mal versuchen.

Gruß

[eisler]

Hallo,

Ich habe ein Beckhoff BK9000 mit Digital Ausgangsklemmen von 2003.

Auszug aus der Config:

Code Auswählen Erweitern

defmod MODBUS Modbus 192.168.1.2:502
attr MODBUS disable 0

defmod MODBUS_Gateway ModbusAttr 1 0 TCP
attr MODBUS_Gateway userattr obj-c0-poll obj-c0-reading obj-c2-poll obj-c2-reading obj-c4-poll obj-c4-reading
attr MODBUS_Gateway IODev MODBUS
attr MODBUS_Gateway obj-c0-poll 0
attr MODBUS_Gateway obj-c0-reading simpleLightbulb1
attr MODBUS_Gateway obj-c2-poll 0
attr MODBUS_Gateway obj-c2-reading simpleLightbulb2
attr MODBUS_Gateway obj-c4-poll 0
attr MODBUS_Gateway obj-c4-reading simpleLightbulb3

Setzen funktioniert leider nur ein mal:

Code Auswählen Erweitern

Cmd: >set MODBUS_Gateway simpleLightbulb2 1<
...
SW: 00000000000601050002ff00

Als Antwort bekomme ich:

Code Auswählen Erweitern

DropFrame - drop 000000000003018504
ReadAnswer got Error code 04 / slave device failure
192.168.1.2:502 disconnected, waiting to reappear (MODBUS)

Hat jemand schon mal einen Beckhoff BK9000 erfolgreich angesprochen?

Grüße
Stephan

[zwehn]

Hallo,
Habe heute einen Kostal plenticore Wechselrichter eingebaut bekommen. Nach Anleitung aus dem Forum habe ich die Einrichtung unter fhem vorgenommen.
Der plenticore ist Modbus master. Ein energy manager em300 hat auch als slave zugriff und ließt daten aus.

Fhem zeigt auch connected an, bekommt aber keine readings. Im logfile steht timeout, waiting for response. Die Zugangsdaten mit Geräte id im define sollten aber richtig sein, siehe unten.
Hat jemand eine Idee woran es liegen könnte?

Logfile:

Code Auswählen Erweitern

2019.04.01 23:30:57 3: Opening Plenticore device 192.168.28.82:1502
2019.04.01 23:30:57 3: Plenticore device opened
2019.04.01 23:31:07 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 203, type h, adr 320, len 2 for device Plenticore reading Total_yield (getUpdate), queued 2.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:31:09 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 101, type h, adr 322, len 2 for device Plenticore reading Daily_yield (getUpdate), queued 4.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:31:11 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 218, type h, adr 100, len 2 for device Plenticore reading Total_DC_Power (getUpdate), queued 6.02 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:32:10 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 224, type h, adr 322, len 2 for device Plenticore reading Daily_yield (getUpdate), queued 2.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:32:12 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 60, type h, adr 100, len 2 for device Plenticore reading Total_DC_Power (getUpdate), queued 4.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:32:14 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 215, type h, adr 320, len 2 for device Plenticore reading Total_yield (getUpdate), queued 6.02 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:33:13 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 79, type h, adr 320, len 2 for device Plenticore reading Total_yield (getUpdate), queued 2.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:33:15 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 217, type h, adr 322, len 2 for device Plenticore reading Daily_yield (getUpdate), queued 4.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:33:17 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 211, type h, adr 100, len 2 for device Plenticore reading Total_DC_Power (getUpdate), queued 6.03 secs ago, sent 2.01 secs ago, read buffer empty

Fhem Web Ausgabe:

Code Auswählen Erweitern

DeviceOverview
Plenticore
opened

Plenticore

Internals
DEF
71 60 192.168.28.82:1502 TCP

DeviceName
192.168.28.82:1502
EXPECT
idle
FD
121
FUUID
5ca27d5d-f33f-70a6-f0f6-2296cc58165efa55
INTERVAL
60
IODev
Plenticore
LASTOPEN
1554154257.897
MODBUSID
71
MODE
master
MODULEVERSION
Modbus 4.0.24 - 18.2.2019
NAME
Plenticore
NOTIFYDEV
global
NR
569
NTFY_ORDER
50-Plenticore
PARTIAL

PROTOCOL
TCP
STATE
opened
TCPConn
1
TIMEOUTS
33
TRIGGERTIME
1554154955.63942
TRIGGERTIME_FMT
2019-04-01 23:42:35
TYPE
ModbusAttr
devioLoglevel
3
lastUpdate
1554154895.63942
nextOpenDelay
60
Readings
state
opened
2019-04-01 23:30:57

Plenticore

Attributes
dev-type-Fl_R2-format
%.2f
deleteattr
dev-type-Fl_R2-len
2
deleteattr
dev-type-Fl_R2-revRegs
1
deleteattr
dev-type-Fl_R2-unpack
f>
deleteattr
obj-h100-poll
1
deleteattr
obj-h100-reading
Total_DC_Power
deleteattr
obj-h100-type
Fl_R2
deleteattr
obj-h320-expr
$val/1000
deleteattr
obj-h320-poll
1
deleteattr
obj-h320-reading
Total_yield
deleteattr
obj-h320-type
Fl_R2
deleteattr
obj-h322-expr
$val/1000
deleteattr
obj-h322-poll
1
deleteattr
obj-h322-reading
Daily_yield
deleteattr
obj-h322-type
Fl_R2
deleteattr
room
Energie
deleteattr
userattr
1 dev-type-Fl_R2-format dev-type-Fl_R2-len dev-type-Fl_R2-revRegs dev-type-Fl_R2-unpack obj-h100-poll obj-h100-reading obj-h100-type obj-h320-expr obj-h320-poll obj-h320-reading obj-h320-type obj-h322-expr obj-h322-poll obj-h322-reading obj-h322-type
deleteattr
Select icon Extend devStateIcon Raw definition Delete this device (Plenticore) Device specific help

Plenticore info:

Code Auswählen Erweitern

Gerät
Name
scb
Typenbezeichnung
PLENTICORE plus 7.0
Seriennummer
92092SBC0002N
Artikelnummer
10335957
Ui-version
01.05.03190
MC-Version
01.21
IOC-Version
01.20
HW-Version
0100
Ländereinstellung
Germany NSR
Batterieeingang
freigeschaltet

Was mich irritiert ist, dass egal ob ich im Wechselrichter Modbus aktiviere oder deaktiviere, fhem immer opened anzeigt aber nichts ausliesst.
Irgendwie stehe ich auf dem Schlauch. Hoffe auf einen Tipp.Danke

[McBasil]

Hallo,
ich lese mit fhem eine Dimplex WWP mit modbus RTU over tcp aus.
Nachdem ich heute ein fhem update durchgeführt habe erhalte ich im Logfile folgende Meldungen in einer Enddlossschleife:


2019.04.03 00:26:15 5: HttpUtils url=http://ecs-ap:8899/
2019.04.03 00:26:15 4: IP: ECS-AP -> 192.168.111.34
2019.04.03 00:26:15 3: ECS-AP:8899 reappeared (RS485)
2019.04.03 00:26:15 5: RS485: StartUpdateTimer called from OpenCB
2019.04.03 00:26:15 5: RS485: SetartUpdateTimer kept existing timer, will call GetUpdate in 16.0 sec at 2019-04-03 00:26:31, interval 30
2019.04.03 00:26:24 3: ECS-AP:8899 disconnected, waiting to reappear (RS485)
2019.04.03 00:26:29 5: HttpUtils url=http://ecs-ap:8899/
2019.04.03 00:26:29 4: IP: ECS-AP -> 192.168.111.34
2019.04.03 00:26:29 3: ECS-AP:8899 reappeared (RS485)
2019.04.03 00:26:29 5: RS485: StartUpdateTimer called from OpenCB
2019.04.03 00:26:29 5: RS485: SetartUpdateTimer kept existing timer, will call GetUpdate in 1.9 sec at 2019-04-03 00:26:31, interval 30
2019.04.03 00:26:31 5: DimplexWWP: GetUpdate called from HandleTimeout
2019.04.03 00:26:31 5: DimplexWWP: StartUpdateTimer called from ModbusLD_GetUpdate
2019.04.03 00:26:31 5: DimplexWWP: SetartUpdateTimer updated timer, will call GetUpdate in 30.0 sec at 2019-04-03 00:27:01, interval 30
2019.04.03 00:26:31 4: DimplexWWP: GetIOHash (called from ModbusLD_CheckDisable) didn't find valid IODev hash key, calling SetIODev now
2019.04.03 00:26:31 5: DimplexWWP: SetIODev called from ModbusLD_GetIOHash
2019.04.03 00:26:31 5: DimplexWWP: UnregAtIODev called from ModbusLD_SetIODev
2019.04.03 00:26:31 3: DimplexWWP: SetIODev found no usable physical modbus device
2019.04.03 00:26:31 4: DimplexWWP: GetIOHash didn't find IODev attribute or matching physical serial Modbus device
2019.04.03 00:26:31 5: DimplexWWP: CheckDisable returns no IO Device to communicate through
2019.04.03 00:26:31 5: DimplexWWP: GetUpdate called but no IO Device to communicate through
2019.04.03 00:26:31 5: RS485: GetUpdate called from HandleTimeout
2019.04.03 00:26:31 5: RS485: StartUpdateTimer called from ModbusLD_GetUpdate
2019.04.03 00:26:31 5: RS485: SetartUpdateTimer updated timer, will call GetUpdate in 30.0 sec at 2019-04-03 00:27:01, interval 30
2019.04.03 00:26:31 5: RS485: GetUpdate objects from attributes:
2019.04.03 00:26:31 5: RS485: GetUpdate full object list:
2019.04.03 00:26:31 5: RS485: GetUpdate tries to combine read commands
2019.04.03 00:26:31 5: RS485: GetUpdate doesn't sort objList before sending requests
2019.04.03 00:26:38 3: ECS-AP:8899 disconnected, waiting to reappear (RS485)


Meine Konfiguration:

define RS485 ModbusAttr 1 30 ECS-AP:8899 RTU
attr     RS485 verbose 5

define DimplexWWP ModbusRTUDimplexWWP 1 30
attr     DimplexWWP IODev RS485
attr     DimplexWWP verbose 5


Was hat sich geändert ?  Was muss ich anpassen?
Für Hilfestellung wäre ich dankbar.
Mit freundlichen Grüßen

[StefanStrobel]

Hallo McBasil,

Wenn Du Modbus-Verbindungen per TCP herstellen möchtest, dann musst Du im Define direkt die Adresse und den Port angeben. Ein IODev-Verweis ist nur für Modbus-Geräte gedacht, die direkt seriell an Fhem angeschlossen sind, da in diesem Fall mehrere Geräte am selben IO Device hängen können.
So war das eigentlich immer schon.

Ich vermute dass Du ein Gateway von TCP auf RS485 mit der Adresse ECS-AP verwendest.

Dann müsste Deine Konfiguration folgendermaßen aussehen:

Code Auswählen Erweitern


define DimplexWWP ModbusRTUDimplexWWP 1 30 ECS-AP:8899 RTU
attr     DimplexWWP verbose 5


Das Gerät mit Namen RS485 solltest Du löschen.

Gruß
   Stefan

[StefanStrobel]

Hallo Zwehn,

Bitte poste doch Deine tatsächliche Konfiguration, so wie sie in der fhem.cfg steht oder bei Klick auf "Raw Definition" in Fhemweb ausgegeben wird.
Zudem wäre ein ausführlicher Log-Auszug bei verbose 5 sehr hilfreich.
Dann vermute ich noch dass Du Modbus Master und Slave durcheinander gebracht hast.
Ein Modbus-Master fragt Daten von einem Slave ab. Ein Slave selbst liest keine Daten.

Gruß
    Stefan

[StefanStrobel]

Hallo Eisler,

Wenn ich Dein Setup richtig verstehe, hast Du ein BK9000 Gateway, das Du per Modbus ansprechen möchtet um dahinter liegende IO-Module zu steuern.
Die Fehlermeldung 04 deutet darauf hin, dass das Modul hinter dem Gateway nicht reagiert / funktioniert.
Schaltet es denn?
Was passiert denn wenn Du die gleichen Requests von einem anderen Master aus absetzt?

Gruß
    Stefan

[McBasil]

Hallo Stefan,

ganz herzlichen Dank für die Schnelle Unterstützung.

Ich habe die Änderung vorgenommen.

Jetzt wird der fhem-Server nicht mehr gestartet.

Die Überprüfung aus einer ssh ergibt folgendes Bild:

pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
-rw-r--r-- 1 fhem dialout 3886 Apr  4 01:12 fhem-2019-04.log
pi@raspber-bdf:/opt/fhem/log $ sudo rm fhem-2019-04.log
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ sudo /etc/init.d/fhem status
fhem is not running
pi@raspber-bdf:/opt/fhem/log $ sudo /etc/init.d/fhem start
Starting fhem...
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
-rw-r--r-- 1 fhem dialout 936 Apr  4 01:21 fhem-2019-04.log
pi@raspber-bdf:/opt/fhem/log $ sudo /etc/init.d/fhem status
fhem is not running
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
-rw-r--r-- 1 fhem dialout 936 Apr  4 01:21 fhem-2019-04.log
pi@raspber-bdf:/opt/fhem/log $

und hier das LOGFILE:

2019.04.04 01:21:10 1: Including fhem.cfg
2019.04.04 01:21:10 3: telnetPort: port 7072 opened
2019.04.04 01:21:10 3: WEB: port 8083 opened
2019.04.04 01:21:10 3: WEBphone: port 8084 opened
2019.04.04 01:21:10 3: WEBtablet: port 8085 opened
2019.04.04 01:21:11 2: eventTypes: loaded 310 events from ./log/eventTypes.txt
2019.04.04 01:21:11 1: Including Junkers-30-kW.cfg
2019.04.04 01:21:11 3: Laden using AES-Key: 7ec67698804f145884840ffb8f0191cdfdf3731acaa68dbe04da8cf392db0d

2019.04.04 01:21:11 1: Including Wi18TU.cfg
2019.04.04 01:21:11 3: DimplexWWP: defined with id 1, interval 30, protocol RTU, mode master, connection to ECS-AP:8899
2019.04.04 01:21:11 4: DimplexWWP: Notify / Init: opening connection
2019.04.04 01:21:11 5: DimplexWWP: open called from Notify
2019.04.04 01:21:11 4: DimplexWWP: open trying to open connection to ECS-AP:8899
Undefined subroutine &main::DevIo_OpenDev called at ./FHEM/98_Modbus.pm line 1593.

Danach erfolgen keine Einträge mehr im LOGFILE

Ich hoffe Du kannst mit meinen Infos etwas anfangen.

Gruß
        Basil

[eisler]

Hallo Stefan,

Das Setup hast du richtig verstanden.
Problem mit dem Beckhoff BK9000 Gateway habe ich gefunden.
Auf dem BK9000 Gateway ist ein Watchdog konfiguriert der nach dem ersten Schreiben alle 100ms ein alive benötigt.
Quick fix war den Watchdog zu deaktivieren.
Da ich die Funktion des Watchdog verstehe und Sinnvoll finde würde ich den Watchdog auch gerne ansprechen.
Hast du eine Idee?

Grüße
Stephan

[StefanStrobel]

Hallo Basil,

kannst Du mal die angehängten minimal geänderten Module ausprobieren?
Eventuell ist das Problem in Deinem Fall damit behoben.

Gruss / Thanx
   Stefan

[StefanStrobel]

Hallo Stephan,

kannst Du den Watchdog etwas genauer beschreiben?
Wer braucht da von wem welche Daten... ??

Gruss / Thanx
   Stefan