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

[StefanStrobel]

Hallo,

offenbar hat der Hersteller hier Modbus "interpretiert" und für die Adressen < 256 Byte-Adressen zugeordnet.
So passt das auch zur Doku.
Somit würde es mich auch nicht wundern, wenn die Byte-Reihenfolge oder sogar Word-Reihenfolge für die Float-Werte abweicht.
Das ist dann ein Fall für die Attribute obj-hXX-bswapRegs und/oder obj-hXX-revRegs.
Definier das Attribut doch mal für alle in Frage kommenden T1-Objekte (z.B. h264 und h270)...

Gruss
   Stefan

[StefanStrobel]

Ergänzung:
Du könntest es auch global setzen:
dev-([cdih]-)*defRevRegs
dev-([cdih]-)*defBswapRegs
dann gilt es für alle Objekte und auch beim Scannen werden die Bytes / Register erst mal vertauscht.

konkret wäre das zum Beispiel

Code Auswählen Erweitern

attr WMZ dev-h-defBswapRegs 1

Gruss
   Stefan

[der-Lolo]

Ok, da scheint was zu sein...

scan-h264
hex=703dd441, len=4, string=p=.A, s=15728, s>=28733, S=15728, S>=28733, i=15728, i>=28733, I=15728, I>=28733, f=26.5299987792969, f>=2.34997064335256e+29
2017-01-08 19:49:54
scan-h265
hex=d441f528, len=4, string=.A.(, s=16852, s>=-11199, S=16852, S>=54337, i=16852, i>=-11199, I=16852, I>=54337, f=2.72290125017706e-14, f>=-3332166909952
2017-01-08 19:49:55
scan-h266
hex=f528b841, len=4, string=.(.A, s=10485, s>=-2776, S=10485, S>=62760, i=10485, i>=-2776, I=10485, I>=62760, f=23.019998550415, f>=-2.13877681990109e+32
2017-01-08 19:49:56
scan-h267
hex=b8410000, len=4, string=.A.., s=16824, s>=-18367, S=16824, S>=47169, i=16824, i>=-18367, I=16824, I>=47169, f=2.35754453638007e-41, f>=-4.60147857666016e-05
2017-01-08 19:49:57

von den Werten her könnte bei 264 und 266 f=.... passen.
jetzt würde ich dann mit unpack f den einzelnen Wert bekommen, oder?

[StefanStrobel]

so ist es

[der-Lolo]

leider nicht...

hex=32362e37333939393937373131313832, len=16, string=26.7399997711182, s=13874, s>=12854, S=13874, S>=12854, i=13874, i>=12854, I=13874, I>=12854, f=1.03838265204104e-05, f>=1.06043023251345e-08

mit unpack f

hex=2d322e3231373736333039303836313134652d3335, len=21, string=-2.21776309086114e-35, s=12845, s>=11570, S=12845, S>=11570, i=12845, i>=11570, I=12845, I>=11570, f=1.01395416507444e-08, f>=1.01283859771373e-11

mit unpack f>

[StefanStrobel]

Das ist noch die Scanner-Ausgabe.
Mit welchen Einstellungen kam denn vorher f=26.5299987792969?
Ist das reproduzierbar?
Wenn ja, dann kannst Du ein neues ModbusAttr Device erzeugen und dann mit obj-h264-... ein Reading erzeugen:

Code Auswählen Erweitern


define WMZ ModbusAttr 35 0
attr WMZ obj-h264-reading T1
attr WMZ obj-h264-showGet 1
attr WMZ obj-h264-unpack f
attr WMZ obj-h264-len 2
attr WMZ obj-h264-revRegs 1 (falls Du das gesetzt hattest)
attr WMZ obj-h264-bswapRegs 1 (falls Du das gesetzt hattest)


die vom Scanner selbst erzeugten Attribute (dev-h-defExpr etc.) sollten hier nicht gesetzt sein!

Gruss
    Stefan

[der-Lolo]

Das schaut gut aus...
Ich schau mal ob ich die anderen Werte auch auf die art eingebunden bekomme.
Dann noch abschneiden auf zwei kommastellen und Einheiten dran...

[tante ju]

So, ich glaube, ich habe die Ursache der Hänger gefunden. Es ist nicht das Modbus-Modul, es ist von einem Zeitfaktor abhängig. Da es ja keine Möglichkeit in FHEM oder dem Modbus-Modul gibt, das Interface auf RS485 umzustellen, mache ich das mit einem externen Programm, welches von FHEM gestartet wird. Wenn das zufällig zusammentrifft mit dem Öffnen des Modbus-Interfaces, dann hängt es.
Habe das mit einem Delay gelöst.

Jetzt habe ich ein anderes Problem. Nach dem letzten Update will er die Daten von einem Gerät nicht wirklich lesen:

Code Auswählen Erweitern

2017.01.08 20:39:57 4: ModBusLine: HandleSendQueue sends fc 1 to id 3, tid 144 for OnOff (c0), len 1, device EG_Tuerschild (RTU), pdu 0100000001, V 3.5.12 - 06.01.2017
2017.01.08 20:39:57 5: SW: 030100000001fc28
2017.01.08 20:39:57 5: ModBusLine: Profiling: Wait, before Send, now is 1483904397.62807, Wait started at 1483904397.5216, Send started at 1483904397.62553
2017.01.08 20:39:57 5: ModBusLine: Profiling: add 0.00253391265869141 to sum for Send (now is 1483904397.62807, start for Send was 1483904397.62553)
2017.01.08 20:39:57 5: ModBusLine: Profiling: Read, before Wait, now is 1483904397.63208, Read started at 1483904397.52561, Wait started at 1483904397.62807
2017.01.08 20:39:57 5: ModBusLine: Profiling: add 0.00401496887207031 to sum for Wait (now is 1483904397.63208, start for Wait was 1483904397.62807)
2017.01.08 20:39:57 5: ModBusLine: raw read: 00
2017.01.08 20:39:57 5: ModBusLine: ParseFrames got: 00
2017.01.08 20:39:57 5: ModBusLine: Profiling: Read, before Read, now is 1483904397.63757, Read started at 1483904397.63208, Read started at 1483904397.63208
2017.01.08 20:39:57 5: ModBusLine: raw read: 0301010191f0
2017.01.08 20:39:57 5: ModBusLine: ParseFrames got: 000301010191f0
2017.01.08 20:39:57 5: ModBusLine: ParseFrames returned error: recieved frame from unexpected Modbus Id 0, expecting fc 1 from 3 for device EG_Tuerschild


Wenn ich das richtig sehe, dann hat er den richtigen Frame bekommen, setzt aber irgendwie ein 0-Byte davor und dann ist der Frame eben ungültig. Das passiert nachvollziehbar und kontinuierlich mit diesem Device. Oder lese ich das log falsch?

[StefanStrobel]

Hallo tante ju,

raw read im Log bedeutet dass die Daten von DevIO gelesen wurden.
Das wird mit älteren Versionen vom Modbus-Modul genauso sein ...
Aber Du hast in sofern recht dass das Antwort-Frame bis auf das überflüssige 00 korrekt aussieht.
Schau doch zur Sicherheit mal ob das mit einer älteren Version von DevIO und/oder Modbus auch passiert.
Hat sich vielleicht etwas an der Schnittstellenkonfiguration geändert?
Für mich sieht das nicht nach einem Software-Problem aus.
Hast Du mal einen ganz einfachen RS485-Adapter ausprobiert, den man nicht konfigurieren muss / kann?
(Z.B. Ein DA70157)

Gruß
    Stefan

[tante ju]

Hallo tante ju,

raw read im Log bedeutet dass die Daten von DevIO gelesen wurden.
Das wird mit älteren Versionen vom Modbus-Modul genauso sein ...
Aber Du hast in sofern recht dass das Antwort-Frame bis auf das überflüssige 00 korrekt aussieht.
Schau doch zur Sicherheit mal ob das mit einer älteren Version von DevIO und/oder Modbus auch passiert.
Hat sich vielleicht etwas an der Schnittstellenkonfiguration geändert?
Für mich sieht das nicht nach einem Software-Problem aus.
Hast Du mal einen ganz einfachen RS485-Adapter ausprobiert, den man nicht konfigurieren muss / kann?
(Z.B. Ein DA70157)

Habe keinen anderen Adapter. Allerdings ist es komisch, sieben Devices sind auf dem Modbus. Bei 6 läuft es, bei diesem nicht. Es ist ja nicht so, daß es ein systematischer Fehler ist. Es kann also nach ein wenig umstecken wieder laufen. Ich würde mich ja nicht wundern, wenn der Frame defekt wäre. Aber dieses mit der führen 0, und nun auch über einen Reboot hinweg ist schon seltsam.

Aber auch seltsam finde ich, daß die Software führende Bytes nicht "eliminieren" kann. Immerhin können das ja Artefakte von Busumschaltungen und dergleichen sein. Wäre es nicht hilfreich bei empfangenen Frames, die fehlerhaft sind, auch mal testweise den Anfang zu verschieben? Zumindest mache ich das so in meinen Modbus-Implementierungen auf den Mikrocontrollern.

[der-Lolo]

Darf ich nochmal kurz dazwischen grätschen?
Ich habe nun das hier:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        35 30
   DEST
   INTERVAL   30
   IODev      ModbusRTU
   MODBUSID   35
   ModuleVersion 3.5.12 - 06.01.2017
   NAME       WMZ
   NOTIFYDEV  global
   NR         787
   NTFY_ORDER 50-WMZ
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   Readings:
     2017-01-08 21:28:39   Durchfluss      1152
     2017-01-08 21:26:45   Ruecklauftemperatur 23.10
     2017-01-08 21:26:50   Vorlauftemperatur 26.63
     2017-01-08 21:30:46   aktWaermeLeistung 4.700
     2017-01-08 21:30:25   gesamtDurchfluss 1508.310
     2017-01-08 21:28:49   gesamtWaermemenge 5.711
   Gotreadings:
     aktWaermeLeistung 4.700
   Helper:
     lrecv      1483907446.55535
     lsend      1483907446.5373
   Lastread:
     h256       1483907329.56603
     h258       1483907319.64838
     h260       1483907425.66531
     h262       1483907446.55789
     h264       1483907210.99511
     h266       1483907205.86859
Attributes:
   IODev      ModbusRTU
   dev-h-defBswapRegs 1
   dev-h-defPoll 1
   obj-h256-format %.3f
   obj-h256-len 2
   obj-h256-reading gesamtWaermemenge
   obj-h256-showGet 1
   obj-h256-unpack f
   obj-h258-format %.3f
   obj-h258-len 2
   obj-h258-poll 1
   obj-h258-reading Durchfluss
   obj-h258-showGet 1
   obj-h258-unpack f
   obj-h260-format %.3f
   obj-h260-len 2
   obj-h260-reading gesamtDurchfluss
   obj-h260-showGet 1
   obj-h260-unpack f
   obj-h262-format %.3f
   obj-h262-len 2
   obj-h262-reading aktWaermeLeistung
   obj-h262-showGet 1
   obj-h262-unpack f
   obj-h264-format %.2f
   obj-h264-len 2
   obj-h264-reading Vorlauftemperatur
   obj-h264-showGet 1
   obj-h264-unpack f
   obj-h266-format %.2f
   obj-h266-len 2
   obj-h266-reading Ruecklauftemperatur
   obj-h266-showGet 1
   obj-h266-unpack f
   room       System
   userattr   IODev dev-h-defBswapRegs dev-h-defPoll obj-h256-format obj-h256-len obj-h256-poll obj-h256-reading obj-h256-showGet obj-h256-unpack obj-h258-format obj-h258-len obj-h258-poll obj-h258-reading obj-h258-showGet obj-h258-unpack obj-h260-format obj-h260-len obj-h260-reading obj-h260-showGet obj-h260-unpack obj-h262-format obj-h262-len obj-h262-reading obj-h262-showGet obj-h262-unpack obj-h264-format obj-h264-len obj-h264-reading obj-h264-showGet obj-h264-unpack obj-h266-format obj-h266-len obj-h266-reading obj-h266-showGet obj-h266-unpack

Frage mich aber jetzt wie ich es hinbekomme das nun die 4 relevanten Informationen zyklisch also alle 30 sec abgefragt werden.
("Ich antworte mir mal selbst -- ein shutdown restart hilft!")

Einheiten, also °C und kW oder MWh und l/h kann ich nicht vergeben?

[StefanStrobel]

Aber auch seltsam finde ich, daß die Software führende Bytes nicht "eliminieren" kann. Immerhin können das ja Artefakte von Busumschaltungen und dergleichen sein. Wäre es nicht hilfreich bei empfangenen Frames, die fehlerhaft sind, auch mal testweise den Anfang zu verschieben? Zumindest mache ich das so in meinen Modbus-Implementierungen auf den Mikrocontrollern.

Das hat bisher niemand benötigt.
Einbauen kann ich das schon.
Ich pack es mal auf die Wunschliste für die nächste Version.

Gruß
    Stefan

[StefanStrobel]

Hallo der-Lolo,

das mit den Einheiten ist ja ein Thema, das im Forum seit Jahren immer wieder mal diskutiert wird.
Da es keine klare Empfehlung für Einheiten gibt und sie in Readings durchaus auch Nachteile haben,
habe ich bisher weder im Modbus-Modul noch in HTTPMOD spezielle Features für Einheiten eingebaut.
Manche Anwender verwenden aber Format-Attribute wie "%.3f kWh" oder die -Expr Attribute um Einheiten an die Readings anzuhängen.
Ich bin kein Fan davon

Gruss
    Stefan

[der-Lolo]

Hallo Stefan, danke Dir!
Das Logging läuft nun sehr stabil und fehlerfrei. Die Einheiten werde ich wie von Dir beschrieben, oder aber mithilfe einer readingsGroup hinzufügen. Tausend Dank für die Hilfe und die tolle Arbeit hier...

[StefanStrobel]

Hallo tante ju,

Hat sich eigentlich jemand mal daran gemacht, für das serielle Interface mittels termios RS485 für die Interfaces einzuschalten? Zur Zeit muß ich aus FHEM noch ein extra Programm aufrufen, da meine seriellen Interfaces erst auf RS485-Modus umgeschaltet werden müssen, um die Leitungstreiber zu aktivieren.

Ich hab mir das nochmal angesehen.
Das Modbus-Modul verwendet für die Kommunikation ja Fhem DevIO. Auch das Setzen der Baudrate, Parity etc. geht vom Modbus-Modul an Devio, und dort wird Device::SerialPort verwendet um die Schnittstellen-Parameter zu setzen. Wenn wir einen Weg finden, wie man Device::SerialPort dazu bringt, ein Interface in den RS485-Modus zu bringen, ist der Rest schnell gemacht. Device::SerialPort verwendet wohl termios recht ausführlich ...

Gruss
    Stefan