Neue Versionen und Support zum Modbus-Modul

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

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo Norbert,

stell einfach mal das Gerät auf Verbose 5 (und falls es über ein serielles Modbus-Gerät aus IODev geht auch dieses) und poste das Log für einen zeitraum, in dem das Problem auftritt. Darin sollten dann jede Menge Debug-Meldungen stehen, aus denen man entnehmen kann, wann / warum / warum nicht Reading abgefragt wird.
Zudem wäre Deine genaue Konfiguration wichtig.

Gruss
   Stefan

cocojambo

#601
Hallo Stefan,

ich habe die LOG Daten und .CFG Daten alle als Word Dokument gespeichert. Um sie hier direkt als Text einzustellen sind sie viel zu lang.
Ich hoffe sie sind lesbar für dich.

Gruß aus Köln
Norbert
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

StefanStrobel

Hallo Norbert,

probier doch mal SE_Inverter dev-h-combine zu reduzieren.
200 erscheint mir ein gewagt hoher Wert ...

Gruss
   Stefan

cocojambo

Hallo Stefan,

Danke, ich werde verrückt, jetzt werden die Werte angezeigt, dafür bin ich seit gestern Abend im Einsatz und habe alles ausprobiert.....Nur combine nicht.
Ich hatte mich dabei auf FHEMWiki verlassen, wo der Wert von 200 vorgegeben ist.

https://wiki.fhem.de/wiki/SolarEdge_SE10k

Ich habe jetzt mal 50 eingesetzt, ist das OK?

attr SE_Inverter dev-h-combine 50

Frage am Rande, wonach richtet sich der Wert? (damit ich es fürs nächste Mal weiß)

Also ich freue mich, das du mir so toll weitergeholfen hast, Prima.

Ich hoffe das ich jetzt auch alle anderen Abfragen hin bekomme und der Wert dafür richtig ist.

Mit freundlichem Gruß aus "Kölle am Rhing"
Norbert

FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

StefanStrobel

Hallo Norbert,

Der combine-Wert gibt an, wie viele aufeinanderfolgende Register mit einem Request gleichzeitig abgefragt werden dürfen. Das ist je Gerät unterschiedlich. Manche erlauben 16, manche nur 4, manche viel mehr. Das Modbus-Protokoll sieht aber bei function code 3 schon eine Obergrenze von 125 vor. 200 geht also definitiv zu weit ;-)

Gruß
    Stefan

ch.eick

Hallo zusammen,
als Meister der Unwissenheit habe ich dazu auch eine Frage.
Mein Device, ein WR hat ca 120 readings, habe ich da eventuell einen Vorteil "dev-h-combine 8" zu setzen?
Bei "dev-h-combine 16 oder 32" sind einige readings (die längeren Register) mit falschen oder zuviel Zeichen.

Wie bekomme ich den besten/korrekten Wert?

Gruß
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Wzut

WOW 120 Readings und die brauchst du unbedingt alle immer und überall ?
Ich hatte bei meinen SMAs am Anfang auch so ein Sack voll (Jäger & Sammler) bis mir klar wurde das ich in Wahrheit fürs Tagesgeschäft 6 Stück brauche :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ch.eick

Zitat von: Wzut am 08 Dezember 2020, 14:40:50
WOW 120 Readings und die brauchst du unbedingt alle immer und überall ?
Ich hatte bei meinen SMAs am Anfang auch so ein Sack voll (Jäger & Sammler) bis mir klar wurde das ich in Wahrheit fürs Tagesgeschäft 6 Stück brauche :)
Ich schreibe sie ja nicht in die DbLog, da würde die ja dicke Backen bekommen :-)
Allerdings sehe ich gerne was da wäre, aber ich habe auch schon nachgedacht ein Device mit kompletter Definition anzulegen und ein mit minimum.
Es wäre jetzt auch an der Zeit mal einen Modul zu exportieren.
Gruß
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

StefanStrobel

Hallo Christian,

wenn combine zu falschen Readings führt, dann ist irgend etwas bei den Definitionen der Readings faul.
Das sollte nicht passieren.
Die Idee von combine ist dass man die Anzahl der nötigen Requests reduziert, indem aufeinanderfolgende Requests kombiniert werden.

Wenn es zum Beispiel Readings für holding register 100 mit Länge 1, 101 mit Länge 1 und eines für 102 mit Länge 4 gibt, dann würden ohne combine bei einem Update-Zyklus drei einzelne Requests versendet und die Ergebnisse einzeln verarbeitet.
Bei z.B. combine 8 würde nur ein Request mit Adresse 100 und Länge 6 erzeugt. Die Antwort wird dann in die drei Teile zerlegt und die Readings werden wie vorher erzeugt. Das sollte etwas performanter sein.

Wenn allerdings die Readings nicht dicht beieinander liegen, dann erzeugt combine auch Overhead, da dann viele Register gelesen werden, die keiner benötigt.

Bei verbose 5 sieht man das gut im Log.

Gruss
   Stefan

gerry1

#609
hallo
Hilfe hab da ein Problem,
ist: windows 10 >DWH300D+ komuniziert über qmod master (usb-rs485 Adapter an com3) :D
soll: fhem soll steuerung übernehmen.
hab gedacht mit Internals:
   DEF        com3@19200,8,E,1

   DeviceName com3@19200,8,E,1

   EXPECT     response
   FUUID      5fce35c1-f33f-17b0-9802-4c6419afdd207e00
   LASTOPEN   1607456975.87163
   MODE       master
   NAME       ModbusRS485
   NR         24
   NTFY_ORDER 50-ModbusRS485
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 10
   nextQueueRun 1607456990.94476
   nextTimeout 1607456992.94248
   FRAME:
   QUEUE:
     HASH(0x6480cd8)
     HASH(0x647caa0)
     HASH(0x647abb8)
     HASH(0x6472ef8)
     HASH(0x64872a8)
     HASH(0x647c740)
     HASH(0x64825c0)
     HASH(0x647ce60)
     HASH(0x64808e8)
     HASH(0x6482c68)
     HASH(0x647ac18)
     HASH(0x647d250)
     HASH(0x6480e40)
     HASH(0x6481020)
     HASH(0x6482c50)
     HASH(0x6492a50)
     HASH(0x6481038)
     HASH(0x6489de0)
     HASH(0x6472aa8)
     HASH(0x6483af8)
     HASH(0x6480c60)
     HASH(0x646a530)
     HASH(0x6475298)
     HASH(0x64823e0)
     HASH(0x64723d0)
     HASH(0x6483300)
     HASH(0x647c440)
     HASH(0x648b1e0)
     HASH(0x648fdf8)
     HASH(0x6474678)
     HASH(0x6483e28)
     HASH(0x6490110)
     HASH(0x647ccb0)
     HASH(0x647cbf0)
     HASH(0x647e050)
     HASH(0x6470470)
     HASH(0x64836d8)
     HASH(0x6480720)
     HASH(0x648a460)
     HASH(0x6483738)
     HASH(0x6482710)
     HASH(0x647eb98)
     HASH(0x647edd8)
     HASH(0x647be20)
     HASH(0x647c078)
   READ:
     BUFFER     
   READINGS:
     2020-12-08 20:49:35   state           opened
   REMEMBER:
     lid        2
     lname      ModbusRS485
     lsend      1607456989.94463
   REQUEST:
     ADR        16
     DBGINFO    getUpdate
     FCODE      3
     FRAME      ��
     LEN        1
     MODBUSID   2
     OPERATION  read
     QUEUED     1607456970.93735
     READING    WW_Hysterese_K
     SENT       1607456989.94248
     TYPE       h
     VALUES     0
     MASTERHASH:
       DEF        2 10

       FUUID      5fcd563d-f33f-17b0-3d9c-94d1ebad1e272aba
       INTERVAL   10
       IODev      ModbusRS485
       MODBUSID   2
       MODE       master
       MODULEVERSION Modbus 4.1.9 - 30.5.2020
       NAME       DHW300D
       NOTIFYDEV  global
       NR         23
       NTFY_ORDER 50-DHW300D
       PROTOCOL   RTU
       STATE      opened
       TRIGGERTIME 1607456990.93287
       TRIGGERTIME_FMT 2020-12-08 20:49:50
       TYPE       ModbusDHW300
       lastUpdate 1607456980.93287
       FRAME:
       READ:
       READINGS:
         2020-12-08 20:01:00   state           opened
       REMEMBER:
         lsend      1607456989.94463
       lastRead:
   defptr:
     DHW300D    2
Attributes:
   nextOpenDelay 10
   room       Heizraum
und Internals:
   DEF        2 10

   FUUID      5fcd563d-f33f-17b0-3d9c-94d1ebad1e272aba
   INTERVAL   10
   IODev      ModbusRS485
   MODBUSID   2
   MODE       master
   MODULEVERSION Modbus 4.1.9 - 30.5.2020
   NAME       DHW300D
   NOTIFYDEV  global
   NR         23
   NTFY_ORDER 50-DHW300D
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1607455170.67169
   TRIGGERTIME_FMT 2020-12-08 20:19:30
   TYPE       ModbusDHW300
   lastUpdate 1607455160.67169
   FRAME:
   READ:
   READINGS:
     2020-12-08 20:01:00   state           opened
   REMEMBER:
     lsend      1607454449.23192
   lastRead:
Attributes:
   event-on-change-reading .*
   room       Heizraum
   verbose    5

sollte dies funktionieren
leider kriege ich bei abfragen immer nur timeouts
die com schnittstelle is solange com3 im modbusrs485 er modul programiert  ist für andere zugriffe blockiert
die wp hat modbus id 2
mach ich was falsch oder hab ich nen gedankenfehler?


Juhu habs zum laufen gebracht :)
Fehler lag am perl win32::serialport.
musste es erst wie hier beschriebenhttps://rt.cpan.org/Public/Bug/Display.html?id=113337#txn-1691722 für 64 bit Windows fit machen.

danke an alle die dieses Forum am leben halten, ohne eure Beiträge wär ich nie drauf gekommen

liebe grüsse an euch
gerry1

StefanStrobel

Hallo,

hier mal wieder eine neue Version zum Testen. Ich hoffe, dass ich die bald einchecken kann.
Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD und wird erst beim Neustart von Fhem geladen.
Die aktuelle Utils.pm habe ich aber auch gerade schon zusammen mit HTTPMOD eingecheckt.

Gruss
   Stefan

holle75

Hallo Ihr, ich muß kurz mal eine unqualifizierte Frage stellen.

Ich nutze das Modbus-Modul mit Hilfe von Rogers "Zusatzmodul" (wie nennt man diese "aufgesetzten" Module?) um zwei sdm220 Stromzähler auszulesen.

Das habe ich vor langer Zeit mit Unterstützung hier aus dem Forum hinbekommen, aber relativ wenig verstanden, was ich da tue.

Jetzt, resp. seit Jahren, möchte ich meine Solaranlage an den selben Bus hängen. Beworben wird das Kästchen, was die Kommunikation zum internen Can-Bus der Anlage herstellt, folgendermaßen:

"The Xcom-485i module offers the possibility to interact with a Studer Xtender/Vario system with a
third-party device  (SCADA system, PLC, etc.)  using Modbus RTU on RS-485"

Bevor ich mir das Kästchen kaufe und mich wahrscheinlich monatelang damit auseinandersetzen muß .......

Kann ich das an den selben Bus/Kabel und USB Dongle wie die beiden Stromzähler hängen?

Ich verstehe noch nicht, wie all diese verschiedenen Protokolle und Unterprotokolle zusammenspielen. Hardwareseitig wie auch programmseitig.

Ich liefere gerne noch zusätzliches Infomaterial vom Hersteller, aber will den Thread nicht zumüllen.

Wenn einer mich erleuchten könnte?

lieb Gruß
H.

StefanStrobel

Hallo holle75,

theoretisch sollten mehrere Slaves an einem gemeinsamen RS485-Bus funktionieren. Ob es in der Praxis nicht doch ein Problem gibt, kann ich nicht sagen. In jedem Fall brauchst Du aber die Liste der Register etc. vom Hersteller, es sei denn im Forum hat schon jemand eine solche Anlage an Fhem angeschlossen.

Gruss
   Stefan

holle75

Danke Stefan, die ganzen HEX Werte, Register gibt es übersichtlich vom Hersteller.

Mein Verständnis-/Grundlagenproblem ist eher, welches Gerät jetzt wie "spricht",....  Modbus RTU, RTU over TCP, Modbus Ascii, etc .... , habe ich einen 232 Bus oder einen 485 Bus, ob jetzt der USB-Dongle und Bus der für die Stromzähler passend ist, das auch für die Solaranlage wäre, etc. Will nicht noch einen Bus aufmachen.

Da fängts an .... jetzt habe ich mich noch ins Wiki, commandref und Modbus Allgemein ein bißchen eingelesen und da bekommt man schon ein wenig Angst. Besonders wegen der "gefühlten Vielfältigkeit der ähnlichen Unterschiede"....

wenn ich denn die passende Hardware, Verkabelung/Bus/Dongle und Protokoll gefunden habe, wurschtel ich mich dann schon durch.

Gruß!
H.

technikki79

Ich hatte gerade ein ähnliches Problem und ihr konntet mir sehr helfen mit euren antworten. danke
Man sollte nur produzieren und bauen dürfen, was brauchbar ist.