Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Hallo hauwech,

schau doch mal ECMD an:
https://fhem.de/commandref.html#ECMD

Gruss
   Stefan

[hauwech]

Danke für den Tip!

Gruß Roland

[Regmus]

Hallo zusammen,

ich bin seit ein paar Tagen am rumversuchen, ein "Power Meter" (PM3-63 ähnlich Stromzähler mit mehr Funktionen) über Modbus auszulesen.
Habe dazu am Raspberrry-Fhem einen Digitus USB - RS485 Schnittstelle dran und meiner Meinung auch richtig in Fhem eingebunden.
Aktuell sieht das so aus (an den Verbindungseinstellungen hinten habe ich schon rumgetestet und natürlich auch am Stromzähler entsprechend umgestellt)

Code Auswählen Erweitern

defmod Modbus Modbus /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600LOZQ-if00-port0@1200,8,N,2

Die Definition vom Gerät sieht aktuell so aus:

Code Auswählen Erweitern

defmod NQA ModbusAttr 3 0
attr NQA userattr IODev dev-timing-commDelay dev-timing-sendDelay dev-timing-timeout enableControlSet obj-h4151-len obj-h4151-reading obj-h4151-showGet obj-h4151-unpack verbose
attr NQA IODev Modbus
attr NQA dev-timing-commDelay 1
attr NQA dev-timing-sendDelay 1
attr NQA dev-timing-timeout 10
attr NQA enableControlSet 1
attr NQA obj-h4151-len 2
attr NQA obj-h4151-reading PowerL1
attr NQA obj-h4151-showGet 1
attr NQA obj-h4151-unpack f>
attr NQA room Modbus
attr NQA verbose 5

Im Log bekomm ich solche Fehlermeldungen:

Code Auswählen Erweitern

2018.02.26 06:40:35 5: NQA: Get: Called with PowerL1 (h4151)
2018.02.26 06:40:35 4: NQA: Send called with h4151, objLen 2 / reqLen - to id 3, op read, qlen 0
2018.02.26 06:40:35 4: NQA: Send adds fc 3 to 3, for h4151 (PowerL1), reqLen 2 at beginning of queue for immediate sending
2018.02.26 06:40:35 5: Modbus: HandleSendQueue: finished delay checking, proceed with sending
2018.02.26 06:40:35 4: Modbus: HandleSendQueue sends fc 3 to id 3, tid 219 for PowerL1 (h4151), len 2, device NQA (RTU), pdu 0310370002, V 3.7.3 - 22.12.2017
2018.02.26 06:40:35 5: SW: 03031037000270e7
2018.02.26 06:40:35 5: NQA: ReadAnswer called and remaining timeout is 9.99958610534668 requested reading is PowerL1
2018.02.26 06:40:35 5: NQA: ReadAnswer got: 00
2018.02.26 06:40:35 5: Modbus: ParseFrames got: 00
2018.02.26 06:40:35 5: NQA: ReadAnswer got: 0003
2018.02.26 06:40:35 5: Modbus: ParseFrames got: 0003
2018.02.26 06:40:35 5: NQA: ReadAnswer got: 000303
2018.02.26 06:40:35 5: Modbus: ParseFrames got: 000303
2018.02.26 06:40:35 5: NQA: ReadAnswer got: 00030304
2018.02.26 06:40:35 5: Modbus: ParseFrames got: 00030304
2018.02.26 06:40:35 5: NQA: ReadAnswer got: 000303043f
2018.02.26 06:40:35 5: Modbus: ParseFrames got: 000303043f
2018.02.26 06:40:35 5: NQA: ReadAnswer: ParseFrames returned error: recieved frame from unexpected Modbus Id 0, expecting fc 3 from 3 for device NQA
2018.02.26 06:40:35 5: Modbus: raw read: ba
2018.02.26 06:40:35 5: Modbus: ParseFrames returned error: got data but did not send a request - ignoring
2018.02.26 06:40:35 5: Modbus: raw read: 08
2018.02.26 06:40:35 5: Modbus: ParseFrames returned error: got data but did not send a request - ignoring
2018.02.26 06:40:35 5: Modbus: raw read: 18
2018.02.26 06:40:35 5: Modbus: ParseFrames returned error: got data but did not send a request - ignoring
2018.02.26 06:40:35 5: Modbus: raw read: f3
2018.02.26 06:40:35 5: Modbus: ParseFrames returned error: got data but did not send a request - ignoring
2018.02.26 06:40:35 5: Modbus: raw read: c8
2018.02.26 06:40:35 5: Modbus: ParseFrames returned error: got data but did not send a request - ignoring
2018.02.26 06:40:35 5: Modbus: raw read: 00
2018.02.26 06:40:35 5: Modbus: ParseFrames returned error: got data but did not send a request - ignoring

Mit dem Attribut obj-hXXX-len habe ich auch schon herumgespielt. Laut Doku vom Zähler hat das Register 4151 eine Länge von 4 Bytes. Also sollte len 2 ja passen!?!
Link zur Modbus-Doku https://www.janitza.com/manuals.html?file=files/download/manuals/current/ECS-Series/Janitza-Technical-description-Modbus-Protocol-en.pdf

Die Verbindung zwischen Raspberry (mit Digitus USB-RS485) zum PowerMeter/Stromzähler habe ich mit einem 1m langen Cat7 Kabel gemacht und hinten und vorne einen 120Ohm Widerstand als Abschluss geklemmt. Cat7 hab ich genommen, da dies mit 100 Ohm Wellenwiderstand am nächsten an das kommt, was laut Spezifikation vorgesehen ist (120 Ohm)
Jetzt bin ich mir aber nicht sicher, ob die Fehlermeldungen evtl. daher kommen, weil das Kabel Reflexionen oder ähnliches hervorruft.

Hatte das evtl. schon mal jemand oder hat jemand ne Idee was ich noch versuchen könnte?

Danke im Voraus!

Michael

[StefanStrobel]

Hallo Michael,

Das sieht für mich so aus, als ob Du eine valide Antwort vom Messgerät bekommst, vor der ein überflüssiges 00 steht. Probier mal das Attribut skipGarbage.

Gruß
    Stefan

[Regmus]

Hallo Michael,

Das sieht für mich so aus, als ob Du eine valide Antwort vom Messgerät bekommst, vor der ein überflüssiges 00 steht. Probier mal das Attribut skipGarbage.

Gruß
    Stefan

Hallo Stefan,

ich bin echt begeistert das es manchmal so einfach sein kann... manchmal sollte man einfach lieber ein wenig früher fragen, als sich 5 Tage damit zu beschäftigen und extra noch einen neuen Digitus USB-RS485 Konverter zu kaufen :-D

Das fehlende Attribut war genau das Problem! DANKE!

Gruß Michael

[HP]

Hallo zusammen,

ich habe gerade auch ein kleines Problem mit bei der Anbindung von FHEM mit einer Wago 750-849.

ich hab des Modbus Modul wie im Commandref beschrieben angelegt. Die IP entspricht dabei der der Wago SPS.

Code Auswählen Erweitern

define ModbusTCP ModbusAttr 5 60 192.168.100.8:502 TCP
attr ModbusTCP room Modbus

In der Wago habe ich folgende Globale Variablen angelegt.

Code Auswählen Erweitern

   SPS_Bit1_IPS_Adresse_12288  AT %MX0.0:BOOL;   (*Modbusadresse 12288*)
   SPS_Bit17_IPS_Adresse_12304  AT %MX1.0:BOOL;   (*Modbusadresse 12304*)
   SPS_Bit33_IPS_Adresse_12320  AT %MX2.0:BOOL;   (*Modbusadresse 12320*)
   SPS_Bit49_IPS_Adresse_12336  AT %MX3.0:BOOL;   (*Modbusadresse 12336*)
   SPS_BYTE101_IPS_Adresse_12338 AT %MB101 :BYTE;   (*Modbusadresse 12338*)
   SPS_Word100_IPS_Adresse_12388 AT %MW100 :WORD;   (*Modbusadresse 12388*)
   SPS_INT200_IPS_Adresse_12488 AT %MW200 :INT;   (*Modbusadresse 12488*)
   SPS_SINT400_IPS_Adresse_12688 AT %MW400 :SINT;   (*Modbusadresse 12688*)
   SPS_SINT416_IPS_Adresse_12704 AT %MW416 :SINT;   (*Modbusadresse 12704*)
   SPS_REAL500_IPS_Adresse_13288 AT %MD500 :REAL;   (*Modbusadresse 13288*)

Jedoch habe ich noch nicht erkannt, wie ich über FHEM zuerst nur einen Digitalenwert lesen bzw. schreiben und später einen Temperaturwert übertragen kann.

Ich hoffe mir kann jemand weiterhelfen.

VG Stefan

[StefanStrobel]

Jedoch habe ich noch nicht erkannt, wie ich über FHEM zuerst nur einen Digitalenwert lesen bzw. schreiben und später einen Temperaturwert übertragen kann.

Was genau möchtest Du den machen?

Wenn Du ein ,,holding register" (Modbus-Bezeichnung für 16-Bit-Objekte, die mit function code 3 gelesen und mit function code 6 geschrieben werden) lesen möchtest, dann musst Du das Objekt mit den Attributen von ModbusAttr (obj-hxxxx-...) definieren. Danach kannst Du den Wert entweder zyklisch Abfragen lassen oder mit get explizit einen Request senden bzw. mit set den Wert ändern.
Die Datentypen müssen ebenfalls angegeben werden, damit Fhem die Werte passend interpretieren kann.
In der commandref zu ModbusAttr und den Beiträgen hier im Forum findest Du Beispiele.

Gruß
    Stefan

[Herjemine]

Hallo Stefan,

ich habe jetzt eine RS232 Modbus Wallbox angeschlossen,
aber 2 Probleme.

Lesen geht nur per get
hier die Config

Code Auswählen Erweitern


define EVSE_Box ModbusAttr 1 60
attr EVSE_Box IODev ModbusRS232
attr EVSE_Box dev-h-combine 5
attr EVSE_Box dev-h-defPoll 1
attr EVSE_Box dev-h-defShowGet 1
attr EVSE_Box obj-h1000-reading Ladestrom
attr EVSE_Box obj-h1000-set 1
attr EVSE_Box obj-h1001-reading Akt_Ladestrom
attr EVSE_Box obj-h1002-reading Fahrzeugstatus
attr EVSE_Box obj-h1003-reading Max_Strom
attr EVSE_Box obj-h1004-reading LadenStop
attr EVSE_Box obj-h1004-set 1
attr EVSE_Box obj-h2000-reading Def_Ladestrom
attr EVSE_Box obj-h2000-set 1
attr EVSE_Box obj-h2001-reading ModbusAktiv
attr EVSE_Box obj-h2001-set 1
attr EVSE_Box obj-h2004-reading StromWertSpeichern
attr EVSE_Box obj-h2004-set 1
attr EVSE_Box room Leaf
attr EVSE_Box verbose 5


wie kann ich es überreden, das es pollt?

Leider kann man bei dem Gerät nur mit WriteMultipleRegister 0x10 schreiben,
siehe Screenshot von Qmodbus

Ich hab es dann mal mit attr EVSE_Box dev-h-write 10 versucht, aber das mag er nicht
siehe Log

Code Auswählen Erweitern


2018.03.28 21:09:52 5: EVSE_Box: Get: Called with Ladestrom (h1000)
2018.03.28 21:09:52 4: EVSE_Box: Send called with h1000, objLen 1 / reqLen - to id 1, op read, qlen 1
2018.03.28 21:09:52 4: EVSE_Box: Send adds fc 3 to 1, for h1000 (Ladestrom), reqLen 1 at beginning of queue for immediate sending
2018.03.28 21:09:52 5: ModbusRS232: handle queue check commDelay (0.1) for EVSE_Box: rest -29.1478931903839
2018.03.28 21:09:52 5: ModbusRS232: handle queue check sendDelay (0.1) for EVSE_Box: rest -31.1506311893463
2018.03.28 21:09:52 5: ModbusRS232: HandleSendQueue: finished delay checking, proceed with sending
2018.03.28 21:09:52 4: ModbusRS232: HandleSendQueue sends fc 3 to id 1, tid 254 for Ladestrom (h1000), len 1, device EVSE_Box (RTU), pdu 0303e80001, V 3.5.27 - 15.7.2017
2018.03.28 21:09:52 5: SW: 010303e80001047a
2018.03.28 21:09:52 5: EVSE_Box: ReadAnswer called and remaining timeout is 1.99951982498169 requested reading is Ladestrom
2018.03.28 21:09:54 5: EVSE_Box: ReadAnswer got: 010302000a3843
2018.03.28 21:09:54 5: ModbusRS232: ParseFrames got: 010302000a3843
2018.03.28 21:09:54 4: ModbusRS232: ParseFrames got fcode 3 from 1, values 000aHeaderLen 2, ActualLen 2, request was for h1000 (Ladestrom), len 1 for module EVSE_Box
2018.03.28 21:09:54 5: EVSE_Box: ParseObj called with 000a and start 1000, op read
2018.03.28 21:09:54 5: EVSE_Box: ParseObj ObjInfo for h1000: reading=Ladestrom, unpack=n, expr=, format=, map=
2018.03.28 21:09:54 5: EVSE_Box: ParseObj unpacked 000a with n to hex 3130 (10)
2018.03.28 21:09:54 4: EVSE_Box: ParseObj for Ladestrom assigns 10
2018.03.28 21:09:54 5: ModbusRS232: ParseFrames got 1 readings from ParseObj
2018.03.28 21:09:54 5: EVSE_Box: ReadAnswer done, reading is Ladestrom, value: 10
2018.03.28 21:09:55 5: ModbusRS232: handle queue check commDelay (0.1) for EVSE_Box: rest -1.32952213287354
2018.03.28 21:09:55 5: ModbusRS232: handle queue check sendDelay (0.1) for EVSE_Box: rest -3.33654522895813
2018.03.28 21:09:55 5: ModbusRS232: HandleSendQueue: finished delay checking, proceed with sending
2018.03.28 21:09:55 3: ModbusRS232: Send function code 10 not yet implemented
2018.03.28 21:10:18 5: EVSE_Box: Set called with Ladestrom (h1000), setVal = 6
2018.03.28 21:10:18 5: EVSE_Box: set packed hex 36 with n to hex 0006
2018.03.28 21:10:18 4: EVSE_Box: Send called with h1000, objLen 1 / reqLen - to id 1, op write, qlen 1, value hex 0006
2018.03.28 21:10:18 4: EVSE_Box: Send adds fc 10 to 1, for h1000 (Ladestrom), reqLen 1, value hex 0006 at beginning of queue for immediate sending
2018.03.28 21:10:18 5: ModbusRS232: handle queue check commDelay (0.1) for EVSE_Box: rest -24.3746891021729
2018.03.28 21:10:18 5: ModbusRS232: handle queue check sendDelay (0.1) for EVSE_Box: rest -26.3816912174225
2018.03.28 21:10:18 5: ModbusRS232: HandleSendQueue: finished delay checking, proceed with sending
2018.03.28 21:10:18 3: ModbusRS232: Send function code 10 not yet implemented
2018.03.28 21:10:18 5: EVSE_Box: ReadAnswer called for Ladestrom
2018.03.28 21:10:20 3: EVSE_Box: Timeout in ReadAnswer for Ladestrom
2018.03.28 21:10:32 5: EVSE_Box: Get: Called with Ladestrom (h1000)
2018.03.28 21:10:32 4: EVSE_Box: Send called with h1000, objLen 1 / reqLen - to id 1, op read, qlen 2
2018.03.28 21:10:32 4: EVSE_Box: Send adds fc 3 to 1, for h1000 (Ladestrom), reqLen 1 at beginning of queue for immediate sending
2018.03.28 21:10:32 5: ModbusRS232: handle queue check commDelay (0.1) for EVSE_Box: rest -38.3785700798035
2018.03.28 21:10:32 5: ModbusRS232: handle queue check sendDelay (0.1) for EVSE_Box: rest -40.3857681751251
2018.03.28 21:10:32 5: ModbusRS232: HandleSendQueue: finished delay checking, proceed with sending
2018.03.28 21:10:32 4: ModbusRS232: HandleSendQueue sends fc 3 to id 1, tid 91 for Ladestrom (h1000), len 1, device EVSE_Box (RTU), pdu 0303e80001, V 3.5.27 - 15.7.2017
2018.03.28 21:10:32 5: SW: 010303e80001047a
2018.03.28 21:10:32 5: EVSE_Box: ReadAnswer called and remaining timeout is 1.99957513809204 requested reading is Ladestrom
2018.03.28 21:10:34 5: EVSE_Box: ReadAnswer got: 010302000a3843
2018.03.28 21:10:34 5: ModbusRS232: ParseFrames got: 010302000a3843
2018.03.28 21:10:34 4: ModbusRS232: ParseFrames got fcode 3 from 1, values 000aHeaderLen 2, ActualLen 2, request was for h1000 (Ladestrom), len 1 for module EVSE_Box
2018.03.28 21:10:34 5: EVSE_Box: ParseObj called with 000a and start 1000, op read
2018.03.28 21:10:34 5: EVSE_Box: ParseObj ObjInfo for h1000: reading=Ladestrom, unpack=n, expr=, format=, map=
2018.03.28 21:10:34 5: EVSE_Box: ParseObj unpacked 000a with n to hex 3130 (10)
2018.03.28 21:10:34 4: EVSE_Box: ParseObj for Ladestrom assigns 10
2018.03.28 21:10:34 5: ModbusRS232: ParseFrames got 1 readings from ParseObj
2018.03.28 21:10:34 5: EVSE_Box: ReadAnswer done, reading is Ladestrom, value: 10
2018.03.28 21:10:34 5: ModbusRS232: handle queue check commDelay (0.1) for EVSE_Box: rest 0.0839829444885254
2018.03.28 21:10:34 4: ModbusRS232: HandleSendQueue / CheckDelay commDelay (0.1) for EVSE_Box not over, try again in 0.0839829444885254
2018.03.28 21:10:34 5: ModbusRS232: handle queue check commDelay (0.1) for EVSE_Box: rest -0.00146007537841797
2018.03.28 21:10:34 5: ModbusRS232: handle queue check sendDelay (0.1) for EVSE_Box: rest -2.00452899932861
2018.03.28 21:10:34 5: ModbusRS232: HandleSendQueue: finished delay checking, proceed with sending
2018.03.28 21:10:34 3: ModbusRS232: Send function code 10 not yet implemented


ist eventuell einmal geplant WriteMultipleRegister auch zu implementieren oder kann das bereits jetzt anders gelöst werden?

Vielen Dank.

Gruß
Hermann

[StefanStrobel]

Hallo Hermann,

Adressen und Function Codes werden im Modbus-Modul in dezimaler Schreibweise angegeben.
0x10 ist supported, aber entspricht nicht 10 dezimal

Leider sehe ich im Log nicht woran das Pollen scheitert. Eventuell am combine 5?
Schick doch einfach noch mal einen Log-Auszug, in dem man den Ablauf bei GetUpdate sieht.

Gruß
    Stefan

[Herjemine]

Hallo Stefan,

danke, muss ich das irgendwie speziell eintragen?

Jetzt kommt dafür die perl Warnung das es nicht Numerisch ist wen ich es direkt setze mit
attr EVSE_Box dev-h-write =0x10

Code Auswählen Erweitern


2018.03.29 11:39:48 5: EVSE_Box: Set called with Ladestrom (h1000), setVal = 8
2018.03.29 11:39:48 5: EVSE_Box: set packed hex 38 with n to hex 0008
2018.03.29 11:39:48 4: EVSE_Box: Send called with h1000, objLen 1 / reqLen - to id 1, op write, qlen 0, value hex 0008
2018.03.29 11:39:48 4: EVSE_Box: Send adds fc 0x10 to 1, for h1000 (Ladestrom), reqLen 1, value hex 0008 at beginning of queue for immediate sending
2018.03.29 11:39:48 5: ModbusRS232: handle queue check commDelay (0.1) for EVSE_Box: rest -47513.8615100384
2018.03.29 11:39:48 5: ModbusRS232: handle queue check sendDelay (0.1) for EVSE_Box: rest -47515.8635442257
2018.03.29 11:39:48 5: ModbusRS232: HandleSendQueue: finished delay checking, proceed with sending
2018.03.29 11:39:48 1: PERL WARNING: Argument "0x10" isn't numeric in numeric eq (==) at ./FHEM/98_Modbus.pm line 1287.
2018.03.29 11:39:48 3: ModbusRS232: Send function code 0x10 not yet implemented
2018.03.29 11:39:48 5: EVSE_Box: ReadAnswer called for Ladestrom
2018.03.29 11:39:50 3: EVSE_Box: Timeout in ReadAnswer for Ladestrom


ah wenn ich es direkt als Zahl dev-h-write 16 Eintrage nimmt er es 
sorry, schon länger nicht mehr hex gedacht 

thx & Gruß
Hermann

[Herjemine]

Hallo Stefan,

danke für die Unterstützung, jetzt läufts 

nach change des Intervals im DEF hat er angefangen zu Pollen im Log,
hatte noch immer wegen dem 0x10 im Log gejammert,
nach fhem neustart funzt es jetzt   

Gruß Hermann

[fhainz]

Hallo!

Ich versuche gerade meine Lüftungsanlage in FHEM zu integrieren. Hab aber mit einem seltsamen verhalten zu kämpfen:
Nach einem scan von zB h0-5 werden bei mir die scan-* readings angelegt und mit schlüssigen werten gefüllt. Nachdem ich das attribut dev-h-defPoll auf 1 setze werden die werte zwar aktualisiert, aber die werte stimmen ich mehr. Anbei 2 lists des devices vor und nach dem setzen des poll attributs. Ich hab auch schon einge unpack varianten versucht, aber die werten stimmen nie.

Kann mir jemand weiterhelfen?

poll nicht gesetzt.

Code Auswählen Erweitern


Internals:
   DEF        20 60
   DEST       
   INTERVAL   60
   IODev      ModBusLine
   LeadingZeros 1
   MODBUSID   20
   ModuleVersion 3.7.3 - 22.12.2017
   NAME       modbusAttr
   NOTIFYDEV  global
   NR         39
   NTFY_ORDER 50-modbusAttr
   PROTOCOL   RTU
   STATE      ???
   TRIGGERTIME 1530390809.15651
   TRIGGERTIME_FMT 2018-06-30 20:33:29
   TYPE       ModbusAttr
   OLDREADINGS:
   READINGS:
     2018-06-30 20:32:56   scan-h000000    0
     2018-06-30 20:32:57   scan-h000001    1
     2018-06-30 20:32:58   scan-h000002    2
     2018-06-30 20:32:59   scan-h000003    1210
     2018-06-30 20:33:00   scan-h000004    1060
     2018-06-30 20:33:01   scan-h000005    1230
   gotReadings:
     scan-h000005 1230
   helper:
     lrecv      1530390781.62507
     lsend      1530390781.60736
   lastRead:
     h0         1530390776.66564
     h000000    1530390689.19264
     h000001    1530390689.70395
     h000002    1530390689.83253
     h000003    1530390689.32096
     h000004    1530390689.44835
     h000005    1530390689.57685
     h000006    1530390689.95983
     h1         1530390777.67015
     h2         1530390778.66053
     h3         1530390779.66717
     h4         1530390780.68096
     h5         1530390781.66535
Attributes:
   IODev      ModBusLine
   dev-h-defExpr ModbusLD_ScanFormat($hash, $val)
   dev-h-defLen 1
   dev-h-defUnpack a2
   enableControlSet 1
   obj-h000000-reading scan-h000000
   obj-h000001-reading scan-h000001
   obj-h000002-reading scan-h000002
   obj-h000003-reading scan-h000003
   obj-h000004-reading scan-h000004
   obj-h000005-reading scan-h000005

poll gesetzt:

Code Auswählen Erweitern

Internals:
   DEF        20 60
   DEST       
   INTERVAL   60
   IODev      ModBusLine
   LeadingZeros 1
   MODBUSID   20
   ModuleVersion 3.7.3 - 22.12.2017
   NAME       modbusAttr
   NOTIFYDEV  global
   NR         39
   NTFY_ORDER 50-modbusAttr
   PROTOCOL   RTU
   STATE      ???
   TRIGGERTIME 1530390929.15972
   TRIGGERTIME_FMT 2018-06-30 20:35:29
   TYPE       ModbusAttr
   OLDREADINGS:
   READINGS:
     2018-06-30 20:34:29   scan-h000000    hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-06-30 20:34:29   scan-h000001    hex=0001, string=.., s=256, s>=1, S=256, S>=1
     2018-06-30 20:34:29   scan-h000002    hex=0002, string=.., s=512, s>=2, S=512, S>=2
     2018-06-30 20:34:29   scan-h000003    hex=04ba, string=.., s=-17916, s>=1210, S=47620, S>=1210
     2018-06-30 20:34:29   scan-h000004    hex=0424, string=.$, s=9220, s>=1060, S=9220, S>=1060
     2018-06-30 20:34:29   scan-h000005    hex=04ce, string=.., s=-12796, s>=1230, S=52740, S>=1230
   gotReadings:
     scan-h000000 hex=0000, string=.., s=0, s>=0, S=0, S>=0
   helper:
     lrecv      1530390869.83458
     lsend      1530390869.80996
   lastRead:
     h0         1530390776.66564
     h000000    1530390869.84011
     h000001    1530390869.45715
     h000002    1530390869.3286
     h000003    1530390869.71269
     h000004    1530390869.58422
     h000005    1530390869.20154
     h000006    1530390689.95983
     h1         1530390777.67015
     h2         1530390778.66053
     h3         1530390779.66717
     h4         1530390780.68096
     h5         1530390781.66535
Attributes:
   IODev      ModBusLine
   dev-h-defExpr ModbusLD_ScanFormat($hash, $val)
   dev-h-defLen 1
   dev-h-defPoll 1
   dev-h-defUnpack a2
   enableControlSet 1
   obj-h000000-reading scan-h000000
   obj-h000001-reading scan-h000001
   obj-h000002-reading scan-h000002
   obj-h000003-reading scan-h000003
   obj-h000004-reading scan-h000004
   obj-h000005-reading scan-h000005

Edit:
Nach löschen des dev-h-defLen und dev-h-defPoll attribut, funktioniert nun alles!

[Fistandantilus]

Hi,

vielen Dank erstmal für Eure Arbeit. Ich versuche gerade meine Poolsteuerung auszulesen, kommen allerdings nicht mit den Readings klar. Basierend auf einer Aussage aus einem anderen Forum sollen die Daten 1:1 drin stehen und müssen nur beispielsweise beim PH Wert durch 100 geteilt werden. Im Register 102 sollte für einen PH-Wert von 7,1 Werte von 710-719 stehen, bei mit wird 319 ausgelesen. Ich hab schon vieles getestet, aber mehr mit meinem Unwissen rumgestochert. Vielleicht habt Ihr einen konkreten Ansatz, was ich probieren könnte.
Meine config sieht wie folgt aus:

Code Auswählen Erweitern

my %BrilixParseInfo = (
# MEASURE
'h100' => { reading => 'MBF_ION_CURRENT',
name => 'ION_CURR',
poll => 1
},
'h101' => { reading => 'MBF_HIDRO_CURRENT',
name => 'HIDRO_CURR',
poll => 1
},
'h102' => { reading => 'MBF_MEASURE_PH',
name => 'PH_MEASURE',
poll => 1
},
'h103' => { reading => 'MBF_MEASURE_RX',
name => 'RX_MEASURE',
poll => 1
},
'h104' => { reading => 'MBF_MEASURE_CL',
name => 'CL_MEASURE',
poll => 1
},
'h105' => { reading => 'MBF_MEASURE_105',
name => '105_MEASURE',
poll => 1
},
'h106' => { reading => 'MBF_MEASURE_TEMP',
name => 'TEMP_MEASURE',
poll => 1
},
'h107' => { reading => 'MBF_PH_STATUS',
name => 'PH_STATUS',
poll => 1
},
'h108' => { reading => 'MBF_RX_STATUS',
name => 'RX_STATUS',
poll => 1
},
'h109' => { reading => 'MBF_CL_STATUS',
name => 'CL_STATUS',
poll => 1
},
'h1010' => { reading => 'MBF_CD_STATUS',
name => 'CD_STATUS',
poll => 1
},
'h1012' => { reading => 'MBF_ION_STATUS',
name => 'ION_STATUS',
poll => 1
},
'h1014' => { reading => 'MBF_HIDRO_STATUS',
name => 'HIDRO_STATUS',
poll => 1
},
'h1015' => { reading => 'MBF_RELAY_STATE',
name => 'RELAY_STATE',
poll => 1
},

#USER PAGE
'h508' => { reading => 'MBF_PAR_RX1',
name => 'PAR_RX1',
poll => 1
},
'h5016' => { reading => 'MBF_PAR_CL1',
name => 'PAR_CL1',
poll => 1
},
);

my %BrilixDeviceInfo = (
'h' => {defShowGet => 1,
combine => 5
},
'c' => {defShowGet => 1,
combine => 5
},
'timing' => {sendDelay => 0.2,
commDelay => 0.2
}
);


#####################################
sub ModbusBrilix_Initialize($) {
my ($hash) = @_;

require "$attr{global}{modpath}/FHEM/98_Modbus.pm";
$hash->{parseInfo}  = \%BrilixParseInfo;  # defines registers, inputs, coils etc. for this Modbus Device
$hash->{deviceInfo} = \%BrilixDeviceInfo; # defines properties of the device like defaults and supported function codes

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

$hash->{AttrList} .= ' '.$hash->{ObjAttrList}.' '.$hash->{DevAttrList}.' poll-.* polldelay-.*';
}

1;

Ansonsten habe ich noch folgende Attribute definiert:

Code Auswählen Erweitern

dev-h-combine 5
dev-h-defPoll 1
dev-h-defShowGet 1

Habt Ihr eine Idee? Das Problem habe ich bei allen Registern, alle Werte passen nicht.

VG
F.

[wthiess]

dir ist schon klar das immer -1 beim Register genommen wird. Dh. 102 = 101

lg
Wolfgang

[Fistandantilus]

Danke Dir, das mit dem -1 war mir bisher nicht bewußt. Das hab ich korrigiert, allerdings ändert das nicht die Tatsache, das die Werte nicht passen:

Code Auswählen Erweitern


MBF_MEASURE_PH 2038
MBF_MEASURE_TEMP 1636

Bei PH müsste wie gesagt irgendwas zwischen 710-719 stehen, bei der Temperatur 250-269 (25 oder 26 Grad, hab ich nicht nochmal gegengecheckt).

VG