FHEM Forum

FHEM => Sonstiges => Thema gestartet von: StefanStrobel am 20 August 2017, 12:11:08

Titel: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 August 2017, 12:11:08
Hallo,

da der alte Thread ziemlich groß geworden ist und auch Titel des alten Threads (https://forum.fhem.de/index.php/topic,25315.0.html) nicht mehr so gut passt, mache ich einen neuen auf und schließe den alten.
Das Modul unterstützt ja schon lange Modbus RTU oder ASCII über RS232, RS485 oder auch als Modbus-TCP oder Modbus-RTU über TCP.

Hier werde ich in Zukunft neue Versionen zum Testen posten und Fragen beantworten.
Bitte keine Fragen zum Modul als PM. Es ist sinnvoller,  diese hier zu stellen, damit auch andere von der Diskussion profitieren können.

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 August 2017, 12:25:01
und hier auch gleich eine neue Version zum Testen.

Neu ist z.B. die Unterstützung von benutzerdefinierten Datentypen. Bei einigen Geräten werden z.B. viele Werte als Fließkommazahl in 2 Registern mit umgekehrter Reihenfolge im big endian Format gespeichert.

um nicht für jedes Objekt 5 Attribute mit Länge, Unpack-Code, revRegs etc. angeben zu müssen, kann man nun einmal den Datentyp mit dev-type- definieren und dann künftig bei jedem Objekt nur noch den Typ zuweisen.

Beispiel:
attr WP dev-type-VT_R4-format %.1f
attr WP dev-type-VT_R4-len 2
attr WP dev-type-VT_R4-revRegs 1
attr WP dev-type-VT_R4-unpack f>

attr WP obj-h1234-reading Temp_Ist
attr WP obj-h1234-type VT_R4
Die ersten vier Attribute erzeugen einen Datentyp mit Namen VT_R4 und legen für diese Typ format, len, revRegs und unpack fest.
Danach wird für das Holding-Register mit der Adresse 1234 ein Reading mit Namen Temp_Ist und der Typ VT_R4 zugewiesen.


Ebenso neu ist ein experimentelles Feature zum automatischen Erzeugen eines individuellen Gerätemoduls aus den Attributen eines Modbus-Attr Geräts.

Mit set WP saveAsModule WP werden die per Attribut definierten Objekte (alles was mit dev- und obj- definiert ist) mit etwas Code drum herum in ein Perl-File geschrieben. Das File würde im obigen Beispiel als /tmp/98_ModbusGenWP.pm gespeichert.
Von dort kann man es ins Modulverzeichnis von Fhem (z.B. /opt/fhem/FHEM) verschieben, Fhem neu starten und dann statt Modbus-Attr mit vielen Attributen ein Gerät mit dem neuen Typ ModbusGenWP definieren.

Wer die Register-Definitionen für seine Heizung oder seinen speziellen Solar-Speicher einfach als Modul weitergeben möchte, kann das mal ausprobieren.

Gruss
   Stefan
Titel: Zugriff auf SMA Batterie-Wechselrichter Si6.0H
Beitrag von: Goulasch am 17 September 2017, 19:00:52
Meine Konfig:
define PWP ModbusAttr 3 30 192.168.1.38:502 TCP
attr PWP userattr obj-h30051-reading obj-h30051-unpack obj-h30051-poll
attr PWP obj-h30051-reading WRtyp
attr PWP obj-h30051-unpack N
attr PWP obj-h30051-poll 1
attr PWP verbose 5
Die Slave Adresse lautet "3".

Das Log:
Zitat
2017.09.17 18:45:54 5: PWP: GetUpdate called
2017.09.17 18:45:54 4: PWP: update timer modified: will call GetUpdate in 30.0 seconds at 2017-09-17 18:46:24 - Interval 30
2017.09.17 18:45:54 5: PWP: GetUpdate objects from attributes: h30051
2017.09.17 18:45:54 5: PWP: GetUpdate full object list: h30051
2017.09.17 18:45:54 5: PWP: GetUpdate check h30051 => WRtyp, poll = 1, last = 0
2017.09.17 18:45:54 4: PWP: GetUpdate will request WRtyp
2017.09.17 18:45:54 5: PWP: GetUpdate tries to combine read commands
2017.09.17 18:45:54 5: PWP: don't sort objList before sending requests
2017.09.17 18:45:54 4: PWP: Send called with h30051, objLen 1 / reqLen 1 to id 3, op read, qlen 0
2017.09.17 18:45:54 4: PWP: Send queues fc 3 to 3, tid 146, for h30051 (WRtyp), reqLen 1
2017.09.17 18:45:54 5: PWP: handle queue check commDelay (0.1) for PWP: rest -29.9109320640564
2017.09.17 18:45:54 5: PWP: handle queue check sendDelay (0.1) for PWP: rest -29.9211559295654
2017.09.17 18:45:54 5: PWP: HandleSendQueue: finished delay checking, proceed with sending
2017.09.17 18:45:54 4: PWP: HandleSendQueue sends fc 3 to id 3, tid 146 for WRtyp (h30051), len 1, device PWP (TCP), pdu 0375630001, V 3.7.0 - 20.8.2017
2017.09.17 18:45:54 5: SW: 009200000006030375630001
2017.09.17 18:45:54 5: PWP: raw read: 0092000000030383
2017.09.17 18:45:54 5: PWP: ParseFrames got: 0092000000030383
2017.09.17 18:45:54 5: PWP: ParseFrames: Modbus TCP PDU too small (expect 3): 2
2017.09.17 18:45:54 5: PWP: raw read: 02
2017.09.17 18:45:54 5: PWP: ParseFrames got: 009200000003038302
2017.09.17 18:45:54 4: PWP: ParseFrames got error code 83 / 02, illegal data address
2017.09.17 18:45:54 5: PWP: ParseFrames returned error: device replied with exception code 83 / 02, illegal data address

Gemäß SMA definiert sich das auszulesende Register:
Modbus register address   Short description   Type   Format   Unit   Access
30051                           Device class           U32   ENUM      RO

Kann mit diversen Modbus-Server-Client Utillities auf den WR zugreifen.
Verstehe nicht, warum hier jetzt ein "exception" kommt.

Im alten Thread hat der User @Fantomas offensichtlich mit Erfolg auf das Interface zugreifen können.
Titel: Antw:Zugriff auf SMA Batterie-Wechselrichter Si6.0H
Beitrag von: Goulasch am 17 September 2017, 19:48:29
Antwort kann ich selbst geben :
attr PWP obj-h30051-len 2fehlte in der Konfig.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 23 September 2017, 20:51:49
Hi Stefan,
ich Roger bin's nach langer Zeit mal wieder mit einer Frage.

Beim Fronius Wechselrichter werden einige Werte aus zwei Registern gebildet: Wert*10**ScaleFactor.
Nun muss sichergestellt werden, das vor dem Auslesen und der Berechnung von Wert der ScaleFactor ausgelesen wurde.
Wie kann mal das sicherstellen?
Im Log sehe ich, das die Werte in unterschiedlicher Reihenfolge reinkommen --> und machmal ergibt die Berechnung falsche werte, da ScaleFactor zu spät kommt.
Fällt Dir dazu was ein?

Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 September 2017, 11:03:25
Hallo Roger,

ist der ScaleFactor auf einer kleineren Adresse?
Ich habe aus einem ähnlichen Grund vor kurzem ein Attribut "sortUpdate" eingebaut. Dann werden die Requests beim zyklischen Update nach Adresse sortiert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 24 September 2017, 14:45:14
Hi Stefan,
man das ist ja Klasse. Ja, die ScaleFactoren sind auf kleineren Adressen. Ich probiere man das Attribut sortUpdate.
Ist wohl noch nicht in der CommandRef, denn da hatte ich schon nach so etwas gesucht.

Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 September 2017, 14:59:49
Hi Roger,

sollte seit Juli in der CommandRef zu ModbusAttr drinstehen.
Aber in der Doku vom Basismodul stehen die ganzen Attribute nicht nochmal drin. ;-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 24 September 2017, 16:02:19
Oh in ModbusAttr hatte ich nicht geschaut, da ich ja mit dem Modul nichts mache.
Vielleicht kannst Du ja ergänzen, das es nach der Adresse sortiert wird. Ich weiß nicht, ob ich beim Durchlesen die Lösung des Problems durch dieses Attribut erkannt hätte.

Und das Wichtigste: Fehler ist weg  :)

mit dankendem Gruß
Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 26 September 2017, 19:37:38
Hi Stefan,
nächste Frage. Ich habe einige Readings umbenennen müssen. Wie kann ich die alten Readings von einem Modul, welches auf 98_Modbus.pm aufsetzt, löschen (also deletereading aufrufen)?
Ich suche nach so was wie X_Define in einem normalen Modul.

(Ich habe mir derzeit mit einer ignoreExpr-Funktion von einem Wert mit poll => "once" beholfen, aber das geht bestimmt sauberer).

Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 September 2017, 20:46:02
Hallo Roger,

jetzt hast Du mich abgehängt.
deletereading funktioniert doch immer - aber was hat das mit X_Define zu tun?
Sorry - ich steh auf dem Schlauch ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 26 September 2017, 22:10:54
Hi Stefan,
ich möchte innerhalb meines Modules, welches auf 98_Modbus.pm aufsetzt, beim Start des Modules einmalig eine Aktion durchführen konkret:
fhem("deletereading <devname> <readingname>")Dafür habe ich bisher nur die Krücke, wie im vorherigen Post beschrieben, gefunden.
In vollständigen FHEM-Modulen, kann man so etwas wohl in der X_Define Sub durchführen.

Ich hoffe das ich mich verständlicher machen konnte  ;D.
Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 September 2017, 20:07:15
Hallo Roger,

Dein Modul definiert vermutlich eine Funktion mit Namen ModbusXYZ_Initialize, die ihrerseits ModbusLD_Initialize aufruft.
Dort wird die Define-Funktion festgelegt:

$modHash->{DefFn}     = "ModbusLD_Define";
Du könntest jetzt in Deiner ModbusXYZ_Initialize direkt nach dem Aufruf von ModbusLD_Initialize einfach die Variable $modHash->{DefFn} überschreiben,
eine eigene Define-Funktion schreiben, die dann ModbusLD_Define aufruft und die Parameter durchreicht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 28 September 2017, 21:44:30
Hi Stefan,
Danke für den Schubs in die richtige Richtung. Da ich aber gespeicherte Readings beim Serverstart/RereadCFG löschen wollte (die hatte ich umbenennen müssen und wollte die Leichen entfernen), musste ich {NotifyFn} wie von Dir beschrieben umbiegen.

Also vielen Dank für die kompetente Hilfe - in den Mechanismen der FHEM-Module bin ich (noch) nicht so fit.

Allerdings war meine Notlösung mit einer ignoreExpr-Funktion von einem Wert mit poll => "once" bedeutend einfacher.
Vielleicht kannst Du ja noch solche Funktionsaufrufe in 98_Modbus.pm einbauen?
Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 30 September 2017, 12:13:07
Hallo Stefan,
ich habe wieder schwierigkeiten meine Modbus Linie in betrieb zu nehmen. Als erstes fällt mir im Log folgendes auf

Zitat
2017.09.30 12:09:48 0: Server started with 57 defined entities (fhem.pl:15112/2017-09-21 perl:5.024002 os:linux user:fhem pid:12069)
2017.09.30 12:09:48 0: Featurelevel: 5.8
2017.09.30 12:09:48 1: Including ./log/fhem.save
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_Send redefined at ./FHEM/98_Modbus.pm line 2674, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_SwpRegs redefined at ./FHEM/98_Modbus.pm line 2653, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_RevRegs redefined at ./FHEM/98_Modbus.pm line 2630, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_GetIOHash redefined at ./FHEM/98_Modbus.pm line 2602, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_GetUpdate redefined at ./FHEM/98_Modbus.pm line 2478, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_compObjKeys redefined at ./FHEM/98_Modbus.pm line 2459, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_ReadAnswer redefined at ./FHEM/98_Modbus.pm line 2349, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_Set redefined at ./FHEM/98_Modbus.pm line 2212, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_ScanFormat redefined at ./FHEM/98_Modbus.pm line 2167, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_ScanIds redefined at ./FHEM/98_Modbus.pm line 2124, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_ScanObjects redefined at ./FHEM/98_Modbus.pm line 2082, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_ControlSet redefined at ./FHEM/98_Modbus.pm line 1888, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_compObjAttrs redefined at ./FHEM/98_Modbus.pm line 1869, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_Get redefined at ./FHEM/98_Modbus.pm line 1824, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_UpdateGetSetList redefined at ./FHEM/98_Modbus.pm line 1762, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_Undef redefined at ./FHEM/98_Modbus.pm line 1748, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_Attr redefined at ./FHEM/98_Modbus.pm line 1652, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Attr redefined at ./FHEM/98_Modbus.pm line 1626, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_Define redefined at ./FHEM/98_Modbus.pm line 1565, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_OpenCB redefined at ./FHEM/98_Modbus.pm line 1551, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_SetTimer redefined at ./FHEM/98_Modbus.pm line 1519, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_SetIODev redefined at ./FHEM/98_Modbus.pm line 1476, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_Initialize redefined at ./FHEM/98_Modbus.pm line 1392, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_HandleSendQueue redefined at ./FHEM/98_Modbus.pm line 1210, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_CheckDelay redefined at ./FHEM/98_Modbus.pm line 1178, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_TimeoutSend redefined at ./FHEM/98_Modbus.pm line 1156, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_CountTimeouts redefined at ./FHEM/98_Modbus.pm line 1131, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_LRC redefined at ./FHEM/98_Modbus.pm line 1116, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_CRC redefined at ./FHEM/98_Modbus.pm line 1096, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Ready redefined at ./FHEM/98_Modbus.pm line 1071, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Open redefined at ./FHEM/98_Modbus.pm line 1027, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Read redefined at ./FHEM/98_Modbus.pm line 994, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_EndBUSY redefined at ./FHEM/98_Modbus.pm line 976, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_ParseFrames redefined at ./FHEM/98_Modbus.pm line 784, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Profiler redefined at ./FHEM/98_Modbus.pm line 700, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Statistics redefined at ./FHEM/98_Modbus.pm line 668, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_ParseObj redefined at ./FHEM/98_Modbus.pm line 529, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_CheckEval redefined at ./FHEM/98_Modbus.pm line 502, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_ObjKey redefined at ./FHEM/98_Modbus.pm line 484, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_DevInfo redefined at ./FHEM/98_Modbus.pm line 454, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine ModbusLD_ObjInfo redefined at ./FHEM/98_Modbus.pm line 373, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Notify redefined at ./FHEM/98_Modbus.pm line 335, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Undef redefined at ./FHEM/98_Modbus.pm line 293, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Define redefined at ./FHEM/98_Modbus.pm line 265, <$fh> line 400.
2017.09.30 12:09:48 1: PERL WARNING: Subroutine Modbus_Initialize redefined at ./FHEM/98_Modbus.pm line 234, <$fh> line 400.
2017.09.30 12:09:47 1: Including /usr/local/fhem/opt/fhem.cfg
2017.09.30 12:09:45 0: Server shutdown

Ich habe das Modul aus diesem Thread geladen und neu gestartet - es bringt aber keinen unterschied.
FHEM läuft auf einer Synology DiskStation - falls das eine Rolle spielt..
Hast Du eine Idee was da los ist?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 September 2017, 13:58:22
Hallo der-Lolo,

das sieht nach einem reload des Moduls aus.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 30 September 2017, 14:10:37
Das sollte also bzgl. der funktion des Moduls keine rolle spielen?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Oktober 2017, 21:09:46
ich würde mich schon fragen, wo das herkommt, aber die Funktion sollte es nicht stören.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 02 Oktober 2017, 22:10:25
Ich hab gestern testweise auf einem Raspi3B mit stretch aufgesetzt, das funktioniert tadellos - angeschlossen an der Synology DiskStation funktioniert es aber nicht. Sehr eigenartig...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Marie am 26 Oktober 2017, 09:20:31
Moin Stefan,


ich habe da mal eine Frage bzgl. des SET Befehls ScanModbusIds..lt commander gibt es den, bei Eingabe bekomme ich die Meldung "Befehl nicht verfügbar"... oder so. FHEM ist aktuell...


Hast Du eine Idee?


LG


Marie
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 26 Oktober 2017, 09:28:18
Ich glaube Du musst noch ein enabelControlSet Attribut beim Device, also nicht am Controller setzen...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Marie am 26 Oktober 2017, 09:36:13
Moin,


ja das habe ich ja gemacht, aber interessanterweise gibt es in der Set-Liste diesen Befehl nicht obwohl er in der CommandRef beschrieben wird....
 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 26 Oktober 2017, 09:38:12
und wenn du ihn von Hand eingibst?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Marie am 26 Oktober 2017, 10:00:34
und wenn du ihn von Hand eingibst?


... kommt die Meldung "geht nicht"...


aber ich sehe gerade das steht nur Scan nach RS485-Teilnehmer... ich habe Modus over TCP...demnach dürfte das nicht gehen denke ich mal..schade..


LG


Marie
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Oktober 2017, 10:38:29
Dafür könnetst Du mit NMAP o.ä. nach IP-Adressen mit offenem TCP-Port 502 suchen.

Das Modbus-Modul kann dann für ein gegebenes Gerät die Register scannen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Marie am 26 Oktober 2017, 10:52:44
Hallo Stefan,


das Problem war folgendes : kommuniziere mit einem Victron gateway (Solaranlage Wohnmobil) per Modus TCP. Leider ist die Doku von Victron für das Gateway nicht aktuell und so war mir nicht klar, wo welches Devices (ID) arbeitet. Aber ich habe mich mittlerweile auf die Console des Gateways gehackt und dort die Zuordnung gefunden..arbeite mich voran, so das ich gerade aktuell diesen Scan nicht mehr brauche... aber trotzdem danke Euch!


LG


Marie
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 30 Oktober 2017, 22:26:22
Hallo,

kann mir wer einen guten USB Modbus Adapter empfehlen?

Habe momentan so einen China RS485 Adapter im Einsatz, welcher zwar gut funktionoert, aber nach ein paar Wochen bekomme ich folgende dmesg Meldung und das Modbus Modul hört auf Readings upzudaten.

[122157.169334] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Nach einem FHEM Neustart geht wieder alles, wo sich das Modul da genau aufhängt weiß ich nicht, hab zwar schon oft probiert das ganze mit verbose 5 zu loggen, aber dann lief lustigerweise alles.

Eventuell kann man dort wo das Modul hängen bleibt ja noch ein Reload einbauen.

Aber mein eigentliches Problem ist wohl der Adapter, dachte erst es ist ein Stromproblem, aber nachdem dann auch der extern versorgte USB Hub nicht half, tippe ich mal darauf das es an dem Adapter selbst liegt.

Danke,
Crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pontiac am 06 Dezember 2017, 12:26:56
Hallo, mein erstes Post hier und gleich eine Frage.

Ich krieg meinen SolarLogPro Zähler nicht dazu über Modbus mit FHEM zu reden. Seit Tagen hab ich alles was hier und im alten Thread  steht ausprobiert, komme aber zu keinem vernünftigen Ergebniss.

Mit folgender Konfig bokomme ich ein paar Daten, immer mal wieder angezeigt, kann sie aber noch nicht mal zuordnen.
Kappiere einfach nicht die Registerabfrage.

define ModbusRS485 Modbus /dev/serial/by-id/usb-CTI_GmbH_Serial_Converter_CT1EI9EF-if00-port0@9600
attr ModbusRS485 devStateIcon disconnected:usb@red open:usb@green opened:usb@green

define Power ModbusAttr 1 20
attr Power userattr IODev dev-h-combine dev-h-defPoll dev-i-defFormat obj-h100-reading obj-h101-reading obj-h102-reading obj-h106-reading obj-h107-reading obj-h108-reading obj-h109-reading obj-h110-reading obj-h111-reading obj-h200-expr obj-h200-len obj-h200-reading obj-h201-expr obj-h201-len obj-h201-reading obj-h202-expr obj-h202-len obj-h202-reading obj-h206-expr obj-h206-reading obj-h207-expr obj-h207-reading obj-h208-expr obj-h208-reading obj-h209-expr obj-h209-reading obj-h21-expr obj-h210-expr obj-h210-reading obj-h211-expr obj-h211-reading obj-h279-expr obj-h279-reading obj-h280-expr obj-h280-reading obj-h281-expr obj-h281-reading obj-h40101-reading verbose
attr Power dev-h-combine 20
attr Power dev-h-defPoll 5

attr Power obj-h206-expr ($val/100)*4
attr Power obj-h206-reading Strom_L1
attr Power obj-h207-expr ($val/100)*4
attr Power obj-h207-reading Strom_L2
attr Power obj-h208-expr ($val * 4) /1000
attr Power obj-h208-reading Strom_L3
attr Power obj-h209-expr ($val * 4) / 1000
attr Power obj-h209-reading W_Leistung_L1
attr Power obj-h210-expr ($val * 4) / 1000
attr Power obj-h210-reading W_Leistung_L2
attr Power obj-h211-expr ($val * 4) / 1000
attr Power obj-h211-reading W_Leistung_L3
attr Power obj-h279-expr ($val * 4) / 100
attr Power obj-h279-reading Wirkleistung_gesamt
attr Power verbose 5

------------------------------------------------------
Strom_L1 2109.44 2017-12-06 11:58:00
Strom_L2 68 2017-12-06 11:58:00
Strom_L3 56.32 2017-12-06 11:58:00                 Ausgabe in Fhem
W_Leistung_L1 0 2017-12-06 11:58:00
W_Leistung_L2 0 2017-12-06 11:49:52
----------------------------------------------

Ist aber schon 30min. alt. Keine Aktualisierung.

Register vom Zähler, laut Anleitung:
RegisterAdress: 2008 5002 L1 Voltage Read Datablocks:4 Float Big Endian
RegisterAdress: 2068 500CL1 Current Read Datablocks:4 Float Big Endian
RegisterAdress: 2088 5014 L1 Avtice Power Read Datablocks:4 Float Big Endian

Hab mit format N n usw. getestet. Wenn ich meine Adressen 2008 bzw. 2007 usw. eingebe kommt nichts mehr.

Würde gerne im von mir einstellbaren Intervall alles von L1 des Zählers abfragen.

Helft mir bitte auf die Sprünge, ich verzweifele langsam. Viele ander Dinge hab ich am laufen, das hier ist mir im Moment zu hoch.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Heuberg am 06 Dezember 2017, 20:09:52
Hallo pontiac,

wie hast Du denn den Zähler angeschlossen?

Viele Grüße
Rainer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pontiac am 06 Dezember 2017, 23:13:00
Hallo Rainer,
am Raspi den USB RS485 Dongle, an A/B, hier auch den Abschlußwiderstand, Zweidraht zum Zähler auf A/B, von dort auf A/B zum Solarlog 300.
Länge ca. 30cm Dongle zum Zähler, ca. 8m zum Solarlog. Solarlog liest einwandfrei den Zähler aus. Den Widerstand am Dongle, da der Solarlog mein Master sein muß, so hab ich es verstanden.

LG Jann
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 07 Dezember 2017, 06:20:15
Hallo Jann,

Verstehe ich das richtig, du versuchst an einem RS485 Modbus mehrere Master zu betreiben? (Solarlog und FHEM)
Bei Modbus gibt es eigentlich nur einen Master und mehrere Slaves.
Kenne mich zwar mit Silarlog nicht aus und erfasse bei mir alles direkt in FHEM, aber du solltest Solarlog selbst via Modbus TCP abfragen können.

Lg crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Heuberg am 07 Dezember 2017, 09:11:28
Hallo Jann,

ja, den Solarlog solltest Du per TCP und Modbus-Adresse abfragen.

Viele Grüße
Rainer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pontiac am 07 Dezember 2017, 11:28:32
Hallo, DANKE euch für die Antworten!
Mein SolarLog ist dann der Master, der Zähler der Slave und ich versuche mit dem Dongle als Master zuzugreifen, das geht so nicht.
Mal schauen ob ich mir Modbus TCP Adapter zulege, ist mir das ganze wahrscheinlich nicht wert.

LG Jann
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Heuberg am 07 Dezember 2017, 12:27:58
Hallo Jann,
kann Dein Wechselrichter Modbus? Wenn ja hänge Deinen Zähler mit Modbus an den Wechselrichter und Du kannst die Daten darüber abrufen. Auf den Wechselrichter habe ich mit WLAN angebunden. So komme ich ohne Adapter aus  :) .
Viele Grüße
Rainer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 08 Dezember 2017, 07:26:16
Hallo Jann,

darf ich fragen welchen USB-RS485 Adapter du hast und ob der stabil auf der Raspi läuft?

Mein China Ding verursacht ca. 1x in der Woche folgende dmesg Meldung, verbindung ist dabei dann natürlich gestört.

[122157.169334] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Powered USB Hub,... hilft leider alles nichts, nur als ich die Raspi auf USB1.0 stellte lief er stabil, das will ich aber natürlich auch nicht.

Würde mir gerne einen anderen Adapter zu legen, wäre toll wenn mir wer einen empfehlen kann.

Danke
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pontiac am 08 Dezember 2017, 12:34:58
@Rainer
Mein Wechselrichter hat kein Modbus, "nur" Bluetooth, da hängt der Solarlog dran um Erzeugung zu lesen. 2. Zähler ist ein s0 am Solarlog um Hausverbrauch zu lesen. Der Modbuszähler ist für die Powerwall, hängt auch am Solarlog. Powerwall hab ich in FHEM, die loggt ja brav mit. Dachte mir nur das ich den Zähler noch direkt einbinde, lass ich jetzt aber. Danke nochmal für die Infos und Ideen.

@crispyduck
Hab einen CTI_GmbH_Serial_Converter, ob der stabil läuft kann ich leider nicht sagen, da er ja bei mir nichts ausliest. Projekt gescheitert.

LG Jann
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 08 Dezember 2017, 14:10:06
Danke,

das schaut zumindest nach einem vernünftigem Adapter aus, schätze mal das der an sich schon gut funktioniert, wenn mein 5€ China ding schon halbwegs geht.  ;)

Wenn du das Projekt Modbus RTU wirklich einstampfst und ihn nicht brauchst würde ich ihn nehmen.  :D

lg,
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Dezember 2017, 20:22:15
Hallo,

ich habe gute Erfahrungen mit dem RS485-Adapter von Digitus. Wird für ca. 10€ verkauft.
Aus China habe ich auch mehrere ausprobiert. Die mit nur 2 Anschlüssen haben am schlechtesten funktioniert.
Beim Abschlusswiderstand muss man vorsichtig sein. Die meisten Adapter haben den schon eingebaut. Doppelt ist dann zu viel.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 08 Dezember 2017, 21:22:54
Danke Stefan,

den Digitus hatte ich schon ins Auge gefasst, sollte jetzt einfach mal einen bestellen. Schiebe das schon seit ein paar Monaten vor mir her, glaube immer wieder es läuft stabil, dann wieder ein Fehler.
Ja, habe genau so einen mit den 2 Anschlüssen.

Bis jetzt war es ja nicht so schlimm, aber seit ein paar Tagen frage ich den Zähler im Sekundentakt ab um überschüssige PV Energie dann fast 1 zu 1 in einem Heizstab zu versenken. Da sollte die Verbindung (was sie bis jetzt ist) auch stabil bleiben.

Danke vorallem für dein Modul, habe es jetzt seit mittlerweile einem Jahr mit zwei SDM630 und einem eigenbau Arduino Bewässerungscomputer im Einsatz.

Lg
crispyduck


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pontiac am 08 Dezember 2017, 23:17:43
Hallo crispyduck, würde für den Adapter  inkl. Porto 25€ haben wollen, hat 39€ +Porto gekostet,
Mit dem Digitus bist du natürlich günstiger.

LG Jann
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 10 Dezember 2017, 07:44:54
Hallo Jann,  ist mir dann doch bisschen zu viel für mein Projekt, vorallem schätze ich mal das da Porto nach AT nicht inbegriffen ist!?

Lg
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: petergw am 11 Dezember 2017, 15:20:53
Hallo,

ich hoffe ich bin hier richtig. Ich habe mir ein Wifi Thermostat von ANSLEF („https://www.amazon.de/gp/product/B06XW3RZ3G/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1“) welches baugleich mit dem BECA Wifi Thermostat („https://www.amazon.de/dp/B01MZAQD8F/_encoding=UTF8?coliid=I2COSWPW70GYVU&colid=247RKMUYH4QS1&psc=0") ist.
Ich stellte eine supportanfrage an BECA und bekam die Anleitung der API.
Leider habe ich keine Ahnung wie ich das in Fhem mit modbus TCP umsetzten kann.
Könnte sich das jemand ansehen?

Danke im Voraus.

Anbei das Dokument von BECA
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Dezember 2017, 20:15:26
Hallo petergw,

In der Anleitung steht nichts von Modbus.
Das scheint ein anderes Protokoll zu sein.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: petergw am 12 Dezember 2017, 10:37:12
Danke für die Antwort.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: privat58 am 16 Dezember 2017, 15:55:16
Hallo, ich setze seit zwei Jahren 3x SDM630 Modbus erfolgreich ein. Diese werden in 5sec Abständen abgefragt. Seit ein paar Tagen habe ich Probleme und ein Teil der Daten kommt nur noch sporadisch rein. Verkabelung habe ich geprüt und der Bus ist auch mit Widerständen versehen.
Auch der RS485-Adapter wurde schon gegen einen baugleichen und einen FTDI getauscht. Busgeschindigkeit normal mit 9,6k und auch mit 19,2k probiert. Ist leider immer das selbe Problem.
Logauszug mit verbose5
2017.12.16 15:37:24 3: SDM630M: Notify / Init: opening connection
2017.12.16 15:37:24 3: Opening SDM630M device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2017.12.16 15:37:24 3: Setting SDM630M serial parameters to 19200,8,N,1
2017.12.16 15:37:24 3: SDM630M device opened
2017.12.16 15:38:49 1: Perfmon: possible freeze starting at 15:38:46, delay is 3.715
2017.12.16 15:40:22 5: SDM630M: raw read: 4004000000000400403480c0fef61066041000000fa256200061004000080000008c10008014a000ff7ee00802800440000c22000004000000000020100c01082484672288
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 7f7fc04000c008800602c80c080000000008000010000000418204200032
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: ce4cd9026080000020707b000800000000008410848030000080861800f0fe
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 9ff7992040326020202000002011010000000a20014010100003302638008c
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 5ffe0e813c00002040a00a400000020008000008301000046b08c8
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 30ce020c4088100008a066200400840000000000004800c8044140
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: ff
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 386360cc00046008c065e4000002424010043080f0800043400111c1
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 27100800a0082f83040810000000000000600002000100060000
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: ff3e5ed810
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 810000829c8c02020000001010000086100208048000c0
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: fa73a43040a010020048c0000800
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 0000000040211420040600280888
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: fa25f0400f200020100052080440000040600000c0004010001090030182
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 7e709ad8a080000400729002400a000002408000
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 8080301030481980
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: 5f00201b1008004250d002d0001040800008000440010801226028c0
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:22 5: SDM630M: raw read: fefbfc407208080006004638002800000100000000000014c0101006
2017.12.16 15:40:22 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: fe3883900203001c000cf60848000000080000000080006040160048fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 5ec220000020007ac20800000208020240000104f0800d2062
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: fed01b421008080010105000c0000000040000068c044010c010f8
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: feaffe0904200c0080000cf04000000c000000c00c004003442d40fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: f3
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 4638000800009000e0df00000240011003003121010000c0030080
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 374e10000000080888005220080040400000000400000440400000ac00fcff4f204831002200181180b6188800040000010020201011800680c4c0ffff0234080041008081443918040000000200401000080002003a0826fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 7fc0150002303810004d200000000000000022008070190900190200
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: fa1a20016000c018094ac20000024008000208800400000800808e80fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 058309c200
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 04ccd004c021c00000000001082004000040
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: e200c6
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: cf5eb80c40080000000024e02014a00000000080800880889276080cfe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 3eb08c000000088080c07b10000000
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 00094800ca40000401004010
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: fffeff01e608040440e004984e0e08080000000022400000200000111040ff
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: e570f861108001
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 0810e6288420004000004040080400001a3f0040fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 1c3a430000800002001f040440000000400886100080840888200002c0
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: fe3b2c00100000000590030003004100211000000c080ea080302e02
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: fb0950420020040c00d0000002400000000000000200000010300300
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: f0e1c0c1000200c21c1c8000000000800043040c40008441f180
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 223e680011008e80889c0e2001004000420002080c0004440c900420fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: c29158018008080222102316440020000200800000400040000200f8
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 7fd6c22e0c080004000808000600000200020002401404820284000c
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: f414401808040000507a2000020200000002008ec020c404020000f0ff
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: f7a6300d40008098801d0100440040002100020000048002c62802e1
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 361d840220010020005a0a00400008000400c0000c0204e4180000
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: fffe36784040114018180808c66210080000600000004010a0000420200110fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: fedf100a32000800003121c2001002000040004200040c1008310100f0
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: ff3132c884008008004098064404002010004000106100000a1d0110
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: ff
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 707f09a0080004300496c80302006280000040702040000000700013e0
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: ce9f4010200c
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 8002181a800040000000
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 000000008048400080d8
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: ee3e5226084200001009e2080003100010200001002000080810000083c0fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: ff5936fc8800001040406018100110000020103000080405229020f8
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: ffef48480700108007804100200000080040000000000088000808008c00c0
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: ff60e0877002082270d020040000004000000020cc0100008008008000
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: 1ffec28420100210001a4c0a0042080008c0080900003120200044b0
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: a1c800424e0c0c040000a4980e424000000800000200620c800281c3fe
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: raw read: ff60a02000108004880840ca0c000000000000000042000c088845a400fefc361b184200bc8000e82142401040200000000000802000048200860000fefe0201401000a00000f038000000204000200028200004000010f20801417e841c0420000000804024000208420000810100000100082082e060e0f0200000022550120100000000000020082001010e0420f0fe070a8010011a004006000a00000000000080800480c42014c2f05312400070000280012c0b841000040240040000003880028000420080fcfe801e200240848004600102c01080c0400000060000840c00c07000f8cefc06000004090e190ce60a00000008008082000100006802
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.477784872055
2017.12.16 15:40:23 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest -8.63156604766846
2017.12.16 15:40:23 5: SDM630M: HandleSendQueue: finished delay checking, proceed with sending
2017.12.16 15:40:23 4: SDM630M: HandleSendQueue sends fc 4 to id 3, tid 47 for Power_all (i52), len 24, device SDM630M_Victron (RTU), pdu 0400340018, V 3.7.0 - 20.8.2017
2017.12.16 15:40:23 5: SW: 030400340018b02c
2017.12.16 15:40:23 5: SDM630M: raw read: 80300a00ce17e036000080100c000302100640000000000000004000501005004040b87a110622200480a03640200080200040000000009800d08240c8
2017.12.16 15:40:23 5: SDM630M: ParseFrames got: 80300a00ce17e036000080100c000302100640000000000000004000501005004040b87a110622200480a03640200080200040000000009800d08240c8
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: recieved frame from unexpected Modbus Id 128, expecting fc 4 from 3 for device SDM630M_Victron
2017.12.16 15:40:23 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.491635799408
2017.12.16 15:40:23 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.689253091812134
2017.12.16 15:40:23 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.689253091812134
2017.12.16 15:40:23 5: SDM630M: raw read: 7ffbf7ffb7ffcf9f7a00003240000000
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.49823474884
2017.12.16 15:40:23 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.682766199111938
2017.12.16 15:40:23 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.682766199111938
2017.12.16 15:40:23 5: SDM630M: raw read: 10000000c0800448de240030ff
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.505089759827
2017.12.16 15:40:23 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.675877094268799
2017.12.16 15:40:23 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.675877094268799
2017.12.16 15:40:23 5: SDM630M: raw read: 717290d604a01030000e000002000040402080007089c31000da00fc
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.522831916809
2017.12.16 15:40:23 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.658172130584717
2017.12.16 15:40:23 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.658172130584717
2017.12.16 15:40:23 5: SDM630M: raw read: ff63c0013200200006444120100a55bac600000000421ff41d00000000c20d5a
2017.12.16 15:40:23 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:23 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.54166674614
2017.12.16 15:40:23 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.639259099960327
2017.12.16 15:40:23 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.639259099960327
2017.12.16 15:40:24 5: SDM630M: raw read: 213ef7349f00000000c27489c6000000004247e0f0446efa7f45ea19ac52dd00
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.558434963226
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.622547149658203
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.622547149658203
2017.12.16 15:40:24 5: SDM630M: raw read: 8000000f00
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.56524682045
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.615742206573486
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.615742206573486
2017.12.16 15:40:24 5: SDM630M: raw read: ffff4e00000000707c200000000000000010001c200000f00e00
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.582452774048
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.598590135574341
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.598590135574341
2017.12.16 15:40:24 5: SDM630M: raw read: 9ce2a204
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.588627815247
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.592411041259766
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.592411041259766
2017.12.16 15:40:24 5: SDM630M: raw read: 00008ae23d20000000020000026000100c0010180888
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.602386951447
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.578742027282715
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.578742027282715
2017.12.16 15:40:24 5: SDM630M: raw read: ffc0e8db160100840276442c0000200000000000000008b01c1c1c8e
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.622726917267
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.558257102966309
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.558257102966309
2017.12.16 15:40:24 5: SDM630M: raw read: fe021e788200000010000805084080400400000000800c101a230030
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.64262676239
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.538383007049561
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.538383007049561
2017.12.16 15:40:24 5: SDM630M: raw read: ce014ff804010108008014af10040200400040000204440101c340e0
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.662720918655
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.518290042877197
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.518290042877197
2017.12.16 15:40:24 5: SDM630M: raw read: ff7ff370d904
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.668962955475
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.512078046798706
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.512078046798706
2017.12.16 15:40:24 5: SDM630M: raw read: 8008065c204800
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.675444841385
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.505527019500732
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.505527019500732
2017.12.16 15:40:24 5: SDM630M: raw read: 2104020000000030002004002000
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.682371854782
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.498663187026978
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.498663187026978
2017.12.16 15:40:24 5: SDM630M: raw read: ff1058303006000010000ac60e00004000000000400004000040380140c0
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.702606916428
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.478450059890747
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.478450059890747
2017.12.16 15:40:24 5: SDM630M: raw read: feef580c01010000820e902e4000000100004801c00410800080308080f6
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.72319984436
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.457799196243286
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.457799196243286
2017.12.16 15:40:24 5: SDM630M: raw read: fece7c7c0012c0400080c01cc0204000000000010282000000008810f8fb
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.743638753891
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.437376976013184
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.437376976013184
2017.12.16 15:40:24 5: SDM630M: raw read: fe8ec400841000004600c00000010000000106400004010028400886c4
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.762847900391
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.418215036392212
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.418215036392212
2017.12.16 15:40:24 5: SDM630M: raw read: fe873e70a70000001008e400000000004010000200800080200e0070fe
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.783221960068
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.397767066955566
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.397767066955566
2017.12.16 15:40:24 5: SDM630M: raw read: fffce059020e00013010c3104808000020000070003010
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.798581838608
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.382483005523682
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.382483005523682
2017.12.16 15:40:24 5: SDM630M: raw read: 86000214c0ff
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.80503988266
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.375969171524048
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.375969171524048
2017.12.16 15:40:24 5: SDM630M: raw read: b0220c80010001604039427000401000000400010e181b00002020f8
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.822876930237
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.358193159103394
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.358193159103394
2017.12.16 15:40:24 5: SDM630M: raw read: d61a018b0004113a40420200026000080002010d320c0521188610f2
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.842929840088
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.338067054748535
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.338067054748535
2017.12.16 15:40:24 5: SDM630M: raw read: 50844004202048080408020000000000020000080000411a800000
2017.12.16 15:40:24 5: SDM630M: ParseFrames returned error: got data but did not send a request - ignoring
2017.12.16 15:40:24 5: SDM630M: handle queue check commDelay (0.7) for SDM630M_Victron: rest -349.862677812576
2017.12.16 15:40:24 5: SDM630M: handle queue check sendDelay (0.7) for SDM630M_Victron: rest 0.31827712059021
2017.12.16 15:40:24 4: SDM630M: HandleSendQueue / CheckDelay sendDelay (0.7) for SDM630M_Victron not over, try again in 0.31827712059021
Eventuell kann mir jemand auf die Sprünge helfen. Dank im Voraus
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Dezember 2017, 18:34:05
Hallo privat58,

Entweder Du hast massive Störungen auf der Leitung oder Dein Adapter hängt auf einer falschen Leitung, über die ein anderes Gerät mit einem anderen Protokoll kommuniziert.
Evt. Ist auch de Adapter defekt.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: privat58 am 19 Dezember 2017, 07:06:15
Danke Stefan, für die Antwort. Es geht wieder.
Ich hatte gestern noch einmal alles auseinander gerissen und habe die Zähler Stück für Stück wieder in Betrieb genommen. Als ich den letzten Zähler dran hatte ging wieder nichts. Es war der Teminierungswiderstand der sich verabschiedet hat. Danach hatte ich natürlich nicht gesucht und auch nicht damit gerechnet. Nachdem ich diesen ersetzt hatte, war alles wieder gut.
Vielen Dank.
Steffen
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 21 Dezember 2017, 23:17:06
Hi Stefan,
Rudi ändert an den timern in fhem.pl --> die Daten meiner Modbus Geräte (über RS485) konnten nicht mehr ausgelesen werden.
Log.-Meldungen:
2017.12.21 18:54:26 3: HA_Modbus_1: timeout waiting for fc 4 from id 1, Request was 010400c8002871ea (i200 / Voltage_L1_to_L2__V, len 40)
2017.12.21 18:54:24 3: HA_Modbus_1: timeout waiting for fc 4 from id 1, Request was 0104014e001e11e9 (i334 / THD_Voltage_L1_L2__prz, len 30)
2017.12.21 18:53:55 3: HA_Modbus_1: timeout waiting for fc 3 from id 2, Request was 02030058000245eb (h88 / Relay2_Energy_Type, len 2)
2017.12.21 18:53:53 3: HA_Modbus_1: timeout waiting for fc 3 from id 2, Request was 02030014000a85fa (h20 / Modbus_Node_adr, len 10)
2017.12.21 18:53:51 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 02040050001cf1e1 (i80 / Energy_apparent__kVAh, len 28)
2017.12.21 18:53:49 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 020400f0001e7002 (i240 / THD_Current_L1__prz, len 30)
2017.12.21 18:53:47 3: HA_Modbus_1: timeout waiting for fc 3 from id 2, Request was 0203002400080434 (h36 / System_Power__W, len 8)
2017.12.21 18:53:45 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 020400000028f027 (i0 / Voltage_L1__V, len 40)
2017.12.21 18:53:43 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 0204014e001e11da (i334 / THD_Voltage_L1_L2__prz, len 30)
2017.12.21 18:53:41 3: HA_Modbus_1: timeout waiting for fc 3 from id 2, Request was 0203000a000ae5fc (h10 / System_Type, len 10)
2017.12.21 18:53:39 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 020400280028702f (i40 / CosPhi_L3__grd, len 40)
2017.12.21 18:53:37 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 020400c8002871d9 (i200 / Voltage_L1_to_L2__V, len 40)
2017.12.21 18:53:35 3: HA_Modbus_1: timeout waiting for fc 4 from id 1, Request was 010400000028f014 (i0 / Voltage_L1__V, len 40)

Mit fhem.pl Version 15564 geht es noch.
Bitte schau es Dir mal an.

Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: noansi am 22 Dezember 2017, 03:37:22
Hallo Stefan,

eventuell hängt Rogers Problem hiermit https://forum.fhem.de/index.php/topic,81365.msg734603.html#msg734603 (https://forum.fhem.de/index.php/topic,81365.msg734603.html#msg734603) und im SVN konkret https://svn.fhem.de/trac/changeset/15657/ (https://svn.fhem.de/trac/changeset/15657/) worauf ich Dich ohnehin aufmerksam machen wollte wegen tiefgreifenderen Änderungsideen im Thread mit Änderungsbedarf bei 98_Modbus.pm.

Wie eng sind die Timinganforderungen und wie eng ist das Modbusmodul mit dem bisherigen Timerabarbeitungsverhalten verwoben?

Gruß, Ansgar.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: herrmannj am 22 Dezember 2017, 10:49:41
@roger: in Arbeit.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: noansi am 22 Dezember 2017, 11:07:58
Hallo Roger,

gibt es eventuell andere Gründe für Dein Problem?
Hast Du dem System was hinzu gefügt?

Mit mehr verbose könnte es klarer werden.

Gruß, Ansgar.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 22 Dezember 2017, 11:36:15
Hallo,

habe gerade ein Update ausgeführt und trotz fhem.pl 15657 bis jetzt keine Probleme.

Habe 3 Modbus Devices an einem USB-RS485 Adapter. 2xSDM630 wo ich alle Werte im 2 und 3 Minuten Takt abfrage und 1xArduino als Bewässerungscomputer.
Auf einem der SDM630 führe ich außerdem im 2 Sekundentakt ein get für einen Wert aus.

Lg,
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: herrmannj am 22 Dezember 2017, 11:39:03
Dankeschön!

Das entspricht auch eher dem erwarteten Verhalten ;)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Dezember 2017, 11:47:04
Hallo,

ich vermute dass das Problem nur auftritt wenn Daten mit "get" abgefragt werden. Dann läuft das in ModbusLD_ReadAnswer und dort wird der vorhandene Timer abgefragt.
Bei den normalen zyklischen Abfragen im Modbus-Modul geht alles über den regulären InternalTimer.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: herrmannj am 22 Dezember 2017, 11:52:10
hast Du eine Idee warum sich das Verhalten dort geändert hat ? 'Eigentlich' ist doch dort alles wie immer ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Dezember 2017, 14:00:01
Hallo,

anbei eine neue Version, bei der ich den Zugriff auf die intAt-Struktur ersetzt habe.
Damit sollte es hoffentlich keine Probleme mehr mit der Änderung bei internalTimer geben.
@Roger: kannst Du es trotz Weihnachtsvorbereitungen kurz testen?

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 22 Dezember 2017, 17:41:24
Hi Stefan,
habe Deine neue Version, wo DU den Zugriff auf die intAt-Struktur ersetzt hast, eingespielt und auch die fhem.pl von heute (Version 15667) --> bisher läuft es. Aber der Abbruch kam auch nicht gleich.

Extra get-Befehle führe ich nicht durch, habe aber neben dem Modbus Modul für zwei SDM630 auch noch zwei Module für Modbus-Abfragen für einen Fronius-Wechselrichter über TCP am laufen.
siehe https://forum.fhem.de/index.php/topic,46685.0.html (https://forum.fhem.de/index.php/topic,46685.0.html)

Bisher lief es stabil  :-[
aber wir/ihr werden es schon hinbekommen  :D
Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andy1981 am 29 Dezember 2017, 15:31:37
Hallo Zusammen und erstmal danke für die FHEM Modbus Module und den Support dazu.
Seit Juni habe ich das Modbus Modul mit einem Fronius WR über TCP am laufen, hat alles wunderbar und ohne Probleme funktioniert. Da es an Weihnachten ja meist etwas langweilig ist habe ich über die Feiertage 2 RS485 Zähler eingebaut (SDM220 und SDM630) Aufgrund eines fehlenden RS485 Adapters habe ich mir schnell einen Adapter aus einem FTDI232RL USB Modul und einem sn75176bp Transceiver zusammengebrutzelt. Das Ganze Gebilde habe ich dann an meinem Windows 10 PC mit einem Modbus Master Simulator getestet, erstaunlicherweise hat alles gleich funktioniert :).
Also hab ich das ganze an meinen Raspi mit FHEM angeschlossen und konfiguriert und siehe da, die Daten Purzeln nur so herein :).
Nach 3 Datenübertragungen dann auf einmal Funkstille >:(. Sobald ich einen get Befehl abschicke wird dieser mit Timeout quittiert. In der Log Datei werden ebenfalls alle Zyklischen abfragen mit Timeout quittiert.

Also Oszi raus und mal schauen was am Bus so ab geht:
Zu meinem erstaunen sendet de Raspi Zyklisch die Anfragen und bekommt auch Antwort von den slaves, nur irgendwie bekommt der Raspi die Antwort nicht mit. Zum testen habe ich einen Slave mit FTDI232RL USB Modul und sn75176bp Transceiver auf einem Steckbrett gebastelt und in den Bus gehängt, diesen Slave habe ich jetzt wieder an meinem Windows 10 PC hängen. Mit HTerm sehe ich die Daten die von FHEM zyklisch gesendet werden und die Antworten der einzelnen slaves, die readings der slaves in FHEM werden jedoch nicht aktualisiert. Wenn ich bei FHEM das Modbus Device disable kurz auf "1" setzte und anschließend wieder auf "0", dann werden die readings der devices wieder für 2-3 Zyklen aktualisiert, so lange die Zyklische Abfrage funktioniert, geht auch die Abfrage über get. Anschließend fängt der Timeout wieder an.
Als weiteren Test habe ich das Modbus Device in FHEM deaktiviert und über die Konsole an den Anschlus ttyUSB0 geschickt:
Anfrage geht vom Raspberry raus, angesprochener Slave antwortet und die Antwort wird in der Raspberry Konsole angezeigt. Nach ca 2 Minuten geht zwar die Anfrage noch raus, der Slave antwortet auch weiterhin, aber es werden keine Daten mehr in der Konsole angezeigt.
So wie sich das ganze verhält würde ich sagen es gibt ein Problem mit dem FTDI Treiber am Raspberry. Momentan schließe ich einen Fehler im Modul oder meiner Hardware aus. Meine Linux Kenntnisse sind leider eher bescheiden, falls jemand eine Idee hat wie man das Problem weiter eingrenzen kann dann einfach melden, habe momentan noch alles als Testumgebung aufgebaut.
 
@Roger: Verwendest du ebenfalls einen FTDI Adapter?

Gestern bin ich mit FHEM vom Raspberry2 auf einen Raspberry3 umgezogen, das Problem ist genau das gleiche. FHEM und Betriebssytem sind auf dem aktuellen Stand vom 29.12.2017.
Ich habe jetzt mal ein paar verschiedene RS485 Adapter bestellt, mal schauen ob ich mit denen Erfolg habe. Werde mich melden sobald ich weitere Erkenntnisse zu dem Problem gesammelt habe.
Einen guten Rutsch in 2018 an alle

Gruß Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andy1981 am 30 Dezember 2017, 14:59:44
Hallo Zusammen, ich habe noch ein paar gute Nachrichten (für mich) im alten Jahr :).
Nach langem probieren und googeln bin ich auf das Problem mit den FTDI Chips gestoßen. Hier mal eine kurze Beschreibung wie ich das Problem umgehen konnte.
Putty Konsole öffnen und Befehl dmesg eingeben -> Solange die Kommunikation funktioniert steht hier noch nichts auffälliges drin, sobald die Readings in FHEM nicht mehr aktuallisiert wurden, wurde folgender Text ausgegeben:
ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Das Problem wird im Zusammenhang mit den FTDI Chips und Raspberry häufig diskutiert, als Workaround wird vorgeschlagen die USB Anschlüsse von USB2.0 auf USB1.1 Standard zu zwingen. Ich habe keine USB2.0 Geräte an meinem Raspberry hängen, also hab ich es gleich mal ausprobiert. Es muss nur in die /boot/cmdline.txt der Befehl dwc_otg.speed=1 eingefügt werden und anschließend ein reboot.
Seit der Änderung vor 5 Stunden quatscht FHEM im Intervall von 60s unaufhörlich mit den beiden Zählern, auch ein get zwischendurch bringt das System nicht aus dem Tritt.
In diesem Sinne nochmals einen guten Rutsch

Gruß Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 30 Dezember 2017, 16:15:14
Hallo,

ja das Problem habe ich auch, allerdings nicht mit einem FTDI, sondern einem 3€ China RS485 Adapter. Siehe meinen Beitrag irgendwo weiter vorne in dem Thread.

Hab mit jetzt einen Digitus RS485 Adapter FTDI/FT232RL bestellt und eigentlich auch schon eine Woche hier rum liegen.

Bin gerade dabei auf diesen umzusteigen, aber irgendwie funktioniert momentan überhaupt nichts, bekomme keine Antwort. Eventuell liegt es daran das ich aktuell keine Abschlusswiderstände habe da damit der China Adapter überhaupt nicht ging. Mal schauen, was da los ist...

FYI: dwc_otg.speed=1, limits all USB devices (including the onboard network adaptor) to 12Mbps

Lg,
crispyduck



Am
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andy1981 am 30 Dezember 2017, 21:38:35
Hallo Crispyduck,
die vorherigen seiten dieses Thread hab ich aus Zeitgründen nur überflogen und deshalb deinen Eintrag übersehen...hätte mir wahrscheinlich etwas Zeit erspart. Das mit der geschwindigkeit für den netzwerkcontroller hab ich auch gelesen, ist halt auch nur ein workaround vorrübergehend. Bei dem datendurchsatz für Fhem bin ich mir nicht sicher ob man wirklich einen nachteil hat, ich konnte bisher keinen nachteil feststellen.
Mir ging es in erster Linie mal darum, dass ich mit meinen vorhandenen mitteln die Zähler auslesen und loggen kann, nächstes Jahr bekomme ich 3 verschiedene Adapter zum testen, mal schauen wie sich die dann schlagen.
Die von mir verwendeten ftdi chips habe ich vor ca 2 jahren gekauft und bisher nur an windows PC's verwendet. Ich gehe mal davon aus, dass es sich hierbei nicht um fakes handelt, zumindest hat der windows treiber noch nicht die ID gelöscht. Hört sich allerdings nicht so toll an, wenn du mit anderen chips die gleichen Probleme am Raspberry hast.
Wünsche dir viel erfolg  mit deinem Adapter, werde mich wieder melden wenn ich die anderen adapter getestet habe.
Gruß Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 31 Dezember 2017, 10:01:41
Hi,

Also ich glaube mein Digitus Adapter hat was. Habe jetzt einen Loopback test mit dem China Adapter und dem Digitus gemacht und wie es scheint sendet der neue Adapter nichts.
Habe jetzt einen neuen bestellt, mal schauen.

@FTDI an der Raspi, ich hab seit Jahren auf der selben Raspi einen Viessmann Optolink Adapter mit FT232RL ohne einen einzigen Ausfall mit USB2.0 in Betrieb.

Ich bin mir immer noch nicht ganz sicher woher der " urb stopped: -32" Fehler kommt.
Dachte erst an ein Strom Problem, habe daher den Strom an USB Bus auf das maximum aufged (max_usb_current=1), half aber auch nicht, externer USB Hub mit eigenem Powersupply scheinte erst zu helfen, aber dann nach einer Woche wieder der Fehler. Mit USB 1.1 lief es eine Woche gut, bin dann aber wieder auf USB2.0.
Hatte den Stick mal schlecht angesteckt, da kam der Fehler dann viel häufiger. Strom schließe ich nach meinen Tests aus, dürfte eher ein Kommunikationsproblem zwischen USB controller und Stick sein, welches bei schlechtem Kontakt noch häufiger auftritt und bei langsamerer Bus Geschwindigkeit nicht auftritt.

Ich probiere es nächste Woche nochmal mit dem Digitus, und wenn der dann wieder nicht läuft, weiß ich auch nicht weiter, könnte dann nur noch einen USB 1.1 Hub dazwischen hängen um nur den Stick auf 1.1 zu haben.

@Stefan: neue Version läuft bei mir ohne Probleme und ich habe viel seltener Timeouts bei get Abfragen im Sekundentakt.

Lg
Crispyduck

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 04 Januar 2018, 13:52:32
Hi,

wollte nur nochmal Rückmeldung geben.

Also der erste Digitus Adapter hatte tatsächlich was, gestern ist dann der neue gekommen und der läuft jetzt mit 150 Ohm Abschlusswiderständen und 480 Ohm Pull up und Pull down Widerständen seit gestern Vormittag ohne Probleme.

Chip in dem Adapter ist ein FTDI FT232RL.

Lg,
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andy1981 am 07 Januar 2018, 15:01:33
Hi,

und ein frohes neues Jahr an alle.
Ich hab noch einen alten Lan com server von w&t in meinem bestand gefunden und angeschlossen...funktioniert einwandfrei. Wahrscheinlich werde ich mit dieser variante weitermachen und mich vorerst nicht mehr um den zickigen usb am raspberry kümmern.
Als nächstes steht an meine pluggit lüftung an den rs485 bus zu bringen, was ziemlich lustig werden kann. Zum glück haben die Kollegen vom knx Forum da schon viel vorarbeit geleistet.

Gruß Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andy1981 am 19 Januar 2018, 19:52:32
Hallo Modbus/Perl Spezialisten,

mein Modbus üer den Com Server läuft nach wie vor noch stabil und ich habe jetzt mal ein bisschen weiter an der Anbindung meiner Pluggit Lüftung gearbeitet. Die Kommunikation zur Anlage läuft bereits, momentan kämpfe ich allerdings mit der unpack Schablone um die Werte in den Readings richtig anzuzeigen. Die Pluggit Anlage sendet die meisten Daten wie z.B die Temperaturen im Signed Byte Format. Im Holdingregister 9 befinden sich z.B. die Temperaturen für "Zuluft" im High Byte und "nach WT" im Low Byte. Wenn ich das Ganze jetzt mit der unpack Schablone "c" auswerte bekomme ich den richtigen Wert für das High Byte angezeigt, aber wie kann ich mir jetzt ein zweites Reading auf das gleiche Register anlegen und das Low Byte auswerten?  Gibt es eine Möglichkeit überhaupt im Modbusattr Modul die Bytes einzeln in Readings zu packen?
Meine nächste Idee wäre ansonsten das Register als Integer auszuwerten und anschließend versuchen das ganze als Userreading auszuwerten, momentan fällt mir zumindest keine andere Lösung ein.
Hat jemand einen Tipp für mich wie man die Aufteilung am besten realisieren kann?

Danke, Gruß
Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Januar 2018, 18:17:46
Hallo Andreas,

Das Modbus-Modul geht beim Parsen davon aus, dass für jede Adresse nur ein Reading erzeugt wird.
Du könntest aber versuchen, in einer "expr" für eine Adresse per Perl readingsBulkUpdate($hash, "nachWT", $val) aufzurufen.
Die Expressions für ein Reading werden im Modul von der Funktion Modbus_CheckEval ausgewertet und dort steht der aktuelle Device-Hash und der Wert zur Verfügung.
Das hat gegenüber einem Userreading den Vorteil, dass Du das Ergebnis später als eigenes Modul für die Pluggit-Lüftung speichern kannst und andere Anwender keine zusätzlichen Attribute setzen müssen wenn Sie Dein Pluggit-Modul verwenden wollen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Negropo am 21 Januar 2018, 11:06:16
Hallo,

ich bin relativ neu in der Modbus-Welt und versuche an FHEM eine Unipi Neuron Extension (xS10) via Modbus RTU anzubinden.
Ich habe folgende Konfiguration in der fhem.cfg mit der ich einige Register (die der 8 Relays) auslese

#Neuron xS10
define NeuronModbus Modbus /dev/ttyUSB0@19200,8,N,1
define NeuronxS10 ModbusAttr 15 10 RTU
attr NeuronxS10 dev-i-combine 8
attr NeuronxS10 userattr obj-i10001-reading obj-i10001-unpack obj-i10001-poll
attr NeuronxS10 obj-i10001-reading RO1
attr NeuronxS10 obj-i10001-unpack N
attr NeuronxS10 obj-i10001-poll 1

attr NeuronxS10 userattr obj-i10002-reading obj-i10002-unpack obj-i10002-poll
attr NeuronxS10 obj-i10002-reading RO2
attr NeuronxS10 obj-i10002-unpack N
attr NeuronxS10 obj-i10002-poll 1

attr NeuronxS10 userattr obj-i10003-reading obj-i10003-unpack obj-i10003-poll
attr NeuronxS10 obj-i10003-reading RO3
attr NeuronxS10 obj-i10003-unpack N
attr NeuronxS10 obj-i10003-poll 1

attr NeuronxS10 userattr obj-i10004-reading obj-i10004-unpack obj-i10004-poll
attr NeuronxS10 obj-i10004-reading RO4
attr NeuronxS10 obj-i10004-unpack N
attr NeuronxS10 obj-i10004-poll 1

attr NeuronxS10 userattr obj-i10005-reading obj-i10005-unpack obj-i10005-poll
attr NeuronxS10 obj-i10005-reading RO5
attr NeuronxS10 obj-i10005-unpack N
attr NeuronxS10 obj-i10005-poll 1

attr NeuronxS10 userattr obj-i10006-reading obj-i10006-unpack obj-i10006-poll
attr NeuronxS10 obj-i10006-reading RO6
attr NeuronxS10 obj-i10006-unpack N
attr NeuronxS10 obj-i10006-poll 1

attr NeuronxS10 userattr obj-i10007-reading obj-i10007-unpack obj-i10007-poll
attr NeuronxS10 obj-i10007-reading RO7
attr NeuronxS10 obj-i10007-unpack N
attr NeuronxS10 obj-i10007-poll 1

attr NeuronxS10 userattr obj-i10008-reading obj-i10008-unpack obj-i10008-poll
attr NeuronxS10 obj-i10008-reading RO8
attr NeuronxS10 obj-i10008-unpack N
attr NeuronxS10 obj-i10008-poll 1
attr NeuronxS10 verbose 5

Kann man das noch optimieren, z.B. durch irgend eine Kombination von Befehlen?
Wie kann ich die readings RO1, RO2... etc. in FHEM auswerten/anzeigen lassen (als Antwort kommt vom Neuron eine 0 wenn das Reay ausgeschaltet ist und eine 1 wenn ein) und die wichtigste Frage,
Wie sieht der Befehl (vermutlich ein SET) aus um das Relay zu schalten?

Vielen Dank und Gruß
Negropo
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: lewej am 22 Januar 2018, 20:07:37
Hallo Zusammen,

ich versuche ein Relay Board von Kmtronic(RS485) auslesen bzw. zu schalten, jedoch weiß ich nicht wie ich diese Adressen definieren muss. Kann mir jemand einen Tipp, bzw ein Bespiel für eine definition sagen?


Folgende habe ich bereits gemacht:
Internals:
   BUSY       0
   CFGFN     
   DEF        /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.4:1.0-port0@9600,8,N,1
   DeviceName /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.4:1.0-port0@9600,8,N,1
   FD         22
   LASTOPEN   1516646757.35302
   NAME       ModBusLine
   NR         50368
   NTFY_ORDER 50-ModBusLine
   PARTIAL   
   STATE      opened
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   READINGS:
     2018-01-22 19:45:57   state           opened
   helper:
     buffer     
Attributes:
   room       Modbus

Internals:
   CFGFN     
   DEF        5 60 RTU
   DEST       
   INTERVAL   60
   MODBUSID   5
   ModuleVersion 3.7.0 - 20.8.2017
   NAME       kmtronic1
   NOTIFYDEV  global
   NR         50584
   NTFY_ORDER 50-kmtronic1
   PROTOCOL   RTU
   STATE      ???
   TYPE       ModbusAttr
Attributes:
   room       Modbus
   userattr   

Laut Hersteller kann diese Relais Abfragen und schalten.

RS485 Relays commands

 

 
           ON Command                    OFF Command
              DEC   HEX                      DEC      HEX
Relay Board ID:01 Relay 1 Channel 1 255 1 1 FF 01 01 255 1 0 FF 01 00
Relay Board ID:01 Relay 2 Channel 2 255 2 1 FF 02 01 255 2 0 FF 02 00
Relay Board ID:01 Relay 3 Channel 3 255 3 1 FF 03 01 255 3 0 FF 03 00
Relay Board ID:01 Relay 4 Channel 4 255 4 1 FF 04 01 255 4 0 FF 04 00
Relay Board ID:01 Relay 5 Channel 5 255 5 1 FF 05 01 255 5 0 FF 05 00
Relay Board ID:01 Relay 6 Channel 6 255 6 1 FF 06 01 255 6 0 FF 06 00
Relay Board ID:01 Relay 7 Channel 7 255 7 1 FF 07 01 255 7 0 FF 07 00
Relay Board ID:01 Relay 8 Channel 8 255 8 1 FF 08 01 255 8 0 FF 08 00
Relay Board ID:02 Relay 1 Channel 9 255 9 1 FF 09 01 255 9 0 FF 09 00
Relay Board ID:02 Relay 2 Channel 10 255 10 1 FF 0A 01 255 10 0 FF 0A 00
Relay Board ID:02 Relay 3 Channel 11 255 11 1 FF 0B 01 255 11 0 FF 0B 00
Relay Board ID:02 Relay 4 Channel 12 255 12 1 FF 0C 01 255 12 0 FF 0C 00
Relay Board ID:02 Relay 5 Channel 13 255 13 1 FF 0D 01 255 13 0 FF 0D 00
Relay Board ID:02 Relay 6 Channel 14 255 14 1 FF 0E 01 255 14 0 FF 0E 00
Relay Board ID:02 Relay 7 Channel 15 255 15 1 FF 0F 01 255 15 0 FF 0F 00
Relay Board ID:02 Relay 8 Channel 16 255 16 1 FF 10 01 255 16 0 FF 10 00
Relay Board ID:03 Relay 1 Channel 17 255 17 1 FF 11 01 255 17 0 FF 11 00
Relay Board ID:03 Relay 2 Channel 18 255 18 1 FF 12 01 255 18 0 FF 12 00
Relay Board ID:03 Relay 3 Channel 19 255 19 1 FF 13 01 255 19 0 FF 13 00
Relay Board ID:03 Relay 4 Channel 20 255 20 1 FF 14 01 255 20 0 FF 14 00
Relay Board ID:03 Relay 5 Channel 21 255 21 1 FF 15 01 255 21 0 FF 15 00
Relay Board ID:03 Relay 6 Channel 22 255 22 1 FF 16 01 255 22 0 FF 16 00

Auf der Konsole kann ich die Relays schalten

echo -e '\xff\x01\x01' >  /dev/serial/by-path/pci-0000\:00\:14.0-usb-0\:4.4\:1.0-port0
echo -e '\xff\x01\x00' >  /dev/serial/by-path/pci-0000\:00\:14.0-usb-0\:4.4\:1.0-port0

Gruß
lewej
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 22 Januar 2018, 21:40:31
Hallo Lewej,

es scheint, dass dieses Board zwar eine RS485-Schnittstelle besitzt, jedoch nicht Modbus "spricht" . Das Modbus-Modul wird dir also hier nicht weiterhelfen können.

Vielmehr sieht das nach einer sehr einfachen seriellen Befehlsübertragung aus.

LG
Mike

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: lewej am 22 Januar 2018, 21:47:41
Hi,

laut Hersteller schon, oder interpretiere ich das falsch?

Communication Parameters:
8 Data, 1 Stop, No Parity
Baud rate : 9600

MODBUS Commands:
01 (0x01) Read Coils
05 (0x05) Write Single Coil

Coil 0000: Relay 01
Coil 0001: Relay 02
Coil 0002: Relay 03
Coil 0003: Relay 04
Coil 0004: Relay 05
Coil 0005: Relay 06
Coil 0006: Relay 07
Coil 0007: Relay 08


Hallo Lewej,

es scheint, dass dieses Board zwar eine RS485-Schnittstelle besitzt, jedoch nicht Modbus "spricht" . Das Modbus-Modul wird dir also hier nicht weiterhelfen können.

Vielmehr sieht das nach einer sehr einfachen seriellen Befehlsübertragung aus.

LG
Mike
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Januar 2018, 22:03:30
Hallo lewej,

die Befehle, die bei Dir über die Konsole funktionieren, sind keine Modbus-Frames.
Entweder muss erst noch von den einfachen seriellen Befehlen auf Modbus umgestellt werden
oder Dein Board verstehen zwei Protokolle gleichzeitig
oder Modbus geht gar nicht ...

Wenn Du es mit Modbus versuchen möchtest, dann müsstest Du die Modbus-Id des Boards kennen (oft einfach 1) und Du müsstest Die Coils mit obj-c001-... definieren.
Im Wiki, hier im Forum und der Commandref findest Du Beispiele.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 22 Januar 2018, 22:07:12
es steht so da ... ja.


Da du das Modell nicht angegeben hast, habe ich nur mal auf die Schnelle bei KMtronic geschaut, der zum Beispiel https://www.kmtronic.com/RS485%20Relay%20Controllers?product_id=73 (https://www.kmtronic.com/RS485%20Relay%20Controllers?product_id=73) verwendet genau das von dir beschriebene Befehlsformat. RS485 ( physical serial Layer ) Ja, Modbus Nein.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Januar 2018, 22:09:10
Hallo Negropo,

Zitat
Kann man das noch optimieren, z.B. durch irgend eine Kombination von Befehlen?
Du kannst z.B. statt bei jedem Input-Register erneut den Unpack-Code und -poll anzugeben entsprechende Defaults für alle Input-Register setzen (dev-i...)
Zitat
Wie kann ich die readings RO1, RO2... etc. in FHEM auswerten/anzeigen lassen (als Antwort kommt vom Neuron eine 0 wenn das Reay ausgeschaltet ist und eine 1 wenn ein)
Diese Frage verstehe ich nicht. Die Readings werden doch in Fhemweb angezeigt sobald Werte erfolgreich gelesen wurden. Oder klappt das Lesen schon nicht?
Zitat
und die wichtigste Frage,
Wie sieht der Befehl (vermutlich ein SET) aus um das Relay zu schalten?
Auch der set-Befehl muss mit Attributen je Objekt aktiviert werden.
obj-xy-set 1Im Wiki und der Commandref ist dafür sogar ein Beispiel.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: lewej am 22 Januar 2018, 22:16:13
es steht so da ... ja.


Da du das Modell nicht angegeben hast, habe ich nur mal auf die Schnelle bei KMtronic geschaut, der zum Beispiel https://www.kmtronic.com/RS485%20Relay%20Controllers?product_id=73 (https://www.kmtronic.com/RS485%20Relay%20Controllers?product_id=73) verwendet genau das von dir beschriebene Befehlsformat. RS485 ( physical serial Layer ) Ja, Modbus Nein.

Wie recht du hast :(.

Die haben das selbe Board noch mit Modbus:
https://sigma-shop.com/product/153/rs485-8-channel-relay-controller-modbus-rtu.html

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: lewej am 23 Januar 2018, 10:52:31
Hallo Zusammen,

Ich hab eine Frage zur Reaktionszeit, wenn ich per Modbus eine Digital Input Board anschliesse, wie schnell reagiert fhem hier? Liegt man im millisekunden Bereich oder eher im Sekunden Bereich?

Gruss
Lewej
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andy1981 am 23 Januar 2018, 12:48:31
Hallo Stefan,

Du könntest aber versuchen, in einer "expr" für eine Adresse per Perl readingsBulkUpdate($hash, "nachWT", $val) aufzurufen.
danke für den Tipp, aber ich habe mich jetzt für einen anderen Weg entschlossen. Da ich sowieso ein arduino als Gateway zwischen meiner Pluggit und FHEM habe, werde ich den arduino als Modbus slave nach der Modbus Spezifikation programmieren. Ich werde in meine Lüftungsanlage noch VOC, Luftdruck, Luftfeuchte und Temperatursensoren einbauen, die Daten will ich auch noch über RS485 an FHEM schicken. Die Kommunikation Arduino Mega zur Pluggit und den Sensoren hab ich fertig, jetzt muss ich noch die Software für einen Modbus slave erstellen. Als Endgültige Version stell ich mir dann noch vor ein paar DI und DO über Modbus mit dem Arduino abzufragen/steuern.

Gruß Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Januar 2018, 17:51:30
Hallo lewej,

Zitat
wenn ich per Modbus eine Digital Input Board anschliesse, wie schnell reagiert fhem hier? Liegt man im millisekunden Bereich oder eher im Sekunden Bereich

Bei Modbus fragt ein Master in regelmäßigen Abständen den Status des Slave ab. Das kann man nicht alle 10 Millisekunden tun. Eher alle 30 Sekunden.
Das ist kein Problem von Fhem sondern vom Protokoll. Wenn Du innerhalb von Millisekunden auf einen Eingang reagieren möchtest, dann sollte das Eingangsmodul sich selbst bei Fhem melden können und nicht darauf warten, dass Fhem nach dem aktuellen Status fragt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Negropo am 27 Januar 2018, 10:51:50
Hallo Negropo,
Du kannst z.B. statt bei jedem Input-Register erneut den Unpack-Code und -poll anzugeben entsprechende Defaults für alle Input-Register setzen (dev-i...)Diese Frage verstehe ich nicht. Die Readings werden doch in Fhemweb angezeigt sobald Werte erfolgreich gelesen wurden. Oder klappt das Lesen schon nicht?Auch der set-Befehl muss mit Attributen je Objekt aktiviert werden.
obj-xy-set 1Im Wiki und der Commandref ist dafür sogar ein Beispiel.

Gruss
   Stefan

Hallo Stefan,

vielen Dank für die Info. Habe es etwas gestrafft.

Zu meiner etwas unverständlichen Frage Die Readings werden bei mir nicht direkt im fhemweb angezeigt sondern lediglich im log-File sehe ich die Werte. Muss ich noch irgendeinen Dummy anlegen und ihm den Wert zuweisen oder wie funktioniert das?

Noch eine Frage zu dem set-Befehl: Ich würde gern einen Taster-Dummy anlegen mit dem ich dann den set-Befehl absetzen kann und somit das Relay ein und ausschalte. Kannst du mir sagen ob und wenn ja, wie der Aufruf sein müsste?!

Hier mal ein Auszug von den Log-Einträgen zu dem ich noch eine Frage habe (habe das Reading auf die coils umgestellt):

2018.01.27 11:46:26 5: NeuronxS10: GetUpdate called
2018.01.27 11:46:26 4: NeuronxS10: update timer modified: will call GetUpdate in 60.0 seconds at 2018-01-27 11:47:26 - Interval 60
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate objects from attributes: c6 c3 c5 c7 c2 c1 c8 c4
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate full object list: c1 c2 c3 c4 c5 c6 c7 c8
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate check c1 => 1, poll = 0, last = 0
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate check c2 => 1, poll = 0, last = 0
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate check c3 => 1, poll = 0, last = 0
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate check c4 => 1, poll = 0, last = 0
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate check c5 => 1, poll = 0, last = 0
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate check c6 => 1, poll = 0, last = 0
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate check c7 => 1, poll = 0, last = 0
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate check c8 => 1, poll = 0, last = 0
2018.01.27 11:46:26 5: NeuronxS10: GetUpdate tries to combine read commands
2018.01.27 11:46:26 5: NeuronxS10: don't sort objList before sending requests

Danke und Gruß
Negropo
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 Januar 2018, 20:41:36
Hallo Negropo,

in dem von Dir geposteten Log-Ausschnitt sieht man dass das Modbus-Modul prüft, ob die Objekte c1, c2 etc. überhaupt abgefragt werden sollen. Poll=0 bedeutet, dass Du weder im Objekt noch als Default für alle Coils poll auf 1 gesetzt hast. Entsprechend wird nichts abgefragt.
Du brauchst keinen Dummy sondern ein Attribut wie in den Beispielen der Anleitung.

Wenn Du ein Relais per Coil 1 schalten möchtest und dieses z.B. als obj-c1-reading Relais1 benannt hast, dann würdest Du mit obj-c1-set 1 den Set-Befehl ermöglichen und dann z.B. mit set Relais1 1 schalten.

Gruß
     Stefan.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Herjemine am 31 Januar 2018, 12:22:51
Hallo Stefan,

hast Du seit der 98_Modbus.pm 98_ModbusAttr.pm von 2017-07-15 noch was am IP Reconnect gemacht?
Muss ich für den Reconnect ein Timeout  Attribut setzen?

Bei mir bleiben die Devices immer mal wieder mit disconnect hängen, bis ich nen fhem neustart mache.

Gruß Hermann
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: device111 am 31 Januar 2018, 19:57:08
Hallo zusammen,

hab jetzt mal das "saveAsModule" Module feature probiert und es funktioniert auch einwandfrei.

Das Modul ist für eine IDM Wärmepumpe mit Navigator 1.7

Einfach ins FHEM Verzeichnis kopieren und definieren als Modul: "ModbusGenIDM <Parameter>".

Danke an Stefan für das echt coole Modbusattr. 

Viel Spass damit.

Gruß,
Martin
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 Februar 2018, 08:35:09
Hallo Hermann,

hast Du seit der 98_Modbus.pm 98_ModbusAttr.pm von 2017-07-15 noch was am IP Reconnect gemacht?
Muss ich für den Reconnect ein Timeout  Attribut setzen?

Im letzten Update habe ich zwar Änderungen am Timeout machen müssen, aber ich kann mir eigentlich nicht vorstellen, dass die negative Auswirkungen haben können. Bei TCP basierten Verbindungen sollte aber maxTimeoutsToReconnect gesetzt werden. Dann versucht das Modul nach der Anzahl vorgegebener Timeouts die TCP-Verbindung neu aufzubauen.
Hast Du das schon gesetzt?

Gruss
  Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mani am 12 Februar 2018, 15:40:14
Hallo @Stefan Strobl,

wie gewünscht nun meine Frage betreffend Varista Ernergyguard.

Ich habe vom Hersteller nachfolgende Info zur RS485 Schnittstelle erhalten,

Informationen zum RS 485 Anschluß
Sie können eine Schnittstelle zum Energiezähler RS485 verwenden, wenn Sie z.B. einen RS485-USBKonverter
(Beispiel TTL-485) und eine Modbus Pol-Software haben.
Sie können alle Register vom Stromzähler inklusive Strom und Strom für eine Phase lesen.
Verbindung mit RS485:
MAPPING DEVICE DATEN
Aufgrund der Beschaffenheit des ModBus-Protokolls sind die Daten in vier Speicherbereiche
unterteilt:
InputRegister (16-Bit-Variablen im Nur-Lese-Modus)
InputStatus (1-Bit-Variablen im Nur-Lese-Modus)
HoldingRegister (16-Bit allgemein nicht-flüchtige Variablen)
CoilStatus (1-Bit-Variablen)
Das Gerät ist kompatibel mit den gängigsten ModBus-Befehlen wie Single und
sequentielles Lesen aller Speicherplätze und einmaliges Schreiben aller Halteregister und
Spulenstatus.
Das Gerät kann als Doppel-Dreiphasen-Energiezähler oder als sechs Einphasen-Energie verwendet
werden Meter. Stichprobendaten werden in zwei Gruppen von InputRegister gruppiert:
1) Adresse 0-88 für sechs einphasigen Betrieb
2) Adresse 100-201 für Doppel-Dreiphasenbetrieb
Der ZR-HM3-EM hat folgende Daten:
(89 + 102) Eingaberegister
3 Eingabestatus
3 HoldingRegister
2 Spulenstatus



InputRegister [120] Phasenspannung L3 B
InputRegister [121] Phasenstrom L1 A
InputRegister [122] Phasenstrom L2 A
InputRegister [123] Phasenstrom L3 A
InputRegister [124] Gesamtphasenstrom A Hi
InputRegister [125] Gesamtphasenstrom A Lo
InputRegister [126] Phasenstrom L1 B
InputRegister [127] Phasenstrom L2 B
InputRegister [128] Phasenstrom L3 B
InputRegister [129] Gesamtphasenstrom B Hi
InputRegister [130] Gesamtphasenstrom B Lo
InputRegister [131] Netzfrequenz
InputRegister [132] Wirkleistung L1 A
InputRegister [133] Wirkleistung L2 A
InputRegister [134] Wirkleistung L3 A
InputRegister [135] Total Wirkleistung A Hi
InputRegister [136] Summe Wirkleistung A Lo
InputRegister [137] Wirkleistung L1 B
InputRegister [138] Wirkleistung L2 B
InputRegister [139] Wirkleistung L3 B
InputRegister [140] Total Wirkleistung B Hi
InputRegister [141] Total Wirkleistung B Lo
InputRegister [142] Blindleistung L1 A
InputRegister [143] Blindleistung L2 A
InputRegister [144] Blindleistung L3 A
InputRegister [145] Total Blindleistung A Hi
InputRegister [146] Total Blindleistung A Lo
InputRegister [147] Blindleistung L1 B
InputRegister [148] Blindleistung L2 B
InputRegister [149] Blindleistung L3 B
InputRegister [150] Gesamtreaktive Leistung B Hi
InputRegister [151] Total Blindleistung B Lo
InputRegister [152] Scheinleistung L1 A
InputRegister [153] Scheinleistung L2 A
InputRegister [154] Scheinleistung L3 A
InputRegister [155] Scheinleistung A Hi
InputRegister [156] Scheinleistung A Lo
InputRegister [157] Scheinleistung L1 B
InputRegister [158] Scheinleistung L2 B
InputRegister [159] Scheinleistung L3 B
InputRegister [160] Gesamte Scheinleistung B Hi
InputRegister [161] Scheinleistung gesamt B Lo
InputRegister [162] Leistungsfaktor L1 A
InputRegister [163] Leistungsfaktor L2 A
InputRegister [164] Leistungsfaktor L3 A
InputRegister [165] Gesamtleistungsfaktor A
InputRegister [166] Leistungsfaktor L1 B
InputRegister [167] Leistungsfaktor L2 B
InputRegister [168] Leistungsfaktor L3 B
InputRegister [169] Gesamtleistungsfaktor B
InputRegister [170] Aktive Energie L1 A Hi
InputRegister [171] Aktive Energie L1 A Lo
InputRegister [172] Aktive Energie L2 A Hi
InputRegister [173] Aktive Energie L2 A Lo
InputRegister [174] Aktive Energie L3 A Hi
InputRegister [175] Aktive Energie L3 A Lo

Nun möchte ich z.B datenpunkt 135 und 140 Auslesen, dazu habe ich folgende Config erstellt:

define ModbusRS485 Modbus /dev/ttyAMA0@9600
define varista ModbusAttr 5 60 RTU
attr varista userattr obj-h135-reading obj-h140-reading
attr varista IODev ModbusRS485
attr varista obj-h135-reading Total Wirkleistung A HI
attr varista obj-h140-reading Total Wirkleistung B HI

kann ich das so machen?


Danke Mfg Mani
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Februar 2018, 21:28:35
Hallo mani,

neben der Zuordnung eines Namens zu einem Objekt sollte man noch den Datentyp als unpack-Code festlegen.
Wenn die Werte Integer ohne Vorzeichen sind, wäre das ein n. Eventuell ist es aber auch ein s>.
Siehe http://perldoc.perl.org/functions/pack.html.

Falls die Werte automatisch alle 60 Sekunden abgefragt werden sollen (60 hast Du ja beim Define angegeben), dann fehlt auch noch ein -poll Attribut.
Oder falls Du die Werte bei Bedarf mit get abfragen möchtest, ein -showGet.

Am besten liest Du Dir einmal die komplette Beschreibung im Wiki durch:
https://wiki.fhem.de/wiki/ModbusAttr

Dann wäre es noch wichtig, dass die Modbus-Adresse des Geräts stimmt. Im Define hast Du 5 angegeben. Viele Geräte stehen per Default erst mal auf 1. Die Seriellen Parameter müssen natürlich auch stimmen (Baudrate, Parität, Stoppbits etc.). Bei RS2232 ist das oft 9600, 8, N, 1.
Bei RS485 mit Modbus ist es oft eine "even" Parity.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mani am 17 Februar 2018, 16:26:03
Hallo @Stefan,

habe die config so angepasst...define ModbusRS485 Modbus /dev/ttyUSB0@9600,8,N,1
define varista ModbusAttr 1 10 RTU
attr varista userattr IODev obj-h135-poll obj-h135-reading obj-h135-unpack obj-h140-poll obj-h140-reading obj-h140-unpack verbose
attr varista IODev ModbusRS485
attr varista obj-h135-poll 1
attr varista obj-h135-reading Total Wirkleistung A HI
attr varista obj-h135-unpack n
attr varista obj-h140-poll 1
attr varista obj-h140-reading Total Wirkleistung B HI
attr varista obj-h140-unpack n
attr varista verbose 5


und das steht im log

2018.02.15 09:00:04 5: Cmd: >attr varista verbose 5<

2018.02.15 09:00:04 5: Cmd: >setstate ModbusRS485 opened<
2018.02.15 09:00:04 5: Cmd: >setstate ModbusRS485 2018-02-15 08:50:19 state opened<

 
2018.02.15 09:00:09 4: varista: update timer modified: will call GetUpdate in 10.0 seconds at 2018-02-15 09:00:19 - Interval 10
2018.02.15 09:00:09 5: varista: GetUpdate called
2018.02.15 09:00:09 5: varista: GetUpdate objects from attributes: h135 h140
2018.02.15 09:00:09 5: varista: GetUpdate full object list: h135 h140
2018.02.15 09:00:09 5: varista: GetUpdate check h135 => Total Wirkleistung A HI, poll = 1, last = 0
2018.02.15 09:00:09 4: varista: GetUpdate will request Total Wirkleistung A HI
2018.02.15 09:00:09 5: varista: GetUpdate check h140 => Total Wirkleistung B HI, poll = 1, last = 0
2018.02.15 09:00:09 4: varista: GetUpdate will request Total Wirkleistung B HI
2018.02.15 09:00:09 5: varista: GetUpdate tries to combine read commands
2018.02.15 09:00:09 5: varista: No Combine Total Wirkleistung A HI / h135 with Total Wirkleistung B HI / h140, span 6 > max 1
2018.02.15 09:00:09 4: varista: Send called with h135, len 1 / span 1 to id 1, op read, qlen 0, value hex 30
2018.02.15 09:00:09 4: varista: Send queues fc 3 to 1, for h135 (Total Wirkleistung A HI), len/span 1, value hex 30
2018.02.15 09:00:09 4: ModbusRS485: HandleSendQueue sends fc 3 to id 1, tid 77 for Total Wirkleistung A HI (h135), len 1, device varista (RTU), pdu 0300870001, V 3.5.12 - 06.01.2017
2018.02.15 09:00:09 5: SW: 0103008700013423
2018.02.15 09:00:09 4: varista: Send called with h140, len 1 / span 1 to id 1, op read, qlen 0, value hex 30
2018.02.15 09:00:09 4: varista: Send queues fc 3 to 1, for h140 (Total Wirkleistung B HI), len/span 1, value hex 30
2018.02.15 09:00:10 5: redefine at command EinTrittDown as +*
2018.02.15 09:00:25 3: ModbusRS485: timeout waiting for fc 3 from id 1, (h140), Request was 0103008c000145e1, Buffer contains
2018.02.15 09:00:25 4: ModbusRS485: HandleSendQueue sends fc 3 to id 1, tid 157 for Total Wirkleistung A HI (h135), len 1, device varista (RTU), pdu 0300870001, V 3.5.12 - 06.01.2017
2018.02.15 09:00:25 5: SW: 0103008700013423
 1 to id 1, op read, qlen 0, value hex 30
2018.02.15 09:01:01 4: varista: Send queues fc 3 to 1, for h140 (Total Wirkleistung B HI), len/span 1, value hex 30
2018.02.15 09:01:01 4: ModbusRS485: HandleSendQueue sends fc 3 to id 1, tid 33 for Total Wirkleistung B HI (h140), len 1, device varista (RTU), pdu 03008c0001, V 3.5.12 - 06.01.2017
2018.02.15 09:01:01 5: SW: 0103008c000145e1
2018.02.15 09:01:01 4: varista: Send called with h135, len 1 / span 1 to id 1, op read, qlen 0, value hex 30
2018.02.15 09:01:01 4: varista: Send queues fc 3 to 1, for h135 (Total Wirkleistung A HI), len/span 1, value hex 30


würdest du sagen das da eine Kommunikation möglich ist?





mfg Mani
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Februar 2018, 22:33:50
Hallo Mani,

Dein Gerät antwortet nicht.
Stimmt die Modbus Id?
Sind die seriellen Parameter korrekt?

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mani am 18 Februar 2018, 09:34:01
Hallo,
Hab ich schon befürchtet.... Weiß die Einstellungen leider nicht werde den Hersteller nochmals kontaktieren.
Danke
Mfg Mani
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: hauwech am 21 Februar 2018, 15:45:41
Hallo an die Experten,

ich versuche mich der Beantwortung meiner Frage hier: https://forum.fhem.de/index.php/topic,84669.0.html (https://forum.fhem.de/index.php/topic,84669.0.html) schrittweise zu nähern.
Ich bin im Bereich Hardware, Arduino usw. nicht so zu Hause.
Kann es sein, daß Modbus für die RS485 Kamera Anbindung an fhem hier mein Freund ist?

Danke und Gruß
Roland
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Februar 2018, 20:25:25
Hallo Roland,

mit Modbus hat das Kommunikationsprotokoll Deiner Kamera leider nichts zu tun.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: hauwech am 23 Februar 2018, 11:41:27
Hallo Stefan,

schade. Der USB-RS485 Adapter schlägt im System als Feb 23 11:21:44 fhem-nuc kernel: [144936.011906] usb 1-2: ch341-uart converter now attached to ttyUSB0

Deswegen dachte ich, daß man mit sowas wie echo <command> > /dev/ttyUSB0 die in der Kamera-Doku beschriebenen Commands hinschicken kann oder eben mit
define ModBusLine Modbus /dev/ttyUSB0@9600 von fhem aus was machen kann und die Kamera empfängt die Daten stumpf und setzt sie im internen RS485 Controller um.

Möglicherweise habe ich aber aus Unkenntnis einfach zu einfach gedacht.

Danke und Gruß
Roland
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 Februar 2018, 14:58:36
Hallo hauwech,

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

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: hauwech am 25 Februar 2018, 13:39:48
Danke für den Tip!

Gruß Roland
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Regmus am 26 Februar 2018, 06:47:10
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)
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:
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:
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 (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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Februar 2018, 14:37:38
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Regmus am 26 Februar 2018, 18:21:45
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: HP am 12 März 2018, 10:14:19
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.

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

In der Wago habe ich folgende Globale Variablen angelegt.
   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


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 März 2018, 18:05:33
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


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Herjemine am 28 März 2018, 22:17:49
Hallo Stefan,

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

Lesen geht nur per get
hier die Config
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
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 März 2018, 11:25:09
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Herjemine am 29 März 2018, 11:51:44
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

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

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Herjemine am 29 März 2018, 13:10:19
Hallo Stefan,

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

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   ;D

Gruß Hermann
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: fhainz am 30 Juni 2018, 22:38:46
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.
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:
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!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 21 August 2018, 23:27:04
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:

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:

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.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 22 August 2018, 12:19:48
dir ist schon klar das immer -1 beim Register genommen wird. Dh. 102 = 101

lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 22 August 2018, 21:39:15
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:

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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 August 2018, 22:56:33
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 23 August 2018, 12:21:41
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.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 23 August 2018, 13:01:09
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?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 August 2018, 18:30:01
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 24 August 2018, 20:50:01
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?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 August 2018, 21:10:07
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 24 August 2018, 21:27:50
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 (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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 August 2018, 23:36:52
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 26 August 2018, 15:30:57
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.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 27 August 2018, 14:30:49
 :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  ;)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 31 August 2018, 18:31:33
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 PoolDer Fehler kommt immer, wenn ich versuche zu schreiben.

Was mache ich falsch?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 31 August 2018, 20:48:59
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.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 31 August 2018, 21:07:58
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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fistandantilus am 31 August 2018, 22:57:31
Perfekt - danke Dir! Den Rest hab ich jetzt beim Hersteller angefragt, da die Doku echt schrecklich ist  :(
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 September 2018, 20:14:09
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|TCPim 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> slaveoder
define <name> ModbusAttr <Id> slave <Address:Port> RTU|ASCII|TCPAdddress 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 TCPsofern 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
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 30 September 2018, 15:23:34
Hallo Stefan,

ich wollte das testen, allerdings verschwinden dann meine bisherigen modbusattr definitionen.
2018.09.30 14:52:29.979 1: define mbSlave10 ModbusAttr 10 0.1: Usage: define <name> ModbusAttr <id> <interval>|slave|relay|passive [host:port] [RTU|ASCII|TCP] [to <relayMasterDevice>]
2018.09.30 14:52:30.478 1: Including /opt/fhem/fhem.save
2018.09.30 14:52:35.604 1: configfile: Usage: define <name> ModbusAttr <id> <interval>|slave|relay|passive [host:port] [RTU|ASCII|TCP] [to <relayMasterDevice>]
/opt/fhem/fhem.save: Please define mbSlave10 first
Please define mbSlave10 first
Please define mbSlave10 first
...
2018.09.30 14:52:35.877 3: Opening RS485 device /dev/ttyS2
2018.09.30 14:52:35.902 3: Setting RS485 serial parameters to 115200,8,N,2
2018.09.30 14:52:35.903 3: RS485 device opened
2018.09.30 14:52:35.903 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 1460.

Müssen die angepasst werden?

Grüße
Marco
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andi291 am 01 Oktober 2018, 12:03:49
Moin!

Ich hatte mir einen eigenen logger geschrieben, den ich nun nicht mehr brauche.
Ich habe zwar noch Probleme beim Umschlüsseln der Register, das liegt aber (denke ich) nicht im Modul.

Zusammenfassend: Positives Feedback, bitte einchecken!

Grüße, Andi
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 Oktober 2018, 12:24:36
Hallo Marco,

danke für's Testen.
Offensichtlich verwendest Du 0.1 als Intervall.
Bei all den Änderungen habe ich offenbar übersehen, dass man bisher auch Bruchteile von Sekunden verwenden konnte.
Der aktuelle Stand akzeptiert nur ganzzahlige Intervalle. Das ändere ich wieder und poste dann heute am Abend oder Morgen eine aktualisierte Version.

Gruss / vielen Dank
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 Oktober 2018, 12:26:00
Hallo Andi,

Auch an Dich vielen Dank fürs Testen!
Ich werde noch ein paar Tage warten, bis mehr Feedback eingetroffen ist, um solche Probleme wie sie von Marco gefunden wurden noch zu beheben.
Dann checke ich es ein :-)

Gruss / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 Oktober 2018, 18:04:01
Hallo,

anbei eine neue Version, in der die Intervalle beim define wieder so funktionieren sollten wie bisher :-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 01 Oktober 2018, 22:04:30
Hallo Stefan,

ich habe die neue Version eingespielt, es kommen aber ständig timeouts.
Die Readings der Slaves werden aktualisiert, also funktionieren tut es wohl.
Ich habe die Pollintervalle und timeouts  auf möglichst kleine werte gesetzt.
Dadurch sind die Slaves fast in Echtzeit abzufragen.
Hat mit dem alten Modul auch gut funktioniert bei knapp 100000 request pro stunde und vielleicht 1 bis 3 timeouts pro Tag.

Gruß
Marco

2018.10.01 21:41:53.517 3: Opening RS485 device /dev/ttyS3
2018.10.01 21:41:53.518 3: Setting RS485 serial parameters to 115200,8,N,2
2018.10.01 21:41:53.518 3: RS485 device opened
2018.10.01 21:41:53.519 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 1461.
2018.10.01 21:41:53.522 3: mbSlave11: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.522 3: mbSlave11: RegisterAtIODev to RS485 with id 11, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.522 3: mbSlave12: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.522 3: mbSlave12: RegisterAtIODev to RS485 with id 12, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.522 3: mbSlave13: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.522 3: mbSlave13: RegisterAtIODev to RS485 with id 13, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.523 3: mbSlave14: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.523 3: mbSlave14: RegisterAtIODev to RS485 with id 14, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.523 3: mbSlave21: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.523 3: mbSlave21: RegisterAtIODev to RS485 with id 21, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.524 3: mbSlave22: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.524 3: mbSlave22: RegisterAtIODev to RS485 with id 22, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.524 3: mbSlave23: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.524 3: mbSlave23: RegisterAtIODev to RS485 with id 23, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.524 3: mbSlave24: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.525 3: mbSlave24: RegisterAtIODev to RS485 with id 24, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.555 0: Featurelevel: 5.8
2018.10.01 21:41:53.556 0: Server started with 75 defined entities (fhem.pl:17329/2018-09-12 perl:5.022001 os:linux user:fhem pid:5878)
2018.10.01 21:41:56.342 3: RS485: Timeout waiting for a modbus response, request: id 14, fCode 3, type h, adr 142, len 7 for device mbSlave14 reading ro-DHT1dewPoint, read buffer empty
2018.10.01 21:41:57.201 3: RS485: Timeout waiting for a modbus response, request: id 11, fCode 3, type h, adr 134, len 8 for device mbSlave11 reading ro-SensorMotion1, read buffer empty
2018.10.01 21:41:58.052 3: RS485: Timeout waiting for a modbus response, request: id 12, fCode 3, type h, adr 135, len 9 for device mbSlave12 reading ro-SensorMotion1, read buffer empty
2018.10.01 21:41:59.138 3: RS485: Timeout waiting for a modbus response, request: id 11, fCode 3, type h, adr 134, len 8 for device mbSlave11 reading ro-SensorMotion1, read buffer empty
2018.10.01 21:41:59.994 3: RS485: Timeout waiting for a modbus response, request: id 12, fCode 3, type h, adr 126, len 7 for device mbSlave12 reading ro-SlaveMaxLooptime, read buffer empty
2018.10.01 21:42:00.867 3: RS485: Timeout waiting for a modbus response, request: id 12, fCode 3, type h, adr 126, len 9 for device mbSlave12 reading ro-SlaveMaxLooptime, read buffer empty
2018.10.01 21:42:02.012 3: RS485: Timeout waiting for a modbus response, request: id 1, fCode 3, type h, adr 125, len 9 for device mbSlave01 reading ro-DoorOpener, read buffer empty
2018.10.01 21:42:02.854 3: RS485: Timeout waiting for a modbus response, request: id 22, fCode 3, type h, adr 137, len 11 for device mbSlave22 reading ro-SensorLight1, read buffer empty
2018.10.01 21:42:03.683 3: RS485: Timeout waiting for a modbus response, request: id 11, fCode 3, type h, adr 126, len 8 for device mbSlave11 reading ro-SlaveMaxLooptime, read buffer empty
2018.10.01 21:42:04.514 3: RS485: Timeout waiting for a modbus response, request: id 12, fCode 3, type h, adr 135, len 9 for device mbSlave12 reading ro-SensorMotion1, read buffer empty
2018.10.01 21:42:05.358 3: RS485: Timeout waiting for a modbus response, request: id 14, fCode 3, type h, adr 126, len 8 for device mbSlave14 reading ro-SlaveMaxLooptime, read buffer empty

mit verbose 5 als Anhang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Oktober 2018, 20:50:24
Hallo Marco,

Dein Log mit verbose 5 beginnt leider erst als der Timeout schon unterwegs ist. Es wäre spannend zu sehen, was davor passiert ist.
Anbei nochmal eine neue Version, die etwas eleganter mit dem Queue-Timer umgehen sollte und weniger überflüssige Dinge protokolliert.
Ich vermute, dass es ein Timing-Problem ist. Deine Anwendung mit Intervall 0.1 und QueueDelay 0 ist schon extrem ;-)
Eventuell ist die neue Version an ein paar Stellen effektiver als die alte und dadurch könnte ein Slave zu schnell abgefragt werden.
Probier doch mal die Delays minimal zu erhöhen, ob das einen Unterschied macht. Falls nicht, könnten wir die Logs der alten mit den Logs der neuen Version vergleichen.

Gruss / vielen Dank
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 04 Oktober 2018, 18:49:46
Hallo Stefan,

ich habe diesmal verbose 5 eingestellt bevor ich fhem neugestartet habe.
Also findest du Einträge mit der alten und der neuen Version.
ich versuche mal die timings hochzuschrauben bis die Fehler weg sind.
Vielleicht gibt das mehr Aufschluss.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 04 Oktober 2018, 19:11:51
ich habe am RS485 Port jetzt mal busDelay (vorher nicht vorhanden) und ClientSwitchDelay (vorher 0.3s) auf 1s
und auf den Slaves dev-timing-sendDelay (vorher 0.015) und dev-timing-commDelay (vorher 0) auf 1s gestellt.
Timeouts bleiben.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 Oktober 2018, 20:40:44
Hallo,

ich glaube da ist ein Bug im delay-Handling. Teilweise gehen die Request 12ms oder sogar nur 5ms nach dem letzten Lesen raus.
Die Delays werden wohl nicht richtig umgesetzt. Das erklärt dann auch die Timeouts.
Ich melde bald mich mit einer neuen Version.

Gruss und vielen Dank
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 Oktober 2018, 22:28:09
Hier eine neue Version, bei der die Delays wieder funktionieren sollten.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 07 Oktober 2018, 16:02:48
Hallo Stefan,

das sieht gut aus, die Timeouts sind weg und es scheint alles zu funktionieren.

Ich habe mich in der Zwischenzeit nochmal näher mit dem Timing auseinandergesetzt.

bei 115200 Baud mit 8N2 = startbit+databits+parity/stopbit+stopbit = 1+8+1+1 = 11 bits per character
1s / 115200 Baud = 8,6805 µs per bit, 11 bit per character = 95,5 µs per character
Modbus Spezifikation Busdelay = min. 3.5 * character time = 335 µs

eine Requestfolge:
Busdelay = 335 µs
Master Request Frame = 8 byte = 8 * char time = 764 µs
Busdelay = 335 µs
Slave Response 25regs = ModbusFrame + HoldingRegs(16bit) = 5+25*2 = 55 characters = 5252,5 µs
Slave Response 11regs = ModbusFrame + HoldingRegs(16bit) = 5+11*2 = 27 characters = 2578,5 µs
Slave Response 10regs = ModbusFrame + HoldingRegs(16bit) = 5+10*2 = 25 characters = 2387,5 µs
Slave Response 9 regs = ModbusFrame + HoldingRegs(16bit) = 5+9 *2 = 23 characters = 2196,5 µs
Slave Response 8 regs = ModbusFrame + HoldingRegs(16bit) = 5+8 *2 = 21 characters = 2005,5 µs
Slave Response 4 regs = ModbusFrame + HoldingRegs(16bit) = 5+4 *2 = 13 characters = 1241,5 µs
Slave Response 1 regs = ModbusFrame + HoldingRegs(16bit) = 5+1 *2 = 7  characters =  668,7 µs

Theoretische Zykluszeit bei 25 Regs = Request + Response = 6,7 ms
Theoretische Zykluszeit bei 11 Regs = Request + Response = 4,0 ms
Theoretische Zykluszeit bei 10 Regs = Request + Response = 3,8 ms
Theoretische Zykluszeit bei  9 Regs = Request + Response = 3,6 ms
Theoretische Zykluszeit bei  8 Regs = Request + Response = 3,4 ms
Theoretische Zykluszeit bei  4 Regs = Request + Response = 2,7 ms
Theoretische Zykluszeit bei  1 Regs = Request + Response = 2,1 ms

Da ich bei meinen Slaves zwischen 8 und 11 Regs pro Request hole, rechne ich mal mit 5 ms.
Daraus schließe ich das folgende Einstellungen laufen sollten.

RS485:
busDelay = 0.001
clientSwitchDelay = 0.01 (nutze ich um den Slaves 10ms Zeit für ihren eigenen Loop zu geben)
queueDelay = 0

Slaves:
dev-h-combine = 8 bis 11
dev-timing-commDelay = 0
dev-timing-sendDelay = 0.005

Bei 9 Slaves mit 1 x 3 Requests und 8 x 2 Requests
= 19 Requests a 5ms + 19 sendDelay a 5ms + 9 x clientSwitchdelay a 10ms + 19 x Busdelay a 1ms
= 299ms Looptime

also mit Reserven geht ein Pollintervall von 0.4s, habe ich jetzt auch so laufen.
Ich hoffe die Timings so richtig interpretiert zu haben, zumindest läuft es so.

Wenn ich noch wünsche äußern dürfte,
- fände ich die Möglichkeit gut wie eine Statemachine kontinuierlich abzuholen anstatt in Intervallen zu pollen.
- ein reading mit dem Füllgrad der Queue
- ein evtl. sogar konfigurierbares retry bei einem Timeout, da es doch manchmal welche gibt, speziell wenn man so hart an der physikalischen grenze fährt wie ich es tue

Ansonsten kann ich mich nur für das Modul bedanken

Grüße
Marco



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Oktober 2018, 18:17:53
Hallo Marco,

das mit dem Reading für die Länge der Queue ist kein Problem. Ebenso eine Möglichkeit für Retries nach Timeouts.
Nur das mit der Statemachine müsstest Du etwas genauer erklären.

Gruss und Danke für's Testen
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 07 Oktober 2018, 20:37:27
Anstatt eine fixe Zeit anzugeben wann gepollt wird, irgend ein anderes Flag.
Wenn gesetzt wird dann kontinuierlich gepollt, sobald alle Slaves mit den passenden Registern durch sind fängt es direkt von vorne wieder an. Evtl. gesetzte polldelay Attribute könnten dann als Faktor eines kompletten Durchlaufs interpretiert werden.
Dann wäre allerdings ein reading schön aus dem die Zeit für einen kompletten Durchlauf ersichtlich ist damit man weis was als polldelay in Frage kommt.
Ein set Befehl könnte direkt zwischen den einzelnen Requests oder nach Beendigung eines kompletten Durchlaufs erfolgen, abhängig vom nonPrioritizedSet Attribut.

Das nur als Gedankenspiel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 10 Oktober 2018, 23:40:21
Hallo Stefan,

hab noch ein Problem gefunden, auf meinem Windows Rechner stürzt der FHEM Prozess ab sobald ich die neue Modbusversion nutze.
Nur wenn das RS485 Device auf disable steht kann ich FHEM starten, mit der alten Version läuft es.

alte version
2018.10.10 23:35:11 1: starting in console mode
2018.10.10 23:35:11 1: Including fhem.cfg
2018.10.10 23:35:11 3: telnetPort: port 7072 opened
2018.10.10 23:35:12 3: WEB: port 8083 opened
2018.10.10 23:35:12 3: WEBphone: port 8084 opened
2018.10.10 23:35:12 3: WEBtablet: port 8085 opened
2018.10.10 23:35:12 2: eventTypes: loaded 184 events from ./log/eventTypes.txt
2018.10.10 23:35:12 3: mbSlave10: defined with id 10, interval 0.1, protocol RTU
2018.10.10 23:35:12 1: PERL WARNING: Use of uninitialized value $L[7] in hex at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:35:12 1: PERL WARNING: Use of uninitialized value $L[0] in concatenation (.) or string at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:35:12 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:35:12 3: mbTest: defined with id 5, interval 1, protocol RTU
2018.10.10 23:35:12 3: mbTest: Support for leading zeros in object addresses enabled. This might slow down the fhem modbus module a bit
2018.10.10 23:35:12 1: Including ./log/fhem.save
2018.10.10 23:35:12 3: RS485: Notify / Init: opening connection
2018.10.10 23:35:12 3: Opening RS485 device COM3
2018.10.10 23:35:12 3: Setting RS485 serial parameters to 115200,8,N,2
2018.10.10 23:35:12 3: RS485 device opened
2018.10.10 23:35:12 3: mbSlave10: Notify / Init: device is disabled
2018.10.10 23:35:12 3: mbTest: Notify / Init: using RS485 for communication
2018.10.10 23:35:12 0: Featurelevel: 5.9
2018.10.10 23:35:12 0: Server started with 12 defined entities (fhem.pl:17488/2018-10-08 perl:5.024002 os:MSWin32 user:qwertz pid:13088)

neue Version
2018.10.10 23:38:46 1: starting in console mode
2018.10.10 23:38:46 1: Including fhem.cfg
2018.10.10 23:38:46 3: telnetPort: port 7072 opened
2018.10.10 23:38:46 3: WEB: port 8083 opened
2018.10.10 23:38:46 3: WEBphone: port 8084 opened
2018.10.10 23:38:46 3: WEBtablet: port 8085 opened
2018.10.10 23:38:46 2: eventTypes: loaded 184 events from ./log/eventTypes.txt
2018.10.10 23:38:46 3: RS485: defined as COM3@115200,8,N,2
2018.10.10 23:38:46 3: mbSlave10: defined with id 10, interval 0.1, protocol default (RTU), mode master
2018.10.10 23:38:46 3: mbSlave10: UnregAtIODev called from ModbusLD_SetIODev
2018.10.10 23:38:46 3: mbSlave10: RegisterAtIODev called from ModbusLD_SetIODev registers mbSlave10 at RS485 with id 10, MODE master, PROTOCOL RTU
2018.10.10 23:38:46 1: PERL WARNING: Use of uninitialized value $L[7] in hex at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:38:46 1: PERL WARNING: Use of uninitialized value $L[0] in concatenation (.) or string at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:38:46 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:38:47 3: mbTest: defined with id 5, interval 10, protocol default (RTU), mode master
2018.10.10 23:38:47 3: mbTest: UnregAtIODev called from ModbusLD_SetIODev
2018.10.10 23:38:47 3: mbTest: RegisterAtIODev called from ModbusLD_SetIODev registers mbTest at RS485 with id 5, MODE master, PROTOCOL RTU
2018.10.10 23:38:47 3: mbTest: attr support for leading zeros in object addresses enabled. This might slow down the fhem modbus module a bit
2018.10.10 23:38:47 1: Including ./log/fhem.save
2018.10.10 23:38:47 4: RS485: Notify / Init: opening connection
2018.10.10 23:38:47 5: RS485: Open called for DevIo connection - closing first
2018.10.10 23:38:47 5: RS485: Close called from Open with noState
2018.10.10 23:38:47 4: RS485: open trying to open connection to COM3@115200,8,N,2
2018.10.10 23:38:47 3: Opening RS485 device COM3
2018.10.10 23:38:47 3: Setting RS485 serial parameters to 115200,8,N,2
2018.10.10 23:38:47 3: RS485 device opened
2018.10.10 23:38:47 3: mbSlave10: Notify / Init: device is disabled
2018.10.10 23:38:47 3: mbTest: UnregAtIODev called from Notify
2018.10.10 23:38:47 3: mbTest: Notify / Init: using RS485 for communication
2018.10.10 23:38:47 3: mbTest: RegisterAtIODev called from Notify registers mbTest at RS485 with id 5, MODE master, PROTOCOL RTU
2018.10.10 23:38:47 0: Featurelevel: 5.9
2018.10.10 23:38:47 0: Server started with 12 defined entities (fhem.pl:17488/2018-10-08 perl:5.024002 os:MSWin32 user:qwertz pid:5896)
2018.10.10 23:38:48 5: RS485: Profiling Fhem initialized, start 1539207528.21466
2018.10.10 23:38:48 5: RS485: QueueRequest called from ModbusLD_DoRequest with h003, qlen 0
2018.10.10 23:38:48 5: RS485: ProcessRequestQueue called from QueueRequest as direct:RS485
2018.10.10 23:38:48 5: RS485: Open called for DevIo connection - closing first
2018.10.10 23:38:48 5: RS485: Close called from Open with noState
2018.10.10 23:38:48 4: RS485: open trying to open connection to COM3@115200,8,N,2
2018.10.10 23:38:48 3: Opening RS485 device COM3
Zugriff verweigert

2018.10.10 23:38:48 1: PERL WARNING: can't open device: \\.\COM3
 at ./FHEM/DevIo.pm line 414.
2018.10.10 23:38:48 1: RS485: Can't open COM3:
2018.10.10 23:38:48 5: RS485: Profiling Idle, before Fhem, now is 1539207528.22875, Idle started at 1539207528.22875, Fhem started at 1539207528.21466
2018.10.10 23:38:48 5: RS485: Profiling add 0.0140969753265381 to sum for Fhem (now is 1539207528.22875, start for Fhem was 1539207528.21466)
Can't use an undefined value as an ARRAY reference at ./FHEM/98_Modbus.pm line 3077.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Oktober 2018, 21:06:04
Hallo,

hier nochmal eine neue Version.
Der Absturz wenn disable gesetzt ist sollte weg sein.
Zusätzlich gibt es die Attribute retriesAfterTimeout (gilt nur für den update-Zyklus, nicht für get/set)
und enableQueueLengthReading.

Beim Parsen / den expr-Attributen hat sich auch etwas geändert: der Wert steht nun nicht mehr nur als $val sondern auch als @val zur Verfügung. @val enthält mehrere Werte falls der unpack-Code mehrere Listenelemente erzeugt (z.B. 'ss'), was sinnvoll sein kann, wenn man mit einem Request zwei Register als ein Objekt lesen möchte und diese dann in der expr wieder zerlegen und danach zusammenrechnen möchte.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 16 Oktober 2018, 00:48:54
Hallo Stefan,

wie kann ich diese Register auslesen ? siehe auch hier (https://forum.fhem.de/index.php/topic,80767.msg846354.html#msg846354).
Wie komme ich zum String. unpack/pack irgendwas ?!

scan-h00004  => SolarEdge
scan-h00020  => SE5K
scan-h00044 ...
scan-h00052 ...

2018-10-16 00:39:07   scan-h00001     hex=6e53, string=nS, s=21358, s>=28243, S=21358, S>=28243
     2018-10-16 00:39:07   scan-h00002     hex=0001, string=.., s=256, s>=1, S=256, S>=1
     2018-10-16 00:39:07   scan-h00003     hex=0041, string=.A, s=16640, s>=65, S=16640, S>=65
     2018-10-16 00:39:07   scan-h00004     hex=536f, string=So, s=28499, s>=21359, S=28499, S>=21359
     2018-10-16 00:39:07   scan-h00005     hex=6c61, string=la, s=24940, s>=27745, S=24940, S>=27745
     2018-10-16 00:39:07   scan-h00006     hex=7245, string=rE, s=17778, s>=29253, S=17778, S>=29253
     2018-10-16 00:39:07   scan-h00007     hex=6467, string=dg, s=26468, s>=25703, S=26468, S>=25703
     2018-10-16 00:39:07   scan-h00008     hex=6520, string=e., s=8293, s>=25888, S=8293, S>=25888
     2018-10-16 00:39:07   scan-h00009     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00010     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00011     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00012     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00013     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00014     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00015     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00016     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00017     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00018     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00019     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00020     hex=5345, string=SE, s=17747, s>=21317, S=17747, S>=21317
     2018-10-16 00:39:07   scan-h00021     hex=354b, string=5K, s=19253, s>=13643, S=19253, S>=13643
     2018-10-16 00:39:07   scan-h00022     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00023     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00024     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00025     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00026     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00027     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00028     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00029     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00030     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00031     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00032     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00033     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00034     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00035     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00036     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00037     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00038     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00039     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00040     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00041     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00042     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00043     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00044     hex=3030, string=00, s=12336, s>=12336, S=12336, S>=12336
     2018-10-16 00:39:07   scan-h00045     hex=3032, string=02, s=12848, s>=12338, S=12848, S>=12338
     2018-10-16 00:39:07   scan-h00046     hex=2e31, string=.1, s=12590, s>=11825, S=12590, S>=11825
     2018-10-16 00:39:07   scan-h00047     hex=3035, string=05, s=13616, s>=12341, S=13616, S>=12341
     2018-10-16 00:39:07   scan-h00048     hex=3300, string=3., s=51, s>=13056, S=51, S>=13056
     2018-10-16 00:39:07   scan-h00049     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:07   scan-h00050     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00051     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00052     hex=3745, string=7E, s=17719, s>=14149, S=17719, S>=14149
     2018-10-16 00:39:00   scan-h00053     hex=3138, string=18, s=14385, s>=12600, S=14385, S>=12600
     2018-10-16 00:39:00   scan-h00054     hex=3230, string=20, s=12338, s>=12848, S=12338, S>=12848
     2018-10-16 00:39:00   scan-h00055     hex=4541, string=EA, s=16709, s>=17729, S=16709, S>=17729
     2018-10-16 00:39:00   scan-h00056     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00057     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00058     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00059     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00060     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00061     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00062     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00063     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00064     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00065     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00066     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00067     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00068     hex=0003, string=.., s=768, s>=3, S=768, S>=3
     2018-10-16 00:39:00   scan-h00069     hex=0067, string=.g, s=26368, s>=103, S=26368, S>=103
     2018-10-16 00:39:00   scan-h00070     hex=0032, string=.2, s=12800, s>=50, S=12800, S>=50
     2018-10-16 00:39:00   scan-h00071     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00072     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00073     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00074     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00075     hex=fffe, string=.., s=-257, s>=-2, S=65279, S>=65534
     2018-10-16 00:39:00   scan-h00076     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00077     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00078     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00079     hex=00ec, string=.., s=-5120, s>=236, S=60416, S>=236
     2018-10-16 00:39:00   scan-h00080     hex=00ed, string=.., s=-4864, s>=237, S=60672, S>=237
     2018-10-16 00:39:00   scan-h00081     hex=00ec, string=.., s=-5120, s>=236, S=60416, S>=236
     2018-10-16 00:39:00   scan-h00082     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00083     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00084     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00085     hex=138a, string=.., s=-30189, s>=5002, S=35347, S>=5002
     2018-10-16 00:39:00   scan-h00086     hex=fffe, string=.., s=-257, s>=-2, S=65279, S>=65534
     2018-10-16 00:39:00   scan-h00087     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00088     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00089     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00090     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00091     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00092     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00093     hex=0112, string=.., s=4609, s>=274, S=4609, S>=274
     2018-10-16 00:39:00   scan-h00094     hex=0408, string=.., s=2052, s>=1032, S=2052, S>=1032
     2018-10-16 00:39:00   scan-h00095     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00096     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:00   scan-h00097     hex=8000, string=.., s=128, s>=-32768, S=128, S>=32768
     2018-10-16 00:39:00   scan-h00098     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00099     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:00   scan-h00100     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:06   scan-h00101     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:06   scan-h00102     hex=8000, string=.., s=128, s>=-32768, S=128, S>=32768
     2018-10-16 00:39:06   scan-h00103     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:06   scan-h00104     hex=8000, string=.., s=128, s>=-32768, S=128, S>=32768
     2018-10-16 00:39:06   scan-h00105     hex=8000, string=.., s=128, s>=-32768, S=128, S>=32768
     2018-10-16 00:39:06   scan-h00106     hex=fffe, string=.., s=-257, s>=-2, S=65279, S>=65534
     2018-10-16 00:39:06   scan-h00107     hex=0002, string=.., s=512, s>=2, S=512, S>=2
     2018-10-16 00:39:06   scan-h00108     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:39:06   scan-h00109     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00110     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00111     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00112     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00113     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00114     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00115     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00116     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00117     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:06   scan-h00118     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:12   scan-h00119     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:14   scan-h00120     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:16   scan-h00121     hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
     2018-10-16 00:39:19   scan-h00122     hex=0000, string=.., s=0, s>=0, S=0, S>=0
     2018-10-16 00:30:00   scanId-3-Response-h100 0

Vielen Dank.
Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Oktober 2018, 22:18:42
Hallo Jörg,

Um Strings aus mehreren Registern auszulesen bietet sich der Unpack-Code a* an.
Als Länge gibst Du die Anzahl der Register an.
Bei Bedarf decode/encode, aber Umlaute sind in Deinem Beispiel vermutlich kein Thema.
Eine Expression, in der nur $val drinsteht ist übrigens völlig ünerflüsssig.

Ergänzung: ich würde je auch noch die Register, zu denen es einen Scale-Faktor im darauf folgenden Register gibt, in einem gemeinsamen Reading lesen, wie ich es im SolarEdge-Thread geschrieben habe.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Benni am 18 Oktober 2018, 04:57:26
wie kann ich diese Register auslesen ? siehe auch hier (https://forum.fhem.de/index.php/topic,80767.msg846354.html#msg846354).
Wie komme ich zum String. unpack/pack irgendwas ?!

scan-h00004  => SolarEdge
scan-h00020  => SE5K
scan-h00044 ...
scan-h00052 ...

Guckst du auch hier: https://wiki.fhem.de/wiki/SolarEdge_SE10k#SunSpec_.28SolarEdge.29  ;)

gb#
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 18 Oktober 2018, 07:17:33
Hallo,

Das mit dem (a4) .... (a16) habe ich ja versucht aber leider ohne Ergebnis werde es aber bei Gelegenheit noch einmal probieren.

Beim register h0000 benutzt ich (a4) dabei wird der String rückwärts dargestellt.->nSSu richtig ist: SunS

Pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 Oktober 2018, 10:39:57
Hallo,

für solche Fälle ist revRegs da :-)
Damit wird die Reihenfolge der Register umgedreht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 21 Oktober 2018, 11:09:30
Hallo Stefan,

vielen Dank. aber ich stehe trotzem noch auf dem Schlauch. Wie rufe ich es auf ?  (4a) ?

Mit dem saveAsModule hat geklappt. Da muss ich nur noch etwas anpassen.

Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 Oktober 2018, 12:19:02
Hallo,

ich habe bei meiner Wärmepumpe für mehrere Strings einen Datentyp definiert und die Konfiguration dadurch vereinfacht:

attr WP dev-type-VT_String-decode cp850
attr WP dev-type-VT_String-encode utf8
attr WP dev-type-VT_String-expr $val =~ s/[\00]+//gr
attr WP dev-type-VT_String-len 8
attr WP dev-type-VT_String-revRegs 0
attr WP dev-type-VT_String-unpack a*

definiert den Typ VT_String mit Länge 8 (bei Dir wäre das 2), setzt a* (wirklich mit Stern) als unpack-Code, Konvertierung der Sonderzeichen (bei Dir vermutlich unnötig). revRegs 0 (wenn die Reihenfolge der Register umgedreht werden soll, dann auf 1 setzen) und eine Expr um 0-Bytes am Ende des Strings zu entfernen.

für das jeweilige Objekt reicht dann ein

attr WP obj-h4689-reading FirmwareVersion
attr WP obj-h4689-type VT_String

attr WP obj-h4817-reading FirmwareDate
attr WP obj-h4817-type VT_String

Die Alternative ist es ohne Datentyp direkt zu konfigurieren, dann muss man das allerdings bei jedem Objekt einzeln angeben:
attr SP obj-h40000-reading C_SunSpec_ID
attr SP obj-h40000-len 4
attr SP obj-h40000-unpack a4

bei Bedarf noch

attr SP obj-h40000-revRegs 1

das a4 oder a* kann man in Klammern setzen, muss man aber nicht.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 21 Oktober 2018, 18:14:37
Hallo Stefan,

vielen Dank, hat geklappt.
Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Oktober 2018, 13:00:19
Hier nochmal ein kleines Update mit Bugfix.
Wenn die Verbindung verloren wurde, wird auch der update-Timer gestoppt. In der vorigen Version ist er dann beim reconnect nicht mehr gestartet worden. Das ist jetzt behoben.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: kingmathers am 26 Oktober 2018, 13:44:14
Vielen Dank fürs Update! Habe es eingespielt und werde berichten, ob die Verbindungsabbrüche damit weiterhin auftreten.

Edit: Habe jetzt seit 2 Tagen keine Probleme mehr.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 27 Oktober 2018, 11:14:03
Hallo,

ich habe eine Heizung, welche ModbusTCP Master kann.

Aktuell habe ich das ModbusTCP-CC Modul im Einsatz. Funktioniert. Würde aber gern umstellen auf ModbusAttr.

Definition mit ModbusTCP_CC

Zitat
define ModbusTCP_Server ModbusTCP_CC 1502
attr ModbusTCP_Server alias ModbusTCP Server
attr ModbusTCP_Server group IO Devices

define ModbusTCP_10_40001 dummy
attr ModbusTCP_10_40001 alias ModbusTCP_10_40001 - Wohnzimmer Temp Soll
attr ModbusTCP_10_40001 comment MBR:10,1,H
attr ModbusTCP_10_40001 group ModbusTCP - Device 10 - Holding Registers

define ModbusTCP_10_40002 dummy
attr ModbusTCP_10_40002 alias ModbusTCP_10_40002 - Wohnzimmer Temp Ist
attr ModbusTCP_10_40002 comment MBR:10,2,H
attr ModbusTCP_10_40002 group ModbusTCP - Device 10 - Holding Registers

Das funktioniert.

Config mit ModbusAttr V1

Zitat
define MB_Heizung  ModbusAttr 10 slave global:1505 TCP

attr MB_Heizung room Heizanlage Modbus Neu

attr MB_Heizung obj-h40001-reading MY_40001
attr MB_Heizung obj-h40002-reading MY_40002

Config mit ModbusAttr V2

Zitat
define MB_Heizung  ModbusAttr 10 slave global:1502 TCP

attr MB_Heizung room Heizanlage Modbus Neu

attr MB_Heizung obj-h1-reading MY_40001
attr MB_Heizung obj-h2-reading MY_40002

Wenn ich mit dem Radzio Modusbus Simulator auf die alte Implementation verbinde... alles okay.
Wenn ich auf die neue Implemation verbinde... Error... egal ob v1 oder v2
An den Ports liegt es nicht... habe mal testweise getauscht. Slave ID habe ich auch mehrere ausprobiert

Hab ich nen Blackout? Muss ich noch was anderes konfigurieren, dass zumindest mal der Connect funktioniert?


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 Oktober 2018, 21:47:00
Hallo  predi-ger-many,

bitte setze doch mal verbose auf 5 und poste den Auszug aus dem Log vom Beginn des Requests bis zum Fehler, damit ich sehen kann, was genau passiert / was für ein Fehler in welchem Zustand auftritt.

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 31 Oktober 2018, 19:37:30
Zitat
attr global verbose 5

define MB_SLAVE_51 ModbusAttr 51 slave global:1551 TCP
attr MB_SLAVE_51 room Heizanlage Modbus Neu
attr MB_SLAVE_51 obj-h1-reading MY_51_1
attr MB_SLAVE_51 obj-h2-reading MY_51_2
define MB_SLAVE_51_FileLog FileLog ./log/MB_SLAVE_51-%Y.log MB_SLAVE_51

define MB_SLAVE_52 ModbusAttr 52 slave global:1552 TCP
attr MB_SLAVE_52 room Heizanlage Modbus Neu
attr MB_SLAVE_52 obj-h40001-reading MY_52_1
attr MB_SLAVE_52 obj-h40002-reading MY_52_2
define MB_SLAVE_52_FileLog FileLog ./log/MB_SLAVE_52-%Y.log MB_SLAVE_52

... zwei Slaves, da ich nicht weiß, ob obj-h1 oder obj-h40001 richtig ist.

Die Logs...

Zitat
2018-10-31_19:28:03 MB_SLAVE_51 opened

Zitat
2018-10-31_19:28:03 MB_SLAVE_52 opened

Der Radzio Simulator sagt immer Timeout. Kein Connect. Ich würde sagen, dass der Slave gar nicht gestartet wird.

Gleiches Ergebnis, wenn ich global:port durch IP:port ersetze

FHEM Log
Zitat
2018.10.31 19:40:19 4: Connection accepted from MB_SLAVE_51_192.168.1.224_51688
2018.10.31 19:40:19 4: MB_SLAVE_51: HandleServerConnection accepted new TCP connection as device MB_SLAVE_51_192.168.1.224_51688
2018.10.31 19:40:19 5: Starting notify loop for global, 1 event(s), first is DEFINED MB_SLAVE_51_192.168.1.224_51688
2018.10.31 19:40:19 5: End notify loop for global
2018.10.31 19:40:19 5: Starting notify loop for global, 1 event(s), first is ATTR MB_SLAVE_51_192.168.1.224_51688 room Connections
2018.10.31 19:40:19 5: End notify loop for global
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: read buffer: 000000000006330300000002
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: ParseFrameStart (TCP) extracted id 51, fCode 3, dlen 6 and data 00000002
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: HandleRequest called from Read
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: ParseRequest called from HandleRequest
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: HandleRequest, request: id 51, fCode 3, type h, len 2, Current read buffer: 000000000006330300000002, Id 51, fCode 3
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: CreateResponse called from HandleRequest
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj called from CreateResponse with h 0 and valuesLen 2
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj doesn't have reading or expr information for h0
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj packed 0 with pack code n to 0000
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj padded / cut object to 0000
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj moves to next object, skip 1 to h1, counter=1
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj ObjInfo for h1: reading=MY_51_1, expr=, format=, len=1, map=, unpack=n
2018.10.31 19:40:19 4: MB_SLAVE_51_192.168.1.224_51688: PackObj for h1 is using reading MY_51_1 of device MB_SLAVE_51_192.168.1.224_51688 with value
2018.10.31 19:40:19 1: PERL WARNING: Argument "" isn't numeric in pack at ./FHEM/98_Modbus.pm line 3256.
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj packed  with pack code n to 0000
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj padded / cut object to 0000
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj counter reached 2
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj full data string is 00000000
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackObj padded / cut data to 00000000
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: prepare response pdu
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: PackFrame called from CreateResponse id 51, pdu 8302
2018.10.31 19:40:19 1: PERL WARNING: Use of uninitialized value $tid in pack at ./FHEM/98_Modbus.pm line 3395.
2018.10.31 19:40:19 4: MB_SLAVE_51_192.168.1.224_51688: CreateResponse sends fc 3 to id 51, for h 0, len 2, device MB_SLAVE_51_192.168.1.224_51688 (TCP), pdu 8302, V 4.0.13 - 26.10.2018
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: Send 000000000003338302
2018.10.31 19:40:19 4: MB_SLAVE_51_192.168.1.224_51688: RequestDone, request: id 51, fCode 3, type h, len 2 for device MB_SLAVE_51_192.168.1.224_51688, Current read buffer: 000000000006330300000002, Id 51, fCode 3, response: id 51, fCode 3, type h, len 2, value 00000000
2018.10.31 19:40:19 5: MB_SLAVE_51_192.168.1.224_51688: DropFrame - drop 000000000006330300000002

98_Modbus.pm und 98_Modbus.pm die letzten Versionen hier aus dem Thread
 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 November 2018, 21:38:29
Hallo,

Im Log sieht man, dass ein function code 3 Request für id 51, holding register 0 mit Länge 2 eingeht.
Da für Regster 0 kein Objekt definiert ist, nur für Register 1, erzeugt das Modul eine Error-Response mit Fehlercode 2. (PDU 8302).

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: andy1986 am 02 November 2018, 13:53:15
Hallo Zusammen,

ich will meine Daten der THZ über Modbus bereitstellen, scheitere aber schon daran den Slave in FHEM zu konfigurieren.
Bei mir kommt nach dem Befehl:
define Data4PLC ModbusAttr 5 60 192.168.178.128:502 TCP

immer der Status disconnected.
Was mache ich falsch?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 02 November 2018, 20:57:53
Hallo Stefan,

ich versuche gerade einen 32bit Wert über 2 Register zu lesen und zu schreiben, scheitere aber am schreiben.
Laut Perl Doku wäre der unpack Code N da alles als Big Endian vorliegt.
Ich habe einen Typ erstellt und den Registern zugewiesen.
attr mbSlave01 dev-type-CountInWh-unpack N
attr mbSlave01 dev-type-CountInWh-len 2

attr mbSlave01 obj-h191-reading S0Counter01
attr mbSlave01 obj-h191-showGet 1
attr mbSlave01 obj-h191-set 1
attr mbSlave01 obj-h191-type CountInWh

Das lesen funktioniert auch korrekt, aber wenn ich einen Wert setzen möchte, bekomme ich folgende Fehlermeldung.
mbSlave01: ParseObj unpack of 0000 with N for S0Counter01 resulted in undefined value

muss da noch ein pack code rein oder passiert das automatisch?

Grüße
Marco
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 November 2018, 11:16:22
Hallo andy1986,

wenn es mal nicht klappt, solltest Du als erstes das Attribut verbose auf 5 setzen, dann den fraglichen Befehl ausführen und ins Fhem-Log schauen.
Dort findest Du vermutlich eine Meldung mit "permission denied". Port 502 kann man nur mit root-Rechten öffnen. Ein Trick, wie man es auch ohne root-Rechte hinbekommt, besteht darin, iptables zu nutzen und Port 502 auf z.B. Port 1502 umzuleiten.
@predi-ger-many: Du hattest Doch eine konkrete Anleitung dafür. Könntest Du die hier posten?

Falls es daran nicht liegt, einfach einen großen Auszug aus dem Log hier posten, dann können andere helfen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 November 2018, 13:58:58
Hallo Marco,

Irgendwie sind bei Dir Master- und Slave-Definitionen durcheinander geraten.
Da Dein Device mbSlave01 heißt, vermute ich, dass es ein Slave sein soll.
Der soll dann ja Requests von einem Master empfangen und entweder Daten von Fhem an den Master liefern oder aber Werte, die der Master schreiben möchte, in eigene Readings schreiben.

showGet ist aber ein Attribut, das nur bei einem Master funktioniert.
Ebenso set.
Bei einem Slave muss man explizit erlauben, dass ein Master Werte schreiben darf. Dafür ist das Attribut allowWrite gedacht.

Unabhängig davon habe ich aber auch noch Fehler im Modul gefunden und behoben.
Anbei eine neue Version.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 03 November 2018, 16:20:30
Hallo Stefan,

was da jetzt durcheinander geraten ist verstehe ich nicht.
FHEM ist der Master und meine zu steuernden Geräte am Bus sind Slaves.
Per FHEM get kann ich holdingregs von den Slaves abholen und in ein Reading packen.
Per FHEM set kann ich werte zu den Slaves schicken.
Beim get funktioniert das auch wenn der Wert über mehrere Register verteilt ist, in Abhängigkeit vom -unpack Attribut.
Beim set funktioniert das in meinem Fall nicht, und das hat, glaube ich, nichts mit Master/Slave Problematik zu tun.
Aus der Doku meine ich verstanden zu haben das durchs -unpack attribut entsprechend ein pack oder unpack stattfindet, je nach Richtung. Was ja sinn macht, wenn der Slave mir ein 32bit Wert über 2 Regs liefert und ich den zurücksenden möchte muss das ja wieder mit dem gleichen Verfahren in beide Regs geschrieben werden.

Vielleicht sehe ich aber den Wald vor lauter Bäumen nicht
Grüße Marco

p.s. dein letzter upload hat 0 bytes

Eine Definition aus meiner Testumgebung
Internals:
   CFGFN     
   CHANGED   
   DEF        1 0.8
   INTERVAL   0.8
   IODev      RS485
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.0.12 - 13.10.2018
   NAME       mbSlave01
   NOTIFYDEV  global
   NR         1289
   NTFY_ORDER 50-mbSlave01
   PROTOCOL   RTU
   STATE      Laufzeit: 000:00:52
   TRIGGERTIME 1541257917.71435
   TRIGGERTIME_FMT 2018-11-03 16:11:57
   TYPE       ModbusAttr
   FRAME:
   READ:
   READINGS:
     2018-11-03 15:17:21   Config-ResetKnownConfig 999
     2018-11-03 15:25:30   Config-WatchdogCountdown 10
     2018-11-03 15:29:00   Logic-ExternalWatchdog 10
     2018-11-03 15:44:15   ro-Counter01    0
     2018-11-03 15:44:15   ro-Counter02    0
     2018-11-03 15:44:16   ro-Counter03    0
     2018-11-03 15:44:16   ro-Counter04    0
     2018-11-03 15:44:19   ro-Counter05    0
     2018-11-03 15:44:19   ro-Counter06    0
     2018-11-03 15:44:18   ro-Counter07    0
     2018-11-03 15:44:18   ro-Counter08    0
     2018-11-03 15:44:18   ro-Counter09    0
     2018-11-03 11:44:12   ro-DHT1dewPoint 0.0
     2018-11-03 11:44:11   ro-DHT1humidity 0
     2018-11-03 11:44:11   ro-DHT1temperature 0.0
     2018-11-03 11:44:09   ro-DoorOpener   0
     2018-11-03 16:11:55   ro-SensorLight1 441
     2018-11-03 11:44:09   ro-SensorMotion1 0
     2018-11-03 11:44:10   ro-SensorSmoke1 0
     2018-11-03 15:17:31   ro-SlaveReset   0
     2018-11-03 16:11:16   ro-Uptime       000:00:52
     2018-11-03 16:11:53   ro-VoltageCurrent 10.9 V
     2018-11-03 16:11:02   ro-WatchdogCountdown 10
     2018-11-03 11:43:55   state           opened
   REMEMBER:
     lrecv      1541257916.61813
     lsend      1541257916.94964
   gotReadings:
     ro-Counter07 0
     ro-Counter08 0
     ro-Counter09 0
   lastRead:
     h117       1541257861.08895
     h126       1541257915.6328
     h127       1541257915.63563
     h129       1541257915.63733
     h130       1541257915.6389
     h131       1541257915.64043
     h132       1541257915.64197
     h133       1541257915.64351
     h134       1541257915.68476
     h135       1541257915.68753
     h136       1541257915.68916
     h137       1541257915.69149
     h138       1541257915.69342
     h140       1541257915.69525
     h142       1541257916.6001
     h144       1541257916.602
     h146       1541257916.60382
     h148       1541257915.61529
     h150       1541257916.62142
     h152       1541257916.62331
     h154       1541257916.62512
     h159       1541254641.93419
Attributes:
   IODev      RS485
   dev-h-combine 8
   dev-timing-commDelay 0.001
   dev-timing-sendDelay 0.001
   dev-timing-timeout 0.5
   dev-type-CountInWh-len 2
   dev-type-CountInWh-unpack N
   dev-type-ProgVersion-expr my $v=int($val / 1000);my $s=int(($val - $v * 1000)/100);my $r=int($val %100); return $v.".".$s.".".$r;
   dev-type-TempInK-expr if ($val != 0 && $val != 27315) {$val / 100 - 273.15;}
   dev-type-TempInK-format %.1f
   dev-type-UpTime-expr my $m = sprintf('%02d',(int($val /60 % 60)));my $h = sprintf('%02d',(int($val /60 /60) % 24));my $d = sprintf('%03d',(int($val /60 /60 /24)));return $d .":".$h.":".$m;
   dev-type-UpTime-len 2
   dev-type-UpTime-unpack N
   dev-type-Voltage-expr $val/10
   dev-type-Voltage-format %.1f V
   disable    0
   event-min-interval ro-Counter..:1800
   event-on-change-reading .*
   group      ComSlaves
   nonPrioritizedGet 1
   nonPrioritizedSet 1
   obj-h0-reading Statistic-Ports-DigitalIn
   obj-h0-showGet 1
   obj-h1-reading State-S0Counter01
   obj-h1-showGet 1
   obj-h10-reading State-SensorMotion1
   obj-h10-showGet 1
   obj-h11-reading State-SensorSmoke1
   obj-h11-showGet 1
   obj-h111-reading Logic-DHT1Temperature
   obj-h111-set 1
   obj-h111-showGet 1
   obj-h112-reading Logic-DHT1Humidity
   obj-h112-set 1
   obj-h112-showGet 1
   obj-h113-reading Logic-DHT1DewPoint
   obj-h113-set 1
   obj-h113-showGet 1
   obj-h117-hint 0,5,10
   obj-h117-reading Logic-ExternalWatchdog
   obj-h117-set 1
   obj-h117-showGet 1
   obj-h126-poll 1
   obj-h126-reading ro-VoltageCurrent
   obj-h126-showGet 1
   obj-h126-type Voltage
   obj-h127-poll 1
   obj-h127-reading ro-Uptime
   obj-h127-showGet 1
   obj-h127-type UpTime
   obj-h128-poll 1
   obj-h129-poll 1
   obj-h129-reading ro-SlaveReset
   obj-h129-showGet 1
   obj-h130-poll 1
   obj-h130-reading ro-DoorOpener
   obj-h130-showGet 1
   obj-h131-poll 1
   obj-h131-reading ro-WatchdogCountdown
   obj-h131-showGet 1
   obj-h132-poll 1
   obj-h132-reading ro-SensorMotion1
   obj-h132-showGet 1
   obj-h133-poll 1
   obj-h133-reading ro-SensorSmoke1
   obj-h133-showGet 1
   obj-h134-poll 1
   obj-h134-reading ro-SensorLight1
   obj-h134-showGet 1
   obj-h135-poll 1
   obj-h135-reading ro-DHT1temperature
   obj-h135-showGet 1
   obj-h135-type TempInK
   obj-h136-poll 1
   obj-h136-reading ro-DHT1humidity
   obj-h136-showGet 1
   obj-h137-poll 1
   obj-h137-reading ro-DHT1dewPoint
   obj-h137-showGet 1
   obj-h137-type TempInK
   obj-h138-poll 1
   obj-h138-reading ro-Counter01
   obj-h138-showGet 1
   obj-h138-type CountInWh
   obj-h140-poll 1
   obj-h140-reading ro-Counter02
   obj-h140-showGet 1
   obj-h140-type CountInWh
   obj-h142-poll 1
   obj-h142-reading ro-Counter03
   obj-h142-showGet 1
   obj-h142-type CountInWh
   obj-h144-poll 1
   obj-h144-reading ro-Counter04
   obj-h144-showGet 1
   obj-h144-type CountInWh
   obj-h146-poll 1
   obj-h146-reading ro-Counter05
   obj-h146-showGet 1
   obj-h146-type CountInWh
   obj-h148-poll 1
   obj-h148-reading ro-Counter06
   obj-h148-showGet 1
   obj-h148-type CountInWh
   obj-h150-poll 1
   obj-h150-reading ro-Counter07
   obj-h150-showGet 1
   obj-h150-type CountInWh
   obj-h152-poll 1
   obj-h152-reading ro-Counter08
   obj-h152-showGet 1
   obj-h152-type CountInWh
   obj-h154-poll 1
   obj-h154-reading ro-Counter09
   obj-h154-showGet 1
   obj-h154-type CountInWh
   obj-h158-reading Config-VoltageFactor
   obj-h158-set 1
   obj-h158-showGet 1
   obj-h159-hint 0,1,999
   obj-h159-reading Config-ResetKnownConfig
   obj-h159-set 1
   obj-h159-showGet 1
   obj-h160-reading Config-DigitalInputDebounceInterval
   obj-h160-set 1
   obj-h160-showGet 1
   obj-h161-reading Config-DigitalInputAnalogLevel
   obj-h161-set 1
   obj-h161-showGet 1
   obj-h167-reading Config-DHT1PollInterval
   obj-h167-set 1
   obj-h167-showGet 1
   obj-h169-reading Config-PowerOutlet1AutoOff
   obj-h169-set 1
   obj-h169-showGet 1
   obj-h17-reading State-SensorVoltage1
   obj-h17-showGet 1
   obj-h170-reading Config-PowerOutlet2AutoOff
   obj-h170-set 1
   obj-h170-showGet 1
   obj-h171-reading Config-AnalogInputPollInterval
   obj-h171-set 1
   obj-h171-showGet 1
   obj-h172-reading Config-NightLight1
   obj-h172-set 1
   obj-h172-showGet 1
   obj-h173-reading Config-StateLED1
   obj-h173-set 1
   obj-h173-showGet 1
   obj-h176-hint 1,10,75,100,1000,2000
   obj-h176-reading Config-S0CounterDivisor01
   obj-h176-set 1
   obj-h176-showGet 1
   obj-h177-hint 1,10,75,100,1000,2000
   obj-h177-reading Config-S0CounterDivisor02
   obj-h177-set 1
   obj-h177-showGet 1
   obj-h178-hint 1,10,75,100,1000,2000
   obj-h178-reading Config-S0CounterDivisor03
   obj-h178-set 1
   obj-h178-showGet 1
   obj-h179-hint 1,10,75,100,1000,2000
   obj-h179-reading Config-S0CounterDivisor04
   obj-h179-set 1
   obj-h179-showGet 1
   obj-h18-reading State-SensorLight1
   obj-h18-showGet 1
   obj-h180-hint 1,10,75,100,1000,2000
   obj-h180-reading Config-S0CounterDivisor05
   obj-h180-set 1
   obj-h180-showGet 1
   obj-h181-hint 1,10,75,100,1000,2000
   obj-h181-reading Config-S0CounterDivisor06
   obj-h181-set 1
   obj-h181-showGet 1
   obj-h182-hint 1,10,75,100,1000,2000
   obj-h182-reading Config-S0CounterDivisor07
   obj-h182-set 1
   obj-h182-showGet 1
   obj-h183-hint 1,10,75,100,1000,2000
   obj-h183-reading Config-S0CounterDivisor08
   obj-h183-set 1
   obj-h183-showGet 1
   obj-h184-hint 1,10,75,100,1000,2000
   obj-h184-reading Config-S0CounterDivisor09
   obj-h184-set 1
   obj-h184-showGet 1
   obj-h185-hint 1,10,75,100,1000,2000
   obj-h185-reading Config-S0CounterDivisor10
   obj-h185-set 1
   obj-h185-showGet 1
   obj-h19-reading State-SensorFlame1
   obj-h19-showGet 1
   obj-h191-reading S0Counter01
   obj-h191-set 1
   obj-h191-showGet 1
   obj-h191-type CountInWh
   obj-h193-reading S0Counter02
   obj-h193-set 1
   obj-h193-showGet 1
   obj-h193-type CountInWh
   obj-h195-reading S0Counter03
   obj-h195-set 1
   obj-h195-showGet 1
   obj-h195-type CountInWh
   obj-h197-reading S0Counter04
   obj-h197-set 1
   obj-h197-showGet 1
   obj-h197-type CountInWh
   obj-h199-reading S0Counter05
   obj-h199-set 1
   obj-h199-showGet 1
   obj-h199-type CountInWh
   obj-h2-reading State-S0Counter02
   obj-h2-showGet 1
   obj-h20-reading Statistic-Ports-DigitalOut
   obj-h20-showGet 1
   obj-h201-reading S0Counter06
   obj-h201-set 1
   obj-h201-showGet 1
   obj-h201-type CountInWh
   obj-h203-reading S0Counter07
   obj-h203-set 1
   obj-h203-showGet 1
   obj-h203-type CountInWh
   obj-h205-reading S0Counter08
   obj-h205-set 1
   obj-h205-showGet 1
   obj-h205-type CountInWh
   obj-h207-reading S0Counter09
   obj-h207-set 1
   obj-h207-showGet 1
   obj-h207-type CountInWh
   obj-h209-reading S0Counter10
   obj-h209-set 1
   obj-h209-showGet 1
   obj-h209-type CountInWh
   obj-h21-reading State-DoorOpener
   obj-h21-set 1
   obj-h21-showGet 1
   obj-h22-reading State-WatchdogRelais
   obj-h22-set 1
   obj-h22-showGet 1
   obj-h3-reading State-S0Counter03
   obj-h3-showGet 1
   obj-h38-reading State-StateLED1
   obj-h38-set 1
   obj-h38-showGet 1
   obj-h39-reading State-NightLight1
   obj-h39-set 1
   obj-h39-showGet 1
   obj-h4-reading State-S0Counter04
   obj-h4-showGet 1
   obj-h40-reading Statistic-Ports-AnalogIn
   obj-h40-showGet 1
   obj-h41-reading Counter-S0Counter01
   obj-h41-showGet 1
   obj-h42-reading Counter-S0Counter02
   obj-h42-showGet 1
   obj-h43-reading Counter-S0Counter03
   obj-h43-showGet 1
   obj-h44-reading Counter-S0Counter04
   obj-h44-showGet 1
   obj-h45-reading Counter-S0Counter05
   obj-h45-showGet 1
   obj-h46-reading Counter-S0Counter06
   obj-h46-showGet 1
   obj-h47-reading Counter-S0Counter07
   obj-h47-showGet 1
   obj-h48-reading Counter-S0Counter08
   obj-h48-showGet 1
   obj-h49-reading Counter-S0Counter09
   obj-h49-showGet 1
   obj-h5-reading State-S0Counter05
   obj-h5-showGet 1
   obj-h50-reading Counter-SensorSmoke1
   obj-h50-showGet 1
   obj-h58-reading Counter-WatchdogRelais
   obj-h58-showGet 1
   obj-h59-reading Counter-DoorOpener
   obj-h59-showGet 1
   obj-h6-reading State-S0Counter06
   obj-h6-showGet 1
   obj-h60-reading Statistic-Ports-AnalogOut
   obj-h60-showGet 1
   obj-h61-reading Statistic-UptimeHighWord
   obj-h61-set 1
   obj-h61-showGet 1
   obj-h62-reading Statistic-UptimeLowWord
   obj-h62-set 1
   obj-h62-showGet 1
   obj-h63-reading Statistic-LooptimeCurrent
   obj-h63-showGet 1
   obj-h64-hint 0
   obj-h64-reading Statistic-LooptimeMax
   obj-h64-set 1
   obj-h64-showGet 1
   obj-h65-reading Statistic-VoltageCurrent
   obj-h65-showGet 1
   obj-h65-type Voltage
   obj-h66-hint 0
   obj-h66-reading Statistic-VoltageMax
   obj-h66-set 1
   obj-h66-showGet 1
   obj-h66-type Voltage
   obj-h67-hint 999
   obj-h67-reading Statistic-VoltageMin
   obj-h67-set 1
   obj-h67-showGet 1
   obj-h67-type Voltage
   obj-h68-reading Statistic-ProgramVersion
   obj-h68-showGet 1
   obj-h68-type ProgVersion
   obj-h69-hint 0
   obj-h69-reading Statistic-DHT1-PollOK
   obj-h69-set 1
   obj-h69-showGet 1
   obj-h7-reading State-S0Counter07
   obj-h7-showGet 1
   obj-h70-hint 0
   obj-h70-reading Statistic-DHT1-PollError
   obj-h70-set 1
   obj-h70-showGet 1
   obj-h8-reading State-S0Counter08
   obj-h8-showGet 1
   obj-h9-reading State-S0Counter09
   obj-h9-showGet 1
   obj-h97-reading Percent-SensorVoltage1
   obj-h97-showGet 1
   obj-h98-reading Percent-SensorLight1
   obj-h98-showGet 1
   obj-h99-reading Percent-SensorFlame1
   obj-h99-showGet 1
   room       Sys_Modbus
   stateFormat Laufzeit: ro-Uptime
   timestamp-on-change-reading .*
   verbose    3

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 November 2018, 19:25:31
Hallo Marco,

danke für den Hinweis bezügl. Upload.
Ich habe es gerade nochmal hochgeladen.

Mit Deiner Erläuterung habe ich auch verstanden, was Du machen möchtest. Ich hatte fälschlicherweise vermutet, dass Du Fhem als Modbus-Slave testen möchtest.

Bitte probier das ganze doch nochmal mit der aktuellen Version. Falls das Problem dort immer noch auftritt, wäre ein längerer Log-Auszug mit Verbose 5 sehr hilfreich.

Gruss / Thanx
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: lechez am 04 November 2018, 20:24:43
Hallo,

habe das neue Modul als Slave konfiguriert. Leider funktioniert es nicht mit meine WP. Ich möchte der WP Werte anstelle eines Modbus Stromzählers zur Verfügung stellen.
Vielleicht erkennt einer warum es nicht geht.
Anbei mal das Log aufgenommen mit Verbose 5

Gruß

 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 04 November 2018, 20:59:18
Hallo Stefan,

auch mit der neuen Version kann ich kein set machen wenn der Wert über 2 Register geht.
2018.11.04 20:41:45.811 5: mbSlave01: ParseObj called with data 0000, type h, adr 191, valuesLen 2, op write
2018.11.04 20:41:45.814 5: mbSlave01: ParseObj ObjInfo for h191: reading=S0Counter01, unpack=N, expr=, format=, map=
2018.11.04 20:41:45.814 3: mbSlave01: ParseObj unpack of 0000 with N for S0Counter01 resulted in undefined value

Im Anhang das Verbose5 Log mit einem get und einem set
Mir ist aufgefallen dass das starten von FHEM sehr lange dauerte.
Bei jedem Slave sind 4 sec Pause, ist mir vorher so nicht aufgefallen, finde ich aber auch nicht so tragisch.

Grüße
Marco
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 04 November 2018, 21:15:25
ich habe das ModbusModul nochmal unter Windows getestet, das alte funktioniert, das neue nicht
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 November 2018, 22:47:51
Hallo Lechez,

Das erste was mir im Log auffällt, ist dass scheinbar keine sinnvollen Daten empfangen werden.
Es scheitert also schon an der Übertragung. Eventuell ist der Bus nicht richtig terminiert oder die seriellen Parameter stimmen nicht.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 November 2018, 23:06:28
Hallo Marco,

Du versuchst zwei Register mit function code 6 zu schreiben.
Dieser function code ist aber nur für ein Register gedacht und Du solltest mit
attr myDevice dev-h-write 16
dafür sorgen, dass function code 16 verwendet wird. Der ist für mehrere Register gedacht.

Das Modul fängt das bisher nicht ab und ich werde das in der nächsten Version einbauen, dass in solchen Fällen automatisch 16 verwendet wird oder zumindest eine aussagekräftige Meldung kommt.

Es überrascht mich, dass Dein Gerät den eigentlich illegalen Request nicht mit einer Fehler-Nachricht beantwortet. Statt dessen wird scheinbar ein Register (das mit 0) beschrieben und in der Antwort zurückgeliefert.
Beim Versuch den 16-Bit-Wert dann mit N wieder zu entpacken wird dann undef erzeugt.

Die Sache mit der Verzögerung und Windows werde ich mir noch näher anschauen.

Gruß und vielen Dank fürs Testen
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 05 November 2018, 00:22:51
Hallo Stefan,

da hätte ich auch selber drauf kommen können das dafür FC16 anstatt FC6 genutzt werden sollte.
Mit dev-h-write 16 funktioniert das wie erwartet, sowohl Einzelregister als auch mehrere.
Danke für die Lösung.

Also ich nutze den Code für die Slaves falls du da mal reinschauen möchtest.
https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino/blob/master/ModbusRtu.h

Ist jetzt die 3. Library die ich dafür nutzte und bisher die schnellste und stabilste.
Ich schaue mir das Fehlerhändling mal an, vielleicht raffe ich das und kann das anpassen.


Grüße
Marco
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: lechez am 05 November 2018, 11:44:10
Hallo Stefan,

ich galub es auch werde mal den Bus kontrollieren.
Mit einem Testtool von PC zum Pi hat es über rs485 und einem anderen Kabel  funktioniert. Nehme jetzt mal das andere Kabel.
Danke für die schnelle antwort.

Gruß
Andre

Hallo Lechez,

Das erste was mir im Log auffällt, ist dass scheinbar keine sinnvollen Daten empfangen werden.
Es scheitert also schon an der Übertragung. Eventuell ist der Bus nicht richtig terminiert oder die seriellen Parameter stimmen nicht.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 05 November 2018, 22:37:31
Hallo,

Im Log sieht man, dass ein function code 3 Request für id 51, holding register 0 mit Länge 2 eingeht.
Da für Regster 0 kein Objekt definiert ist, nur für Register 1, erzeugt das Modul eine Error-Response mit Fehlercode 2. (PDU 8302).

Gruß
    Stefan

Danke. Jetzt funktioniert  mal der Connect
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 05 November 2018, 22:47:40
Hallo andy1986,

wenn es mal nicht klappt, solltest Du als erstes das Attribut verbose auf 5 setzen, dann den fraglichen Befehl ausführen und ins Fhem-Log schauen.
Dort findest Du vermutlich eine Meldung mit "permission denied". Port 502 kann man nur mit root-Rechten öffnen. Ein Trick, wie man es auch ohne root-Rechte hinbekommt, besteht darin, iptables zu nutzen und Port 502 auf z.B. Port 1502 umzuleiten.
@predi-ger-many: Du hattest Doch eine konkrete Anleitung dafür. Könntest Du die hier posten?

Falls es daran nicht liegt, einfach einen großen Auszug aus dem Log hier posten, dann können andere helfen.

Gruss
   Stefan

Port 502 ohne root-Rechte per iptables

Ich gehe davon aus, dass DHCPCD verwendet wird. Hier 502 nach 1502 per iptables. Getestet auf PI mit Stretch

iptables Regel anlegen
sudo iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 502 -j REDIRECT --to-port 1502

iptables File anlegen
sudo touch /etc/iptables-rules.v4
sudo chmod 666 /etc/iptables-rules.v4

iptables Regel speichern
sudo iptables-save > /etc/iptables-rules.v4

/etc/dhcpcd.enter-hook anlegen
sudo touch /etc/dhcpcd.enter-hook
sudo chmod 755 /etc/dhcpcd.enter-hook

/etc/dhcpcd.enter-hook anpassen
iptables-restore < /etc/iptables-rules.v4

Reboot
sudo reboot

Check nach Reboot
sudo iptables -t nat -L -n -v
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 05 November 2018, 23:21:43
Hi,

meine Config sieht aktuell so aus.

define MB_SLAVE_51 ModbusAttr 51 slave 192.168.1.52:1551 TCP
attr MB_SLAVE_51 room Heizanlage Modbus Neu
attr MB_SLAVE_51 obj-h0-reading MY_51_00
attr MB_SLAVE_51 obj-h1-reading MY_51_01
attr MB_SLAVE_51 obj-h2-reading MY_51_02
attr MB_SLAVE_51 obj-h3-reading MY_51_03
attr MB_SLAVE_51 obj-h4-reading MY_51_04
attr MB_SLAVE_51 obj-h5-reading MY_51_05
attr MB_SLAVE_51 obj-h6-reading MY_51_06
attr MB_SLAVE_51 obj-h7-reading MY_51_07
attr MB_SLAVE_51 obj-h8-reading MY_51_08
attr MB_SLAVE_51 obj-h9-reading MY_51_09
attr MB_SLAVE_51 obj-h10-reading MY_51_10
attr MB_SLAVE_51 obj-h11-reading MY_51_11

Der Connect vom Master aus funktioniert. Nun würde ich ich innerhalb FHEM Werte lesen und schreiben.

set MB_SLAVE_51 MY_51_00 100 liefert "only possible as Modbus master"
get MB_SLAVE_51 MY_51_00 liefert "only possible as Modbus master"

Wie lese und schreibe ich denn intern auf den Slave?

Kann vielleicht jemand eine lauffähige Sample-Config für Slave posten? Die Doku ist etwas arg dünn und 99% dessen was ich finde geht immer um Master und nicht Slave
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: lechez am 06 November 2018, 05:43:47
Hi,

meine Config sieht aktuell so aus.

define MB_SLAVE_51 ModbusAttr 51 slave 192.168.1.52:1551 TCP
attr MB_SLAVE_51 room Heizanlage Modbus Neu
attr MB_SLAVE_51 obj-h0-reading MY_51_00

versuch mal mit setreading MB_SLAVE_51 MY_51_00 1200

Setzt den wert auf 1200. Bei mir hat er es sofort übertragen.
"set" und "get" geht nur bei Master.


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 November 2018, 07:54:26
Hallo,

Infos zur Slave-Funktionalität des Modbus-Moduls gibt es im Forum noch wenig, da die Funktion ja noch sehr neu ist. Deshalb hier noch ein paar Erläuterungen:

Die Idee beim Slave ist ja, dass er Werte, die bereits in Fhem vorliegen einem Master zur Verfügung stellt oder dass ein Master von Außen Werte in Fhem schreiben kann.
Jetzt kann man beispielsweise mit Readings im definierten Modbus-Slave selbst arbeiten.
Um diese intern mit einem Wert zu belegen, nimmt man am besten setreading. Ein eigener set-Befehl im Modul wäre dafür meiner Meinung nach überflüssig.

Man muss Werte aber auch gar nicht als Reading im Modbus-Slave-Gerät setzen um sie einem externen Master zur Verfügung zu stellen.
Ich gehe davon aus, dass die Werte schon irgendwo im Fhem vorliegen, z.B. als Readings eines anderen Geräts oder Sensors.
Dann kann man bei der Konfiguration des Maodbus-Slaves in Fhem auch gleich auf die existierenden Readings verweisen:
attr MB_SLAVE_51 obj-h100-reading SensorGarten:temperature
würde das Reading temperature eines existierenden Geräts mit dem Namen SensorGarten als holding register 100 bereitstellen.

Wenn man dem externen Master erlauben möchte, Werte in Fhem hineinzuschreiben, dann kann man auch das direkt auf Readings anderer Geräte erlauben, z.B.:
attr MB_SLAVE_51 obj-h101-reading Heizung:TempSoll
attr MB_SLAVE_51 obj-h101-allowWrite 1

allerdings muss man hier explizit erlauben, dass die Readings geschrieben werden, damit nicht versehentlich Sensor-Werte von Außen überschrieben werden, die eigentlich nur zum Lesen da sind.

Wenn Euch sonst noch sinnvolle Funktionen fehlen, kann ich die aber auch noch einbauen. Die Slave-Funktionalität oder auch die Relay-Funktion sind ja noch neu und ich freue mich über Tester und Feedback.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 06 November 2018, 19:52:05
Hi,

also langsam wird es etwas.

Aktuell habe ich folgende Konfig:

attr MB_SLAVE_51 room Heizanlage Modbus Neu
attr MB_SLAVE_51 obj-h0-reading MY_51_00
attr MB_SLAVE_51 obj-h1-reading MY_51_01
attr MB_SLAVE_51 obj-h2-reading MY_51_02
attr MB_SLAVE_51 obj-h3-reading MY_51_03
attr MB_SLAVE_51 obj-h4-reading MY_51_04
attr MB_SLAVE_51 obj-h5-reading HM_Bad_WT:2.SET_TEMPERATURE
attr MB_SLAVE_51 obj-h6-reading MY_51_06
attr MB_SLAVE_51 obj-h7-reading MY_51_07
attr MB_SLAVE_51 obj-h7-allowWrite 1
attr MB_SLAVE_51 obj-h8-reading MY_51_08
attr MB_SLAVE_51 obj-h9-reading MY_51_09
attr MB_SLAVE_51 obj-h10-reading MY_51_10
attr MB_SLAVE_51 obj-h11-reading MY_51_11

MY_51_06 habe ich mittels "setreading MB_SLAVE_51 MY_51_06 106" gesetzt.

Im Modbus Master Simulator wird angezeigt:

Holding Adresse 5 - 23 wird angezeigt ... das Reading kommt als 23.0. Ich würde aber gern mit Nachkommastelle übergeben ... also 230. Wie bekomme ich denn das hin.
Holding Adresse 6 - 0 wird angezeigt im Simulator... fehlt da noch etwas?

Ich würde gern den Weg über "setreadings" gehen. Da muss ich weniger migrieren... komme ja von ModbusTCP_CC.

Sorry, wenn meine Fragen total dämlich sind. Aber ich blicke ehrlich gesagt die Doku nicht wirklich.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 November 2018, 21:21:45
Hallo,

die Zahlenformate kannst Du flexibel über den unpack-code beeinflussen. Wenn Du einen Wert mit Nachkommastellen als Float bereitstellen möchtest, brauchst Du allerdings zwei Register - also Länge 2. Du kannst aber auch einfach den Wert mit 10 multipliziert darstellen. Dazu gibt es die Expressions. Das ist alles relativ analog zu der Konfiguration für einen Master.
Also beispielsweise:
attr MB_SLAVE_51 obj-h5-reading HM_Bad_WT:temperature
attr MB_SLAVE_51 obj-h5-unpack f>
attr MB_SLAVE_51 obj-h5-len 2
oder
attr MB_SLAVE_51 obj-h5-reading HM_Bad_WT:temperature
attr MB_SLAVE_51 obj-h5-setExpr $val*10

oder Du definierst einen eigenen Datentyp (siehe https://wiki.fhem.de/wiki/ModbusAttr#Handling_Data_Types)

Zum Unterscheid zwischen -expr und -setExpr:
-setExpr ist immer dazu da, einen Wert in das Format für Register zu übersetzen, also wenn ein Slave Daten liefern soll oder wenn ein Master per Set-Befehl Daten an einen Slave sendet.

-expr ist immer dafür da, Werte aus Registern für den Anwender oder für Readings aufzubereiten. Also bei einem Slave beim Schreiben von Readings als Reaktion auf einen Schreib-Befehl per Modbus oder bei einem Master um von einem Slave gelesene Werte in Readings zu packen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 November 2018, 22:03:49
Hallo Marco,

anbei eine neue Version, die vermutlich unter Windows besser funktionieren sollte.
Könntest Du das nochmal testen?

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 10 November 2018, 16:10:25
Hallo Stefan,

"attr MB_SLAVE_51 obj-h5-setExpr $val*10" liefert folgenden Fehler:

MB_SLAVE_51: unknown attribute obj-h113-setExpr. Type 'attr MB_SLAVE_51 ?' for a detailed list.

setexpr anstatt setExpr funktioniert zumindest von der Syntax.


HM_Bad_WT:2.SET_TEMPERATURE hat Wert 23.0.
Habe testweise folgende Definition gemacht:

attr MB_SLAVE_51 obj-h104-reading HM_Bad_WT:2.SET_TEMPERATURE
attr MB_SLAVE_51 obj-h104-setexpr $val*10
attr MB_SLAVE_51 obj-h104-expr $val*10

Im Simulator kommt nicht 230 an, sondern 23. Entweder bin ich zu blöd... oder BUG?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 November 2018, 16:39:40
Hallo,

im code stand setExpr, in der Liste der erlaubten Attribute so wie bisher und in der doku setexpr, also Bug.
setexpr ist natürlich richtig.
Anbei ein Update.

Gruss und Danke fürs Testen
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 10 November 2018, 18:33:35
attr MB_SLAVE_51 obj-h104-reading HM_Bad_WT:2.SET_TEMPERATURE
attr MB_SLAVE_51 obj-h104-setexpr $val*10

... funktioniert

attr MB_SLAVE_51 obj-h100-reading Wohnzimmer_Temp_Soll
attr MB_SLAVE_51 obj-h100-setexpr $val*10

... funktioniert plötzlich auch


Vielen Dank!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 10 November 2018, 22:05:21
Hallo Stefan,

ich komme ja von ModbusTCP_CC.

Bisher hatte ich definiert:

define ModbusTCP_Server ModbusTCP_CC 1502

###############################################################################
# ModbusTCP - Device 10 - Coils
###############################################################################
define ModbusTCP_10_00001 dummy
attr ModbusTCP_10_00001 comment MBC:10,1,C
...
...
...

###############################################################################
# ModbusTCP - Device 20 - Holding Registers
###############################################################################
define ModbusTCP_20_40001 dummy
attr ModbusTCP_20_40001 comment MBR:20,1,H
...
...
...

Bei ModbusTCP_CC war die DeviceID auf dem Wert hinterlegt. Man konnte also X-Devices auf einem Port laufen lassen.

Bei ModbusAttr habe ich nun versucht:

define ModbusTCP_10 ModbusAttr 10 slave 192.168.1.52:1502 TCP
define ModbusTCP_20 ModbusAttr 20 slave 192.168.1.52:1502 TCP

Device 10 startet. Device 20 bleibt Initialized. Naja, zwei Prozesse, welche auf den gleichen Port wollen...

Böse Frage: Kannst du umbauen, so dass X-Devices auf einer IP und Port gehen würden. Mir ist klar, dass das richtig Aufwand ist. Wäre aber sehr praktisch



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mba am 11 November 2018, 20:01:41
Hallo Stefan,

ich habe 4.0.17 unter Windows getestet. Die Fehler mit Zugriff verweigert auf COM3 sind weg.
Ich sehe auf einem Slave RX aktivität, aber kein TX, somit auch keine Antwort vom Slave.
Bin mir aber nicht sicher ob es am Slave liegt. Ich werde nochmal mit einem Testen wo ich weis das er funktioniert, aber momentan sind alle anderen in Benutzung.

Guß
Marco
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: predi-ger-many am 11 November 2018, 20:45:30
Hallo Stefan,

ich komme von ModbusTCP_CC. Die Umstellung auf ModbusAttr war steinig. Aber eigentlich nur wegen diesem einen dusseligen Bug.
Nach dem Bugfix muss ich sagen, dass der Rest jetzt ein Kinderspiel ist.

Werte werden an Heizung gesendet. Werte werden von Heizung empfangen. Sogar negative Werte werden Out-of-the-box korrekt behandelt.
Die Performance sieht auch gut aus.

Holding Register laufen jetzt. Mal schauen, ob der Rest auch so problemlos wird

Eigentlich war die Umstellung auf ModbussAttr nur als Zwischenlösung gedacht und ich wollte auf auf KNX umstellen. Wenn alles weiter
so top läuft, kann ich mir das wohl ersparen.

Von daher super vielen Dank für deinen tollen Support.

Viele Grüße
Predi
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Turnschuh am 14 November 2018, 21:32:26
Hallo Stefan,

ich bin mir nicht sicher ob die Frage hier hin passt.
Ich habe ein Problem mit einem SDM630M Modubus Zaehler.

Initial habe ich eine Modbus Verbindung hinbekommen aber seit einigen Tagen funktioniert diese nicht mehr.
Ob es passt weis ich deshalb nicht, da ich ein modifiziertes Modbus Modul "98_ModbusSDM630M.pm" nutze.

Aber vielleicht hast Du einen Tip wie ich pruefen kann ob ueberhaupt noch eine Verbindung mit dem Zaehler aufgebaut wird.

Danke schonmal vorab,
Andy
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 15 November 2018, 20:20:37
Hallo Andy,

ich vermute, 98_ModbusSDM630M.pm ist das Modul von Roger. Das basiert auf 98_Modbus.pm und kann damit genauso verwendet und konfiguriert werden wie ModbuAttr, allerdings sind die ganzen Attribute zur Konfiguration der Register für den SDM630 im Modul schon enthalten.

Bei der Fehlersuche sollte man das Attribut verbose für das Gerät und für das rs485-Interface auf 5 setzen und dann schauen was beim Starten / Öffnen im Log steht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Turnschuh am 16 November 2018, 00:10:31
Hallo Stefan,

danke fuer Deine Antwort.

Ich habe das Loglevel auf 5 gestellt und sehe jetzt den Verbindungsaufbau:

2018.11.15 22:37:55 3: SDM_630_Meter: defined as /dev/ttyUSB0@9600
2018.11.15 22:38:03 4: SDM_630_Meter: Notify / Init: opening connection
2018.11.15 22:38:03 5: SDM_630_Meter: open called from Notify
2018.11.15 22:38:03 4: SDM_630_Meter: open trying to open connection to /dev/ttyUSB0@9600
2018.11.15 22:38:03 3: Opening SDM_630_Meter device /dev/ttyUSB0
2018.11.15 22:38:03 3: Setting SDM_630_Meter serial parameters to 9600,8,N,1
2018.11.15 22:38:03 3: SDM_630_Meter device opened

Das sieht fuer mich so aus als ob das so erfolgreich war.

Spaeter habe ich aber dann Timeouts, wie folgt:

2018.11.15 22:38:06 5: SDM_630_Meter: ProcessRequestQueue called from HandleTimeout as queue:SDM_630_Meter
2018.11.15 22:38:06 5: SDM_630_Meter: ProcessRequestQueue called from HandleTimeout returns, Fhem is still waiting for response, qlen 10, try again in 1 seconds
2018.11.15 22:38:06 5: SDM_630_Meter: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2018.11.15 22:38:06 3: SDM_630_Meter: ResponseTimeout called, devhash=HASH(0x24c87f0), name of devhash=SDM630M
2018.11.15 22:38:06 3: SDM_630_Meter: Timeout waiting for a modbus response, request: id 1, fCode 4, type i, adr 40, len 40 for device SDM630M reading CosPhi_L3__grd, read buffer empty
2018.11.15 22:38:06 5: SDM_630_Meter: DropFrame - drop

Irgendeine Idee warum das sein koennte?

Ich hatte den Zaehler ja bereits mal am laufen und auch Werte bekommen.

Cheers,
Andy
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 16 November 2018, 17:36:55
Hallo Andy,

ist denn ttyUSB0 wirklich noch korrekt? Evt. ist der richtige serielle Adapter ja inzwischen ttyUSB1 oder ttyUSB2 ...
Der Log-Eintrag "opened" bedeutet nur dass die serielle Schnittstelle geöffnet wurde. Einen echten Verbindungsaufbau gibt es nicht.
Eventuell hat sich ja auch an der Verkabelung etwas gelöst. Probier es doch mal mit einem anderen Modbus-Simulator.
Oder die ID stimmt nicht mehr ...

Es kann leider viele Gründe haben, warum keine Antwort kommt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 November 2018, 15:20:43
Ich habe die neuen Versionen von 98_Modbus und 98_ModbusAttr gerade eingecheckt und hoffe das die größten Bugs der neuen Version behoben sind.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 19 November 2018, 16:07:12
Hallo Stefan, seit heutigem update hagelts bei Neustart fhem:

2018.11.19 15:56:27 3: Xtender_AC_in: MapConvert called from ModbusLD_ParseObj did not find 00020000 in map 1:import, 2:import+export, 3:import-export
2018.11.19 15:56:46 3: Xtender_AC_out: MapConvert called from ModbusLD_ParseObj did not find 00020000 in map 1:import, 2:import+export, 3:import-export
2018.11.19 15:56:50 3: Xtender_AC_out: MapConvert called from ModbusLD_ParseObj did not find 00000000 in map 0:0.001/imp, 1:0.01/imp, 2:0.1/imp, 3:1/imp
2018.11.19 15:56:54 3: Xtender_AC_out: MapConvert called from ModbusLD_ParseObj did not find 00000000 in map 0:0.001/imp, 1:0.01/imp, 2:0.1/imp, 3:1/imp
2018.11.19 15:56:56 3: Xtender_AC_out: MapConvert called from ModbusLD_ParseObj did not find 00020000 in map 1:import, 2:import+export, 3:import-export

Bei mir  SDM220M von Roger. Das war vorher nicht so. Kann ich etwas zur Fehlerfindung beitragen? List, etc ... oder sagt dir das schon was?

Die defines:
define Eastron Modbus /dev/ttyUSB1@9600
attr Eastron busDelay 1
attr Eastron clientSwitchDelay 1
attr Eastron group Xtender
#attr Eastron timeoutLogLevel 4

#------------------------ 1. Zaehler AC-IN, Modul Modbus , ID1, abfrage alle 25sec. ---------------#

define Xtender_AC_in ModbusSDM220M 1 25
attr Xtender_AC_in userattr IODev event-min-interval event-on-change-reading event-on-update-reading userReadings
attr Xtender_AC_in IODev Eastron
attr Xtender_AC_in event-min-interval Power_.*.W:900,Voltage__V:900,Energy_total__kWh:900,statEnergy_total__kWh:900,statEnergy_total__kWhDay:900,Verbrauch_Enel:900,.*Last.*:900
attr Xtender_AC_in event-on-change-reading Power_.*.W:10,Voltage__V:1,Energy_total__kWh,statEnergy_total__kWh,statEnergy_total__kWhDay,Verbrauch_Enel,.*Last.*
attr Xtender_AC_in event-on-update-reading Power_.*.W,Voltage__V,Energy_total__kWh,statEnergy_total__kWh,statEnergy_total__kWhDay,Verbrauch_Enel,.*Last.*
attr Xtender_AC_in group Xtender
attr Xtender_AC_in userReadings Verbrauch_Enel:Energy_total__kWh { ReadingsNum("$name","Energy_total__kWh",0)-159.01 . " kWh";; }

#--------------------------- 2. Zaehler AC-Out, Modul Modbus , ID2, abfrage alle 7 sec. -------------#

define Xtender_AC_out ModbusSDM220M 2 7
attr Xtender_AC_out userattr IODev event-min-interval event-on-change-reading event-on-update-reading userReadings
attr Xtender_AC_out IODev Eastron
attr Xtender_AC_out event-min-interval Power_.*.W:900,Voltage__V:900,Energy_total__kWh:900,statEnergy_total__kWh:900,statEnergy_total__kWhDay:900,Verbrauch_Home:900,.*Last.*:900
attr Xtender_AC_out event-on-change-reading Power_.*.W:10,Voltage__V:1,Energy_total__kWh,statEnergy_total__kWh,statEnergy_total__kWhDay,Verbrauch_Enel,.*Last.*
attr Xtender_AC_out event-on-update-reading Power_.*.W,Voltage__V,Energy_total__kWh,statEnergy_total__kWh,statEnergy_total__kWhDay,Verbrauch_Home,.*Last.*
attr Xtender_AC_out group Xtender
attr Xtender_AC_out userReadings Verbrauch_Home:Energy_total__kWh { ReadingsNum("$name","Energy_total__kWh",0)-366.51 . " kWh";; }

Grüße!
H.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 November 2018, 18:16:27
Hallo,

Ein Log-Auszug mit verbose 5 (sowohl für das Modbus-Device als auch die SDM-Devices)
wäre sehr hilfreich.

Gruss / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 19 November 2018, 18:25:22
Hallo Stefan, log anbei. Habe jetzt mal neben Modbus-Device nur den einen Zähler auf verbose 5 gesetzt, da beide das selbe Problem haben sollten. Datenmenge reduzieren. Wenn das nicht in deinem Sinne ist mach ich das gerne nochmal.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 November 2018, 20:50:36
Hallo,

wenn ich mir das so ansehe, dann wundere ich mich wie das bisher funktioniert hat.
Um diese Frage zu klären, wäre es hilfreich, wenn Du das alte Modul nochmal reaktivieren könntest und damit den gleichen Teil mit verbose 5 loggen könntest.
Ich wäre da sehr neugierig...

Um es mit dem neuen Modul in Ordnung zu bringen, würde ich das SDM220-Modul korrigieren:
Bisher (sofern das noch aktuell ist) steht da bei Zeile 340:

"h63776" => { # holding register 0xF920
# Data Format: Hex
# 0001:mode 1(total = import)
# 0002:mode 2(total = import + export) ( default)
# 0003:mode 3 (total = import - export)
name => "Measurement mode", # internal name of this register in the hardware doc
reading => "System_Measurement_mode", # name of the reading for this value
unpack => "H*", # Hex pack / unpack code to convert raw values
map => "1:import, 2:import+export, 3:import-export", # map to convert visible values to internal numbers (for reading and writing)
hint => "1,2,3", # string for fhemweb to create a selection or slider
format => '%s', # format string for sprintf
poll => "once", # only poll once after define (or after a set)
set => 1, # this value can be set
},

korrigiert sollte da stehen:

"h63776" => { # holding register 0xF920
# Data Format: Hex
# 0001:mode 1(total = import)
# 0002:mode 2(total = import + export) ( default)
# 0003:mode 3 (total = import - export)
name => "Measurement mode", # internal name of this register in the hardware doc
reading => "System_Measurement_mode", # name of the reading for this value
        unpack => "S", # unsigned 16 Bit Integer
                                        len                    =>   1,                                     # one register, not two
map => "1:import, 2:import+export, 3:import-export", # map to convert visible values to internal numbers (for reading and writing)
hint => "1,2,3", # string for fhemweb to create a selection or slider
format => '%s', # format string for sprintf
poll => "once", # only poll once after define (or after a set)
set => 1, # this value can be set
},

Ich habe len 1 hinzugefügt, da sonst defLen 2 aus Zeile 77 greift und
unpack auf S geändert, da sonst Werte wie 0001 kommen, die Map aber auf 1 matcht und nicht 0001.

Es wäre super wenn Du beides mal testen könntest, da ich keinen SDM220 habe.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 19 November 2018, 21:14:16
gib mir ein halbes Stündchen
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 19 November 2018, 21:49:18
Dateien jongliert.

die logs anbei. ModbusSDM220 in der geänderten Form

Jetzt in der letzten Testversion (modbus neu, Modifikationen an SDM220 ausgeführt) wieder auf Verbose 3 gibts noch folgende (selbige) Infos/Fehler

2018.11.19 21:31:42 3: Xtender_AC_in: defined with id 1, interval 25, protocol default (RTU), mode master
2018.11.19 21:31:42 3: Xtender_AC_in: RegisterAtIODev called from ModbusLD_SetIODev registers Xtender_AC_in at Eastron with id 1, MODE master, PROTOCOL RTU
2018.11.19 21:31:42 3: Xtender_AC_out: defined with id 2, interval 7, protocol default (RTU), mode master
2018.11.19 21:31:42 3: Xtender_AC_out: RegisterAtIODev called from ModbusLD_SetIODev registers Xtender_AC_out at Eastron with id 2, MODE master, PROTOCOL RTU


2018.11.19 21:39:10 3: Xtender_AC_in: RegisterAtIODev called from ModbusLD_SetIODev registers Xtender_AC_in at Eastron with id 1, MODE master, PROTOCOL RTU
2018.11.19 21:39:10 3: Xtender_AC_in: Notify / Init: using Eastron for communication
2018.11.19 21:39:10 3: Xtender_AC_out: RegisterAtIODev called from ModbusLD_SetIODev registers Xtender_AC_out at Eastron with id 2, MODE master, PROTOCOL RTU
2018.11.19 21:39:10 3: Xtender_AC_out: Notify / Init: using Eastron for communication

2018.11.19 21:39:12 3: Xtender_AC_in: MapConvert called from ModbusLD_ParseObj did not find 00000000 in map 0:0.001/imp, 1:0.01/imp, 2:0.1/imp, 3:1/imp
2018.11.19 21:39:21 3: Xtender_AC_in: MapConvert called from ModbusLD_ParseObj did not find 512 in map 1:import, 2:import+export, 3:import-export
2018.11.19 21:39:48 3: Xtender_AC_out: MapConvert called from ModbusLD_ParseObj did not find 00000000 in map 0:0.001/imp, 1:0.01/imp, 2:0.1/imp, 3:1/imp
2018.11.19 21:39:52 3: Xtender_AC_out: MapConvert called from ModbusLD_ParseObj did not find 00000000 in map 0:0.001/imp, 1:0.01/imp, 2:0.1/imp, 3:1/imp

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 November 2018, 22:50:21
Hallo,

Zunächst mal Danke fürs Testen.
Im Log der alten Version ist der Fehler auch drin. Nur wird er nicht auf Level 3 Protokolliert:
2018.11.19 21:25:22 5: Xtender_AC_out: ParseObj unpacked 00020000 with H* to hex 3030303230303030 (00020000)
2018.11.19 21:25:22 5: Xtender_AC_out: ParseObj for System_Measurement_mode maps value to 00020000 with 1:import, 2:import+export, 3:import-export
2018.11.19 21:25:22 5: Xtender_AC_out: ParseObj for System_Measurement_mode does sprintf with format %s value is 00020000
2018.11.19 21:25:22 5: Xtender_AC_out: ParseObj for System_Measurement_mode sprintf result is 00020000
2018.11.19 21:25:22 4: Xtender_AC_out: ParseObj for System_Measurement_mode assigns 00020000
2018.11.19 21:25:22 5: Eastron: ParseFrames got 1 readings from ParseObj

In der neuen Version klappt es auch noch nicht ganz, da die Byte-Reihenfolge noch falsch ist. Unpack mit S macht aus hex 0001 eine 512. Unpack S> sollte besser funktionieren und daraus eine 1 machen, die dann in der Map gefunden wird.

Das gleiche Problem besteht mit h63760 und eventuell bei anderen Maps, die mit Unpack H* definiert sind.
In der alten Version ist der ursprüngliche Wert einfach beibehalten worden, wenn eine Map nicht gepasst hat. Die neue beschwert sich im Log.

Gruß
    Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 20 November 2018, 00:11:43
Danke Stefan. Könntest du mir noch ein bißchen genauer sagen was ich jetzt wo ändern muß? Das File ist ja von Roger und ich bin nicht drin was wie wo.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 20 November 2018, 15:51:45
TsTs, Angst abgelegt und einfach mal gemacht, was du geschrieben hast :D

Alle (die 2) H* gegen S> getauscht und funktioniert (zumindest ohne Fehlermeldungen beim starten).

Danke dir!

Braucht es Dies hier beim starten?:

2018.11.20 15:45:49 3: Xtender_AC_in: defined with id 1, interval 25, protocol default (RTU), mode master
2018.11.20 15:45:49 3: Xtender_AC_in: RegisterAtIODev called from ModbusLD_SetIODev registers Xtender_AC_in at Eastron with id 1, MODE master, PROTOCOL RTU
2018.11.20 15:45:49 3: Xtender_AC_out: defined with id 2, interval 7, protocol default (RTU), mode master
2018.11.20 15:45:49 3: Xtender_AC_out: RegisterAtIODev called from ModbusLD_SetIODev registers Xtender_AC_out at Eastron with id 2, MODE master, PROTOCOL RTU
2018.11.20 15:45:53 3: Opening Eastron device /dev/ttyUSB1
2018.11.20 15:45:53 3: Setting Eastron serial parameters to 9600,8,N,1
2018.11.20 15:45:53 3: Eastron device opened
2018.11.20 15:45:53 3: Xtender_AC_in: RegisterAtIODev called from ModbusLD_SetIODev registers Xtender_AC_in at Eastron with id 1, MODE master, PROTOCOL RTU
2018.11.20 15:45:53 3: Xtender_AC_in: Notify / Init: using Eastron for communication
2018.11.20 15:45:53 3: Xtender_AC_out: RegisterAtIODev called from ModbusLD_SetIODev registers Xtender_AC_out at Eastron with id 2, MODE master, PROTOCOL RTU
2018.11.20 15:45:53 3: Xtender_AC_out: Notify / Init: using Eastron for communication

und ein Fehler kommt dann noch verspätet:

2018.11.20 16:51:02 1: PERL WARNING: Argument "" isn't numeric in sprintf at ./FHEM/98_HTTPMOD.pm line 1791.
ist das ein Auslesefehler oder was Generelles?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 November 2018, 21:11:48
Hallo,

die Meldungen beim Starten sind in Ordnung.
Der Fehler bei HTTPMOD ist ein anderes Thema, vermutlich wurde da ein numerisches Format per Attribut angegeben, aber der gelesene Wert ist "".

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Turnschuh am 28 November 2018, 12:27:49
Hallo Stefan,

danke schonmal fuer die Antwort.
ttyUSB0 ist korrekt und auch die Modbus ID.

Ich pruefe dann nochmal die Verkabelung.
Hast Du noch einen anderen Hinweis fuer mich?

Cheers,
Andy
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 28 November 2018, 17:16:24
habe nun auch die neue Version (Id: 98_Modbus.pm 17767) per Update erhalten.
Ich hole Daten von einem Wechselrichter. Meine Definition ist
defmod SE7K ModbusAttr 1 300 <IP>:502 TCP
attr SE7K dev-h-combine 50
attr SE7K dev-h-defPoll 1
attr SE7K dev-h-defShowGet 1
attr SE7K enableControlSet 1
attr SE7K event-on-change-reading .*
attr SE7K maxTimeoutsToReconnect 600
........
und dann die Register

prinzipiell funktioniert das auch noch, nur die Readings werden nicht mehr automatisch aktualisiert.
Ein set reread funktioniert. Ich habe an der config nichts geändert.
mit der alten Version (Id: 98_Modbus.pm 15871) hat das funktioniert.
Frage: muss ich etwas an der config anpassen?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 28 November 2018, 17:39:31
Hallo Tom_S,

versuche es mal mit diesem Modul (https://forum.fhem.de/index.php/topic,80767.msg853967.html#msg853967).

defmod SE7k SolarEdge 1 60 ip:502 TCP

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 28 November 2018, 18:48:01
naja, das greift ja auf das selbe Modul zurück. Ich weis nicht, ob ich dafür ein eigenes Modul brauche. Es funktioniert ja alles soweit. Wenn es mit deinem Modul geht, liegt es doch nur an meiner config oder?

LG
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 November 2018, 17:05:34
Hallo Tom,

eigentlich sollte die alte Konfig mit dem neuen Modul noch genauso funktionieren.
Könntest Du mal verbose auf 5 setzen und dann das Log posten?
Zur Sicherheit solltest Du dabei auch das event-on-change-reading entfernen.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 29 November 2018, 20:13:56
mach ich doch.

also ohne event-on-change-reading mit verbose 5

2018.11.29 19:40:49 5: SE7K: GetUpdate called from ModbusLD_ControlSet
2018.11.29 19:40:49 5: SE7K: GetUpdate objects from attributes: h20 h100 h71 h103 h81 h126 h101 h107 h98 h106 h84 h75 h123 h85 h80 h93 h96 h83 h21 h79
2018.11.29 19:40:49 5: SE7K: GetUpdate full object list: h100 h101 h103 h106 h107 h123 h126 h20 h21 h71 h75 h79 h80 h81 h83 h84 h85 h93 h96 h98
2018.11.29 19:40:49 5: SE7K: GetUpdate check h100 => I_DC_Power_raw, poll = 1, last = 1543515232.99694
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_DC_Power_raw
2018.11.29 19:40:49 5: SE7K: GetUpdate check h101 => I_DC_Power, poll = 1, last = 1543515233.00012
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_DC_Power
2018.11.29 19:40:49 5: SE7K: GetUpdate check h103 => Temperature, poll = 1, last = 1543515233.00342
2018.11.29 19:40:49 4: SE7K: GetUpdate will request Temperature
2018.11.29 19:40:49 5: SE7K: GetUpdate check h106 => I_Temp_SF, poll = 1, last = 1543515233.00627
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_Temp_SF
2018.11.29 19:40:49 5: SE7K: GetUpdate check h107 => C_Status, poll = 1, last = 1543515233.01054
2018.11.29 19:40:49 4: SE7K: GetUpdate will request C_Status
2018.11.29 19:40:49 5: SE7K: GetUpdate check h123 => U_L1, poll = 1, last = 1543515232.81453
2018.11.29 19:40:49 4: SE7K: GetUpdate will request U_L1
2018.11.29 19:40:49 5: SE7K: GetUpdate check h126 => I_L1, poll = 1, last = 1543515232.81798
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_L1
2018.11.29 19:40:49 5: SE7K: GetUpdate check h20 => I_AC_Energie_year, poll = 1, last = 1543515233.13874
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_AC_Energie_year
2018.11.29 19:40:49 5: SE7K: GetUpdate check h21 => I_AC_Energie_month, poll = 1, last = 1543515233.14194
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_AC_Energie_month
2018.11.29 19:40:49 5: SE7K: GetUpdate check h71 => I_AC_Strom, poll = 1, last = 1543515232.96024
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_AC_Strom
2018.11.29 19:40:49 5: SE7K: GetUpdate check h75 => I_AC_Strom_SF, poll = 1, last = 1543515232.96379
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_AC_Strom_SF
2018.11.29 19:40:49 5: SE7K: GetUpdate check h79 => I_L1_Spannung, poll = 1, last = 1543515232.96758
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_L1_Spannung
2018.11.29 19:40:49 5: SE7K: GetUpdate check h80 => I_L2_Spannung, poll = 1, last = 1543515232.97072
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_L2_Spannung
2018.11.29 19:40:49 5: SE7K: GetUpdate check h81 => I_L3_Spannung, poll = 1, last = 1543515232.97378
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_L3_Spannung
2018.11.29 19:40:49 5: SE7K: GetUpdate check h83 => I_AC_Power_raw, poll = 1, last = 1543515232.97698
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_AC_Power_raw
2018.11.29 19:40:49 5: SE7K: GetUpdate check h84 => I_AC_Power, poll = 1, last = 1543515232.98031
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_AC_Power
2018.11.29 19:40:49 5: SE7K: GetUpdate check h85 => I_AC_Frequenz, poll = 1, last = 1543515232.98342
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_AC_Frequenz
2018.11.29 19:40:49 5: SE7K: GetUpdate check h93 => I_AC_Energie, poll = 1, last = 1543515232.98721
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_AC_Energie
2018.11.29 19:40:49 5: SE7K: GetUpdate check h96 => I_DC_Strom, poll = 1, last = 1543515232.9905
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_DC_Strom
2018.11.29 19:40:49 5: SE7K: GetUpdate check h98 => I_DC_Spannung, poll = 1, last = 1543515232.99375
2018.11.29 19:40:49 4: SE7K: GetUpdate will request I_DC_Spannung
2018.11.29 19:40:49 5: SE7K: GetUpdate tries to combine read commands
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Energie_year (h20) with I_AC_Energie_month (h21), span=2, max=50, drop read for h21
2018.11.29 19:40:49 5: SE7K: GetUpdate cant combine request for I_AC_Energie_year / h20 with I_AC_Strom / h71, span 52 > max 50
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Strom_SF (h75), span=5, max=50, drop read for h75
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_L1_Spannung (h79), span=9, max=50, drop read for h79
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_L2_Spannung (h80), span=10, max=50, drop read for h80
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_L3_Spannung (h81), span=11, max=50, drop read for h81
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Power_raw (h83), span=13, max=50, drop read for h83
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Power (h84), span=14, max=50, drop read for h84
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Frequenz (h85), span=15, max=50, drop read for h85
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Energie (h93), span=24, max=50, drop read for h93
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_DC_Strom (h96), span=26, max=50, drop read for h96
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_DC_Spannung (h98), span=28, max=50, drop read for h98
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_DC_Power_raw (h100), span=30, max=50, drop read for h100
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_DC_Power (h101), span=31, max=50, drop read for h101
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with Temperature (h103), span=33, max=50, drop read for h103
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_Temp_SF (h106), span=36, max=50, drop read for h106
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with C_Status (h107), span=37, max=50, drop read for h107
2018.11.29 19:40:49 5: SE7K: GetUpdate cant combine request for I_AC_Strom / h71 with U_L1 / h123, span 53 > max 50
2018.11.29 19:40:49 5: SE7K: GetUpdate combines request for U_L1 (h123) with I_L1 (h126), span=4, max=50, drop read for h126
2018.11.29 19:40:49 5: SE7K: GetUpdate doesn't sort objList before sending requests
2018.11.29 19:40:49 5: SE7K: DoRequest called from ModbusLD_GetUpdate
2018.11.29 19:40:49 4: SE7K: DoRequest (called from ModbusLD_GetUpdate) created, request: id 1, fCode 3, tid 134, type h, adr 123, len 4 for device SE7K reading U_L1, read buffer empty
2018.11.29 19:40:49 5: SE7K: QueueRequest called from ModbusLD_DoRequest with h123, qlen 0
2018.11.29 19:40:49 5: SE7K: ProcessRequestQueue called from QueueRequest as direct:SE7K
2018.11.29 19:40:49 5: SE7K: open called from ProcessRequestQueue
2018.11.29 19:40:49 4: SE7K: open trying to open connection to 192.168.115.15:502
2018.11.29 19:40:49 3: Opening SE7K device 192.168.115.15:502
2018.11.29 19:40:49 5: HttpUtils url=http://192.168.115.15:502/
2018.11.29 19:40:50 5: SE7K: ProcessRequestQueue called from QueueRequest returns, device is disconnected, qlen 1, try again in 1 seconds
2018.11.29 19:40:50 5: SE7K: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2018.11.29 19:40:50 5: SE7K: DoRequest called from ModbusLD_GetUpdate
2018.11.29 19:40:50 4: SE7K: DoRequest (called from ModbusLD_GetUpdate) created, request: id 1, fCode 3, tid 72, type h, adr 20, len 2 for device SE7K reading I_AC_Energie_year, read buffer empty
2018.11.29 19:40:50 5: SE7K: QueueRequest called from ModbusLD_DoRequest with h20, qlen 1
2018.11.29 19:40:50 5: SE7K: ProcessRequestQueue called from QueueRequest as direct:SE7K
2018.11.29 19:40:50 5: SE7K: open called from ProcessRequestQueue
2018.11.29 19:40:50 5: SE7K: ProcessRequestQueue called from QueueRequest returns, device is disconnected, qlen 2, try again in 1 seconds
2018.11.29 19:40:50 5: SE7K: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2018.11.29 19:40:50 5: SE7K: DoRequest called from ModbusLD_GetUpdate
2018.11.29 19:40:50 4: SE7K: DoRequest (called from ModbusLD_GetUpdate) created, request: id 1, fCode 3, tid 251, type h, adr 71, len 37 for device SE7K reading I_AC_Strom, read buffer empty
2018.11.29 19:40:50 5: SE7K: QueueRequest called from ModbusLD_DoRequest with h71, qlen 2
2018.11.29 19:40:50 5: SE7K: ProcessRequestQueue called from QueueRequest as direct:SE7K
2018.11.29 19:40:50 5: SE7K: open called from ProcessRequestQueue
2018.11.29 19:40:50 5: SE7K: ProcessRequestQueue called from QueueRequest returns, device is disconnected, qlen 3, try again in 1 seconds
2018.11.29 19:40:50 5: SE7K: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2018.11.29 19:40:50 4: SE7K device opened
2018.11.29 19:40:50 4: SE7K: SetUpdateTimer updated timer - will call GetUpdate in 300.0 seconds at 2018-11-29 19:45:50 - Interval 300
2018.11.29 19:40:51 5: SE7K: ProcessRequestQueue called from HandleTimeout as queue:SE7K
2018.11.29 19:40:51 5: SE7K: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 19:13:53.134) for SE7K, delay over
2018.11.29 19:40:51 5: SE7K: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 19:13:53.130) for SE7K, delay over
2018.11.29 19:40:51 5: SE7K: PackRequest called from ProcessRequestQueue
2018.11.29 19:40:51 4: SE7K: ProcessRequestQueue got pdu from PackRequest: 03007b0004
2018.11.29 19:40:51 5: SE7K: PackFrame called from ProcessRequestQueue id 1, tid 134, pdu 03007b0004
2018.11.29 19:40:51 4: SE7K: ProcessRequestQueue (V4.0.17 - 10.11.2018) sending, request: id 1, fCode 3, tid 134, type h, adr 123, len 4 for device SE7K reading U_L1, read buffer empty
2018.11.29 19:40:51 5: SW: 0086000000060103007b0004
2018.11.29 19:40:51 5: SE7K: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2018.11.29 19:40:51 4: 192.168.115.15:502 disconnected, waiting to reappear (SE7K)
2018.11.29 19:40:51 5: SE7K: StopQueueTimer called from Open removes internal timer to call Modbus_ProcessRequestQueue
2018.11.29 19:40:51 5: HttpUtils url=http://192.168.115.15:502/
2018.11.29 19:40:51 4: 192.168.115.15:502 reappeared (SE7K)
2018.11.29 19:40:51 4: SE7K: SetUpdateTimer updated timer - will call GetUpdate in 300.0 seconds at 2018-11-29 19:45:51 - Interval 300
2018.11.29 19:40:53 3: SE7K: ResponseTimeout called, devhash=HASH(0x20e3388), name of devhash=SE7K
2018.11.29 19:40:53 3: SE7K: Timeout waiting for a modbus response, request: id 1, fCode 3, tid 134, type h, adr 123, len 4 for device SE7K reading U_L1, read buffer empty
2018.11.29 19:40:53 5: SE7K: DropFrame - drop
2018.11.29 19:40:53 5: SE7K: StartQueueTimer called form ResponseTimeout sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2018.11.29 19:40:53 5: SE7K: ProcessRequestQueue called from HandleTimeout as queue:SE7K
2018.11.29 19:40:53 5: SE7K: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 19:13:53.134) for SE7K, delay over
2018.11.29 19:40:53 5: SE7K: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 19:40:51.025) for SE7K, delay over
2018.11.29 19:40:53 5: SE7K: PackRequest called from ProcessRequestQueue
2018.11.29 19:40:53 4: SE7K: ProcessRequestQueue got pdu from PackRequest: 0300140002
2018.11.29 19:40:53 5: SE7K: PackFrame called from ProcessRequestQueue id 1, tid 72, pdu 0300140002
2018.11.29 19:40:53 4: SE7K: ProcessRequestQueue (V4.0.17 - 10.11.2018) sending, request: id 1, fCode 3, tid 72, type h, adr 20, len 2 for device SE7K reading I_AC_Energie_year, read buffer empty
2018.11.29 19:40:53 5: SW: 004800000006010300140002
2018.11.29 19:40:53 5: SE7K: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2018.11.29 19:40:53 5: SE7K: read buffer: 0048000000070103045345374b
2018.11.29 19:40:53 5: SE7K: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 72, dlen 7 and data 045345374b
2018.11.29 19:40:53 5: SE7K: HandleResponse called from Read
2018.11.29 19:40:53 5: SE7K: ParseResponse called from HandleResponse
2018.11.29 19:40:53 5: SE7K: HandleResponse now passing to logical device SE7K for parsing data
2018.11.29 19:40:53 5: SE7K: ParseObj called with data 5345374b, type h, adr 20, valuesLen 2, op read
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h20: reading=I_AC_Energie_year, unpack=n, expr=$val / 100, format=%.2f kWh, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 5345374b with n to 21317 hex 3231333137
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Energie_year, val=21317, expr=$val / 100
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 213.17
2018.11.29 19:40:53 5: SE7K: ParseObj for I_AC_Energie_year does sprintf with format %.2f kWh, value is 213.17
2018.11.29 19:40:53 5: SE7K: ParseObj for I_AC_Energie_year sprintf result is 213.17 kWh
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 213.17 kWh to I_AC_Energie_year
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h21
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h21: reading=I_AC_Energie_month, unpack=n, expr=$val / 100, format=%.2f kWh, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 374b with n to 14155 hex 3134313535
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Energie_month, val=14155, expr=$val / 100
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 141.55
2018.11.29 19:40:53 5: SE7K: ParseObj for I_AC_Energie_month does sprintf with format %.2f kWh, value is 141.55
2018.11.29 19:40:53 5: SE7K: ParseObj for I_AC_Energie_month sprintf result is 141.55 kWh
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 141.55 kWh to I_AC_Energie_month
2018.11.29 19:40:53 5: SE7K: HandleResponse got 2 readings from ParseObj for SE7K
2018.11.29 19:40:53 4: SE7K: ResponseDone, request: id 1, fCode 3, tid 72, type h, adr 20, len 2 for device SE7K reading I_AC_Energie_year, Current read buffer: 0048000000070103045345374b, Id 1, fCode 3, tid 72, response: id 1, fCode 3, type h, adr 20, len 2, value 5345374b
2018.11.29 19:40:53 5: SE7K: DropFrame - drop 0048000000070103045345374b
2018.11.29 19:40:53 5: SE7K: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2018.11.29 19:40:53 5: SE7K: ProcessRequestQueue called from HandleTimeout as queue:SE7K
2018.11.29 19:40:53 4: SE7K: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 19:40:53.471) for SE7K, rest 0.037, set timer to try again later
2018.11.29 19:40:53 5: SE7K: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.037 seconds
2018.11.29 19:40:53 5: SE7K: ProcessRequestQueue called from HandleTimeout as queue:SE7K
2018.11.29 19:40:53 5: SE7K: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 19:40:53.471) for SE7K, delay over
2018.11.29 19:40:53 5: SE7K: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 19:40:53.030) for SE7K, delay over
2018.11.29 19:40:53 5: SE7K: PackRequest called from ProcessRequestQueue
2018.11.29 19:40:53 4: SE7K: ProcessRequestQueue got pdu from PackRequest: 0300470025
2018.11.29 19:40:53 5: SE7K: PackFrame called from ProcessRequestQueue id 1, tid 251, pdu 0300470025
2018.11.29 19:40:53 4: SE7K: ProcessRequestQueue (V4.0.17 - 10.11.2018) sending, request: id 1, fCode 3, tid 251, type h, adr 71, len 37 for device SE7K reading I_AC_Strom, read buffer empty
2018.11.29 19:40:53 5: SW: 00fb00000006010300470025
2018.11.29 19:40:53 5: SE7K: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2018.11.29 19:40:53 5: SE7K: read buffer: 00fb0000004d01034a0000000000000000fffe000000000000092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002
2018.11.29 19:40:53 5: SE7K: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 251, dlen 77 and data 4a0000000000000000fffe000000000000092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002
2018.11.29 19:40:53 5: SE7K: HandleResponse called from Read
2018.11.29 19:40:53 5: SE7K: ParseResponse called from HandleResponse
2018.11.29 19:40:53 5: SE7K: HandleResponse now passing to logical device SE7K for parsing data
2018.11.29 19:40:53 5: SE7K: ParseObj called with data 0000000000000000fffe000000000000092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002, type h, adr 71, valuesLen 37, op read
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h71: reading=I_AC_Strom, unpack=n, expr=$val /ReadingsVal($name,"I_AC_Strom_SF",10)/10, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 0000000000000000fffe000000000000092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Strom, val=0, expr=$val /ReadingsVal($name,"I_AC_Strom_SF",10)/10
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 0 to I_AC_Strom
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h72
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h72
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h73
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h73
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h74
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h74
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h75
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h75: reading=I_AC_Strom_SF, unpack=n, expr=10 ** (65536 - $val), format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked fffe000000000000092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 65534 hex 3635353334
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Strom_SF, val=65534, expr=10 ** (65536 - $val)
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 100
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 100 to I_AC_Strom_SF
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h76
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h76
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h77
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h77
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h78
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h78
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h79
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h79: reading=I_L1_Spannung, unpack=n, expr=$val /10, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 2347 hex 32333437
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_L1_Spannung, val=2347, expr=$val /10
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 234.7
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 234.7 to I_L1_Spannung
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h80
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h80: reading=I_L2_Spannung, unpack=n, expr=$val /10, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 2353 hex 32333533
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_L2_Spannung, val=2353, expr=$val /10
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 235.3
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 235.3 to I_L2_Spannung
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h81
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h81: reading=I_L3_Spannung, unpack=n, expr=$val /10, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 0931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 2353 hex 32333533
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_L3_Spannung, val=2353, expr=$val /10
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 235.3
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 235.3 to I_L3_Spannung
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h82
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h82
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h83
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h83: reading=I_AC_Power_raw, unpack=n, expr=$val, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Power_raw, val=0, expr=$val
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 0 to I_AC_Power_raw
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h84
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h84: reading=I_AC_Power, unpack=n, expr=ReadingsVal($name,"I_AC_Power_raw",1) / (($val > 0) ? 10 ** (65536 - $val) : 1), format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 00001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Power, val=0, expr=ReadingsVal($name,"I_AC_Power_raw",1) / (($val > 0) ? 10 ** (65536 - $val) : 1)
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 0 to I_AC_Power
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h85
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h85: reading=I_AC_Frequenz, unpack=n, expr=$val /100, format=%.2f Hz, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 1387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 4999 hex 34393939
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Frequenz, val=4999, expr=$val /100
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 49.99
2018.11.29 19:40:53 5: SE7K: ParseObj for I_AC_Frequenz does sprintf with format %.2f Hz, value is 49.99
2018.11.29 19:40:53 5: SE7K: ParseObj for I_AC_Frequenz sprintf result is 49.99 Hz
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 49.99 Hz to I_AC_Frequenz
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h86
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h86
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h87
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h87
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h88
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h88
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h89
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h89
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h90
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h90
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h91
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h91
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h92
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h92
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h93
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h93: reading=I_AC_Energie, unpack=l>, expr=$val / 1000, format=%.2f kWh, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with l> to 8360407 hex 38333630343037
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Energie, val=8360407, expr=$val / 1000
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 8360.407
2018.11.29 19:40:53 5: SE7K: ParseObj for I_AC_Energie does sprintf with format %.2f kWh, value is 8360.407
2018.11.29 19:40:53 5: SE7K: ParseObj for I_AC_Energie sprintf result is 8360.41 kWh
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 8360.41 kWh to I_AC_Energie
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 2 to h95
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h95
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h96
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h96: reading=I_DC_Strom, unpack=n, expr=$val /ReadingsVal($name,"I_AC_Power_SF",10)/1000, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked ffff80000000ffff000000008000000080008000fffe0002 with n to 65535 hex 3635353335
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_DC_Strom, val=65535, expr=$val /ReadingsVal($name,"I_AC_Power_SF",10)/1000
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 6.5535
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 6.5535 to I_DC_Strom
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h97
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h97
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h98
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h98: reading=I_DC_Spannung, unpack=n, expr=$val /10, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 0000ffff000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_DC_Spannung, val=0, expr=$val /10
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 0 to I_DC_Spannung
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h99
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h99
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h100
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h100: reading=I_DC_Power_raw, unpack=n, expr=$val, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_DC_Power_raw, val=0, expr=$val
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 0 to I_DC_Power_raw
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h101
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h101: reading=I_DC_Power, unpack=n, expr=ReadingsVal($name,"I_DC_Power_raw",1) / (($val > 0) ? 10 ** (65536 - $val) : 1), format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 00008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_DC_Power, val=0, expr=ReadingsVal($name,"I_DC_Power_raw",1) / (($val > 0) ? 10 ** (65536 - $val) : 1)
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 0 to I_DC_Power
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h102
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h102
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h103
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h103: reading=Temperature, unpack=s>, expr=$val * (10 ** ReadingsNum ($name ,"I_Temp_SF",0)), format=%.2f ′C, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 000080008000fffe0002 with s> to 0 hex 30
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for Temperature, val=0, expr=$val * (10 ** ReadingsNum ($name ,"I_Temp_SF",0))
2018.11.29 19:40:53 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:53 5: SE7K: ParseObj for Temperature does sprintf with format %.2f ′C, value is 0
2018.11.29 19:40:53 5: SE7K: ParseObj for Temperature sprintf result is 0.00 ′C
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value 0.00 ′C to Temperature
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h104
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h104
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h105
2018.11.29 19:40:53 5: SE7K: ParseObj has no information about parsing h105
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h106
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h106: reading=I_Temp_SF, unpack=s>, expr=, format=, map=
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked fffe0002 with s> to -2 hex 2d32
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value -2 to I_Temp_SF
2018.11.29 19:40:53 5: SE7K: ParseObj moves to next object, skip 1 to h107
2018.11.29 19:40:53 5: SE7K: ParseObj ObjInfo for h107: reading=C_Status, unpack=n, expr=, format=, map=1:Aus, 2:Nachtmodus, 4:Betrieb
2018.11.29 19:40:53 5: SE7K: ParseObj unpacked 0002 with n to 2 hex 32
2018.11.29 19:40:53 5: SE7K: MapConvert called from ModbusLD_ParseObj converted 2 to Nachtmodus with map 1:Aus, 2:Nachtmodus, 4:Betrieb
2018.11.29 19:40:53 5: SE7K: ParseObj for C_Status maps value 2 to Nachtmodus with 1:Aus, 2:Nachtmodus, 4:Betrieb
2018.11.29 19:40:53 4: SE7K: ParseObj assigns value Nachtmodus to C_Status
2018.11.29 19:40:53 5: SE7K: HandleResponse got 16 readings from ParseObj for SE7K
2018.11.29 19:40:53 4: SE7K: ResponseDone, request: id 1, fCode 3, tid 251, type h, adr 71, len 37 for device SE7K reading I_AC_Strom, Current read buffer: 00fb0000004d01034a0000000000000000fffe000000000000092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002, Id 1, fCode 3, tid 251, response: id 1, fCode 3, type h, adr 71, len 37, value 0000000000000000fffe000000000000092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002
2018.11.29 19:40:53 5: SE7K: DropFrame - drop 00fb0000004d01034a0000000000000000fffe000000000000092b09310931ffff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002
2018.11.29 19:40:53 5: SE7K: StartQueueTimer called from Read removes internal timer because it is not needed now
2018.11.29 19:40:56 5: SE7K: GetUpdate called from ModbusLD_ControlSet
2018.11.29 19:40:56 5: SE7K: GetUpdate objects from attributes: h20 h100 h71 h103 h81 h126 h101 h107 h98 h106 h84 h75 h123 h85 h80 h93 h96 h83 h21 h79
2018.11.29 19:40:56 5: SE7K: GetUpdate full object list: h100 h101 h103 h106 h107 h123 h126 h20 h21 h71 h75 h79 h80 h81 h83 h84 h85 h93 h96 h98
2018.11.29 19:40:56 5: SE7K: GetUpdate check h100 => I_DC_Power_raw, poll = 1, last = 1543516853.66438
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_DC_Power_raw
2018.11.29 19:40:56 5: SE7K: GetUpdate check h101 => I_DC_Power, poll = 1, last = 1543516853.66945
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_DC_Power
2018.11.29 19:40:56 5: SE7K: GetUpdate check h103 => Temperature, poll = 1, last = 1543516853.67577
2018.11.29 19:40:56 4: SE7K: GetUpdate will request Temperature
2018.11.29 19:40:56 5: SE7K: GetUpdate check h106 => I_Temp_SF, poll = 1, last = 1543516853.68083
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_Temp_SF
2018.11.29 19:40:56 5: SE7K: GetUpdate check h107 => C_Status, poll = 1, last = 1543516853.68693
2018.11.29 19:40:56 4: SE7K: GetUpdate will request C_Status
2018.11.29 19:40:56 5: SE7K: GetUpdate check h123 => U_L1, poll = 1, last = 1543515232.81453
2018.11.29 19:40:56 4: SE7K: GetUpdate will request U_L1
2018.11.29 19:40:56 5: SE7K: GetUpdate check h126 => I_L1, poll = 1, last = 1543515232.81798
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_L1
2018.11.29 19:40:56 5: SE7K: GetUpdate check h20 => I_AC_Energie_year, poll = 1, last = 1543516853.47967
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_AC_Energie_year
2018.11.29 19:40:56 5: SE7K: GetUpdate check h21 => I_AC_Energie_month, poll = 1, last = 1543516853.48616
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_AC_Energie_month
2018.11.29 19:40:56 5: SE7K: GetUpdate check h71 => I_AC_Strom, poll = 1, last = 1543516853.59642
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_AC_Strom
2018.11.29 19:40:56 5: SE7K: GetUpdate check h75 => I_AC_Strom_SF, poll = 1, last = 1543516853.60363
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_AC_Strom_SF
2018.11.29 19:40:56 5: SE7K: GetUpdate check h79 => I_L1_Spannung, poll = 1, last = 1543516853.61099
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_L1_Spannung
2018.11.29 19:40:56 5: SE7K: GetUpdate check h80 => I_L2_Spannung, poll = 1, last = 1543516853.61612
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_L2_Spannung
2018.11.29 19:40:56 5: SE7K: GetUpdate check h81 => I_L3_Spannung, poll = 1, last = 1543516853.62096
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_L3_Spannung
2018.11.29 19:40:56 5: SE7K: GetUpdate check h83 => I_AC_Power_raw, poll = 1, last = 1543516853.6266
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_AC_Power_raw
2018.11.29 19:40:56 5: SE7K: GetUpdate check h84 => I_AC_Power, poll = 1, last = 1543516853.63171
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_AC_Power
2018.11.29 19:40:56 5: SE7K: GetUpdate check h85 => I_AC_Frequenz, poll = 1, last = 1543516853.6375
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_AC_Frequenz
2018.11.29 19:40:56 5: SE7K: GetUpdate check h93 => I_AC_Energie, poll = 1, last = 1543516853.6475
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_AC_Energie
2018.11.29 19:40:56 5: SE7K: GetUpdate check h96 => I_DC_Strom, poll = 1, last = 1543516853.65335
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_DC_Strom
2018.11.29 19:40:56 5: SE7K: GetUpdate check h98 => I_DC_Spannung, poll = 1, last = 1543516853.65891
2018.11.29 19:40:56 4: SE7K: GetUpdate will request I_DC_Spannung
2018.11.29 19:40:56 5: SE7K: GetUpdate tries to combine read commands
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Energie_year (h20) with I_AC_Energie_month (h21), span=2, max=50, drop read for h21
2018.11.29 19:40:56 5: SE7K: GetUpdate cant combine request for I_AC_Energie_year / h20 with I_AC_Strom / h71, span 52 > max 50
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Strom_SF (h75), span=5, max=50, drop read for h75
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_L1_Spannung (h79), span=9, max=50, drop read for h79
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_L2_Spannung (h80), span=10, max=50, drop read for h80
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_L3_Spannung (h81), span=11, max=50, drop read for h81
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Power_raw (h83), span=13, max=50, drop read for h83
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Power (h84), span=14, max=50, drop read for h84
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Frequenz (h85), span=15, max=50, drop read for h85
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_AC_Energie (h93), span=24, max=50, drop read for h93
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_DC_Strom (h96), span=26, max=50, drop read for h96
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_DC_Spannung (h98), span=28, max=50, drop read for h98
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_DC_Power_raw (h100), span=30, max=50, drop read for h100
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_DC_Power (h101), span=31, max=50, drop read for h101
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with Temperature (h103), span=33, max=50, drop read for h103
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with I_Temp_SF (h106), span=36, max=50, drop read for h106
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for I_AC_Strom (h71) with C_Status (h107), span=37, max=50, drop read for h107
2018.11.29 19:40:56 5: SE7K: GetUpdate cant combine request for I_AC_Strom / h71 with U_L1 / h123, span 53 > max 50
2018.11.29 19:40:56 5: SE7K: GetUpdate combines request for U_L1 (h123) with I_L1 (h126), span=4, max=50, drop read for h126
2018.11.29 19:40:56 5: SE7K: GetUpdate doesn't sort objList before sending requests
2018.11.29 19:40:56 5: SE7K: DoRequest called from ModbusLD_GetUpdate
2018.11.29 19:40:56 4: SE7K: DoRequest (called from ModbusLD_GetUpdate) created, request: id 1, fCode 3, tid 1, type h, adr 71, len 37 for device SE7K reading I_AC_Strom, read buffer empty
2018.11.29 19:40:56 5: SE7K: QueueRequest called from ModbusLD_DoRequest with h71, qlen 0
2018.11.29 19:40:56 5: SE7K: ProcessRequestQueue called from QueueRequest as direct:SE7K
2018.11.29 19:40:56 5: SE7K: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 19:40:53.589) for SE7K, delay over
2018.11.29 19:40:56 5: SE7K: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 19:40:53.579) for SE7K, delay over
2018.11.29 19:40:56 5: SE7K: PackRequest called from ProcessRequestQueue
2018.11.29 19:40:56 4: SE7K: ProcessRequestQueue got pdu from PackRequest: 0300470025
2018.11.29 19:40:56 5: SE7K: PackFrame called from ProcessRequestQueue id 1, tid 1, pdu 0300470025
2018.11.29 19:40:56 4: SE7K: ProcessRequestQueue (V4.0.17 - 10.11.2018) sending, request: id 1, fCode 3, tid 1, type h, adr 71, len 37 for device SE7K reading I_AC_Strom, read buffer empty
2018.11.29 19:40:56 5: SW: 000100000006010300470025
2018.11.29 19:40:56 5: SE7K: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2018.11.29 19:40:56 5: SE7K: DoRequest called from ModbusLD_GetUpdate
2018.11.29 19:40:56 4: SE7K: DoRequest (called from ModbusLD_GetUpdate) created, request: id 1, fCode 3, tid 226, type h, adr 20, len 2 for device SE7K reading I_AC_Energie_year, read buffer empty
2018.11.29 19:40:56 5: SE7K: QueueRequest called from ModbusLD_DoRequest with h20, qlen 0
2018.11.29 19:40:56 5: SE7K: StartQueueTimer called form QueueRequest sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2018.11.29 19:40:56 5: SE7K: DoRequest called from ModbusLD_GetUpdate
2018.11.29 19:40:56 4: SE7K: DoRequest (called from ModbusLD_GetUpdate) created, request: id 1, fCode 3, tid 19, type h, adr 123, len 4 for device SE7K reading U_L1, read buffer empty
2018.11.29 19:40:56 5: SE7K: QueueRequest called from ModbusLD_DoRequest with h123, qlen 1
2018.11.29 19:40:56 5: SE7K: StartQueueTimer called form QueueRequest has already set internal timer to call Modbus_ProcessRequestQueue in 0.996 seconds
2018.11.29 19:40:56 5: SE7K: read buffer: 00010000004d01034a0000000000000000fffe000000000000092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002
2018.11.29 19:40:56 5: SE7K: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 1, dlen 77 and data 4a0000000000000000fffe000000000000092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002
2018.11.29 19:40:56 5: SE7K: HandleResponse called from Read
2018.11.29 19:40:56 5: SE7K: ParseResponse called from HandleResponse
2018.11.29 19:40:56 5: SE7K: HandleResponse now passing to logical device SE7K for parsing data
2018.11.29 19:40:56 5: SE7K: ParseObj called with data 0000000000000000fffe000000000000092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002, type h, adr 71, valuesLen 37, op read
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h71: reading=I_AC_Strom, unpack=n, expr=$val /ReadingsVal($name,"I_AC_Strom_SF",10)/10, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 0000000000000000fffe000000000000092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Strom, val=0, expr=$val /ReadingsVal($name,"I_AC_Strom_SF",10)/10
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 0 to I_AC_Strom
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h72
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h72
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h73
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h73
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h74
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h74
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h75
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h75: reading=I_AC_Strom_SF, unpack=n, expr=10 ** (65536 - $val), format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked fffe000000000000092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 65534 hex 3635353334
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Strom_SF, val=65534, expr=10 ** (65536 - $val)
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 100
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 100 to I_AC_Strom_SF
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h76
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h76
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h77
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h77
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h78
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h78
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h79
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h79: reading=I_L1_Spannung, unpack=n, expr=$val /10, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 2347 hex 32333437
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_L1_Spannung, val=2347, expr=$val /10
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 234.7
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 234.7 to I_L1_Spannung
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h80
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h80: reading=I_L2_Spannung, unpack=n, expr=$val /10, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 2354 hex 32333534
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_L2_Spannung, val=2354, expr=$val /10
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 235.4
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 235.4 to I_L2_Spannung
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h81
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h81: reading=I_L3_Spannung, unpack=n, expr=$val /10, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 2350 hex 32333530
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_L3_Spannung, val=2350, expr=$val /10
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 235
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 235 to I_L3_Spannung
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h82
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h82
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h83
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h83: reading=I_AC_Power_raw, unpack=n, expr=$val, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Power_raw, val=0, expr=$val
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 0 to I_AC_Power_raw
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h84
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h84: reading=I_AC_Power, unpack=n, expr=ReadingsVal($name,"I_AC_Power_raw",1) / (($val > 0) ? 10 ** (65536 - $val) : 1), format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 00001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Power, val=0, expr=ReadingsVal($name,"I_AC_Power_raw",1) / (($val > 0) ? 10 ** (65536 - $val) : 1)
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 0 to I_AC_Power
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h85
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h85: reading=I_AC_Frequenz, unpack=n, expr=$val /100, format=%.2f Hz, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 1387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with n to 4999 hex 34393939
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Frequenz, val=4999, expr=$val /100
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 49.99
2018.11.29 19:40:56 5: SE7K: ParseObj for I_AC_Frequenz does sprintf with format %.2f Hz, value is 49.99
2018.11.29 19:40:56 5: SE7K: ParseObj for I_AC_Frequenz sprintf result is 49.99 Hz
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 49.99 Hz to I_AC_Frequenz
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h86
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h86
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h87
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h87
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h88
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h88
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h89
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h89
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h90
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h90
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h91
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h91
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h92
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h92
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h93
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h93: reading=I_AC_Energie, unpack=l>, expr=$val / 1000, format=%.2f kWh, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 007f91d70000ffff80000000ffff000000008000000080008000fffe0002 with l> to 8360407 hex 38333630343037
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Energie, val=8360407, expr=$val / 1000
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 8360.407
2018.11.29 19:40:56 5: SE7K: ParseObj for I_AC_Energie does sprintf with format %.2f kWh, value is 8360.407
2018.11.29 19:40:56 5: SE7K: ParseObj for I_AC_Energie sprintf result is 8360.41 kWh
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 8360.41 kWh to I_AC_Energie
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 2 to h95
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h95
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h96
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h96: reading=I_DC_Strom, unpack=n, expr=$val /ReadingsVal($name,"I_AC_Power_SF",10)/1000, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked ffff80000000ffff000000008000000080008000fffe0002 with n to 65535 hex 3635353335
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_DC_Strom, val=65535, expr=$val /ReadingsVal($name,"I_AC_Power_SF",10)/1000
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 6.5535
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 6.5535 to I_DC_Strom
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h97
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h97
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h98
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h98: reading=I_DC_Spannung, unpack=n, expr=$val /10, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 0000ffff000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_DC_Spannung, val=0, expr=$val /10
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 0 to I_DC_Spannung
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h99
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h99
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h100
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h100: reading=I_DC_Power_raw, unpack=n, expr=$val, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 000000008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_DC_Power_raw, val=0, expr=$val
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 0 to I_DC_Power_raw
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h101
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h101: reading=I_DC_Power, unpack=n, expr=ReadingsVal($name,"I_DC_Power_raw",1) / (($val > 0) ? 10 ** (65536 - $val) : 1), format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 00008000000080008000fffe0002 with n to 0 hex 30
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_DC_Power, val=0, expr=ReadingsVal($name,"I_DC_Power_raw",1) / (($val > 0) ? 10 ** (65536 - $val) : 1)
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 0 to I_DC_Power
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h102
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h102
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h103
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h103: reading=Temperature, unpack=s>, expr=$val * (10 ** ReadingsNum ($name ,"I_Temp_SF",0)), format=%.2f ′C, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 000080008000fffe0002 with s> to 0 hex 30
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for Temperature, val=0, expr=$val * (10 ** ReadingsNum ($name ,"I_Temp_SF",0))
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 0
2018.11.29 19:40:56 5: SE7K: ParseObj for Temperature does sprintf with format %.2f ′C, value is 0
2018.11.29 19:40:56 5: SE7K: ParseObj for Temperature sprintf result is 0.00 ′C
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 0.00 ′C to Temperature
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h104
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h104
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h105
2018.11.29 19:40:56 5: SE7K: ParseObj has no information about parsing h105
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h106
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h106: reading=I_Temp_SF, unpack=s>, expr=, format=, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked fffe0002 with s> to -2 hex 2d32
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value -2 to I_Temp_SF
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h107
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h107: reading=C_Status, unpack=n, expr=, format=, map=1:Aus, 2:Nachtmodus, 4:Betrieb
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 0002 with n to 2 hex 32
2018.11.29 19:40:56 5: SE7K: MapConvert called from ModbusLD_ParseObj converted 2 to Nachtmodus with map 1:Aus, 2:Nachtmodus, 4:Betrieb
2018.11.29 19:40:56 5: SE7K: ParseObj for C_Status maps value 2 to Nachtmodus with 1:Aus, 2:Nachtmodus, 4:Betrieb
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value Nachtmodus to C_Status
2018.11.29 19:40:56 5: SE7K: HandleResponse got 16 readings from ParseObj for SE7K
2018.11.29 19:40:56 4: SE7K: ResponseDone, request: id 1, fCode 3, tid 1, type h, adr 71, len 37 for device SE7K reading I_AC_Strom, Current read buffer: 00010000004d01034a0000000000000000fffe000000000000092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002, Id 1, fCode 3, tid 1, response: id 1, fCode 3, type h, adr 71, len 37, value 0000000000000000fffe000000000000092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002
2018.11.29 19:40:56 5: SE7K: DropFrame - drop 00010000004d01034a0000000000000000fffe000000000000092b0932092effff000000001387fffe000000000000000000000000007f91d70000ffff80000000ffff000000008000000080008000fffe0002
2018.11.29 19:40:56 5: SE7K: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2018.11.29 19:40:56 5: SE7K: ProcessRequestQueue called from HandleTimeout as queue:SE7K
2018.11.29 19:40:56 5: SE7K: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 19:40:56.406) for SE7K, delay over
2018.11.29 19:40:56 5: SE7K: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 19:40:56.363) for SE7K, delay over
2018.11.29 19:40:56 5: SE7K: PackRequest called from ProcessRequestQueue
2018.11.29 19:40:56 4: SE7K: ProcessRequestQueue got pdu from PackRequest: 0300140002
2018.11.29 19:40:56 5: SE7K: PackFrame called from ProcessRequestQueue id 1, tid 226, pdu 0300140002
2018.11.29 19:40:56 4: SE7K: ProcessRequestQueue (V4.0.17 - 10.11.2018) sending, request: id 1, fCode 3, tid 226, type h, adr 20, len 2 for device SE7K reading I_AC_Energie_year, read buffer empty
2018.11.29 19:40:56 5: SW: 00e200000006010300140002
2018.11.29 19:40:56 5: SE7K: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2018.11.29 19:40:56 5: SE7K: read buffer: 00e2000000070103045345374b
2018.11.29 19:40:56 5: SE7K: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 226, dlen 7 and data 045345374b
2018.11.29 19:40:56 5: SE7K: HandleResponse called from Read
2018.11.29 19:40:56 5: SE7K: ParseResponse called from HandleResponse
2018.11.29 19:40:56 5: SE7K: HandleResponse now passing to logical device SE7K for parsing data
2018.11.29 19:40:56 5: SE7K: ParseObj called with data 5345374b, type h, adr 20, valuesLen 2, op read
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h20: reading=I_AC_Energie_year, unpack=n, expr=$val / 100, format=%.2f kWh, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 5345374b with n to 21317 hex 3231333137
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Energie_year, val=21317, expr=$val / 100
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 213.17
2018.11.29 19:40:56 5: SE7K: ParseObj for I_AC_Energie_year does sprintf with format %.2f kWh, value is 213.17
2018.11.29 19:40:56 5: SE7K: ParseObj for I_AC_Energie_year sprintf result is 213.17 kWh
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 213.17 kWh to I_AC_Energie_year
2018.11.29 19:40:56 5: SE7K: ParseObj moves to next object, skip 1 to h21
2018.11.29 19:40:56 5: SE7K: ParseObj ObjInfo for h21: reading=I_AC_Energie_month, unpack=n, expr=$val / 100, format=%.2f kWh, map=
2018.11.29 19:40:56 5: SE7K: ParseObj unpacked 374b with n to 14155 hex 3134313535
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_AC_Energie_month, val=14155, expr=$val / 100
2018.11.29 19:40:56 5: SE7K: CheckEval for ModbusLD_ParseObj result is 141.55
2018.11.29 19:40:56 5: SE7K: ParseObj for I_AC_Energie_month does sprintf with format %.2f kWh, value is 141.55
2018.11.29 19:40:56 5: SE7K: ParseObj for I_AC_Energie_month sprintf result is 141.55 kWh
2018.11.29 19:40:56 4: SE7K: ParseObj assigns value 141.55 kWh to I_AC_Energie_month
2018.11.29 19:40:56 5: SE7K: HandleResponse got 2 readings from ParseObj for SE7K
2018.11.29 19:40:56 4: SE7K: ResponseDone, request: id 1, fCode 3, tid 226, type h, adr 20, len 2 for device SE7K reading I_AC_Energie_year, Current read buffer: 00e2000000070103045345374b, Id 1, fCode 3, tid 226, response: id 1, fCode 3, type h, adr 20, len 2, value 5345374b
2018.11.29 19:40:56 5: SE7K: DropFrame - drop 00e2000000070103045345374b
2018.11.29 19:40:56 5: SE7K: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2018.11.29 19:40:57 5: SE7K: ProcessRequestQueue called from HandleTimeout as queue:SE7K
2018.11.29 19:40:57 5: SE7K: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 19:40:56.901) for SE7K, delay over
2018.11.29 19:40:57 5: SE7K: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 19:40:56.889) for SE7K, delay over
2018.11.29 19:40:57 5: SE7K: PackRequest called from ProcessRequestQueue
2018.11.29 19:40:57 4: SE7K: ProcessRequestQueue got pdu from PackRequest: 03007b0004
2018.11.29 19:40:57 5: SE7K: PackFrame called from ProcessRequestQueue id 1, tid 19, pdu 03007b0004
2018.11.29 19:40:57 4: SE7K: ProcessRequestQueue (V4.0.17 - 10.11.2018) sending, request: id 1, fCode 3, tid 19, type h, adr 123, len 4 for device SE7K reading U_L1, read buffer empty
2018.11.29 19:40:57 5: SW: 0013000000060103007b0004
2018.11.29 19:40:57 5: SE7K: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2018.11.29 19:40:57 5: SE7K: read buffer: 00130000000b010308576174744e6f6465
2018.11.29 19:40:57 5: SE7K: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 19, dlen 11 and data 08576174744e6f6465
2018.11.29 19:40:57 5: SE7K: HandleResponse called from Read
2018.11.29 19:40:57 5: SE7K: ParseResponse called from HandleResponse
2018.11.29 19:40:57 5: SE7K: HandleResponse now passing to logical device SE7K for parsing data
2018.11.29 19:40:57 5: SE7K: ParseObj called with data 576174744e6f6465, type h, adr 123, valuesLen 4, op read
2018.11.29 19:40:57 5: SE7K: ParseObj ObjInfo for h123: reading=U_L1, unpack=n, expr=$val, format=, map=
2018.11.29 19:40:57 5: SE7K: ParseObj unpacked 576174744e6f6465 with n to 22369 hex 3232333639
2018.11.29 19:40:57 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for U_L1, val=22369, expr=$val
2018.11.29 19:40:57 5: SE7K: CheckEval for ModbusLD_ParseObj result is 22369
2018.11.29 19:40:57 4: SE7K: ParseObj assigns value 22369 to U_L1
2018.11.29 19:40:57 5: SE7K: ParseObj moves to next object, skip 1 to h124
2018.11.29 19:40:57 5: SE7K: ParseObj has no information about parsing h124
2018.11.29 19:40:57 5: SE7K: ParseObj moves to next object, skip 1 to h125
2018.11.29 19:40:57 5: SE7K: ParseObj has no information about parsing h125
2018.11.29 19:40:57 5: SE7K: ParseObj moves to next object, skip 1 to h126
2018.11.29 19:40:57 5: SE7K: ParseObj ObjInfo for h126: reading=I_L1, unpack=n, expr=$val, format=, map=
2018.11.29 19:40:57 5: SE7K: ParseObj unpacked 6465 with n to 25701 hex 3235373031
2018.11.29 19:40:57 5: SE7K: CheckEval for ModbusLD_ParseObj evaluates expr for I_L1, val=25701, expr=$val
2018.11.29 19:40:57 5: SE7K: CheckEval for ModbusLD_ParseObj result is 25701
2018.11.29 19:40:57 4: SE7K: ParseObj assigns value 25701 to I_L1
2018.11.29 19:40:57 5: SE7K: HandleResponse got 2 readings from ParseObj for SE7K

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 29 November 2018, 22:44:56
und so geht es dann weiter

2018.11.29 20:27:55 4: SE7K: SetUpdateTimer updated timer - will call GetUpdate in 300.0 seconds at 2018-11-29 20:32:55 - Interval 300
2018.11.29 20:29:55 4: 192.168.115.15:502 disconnected, waiting to reappear (SE7K)
2018.11.29 20:29:55 5: HttpUtils url=http://192.168.115.15:502/
2018.11.29 20:29:55 4: 192.168.115.15:502 reappeared (SE7K)
2018.11.29 20:29:55 4: SE7K: SetUpdateTimer updated timer - will call GetUpdate in 300.0 seconds at 2018-11-29 20:34:55 - Interval 300
2018.11.29 20:31:55 4: 192.168.115.15:502 disconnected, waiting to reappear (SE7K)
2018.11.29 20:31:55 5: HttpUtils url=http://192.168.115.15:502/
2018.11.29 20:31:55 4: 192.168.115.15:502 reappeared (SE7K)
2018.11.29 20:31:55 4: SE7K: SetUpdateTimer updated timer - will call GetUpdate in 300.0 seconds at 2018-11-29 20:36:55 - Interval 300
2018.11.29 20:33:55 4: 192.168.115.15:502 disconnected, waiting to reappear (SE7K)
2018.11.29 20:33:55 5: HttpUtils url=http://192.168.115.15:502/
2018.11.29 20:33:55 4: 192.168.115.15:502 reappeared (SE7K)
2018.11.29 20:33:55 4: SE7K: SetUpdateTimer updated timer - will call GetUpdate in 300.0 seconds at 2018-11-29 20:38:55 - Interval 300
2018.11.29 20:35:55 4: 192.168.115.15:502 disconnected, waiting to reappear (SE7K)
2018.11.29 20:35:55 5: HttpUtils url=http://192.168.115.15:502/
2018.11.29 20:35:55 4: 192.168.115.15:502 reappeared (SE7K)

sorry, die Zeichen je Post sind wohl limitiert.

LG
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 29 November 2018, 23:11:21
@Tom_S,

Versuche einfach mal das andere Modul. Ist ja nur eine Zeile, wenn es nicht geht kannst du es ja ganz einfach wieder rausnehmen.

Mit

update all https://raw.githubusercontent.com/pejonp/FHEM---SolarEdge/master/controls_SolarEdge.txt

kannst du es runterladen und danach ein "shutdown restart".

defmod SE7k-Test SolarEdge 1 60 ip:502 TCP

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 November 2018, 08:52:33
Hallo Tom,

ich glaube Du bist da über eine Art race condition im neuen Modul gestolpert.
Das bringe ich übers Wochenende in Ordnung.

Auf den ersten Blick sieht das so aus, als ob das neue Modbus-Basis-Modul beim Öffnen der Verbindung den Update-Timer neu setzt - in Deinem Fall auf 5 Minuten. Vorher beendet aber der Slave die Verbindung. Das Modul baut sie dann wieder auf, setzt aber den Timer neu auf 5 Minuten und vor Ablauf dieser 5 Minuten greift wieder ein Disconnect-Timer im Slave und beendet die Verbindung. Das geht dann immer so weiter ...

Sorry und Danke für's Testen, Update kommt :-)
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Dezember 2018, 10:23:33
Hallo,

ich habe gerade eine neue Version (4.0.18) von 98_Modbus.pm eingecheckt, die das Problem mit dem Update-Timer beheben sollte.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 02 Dezember 2018, 23:50:41
Ich werde es morgen testen und berichten.
Danke
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 03 Dezember 2018, 19:24:24
Ja oK. Es läuft.
nochmal Danke
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 09 Dezember 2018, 18:12:19
Hallo Stefan (denke mal als Entwickler bist du da die beste direkte Ansprechstelle),

TsTs, Angst abgelegt und einfach mal gemacht, was du geschrieben hast :D

Alle (die 2) H* gegen S> getauscht und funktioniert (zumindest ohne Fehlermeldungen beim starten).

Danke dir!


hier hatten wir ja gesprochen, aber so langsam wird mir klar, dass es wohl auch schon vor dem Update des Moduls das selbe (jetzt folgende) Problem gab, nur der Verbose-Wert ein anderer war für die entsprechende Fehlermeldung.

Ich bekomme, zu beachten: NUR WENN INTERNET DOWN, repetierend diese Fehlermeldung:

2018.12.09 12:25:40 3: Eastron: Timeout waiting for a modbus response, request: id 2, fCode 4, type i, adr 12, len 14 for device Xtender_AC_out reading Power__W, read buffer empty
2018.12.09 12:25:40 3: Eastron: read got new data while idle, drop buffer 02041c42fda3880000000000000000430926ea0000000000000000c250e707ee08
2018.12.09 12:25:51 3: Eastron: ResponseTimeout called, devhash=HASH(0x373c428), name of devhash=Xtender_AC_out
2018.12.09 12:25:51 3: Eastron: Timeout waiting for a modbus response, request: id 2, fCode 4, type i, adr 72, len 4 for device Xtender_AC_out reading Energy_import__kWh, read buffer empty
2018.12.09 12:25:51 3: Eastron: read got new data while idle, drop buffer 02040845cae03f00000000872f
2018.12.09 12:29:21 3: Eastron: ResponseTimeout called, devhash=HASH(0x359d220), name of devhash=Xtender_AC_in
2018.12.09 12:29:21 3: Eastron: Timeout waiting for a modbus response, request: id 1, fCode 4, type i, adr 12, len 2 for device Xtender_AC_in reading Power__W, read buffer empty
2018.12.09 12:29:21 3: Eastron: read got new data while idle, drop buffer 02040845cae050000000005326
2018.12.09 12:31:36 3: Eastron: ResponseTimeout called, devhash=HASH(0x373c428), name of devhash=Xtender_AC_out
2018.12.09 12:31:36 3: Eastron: Timeout waiting for a modbus response, request: id 2, fCode 4, type i, adr 72, len 4 for device Xtender_AC_out reading Energy_import__kWh, read buffer empty
2018.12.09 12:31:36 3: Eastron: read got new data while idle, drop buffer 02040845cae05800000000b2e7
2018.12.09 12:45:37 3: Eastron: ResponseTimeout called, devhash=HASH(0x373c428), name of devhash=Xtender_AC_out
2018.12.09 12:45:37 3: Eastron: Timeout waiting for a modbus response, request: id 2, fCode 4, type i, adr 344, len 2 for device Xtender_AC_out reading Energy_total__kVArh, read buffer empty
2018.12.09 13:09:09 3: Eastron: ResponseTimeout called, devhash=HASH(0x373c428), name of devhash=Xtender_AC_out
2018.12.09 13:09:09 3: Eastron: Timeout waiting for a modbus response, request: id 2, fCode 4, type i, adr 72, len 4 for device Xtender_AC_out reading Energy_import__kWh, read buffer empty
2018.12.09 13:09:09 3: Eastron: read got new data while idle, drop buffer 020404450742105d25
2018.12.09 13:29:49 3: Eastron: ResponseTimeout called, devhash=HASH(0x373c428), name of devhash=Xtender_AC_out
2018.12.09 13:29:49 3: Eastron: Timeout waiting for a modbus response, request: id 2, fCode 4, type i, adr 12, len 2 for device Xtender_AC_out reading Power__W, read buffer empty
2018.12.09 13:29:49 3: Eastron: read got new data while idle, drop buffer 02040442fab8c94e9b
2018.12.09 13:37:28 3: Eastron: ResponseTimeout called, devhash=HASH(0x373c428), name of devhash=Xtender_AC_out
2018.12.09 13:37:28 3: Eastron: Timeout waiting for a modbus response, request: id 2, fCode 4, type i, adr 6, len 8 for device Xtender_AC_out reading Current__A, read buffer empty
2018.12.09 13:37:28 3: Eastron: read got new data while idle, drop buffer 0204103f1eec70000000000000000042fb0434ea02
2018.12.09 13:39:48 3: Eastron: ResponseTimeout called, devhash=HASH(0x373c428), name of devhash=Xtender_AC_out
2018.12.09 13:39:48 3: Eastron: Timeout waiting for a modbus response, request: id 2, fCode 4, type i, adr 12, len 2 for device Xtender_AC_out reading Power__W, read buffer empty
2018.12.09 13:39:48 3: Eastron: read got new data while idle, drop buffer 02040442fc507820ee

Das selbe Problem (fhem "hängt" und die Daten kommen nicht an) übrigens mit meinem Homematic-HMLAN, aber das ist eine andere Baustelle. Nur zur Info.

Ist Modbus 100% NonBlocking? Wieso tritt dieser Fehler immer nur auf wenn mein Internet down ist? Oder umgedreht, kann es sein, dass ein anderes Modul blockt und das nur die Auswirkungen sind?

lieb Gruß
H.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Dezember 2018, 20:26:57
Hallo Holle,

das Modbus-Modul ist komplett asynchron, solange Du keine get-Befehle verwendest, bei denen auf eine Antwort gewartet werden muss.
Was eventuell noch blocken könnte, sind Namensauflösungen.

Im Log sieht es so aus, als ob der Timeout zuschlägt und direkt danach die Daten ankommen und nicht mehr verarbeitet werden können, da der zugehörige Request bereits in den Timeout gelaufen ist.

Probier doch mal verbose auf 5 zu setzen und dann die Internet-Verbindung zu trennen, so dass wir im Log sehen, was tatsächlich passiert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Dezember 2018, 21:59:55
Hallo Stefan und Danke für die Rückmeldung. Bin im Moment nicht vor Ort, melde mich aber, sobald ich wieder sinnvoll rankomme.

Grüße!
H.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: elektro_rainer am 11 Dezember 2018, 09:42:38
Hallo zusammen,
Anfängerfrage:
in der alten Version hatte ich folgende Definition: "define modbus Modbus 192.168.xxx.xxx:502 tcp"
auf dieses Interface hat das ModbusTrovis Modul mit: "define modbustrovis ModbusTrovis5576 222 60 TCP"
zugegriffen, lief alles ohne Probleme.
Nach meinem letztem Update ist das modbus device einfach weg.
Ein neues modbus device mit: "define modbus Modbus IP adresse" krieg ich nicht definiert......
Ein neues modbus device mit: "define modbus ModbusAttr slave 10 60 192.168.xxx.xxx:502 TCP" steht zwar auf opened aber das modbusTrovis Modul bekommt keine Daten.
Hat jemand eine kreative Idee??

Danke und Grüße,
Rainer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Dezember 2018, 23:06:52
Hallo Rainer,
in der alten Version hatte ich folgende Definition: "define modbus Modbus 192.168.xxx.xxx:502 tcp"
auf dieses Interface hat das ModbusTrovis Modul mit: "define modbustrovis ModbusTrovis5576 222 60 TCP"
zugegriffen, lief alles ohne Probleme.
Das klingt für mich nach einem Missverständnis. Auch in den älteren Versionen des Modbus-Moduls haben Fhem-Geräte Verbindungen per Modbus-TCP direkt aufgebaut. Nur bei Verbindungen über eine serielle Schnittstelle war und ist ein physisches Modbus-Fhem-Gerät nötig. Dein erstes "define modbus ..." war meiner Meinung nach immer schon sinnlos.

Zitat
Nach meinem letztem Update ist das modbus device einfach weg.
In der neuen Version musste ich das Parsen der define-Befehle im Modbus-Modul umbauen. Vermutlich ist das alte und überflüssige Gerät deshalb weg weil es jetzt korrekterweise eine Fehlermeldung erzeugt.
Mit der Funktion des ModbusTrovis-Moduls sollte das aber nichts zu tun haben.
Zitat
Ein neues modbus device mit: "define modbus Modbus IP adresse" krieg ich nicht definiert......
Das ist auch gut so, so ein Device macht auch keinen Sinn. :-)
Zitat
Ein neues modbus device mit: "define modbus ModbusAttr slave 10 60 192.168.xxx.xxx:502 TCP" steht zwar auf opened aber das modbusTrovis Modul bekommt keine Daten.
Das wäre dann ein Modbus-Slave, der Anfagen von anderen Geräten im Netzwerk entgegen nehmen kann. Aber das ist etwas ganz anderes als das was du suchst ...

Zitat
Hat jemand eine kreative Idee??

Ich möchte nicht ausschließen, dass die neue Version des Modbus-Moduls ein Problem mit dem ModbusTrovis-Modul erzeugt. Um das zu klären könntest Du zunächst testweise wieder das alte Modbus-Modul einspielen. Wenn es damit funktioniert und mit dem neuen nicht, dann könntest Du das Attribut verbose für das Modbus-Trovis-Gerät auf 5 setzen und dann das Protokoll posten.
Daran kann ich dann hoffentlich erkennen, wo das Problem liegt.

Vielleicht lesen ja auch andere Anwender des Modbus-Trovis-Moduls mit und können berichten ob es bei Ihnen auch Probleme gibt ...

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: elektro_rainer am 12 Dezember 2018, 08:29:19
Hallo Stefan,

das modbus Modul ist Voraussetzung das das ModbusTrovis Modul läuft:
https://fhem.de/commandref_DE.html#ModbusTrovis5576
Vielleicht noch eine Ergänzung: FHEM spricht mit einem Modbus Gateway über IP zu meinem Trovis Regler.

Wie kommen wir nun weiter?

Danke und Grüße,
Rainer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Reinerlein am 12 Dezember 2018, 18:51:59
Hallo Stefan, hallo Rainer,

also ich habe das bei mir über eine serielle Schnittstelle laufen, und dementsprechend zwei Devices wie folgt definiert:
define modbus Modbus /dev/serial0@19200

define hwr_Heizungsanlage ModbusTrovis5576 240 300

Das funktioniert immer noch, zumindest mit folgender Version: Modbus 4.0.18 - 1.12.2018.
Es kommt nur eine Fehlermeldung, dass er ein Mapping nicht auflösen kann (weil bei einem Register plötzlich eine unerwartete "0" kommt). Das habe ich bei mir schon mal korrigiert, und beobachte es gerade... 

Grüße
Reiner
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Dezember 2018, 21:27:22
Hallo Rainer, hallo Reiner,

wenn es über RS485 funktioniert, sollte es auch über Modbus TCP weiterhin funktionieren. Vielen Dank für's Testen!
Bei RS485 oder RS232 ist ein Device vom Typ Modbus nötig, bei Verbindungen über Modbus TCP sollte das nicht der Fall sein.
Das Trovis-Modul sorgt selbst dafür, dass 98_Modbus.pm geladen wird.

Hintergrund ist der, dass bei Modbus TCP jedes Device eine eigene TCP-Verbindung öffnet und verwaltet. Bei RS485 / RS232 könnten mehrere Fhem-Geräte über die gleiche Schnittstelle kommunizieren wollen. Damit das kein Problem wird, gibt es das physische Modbus-Device in Fhem und die logischen Geräte verwenden dieses als IO-Device.

Für die Fehlersuche würde ich vorschlagen, verbose auf 5 zu setzen und dann das Log zu posten. Dann sollten wir sehen was tatsächlich passiert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: elektro_rainer am 14 Dezember 2018, 09:42:51
Hallo Stefan,

wo und wie definiere ich die IP von meinem Gateway?

Danke und Grüße,
Rainer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 14 Dezember 2018, 14:52:22
Hallo Rainer,

die Syntax bei Modulen auf Basis von 98_Modbus.pm ist typischerweise identisch mit der Syntax von ModbusAttr.
Im Prinzip kann man sich die gerätespezifischen Modbus-Module wie ein ModbusAttr mit eingebauten Registerdefinitionen vorstellen.
Entsprechend kann man Register oder Details zur Ausgabe mit den Attributen wie sie in der Doku zu ModbusAttr stehen überschreiben.
Langer Rede kurzer Sinn:
Zitat
define WP ModbusAttr 5 60 192.168.1.122:502 TCP
to talk Modbus TCP to a device with IP-Address 192.168.1.122 and the reserved port for Modbus TCP 502
Note that for Modbus over a TCP connection you don't need a basic Modbus device for the interface like ModbusLine above.
so steht es in der Doku zu ModbusAttr.
In Deinem Fall ist die IP-Adresse nicht die des Geräts (das hat ja keine sondern spricht Modbus-RTU) sondern die des Gateways:
define modbustrovis ModbusTrovis5576 222 60 192.168.1.x:502 TCP

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: elektro_rainer am 17 Dezember 2018, 08:36:05
Hallo Stefan,

danke für Deine Antwort,... genauso funktioniert's!

Vielen Dank!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 10 Januar 2019, 14:03:00
Hi Stefan,
einen Nutzer von dem 98_Fronius_Modbus.pm Modul ist folgende Warnung aufgefallen:
2019.01.01 13:58:16 3: Wechselrichter: MapConvert called from ModbusLD_ParseObj did not find 0 in map 1:aus, 2:AutoShutdown, 3:startet, 4:Normalbetrieb, 5:Leistungsreduktion, 6:abschalten, 7:Fehler, 8:Standby
Nun ist 0 bei Fronius nicht als Status definiert.
Kann man die Fehlermeldung unterdrücken/abstellen?

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Reinerlein am 10 Januar 2019, 17:00:07
Hi Roger,

ich habe das auch in meinem Trovis-Modul festgestellt, und erstmal einfach ein Mapping für die 0 angegeben.

Das ist erst mit einer neuen Version irgendwann reingekommen. Anscheinend wird da etwas in der falschen Reihenfolge ausgewertet, da ich im Reading niemals diese 0 zu sehen bekomme...

Grüße
Reinerlein
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Januar 2019, 17:10:21
Hallo,

ich könnte das LogLevel für diese Meldung generell auf 4 oder 5 erhöhen.
Andererseits wäre es interessant zu sehen, wie die Situation entsteht.
Wenn es sich also reproduzieren lässt, würde ich mich über ein Log mit Verbose 5 freuen :-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Januar 2019, 18:08:40
Hallo,

anbei eine neue Version zum Testen.
Man kann jetzt auch dev-x-defSet, dev-x-defHint sowie
dev-type-[A-Za-z0-9_]+-hint  und dev-type-[A-Za-z0-9_]+-set verwenden

Wenn keine Beschwerden kommen, würde ich es demnächst einchecken :-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 29 Januar 2019, 21:36:03
Hallo Stefan!
die neue Version läuft bei mir Ralais Lüftung und Thermostate wie gewohnt.

Aber ich hab unabhängig eine Frage. Seit geraumer Zeit habe ich immer wieder Timeoutfehler.
Meldung: Timeout waiting for a modbus response in ReadAnswer
Zu 90%Meistens schaltet er aber korrekt.
Welches attr kann ich da einsetzen.
lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Januar 2019, 21:53:01
Hallo Wolfgang,

Da würde ich zunächst nach der Ursache forschen.
Ein Log-Auszug bei verbose 5 wenn gerade ein Timout kommt, wäre hilfreich.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 29 Januar 2019, 21:57:05
Hallo Stefan,

habe mal die neuen Module installiert. Werde testen und berichten.

Ein Frage habe ich aber noch. Wie kann ich die Abfrage von Reg nur einmal täglich machen. Bei meinem SolarEdge-Modul sind ja einige Reg nicht veränderlich. Die brauchen eigentlich nur einmal am Tag oder bei Neustart ausgelesen werden.

C_DeviceAddress  3 2019-01-29 21:51:59
C_Manufacturer    SolarEdge 2019-01-29 21:51:59
C_Model                SE5K 2019-01-29 21:51:59
C_SerialNumber    7E1820EA 2019-01-29 21:51:59
C_SunSpec_DID    Dreiphasig 2019-01-29 21:51:59
C_SunSpec_ID      SunS 2019-01-29 21:51:59
C_Version              0002.1053 2019-01-29 21:51:59

Definition ist so.

"type-VT_String" =>  { 
        'decode' => 'cp850',
        'encode' => 'utf8',
        'expr' => '$val =~ s/[\00]+//gr',
        'len' => '8',
        'revRegs' => '0',
        'unpack' => 'a16',
    },
....

"h40000" =>  {  # 40001 2 C_SunSpec_ID uint32 Wert = "SunS" (0x53756e53). Identifiziert dies eindeutig als eine SunSpec Modbus-Karte
                                   'len' => '2',
                               'reading' => 'C_SunSpec_ID',
                               'revRegs' => '0',
                                'unpack' => 'a4',
                               'defPoll' => '0',
                       },
          "h40004" =>  { # 40005 16 C_Hersteller String(32) Bei SunSpec eingetragener Wert = " SolarEdge "
                               'reading' => 'C_Manufacturer',
                                  'type' => 'VT_String',
                               'defPoll' => '0',
                       },
          "h40020" =>  {       'reading' => 'Block_C_Model',
                                  'type' => 'VT_String',
                               'defPoll' => '0',
                                  'expr' => 'ExprMppt($hash,$name,"C_Model",$val[0],0,0,0,0)', # conversion of raw value to visible value
                       },
          "h40044" =>  {       'reading' => 'C_Version',
                                  'type' => 'VT_String',
                               'defPoll' => '0',
                       },
          "h40052" =>  {       'reading' => 'C_SerialNumber',
                                  'type' => 'VT_String',
                               'defPoll' => '0',
                       },
          "h40068" =>  { #
                      'reading'  => 'C_DeviceAddress',
                               'defPoll' => '0',
                       },
          "h40069" => { # 40070 1 C_SunSpec_DID uint16 101 = Einphasig 102 = Spaltphase1 103 = Dreiphasig
                      'reading' => 'C_SunSpec_DID', # name of the reading for this value
                          'len' => '1' ,
                                  'map' => '101:Einphasig, 102:Spaltphase1, 103:Dreiphasig',
                              'defPoll' => '0',
                },


Gruß Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 29 Januar 2019, 22:08:46
Hallo Stefan!

Hier einige Meldungen.2019.01.29 21:58:56 3: VR400Mod: Timeout waiting for a modbus response, request: id 1, fCode 3, type h, adr 800, len 1 for device Alarms reading REG_ALARMS_ALL, read buffer empty
2019.01.29 21:58:56 3: Zaehler: Timeout waiting for a modbus response, request: id 16, fCode 3, type h, adr 9, len 1 for device Birgit_Soll reading temperature, read buffer empty

2019.01.29 22:00:42 5: Zaehler: QueueRequest called from ModbusLD_DoRequest with c1, qlen 1
2019.01.29 22:00:42 5: Zaehler: StartQueueTimer called form QueueRequest has already set internal timer to call Modbus_ProcessRequestQueue in 0.991 seconds
2019.01.29 22:00:42 5: Zaehler: read buffer: 100302000ac440
2019.01.29 22:00:42 5: Zaehler: ParseFrameStart (RTU) extracted id 16, fCode 3 and data 02000a
2019.01.29 22:00:42 5: Zaehler: HandleResponse called from Read
2019.01.29 22:00:42 5: Zaehler: ParseResponse called from HandleResponse
2019.01.29 22:00:42 5: Zaehler: CheckChecksum (called from HandleResponse): c440 is valid
2019.01.29 22:00:42 5: Zaehler: HandleResponse now passing to logical device Birgit_Soll for parsing data
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj called with data 000a, type h, adr 9, valuesLen 1, op read
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj ObjInfo for h9: reading=temperature, unpack=n, expr=$val/2, format=%.1f, map=
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj unpacked 000a with n to 10 hex 3130
2019.01.29 22:00:42 5: Birgit_Soll: CheckEval for ModbusLD_ParseObj evaluates expr for temperature, val=10, expr=$val/2
2019.01.29 22:00:42 5: Birgit_Soll: CheckEval for ModbusLD_ParseObj result is 5
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj for temperature does sprintf with format %.1f, value is 5
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj for temperature sprintf result is 5.0
2019.01.29 22:00:42 4: Birgit_Soll: ParseObj assigns value 5.0 to temperature


lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 29 Januar 2019, 22:12:23
Hallo Stefan!
Ich hab das auch wenn ich nichts ändere. DH auch beim auslesen dürfte hier ein Timingproblem vorliegen.
lg
Wolfgang

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 Januar 2019, 19:52:13
Hallo Wolfgang,

In Deinem Log-Ausschnitt kommt der Fehler als erstes, danach scheinen einige Zeilen zu fehlen und dann kommt ein erfolgreicher Request.
Um die Herkunft des Fehler zu sehen, bräuchte ich mehr Kontext, vor allem was vor dem Fehler passiert.
Bitte poste doch noch einen ungekürzten Log-Auszug beginnend mindestens 4 Sekunden vor der Fehlermeldung.

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 Januar 2019, 19:59:51
Halo Jörg,

um Objekte seltener, nur täglich oder sogar nur einmal nach einem Neustart zu lesen, kann man pollDelay setzen.

Die Erläuterungen zu solchen Dingen sollten immer bei ModbusAttr stehen:
Zitat
obj-[cdih][1-9][0-9]*-polldelay
this applies only to master mode. It allows to poll objects at a lower rate than the interval specified in the define command. You can either specify a time in seconds or number prefixed by "x" which means a multiple of the interval of the define command.
If you specify a normal numer then it is interpreted as minimal time between the last read and another automatic read.
Please note that this does not create an additional interval timer. Instead the normal interval timer defined by the interval of the define command will check if this reading is due or not yet. So the effective interval will always be a multiple of the interval of the define.

was in der Doku aber fehlt (shame on me) ist dass man pollDelay auch auf once stellen kann.
Dann wird das Objekt nur einmal nach dem Start abgefragt.
Ich habe es gerade in der Doku ergänzt. Beim nächsten Einchecken ist es dann drin ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 30 Januar 2019, 21:19:10
Hallo Stefan!

Hier der logauszug
2019.01.30 21:14:26 5: VR400Mod: HandleResponse got 1 readings from ParseObj for Soll_WZ
2019.01.30 21:14:26 4: VR400Mod: ResponseDone, request: id 2, fCode 3, type h, adr 523, len 1 for device Soll_WZ reading Sollof, Current read buffer: 020302ff6a3d9b, Id 2, fCode 3, response: id 2, fCode 3, type h, adr 523, len 1, value ff6a
2019.01.30 21:14:26 5: VR400Mod: DropFrame - drop 020302ff6a3d9b
2019.01.30 21:14:26 5: VR400Mod: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2019.01.30 21:14:26 5: Wolfgang_Soll: GetUpdate called from HandleTimeout
2019.01.30 21:14:26 5: Wolfgang_Soll: SetartUpdateTimer called from ModbusLD_GetUpdate updated timer, will call GetUpdate in 5.0 sec at 2019-01-30 21:14:31, interval 5
2019.01.30 21:14:26 5: Wolfgang_Soll: GetUpdate objects from attributes: h9
2019.01.30 21:14:26 5: Wolfgang_Soll: GetUpdate full object list: h9
2019.01.30 21:14:26 5: Wolfgang_Soll: GetUpdate check h9 => temperature, poll = 1, last = 1548879263.65399
2019.01.30 21:14:26 4: Wolfgang_Soll: GetUpdate will request temperature
2019.01.30 21:14:26 5: Wolfgang_Soll: GetUpdate tries to combine read commands
2019.01.30 21:14:26 5: Wolfgang_Soll: GetUpdate doesn't sort objList before sending requests
2019.01.30 21:14:26 4: Wolfgang_Soll: DoRequest called from ModbusLD_GetUpdate created, request: id 18, fCode 3, type h, adr 9, len 1 for device Wolfgang_Soll reading temperature, read buffer empty
2019.01.30 21:14:26 5: Zaehler: QueueRequest called from ModbusLD_DoRequest with h9, qlen 17
2019.01.30 21:14:26 5: Zaehler: StartQueueTimer called form QueueRequest has already set internal timer to call Modbus_ProcessRequestQueue in 0.537 seconds
2019.01.30 21:14:26 5: VR400Mod: ProcessRequestQueue called from HandleTimeout as queue:VR400Mod
2019.01.30 21:14:26 4: VR400Mod: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 21:14:26.589) for Soll_WZ, rest 0.080, set timer to try again later
2019.01.30 21:14:26 5: VR400Mod: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.080 seconds
2019.01.30 21:14:26 4: Connection accepted from WEB_192.168.26.200_54961
2019.01.30 21:14:26 4: WEB_192.168.26.200_54961 POST /fhem?cmd=set%20Birgit_Aktiv%20Aktiv%20Ein&XHR=1&fwcsrf=csrf_448301314370321&fw_id=907; BUFLEN:0
2019.01.30 21:14:26 5: Cmd: >set Birgit_Aktiv Aktiv Ein<
2019.01.30 21:14:26 5: Birgit_Aktiv: set called with Aktiv (h0) setVal = Ein
2019.01.30 21:14:26 5: Birgit_Aktiv: MapConvert called from ModbusLD_Set converted Ein to 165 with reversed map Aus:90, Ein:165,
2019.01.30 21:14:26 5: Birgit_Aktiv: set converted Ein to 165 using map 90:Aus,165:Ein
2019.01.30 21:14:26 5: Birgit_Aktiv: set packed hex 313635 with n to hex 00a5
2019.01.30 21:14:26 4: Birgit_Aktiv: DoRequest called from ModbusLD_Set created, request: id 16, fCode 6, type h, adr 0, len 1, value 00a5 for device Birgit_Aktiv reading Aktiv, read buffer empty
2019.01.30 21:14:26 5: Zaehler: QueueRequest called from ModbusLD_DoRequest with h0, qlen 18
2019.01.30 21:14:26 5: Zaehler: ProcessRequestQueue called from QueueRequest as direct:Zaehler, force
2019.01.30 21:14:26 5: Zaehler: ProcessRequestQueue called from QueueRequest returns, Fhem is still waiting for response, qlen 19, try again in 1 seconds
2019.01.30 21:14:26 5: Zaehler: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.01.30 21:14:26 5: Zaehler: ReadAnswer called from ModbusLD_Set
2019.01.30 21:14:26 5: Zaehler: ReadAnswer called and remaining timeout is 0.467666149139404
2019.01.30 21:14:27 3: Zaehler: Timeout waiting for a modbus response in ReadAnswer, request: id 3, fCode 1, type c, adr 2, len 1 for device R2 reading Relais2, read buffer empty
2019.01.30 21:14:27 5: Zaehler: DropFrame - drop
2019.01.30 21:14:27 5: Zaehler: StartQueueTimer called form ReadAnswerTimeout sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2019.01.30 21:14:27 4: WEB: /fhem?cmd=set%20Birgit_Aktiv%20Aktiv%20Ein&XHR=1&fwcsrf=csrf_448301314370321&fw_id=907 / RL:72 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.01.30 21:14:27 5: VR400Mod: ProcessRequestQueue called from HandleTimeout as queue:VR400Mod
2019.01.30 21:14:27 5: VR400Mod: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 21:14:26.589) for Soll_WZ, delay over
2019.01.30 21:14:27 5: VR400Mod: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 21:14:26.553) for Soll_WZ, delay over
2019.01.30 21:14:27 5: VR400Mod: PackRequest called from ProcessRequestQueue
2019.01.30 21:14:27 4: VR400Mod: ProcessRequestQueue got pdu from PackRequest: 0301040001
2019.01.30 21:14:27 5: VR400Mod: PackFrame called from ProcessRequestQueue id 2, pdu 0301040001
2019.01.30 21:14:27 4: VR400Mod: ProcessRequestQueue (V4.0.20 - 29.1.2019) sending, request: id 2, fCode 3, type h, adr 260, len 1 for device Soll_WZ reading TemperaturSoll, read buffer empty
2019.01.30 21:14:27 5: SW: 020301040001c404
2019.01.30 21:14:27 5: VR400Mod: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.01.30 21:14:27 5: Zaehler: ProcessRequestQueue called from HandleTimeout as queue:Zaehler
2019.01.30 21:14:27 5: Zaehler: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 21:14:23.727) for Birgit_Aktiv, delay over
2019.01.30 21:14:27 5: Zaehler: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 21:14:23.702) for Birgit_Aktiv, delay over
2019.01.30 21:14:27 5: Zaehler: PackRequest called from ProcessRequestQueue
2019.01.30 21:14:27 4: Zaehler: ProcessRequestQueue got pdu from PackRequest: 06000000a5
2019.01.30 21:14:27 5: Zaehler: PackFrame called from ProcessRequestQueue id 16, pdu 06000000a5
2019.01.30 21:14:27 4: Zaehler: ProcessRequestQueue (V4.0.20 - 29.1.2019) sending, request: id 16, fCode 6, type h, adr 0, len 1, value 00a5 for device Birgit_Aktiv reading Aktiv, read buffer empty
2019.01.30 21:14:27 5: SW: 1006000000a54af0
2019.01.30 21:14:27 5: Zaehler: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.01.30 21:14:27 5: Zaehler: read buffer: 1006000000a54af0
2019.01.30 21:14:27 5: Zaehler: ParseFrameStart (RTU) extracted id 16, fCode 6 and data 000000a5
2019.01.30 21:14:27 5: Zaehler: HandleResponse called from Read
2019.01.30 21:14:27 5: Zaehler: ParseResponse called from HandleResponse
2019.01.30 21:14:27 5: Zaehler: CheckChecksum (called from HandleResponse): 4af0 is valid
2019.01.30 21:14:27 5: Zaehler: HandleResponse now passing to logical device Birgit_Aktiv for parsing data
2019.01.30 21:14:27 5: Birgit_Aktiv: ParseObj called with data 00a5, type h, adr 0, valuesLen 1, op write
2019.01.30 21:14:27 5: Birgit_Aktiv: ParseObj ObjInfo for h0: reading=Aktiv, unpack=n, expr=, format=, map=90:Aus,165:Ein
2019.01.30 21:14:27 5: Birgit_Aktiv: ParseObj unpacked 00a5 with n to 165 hex 313635
2019.01.30 21:14:27 5: Birgit_Aktiv: MapConvert called from ModbusLD_ParseObj converted 165 to Ein with map 90:Aus,165:Ein
2019.01.30 21:14:27 5: Birgit_Aktiv: ParseObj for Aktiv maps value 165 to Ein with 90:Aus,165:Ein
2019.01.30 21:14:27 4: Birgit_Aktiv: ParseObj assigns value Ein to Aktiv
2019.01.30 21:14:27 5: Starting notify loop for Birgit_Aktiv, 1 event(s), first is Aktiv: Ein
2019.01.30 21:14:27 4: dewpoint_notify: cmd_type=dewpoint devname=Birgit_Aktiv dewname=Taupunkt1, dev=Birgit_Aktiv, dev_regex=.* temp_name=temperature hum_name=humidity
2019.01.30 21:14:27 5: dewpoint_notify: s='Aktiv: Ein'
2019.01.30 21:14:27 5: dewpoint_notify: evName='Aktiv:' val=Ein'
2019.01.30 21:14:27 5: dewpoint max_timediff=1
2019.01.30 21:14:27 4: dewpoint_notify: cmd_type=dewpoint devname=Birgit_Aktiv dewname=Taupunkt2, dev=Birgit_Aktiv, dev_regex=.* temp_name=T hum_name=H
2019.01.30 21:14:27 5: dewpoint_notify: s='Aktiv: Ein'
2019.01.30 21:14:27 5: dewpoint_notify: evName='Aktiv:' val=Ein'
2019.01.30 21:14:27 5: dewpoint max_timediff=1
2019.01.30 21:14:27 5: End notify loop for Birgit_Aktiv
2019.01.30 21:14:27 5: Zaehler: HandleResponse got 1 readings from ParseObj for Birgit_Aktiv
2019.01.30 21:14:27 4: Zaehler: ResponseDone, request: id 16, fCode 6, type h, adr 0, len 1, value 00a5 for device Birgit_Aktiv reading Aktiv, Current read buffer: 1006000000a54af0, Id 16, fCode 6, response: id 16, fCode 6, type h, adr 0, len 1, value 00a5
2019.01.30 21:14:27 5: Zaehler: DropFrame - drop 1006000000a54af0
2019.01.30 21:14:27 5: Zaehler: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2019.01.30 21:14:27 5: Zaehler: ProcessRequestQueue called from HandleTimeout as queue:Zaehler
2019.01.30 21:14:27 5: Zaehler: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 21:13:54.937) for Kueche_01, delay over
2019.01.30 21:14:27 5: Zaehler: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 21:13:54.900) for Kueche_01, delay over
2019.01.30 21:14:27 5: Zaehler: PackRequest called from ProcessRequestQueue
2019.01.30 21:14:27 4: Zaehler: ProcessRequestQueue got pdu from PackRequest: 0300030001
2019.01.30 21:14:27 5: Zaehler: PackFrame called from ProcessRequestQueue id 17, pdu 0300030001
2019.01.30 21:14:27 4: Zaehler: ProcessRequestQueue (V4.0.20 - 29.1.2019) sending, request: id 17, fCode 3, type h, adr 3, len 1 for device Kueche_01 reading EinAus, read buffer empty
2019.01.30 21:14:27 5: SW: 110300030001769a
2019.01.30 21:14:27 5: Zaehler: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds

Zaehler ist mein Stik für Thermostate und Stromzähler und Relais.
VR400Mod ist mein Stik für die Lüftung und ein Thermostat.

lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 31 Januar 2019, 19:31:51
Hallo Wolfgang,

beim Durchsehen Deiner Logs ist mir ein Bug aufgefallen. Ich bin nicht sicher, ob es Deine Timeouts behebt, aber zumindest das Logging wird dadurch klarer.
Könntest Du mit der angehängten neuen Version nochmal Logs erzeugen und posten?

Gruss / vielen Dank
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 31 Januar 2019, 20:00:14
Hallo Stefan!
keine Änderung

2019.01.31 19:55:40 5: Kueche_Aktiv: set called with Aktiv (h0) setVal = Ein
2019.01.31 19:55:40 5: Kueche_Aktiv: MapConvert called from ModbusLD_Set converted Ein to 165 with reversed map Aus:90, Ein:165,
2019.01.31 19:55:40 5: Kueche_Aktiv: set converted Ein to 165 using map 90:Aus,165:Ein
2019.01.31 19:55:40 5: Kueche_Aktiv: set packed hex 313635 with n to hex 00a5
2019.01.31 19:55:40 4: Kueche_Aktiv: DoRequest called from ModbusLD_Set created, request: id 17, fCode 6, type h, adr 0, len 1, value 00a5 for device Kueche_Aktiv reading Aktiv, read buffer empty
2019.01.31 19:55:40 5: Zaehler: QueueRequest called from ModbusLD_DoRequest with h0, qlen 21
2019.01.31 19:55:40 5: Zaehler: ProcessRequestQueue called from QueueRequest as direct:Zaehler, force
2019.01.31 19:55:40 5: Zaehler: ProcessRequestQueue called from QueueRequest returns, Fhem is still waiting for response, qlen 22, try again in 1 seconds
2019.01.31 19:55:40 5: Zaehler: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.01.31 19:55:40 5: Zaehler: ReadAnswer called from ModbusLD_Set
2019.01.31 19:55:40 5: Zaehler: ReadAnswer called and remaining timeout is 0.838778972625732
2019.01.31 19:55:40 3: Zaehler: Timeout waiting for a modbus response in ReadAnswer, request: id 3, fCode 1, type c, adr 1, len 1 for device R1 reading Relais1, read buffer empty
2019.01.31 19:55:40 5: Zaehler: DropFrame - drop
2019.01.31 19:55:40 5: Zaehler: StartQueueTimer called form ReadAnswerTimeout sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2019.01.31 19:55:40 4: WEB: /fhem?cmd=set%20Kueche_Aktiv%20Aktiv%20Ein&XHR=1&fwcsrf=csrf_416846969762650&fw_id=910 / RL:72 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.01.31 19:55:40 5: Zaehler: ProcessRequestQueue called from HandleTimeout as queue:Zaehler
2019.01.31 19:55:40 5: Zaehler: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 19:55:38.852) for Kueche_Aktiv, delay over
2019.01.31 19:55:40 5: Zaehler: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 19:55:38.828) for Kueche_Aktiv, delay over
2019.01.31 19:55:40 5: Zaehler: PackRequest called from ProcessRequestQueue
2019.01.31 19:55:40 4: Zaehler: ProcessRequestQueue got pdu from PackRequest: 06000000a5
2019.01.31 19:55:40 5: Zaehler: PackFrame called from ProcessRequestQueue id 17, pdu 06000000a5
2019.01.31 19:55:40 4: Zaehler: ProcessRequestQueue (V4.0.20 - 29.1.2019) sending, request: id 17, fCode 6, type h, adr 0, len 1, value 00a5 for device Kueche_Aktiv reading Aktiv, read buffer empty
2019.01.31 19:55:40 5: SW: 1106000000a54b21
2019.01.31 19:55:40 5: Zaehler: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.01.31 19:55:40 5: Zaehler: read buffer: 1106000000a54b21
2019.01.31 19:55:40 5: Zaehler: ParseFrameStart (RTU) extracted id 17, fCode 6 and data 000000a5
2019.01.31 19:55:40 5: Zaehler: HandleResponse called from Read
2019.01.31 19:55:40 5: Zaehler: ParseResponse called from HandleResponse
2019.01.31 19:55:40 5: Zaehler: CheckChecksum (called from HandleResponse): 4b21 is valid
2019.01.31 19:55:40 5: Zaehler: HandleResponse now passing to logical device Kueche_Aktiv for parsing data
2019.01.31 19:55:40 5: Kueche_Aktiv: ParseObj called with data 00a5, type h, adr 0, valuesLen 1, op write
2019.01.31 19:55:40 5: Kueche_Aktiv: ParseObj ObjInfo for h0: reading=Aktiv, unpack=n, expr=, format=, map=90:Aus,165:Ein
2019.01.31 19:55:40 5: Kueche_Aktiv: ParseObj unpacked 00a5 with n to 165 hex 313635
2019.01.31 19:55:40 5: Kueche_Aktiv: MapConvert called from ModbusLD_ParseObj converted 165 to Ein with map 90:Aus,165:Ein
2019.01.31 19:55:40 5: Kueche_Aktiv: ParseObj for Aktiv maps value 165 to Ein with 90:Aus,165:Ein
2019.01.31 19:55:40 4: Kueche_Aktiv: ParseObj assigns value Ein to Aktiv

lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 31 Januar 2019, 22:34:36
Hallo Wolfgang,

Das Log sieht auch nicht nach der neuen Version aus.
Die neue ist von Heute, Version 4.0.22.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 Februar 2019, 12:43:58
Hallo Wolfgang,

konntest Du schon einen Test mit der neuen Version machen?
Ich gehe davon aus, dass der bei Dir angezeigte Timeout gar nicht von dem set-Befehl sondern von dem bereits in der Queue vorhandenen Lesen kam.
Durch den Bug, den ich in Version 4.0.22 des Modbus-Moduls hoffentlich behoben habe, wurde der Timout im Kontext des Set-Befehls angezeigt, da sich der Set-Befehl mit höhere Priorität in die Queue "quetscht".
Die Timeouts werden durch den Fix nicht behoben, aber sollten jetzt korrekt im Log erscheinen und dann kann man hoffentlich besser erkennen, welches Delay-Attribut erhöht werden sollte.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 04 Februar 2019, 21:10:56
Hallo Stefan!

Ich habe die Version von 31.1.
Sicherheitshalber alles neu gestartet.

2019-01-31  fixed bug in GetSetCheck (failed to check for busy)

2019.02.04 20:58:49 4: Syn1_cam3V - SSCam_refresh - caller: "n.a.", callerroom: "n.a.", detail: "n.a.", pload: 0, forcePageRefresh: 0
2019.02.04 20:58:50 4: WEB_192.168.26.200_51705 POST /fhem?cmd=set%20Birgit_Aktiv%20Aktiv%20Ein&XHR=1&fwcsrf=csrf_414770179673336&fw_id=904; BUFLEN:0
2019.02.04 20:58:50 5: Cmd: >set Birgit_Aktiv Aktiv Ein<
2019.02.04 20:58:50 5: Birgit_Aktiv: set called with Aktiv (h0) setVal = Ein
2019.02.04 20:58:50 5: Birgit_Aktiv: GetSetChecks with force
2019.02.04 20:58:50 4: Birgit_Aktiv: GetSetChecks calls ReadAnswer to take over async read (still waiting for response to request: id 3, fCode 1, type c, adr 1, len 1 for device R1 reading Relais1 (getUpdate), queued 14.68 secs ago, sent 0.90 secs ago, read buffer empty
2019.02.04 20:58:50 5: Zaehler: ReadAnswer called from ModbusLD_GetSetChecks
2019.02.04 20:58:50 5: Zaehler: ReadAnswer called and remaining timeout is 1.09723496437073
2019.02.04 20:58:51 3: Zaehler: Timeout waiting for a modbus response in ReadAnswer request: id 3, fCode 1, type c, adr 1, len 1 for device R1 reading Relais1 (getUpdate), queued 15.78 secs ago, sent 2.00 secs ago, read buffer empty
2019.02.04 20:58:51 5: Zaehler: DropFrame - drop
2019.02.04 20:58:51 5: Zaehler: StartQueueTimer called form ReadAnswerTimeout sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2019.02.04 20:58:51 5: Birgit_Aktiv: GetSetChecks returns success
2019.02.04 20:58:51 5: Birgit_Aktiv: MapConvert called from ModbusLD_Set converted Ein to 165 with reversed map Aus:90, Ein:165,
2019.02.04 20:58:51 5: Birgit_Aktiv: set converted Ein to 165 using map 90:Aus,165:Ein
2019.02.04 20:58:51 5: Birgit_Aktiv: set packed hex 313635 with n to hex 00a5
2019.02.04 20:58:51 4: Birgit_Aktiv: DoRequest called from ModbusLD_Set created request: id 16, fCode 6, type h, adr 0, len 1, value 00a5 for device Birgit_Aktiv reading Aktiv (set Aktiv), read buffer empty
2019.02.04 20:58:51 5: Zaehler: QueueRequest called from ModbusLD_DoRequest (Birgit_Aktiv) with h0, qlen 15
2019.02.04 20:58:51 5: Zaehler: ProcessRequestQueue called from QueueRequest as direct:Zaehler, force
2019.02.04 20:58:51 5: Zaehler: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 20:58:47.438) for Birgit_Aktiv, delay over
2019.02.04 20:58:51 5: Zaehler: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 20:58:47.414) for Birgit_Aktiv, delay over
2019.02.04 20:58:51 5: Zaehler: PackRequest called from ProcessRequestQueue
2019.02.04 20:58:51 4: Zaehler: ProcessRequestQueue got pdu from PackRequest: 06000000a5
2019.02.04 20:58:51 5: Zaehler: PackFrame called from ProcessRequestQueue id 16, pdu 06000000a5
2019.02.04 20:58:51 4: Zaehler: ProcessRequestQueue (V4.0.22 - 31.1.2019) sending request: id 16, fCode 6, type h, adr 0, len 1, value 00a5 for device Birgit_Aktiv reading Aktiv (set Aktiv), queued 0.00 secs ago, read buffer empty
2019.02.04 20:58:51 5: SW: 1006000000a54af0
2019.02.04 20:58:51 5: Zaehler: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.02.04 20:58:51 5: Zaehler: ReadAnswer called from ModbusLD_Set
2019.02.04 20:58:51 5: Zaehler: ReadAnswer called and remaining timeout is 1.99387216567993
2019.02.04 20:58:51 5: Zaehler: ReadAnswer got: 1006000000a54af0
2019.02.04 20:58:51 5: Zaehler: ParseFrameStart (RTU) extracted id 16, fCode 6 and data 000000a5
2019.02.04 20:58:51 5: Zaehler: HandleResponse called from ReadAnswer
2019.02.04 20:58:51 5: Zaehler: ParseResponse called from HandleResponse
2019.02.04 20:58:51 5: Zaehler: CheckChecksum (called from HandleResponse): 4af0 is valid
2019.02.04 20:58:51 5: Zaehler: HandleResponse now passing to logical device Birgit_Aktiv for parsing data
2019.02.04 20:58:51 5: Birgit_Aktiv: ParseObj called with data 00a5, type h, adr 0, valuesLen 1, op write
2019.02.04 20:58:51 5: Birgit_Aktiv: ParseObj ObjInfo for h0: reading=Aktiv, unpack=n, expr=, format=, map=90:Aus,165:Ein
2019.02.04 20:58:51 5: Birgit_Aktiv: ParseObj unpacked 00a5 with n to 165 hex 313635
2019.02.04 20:58:51 5: Birgit_Aktiv: MapConvert called from ModbusLD_ParseObj converted 165 to Ein with map 90:Aus,165:Ein
2019.02.04 20:58:51 5: Birgit_Aktiv: ParseObj for Aktiv maps value 165 to Ein with 90:Aus,165:Ein
2019.02.04 20:58:51 4: Birgit_Aktiv: ParseObj assigns value Ein to Aktiv
2019.02.04 20:58:51 5: Starting notify loop for Birgit_Aktiv, 1 event(s), first is Aktiv: Ein
2019.02.04 20:58:51 4: dewpoint_notify: cmd_type=dewpoint devname=Birgit_Aktiv dewname=Taupunkt1, dev=Birgit_Aktiv, dev_regex=.* temp_name=temperature hum_name=humidity
2019.02.04 20:58:51 5: dewpoint_notify: s='Aktiv: Ein'
2019.02.04 20:58:51 5: dewpoint_notify: evName='Aktiv:' val=Ein'
2019.02.04 20:58:51 5: dewpoint max_timediff=1
2019.02.04 20:58:51 4: dewpoint_notify: cmd_type=dewpoint devname=Birgit_Aktiv dewname=Taupunkt2, dev=Birgit_Aktiv, dev_regex=.* temp_name=T hum_name=H
2019.02.04 20:58:51 5: dewpoint_notify: s='Aktiv: Ein'
2019.02.04 20:58:51 5: dewpoint_notify: evName='Aktiv:' val=Ein'
2019.02.04 20:58:51 5: dewpoint max_timediff=1
2019.02.04 20:58:51 5: End notify loop for Birgit_Aktiv
2019.02.04 20:58:51 5: Zaehler: HandleResponse got 1 readings from ParseObj for Birgit_Aktiv
2019.02.04 20:58:51 4: Zaehler: ResponseDone request: id 16, fCode 6, type h, adr 0, len 1, value 00a5 for device Birgit_Aktiv reading Aktiv (set Aktiv), queued 0.05 secs ago, sent 0.05 secs ago, Current read buffer: 1006000000a54af0, Id 16, fCode 6, response: id 16, fCode 6, type h, adr 0, len 1, value 00a5
2019.02.04 20:58:51 5: Zaehler: DropFrame - drop 1006000000a54af0
2019.02.04 20:58:51 5: Birgit_Aktiv: StartQueueTimer called from ModbusLD_Set removes internal timer because it is not needed now
2019.02.04 20:58:51 4: WEB: /fhem?cmd=set%20Birgit_Aktiv%20Aktiv%20Ein&XHR=1&fwcsrf=csrf_414770179673336&fw_id=904 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.02.04 20:58:51 5: Birgit_Soll: GetUpdate called from HandleTimeout
2019.02.04 20:58:51 5: Birgit_Soll: SetartUpdateTimer called from ModbusLD_GetUpdate updated timer, will call GetUpdate in 5.0 sec at 2019-02-04 20:58:56, interval 5
2019.02.04 20:58:51 5: Birgit_Soll: GetUpdate objects from attributes: h9
2019.02.04 20:58:51 5: Birgit_Soll: GetUpdate full object list: h9
2019.02.04 20:58:51 5: Birgit_Soll: GetUpdate check h9 => temperature, poll = 1, last = 1549310329.18303
2019.02.04 20:58:51 4: Birgit_Soll: GetUpdate will request temperature
2019.02.04 20:58:51 5: Birgit_Soll: GetUpdate tries to combine read commands
2019.02.04 20:58:51 5: Birgit_Soll: GetUpdate doesn't sort objList before sending requests
2019.02.04 20:58:51 4: Birgit_Soll: DoRequest called from ModbusLD_GetUpdate created request: id 16, fCode 3, type h, adr 9, len 1 for device Birgit_Soll reading temperature (getUpdate), read buffer empty
2019.02.04 20:58:51 5: Zaehler: QueueRequest called from ModbusLD_DoRequest (Birgit_Soll) with h9, qlen 15
2019.02.04 20:58:51 5: Zaehler: ProcessRequestQueue called from QueueRequest as direct:Zaehler
2019.02.04 20:58:51 5: Zaehler: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 20:58:38.506) for Wolfgang_Soll, delay over
2019.02.04 20:58:51 5: Zaehler: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 20:58:38.482) for Wolfgang_Soll, delay over
2019.02.04 20:58:51 5: Zaehler: PackRequest called from ProcessRequestQueue
2019.02.04 20:58:51 4: Zaehler: ProcessRequestQueue got pdu from PackRequest: 0300090001
2019.02.04 20:58:51 5: Zaehler: PackFrame called from ProcessRequestQueue id 18, pdu 0300090001
2019.02.04 20:58:51 4: Zaehler: ProcessRequestQueue (V4.0.22 - 31.1.2019) sending request: id 18, fCode 3, type h, adr 9, len 1 for device Wolfgang_Soll reading temperature (getUpdate), queued 16.32 secs ago, read buffer empty
2019.02.04 20:58:51 5: SW: 12030009000156ab
2019.02.04 20:58:51 5: Zaehler: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.02.04 20:58:51 5: Kueche_Soll: GetUpdate called from HandleTimeout
2019.02.04 20:58:51 5: Kueche_Soll: SetartUpdateTimer called from ModbusLD_GetUpdate updated timer, will call GetUpdate in 5.0 sec at 2019-02-04 20:58:56, interval 5
2019.02.04 20:58:51 5: Kueche_Soll: GetUpdate objects from attributes: h9
2019.02.04 20:58:51 5: Kueche_Soll: GetUpdate full object list: h9
2019.02.04 20:58:51 5: Kueche_Soll: GetUpdate check h9 => temperature, poll = 1, last = 1549310329.21437
2019.02.04 20:58:51 4: Kueche_Soll: GetUpdate will request temperature
2019.02.04 20:58:51 5: Kueche_Soll: GetUpdate tries to combine read commands
2019.02.04 20:58:51 5: Kueche_Soll: GetUpdate doesn't sort objList before sending requests
2019.02.04 20:58:51 4: Kueche_Soll: DoRequest called from ModbusLD_GetUpdate created request: id 17, fCode 3, type h, adr 9, len 1 for device Kueche_Soll reading temperature (getUpdate), read buffer empty
2019.02.04 20:58:51 5: Zaehler: QueueRequest called from ModbusLD_DoRequest (Kueche_Soll) with h9, qlen 15
2019.02.04 20:58:51 5: Zaehler: StartQueueTimer called form QueueRequest has already set internal timer to call Modbus_ProcessRequestQueue in 0.993 seconds
2019.02.04 20:58:51 5: R1: GetUpdate called from HandleTimeout
2019.02.04 20:58:51 5: R1: SetartUpdateTimer called from ModbusLD_GetUpdate updated timer, will call GetUpdate in 5.0 sec at 2019-02-04 20:58:56, interval 5
2019.02.04 20:58:51 5: R1: GetUpdate objects from attributes: c1
2019.02.04 20:58:51 5: R1: GetUpdate full object list: c1
2019.02.04 20:58:51 5: R1: GetUpdate check c1 => Relais1, poll = 1, last = 0
2019.02.04 20:58:51 4: R1: GetUpdate will request Relais1
2019.02.04 20:58:51 5: R1: GetUpdate tries to combine read commands
2019.02.04 20:58:51 5: R1: GetUpdate doesn't sort objList before sending requests
2019.02.04 20:58:51 4: R1: DoRequest called from ModbusLD_GetUpdate created request: id 3, fCode 1, type c, adr 1, len 1 for device R1 reading Relais1 (getUpdate), read buffer empty
2019.02.04 20:58:51 5: Zaehler: QueueRequest called from ModbusLD_DoRequest (R1) with c1, qlen 16
2019.02.04 20:58:51 5: Zaehler: StartQueueTimer called form QueueRequest has already set internal timer to call Modbus_ProcessRequestQueue in 0.986 seconds
2019.02.04 20:58:51 5: Soll_WZ: GetUpdate called from HandleTimeout
2019.02.04 20:58:51 5: Soll_WZ: SetartUpdateTimer called from ModbusLD_GetUpdate updated timer, will call GetUpdate in 5.0 sec at 2019-02-04 20:58:56, interval 5
2019.02.04 20:58:51 5: Soll_WZ: GetUpdate objects from attributes: h260 h523
2019.02.04 20:58:51 5: Soll_WZ: GetUpdate full object list: h260 h523
2019.02.04 20:58:51 5: Soll_WZ: GetUpdate check h260 => TemperaturSoll, poll = 1, last = 1549310326.83856
2019.02.04 20:58:51 4: Soll_WZ: GetUpdate will request TemperaturSoll
2019.02.04 20:58:51 5: Soll_WZ: GetUpdate check h523 => Sollof, poll = 1, last = 1549310326.97977
2019.02.04 20:58:51 4: Soll_WZ: GetUpdate will request Sollof
2019.02.04 20:58:51 5: Soll_WZ: GetUpdate tries to combine read commands
2019.02.04 20:58:51 5: Soll_WZ: GetUpdate cant combine request for TemperaturSoll / h260 with Sollof / h523, span 264 > max 5
2019.02.04 20:58:51 5: Soll_WZ: GetUpdate doesn't sort objList before sending requests
2019.02.04 20:58:51 4: Soll_WZ: DoRequest called from ModbusLD_GetUpdate created request: id 2, fCode 3, type h, adr 523, len 1 for device Soll_WZ reading Sollof (getUpdate), read buffer empty
2019.02.04 20:58:51 5: VR400Mod: QueueRequest called from ModbusLD_DoRequest (Soll_WZ) with h523, qlen 0
2019.02.04 20:58:51 5: VR400Mod: ProcessRequestQueue called from QueueRequest as direct:VR400Mod
2019.02.04 20:58:51 5: VR400Mod: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 20:58:46.977) for Soll_WZ, delay over
2019.02.04 20:58:51 5: VR400Mod: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 20:58:46.939) for Soll_WZ, delay over
2019.02.04 20:58:51 5: VR400Mod: PackRequest called from ProcessRequestQueue
2019.02.04 20:58:51 4: VR400Mod: ProcessRequestQueue got pdu from PackRequest: 03020b0001
2019.02.04 20:58:51 5: VR400Mod: PackFrame called from ProcessRequestQueue id 2, pdu 03020b0001
2019.02.04 20:58:51 4: VR400Mod: ProcessRequestQueue (V4.0.22 - 31.1.2019) sending request: id 2, fCode 3, type h, adr 523, len 1 for device Soll_WZ reading Sollof (getUpdate), queued 0.00 secs ago, read buffer empty
2019.02.04 20:58:51 5: SW: 0203020b0001f443
2019.02.04 20:58:51 5: VR400Mod: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.02.04 20:58:51 4: Soll_WZ: DoRequest called from ModbusLD_GetUpdate created request: id 2, fCode 3, type h, adr 260, len 1 for device Soll_WZ reading TemperaturSoll (getUpdate), read buffer empty
2019.02.04 20:58:51 5: VR400Mod: QueueRequest called from ModbusLD_DoRequest (Soll_WZ) with h260, qlen 0
2019.02.04 20:58:51 5: VR400Mod: StartQueueTimer called form QueueRequest sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.02.04 20:58:51 5: Zaehler: read buffer: 12030200143d88
2019.02.04 20:58:51 5: Zaehler: ParseFrameStart (RTU) extracted id 18, fCode 3 and data 020014
2019.02.04 20:58:51 5: Zaehler: HandleResponse called from Read
2019.02.04 20:58:51 5: Zaehler: ParseResponse called from HandleResponse
2019.02.04 20:58:51 5: Zaehler: CheckChecksum (called from HandleResponse): 3d88 is valid
2019.02.04 20:58:51 5: Zaehler: HandleResponse now passing to logical device Wolfgang_Soll for parsing data
2019.02.04 20:58:51 5: Wolfgang_Soll: ParseObj called with data 0014, type h, adr 9, valuesLen 1, op read
2019.02.04 20:58:51 5: Wolfgang_Soll: ParseObj ObjInfo for h9: reading=temperature, unpack=n, expr=$val/2, format=%.1f, map=
2019.02.04 20:58:51 5: Wolfgang_Soll: ParseObj unpacked 0014 with n to 20 hex 3230
2019.02.04 20:58:51 5: Wolfgang_Soll: CheckEval for ModbusLD_ParseObj evaluates expr for temperature, val=20, expr=$val/2
2019.02.04 20:58:51 5: Wolfgang_Soll: CheckEval for ModbusLD_ParseObj result is 10
2019.02.04 20:58:51 5: Wolfgang_Soll: ParseObj for temperature does sprintf with format %.1f, value is 10
2019.02.04 20:58:51 5: Wolfgang_Soll: ParseObj for temperature sprintf result is 10.0
2019.02.04 20:58:51 4: Wolfgang_Soll: ParseObj assigns value 10.0 to temperature
2019.02.04 20:58:51 5: Zaehler: HandleResponse got 1 readings from ParseObj for Wolfgang_Soll
2019.02.04 20:58:51 4: Zaehler: ResponseDone request: id 18, fCode 3, type h, adr 9, len 1 for device Wolfgang_Soll reading temperature (getUpdate), queued 16.36 secs ago, sent 0.04 secs ago, Current read buffer: 12030200143d88, Id 18, fCode 3, response: id 18, fCode 3, type h, adr 9, len 1, value 0014
2019.02.04 20:58:51 5: Zaehler: DropFrame - drop 12030200143d88
2019.02.04 20:58:51 5: Zaehler: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2019.02.04 20:58:51 5: Temp_WZ_S: GetUpdate called from HandleTimeout
2019.02.04 20:58:51 5: Temp_WZ_S: SetartUpdateTimer called from ModbusLD_GetUpdate updated timer, will call GetUpdate in 5.0 sec at 2019-02-04 20:58:56, interval 5
2019.02.04 20:58:51 5: Temp_WZ_S: GetUpdate objects from attributes: h260
2019.02.04 20:58:51 5: Temp_WZ_S: GetUpdate full object list: h260
2019.02.04 20:58:51 5: Temp_WZ_S: GetUpdate check h260 => TemperaturSoll, poll = 1, last = 1549310327.02843
2019.02.04 20:58:51 4: Temp_WZ_S: GetUpdate will request TemperaturSoll
2019.02.04 20:58:51 5: Temp_WZ_S: GetUpdate tries to combine read commands
2019.02.04 20:58:51 5: Temp_WZ_S: GetUpdate doesn't sort objList before sending requests
2019.02.04 20:58:51 4: Temp_WZ_S: DoRequest called from ModbusLD_GetUpdate created request: id 2, fCode 3, type h, adr 260, len 1 for device Temp_WZ_S reading TemperaturSoll (getUpdate), read buffer empty


lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 Februar 2019, 08:52:03
Hallo Wolfgang,

Ja, jetzt ist es die aktuelle Version. Man sieht ganz gut was passiert.

Könntest Du noch das Log für den Zeitraum zwischen 20:58:30 und 20:58:50 posten?
Oder sogar für eine ganze Minute?
In den Log-Ausschnitten, die ich bisher gesehen habe, scheint es immer eine Abfrage eines Relais zu sein, die in den Timeout läuft. Gleichzeitig scheint die Queue auch recht voll zu sein und ich frage mich wie viele Abfragen vor dem Timout erfolgreich sind. Wie oft kommt der Fehler? Wie sind die Fhem-Geräte definiert?
Ein größerer Ausschnitt gibt eventuell ein klareres Bild.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 06 Februar 2019, 22:18:11
Hallo Stefan!
hier der link zu meinem log
Leider kann ich den log nicht in ein Codefenster einfügen.
www.thiess.at/log/log.zip (http://www.thiess.at/log/log.zip)
lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: SandroK am 07 Februar 2019, 17:58:49
Hallo Stephan,

wie kann ich Bit's bswp. MX1000.0 von einem WAGO PFC auslesen ?
Laut Modulbeschreibung mit c13289, da kommt aber nichts.
Wenn ich mit h13289 das komplette Register lese, dann kommt auch derkomplette Wert.

Mich interessiert die Adressier-/Zählweise von Bit's innerhalb eines Wortes.

Danke für eine kurze Hilfestellung

VG Sandro
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Februar 2019, 20:00:48
Hallo Wolfgang,

im Log sieht es so aus, als ob die Timeouts regelmäßig dann kommen, wenn id 3 abgefragt wird und zuvor eine andere id abgefragt wurde.
Versuch doch mal ein commDelay für das Gerät mit id 3 auf 0,2 statt 0,1 zu setzen oder ein clientSwitchDelay auf 0,2 zu setzen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Februar 2019, 20:04:34
Hallo Sandro,

die Adressen und die Bedeutung der Bits in Registern ist immer geräteabhängig.
Was meinst Du mit "kommt nichts". Kommt ein Fehler / ein Timeout oder ein Wert 0 und Du erwartest eine 1?
Wenn Du die Bits auch über ein holding register abfragen kannst, dann kannst Du ja auch im Register-Wert per Expression und eine Und-Verknüpfung das richtige Bit herausholen. Ich bezweifle aber, dass die Register-Adresse dann der Adresse des Coils entspricht. Vermutlich werden dann immer 16 Coils in ein Register gepackt.
Das müsste aber im Handbuch des Geräts stehen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 08 Februar 2019, 20:59:38
Hallo Stefan!

"dev-timing-commDelay" hat nichts gebracht.
"clientSwitchDelay" find ich nicht.

lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Februar 2019, 21:39:08
Hallo Wolfgang,

Wie hoch bist Du denn mit commDelay gegangen?
Ich würde das durchaus bis auf 1 Sekunde testen ...

clientSwitchDelay wird auf dem physischen Interface angegeben.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 08 Februar 2019, 21:59:28
Hallo Stefan!

Habe beide Werte nun bis 1 Sek. getestet.
Kein Erfolg.

lg
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Februar 2019, 22:27:38
Hallo Wolfgang,

Ich würde mich auf das Device mit id 3 konzentrieren, da es die meisten Timeouts hat.
Probier doch mal folgendes aus:

- eine Fhem-Komfiguration, in der nur dieses Gerät abgefragt wird und nichts anderes. Sollte klären, ob es damit zusammen hängt
- ein eigener Bus für id 3, an dem keine anderen Geräte hängen.
- noch höhere Delays z.B, 3 Sekunden - könnte ausschließen, dass es überhaupt am Timing hängt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 08 Februar 2019, 22:57:44
Hallo Stefan!

Ich bin wieder in 2 Wochen vor Ort. Dann werde ich an der Hardware einiges testen. Hab schon einen neuen Stik bekommen. Danke vorerst.

lg
Wolfgang

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: SandroK am 09 Februar 2019, 13:54:44
Hallo Sandro,

die Adressen und die Bedeutung der Bits in Registern ist immer geräteabhängig.
Was meinst Du mit "kommt nichts". Kommt ein Fehler / ein Timeout oder ein Wert 0 und Du erwartest eine 1?
Wenn Du die Bits auch über ein holding register abfragen kannst, dann kannst Du ja auch im Register-Wert per Expression und eine Und-Verknüpfung das richtige Bit herausholen. Ich bezweifle aber, dass die Register-Adresse dann der Adresse des Coils entspricht. Vermutlich werden dann immer 16 Coils in ein Register gepackt.
Das müsste aber im Handbuch des Geräts stehen.

Gruss
   Stefan

Mit "es kommt nicht" meine ich das halt eine 0 zurückkommt. Ansonsten ist das Log fehlerfrei.
Die Variante mit Expression habe ich probiert, das funktioniert schon mal sehr gut, wie müsste ich aber das dann machen, ich kann ja nur ein
Holding-Register bsw. obj-h1200-reading anlegen, aus dem ich dann "mein" Bit heraus Extrahiere. Geht das dann nur über den Weg eines eigenen Userreading

Grüße Sandro
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: wthiess am 19 Februar 2019, 21:13:36
Hallo Stefan!

Habe nach einem Update kaum Fehler. Werde noch die Stränge aufteilen. Außerdem werde ich in den nächsten Wochen meine Verkabelung auf besseren Stand bringen. Aber seid neuesten habe ich im Log folgenden Fehler:
2019.02.19 21:02:43 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/98_Modbus.pm line 3224.
2019.02.19 21:02:43 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/98_Modbus.pm line 3225.
2019.02.19 21:02:43 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/98_Modbus.pm line 3226.
2019.02.19 21:02:43 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3227.
Hat das was zu bedeuten?

lg
Wolfgang

Haber gerade neue Versionen eingespielt aber keine Änderung. 19.02.2019 21:18
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 Februar 2019, 23:19:46
Hallo,

Ja, das ist ein bekannter Bug und das Update ist seit ein paar Stunden eingecheckt :-)

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 Februar 2019, 23:23:44
Hallo Sandro,

Die Expression würdest Du per obj-h1200-expr einbinden.
Oder meintest Du etwas anderes?

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 27 Februar 2019, 20:18:11
Hallo,

anbei eine neue Version zum Testen.
Man kann jetzt auch dev-x-defSet, dev-x-defHint sowie
dev-type-[A-Za-z0-9_]+-hint  und dev-type-[A-Za-z0-9_]+-set verwenden

Wenn keine Beschwerden kommen, würde ich es demnächst einchecken :-)

Gruss
   Stefan

Hallo Stefan,

danke für die Erweiterung. Ich habe Sie getestet und sie funktioniert ohne Probleme.

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 02 März 2019, 22:39:18
hallo,

ich weis nicht ob es ein Denkfehler ist oder ob es so nicht funktioniert.
Ich habe ein Gateway für SDM630 Zähler auf TCP. Daran kann man zwei Zähler anschließen. Bislang hatte ich nur einen Zähler dran. Das hat gut funktioniert.
Die Definition ist:
defmod SDM630 ModbusAttr 1 180 <IP>:502 TCPoder auch
defmod SDM630 ModbusSDM630M 1 180 <IP>:502 TCPDer Zähler hat die Modbus Adresse 1. Das funktioniert.
Wie bekomme ich nun den zweiten Zähler zum laufen. Ich habe ihn parallel angeschlossen und die Adresse 2 gegeben
ich dachte jetzt vielleicht so:
defmod SDM630W ModbusSDM630M 2 180 <IP>:502 TCPaber das geht leider nicht. Ich bekomme die Werte von ersten Zähler angezeigt.
Ein Verdrahtungsproblem schließe ich aus. Beim Gateway war ein Testprogramm für Windows dabei. Damit bekomme ich die richtigen Werte angezeigt.
Habe ich einen Denkfehler, oder sollte es so gehen?

LG Tom
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 März 2019, 17:53:12
Hallo Tom,

Eigentlich sollte es so gehen.
Kannst Du mal den Request, den das Testprogramm an Dein Gateway sendet, mitsniffen?
Dann können wir das mit dem Request von Fhem vergleichen (bei Verbose 5 wird der gesendete Request protokolliert).

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 03 März 2019, 18:59:17
Ja kann ich. Gute Idee. bis dann.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 03 März 2019, 19:34:37
So habe das Tool geöffnet, beide Zähler gelesen und wieder geschlossen. Das Ergebnis habe ich mal angehängt.
Es wird irgenwie immer nur Unit Identifier: 1 gelesen.
Es werden 212 16 bit Register gelesen. Ich kann nicht erkennen was Zähler eins und was Zähler zwei ist.

LG Tom
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: elektro_rainer am 03 März 2019, 20:00:13
Auch wenn’s banal klingt,.... hast du die Modbus Adresse 2 auch bei dem Modbus Teilnehmer richtig eingetragen?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 03 März 2019, 20:06:23
Also am Windows-Tool kann man nichts einstellen. Die Zähler stehen auf 1 und 2. Wenn ich einen auf 3 oder etwas anderes stelle, wird er nicht gefunden. Du meinst doch die Einstellung am Zähler?
Ich habe langsam eine andere Vermutung.

LG Tom
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 März 2019, 18:18:16
Hallo Tom,

Verstehe ich das richtig, dass Du das pcap aufgezeichnet hast, während Du beide Zähler abgefragt hast?
Ich sehe da auch nur Unit identifier 1 im pcap.

Könnte es sein, dass das Gateway den unit identifier ignoriert und satt dessen die Register-Adressen einen Offset haben?

Seltsam ...

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 04 März 2019, 18:50:17
@Tom_S , hast du bitte mal ne Bezeichnung/Modell von dem Gateway ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 04 März 2019, 18:53:18
so, erstmal danke an alle die sich hier Gedanken gemacht haben. Das sniffen war der entscheidende Tip.

hallo Stefan,

ja genau so ist es. Das Testprogramm fragt nur Unit identifier 1 ab. So habe ich das auch gesehen. Die Zähler werden nur angezeigt wenn sie ID1 und ID2 haben. Die Software im Gateway setzt das um und setzt die Register mit einem Offset von 100 hintereinander.
Darum waren auch mit einem Zähler die Werte der Register > 100 immer 0 oder zeigten Unsinn.
Workaround:
Entweder anderes Gateway kaufen oder ein Modul auf Basis des SDM630M Moduls bauen, das beide Zähler ausgibt.
Ich werde mal zweites angehen. Das ist denke ich schnell gemacht, und ich komme an alle Daten die ich benötige ran.
Mir war wichtig ob ich mit meiner define überhaupt richtig liege. 

Danke noch mal
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 04 März 2019, 18:55:30
@Wzut

möchte jetzt keinen Link posten. Schau mal in der Bucht nach "Gateway Zähler 2x SDM630 Modbus TCP"

LG
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 04 März 2019, 19:38:49
OK, gefunden und gibt es sogar als 4 x für meine SDM72D-M
Was ich aber jetzt nicht verstehe warum du deines nicht nutzen kannst.
Ist denn die Registerabfrage mit dem +100 Offset nicht möglich ? 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 04 März 2019, 20:21:04
Doch das funktioniert. Habe das SDM630M Modul umgeschrieben. Hat jetzt alle Register zwei mal. Erstmal o.K.
Aber warum der Entwickler dieses Gateway das so umsetzt ist mir nicht klar.
Und man kommt nicht an die Register > 100 ran da 101 dem 2. Zähler gehört. Wenn du zB U L1-L2 brauchst hast du keine Möglichkeit
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 März 2019, 21:08:25
Als Gateway käme übrigens auch ein Pi mit Fhem in Frage.
Das Modbus-Modul kann seit einer Weile auch Relay sein.
Allerdings habe ich dabei die Id bisher auch nicht ausgewertet.
Das könnte man aber erweitern.
Bisher müsste man für jeden nachgelagerten Slave ein eigens Relay Fhem-Device definieren.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Guzzi-Charlie am 14 März 2019, 00:00:20
Hallo,

ich benötige mal etwas Hilfe.

Ich habe aktuell 3 Modbus-Hutschienenzähler (XTM100A) mit einem RS485-USB Adapter über das Modbus-Modul und über Rogers SDM220M-Modul eingebunden. Das SDM220M-Modul habe ich an die Register meiner Zähler angepaßt. Das läuft auch alles wunderbar.

Jetzt möchte ich 4 weitere Zähler die sich an meiner 2. PV-Anlage im Nachbarhaus befinden auch anbinden. Da die gleiche Konfi mit RS485-USB Adapter wegen der Entfernung nicht geht soll die Anbindung hier über Ethernet erfolgen. Das Netzwerk ist dort schon vorhanden. Dafür habe ich mir einen RS485-TCP Adapter besorgt. Was ich bisher aber noch nicht verstanden habe, bzw. nicht hinbekommen habe ist die Einbindung dieses Adapters.

Muß ich den Adapter auch als I/O-Device für die eigentlichen SDM220M-Module anlegen und wie wäre die richtige Syntax, oder brauche ich das gar nicht und kann die Zähler direkt mit dem SDM220M-Modul ansprechen (Syntax?)? Was ich auch noch nicht verstanden habe ist: Muß ich das Device nun als RTU, oder als TCP definieren.

Wie gesagt: über USB funktionieren die SDM220M-Module perfekt. Was mir fehlt ist nur die Einbindung des RS485-TCP Gateways. Das bekomme ich nicht gebacken.

Wäre super wenn mich Jemand dabei unterstützen könnte.

Gruß
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 14 März 2019, 00:15:28
welches Gateway hast du denn. Kannst du da nähere Angaben machen?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Guzzi-Charlie am 14 März 2019, 09:28:14
Hallo,

ja natürlich. Das ist ein USR-TCP232-304 (siehe Foto).

Ich denke die HW wird nicht das Problem sein. Mir geht es hauptsächlich um das Verständnis ob ich nun dafür ein eigenes I/O-device (mit modbus.pm) anlegen muß und wie die richtige Syntax wäre.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 14 März 2019, 11:58:18
Ich habe nur gefragt weil es spezielle Module für die Zähler gibt. Ich habe so eins für zwei SDM630.
Bei deinem müsste doch
defmod <Name> ModbusAttr 1 180 <IP>:502 TCP
die Werte des ersten Zähler bringen. Die IP stellst du am Gateway ein und den Zähler auf die ModbusID 1.
Wenn das funktioniert dann kannst du die weiteren Zähler genauso einbinden. Mit anderer ModbusID natürlich. So habe ich das verstanden. Wenn es geht bitte hier mitteilen.

Gruß Tom S.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Guzzi-Charlie am 14 März 2019, 14:27:59
Leider funktioniert das so einfach eben nicht. Damit kann ich keine Verbindung herstellen.

Wie kommst Du auf den Port "502"? ist das nur ein Beispiel? in meinem Gateway steht als

Das habe ich auch beim Anlegen eingetragen.

Was ich auch immer noch nicht verstehe ist "TCP" oder "RTU". Die Schnittstelle meiner Zähler ist definitv Modbus RTU und nicht Modbus TCP. Was ich hier machen will ist doch Modbus RTU über TCP.

Und nochmal zu meiner Eingangsfrage:


Gruß
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tom_S am 14 März 2019, 18:14:03
Das ModbusTCP greift auf das Modbus.pm Modul zu. Der Port 502 ist in meinem Gateway und auch im Wechselrichter für ModbusTCP eingestellt. Er ist als Standard für ModbusTCP unter den know well Ports reserviert. In deinem Fall sollte aber auch der 8233 gehen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 14 März 2019, 19:31:01
Hallo,

man kann auch RTU über TCP machen. Dann gibt man beim Define nach der Adresse und dem Port statt TCP einfach RTU ein. Trotzdem benötigt man kein zusätzliches IO-Device vom Typ "Modbus" wie bei seriellen Verbindungen.

Wenn es gar nicht klappt, kann man auch einen weiteren Pi mit Fhem als Modbus-TCP zu RTU Gateway nehmen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Guzzi-Charlie am 15 März 2019, 21:54:09
Hallo Stefan,

vielen Dank für die Info.

Ich bin inzwischen auch etwas weiter gekommen. Ich hatte erstmal mit Windows experimentiert. Mit dem Tool "Modbus Master" habe ich dann letztlich eine Verbindung zum Zähler (über den TCP-RS485 Adapter) per "RTU over TCP-Protokoll" herstellen können. Das Tool sagt "Modbus_Device_Ok" und ich erhalte Werte, obwohl die Werte selbst mir suspekt sind.

Auf Basis der experimentell ermittelten Einstellungen habe ich dann in FHEM das ModbusAttr Gerät angelegt.
defmod XTM100A_21a ModbusAttr 48 30 192.168.178.126:502 RTU
attr XTM100A_21a userattr obj-h0-reading obj-h18-reading obj-h256-reading obj-h8-reading
attr XTM100A_21a obj-h0-reading voltage
attr XTM100A_21a obj-h18-reading power
attr XTM100A_21a obj-h256-reading total_power
attr XTM100A_21a obj-h8-reading current
attr XTM100A_21a room Test

setstate XTM100A_21a opened
setstate XTM100A_21a 2019-03-15 18:26:01 state opened

Das Gerät geht in den state "opened". Allerdings erhalte ich keine readings.

Wie ist das denn mit der Definition der holding Register? Setzt das Modul das "h" automatisch in den richtigen Funktionscode "04" um?

Woran könnte es liegen das ich keine readings erhalte?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 15 März 2019, 22:47:31
Hallo,

Function Code 4 liest Input Register, keine Holding Register.
Warum nimmst Du nicht das SDM220 Modul? Da sind dann die Register, Datentypen etc. schon richtig hinterlegt.

Wenn etwas nicht klappt, sollte man verbose für das betroffene Gerät auf 5 setzen und das Log verfolgen.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Guzzi-Charlie am 16 März 2019, 00:38:26
Oh Mann, da hast Du natürlich Recht. Ich weiß nicht wieso ich das "h" benutzt habe. War mir eigentlich klar, daß es um Input-Register geht. Vielleicht weil in den Beispielen auch überall nur das "h" verwendet wird.

Das SDM220M-Modul kann ich ja nicht nehmen, da das doch nur für die serielle Anbindung funktioniert, oder hab ich da was falsch verstanden? Ich brauche ja RTU over TCP.

Ich habe ja 3 Zähler mit serieller Anbindung (über RS485-USB Adapter) in Betrieb. Das funktioniert einwandfrei. Ich habe allerdings nicht das Original-SSDM220M sondern habe es auf meine Zähler angepaßt (z.B. Register-Adressen), bzw. alles rausgeschmissen was meine Zähler nicht an Daten zur Verfügung stellen.

Ich versuche es Morgen nochmal mit der Definition als Input-Register. Das Decode-Attribut muß ich aber nicht benutzen, oder?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 16 März 2019, 08:05:41
Hallo,

das SDM230M-Modul und alle anderen Module, die auf 98_Modbus.pm basieren, verstehen auch alle Optionen beim Define und alle Attribute von ModbusAttr.
Du kannst also auch damit RTU über TCP machen!

Gruß
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 16 März 2019, 17:35:27
Hallo Guzzi-Charlie,

wenn du ein USR-TCP232-T24 (siehe Bild) im Einsatz hast must du das Modul z.B. so definieren. RS485 muss aktiv sein. Vielleicht hilft es weiter.

define PWP ModbusAttr 3 60 192.168.2.7:20108 RTU

Ich sehe bei einem Adapter jetzt nicht ob es RS485 kann bzw. aktiviert werden kann.

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Guzzi-Charlie am 16 März 2019, 18:37:41
Hallo zusammen,

wenn ich gewußt hätte das es so einfach sein kann.....

Also, ich habe mein modifiziertes SDM220M-Modul (mit angepaßten Registern) genommen, die IP-Adresse des RS485-TCP Gateways und "RTU" angehängt und schon hat es funktioniert. Mit dem allgemeinen ModbusAtt-Modul bekomme ich das zwar immer noch nicht hin, aber das soll mir jetzt mal egal sein.

@Stefan
Vielen Dank für die Erläuterungen.


Ich hab noch eine andere Frage:
Da ich mich mit Perl absolut nicht auskenne habe ich natürlich auch noch kein Modul selbst programmiert, sondern nur (z.B.) das vorhandene SDM220M modifiziert. Jetzt hatte ich ein wenig zu einfach gedacht (wie es scheint). Da ich ja das originale SDM220 abgeändert habe würde das dann allerdings beim nächsten Update wieder überschrieben. Deshalb hatte ich das Modul einfach kopiert und ihm einen anderen Namen gegeben. Als ich dann damit ein neues Gerät (Zähler) definieren wollte bekam ich allerdings die Meldung "kann Modul nicht laden", oder so ähnlich. FHEM "Shutdown restart" hatte ich vorher durchgeführt.

Was müßte ich denn tun damit er mein umbenanntes Modul akzeptiert?

Gruß
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 16 März 2019, 18:42:32
wenn du ein Modul unter einem neuen Namen führen willst (ich mach das öfters) dann schau ins Modul und ersetze dort überall den Orignal Namen gegen deinen Neuen.
I.d.R tragen fast alle subs den Modulnamen in sich :) aber ein guter Editor macht das via suchen & ersetzen recht schnell. 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Guzzi-Charlie am 16 März 2019, 18:47:37
OK, Danke.

Wenn das alles sein sollte, dann wäre das ja schnell eledigt. Werd ich mal versuchen.

Gruß
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: eisler am 01 April 2019, 18:42:22
Hallo,

Ich habe ein Beckhoff BK9000 mit Digital Ausgangsklemmen von 2003.

Auszug aus der Config:

defmod MODBUS Modbus 192.168.1.2:502
attr MODBUS disable 0

defmod MODBUS_Gateway ModbusAttr 1 0 TCP
attr MODBUS_Gateway userattr obj-c0-poll obj-c0-reading obj-c2-poll obj-c2-reading obj-c4-poll obj-c4-reading
attr MODBUS_Gateway IODev MODBUS
attr MODBUS_Gateway obj-c0-poll 0
attr MODBUS_Gateway obj-c0-reading simpleLightbulb1
attr MODBUS_Gateway obj-c2-poll 0
attr MODBUS_Gateway obj-c2-reading simpleLightbulb2
attr MODBUS_Gateway obj-c4-poll 0
attr MODBUS_Gateway obj-c4-reading simpleLightbulb3

Setzen funktioniert leider nur ein mal:

Cmd: >set MODBUS_Gateway simpleLightbulb2 1<
...
SW: 00000000000601050002ff00

Als Antwort bekomme ich:

DropFrame - drop 000000000003018504
ReadAnswer got Error code 04 / slave device failure
192.168.1.2:502 disconnected, waiting to reappear (MODBUS)

Hat jemand schon mal einen Beckhoff BK9000 erfolgreich angesprochen?

Grüße
Stephan



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: zwehn am 02 April 2019, 09:51:08
Hallo,
Habe heute einen Kostal plenticore Wechselrichter eingebaut bekommen. Nach Anleitung aus dem Forum habe ich die Einrichtung unter fhem vorgenommen.
Der plenticore ist Modbus master. Ein energy manager em300 hat auch als slave zugriff und ließt daten aus.

Fhem zeigt auch connected an, bekommt aber keine readings. Im logfile steht timeout, waiting for response. Die Zugangsdaten mit Geräte id im define sollten aber richtig sein, siehe unten.
Hat jemand eine Idee woran es liegen könnte?

Logfile:
2019.04.01 23:30:57 3: Opening Plenticore device 192.168.28.82:1502
2019.04.01 23:30:57 3: Plenticore device opened
2019.04.01 23:31:07 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 203, type h, adr 320, len 2 for device Plenticore reading Total_yield (getUpdate), queued 2.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:31:09 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 101, type h, adr 322, len 2 for device Plenticore reading Daily_yield (getUpdate), queued 4.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:31:11 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 218, type h, adr 100, len 2 for device Plenticore reading Total_DC_Power (getUpdate), queued 6.02 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:32:10 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 224, type h, adr 322, len 2 for device Plenticore reading Daily_yield (getUpdate), queued 2.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:32:12 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 60, type h, adr 100, len 2 for device Plenticore reading Total_DC_Power (getUpdate), queued 4.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:32:14 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 215, type h, adr 320, len 2 for device Plenticore reading Total_yield (getUpdate), queued 6.02 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:33:13 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 79, type h, adr 320, len 2 for device Plenticore reading Total_yield (getUpdate), queued 2.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:33:15 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 217, type h, adr 322, len 2 for device Plenticore reading Daily_yield (getUpdate), queued 4.01 secs ago, sent 2.01 secs ago, read buffer empty
2019.04.01 23:33:17 3: Plenticore: Timeout waiting for a modbus response request: id 71, fCode 3, tid 211, type h, adr 100, len 2 for device Plenticore reading Total_DC_Power (getUpdate), queued 6.03 secs ago, sent 2.01 secs ago, read buffer empty

Fhem Web Ausgabe:
DeviceOverview
Plenticore
opened

 Plenticore

Internals
DEF
71 60 192.168.28.82:1502 TCP

DeviceName
192.168.28.82:1502
EXPECT
idle
FD
121
FUUID
5ca27d5d-f33f-70a6-f0f6-2296cc58165efa55
INTERVAL
60
IODev
Plenticore
LASTOPEN
1554154257.897
MODBUSID
71
MODE
master
MODULEVERSION
Modbus 4.0.24 - 18.2.2019
NAME
Plenticore
NOTIFYDEV
global
NR
569
NTFY_ORDER
50-Plenticore
PARTIAL

PROTOCOL
TCP
STATE
opened
TCPConn
1
TIMEOUTS
33
TRIGGERTIME
1554154955.63942
TRIGGERTIME_FMT
2019-04-01 23:42:35
TYPE
ModbusAttr
devioLoglevel
3
lastUpdate
1554154895.63942
nextOpenDelay
60
Readings
state
opened
2019-04-01 23:30:57

 Plenticore

Attributes
dev-type-Fl_R2-format
%.2f
deleteattr
dev-type-Fl_R2-len
2
deleteattr
dev-type-Fl_R2-revRegs
1
deleteattr
dev-type-Fl_R2-unpack
f>
deleteattr
obj-h100-poll
1
deleteattr
obj-h100-reading
Total_DC_Power
deleteattr
obj-h100-type
Fl_R2
deleteattr
obj-h320-expr
$val/1000
deleteattr
obj-h320-poll
1
deleteattr
obj-h320-reading
Total_yield
deleteattr
obj-h320-type
Fl_R2
deleteattr
obj-h322-expr
$val/1000
deleteattr
obj-h322-poll
1
deleteattr
obj-h322-reading
Daily_yield
deleteattr
obj-h322-type
Fl_R2
deleteattr
room
Energie
deleteattr
userattr
1 dev-type-Fl_R2-format dev-type-Fl_R2-len dev-type-Fl_R2-revRegs dev-type-Fl_R2-unpack obj-h100-poll obj-h100-reading obj-h100-type obj-h320-expr obj-h320-poll obj-h320-reading obj-h320-type obj-h322-expr obj-h322-poll obj-h322-reading obj-h322-type
deleteattr
Select icon Extend devStateIcon Raw definition Delete this device (Plenticore) Device specific help
Plenticore info:
Gerät
Name
scb
Typenbezeichnung
PLENTICORE plus 7.0
Seriennummer
92092SBC0002N
Artikelnummer
10335957
Ui-version
01.05.03190
MC-Version
01.21
IOC-Version
01.20
HW-Version
0100
Ländereinstellung
Germany NSR
Batterieeingang
freigeschaltet

Was mich irritiert ist, dass egal ob ich im Wechselrichter Modbus aktiviere oder deaktiviere, fhem immer opened anzeigt aber nichts ausliesst.
Irgendwie stehe ich auf dem Schlauch. Hoffe auf einen Tipp.Danke
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 03 April 2019, 01:34:02
Hallo,
ich lese mit fhem eine Dimplex WWP mit modbus RTU over tcp aus.
Nachdem ich heute ein fhem update durchgeführt habe erhalte ich im Logfile folgende Meldungen in einer Enddlossschleife:


2019.04.03 00:26:15 5: HttpUtils url=http://ECS-AP:8899/
2019.04.03 00:26:15 4: IP: ECS-AP -> 192.168.111.34
2019.04.03 00:26:15 3: ECS-AP:8899 reappeared (RS485)
2019.04.03 00:26:15 5: RS485: StartUpdateTimer called from OpenCB
2019.04.03 00:26:15 5: RS485: SetartUpdateTimer kept existing timer, will call GetUpdate in 16.0 sec at 2019-04-03 00:26:31, interval 30
2019.04.03 00:26:24 3: ECS-AP:8899 disconnected, waiting to reappear (RS485)
2019.04.03 00:26:29 5: HttpUtils url=http://ECS-AP:8899/
2019.04.03 00:26:29 4: IP: ECS-AP -> 192.168.111.34
2019.04.03 00:26:29 3: ECS-AP:8899 reappeared (RS485)
2019.04.03 00:26:29 5: RS485: StartUpdateTimer called from OpenCB
2019.04.03 00:26:29 5: RS485: SetartUpdateTimer kept existing timer, will call GetUpdate in 1.9 sec at 2019-04-03 00:26:31, interval 30
2019.04.03 00:26:31 5: DimplexWWP: GetUpdate called from HandleTimeout
2019.04.03 00:26:31 5: DimplexWWP: StartUpdateTimer called from ModbusLD_GetUpdate
2019.04.03 00:26:31 5: DimplexWWP: SetartUpdateTimer updated timer, will call GetUpdate in 30.0 sec at 2019-04-03 00:27:01, interval 30
2019.04.03 00:26:31 4: DimplexWWP: GetIOHash (called from ModbusLD_CheckDisable) didn't find valid IODev hash key, calling SetIODev now
2019.04.03 00:26:31 5: DimplexWWP: SetIODev called from ModbusLD_GetIOHash
2019.04.03 00:26:31 5: DimplexWWP: UnregAtIODev called from ModbusLD_SetIODev
2019.04.03 00:26:31 3: DimplexWWP: SetIODev found no usable physical modbus device
2019.04.03 00:26:31 4: DimplexWWP: GetIOHash didn't find IODev attribute or matching physical serial Modbus device
2019.04.03 00:26:31 5: DimplexWWP: CheckDisable returns no IO Device to communicate through
2019.04.03 00:26:31 5: DimplexWWP: GetUpdate called but no IO Device to communicate through
2019.04.03 00:26:31 5: RS485: GetUpdate called from HandleTimeout
2019.04.03 00:26:31 5: RS485: StartUpdateTimer called from ModbusLD_GetUpdate
2019.04.03 00:26:31 5: RS485: SetartUpdateTimer updated timer, will call GetUpdate in 30.0 sec at 2019-04-03 00:27:01, interval 30
2019.04.03 00:26:31 5: RS485: GetUpdate objects from attributes:
2019.04.03 00:26:31 5: RS485: GetUpdate full object list:
2019.04.03 00:26:31 5: RS485: GetUpdate tries to combine read commands
2019.04.03 00:26:31 5: RS485: GetUpdate doesn't sort objList before sending requests
2019.04.03 00:26:38 3: ECS-AP:8899 disconnected, waiting to reappear (RS485)


Meine Konfiguration:

define RS485 ModbusAttr 1 30 ECS-AP:8899 RTU
attr     RS485 verbose 5

define DimplexWWP ModbusRTUDimplexWWP 1 30
attr     DimplexWWP IODev RS485
attr     DimplexWWP verbose 5



Was hat sich geändert ?  Was muss ich anpassen?
Für Hilfestellung wäre ich dankbar.
Mit freundlichen Grüßen






Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 April 2019, 22:53:32
Hallo McBasil,

Wenn Du Modbus-Verbindungen per TCP herstellen möchtest, dann musst Du im Define direkt die Adresse und den Port angeben. Ein IODev-Verweis ist nur für Modbus-Geräte gedacht, die direkt seriell an Fhem angeschlossen sind, da in diesem Fall mehrere Geräte am selben IO Device hängen können.
So war das eigentlich immer schon.

Ich vermute dass Du ein Gateway von TCP auf RS485 mit der Adresse ECS-AP verwendest.

Dann müsste Deine Konfiguration folgendermaßen aussehen:
define DimplexWWP ModbusRTUDimplexWWP 1 30 ECS-AP:8899 RTU
attr     DimplexWWP verbose 5

Das Gerät mit Namen RS485 solltest Du löschen.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 April 2019, 22:58:46
Hallo Zwehn,

Bitte poste doch Deine tatsächliche Konfiguration, so wie sie in der fhem.cfg steht oder bei Klick auf "Raw Definition" in Fhemweb ausgegeben wird.
Zudem wäre ein ausführlicher Log-Auszug bei verbose 5 sehr hilfreich.
Dann vermute ich noch dass Du Modbus Master und Slave durcheinander gebracht hast.
Ein Modbus-Master fragt Daten von einem Slave ab. Ein Slave selbst liest keine Daten.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 April 2019, 23:03:48
Hallo Eisler,

Wenn ich Dein Setup richtig verstehe, hast Du ein BK9000 Gateway, das Du per Modbus ansprechen möchtet um dahinter liegende IO-Module zu steuern.
Die Fehlermeldung 04 deutet darauf hin, dass das Modul hinter dem Gateway nicht reagiert / funktioniert.
Schaltet es denn?
Was passiert denn wenn Du die gleichen Requests von einem anderen Master aus absetzt?

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 04 April 2019, 01:46:35
Hallo Stefan,

ganz herzlichen Dank für die Schnelle Unterstützung.

Ich habe die Änderung vorgenommen.

Jetzt wird der fhem-Server nicht mehr gestartet.

Die Überprüfung aus einer ssh ergibt folgendes Bild:

pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
-rw-r--r-- 1 fhem dialout 3886 Apr  4 01:12 fhem-2019-04.log
pi@raspber-bdf:/opt/fhem/log $ sudo rm fhem-2019-04.log
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
ls: Zugriff auf 'fhem-2019-04.log' nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspber-bdf:/opt/fhem/log $ sudo /etc/init.d/fhem status
fhem is not running
pi@raspber-bdf:/opt/fhem/log $ sudo /etc/init.d/fhem start
Starting fhem...
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
-rw-r--r-- 1 fhem dialout 936 Apr  4 01:21 fhem-2019-04.log
pi@raspber-bdf:/opt/fhem/log $ sudo /etc/init.d/fhem status
fhem is not running
pi@raspber-bdf:/opt/fhem/log $ ls -l fhem-2019-04.log
-rw-r--r-- 1 fhem dialout 936 Apr  4 01:21 fhem-2019-04.log
pi@raspber-bdf:/opt/fhem/log $


und hier das LOGFILE:

2019.04.04 01:21:10 1: Including fhem.cfg
2019.04.04 01:21:10 3: telnetPort: port 7072 opened
2019.04.04 01:21:10 3: WEB: port 8083 opened
2019.04.04 01:21:10 3: WEBphone: port 8084 opened
2019.04.04 01:21:10 3: WEBtablet: port 8085 opened
2019.04.04 01:21:11 2: eventTypes: loaded 310 events from ./log/eventTypes.txt
2019.04.04 01:21:11 1: Including Junkers-30-kW.cfg
2019.04.04 01:21:11 3: Laden using AES-Key: 7ec67698804f145884840ffb8f0191cdfdf3731acaa68dbe04da8cf392db0d

2019.04.04 01:21:11 1: Including Wi18TU.cfg
2019.04.04 01:21:11 3: DimplexWWP: defined with id 1, interval 30, protocol RTU, mode master, connection to ECS-AP:8899
2019.04.04 01:21:11 4: DimplexWWP: Notify / Init: opening connection
2019.04.04 01:21:11 5: DimplexWWP: open called from Notify
2019.04.04 01:21:11 4: DimplexWWP: open trying to open connection to ECS-AP:8899
Undefined subroutine &main::DevIo_OpenDev called at ./FHEM/98_Modbus.pm line 1593.


Danach erfolgen keine Einträge mehr im LOGFILE

Ich hoffe Du kannst mit meinen Infos etwas anfangen.

Gruß
        Basil

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: eisler am 04 April 2019, 15:03:16
Hallo Stefan,

Das Setup hast du richtig verstanden.
Problem mit dem Beckhoff BK9000 Gateway habe ich gefunden.
Auf dem BK9000 Gateway ist ein Watchdog konfiguriert der nach dem ersten Schreiben alle 100ms ein alive benötigt.
Quick fix war den Watchdog zu deaktivieren.
Da ich die Funktion des Watchdog verstehe und Sinnvoll finde würde ich den Watchdog auch gerne ansprechen.
Hast du eine Idee?

Grüße
Stephan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 April 2019, 07:53:14
Hallo Basil,

kannst Du mal die angehängten minimal geänderten Module ausprobieren?
Eventuell ist das Problem in Deinem Fall damit behoben.

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 April 2019, 07:54:02
Hallo Stephan,

kannst Du den Watchdog etwas genauer beschreiben?
Wer braucht da von wem welche Daten... ??

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: eisler am 05 April 2019, 08:09:12
Hallo Stefan,

Aus dem Datenblatt: https://download.beckhoff.com/download/document/io/bus-terminals/bk9000de.pdf

"Der Watchdog ist im Auslieferungszustand aktiviert. Nach dem ersten Schreibtelegramm wird der Watchdog scharf geschaltet und bei jedem empfangenden Telegramm dieses Teilnehmers getriggert. Andere Teilnehmer haben auf den Watchdog keinen Einfluss. Eine zweite Möglichkeit, die eine schärfere Bedingung des Watchdogs darstellt, ist, dass der Watchdog nur nach jedem Schreibtelegramm getriggert wird."

Bei Watchdog Fehler werden nicht nur die Ausgänge auf Null gesetzt. Der BK9000 bleibt einfach stehen und ich muss ihn neu booten um ihn anzusprechen.

Grüße
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 05 April 2019, 23:11:31
Guten Abend Stefan,

ganz herzlichen Dank für das Update. Jetzt laufen die Zugriffe auf meine Wärmepumpe mit der von Dir vorgeschlagenen Definition, die übermittelten Werte erscheinen plausibel.
Solltest Du am Logfile interessiert sein, kann ich es gerne nachreichen.

Wäre für Dich ein Test Deines Modbus im passiven Modus mit einem iobroker als Master von Interesse? Ich wäre gerne bereit diesen durchzuführen.

Gruß Basil
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 April 2019, 20:35:23
Hallo Basil,

Du bist da offenbar über einen Bug gestolpert, der schon lange im Modul ist und nur normalerweise nicht auffällt, da DevIO von sehr vielen anderen Modulen genutzt wird und in der Regel schon geladen ist. In Deiner Konstellation wurde DevIO aber zu spät geladen.

Wenn Du den passiven Modus testen könntest wäre das hilfreich. Ich vermute dass den außer mir mir noch kaum jemand getestet hat.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 12 April 2019, 11:35:24
Hallo Stefan,

wie kann ich am besten in einem Modul verschieden Modbus-Wechselrichter (SunSpec ?)  abfragen, da doch einige Unterschiede sind.

SolarEdge SE5K -> https://forum.fhem.de/index.php/topic,80767.msg853967.html#msg853967
KACO -> https://forum.fhem.de/index.php/topic,98581.msg919950.html#msg919950
Kostal Plenticore plus  -> https://forum.fhem.de/index.php/topic,92281.0.html

Sollte erst der ganze Block ausgelesen werden und später aufgeteilt werden (ExprMppt).
"h40020" =>  {       'reading' => 'Block_C_Model',
                                  'type' => 'VT_String',
                                  'expr' => 'ExprMppt($hash,$name,"C_Model",$val[0],0,0,0,0)', # conversion of raw value to visible value

Oder kann man beim "_Initialize" eine Auswahl/Abfrage einbauen. Vorher muss das Model festlegen oder mit übergeben werden.
z.B.
SEdge SunSpecWR 3 60 192.168.0.23:502 RTU  SolarEdge

KACO SunSpecWR 3 60 192.168.0.23:502 RTU  KACO

Kostal SunSpecWR 3 60 192.168.0.23:502 RTU  Kostal

sub
SolarEdge_Initialize($)
{
    my ($hash) = @_;

  require "$attr{global}{modpath}/FHEM/98_Modbus.pm";
    require "$attr{global}{modpath}/FHEM/DevIo.pm";

 $hash->{DefFn}     = "SolarEdge_Define";
 $hash->{AttrFn} = "SolarEdge_Attr";

...Abfrage (MODEL)

 $hash->{parseInfo}  = \%SolarEdgeparseInfoM0; # defines registers for this Modbus Defive
 $hash->{deviceInfo} = \%SolarEdgedeviceInfoM0; # defines properties of the device like

...(MODEL1)

 $hash->{parseInfo}  = \%SolarEdgeparseInfoM1; # defines registers for this Modbus Defive
 $hash->{deviceInfo} = \%SolarEdgedeviceInfoM1; # defines properties of the device like

... END-Auswahl

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


Vielleicht hast du ja eine Idee. Vielen Dank.

Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 April 2019, 15:56:33
Hallo Jörg,

Initialize wird beim Laden des Moduls aufgerufen. Da hast Du noch keine Informationen aus dem Define oder aus Attributen.
Das ist also der falsche Platz.
Ein weiteres Problem ist dass der parseInfo-Hash ja im Modul-Hash steht und deshalb für alle Geräte eines Moduls identisch ist.

Ich könnte das Basis-Modul so erweitern, dass der parseInfo Hash auch im Geräte-Hash stehen kann und nicht nur im Modul-Hash. Der Geräte-Hash hätte dann Priorität. Dann könnte man im Define einen zusätzlichen optionalen Parameter einbauen, der dann eine von mehreren parseInfo-Vorlagen aus dem Modul-Hash in den Geräte-Hash kopiert.

Oder man könnte das auch dynamisch zur Laufzeit setzen, nachdem die Geräte-Spezifikation aus einem immer gleichen Register geladen wurde. Dafür müsste ich aber auch eine Art Setup-Funktion im Modul vorsehen, die vor allen anderen Abfragen erst mal den Geräte-Typ ermittelt und dann parseInfo setzt. Das müsste aber auch wieder asynchron erfolgen  ...

Vielleicht komme ich in den nächsten Tagen mal dazu beide Features im Basis-Modul einzubauen.

Gruss
   Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 April 2019, 09:16:41
Hallo,

anbei eine neue Version des Modbus-Basis-Moduls zum Testen.
Die Änderungen sind sind nur für Autoren von eigenen Modulen auf Basis von Modbus relevant:

1)  Die Hashes für die Definition der Modbus-Objekte (parseInfo und deviceInfo) können jetzt auch in den Device-Hash gelegt werden. Dort haben sie dann Priorität gegenüber den Daten im Modul-Hash. Damit kann ein Modul mehrere Varianten eines Geräts mit abweichender Register-Belegung unterstützen und die passende Definition zur Laufzeit festlegen.

Beispiel aus einer Funktion oder Expression heraus:
if (!$logHash->{ModelChosen}) {
# select model and correct parseInfo
$logHash->{parseInfo} = \%SET10parseInfo2;
$logHash->{ModelChosen} = 1;
$logHash->{".updateSetGet"} = 1;
Log3 $name, 3, "$name: ModbusReadingsFn set model to XY";
}

2) Man kann eine "ModbusReadingsFn" Funktion einklinken, die immer aufgerufen wird, bevor das Basis-Modul die aus einer Modbus-Response extrahierten Werte in Readings schreibt. Diese Funktion wird mit dem Device-Hash, dem Namen des Readings und dem Wert aufgerufen.
Wenn die Funktion 1 zurückgibt, wird danach vom Basis-Modul kein readingsBulkUpdate aufgerufen.

Beispiel:
#####################################
sub ModbusSET_Initialize($)
{
    my ($modHash) = @_;
    require "$attr{global}{modpath}/FHEM/98_Modbus.pm";

    $modHash->{parseInfo}  = \%SET10parseInfo;  # defines registers, inputs, coils etc. for this Modbus Defive   
    $modHash->{deviceInfo} = \%SET10deviceInfo; # defines properties of the device like defaults and supported function codes

    ModbusLD_Initialize($modHash);                        # Generic function of the Modbus module does the rest
    $modHash->{ModbusReadingsFn} = "ModbusSET_Reading";    # to be called before a reading is set
   
    $modHash->{AttrList} = $modHash->{AttrList} . " " .     # Standard Attributes like IODEv etc
        $modHash->{ObjAttrList} . " " .                     # Attributes to add or overwrite parseInfo definitions
        $modHash->{DevAttrList} . " " .                     # Attributes to add or overwrite devInfo definitions
        "poll-.* " .                                                     # overwrite poll with poll-ReadingName
        "polldelay-.* ";                                              # overwrite polldelay with polldelay-ReadingName
}

In 98_Modbus-pm sieht das folgendermaßen aus:
# Try to call a user defined function if defined
#################################################
sub Modbus_TryCall($$$$)
{
    my ($hash, $fName, $reading, $val) = @_;
    my $name = $hash->{NAME};
my $modHash = $modules{$hash->{TYPE}};
if ($modHash->{$fName}) {
my $func = $modHash->{$fName};
Log3 $name, 5, "$name: calling $fName for reading $reading and val $val";
no strict "refs";     
my $ret = eval { &{$func}($hash,$reading,$val) };
if( $@ ) {         
Log3 $name, 3, "$name: error calling $fName: $@";
return;
}                   
use strict "refs";
return $ret
}
return;
}

...

if (!Modbus_TryCall($logHash, 'ModbusReadingsFn', $reading, $val)) {
Log3 $name, 4, "$name: ParseObj assigns value $val to $reading";
readingsBulkUpdate($logHash, $reading, $val);
}


Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 17 April 2019, 09:50:14
Hallo Stefan,

Werde ich mal testen. Kann aber nicht sagen wann ich dazu komme.

Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 01 Mai 2019, 20:05:26
Hallo Stefan,

jetzt bin ich auch dazu gekommen den passiven Modus zu testen, leider erfolglos. Es ist mir nicht gelungen mein Modbus/TCP Gateway als benutzbares Gerät zu vermitteln. Nachfolgend findest Du die relevanten Logfileeinträge, die zugehörigen "defines ..." habe ich als Komentar eingefügt.

Dass der passive Empfang grundsätzlich funktioniert ist aus dem letzten Beispiel ersichtlich, da ist DimplexWWP über das  protocol RTU im mode master mit  ECS-AP:8899 verbunden. Gleichzeitig besteht auch eine Verbindung zwischen iobrokerServer und der Wärmepumpe. Die Antworten auf die Anfragen des iobrokerServers werden in fhem erkannt und im logfile wird notiert, dass Nachrichten vom slave kamen obwohl keine Anfragen gestellt wurden.

Hier der Auszug aus dem Logfile
2019.04.28 01:59:02 1: Including fhem.cfg
2019.04.28 01:59:02 3: telnetPort: port 7072 opened
2019.04.28 01:59:03 3: WEB: port 8083 opened
2019.04.28 01:59:03 3: WEBphone: port 8084 opened
2019.04.28 01:59:03 3: WEBtablet: port 8085 opened
2019.04.28 01:59:03 2: eventTypes: loaded 395 events from ./log/eventTypes.txt

#define DimplexWWP ModbusRTUDimplexWWP 1 passive RTU

2019.04.28 01:59:03 1: Including FHEM/Wi18TU.cfg
2019.04.28 01:59:03 3: DimplexWWP: defined with id 1, protocol RTU, mode passive
2019.04.28 01:59:03 1: Including ./log/fhem.save
2019.04.28 01:59:03 3: DimplexWWP: SetIODev found no usable physical modbus device
2019.04.28 01:59:03 3: DimplexWWP: Notify / Init: no IODev for communication
2019.04.28 01:59:03 0: Featurelevel: 5.9
2019.04.28 01:59:03 0: Server started with 12 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:24412)
2019.04.28 02:01:48 0: Server shutdown



2019.04.28 02:01:50 1: Including fhem.cfg
2019.04.28 02:01:50 3: telnetPort: port 7072 opened
2019.04.28 02:01:50 3: WEB: port 8083 opened
2019.04.28 02:01:51 3: WEBphone: port 8084 opened
2019.04.28 02:01:51 3: WEBtablet: port 8085 opened
2019.04.28 02:01:51 2: eventTypes: loaded 395 events from ./log/eventTypes.txt

#define DimplexWWP ModbusRTUDimplexWWP 1 passive ECS-AP:8899 RTU

2019.04.28 02:01:51 1: Including FHEM/Wi18TU.cfg
2019.04.28 02:01:51 3: DimplexWWP: define as passive is only possible for serial connections, not with a defined host:port
2019.04.28 02:01:51 1: define DimplexWWP ModbusRTUDimplexWWP 1 passive ECS-AP:8899 RTU: Define as passive is only possible for serial connections, not with a defined host:port
2019.04.28 02:01:51 1: Including ./log/fhem.save
Define as passive is only possible for serial connections, not with a defined host:port
./log/fhem.save: Please define DimplexWWP first
2019.04.28 02:01:51 0: Featurelevel: 5.9
2019.04.28 02:01:51 0: Server started with 11 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:24455)
2019.04.28 02:04:07 0: Server shutdown



2019.04.28 02:04:09 1: Including fhem.cfg
2019.04.28 02:04:09 3: telnetPort: port 7072 opened
2019.04.28 02:04:09 3: WEB: port 8083 opened
2019.04.28 02:04:10 3: WEBphone: port 8084 opened
2019.04.28 02:04:10 3: WEBtablet: port 8085 opened
2019.04.28 02:04:10 2: eventTypes: loaded 395 events from ./log/eventTypes.txt

#define RS485 Modbus ECS-AP:8899 RTU
#define DimplexWWP ModbusRTUDimplexWWP 1 passive RTU
#attr DimplexWWP IODev RS485

2019.04.28 02:04:10 1: Including FHEM/Wi18TU.cfg
2019.04.28 02:04:10 1: define RS485 Modbus ECS-AP:8899 RTU: wrong syntax: define <name> Modbus [tty-devicename|none]
2019.04.28 02:04:10 3: DimplexWWP: defined with id 1, protocol RTU, mode passive
2019.04.28 02:04:10 3: DimplexWWP: SetIODev from DimplexWWP to RS485 but RS485 does not exist (yet?)
2019.04.28 02:04:10 3: DimplexWWP: SetIODev found no usable physical modbus device
2019.04.28 02:04:10 1: Including ./log/fhem.save
2019.04.28 02:04:10 3: No I/O device found for DimplexWWP
wrong syntax: define <name> Modbus [tty-devicename|none]
2019.04.28 02:04:10 3: DimplexWWP: SetIODev from DimplexWWP to RS485 but RS485 does not exist (yet?)
2019.04.28 02:04:10 3: DimplexWWP: SetIODev found no usable physical modbus device
2019.04.28 02:04:10 3: DimplexWWP: Notify / Init: no IODev for communication
2019.04.28 02:04:10 0: Featurelevel: 5.9
2019.04.28 02:04:10 0: Server started with 12 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:24460)
2019.04.28 02:08:11 0: Server shutdown



2019.04.28 16:51:18 1: Including fhem.cfg
2019.04.28 16:51:18 3: telnetPort: port 7072 opened
2019.04.28 16:51:18 3: WEB: port 8083 opened
2019.04.28 16:51:18 3: WEBphone: port 8084 opened
2019.04.28 16:51:18 3: WEBtablet: port 8085 opened
2019.04.28 16:51:19 2: eventTypes: loaded 395 events from ./log/eventTypes.txt

#define DimplexWWP ModbusRTUDimplexWWP 1 1 ECS-AP:8899 RTU

2019.04.28 16:51:19 1: Including FHEM/Wi18TU.cfg
2019.04.28 16:51:19 3: DimplexWWP: defined with id 1, interval 1, protocol RTU, mode master, connection to ECS-AP:8899
2019.04.28 16:51:19 1: Including ./log/fhem.save
2019.04.28 16:51:19 3: Opening DimplexWWP device ECS-AP:8899
2019.04.28 16:51:19 0: Featurelevel: 5.9
2019.04.28 16:51:19 0: Server started with 12 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:31861)
2019.04.28 16:51:19 3: DimplexWWP device opened
2019.04.29 00:44:33 3: DimplexWWP: read got new data while idle, drop buffer 01020200fe3838
2019.04.29 00:44:33 3: DimplexWWP: read got new data while idle, drop buffer 01010200fe387c

Was kann/muss ich tun um den passiven Modus richtig zu aktivieren?

Gruß Basil

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 Mai 2019, 21:05:01
Hallo Basil,

der passive Modus ist dafür gedacht auf einer seriellen Leitung (RS232 oder RS485) mitzulesen wenn zwei andere Geräte darüber per Modbus RTU oder ASCII kommunizieren und aus den dabei übertragenen Inhalten Readings zu machen.
Du brauchst also z.B. eine Wärmepumpe mit Modbus RTU per RS485, die von einem anderen Master oder Gateway abgefragt wird.

Da es um serielle Kommunikation geht, muss also zunächst ein IODev erzeugt werden, z.B.:
define ModbusRS232 Modbus /dev/dualser0@9600

Danach muss ein passives ModbusAttr-Gerät (oder ein anderes Modul auf Basis von Modbus wie ModbusSET oder ModbusSDM630M) erzeugt werden, welches das zuvor definierte IODev benutzt, z.B.:
define WP ModbusAttr 1 passive

Bei ModbusAttr muss man dann natürlich noch Attribute angeben, damit klar ist, wie die Inhalte zu interpretieren sind (Länge der Objekte, Unpack-Code / Format etc.)

Wenn Du beim Define eine Portnummer wie :8899 angibst, dann geht das Modul davon aus, das Du keine serielle sondern eine TCP basierte Kommunikation haben möchtest. Dafür ist ein Mitlesen nicht implementiert (sonst müsste Fhem das Ethernet-Interface in den Promicious-Mode bringen und erst mal den TCP-Stream reassemblieren ...).

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: klaus.schauer am 01 Mai 2019, 21:50:34

Danach muss ein passives ModbusAttr-Gerät (oder ein anderes Modul auf Basis von Modbus wie ModbusSET oder ModbusSDM630M) erzeugt werden, welches das zuvor definierte IODev benutzt, z.B.:
define WP ModbusAttr 1 passive

Wäre es also z. B. beim dem neuen Modul ModbusElsnerWS so möglich, mit zusätzlichen passiven Devices auf dem gleichen Fhem oder auf einem weiteren Fhem-Gerät mitzulesen, falls die weiteren Devices mit "passive" definiert werden:

Aktives Device
define modbus Modbus /dev/ttyUSB1@19200,8,E,1
define WS_active ModbusElsnerWS id=1 interval=1

Passives Device auf weiterer Fhem-Installation
define modbus Modbus /dev/ttyUSB1@19200,8,E,1
define WS_passive ModbusElsnerWS id=1 interval=passive
Das wäre durchaus praktisch, da man dann die Auswertung der Wetterstationsdaten noch individueller für die Steuerung mehrerer Gruppen von Rollos festlegen könnte. Das würde ich dann direkt in die commandref des Moduls aufnehmen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 Mai 2019, 21:53:50
Hallo Klaus,

eigentlich sollte es so funktionieren.
Nur leider hat es noch kaum jemand ausser mir selbst getestet ;-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: klaus.schauer am 01 Mai 2019, 21:57:19
eigentlich sollte es so funktionieren.
Nur leider hat es noch kaum jemand ausser mir selbst getestet ;-)

Ich probiere das bei Gelegenheit aus.
Titel: Antw: Modbsus passiv-Modus
Beitrag von: klaus.schauer am 04 Mai 2019, 19:09:06
Leider funktioniert ein Passiv-Device parallel zu einem Master-Device auf einem Fhem-System nicht:

define modbus Modbus /dev/ttyUSB1@19200,8,E,1
define WS ModbusElsnerWS id=1 interval=1
define WS_passive ModbusElsnerWS id=1 interval=passive

Internals:
   .getList   
   .setList   reconnect:noArg saveAsModule
   .updateSetGet 0
   DEF        id=1 interval=passive
   FUUID      5ccdbe65-f33f-9749-6ec3-30d1a2d40a0c30ad
   MODBUSID   1
   MODE       passive
   MODULEVERSION Modbus 4.1.2 - 17.4.2019
   NAME       WS_passive
   NOTIFYDEV  global
   NR         129
   NTFY_ORDER 50-WS_passive
   PROTOCOL   RTU
   STATE      disconnected
   TYPE       ModbusElsnerWS
   .attraggr:
   .attrminint:
   READINGS:
     2019-05-04 18:47:50   state           disconnected
Attributes:
   enableControlSet 1
   room       ElsnerWS
   verbose    5

Folgende Fehlermeldungen kommen beim Restart:

...
2019.05.04 18:47:50 3: WS: RegisterAtIODev called from SetIODev registers WS at modbus with id 1, MODE master, PROTOCOL RTU
2019.05.04 18:47:50 3: WS: Notify / Init: using modbus for communication
2019.05.04 18:47:50 5: WS_passive: UnregAtIODev called from Notify
2019.05.04 18:47:50 4: WS_passive: GetIOHash (called from Notify) didn't find valid IODev hash key, calling SetIODev now
2019.05.04 18:47:50 5: WS_passive: SetIODev called from GetIOHash
2019.05.04 18:47:50 5: WS_passive: CheckIOCompat (called from SetIODev) for WS_passive and modbus: modbus is locked to mode master by WS
2019.05.04 18:47:50 5: WS_passive: UnregAtIODev called from SetIODev
2019.05.04 18:47:50 3: WS_passive: SetIODev found no usable physical modbus device
2019.05.04 18:47:50 4: WS_passive: GetIOHash didn't find IODev attribute or matching physical serial Modbus device
2019.05.04 18:47:50 3: WS_passive: Notify / Init: no IODev for communication
...
2019.05.04 18:47:59 3: Opening modbus device /dev/ttyUSB1
2019.05.04 18:47:59 3: Setting modbus serial parameters to 19200,8,E,1
2019.05.04 18:47:59 3: modbus device opened
2019.05.04 18:47:59 0: Featurelevel: 5.9
2019.05.04 18:47:59 0: Server started with 94 defined entities (fhem.pl:19265/2019-04-26 perl:5.024001 os:linux user:fhem pid:6383)

Setzt man ein set WS_passive reconnect ab, so kommt die Fehlermeldung:

Unknown argument HASH(0x42704e0), choose one of reconnect saveAsModule

Vielleicht liegt es auch an meinem neuen Modul. Ich musste insbesondere ein paar Routinen wie _Initialize, _Define etwas umbiegen, siehe Moduldatei.

P. S. Die Hash-Fehlermeldung hat sich geklärt. Ich hatte die neue Parse-Funktion mit
$hash->{parseParams}      = 1;
aktiviert und nur in _Define die Übergabeparaneter an das Modbus-Modul wieder "zurückgewandelt".
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 Mai 2019, 11:57:36
Hallo Klaus,

auf einem Fhem-System kann man über ein gemeinsames serielles Interface nur eine Art von logischem Modbus-Device haben (Master, Slave oder Passive).
Wenn der Master auf dem selben Fhem läuft, muss man ja auch nicht passiv mitlesen sondern kann direkt auf die Readings des Master zugreifen.

Du müsstest es deshalb auf einer zusätzlichen Fhem-Installation testen.
Der typische Anwendungsfall ist ja dass ein anderer Master bereits am Bus hängt. (z.B. Wechselrichter / Solar-Steuerung, die einen Modbus-Stromzähler abfragt).
Da Modbus nur einen Master am Bus vorsieht, ist der passive Modus eine Möglichkeit, trotzdem die Daten des Slaves lesen und verarbeiten zu können.

Beim Programmieren hatte ich mir lange überlegt, ob ich den Aufwand treiben und es ermöglichen soll, dass sowohl ein Master als auch ein Slave o.ä. im gleichen Fhem auf dem gleichen Interface laufen kann. Das hätte einige Komplikationen beim Parsen mit sich gebracht. Unterm Strich habe ich dann aber gedacht dass das eher von akademischem Interesse wäre und in der Praxis keine Anwendung dafür existiert. Deshalb wird beim ersten Define eines logischen Modbus-Geräts das zugehörige serielle Device per "Lock" auf einen Mode (Master, Slave, Passive oder Relay) und ein Protokoll (RTU / ASCII) gesetzt.

Sorry falls ich das nicht deutlich genug geschrieben habe.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: klaus.schauer am 05 Mai 2019, 17:32:21
Passt schon so. Ein zweites passives Device neben dem Master ist wirklich nur ein Luxusproblem.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 07 Mai 2019, 19:42:21
Hallo Stefan,

bei der Definition von Datenpunkten eines Modbusgerätes besteht ja die Möglichkeit, den ausgelesenen Registerwerten über das Attribut map den ausgelesenen Code in verständliche Sprache zu konvertieren. Bei Status- oder Störmeldungen wird die map so umfangreich, dass, wenn alles in einer Zeile untergebracht werden soll, die Übersicht verloren geht. Aus meiner Sicht ist es wünschenswert jede Paarung Schlüssel : Text, in eine neue Zeile schreiben zu können. Das führt jetzt aber zu unschönen Effekten bei der Konvertierung der Codes in Text.
Die Steuerzeuchen \t \n ect. ,die die Lesbarkeit  im Definitionsfile ermöglichen, werden zum Bestandteil der map. Stehen die Steuerzeichen bei den codes, dann werden diese nicht gematched oder die Steuerzeichen sind Bestandteil der Texte geworden, dann sieht deren Darstellung auf dem Bildschirm unmöglich aus.

Hier ein Beispiel der Datenpunktdefinition mit den möglichen vorgegebenen Sperrursachen:

'h104' => { reading => 'wp_dis_Waermepumpe_Sperre',
name => 'Waermepumpe Sperre',
unpack => 'n',
                    map => '0:keine Sperre,
2:Volumenstrom,
5:Funktionskontrolle,
6:Einsatzgrenze HT,
7:Systemkontrolle,
8:Verzögerung Umschaltung Kühlen,
9:Pumpenvorlauf,
10:Mindeststandzeit,
11:Netzbelastung,
12:Schaltspielsperre,
13:Warmwasser Nacherwärmung,
14:Regenerativ,
15:EVU-Sperre,
16:Sanftanlasser,
17:Durchfluss,
18:Einsatzgrenze Wärmepumpe,
19:Hochdruck,
20:Niederdruck,
21:Einsatzgrenze Wärmequelle,
23:System Grenze,
24:Last Primärkreis,
25:Sperre Extern,
33:EvD Initialisierung,
34:2.Wärmeerzeuger freigegeben,
35:Störung,
36:Pumpenvorlauf,
37:Mindeststandzeit,
38:Netzbelastung,
39:Schaltspielsperre,
40:Einsatzgrenze Wärmequelle,
41:Sperre Extern,
42:2.Wärmeerzeuger freigegeben,
43:Störung',
poll => 1,
},


Durch Einfügen von     $map =~ s/\s+/ /g;       in 98_Modbus.pm sind diese Effekte verschwunden:

.......
sub Modbus_MapConvert($$$;$)
{
    my ($hash, $map, $val, $reverse) = @_;
    my $name = $hash->{NAME};

    $map =~ s/\s+/ /g; # substitute all \t \n etc. by one space only
   
    if ($reverse) {
        $map =~ s/([^, ][^,\$]*):([^,][^,\$]*),? */$2:$1, /g;   # reverse map
    }
    # spaces in words allowed, separator is ',' or ':'
......
 

Kannst Du Dir vorstellen, diese Änderung ins 98_Modbus.pm zu implementieren?

Gruß Basil
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Mai 2019, 18:18:01
Hallo Basil,

ich habe es mal in MapConvert und MapToHint eingebaut und hoffe, dass es keine Seiteneffekte hat.
Eigentlich sollte bisher niemand mit Maps, die mehrere aufeinanderfolgende Whitespaces enthalten, arbeiten müssen ...

Teste doch mal ob es bei Dir so passt, dann riskiere ich den check in :-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Rudy am 12 Mai 2019, 12:37:25
Versuche gerade das Modbus-Modul im Zusammenhang mit dem Modul ModbusSDM630M zu nutzen. Das Einbinden funktioniert grundsätzlich auch. Daten vom Stromzähler kommen grundsätzlich in FHEM beim SDM630-Modul an. Sobald ich aber meinen SDM630-Stromzähler mit Fhem verbinde wechselt das Modbus-Modul ständig (alle 2 Sekunden) in den Status disconnected und wieder zurück.

Die Verbindung zwischen dem SDM630 und meinem FHEM-Raspi erfolgt über den Digitus DA-70157 USB-to-Serial-RS485-Converter. Das Kabel ist ein 4-adriges Telefonkabel (von welchem nur zwei Adern und Ground genutzt werden) mit 6,5 m Länge. An beiden Enden habe ich bei jedem Kabel (außer Ground) einen 120-Ohm-Widerstand eingelötet.

Kann mir jemand einen Tipp geben, woran es liegen könnte? Ich vermute, dass noch weitere Angaben meinerseits fehlen. Da ich aber nicht sicher weiß welche, einfach bescheid sagen und ich liefere die selbstverständlich gerne nach.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 12 Mai 2019, 20:50:55
Hallo Stefan,

die Änderung im MapConvert läuft bei mir schon seit einer Woche und verursacht keine Probleme. 

Gruß Basil
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 12 Mai 2019, 21:17:47
Hallo Stefan,

Mit MapToHint ist wohl nicht die Hintliste sondern wahrscheinlich diese Konstruktion gemeint?:

'h131' => { reading => 'Sprache',
name => 'Sprache',
unpack => 'n',
                    map => '0:Deutsch,
1:English,
2:Francais,
3:Italiano,
4:Nederland,
5:Portugues,
6:Polski,
7:Svenska,
8:Slovensko,
9:Espanol,
10:Cesky,
11:Suomi,
12:Norsk,
13:Dansk',
poll => 1,
polldelay => 60,
set => 1,
},
Die Liste wird korrekt umgesetzt und erscheint als Klappmenu. Nach Auswahl einer Sprache und anschließendem set erscheint die gewählte Sprache.

Gruß Basil
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 15 Mai 2019, 10:49:23
Hallo Rudy,

Bitte setze doch verbose für beide Devices auf 5 und poste das Log, so dass man sieht was wirklich passiert.

Die Verbindung zwischen dem SDM630 und meinem FHEM-Raspi erfolgt über den Digitus DA-70157 USB-to-Serial-RS485-Converter. Das Kabel ist ein 4-adriges Telefonkabel (von welchem nur zwei Adern und Ground genutzt werden) mit 6,5 m Länge. An beiden Enden habe ich bei jedem Kabel (außer Ground) einen 120-Ohm-Widerstand eingelötet.

Das klingt nicht gut. Wie genau hast Du die Widerstände eingelötet?
Kannst Du einen Verdrahtungsplan posten?

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Rudy am 17 Mai 2019, 17:14:41
Hallo Stefan.
Bitte setze doch verbose für beide Devices auf 5 und poste das Log, so dass man sieht was wirklich passiert.

Das klingt nicht gut. Wie genau hast Du die Widerstände eingelötet?
Kannst Du einen Verdrahtungsplan posten?
Nach meinem Post hatte ich das Modbus Gateway wegen der ständigen disconnects von meinem FHEM-Pi getrennt. Um jetzt die gewünschten Daten liefern zu können habe gestern ich die Verbindung wieder hergestellt und nun gab keine disconnects des Modbus-Moduls mehr. Keine Ahnung woran das nun gelegen haben mag. Vielleicht hat ein zwischenzeitlicher Neustart des ganzen Systems da für Besserung gesorgt.

Ganz in Ordnung ist die Verbindung aber noch nicht. So gibt es im Log noch einige Timouts. Nachfolgend einige Beispiele.
2019.05.17 16:59:56 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 10, len 10 for device Stromzaehler reading System_Type (getUpdate), queued 8.01 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 16:59:58 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 36, len 8 for device Stromzaehler reading System_Power__W (getUpdate), queued 10.01 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:00 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 0, len 10 for device Stromzaehler reading Demand_Time__minutes (getUpdate), queued 12.02 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:02 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 40, len 40 for device Stromzaehler reading CosPhi_L3__grd (getUpdate), queued 14.03 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:04 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 0, len 40 for device Stromzaehler reading Voltage_L1__V (getUpdate), queued 16.03 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:06 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 334, len 30 for device Stromzaehler reading THD_Voltage_L1_L2__prz (getUpdate), queued 18.04 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:00:08 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 240, len 30 for device Stromzaehler reading THD_Current_L1__prz (getUpdate), queued 20.05 secs ago, sent 2.01 secs ago, read buffer empty
und2019.05.17 17:09:21 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 334, len 30 for device Stromzaehler reading THD_Voltage_L1_L2__prz (getUpdate), queued 11.45 secs ago, sent 2.14 secs ago, read buffer empty
2019.05.17 17:09:23 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 0, len 10 for device Stromzaehler reading Demand_Time__minutes (getUpdate), queued 13.61 secs ago, sent 2.03 secs ago, read buffer empty
2019.05.17 17:09:25 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 200, len 40 for device Stromzaehler reading Voltage_L1_to_L2__V (getUpdate), queued 15.71 secs ago, sent 2.09 secs ago, read buffer empty
2019.05.17 17:09:27 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 4, type i, adr 0, len 40 for device Stromzaehler reading Voltage_L1__V (getUpdate), queued 17.72 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:09:29 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 20, len 10 for device Stromzaehler reading Modbus_Node_adr (getUpdate), queued 19.72 secs ago, sent 2.00 secs ago, read buffer empty
2019.05.17 17:09:31 3: ModbusGateway: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 88, len 2 for device Stromzaehler reading Relay2_Energy_Type (getUpdate), queued 21.73 secs ago, sent 2.01 secs ago, read buffer empty
Und nachdem ich mich nun heute zurückmelden wollte und die Verbindung zum SDM630 erneut hergestellt habe kommen aktuell garkeine neuen Daten mehr an. Stattdessen gibt es reihenweise Timeouts wie schon oben geposted.

Die Verkabelung und wie ich die Widerstände eingelötet habe, habe ich versucht in dem von dir gewünschten Verdrahtungsplan darzustellen (s. Anhang). Ich hoffe, das entspricht deinen Vorstellungen. Ist das erste mal, dass ich so ein Programm zur Erstellung genutzt habe.

Ist es evtl. sinnvoller, nur an einer Seite die Widerstände zu verwenden?

Gruß Rudy
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 Mai 2019, 09:53:42
Hallo Rudy,

das mit dem Abschlusswiderstand hast Du falsch verstanden.
Der muss zwischen A und B.

Schau mal z.B. diese Diskussion an:
https://www.sps-forum.de/feldbusse/44809-abschlusswiderstaende-fuer-modbus-rs485.html
oder
https://www.janitza.de/kommunikation-ueber-die-rs485-schnittstelle.html

Viele USB-RS485-Adapter haben den schon drin. Durch zusätzliche Parallelschaltungen kann dann ggf. gar nichts mehr übertragen werden.

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 03 Juli 2019, 09:40:49
Hallo,

ich wusste nicht so Recht wohin damit aber es geht um den Modbus:

Ich habe vor kurzem ein FHEM Update ausgeführt und nun wird mein Log damit gefüllt:

2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request temperature
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request humidity
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Abluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Abluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request temperature
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request humidity
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Zuluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Zuluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 23.1 to temperature
2019.07.03 09:13:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 45.1 to humidity
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request temperature
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request humidity
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Abluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Abluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request temperature
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request humidity
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Zuluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Zuluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 44.8 to humidity
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 23.2 to temperature
2019.07.03 09:23:48 4: Mod_Lueftung_Sensor_Zuluft: ParseObj assigns value 47 to humidity
2019.07.03 09:23:49 4: Mod_Lueftung_Sensor_Zuluft: ParseObj assigns value 20.5 to temperature
2019.07.03 09:28:29 1: Das diBMode hat ausgeloest. Sommer mode 0 ueberschuss 490.181516
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request temperature
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: GetUpdate will request humidity
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Abluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: DoRequest called from GetUpdate created request: id 3, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Abluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request temperature
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Zuluft: GetUpdate will request humidity
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 1, len 1 for device Mod_Lueftung_Sensor_Zuluft reading temperature (getUpdate), read buffer empty
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Zuluft: DoRequest called from GetUpdate created request: id 4, fCode 4, type i, adr 2, len 1 for device Mod_Lueftung_Sensor_Zuluft reading humidity (getUpdate), read buffer empty
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 23.2 to temperature
2019.07.03 09:33:48 4: Mod_Lueftung_Sensor_Abluft: ParseObj assigns value 45.1 to humidity
2019.07.03 09:33:50 4: Mod_Lueftung_Sensor_Zuluft: ParseObj assigns value 45.8 to humidity

Die Modbus Sensoren (TYPE: ModbusAttr) werden alle 10 Minuten gepollt (INTERVAL: 600).
Das Verbose in global steht auf 3. Das Verbose in dem jeweiligen ModbusAttr Device steht auf 4... Werte aus den jeweils gelesenen zwei Registern kommen an. Was ist hier das Problem?


Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 03 Juli 2019, 10:07:44
Das Verbose in dem jeweiligen ModbusAttr Device steht auf 4
das ist dein Problem :) , gehe runter auf 3 und es wird Ruhe sein ....
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 26 Juli 2019, 14:34:22
Hallo Stefan,

kannst du dir das hier mal ansehen (https://forum.fhem.de/index.php/topic,44710.msg961461.html#msg961461).
Danke.

Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nestor am 31 Juli 2019, 20:49:44
I receive following warning upon startup:
PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_Modbus.pm line 2956, <$fh> line 1444.

I suppose there are some comment markers missing in the source:
--- - 2019-07-31 20:48:23.650336998 +0200
+++ /srv/fhem/FHEM/98_Modbus.pm 2019-07-31 20:46:11.724671421 +0200
@@ -2953,8 +2953,8 @@
     my $qlen   = ($ioHash->{QUEUE} ? scalar(@{$ioHash->{QUEUE}}) : 0);
     
     #Log3 $name, 4, "$name: DoRequest called from " . Modbus_Caller() . " with $type$adr, objLen $objLen / reqLen " .
-        ($reqLen ? $reqLen : "-") . " to id $devId, op $op, qlen $qlen" .
-        ((defined($v1) && $op eq 'write') ? ", value hex " . unpack ('H*', $v1) : "");
+        #($reqLen ? $reqLen : "-") . " to id $devId, op $op, qlen $qlen" .
+        #((defined($v1) && $op eq 'write') ? ", value hex " . unpack ('H*', $v1) : "");
     $reqLen = $objLen if (!$reqLen);            # combined reqLen from GetUpdate or scans
 
     return if (ModbusLD_CheckDisable($hash));   # returns if there is no io device
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 30 August 2019, 16:41:47
Hallo, mal eine Frage zu lesen und schreiben von 2 Registern.

Ich habe im Gerät 2 aufeinanderfolgende Register.
0x3312 Total Generated energy L     KWH
0x3313 Total Generated energy H
angenommen ich lese die mit  len 2  ohne das ich noch weitere Parameter wie revRegs mitgebe, wäre dann das ganze richtig ?
ohne das 2te Register habe ich ja schon alles, da ich noch nicht so viele kWh  habe.
In der Beschreibung steht als Beispiel folgendes:

For the data with the length of 32 bits, such as power, using the L and H registers represent the low andhigh 16 bits value,respectively. e.g.The charging input rated power is actually 3000W, multiples of 100 times,then the value of 0x3002 register is 0x93E0 and value of 0x3003 is 0x0004


mein Aktueller code sieht so aus:
attr Solarlader obj-i13074-expr $val=($val/100)." kWh"
attr Solarlader obj-i13074-len 2
attr Solarlader obj-i13074-poll 1
attr Solarlader obj-i13074-reading EnergieGewinnTotal

Dann wäre da noch ein 3fach Register mit Datum und Uhrzeit was ich bisher einzeln wie folgt auslese:

attr Solarlader obj-h36883-expr (( sprintf("Minute:%02d Sekunde:%02d", (( $val >> 8 )),(( $val & 0xff )) ) ))
attr Solarlader obj-h36883-poll 1
attr Solarlader obj-h36883-reading clock1
attr Solarlader obj-h36883-set 1
attr Solarlader obj-h36884-expr (( sprintf("Stunde:%02d Tag:%02d", (( $val & 0xff )),(( $val >> 8 )) ) ))
attr Solarlader obj-h36884-poll 1
attr Solarlader obj-h36884-reading clock2
attr Solarlader obj-h36884-set 1
attr Solarlader obj-h36885-expr (( sprintf("Monat:%02d Jahr:%02d", (( $val & 0xff )),(( $val >> 8 )) ) ))
attr Solarlader obj-h36885-poll 1
attr Solarlader obj-h36885-reading clock3
attr Solarlader obj-h36885-set 1

Am liebsten wäre mir das mit len 3 z.b. zu lesen, so das man auch Datum und Uhrzeit setzen kann, denn leider läuft die Uhr ganz schön auseinander.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 30 August 2019, 19:28:12
Ich habe im Gerät 2 aufeinanderfolgende Register.
0x3312 Total Generated energy L     KWH
0x3313 Total Generated energy H
angenommen ich lese die mit  len 2  ohne das ich noch weitere Parameter wie revRegs mitgebe, wäre dann das ganze richtig ?
IMHO ja, bei meinem WR belegen fast alle Werte zwei Register. Um da viel Tipparbeit zu sparen habe ich gleich oben
 attr 8000TL dev-h-defExpr $val & 0x1FFFFFFF
attr 8000TL dev-h-defLen 2
attr 8000TL dev-h-defPoll 1
attr 8000TL dev-h-defUnpack N
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: noname41 am 15 September 2019, 10:27:50
Hallo  zusammen,

ich versuche gerade meinen ETA-Heizkessel per Modbus/TCP einzubinden.

Ich habe hierzu das Modul ModbusAttr verwendet. Er zeigt auch "opened" als Status an. Leider bekomme ich aber keine Werte.
Register ist als 1000 festgelegt. Gefunden habe ich hierzu folgende Anleitungen (leider nur für die Loxone)
https://www.loxforum.com/forum/hardware-zubeh%C3%B6r-sensorik/60229-miniserver-go-modbus-tcp

hier meine Einstellungen:
defmod etamod ModbusAttr 1 60 192.168.XX.XX:502 TCP
attr etamod userattr IODev obj-h1000-poll obj-h1000-reading obj-h1000-type obj-i1000-len
attr etamod obj-h1000-poll 1
attr etamod obj-h1000-reading Ladezustand
attr etamod obj-i1000-len 2
attr etamod verbose 5

kann mir da jemand einen Tipp geben?

Danke!
LG
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 15 September 2019, 13:32:51
warum 2x h und 1x i ?
ich würde aus dem attr etamod obj-i1000-len 2 als erstes ein attr etamod obj-h1000-len 2 machen
was mir auch noch auffällt ist das du keine Angabe machst wir das Register 1000 zu decodieren ist , fang mal mit
attr etamod obj-h1000-Unpack N an
und gibt es von ETA keine Doku wie die Modbus Register belegt sind ?
Tipp : wenn es doch noch mehr Register werden sollten : das poll , len & Unpack nach oben in die dev-h-def Attribute packen, spart Tipparbeit. (siehe #313)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: noname41 am 15 September 2019, 19:09:47
Danke das war es!

Nun kann ich mit dem Kessel kommunizieren. Sehr fein :-)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Karflyer am 17 September 2019, 13:34:21
Ich erhalte beim Neustart von FHEM die folgende Fehlermeldung im Log:
PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_Modbus.pm line 2960, <$fh> line 2221
Benutzt wird von mir das modbusattr-Modul. Ich kann an meinen Einstellungen nicht erkennen was diese Fehlermeldung verursacht.
Hat jemand eine Idee?

Grüße
Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nestor am 17 September 2019, 13:57:35
Ich erhalte beim Neustart von FHEM die folgende Fehlermeldung im Log:
PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/98_Modbus.pm line 2960, <$fh> line 2221

It's an error in the code. I already posted the fix in July but the developer never bothered to respond.
https://forum.fhem.de/index.php/topic,75638.msg963206.html#msg963206
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 September 2019, 14:56:07
Sorry, das ist urlaubsbedingt hinten runter gefallen.
Eine neue Version ist jetzt eingecheckt.

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 19 September 2019, 11:43:58
Hallo zusammen,

verwendet jemand den Relay-Mode des ModbusAttr-Moduls?
Ich habe das von Stefan beschriebene Szenario bei mir installiert und bekomme leider in der zweiten Instanz entweder unsinnige Werte oder Timeouts
zum Beispiel:
HKVEG1: Timeout waiting for a modbus response request: id 57, fCode 1, tid 203, type c, adr 2, len 1 for device HKVEG1 reading HK4 (getUpdate), queued 18.69 secs ago, sent 3.00 secs ago, read buffer empty
2019.09.19 11:49:01 3 : HKVEG1: Timeout waiting for a modbus response request: id 57, fCode 1, tid 216, type c, adr 6, len 1 for device HKVEG1 reading HK8 (getUpdate), queued 21.69 secs ago, sent 3.00 secs ago, read buffer empty


Ich habe aktuell drei solcher Modbus-Geräte, zwei Eigenbau und ein "kommerzielles" ( Fronius Solarwechselrichter). Das Problem tritt bei allen drei Geräten gleichermaßen auf.




Die Relay-Instanz läuft gut, da stimmt alles.
list HKVEG1 :
Internals:
   CHANGED   
   DEF        7 20
   FUUID      5c7597dc-f33f-53e7-ac4f-6112c82865bad6fd
   INTERVAL   20
   IODev      MBGate
   MODBUSID   7
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       HKVEG1
   NOTIFYDEV  global
   NR         135
   NTFY_ORDER 50-HKVEG1
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1568885848.93544
   TRIGGERTIME_FMT 2019-09-19 11:37:28
   TYPE       ModbusAttr
   lastUpdate 1568885828.93544
   FRAME:
   READ:
   READINGS:
     2019-09-19 11:37:05   1W-val-1        35.0
     2019-09-19 11:36:06   1WConvertT      0
     2019-09-19 11:37:08   1WScanBus       0
     2019-09-19 11:36:26   1Wcount         1
     2019-09-19 11:36:06   HK-ALL-OFF      0
     2019-09-19 11:37:05   HK-ALL-ON       0
     2019-09-19 11:33:46   HK1             off
     2019-09-19 11:32:46   HK2             off
     2019-09-19 11:36:06   HK3             off
     2019-09-19 11:37:15   HK4             on
     2019-09-19 11:37:07   HK5             on
     2019-09-19 11:37:01   HK6             on
     2019-09-19 11:37:08   HK7             on
     2019-09-19 11:37:15   HK8             on
     2019-09-19 11:37:08   HK9             on
     2019-09-19 10:55:46   state           opened
   REMEMBER:
     lrecv      1568885828.3477
     lsend      1568885828.45192
   gotReadings:
     HK8        on
   lastRead:
     c0         1568885566.98978
     c1         1568885766.60762
     c16        1568885766.37595
     c17        1568885828.23412
     c18        1568885825.65348
     c19        1568885766.26195
     c2         1568885835.65742
     c3         1568885827.88991
     c4         1568885821.08267
     c5         1568885828.00435
     c6         1568885835.77551
     c7         1568885828.11922
     c8         1568885626.42869
     i0         1568885786.54816
     i13        1568885825.77087
Attributes:
   dev-c-combine 1
   dev-c-defPoll 1
   dev-i-defPoll 1
   disable    0
   event-min-interval .*:360
   event-on-change-reading .*
   obj-c0-map 0:off,1:on
   obj-c0-reading HK2
   obj-c0-set 1
   obj-c1-map 0:off,1:on
   obj-c1-reading HK3
   obj-c1-set 1
   obj-c16-reading 1WConvertT
   obj-c16-set 1
   obj-c17-reading 1WScanBus
   obj-c17-set 1
   obj-c18-reading HK-ALL-ON
   obj-c18-set 1
   obj-c19-reading HK-ALL-OFF
   obj-c19-set 1
   obj-c2-map 0:off,1:on
   obj-c2-reading HK4
   obj-c2-set 1
   obj-c3-map 0:off,1:on
   obj-c3-reading HK5
   obj-c3-set 1
   obj-c4-map 0:off,1:on
   obj-c4-reading HK6
   obj-c4-set 1
   obj-c5-map 0:off,1:on
   obj-c5-reading HK7
   obj-c5-set 1
   obj-c6-map 0:off,1:on
   obj-c6-reading HK8
   obj-c6-set 1
   obj-c7-map 0:off,1:on
   obj-c7-reading HK9
   obj-c7-set 1
   obj-c8-map 0:off,1:on
   obj-c8-reading HK1
   obj-c8-set 1
   obj-c9-map 0:off,1:on
   obj-i0-expr ($val >> 8 )
   obj-i0-reading 1Wcount
   obj-i13-expr ( $val / 2 )
   obj-i13-format %.1f
   obj-i13-poll 1
   obj-i13-reading 1W-val-1
   room       ,Modbus
   userattr   dev-c-combine dev-c-defPoll dev-i-defPoll obj-c0-map obj-c0-reading obj-c0-set obj-c1-map obj-c1-reading obj-c1-set obj-c16-reading obj-c16-set obj-c17-reading obj-c17-set obj-c18-reading obj-c18-set obj-c19-reading obj-c19-set obj-c2-map obj-c2-reading obj-c2-set obj-c3-map obj-c3-reading obj-c3-set obj-c4-map obj-c4-reading obj-c4-set obj-c5-map obj-c5-reading obj-c5-set obj-c6-map obj-c6-reading obj-c6-set obj-c7-map obj-c7-reading obj-c7-set obj-c8-map obj-c8-reading obj-c8-set obj-c9-map obj-i0-expr obj-i0-reading obj-i13-expr obj-i13-format obj-i13-poll obj-i13-reading
   verbose    0

Das entsprechende Relay auf derselben Instanz:
Internals:
   CHANGED   
   CONNECTS   2
   DEF        57 relay 192.168.3.15:1502 TCP to HKVEG1
   DeviceName 192.168.3.15:1502
   EXPECT     request
   FD         10
   FUUID      5c759876-f33f-53e7-e63d-dbf32ea83003afce
   IODev      RelayHKVEG1
   LASTCONN   RelayHKVEG1_192.168.3.10_52364
   MODBUSID   57
   MODE       relay
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       RelayHKVEG1
   NOTIFYDEV  global
   NR         136
   NTFY_ORDER 50-RelayHKVEG1
   PORT       1502
   PROTOCOL   TCP
   RELAY      HKVEG1
   RELID      7
   STATE      opened
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   CONNECTHASH:
     RelayHKVEG1_192.168.3.10_52282:
       BUF       
       EXPECT     request
       FD         26
       IODev      RelayHKVEG1_192.168.3.10_52282
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_52282
       NR         158
       PEER       192.168.3.10
       PORT       52282
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READ:
         BUFFER     
       READINGS:
         2019-09-19 10:56:35   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_52282
         lrecv      1568883872.15009
         lsend      1568883872.13761
       REQUEST:
         ADR        6
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        38
         TYPE       c
         DEVHASH:
     RelayHKVEG1_192.168.3.10_52364:
       BUF       
       EXPECT     request
       FD         19
       IODev      RelayHKVEG1_192.168.3.10_52364
       MODBUSID   57
       MODE       relay
       NAME       RelayHKVEG1_192.168.3.10_52364
       NR         182
       PEER       192.168.3.10
       PORT       52364
       PROTOCOL   TCP
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READ:
         BUFFER     
       READINGS:
         2019-09-19 11:04:13   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_52364
         lrecv      1568885913.98055
         lsend      1568885913.78336
       REQUEST:
         ADR        6
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        244
         TYPE       c
         DEVHASH:
   READ:
     BUFFER     
   READINGS:
     2019-09-19 10:55:46   state           opened
   REMEMBER:
     lsend      1568885912.19954
   defptr:
     RelayHKVEG1 57
   gotReadings:
Attributes:
   room       Modbus

Und auf der zweiten Instanz dann wie folgt:
Internals:
   CHANGED   
   DEF        57 10 192.168.3.15:1502 TCP
   DeviceName 192.168.3.15:1502
   EXPECT     response
   FD         33
   FUUID      5c5da6c9-f33f-53e7-4c38-f79a22e8f0185b2c
   INTERVAL   10
   IODev      HKVEG1
   LASTOPEN   1568884643.34217
   MODBUSID   57
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       HKVEG1
   NOTIFYDEV  global
   NR         37
   NTFY_ORDER 50-HKVEG1
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TIMEOUTS   1
   TRIGGERTIME 1568886620.04219
   TRIGGERTIME_FMT 2019-09-19 11:50:20
   TRIGGERTIME_SAVED
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1568886610.04219
   nextOpenDelay 60
   nextQueueRun 1568886617.98657
   nextTimeout 1568886618.98244
   FRAME:
   Helper:
     DBLOG:
       1W-val-1:
         logdb:
           TIME       1568884898.04194
           VALUE      35.0
   QUEUE:
     HASH(0x5c7d578)
     HASH(0x5c758c0)
     HASH(0x2867fd8)
     HASH(0x5c78fd8)
     HASH(0x5c8bed8)
     HASH(0x5c75d50)
     HASH(0x28580b8)
     HASH(0x5c8ce78)
     HASH(0x5c4c4d8)
     HASH(0x2863bb0)
     HASH(0x5c8aca0)
     HASH(0x286c080)
     HASH(0x5c7e5b0)
     HASH(0x5c6c938)
     HASH(0x5c77e40)
     HASH(0x5c8a0e8)
     HASH(0x5c89b08)
     HASH(0x45ff2f8)
     HASH(0x27f7c70)
     HASH(0x5c6f950)
     HASH(0x2846f08)
     HASH(0x38ec5f0)
     HASH(0x5c8c688)
     HASH(0x5c87940)
     HASH(0x2864018)
     HASH(0x28667c8)
     HASH(0x5c8aed8)
   READ:
     BUFFER     
   READINGS:
     2019-09-19 11:49:35   1W-val-1        35.0
     2019-09-19 11:00:41   1WConvertT      0
     2019-09-19 11:15:34   1WScanBus       0
     2019-09-19 11:15:33   1Wcount         1
     2019-09-19 11:15:32   HK-ALL-OFF      1
     2019-09-19 11:50:10   HK-ALL-ON       1
     2019-09-19 10:53:34   HK1             on
     2019-09-19 11:15:33   HK2             off
     2019-09-19 10:56:50   HK3             on
     2019-09-19 11:49:47   HK4             on
     2019-09-19 11:50:02   HK5             on
     2019-09-19 11:49:33   HK6             on
     2019-09-19 11:32:50   HK7             on
     2019-09-19 11:50:07   HK8             on
     2019-09-19 11:36:30   HK9             on
     2019-09-19 11:17:23   state           opened
   REMEMBER:
     lid        57
     lname      HKVEG1
     lrecv      1568886612.87726
     lsend      1568886615.98474
   REQUEST:
     ADR        13
     DBGINFO    getUpdate
     FCODE      4
     FRAME      �9

     LEN        1
     MODBUSID   57
     OPERATION  read
     READING    1W-val-1
     SENT       1568886615.98244
     TID        172
     TIMESTAMP  1568886600.05081
     TYPE       i
     VALUES     0
     DEVHASH:
   defptr:
     HKVEG1     57
   gotReadings:
     HK-ALL-ON  1
   lastRead:
     c0         1568884533.20044
     c16        1568883641.2242
     c17        1568884534.20831
     c18        1568886610.55423
     c19        1568884532.69871
     c2         1568886587.04819
     c3         1568886602.35437
     c4         1568886573.39565
     c5         1568885570.02873
     c6         1568886607.7564
     c7         1568885790.0502
     i0         1568884533.7045
     i13        1568886575.63942
Attributes:
   DbLogInclude 1W-val-.*
   dev-c-defPoll 1
   dev-i-defPoll 1
   dev-timing-sendDelay 0.5
   dev-timing-timeout 3
   event-on-change-reading .*
   obj-c0-map 0:off,1:on
   obj-c0-reading HK2
   obj-c0-set 1
   obj-c1-map 0:off,1:on
   obj-c1-reading HK3
   obj-c1-set 1
   obj-c16-reading 1WConvertT
   obj-c16-set 1
   obj-c17-reading 1WScanBus
   obj-c17-set 1
   obj-c18-reading HK-ALL-ON
   obj-c18-set 1
   obj-c19-reading HK-ALL-OFF
   obj-c19-set 1
   obj-c2-map 0:off,1:on
   obj-c2-reading HK4
   obj-c2-set 1
   obj-c3-map 0:off,1:on
   obj-c3-reading HK5
   obj-c3-set 1
   obj-c4-map 0:off,1:on
   obj-c4-reading HK6
   obj-c4-set 1
   obj-c5-map 0:off,1:on
   obj-c5-reading HK7
   obj-c5-set 1
   obj-c6-map 0:off,1:on
   obj-c6-reading HK8
   obj-c6-set 1
   obj-c7-map 0:off,1:on
   obj-c7-reading HK9
   obj-c7-set 1
   obj-c8-map 0:off,1:on
   obj-c8-reading HK1
   obj-c8-set 1
   obj-c9-map 0:off,1:on
   obj-i0-expr ($val >> 8 )
   obj-i0-reading 1Wcount
   obj-i13-expr ( $val / 2 )
   obj-i13-format %.1f
   obj-i13-poll 1
   obj-i13-reading 1W-val-1
   room       Modbus
   userattr   DbLogInclude dev-c-combine dev-c-defPoll dev-h-combine dev-i-defPoll disable enableControlSet event-on-change-reading obj-c0-map obj-c0-reading obj-c0-set obj-c1-map obj-c1-reading obj-c1-set obj-c16-reading obj-c16-set obj-c17-reading obj-c17-set obj-c18-reading obj-c18-set obj-c19-reading obj-c19-set obj-c2-map obj-c2-reading obj-c2-set obj-c3-map obj-c3-reading obj-c3-set obj-c4-map obj-c4-reading obj-c4-set obj-c5-map obj-c5-reading obj-c5-set obj-c6-map obj-c6-reading obj-c6-set obj-c7-map obj-c7-reading obj-c7-set obj-c8-map obj-c8-reading obj-c8-set obj-c9-map obj-h0-reading obj-h1-reading obj-i0-expr obj-i0-reading obj-i13-expr obj-i13-format obj-i13-poll obj-i13-reading openTimeout verbose
   verbose    3

Mach ich da was falsch oder ist das einfach ein Problem, das bisher nicht aufgetreten ist oder nicht behoben wurde? 


Dankbar für Tipps und Hinweise !

Gruß
Mike
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 September 2019, 14:42:54
Hallo Mike,

schick doch mal einen Auszug aus dem Log bei verbose 5 (sowohl für die physischen als auch für die logischen Devices),
dann finden wir das Problem sicher.

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 26 September 2019, 14:52:08
Hallo,

Nach einem Wasserschaden im Keller will ich vor dem Wiederverschliessen der Trocknungslöcher im Estrich einen Feuchtigkeits-Sensor einbringen. Ich hab mir beim Chinamann das hier bestellt: https://www.aliexpress.com/item/32828614172.html (https://www.aliexpress.com/item/32828614172.html) (wegen des für diesen Zweck gut geeigneten Sensors).

Das Gerät spricht auch Modbus. Mit einem Serial-to-USB Adapter direkt am fhem Server bekomme ich Temperatur und Feuchtigkeit auch via fhem im Testaufbau ausgelesen.
Ich will aber eigentlich via WLAN die Werte abfragen und dachte mir, ich verwende dazu einen günstigen Konverter (Elfin-EW11):

https://www.aliexpress.com/item/32918253841.html (https://www.aliexpress.com/item/32918253841.html)

Bei dem Preis lohnt sich ja kein Selbstbau ...

Wenn ich das ModbusAttr Device von serieller Kommunikation auf TCP umstelle bekomme ich zwar eine Verbindung, aber es kommen keine Daten zurück. Kennt jemand zufällig diesen Konverter oder gibt es günstige Alternativen ?

Grüße,

gadget.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 26 September 2019, 16:14:24
Wenn ich das ModbusAttr Device von serieller Kommunikation auf TCP umstelle bekomme ich zwar eine Verbindung, aber es kommen keine Daten zurück.

hast du bei der Definition  TCP oder RTU angegeben ?
Ich habe zwar diesen Adapter nicht, aber bei meinen ESPEasy Verbindungen musste ich RTU anstatt TCP als Parameter angeben
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 26 September 2019, 16:27:05
Hallo,

Ich hatte beides ohne Erfolg probiert. Ich werde mal einen Versuch mit einen Rasperry Zero W und ser2net starten.

Wie machst Du das mit ESPEasy ? Insbesondere was den elektrischen Part angeht ?

Grüße,

gadget
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 26 September 2019, 17:00:20
ich habe an meinen Solarcontroller RS485. Einfach einen TTL RS485 Adapter dazwischen, der mir auch das auf die 3,3V vom ESP bringt. Der hängt einfach an der seriellen vom ESP. Und unter Device einfach den Serial Server eingerichtet.
ESP und der Adapter sind aber teurer als deine Lösung.

Kannst du die Baudrate fix auf einen Wert einstellen ? Eventuell liegt da das Problem.


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: blueberry63 am 27 September 2019, 12:16:11
Hallo,

ich benutze das Modul erst seit kurzem (Danke an alle Entwickler) und mir ist aufgefallen, dass die Einstellung für "Intervall" nach einem Neustart von FHEM verloren gehen. Könnte man den Wert für "Intervall" nicht als Attribute setzen?

Gruß
Blueberry63
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 27 September 2019, 12:21:52
IMHO "works as designed" :)
dauerhaftes Intervall beim define angeben :
define <name> ModbusAttr <Id> <Interval>
set <name> überschreibt lediglich diese Vorgabe bis zum nächsten set bzw. Neustart l
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 28 September 2019, 11:11:34
Kannst du die Baudrate fix auf einen Wert einstellen ?

Ja, kann ich. Und wenn ich den Elfin EW11 passiv gleichzeitig mit dem UARTtoUSB Adapter am Bus betreibe, sehe ich im GUI auch ein- und ausgehende Pakete. Das Problem scheint eher auf der Netzwerkseite zu liegen.

Mein Test mit Pi Zero W und ser2net war erfolgreich, ich werde es wohl so umsetzen und den EW11 beiseite legen. Trotzdem schade, das Elfin Gerät wäre eine wirklich einfache, preisgünstige (<10 EUR) und kompakte Alternative gewesen.

Grüße, gadget

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 Oktober 2019, 11:50:50
Hallo Gadget,

ich denke wenn man noch ein bisschen mehr Aufwand ins Testen steckt, wird es mit dem EW11 doch noch klappen.

1) mit einem Oszi oder auch mit einem weiteren Raspberry mit Fhem und usb-to-RS485-Adapter im passiven Modus könntest Du prüfen, was bei einem Request über WLAN tatsächlich auf der RS485-Seite des EW11 rauskommt. Vielleicht stimmt ja dort die Modbus-ID einfach nicht.

2) mit verbose 5 könntest Du genauer sehen, was zwischen Fhem und dem EW11 per TCP gesprochen wird.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 03 Oktober 2019, 16:00:07
Hallo,

Ich bleibe jetzt erst mal bei der ser2net Lösung. Ich hätte auch noch einen Elfin EE11, den ich auf Verdacht in China mitbestellt hatte. Das ist die Variante RS485 zu Ethernet (LAN). Wenn sich jemand berufen fühlt und das technische KnowHow hat sich da tiefer reinzufrickeln stelle ich den gerne zur Verfügung.

Grüße, gadget
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 08 Oktober 2019, 07:17:13
Hallo Mike,

schick doch mal einen Auszug aus dem Log bei verbose 5 (sowohl für die physischen als auch für die logischen Devices),
dann finden wir das Problem sicher.

Gruss
    Stefan

Hallo Stefan,

war leider ein paar Tage nicht dran. Ich habe jetzt die Logs gemacht und angehängt als Datei.

Ich hoffe, du kannst daraus was erkennen :)

Danke und Grüße

Mike 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Oktober 2019, 23:33:17
Hallo Mike,

Leider fehlen einige Informationen im Log, primär auf der Seite des Relays.
Zum einen scheint das physische Modbus-Device MBGate nicht auf verbose 5 gestanden zu haben oder zumindest sehe ich nichts im Log und auf dieser Ebene findet das Relaying statt.

Zum anderen sehe ich auch die Kommunikation auf TCP-Ebene nicht im Log auf der Relay-Seite.

Kann es sein, dass Du verbose 5 erst gesetzt hast, als die TCP-Verbindung zwischen dem Slave und dem Relay schon geöffnet war? (Für die Verbindung wird intern ein neues Device erstellt, das dann von dem verbose-Attribut nichts mehr mitbekommt).

Du müsstest daher verbose 5 setzen, bevor die Verbindung geöffnet wird. Dann erbt das Verbindungs-Device die Attribute und dann sollte man im Log auch die Kommunikation innerhalb der TCP-Verbindung sehen.

Und dann ist es noch problematisch, dass das Relay selbst auch einen Update-Timer hat und gleichzeitig als eigenständiger Master Werte abfragt. Das war nicht so gedacht, könnte zwar klappen, macht aber die Fehlersuche schwieriger.
Eventuell kommen so aber die Requests durcheinander.
Daher würde ich vorschlagen, hier beim Define 0 als Intervall zu setzen. Eventuell löst das schon das Problem ...

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 09 Oktober 2019, 07:39:22
Hallo Stefan,

vielen Dank dass Du Dir die Mühe gemacht hast. In der Tat - ich hatte beim MBGate kein verbose und auch das Öffnen nach dem Setzen des Attributes hatte ich nicht gemacht. Ich mach das nochmal ..

Zuvor teste ich aber den Hinweis mit dem Master+Relay und deaktiviere das Master-Device auf dem Relay-Host.

Ich melde mich dann mit den Ergebnissen :)

Einen schönen Tag !

Mike
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 09 Oktober 2019, 22:04:09
Hallo und guten Abend,

ich habe jetzt die beiden neuen Logs.
Zuvor habe ich den HKVEG1 auf dem Relay entrümpelt. Der sieht jetzt ganz blank aus und dürfte sich mit dem Relay nicht mehr in die Quere kommen.

def:
defmod RelayHKVEG1 ModbusAttr 57 relay 192.168.3.15:1502 TCP to HKVEG1
attr RelayHKVEG1 room Modbus

list:
Internals:
   CHANGED   
   CONNECTS   9
   DEF        57 relay 192.168.3.15:1502 TCP to HKVEG1
   DeviceName 192.168.3.15:1502
   EXPECT     request
   FD         11
   FUUID      5c759876-f33f-53e7-e63d-dbf32ea83003afce
   IODev      RelayHKVEG1
   LASTCONN   RelayHKVEG1_192.168.3.10_40724
   MODBUSID   57
   MODE       relay
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       RelayHKVEG1
   NOTIFYDEV  global
   NR         133
   NTFY_ORDER 50-RelayHKVEG1
   PORT       1502
   PROTOCOL   TCP
   RELAY      HKVEG1
   RELID      7
   STATE      opened
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   CONNECTHASH:
     RelayHKVEG1_192.168.3.10_33524:
       BUF       
       EXPECT     idle
       IODev      RelayHKVEG1_192.168.3.10_33524
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_33524
       NR         160
       PEER       192.168.3.10
       PORT       33524
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      disconnected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHANGED:
         disconnected
       CHANGEDWITHSTATE:
       CHILDOF:
       FRAME:
       READ:
         BUFFER     
       READINGS:
         2019-10-08 06:30:29   state           disconnected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_33524
         lrecv      1570508928.66522
         lsend      1570508928.67016
       REQUEST:
         ADR        2
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        144
         TYPE       c
         DEVHASH:
     RelayHKVEG1_192.168.3.10_33872:
       BUF       
       EXPECT     request
       FD         27
       IODev      RelayHKVEG1_192.168.3.10_33872
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_33872
       NR         4277
       PEER       192.168.3.10
       PORT       33872
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READ:
         BUFFER     
       READINGS:
         2019-10-09 07:50:48   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_33872
         lrecv      1570600379.58042
         lsend      1570600379.56862
       REQUEST:
         ADR        4
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        178
         TYPE       c
         DEVHASH:
     RelayHKVEG1_192.168.3.10_33894:
       BUF       
       EXPECT     request
       FD         33
       IODev      RelayHKVEG1_192.168.3.10_33894
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_33894
       NR         4287
       PEER       192.168.3.10
       PORT       33894
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READ:
         BUFFER     
       READINGS:
         2019-10-09 07:52:42   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_33894
         lrecv      1570601024.47478
         lsend      1570601024.46291
       REQUEST:
         ADR        3
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        124
         TYPE       c
         DEVHASH:
     RelayHKVEG1_192.168.3.10_34014:
       BUF       
       EXPECT     request
       FD         17
       IODev      RelayHKVEG1_192.168.3.10_34014
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_34014
       NR         4331
       PEER       192.168.3.10
       PORT       34014
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READ:
         BUFFER     
       READINGS:
         2019-10-09 08:03:32   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_34014
         lrecv      1570646600.46573
         lsend      1570646600.45299
       REQUEST:
         ADR        13
         FCODE      4
         LEN        1
         MODBUSID   57
         PDU        

         TID        68
         TYPE       i
         DEVHASH:
     RelayHKVEG1_192.168.3.10_40612:
       BUF       
       EXPECT     request
       FD         34
       IODev      RelayHKVEG1_192.168.3.10_40612
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_40612
       NR         5537
       PEER       192.168.3.10
       PORT       40612
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       FRAME:
       READ:
         BUFFER     
       READINGS:
         2019-10-09 20:43:02   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_40612
         lrecv      1570647306.14011
         lsend      1570647306.14516
       REQUEST:
         ADR        7
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        102
         TYPE       c
         DEVHASH:
     RelayHKVEG1_192.168.3.10_40724:
       BUF       
       EXPECT     request
       FD         16
       IODev      RelayHKVEG1_192.168.3.10_40724
       MODBUSID   57
       MODE       relay
       NAME       RelayHKVEG1_192.168.3.10_40724
       NR         5587
       PEER       192.168.3.10
       PORT       40724
       PROTOCOL   TCP
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READ:
         BUFFER     
       READINGS:
         2019-10-09 20:55:06   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_40724
         lrecv      1570651032.73492
         lsend      1570651032.34768
       REQUEST:
         ADR        4
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        243
         TYPE       c
         DEVHASH:
     RelayHKVEG1_192.168.3.10_46176:
       BUF       
       EXPECT     request
       FD         18
       IODev      RelayHKVEG1_192.168.3.10_46176
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_46176
       NR         1835
       PEER       192.168.3.10
       PORT       46176
       RELAY      HKVEG1
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READINGS:
         2019-10-08 06:30:29   state           Connected
     RelayHKVEG1_192.168.3.10_46206:
       BUF       
       EXPECT     request
       FD         25
       IODev      RelayHKVEG1_192.168.3.10_46206
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_46206
       NR         1845
       PEER       192.168.3.10
       PORT       46206
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       FRAME:
       READ:
         BUFFER     
       READINGS:
         2019-10-08 06:32:07   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_46206
         lrecv      1570512955.83844
         lsend      1570512955.82821
       REQUEST:
         ADR        18
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        50
         TYPE       c
         DEVHASH:
     RelayHKVEG1_192.168.3.10_46910:
       BUF       
       EXPECT     request
       FD         29
       IODev      RelayHKVEG1_192.168.3.10_46910
       MODBUSID   57
       NAME       RelayHKVEG1_192.168.3.10_46910
       NR         1970
       PEER       192.168.3.10
       PORT       46910
       RELAY      HKVEG1
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READ:
         BUFFER     
       READINGS:
         2019-10-08 07:35:56   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_46910
         lrecv      1570600248.22052
         lsend      1570600248.223
       REQUEST:
         ADR        3
         ERRCODE    10
         FCODE      1
         LEN        1
         MODBUSID   57
         PDU        
         TID        192
         TYPE       c
         DEVHASH:
   READ:
     BUFFER     
   READINGS:
     2019-10-07 10:00:12   state           opened
   REMEMBER:
     lsend      1570651031.11842
   defptr:
     RelayHKVEG1 57
   gotReadings:
Attributes:
   room       Modbus

auffallend: 9 *neun* connections , obwohl ja nur eine besteht ..

MBGate, HKVEG1 und Relay HKVEG1 waren für das Log auf verbose 5 eingestellt.

Die Logs hab ich mal auf 10 Minuten gekürzt ab dem Zeitpunkt als sich der Client verbindet und auch noch gepackt, weil dennoch zu groß .

Ich bin gespannt, was Stefan in den Logs findet :) 

Grüße
Mike
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 Oktober 2019, 23:07:56
Hallo Mike,

Vielen Dank für die ausführlichen Logs.
Nur um zu verhindern, dass ich an den falschen Stellen suche:
Welches sind denn die unsinnigen Werte?

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 10 Oktober 2019, 07:45:52
Guten Morgen Stefan,

ich habe jetzt das Log durchsucht, um dir ein Beispiel für einen Fehler zu geben. Da ist keiner drin  :o

Da stellt sich die Frage WARUM?  - Das Log ist unter "Laborbedingungen" entstanden. Ich hatte alle anderen Relays disabled.

Vermutlich hat es also etwas mit der parallelen Nutzung mehrer Relays zu tun. Nachdem ich das für ZContr wieder aktiviert habe, sieht das Log am Client ( verbose 3, Filter .*Modbus.*  ) auszugsweise so aus:

2019-10-10 07:36:25 ModbusAttr ZContr 1W-DevCount: 15
2019.10.10 07:36:26 3 : HKVEG1: Timeout waiting for a modbus response request: id 57, fCode 1, tid 24, type c, adr 3, len 1 for device HKVEG1 reading HK5 (getUpdate), queued 13.82 secs ago, sent 3.00 secs ago, read buffer empty
2019.10.10 07:36:27 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 3, tid 149, type h, adr 41001, len 1 for device ZContr reading 1W-ROM-1 (getUpdate), queued 15.07 secs ago, sent 2.00 secs ago, read buffer empty
2019.10.10 07:36:31 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 4, tid 237, type i, adr 30001, len 1 for device ZContr reading 1W-VAL-1 (getUpdate), queued 9.41 secs ago, sent 2.00 secs ago, read buffer empty
2019-10-10 07:36:34 ModbusAttr ZContr LaufZeit: 65064
2019.10.10 07:36:36 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 1, tid 87, type c, adr 0008, len 1 for device ZContr reading ZTrigger (getUpdate), queued 14.09 secs ago, sent 2.00 secs ago, read buffer empty
2019-10-10 07:36:36 ModbusAttr HKVEG1 HK6: off
2019.10.10 07:36:41 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 4, tid 59, type i, adr 30001, len 1 for device ZContr reading 1W-VAL-1 (getUpdate), queued 8.79 secs ago, sent 2.00 secs ago, read buffer empty
2019.10.10 07:36:42 3 : HKVEG1: Timeout waiting for a modbus response request: id 57, fCode 1, tid 38, type c, adr 2, len 1 for device HKVEG1 reading HK4 (getUpdate), queued 19.73 secs ago, sent 3.00 secs ago, read buffer empty
2019.10.10 07:36:43 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 2, tid 62, type d, adr 0003, len 1 for device ZContr reading runF (getUpdate), queued 10.79 secs ago, sent 2.00 secs ago, read buffer empty
2019-10-10 07:36:43 ModbusAttr ZContr LaufZeit: 1
2019.10.10 07:36:46 3 : HKVEG1: Timeout waiting for a modbus response request: id 57, fCode 1, tid 7, type c, adr 4, len 1 for device HKVEG1 reading HK6 (getUpdate), queued 14.60 secs ago, sent 3.00 secs ago, read buffer empty
2019.10.10 07:36:47 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 3, tid 16, type h, adr 41001, len 1 for device ZContr reading 1W-ROM-1 (getUpdate), queued 15.60 secs ago, sent 2.00 secs ago, read buffer empty
2019.10.10 07:36:47 3 : ZContr: read got new data while idle, drop buffer 0010000000053804020066
2019.10.10 07:36:47 3 : HKVEG1: read got new data while idle, drop buffer 00190000000439010100
2019.10.10 07:36:47 3 : ZContr: read got new data while idle, drop buffer 00100000000438020101
2019-10-10 07:36:50 ModbusAttr ZContr SperrZeit: 10
2019.10.10 07:36:51 3 : HKVEG1: Timeout waiting for a modbus response request: id 57, fCode 1, tid 241, type c, adr 6, len 1 for device HKVEG1 reading HK8 (getUpdate), queued 19.24 secs ago, sent 3.00 secs ago, read buffer empty
2019.10.10 07:36:52 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 4, tid 132, type i, adr 30200, len 1 for device ZContr reading NTCVAL (getUpdate), queued 9.92 secs ago, sent 2.00 secs ago, read buffer empty
2019.10.10 07:36:54 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 3, tid 254, type h, adr 40001, len 1 for device ZContr reading LaufZeit (getUpdate), queued 12.15 secs ago, sent 2.00 secs ago, read buffer empty
2019-10-10 07:36:57 ModbusAttr HKVEG1 HK5 on
2019-10-10 07:36:57 ModbusAttr HKVEG1 HK6 on
2019-10-10 07:36:59 ModbusAttr HKVEG1 HK6: on
2019.10.10 07:37:01 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 4, tid 250, type i, adr 30001, len 1 for device ZContr reading 1W-VAL-1 (getUpdate), queued 9.25 secs ago, sent 2.00 secs ago, read buffer empty
2019.10.10 07:37:03 3 : ZContr: Timeout waiting for a modbus response request: id 56, fCode 1, tid 95, type c, adr 0008, len 1 for device ZContr reading ZTrigger (getUpdate), queued 11.53 secs ago, sent 2.00 secs ago, read buffer empty
2019-10-10 07:37:04 ModbusAttr Fronius1 F_Site_Total: 4
2019-10-10 07:37:04 ModbusAttr ZContr 1W-DevCount: 65064


Da sind zunächst wieder die Timeouts, dann die Meldungen wie "ZContr: read got new data while idle, drop buffer 0010000000053804020066"
und auch "unsinnige" Werte wie
2019-10-10 07:36:25 ModbusAttr ZContr 1W-DevCount: 15
.
.
2019-10-10 07:37:04 ModbusAttr ZContr 1W-DevCount: 65064

, was real nur ein Device ist .

Soll ich da jetzt nochmal unter diesen Bedingungen so ein umfangreicheres Log machen oder noch etwas anderes testen?

Gruß
Mike
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Oktober 2019, 17:51:01
Hallo Mike,

Wir kommen der Sache näher ;-)
Es ist vermutlich ein Problem, das nur bei mehreren Relays auftritt.
Um das besser nachvollziehen zu können, könntest Du mir noch genauer beschreiben, welche Geräte wie miteinander reden?
Sind das mehrere Geräte an einem gemeinsamen RS485-Bus, die von mehreren Relay-Definitionen in einem gemeinsamen Fhem per TCP an einen Client bereitgestellt werden?
Oder sind da mehr als 2 Fhem-Installationen beteiligt?

Gruß / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 10 Oktober 2019, 20:22:12
Hallo Stefan,

Zitat
Um das besser nachvollziehen zu können, könntest Du mir noch genauer beschreiben, welche Geräte wie miteinander reden?

Also ... es gibt EINEN RS485-Bus mit aktuell drei Modbus-Geräten: Heizkreisverteiler (HKVEG1) , Zirkulationskontrolle (ZContr) sowie den Solarwechselrichter (Fronius1) . Dieser Bus wird von einer FHEM-Instanz (FHEM1) über das Device MBGate abgefragt (und beschrieben). Auf einer zweiten FHEM-Instanz im Netz (FHEM2) werden aktuell der HKVEG1 und der Fronius1 ( und bisher auch das ZContr) verwendet. FHEM1 diente also bisher ausschließlich als Relay für diese drei Geräte.

Hier mal die Definitionen

MBGate:
define:
defmod MBGate Modbus /dev/ttyUSB0@19200
attr MBGate room Modbus
attr MBGate timeoutLogLevel 4

list::
Internals:
   DEF        /dev/ttyUSB0@19200
   DeviceName /dev/ttyUSB0@19200
   EXPECT     response
   FD         10
   FUUID      5c7596dd-f33f-53e7-2a57-81c950e0f8764b0b
   LASTOPEN   1570719741.89892
   MODE       master
   NAME       MBGate
   NR         131
   NTFY_ORDER 50-MBGate
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   nextQueueRun 1570730796.81963
   nextTimeout 1570730796.81415
   FRAME:
   QUEUE:
     HASH(0x8fd4a90)
     HASH(0xaa79138)
     HASH(0xaa64b88)
     HASH(0xaa6a0c0)
     HASH(0xaa676f0)
     HASH(0xa9d12c8)
     HASH(0xaa77780)
     HASH(0xaa68bd8)
     HASH(0xaa65f80)
     HASH(0xa9ca608)
     HASH(0xaa75ab8)
     HASH(0x8fb4118)
     HASH(0xaa64488)
     HASH(0xaa07f38)
     HASH(0xaa6ab68)
     HASH(0xa9cd058)
     HASH(0x8fb46d8)
     HASH(0x8e1ad10)
     HASH(0xa9d3d80)
     HASH(0xa9ccbe8)
     HASH(0xaa6c7c0)
     HASH(0xaa755b8)
     HASH(0xaa07358)
     HASH(0xaa78f98)
   READ:
     BUFFER     
   READINGS:
     2019-10-10 17:02:21   state           opened
   REMEMBER:
     lid        1
     lname      MBGate
     lrecv      1570730788.79952
     lsend      1570730794.81717
   REQUEST:
     ADR        502
     DBGINFO    getUpdate
     FCODE      3
     FRAME      ���
     LEN        4
     MODBUSID   1
     OPERATION  read
     READING    F_Site_Energy_Day
     SENT       1570730794.81415
     TIMESTAMP  1570730777.77799
     TYPE       h
     VALUES     0
     DEVHASH:
       CHANGED   
       DEF        1 10
       FUUID      5c759eec-f33f-53e7-810b-f27ff2e2548329a1
       INTERVAL   10
       IODev      MBGate
       MODBUSID   1
       MODE       master
       MODULEVERSION Modbus 4.1.5 - 17.9.2019
       NAME       Fronius1
       NOTIFYDEV  global
       NR         135
       NTFY_ORDER 50-Fronius1
       PROTOCOL   RTU
       STATE      opened
       TRIGGERTIME 1570730797.76961
       TRIGGERTIME_FMT 2019-10-10 20:06:37
       TYPE       ModbusAttr
       lastUpdate 1570730787.76961
       FRAME:
       READ:
       READINGS:
         2019-10-10 19:21:40   F_Active_State_Code 0
         2019-10-10 19:21:49   F_ModelType     0
         2019-10-10 19:21:40   F_Site_Energy_Day 12312
         2019-10-10 19:21:39   F_Site_Energy_Year 103
         2019-10-10 19:21:39   F_Site_Power    0
         2019-10-10 18:13:36   F_Site_Total    3378643255
         2019-10-10 18:15:14   state           opened
       REMEMBER:
         lrecv      1570728109.25355
         lsend      1570730794.81717
       gotReadings:
         F_ModelType 0
       lastRead:
         h213       1570722994.71628
         h214       1570728100.54474
         h216       1570728109.25644
         h499       1570723234.48913
         h500       1570728099.89025
         h501       1570723274.80587
         h502       1570728100.21757
         h505       1570723285.80048
         h506       1570728099.55056
         h509       1570723333.85567
         h510       1570724016.29744
   defptr:
     Fronius1   1
     HKVEG1     7
     ZContr     6
Attributes:
   room       Modbus
   timeoutLogLevel 4

HKVEG1 und das Relay
defmod HKVEG1 ModbusAttr 7 0
attr HKVEG1 room Modbus

Internals:
   CHANGED   
   DEF        7 0
   FUUID      5d9d77bd-f33f-53e7-8e15-3e37ba56d40b0bad
   IODev      MBGate
   MODBUSID   7
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       HKVEG1
   NOTIFYDEV  global
   NR         143
   NTFY_ORDER 50-HKVEG1
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   READINGS:
     2019-10-10 16:59:49   state           opened
   gotReadings:
Attributes:
   room       Modbus


defmod RelayHKVEG1 ModbusAttr 57 relay 192.168.3.15:1502 TCP to HKVEG1
attr RelayHKVEG1 room Modbus

Internals:
   CHANGED   
   CONNECTS   1
   DEF        57 relay 192.168.3.15:1502 TCP to HKVEG1
   DeviceName 192.168.3.15:1502
   EXPECT     request
   FD         11
   FUUID      5c759876-f33f-53e7-e63d-dbf32ea83003afce
   IODev      RelayHKVEG1
   LASTCONN   RelayHKVEG1_192.168.3.10_52534
   MODBUSID   57
   MODE       relay
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       RelayHKVEG1
   NOTIFYDEV  global
   NR         132
   NTFY_ORDER 50-RelayHKVEG1
   PORT       1502
   PROTOCOL   TCP
   RELAY      HKVEG1
   RELID      7
   STATE      opened
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   CONNECTHASH:
     RelayHKVEG1_192.168.3.10_52534:
       BUF       
       EXPECT     request
       FD         21
       IODev      RelayHKVEG1_192.168.3.10_52534
       MODBUSID   57
       MODE       relay
       NAME       RelayHKVEG1_192.168.3.10_52534
       NR         152
       PEER       192.168.3.10
       PORT       52534
       PROTOCOL   TCP
       RELAY      HKVEG1
       RELID      7
       SNAME      RelayHKVEG1
       SSL       
       STATE      Connected
       TCPChild   1
       TCPConn    1
       TEMPORARY  1
       TYPE       ModbusAttr
       CHILDOF:
       READ:
         BUFFER     
       READINGS:
         2019-10-10 17:00:23   state           Connected
       REMEMBER:
         lid        57
         lname      RelayHKVEG1_192.168.3.10_52534
         lrecv      1570731004.88455
         lsend      1570730998.72505
       REQUEST:
         ADR        4
         FCODE      5
         LEN        1
         MODBUSID   57
         PDU        
         TID        236
         TYPE       c
         VALUES     
         DEVHASH:
   READ:
     BUFFER     
   READINGS:
     2019-10-10 16:59:49   state           opened
   REMEMBER:
     lsend      1570730981.44594
   defptr:
     RelayHKVEG1 57
   gotReadings:
Attributes:
   room       Modbus


und der Fronius
defmod Fronius1 ModbusAttr 1 10
attr Fronius1 event-min-interval .*:300
attr Fronius1 event-on-change-reading .*
attr Fronius1 room Modbus
attr Fronius1 verbose 3

Internals:
   DEF        1 10
   FUUID      5d9f74d9-f33f-53e7-505f-bfb915bd8518f9d5
   INTERVAL   10
   IODev      MBGate
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       Fronius1
   NOTIFYDEV  global
   NR         859
   NTFY_ORDER 50-Fronius1
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1570731277.90637
   TRIGGERTIME_FMT 2019-10-10 20:14:37
   TYPE       ModbusAttr
   lastUpdate 1570731267.90637
   READINGS:
     2019-10-10 20:13:45   state           opened
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   room       Modbus
   verbose    3

defmod RelayFronius1 ModbusAttr 51 relay 192.168.3.15:1504 TCP to Fronius1
attr RelayFronius1 room Modbus

Internals:
   CONNECTS   2
   DEF        51 relay 192.168.3.15:1504 TCP to Fronius1
   DeviceName 192.168.3.15:1504
   EXPECT     request
   FD         15
   FUUID      5c759f0e-f33f-53e7-e08d-5681be80c05b6f39
   IODev      RelayFronius1
   LASTCONN   RelayFronius1_192.168.3.10_35926
   MODBUSID   51
   MODE       relay
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       RelayFronius1
   NOTIFYDEV  global
   NR         136
   NTFY_ORDER 50-RelayFronius1
   PORT       1504
   PROTOCOL   TCP
   RELAY      Fronius1
   STATE      opened
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   READ:
     BUFFER     
   READINGS:
     2019-10-10 20:14:58   state           opened
   REMEMBER:
     lsend      1570724010.64428
   defptr:
     RelayFronius1 51
   gotReadings:
Attributes:
   room       Modbus

Dazu die Devices auf dem FHEM2:

HKVEG1
Internals:
   CHANGED   
   DEF        57 10 192.168.3.15:1502 TCP
   DeviceName 192.168.3.15:1502
   EXPECT     response
   FD         31
   FUUID      5c5da6c9-f33f-53e7-4c38-f79a22e8f0185b2c
   INTERVAL   10
   IODev      HKVEG1
   LASTOPEN   1570719623.38817
   MODBUSID   57
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       HKVEG1
   NOTIFYDEV  global
   NR         35
   NTFY_ORDER 50-HKVEG1
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TRIGGERTIME 1570731469.70685
   TRIGGERTIME_FMT 2019-10-10 20:17:49
   TRIGGERTIME_SAVED
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1570731459.70685
   nextOpenDelay 60
   nextQueueRun 1570731464.75762
   nextTimeout 1570731466.75491
   FRAME:
   Helper:
     DBLOG:
       1W-val-1:
         logdb:
           TIME       1570728129.7915
           VALUE      33.5
   QUEUE:
     HASH(0x482cc50)
     HASH(0x483a5b8)
     HASH(0x48309c8)
     HASH(0x48203f0)
     HASH(0x48302d8)
     HASH(0x482ca28)
   READ:
     BUFFER     
   READINGS:
     2019-10-10 20:17:40   1W-val-1        33.5
     2019-10-10 20:17:37   1WConvertT      0
     2019-10-10 20:17:37   1WScanBus       0
     2019-10-10 20:17:36   1Wcount         1
     2019-10-10 20:17:35   HK-ALL-OFF      0
     2019-10-10 20:17:42   HK-ALL-ON       0
     2019-10-10 20:17:38   HK1             off
     2019-10-10 20:17:36   HK2             off
     2019-10-10 20:17:38   HK3             off
     2019-10-10 20:17:41   HK4             off
     2019-10-10 20:17:39   HK5             off
     2019-10-10 20:17:40   HK6             off
     2019-10-10 20:17:43   HK7             off
     2019-10-10 20:17:41   HK8             off
     2019-10-10 20:17:42   HK9             off
     2019-10-10 17:00:23   state           opened
   REMEMBER:
     lid        57
     lname      HKVEG1
     lrecv      1570731463.37003
     lsend      1570731463.75727
   REQUEST:
     ADR        19
     DBGINFO    getUpdate
     FCODE      1
     FRAME      �9
     LEN        1
     MODBUSID   57
     OPERATION  read
     READING    HK-ALL-OFF
     SENT       1570731463.75491
     TID        223
     TIMESTAMP  1570731459.72489
     TYPE       c
     VALUES     0
     DEVHASH:
   defptr:
     HKVEG1     57
   gotReadings:
     HK7        off
   lastRead:
     c0         1570731456.07442
     c1         1570731458.09085
     c16        1570731457.58744
     c17        1570731457.08421
     c18        1570731462.36141
     c19        1570731455.57076
     c2         1570731461.3516
     c3         1570731459.83872
     c4         1570731460.34442
     c5         1570731463.37142
     c6         1570731461.85765
     c7         1570731462.87062
     c8         1570731458.59398
     i0         1570731456.58094
     i13        1570731460.85252
Attributes:
   DbLogInclude 1W-val-.*
   dev-c-defPoll 1
   dev-i-defPoll 1
   dev-timing-sendDelay 0.5
   dev-timing-timeout 3
   event-on-change-reading .*
   obj-c0-map 0:off,1:on
   obj-c0-reading HK2
   obj-c0-set 1
   obj-c1-map 0:off,1:on
   obj-c1-reading HK3
   obj-c1-set 1
   obj-c16-reading 1WConvertT
   obj-c16-set 1
   obj-c17-reading 1WScanBus
   obj-c17-set 1
   obj-c18-reading HK-ALL-ON
   obj-c18-set 1
   obj-c19-reading HK-ALL-OFF
   obj-c19-set 1
   obj-c2-map 0:off,1:on
   obj-c2-reading HK4
   obj-c2-set 1
   obj-c3-map 0:off,1:on
   obj-c3-reading HK5
   obj-c3-set 1
   obj-c4-map 0:off,1:on
   obj-c4-reading HK6
   obj-c4-set 1
   obj-c5-map 0:off,1:on
   obj-c5-reading HK7
   obj-c5-set 1
   obj-c6-map 0:off,1:on
   obj-c6-reading HK8
   obj-c6-set 1
   obj-c7-map 0:off,1:on
   obj-c7-reading HK9
   obj-c7-set 1
   obj-c8-map 0:off,1:on
   obj-c8-reading HK1
   obj-c8-set 1
   obj-c9-map 0:off,1:on
   obj-i0-expr ($val >> 8 )
   obj-i0-reading 1Wcount
   obj-i13-expr ( $val / 2 )
   obj-i13-format %.1f
   obj-i13-poll 1
   obj-i13-reading 1W-val-1
   room       Modbus
   userattr   DbLogInclude dev-c-combine dev-c-defPoll dev-h-combine dev-i-defPoll disable enableControlSet event-on-change-reading obj-c0-map obj-c0-reading obj-c0-set obj-c1-map obj-c1-reading obj-c1-set obj-c16-reading obj-c16-set obj-c17-reading obj-c17-set obj-c18-reading obj-c18-set obj-c19-reading obj-c19-set obj-c2-map obj-c2-reading obj-c2-set obj-c3-map obj-c3-reading obj-c3-set obj-c4-map obj-c4-reading obj-c4-set obj-c5-map obj-c5-reading obj-c5-set obj-c6-map obj-c6-reading obj-c6-set obj-c7-map obj-c7-reading obj-c7-set obj-c8-map obj-c8-reading obj-c8-set obj-c9-map obj-h0-reading obj-h1-reading obj-i0-expr obj-i0-reading obj-i13-expr obj-i13-format obj-i13-poll obj-i13-reading openTimeout verbose
   verbose    3

und Fronius
Internals:
   DEF        51 10 192.168.3.15:1504 TCP
   DeviceName 192.168.3.15:1504
   EXPECT     idle
   FUUID      5c5da6c9-f33f-53e7-1a86-ef80cbf91187f7f3
   INTERVAL   10
   IODev      Fronius1
   LASTOPEN   1570731527.75132
   MODBUSID   51
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       Fronius1
   NEXT_OPEN  1570732119
   NOTIFYDEV  global
   NR         30
   NTFY_ORDER 50-Fronius1
   PARTIAL   
   PROTOCOL   TCP
   STATE      disconnected
   TCPConn    1
   TIMEOUTS   1
   TRIGGERTIME 1570731529.70599
   TRIGGERTIME_FMT 2019-10-10 20:18:49
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1570731519.70599
   nextOpenDelay 900
   FRAME:
     DATA       0
     FCODE      3
     MODBUSID   51
     PDULEXP    10
     TID        15
   Helper:
     DBLOG:
       F_Site_Energy_Day:
         logdb:
           TIME       1570723942.74183
           VALUE      12302
       F_Site_Energy_Year:
         logdb:
           TIME       1570723949.30168
           VALUE      20433240
       F_Site_Power:
         logdb:
           TIME       1570723872.55345
           VALUE      0
       F_Site_Total:
         logdb:
           TIME       1570724010.99301
           VALUE      12303
   QUEUE:
     HASH(0x483d1c8)
     HASH(0x4840e28)
     HASH(0x4823050)
     HASH(0x132c960)
     HASH(0x48378d8)
     HASH(0x4834098)
     HASH(0x482ca10)
     HASH(0x1508280)
     HASH(0x4834920)
     HASH(0x15380e0)
   READ:
     BUFFER     
   READINGS:
     2019-10-10 18:13:20   F_Active_State_Code 0
     2019-10-10 18:12:22   F_Site_Energy_Day 12302
     2019-10-10 18:12:29   F_Site_Energy_Year 20433240
     2019-10-10 18:13:15   F_Site_Power    0
     2019-10-10 18:13:30   F_Site_Total    12303
     2019-10-10 20:13:39   state           disconnected
   REMEMBER:
     lid        51
     lname      Fronius1
     lrecv      1570724016.97228
     lsend      1570724013.32811
   defptr:
     Fronius1   51
   gotReadings:
   lastRead:
     h213       1570724000.57744
     h499       1570723995.27645
     h501       1570723942.74024
     h505       1570723949.29998
     h509       1570724010.99143
Attributes:
   DbLogInclude F_Site_Energy_Day,F_Site_Energy_Year,F_Site_Power,F_Site_Total
   dev-h-defPoll 1
   disable    0
   enableControlSet 0
   event-min-interval .*:300
   event-on-change-reading .*
   nextOpenDelay 900
   obj-h213-reading F_Active_State_Code
   obj-h499-len 2
   obj-h499-reading F_Site_Power
   obj-h499-unpack L>
   obj-h501-len 4
   obj-h501-reading F_Site_Energy_Day
   obj-h501-unpack Q>
   obj-h505-len 4
   obj-h505-reading F_Site_Energy_Year
   obj-h505-unpack Q>
   obj-h509-len 4
   obj-h509-reading F_Site_Total
   obj-h509-unpack Q>
   room       SWR
   userattr   DbLogInclude dev-h-defPoll enableControlSet event-min-interval event-on-change-reading nextOpenDelay obj-h213-reading obj-h499-len obj-h499-reading obj-h499-revRegs obj-h499-unpack obj-h501-format obj-h501-len obj-h501-reading obj-h501-revRegs obj-h501-unpack obj-h505-len obj-h505-reading obj-h505-unpack obj-h509-len obj-h509-reading obj-h509-revRegs obj-h509-unpack obj-h510-unpack

Soviel zur Situation . Den ZContr hab ich jetzt ausgelassen.

PlanB wäre , nur den HKV via Relay auf FHEM2 zu behalten und die anderen beiden auf dem FHEM1 direkt zu konfigurieren. Das könnte _mein_ Problem dann wohl lösen, nicht aber den Grund beseitigen  ;) 

Gruß
Mike
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Oktober 2019, 21:35:24
Hallo Mike,

vielen Dank für die Details.
Ein Fehler, der ja nun schon klar ist, ist dass ein Relay zwischen TCP und RS485 auf seiner RS485-Seite ein Problem hat,
wenn gleichzeitig ein zweiter Update-Timer lokal auf der "Master"-Seite des Relays läuft.

Das Problem muss ich im Modul lösen bzw. verhindern, dass so ein zweiter Timer definiert wird.

Für HKVEG1 hast Du den Timer ja abgeschaltet, aber für Fronius1 steht er noch auf 10 Sekunden.
bevor wir nach weiteren Problemen suchen, würde ich Dich bitten, auch bei Fronius1 auf Fhem1 den lokalen Timer auf 0 zu setzen.

Wenn es danach immer noch Probleme gibt, dann bräuchte ich nochmal ein so ausführliches Log wie beim letzten Mal.
Damit sollte ich dann eventuelle weitere Probleme im Modul eingrenzen und beheben können.

Gruss / Thanx
    Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mike73 am 11 Oktober 2019, 07:49:45
Moin Stefan,

ich hab jetzt folgendes gemacht:
FHEM2: Fronius und ZContr deaktiviert , nur HKVEG1 läuft noch via Relay
FHEM1: Fronius komplett deaktiviert , HKVEG1 Master ohne eigenen Timer,
             ZContr von FHEM2 auf 1 umgezogen, der läuft jetzt nur hier lokal.

Jetzt scheint es auf den ersten Blick gut zu laufen. Letztlich brachte erst das Deaktivieren des zweiten Relays ( für den Fronius ) den gewünschten Effekt. Solange das Relay (mehr als eins) aktiv war, auch ohne eigenen Update-Timer des "Master"-Devices, lief es nicht sauber.

So kann ich es auch erstmal lassen. WFM ( works for me  ;) )   

viele Grüße und schönen Freitag !
Mike 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Oktober 2019, 16:08:26
Hallo Mike,

auch wenn das Setup mit mehreren Relays nicht alltäglich ist, würde ich das Problem doch gerne lösen bzw. die Bugs im Modul für so ein Setup beheben.
Ich versuche mal das ganze bei mir nachzubauen. Falls Du nochmal Zeit findest, Logs wie beschrieben zu erzeugen, wäre das natürlich eine große Hilfe :-)

Gruss / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: oniT am 11 Oktober 2019, 22:14:00
Hallo Stefan,

ich habe noch einen offenen Punkt aus dem alten Thread. Jetzt nach Jahren komme ich endlich dazu an dem Projekt weiter zu machen.

Ich habe das Problem, dass die Werte nicht geschrieben werden. Die PDF mit den Registern ist angehängt. Der Auszug aus der Config, für das Modbus-Modul und das Modbus-Attr Modul. Ausserdem der Auszug aus dem Logfile wo ich auf die Adresse h261 den Wert 100 geschrieben habe. Der Wert wird jedoch nicht gesetzt. Zumindest nicht hierüber. Über hterm funktioniert es.

Modbus-Attr:
defmod RTUWrite ModbusAttr 99 3600
attr RTUWrite userattr dev-h-combine dev-h-read dev-h-write dev-timing-timeout obj-h256-len obj-h256-reading obj-h256-set obj-h257-len obj-h257-reading obj-h257-set obj-h258-len obj-h258-reading obj-h258-set obj-h259-len obj-h259-reading obj-h259-set obj-h260-len obj-h260-reading obj-h260-set obj-h261-hint obj-h261-len obj-h261-max obj-h261-min obj-h261-reading obj-h261-set obj-h262-len obj-h262-max obj-h262-min obj-h262-reading obj-h262-set obj-h263-hint obj-h263-len obj-h263-max obj-h263-min obj-h263-reading obj-h263-set obj-h264-hint obj-h264-len obj-h264-max obj-h264-min obj-h264-reading obj-h264-set
attr RTUWrite dev-h-combine 9
attr RTUWrite dev-h-read 16
attr RTUWrite dev-h-write 16
attr RTUWrite dev-timing-timeout 4
attr RTUWrite obj-h256-reading 256
attr RTUWrite obj-h256-set 1
attr RTUWrite obj-h257-reading 257
attr RTUWrite obj-h257-set 1
attr RTUWrite obj-h258-reading 258
attr RTUWrite obj-h258-set 1
attr RTUWrite obj-h259-reading 259
attr RTUWrite obj-h259-set 1
attr RTUWrite obj-h260-reading 260
attr RTUWrite obj-h260-set 1
attr RTUWrite obj-h261-reading 261
attr RTUWrite obj-h261-set 1
attr RTUWrite obj-h262-reading 262
attr RTUWrite obj-h262-set 1
attr RTUWrite obj-h263-reading 263
attr RTUWrite obj-h263-set 1
attr RTUWrite obj-h264-reading 264
attr RTUWrite obj-h264-set 1
attr RTUWrite verbose 5

Modbus Modul:
defmod ModbusLine Modbus /dev/ttyUSB0@9600,8,E,1
attr ModbusLine verbose 5

Auszug aus Log nach dem Schreiben auf h261:
2019.10.11 22:05:54 5: RTUWrite: set called with 261 (h261) setVal = 100
2019.10.11 22:05:54 5: RTUWrite: GetSetChecks with force
2019.10.11 22:05:54 5: RTUWrite: GetSetChecks returns success
2019.10.11 22:05:54 5: RTUWrite: set packed hex 313030 with n to hex 0064
2019.10.11 22:05:54 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), read buffer empty
2019.10.11 22:05:54 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h261, qlen 0
2019.10.11 22:05:54 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 515.146 secs ago, last read 515.118 secs ago, last read on bus 500.813 secs ago from id 99 (Quantum)
2019.10.11 22:05:54 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 21:57:19.717) for RTUWrite, delay 515.019secs over
2019.10.11 22:05:54 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 21:57:19.689) for RTUWrite, delay 515.047secs over
2019.10.11 22:05:54 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 631001050001020064064c request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), queued 0.00 secs ago, read buffer empty
2019.10.11 22:05:54 5: SW: 631001050001020064064c
2019.10.11 22:05:54 5: ModbusLine: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer called from Set
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer called and remaining timeout is 3.99469089508057
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 63
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 6310
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 631000
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 63100000
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 6310000000
2019.10.11 22:05:54 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 00
2019.10.11 22:05:54 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.11 22:05:54 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 631000000000
2019.10.11 22:05:54 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 0000
2019.10.11 22:05:54 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.11 22:05:54 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.11 22:05:54 5: ModbusLine: HandleResponse did not get a valid frame yet, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 631000000000c8
2019.10.11 22:05:54 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 000000
2019.10.11 22:05:54 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.11 22:05:54 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.11 22:05:54 5: ModbusLine: HandleResponse did not get a valid frame yet, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 631000000000c84b
2019.10.11 22:05:54 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 00000000
2019.10.11 22:05:54 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.11 22:05:54 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.11 22:05:54 5: ModbusLine: CheckChecksum (called from HandleResponse): c84b is valid
2019.10.11 22:05:54 4: ModbusLine: ResponseDone request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), queued 0.04 secs ago, sent 0.04 secs ago, Current read buffer: 631000000000c84b, Id 99, fCode 16, response: id 99, fCode 16, type c, adr 261, len 1
2019.10.11 22:05:54 5: ModbusLine: DropFrame - drop 631000000000c84b
2019.10.11 22:05:54 5: RTUWrite: set is sending read after write
2019.10.11 22:05:54 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), read buffer empty
2019.10.11 22:05:54 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h261, qlen 0
2019.10.11 22:05:54 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 0.035 secs ago, last read 0.004 secs ago, last read on bus 0.005 secs ago from id 99 (RTUWrite)
2019.10.11 22:05:54 4: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 22:05:54.870) for RTUWrite, rest 0.095, sleep forced
2019.10.11 22:05:54 4: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 22:05:54.839) for RTUWrite, rest 0.064, sleep forced
2019.10.11 22:05:54 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 63100105000102308a92 request: id 99, fCode 16, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), queued 0.00 secs ago, read buffer empty
2019.10.11 22:05:54 5: SW: 63100105000102308a92
2019.10.11 22:05:54 5: ModbusLine: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer called from Set
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer called and remaining timeout is 3.99487614631653
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 63
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 6310
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 631000
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 63100000
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 6310000000
2019.10.11 22:05:54 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 00
2019.10.11 22:05:54 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.11 22:05:54 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 631000000000
2019.10.11 22:05:54 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 0000
2019.10.11 22:05:54 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.11 22:05:54 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.11 22:05:54 5: ModbusLine: HandleResponse did not get a valid frame yet, wait for more data
2019.10.11 22:05:54 5: ModbusLine: ReadAnswer got: 631000000000c84b
2019.10.11 22:05:54 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 00000000
2019.10.11 22:05:54 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.11 22:05:54 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.11 22:05:54 5: ModbusLine: CheckChecksum (called from HandleResponse): c84b is valid
2019.10.11 22:05:54 4: ModbusLine: ResponseDone request: id 99, fCode 16, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), queued 0.03 secs ago, sent 0.03 secs ago, Current read buffer: 631000000000c84b, Id 99, fCode 16, response: id 99, fCode 16, type c, adr 261, len 1
2019.10.11 22:05:54 5: ModbusLine: DropFrame - drop 631000000000c84b
2019.10.11 22:05:54 5: RTUWrite: StartQueueTimer called from Set removes internal timer because it is not needed now

Kannst Du hier irgendwas erkennen was da nicht passt?

Danke
Tino
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Oktober 2019, 22:38:41
Hallo Tino,

Du hast den Function-Code zum Schreiben und zum Lesen auf 16 gesetzt.
Damit überschreibst Du einen zuvor geschriebenen Wert beim vermeintlichen Lesen sofort wieder mit 0.
Siehe http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

Bitte Probier doch mal den Code fürs Lesen auf seiner Default-Einstellung 3 zu belassen.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Oktober 2019, 22:55:34
Ergänzung:

Die Antwort des Geräts auf den Schreib-Request sieht leider auch nicht gut aus.
Kannst Du denn mit anderen Tools das Register 261 per Code 16 einzeln beschreiben?

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: oniT am 12 Oktober 2019, 22:27:11
Hallo Stefan,

hier der Log beim Lesen mit den FC3:
Error code 02 / illegal data address (in read after write for FCode 16)

2019.10.12 20:41:43 5: RTUWrite: set called with 261 (h261) setVal = 100
2019.10.12 20:41:43 5: RTUWrite: GetSetChecks with force
2019.10.12 20:41:43 5: RTUWrite: GetSetChecks returns success
2019.10.12 20:41:43 5: RTUWrite: set packed hex 313030 with n to hex 0064
2019.10.12 20:41:43 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), read buffer empty
2019.10.12 20:41:43 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h261, qlen 0
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 81349.043 secs ago, last read 81349.014 secs ago, last read on bus 3339.454 secs ago from id 99 (Quantum)
2019.10.12 20:41:43 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 22:05:54.907) for RTUWrite, delay 81348.915secs over
2019.10.12 20:41:43 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 22:05:54.878) for RTUWrite, delay 81348.944secs over
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 631001050001020064064c request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), queued 0.00 secs ago, read buffer empty
2019.10.12 20:41:43 5: SW: 631001050001020064064c
2019.10.12 20:41:43 5: ModbusLine: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer called from Set
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer called and remaining timeout is 3.99478101730347
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 6310
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 631000
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 63100000
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 6310000000
2019.10.12 20:41:43 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 00
2019.10.12 20:41:43 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.12 20:41:43 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 631000000000
2019.10.12 20:41:43 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 0000
2019.10.12 20:41:43 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.12 20:41:43 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.12 20:41:43 5: ModbusLine: HandleResponse did not get a valid frame yet, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 631000000000c84b
2019.10.12 20:41:43 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 00000000
2019.10.12 20:41:43 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.12 20:41:43 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.12 20:41:43 5: ModbusLine: CheckChecksum (called from HandleResponse): c84b is valid
2019.10.12 20:41:43 4: ModbusLine: ResponseDone request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), queued 0.04 secs ago, sent 0.04 secs ago, Current read buffer: 631000000000c84b, Id 99, fCode 16, response: id 99, fCode 16, type c, adr 261, len 1
2019.10.12 20:41:43 5: ModbusLine: DropFrame - drop 631000000000c84b
2019.10.12 20:41:43 5: RTUWrite: set is sending read after write
2019.10.12 20:41:43 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 3, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), read buffer empty
2019.10.12 20:41:43 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h261, qlen 0
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 0.034 secs ago, last read 0.004 secs ago, last read on bus 0.005 secs ago from id 99 (RTUWrite)
2019.10.12 20:41:43 4: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 20:41:43.955) for RTUWrite, rest 0.095, sleep forced
2019.10.12 20:41:43 4: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 20:41:43.925) for RTUWrite, rest 0.065, sleep forced
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 6303010500019db5 request: id 99, fCode 3, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), queued 0.00 secs ago, read buffer empty
2019.10.12 20:41:43 5: SW: 6303010500019db5
2019.10.12 20:41:43 5: ModbusLine: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer called from Set
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer called and remaining timeout is 3.99506902694702
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 63
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 6383
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 638302
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 63830261
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 638302612f
2019.10.12 20:41:43 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 131 and data 02
2019.10.12 20:41:43 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.12 20:41:43 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.12 20:41:43 5: ModbusLine: CheckChecksum (called from HandleResponse): 612f is valid
2019.10.12 20:41:43 4: ModbusLine: HandleResponse got response with error code 83 / 02, illegal data address
2019.10.12 20:41:43 4: ModbusLine: ResponseDone request: id 99, fCode 3, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), queued 0.03 secs ago, sent 0.03 secs ago, Current read buffer: 638302612f, Id 99, fCode 131, response: id 99, fCode 131, adr 261, len 1
2019.10.12 20:41:43 5: ModbusLine: DropFrame - drop 638302612f
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got Error code 02 / illegal data address

Nachfolgend ein Auszug der Befehle für Register 261 Leistungsstufe mit hterm:
100%
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 64 00 64 00 01 00 00 54 5A

66%
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 42 00 64 00 01 00 00 13 98

33%
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 21 00 64 00 01 00 00 40 9E

0%
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 00 00 64 00 01 00 00 71 9C

Damit schalten die Leistungsstufen.

Im Anhang habe ich noch ein Dokument gefunden, da sind noch etwas mehr Informationen enthalten, gerade bzgl. Rückmeldung.

Zitat
Kannst Du denn mit anderen Tools das Register 261 per Code 16 einzeln beschreiben?
Bisher nur mit dem CAS Modbus Scanner. Allerdings ebenfalls ohne Erfolg. Hast Du einen Vorschlag mit was ich es noch Testen kann um weitere Informationen zu erhalten?

Danke
Tino
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Oktober 2019, 23:55:20
Hallo Tino,

Die Befehle, die Du mit hterm übertragen hast, schreiben immer 8 Register auf einmal, beginnend bei 0x100 also 256.
Offenbar reagiert das Gerät nur auf diese Anfangsadresse korrekt. Bei einem direkten Schreibzugriff auf 261 hat es keine Fehlermeldung zurückgeschickt, aber in der Antwort stand dass 0 Bytes geschrieben wurden.
Beim Versuch das Register 261 zu lesen kommt dann sogar die Fehlermeldung dass die Adresse illegal ist.
Das sieht für mich nach einer etwas "reduzierten" Modbus-Implementation aus.

Wenn Du nur die Leistungsstufen schalten möchtest, dann kannst Du das auch in so einem Fall von Fhem aus machen.
Du musst eben auch 8 Register bzw. 16 Bytes ab Register 256 gleichzeitig schreiben.
Dazu könntest Du ein Objekt als h256 mit Länge 8 definieren und einen Hex-String übergeben.
Unpack-Code dann so etwas wie H*

Im Log siehst Du ja was gesendet wird:
Zitat
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 631001050001020064064c request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), queued 0.00 secs ago, read buffer empty
2019.10.12 20:41:43 5: SW: 631001050001020064064c

Da müsste statt dessen der String stehen, den Du auch per hterm geschickt hast:
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 64 00 64 00 01 00 00 54 5A
Natürlich ohne die Spaces.

Das Bedeutet:
Adresse 0x63 bzw. 99
Fcode 0x10 (schreibe mehrere Holding-Register)
0100 ab Adresse 0x100 bzw. 256
0008 Länge 8 Register
10 als Bytes 16 Bytes
0000 0000 0000 0000 0000 das sind jeweils 0-Werte für die Register 256 bis 260
0064 das ist dann der Wert für Register 261
0001 Wert für Register 262
0000 Wert für Regsiter 263
545A das ist die Prüfsumme. Die erzeugt das Modul automatisch.

Damit Du beim set den Wert als 0-100 übergeben kannst, könntest Du eine setexpr verwenden, die aus dem Wert den passenden Hex-String erzeugt.

Ebenso musst Du vermutlich beim Lesen immer ab Register 256 lesen. Das macht die Sache recht unschön. Ich würde deshalb erstmal nur das mit dem Schreiben umsetzen. Wenn das soweit klappt, kann ich mit dem Lesen und zerlegen der einzelnen Werte helfen.

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: oniT am 13 Oktober 2019, 21:40:56
Hallo Stefan,

Zitat
Die Befehle, die Du mit hterm übertragen hast, schreiben immer 8 Register auf einmal, beginnend bei 0x100 also 256.
Offenbar reagiert das Gerät nur auf diese Anfangsadresse korrekt. Bei einem direkten Schreibzugriff auf 261 hat es keine Fehlermeldung zurückgeschickt, aber in der Antwort stand dass 0 Bytes geschrieben wurden. Beim Versuch das Register 261 zu lesen kommt dann sogar die Fehlermeldung dass die Adresse illegal ist.
Das sieht für mich nach einer etwas "reduzierten" Modbus-Implementation aus.
Ja das ist auch meine Vermutung.

Zitat
Wenn Du nur die Leistungsstufen schalten möchtest, dann kannst Du das auch in so einem Fall von Fhem aus machen.
Du musst eben auch 8 Register bzw. 16 Bytes ab Register 256 gleichzeitig schreiben.
Dazu könntest Du ein Objekt als h256 mit Länge 8 definieren
Ja verstanden. Ist soweit klar. Ich habe h256 mit der Länge 8 (obj-h256-len 8) angelegt.

Zitat
und einen Hex-String übergeben. Unpack-Code dann so etwas wie H*
Das ist mir beides nicht klar.

Zitat
Da müsste statt dessen der String stehen, den Du auch per hterm geschickt hast:
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 64 00 64 00 01 00 00 54 5A
Natürlich ohne die Spaces.

Das Bedeutet:
Adresse 0x63 bzw. 99
Fcode 0x10 (schreibe mehrere Holding-Register)
0100 ab Adresse 0x100 bzw. 256
0008 Länge 8 Register
10 als Bytes 16 Bytes
0000 0000 0000 0000 0000 das sind jeweils 0-Werte für die Register 256 bis 260
0064 das ist dann der Wert für Register 261
0001 Wert für Register 262
0000 Wert für Regsiter 263
545A das ist die Prüfsumme. Die erzeugt das Modul automatisch.
Ja das ist mir wieder klar.

Zitat
Damit Du beim set den Wert als 0-100 übergeben kannst, könntest Du eine setexpr verwenden, die aus dem Wert den passenden Hex-String erzeugt.
Ist mir nicht ganz klar. Wie mach ich das? Setzte ich auf das Register h256 den Wert 100, dann steht im Log auch 0064. Soweit richtig. Aber, trotz Länge 8 hätte ich jetzt den kompletten String 63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 64 00 00 00 00 00 00 erwartet. Kommt aber nicht. Der ist trotzdem noch immer kurz und es fehlen die 0000 für die Register 256 bis 260 bzw. 262 bis 263.

2019.10.13 21:36:03 5: RTUWrite: set called with 256 (h256) setVal = 100
2019.10.13 21:36:03 5: RTUWrite: GetSetChecks with force
2019.10.13 21:36:03 5: RTUWrite: GetSetChecks returns success
2019.10.13 21:36:03 5: RTUWrite: set packed hex 313030 with n to hex 0064
2019.10.13 21:36:03 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 256, len 8, value 0064 for device RTUWrite reading 256 (set 256), read buffer empty
2019.10.13 21:36:03 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h256, qlen 0
2019.10.13 21:36:03 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 17.548 secs ago, last read 17.525 secs ago, last read on bus 12.055 secs ago from id 99 (Quantum)
2019.10.13 21:36:03 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 21:35:46.051) for RTUWrite, delay 17.426secs over
2019.10.13 21:36:03 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 21:35:46.028) for RTUWrite, delay 17.449secs over
2019.10.13 21:36:03 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 631001000008100064a580 request: id 99, fCode 16, type h, adr 256, len 8, value 0064 for device RTUWrite reading 256 (set 256), queued 0.00 secs ago, read buffer empty
2019.10.13 21:36:03 5: SW: 631001000008100064a580

Irgendwie stehe ich da auf dem Schlauch. Ich benötige hier bitte noch weitere Unterstützung.

Danke
Gruß
Tino
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Oktober 2019, 22:12:05
Hallo Tino,

Das Modul kann nicht wissen, in welcher Form die Benutzereingabe kodiert werden soll. Manche Geräte speichern Zahlen als 16Bit signed integer, manche als 32Bit float etc.
Deshalb konfiguriert man einen unpack-Code, mit dem das Modul beim Lesen den Wert aus der Modbus-Response in ein Reading umwandelt und andersherum mit dem eine Benutzereingabe beim Set-Befehl in das Format für das Gerät umgewandelt wird. Der Default ist dabei ein n (unsigned short (16-bit) in "network" (big-endian) order).

In Deinem Fall muss aber aus dem Perl String/Wert 100 nicht einfach nur der Code 0064 in ein Register geschrieben werden, sondern Du musst noch viel mehr Bytes schreiben und 0064 kommt erst nach ein paar Nullen.

Jetzt könntest Du mit dem Unpack-Code H*, der bei einem Set-Befehl zum Packen verwendet wird, und einem Set-Befehl mit 000000000000000000000064 statt 100 den Hex-Strong an das Modul übergeben.
Das wäre aber nicht so elegant wie einfach nur set Device 100.

Deshalb gibt es auch noch eine setexpr. Da kann man per Attribut eine Perl-Expression festlegen, die den bei Set übergebenen Wert als $val weiterverarbeiten kann, z.B. Mit '00000000000000000000'.unpack('H4',pack('n',$val))
Ich kann das gerade nicht testen, aber so sollte aus einer eingegebenen 100 der String "000000000000000000000064" werden.

Dann kommt der per Attribut definierte Unpack-Code H* und macht daraus den Binärstring für den Schreib-Request.

Wenn ich in den nächsten Tagen mal dazu komme, kann ich die konkrete Konfiguration mal testen und posten..

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: oniT am 14 Oktober 2019, 22:25:42
Hallo Stefan,

ok, so ein wenig habe ich es verstanden. Ich habe dies mal so zusammengesetzt

0000000000000000000000'.unpack("H4", pack("n", $val)).'006400010000
oder auch mal so
000000000000000000'.unpack("H8", pack("N", $val)).'006400010000
Das Resultat ist gleich. Dabei ist im Log nun folgender Eintrag

2019.10.14 22:14:49 5: RTUWrite: set called with 256 (h256) setVal = 100
2019.10.14 22:14:49 5: RTUWrite: GetSetChecks with force
2019.10.14 22:14:49 5: RTUWrite: GetSetChecks returns success
2019.10.14 22:14:49 5: RTUWrite: CheckEval for Set evaluates setexpr for 256, val=100, expr='0000000000000000000000'.unpack("H4", pack("n", $val)).'006400010000'
2019.10.14 22:14:49 5: RTUWrite: CheckEval for Set result is 00000000000000000000000064006400010000
2019.10.14 22:14:49 5: RTUWrite: set packed hex 3030303030303030303030303030303030303030303030303634303036343030303130303030 with n to hex 6710
2019.10.14 22:14:49 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 256, len 8, value 6710 for device RTUWrite reading 256 (set 256), read buffer empty
2019.10.14 22:14:49 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h256, qlen 0
2019.10.14 22:14:49 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 271.094 secs ago, last read 271.072 secs ago, last read on bus 271.073 secs ago from id 99 (RTUWrite)
2019.10.14 22:14:49 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 22:10:17.999) for RTUWrite, delay 270.973secs over
2019.10.14 22:14:49 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 22:10:17.977) for RTUWrite, delay 270.995secs over
2019.10.14 22:14:49 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 6310010000081067108f97 request: id 99, fCode 16, type h, adr 256, len 8, value 6710 for device RTUWrite reading 256 (set 256), queued 0.00 secs ago, read buffer empty

Diese Zeile sieht dabei ja schon einmal vielversprechend aus
2019.10.14 22:14:49 5: RTUWrite: CheckEval for Set result is 00000000000000000000000064006400010000

Was bedeutet eigentlich dies hier
RTUWrite: set packed hex 3030303030303030303030303030303030303030303030303634303036343030303130303030 with n to hex 6710

Grundsätzlich komme ich vermutlich mit den unpack und pack nicht ganz klar.

Danke schon einmal für Deine Geduld.

Gruß
Tino
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 14 Oktober 2019, 22:52:06
Hallo Tino,

Du kommst der Sache schon näher :-)
Die setexpr hat noch den Fehler, dass nach dem umgewandelten Wert nochmal 0064 angehängt wird. Damit hast Du 0064 doppelt.
Das Hauptproblem ist aber, dass das Attribut für den unpack-Code noch fehlt. Daher wird per Default "n" genommen. Wenn das Modul nun den mühsam zusammengesetzten Hex-String mit "n" an die pack-Funktion übergibt, bleibt nur 6710 übrig. So macht das ja keine Sinn.
Wenn Du jetzt aber obj-h256-unpack H* angibst, sollte sich etwas ändern. Dann wird der Hex-String nicht als Integer sondern tatsächlich als Hex-String interpretiert.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: oniT am 15 Oktober 2019, 21:58:59
Hallo Stefan,

ja fein, das ist die Lösung. Ich hatte noch ein paar 00 zu viel, aber jetzt konnten die Werte 0, 33, 66 und 100% für die Leistungsstufe geschrieben werden. Hier wieder ein Auszug aus dem Log:

2019.10.15 20:28:47 5: RTUWrite: set called with 256 (h256) setVal = 100
2019.10.15 20:28:47 5: RTUWrite: GetSetChecks with force
2019.10.15 20:28:47 5: RTUWrite: GetSetChecks returns success
2019.10.15 20:28:47 5: RTUWrite: CheckEval for Set evaluates setexpr for 256, val=100, expr='00000000000000000000'.unpack("H4", pack("n", $val)).'006400010000'
2019.10.15 20:28:47 5: RTUWrite: CheckEval for Set result is 000000000000000000000064006400010000
2019.10.15 20:28:47 5: RTUWrite: set packed hex 303030303030303030303030303030303030303030303634303036343030303130303030 with H* to hex 000000000000000000000064006400010000
2019.10.15 20:28:47 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 256, len 8, value 000000000000000000000064006400010000 for device RTUWrite reading 256 (set 256), read buffer empty
2019.10.15 20:28:47 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h256, qlen 0
2019.10.15 20:28:47 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 51.455 secs ago, last read 51.432 secs ago, last read on bus 21.616 secs ago from id 99 (Quantum)
2019.10.15 20:28:47 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 20:27:56.018) for RTUWrite, delay 51.333secs over
2019.10.15 20:28:47 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 20:27:55.995) for RTUWrite, delay 51.356secs over
2019.10.15 20:28:47 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 63100100000810000000000000000000000064006400010000545a request: id 99, fCode 16, type h, adr 256, len 8, value 000000000000000000000064006400010000 for device RTUWrite reading 256 (set 256), queued 0.00 secs ago, read buffer empty
2019.10.15 20:28:47 5: SW: 63100100000810000000000000000000000064006400010000545a

Und hier die Definition, für alle die auch einmal solch eine Lösung benötigen.

defmod RTUWrite ModbusAttr 99 3600
attr RTUWrite userattr dev-h-write dev-timing-timeout obj-h256-len obj-h256-reading obj-h256-set obj-h256-setexpr obj-h256-unpack
attr RTUWrite dev-h-write 16
attr RTUWrite dev-timing-timeout 4
attr RTUWrite obj-h256-len 8
attr RTUWrite obj-h256-reading 256
attr RTUWrite obj-h256-set 1
attr RTUWrite obj-h256-setexpr '00000000000000000000'.unpack("H4", pack("n", $val)).'006400010000'
attr RTUWrite obj-h256-unpack H*

Ist noch nicht dringend, gibt es aber auch irgendwie die Möglichkeit diesen String mit den anderen Registern zusammenzusetzen? Bei dieser Lösung ist dieser ja bis auf h261 fest. Im setexpr wird ja der eingegebene Wert durch $val mit übergeben. Könnte man zum Beispiel in einem DOIF oder notify, ist ja egal, die Setexpr mit anderen Werten zum Beispiel aus einem Dummy zusammenbauen und dann in das "attr RTUWrite obj-h256-setexpr ' ....'" schreiben. Anschließend wird noch der Befehl ausgeführt, fertig. Das ist meiner Meinung nach doch möglich und sollte unktionieren. Ist vielleicht nicht die eleganteste Lösung, aber vermutlich die einfachste. Oder was meinst Du? Gibt es noch eine andere Lösung.

Danke für die Unterstützung, hat mich wieder ein Stück weitergebracht.

Gruß
Tino
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 15 Oktober 2019, 23:23:14
Hallo Tino,

Du kannst in der setexpr durchaus Werte von Readings oder Attributen verwenden.
Siehe https://wiki.fhem.de/wiki/DevelopmentModuleAPI#ReadingsVal
Oder https://wiki.fhem.de/wiki/DevelopmentModuleAPI#AttrVal
Die Variable $hash steht in der Expression ebenso wie $val zur Verfügung.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: oniT am 16 Oktober 2019, 20:50:14
Hallo Stefan,

alles klar. ReadingsVal steht im Attribut setexpr zur Verfügung. Ist ja noch besser.  :)

Hier mal das Beispiel, funktioniert und kann beliebig um die restlichen Register ja erweitert werden.
obj-h256-setexpr '00000000000000000000'.unpack("H4", pack("n", $val)).unpack("H4",pack("n",ReadingsVal("dummy_h262_quantum","state","0000"))).unpack("H4",pack("n",ReadingsVal("dummy_h263_quantum","state","0000"))).'0000'

Eine weitere Frage oder auch Anmerkung, wenn ich hieraus über saveAsModule dies als Modul speichere und später über Edit Files bearbeite, kommt dann beim Speichern eine Fehlermeldung bzgl. der Zeichensetzung. Ich wollte es nur erwähnen, ich weiß nicht ob es schon jemand aufgefallen ist. Eventuell kannst du dies ja sogar im ModbusAttr Modul mit beheben. Also falls das geht und die Zeichensetzung berücksichtigt werden kann.

syntax error at ./FHEM/98_ModbusRTUDimplexQuantum.pm line 44, near "''00000000000000000000"

Danke
Gruß
Tino
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Oktober 2019, 00:58:55
Hallo Tino,

Danke für den Hinweis.
Ist bisher nicht aufgefallen.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 27 Oktober 2019, 16:59:52
Hallo zusammen.

Ich denke ich bin hier richtig um einen Kostal plenticore Wechselrichter über modbus TCP auszulesen. Ich habe einfach mal folgendes in FHEM definiert:

Internals:
   CFGFN     
   DEF        5 60 192.168.178.18:1502 TCP
   DeviceName 192.168.178.18:1502
   EXPECT     idle
   FD         28
   FUUID      5db5b8b3-f33f-81e9-4e6c-e6ea81fa8ef6414b
   INTERVAL   30
   IODev      PV_Anlage_1
   LASTOPEN   1572190873.57548
   MODBUSID   5
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       PV_Anlage_1
   NOTIFYDEV  global
   NR         13633
   NTFY_ORDER 50-PV_Anlage_1
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TRIGGERTIME 1572191536.36499
   TRIGGERTIME_FMT 2019-10-27 16:52:16
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1572191476.36499
   nextOpenDelay 60
   READ:
     BUFFER     
   READINGS:
     2019-10-27 16:41:13   state           opened
   defptr:
     PV_Anlage_1 5
Attributes:
   verbose    5

Und bekomme schon dies im Log zu sehen
2019.10.27 16:39:06 3: PV_Anlage_1: defined with id 5, interval 30, protocol TCP, mode master, connection to 192.168.178.18:1502
2019.10.27 16:39:07 4: PV_Anlage_1: Notify / Init: opening connection
2019.10.27 16:39:07 5: PV_Anlage_1: open called from Notify
2019.10.27 16:39:07 4: PV_Anlage_1: open trying to open connection to 192.168.178.18:1502
2019.10.27 16:39:07 3: Opening PV_Anlage_1 device 192.168.178.18:1502
2019.10.27 16:39:07 5: HttpUtils url=http://192.168.178.18:1502/
2019.10.27 16:39:07 4: IP: 192.168.178.18 -> 192.168.178.18
2019.10.27 16:39:07 5: PV_Anlage_1: SetartUpdateTimer called from Notify kept existing timer, will call GetUpdate in 6.8 sec at 2019-10-27 16:39:13, interval 30
2019.10.27 16:39:07 5: PV_Anlage_1: UpdateSetList: setList=interval reread:noArg reconnect:noArg stop:noArg start:noArg close:noArg saveAsModule scanStop:noArg scanModbusObjects
2019.10.27 16:39:07 5: PV_Anlage_1: UpdateSetList: getList=
2019.10.27 16:39:07 3: PV_Anlage_1 device opened
2019.10.27 16:39:07 5: PV_Anlage_1: SetartUpdateTimer called from OpenCB kept existing timer, will call GetUpdate in 6.6 sec at 2019-10-27 16:39:13, interval 30

2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate called from HandleTimeout
2019.10.27 16:39:13 5: PV_Anlage_1: SetartUpdateTimer called from GetUpdate updated timer, will call GetUpdate in 30.0 sec at 2019-10-27 16:39:43, interval 30
2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate objects from attributes:
2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate full object list:
2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate tries to combine read commands
2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate doesn't sort objList before sending requests

Gibt es nun eine Möglichkeit eine Liste aller Datenfelder von dem Kostal Plenticor (Master) zu bekommen?


Mit dem Python Skript kostal_modbusquery_V003.py bekomme ich bereits diese Liste, jedoch wäre mir das Modbus Modul eleganter.

Desweiteren habe ich dann noch den EM410 und einen BYD Speicher. Der EM410 spricht ebenfalls modbus TCP, womit ich meine Hilfeersuchen direkt erweitern möchte.

Viele Grüße
     Christian

fhem@raspberrypi:~/python/kostal$ python kostal_modbusquery_V003.py
Starting QUERY ..........
Inverter article number b'10335959'
Software-Version IO-Controller (IOC) b'01.34\x00\x00\x00'
Total DC power 13.52
State of energy manager 0.0
Home own consumption from battery 0.0
Home own consumption from grid 0.0
Total home consumption Battery 0.0
Total home consumption Grid 0.0
Total home consumption PV 0.0
Home own consumption from PV 0.0
Total home consumption 0.0
Isolation resistance 65535000.0
Power limit from EVU 100.0
Total home consumption rate 0.0
Worktime 38235.0
Actual cos phi 1.0
Grid frequency 49.98
Current Phase 1 0.04
Active power Phase 1 -2.75
Voltage Phase 1 228.66
Current Phase 2 0.05
Active power Phase 2 -2.94
Voltage Phase 2 229.93
Current Phase 3 0.04
Active power Phase 3 -2.65
Voltage Phase 3 229.54
Total AC active power -8.35
Total AC reactive power 28.08
Total AC apparent power 29.29
Battery charge current 20.0
Number of battery cycles 0.0
Actual battery charge -minus or discharge -plus current 0.0
PSSB fuse state 0.0
Battery ready flag 1.0
Act. state of charge 17.0
Battery temperature 16.6
Battery voltage 14.31
Cos phi (powermeter) nan
Frequency (powermeter) nan
Current phase 1 (powermeter) nan
Active power phase 1 (powermeter) nan
Reactive power phase 1 (powermeter) nan
Apparent power phase 1 (powermeter) nan
Voltage phase 1 (powermeter) nan
Current phase 2 (powermeter) nan
Active power phase 2 (powermeter) nan
Reactive power phase 2 (powermeter) nan
Apparent power phase 2 (powermeter) nan
Voltage phase 2 (powermeter) nan
Current phase 3 (powermeter) nan
Active power phase 3 (powermeter) nan
Reactive power phase 3 (powermeter) nan
Apparent power phase 3 (powermeter) nan
Voltage phase 3 (powermeter) nan
Total active power (powermeter) nan
Total reactive power (powermeter) nan
Total apparent power (powermeter) nan
Current DC1 0.02
Power DC1 8.36
Voltage DC1 443.86
Current DC2 0.05
Power DC2 5.73
Voltage DC2 118.62
Current DC3 0.0
Power DC3 0.0
Voltage DC3 0.0
Total yield 10850.03
Daily yield 2690.12
Yearly yield 10850.03
Monthly yield 10850.03
Battery actual SOC 17
Battery Manufacturer b'        '
Battery Model ID 0
Battery Serial Number 0
Work Capacity 0
Inverter Max Power 10000
Inverter Generation Power (actual) 65528
Generation Energy 711065600
Actual battery charge-discharge power 0
Battery Firmware 0
Battery Type 4
Done...
[[6, 'Inverter article number', 'Strg8', b'10335959'],
 [46, 'Software-Version IO-Controller (IOC)', 'Strg8', b'01.34\x00\x00\x00'],
 [100, 'Total DC power', 'Float', 13.52],
 [104, 'State of energy manager', 'Float', 0.0],
 [106, 'Home own consumption from battery', 'Float', 0.0],
 [108, 'Home own consumption from grid', 'Float', 0.0],
 [110, 'Total home consumption Battery', 'Float', 0.0],
 [112, 'Total home consumption Grid', 'Float', 0.0],
 [114, 'Total home consumption PV', 'Float', 0.0],
 [116, 'Home own consumption from PV', 'Float', 0.0],
 [118, 'Total home consumption', 'Float', 0.0],
 [120, 'Isolation resistance', 'Float', 65535000.0],
 [122, 'Power limit from EVU', 'Float', 100.0],
 [124, 'Total home consumption rate', 'Float', 0.0],
 [144, 'Worktime', 'Float', 38235.0],
 [150, 'Actual cos phi', 'Float', 1.0],
 [152, 'Grid frequency', 'Float', 49.98],
 [154, 'Current Phase 1', 'Float', 0.04],
 [156, 'Active power Phase 1', 'Float', -2.75],
 [158, 'Voltage Phase 1', 'Float', 228.66],
 [160, 'Current Phase 2', 'Float', 0.05],
 [162, 'Active power Phase 2', 'Float', -2.94],
 [164, 'Voltage Phase 2', 'Float', 229.93],
 [166, 'Current Phase 3', 'Float', 0.04],
 [168, 'Active power Phase 3', 'Float', -2.65],
 [170, 'Voltage Phase 3', 'Float', 229.54],
 [172, 'Total AC active power', 'Float', -8.35],
 [174, 'Total AC reactive power', 'Float', 28.08],
 [178, 'Total AC apparent power', 'Float', 29.29],
 [190, 'Battery charge current', 'Float', 20.0],
 [194, 'Number of battery cycles', 'Float', 0.0],
 [200, 'Actual battery charge -minus or discharge -plus current', 'Float', 0.0],
 [202, 'PSSB fuse state', 'Float', 0.0],
 [208, 'Battery ready flag', 'Float', 1.0],
 [210, 'Act. state of charge', 'Float', 17.0],
 [214, 'Battery temperature', 'Float', 16.6],
 [216, 'Battery voltage', 'Float', 14.31],
 [218, 'Cos phi (powermeter)', 'Float', nan],
 [220, 'Frequency (powermeter)', 'Float', nan],
 [222, 'Current phase 1 (powermeter)', 'Float', nan],
 [224, 'Active power phase 1 (powermeter)', 'Float', nan],
 [226, 'Reactive power phase 1 (powermeter)', 'Float', nan],
 [228, 'Apparent power phase 1 (powermeter)', 'Float', nan],
 [230, 'Voltage phase 1 (powermeter)', 'Float', nan],
 [232, 'Current phase 2 (powermeter)', 'Float', nan],
 [234, 'Active power phase 2 (powermeter)', 'Float', nan],
 [236, 'Reactive power phase 2 (powermeter)', 'Float', nan],
 [238, 'Apparent power phase 2 (powermeter)', 'Float', nan],
 [240, 'Voltage phase 2 (powermeter)', 'Float', nan],
 [242, 'Current phase 3 (powermeter)', 'Float', nan],
 [244, 'Active power phase 3 (powermeter)', 'Float', nan],
 [246, 'Reactive power phase 3 (powermeter)', 'Float', nan],
 [248, 'Apparent power phase 3 (powermeter)', 'Float', nan],
 [250, 'Voltage phase 3 (powermeter)', 'Float', nan],
 [252, 'Total active power (powermeter)', 'Float', nan],
 [254, 'Total reactive power (powermeter)', 'Float', nan],
 [256, 'Total apparent power (powermeter)', 'Float', nan],
 [258, 'Current DC1', 'Float', 0.02],
 [260, 'Power DC1', 'Float', 8.36],
 [266, 'Voltage DC1', 'Float', 443.86],
 [268, 'Current DC2', 'Float', 0.05],
 [270, 'Power DC2', 'Float', 5.73],
 [276, 'Voltage DC2', 'Float', 118.62],
 [278, 'Current DC3', 'Float', 0.0],
 [280, 'Power DC3', 'Float', 0.0],
 [286, 'Voltage DC3', 'Float', 0.0],
 [320, 'Total yield', 'Float', 10850.03],
 [322, 'Daily yield', 'Float', 2690.12],
 [324, 'Yearly yield', 'Float', 10850.03],
 [326, 'Monthly yield', 'Float', 10850.03],
 [514, 'Battery actual SOC', 'U16', 17],
 [517, 'Battery Manufacturer', 'Strg8', b'        '],
 [525, 'Battery Model ID', 'U32', 0],
 [527, 'Battery Serial Number', 'U32', 0],
 [529, 'Work Capacity', 'U32', 0],
 [531, 'Inverter Max Power', 'Float', 10000],
 [575, 'Inverter Generation Power (actual)', 'S16', 65528],
 [577, 'Generation Energy', 'U32', 711065600],
 [582, 'Actual battery charge-discharge power', 'S16', 0],
 [586, 'Battery Firmware', 'U32', 0],
 [588, 'Battery Type', 'U16', 4]]
----------------------------------
Doing some Calculations of the received information:
Left Side Raw Power Generation of Panles : 14.1
BatteryCharge (-) / Discharge(+) is      : 0.0
Powerfromgrid (-) /To Grid (+) is        : 65528.0
Total current Home consumption is        : 0.0
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 Oktober 2019, 22:36:36
Hallo Christian,

Eine Liste der definierten Datenpunkte und vor allem der zugehörigen Datentypen kann man leider nicht von einem Modbus-Gerät abfragen. Aber in dem von Dir erwähnten Skript wird das wohl alles drinstehen.
Schau das doch mal genauer an.
Alternativ sollte der Hersteller solche Infos bereitstellen.
Eventuell hat das aber auch schon jemand mit Fhem gemacht und kann Dir die fertige Konfiguration zur Verfügung stellen.
Hast Du schon mal im Forum gesucht?

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 29 Oktober 2019, 12:31:24
Hallo Stefan,

danke für Deine unermüdlichen Hilfen.

Ja, gesucht habe ich bereits, denn so bin ich hier gelandet ;-) Eine Dokumentation zum Modbus TCP habe ich auch bereits und halt das Python Skript.
Mir fehlt momentan das Verständnis, wie ich das bereits definierte Modbus Device in FHEM so modifizieren kann, dass es die readings vom Modbus ausliest.

An diese Stelle natürlich auch noch mal Dank an den Pythen Skript Ersteller.

Hier einige Ausschnitte, um einen Einstieg für die Definitionen in FHEM zu haben

Das habe ich ja bereits bei der definition des FHEM devices eingetragen
        #Change the IP address and port to suite your environment:
        self.inverter_ip="192.168.178.18"
        self.inverter_port="1502"
        #No more changes required beyond this point

.....
Und so sind in Python die Kostal Register definiert

        self.KostalRegister = []
        self.Adr6=[]
        self.Adr6=[6]
        self.Adr6.append("Inverter article number")
        self.Adr6.append("Strg8")
        self.Adr6.append(0)
       
        self.Adr46=[]
        self.Adr46 =[46]
        self.Adr46.append("Software-Version IO-Controller (IOC)")
        self.Adr46.append("Strg8")
        self.Adr46.append(0)
       
        self.Adr100=[]
        self.Adr100 =[100]
        self.Adr100.append("Total DC power")
        self.Adr100.append("Float")
        self.Adr100.append(0)
               
        self.Adr104=[]
        self.Adr104 =[104]
        self.Adr104.append("State of energy manager")
        self.Adr104.append("Float")
        self.Adr104.append(0)

Ich könnte jetzt natürlich das Python Skript aufrufen und aus Python die readings mit set sezten, jedoch fände ich scharmanter, wenn ich es direkt in FHEM durchführen würde.

Für ein Muster der änderungen wäre ich schon dankbar und würde dann die Fleißarbeit übernehmen.

Viele Grüße
    Christian

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 29 Oktober 2019, 12:43:44
fang mal ganz klein an :
attr PV_Anlage_1 dev-h-defLen 2
attr PV_Anlage_1 dev-h-defPoll 1
attr PV_Anlage_1 dev-h-defUnpack N
(das erspart dir später eventuell Tipparbeit )
und dann holst du deinen ersten Wert , laut deinem Listing liegt in Register 100 der Wert "Total DC power"
also noch :
attr PV_Anlage_1 obj-h1000-reading Total_DC_Powerdanach sollte dein erstes Reading da sein, wenn der Wert unsinnig ist mit Unpack spielen und/oder ggf die Länge von 2 auf 1 ändern.
Steht aber alles in der Kostal Modubus pdf Doku, d.h. Register Nr. , Name, Länge & Typ


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 29 Oktober 2019, 13:12:30
Okay, einfach ist immer gut...


Wäre der MODE master in der fhem definition denn richtig? Der Kostal Plenticore ist auch als Master definiert.
Internals:
   CFGFN     
   DEF        5 60 192.168.178.18:1502 TCP
   DeviceName 192.168.178.18:1502
   EXPECT     idle
   FD         23
   FUUID      5db5b8b3-f33f-81e9-4e6c-e6ea81fa8ef6414b
   INTERVAL   60
   IODev      PV_Anlage_1
   LASTOPEN   1572284858.33409
   MODBUSID   5
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       PV_Anlage_1
   NOTIFYDEV  global
   NR         13633
   NTFY_ORDER 50-PV_Anlage_1
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TIMEOUTS   5
   TRIGGERTIME 1572350716.61945
   TRIGGERTIME_FMT 2019-10-29 13:05:16
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1572350656.61945
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2019-10-28 18:47:38   state           opened
   REMEMBER:
     lid        5
     lname      PV_Anlage_1
     lsend      1572350658.68951
   defptr:
     PV_Anlage_1 5
   lastRead:
Attributes:
   dev-h-defLen 2
   dev-h-defPoll 1
   dev-h-defUnpack N
   obj-h100-reading Total_DC_Power
   room       Strom->Photovoltaik
   userattr   dev-h-defLen dev-h-defPoll dev-h-defUnpack obj-h100-reading
   verbose    5

2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate called from HandleTimeout
2019.10.29 13:09:17 5: PV_Anlage_1: SetartUpdateTimer called from GetUpdate updated timer, will call GetUpdate in 60.0 sec at 2019-10-29 13:10:17, interval 60
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate objects from attributes: h100
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate full object list: h100
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate check h100 => Total_DC_Power, poll = 1, last = 0
2019.10.29 13:09:17 4: PV_Anlage_1: GetUpdate will request Total_DC_Power
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate tries to combine read commands
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate doesn't sort objList before sending requests
2019.10.29 13:09:17 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 5, fCode 3, tid 77, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), read buffer empty
2019.10.29 13:09:17 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h100, qlen 0
2019.10.29 13:09:17 4: PV_Anlage_1: ProcessRequestQueue called from QueueRequest, qlen 1, next entry to id 5 (PV_Anlage_1), last send to this device was 60.015 secs ago, last read never, last read on bus never from id 5 (PV_Anlage_1)
2019.10.29 13:09:17 5: PV_Anlage_1: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 13:08:17.028) for PV_Anlage_1, delay 59.919secs over
2019.10.29 13:09:17 4: PV_Anlage_1: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 004d00000006050300640002 request: id 5, fCode 3, tid 77, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), queued 0.01 secs ago, read buffer empty
2019.10.29 13:09:17 5: SW: 004d00000006050300640002
2019.10.29 13:09:17 5: PV_Anlage_1: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.29 13:09:19 3: PV_Anlage_1: Timeout waiting for a modbus response request: id 5, fCode 3, tid 77, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), queued 2.00 secs ago, sent 2.00 secs ago, read buffer empty
2019.10.29 13:09:19 5: PV_Anlage_1: DropFrame - drop
2019.10.29 13:09:19 5: PV_Anlage_1: StartQueueTimer called from ResponseTimeout removes internal timer because it is not needed now
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 29 Oktober 2019, 13:52:43
Ein erster Erfolg ist da.

Internals:
   CFGFN     
   DEF        71 60 192.168.178.18:1502 TCP
   DeviceName 192.168.178.18:1502
   EXPECT     idle
   FD         29
   FUUID      5db5b8b3-f33f-81e9-4e6c-e6ea81fa8ef6414b
   INTERVAL   60
   IODev      PV_Anlage_1
   LASTOPEN   1572353223.64744
   MODBUSID   71
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       PV_Anlage_1
   NOTIFYDEV  global
   NR         13633
   NTFY_ORDER 50-PV_Anlage_1
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TRIGGERTIME 1572353463.06452
   TRIGGERTIME_FMT 2019-10-29 13:51:03
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1572353403.06452
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2019-10-29 13:50:03   Total_DC_Power  89015481
     2019-10-29 13:47:03   state           opened
   REMEMBER:
     lid        71
     lname      PV_Anlage_1
     lrecv      1572353403.13239
     lsend      1572353403.11398
   defptr:
     PV_Anlage_1 71
   gotReadings:
     Total_DC_Power 89015481
   lastRead:
     h100       1572353403.15377
Attributes:
   dev-h-defLen 2
   dev-h-defPoll 1
   dev-h-defUnpack N
   obj-h100-reading Total_DC_Power
   room       Strom->Photovoltaik
   userattr   dev-h-defLen dev-h-defPoll dev-h-defUnpack obj-h100-reading
   verbose    5

2019.10.29 13:52:03 5: PV_Anlage_1: GetUpdate called from HandleTimeout
2019.10.29 13:52:03 5: PV_Anlage_1: SetartUpdateTimer called from GetUpdate updated timer, will call GetUpdate in 60.0 sec at 2019-10-29 13:53:03, interval 60
2019.10.29 13:52:03 5: PV_Anlage_1: GetUpdate objects from attributes: h100
2019.10.29 13:52:03 5: PV_Anlage_1: GetUpdate full object list: h100
2019.10.29 13:52:03 5: PV_Anlage_1: GetUpdate check h100 => Total_DC_Power, poll = 1, last = 1572353463.15642
2019.10.29 13:52:03 4: PV_Anlage_1: GetUpdate will request Total_DC_Power
2019.10.29 13:52:03 5: PV_Anlage_1: GetUpdate tries to combine read commands
2019.10.29 13:52:03 5: PV_Anlage_1: GetUpdate doesn't sort objList before sending requests
2019.10.29 13:52:03 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 68, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), read buffer empty
2019.10.29 13:52:03 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h100, qlen 0
2019.10.29 13:52:03 4: PV_Anlage_1: ProcessRequestQueue called from QueueRequest, qlen 1, next entry to id 71 (PV_Anlage_1), last send to this device was 60.485 secs ago, last read 60.468 secs ago, last read on bus 60.468 secs ago from id 71 (PV_Anlage_1)
2019.10.29 13:52:03 5: PV_Anlage_1: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 13:51:03.135) for PV_Anlage_1, delay 60.372secs over
2019.10.29 13:52:03 5: PV_Anlage_1: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 13:51:03.118) for PV_Anlage_1, delay 60.392secs over
2019.10.29 13:52:03 4: PV_Anlage_1: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 004400000006470300640002 request: id 71, fCode 3, tid 68, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), queued 0.02 secs ago, read buffer empty
2019.10.29 13:52:03 5: SW: 004400000006470300640002
2019.10.29 13:52:03 5: PV_Anlage_1: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.29 13:52:03 5: PV_Anlage_1: read buffer: 0044000000074703046ffd44b8
2019.10.29 13:52:03 4: PV_Anlage_1: ParseFrameStart (TCP) extracted id 71, fCode 3, tid 68, dlen 7 and data 046ffd44b8
2019.10.29 13:52:03 5: PV_Anlage_1: HandleResponse called from Read
2019.10.29 13:52:03 5: PV_Anlage_1: ParseResponse called from HandleResponse
2019.10.29 13:52:03 5: PV_Anlage_1: HandleResponse now passing to logical device PV_Anlage_1 for parsing data
2019.10.29 13:52:03 5: PV_Anlage_1: ParseObj called with data 6ffd44b8, type h, adr 100, valuesLen 2, op read
2019.10.29 13:52:03 5: PV_Anlage_1: ParseObj ObjInfo for h100: reading=Total_DC_Power, unpack=N, expr=, format=, map=
2019.10.29 13:52:03 5: PV_Anlage_1: ParseObj unpacked 6ffd44b8 with N to 1878869176 hex 31383738383639313736
2019.10.29 13:52:03 4: PV_Anlage_1: ParseObj assigns value 1878869176 to Total_DC_Power
2019.10.29 13:52:03 5: PV_Anlage_1: HandleResponse got 1 readings from ParseObj for PV_Anlage_1
2019.10.29 13:52:03 4: PV_Anlage_1: ResponseDone request: id 71, fCode 3, tid 68, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), queued 0.24 secs ago, sent 0.24 secs ago, Current read buffer: 0044000000074703046ffd44b8, Id 71, fCode 3, tid 68, response: id 71, fCode 3, type h, adr 100, len 2, value 6ffd44b8
2019.10.29 13:52:03 5: PV_Anlage_1: DropFrame - drop 0044000000074703046ffd44b8
2019.10.29 13:52:03 5: PV_Anlage_1: StartQueueTimer called from Read removes internal timer because it is not needed now
Jetzt kann ich mit der Fleißarbeit beginnen.

Vielen dank erst ein mal.
Gruß
     Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 29 Oktober 2019, 14:58:41
Zitat
2019-10-29 13:50:03   Total_DC_Power  89015481
ok ein Wert gelesen , aber das Format stimmt bestimmt noch nicht. Was sagt denn die Doku wie lang das Register 100 ist 1,2 oder 4 Byte ?
Dementsprechend die Länge für dieses Register anpassen und dann das Thema High/Low Byte ( Litte & Big Endian ) , zu guter letzt halt noch wie muss Unpack gesetzt sein. Ist aber alles in der command.ref ausführlich dokumentiert und wenn man die Doku des Herstellers hat auch schnell erledigt.

Nach dem Schema holst du dir alle Register bzw. deren Werte von in FHEM haben willst.
Zugegeben etwas Arbeit gerade zum Beginn, aber wenn man das Schema mal begriffen hat geht es flott bzw. man macht es i.d.R. eh nur einmal 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 29 Oktober 2019, 15:05:41
Okay,

ich habe jetzt bereits tausende :-) readings eingetragen und bin beim Datenformat angelangt.

Die default Länge 2 passt bei den meisten Objekten, für die anderen trage ich dann mal die richtige Länge ein.

In der Hersteller Doku finde ich folgende Formate:

Bool
U16 länge 1
U32 länge 2
String länge 8 und 32

Das meiste ist:
Float länge 2

Gruß
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 29 Oktober 2019, 15:44:29
Hallo nochmal.

Mit den Floatingpoint Formaten bin ich total raus. Das ist über 30 Jahre her bei mir :-)

Im Python Skript habe ich dann noch folgendes gefunden. Eventuell kann mir damit ja jemand sagen, was ich für unpack und eventuell Format verwenden muss.

    #-----------------------------------------
    # Routine to read a string from one address with 8 registers
    def ReadStr8(self,myadr_dec):   
        r1=self.client.read_holding_registers(myadr_dec,8,unit=71)
        STRG8Register = BinaryPayloadDecoder.fromRegisters(r1.registers, byteorder=Endian.Big)
        result_STRG8Register =STRG8Register.decode_string(8)     
        return(result_STRG8Register)
    #-----------------------------------------
    # Routine to read a Float from one address with 2 registers     
    def ReadFloat(self,myadr_dec):
        r1=self.client.read_holding_registers(myadr_dec,2,unit=71)
        FloatRegister = BinaryPayloadDecoder.fromRegisters(r1.registers, byteorder=Endian.Big, wordorder=Endian.Little)
        result_FloatRegister =round(FloatRegister.decode_32bit_float(),2)
        return(result_FloatRegister)   
    #-----------------------------------------
    # Routine to read a U16 from one address with 1 register
    def ReadU16_1(self,myadr_dec):
        r1=self.client.read_holding_registers(myadr_dec,1,unit=71)
        U16register = BinaryPayloadDecoder.fromRegisters(r1.registers, byteorder=Endian.Big, wordorder=Endian.Little)
        result_U16register = U16register.decode_16bit_uint()
        return(result_U16register)
    #-----------------------------------------
    # Routine to read a U16 from one address with 2 registers
    def ReadU16_2(self,myadr_dec):
        r1=self.client.read_holding_registers(myadr_dec,2,unit=71)
        U16register = BinaryPayloadDecoder.fromRegisters(r1.registers, byteorder=Endian.Big, wordorder=Endian.Little)
        result_U16register = U16register.decode_16bit_uint()
        return(result_U16register)
    #-----------------------------------------
    # Routine to read a U32 from one address with 2 registers
    def ReadU32(self,myadr_dec):
        r1=self.client.read_holding_registers(myadr_dec,2,unit=71)
        #print ("r1 ", rl.registers)
        U32register = BinaryPayloadDecoder.fromRegisters(r1.registers, byteorder=Endian.Big, wordorder=Endian.Little)
        #print ("U32register is", U32register)
        #result_U32register = U32register.decode_32bit_float()
        result_U32register = U32register.decode_32bit_uint()
        return(result_U32register)
    #-----------------------------------------
    def ReadU32new(self,myadr_dec):
        print ("I am in ReadU32new with", myadr_dec)
        r1=self.client.read_holding_registers(myadr_dec,2,unit=71)
        U32register = BinaryPayloadDecoder.fromRegisters(r1.registers, byteorder=Endian.Big, wordorder=Endian.Little)
        result_U32register = U32register.decode_32bit_uint()
        return(result_U32register)
    #-----------------------------------------   
    # Routine to read a U32 from one address with 2 registers
    def ReadS16(self,myadr_dec):
        r1=self.client.read_holding_registers(myadr_dec,1,unit=71)
        S16register = BinaryPayloadDecoder.fromRegisters(r1.registers, byteorder=Endian.Big, wordorder=Endian.Little)
        result_S16register = S16register.decode_16bit_uint()
        return(result_S16register)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 29 Oktober 2019, 16:03:59
passt den das Beispiel aus der command.ref nicht  ? :
attr PWP obj-h338-reading Pressure
attr PWP obj-h338-len 2
attr PWP obj-h338-unpack f>
attr PWP obj-h338-revRegs 1
attr PWP obj-h338-format %.2f

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 29 Oktober 2019, 18:14:29
Hallo mal wieder.

Bei dem Wert, den ich zuerst getestet habe hatte es nicht gepasst, oder ich habe etwas falsch gemacht.
Nun noch mal mit Konzentration und einem anderen Wert und schon geht es:-)

Voltage_Phase_1  232.19
Voltage_Phase_2  232.01
Voltage_Phase_3  233.03

Ich schau dann morgen nach den anderen Werten
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 01 November 2019, 13:37:44
Hallo mal wieder

Ich habe jetzt die meisten Werte entschlüsselt, jedoch sind noch viele die ich nicht formatiert bekomme.

Dies passt für die Floatingpoint und ist als default gesetzt, weil es die größte Anzahl ist.
attr PV_Anlage_1 dev-h-defFormat %.2f
attr PV_Anlage_1 dev-h-defLen 2
attr PV_Anlage_1 dev-h-defPoll 1
attr PV_Anlage_1 dev-h-defRevRegs 1
attr PV_Anlage_1 dev-h-defUnpack f>

Das ist aus der modbus definition vom Hersteller
0x213 531 Inverter Max Power W U16 1 RO 0x03
0x214 532 Inverter Peak Generation Power Scale Factor4 - - 1 RO 0x03
0x217 535 Inverter Manufacturer - String 16 RO 0x03
0x227 551 Inverter Model ID - String 8 RO 0x03
0x22F 559 Inverter Serial Number - String 16 RO 0x03
0x23F 575 Inverter Generation Power (actual) W S16 1 RO 0x03
0x240 576 Power Scale Factor4 - - 1 RO 0x03
0x241 577 Generation Energy Wh U32 2 RO 0x03
0x243 579 Energy Scale Factor - - 1 RO 0x03
0x246 582 Actual battery charge/discharge power W S16 1 RO 0x03
0x24A 586 Battery Firmware - U32 1 RO 0x03
0x24C 588 Battery Type6 - U16 1 RO 0x03
0x300 768 Productname (e.g. PLENTICORE plus) - String 32 RO 0x03
0x320 800 Power class (e.g. 10) - String 32 RO 0x03


U16 soll unsigned 16 Bit sein

das habe ich im Netz gefunden zum Thema unpack https://apidock.com/ruby/String/unpack (https://apidock.com/ruby/String/unpack)
n             | Integer | 16-bit unsigned, network (big-endian) byte order
N             | Integer | 32-bit unsigned, network (big-endian) byte order
v             | Integer | 16-bit unsigned, VAX (little-endian) byte order
V             | Integer | 32-bit unsigned, VAX (little-endian) byte order

Ich bin verwirrt und für Hilfe offen

Gruß
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 01 November 2019, 14:15:22
attr PV_Anlage_1 dev-h-defPoll 2
Zitat
obj-[cdih][1-9][0-9]*-poll
If the Fhem Modbus device is in master mode, Fhem automatically creates read requests to the external modbus slave. If this attribute is set to 1 for an object then this obeject is included in the cyclic update request as specified in the define command for a Modbus master. If not set, then the object can manually be requested with a get command, but it is not automatically updated each interval. Note that this setting can also be specified as default for all objects with the dev- atributes described later.
This attribute is ignored in slave mode.
also warum 2 ?

Ich bin verwirrt
und warum ? Was du zum unpack gefunden hast deckt sich doch 1:1 mit der commandref
Wo ist jetzt das Problem ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 01 November 2019, 15:23:39
Hallo

Die erste Verwirrung war, das ich das Attribut als Pollingzeit angesehen hatte. Sorry, beim Lesen war es schon spät :-)
Jetzt habe ich es wieder auf "dev-h-defPoll 1" gesetzt.

Hersteller Doku
586 Battery Firmware - U32 1

Fhem
obj-h586-format %c
obj-h586-len 1
obj-h586-reading Battery_Firmware
obj-h586-unpack <<<<<<<<<< hier habe ich N und V ausbrobiert

jedoch wird immer 0.00 angezeigt

EDIT:

Ich habe noch mal verbose 5 gesetzt, da stimmt wohl noch mehr nicht...
2019.11.01 15:24:26 3: PV_Anlage_1 device opened
2019.11.01 15:24:26 5: PV_Anlage_1: SetartUpdateTimer called from OpenCB updated timer, will call GetUpdate in 0.0 sec at 2019-11-01 15:24:26, interval 60
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate called from HandleTimeout
2019.11.01 15:24:26 5: PV_Anlage_1: SetartUpdateTimer called from GetUpdate updated timer, will call GetUpdate in 60.0 sec at 2019-11-01 15:25:26, interval 60
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate objects from attributes: h164 h324 h586 h108 h202 h525 h575 h154 h268 h258 h216 h276 h240 h112 h242 h248 h144 h232 h6 h100 h210 h326 h228 h160 h194
 h200 h212 h162 h252 h172 h278 h517 h254 h114 h577 h578 h214 h118 h582 h260 h234 h322 h150 h246 h156 h152 h110 h208 h250 h190 h588 h46 h104 h320 h514 h220 h527 h116 h106 h120 h280 h230 h266 h27
0 h256 h529 h244 h531 h286 h166 h170 h224 h226 h158 h222 h122 h168 h174 h124 h178 h238 h218 h236
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate full object list: h100 h104 h106 h108 h110 h112 h114 h116 h118 h120 h122 h124 h144 h150 h152 h154 h156 h158 h160 h162 h164 h166 h168 h170 h172 h174
 h178 h190 h194 h200 h202 h208 h210 h212 h214 h216 h218 h220 h222 h224 h226 h228 h230 h232 h234 h236 h238 h240 h242 h244 h246 h248 h250 h252 h254 h256 h258 h260 h266 h268 h270 h276 h278 h280 h2
86 h320 h322 h324 h326 h46 h514 h517 h525 h527 h529 h531 h575 h577 h578 h582 h586 h588 h6
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h100 => Total_DC_Power, poll = 1, last = 1572618098.84707
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_DC_Power
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h104 => State_of_energy_manager, poll = 1, last = 1572618100.17873
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request State_of_energy_manager
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h106 => Home_own_consumption_from_battery, poll = 1, last = 1572618102.38253
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Home_own_consumption_from_battery
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h108 => Home_own_consumption_from_grid, poll = 1, last = 1572618097.07366
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Home_own_consumption_from_grid
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h110 => Total_home_consumption_Battery, poll = 1, last = 1572618103.78203
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_home_consumption_Battery
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h112 => Total_home_consumption_Grid, poll = 1, last = 1572618098.44053
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_home_consumption_Grid
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h114 => Total_home_consumption_PV, poll = 1, last = 1572618103.52435
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_home_consumption_PV
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h116 => Home_own_consumption_from_PV, poll = 1, last = 1572618102.50387
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Home_own_consumption_from_PV
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h118 => Total_home_consumption, poll = 1, last = 1572618098.7267
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_home_consumption
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h120 => Isolation_resistance, poll = 1, last = 1572618098.19903
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Isolation_resistance
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h122 => Power_limit_from_EVU, poll = 1, last = 1572618110.95207
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Power_limit_from_EVU
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h124 => Total_home_consumption_rate, poll = 1, last = 1572618112.7723
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_home_consumption_rate
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h144 => Worktime, poll = 1, last = 1572618111.92906
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Worktime
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h150 => Actual_cos_phi, poll = 1, last = 1572618097.71498
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Actual_cos_phi
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h152 => Grid_frequency, poll = 1, last = 1572618099.37964
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Grid_frequency
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h154 => Current_Phase_1, poll = 1, last = 1572618110.63971
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_Phase_1
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h156 => Active_power_Phase_1, poll = 1, last = 1572618103.15936
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Active_power_Phase_1
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h158 => Voltage_Phase_1, poll = 1, last = 1572618111.68731
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_Phase_1
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h160 => Current_Phase_2, poll = 1, last = 1572618100.29932
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_Phase_2
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h162 => Active_power_Phase_2, poll = 1, last = 1572618103.90261
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Active_power_Phase_2
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h164 => Voltage_Phase_2, poll = 1, last = 1572618097.23844
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_Phase_2
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h166 => Current_Phase_3, poll = 1, last = 1572618096.71237
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_Phase_3
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h168 => Active_power_Phase_3, poll = 1, last = 1572618112.16956
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Active_power_Phase_3
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h170 => Voltage_Phase_3, poll = 1, last = 1572618110.51547
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_Phase_3
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h172 => Total_AC_active_power, poll = 1, last = 1572618101.11557
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_AC_active_power
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h174 => Total_AC_reactive_power, poll = 1, last = 1572618102.63189
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_AC_reactive_power
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h178 => Total_AC_apparent_power, poll = 1, last = 1572618112.89206
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_AC_apparent_power
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h190 => Battery_charge_current, poll = 1, last = 1572618102.01406
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_charge_current
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h194 => Number_of_battery_cycles, poll = 1, last = 1572618104.14386
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Number_of_battery_cycles
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h200 => Actual_battery_charge_-minus_or_discharge_-plus_current, poll = 1, last = 1572618014.06195
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Actual_battery_charge_-minus_or_discharge_-plus_current
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h202 => PSSB_fuse_state, poll = 1, last = 1572618102.87378
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request PSSB_fuse_state
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h208 => Battery_ready_flag, poll = 1, last = 1572618097.83624
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_ready_flag
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h210 => Act_state_of_charge, poll = 1, last = 1572618112.04855
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Act_state_of_charge
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h212 => Battery_state, poll = 1, last = 1572618099.62045
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_state
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h214 => Battery_temperature, poll = 1, last = 1572618104.43073
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_temperature
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h216 => Battery_voltage, poll = 1, last = 1572618097.59299
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_voltage
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h218 => Cos_phi_(powermeter), poll = 1, last = 1572618103.6446
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Cos_phi_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h220 => Frequency_(powermeter), poll = 1, last = 1572618098.31932
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Frequency_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h222 => Current_phase_1_(powermeter), poll = 1, last = 1572618101.36779
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_phase_1_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h224 => Active_power_phase_1_(powermeter), poll = 1, last = 1572618100.87428
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Active_power_phase_1_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h226 => Reactive_power_phase_1_(powermeter), poll = 1, last = 1572618013.9409
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Reactive_power_phase_1_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h228 => Apparent_power_phase_1_(powermeter), poll = 1, last = 1572618096.95141
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Apparent_power_phase_1_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h230 => Voltage_phase_1_(powermeter), poll = 1, last = 1572618101.48841
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_phase_1_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h232 => Current_phase_2_(powermeter), poll = 1, last = 1572618103.28358
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_phase_2_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h234 => Active_power_phase_2_(powermeter), poll = 1, last = 1572618100.42088
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Active_power_phase_2_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h236 => Reactive_power_phase_2_(powermeter), poll = 1, last = 1572618104.0227
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Reactive_power_phase_2_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h238 => Apparent_power_phase_2_(powermeter), poll = 1, last = 1572618100.54188
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Apparent_power_phase_2_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h240 => Voltage_phase_2_(powermeter), poll = 1, last = 1572618111.07297
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_phase_2_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h242 => Current_phase_3_(powermeter), poll = 1, last = 1572618101.85096
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_phase_3_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h244 => Active_power_phase_3_(powermeter), poll = 1, last = 1572618102.99387
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Active_power_phase_3_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h246 => Reactive_power_phase_3_(powermeter), poll = 1, last = 1572618110.83245
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Reactive_power_phase_3_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h248 => Apparent_power_phase_3_(powermeter), poll = 1, last = 1572618111.32462
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Apparent_power_phase_3_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h250 => Voltage_phase_3_(powermeter), poll = 1, last = 1572618102.26189
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_phase_3_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h252 => Total_active_power_(powermeter), poll = 1, last = 1572618103.40326
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_active_power_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h254 => Total_reactive_power_(powermeter), poll = 1, last = 1572618099.50082
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_reactive_power_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h256 => Total_apparent_power_(powermeter), poll = 1, last = 1572618104.30935
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_apparent_power_(powermeter)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h258 => Current_DC1, poll = 1, last = 1572618101.72938
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_DC1
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h260 => Power_DC1, poll = 1, last = 1572618112.41241
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Power_DC1
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h266 => Voltage_DC1, poll = 1, last = 1572618098.96813
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_DC1
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h268 => Current_DC2, poll = 1, last = 1572618097.95749
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_DC2
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h270 => Power_DC2, poll = 1, last = 1572618112.65247
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Power_DC2
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h276 => Voltage_DC2, poll = 1, last = 1572618098.56072
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_DC2
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h278 => Current_DC3, poll = 1, last = 1572618111.44513
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Current_DC3
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h280 => Power_DC3, poll = 1, last = 1572618112.29015
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Power_DC3
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h286 => Voltage_DC3, poll = 1, last = 1572618100.99434
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Voltage_DC3
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h320 => Total_yield, poll = 1, last = 1572618102.75366
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_yield
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h322 => Daily_yield, poll = 1, last = 1572618096.83154
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Daily_yield
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h324 => Yearly_yield, poll = 1, last = 1572618099.25997
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Yearly_yield
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h326 => Monthly_yield, poll = 1, last = 1572618100.05879
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Monthly_yield
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h46 => Software-Version_IO-Controller_(IOC), poll = 1, last = 1572618111.19881
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Software-Version_IO-Controller_(IOC)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h514 => Battery_actual_SOC, poll = 1, last = 1572358634.24748
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_actual_SOC
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h517 => Battery_Manufacturer, poll = 1, last = 1572618101.24702
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_Manufacturer
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h525 => Battery_Model_ID, poll = 1, last = 1572618099.93713
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_Model_ID
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h527 => Battery_Serial_Number, poll = 1, last = 1572618101.60939
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_Serial_Number
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h529 => Work_Capacity, poll = 1, last = 1572618099.81512
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Work_Capacity
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h531 => Inverter_Max_Power, poll = 1, last = 1572358640.36286
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Inverter_Max_Power
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h575 => Inverter_Generation_Power_(actual), poll = 1, last = 1572358636.87452
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Inverter_Generation_Power_(actual)
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h577 => Generation_Energy, poll = 1, last = 1572618112.53159
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Generation_Energy
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h578 => Total_energy, poll = 1, last = 0
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Total_energy
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h582 => Actual_battery_charge-discharge_power, poll = 1, last = 0
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Actual_battery_charge-discharge_power
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h586 => Battery_Firmware, poll = 1, last = 1572611302.3511
2019.11.01 15:24:26 4: PV_Anlage_1: GetUpdate will request Battery_Firmware
2019.11.01 15:24:26 5: PV_Anlage_1: GetUpdate check h588 => Battery_Type, poll = 1, last = 0
2019.11.01 15:24:27 4: PV_Anlage_1: GetUpdate will request Battery_Type
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate check h6 => Inverter_article_number, poll = 1, last = 1572618099.1381
2019.11.01 15:24:27 4: PV_Anlage_1: GetUpdate will request Inverter_article_number
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate tries to combine read commands
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Inverter_article_number / h6 with Software-Version_IO-Controller_(IOC) / h46, span 48 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Software-Version_IO-Controller_(IOC) / h46 with Total_DC_Power / h100, span 56 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_DC_Power / h100 with State_of_energy_manager / h104, span 6 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for State_of_energy_manager / h104 with Home_own_consumption_from_battery / h106, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Home_own_consumption_from_battery / h106 with Home_own_consumption_from_grid / h108, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Home_own_consumption_from_grid / h108 with Total_home_consumption_Battery / h110, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_home_consumption_Battery / h110 with Total_home_consumption_Grid / h112, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_home_consumption_Grid / h112 with Total_home_consumption_PV / h114, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_home_consumption_PV / h114 with Home_own_consumption_from_PV / h116, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Home_own_consumption_from_PV / h116 with Total_home_consumption / h118, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_home_consumption / h118 with Isolation_resistance / h120, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Isolation_resistance / h120 with Power_limit_from_EVU / h122, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Power_limit_from_EVU / h122 with Total_home_consumption_rate / h124, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_home_consumption_rate / h124 with Worktime / h144, span 22 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Worktime / h144 with Actual_cos_phi / h150, span 8 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Actual_cos_phi / h150 with Grid_frequency / h152, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Grid_frequency / h152 with Current_Phase_1 / h154, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_Phase_1 / h154 with Active_power_Phase_1 / h156, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Active_power_Phase_1 / h156 with Voltage_Phase_1 / h158, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_Phase_1 / h158 with Current_Phase_2 / h160, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_Phase_2 / h160 with Active_power_Phase_2 / h162, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Active_power_Phase_2 / h162 with Voltage_Phase_2 / h164, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_Phase_2 / h164 with Current_Phase_3 / h166, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_Phase_3 / h166 with Active_power_Phase_3 / h168, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Active_power_Phase_3 / h168 with Voltage_Phase_3 / h170, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_Phase_3 / h170 with Total_AC_active_power / h172, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_AC_active_power / h172 with Total_AC_reactive_power / h174, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_AC_reactive_power / h174 with Total_AC_apparent_power / h178, span 6 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_AC_apparent_power / h178 with Battery_charge_current / h190, span 14 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_charge_current / h190 with Number_of_battery_cycles / h194, span 6 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Number_of_battery_cycles / h194 with Actual_battery_charge_-minus_or_discharge_-plus_current / h200, span 8 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Actual_battery_charge_-minus_or_discharge_-plus_current / h200 with PSSB_fuse_state / h202, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for PSSB_fuse_state / h202 with Battery_ready_flag / h208, span 8 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_ready_flag / h208 with Act_state_of_charge / h210, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Act_state_of_charge / h210 with Battery_state / h212, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_state / h212 with Battery_temperature / h214, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_temperature / h214 with Battery_voltage / h216, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_voltage / h216 with Cos_phi_(powermeter) / h218, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Cos_phi_(powermeter) / h218 with Frequency_(powermeter) / h220, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Frequency_(powermeter) / h220 with Current_phase_1_(powermeter) / h222, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_phase_1_(powermeter) / h222 with Active_power_phase_1_(powermeter) / h224, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Active_power_phase_1_(powermeter) / h224 with Reactive_power_phase_1_(powermeter) / h226, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Reactive_power_phase_1_(powermeter) / h226 with Apparent_power_phase_1_(powermeter) / h228, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Apparent_power_phase_1_(powermeter) / h228 with Voltage_phase_1_(powermeter) / h230, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_phase_1_(powermeter) / h230 with Current_phase_2_(powermeter) / h232, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_phase_2_(powermeter) / h232 with Active_power_phase_2_(powermeter) / h234, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Active_power_phase_2_(powermeter) / h234 with Reactive_power_phase_2_(powermeter) / h236, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Reactive_power_phase_2_(powermeter) / h236 with Apparent_power_phase_2_(powermeter) / h238, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Apparent_power_phase_2_(powermeter) / h238 with Voltage_phase_2_(powermeter) / h240, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_phase_2_(powermeter) / h240 with Current_phase_3_(powermeter) / h242, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_phase_3_(powermeter) / h242 with Active_power_phase_3_(powermeter) / h244, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Active_power_phase_3_(powermeter) / h244 with Reactive_power_phase_3_(powermeter) / h246, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Reactive_power_phase_3_(powermeter) / h246 with Apparent_power_phase_3_(powermeter) / h248, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Apparent_power_phase_3_(powermeter) / h248 with Voltage_phase_3_(powermeter) / h250, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_phase_3_(powermeter) / h250 with Total_active_power_(powermeter) / h252, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_active_power_(powermeter) / h252 with Total_reactive_power_(powermeter) / h254, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_reactive_power_(powermeter) / h254 with Total_apparent_power_(powermeter) / h256, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_apparent_power_(powermeter) / h256 with Current_DC1 / h258, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_DC1 / h258 with Power_DC1 / h260, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Power_DC1 / h260 with Voltage_DC1 / h266, span 8 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_DC1 / h266 with Current_DC2 / h268, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_DC2 / h268 with Power_DC2 / h270, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Power_DC2 / h270 with Voltage_DC2 / h276, span 8 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_DC2 / h276 with Current_DC3 / h278, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Current_DC3 / h278 with Power_DC3 / h280, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Power_DC3 / h280 with Voltage_DC3 / h286, span 8 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Voltage_DC3 / h286 with Total_yield / h320, span 36 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_yield / h320 with Daily_yield / h322, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Daily_yield / h322 with Yearly_yield / h324, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Yearly_yield / h324 with Monthly_yield / h326, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Monthly_yield / h326 with Battery_actual_SOC / h514, span 189 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_actual_SOC / h514 with Battery_Manufacturer / h517, span 11 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_Manufacturer / h517 with Battery_Model_ID / h525, span 10 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_Model_ID / h525 with Battery_Serial_Number / h527, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_Serial_Number / h527 with Work_Capacity / h529, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Work_Capacity / h529 with Inverter_Max_Power / h531, span 3 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Inverter_Max_Power / h531 with Inverter_Generation_Power_(actual) / h575, span 45 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Inverter_Generation_Power_(actual) / h575 with Generation_Energy / h577, span 4 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Generation_Energy / h577 with Total_energy / h578, span 3 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Total_energy / h578 with Actual_battery_charge-discharge_power / h582, span 5 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Actual_battery_charge-discharge_power / h582 with Battery_Firmware / h586, span 5 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate cant combine request for Battery_Firmware / h586 with Battery_Type / h588, span 3 > max 1
2019.11.01 15:24:27 5: PV_Anlage_1: GetUpdate doesn't sort objList before sending requests
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 240, type h, adr 150, len 2 for device PV_Anlage_1 reading Actual_cos_phi (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h150, qlen 0
2019.11.01 15:24:27 4: PV_Anlage_1: ProcessRequestQueue called from QueueRequest, qlen 1, next entry to id 71 (PV_Anlage_1), last send to this device was 154.244 secs ago, last read 154.233 secs ago, last read on bus 154.233 secs ago from id 71 (PV_Anlage_1)
2019.11.01 15:24:27 5: PV_Anlage_1: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 15:21:53.049) for PV_Anlage_1, delay 154.137secs over
2019.11.01 15:24:27 5: PV_Anlage_1: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 15:21:53.038) for PV_Anlage_1, delay 154.151secs over
2019.11.01 15:24:27 4: PV_Anlage_1: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 00f000000006470300960002 request: id 71, fCode 3, tid 240, type h, adr 150, len 2 for device PV_Anlage_1 reading Actual_cos_phi (getUpdate), queued 0.01 secs ago, read buffer empty
2019.11.01 15:24:27 5: SW: 00f000000006470300960002
2019.11.01 15:24:27 5: PV_Anlage_1: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 70, type h, adr 268, len 2 for device PV_Anlage_1 reading Current_DC2 (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h268, qlen 0
2019.11.01 15:24:27 5: PV_Anlage_1: StartQueueTimer called form QueueRequest sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 213, type h, adr 208, len 2 for device PV_Anlage_1 reading Battery_ready_flag (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h208, qlen 1
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 78, type h, adr 120, len 2 for device PV_Anlage_1 reading Isolation_resistance (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h120, qlen 2
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 149, type h, adr 586, len 1 for device PV_Anlage_1 reading Battery_Firmware (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h586, qlen 3
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 86, type h, adr 220, len 2 for device PV_Anlage_1 reading Frequency_(powermeter) (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h220, qlen 4
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 29, type h, adr 276, len 2 for device PV_Anlage_1 reading Voltage_DC2 (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h276, qlen 5
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 212, type h, adr 112, len 2 for device PV_Anlage_1 reading Total_home_consumption_Grid (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h112, qlen 6
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 223, type h, adr 322, len 2 for device PV_Anlage_1 reading Daily_yield (getUpdate), read buffer empty
2019.11.01 15:24:27 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h322, qlen 7
2019.11.01 15:24:27 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 71, fCode 3, tid 21, type h, adr 166, len 2 for device PV_Anlage_1 reading Current_Phase_3
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 01 November 2019, 16:50:21
wenn der Hersteller U32 vorgibt musst du auch len 2 nehmen (16 +16 = 32 )
mit deiner len 1 hast du immer nur die oberen 16 Bit und da ist wenn der Wert kleiner 65535 ist die Null schon richtig :)
unpack N wird vermutlich passen
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 01 November 2019, 17:53:15
Hmm, da is die Verwirrung wieder

Hersteller Doku
586 Battery Firmware - U32 1

Also für 32 len 2 obwohl 1 angegeben ist?
Und bei U32 2 dann Länge 4?

Ich versuch es morgen nochmal zu knacken...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 01 November 2019, 22:02:26
schau doch mal genau hin : ( aus dem Kostal Modbus pdf )
0x24A 586 Battery Firmware - U32 1 RO 0x03
0x24C 588 Battery Type 6 - U16 1 RO 0x03
warum folgt auf 586 nicht 587 sondern 588 ?
Die Antwort ist : weil das Register Battery Firmware sowohl 586 (high) als auch 587 (low) belegt
oder
0x217 535 Inverter Manufacturer - String 16 RO 0x03
0x227 551 Inverter Model ID - String 8 RO 0x03
585 + 16 Byte String also beginnt der nächste String bei 551

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 02 November 2019, 10:52:48
Au man bin ich dusselig,
vielen Dank für die Nachhilfe, ich bin schon zu lange raus aus den Feinheiten.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 13 November 2019, 15:26:08
Hallo Wzut,

ich komme einfach nicht klar und muss leider das Thema unpack/format wieder aufnehmen.

EDIT 2:
Ich habe nun den Fehler für die Strings gefunden. Weil die meisten Werte flouting point waren und dort "revRegs"  benötigt wurde hatte ich das als Default gesetzt.
Für die Strings musste ich das dann nun geziehlt mit "revRegs 0" wieder aufheben. So schießt man sich halt manchmal ins Knie :-)


EDIT 1:

Software-Version_IO-Controller_(IOC)     43.10     2019-11-13 16:26:39

Das habe ich jetzt durch probieren schon mal erreicht, nur ist es leider von rechts nach links zu lesen :-)

   obj-h46-bswapRegs 1     < wenn ich das auf 0 (default) setze, dann wandert der Punkt auf 4.310        es sollte jedoch 01.34 lauten.
   obj-h46-format %s
   obj-h46-len 8
   obj-h46-reading Software-Version_IO-Controller_(IOC)
   obj-h46-unpack a*         < Auch A* bringt nicht den gewünschten Erfolg
Diese Definition habe ich nun auf mehrere readings angewendet und alle Strings werden in umgekehrter Reihenfolge ausgegeben :-(

_________________________________________________________________________________________________________________
Das steht in der Modbus Doku von Kostal
Addr(hex); Addr(dec); Description; Unit; Format N; Access; Function Code   
0x2E; 46; Software-Version IO-Controller (IOC); -; String 8; RO; 0x03

Ich habe daraus nun folgendes (wohl falsch) gemacht:
obj-h46-format %s                <  %s    a string
obj-h46-len 8                    < String 8 ????
obj-h46-reading Software-Version_IO-Controller_(IOC)
obj-h46-unpack A             <  hier habe ich a,A,Z ausprobiert

Das steht im Log
2019.11.13 14:53:34 4: PV_Anlage_1: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 72, sending 006b000000064703002e0008 request: id 71, fCode 3, tid 107, type h, adr 46, len 8 for device PV_Anlage_1 reading Software-Version_IO-Controller_(IOC) (getUpdate), queued 16.23 secs ago, read buffer empty
2019.11.13 14:53:34 5: SW: 006b000000064703002e0008
2019.11.13 14:53:34 5: PV_Anlage_1: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2019.11.13 14:53:34 5: PV_Anlage_1: read buffer: 006b0000001347031030312e33340000000000000000000000
2019.11.13 14:53:34 4: PV_Anlage_1: ParseFrameStart (TCP) extracted id 71, fCode 3, tid 107, dlen 19 and data 1030312e33340000000000000000000000
2019.11.13 14:53:34 5: PV_Anlage_1: HandleResponse called from Read
2019.11.13 14:53:34 5: PV_Anlage_1: ParseResponse called from HandleResponse
2019.11.13 14:53:34 5: PV_Anlage_1: HandleResponse now passing to logical device PV_Anlage_1 for parsing data
2019.11.13 14:53:34 5: PV_Anlage_1: ParseObj called with data 30312e33340000000000000000000000, type h, adr 46, valuesLen 8, op read
2019.11.13 14:53:34 5: PV_Anlage_1: RevRegs is reversing order of up to 8 registers2019.11.13 14:53:34 5: PV_Anlage_1: RevRegs string before is 30312e33340000000000000000000000
2019.11.13 14:53:34 5: PV_Anlage_1: RevRegs string after  is 0000000000000000000034002e333031
2019.11.13 14:53:34 5: PV_Anlage_1: ParseObj ObjInfo for h46: reading=Software-Version_IO-Controller_(IOC), unpack=A, expr=, format=%s, map=
2019.11.13 14:53:34 5: PV_Anlage_1: ParseObj unpacked 0000000000000000000034002e333031 with A to  hex
2019.11.13 14:53:34 5: PV_Anlage_1: ParseObj for Software-Version_IO-Controller_(IOC) does sprintf with format %s, value is
2019.11.13 14:53:34 5: PV_Anlage_1: ParseObj for Software-Version_IO-Controller_(IOC) sprintf result is
2019.11.13 14:53:34 4: PV_Anlage_1: ParseObj assigns value  to Software-Version_IO-Controller_(IOC)
2019.11.13 14:53:34 5: PV_Anlage_1: HandleResponse got 1 readings from ParseObj for PV_Anlage_1
2019.11.13 14:53:34 4: PV_Anlage_1: ResponseDone request: id 71, fCode 3, tid 107, type h, adr 46, len 8 for device PV_Anlage_1 reading Software-Version_IO-Controller_(IOC) (getUpdate), queued 16.42 secs ago, sent 0.20 secs ago, Current read buffer: 006b0000001347031030312e33340000000000000000000000, Id 71, fCode 3, tid 107, response: id 71, fCode 3, type h, adr 46, len 8, value 30312e33340000000000000000000000
2019.11.13 14:53:34 5: PV_Anlage_1: DropFrame - drop 006b0000001347031030312e33340000000000000000000000
2019.11.13 14:53:34 5: PV_Anlage_1: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2019.11.13 14:53:34 4: PV_Anlage_1: ProcessRequestQueue called from HandleTimeout, qlen 71, next entry to id 71 (PV_Anlage_1), last send to this device was 0.195 secs ago, last read 0.123 secs ago, last read on bus 0.123 secs ago from id 71 (PV_Anlage_1)
2019.11.13 14:53:34 5: PV_Anlage_1: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 14:53:34.608) for PV_Anlage_1, delay 0.027secs over
2019.11.13 14:53:34 5: PV_Anlage_1: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 14:53:34.535) for PV_Anlage_1, delay 0.104secs over

Und im Fhem reading wird bei %s nichts angezeigt.

Aus der Kostal Oberfläche habe ich folgendes gelesen:
IOC-Version 01.34    < 0134 steht auch in dem gelesenen Buffer

006b 0000 0013 4703 1030 312e 3334 0000 0000 0000 0000 0000 00

Dann habe ich noch die Konvertierungsfunktion aus dem python Skript
#-----------------------------------------
    # Routine to read a string from one address with 8 registers
    def ReadStr8(self,myadr_dec):
        r1=self.client.read_holding_registers(myadr_dec,8,unit=71)
        STRG8Register = BinaryPayloadDecoder.fromRegisters(r1.registers, byteorder=Endian.Big)
        result_STRG8Register =STRG8Register.decode_string(8)
        return(result_STRG8Register)

Aus diesem Skript kommen folgende Meldungen für h46
46, 'Software-Version IO-Controller (IOC)', 'Strg8', b'01.34\x00\x00\x00']

Tja und nu hab ich keine Idee mehr....

Gruß
     Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: franky08 am 14 November 2019, 22:05:25
Hallo Allerseits, habe mir in die UV einen SDM530Modbus Zähler von B+G E-TECH eingebaut. Meine Frage, lässt sich Zähler über das ModbusSDM220.pm Modul oder ModbusSDM630.pm Modul oder wie auslesen? Ich habe einen Konverter (Digitus) an FHEM, der wird auch über das HM485_LAN Modul erkannt und über das Modbus Modul eingebunden.

Funktioniert das auch über das ModbusSDM630M Modul (SDM530Modbus Zähler)?


Viele Grüße
franky08
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 November 2019, 23:00:25
Hallo franky08,

Wenn es nicht funktioniert, kann das viele Gründe haben:
- serielle Parameter (Baudrate, Datenbits, Parität, Stoppbits) müssen übereinstimmen
- Modbus-Adresse muss übereinstimmen (es muss nicht die 1 sein)
- die RS485-Schnittstelle muss verfügbar sein (wenn Dein HM485 Modul die schon verwendet, könnte das ein Problem sein)
- die physische Verkabelung muss passen (der Digitus hat möglicherweise schon einen Abschlusswiderstand eingebaut. Doppelt terminiert führt evt. dazu, dass nichts mehr geht)
- es müssen die richtigen Register abgefragt werden. Viele Geräte antworten einfach nicht (auch nicht mit einer Fehlermeldung) wenn eine unbekannte Register-Adresse angefragt wird.

Ich hoffe das hilft bei der Fehlersuche.
 
Gruß
    Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: franky08 am 23 November 2019, 23:26:06
Hallo Stefan, Danke für die Antwort, hatte hier einen anderen Thread aufgemacht:https://forum.fhem.de/index.php/topic,105654.0.html

der SDM530 steht auf Adresse 1, 2400 Baud, EVEN und einem Stop Bit, genau so habe ich das in HM485_LAN:
Internals:
   DEF        localhost:2000
   DeviceName localhost:2000
   FD         7
   FUUID      5dd960f8-f33f-9332-9f01-9e4258504d86364f
   HM485d_CommandLine ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device /dev/ttyUSB0 --localPort 2000
   HM485d_PID  7466
   HM485d_STATE started
   InterfaceType HMW-SOFT-GW
   NAME       hm485
   NR         142
   PARTIAL   
   ProtokolVersion 01
   STATE      opened
   SerialNumber SGW0123456
   TYPE       HM485_LAN
   Version    0.2.2
   hmwId      00000001
   msgCounter 202
   READINGS:
     2019-11-23 22:02:37   state           opened
   keepalive:
     ok         1
     retry      0
Attributes:
   HM485d_bind 1
   HM485d_device /dev/ttyUSB0
   hmwId      00000001
   room       ModBus,System
   verbose    3

Das Modul ModbusSDM630M.pm habe ich mit der Register Belegung vom SDM530 verglichen und das Modul für diesen Zähler angepasst (da hat der 630 nur eine Register mehr, die habe ich raus genommen).

Internals:
   CFGFN     
   DEF        1 60
   FUUID      5dd99ec7-f33f-9332-adf3-b68f038d3f4cf6d2
   INTERVAL   60
   IODev      ModBusLine
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       SDM530M
   NOTIFYDEV  global
   NR         149
   NTFY_ORDER 50-SDM530M
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1574547129.93382
   TRIGGERTIME_FMT 2019-11-23 23:12:09
   TYPE       ModbusSDM530M
   lastUpdate 1574547069.93382
   FRAME:
   READ:
   READINGS:
     2019-11-23 22:04:07   state           opened
   REMEMBER:
     lrecv      1574544637.32669
     lsend      1574547069.95952
   lastRead:
Attributes:
   room       ModBus

ModBusLine :
Internals:
   DEF        /dev/ttyUSB0@2400,E,1
   DeviceName /dev/ttyUSB0@2400,E,1
   EXPECT     idle
   FD         11
   FUUID      5dd96221-f33f-9332-bd7e-141e66337d33a419
   LASTOPEN   1574547268.06125
   MODE       master
   NAME       ModBusLine
   NR         143
   NTFY_ORDER 50-ModBusLine
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2019-11-23 23:14:28   state           opened
   REMEMBER:
     lid        1
     lname      ModBusLine
     lrecv      1574547086.02487
     lsend      1574547268.0041
   defptr:
     SDM530M    1
Attributes:
   room       ModBus,System

Zitat
die RS485-Schnittstelle muss verfügbar sein (wenn Dein HM485 Modul die schon verwendet, könnte das ein Problem sein)

definitiv wird die noch nicht verwendet. Habe zum testen eine Installation auf einem "nackten" System laufen.
Zitat
die physische Verkabelung muss passen (der Digitus hat möglicherweise schon einen Abschlusswiderstand eingebaut. Doppelt terminiert führt evt. dazu, dass nichts mehr geht)

Hatte vorher gar keinen Abschlusswiderstand am Digitus (irgendwo hatte ich gelesen das einige Adapter schon einen eingebaut haben, nachgemessen --> da war keiner), mit dem 120 Ohm am Digitus bekomme ich nun ja wenigstes die Timeout Meldung. Die Register Adressen stimmen mit dem im ModBusSDM630M.pm Modul zu 99.8 % überein.

Vlt. siehst du ja im List noch was.
P.S. Müsste am Zähler eigentlich auch noch ein 120 Ohm zwischen 485+ und 485- ?
Die Kabellänge zwischen dem Zähler und FHEM beträgt ca. 2 m, dürfte auch kein Problem sein.

VG
frank
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: blueberry63 am 24 November 2019, 16:19:53
Hallo,

ich versuche mich gerade am Auslesen des Drehstromzählers OR-WE-517 von ORNO (s.: https://forum.fhem.de/index.php/topic,105685.0.html (https://forum.fhem.de/index.php/topic,105685.0.html)).

Nun stehe ich aber vollkommen auf dem Schlauch beim Umrechnen der Werte im Floating-Format. Zum Beispiel wird die Spannung (ca. 225V) mit "17245" ausgelesen. Kann mir jemand eine "Für Dummys"-Erklärung geben, wie man damit umgeht?

Gruß
Blueberry63
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 November 2019, 23:10:37
Hallo Frank,

Setz doch mal verbose von SDM530M und ModbusLine auf 5 und poste einen Auszug aus dem Log.
Vielleicht sieht man da etwas.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 November 2019, 23:18:03
Hallo Blueberry63,

Schau Dir doch mal die Erklärung im Wiki an:
https://wiki.fhem.de/wiki/ModbusAttr#Handling_Data_Types

Leider gibt es viele Möglichkeiten Float-Werte darzustellen.
Du muss einfach mal ausprobieren ob als Unpack-Code f>, f<, mit oder ohne RevRegs passen könnte.
Die Lämge wird aber vermutlich 2 sein.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: blueberry63 am 25 November 2019, 12:36:27
Danke für den Tipp:

"obj-hxxx-unpack f>" ist die Lösung  :D

Gruß
Blueberry63
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: franky08 am 25 November 2019, 15:04:01
Hallo Stefan, im Anhang der Logauszug mit verbose 5 für ModbusLine und SDM530M. Vlt. siehst du ja etwas.

VG
Frank
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: franky08 am 25 November 2019, 22:48:25
P.S. muss der Zähler neu gestartet werden nachdem die Einstellungen für die Schnittstelle geändert wurden???
PPS. Und ist B +485 und A -485?, da gibt es widersprüchliche Inhalte im Netz und müssen die Pull-up Pull-down Widerstände noch dran?

VG
Frank
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 25 November 2019, 23:45:05
Hallo Frank,

Das sieht tatsächlich seltsam aus:
2019.11.25 14:48:49 3: /dev/ttyUSB0 disconnected, waiting to reappear (ModBusLine)
2019.11.25 14:48:49 5: ModBusLine: StopQueueTimer called from Open removes internal timer to call Modbus_ProcessRequestQueue
2019.11.25 14:48:49 3: Setting ModBusLine serial parameters to 9600,8,N,1
2019.11.25 14:48:49 3: /dev/ttyUSB0 reappeared (ModBusLine)

Du hattest doch 2400,8,e,1 konfiguriert oder?

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: franky08 am 26 November 2019, 06:46:04
Bin inzwischen wieder auf 9600,N,2 gegangen, es kann sein das der Log vorher entstanden ist.

Internals:
   DEF        /dev/ttyUSB0@9600,N,2
   DeviceName /dev/ttyUSB0@9600,N,2
   EXPECT     idle
   FD         9
   FUUID      5ddbbd6e-f33f-9332-ad88-0faa635de69829ce
   IODev      ModBusLine
   LASTOPEN   1574747131.22007
   MODE       master
   NAME       ModBusLine
   NR         142
   NTFY_ORDER 50-ModBusLine
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   nextTimeout 1574747133.19154
   FRAME:
   QUEUE:
     HASH(0x5641f7399c90)
   READ:
     BUFFER     
   READINGS:
     2019-11-26 06:45:31   state           opened
   REMEMBER:
     lid        1
     lname      ModBusLine
     lrecv      1574742271.04993
     lsend      1574747131.19431
   REQUEST:
     ADR        0
     DBGINFO    getUpdate
     FCODE      4
     FRAME      (�
     LEN        40
     MODBUSID   1
     OPERATION  read
     READING    Voltage_L1__V
     SENT       1574747131.19154
     TIMESTAMP  1574747113.16472
     TYPE       i
     VALUES     0
     DEVHASH:
       DEF        1 60
       FUUID      5ddbdb7b-f33f-9332-cd96-82fc9ca5fa7b436a
       INTERVAL   60
       IODev      ModBusLine
       MODBUSID   1
       MODE       master
       MODULEVERSION Modbus 4.1.5 - 17.9.2019
       NAME       SDM530M
       NOTIFYDEV  global
       NR         143
       NTFY_ORDER 50-SDM530M
       PROTOCOL   RTU
       STATE      opened
       TRIGGERTIME 1574747173.13267
       TRIGGERTIME_FMT 2019-11-26 06:46:13
       TYPE       ModbusSDM630M
       lastUpdate 1574747113.13267
       FRAME:
       READ:
       READINGS:
         2019-11-25 22:27:10   state           opened
       REMEMBER:
         lsend      1574747131.19431
       lastRead:
   defptr:
     SDM530M    1
Attributes:
   disable    0
   room       ModBus,System
   skipGarbage 1
   verbose    0

P.S. in fhem wird mir angezeigt:
HM485d is running with PID 29004
wenn ich unter top nachschaue ist der Prozess nicht da!

   44 root      20   0       0      0      0 S  2,3  0,0   4:21.79 kworker/0:1                                                                                                                           
28506 fhem      20   0  198060 103032   3920 S  1,0  1,3   0:01.67 perl                                                                                                                                 
28472 fhem      20   0  199384 105996   5508 S  0,7  1,3   0:16.18 perl                                                                                                                                 
29178 root      20   0   42824   3620   2992 R  0,7  0,0   0:01.59 top                                                                                                                                   
  374 avahi     20   0   47256   3700   3164 S  0,3  0,0   0:05.71 avahi-daemon                                                                                                                         
    1 root      20   0  138904   6804   5340 S  0,0  0,1   0:02.34 systemd                                                                                                                               
    2 root      20   0       0      0      0 S  0,0  0,0   0:00.02 kthreadd                                                                                                                             
    3 root      20   0       0      0      0 S  0,0  0,0   0:00.29 ksoftirqd/0                                                                                                                           
    5 root       0 -20       0      0      0 S  0,0  0,0   0:00.00 kworker/0:0H                                                 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 November 2019, 18:39:27
Ich würde das ganze auf jeden Fall erst mal auf einem System ohne die Homematik-Komponenten testen.
Solange alle 2 Sekunden im Log steht, dass die rs485-Schnittstelle sich disconnected, ist vermutlich etwas auf der untersten Ebene faul.

Zudem könntest Du den rs485-Adapter mal an einen PC mit einem anderen Modbus-Master-Simulator hängen und von dort ein Register abfragen. Dann bist Du sicher, dass kein anderer Dienst sich die Schnittstelle klaut und siehst, ob Dein Zähler überhaupt reagiert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: franky08 am 26 November 2019, 18:52:48
Zitat
Ich würde das ganze auf jeden Fall erst mal auf einem System ohne die Homematik-Komponenten testen.

Hallo Stefan, auf dem System läuft nur HMCCUDEV für eine CCU2 und LaCrosse.

Mal sehen...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: R1F800 am 28 November 2019, 07:11:55
Ich würde das ganze auf jeden Fall erst mal auf einem System ohne die Homematik-Komponenten testen.
Solange alle 2 Sekunden im Log steht, dass die rs485-Schnittstelle sich disconnected, ist vermutlich etwas auf der untersten Ebene faul.

Zudem könntest Du den rs485-Adapter mal an einen PC mit einem anderen Modbus-Master-Simulator hängen und von dort ein Register abfragen. Dann bist Du sicher, dass kein anderer Dienst sich die Schnittstelle klaut und siehst, ob Dein Zähler überhaupt reagiert.

Gruss
   Stefan

Hallo Stefan,
besteht die Möglichkeit das Modbus Modul direkt mit dem RS485 (RX / TX / Pin n) kommunizieren zu lassen?
also über UART am PIN 8 / 10 / 12 ?
vG
Ingo
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 November 2019, 19:27:53
Hallo Ingo,

was meinst Du mit "direkt"?
Das Modul verwendet DevIO für die Kommunikation und das geht über die üblichen Betriebssystem-Funktionen.
Falls Du statt über /dev/ttyUSBx direkt die Hardware / Pins ansprechen möchtest, dann geht das so nicht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: R1F800 am 29 November 2019, 20:36:11
Ja genau,
Ich würde gerne direkt auf die Hardware.

Was genau müsste dann gemacht werden?
Gibt es noch kein passendes Modul für UART über TX RX?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 November 2019, 21:05:19
Darf ich fragen, was Du Dir davon versprichst?

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 29 November 2019, 21:12:06
also über UART am PIN 8 / 10 / 12 ?
wenn du an direkt an den beiden GPIOS etwas anklemmst dann ändert sich aus FHEM Sicht lediglich der Port.
D.h. statt etwa /dev/ttyUSBx oder /dev/ttyACMx hat die interne serielle Schnittstelle des RPi /dev/AMA0,
musst nur darauf achten sie auch zuvor "frei" zu machen (config.txt , usw siehe GOOGLE) wie bei allem was da direkt drauf gesteckt wird. 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: R1F800 am 29 November 2019, 22:00:53
Darf ich fragen, was Du Dir davon versprichst?

Gruss
    Stefan
Das ich kein USB kabelgeraffel an dem PI dran hab, da ich das nicht brauche.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: R1F800 am 29 November 2019, 22:02:53
wenn du an direkt an den beiden GPIOS etwas anklemmst dann ändert sich aus FHEM Sicht lediglich der Port.
D.h. statt etwa /dev/ttyUSBx oder /dev/ttyACMx hat die interne serielle Schnittstelle des RPi /dev/AMA0,
musst nur darauf achten sie auch zuvor "frei" zu machen (config.txt , usw siehe GOOGLE) wie bei allem was da direkt drauf gesteckt wird.
Soweit ok.
Aber wie kann ich dann im Modbus Modul den RX TX switch mitteilen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: franky08 am 29 November 2019, 22:03:39
@Stefan
Sooo, hab das Ganze mal auf einem frisch installierten fhem getestet, da zeigt sich der gleiche Fehler! Ich warte iMo auf ein anderes 485 ---> USB Interface (welche Module werden eigentlich benötigt? 00_HM485LAN.pm/10_HM485.pm, 98_Modbus.pm und 98_ModbusSDM530M.pm)
98_Modbus.pm und 98_ModbusSDM530M.pm werden auf jeden Fall benötigt, doch ob HM485LAN oder HM485 benötigt wird ist mir nicht ganz klar!

VG
Frank
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 November 2019, 20:38:05
Hallo Frank,

98_Modbus.pm ist das Basis-Modul für Modbus. Das brauchst Du.
98_ModbusSDM530.pm enthält die Registerdefinitionen fpr den Zähler und baut auf 98_Modbus.pm auf.

HM485 etc. haben nichts mit Modbus zu tun und wenn die auf das gleiche RS485-Interface zugreifen wollen, könnte das Probleme machen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 05 Dezember 2019, 16:33:18
Hallo zusammen,

Ich habe einen EM410 mit modbus TCP im Einsatz und wollte mal fragen, ob schon jemand so fleißig war die register zu entschlüsseln?
Für einen Kostal Plenticore 10 Plus habe ich das bereits gemacht und würde mich über einwenig Zeitersparnis freuen.

Viele Grüße
    Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: jewuma am 05 Dezember 2019, 16:51:33
Hallo Stefan,

wir versuchen gerade mit einem "IntensisBox" Modbus-Server zu sprechen.
Da hängen diverse Klimageräte dran. Dabei werden die jeweiligen Modbus-Adressen in 100er Schritten auf die einzelnen Geräte gemappt.

Eigentlich wollte ich jetzt ein define mb<id> ModbusINTENSISBOX <id> 60 <IP> TCP für jedes Klimagerät machen.
Entsprechend deinem Post vom 17.04. dachte ich auch, dass man die parseInfo im Rahmen der Define-Funktion auch anpassen kann, so dass
die passenden Register also h1xx für das erste Gerät, h2xx für das 2. Gerät usw. ausgelesen werden können. Leider klappt das nicht.
Offensichtlich existiert hier bei mir ein Denkfehler, denn er liest nur die Adressen, die in der "initialize"-Funktion angegeben werden.
Mein Code sieht so aus:

sub ModbusIBOX_Define($$) {
    my ($hash, $def) = @_;
    my @a = split("[ \t]+", $def);
    my $id=$a[2];
    my %newInfo = (
      "h105" => {
              name => "Ambient Temperature",
              reading => "Ambient_Temperature",
              unpack => "s>",
              expr => '$val/10',
              format => '%.1f C',
              poll => 1,
            },
    );
    $hash->{parseInfo}=\%newInfo;
    #foreach my $key ( keys %{$parseInfo}) {
    #  $newInfo{"h".($key+(100*$id))}=$parseInfo->{$key};
    #}
    Modbus_LD_Define($hash,$def);
}

Hast Du einen Tipp für mich, wie man mehrere Geräte mit verschiedenen Registern einbindet?

Gruß
Jens
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: jewuma am 06 Dezember 2019, 09:43:48
Das Grundproblem habe ich selbst gelöst, die Define-Funktion wurde nicht ausgelöst, da ich in der Initialize-Funktion


 $modHash->{DefFn}      = "ModbusIBOX_Define";
 ModbusLD_Initialize($modHash);

anstatt

ModbusLD_Initialize($modHash);
 $modHash->{DefFn}      = "ModbusIBOX_Define";

geschrieben hatte.
Irgendwie verstehe ich das mit den Perl-Variablen noch nicht.
Ich dachte eigentlich, wenn man eine Variable in einer Funktion mit "my $var" initialisiert, dann ist diese Variable auch nur in der Funktion sichtbar.
Offensichtlich ist das nicht so...
 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 28 Dezember 2019, 18:43:47
Hallo Ihr, "früher" hat mir modbus im fhem-log (sehr viele aufeinanderfolgende) timeout-Fehler geworfen, wenn ein Device (Stromzähler) nicht mehr ansprechbar war. Dies war der Fall, wenn der Stromzähler nicht mehr mit Strom versorgt wurde. Auf diese Fehler im Log konnte ich mit einem notify reagieren.

Mit der aktuellen modbus Version werden diese (vielen) Fehler im Log nicht mehr geschrieben....  und alle Readings bleiben unverändert .... was schade ist, da ich somit nicht mehr automatisiert auf eine fehlende Verbindung mit dem Stromnetz reagieren kann.

Jemand eine Idee, welches Reading ausgelesen werden, oder welches attr gesetzt werden kann, um ein nicht reagierendes Modbus device auch als solches zu identifizieren?

Danke und Gruß
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 Dezember 2019, 22:27:33
Hallo holle75,

timeouts werden nach wie vor geloggt. Das Loglevel ist dabei mit dem Attribut timeoutLogLevel einstellbar. Default ist 3.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 28 Dezember 2019, 23:55:41
Mmh, hatte es vorhin getestet (Zähler stromlos gesetzt) und für diesen Stromzähler kein einziges timeout mehr bekommen. Entgegen den von uns schon öfter besprochenen "normalen" timeouts ;) ... vielleicht während all der gerade parallel laufenden Tests irgendwas durcheinandergekommen. Ich versuche es morgen nochmals.

Ein galanterer Weg existiert nicht? Der ganze Umweg über fhem-log, notify usw. hat mir noch nie ganz gefallen. Gibt es nicht irgend ein Reading, was dir sagt, dass das Device gerade nicht erreichbar ist? Du hast doch sonst so ziemlich alle erdenklichen Manipulationsmöglichkeiten eingebaut ;)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 30 Dezember 2019, 11:18:28
Jo, funktioniert wie eh und je. Keine Ahnung, warum ich die timeouts im Test nicht bekommen habe.

Noch eine Idee, wie ich ohne den ganzen Umweg erkennen kann, ob ein physisches Modbus Device aktiv/inaktiv ist?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 Dezember 2019, 13:58:07
Hallo,

Setz doch mal das Attribut profileInterval.
Da werden auch Statistik-Readings zu Timeouts erzeugt.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 30 Dezember 2019, 17:41:59
Ah, very nice. Muss mal schauen, wie viele timeouts bei Stromlos in der entsprechenden Zeitspanne geworfen werden und kann dann darauf triggern. Und dann endlich timeoutloglevel auf 4 setzen :)

Das sagt mir zwar nicht welches Device, aber das etwas nicht stimmt. Bei nur zwei Devices ist die Wahrscheinlichkeit hoch, dass es der entsprechende Stromzähler ist.

Danke Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: breitbanddilettant am 09 Januar 2020, 22:42:22
Hallo Zusammen,

ich besitze eine Ecodan ERSC-VM2C und greife per Modbus Interface auf die Ecodan zu.

define ModbusBus Modbus /dev/ttyUSB0@9600
define Ecodan ModbusAttr 1 60
attr Ecodan IODev ModbusBus
attr Ecodan dev-h-defPoll 1
attr Ecodan event-min-interval .*:600
attr Ecodan event-on-change-reading .*

Einmal die Minute hole ich mir mit ca. 30 Readings die Werte diverser Ecodan Register ab - darunter auch z.B. der Sollwert der Vorlauftemperatur. Die Vorlauftemperatur kann ich dann von fhem aus auch anpassen und an die Ecodan zurückschicken.

Das reading für Tsoll-Vorlauf sieht z.B. so aus:
attr Ecodan obj-h32-expr $val/100
attr Ecodan obj-h32-hint 30,31,32,33,34,35,36,37,38,39,40
attr Ecodan obj-h32-max 60
attr Ecodan obj-h32-min 10
attr Ecodan obj-h32-reading Tsoll-Vorlauf
attr Ecodan obj-h32-set 1
attr Ecodan obj-h32-setexpr $val*100

Über ftui habe ich eine GUI gebaut, mit der ich per Knopfdruck diesen Sollwert um 1 erhöhen oder verringern kann.
<div class="cell">
<div class="doublebox-v tiny">
<div data-type="push" data-device="Ecodan" data-set="Tsoll-Vorlauf" data-icon="fa-chevron-up" data-background-icon="fa-square-o" data-set-on="[Ecodan:Tsoll-Vorlauf-Up]">
</div>
<div data-type="push" data-device="Ecodan" data-set="Tsoll-Vorlauf" data-icon="fa-chevron-down" data-background-icon="fa-square-o" data-set-on="[Ecodan:Tsoll-Vorlauf-Down]">
</div>
</div>

Außerdem habe ich eine Anzeige für Tsoll-Vorlauf
<div class="cell">
<div data-type="label" data-device="Ecodan" data-get="Tsoll-Vorlauf" data-unit="&deg;C" data-fix="0" class="big bold cell orange"></div>
<div class="top-narrow  small">Soll</div>
</div>

Folgendes Verhalten (wir starten mit 35°C Tsoll-Vorlauf):

- in der GUI wird Tsoll-Vorlauf angepasst. Drei mal drücken auf "push" -daher sollte folgende Sequenz angezeigt werden 35°C->36°C->37°C->38°C

- bei jedem neuen Wert wird ein set Befehl an die Ecodan geschickt, diese Braucht aber einige Sekunden, um das Empfangene zu verarbeiten. In ftui wird aber alles direkt richtig angezeigt. Also 35°C->36°C->37°C

- ABER: ziemlich zeitgleich werden manchmal zufällig (z.B. weil eine Minute wieder vergangen ist) die Register der Ecodan ausgelesen - und hier steht auf Grund der Verzögerung der Ecodan noch der alte Wert 35°C drin

- Das hat dann zur Folge, dass der in fhem/ftui angezeigte Wert von Tsoll-Vorlauf mal dem neuen Vorlaufwert (von mir per gui vorgegeben) und mal dem alten Vorlaufwert (der, der halt noch von der Ecodan genutzt wird und gerade vom reading geholt wurde) entspricht. Also springt die Anzeige von 35°C->36°C->37°C->35°C und mein nächster Tastendruck erhöht den Wert dann wieder auf 36°C. Also schauts dann in Realität so aus: 35°C->36°C->37°C->35°C->36°C.

Grundsätzlich ist das Problem, dass ich den neuen Sollwert auf Basis des aktuellen Wertes berechne und sich durch das minütlich wiederkehrende reading teilweise der falsche aktuelle Wert ausgelesen wird.

Jetzt zu meiner Frage:
- Gibt es eine Möglichkeit neue set Werte direkt zu übermitteln, aber mit dem get Abruf der Werte eine Vorgegebene Zeit zu warten, sodass sich set und get nicht in die Quere kommen?
- hat jemand eine alternative Idee?

Danke und schöne Grüße

 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 Januar 2020, 23:45:33
Hallo breitbanddilettant,

Du könntest mal versuchen, für Dein Soll-Reading ein pollDelay zu setzen.
Die Modbus-Response für function code 6 (write Holding Register) enthält ja wieder den gesetzten Wert.
Der wird vom Modul wie eine Antwort auf function code 3 verarbeitet und dabei merkt sich das Modul, wann das Reading zuletzt gelesen wurde. Auch wenn es kein function code 3 zum Lesen sondern 6 zum Schreiben war.

Beim nächsten Update-Zyklus (wenn die Minute um ist) schaut das Modul dann für jedes zu lesende Objekt ob ein gesetzter pollDelay auch schon abgelaufen ist. Falls nicht (weil zwischen drin ein set Befehl kam) wird das Reading dieses Mal nicht abgefragt, sondern erst beim nächsten Update-Zyklus.
Eventuell kannst Du Dein Problem so lösen.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: breitbanddilettant am 10 Januar 2020, 08:49:13
Hi Stefan,

vielen Dank - das scheint geholfen zu haben :-)

Grüße,
Konstantin
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 21 Januar 2020, 18:32:42
Hi,

ich lese gerade ein Gerät mit modbus aus und kann den Wert auch schon sehen.

dev-type-INT16-format %s
dev-type-INT16-len 1

obj-h40077-reading Phase_A_to_Neutral_AC_Voltage
obj-h40077-type INT16

Das ergibt folgendes Reading

Phase_A_to_Neutral_AC_Voltage 23081

%s ergibt hierbei natürlich einen String, jedoch müsste der Wert 230.08 werden und ich finde das Zauberwort dazu nicht.

In der Modbus Doku steht dazu als Beispiel folgendes "4950 Hz * 10 ^ {- 2} = 49.50 Hz"

Wie kann ich das nun im modbus Modul umsetzen? Gibt es eventuell einen anderen Parameter (anstatt %s), der mir den Wert umrechnet?
Kann ich die Formel bei der Formatanweisung irgendwie direkt einsetzen? Wie wäre da der Syntax?

Viele Grüße
    Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Frank_Huber am 21 Januar 2020, 20:20:39
Müsstest doch nur durch 100 teilen.

Das obj-h40077-expr attribut auf "$val/100"



Gesendet von meinem Doogee S60 mit Tapatalk
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 22 Januar 2020, 14:11:49
Müsstest doch nur durch 100 teilen.
Das obj-h40077-expr attribut auf "$val/100"
Hallo Frank,
ich bin echt dem Depp sein Sohn :-)

Mit der folgenden Format geht es problemlos
dev-type-INT16-expr  $val/100
dev-type-INT16-format  %.2f
dev-type-INT16-len 1

Und schon sieht es dann so aus

Phase_A_to_Neutral_AC_Voltage  232.97

Gruß
    Christian
Titel: Frage zu MODBUS und RS485 über USB
Beitrag von: w125t am 23 Januar 2020, 11:57:08
Ich hatte schon seit einiger zeit einen EPEVER TRACER Laderegler mit USB-RS485 Adapter mit CM340 und Modbussattr am laufen , seit voriger Woche erhalte ich jedoch keine Readings mehr.
Am WINDOWS rechner funktioniert der Adapter problemlos.

Ich habe schon einige tests mit den timern gemacht , aber leider immer kein Ergebnis.

Könnt Ihr helfen ?

LOG ist als Anlage dran.
Danke
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: w125t am 23 Januar 2020, 18:40:35
ich habe FHEm neu aufgesetzt und damit funktioniert es erstmal readings sind wieder da ,aber interessant wäre schon , warum es nicht mehr ging.
Es hat 2 Monate funktioniert. Ich mache jetzt nochmal ein Fhem update und schaue mal.

Ich denke der der CH340 chip ist eher ungeeignet , ich habe mir jetzt mal diesen bestellt ,
https://www.amazon.de/gp/product/B07B416CPK/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
was denkt Ihr als Profis darüber ?????
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: w125t am 23 Januar 2020, 18:49:39
nach update all wieder keine readings , schade , habt ihr eine Idee???
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: w125t am 23 Januar 2020, 19:05:31
letzte Version war die 5.8 Fhem mit der läuft es
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: w125t am 24 Januar 2020, 11:55:21
letzte Version war die 5.8 Fhem mit der läuft es

NAch  1 Stund fällt es wieder aus :-(
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: The Spirit am 19 Februar 2020, 10:30:50
Hi.
Ich versuche mit dem SolarEdge modul was Modbus benutzt auf meinen Wechselrichter zuzugreifen.
Leider klappt dies nicht (disconnected).
Daher wollte ich erstmal nur mit dem Modbus Modul versuchen, ein connected hinzubekommen.
Leider bleibt auch hier das device auf disconnected stehen.
Im log steht einmal:
Open Callback: ip: Connection refused (111)bzw.
successive open ignoredIch muss dazu sagen, das ich von einer anderen Haussteuerungssoftware schon auf den Wechselrichter per Modbus TCP zugreife.
Kann es sein, das ich dann mit FHEM nicht mehr per modbus TCP auf das gleiche Gerät zugreifen kann?
Was kann ich noch testen?
Danke
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bertl am 19 März 2020, 21:33:17
Hallo Zusammen,

ich habe eine Mitsubishi Ecodan Luft-Wärmepumpe.
An der Inneneinheit EHST20C-YM9EB ist das Modbus-Modul Procon MelcoBEMS MINI A1M angeschlossen.
Das Modbus RTU Protokoll wird über den Ethernet-Converter USR-TCP232-410s ins hausinterne LAN gespeist.
Von dort holt sich mein Raspberry Pi 3 Model B die Daten ab.

define mdbsWaermepumpe ModbusEcodanWP 1 30 192.168.1.101:502 TCP
Prinzipiell funktioniert das Ganze auch, aber ich bekomme relativ viele Einträge im Log-File folgender Art:

2020.03.19 12:20:06 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 152, type i, adr 28, len 2 for device mdbsWaermepumpe reading Kaeltemittel_Fehlerinfo (getUpdate), queued 5.93 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 12:35:11 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 63, type i, adr 8, len 2 for device mdbsWaermepumpe reading Modbus_Fehler (getUpdate), queued 11.09 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 12:37:37 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 129, type i, adr 39, len 2 for device mdbsWaermepumpe reading Heizen_Quelle (getUpdate), queued 6.67 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 12:57:42 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 247, type i, adr 29, len 2 for device mdbsWaermepumpe reading Anlage_Fehlercode1 (getUpdate), queued 11.82 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 12:58:40 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 104, type i, adr 32, len 2 for device mdbsWaermepumpe reading WP_Frequenz_Hz (getUpdate), queued 9.61 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:07:14 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 15, type i, adr 32, len 2 for device mdbsWaermepumpe reading WP_Frequenz_Hz (getUpdate), queued 14.02 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:14:40 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 70, type i, adr 8, len 2 for device mdbsWaermepumpe reading Modbus_Fehler (getUpdate), queued 9.60 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:36:12 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 225, type i, adr 44, len 2 for device mdbsWaermepumpe reading Temp_Vorlauf_SOLL (getUpdate), queued 11.81 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:44:39 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 2, tid 91, type d, adr 21, len 1 for device mdbsWaermepumpe reading Wasserpumpe (getUpdate), queued 8.88 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:46:09 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 2, tid 64, type d, adr 21, len 1 for device mdbsWaermepumpe reading Wasserpumpe (getUpdate), queued 8.87 secs ago, sent 3.00 secs ago, read buffer empty
2020.03.19 13:53:07 3: mdbsWaermepumpe: Timeout waiting for a modbus response request: id 1, fCode 4, tid 103, type i, adr 28, len 2 for device mdbsWaermepumpe reading Kaeltemittel_Fehlerinfo (getUpdate), queued 6.69 secs ago, sent 3.00 secs ago, read buffer empty
Pro Tag in etwa 30 bis 50 Einträge, wobei es sich um verschiedenste Readings handelt.

Meine Frage dazu:
Sind diese Log-Einträge normal oder passt irgend eine Einstellung nicht (ich kann leider mit dieser Log-Info nicht viel anfangen)?

Danke für eure Hilfe!

(Im Anhang die Internals und ein 17min Verbose 5 Log - leider kein Timeout in dieser Zeit)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 22 März 2020, 13:33:21
ohne jetzt das zu kennen, evtl. ein Ansatz:

dev-timing-timeout 3

3 Sekunden ist vieleicht etwas wenig

und bei deinem DEFINE vom Device   hast du 30 Sekunden intervall angelegt, vieleicht definierst du das device mit einem längeren intervall.


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bertl am 23 März 2020, 13:49:31
Hallo laserrichi,

danke für deinen Vorschlag!

Dadurch wird aber wahrscheinlich das Problem nicht gelöst, WARUM diese Timeouts mit den 'read buffer empty' auftreten.
Auf was soll ich das 'dev-timing-timeout' setzen?
Bei den Meldungen 'queued X.XX secs ago, sent 3.00 secs ago' variert X.XX von 3.00 bis zu 17.00 secs!

Sicher könnte man das Device Abfrageintervall auf 120 Sekunden und das Register-Timeout auf 30 Sekunden setzen - aber gehen dann nicht wichtige Infos verloren?

Wenn man den Grund für die hohen Timeouts findet (falsches Setup, Internetverbindung, Sync-Probleme, ...), dann kann man das Problem bei den Wurzeln packen und lösen.
Leider habe ich überhaupt keine Idee, wo ich zum Suchen anfangen soll!

Daher meine Frage um Hilfe in diesem Forum.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 23 März 2020, 17:12:25
also ich weis ja nicht wie dein Netzwerk aussieht, gehst du z.b. über eine Wlan Verbindung dahin ?
Ich hab bei meinem Modbus Device gemerkt das bei zu vielen Abfragen sich das auch gerne mal beleidigt fühlt.
Daher erst mal der Ansatz die Zeiten zu erhöhen.

Brauchst du wirklich alle 30sekunden die Informationen ?

Setz das ruhig mal auf 5min. Ich frage mein Solar z.b. nur alle 10min ab, sicher gehen mir dann schon mal Peaks verloren in der Statistik.

Wenn du z.b. 10 requests hast und jeder bringt einen timeout von z.b. 3sek plus die eigentliche request zeit, dann bist du schon über 30sekunden ;-)

Weniger abfragen ist meist mehr.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bertl am 23 März 2020, 20:23:02
Sämtliche Verbindungen sind verkabelt, also über LAN verbunden.

5min sind definitiv zu lange, da z.B. die Zusatzheizung meistens nur für etwa 1,5 Minuten anspringt und dann würde ich diverse Events verpassen.

Ich habe das Abfrageintervall vor 2 Stunden auf 1Min erhöht und hatte innerhalb dieser Zeit schon 2 Timeouts.

Gibt es sonst noch Lösungsvorschläge (Baudrate zwischen Modbus-Modul und Ethernet-Converter von 9600 auf ?? erhöhen, ...)?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 24 März 2020, 00:46:28
@bertl,

wenn die Modbusschnittstellen 115200 Baud hergeben würde ich das auch einstellen. laut Doku sollte es die Pumpe und das TCP/IP Modul können.
Versuch macht klug ;-) .

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 24 März 2020, 08:26:55
Gibt es sonst noch Lösungsvorschläge
Wieviele Register liest du denn jedesmal ? Ich hatte bei meinem SMA WR auch ab und an die Meldungen im Log und habe dann die Anzahl der Lese Register auf das wirklich notwendige beschränkt. Seit dieser Zeit ist Ruhe im Log.
Titel: Antw:Frage zu MODBUS und RS485 über USB
Beitrag von: StefanStrobel am 24 März 2020, 20:33:57
Ich hatte schon seit einiger zeit einen EPEVER TRACER Laderegler mit USB-RS485 Adapter mit CM340 und Modbussattr am laufen , seit voriger Woche erhalte ich jedoch keine Readings mehr.
Am WINDOWS rechner funktioniert der Adapter problemlos.

Ich habe schon einige tests mit den timern gemacht , aber leider immer kein Ergebnis.

Könnt Ihr helfen ?

LOG ist als Anlage dran.
Danke

Hallo w125t,

ich habe Deine Frage leider erst jetzt bemerkt. Bei einem Blick ins Log fallen mir direkt Konfigurations-Fehler auf:
Zitat
request: id 1, fCode 4, type h, adr 12544
Du versuchst Holding-Register mit function code 4 zu lesen. Damit liest Du aber ein Input-Register. Entsprechend wird beim Verarbeiten der Antwort nach einer Parse-Anweisung für i12544 gesucht. Die gibt es aber nicht.

Poste doch mal die komplette Konfiguration, dann lässt sich das Problem sicher lösen, sofern es noch aktuell ist.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bertl am 25 März 2020, 11:20:44
Ich glaube das Problem für meine Log-Einträge (Timeouts mit "read buffer empty") gefunden zu haben.

Aufgrund des Vorschlages von pejonp habe ich die Baudrate auf 115200 eingestellt.
wenn die Modbusschnittstellen 115200 Baud hergeben würde ich das auch einstellen. laut Doku sollte es die Pumpe und das TCP/IP Modul können.
Versuch macht klug ;-) .

Dabei ist mir ein Eintrag im Log aufgefallen, den ich bis jetzt nicht beachtet habe, da ja das Lesen und Schreiben der Modbus-Werte prinzipiell funktioniert hat.
2020.03.24 09:55:19 3: mdbsWaermepumpe: DoRequest tries to use function code 6 to write more than one register. This will not work
Nach genauerer Recherche ist mir aufgefallen, dass beim Mitsubishi Modbus-Adapter sämtliche Werte in einem separaten Register stehen (keine Werte wo 2 Register wie z.B. bei Float benötigt werden).
Bei meinen Device-Definitionen "dev-([cdih]-)*defLen" wurden die Holding- und Input-Register aber auf 2 gesetzt.

Ich habe das Modbus-Modul "98_ModbusEcodanWP.pm" von Fritz Muster verwendet und bin davon ausgegangen, dass die Device-Definitionen passen, nachdem es sich um den gleichen Modbus-Adapter handelt.
https://forum.fhem.de/index.php/topic,69066.msg605457.html#msg605457 (https://forum.fhem.de/index.php/topic,69066.msg605457.html#msg605457)

Lieber Fritz, vielleicht kannst du die Device-Definition in deinem Modul "98_ModbusEcodanWP.pm" richtig stellen, falls es jemand anderer auch verwendet.

Nachdem ich die "dev-([cdih]-)*defLen" für die Holding- und Input-Register auf 1 gesetzt habe, sind die Timeouts mit "read buffer empty" weg.

Was ich sonst noch aufgrund den Empfehlungen von laserrichi und pejonp getan habe:
+ Device Abfrageintervall von 30 auf 60 Sekunden erhöht
+ Baudrate von 9600 auf 115200 erhöht

Danke an alle die mir geholfen haben mein Problem zu lösen!  :)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 25 März 2020, 22:32:16
Zum Thema Intervall ist mir etwas aufgefallen als ich mir das Modul soeben nochmal angesehen habe.

Bei den Abfragen sind Poll Delays drin.
z.b. x6  oder auch höhere Werte mit x360
das ist ein multiplikator also 6x 60sekunden. Vieleicht macht es hier Sinn das du Dir das nochmal ansiehst und nach deinen bedürfnissen anpasst.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bertl am 27 März 2020, 22:10:11
Hallo laserrichi,

danke für den Hinweis - dieses Detail ist mir bekannt und die Werte sind darauf abgestimmt!

Gruss bertl
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Fritz Muster am 30 März 2020, 13:20:27
Lieber Fritz, vielleicht kannst du die Device-Definition in deinem Modul "98_ModbusEcodanWP.pm" richtig stellen, falls es jemand anderer auch verwendet.

Erledigt, danke für den Hinweis.

+ Baudrate von 9600 auf 115200 erhöht

Das funktioniert aber nicht bei Anbindung via Arduino wie ich es in meinem Thread beschreibe!

Grüße Fritz
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bertl am 30 März 2020, 14:19:50
Hallo Fritz,

danke für die Implementierung!

Das funktioniert aber nicht bei Anbindung via Arduino wie ich es in meinem Thread beschreibe!
Warum sollte das nicht funktionieren?

Meines Wissens kann ein Arduino mehr als nur 9600 Baud?  https://forum.arduino.cc/index.php?topic=207375.0 (https://forum.arduino.cc/index.php?topic=207375.0)

Gruss bertl
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Knallkopp_02 am 17 April 2020, 11:24:38
Ich bin durch Zufall auf diesen Thread gestossen, weiß aber nicht, ob ich richtig bin, da ich nicht genau weiß ob die Datenabfrage bei mir über RS485 läu.ft

Ich habe jetzt an meinem Raspberry einen USB To Serial Adapter, an dem dann der Adapter zu RS485 mit der Anlage ist (zumindest gehe ich davon aus). Da diese Konstellation am PC ja mit dem Maservolt eigenen Programm läuft gehe ich davon aus, das dies auch generell am Raspberry funktionieren sollte.

Leider verstehe ich nicht, wie ich nun die Anfrage per Modbus an die Wechselrichter schicke und dann die passende antwort erhalte.

Der Befehl ist so aufgebaut:

ID WR Befehl Checksumme
22 01 ff ff b4 00 00 00 d5

Wenn ich den oben genannte Frage am PC stelle (das habe ich über VBA getestet), bekomme ich folgende Antwort.

Wobei Modell Firmware Datum sein sollte
22 01 ff ff b4 00 00 00 d5 ff ff 22 01 b4 fe 04 57 36 07 4a 03 06 e4 00 12 00 17 08 e5 00 54 00 29 08 e6 01 00 24 07 4f

Generell habe ich folgendes in FHEM definiert:

define ModBusPVA Modbus /dev/ttyUSB1@9600,8,N,1

Würde mich über eure Hilfestellung freuen.

Gruß Knallkopp_02
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 17 April 2020, 20:38:23
Also RS-485 ist im Prinzip eine Definition für die Physikalische Schnittstelle  und ist eine asynchrone Datenübertragung und symetrisch damit eben keine Störeinflüsse auf die Leitungen kommen.
Das hat jetzt erstmal nichts mit Modbus zu tun :-)
Aber jetzt kommt der Haken... du gehst von USB auf serial... das teil muss dann die gleiche Datenrate aufweisen wie deine Gegenstelle.

Du hast jetzt 9600 baud eingestellt, ist normalerweise aus alten Zeiten und die sichere Datenrate was eigentlich alle können müssten.

Dein USB to serial sollte das ja dann richtig umsetzen. Dann wandelst du das in RS-485 symetrische Spannungspegel.

Sofern die Physik Ok ist. gehts dann an Modbus.

Du nutzt Modbus Modul.. hast du schon mal ModbusAttr  probiert ? Und eben die readings direkt selbst difiniert ?


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 17 April 2020, 21:00:00
@Knallkopp_02

was für einen WR nutzt du den ? Bezeichung, Datenblatt ?

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Knallkopp_02 am 18 April 2020, 07:14:34
Hallo ihr beiden,

Leider ist die Dokumentation der Schnittstelle sehr minimalistisch, um es positiv auszudrücken, vom Hersteller Mastervolt habe ich praktisch nichts an Doku gefunden. Durch Zufall bin ich dann auf einen Beitrag in einem anderen Forum gestoßen wo jemand die Kommunikation mit KNX lösen wollte und da habe ich zumindest diese Daten her.

Insgesamt nutzte ich 3 Wechselrichter die hintereinander an einem RJ45 Kabel an besagtem Adapter hängen ( Mastervolt XS 6500 und 2x XS 3200)

Angeblich soll die Kommunikation ähnlich wie zum Soladin von Mastervolt sein.

Ich habe damals vom Solateur einmal diesen absolut überteuerten Adapter bekommen, und die Info, dass ich die Baudrate auf 9600 stellen soll, und dann das Mastervolt eigene Programm darauf zugreifen kann. Die ist zwar funktional, war aber nur mit Gut Zureden auch unter Win 10 ans laufen zu bekommen.

Wenn ich dich Laserrichi jetzt richtig verstehe muss ich mit modbusattr eine „Befehl“ so wie oben erstellen, dem gebe ich einen Namen und dann die Zeichenfolge. Daraufhin sollte er mir dann irgendetwas zurück geben?

Ist mein erstes herumspielen mit Modbus und Fhem, daher muss ich erstmal die Zusammenhänge verstehen. Mit dem VBA Script musste erstmal der Port geöffnet werden, dann die Anfrage gestellt und dann die Antwort abgefragt werden. Leider funktioniert das Script under Win 10 64 Bit nicht mehr, dass hatte ich mir vor langer Zeit mal unter 32 Bit zusammen gestückelt.

Gruß Knallkopp_02
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 18 April 2020, 11:10:27
@Knallkopp_02

Ist es dieser Hersteller : https://www.mastervolt.de/produkte/masterbus-interfaces/masterbus-modbus-interface/

Meine Gehversuche mit meinem SolarEdge sahen so aus. Er ist übe einen RS485/IP-Adapter angebunden.
wenn du per USB, dann eher so

define Modbus /dev/device@baudrate,bits,parity,stop
define <name> ModbusAttr <Id> <Interval>

define ModbusUSB Modbus /dev/ttyUSB2@38400,8,E,2
define PWP ModbusAttr 20 0 ASCII

richtige Modbus-ID eingeben und ein Modbus-Register abfragen. Versuche mit h1 ?! Oder es gibt auch jetzt eine Funktion die das automatisch versucht. Schau mal ins Forum oder in die commandref (ModbusAttr).

...
Set-Commands for Fhem as Modbus master operation

    are created based on the attributes defining the data objects.
    Every object for which an attribute like obj-xy-set is set to 1 will create a valid set option.
    Additionally the attribute enableControlSet enables the set options interval, stop, start, reread as well as scanModbusObjects, scanStop and scanModbusIds (for devices connected with RTU / ASCII over a serial line).
    Starting with Version 4 of the Modbus module enableControlSet defaults to 1.
...

Beispielcode
# RS485 SolarEdge Wechselrichter
define PWP ModbusAttr 3 60 192.168.2.7:20108 RTU
attr PWP dev-h-combine 30
attr PWP dev-h-defPoll 1
attr PWP obj-h100-reading I_DC_Leistung_W
attr PWP obj-h101-reading I_DC_Leistung_SF
attr PWP obj-h103-expr $val / 100
attr PWP obj-h103-format %.f
attr PWP obj-h103-reading Temp_Kuehler_C
attr PWP obj-h107-map 1:Aus, 2:Nachtmodus, 4:WR_An
attr PWP obj-h107-reading C_Status
attr PWP room Solar
attr PWP verbose 5

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Knallkopp_02 am 18 April 2020, 19:17:40
Ich werde mich mal durchtesten und sehen was ichh an Infos bekomme. Schonmal herzlichen Dank, Melde mich, wenn ich Daten bekomme.

Gruß Knallkopp_02
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 19 April 2020, 11:46:35
Also duku lesen wird dir nicht erspart bleiben.

Ich habe selbst auch etwas zeit gebraucht bis ich das ganze begriffen habe, vor allem das man hex in dezimal umrechnen musste. Die Readings sind in dezimal, und die dokus der Geräte meistens in hex.
Wenn du da keine Dokumentation hast wird es sowieso extrem schwierig. Du weist ja nicht welche Art von Register (input, hold, coil) und ob es high low register gibt und wie sie zusammengehören.

Es gibt bei modbusattr ja scanModbusId  dann findest du vieleicht deine ganzen Geräte. scanModbusObjects findet vieleicht deine readings. Habe das selber nie probiert.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Knallkopp_02 am 19 April 2020, 12:17:22
Da die Doku praktisch nicht vorhanden ist, habe ich sowieso schon viel gesucht.

Mit der ID ist die ID des Gerätes gemeint? Weil das PC Programm gibt mir IDs aus, dann könnte ich damit schonmal starten. BZW eigendlich ist die 22 01 die Geräteaddresse in der Anfrage.

Das ist aus meinem Script, was zu Windows 7 32Bit Zeiten noch gelaufen ist. Ich hatte den Rückgabewert an den Leerzeichen getrennt und dann als Array generiert. Ich nehme an, das die Register jetzt der Arraynummer entsprechen, oder sehe ich das falsch?

seriennummer = Chr(CLng("&H" & WrdArray(16))) & Chr(CLng("&H" & WrdArray(17))) & Format(WrdArray(18), "00") & Chr(CLng("&H" & WrdArray(19))) & Format(WrdArray(20), "00") & Format(WrdArray(21), "00")wenn ich die Seriennummer des Gerätes ausgelesen bekomme, dann habe ich es warscheinlich auch verstanden, weil wo was steht habe ich in meinem Script.

Gruß Knallkopp_02
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 April 2020, 12:22:00
Hallo,

ID WR Befehl Checksumme
22 01 ff ff b4 00 00 00 d5

Wenn ich den oben genannte Frage am PC stelle (das habe ich über VBA getestet), bekomme ich folgende Antwort.

Wobei Modell Firmware Datum sein sollte
22 01 ff ff b4 00 00 00 d5 ff ff 22 01 b4 fe 04 57 36 07 4a 03 06 e4 00 12 00 17 08 e5 00 54 00 29 08 e6 01 00 24 07 4f

Das sieht leider nicht nach Modbus aus.
Unter http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf findest Du die Spezifikation des Modbus-Protokolls.
Modbus RTU über serielle Leitungen überträgt die Requests in der Form id,fCode,data,crc.
Für mich sieht das nach einem anderen / proprietären Protokoll aus.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Knallkopp_02 am 19 April 2020, 13:37:57
Könnte es dann eine normale Serielle Verbindung über RS485 sein, weil dieser Begriff ist immer gefallen?

Gruß
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 April 2020, 14:00:26
Klar, RS485 ist nur eine Alternative zu RS232. Einfach eine anderen Verkabelung / Logik, aber ebenso eine serielle Verbindung.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Knallkopp_02 am 19 April 2020, 15:14:43
Dann werde ich mich wohl mit ECMD von FHEM beschäftigen müssen, dass scheint dann das richtige zu sein.

Gruß und herzlichen Dank
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 19 April 2020, 18:46:01
@Knallkopp_02 , pejonp hat dir mit https://www.mastervolt.de/produkte/masterbus-interfaces/masterbus-modbus-interface/ schon die goldene Brücke gebaut !
Rübergehen , d.h. runterladen und lesen musst du schon selbst. Die beschreiben dort ganz genau wie via Modbus Register zu lesen oder zu beschreiben sind und vor allem in welchen Registern sich die Werte verstecken.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 21 April 2020, 17:57:34
da ich leider nicht der perl Spezialist bin und mir das Thema unpack immer noch etwas rätselhaft ist, hier eine Frage an die Experten:

Folgendes Register will ich verarbeiten:
Battery Current Low  331B (hex) The net battery current,charging current minus the discharging one. The positive value representscharging and negative, discharging.
darauf folgt das high register mit Adresse 331C
Das ist der Lade/Entladestrom der Batterie.
Bisher hatte ich nur das low Register ausgelesen und entsprechend umgerechnet.
dev-i-defRevRegs 1
attr Solarlader obj-i13083-expr if ($val > 32767){($val-65536)/100}else{$val=($val/100)}
attr Solarlader obj-i13083-reading BattStrom
aber sauber ist das meiner meinung nach nicht, vor allem möchte ich es "sauber" mit dem High entsprechend abbilden.

hier habe ich versucht:

attr Solarlader obj-i13083-expr $val=($val/100)
attr Solarlader obj-i13083-len 2
attr Solarlader obj-i13083-reading BattStrom
attr Solarlader obj-i13083-unpack N

das liefert mir natürlich utopische werte wie  42949672.95  sobald der Strom ins negative geht, also die Batterie entladen wird.

Da bei meinem Laderegler die High immer in der Adresse danach kommen, habe ich eben defRevRegs 1  generell gesetzt.
Oder muss ich hier das entfernen und unpack N>  als big-endian angeben ?

Seltsamerweise wenn es im Positiven Bereich ist, stimmt der Strom.
Versuche mit unpack l L als signed oder unsigned scheiterten.
Der Wert ist 0,00A deswegen teile ich immer durch 100 bei den expr.

Die doku gibt da leider nicht mehr her als der text der da oben steht.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 21 April 2020, 19:13:45
Hi laserrichi,

Kannst du mal einen link oder die Doku hier anhänge. Vielleicht gibt es ein extra Register mit der Angabe der Richtung. Beim SolarEdge gibt es ein Register für die kommastelle. Nur so ein Schuss ins blaue.

Pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 21 April 2020, 19:40:54
Ok, hier sind 2 PDFs über die Protokolle die ich im Netz gefunden habe. Nicht alle Regler haben alle Register. Aber diese ganzen EPEVER haben wohl alle den gleichen Aufbau egal welche Serie, und gibt es auch unter verschiedene Namen. In dem einen sind auch Beispiele drin aber eben nicht zu dem Register mit möglichen Negativen Wert.

Kann ich meine readings so setzen und bearbeiten das ich diese in binär form in ein Log bekomme ?
Dann erkennt man vieleicht etwas wie das gesetzt wird. Wenn ich z.b. 1A habe postiv, dann steht das Word auch entsprechend. Habe ich -1A dann muss ich vom Word 32767 dezimal abziehen. Zumindest hatten so meine Werte einigermaßen gestimmt.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 21 April 2020, 20:07:59
@laserrichi

schau mal hier --> https://www.perl-community.de/bat/poard/thread/19451 vielleicht hilft das.

Du kannst doch aber auch das Modbus-Device definieren.

defmod PWP ModbusAttr 3 60 192.168.4.7:20108 RTU

und dann mit

set PWP scanModbusObjects

das erkennen loslaufen lassen. Es werden dann mehrere Decodierungen versucht.

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 21 April 2020, 20:27:03
Ok Danke,  das werd ich mal probieren.
Ich habe gerade mit Verbose 5 das ganze angesehen.
die 2Bytes  und der umgerechnete dezimalwert /100:
0007    0.07
und bei negativem Strom wird wohl von ffff  runtergerechnet:
ff6f   -1.45
ff45   -1.87
ffed   -0.19

Wenn ich jetzt die 2 readings nehme habe ich bei postiven werten
00000007
bei negativen
zählt wohl auch das highbyte von ffff runterwärts
fffffff1

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 21 April 2020, 20:51:06
@laserrichi

vielleicht kannst du es dir auch einfach machen:

bin: 0111111111111111
dec: 32767
hex: 7FFF

alles was grösser als 32767 ist, ist negativ. So wie du es in deinem Beispiel schon beschrieben hast. Die linke Stelle ist das Vorzeichen.

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 23 April 2020, 22:38:13
 ;) so hab ich es ja schon immer am laufen, aber eben nur mit dem Low register. Sicher kann ich das high nie nutzen, soviele Ampere geht ja nicht. Aber es geht einfach um die vollständikeit und richtigkeit des ganzen.

Es zählt ja von  FFFFFF rückwärts runter wenn es negativ ist. Von daher dachte ich das es eine einfachere variante gibt als dezimal 65536 abzuziehen.
Idealerweise ein invertiren der Bits (Byte).
Mal wieder was gelernt und fühle mich wie in den 80er zurück, wo ich am Z80 mit Schaltern Register gesetzt und geschoben habe :-)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 24 April 2020, 07:36:13
fühle mich wie in den 80er zurück
[OT on]
Klar, Modbus entwickelt von Modicon in den 80 Jahren. War damals als noch jeder SPS Hersteller sein eigenes serielles Protokoll via 20mA/RS232/RS485 hatte bei uns die einzige Möglichkeit Geräte verschiedener Hersteller direkt zu miteinander koppeln. Fast alle konnten neben dem eigenen Hausprotokoll auch das Fremdprotokoll Modbus :)
[OT off]
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Knallkopp_02 am 24 April 2020, 10:52:35
Bei mir hat sich herausgestellt, das es kein Mosbus ist, sondern eine ganz einfache serielle Verbindung die ich jetzt noch konfigurieren muss.

Hier mal der Link zum Post https://forum.fhem.de/index.php/topic,110470.0.html

Gruß Knallkopp_03
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 10 Mai 2020, 19:19:54
Hallo,

nach sehr langer Zeit ohne Probleme  möchte ich mein System um ein Device erweitern.

Würde hierfür aber gerne einen zweiten unabhängigen Modbus betreiben.

Ist es möglich ein zweites Modbus Device mit einem separaten USB to RS485 Adapter anzulegen?

Wenn ja, wie sieht es mit ModbusAttr aus? Hier wird ja auf kein Modbus Device verwiesen.

Lg crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Mai 2020, 16:53:03
Hallo crispyduck,

das solle kein Problem sein.
Ich habe bei mir auch mehrere Adapter für verschiedene Modbus-Geräte.
Einfach das IODev entsprechend auf das physische Modbus-Gerät setzen.

z.B.
define Waermepumpe ModbusAttr ...
define RS485MB Modbus ...
attr Waermepumpe IODev RS485MB
...

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 11 Mai 2020, 17:00:19
Hallo Stefan.

Ah, über das IODev Attribut!  :)

Super danke! Dann sollte das ja ohne Probleme Funktionieren.
Hoffentlich geht nach über einem Jahr ohne Update nach einem Update auch noch alles andere.  :P

Lg,
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 12 Mai 2020, 16:16:18
Hallo Stefan, hätte da noch eine Frage.

Da es zumindest für mich bei sehr vielen Modbus Registern mit den Attributen sehr schnell unübersichtlich wird hab ich mir vor längerer Zeit einmal ein device Modul geschrieben welches abhängig von einem zusätzlichem Parameter beim define paresinfo und deviceinfo aus einem cfg file ladet und dann erst MudbusLD_Define aufruft.
Funktioniert zwar, aber eben nur einmal da, wenn ich es richtig verstehe paresinfo und deviceinfo im modul hash $modules{$hash->{TYPE}}; steht und somit nur 1x pro modul und nicht pro device existiert.

Hab mir das heute nach 2,5 Jahren mal wieder angesehen, hab aber keinen Plan ob man das irgendwie hin bekommen könnte.

Wenn ich das richtig verstehe nutzen die ModbusLD subs den modul hash, was dann auch der Grund ist weshalb mir das letzte define immer alles überschreibt.

Hast du eine Idee ob und wie das überhaupt funktionieren könnte?

Lg,
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Mai 2020, 22:45:54
Hallo crispyduck,

Ich würde einfach die Attribute einmal per "set saveAsModule" als neues Modul speichern und dann für jedes Gerät statt ModbusAttr ModbusGerät1 etc. verwenden. Dann sind die ganzen Attribute sauber in einer Datei und können dort bei Bedarf auch ergänzt oder geändert werden.
Man kann aber auch weiterhin alle Attribute von ModbusAttr auf so ein neues Modul anwenden und spontan Dinge erweitern oder überschreiben.

Eine cig-Datei wie Du es beschrieben hast, ist doch eigentlich auch nichts anderes, nur eben ein Sonderweg.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 13 Mai 2020, 08:09:29
Hallo Stefan,

ja, so mache ich es jetzt dann auch. Idee dahinter war ein mehr oder weniger "dummes" Modul für alles zu haben und die config der unterschiedlichen device Typen dann aus einem File aus der DB zu laden.
Hab bei mir das File System der Raspi auf welcher FHEM läuft als ro konfiguriert, und speicher eigentlich alles was die Konfiguration betrifft in der DB.
Momentan, nachdem ich damals drauf gekommen bin das ich mir den Modul hash jedesmal überschreibehabe ich eben pro device Typ ein Modul welches sich dann wiederum die config aus einem file in der DB holt. Geht zwar, aber dann braucht man erst recht wieder ein Modul pro device typ.
Wie gesagt hab da jetzt zwei Jahre nichts gemacht und gestern als ich mir das dann wieder angesehen habe ist mir dann aufgefallen das es wohl daran liegt das paresinfo und deviceinfo  im Modul hash gespeichert werden.
Wenn ich das richtig sehe gibt es ohne das Basis Modbus Modul zu ändern eigentlich keine Möglichkeit das was ich möchte umzusetzen.

Bevor ich also mein Vorhaben komplett verwerfe dachte ich ich frag mal ob es vielleicht doch eine andere Möglichkeit gibt die ich einfach nicht sehe.

Lg,
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 13 Mai 2020, 16:57:17
So, da mir das keine Ruhe gelassen hat hab ich mich jetzt meinen halben Urlaubstag damit beschäftigt.  ;)

Ohne wirkliche Programmier und Perl Kenntnisse nicht so einfach.

Denke ohne wirklich was im 98_Modbus.pm Modul zu ändern ist das was ich möchte, parseInfo und devInfo per Device und nicht per Modul zu haben wohl nicht möglich.

Hab jetzt testweise in 98_Modbus.pm Modul paar kleine Änderungen gemacht.

alle
my $parseInfo = ($hash->{parseInfo} ? $hash->{parseInfo} : $modHash->{parseInfo});ersetzt mit
my $parseInfo = ($hash->{parseInfo} ? $hash->{parseInfo} : ($modHash->{$hash->{NAME}}->{parseInfo} ? $modHash->{$hash->{NAME}}->{parseInfo} : $modHash->{parseInfo}));
und alle
my $devInfo   = ($hash->{deviceInfo} ? $hash->{deviceInfo} : $modHash->{deviceInfo});   
ersetzt mit
my $devInfo   = ($hash->{deviceInfo} ? $hash->{deviceInfo} : ($modHash->{$hash->{NAME}}->{deviceInfo} ? $modHash->{$hash->{NAME}}->{deviceInfo} : $modHash->{deviceInfo}));

Damit wäre es möglich parseInfo und deviceInfo in "modul-hash->{device-name}" zu speichern.
Sollte es "modul-hash->{device-name}->{parseInfo}" geben, so wird dies verwendet, sonst wie gehabt "modul-hash->{parseInfo}"

Spricht irgend was dagegen das so zu machen? Damit wäre es möglich statt nur pro Modul auch per Device parseInfo und deviceInfo festzulegen.

Hoffe mal ich hab hier nichts wesentliches vergessen.

Lg, crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Mai 2020, 19:35:22
Hallo crispyduck,

das muss ich mir mal in Ruhe ansehen.
Ich packs auf die Wunschliste :-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Mai 2020, 19:53:50
Korrektur: das war schon auf der Wunschliste und ist in meiner Arbeitskopie auch schon drin.
Ich habe da allerdings auch einige andere Sachen umgestellt und noch nicht ganz zu Ende gebracht. Insbesondere wenn das Modul als Relay verwendet wird. In letzter Zeit habe ich mich mehr um die neue Version von ArduCounter gekümmert. deshalb hat sich beim Modbus-Modul weniger getan. 
Du kannst meine aktuelle Version aber gerne mal testen.
Bei mir hat sie in den letzten Monaten keine Probleme verursacht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: crispyduck am 19 Mai 2020, 16:06:43
Super, Danke! Werde ich testen.

Frage noch dazu, wo/wie muss hier parseInfo und devInfo im device hash stehen? Blick mich nicht ganz durch wo hier der device hash genommen wird.

Lg,
crispyduck
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 Mai 2020, 16:54:29
Hallo,

ein logisches Modul auf Basis von Modbus (wie zum Beispiel ModbusAttr oder ModbusSET) kann $hash->{parseInfo} setzen.
Zum Zugriff auf Objektinformationen (Länge, unpack etc.) wird intern meist die Funktion Modbus_ObjInfo aufgerufen.
################################################
# Get Object Info from Attributes,
# parseInfo Hash or default from deviceInfo Hash
sub Modbus_ObjInfo($$$;$$) {
    my ($hash, $key, $oName, $defName, $lastDefault) = @_;
    #   Device  h123  unpack  defUnpack
    $hash = $hash->{CHILDOF} if ($hash->{CHILDOF});                     # take info from parent device if TCP server conn (TCP slave)
    my $name      = $hash->{NAME};
    my $modHash   = $modules{$hash->{TYPE}};
    my $parseInfo = ($hash->{parseInfo} ? $hash->{parseInfo} : $modHash->{parseInfo});

falls $hash->{parseInfo} existiert, wird diese Struktur (aus dem Hash des logischen Geräts) verwendet. Falls nicht, dann die aus dem Modulhash.
In jedem Fall aber haben Attribute nochmal Vorrang vor dem parseInfo Hash.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: stolus am 22 Mai 2020, 22:13:41
Guten Abend,
läst sich die Relay Funktion auch zwischen zwei FHEM Instanzen nutzen?
In meinem Anwendungsfall ist eine Wärmepumpe über RS485 mit einem RaspberryZero verbunden.
Das funktioniert dank Hilfe von Hollo ganz gut. ;D
Jetzt würde ich gerne auf meinem Haupt FHEM Server auf dem Dachboden, als Masterdevice die Wärmepumpe steuern.
Ich habe das relay und den Master gerade zusätzlich angelegt, leider kommt nur disconnected.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Mai 2020, 23:56:22
Hallo Stolus,

Ja, wenn eine erste Fhem-Instanz an der Wärmepumpe als Relay konfiguriert ist, und per Modbus als Master mit der Wärmepumpe als Slave reden kann, dann kann eine zweite Fhem-Instanz als Master mit der ersten Instanz als Slave reden und so auf die Wärmepumpe durchgreifen.

Poste doch mal Deine Konfiguration.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: stolus am 23 Mai 2020, 09:13:05
Hi Stefan,
vielen Dank für die Hilfe, hier meine Konfig: FHEM auf dem RaspberryZero hat die IP 192.168.1.33 und der FHEM Hauptserver die IP 192.168.1.35

Hier Die Konfig auf dem RaspberryZero:
1. Device ModbusRS485 Verbindung zur Wärmepumpe:

Internals:
   DEF        /dev/ttyS0@19200,8,E,1
   DeviceName /dev/ttyS0@19200,8,E,1
   EXPECT     idle
   FD         4
   FUUID      5eaec0a2-f33f-c83a-c2b3-f7cdf3852cd5fa82
   LASTOPEN   1590172778.53833
   MODE       master
   NAME       ModbusRS485
   NR         32
   NTFY_ORDER 50-ModbusRS485
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2020-05-22 20:39:38   state           opened
   REMEMBER:
     lid        2
     lname      DHW300
     lrecv      1590216923.12295
     lsend      1590216923.09544
   defptr:
     DHW300     2
Attributes:
   room       Heizungsraum

2. Modbus Modul DHW300 zum Auslesen der Wärmepumpe Dimplex DHW300

Internals:
   CHANGED   
   DEF        2 60
   FUUID      5eb3e9b3-f33f-c83a-4c4d-0a1b18afa2d7fbd7
   INTERVAL   60
   IODev      ModbusRS485
   MODBUSID   2
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DHW300
   NOTIFYDEV  global
   NR         33
   NTFY_ORDER 50-DHW300
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1590217390.11278
   TRIGGERTIME_FMT 2020-05-23 09:03:10
   TYPE       ModbusDHW300
   lastUpdate 1590217330.11278
   FRAME:
   READ:
   READINGS:
     2020-05-23 09:02:11   Abtaufuehler_C  25
     2020-05-23 09:02:20   Betriebsart     Idle
     2020-05-23 09:02:12   Elektroheizung  AUS
     2020-05-23 09:01:12   Kollektrortemperatur_C 209
     2020-05-23 09:02:13   Laufzeit_Elektroheizung_h 70
     2020-05-23 09:02:18   Laufzeit_Geraet_h 1782
     2020-05-23 09:01:13   Laufzeit_Ventilator_h 237
     2020-05-23 09:02:26   Laufzeit_Verdichter_h 221
     2020-05-23 09:01:11   Leistung_W      0
     2020-05-23 09:02:28   Lufteintritt_C  20
     2020-05-23 09:02:15   Meldungen       Fuehlerfehler_R13
     2020-05-23 09:02:10   Solar-/Ladepumpe AUS
     2020-05-23 09:02:19   Sollwert_aktuell_C 15
     2020-05-23 09:02:14   Speichertemperatur_oben_C 46
     2020-05-23 09:02:23   Speichertemperatur_unten_C 46
     2020-05-23 09:02:27   Ventilator      AUS
     2020-05-23 09:01:10   Verdichter      AUS
     2020-05-23 09:02:17   WW_Absenktemperatur_C 15
     2020-05-23 09:02:29   WW_Boost_Dauer_h 4
     2020-05-23 09:02:22   WW_Boost_Solltemp_C 65
     2020-05-23 09:02:24   WW_Hysterese_K  5
     2020-05-23 09:02:25   WW_Modus        ECO
     2020-05-23 09:02:16   WW_Solltemperatur_C 55
     2020-05-23 09:02:21   WW_Verzoegerung_h 12
     2020-05-22 20:39:38   state           opened
   REMEMBER:
     lrecv      1590217349.98522
     lsend      1590217349.95613
   gotReadings:
     WW_Boost_Dauer_h 4
   lastRead:
     h14        1590217336.49537
     h15        1590217337.53371
     h16        1590217344.80143
     h17        1590217345.8406
     h18        1590217341.68684
     h19        1590217349.9927
     h20        1590217342.72483
     i10        1590217348.95442
     i11        1590217272.51521
     i12        1590217339.60988
     i13        1590217331.3041
     i14        1590217347.91674
     i15        1590217270.4393
     i16        1590217332.34306
     i17        1590217330.26112
     i18        1590217271.47673
     i19        1590217340.64979
     i20        1590217335.45801
     i21        1590217338.57179
     i22        1590217273.55346
     i23        1590217346.87779
     i24        1590217333.38071
     i8         1590217334.4187
     i9         1590217343.75937
Attributes:
   event-on-change-reading .*
   room       Heizungsraum

3. Modbus Relay DHW300RELAY zum weiterleiten der Anfrage aus dem FHEM Hauptserver
Internals:
   CFGFN     
   DEF        3 relay 192.168.1.35:502 TCP to DHW300
   DeviceName 192.168.1.35:502
   EXPECT     request
   FUUID      5ec82669-f33f-c83a-7f42-ef064944d7189bc8
   IODev      DHW300RELAY
   MODBUSID   3
   MODE       relay
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DHW300RELAY
   NOTIFYDEV  global
   NR         63
   NTFY_ORDER 50-DHW300RELAY
   PROTOCOL   TCP
   RELAY      DHW300
   RELID      2
   SERVERSOCKET
   STATE      Initialized
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   READ:
     BUFFER     
   READINGS:
     2020-05-22 22:02:34   state           Initialized
   defptr:
     DHW300RELAY 3
Attributes:
   room       Heizungsraum

Hier die Konfig auf dem FHEM Hauptserver:
1. Modbus Modul DHW300MASTER

Internals:
   DEF        4 60 192.168.1.33:502 TCP
   DeviceName 192.168.1.33:502
   EXPECT     idle
   FUUID      5ec82930-f33f-8703-0938-336013e718f2d6e8
   INTERVAL   60
   IODev      DHW300MASTER
   LASTOPEN   1590217817.93141
   MODBUSID   4
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DHW300MASTER
   NEXT_OPEN  1590217851.85001
   NOTIFYDEV  global
   NR         362
   NTFY_ORDER 50-DHW300MASTER
   PARTIAL   
   PROTOCOL   TCP
   STATE      disconnected
   TCPConn    1
   TRIGGERTIME 1590217837.78341
   TRIGGERTIME_FMT 2020-05-23 09:10:37
   TYPE       ModbusDHW300
   devioLoglevel 3
   lastUpdate 1590217777.78341
   nextOpenDelay 60
   FRAME:
   QUEUE:
     HASH(0xa374e20)
     HASH(0xa076558)
     HASH(0xa2fd818)
     HASH(0xa2d05c8)
     HASH(0x9fc7b08)
     HASH(0xa2e58a8)
     HASH(0xa31e248)
     HASH(0xa0ac6f0)
     HASH(0xa2f34c8)
     HASH(0x9fc2d08)
     HASH(0xa2cb220)
     HASH(0x9fac470)
     HASH(0xa303440)
     HASH(0xa2ee2c0)
     HASH(0xa0a3158)
     HASH(0xa2bc340)
     HASH(0xa096598)
     HASH(0xa2c7e90)
     HASH(0xa315290)
     HASH(0xa2c7b00)
     HASH(0x9751550)
     HASH(0xa2f1670)
     HASH(0x9f93fc8)
     HASH(0xa314c30)
   READ:
     BUFFER     
   READINGS:
     2020-05-23 09:09:51   state           disconnected
   defptr:
     DHW300MASTER 4
   lastRead:
Attributes:
   DbLogExclude .*
   room       Heizungsraum

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: stolus am 23 Mai 2020, 09:30:37
Ich habe es alternativ auch mit dem Modbusattr auf dem RaspberryZero probiert

1. Modbus Master DHW300 mit Modbusattr

Internals:
   CFGFN     
   DEF        2 60
   FUUID      5ec8cf90-f33f-c83a-bd15-41403676820e59d7
   INTERVAL   60
   IODev      ModbusRS485
   MODBUSID   2
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DHW300
   NOTIFYDEV  global
   NR         136
   NTFY_ORDER 50-DHW300
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1590218942.69795
   TRIGGERTIME_FMT 2020-05-23 09:29:02
   TYPE       ModbusAttr
   lastUpdate 1590218882.69795
   READINGS:
     2020-05-23 09:24:00   state           opened
Attributes:
   room       Heizungsraum

Leider auch keine Verbindung
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Mai 2020, 14:10:43
Hallo Stolus,

mir fallen zwei Dinge auf:
Bei der Definition des Relays musst Du eine lokale IP-Adresse und einen lokalen TCP-Port angeben, auf dem das Relay auf eingehende Verbindungen wartet. Du hast aber die Adresse des Haupt-Fhem-Servers beim Relay angegeben. Das kann nicht funktionieren.

Als Port für das Relay hast Du 502 angegeben. Wenn Fhem aber nicht als root läuft oder anderweitig dafür gesorgt wird, kann es diesen Port nicht öffnen. Ich würde eher 1502 nehmen.

Ich muss das wohl in der Doku etwas deutlicher beschreiben.

Am besten nimmst Du auch die neue Version, die ich hier vor ein paar Tagen gepostet habe. Gerade beim Betrieb als Relay sollte die besser funktionieren, muss aber noch getestet werden ;-)

Gruß
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: stolus am 24 Mai 2020, 17:09:59
Hallo Stefan,
danke für den Tip, ich habe die Def jetzt angepasst
RaspberryZero:
defmod DHW300RELAY ModbusAttr 3 relay 192.168.1.33:1502 TCP to DHW300FHEM Hauptserver:
defmod DHW300MASTER ModbusDHW300 4 60 192.168.1.33:1502Jetzt kommt beim Hautpserver ein opened.

Leider bekomme ich beim auslesen der Register nur Fehlermeldung (Timeout).
Hier ein paar Beispiele:
2020.05.24 17:04:16 3: DHW300MASTER: ResponseTimeout called, master was DHW300MASTER
2020.05.24 17:04:16 3: DHW300MASTER: Timeout waiting for a modbus response, read buffer empty, request: id 4, fCode 3, type h, adr 19, len 1, master device DHW300MASTER, reading WW_Boost_Dauer_h (getUpdate), queued 12.00 secs ago, sent 3.00 secs ago
2020.05.24 17:04:19 3: DHW300MASTER: ResponseTimeout called, master was DHW300MASTER
2020.05.24 17:04:19 3: DHW300MASTER: Timeout waiting for a modbus response, read buffer empty, request: id 4, fCode 4, type i, adr 14, len 1, master device DHW300MASTER, reading Ventilator (getUpdate), queued 15.01 secs ago, sent 3.00 secs ago
2020.05.24 17:04:22 3: DHW300MASTER: ResponseTimeout called, master was DHW300MASTER
2020.05.24 17:04:22 3: DHW300MASTER: Timeout waiting for a modbus response, read buffer empty, request: id 4, fCode 4, type i, adr 17, len 1, master device DHW300MASTER, reading Solar-/Ladepumpe (getUpdate), queued 18.01 secs ago, sent 3.00 secs ago
2020.05.24 17:04:25 3: DHW300MASTER: ResponseTimeout called, master was DHW300MASTER
2020.05.24 17:04:25 3: DHW300MASTER: Timeout waiting for a modbus response, read buffer empty, request: id 4, fCode 4, type i, adr 10, len 1, master device DHW300MASTER, reading Lufteintritt_C (getUpdate), queued 21.01 secs ago, sent 3.00 secs ago

Das Modul habe ich auf beiden Instanzen gegen das aktuelle von Dir getauscht.


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 Mai 2020, 21:09:51
Hallo stolus,

Dein Relay hört auf Modbus ID 3, Dein Master versucht aber Modbus ID 4 abzufragen.
Stell mal den DHW300Master so ein, dass er die ID des Relays abfragt, also 3.

Wenn es dann noch nicht klappt, wäre ein Auszug aus den Logs hilfreich, wobei sowohl für ModbusRS485, DHW300, DHW300RELAY als auch DHW300Master das verbose-Attribut auf 5 stehen sollte.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: stolus am 29 Mai 2020, 09:55:42
Hi Stefan,
alleine komme ich da anscheinend nicht weiter. >:(

FHEM DHW300MASTER jetzt auf ID 3

Internals:
   DEF        3 60 192.168.1.33:1502
   DeviceName 192.168.1.33:1502
   EXPECT     idle
   FD         5
   FUUID      5ec82930-f33f-8703-0938-336013e718f2d6e8
   INTERVAL   60
   IODev      DHW300MASTER
   LASTOPEN   1590736838.56948
   MODBUSID   3
   MODE       master
   MODULEVERSION Modbus 4.1.8 - 12.11.2019
   NAME       DHW300MASTER
   NOTIFYDEV  global
   NR         362
   NTFY_ORDER 50-DHW300MASTER
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   TCPConn    1
   TIMEOUTS   221
   TRIGGERTIME 1590738766.13994
   TRIGGERTIME_FMT 2020-05-29 09:52:46
   TYPE       ModbusDHW300
   devioLoglevel 3
   lastUpdate 1590738706.13994
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2020-05-29 09:20:39   state           opened
   REMEMBER:
     lid        3
     lname      DHW300MASTER
     lsend      1590738724.15785
   defptr:
     DHW300MASTER 3
   lastRead:
Attributes:
   DbLogExclude .*
   room       Heizungsraum
   verbose    5

Hier ein Auszug der Logfiles:
FHEM Server:
https://pastebin.com/RXbCjZu8 (https://pastebin.com/RXbCjZu8)

FHEM Raspberry Zero
https://pastebin.com/QrVL6jfd (https://pastebin.com/QrVL6jfd)

98_ModbusDHW300
https://pastebin.com/MyjaiNmh (https://pastebin.com/MyjaiNmh)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Mai 2020, 20:44:12
Hallo stolus,

kein Problem, das bekommender schon noch hin :-)
Aktuell scheitert es daran, dass Du bei DHW300MASTER im Define das Schlüsselwort TCP vergessen hast.
Dann verwendet der das Protokoll Modbus-RTU über TCP und nicht Modbus-TCP.
Beim Relay hattest Du aber TCP angegeben, so dass das Relay eben Modbus-TCP erwartet.
Modbus-RTU über TCP und Modbus-TCP verwenden unterschiedliche Frame-Formate.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: stolus am 29 Mai 2020, 22:01:32
Hi Stefan,
TCP habe ich ergänzt.
Leider noch immer kein Erfolg.
Hier mal die Logs der letzten Minuten

FHEM RaspberryZero
https://pastebin.com/xSwwAbyK (https://pastebin.com/xSwwAbyK)

FHEM Server
https://pastebin.com/0Rh6HcSp (https://pastebin.com/0Rh6HcSp)

Internals:
   DEF        3 60 192.168.1.33:1502 TCP
   DeviceName 192.168.1.33:1502
   EXPECT     idle
   FD         42
   FUUID      5ec82930-f33f-8703-0938-336013e718f2d6e8
   INTERVAL   60
   IODev      DHW300MASTER
   LASTOPEN   1590780191.00167
   MODBUSID   3
   MODE       master
   MODULEVERSION Modbus 4.1.8 - 12.11.2019
   NAME       DHW300MASTER
   NOTIFYDEV  global
   NR         362
   NTFY_ORDER 50-DHW300MASTER
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TIMEOUTS   21
   TRIGGERTIME 1590782442.32565
   TRIGGERTIME_FMT 2020-05-29 22:00:42
   TRIGGERTIME_SAVED
   TYPE       ModbusDHW300
   devioLoglevel 3
   lastUpdate 1590782382.32565
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2020-05-29 21:23:11   state           opened
   REMEMBER:
     lid        3
     lname      DHW300MASTER
     lrecv      1590782221.44373
     lsend      1590782400.34241
   defptr:
     DHW300MASTER 3
   lastRead:
Attributes:
   DbLogExclude .*
   room       Heizungsraum
   verbose    5

Es kommen immer noch timeouts.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 Mai 2020, 11:06:32
Hallo stolus,

Die Requests vom Master kommen jetzt korrekt beim Relay an, werden zum Slave weitergeleitet und die Antwort wird auch vom Relay wieder empfangen. Dann schlägt aber scheinbar ein Bug im Relay zu und das Relay hat vergessen, an wen die Antwort weiter geleitet werden soll. Dass muss ich mir genauer ansehen. Es kann sein, dass der Bug nur in der aktuellen Entwicklungsversion steckt oder dass er schon immer da war und aus irgendwelchen Gründen bisher nicht aufgefallen ist.
Ich melde mich sobald ich ein Update habe.

Gruß
  Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 Mai 2020, 22:08:53
Hallo,

Anbei ein neuer Zwischenstand des Modbus-Moduls, bei dem der Fehler im Relay-Modus der letzen Version behoben sein sollte.
   
Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: sukram am 31 Mai 2020, 14:39:11
Hallo alle beisammen,

ich hätte da gern mal ein Problem ::)

Ist Zustand:
FHEM auf Ubuntu Server
DIY Modbus TCP-RTU Gateway (ethersex auf mod. AVR-Net-IO)
3x Saia ALE3 Modbus Stromzähler
Eine Instanz ModbusAttr für einen Zähler funktioniert problemlos, alle 30sek neue Daten (10 von 52 Registern)

Soll Zustand:
mind. 3-10 Instanzen ModbusAttr für Stromzähler, Thermostate, Aktoren.

Problem:
konkurrierender TCP Zugriff auf das Gateway schlägt fehl. Die erste Instanz bekommt kurz Zugriff, danach gehen alle Instanzen auf Timeout. Dabei wird von einer anderen Instanz der Fehler gemeldet, dass unaufgefordete Daten eingegangen sind. Anscheinend gibt es Probleme bei der Koordination der Datenströme.

Logauszug:
2020.05.30 15:07:14 3: nioZaehler1: read got new data while idle, drop buffer 000a00000007040304000652dc
2020.05.30 15:07:16 3: nioZaehler3: Timeout waiting for a modbus response request: id 4, fCode 3, tid 10, type h, adr 27, len 2 for device nioZaehler3 reading Total1 (getUpdate), queued 2.37 secs ago, sent 2.37 secs ago, read buffer empty
"nioZaehlerx" ist der Name der jeweiligen ModbusAttr Instanz.

Raw definition der Instanz:
define nioZaehler1 ModbusAttr 2 30 10.102.1.240 TCP
attr nioZaehler1 dev-h-combine 20
attr nioZaehler1 dev-type-dint-expr $val/100
attr nioZaehler1 dev-type-dint-len 2
attr nioZaehler1 dev-type-dint-revRegs 0
attr nioZaehler1 dev-type-dint-unpack N
attr nioZaehler1 obj-h0-reading Firmwareversion
attr nioZaehler1 obj-h1-reading Registercount
attr nioZaehler1 obj-h14-reading Hardwareversion
attr nioZaehler1 obj-h15-reading Serialnumber
attr nioZaehler1 obj-h15-type dint
attr nioZaehler1 obj-h2-reading Flagcount
attr nioZaehler1 obj-h21-reading Status
attr nioZaehler1 obj-h22-reading Modbustimeout
attr nioZaehler1 obj-h23-reading ModbusAddress
attr nioZaehler1 obj-h24-reading Error
attr nioZaehler1 obj-h26-reading Tarif
attr nioZaehler1 obj-h27-poll 1
attr nioZaehler1 obj-h27-reading Total1
attr nioZaehler1 obj-h27-type dint
attr nioZaehler1 obj-h29-poll 1
attr nioZaehler1 obj-h29-reading Subtotal1
attr nioZaehler1 obj-h29-type dint
attr nioZaehler1 obj-h3-reading Baudrate
attr nioZaehler1 obj-h3-type dint
attr nioZaehler1 obj-h31-reading Total2
attr nioZaehler1 obj-h31-type dint
attr nioZaehler1 obj-h33-reading Subtotal2
attr nioZaehler1 obj-h33-type dint
attr nioZaehler1 obj-h35-poll 1
attr nioZaehler1 obj-h35-reading Urms_L1
attr nioZaehler1 obj-h36-expr $val/10
attr nioZaehler1 obj-h36-poll 1
attr nioZaehler1 obj-h36-reading Irms_L1
attr nioZaehler1 obj-h37-expr $val/100
attr nioZaehler1 obj-h37-poll 1
attr nioZaehler1 obj-h37-reading Prms_L1
attr nioZaehler1 obj-h38-expr $val/100
attr nioZaehler1 obj-h38-poll 1
attr nioZaehler1 obj-h38-reading Qrms_L1
attr nioZaehler1 obj-h39-expr $val/100
attr nioZaehler1 obj-h39-poll 1
attr nioZaehler1 obj-h39-reading CosPhi_L1
attr nioZaehler1 obj-h40-poll 0
attr nioZaehler1 obj-h40-reading Urms_L2
attr nioZaehler1 obj-h41-expr $val/10
attr nioZaehler1 obj-h41-poll 0
attr nioZaehler1 obj-h41-reading Irms_L2
attr nioZaehler1 obj-h42-expr $val/100
attr nioZaehler1 obj-h42-poll 0
attr nioZaehler1 obj-h42-reading Prms_L2
attr nioZaehler1 obj-h43-expr $val/100
attr nioZaehler1 obj-h43-poll 0
attr nioZaehler1 obj-h43-reading Qrms_L2
attr nioZaehler1 obj-h44-expr $val/100
attr nioZaehler1 obj-h44-poll 0
attr nioZaehler1 obj-h44-reading CosPhi_L2
attr nioZaehler1 obj-h45-poll 0
attr nioZaehler1 obj-h45-reading Urms_L3
attr nioZaehler1 obj-h46-expr $val/10
attr nioZaehler1 obj-h46-poll 0
attr nioZaehler1 obj-h46-reading Irms_L3
attr nioZaehler1 obj-h47-expr $val/100
attr nioZaehler1 obj-h47-poll 0
attr nioZaehler1 obj-h47-reading Prms_L3
attr nioZaehler1 obj-h48-expr $val/100
attr nioZaehler1 obj-h48-poll 0
attr nioZaehler1 obj-h48-reading Qrms_L3
attr nioZaehler1 obj-h49-expr $val/100
attr nioZaehler1 obj-h49-poll 0
attr nioZaehler1 obj-h49-reading CosPhi_L3
attr nioZaehler1 obj-h50-expr $val/100
attr nioZaehler1 obj-h50-poll 1
attr nioZaehler1 obj-h50-reading Prms_total
attr nioZaehler1 obj-h51-expr $val
attr nioZaehler1 obj-h51-poll 1
attr nioZaehler1 obj-h51-reading Qrms_total
attr nioZaehler1 obj-h6-len 8
attr nioZaehler1 obj-h6-reading Type
attr nioZaehler1 obj-h6-unpack a*
attr nioZaehler1 stateFormat Summe: Total1 kWh Aktuell: Prms_total W Qrms_total VA<br />L1 Urms_L1 V Irms_L1 A Prms_L1 W Qrms_L1 VA Cos Phi CosPhi_L1

Wie gesagt, eine Instanz läuft ganz brav, mehrere schlagen sich. Ein alternativer Ansatz ist jetzt am Start, dabei habe ich einen ModbusTCPServer definiert, der auf das NetIO Gateway zeigt, und dann muss ich jedes Register einzeln anlegen. Nicht so schön, aber funktioniert stabil:

define netiomb ModbusTCPServer 10.102.1.240
attr netiomb combineReads 10:20
attr netiomb pollInterval 30
attr netiomb queueDelay 20

define Zaehler02PRMS ModbusRegister 2 50
attr Zaehler02PRMS IODev netiomb

define Zaehler04PRMS ModbusRegister 4 50
attr Zaehler04PRMS IODev netiomb

define Zaehler02Stand ModbusRegister 2 27
attr Zaehler02Stand IODev netiomb
attr Zaehler02Stand plcDataType DINT_BE

define Zaehler04Stand ModbusRegister 4 27
attr Zaehler04Stand IODev netiomb
attr Zaehler04Stand plcDataType DINT_BE

Da jetzt am Relay Teil wegen der Adresszuordnung gebaut wurde, kann das hier auch zum Erfolg führen?

Danke schon mal!

MfG sukram

PS: gibt es irgendwo eine Sammlung von Registerdefinitionen für verschiedene Geräte?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 31 Mai 2020, 15:46:24
Hallo Sukram,

Auf den ersten Blick sieht es so aus, als ob Dein Gateway nicht in der Lage wäre mehrere TCP-Verbindungen zu bedienen bzw. Replies korrekt einem Request und dessen TCP-Verbindung zuzuordnen. Es scheint so als ob Das Gateway die Modbus-Replies einfach an die zuletzt geöffnete TCP-Verbindung schickt, unabhängig davon, ob darüber auch der Request reinkam.
Genau kann ich das aber erst sagen, wenn Du Logs mit Verbose 5 postest.

Die einfachste Lösung wäre vermutlich das Gateway durch ein Relay auf einem Pi/Pi-Zero und Fhem-Basis auszutauschen. Dann kümmert sich das Relay darum.

Poste doch mal ein ausführliches Log mit Verbose 5, dann sehen wir, was genau passiert und welche Optionen es gibt.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: stolus am 31 Mai 2020, 15:50:02
Hallo Stefan,
ich habe gerade Deinen aktuellen Stand des Moduls eingepflegt.
Läuft jetzt wie erwartet.
Vielen Dank für Deine Hilfe und super schnelle Reaktion !! ;D
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: sukram am 31 Mai 2020, 17:01:00
Hallo Sukram,

Auf den ersten Blick sieht es so aus, als ob Dein Gateway nicht in der Lage wäre mehrere TCP-Verbindungen zu bedienen bzw. Replies korrekt einem Request und dessen TCP-Verbindung zuzuordnen. Es scheint so als ob Das Gateway die Modbus-Replies einfach an die zuletzt geöffnete TCP-Verbindung schickt, unabhängig davon, ob darüber auch der Request reinkam.
Genau kann ich das aber erst sagen, wenn Du Logs mit Verbose 5 postest.

Mit der 1x TCP Verbindung bin ich mir ziemlich sicher, dass dem so ist. So leistungsfähig ist die Kombination ATMega und Ethersex nicht.

Zitat
Die einfachste Lösung wäre vermutlich das Gateway durch ein Relay auf einem Pi/Pi-Zero und Fhem-Basis auszutauschen. Dann kümmert sich das Relay darum.

Poste doch mal ein ausführliches Log mit Verbose 5, dann sehen wir, was genau passiert und welche Optionen es gibt.

Gruß
    Stefan

Den Stromverbrauch/Pflegeaufwand eines Raspi wollte ich mir gerne sparen. Deshalb die Lightversion mit AVR. Ausserdem passt das auch in ein kleines Hutschienengehäuse.

Ich liefere gern noch Logdaten, das dauert aber bis morgen. Was mir vorschweben würde, dass die Daten wie bei dem Modbusmodul für lokale Schnittstellen zusammengefasst wird, bevor es auf die Reise geht. Ich hätte ansonsten noch mit Kommandozeilentricks wie netcat, socat und co probiert...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: sukram am 01 Juni 2020, 23:48:06
Hallo nochmal, ich habe hier ein kurzes Logfile, mit 2 aktiven ModbusAttr Instanzen - nioZaehler1 und nioZaehler3 - im verbose 5. Die Definitionen dazu stehen ein paar Post weiter oben.

Das Gateway kann definitiv nur 1 TCP Stream gleichzeitig bearbeiten. Gibt es eine Möglichkeit, dass die ModbusAttr Instanz sofort die TCP Verbindung wieder schließt oder statt direkt eine Verbindung aufzubauen an eine ModbusTCPServer Instanz bindet?

Ich möchte verschiedene einfache Geräte wie z.B. Relais-I/O-Module, kleine Feldbuskoppler und eben komplexe Geräte wie diese Zähler an einem Bus bündeln, und das auch ohne Kopfstände in FHEM einbinden. Gibt es eine Variante, die nicht auf externe Rechenleistung im Interface/Gateway angewiesen ist?

MfG sukraM
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Juni 2020, 17:27:15
Hallo sukram,

Probier doch mal die angehängte neue Version. Da gibt es ein neues Attribut mit Namen closeAfterResponse. Wenn das auf 1 steht, dann wird die TCP-Verbindung nach Erhalt der Response geschlossen und erst bei Bedarf wieder geöffnet.
Das muss allerdings noch getestet werden.

Du musst auch selbst dafür sorgen, dass verschiedene ModbusAttr-Instanzen sich nicht in die Quere kommen. Dazu musst Du die Update-Timer passend und nicht zu kurz setzen und am besten zusätzlich mit alignTime arbeiten.

Das Grundproblem bleibt dass Dein Relay nicht mehrere TCP-Verbindungen und keine überlappenden Anfragen bekommen darf. Mit einem Relay auf einem Pi-Zero mit Fhem wäre das sauber zu lösen und ich denke nicht dass der Strombedarf dadurch signifikant steigt.

Alternativ kann ich mal versuchen, das Modbus-Modul so zu erweitern, dass man auch ein Modbus-TCP-Device als IODev für andere Modbus-TCP-Devices eintragen kann, dann könnte Fhem auch als Master über TCP dafür sorgen, dass die Requests immer nur über eine Verbindung und sequentiell kommen.
Das könnte aber ein paar Tage dauern.

Gruß
    Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 06 Juni 2020, 14:51:23
Frage zum setzen von Registern, da es bei mir nicht so funktioniert wie es soll:

Setzen von Coil klappt. Bei den Holding leider nicht so richtig, ich will das h36870 von 1440 (14,40V) auf 1441 z.b. setzen, evtl. ein Thema mit pack ?

2020.06.06 13:32:45 5: Solarlader: set called with EqualizingVoltage (h36870) setVal = 1441
2020.06.06 13:32:45 5: Solarlader: GetSetChecks with force
2020.06.06 13:32:45 5: Solarlader: GetSetChecks returns success
2020.06.06 13:32:45 5: Solarlader: set packed hex 31343431 with n to hex 05a1
2020.06.06 13:32:45 4: Solarlader: DoRequest called from Set created request: id 1, fCode 16, type h, adr 36870, len 1, value 05a1 for device Solarlader reading EqualizingVoltage (set EqualizingVoltage), read buffer empty
2020.06.06 13:32:45 5: Solarlader: QueueRequest called from DoRequest (Solarlader) with h36870, qlen 0
2020.06.06 13:32:45 4: Solarlader: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 1 (Solarlader), last send to this device was 4.704 secs ago, last read 4.611 secs ago, last read on bus 4.611 secs ago from id 1 (Solarlader)
2020.06.06 13:32:45 5: Solarlader: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 13:32:41.064) for Solarlader, delay 4.511secs over
2020.06.06 13:32:45 5: Solarlader: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 13:32:40.971) for Solarlader, delay 4.605secs over
2020.06.06 13:32:45 4: Solarlader: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 0110900600010205a1f4d7 request: id 1, fCode 16, type h, adr 36870, len 1, value 05a1 for device Solarlader reading EqualizingVoltage (set EqualizingVoltage), queued 0.00 secs ago, read buffer empty
2020.06.06 13:32:45 5: Solarlader: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2020.06.06 13:32:45 5: Solarlader: ReadAnswer called from Set
2020.06.06 13:32:45 5: Solarlader: ReadAnswer called and remaining timeout is 1.99727821350098
2020.06.06 13:32:45 5: Solarlader: ReadAnswer got: 0190044dc3
2020.06.06 13:32:45 4: Solarlader: ParseFrameStart (RTU) extracted id 1, fCode 144 and data 04
2020.06.06 13:32:45 5: Solarlader: HandleResponse called from ReadAnswer
2020.06.06 13:32:45 5: Solarlader: ParseResponse called from HandleResponse
2020.06.06 13:32:45 5: Solarlader: CheckChecksum (called from HandleResponse): 4dc3 is valid
2020.06.06 13:32:45 4: Solarlader: HandleResponse got response with error code 90 / 04, slave device failure
2020.06.06 13:32:45 4: Solarlader: ResponseDone request: id 1, fCode 16, type h, adr 36870, len 1, value 05a1 for device Solarlader reading EqualizingVoltage (set EqualizingVoltage), queued 0.08 secs ago, sent 0.08 secs ago, Current read buffer: 0190044dc3, Id 1, fCode 144, response: id 1, fCode 144, adr 36870, len 1
2020.06.06 13:32:45 5: Solarlader: DropFrame - drop 0190044dc3
2020.06.06 13:32:45 5: Solarlader: ReadAnswer got Error code 04 / slave device failure
2020.06.06 13:32:56 5: Solarlader: attr change set updateGetSetList to 1


Beim setzen des Holding Registers von der Batteriekapazität die ich z.b. von 80 auf 81 ändere geht es und das Log sieht so aus:

2020.06.06 14:37:14 5: Solarlader: set called with BattCapacityDefault (h36865) setVal = 81
2020.06.06 14:37:14 5: Solarlader: GetSetChecks with force
2020.06.06 14:37:14 5: Solarlader: GetSetChecks returns success
2020.06.06 14:37:14 5: Solarlader: set packed hex 3831 with n to hex 0051
2020.06.06 14:37:14 4: Solarlader: DoRequest called from Set created request: id 1, fCode 16, type h, adr 36865, len 1, value 0051 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault), read buffer empty
2020.06.06 14:37:14 5: Solarlader: QueueRequest called from DoRequest (Solarlader) with h36865, qlen 8
2020.06.06 14:37:14 4: Solarlader: ProcessRequestQueue called from QueueRequest, force, qlen 9, next entry to id 1 (Solarlader), last send to this device was 0.163 secs ago, last read 0.075 secs ago, last read on bus 0.075 secs ago from id 1 (Solarlader)
2020.06.06 14:37:14 4: Solarlader: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 14:37:14.314) for Solarlader, rest 0.025, sleep forced
2020.06.06 14:37:14 5: Solarlader: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 14:37:14.227) for Solarlader, delay 0.063secs over
2020.06.06 14:37:14 4: Solarlader: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 9, sending 011090010001020051f674 request: id 1, fCode 16, type h, adr 36865, len 1, value 0051 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault), queued 0.00 secs ago, read buffer empty
2020.06.06 14:37:14 5: SW: 011090010001020051f674
2020.06.06 14:37:14 5: Solarlader: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.06.06 14:37:14 5: Solarlader: ReadAnswer called from Set
2020.06.06 14:37:14 5: Solarlader: ReadAnswer called and remaining timeout is 1.99591517448425
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got: 0110900100017d
2020.06.06 14:37:14 4: Solarlader: ParseFrameStart (RTU) extracted id 1, fCode 16 and data 900100
2020.06.06 14:37:14 5: Solarlader: HandleResponse called from ReadAnswer
2020.06.06 14:37:14 5: Solarlader: ParseResponse called from HandleResponse
2020.06.06 14:37:14 5: Solarlader: HandleResponse did not get a valid frame yet, wait for more data
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got: 0110900100017d09
2020.06.06 14:37:14 4: Solarlader: ParseFrameStart (RTU) extracted id 1, fCode 16 and data 90010001
2020.06.06 14:37:14 5: Solarlader: HandleResponse called from ReadAnswer
2020.06.06 14:37:14 5: Solarlader: ParseResponse called from HandleResponse
2020.06.06 14:37:14 5: Solarlader: CheckChecksum (called from HandleResponse): 7d09 is valid
2020.06.06 14:37:14 4: Solarlader: ResponseDone request: id 1, fCode 16, type h, adr 36865, len 1, value 0051 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault), queued 0.16 secs ago, sent 0.16 secs ago, Current read buffer: 0110900100017d09, Id 1, fCode 16, response: id 1, fCode 16, type c, adr 36865, len 1
2020.06.06 14:37:14 5: Solarlader: DropFrame - drop 0110900100017d09
2020.06.06 14:37:14 5: Solarlader: set is sending read after write
2020.06.06 14:37:14 4: Solarlader: DoRequest called from Set created request: id 1, fCode 3, type h, adr 36865, len 1 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault Rd), read buffer empty
2020.06.06 14:37:14 5: Solarlader: QueueRequest called from DoRequest (Solarlader) with h36865, qlen 8
2020.06.06 14:37:14 4: Solarlader: ProcessRequestQueue called from QueueRequest, force, qlen 9, next entry to id 1 (Solarlader), last send to this device was 0.156 secs ago, last read 0.003 secs ago, last read on bus 0.003 secs ago from id 1 (Solarlader)
2020.06.06 14:37:14 4: Solarlader: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 14:37:14.546) for Solarlader, rest 0.097, sleep forced
2020.06.06 14:37:14 5: Solarlader: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 14:37:14.392) for Solarlader, delay 0.057secs over
2020.06.06 14:37:14 4: Solarlader: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 9, sending 010390010001f8ca request: id 1, fCode 3, type h, adr 36865, len 1 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault Rd), queued 0.00 secs ago, read buffer empty
2020.06.06 14:37:14 5: SW: 010390010001f8ca
2020.06.06 14:37:14 5: Solarlader: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.06.06 14:37:14 5: Solarlader: ReadAnswer called from Set
2020.06.06 14:37:14 5: Solarlader: ReadAnswer called and remaining timeout is 1.99602508544922
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got: 01030200
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got: 010302005179b8
2020.06.06 14:37:14 4: Solarlader: ParseFrameStart (RTU) extracted id 1, fCode 3 and data 020051
2020.06.06 14:37:14 5: Solarlader: HandleResponse called from ReadAnswer
2020.06.06 14:37:14 5: Solarlader: ParseResponse called from HandleResponse
2020.06.06 14:37:14 5: Solarlader: CheckChecksum (called from HandleResponse): 79b8 is valid
2020.06.06 14:37:14 5: Solarlader: HandleResponse now passing to logical device Solarlader for parsing data
2020.06.06 14:37:14 5: Solarlader: ParseObj called with data 0051, type h, adr 36865, valuesLen 1, op read
2020.06.06 14:37:14 5: Solarlader: ParseObj ObjInfo for h36865: reading=BattCapacityDefault, unpack=n, expr=$val=$val." Ah", format=, map=
2020.06.06 14:37:14 5: Solarlader: ParseObj unpacked 0051 with n to 81 hex 3831
2020.06.06 14:37:14 5: Solarlader: CheckEval for ParseObj evaluates expr for BattCapacityDefault, val=81, expr=$val=$val." Ah"
2020.06.06 14:37:14 5: Solarlader: CheckEval for ParseObj result is 81 Ah
2020.06.06 14:37:14 4: Solarlader: ParseObj assigns value 81 Ah to BattCapacityDefault

dann wäre da noch eine Frage zu meinen erstellten Modul (Anhang).

Wie kann man in dem Modul z.b. stateformat webcmd webCmdLabel  fest mit einbauen?

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 Juni 2020, 19:34:46
Hallo laserrichi,

spontan sehe ich keinen Fehler.
Kann das Holding-Register 36870 denn korrekt gelesen werden?
Was steht denn in der Dokumentation des Geräts zum Datentyp?

Zu stateformat und WebCMD: das kannst Du nicht so einfach im Modul ablegen.
Die Attribute sollte der Anwender setzen oder ein Attr-Template verwenden.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 Juni 2020, 19:46:09
Hallo sukram,

habe gerade gesehen, dass das Modul im obigen Post nicht richtig hochgeladen wurde.
Jetzt ist die aktuelle Datei oben angehängt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 06 Juni 2020, 21:53:14
Hallo Stefan,

ich habe mal mit Wireshark mitgeschnitten was denn die original Software so sendet. Leider kann ich da das einzelne nicht selektieren und die Software liest z.b. 16 aufeinanderfolgende Register aus oder schreibt die dann auch so.

Was mir aber jetzt aufgefallen ist, das der CRC in der Doku immer aus 2 Byte wohl besteht.

Aus meinen Beispiel oben wenn ich das Send Commando aufdrösel kommt folgendes dabei heraus:
sending 0110900600010205a1f4d7
01       device ID
10       function Code
90 06  start adresse
00 01  Anzahl adressen
02       CRC ... sollten eigentlich 2 sein  denn 02 05 als CRC wäre falsch
05 a1  das wäre  eigentlich mein gesetzter wert mit 1441 (14,41V)
f4 d7   ?  was das jetzt ist weis ich nicht

Vieleicht liegt hier der Hund begraben ? Oder Byte / Word Thema ?

Bei dem anderen setzen wo es funktioniert mit der Batterie kapazität steht der gesetzte Wert an der richtigen stelle aber nur mit einem Byte.
Im Anhang mal die Doku von epsolar
Auch wäre interessant wie ich meine Uhrzeit auch setzen kann die aus 3 Registern besteht, da war irgendwo im Forum schon ein anderer Beitrag, aber ist wohl tricky beim senden die Bytes wieder richtig zusammenzubauen...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 Juni 2020, 22:45:29
Hallo laserrichi,

02 ist der Bytecount.
Die Prüfsumme kommt nach dem zu schreibenden Wert.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 07 Juni 2020, 14:06:44
Hallo Stefan,
ok ja jetzt hab ich es auch gesehen das es beim lesen und schreiben ja anders ist ;-)

Soweit ich sehe ist das ganze dann schon richtig, nur der Controler lehnt das ab oder er erwartet hier eine ganze reihe von Registern auf einmal.
Zumindest liest die Software von denen diese 16 Register auf einmal und schreibt sie auch so.
Andere Holding Register lassen sich ja schreiben.

Andere Frage, kann ich z.b. bei nur einem Reading den Function Code anpassen ?
So liest die Software wohl Gerätebezeichnung und Firmware Version aus:
01 2b 0e 01 00 70 77

das wäre ja Holding mit read 34

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Juni 2020, 14:19:16
Hallo laserrichi,

Function code 43 (Hex 2b) steht für Encapsulated Interface Transport. Das ist nicht einfach ein Zugriff auf Holding-Register.
Ich setz den mal auf die Wunschliste. Sollte nicht zu aufwändig sein, den zu implemeritieren.  Bisher hatte ich aber noch kein Gerät, das diesen Code unterstützt ...

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 07 Juni 2020, 22:19:18
ok :-) Super.
Ich habe jetzt doch tatsächlich in der Doku die auch oben angehängt ist, den Satz hier gefunden:
Only when the battery type is User, the customer can set the other parameters(the parameters need to be set at the same time)
Ok Typ hab ich ja auf User, aber das entscheidende ist das man die Parameter alle zur selben Zeit setzen muss, also genau die 16 Aufeinanderfolgenden Registern.
k.a. wie ich das im Modul umsetzen kann. Aber das wäre dann mit Kanonen auf Spatzen geschossen. Denn man setzt das ja nur einmal und dann nimmt man halt die Original Software und in Fhem reicht es wenn man die Werte liest und weis was eingestellt ist.
Ich hab heute viel an dem Modul gebastelt und auch Doku mit eingebaut zu den Readings. Ich sollte wenn es soweit ist, vieleicht für den Hersteller (gibt davon ja auch andere Brands) einen eigenen Thread eröffnen und da das Modul anhängen, ist sicher auch anderen Nützlich zumal ich danach schon gefragt wurde.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: sukram am 11 Juni 2020, 20:20:01
Hallo Stefan,

danke fürs nochmal hochladen. Bin arbeitsbedingt noch nicht weitergekommen, habe das gerade erst eingerichtet. Es werden jetzt im 5 Sekundentakt die 3 Zähler abgefragt, sehr schön. Es springt zwar bei jedem Reconnect die State-Anzeige von meiner Zusammenfassung auf "disconnected, opened" und wieder zurück, aber das ist eher kosmetisch. SilentReconnect scheint ja eher für das Systemlog gedacht zu sein, richtig?

Ich bin mit der Lösung erst mal ganz zufrieden, du musst dir nicht die zusätzliche Arbeit machen. In meinem Fundus hat sich noch ein älterer Advantech ADAM 4570 Adapter aufgetan (2x Seriell RS232/485/422 auf Ethernet), der dann für FHEM als serieller Port erscheint. Den werde ich erstmal auf Tauglichkeit prüfen.

MfG

EDIT: Nach etwas basteln habe ich den Takt auf 10 Sekunden zwischen den Modulen und 60 Sekunden Intervall pro Modul eingerichtet. Das reicht erstmal  :D
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wolfshund am 22 Juni 2020, 14:02:03
Hallo zusammen,

habe inzwischen mein modbus am laufen, jedoch noch ein Problem.
Es soll ein Modbus device in Fhem angelegt werden, das mit einer vorhandenen Erfassungssoftware ( closed Source) zusammenarbeitet.
Software arbeitet NUR mit Wattnode Metern zusammen und genau das möchten wird umgehen.
Die Software sendet zur Identifizierung der angeschlossenen Nodes den Function Code 17(0x11) nennt sich "Report Slave ID"
Laut der Doku von Wattnode antwortet das Meter mit einem vorgegebenen Textstring

Address                             1 byte           1-247                          Modbus address of meter
Function Code                   1 byte            0x11                           Report Slave ID Function Code
Byte Count                        1 byte            1-x                             Number of bytes in Slave ID, Run Indicator Status, and Additional Data
Slave ID                             1 byte            0x02                         WattNode meter Slave ID byte
Run Indicator Status         1 byte             0xFF                         Always returns 0xFF
Additional Data                  Variable         ASCII string              Example: “Continental Control Systems LLC, WattNode MODBUS, WNC-3Y-208-MB“
                                                                null terminated
CRC                                   2 byte   

Ich habe probeweise mal an zweistellen im 98_Modbus.pw den Function Code 17(0x11)  hinzugefügt und bekomme auch schon eine Reaktion auf die Anfrage ,
die natürlich falsch formatiert ist.

2020.06.22 11:48:04 4: Weidmueller_192.168.74.86_1081: ParseFrameStart (TCP) extracted id 7, fCode 17, tid 1, dlen 2 and data
2020.06.22 11:48:04 5: Weidmueller_192.168.74.86_1081: HandleRequest called from Read
2020.06.22 11:48:04 5: Weidmueller_192.168.74.86_1081: ParseRequest called from HandleRequest
2020.06.22 11:48:04 5: Weidmueller_192.168.74.86_1081: HandleRequest could not parse request frame yet, wait for more data

in Modbus_ParseResponse  und  Modbus_ParseRequest habe ich hinzugefügt :

} elsif ($fCode == 17) {
        # Read id as acii                     pdu: fCode, adr, len
        return if ($dataLength) < 2;
        my ($adr, $values)  = unpack ('na*', $data);
        $response->{ADR}    = $adr;                         # adr of register
        $response->{VALUES} = "Continental Control Systems LLC, WattNode MODBUS, WNC-3Y-400-MB";
        $response->{TYPE}   = 'h';                          # holding registers
        $frame->{PDULEXP}   = 5;                            # 1 Byte fCode + 2 Bytes adr + 2 Bytes register

Das war nur ein Versuch der jedoch schon mal den Logeintag von oben erzeugt hat.
Meine vermutung ist das  $frame->{PDULEXP}   = 5;    geänert werden muss bzw. noch ananderen Stellen was fehlt.
Kann mir jemand einen Fingerzeig geben, oder kann ich das unter keinen Umstänen selber lösen?

LG

Andreas







Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Juni 2020, 10:31:31
Hallo Andreas,

$hash->{FRAME}{PDULEXP} bzw. $frame->{PDULEXP} ist die zu erwartende Länge der PDU.
Das wird in ParseRequest und ParseResponse gesetzt beziehungsweise bei Modbus-TCP schon in ParseFrameStart.
In HandleRequest wir daraus die erwartete Frame-Länge berechnet um dann zu erkennen, ob schon alle Daten gelesen wurden.
Eigentlich sollte es nicht zu kompliziert sein, den function code zu ergänzen. Am sinnvollsten wäre es natürlich, wenn der String dann nicht im Code steht, sondern aus einem Attribut geholt wird.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wolfshund am 26 Juni 2020, 15:14:14
Hallo Stefan,

Danke für die Antwort, jedoch habe ich das inzwischen mit einen Arduino gelöst,
Da es nur darum geht den Function Code 0x11 zu beantworten, und es läuft auch so wie es soll,
Ich bin kein Perl Programmierer, kann es zwar bedingtlesen, aber NICHT programmieren.

Mein momentanes Problem ist einfach in meiner Unwissenheit in Perl begründet.

Ich bekomme folgendes Reading in mein Modbus Device eingelesen

   
Energy_Sum_LRA   hex=3233332e333337313733343631393134, string=233.337173461914, s=13106, s>=12851, S=13106, S>=12851, i=13106, i>=12851, I=13106, I>=12851, f=4.07453584760908e-11, f>=1.04308082171656e-08
ich möchte den Wert string=233.337173461914 als 233,33 angezeigt bekommen

Das reading habe ich so definiert
Zitat
attr mega_id10 obj-h19000-allowWrite 0
attr mega_id10 obj-h19000-len 2
attr mega_id10 obj-h19000-reading Energy_Sum_LRA
attr mega_id10 obj-h19000-revRegs 0
attr mega_id10 obj-h19000-set 1
attr mega_id10 obj-h19000-unpack f>

Ich glaube es ist nur eine Formatierung
wie z.B.
attr mega_id10 obj-h19000-format %.2f
das geht aber nicht. sondern liefert immer nur 0.00

Dank nochmals für das Modul Modbus und Deine Antwort

LG

Andreas

2020-06-26 15:04:56
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 Juni 2020, 18:16:36
Hallo Andreas,

Das sieht nach einem ASCII-String aus, nicht nach einer Float-Zahl.
Gib doch mal als unpack-Code a* an.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: max333 am 04 Juli 2020, 22:07:38
Hallo,

ich habe mir mit ModbusAttr ein Modul erstellen lassen für meinen Sensor. Dieser Sensor gibt zusätzlich zu den Werten einen Fehlerstatus aus. Falls dieser größer als 0 ist, dann sind alle Messwerte zu verwerfen. Wie kann ich das erreichen, das im Fehlerfall keine readings aktualisiert werden außer dieser Fehlerstatus? Der Fehlerstatus hat nichts mit der Prüfsumme vom Modbusprotokoll zu tun.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 06 Juli 2020, 09:51:42
Hallo max333,

ich denke das kann das Modbus Modul nicht direkt selber unterstützen, da es eine weitergehende Auswertung der übermittelten Werte ist.
In einem Device habe ich mal innerhalb des userreadings nicht mehr benötigte Readings entfernt, was sicherlich nicht die tollste Lösung sein wird.

Dieses Beispiel erstellt aus drei readings ein lesbares Datum und löscht anschließend die einzelnen readings
consumption_WaterDailyDate:consumption_WaterDailyDate-1.* {my $date=sprintf("%4d-%02d-%02d",ReadingsVal("$NAME","consumption_WaterDailyDate-3",0),ReadingsVal("$NAME","consumption_WaterDailyDate-2",0),ReadingsVal("$NAME","consumption_WaterDailyDate-1",0) );; fhem("deletereading $NAME  consumption_WaterDailyDate-.*");; $date }

Wenn Du so etwas wie fhem("deletereading $NAME  consumption_WaterDailyDate-.*") in eine if Abfrage auf den Status einbaust, dann wären Deine Readings weg, die Events kommen jedoch trotzdem.
Sollte sich der Inhalt der Readings bei einem negativen Status jedoch nicht verändern, dann könntest Du mal mit event-on-change experimentieren.

Gruß
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: max333 am 06 Juli 2020, 10:43:07
Das nachträgliche Löschen ist für mich leider keine Option, denn die falschen Werte sind schon in der LogDB und es kommt zu Fehlermeldungen im Log.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 06 Juli 2020, 11:31:17
Das nachträgliche Löschen ist für mich leider keine Option, denn die falschen Werte sind schon in der LogDB und es kommt zu Fehlermeldungen im Log.

Wenn Du ein Modul erstellt hast, musstest Du den Status zuerst abfragen und die restlichen Werte dann ueberspringen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 Juli 2020, 18:04:37
dafür gibt es folgendes Attribut:

Zitat
obj-[cdih][1-9][0-9]*-ignoreExpr
defines a perl expression that returns 1 if a value should be ignored and the existing reading should not be modified
beziehungsweise
Zitat
dev-([cdih]-)*defIgnoreExpr
defines a default Perl expression to decide when values should be ignored.

Allerdings muss man dabei aufpassen, welche Werte in welcher Reihenfolge bzw. zusammen gelesen werden...

Gruss
   Stefan Strobel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: max333 am 06 Juli 2020, 19:11:32
Ich habe das mit obj-[cdih][1-9][0-9]*-ignoreExpr hinbekommen, vielen Dank für den Tipp.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 15 Juli 2020, 08:36:48
Guten Morgen Community - Stefan,
ich habe keine ahnung seit wann es so ist - aber ich habe via Modbus meinen Wärmemengenzähler eingebunden. Aus mir unerklärlichen Gründen kommen hier "ohne Ende" Events an.

2020-07-15 08:26:44 statistics statistic Updated stats for: WMZ
2020-07-15 08:26:44 ModbusAttr WMZ Vorlauftemperatur: 24.7
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 ModbusAttr WMZ statGesamtWaermemenge: Hour: 0.000 Day: 0.006 Month: 0.089 Year: 1.466 (since: 2020-03-23 )
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 statistics statistic Updated stats for: WMZ
2020-07-15 08:26:44 ModbusAttr WMZ Ruecklauftemperatur: 26.4
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 ModbusAttr WMZ statGesamtWaermemenge: Hour: 0.000 Day: 0.006 Month: 0.089 Year: 1.466 (since: 2020-03-23 )
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 statistics statistic Updated stats for: WMZ
2020-07-15 08:26:44 ModbusAttr WMZ gesamtWaermemenge: 40.629
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 ModbusAttr WMZ statGesamtWaermemenge: Hour: 0.000 Day: 0.006 Month: 0.089 Year: 1.466 (since: 2020-03-23 )
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 statistics statistic Updated stats for: WMZ
2020-07-15 08:26:44 ModbusAttr WMZ aktWaermeleistung: 0
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 ModbusAttr WMZ statGesamtWaermemenge: Hour: 0.000 Day: 0.006 Month: 0.089 Year: 1.466 (since: 2020-03-23 )
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 statistics statistic Updated stats for: WMZ
2020-07-15 08:26:44 ModbusAttr WMZ Durchfluss: 0
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00
2020-07-15 08:26:44 ModbusAttr WMZ statGesamtWaermemenge: Hour: 0.000 Day: 0.006 Month: 0.089 Year: 1.466 (since: 2020-03-23 )
2020-07-15 08:26:44 ModbusAttr WMZ Spreizung: -1.7
2020-07-15 08:26:44 ModbusAttr WMZ Waermeleistung: 0.0
2020-07-15 08:26:44 ModbusAttr WMZ aktAZ: 0.00


Eigentllich brauche ich jeden Wert ja nur einmal. Habe aber keine Idee wie ich hier einfluss nehmen kann.
Vielleicht habt Ihr eine Idee...

Noch ein list des Devices:
Internals:
   DEF        35 30
   FUUID      5e765a10-f33f-c6c7-f386-bc294aafb8467fbb
   INTERVAL   30
   IODev      modbusRTU
   MODBUSID   35
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       WMZ
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-WMZ
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1594794698.36077
   TRIGGERTIME_FMT 2020-07-15 08:31:38
   TYPE       ModbusAttr
   lastUpdate 1594794668.36077
   FRAME:
   READ:
   READINGS:
     2020-07-15 08:31:10   Durchfluss      0
     2020-07-15 08:31:09   Ruecklauftemperatur 26.4
     2020-07-15 08:31:11   Spreizung       -1.7
     2020-07-15 08:31:10   Vorlauftemperatur 24.7
     2020-07-15 08:31:11   Waermeleistung  0.0
     2020-07-15 08:31:11   aktAZ           0.00
     2020-07-15 08:31:10   aktWaermeleistung 0
     2018-10-01 06:13:08   gesElektrAm01.10.18 3739.418
     2019-10-01 06:54:03   gesElektrAm01.10.19 5811.907
     2018-09-30 22:27:43   gesWaer