Neue Versionen und Support zum Modbus-Modul

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

Vorheriges Thema - Nächstes Thema

Wolfshund

Zitat von: StefanStrobel am 23 Juli 2020, 22:35:01

wenn Du auf dem Ziel-Gerät auch einen Float-Wert hast, der über zwei Register geht, dann musst Du die nicht einzeln schreiben. Statt dessen kannst Du die Länge des Objekts auf zwei setzen und mit dem passenden Unpack-code einen Float-Wert direkt über zwei Register schreiben. Es kommt aber darauf an, wie das Ziel-Gerät den Wert haben will...

Hallo Stefan,

Danke, habe das nach dem Try and Error Prinzip so am Freitag auch gelöst, habe mich mit den 16 Bit / 32Bit enfach verrannt.
Das Thema Modbus ist für mich noch ziemliches Neuland, es funktionet nun so wie es soll.

Inzwischen habe ich dein Modbus Modul auch dazu bekommen, den Befehl 17(0x11) richtig zu beantworten, dies aber mit einer Quick und dirty Methode.


sub Modbus_ParseResponse($$%)
.
.
elsif ($fCode == 17) {
        # Read id as acii                     pdu: fCode, adr, len
        return if ($dataLength) < 2;
        my ($adr, $values)  = unpack ('na*', $data);
        $response->{ADR}    = $adr;                         # adr of register
        $response->{VALUES} = "Continental Control Systems LLC, WattNode MODBUS$
        $response->{TYPE}   = '';                          # holding registers
        $frame->{PDULEXP}   = 5;                            # 1 Byte fCode + 2 $

sub Modbus_HandleRequest($)
.
.
    Modbus_CheckChecksum($hash);                    # get $hash->{FRAME}{CHECKS$
     if ($fc > 16  ) {
                     $frameLen = 5 ;
                }
sub Modbus_ParseRequest($$)
.
.
elsif ($fCode == 17) {
        # Read id as acii                     pdu: fCode, adr, len
        #return if ($dataLength) < 2;
        my ($adr, $values)  = unpack ('na*', $data);
        $request->{ADR}    = $adr;                         # adr of register
        $request->{VALUES} = "Continental Control Systems LLC, WattNode MODBUS,$
        $request->{TYPE}   = 'c';                          # holding registers
        $frame->{PDULEXP}   = 8;                            # 1 Byte fCode + 2 $
    } else

sub Modbus_PackResponse($$)
.
.

    my $data;
if ($fCode == 17) {
$response->{ERRCODE} = 0;
}
.
.
elsif ($fCode == 17) {                    # Request ID                   $
        $data = pack ('ccca*', 66, 2 , 255,"Continental Control Systems LLC, Wa$
    }


Mit meinem beschränten Perl Wissen bin ich aber trotzdem zufrieden das ich die Stellen gefunden habe, und das System so "verbiegen" konnte das es funktioniert.

Warum dieser Aufwand?
Siehe mein Post « Antwort #490 am: 22 Juni 2020, 14:02:03 »

Dank Deines Modbus Modules, konnte ich die gesamte Problematik lösen, wenn auch sehr unprofessionell und gehackt.
Meine Bitte wäre, die Funktion 17(0x11) auf die Wunschliste zu setzen, da ich z.B. mit der Einbindung von Attributen komplett überfordert war und deshalb diesen
"Quick & Dirty Hack" benutzt habe.

Danke für Dein Modul un Deine Hilfe.


LG

Andreas



Raspberry PI, Mysensors Serial Gateway, Firmata Relais,Mysensors Dallas/Relais, Mysensors Dallas mit Nokia Display

StefanStrobel

Hallo Andreas,

function code 17 kann ich gerne einbauen.
Ich bein eh gerade dabei das Modul zu überarbeiten.

Gruss
   Stefan

JF Mennedy

Hallo, ich versuche so ein Register zu entschlüsseln, wie im Anhang beschrieben. Wenn ich das Register auslese bekomme ich folgende Antwort: hex=e500, string=.., s=229, s>=-6912, S=229, S>=58624

ich stehe hier leider komplett auf dem Schlauch, wie ich das nun weiter verarbeiten könnte...

Gruss Jan

JF Mennedy

Also, Selbsthilfe ist der Beste Weg zum Lernen...

Ich habe nun die Dezimalzahl in eine Binärzahl umgewandelt:
PH_STATUS { sprintf("%016b",ReadingsVal($name,"pH-Status",0)) }

Das Ergebnis ist:
PH_STATUS 1110010100000000

Die Bitfolge ist :


bit:     15 14 13 12   11 10 9  8    7  6  5  4    3  2  1  0
binar:   1  1  1  0    0  1  0  1    0  0  0  0    0  0  0  0


Und somit komme ich an die jeweiligen Statusmeldungen aus dem Register :-)


Wolfshund

Hallo Stefan,

Zitatfunction code 17 kann ich gerne einbauen.

Das wäre super, traue meiner gehackten Version nicht so ganz ;)
habe im Moment auch das Update für Modbus deaktiviert.


LG
Andreas
Raspberry PI, Mysensors Serial Gateway, Firmata Relais,Mysensors Dallas/Relais, Mysensors Dallas mit Nokia Display

Tomk

Hallo zusammen, erstmal besten Dank für dieses Modul. Ich nutze Modbus attr mit tcp als Slave zur Kommunikation zu einem Touch Panel.
Ich habe folgendes Problem:
In fhem bekomme ich immer ein zusätzliches device im room ,,Connections" angelegt. Ich habe den Eindruck das dies bei jeder neuen TCP Verbindung (mehrmals täglich) erfolgt. Der Name des devices enthält den names des von mir angelegten Devices plus Ip und Port. Type ist auch ModbusAtrr.

Ist das so gewollt? Oder läuft hier noch was schief?
Danke vorab!

StefanStrobel

Hallo,

das temporäre Device unter Connections ist normal.
Stört es?

Gruß
    Stefan

Tomk

Hallo Stefan, danke für die Antwort. Es würde nicht stören wenn es nicht dazu führen würde das FHEM immer umgespeicherte Änderungen anzeigt, daher weiß man nicht Ob man wirklich speichern muss oder nicht.
es wäre auch gut wenn der Raum von dem ,,Mutterobjekt" genommen werden könnte...

Tomk

Hallo Stefan, wäre diese Änderung aufwendiger? Wie gesagt mir würde es reichen wenn das Device sich nicht immer ändert und damit die Fehm Konfiguration editiert...
Besten dank vorab!

StefanStrobel

Hallo Tomk,

Ich muss da selbst erst mal recherchieren.
Das Modbus-Modul verwendet die TCPServerUtils für die TCP-Verbindungen als Slave.
Ob / wie das dann ohne neues Device funktioniert, muss ich noch klären.

Gruß
    Stefan

gramels

Hallo,

ich habe Probleme mit Datentypen.

In meinem Kamstrup Ominpower Stromzähler steckt nun ein smart-me modul (EWS Schyz in der Schweiz). Das kann ich vie modbus tcp ansprchen.

Die aktuelle Leistung wird korrekt angezeigt in fhem.

Wenn ich die Zählerstände abfrage erhalte ich unklare Werte. Ich vermute ine unpack Problem. Habe aber schon allerhand durchprobiert. Wenn ich nun mit einem Windows Modbus Tool die Register abfrage erhalte ich

in Hex
0002 1810

was in Dec
137232

entspricht und korrekt ist . Nur in FHEM bekomme ich dies nicht aufgelöst.

Was sind die richtigen Objekteinstellungen um dies in FHEM rcihtig drazustellen?

Grüsse Lothar

StefanStrobel

Hallo,

Zitat von: Tomk am 08 August 2020, 07:01:26
Hallo Stefan, wäre diese Änderung aufwendiger? Wie gesagt mir würde es reichen wenn das Device sich nicht immer ändert und damit die Fehm Konfiguration editiert...
Besten dank vorab!

Ich habe mir das nochmal angesehen. Die Connection-Devices werden als TEMPORARY erzeugt. Das sieht man bei den Internals. Solche Devices sind keine strukturellen Änderungen und Fhem möchte deswegen auch keine Änderungen speichern.
Hilft das?

Gruss
   Stefan

StefanStrobel

Hallo Lothar,

Zitat von: gramels am 02 September 2020, 10:25:53
Wenn ich die Zählerstände abfrage erhalte ich unklare Werte. Ich vermute ine unpack Problem. Habe aber schon allerhand durchprobiert. Wenn ich nun mit einem Windows Modbus Tool die Register abfrage erhalte ich

in Hex
0002 1810

was in Dec
137232

entspricht und korrekt ist . Nur in FHEM bekomme ich dies nicht aufgelöst.

Was sind die richtigen Objekteinstellungen um dies in FHEM rcihtig drazustellen?

0002 1810 sind offensichtlich 32 Bit, also zwei aufeinanderfolgende Register.
Entsprechend muss bei der Konfiguration als Länge zwei angegeben werden.
Das Format scheint ein 32-Bit Integer zu sein (vermutlich unsigned im big-endian format).
Auf https://perldoc.perl.org/functions/pack.html findet sich dafür N

Gruss
   Stefan

Tomk

#523
Zitat von: StefanStrobel am 07 September 2020, 13:14:56
Hallo,

Ich habe mir das nochmal angesehen. Die Connection-Devices werden als TEMPORARY erzeugt. Das sieht man bei den Internals. Solche Devices sind keine strukturellen Änderungen und Fhem möchte deswegen auch keine Änderungen speichern.
Hilft das?

Gruss
   Stefan

Danke für die Info! Das attribute temporary ist auf 1, richtig. Allerdings zeigt fhem immer wieder eine Änderung an nach einigen Stunden und ich habe das in Verbindung mit modbus gebracht, da ich nur dies geändert habe als das Phänomen erstmals auftrat. Kann man irgendwie herausfinden welche Änderung Fhem speichern möchte?
Ich habe die Fhem.cfg verglichen, hier sind keine Änderungen drin...

Was mir noch einfällt, vielleicht sorgt der neue ,,Raum" Connections dafür das die Änderung erkannt wird und nicht das temporary device selbst?

pechnase

Hallo,
ich möchte mein FHEM um den Modbus RTU über eine serielle Schnittstelle erweitern. Als Testsystem verwende ich einen Raspberry Pi und da ich noch keinen USB-RS485 Wandler zur Hand habe, verbinde ich einfach einen USB-seriell Adabpter mit FTDI-Chip mit einer USB Schnittstelle des Raspberry. Die Schnittstelle wird vom raspbian Betriebssystem auch erkann und ich habe folgende Devices definiert:
defmod ModbusLine Modbus /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A400YZ8S-if00-port0@19200,8,E,1
attr ModbusLine comment 09.09.2020: laut Proxon Tabelle 19200,8,E,1 als Werkeinstellung
attr ModbusLine room myModbus
attr ModbusLine verbose 5

setstate ModbusLine opened
setstate ModbusLine 2020-09-10 10:19:21 state opened


und
defmod Proxon_WP ModbusAttr 41 10 RTU
attr Proxon_WP userattr obj-i195-reading
attr Proxon_WP comment 09.09.2020: Laut Modbus Tabelle default Adresse 41 und 19200baud
attr Proxon_WP obj-i195-reading T1-Zuluft
attr Proxon_WP room myModbus

setstate Proxon_WP opened
setstate Proxon_WP 2020-09-10 10:38:24 state opened



Das Master-Slave Prinzip des Modbus ist mir bekannt. Da ich die Proxon WP noch nicht physikalisch verfügbar habe wollte ich folgende Testschritte durchführen:

  • nur den Raspberry mit USB-Seriell Adapter und mit einem Analyser auf der seriellen Schnittstelle schauen, was da zu 'sehen' ist. Erwartet hätte ich, dass der Master (Raspberry Pi) alle 10sec (in Proxon_WP konfiguriert) versucht eine Nachricht an den Slave, den es ja noch nicht gibt, zu schicken. Ich sehe aber nichts.
  • in einem zweiten Schritt wollte ich mir mit einem Arduino einen Slave mit ein paar wenigen Input- bzw. Holding-Register nachbauen um die Kommunikation zu verfolgen.

Wo ist mein Gedankenfehler bzw. woran könnte es liegen, dass ich kein Poll des Masters auf der Seriellen Schnittstelle sehe? Welche STATE kann das Modul 'Modbus' einnehmen? Bei mir wird 'opened' angezeigt.

Danke für einen kleinen Gedankenanstoß

Wolfgang
2 x RPI mit FHEM 5.8 (RPI B+ & RPI 2B) verbunden über FHEM2FHEM
- HM Fensterkontakte, Rauchmelder, Fernbedienung, Schalter
- Optolink (Selbstbau) Vitotronic 200KW2
- 1-wire DS1820 Temp.Sensoren, TX29DT-IT
- CUL (busware), nanoCUL, Jeelink (Nachbau), FHEMduino