Neues Modul für Geräte mit Modbus Schnittstelle über RS232 bzw. RS485

[StefanStrobel]

und hier nochmal ein kleines Update.
Ich hoffe jetzt sind alle bekannten Fehler draussen ...

Gruss
    Stefan

[HenryD]

Seit dem letzen Update hatte ich Probleme mit dem Schreiben mit Funktion 5. Lesen ging, schreiben nicht. Sowohl bei RTU als auch bei TCP. Mit dem Update von 8.12. funktioniert das wieder. SUPER - DANKE.
Ich bekomme aber eine Meldung: "Timeout reading answer". Mir ist nicht bewust, das die vorher auch da war, könnte aber sein. An welcher Schraube kann ich noch drehen, um das weg zu bekommen?

[StefanStrobel]

Hallo HenryD,

Wenn Du das Gerät bzw. bei RTU auch das physische Gerät (IO Device) auf verbose 5 setzt und das Log postest, kann ich vermutlich erkennen, wo das Problem liegt.

Gruß
   Stefan

[HenryD]

Hier das Log vom RTU:
2016.12.12 22:27:20 3: ModBus: timeout waiting for fc 1 from id 2, (c4), Request was 020100040001bc38, last Buffer:
2016.12.12 22:27:22 3: ModBus: timeout waiting for fc 1 from id 2, (c1), Request was 020100010001ac39, last Buffer:
2016.12.12 22:27:24 3: ModBus: timeout waiting for fc 1 from id 2, (c5), Request was 020100050001edf8, last Buffer:
2016.12.12 22:27:26 3: ModBus: timeout waiting for fc 1 from id 2, (c3), Request was 0201000300010df9, last Buffer:
2016.12.12 22:27:57 4: ModBus: HandleSendQueue sends fc 5 to id 2, tid 1 for Einzelleuchte (c3), len 1, device Romutec (RTU), pdu 050003ff00, V 3.5.5 - 8.12.2016
2016.12.12 22:27:57 5: SW: 02050003ff007c09
2016.12.12 22:27:59 3: Romutec: Timeout2 in ReadAnswer for Einzelleuchte
2016.12.12 22:28:12 4: ModBus: HandleSendQueue sends fc 5 to id 2, tid 137 for Einzelleuchte (c3), len 1, device Romutec (RTU), pdu 0500030000, V 3.5.5 - 8.12.2016
2016.12.12 22:28:12 5: SW: 0205000300003df9
2016.12.12 22:28:14 3: Romutec: Timeout2 in ReadAnswer for Einzelleuchte
2016.12.12 22:28:14 4: ModBus: HandleSendQueue sends fc 1 to id 2, tid 143 for Innenwand (c2), len 1, device Romutec (RTU), pdu 0100020001, V 3.5.5 - 8.12.2016
2016.12.12 22:28:14 5: SW: 0201000200015c39
2016.12.12 22:28:16 3: ModBus: timeout waiting for fc 1 from id 2, (c2), Request was 0201000200015c39, last Buffer:
2016.12.12 22:28:16 4: ModBus: HandleSendQueue sends fc 1 to id 2, tid 117 for LichtFensterSeite (c0), len 1, device Romutec (RTU), pdu 0100000001, V 3.5.5 - 8.12.2016
2016.12.12 22:28:16 5: SW: 020100000001fdf9

[Bjoernar]

Hallo,

vielleicht könnt ihr mir ja helfen.
Ich lese meinen Wechselrichter aus und bekomme oft falsche werte.
Eine Sache habe ich vermutlich schon durch timings gelöst.

Aber ich bekomme hier immer mal wieder Werte von genau 655 und die sind dann falsch.

Kann ich irgendwie dafür sorgen das die Werte von 655 einfach verworfen werden?

Code Auswählen Erweitern

expr => 'MinMaxChk($val*10**ReadingsNum($name,".ScaleFactor_Power",0),0,7000,$name,"Power_String1__W")',

Gruß´
Björnar

[StefanStrobel]

Hallo HenryD,

0201000200015c39 sieht absolut korrekt aus. Function code 1 an Modbus Id 2 für Coil 2.
Wenn das Gerät nicht antwortet, scheint es nicht am gesendeten Request zu liegen.
Hat das tatsächlich mit dem alten Modul funktioniert?
Klappt es wenn Du die alte Version zurückspielst?
Oder liegt das Problem vielleicht doch an einer anderen Stelle?

Gruß
   Stefan

[StefanStrobel]

Hallo Bjoernar,

Zum Ignorieren von Werten fällt mir spontan nichts ein.
Ich könnte aber noch ein optionales Attribut einbauen, mit dem man eine Ignorier-Bedingung festlegen kann. Sollte nicht schwer sein.

Gruß
    Stefan

[Bjoernar]

Hallo Bjoernar,

Zum Ignorieren von Werten fällt mir spontan nichts ein.
Ich könnte aber noch ein optionales Attribut einbauen, mit dem man eine Ignorier-Bedingung festlegen kann. Sollte nicht schwer sein.

Gruß
    Stefan

Das klingt gut.
Warum Fronius die Werte ab und zu zurück gibt ist mir unklar. Steht auch nichts dazu in der Doku.

Gesendet von meinem Moto G (4) mit Tapatalk

[wthiess]

Sowas ist bekannt bei 1-Wire Bus bei unsauberer Verkabelung/Terminierung. Da ist es die 85 die immer wieder kommt.  Bei Modbus habe ich mit billigen Adaptern/Terminierung auch schon diverse Probleme.

Lg Wolfgang

[Bjoernar]

Mit dem WR spreche ich über TCP bei den RTU Geräten habe ich diese Probleme nicht. Also kein Terminierungsproblem

Gesendet von meinem Moto G (4) mit Tapatalk

[Bjoernar]

...bei den DS18B20 habe ich das auch drin, hatte auch diese Probleme:

Code Auswählen Erweitern

if ($1 ne "655") {...}

Kann ich das denn so in die expr einbauen?

Ich habe auch noch einen anderen Indikator dafür:
Nur wenn das reading 4 oder 5 zurückgibt macht es überhaupt Sinn die anderen Readings abzufragen.

Code Auswählen Erweitern


"h40290" => { # float
# "h40280" => { # int+SF
# Start: +28, Länge: 1, enum16; String 1: Operating State
name => "1_DCSt", # internal name of this register in the hardware doc
reading => "Operating_State_String1",# name of the reading for this value
len => 1, # number of Registers this value spans
unpack => "n", # defines the translation between data in the module and in the communication frame
map => "1:Off, 2:in.operation(no.feed-in), 3:Run-up.phase, 4:normal.operation, 5:Power.Reduction, 6:Switch-off.phase, 7:Error.exists, 8:Standby", # map to convert visible values to internal numbers (for reading and writing)
polldelay => "x1", # only poll this Value if last read is older than 5*Iteration, otherwiese getUpdate will skip it
},

[HenryD]

Hallo HenryD,

0201000200015c39 sieht absolut korrekt aus. Function code 1 an Modbus Id 2 für Coil 2.
Wenn das Gerät nicht antwortet, scheint es nicht am gesendeten Request zu liegen.
Hat das tatsächlich mit dem alten Modul funktioniert?
Klappt es wenn Du die alte Version zurückspielst?
Oder liegt das Problem vielleicht doch an einer anderen Stelle?

Gruß
   Stefan

Hallo Stefan,
Ich bin mir nicht sicher, ob es vorher Fehlermeldungen gab. Die Relais werden und wurden auf jeden Fall geschalten. Den alten Stand möchte ich nicht zurückspielen. Es funktioniert gerade alles so schön 
Ich werde mal direkt auf dem 485er Bus mitschneiden und  schauen was da so passiert. Timeouts würde ich da ja sehen.

[Allgaeuer]

Hallo Stefan,

beim Schreiben auf Holding-Register 0 (zumindest mit Länge 1) geht FHEM in eine Endlosschleife (siehe Log-Auszug). Holding-Register 1 funktioniert. Auch mit Deiner neuesten Version vom 04.12.2016 habe ich den Fehler.

Code Auswählen Erweitern

2016.12.16 13:40:35.197 5: Pressure_Meter_1_6bar: Set: key for Pressure_unit = h0000
2016.12.16 13:40:35.199 5: Pressure_Meter_1_6bar: Set: found option Pressure_unit (h0000), setVal = 6
2016.12.16 13:40:35.202 5: Pressure_Meter_1_6bar: set packed 36 with S> to 0006
2016.12.16 13:40:35.203 4: Pressure_Meter_1_6bar: Send called with h0000, len 1 / span - to id 100, queue has 0 requests
2016.12.16 13:40:35.205 4: Pressure_Meter_1_6bar: Send queues fc 6 to 100, tid 0 for h0000 (Pressure_unit), len/span 1, PDU 0600000006, force
2016.12.16 13:40:35.214 5: Pressure_Meter_1_6bar: ReadAnswer called and remaining timeout is 1.99818801879883 requested reading is Pressure_unit
2016.12.16 13:40:35.219 5: Pressure_Meter_1_6bar: ReadAnswer got: 640600000006003d
2016.12.16 13:40:35.221 3: ModbusLine1: ParseFrames got a copy of the request sent before - looks like an echo!
2016.12.16 13:40:35.223 5: Pressure_Meter_1_6bar: ParseObj called with 0006 and start 0
2016.12.16 13:40:35.225 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.226 1: PERL WARNING: Use of uninitialized value $len in addition (+) at ./FHEM/98_Modbus.pm line 509.
2016.12.16 13:40:35.228 1: PERL WARNING: Use of uninitialized value $len in multiplication (*) at ./FHEM/98_Modbus.pm line 510.
2016.12.16 13:40:35.229 1: PERL WARNING: Use of uninitialized value $len in multiplication (*) at ./FHEM/98_Modbus.pm line 511.
2016.12.16 13:40:35.230 1: PERL WARNING: Use of uninitialized value $len in concatenation (.) or string at ./FHEM/98_Modbus.pm line 516.
2016.12.16 13:40:35.231 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.232 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.234 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.235 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.236 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.237 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.240 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.241 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.242 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.243 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.245 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.246 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.247 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.249 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.251 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.252 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0
2016.12.16 13:40:35.253 5: Pressure_Meter_1_6bar: ParseObj moves to next object, skip  to h0
2016.12.16 13:40:35.254 5: Pressure_Meter_1_6bar: ParseObj has no parseInfo for h0

Ich traue mich nicht an Deinen Code ran, kannst Du bei Gelegenheit mal nachschauen.

Danke und Gruß,

Allgäuer

[vuffiraa]

Hallo,

ich wollte per Modbus TCP auf meinen Fronius Wechselrichter zugreifen und bin der Anleitung aus dem Thread gefolgt.

Leider gibt es schon mit dem ersten define ein Problem (define myMb Modbus):

Code Auswählen Erweitern

2016.12.16 16:53:00 5: Cmd: >define myMb Modbus<
2016.12.16 16:53:00 5: Loading ./FHEM/98_Modbus.pm
2016.12.16 16:53:00 1: PERL WARNING: Use of uninitialized value $dev in string eq at ./FHEM/98_Modbus.pm line 221.
2016.12.16 16:53:00 3: Opening myMb device
2016.12.16 16:53:00 1: PERL WARNING: Use of uninitialized value $nameOrConf in -f at /usr/lib/x86_64-linux-gnu/perl5/5.22/Device/SerialPort.pm line 285.
2016.12.16 16:53:00 1: PERL WARNING: Use of uninitialized value in subroutine entry at /usr/lib/x86_64-linux-gnu/perl5/5.22/Device/SerialPort.pm line 312.
2016.12.16 16:53:00 3: Can't open : No such file or directory
2016.12.16 16:53:00 1: PERL WARNING: Use of uninitialized value $dev in concatenation (.) or string at ./FHEM/98_Modbus.pm line 228.
2016.12.16 16:53:00 1: define myMb Modbus:  could not be openend yet
2016.12.16 16:53:00 4: name: /fhem&fw_id=43&room=Unsorted&cmd=define+myMb+Modbus / RL:1192 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.16 16:53:00 0: Strange call for nonexistent myMb: ReadyFn
2016.12.16 16:53:00 0: Strange call for nonexistent myMb: ReadyFn
2016.12.16 16:53:01 0: Strange call for nonexistent myMb: ReadyFn

Die letzte Melduhg wiederholt sich dann im 2-3 Sekunden Takt

Kann mir jemand sagen, was hier schief geht und wie ich das beheben kann?

Gruß
vuffiraa

[StefanStrobel]

Hallo vuffiraa,

der

Code Auswählen Erweitern

define myMb Modbus
sollte gar nicht nötig sein und ist so eigentlich nicht vorgesehen.
Die Module wie Fronius_Modbus laden 98_Modbus.pm eigentlich automatisch.
Unabhängig davon habe ich nochmal eine neue Version angehängt, die auch bei so einer "leeren" Definition den Fehler vermeidet.

Gruss
    Stefan