Neue Versionen und Support zum Modbus-Modul

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

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo,

neben der unterschiedlichen Adressierung (manche beginnen die Register bei 0 zu zählen, manche bei 1) sind auch die Datentypen nicht normiert. Wenn Du die Scan-Funktion von ModbusAttr verwendest, werden automatisch verschiedene unpack-Codes ausprobiert. Vielleicht hilft das.

Gruss
   Stefan

Fistandantilus

Ich habe das mal gemacht:

set Pool2 scanModbusObjects h105- 106 1

im Log steht folgendes:
2018.08.23 12:15:15 4: Pool2: Send called with h105, objLen 1 / reqLen 1 to id 1, op scanobj, qlen 0
2018.08.23 12:15:15 4: Pool2: Send queues fc 3 to 1, for h105, reqLen 1
2018.08.23 12:15:15 5: Pool2: ParseObj called with 05e2 and start 105, op scanobj
2018.08.23 12:15:15 3: Pool2: Address in attribute obj-h000105 too long, shortened to obj-h000105
2018.08.23 12:15:15 5: Pool2: ParseObj ObjInfo for h105: reading=scan-h000105, unpack=n, expr=, format=, map=
2018.08.23 12:15:15 5: Pool2: ParseObj unpacked 05e2 with n to hex 31353036 (1506)
2018.08.23 12:15:15 4: Pool2: ParseObj for scan-h000105 assigns 1506
2018.08.23 12:15:16 4: Pool2: Send called with h106, objLen 1 / reqLen 1 to id 1, op scanobj, qlen 0
2018.08.23 12:15:16 4: Pool2: Send queues fc 3 to 1, for h106, reqLen 1
2018.08.23 12:15:16 5: Pool2: ParseObj called with 0c3e and start 106, op scanobj
2018.08.23 12:15:16 3: Pool2: Address in attribute obj-h000106 too long, shortened to obj-h000106
2018.08.23 12:15:16 5: Pool2: ParseObj ObjInfo for h106: reading=scan-h000106, unpack=n, expr=, format=, map=
2018.08.23 12:15:16 5: Pool2: ParseObj unpacked 0c3e with n to hex 33313334 (3134)
2018.08.23 12:15:16 4: Pool2: ParseObj for scan-h000106 assigns 3134


Im Reg105 steht der Wert 1506 im Reg106 3134.

Mit Länge 2 set Pool2 scanModbusObjects h105- 106 2 ändert sich nichts.
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

Fistandantilus

Hier mal die abgelesenen Vergleichswerte:

PH: 6,8
RX: 673
Temp:25°

laut Doku werden folgende Register belegt:

PH - 102
RX - 103
Temp ist nicht beschrieben, laut Internet 106

Modbusergebnisse sind wie folgt:

PH 102: 337 -> wenn man mit 2 multipliziert , ergibt das 674 und durch 100 teilt und dann aufrundet kommen 6,8 -> sieht nach einer möglichen Lösung aus
RX 103: 0 -> passt nicht zur Anzeige
Temp 106: 3134 -> keine Idee, wie ich auf 25° kommen soll

wenn man annimmt, die Zählung geht bei 0 Los, hätten wir folgendes:

PH 101: 2026-> keine Idee, wie ich auf 6,8 kommen soll
RX 102: 337  -> wenn man mit 2 multipliziert, ergibt das 674, die Anzeige steht auf 673, was auch sein könnte
Temp 105: 1608 -> keine Idee, wie ich auf 25° kommen soll

Rein aus der Tatsache, dass und in welchen Registern Werte stehen, gehe ich davon aus, dass tatsächlich bei 0 angefangen wird zu zählen, das passt am besten.
Beim Auswerten benötige ich Eure Hilfe :)
Kann eigentlich der Abschlusswiderstand die Werte beeinflussen/verfälschen, oder spielt der nur für die generelle Kommunikation eine Rolle?
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

StefanStrobel

Hallo,

ich stelle mit Schreck fest, dass die Scan-Funktion in der aktuell eingecheckten Version einen Fehler hat.
Anbei eine korrigierte Version. Damit sollten nicht nur Zahlen sondern eine ganze Reihe möglicher Interpretationen der Register als Reading erscheinen. Mach doch damit nochmal einen Scan von 100 bis 106.

Gruss
   Stefan

Fistandantilus

Hab ich gemacht, jetzt wird auch mehr ausgegeben:

Länge 1
scan-h00100 hex=0004, string=.., s=1024, s>=4, S=1024, S>=4
scan-h00101 hex=07f2, string=.., s=-3577, s>=2034, S=61959, S>=2034
scan-h00102 hex=0149, string=.I, s=18689, s>=329, S=18689, S>=329
scan-h00103 hex=0000, string=.., s=0, s>=0, S=0, S>=0
scan-h00104 hex=011a, string=.., s=6657, s>=282, S=6657, S>=282
scan-h00105 hex=0629, string=.), s=10502, s>=1577, S=10502, S>=1577
scan-h00106 hex=0c3f, string=.?, s=16140, s>=3135, S=16140, S>=3135


Länge 2
scan-h00100 hex=000407ec, string=...., s=1024, s>=4, S=1024, S>=4, i=1024, i>=4, I=1024, I>=4, f=-6.52895500455626e+26, f>=3.70183817917616e-40
scan-h00101 hex=07ed0149, string=...I, s=-4857, s>=2029, S=60679, S>=2029, i=-4857, i>=2029, I=60679, I>=2029, f=532176.4375, f>=3.56605519735008e-34
scan-h00102 hex=01490000, string=.I.., s=18689, s>=329, S=18689, S>=329, i=18689, i>=329, I=18689, I>=329, f=2.61888669997665e-41, f>=3.69178694555125e-38
scan-h00103 hex=00000113, string=...., s=0, s>=0, S=0, S>=0, i=0, i>=0, I=0, I>=0, f=1.62820890837617e-27, f>=3.85357077689325e-43
scan-h00104 hex=0114065f, string=..._, s=5121, s>=276, S=5121, S>=276, i=5121, i>=276, I=5121, I>=276, f=9.66134820012818e+18, f>=2.7187877898356e-38
scan-h00105 hex=064c0c3f, string=.L.?, s=19462, s>=1612, S=19462, S>=1612, i=19462, i>=1612, I=19462, I>=1612, f=0.548035025596619, f>=3.83771326196037e-35
scan-h00106 hex=0c3f0000, string=.?.., s=16140, s>=3135, S=16140, S>=3135, i=16140, i>=3135, I=16140, I>=3135, f=2.26169572142025e-41, f>=1.47141047751185e-31


Kannst Du daraus was ableiten?
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

StefanStrobel

da sieht leider nichts nach einem PH-Wert oder einer Temperatur aus.
Floats, die über zwei Register gehen, können wir vermutlich auch ausschließen. Die Werte sind nicht sinnvoll.
Hast Du denn eine Doku, in der eventuell noch etwas hilfreiches steht?
Wie genau ist denn die Bezeichnung von Deinem Gerät?

Gruss
   Stefan

Fistandantilus

#111
Die Doku ist dahingehend echt bescheiden. Das Gerät ist ein Hidrolife 16. Die ist wohl identisch mit den Sugar Valley Anlagen (Salt Relax Pro). Eine Beschreibung der Register habe ich hier gefunden:
https://downloads.vodnici.net/uploads/wpforo/attachments/69/171-Modbus-registers.pdf

Kann die technische Anbindung noch Ursache für die komischen Werte sein?

Hier ist ein tschechisches Forum, da steht bissel was drin zu dem Gerät, aber ich versteh nur Bahnhof:

https://translate.googleusercontent.com/translate_c?depth=1&hl=de&prev=search&rurl=translate.google.de&sl=cs&sp=nmt4&u=https://www.vodnici.net/community/loxone-a-arduino/loxone-modbus/&xid=17259,15700021,15700124,15700149,15700186,15700190,15700201&usg=ALkJrhjzpRhAKOzJKoyWiaY-EBNZCxLNtQ#post-3549
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

StefanStrobel

Hallo,

Wenn die Kommunikation gestört wäre, würdest Du Fehler bekommen. Modbus RTU hat einen CRC in jedem Frame. Daran kann es nicht liegen.
Ich denke die Beschreibung der Register kann nicht zu Deinem Gerät passen.
Oder hat Dein Gerät mehrere unterschiedliche Modbus-Schnittstellen (eher unwahrscheinlich)?

Ich würde einfach mal einen Scan von 0 bis 1000 laufen lassen. Bei einigen Bereichen (wenn die Adressen nicht belegt sind) werden Fehlermedungen oder Timeouts kommen. Dort wo Antworten kommen, ist dann hoffentlich was dabei was zu Deinen echten Messwerten passt.

Gruß
    Stefan

Fistandantilus

Die Register scheinen tatsächlich falsch zu sein. Nach ein wenig Analyse, sind offensichtlich die Register ab 258 die richtigen. PH 258, RX 259 und Temp 262. Spannend/aufwendiger wird es jetzt die Register für die Relais rauszufinden und dann zu schreiben. Ich hab den Hersteller nochmal angeschrieben für eine Doku.
Ihr habt mir auf jeden Fall sehr geholfen!

Danke, F.
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

Fistandantilus

 :o nachdem ich jetzt gerade einen Geistesblitz hatte, habe ich mal die Register aus der Doku umgewandelt und siehe da, Register 106 Hexadezimal = 262 dezimal  ::)
Meine Doku ist also korrekt, man muss nur richtig lesen  ;)
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

Fistandantilus

#115
Neues Problem :(

Ich habe mein Register wie folgt definiert:

'h1288' => { reading => 'MBF_PAR_RX1',
name => 'PAR_RX1',
unpack => "s>",
set => 1,
poll => 1
},


Als Wert bekomme ich damit 740 raus, was korrekt ist. Ich habe jetzt versucht, das Register mit 750 zu schreiben. Es kommt allerdings dann ein Wert von -6700 irgendwas raus.
Fhem gibt mir als Fehler zurück: unexpected function code 16 from 1, expecting fc 6 from 1 for device Pool
Der Fehler kommt immer, wenn ich versuche zu schreiben.

Was mache ich falsch?
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

Fistandantilus

Update: Mit dem Attribute dev-h-write 16 ist das Problem gelöst. Jetzt wird dafür bei den Readings immer der selbe output wie beim Scan angezeigt:

z.B.
hex=2d3134393736, string=-14976, s=12589, s>=11569, S=12589, S>=11569, i=12589, i>=11569, I=12589, I>=11569, f=0.000171844571013935, f>=1.00728808974382e-11

Ich habe schon enableControlSet auf 0 gesetzt, alle readings gelöscht und neu gebootet, allerdings ohne Erfolg.
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

StefanStrobel

Hallo,

Beim Scan wird das Attribut def-h-defExpr auf ModbusLD_ScanFormat($hash, $val) gesetzt, damit alle Werte über eine Funktion in verschiedenen Interpretationen angezeigt werden.
Das solltest Du nach dem Scan wieder löschen. Ebenso def-h-defUnpack und def-h-defLen.
Ich persönlich würde zum Scannen einfach ein eigenes Device verwenden, das ich danach wieder lösche.
Ich werde das für die nächste Version etwas deutlicher in die Doku schreiben.

Dein erstes Problem zeigt dass Die Modbus-Implermentation Deines Pool-Systems fehlerhaft ist. Eine Anfrage mit function code 6 sollte auch mit function code 6 beantwortet werden, nicht mit 16.
Deine Lösung von vorneherein mit 16 zu schreiben ist ein sinnvoller Weg um das zu umgehen.

Gruss
    Stefan

Fistandantilus

Perfekt - danke Dir! Den Rest hab ich jetzt beim Hersteller angefragt, da die Doku echt schrecklich ist  :(
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

StefanStrobel

#119
Für die nächste Version des Modbus-Moduls suche ich noch nach Anwendern, die beim Testen helfen können.
Es sind einige neue Funktionen hinzu gekommen, was auch einige Änderungen am Code mit sich bringt.
Deshalb können natürlich auch Dinge, die vorher mal funktioniert haben, kaputt gegangen sein.

Die wesentlichen Neuerungen sind:

Passives Mitlesen von seriellem Modbus-Verkehr zwischen existierenden Geräten
Wenn bereits ein Modbus-Master per RS485 die Daten von einem Gerät abfragt, konnte Fhem bisher nicht auch noch Daten abfragen. Es darf ja nur einen Master geben. Mit der neuen Funktion kann Fhem nun passiv die Kommunikation zwischen dem existierenden Master und den angeschlossenen Geräten mitlesen und aus den übertragenen Werten Readings erzeugen.
Bei RS485 geht das relativ einfach. Bei RS232 sollte es prinzipiell auch möglich sein, aber damit Fhem die Kommunikation von beiden Richtungen sehen kann, wäre ein spezieller Adapter nötig.

Modbus-Slave Funktionen
Für das passive Mitlesen war es nötig, dass das Modul auch Requests von einem Master parsen kann. Die Slave-Funktion hat sich daraus ergeben. Damit kann das Modul Daten für einen externen Modbus-Master (z.B. eine SPS) bereitstellen oder auch Schreib-Requests von einem Master annehmen und daraufhin Readings ändern (sofern man das erlaubt).

Modbus Gateway / Relay Funktionen
Da das Modul nun sowohl Master als auch Slave sein kann, ist die naheliegende Erweiterung ein Modbus-Relay, das Requests wie ein Slave von einem externen Master annimmt, diese aber dann nicht selbst beantwortet sondern an einen weiteren Slave weitergibt. So kann Fhem nun z.B. per Modbus-TCP Anfragen empfangen und diese direkt per Modbus-RTU an ein seriell angeschlossenes Gerät weitergeben. Die Antwort des Geräts wird dann als Antwort per TCP an den ursprünglich anfragenden Master umkodiert und durchgereicht. Gleichzeitig können optional wieder die übertragenen Daten in Readings gepackt werden.

Der define für ein passives Mitlesen sieht folgendermaßen aus:
define <name> ModbusAttr <Id> passive RTU|ASCII|TCP
im Prinzip also wie bisher bei einem Master, nur dass an Stelle des Abfrageintervalls das Schlüsselwort passive angegeben wird. Ein Intervall kann es bei passivem Mitlesen ja nicht geben, da man keinen Einfluss darauf hat, wann der Master seine Daten abfragt.
Die Definition der Readings erfolgt wie bisher, allerdings hat man auch hier keinen Einfluss darauf, ob der existierende Master die gewünschten Objekte auch anfragt. Nur wenn er dies tut, gehen die Daten über die Leitung und Fhem kann sie dann mitlesen.

Beispiel:
define MB-485 Modbus /dev/ttyUSB2
define WP ModbusAttr 1 passive
attr WP obj-h256-reading Temp_Wasser_ein
attr WP obj-h256-expr $val/10
attr WP obj-h258-reading Temp_Wasser_Aus
attr WP obj-h258-expr $val/10


Für einen Modbus Slave sieht die Definition folgendermassen aus:
define <name> ModbusAttr <Id> slave
oder
define <name> ModbusAttr <Id> slave <Address:Port> RTU|ASCII|TCP
Adddress ist in diesem Fall eine der lokalen IP-Adressen der Fhem-Installation oder das Schlüsselwort global um auf allen Adressen auf eingehende Verbindungen zu warten.

Beispiel:
define MRS485 Modbus /dev/ttyUSB2@9600,8,E,1
define Data4PLC ModbusAttr 1 slave

oder
define MRS485 Modbus /dev/ttyUSB2@19200,8,N,1
define Data4PLC ModbusAttr 20 slave ASCII

oder
define Data4PLC ModbusAttr 5 slave global:502 TCP
sofern Fhem als root läuft und Port 502 öffnen darf
oder
define Data4PLC ModbusAttr 3 slave 192.168.1.2:8000 RTU

Die Konfiguration der Objekte z.B.:

attr Data4PLC obj-h300-reading Wetterstation:temperature
attr Data4PLC obj-h300-unpack f>
attr Data4PLC obj-h300-len 2
attr Data4PLC obj-h302-reading Wetterstation:humidity
attr Data4PLC obj-h302-unpack f>
attr Data4PLC obj-h302-len 2


Die gewohnten Attribute von einem Master gibt es auch für den Slave, nur dass sie umgekehrt wirken (Fhem stellt Daten für einen externen Master bereit statt sie selbst von einem Slave abzufragen). Entsprechend können auch Datentypen einmal definiert und später für mehrere Objekte verwendet werden

Für ein Relay definiert man zunächst einen Master, der die Daten an der Quelle abholen könnte und danach das Relay mit einem Verweis auf den Master:

define MyMaster ModbusAttr <Id1> 0
define <name> ModbusAttr <Id2> relay to MyMaster

oder
define <name> ModbusAttr <Id2> relay <Address:Port> RTU|ASCII|TCP to MyMaster

Beispiel:
define MB-485 Modbus /dev/ttyUSB2
define Heating ModbusAttr 22 0
define Relay ModbusAttr 33 relay global:1502 TCP to Heating

definiert MB-485 als physisches Basis-Device für die RS485-Kommunikation auf dem Bus,
dann Heating als Master-Device mit der Id der Heizung und 0 als Intervall,
dann das Relay, das per Modbus-TCP mit dem Port 1502 auf die Id 33 reagiert und die Anfragen dann an die Heizung weiterleitet.

Weitere Details in der Doku im Modul.
Wie bisher ist der eigentliche Code in 98_Modbus.pm, verwendet wird aber das Frontend 98_ModbusAttr.pm. Dort ist auch die Doku zu finden. Beide Module sollten zum Testen aktualisiert werden.

Gruss
   Stefan

EDIT 1.10.18: angehängte Dateien entfernt, neue Version in späterem Post