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:
Zitat2017.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 2
fehlte 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

Zitat2017.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
Zitat von: der-Lolo am 26 Oktober 2017, 09:38:12
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



Zitat 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: 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 1
Im 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
Zitat 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.

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,

Zitat von: StefanStrobel am 20 Januar 2018, 18:17:46
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
Zitat von: StefanStrobel am 22 Januar 2018, 22:09:10
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 1
Im 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,

Zitat von: Herjemine am 31 Januar 2018, 12:22:51
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
Zitat 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

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
Zitat von: HP am 12 März 2018, 10:14:19
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 Pool
Der 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|TCP
im 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> slave
oder
define <name> ModbusAttr <Id> slave <Address:Port> RTU|ASCII|TCP
Adddress 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 TCP
sofern 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
Zitat von: pejonp am 16 Oktober 2018, 00:48:54
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

Zitat 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: predi-ger-many am 05 November 2018, 22:37:31
Zitat 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

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
Zitat 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

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
Zitat 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

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),

Zitat 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!


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,
Zitat von: elektro_rainer am 11 Dezember 2018, 09:42:38
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
Zitat 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

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
Zitat 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

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 TCP
oder auch
defmod SDM630 ModbusSDM630M 1 180 <IP>:502 TCP
Der 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 TCP
aber 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
Zitat von: StefanStrobel am 01 Mai 2019, 21:05:01

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
Zitat von: StefanStrobel am 01 Mai 2019, 21:53:50
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.

Zitat von: Rudy am 12 Mai 2019, 12:37:25
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.
Zitat von: StefanStrobel am 15 Mai 2019, 10:49:23
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
und
2019.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
Zitat von: ahermann86 am 03 Juli 2019, 09:40:49
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
Zitat von: laserrichi am 30 August 2019, 16:41:47
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
Zitat 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

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
Zitat von: gadget am 26 September 2019, 14:52:08
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
Zitat von: laserrichi am 26 September 2019, 17:00:20
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
Zitat 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

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,

ZitatUm 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.

ZitatDamit 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_Power
danach 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
Zitat2019-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
Zitat von: ch.eick am 01 November 2019, 13:37:44
attr PV_Anlage_1 dev-h-defPoll 2
Zitatobj-[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 ?

Zitat von: ch.eick am 01 November 2019, 13:37:44
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


Zitatdie 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.
Zitatdie 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
ZitatIch 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
Zitat 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

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
Zitat von: R1F800 am 28 November 2019, 07:11:55
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
Zitat von: StefanStrobel am 29 November 2019, 21:05:19
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
Zitat von: Wzut am 29 November 2019, 21:12:06
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
Zitat 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"
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
Zitat von: w125t am 23 Januar 2020, 19:05:31
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 ignored
Ich 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
Zitat von: bertl am 23 März 2020, 20:23:02
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
Zitat 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

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.
Zitat von: pejonp am 24 März 2020, 00:46:28wenn 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
Zitat von: bertl am 25 März 2020, 11:20:44
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.

Zitat von: bertl am 25 März 2020, 11:20:44
+ 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!

Zitat von: Fritz Muster am 30 März 2020, 13:20:27Das 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,

Zitat von: Knallkopp_02 am 17 April 2020, 11:24:38
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
Zitat von: laserrichi am 23 April 2020, 22:38: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 DHW300
FHEM Hauptserver:
defmod DHW300MASTER ModbusDHW300 4 60 192.168.1.33:1502
Jetzt 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
Zitat 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.

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
Zitatattr 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
Zitat 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.

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   gesWaermeAm01.10.18 22.384
     2019-10-01 06:51:18   gesWaermeAm01.10.19 32.031
     2020-07-15 08:31:10   gesamtWaermemenge 40.629
     2020-07-15 08:31:11   statGesamtWaermemenge Hour: 0.000 Day: 0.006 Month: 0.089 Year: 1.466 (since: 2020-03-23 )
     2020-07-15 07:59:55   statGesamtWaermemengeLast Hour: 0.000 Day: 0.007 Month: 0.189 Year: -
     2020-03-22 19:17:31   statStateDay    opened: 19:17:36 opened_Count: 1
     2020-03-21 23:59:55   statStateDayLast opened: 04:20:56 opened_Count: 1 (since: 2020-03-21_19:38:59)
     2020-03-22 19:17:31   statStateMonth  opened: 23:38:32 opened_Count: 1 (since: 2020-03-21_19:38:59)
     2020-03-22 19:17:31   statStateYear   opened: 23:38:32 opened_Count: 1 (since: 2020-03-21_19:38:59)
     2020-07-15 08:31:00   state           opened
   REMEMBER:
     lrecv      1594794670.4295
     lsend      1594794670.40396
   gotReadings:
     Durchfluss 0
   helper:
     _98_statistics statistic
   lastRead:
     h256       1594794670.3028
     h258       1594794670.43084
     h262       1594794670.17471
     h264       1594794670.04711
     h266       1594794669.91922
Attributes:
   IODev      modbusRTU
   comment    aktAZ {sprintf("%.2f",ReadingsVal("WMZ","aktWaermeleistung","0")*1000 / ReadingsVal("SDM630","Power_L2__W","0"))},
   dev-h-defBswapRegs 1
   dev-h-defPoll 1
   event-on-update-reading .*
   obj-h256-format %.3f
   obj-h256-len 2
   obj-h256-reading gesamtWaermemenge
   obj-h256-showGet 1
   obj-h256-unpack f
   obj-h258-len 2
   obj-h258-reading Durchfluss
   obj-h258-showGet 1
   obj-h258-unpack f
   obj-h262-len 2
   obj-h262-reading aktWaermeleistung
   obj-h262-showGet 1
   obj-h262-unpack f
   obj-h264-format %.1f
   obj-h264-len 2
   obj-h264-reading Vorlauftemperatur
   obj-h264-showGet 1
   obj-h264-unpack f
   obj-h266-format %.1f
   obj-h266-len 2
   obj-h266-reading Ruecklauftemperatur
   obj-h266-showGet 1
   obj-h266-unpack f
   room       ModbusRTU
   userReadings Spreizung {sprintf("%.1f",ReadingsVal("WMZ","Vorlauftemperatur","0") - ReadingsVal("WMZ","Ruecklauftemperatur","0"))},
Waermeleistung {sprintf("%.1f",ReadingsVal("WMZ","aktWaermeleistung","0")*1000)},
aktAZ {sprintf("%.2f",ReadingsVal("WMZ","aktWaermeleistung","0")*1000 / ReadingsVal("SDM630","Power_L2__W","0"))}
   userattr   IODev dev-h-defBswapRegs dev-h-defPoll disable event-min-interval event-on-change-reading event-on-update-reading obj-h256-format obj-h256-len obj-h256-poll obj-h256-reading obj-h256-showGet obj-h256-unpack obj-h258-format obj-h258-len obj-h258-poll obj-h258-reading obj-h258-showGet obj-h258-unpack obj-h262-format obj-h262-len obj-h262-poll obj-h262-reading obj-h262-showGet obj-h262-unpack obj-h264-format obj-h264-len obj-h264-poll obj-h264-reading obj-h264-showGet obj-h264-unpack obj-h266-format obj-h266-len obj-h266-poll obj-h266-reading obj-h266-showGet obj-h266-unpack userReadings


Ich kann mir vorstellen das es mit dem userattr zusammenhängt - kann mir auch nicht erklären wo das herkommt, bzw. wie es entstanden ist.
Habe aber versucht das ganze userattr zu löschen, es hat scheinbar keinen Einfluss auf die Event menge...

Mein DB-Log stellt im nachhinein das hauptproblem da, ich habe etwa 40.000 Einträge zuviel pro Tag.

Ich hoffe es hat jemand eine Idee wie ich es hinbekommen kann das der Wärmemengenzähler nicht mehr ganz so gesprächig ist.

Gruß aus Berlin,
der-lolo
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 15 Juli 2020, 18:11:08
Zitat von: der-Lolo am 15 Juli 2020, 08:36:48
   event-on-update-reading .*

Hier wuerde ich mal nur die readings angeben, die Du wirklich haben willst.
Eventuell waere auch event-on-change-reading denkbar, dann gibt es nur Events, wenn der Wert anders ist als der Vorherige.
Das hat natuerlich zur Folge, dass es zu Plotabbruechen kommen kann, wenn die Aenderungen zu lange (Tageswechsel) auseinander liegen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 15 Juli 2020, 18:49:42
Ja ch.eick -
grundsätzlich gebe ich Dir recht - frage mich aber warum ich innerhalb eines Lesezykluses mehrfach Updates bekomme.
Und warum die Wärmeleistung z.b. auch innerhalb einer Sekunde mehrfach reinkommt...
Bei der Spreizung kann ich es ja noch verstehen, weil die ja über ein userReading gerechnet wird.
Ich dachte das jedes angefragte object einmal pro Lesezyklus abgerufen wird...



Ich finde das userAttr komisch - zumal wenn ich es lösche, speicher und einen shutdown restart absetze das user Attr sich automatisch wieder setzt...
Oder wird das automatisch vom Modul generiert?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 15 Juli 2020, 20:22:06
Zitat von: der-Lolo am 15 Juli 2020, 18:49:42
Ich finde das userAttr komisch - zumal wenn ich es lösche, speicher und einen shutdown restart absetze das user Attr sich automatisch wieder setzt...
Oder wird das automatisch vom Modul generiert?
Ich meine auch, dass es automatisch generiert wird und nur eine Liste aller attribute darstellt.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 15 Juli 2020, 20:26:00
Zitat von: der-Lolo am 15 Juli 2020, 18:49:42
grundsätzlich gebe ich Dir recht - frage mich aber warum ich innerhalb eines Lesezykluses mehrfach Updates bekomme.
Und warum die Wärmeleistung z.b. auch innerhalb einer Sekunde mehrfach reinkommt...
Bei der Spreizung kann ich es ja noch verstehen, weil die ja über ein userReading gerechnet wird.
Ich dachte das jedes angefragte object einmal pro Lesezyklus abgerufen wird...
Bei meinen Modbus devices hat das auf jedenfall fuer Ruhe gesorgt. Ich schau auch immer zu beginn in das event log, bis ich nur noch das sehe was ich haben moechte.

Wie hast Du das mit dem WMZ angeschlossen, ich habe einen mit einer Leseschnittstelle integriert, habe aber noch nicht den passenden Lesekopf gefunden :-(

Gruss
     Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 17 Juli 2020, 14:37:13
Hallo Stefan,
ich habe ein Problem mit Modbus. Darf ich kurz verlinken?
https://forum.fhem.de/index.php/topic,112869.0.html

Muss mir noch angewöhnen, *vorher* in die Maintainer zu schauen, um das richtige Forum zu finden...
Die Suche hat leider nix brauchbares ergeben, und ich bin mit meinem Perl am Ende :)

Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wolfshund am 17 Juli 2020, 17:46:03
Hallo ,

mein Modbus läuft relativ dank Stefans Hilfe, und ich bekomme inzwische auch richtige Werte.
Ein Problen kann ich momentan nicht lösen.
Ich lese aus ainem Weidmüller Energy meter ein Register aus
attr WeidMuellerInput dev-h-defLen 2
attr WeidMuellerInput dev-h-defPoll 1
attr WeidMuellerInput dev-h-defRevRegs 0
attr WeidMuellerInput dev-h-defShowGet 1
attr WeidMuellerInput dev-h-defUnpack f>
attr WeidMuellerInput event-on-change-reading .*
attr WeidMuellerInput event-on-update-reading .*
attr WeidMuellerInput obj-h19026-reading r19026


r19026                      189.201049804688



Dieses Reading möchte ich nun in zwei Teile zerlegen um es dann in zwei 16 bit Register eines anderen Modbus devices zu schreiben

was nachher rauskommen soll ist etwa folgendes


das eingelesene Register s.o.     float             189.201049804688


register100  (anderes Device)                      0x433d
register101 (anderes Device)                       0x3378

das ganze würde ich über notifys lösen

Ich scheitere momentan an der Umrechnung float in zweimal 16 bit.


Liebe Grüße,

Andreas



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 17 Juli 2020, 18:53:05
@ch.eik - Danke, ich habe mit event-on-change und event-min-interval für ruhe gesorgt...
Mein WMZ hat eine "eingebaute" Modbus Schnittstelle - also kein Lesekopf oder ähnliches.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Juli 2020, 22:35:01
Hallo Andreas,

wenn Du auf dem Ziel-Gerät auch einen Float-Wert hast, der über zwei Register geht, dann musst Du die nicht einzeln schreiben. Statt dessen kannst Du die Länge des Objekts auf zwei setzen und mit dem passenden Unpack-code einen Float-Wert direkt über zwei Register schreiben. Es kommt aber darauf an, wie das Ziel-Gerät den Wert haben will...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nestor am 25 Juli 2020, 22:54:56
Hello Stefan,

Attached is small patch to optimize the event processing in Fhem. For ModbusAttr module this NOTIFYDEV was already set. ;)

--- - 2020-07-25 01:14:07.434805432 +0200
+++ /srv/fhem/FHEM/98_Modbus.pm 2020-07-25 01:13:34.000000000 +0200
@@ -547,6 +547,7 @@
     $ioHash->{DeviceName} = $dev;           # needed by DevIo to get Device, Port, Speed etc.       
     $ioHash->{IODev}      = $ioHash;        # point back to self to make getIOHash easier
     $ioHash->{SerialConn} = 1;
+    $ioHash->{NOTIFYDEV}  = "global";       # NotifyFn nur aufrufen wenn global events (INITIALIZED etc.)
     
     Modbus_Close($ioHash, 1);               # close, set Expect, clear Buffer, but don't set state to disconnected 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wolfshund am 27 Juli 2020, 12:18:43
Zitat von: StefanStrobel am 23 Juli 2020, 22:35:01

wenn Du auf dem Ziel-Gerät auch einen Float-Wert hast, der über zwei Register geht, dann musst Du die nicht einzeln schreiben. Statt dessen kannst Du die Länge des Objekts auf zwei setzen und mit dem passenden Unpack-code einen Float-Wert direkt über zwei Register schreiben. Es kommt aber darauf an, wie das Ziel-Gerät den Wert haben will...

Hallo Stefan,

Danke, habe das nach dem Try and Error Prinzip so am Freitag auch gelöst, habe mich mit den 16 Bit / 32Bit enfach verrannt.
Das Thema Modbus ist für mich noch ziemliches Neuland, es funktionet nun so wie es soll.

Inzwischen habe ich dein Modbus Modul auch dazu bekommen, den Befehl 17(0x11) richtig zu beantworten, dies aber mit einer Quick und dirty Methode.


sub Modbus_ParseResponse($$%)
.
.
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$
        $response->{TYPE}   = '';                          # holding registers
        $frame->{PDULEXP}   = 5;                            # 1 Byte fCode + 2 $

sub Modbus_HandleRequest($)
.
.
    Modbus_CheckChecksum($hash);                    # get $hash->{FRAME}{CHECKS$
     if ($fc > 16  ) {
                     $frameLen = 5 ;
                }
sub Modbus_ParseRequest($$)
.
.
elsif ($fCode == 17) {
        # Read id as acii                     pdu: fCode, adr, len
        #return if ($dataLength) < 2;
        my ($adr, $values)  = unpack ('na*', $data);
        $request->{ADR}    = $adr;                         # adr of register
        $request->{VALUES} = "Continental Control Systems LLC, WattNode MODBUS,$
        $request->{TYPE}   = 'c';                          # holding registers
        $frame->{PDULEXP}   = 8;                            # 1 Byte fCode + 2 $
    } else

sub Modbus_PackResponse($$)
.
.

    my $data;
if ($fCode == 17) {
$response->{ERRCODE} = 0;
}
.
.
elsif ($fCode == 17) {                    # Request ID                   $
        $data = pack ('ccca*', 66, 2 , 255,"Continental Control Systems LLC, Wa$
    }


Mit meinem beschränten Perl Wissen bin ich aber trotzdem zufrieden das ich die Stellen gefunden habe, und das System so "verbiegen" konnte das es funktioniert.

Warum dieser Aufwand?
Siehe mein Post « Antwort #490 am: 22 Juni 2020, 14:02:03 »

Dank Deines Modbus Modules, konnte ich die gesamte Problematik lösen, wenn auch sehr unprofessionell und gehackt.
Meine Bitte wäre, die Funktion 17(0x11) auf die Wunschliste zu setzen, da ich z.B. mit der Einbindung von Attributen komplett überfordert war und deshalb diesen
"Quick & Dirty Hack" benutzt habe.

Danke für Dein Modul un Deine Hilfe.


LG

Andreas



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Juli 2020, 17:35:32
Hallo Andreas,

function code 17 kann ich gerne einbauen.
Ich bein eh gerade dabei das Modul zu überarbeiten.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: JF Mennedy am 31 Juli 2020, 11:34:39
Hallo, ich versuche so ein Register zu entschlüsseln, wie im Anhang beschrieben. Wenn ich das Register auslese bekomme ich folgende Antwort: hex=e500, string=.., s=229, s>=-6912, S=229, S>=58624

ich stehe hier leider komplett auf dem Schlauch, wie ich das nun weiter verarbeiten könnte...

Gruss Jan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: JF Mennedy am 31 Juli 2020, 12:35:42
Also, Selbsthilfe ist der Beste Weg zum Lernen...

Ich habe nun die Dezimalzahl in eine Binärzahl umgewandelt:
PH_STATUS { sprintf("%016b",ReadingsVal($name,"pH-Status",0)) }

Das Ergebnis ist:
PH_STATUS 1110010100000000

Die Bitfolge ist :


bit:     15 14 13 12   11 10 9  8    7  6  5  4    3  2  1  0
binar:   1  1  1  0    0  1  0  1    0  0  0  0    0  0  0  0


Und somit komme ich an die jeweiligen Statusmeldungen aus dem Register :-)

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wolfshund am 31 Juli 2020, 17:42:42
Hallo Stefan,

Zitatfunction code 17 kann ich gerne einbauen.

Das wäre super, traue meiner gehackten Version nicht so ganz ;)
habe im Moment auch das Update für Modbus deaktiviert.


LG
Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 02 August 2020, 06:16:04
Hallo zusammen, erstmal besten Dank für dieses Modul. Ich nutze Modbus attr mit tcp als Slave zur Kommunikation zu einem Touch Panel.
Ich habe folgendes Problem:
In fhem bekomme ich immer ein zusätzliches device im room ,,Connections" angelegt. Ich habe den Eindruck das dies bei jeder neuen TCP Verbindung (mehrmals täglich) erfolgt. Der Name des devices enthält den names des von mir angelegten Devices plus Ip und Port. Type ist auch ModbusAtrr.

Ist das so gewollt? Oder läuft hier noch was schief?
Danke vorab!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 August 2020, 07:56:52
Hallo,

das temporäre Device unter Connections ist normal.
Stört es?

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 02 August 2020, 21:21:33
Hallo Stefan, danke für die Antwort. Es würde nicht stören wenn es nicht dazu führen würde das FHEM immer umgespeicherte Änderungen anzeigt, daher weiß man nicht Ob man wirklich speichern muss oder nicht.
es wäre auch gut wenn der Raum von dem ,,Mutterobjekt" genommen werden könnte...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 08 August 2020, 07:01:26
Hallo Stefan, wäre diese Änderung aufwendiger? Wie gesagt mir würde es reichen wenn das Device sich nicht immer ändert und damit die Fehm Konfiguration editiert...
Besten dank vorab!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 August 2020, 13:17:59
Hallo Tomk,

Ich muss da selbst erst mal recherchieren.
Das Modbus-Modul verwendet die TCPServerUtils für die TCP-Verbindungen als Slave.
Ob / wie das dann ohne neues Device funktioniert, muss ich noch klären.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gramels am 02 September 2020, 10:25:53
Hallo,

ich habe Probleme mit Datentypen.

In meinem Kamstrup Ominpower Stromzähler steckt nun ein smart-me modul (EWS Schyz in der Schweiz). Das kann ich vie modbus tcp ansprchen.

Die aktuelle Leistung wird korrekt angezeigt in fhem.

Wenn ich die Zählerstände abfrage erhalte ich unklare Werte. Ich vermute ine unpack Problem. Habe aber schon allerhand durchprobiert. Wenn ich nun mit einem Windows Modbus Tool die Register abfrage erhalte ich

in Hex
0002 1810

was in Dec
137232

entspricht und korrekt ist . Nur in FHEM bekomme ich dies nicht aufgelöst.

Was sind die richtigen Objekteinstellungen um dies in FHEM rcihtig drazustellen?

Grüsse Lothar
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 September 2020, 13:14:56
Hallo,

Zitat von: Tomk am 08 August 2020, 07:01:26
Hallo Stefan, wäre diese Änderung aufwendiger? Wie gesagt mir würde es reichen wenn das Device sich nicht immer ändert und damit die Fehm Konfiguration editiert...
Besten dank vorab!

Ich habe mir das nochmal angesehen. Die Connection-Devices werden als TEMPORARY erzeugt. Das sieht man bei den Internals. Solche Devices sind keine strukturellen Änderungen und Fhem möchte deswegen auch keine Änderungen speichern.
Hilft das?

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 September 2020, 13:20:44
Hallo Lothar,

Zitat von: gramels am 02 September 2020, 10:25:53
Wenn ich die Zählerstände abfrage erhalte ich unklare Werte. Ich vermute ine unpack Problem. Habe aber schon allerhand durchprobiert. Wenn ich nun mit einem Windows Modbus Tool die Register abfrage erhalte ich

in Hex
0002 1810

was in Dec
137232

entspricht und korrekt ist . Nur in FHEM bekomme ich dies nicht aufgelöst.

Was sind die richtigen Objekteinstellungen um dies in FHEM rcihtig drazustellen?

0002 1810 sind offensichtlich 32 Bit, also zwei aufeinanderfolgende Register.
Entsprechend muss bei der Konfiguration als Länge zwei angegeben werden.
Das Format scheint ein 32-Bit Integer zu sein (vermutlich unsigned im big-endian format).
Auf https://perldoc.perl.org/functions/pack.html findet sich dafür N

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 07 September 2020, 21:06:27
Zitat von: StefanStrobel am 07 September 2020, 13:14:56
Hallo,

Ich habe mir das nochmal angesehen. Die Connection-Devices werden als TEMPORARY erzeugt. Das sieht man bei den Internals. Solche Devices sind keine strukturellen Änderungen und Fhem möchte deswegen auch keine Änderungen speichern.
Hilft das?

Gruss
   Stefan

Danke für die Info! Das attribute temporary ist auf 1, richtig. Allerdings zeigt fhem immer wieder eine Änderung an nach einigen Stunden und ich habe das in Verbindung mit modbus gebracht, da ich nur dies geändert habe als das Phänomen erstmals auftrat. Kann man irgendwie herausfinden welche Änderung Fhem speichern möchte?
Ich habe die Fhem.cfg verglichen, hier sind keine Änderungen drin...

Was mir noch einfällt, vielleicht sorgt der neue ,,Raum" Connections dafür das die Änderung erkannt wird und nicht das temporary device selbst?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pechnase am 10 September 2020, 11:57:18
Hallo,
ich möchte mein FHEM um den Modbus RTU über eine serielle Schnittstelle erweitern. Als Testsystem verwende ich einen Raspberry Pi und da ich noch keinen USB-RS485 Wandler zur Hand habe, verbinde ich einfach einen USB-seriell Adabpter mit FTDI-Chip mit einer USB Schnittstelle des Raspberry. Die Schnittstelle wird vom raspbian Betriebssystem auch erkann und ich habe folgende Devices definiert:
defmod ModbusLine Modbus /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A400YZ8S-if00-port0@19200,8,E,1
attr ModbusLine comment 09.09.2020: laut Proxon Tabelle 19200,8,E,1 als Werkeinstellung
attr ModbusLine room myModbus
attr ModbusLine verbose 5

setstate ModbusLine opened
setstate ModbusLine 2020-09-10 10:19:21 state opened


und
defmod Proxon_WP ModbusAttr 41 10 RTU
attr Proxon_WP userattr obj-i195-reading
attr Proxon_WP comment 09.09.2020: Laut Modbus Tabelle default Adresse 41 und 19200baud
attr Proxon_WP obj-i195-reading T1-Zuluft
attr Proxon_WP room myModbus

setstate Proxon_WP opened
setstate Proxon_WP 2020-09-10 10:38:24 state opened



Das Master-Slave Prinzip des Modbus ist mir bekannt. Da ich die Proxon WP noch nicht physikalisch verfügbar habe wollte ich folgende Testschritte durchführen:

Wo ist mein Gedankenfehler bzw. woran könnte es liegen, dass ich kein Poll des Masters auf der Seriellen Schnittstelle sehe? Welche STATE kann das Modul 'Modbus' einnehmen? Bei mir wird 'opened' angezeigt.

Danke für einen kleinen Gedankenanstoß

Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pechnase am 10 September 2020, 21:07:03
ich glaube, ich habe meinen Fehler gefunden. Es fehlt das
attr Proxon_WP obj-i195-poll 1
bzw. alternativ
attr Proxon_WP dev-i-defPoll 1

Jetzt pollt der Master schon mal den Slave.

Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Oktober 2020, 19:31:23
Hallo Ihr, kurze Zwischenfrage: gibt es ein Attribut welches eine Zeit angibt, nachdem ein ehemals gelesener Wert auf "0" oder "error" oder irgendwas anderes gesetzt wird? Also wenn seit x Sekunden/Minuten kein neuer Wert gelesen werden kann -> 0/error

bin in der Commandref nicht fündig geworden.

Danke und Gruß
H.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 10 Oktober 2020, 19:43:44
Zitat von: holle75 am 10 Oktober 2020, 19:31:23
Also wenn seit x Sekunden/Minuten kein neuer Wert gelesen werden kann -> 0/error
schau dir mal readingsWatcher an, der ist genau für so etwas macht wurden :)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Oktober 2020, 20:19:00
Ah ok, werde ich mir ansehen.
Dachte Stefan hat da vielleicht schon direkt was ins Modul gebaut.
Bei mir bleiben Werte generell stehen, auch wenn das Device nicht erreichbar ist. Bei httpmod fallen die Werte, als Beispiel, bei mir auf 0 wenn ein Wert nicht auslesbar ist.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 20 Oktober 2020, 14:53:56
Hallo,
ich habe einen Infini10k Solar-Wechselrichter mit einer Modbus-Karte.
Auf dem einen Port läuft die Kommunikation bereits einwandfrei, dank Stefans Hilfe.

Für die Kommunikation mit dem Batteriepack benötigt man angeblich eine weitere Karte, die dann "BMS-Modbus-Karte" heisst.
Aus diesem Grund versuche ich nun, herauszufinden, ob nicht vielleicht beides über die gleiche Karte funktioniert.
Da ich leider noch nicht viel Ahnung von Modbus habe und mich grade auch irgendwie sehr schwer tue, voranzukommen,
wollte ich mal fragen, ob jemand aus den ankommenden Daten irgendwas sinnvolles interpretieren kann:


2020.10.20 12:52:23.384 5: infini_test: HandleRequest could not parse request frame yet, wait for more data
2020.10.20 12:52:23.386 5: infini_test: read buffer: b7007feef8b8c3d8f8431f007fdfdfafd0ffa3b7007feef8b8c3d8f8431f007fdfdfaf9dff63a6007feef8b8c3d8f8431f007fdfdfaf9dff63a6007feef8b8c3d8f8431f007fdfdfaf9dff63a6007feef8b8c3d8f8431f007fdfdfaf9dff63a6007feef8b8c3d8f8431f007fdf5fafd6ff03d1007feef8b8c3d8f8431f007fdf5fafa4ff438a007feef8b8c3d8f8431f007fdf5fafa4ff43c5007feef8b8c3d8f8431f007fdf5fafb6ffe169007feef8b8c3d8f8431f007fdf5fafb6ffe169007feef8b8c3d8f8431f007fdf5fafb6ffe169007feef8b8c3d8f8431f007fdf5fafddffa3ee007feef8b8c3d8f8431f007fdf5fd7ddffa3ee007feef8b8c3d8f8431f007fdfdfedfcff63ff007feef8b8c3d8f8431f007fdfdfafe8ff2135007feef8b8c3d8f8431f007fdfdfafe8ff2135007feef8b8c3d8f8431f007fdf5f7dfaff2332007feef8b8c3d8f8431f007fdfdfaff7ff231a007feef8b8c3d8f8431f007fdfdf7dffff238a007feef8b8c3d8f8431f007fdfdfffffff09ee007feef8b8c3d8f8431f007fdfdffdfcff231e007feef8b8c3d8f8431f007fdfdffdfcff231e007feef8b8c3d8f8431f007fdf5ffdffff211e007feef8b8c3d8f8431f007fdf5fbdfcff2373007feef8b8c3d8f8431f007fdf5fbdfcff2373007feef8b8c3d8f8431f007fdfdfafcaffa145007feef8b8c3d8f8431f007fdfdfafc9ffa196007feef8b8c3d8f8431f007fdfdfafc2ffa3ed007feef8b8c3d8f8431f007fdfdfafc2ffa3ed007feef8b8c3d8f8431f007fdf5fafdeff0179007feef8b8c3d8f8431f007fdfdfaf83ff63e1007feef8b8c3d8f8431f007fdf5fafdaffa16d007feef8b8c3d8f8431f007fdf5fafbbff63f5007feef8b8c3d8f8431f007fdf5fafb6ff43e9007feef8b8c3d8f8431f007fdf5fafb6ff43e9007feef8b8c3d8f8431f007fdf5fb5ffff816f007feef8b8c3d8f8431f007fdfdfafe2ff2171007feef8b8c3d8f8431f007fdf5fafecff2165007feef8b8c3d8f8431f007fdf5fc5ffff417d007feef8b8c3d8f8431f007fdf5fafdfffa1fa007feef8b8c3d8f8431f007fdf5fafdfffa1fa007feef8b8c3d8f8431f007fdfdfafe5ff23c7007feef8b8c3d8f8431f007fdfdfbdf9ff23c7007feef8b8c3d8f8431f007fdfdfd7fcff217e007feef8b8c3d8f8431f007fdfdfaffcff217f007feef8b8c3d8f8431f007fdfdfaff6ff2132007feef8b8c3d8f8431f007fdfdfafebff212b007feef8b8c3d8f8431f007fdfdfafebff212b007feef8b8c3d8f8431f007fdfdfafd6ffa3a9007feef8b8c3d8f8431f007fdfdf3dfbff239d007feef8b8c3d8f8431f007fdfdfafecff239d007feef8b8c3d8f8431f007fdfdfaf8affe3f7007feef8b8c3d8f8431f007fdfdfaf8effe17d007feef8b8c3d8f8431f007fdfdfaf8effe17d007feef8b8c3d8f8431f007fdfdfdffdff235e007feef8b8c3d8f8431f007fdf5f3dfeff2351007feef8b8c3d8f8431f007fdf5f3dfeff2351007feef8b8c3d8f8431f007fdf5fbdfcff2373007feef8b8c3d8f8431f007fdf5ffdfbff2336007feef8b8c3d8f8431f007fdf5f3dfeff2351007feef8b8c3d8f8431f007fdf5f3dfeff2351007feef8b8c3d8f8431f007fdf5f90feff411e007feef8b8c3d8f8431f007fdf5fbdfcff2373007feef8b8c3d8f8431f007fdfdfafd6ffa3a9007feef8b8c3d8f8431f007fdfdfafd6ffa3a9007feef8b8c3d8f8431f007fdfdf5dfdffa3a7007feef8b8c3d8f8431f007fdf5f7dfcff21d2007feef8b8c3d8f8431f007fdfdfaff6ff2132007feef8b8c3d8f8431f007fdfdfeff6ff2132007feef8b8c3d8f8431f007fdf5f7dffff230200
2020.10.20 12:52:23.387 4: infini_test: ParseFrameStart (RTU) extracted id 183, fCode 0 and data 7feef8b8c3d8f8431f007fdfdfafd0ffa3b7007feef8b8c3d8f8431f007fdfdfaf9dff63a6007feef8b8c3d8f8431f007fdfdfaf9dff63a6007feef8b8c3d8f8431f007fdfdfaf9dff63a6007feef8b8c3d8f8431f007fdfdfaf9dff63a6007feef8b8c3d8f8431f007fdf5fafd6ff03d1007feef8b8c3d8f8431f007fdf5fafa4ff438a007feef8b8c3d8f8431f007fdf5fafa4ff43c5007feef8b8c3d8f8431f007fdf5fafb6ffe169007feef8b8c3d8f8431f007fdf5fafb6ffe169007feef8b8c3d8f8431f007fdf5fafb6ffe169007feef8b8c3d8f8431f007fdf5fafddffa3ee007feef8b8c3d8f8431f007fdf5fd7ddffa3ee007feef8b8c3d8f8431f007fdfdfedfcff63ff007feef8b8c3d8f8431f007fdfdfafe8ff2135007feef8b8c3d8f8431f007fdfdfafe8ff2135007feef8b8c3d8f8431f007fdf5f7dfaff2332007feef8b8c3d8f8431f007fdfdfaff7ff231a007feef8b8c3d8f8431f007fdfdf7dffff238a007feef8b8c3d8f8431f007fdfdfffffff09ee007feef8b8c3d8f8431f007fdfdffdfcff231e007feef8b8c3d8f8431f007fdfdffdfcff231e007feef8b8c3d8f8431f007fdf5ffdffff211e007feef8b8c3d8f8431f007fdf5fbdfcff2373007feef8b8c3d8f8431f007fdf5fbdfcff2373007feef8b8c3d8f8431f007fdfdfafcaffa145007feef8b8c3d8f8431f007fdfdfafc9ffa196007feef8b8c3d8f8431f007fdfdfafc2ffa3ed007feef8b8c3d8f8431f007fdfdfafc2ffa3ed007feef8b8c3d8f8431f007fdf5fafdeff0179007feef8b8c3d8f8431f007fdfdfaf83ff63e1007feef8b8c3d8f8431f007fdf5fafdaffa16d007feef8b8c3d8f8431f007fdf5fafbbff63f5007feef8b8c3d8f8431f007fdf5fafb6ff43e9007feef8b8c3d8f8431f007fdf5fafb6ff43e9007feef8b8c3d8f8431f007fdf5fb5ffff816f007feef8b8c3d8f8431f007fdfdfafe2ff2171007feef8b8c3d8f8431f007fdf5fafecff2165007feef8b8c3d8f8431f007fdf5fc5ffff417d007feef8b8c3d8f8431f007fdf5fafdfffa1fa007feef8b8c3d8f8431f007fdf5fafdfffa1fa007feef8b8c3d8f8431f007fdfdfafe5ff23c7007feef8b8c3d8f8431f007fdfdfbdf9ff23c7007feef8b8c3d8f8431f007fdfdfd7fcff217e007feef8b8c3d8f8431f007fdfdfaffcff217f007feef8b8c3d8f8431f007fdfdfaff6ff2132007feef8b8c3d8f8431f007fdfdfafebff212b007feef8b8c3d8f8431f007fdfdfafebff212b007feef8b8c3d8f8431f007fdfdfafd6ffa3a9007feef8b8c3d8f8431f007fdfdf3dfbff239d007feef8b8c3d8f8431f007fdfdfafecff239d007feef8b8c3d8f8431f007fdfdfaf8affe3f7007feef8b8c3d8f8431f007fdfdfaf8effe17d007feef8b8c3d8f8431f007fdfdfaf8effe17d007feef8b8c3d8f8431f007fdfdfdffdff235e007feef8b8c3d8f8431f007fdf5f3dfeff2351007feef8b8c3d8f8431f007fdf5f3dfeff2351007feef8b8c3d8f8431f007fdf5fbdfcff2373007feef8b8c3d8f8431f007fdf5ffdfbff2336007feef8b8c3d8f8431f007fdf5f3dfeff2351007feef8b8c3d8f8431f007fdf5f3dfeff2351007feef8b8c3d8f8431f007fdf5f90feff411e007feef8b8c3d8f8431f007fdf5fbdfcff2373007feef8b8c3d8f8431f007fdfdfafd6ffa3a9007feef8b8c3d8f8431f007fdfdfafd6ffa3a9007feef8b8c3d8f8431f007fdfdf5dfdffa3a7007feef8b8c3d8f8431f007fdf5f7dfcff21d2007feef8b8c3d8f8431f007fdfdfaff6ff2132007feef8b8c3d8f8431f007fdfdfeff6ff2132007feef8b8c3d8f8431f007fdf5f7dffff23
2020.10.20 12:52:23.387 5: infini_test: HandleRequest called from Read
2020.10.20 12:52:23.387 5: infini_test: HandleRequest could not parse request frame yet, wait for more data

Prinzipiell scheint das immer das gleiche zu sein:
feef8b8c3d8f8431f007fdfdfafd0ffa3b7007

Ein Ansatzpunkt, eine Idee, oder ein Tipp würden mir vielleicht schon helfen...
Oder ist das überhaupt kein Modbus?

Danke und viele Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Oktober 2020, 19:34:57
Hallo,

für mich sieht das nicht nach Modbus aus.

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Oktober 2020, 19:41:42
Hallo,

anbei mal wieder eine neue Version des Basis-Moduls.
Es hat jetzt einen eigenen Namespace und einige interne Optimierungen. Falls ein paar Leute Zeit haben, es zu testen, wäre das sehr hilfreich.
Es benötigt die aktuelle Version des Utils-Moduls von HTTPMOD, da ich einige redundante Funktionen von beiden Modulen darin ausgelagert habe.
Das muss entweder per update geholt werden (habe es gerade eingecheckt) oder manuell ins Verzeichnis lib/FHEM/HTTPMOD.
Zudem muss das File modTemplate nach lib/FHEM/Modbus (das ist der neue Rahmen für "set saveAsModule")

Gruss / vielen Dank
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 21 Oktober 2020, 21:07:32
Die neue Version scheint bei mir problemlos zu laufen.

Für die Steuerung meines Wechselrichters möchte ich gerne bei erreichen eines bestimmten Ladezustandes der Batterie keine Antworten mehr auf Modbus-Anfragen senden.
Ich habe herausgefunden, dass das mit dem Attribut "disable" funktioniert.
Allerdings ist das ein bisschen unschön, weil es jedesmal das rote Fragezeichen bei save triggert. Andererseits wird es hoffentlich nicht so oft vorkommen, dass ich den WR abschalten muss.
Die Frage dazu wäre, ob es eine andere Möglichkeit gibt, den Modbus-Slave temporär zu deaktivieren?

Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Heuberg am 21 Oktober 2020, 22:28:19
Hallo Stephan (abc2006),
kleine Frage zu Deinem Vorgehen: Warum möchtest Du den Wechselrichter abschalten, wenn Deine Batterie "voll" ist?

Viele Grüße
Rainer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 22 Oktober 2020, 13:20:54
Hallo zusammen,
das ist zwar OT, aber seis drum :-)

Zitat von: Heuberg am 21 Oktober 2020, 22:28:19
kleine Frage zu Deinem Vorgehen: Warum möchtest Du den Wechselrichter abschalten, wenn Deine Batterie "voll" ist?
Ich vermute, dass der WR mit der Batterie über modBus kommuniziert. Durch das unterbinden dieser Kommunikation würde der WR nicht mehr die Batterie weiter laden.
Das könnte man verwenden, um selber zu bestimmen, wann die Batterie geladen wird.

Zitat
bei erreichen eines bestimmten Ladezustandes
Das bedeutet nicht, dass die Batterie voll ist.

Bei mir hat der WR eine "inteligente" Ladesteuerung und versucht im Sommer das Maximum am Mittag für die Ladung zu verwenden. Dann wird zB 70% ins Netz eingespeist, zusätzlich das Haus versorgt und dann noch die Batterie geladen. Somit erfolgt dann keine Begrenzung der Leistung.

Gruß
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Oktober 2020, 16:58:27
Hallo,

bisher wird alles über Attribute gesteuert und wenn ein Attribut sich ändert, dann bietet Fhem an die Konfiguration zu speichern.
Aber: das Modbus-Modul verwendet die Fhem-Funktion IsDisabled um abzufragen ob das Gerät auf disabled steht. Die prüft nicht nur Attribute sondern auch den State:


return 1 if($attr{$devname}{disable});
return 3 if($defs{$devname} && $defs{$devname}{STATE} &&
              $defs{$devname}{STATE} eq "inactive");
return 3 if(ReadingsVal($devname, "state", "") eq "inactive");


Man könnte mal ausprobieren einfach den State auf inactive zu setzen. Ich hab das noch nicht getestet.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Heuberg am 22 Oktober 2020, 17:17:24
Hallo Christian,

OT hin oder her :-), ich denke es geht hier um die Möglichkeiten des Modbus.
Wenn Du den Modbus vom FHEM her auf "disable" stellst, ist doch nur FHEM "vom Netz". Dein WR unterhält sich dabei weiterhin mit Deiner Batterie, unter der Annahme, daß die beiden sich über Modbus unterhalten und nicht über andere Steuerleitungen.

Das würde doch heißen, Du nimmst Dir nur die Überwachungs- und Steuerungsmöglichkeit von FHEM auf dem Modbus. Die Geräte unterhalten sich weiterhin.

Aus meiner Sicht müßtest Du für Deinen Wunsch genau FHEM dafür nehmen, den WR zu steuern und die Parameter in Deinem Sinne zu verändern, sofern er sich über den Modbus steuern läßt.

Viele Grüße
Rainer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 22 Oktober 2020, 17:26:58
Zitat von: Heuberg am 22 Oktober 2020, 17:17:24
Aus meiner Sicht müßtest Du für Deinen Wunsch genau FHEM dafür nehmen, den WR zu steuern und die Parameter in Deinem Sinne zu verändern, sofern er sich über den Modbus steuern läßt.
Bei mir mache ich das auch so, es war ja nur eine Vermutung, was er versuchen möchte.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 22 Oktober 2020, 17:31:42
Zitat von: StefanStrobel am 20 Oktober 2020, 19:41:42
Hallo,

anbei mal wieder eine neue Version des Basis-Moduls.
......

Hallo Stefan,

das die Module 2017 Versionen haben ist so gewollt ?! Ich werde sie in den nächsten Tagen einmal testen.


Hab es mal getestet: ich nutzte deine Funktionen in diesem Modul (https://github.com/pejonp/FHEM---SolarEdge/tree/master/FHEM)

Zitat
2020.10.22 17:48:48 0: Undefined subroutine &FHEM::SolarEdge::ModbusLD_Initialize called at ./FHEM/98_SolarEdge.pm line 629, <$fh> line 102.

2020.10.22 17:48:48 1: Including ./log/fhem.save
2020.10.22 17:48:48 1: Messages collected while initializing FHEM:configfile: Cannot load module SolarEdge
Please define SEdge 5e9c7d2d-f33f-416a-a25c-8a42e71ede7a0bb6 first
./log/fhem.save: Please define SEdge first

Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Oktober 2020, 19:33:08
Hallo Jörg,

wo siehst Du denn 2017?
bei mir ist das
Zitat
MODULEVERSION  Modbus 4.3 - 27.9.2020

Was den Fehler angeht, so muss ich mir mal das SolarEdge-Modul näher ansehen.
Genau solche Probleme habe ich vermutet / befürchtet. Das Basismodul ist jetzt in einem eigenen Package:

package Modbus;


zur Rückwärtskompatibilität habe ich folgendes eingefügt:

    # special case to be used by legacy Fhem modules built on Modbus ...
    *main::ModbusLD_Initialize = *Modbus::InitializeLD;
    *main::ModbusLD_Define = *Modbus::DefineLDFn;
    *main::ModbusLD_Undef = *Modbus::UndefLDFn;
    *main::ModbusLD_Set = *Modbus::SetLDFn;
    *main::ModbusLD_Get = *Modbus::GetLDFn;
    *main::ModbusLD_Attr = *Modbus::AttrLDFn;
    *main::Modbus_Notify = *Modbus::NotifyFn;


aber wenn das SolarEdge-Modul nach FHEM::SolarEdge::ModbusLD_Initialize sucht, dann kann das natürlich nicht klappen.
Ich poste dann wieder ein Update sobald ich Zeit hatte, mir das anzusehen.

Grus / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 23 Oktober 2020, 08:20:51
Hallo stefan,

In der 2. Zeile hinter der $ID.
Ich schreibe die bei mir immer fortlaufend damit ich meine Versionen auseinanderhalten kann ;-).
Das mit dem Modul schaue ich mir an. Mal sehen ob ich es hinbekomme. Das muss ja mit der vorhandenen und neuen Version laufen.

Gruß Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 23 Oktober 2020, 19:23:12
Hallo Stefan,

wenn ich version auf dem System mache der die Module per update holt, habe ich Version

Zitat
98_Modbus.pm           20182 2019-09-17 12:53:40Z StefanStrobel
98_ModbusAttr.pm       19133 2019-04-06 18:40:30Z StefanStrobel

Wenn ich die Module aus dem Post nehme, habe ich Version

Zitat
98_Modbus.pm      14234 2017-05-09 19:11:34Z StefanStrobel
98_ModbusAttr.pm  13878 2017-04-02 09:12:12Z StefanStrobel

Kannst du mir sagen wie ich die Module einbinden muss ?

Ich habe es so versucht. Habe noch nicht so die Ahnung wie es gehen könnte :-(.


package Modbus;
#package FHEM::SolarEdge;


kommt folgender Fehler.

Zitat
2020.10.23 19:10:05 1: PERL WARNING: Prototype mismatch: sub main::Initialize () vs none at ./FHEM/98_Modbus.pm line 483, <$fh> line 102.
2020.10.23 19:10:05 1: PERL WARNING: Subroutine Initialize redefined at ./FHEM/98_Modbus.pm line 467, <$fh> line 102.
2020.10.23 19:10:05 0: Undefined subroutine &main::SolarEdge_Initialize called at fhem.pl line 2661, <$fh> line 102.

2020.10.23 19:10:05 1: Including ./log/fhem.save
2020.10.23 19:10:05 1: Messages collected while initializing FHEM:configfile: Cannot load module SolarEdge
Please define SEdge 5e9c7d2d-f33f-416a-a25c-8a42e71ede7a0bb6 first
./log/fhem.save: Please define SEdge first

Mit den vom update ausgelieferten Modulen läuft es ja, nur nochnicht mit den neuen. Es eilt hoffentlich noch nicht. Nur weil du gefragt hast, ob es mal jemand testen könnte.

Grüße Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 Oktober 2020, 15:17:48
Hallo Jörg,

die Versionsinformation kommt aus dem $Id in der ersten Zeile des Moduls. Die wird beim Einchecken ins SVN automatisch gesetzt. Eine neue Version, die ich hier poste, ist noch nicht eingecheckt und entsprechend steht etwas altes in der Versionsangabe im Quellcode. Aussagekräftiger ist

$hash->{MODULEVERSION}   = "Modbus $Module_Version";

bzw.

my $Module_Version = '4.3 - 27.9.2020';

das wird als Internal auch angezeigt.

Ich war so frei mal in Deinem Modul herumzueditieren ;-)

diff -u 98_SolarEdge.pm 98_SolarEdge2.pm
--- 98_SolarEdge.pm     2020-10-24 15:05:05.382521481 +0200
+++ 98_SolarEdge2.pm    2020-10-24 15:04:40.139651939 +0200
@@ -36,6 +36,8 @@
# 2020-24-10  unpack angepasst


+#package Modbus;
+package FHEM::SolarEdge;

use strict;
use warnings;
@@ -51,10 +53,6 @@
}


-#package Modbus;
-package FHEM::SolarEdge;
-
-
no if $] >= 5.017011, warnings => 'experimental::smartmatch';
#no warnings 'portable';    # Support for 64-bit ints required
use Time::Local;
@@ -68,8 +66,7 @@

use FHEM::Meta;
main::LoadModule( 'Modbus');
-main::LoadModule( 'ModbusAttr');
-
+#main::LoadModule( 'ModbusAttr');


## Import der FHEM Funktionen
@@ -625,11 +622,11 @@
     #require "$attr{global}{modpath}/FHEM/DevIo.pm";


-    $hash->{DefFn} = \&Define;
-    $hash->{AttrFn}     = \&Attr;
+    #$hash->{DefFn} = \&Define;
+    #$hash->{AttrFn}     = \&Attr;
     $hash->{parseInfo}  = \%SolarEdgeparseInfoAll;    # defines registers for this Modbus Defive
     $hash->{deviceInfo} = \%SolarEdgedeviceInfo;      # defines properties of the device like
-    ModbusLD_Initialize($hash);        # Generic function of the Modbus module does the rest
+    Modbus::InitializeLD($hash);                      # Generic function of the Modbus module does the rest

     $hash->{AttrList} =
         $hash->{AttrList}



package FHEM::SolarEdge ist ok. Du hast ja auch die Initialize-Funktion entsprechend benannt.
Die Zuweisungen zu DefFn und AttrFn sind überflüssig. Darum kümmert sich Modbus::InitializeLD($hash).
Ein Aufrug von ModbusLD_Initialize($hash) sollte zwar noch funktionieren, aber das ist nur eine Alias. Der tatsächliche Name im Modul ist Modbus::InitializeLD.
Das Laden von ModbusAttr ist auch überflüssig.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 25 Oktober 2020, 11:41:05
Hallo Stefan,

ich habe die Änderungen mal eingebaut und getestet. Leider findet er Modbus::InitializeLD nicht. Ich habe die neuen Module auch ins Verzeichnis opt/fhem/FHEM gelegt und die vorhandenen überschrieben und die Rechte angepasst. Leider klapt das aber noch nicht. Vielleicht habe ich auch etwas übersehen.


-    ModbusLD_Initialize($hash);        # Generic function of the Modbus module does the rest
+    Modbus::InitializeLD($hash);                      # Generic function of the Modbus module does the rest


Wenn das funktioniert, sollte das Modul (Version) ja eigentlich egal sein ?!

Ich habe aber noch eine andere Frage. Bei meinem Modul werden 3 verschiedene Geräte abgefragt.
Ich habe nur eine SolarEdge WR (ohne Meter, ohne Batterie). Leider habe ich es noch nicht hinbekommen bzw. es ist jetzt ein Fehler drin das nur die Modbus-Register für den WR angezeigt werde. Ich bekomme jetzt wieder alle Register angezeigt, nur in den anderen steht Schrott.

Jetzt möchte ich 2 Attribute einbauen:

Device_Meter:0,1
Device_Battery:0,1

und darüber das auslesen der Modbus-Register steuern.


  $hash->{AttrList} =
        $hash->{AttrList}
        . "$readingFnAttributes"
        . "Device_Meter:0,1"
        . "Device_Battery:0,1"
        .                                             # Standard Attributes like IODEv etc
      $hash->{ObjAttrList} . " " .     


Die anderen beiden können bei Bedarf zugeschaltet werden. Jetzt ist die Frage wie bekomme ich das hin.
Bis jetzt funktioniert es noch nicht. Die AttrList wird nicht um die beiden Parameter erweitert.



sub Initialize()
{
    my $hash = shift;

    my $modusM = AttrVal($hash->{NAME},'Device_Meter',0);
    my $modusB = AttrVal($hash->{NAME},'Device_Battery',0);
   
    my %SolarEdgeparseInfoAll = ( %SolarEdgeparseInfo);
     
    if ($modusM == 1 && $modusB == 1 ){
        %SolarEdgeparseInfoAll = ( %SolarEdgeparseInfo, %SolarEdgeMeter1parseInfo, %SolarEdgeBat1parseInfo );
    } elsif ( $modusM == 1) {
        %SolarEdgeparseInfoAll = (%SolarEdgeparseInfo, %SolarEdgeMeter1parseInfo);   
    } else {
        %SolarEdgeparseInfoAll = ( %SolarEdgeparseInfo);
    }
   
    # my %SolarEdgeparseInfoAll = ( %SolarEdgeparseInfo, %SolarEdgeMeter1parseInfo, %SolarEdgeBat1parseInfo );
....



Oder gibt es einen anderen Weg. Vielen Dank.

Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Oktober 2020, 09:09:45
Hallo Jörg,

zunächst zu Deiner Frage mit dem Aufruf von InitializeLD:
Es gibt zwei Möglichkeiten:

    main::ModbusLD_Initialize($hash);                 # call alias of Modbus::InitializeLD() to be compatible with old Modbus module
    #Modbus::InitializeLD($hash);                     # this is the long term version: call original name of Initialize function

Ich habe beides nochmal getestet und sofern das neue Modul vorher geladen wird, bekomme ich keine Fehler diesbezüglich.

Allerdings gibt es Fehler mit

sub ExprMppt {
    my ( $hash, $DevName, $ReadingName, $vval_0 , $vval_1 , $vval_2 , $vval_3 , $vval_4 ) = @_;
    return SolarEdge_ExprMppt( $hash, $DevName, $ReadingName, $vval_0 , $vval_1 , $vval_2 , $vval_3 , $vval_4 );
}

sub ExprMeter {
    my ( $hash, $DevName, $ReadingName, $vval_0 , $vval_1 , $vval_2 , $vval_3 , $vval_4 , $vval_5 , $vval_6 , $vval_7 , $vval_8 ) = @_;
    return SolarEdge_ExprMeter( $hash, $DevName, $ReadingName, $vval_0 , $vval_1 , $vval_2 , $vval_3 , $vval_4, $vval_5 , $vval_6 , $vval_7 , $vval_8 );
}

das solltest Du einfach löschen. Die tatsächliche Funktion im Code sollte ohne SolarEdge_ benannt werden.

Durch

GP_Export(
    qw(
      Initialize
      ExprMppt
      ExprMeter
      )
);

werden die eigentlichen Funktionen ExprMppt und ExprMeter (im einem Modul, das ein eigenes Package hat, lässt man die Mudulname_ Präfixes weg) schon als main::SolarEdge_ExprMppt und main:SolarEdge_ExprMeter exportiert. Du müsstest dann aber in den Expressions auch die lange Form SolarEdge_Expr... verwenden, da die Expressions im Kontext des Packages main:: evaluiert werden.

anbei nochmal eine Version Deines Moduls, die bei mir ohne Fehler geladen werden kann. In Betrieb kann ich sie mangels eines SolarEdge-Geräts leider noch nicht testen.
Ich plane noch eine "generateTestdata"-Funktion, mit der man Daten für die Simulation von Geräten für Modul-Tests bereitstellen kann.

Gruss
    Stefan

EDIT: Erklärung mit dem Export war falsch herum. habe es direkt korrigiert um weitere Verwirrung zu vermeiden

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Oktober 2020, 09:16:54
Zur zweiten Frage: parseInfo abhängig von Attributen.

Die Initialize-Funktion wird beim Laden des Moduls aufgerufen. Attribute sind zu diesem Zeitpunkt noch nicht bekannt. Deshalb kann Dein Code auch parseInfo an dieser Stelle nicht erweitern.
Statt dessen müsstest Du das in einer _Attr-Funktion machen und dort aktiv werden, wenn das Attribut gesetzt wird.
In der Initialize-Funktion müsstest Du so etwas wie

$hash->{AttrFn}     = \&SolarEdge_Attr;

einbauen und in SolarEdge_Attr dann auf das neue Attribut prüfen und am Ende Modbus::AttrFn aufrufen, damit die anderen Attribute noch funktionieren.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 26 Oktober 2020, 20:47:29
Hallo Stefan,

vielen Dank für deine Hilfe. Ich habe dein Modul mal auf einem anderen Server getestet. Vorher deine geänderten Dateien eingespielt.
Leider kommen Fehler. Ich hänge mal den Log an. Wenn du Zeit hast könntest du ja mal drüber schauen.

es kommt sehr häufig dieser Hinweis:

2020.10.26 20:39:59 4: SEdge: ParseFrameStart (RTU) extracted id 3, fCode 131 and data 02
2020.10.26 20:39:59 4: SEdge: HandleResponse got response with error code 83 / 02, illegal data address


Vielen Dank.
Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 27 Oktober 2020, 11:53:27
Zitat von: StefanStrobel am 20 Oktober 2020, 19:41:42
Falls ein paar Leute Zeit haben, es zu testen, wäre das sehr hilfreich.


Hallo Stefan,
ich habe die neue Version bei mir laufen.
Nachdem ich heute Modbus deaktivieren musste (mit disable 1), lief es nach dem aktivieren (disable 0) nicht wieder richtig an.
Möglicherweise sendet der WR erstmal Mist, wenn er aus dem Standby aufwacht, und Modbus findet den Anfang nicht richtig.

Ich poste dir mal die Logmeldung:

[code]
2020.10.27 11:48:22.143 5: infini_modbus: ParseFrameStart called from Modbus::ReadFn
2020.10.27 11:48:22.147 4: infini_modbus: ParseFrameStart (RTU) extracted id 5, fCode 0 and data 0104003400023005050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 27 Oktober 2020, 12:03:57
Zitat von: ch.eick am 22 Oktober 2020, 17:26:58
Bei mir mache ich das auch so, es war ja nur eine Vermutung, was er versuchen möchte.

Hallo ihr zwei,

Der Grund, warum ich das machen will, ist ziemlich trivial:

Ich habe folgenden Aufbau
Stromzaehler --> FHEM ---> Wechselrichter

Der Stromzaehler misst den gerade verbrauchten Strom und meldet diesen Wert an FHEM.
FHEM prüft die aktuelle PV-Leistung, den aktuellen Verbrauch und den Ladezustand der Batterien und berechnet daraus eine gewünschte einspeisemenge für den Wechselrichter.
Die Differenz zwischen der gewünschten und der tatsächlichen Einspeisemenge fragt der Wechselrichter per Modbus ab. Eigentlich beim Stromzähler selbst, ich fake diesen mit Hilfe von FHEM. Der Wechselrichter passt daraufhin seine Leistung an.

Wenn die Batterien leer sind (nur um diesen Fall geht es), der Wechselrichter aber weiter einspeist, schalten diese ab, und der WR ist offline.
Selbst wenn die Sonne wieder scheint, erwacht das ganze Ding erst wieder zum Leben, wenn ich die Batterien manuell einschalte (ganz abgesehen davon, dass diese tiefentladung nicht besonders gut ist). Wenn ich negative Werte sende, fängt der WR an, aus dem Stromnetz zu laden (was bei leeren Batterien nachts keine wirtschaftlich sinnvolle Entscheidung ist.
Nun habe ich herausgefunden, dass wenn ich die Verbindung zwischen Wechselrichter und Zähler kappe (was in diesem Fall bedeutet, dass die Anfragen des Wechselrichters einfach "nicht beantwortet" werden, geht der Wechselrichter in einen "Fail Safe-Mode" und schaltet in Standby. Dadurch habe ich keine Einspeisung und keinen Batterieverbrauch mehr, und die Batterien bleiben online, bis die Sonne wieder scheint. Dann lädt der WR die Batterien, und sobald ein akzeptabler Ladezustand erreicht ist, beantworte ich die Anfragen wieder, und der WR speist wieder ein.

Dies schaffe ich mit dem attribut "disable", was allerdings das rote fragezeichen triggert und (siehe mein vorheriger Beitrag) auch noch andere Probleme hervorzurufen scheint.

Hoffe das war nicht zu lang :)

Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 27 Oktober 2020, 12:20:11
Ich habe gerade versucht, mein Modbusattr als Modul zu speichern.
Nachdem ich FHEM neu gestartet habe, kommt der Fehler
Cannot load module ModbusGensdmfake

Das Logfile sagt:
2020.10.27 12:16:58.954 5: infini_modbus: DropFrame - drop 0104003400023005
2020.10.27 12:16:59.749 1: reload: Error:Modul 98_ModbusGensdmfake deactivated:
Unmatched right curly bracket at ./FHEM/98_ModbusGensdmfake.pm line 20, at end of line
syntax error at ./FHEM/98_ModbusGensdmfake.pm line 20, near "(
                      }"
Global symbol "%ModbusGensdmfakedeviceInfo" requires explicit package name (did you forget to declare "my %ModbusGensdmfakedeviceInfo"?) at ./FHEM/98_ModbusGensdmfake.pm line 30.

2020.10.27 12:16:59.754 0: Unmatched right curly bracket at ./FHEM/98_ModbusGensdmfake.pm line 20, at end of line
syntax error at ./FHEM/98_ModbusGensdmfake.pm line 20, near "(
                      }"
Global symbol "%ModbusGensdmfakedeviceInfo" requires explicit package name (did you forget to declare "my %ModbusGensdmfakedeviceInfo"?) at ./FHEM/98_ModbusGensdmfake.pm line 30.

2020.10.27 12:17:00.000 5: infini_modbus: read buffer: 0104003400023005


das generierte Modul hab ich unten angehängt.
Ein List des ModbusAttr:
Internals:
   DEF        1 slave
   FUUID      5f9065ae-f33f-c595-0470-6439b4611fc27d0a
   IODev      infini_modbus
   MODBUSID   1
   MODE       slave
   MODULEVERSION Modbus 4.3 - 27.9.2020
   NAME       modbus
   NOTIFYDEV  global
   NR         29
   NTFY_ORDER 50-modbus
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   READINGS:
     2020-10-27 12:14:30   state           opened
   REMEMBER:
     lsend      1603797551.33764
Attributes:
   disable    0
   obj-i52-len 2
   obj-i52-reading Stromzaehler:4_modbus
   obj-i52-unpack f>1
   userattr   obj-i52-len obj-i52-reading obj-i52-unpack



Wenn du noch Infos brauchst, meld dich.
Grüße,
Stephan

edit:
Die commandref ist für mich an dieser Stelle etwas unklar... Ich vermute zwar, dass ich es richtig gemacht habe, aber wenn du vielleicht ein Beispiel einstellen könntest, wäre das enorm hilfreich.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 27 Oktober 2020, 12:27:09
Zitat von: abc2006 am 27 Oktober 2020, 12:03:57
Dies schaffe ich mit dem attribut "disable", was allerdings das rote fragezeichen triggert
Daher haben heute viele Module ausser dem Attribut disable noch ein set aktiv/inaktiv um temporär das Device lahm zu legen,
entweder bis zum nächsten FHEM Start oder der User setzt es wieder aktiv. ( Bsp notify )
Modul intern kann mann dann in beiden Fällen mit IsDisabled(<name>) schön weiternachen, wäre vllt mal eine Überlegung wert :)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 27 Oktober 2020, 12:46:35
Zitat von: abc2006 am 27 Oktober 2020, 12:03:57
Der Grund, warum ich das machen will, ist ziemlich trivial:
Ich habe folgenden Aufbau
Stromzaehler --> FHEM ---> Wechselrichter
Okay, da bin ich raus, das macht mein WR mit einer Messeinheit alleine. Die Batterie ist bei mir direkt am WR und somit sind die Hersteller auch für das richtige Laden/Entladen verantwortlich.
Bei einer Ladung unter MinSoc, was im Winter passieren kann wird auch eine Notladung  vom WR gesteuert.

Gruß
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 27 Oktober 2020, 14:22:54
Zitat von: StefanStrobel am 22 Oktober 2020, 16:58:27
Man könnte mal ausprobieren einfach den State auf inactive zu setzen. Ich hab das noch nicht getestet.

Das funktioniert leider nicht.

Zitat von: Wzut am 27 Oktober 2020, 12:27:09
entweder bis zum nächsten FHEM Start oder der User setzt es wieder aktiv.
Da muss ich sagen, ich finde es besser, wenn auch das aktivieren dem User überlassen bleibt..

Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 Oktober 2020, 14:44:31
Hallo,

vielen Dank für Euer Testen und Feedback. Ich versuche das der Reihe nach abzuarbeiten :-)

@Jörg: Die Fehlermeldungen und das Log sehen wirklich seltsam aus. Zuerst schickt der Slave immer einen Fehlermeldung und dann kommt die Antwort doch noch, wird dann aber ignoriert. Kann es sein, dass da am Setup etwas nicht stimmt?
Ich tue mich auch mit dem Log schwer. Das ist leider nur mit verbose 4 erstellt und so muss ich an vielen Stellen raten.
kannst Du das nochmal mit verbose 5 machen?

Gruss / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 Oktober 2020, 21:36:14
Hallo,

anbei eine neue Version zum Testen.
Da gibt es auch ein set inactive / set active (nach einem attr enableSetInactive 1).
Der Fehler mit saveAsModule sollte auch behoben sein.

Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD und das File modTemplate nach lib/FHEM/Modbus.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 01 November 2020, 11:01:10
Hi Stefan, erstmal vielen Dank für die Arbeit, die du dir gemacht hast, und genauso vielen Dank für die Umsetzung meiner/unserer Wünsche!
Ich habe die Dateien leider erst heute morgen bei mir einspielen können. Dabei sind mir folgende Punkte aufgefallen und Gedanken gekommen:

a) set .. active/inactive über die Kommandozeile funktioniert, evtl wäre es sinnvoll, dieses noch im dropdown hinzuzufügen.

b) Bei durchsicht des Logfiles habe ich den Eindruck, dass die während "set inactive" eingehenden Anfragen gespeichert werden und nach einem "set active" abgearbeitet werden:

2020.11.01 10:40:38.897 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c1d80000, device infini_modbus_logical (RTU), pdu 0404c1d80000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:39.963 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:39.963 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:39.965 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value -27
2020.11.01 10:40:39.966 5: infini_modbus_logical: PackObj packed -27 with pack code f>1 to c1d80000
2020.11.01 10:40:39.966 5: infini_modbus_logical: PackObj padded / cut object to c1d80000
2020.11.01 10:40:39.966 5: infini_modbus_logical: PackObj full data string is c1d80000
2020.11.01 10:40:39.967 5: infini_modbus_logical: PackObj padded / cut data string to c1d80000
2020.11.01 10:40:39.967 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:39.968 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c1d80000, device infini_modbus_logical (RTU), pdu 0404c1d80000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:41.016 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:41.017 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:41.025 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value -27
2020.11.01 10:40:41.026 5: infini_modbus_logical: PackObj packed -27 with pack code f>1 to c1d80000
2020.11.01 10:40:41.026 5: infini_modbus_logical: PackObj padded / cut object to c1d80000
2020.11.01 10:40:41.027 5: infini_modbus_logical: PackObj full data string is c1d80000
2020.11.01 10:40:41.027 5: infini_modbus_logical: PackObj padded / cut data string to c1d80000
2020.11.01 10:40:41.027 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:41.028 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c1d80000, device infini_modbus_logical (RTU), pdu 0404c1d80000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:42.072 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:42.073 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:42.075 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value -27
2020.11.01 10:40:42.076 5: infini_modbus_logical: PackObj packed -27 with pack code f>1 to c1d80000
2020.11.01 10:40:42.076 5: infini_modbus_logical: PackObj padded / cut object to c1d80000
2020.11.01 10:40:42.077 5: infini_modbus_logical: PackObj full data string is c1d80000
2020.11.01 10:40:42.077 5: infini_modbus_logical: PackObj padded / cut data string to c1d80000
2020.11.01 10:40:42.078 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:42.079 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c1d80000, device infini_modbus_logical (RTU), pdu 0404c1d80000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:42.715 5: infini_modbus_logical: SetState called from Modbus::ControlSet with inactive sets state and STATE to inactive
2020.11.01 10:40:42.718 5: infini_modbus_logical: UnregAtIODev called from Modbus::SetLDInactive
2020.11.01 10:40:42.718 5: infini_modbus_logical: UnregAtIODev is removing infini_modbus_logical from registrations at infini_modbus_physical
2020.11.01 10:40:42.719 5: infini_modbus_logical: UnregAtIODev is removing locks at infini_modbus_physical
2020.11.01 10:40:42.719 5: infini_modbus_logical: UnregAtIODev is removing locks at infini_modbus
2020.11.01 10:40:42.778 5: sendSerialCommand argument ? _Line: 89
2020.11.01 10:40:42.778 5: sendSerialCommand argument fragezeichen _Line:91
2020.11.01 10:40:54.255 5: infini_modbus_logical: SetState called from Modbus::ControlSet with active sets state and STATE to active
2020.11.01 10:40:54.257 3: infini_modbus_logical: RegisterAtIODev called from Modbus::SetLDActive registers infini_modbus_logical at infini_modbus_physical with id 1, MODE slave, PROTOCOL RTU
2020.11.01 10:40:54.257 3: infini_modbus_logical: using infini_modbus_physical for communication
2020.11.01 10:40:54.259 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.260 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.261 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.261 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.262 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.262 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.262 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.263 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.263 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.266 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.266 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.267 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.268 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.268 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.268 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.269 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.269 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.270 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.272 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.273 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.274 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.274 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.274 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.275 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.275 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.275 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.276 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.278 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.279 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.280 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.280 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.281 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.281 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.281 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.281 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.282 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.285 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.285 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.286 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.287 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.287 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.287 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.287 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.288 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.289 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.291 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.291 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.292 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.293 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.293 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.293 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.294 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.294 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.295 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.297 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.298 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.299 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.299 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.300 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.300 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.300 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.300 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.301 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.304 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.304 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.305 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.306 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.306 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.306 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.306 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.307 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.307 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.310 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.310 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.311 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.312 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.312 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.312 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.313 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.313 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.314 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.316 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.317 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.318 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.318 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.318 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.319 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.319 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.319 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.320 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.323 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.323 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.324 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.324 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.325 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.325 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.325 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.325 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.326 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.354 5: sendSerialCommand argument ? _Line: 89
2020.11.01 10:40:54.355 5: sendSerialCommand argument fragezeichen _Line:91
2020.11.01 10:40:54.790 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.790 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.792 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.792 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.792 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.793 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.793 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.793 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.794 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:55.847 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:55.848 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:55.850 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 685
2020.11.01 10:40:55.851 5: infini_modbus_logical: PackObj packed 685 with pack code f>1 to 442b4000
2020.11.01 10:40:55.852 5: infini_modbus_logical: PackObj padded / cut object to 442b4000
2020.11.01 10:40:55.852 5: infini_modbus_logical: PackObj full data string is 442b4000
2020.11.01 10:40:55.853 5: infini_modbus_logical: PackObj padded / cut data string to 442b4000
2020.11.01 10:40:55.853 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:55.854 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 442b4000, device infini_modbus_logical (RTU), pdu 0404442b4000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:56.901 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:56.902 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:56.904 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 691
2020.11.01 10:40:56.905 5: infini_modbus_logical: PackObj packed 691 with pack code f>1 to 442cc000
2020.11.01 10:40:56.906 5: infini_modbus_logical: PackObj padded / cut object to 442cc000
2020.11.01 10:40:56.906 5: infini_modbus_logical: PackObj full data string is 442cc000
2020.11.01 10:40:56.907 5: infini_modbus_logical: PackObj padded / cut data string to 442cc000
2020.11.01 10:40:56.907 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:56.909 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 442cc000, device infini_modbus_logical (RTU), pdu 0404442cc000, V 4.3.2 - 30.10.2020
^C


Ich werde das mal umbauen und über Nacht betreiben. Wenns dann weitere Probleme geben sollte, melde ich mich.

c)
Ich habe das logische Modul (ModbusAttr) auf set .. inactive gesetzt, und danach das noch vorhandene attr disable 0 gelöscht.
Das bewirkte, dass das Modul wieder auf aktiv sprang. Ist ja eigentlich kein Problem, kommt bestimmt auch selten vor. Fiel mir aber auf, ich weiss ja nicht, ob das Absicht oder ein Fehler ist.

Nochmal Danke
Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 November 2020, 12:03:29
Hallo Stephan,

Zitat von: abc2006 am 01 November 2020, 11:01:10
a) set .. active/inactive über die Kommandozeile funktioniert, evtl wäre es sinnvoll, dieses noch im dropdown hinzuzufügen.
Stimmt. kommt in der nächsten Version

Zitat
b) Bei durchsicht des Logfiles habe ich den Eindruck, dass die während "set inactive" eingehenden Anfragen gespeichert werden und nach einem "set active" abgearbeitet werden:
Das macht der Master. Wenn er seinen Slave nicht erreichen kann, bleiben die Anfragen in seiner Queue. Über queueTimeout kann man das aber beeinflussen.
Ein Slave im Zustand disabled oder inactive sollte eingehende Anfragen abweisen. Eine Queue gibt es für eingegangene Anfragen nicht.

Zitat
  • Ich könnte mir vorstellen, dass das bei FHEM Probleme gibt, wenn die Abfragen alle gespeichert werden
Auch das kann man über dropQueueDoubles und queueMax auf Seite des Masters einstellen.

Zitat
  • Ich könnte mir vorstellen, dass das bei FHEM Probleme gibt, wenn die Abfragen alle auf einen Schlag beantwortet werden
Genau. Ein Slave kann daher nur eine Anfrage bearbeiten und ein Master schickt immer nur dann eine neue Anfrage, wenn die alte beantwortet wurde oder in einen Timeout gelaufen ist.

Zitat
  • Ich könnte mir vorstellen, dass das bei diversen Endgeräten Probleme gibt, wenn die Abfragen alle auf einen Schlag beantwortet werden
Für den Master gibt es hier detaillierte Timing-Einstellungen um Probleme zu vermeiden, falls ein Slave nicht schnell genug ist.

Zitat
c)
Ich habe das logische Modul (ModbusAttr) auf set .. inactive gesetzt, und danach das noch vorhandene attr disable 0 gelöscht.
Das bewirkte, dass das Modul wieder auf aktiv sprang. Ist ja eigentlich kein Problem, kommt bestimmt auch selten vor. Fiel mir aber auf, ich weiss ja nicht, ob das Absicht oder ein Fehler ist.
Das ist Absicht. Das Modul merkt sich nicht, welcher Zustand vor einem disable bestand. Inactive ist ja auch kein eigenes Attribut, das gespeichert bleibt, sondern das state-Reading. Disable überschreibt das. Entsprechend kann das Modul nach einem entfernen des disable-Attributs nur zu active wechseln.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 01 November 2020, 12:20:16
Hallo Stefan,
danke für deine Erklärungen. Ich habe dazu noch ein paar Verständnisfragen:

Zitat von: StefanStrobel am 01 November 2020, 12:03:29
Das macht der Master. Wenn er seinen Slave nicht erreichen kann, bleiben die Anfragen in seiner Queue. Über queueTimeout kann man das aber beeinflussen.
Verstehe ich richtig, dass der Master der ist, der abfragt? Also habe ich doch mit
defmod infini_modbus_logical ModbusAttr 1 slave
keinen Master, sondern einen slave?
Das würde ja bedeuten, der Master ist mein Wechselrichter. Den kann ich aber leider nicht beeinflussen...
Ich glaube aber auch nicht, dass der WR eine queue hat.. entweder kommt eine Antwort - oder halt nicht...

Zitat von: StefanStrobel am 01 November 2020, 12:03:29
Ein Slave im Zustand disabled oder inactive sollte eingehende Anfragen abweisen. Eine Queue gibt es für eingegangene Anfragen nicht.
Wie erkläre ich mir dann, dass nach einem set active viele Antworten innerhalb weniger ms gesendet werden, in Abständen die deutlich geringer sind als die Abfragen normalerweise kommen? (siehe Beispiel unten)

Zitat von: StefanStrobel am 01 November 2020, 12:03:29
Ein Slave im Zustand disabled oder inactive sollte eingehende Anfragen abweisen. Eine Queue gibt es für eingegangene Anfragen nicht.
Auch das kann man über dropQueueDoubles und queueMax auf Seite des Masters einstellen.
Ich glaube, ich missverstehe deine definition von "Master"...

Zitat von: StefanStrobel am 01 November 2020, 12:03:29
Genau. Ein Slave kann daher nur eine Anfrage bearbeiten und ein Master schickt immer nur dann eine neue Anfrage, wenn die alte beantwortet wurde oder in einen Timeout gelaufen ist.
Das ist offensichtlich leider nicht so:
Beispiel:
log-auszug direkt nach einem set .. active:
response: id 1, fc 4 i52, len 2, value 41200000
2020.11.01 12:11:58.724 5: infini_modbus_physical: DropFrame - drop 0104003400023005
2020.11.01 12:11:59.351 5: infini_modbus_logical: SetState called from Modbus::ControlSet with inactive sets state and STATE to inactive
2020.11.01 12:11:59.354 5: infini_modbus_logical: UnregAtIODev called from Modbus::SetLDInactive
2020.11.01 12:11:59.354 5: infini_modbus_logical: UnregAtIODev is removing infini_modbus_logical from registrations at infini_modbus_physical
2020.11.01 12:11:59.355 5: infini_modbus_logical: UnregAtIODev is removing locks at infini_modbus_physical
2020.11.01 12:11:59.412 5: sendSerialCommand argument ? _Line: 89
2020.11.01 12:11:59.412 5: sendSerialCommand argument fragezeichen _Line:91
2020.11.01 12:12:07.574 5: infini_modbus_logical: SetState called from Modbus::ControlSet with active sets state and STATE to active
2020.11.01 12:12:07.576 3: infini_modbus_logical: RegisterAtIODev called from Modbus::SetLDActive registers infini_modbus_logical at infini_modbus_physical with id 1, MODE slave, PROTOCOL RTU
2020.11.01 12:12:07.577 3: infini_modbus_logical: using infini_modbus_physical for communication
2020.11.01 12:12:07.578 5: infini_modbus_physical: read buffer: 01040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005
2020.11.01 12:12:07.578 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2020.11.01 12:12:07.579 4: infini_modbus_physical: ParseFrameStart (RTU) extracted id 1, fCode 4 and data 003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002
2020.11.01 12:12:07.579 5: infini_modbus_physical: HandleRequest called from Modbus::ReadFn
2020.11.01 12:12:07.580 5: infini_modbus_physical: ParseRequest called from Modbus::HandleRequest
2020.11.01 12:12:07.580 5: infini_modbus_physical: CheckChecksum (called from Modbus::HandleRequest): 3005 is valid
2020.11.01 12:12:07.581 4: infini_modbus_physical: HandleRequest, current frame / read buffer: 01040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2
2020.11.01 12:12:07.581 5: infini_modbus_physical: GetLogHash returns hash for device infini_modbus_logical
2020.11.01 12:12:07.582 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 12:12:07.582 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 12:12:07.583 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value -2
2020.11.01 12:12:07.584 5: infini_modbus_logical: PackObj packed -2 with pack code f>1 to c0000000
2020.11.01 12:12:07.584 5: infini_modbus_logical: PackObj padded / cut object to c0000000
2020.11.01 12:12:07.584 5: infini_modbus_logical: PackObj full data string is c0000000
2020.11.01 12:12:07.584 5: infini_modbus_logical: PackObj padded / cut data string to c0000000
2020.11.01 12:12:07.585 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 12:12:07.585 5: infini_modbus_physical: PackResponse called from Modbus::CreateResponse
2020.11.01 12:12:07.586 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c0000000, device infini_modbus_logical (RTU), pdu 0404c0000000, V 4.3.2 - 30.10.2020
2020.11.01 12:12:07.586 5: infini_modbus_physical: Send called from Modbus::CreateResponse
2020.11.01 12:12:07.586 5: SW: 010404c0000000c784
2020.11.01 12:12:07.588 4: infini_modbus_physical: RequestDone, current frame / read buffer: 01040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2,

Hier sieht man, dass im read buffer offensichtlich Anfragen angesammelt wurden:

2020.11.01 12:12:07.588 4: infini_modbus_physical: RequestDone, current frame / read buffer: 01040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2,


Normalzustand:

2020.11.01 12:12:08.231 5: infini_modbus_physical: read buffer: 0104003400023005



Ich hoffe, ich denke jetzt nicht völlig in die falsche Richtung... Falls doch, hole mich bitte wieder ins Boot :)

Danke,
Stephan

edit:
ich entnehme aber dem Kontext, dass der Master (also der der Abfragt) mit Fehlverhalten des Slaves klarkommen muss.
Tut er bisher auch - glaube ich.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 November 2020, 20:49:33
Hallo Stephan,

ich hab mir das mal näher angesehen und Du hast recht, da hat etwas nicht so funktioniert wie es sollte. Der Slave hat im inaktiven Zustand die Anfragen nicht wirklich abgewiesen sondern die sind ungelesen im "seriellen Device" liegen geblieben. Ich habe das korrigiert.
Anbei eine neue Version.

Die Definitionen zu "Master" und "Slave" bzw. zum Modbus-Protokoll findest Du übrigens hier: https://modbus.org/specs.php

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 02 November 2020, 08:43:31
Zitat von: StefanStrobel am 01 November 2020, 20:49:33
Hallo Stephan,

ich hab mir das mal näher angesehen und Du hast recht, da hat etwas nicht so funktioniert wie es sollte. Der Slave hat im inaktiven Zustand die Anfragen nicht wirklich abgewiesen sondern die sind ungelesen im "seriellen Device" liegen geblieben. Ich habe das korrigiert.
Anbei eine neue Version.
Guten Morgen,
die neue Version funktioniert.
Ich bin aber nicht sicher, ob die Fehlermeldung etwas irreführend sein könnte:
DropBuffer for Modbus::ReadFn clears the reception buffer with 0104 mode or protocol not set
Ist aber nur ein Unschönheit, tut der Funktion keinen Abbruch.

Zitat von: StefanStrobel am 01 November 2020, 20:49:33
Die Definitionen zu "Master" und "Slave" bzw. zum Modbus-Protokoll findest Du übrigens hier: https://modbus.org/specs.php

Ich fühle mich in meiner Ansicht bestätigt, dass der Wechselrichter der Master ist :)

Danke für deine Arbeit!

Viele Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Hollo am 02 November 2020, 14:39:30
Zitat von: StefanStrobel am 01 November 2020, 20:49:33
...
Die Definitionen zu "Master" und "Slave" bzw. zum Modbus-Protokoll findest Du übrigens hier: https://modbus.org/specs.php
Die Modbus Organisation hat im Übrigen aufgrund der "aktuellen Unruhen und Debatten" Ihre Spec dahingehend geändert,
dass auf die Verwendung der Begriffe "Master" uns "Slave" verzichtet werden soll.
Stattdessen sollen auch hier die Begriffe "Client" und "Server" verwendet werden; wie es bei Modbus TCP eigentlich üblich ist.

Quelle:  https://modbus.org/docs/Client-ServerPR-07-2020-final.docx.pdf (https://modbus.org/docs/Client-ServerPR-07-2020-final.docx.pdf)

Das macht vielleicht auch das Verständnis einfacher...

Slave = Server = stellt Daten zur Verfügung
Master = Client = ruft die Daten ab
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 November 2020, 18:59:21
Puh, ich bin nicht sicher ob ich Spaß daran habe jedes Vorkommen von "Master" im Modul und in der Dokumentation durch "Client" zu ersetzen...  ;)

Gruss
    Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 04 November 2020, 22:03:47
Hi Stefan,
in 98_Modbus.pm ist ein readingsEndUpdate($hash, 0) drin - also ohne Events zu generieren. Dabei geht es um die Profiler-Readings. Ich möchte auf das Update von Profiler_Idle_sum triggern.
Was ist der Grund dieses eine readingsEndUpdate ohne Event auszuführen?
Kannst Du es auf Eventgenerierung (also mit 1) umstellen? (Notfalls durch Attr steuerbar.)

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 November 2020, 18:18:43
Hallo Roger,

hier eine neue Version, die auch für Profiler-Readings Events erzeugt. Ich vermute ich habe das damals ohne Event gemacht, um die Fhem-Last geringer zu halten. Das sollte in diesem Fall aber nicht relevant sein.

Funktioniert das neue Basis-Modul ansonsten mit Deinem Modul?

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 06 November 2020, 21:01:10
Hi Stefan,
die neue Version bringt FHEM zum Absturz  :(.

2020.11.06 20:57:10.444 1: PERL WARNING: Use of uninitialized value $oldE in string ne at /usr/lipo/fhem/FHEM/98_Modbus.pm line 4318, <$fh> line 20.
2020.11.06 20:57:10.445 1: PERL WARNING: Use of uninitialized value $oldE in concatenation (.) or string at /usr/lipo/fhem/FHEM/98_Modbus.pm line 4318, <$fh> line 20.
Undefined subroutine &Modbus::Profiler called at /usr/lipo/fhem/FHEM/98_Modbus.pm line 1748, <$fh> line 20.


//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 November 2020, 21:41:08
Oh, ich sehe schon wo das Problem ist.
Sorry.
Neue Version kommt.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 07 November 2020, 23:15:51
Hallo Stefan,

ich habe die neue Version an meiner Wärmepumpe eingesetzt. Sie läuft zufriedenstellend. Es werden zwei PERL-Warnungen ausgegeben.

Es gibt ein unschönes Verhalten, dem bin ich nachgegangen. Unter bestimmten Voraussetzungen führt das Setzen von Variablen aus einer Map heraus nicht zum Treffer, obwohl die Auswahl aus der Map entnommen vorgegeben wird. Die Ursache liegt in der Funktion MapConvert. Wenn man die Funktion traced ist zu sehen, dass inVal und Map in UTF-8 Codierung vorliegen. Offensichtlich werden Space, die in Map vorhanden sind, im Set-Procedere in nbsp verwandelt (warum auch immer) und erscheinen dann in inVal als nbsp. Damit kann inVal nicht mehr zum Treffer mit Map führen, denn die Strings sind jetzt unterschiedlich. Der Decode verbessert die Bedingungen nicht, vielmehr ist anzunehmen, dass jetzt  der Vergleich wegen unterschiedlicher Codierungen keinesfalls zum Treffer führen kann. Zum Ziel führt nur die Substitution der nbsp durch space in inVal in UTF-8.

Um Überraschungen bei der Reversmap, wenn der hash-key Leerzeichen enthält, vorzubeugen, habe ich die Spaces für den Reversvergleich durch das "?" maskiert.

Ich schlage vor die Funktion wie folgt zu ändern:
sub MapConvert {
    my $hash    = shift;
    my $oRef    = shift;                                        # hash ref for passing options and variables for use in expressions

    my $map            = $oRef->{'map'} // '';                  # map to use
    my $reverse        = $oRef->{'reverse'} // 0;               # use reverse map
    my $action         = $oRef->{'action'} // 'apply map';      # context for logging
    my $UndefIfNoMatch = $oRef->{'undefIfNoMatch'} // 0;        # return undef if map is not matching,
    my $inVal          = $oRef->{'val'} // '';                  # input value
    my $name           = $hash->{NAME};
   
    return $inVal if (!$map);                                   # don't change anyting if map is empty

    my $val = $inVal;                       # subst all nbsp by space
    $map =~ s/\s+/ /g;                                          # substitute all \t \n etc. by one space only       
    $val =~ s/\xc2\xa0/ /g;                                    # subst all nbsp by space

    # spaces in words allowed,     separator is ',' or ':',     hash-key do not allowe spaces
    if ($reverse) { #
        $map =~ s/([^, ][^,\$]*):([^,][^,\$]*),? */$2:$1, /g;   # reverse map
$map =~ s/ /?/g;                                        # mask spaces for hash-key
$val =~ s/ /?/g;                                          # mask spaces for hash-key
$map =~ s/,\?/, /g;                                     # mask spaces for separation
    }

    my %mapHash = split (/, *|:/, $map);                       # reverse hash aus dem reverse string                   

    if (defined($mapHash{$val})) {                                  # Eintrag für den übergebenen Wert in der Map?
        my $newVal = $mapHash{$val};                            # entsprechender Raw-Wert für das Gerät
        Log3 $name, 5, "$name: MapConvert called from " . FhemCaller() . " converted $val to $newVal with" .
        ($reverse ? " reversed" : "") . " map $map";
        return $newVal;
    }
    else {
        Log3 $name, 3, "$name: MapConvert called from " . FhemCaller() . " did not find $val in" .
        ($reverse ? " reversed" : "") . " map $map";
        return if ($UndefIfNoMatch);
        return $inVal;
    }
}


und hier noch der Trace:
2020.11.06 15:46:33 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 2953.
2020.11.06 15:46:33 2: Wi18Tu: MapConvert mit inval <2. Wärmeerzeuger> suchen in Map <Sommer:0, Automatik:1, Urlaub:2, Party:3, 2. Wärmeerzeuger:4, Kühlen:5, >
2020.11.06 15:46:33 2: Wi18Tu: MapConvert inval                 <2. Wärmeerzeuger>   <50 46 194 160 87 195 164 114 109 101 101 114 122 101 117 103 101 114>
2020.11.06 15:46:33 2: Wi18Tu: MapConvert inval nach Decode     <2. W�rmeerzeuger>   <50 46 160 87 228 114 109 101 101 114 122 101 117 103 101 114>>   
2020.11.06 15:46:33 2: Wi18Tu: MapConvert inval nach Substitute <2. W�rmeerzeuger>   <50 46 32 87 228 114 109 101 101 114 122 101 117 103 101 114>   
2020.11.06 15:46:33 2: Wi18Tu: MapConvert Keys   Party Automatik 2. Wärmeerzeuger Kühlen Urlaub Sommer   
2020.11.06 15:46:33 2: Wi18Tu: MapConvert Map   <S  o   m   m   e   r   :  0  , ' ' A  u   t   o   m   a  t   i   k   :  1  , ' ' U  r   l   a  u   b  :  2  , ' ' P  a  r   t   y   :  3  , ' ' 2  . ' ' W  ä       r   m   e   e   r   z   e   u   g   e   r   :  4  , ' ' K  ü       h   l   e   n   :  5  , ' '>
2020.11.06 15:46:33 2: Wi18Tu: MapConvert Keys  <83 111 109 109 101 114 58 48 44 32 65 117 116 111 109 97 116 105 107 58 49 44 32 85 114 108 97 117 98 58 50 44 32 80 97 114 116 121 58 51 44 32 50 46 32 87 195 164 114 109 101 101 114 122 101 117 103 101 114 58 52 44 32 75 195 188 104 108 101 110 58 53 44 32>   
2020.11.06 15:46:33 2: Wi18Tu: MapConvert Values <3 1 4 5 2 0> 
2020.11.06 15:46:33 3: Wi18Tu: MapConvert called from Modbus::FormatSetVal did not find 2. W�rmeerzeuger in reversed map Sommer:0, Automatik:1, Urlaub:2, Party:3, 2. Wärmeerzeuger:4, Kühlen:5,



2020.11.07 00:59:50 3: Opening Wi18Tu device ECS-AP:8899
2020.11.07 00:59:50 0: Featurelevel: 6
2020.11.07 00:59:50 0: Server started with 16 defined entities (fhem.pl:22990/2020-10-19 perl:5.028001 os:linux user:fhem pid:9809)
2020.11.07 00:59:50 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 2953.
2020.11.07 00:59:50 3: Wi18Tu device opened
2020.11.07 00:59:59 2: Wi18Tu: MapConvert mit inval <Automatik> suchen in Map <0:Sommer,1:Automatik,2:Urlaub,3:Party,4:2. Wärmeerzeuger,5:Kühlen>
2020.11.07 00:59:59 2: Wi18Tu: MapConvert inval                 <Automatik>   <65 117 116 111 109 97 116 105 107>
2020.11.07 00:59:59 2: Wi18Tu: MapConvert inval nbsp->space     <Automatik>   <65 117 116 111 109 97 116 105 107>   
2020.11.07 00:59:59 2: Wi18Tu: MapConvert inval nach Substitute <Automatik>   <65 117 116 111 109 97 116 105 107>   
2020.11.07 00:59:59 2: Wi18Tu: MapConvert Keys   <Urlaub Automatik Kühlen 2.?Wärmeerzeuger Party Sommer>   
2020.11.07 00:59:59 2: Wi18Tu: MapConvert Map    <Sommer:0, Automatik:1, Urlaub:2, Party:3, 2.?Wärmeerzeuger:4, Kühlen:5, >
2020.11.07 00:59:59 2: Wi18Tu: MapConvert Keys   <83 111 109 109 101 114 58 48 44 32 65 117 116 111 109 97 116 105 107 58 49 44 32 85 114 108 97 117 98 58 50 44 32 80 97 114 116 121 58 51 44 32 50 46 63 87 195 164 114 109 101 101 114 122 101 117 103 101 114 58 52 44 32 75 195 188 104 108 101 110 58 53 44 32>   
2020.11.07 00:59:59 2: Wi18Tu: MapConvert Values <2 1 5 4 3 0>   
2020.11.07 00:59:59 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3697.
2020.11.07 01:00:05 2: Wi18Tu: MapConvert mit inval <2. Wärmeerzeuger> suchen in Map <0:Sommer,1:Automatik,2:Urlaub,3:Party,4:2. Wärmeerzeuger,5:Kühlen>
2020.11.07 01:00:05 2: Wi18Tu: MapConvert inval                 <2. Wärmeerzeuger>   <50 46 194 160 87 195 164 114 109 101 101 114 122 101 117 103 101 114>
2020.11.07 01:00:05 2: Wi18Tu: MapConvert inval nbsp->space     <2. Wärmeerzeuger>   <50 46 32 87 195 164 114 109 101 101 114 122 101 117 103 101 114>   
2020.11.07 01:00:05 2: Wi18Tu: MapConvert inval nach Substitute <2.?Wärmeerzeuger>   <50 46 63 87 195 164 114 109 101 101 114 122 101 117 103 101 114>   
2020.11.07 01:00:05 2: Wi18Tu: MapConvert Keys   <Urlaub Automatik Kühlen 2.?Wärmeerzeuger Party Sommer>   
2020.11.07 01:00:05 2: Wi18Tu: MapConvert Map    <Sommer:0, Automatik:1, Urlaub:2, Party:3, 2.?Wärmeerzeuger:4, Kühlen:5, >
2020.11.07 01:00:05 2: Wi18Tu: MapConvert Keys   <83 111 109 109 101 114 58 48 44 32 65 117 116 111 109 97 116 105 107 58 49 44 32 85 114 108 97 117 98 58 50 44 32 80 97 114 116 121 58 51 44 32 50 46 63 87 195 164 114 109 101 101 114 122 101 117 103 101 114 58 52 44 32 75 195 188 104 108 101 110 58 53 44 32>   
2020.11.07 01:00:05 2: Wi18Tu: MapConvert Values <2 1 5 4 3 0>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert mit inval <Automatik> suchen in Map <0:Sommer,1:Automatik,2:Urlaub,3:Party,4:2. Wärmeerzeuger,5:Kühlen>
2020.11.07 01:00:12 2: Wi18Tu: MapConvert inval                 <Automatik>   <65 117 116 111 109 97 116 105 107>
2020.11.07 01:00:12 2: Wi18Tu: MapConvert inval nbsp->space     <Automatik>   <65 117 116 111 109 97 116 105 107>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert inval nach Substitute <Automatik>   <65 117 116 111 109 97 116 105 107>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert Keys   <Urlaub Automatik Kühlen 2.?Wärmeerzeuger Party Sommer>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert Map    <Sommer:0, Automatik:1, Urlaub:2, Party:3, 2.?Wärmeerzeuger:4, Kühlen:5, >
2020.11.07 01:00:12 2: Wi18Tu: MapConvert Keys   <83 111 109 109 101 114 58 48 44 32 65 117 116 111 109 97 116 105 107 58 49 44 32 85 114 108 97 117 98 58 50 44 32 80 97 114 116 121 58 51 44 32 50 46 63 87 195 164 114 109 101 101 114 122 101 117 103 101 114 58 52 44 32 75 195 188 104 108 101 110 58 53 44 32>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert Values <2 1 5 4 3 0>   

2020.11.07 01:12:34 3: Opening Wi18Tu device ECS-AP:8899
2020.11.07 01:12:34 0: Featurelevel: 6
2020.11.07 01:12:34 0: Server started with 16 defined entities (fhem.pl:22990/2020-10-19 perl:5.028001 os:linux user:fhem pid:10359)
2020.11.07 01:12:34 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 2953.
2020.11.07 01:12:34 3: Wi18Tu device opened
2020.11.07 01:12:52 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3697.



Weiterhin ist mir aufgefallen, dass der FHEM-reload Befehl die Moduln immer unter ./FHEM/ sucht. Damit besteht keine Chance deine Moduln, die jetzt unter ./lib/ residieren, nachzuladen. Da hilft nur ein Restart.

Viel Grüße
Basil
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 November 2020, 13:38:23
Hallo Basil,

zum Hintergrund der der &nbsp;-Geschichte:
Die Maps werden meist auch als Hints in Fhemweb verwendet, so dass man im Browser-GUI bei einem Set-Befehl aus einer Liste von Werten auswählen kann. Damit das funktioniert, kann das Space-Zeichen nicht einfach so als Hint übergeben werden.
Die damals naheliegende Lösung war das &nbsp;. (siehe MapToHint). Entsprechend muss &nbsp; aus einem Set-Befehl wieder zurück in ein Space gewandelt werden.
Inzwischen scheint sich in Fhemweb etwas geändert zu haben, denn statt dem &nbsp; kommt beim Set ein utf-8 nbsp (\xc2\xa0) zurück.
Zudem macht das decode Ärger mit den Umlauten.
Ich bin dabei das umzubauen und poste eine neue Version sobald ich es testen konnte.

Das mit dem reload ist ein bekanntes Problem mit Bibliotheks-Funktionen.
Das kann ich aber nicht im Modbus-Modul lösen. Daher kommt übrigens auch der Fehler, den Roger gemeldet hat. Nach einem Neustart (wenn auch die Utils neu geladen sind), sollte kein Undefined subroutine &Modbus::Profiler mehr kommen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 November 2020, 16:55:06
Hier eine neue Version, bei der kein decode mehr auf set -Werte gemacht wird und auch utf8-nbsp vor Anwendung einer Map in ein normales Space gewandelt wird.
Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD und wird erst beim Neustart von Fhem geladen.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 08 November 2020, 17:36:51
Hi Stefan,

Zitat von: StefanStrobel am 08 November 2020, 13:38:23
Das mit dem reload ist ein bekanntes Problem mit Bibliotheks-Funktionen.
Das kann ich aber nicht im Modbus-Modul lösen. Daher kommt übrigens auch der Fehler, den Roger gemeldet hat. Nach einem Neustart (wenn auch die Utils neu geladen sind), sollte kein Undefined subroutine &Modbus::Profiler mehr kommen.
Ich hatte einen anderen Fehler. Ich hatte nicht mitbekommen, das Utils.pm nicht nach FHEM kommt.  >:(
Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD
Allerdings habe ich es nach FHEM/lib/HTTPMOD kopiert. War das richtig?
Damit stürzt FHEM beim Start zumindest nicht mehr ab.

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 November 2020, 19:28:14
Hallo Roger,

Utils.pm gehört nach lib/FHEM/HTTPMOD.
Da sind Funktionen drin, die HTTPMOD, Modbus und künftig noch andere Module gemeinsam nutzen.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 09 November 2020, 13:45:22
Hi Stefan,
auch es gibt ja auch zwei lib-Verzeichnisse:
- lib/FHEM/...
- FHEM/lib/...
Warum auch immer.

Die neue Utils.pm habe nun nach lib/FHEM/HTTPMOD kopiert.

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 10 November 2020, 10:12:16
Hallo,

ich wollte nur mal kurz loswerden, dass ich gestern ein völlig unbenutzbares fhem hatte und das kam so:

Ich habe einen Temperatur/Feuchte Sensor, der per Modbus abfragbar ist. Dieser hängt an einem Serial - USB Adapter. Dieser steckt wiederum an einem raspi auf dem ser2net läuft. Der fhem Server bzw. das Modbus-Modul greift über Netzwerk auf ser2net zu. Das Konstrukt läuft seit über einem Jahr problemlos. Jetzt hatte ich offenbar ein Problem bei der USB-Verbindung des Serial-USB-Adapters. Das hatte zur Folge, dass der Port auf dem raspi mit dem ser2net wohl nicht mehr zu öffnen war, der pi selbst war aber noch online. fhem-seitig ist dann aber das MODUS-Device Amok gelaufen und hat im Millisekunden-Abstand versucht, den Port wieder zu öffnen (und dabei natürlich auch das Log geflutet etc.). Letztendlich hat das dann die ganze fhem-Installation in die Knie gezwungen, inklusive Heizungssteuerung (fröstel). Ich hätte eigentlich erwartet, das so etwas nicht passiert, insbesondere wenn maxTimeoutsToReconnect und nextOpenDelay gesetzt sind.  Vielleicht kann da ja mal jemand an die entscheidenen Stellen im Code kritisch anschauen bzw. das auch mal nachstellen mit einem ser2net. Wahrscheinlich kann man das sogar reproduzieren, wenn man das ser2net per loopback direkt auf dem fhem-Server verwendet. Ich hänge ein List an. Soll natürlich keine Kritik an dem ansonsten tollen Modul und der vielen Arbeit sein, die da rein gesteckt wurde.

Mein Modbus-Device:


Internals:
   DEF        1 60 192.168.178.135:2002 RTU
   DeviceName 192.168.178.135:2002
   EXPECT     idle
   FD         204
   FUUID      5d8cc401-f33f-6385-e4cd-4cdd0c0360cf282b
   INTERVAL   60
   IODev      PKTH400A
   LASTOPEN   1604941486.48958
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       PKTH400A
   NOTIFYDEV  global
   NR         759
   NTFY_ORDER 50-PKTH400A
   PARTIAL   
   PROTOCOL   RTU
   STATE      18.5 °C 86 %
   TCPConn    1
   TRIGGERTIME 1604998345.19715
   TRIGGERTIME_FMT 2020-11-10 09:52:25
   TRIGGERTIME_SAVED
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1604998285.19715
   nextOpenDelay 40
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2020-11-10 09:09:10   dewpoint        16.2
     2020-11-10 09:51:27   humidity        86.4
     2020-11-09 18:04:46   state           opened
     2020-11-10 09:51:25   temperature     18.5
   REMEMBER:
     lid        1
     lname      PKTH400A
     lrecv      1604998287.4279
     lsend      1604998286.64982
   defptr:
     PKTH400A   1
   gotReadings:
     humidity   86.4
   lastRead:
     h0         1604998285.97811
     h1         1604998287.42992
Attributes:
   alias      Estrich
   dev-h-defPoll 1
   disable    0
   event-aggregator temperature:6000:linear:mean,humidity:6000:linear:mean
   event-min-interval state:6000,temperature:6000,humidity:6000
   event-on-change-reading humidity,temperature
   group      Temperatur
   icon       scene_swimming
   maxTimeoutsToReconnect 100
   nextOpenDelay 40
   obj-h0-expr $val / 10
   obj-h0-reading temperature
   obj-h1-expr $val / 10
   obj-h1-reading humidity
   openTimeout 20
   room       Keller,Modbus
   sortby     Z99
   stateFormat {sprintf( "%.1f °C %.0f %%",ReadingsVal($name,"temperature",0),ReadingsVal($name,"humidity",0))}
   userattr   dev-h-defPoll obj-h0-expr obj-h0-reading obj-h1-expr obj-h1-reading obj-h2-reading


ser2net.conf:


BANNER:banner:\r\nser2net port \p device \d [\s] (Debian GNU/Linux)\r\n\r\n
# ModBus
2002:raw:0:/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0:9600 1STOPBIT 8DATABITS HANGUP_WHEN_DONE


Grüße, gadget
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 November 2020, 19:51:45
Hallo Gadget,

was kam denn im Log in dieser Zeit?
Könntest Du da mal einen Ausschnitt posten?

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 14 November 2020, 17:25:25
Hallo,

das sind die Logeinträge von 2 Sekunden


2020.11.09 17:56:55 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:56 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:57 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:57 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:57 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:57 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:57 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:57 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:57 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:57 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:57 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:57 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:57 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:57 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:57 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:57 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:57 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:57 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:57 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:57 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:58 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:58 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:58 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:58 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:58 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:58 3: 192.168.178.135:2002 reappeared (PKTH400A)
2020.11.09 17:56:58 3: PKTH400A: read got new data while idle, drop buffer 506f727420616c726561647920696e207573650d0a
2020.11.09 17:56:58 3: 192.168.178.135:2002 disconnected, waiting to reappear (PKTH400A)
2020.11.09 17:56:58 3: 192.168.178.135:2002 reappeared (PKTH400A)


Grüße, gadget
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 15 November 2020, 15:24:53
Hallo Gadget,

danke für das Log.
Ich werde mal auf die Suche gehen.
Falls Du eine Test-Config posten kannst, mit der man das Problem nachvollziehen kann, wäre das natürlich sehr hilfreich.

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 16 November 2020, 11:52:05
Wäre super wenn Du da was finden würdest.
Nachstellen wäre denke ich am einfachsten, wenn man einen USB-Adapter, der direkt am fhem-Server hängt, statt direkt vom Modul über ser2net per loopback (127.0.0.1) zugreift, also statt


define modbus Modbus /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@9600,8,N,1
attr modbus ModbusAttr 1 60



den Stick an ser2net betreiben



apt-get install ser2net

nano /etc/ser2net.conf :

2002:raw:0:/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0:9600 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
systemctl enable ser2net
systemctl start ser2net
systemctl status ser2net


und den define ändern in


define modbus Modbus 1 60 127.0.0.1:2002 RTU



Damit sollte erst mal alles normal weiterlaufen. Wenn man nun den Stick abzieht (und ggf. auch den pi durchstartet) müsste das ungewünschte Verhalten auftreten.

Grüße, gadget
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 November 2020, 19:19:22
Hallo Gadget,

ich konnte das Phänomen nachstellen.
Das Problem ist dass ser2net in dieser Situation die TCP-Verbindung von Fhem akzeptiert und dann sofort wieder schließt.
Der Parameter nextOpenDelay greift hier nicht, weil die Verbindung ja erfolgreich aufgebaut wurde.
Es gibt viele Konfigurationen, in denen das Modbus-Modul bei Verlust der TCP-Verbindung diese sofort wieder aufbauen soll. daher ist die Lösung nicht so ganz offensichtlich. Bin noch am überlegen, wie man das ohne andere Seiteneffeke verhindern könnte...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: killah78 am 18 November 2020, 09:50:05
Hi kurze Frage:
Ich habe mehrere Modbus Devices eingebunden mit ModbusAttr.
Wenn ich apptime starte, bekomme ich keine Modbus Antworten mehr.
Erst nach einem FHEM Neustart kommen wieder Modbus Nachrichten.
Kann das jemand bestätigen? Oder habe ich ein lokales Problem?

Gruss
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 November 2020, 17:37:14
Hallo,

mir ist das Problem nicht bekannt.
Poste doch mal die genaue Konfiguration und wie man das Problem nachstellen kann.
Am besten auch einen Log-Auszug mit verbose 5 für die Modbus-Geräte.

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: killah78 am 20 November 2020, 11:12:27
Hallo Stefan

hier ein Verbose5 von dem Gerät "KSEM" vor dem Aufruf von apptime. In den letzten 2 Zeilen sieht man eine Warning vom Starten von Apptime.

2020.11.20 10:53:00.519 5: KSEM: GetUpdate called from HandleTimeout
2020.11.20 10:53:00.519 5: KSEM: SetartUpdateTimer called from GetUpdate updated timer, will call GetUpdate in 30.0 sec at 2020-11-20 10:53:30, interval 30
2020.11.20 10:53:00.520 5: KSEM: GetUpdate objects from attributes: h42 h40 h0 h122 h752 h592 h512 h596 h756 h672 h516 h120 h82 h80 h2 h676
2020.11.20 10:53:00.520 5: KSEM: GetUpdate full object list: h0 h120 h122 h2 h40 h42 h512 h516 h592 h596 h672 h676 h752 h756 h80 h82
2020.11.20 10:53:00.520 5: KSEM: GetUpdate check h0 => Active_Power_total_+_W, poll = 1, last = 0
2020.11.20 10:53:00.520 4: KSEM: GetUpdate will request Active_Power_total_+_W
2020.11.20 10:53:00.520 5: KSEM: GetUpdate check h120 => Active_Power_L3_+_W, poll = 1, last = 1605865965.65916
2020.11.20 10:53:00.520 4: KSEM: GetUpdate will request Active_Power_L3_+_W
2020.11.20 10:53:00.520 5: KSEM: GetUpdate check h122 => Active_Power_L3_-_W, poll = 1, last = 0
2020.11.20 10:53:00.521 4: KSEM: GetUpdate will request Active_Power_L3_-_W
2020.11.20 10:53:00.521 5: KSEM: GetUpdate check h2 => Active_Power_total_-_W, poll = 1, last = 1605865969.87493
2020.11.20 10:53:00.521 4: KSEM: GetUpdate will request Active_Power_total_-_W
2020.11.20 10:53:00.521 5: KSEM: GetUpdate check h40 => Active_Power_L1_+_W, poll = 1, last = 1605865954.69412
2020.11.20 10:53:00.521 4: KSEM: GetUpdate will request Active_Power_L1_+_W
2020.11.20 10:53:00.521 5: KSEM: GetUpdate check h42 => Active_Power_L1_-_W, poll = 1, last = 1605865968.64777
2020.11.20 10:53:00.521 4: KSEM: GetUpdate will request Active_Power_L1_-_W
2020.11.20 10:53:00.521 5: KSEM: GetUpdate check h512 => Active_Energy_total_+_Wh, poll = 1, last = 1605865958.145
2020.11.20 10:53:00.521 4: KSEM: GetUpdate will request Active_Energy_total_+_Wh
2020.11.20 10:53:00.522 5: KSEM: GetUpdate check h516 => Active_Energy_total_-_Wh, poll = 1, last = 1605865970.30209
2020.11.20 10:53:00.522 4: KSEM: GetUpdate will request Active_Energy_total_-_Wh
2020.11.20 10:53:00.522 5: KSEM: GetUpdate check h592 => Active_Energy_L1_+_Wh, poll = 1, last = 1605865969.15706
2020.11.20 10:53:00.522 4: KSEM: GetUpdate will request Active_Energy_L1_+_Wh
2020.11.20 10:53:00.522 5: KSEM: GetUpdate check h596 => Active_Energy_L1_-_Wh, poll = 1, last = 1605865970.48032
2020.11.20 10:53:00.522 4: KSEM: GetUpdate will request Active_Energy_L1_-_Wh
2020.11.20 10:53:00.522 5: KSEM: GetUpdate check h672 => Active_Energy_L2_+_Wh, poll = 1, last = 1605865969.3816
2020.11.20 10:53:00.522 4: KSEM: GetUpdate will request Active_Energy_L2_+_Wh
2020.11.20 10:53:00.522 5: KSEM: GetUpdate check h676 => Active_Energy_L2_-_Wh, poll = 1, last = 1605865968.84743
2020.11.20 10:53:00.522 4: KSEM: GetUpdate will request Active_Energy_L2_-_Wh
2020.11.20 10:53:00.523 5: KSEM: GetUpdate check h752 => Active_Energy_L3_+_Wh, poll = 1, last = 1605865969.71687
2020.11.20 10:53:00.523 4: KSEM: GetUpdate will request Active_Energy_L3_+_Wh
2020.11.20 10:53:00.523 5: KSEM: GetUpdate check h756 => Active_Energy_L3_-_Wh, poll = 1, last = 1605865954.27527
2020.11.20 10:53:00.523 4: KSEM: GetUpdate will request Active_Energy_L3_-_Wh
2020.11.20 10:53:00.523 5: KSEM: GetUpdate check h80 => Active_Power_L2_P_W, poll = 1, last = 1605865966.42502
2020.11.20 10:53:00.523 4: KSEM: GetUpdate will request Active_Power_L2_P_W
2020.11.20 10:53:00.523 5: KSEM: GetUpdate check h82 => Active_Power_L2_-_W, poll = 1, last = 1605865970.0956
2020.11.20 10:53:00.523 4: KSEM: GetUpdate will request Active_Power_L2_-_W
2020.11.20 10:53:00.523 5: KSEM: GetUpdate tries to combine read commands
2020.11.20 10:53:00.524 5: KSEM: GetUpdate cant combine request for Active_Power_total_+_W / h0 with Active_Power_total_-_W / h2, span 4 > max 1
2020.11.20 10:53:00.524 5: KSEM: GetUpdate cant combine request for Active_Power_total_-_W / h2 with Active_Power_L1_+_W / h40, span 40 > max 1
2020.11.20 10:53:00.524 5: KSEM: GetUpdate cant combine request for Active_Power_L1_+_W / h40 with Active_Power_L1_-_W / h42, span 4 > max 1
2020.11.20 10:53:00.524 5: KSEM: GetUpdate cant combine request for Active_Power_L1_-_W / h42 with Active_Power_L2_P_W / h80, span 40 > max 1
2020.11.20 10:53:00.524 5: KSEM: GetUpdate cant combine request for Active_Power_L2_P_W / h80 with Active_Power_L2_-_W / h82, span 4 > max 1
2020.11.20 10:53:00.524 5: KSEM: GetUpdate cant combine request for Active_Power_L2_-_W / h82 with Active_Power_L3_+_W / h120, span 40 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Power_L3_+_W / h120 with Active_Power_L3_-_W / h122, span 4 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Power_L3_-_W / h122 with Active_Energy_total_+_Wh / h512, span 394 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Energy_total_+_Wh / h512 with Active_Energy_total_-_Wh / h516, span 8 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Energy_total_-_Wh / h516 with Active_Energy_L1_+_Wh / h592, span 80 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Energy_L1_+_Wh / h592 with Active_Energy_L1_-_Wh / h596, span 8 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Energy_L1_-_Wh / h596 with Active_Energy_L2_+_Wh / h672, span 80 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Energy_L2_+_Wh / h672 with Active_Energy_L2_-_Wh / h676, span 8 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Energy_L2_-_Wh / h676 with Active_Energy_L3_+_Wh / h752, span 80 > max 1
2020.11.20 10:53:00.525 5: KSEM: GetUpdate cant combine request for Active_Energy_L3_+_Wh / h752 with Active_Energy_L3_-_Wh / h756, span 8 > max 1
2020.11.20 10:53:00.526 5: KSEM: GetUpdate doesn't sort objList before sending requests
2020.11.20 10:53:00.526 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 52, type h, adr 592, len 4 for device KSEM reading Active_Energy_L1_+_Wh (getUpdate), read buffer empty
2020.11.20 10:53:00.526 5: KSEM: QueueRequest called from DoRequest (KSEM) with h592, qlen 0
2020.11.20 10:53:00.526 4: KSEM: ProcessRequestQueue called from QueueRequest, qlen 1, next entry to id 1 (KSEM), last send to this device was 10.120 secs ago, last read 10.048 secs ago, last read on bus 10.048 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.527 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:52:50.478) for KSEM, delay 9.949secs over
2020.11.20 10:53:00.527 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:52:50.407) for KSEM, delay 10.020secs over
2020.11.20 10:53:00.527 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 003400000006010302500004 request: id 1, fCode 3, tid 52, type h, adr 592, len 4 for device KSEM reading Active_Energy_L1_+_Wh (getUpdate), queued 0.00 secs ago, read buffer empty
2020.11.20 10:53:00.527 5: SW: 003400000006010302500004
2020.11.20 10:53:00.529 5: KSEM: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2020.11.20 10:53:00.530 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 41, type h, adr 676, len 4 for device KSEM reading Active_Energy_L2_-_Wh (getUpdate), read buffer empty
2020.11.20 10:53:00.530 5: KSEM: QueueRequest called from DoRequest (KSEM) with h676, qlen 0
2020.11.20 10:53:00.530 5: KSEM: StartQueueTimer called form QueueRequest sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:00.530 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 108, type h, adr 120, len 2 for device KSEM reading Active_Power_L3_+_W (getUpdate), read buffer empty
2020.11.20 10:53:00.531 5: KSEM: QueueRequest called from DoRequest (KSEM) with h120, qlen 1
2020.11.20 10:53:00.531 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 175, type h, adr 0, len 2 for device KSEM reading Active_Power_total_+_W (getUpdate), read buffer empty
2020.11.20 10:53:00.531 5: KSEM: QueueRequest called from DoRequest (KSEM) with h0, qlen 2
2020.11.20 10:53:00.532 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 119, type h, adr 2, len 2 for device KSEM reading Active_Power_total_-_W (getUpdate), read buffer empty
2020.11.20 10:53:00.532 5: KSEM: QueueRequest called from DoRequest (KSEM) with h2, qlen 3
2020.11.20 10:53:00.532 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 47, type h, adr 512, len 4 for device KSEM reading Active_Energy_total_+_Wh (getUpdate), read buffer empty
2020.11.20 10:53:00.532 5: KSEM: QueueRequest called from DoRequest (KSEM) with h512, qlen 4
2020.11.20 10:53:00.532 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 230, type h, adr 122, len 2 for device KSEM reading Active_Power_L3_-_W (getUpdate), read buffer empty
2020.11.20 10:53:00.533 5: KSEM: QueueRequest called from DoRequest (KSEM) with h122, qlen 5
2020.11.20 10:53:00.533 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 173, type h, adr 82, len 2 for device KSEM reading Active_Power_L2_-_W (getUpdate), read buffer empty
2020.11.20 10:53:00.533 5: KSEM: QueueRequest called from DoRequest (KSEM) with h82, qlen 6
2020.11.20 10:53:00.533 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 188, type h, adr 42, len 2 for device KSEM reading Active_Power_L1_-_W (getUpdate), read buffer empty
2020.11.20 10:53:00.533 5: KSEM: QueueRequest called from DoRequest (KSEM) with h42, qlen 7
2020.11.20 10:53:00.534 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 207, type h, adr 672, len 4 for device KSEM reading Active_Energy_L2_+_Wh (getUpdate), read buffer empty
2020.11.20 10:53:00.534 5: KSEM: QueueRequest called from DoRequest (KSEM) with h672, qlen 8
2020.11.20 10:53:00.534 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 171, type h, adr 756, len 4 for device KSEM reading Active_Energy_L3_-_Wh (getUpdate), read buffer empty
2020.11.20 10:53:00.534 5: KSEM: QueueRequest called from DoRequest (KSEM) with h756, qlen 9
2020.11.20 10:53:00.534 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 148, type h, adr 752, len 4 for device KSEM reading Active_Energy_L3_+_Wh (getUpdate), read buffer empty
2020.11.20 10:53:00.535 5: KSEM: QueueRequest called from DoRequest (KSEM) with h752, qlen 10
2020.11.20 10:53:00.535 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 138, type h, adr 596, len 4 for device KSEM reading Active_Energy_L1_-_Wh (getUpdate), read buffer empty
2020.11.20 10:53:00.535 5: KSEM: QueueRequest called from DoRequest (KSEM) with h596, qlen 11
2020.11.20 10:53:00.535 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 59, type h, adr 516, len 4 for device KSEM reading Active_Energy_total_-_Wh (getUpdate), read buffer empty
2020.11.20 10:53:00.535 5: KSEM: QueueRequest called from DoRequest (KSEM) with h516, qlen 12
2020.11.20 10:53:00.536 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 182, type h, adr 40, len 2 for device KSEM reading Active_Power_L1_+_W (getUpdate), read buffer empty
2020.11.20 10:53:00.536 5: KSEM: QueueRequest called from DoRequest (KSEM) with h40, qlen 13
2020.11.20 10:53:00.536 4: KSEM: DoRequest called from GetUpdate created request: id 1, fCode 3, tid 252, type h, adr 80, len 2 for device KSEM reading Active_Power_L2_P_W (getUpdate), read buffer empty
2020.11.20 10:53:00.536 5: KSEM: QueueRequest called from DoRequest (KSEM) with h80, qlen 14
2020.11.20 10:53:00.537 5: KSEM: read buffer: 00340000000b0103080000000000abca2d
2020.11.20 10:53:00.537 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 52, dlen 11 and data 080000000000abca2d
2020.11.20 10:53:00.537 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:00.538 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:00.538 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:00.538 5: KSEM: ParseObj called with data 0000000000abca2d, type h, adr 592, valuesLen 4, op read
2020.11.20 10:53:00.538 5: KSEM: ParseObj ObjInfo for h592: reading=Active_Energy_L1_+_Wh, unpack=Q>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:00.539 5: KSEM: ParseObj unpacked 0000000000abca2d with Q> to 11258413 hex 3131323538343133
2020.11.20 10:53:00.539 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Energy_L1_+_Wh, val=11258413, expr=$val / 10
2020.11.20 10:53:00.539 5: KSEM: CheckEval for ParseObj result is 1125841.3
2020.11.20 10:53:00.539 5: KSEM: ParseObj for Active_Energy_L1_+_Wh does sprintf with format %.2f, value is 1125841.3
2020.11.20 10:53:00.539 5: KSEM: ParseObj for Active_Energy_L1_+_Wh sprintf result is 1125841.30
2020.11.20 10:53:00.539 4: KSEM: ParseObj assigns value 1125841.30 to Active_Energy_L1_+_Wh
2020.11.20 10:53:00.572 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:00.574 4: KSEM: ResponseDone request: id 1, fCode 3, tid 52, type h, adr 592, len 4 for device KSEM reading Active_Energy_L1_+_Wh (getUpdate), queued 0.05 secs ago, sent 0.05 secs ago, Current read buffer: 00340000000b0103080000000000abca2d, Id 1, fCode 3, tid 52, response: id 1, fCode 3, type h, adr 592, len 4, value 0000000000abca2d
2020.11.20 10:53:00.574 5: KSEM: DropFrame - drop 00340000000b0103080000000000abca2d
2020.11.20 10:53:00.575 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:00.577 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 15, next entry to id 1 (KSEM), last send to this device was 0.048 secs ago, last read 0.039 secs ago, last read on bus 0.039 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.577 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.538) for KSEM, rest 0.061, set timer to try again later
2020.11.20 10:53:00.577 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.061 seconds
2020.11.20 10:53:00.640 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 15, next entry to id 1 (KSEM), last send to this device was 0.111 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.640 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.538) for KSEM, delay 0.003secs over
2020.11.20 10:53:00.640 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:00.529) for KSEM, delay 0.012secs over
2020.11.20 10:53:00.641 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 15, sending 002900000006010302a40004 request: id 1, fCode 3, tid 41, type h, adr 676, len 4 for device KSEM reading Active_Energy_L2_-_Wh (getUpdate), queued 0.11 secs ago, read buffer empty
2020.11.20 10:53:00.641 5: SW: 002900000006010302a40004
2020.11.20 10:53:00.643 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:00.643 5: KSEM: read buffer: 00290000000b01030800000000007f10c5
2020.11.20 10:53:00.644 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 41, dlen 11 and data 0800000000007f10c5
2020.11.20 10:53:00.644 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:00.644 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:00.644 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:00.644 5: KSEM: ParseObj called with data 00000000007f10c5, type h, adr 676, valuesLen 4, op read
2020.11.20 10:53:00.645 5: KSEM: ParseObj ObjInfo for h676: reading=Active_Energy_L2_-_Wh, unpack=Q>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:00.645 5: KSEM: ParseObj unpacked 00000000007f10c5 with Q> to 8327365 hex 38333237333635
2020.11.20 10:53:00.645 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Energy_L2_-_Wh, val=8327365, expr=$val / 10
2020.11.20 10:53:00.645 5: KSEM: CheckEval for ParseObj result is 832736.5
2020.11.20 10:53:00.645 5: KSEM: ParseObj for Active_Energy_L2_-_Wh does sprintf with format %.2f, value is 832736.5
2020.11.20 10:53:00.645 5: KSEM: ParseObj for Active_Energy_L2_-_Wh sprintf result is 832736.50
2020.11.20 10:53:00.645 4: KSEM: ParseObj assigns value 832736.50 to Active_Energy_L2_-_Wh
2020.11.20 10:53:00.675 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:00.675 4: KSEM: ResponseDone request: id 1, fCode 3, tid 41, type h, adr 676, len 4 for device KSEM reading Active_Energy_L2_-_Wh (getUpdate), queued 0.15 secs ago, sent 0.04 secs ago, Current read buffer: 00290000000b01030800000000007f10c5, Id 1, fCode 3, tid 41, response: id 1, fCode 3, type h, adr 676, len 4, value 00000000007f10c5
2020.11.20 10:53:00.675 5: KSEM: DropFrame - drop 00290000000b01030800000000007f10c5
2020.11.20 10:53:00.676 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:00.678 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 14, next entry to id 1 (KSEM), last send to this device was 0.035 secs ago, last read 0.034 secs ago, last read on bus 0.034 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.678 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.644) for KSEM, rest 0.066, set timer to try again later
2020.11.20 10:53:00.678 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.066 seconds
2020.11.20 10:53:00.746 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 14, next entry to id 1 (KSEM), last send to this device was 0.104 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.746 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.644) for KSEM, delay 0.003secs over
2020.11.20 10:53:00.747 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:00.642) for KSEM, delay 0.005secs over
2020.11.20 10:53:00.747 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 14, sending 006c00000006010300780002 request: id 1, fCode 3, tid 108, type h, adr 120, len 2 for device KSEM reading Active_Power_L3_+_W (getUpdate), queued 0.22 secs ago, read buffer empty
2020.11.20 10:53:00.747 5: SW: 006c00000006010300780002
2020.11.20 10:53:00.749 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:00.749 5: KSEM: read buffer: 006c0000000701030400000000
2020.11.20 10:53:00.750 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 108, dlen 7 and data 0400000000
2020.11.20 10:53:00.750 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:00.750 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:00.750 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:00.750 5: KSEM: ParseObj called with data 00000000, type h, adr 120, valuesLen 2, op read
2020.11.20 10:53:00.751 5: KSEM: ParseObj ObjInfo for h120: reading=Active_Power_L3_+_W, unpack=I>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:00.751 5: KSEM: ParseObj unpacked 00000000 with I> to 0 hex 30
2020.11.20 10:53:00.751 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Power_L3_+_W, val=0, expr=$val / 10
2020.11.20 10:53:00.751 5: KSEM: CheckEval for ParseObj result is 0
2020.11.20 10:53:00.751 5: KSEM: ParseObj for Active_Power_L3_+_W does sprintf with format %.2f, value is 0
2020.11.20 10:53:00.751 5: KSEM: ParseObj for Active_Power_L3_+_W sprintf result is 0.00
2020.11.20 10:53:00.751 4: KSEM: ParseObj assigns value 0.00 to Active_Power_L3_+_W
2020.11.20 10:53:00.752 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:00.752 4: KSEM: ResponseDone request: id 1, fCode 3, tid 108, type h, adr 120, len 2 for device KSEM reading Active_Power_L3_+_W (getUpdate), queued 0.22 secs ago, sent 0.01 secs ago, Current read buffer: 006c0000000701030400000000, Id 1, fCode 3, tid 108, response: id 1, fCode 3, type h, adr 120, len 2, value 00000000
2020.11.20 10:53:00.752 5: KSEM: DropFrame - drop 006c0000000701030400000000
2020.11.20 10:53:00.753 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:00.754 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 13, next entry to id 1 (KSEM), last send to this device was 0.006 secs ago, last read 0.004 secs ago, last read on bus 0.004 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.755 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.750) for KSEM, rest 0.095, set timer to try again later
2020.11.20 10:53:00.755 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.095 seconds
2020.11.20 10:53:00.853 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 13, next entry to id 1 (KSEM), last send to this device was 0.104 secs ago, last read 0.103 secs ago, last read on bus 0.103 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.853 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.750) for KSEM, delay 0.003secs over
2020.11.20 10:53:00.853 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:00.748) for KSEM, delay 0.005secs over
2020.11.20 10:53:00.853 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 13, sending 00af00000006010300000002 request: id 1, fCode 3, tid 175, type h, adr 0, len 2 for device KSEM reading Active_Power_total_+_W (getUpdate), queued 0.32 secs ago, read buffer empty
2020.11.20 10:53:00.853 5: SW: 00af00000006010300000002
2020.11.20 10:53:00.855 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:00.856 5: KSEM: read buffer: 00af0000000701030400000000
2020.11.20 10:53:00.856 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 175, dlen 7 and data 0400000000
2020.11.20 10:53:00.856 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:00.856 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:00.857 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:00.857 5: KSEM: ParseObj called with data 00000000, type h, adr 0, valuesLen 2, op read
2020.11.20 10:53:00.857 5: KSEM: ParseObj ObjInfo for h0: reading=Active_Power_total_+_W, unpack=I>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:00.857 5: KSEM: ParseObj unpacked 00000000 with I> to 0 hex 30
2020.11.20 10:53:00.857 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Power_total_+_W, val=0, expr=$val / 10
2020.11.20 10:53:00.858 5: KSEM: CheckEval for ParseObj result is 0
2020.11.20 10:53:00.858 5: KSEM: ParseObj for Active_Power_total_+_W does sprintf with format %.2f, value is 0
2020.11.20 10:53:00.858 5: KSEM: ParseObj for Active_Power_total_+_W sprintf result is 0.00
2020.11.20 10:53:00.858 4: KSEM: ParseObj assigns value 0.00 to Active_Power_total_+_W
2020.11.20 10:53:00.888 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:00.888 4: KSEM: ResponseDone request: id 1, fCode 3, tid 175, type h, adr 0, len 2 for device KSEM reading Active_Power_total_+_W (getUpdate), queued 0.36 secs ago, sent 0.04 secs ago, Current read buffer: 00af0000000701030400000000, Id 1, fCode 3, tid 175, response: id 1, fCode 3, type h, adr 0, len 2, value 00000000
2020.11.20 10:53:00.888 5: KSEM: DropFrame - drop 00af0000000701030400000000
2020.11.20 10:53:00.889 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:00.890 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 12, next entry to id 1 (KSEM), last send to this device was 0.035 secs ago, last read 0.034 secs ago, last read on bus 0.034 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.891 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.856) for KSEM, rest 0.066, set timer to try again later
2020.11.20 10:53:00.891 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.066 seconds
2020.11.20 10:53:00.959 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 12, next entry to id 1 (KSEM), last send to this device was 0.104 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.959 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.856) for KSEM, delay 0.002secs over
2020.11.20 10:53:00.959 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:00.855) for KSEM, delay 0.004secs over
2020.11.20 10:53:00.959 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 12, sending 007700000006010300020002 request: id 1, fCode 3, tid 119, type h, adr 2, len 2 for device KSEM reading Active_Power_total_-_W (getUpdate), queued 0.43 secs ago, read buffer empty
2020.11.20 10:53:00.959 5: SW: 007700000006010300020002
2020.11.20 10:53:00.961 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:00.964 5: KSEM: read buffer: 0077000000070103040000002d
2020.11.20 10:53:00.964 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 119, dlen 7 and data 040000002d
2020.11.20 10:53:00.964 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:00.964 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:00.965 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:00.965 5: KSEM: ParseObj called with data 0000002d, type h, adr 2, valuesLen 2, op read
2020.11.20 10:53:00.965 5: KSEM: ParseObj ObjInfo for h2: reading=Active_Power_total_-_W, unpack=I>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:00.965 5: KSEM: ParseObj unpacked 0000002d with I> to 45 hex 3435
2020.11.20 10:53:00.965 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Power_total_-_W, val=45, expr=$val / 10
2020.11.20 10:53:00.966 5: KSEM: CheckEval for ParseObj result is 4.5
2020.11.20 10:53:00.966 5: KSEM: ParseObj for Active_Power_total_-_W does sprintf with format %.2f, value is 4.5
2020.11.20 10:53:00.966 5: KSEM: ParseObj for Active_Power_total_-_W sprintf result is 4.50
2020.11.20 10:53:00.966 4: KSEM: ParseObj assigns value 4.50 to Active_Power_total_-_W
2020.11.20 10:53:00.996 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:00.996 4: KSEM: ResponseDone request: id 1, fCode 3, tid 119, type h, adr 2, len 2 for device KSEM reading Active_Power_total_-_W (getUpdate), queued 0.46 secs ago, sent 0.04 secs ago, Current read buffer: 0077000000070103040000002d, Id 1, fCode 3, tid 119, response: id 1, fCode 3, type h, adr 2, len 2, value 0000002d
2020.11.20 10:53:00.996 5: KSEM: DropFrame - drop 0077000000070103040000002d
2020.11.20 10:53:00.997 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:00.998 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 11, next entry to id 1 (KSEM), last send to this device was 0.037 secs ago, last read 0.034 secs ago, last read on bus 0.034 secs ago from id 1 (KSEM)
2020.11.20 10:53:00.999 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.964) for KSEM, rest 0.066, set timer to try again later
2020.11.20 10:53:00.999 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.066 seconds
2020.11.20 10:53:01.067 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 11, next entry to id 1 (KSEM), last send to this device was 0.106 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.067 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:00.964) for KSEM, delay 0.003secs over
2020.11.20 10:53:01.067 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:00.961) for KSEM, delay 0.006secs over
2020.11.20 10:53:01.067 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 11, sending 002f00000006010302000004 request: id 1, fCode 3, tid 47, type h, adr 512, len 4 for device KSEM reading Active_Energy_total_+_Wh (getUpdate), queued 0.54 secs ago, read buffer empty
2020.11.20 10:53:01.068 5: SW: 002f00000006010302000004
2020.11.20 10:53:01.069 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.070 5: KSEM: read buffer: 002f0000000b0103080000000000ef22b5
2020.11.20 10:53:01.070 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 47, dlen 11 and data 080000000000ef22b5
2020.11.20 10:53:01.070 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.071 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.071 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.071 5: KSEM: ParseObj called with data 0000000000ef22b5, type h, adr 512, valuesLen 4, op read
2020.11.20 10:53:01.071 5: KSEM: ParseObj ObjInfo for h512: reading=Active_Energy_total_+_Wh, unpack=Q>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.071 5: KSEM: ParseObj unpacked 0000000000ef22b5 with Q> to 15671989 hex 3135363731393839
2020.11.20 10:53:01.072 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Energy_total_+_Wh, val=15671989, expr=$val / 10
2020.11.20 10:53:01.072 5: KSEM: CheckEval for ParseObj result is 1567198.9
2020.11.20 10:53:01.072 5: KSEM: ParseObj for Active_Energy_total_+_Wh does sprintf with format %.2f, value is 1567198.9
2020.11.20 10:53:01.072 5: KSEM: ParseObj for Active_Energy_total_+_Wh sprintf result is 1567198.90
2020.11.20 10:53:01.072 4: KSEM: ParseObj assigns value 1567198.90 to Active_Energy_total_+_Wh
2020.11.20 10:53:01.073 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.073 4: KSEM: ResponseDone request: id 1, fCode 3, tid 47, type h, adr 512, len 4 for device KSEM reading Active_Energy_total_+_Wh (getUpdate), queued 0.54 secs ago, sent 0.01 secs ago, Current read buffer: 002f0000000b0103080000000000ef22b5, Id 1, fCode 3, tid 47, response: id 1, fCode 3, type h, adr 512, len 4, value 0000000000ef22b5
2020.11.20 10:53:01.073 5: KSEM: DropFrame - drop 002f0000000b0103080000000000ef22b5
2020.11.20 10:53:01.073 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.075 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 10, next entry to id 1 (KSEM), last send to this device was 0.006 secs ago, last read 0.004 secs ago, last read on bus 0.004 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.075 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.070) for KSEM, rest 0.095, set timer to try again later
2020.11.20 10:53:01.076 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.095 seconds
2020.11.20 10:53:01.175 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 10, next entry to id 1 (KSEM), last send to this device was 0.106 secs ago, last read 0.104 secs ago, last read on bus 0.104 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.175 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.070) for KSEM, delay 0.005secs over
2020.11.20 10:53:01.176 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.069) for KSEM, delay 0.007secs over
2020.11.20 10:53:01.176 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 10, sending 00e6000000060103007a0002 request: id 1, fCode 3, tid 230, type h, adr 122, len 2 for device KSEM reading Active_Power_L3_-_W (getUpdate), queued 0.64 secs ago, read buffer empty
2020.11.20 10:53:01.177 5: SW: 00e6000000060103007a0002
2020.11.20 10:53:01.180 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.181 5: KSEM: read buffer: 00e600000007010304000003b6
2020.11.20 10:53:01.181 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 230, dlen 7 and data 04000003b6
2020.11.20 10:53:01.181 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.181 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.181 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.182 5: KSEM: ParseObj called with data 000003b6, type h, adr 122, valuesLen 2, op read
2020.11.20 10:53:01.182 5: KSEM: ParseObj ObjInfo for h122: reading=Active_Power_L3_-_W, unpack=I>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.182 5: KSEM: ParseObj unpacked 000003b6 with I> to 950 hex 393530
2020.11.20 10:53:01.182 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Power_L3_-_W, val=950, expr=$val / 10
2020.11.20 10:53:01.182 5: KSEM: CheckEval for ParseObj result is 95
2020.11.20 10:53:01.183 5: KSEM: ParseObj for Active_Power_L3_-_W does sprintf with format %.2f, value is 95
2020.11.20 10:53:01.183 5: KSEM: ParseObj for Active_Power_L3_-_W sprintf result is 95.00
2020.11.20 10:53:01.183 4: KSEM: ParseObj assigns value 95.00 to Active_Power_L3_-_W
2020.11.20 10:53:01.212 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.213 4: KSEM: ResponseDone request: id 1, fCode 3, tid 230, type h, adr 122, len 2 for device KSEM reading Active_Power_L3_-_W (getUpdate), queued 0.68 secs ago, sent 0.04 secs ago, Current read buffer: 00e600000007010304000003b6, Id 1, fCode 3, tid 230, response: id 1, fCode 3, type h, adr 122, len 2, value 000003b6
2020.11.20 10:53:01.213 5: KSEM: DropFrame - drop 00e600000007010304000003b6
2020.11.20 10:53:01.213 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.215 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 9, next entry to id 1 (KSEM), last send to this device was 0.036 secs ago, last read 0.034 secs ago, last read on bus 0.034 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.215 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.181) for KSEM, rest 0.066, set timer to try again later
2020.11.20 10:53:01.216 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.066 seconds
2020.11.20 10:53:01.284 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 9, next entry to id 1 (KSEM), last send to this device was 0.105 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.284 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.181) for KSEM, delay 0.003secs over
2020.11.20 10:53:01.284 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.178) for KSEM, delay 0.006secs over
2020.11.20 10:53:01.284 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 9, sending 00ad00000006010300520002 request: id 1, fCode 3, tid 173, type h, adr 82, len 2 for device KSEM reading Active_Power_L2_-_W (getUpdate), queued 0.75 secs ago, read buffer empty
2020.11.20 10:53:01.285 5: SW: 00ad00000006010300520002
2020.11.20 10:53:01.286 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.287 5: KSEM: read buffer: 00ad00000007010304000003be
2020.11.20 10:53:01.287 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 173, dlen 7 and data 04000003be
2020.11.20 10:53:01.288 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.288 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.288 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.288 5: KSEM: ParseObj called with data 000003be, type h, adr 82, valuesLen 2, op read
2020.11.20 10:53:01.289 5: KSEM: ParseObj ObjInfo for h82: reading=Active_Power_L2_-_W, unpack=I>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.289 5: KSEM: ParseObj unpacked 000003be with I> to 958 hex 393538
2020.11.20 10:53:01.289 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Power_L2_-_W, val=958, expr=$val / 10
2020.11.20 10:53:01.289 5: KSEM: CheckEval for ParseObj result is 95.8
2020.11.20 10:53:01.289 5: KSEM: ParseObj for Active_Power_L2_-_W does sprintf with format %.2f, value is 95.8
2020.11.20 10:53:01.289 5: KSEM: ParseObj for Active_Power_L2_-_W sprintf result is 95.80
2020.11.20 10:53:01.289 4: KSEM: ParseObj assigns value 95.80 to Active_Power_L2_-_W
2020.11.20 10:53:01.319 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.319 4: KSEM: ResponseDone request: id 1, fCode 3, tid 173, type h, adr 82, len 2 for device KSEM reading Active_Power_L2_-_W (getUpdate), queued 0.79 secs ago, sent 0.04 secs ago, Current read buffer: 00ad00000007010304000003be, Id 1, fCode 3, tid 173, response: id 1, fCode 3, type h, adr 82, len 2, value 000003be
2020.11.20 10:53:01.320 5: KSEM: DropFrame - drop 00ad00000007010304000003be
2020.11.20 10:53:01.320 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.322 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 8, next entry to id 1 (KSEM), last send to this device was 0.036 secs ago, last read 0.034 secs ago, last read on bus 0.034 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.322 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.288) for KSEM, rest 0.066, set timer to try again later
2020.11.20 10:53:01.322 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.066 seconds
2020.11.20 10:53:01.390 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 8, next entry to id 1 (KSEM), last send to this device was 0.104 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.390 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.288) for KSEM, delay 0.003secs over
2020.11.20 10:53:01.390 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.286) for KSEM, delay 0.005secs over
2020.11.20 10:53:01.391 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 8, sending 00bc000000060103002a0002 request: id 1, fCode 3, tid 188, type h, adr 42, len 2 for device KSEM reading Active_Power_L1_-_W (getUpdate), queued 0.86 secs ago, read buffer empty
2020.11.20 10:53:01.391 5: SW: 00bc000000060103002a0002
2020.11.20 10:53:01.393 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.395 5: KSEM: read buffer: 00bc0000000701030400000000
2020.11.20 10:53:01.395 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 188, dlen 7 and data 0400000000
2020.11.20 10:53:01.395 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.395 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.395 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.395 5: KSEM: ParseObj called with data 00000000, type h, adr 42, valuesLen 2, op read
2020.11.20 10:53:01.396 5: KSEM: ParseObj ObjInfo for h42: reading=Active_Power_L1_-_W, unpack=I>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.396 5: KSEM: ParseObj unpacked 00000000 with I> to 0 hex 30
2020.11.20 10:53:01.396 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Power_L1_-_W, val=0, expr=$val / 10
2020.11.20 10:53:01.396 5: KSEM: CheckEval for ParseObj result is 0
2020.11.20 10:53:01.396 5: KSEM: ParseObj for Active_Power_L1_-_W does sprintf with format %.2f, value is 0
2020.11.20 10:53:01.397 5: KSEM: ParseObj for Active_Power_L1_-_W sprintf result is 0.00
2020.11.20 10:53:01.397 4: KSEM: ParseObj assigns value 0.00 to Active_Power_L1_-_W
2020.11.20 10:53:01.397 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.397 4: KSEM: ResponseDone request: id 1, fCode 3, tid 188, type h, adr 42, len 2 for device KSEM reading Active_Power_L1_-_W (getUpdate), queued 0.86 secs ago, sent 0.01 secs ago, Current read buffer: 00bc0000000701030400000000, Id 1, fCode 3, tid 188, response: id 1, fCode 3, type h, adr 42, len 2, value 00000000
2020.11.20 10:53:01.397 5: KSEM: DropFrame - drop 00bc0000000701030400000000
2020.11.20 10:53:01.398 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.400 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 7, next entry to id 1 (KSEM), last send to this device was 0.008 secs ago, last read 0.005 secs ago, last read on bus 0.005 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.400 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.395) for KSEM, rest 0.095, set timer to try again later
2020.11.20 10:53:01.401 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.095 seconds
2020.11.20 10:53:01.499 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 7, next entry to id 1 (KSEM), last send to this device was 0.107 secs ago, last read 0.104 secs ago, last read on bus 0.104 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.500 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.395) for KSEM, delay 0.005secs over
2020.11.20 10:53:01.500 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.392) for KSEM, delay 0.008secs over
2020.11.20 10:53:01.501 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 7, sending 00cf00000006010302a00004 request: id 1, fCode 3, tid 207, type h, adr 672, len 4 for device KSEM reading Active_Energy_L2_+_Wh (getUpdate), queued 0.97 secs ago, read buffer empty
2020.11.20 10:53:01.501 5: SW: 00cf00000006010302a00004
2020.11.20 10:53:01.504 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.505 5: KSEM: read buffer: 00cf0000000b010308000000000033c3ae
2020.11.20 10:53:01.505 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 207, dlen 11 and data 08000000000033c3ae
2020.11.20 10:53:01.505 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.505 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.505 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.505 5: KSEM: ParseObj called with data 000000000033c3ae, type h, adr 672, valuesLen 4, op read
2020.11.20 10:53:01.506 5: KSEM: ParseObj ObjInfo for h672: reading=Active_Energy_L2_+_Wh, unpack=Q>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.506 5: KSEM: ParseObj unpacked 000000000033c3ae with Q> to 3392430 hex 33333932343330
2020.11.20 10:53:01.506 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Energy_L2_+_Wh, val=3392430, expr=$val / 10
2020.11.20 10:53:01.506 5: KSEM: CheckEval for ParseObj result is 339243
2020.11.20 10:53:01.506 5: KSEM: ParseObj for Active_Energy_L2_+_Wh does sprintf with format %.2f, value is 339243
2020.11.20 10:53:01.506 5: KSEM: ParseObj for Active_Energy_L2_+_Wh sprintf result is 339243.00
2020.11.20 10:53:01.507 4: KSEM: ParseObj assigns value 339243.00 to Active_Energy_L2_+_Wh
2020.11.20 10:53:01.507 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.507 4: KSEM: ResponseDone request: id 1, fCode 3, tid 207, type h, adr 672, len 4 for device KSEM reading Active_Energy_L2_+_Wh (getUpdate), queued 0.97 secs ago, sent 0.01 secs ago, Current read buffer: 00cf0000000b010308000000000033c3ae, Id 1, fCode 3, tid 207, response: id 1, fCode 3, type h, adr 672, len 4, value 000000000033c3ae
2020.11.20 10:53:01.507 5: KSEM: DropFrame - drop 00cf0000000b010308000000000033c3ae
2020.11.20 10:53:01.508 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.509 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 6, next entry to id 1 (KSEM), last send to this device was 0.007 secs ago, last read 0.004 secs ago, last read on bus 0.004 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.510 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.505) for KSEM, rest 0.095, set timer to try again later
2020.11.20 10:53:01.510 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.095 seconds
2020.11.20 10:53:01.607 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 6, next entry to id 1 (KSEM), last send to this device was 0.105 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.608 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.505) for KSEM, delay 0.003secs over
2020.11.20 10:53:01.608 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.503) for KSEM, delay 0.005secs over
2020.11.20 10:53:01.608 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 6, sending 00ab00000006010302f40004 request: id 1, fCode 3, tid 171, type h, adr 756, len 4 for device KSEM reading Active_Energy_L3_-_Wh (getUpdate), queued 1.07 secs ago, read buffer empty
2020.11.20 10:53:01.608 5: SW: 00ab00000006010302f40004
2020.11.20 10:53:01.610 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.611 5: KSEM: read buffer: 00ab0000000b010308000000000073be42
2020.11.20 10:53:01.611 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 171, dlen 11 and data 08000000000073be42
2020.11.20 10:53:01.611 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.612 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.612 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.612 5: KSEM: ParseObj called with data 000000000073be42, type h, adr 756, valuesLen 4, op read
2020.11.20 10:53:01.612 5: KSEM: ParseObj ObjInfo for h756: reading=Active_Energy_L3_-_Wh, unpack=Q>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.613 5: KSEM: ParseObj unpacked 000000000073be42 with Q> to 7585346 hex 37353835333436
2020.11.20 10:53:01.613 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Energy_L3_-_Wh, val=7585346, expr=$val / 10
2020.11.20 10:53:01.613 5: KSEM: CheckEval for ParseObj result is 758534.6
2020.11.20 10:53:01.613 5: KSEM: ParseObj for Active_Energy_L3_-_Wh does sprintf with format %.2f, value is 758534.6
2020.11.20 10:53:01.613 5: KSEM: ParseObj for Active_Energy_L3_-_Wh sprintf result is 758534.60
2020.11.20 10:53:01.613 4: KSEM: ParseObj assigns value 758534.60 to Active_Energy_L3_-_Wh
2020.11.20 10:53:01.643 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.643 4: KSEM: ResponseDone request: id 1, fCode 3, tid 171, type h, adr 756, len 4 for device KSEM reading Active_Energy_L3_-_Wh (getUpdate), queued 1.11 secs ago, sent 0.04 secs ago, Current read buffer: 00ab0000000b010308000000000073be42, Id 1, fCode 3, tid 171, response: id 1, fCode 3, type h, adr 756, len 4, value 000000000073be42
2020.11.20 10:53:01.643 5: KSEM: DropFrame - drop 00ab0000000b010308000000000073be42
2020.11.20 10:53:01.644 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.645 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 5, next entry to id 1 (KSEM), last send to this device was 0.036 secs ago, last read 0.034 secs ago, last read on bus 0.034 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.646 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.612) for KSEM, rest 0.066, set timer to try again later
2020.11.20 10:53:01.646 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.066 seconds
2020.11.20 10:53:01.714 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 5, next entry to id 1 (KSEM), last send to this device was 0.104 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.714 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.612) for KSEM, delay 0.003secs over
2020.11.20 10:53:01.714 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.609) for KSEM, delay 0.005secs over
2020.11.20 10:53:01.715 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 5, sending 009400000006010302f00004 request: id 1, fCode 3, tid 148, type h, adr 752, len 4 for device KSEM reading Active_Energy_L3_+_Wh (getUpdate), queued 1.18 secs ago, read buffer empty
2020.11.20 10:53:01.715 5: SW: 009400000006010302f00004
2020.11.20 10:53:01.717 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.717 5: KSEM: read buffer: 00940000000b0103080000000000404928
2020.11.20 10:53:01.718 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 148, dlen 11 and data 080000000000404928
2020.11.20 10:53:01.718 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.718 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.718 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.718 5: KSEM: ParseObj called with data 0000000000404928, type h, adr 752, valuesLen 4, op read
2020.11.20 10:53:01.719 5: KSEM: ParseObj ObjInfo for h752: reading=Active_Energy_L3_+_Wh, unpack=Q>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.719 5: KSEM: ParseObj unpacked 0000000000404928 with Q> to 4213032 hex 34323133303332
2020.11.20 10:53:01.719 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Energy_L3_+_Wh, val=4213032, expr=$val / 10
2020.11.20 10:53:01.719 5: KSEM: CheckEval for ParseObj result is 421303.2
2020.11.20 10:53:01.719 5: KSEM: ParseObj for Active_Energy_L3_+_Wh does sprintf with format %.2f, value is 421303.2
2020.11.20 10:53:01.719 5: KSEM: ParseObj for Active_Energy_L3_+_Wh sprintf result is 421303.20
2020.11.20 10:53:01.719 4: KSEM: ParseObj assigns value 421303.20 to Active_Energy_L3_+_Wh
2020.11.20 10:53:01.720 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.720 4: KSEM: ResponseDone request: id 1, fCode 3, tid 148, type h, adr 752, len 4 for device KSEM reading Active_Energy_L3_+_Wh (getUpdate), queued 1.19 secs ago, sent 0.01 secs ago, Current read buffer: 00940000000b0103080000000000404928, Id 1, fCode 3, tid 148, response: id 1, fCode 3, type h, adr 752, len 4, value 0000000000404928
2020.11.20 10:53:01.720 5: KSEM: DropFrame - drop 00940000000b0103080000000000404928
2020.11.20 10:53:01.721 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.722 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 4, next entry to id 1 (KSEM), last send to this device was 0.006 secs ago, last read 0.004 secs ago, last read on bus 0.004 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.723 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.718) for KSEM, rest 0.095, set timer to try again later
2020.11.20 10:53:01.723 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.095 seconds
2020.11.20 10:53:01.823 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 4, next entry to id 1 (KSEM), last send to this device was 0.106 secs ago, last read 0.105 secs ago, last read on bus 0.105 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.824 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.718) for KSEM, delay 0.006secs over
2020.11.20 10:53:01.824 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.716) for KSEM, delay 0.008secs over
2020.11.20 10:53:01.825 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 4, sending 008a00000006010302540004 request: id 1, fCode 3, tid 138, type h, adr 596, len 4 for device KSEM reading Active_Energy_L1_-_Wh (getUpdate), queued 1.29 secs ago, read buffer empty
2020.11.20 10:53:01.825 5: SW: 008a00000006010302540004
2020.11.20 10:53:01.827 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.829 5: KSEM: read buffer: 008a0000000b0103080000000000583e77
2020.11.20 10:53:01.829 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 138, dlen 11 and data 080000000000583e77
2020.11.20 10:53:01.830 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.830 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.830 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.831 5: KSEM: ParseObj called with data 0000000000583e77, type h, adr 596, valuesLen 4, op read
2020.11.20 10:53:01.832 5: KSEM: ParseObj ObjInfo for h596: reading=Active_Energy_L1_-_Wh, unpack=Q>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.833 5: KSEM: ParseObj unpacked 0000000000583e77 with Q> to 5783159 hex 35373833313539
2020.11.20 10:53:01.833 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Energy_L1_-_Wh, val=5783159, expr=$val / 10
2020.11.20 10:53:01.834 5: KSEM: CheckEval for ParseObj result is 578315.9
2020.11.20 10:53:01.834 5: KSEM: ParseObj for Active_Energy_L1_-_Wh does sprintf with format %.2f, value is 578315.9
2020.11.20 10:53:01.834 5: KSEM: ParseObj for Active_Energy_L1_-_Wh sprintf result is 578315.90
2020.11.20 10:53:01.834 4: KSEM: ParseObj assigns value 578315.90 to Active_Energy_L1_-_Wh
2020.11.20 10:53:01.835 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.835 4: KSEM: ResponseDone request: id 1, fCode 3, tid 138, type h, adr 596, len 4 for device KSEM reading Active_Energy_L1_-_Wh (getUpdate), queued 1.30 secs ago, sent 0.01 secs ago, Current read buffer: 008a0000000b0103080000000000583e77, Id 1, fCode 3, tid 138, response: id 1, fCode 3, type h, adr 596, len 4, value 0000000000583e77
2020.11.20 10:53:01.835 5: KSEM: DropFrame - drop 008a0000000b0103080000000000583e77
2020.11.20 10:53:01.836 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.837 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 3, next entry to id 1 (KSEM), last send to this device was 0.011 secs ago, last read 0.007 secs ago, last read on bus 0.007 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.837 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.830) for KSEM, rest 0.093, set timer to try again later
2020.11.20 10:53:01.838 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.093 seconds
2020.11.20 10:53:01.932 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 3, next entry to id 1 (KSEM), last send to this device was 0.106 secs ago, last read 0.102 secs ago, last read on bus 0.102 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.933 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.830) for KSEM, delay 0.003secs over
2020.11.20 10:53:01.934 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.826) for KSEM, delay 0.007secs over
2020.11.20 10:53:01.934 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 3, sending 003b00000006010302040004 request: id 1, fCode 3, tid 59, type h, adr 516, len 4 for device KSEM reading Active_Energy_total_-_Wh (getUpdate), queued 1.40 secs ago, read buffer empty
2020.11.20 10:53:01.934 5: SW: 003b00000006010302040004
2020.11.20 10:53:01.937 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:01.943 5: KSEM: read buffer: 003b0000000b01030800000000011a592f
2020.11.20 10:53:01.944 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 59, dlen 11 and data 0800000000011a592f
2020.11.20 10:53:01.944 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:01.944 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:01.945 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:01.945 5: KSEM: ParseObj called with data 00000000011a592f, type h, adr 516, valuesLen 4, op read
2020.11.20 10:53:01.946 5: KSEM: ParseObj ObjInfo for h516: reading=Active_Energy_total_-_Wh, unpack=Q>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:01.947 5: KSEM: ParseObj unpacked 00000000011a592f with Q> to 18503983 hex 3138353033393833
2020.11.20 10:53:01.947 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Energy_total_-_Wh, val=18503983, expr=$val / 10
2020.11.20 10:53:01.947 5: KSEM: CheckEval for ParseObj result is 1850398.3
2020.11.20 10:53:01.947 5: KSEM: ParseObj for Active_Energy_total_-_Wh does sprintf with format %.2f, value is 1850398.3
2020.11.20 10:53:01.948 5: KSEM: ParseObj for Active_Energy_total_-_Wh sprintf result is 1850398.30
2020.11.20 10:53:01.948 4: KSEM: ParseObj assigns value 1850398.30 to Active_Energy_total_-_Wh
2020.11.20 10:53:01.948 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:01.949 4: KSEM: ResponseDone request: id 1, fCode 3, tid 59, type h, adr 516, len 4 for device KSEM reading Active_Energy_total_-_Wh (getUpdate), queued 1.41 secs ago, sent 0.02 secs ago, Current read buffer: 003b0000000b01030800000000011a592f, Id 1, fCode 3, tid 59, response: id 1, fCode 3, type h, adr 516, len 4, value 00000000011a592f
2020.11.20 10:53:01.949 5: KSEM: DropFrame - drop 003b0000000b01030800000000011a592f
2020.11.20 10:53:01.949 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:01.951 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 2, next entry to id 1 (KSEM), last send to this device was 0.015 secs ago, last read 0.007 secs ago, last read on bus 0.007 secs ago from id 1 (KSEM)
2020.11.20 10:53:01.952 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.944) for KSEM, rest 0.093, set timer to try again later
2020.11.20 10:53:01.952 5: KSEM: StartQueueTimer called form CheckDelay sets internal timer to call Modbus_ProcessRequestQueue in 0.093 seconds
2020.11.20 10:53:02.045 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 2, next entry to id 1 (KSEM), last send to this device was 0.109 secs ago, last read 0.101 secs ago, last read on bus 0.101 secs ago from id 1 (KSEM)
2020.11.20 10:53:02.046 5: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:01.944) for KSEM, delay 0.001secs over
2020.11.20 10:53:02.046 5: KSEM: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 10:53:01.936) for KSEM, delay 0.010secs over
2020.11.20 10:53:02.046 4: KSEM: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 2, sending 00b600000006010300280002 request: id 1, fCode 3, tid 182, type h, adr 40, len 2 for device KSEM reading Active_Power_L1_+_W (getUpdate), queued 1.51 secs ago, read buffer empty
2020.11.20 10:53:02.046 5: SW: 00b600000006010300280002
2020.11.20 10:53:02.048 5: KSEM: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.11.20 10:53:02.049 5: KSEM: read buffer: 00b60000000701030400000743
2020.11.20 10:53:02.049 4: KSEM: ParseFrameStart (TCP) extracted id 1, fCode 3, tid 182, dlen 7 and data 0400000743
2020.11.20 10:53:02.049 5: KSEM: HandleResponse called from Read
2020.11.20 10:53:02.049 5: KSEM: ParseResponse called from HandleResponse
2020.11.20 10:53:02.049 5: KSEM: HandleResponse now passing to logical device KSEM for parsing data
2020.11.20 10:53:02.049 5: KSEM: ParseObj called with data 00000743, type h, adr 40, valuesLen 2, op read
2020.11.20 10:53:02.050 5: KSEM: ParseObj ObjInfo for h40: reading=Active_Power_L1_+_W, unpack=I>, expr=$val / 10, format=%.2f, map=
2020.11.20 10:53:02.050 5: KSEM: ParseObj unpacked 00000743 with I> to 1859 hex 31383539
2020.11.20 10:53:02.050 5: KSEM: CheckEval for ParseObj evaluates expr for Active_Power_L1_+_W, val=1859, expr=$val / 10
2020.11.20 10:53:02.050 5: KSEM: CheckEval for ParseObj result is 185.9
2020.11.20 10:53:02.051 5: KSEM: ParseObj for Active_Power_L1_+_W does sprintf with format %.2f, value is 185.9
2020.11.20 10:53:02.051 5: KSEM: ParseObj for Active_Power_L1_+_W sprintf result is 185.90
2020.11.20 10:53:02.051 4: KSEM: ParseObj assigns value 185.90 to Active_Power_L1_+_W
2020.11.20 10:53:02.081 5: KSEM: HandleResponse got 1 readings from ParseObj for KSEM
2020.11.20 10:53:02.082 4: KSEM: ResponseDone request: id 1, fCode 3, tid 182, type h, adr 40, len 2 for device KSEM reading Active_Power_L1_+_W (getUpdate), queued 1.55 secs ago, sent 0.04 secs ago, Current read buffer: 00b60000000701030400000743, Id 1, fCode 3, tid 182, response: id 1, fCode 3, type h, adr 40, len 2, value 00000743
2020.11.20 10:53:02.082 5: KSEM: DropFrame - drop 00b60000000701030400000743
2020.11.20 10:53:02.082 5: KSEM: StartQueueTimer called form Read sets internal timer to call Modbus_ProcessRequestQueue in 0.000 seconds
2020.11.20 10:53:02.084 4: KSEM: ProcessRequestQueue called from HandleTimeout, qlen 1, next entry to id 1 (KSEM), last send to this device was 0.037 secs ago, last read 0.035 secs ago, last read on bus 0.035 secs ago from id 1 (KSEM)
2020.11.20 10:53:02.084 4: KSEM: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 10:53:02.049) for KSEM, rest 0.065, set timer to try again later
... abgeschnitten... :-(
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 November 2020, 17:50:18
Hallo,

das Log scheint abgeschnitten - am Ende steht nichts von apptime oder timeouts.
So lange Logs sollte man in Code-Tags einpacken.

Anbei nochmal eine neue Version, in der es ein neues Attribut nextOpenDelay2 gibt. Das verzögert aufeinanderfolgende Open-Calls, auch wenn der vorherige erfolgreich war.
@Gadget, damit müsstest Du Deinen Fall in den Griff bekommen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 21 November 2020, 18:10:27
Zitat von: StefanStrobel am 21 November 2020, 17:50:18
So lange Logs sollte man in Code-Tags einpacken.
Ein Forum Post hat auch eine Limitierung, da wird dann auch das code Tag am Ende abgeschnitten.
Also doch besser als .txt anhängen.
My five cent
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 23 November 2020, 10:08:57
Zitat von: StefanStrobel am 21 November 2020, 17:50:18
Anbei nochmal eine neue Version, in der es ein neues Attribut nextOpenDelay2 gibt. Das verzögert aufeinanderfolgende Open-Calls, auch wenn der vorherige erfolgreich war.
@Gadget, damit müsstest Du Deinen Fall in den Griff bekommen.

Erfolgreich getestet. Mit

nextOpenDelay 40
nextOpenDelay2 30


bekomme ich jetzt im Fehlerfall (device in ser2net konfiguiert, aber physikalisch abgesteckt) exakt 1 Minute zwischen den Retries. Warum 1 Minute und nicht 30 Sekunden ist mir nicht klar, aber das ist mir auch nicht wichtig. Hauptsache nicht mehrfach pro Sekunde.

Danke und Grüße,

gadget.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: killah78 am 23 November 2020, 11:26:38
Zitat von: StefanStrobel am 21 November 2020, 17:50:18
das Log scheint abgeschnitten - am Ende steht nichts von apptime oder timeouts.
So lange Logs sollte man in Code-Tags einpacken.

Ja, ist abgeschnitten. Ich hatte es in Code-Tags verpackt, und die Vorschau sah auch gut aus. Naja.
Hier nochmal per File.
1.txt ist der Abruf vor apptime. Apptime verursacht Warnungen beim Aufruf (letzte 3 Zeilen).
2. txt und 3. txt sind dann manuelle Abrufe per set reread.
Eigenständig wird ab dem Aufruf von Apptime nichts mehr gelesen. Für kein Modbus-Gerät. Erst wieder nach dem Neustart von Fhem. Andere Geräte sind nicht betroffen.

Viele Grüße
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 23 November 2020, 12:26:07
Zitat von: killah78 am 23 November 2020, 11:26:38
Eigenständig wird ab dem Aufruf von Apptime nichts mehr gelesen. Für kein Modbus-Gerät. Erst wieder nach dem Neustart von Fhem. Andere Geräte sind nicht betroffen.
Kannst Du mir die einzelnen Schritte für apptime mal schicken? Ich würde es dann so testen und schauen, ob es bei mir dann auch nicht mehr aktualisiert würde.
Ich habe apptime noch nie verwendet, weil Aufräumen bisher immer gelangt hat :-)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: killah78 am 23 November 2020, 12:57:58
Ich gucke ab und zu mal in Apptime, um Verzögerungen zu sehen.
Da ist eigentlich nichts hinter. "apptime" eingeben, dann startet das im Hintergrund. Danach kann man dann mit erneutem Aufruf von zB "apptime max" die Prozesszeiten entsprechend sortiert aufzeigen lassen.
Ab dem Zeitpunkt, wenn ich das erste mal apptime eingebe, werden keine Modbus Devices mehr gelesen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 November 2020, 18:03:27
Hallo Gadget,

da funkt auch noch ein DevIo-interner Mechanismus rein. Der erste Aufruf von Open nach einem Close wird ignoriert weil dann $hash->{DevIoJustClosed} gesetzt ist.
Ich werde mal probieren den auszuhebeln wenn nextOpenDelay2 schon greift, dann sollten es auch 30 Sekunden sein.

Gruss / thanks
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 November 2020, 18:12:54
Hallo killah78,

ich habe versucht das bei mir nachzustellen.
nach Aufruf von apptime laufen die Modbus-Devices bei mir weiter. Im Log sieht man aber dass apptime sich eingeklinkt hat:

2020.11.24 18:08:43 5: PWP: GetUpdate called from apptime_getTiming
2020.11.24 18:08:43 4: PWP: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 2020-11-24 18:08:53, interval 10
2020.11.24 18:08:43 5: PWP: GetUpdate objects from attributes:


Kannst Du mal Deine Konfiguration posten? Irgend etwas muss bei Dir anders sein ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: killah78 am 26 November 2020, 15:27:14
Hallo Stefan,
so, scheinbar funktioniert es wieder. Was ich gemacht habe: Ich habe die TSCUL Module entfernt.
In wie weit das damit zusammenhängt weiss ich nicht. Aber es funktioniert und ich bekomme auch einen Eintrag mit GetUpdate called from apptime_getTiming.
Liegt aber zumindest nicht am ModbusAttr.
Ich sollte mal weiter aufräumen und entfernen, was ich nicht benötige....
Viele Dank für deine Hilfe.
Viele Grüße
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: breitbanddilettant am 03 Dezember 2020, 15:11:43
Hallo zusammen,

ich lese aus meiner Wärmepumpe (ME Ecodan) per modbus alle möglichen Register aus und schreibe auch einige:


###################################
######### Define Modbus ###########
###################################

define ModbusBus Modbus /dev/ttyUSB0@9600
setuuid ModbusBus 5dee511c-f33f-9858-4f2a-a99a0e6119e1eb3e
attr ModbusBus room Heizung

###################################
######### Define Ecodan ###########
###################################

define Ecodan ModbusAttr 1 30
setuuid Ecodan 5dee5132-f33f-9858-e581-6a34208d19a2f8d9
attr Ecodan userattr dev-h-defPoll obj-h102-expr obj-h102-reading obj-h104-expr obj-h104-reading obj-h106-expr obj-h106-reading obj-h108-expr obj-h108-reading obj-h110-expr obj-h110-reading obj-h112-expr obj-h112-reading obj-h114-expr obj-h114-reading obj-h116-expr obj-h116-reading obj-h118-expr obj-h118-reading obj-h12-expr obj-h12-reading obj-h127-reading obj-h25-hint obj-h25-max obj-h25-min obj-h25-polldelay obj-h25-reading obj-h25-set obj-h26-reading obj-h28-hint obj-h28-max obj-h28-min obj-h28-polldelay obj-h28-reading obj-h28-set obj-h282-reading obj-h283-expr obj-h283-reading obj-h284-reading obj-h285-expr obj-h285-reading obj-h286-reading obj-h287-expr obj-h287-reading obj-h29-hint obj-h29-max obj-h29-min obj-h29-polldelay obj-h29-reading obj-h29-set obj-h292-reading obj-h293-expr obj-h293-reading obj-h294-reading obj-h295-expr obj-h295-reading obj-h296-reading obj-h297-expr obj-h297-reading obj-h31-expr obj-h31-hint obj-h31-max obj-h31-min obj-h31-polldelay obj-h31-reading obj-h31-set obj-h31-setexpr obj-h33-expr obj-h33-hint obj-h33-max obj-h33-min obj-h33-polldelay obj-h33-reading obj-h33-set obj-h33-setexpr obj-h35-expr obj-h35-hint obj-h35-max obj-h35-min obj-h35-polldelay obj-h35-reading obj-h35-set obj-h35-setexpr obj-h37-hint obj-h37-max obj-h37-min obj-h37-polldelay obj-h37-reading obj-h37-set obj-h67-reading obj-h80-reading obj-h92-expr obj-h92-reading obj-h99-expr obj-h99-reading
attr Ecodan IODev ModbusBus
attr Ecodan dev-h-defPoll 1
attr Ecodan event-aggregator T-Aussen-median:300:none:median:300
attr Ecodan event-min-interval .*:130
#attr Ecodan event-on-change-reading .*
attr Ecodan obj-h102-expr $val/100
attr Ecodan obj-h102-reading TV-Ecodan
attr Ecodan obj-h104-expr $val/100
attr Ecodan obj-h104-reading TR-Ecodan
attr Ecodan obj-h106-expr $val/100
attr Ecodan obj-h106-reading T-Warmwasser
attr Ecodan obj-h108-expr $val/100
attr Ecodan obj-h108-reading TV-Z1
attr Ecodan obj-h110-expr $val/100
attr Ecodan obj-h110-reading TR-Z1
attr Ecodan obj-h112-expr $val/100
attr Ecodan obj-h112-reading TV-Z2
attr Ecodan obj-h114-expr $val/100
attr Ecodan obj-h114-reading TR-Z2
attr Ecodan obj-h116-expr $val/100
attr Ecodan obj-h116-reading TV-Ofen
attr Ecodan obj-h118-expr $val/100
attr Ecodan obj-h118-reading TR-Ofen
attr Ecodan obj-h12-expr $val == 8000 ? 0 : $val
attr Ecodan obj-h12-reading Error-Ecodan
attr Ecodan obj-h127-reading EinAus-Ausseneinheit
attr Ecodan obj-h25-hint 0,1
attr Ecodan obj-h25-max 1
attr Ecodan obj-h25-min 0
attr Ecodan obj-h25-polldelay 20
attr Ecodan obj-h25-reading EinAus-System
attr Ecodan obj-h25-set 1
attr Ecodan obj-h26-reading Arbeitsmodus
attr Ecodan obj-h28-hint 1,2,4
attr Ecodan obj-h28-max 4
attr Ecodan obj-h28-min 0
attr Ecodan obj-h28-polldelay 20
attr Ecodan obj-h28-reading AC-Modus-Z1
attr Ecodan obj-h28-set 1
attr Ecodan obj-h282-reading W-Verbrauch-Heizung-kW
attr Ecodan obj-h283-expr $val * 10
attr Ecodan obj-h283-reading W-Verbrauch-Heizung-W
attr Ecodan obj-h284-reading W-Verbrauch-Kuehlen-kW
attr Ecodan obj-h285-expr $val * 10
attr Ecodan obj-h285-reading W-Verbrauch-Kuehlen-W
attr Ecodan obj-h286-reading W-Verbrauch-Warmwasser-kW
attr Ecodan obj-h287-expr $val * 10
attr Ecodan obj-h287-reading W-Verbrauch-Warmwasser-W
attr Ecodan obj-h29-hint 1,2,4
attr Ecodan obj-h29-max 4
attr Ecodan obj-h29-min 0
attr Ecodan obj-h29-polldelay 20
attr Ecodan obj-h29-reading AC-Modus-Z2
attr Ecodan obj-h29-set 1
attr Ecodan obj-h292-reading W-Erzeugt-Heizung-kW
attr Ecodan obj-h293-expr $val * 10
attr Ecodan obj-h293-reading W-Erzeugt-Heizung-W
attr Ecodan obj-h294-reading W-Erzeugt-Kuehlen-kW
attr Ecodan obj-h295-expr $val * 10
attr Ecodan obj-h295-reading W-Erzeugt-Kuehlen-W
attr Ecodan obj-h296-reading W-Erzeugt-Warmwasser-kW
attr Ecodan obj-h297-expr $val * 10
attr Ecodan obj-h297-reading W-Erzeugt-Warmwasser-W
attr Ecodan obj-h31-expr $val/100
attr Ecodan obj-h31-hint 45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60
attr Ecodan obj-h31-max 60
attr Ecodan obj-h31-min 45
attr Ecodan obj-h31-polldelay 20
attr Ecodan obj-h31-reading Tsoll-Warmwasser
attr Ecodan obj-h31-set 1
attr Ecodan obj-h31-setexpr $val * 100
attr Ecodan obj-h33-expr $val/100
attr Ecodan obj-h33-hint 26,28,30,31,32,33,34,35,36,37,38,39,40
attr Ecodan obj-h33-max 43
attr Ecodan obj-h33-min 25
attr Ecodan obj-h33-polldelay 20
attr Ecodan obj-h33-reading Tsoll-Vorlauf-Z1
attr Ecodan obj-h33-set 1
attr Ecodan obj-h33-setexpr $val*100
attr Ecodan obj-h35-expr $val/100
attr Ecodan obj-h35-hint 26,28,30,31,32,33,34,35,36,37,38,39,40
attr Ecodan obj-h35-max 60
attr Ecodan obj-h35-min 10
attr Ecodan obj-h35-polldelay 20
attr Ecodan obj-h35-reading Tsoll-Vorlauf-Z2
attr Ecodan obj-h35-set 1
attr Ecodan obj-h35-setexpr $val*100
attr Ecodan obj-h37-hint 0,1
attr Ecodan obj-h37-max 1
attr Ecodan obj-h37-min 0
attr Ecodan obj-h37-polldelay 20
attr Ecodan obj-h37-reading Warmwasser-Start
attr Ecodan obj-h37-set 1
attr Ecodan obj-h67-reading Abtaubetrieb
attr Ecodan obj-h80-reading Waermequelle
attr Ecodan obj-h92-expr $val/10
attr Ecodan obj-h92-reading Tdelta-Warmwasser
attr Ecodan obj-h99-expr $val > (2**15) ? (($val-(2**16))/10) : $val/10
attr Ecodan obj-h99-reading T-Aussen
attr Ecodan room Heizung
attr Ecodan userReadings kW-Verbrauch-Kuehlen {ReadingsNum("Ecodan","W-Verbrauch-Kuehlen-kW",0) + (ReadingsNum("Ecodan","W-Verbrauch-Kuehlen-W",0)/1000)}, kW-Erzeugt-Kuehlen {ReadingsNum("Ecodan","W-Erzeugt-Kuehlen-kW",0) + (ReadingsNum("Ecodan","W-Erzeugt-Kuehlen-W",0)/1000)}, kW-Verbrauch-Heizung {ReadingsNum("Ecodan","W-Verbrauch-Heizung-kW",0) + (ReadingsNum("Ecodan","W-Verbrauch-Heizung-W",0)/1000)}, kW-Erzeugt-Heizung {ReadingsNum("Ecodan","W-Erzeugt-Heizung-kW",0) + (ReadingsNum("Ecodan","W-Erzeugt-Heizung-W",0)/1000)}, kW-Verbrauch-Warmwasser {ReadingsNum("Ecodan","W-Verbrauch-Warmwasser-kW",0) + (ReadingsNum("Ecodan","W-Verbrauch-Warmwasser-W",0)/1000)}, kW-Erzeugt-Warmwasser {ReadingsNum("Ecodan","W-Erzeugt-Warmwasser-kW",0) + (ReadingsNum("Ecodan","W-Erzeugt-Warmwasser-W",0)/1000)}, COP-Heizung {ReadingsNum("Ecodan","kW-Erzeugt-Heizung",0) / ReadingsNum("Ecodan","kW-Verbrauch-Heizung",0)},COP-Kuehlen {(ReadingsNum("Ecodan","AC-Modus-Z1",0) == 3) ? (ReadingsNum("Ecodan","kW-Erzeugt-Kuehlen",0) / ReadingsNum("Ecodan","kW-Verbrauch-Kuehlen",0)) : 0},COP-Warmwasser {ReadingsNum("Ecodan","kW-Erzeugt-Warmwasser",0) / ReadingsNum("Ecodan","kW-Verbrauch-Warmwasser",0)}, Tsoll-Warmwasser-Up {ReadingsNum("Ecodan","Tsoll-Warmwasser",0) + 1}, Tsoll-Warmwasser-Down {ReadingsNum("Ecodan","Tsoll-Warmwasser",0) - 1}, Tavg-Speicher {(ReadingsNum("Ecodan","TV-Z1",0) + ReadingsNum("Ecodan","TR-Z1",0) + ReadingsNum("1W_TVM_Speicher","temperature",0) + ReadingsNum("1W_TRM_Speicher","temperature",0))/4}, Tsoll-Vorlauf-Z1-Up {ReadingsNum("Ecodan","Tsoll-Vorlauf-Z1",0) + 1}, Tsoll-Vorlauf-Z1-Down {ReadingsNum("Ecodan","Tsoll-Vorlauf-Z1",0) - 1}, Tsoll-Vorlauf-Z2-Up {ReadingsNum("Ecodan","Tsoll-Vorlauf-Z2",0) + 1}, Tsoll-Vorlauf-Z2-Down {ReadingsNum("Ecodan","Tsoll-Vorlauf-Z2",0) - 1}, Error-Ofen {ReadingsNum("Ecodan","TV-Ofen",0) < 65 ? 0 : ReadingsNum("Ecodan","TV-Ofen",0)}, Brenner-Aktiv {(ReadingsNum("Ecodan","Arbeitsmodus",0) == 2 ? 1 : 0)*(ReadingsNum("Ecodan","TV-Ofen",0) > 55 ? 1 : 0)}, Arbeitsmodus-Inkl-Brenner {ReadingsNum("Ecodan","Arbeitsmodus",0) + (ReadingsNum("Ecodan","Brenner-Aktiv",0)*10)}, T-Aussen-median {ReadingsNum("Ecodan","T-Aussen",0)}


Die Wärmepumpe läuft mit zwei Heizzonen deren Solltemperaturen Tsoll-Vorlauf-Z1 und Tsoll-Vorlauf-Z2 sind.

Ich würde gerne den Sollwert der Vorlauftemperatur der Zone 1 automatisch anpassen, wenn sich die Vorlauftemperatur der Zone 2 ändert.

Das heißt also, dass ich Tsoll-Vorlauf-Z2 auf 31 setzte und das entsprechende holding Register geschrieben wird. Dann soll im Anschluss automatisch Tsoll-Vorlauf-Z1 auf den selben Wert wie Tsoll-Vorlauf-Z2 gesetzt werden und auch in das entsprechende Register geschrieben werden.

Leider kriege ich aber genau das nicht so richtig hin. Könnt ihr mir da weiterhelfen? Ich habe das schon mit einem Notify auf eine Änderung von Tsoll-Vorlauf-Z2 probiert und dann getriggert Tsoll-Vorlauf-Z1 schreiben lassen. Allerdings ist er dann mit dem zyklischen Auslesen der Register durcheinander gekommen und hatte viele modbus Zugriffs-Timeouts.

Danke und schöne Grüße,
Breitbanddilettant
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 03 Dezember 2020, 16:25:29
Zitat von: breitbanddilettant am 03 Dezember 2020, 15:11:43
Ich würde gerne den Sollwert der Vorlauftemperatur der Zone 1 automatisch anpassen, wenn sich die Vorlauftemperatur der Zone 2 ändert.

Das heißt also, dass ich Tsoll-Vorlauf-Z2 auf 31 setzte und das entsprechende holding Register geschrieben wird. Dann soll im Anschluss automatisch Tsoll-Vorlauf-Z1 auf den selben Wert wie Tsoll-Vorlauf-Z2 gesetzt werden und auch in das entsprechende Register geschrieben werden.

Wie setzt Du denn Tsoll-Vorlauf-Z2 ? Über fhemweb ? Wenn Du hierfür einen z.B. einen Dummy verwendest, hindert dich ja niemand daran zwei notifys zu machen, die dann Z1 und Z2 setzen.
Mit einem DOIF würde das auch gehen, da kannst Du dann auch zwischen dem set für Z1 und Z2 z.B. einen wait einbauen oder mit cmdpause verhindern, dass da zu oft geändert wird usw.


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: breitbanddilettant am 03 Dezember 2020, 16:53:00
Hallo gadget,

Du meinst so?

Dummy definieren:

define Tsoll-Vorlauf-Dummy dummy
attr Tsoll-Vorlauf-Dummy readingsList Tsoll-Vorlauf


Den Istwert holt sich ftui aus den Ecodan readings "Tsoll-Vorlauf-Z1" und "Tsoll-Vorlauf-Z2". Den neuen Sollwert schreibe ich in ftui in "Tsoll-Vorlauf"
Die Änderung dieses Dummy readings erzeugt dann ein notify und triggert eine z.B. "set Ecodan Tsoll-Vorlauf-Z1 30" Funktion.

define TriggerTsollVLZ1 notify Tsoll-Vorlauf-Dummy|Tsoll-Vorlauf-Dummy:.* set Ecodan Tsoll-Vorlauf-Z1 30


Jetzt sind wir aber bei dem Problem, dass der im notify auszuführende set Befehl wohl nur Werte und keine Variableninhalte verarbeiten kann - sprich: ich bekomme den Inhalt vom Dummy "Tsoll-Vorlauf" nicht an "Tsoll-Vorlauf-Z1" übergeben - ich kann da nur skalare Werte (30, 31, 32, ...) reinschreiben.

Da ich im Programmieren nicht sooooo fit bin, könntest du mir etwas beschreiben, wie das mit DOIF gehen würde? muss ich da eine Funktion in the myutils schreiben? Da kenne ich mich leider echt nicht so gut aus :-(


Vielen Dank und schöne Grüße

Schöne Grüße
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gadget am 03 Dezember 2020, 17:29:14
Hi,

Ich meine sowas hier (per "Raw Definition importieren ") - dein Modbus Device habe ich mit einem dummy simuliert.



defmod di_TsollVorlauf DOIF ## wenn dieser Dummy ein Event erzeugt\
([d_TsollVorlauf])\
  ## diesen set ausfuehrern \
  (set d_Ecodan Tsoll-Vorlauf-Z1 [d_TsollVorlauf])\
  ## 10 Sekunden spaeter diesen hier - siehe wait\
  (set d_Ecodan Tsoll-Vorlauf-Z2 [d_TsollVorlauf])\

attr di_TsollVorlauf do always
attr di_TsollVorlauf room Spielwiese
attr di_TsollVorlauf wait 0,10

defmod d_Ecodan dummy
attr d_Ecodan readingList Tsoll-Vorlauf-Z1 Tsoll-Vorlauf-Z2
attr d_Ecodan room Spielwiese

defmod d_TsollVorlauf dummy
attr d_TsollVorlauf event-on-change-reading state
attr d_TsollVorlauf room Spielwiese
attr d_TsollVorlauf setList 16 17 18 19 20 21 22 23 25 27 29 31 33 35 37 40 44





Grüße, gadget
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: breitbanddilettant am 03 Dezember 2020, 21:28:53
sehr cool - das hat geklappt

Danke!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: breitbanddilettant am 04 Dezember 2020, 15:14:36
Hallo Zusammen,

ich habe nun ein neues Problem mit dem Modbus Interface. Ich bekomme immer mehr timeouts der readings und weiß nicht woran das liegt. Schon früher hatte ich timeouts. Nun habe ich vorhin fhem geupdated in der Hoffnung, dass es besser wird, und bekomme jetzt noch mehr timeouts.

Zitat
2020.12.04 14:54:43 2: eventTypes: loaded 352 events from ./log/eventTypes.txt
2020.12.04 14:54:43 3: ModbusBus: defined as /dev/ttyUSB0@9600
2020.12.04 14:54:43 3: Ecodan: defined with id 1, interval 60, protocol default (RTU), mode master
2020.12.04 14:54:43 3: Ecodan: RegisterAtIODev called from SetIODev registers Ecodan at ModbusBus with id 1, MODE master, PROTOCOL RTU
2020.12.04 14:54:49 3: HourCounter HourCounter Initialize.220 Init Done with Version 1.0.1.2 - 24.12.2014
2020.12.04 14:54:49 0: HourCounter WPVerbrauch_HourCounter Define.228 parameters: WPVerbrauch_HourCounter HourCounter GPIO15:Counter:.* GPIO15:Pinlevel:.low
2020.12.04 14:54:49 1: Including ./log/fhem.save
2020.12.04 14:54:49 3: Ecodan: RegisterAtIODev called from SetIODev registers Ecodan at ModbusBus with id 1, MODE master, PROTOCOL RTU
2020.12.04 14:54:49 3: Ecodan: Notify / Init: using ModbusBus for communication
2020.12.04 14:54:49 3: Opening ModbusBus device /dev/ttyUSB0
2020.12.04 14:54:49 3: Setting ModbusBus serial parameters to 9600,8,N,1
2020.12.04 14:54:49 3: ModbusBus device opened
2020.12.04 14:54:49 1: usb create starting
2020.12.04 14:54:49 3: Probing ZWDongle device /dev/serial0
2020.12.04 14:54:49 1: ZWDongle: Can't open /dev/serial0: Permission denied
2020.12.04 14:54:49 3: Probing ZWDongle device /dev/serial1
2020.12.04 14:54:50 3: Probing CUL device /dev/ttyAMA0
2020.12.04 14:54:50 3: Probing TCM_ESP3 device /dev/ttyAMA0
2020.12.04 14:54:50 3: Probing ZWDongle device /dev/ttyAMA0
2020.12.04 14:54:50 3: Probing SIGNALDuino device /dev/ttyAMA0
2020.12.04 14:54:50 3: Probing MYSENSORS device /dev/ttyAMA0
2020.12.04 14:54:50 3: Probing ArduCounter device /dev/ttyAMA0
2020.12.04 14:54:51 3: Probing ElsnerWS device /dev/ttyAMA0
2020.12.04 14:54:52 3: Probing FRM device /dev/ttyAMA0
2020.12.04 14:54:57 3: Probing CUL device /dev/ttyS0
2020.12.04 14:54:57 1: CUL: Can't open /dev/ttyS0: Permission denied
2020.12.04 14:54:57 1: usb create end
2020.12.04 14:54:57 0: Featurelevel: 6
2020.12.04 14:54:57 0: Server started with 31 defined entities (fhem.pl:23278/2020-12-02 perl:5.028001 os:linux user:fhem pid:2556)
2020.12.04 14:55:04 0: HourCounter WPVerbrauch_HourCounter Run.598 first run done countsOverall:2299318
2020.12.04 14:55:16 3: telnetForBlockingFn_1607090116: port 35235 opened
2020.12.04 14:59:00 3: ModbusBus: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 37, len 1 for device Ecodan reading Warmwasser-Start (getUpdate), queued 3.37 secs ago, sent 2.63 secs ago, read buffer empty
2020.12.04 14:59:01 3: ModbusBus: read got new data while idle, drop buffer 0103020000b844
2020.12.04 15:00:01 3: ModbusBus: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 99, len 1 for device Ecodan reading T-Aussen (getUpdate), queued 4.53 secs ago, sent 2.98 secs ago, read buffer empty
2020.12.04 15:00:01 3: ModbusBus: read got new data while idle, drop buffer 0103020028b85a
2020.12.04 15:00:07 3: ModbusBus: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 29, len 1 for device Ecodan reading AC-Modus-Z2 (getUpdate), queued 10.09 secs ago, sent 3.70 secs ago, read buffer empty
2020.12.04 15:00:07 3: ModbusBus: read got new data while idle, drop buffer 01030200017984
2020.12.04 15:00:15 3: ModbusBus: Timeout waiting for a modbus response request: id 1, fCode 3, type h, adr 80, len 1 for device Ecodan reading Waermequelle (getUpdate), queued 17.97 secs ago, sent 3.34 secs ago, read buffer empty
2020.12.04 15:00:15 3: ModbusBus: read got new data while idle, drop buffer 0103020000b844

Hier meine Modubus Konfiguration:


###################################
######### Define Modbus ###########
###################################

define ModbusBus Modbus /dev/ttyUSB0@9600
setuuid ModbusBus 5dee511c-f33f-9858-4f2a-a99a0e6119e1eb3e
attr ModbusBus room Heizung

###################################
######### Define Ecodan ###########
###################################

define Ecodan ModbusAttr 1 60
setuuid Ecodan 5dee5132-f33f-9858-e581-6a34208d19a2f8d9
attr Ecodan userattr dev-h-defPoll obj-h102-expr obj-h102-reading obj-h104-expr obj-h104-reading obj-h106-expr obj-h106-reading obj-h108-expr obj-h108-reading obj-h110-expr obj-h110-reading obj-h112-expr obj-h112-reading obj-h114-expr obj-h114-reading obj-h116-expr obj-h116-reading obj-h118-expr obj-h118-reading obj-h12-expr obj-h12-reading obj-h127-reading obj-h25-hint obj-h25-max obj-h25-min obj-h25-polldelay obj-h25-reading obj-h25-set obj-h26-reading obj-h28-hint obj-h28-max obj-h28-min obj-h28-polldelay obj-h28-reading obj-h28-set obj-h282-reading obj-h283-expr obj-h283-reading obj-h284-reading obj-h285-expr obj-h285-reading obj-h286-reading obj-h287-expr obj-h287-reading obj-h29-hint obj-h29-max obj-h29-min obj-h29-polldelay obj-h29-reading obj-h29-set obj-h292-reading obj-h293-expr obj-h293-reading obj-h294-reading obj-h295-expr obj-h295-reading obj-h296-reading obj-h297-expr obj-h297-reading obj-h31-expr obj-h31-hint obj-h31-max obj-h31-min obj-h31-polldelay obj-h31-reading obj-h31-set obj-h31-setexpr obj-h33-expr obj-h33-hint obj-h33-max obj-h33-min obj-h33-polldelay obj-h33-reading obj-h33-set obj-h33-setexpr obj-h35-expr obj-h35-hint obj-h35-max obj-h35-min obj-h35-polldelay obj-h35-reading obj-h35-set obj-h35-setexpr obj-h37-hint obj-h37-max obj-h37-min obj-h37-polldelay obj-h37-reading obj-h37-set obj-h67-reading obj-h80-reading obj-h92-expr obj-h92-reading obj-h99-expr obj-h99-reading
attr Ecodan IODev ModbusBus
attr Ecodan dev-h-defPoll 1
attr Ecodan event-aggregator T-Aussen-median:300:none:median:300
attr Ecodan event-min-interval .*:190
attr Ecodan obj-h102-expr $val/100
attr Ecodan obj-h102-reading TV-Ecodan
attr Ecodan obj-h104-expr $val/100
attr Ecodan obj-h104-reading TR-Ecodan
attr Ecodan obj-h106-expr $val/100
attr Ecodan obj-h106-reading T-Warmwasser
attr Ecodan obj-h108-expr $val/100
attr Ecodan obj-h108-reading TV-Z1
attr Ecodan obj-h110-expr $val/100
attr Ecodan obj-h110-reading TR-Z1
attr Ecodan obj-h112-expr $val/100
attr Ecodan obj-h112-reading TV-Z2
attr Ecodan obj-h114-expr $val/100
attr Ecodan obj-h114-reading TR-Z2
attr Ecodan obj-h116-expr $val/100
attr Ecodan obj-h116-reading TV-Ofen
attr Ecodan obj-h118-expr $val/100
attr Ecodan obj-h118-reading TR-Ofen
attr Ecodan obj-h12-expr $val == 8000 ? 0 : $val
attr Ecodan obj-h12-reading Error-Ecodan
attr Ecodan obj-h127-reading EinAus-Ausseneinheit
attr Ecodan obj-h25-hint 0,1
attr Ecodan obj-h25-max 1
attr Ecodan obj-h25-min 0
attr Ecodan obj-h25-polldelay 20
attr Ecodan obj-h25-reading EinAus-System
attr Ecodan obj-h25-set 1
attr Ecodan obj-h26-reading Arbeitsmodus
attr Ecodan obj-h28-hint 1,2,4
attr Ecodan obj-h28-max 4
attr Ecodan obj-h28-min 0
attr Ecodan obj-h28-polldelay 20
attr Ecodan obj-h28-reading AC-Modus-Z1
attr Ecodan obj-h28-set 1
attr Ecodan obj-h282-reading W-Verbrauch-Heizung-kW
attr Ecodan obj-h283-expr $val * 10
attr Ecodan obj-h283-reading W-Verbrauch-Heizung-W
attr Ecodan obj-h284-reading W-Verbrauch-Kuehlen-kW
attr Ecodan obj-h285-expr $val * 10
attr Ecodan obj-h285-reading W-Verbrauch-Kuehlen-W
attr Ecodan obj-h286-reading W-Verbrauch-Warmwasser-kW
attr Ecodan obj-h287-expr $val * 10
attr Ecodan obj-h287-reading W-Verbrauch-Warmwasser-W
attr Ecodan obj-h29-hint 1,2,4
attr Ecodan obj-h29-max 4
attr Ecodan obj-h29-min 0
attr Ecodan obj-h29-polldelay 20
attr Ecodan obj-h29-reading AC-Modus-Z2
attr Ecodan obj-h29-set 1
attr Ecodan obj-h292-reading W-Erzeugt-Heizung-kW
attr Ecodan obj-h293-expr $val * 10
attr Ecodan obj-h293-reading W-Erzeugt-Heizung-W
attr Ecodan obj-h294-reading W-Erzeugt-Kuehlen-kW
attr Ecodan obj-h295-expr $val * 10
attr Ecodan obj-h295-reading W-Erzeugt-Kuehlen-W
attr Ecodan obj-h296-reading W-Erzeugt-Warmwasser-kW
attr Ecodan obj-h297-expr $val * 10
attr Ecodan obj-h297-reading W-Erzeugt-Warmwasser-W
attr Ecodan obj-h31-expr $val/100
attr Ecodan obj-h31-hint 45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60
attr Ecodan obj-h31-max 60
attr Ecodan obj-h31-min 45
attr Ecodan obj-h31-polldelay 20
attr Ecodan obj-h31-reading Tsoll-Warmwasser
attr Ecodan obj-h31-set 1
attr Ecodan obj-h31-setexpr $val * 100
attr Ecodan obj-h33-expr $val/100
attr Ecodan obj-h33-hint 26,28,30,31,32,33,34,35,36,37,38,39,40
attr Ecodan obj-h33-max 43
attr Ecodan obj-h33-min 25
attr Ecodan obj-h33-polldelay 20
attr Ecodan obj-h33-reading Tsoll-Vorlauf-Z1
attr Ecodan obj-h33-set 1
attr Ecodan obj-h33-setexpr $val*100
attr Ecodan obj-h35-expr $val/100
attr Ecodan obj-h35-hint 26,28,30,31,32,33,34,35,36,37,38,39,40
attr Ecodan obj-h35-max 60
attr Ecodan obj-h35-min 10
attr Ecodan obj-h35-polldelay 20
attr Ecodan obj-h35-reading Tsoll-Vorlauf-Z2
attr Ecodan obj-h35-set 1
attr Ecodan obj-h35-setexpr $val*100
attr Ecodan obj-h37-hint 0,1
attr Ecodan obj-h37-max 1
attr Ecodan obj-h37-min 0
attr Ecodan obj-h37-polldelay 20
attr Ecodan obj-h37-reading Warmwasser-Start
attr Ecodan obj-h37-set 1
attr Ecodan obj-h67-reading Abtaubetrieb
attr Ecodan obj-h80-reading Waermequelle
attr Ecodan obj-h92-expr $val/10
attr Ecodan obj-h92-reading Tdelta-Warmwasser
attr Ecodan obj-h99-expr $val > (2**15) ? (($val-(2**16))/10) : $val/10
attr Ecodan obj-h99-reading T-Aussen
attr Ecodan room Heizung
attr Ecodan userReadings kW-Verbrauch-Kuehlen {ReadingsNum("Ecodan","W-Verbrauch-Kuehlen-kW",0) + (ReadingsNum("Ecodan","W-Verbrauch-Kuehlen-W",0)/1000)}, kW-Erzeugt-Kuehlen {ReadingsNum("Ecodan","W-Erzeugt-Kuehlen-kW",0) + (ReadingsNum("Ecodan","W-Erzeugt-Kuehlen-W",0)/1000)}, kW-Verbrauch-Heizung {ReadingsNum("Ecodan","W-Verbrauch-Heizung-kW",0) + (ReadingsNum("Ecodan","W-Verbrauch-Heizung-W",0)/1000)}, kW-Erzeugt-Heizung {ReadingsNum("Ecodan","W-Erzeugt-Heizung-kW",0) + (ReadingsNum("Ecodan","W-Erzeugt-Heizung-W",0)/1000)}, kW-Verbrauch-Warmwasser {ReadingsNum("Ecodan","W-Verbrauch-Warmwasser-kW",0) + (ReadingsNum("Ecodan","W-Verbrauch-Warmwasser-W",0)/1000)}, kW-Erzeugt-Warmwasser {ReadingsNum("Ecodan","W-Erzeugt-Warmwasser-kW",0) + (ReadingsNum("Ecodan","W-Erzeugt-Warmwasser-W",0)/1000)}, COP-Heizung {ReadingsNum("Ecodan","kW-Erzeugt-Heizung",0) / ReadingsNum("Ecodan","kW-Verbrauch-Heizung",0)},COP-Kuehlen {(ReadingsNum("Ecodan","AC-Modus-Z1",0) == 3) ? (ReadingsNum("Ecodan","kW-Erzeugt-Kuehlen",0) / ReadingsNum("Ecodan","kW-Verbrauch-Kuehlen",0)) : 0},COP-Warmwasser {ReadingsNum("Ecodan","kW-Erzeugt-Warmwasser",0) / ReadingsNum("Ecodan","kW-Verbrauch-Warmwasser",0)}, Tsoll-Warmwasser-Up {ReadingsNum("Ecodan","Tsoll-Warmwasser",0) + 1}, Tsoll-Warmwasser-Down {ReadingsNum("Ecodan","Tsoll-Warmwasser",0) - 1}, Tavg-Speicher {(ReadingsNum("Ecodan","TV-Z1",0) + ReadingsNum("Ecodan","TR-Z1",0) + ReadingsNum("1W_TVM_Speicher","temperature",0) + ReadingsNum("1W_TRM_Speicher","temperature",0))/4}, Tsoll-Vorlauf-Z1-Up {ReadingsNum("Ecodan","Tsoll-Vorlauf-Z1",0) + 1}, Tsoll-Vorlauf-Z1-Down {ReadingsNum("Ecodan","Tsoll-Vorlauf-Z1",0) - 1}, Tsoll-Vorlauf-Z2-Up {ReadingsNum("Ecodan","Tsoll-Vorlauf-Z2",0) + 1}, Tsoll-Vorlauf-Z2-Down {ReadingsNum("Ecodan","Tsoll-Vorlauf-Z2",0) - 1}, Error-Ofen {ReadingsNum("Ecodan","TV-Ofen",0) < 65 ? 0 : ReadingsNum("Ecodan","TV-Ofen",0)}, Brenner-Aktiv {(ReadingsNum("Ecodan","Arbeitsmodus",0) == 2 ? 1 : 0)*(ReadingsNum("Ecodan","TV-Ofen",0) > 55 ? 1 : 0)}, Arbeitsmodus-Inkl-Brenner {ReadingsNum("Ecodan","Arbeitsmodus",0) + (ReadingsNum("Ecodan","Brenner-Aktiv",0)*10)}, T-Aussen-median {ReadingsNum("Ecodan","T-Aussen",0)}

######################################################################################
######### Define Dummy for setting two Modbus readings with the same value ###########
######################################################################################

define d_TsollVorlauf dummy
attr d_TsollVorlauf event-on-change-reading state
attr d_TsollVorlauf room Heizung
attr d_TsollVorlauf setList 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

define di_TsollVorlauf DOIF ([d_TsollVorlauf]) (set Ecodan Tsoll-Vorlauf-Z1 [d_TsollVorlauf]) (set Ecodan Tsoll-Vorlauf-Z2 [d_TsollVorlauf])
attr di_TsollVorlauf do always
attr di_TsollVorlauf room Heizung
attr di_TsollVorlauf wait 0,10


Könnt Ihr mir sagen, was hier dafür verantwortlich sein kann, dass sich timeouts häufen? Generiert das Modbus modul eine queue für alle readings (set wie auch get)?

Vielen Dank schonmal
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 Dezember 2020, 16:20:30
Hallo breitbanddilettant,

auf den ersten Blick sieht das so aus, als ob Dein Slave erst nach 4 Sekunden antwortet und der Timeout immer kurz davor zuschlägt.
Nach dem Timeout kommt dann doch noch eine Antworte, die wird dann aber verworfen.
Setz doch mal den Timeout auf 5 Sekunden oder erzeuge ein Log mit Verbose 5 für ModbusBus und Ecodan.
Vielleicht kann man dann noch mehr Details erkennen.

Am Fhem-Update sollte es nicht liegen, da das Modbus-Modul schon lange nicht mehr im SVN aktualisiert wurde.
Eine neue Version gibt es bisher nur hier im Forum.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: breitbanddilettant am 04 Dezember 2020, 17:15:46
Hallo Stefan,

scheint auf den ersten Blick, als dass Attribut

attr Ecodan dev-timing-timeout 5

geholfen hat :-)
Ich warte mal die nächsten Tage ab.

Danke schonmal und schöne Grüße,
Konstantin
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 Dezember 2020, 17:39:53
Hallo Konstantin,

es ist schon ungewöhnlich, dass ein Gerät so lange braucht um zu antworten.
Kannst Du das mal neu starten? Evt. liegt das Problem ja auf der Seite des Slave.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: cocojambo am 06 Dezember 2020, 22:01:20
Ich benutze das Modul um einen SolarEdge Inverter mit zwei Modbuszähler und einer Batterie auszulesen. Bis auf ein paar Adressen werden alle Readings im Intervall aktuallisiert. Gebe ich zB. mit "Get SE_Inverter M_1_AC_Power_C_Battery_in_out" ein, wird der Wert im Reading jedesmal aktuallisiert, aber beim nächsten Intervall nicht mehr. Die beiden Zähler sind bis auf die Adressen gleich, aber nur Zähler 2 wird automatisch aktuallisiert.(siehe Anlage Screenshots)
Ich habe auch die Attribute und Readings gelöscht und "händisch" wieder eingegeben und dann "reload" . Danach erscheinen die Attribute mit allen Werte, aber es erfolgt immer noch keine Aktuallisierung der Readings.

Woran liegt das ? und wie kann ich das ändern?
Ich komme einfach nicht weiter.

Gruß aus Köln
Norbert
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Dezember 2020, 17:31:09
Hallo Norbert,

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

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: cocojambo am 07 Dezember 2020, 17:55:34
Hallo Stefan,

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

Gruß aus Köln
Norbert
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Dezember 2020, 20:45:22
Hallo Norbert,

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

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: cocojambo am 07 Dezember 2020, 21:08:29
Hallo Stefan,

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

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

Ich habe jetzt mal 50 eingesetzt, ist das OK?

attr SE_Inverter dev-h-combine 50

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

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

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

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

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Dezember 2020, 22:10:06
Hallo Norbert,

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

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 08 Dezember 2020, 10:57:42
Hallo zusammen,
als Meister der Unwissenheit habe ich dazu auch eine Frage.
Mein Device, ein WR hat ca 120 readings, habe ich da eventuell einen Vorteil "dev-h-combine 8" zu setzen?
Bei "dev-h-combine 16 oder 32" sind einige readings (die längeren Register) mit falschen oder zuviel Zeichen.

Wie bekomme ich den besten/korrekten Wert?

Gruß
    Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 08 Dezember 2020, 14:40:50
WOW 120 Readings und die brauchst du unbedingt alle immer und überall ?
Ich hatte bei meinen SMAs am Anfang auch so ein Sack voll (Jäger & Sammler) bis mir klar wurde das ich in Wahrheit fürs Tagesgeschäft 6 Stück brauche :)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 08 Dezember 2020, 15:29:05
Zitat von: Wzut am 08 Dezember 2020, 14:40:50
WOW 120 Readings und die brauchst du unbedingt alle immer und überall ?
Ich hatte bei meinen SMAs am Anfang auch so ein Sack voll (Jäger & Sammler) bis mir klar wurde das ich in Wahrheit fürs Tagesgeschäft 6 Stück brauche :)
Ich schreibe sie ja nicht in die DbLog, da würde die ja dicke Backen bekommen :-)
Allerdings sehe ich gerne was da wäre, aber ich habe auch schon nachgedacht ein Device mit kompletter Definition anzulegen und ein mit minimum.
Es wäre jetzt auch an der Zeit mal einen Modul zu exportieren.
Gruß
    Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Dezember 2020, 16:27:48
Hallo Christian,

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

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

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

Bei verbose 5 sieht man das gut im Log.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: gerry1 am 08 Dezember 2020, 20:41:49
hallo
Hilfe hab da ein Problem,
ist: windows 10 >DWH300D+ komuniziert über qmod master (usb-rs485 Adapter an com3) :D
soll: fhem soll steuerung übernehmen.
hab gedacht mit Internals:
   DEF        com3@19200,8,E,1

   DeviceName com3@19200,8,E,1

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

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

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

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


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

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

liebe grüsse an euch
gerry1
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Dezember 2020, 12:11:04
Hallo,

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

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 12 Dezember 2020, 15:37:02
Hallo Ihr, ich muß kurz mal eine unqualifizierte Frage stellen.

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

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

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

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

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

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

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

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

Wenn einer mich erleuchten könnte?

lieb Gruß
H.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Dezember 2020, 16:18:10
Hallo holle75,

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

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 13 Dezember 2020, 18:03:44
Danke Stefan, die ganzen HEX Werte, Register gibt es übersichtlich vom Hersteller.

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

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

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

Gruß!
H.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: technikki79 am 16 Dezember 2020, 19:22:45
Ich hatte gerade ein ähnliches Problem und ihr konntet mir sehr helfen mit euren antworten. danke
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 25 Dezember 2020, 20:29:08
Hallo,

hier nochmal eine neue Version mit der Bitte diese zu testen.
Wenn keine neuen Probleme auftreten, würde ich sie demnächst einchecken.
Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD und wird erst beim Neustart von Fhem geladen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 26 Dezember 2020, 17:06:21
habe deine Module mal eingebaut, nach restart kamen folgende Fehlermeldungen:

PERL WARNING: Argument "once" isn't numeric in addition (+) at ./FHEM/98_Modbus.pm line 3710, <FH> line 24705.
PERL WARNING: Invalid conversion in sprintf: end of string at lib/FHEM/HTTPMOD/Utils.pm line 419, <FH> line 24705.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Dezember 2020, 17:53:03
Hallo laserichi,

vielen Dank für's Testen!
die erste Meldung ist ein Fehler, der vermutlich schon immer im Modul war. "once" wurde nicht wie in der Doku beschrieben als Wert von polldelay abgefragt sondern als Wert von poll.
Das habe ich jetzt behoben.

Bevor ich eine neue Version poste, würde ich gerne auch noch die zweite Meldung beheben. Die kommt von einer Format-Angabe.
Um das nachstellen zu können, wäre es sehr hilfreich, wenn Du einen Auszug aus dem Log mit Verbose 5 posten könntest. Da sollte dann stehen, was für ein Wert mit welchem Format-String zu der Meldung führt.

Gruss / vielen Dank
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 26 Dezember 2020, 18:51:46
das mit verbose ist etwas schwierig, ich habe im global den verbose einmal gesetzt und dann meine Tankstellenabfragen da die ja httpmod nutzen aber konnte weiter nichts finden.
An welcher stelle sollte ich da noch verbose 5 setzen ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Funnel am 26 Dezember 2020, 22:17:13
Hallo Stefan,

ich führe meinen Ursprungsthread (https://forum.fhem.de/index.php/topic,116974.0.html) mal hier fort, um das ganze etwas zusammen zu halten. Der von mir berichtete Fehler im passive listening Modus scheint behoben, das Modul läuft jetzt seit 10 Stunden fehlerfrei. Hier zunächst einmal vielen Dank für deine Arbeit und das wirklich tolle Modbus Modul.

Ich habe jetzt allerdings einen Fehler von dem ich nicht weiß ob er neu ist bzw. ob es überhaupt ein Fehler ist oder ich eine fehlerhafte Konfiguration habe. Ich habe einen Modbus TCP Master mit 2 Datenobjekten angelegt, von denen jedoch immer nur eins (obj-i5016-reading DC_Power) im 60 Sekunden Intervall aktualisiert wird. Entferne ich dieses Objekt wird das andere verbleibende Objekt (obj-i13022-reading Battery_Level) aktualisiert. Wenn ich das Attribut "closeAfterResponse" auf 0 setze funktioniert das ganze wie gewünscht mit beiden Objekten, allerdings habe ich dann meinen Wechselrichter für andere FHEM unabhängige Tasks die ich zur Zeit noch brauche blockiert.

Internals:
   DEF        1 60 192.168.2.113:502 TCP
   DeviceName 192.168.2.113:502
   EXPECT     idle
   FUUID      5fe72a85-f33f-2788-89fd-f6a4cdbfcb141377
   IODev      Sungrow
   Interval   60
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.8 - 25.12.2020
   NAME       Sungrow
   NOTIFYDEV  global
   NR         390
   NTFY_ORDER 50-Sungrow
   PROTOCOL   TCP
   STATE      disconnected
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 4
   nextOpenDelay 60
   Helper:
     DBLOG:
       DC_Power:
         myDbLog:
           TIME       1609016388.80555
           VALUE      0
   OLDREADINGS:
   READ:
     BUFFER     
   READINGS:
     2020-12-26 21:33:27   Battery_Level   7.6
     2020-12-26 21:59:48   DC_Power        0
     2020-12-26 21:59:48   state           disconnected
   REMEMBER:
     lid        1
     lname      Sungrow
     lrecv      1609016388.79634
     lsend      1609016388.79089
   defptr:
     Sungrow    1
   gotReadings:
     DC_Power   0
   lastRead:
     h13023     1608986661.47167
     i13022     1609014807.94357
     i13023     1608986841.46699
     i5016      1609016388.80405
     i5060      1609014688.44647
Attributes:
   DbLogInclude DC_Power
   closeAfterResponse 1
   dev-i-defPoll 1
   dev-type-U16-expr $val/10
   dev-type-U16-len 1
   dev-type-U16-unpack n
   dev-type-U32-len 2
   dev-type-U32-unpack L<
   disable    0
   icon       sani_solar
   obj-i13022-reading Battery_Level
   obj-i13022-type U16
   obj-i5016-reading DC_Power
   obj-i5016-type U32
   room       Keller
   silentReconnect 1
   verbose    5


2020.12.26 22:14:16 5: Sungrow: GetUpdate called from Fhem internal timer
2020.12.26 22:14:16 4: Sungrow: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 60.0 sec at 2020-12-26 22:15:16, interval 60
2020.12.26 22:14:16 5: Sungrow: GetUpdate objects from attributes: i5016 i13022
2020.12.26 22:14:16 5: Sungrow: GetUpdate full object list: i13022 i5016
2020.12.26 22:14:16 5: Sungrow: GetUpdate check i13022 => Battery_Level, poll = 1, last = 1609017016.45331
2020.12.26 22:14:16 4: Sungrow: GetUpdate will request Battery_Level
2020.12.26 22:14:16 5: Sungrow: GetUpdate check i5016 => DC_Power, poll = 1, last = 1609017197.33515
2020.12.26 22:14:16 4: Sungrow: GetUpdate will request DC_Power
2020.12.26 22:14:16 5: Sungrow: GetUpdate tries to combine read commands
2020.12.26 22:14:16 5: Sungrow: GetUpdate cant combine request for DC_Power / i5016 with Battery_Level / i13022, span 8007 > max 1
2020.12.26 22:14:16 4: Sungrow: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i5016, len 2, tid 79, master device Sungrow, reading DC_Power (getUpdate)
2020.12.26 22:14:16 5: Sungrow: QueueRequest called from DoRequest with i5016, qlen 0 from master Sungrow through io device Sungrow
2020.12.26 22:14:16 5: Sungrow: ProcessRequestQueue called from QueueRequest as direct:Sungrow, qlen 1, request: request: id 1, read fc 4 i5016, len 2, tid 79, master device Sungrow, reading DC_Power (getUpdate), queued 0.00 secs ago
2020.12.26 22:14:16 5: Sungrow: open called from ProcessRequestQueue, busyOpenDev 0
2020.12.26 22:14:16 4: Sungrow: open trying to open connection to 192.168.2.113:502
2020.12.26 22:14:16 3: Opening Sungrow device 192.168.2.113:502
2020.12.26 22:14:16 5: HttpUtils url=http://192.168.2.113:502/
2020.12.26 22:14:16 4: IP: 192.168.2.113 -> 192.168.2.113
2020.12.26 22:14:16 5: Sungrow: StartQueueTimer called from DoOpen sets internal timer to process queue in 0.500 seconds
2020.12.26 22:14:16 5: Sungrow: ProcessRequestQueue returns, device is disconnected, qlen 1, try again in 1 seconds
2020.12.26 22:14:16 4: Sungrow: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i13022, len 1, tid 4, master device Sungrow, reading Battery_Level (getUpdate)
2020.12.26 22:14:16 5: Sungrow: QueueRequest called from DoRequest with i13022, qlen 1 from master Sungrow through io device Sungrow
2020.12.26 22:14:16 5: Sungrow: ProcessRequestQueue called from QueueRequest as direct:Sungrow, qlen 2, request: request: id 1, read fc 4 i5016, len 2, tid 79, master device Sungrow, reading DC_Power (getUpdate), queued 0.01 secs ago
2020.12.26 22:14:16 5: Sungrow: open called from ProcessRequestQueue, busyOpenDev 1
2020.12.26 22:14:16 5: Sungrow: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2020.12.26 22:14:16 5: Sungrow: ProcessRequestQueue returns, device is disconnected, qlen 2, try again in 1 seconds
2020.12.26 22:14:16 4: Sungrow device opened
2020.12.26 22:14:16 4: Sungrow: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 60.0 sec at 2020-12-26 22:15:16, interval 60
2020.12.26 22:14:17 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 2, request: request: id 1, read fc 4 i5016, len 2, tid 79, master device Sungrow, reading DC_Power (getUpdate), queued 1.01 secs ago
2020.12.26 22:14:17 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.26 22:14:17 5: Sungrow: checkDelays sendDelay, last send to same device was 59.984 secs ago, required delay is 0.1
2020.12.26 22:14:17 5: Sungrow: checkDelays commDelay, last communication with same device was 59.978 secs ago, required delay is 0.1
2020.12.26 22:14:17 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 59.978 secs ago, required delay is 0
2020.12.26 22:14:17 4: Sungrow: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 2, sending 004f00000006010413980002 via 192.168.2.113:502, read buffer empty,
request: id 1, read fc 4 i5016, len 2, tid 79, master device Sungrow, reading DC_Power (getUpdate), queued 1.02 secs ago
2020.12.26 22:14:17 5: Sungrow: Send called from ProcessRequestQueue
2020.12.26 22:14:17 5: SW: 004f00000006010413980002
2020.12.26 22:14:17 5: Sungrow: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2020.12.26 22:14:17 5: Sungrow: read buffer: 004f0000000701040400000000
2020.12.26 22:14:17 5: Sungrow: ParseFrameStart called from ReadFn
2020.12.26 22:14:17 4: Sungrow: ParseFrameStart (TCP) extracted id 1, fCode 4, tid 79, dlen 7 and data 0400000000
2020.12.26 22:14:17 5: Sungrow: HandleResponse called from ReadFn
2020.12.26 22:14:17 5: Sungrow: ParseResponse called from HandleResponse
2020.12.26 22:14:17 5: Sungrow: HandleResponse now acts on fcode 4, masterhash Sungrow
2020.12.26 22:14:17 5: Sungrow: HandleResponse calls parseObj with master device Sungrow for parsing data
2020.12.26 22:14:17 5: Sungrow: ParseObj called with data hex 00000000, type i, adr 5016, valuesLen 2, op read
2020.12.26 22:14:17 5: Sungrow: ParseObj unpacked 00000000 with L< to 0
2020.12.26 22:14:17 4: Sungrow: ParseObj assigns value 0 to DC_Power
2020.12.26 22:14:17 5: Sungrow: HandleResponse got 1 readings from ParseObj for Sungrow
2020.12.26 22:14:17 5: Sungrow: ResetExpect for HandleResponse from response to idle
2020.12.26 22:14:17 5: Sungrow: Close called from HandleResponse
2020.12.26 22:14:17 4: Sungrow: Close connection with DevIo_CloseDev
2020.12.26 22:14:17 5: Sungrow: SetState called from DoClose with disconnected sets state and STATE to disconnected
2020.12.26 22:14:17 5: Sungrow: DropBuffer for DoClose clears the reception buffer with 004f0000000701040400000000
2020.12.26 22:14:17 4: Sungrow: HandleResponse done, read buffer empty, id 1, fCode 4, tid 79,
request: id 1, read fc 4 i5016, len 2, tid 79, master device Sungrow, reading DC_Power (getUpdate), queued 1.05 secs ago, sent 0.04 secs ago,
response: id 1, fc 4 i5016, len 2, value 00000000



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Dezember 2020, 22:54:48
Hallo laserichi,

In Deinem Modbus-Device kannst Du auch das Attribut verbose auf 5 setzen.
Das verwendet die Utils von HTTPMOD und hat vermutlich in seiner Konfiguration ein Format-Attribut, mit dem eine Funktion von den Utils nicht klar kommt.

Gruß / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Dezember 2020, 22:58:04
Hallo Thomas,

closeAfterResponse scheint noch nicht richtig zu funktionieren. Das schau ich mir morgen mal näher an.

Gruß / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 27 Dezember 2020, 08:47:33
Ok habe 2 Modbusmodule am Laufen. Der Fehler scheint wohl im Zusammenhang mit dem ModbusSDM630M zu stehen wegen dem - Vorzeichen vielleicht ?

2020.12.27 08:39:12 5: Hausstrom: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2020.12.27 08:39:12 5: Hausstrom: ProcessRequestQueue called from Fhem internal timer as queue:Hausstrom, qlen 6, request: request: id 1, read fc 4 i0, len 40, master device Hausstrom, reading Voltage_L1__V (getUpdate), queued 10.85 secs ago
2020.12.27 08:39:12 5: Hausstrom: checkDelays clientSwitchDelay is not relevant
2020.12.27 08:39:12 5: Hausstrom: checkDelays busDelayRead, last activity on bus  was 0.153 secs ago, required delay is 0
2020.12.27 08:39:12 5: Hausstrom: checkDelays sendDelay, last send to same device was 0.265 secs ago, required delay is 0.7
2020.12.27 08:39:12 5: Hausstrom: checkDelays commDelay, last communication with same device was 0.153 secs ago, required delay is 0.7
2020.12.27 08:39:12 4: Hausstrom: checkDelays found commDelay not over, set timer to try again in 0.547
2020.12.27 08:39:12 5: Hausstrom: ProcessRequestQueue called from Fhem internal timer as queue:Hausstrom, qlen 6, request: request: id 1, read fc 4 i0, len 40, master device Hausstrom, reading Voltage_L1__V (getUpdate), queued 11.44 secs ago
2020.12.27 08:39:12 5: Hausstrom: checkDelays busDelayRead, last activity on bus  was 0.746 secs ago, required delay is 0
2020.12.27 08:39:12 5: Hausstrom: checkDelays clientSwitchDelay is not relevant
2020.12.27 08:39:12 5: Hausstrom: checkDelays commDelay, last communication with same device was 0.746 secs ago, required delay is 0.7
2020.12.27 08:39:12 5: Hausstrom: checkDelays sendDelay, last send to same device was 0.857 secs ago, required delay is 0.7
2020.12.27 08:39:12 4: Hausstrom: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 6, sending 010400000028f014 via 192.168.10.7:23, read buffer empty,
request: id 1, read fc 4 i0, len 40, master device Hausstrom, reading Voltage_L1__V (getUpdate), queued 11.45 secs ago
2020.12.27 08:39:12 5: Hausstrom: Send called from ProcessRequestQueue
2020.12.27 08:39:12 5: SW: 010400000028f014
2020.12.27 08:39:12 5: Hausstrom: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2020.12.27 08:39:12 5: Hausstrom: read buffer: 0104504368e8454367ef954368f42b3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c1
2020.12.27 08:39:12 5: Hausstrom: ParseFrameStart called from ReadFn
2020.12.27 08:39:12 4: Hausstrom: SkipGarbageCheck looking for start byte 01 protocol is RTU, mode is master
2020.12.27 08:39:12 4: Hausstrom: ParseFrameStart (RTU) extracted id 1, fCode 4 and data 504368e8454367ef954368f42b3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bd
2020.12.27 08:39:12 5: Hausstrom: HandleResponse called from ReadFn
2020.12.27 08:39:12 5: Hausstrom: ParseResponse called from HandleResponse
2020.12.27 08:39:12 5: Hausstrom: HandleResponse did not get a valid frame yet, wait for more data
2020.12.27 08:39:12 5: Hausstrom: read buffer: 0104504368e8454367ef954368f42b3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32bde5e
2020.12.27 08:39:12 5: Hausstrom: ParseFrameStart called from ReadFn
2020.12.27 08:39:12 4: Hausstrom: SkipGarbageCheck looking for start byte 01 protocol is RTU, mode is master
2020.12.27 08:39:12 4: Hausstrom: ParseFrameStart (RTU) extracted id 1, fCode 4 and data 504368e8454367ef954368f42b3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b
2020.12.27 08:39:12 5: Hausstrom: HandleResponse called from ReadFn
2020.12.27 08:39:12 5: Hausstrom: ParseResponse called from HandleResponse
2020.12.27 08:39:12 5: Hausstrom: CheckChecksum (called from HandleResponse): de5e is valid
2020.12.27 08:39:12 5: Hausstrom: HandleResponse now acts on fcode 4, masterhash Hausstrom
2020.12.27 08:39:12 5: Hausstrom: HandleResponse calls parseObj with master device Hausstrom for parsing data
2020.12.27 08:39:12 5: Hausstrom: ParseObj called with data hex 4368e8454367ef954368f42b3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b, type i, adr 0, valuesLen 40, op read
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 4368e8454367ef954368f42b3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 232.907302856445
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 232.907302856445 with %.1f V, result is 232.9 V
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 232.9 V to Voltage_L1__V
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i2
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 4367ef954368f42b3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 231.93586730957
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 231.93586730957 with %.1f V, result is 231.9 V
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 231.9 V to Voltage_L2__V
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i4
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 4368f42b3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 232.95378112793
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 232.95378112793 with %.1f V, result is 233.0 V
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 233.0 V to Voltage_L3__V
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i6
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 3d52f6d83f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 0.0515049397945404
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 0.0515049397945404 with %.2f A, result is 0.05 A
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 0.05 A to Current_L1__A
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i8
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 3f6026803f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 0.875587463378906
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 0.875587463378906 with %.2f A, result is 0.88 A
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 0.88 A to Current_L2__A
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i10
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 3f383d8740e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 0.719688832759857
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 0.719688832759857 with %.2f A, result is 0.72 A
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 0.72 A to Current_L3__A
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i12
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 40e762544348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 7.23075294494629
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 7.23075294494629 with %.f W, result is 7 W
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 7 W to Power_L1__W
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i14
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 4348db8b431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 200.85758972168
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 200.85758972168 with %.f W, result is 201 W
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 201 W to Power_L2__W
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i16
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 431b7936413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 155.473480224609
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 155.473480224609 with %.f W, result is 155 W
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 155 W to Power_L3__W
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i18
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 413fef1c434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 11.9958763122559
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 11.9958763122559 with %.1f VA, result is 12.0 VA
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 12.0 VA to Power_L1__VA
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i20
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 434b14844327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 203.080139160156
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 203.080139160156 with %.1f VA, result is 203.1 VA
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 203.1 VA to Power_L2__VA
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i22
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 4327a77cc11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 167.654235839844
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 167.654235839844 with %.1f VA, result is 167.7 VA
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 167.7 VA to Power_L3__VA
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i24
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked c11925a6c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to -9.57169151306152
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats -9.57169151306152 with %.1f VAr, result is -9.6 VAr
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value -9.6 VAr to Power_L1__VAr
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i26
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked c1efb425c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to -29.9629611968994
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats -29.9629611968994 with %.1f VAr, result is -30.0 VAr
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value -30.0 VAr to Power_L2__VAr
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i28
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked c27af2c93f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to -62.7370948791504
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats -62.7370948791504 with %.1f VAr, result is -62.7 VAr
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value -62.7 VAr to Power_L3__VAr
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i30
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 3f1a4f203f7d32c23f6d668ac253bdd0c107c32b with f> to 0.60276985168457
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 0.60276985168457 with %.1f, result is 0.6
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 0.6 to PowerFactor_L1
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i32
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 3f7d32c23f6d668ac253bdd0c107c32b with f> to 0.989055752754211
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 0.989055752754211 with %.1f, result is 1.0
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 1.0 to PowerFactor_L2
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i34
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked 3f6d668ac253bdd0c107c32b with f> to 0.927345871925354
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats 0.927345871925354 with %.1f, result is 0.9
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value 0.9 to PowerFactor_L3
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i36
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked c253bdd0c107c32b with f> to -52.9353637695312
2020.12.27 08:39:12 1: PERL WARNING: Invalid conversion in sprintf: end of string at lib/FHEM/HTTPMOD/Utils.pm line 419.
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats -52.9353637695312 with %.1f %, result is -52.9 %
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value -52.9 % to CosPhi_L1
2020.12.27 08:39:12 5: Hausstrom: ParseObj moves to next object, skip 2 to i38
2020.12.27 08:39:12 5: Hausstrom: ParseObj unpacked c107c32b with f> to -8.48514842987061
2020.12.27 08:39:12 5: Hausstrom: FormatVal for ParseObj formats -8.48514842987061 with %.1f %, result is -8.5 %
2020.12.27 08:39:12 4: Hausstrom: ParseObj assigns value -8.5 % to CosPhi_L2
2020.12.27 08:39:12 5: Hausstrom: HandleResponse got 20 readings from ParseObj for Hausstrom
2020.12.27 08:39:12 5: Hausstrom: ResetExpect for HandleResponse from response to idle
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 Dezember 2020, 10:26:28
Ja, dein Format String %.1f % ist ungültig.

Du müsstest das letzte % verdoppeln.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Funnel am 28 Dezember 2020, 14:00:32
Hallo Stefan,

ich habe noch ein Problem mit dem Modbus-Modul gefunden: Das polldelay Attribut hat in dem von mir benutzten Setup keinerlei Auswirkung, es wird immer in dem Intervall aus dem define gepollt.

Internals:
   DEF        1 30 192.168.2.113:502 TCP
   DeviceName 192.168.2.113:502
   EXPECT     idle
   FD         9
   FUUID      5fe72a85-f33f-2788-89fd-f6a4cdbfcb141377
   IODev      Sungrow
   Interval   30
   LASTOPEN   1609160034.13962
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.8 - 25.12.2020
   NAME       Sungrow
   NOTIFYDEV  global
   NR         390
   NTFY_ORDER 50-Sungrow
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 4
   nextOpenDelay 60
   Helper:
     DBLOG:
       Battery_Level:
         myDbLog:
           TIME       1609160009.39626
           VALUE      38
       DC_Power:
         myDbLog:
           TIME       1609160009.14658
           VALUE      243
   OLDREADINGS:
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2020-12-28 13:53:29   Battery_Level   38
     2020-12-28 13:53:29   DC_Power        243
     2020-12-28 13:53:29   Total_Energy    56600
     2020-12-28 13:53:29   Yearly_Energy   000000000000000000000000000000000000000002360000000000000000
     2020-12-28 13:53:54   state           opened
   REMEMBER:
     lid        1
     lname      Sungrow
     lrecv      1609160009.38946
     lsend      1609160009.38685
   defptr:
     Sungrow    1
   gotReadings:
     Battery_Level 38
   lastRead:
     h13023     1608986661.47167
     i13022     1609160009.39495
     i13023     1608986841.46699
     i5016      1609160009.14469
     i5060      1609014688.44647
     i6249      1609160009.27496
Attributes:
   DbLogInclude DC_Power,Battery_Level
   closeAfterResponse 0
   dev-i-defPoll 1
   dev-type-U16-expr $val/10
   dev-type-U16-len 1
   dev-type-U16-unpack n
   dev-type-U32-len 2
   dev-type-U32-revRegs 0
   disable    0
   icon       sani_solar
   obj-i13022-reading Battery_Level
   obj-i13022-type U16
   obj-i5016-reading DC_Power
   obj-i5016-type U32
   obj-i6249-len 30
   obj-i6249-polldelay 3600
   obj-i6249-reading Yearly_Energy
   obj-i6249-unpack H60
   room       Keller
   silentReconnect 1
   userReadings Total_Energy {SungrowTotalEnergy(ReadingsVal("Sungrow","Yearly_Energy",0))}
   verbose    5


request: id 1, read fc 4 i6249, len 30, tid 213, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.12 secs ago, sent 0.01 secs ago,
response: id 1, fc 4 i6249, len 30, value 000000000000000000000000000000000000000002360000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.28 13:57:29 5: Sungrow: DropFrame - drop 00d50000003f01043c000000000000000000000000000000000000000002360000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.28 13:57:29 5: Sungrow: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2020.12.28 13:57:29 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 6, master device Sungrow, reading Battery_Level (getUpdate), queued 0.12 secs ago
2020.12.28 13:57:29 5: Sungrow: checkDelays sendDelay, last send to same device was 0.012 secs ago, required delay is 0.1
2020.12.28 13:57:29 5: Sungrow: checkDelays commDelay, last communication with same device was 0.008 secs ago, required delay is 0.1
2020.12.28 13:57:29 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.008 secs ago, required delay is 0
2020.12.28 13:57:29 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.28 13:57:29 4: Sungrow: checkDelays found commDelay not over, set timer to try again in 0.092
2020.12.28 13:57:29 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 6, master device Sungrow, reading Battery_Level (getUpdate), queued 0.22 secs ago
2020.12.28 13:57:29 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.104 secs ago, required delay is 0
2020.12.28 13:57:29 5: Sungrow: checkDelays commDelay, last communication with same device was 0.104 secs ago, required delay is 0.1
2020.12.28 13:57:29 5: Sungrow: checkDelays sendDelay, last send to same device was 0.108 secs ago, required delay is 0.1
2020.12.28 13:57:29 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.28 13:57:29 4: Sungrow: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 1, sending 000600000006010432de0001 via 192.168.2.113:502, read buffer empty,
request: id 1, read fc 4 i13022, len 1, tid 6, master device Sungrow, reading Battery_Level (getUpdate), queued 0.22 secs ago
2020.12.28 13:57:29 5: Sungrow: Send called from ProcessRequestQueue
2020.12.28 13:57:29 5: SW: 000600000006010432de0001
2020.12.28 13:57:29 5: Sungrow: read buffer: 0006000000050104020187
2020.12.28 13:57:29 5: Sungrow: ParseFrameStart called from ReadFn
2020.12.28 13:57:29 4: Sungrow: ParseFrameStart (TCP) extracted id 1, fCode 4, tid 6, dlen 5 and data 020187
2020.12.28 13:57:29 5: Sungrow: HandleResponse called from ReadFn
2020.12.28 13:57:29 5: Sungrow: ParseResponse called from HandleResponse
2020.12.28 13:57:29 5: Sungrow: HandleResponse now acts on fcode 4, masterhash Sungrow
2020.12.28 13:57:29 5: Sungrow: HandleResponse calls parseObj with master device Sungrow for parsing data
2020.12.28 13:57:29 5: Sungrow: ParseObj called with data hex 0187, type i, adr 13022, valuesLen 1, op read
2020.12.28 13:57:29 5: Sungrow: ParseObj unpacked 0187 with n to 391
2020.12.28 13:57:29 5: Sungrow: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/10 to 39.1
2020.12.28 13:57:29 4: Sungrow: ParseObj assigns value 39.1 to Battery_Level
2020.12.28 13:57:29 5: Sungrow: HandleResponse got 1 readings from ParseObj for Sungrow
2020.12.28 13:57:29 5: Sungrow: ResetExpect for HandleResponse from response to idle
2020.12.28 13:57:29 4: Sungrow: HandleResponse done, current frame / read buffer: 0006000000050104020187, id 1, fCode 4, tid 6,
request: id 1, read fc 4 i13022, len 1, tid 6, master device Sungrow, reading Battery_Level (getUpdate), queued 0.24 secs ago, sent 0.02 secs ago,
response: id 1, fc 4 i13022, len 1, value 0187
2020.12.28 13:57:29 5: Sungrow: DropFrame - drop 0006000000050104020187


Gruß
Thomas




Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 28 Dezember 2020, 15:00:28
Zitat von: StefanStrobel am 25 Dezember 2020, 20:29:08
Hallo,

hier nochmal eine neue Version mit der Bitte diese zu testen.
Wenn keine neuen Probleme auftreten, würde ich sie demnächst einchecken.
Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD und wird erst beim Neustart von Fhem geladen.

Gruss
   Stefan

Hallo Stefan,

habe die neuen Module auch bei mir getestet. Muste nur noch eine Anpasung machen -->   Modbus::InitializeLD($hash). Jetzt läuft es aber, Zumindestens bei mir.

Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Funnel am 28 Dezember 2020, 18:09:13
Hallo Stefan,

leider hat sich der Modbus im "passive listening" Modus doch noch einmal aufgehangen, mehr als diesen kurzen Ausschnitt des Logs habe ich leider nicht:

016400081020fe0310fffffff0ffffffd100000029ffffffea9d9efe03016400081020fe0310fffffff4ffffffd800000024fffffff19480fe03016400081020fe0310fffffff5ffffffdc0000002bfffffffb70c7fe03016400081020fe0310fffffffbffffffdc00000029ffffffff1e4afe03016400081020fe0310f
ffffffbffffffdb000000300000000425effe03016400081020fe0310fffffffdffffffde0000002e00000007fb7afe03016400081020fe0310ffffffffffffffdc0000002f00000009595cfe03016400081020fe0310fffffffdffffffe100000033000000104287fe03016400081020fe031000000000ffffffe10000
0033000000131035fe03016400081020fe031000000000ffffffe20000003300000016c4c6fe03016400081020fe031000000001ffffffe40000003400000018d9e3fe03016400081020fe031000000001ffffffe4000000370000001c9c20fe03016400081020fe031000000003ffffffe6000000360000001fffc3fe0
3016400081020fe031000000004ffffffe600000037000000214894fe03016400081020fe031000000004ffffffe70000003a000000256906fe03016400081020fe031000000006ffffffe800000038000000261675fe03016400081020fe031000000007ffffffe90000003900000028a560fe03016400081020fe0310
00000006ffffffe900000039000000296621fe03016400081020fe031000000006ffffffe800000038000000261675fe03016400081020fe031000000004ffffffe600000038000000239d54fe03016400081020fe031000000000ffffffe50000003300000019a2f2fe03016400081020fe031000000000ffffffe5000
0003200000016df36fe03016400081020fe0310fffffffeffffffde000000310000000c2abcfe03016400081020fe0310fffffffaffffffdf0000002f00000007c06dfe03016400081020fe0310fffffffdffffffd90000003000000000348afe03016400081020fe0310fffffffaffffffd70000002bfffffffd97fafe
03016400081020fe0310fffffff4ffffffda0000002dfffffffbd1e6fe03016400081020fe0310fffffff3ffffffd80000002bfffffff68a04fe03016400081020fe0310fffffff8ffffffd800000025fffffff5b94ffe03016400081020fe0310fffffffaffffffd200000025fffffff1c16efe03016400081020fe031
0ffffffefffffffd900000025ffffffed8102fe03016400081020fe0310fffffff5ffffffd000000028ffffffede009fe03016400081020fe0310ffffffedffffffd00000002bffffffe845d2fe03016400081020fe0310fffffff6ffffffd00000001fffffffe511c8fe03016400081020fe0310ffffffefffffffcd00
000027ffffffe4c7c4fe03016400081020fe0310ffffffedffffffd600000020ffffffe38a74fe03016400081020fe0310ffffffe9ffffffce0000002cffffffe33ef1fe03016400081020fe0310fffffff0ffffffd60000001affffffe03fadfe03000a000c71c2fe03180000b85a0000b85a000000000000000000000
00000009c7efc2ffe03016400081020fe0310ffffffe8ffffffd700000021ffffffe0f620fe0300610003401afe0306094b0941094bd5f9fe03016400081020fe0310fffffff2ffffffd10000001dffffffe0ab1ffe0300770001201ffe03021384a103fe03016400081020fe0310ffffffeeffffffd60000001effffff
e127b3fe03016400081020fe0310fffffff3ffffffd300000022ffffffe8a53dfe03016400081020fe0310ffffffecffffffd500000029ffffffea8002fe03016400081020fe0310fffffff6ffffffd300000026ffffffef193afe03016400081020fe0310fffffff6ffffffd800000026fffffff5ebc1fe03016400081
020fe0310fffffff7ffffffd600000030fffffffc2ce5fe03016400081020fe0310fffffffbffffffd90000002bffffffff58dafe03016400081020fe0310fffffffaffffffda0000002e0000000142fffe03016400081020fe0310fffffff8ffffffe00000002e000000056edffe03016400081020fe0310fffffffcff
ffffdd0000003100000009f90dfe03016400081020fe0310fffffffbffffffdf000000330000000c52e9fe03016400081020fe031000000000ffffffdf00000033000000118995fe03016400081020fe0310fffffffeffffffe100000034000000127345fe03016400081020fe0310fffffffcffffffe30000003300000
0159965fe03016400081020fe0310ffffffffffffffe300000034000000152966fe0301640008
2020.12.28 18:01:02 4: RS485_P3: SkipGarbageCheck special feature without given id
2020.12.28 18:01:02 4: RS485_P3: SkipGarbageCheck found potential id 254 at 0
2020.12.28 18:01:02 4: RS485_P3: ParseFrameStart (RTU) extracted id 254, fCode 0 and data 000000e883fe03016400081020fe031000000007ffffffe80000000effffffff5cbefe03016400081020fe03100000001bffffffe7fffffffcffffffff5fc3fe03016400081020fe03100000000dfffff
ff3fffffffefffffffe2f95fe03016400081020fe031000000019ffffffdd00000009ffffffffaa31fe03016400081020fe03100000001bffffffe9fffffffc000000001237fe03016400081020fe03100000000cfffffff300000000000000009090fe03016400081020fe03100000001bffffffde0000000600000000
ec16fe03016400081020fe031000000013ffffffee00000000000000002f5ffe03016400081020fe031000000017ffffffdd0000000afffffffff8bffe03016400081020fe031000000019ffffffe7fffffffdfffffffde480fe03016400081020fe03100000000affffffef00000002fffffffdf803fe0301640008102
0fe03100000001bffffffe300000000fffffffea8d3fe03016400081020fe03100000000ffffffff1ffffffffffffffffcdb7fe03016400081020fe031000000017ffffffda0000000f00000000131bfe03016400081020fe03100000001dffffffe4ffffffff000000000761fe03016400081020fe03100000000cffff
ffe300000010000000009c93fe03016400081020fe03100000001cffffffdc0000000700000000c3f1fe03016400081020fe03100000001affffffeafffffffc000000000446fe03016400081020fe03100000000bffffffe40000001000000000b1e4fe03016400081020fe03100000001cffffffde00000004fffffff
f9f05fe03016400081020fe03100000000bfffffff300000000000000009bd7fe03016400081020fe031000000009ffffffe40000001300000000f2a6fe03016400081020fe03100000001affffffda0000000b00000000f196fe03016400081020fe03100000000dfffffff20000000100000000a241fe030164000810
20fe031000000009ffffffe5000000110000000086f6fe03016400081020fe03100000001effffffe4fffffffcfffffffe86f6fe03016400081020fe03100000000dfffffff3ffffffffffffffffd395fe03016400081020fe031000000006ffffffe800000010fffffffff63dfe03016400081020fe03100000001ffff
fffe2fffffffdfffffffe9217fe03000a000c71c2fe03180000b8590000b85900000000000000000000000000009c7d7fedfe03016400081020fe031000000006ffffffe200000015fffffffe855dfe0300610003401afe030609410941094b4df8fe03016400081020fe03100000001effffffe2fffffffeffffffff15
56fe0300770001201ffe0302138560c3fe03016400081020fe031000000016ffffffdc0000000bfffffffd4baffe03016400081020fe031000000013fffffff2fffffff7fffffffd961bfe03016400081020fe031000000005fffffff100000006fffffffd9c6cfe03016400081020fe031000000008ffffffe00000001
5fffffffe8ab3fe03016400081020fe03100000001cffffffe6fffffffbfffffffd6d15fe03016400081020fe03100000000dfffffff2fffffffefffffffd6204fe03016400081020fe031000000013ffffffdb00000010ffffffff8459fe03016400081020fe03100000001affffffe4000000010000000071f6fe0301
6400081020fe031000000017ffffffde0000000a00000000eddbfe03016400081020fe03100000001dffffffe6fffffffd0000000067c1fe03016400081020fe03100000000efffffff300000001000000016bd2fe03016400081020fe03100000001cffffffdf000000070000000256c0fe03016400081020fe0310000
0001bffffffebfffffffc00


Eventuell kannst du damit was anfangen.

Gruß
Thomas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Dezember 2020, 16:48:44
Hallo Thomas,

zum pollDelay: leider enthält der von Dir gepostete Log-Ausschnitt den relevanten Teil nicht.
Ein paar Zeilen früher (Beginn von GetUpdate) wäre vermutlich zu sehen gewesen, warum i6249 abgefragt wird.
Ich versuche das mal nachzustellen. Falls Du das Log noch hast, wäre das aber schneller zu klären ;-)

zum passiven Modus:
Ich habe noch ein paar weitere Optimierungen für den speziellen Fall bei Dir eingebaut (wenn ein Master den Request innerhalb kurzer Zeit mehrfach wiederholt).
Das poste ich sobald ich noch ein paar weitere Änderungen und Tests gemacht habe.

Gruss
   Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Funnel am 29 Dezember 2020, 17:28:44
Hallo Stefan,
hier ein weiteres Log zum Thema pollDelay:

2020.12.29 17:22:44 5: Sungrow: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects inactive active
2020.12.29 17:22:44 5: Sungrow: UpdateSetList: getList=
2020.12.29 17:22:44 5: Sungrow: GetUpdate called from Fhem internal timer
2020.12.29 17:22:44 4: Sungrow: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 30.0 sec at 2020-12-29 17:23:14, interval 30
2020.12.29 17:22:44 5: Sungrow: GetUpdate objects from attributes: i5016 i6249 i13022
2020.12.29 17:22:44 5: Sungrow: GetUpdate full object list: i13022 i5016 i6249
2020.12.29 17:22:44 5: Sungrow: GetUpdate check i13022 => Battery_Level, poll = 1, last = 1609258935.20449
2020.12.29 17:22:44 4: Sungrow: GetUpdate will request Battery_Level
2020.12.29 17:22:44 5: Sungrow: GetUpdate check i5016 => DC_Power, poll = 1, last = 1609258934.99081
2020.12.29 17:22:44 4: Sungrow: GetUpdate will request DC_Power
2020.12.29 17:22:44 5: Sungrow: GetUpdate check i6249 => Yearly_Energy, poll = 1, last = 1609258935.09667
2020.12.29 17:22:44 4: Sungrow: GetUpdate will skip Yearly_Energy, delay not over
2020.12.29 17:22:44 5: Sungrow: GetUpdate tries to combine read commands
2020.12.29 17:22:44 5: Sungrow: GetUpdate cant combine request for DC_Power / i5016 with Yearly_Energy / i6249, span 1263 > max 1
2020.12.29 17:22:44 5: Sungrow: GetUpdate cant combine request for Yearly_Energy / i6249 with Battery_Level / i13022, span 6774 > max 1
2020.12.29 17:22:44 4: Sungrow: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i5016, len 2, tid 216, master device Sungrow, reading DC_Power (getUpdate)
2020.12.29 17:22:44 5: Sungrow: QueueRequest called from DoRequest with i5016, qlen 0 from master Sungrow through io device Sungrow
2020.12.29 17:22:44 5: Sungrow: ProcessRequestQueue called from QueueRequest as direct:Sungrow, qlen 1, request: request: id 1, read fc 4 i5016, len 2, tid 216, master device Sungrow, reading DC_Power (getUpdate), queued 0.00 secs ago
2020.12.29 17:22:44 5: Sungrow: checkDelays sendDelay, last send to same device was 29.776 secs ago, required delay is 0.1
2020.12.29 17:22:44 5: Sungrow: checkDelays commDelay, last communication with same device was 29.774 secs ago, required delay is 0.1
2020.12.29 17:22:44 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:22:44 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 29.774 secs ago, required delay is 0
2020.12.29 17:22:44 4: Sungrow: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 1, sending 00d800000006010413980002 via 192.168.2.113:502, read buffer empty,
request: id 1, read fc 4 i5016, len 2, tid 216, master device Sungrow, reading DC_Power (getUpdate), queued 0.01 secs ago
2020.12.29 17:22:44 5: Sungrow: Send called from ProcessRequestQueue
2020.12.29 17:22:44 5: SW: 00d800000006010413980002
2020.12.29 17:22:44 4: Sungrow: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i6249, len 30, tid 182, master device Sungrow, reading Yearly_Energy (getUpdate)
2020.12.29 17:22:44 5: Sungrow: QueueRequest called from DoRequest with i6249, qlen 0 from master Sungrow through io device Sungrow
2020.12.29 17:22:44 5: Sungrow: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2020.12.29 17:22:44 4: Sungrow: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i13022, len 1, tid 19, master device Sungrow, reading Battery_Level (getUpdate)
2020.12.29 17:22:44 5: Sungrow: QueueRequest called from DoRequest with i13022, qlen 1 from master Sungrow through io device Sungrow
2020.12.29 17:22:44 5: Sungrow: read buffer: 00d80000000701040400000000
2020.12.29 17:22:44 5: Sungrow: ParseFrameStart called from ReadFn
2020.12.29 17:22:44 4: Sungrow: ParseFrameStart (TCP) extracted id 1, fCode 4, tid 216, dlen 7 and data 0400000000
2020.12.29 17:22:44 5: Sungrow: HandleResponse called from ReadFn
2020.12.29 17:22:44 5: Sungrow: ParseResponse called from HandleResponse
2020.12.29 17:22:44 5: Sungrow: HandleResponse now acts on fcode 4, masterhash Sungrow
2020.12.29 17:22:44 5: Sungrow: HandleResponse calls parseObj with master device Sungrow for parsing data
2020.12.29 17:22:44 5: Sungrow: ParseObj called with data hex 00000000, type i, adr 5016, valuesLen 2, op read
2020.12.29 17:22:45 5: Sungrow: ParseObj unpacked 00000000 with n to 0
2020.12.29 17:22:45 4: Sungrow: ParseObj assigns value 0 to DC_Power
2020.12.29 17:22:45 5: Sungrow: HandleResponse got 1 readings from ParseObj for Sungrow
2020.12.29 17:22:45 5: Sungrow: ResetExpect for HandleResponse from response to idle
2020.12.29 17:22:45 4: Sungrow: HandleResponse done, current frame / read buffer: 00d80000000701040400000000, id 1, fCode 4, tid 216,
request: id 1, read fc 4 i5016, len 2, tid 216, master device Sungrow, reading DC_Power (getUpdate), queued 0.03 secs ago, sent 0.03 secs ago,
response: id 1, fc 4 i5016, len 2, value 00000000
2020.12.29 17:22:45 5: Sungrow: DropFrame - drop 00d80000000701040400000000
2020.12.29 17:22:45 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 2, request: request: id 1, read fc 4 i6249, len 30, tid 182, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.03 secs ago
2020.12.29 17:22:45 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:22:45 5: Sungrow: checkDelays commDelay, last communication with same device was 0.012 secs ago, required delay is 0.1
2020.12.29 17:22:45 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.012 secs ago, required delay is 0
2020.12.29 17:22:45 5: Sungrow: checkDelays sendDelay, last send to same device was 0.028 secs ago, required delay is 0.1
2020.12.29 17:22:45 4: Sungrow: checkDelays found commDelay not over, set timer to try again in 0.088
2020.12.29 17:22:45 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 2, request: request: id 1, read fc 4 i6249, len 30, tid 182, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.12 secs ago
2020.12.29 17:22:45 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.104 secs ago, required delay is 0
2020.12.29 17:22:45 5: Sungrow: checkDelays commDelay, last communication with same device was 0.104 secs ago, required delay is 0.1
2020.12.29 17:22:45 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:22:45 5: Sungrow: checkDelays sendDelay, last send to same device was 0.120 secs ago, required delay is 0.1
2020.12.29 17:22:45 4: Sungrow: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 2, sending 00b60000000601041869001e via 192.168.2.113:502, read buffer empty,
request: id 1, read fc 4 i6249, len 30, tid 182, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.12 secs ago
2020.12.29 17:22:45 5: Sungrow: Send called from ProcessRequestQueue
2020.12.29 17:22:45 5: SW: 00b60000000601041869001e
2020.12.29 17:22:45 5: Sungrow: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2020.12.29 17:22:45 5: Sungrow: read buffer: 00b60000003f01043c000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.29 17:22:45 5: Sungrow: ParseFrameStart called from ReadFn
2020.12.29 17:22:45 4: Sungrow: ParseFrameStart (TCP) extracted id 1, fCode 4, tid 182, dlen 63 and data 3c000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.29 17:22:45 5: Sungrow: HandleResponse called from ReadFn
2020.12.29 17:22:45 5: Sungrow: ParseResponse called from HandleResponse
2020.12.29 17:22:45 5: Sungrow: HandleResponse now acts on fcode 4, masterhash Sungrow
2020.12.29 17:22:45 5: Sungrow: HandleResponse calls parseObj with master device Sungrow for parsing data
2020.12.29 17:22:45 5: Sungrow: ParseObj called with data hex 000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000, type i, adr 6249, valuesLen 30, op read
2020.12.29 17:22:45 5: Sungrow: ParseObj unpacked 000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000 with H60 to 000000000000000000000000000000000000000002430000000000000000
2020.12.29 17:22:45 4: Sungrow: ParseObj assigns value 000000000000000000000000000000000000000002430000000000000000 to Yearly_Energy
2020.12.29 17:22:45 5: Sungrow: HandleResponse got 1 readings from ParseObj for Sungrow
2020.12.29 17:22:45 5: Sungrow: ResetExpect for HandleResponse from response to idle
2020.12.29 17:22:45 4: Sungrow: HandleResponse done, current frame / read buffer: 00b60000003f01043c000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000, id 1, fCode 4, tid 182,
request: id 1, read fc 4 i6249, len 30, tid 182, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.15 secs ago, sent 0.03 secs ago,
response: id 1, fc 4 i6249, len 30, value 000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.29 17:22:45 5: Sungrow: DropFrame - drop 00b60000003f01043c000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.29 17:22:45 5: Sungrow: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2020.12.29 17:22:45 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 19, master device Sungrow, reading Battery_Level (getUpdate), queued 0.15 secs ago
2020.12.29 17:22:45 5: Sungrow: checkDelays commDelay, last communication with same device was 0.022 secs ago, required delay is 0.1
2020.12.29 17:22:45 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:22:45 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.022 secs ago, required delay is 0
2020.12.29 17:22:45 5: Sungrow: checkDelays sendDelay, last send to same device was 0.028 secs ago, required delay is 0.1
2020.12.29 17:22:45 4: Sungrow: checkDelays found commDelay not over, set timer to try again in 0.078
2020.12.29 17:22:45 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 19, master device Sungrow, reading Battery_Level (getUpdate), queued 0.23 secs ago
2020.12.29 17:22:45 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.105 secs ago, required delay is 0
2020.12.29 17:22:45 5: Sungrow: checkDelays commDelay, last communication with same device was 0.105 secs ago, required delay is 0.1
2020.12.29 17:22:45 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:22:45 5: Sungrow: checkDelays sendDelay, last send to same device was 0.111 secs ago, required delay is 0.1
2020.12.29 17:22:45 4: Sungrow: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 1, sending 001300000006010432de0001 via 192.168.2.113:502, read buffer empty,
request: id 1, read fc 4 i13022, len 1, tid 19, master device Sungrow, reading Battery_Level (getUpdate), queued 0.24 secs ago
2020.12.29 17:22:45 5: Sungrow: Send called from ProcessRequestQueue
2020.12.29 17:22:45 5: SW: 001300000006010432de0001
2020.12.29 17:22:45 5: Sungrow: read buffer: 0013000000050104020130
2020.12.29 17:22:45 5: Sungrow: ParseFrameStart called from ReadFn
2020.12.29 17:22:45 4: Sungrow: ParseFrameStart (TCP) extracted id 1, fCode 4, tid 19, dlen 5 and data 020130
2020.12.29 17:22:45 5: Sungrow: HandleResponse called from ReadFn
2020.12.29 17:22:45 5: Sungrow: ParseResponse called from HandleResponse
2020.12.29 17:22:45 5: Sungrow: HandleResponse now acts on fcode 4, masterhash Sungrow
2020.12.29 17:22:45 5: Sungrow: HandleResponse calls parseObj with master device Sungrow for parsing data
2020.12.29 17:22:45 5: Sungrow: ParseObj called with data hex 0130, type i, adr 13022, valuesLen 1, op read
2020.12.29 17:22:45 5: Sungrow: ParseObj unpacked 0130 with n to 304
2020.12.29 17:22:45 5: Sungrow: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/10 to 30.4
2020.12.29 17:22:45 4: Sungrow: ParseObj assigns value 30.4 to Battery_Level
2020.12.29 17:22:45 5: Sungrow: HandleResponse got 1 readings from ParseObj for Sungrow
2020.12.29 17:22:45 5: Sungrow: ResetExpect for HandleResponse from response to idle
2020.12.29 17:22:45 4: Sungrow: HandleResponse done, current frame / read buffer: 0013000000050104020130, id 1, fCode 4, tid 19,
request: id 1, read fc 4 i13022, len 1, tid 19, master device Sungrow, reading Battery_Level (getUpdate), queued 0.26 secs ago, sent 0.03 secs ago,
response: id 1, fc 4 i13022, len 1, value 0130
2020.12.29 17:22:45 5: Sungrow: DropFrame - drop 0013000000050104020130
2020.12.29 17:23:00 4: 192.168.2.113:502 disconnected, waiting to reappear (Sungrow)
2020.12.29 17:23:01 5: Sungrow: open called from ReadyFn, busyOpenDev 0
2020.12.29 17:23:01 4: Sungrow: open trying to open connection to 192.168.2.113:502
2020.12.29 17:23:01 5: HttpUtils url=http://192.168.2.113:502/
2020.12.29 17:23:01 4: IP: 192.168.2.113 -> 192.168.2.113
2020.12.29 17:23:01 4: 192.168.2.113:502 reappeared (Sungrow)
2020.12.29 17:23:01 4: Sungrow: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 13.9 sec at 2020-12-29 17:23:14, interval 30
2020.12.29 17:23:14 5: Sungrow: GetUpdate called from Fhem internal timer
2020.12.29 17:23:14 4: Sungrow: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 30.0 sec at 2020-12-29 17:23:44, interval 30
2020.12.29 17:23:14 5: Sungrow: GetUpdate objects from attributes: i5016 i6249 i13022
2020.12.29 17:23:14 5: Sungrow: GetUpdate full object list: i13022 i5016 i6249
2020.12.29 17:23:14 5: Sungrow: GetUpdate check i13022 => Battery_Level, poll = 1, last = 1609258965.23821
2020.12.29 17:23:14 4: Sungrow: GetUpdate will request Battery_Level
2020.12.29 17:23:14 5: Sungrow: GetUpdate check i5016 => DC_Power, poll = 1, last = 1609258965.00175
2020.12.29 17:23:14 4: Sungrow: GetUpdate will request DC_Power
2020.12.29 17:23:14 5: Sungrow: GetUpdate check i6249 => Yearly_Energy, poll = 1, last = 1609258965.12355
2020.12.29 17:23:14 4: Sungrow: GetUpdate will skip Yearly_Energy, delay not over
2020.12.29 17:23:14 5: Sungrow: GetUpdate tries to combine read commands
2020.12.29 17:23:14 5: Sungrow: GetUpdate cant combine request for DC_Power / i5016 with Yearly_Energy / i6249, span 1263 > max 1
2020.12.29 17:23:14 5: Sungrow: GetUpdate cant combine request for Yearly_Energy / i6249 with Battery_Level / i13022, span 6774 > max 1
2020.12.29 17:23:14 4: Sungrow: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i5016, len 2, tid 194, master device Sungrow, reading DC_Power (getUpdate)
2020.12.29 17:23:14 5: Sungrow: QueueRequest called from DoRequest with i5016, qlen 0 from master Sungrow through io device Sungrow
2020.12.29 17:23:14 5: Sungrow: ProcessRequestQueue called from QueueRequest as direct:Sungrow, qlen 1, request: request: id 1, read fc 4 i5016, len 2, tid 194, master device Sungrow, reading DC_Power (getUpdate), queued 0.00 secs ago
2020.12.29 17:23:14 5: Sungrow: checkDelays sendDelay, last send to same device was 29.741 secs ago, required delay is 0.1
2020.12.29 17:23:14 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:23:14 5: Sungrow: checkDelays commDelay, last communication with same device was 29.737 secs ago, required delay is 0.1
2020.12.29 17:23:14 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 29.737 secs ago, required delay is 0
2020.12.29 17:23:14 4: Sungrow: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 1, sending 00c200000006010413980002 via 192.168.2.113:502, read buffer empty,
request: id 1, read fc 4 i5016, len 2, tid 194, master device Sungrow, reading DC_Power (getUpdate), queued 0.00 secs ago
2020.12.29 17:23:14 5: Sungrow: Send called from ProcessRequestQueue
2020.12.29 17:23:14 5: SW: 00c200000006010413980002
2020.12.29 17:23:14 4: Sungrow: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i6249, len 30, tid 40, master device Sungrow, reading Yearly_Energy (getUpdate)
2020.12.29 17:23:14 5: Sungrow: QueueRequest called from DoRequest with i6249, qlen 0 from master Sungrow through io device Sungrow
2020.12.29 17:23:14 5: Sungrow: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2020.12.29 17:23:14 4: Sungrow: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i13022, len 1, tid 200, master device Sungrow, reading Battery_Level (getUpdate)
2020.12.29 17:23:14 5: Sungrow: QueueRequest called from DoRequest with i13022, qlen 1 from master Sungrow through io device Sungrow
2020.12.29 17:23:14 5: Sungrow: read buffer: 00c20000000701040400000000
2020.12.29 17:23:14 5: Sungrow: ParseFrameStart called from ReadFn
2020.12.29 17:23:14 4: Sungrow: ParseFrameStart (TCP) extracted id 1, fCode 4, tid 194, dlen 7 and data 0400000000
2020.12.29 17:23:14 5: Sungrow: HandleResponse called from ReadFn
2020.12.29 17:23:14 5: Sungrow: ParseResponse called from HandleResponse
2020.12.29 17:23:14 5: Sungrow: HandleResponse now acts on fcode 4, masterhash Sungrow
2020.12.29 17:23:14 5: Sungrow: HandleResponse calls parseObj with master device Sungrow for parsing data
2020.12.29 17:23:14 5: Sungrow: ParseObj called with data hex 00000000, type i, adr 5016, valuesLen 2, op read
2020.12.29 17:23:14 5: Sungrow: ParseObj unpacked 00000000 with n to 0
2020.12.29 17:23:14 4: Sungrow: ParseObj assigns value 0 to DC_Power
2020.12.29 17:23:15 5: Sungrow: HandleResponse got 1 readings from ParseObj for Sungrow
2020.12.29 17:23:15 5: Sungrow: ResetExpect for HandleResponse from response to idle
2020.12.29 17:23:15 4: Sungrow: HandleResponse done, current frame / read buffer: 00c20000000701040400000000, id 1, fCode 4, tid 194,
request: id 1, read fc 4 i5016, len 2, tid 194, master device Sungrow, reading DC_Power (getUpdate), queued 0.04 secs ago, sent 0.04 secs ago,
response: id 1, fc 4 i5016, len 2, value 00000000
2020.12.29 17:23:15 5: Sungrow: DropFrame - drop 00c20000000701040400000000
2020.12.29 17:23:15 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 2, request: request: id 1, read fc 4 i6249, len 30, tid 40, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.02 secs ago
2020.12.29 17:23:15 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:23:15 5: Sungrow: checkDelays commDelay, last communication with same device was 0.011 secs ago, required delay is 0.1
2020.12.29 17:23:15 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.011 secs ago, required delay is 0
2020.12.29 17:23:15 5: Sungrow: checkDelays sendDelay, last send to same device was 0.026 secs ago, required delay is 0.1
2020.12.29 17:23:15 4: Sungrow: checkDelays found commDelay not over, set timer to try again in 0.089
2020.12.29 17:23:15 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 2, request: request: id 1, read fc 4 i6249, len 30, tid 40, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.12 secs ago
2020.12.29 17:23:15 5: Sungrow: checkDelays sendDelay, last send to same device was 0.119 secs ago, required delay is 0.1
2020.12.29 17:23:15 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.104 secs ago, required delay is 0
2020.12.29 17:23:15 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:23:15 5: Sungrow: checkDelays commDelay, last communication with same device was 0.104 secs ago, required delay is 0.1
2020.12.29 17:23:15 4: Sungrow: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 2, sending 00280000000601041869001e via 192.168.2.113:502, read buffer empty,
request: id 1, read fc 4 i6249, len 30, tid 40, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.12 secs ago
2020.12.29 17:23:15 5: Sungrow: Send called from ProcessRequestQueue
2020.12.29 17:23:15 5: SW: 00280000000601041869001e
2020.12.29 17:23:15 5: Sungrow: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2020.12.29 17:23:15 5: Sungrow: read buffer: 00280000003f01043c000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.29 17:23:15 5: Sungrow: ParseFrameStart called from ReadFn
2020.12.29 17:23:15 4: Sungrow: ParseFrameStart (TCP) extracted id 1, fCode 4, tid 40, dlen 63 and data 3c000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.29 17:23:15 5: Sungrow: HandleResponse called from ReadFn
2020.12.29 17:23:15 5: Sungrow: ParseResponse called from HandleResponse
2020.12.29 17:23:15 5: Sungrow: HandleResponse now acts on fcode 4, masterhash Sungrow
2020.12.29 17:23:15 5: Sungrow: HandleResponse calls parseObj with master device Sungrow for parsing data
2020.12.29 17:23:15 5: Sungrow: ParseObj called with data hex 000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000, type i, adr 6249, valuesLen 30, op read
2020.12.29 17:23:15 5: Sungrow: ParseObj unpacked 000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000 with H60 to 000000000000000000000000000000000000000002430000000000000000
2020.12.29 17:23:15 4: Sungrow: ParseObj assigns value 000000000000000000000000000000000000000002430000000000000000 to Yearly_Energy
2020.12.29 17:23:15 5: Sungrow: HandleResponse got 1 readings from ParseObj for Sungrow
2020.12.29 17:23:15 5: Sungrow: ResetExpect for HandleResponse from response to idle
2020.12.29 17:23:15 4: Sungrow: HandleResponse done, current frame / read buffer: 00280000003f01043c000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000, id 1, fCode 4, tid 40,
request: id 1, read fc 4 i6249, len 30, tid 40, master device Sungrow, reading Yearly_Energy (getUpdate), queued 0.14 secs ago, sent 0.02 secs ago,
response: id 1, fc 4 i6249, len 30, value 000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.29 17:23:15 5: Sungrow: DropFrame - drop 00280000003f01043c000000000000000000000000000000000000000002430000000000000000000000000000000000000000000000000000000000000000000000000000
2020.12.29 17:23:15 5: Sungrow: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2020.12.29 17:23:15 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 200, master device Sungrow, reading Battery_Level (getUpdate), queued 0.14 secs ago
2020.12.29 17:23:15 5: Sungrow: checkDelays sendDelay, last send to same device was 0.019 secs ago, required delay is 0.1
2020.12.29 17:23:15 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:23:15 5: Sungrow: checkDelays commDelay, last communication with same device was 0.014 secs ago, required delay is 0.1
2020.12.29 17:23:15 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.014 secs ago, required delay is 0
2020.12.29 17:23:15 4: Sungrow: checkDelays found commDelay not over, set timer to try again in 0.086
2020.12.29 17:23:15 5: Sungrow: ProcessRequestQueue called from Fhem internal timer as queue:Sungrow, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 200, master device Sungrow, reading Battery_Level (getUpdate), queued 0.23 secs ago
2020.12.29 17:23:15 5: Sungrow: checkDelays busDelayRead, last activity on bus  was 0.105 secs ago, required delay is 0
2020.12.29 17:23:15 5: Sungrow: checkDelays commDelay, last communication with same device was 0.105 secs ago, required delay is 0.1
2020.12.29 17:23:15 5: Sungrow: checkDelays clientSwitchDelay is not relevant
2020.12.29 17:23:15 5: Sungrow: checkDelays sendDelay, last send to same device was 0.110 secs ago, required delay is 0.1
2020.12.29 17:23:15 4: Sungrow: ProcessRequestQueue (V4.3.8 - 25.12.2020) qlen 1, sending 00c800000006010432de0001 via 192.168.2.113:502, read buffer empty,
request: id 1, read fc 4 i13022, len 1, tid 200, master device Sungrow, reading Battery_Level (getUpdate), queued 0.23 secs ago
2020.12.29 17:23:15 5: Sungrow: Send called from ProcessRequestQueue
2020.12.29 17:23:15 5: SW: 00c800000006010432de0001
2020.12.29 17:23:15 5: Sungrow: read buffer: 00c8000000050104020130
2020.12.29 17:23:15 5: Sungrow: ParseFrameStart called from ReadFn
2020.12.29 17:23:15 4: Sungrow: ParseFrameStart (TCP) extracted id 1, fCode 4, tid 200, dlen 5 and data 020130
2020.12.29 17:23:15 5: Sungrow: HandleResponse called from ReadFn
2020.12.29 17:23:15 5: Sungrow: ParseResponse called from HandleResponse
2020.12.29 17:23:15 5: Sungrow: HandleResponse now acts on fcode 4, masterhash Sungrow
2020.12.29 17:23:15 5: Sungrow: HandleResponse calls parseObj with master device Sungrow for parsing data
2020.12.29 17:23:15 5: Sungrow: ParseObj called with data hex 0130, type i, adr 13022, valuesLen 1, op read
2020.12.29 17:23:15 5: Sungrow: ParseObj unpacked 0130 with n to 304
2020.12.29 17:23:15 5: Sungrow: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/10 to 30.4
2020.12.29 17:23:15 4: Sungrow: ParseObj assigns value 30.4 to Battery_Level
2020.12.29 17:23:15 5: Sungrow: HandleResponse got 1 readings from ParseObj for Sungrow
2020.12.29 17:23:15 5: Sungrow: ResetExpect for HandleResponse from response to idle
2020.12.29 17:23:15 4: Sungrow: HandleResponse done, current frame / read buffer: 00c8000000050104020130, id 1, fCode 4, tid 200,
request: id 1, read fc 4 i13022, len 1, tid 200, master device Sungrow, reading Battery_Level (getUpdate), queued 0.26 secs ago, sent 0.03 secs ago,
response: id 1, fc 4 i13022, len 1, value 0130
2020.12.29 17:23:15 5: Sungrow: DropFrame - drop 00c8000000050104020130
2020.12.29 17:23:15 4: 192.168.2.113:502 disconnected, waiting to reappear (Sungrow)
2020.12.29 17:23:15 5: Sungrow: open called from ReadyFn, busyOpenDev 0
2020.12.29 17:23:15 4: Sungrow: open trying to open connection to 192.168.2.113:502
2020.12.29 17:23:15 5: HttpUtils url=http://192.168.2.113:502/
2020.12.29 17:23:15 4: IP: 192.168.2.113 -> 192.168.2.113
2020.12.29 17:23:15 4: 192.168.2.113:502 reappeared (Sungrow)
2020.12.29 17:23:15 4: Sungrow: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 29.4 sec at 2020-12-29 17:23:44, interval 30
2020.12.29 17:23:31 4: 192.168.2.113:502 disconnected, waiting to reappear (Sungrow)
2020.12.29 17:23:31 5: Sungrow: open called from ReadyFn, busyOpenDev 0
2020.12.29 17:23:31 4: Sungrow: open trying to open connection to 192.168.2.113:502
2020.12.29 17:23:31 5: HttpUtils url=http://192.168.2.113:502/
2020.12.29 17:23:31 4: IP: 192.168.2.113 -> 192.168.2.113
2020.12.29 17:23:31 4: 192.168.2.113:502 reappeared (Sungrow)
2020.12.29 17:23:31 4: Sungrow: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 13.9 sec at 2020-12-29 17:23:44, interval 30


Gruß
Thomas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Dezember 2020, 20:44:51
Hallo,

den Fehler beim polldelay habe ich gefunden und hoffentlich behoben. Der ist wohl bei der Überarbeitung in den letzten Monaten reingekommen.
Hier die neueste Version mit weiteren Bugfixes und Überarbeitungen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 29 Dezember 2020, 23:18:56
Hallo Stefan,

ein Hinweis kommt noch:


PERL WARNING: Useless use of string in void context at ./FHEM/98_Modbus.pm line 2102, <$fh> line 1646.


2101 (Zeilenumbruch, fehlt Kommentarzeichen)
Zitat
        #Log3 $name, 4, "$name: SkipGarbageCheck looking for start byte " . unpack ('H*', $startByte).
            " protocol is $hash->{PROTOCOL}, mode is $hash->{MODE}";

Die Module werden aber geladen. Fehler bis jetzt noch keine.

Grüße Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Funnel am 30 Dezember 2020, 10:05:52
Hallo Stefan,

ein erstes Feedback von mir:
Gruß
Thomas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Januar 2021, 17:55:38
Hallo,

Ich habe inzwischen noch einige automatische Tests für das Modul geschrieben und dabei noch Fehler beim Handling von Modbus ASCII gefunden und hoffentlich behoben.
Hier die aktuelle Version.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Zwiebel am 03 Januar 2021, 11:03:44
Hallo Stefan,

danke für dein tolles Modul!
Ich habe 6 Modbus Strom Zähler (1xSDM630 und 5xSDM120) die seit etwa 4 Jahren so vor sich hin zählen. Es gab immer mal wieder timeouts und checksum Probleme die ich mit verbose 2 ignoriert habe weil immer ausreichende Werte gekommen sind.
Dann habe ich zwei weitere SDM120 Zähler installiert. Einer von den beiden (Trockner id 13) liefert aber kein "Power__W", es kommt aber "energyTotal".
Daraufhin hab ich den Modbus neu verkabelt und geschirmte Leitungen verwendet. Die Modbus Kabellänge ist etwa 6-7 Meter.

Leider hat das keine Veränderung gebracht, Trockner liefert automatisch kein "Power__W". Ein "get Trockner Power__W" liefert nach paar sekunden einen Wert.

So habe ich den Trockner definiert:

define Trockner ModbusSDM220M 13 60
attr Trockner IODev modbus
attr Trockner dev-timing-commDelay 3
attr Trockner deleteattr dev-timing-timeout 6
attr Trockner poll-Energy_total__kwh 1


Ich habe seit gestern um 18 Uhr dein Modul upgedatet und FHEM neu gestartet.
In dem screenshot sieht man das die Requests weniger geworden sind. Ich habe aber nur das Modul ausgetauscht.

Ich kann sonnst keine Veränderung sehen, es kommen von allen anderen Zählern Werte bis auf "Power__W" vom Trockner.

fhem log (filter "modbus") und das pm sind im Anhang.

viele Dank und Grüße,
Zwiebel.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 Januar 2021, 22:56:50
Hallo Zwiebel,

vielen Dank fürs Testen.
Dass die Anzahl der Requests zurückgegangen ist, liegt vermutlich an einem Bug in einer früheren Version, in der polldelay ignoriert wurde. Um das genau sagen zu können, müsste ich aber auch die Logs der logischen devices sehen und mit älteren Logs vergleichen. Wenn alle Werte wie erwartet kommen, ist es aber vermutlich ein behobener Bug.

Das mit dem Power-Reading des Trockners ist seltsam. Um das zu klären bräuchte ich aber auch ein Log, in dem ich auch das logische Device sehe und nicht nur das Modbus-Io-Device. Am besten während eines Updates und eines expliziten get.

Was mir sonst noch auffällt ist die Häufigkeit, mit der die Send-Queue abgearbeitet wird. Kann es sein, dass Du queueDelay auf 0 gesetzt hast?

Gruß
     Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Zwiebel am 04 Januar 2021, 13:59:38
Hallo Stefan,

du hast recht ich hatte queueDelay auf 0 gesetzt, in der Hoffnung das damit die Timeouts weniger werden. Das war aber nicht der Fall. Ich habe es jetzt wieder auf 1 abgeändert.

Im Anhang das log mit verbose 5. Um 13:53:58 hab ich einen manuellen get von Power__W gemacht. Das hat sehr schnell funktioniert. Wert war 0 Watt, was richtig ist.

vielen dank!
Zwiebel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 Januar 2021, 15:56:50
Hallo Zwiebel,

ich vermute dass Deine Probleme von einem zu hohen Combine-Wert für die Input-Register kommen.
Überschrieb doch mal die 40 aus dem sdm220-Modul per

attr Trockner dev-i-combine 20


und erzeuge dann wieder ein Log wie Du es gerade gepostet hast.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Zwiebel am 04 Januar 2021, 17:35:44
Hallo Stefan,

du hattes recht es war der "combine "Wert! Nach dem das Attribute funktioniert hat habe ich es im Modul übernommen.
Jetzt habe ich keine timeouts mehr, und ich kann alles in verbose 3 laufen lassen ohne Probleme.

Im Anhang die verbose 5 logs und das abgeänderte Modul.

vielen dank für deine Hilfe!

Gruß
Zwiebel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Januar 2021, 14:14:00
Hallo,

ich habe gerade die neue Version eingecheckt.
Meldet Euch bitte falls es doch noch Probleme damit gibt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Funnel am 07 Januar 2021, 14:33:17
Ein "update" führt bei mir nicht zur Aktualisierung deiner Module
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 07 Januar 2021, 14:40:59
kann ich bestätigen in der controls_fhem.txt  steht noch 2019  drin ;-)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Januar 2021, 17:32:36
Das dauert immer bis zum nächsten Tag bis die neuen Sachen aus dem SVN per update verteilt werden. :-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 09 Januar 2021, 19:45:52
Bezugnehmend auf https://forum.fhem.de/index.php/topic,75638.msg1110251.html#msg1110251 (https://forum.fhem.de/index.php/topic,75638.msg1110251.html#msg1110251) habe ich die letzten Tage versucht, meine Solaranlage in fhem zu implementieren.

Selten in den letzten Dekaden mit einer selbst gestellten Aufgabe so dermaßen gescheitert ;)
Das ist dann doch hochgradig komplex.

Mein Problem ist noch immer, den Ansatz zu finden. Ich weiß nichtmal wonach ich suchen kann. "modbus 16bit HEX" hat mich nicht wirklich weitergebracht.

Auf einem Testsystem steckt der USB-RS485 Adapter der mit der Solaranlage verbunden ist.
Definiert sind zwei Devices:

Internals:
   DEF        /dev/ttyUSB0@9600,8,E,1
   DeviceName /dev/ttyUSB0@9600,8,E,1
   EXPECT     idle
   FD         4
   FUUID      5ff9c3ef-f33f-c138-67ef-7277e323cb47cd25
   IODev      ModbusLine
   LASTOPEN   1610212035.22143
   MODE       master
   NAME       ModbusLine
   NOTIFYDEV  global
   NR         15
   NTFY_ORDER 50-ModbusLine
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   READ:
     BUFFER     
   READINGS:
     2021-01-09 18:07:15   state           opened
   REMEMBER:
     lrecv      1610215927.04427
   defptr:
     Studer485  10
Attributes:


und das ModbusAttr
Internals:
   DEF        1 10
   FUUID      5ff9d4f6-f33f-c138-b74c-0d17d513dd4c86d7
   IODev      ModbusLine
   Interval   10
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-Studer485
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   READINGS:
     2021-01-09 18:53:25   state           opened
   lastRead:
Attributes:


LEDS am USB Stick blinken unregelmäßig und sekündlich bekomme ich Fehlermeldungen im Log:

2021.01.09 19:13:45 3: ModbusLine: readfn got data while EXPECT was set to idle: 00000000
2021.01.09 19:13:45 3: ModbusLine: readfn got data while EXPECT was set to idle: 00ff0000
2021.01.09 19:13:45 3: ModbusLine: readfn got data while EXPECT was set to idle: e0000000
2021.01.09 19:13:45 3: ModbusLine: readfn got data while EXPECT was set to idle: 0000ff00


das finde ich schonmal schön, weil irgendjemand redet ja mit irgendwem. Auch wenn falsch und ich es nicht verstehe.

Dass ich dem Device Studer485 sagen muß, was es tun soll vermute ich. Drehe mich hier mit Versuchen seit 6 Stunden im Kreis.

Wie muß ich eine Abfrage eines HEX-Wertes definieren? Was ich habe ist ein Auszug der Doku der Solaranlage die wohl sehr verständlich beschreibt, wie man Werte ausliest .... nur leider bekomme ich die Transferleistung zum modbus Modul nicht hin. Auch finde ich vermeintlich kein Beispiel in der commandref oder im Forum was mir verständlich aufzeigt, wie man Hex sendet.

Könnte mal jemand auf die zwei angehängten Bilder schauen und mir einen Tip geben, wie ich eine HEX-Abfrage für einen Wert aufzubauen habe?

Auch verstehe ich nicht, welche ID die Solaranlage am Bus hat.

Der Ordnung halber auch noch die kompletten pdf-Files aus denen die Bilder extrahiert sind.

Danke für eure Hilfe.
H.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 09 Januar 2021, 21:04:06
@holle75

schau mal hier (https://github.com/studer-innotec/xcom485i) gibt es ein phyton-script zum auslesen über rs485. Vielelicht kommt da ja schon was.

und hier etwas Doku --> Open STUDER  (https://www.studer-innotec.com/de/downloads/)

Du fragst aber per Modbus-Modul noch kein Register ab ?!
Das ist jetzt nur ein Beispiel das nicht stimmen muss ;-(


dev-h-combine 10
dev-h-defPoll 1
dev-h-defShowGet 1
enableControlSet 1
attr <DEVICE-NAME> obj-h30001-len 4
attr <DEVICE-NAME> obj-h30001-Test1
attr <DEVICE-NAME> obj-h30001-unpack (a16)


pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 09 Januar 2021, 21:57:35
@holle75

hattes du die Lösung von @satprofie schon mal bei dir am laufen ? Da werden doch schon Werte ausgelesen.
Diese könnte man doch versuchen über MQTT nach FHEM zu senden. So könnte man das pyhton-Modul weiter nehmen. Oder man versucht es über ModBus.

Versuche mal die 30001 über ModBus RTU auszulesen.

pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 Januar 2021, 23:23:56
Hallo holle75,

mit den Unterlagen, die Du angehängt hast, bekommt man das hin.
Dazu gehört leider ein wenig Geduld und Ausprobieren, da die Angaben nicht ganz eindeutig sind. Ein Phyton-Skript oder andere Sachen brauchst Du aber sicher nicht.

Aus Deiner Doku lese ich heraus, dass z.B. die Batterie-Temperatur aus dem Modbus-Input-Register 2 gelesen werden kann. Der Wert wird vermutlich an anderer Stelle als Wert Nummer 3001 bezeichnet, aber in der Doku steht als Beispiel explizit Register 2, Länge 2 und Function Code 4 (das ist der Code zum Lesen con Input-Registern. Wenn es Holding-Register wären, dann wäre das der Function-Code 3)
Also Must Du in ModbusAttr ein Objekt dafür definieren.

attr Studer485 obj-i2-reading BatTemp
attr Studer485 obj-i2-len 2


Fraglich ist dann noch das Datenformat. In der Doku steht zwar "Float", aber da gibt es verschiedene Varianten. Im Modbus-Modul wird das über einen unpack-Code angegeben. Ich würde es mit f> oder auch mal f< ausprobieren:


attr Studer485 obj-i2-unpack f>


Damit man dieses Objekt auch per get Abfragen kann, muss es dann noch dafür freigeschaltet werden:


attr Studer485 obj-i2-showGet 1


oder alternativ einmal als Default für alle Input-Register:


attr Studer485 dev-defShowGet 1


Ebenso kann man einstellen, ob das Objekt automatisch alle x Sekunden abgefragt werden soll. Das Intervall hast Du ja beim Define des Geräts auf 10 Sekunden gesetzt:


attr Studer485 obj-i2-poll 1


Oder auch hier einmal für alle Input-Register:


attr Studer485 dev-defPoll 1


Ein combine-Attribut würde erst mal nicht setzen. Das ist eine potentielle Optimierung für später, wenn es mal funktioniert. Es kann aber auch Probleme machen und in Deiner Doku steht sogar, dass die Länge nicht größer als zwei sein sollte...

Wenn das soweit eingegeben ist, dann solltest Du dringend verbose auf 5 setzen, damit im Log möglichst viele Details landen:


attr Studer485 verbose 5
attr ModbusLine verbose 5


Dann schau mal was im Log landet und poste es :-)

Interessant wäre aber auch noch die physische Verkabelung.
Wer oder was hängt denn alles am Kabel?

Die bisherigen Meldungen in Deinem Log weisen darauf hin, dass entweder ein Verkabelungsproblem vorliegt und Unsinn empfangen wird (z.B. falsch angeschlossen, falsche Terminierung o.ä.) oder dass da doch schon ein anderer Master am Bus hängt. Es darf aber nur einen Master am Bus geben.

Zudem hat Dein Gerät sicher eine Möglichkeit die eigene Id zu konfigurieren. Ggf. Per DIP-Switches.
Was ist denn da eingestellt?

Gruß
     Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 12:17:38
Zitat von: pejonp am 09 Januar 2021, 21:57:35
@holle75

hattes du die Lösung von @satprofie schon mal bei dir am laufen ? Da werden doch schon Werte ausgelesen.
Diese könnte man doch versuchen über MQTT nach FHEM zu senden. So könnte man das pyhton-Modul weiter nehmen. Oder man versucht es über ModBus.

Versuche mal die 30001 über ModBus RTU auszulesen.

pejonp

Hallo pejonp, danke für deine Hilfe. Satprofis python-script (resp. die Studer python Anleitung) hatte ich damals nicht ausprobiert, da ich es als Workaround im Zusammenspiel mit fhem sah. Ich wollte ohne externen Script mit fhem kommunizieren. Ich hatte mit Studer gesprochen und auf das Xcom485i gewartet. Satprofis Setup, glaube ich, sind zwei Xcom232+Moxa am Canbus der Anlage. Einer kommuniziert mit der Studer-Cloud und einer mit Python Lokal. Hat Satprofi toll umgesetzt.

Bis dato las ich die Werte über Xcom232 plus Moxa mit HTTPMOD über die Cloud aus. Bzw mach das bis jetzt noch immer.
Das funktioniert, aber Cloud nervt, wenn es direkte Lösungen im Heimnetz gibt/geben könnte.

Deswegen der Ansatz mit Modbus. Außerdem finde ich es schade, dass im Inselanlagenbereich primär nur von Victron gesprochen wird. Nicht hier, aber zB im Photovoltaik Forum. Studer ist bißchen teuerer, aber das sind sehr solide Maschinen die in der Schweiz produziert werden. Victron produziert, glaube ich, in China. Da ist nichts gegen zu sagen, aber der Support wird auschließlich über Händler abgewickelt. Welcher Händler hat Lust, 5 Jahre nach Verkauf, Support im Detail über irgendwelche Einstellungen zu geben?

Bei Studer wird mit dir jedes Problem tage- und notfalls monatelang durchgekaut bis zur Lösung. Ein guter Laden.

Wenn ich es schaffe, mit eurer Hilfe, ein AufsatzModul für Stefans Modbus hinzubiegen hätten alle zukünftigen Studer-Nutzer es recht einfach.

Das waren meine zwei Ansätze mich mit Modbus zu beschäftigen.

Zitat von: StefanStrobel am 09 Januar 2021, 23:23:56


Dann schau mal was im Log landet und poste es :-)

Interessant wäre aber auch noch die physische Verkabelung.
Wer oder was hängt denn alles am Kabel?

Die bisherigen Meldungen in Deinem Log weisen darauf hin, dass entweder ein Verkabelungsproblem vorliegt und Unsinn empfangen wird (z.B. falsch angeschlossen, falsche Terminierung o.ä.) oder dass da doch schon ein anderer Master am Bus hängt. Es darf aber nur einen Master am Bus geben.

Zudem hat Dein Gerät sicher eine Möglichkeit die eigene Id zu konfigurieren. Ggf. Per DIP-Switches.
Was ist denn da eingestellt?

Gruß
     Stefan


Hallo Stefan, vielen Dank!

Im Moment noch ein fhem-Testsystem mit eigenem USB Adapter und nur der Xom485i dranhängend.

Später soll die Solaranlage mit auf den Modbus der beiden Stromzähler SDM220 (wo ich dann gespannt bin, ob es Probleme mit der Parity Dfinition im Modbus-Device gibt, weil Studer will "E", ich glaube die SDM´s wollen "N", aber das ist der zweite Schritt.)

aktuelle Lists:
Internals:
   DEF        /dev/ttyUSB0@9600,8,E,1
   DeviceName /dev/ttyUSB0@9600,8,E,1
   EXPECT     idle
   FD         4
   FUUID      5ff9c3ef-f33f-c138-67ef-7277e323cb47cd25
   LASTOPEN   1610218212.57301
   NAME       ModbusLine
   NOTIFYDEV  global
   NR         15
   NTFY_ORDER 50-ModbusLine
   PARTIAL   
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2021-01-09 19:50:12   state           opened
   REMEMBER:
     lid        0
     lname      Studer485
     lrecv      1610275542.74744
     lsend      1610273334.243
   defptr:
Attributes:
   verbose    5

Internals:
   DEF        1 10
   FUUID      5ff9d4f6-f33f-c138-b74c-0d17d513dd4c86d7
   IODev      ModbusLine
   Interval   10
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-Studer485
   PROTOCOL   RTU
   STATE      inactive
   TYPE       ModbusAttr
   FRAME:
   READ:
   READINGS:
     2021-01-10 11:08:58   state           inactive
   REMEMBER:
     lrecv      1610273334.51309
     lsend      1610273334.243
   gotReadings:
   lastRead:
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   obj-i2-len 2
   obj-i2-reading BatTemp
   obj-i2-unpack f>
   verbose    5


und das Log nach paar Sekunden nach Neustart als Anhang.

Readings bekomme ich keine rein.

Die ID Definition habe ich in keiner Doku gefunden. Den Adress-Bereich kannst du über Dip-Schalter einstellen. Bei Adress-Bereich bei 1 startend bekommt der Xcom485i die Adresse 1 und die Geräte im CanBus der Anlage dann weitere Adressen. Ich hoffe, das sind dann die ID´s??! Anbei Auszug aus einem Manual.

Ob die Testverkabelung fehlerfrei ist, kann ich noch nicht beurteilen. Blöderweise ist der USB-Adapter mit D+ und D- benannt, Studer nennt es A und B ... wie ich herausfinden mußte, gibt es keine allgemeingültige Übersetzung, was was entspricht. Soll wohl variieren. Also habe ich es jetzt so verkabelt, wie die LED-Orgeln am USB-Adapter am meisten Sinn ergeben ;)

Auch die am USB-Stick einzustellenden Widerstände sind im Moment laut Internet gedipt. Obs stimmt, weiß ich nicht.

Wenn ich weiß, dass einstellungsseitig in fhem die Wahrscheinlichkeit groß ist, dass Readings kommen sollten, kann ich an den Kabeln spielen.

Eure Gedanken sind sehr willkommen.

Grüße!
H.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 13:57:36
Hoppala, nachdem ich sowohl den/alle Widerstände am USB-Adapter rausgenommen und am Xcom485i den Endwiderstand aktiviert habe..... SPRICHT das Ding mit mir dank Stefans config. Großer Schritt .... und keine Fehlermeldungen im Log (mit verbose standard)

das allerdings nur wenn ich
defmod ModbusLine Modbus /dev/ttyUSB0@9600,8,E,1
mit
,8,E,1
definiere.

Ohne gibts nur Fehlermeldungen. Denke das wird dann schwierig mit den SDM220´s

als Reading bekomme ich

BatTemp           -1.98523347012727e-23            2021-01-10 13:44:02

list

Internals:
   DEF        1 10
   FUUID      5ff9d4f6-f33f-c138-b74c-0d17d513dd4c86d7
   IODev      ModbusLine
   Interval   10
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-Studer485
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   READ:
   READINGS:
     2021-01-10 13:44:52   BatTemp         -1.98523347012727e-23
     2021-01-10 13:37:41   state           opened
   REMEMBER:
     lrecv      1610282692.90027
     lsend      1610282692.8716
   gotReadings:
     BatTemp    -1.98523347012727e-23
   lastRead:
     i2         1610282692.9028
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   obj-i2-len 2
   obj-i2-reading BatTemp
   obj-i2-unpack f>


mit einem "f<" bekomme ich

BatTemp         6.90910207835351e-41

bin ganz aufgeregt :D

wie bekomme ich da einen sinnvollen Wert?

mit verbose 5 im Studer485 gibt es folgende Infos im Log
2021.01.10 14:00:07 4: Studer485: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 14:00:17.085, interval 10
2021.01.10 14:00:07 5: Studer485: GetUpdate objects from attributes: i2
2021.01.10 14:00:07 5: Studer485: GetUpdate full object list: i2
2021.01.10 14:00:07 5: Studer485: GetUpdate check i2 => BatTemp, poll = 1, polldelay = 0.5, last = 1610283597.12929
2021.01.10 14:00:07 4: Studer485: GetUpdate will request BatTemp
2021.01.10 14:00:07 5: Studer485: GetUpdate tries to combine read commands
2021.01.10 14:00:07 4: Studer485: GetUpdate readList = i2
2021.01.10 14:00:07 4: Studer485: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i2, len 2, master device Studer485, reading BatTemp (getUpdate)
2021.01.10 14:00:07 5: Studer485: ParseObj called from HandleResponse with data hex 99c00000d5, type i, adr 2, valuesLen 2, op read
2021.01.10 14:00:07 5: Studer485: ParseObj unpacked 99c00000d5 with f< to 6.90910207835351e-41
2021.01.10 14:00:07 4: Studer485: ParseObj assigns value 6.90910207835351e-41 to BatTemp
2021.01.10 14:00:07 5: Studer485: ParseObj moves to next object, skip 2 to i4
2021.01.10 14:00:07 5: Studer485: ParseObj has no information about handling i4
2021.01.10 14:00:07 5: Studer485: ParseObj created 1 readings
2021.01.10 14:00:17 5: Studer485: GetUpdate called from Fhem internal timer
2021.01.10 14:00:17 4: Studer485: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 14:00:27.087, interval 10
2021.01.10 14:00:17 5: Studer485: GetUpdate objects from attributes: i2
2021.01.10 14:00:17 5: Studer485: GetUpdate full object list: i2
2021.01.10 14:00:17 5: Studer485: GetUpdate check i2 => BatTemp, poll = 1, polldelay = 0.5, last = 1610283607.12887
2021.01.10 14:00:17 4: Studer485: GetUpdate will request BatTemp
2021.01.10 14:00:17 5: Studer485: GetUpdate tries to combine read commands
2021.01.10 14:00:17 4: Studer485: GetUpdate readList = i2
2021.01.10 14:00:17 4: Studer485: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i2, len 2, master device Studer485, reading BatTemp (getUpdate)
2021.01.10 14:00:17 5: Studer485: ParseObj called from HandleResponse with data hex 99c00000d5, type i, adr 2, valuesLen 2, op read
2021.01.10 14:00:17 5: Studer485: ParseObj unpacked 99c00000d5 with f< to 6.90910207835351e-41
2021.01.10 14:00:17 4: Studer485: ParseObj assigns value 6.90910207835351e-41 to BatTemp
2021.01.10 14:00:17 5: Studer485: ParseObj moves to next object, skip 2 to i4
2021.01.10 14:00:17 5: Studer485: ParseObj has no information about handling i4
2021.01.10 14:00:17 5: Studer485: ParseObj created 1 readings


--------------------------------------------------------------------------------------------------------------------------------------------------------

Einer eine Idee, wie ich das mit der Parity ",8,E,1" mit den SDM´s kombiniert bekomme? Eben mal im Hauptsystem mit an die Definition gehängt, also anstatt

defmod Eastron Modbus /dev/ttyUSB1@9600
mit
defmod Eastron Modbus /dev/ttyUSB1@9600,8,E,1

dann kommen von den SDM´s keine Readings mehr. Mmmmmmmh.

Später würde ich schon gerne nur einen USB-Adaper und einen Bus betreiben.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 14:08:47
Ach so im Manual steht folgendes auf Seite 9

At address 0x0000, there is a first register that contains the number of currently pending
messages. It should be read first using Modbus Read Input Registers with the "Quantity of Input
Registers" set to 1. It should be done like that, otherwise the Xcom-485i will send back an
exception.


Nicht das ich versuche den BatTemp-Wert in ein lesbares Format zu bekommen und es ist gar kein Wert?
Oder das eine  hängt mit dem anderen gar nicht zusammen? Sag ja, recht komplexe Angelegenheit ....
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 14:28:15
Ooooh, die

6.90910207835351e-41

ist tatsächlich die BatTemp. Das Hauptsystem ruft ja über die Cloud ab und 6.9 Grad ist die Temperatur. Nur das "e-41" irritiert und gibt einem nicht das Gefühl, dass das so richtig ist.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Januar 2021, 14:43:11
In dem Fall befürchte ich dass 6.90910207835351e-41 nicht der richtige Wert ist.
Aber wenn Du auf einen Request eine prinzipiell gültige Antwort (kein CRC-Fehler) bekommst, ist das ja schon mal ein erster Erfolg!
Dann ist die Verkabelung vermutlich ok.

Von welcher Modbus-Id hast Du das denn abgefragt?
So wie ich die Doku verstehe, bekommst du von der Modbus-Id 0 z.B. die anstehenden Nachrichten, die ein Gerät von sich aus an das Gateway gesendet hat (dazu gehört der von Dir vorhin zitierte Absatz - siehe Kapitel 5 in dem zuletzt von Dir geposteten PDF).
Dazu must Du laut Deiner Doku Input Register 0 immer mit der Länge 1 abfragen und danach Register 1 immer mit der Länge 4.

Die tatsächlichen Werte der Geräte hinter dem Gateway werden über andere Modbus-Ids abgefragt. Das steht in Kapitel 6.
Da muss man dann Register 2 mit Länge 2 abfragen um die Temperatur als 64-Bit-Wert zu bekommen.
Die Id hängt von Deinen Einstellungen ab.
Zitat
The value of user info 3001 is stored in register 2 and 3 and in order to read this user info on
Xtender 1, the request must be addressed to slave n°11 (0x0B) , assuming that Address Offset is
set to 0.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 15:18:17
Zitat von: StefanStrobel am 10 Januar 2021, 14:43:11
Aber wenn Du auf einen Request eine prinzipiell gültige Antwort (kein CRC-Fehler) bekommst, ist das ja schon mal ein erster Erfolg!
Dann ist die Verkabelung vermutlich ok.

YES! denke ich auch. Dank dir

Zitat von: StefanStrobel am 10 Januar 2021, 14:43:11
In dem Fall befürchte ich dass 6.90910207835351e-41 nicht der richtige Wert ist.

Schau mal meine Antwort im Thread eins über deiner. Ich denke (jetzt) schon, dass es der richtige Wert ist. Allerdings noch ein bißchen verholpert ;)

Zitat von: StefanStrobel am 10 Januar 2021, 14:43:11
Von welcher Modbus-Id hast Du das denn abgefragt?

ID 1

Ich verstehe das (jetzt) so, dass je nach gedipten Adressbereich (Adresse->ID) der Xcom485 ID1, bzw. ID33, bzw. ID65 bekommt. Die Studer Geräte an sich dann ID´s entsprechend dem Offset (Seite 6, ich hängs nochmal komplett an)

Zitat von: StefanStrobel am 10 Januar 2021, 14:43:11
So wie ich die Doku verstehe, bekommst du von der Modbus-Id 0 z.B. die anstehenden Nachrichten, die ein Gerät von sich aus an das Gateway gesendet hat (dazu gehört der von Dir vorhin zitierte Absatz - siehe Kapitel 5 in dem zuletzt von Dir geposteten PDF).
Dazu must Du laut Deiner Doku Input Register 0 immer mit der Länge 1 abfragen und danach Register 1 immer mit der Länge 4.

Ich glaube mit dieser Aussage habe ich mich verrannt:

Zitat von: holle75 am 10 Januar 2021, 14:08:47
Ach so im Manual steht folgendes auf Seite 9

At address 0x0000, there is a first register that contains the number of currently pending
messages. It should be read first using Modbus Read Input Registers with the "Quantity of Input
Registers" set to 1. It should be done like that, otherwise the Xcom-485i will send back an
exception.


Nicht das ich versuche den BatTemp-Wert in ein lesbares Format zu bekommen und es ist gar kein Wert?
Oder das eine  hängt mit dem anderen gar nicht zusammen? Sag ja, recht komplexe Angelegenheit ....

(jetzt) denke ich, es geht tatsächlich um MESSAGES im Studer CanBus. Also Hinweise wie "Transferrelais getrennt um 12:33" usw. die du dir als User im Display/RCC anschauen kannst. Seite 9
Vorher nahm ich an, mit Messages seien allgemein "Werte" gemeint.

Wenn ich davon ausgehe, dass die BatTemp-Abfrage von der ID1 den richtigen (noch nicht richtig konfektionierten) Wert enthält, und ich weiter interpretiere, dass alle Werte die lesend und nicht schreibend sind über ID1 abgefragt werden können ..... sind wir schon richtig weit.
Hättest du noch eine Idee, warum der BatTemp hinten noch das e-41 hat?

Und hey, vielleicht lieg ich mit meinen Annahmen komplett falsch.

Ich versuche jetzt mal, einen weiteren Wert nach deinem Raster abzufragen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 15:49:28
.... nach weiterer Lektüre der Doks scheine ich quatsch zu interpretieren und du das genau richtig zu sehen. Damn.
Ich muß wohl doch jedes Studer-Gerät mit eigener ID ansprechen da Register jeweils gleich sind. Aber wie ändere ich die ID wenn diese in der DEF vorgegeben ist?
... und ich Frage mich, warum mir dann ID1 (Xcom485), Register 2 den Wert von eigentlich ID10/ID11 (Xtender), Register 2 gibt.

Anlage Appendix
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Januar 2021, 15:53:21
einfach für jedes Gerät auch ein eigenes Fhem-Gerät mit pasender ID anlegen.

Die nutzen dann alle das ModbusLine als IO-Device.

Wegen dem Bat-Temp-Wert: schick doch mal das Log, in dem man die tatsächlich gelesenen Byte-Werts sieht. Evt. ist ein anderer unpack-Code oder sogar das Attribut RevRegs nötig um die Register zu vertauschen. Das muss man ausprobieren.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 15:57:55
Danke. Ich versuche mal ein sauberes Reading auf richtiger ID anzulegen und dann mach ich ein Log.
Für später schraub ich aber erstmal das Ding auf und mach ein 33er Offset weil die SDM´s auf ID1 und ID2 liegen
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 17:38:20
Grandios! Infos lesen funktioniert jetzt. Danke Stefan.

[OT]
Aber was mir gerade auffällt: Ich habe wirklich Wiki, commandref durchgearbeitet und mir Beispiele angeschaut. Ich habe nichts/nicht viel verstanden.
Wenn ich jetzt die ersten Erfolge sehe, wundert es mich enorm, wie leicht es erscheint. Zumindest der erste Schritt.
Dein Modul ist hervorragend dokumentiert! .... aber setzt an einem Punkt an, wo wahrscheinlich die meisten inkl. mir vom Verständnis her (Modbus und der Wahnsinn dahinter) noch entfernt sind.
Ich fand fhem anfänglich recht steil von der Lernkurve her. Jetzt ist zumindest das Handling kinderleicht. Nicht weil ich es jetzt verstehe, sondern weil fhem an sich leicht ist ... wenn man die entscheidenden Vorgehensweisen am Anfang erklärt bekommt.
Frag mich nicht, worauf ich eigentlich hinauswill ;) ... wahrscheinlich das zur Erklärung und Entschuldigung wenn man sich bißchen blöd anstellt und Dankeschön an deine Geduld.
[OT Ende]

mit
Internals:
   DEF        11 5
   FUUID      5ff9d4f6-f33f-c138-b74c-0d17d513dd4c86d7
   IODev      ModbusLine
   Interval   5
   MODBUSID   11
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485_XTM
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-Studer485_XTM
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   READ:
   READINGS:
     2021-01-10 16:57:20   Battery_temperature 6
     2021-01-10 16:57:20   SoC             100
     2021-01-10 16:49:08   state           opened
   REMEMBER:
     lrecv      1610294240.29133
     lsend      1610294240.25963
   gotReadings:
     SoC        100
   lastRead:
     i14        1610294240.29408
     i2         1610294240.15802
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   obj-i14-len 2
   obj-i14-reading SoC
   obj-i14-unpack f>
   obj-i2-len 2
   obj-i2-reading Battery_temperature
   obj-i2-unpack f>


bekomme ich Infos aus dem Xtender. Mit

Internals:
   DEF        61 5
   FUUID      5ffb1f69-f33f-c138-fbe8-92096ca34e9a6870
   IODev      ModbusLine
   Interval   5
   MODBUSID   61
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485_BSP
   NOTIFYDEV  global
   NR         17
   NTFY_ORDER 50-Studer485_BSP
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   OLDREADINGS:
   READ:
   READINGS:
     2021-01-10 16:58:06   Charge_Discharge_W -2.091796875
   REMEMBER:
     lrecv      1610294286.48832
     lsend      1610294286.45657
   gotReadings:
     Charge_Discharge_W -2.091796875
   lastRead:
     i6         1610294286.49106
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   obj-i6-len 2
   obj-i6-reading Charge_Discharge_W
   obj-i6-unpack f>


Infos aus dem BSP.

Da es regnet und die Anlage recht weit weg ist, habe ich die ID´s jetzt erstmal ohne offset gelassen.

Ich bastel weiter und werde dann wieder Fragen. Danke erstmal.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 19:09:41
jetzt alle Info-Werte die ich bisher über die Cloud geholt habe auf dem Modbus.
Als nächstes schaue ich mal, wie man Setting Prameter schreibt. Ich bin bestimmt recht schnell wieder hier ;)

Aber Zwischenfrage wegen der Definition des Modbus-Devices:

wie bekomme ich (nach Umstellung der ID´s) den Xcom485 auf den selben Bus wie die SDM´s ... (wegen der ",8,E,1" - Problematik)?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 10 Januar 2021, 20:35:55
... und noch eine Frage:

attr Studer485_BSP obj-i6-format %2d
attr Studer485_BSP obj-i6-len 2
attr Studer485_BSP obj-i6-reading Charge_Discharge_W
attr Studer485_BSP obj-i6-unpack f>


generiert mir brav ein Reading. Dieses ist je nach Situation positiv oder negativ.
Allerdings bekomme ich im Log folgenden Fehler

Studer485_BSP: ParseObj unpack of d2 with f> for Charge_Discharge_W resulted in undefined value

habs auch schon mit allen möglichen anderen Parametern wie "s", "c", etc in "attr Studer485_BSP obj-i6-unpack f>" probiert, aber dann bekomme ich falsche Werte im Reading.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Hollo am 10 Januar 2021, 21:59:41
Zitat von: holle75 am 10 Januar 2021, 19:09:41
...Aber Zwischenfrage wegen der Definition des Modbus-Devices:

wie bekomme ich (nach Umstellung der ID´s) den Xcom485 auf den selben Bus wie die SDM´s ... (wegen der ",8,E,1" - Problematik)?
Das stellst du doch am Device ein, oder?
Den SDM kannst du auf jeden Fall passend konfigurieren.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Januar 2021, 22:03:48
Zitat von: holle75 am 10 Januar 2021, 20:35:55
Studer485_BSP: ParseObj unpack of d2 with f> for Charge_Discharge_W resulted in undefined value
habs auch schon mit allen möglichen anderen Parametern wie "s", "c", etc in "attr Studer485_BSP obj-i6-unpack f>" probiert, aber dann bekomme ich falsche Werte im Reading.

Da wäre ein größerer Ausschnitt aus dem Log sehr hilfreich, damit ich den Kontext sehe.
Scheinbar hat er in dieser Situation nur ein Byte (d2) als Eingabe für den unpack-Befehl. Der erwartet aber 4 Bytes ...

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 07:32:11
Zitat von: Hollo am 10 Januar 2021, 21:59:41
Das stellst du doch am Device ein, oder?
Den SDM kannst du auf jeden Fall passend konfigurieren.
Ja, aber am Modbus-Device. Weiß nicht wie man es nennt. Das Übergeordnete, welches dann auf deinen USB-Adapter zugreift. Dort muß ich im Falle Xcom485i das ",8,E,1" anhängen. Für die SDM´s ergibt sich aus der Nichtdefinition glaubs ",8,N,1"

Auf das Device greifen dann die Modbusattr zu. Oder ich verstehe es falsch.

hier hatte ich versucht es deutlicher zu beschreiben

Zitat von: holle75 am 10 Januar 2021, 13:57:36
Einer eine Idee, wie ich das mit der Parity ",8,E,1" mit den SDM´s kombiniert bekomme? Eben mal im Hauptsystem mit an die Definition gehängt, also anstatt

defmod Eastron Modbus /dev/ttyUSB1@9600
mit
defmod Eastron Modbus /dev/ttyUSB1@9600,8,E,1

dann kommen von den SDM´s keine Readings mehr. Mmmmmmmh.

Später würde ich schon gerne nur einen USB-Adaper und einen Bus betreiben.


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 07:36:16
Zitat von: StefanStrobel am 10 Januar 2021, 22:03:48
Da wäre ein größerer Ausschnitt aus dem Log sehr hilfreich, damit ich den Kontext sehe.
Scheinbar hat er in dieser Situation nur ein Byte (d2) als Eingabe für den unpack-Befehl. Der erwartet aber 4 Bytes ...

Gruß
   Stefan

ein Ausschnitt auf verbose 5:

2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate called from Fhem internal timer
2021.01.11 12:01:09 4: Studer485_BSP: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 12:01:14.427, interval 5
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate objects from attributes: i6 i4 i0 i58
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate full object list: i0 i4 i58 i6
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate check i0 => Volt_Batt, poll = 1, polldelay = 0.5, last = 1610362864.48518
2021.01.11 12:01:09 4: Studer485_BSP: GetUpdate will request Volt_Batt
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate check i4 => SoC, poll = 1, polldelay = 0.5, last = 1610362864.62137
2021.01.11 12:01:09 4: Studer485_BSP: GetUpdate will request SoC
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate check i58 => Temp_Batt, poll = 1, polldelay = 0.5, last = 1610362864.88605
2021.01.11 12:01:09 4: Studer485_BSP: GetUpdate will request Temp_Batt
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate check i6 => Charge_Discharge_W, poll = 1, polldelay = 0.5, last = 1610362389.51011
2021.01.11 12:01:09 4: Studer485_BSP: GetUpdate will request Charge_Discharge_W
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate tries to combine read commands
2021.01.11 12:01:09 4: Studer485_BSP: GetUpdate readList = i4 i58 i0 i6
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate cant combine request for Volt_Batt / i0 with SoC / i4, span 6 > max 1
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate cant combine request for SoC / i4 with Charge_Discharge_W / i6, span 6 > max 1
2021.01.11 12:01:09 5: Studer485_BSP: GetUpdate cant combine request for Charge_Discharge_W / i6 with Temp_Batt / i58, span 54 > max 1
2021.01.11 12:01:09 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate)
2021.01.11 12:01:09 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate)
2021.01.11 12:01:09 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i6, len 4, master device Studer485_BSP, reading Charge_Discharge_W (getUpdate)
2021.01.11 12:01:09 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate)
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 41ea000032, type i, adr 0, valuesLen 2, op read
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj unpacked 41ea000032 with f> to 29.25
2021.01.11 12:01:09 5: Studer485_BSP: FormatVal for ParseObj formats 29.25 with format %.2f, result is 29.25
2021.01.11 12:01:09 4: Studer485_BSP: ParseObj assigns value 29.25 to Volt_Batt
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i2
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj has no information about handling i2
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 42a6a0008b, type i, adr 4, valuesLen 2, op read
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj unpacked 42a6a0008b with f> to 83.3125
2021.01.11 12:01:09 5: Studer485_BSP: FormatVal for ParseObj formats 83.3125 with format %.1f, result is 83.3
2021.01.11 12:01:09 4: Studer485_BSP: ParseObj assigns value 83.3 to SoC
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i6
2021.01.11 12:01:09 3: Studer485_BSP: ParseObj unpack of 8b with f> for Charge_Discharge_W resulted in undefined value
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 40ce400042, type i, adr 58, valuesLen 2, op read
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj unpacked 40ce400042 with f> to 6.4453125
2021.01.11 12:01:09 5: Studer485_BSP: FormatVal for ParseObj formats 6.4453125 with format %.1f, result is 6.4
2021.01.11 12:01:09 4: Studer485_BSP: ParseObj assigns value 6.4 to Temp_Batt
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i60
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj has no information about handling i60
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:11 5: Studer485_XTM: GetUpdate called from Fhem internal timer
2021.01.11 12:01:11 4: Studer485_XTM: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 12:01:16.281, interval 5
2021.01.11 12:01:11 5: Studer485_XTM: GetUpdate objects from attributes: i64 i62
2021.01.11 12:01:11 5: Studer485_XTM: GetUpdate full object list: i62 i64
2021.01.11 12:01:11 5: Studer485_XTM: GetUpdate check i62 => State_of_auxiliary_relay_1, poll = 1, polldelay = 0.5, last = 1610362866.33345
2021.01.11 12:01:11 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_1
2021.01.11 12:01:11 5: Studer485_XTM: GetUpdate check i64 => State_of_auxiliary_relay_2, poll = 1, polldelay = 0.5, last = 1610362866.46564
2021.01.11 12:01:11 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_2
2021.01.11 12:01:11 5: Studer485_XTM: GetUpdate tries to combine read commands
2021.01.11 12:01:11 4: Studer485_XTM: GetUpdate readList = i62 i64
2021.01.11 12:01:11 5: Studer485_XTM: GetUpdate cant combine request for State_of_auxiliary_relay_1 / i62 with State_of_auxiliary_relay_2 / i64, span 4 > max 1
2021.01.11 12:01:11 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 11, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate)
2021.01.11 12:01:11 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 11, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate)
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj called from HandleResponse with data hex 3f8000005c, type i, adr 62, valuesLen 2, op read
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj unpacked 3f8000005c with f> to 1
2021.01.11 12:01:11 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_1
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj moves to next object, skip 2 to i64
2021.01.11 12:01:11 3: Studer485_XTM: ParseObj unpack of 5c with f> for State_of_auxiliary_relay_2 resulted in undefined value
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj created 1 readings
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj called from HandleResponse with data hex 3f8000005c, type i, adr 64, valuesLen 2, op read
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj unpacked 3f8000005c with f> to 1
2021.01.11 12:01:11 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_2
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj moves to next object, skip 2 to i66
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj has no information about handling i66
2021.01.11 12:01:11 5: Studer485_XTM: ParseObj created 1 readings
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate called from Fhem internal timer
2021.01.11 12:01:14 4: Studer485_BSP: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 12:01:19.429, interval 5
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate objects from attributes: i6 i4 i0 i58
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate full object list: i0 i4 i58 i6
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate check i0 => Volt_Batt, poll = 1, polldelay = 0.5, last = 1610362869.48205
2021.01.11 12:01:14 4: Studer485_BSP: GetUpdate will request Volt_Batt
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate check i4 => SoC, poll = 1, polldelay = 0.5, last = 1610362869.61799
2021.01.11 12:01:14 4: Studer485_BSP: GetUpdate will request SoC
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate check i58 => Temp_Batt, poll = 1, polldelay = 0.5, last = 1610362869.88394
2021.01.11 12:01:14 4: Studer485_BSP: GetUpdate will request Temp_Batt
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate check i6 => Charge_Discharge_W, poll = 1, polldelay = 0.5, last = 1610362389.51011
2021.01.11 12:01:14 4: Studer485_BSP: GetUpdate will request Charge_Discharge_W
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate tries to combine read commands
2021.01.11 12:01:14 4: Studer485_BSP: GetUpdate readList = i4 i58 i0 i6
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate cant combine request for Volt_Batt / i0 with SoC / i4, span 6 > max 1
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate cant combine request for SoC / i4 with Charge_Discharge_W / i6, span 6 > max 1
2021.01.11 12:01:14 5: Studer485_BSP: GetUpdate cant combine request for Charge_Discharge_W / i6 with Temp_Batt / i58, span 54 > max 1
2021.01.11 12:01:14 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate)
2021.01.11 12:01:14 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate)
2021.01.11 12:01:14 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i6, len 4, master device Studer485_BSP, reading Charge_Discharge_W (getUpdate)
2021.01.11 12:01:14 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate)
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 41ea20002b, type i, adr 0, valuesLen 2, op read
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj unpacked 41ea20002b with f> to 29.265625
2021.01.11 12:01:14 5: Studer485_BSP: FormatVal for ParseObj formats 29.265625 with format %.2f, result is 29.27
2021.01.11 12:01:14 4: Studer485_BSP: ParseObj assigns value 29.27 to Volt_Batt
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i2
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj has no information about handling i2
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 42a6a0008b, type i, adr 4, valuesLen 2, op read
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj unpacked 42a6a0008b with f> to 83.3125
2021.01.11 12:01:14 5: Studer485_BSP: FormatVal for ParseObj formats 83.3125 with format %.1f, result is 83.3
2021.01.11 12:01:14 4: Studer485_BSP: ParseObj assigns value 83.3 to SoC
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i6
2021.01.11 12:01:14 3: Studer485_BSP: ParseObj unpack of 8b with f> for Charge_Discharge_W resulted in undefined value
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 40ce400042, type i, adr 58, valuesLen 2, op read
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj unpacked 40ce400042 with f> to 6.4453125
2021.01.11 12:01:14 5: Studer485_BSP: FormatVal for ParseObj formats 6.4453125 with format %.1f, result is 6.4
2021.01.11 12:01:14 4: Studer485_BSP: ParseObj assigns value 6.4 to Temp_Batt
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i60
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj has no information about handling i60
2021.01.11 12:01:14 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:16 5: Studer485_XTM: GetUpdate called from Fhem internal timer
2021.01.11 12:01:16 4: Studer485_XTM: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 12:01:21.283, interval 5
2021.01.11 12:01:16 5: Studer485_XTM: GetUpdate objects from attributes: i64 i62
2021.01.11 12:01:16 5: Studer485_XTM: GetUpdate full object list: i62 i64
2021.01.11 12:01:16 5: Studer485_XTM: GetUpdate check i62 => State_of_auxiliary_relay_1, poll = 1, polldelay = 0.5, last = 1610362871.3374
2021.01.11 12:01:16 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_1
2021.01.11 12:01:16 5: Studer485_XTM: GetUpdate check i64 => State_of_auxiliary_relay_2, poll = 1, polldelay = 0.5, last = 1610362871.46565
2021.01.11 12:01:16 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_2
2021.01.11 12:01:16 5: Studer485_XTM: GetUpdate tries to combine read commands
2021.01.11 12:01:16 4: Studer485_XTM: GetUpdate readList = i64 i62
2021.01.11 12:01:16 5: Studer485_XTM: GetUpdate cant combine request for State_of_auxiliary_relay_1 / i62 with State_of_auxiliary_relay_2 / i64, span 4 > max 1
2021.01.11 12:01:16 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 11, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate)
2021.01.11 12:01:16 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 11, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate)
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj called from HandleResponse with data hex 3f8000005c, type i, adr 62, valuesLen 2, op read
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj unpacked 3f8000005c with f> to 1
2021.01.11 12:01:16 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_1
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj moves to next object, skip 2 to i64
2021.01.11 12:01:16 3: Studer485_XTM: ParseObj unpack of 5c with f> for State_of_auxiliary_relay_2 resulted in undefined value
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj created 1 readings
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj called from HandleResponse with data hex 3f8000005c, type i, adr 64, valuesLen 2, op read
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj unpacked 3f8000005c with f> to 1
2021.01.11 12:01:16 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_2
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj moves to next object, skip 2 to i66
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj has no information about handling i66
2021.01.11 12:01:16 5: Studer485_XTM: ParseObj created 1 readings
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate called from Fhem internal timer
2021.01.11 12:01:19 4: Studer485_BSP: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 12:01:24.431, interval 5
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate objects from attributes: i6 i4 i0 i58
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate full object list: i0 i4 i58 i6
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate check i0 => Volt_Batt, poll = 1, polldelay = 0.5, last = 1610362874.48505
2021.01.11 12:01:19 4: Studer485_BSP: GetUpdate will request Volt_Batt
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate check i4 => SoC, poll = 1, polldelay = 0.5, last = 1610362874.62105
2021.01.11 12:01:19 4: Studer485_BSP: GetUpdate will request SoC
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate check i58 => Temp_Batt, poll = 1, polldelay = 0.5, last = 1610362874.88452
2021.01.11 12:01:19 4: Studer485_BSP: GetUpdate will request Temp_Batt
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate check i6 => Charge_Discharge_W, poll = 1, polldelay = 0.5, last = 1610362389.51011
2021.01.11 12:01:19 4: Studer485_BSP: GetUpdate will request Charge_Discharge_W
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate tries to combine read commands
2021.01.11 12:01:19 4: Studer485_BSP: GetUpdate readList = i6 i0 i58 i4
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate cant combine request for Volt_Batt / i0 with SoC / i4, span 6 > max 1
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate cant combine request for SoC / i4 with Charge_Discharge_W / i6, span 6 > max 1
2021.01.11 12:01:19 5: Studer485_BSP: GetUpdate cant combine request for Charge_Discharge_W / i6 with Temp_Batt / i58, span 54 > max 1
2021.01.11 12:01:19 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate)
2021.01.11 12:01:19 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate)
2021.01.11 12:01:19 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i6, len 4, master device Studer485_BSP, reading Charge_Discharge_W (getUpdate)
2021.01.11 12:01:19 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 61, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate)
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 41e9e0008b, type i, adr 0, valuesLen 2, op read
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj unpacked 41e9e0008b with f> to 29.234375
2021.01.11 12:01:19 5: Studer485_BSP: FormatVal for ParseObj formats 29.234375 with format %.2f, result is 29.23
2021.01.11 12:01:19 4: Studer485_BSP: ParseObj assigns value 29.23 to Volt_Batt
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i2
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj has no information about handling i2
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 42a6a0008b, type i, adr 4, valuesLen 2, op read
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj unpacked 42a6a0008b with f> to 83.3125
2021.01.11 12:01:19 5: Studer485_BSP: FormatVal for ParseObj formats 83.3125 with format %.1f, result is 83.3
2021.01.11 12:01:19 4: Studer485_BSP: ParseObj assigns value 83.3 to SoC
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i6
2021.01.11 12:01:19 3: Studer485_BSP: ParseObj unpack of 8b with f> for Charge_Discharge_W resulted in undefined value
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 40ce400042, type i, adr 58, valuesLen 2, op read
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj unpacked 40ce400042 with f> to 6.4453125
2021.01.11 12:01:19 5: Studer485_BSP: FormatVal for ParseObj formats 6.4453125 with format %.1f, result is 6.4
2021.01.11 12:01:19 4: Studer485_BSP: ParseObj assigns value 6.4 to Temp_Batt
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj moves to next object, skip 2 to i60
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj has no information about handling i60
2021.01.11 12:01:19 5: Studer485_BSP: ParseObj created 1 readings
2021.01.11 12:01:21 5: Studer485_XTM: GetUpdate called from Fhem internal timer
2021.01.11 12:01:21 4: Studer485_XTM: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 12:01:26.285, interval 5
2021.01.11 12:01:21 5: Studer485_XTM: GetUpdate objects from attributes: i64 i62
2021.01.11 12:01:21 5: Studer485_XTM: GetUpdate full object list: i62 i64
2021.01.11 12:01:21 5: Studer485_XTM: GetUpdate check i62 => State_of_auxiliary_relay_1, poll = 1, polldelay = 0.5, last = 1610362876.355
2021.01.11 12:01:21 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_1
2021.01.11 12:01:21 5: Studer485_XTM: GetUpdate check i64 => State_of_auxiliary_relay_2, poll = 1, polldelay = 0.5, last = 1610362876.46781
2021.01.11 12:01:21 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_2
2021.01.11 12:01:21 5: Studer485_XTM: GetUpdate tries to combine read commands
2021.01.11 12:01:21 4: Studer485_XTM: GetUpdate readList = i64 i62
2021.01.11 12:01:21 5: Studer485_XTM: GetUpdate cant combine request for State_of_auxiliary_relay_1 / i62 with State_of_auxiliary_relay_2 / i64, span 4 > max 1
2021.01.11 12:01:21 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 11, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate)
2021.01.11 12:01:21 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 11, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate)
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj called from HandleResponse with data hex 3f8000005c, type i, adr 62, valuesLen 2, op read
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj unpacked 3f8000005c with f> to 1
2021.01.11 12:01:21 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_1
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj moves to next object, skip 2 to i64
2021.01.11 12:01:21 3: Studer485_XTM: ParseObj unpack of 5c with f> for State_of_auxiliary_relay_2 resulted in undefined value
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj created 1 readings
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj called from HandleResponse with data hex 3f8000005c, type i, adr 64, valuesLen 2, op read
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj unpacked 3f8000005c with f> to 1
2021.01.11 12:01:21 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_2
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj moves to next object, skip 2 to i66
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj has no information about handling i66
2021.01.11 12:01:21 5: Studer485_XTM: ParseObj created 1 readings


list device1
Internals:
   DEF        61 5
   FUUID      5ffb1f69-f33f-c138-fbe8-92096ca34e9a6870
   IODev      ModbusLine
   Interval   5
   MODBUSID   61
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485_BSP
   NOTIFYDEV  global
   NR         17
   NTFY_ORDER 50-Studer485_BSP
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   OLDREADINGS:
   READ:
   READINGS:
     2021-01-11 11:44:31   Charge_Discharge_W -946
     2021-01-11 11:44:31   SoC             83.3
     2021-01-11 11:44:31   Temp_Batt       6.2
     2021-01-11 11:44:31   Volt_Batt       27.14
     2021-01-11 07:37:25   state           opened
   REMEMBER:
     lrecv      1610361871.54109
     lsend      1610361871.50956
   gotReadings:
     Temp_Batt  6.2
   lastRead:
     i0         1610361871.13603
     i4         1610361871.27209
     i58        1610361871.54431
     i6         1610361871.40838
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   event-min-interval .*:1800
   event-on-change-reading Charge_Discharge_W:20,Volt_Batt:0.3,SoC,Temp_Batt
   event-on-update-reading .*
   obj-i0-format %.2f
   obj-i0-len 2
   obj-i0-reading Volt_Batt
   obj-i0-unpack f>
   obj-i4-format %.1f
   obj-i4-len 2
   obj-i4-reading SoC
   obj-i4-unpack f>
   obj-i58-format %.1f
   obj-i58-len 2
   obj-i58-reading Temp_Batt
   obj-i58-unpack f>
   obj-i6-format %2d
   obj-i6-len 2
   obj-i6-reading Charge_Discharge_W
   obj-i6-unpack f>
   verbose 5


list Device2
Internals:
   DEF        11 5
   FUUID      5ffc29b8-f33f-c138-f855-14efee2f996de15b
   IODev      ModbusLine
   Interval   5
   MODBUSID   11
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485_XTM
   NOTIFYDEV  global
   NR         18
   NTFY_ORDER 50-Studer485_XTM
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   OLDREADINGS:
   READ:
   READINGS:
     2021-01-11 12:02:46   State_of_auxiliary_relay_1 1
     2021-01-11 12:02:46   State_of_auxiliary_relay_2 1
     2021-01-11 11:58:06   state           opened
   REMEMBER:
     lrecv      1610362966.51022
     lsend      1610362966.47834
   gotReadings:
     State_of_auxiliary_relay_2 1
   lastRead:
     i62        1610362966.38218
     i64        1610362966.51496
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   event-min-interval .*:1800
   event-on-change-reading .*
   event-on-update-reading .*
   obj-i62-len 2
   obj-i62-reading State_of_auxiliary_relay_1
   obj-i62-unpack f>
   obj-i64-len 2
   obj-i64-reading State_of_auxiliary_relay_2
   obj-i64-unpack f>
   verbose    5


edit: sichergestellt, dass das Reading in Device1 auch gerade negativ war. Wobei der Fehler bei jedem Durchlauf, auch wenn positiv, kommt.
edit2: eben noch ein zweites Device erstellt. Auch hier kommen Fehler. Interessant, dass es jeweils dass letztdefinierte Reading ist.
edit3: Im zweiten Device Studer485_XTM soll laut Studer der Wert im Register als "ENUM" vorliegen. Mal gesucht und nicht wirklich Hilfreiches bzgl unpack dazu gefunden.
Auch wird ja das erste Reading, obwohl identisch, korrekt ausgelesen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Frank_Huber am 11 Januar 2021, 10:11:27
Hallo,

Ich habe ein kleines Problemchen mit negativen Werten die von meiner Heizung per Modbus IP kommen.

positive Werte entpacke ich mit "N", bei negativen kommt da aber nur murks.
Beispiel, Aussentemperatur -3.2 Grad.
unpack mit N: 429496726.3
unpack mit s>: -0.1
unpack mit s<: -0.1

EDIT: positive Werte werden nur mit "N" richtig entpackt und dargestellt.

Hier das List:
Internals:
   DEF        1 60 192.168.12.207:502 TCP
   DeviceName 192.168.12.207:502
   EXPECT     idle
   FUUID      5ffb04b9-f33f-5ef8-03a5-5c6c0fbebffc5dbe
   FVERSION   98_ModbusAttr.pm:0.234840/2021-01-07
   IODev      ETA_PU11_Modbus
   Interval   60
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       ETA_PU11_Modbus
   NOTIFYDEV  global
   NR         84
   NTFY_ORDER 50-ETA_PU11_Modbus
   PROTOCOL   TCP
   STATE      disabled
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   nextOpenDelay 60
   READ:
     BUFFER     
   READINGS:
     2021-01-11 10:04:48   Aussentemperatur -0.1
     2021-01-11 10:04:56   state           disabled
   REMEMBER:
     lid        1
     lname      ETA_PU11_Modbus
     lrecv      1610355888.20987
     lsend      1610355888.16397
   defptr:
     ETA_PU11_Modbus 1
   gotReadings:
     Aussentemperatur -0.1
   lastRead:
     h1010      1610355888.21235
Attributes:
   DbLogExclude .*
   disable    1
   group      ETA_Modbus
   obj-h1010-expr $val/10
   obj-h1010-len 2
   obj-h1010-poll 1
   obj-h1010-reading Aussentemperatur
   obj-h1010-unpack s<
   room       Heizung
   sortUpdate 1
   verbose    5


Im Anhang noch die verbose 5 Logs von "N", "s>" und "s<" sowie Screenshots vom Kessel.

weiß jemand Rat?

Danke & Grüße
Frank
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 12:06:51
Hallo Frank, meinen Beitrag über dir habe ich gerade nochmal editiert.
Ist es bei dir auch das letzte Reading im Device?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Frank_Huber am 11 Januar 2021, 12:13:08
Zitat von: holle75 am 11 Januar 2021, 12:06:51
Hallo Frank, meinen Beitrag über dir habe ich gerade nochmal editiert.
Ist es bei dir auch das letzte Reading im Device?
Nein, mein Problem kommt durch negative Werte.
Das list oben ist von meinem Test System. Dort rufe ich nur einen Wert ab.
Am produktiven System rufe ich so ca 20 Werte ab.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 12:19:13
Bei mir ist seltsam, dass im neu definierten Device zwei Werte und Register identisch abgefragt werden, aber nur das zweite und letzte Reading den Fehler wirft.
Auch im Device 1 ist es das letzte Reading.

Im Device 1 dachte ich auch, es hat was mit dem ab und zu negativen Wert zu tun.

Scheinen zwei unabhängige Probleme zu sein.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Frank_Huber am 11 Januar 2021, 12:22:03
Ja, das denke ich auch.
Die gleiche Definition funktioniert mit unpack N prima wenn der Wert positiv ist.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 15:57:10
Zitat von: Hollo am 10 Januar 2021, 21:59:41
Das stellst du doch am Device ein, oder?
Den SDM kannst du auf jeden Fall passend konfigurieren.

Aah, jetzt habe ich dich verstanden. Eben nochmals die Anleitung der SDM´s gelesen und DA kann man ebenfalls parity einstellen.
Top. Dann stell ich da auf E statt N und dann sind die SDM´s mit dem Xcom485 auf dem Modbus-Device/Bus mit der Erweiterung ",8,E,1" kompatibel.
Den Xcom485 kann man leider nicht auf N stellen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Januar 2021, 16:11:53
Hallo Holle75,

in deinem Log sind leider nur die logischen Devices mit verbose 5 drin. Das physische IO-Device (ModbusLine) fehlt. Das bräuchte ich aber auch.
Aus irgendeinem Grund kommt ein Byte zu viel von Deinem Gateway:

Zitat
2021.01.11 12:01:09 5: Studer485_BSP: ParseObj called from HandleResponse with data hex 41ea000032, type i, adr 0, valuesLen 2, op read

41ea00003 wäre als 32Bit Float ok, aber das 32 danach ist zu viel. Angefragt waren ja nur zwei Register, also 32 Bit.
Das Modul versucht das zusätzliche Byte dann für das nächste Objekt zu verwenden. Dafür ist es aber zu wenig.

Um es besser zu verstehen bräuchte ich das Log sowohl für die logischen Geräte als auch das physische IO-Device mit verbose 5.

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Januar 2021, 16:19:55
Hallo Frank,

dier Lösung findest Du hier:
https://perldoc.perl.org/functions/pack

N steht für "An unsigned long (32-bit) in "network" (big-endian) order."
Das verarbeitet 32 Bit (2 Register), kann aber mit negativen Zahlen nichts anfangen.

s steht für "A signed short (16-bit) value."
Das kann weder als s> noch s> etwas mit 32-Bit-Werten anfangen.

Wenn Deine Werte tatsächlich als 32-Bit signed integers aus zwei Registern geliefert werden, dann müsste der Unpack-Code l> für big endian long integer lauten.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Frank_Huber am 11 Januar 2021, 16:25:28
Danke Stefan,

wenn man weis wo man suchen muss ist das einfach. ;-)
Dachte es gibt nicht mehr als in der CREF steht.

Wir haben gerade 0,8 Grad Plus. Das klappt mit "l>" schonmal.
Mal schauen wann wir wieder in den Frost rutschen. ich geb Bescheid!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 16:26:50
Danke, als Anlage das Log
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 16:39:52
... und noch die passende Seite zum Auslesen von Infos als Extrakt von Studer.
Studer schmuggelt da noch ein Byte "Byte Count" in die Antwort??
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Januar 2021, 17:11:25
Hallo Holle75,

Dein Gateway hängt an die gültigen Modbus-Response-Frames noch ein zusätzliches 00 an.
Das bringt das Modbus-Modul etwas durcheinander.
Ich passe das Modul entsprechend an, dass es auch ohne Warning mit solchen Abarten klar kommt.
Bisher hatte ich so einen Fall noch nicht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 17:13:36
Nice! Danke

... kann  das was mit dem "ByteCount" zu tun haben? s.o.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Januar 2021, 19:39:40
Hallo,

der Byte-Count in einer Antwort für Function Code 3 oder 4 ist normal. Das 00 am Ende nicht.
Anbei eine neue Version zum Testen, die auch bei solchen Frames keine Warnungen erzeugen sollte.
Wenn das keine anderen Probleme erzeugt, checke ich es gleich wieder ein :-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 11 Januar 2021, 23:45:42
bis jetzt keine Fehlermeldungen im Log. Die Readings sind auch sauber.
Aber seltsam ist das schon, dass jetzt Studer meint, unsaubere Messages zu schicken?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Januar 2021, 07:10:13
Hallo Holle75,

es könnte auch an Deinem USB-RS485-Adapter liegen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 12 Januar 2021, 11:41:38
Gut zu wissen, Danke.
Gibt es eine Möglichkeit, zu überprüfen, ob weiterhin "defekte" Pakete gesendet werden?
So könnte ich an den Widerständen/Kabel spielen um das Problem zu finden.

-------------------------------------------------------------------------------------------------------------------------------------------------------

was mir gerade beim Einbringen der Readings auffällt ist diese blöde Verteilung von jedem ModbusAttr-Device auf jedes Einzelgerät bei Studer ... XTM, VT, BSP, etc.
Das ist von Studer mMn nicht wirklich sexy gelöst ... und würde es erschweren oder komplizierter machen, diese ganz vielen Readings die ich gerade einpflege in ein ModbusAttr-Modul zu packen. Resp. EIN Modul wäre dann ja gar nicht möglich weil dort EINE ID definiert ist?

Siehst du irgend eine (einfache) Möglichkeit, bei der Definition der Readings auch eine ID zu übergeben? So mal ganz ins Blaue gefragt.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 12 Januar 2021, 16:16:55
Habe jetzt mal ein global verbose 4 laufen lassen.

Muss man sich über die häufigeren (jetzt nur zweimal weil kleiner Zeitraum) "Got 7 but expecting 9 bytes", "Got 8 but expecting 9 bytes" Gedanken machen?

2021.01.12 16:08:40 3: Opening ModbusLine device /dev/ttyUSB0
2021.01.12 16:08:40 3: Setting ModbusLine serial parameters to 9600,8,E,1
2021.01.12 16:08:40 3: ModbusLine device opened
2021.01.12 16:08:40 3: Studer485_BSP: RegisterAtIODev called from SetIODev registers Studer485_BSP at ModbusLine with id 93, MODE master, PROTOCOL RTU
2021.01.12 16:08:40 3: Studer485_BSP: Notify / Init: using ModbusLine for communication
2021.01.12 16:08:40 3: Studer485_VT: RegisterAtIODev called from SetIODev registers Studer485_VT at ModbusLine with id 53, MODE master, PROTOCOL RTU
2021.01.12 16:08:40 3: Studer485_VT: Notify / Init: using ModbusLine for communication
2021.01.12 16:08:40 3: Studer485_XTM: RegisterAtIODev called from SetIODev registers Studer485_XTM at ModbusLine with id 43, MODE master, PROTOCOL RTU
2021.01.12 16:08:40 3: Studer485_XTM: Notify / Init: using ModbusLine for communication
2021.01.12 16:08:40 0: Featurelevel: 6
2021.01.12 16:08:40 0: Server started with 9 defined entities (fhem.pl:23471/2021-01-04 perl:5.028001 os:linux user:fhem pid:4443)
2021.01.12 16:09:12 4: WEB: /fhem?cmd.attrglobal%3Dattr%20global%20verbose%204&XHR=1&fwcsrf=csrf_397473377530003&fw_id=24 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2021.01.12 16:09:12 4: Connection closed for WEB_192.168.10.21_51805: EOF
2021.01.12 16:09:12 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data
2021.01.12 16:09:12 4: WEB_192.168.10.21_51806 GET /fhem?detail=global&fw_id=24; BUFLEN:0
2021.01.12 16:09:12 4: WEB: /fhem?detail=global&fw_id=24 / RL:3837 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2021.01.12 16:09:12 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 0400000000
2021.01.12 16:09:12 4: Studer485_XTM: ParseObj assigns value 0.00 to Input_power
2021.01.12 16:09:12 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404000000007046, id 43, fCode 4,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate), queued 1.00 secs ago, sent 0.06 secs ago,
response: id 43, fc 4 i26, len 2, value 00000000
2021.01.12 16:09:12 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:12 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 4, sending 2b04002a000257c9 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate), queued 1.09 secs ago
2021.01.12 16:09:12 4: WEB_192.168.10.21_51806 GET /fhem?cmd=%7BAttrVal(%22global%22%2C%22room%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_397473377530003; BUFLEN:0
2021.01.12 16:09:12 4: WEB: /fhem?cmd=%7BAttrVal(%22global%22%2C%22room%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_397473377530003 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2021.01.12 16:09:12 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 04435d
2021.01.12 16:09:12 4: ModbusLine: ParseResponse got incomplete frame. Got 7 but expecting 9 bytes
2021.01.12 16:09:12 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 04435d0000
2021.01.12 16:09:12 4: Studer485_XTM: ParseObj assigns value 221 to Output_voltage
2021.01.12 16:09:12 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404435d0000f410, id 43, fCode 4,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate), queued 1.15 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i42, len 2, value 435d0000
2021.01.12 16:09:12 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:12 4: WEB_192.168.10.21_51806 GET /fhem?XHR=1&inform=type=status;filter=global;since=1610464151;fmt=JSON&fw_id=24×tamp=1610464136897; BUFLEN:0
2021.01.12 16:09:12 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 3, sending 2b04002e00021608 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate), queued 1.24 secs ago
2021.01.12 16:09:12 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f440000
2021.01.12 16:09:12 4: Studer485_XTM: ParseObj assigns value 0.77 to Output_power
2021.01.12 16:09:12 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f4400003c47, id 43, fCode 4,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate), queued 1.29 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i46, len 2, value 3f440000
2021.01.12 16:09:12 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:12 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 2, sending 2b04003e000217cd via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate), queued 1.39 secs ago
2021.01.12 16:09:12 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f800000
2021.01.12 16:09:12 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_1
2021.01.12 16:09:12 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f8000007dba, id 43, fCode 4,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate), queued 1.43 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i62, len 2, value 3f800000
2021.01.12 16:09:12 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:12 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 1, sending 2b040040000277d5 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate), queued 1.53 secs ago
2021.01.12 16:09:12 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f800000
2021.01.12 16:09:12 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_2
2021.01.12 16:09:12 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f8000007dba, id 43, fCode 4,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate), queued 1.58 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i64, len 2, value 3f800000
2021.01.12 16:09:14 4: Connection closed for WEB_192.168.10.21_51806: EOF
2021.01.12 16:09:14 4: Connection accepted from WEB_192.168.10.21_51807
2021.01.12 16:09:14 4: WEB_192.168.10.21_51807 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:14 4: WEB_192.168.10.21_51807 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464153;fmt=JSON&fw_id=26×tamp=1610464139325; BUFLEN:0
2021.01.12 16:09:16 4: Studer485_BSP: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:21.067, interval 5
2021.01.12 16:09:16 4: Studer485_BSP: GetUpdate will request Volt_Batt
2021.01.12 16:09:16 4: Studer485_BSP: GetUpdate will request SoC
2021.01.12 16:09:16 4: Studer485_BSP: GetUpdate will request Temp_Batt
2021.01.12 16:09:16 4: Studer485_BSP: GetUpdate will request Power
2021.01.12 16:09:16 4: Studer485_BSP: GetUpdate readList = i6 i4 i58 i0
2021.01.12 16:09:16 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate)
2021.01.12 16:09:16 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate)
2021.01.12 16:09:16 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate)
2021.01.12 16:09:16 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate)
2021.01.12 16:09:16 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 4, sending 5d04000000027d57 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate), queued 0.01 secs ago
2021.01.12 16:09:16 4: Studer485_VT: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:21.084, interval 5
2021.01.12 16:09:16 4: Studer485_VT: GetUpdate will request PV_Day_KWh
2021.01.12 16:09:16 4: Studer485_VT: GetUpdate will request Battery_cycle_phase
2021.01.12 16:09:16 4: Studer485_VT: GetUpdate will request PV_Power_KW
2021.01.12 16:09:16 4: Studer485_VT: GetUpdate readList = i76 i8 i14
2021.01.12 16:09:16 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate)
2021.01.12 16:09:16 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate)
2021.01.12 16:09:16 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate)
2021.01.12 16:09:16 4: Studer485_XTM: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:21.094, interval 5
2021.01.12 16:09:16 4: Studer485_XTM: GetUpdate will request Input_voltage
2021.01.12 16:09:16 4: Studer485_XTM: GetUpdate will request Input_power
2021.01.12 16:09:16 4: Studer485_XTM: GetUpdate will request Output_voltage
2021.01.12 16:09:16 4: Studer485_XTM: GetUpdate will request Output_power
2021.01.12 16:09:16 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_1
2021.01.12 16:09:16 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_2
2021.01.12 16:09:16 4: Studer485_XTM: GetUpdate readList = i22 i26 i46 i62 i42 i64
2021.01.12 16:09:16 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate)
2021.01.12 16:09:16 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate)
2021.01.12 16:09:16 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate)
2021.01.12 16:09:16 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate)
2021.01.12 16:09:16 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate)
2021.01.12 16:09:16 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate)
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 0441c6a000
2021.01.12 16:09:16 4: Studer485_BSP: ParseObj assigns value 24.83 to Volt_Batt
2021.01.12 16:09:16 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d040441c6a000eb80, id 93, fCode 4,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate), queued 0.05 secs ago, sent 0.04 secs ago,
response: id 93, fc 4, len 2, value 41c6a000
2021.01.12 16:09:16 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.092
2021.01.12 16:09:16 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 12, sending 5d04000400023c96 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate), queued 0.14 secs ago
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 0442b2e000
2021.01.12 16:09:16 4: Studer485_BSP: ParseObj assigns value 89.4 to SoC
2021.01.12 16:09:16 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d040442b2e0009a1e, id 93, fCode 4,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate), queued 0.19 secs ago, sent 0.05 secs ago,
response: id 93, fc 4 i4, len 2, value 42b2e000
2021.01.12 16:09:16 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.093
2021.01.12 16:09:16 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 11, sending 5d04000600029d56 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate), queued 0.28 secs ago
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 04c3ee6000
2021.01.12 16:09:16 4: Studer485_BSP: ParseObj assigns value -476 to Power
2021.01.12 16:09:16 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d0404c3ee600013f0, id 93, fCode 4,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate), queued 0.33 secs ago, sent 0.05 secs ago,
response: id 93, fc 4 i6, len 2, value c3ee6000
2021.01.12 16:09:16 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.092
2021.01.12 16:09:16 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 10, sending 5d04003a00025d5a via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate), queued 0.42 secs ago
2021.01.12 16:09:16 4: Connection closed for WEB_192.168.10.21_51807: EOF
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 04410fa000
2021.01.12 16:09:16 4: Studer485_BSP: ParseObj assigns value 9.0 to Temp_Batt
2021.01.12 16:09:16 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d0404410fa0003bbe, id 93, fCode 4,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate), queued 0.47 secs ago, sent 0.05 secs ago,
response: id 93, fc 4 i58, len 2, value 410fa000
2021.01.12 16:09:16 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 9, sending 350400080002f47d via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate), queued 0.46 secs ago
2021.01.12 16:09:16 4: Connection accepted from WEB_192.168.10.21_51808
2021.01.12 16:09:16 4: WEB_192.168.10.21_51808 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 043e7ec000
2021.01.12 16:09:16 4: Studer485_VT: ParseObj assigns value 0.25 to PV_Power_KW
2021.01.12 16:09:16 4: ModbusLine: HandleResponse done, current frame / read buffer: 3504043e7ec000b3b7, id 53, fCode 4,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate), queued 0.57 secs ago, sent 0.10 secs ago,
response: id 53, fc 4 i8, len 2, value 3e7ec000
2021.01.12 16:09:16 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.092
2021.01.12 16:09:16 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 8, sending 3504000e0002147c via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate), queued 0.66 secs ago
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 0440b6c000
2021.01.12 16:09:16 4: Studer485_VT: ParseObj assigns value 5.71 to PV_Day_KWh
2021.01.12 16:09:16 4: ModbusLine: HandleResponse done, current frame / read buffer: 35040440b6c0002a61, id 53, fCode 4,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate), queued 0.70 secs ago, sent 0.04 secs ago,
response: id 53, fc 4 i14, len 2, value 40b6c000
2021.01.12 16:09:16 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.096
2021.01.12 16:09:16 4: WEB_192.168.10.21_51808 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464155;fmt=JSON&fw_id=27×tamp=1610464141484; BUFLEN:0
2021.01.12 16:09:16 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 7, sending 3504004c0002b468 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate), queued 0.79 secs ago
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 0440400000
2021.01.12 16:09:16 4: Studer485_VT: ParseObj assigns value Floating to Battery_cycle_phase
2021.01.12 16:09:16 4: ModbusLine: HandleResponse done, current frame / read buffer: 350404404000009a53, id 53, fCode 4,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate), queued 0.84 secs ago, sent 0.05 secs ago,
response: id 53, fc 4 i76, len 2, value 40400000
2021.01.12 16:09:16 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 6, sending 2b040016000297c5 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate), queued 0.83 secs ago
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data
2021.01.12 16:09:16 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 04436a0000
2021.01.12 16:09:16 4: Studer485_XTM: ParseObj assigns value 234 to Input_voltage
2021.01.12 16:09:16 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404436a000045de, id 43, fCode 4,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate), queued 0.88 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i22, len 2, value 436a0000
2021.01.12 16:09:16 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.095
2021.01.12 16:09:17 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 5, sending 2b04001a000257c6 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate), queued 0.97 secs ago
2021.01.12 16:09:17 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 0400000000
2021.01.12 16:09:17 4: Studer485_XTM: ParseObj assigns value 0.00 to Input_power
2021.01.12 16:09:17 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404000000007046, id 43, fCode 4,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate), queued 1.02 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i26, len 2, value 00000000
2021.01.12 16:09:17 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.093
2021.01.12 16:09:17 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 4, sending 2b04002a000257c9 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate), queued 1.12 secs ago
2021.01.12 16:09:17 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data
2021.01.12 16:09:17 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 04435d0000
2021.01.12 16:09:17 4: Studer485_XTM: ParseObj assigns value 221 to Output_voltage
2021.01.12 16:09:17 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404435d0000f410, id 43, fCode 4,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate), queued 1.16 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i42, len 2, value 435d0000
2021.01.12 16:09:17 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.095
2021.01.12 16:09:17 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 3, sending 2b04002e00021608 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate), queued 1.26 secs ago
2021.01.12 16:09:17 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data
2021.01.12 16:09:17 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f440000
2021.01.12 16:09:17 4: Studer485_XTM: ParseObj assigns value 0.77 to Output_power
2021.01.12 16:09:17 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f4400003c47, id 43, fCode 4,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate), queued 1.31 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i46, len 2, value 3f440000
2021.01.12 16:09:17 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:17 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 2, sending 2b04003e000217cd via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate), queued 1.40 secs ago
2021.01.12 16:09:17 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f800000
2021.01.12 16:09:17 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_1
2021.01.12 16:09:17 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f8000007dba, id 43, fCode 4,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate), queued 1.45 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i62, len 2, value 3f800000
2021.01.12 16:09:17 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:17 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 1, sending 2b040040000277d5 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate), queued 1.55 secs ago
2021.01.12 16:09:17 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f800000
2021.01.12 16:09:17 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_2
2021.01.12 16:09:17 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f8000007dba, id 43, fCode 4,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate), queued 1.59 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i64, len 2, value 3f800000
2021.01.12 16:09:18 4: Connection closed for WEB_192.168.10.21_51808: EOF
2021.01.12 16:09:18 4: Connection accepted from WEB_192.168.10.21_51809
2021.01.12 16:09:18 4: WEB_192.168.10.21_51809 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:18 4: WEB_192.168.10.21_51809 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464157;fmt=JSON&fw_id=28×tamp=1610464143242; BUFLEN:0
2021.01.12 16:09:19 4: Connection closed for WEB_192.168.10.21_51809: EOF
2021.01.12 16:09:19 4: Connection accepted from WEB_192.168.10.21_51810
2021.01.12 16:09:19 4: WEB_192.168.10.21_51810 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:19 4: WEB_192.168.10.21_51810 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464158;fmt=JSON&fw_id=29×tamp=1610464144554; BUFLEN:0
2021.01.12 16:09:20 4: Connection closed for WEB_192.168.10.21_51810: EOF
2021.01.12 16:09:20 4: Connection accepted from WEB_192.168.10.21_51811
2021.01.12 16:09:20 4: WEB_192.168.10.21_51811 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:21 4: WEB_192.168.10.21_51811 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464159;fmt=JSON&fw_id=30×tamp=1610464145654; BUFLEN:0
2021.01.12 16:09:21 4: Studer485_BSP: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:26.067, interval 5
2021.01.12 16:09:21 4: Studer485_BSP: GetUpdate will request Volt_Batt
2021.01.12 16:09:21 4: Studer485_BSP: GetUpdate will request SoC
2021.01.12 16:09:21 4: Studer485_BSP: GetUpdate will request Temp_Batt
2021.01.12 16:09:21 4: Studer485_BSP: GetUpdate will request Power
2021.01.12 16:09:21 4: Studer485_BSP: GetUpdate readList = i58 i0 i4 i6
2021.01.12 16:09:21 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate)
2021.01.12 16:09:21 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate)
2021.01.12 16:09:21 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate)
2021.01.12 16:09:21 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate)
2021.01.12 16:09:21 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 4, sending 5d04000000027d57 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate), queued 0.00 secs ago
2021.01.12 16:09:21 4: Studer485_VT: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:26.084, interval 5
2021.01.12 16:09:21 4: Studer485_VT: GetUpdate will request PV_Day_KWh
2021.01.12 16:09:21 4: Studer485_VT: GetUpdate will request Battery_cycle_phase
2021.01.12 16:09:21 4: Studer485_VT: GetUpdate will request PV_Power_KW
2021.01.12 16:09:21 4: Studer485_VT: GetUpdate readList = i8 i14 i76
2021.01.12 16:09:21 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate)
2021.01.12 16:09:21 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate)
2021.01.12 16:09:21 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate)
2021.01.12 16:09:21 4: Studer485_XTM: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:26.094, interval 5
2021.01.12 16:09:21 4: Studer485_XTM: GetUpdate will request Input_voltage
2021.01.12 16:09:21 4: Studer485_XTM: GetUpdate will request Input_power
2021.01.12 16:09:21 4: Studer485_XTM: GetUpdate will request Output_voltage
2021.01.12 16:09:21 4: Studer485_XTM: GetUpdate will request Output_power
2021.01.12 16:09:21 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_1
2021.01.12 16:09:21 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_2
2021.01.12 16:09:21 4: Studer485_XTM: GetUpdate readList = i64 i26 i22 i42 i62 i46
2021.01.12 16:09:21 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate)
2021.01.12 16:09:21 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate)
2021.01.12 16:09:21 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate)
2021.01.12 16:09:21 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate)
2021.01.12 16:09:21 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate)
2021.01.12 16:09:21 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate)
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 0441c68000
2021.01.12 16:09:21 4: Studer485_BSP: ParseObj assigns value 24.81 to Volt_Batt
2021.01.12 16:09:21 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d040441c68000f240, id 93, fCode 4,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate), queued 0.05 secs ago, sent 0.04 secs ago,
response: id 93, fc 4, len 2, value 41c68000
2021.01.12 16:09:21 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.096
2021.01.12 16:09:21 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 12, sending 5d04000400023c96 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate), queued 0.14 secs ago
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 0442b2e000
2021.01.12 16:09:21 4: Studer485_BSP: ParseObj assigns value 89.4 to SoC
2021.01.12 16:09:21 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d040442b2e0009a1e, id 93, fCode 4,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate), queued 0.19 secs ago, sent 0.05 secs ago,
response: id 93, fc 4 i4, len 2, value 42b2e000
2021.01.12 16:09:21 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.096
2021.01.12 16:09:21 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 11, sending 5d04000600029d56 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate), queued 0.29 secs ago
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 04c3ee2000
2021.01.12 16:09:21 4: Studer485_BSP: ParseObj assigns value -476 to Power
2021.01.12 16:09:21 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d0404c3ee20002230, id 93, fCode 4,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate), queued 0.33 secs ago, sent 0.05 secs ago,
response: id 93, fc 4 i6, len 2, value c3ee2000
2021.01.12 16:09:21 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.096
2021.01.12 16:09:21 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 10, sending 5d04003a00025d5a via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate), queued 0.43 secs ago
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 04410fc000
2021.01.12 16:09:21 4: Studer485_BSP: ParseObj assigns value 9.0 to Temp_Batt
2021.01.12 16:09:21 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d0404410fc00013be, id 93, fCode 4,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate), queued 0.48 secs ago, sent 0.05 secs ago,
response: id 93, fc 4 i58, len 2, value 410fc000
2021.01.12 16:09:21 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 9, sending 350400080002f47d via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate), queued 0.47 secs ago
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 043e7e4000
2021.01.12 16:09:21 4: Studer485_VT: ParseObj assigns value 0.25 to PV_Power_KW
2021.01.12 16:09:21 4: ModbusLine: HandleResponse done, current frame / read buffer: 3504043e7e4000d277, id 53, fCode 4,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate), queued 0.51 secs ago, sent 0.05 secs ago,
response: id 53, fc 4 i8, len 2, value 3e7e4000
2021.01.12 16:09:21 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.092
2021.01.12 16:09:21 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 8, sending 3504000e0002147c via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate), queued 0.61 secs ago
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 0440b6e000
2021.01.12 16:09:21 4: Studer485_VT: ParseObj assigns value 5.71 to PV_Day_KWh
2021.01.12 16:09:21 4: ModbusLine: HandleResponse done, current frame / read buffer: 35040440b6e00033a1, id 53, fCode 4,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate), queued 0.65 secs ago, sent 0.05 secs ago,
response: id 53, fc 4 i14, len 2, value 40b6e000
2021.01.12 16:09:21 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.093
2021.01.12 16:09:21 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 7, sending 3504004c0002b468 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate), queued 0.75 secs ago
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 0440400000
2021.01.12 16:09:21 4: Studer485_VT: ParseObj assigns value Floating to Battery_cycle_phase
2021.01.12 16:09:21 4: ModbusLine: HandleResponse done, current frame / read buffer: 350404404000009a53, id 53, fCode 4,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate), queued 0.80 secs ago, sent 0.05 secs ago,
response: id 53, fc 4 i76, len 2, value 40400000
2021.01.12 16:09:21 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 6, sending 2b040016000297c5 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate), queued 0.79 secs ago
2021.01.12 16:09:21 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 04436a0000
2021.01.12 16:09:21 4: Studer485_XTM: ParseObj assigns value 234 to Input_voltage
2021.01.12 16:09:21 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404436a000045de, id 43, fCode 4,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate), queued 0.84 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i22, len 2, value 436a0000
2021.01.12 16:09:21 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.090
2021.01.12 16:09:22 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 5, sending 2b04001a000257c6 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate), queued 0.93 secs ago
2021.01.12 16:09:22 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 0400000000
2021.01.12 16:09:22 4: Studer485_XTM: ParseObj assigns value 0.00 to Input_power
2021.01.12 16:09:22 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404000000007046, id 43, fCode 4,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate), queued 0.98 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i26, len 2, value 00000000
2021.01.12 16:09:22 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:22 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 4, sending 2b04002a000257c9 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate), queued 1.08 secs ago
2021.01.12 16:09:22 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 04435d0000
2021.01.12 16:09:22 4: Studer485_XTM: ParseObj assigns value 221 to Output_voltage
2021.01.12 16:09:22 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404435d0000f410, id 43, fCode 4,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate), queued 1.12 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i42, len 2, value 435d0000
2021.01.12 16:09:22 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:22 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 3, sending 2b04002e00021608 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate), queued 1.22 secs ago
2021.01.12 16:09:22 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043e980000
2021.01.12 16:09:22 4: Studer485_XTM: ParseObj assigns value 0.30 to Output_power
2021.01.12 16:09:22 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043e980000fc41, id 43, fCode 4,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate), queued 1.27 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i46, len 2, value 3e980000
2021.01.12 16:09:22 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.089
2021.01.12 16:09:22 4: Connection closed for WEB_192.168.10.21_51811: EOF
2021.01.12 16:09:22 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 2, sending 2b04003e000217cd via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate), queued 1.36 secs ago
2021.01.12 16:09:22 4: Connection accepted from WEB_192.168.10.21_51812
2021.01.12 16:09:22 4: WEB_192.168.10.21_51812 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:22 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f800000
2021.01.12 16:09:22 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_1
2021.01.12 16:09:22 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f8000007dba, id 43, fCode 4,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate), queued 1.46 secs ago, sent 0.11 secs ago,
response: id 43, fc 4 i62, len 2, value 3f800000
2021.01.12 16:09:22 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.095
2021.01.12 16:09:22 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 1, sending 2b040040000277d5 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate), queued 1.56 secs ago
2021.01.12 16:09:22 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f8000
2021.01.12 16:09:22 4: ModbusLine: ParseResponse got incomplete frame. Got 8 but expecting 9 bytes
2021.01.12 16:09:22 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f800000
2021.01.12 16:09:22 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_2
2021.01.12 16:09:22 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f8000007dba, id 43, fCode 4,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate), queued 1.61 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i64, len 2, value 3f800000
2021.01.12 16:09:22 4: WEB_192.168.10.21_51812 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464161;fmt=JSON&fw_id=31×tamp=1610464147425; BUFLEN:0
2021.01.12 16:09:24 4: Connection closed for WEB_192.168.10.21_51812: EOF
2021.01.12 16:09:24 4: Connection accepted from WEB_192.168.10.21_51813
2021.01.12 16:09:24 4: WEB_192.168.10.21_51813 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:24 4: WEB_192.168.10.21_51813 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464163;fmt=JSON&fw_id=32×tamp=1610464149074; BUFLEN:0
2021.01.12 16:09:26 4: Studer485_BSP: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:31.069, interval 5
2021.01.12 16:09:26 4: Studer485_BSP: GetUpdate will request Volt_Batt
2021.01.12 16:09:26 4: Studer485_BSP: GetUpdate will request SoC
2021.01.12 16:09:26 4: Studer485_BSP: GetUpdate will request Temp_Batt
2021.01.12 16:09:26 4: Studer485_BSP: GetUpdate will request Power
2021.01.12 16:09:26 4: Studer485_BSP: GetUpdate readList = i6 i4 i0 i58
2021.01.12 16:09:26 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate)
2021.01.12 16:09:26 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate)
2021.01.12 16:09:26 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate)
2021.01.12 16:09:26 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate)
2021.01.12 16:09:26 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 4, sending 5d04000000027d57 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate), queued 0.01 secs ago
2021.01.12 16:09:26 4: Studer485_VT: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:31.087, interval 5
2021.01.12 16:09:26 4: Studer485_VT: GetUpdate will request PV_Day_KWh
2021.01.12 16:09:26 4: Studer485_VT: GetUpdate will request Battery_cycle_phase
2021.01.12 16:09:26 4: Studer485_VT: GetUpdate will request PV_Power_KW
2021.01.12 16:09:26 4: Studer485_VT: GetUpdate readList = i76 i8 i14
2021.01.12 16:09:26 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate)
2021.01.12 16:09:26 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate)
2021.01.12 16:09:26 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate)
2021.01.12 16:09:26 4: Studer485_XTM: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:31.098, interval 5
2021.01.12 16:09:26 4: Studer485_XTM: GetUpdate will request Input_voltage
2021.01.12 16:09:26 4: Studer485_XTM: GetUpdate will request Input_power
2021.01.12 16:09:26 4: Studer485_XTM: GetUpdate will request Output_voltage
2021.01.12 16:09:26 4: Studer485_XTM: GetUpdate will request Output_power
2021.01.12 16:09:26 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_1
2021.01.12 16:09:26 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_2
2021.01.12 16:09:26 4: Studer485_XTM: GetUpdate readList = i64 i22 i26 i62 i46 i42
2021.01.12 16:09:26 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate)
2021.01.12 16:09:26 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate)
2021.01.12 16:09:26 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate)
2021.01.12 16:09:26 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate)
2021.01.12 16:09:26 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate)
2021.01.12 16:09:26 4: Studer485_XTM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate)
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 0441c86000
2021.01.12 16:09:26 4: Studer485_BSP: ParseObj assigns value 25.05 to Volt_Batt
2021.01.12 16:09:26 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d040441c86000da43, id 93, fCode 4,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate), queued 0.05 secs ago, sent 0.04 secs ago,
response: id 93, fc 4, len 2, value 41c86000
2021.01.12 16:09:26 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.092
2021.01.12 16:09:26 4: Connection closed for WEB_192.168.10.21_51813: EOF
2021.01.12 16:09:26 4: Connection accepted from WEB_192.168.10.21_51814
2021.01.12 16:09:26 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 12, sending 5d04000400023c96 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate), queued 0.16 secs ago
2021.01.12 16:09:26 4: WEB_192.168.10.21_51814 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 0442b2e000
2021.01.12 16:09:26 4: Studer485_BSP: ParseObj assigns value 89.4 to SoC
2021.01.12 16:09:26 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d040442b2e0009a1e, id 93, fCode 4,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate), queued 0.20 secs ago, sent 0.04 secs ago,
response: id 93, fc 4 i4, len 2, value 42b2e000
2021.01.12 16:09:26 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.096
2021.01.12 16:09:26 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 11, sending 5d04000600029d56 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate), queued 0.30 secs ago
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 04c2430000
2021.01.12 16:09:26 4: Studer485_BSP: ParseObj assigns value -48 to Power
2021.01.12 16:09:26 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d0404c2430000abed, id 93, fCode 4,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate), queued 0.34 secs ago, sent 0.05 secs ago,
response: id 93, fc 4 i6, len 2, value c2430000
2021.01.12 16:09:26 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.095
2021.01.12 16:09:26 4: WEB_192.168.10.21_51814 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464165;fmt=JSON&fw_id=33×tamp=1610464151084; BUFLEN:0
2021.01.12 16:09:26 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 10, sending 5d04003a00025d5a via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate), queued 0.44 secs ago
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 93, fCode 4 and data 04410fc000
2021.01.12 16:09:26 4: Studer485_BSP: ParseObj assigns value 9.0 to Temp_Batt
2021.01.12 16:09:26 4: ModbusLine: HandleResponse done, current frame / read buffer: 5d0404410fc00013be, id 93, fCode 4,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate), queued 0.48 secs ago, sent 0.05 secs ago,
response: id 93, fc 4 i58, len 2, value 410fc000
2021.01.12 16:09:26 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 9, sending 350400080002f47d via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate), queued 0.47 secs ago
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 043e7d4000
2021.01.12 16:09:26 4: Studer485_VT: ParseObj assigns value 0.25 to PV_Power_KW
2021.01.12 16:09:26 4: ModbusLine: HandleResponse done, current frame / read buffer: 3504043e7d40002277, id 53, fCode 4,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate), queued 0.52 secs ago, sent 0.05 secs ago,
response: id 53, fc 4 i8, len 2, value 3e7d4000
2021.01.12 16:09:26 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.096
2021.01.12 16:09:26 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 8, sending 3504000e0002147c via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate), queued 0.62 secs ago
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 0440b6e000
2021.01.12 16:09:26 4: Studer485_VT: ParseObj assigns value 5.71 to PV_Day_KWh
2021.01.12 16:09:26 4: ModbusLine: HandleResponse done, current frame / read buffer: 35040440b6e00033a1, id 53, fCode 4,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate), queued 0.66 secs ago, sent 0.05 secs ago,
response: id 53, fc 4 i14, len 2, value 40b6e000
2021.01.12 16:09:26 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.096
2021.01.12 16:09:26 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 7, sending 3504004c0002b468 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate), queued 0.76 secs ago
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 53, fCode 4 and data 0440400000
2021.01.12 16:09:26 4: Studer485_VT: ParseObj assigns value Floating to Battery_cycle_phase
2021.01.12 16:09:26 4: ModbusLine: HandleResponse done, current frame / read buffer: 350404404000009a53, id 53, fCode 4,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate), queued 0.81 secs ago, sent 0.05 secs ago,
response: id 53, fc 4 i76, len 2, value 40400000
2021.01.12 16:09:26 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 6, sending 2b040016000297c5 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate), queued 0.80 secs ago
2021.01.12 16:09:26 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 04436a0000
2021.01.12 16:09:26 4: Studer485_XTM: ParseObj assigns value 234 to Input_voltage
2021.01.12 16:09:26 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404436a000045de, id 43, fCode 4,
request: id 43, read fc 4 i22, len 2, master device Studer485_XTM, reading Input_voltage (getUpdate), queued 0.85 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i22, len 2, value 436a0000
2021.01.12 16:09:26 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:27 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 5, sending 2b04001a000257c6 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate), queued 0.94 secs ago
2021.01.12 16:09:27 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 0400000000
2021.01.12 16:09:27 4: Studer485_XTM: ParseObj assigns value 0.00 to Input_power
2021.01.12 16:09:27 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404000000007046, id 43, fCode 4,
request: id 43, read fc 4 i26, len 2, master device Studer485_XTM, reading Input_power (getUpdate), queued 0.99 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i26, len 2, value 00000000
2021.01.12 16:09:27 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.090
2021.01.12 16:09:27 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 4, sending 2b04002a000257c9 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate), queued 1.08 secs ago
2021.01.12 16:09:27 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 04435d0000
2021.01.12 16:09:27 4: Studer485_XTM: ParseObj assigns value 221 to Output_voltage
2021.01.12 16:09:27 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b0404435d0000f410, id 43, fCode 4,
request: id 43, read fc 4 i42, len 2, master device Studer485_XTM, reading Output_voltage (getUpdate), queued 1.13 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i42, len 2, value 435d0000
2021.01.12 16:09:27 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:27 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 3, sending 2b04002e00021608 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate), queued 1.23 secs ago
2021.01.12 16:09:27 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043e980000
2021.01.12 16:09:27 4: Studer485_XTM: ParseObj assigns value 0.30 to Output_power
2021.01.12 16:09:27 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043e980000fc41, id 43, fCode 4,
request: id 43, read fc 4 i46, len 2, master device Studer485_XTM, reading Output_power (getUpdate), queued 1.27 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i46, len 2, value 3e980000
2021.01.12 16:09:27 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:27 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 2, sending 2b04003e000217cd via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate), queued 1.37 secs ago
2021.01.12 16:09:27 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f800000
2021.01.12 16:09:27 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_1
2021.01.12 16:09:27 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f8000007dba, id 43, fCode 4,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_1 (getUpdate), queued 1.42 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i62, len 2, value 3f800000
2021.01.12 16:09:27 4: ModbusLine: checkDelays found commDelay not over, set timer to try again in 0.091
2021.01.12 16:09:27 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 1, sending 2b040040000277d5 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate), queued 1.51 secs ago
2021.01.12 16:09:27 4: ModbusLine: ParseFrameStart (RTU) extracted id 43, fCode 4 and data 043f800000
2021.01.12 16:09:27 4: Studer485_XTM: ParseObj assigns value 1 to State_of_auxiliary_relay_2
2021.01.12 16:09:27 4: ModbusLine: HandleResponse done, current frame / read buffer: 2b04043f8000007dba, id 43, fCode 4,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading State_of_auxiliary_relay_2 (getUpdate), queued 1.56 secs ago, sent 0.05 secs ago,
response: id 43, fc 4 i64, len 2, value 3f800000
2021.01.12 16:09:28 4: Connection closed for WEB_192.168.10.21_51814: EOF
2021.01.12 16:09:28 4: Connection accepted from WEB_192.168.10.21_51815
2021.01.12 16:09:28 4: WEB_192.168.10.21_51815 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:28 4: WEB_192.168.10.21_51815 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464167;fmt=JSON&fw_id=34×tamp=1610464153325; BUFLEN:0
2021.01.12 16:09:30 4: Connection closed for WEB_192.168.10.21_51815: EOF
2021.01.12 16:09:30 4: Connection accepted from WEB_192.168.10.21_51816
2021.01.12 16:09:30 4: WEB_192.168.10.21_51816 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2021-01.log; BUFLEN:0
2021.01.12 16:09:30 4: WEB_192.168.10.21_51816 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1610464169;fmt=JSON&fw_id=35×tamp=1610464155324; BUFLEN:0
2021.01.12 16:09:31 4: Studer485_BSP: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:36.070, interval 5
2021.01.12 16:09:31 4: Studer485_BSP: GetUpdate will request Volt_Batt
2021.01.12 16:09:31 4: Studer485_BSP: GetUpdate will request SoC
2021.01.12 16:09:31 4: Studer485_BSP: GetUpdate will request Temp_Batt
2021.01.12 16:09:31 4: Studer485_BSP: GetUpdate will request Power
2021.01.12 16:09:31 4: Studer485_BSP: GetUpdate readList = i58 i0 i4 i6
2021.01.12 16:09:31 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate)
2021.01.12 16:09:31 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i4, len 2, master device Studer485_BSP, reading SoC (getUpdate)
2021.01.12 16:09:31 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i6, len 2, master device Studer485_BSP, reading Power (getUpdate)
2021.01.12 16:09:31 4: Studer485_BSP: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 93, read fc 4 i58, len 2, master device Studer485_BSP, reading Temp_Batt (getUpdate)
2021.01.12 16:09:31 4: ModbusLine: ProcessRequestQueue (V4.3.12 - 11.1.2021) qlen 4, sending 5d04000000027d57 via /dev/ttyUSB0@9600,8,E,1, read buffer empty,
request: id 93, read fc 4 i0, len 2, master device Studer485_BSP, reading Volt_Batt (getUpdate), queued 0.01 secs ago
2021.01.12 16:09:31 4: Studer485_VT: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:36.090, interval 5
2021.01.12 16:09:31 4: Studer485_VT: GetUpdate will request PV_Day_KWh
2021.01.12 16:09:31 4: Studer485_VT: GetUpdate will request Battery_cycle_phase
2021.01.12 16:09:31 4: Studer485_VT: GetUpdate will request PV_Power_KW
2021.01.12 16:09:31 4: Studer485_VT: GetUpdate readList = i8 i76 i14
2021.01.12 16:09:31 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i8, len 2, master device Studer485_VT, reading PV_Power_KW (getUpdate)
2021.01.12 16:09:31 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i14, len 2, master device Studer485_VT, reading PV_Day_KWh (getUpdate)
2021.01.12 16:09:31 4: Studer485_VT: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 53, read fc 4 i76, len 2, master device Studer485_VT, reading Battery_cycle_phase (getUpdate)
2021.01.12 16:09:31 4: Studer485_XTM: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 16:09:36.102, interval 5
2021.01.12 16:09:31 4: Studer485_XTM: GetUpdate will request Input_voltage
2021.01.12 16:09:31 4: Studer485_XTM: GetUpdate will request Input_power
2021.01.12 16:09:31 4: Studer485_XTM: GetUpdate will request Output_voltage
2021.01.12 16:09:31 4: Studer485_XTM: GetUpdate will request Output_power
2021.01.12 16:09:31 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_1
2021.01.12 16:09:31 4: Studer485_XTM: GetUpdate will request State_of_auxiliary_relay_2
2021.01.12 16:09:31 4: Studer485_XTM: GetUpdate readList = i64 i46 i62 i42 i22 i26
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Januar 2021, 17:00:05
Hallo Holle75,

die Meldungen sind normal. Das Modul bemerkt einfach nur dass das Frame noch nicht ganz angekommen ist und probiert es dann mit mehr Daten nochmal. Ich sollte das Level dieser Meldungen vermutlich von 4 auf 5 ändern :-)
Eine Kombination mehrerer Geräte mit unterschiedlichen Ids in ein gemeinsames Fhem-Gerät geht derzeit leider nur über Konstrukte wie ReadingsGroup.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 12 Januar 2021, 17:39:10
Danke Stefan. Ich mach mich jetzt mal an den Versuch einen Parameter zu schreiben :-)

Hast du noch eine Antwort darauf?
Zitat von: holle75 am 12 Januar 2021, 11:41:38
Gibt es eine Möglichkeit, zu überprüfen, ob weiterhin "defekte" Pakete gesendet werden?

Mit verbose 5 Meldungen komme ich im Wirrwarr nicht klar.


Möchte auf dem Testsystem alles so hinbiegen, dass es sauber läuft bevor ich mich dann an die neuen Busprobleme nach Portierung mache ;)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 12 Januar 2021, 19:21:05
Noch eine Frage: darf ich das

attr Studer485_XTM dev-combine 4
attr Studer485_XTM dev-defLen 2
attr Studer485_XTM dev-defPoll 1
attr Studer485_XTM dev-defShowGet 1
attr Studer485_XTM dev-defUnpack f>
attr Studer485_XTM dev-h-read 3
attr Studer485_XTM dev-h-write 16
attr Studer485_XTM dev-i-read 4


so verwenden? Also ohne "-i-" oder "-h-" nach dem "dev" und somit für alle gültig? Meckern tut fhem nicht, wenn ich es definiere, aber ich habe direkt so kein Beispiel gesehen. Oder muß da der "-*-" dazwischen?


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 17 Januar 2021, 12:53:12
Ich bin jetzt schon relativ weit gekommen.

Im Hauptsystem bekomme ich jetzt EINMAL

PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3747.

Dies passiert bei Schaltung eines DOIF. Auch bei mehrmaligem Schalten Warning nur einmal im Log

Fällt dir spontan etwas zu Zeile 3747 ein?


List vom geschalteten ModbusAttr
Internals:
   DEF        43 7
   FUUID      60030590-f33f-6bb4-37e3-d47f7da860281aef
   IODev      Eastron
   Interval   7
   MODBUSID   43
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485_XTM
   NOTIFYDEV  global
   NR         634
   NTFY_ORDER 50-Studer485_XTM
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   READ:
   READINGS:
     2021-01-17 13:08:59   AUX1_Transfer   kein_Transfer
     2021-01-17 13:08:59   AUX2_SoC90      ueber90
     2021-01-17 12:41:00   state           opened
   REMEMBER:
     lrecv      1610885339.73961
     lsend      1610885339.70257
   gotReadings:
     AUX2_SoC90 ueber90
   lastRead:
     i62        1610885339.59934
     i64        1610885339.74316
Attributes:
   dev-defLen 2
   dev-defPoll 1
   dev-defShowGet 1
   dev-defUnpack f>
   dev-h-read 3
   dev-h-write 16
   dev-i-read 4
   dev-timing-timeout 1
   event-min-interval .*:900
   event-on-change-reading .*
   event-on-update-reading .*
   group      Xtender
   obj-h6394-hint 24.6,25.8
   obj-h6394-max 26.0
   obj-h6394-min 24.0
   obj-h6394-reading Battery_priority_voltage_RAM
   obj-h6394-set 1
   obj-h6836-hint Transfer,kein_Transfer
   obj-h6836-map 1:Transfer, 0:kein_Transfer
   obj-h6836-reading AUX1_Transfer_RAM
   obj-h6836-set 1
   obj-h7064-hint 5.0,30.0,65.0
   obj-h7064-max 100
   obj-h7064-min 0
   obj-h7064-reading Dynamic_compensation_RAM
   obj-h7064-set 1
   obj-i62-map 0:Transfer, 1:kein_Transfer
   obj-i62-reading AUX1_Transfer
   obj-i64-map 0:ueber90, 1:unter90
   obj-i64-reading AUX2_SoC90


das DOIF
Internals:
   DEF        ([Studer485_BSP:SoC] < 93 and [?$SELF:cmd_nr] ne "4")
(set Studer485_XTM AUX1_Transfer_RAM Transfer)
(set Studer485_XTM Dynamic_compensation_RAM 5.0)
(set Studer485_XTM Battery_priority_voltage_RAM 25.8)
DOELSEIF ([Studer485_BSP:SoC] >= 93 and [?$SELF:cmd_nr] ne "1" and [?$SELF:cmd_nr] ne "4")
(set Studer485_XTM AUX1_Transfer_RAM kein_Transfer)
(set Studer485_XTM Dynamic_compensation_RAM 30.0)
(set Studer485_XTM Battery_priority_voltage_RAM 24.6)
DOELSEIF ([Studer485_BSP:SoC] >= 95 and [?$SELF:cmd_nr] ne "4" and [Studer485_VT:Battery_cycle_phase] eq "Floating")
(set Studer485_XTM AUX1_Transfer_RAM kein_Transfer)
(set Studer485_XTM Dynamic_compensation_RAM 30.0)
(set Studer485_XTM Battery_priority_voltage_RAM 24.6)
DOELSEIF ([?$SELF:state] ne "initialized")
(set Studer485_XTM AUX1_Transfer_RAM Transfer)
(set Studer485_XTM Dynamic_compensation_RAM 5.0)
(set Studer485_XTM Battery_priority_voltage_RAM 25.8)
   FUUID      5c86875c-f33f-6bb4-9bea-86f06a2e40318731
   MODEL      FHEM
   NAME       XtenderSetEnel72hDOIF
   NOTIFYDEV  Studer485_VT,Studer485_BSP,global
   NR         662
   NTFY_ORDER 50-XtenderSetEnel72hDOIF
   STATE      cmd_2
   TYPE       DOIF
   VERSION    23466 2021-01-03 17:14:46
   READINGS:
     2021-01-17 13:10:44   Device          Studer485_BSP
     2021-01-17 13:07:25   cmd             2.3
     2021-01-17 13:07:25   cmd_event       set_cmd_2
     2021-01-17 13:07:25   cmd_nr          2
     2021-01-17 13:07:25   cmd_seqnr       3
     2021-01-17 13:10:44   e_Studer485_BSP_SoC 99.4
     2021-01-17 12:56:08   e_Studer485_VT_Battery_cycle_phase Bulk
     2020-11-24 09:21:47   last_cmd        cmd_2
     2020-11-24 23:48:20   mode            enabled
     2021-01-17 13:07:25   state           cmd_2
     2021-01-17 13:07:25   wait_timer      no timer
   Regex:
     accu:
     cond:
       Studer485_BSP:
         0:
           SoC        ^Studer485_BSP$:^SoC:
         1:
           SoC        ^Studer485_BSP$:^SoC:
         2:
           SoC        ^Studer485_BSP$:^SoC:
         3:
       Studer485_VT:
         0:
         1:
         2:
           Battery_cycle_phase ^Studer485_VT$:^Battery_cycle_phase:
         3:
   attr:
     cmdState:
     wait:
       0:
         172800
         1
         1
       1:
         5
         1
         1
       2:
         5
         1
         1
       3:
         5
         1
         1
     waitdel:
   condition:
     0          ::ReadingValDoIf($hash,'Studer485_BSP','SoC') < 93 and ::ReadingValDoIf($hash,'XtenderSetEnel72hDOIF','cmd_nr') ne "4"
     1          ::ReadingValDoIf($hash,'Studer485_BSP','SoC') >= 93 and ::ReadingValDoIf($hash,'XtenderSetEnel72hDOIF','cmd_nr') ne "1" and ::ReadingValDoIf($hash,'XtenderSetEnel72hDOIF','cmd_nr') ne "4"
     2          ::ReadingValDoIf($hash,'Studer485_BSP','SoC') >= 95 and ::ReadingValDoIf($hash,'XtenderSetEnel72hDOIF','cmd_nr') ne "4" and ::ReadingValDoIf($hash,'Studer485_VT','Battery_cycle_phase') eq "Floating"
     3          ::ReadingValDoIf($hash,'XtenderSetEnel72hDOIF','state') ne "initialized"
   do:
     0:
       0          set Studer485_XTM AUX1_Transfer_RAM Transfer
       1          set Studer485_XTM Dynamic_compensation_RAM 5.0
       2          set Studer485_XTM Battery_priority_voltage_RAM 25.8
     1:
       0          set Studer485_XTM AUX1_Transfer_RAM kein_Transfer
       1          set Studer485_XTM Dynamic_compensation_RAM 30.0
       2          set Studer485_XTM Battery_priority_voltage_RAM 24.6
     2:
       0          set Studer485_XTM AUX1_Transfer_RAM kein_Transfer
       1          set Studer485_XTM Dynamic_compensation_RAM 30.0
       2          set Studer485_XTM Battery_priority_voltage_RAM 24.6
     3:
       0          set Studer485_XTM AUX1_Transfer_RAM Transfer
       1          set Studer485_XTM Dynamic_compensation_RAM 5.0
       2          set Studer485_XTM Battery_priority_voltage_RAM 25.8
     4:
   helper:
     DEVFILTER  ^global$|^Studer485_VT$|^Studer485_BSP$
     NOTIFYDEV  global|Studer485_VT|Studer485_BSP
     event      SoC: 99.4
     globalinit 1
     last_timer 0
     sleepdevice set_cmd_2
     sleepsubtimer -1
     sleeptimer -1
     timerdev   Studer485_BSP
     timerevent SoC: 99.4
     triggerDev Studer485_BSP
     timerevents:
       SoC: 99.4
     timereventsState:
       SoC: 99.4
     triggerEvents:
       SoC: 99.4
     triggerEventsState:
       SoC: 99.4
   internals:
   perlblock:
   readings:
     all         Studer485_BSP:SoC Studer485_VT:Battery_cycle_phase
   trigger:
   uiState:
   uiTable:
Attributes:
   devStateIcon disabled:general_aus@red:initialize initialize:general_an@yellow:disable initialized:general_an@yellow:disable cmd_1:general_an@green:disable cmd_2:general_an@yellow:disable cmd_3:general_an@yellow:disable cmd_4:general_an@blue:disable
   group      System_2
   room       System,Xtender
   sortby     1
   wait       172800,1,1:5,1,1:5,1,1:5,1,1
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dobiwan am 18 Januar 2021, 08:25:29
Hallo zusammen,

ich habe mir einen Smartfox Pro zugelegt. Der alte Reg 9Te konnte per json ausgelesen werden. Der Pro hat nun eine Modbus over TCP schnittstelle.
Leider habe ich noch nie ein Modul geschrieben. Ich kann mich zwar mit modbusattr mit dem Smartfox verbinden, aber, da das Modul die Daten nicht kennt, bekomme ich keine Readings. Nun die Frage an den Entwickler, könnte man den Smartfox als Solar und Energieregler hier integrieren.
Die Bschreibung des Modbus findet ihr im Anhang.

Vielen Dank
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 Januar 2021, 17:34:11
Hallo holle75,

dev-defPoll gilt für alle Objekttypen (holding register, input register, digital inputs und coils).
dev-h-defPoll gilt nur für input register.

Beide Arten sind korrekt.

Die Warnung kannst Du ignorieren, das hat nur etwas mit dem Logging zu tun.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 Januar 2021, 17:36:16
Hallo dobiwan,

Du musst nur die Objekte, die Du auslesen oder schreiben möchtest, per Attribut in ModbusAttr angeben. Dazu die Länge, den Namen des gewünschten Readings und einen unpack-Code für die richtige Kodierung.
Sollte kein größeres Problem sein.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 18 Januar 2021, 17:52:24
Vielen Dank Stefan. Dann läuft jetzt alles. Habe auch die Beispiele im Solar Unterforum verewigt. Damit wäre Studer jetzt dank deines Moduls auch abgedeckt.

lieb Gruß
H.

edit: Link zu den Beispielen im Solar Unterforum https://forum.fhem.de/index.php/topic,117826.0.html (https://forum.fhem.de/index.php/topic,117826.0.html)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dobiwan am 18 Januar 2021, 22:02:19
Zitat von: StefanStrobel am 18 Januar 2021, 17:36:16
Hallo dobiwan,

Du musst nur die Objekte, die Du auslesen oder schreiben möchtest, per Attribut in ModbusAttr angeben. Dazu die Länge, den Namen des gewünschten Readings und einen unpack-Code für die richtige Kodierung.
Sollte kein größeres Problem sein.

Gruss
   Stefan
Hallo Stefan,
Kannst du bitte ein Beispiel nennen.

Danke
Dirk
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 Januar 2021, 17:10:50
Zitat von: dobiwan am 18 Januar 2021, 22:02:19
Hallo Stefan,
Kannst du bitte ein Beispiel nennen.

Hallo Dirk,

wenn Du zwei Seiten zurückblätterst (Post 645) siehst Du die Erläuterungen, die ich vor ein paar Tagen für holle75 gepostet habe.
Wenn Du noch weiter zurückblätterst, findest Du viele weitere Beispiele.
Ansonsten habe ich das auch recht ausführlich im Wiki beschrieben: https://wiki.fhem.de/wiki/ModbusAttr. Da würde ich anfangen.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Bjoernar am 19 Januar 2021, 19:18:18
Hallo,

ich nutze schon seit ca. 5 Jahren ohne Probleme das Modbus Modul (dafür schon mal Danke!) nun bekomme ich aber immer wieder folgende Meldung in mein log:

Undefined subroutine &Modbus::DevIo_Disconnected called at ./FHEM/98_Modbus.pm line 3916.

Das ist an für sich ja nicht schlimm, jedoch hängt sich danach meine FHEM komplett weg.

Vielleicht kann mir ja jemand bei der Lösung helfen.

Danke und Gruß
Björnar
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 20 Januar 2021, 13:37:44
Ich muss mich hier leider auch nochmal dranhängen.
Heute hat mein Modbus leider nicht funktioniert, der Wechselrichter speist nicht ein.
Mit verbose 5 erhalte ich folgende Meldungen im Log:

2021.01.20 13:29:36.564 5: infini_modbus_physical: read buffer: 050104
2021.01.20 13:29:36.564 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2021.01.20 13:29:36.565 5: infini_modbus_physical: readFn did not see a valid RTU frame start yet, wait for more data
2021.01.20 13:29:36.580 5: infini_modbus_physical: read buffer: 050104003400023005
2021.01.20 13:29:36.581 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2021.01.20 13:29:36.581 4: infini_modbus_physical: ParseFrameStart (RTU) extracted id 5, fCode 1 and data 0400340002
2021.01.20 13:29:36.582 5: infini_modbus_physical: HandleRequest called from Modbus::ReadFn
2021.01.20 13:29:36.582 5: infini_modbus_physical: ParseRequest called from Modbus::HandleRequest
2021.01.20 13:29:36.583 4: infini_modbus_physical: RequestDone, Frame with checksum error, error: Invalid checksum 0230 received. Calculated 2a7e, current frame / read buffer: 050104003400023005, id 5, fCode 1, error: Invalid checksum 0230 received. Calculated 2a7e
2021.01.20 13:29:36.584 5: infini_modbus_physical: DropFrame - drop 0501040034000230 rest 05
2021.01.20 13:29:36.584 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2021.01.20 13:29:36.584 5: infini_modbus_physical: readFn did not see a valid RTU frame start yet, wait for more data


diese wiederholten sich sekündlich.
Mit einem Klick auf DEF und modify (ohne was an der DEF zu ändern), wechselten die Meldungen zu

2021.01.20 13:29:41.870 5: infini_modbus_physical: read buffer: 0104003400023005
2021.01.20 13:29:41.871 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2021.01.20 13:29:41.871 4: infini_modbus_physical: ParseFrameStart (RTU) extracted id 1, fCode 4 and data 00340002
2021.01.20 13:29:41.871 5: infini_modbus_physical: HandleRequest called from Modbus::ReadFn
2021.01.20 13:29:41.871 5: infini_modbus_physical: ParseRequest called from Modbus::HandleRequest
2021.01.20 13:29:41.872 5: infini_modbus_physical: CheckChecksum (called from Modbus::HandleRequest): 3005 is valid
2021.01.20 13:29:41.872 4: infini_modbus_physical: HandleRequest, current frame / read buffer: 0104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2
2021.01.20 13:29:41.872 5: infini_modbus_physical: GetLogHash returns hash for device infini_modbus_logical
2021.01.20 13:29:41.874 5: infini_modbus_physical: PackResponse called from Modbus::CreateResponse
2021.01.20 13:29:41.874 5: infini_modbus_physical: Send called from Modbus::CreateResponse
2021.01.20 13:29:41.875 5: SW: 010404442fc0008ebd
2021.01.20 13:29:41.876 4: infini_modbus_physical: RequestDone, current frame / read buffer: 0104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2,
response: id 1, fc 4 i52, len 2, value 442fc000
2021.01.20 13:29:41.876 5: infini_modbus_physical: DropFrame - drop 0104003400023005


und schon nimmt mein Wechselrichter die Arbeit auf.

Erinnerst du dich, dass ich sowas schonmal reportet hatte? Wenn nicht, such ich gleich mal nach der Stelle...
Bitteschön: hier ist der Link:
https://forum.fhem.de/index.php/topic,75638.msg1072886.html#msg1072886

Grüße,
Stephan

edit: Ich mach jetzt auch noch ein update - da ich die Situation aber leider nicht provozieren kann, wollte ich es trotzdem mal melden.
edit2: ich habe noch die "# $Id: 98_Modbus.pm unreleased development version StefanStrobel $" laufen. Soll ich besser die letzte Version aus dem Thread oder die aus dem update nehmen?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Januar 2021, 21:37:45
Hallo,

anbei eine neue Version zum Testen, in der das Problem von Bjoernar gelöst sein sollte. Das war ein Bug / fehlender Eintrag in der Import-Liste.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Januar 2021, 21:39:26
Hallo Stephan,

ich glaube ich erkenne die Ursache des Problems.
Um das vernünftig nachstellen zu können, würde es mir sehr helfen, wenn Du Deine komplette Konfiguration und einen größeren Ausschnitt aus dem Log mit verbose 5 für sowohl das logische, als auch das physische io-Device posten könntest.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 20 Januar 2021, 22:47:00
das logical device:
Internals:
   DEF        1 slave
   FUUID      5f9065ae-f33f-c595-0470-6439b4611fc27d0a
   IODev      infini_modbus_physical
   MODBUSID   1
   MODE       slave
   MODULEVERSION Modbus 4.3.12 - 11.1.2021
   NAME       infini_modbus_logical
   NOTIFYDEV  global
   NR         25
   NTFY_ORDER 50-infini_modbus_logical
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   READINGS:
     2021-01-20 13:58:48   state           opened
   REMEMBER:
     lsend      1611178999.68184
Attributes:
   obj-i52-len 2
   obj-i52-reading Stromzaehler:4_modbus
   obj-i52-unpack f>1
   room       Solar_PV
   verbose    5
   webCmd     active:inactive

das physical device:

Internals:
   DEF        /dev/fspmodbus@19200,8,N,1
   DeviceName /dev/fspmodbus@19200,8,N,1
   EXPECT     request
   FD         4
   FUUID      5f0aea1b-f33f-c595-6afd-f82bc0e7fc2ead7b
   LASTOPEN   1611147525.10464
   MODE       slave
   NAME       infini_modbus_physical
   NOTIFYDEV  global
   NR         22
   NTFY_ORDER 50-infini_modbus_physical
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   READ:
     BUFFER     
   READINGS:
     2021-01-20 13:58:45   state           opened
   REMEMBER:
     lid        1
     lname      infini_modbus_physical
     lrecv      1611179053.66588
     lsend      1611179053.68261
   REQUEST:
     ADR        52
     FCODE      4
     LEN        2
     MODBUSID   1
     PDU        4
     TYPE       i
   defptr:
     infini_modbus_logical 1
Attributes:
   verbose    5


das Logfile häng ich dir an. Reicht das?
Wenn du noch was anderes brauchst, meld dich.

Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 Januar 2021, 20:35:29
Hallo Stephan,

In Deinem Fall hat der Slave offenbar den Beginn eines Frames verpasst und aufgrund der häufigen Abfragen den Beginn nicht mehr gefunden.
Bitte teste doch mal die angehängte neue Version. Ich habe zwei Stellen erweitert, die in solchen Fällen jetzt dafür sorgen sollten, dass es sich schnell wieder synchronisiert.
Am besten mit dem Attribut skipGarbage 1 für das physische IO-Device.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Hollo am 21 Januar 2021, 21:43:36
Wenn ich das gerade richtig im Kopf habe, schreibt die Modbus RTU Spec eigentlich eine der folgenden Varianten vor:
1 Startbit, 8 Datenbits, Parität gerade oder ungerade, 1 Stoppbit
1 Startbit, 8 Datenbits, keine Parität, 2 Stoppbits

8N1 entspricht dementsprechend nicht der Spec; kann funktionieren, muss aber nicht.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 21 Januar 2021, 21:51:07
Zitat von: dobiwan am 18 Januar 2021, 22:02:19
Hallo Stefan,
Kannst du bitte ein Beispiel nennen.

Danke
Dirk

sag mal ein Beispiel, was du auslesen möchtest. Bin ja gerade "drin" im Thema.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dobiwan am 22 Januar 2021, 07:04:33
Zitat von: StefanStrobel am 18 Januar 2021, 17:36:16
Hallo dobiwan,

Du musst nur die Objekte, die Du auslesen oder schreiben möchtest, per Attribut in ModbusAttr angeben. Dazu die Länge, den Namen des gewünschten Readings und einen unpack-Code für die richtige Kodierung.
Sollte kein größeres Problem sein.

Gruss
   Stefan
Hallo Stefan,
ich habe jetzt die Beispiele und das Wiki angesehen. Leider bekomme ich keine Werte. Siehe Bild.
Die ID 211 verwende ich, weil ein Modbus Scan mit dem Handy das als offset/ID ergeben hat. Bin mir aber nicht sicher, dass das stimmt.

Gruß

Dirk
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Hollo am 22 Januar 2021, 09:58:07
Zitat von: dobiwan am 22 Januar 2021, 07:04:33
...Die ID 211 verwende ich, weil ein Modbus Scan mit dem Handy das als offset/ID ergeben hat. Bin mir aber nicht sicher, dass das stimmt...
Wenn du nur Modbus/TCP hast, gibt es keine ID; dafür hat das Device (der Modbus/TCP Server) ja eine IP und den Port.
Hast du es mal ohne diese 211 probiert?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dobiwan am 22 Januar 2021, 11:47:27
Zitat von: Hollo am 22 Januar 2021, 09:58:07
Wenn du nur Modbus/TCP hast, gibt es keine ID; dafür hat das Device (der Modbus/TCP Server) ja eine IP und den Port.
Hast du es mal ohne diese 211 probiert?
Das Modul verlangt eine ID beim anlegen. da habe ich schon mehrere ausprobiert.
ID ist aber in der CommandRef nicht näher beschrieben.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 22 Januar 2021, 15:20:57
Vielleicht verstehe ich dich auch falsch, aber die ID (bei meinem Solarlader beschreibt der Hersteller das auch als "slave address") von deinem Solarregler ist die Basis von allem was danach kommt. Gibts da nicht ein Manual oä. wo das beschrieben ist?

edit: oops, TCP, nicht seriell. TCP habe ich keine Ahnung.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 22 Januar 2021, 15:44:23
Zitat von: Hollo am 21 Januar 2021, 21:43:36
8N1 entspricht dementsprechend nicht der Spec; kann funktionieren, muss aber nicht.

Hat funktioniert, habs trotzdem geändert, bisher funktionierts immer noch. Danke für den Hinweis.

Zitat von: StefanStrobel am 21 Januar 2021, 20:35:29
Bitte teste doch mal die angehängte neue Version.

Hab die neue Version eingespielt, danke dafür.
Leider treten die Fehler nur sehr selten auf, ich werde es aber reporten, wenn es wieder passiert.


Grüße,
Stephan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Januar 2021, 16:27:48
Hallo dobiwan,

wie fragst Du die Readings denn ab?
Hast Du einen get-Befehl verwendet?
Oder möchtest Du dass die Readings automatisch zyklisch abgefragt werden, dann muss beim Define ein Intervall angegeben sein und das poll-Attribut entsprechend bei den Objekten.
In jedem Fall hilft es wenn Du verbose auf 5 setzt und dann einen Auszug aus dem Log postest. Dann sieht man was wirklich passiert und muss weniger raten :-)

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 22 Januar 2021, 16:46:44
Hallo @StefanStrobel

ich habe jetzt noch ab und zu diese PERL WARNINGS

2021.01.22 16:09:50 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3747.
2021.01.22 16:18:52 3: Eastron: Timeout waiting for a modbus response, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading AUX1_Transfer (getUpdate), queued 5.28 secs ago, sent 1.30 secs ago
2021.01.22 16:18:52 1: PERL WARNING: Use of uninitialized value $startByte in index at ./FHEM/98_Modbus.pm line 2102.
2021.01.22 16:18:52 3: Eastron: readfn got data while EXPECT was set to idle: 2b0404000000007046


Das Erste hatten wir ja schon. Meintest du, solle man ignorieren. Das Zweite bekomme ich nachdem ich das Attr skipGarbage 1 im Modbus Device gesetzt habe wenn mal ein Timeout kommt.

Ich bin ja einer dieser Log-Fanatiker die Warnings unästhetisch finden ;)

Kannst man/du da was machen?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Januar 2021, 20:58:22
Hallo holle75,

schau doch mal ob die Warnings bei Dir jetzt weg sind.

Gruss / Thanx
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 22 Januar 2021, 21:16:23
werde ich probieren. Braucht ein paar Stunden, da die Warnings nur bei bestimmten Aktionen/Konstellationen geworfen werden. Danke!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 23 Januar 2021, 00:07:30
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3771.

der kommt noch, wenn geschaltet wird.

Der Zweite ist bisher noch nicht wieder aufgetaucht. Allerdings gab es auch noch keinen Timeout.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Januar 2021, 16:33:42
Hallo Holle75,

das scheint nochmal ein Log an einer anderen Stelle zu sein.
Da dürfte jetzt auch keine Warnung mehr kommen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 23 Januar 2021, 16:45:20
Danke Stefan. Kein Warning mehr beim Schalten.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 23 Januar 2021, 19:46:32
jetzt habe ich doch noch ein Problem.
Der Xcom485 macht manchmal komplett zu. So alle 1-2 Tage.
Dann werden alle Anfragen an ihn mit einem

2021.01.23 19:39:31 3: Eastron: Timeout waiting for a modbus response, read buffer empty,
request: id 43, read fc 4 i64, len 2, master device Studer485_XTM, reading AUX2_SoC90 (getUpdate), queued 6.77 secs ago, sent 1.00 secs ago


quittiert und nur ein vom Strom Trennen lässt ihn danach wieder kommunizieren.

Kennt jemand so ein Problem und wie lässt es sich fixen?

Ich rufe alle 5-7 Sekunden 2-5 Readings ab. Das sollte ihn doch nicht in die Knie zwingen? ... und wenn sollte er doch nicht gleich komplett die Zusammenarbeit für die Zukunft verweigern?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Jewe am 24 Januar 2021, 14:01:37
Hallo,

versuche im Moment meine KWL über Modbus (ModbusAttr) an FHEM anzubinden. Nun habe ich das problem, dass ich die Register nicht rigchtig angezeigt bekomme.

So steht es z.B. in der Doku:
Nr.    Name                 Daten                                               
                                            Zugriff   Typ                          Werte   Beispiel
           1     ON/OFF Status  R/W       unsigned char         0 - 1      Off = 0, On = 1


So habe ich es versucht, aber dann bekomme ich nicht 0 oder 1 zurück, sondern bei 1 eine 0:
attr DOMEKT obj-h00000-format %.1o
attr DOMEKT obj-h00000-reading ON_OFF_Status


Irgendwie blicke ich es mit dem "sprintf — Gibt einen formatierten String zurück" nicht ??

Need Help, Jens
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 24 Januar 2021, 14:54:38
nimm doch map, ich habe in einem Register diverse Codes die ich mir so in Text übersetze :
attr 8000TL obj-h30211-map 336:Contact manufacturer, 337:Contact installer, 338:invalid, 887:none
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Jewe am 24 Januar 2021, 17:18:31
Zitat von: Wzut am 24 Januar 2021, 14:54:38
nimm doch map, ich habe in einem Register diverse Codes die ich mir so in Text übersetze :
attr 8000TL obj-h30211-map 336:Contact manufacturer, 337:Contact installer, 338:invalid, 887:none

Das hört sich gut an. Da benötige ich dann das format gar nicht mehr?
So habe ich es nun probiert :
attr DOMEKT obj-h00000-map 0:Off, 1:On
attr DOMEKT obj-h00000-reading ON_OFF_Status


Dann bekomme ich aber das als Reading zurück.
ON_OFF_Status      hex=31, string=1, s=, s>=, S=, S>=    2021-01-24 17:16:52

Das ist dann so wie als wenn ich gar nichts angebe.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 24 Januar 2021, 17:47:27
Zeig doch mal alles vom h00000, wie erwartest du denn das Register ?
Da scheint ja eine 1 drin zu stehen und wie in deiner Doku steht als Char.
Zeichencode 31 ist "1" , ergo müsstest du dann mappen
attr DOMEKT obj-h00000-map 30:Off, 31:On
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Jewe am 24 Januar 2021, 18:38:46
Zitat von: Wzut am 24 Januar 2021, 17:47:27
Zeichencode 31 ist "1" , ergo müsstest du dann mappen
attr DOMEKT obj-h00000-map 30:Off, 31:On

oh man, da hätte ich auch drauf kommen können, allerdings will es so auch nicht klappen...
Das Reading sieht immer noch gleich aus.

Das sind die ersten Zeilen des Devices:
defmod DOMEKT ModbusAttr 254 60 192.168.6.25:502 TCP
attr DOMEKT userattr dev-h-combine dev-h-defExpr dev-h-defLen dev-h-defPoll dev-h-defUnpack obj-h00000-map obj-h00000-reading obj-h00001-map obj-h00001-reading obj-h00002-map obj-h00002-reading obj-h00003-map obj-h00003-reading obj-h00004-map obj-h00004-reading obj-h00005-map obj-h00005-reading obj-h00900-map obj-h00900-reading obj-h00901-expr obj-h00901-format obj-h00901-reading obj-h00901-unpack obj-h00902-expr obj-h00902-format obj-h00902-reading obj-h00903-expr obj-h00903-format obj-h00903-reading obj-h00904-expr obj-h00904-format obj-h00904-reading obj-h00905-reading obj-h00907-reading obj-h00909-expr obj-h00909-format obj-h00909-reading obj-h00910-expr obj-h00910-format obj-h00910-reading obj-h00911-expr obj-h00911-format obj-h00911-reading obj-h00912-expr obj-h00912-format obj-h00912-reading obj-h00913-expr obj-h00913-format obj-h00913-reading obj-h00914-expr obj-h00914-format obj-h00914-reading obj-h00915-expr obj-h00915-format obj-h00915-reading obj-h00916-expr obj-h00916-format obj-h00916-reading obj-h00917-expr obj-h00917-format obj-h00917-reading obj-h00918-expr obj-h00918-format obj-h00918-reading obj-h00919-expr obj-h00919-format obj-h00919-reading obj-h00920-expr obj-h00920-format obj-h00920-reading obj-h00921-expr obj-h00921-format obj-h00921-reading obj-h00922-expr obj-h00922-format obj-h00922-reading obj-h00923-expr obj-h00923-format obj-h00923-reading obj-h00924-expr obj-h00924-format obj-h00924-reading obj-h00925-expr obj-h00925-format obj-h00925-reading obj-h00926-reading obj-h00928-reading obj-h00930-reading obj-h00932-reading obj-h00934-reading obj-h00936-reading obj-h00938-reading obj-h00940-reading obj-h00942-reading obj-h00944-expr obj-h00944-format obj-h00944-reading obj-h00945-expr obj-h00945-format obj-h00945-reading obj-h00946-expr obj-h00946-format obj-h00946-reading obj-h00947-format obj-h00947-reading
attr DOMEKT dev-h-combine 20
attr DOMEKT dev-h-defExpr ModbusLD_ScanFormat($hash, $val)
attr DOMEKT dev-h-defLen 1
attr DOMEKT dev-h-defPoll 1
attr DOMEKT dev-h-defUnpack n
attr DOMEKT devStateIcon opened:general_an@32CD32  disconnected:general_aus@red
attr DOMEKT icon vent_ventilation
attr DOMEKT obj-h00000-map 30:Off, 31:On
attr DOMEKT obj-h00000-reading ON_OFF_Status
attr DOMEKT obj-h00001-map 30:Scheduling, 31:AirQuality
attr DOMEKT obj-h00001-reading Auto-Modus_Kontrolle
attr DOMEKT obj-h00002-map 30:Off, 31:On
attr DOMEKT obj-h00002-reading ECO_Modus
attr DOMEKT obj-h00003-map 30:Off, 31:On
attr DOMEKT obj-h00003-reading AUTO_Modus
attr DOMEKT obj-h00004-map 30:Standby, 31:Abwesend, 32:Normal, 33:Intensive, 34:Boost, 35:Küche, 36:Feuerstätte, 37:Override, 38:Urlaub, 39:AirQuality, 3130:Off
attr DOMEKT obj-h00004-reading aktueller_Modus
attr DOMEKT obj-h00005-map 30:zuhause=, 31:Arbeitswoche, 32:Büro, 33:Praxis
attr DOMEKT obj-h00005-reading geplanter_Betriebs-Modus
attr DOMEKT obj-h00900-map 30:ElectricHeater=, 31:WaterCoolerHeater, 32:DXUunit
attr DOMEKT obj-h00900-reading Heizen-kühlen_config
attr DOMEKT obj-h00901-expr $val/10
attr DOMEKT obj-h00901-format %.1f °C
attr DOMEKT obj-h00901-reading Zuluft_Temperatur
attr DOMEKT obj-h00901-unpack n
attr DOMEKT obj-h00902-expr $val/10
attr DOMEKT obj-h00902-format %.1f °C
attr DOMEKT obj-h00902-reading Abluft_Temperatur
attr DOMEKT obj-h00903-expr $val/10
attr DOMEKT obj-h00903-format %.3s °C
attr DOMEKT obj-h00903-reading Aussenluft_Temperatur
attr DOMEKT obj-h00904-expr $val/10
attr DOMEKT obj-h00904-format %.1f °C
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Wzut am 24 Januar 2021, 19:16:48
Sorry, aber ich blick da bei dir nicht so ganz durch.
Laut deiner Doku png beginnen die Register Nr. bei 1 , du fängst aber mit 0 an, sicher das jetzt nicht alles um eins verschoben ist ?
Des weiteren sagt die Doku die Werte seien unsigend Char, du dekodierst aber per default n = unsigned short (16-bit)
IMHO wäre laut pack Doku C passender.
Egal ob deine Register nun falsch decodiert oder um eins verschoben sind was steht denn überhaupt in den Readings ?
Leider zeigt diesen Teil dein RAW Abschnitt nicht. BTW: RAW zu posten ist meist genauso sinnlos wie Abschnitte aus der fhem.cfg.
Nicht ohne Grund fordern wir immer wieder : "Leute, postet bitte lists eines Device"

Dann habe ich aber auch noch Blödsinn geschrieben -> 31 in HEX ist das Zeichen 1 , wenn du dezimal rechnest ist das natürlich 49 bzw 48 bei der 0
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Jewe am 24 Januar 2021, 20:44:24
Ja, die Register sind alle um 1 verschoben, warum auch immer....
Du hast auch recht bzgl. des List vom Device.
Es wird wohl besser sein, bei jedem Register die Dekodierung seperat mit einzutragen, als ein Default einzugeben. Das habe ich bei den ersten Werte geändert.

Beim reading ON_OFF_Status seht hex=30 bzw. string=0 drin, oder?
  2021-01-24 20:28:41   ON_OFF_Status   hex=30, string=0, s=, s>=, S=, S>=

Müsste dann nicht in das Mapping 0:Off, 1:On
Irgenwie passt das unpack vmtl. nicht.

Hier das List des Device:
Internals:
   DEF        254 60 192.168.6.25:502 TCP
   DeviceName 192.168.6.25:502
   EXPECT     idle
   FD         61
   FUUID      5fddac38-f33f-9f49-3535-7de81bc7260b2287
   INTERVAL   60
   IODev      DOMEKT
   LASTOPEN   1611516521.19787
   LeadingZeros 1
   MODBUSID   254
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DOMEKT
   NOTIFYDEV  global
   NR         708
   NTFY_ORDER 50-DOMEKT_2
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TRIGGERTIME 1611516581.06519
   TRIGGERTIME_FMT 2021-01-24 20:29:41
   TRIGGERTIME_SAVED
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1611516521.06519
   nextOpenDelay 60
   Helper:
     DBLOG:
       Abluft_Temperatur:
         myDbLog:
           TIME       1611516475.18081
           VALUE      21.6 °C
       Akt.Abluftstrom-Ventilator_Intensität:
         myDbLog:
           TIME       1611516475.18081
           VALUE      50 %
       Akt.Zuluftstrom-Ventilator_Intenstät:
         myDbLog:
           TIME       1611516475.18081
           VALUE      50 %
       Aussenluft_Temperatur:
         myDbLog:
           TIME       1611516475.18081
           VALUE      1 °C
       Auto-Modus_Kontrolle:
         myDbLog:
           TIME       1611516521.16389
           VALUE      hex=30, string=0, s=, s>=, S=, S>=
       Elektrischer_Heizer:
         myDbLog:
           TIME       1611516475.18081
           VALUE      0 %
       Heizleistung:
         myDbLog:
           TIME       1611516491.18142
           VALUE       W
       Luftklappen:
         myDbLog:
           TIME       1611516475.18081
           VALUE      100 %
       Panel_1_Feuchtigkeit:
         myDbLog:
           TIME       1611516473.30889
           VALUE      29 %
       Panel_1_Luftqualität:
         myDbLog:
           TIME       1611516473.30889
           VALUE      hex=30, string=0, s=, s>=, S=, S>=
       Panel_1_Temperatur:
         myDbLog:
           TIME       1611516473.30889
           VALUE      23.9 °C
       Wärmetauscher:
         myDbLog:
           TIME       1611516475.18081
           VALUE      100 %
       Wärmetauscher-Effizienz:
         myDbLog:
           TIME       1611516491.18142
           VALUE      76 %
       Wärmetauscher-Rückgewinnung:
         myDbLog:
           TIME       1611516491.18142
           VALUE      663 W
       Zuluft_Temperatur:
         myDbLog:
           TIME       1611516475.18081
           VALUE      17.2 °C
   OLDREADINGS:
   QUEUE:
     HASH(0xf2afbb8)
     HASH(0xc24a088)
     HASH(0xbe9b4d8)
   READ:
     BUFFER     
   READINGS:
     2021-01-24 20:28:11   AHU_Verbrauch,_Gesamt hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:11   AHU_Verbrauch,_Monat hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:11   AHU_Verbrauch,_Tag hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:41   AUTO_Modus      hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:27:55   Abluft_Temperatur 21.6 °C
     2021-01-24 20:27:55   Abluftdruck      Pa
     2021-01-24 20:27:55   Akt.Abluftstrom-Ventilator_Intensität 50 %
     2021-01-24 20:27:55   Akt.Zuluftstrom-Ventilator_Intenstät 50 %
     2021-01-24 20:27:55   Aussenluft_Temperatur 1 °C
     2021-01-24 20:28:41   Auto-Modus_Kontrolle hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:27:55   DX_Einheit      0 %
     2021-01-24 20:28:41   ECO_Modus       hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:27:55   Elektrischer_Heizer 0 %
     2021-01-24 20:28:11   Energie_sparen  100 %
     2021-01-24 20:28:11   Energieverbrauch 35 W
     2021-01-24 20:27:55   Filterverstopfung 13 %
     2021-01-24 20:27:55   Heizen-kühlen_config hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:11   Heizleistung     W
     2021-01-24 20:27:55   Luftklappen     100 %
     2021-01-24 20:28:41   ON_OFF_Status   hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:27:53   Panel_1_Feuchtigkeit 29 %
     2021-01-24 20:27:53   Panel_1_Luftqualität hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:27:53   Panel_1_Temperatur 23.9 °C
     2021-01-24 20:28:11   SPI_Specific_Power 288 W/(m3/h)
     2021-01-24 20:27:53   SPI_Specific_Power_pro_Tag 287 W/(m3/h)
     2021-01-24 20:27:55   Wasser_Heizer   0 %
     2021-01-24 20:27:55   Wasser_Kühler  0 %
     2021-01-24 20:27:55   Wasser_Temperatur 3276.8 °C
     2021-01-24 20:27:55   Wärmetauscher  100 %
     2021-01-24 20:28:11   Wärmetauscher-Effizienz 76 %
     2021-01-24 20:28:11   Wärmetauscher-Rückgewinnung 663 W
     2021-01-24 20:27:55   Zuluft_Temperatur 17.2 °C
     2021-01-24 20:27:55   Zuluftdruck      Pa
     2021-01-24 20:27:53   Zurückgew.Energie_Gesamt hex=35, string=5, s=, s>=, S=, S>=
     2021-01-24 20:27:53   Zurückgew.Energie_Monat hex=34, string=4, s=, s>=, S=, S>=
     2021-01-24 20:28:11   Zurückgew.Energie_Tag hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:11   Zus.Luftheizer Verbrauch_Gesamt hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:11   Zus.Luftheizer-Verbrauch_Monat hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:11   Zus.Luftheizer-Verbrauch_Tag hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:41   aktueller_Modus hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:27:55   aktueller_Zuluftstrom hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:41   geplanter_Betriebs-Modus hex=30, string=0, s=, s>=, S=, S>=
     2021-01-24 20:28:41   state           opened
   REMEMBER:
     lid        254
     lname      DOMEKT
     lrecv      1611516521.10232
     lsend      1611516521.08865
   defptr:
     DOMEKT     254
     DOMEKT_2   254
   gotReadings:
     AUTO_Modus hex=30, string=0, s=, s>=, S=, S>=
     Auto-Modus_Kontrolle hex=30, string=0, s=, s>=, S=, S>=
     ECO_Modus  hex=30, string=0, s=, s>=, S=, S>=
     ON_OFF_Status hex=30, string=0, s=, s>=, S=, S>=
     aktueller_Modus hex=30, string=0, s=, s>=, S=, S>=
     geplanter_Betriebs-Modus hex=30, string=0, s=, s>=, S=, S>=
   lastRead:
     h00000     1611516521.10475
     h00001     1610753399.83722
     h00005     1611479341.89412
     h00900     1611516475.03812
     h00905     1611479762.59982
     h00910     1611479281.74386
     h00915     1611479882.66739
     h00920     1611516491.06912
     h00921     1611426275.03925
     h00925     1611479521.8901
     h00930     1611478379.90058
     h00932     1610753930.73023
     h00936     1611478079.81206
     h00938     1610753931.86023
     h00940     1611516473.25581
     h00942     1611478349.51781
     h00944     1610753931.13487
     h00947     1611479822.64388
     h00949     1610753931.62
     h1         1611516521.10847
     h2         1611516521.11208
     h3         1611516521.1157
     h4         1611516521.11942
     h5         1611516521.12307
     h901       1611516475.04037
     h902       1611516475.04269
     h903       1611516475.04503
     h904       1611516475.04749
     h905       1611516475.0503
     h907       1610819889.60996
     h909       1611516475.05294
     h910       1611516475.0553
     h911       1611516475.05777
     h912       1611516475.0601
     h913       1611516475.06239
     h914       1611516475.06477
     h915       1611516475.06713
     h916       1611516475.06945
     h917       1611516475.0717
     h918       1611516475.07396
     h919       1611516475.0763
     h921       1611516491.07141
     h922       1611516491.07369
     h923       1611516491.07598
     h924       1611516491.07838
     h925       1611516491.08069
     h926       1611516491.08348
     h928       1611516491.08644
     h930       1611516491.08923
     h932       1611516491.09204
     h934       1611516491.09483
     h936       1611516491.09769
     h938       1611516491.10065
     h940       1611478079.82411
     h942       1611516473.25882
     h944       1611516473.26121
     h945       1611516473.2635
     h946       1611516473.26582
     h947       1611516473.26854
     h948       1610811538.65974
     h949       1610811538.66267
     h950       1610811538.66584
Attributes:
   dev-h-combine 20
   dev-h-defExpr ModbusLD_ScanFormat($hash, $val)
   dev-h-defLen 1
   dev-h-defPoll 1
   devStateIcon opened:general_an@32CD32  disconnected:general_aus@red
   icon       vent_ventilation
   obj-h00000-map 48:Off, 49:On
   obj-h00000-reading ON_OFF_Status
   obj-h00000-unpack C
   obj-h00001-map 30:Scheduling, 31:AirQuality
   obj-h00001-reading Auto-Modus_Kontrolle
   obj-h00001-unpack C
   obj-h00002-map 48:Off, 49:On
   obj-h00002-reading ECO_Modus
   obj-h00002-unpack C
   obj-h00003-map 48:Off, 49:On
   obj-h00003-reading AUTO_Modus
   obj-h00003-unpack C
   obj-h00004-map 30:Standby, 31:Abwesend, 32:Normal, 33:Intensive, 34:Boost, 35:Küche, 36:Feuerstätte, 37:Override, 38:Urlaub, 39:AirQuality, 3130:Off
   obj-h00004-reading aktueller_Modus
   obj-h00004-unpack C
   obj-h00005-map 30:zuhause=, 31:Arbeitswoche, 32:Büro, 33:Praxis
   obj-h00005-reading geplanter_Betriebs-Modus
   obj-h00005-unpack C
   obj-h00900-map 30:ElectricHeater=, 31:WaterCoolerHeater, 32:DXUunit
   obj-h00900-reading Heizen-kühlen_config
   obj-h00900-unpack C
   obj-h00901-expr $val/10
   obj-h00901-format %.1f °C
   obj-h00901-reading Zuluft_Temperatur
   obj-h00901-unpack n
   obj-h00902-expr $val/10
   obj-h00902-format %.1f °C
   obj-h00902-reading Abluft_Temperatur
   obj-h00903-expr $val/10
   obj-h00903-format %.3s °C
   obj-h00903-reading Aussenluft_Temperatur
   obj-h00904-expr $val/10
   obj-h00904-format %.1f °C
   obj-h00904-reading Wasser_Temperatur
   obj-h00905-reading aktueller_Zuluftstrom
   obj-h00909-expr $val/10
   obj-h00909-format %.1u %%
   obj-h00909-reading Akt.Zuluftstrom-Ventilator_Intenstät
   obj-h00910-expr $val/10
   obj-h00910-format %.1u %%
   obj-h00910-reading Akt.Abluftstrom-Ventilator_Intensität
   obj-h00911-expr $val/10
   obj-h00911-format %.1u %%
   obj-h00911-reading Wärmetauscher
   obj-h00912-expr $val/10
   obj-h00912-format %.1u %%
   obj-h00912-reading Elektrischer_Heizer
   obj-h00913-expr $val/10
   obj-h00913-format %.1u %%
   obj-h00913-reading Wasser_Heizer
   obj-h00914-expr $val/10
   obj-h00914-format %.1u %%
   obj-h00914-reading Wasser_Kühler
   obj-h00915-expr $val/10
   obj-h00915-format %.1u %%
   obj-h00915-reading DX_Einheit
   obj-h00916-expr $val
   obj-h00916-format %.0u %%
   obj-h00916-reading Filterverstopfung
   obj-h00917-expr $val
   obj-h00917-format %.0u %%
   obj-h00917-reading Luftklappen
   obj-h00918-expr $val
   obj-h00918-format %.0u Pa
   obj-h00918-reading Zuluftdruck
   obj-h00919-expr $val
   obj-h00919-format %.0u Pa
   obj-h00919-reading Abluftdruck
   obj-h00920-expr $val
   obj-h00920-format %.0u W
   obj-h00920-reading Energieverbrauch
   obj-h00921-expr $val
   obj-h00921-format %.0u W
   obj-h00921-reading Heizleistung
   obj-h00922-expr $val
   obj-h00922-format %.0u W
   obj-h00922-reading Wärmetauscher-Rückgewinnung
   obj-h00923-expr $val
   obj-h00923-format %.0u %%
   obj-h00923-reading Wärmetauscher-Effizienz
   obj-h00924-expr $val
   obj-h00924-format %.0u %%
   obj-h00924-reading Energie_sparen
   obj-h00925-expr $val
   obj-h00925-format %.0u W/(m3/h)
   obj-h00925-reading SPI_Specific_Power
   obj-h00926-reading AHU_Verbrauch,_Tag
   obj-h00928-reading AHU_Verbrauch,_Monat
   obj-h00930-reading AHU_Verbrauch,_Gesamt
   obj-h00932-reading Zus.Luftheizer-Verbrauch_Tag
   obj-h00934-reading Zus.Luftheizer-Verbrauch_Monat
   obj-h00936-reading Zus.Luftheizer Verbrauch_Gesamt
   obj-h00938-reading Zurückgew.Energie_Tag
   obj-h00940-reading Zurückgew.Energie_Monat
   obj-h00942-reading Zurückgew.Energie_Gesamt
   obj-h00944-expr $val
   obj-h00944-format %.0u W/(m3/h)
   obj-h00944-reading SPI_Specific_Power_pro_Tag
   obj-h00945-expr $val/10
   obj-h00945-format %.1f °C
   obj-h00945-reading Panel_1_Temperatur
   obj-h00946-expr $val/1
   obj-h00946-format %.0u %%
   obj-h00946-reading Panel_1_Feuchtigkeit
   obj-h00947-reading Panel_1_Luftqualität
   room       KWL
   userattr   dev-h-combine dev-h-defExpr dev-h-defLen dev-h-defPoll dev-h-defUnpack obj-h00000-map obj-h00000-reading obj-h00000-unpack obj-h00001-map obj-h00001-reading obj-h00001-unpack obj-h00002-map obj-h00002-reading obj-h00002-unpack obj-h00003-map obj-h00003-reading obj-h00003-unpack obj-h00004-map obj-h00004-reading obj-h00004-unpack obj-h00005-map obj-h00005-reading obj-h00005-unpack obj-h00900-map obj-h00900-reading obj-h00900-unpack obj-h00901-expr obj-h00901-format obj-h00901-reading obj-h00901-unpack obj-h00902-expr obj-h00902-format obj-h00902-reading obj-h00903-expr obj-h00903-format obj-h00903-reading obj-h00904-expr obj-h00904-format obj-h00904-reading obj-h00905-reading obj-h00907-reading obj-h00909-expr obj-h00909-format obj-h00909-reading obj-h00910-expr obj-h00910-format obj-h00910-reading obj-h00911-expr obj-h00911-format obj-h00911-reading obj-h00912-expr obj-h00912-format obj-h00912-reading obj-h00913-expr obj-h00913-format obj-h00913-reading obj-h00914-expr obj-h00914-format obj-h00914-reading obj-h00915-expr obj-h00915-format obj-h00915-reading obj-h00916-expr obj-h00916-format obj-h00916-reading obj-h00917-expr obj-h00917-format obj-h00917-reading obj-h00918-expr obj-h00918-format obj-h00918-reading obj-h00919-expr obj-h00919-format obj-h00919-reading obj-h00920-expr obj-h00920-format obj-h00920-reading obj-h00921-expr obj-h00921-format obj-h00921-reading obj-h00922-expr obj-h00922-format obj-h00922-reading obj-h00923-expr obj-h00923-format obj-h00923-reading obj-h00924-expr obj-h00924-format obj-h00924-reading obj-h00925-expr obj-h00925-format obj-h00925-reading obj-h00926-reading obj-h00928-reading obj-h00930-reading obj-h00932-reading obj-h00934-reading obj-h00936-reading obj-h00938-reading obj-h00940-reading obj-h00942-reading obj-h00944-expr obj-h00944-format obj-h00944-reading obj-h00945-expr obj-h00945-format obj-h00945-reading obj-h00946-expr obj-h00946-format obj-h00946-reading obj-h00947-format obj-h00947-reading
   verbose    0
   webCmd     reread
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 25 Januar 2021, 17:01:46
Hallo Jewe,

Hast Du

attr DOMEKT dev-h-defExpr ModbusLD_ScanFormat($hash, $val)


absichtlich in der Konfiguration gelassen?
Nicht dass Dir das ständig in die Quere kommt.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Jewe am 25 Januar 2021, 21:17:14
Hallo Stefan,
nein das habe ich nicht absichtlich drin gelassen. Nachdem ich das rausgelöscht habe funktioniert es auch so wie es soll. Nun bin ich ein ganzes Stück weiter.
Danke an Euch zwei für die Hilfe.

Jens
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dobiwan am 26 Januar 2021, 09:19:03
Zitat von: StefanStrobel am 22 Januar 2021, 16:27:48
Hallo dobiwan,

wie fragst Du die Readings denn ab?
Hast Du einen get-Befehl verwendet?
Oder möchtest Du dass die Readings automatisch zyklisch abgefragt werden, dann muss beim Define ein Intervall angegeben sein und das poll-Attribut entsprechend bei den Objekten.
In jedem Fall hilft es wenn Du verbose auf 5 setzt und dann einen Auszug aus dem Log postest. Dann sieht man was wirklich passiert und muss weniger raten :-)

Gruss
    Stefan

Hallo Stefan,

das poll hat jetzt geholfen und ich bekomme Werte angezeigt. Leider sind die Werte toital willkürlich. Da ist wohl noch etwas tuning nötig.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 26 Januar 2021, 15:26:02
Hallo,


RegisterNr  VarioTrack parameter description  Unit  Default  Min  Max  Format  Incremt
  18       Absorption voltage                  Vdc      57.6  37.9  68.2  FLOAT  0.1
  20       Force absorption phase              S           S              "SIGNAL"   
  22       Absorption duration                 min        120   5    510     FLOAT  5


ich möchte Register 20 Force absorption phase schreiben.
Aber wie setze ich ein "Signal" ab und was wäre das unpack??


attr Studer485_VT obj-h20-hint S
attr Studer485_VT obj-h20-reading Force_Absorption
attr Studer485_VT obj-h20-set 1
attr Studer485_VT obj-h20-poll 0
attr Studer485_VT obj-h20-unpack ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 26 Januar 2021, 17:15:38
blöd, ganz einfach. Man muß "1" senden.

attr Studer485_VT obj-h20-hint ForceNow
attr Studer485_VT obj-h20-reading Force_Absorption
attr Studer485_VT obj-h20-set 1
attr Studer485_VT obj-h20-poll 0
attr Studer485_VT obj-h20-map 1:ForceNow
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 Januar 2021, 16:20:19
Hallo,

ich habe gerade eine neue Version eingecheckt, in der die letzten Fixes drin sind.
Zudem war das Scanning defekt und sollte jetzt wieder gehen.
Ab morgen wird das per update verteilt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Februar 2021, 12:05:12
Hallo,

es gibt mal wieder was Neues zum Testen:
Ein neues Attribut ...-group ermöglich es die Zusammenfassung von Requests und die Reihenfolge der Auswertung bei Responses zu steuern.
Für SolarEdge, Fronius Wechselrichter und ähnliche Geräte, bei denen es einen Scale-Faktor oder Multiplyer gibt, sollte das eine Vereinfachung bringen.

Beispiel:

attr MyMaster obj-h100-reading Temp
attr MyMaster obj-h100-unpack f>
attr MyMaster obj-h100-len 2
attr MyMaster obj-h100-format %.2f
attr MyMaster obj-h100-poll 1
attr MyMaster obj-h100-expr ReadingsVal($name, 'TempMultiplyer', 1) * $val
attr MyMaster obj-h100-group 1-2

attr MyMaster obj-h102-reading TempMultiplyer
attr MyMaster obj-h102-unpack f>
attr MyMaster obj-h102-len 2
attr MyMaster obj-h102-poll 1
attr MyMaster obj-h102-group 1-1

attr MyMaster dev-h-combine 8


Durch die -group-Attribute wird zum Einen sichergestellt, das h100 und h102 immer gemeinsam gelesen werden.
Zudem wird durch -group 1-2 und group 1-1 festgelegt, dass zuerst das Reading für h102 und erst danach das Reading für h100 aktualisiert wird.

welche Rolle dev-h-combine dabei spielen soll, muss ich mir noch überlegen. Momentan muss combine mindestens genauso groß sein wie die größte definierte Gruppe. Es können bei combine aber auch Gruppen insgesamt kombiniert werden.
Ich könnte mir aber auch vorstellen, dass combine bei Gruppen einfach ignoriert wird.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dobiwan am 08 Februar 2021, 06:56:49
Hallo Stefan,

ich habe jetzt ein enigg mit den Werten die bekomme experimentiert. Leider bekomme ich es nicht hin, dass ich realistische Werte raus bekomme. Im Bild siehst du was ich eingestellt habe und in der Excel Datei ist die Definition des Smartfox. Die Werte die ich erwarte sin uint32 / uint 16.

Vielen Dank für die Hilfe im Voraus.

Dirk
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Februar 2021, 17:42:37
Hallo dobiwan,

leider sehe ich keine Einstellungen, nur das Bild mit den Internals und Readings.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dobiwan am 10 Februar 2021, 07:09:31
Zitat von: StefanStrobel am 08 Februar 2021, 17:42:37
Hallo dobiwan,

leider sehe ich keine Einstellungen, nur das Bild mit den Internals und Readings.

Gruss
   Stefan

Hier die Device Definitionen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Februar 2021, 20:32:38
Hallo dobiwan,

folgendes fällt mir an Deiner Konfiguration auf:


define Smartfox ModbusAttr 1 60 192.168.178.6:502 TCP
attr Smartfox obj-h41012-expr $val
attr Smartfox obj-h41012-len 2
attr Smartfox obj-h41012-poll 60
attr Smartfox obj-h41012-reading Day-Energy-from-Grid
attr Smartfox obj-h41012-unpack V


Die Zeile mit -expr $val ist überflüssig. Eine Perl Expression kann man verwenden, wenn man einen Wert umrechnen muss. Wenn Du nur $val als Ausdruck angibst, dann ist das so etwas wie $val = $val. Das kannst Du einfach weglassen.

die Zeile mit -poll 60 sollte -poll 1 sein. Besser wäre noch dev-h-defPoll 1. Damit wird für alle definierten Holding register festgelegt, dass sie im definierten Intervall abgefragt werden.
Das Intervall wird beim Define angegeben.

unpack V steht für "An unsigned long (32-bit) in "VAX" (little-endian) order". (siehe https://perldoc.perl.org/functions/pack). Das kann richtig sein, muss es aber nicht.
Es könnte auch "N" sein ("An unsigned long (32-bit) in "network" (big-endian) order.") oder es könnten die beiden Register vorher vertauscht werden müssen. dafür gäbe es dann das Attribut -revRegs (siehe Commandref). Das muss man einfach alles ausprobieren.


attr Smartfox obj-h41430-expr $val
attr Smartfox obj-h41430-len 1
attr Smartfox obj-h41430-poll 60
attr Smartfox obj-h41430-reading Battery-Load


Da hast Du keinen unpack-Code angegeben. Als Default wird dann n verwendet ("An unsigned short (16-bit) in "network" (big-endian) order.")
Es ist davon auszugehen, dass Dein Gerät entweder big-endian oder little-endian Formate verwendet. Sicher nicht beides gemischt.

Leider gibt es da keinen Standard und so muss man eben alles ausprobieren. Jeder Hersteller macht das auf seine Weise ...

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dobiwan am 11 Februar 2021, 07:21:56
Zitat von: StefanStrobel am 10 Februar 2021, 20:32:38
Hallo dobiwan,

folgendes fällt mir an Deiner Konfiguration auf:


define Smartfox ModbusAttr 1 60 192.168.178.6:502 TCP
attr Smartfox obj-h41012-expr $val
attr Smartfox obj-h41012-len 2
attr Smartfox obj-h41012-poll 60
attr Smartfox obj-h41012-reading Day-Energy-from-Grid
attr Smartfox obj-h41012-unpack V


Die Zeile mit -expr $val ist überflüssig. Eine Perl Expression kann man verwenden, wenn man einen Wert umrechnen muss. Wenn Du nur $val als Ausdruck angibst, dann ist das so etwas wie $val = $val. Das kannst Du einfach weglassen.

die Zeile mit -poll 60 sollte -poll 1 sein. Besser wäre noch dev-h-defPoll 1. Damit wird für alle definierten Holding register festgelegt, dass sie im definierten Intervall abgefragt werden.
Das Intervall wird beim Define angegeben.

unpack V steht für "An unsigned long (32-bit) in "VAX" (little-endian) order". (siehe https://perldoc.perl.org/functions/pack). Das kann richtig sein, muss es aber nicht.
Es könnte auch "N" sein ("An unsigned long (32-bit) in "network" (big-endian) order.") oder es könnten die beiden Register vorher vertauscht werden müssen. dafür gäbe es dann das Attribut -revRegs (siehe Commandref). Das muss man einfach alles ausprobieren.


attr Smartfox obj-h41430-expr $val
attr Smartfox obj-h41430-len 1
attr Smartfox obj-h41430-poll 60
attr Smartfox obj-h41430-reading Battery-Load


Da hast Du keinen unpack-Code angegeben. Als Default wird dann n verwendet ("An unsigned short (16-bit) in "network" (big-endian) order.")
Es ist davon auszugehen, dass Dein Gerät entweder big-endian oder little-endian Formate verwendet. Sicher nicht beides gemischt.

Leider gibt es da keinen Standard und so muss man eben alles ausprobieren. Jeder Hersteller macht das auf seine Weise ...

Gruss
   Stefan
Hallo Stefan,

Laut der Beschreibung des Modbus von Smartfox sind die Werte wie folgt definiert:

battery 1 SOC           int16   %               Battery-Load
battery 1 power   uint32   W               Battery-Power

Day Energy from grid   uint32   Wh     
Day Energy into grid   uint32   Wh
Day Energy Smartfox   uint32   Wh

Die Verbindung so:
offset   com   baud   parity   host   port
-1   COM4   9600   none   192.168.xxx.xxx   502

Also ich hatte unpack N auch schon probiert.

Im Bild siehst du den Vergleich der Werte vom Smartfox mit denen vom Fronius Smartmeter

Da ist irgendwie noch nicht der richtige Wert gefunden. Ich teste mal weiter, aber vielleicht ahst du noch eine Idee.

Vielen Dank erstmal bis hierher.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Februar 2021, 07:34:48
Manchmal zählen die Geräte ihre Adressen auch anders und beginnen mit Register 1 statt Register 0.
Du könntest also versuchen, die Adressen um 1 zu verschieben.
Falls der gesuchte Wert mit Kommas dargestellt wird, würde ich auch vermuten, dass man noch etwas umrechnen muss. Ein Integer-Wert kann ja keine Kommas haben. Manche Geräte speichern die Werte dann mit 10 multipliziert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: torte am 09 März 2021, 07:29:08
Hallo zusammen,

hab gestern meinen ersten Kontakt mit Modbus gehabt. Hab nun eine Frage, ich hab eine Alfen Wallbox
laut Doku des Herstellers werden einige Werte über die Slave Adresse 200 und andere Werte über die Slave Adresse 1 (oder 2, wenn man 2 Ladebuchsen) hat.
Ich hab das jetzt so gelöst das ich zwei Devices in FHEM hab, eins für die Slave Adresse 200 und eins  für die Slave Adresse 1. Ist
das so Ok oder macht man das besser irgendwie anders?

Danke!

Grüße
Torte
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 März 2021, 16:30:13
Hallo Torte,

so macht man das, alles richtig :-)

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: torte am 12 März 2021, 17:39:57
Hallo Stefan,

ich bekomme unpack Float64 Big Endian nicht hin.


2021.03.12 17:31:26 5: alfenVolt: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2021.03.12 17:31:26 4: alfenVolt: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 152, dlen 11 and potential data 0840e5f54000000000
2021.03.12 17:31:26 5: alfenVolt: HandleResponse called from ReadFn
2021.03.12 17:31:26 5: alfenVolt: ParseResponse called from HandleResponse
2021.03.12 17:31:26 5: alfenVolt: now parsing response data objects, master is alfenVolt relay is undefined
2021.03.12 17:31:26 4: alfenVolt: ParseObj called from HandleResponse with data hex 40e5f54000000000, type h, adr 374, valuesLen 4, op read
2021.03.12 17:31:26 5: alfenVolt: ParseObj unpacked 40e5f54000000000 with F> to 44970
2021.03.12 17:31:26 4: alfenVolt: ParseObj assigns value 44970 to RealEnergyDeliveredSum
2021.03.12 17:31:26 5: alfenVolt: ParseObj created 1 readings
2021.03.12 17:31:26 4: alfenVolt: HandleResponse done, current frame / read buffer: 00980000000b01030840e5f54000000000, id 1, fCode 3, tid 152,
request: id 1, read fc 3 h374, len 4, tid 152, master device alfenVolt, reading RealEnergyDeliveredSum (getUpdate for RealEnergyDeliveredSum len 4), queued 2.15 secs ago, sent 0.13 secs ago,
response: id 1, , fc 3, h . 374, len 4, values 40e5f54000000000
2021.03.12 17:31:26 5: alfenVolt: ResetExpect for HandleResponse from response to idle
2021.03.12 17:31:26 5: alfenVolt: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2021.03.12 17:31:26 5: alfenVolt: DropFrame called from ReadFn - drop 00980000000b01030840e5f54000000000
2021.03.12 17:31:26 5: alfenVolt: ProcessRequestQueue called from Fhem internal timer as queue:alfenVolt, qlen 2, request: request: id 1, read fc 3 h1201, len 5, tid 95, master device alfenVolt, reading Mode3State (getUpdate for Mode3State len 5), queued 2.15 secs ago
2021.03.12 17:31:26 5: alfenVolt: checkDelays clientSwitchDelay is not relevant
2021.03.12 17:31:26 5: alfenVolt: checkDelays busDelayRead, last activity on bus was 0.002 secs ago, required delay is 0
2021.03.12 17:31:26 5: alfenVolt: checkDelays commDelay, last communication with same device was 0.002 secs ago, required delay is 0.1



Das sollte das Register 374 mit einer 4er Länge sein. Hier kommt ein Wert 44970 raus sollte aber was mit ca.24244 (wH)  sein
Hab eigentlich schon alles durch. Hat das was mit dem 64 Bit und Perl zu tun?
Obwohl ein Unsigned64 funktioniert mit dem richtigen Wert bei mir.

Danke
Grüße
Torte
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: torte am 12 März 2021, 17:46:29
obwohl warte mal, ich glaub F> passt schon.
Das was ausgelesen wird ist der aktuelle Stand des Zählers und nicht die Differenz.
Wenn ich den alt Stand des Zählers abziehe ist es schlüssig.

Sorry

Grüße
Torte
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: straightshooter am 17 März 2021, 11:15:26
Hallo Stefan

Ich habe eine AP310 Lüftungsanlage an mein FHEM über ModbusAttr angebunden.
Bis jetzt hat alles seit Jahren wunderbar funktioniert.
Außer Updates von FHEM und Raspberry wurde an dem System nichts geändert.


Gefühlt seit dem letzten FHEM ModbusAttr Update habe ich nun Probleme mit den Werten, die ich von der Anlage empfange.
Alle Werte, die ich nun von der Anlage empfange, sind jetzt nur noch sinnlos: falsche Werte, viel zu große Werte, oder dann wieder "0".
Gleichzeitig sind manche dieser Werte auch nicht mehr konstant. Bei der Temperatur wechselt der falsche Wert immer wieder sehr extrem.
Es kommt aus der Anlage kein einziger richtiger Wert mehr zustande.

Genau kann ich nicht sagen, seit wann die Werte falsch sind, da ich eine Alarmmeldung nur generiere, wenn keine Werte empfangen werten.
In dem Fall werten zwar weiterhin die Werte empfangen, leider nur nicht mehr korrekt.


Die Lüftungsanlage stromlos zu setzen und neu zu starten hat nichts gebracht.
Genauso wie der Restart vom Raspberry.
Über eine firmenspezifische APP werden die Werte korrekt ausgegeben, also kann ich ein Anlagendefekt wohl ausschließen.

Wurde im letzten Update was geändert, was nun eine Anpassung von Einstellungen erfordert?
Anbei sende ich noch meine Einstellungen und ein Bild von den Ergebnissen:


Viele Grüße
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 März 2021, 17:33:26
Hallo,

Probier doch einfach mal auf eine frühere Version von 98_Modbus.pm zurückzugehen. Wenn es dann wieder geht, ist es offensichtlich ein Bug in der neuen Version. 98_ModbusAttr.pm selbst wird es eher nicht sein, da die eigentliche Funktionalität im Basismodul steckt.
Für die weitere Fehlersuche wäre ein Auszug aus dem Log mit verbose 5 sehr hilfreich.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: straightshooter am 17 März 2021, 18:25:41
OK ... hab gerade die beiden Dateien 98_Modbus.pm und 98_ModbusAttr durch ältere ersetzt.
Jetzt klappt alles wieder.

Danke schon mal für den Tip.
Mein Fehler war ich habe nur die 98_ModbusAttr ersetzt ... da hat es nicht funktioniert.

Hier noch die Log-Datei (Auszug aus GesamtLog nach Einspielen der fehlerhaften Dateien)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 März 2021, 20:36:36
Ok, wenn es mit der alten Version wieder funktioniert, dann läuft da irgend etwas mit der aktuellen Version schief.
Das sollte sich finden und korrigieren lassen.
Könntest Du auch noch die komplette Konfiguration für das Device sowie das Log mit der alten funktionierenden Version posten?

Gruss / vielen Dank
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: straightshooter am 17 März 2021, 21:31:42
So ... hier die zwei Dateien
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 März 2021, 22:52:36
Vielen Dank!
Ich glaube ich habe das Problem erkannt.
RevRegs scheint bei der letzten Umstrukturierung im Code kaputt gegangen zu sein.
Update kommt ...

Gruß / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 März 2021, 19:10:33
Hallo,

ich habe den Bug behoben und eine neue Version eingecheckt.
Ab morgen wird die dann per Update verteilt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: straightshooter am 19 März 2021, 09:33:20
Danke Stefan :-)

Nach dem heutigen Update läuft wieder alles korrekt. 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 21 März 2021, 12:29:00
Hallo Stefan - und mitleser,
ich habe mir einen Invertek Optidrive E3 Frequenzumrichter gekauft - und möchte diesen mit dem Modbus/RTU Modul in FHEM einbinden.
Aus den gegebenen Daten werde ich allerdings nicht richtig schlau.

Ich benutze den USB-RS485 Adapter von IN-Circuit und bin schon unsicher was die Stellungen der DIP-Switches angeht.
Ich habe es auch noch nicht geschafft eine vernünftige Antwort des FUs zu bekommen.

Ich habe zwar vor etwa 5 Jahren schon eine Modbus/RTU definition für meinen Wärmemengenzähler erstellt, diese läuft aber so problemlos das ich da nie wieder ran musste und ich über die Jahre natürlich die vorgehensweise vergessen habe.

Als Anhang mal die Seite der BA des FUs auf der es um den Modbus geht...

Fühlt sich jemand in der lage mir zu helfen - sodass ich z.b. mal ein Beispiel Reading habe?
Das wäre toll!

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 März 2021, 13:44:47
Hallo,

zuerst ein IO-Device auf den USB-Adapter:

define ModbusRS485E3 /dev/ttyUSBXY@115200

dabei muss natürlich das korrekte Device verwendet werden. Ich würde nach dem Einstecken einfach mit dmesg schauen, welches Device es ist.

Dann ein ModbusAttr:

define Frequenzumrichter ModbusAttr 1 60

unter der Annahme, dass die Modbus-Id 1 ist. Die kann vermutlich irgendwo eingestellt werden.
Alle 60 Sekunden soll abgefragt werden.


# alle definierten Objekte auch abfragen:
attr Frequenzumrichter dev-h-defPoll 1

# Register 22 (könnte auch 21 sein) ist laut Doku Drehzahl
attr Frequenzumrichter obj-h22-reading Drehzahl

# Wert ist *10 gespeichert
attr Frequenzumrichter obj-h22-expr $val / 10

# vermutlich ein unsigned long
attr Frequenzumrichter obj-h22-unpack n

# alle Debug logs anzeigen
attr Frequenzumrichter verbose 5
attr ModbusRS485E3 verbose 5


und dann mal testen und das Log posten.
Ich hab das nicht getestet, es kann also sein, dass gleich eine Fehlermeldung kommt ;-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 21 März 2021, 13:58:07
Ok Stefan, tausend Dank...
So bekomme ich zumindest schonmal eine Antwort vom Gerät..
Wobei es auf dem Schreibtisch steht, ein Motor ist noch nicht angeschlossen - deswegen kommt mir die Drehzahl von 30 komisch vor ;)


2021.03.21 13:56:01 1: Including fhem.cfg
2021.03.21 13:56:01 3: WEB: port 8083 opened
2021.03.21 13:56:02 2: eventTypes: loaded 17 lines from ./log/eventTypes.txt
2021.03.21 13:56:02 3: modbusRTU: defined as /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AG0KFFLW-if00-port0@115200
2021.03.21 13:56:02 3: Optidrive: defined master with id 1, protocol RTU and interval 5
2021.03.21 13:56:02 1: Including ./log/fhem.save
2021.03.21 13:56:02 4: Optidrive: GetIOHash (called from NotifyFn) did not find valid IODev hash key, calling SetIODev now
2021.03.21 13:56:02 5: Optidrive: SetIODev called from GetIOHash
2021.03.21 13:56:02 3: Optidrive: RegisterAtIODev called from SetIODev registers Optidrive at modbusRTU with id 1, MODE master, PROTOCOL RTU
2021.03.21 13:56:02 5: Optidrive: SetState called from SetIODev with opened sets state and STATE to opened
2021.03.21 13:56:02 3: Optidrive: Notify / Init: using modbusRTU for communication
2021.03.21 13:56:02 4: Optidrive: UpdateTimer called from NotifyFn with cmd start sets timer to call update function in 0.0 sec at 13:56:02.976, interval 5
2021.03.21 13:56:02 4: modbusRTU: Notify / Init: opening connection
2021.03.21 13:56:02 5: modbusRTU: open called from NotifyFn, busyOpenDev 0
2021.03.21 13:56:02 4: modbusRTU: open trying to open connection to /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AG0KFFLW-if00-port0@115200
2021.03.21 13:56:02 3: Opening modbusRTU device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AG0KFFLW-if00-port0
2021.03.21 13:56:03 3: Setting modbusRTU serial parameters to 115200,8,N,1
2021.03.21 13:56:03 3: modbusRTU device opened
2021.03.21 13:56:03 0: Featurelevel: 6
2021.03.21 13:56:03 0: Server started with 11 defined entities (fhem.pl:23904/2021-03-07 perl:5.028001 os:linux user:fhem pid:4049)
2021.03.21 13:56:04 4: Optidrive: GetUpdate (V4.4.01 - 18.3.2021) called from Fhem internal timer
2021.03.21 13:56:04 4: Optidrive: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 5.0 sec at 13:56:09.097, interval 5
2021.03.21 13:56:04 5: Optidrive: CreateUpdateList full object list: h22
2021.03.21 13:56:04 5: Optidrive: CreateUpdateList will request h22 len 1 Drehzahl
2021.03.21 13:56:04 4: Optidrive: CombineUpdateHash objHash keys before combine: h22
2021.03.21 13:56:04 5: Optidrive: CombineUpdateHash tries to combine read commands
2021.03.21 13:56:04 5: Optidrive: CombineUpdateHash keys are now h22
2021.03.21 13:56:04 4: Optidrive: GetUpdate will now create requests for h22 len 1 (Drehzahl)
2021.03.21 13:56:04 4: Optidrive: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h22, len 1, master device Optidrive, reading Drehzahl (getUpdate for Drehzahl len 1)
2021.03.21 13:56:04 5: modbusRTU: QueueRequest called from DoRequest with h22, qlen 0 from master Optidrive through io device modbusRTU
2021.03.21 13:56:04 5: modbusRTU: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2021.03.21 13:56:04 5: modbusRTU: ProcessRequestQueue called from Fhem internal timer as queue:modbusRTU, qlen 1, request: request: id 1, read fc 3 h22, len 1, master device Optidrive, reading Drehzahl (getUpdate for Drehzahl len 1), queued 0.00 secs ago
2021.03.21 13:56:04 5: modbusRTU: checkDelays sendDelay, last send to same device was never, required delay is 0.1
2021.03.21 13:56:04 5: modbusRTU: checkDelays commDelay, last communication with same device was never, required delay is 0.1
2021.03.21 13:56:04 5: modbusRTU: checkDelays busDelayRead, last activity on bus was never, required delay is 0
2021.03.21 13:56:04 5: modbusRTU: checkDelays clientSwitchDelay is not relevant
2021.03.21 13:56:04 4: modbusRTU: ProcessRequestQueue (V4.4.01 - 18.3.2021) qlen 1, sending 01030016000165ce via /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AG0KFFLW-if00-port0@115200, read buffer empty,
request: id 1, read fc 3 h22, len 1, master device Optidrive, reading Drehzahl (getUpdate for Drehzahl len 1), queued 0.01 secs ago
2021.03.21 13:56:04 5: modbusRTU: Send called from ProcessRequestQueue
2021.03.21 13:56:04 5: SW: 01030016000165ce
2021.03.21 13:56:04 5: modbusRTU: readFn buffer: 010302013579c3
2021.03.21 13:56:04 5: modbusRTU: ParseFrameStart called from ReadFn protocol RTU expecting id 1
2021.03.21 13:56:04 4: modbusRTU: ParseFrameStart (RTU, master) extracted id 1, fCode 3 and potential data 020135
2021.03.21 13:56:04 5: modbusRTU: HandleResponse called from ReadFn
2021.03.21 13:56:04 5: modbusRTU: ParseResponse called from HandleResponse
2021.03.21 13:56:04 5: modbusRTU: CheckChecksum (called from ParseResponse): 79c3 is valid
2021.03.21 13:56:04 5: modbusRTU: now parsing response data objects, master is Optidrive relay is undefined
2021.03.21 13:56:04 5: Optidrive: ParseDataString called from HandleResponse with data hex 0135, type h, adr 22, op read
2021.03.21 13:56:04 5: Optidrive: SplitDataString called from ParseDataString with data hex 0135, type h, adr 22, valuesLen 1, op read
2021.03.21 13:56:04 5: Optidrive: CreateDataObjects called from ParseDataString with objList h22
2021.03.21 13:56:04 5: Optidrive: CreateDataObjects sortedList h22
2021.03.21 13:56:04 5: Optidrive: CreateDataObjects unpacked 0135 with n to 309
2021.03.21 13:56:04 5: Optidrive: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val / 10 to 30.9
2021.03.21 13:56:04 4: Optidrive: CreateDataObjects assigns value 30.9 to Drehzahl
2021.03.21 13:56:04 5: Optidrive: ParseDataString created 1 readings
2021.03.21 13:56:04 4: modbusRTU: HandleResponse done, current frame / read buffer: 010302013579c3, id 1, fCode 3,
request: id 1, read fc 3 h22, len 1, master device Optidrive, reading Drehzahl (getUpdate for Drehzahl len 1), queued 0.03 secs ago, sent 0.02 secs ago,
response: id 1, fc 3, h22, len 1, values 0135
2021.03.21 13:56:04 5: modbusRTU: ResetExpect for HandleResponse from response to idle
2021.03.21 13:56:04 5: modbusRTU: DropFrame called from ReadFn - drop 010302013579c3
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 März 2021, 21:23:02
Ich würde das laut Doku auch eher als Soll-Frequenz interpretieren. Eine echte Drehzahl kann der FU ja nicht messen.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 23 März 2021, 11:51:37
Hallo zusammen,
ich habe da ein Phänomen, das ich nicht wirklich verstehe.

Ist-Situation:
2 Wechselrichter mit 100% identischer Konfiguration
  - gleiche Firmware
  - nur die IP-Adresse ist unterschiedlich
  - Die Netzwerkverbindung ist bis auf die letzte Netzwerkleitung identisch
  - Alle Werte werden bereits ausgelesen und als reading abgelegt, auch wenn sie noch auf 0.00 stehen

Der erste WR läuft mit dieser Konfiguration bereits seit fast 2 Jahren, der zweite ist jetzt hinzu gekommen.

Das Problem: beim neuen WR kommt es zu sehr häufigen connect/disconnect
Hier ein kurzes Beispiel, was minütlich auftritt.

2021.03.23 09:12:00.598 4: WR_2: HandleResponse done, current frame / read buffer: 00810000001347031031303333353935370000000000000000, id 71, fCode 3, tid 129,
request: id 71, read fc 3 h6, len 8, tid 129, master device WR_2, reading Inverter_article_number (getUpdate for Inverter_article_number len 8), queued 0.45 secs ago, sent 0.08 secs ago,
response: id 71, fc 3, h6, len 8, values 31303333353935370000000000000000
2021.03.23 09:12:00.598 5: WR_2: ResetExpect for HandleResponse from response to idle
2021.03.23 09:12:00.599 5: WR_2: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2021.03.23 09:12:00.599 5: WR_2: DropFrame called from ReadFn - drop 00810000001347031031303333353935370000000000000000
2021.03.23 09:12:00.610 3: 192.168.178.19:1502 disconnected, waiting to reappear (WR_2)
2021.03.23 09:12:00.617 5: HttpUtils url=http://192.168.178.19:1502/
2021.03.23 09:12:00.617 4: IP: 192.168.178.19 -> 192.168.178.19
2021.03.23 09:12:00.620 5: WR_2: ProcessRequestQueue called from Fhem internal timer as queue:WR_2, qlen 42, request: request: id 71, read fc 3 h14, len 8, tid 218, master device WR_2, reading Inverter_serial_number (getUpdate for Inverter_serial_number len 8), queued 0.47 secs ago
2021.03.23 09:12:00.620 5: WR_2: open called from ProcessRequestQueue, busyOpenDev 1
2021.03.23 09:12:00.620 5: WR_2: ProcessRequestQueue will return, device is disconnected, qlen 42, try again in 1 seconds
2021.03.23 09:12:00.620 5: WR_2: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2021.03.23 09:12:00.622 3: 192.168.178.19:1502 reappeared (WR_2)
2021.03.23 09:12:00.630 4: WR_2: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 59.4 sec at 09:13:00.000, interval 60
2021.03.23 09:12:04.101 5: WR_2: ProcessRequestQueue called from Fhem internal timer as queue:WR_2, qlen 42, request: request: id 71, read fc 3 h14, len 8, tid 218, master device WR_2, reading Inverter_serial_number (getUpdate for Inverter_serial_number len 8), queued 3.95 secs ago
2021.03.23 09:12:04.101 5: WR_2: checkDelays clientSwitchDelay is not relevant
2021.03.23 09:12:04.102 5: WR_2: checkDelays sendDelay, last send to same device was 3.577 secs ago, required delay is 0.1
2021.03.23 09:12:04.102 5: WR_2: checkDelays busDelayRead, last activity on bus was 3.507 secs ago, required delay is 0
2021.03.23 09:12:04.102 5: WR_2: checkDelays commDelay, last communication with same device was 3.507 secs ago, required delay is 0.1


Getestet habe ich bereits folgendes:

Beide WR aktiv -> WR_2 connect/disconnect
Nur WR-2 aktiv -> WR_2 connect/disconnect
WR_1 hat keine Probleme dieser Art


Nun mein Hilfegesuch, trotz verbose 5 kann ich nicht erkennen, warum es zu diesen reconnect kommt.
Was hätte ich für weitere Diagnosemöglichkeiten?

VG
    Christian

List:

Internals:
   DEF        71 60 192.168.178.19:1502 TCP
   DeviceName 192.168.178.19:1502
   EXPECT     idle
   FUUID      60192f14-f33f-61a8-570e-95a483c2a0f83537
   FVERSION   98_ModbusAttr.pm:0.239440/2021-03-13
   IODev      WR_2
   Interval   60
   MODBUSID   71
   MODE       master
   MODULEVERSION Modbus 4.4.01 - 18.3.2021
   NAME       WR_2
   NOTIFYDEV  global
   NR         517
   NTFY_ORDER 50-WR_2
   PROTOCOL   TCP
   STATE     
<TABLE>

<TR>
  <TH ALIGN="MIDDLE" WIDTH="20">Batterie <span style='color:#FF0000'>Entladen</span></TH>
  <TH ALIGN="MIDDLE" WIDTH="20">aktuell</TH>
  <TH ALIGN="RIGHT" WIDTH="20">Hausverbrauch</TH>
  <TH ALIGN="MIDDLE" WIDTH="20">Erträge</TH>
</TR>

<TR>
  <TD ALIGN="MIDDLE" WIDTH="20">
    Leistung:  0000 W<br>
    Temp.: 0.0 °C<br>
    Ladung total:  0 %<br>
    Ladung Res.: 0000 Wh
  </TD>

  <TD ALIGN="RIGHT" WIDTH="20">
    DC total: 00000 W<br>
    <br>
    <br>
    PV reserve: 00000 W
  </TD>

  <TD ALIGN="RIGHT" WIDTH="20">
    von PV: 00000 W <br>
    von Batterie: 00000 W<br>
    vom Netz: 00000 W<br>
    ins Haus: 00000 W<br>
    Netz: 00000 W
  </TD>

  <TD ALIGN="RIGHT" WIDTH="20">
    Tag: 00000 KWh <br>
    Monat: 00000 KWh<br>
    Jahr: 00000 KWh<br>
    Total: 00000 KWh
  </TD>
</TR>

</TABLE>

   TCPConn    1
   TYPE       ModbusAttr
   TimeAlignFmt 2021-03-22 00:00:00
   devioLoglevel 3
   nextOpenDelay 60
   Helper:
     DBLOG:
       Act_state_of_charge:
         LogDB:
           TIME       1616410337.29791
           VALUE      0.00
       Battery_Total_AC_Charge_Energy_(AC-sideToBattery):
         LogDB:
           TIME       1616410347.89315
           VALUE      0.00
       Battery_Total_AC_Charge_Energy_(gridToBattery):
         LogDB:
           TIME       1616411189.62477
           VALUE      0.00
       Battery_Total_AC_Discharge_Energy_(batteryToGrid):
         LogDB:
           TIME       1616410347.89315
           VALUE      0.00
       Battery_Total_DC_Charge_Energy_(DC-sideToBattery):
         LogDB:
           TIME       1616410347.89315
           VALUE      0.00
       Battery_Total_DC_Discharge_Energy_(DC-sideFromBattery):
         LogDB:
           TIME       1616410347.89315
           VALUE      0.00
       Battery_charge_current:
         LogDB:
           TIME       1616410335.183
           VALUE      0.00
       Battery_gross_capacity:
         LogDB:
           TIME       1616411125.59911
           VALUE      0
       Battery_temperature:
         LogDB:
           TIME       1616410337.29791
           VALUE      0.00
       Home_own_consumption_from_PV:
         LogDB:
           TIME       1616410327.68621
           VALUE      0.00
       Home_own_consumption_from_grid:
         LogDB:
           TIME       1616410326.61799
           VALUE      0.00
       Power_DC1:
         LogDB:
           TIME       1616410341.55821
           VALUE      0.00
       Power_DC2:
         LogDB:
           TIME       1616411182.82781
           VALUE      0.00
       Total_DC_PV_Energy_(sumOfAllPVInputs):
         LogDB:
           TIME       1616411189.62477
           VALUE      0.00
       Total_DC_Power:
         LogDB:
           TIME       1616410325.56464
           VALUE      0.00
       Total_DC_Power_(sumOfAllPVInputs):
         LogDB:
           TIME       1616411128.8626
           VALUE      0.00
       Total_DC_Power_Max:
         LogDB:
           TIME       1616411128.8626
           VALUE      0.00
       Total_PV_Power_reserve:
         LogDB:
           TIME       1616411128.8626
           VALUE      0.000
   READ:
     BUFFER     
   READINGS:
     2021-03-23 09:32:17   Act_state_of_charge 0.00
     2021-03-23 09:32:11   Active_power_Phase_1 0.00
     2021-03-23 09:32:12   Active_power_Phase_2 0.00
     2021-03-23 09:32:13   Active_power_Phase_3 0.00
     2021-03-23 09:32:19   Active_power_phase_1_(powermeter) 0.00
     2021-03-23 09:31:20   Active_power_phase_2_(powermeter) 0.00
     2021-03-23 09:30:21   Active_power_phase_3_(powermeter) 0.00
     2021-02-02 11:53:13   Actual_battery_charge_-minus_or_discharge_-plus_Power 0
     2021-03-23 09:32:16   Actual_battery_charge_-minus_or_discharge_-plus_current 0.00
     2021-02-02 11:53:13   Actual_battery_charge_usable_Power 0
     2021-03-23 09:32:10   Actual_cos_phi  1.00
     2021-03-23 09:32:19   Apparent_power_phase_1_(powermeter) 0.00
     2021-03-23 09:31:20   Apparent_power_phase_2_(powermeter) 0.00
     2021-03-23 09:11:21   Apparent_power_phase_3_(powermeter) 0.00
     2021-03-23 09:11:25   Battery_Maincontroller_(MC) 4653057
     2021-03-23 09:31:25   Battery_Manufacturer                 
     2021-03-23 09:30:26   Battery_Model_ID 0
     2021-03-23 09:30:26   Battery_Serial_Number 0
     2021-03-23 09:31:27   Battery_Total_AC_Charge_Energy_(AC-sideToBattery) 0.00
     2021-03-23 09:30:28   Battery_Total_AC_Charge_Energy_(gridToBattery) 0.00
     2021-03-23 09:31:27   Battery_Total_AC_Discharge_Energy_(batteryToGrid) 0.00
     2021-03-23 09:31:27   Battery_Total_DC_Charge_Energy_(DC-sideToBattery) 0.00
     2021-03-23 09:31:27   Battery_Total_DC_Discharge_Energy_(DC-sideFromBattery) 0.00
     2021-03-21 11:25:37   Battery_actual_SOC 0.00
     2021-03-23 09:32:15   Battery_charge_current 0.00
     2021-03-23 09:11:25   Battery_gross_capacity 0
     2021-03-23 09:32:17   Battery_ready_flag 0.00
     2021-03-23 09:32:17   Battery_state   NaN
     2021-03-23 09:32:17   Battery_temperature 0.00
     2021-03-23 09:32:18   Battery_voltage 0.00
     2021-03-23 09:32:18   Cos_phi_(powermeter) 0.00
     2021-03-23 09:31:21   Current_DC1     0.00
     2021-03-23 09:30:22   Current_DC2     0.00
     2021-03-23 09:11:22   Current_DC3     0.00
     2021-03-23 09:32:11   Current_Phase_1 0.00
     2021-03-23 09:32:12   Current_Phase_2 0.00
     2021-03-23 09:32:12   Current_Phase_3 0.00
     2021-03-23 09:32:18   Current_phase_1_(powermeter) 0.00
     2021-03-23 09:31:20   Current_phase_2_(powermeter) 0.00
     2021-03-23 09:30:21   Current_phase_3_(powermeter) 0.00
     2021-03-23 09:30:23   Daily_yield     0.00
     2021-03-23 09:32:18   Frequency_(powermeter) 0.00
     2021-03-23 09:11:26   Generation_Energy 0.00
     2021-03-23 09:32:11   Grid_frequency  50.02
     2021-03-23 09:32:08   Home_own_consumption_from_PV 0.00
     2021-03-23 09:32:06   Home_own_consumption_from_battery 0.00
     2021-03-23 09:32:07   Home_own_consumption_from_grid 0.00
     2021-03-23 09:31:24   IP-DNS1         192.168.178.1
     2021-03-23 09:30:25   IP-DNS2         
     2021-03-23 09:31:23   IP-address      192.168.178.19
     2021-03-23 09:11:24   IP-gateway      192.168.178.1
     2021-03-23 09:30:24   IP-subnetmask   255.255.255.0
     2021-03-21 11:25:38   Inverter_Generation_Power_(actual) 0.00
     2021-03-21 11:25:38   Inverter_Max_Power 6999
     2021-03-23 09:32:00   Inverter_article_number 10335957
     2021-03-23 09:11:23   Inverter_network_name WR-2
     2021-03-23 09:32:01   Inverter_serial_number 92092TIE0001U
     2021-03-23 09:32:04   Inverter_state  0
     2021-03-23 09:32:08   Isolation_resistance 0.00
     2021-03-23 09:30:23   Monthly_yield   0.00
     2021-03-23 09:32:15   Number_of_battery_cycles 0
     2021-03-23 09:32:16   PSSB_fuse_state 0.00
     2021-03-23 09:31:21   Power_DC1       0.00
     2021-03-23 09:30:22   Power_DC2       0.00
     2021-03-23 09:11:22   Power_DC3       0.00
     2021-03-23 09:11:27   Power_class     7.0
     2021-03-23 09:32:08   Power_limit_from_EVU 100.00
     2021-03-23 09:30:27   Productname     PLENTICORE plus
     2021-03-23 09:32:19   Reactive_power_phase_1_(powermeter) 0.00
     2021-03-23 09:31:20   Reactive_power_phase_2_(powermeter) 0.00
     2021-03-23 09:30:21   Reactive_power_phase_3_(powermeter) 0.00
     2021-03-23 09:32:03   Software-Version_IO-Controller_(IOC) 01.45
     2021-03-23 09:32:02   Software-Version_Maincontroller_(MC) 01.47
     2021-03-20 10:05:39   Solar_Calculation 5313
     2021-03-20 10:05:39   Solar_Calculation_fc0_07 0
     2021-03-20 10:05:39   Solar_Calculation_fc0_08 3707
     2021-03-20 10:05:39   Solar_Calculation_fc0_09 4770
     2021-03-20 10:05:39   Solar_Calculation_fc0_10 5313
     2021-03-20 10:05:39   Solar_Calculation_fc0_11 5269
     2021-03-20 10:05:39   Solar_Calculation_fc0_12 4722
     2021-03-20 10:05:39   Solar_Calculation_fc0_13 4203
     2021-03-20 10:05:39   Solar_Calculation_fc0_14 2735
     2021-03-20 10:05:39   Solar_Calculation_fc0_15 1625
     2021-03-20 10:05:39   Solar_Calculation_fc0_16 1004
     2021-03-20 10:05:39   Solar_Calculation_fc0_17 455
     2021-03-20 10:05:39   Solar_Calculation_fc0_18 0
     2021-03-20 10:05:39   Solar_Calculation_fc0_19 0
     2021-03-20 10:05:39   Solar_Calculation_fc0_4h 19507
     2021-03-20 10:05:39   Solar_Calculation_fc0_day 33803
     2021-03-20 10:05:39   Solar_Calculation_fc0_rest 25326
     2021-03-20 10:06:51   Solar_Calculation_fc1_07 0
     2021-03-20 10:06:51   Solar_Calculation_fc1_08 1029
     2021-03-20 10:06:51   Solar_Calculation_fc1_09 1176
     2021-03-20 10:06:51   Solar_Calculation_fc1_10 1377
     2021-03-20 10:06:51   Solar_Calculation_fc1_11 1509
     2021-03-20 10:06:51   Solar_Calculation_fc1_12 1421
     2021-03-20 10:06:51   Solar_Calculation_fc1_13 1501
     2021-03-20 10:06:51   Solar_Calculation_fc1_14 1092
     2021-03-20 10:06:51   Solar_Calculation_fc1_15 677
     2021-03-20 10:06:51   Solar_Calculation_fc1_16 468
     2021-03-20 10:06:51   Solar_Calculation_fc1_17 241
     2021-03-20 10:06:51   Solar_Calculation_fc1_18 0
     2021-03-20 10:06:51   Solar_Calculation_fc1_19 0
     2021-03-20 10:06:51   Solar_Calculation_fc1_day 10491
     2021-03-20 10:05:39   Solar_Cloud     29
     2021-03-20 10:05:39   Solar_Correction_Cloud 0.869
     2021-03-20 10:05:39   Solar_Correction_Rain 0.990
     2021-03-20 10:05:39   Solar_Correction_Temp 1.047
     2021-03-20 10:05:39   Solar_Rain      5
     2021-03-20 10:05:39   Solar_SolarRadiation 511
     2021-03-20 10:05:39   Solar_South     3162
     2021-03-20 10:05:39   Solar_Temp      12.9
     2021-03-20 10:05:39   Solar_West      2151
     2021-03-20 10:05:39   Solar_middayhigh_fc0 0
     2021-03-20 10:05:39   Solar_middayhigh_fc0_start 00:00
     2021-03-20 10:05:39   Solar_middayhigh_fc0_stop 00:00
     2021-03-20 10:06:51   Solar_middayhigh_fc1 0
     2021-03-20 10:06:51   Solar_middayhigh_fc1_start 00:00
     2021-03-20 10:06:51   Solar_middayhigh_fc1_stop 00:00
     2021-03-23 09:32:06   State_of_energy_manager 0
     2021-03-23 09:11:28   Total_AC_Energy_(AC-sideToGrid) 0.00
     2021-03-23 09:32:13   Total_AC_active_power 0.00
     2021-03-23 09:32:14   Total_AC_apparent_power 282.43
     2021-03-23 09:32:13   Total_AC_reactive_power 282.52
     2021-03-23 09:30:28   Total_DC_Energy_From_PV1 0.00
     2021-03-23 09:30:28   Total_DC_Energy_From_PV2 0.00
     2021-03-23 09:11:28   Total_DC_Energy_From_PV3 0.00
     2021-03-23 09:30:28   Total_DC_PV_Energy_(sumOfAllPVInputs) 0.00
     2021-03-23 09:32:06   Total_DC_Power  0.00
     2021-03-23 09:11:28   Total_DC_Power_(sumOfAllPVInputs) 0.00
     2021-03-22 12:05:28   Total_DC_Power_Max 0.00
     2021-03-22 12:05:28   Total_PV_Power_reserve 0.000
     2021-03-23 09:11:21   Total_active_power_(powermeter) 0.00
     2021-03-23 09:31:21   Total_apparent_power_(powermeter) 0.00
     2021-03-23 09:32:08   Total_home_consumption 0.00
     2021-03-23 09:32:07   Total_home_consumption_Battery 0.00
     2021-03-23 09:32:07   Total_home_consumption_Grid 0.00
     2021-03-23 09:32:07   Total_home_consumption_PV 0.00
     2021-03-23 09:32:09   Total_home_consumption_rate 0.00
     2021-03-23 09:11:21   Total_reactive_power_(powermeter) 0.00
     2021-03-23 09:30:23   Total_yield     0.00
     2021-03-23 09:30:22   Voltage_DC1     0.45
     2021-03-23 09:11:22   Voltage_DC2     0.34
     2021-03-23 09:31:22   Voltage_DC3     0.30
     2021-03-23 09:32:11   Voltage_Phase_1 229.76
     2021-03-23 09:32:12   Voltage_Phase_2 232.12
     2021-03-23 09:32:13   Voltage_Phase_3 229.44
     2021-03-23 09:32:19   Voltage_phase_1_(powermeter) 0.00
     2021-03-23 09:30:21   Voltage_phase_2_(powermeter) 0.00
     2021-03-23 09:11:21   Voltage_phase_3_(powermeter) 0.00
     2021-03-23 09:30:26   Work_Capacity   6999.00
     2021-03-23 09:32:10   Worktime        0.00
     2021-03-23 09:30:23   Yearly_yield    0.00
     2021-03-23 09:32:19   state           disabled
   REMEMBER:
     lid        71
     lname      WR_2
     lrecv      1616488339.75513
     lsend      1616488339.74035
   defptr:
     WR_2       71
   gotReadings:
     Active_power_phase_1_(powermeter) 0.00
     Apparent_power_phase_1_(powermeter) 0.00
     Reactive_power_phase_1_(powermeter) 0.00
     Voltage_phase_1_(powermeter) 0.00
   lastRead:
     h100       1616488326.12006
     h104       1616488326.12093
     h1046      1616488287.78218
     h1048      1616488287.78434
     h1050      1616488287.78607
     h1052      1616488287.78855
     h1054      1616488228.97616
     h1056      1616488228.9786
     h1058      1616488228.98103
     h106       1616488326.12187
     h1060      1616488228.98528
     h1062      1616487088.97169
     h1064      1616487088.97279
     h1066      1616487088.97376
     h108       1616488327.1991
     h110       1616488327.20043
     h112       1616488327.20154
     h114       1616488327.20248
     h116       1616488328.24349
     h118       1616488328.24432
     h120       1616488328.24512
     h122       1616488328.24591
     h124       1616488329.27625
     h14        1616488321.77761
     h144       1616488330.3231
     h150       1616488330.32514
     h152       1616488331.37614
     h154       1616488331.37732
     h156       1616488331.37844
     h158       1616488331.37959
     h160       1616488332.44311
     h162       1616488332.44412
     h164       1616488332.44512
     h166       1616488332.4461
     h168       1616488333.48945
     h170       1616488333.49069
     h172       1616488333.4916
     h174       1616488333.49255
     h178       1616488334.52683
     h190       1616488335.58818
     h194       1616488335.58963
     h200       1616488336.62759
     h202       1616488336.62867
     h208       1616488337.66852
     h210       1616488337.66968
     h212       1616488337.67077
     h214       1616488337.6719
     h216       1616488338.71376
     h218       1616488338.71464
     h220       1616488338.71549
     h222       1616488338.71629
     h224       1616488339.75766
     h226       1616488339.75889
     h228       1616488339.76065
     h230       1616488339.7624
     h232       1616488280.37323
     h234       1616488280.3741
     h236       1616488280.37495
     h238       1616488280.37576
     h240       1616488221.50375
     h242       1616488221.50458
     h244       1616488221.50538
     h246       1616488221.50618
     h248       1616487081.37468
     h250       1616487081.37671
     h252       1616487081.37806
     h254       1616487081.37948
     h256       1616488281.41824
     h258       1616488281.42009
     h260       1616488281.42193
     h266       1616488222.54855
     h268       1616488222.55064
     h270       1616488222.55296
     h276       1616487082.44093
     h278       1616487082.44176
     h280       1616487082.44258
     h286       1616488282.46975
     h320       1616488223.60816
     h322       1616488223.61021
     h324       1616488223.61248
     h326       1616488223.6148
     h38        1616488322.8418
     h384       1616487083.60593
     h420       1616488283.57242
     h428       1616488224.71344
     h436       1616487084.6396
     h446       1616488284.62456
     h454       1616488225.75017
     h46        1616488323.92955
     h512       1616487085.69222
     h515       1616487085.69376
     h517       1616488285.67987
     h525       1616488226.83885
     h527       1616488226.8401
     h529       1616488226.84135
     h56        1616488324.98067
     h577       1616487086.81091
     h6         1616488320.6097
     h768       1616488227.92624
     h800       1616487087.90866
Attributes:
   DbLogExclude .*
   DbLogInclude Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_Total.*,Battery_charge.*,Battery_gross.*,Battery_temperature,Home_own_consumption.*,Power_DC1,Power_DC2,Total_DC_Power.*,Total_DC_PV_Energy.*,Total_PV_Power_reserve,Solar_Calculation,Solar_Calculation_fc0_4h,Solar_Calculation_fc0_day,Solar_Calculation_fc0_rest,Solar_Correction.*,Solar_Cloud,Solar_East,Solar_East_Covered,Solar_Rain,Solar_SolarRadiation,Solar_South,Solar_Temp,Solar_West,Solar_middayhigh.*
   alias      WR_2
   comment    Version 2020.03.19 19:00
Kostal Plenticore Plus 7
   dev-h-combine 8
   dev-h-defFormat %.2f
   dev-h-defLen 2
   dev-h-defPoll 1
   dev-h-defRevRegs 1
   dev-h-defUnpack f>
   dev-type-STR-format %s
   dev-type-STR-len 8
   dev-type-STR-revRegs 0
   dev-type-STR-unpack a*
   disable    1
   event-on-change-reading Act_state_of_charge,Actual_battery_charge_.*,Battery_Total.*,Battery_charge.*,Battery_gross.*,Battery_temperature,Home_own_consumption.*,Power_DC1,Power_DC2,Total_DC_Power.*,Total_DC_PV_Energy.*,Total_PV_Power_reserve,Solar_.*
   group      PV Eigenverbrauch
   icon       sani_solar
   obj-h100-reading Total_DC_Power
   obj-h104-format %s
   obj-h104-reading State_of_energy_manager
   obj-h104-revRegs 0
   obj-h104-unpack N
   obj-h1046-reading Battery_Total_DC_Charge_Energy_(DC-sideToBattery)
   obj-h1048-reading Battery_Total_DC_Discharge_Energy_(DC-sideFromBattery)
   obj-h1050-reading Battery_Total_AC_Charge_Energy_(AC-sideToBattery)
   obj-h1052-reading Battery_Total_AC_Discharge_Energy_(batteryToGrid)
   obj-h1054-reading Battery_Total_AC_Charge_Energy_(gridToBattery)
   obj-h1056-reading Total_DC_PV_Energy_(sumOfAllPVInputs)
   obj-h1058-reading Total_DC_Energy_From_PV1
   obj-h106-reading Home_own_consumption_from_battery
   obj-h1060-reading Total_DC_Energy_From_PV2
   obj-h1062-reading Total_DC_Energy_From_PV3
   obj-h1064-reading Total_AC_Energy_(AC-sideToGrid)
   obj-h1066-reading Total_DC_Power_(sumOfAllPVInputs)
   obj-h108-reading Home_own_consumption_from_grid
   obj-h110-reading Total_home_consumption_Battery
   obj-h112-reading Total_home_consumption_Grid
   obj-h114-reading Total_home_consumption_PV
   obj-h116-reading Home_own_consumption_from_PV
   obj-h118-reading Total_home_consumption
   obj-h120-reading Isolation_resistance
   obj-h122-reading Power_limit_from_EVU
   obj-h124-reading Total_home_consumption_rate
   obj-h14-reading Inverter_serial_number
   obj-h14-type STR
   obj-h144-reading Worktime
   obj-h150-reading Actual_cos_phi
   obj-h152-reading Grid_frequency
   obj-h154-reading Current_Phase_1
   obj-h156-reading Active_power_Phase_1
   obj-h158-reading Voltage_Phase_1
   obj-h160-reading Current_Phase_2
   obj-h162-reading Active_power_Phase_2
   obj-h164-reading Voltage_Phase_2
   obj-h166-reading Current_Phase_3
   obj-h168-reading Active_power_Phase_3
   obj-h170-reading Voltage_Phase_3
   obj-h172-reading Total_AC_active_power
   obj-h174-reading Total_AC_reactive_power
   obj-h178-reading Total_AC_apparent_power
   obj-h190-reading Battery_charge_current
   obj-h194-format %.0f
   obj-h194-reading Number_of_battery_cycles
   obj-h200-reading Actual_battery_charge_-minus_or_discharge_-plus_current
   obj-h202-reading PSSB_fuse_state
   obj-h208-reading Battery_ready_flag
   obj-h210-reading Act_state_of_charge
   obj-h212-reading Battery_state
   obj-h214-reading Battery_temperature
   obj-h216-reading Battery_voltage
   obj-h218-reading Cos_phi_(powermeter)
   obj-h220-reading Frequency_(powermeter)
   obj-h222-reading Current_phase_1_(powermeter)
   obj-h224-reading Active_power_phase_1_(powermeter)
   obj-h226-reading Reactive_power_phase_1_(powermeter)
   obj-h228-reading Apparent_power_phase_1_(powermeter)
   obj-h230-reading Voltage_phase_1_(powermeter)
   obj-h232-reading Current_phase_2_(powermeter)
   obj-h234-reading Active_power_phase_2_(powermeter)
   obj-h236-reading Reactive_power_phase_2_(powermeter)
   obj-h238-reading Apparent_power_phase_2_(powermeter)
   obj-h240-reading Voltage_phase_2_(powermeter)
   obj-h242-reading Current_phase_3_(powermeter)
   obj-h244-reading Active_power_phase_3_(powermeter)
   obj-h246-reading Reactive_power_phase_3_(powermeter)
   obj-h248-reading Apparent_power_phase_3_(powermeter)
   obj-h250-reading Voltage_phase_3_(powermeter)
   obj-h252-reading Total_active_power_(powermeter)
   obj-h254-reading Total_reactive_power_(powermeter)
   obj-h256-reading Total_apparent_power_(powermeter)
   obj-h258-reading Current_DC1
   obj-h260-reading Power_DC1
   obj-h266-reading Voltage_DC1
   obj-h268-reading Current_DC2
   obj-h270-reading Power_DC2
   obj-h276-reading Voltage_DC2
   obj-h278-reading Current_DC3
   obj-h280-reading Power_DC3
   obj-h286-reading Voltage_DC3
   obj-h320-reading Total_yield
   obj-h322-reading Daily_yield
   obj-h324-reading Yearly_yield
   obj-h326-reading Monthly_yield
   obj-h38-reading Software-Version_Maincontroller_(MC)
   obj-h38-type STR
   obj-h384-len 16
   obj-h384-reading Inverter_network_name
   obj-h384-type STR
   obj-h420-reading IP-address
   obj-h420-type STR
   obj-h428-reading IP-subnetmask
   obj-h428-type STR
   obj-h436-reading IP-gateway
   obj-h436-type STR
   obj-h446-reading IP-DNS1
   obj-h446-type STR
   obj-h454-reading IP-DNS2
   obj-h454-type STR
   obj-h46-reading Software-Version_IO-Controller_(IOC)
   obj-h46-type STR
   obj-h512-format %s
   obj-h512-reading Battery_gross_capacity
   obj-h512-unpack N
   obj-h514-len 1
   obj-h514-reading Battery_actual_SOC
   obj-h515-format %s
   obj-h515-reading Battery_Maincontroller_(MC)
   obj-h515-unpack N
   obj-h517-reading Battery_Manufacturer
   obj-h517-type STR
   obj-h525-format %s
   obj-h525-reading Battery_Model_ID
   obj-h525-unpack N
   obj-h527-format %s
   obj-h527-reading Battery_Serial_Number
   obj-h527-unpack N
   obj-h529-len 4
   obj-h529-reading Work_Capacity
   obj-h529-unpack N
   obj-h531-format %.0f
   obj-h531-reading Inverter_Max_Power
   obj-h531-unpack N
   obj-h535-revRegs 0
   obj-h535-unpack n
   obj-h551-revRegs 0
   obj-h559-revRegs 0
   obj-h56-format %.0f
   obj-h56-reading Inverter_state
   obj-h56-unpack N
   obj-h575-len 1
   obj-h575-reading Inverter_Generation_Power_(actual)
   obj-h577-len 2
   obj-h577-reading Generation_Energy
   obj-h577-unpack N
   obj-h578-reading Total_energy
   obj-h582-reading Actual_battery_charge-discharge_power
   obj-h586-format %s
   obj-h586-reading Battery_Firmware
   obj-h586-unpack N
   obj-h588-format %s
   obj-h588-len 1
   obj-h588-reading Battery_Type
   obj-h588-unpack N
   obj-h6-reading Inverter_article_number
   obj-h6-type STR
   obj-h768-len 32
   obj-h768-reading Productname
   obj-h768-type STR
   obj-h800-len 32
   obj-h800-reading Power_class
   obj-h800-type STR
   room       Strom->Photovoltaik
   sortby     211
   stateFormat {sprintf("
<TABLE>

<TR>
  <TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Batterie %s</TH>
  <TH ALIGN=\"MIDDLE\" WIDTH=\"20\">aktuell</TH>
  <TH ALIGN=\"RIGHT\" WIDTH=\"20\">Hausverbrauch</TH>
  <TH ALIGN=\"MIDDLE\" WIDTH=\"20\">Erträge</TH>
</TR>

<TR>
  <TD ALIGN=\"MIDDLE\" WIDTH=\"20\">
    Leistung:  %04d W<br>
    Temp.: %02.1f °C<br>
    Ladung total: %2d %%<br>
    Ladung Res.: %04d Wh
  </TD>

  <TD ALIGN=\"RIGHT\" WIDTH=\"20\">
    DC total: %05d W<br>
    <br>
    <br>
    PV reserve: %05d W
  </TD>

  <TD ALIGN=\"RIGHT\" WIDTH=\"20\">
    von PV: %05d W <br>
    von Batterie: %05d W<br>
    vom Netz: %05d W<br>
    ins Haus: %05d W<br>
    Netz: %05d W
  </TD>

  <TD ALIGN=\"RIGHT\" WIDTH=\"20\">
    Tag: %05d KWh <br>
    Monat: %05d KWh<br>
    Jahr: %05d KWh<br>
    Total: %05d KWh
  </TD>
</TR>

</TABLE>
" ,
(ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0) lt 0) ? "<span style='color:#00FF00'>Laden</span>":"<span style='color:#FF0000'>Entladen</span>" ,

ReadingsVal($name,"Actual_battery_charge_-minus_or_discharge_-plus_Power",0),
ReadingsVal($name,"Battery_temperature",0) ,
ReadingsVal($name,"Act_state_of_charge",0) ,
ReadingsVal($name,"Actual_battery_charge_usable_Power",0) ,

ReadingsVal($name,"Total_DC_Power_(sumOfAllPVInputs)",0),
ReadingsVal($name,"Total_PV_Power_reserve",0),

ReadingsVal($name,"Home_own_consumption_from_PV",0) ,
ReadingsVal($name,"Home_own_consumption_from_battery",0) ,
ReadingsVal($name,"Home_own_consumption_from_grid",0),
ReadingsVal($name,"Home_own_consumption_from_PV",0) +ReadingsVal($name,"Home_own_consumption_from_battery",0)+ReadingsVal($name,"Home_own_consumption_from_grid",0),
ReadingsVal($name,"Total_active_power_(powermeter)",0),

round(ReadingsVal($name,"Daily_yield",0)/1000 ,0),
round(ReadingsVal($name,"Monthly_yield",0)/1000 ,0) ,
round(ReadingsVal($name,"Yearly_yield",0)/1000 ,0) ,
round(ReadingsVal($name,"Total_yield",0)/1000 ,0)
)}
   userReadings Total_PV_Power_reserve:Total_DC_Power.* {my $reserve = ReadingsVal($NAME,"Total_DC_Power_(sumOfAllPVInputs)","0") * 0.90 - ReadingsVal($NAME,"Home_own_consumption_from_PV","0");; ($reserve lt 0)?0:round($reserve,3)  },

Total_DC_Power_Max:Total_DC_Power.* { ReadingsVal($NAME,"Total_DC_Power_(sumOfAllPVInputs)","0") }

   verbose    5
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 23 März 2021, 16:22:45
Und nochmal hallo.

In einem ModBus Device habe ich readings mit "()" im Namen, so wie sie beim Geräte hersteller verwendet werde.

Nun wollte ich das in einem userReadings auch so verwenden, jedoch werden wohl die Klammern nicht akzeptiert.
Ein Escapen mit "\(" hat auch nicht funktioniert.

klappt nicht:
SW_1_Total_DC_Power_(sumOfAllPVInputs):Total_DC_Power.* {ReadingsVal($NAME,"Total_DC_Power_(sumOfAllPVInputs)",0)+ReadingsVal("WR_2","Total_DC_Power_(sumOfAllPVInputs)",0)}

geht auch nicht:
SW_1_Total_DC_Power_\(sumOfAllPVInputs\):Total_DC_Power.* {ReadingsVal($NAME,"Total_DC_Power_(sumOfAllPVInputs)",0)+ReadingsVal("WR_2","Total_DC_Power_(sumOfAllPVInputs)",0)}

Funktioniert:
SW_1_Total_DC_Power_sumOfAllPVInputs:Total_DC_Power.* {ReadingsVal($NAME,"Total_DC_Power_(sumOfAllPVInputs)",0)+ReadingsVal("WR_2","Total_DC_Power_(sumOfAllPVInputs)",0)}


VG
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 März 2021, 17:54:59
Hallo Christian,

das mit den Klammern ist klar: die sind nicht erlaubt.
Im Modbus-Modul habe ich es vor langer Zeit versäumt, die erlaubten Zeichen zu prüfen und wenn ich das jetzt nachträglich mache, dann gibt es viele Beschwerden.
Aber die Konsequenz ist eben dass man per Attribut auch unerlaubte Readng-Namen definieren kann.
(siehe https://wiki.fhem.de/wiki/DevelopmentModuleAPI#goodReadingName)

Auf die Disconnects hat das aber meiner Meinung nach keinen Einfluss.
Probier doch mal mit einem anderen Tool per ModbusTCP etwas von dem Device zu lesen und ob dort auch die Verbindung getrennt wird.
Es kann schon sein, dass die Firmware oder Konfiguration doch nicht ganz identisch ist und das Device daher nach einer Minute die TCP-Verbindung schließt. Das ist eigentlich auch gar nicht schlimm. Fhem baut sie dann ja wieder auf. Um die störenden Meldungen wegzubekommen kann man das Attribut silentReconnect setzen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 24 März 2021, 18:05:17
Hallo Stefan

Zitat von: StefanStrobel am 24 März 2021, 17:54:59
das mit den Klammern ist klar: die sind nicht erlaubt.
Im Modbus-Modul habe ich es vor langer Zeit versäumt, die erlaubten Zeichen zu prüfen und wenn ich das jetzt nachträglich mache, dann gibt es viele Beschwerden.
Aber die Konsequenz ist eben dass man per Attribut auch unerlaubte Readng-Namen definieren kann.
(siehe https://wiki.fhem.de/wiki/DevelopmentModuleAPI#goodReadingName)
Okay, dann bereinige ich die reading namen :-)


Zitat
Probier doch mal mit einem anderen Tool per ModbusTCP etwas von dem Device zu lesen und ob dort auch die Verbindung getrennt wird.
Es kann schon sein, dass die Firmware oder Konfiguration doch nicht ganz identisch ist und das Device daher nach einer Minute die TCP-Verbindung schließt. Das ist eigentlich auch gar nicht schlimm. Fhem baut sie dann ja wieder auf. Um die störenden Meldungen wegzubekommen kann man das Attribut silentReconnect setzen.
Welche Tools gibt es denn da?

Ich habe zwei Wechselrichter, bei denen ich die FW aus dem selben File aktualisiert habe.
Am zweiten WR sind nur noch keine Strings angeschlossen und ich habe gestern noch gesehen, dass er aus "Aus" gegangen ist. Trotzdem antwortet die LAN Schnittstelle.

Ich schau dann mal, wie es ist, wenn er komplett Installiert ist. Sollte es dann immer noch so sein teste ich mal das Attribut silentReconnect und melde mich wieder.

Aufgefallen ist es mir nur, weil ich ein stateFormat mit HTML habe und im Moment wechselt ständig connect/disconnect , was das stateFormat dann überschreibt.
Das Device ist jetzt auf disable 1 und es flackert nicht mehr :-)

VG
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 30 März 2021, 21:12:10
Hallo, ich habe heute ein Update gemacht und bekomme das log file voll geschrieben:
Use of uninitialized value $val in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3467

Bin ich alleine?

Danke euch schon mal vorab!

Liegt nicht an diesem Modul, sondern am Rasenmäher dessen Status über modbus übertragen wird. Sorry für die Falschmeldung.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mastodon am 18 April 2021, 19:29:54
Hallo,

ich habe vor einigen Tagen seit langer Zeit mal wieder ein FHEM-Update durchgeführt und sehe nun Probleme mit meinem ModbusAttr-Device (Solarlader). Ausgelesen wird ein Epever MPPT Gerät. Vor dem Update hat das problemlos funktioniert. Nun wird allerdings ein einzelner Wert nicht mehr automatisch (alle 5 Minuten) aktualisiert. Im log-file taucht folgende Meldung auf:

Solarlader: Timeout waiting for a modbus response, current frame / read buffer: 010402059e3b, id 1, fCode 4,
request: id 1, read fc 4 i12544, len 1, master device Solarlader, reading PanelVoltage (getUpdate for PanelVoltage len 1), queued 2.23 secs ago, sent 2.00 secs ago, error: Invalid checksum 9e3b received. Calculated 817a

Der Fehler tritt nicht auf, wenn ich die Auswahl der auszulesenden Datensätze auf den fehlenden Wert (obj-i12544) einschränke. Sobald ich das Coils-Register (obj-c2) hinzunehme, taucht die Fehlermeldung wieder auf. Manuell lässt sich der Wert über den "get"-Befehl problemlos auslesen. Wo liegt hier der Fehler?

Hier meine Definition:

Internals:
   DEF        1 300 192.168.188.47:23 RTU
   DeviceName 192.168.188.47:23
   EXPECT     idle
   FD         4
   FUUID      5ced6f5c-f33f-b582-0318-1940751ee0562821
   IODev      Solarlader
   Interval   300
   LASTOPEN   1618764431.74967
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.4.01 - 18.3.2021
   NAME       Solarlader
   NOTIFYDEV  global
   NR         439
   NTFY_ORDER 50-Solarlader
   PARTIAL   
   PROTOCOL   RTU
   STATE      Batterie: BattCapacityRemaining %  Battspannung V BattPowerL W PANEL: 0.66 W Panelspannung V LAST: 0 W
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   nextOpenDelay 60
   OLDREADINGS:
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2021-04-18 19:17:14   BatteryCurrent  0.05
     2021-04-18 19:17:15   BatteryLevel    68
     2021-04-18 19:17:14   BatteryPowerL   0.53
     2021-04-18 19:17:14   BatteryVoltage  13.36
     2021-04-18 19:17:16   ConsEnergyTodL  0.02
     2021-04-18 19:17:16   ConsEnergyTodL_Wh 20
     2021-04-18 19:17:16   GenEnergyTodL   0.06
     2021-04-18 19:17:16   GenEnergyTodL_Wh 60
     2021-04-18 19:17:15   LoadCurrent     0
     2021-04-18 19:17:15   LoadPowerL      0
     2021-04-18 19:17:14   LoadVoltage     0
     2021-04-18 19:17:11   ManualControlLoad 0
     2021-04-18 19:17:14   PanelCurrent    0.03
     2021-04-18 19:17:14   PanelPowerL     0.66
     2021-04-18 17:15:36   PanelVoltage    15.35
     2021-04-18 19:17:15   Temperature_battery 25
     2021-04-18 19:17:15   Temperature_case 29.62
     2021-04-18 19:17:15   Temperature_sink 29.6
     2021-04-18 19:17:16   TotalConsEnergyL 37.6
     2021-04-18 19:17:16   TotalGenEnergyL 87.66
     2021-04-18 18:47:11   state           opened
   REMEMBER:
     lid        1
     lname      Solarlader
     lrecv      1618766236.45454
     lsend      1618766236.40814
   defptr:
     Solarlader 1
   gotReadings:
     TotalGenEnergyL 87.66
   lastRead:
     c0         1618763310.37581
     c2         1618766231.9835
     i12544     1618758936.14383
     i12545     1618766234.14724
     i12546     1618766234.31589
     i12548     1618766234.50324
     i12549     1618766234.68588
     i12550     1618766234.84331
     i12556     1618766234.98282
     i12557     1618766235.12037
     i12558     1618766235.26276
     i12561     1618766235.39352
     i12562     1618766235.52501
     i12570     1618766235.73491
     i12571     1618766235.87044
     i13060     1618766236.02721
     i13066     1618766236.14372
     i13068     1618766236.30614
     i13074     1618766236.45715
Attributes:
   dev-c-defShowGet 1
   dev-i-defShowGet 1
   event-on-change-reading .*
   obj-c2-poll 1
   obj-c2-reading ManualControlLoad
   obj-c2-set 1
   obj-i12544-expr $val/100
   obj-i12544-poll 1
   obj-i12544-reading PanelVoltage
   obj-i12545-expr $val/100
   obj-i12545-poll 1
   obj-i12545-reading PanelCurrent
   obj-i12546-expr $val/100
   obj-i12546-poll 1
   obj-i12546-reading PanelPowerL
   obj-i12548-expr $val/100
   obj-i12548-poll 1
   obj-i12548-reading BatteryVoltage
   obj-i12549-expr $val/100
   obj-i12549-poll 1
   obj-i12549-reading BatteryCurrent
   obj-i12550-expr $val/100
   obj-i12550-poll 1
   obj-i12550-reading BatteryPowerL
   obj-i12556-expr $val/100
   obj-i12556-poll 1
   obj-i12556-reading LoadVoltage
   obj-i12557-expr $val/100
   obj-i12557-poll 1
   obj-i12557-reading LoadCurrent
   obj-i12558-expr $val/100
   obj-i12558-poll 1
   obj-i12558-reading LoadPowerL
   obj-i12561-expr $val/100
   obj-i12561-poll 1
   obj-i12561-reading Temperature_case
   obj-i12562-expr $val/100
   obj-i12562-poll 1
   obj-i12562-reading Temperature_sink
   obj-i12570-poll 1
   obj-i12570-reading BatteryLevel
   obj-i12571-expr $val/100
   obj-i12571-poll 1
   obj-i12571-reading Temperature_battery
   obj-i13060-expr $val/100
   obj-i13060-poll 1
   obj-i13060-reading ConsEnergyTodL
   obj-i13066-expr $val/100
   obj-i13066-poll 1
   obj-i13066-reading TotalConsEnergyL
   obj-i13068-expr $val/100
   obj-i13068-poll 1
   obj-i13068-reading GenEnergyTodL
   obj-i13074-expr $val/100
   obj-i13074-poll 1
   obj-i13074-reading TotalGenEnergyL
   room       Solaranlage
   stateFormat Batterie: BattCapacityRemaining %  Battspannung V BattPowerL W PANEL: PanelPowerL W Panelspannung V LAST: LoadPowerL W
   userReadings ConsEnergyTodL_Wh { ((ReadingsVal("Solarlader","ConsEnergyTodL",0)-ReadingsVal("Solarladerenergie","fixSL",0))*1000)+ReadingsVal("Solarladerenergie","fix0",0)}, GenEnergyTodL_Wh { ReadingsVal("Solarlader","GenEnergyTodL",0)*1000}


   userattr   dev-c-read dev-c-write event-on-change-reading obj-c0-showGet obj-c2-showGet obj-i12544-showGet obj-i12545-showGet obj-i12546-showGet obj-i12548-showGet obj-i12549-showGet obj-i12550-showGet obj-i12556-showGet obj-i12557-showGet obj-i12558-showGet obj-i12561-showGet obj-i12562-showGet obj-i12570-expr obj-i12570-showGet obj-i12571-showGet obj-i13060-showGet obj-i13066-showGet obj-i13074-showGet stateFormat
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 18 April 2021, 21:28:39
Zitat von: Mastodon am 18 April 2021, 19:29:54

Solarlader: Timeout waiting for a modbus response, current frame / read buffer: 010402059e3b, id 1, fCode 4,
request: id 1, read fc 4 i12544, len 1, master device Solarlader, reading PanelVoltage (getUpdate for PanelVoltage len 1), queued 2.23 secs ago, sent 2.00 secs ago, error: Invalid checksum 9e3b received. Calculated 817a

Der Fehler tritt nicht auf, wenn ich die Auswahl der auszulesenden Datensätze auf den fehlenden Wert (obj-i12544) einschränke. Sobald ich das Coils-Register (obj-c2) hinzunehme, taucht die Fehlermeldung wieder auf. Manuell lässt sich der Wert über den "get"-Befehl problemlos auslesen. Wo liegt hier der Fehler?

Hi, also ich weis nicht ob dir mein Modul genau dafür schon bekannt ist
https://forum.fhem.de/index.php/topic,111967.0.html

Wenn ich bei meinen einmal solche effekte hatte half ein reboot von fhem oder auch mal des Solarladers.
Die Software im Solarlader kann man mit manchen Abfragen bzw. setzen von Werten auch schon einmal durcheinander bringen.
Zumindest hatte ich das schon bei meiner fhem implementierung geschafft ;-)
Man kann auch mehrere Readings in einem rutsch abfragen.

Welchen Adapter hast du auf IP ? Stimmt da die Baudrate auch ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mastodon am 19 April 2021, 08:38:46
Zitat von: laserrichi am 18 April 2021, 21:28:39
Hi, also ich weis nicht ob dir mein Modul genau dafür schon bekannt ist
https://forum.fhem.de/index.php/topic,111967.0.html

Wenn ich bei meinen einmal solche effekte hatte half ein reboot von fhem oder auch mal des Solarladers.
Die Software im Solarlader kann man mit manchen Abfragen bzw. setzen von Werten auch schon einmal durcheinander bringen.
Zumindest hatte ich das schon bei meiner fhem implementierung geschafft ;-)
Man kann auch mehrere Readings in einem rutsch abfragen.

Welchen Adapter hast du auf IP ? Stimmt da die Baudrate auch ?

Hallo laserrichi,

nein, das Modul kannte ich noch nicht. Deshalb bin ich Dir umso dankbarer, dass Du mich darauf hingewiesen hast. Installiert, definiert und funktioniert. Ich werde beobachten, ob es im weiteren Betrieb irgendwelche Auffälligkeiten gibt. Ich habe gerade einen Victron BMV-700 Batteriemonitor eingebunden und muss die Programmperipherie sowieso anpassen. Die Einbindung des neuen EPEVER-Moduls kommt also gerade zur rechten Zeit. 
FHEM-Reboot hat vorher leider nicht geholfen. Den Solarlader hatte ich bisher keinem Reboot unterworfen. Ich benutze einen Selbstbau-Adapter auf ESP8266-Basis zur Kommunikation über WLAN. Die Baudrate sollte stimmen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 April 2021, 19:24:26
Wenn Werte beim automatischen Abfragen fehlen, aber einzeln erfolgreich abgefragt werden können, dann liegt es meistens am "combine". Jedes Gerät hat sein eigens Maximum bezüglich der Werte, die innerhalb eines Requests gelesen werden können. Wenn man combine zu hoch einstellt, dann gibt es Probleme...

Gruss
     Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 28 April 2021, 21:20:03
Hallo Stefan,

du wolltest doch auf deine Wunschliste mal Function code 43 (Hex 2b) Encapsulated Interface Transport setzen.
Oder hattest du das wieder verworfen ?
Ist ja auch sowieso nur nice to have.

Gruß Laserrichi
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 April 2021, 16:50:43
Hallo Laserrichi,

ich hab mir das mal angesehen und den Eindruck bekommen, dass man das nicht so einfach über Attribute umsetzen kann.

Zitat
The MODBUS Encapsulated Interface (MEI)Transport is a mechanism for tunneling service
requests and method invocations, as well as their returns, inside MODBUS PDUs .
The primary feature of the MEI Transport is the encapsulation of method invocations or
service requests that are part of a defined interface as well as method invocation returns or
service responses.

Das kann alles sein.
Vermutlich könnte man eigenen Perl-Code aufrufen um die Inhalte je nach Gerät zu interpretieren.
Deshalb habe ich es bisher nicht weiter verfolgt.
Was war denn Dein Anwendungsfall?

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 29 April 2021, 17:52:49
Hallo Stefan,

ok verstehe. Es wäre nur nice to have gewesen. Damit wird bei epever Laderegler die Version Seriennummer usw. ausgelesen.

Gruß laserrichi
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 01 Mai 2021, 18:22:11
nochmal eine Frage.
Ich möchte in meinen Modul bei "set"  werte von anderen Readings mit einbauen.

'setexpr' => 'sprintf("%02d", ReadingsVal($name,"einzulesendesreading")',

Hintergrund ist, das ich im Modbus Device manche Werte nur kombiniert setzen kann, diese jedoch als einzelne Readings vorhanden sind.

D.h. wenn ich einen Wert verändere, muss ich die anderen reading register ebenfalls beim set mitschicken.
kann ich bei setexpr eigentlich das so in der Art einbauen ? $name $device oder vieleicht anders ?

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 Mai 2021, 17:15:57
Hallo laserrichi,

einfach mit ReadingsVal, so wie Du es angedeutet hast.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Vorhand am 09 Mai 2021, 14:45:18
Hallo Stefan, du konntest schon mal in Sachen DimplexBrauchwasserWP bei "stolus" helfen, so dass die Kommunikation funktionierte. Ich hab' zwar alles gelesen -  kein Erfolg.
Hier sind die beiden lists:
ModBusLine
Internals:
   DEF        /dev/ttyUSB0@19200,8,E,1
   DeviceName /dev/ttyUSB0@19200,8,E,1
   EXPECT     response
   FD         4
   FUUID      6096a1e6-f33f-0224-74ab-cb4e1fe42a94885e
   LASTOPEN   1620556537.41282
   MODE       master
   NAME       ModBusLine
   NOTIFYDEV  global
   NR         15
   NTFY_ORDER 50-ModBusLine
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   nextQueueRun 1620563905.75668
   nextTimeout 1620563907.73818
   FRAME:
   QUEUE:
     HASH(0x3148cd8)
     HASH(0x3149728)
     HASH(0x31493b0)
     HASH(0x31a32d8)
     HASH(0x30cb1c8)
     HASH(0x31af040)
     HASH(0x322ae48)
     HASH(0x32411f0)
     HASH(0x31a4378)
     HASH(0x3149530)
     HASH(0x31a43d8)
     HASH(0x31a23a0)
     HASH(0x30bf2f8)
     HASH(0x30d33c8)
     HASH(0x316f4c0)
     HASH(0x30cb300)
     HASH(0x31a61a8)
     HASH(0x31a4468)
     HASH(0x31493c8)
     HASH(0x2528df8)
     HASH(0x322e078)
   READ:
     BUFFER     
   READINGS:
     2021-05-09 12:35:37   state           opened
   REMEMBER:
     lid        2
     lname      ModBusLine
     lrecv      1620563900.71293
     lsend      1620563904.75499
   REQUEST:
     ADR        16
     DBGINFO    getUpdate for WW_Hysterese_K len 1
     FCODE      3
     FRAME      ��
     LEN        1
     MODBUSID   2
     OPERATION  read
     QUEUED     1620563899.53765
     READING    WW_Hysterese_K
     SENT       1620563904.73818
     TYPE       h
     MASTERHASH:
       DEF        2 60
       FUUID      6096b410-f33f-0224-1063-7d1e95ce7a4a04f0
       IODev      ModBusLine
       Interval   60
       MODBUSID   2
       MODE       master
       MODULEVERSION Modbus 4.4.02 - 31.3.2021
       NAME       DHW300
       NOTIFYDEV  global
       NR         16
       NTFY_ORDER 50-DHW300
       PROTOCOL   RTU
       STATE      opened
       TYPE       ModbusDHW300
       FRAME:
       READ:
       READINGS:
         2021-05-09 11:30:04   state           opened
       REMEMBER:
         lrecv      1620563900.71623
         lsend      1620563904.75499
       gotReadings:
       lastRead:
   defptr:
     DHW300     2
Attributes:
   room       DHW300

DHW300
Internals:
   DEF        2 60
   FUUID      6096b410-f33f-0224-1063-7d1e95ce7a4a04f0
   IODev      ModBusLine
   Interval   60
   MODBUSID   2
   MODE       master
   MODULEVERSION Modbus 4.4.02 - 31.3.2021
   NAME       DHW300
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-DHW300
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusDHW300
   FRAME:
   READ:
   READINGS:
     2021-05-09 11:30:04   state           opened
   REMEMBER:
     lrecv      1620563141.01976
     lsend      1620563139.97051
   gotReadings:
   lastRead:
Attributes:
   room       DHW300

Mache ich da was grundsätzlich falsch? In der DHW300 habe ich im Menü PVO anstatt BWS als Modus eingestellt, so wie es auch für den Dimplex PV-Optimizer vorgegeben ist.
Meine get Anfragen enden alle mit "Timeout in Readanswer"
Danke
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 Mai 2021, 18:39:44
Hallo Vorhand,

Bist Du denn sicher, dass die Kommunikationsparameter stimmen?
19200,8,E,1 sowie Modbusid 2?

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Vorhand am 10 Mai 2021, 14:48:34
Diese Parameter habe ich auch an der BW-Wärmepumpe eingestellt.
Zunächst hatte ich mit USB1 definiert und nur disconnect bekommen. Als ich auf USB0 umstellte erschien opened.
Ist der Status opened keine Bestätigung für eine Verbindung?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Mai 2021, 19:11:23
Hallo,

der Status opened bedeutet, dass eine serielle Schnittstelle geöffnet wurde.
Mit Modbus hat das noch nichts zu tun.
Ich würde mit dmesg schauen was passiert, wenn Du den Adapter kurz rausziehst und wieder reinsteckst.
Eventuell hast Du ja die falsche geöffnet...

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 10 Mai 2021, 21:00:46
Zitat von: Vorhand am 10 Mai 2021, 14:48:34
Diese Parameter habe ich auch an der BW-Wärmepumpe eingestellt.
Zunächst hatte ich mit USB1 definiert und nur disconnect bekommen. Als ich auf USB0 umstellte erschien opened.
Ist der Status opened keine Bestätigung für eine Verbindung?

nur um sicher zu gehen ob das usb serial interface auch richtig ist, zeig mal den output von:
lsusb -t
ls -la /dev/serial/by-id/

soweit ich jetzt von Dimplex was gelesen habe steht da auch  Modbus RTU  also solltest du auch vermutlich bei deinem define  RTU mitgeben

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Vorhand am 11 Mai 2021, 12:00:25
Mit dmesg kommt jede Menge:
Hier ohne USB-Stick:
pi@G15T58:~ $ dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.4.79-v7+ (dom@buildbot) (gcc version 8.4.0 (Ubuntu/Linaro 8.4.0-3ubuntu1)) #1373 SMP Mon Nov 23 13:22:33 GMT 2020
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Rev 1.2
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Reserved memory: created CMA memory pool at 0x37400000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] On node 0 totalpages: 242688
[    0.000000]   Normal zone: 2133 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 242688 pages, LIFO batch:63
[    0.000000] percpu: Embedded 20 pages/cpu s49740 r8192 d23988 u81920
[    0.000000] pcpu-alloc: s49740 r8192 d23988 u81920 alloc=20*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 240555
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1080 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=ttyS0,115200 console=tty1 root=PARTUUID=987c9eea-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 880480K/970752K available (9216K kernel code, 698K rwdata, 2608K rodata, 1024K init, 827K bss, 24736K reserved, 65536K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] ftrace: allocating 29201 entries in 58 pages
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] random: get_random_bytes called from start_kernel+0x324/0x4f8 with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000007] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[    0.000017] Switching to timer-based delay loop, resolution 52ns
[    0.000273] Console: colour dummy device 80x30
[    0.000299] printk: console [tty1] enabled
[    0.000352] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[    0.000371] pid_max: default: 32768 minimum: 301
[    0.000558] LSM: Security Framework initializing
[    0.000772] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000792] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.002199] Disabling memory control group subsystem
[    0.002316] CPU: Testing write buffer coherency: ok
[    0.002858] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.003783] Setting up static identity map for 0x100000 - 0x10003c
[    0.003977] rcu: Hierarchical SRCU implementation.
[    0.004650] smp: Bringing up secondary CPUs ...
[    0.005741] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.006983] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.008123] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.008276] smp: Brought up 1 node, 4 CPUs
[    0.008292] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[    0.008301] CPU: All CPU(s) started in HYP mode.
[    0.008310] CPU: Virtualization extensions available.
[    0.009241] devtmpfs: initialized
[    0.025560] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4
[    0.025814] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.025840] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.029069] pinctrl core: initialized pinctrl subsystem
[    0.030243] NET: Registered protocol family 16
[    0.034331] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[    0.039085] audit: initializing netlink subsys (disabled)
[    0.039351] audit: type=2000 audit(0.030:1): state=initialized audit_enabled=0 res=1
[    0.040916] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.040927] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.041136] Serial: AMBA PL011 UART driver
[    0.043067] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[    0.060084] raspberrypi-firmware soc:firmware: Attached to firmware from 2020-11-30 22:13, variant start
[    0.070097] raspberrypi-firmware soc:firmware: Firmware hash is ab1181cc0cb6df52bfae3b1d3fef0ce7c325166c
[    0.122004] bcm2835-dma 3f007000.dma: DMA legacy API manager, dmachans=0x1
[    0.124140] SCSI subsystem initialized
[    0.124392] usbcore: registered new interface driver usbfs
[    0.124453] usbcore: registered new interface driver hub
[    0.124588] usbcore: registered new device driver usb
[    0.126549] clocksource: Switched to clocksource arch_sys_counter
[    1.385926] VFS: Disk quotas dquot_6.6.0
[    1.386034] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.386222] FS-Cache: Loaded
[    1.386485] CacheFiles: Loaded
[    1.397741] thermal_sys: Registered thermal governor 'step_wise'
[    1.398119] NET: Registered protocol family 2
[    1.399072] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[    1.399115] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    1.399230] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    1.399419] TCP: Hash tables configured (established 8192 bind 8192)
[    1.399573] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.399626] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.399911] NET: Registered protocol family 1
[    1.400600] RPC: Registered named UNIX socket transport module.
[    1.400610] RPC: Registered udp transport module.
[    1.400619] RPC: Registered tcp transport module.
[    1.400629] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.402401] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available
[    1.405678] Initialise system trusted keyrings
[    1.405914] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[    1.417499] FS-Cache: Netfs 'nfs' registered for caching
[    1.418300] NFS: Registering the id_resolver key type
[    1.418350] Key type id_resolver registered
[    1.418360] Key type id_legacy registered
[    1.418381] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.419656] Key type asymmetric registered
[    1.419668] Asymmetric key parser 'x509' registered
[    1.419729] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    1.419741] io scheduler mq-deadline registered
[    1.419752] io scheduler kyber registered
[    1.424308] bcm2708_fb soc:fb: FB found 1 display(s)
[    1.458019] Console: switching to colour frame buffer device 240x67
[    1.493398] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 1920x1080
[    1.496965] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[    1.499438] bcm2835-rng 3f104000.rng: hwrng registered
[    1.499955] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[    1.500688] vc-sm: Videocore shared memory driver
[    1.501162] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[    1.514146] brd: module loaded
[    1.526844] loop: module loaded
[    1.528296] Loading iSCSI transport class v2.0-870.
[    1.529166] libphy: Fixed MDIO Bus: probed
[    1.529277] usbcore: registered new interface driver lan78xx
[    1.529339] usbcore: registered new interface driver smsc95xx
[    1.529362] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    2.257547] Core Release: 2.80a
[    2.257572] Setting default values for core params
[    2.257599] Finished setting default values for core params
[    2.458011] Using Buffer DMA mode
[    2.458022] Periodic Transfer Interrupt Enhancement - disabled
[    2.458031] Multiprocessor Interrupt Enhancement - disabled
[    2.458042] OTG VER PARAM: 0, OTG VER FLAG: 0
[    2.458069] Dedicated Tx FIFOs mode
[    2.458761] WARN::dwc_otg_hcd_init:1074: FIQ DMA bounce buffers: virt = b7504000 dma = 0xf7504000 len=9024
[    2.458787] FIQ FSM acceleration enabled for :
               Non-periodic Split Transactions
               Periodic Split Transactions
               High-Speed Isochronous Endpoints
               Interrupt/Control Split Transaction hack enabled
[    2.458798] dwc_otg: Microframe scheduler enabled
[    2.458858] WARN::hcd_init_fiq:457: FIQ on core 1
[    2.458868] WARN::hcd_init_fiq:458: FIQ ASM at 8070b948 length 36
[    2.458878] WARN::hcd_init_fiq:497: MPHI regs_base at bb810000
[    2.458898] dwc_otg 3f980000.usb: DWC OTG Controller
[    2.458934] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[    2.458979] dwc_otg 3f980000.usb: irq 56, io mem 0x00000000
[    2.459029] Init: Port Power? op_state=1
[    2.459038] Init: Power Port (0)
[    2.459410] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[    2.459425] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.459439] usb usb1: Product: DWC OTG Controller
[    2.459452] usb usb1: Manufacturer: Linux 5.4.79-v7+ dwc_otg_hcd
[    2.459465] usb usb1: SerialNumber: 3f980000.usb
[    2.460171] hub 1-0:1.0: USB hub found
[    2.460236] hub 1-0:1.0: 1 port detected
[    2.461030] dwc_otg: FIQ enabled
[    2.461040] dwc_otg: NAK holdoff enabled
[    2.461049] dwc_otg: FIQ split-transaction FSM enabled
[    2.461064] Module dwc_common_port init
[    2.461423] usbcore: registered new interface driver usb-storage
[    2.461626] mousedev: PS/2 mouse device common for all mice
[    2.462821] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[    2.465496] sdhci: Secure Digital Host Controller Interface driver
[    2.465505] sdhci: Copyright(c) Pierre Ossman
[    2.466110] mmc-bcm2835 3f300000.mmcnr: could not get clk, deferring probe
[    2.466834] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[    2.467076] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.468839] ledtrig-cpu: registered to indicate activity on CPUs
[    2.469212] hidraw: raw HID events driver (C) Jiri Kosina
[    2.469381] usbcore: registered new interface driver usbhid
[    2.469390] usbhid: USB HID core driver
[    2.470412] vchiq: vchiq_init_state: slot_zero = (ptrval)
[    2.472115] [vc_sm_connected_init]: start
[    2.480391] [vc_sm_connected_init]: end - returning 0
[    2.482423] Initializing XFRM netlink socket
[    2.482461] NET: Registered protocol family 17
[    2.482610] Key type dns_resolver registered
[    2.483362] Registering SWP/SWPB emulation handler
[    2.483681] registered taskstats version 1
[    2.483703] Loading compiled-in X.509 certificates
[    2.484265] Key type ._fscrypt registered
[    2.484277] Key type .fscrypt registered
[    2.495075] uart-pl011 3f201000.serial: cts_event_workaround enabled
[    2.495174] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[    2.497757] printk: console [ttyS0] disabled
[    2.497836] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 50000000) is a 16550
[    2.497904] printk: console [ttyS0] enabled
[    2.498646] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[    2.500179] mmc-bcm2835 3f300000.mmcnr: mmc_debug:0 mmc_debug2:0
[    2.500192] mmc-bcm2835 3f300000.mmcnr: DMA channel allocated
[    2.526823] sdhost: log_buf @ (ptrval) (f7507000)
[    2.566752] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    2.568403] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    2.570047] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    2.572995] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    2.574791] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[    2.577517] of_cfs_init
[    2.577811] of_cfs_init: OK
[    2.578755] Waiting for root device PARTUUID=987c9eea-02...
[    2.639764] random: fast init done
[    2.659716] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.664652] mmc0: new high speed SDHC card at address aaaa
[    2.665760] mmcblk0: mmc0:aaaa SL32G 28.8 GiB
[    2.668732]  mmcblk0: p1 p2
[    2.676780] Indeed it is in host mode hprt0 = 00021501
[    2.710913] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    2.711006] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    2.712081] devtmpfs: mounted
[    2.738592] Freeing unused kernel memory: 1024K
[    2.755788] mmc1: new high speed SDIO card at address 0001
[    2.776991] Run /sbin/init as init process
[    2.886624] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    2.886803] Indeed it is in host mode hprt0 = 00001101
[    3.127011] usb 1-1: New USB device found, idVendor=0424, idProduct=9514, bcdDevice= 2.00
[    3.127032] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.127788] hub 1-1:1.0: USB hub found
[    3.127905] hub 1-1:1.0: 5 ports detected
[    3.426962] systemd[1]: System time before build time, advancing clock.
[    3.446619] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    3.577094] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00, bcdDevice= 2.00
[    3.577116] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.579951] smsc95xx v1.0.6
[    3.590353] NET: Registered protocol family 10
[    3.591810] Segment Routing with IPv6
[    3.622134] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[    3.623167] systemd[1]: Detected architecture arm.
[    3.681420] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:40:07:08
[    3.690388] systemd[1]: Set hostname to <G15T58>.
[    3.776780] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    3.909937] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[    3.909979] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[    3.910005] usb 1-1.2: Product: USB Serial
[    4.006670] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
[    4.149491] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice= 7.02
[    4.149512] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    4.149526] usb 1-1.3: Product: USB2.0 Hub
[    4.150406] hub 1-1.3:1.0: USB hub found
[    4.150721] hub 1-1.3:1.0: 4 ports detected
[    4.466636] usb 1-1.3.1: new low-speed USB device number 6 using dwc_otg
[    4.615437] usb 1-1.3.1: New USB device found, idVendor=1c4f, idProduct=0016, bcdDevice= 1.10
[    4.615458] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    4.615475] usb 1-1.3.1: Product: USB Keyboard
[    4.615488] usb 1-1.3.1: Manufacturer: SIGMACHIP
[    4.627921] input: SIGMACHIP USB Keyboard as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/0003:1C4F:0016.0001/input/input0
[    4.697450] hid-generic 0003:1C4F:0016.0001: input,hidraw0: USB HID v1.10 Keyboard [SIGMACHIP USB Keyboard] on usb-3f980000.usb-1.3.1/input0
[    4.707448] input: SIGMACHIP USB Keyboard Consumer Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/0003:1C4F:0016.0002/input/input1
[    4.769750] random: systemd: uninitialized urandom read (16 bytes read)
[    4.777179] input: SIGMACHIP USB Keyboard System Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/0003:1C4F:0016.0002/input/input2
[    4.777504] hid-generic 0003:1C4F:0016.0002: input,hidraw1: USB HID v1.10 Device [SIGMACHIP USB Keyboard] on usb-3f980000.usb-1.3.1/input1
[    4.786114] random: systemd: uninitialized urandom read (16 bytes read)
[    4.786752] systemd[1]: Listening on initctl Compatibility Named Pipe.
[    4.787451] random: systemd: uninitialized urandom read (16 bytes read)
[    4.788204] systemd[1]: Listening on Syslog Socket.
[    4.791844] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[    4.800237] systemd[1]: Listening on fsck to fsckd communication Socket.
[    4.801117] systemd[1]: Listening on Journal Socket (/dev/log).
[    4.809187] systemd[1]: Listening on udev Kernel Socket.
[    4.810660] systemd[1]: Created slice User and Session Slice.
[    4.877406] usb 1-1.3.2: new low-speed USB device number 7 using dwc_otg
[    4.953762] i2c /dev entries driver
[    5.038721] usb 1-1.3.2: New USB device found, idVendor=0000, idProduct=3825, bcdDevice= 1.00
[    5.038743] usb 1-1.3.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    5.038757] usb 1-1.3.2: Product:  USB OPTICAL MOUSE
[    5.050768] input:  USB OPTICAL MOUSE as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:0000:3825.0003/input/input3
[    5.051491] hid-generic 0003:0000:3825.0003: input,hidraw2: USB HID v1.11 Mouse [ USB OPTICAL MOUSE] on usb-3f980000.usb-1.3.2/input0
[    5.589578] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    5.714261] systemd-journald[105]: Received request to flush runtime journal from PID 1
[    7.189756] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[    7.194366] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[    7.194390] [vc_sm_connected_init]: start
[    7.196262] [vc_sm_connected_init]: installed successfully
[    7.200279] mc: Linux media interface: v0.10
[    7.278025] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[    7.281743] videodev: Linux video capture interface: v2.00
[    7.286218] bcm2835_audio bcm2835_audio: card created with 4 channels
[    7.312290] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    7.315137] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    7.318522] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    7.322153] bcm2835_audio bcm2835_audio: card created with 4 channels
[    7.335182] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[    7.336170] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[    7.369806] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[    7.398500] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
[    7.399897] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
[    7.400358] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
[    7.400763] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
[    7.400796] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
[    7.400818] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[    7.400836] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[    7.400854] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[    7.401093] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
[    7.405594] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[    7.405679] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[    7.414611] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[    7.414665] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[    7.421301] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[    7.421352] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[    7.895811] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    8.061406] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    8.192861] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[    8.202044] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[    8.202392] usbcore: registered new interface driver brcmfmac
[    8.239344] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt failed with error -2
[    8.260898] usbcore: registered new interface driver usbserial_generic
[    8.260975] usbserial: USB Serial support registered for generic
[    8.268404] usbcore: registered new interface driver ch341
[    8.269533] usbserial: USB Serial support registered for ch341-uart
[    8.269689] ch341 1-1.2:1.0: ch341-uart converter detected
[    8.278798] usb 1-1.2: ch341-uart converter now attached to ttyUSB0
[    8.454295] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[    8.454474] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[    8.455429] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 22 2019 01:59:28 version 7.45.98.94 (r723000 CY) FWID 01-3b33decd
[   10.169880] random: crng init done
[   10.169897] random: 7 urandom warning(s) missed due to ratelimiting
[   10.318187] uart-pl011 3f201000.serial: no DMA platform data
[   10.863796] 8021q: 802.1Q VLAN Support v1.8
[   11.138066] Adding 102396k swap on /var/swap.  Priority:-2 extents:1 across:102396k SSFS
[   11.458726] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[   12.019479] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[   13.534252] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   13.537221] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   14.616920] warning: process `colord-sane' used the deprecated sysctl system call with 8.1.2.
[   14.880723] Bluetooth: Core ver 2.22
[   14.881024] NET: Registered protocol family 31
[   14.881056] Bluetooth: HCI device and connection manager initialized
[   14.887244] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.eth0.retrans_time - use net.ipv6.neigh.eth0.retrans_time_ms instead
[   14.897966] Bluetooth: HCI socket layer initialized
[   14.897981] Bluetooth: L2CAP socket layer initialized
[   14.898013] Bluetooth: SCO socket layer initialized
[   14.908907] Bluetooth: HCI UART driver ver 2.3
[   14.908919] Bluetooth: HCI UART protocol H4 registered
[   14.909129] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   14.911549] Bluetooth: HCI UART protocol Broadcom registered
[   15.249801] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   15.249811] Bluetooth: BNEP filters: protocol multicast
[   15.249828] Bluetooth: BNEP socket layer initialized
[   17.356691] Bluetooth: hci0: command 0x0c56 tx timeout
[   17.751067] fuse: init (API version 7.31)
[   19.796330] Bluetooth: RFCOMM TTY layer initialized
[   19.796381] Bluetooth: RFCOMM socket layer initialized
[   19.796418] Bluetooth: RFCOMM ver 1.11
[  454.967744] usb 1-1.3.4: new full-speed USB device number 8 using dwc_otg
[  455.387757] usb 1-1.3.4: new high-speed USB device number 9 using dwc_otg
[  455.519098] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  455.519145] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  455.519159] usb 1-1.3.4: Product: Mass Storage Device
[  455.519172] usb 1-1.3.4: Manufacturer: Generic
[  455.519185] usb 1-1.3.4: SerialNumber: 125C20100726
[  455.520341] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  455.520972] scsi host0: usb-storage 1-1.3.4:1.0
[  455.599484] usbcore: registered new interface driver uas
[  456.558776] scsi 0:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[  456.562397] sd 0:0:0:0: [sda] 32372736 512-byte logical blocks: (16.6 GB/15.4 GiB)
[  456.563008] sd 0:0:0:0: [sda] Write Protect is off
[  456.563031] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[  456.563764] sd 0:0:0:0: [sda] No Caching mode page found
[  456.563781] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  456.591953] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  456.631424]  sda: sda1 sda2
[  456.635120] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  457.325456] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[  457.366506] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[  457.445971] dwc_otg: DEVICE:009 : update_urb_state_xfer_comp:751:trimming xfer length
[  457.537801] usb 1-1.3.4: reset high-speed USB device number 9 using dwc_otg
[  457.678375] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[  457.678402] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 20 29 00 00 80 00
[  457.678419] blk_update_request: I/O error, dev sda, sector 8233 op 0x0:(READ) flags 0x84700 phys_seg 128 prio class 0
[  457.777757] usb 1-1.3.4: reset high-speed USB device number 9 using dwc_otg
[  524.853299] usb 1-1.3.4: USB disconnect, device number 9
[  525.307980] usb 1-1.3.4: new high-speed USB device number 10 using dwc_otg
[  525.438997] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  525.439011] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  525.439019] usb 1-1.3.4: Product: Mass Storage Device
[  525.439026] usb 1-1.3.4: Manufacturer: Generic
[  525.439032] usb 1-1.3.4: SerialNumber: 125C20100726
[  525.440454] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  525.441596] scsi host0: usb-storage 1-1.3.4:1.0
[  526.135140] usb 1-1.3.4: USB disconnect, device number 10
[  526.427980] usb 1-1.3.4: new high-speed USB device number 11 using dwc_otg
[  526.558993] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  526.559005] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  526.559012] usb 1-1.3.4: Product: Mass Storage Device
[  526.559019] usb 1-1.3.4: Manufacturer: Generic
[  526.559025] usb 1-1.3.4: SerialNumber: 125C20100726
[  526.559685] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  526.560562] scsi host0: usb-storage 1-1.3.4:1.0
[  526.905313] usb 1-1.3.4: USB disconnect, device number 11
[  528.008665] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  528.918676] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  528.918995] usb 1-1.3-port4: attempt power cycle
[  530.168853] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  530.268069] usb 1-1.3.4: new high-speed USB device number 15 using dwc_otg
[  530.299555] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  530.299578] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  530.299593] usb 1-1.3.4: Product: Mass Storage Device
[  530.299623] usb 1-1.3.4: Manufacturer: Generic
[  530.299637] usb 1-1.3.4: SerialNumber: 125C20100726
[  530.300663] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  530.302075] scsi host0: usb-storage 1-1.3.4:1.0
[  530.457129] usb 1-1.3.4: USB disconnect, device number 15
[  531.038103] usb 1-1.3.4: new high-speed USB device number 16 using dwc_otg
[  531.169427] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  531.169448] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  531.169462] usb 1-1.3.4: Product: Mass Storage Device
[  531.169489] usb 1-1.3.4: Manufacturer: Generic
[  531.169503] usb 1-1.3.4: SerialNumber: 125C20100726
[  531.170517] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  531.173614] scsi host0: usb-storage 1-1.3.4:1.0
[  531.483172] usb 1-1.3.4: USB disconnect, device number 16
[  531.818055] usb 1-1.3.4: new high-speed USB device number 17 using dwc_otg
[  531.949126] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  531.949140] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  531.949148] usb 1-1.3.4: Product: Mass Storage Device
[  531.949155] usb 1-1.3.4: Manufacturer: Generic
[  531.949163] usb 1-1.3.4: SerialNumber: 125C20100726
[  531.949801] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  531.950461] scsi host0: usb-storage 1-1.3.4:1.0
[  532.519150] usb 1-1.3.4: USB disconnect, device number 17
[  532.818147] usb 1-1.3.4: new high-speed USB device number 18 using dwc_otg
[  533.758715] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  534.668795] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  534.669131] usb 1-1.3-port4: attempt power cycle
[  535.918788] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  536.828927] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  536.829262] usb 1-1.3-port4: unable to enumerate USB device
[  610.089008] usb 1-1.3.4: new full-speed USB device number 22 using dwc_otg
[  610.508994] usb 1-1.3.4: new high-speed USB device number 23 using dwc_otg
[  610.640337] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  610.640359] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  610.640434] usb 1-1.3.4: Product: Mass Storage Device
[  610.640448] usb 1-1.3.4: Manufacturer: Generic
[  610.640461] usb 1-1.3.4: SerialNumber: 125C20100726
[  610.641521] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  610.645970] scsi host0: usb-storage 1-1.3.4:1.0
[  611.680041] scsi 0:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[  611.682153] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  611.682379] sd 0:0:0:0: [sda] 32372736 512-byte logical blocks: (16.6 GB/15.4 GiB)
[  611.689154] sd 0:0:0:0: [sda] Write Protect is off
[  611.689179] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[  611.689638] sd 0:0:0:0: [sda] No Caching mode page found
[  611.689655] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  611.762419]  sda: sda1 sda2
[  611.765279] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  612.431411] EXT4-fs (sda2): recovery complete
[  612.431435] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[  612.450322] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[  684.031827] usb 1-1.3.4: USB disconnect, device number 23
[  684.070268] blk_update_request: I/O error, dev sda, sector 532480 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[  684.070295] Buffer I/O error on dev sda2, logical block 0, lost async page write
[  684.070354] blk_update_request: I/O error, dev sda, sector 8922072 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[  684.070367] Buffer I/O error on dev sda2, logical block 1048699, lost async page write
[  684.070506] blk_update_request: I/O error, dev sda, sector 8923232 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[  684.070519] Buffer I/O error on dev sda2, logical block 1048844, lost async page write
[  684.070561] blk_update_request: I/O error, dev sda, sector 9064624 op 0x1:(WRITE) flags 0x3000 phys_seg 2 prio class 0
[  684.070574] Buffer I/O error on dev sda2, logical block 1066518, lost async page write
[  684.070596] Buffer I/O error on dev sda2, logical block 1066519, lost async page write
[  684.070667] blk_update_request: I/O error, dev sda, sector 9064784 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[  684.070679] Buffer I/O error on dev sda2, logical block 1066538, lost async page write
[  684.091142] JBD2: Error while async write back metadata bh 0.
[  684.091153] Aborting journal on device sda2-8.
[  684.091287] blk_update_request: I/O error, dev sda, sector 3678208 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[  684.091307] Buffer I/O error on dev sda2, logical block 393216, lost sync page write
[  684.091343] JBD2: Error -5 detected when updating journal superblock for sda2-8.
[  684.099349] JBD2: Error while async write back metadata bh 1048699.
[  684.100350] JBD2: Error while async write back metadata bh 1048844.
[  684.101480] JBD2: Error while async write back metadata bh 1066518.
[  684.101510] JBD2: Error while async write back metadata bh 1066519.
[  684.101597] JBD2: Error while async write back metadata bh 1066538.
[  818.174743] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 6
[  819.120775] usb 1-1.3.1: reset low-speed USB device number 6 using dwc_otg
[  820.920769] usb 1-1.3.4: new full-speed USB device number 24 using dwc_otg
[  821.340722] usb 1-1.3.4: new high-speed USB device number 25 using dwc_otg
[  821.471747] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  821.471759] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  821.471766] usb 1-1.3.4: Product: Mass Storage Device
[  821.471772] usb 1-1.3.4: Manufacturer: Generic
[  821.471779] usb 1-1.3.4: SerialNumber: 125C20100726
[  821.472435] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  821.474694] scsi host0: usb-storage 1-1.3.4:1.0
[  822.482531] scsi 0:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[  822.485069] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  822.490913] sd 0:0:0:0: [sda] 32372736 512-byte logical blocks: (16.6 GB/15.4 GiB)
[  822.492684] sd 0:0:0:0: [sda] Write Protect is off
[  822.492700] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[  822.493034] sd 0:0:0:0: [sda] No Caching mode page found
[  822.493043] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  822.553985]  sda: sda1 sda2
[  822.556616] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  823.625544] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[  823.663639] EXT4-fs (sda2): recovery complete
[  823.670830] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[ 1155.253315] usb 1-1.3.4: USB disconnect, device number 25
[ 1155.728389] usb 1-1.3.4: new high-speed USB device number 26 using dwc_otg
[ 1155.859677] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[ 1155.859699] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 1155.859713] usb 1-1.3.4: Product: Mass Storage Device
[ 1155.859727] usb 1-1.3.4: Manufacturer: Generic
[ 1155.859741] usb 1-1.3.4: SerialNumber: 125C20100726
[ 1155.860771] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[ 1155.864766] scsi host0: usb-storage 1-1.3.4:1.0
[ 1156.023123] usb 1-1.3.4: USB disconnect, device number 26
[ 1156.358292] usb 1-1.3.4: new high-speed USB device number 27 using dwc_otg
[ 1156.489257] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[ 1156.489270] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 1156.489278] usb 1-1.3.4: Product: Mass Storage Device
[ 1156.489284] usb 1-1.3.4: Manufacturer: Generic
[ 1156.489291] usb 1-1.3.4: SerialNumber: 125C20100726
[ 1156.489935] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[ 1156.490348] scsi host0: usb-storage 1-1.3.4:1.0
[ 1156.716471] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 3
[ 1157.218381] usb 1-1.3.1: reset low-speed USB device number 6 using dwc_otg
[ 1158.290678] usb 1-1.3.4: USB disconnect, device number 27
[ 1158.578380] usb 1-1.3.1: reset low-speed USB device number 6 using dwc_otg
[ 2412.392034] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 2412.392147] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 2412.564602] usb 1-1.2: USB disconnect, device number 4
[ 2412.565179] usb 1-1.2: failed to send control message: -19
[ 2412.565825] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 2412.565927] ch341 1-1.2:1.0: device disconnected
[ 2669.120463] usb 1-1.2: new full-speed USB device number 28 using dwc_otg
[ 2669.253692] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 2669.253715] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 2669.253729] usb 1-1.2: Product: USB Serial
[ 2669.254936] ch341 1-1.2:1.0: ch341-uart converter detected
[ 2669.257292] usb 1-1.2: ch341-uart converter now attached to ttyUSB0
[25120.357619] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[25120.357722] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[25120.536679] usb 1-1.2: USB disconnect, device number 28
[25120.537204] usb 1-1.2: failed to send control message: -19
[25120.537886] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[25120.537997] ch341 1-1.2:1.0: device disconnected
pi@G15T58:~ $
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Vorhand am 11 Mai 2021, 18:32:45
Jetzt mit USB-Stick

pi@G15T58:~ $ dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.4.79-v7+ (dom@buildbot) (gcc version 8.4.0 (Ubuntu/Linaro 8.4.0-3ubuntu1)) #1373 SMP Mon Nov 23 13:22:33 GMT 2020
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Rev 1.2
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Reserved memory: created CMA memory pool at 0x37400000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] On node 0 totalpages: 242688
[    0.000000]   Normal zone: 2133 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 242688 pages, LIFO batch:63
[    0.000000] percpu: Embedded 20 pages/cpu s49740 r8192 d23988 u81920
[    0.000000] pcpu-alloc: s49740 r8192 d23988 u81920 alloc=20*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 240555
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1080 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=ttyS0,115200 console=tty1 root=PARTUUID=987c9eea-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 880480K/970752K available (9216K kernel code, 698K rwdata, 2608K rodata, 1024K init, 827K bss, 24736K reserved, 65536K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] ftrace: allocating 29201 entries in 58 pages
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] random: get_random_bytes called from start_kernel+0x324/0x4f8 with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000007] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[    0.000017] Switching to timer-based delay loop, resolution 52ns
[    0.000273] Console: colour dummy device 80x30
[    0.000299] printk: console [tty1] enabled
[    0.000352] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[    0.000371] pid_max: default: 32768 minimum: 301
[    0.000558] LSM: Security Framework initializing
[    0.000772] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000792] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.002199] Disabling memory control group subsystem
[    0.002316] CPU: Testing write buffer coherency: ok
[    0.002858] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.003783] Setting up static identity map for 0x100000 - 0x10003c
[    0.003977] rcu: Hierarchical SRCU implementation.
[    0.004650] smp: Bringing up secondary CPUs ...
[    0.005741] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.006983] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.008123] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.008276] smp: Brought up 1 node, 4 CPUs
[    0.008292] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[    0.008301] CPU: All CPU(s) started in HYP mode.
[    0.008310] CPU: Virtualization extensions available.
[    0.009241] devtmpfs: initialized
[    0.025560] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4
[    0.025814] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.025840] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.029069] pinctrl core: initialized pinctrl subsystem
[    0.030243] NET: Registered protocol family 16
[    0.034331] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[    0.039085] audit: initializing netlink subsys (disabled)
[    0.039351] audit: type=2000 audit(0.030:1): state=initialized audit_enabled=0 res=1
[    0.040916] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.040927] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.041136] Serial: AMBA PL011 UART driver
[    0.043067] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[    0.060084] raspberrypi-firmware soc:firmware: Attached to firmware from 2020-11-30 22:13, variant start
[    0.070097] raspberrypi-firmware soc:firmware: Firmware hash is ab1181cc0cb6df52bfae3b1d3fef0ce7c325166c
[    0.122004] bcm2835-dma 3f007000.dma: DMA legacy API manager, dmachans=0x1
[    0.124140] SCSI subsystem initialized
[    0.124392] usbcore: registered new interface driver usbfs
[    0.124453] usbcore: registered new interface driver hub
[    0.124588] usbcore: registered new device driver usb
[    0.126549] clocksource: Switched to clocksource arch_sys_counter
[    1.385926] VFS: Disk quotas dquot_6.6.0
[    1.386034] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.386222] FS-Cache: Loaded
[    1.386485] CacheFiles: Loaded
[    1.397741] thermal_sys: Registered thermal governor 'step_wise'
[    1.398119] NET: Registered protocol family 2
[    1.399072] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[    1.399115] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    1.399230] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    1.399419] TCP: Hash tables configured (established 8192 bind 8192)
[    1.399573] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.399626] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.399911] NET: Registered protocol family 1
[    1.400600] RPC: Registered named UNIX socket transport module.
[    1.400610] RPC: Registered udp transport module.
[    1.400619] RPC: Registered tcp transport module.
[    1.400629] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.402401] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available
[    1.405678] Initialise system trusted keyrings
[    1.405914] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[    1.417499] FS-Cache: Netfs 'nfs' registered for caching
[    1.418300] NFS: Registering the id_resolver key type
[    1.418350] Key type id_resolver registered
[    1.418360] Key type id_legacy registered
[    1.418381] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.419656] Key type asymmetric registered
[    1.419668] Asymmetric key parser 'x509' registered
[    1.419729] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    1.419741] io scheduler mq-deadline registered
[    1.419752] io scheduler kyber registered
[    1.424308] bcm2708_fb soc:fb: FB found 1 display(s)
[    1.458019] Console: switching to colour frame buffer device 240x67
[    1.493398] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 1920x1080
[    1.496965] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[    1.499438] bcm2835-rng 3f104000.rng: hwrng registered
[    1.499955] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[    1.500688] vc-sm: Videocore shared memory driver
[    1.501162] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[    1.514146] brd: module loaded
[    1.526844] loop: module loaded
[    1.528296] Loading iSCSI transport class v2.0-870.
[    1.529166] libphy: Fixed MDIO Bus: probed
[    1.529277] usbcore: registered new interface driver lan78xx
[    1.529339] usbcore: registered new interface driver smsc95xx
[    1.529362] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    2.257547] Core Release: 2.80a
[    2.257572] Setting default values for core params
[    2.257599] Finished setting default values for core params
[    2.458011] Using Buffer DMA mode
[    2.458022] Periodic Transfer Interrupt Enhancement - disabled
[    2.458031] Multiprocessor Interrupt Enhancement - disabled
[    2.458042] OTG VER PARAM: 0, OTG VER FLAG: 0
[    2.458069] Dedicated Tx FIFOs mode
[    2.458761] WARN::dwc_otg_hcd_init:1074: FIQ DMA bounce buffers: virt = b7504000 dma = 0xf7504000 len=9024
[    2.458787] FIQ FSM acceleration enabled for :
               Non-periodic Split Transactions
               Periodic Split Transactions
               High-Speed Isochronous Endpoints
               Interrupt/Control Split Transaction hack enabled
[    2.458798] dwc_otg: Microframe scheduler enabled
[    2.458858] WARN::hcd_init_fiq:457: FIQ on core 1
[    2.458868] WARN::hcd_init_fiq:458: FIQ ASM at 8070b948 length 36
[    2.458878] WARN::hcd_init_fiq:497: MPHI regs_base at bb810000
[    2.458898] dwc_otg 3f980000.usb: DWC OTG Controller
[    2.458934] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[    2.458979] dwc_otg 3f980000.usb: irq 56, io mem 0x00000000
[    2.459029] Init: Port Power? op_state=1
[    2.459038] Init: Power Port (0)
[    2.459410] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[    2.459425] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.459439] usb usb1: Product: DWC OTG Controller
[    2.459452] usb usb1: Manufacturer: Linux 5.4.79-v7+ dwc_otg_hcd
[    2.459465] usb usb1: SerialNumber: 3f980000.usb
[    2.460171] hub 1-0:1.0: USB hub found
[    2.460236] hub 1-0:1.0: 1 port detected
[    2.461030] dwc_otg: FIQ enabled
[    2.461040] dwc_otg: NAK holdoff enabled
[    2.461049] dwc_otg: FIQ split-transaction FSM enabled
[    2.461064] Module dwc_common_port init
[    2.461423] usbcore: registered new interface driver usb-storage
[    2.461626] mousedev: PS/2 mouse device common for all mice
[    2.462821] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[    2.465496] sdhci: Secure Digital Host Controller Interface driver
[    2.465505] sdhci: Copyright(c) Pierre Ossman
[    2.466110] mmc-bcm2835 3f300000.mmcnr: could not get clk, deferring probe
[    2.466834] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[    2.467076] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.468839] ledtrig-cpu: registered to indicate activity on CPUs
[    2.469212] hidraw: raw HID events driver (C) Jiri Kosina
[    2.469381] usbcore: registered new interface driver usbhid
[    2.469390] usbhid: USB HID core driver
[    2.470412] vchiq: vchiq_init_state: slot_zero = (ptrval)
[    2.472115] [vc_sm_connected_init]: start
[    2.480391] [vc_sm_connected_init]: end - returning 0
[    2.482423] Initializing XFRM netlink socket
[    2.482461] NET: Registered protocol family 17
[    2.482610] Key type dns_resolver registered
[    2.483362] Registering SWP/SWPB emulation handler
[    2.483681] registered taskstats version 1
[    2.483703] Loading compiled-in X.509 certificates
[    2.484265] Key type ._fscrypt registered
[    2.484277] Key type .fscrypt registered
[    2.495075] uart-pl011 3f201000.serial: cts_event_workaround enabled
[    2.495174] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[    2.497757] printk: console [ttyS0] disabled
[    2.497836] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 50000000) is a 16550
[    2.497904] printk: console [ttyS0] enabled
[    2.498646] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[    2.500179] mmc-bcm2835 3f300000.mmcnr: mmc_debug:0 mmc_debug2:0
[    2.500192] mmc-bcm2835 3f300000.mmcnr: DMA channel allocated
[    2.526823] sdhost: log_buf @ (ptrval) (f7507000)
[    2.566752] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    2.568403] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    2.570047] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    2.572995] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    2.574791] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[    2.577517] of_cfs_init
[    2.577811] of_cfs_init: OK
[    2.578755] Waiting for root device PARTUUID=987c9eea-02...
[    2.639764] random: fast init done
[    2.659716] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.664652] mmc0: new high speed SDHC card at address aaaa
[    2.665760] mmcblk0: mmc0:aaaa SL32G 28.8 GiB
[    2.668732]  mmcblk0: p1 p2
[    2.676780] Indeed it is in host mode hprt0 = 00021501
[    2.710913] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    2.711006] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    2.712081] devtmpfs: mounted
[    2.738592] Freeing unused kernel memory: 1024K
[    2.755788] mmc1: new high speed SDIO card at address 0001
[    2.776991] Run /sbin/init as init process
[    2.886624] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    2.886803] Indeed it is in host mode hprt0 = 00001101
[    3.127011] usb 1-1: New USB device found, idVendor=0424, idProduct=9514, bcdDevice= 2.00
[    3.127032] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.127788] hub 1-1:1.0: USB hub found
[    3.127905] hub 1-1:1.0: 5 ports detected
[    3.426962] systemd[1]: System time before build time, advancing clock.
[    3.446619] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    3.577094] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00, bcdDevice= 2.00
[    3.577116] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.579951] smsc95xx v1.0.6
[    3.590353] NET: Registered protocol family 10
[    3.591810] Segment Routing with IPv6
[    3.622134] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[    3.623167] systemd[1]: Detected architecture arm.
[    3.681420] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:40:07:08
[    3.690388] systemd[1]: Set hostname to <G15T58>.
[    3.776780] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    3.909937] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[    3.909979] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[    3.910005] usb 1-1.2: Product: USB Serial
[    4.006670] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
[    4.149491] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice= 7.02
[    4.149512] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    4.149526] usb 1-1.3: Product: USB2.0 Hub
[    4.150406] hub 1-1.3:1.0: USB hub found
[    4.150721] hub 1-1.3:1.0: 4 ports detected
[    4.466636] usb 1-1.3.1: new low-speed USB device number 6 using dwc_otg
[    4.615437] usb 1-1.3.1: New USB device found, idVendor=1c4f, idProduct=0016, bcdDevice= 1.10
[    4.615458] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    4.615475] usb 1-1.3.1: Product: USB Keyboard
[    4.615488] usb 1-1.3.1: Manufacturer: SIGMACHIP
[    4.627921] input: SIGMACHIP USB Keyboard as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/0003:1C4F:0016.0001/input/input0
[    4.697450] hid-generic 0003:1C4F:0016.0001: input,hidraw0: USB HID v1.10 Keyboard [SIGMACHIP USB Keyboard] on usb-3f980000.usb-1.3.1/input0
[    4.707448] input: SIGMACHIP USB Keyboard Consumer Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/0003:1C4F:0016.0002/input/input1
[    4.769750] random: systemd: uninitialized urandom read (16 bytes read)
[    4.777179] input: SIGMACHIP USB Keyboard System Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/0003:1C4F:0016.0002/input/input2
[    4.777504] hid-generic 0003:1C4F:0016.0002: input,hidraw1: USB HID v1.10 Device [SIGMACHIP USB Keyboard] on usb-3f980000.usb-1.3.1/input1
[    4.786114] random: systemd: uninitialized urandom read (16 bytes read)
[    4.786752] systemd[1]: Listening on initctl Compatibility Named Pipe.
[    4.787451] random: systemd: uninitialized urandom read (16 bytes read)
[    4.788204] systemd[1]: Listening on Syslog Socket.
[    4.791844] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[    4.800237] systemd[1]: Listening on fsck to fsckd communication Socket.
[    4.801117] systemd[1]: Listening on Journal Socket (/dev/log).
[    4.809187] systemd[1]: Listening on udev Kernel Socket.
[    4.810660] systemd[1]: Created slice User and Session Slice.
[    4.877406] usb 1-1.3.2: new low-speed USB device number 7 using dwc_otg
[    4.953762] i2c /dev entries driver
[    5.038721] usb 1-1.3.2: New USB device found, idVendor=0000, idProduct=3825, bcdDevice= 1.00
[    5.038743] usb 1-1.3.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    5.038757] usb 1-1.3.2: Product:  USB OPTICAL MOUSE
[    5.050768] input:  USB OPTICAL MOUSE as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:0000:3825.0003/input/input3
[    5.051491] hid-generic 0003:0000:3825.0003: input,hidraw2: USB HID v1.11 Mouse [ USB OPTICAL MOUSE] on usb-3f980000.usb-1.3.2/input0
[    5.589578] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    5.714261] systemd-journald[105]: Received request to flush runtime journal from PID 1
[    7.189756] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[    7.194366] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[    7.194390] [vc_sm_connected_init]: start
[    7.196262] [vc_sm_connected_init]: installed successfully
[    7.200279] mc: Linux media interface: v0.10
[    7.278025] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[    7.281743] videodev: Linux video capture interface: v2.00
[    7.286218] bcm2835_audio bcm2835_audio: card created with 4 channels
[    7.312290] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    7.315137] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    7.318522] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    7.322153] bcm2835_audio bcm2835_audio: card created with 4 channels
[    7.335182] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[    7.336170] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[    7.369806] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[    7.398500] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
[    7.399897] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
[    7.400358] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
[    7.400763] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
[    7.400796] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
[    7.400818] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[    7.400836] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[    7.400854] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[    7.401093] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
[    7.405594] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[    7.405679] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[    7.414611] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[    7.414665] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[    7.421301] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[    7.421352] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[    7.895811] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    8.061406] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    8.192861] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[    8.202044] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[    8.202392] usbcore: registered new interface driver brcmfmac
[    8.239344] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt failed with error -2
[    8.260898] usbcore: registered new interface driver usbserial_generic
[    8.260975] usbserial: USB Serial support registered for generic
[    8.268404] usbcore: registered new interface driver ch341
[    8.269533] usbserial: USB Serial support registered for ch341-uart
[    8.269689] ch341 1-1.2:1.0: ch341-uart converter detected
[    8.278798] usb 1-1.2: ch341-uart converter now attached to ttyUSB0
[    8.454295] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[    8.454474] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[    8.455429] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 22 2019 01:59:28 version 7.45.98.94 (r723000 CY) FWID 01-3b33decd
[   10.169880] random: crng init done
[   10.169897] random: 7 urandom warning(s) missed due to ratelimiting
[   10.318187] uart-pl011 3f201000.serial: no DMA platform data
[   10.863796] 8021q: 802.1Q VLAN Support v1.8
[   11.138066] Adding 102396k swap on /var/swap.  Priority:-2 extents:1 across:102396k SSFS
[   11.458726] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[   12.019479] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[   13.534252] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   13.537221] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   14.616920] warning: process `colord-sane' used the deprecated sysctl system call with 8.1.2.
[   14.880723] Bluetooth: Core ver 2.22
[   14.881024] NET: Registered protocol family 31
[   14.881056] Bluetooth: HCI device and connection manager initialized
[   14.887244] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.eth0.retrans_time - use net.ipv6.neigh.eth0.retrans_time_ms instead
[   14.897966] Bluetooth: HCI socket layer initialized
[   14.897981] Bluetooth: L2CAP socket layer initialized
[   14.898013] Bluetooth: SCO socket layer initialized
[   14.908907] Bluetooth: HCI UART driver ver 2.3
[   14.908919] Bluetooth: HCI UART protocol H4 registered
[   14.909129] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   14.911549] Bluetooth: HCI UART protocol Broadcom registered
[   15.249801] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   15.249811] Bluetooth: BNEP filters: protocol multicast
[   15.249828] Bluetooth: BNEP socket layer initialized
[   17.356691] Bluetooth: hci0: command 0x0c56 tx timeout
[   17.751067] fuse: init (API version 7.31)
[   19.796330] Bluetooth: RFCOMM TTY layer initialized
[   19.796381] Bluetooth: RFCOMM socket layer initialized
[   19.796418] Bluetooth: RFCOMM ver 1.11
[  454.967744] usb 1-1.3.4: new full-speed USB device number 8 using dwc_otg
[  455.387757] usb 1-1.3.4: new high-speed USB device number 9 using dwc_otg
[  455.519098] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  455.519145] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  455.519159] usb 1-1.3.4: Product: Mass Storage Device
[  455.519172] usb 1-1.3.4: Manufacturer: Generic
[  455.519185] usb 1-1.3.4: SerialNumber: 125C20100726
[  455.520341] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  455.520972] scsi host0: usb-storage 1-1.3.4:1.0
[  455.599484] usbcore: registered new interface driver uas
[  456.558776] scsi 0:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[  456.562397] sd 0:0:0:0: [sda] 32372736 512-byte logical blocks: (16.6 GB/15.4 GiB)
[  456.563008] sd 0:0:0:0: [sda] Write Protect is off
[  456.563031] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[  456.563764] sd 0:0:0:0: [sda] No Caching mode page found
[  456.563781] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  456.591953] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  456.631424]  sda: sda1 sda2
[  456.635120] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  457.325456] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[  457.366506] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[  457.445971] dwc_otg: DEVICE:009 : update_urb_state_xfer_comp:751:trimming xfer length
[  457.537801] usb 1-1.3.4: reset high-speed USB device number 9 using dwc_otg
[  457.678375] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[  457.678402] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 20 29 00 00 80 00
[  457.678419] blk_update_request: I/O error, dev sda, sector 8233 op 0x0:(READ) flags 0x84700 phys_seg 128 prio class 0
[  457.777757] usb 1-1.3.4: reset high-speed USB device number 9 using dwc_otg
[  524.853299] usb 1-1.3.4: USB disconnect, device number 9
[  525.307980] usb 1-1.3.4: new high-speed USB device number 10 using dwc_otg
[  525.438997] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  525.439011] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  525.439019] usb 1-1.3.4: Product: Mass Storage Device
[  525.439026] usb 1-1.3.4: Manufacturer: Generic
[  525.439032] usb 1-1.3.4: SerialNumber: 125C20100726
[  525.440454] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  525.441596] scsi host0: usb-storage 1-1.3.4:1.0
[  526.135140] usb 1-1.3.4: USB disconnect, device number 10
[  526.427980] usb 1-1.3.4: new high-speed USB device number 11 using dwc_otg
[  526.558993] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  526.559005] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  526.559012] usb 1-1.3.4: Product: Mass Storage Device
[  526.559019] usb 1-1.3.4: Manufacturer: Generic
[  526.559025] usb 1-1.3.4: SerialNumber: 125C20100726
[  526.559685] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  526.560562] scsi host0: usb-storage 1-1.3.4:1.0
[  526.905313] usb 1-1.3.4: USB disconnect, device number 11
[  528.008665] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  528.918676] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  528.918995] usb 1-1.3-port4: attempt power cycle
[  530.168853] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  530.268069] usb 1-1.3.4: new high-speed USB device number 15 using dwc_otg
[  530.299555] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  530.299578] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  530.299593] usb 1-1.3.4: Product: Mass Storage Device
[  530.299623] usb 1-1.3.4: Manufacturer: Generic
[  530.299637] usb 1-1.3.4: SerialNumber: 125C20100726
[  530.300663] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  530.302075] scsi host0: usb-storage 1-1.3.4:1.0
[  530.457129] usb 1-1.3.4: USB disconnect, device number 15
[  531.038103] usb 1-1.3.4: new high-speed USB device number 16 using dwc_otg
[  531.169427] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  531.169448] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  531.169462] usb 1-1.3.4: Product: Mass Storage Device
[  531.169489] usb 1-1.3.4: Manufacturer: Generic
[  531.169503] usb 1-1.3.4: SerialNumber: 125C20100726
[  531.170517] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  531.173614] scsi host0: usb-storage 1-1.3.4:1.0
[  531.483172] usb 1-1.3.4: USB disconnect, device number 16
[  531.818055] usb 1-1.3.4: new high-speed USB device number 17 using dwc_otg
[  531.949126] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  531.949140] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  531.949148] usb 1-1.3.4: Product: Mass Storage Device
[  531.949155] usb 1-1.3.4: Manufacturer: Generic
[  531.949163] usb 1-1.3.4: SerialNumber: 125C20100726
[  531.949801] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  531.950461] scsi host0: usb-storage 1-1.3.4:1.0
[  532.519150] usb 1-1.3.4: USB disconnect, device number 17
[  532.818147] usb 1-1.3.4: new high-speed USB device number 18 using dwc_otg
[  533.758715] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  534.668795] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  534.669131] usb 1-1.3-port4: attempt power cycle
[  535.918788] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  536.828927] usb 1-1.3-port4: Cannot enable. Maybe the USB cable is bad?
[  536.829262] usb 1-1.3-port4: unable to enumerate USB device
[  610.089008] usb 1-1.3.4: new full-speed USB device number 22 using dwc_otg
[  610.508994] usb 1-1.3.4: new high-speed USB device number 23 using dwc_otg
[  610.640337] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  610.640359] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  610.640434] usb 1-1.3.4: Product: Mass Storage Device
[  610.640448] usb 1-1.3.4: Manufacturer: Generic
[  610.640461] usb 1-1.3.4: SerialNumber: 125C20100726
[  610.641521] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  610.645970] scsi host0: usb-storage 1-1.3.4:1.0
[  611.680041] scsi 0:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[  611.682153] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  611.682379] sd 0:0:0:0: [sda] 32372736 512-byte logical blocks: (16.6 GB/15.4 GiB)
[  611.689154] sd 0:0:0:0: [sda] Write Protect is off
[  611.689179] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[  611.689638] sd 0:0:0:0: [sda] No Caching mode page found
[  611.689655] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  611.762419]  sda: sda1 sda2
[  611.765279] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  612.431411] EXT4-fs (sda2): recovery complete
[  612.431435] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[  612.450322] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[  684.031827] usb 1-1.3.4: USB disconnect, device number 23
[  684.070268] blk_update_request: I/O error, dev sda, sector 532480 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[  684.070295] Buffer I/O error on dev sda2, logical block 0, lost async page write
[  684.070354] blk_update_request: I/O error, dev sda, sector 8922072 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[  684.070367] Buffer I/O error on dev sda2, logical block 1048699, lost async page write
[  684.070506] blk_update_request: I/O error, dev sda, sector 8923232 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[  684.070519] Buffer I/O error on dev sda2, logical block 1048844, lost async page write
[  684.070561] blk_update_request: I/O error, dev sda, sector 9064624 op 0x1:(WRITE) flags 0x3000 phys_seg 2 prio class 0
[  684.070574] Buffer I/O error on dev sda2, logical block 1066518, lost async page write
[  684.070596] Buffer I/O error on dev sda2, logical block 1066519, lost async page write
[  684.070667] blk_update_request: I/O error, dev sda, sector 9064784 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[  684.070679] Buffer I/O error on dev sda2, logical block 1066538, lost async page write
[  684.091142] JBD2: Error while async write back metadata bh 0.
[  684.091153] Aborting journal on device sda2-8.
[  684.091287] blk_update_request: I/O error, dev sda, sector 3678208 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[  684.091307] Buffer I/O error on dev sda2, logical block 393216, lost sync page write
[  684.091343] JBD2: Error -5 detected when updating journal superblock for sda2-8.
[  684.099349] JBD2: Error while async write back metadata bh 1048699.
[  684.100350] JBD2: Error while async write back metadata bh 1048844.
[  684.101480] JBD2: Error while async write back metadata bh 1066518.
[  684.101510] JBD2: Error while async write back metadata bh 1066519.
[  684.101597] JBD2: Error while async write back metadata bh 1066538.
[  818.174743] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 6
[  819.120775] usb 1-1.3.1: reset low-speed USB device number 6 using dwc_otg
[  820.920769] usb 1-1.3.4: new full-speed USB device number 24 using dwc_otg
[  821.340722] usb 1-1.3.4: new high-speed USB device number 25 using dwc_otg
[  821.471747] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[  821.471759] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[  821.471766] usb 1-1.3.4: Product: Mass Storage Device
[  821.471772] usb 1-1.3.4: Manufacturer: Generic
[  821.471779] usb 1-1.3.4: SerialNumber: 125C20100726
[  821.472435] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[  821.474694] scsi host0: usb-storage 1-1.3.4:1.0
[  822.482531] scsi 0:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[  822.485069] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  822.490913] sd 0:0:0:0: [sda] 32372736 512-byte logical blocks: (16.6 GB/15.4 GiB)
[  822.492684] sd 0:0:0:0: [sda] Write Protect is off
[  822.492700] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[  822.493034] sd 0:0:0:0: [sda] No Caching mode page found
[  822.493043] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  822.553985]  sda: sda1 sda2
[  822.556616] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  823.625544] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[  823.663639] EXT4-fs (sda2): recovery complete
[  823.670830] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[ 1155.253315] usb 1-1.3.4: USB disconnect, device number 25
[ 1155.728389] usb 1-1.3.4: new high-speed USB device number 26 using dwc_otg
[ 1155.859677] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[ 1155.859699] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 1155.859713] usb 1-1.3.4: Product: Mass Storage Device
[ 1155.859727] usb 1-1.3.4: Manufacturer: Generic
[ 1155.859741] usb 1-1.3.4: SerialNumber: 125C20100726
[ 1155.860771] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[ 1155.864766] scsi host0: usb-storage 1-1.3.4:1.0
[ 1156.023123] usb 1-1.3.4: USB disconnect, device number 26
[ 1156.358292] usb 1-1.3.4: new high-speed USB device number 27 using dwc_otg
[ 1156.489257] usb 1-1.3.4: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
[ 1156.489270] usb 1-1.3.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 1156.489278] usb 1-1.3.4: Product: Mass Storage Device
[ 1156.489284] usb 1-1.3.4: Manufacturer: Generic
[ 1156.489291] usb 1-1.3.4: SerialNumber: 125C20100726
[ 1156.489935] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected
[ 1156.490348] scsi host0: usb-storage 1-1.3.4:1.0
[ 1156.716471] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 3
[ 1157.218381] usb 1-1.3.1: reset low-speed USB device number 6 using dwc_otg
[ 1158.290678] usb 1-1.3.4: USB disconnect, device number 27
[ 1158.578380] usb 1-1.3.1: reset low-speed USB device number 6 using dwc_otg
[ 2412.392034] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 2412.392147] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 2412.564602] usb 1-1.2: USB disconnect, device number 4
[ 2412.565179] usb 1-1.2: failed to send control message: -19
[ 2412.565825] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 2412.565927] ch341 1-1.2:1.0: device disconnected
[ 2669.120463] usb 1-1.2: new full-speed USB device number 28 using dwc_otg
[ 2669.253692] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 2669.253715] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 2669.253729] usb 1-1.2: Product: USB Serial
[ 2669.254936] ch341 1-1.2:1.0: ch341-uart converter detected
[ 2669.257292] usb 1-1.2: ch341-uart converter now attached to ttyUSB0
[25120.357619] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[25120.357722] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[25120.536679] usb 1-1.2: USB disconnect, device number 28
[25120.537204] usb 1-1.2: failed to send control message: -19
[25120.537886] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[25120.537997] ch341 1-1.2:1.0: device disconnected
[25340.998862] usb 1-1.2: new full-speed USB device number 29 using dwc_otg
[25341.132005] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[25341.132026] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[25341.132040] usb 1-1.2: Product: USB Serial
[25341.133165] ch341 1-1.2:1.0: ch341-uart converter detected
[25341.135675] usb 1-1.2: ch341-uart converter now attached to ttyUSB0
pi@G15T58:~ $

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Vorhand am 11 Mai 2021, 18:35:39
Hier die Anworten für :

pi@G15T58:~ $ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 2: Dev 29, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
        |__ Port 3: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 1: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 2: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
pi@G15T58:~ $ ls -la /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60 Mai 11 18:24 .
drwxr-xr-x 4 root root 80 Mai 11 18:24 ..
lrwxrwxrwx 1 root root 13 Mai 11 18:24 usb-1a86_USB_Serial-if00-port0 -> ../../ttyUSB0
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Mai 2021, 19:40:48
Hallo,

ttyUSB0 scheint zu stimmen.
Wenn gar keine Antwort kommt, kann das aber immer noch viele Ursachen haben.
Falsche serielle Einstellungen (Bps, Parity), falsche Verkabelung / Anschluss, falsche Modbus-Id oder auch einfach ein defekter Adapter.
Da hilft nur ausprobieren.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Vorhand am 15 Mai 2021, 17:41:27
Jetzt geht's. In der BrauchwasserWärmePumpe DHW300 war der Modus auf PVO anstatt auf BMS eingestellt. Ich kenne nicht die Bedeutung der Modi - hab's einfach umgestellt.
Alle readings waren sofort da. Ich vermute, dass der Modus PVO für die Dimplex Box gedacht ist, welche den PV-Überschuss feststellt.
Wer hat eigentlich das Modul ModbusDHW300 erstellt? Ich hatte es nur über die Beiträge von stolus entdeckt. Jedenfalls vielen Dank.
Grüße Vorhand
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 17 Mai 2021, 09:41:04
Hallo Stefan,

gibt es eine Möglichkeit wenn man ein eigenes modul hat, das der set createAttrsFromParseInfo   ausgeblendet wird ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Init am 29 Mai 2021, 10:52:41
Hallo zusammen,

seit ca. 4 Wochen habe ich eine Brilix Wärmepumpe (XHPFD PX140) und bin mit der App total unzufrieden.
Unabhängig von der schlechten APP war es eh mein Wunsch, die Wärmepumpe in FHEM einzubinden.

Die Einbindung von meinem E3DC Speicher über modbus hat auch wunderbar geklappt.

Laut Anleitung kann ich die WP mittels Parameter P17 auf modbus umstellen.

Aber viel mehr Informationen zum Thema modbus finde ich von der Pumpe leider nirgends :-(

Die einstellbaren Werte aus der Anleitung sind im Anhang.

Egal ob ich P17 auf WIFI oder modbus eingestellt habe, ich kann mit meinem Portscanner keinen offenen Port entdecken, obwohl die Pumpe via App erreichbar ist.
Auch ein Ping funktioniert.

Leider scheitere ich natürlich nun bei der Einbindung in FHEM.

Ich habe Folgendes analog zum Speicher definiert:

defmod BrilixXHPFD ModbusAttr 9 20 172.16.0.70:502 TCP

Habe schon versucht, über den Händler Informationen zu Register, Port, ggf. separates Kabel usw. zu erhalten, doch leider ohne Erfolg :(
Der Support reagiert weder auf meine Anfrage noch auf deine Anfrage des Händlers.

Hat jemand eine Idee, wie ich an das Problem herangehen kann?

Würde mich riesig über Antworten/Ideen freuen.

Viele Grüße
Marc
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Heiner am 30 Mai 2021, 09:51:35
Hi Init,

wenn ich das richtig sehe kannst Du an der Brilix (hab die gleiche bestellt, ist aber noch nicht geliefert) zwischen modbus und WIFI wählen. Da die Brilix das WIFI Modul verbaut hat wir d das Eingangssignal zum WIFI Modul auch entsprechend stehen müssen.
Da ist vermutlich ein serielles Signal das dann ins WIFI Modul geht.

Kannst du direkt per WIFI auf die IP Adresse per Browser gehen, ist da eine Webseite? Ich bin sicher das man die irgendwie auslesen koennte, das hat dann aber nix mehr mit modbus zu tun und sollte in einen separaten Thread.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Init am 30 Mai 2021, 15:26:31
Hallo Heiner,

habe "wunschgemäß" einen separaten Thread geschrieben.

Denke es sollte weiterhin ein Modbus-Thema bleiben, da ich über den Browser auch keine Informationen erhalte.

Hier der neue Thread: https://forum.fhem.de/index.php/topic,121375.0.html

Habe noch herausgefunden, dass ich in Parameter P15 einen 4 stelligen HEX-Code vergeben kann. Aber laut Anleteitung ist dies der Modellcode im Modbus. Aktuell steht dieser Wert auf 0000.

Vielleicht hat dazu ja jemand eine Idee. Sollten wir dann aber unter dem neuen Thread verfolgen.

Viele Grüße
Marc
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: JF Mennedy am 01 Juni 2021, 15:11:58
Hallo,

ich versuche von meinem Hausasnchluss-Stromzähler die aktuelle Leistung darzustellen. Das funktioniert soweit auch alles ganz schön, bis die Leistung negativ wird (PV-Anlage).

2021.06.01 13:07:49.803 5: ADFweb_Hausanschluss: ParseDataString called from HandleResponse with data hex fff911e6, type h, adr 22038, op read,
2021.06.01 13:07:49.804 5: ADFweb_Hausanschluss: SplitDataString called from ParseDataString with data hex fff911e6, type h, adr 22038, valuesLen 2, op read,
2021.06.01 13:07:49.804 5: ADFweb_Hausanschluss: CreateDataObjects called from ParseDataString with objList h22038,
2021.06.01 13:07:49.805 5: ADFweb_Hausanschluss: CreateDataObjects sortedList h22038,
2021.06.01 13:07:49.805 5: ADFweb_Hausanschluss: CreateDataObjects unpacked fff911e6 with N to 4294513126,
2021.06.01 13:07:49.805 5: ADFweb_Hausanschluss: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val * 1 to 4294513126,
2021.06.01 13:07:49.806 5: ADFweb_Hausanschluss: FormatVal for CreateDataObjects formats 4294513126 with format %.2f, result is 4294513126.00,
2021.06.01 13:07:49.806 4: ADFweb_Hausanschluss: CreateDataObjects assigns value 4294513126.00 to 3-PHASE_SYSTEM_ACTIVE_POWER_Watt,


Jetzt bin ich inzischen soweit, dass wenn die Werte negativ sind und ich 4294967295 (0x ffff ffff) subtrahiere, der richtige Wert dabei herauskommt...

Wenn ich eine positive Leistung habe, z.B 2000 Watt, passt es. Dann wird die 0x0000 07d0 richtig interpretiert...

Ich habe schon mit unpack bereits versucht hier weiterzukommen, aber leider bin ich da auf dem Holzweg... 

Gelöst habe ich es nun mit einer expression

if ($val > 65535){($val-4294967295)/100}else{$val=($val/100)}

Ist das so in Ordnung oder gibt es da eventuell noch einen besseren Ansatz?

Gruss Jan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: JF Mennedy am 01 Juni 2021, 19:06:38
Kleines Update, nachdem der Zähler wieder positiv ist.. 65535 ist leider nicht 0 der Wert.. :-( finde den Fehler...


EDIT: Neuer Denkansatz: ab 0xffff0000 habe ich negative Werte. Das entspricht 4294901760, also die expression angepasst 
if ($val > 4294901760){($val-4294967295)/100}else{$val=($val/100)}

Das scheint jetzt gerade zu klappen :-)

EDIT2: Nicht ab 0xffff0000 habe ich negative Werte, sondern 0xfff00000 -> Das entspricht 4293918720, also die expression nochmals angepasst 
if ($val > 4293918720){($val-4294967295)/100}else{$val=($val/100)}

Ich taste mich dran ;-)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: JF Mennedy am 01 Juni 2021, 20:25:29
Hier noch ein Screenshot der Readings... Wenn es jetzt so läuft bin ich glücklich... Wenn es aber von hinten durch die Brust ist und es eine elegantere Lösung gibt, bin ich für Vor- bzw. Ratschläge dankbar :-)

Falls sich jemand wundert über die Volt. Ich habe ein TT Netz mit 230 V zwischen den Phasen (kein Neutralleiter)... Gibt es tatsächlich noch im hochmodernen europäischen Belgien ;-)

Schönen Abend und viele Grüsse,

Jan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 03 Juni 2021, 16:26:13
probier mal

unpack    s>

das sollte richtig sein
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: JF Mennedy am 03 Juni 2021, 17:04:45
Hi,

ich hatte schon sämtliche unpack Methoden durchprobiert... Mit der expression if ($val > 4293918720){($val-4294967295)/100}else{$val=($val/100)} hab ich die Werte genau richtig...

Gruss Jan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: kurt6908 am 25 Juni 2021, 11:23:50
Hallo,

ich brächte mal Unterstützung, bin am Verzweifeln ...

Ich will meinen EPEver UP3000-M6322 Inverter/Charger per Modbus/RS485 abfragen.

Als Modul verwende ich hier 98_ModbusEPEVER und natürlich diese Modbus-Modul hier.

Als ModBus-Device ist ein DSD Tech USB FTDI FT232RL Konverter im Einsatz.

Aktuell habe ich das Problem, dass keinerlei Werte ausgelesen werden, ich habe zwei Fehlerzustände vom Modbus-Modul:

* RS485 A/B auf USB-Adapter A/B:
Timeout waiting for a modbus response, read buffer empty

* RS485 A/B auf umgedreht auf USB-Adapter B/A:
Timeout waiting for a modbus response, current frame / read buffer: 00

Die Anfragen vom MasterDevice (98_ModbusEPEVER) kommen im Modbus-Modul an.

Adapter ist mit /dev/ttyUSB1@115200 definiert; 98_ModbusEPEVER mit 1 300 und Protokoll RTU

Ich vermute mal es liegt nicht am 98_ModBusEPEVER, sondern eher an einem Timeming-Problem (eventuell Baudrate?) meiner Konfiguration, so dass das Modbus-Modul nichts zurückliefert. Auch da ich im Netz unterschiedlich A/B-Belegungen gefunden habe, bringt mich bei der Lösungsfindung nicht weiter....

Kann mir jemand noch einen Tipp geben, wo der Fehler liegen könnte....

Vielen Dank.

Kurt

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: antonwinden am 25 Juni 2021, 12:34:58
Widerstand am Ende des Kabels zwischen A und B vorhanden?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: kurt6908 am 25 Juni 2021, 20:23:13
Hallo antonwinden,

ZitatWiderstand am Ende des Kabels zwischen A und B vorhanden?

Nein, bei meinem Adapter gibt es nur Schraubanschlüsse für A/B. Ich habe mir nun noch einen Adapter gekauft, bei dem man einen Widerstand zwischen A und B bei Bedarf schalten kann.

Ich glaube ich habe nun alle A/B-Variationen durch. Der RJ45-Anschluss der RS485-Buchse hat

3+4 B
5+6 A
7+8 GND

Im Netz finde ich mindestens 4 verschiedene Variationen welchen Pin ich auf die A/B/GND-Anschlüsse am Adapter legen muss. Egal was ich belege, es kommt immer der TimeOut....

Kurt
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: beejayf am 26 Juni 2021, 21:25:21
Hallo zusammen,

ich bekomme nachdem ich nach Ewigkeiten mein FHEM mal neu gestartet habe folgende Fehlermeldung in meine Logfile:

Undefined subroutine &Modbus::InitializeLD called at ./FHEM/98_ModbusAttr.pm line 46.
Undefined subroutine &Modbus::InitializeLD called at ./FHEM/98_SolarEdge.pm line 779.


Da ich nicht weiß ob der Fehler von Modbus oder einem der beiden Module kommt habe ich das Problem hier und in ähnlicher Form in SorlarEdge Thread gepostet - hoffe das ist okay.

Danke im Voraus für Eure Hinweise!

BeeJayF
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: beejayf am 28 Juni 2021, 17:39:50
So - hab FHEM neu installiert und die fhem.conf wieder hergestellt, alle Module neu installiert - jetzt klappts
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: kurt6908 am 29 Juni 2021, 21:30:29
Hallo antonwinden,

vielen Dank für Deinen Hinweis.

Nach dem dritten Adapter (dem billigesten von allen) und der richtigen Kabelbelegung klappt nun die Kommunikation unter Windows und über Raspbian.

Gruß

Kurt
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: kurt6908 am 01 Juli 2021, 07:21:24
Hallo Stefan,

ich verwende Dein low level Modul mit dem Modul 98_ModbusEPEVER.

Ich verwende hierzu einen seriellen USB-Adapter und das RTU_Protokoll. Der Adapter funktioniert mit der herstellereigenen Sofware ohne Probleme.

Nun habe ich das Problem das im ModBusEPEVER nur drei Readings ausgelesen und angelegt werden.

Ein Verbose 5 auf Deinem Modul und auf ModbusEPEVER schaut bei einem get so aus:


2021.06.30 21:42:06 4: OffGridLoader: get called with BattVoltage (i13082)
2021.06.30 21:42:06 5: OffGridLoader: GetSetChecks with force
2021.06.30 21:42:06 5: OffGridLoader: GetSetChecks returns success
2021.06.30 21:42:06 4: OffGridLoader: DoRequest called from GetLDFn created new request, read buffer empty,
request: id 1, read fc 4 i13082, len 1, master device OffGridLoader, reading BattVoltage (get BattVoltage)
2021.06.30 21:42:06 5: ModBusLine: QueueRequest called from DoRequest with i13082, qlen 0 from master OffGridLoader through io device ModBusLine
2021.06.30 21:42:06 5: ModBusLine: ProcessRequestQueue called from QueueRequest as direct:ModBusLine, qlen 1, force, request: request: id 1, read fc 4 i13082, len 1, master device OffGridLoader, reading BattVoltage (get BattVoltage), queued 0.00 secs ago
2021.06.30 21:42:06 5: ModBusLine: checkDelays clientSwitchDelay is not relevant
2021.06.30 21:42:06 5: ModBusLine: checkDelays commDelay, last communication with same device was 200.575 secs ago, required delay is 0.1
2021.06.30 21:42:06 5: ModBusLine: checkDelays sendDelay, last send to same device was 200.771 secs ago, required delay is 0.1
2021.06.30 21:42:06 5: ModBusLine: checkDelays busDelayRead, last activity on bus was 200.576 secs ago, required delay is 0
2021.06.30 21:42:06 4: ModBusLine: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 0104331a00011f49 via /dev/ttyUSB1@115200, read buffer empty,
request: id 1, read fc 4 i13082, len 1, master device OffGridLoader, reading BattVoltage (get BattVoltage), queued 0.00 secs ago
2021.06.30 21:42:06 5: ModBusLine: Send called from ProcessRequestQueue
2021.06.30 21:42:06 5: SW: 0104331a00011f49
2021.06.30 21:42:06 5: ModBusLine: ReadAnswer called from GetLDFn
2021.06.30 21:42:06 5: ModBusLine: ReadAnswer remaining timeout is 1.99355697631836
2021.06.30 21:42:06 5: ModBusLine: ReadAnswer got: 018402c2c1
2021.06.30 21:42:06 5: ModBusLine: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2021.06.30 21:42:06 4: ModBusLine: ParseFrameStart (RTU, master) extracted id 1, fCode 132 and potential data 02
2021.06.30 21:42:06 5: ModBusLine: HandleResponse called from ReadAnswer
2021.06.30 21:42:06 5: ModBusLine: ParseResponse called from HandleResponse
2021.06.30 21:42:06 5: ModBusLine: CheckChecksum (called from ParseResponse): c2c1 is valid
2021.06.30 21:42:06 4: ModBusLine: HandleResponse got response with error code 84 / 02, illegal data address
2021.06.30 21:42:06 4: ModBusLine: HandleResponse done, current frame / read buffer: 018402c2c1, id 1, fCode 132,
request: id 1, read fc 4 i13082, len 1, master device OffGridLoader, reading BattVoltage (get BattVoltage), queued 0.11 secs ago, sent 0.11 secs ago,
response: id 1, fc 132, error code 02, len 1
2021.06.30 21:42:06 5: ModBusLine: ResetExpect for HandleResponse from response to idle
2021.06.30 21:42:06 5: ModBusLine: DropFrame called from ReadAnswer - drop 018402c2c1


Laut laserrichi liegt es wohl am RTU-Protokoll bzw. an Deinem Modul:

Zitat
Code:

2021.06.30 21:42:06 5: ModBusLine: ReadAnswer got: 018402c2c1
2021.06.30 21:42:06 5: ModBusLine: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2021.06.30 21:42:06 4: ModBusLine: ParseFrameStart (RTU, master) extracted id 1, fCode 132 and potential data 02
2021.06.30 21:42:06 5: ModBusLine: HandleResponse called from ReadAnswer
2021.06.30 21:42:06 5: ModBusLine: ParseResponse called from HandleResponse
2021.06.30 21:42:06 5: ModBusLine: CheckChecksum (called from ParseResponse): c2c1 is valid
2021.06.30 21:42:06 4: ModBusLine: HandleResponse got response with error code 84 / 02, illegal data address

also hier kommt etwas falsches zurück: 018402c2c1

01 = device ID  ist Richtig
84 = function Code... das ist Falsch.... hier müsste eigentlich 04 stehen
02 = zwei bytes  ist wohl auch Richtig
c2c1 ist auch nicht plausibel, das wären ja 498,57V  :-)  bissl viel...

das ist eigentlich ein Fall für StefanStrobel... der kann dazu vieleicht mehr sagen.

Edit: habe gerade bei Modbus Spezifikationen gefunden das es  wohl Function Code in Exception Response ist.

Kannst Du Dir dieses bitte mal anschauen, ich stehe für Tests und andere Log-Auszüge natürlich bereit...

Viele Grüße

Kurt
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 Juli 2021, 18:59:21
Hallo Kurt,

die Kommunikation scheint sauber zu funktionieren, aber Dein Gerät antwortet auf die Anfrage für das Input-Register 13082 mit der Fehlermeldung dass diese Adresse nicht erlaubt ist. Hast Du denn eine Doku für das Gerät und steht da drin, dass diese Register-Nummer korrekt sein sollte?

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: kurt6908 am 01 Juli 2021, 20:14:19
Hallo Stefan,

es handelt sich um einen EPEver UPower Inverter.

Das Modul von laserrichi 98_ModbusEPEVER sollte diesen eigentlich unterstützen. Eine Modbus-Doku habe ich leider nicht, vielleicht laserrichi. Eventuell hat es bei den neuen UPower-Modellen eine Änderung geben, im Netz habe ich z.B. das gefunden:

https://stackoverflow.com/questions/63055446/issue-reading-modbus-registers-from-epever-upower-charger-inverter-using-pymod]https://stackoverflow.com/questions/63055446/issue-reading-modbus-registers-from-epever-upower-charger-inverter-using-pymod]https://stackoverflow.com/questions/63055446/issue-reading-modbus-registers-from-epever-upower-charger-inverter-using-pymod (https://stackoverflow.com/questions/63055446/issue-reading-modbus-registers-from-epever-upower-charger-inverter-using-pymod)

Zitat
You need to change your Address from 0x3100 to 0x3500.

I decompiled the SolarStationSoftware and found out that they changed the Realtime Address to 13568.

Aber wenn ich Dich richtig verstehe, ist es doch eher ein Problem vom 98_ModbusEPEVER?

Ansonsten habe ich nur Dokus über die B-Serie gefunden:

https://www.developpez.net/forums/attachments/p196506d1451307310/systemes/autres-systemes/automation/probleme-com-modbus-pl7-pro/controllerprotocolv2.3.pdf (https://www.developpez.net/forums/attachments/p196506d1451307310/systemes/autres-systemes/automation/probleme-com-modbus-pl7-pro/controllerprotocolv2.3.pdf)

https://www.aggsoft.com/serial-data-logger/tutorials/modbus-data-logging/epever-b-series.htm]https://www.aggsoft.com/serial-data-logger/tutorials/modbus-data-logging/epever-b-series.htm]https://www.aggsoft.com/serial-data-logger/tutorials/modbus-data-logging/epever-b-series.htm (https://www.aggsoft.com/serial-data-logger/tutorials/modbus-data-logging/epever-b-series.htm)

http%3A%2F%2Fwww.solar-elektro.cz%2Fdata%2Fdokumenty%2F1733_modbus_protocol.pdf&usg=AOvVaw2l5P3iHoscUNM1t4jzkCSc]http://http%3A%2F%2Fwww.solar-elektro.cz%2Fdata%2Fdokumenty%2F1733_modbus_protocol.pdf&usg=AOvVaw2l5P3iHoscUNM1t4jzkCSc]http%3A%2F%2Fwww.solar-elektro.cz%2Fdata%2Fdokumenty%2F1733_modbus_protocol.pdf&usg=AOvVaw2l5P3iHoscUNM1t4jzkCSc (http://http%3a%2f%2fwww.solar-elektro.cz%2fdata%2fdokumenty%2f1733_modbus_protocol.pdf&usg=aovvaw2l5p3ihoscunm1t4jzkcsc)

Gruß

Kurt
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 01 Juli 2021, 21:08:06
ah ok jetzt habe ich es auch verstanden, Stefan hat recht, die Exception kommt wenn die Anfrage falsch ist.
Scheinbar hat die Upower Serie andere Abfragen....
Ich habe mal die Doku angefordert, mal sehen was da dann kommt dann wissen wir wohl mehr.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: kurt6908 am 01 Juli 2021, 21:25:01
WOW .... Super, danke Euch !!!

Gruß

Kurt
Titel: Dupline Kanalgenerator mit ModbusAttr auslesen. Unpack immer "a"
Beitrag von: RaKoHe am 07 Juli 2021, 09:14:50
Moin aus dem sonnigen Norden,


Ich möchte meinen Dupline Kanalgenerator DKG20 von der Firma Doepke per Modbus RTU auszulesen.

Ausgelesen wird mit ModbusAttr und einem USB to Serial.

Es werden auch die aktuellen Zustände(0000/0001) gelesen, nur wird dann immer mit unpack "a" aus dem 0001=
ParseObj unpacked 30 with a to 0 hex 30
gemacht.
Wo kommt diese 30 her?

Es ist egal was ich als unpack definiere,hier versuchsweise C
Ich habe auch schon map ohne Erfolg probiert, was aber letzlich das Ziel ist.
0000=Aus 0001=Ein



Anbei die Modbus Beschreibung von Doepke. siehe 3.3.2 auf Seite 15

https://www.doepke.de/uploads/tx_doepkeproducts/bedienungsanleitung/web/doepke_dupline_modbus_man_de.pdf

Vielen Dank für eure Hilfe

P.S.: Das Dupline System entspricht vermutlich dem Carlo Gavazzi Fieldbus.

defmod DUPATTR ModbusAttr 5 15 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@57600,8,N,1
attr DUPATTR userattr dev-d-defPoll dev-d-defUnpack dev-d-read obj-d1584-reading
attr DUPATTR dev-d-defPoll 1
attr DUPATTR dev-d-defUnpack C
attr DUPATTR dev-d-read 02
attr DUPATTR obj-d1584-reading Schreibtischlampeneu
attr DUPATTR room Heizung
attr DUPATTR verbose 5

setstate DUPATTR opened
setstate DUPATTR 2021-06-30 12:18:48 Schreibtischlampe 0
setstate DUPATTR 2021-06-30 14:02:31 Schreibtischlampeneu 0
setstate DUPATTR 2021-06-30 14:02:48 state opened


2021.06.30 14:17:40 4: DUPATTR: ResponseDone request: id 5, fCode 02, type d, adr 1584, len 1 for device DUPATTR reading Schreibtischlampeneu (getUpdate), queued 0.02 secs ago, sent 0.02 secs ago, Current read buffer: 050202000189b8, Id 5, fCode 2, response: id 5, fCode 2, type d, adr 1584, len 1, value 0001
2021.06.30 14:17:40 5: DUPATTR: HandleResponse got 1 readings from ParseObj for DUPATTR
2021.06.30 14:17:40 4: DUPATTR: ParseObj assigns value 0 to Schreibtischlampeneu
2021.06.30 14:17:40 5: DUPATTR: ParseObj unpacked 30 with a to 0 hex 30
2021.06.30 14:17:40 5: DUPATTR: ParseObj ObjInfo for d1584: reading=Schreibtischlampeneu, unpack=a, expr=, format=, map=
2021.06.30 14:17:40 5: DUPATTR: ParseObj shortened coil / input bit string: 0, start adr 1584, valuesLen 1
2021.06.30 14:17:40 5: DUPATTR: ParseObj called with data 0001, type d, adr 1584, valuesLen 1, op read
2021.06.30 14:17:40 5: DUPATTR: HandleResponse now passing to logical device DUPATTR for parsing data
2021.06.30 14:17:40 5: DUPATTR: CheckChecksum (called from HandleResponse): 89b8 is valid
2021.06.30 14:17:40 5: DUPATTR: ParseResponse called from HandleResponse
2021.06.30 14:17:40 5: DUPATTR: HandleResponse called from Read
2021.06.30 14:17:40 4: DUPATTR: ParseFrameStart (RTU) extracted id 5, fCode 2 and data 020001
2021.06.30 14:17:40 5: DUPATTR: read buffer: 050202000189b8
2021.06.30 14:17:40 5: DUPATTR: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2021.06.30 14:17:40 5: SW: 050206300001b8c9
2021.06.30 14:17:40 4: DUPATTR: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 050206300001b8c9 request: id 5, fCode 02, type d, adr 1584, len 1 for device DUPATTR reading Schreibtischlampeneu (getUpdate)


Vielen Dank

Ralf

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 07 Juli 2021, 19:45:53
also a wäre ja hier falsch, das ist : A string with arbitrary binary data, will be null padded

deine Antwort mal zerlegt die du bekommst:

050202000189b8
05 Device ID
02 Function Code
02 zwei Bytes    bingo....
00 01  das ist dein wert
Mit C machst du daraus:  An unsigned char (octet) value

ich würde Vorschlagen nimm mal  defunpack S 
dann sollte es richtig sein
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 Juli 2021, 22:01:41
Hallo Ralf,

Zunächst solltest Du Fhem aktualisieren. Du scheinst ein sehr altes Modul zu verwenden. In der aktuellen Version kommen andere Meldungen und einige Bugs sind behoben.

Für coils und digital inputs verwendet das Modbus-Modul eine spezielle Behandlung, da die Daten immer 0/1 sind und als Folge einzelner Bits gelesen werden. Die werden intern als String von 0/1-Zeichen verarbeitet.

Insbesondere solltest Du gar keinen unpack-Code vorgeben. Der würde bei digital inputs und coils eh ignoriert.
Ebenso kannst Du das Attribut für den function code 2 weglassen. Das ist der Default.

Probier es doch nochmal mit der aktuelle Version und einer vereinfachten Konfiguration und poste dann einen Ausschnitt aus dem Log.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RaKoHe am 08 Juli 2021, 11:32:26
Moin,

danke Laserrichi und Stefan.


Da das Update und weniger Attr kein Erfolg gebracht hat habe ich FHEM auf dem just eingetroffenen pi4 mit einer neuen Karte installiert.
Dann nur DUPATTR definiert.
Leider ohne Erfolg.

defmod DUPATTR ModbusAttr 5 15 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0@57600,8,N,1
attr DUPATTR dev-d-defPoll 1
attr DUPATTR obj-d1584-reading Schreibtischlampeneu
attr DUPATTR room Heizung
attr DUPATTR verbose 2

setstate DUPATTR opened
setstate DUPATTR 2021-07-08 11:26:25 Schreibtischlampeneu 0
setstate DUPATTR 2021-07-08 11:19:48 state opened


2021.07.08 11:16:51 4: DUPATTR: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2021.07.08 11:16:51 4: DUPATTR: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 15.0 sec at 11:17:06.333, interval 15
2021.07.08 11:16:51 5: DUPATTR: CreateUpdateList full object list: d1584
2021.07.08 11:16:51 5: DUPATTR: CreateUpdateList will request d1584 len 1 Schreibtischlampeneu
2021.07.08 11:16:51 4: DUPATTR: CombineUpdateHash objHash keys before combine: d1584
2021.07.08 11:16:51 5: DUPATTR: CombineUpdateHash tries to combine read commands
2021.07.08 11:16:51 5: DUPATTR: CombineUpdateHash keys are now d1584
2021.07.08 11:16:51 4: DUPATTR: GetUpdate will now create requests for d1584 len 1 (Schreibtischlampeneu)
2021.07.08 11:16:51 4: DUPATTR: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1)
2021.07.08 11:16:51 5: DUPATTR: QueueRequest called from DoRequest with d1584, qlen 0 from master DUPATTR through io device DUPATTR
2021.07.08 11:16:51 5: DUPATTR: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2021.07.08 11:16:51 5: DUPATTR: ProcessRequestQueue called from Fhem internal timer as queue:DUPATTR, qlen 1, request: request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:16:51 5: DUPATTR: checkDelays commDelay, last communication with same device was 14.992 secs ago, required delay is 0.1
2021.07.08 11:16:51 5: DUPATTR: checkDelays busDelayRead, last activity on bus was 14.992 secs ago, required delay is 0
2021.07.08 11:16:51 5: DUPATTR: checkDelays sendDelay, last send to same device was 14.999 secs ago, required delay is 0.1
2021.07.08 11:16:51 5: DUPATTR: checkDelays clientSwitchDelay is not relevant
2021.07.08 11:16:51 4: DUPATTR: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 050206300001b8c9 via /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0@57600,8,N,1, read buffer empty,
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:16:51 5: DUPATTR: Send called from ProcessRequestQueue
2021.07.08 11:16:51 5: SW: 050206300001b8c9
2021.07.08 11:16:51 5: DUPATTR: readFn buffer: 050202000189b8
2021.07.08 11:16:51 5: DUPATTR: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2021.07.08 11:16:51 4: DUPATTR: ParseFrameStart (RTU, master) extracted id 5, fCode 2 and potential data 020001
2021.07.08 11:16:51 5: DUPATTR: HandleResponse called from ReadFn
2021.07.08 11:16:51 5: DUPATTR: ParseResponse called from HandleResponse
2021.07.08 11:16:51 5: DUPATTR: CheckChecksum (called from ParseResponse): 89b8 is valid
2021.07.08 11:16:51 5: DUPATTR: now parsing response data objects, master is DUPATTR relay is undefined
2021.07.08 11:16:51 5: DUPATTR: ParseDataString called from HandleResponse with data hex 0001, type d, adr 1584, op read
2021.07.08 11:16:51 5: DUPATTR: SplitDataString called from ParseDataString with data hex 0001, type d, adr 1584, valuesLen 1, op read
2021.07.08 11:16:51 5: DUPATTR: SplitDataString shortened coil / input bit string to 0, start adr 1584, valuesLen 1
2021.07.08 11:16:51 5: DUPATTR: CreateDataObjects called from ParseDataString with objList d1584
2021.07.08 11:16:51 5: DUPATTR: CreateDataObjects sortedList d1584
2021.07.08 11:16:51 5: DUPATTR: CreateDataObjects unpacked 30 with a to 0
2021.07.08 11:16:51 4: DUPATTR: CreateDataObjects assigns value 0 to Schreibtischlampeneu
2021.07.08 11:16:51 5: DUPATTR: ParseDataString created 1 readings
2021.07.08 11:16:51 4: DUPATTR: HandleResponse done, current frame / read buffer: 050202000189b8, id 5, fCode 2,
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 5, fc 2, d1584, len 1, values 0001
2021.07.08 11:16:51 5: DUPATTR: ResetExpect for HandleResponse from response to idle
2021.07.08 11:16:51 5: DUPATTR: DropFrame called from ReadFn - drop 050202000189b8
2021.07.08 11:17:06 4: DUPATTR: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2021.07.08 11:17:06 4: DUPATTR: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 15.0 sec at 11:17:21.336, interval 15
2021.07.08 11:17:06 5: DUPATTR: CreateUpdateList full object list: d1584
2021.07.08 11:17:06 5: DUPATTR: CreateUpdateList will request d1584 len 1 Schreibtischlampeneu
2021.07.08 11:17:06 4: DUPATTR: CombineUpdateHash objHash keys before combine: d1584
2021.07.08 11:17:06 5: DUPATTR: CombineUpdateHash tries to combine read commands
2021.07.08 11:17:06 5: DUPATTR: CombineUpdateHash keys are now d1584
2021.07.08 11:17:06 4: DUPATTR: GetUpdate will now create requests for d1584 len 1 (Schreibtischlampeneu)
2021.07.08 11:17:06 4: DUPATTR: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1)
2021.07.08 11:17:06 5: DUPATTR: QueueRequest called from DoRequest with d1584, qlen 0 from master DUPATTR through io device DUPATTR
2021.07.08 11:17:06 5: DUPATTR: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2021.07.08 11:17:06 5: DUPATTR: ProcessRequestQueue called from Fhem internal timer as queue:DUPATTR, qlen 1, request: request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:17:06 5: DUPATTR: checkDelays sendDelay, last send to same device was 15.003 secs ago, required delay is 0.1
2021.07.08 11:17:06 5: DUPATTR: checkDelays clientSwitchDelay is not relevant
2021.07.08 11:17:06 5: DUPATTR: checkDelays commDelay, last communication with same device was 14.997 secs ago, required delay is 0.1
2021.07.08 11:17:06 5: DUPATTR: checkDelays busDelayRead, last activity on bus was 14.997 secs ago, required delay is 0
2021.07.08 11:17:06 4: DUPATTR: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 050206300001b8c9 via /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0@57600,8,N,1, read buffer empty,
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:17:06 5: DUPATTR: Send called from ProcessRequestQueue
2021.07.08 11:17:06 5: SW: 050206300001b8c9
2021.07.08 11:17:06 5: DUPATTR: readFn buffer: 050202000189b8
2021.07.08 11:17:06 5: DUPATTR: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2021.07.08 11:17:06 4: DUPATTR: ParseFrameStart (RTU, master) extracted id 5, fCode 2 and potential data 020001
2021.07.08 11:17:06 5: DUPATTR: HandleResponse called from ReadFn
2021.07.08 11:17:06 5: DUPATTR: ParseResponse called from HandleResponse
2021.07.08 11:17:06 5: DUPATTR: CheckChecksum (called from ParseResponse): 89b8 is valid
2021.07.08 11:17:06 5: DUPATTR: now parsing response data objects, master is DUPATTR relay is undefined
2021.07.08 11:17:06 5: DUPATTR: ParseDataString called from HandleResponse with data hex 0001, type d, adr 1584, op read
2021.07.08 11:17:06 5: DUPATTR: SplitDataString called from ParseDataString with data hex 0001, type d, adr 1584, valuesLen 1, op read
2021.07.08 11:17:06 5: DUPATTR: SplitDataString shortened coil / input bit string to 0, start adr 1584, valuesLen 1
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects called from ParseDataString with objList d1584
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects sortedList d1584
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects unpacked 30 with a to 0
2021.07.08 11:17:06 4: DUPATTR: CreateDataObjects assigns value 0 to Schreibtischlampeneu
2021.07.08 11:17:06 5: DUPATTR: ParseDataString created 1 readings
2021.07.08 11:17:06 4: DUPATTR: HandleResponse done, current frame / read buffer: 050202000189b8, id 5, fCode 2,
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 5, fc 2, d1584, len 1, values 0001
2021.07.08 11:17:06 5: DUPATTR: ResetExpect for HandleResponse from response to idle


Noch eine Idee??

Vielen Dank

Mit sonnigen Grüßen

Ralf
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 Juli 2021, 18:28:45
Hallo Ralf,

ich denke ich habe das Problem verstanden.
Folgendes erkenne ich im Log:
Zitat
2021.07.08 11:16:51 4: DUPATTR: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 050206300001b8c9 via /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0@57600,8,N,1, read buffer empty,
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:16:51 5: DUPATTR: Send called from ProcessRequestQueue
2021.07.08 11:16:51 5: SW: 050206300001b8c9
Das Modul schickt einen korrekten Request für einen einzelnen Digital Input mit Adresse 1584.

Zitat
2021.07.08 11:17:06 5: DUPATTR: readFn buffer: 050202000189b8
Es kommt eine gültige Antwort vom Device mit zwei Bytes als Daten: 00 01
Das ist schonmal seltsam, denn es war ja nur 1 Input angefragt und der passt in ein einzelnes Byte ...

Zitat
2021.07.08 11:17:06 5: DUPATTR: SplitDataString called from ParseDataString with data hex 0001, type d, adr 1584, valuesLen 1, op read
2021.07.08 11:17:06 5: DUPATTR: SplitDataString shortened coil / input bit string to 0, start adr 1584, valuesLen 1
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects called from ParseDataString with objList d1584
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects sortedList d1584
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects unpacked 30 with a to 0
2021.07.08 11:17:06 4: DUPATTR: CreateDataObjects assigns value 0 to Schreibtischlampeneu

Das Modul geht wie im Modbus-Standard beschrieben davon aus, dass im ersten Byte der angefragte Input steht und kürzt das folgende vermeintlich überflüssige Byte weg.

siehe: MODBUS Application Protocol Specification V1.1b3 Modbus / http://www.modbus.org
Zitat
6.2 02 (0x02) Read Discrete Inputs
This function code is used to read from 1 to 2000 contiguous status of discrete inputs in a
remote device. The Request PDU specifies the starting address, i.e. the address of the first
input specified, and the number of inputs. In the PDU Discrete Inputs are addressed starting
at zero. Therefore Discrete inputs numbered 1-16 are addressed as 0-15.

The discrete inputs in the response message are packed as one input per bit of the data field.
Status is indicated as 1= ON; 0= OFF. The LSB of the first data byte contains the input
addressed in the query. The other inputs follow toward the high order end of this byte, and
from low order to high order in subsequent bytes.

If the returned input quantity is not a multiple of eight, the remaining bits in the final d ata byte
will be padded with zeros (toward the high order end of the byte). The Byte Count field
specifies the quantity of complete bytes of data.

Im Standard ist sogar noch ein Beispiel abgebildet um das zu verdeutlichen.
Zudem habe ich das ganze kurz mit einer anderen Modbus-Implementation verglichen und da kommt auch ein einzelnes Byte als Antwort.

Ich interpretiere das so, dass Doepke hier eine Abweichung vom Modbus-Standard implementiert hat.
In deren Doku auf Seite 13 steht es auch so (mit einem vorangestellten "dummy-Byte") drin, daher ist das nicht einfach ein Bug, sondern eine eigene Protokoll-Variante.
Es würde mich interessieren, wie andere Modbus-Master damit umgehen.

Ich habe schon mehrere Fälle von Standard-Abweichungen im Fhem-Modbus-Modul eingebaut.
Für diesen Fall kann ich das auch als Attribut machen, z.B. "attr DUPATTR broken-fc2 doepke"
und dann wird das erste Byte verworfen oder die Reihenfolge der Bytes vertauscht (da wäre es schön zu wissen, wie das Device antwortet, wenn 10 Eingänge gleichzeitig abgefragt werden...

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RaKoHe am 08 Juli 2021, 18:33:48
Moin Stefan,

das hört sich super an.
Ich habe den ganzen Tag probiert, ohne ein Ergebnis :'(

Ich probiere es gerne aus:-)

Mit sonnigen Grüßen

Ralf
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 Juli 2021, 17:26:41
Hallo Ralf,

hier ist eine neue Version zum Testen, die ein zusätzliches Attribut für diesen Zweck versteht:

attr DUPATTR dev-d-brokenFC2 doepke


probier das doch mal aus und poste das Log. Ich hab ja kein Doepke-Gerät zum Testen.

Gruss
   Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RaKoHe am 09 Juli 2021, 19:57:48
Hallo Stefan,

funktioniert auf Anhieb.
Teste jetzt mehrere Register, Rückmeldung vermutlich erst morgen ;D

Vielen Dank für den super Service!

Ralf
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: claudio am 11 Juli 2021, 03:25:05
This is a personnal message for @StefanStrobel

I post it there at your demand. I hope to be in the right thread.

This post is concerning the abnormaly high cpu usage while polling one modbus device every 1 sec.  Right now, I read 20 registers but the setup is not completed yet. I stopped when I discovered the cpu usage increase. I've tried to read the same registers on the same machine (a raspberry pi 2) not with fhem but with a test program in java (using de.re.easymodbus.modbusclient library and jssc serial library), and a faster poll of 500ms, the cpu usage is way lower, in the range 0.5-1.5% CPU for the process.

Problem is I need to deal with the data in fhem and the I would need to find a way to pass data from this app to fhem... seems pretty ugly but could work. The best would be to have everything in fhem.

Joined are the files you asked,

Thanks you in advance
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Juli 2021, 08:47:24
Hello Claudio,

thanks for posting the files.
The Modbus module has beed designed to be very flexible and allows a lot of generic options which make it cpu intensive.
In addition the Fhem framework and every event in the framework adds to that.
But I will have a close look your scenario and check if there is a way to reduce the cpu load.

regards,
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Juli 2021, 13:58:20
Hello Claudio,

I noticed that you didn't define a polldelay for your objects.
Currently this defaults to 0.5 seconds which probably is a problem in your use case.
Please define something like 0.1 as polldelay for all your objects.
I will make a dev-defPolldelay attribute available in the next release to make this easier.
Until then this would need to be defined individually.
Also to make understanding your problem easier, it would help a lot if you can specify

attr global mseclog 1

and the post another log. Otherwise I can't really see where most of the time is lost in your case.
I've bee trying to simulate it but since I don't have your device, I can only guess some things.

It would also help if you can disable events temporarly to see if the problem really lies in the modbus device or if the frequent events just slow down the fhem platform. Just replace your event-on-change-reading with event-min-interval 600 to see how that changes the load and processing time.

regards,
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: claudio am 12 Juli 2021, 03:19:21
Zitat von: StefanStrobel am 11 Juli 2021, 13:58:20
Hello Claudio,

I noticed that you didn't define a polldelay for your objects.
Currently this defaults to 0.5 seconds which probably is a problem in your use case.
Please define something like 0.1 as polldelay for all your objects.
I will make a dev-defPolldelay attribute available in the next release to make this easier.
Until then this would need to be defined individually.
Also to make understanding your problem easier, it would help a lot if you can specify

attr global mseclog 1

and the post another log. Otherwise I can't really see where most of the time is lost in your case.
I've bee trying to simulate it but since I don't have your device, I can only guess some things.

It would also help if you can disable events temporarly to see if the problem really lies in the modbus device or if the frequent events just slow down the fhem platform. Just replace your event-on-change-reading with event-min-interval 600 to see how that changes the load and processing time.

regards,
   Stefan

thanks Stefan

I tried what you suggested, setting polldelay on all objects : it doesn't make things better, quiet the opposite, I see between 1-3% CPU increase
attr Satel_ACU220 obj-h0-polldelay 0.1
attr Satel_ACU220 obj-h1-polldelay 0.1
etc...

My observations:
- if I remove event-on-change-reading and set event-min-interval for all ModbusAttr objects: (.*:600) I dont see any gain in cpu %, the cpu usage remain the same

- the suppression of associated notify has no effect on cpu usage

- if I use a modbus proxy like https://github.com/3cky/mbusd which convert modbus serial to tcp and setup fhem to use an ip to connect to modbus, DEF : 5 1 127.0.0.1:502 TCP I observe no improvement in cpu usage.

- I Transfered the modbus slave near my main FHEM (running on a raspi 4, instead of raspi2 for tests), with the exact same fhem config, the cpu is still high but lower (near 10%, instead of 23% on raspi2)

- with a virtual machine (x86 vmware) running ubuntu 18.04 LTS, a test fhem instance without much device, just the modbus in tcp mode I see just 0.3 - 0.7 % cpu usage for fhem but the processor is way more powerful

- disabling the modbus master ModbusAttr, fhem goes back between 0.3 and 1.7 % cpu usage on raspi4 and raspi2

files joined:
about 1 minute of log each. I generated an event on log1 with a remote control received on the slave device ACU-220
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: claudio am 13 Juli 2021, 13:03:57
@StefanStrobel
One little question about RS-485 serial interface:

I found this : https://home.hottis.de/gitlab/wolutator/modbusmaster

the pcb use a RS485 chip LTC485 which I have personnally in my parts but not actually used. This chip use a GPIO on master device (arduino, pi whatever) connected to it's RE (Receiver Output Enable) and DE (Driver Output Enable) pins. According to this site,quote: "TX is at GPIO14, RX is at GPIO15 and RTS (control line for transmitter enable) is at GPIO17."

the rs485 device I currently use doesn't have any rts or cts pin on serial interface, only RX,TX,VCC,GND but it appear to work

Did fhem modbus make use of RTS and how to configure it ? I don't seen options in module to set it up. Can't you light me up ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Juli 2021, 17:20:14
Hello Claude,

I'm trying out a few optimisations / caching of structures in the module to speed things up, up it is probably not going to be a massive improvement. I'll post an update when I'm through with it.
Regarding the rs485 interface, I have used probably 5 to 10 different cheap usb tp rs485 adapters from ebay / aliexpress in the past and most worked. The module doesn't care about setting individual hardware flow control but relies on the underlying fhem / os routines to do that.
In most cases it's an ftdi chip that drives usb to serial which also controls RE / OE on the RS485 driver chip (e.g. a max485)

I hope this helps.

regards,
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Juli 2021, 20:29:09
Hello Claude,

can you please test the attached new base module and set the attributes

attr Satel_ACU220 cacheUpdateHash 1
attr Satel_ACU220 cacheParseInfo 1


cacheUpdateHash will cache all info needed when preparing a new request round. PollDelay will not be available if this is used, but it should speed up the request creation when it is done the second time and later.

cacheParseInfo will save a little time when the same object is retrieved the second time and later.

It is not going to decrease cpu load a lot. On my system it is hardy measurable but maybe on an old Pi 2 it can make a difference.
In any case I would recommend to use a decent cpu ;-)

regards,
   Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: claudio am 14 Juli 2021, 02:00:31
Zitat von: StefanStrobel am 13 Juli 2021, 20:29:09
Hello Claude,

can you please test the attached new base module and set the attributes

attr Satel_ACU220 cacheUpdateHash 1
attr Satel_ACU220 cacheParseInfo 1


cacheUpdateHash will cache all info needed when preparing a new request round. PollDelay will not be available if this is used, but it should speed up the request creation when it is done the second time and later.

cacheParseInfo will save a little time when the same object is retrieved the second time and later.

It is not going to decrease cpu load a lot. On my system it is hardy measurable but maybe on an old Pi 2 it can make a difference.
In any case I would recommend to use a decent cpu ;-)

regards,
   Stefan

Thanks Stefan.

I've tried your test version of the module with associated attributes but unfortunately, I didn't see any improvement in cpu usage. I now test exclusively on a raspi 4.

2 things I may mention : First, about 1 week ago, I tested a configuration that appeared to have nearly no impact on cpu, even on a raspi2. It may give you a clue of what's going on. I've programmed an Arduino uno atmega328p to poll the slave with the same registers setup in fhem. The arduino job was only to poll the slave, it wasn't doing anything with the data. Then in fhem, I've setup modbusattr as a passive listener. The registers where updated continously with nearly no impact on cpu.
I've reverted to master mode on fhem because I needed to send data to the slave at times and this is not possible in passive mode.

EDIT: redone the tests, it has the same performance impact when fhem is in passive listener mode.  I was mislead by the fact I did not have the same amount of readings to process

Second, I've tried to setup fhem in slave mode and put the arduino in master mode. The arduino was still polling the satel slave but in the same time, if a register had changed since the last iteration poll, the arduino would then send the data to the fhem slave. this worked, albeit, I needed to insert delay in the code between reading a device and sending to another. But the most intriguing fact is that fhem showed also a significant raise in cpu usage, I don't recall the exact values, but it was in the same league. this is strange since the cpu was high even when no new data was incoming.
Could this be related to the way that fhem deal with serial ports ??
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 14 Juli 2021, 18:13:49
Hello Claude,

why don't you set fhem globally to verbose 5 and then watch the log.
If fhem does nothing else as slave, there should be no activity in the log while no data is received.
This should explain what's happening ...

regards,
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 26 Juli 2021, 08:40:28
Sprung in eine sub routine mit Wertübergabe klappt nicht so richtig.

Ich möchte in einer subroutine springen und den aktuellen wert übergeben, dazu habe ich folgendes probiert:
          "i12801" =>  {       'reading' => 'SolarladerStatus',
       'unpack' => 'B16',  # zerlegen in 16 bits
               'expr' => '$val=(ModbusEPEVER_laderstatus($val))' #übergabe an die sub


in der sub nehme ich den Wert entgegen:
sub ModbusEPEVER_laderstatus($)
{
my ($inputa) = $_;


jedoch ist der inhalt $inputa  ein komplett anderer, und zwar irgendwelche http aufrufe.
wie bekomme ich die gefüllte variable in die sub?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 26 Juli 2021, 10:05:22
ok... habe den Fehler jetzt selbst gefunden :

my ($inputa) = $_;  ist natürlich falsch
my ($inputa) = @_;  so scheint es zu funktionieren


dachte @ wäre für array und $ für einzelne
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: claudio am 03 August 2021, 22:13:00
Zitat von: StefanStrobel am 14 Juli 2021, 18:13:49
Hello Claude,

why don't you set fhem globally to verbose 5 and then watch the log.
If fhem does nothing else as slave, there should be no activity in the log while no data is received.
This should explain what's happening ...

regards,
   Stefan

Hi Stefan

Excuse me for the delay, I was on holidays  8)
I've put fhem to verbose 4 globally to observe activity, there is some, but stopping the modules causing them (gsmsms, wol) them doesn't change anything for the high cpu usage I see in modbus polling. When modbus polling is disabled, there is between 0.3 and ~ 1.3 % CPU used. As soon as modbus poll is enabled, cpu goes between 10 and 14 % CPU constantly. The test was done as modbus master.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 August 2021, 18:34:37
Hello Claude,

I'm not sure that we can decrease the cpu load below the 10 to 14 percent that you observe right now but there are a few things left that we can try to narrow down the the main cause of the load.

If I understood you correct, you already tried to let another master query the slave and have fhem in passive mode. Since this resulted in the same CPU load, the load can not come from creating and sending the requests. In passive Mode the Modbus Module just listens and does not send requests itself.

So the load must come from receiving or parsing. Reading Modbus RTU via serial line might be more cpu intensive than Reading Modbus TCP so just for clarification you could try to configure one raspberry pi with fhem as a Modbus relay that speaks Modbus rtu to your alarm system and Modbus TCP to a second raspberry pi.
Depending on your observation we should know where the main load is cased and maybe find some optimisation there.

Regards,
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: claudio am 10 August 2021, 21:52:57
thanks Stefan

I'm in the process of developping my own C console app to query the modbus slave since fhem appear to be very inefficient when dealing with continuously incoming data at rate of 1 per second or less (at least, that's what I observed)
My current app is probing modbus slave every 800ms and send back (changed data only) to my local mqtt mosquitto broker. The changes are reported to fhem via MQTT.
While I'm far from having a finished app, the cpu usage of the C console app is negligeable, between 0.3 and 1% CPU.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 August 2021, 19:12:07
Hello Claude,

a purpose built C-Program is certainly the most effeicient solution.
The Modbus-Module for Fhem has been designed to be very generic and to handle all sorts of special cases so it will never be as efficient as a C-Program that does exactly what you need :-)

regards,
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 14 August 2021, 20:58:22
Hallo Stefan,

nochmals vielen Dank für das Modul. Eine kleine Frage: ich nutze obj-i0-map um Zustände meines Rasenmähers auf integers zu Mappen welche an ein Touch Panel übertragen werden. Jetzt kommen dummerweise immer wieder neue Fehlerwerte als Ausgabe des Mähers zu Tage. Wenn diese nicht gemapped sind gibt modbusattr den Fehler Use of uninitialized value $val in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3467.

Kann man irgendwie alles undefinierte auf einen einzelnen fehlerwert Mappen? Sowas wie z.b. "5:*"?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 15 August 2021, 20:03:36
Hallo Tomk,

bisher gibt es keinen Default bei der map (wenn Fhem als Modbus Master gelesene Werte konvertiert) bzw. der reverse map (wenn Fhem eingegebene oder als Slave zu sendende Werte konvertiert).
Das klingt ab er nach einer sinnvollen Erweiterung.

Wie sieht denn Deine Konfiguration genau aus?
Der Fehlermeldung nach geht es um Werte, die von ein anderer Master von Fhem als Slave abfragt oder?

Gruss
    Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 15 August 2021, 21:10:34
Vielen Dank für deine Antwort!
Richtig, ModbusAttr ist als Slave konfiguriert und ich stelle verschiedene Daten bereit. Vielleicht einfach ein default attr?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 15 August 2021, 21:21:05
Ich könnte mir ein obj-i0-mapDefault und ein obj-i0-rmapDefault vorstellen. Es könnte ja in beide Richtungen benötigt werden. Vielleicht komme ich in den nächsten Tagen mal dazu das einzubauen. Ich poste dann eine neue Version zum Testen.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 15 August 2021, 21:33:39
Super, vielen Dank vorab... Werde ich testen :-)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 August 2021, 20:06:38
Hallo,

hier eine neue Version zum Testen mit den angekündigten ..-mapDefault und ..-rmapDefault Attributen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 17 August 2021, 21:10:09
Vielen Dank Stefan! Das ging ja schnell... Ich habe es gleich mal übernommen und starte den Test...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 August 2021, 07:24:58
Sorry - die Utils-Datei muss auch ausgetauscht werden, sonst fehlt was ...

EDIT: und um Missverständnisse zu vermeiden: Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD und wird erst beim Neustart von Fhem geladen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 19 August 2021, 13:00:26
Ist mir nicht nicht aufgefallen... bis jetzt sieht's auch ohne die Utils gut aus. Wann sollte sich das fehlende Update auswirken!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 August 2021, 20:44:02
Ohne die Utils ist nur die Fehlermeldung weg.
Ein expliziter Default-Wert ist aber erst in der neuen Version der Utils implementiert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 27 August 2021, 06:20:15
Hallo Stefan, ich habe es jetzt ein paar Tage so laufen und konnte keine Problem feststellen. Allerdings nur in der Slave Konfiguration für mich testbar...
Ich wäre froh wenn du Version in das offizielle Release einbauen könntest?

Besten Dank
Tomk
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 August 2021, 10:03:27
mach ich.
Ich hoffe noch auf ein paar mehr Tester, die bestätigen, dass durch die neue Version keine neuen Probleme entstehen, dann checke ich es ein.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Init am 06 September 2021, 14:05:27
Zitat von: Heiner am 30 Mai 2021, 09:51:35
Hi Init,

wenn ich das richtig sehe kannst Du an der Brilix (hab die gleiche bestellt, ist aber noch nicht geliefert) zwischen modbus und WIFI wählen. Da die Brilix das WIFI Modul verbaut hat wir d das Eingangssignal zum WIFI Modul auch entsprechend stehen müssen.
Da ist vermutlich ein serielles Signal das dann ins WIFI Modul geht.

Kannst du direkt per WIFI auf die IP Adresse per Browser gehen, ist da eine Webseite? Ich bin sicher das man die irgendwie auslesen koennte, das hat dann aber nix mehr mit modbus zu tun und sollte in einen separaten Thread.

Hallo Heiner,

konntest du die Wärmepumpe mittlerweile ansprechen?

Viele Grüße
Marc
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tedious am 21 September 2021, 13:13:05
Hallo zusammen,

kann mir jemand auf die Sprünge helfen? Ich habe eine neue Pelletheizung, eine Herz Condensation Star. Registerbeschreibungen von Herz habe ich da, habe jetzt versucht per Modbusattr lesend zuzugreifen. Im Test die ersten 10 Register.

defmod Heizung ModbusAttr 1 60 192.168.192.86:502 TCP
attr Heizung enableControlSet 1
attr Heizung obj-h00000-reading Kesseltemperatur
attr Heizung obj-h00002-reading Bedarfstemperatur
attr Heizung obj-h00004-reading Kesselstatus
attr Heizung obj-h00006-reading Kesselleistung
attr Heizung obj-h00008-reading Kessel RL-Ist
attr Heizung obj-h00010-reading Kessel RL-Soll
attr Heizung room Heizung

setstate Heizung opened
setstate Heizung 2021-09-13 16:14:49 scan-h00000 hex=00000219, string=...., s=0, s>=0, S=0, S>=0, i=0, i>=0, I=0, I>=0, f=6.72084247699335e-24, f>=7.52497275342427e-43
setstate Heizung 2021-09-13 16:14:51 scan-h00002 hex=00000000, string=...., s=0, s>=0, S=0, S>=0, i=0, i>=0, I=0, I>=0, f=0, f>=0
setstate Heizung 2021-09-13 16:14:53 scan-h00004 hex=00000002, string=...., s=0, s>=0, S=0, S>=0, i=0, i>=0, I=0, I>=0, f=9.4039548065783e-38, f>=2.80259692864963e-45
setstate Heizung 2021-09-13 16:14:55 scan-h00006 hex=00000000, string=...., s=0, s>=0, S=0, S>=0, i=0, i>=0, I=0, I>=0, f=0, f>=0
setstate Heizung 2021-09-13 16:14:57 scan-h00008 hex=00000199, string=...., s=0, s>=0, S=0, S>=0, i=0, i>=0, I=0, I>=0, f=-6.66914368870879e-24, f>=5.7313107190885e-43
setstate Heizung 2021-09-13 16:14:59 scan-h00010 hex=000000fa, string=...., s=0, s>=0, S=0, S>=0, i=0, i>=0, I=0, I>=0, f=-1.66153499473114e+35, f>=3.50324616081204e-43
setstate Heizung 2021-09-20 11:50:54 state opened


so weit, so gut - leider aktualisiert er die Readings nicht. Muss gestehen das sind meine ersten Gehversuche mit Modbus, aber wenn ich die Beschreibung richtig interpretiere sollte er doch alle 60 Sekunden die Readings aktualisieren? Oder stehe ich irgendwo auf dem Schlauch und habe was überlesen/vergessen?

Bin für jeden Tip dankbar,

Grüße Tedious
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Adimarantis am 21 September 2021, 13:54:41
Du musst noch def-h-poll auf 1 setzen:

dev-([cdih]-)*defPoll
if set to 1 then all objects of this type will be included in the cyclic update by default.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tedious am 22 September 2021, 15:53:22
Vielen Dank für das Feedback!

Ist implementiert, leider tut sich aber nichts...

defmod Heizung ModbusAttr 1 60 192.168.192.86:502 TCP
attr Heizung dev-h-defPoll 1
attr Heizung enableControlSet 1
attr Heizung obj-h00000-reading Kesseltemperatur
attr Heizung obj-h00002-reading Bedarfstemperatur
attr Heizung obj-h00004-reading Kesselstatus
attr Heizung obj-h00006-reading Kesselleistung
attr Heizung obj-h00008-reading Kessel RL-Ist
attr Heizung obj-h00010-reading Kessel RL-Soll


Fehlt mir noch etwas?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Adimarantis am 22 September 2021, 20:38:13
Ich habe bei mir auch nichts anderes definiert - allerdings verwende ich Modbus per RS485 (RTU)
Brauchst du bei TCP auch ein Modbus IO Device? Wie ist das definiert?
Wenn du ein "set reread" machst - kriegst du dann neue Werte?
Hast to mal ein "set start" versucht? Vielleicht ist der Timer aus irgendwelchen Gründen angehalten?

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 September 2021, 18:40:27
Hallo,

für Modbus-TCP braucht man kein zusätzliches IO-Device.
Wenn es trotz der bisherigen Tips nicht klappt, dann hilft verbose 5 und ein Blick ins Log.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tedious am 27 September 2021, 10:07:57
Danke für die Info - Verbose hatte ich gar nicht mehr auf dem Schirm :)

Hie die Fehler:

2021.09.27 10:04:13 5:  Heizung: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects inactive active
2021.09.27 10:04:13 5:  Heizung: UpdateSetList: getList=
2021.09.27 10:04:50 4:  Heizung: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2021.09.27 10:04:50 4:  Heizung: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 60.0 sec at 10:05:50.925, interval 60
2021.09.27 10:04:50 5:  Heizung: CreateUpdateList full object list: h00000 h00002 h00004 h00006 h00008 h00010
2021.09.27 10:04:50 5:  Heizung: CreateUpdateList will request h00000 len 1 Kesseltemperatur
2021.09.27 10:04:50 5:  Heizung: CreateUpdateList will request h00002 len 1 Bedarfstemperatur
2021.09.27 10:04:50 5:  Heizung: CreateUpdateList will request h00004 len 1 Kesselstatus
2021.09.27 10:04:50 5:  Heizung: CreateUpdateList will request h00006 len 1 Kesselleistung
2021.09.27 10:04:50 5:  Heizung: CreateUpdateList will request h00008 len 1 Kessel RL-Ist
2021.09.27 10:04:50 5:  Heizung: CreateUpdateList will request h00010 len 1 Kessel RL-Soll
2021.09.27 10:04:50 4:  Heizung: CombineUpdateHash objHash keys before combine: h00004,h00002,h00010,h00008,h00000,h00006
2021.09.27 10:04:50 5:  Heizung: CombineUpdateHash tries to combine read commands
2021.09.27 10:04:50 5:  Heizung: CombineUpdateHash cant combine h00000 len 1 Kesseltemperatur with h00002 len 1 Bedarfstemperatur, span 3 would be bigger than max 1
2021.09.27 10:04:50 5:  Heizung: CombineUpdateHash cant combine h00002 len 1 Bedarfstemperatur with h00004 len 1 Kesselstatus, span 3 would be bigger than max 1
2021.09.27 10:04:50 5:  Heizung: CombineUpdateHash cant combine h00004 len 1 Kesselstatus with h00006 len 1 Kesselleistung, span 3 would be bigger than max 1
2021.09.27 10:04:50 5:  Heizung: CombineUpdateHash cant combine h00006 len 1 Kesselleistung with h00008 len 1 Kessel RL-Ist, span 3 would be bigger than max 1
2021.09.27 10:04:50 5:  Heizung: CombineUpdateHash cant combine h00008 len 1 Kessel RL-Ist with h00010 len 1 Kessel RL-Soll, span 3 would be bigger than max 1
2021.09.27 10:04:50 5:  Heizung: CombineUpdateHash keys are now h00004,h00002,h00010,h00008,h00000,h00006
2021.09.27 10:04:50 4:  Heizung: GetUpdate will now create requests for h00000 len 1 (Kesseltemperatur), h00002 len 1 (Bedarfstemperatur), h00004 len 1 (Kesselstatus), h00006 len 1 (Kesselleistung), h00008 len 1 (Kessel RL-Ist), h00010 len 1 (Kessel RL-Soll)
2021.09.27 10:04:50 4:  Heizung: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h00000, len 1, tid 252, master device Heizung, reading Kesseltemperatur (getUpdate for Kesseltemperatur len 1)
2021.09.27 10:04:50 5:  Heizung: QueueRequest called from DoRequest with h00000, qlen 0 from master Heizung through io device Heizung
2021.09.27 10:04:50 5:  Heizung: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2021.09.27 10:04:50 4:  Heizung: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h00002, len 1, tid 96, master device Heizung, reading Bedarfstemperatur (getUpdate for Bedarfstemperatur len 1)
2021.09.27 10:04:50 5:  Heizung: QueueRequest called from DoRequest with h00002, qlen 1 from master Heizung through io device Heizung
2021.09.27 10:04:50 4:  Heizung: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h00004, len 1, tid 192, master device Heizung, reading Kesselstatus (getUpdate for Kesselstatus len 1)
2021.09.27 10:04:50 5:  Heizung: QueueRequest called from DoRequest with h00004, qlen 2 from master Heizung through io device Heizung
2021.09.27 10:04:50 4:  Heizung: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h00006, len 1, tid 204, master device Heizung, reading Kesselleistung (getUpdate for Kesselleistung len 1)
2021.09.27 10:04:50 5:  Heizung: QueueRequest called from DoRequest with h00006, qlen 3 from master Heizung through io device Heizung
2021.09.27 10:04:50 4:  Heizung: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h00008, len 1, tid 67, master device Heizung, reading Kessel RL-Ist (getUpdate for Kessel RL-Ist len 1)
2021.09.27 10:04:50 5:  Heizung: QueueRequest called from DoRequest with h00008, qlen 4 from master Heizung through io device Heizung
2021.09.27 10:04:50 4:  Heizung: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h00010, len 1, tid 210, master device Heizung, reading Kessel RL-Soll (getUpdate for Kessel RL-Soll len 1)
2021.09.27 10:04:50 5:  Heizung: QueueRequest called from DoRequest with h00010, qlen 5 from master Heizung through io device Heizung
2021.09.27 10:04:50 3:  cm, Send Queue unable to change IODev !
2021.09.27 10:04:50 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 6, request: request: id 1, read fc 3 h00000, len 1, tid 252, master device Heizung, reading Kesseltemperatur (getUpdate for Kesseltemperatur len 1), queued 0.04 secs ago
2021.09.27 10:04:50 5:  Heizung: checkDelays commDelay, last communication with same device was 59.408 secs ago, required delay is 0.1
2021.09.27 10:04:50 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:50 5:  Heizung: checkDelays sendDelay, last send to same device was 59.425 secs ago, required delay is 0.1
2021.09.27 10:04:50 5:  Heizung: checkDelays busDelayRead, last activity on bus was 59.408 secs ago, required delay is 0
2021.09.27 10:04:50 4:  Heizung: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 6, sending 00fc00000006010300000001 via 192.168.192.86:502, read buffer empty,
request: id 1, read fc 3 h00000, len 1, tid 252, master device Heizung, reading Kesseltemperatur (getUpdate for Kesseltemperatur len 1), queued 0.04 secs ago
2021.09.27 10:04:50 5:  Heizung: Send called from ProcessRequestQueue
2021.09.27 10:04:50 5:  DevIo_SimpleWrite Heizung: 00fc00000006010300000001
2021.09.27 10:04:50 5:  Heizung: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2021.09.27 10:04:51 5:  Heizung: readFn buffer: 00fc00000006018303
2021.09.27 10:04:51 5:  Heizung: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2021.09.27 10:04:51 4:  Heizung: ParseFrameStart (TCP, master) extracted id 1, fCode 131, tid 252, dlen 6 and potential data 03
2021.09.27 10:04:51 5:  Heizung: HandleResponse called from ReadFn
2021.09.27 10:04:51 5:  Heizung: ParseResponse called from HandleResponse
2021.09.27 10:04:51 4:  Heizung: HandleResponse got response with error code 83 / 03, illegal data value
2021.09.27 10:04:51 4:  Heizung: HandleResponse done, current frame / read buffer: 00fc00000006018303, id 1, fCode 131, tid 252,
request: id 1, read fc 3 h00000, len 1, tid 252, master device Heizung, reading Kesseltemperatur (getUpdate for Kesseltemperatur len 1), queued 0.08 secs ago, sent 0.03 secs ago,
response: id 1, fc 131, error code 03, len 1
2021.09.27 10:04:51 5:  Heizung: ResetExpect for HandleResponse from response to idle
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2021.09.27 10:04:51 5:  Heizung: DropFrame called from ReadFn - drop 00fc00000006018303
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 5, request: request: id 1, read fc 3 h00002, len 1, tid 96, master device Heizung, reading Bedarfstemperatur (getUpdate for Bedarfstemperatur len 1), queued 0.08 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.033 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.001 secs ago, required delay is 0
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.001 secs ago, required delay is 0.1
2021.09.27 10:04:51 4:  Heizung: checkDelays found commDelay not over, set timer to try again in 0.099
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 5, request: request: id 1, read fc 3 h00002, len 1, tid 96, master device Heizung, reading Bedarfstemperatur (getUpdate for Bedarfstemperatur len 1), queued 0.18 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.101 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.133 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.101 secs ago, required delay is 0
2021.09.27 10:04:51 4:  Heizung: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 5, sending 006000000006010300020001 via 192.168.192.86:502, read buffer empty,
request: id 1, read fc 3 h00002, len 1, tid 96, master device Heizung, reading Bedarfstemperatur (getUpdate for Bedarfstemperatur len 1), queued 0.18 secs ago
2021.09.27 10:04:51 5:  Heizung: Send called from ProcessRequestQueue
2021.09.27 10:04:51 5:  DevIo_SimpleWrite Heizung: 006000000006010300020001
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2021.09.27 10:04:51 5:  Heizung: readFn buffer: 006000000006018303
2021.09.27 10:04:51 5:  Heizung: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2021.09.27 10:04:51 4:  Heizung: ParseFrameStart (TCP, master) extracted id 1, fCode 131, tid 96, dlen 6 and potential data 03
2021.09.27 10:04:51 5:  Heizung: HandleResponse called from ReadFn
2021.09.27 10:04:51 5:  Heizung: ParseResponse called from HandleResponse
2021.09.27 10:04:51 4:  Heizung: HandleResponse got response with error code 83 / 03, illegal data value
2021.09.27 10:04:51 4:  Heizung: HandleResponse done, current frame / read buffer: 006000000006018303, id 1, fCode 131, tid 96,
request: id 1, read fc 3 h00002, len 1, tid 96, master device Heizung, reading Bedarfstemperatur (getUpdate for Bedarfstemperatur len 1), queued 0.20 secs ago, sent 0.02 secs ago,
response: id 1, fc 131, error code 03, len 1
2021.09.27 10:04:51 5:  Heizung: ResetExpect for HandleResponse from response to idle
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2021.09.27 10:04:51 5:  Heizung: DropFrame called from ReadFn - drop 006000000006018303
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 4, request: request: id 1, read fc 3 h00004, len 1, tid 192, master device Heizung, reading Kesselstatus (getUpdate for Kesselstatus len 1), queued 0.20 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.001 secs ago, required delay is 0
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.019 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.001 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 4:  Heizung: checkDelays found commDelay not over, set timer to try again in 0.099
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 4, request: request: id 1, read fc 3 h00004, len 1, tid 192, master device Heizung, reading Kesselstatus (getUpdate for Kesselstatus len 1), queued 0.30 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.101 secs ago, required delay is 0
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.119 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.101 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 4:  Heizung: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 4, sending 00c000000006010300040001 via 192.168.192.86:502, read buffer empty,
request: id 1, read fc 3 h00004, len 1, tid 192, master device Heizung, reading Kesselstatus (getUpdate for Kesselstatus len 1), queued 0.30 secs ago
2021.09.27 10:04:51 5:  Heizung: Send called from ProcessRequestQueue
2021.09.27 10:04:51 5:  DevIo_SimpleWrite Heizung: 00c000000006010300040001
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2021.09.27 10:04:51 5:  Heizung: readFn buffer: 00c000000006018303
2021.09.27 10:04:51 5:  Heizung: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2021.09.27 10:04:51 4:  Heizung: ParseFrameStart (TCP, master) extracted id 1, fCode 131, tid 192, dlen 6 and potential data 03
2021.09.27 10:04:51 5:  Heizung: HandleResponse called from ReadFn
2021.09.27 10:04:51 5:  Heizung: ParseResponse called from HandleResponse
2021.09.27 10:04:51 4:  Heizung: HandleResponse got response with error code 83 / 03, illegal data value
2021.09.27 10:04:51 4:  Heizung: HandleResponse done, current frame / read buffer: 00c000000006018303, id 1, fCode 131, tid 192,
request: id 1, read fc 3 h00004, len 1, tid 192, master device Heizung, reading Kesselstatus (getUpdate for Kesselstatus len 1), queued 0.32 secs ago, sent 0.02 secs ago,
response: id 1, fc 131, error code 03, len 1
2021.09.27 10:04:51 5:  Heizung: ResetExpect for HandleResponse from response to idle
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2021.09.27 10:04:51 5:  Heizung: DropFrame called from ReadFn - drop 00c000000006018303
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 3, request: request: id 1, read fc 3 h00006, len 1, tid 204, master device Heizung, reading Kesselleistung (getUpdate for Kesselleistung len 1), queued 0.32 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.001 secs ago, required delay is 0
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.017 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.001 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 4:  Heizung: checkDelays found commDelay not over, set timer to try again in 0.099
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 3, request: request: id 1, read fc 3 h00006, len 1, tid 204, master device Heizung, reading Kesselleistung (getUpdate for Kesselleistung len 1), queued 0.42 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.101 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.101 secs ago, required delay is 0
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.117 secs ago, required delay is 0.1
2021.09.27 10:04:51 4:  Heizung: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 3, sending 00cc00000006010300060001 via 192.168.192.86:502, read buffer empty,
request: id 1, read fc 3 h00006, len 1, tid 204, master device Heizung, reading Kesselleistung (getUpdate for Kesselleistung len 1), queued 0.42 secs ago
2021.09.27 10:04:51 5:  Heizung: Send called from ProcessRequestQueue
2021.09.27 10:04:51 5:  DevIo_SimpleWrite Heizung: 00cc00000006010300060001
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2021.09.27 10:04:51 5:  Heizung: readFn buffer: 00cc00000006018303
2021.09.27 10:04:51 5:  Heizung: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2021.09.27 10:04:51 4:  Heizung: ParseFrameStart (TCP, master) extracted id 1, fCode 131, tid 204, dlen 6 and potential data 03
2021.09.27 10:04:51 5:  Heizung: HandleResponse called from ReadFn
2021.09.27 10:04:51 5:  Heizung: ParseResponse called from HandleResponse
2021.09.27 10:04:51 4:  Heizung: HandleResponse got response with error code 83 / 03, illegal data value
2021.09.27 10:04:51 4:  Heizung: HandleResponse done, current frame / read buffer: 00cc00000006018303, id 1, fCode 131, tid 204,
request: id 1, read fc 3 h00006, len 1, tid 204, master device Heizung, reading Kesselleistung (getUpdate for Kesselleistung len 1), queued 0.46 secs ago, sent 0.04 secs ago,
response: id 1, fc 131, error code 03, len 1
2021.09.27 10:04:51 5:  Heizung: ResetExpect for HandleResponse from response to idle
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2021.09.27 10:04:51 5:  Heizung: DropFrame called from ReadFn - drop 00cc00000006018303
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 2, request: request: id 1, read fc 3 h00008, len 1, tid 67, master device Heizung, reading Kessel RL-Ist (getUpdate for Kessel RL-Ist len 1), queued 0.46 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.001 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.040 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.001 secs ago, required delay is 0
2021.09.27 10:04:51 4:  Heizung: checkDelays found commDelay not over, set timer to try again in 0.099
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 2, request: request: id 1, read fc 3 h00008, len 1, tid 67, master device Heizung, reading Kessel RL-Ist (getUpdate for Kessel RL-Ist len 1), queued 0.56 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.101 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.140 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.101 secs ago, required delay is 0
2021.09.27 10:04:51 4:  Heizung: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 004300000006010300080001 via 192.168.192.86:502, read buffer empty,
request: id 1, read fc 3 h00008, len 1, tid 67, master device Heizung, reading Kessel RL-Ist (getUpdate for Kessel RL-Ist len 1), queued 0.56 secs ago
2021.09.27 10:04:51 5:  Heizung: Send called from ProcessRequestQueue
2021.09.27 10:04:51 5:  DevIo_SimpleWrite Heizung: 004300000006010300080001
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2021.09.27 10:04:51 5:  Heizung: readFn buffer: 004300000006018303
2021.09.27 10:04:51 5:  Heizung: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2021.09.27 10:04:51 4:  Heizung: ParseFrameStart (TCP, master) extracted id 1, fCode 131, tid 67, dlen 6 and potential data 03
2021.09.27 10:04:51 5:  Heizung: HandleResponse called from ReadFn
2021.09.27 10:04:51 5:  Heizung: ParseResponse called from HandleResponse
2021.09.27 10:04:51 4:  Heizung: HandleResponse got response with error code 83 / 03, illegal data value
2021.09.27 10:04:51 4:  Heizung: HandleResponse done, current frame / read buffer: 004300000006018303, id 1, fCode 131, tid 67,
request: id 1, read fc 3 h00008, len 1, tid 67, master device Heizung, reading Kessel RL-Ist (getUpdate for Kessel RL-Ist len 1), queued 0.58 secs ago, sent 0.02 secs ago,
response: id 1, fc 131, error code 03, len 1
2021.09.27 10:04:51 5:  Heizung: ResetExpect for HandleResponse from response to idle
2021.09.27 10:04:51 5:  Heizung: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2021.09.27 10:04:51 5:  Heizung: DropFrame called from ReadFn - drop 004300000006018303
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 1, request: request: id 1, read fc 3 h00010, len 1, tid 210, master device Heizung, reading Kessel RL-Soll (getUpdate for Kessel RL-Soll len 1), queued 0.58 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.019 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.001 secs ago, required delay is 0
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.001 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 4:  Heizung: checkDelays found commDelay not over, set timer to try again in 0.099
2021.09.27 10:04:51 5:  Heizung: ProcessRequestQueue called from Fhem internal timer as queue:Heizung, qlen 1, request: request: id 1, read fc 3 h00010, len 1, tid 210, master device Heizung, reading Kessel RL-Soll (getUpdate for Kessel RL-Soll len 1), queued 0.68 secs ago
2021.09.27 10:04:51 5:  Heizung: checkDelays busDelayRead, last activity on bus was 0.101 secs ago, required delay is 0
2021.09.27 10:04:51 5:  Heizung: checkDelays sendDelay, last send to same device was 0.119 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays commDelay, last communication with same device was 0.101 secs ago, required delay is 0.1
2021.09.27 10:04:51 5:  Heizung: checkDelays clientSwitchDelay is not relevant
2021.09.27 10:04:51 4:  Heizung: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 00d2000000060103000a0001 via 192.168.192.86:502, read buffer empty,
request: id 1, read fc 3 h00010, len 1, tid 210, master device Heizung, reading Kessel RL-Soll (getUpdate for Kessel RL-Soll len 1), queued 0.68 secs ago
2021.09.27 10:04:51 5:  Heizung: Send called from ProcessRequestQueue
2021.09.27 10:04:51 5:  DevIo_SimpleWrite Heizung: 00d2000000060103000a0001
2021.09.27 10:04:51 5:  Heizung: readFn buffer: 00d200000006018303
2021.09.27 10:04:51 5:  Heizung: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2021.09.27 10:04:51 4:  Heizung: ParseFrameStart (TCP, master) extracted id 1, fCode 131, tid 210, dlen 6 and potential data 03
2021.09.27 10:04:51 5:  Heizung: HandleResponse called from ReadFn
2021.09.27 10:04:51 5:  Heizung: ParseResponse called from HandleResponse
2021.09.27 10:04:51 4:  Heizung: HandleResponse got response with error code 83 / 03, illegal data value
2021.09.27 10:04:51 4:  Heizung: HandleResponse done, current frame / read buffer: 00d200000006018303, id 1, fCode 131, tid 210,
request: id 1, read fc 3 h00010, len 1, tid 210, master device Heizung, reading Kessel RL-Soll (getUpdate for Kessel RL-Soll len 1), queued 0.70 secs ago, sent 0.02 secs ago,
response: id 1, fc 131, error code 03, len 1
2021.09.27 10:04:51 5:  Heizung: ResetExpect for HandleResponse from response to idle
2021.09.27 10:04:51 5:  Heizung: DropFrame called from ReadFn - drop 00d200000006018303


Aber ich komme der Sache näher - sind 32 Bit Register, habe jetzt noch ein  dev-h-defLen 2 hinzugefügt. Jetzt kommen zwar noch keine Werte an (alles 0), aber irgendwas passiert schon mal :)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 September 2021, 19:55:45
Hallo Tedious,

Das Log zeigt aber noch Requests mit Länge 1 und entsprechend Fehlermeldungen als Antwort von der Heizung.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tedious am 28 September 2021, 15:38:00
Super, vielen Dank! Sorry, MobBus ist für mich völliges Neuland... :-/

Anschließend eine weitere Frage. Die Daten kommen jetzt rein, als Parameter habe ich in analog zu den Beispielen dev-h-defUnpack f> gesetzt. Dementsprechend zeigt das Eventlog jetzt

ModbusAttr Heizung Kesseltemperatur: 2.90934851828516e-37

das Reading ist dementsprechend

Kesseltemperatur 2.90934851828516e-37 2021-09-28 15:34:46

Beim initialen Scan lieferte er mir

scan-h00000
hex=00000219, string=...., s=0, s>=0, S=0, S>=0, i=0, i>=0, I=0, I>=0, f=6.72084247699335e-24, f>=7.52497275342427e-43
2021-09-13 16:14:49


Was ich eigentlich brauche ist der hex=.... Wert als dezimal umgerechnete Darstellung, das wären die Werte die ich benötige. Kannst Du mir hier auch noch auf die Sprünge helfen? Im Moment ist die Def wie folgt:

defmod Heizung ModbusAttr 1 60 192.168.192.86:502 TCP
attr Heizung DbLogExclude .*
attr Heizung dev-h-defLen 2
attr Heizung dev-h-defPoll 1
attr Heizung dev-h-defRevRegs 1
attr Heizung dev-h-defUnpack f>
attr Heizung enableControlSet 1
attr Heizung obj-h00000-reading Kesseltemperatur
attr Heizung obj-h00002-reading Bedarfstemperatur
attr Heizung obj-h00004-reading Kesselstatus
attr Heizung obj-h00006-reading Kesselleistung
attr Heizung obj-h00008-reading Kessel RL-Ist
attr Heizung obj-h00010-reading Kessel RL-Soll
attr Heizung room Heizung


Ich würde gerne für die Hand voll Parameter eine saubere Darstellung finden bevor ich die restlichen Register hinzufüge.

Besten Dank,

Tedious


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 September 2021, 21:50:00
Hallo,

wenn der Hex-Wert der gesuchte Wert ist, dann möchtest Du die beiden Register offenbar nicht als 32-Bit Float interpretieren, sondern als 32-Bit Integer.
Schau Dir mal die entsprechenden Pack- bzw. Unpack-Codes unter https://perldoc.perl.org/functions/pack an.
Vermutlich (wenn es wirklich je zwei Register, also 32 Bit sind) wird es "l" oder "L" sein und nicht "f>"

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tedious am 29 September 2021, 18:07:15
Hi,

danke für Deine Hilfe. Leider stehe ich immer noch auf dem Schlauch. QModMaster liefert mir in den Registern die passenden Werte (s. Bild). In Fhem kommt dagegen - egal welche Parameter ich nehme - nur schräges Zeug an. Der Wert im Bild entspricht dem Wert per VPN, nur x10 (also hier 64,1°C).

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 September 2021, 19:37:27
Hallo Tedious,

was ist denn das "schräge Zeug" das ankommt?
Wie sieht denn Deine Konfiguration (unpack, expr, ...) nun aus?
Stimmen denn die Register-Adressen (manche beginnen bei 0 zu zählen, andere bei 1)?
Wie immer hilft ein Log mit verbose 5 um besser zu verstehen, was bei Dir passiert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tedious am 01 Oktober 2021, 16:23:01
Hallo Stefan,

vielen Dank für Deine Geduld. Ich hab den Schritt vom Schlauch runter hinbekommen, läuft jetzt. Zur Doku für die Nachwelt, falls jemand mal einen Herz Pelletstar Condendation einbinden will hier ein Teil der Konfig als Guideline. Ist noch nicht komplett, aber das Muster ist klar, insofern kann ich jetzt nach und nach alle Parameter reinbauen.

defmod Pelletheizung ModbusAttr 1 60 192.168.192.86:502 TCP
attr Pelletheizung group Pelletheizung
attr Pelletheizung obj-h00000-expr $val/10
attr Pelletheizung obj-h00000-len 2
attr Pelletheizung obj-h00000-poll 1
attr Pelletheizung obj-h00000-reading Kesseltemperatur
attr Pelletheizung obj-h00000-unpack N
attr Pelletheizung obj-h00002-expr $val/10
attr Pelletheizung obj-h00002-len 2
attr Pelletheizung obj-h00002-poll 1
attr Pelletheizung obj-h00002-reading Bedarfstemperatur_Kessel
attr Pelletheizung obj-h00002-unpack N
attr Pelletheizung obj-h00004-len 2
attr Pelletheizung obj-h00004-poll 1
attr Pelletheizung obj-h00004-reading Kesselstatus
attr Pelletheizung obj-h00004-unpack N
attr Pelletheizung obj-h00006-expr $val/10
attr Pelletheizung obj-h00006-len 2
attr Pelletheizung obj-h00006-poll 1
attr Pelletheizung obj-h00006-reading Kesselleistung
attr Pelletheizung obj-h00006-unpack N
attr Pelletheizung obj-h01362-expr $val/10
attr Pelletheizung obj-h01362-len 2
attr Pelletheizung obj-h01362-poll 1
attr Pelletheizung obj-h01362-reading Kollektor-Rücklauf
attr Pelletheizung obj-h01362-unpack N
attr Pelletheizung obj-h01364-expr $val/10
attr Pelletheizung obj-h01364-len 2
attr Pelletheizung obj-h01364-poll 1
attr Pelletheizung obj-h01364-reading Kollektor-Vorlauf
attr Pelletheizung obj-h01364-unpack N
attr Pelletheizung obj-h01366-expr $val/10
attr Pelletheizung obj-h01366-len 2
attr Pelletheizung obj-h01366-poll 1
attr Pelletheizung obj-h01366-reading Speichertemperatur
attr Pelletheizung obj-h01366-unpack N
attr Pelletheizung obj-h01368-reading scan-h01368
attr Pelletheizung obj-h01370-expr $val/10
attr Pelletheizung obj-h01370-len 2
attr Pelletheizung obj-h01370-poll 1
attr Pelletheizung obj-h01370-reading Pumpendrehzahl
attr Pelletheizung obj-h01370-unpack N
attr Pelletheizung obj-h01378-expr $val/10
attr Pelletheizung obj-h01378-len 2
attr Pelletheizung obj-h01378-poll 1
attr Pelletheizung obj-h01378-reading Ertrag-aktuell
attr Pelletheizung obj-h01378-unpack N
attr Pelletheizung room Heizung
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mBielemeier am 04 Oktober 2021, 20:46:46
Hallo,

ich habe seit kurzem eine Wallbox von cFos, die angeschlossene Zähler über Modbus auswertet. Num bietet die Wallbox auch einen Modbus-Proxy über TCP an. Mit einem Zähler konnte ich fehlerfrei über ModbusAttr mit der TCP-Definition arbeiten, bei zwei Zählern wurde es etwas instabil, connectete sich aber schnell wieder von selbst. Die dritte ModbusAttr-Definition auf die gleiche Adresse mit dritter ID führt nun dazu, dass ein Zähler sich komplett disconnected.

Damit sich die Modbus-Zugriffe nicht überlagern dachte ich das über die Modbus/ModbusAttr - Kombination zu machen. Dazu habe ich hart kodiert und somit nicht allgemeingültig in 98_Modbus.pm - DefineFn - Zeile 539 $ioHash->{SerialConn} = 1; durch $ioHash->{TCPConn} = 1; ersetzt. Dadurch konnte ich aber die Wallbox (= Modbus-Proxy) mit
defmod ModbusProxy Modbus 192.168.xxx.xxx:4710
definieren und alle Zähler in der Art
defmod ZaehlerAuto ModbusAttr 3 60 TCP
Seitdem gibt es keinen Timeout mehr.

Soweit zum Problem und nun die Frage: Gibt es eine geplante Lösung für das Problem oder ist das eine sinnvolle Lösung (dann natürlich mit der Erkennung Serial/TCP bei der Modbus-Definition)?

Viele Grüße
Manfred
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 Oktober 2021, 21:28:48
Hallo Manfred,

wie Du vermutlich zwei Zeilen weiter im Code schon gelesen hast:

# todo: check if tcp or serial to allow sharing of a tcp connection iodev for multiple devices
# e.g. to a gateway


ist das eine offene Aufgabe ;-)
Die Anfrage dass man Verbindungen für mehrere Geräte über eine gemeinsame TCP-Verbindung schieben kann, kam schon mal und bei der letzten größeren Überarbeitung des Moduls habe ich versucht, die Voraussetzungen dafür zu schaffen, ohne das wirklich zu Ende zu bringen. Dann kamen andere Projekte dazwischen ;-)
Dass es jetzt schon mit so einer kleinen Änderung funktioniert, überrascht mich selbst ein wenig. Ich werde das aber zum Anlass nehmen und den Rest vollends einbauen bzw. suchen wo es noch zu Problemen kommen könnte.
Das kann aber noch eine Weile dauern und bis dahin kannst Du ja mal weiter beobachten, ob es mit Deiner Lösung noch Probleme gibt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mBielemeier am 04 Oktober 2021, 23:34:33
Hallo Stefan,

danke für die Antwort. Ich habe jetzt für das Modbus-Modul die Statistik aktiviert und bei 7-8 Requests je Minute auf 3 IDs kene Timeouts oder Disconnects.

Die Wallbox bietet auch noch einen zweiten TCP-Modbus mit 3 IDs. Den habe ich auch noch aktiviert und scheinbar läuft es fehlerfrei. Ich beobachte das weiter.

Vielen Dank für das Modul, darüber habe ich jetzt meine Stromzähler und den Gaszähler angeschlossen :)

Viele Grüße,
Manfred
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 Oktober 2021, 20:50:47
Hallo Manfred,

schau doch mal ob diese kleine Änderung schon ausreicht:


    if ($dev =~ /\:[\d]+/) {
        $ioHash->{TCPConn} = 1;
    } else {
        $ioHash->{SerialConn} = 1;   
    }


Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mBielemeier am 07 Oktober 2021, 21:07:38
Hallo Stefan,

ich habe aus DefineLDFn noch die Bereinigung von SerialConn und TCPConn übernommen. Auch ein Standard-Port wird da gesetzt, wenn nicht explizit angegeben. Wenn das erhalten bleiben soll, wäre die Abfrage nicht passend. Sehe ich richtig, dass bei serieller Verbindung immer "@<Geschwindigkeit>". Dann könnte das "@" als Unterscheidung genommen werden, denn das gibt es weder in IP-Adressen noch in URI-Adressen. Getestet mit 192.168.178.100, 192.168.178.100:4000, /dev/ttyUSB1@9600 und /dev/ttyUSB2@38400,8,E,2 .

if ($dev !~ /@[\d]+/) {
    $ioHash->{TCPConn} = 1;
    $dev .= ':502' if ($dev !~ /.*:[0-9]/);   # add default port if no port specified
    delete $ioHash->{SerialConn};
} else {
    $ioHash->{SerialConn} = 1;   
    delete $ioHash->{TCPConn};
}


Es laufen weiter 2 TCP-Proxys gleichzeitig auf einer Adresse mit zwei Ports fehlerfrei. Gemischten Betrieb Seriell / TCP kann ich leider nicht testen.

Viele Grüße,
Manfred
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Oktober 2021, 21:29:57
Hallo Manfred,

Du hast recht, eigentlich müsste die serielle Geschwindigkeit immer angegeben werden.
Ich übernehme Deine Änderung (allerdings in umgedrehter Logik) und hoffe, dass wir nichts übersehen.
Dann fehlt noch eine Ergänzung in der Commandref und im Wiki ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: hasenhirn am 23 Oktober 2021, 12:11:18
Hallo und guten Morgen :-)

als erstes einmal danke an Stefan für das tolle Modbus-Modul und den super Support!!!

Nun zu meinem "Problem":
Nach einem Firmwareupdate kann meine Keba-Wallbox Modbus  ;D

Ich habe mich jetzt mal an die Umsetzung gemacht und dank dem Wiki, den Beiträgen und dem Forum bin ich ( wie ich finde ) schon ganz gut voran gekommen. An einer Stelle hakt es aber und da bräuchte ich einen guten Tipp.
Bei der Adresse 5014 - Enable/Disable charging station steht 0: Disable charging station und 1: Enable charging station.
Leider ist das der Punkt an dem ich nicht weiter komme. Die Wallbox läuft immer durch und ich bekomme den Ladevorgang nicht unterbrochen  >:(
Alle anderen Funktionen sind ok und bringen die Werte die ich erwarte.
Als Konfiguration habe ich schon obj-h05014-reading und obj-c05014-reading versucht wobei bei obj-c05014-reading die Fehlermeldung "Timeout in Readanswer" kommt.
Hier mal eine paar Informationen über meine Konfiguration und die Logeinträge.

defmod Keba_Stellplatz ModbusAttr 1 10 192.168.1.22:502 TCP
attr Keba_Stellplatz dev-h-defPoll 1
attr Keba_Stellplatz event-min-interval .*:60
attr Keba_Stellplatz event-on-change-reading .*
attr Keba_Stellplatz obj-h01000-len 2
attr Keba_Stellplatz obj-h01000-map 0:booting, 1:not ready for charging, 2:ready for chargin, 3:charging, 4:error, 5:charging process interrupted
attr Keba_Stellplatz obj-h01000-reading Chargingstate
attr Keba_Stellplatz obj-h01000-unpack N
attr Keba_Stellplatz obj-h01004-len 2
attr Keba_Stellplatz obj-h01004-map 0:no cable is plugged, 1:Cable is connected to charging station, 3:Cabel is connected to the charging station and locked, 5:Cable is connected to the charging station and the EV, 7:Cable is connected to the charging station and the EV an locked
attr Keba_Stellplatz obj-h01004-reading Cablestate
attr Keba_Stellplatz obj-h01004-unpack N
attr Keba_Stellplatz obj-h01006-len 2
attr Keba_Stellplatz obj-h01006-map 0:No error
attr Keba_Stellplatz obj-h01006-reading Error_code
attr Keba_Stellplatz obj-h01006-unpack N
attr Keba_Stellplatz obj-h01008-expr $val / 1000
attr Keba_Stellplatz obj-h01008-format %.3f A
attr Keba_Stellplatz obj-h01008-len 2
attr Keba_Stellplatz obj-h01008-reading Charging_current_phase_1
attr Keba_Stellplatz obj-h01008-unpack N
attr Keba_Stellplatz obj-h01010-expr $val / 1000
attr Keba_Stellplatz obj-h01010-format %.3f A
attr Keba_Stellplatz obj-h01010-len 2
attr Keba_Stellplatz obj-h01010-reading Charging_current_phase_2
attr Keba_Stellplatz obj-h01010-unpack N
attr Keba_Stellplatz obj-h01012-expr $val / 1000
attr Keba_Stellplatz obj-h01012-format %.3f A
attr Keba_Stellplatz obj-h01012-len 2
attr Keba_Stellplatz obj-h01012-reading Charging_current_phase_3
attr Keba_Stellplatz obj-h01012-unpack N
attr Keba_Stellplatz obj-h01014-len 2
attr Keba_Stellplatz obj-h01014-reading Serialnumber
attr Keba_Stellplatz obj-h01014-unpack N
attr Keba_Stellplatz obj-h01016-len 2
attr Keba_Stellplatz obj-h01016-reading Producttype
attr Keba_Stellplatz obj-h01016-unpack N
attr Keba_Stellplatz obj-h01018-len 2
attr Keba_Stellplatz obj-h01018-reading Firmwareversion
attr Keba_Stellplatz obj-h01018-unpack N
attr Keba_Stellplatz obj-h01020-expr $val / 1000
attr Keba_Stellplatz obj-h01020-format %.3f W
attr Keba_Stellplatz obj-h01020-len 2
attr Keba_Stellplatz obj-h01020-reading Active_power
attr Keba_Stellplatz obj-h01020-unpack N
attr Keba_Stellplatz obj-h01036-expr $val / 1000
attr Keba_Stellplatz obj-h01036-format %.3f kWh
attr Keba_Stellplatz obj-h01036-len 2
attr Keba_Stellplatz obj-h01036-reading Total_energy
attr Keba_Stellplatz obj-h01036-unpack N
attr Keba_Stellplatz obj-h01040-format %.1f V
attr Keba_Stellplatz obj-h01040-len 2
attr Keba_Stellplatz obj-h01040-reading Voltage_phase_1
attr Keba_Stellplatz obj-h01040-unpack N
attr Keba_Stellplatz obj-h01042-format %.1f V
attr Keba_Stellplatz obj-h01042-len 2
attr Keba_Stellplatz obj-h01042-reading Voltage_phase_2
attr Keba_Stellplatz obj-h01042-unpack N
attr Keba_Stellplatz obj-h01044-format %.1f V
attr Keba_Stellplatz obj-h01044-len 2
attr Keba_Stellplatz obj-h01044-reading Voltage_phase_3
attr Keba_Stellplatz obj-h01044-unpack N
attr Keba_Stellplatz obj-h01046-expr $val / 10
attr Keba_Stellplatz obj-h01046-format %.1f %
attr Keba_Stellplatz obj-h01046-len 2
attr Keba_Stellplatz obj-h01046-reading Powerfactor
attr Keba_Stellplatz obj-h01046-unpack N
attr Keba_Stellplatz obj-h01100-expr $val / 1000
attr Keba_Stellplatz obj-h01100-format %d A
attr Keba_Stellplatz obj-h01100-len 2
attr Keba_Stellplatz obj-h01100-reading Max_charging_current
attr Keba_Stellplatz obj-h01100-unpack N
attr Keba_Stellplatz obj-h01110-expr $val / 1000
attr Keba_Stellplatz obj-h01110-format %d A
attr Keba_Stellplatz obj-h01110-len 2
attr Keba_Stellplatz obj-h01110-reading Max_supported_current
attr Keba_Stellplatz obj-h01110-unpack N
attr Keba_Stellplatz obj-h05004-expr $val / 1000
attr Keba_Stellplatz obj-h05004-format %.3f A
attr Keba_Stellplatz obj-h05004-max 63
attr Keba_Stellplatz obj-h05004-min 6
attr Keba_Stellplatz obj-h05004-reading Set_charging_current
attr Keba_Stellplatz obj-h05004-set 1
attr Keba_Stellplatz obj-h05004-setexpr $val * 1000
attr Keba_Stellplatz obj-h05010-reading Set_energy
attr Keba_Stellplatz obj-h05010-set 1
attr Keba_Stellplatz obj-h05010-unpack N
attr Keba_Stellplatz obj-h05012-reading Unlock_plug
attr Keba_Stellplatz obj-h05012-set 1
attr Keba_Stellplatz obj-h05014-reading Enable/Disable_charging_station
attr Keba_Stellplatz obj-h05014-set 1
attr Keba_Stellplatz verbose 5

setstate Keba_Stellplatz opened
setstate Keba_Stellplatz 2021-10-23 11:58:57 Active_power 4205.857 W
setstate Keba_Stellplatz 2021-10-23 11:58:56 Cablestate Cable is connected to the charging station and the EV an locked
setstate Keba_Stellplatz 2021-10-23 11:58:56 Charging_current_phase_1 6.107 A
setstate Keba_Stellplatz 2021-10-23 11:58:56 Charging_current_phase_2 6.112 A
setstate Keba_Stellplatz 2021-10-23 11:58:56 Charging_current_phase_3 6.115 A
setstate Keba_Stellplatz 2021-10-23 11:58:56 Chargingstate charging
setstate Keba_Stellplatz 2021-10-23 11:58:44 Enable/Disable_charging_station 0
setstate Keba_Stellplatz 2021-10-23 11:58:56 Error_code No error
setstate Keba_Stellplatz 2021-10-23 11:58:57 Firmwareversion 50993920
setstate Keba_Stellplatz 2021-10-23 11:58:58 Max_charging_current 6 A
setstate Keba_Stellplatz 2021-10-23 11:58:58 Max_supported_current 16 A
setstate Keba_Stellplatz 2021-10-23 11:58:58 Powerfactor 99.5 %
setstate Keba_Stellplatz 2021-10-23 11:58:57 Producttype 314121
setstate Keba_Stellplatz 2021-10-23 11:58:57 Serialnumber 22218033
setstate Keba_Stellplatz 2021-10-23 11:54:48 Set_charging_current 6.000 A
setstate Keba_Stellplatz 2021-10-23 11:58:57 Total_energy 1127.018 kWh
setstate Keba_Stellplatz 2021-10-23 11:58:57 Voltage_phase_1 229.0 V
setstate Keba_Stellplatz 2021-10-23 11:58:57 Voltage_phase_2 230.0 V
setstate Keba_Stellplatz 2021-10-23 11:58:57 Voltage_phase_3 230.0 V
setstate Keba_Stellplatz 2021-10-23 11:56:14 state opened


Hier gibt es die Programmieranleitung zur Keba-Wallbox:
https://www.keba.com/download/x/dea7ae6b84/kecontactp30modbustcp_pgen.pdf (https://www.keba.com/download/x/dea7ae6b84/kecontactp30modbustcp_pgen.pdf)

Ich hoffe mit den Informationen kann mir jemand weiter helfen  :)

LG

Thomas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 25 Oktober 2021, 17:36:15
Hallo Thomas,

laut Log wird der Wert 0 oder 1 korrekt geschrieben. Da uint16 als Typ angegeben wird, muss es auch ein Holding Register sein. Ein Coil wäre ja nur ein einzelnes Bit. Warum die Wallbox das dann nicht umsetzt kann ich nicht sagen. Da würde ich mal den Hersteller fragen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: hasenhirn am 25 Oktober 2021, 17:49:01
Hallo Stefan,

danke für die Info und deine Mühe.
Ich habe die 2te Wallbox auch gerade von UDP auf Modbus umgestellt und probiere mal ob es an der Box liegt.
Wenn ich neue Erkenntnisse habe melde ich mich noch mal  ;)

LG

Thomas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: hasenhirn am 25 Oktober 2021, 18:34:15
@ Stefan
Satz mit x, das war wohl nix  >:(
Es  scheint, wie Du schon richtig vermutet hast, an der Wallbox zu liegen.
Ich habe jetzt mal den Support angeschrieben was die dazu meinen. Da bin ich mal gespannt.
Mal schauen wie es weiter geht.
Da per Modbus aber viel weniger Daten abgefragt werden würde ich lieber wieder auf UDP wechseln, aber da funktioniert das Modul nur mit einer Box.
Es ist zum verzweifeln  :-[ :-[ :-[
Trotzdem noch mal danke für deine Bemühungen und die super Arbeit an dem Modul  :)

LG

Thomas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 26 Oktober 2021, 17:34:24
Moin,
ich würd mich hier auch nochmal kurz ranhängen:

Ich hab ne Alfen-Wallbox und möchte das Register für die Verbrauchte Energie auslesen.
Laut Manual 4x16Bit lang in Wh. (siehe Bild)

Das Modul erhält von der Box den Wert 411869b000000000
Leider schaffe ich es nicht herauszufinden, welcher der richtige Dekodierbefehl ist.
Die Buchstaben habe ich durch, NFDLI, aber es kommt nirgends was sinnvolles raus.
Der Zählerstand müsste so um die 400kWh liegen.
Mit der Perl-Pack-doku habe ich mich heute mal wieder einen halben Tag herumgeschlagen, aber auch die lieferte mir keinen Hilfreichen Tipp.
Hat vllt einer von Euch ne Idee?

Danke,
Stephan







2021.10.26 17:28:47.513 5: alfen_Socket_aussen: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2021.10.26 17:28:47.513 5: alfen_Socket_aussen: DropFrame called from ReadFn - drop 008e0000000b010308ffffffffffffffff
2021.10.26 17:28:47.514 5: alfen_Socket_aussen: ProcessRequestQueue called from Fhem internal timer as queue:alfen_Socket_aussen, qlen 7, request: request: id 1, read fc 3 h374, len 4, tid 250, master device alfen_Socket_aussen, reading RealEnergyDeliveredSum (getUpdate for RealEnergyDeliveredSum len 4), queued 2.18 secs ago
2021.10.26 17:28:47.514 5: alfen_Socket_aussen: checkDelays busDelayRead, last activity on bus was 0.002 secs ago, required delay is 0
2021.10.26 17:28:47.514 5: alfen_Socket_aussen: checkDelays sendDelay, last send to same device was 0.143 secs ago, required delay is 0.1
2021.10.26 17:28:47.514 5: alfen_Socket_aussen: checkDelays clientSwitchDelay is not relevant
2021.10.26 17:28:47.514 5: alfen_Socket_aussen: checkDelays commDelay, last communication with same device was 0.002 secs ago, required delay is 0.1
2021.10.26 17:28:47.514 4: alfen_Socket_aussen: checkDelays found commDelay not over, set timer to try again in 0.098
2021.10.26 17:28:47.613 5: alfen_Socket_aussen: ProcessRequestQueue called from Fhem internal timer as queue:alfen_Socket_aussen, qlen 7, request: request: id 1, read fc 3 h374, len 4, tid 250, master device alfen_Socket_aussen, reading RealEnergyDeliveredSum (getUpdate for RealEnergyDeliveredSum len 4), queued 2.28 secs ago
2021.10.26 17:28:47.613 5: alfen_Socket_aussen: checkDelays sendDelay, last send to same device was 0.242 secs ago, required delay is 0.1
2021.10.26 17:28:47.613 5: alfen_Socket_aussen: checkDelays busDelayRead, last activity on bus was 0.102 secs ago, required delay is 0
2021.10.26 17:28:47.613 5: alfen_Socket_aussen: checkDelays clientSwitchDelay is not relevant
2021.10.26 17:28:47.613 5: alfen_Socket_aussen: checkDelays commDelay, last communication with same device was 0.102 secs ago, required delay is 0.1
2021.10.26 17:28:47.613 4: alfen_Socket_aussen: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 7, sending 00fa00000006010301760004 via 192.168.0.49:502, read buffer empty,
request: id 1, read fc 3 h374, len 4, tid 250, master device alfen_Socket_aussen, reading RealEnergyDeliveredSum (getUpdate for RealEnergyDeliveredSum len 4), queued 2.28 secs ago
2021.10.26 17:28:47.614 5: alfen_Socket_aussen: Send called from ProcessRequestQueue
2021.10.26 17:28:47.614 5: DevIo_SimpleWrite alfen_Socket_aussen: 00fa00000006010301760004
2021.10.26 17:28:47.615 5: alfen_Socket_aussen: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2021.10.26 17:28:47.716 5: alfen_Socket_aussen: readFn buffer: 00fa0000000b010308411869b000000000
2021.10.26 17:28:47.716 5: alfen_Socket_aussen: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2021.10.26 17:28:47.716 4: alfen_Socket_aussen: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 250, dlen 11 and potential data 08411869b000000000
2021.10.26 17:28:47.716 5: alfen_Socket_aussen: HandleResponse called from ReadFn
2021.10.26 17:28:47.717 5: alfen_Socket_aussen: ParseResponse called from HandleResponse
2021.10.26 17:28:47.717 5: alfen_Socket_aussen: now parsing response data objects, master is alfen_Socket_aussen relay is undefined
2021.10.26 17:28:47.717 5: alfen_Socket_aussen: ParseDataString called from HandleResponse with data hex 411869b000000000, type h, adr 374, op read
2021.10.26 17:28:47.717 5: alfen_Socket_aussen: SplitDataString called from ParseDataString with data hex 411869b000000000, type h, adr 374, valuesLen 4, op read
2021.10.26 17:28:47.718 5: alfen_Socket_aussen: CreateDataObjects called from ParseDataString with objList h374
2021.10.26 17:28:47.718 5: alfen_Socket_aussen: CreateDataObjects sortedList h374
2021.10.26 17:28:47.718 5: alfen_Socket_aussen: CreateDataObjects unpacked 411869b000000000 with l to -1335289791
2021.10.26 17:28:47.719 5: alfen_Socket_aussen: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};int(100000*$val)/10000 to -13352897910
2021.10.26 17:28:47.719 4: alfen_Socket_aussen: CreateDataObjects assigns value -13352897910 to RealEnergyDeliveredSum
2021.10.26 17:28:47.720 5: alfen_Socket_aussen: ParseDataString created 1 readings
2021.10.26 17:28:47.721 4: alfen_Socket_aussen: HandleResponse done, current frame / read buffer: 00fa0000000b010308411869b000000000, id 1, fCode 3, tid 250,
request: id 1, read fc 3 h374, len 4, tid 250, master device alfen_Socket_aussen, reading RealEnergyDeliveredSum (getUpdate for RealEnergyDeliveredSum len 4), queued 2.39 secs ago, sent 0.11 secs ago,
response: id 1, fc 3, h374, len 4, values 411869b000000000



Hier ein List:

Internals:
   DEF        1 10 192.168.0.49:502 TCP
   DeviceName 192.168.0.49:502
   EXPECT     idle
   FD         14
   FUUID      614b4c0b-f33f-4040-d23a-6bdbb3cd4d8ea62e
   IODev      alfen_Socket_aussen
   Interval   10
   LASTOPEN   1635259120.63929
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.4.02 - 31.3.2021
   NAME       alfen_Socket_aussen
   NOTIFYDEV  global
   NR         630
   NTFY_ORDER 50-alfen_Socket_aussen
   PARTIAL   
   PROTOCOL   TCP
   STATE      charging approved by EV, but not by EVSE Ladestrom: 0 A Ladeleistung: 0 W NoP: 1
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   nextOpenDelay 60
   Helper:
     DBLOG:
       RealEnergyDeliveredSum:
         logdb:
           TIME       1635261444.91727
           VALUE      -13352897910
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2021-10-26 17:27:48   ActualAppliedMaxCurrent 0
     2021-10-26 17:27:47   Availability    1
     2021-10-26 17:27:48   Charge_Current  0
     2021-10-26 17:27:48   Charge_with_1_or_3_phases 1
     2021-10-26 17:27:45   CurrentPhaseL1  0
     2021-10-26 17:27:46   CurrentPhaseL2  0
     2021-10-26 17:27:46   CurrentPhaseL3  0
     2021-10-26 17:27:48   Fzg_angeschlossen Fahrzeug angeschlossen
     2021-10-26 17:27:48   Laden_moeglich  Laden moeglich
     2021-10-26 17:27:48   MaxCurrentValidTimeRemaining 292
     2021-10-26 17:27:47   Mode3State      C1
     2021-10-26 17:27:48   Mode3State_     charging approved by EV, but not by EVSE
     2021-10-26 17:27:47   RealEnergyDeliveredSum -13352897910
     2021-10-26 17:27:46   RealEnergyDeliveredSumL1 -1
     2021-10-26 17:27:47   RealEnergyDeliveredSumL2 -1
     2021-10-26 17:27:47   RealEnergyDeliveredSumL3 -1
     2021-10-26 17:27:46   RealPowerSum    0
     2021-10-26 17:27:45   VoltPhase1      231.3
     2021-10-26 17:27:45   VoltPhase2      231.3
     2021-10-26 17:27:45   VoltPhase3      233
     2021-10-26 16:38:40   state           opened
   REMEMBER:
     lid        1
     lname      alfen_Socket_aussen
     lrecv      1635262068.8714
     lsend      1635262068.74836
   defptr:
     alfen_Socket_aussen 1
   gotReadings:
     Charge_with_1_or_3_phases 1
   lastRead:
     h1200      1635262067.74735
     h1201      1635262067.97281
     h1206      1635262068.19579
     h1208      1635262068.42204
     h1210      1635262068.64737
     h1215      1635262068.87206
     h306       1635262065.25136
     h308       1635262065.47541
     h310       1635262065.7069
     h320       1635262065.92303
     h322       1635262066.14579
     h324       1635262066.37139
     h344       1635262066.59597
     h362       1635262066.82293
     h366       1635262067.04675
     h370       1635262067.27264
     h374       1635262067.49656
Attributes:
   DbLogInclude RealEnergyDeliveredSum
   dev-h-defPoll 1
   dev-type-FLOAT16-len 2
   dev-type-FLOAT16-unpack f>
   dev-type-FLOAT32-len 4
   dev-type-FLOAT32-unpack f>
   dev-type-FLOAT64-len 4
   dev-type-FLOAT64-unpack l
   dev-type-SIGNED16-len 1
   dev-type-SIGNED16-unpack n!
   dev-type-STRING17-len 17
   dev-type-STRING17-unpack Z*
   dev-type-STRING5-len 5
   dev-type-STRING5-unpack Z*
   dev-type-UNSIGNED16-len 1
   dev-type-UNSIGNED16-unpack S>
   dev-type-UNSIGNED32-len 2
   dev-type-UNSIGNED32-unpack L>
   dev-type-UNSIGNED64-len 4
   dev-type-UNSIGNED64-unpack Q>
   event-on-change-reading RealEnergyDeliveredSum:0.1,.*
   event-on-update-reading MaxCurrentValidTimeRemaining
   obj-h1200-reading Availability
   obj-h1200-type UNSIGNED16
   obj-h1201-reading Mode3State
   obj-h1201-type STRING5
   obj-h1206-reading ActualAppliedMaxCurrent
   obj-h1206-type FLOAT32
   obj-h1208-reading MaxCurrentValidTimeRemaining
   obj-h1208-type UNSIGNED32
   obj-h1210-allowWrite 1
   obj-h1210-hint 0,6,7,8,9,10,11,12,13,14,15,16
   obj-h1210-reading Charge_Current
   obj-h1210-set 1
   obj-h1210-type FLOAT16
   obj-h1215-allowWrite 1
   obj-h1215-hint 1,3
   obj-h1215-reading Charge_with_1_or_3_phases
   obj-h1215-set 1
   obj-h1215-type UNSIGNED16
   obj-h256-expr int($val)/10
   obj-h306-expr int(10*$val)/10
   obj-h306-reading VoltPhase1
   obj-h306-type FLOAT32
   obj-h308-expr int(10*$val)/10
   obj-h308-reading VoltPhase2
   obj-h308-type FLOAT32
   obj-h310-expr int(10*$val)/10
   obj-h310-reading VoltPhase3
   obj-h310-type FLOAT32
   obj-h320-expr int(10*$val)/10
   obj-h320-reading CurrentPhaseL1
   obj-h320-type FLOAT32
   obj-h322-expr int(10*$val)/10
   obj-h322-reading CurrentPhaseL2
   obj-h322-type FLOAT32
   obj-h324-expr int(10*$val)/10
   obj-h324-reading CurrentPhaseL3
   obj-h324-type FLOAT32
   obj-h344-expr int($val)
   obj-h344-reading RealPowerSum
   obj-h344-type FLOAT32
   obj-h362-reading RealEnergyDeliveredSumL1
   obj-h362-type FLOAT64
   obj-h366-reading RealEnergyDeliveredSumL2
   obj-h366-type FLOAT64
   obj-h370-reading RealEnergyDeliveredSumL3
   obj-h370-type FLOAT64
   obj-h374-expr int(100000*$val)/10000
   obj-h374-reading RealEnergyDeliveredSum
   obj-h374-type FLOAT64
   room       tesla
   stateFormat Mode3State_ Ladestrom: ActualAppliedMaxCurrent A Ladeleistung: RealPowerSum W NoP: Charge_with_1_or_3_phases
   userReadings Mode3State_ {my $M3state = ReadingsVal($name,"Mode3State",-1);
if($M3state =~ /A/ ){
return "EVSE ready and standby";
} elsif($M3state =~ /B1/ ){
return "EV connected to EVSE";
} elsif($M3state =~ /B2/ ){
return "charging approved by EVSE";
} elsif($M3state =~ /C1/ ){
return "charging approved by EV, but not by EVSE";
} elsif($M3state =~ /C2/ ){
return "charging in progress";
} elsif($M3state =~ /D1/ ){
return "ventilated charging approved by EV, but not by EVSE";
} elsif($M3state =~ /D2/ ){
return "ventilated charging in progress";
} elsif($M3state =~ /E/ ){
return "Error inside Vehicle";
} elsif($M3state =~ /F/ ){
return "Error inside Wallbox";
}
},
Fzg_angeschlossen {my $M3state = ReadingsVal($name,"Mode3State",-1);
if($M3state =~ /A/ ){
return "Kein Fahrzeug angeschlossen";
} else{
return "Fahrzeug angeschlossen";
}
},
Laden_moeglich {my $M3state = ReadingsVal($name,"Mode3State",-1);
if($M3state =~ /[CD]/ ){
return "Laden moeglich";
} else{
return "Laden nicht moeglich";
}
}


   verbose    5
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mBielemeier am 26 Oktober 2021, 21:08:11
Hallo Stephan / abc2006,

wenn ich das richtig sehe müsste es
dev-type-FLOAT64-unpack d>
sein. Per Excel ausgerechnet ergibt 411869b000000000 als double in IEEE-Format 399976 Wh.

Viele Grüße,
Manfred
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 26 Oktober 2021, 22:50:32
Hallo Manfred, vielen vielen Dank! (Es funktioniert:)
Für den Lerneffekt: kannst du mir kurz erklären, wie ich da selbst hätte draufkommen können - und mir ggf. das Excel zur Verfügung stellen?

Viele Grüße,
Stephan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mBielemeier am 26 Oktober 2021, 23:08:35
Hallo Stephan,

ich knoble gerne: erst mal nach Float64 gesucht und hier https://gertingold.github.io/eidprog/floats.html eine gute Beschreibung gefunden. Deine HEX-Zahl habe ich zu Binär gewandelt und Excel nur dazu gebraucht die vielen 2^x zu berechnen und aufzusummieren. Nachdem daraus wirklich die ca. 400kWh wurden musste es ja ein passendes unpack geben und das habe ich hier https://perldoc.perl.org/functions/pack gefunden. Das ">" muss dann noch hinter das "d" da die wichtigen Ziffern ja links sind, also big endian format.

Freut mich, dass ich helfen konnte.

Viele Grüße,
Manfred
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RaKoHe am 17 November 2021, 12:23:54
Moin Stefan,

nach einigen Problemen mit dem Kanalgenerator(Goldcap defekt) kann ich mit deiner Änderung für Doepke die Register zuverlässig auslesen und schalten.

Ich lese jetzt 14 von den 128 Register aus. Tendenz steigend.
Nun frage ich mich ob es sinnvoller wäre(um den Traffic zu reduzieren) besser alle Register mit einem Befehl auszulesen.

Beim probieren habe ich ein scanModbusObjects(h0-7) gemacht, was auch funktioniert hat.
Leider hat dann der Befehl scanStop FHEM zum Absturz gebracht:

Undefined subroutine &Modbus::asyncOutput called at ./FHEM/98_Modbus.pm line 1191.
2021.11.16 22:03:46 3: $name: scanStop - try asyncOutput to $hash

Gleiches Verhalten nach Modulupdate.

Wobei dann natürlich die Doepke Anpassung weg war.
Kommt die Änderung in das nächste offiziele Update?



Wenn mir noch jemand einen Tipp geben könnte wie ich aus


2021.11.17 11:45:59 5: ALLDUPATTR: ParseDataString called from HandleResponse with data hex 00400050000000010000000001000042, type h, adr 0, op read
request: id 1, read fc 3 h0, len 8, master device ALLDUPATTR, reading alles (getUpdate for alles len 8)


die 128 Kanäle(A1/A8 bis P1/P8) unpacken muss.
00 40 00 50 00 00 00 01 00 00 00 00 01 00 00 42

laut der Doku:
00 ist das Register 1 High mit den Kanälen B8-B1
40  Register 1 Low A8-A1
00 ist das Register 2 High mit den Kanälen D8-D1
usw...

Bin etwas weiter gekommen unpack H* :-)

Vielen Dank

Mit sonnigen Grüßen

Ralf



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Apollon am 23 November 2021, 10:58:53
Hallo,

mein Vorhaben, einen Zweirichtungsdrehstromzähler mit einem RS485 / Ethernetkonverter vom Elektriker installieren zu lassen, hatte ich schon verworfen,  weil mir das Know-how für die Einrichtung und Einbindung in FHEM fehlt.

Dieser Beitrag hier zeigt mir, dass sich schon einige Leute mit diesem oder ähnlichen Problemen beschäftigt haben.

Nun zu meiner Frage oder besser zu meiner Bitte. Ist jemand in der Lage, mir Hilfestellung bei der Konfiguration und Einbindung in FHEM zu geben?
Vorgesehen ist folgende Hardware:

https://stromzähler.eu/stromzaehler/drehstromzaehler/fuer-hutschiene-geeicht/246/sdm72dm-v2-mid-3-phasen-zweirichtungs-drehstromzaehler-mit-rs485-und-s0?c=97 (https://xn--stromzhler-v5a.eu/stromzaehler/drehstromzaehler/fuer-hutschiene-geeicht/246/sdm72dm-v2-mid-3-phasen-zweirichtungs-drehstromzaehler-mit-rs485-und-s0?c=97)
und
https://www.amazon.de/dp/B095HBL9QC/?coliid=I2TU7MXQBD6IDP&colid=1FEP8L3MKLREF&psc=1&ref_=lv_ov_lig_dp_it (https://www.amazon.de/dp/B095HBL9QC/?coliid=I2TU7MXQBD6IDP&colid=1FEP8L3MKLREF&psc=1&ref_=lv_ov_lig_dp_it)

Der Konverter ist bereits vorhanden und zu Testzwecken im Netz eingebunden.

Gruß
Apollon
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 November 2021, 20:28:13
Hallo Ralf,

da hast Du einen Bug gefunden.
Bitte teste doch mal, ob der in dem angehängten Modul behoben ist.
Die neue Version würde ich auch einchecken. Allerdings haben sich inzwischen einige Änderungen angesammelt und ich würde mich wohler fühlen, wenn ein paar Anwender das neue Modul vorher testen und hier posten ob noch alles funktioniert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 November 2021, 20:34:43
Hallo Apollon,

die Registerbelegung des Zählers für Modbus kann man einfach runterladen. Die direkte Einbindung per RS485 in Fhem wäre also kein Problem. Wenn Du die alten Beiträge zum Modbus-Modul durchliest, findest Du mehrere Fälle, die ähnlich gelagert waren bzw. Anleitungen, wie man schrittweise vorgeht.
Zu Deinem Konverter kann ich jedoch nichts sagen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Apollon am 24 November 2021, 09:04:19
Hallo Stefan,

vielen Dank für deine Antwort. Ich habe gedacht, ich sei in diesem Beitrag richtig. Gesucht und gelesen habe ich schon sehr viel. Je mehr ich gelesen habe, umso verwirrender wurde es für mich.
Ich werde wohl einfach mal den Zähler kaufen und versuchen ihn in FHEM zu integrieren. Wenn es nicht funktioniert habe ich halt pech gehabt.

Gruß
Apollon
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RaKoHe am 24 November 2021, 18:45:33
Moin Stefan,

der Bug durch ScanStop ist weg.

Zum Spaß habe ich obj-h0-unpack 0 gemacht was zum sofortigen Absturz führte. ???
Invalid type '0' in unpack at ./FHEM/98_Modbus.pm line 2652.

Mit sonnigen Grüßen

Ralf
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: MiniBlister am 08 Dezember 2021, 08:56:50
Guten Morgen,

erst einmal vielen Dank für das tolle Module.
Ich bin dabei, ein Grundfos CIM200 Modul zu integrieren.

Was mir noch nicht ganz klar ist, wie ich ein Halteregister, welches mit functions code 0x06 oder 0x10 schreibbar ist bit weise mainipuliere (siehe bild im Anhang)
Ich stelle mir vor, dass ich aus mehreren userattr einen binären Wert generiere und dann über das -set auf das Register schreibe.

Gibt es da eine anderen Möglichkeit? Vielen Dank für die Hilfe
 
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Dezember 2021, 18:42:38
Hallo MiniBlister,

eine wirklich elegantere Lösung fällt mir auch nicht ein.
Wenn man einen unpack-Code hätte, der die Bit-Werte als Liste erzeugt, dann könnte das Modul daraus automatisch einzelne Readings erzeugen, aber so wie ich den unpack-Code "B" verstehe, erzeugt der leider einen String statt einer Liste.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 28 Dezember 2021, 10:43:21
Hallo Stefan,
ich hoffe Du hattest ein Frohes Fest..!
Bei uns gibt es ein nebengebäude - ein kleines Gartenhaus. In dem sorgt ein Pelletofen für Wärme.
Es ist ein MCZ Ego Air 2.0 mit Rauchabzug oben.

Es gibt von MCZ ein passendes WiFi Modul welches aber mit 320€ eindeutig zu teuer ist.

Beim durchforsten der zugehörigen dokumente ist mir aber aufgefallen das dieses WiFi Modul via Modbus an der Platine des Ofens angeschlossen wird.
Nun würde ich gerne versuchen den Ofen direkt via Modbus in FHEM zu integrieren.

Leider gibt es nicht wie sonst üblich eine Register beschreibung des Herstellers.

Wie hoch schätzt Du den Aufwand ein die notwendigen Register zu erforschen um an ende den Ofen steuern zu können...?

Was ist der eleganteste weg RS485 via Lan ins Netzwerk zu bringen?
Es wäre auch möglich einen eigenen Raspberry zu opfern, ich würde das aber gerne vermeiden.

- hat vielleicht sonst jemand einen MCZ Pelletofen am laufen und nutzt schon die Modbus anbindung?

Allen einen Guten Rutsch ins neue Jahr!

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 Dezember 2021, 13:35:37
Hallo,

das sollte in ein paar Tagen und mit genügend Geduld schon machbar sein.
Mit einem Register-Scan müsste man nach passenden Einträgen suchen, dann manuell am Gerät die relevanten Parameter einstellen und vergleichen, welche Register sich entsprechend ändern.
Am einfachsten wäre es natürlich wenn man das WLAN-Modul mal testweise anschließen könnte und dabei mit dem Fhem-Modbus-Modul im passiven Modus mitlauschen könnte, auf welche Register das zugreift .

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Cybers am 24 Januar 2022, 10:10:48
Hallo,

ich habe ein kleines Problem beim Anlegen eines Registers. Ich benutze die angehängte Datei für das Auslesen meines SDM72D-M Drehstromzählers. Grundsätzlich kann ich alle in der Datei hinterlegten Register auslesen.
Jetzt möchte ich aber den Tageszähler über Fhem resetten können. Für den Reset ist folgender Register zuständig:
Adress Register: 461457
Paramter: Reset historical data
Modbus Protocol, Start Address Hex: F0 / 10
Valid rang: 00 03 = reset energy info / Length : 2 byte /Data Format: Hex
Mode: wo
Hier noch der Link zur Übersicht der Register: https://stromzähler.eu/media/pdf/93/17/d7/SDM72DM-V2.pdf (https://xn--stromzhler-v5a.eu/media/pdf/93/17/d7/SDM72DM-V2.pdf)

In Zeile 187-198 der angehängten Datei habe ich mal einen Anfang gewagt, komme aber nicht weiter.
"h61457" => { # holding register 0x0014
# Write the network port node address: 1 to 247 for MODBUS Protocol, default 1.
# Requires a restart to become effective.
# https://data.stromzähler.eu/eastron/SDM72DM-manual.pdf
name => "Reset", # internal name of this register in the hardware doc
reading => "Reset", # name of the reading for this value
min => 1, # input validation for set: min value
max => 247, # input validation for set: max value
format => '%u', # format string for sprintf
poll => "once", # only poll once after define (or after a set)
set => 1, # this value can be set
},


Kann mir einer helfen?

Gruß, Sascha
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 Januar 2022, 18:12:59
Hallo Cybers,

Du musst von den in Hex angegebenen Protokolladressen ausgehen.
Dein Register hat die Adresse F010, das ist dezimal 61456, nicht 61457.
Zudem ist das Register als write only angegeben. Ich würde deshalb gar nicht erst versuchen, es zu lesen. Auch nicht mit "once".
Format %u würde ich weglassen. Dafür ist es aber wichtig, den passenden unpack-code anzugeben. Der wird auch für das Packen beim set verwendet.
Bisher greift hier die Angabe von weiter oben in Deinem File:
Zitat
defUnpack   =>   "f>",   # default pack / unpack code to convert raw values, e.g. "n" for a 16 bit integer oder
Das wäre ein Float, der über zwei Register geht. Du brauchst aber n oder eventuell v.
Die Angaben von min und max kannst Du auf 3 setzen, wenn 3 der einzig akzeptierte Wert ist.
Und dann wäre da noch der function code. Laut Anleitung möchte der Zähler mit function code 10 (hex) beschrieben werden, aber das steht in Deinem File schon so drin (write    => 16), sollte also passen.
Ich hoffe da fehlt nicht noch was ;-)

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 24 Januar 2022, 21:26:44
Hallo zusammen,

ich bin dabei, ein Modbus Relaisboard von Waveshare (https://www.waveshare.com/modbus-rtu-relay.htm (https://www.waveshare.com/modbus-rtu-relay.htm)) in Betrieb zu nehmen. Modbusprotokoll siehe hier: https://www.waveshare.com/wiki/Protocol_Manual_of_Modbus_RTU_Relay (https://www.waveshare.com/wiki/Protocol_Manual_of_Modbus_RTU_Relay). Einzelne Relais schalten geht, bei den restlichen Funktionen stehe ich aber an: das Board hält sich leider nicht an die Spezifikationen und "missbraucht" Coils als Holding Registers wenn ich das richtig verstanden habe:


Command:01 05 00 FF FF FF FC 4A

Byte    Meaning         Description
01      Device address  0x00 is broadcast;0x01-0xFF are devices address
05      05 command      Command for controlling Relay
00 FF   Address         Fixed 0x00FF
FF FF   Command         0xFFFF:Open Relay;
FC 4A   CRC16           The CRC checksum of the first six bytes


Dieser Befehl schaltet alle Relais ein. Es wird hierfür ein "Coil write" (05) verwendet, der "Command" ist aber nicht "FF 00" sondern "FF FF". Für andere Befehle wird wiederum "FF 00" oder auch "55 00" (toggelt ein Relais) verwendet, dev-c-brokenFC5 65535 z.B. fällt also flach da in der Sichtweise des Herstellers ein Coil nicht 0 oder 1 ist sondern durchaus auch mehrere Werte aufweisen kann  :(

Ich habe mit dev-h-write 5 versucht, Holding Registers als "Coils" zu verwenden, das klappt aber leider auch nicht: es wird immer "FF 00" gesendet sobald ich das Holding Register auf einen Wert !=0 setze (also scheint Modbus_Attr intern das Holding Register dann als Coil zu betrachten).

Hier ein Beispiel:


attr Waveshare_Relay obj-h255-reading Alle_Relais
attr Waveshare_Relay obj-h255-set 1
attr Waveshare_Relay obj-h255-unpack n


führt zu folgendem Logeintrag (auf den Befehl set Waveshare_Relay Alle_Relais 65535)


2022.01.24 20:58:40.100 4: ModBusUSBStick: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 010600ffffffb84a via /dev/ttyUSB4@9600, read buffer empty


Das wäre fast das was ich bräuchte (010500fffffffc4a). Also 05 statt 06. Verwende ich attr Waveshare_Relay dev-h-write 5 gibt es folgenden Logeintrag:


2022.01.24 21:21:39.449 4: ModBusUSBStick: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 010500ffff00bc0a via /dev/ttyUSB4@9600, read buffer empty,


Auch wieder nur fast das was ich bräuchte (010500fffffffc4a).

Hat da irgendjemand einen Lösungsansatz für mich? Meine Idee wäre: da ich einzelne Relais grundsätzlich an- und abschalten kann würde ich mir ein DOIF o.ä. basteln das nacheinander alle Relais an- oder abschaltet. Elegant ist das nicht (was, wenn >1 Befehle verloren gehen).....

Beste Grüsse, Anton
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Cybers am 25 Januar 2022, 08:01:10
Zitat von: StefanStrobel am 24 Januar 2022, 18:12:59
Hallo Cybers,

Du musst von den in Hex angegebenen Protokolladressen ausgehen.
Dein Register hat die Adresse F010, das ist dezimal 61456, nicht 61457.
Zudem ist das Register als write only angegeben. Ich würde deshalb gar nicht erst versuchen, es zu lesen. Auch nicht mit "once".
Format %u würde ich weglassen. Dafür ist es aber wichtig, den passenden unpack-code anzugeben. Der wird auch für das Packen beim set verwendet.
Bisher greift hier die Angabe von weiter oben in Deinem File:Das wäre ein Float, der über zwei Register geht. Du brauchst aber n oder eventuell v.
Die Angaben von min und max kannst Du auf 3 setzen, wenn 3 der einzig akzeptierte Wert ist.
Und dann wäre da noch der function code. Laut Anleitung möchte der Zähler mit function code 10 (hex) beschrieben werden, aber das steht in Deinem File schon so drin (write    => 16), sollte also passen.
Ich hoffe da fehlt nicht noch was ;-)

Gruss
   Stefan

Hallo Stefan,

vielen Dank für deine Antwort. Ich habe es entsprechend geändert und die Definition für den Reset erweitert:
"s" => { # details for "setting reset" if the device offers them
read => 3, # use function code 3 to read holding registers.
write => 16, # use function code 6 to write holding registers (alternative could be 16)
defLen => 2, # default length (number of registers) per value (e.g. 2 for a float of 4 bytes that spans 2 registers)
# can be overwritten in parseInfo per reading by specifying the key "len"
combine => 10, # allow combined read of up to 10 adjacent registers during getUpdate
defUnpack => "v", # default pack / unpack code to convert raw values, e.g. "n" for a 16 bit integer oder
# "f>" for a big endian float IEEE 754 floating-point numbers
# can be overwritten in parseInfo per reading by specifying the key "unpack"
defShowGet => 1, # default für showget Key in parseInfo
},


"s61456" => { # holding register 0x0014
# Write the network port node address: 1 to 247 for MODBUS Protocol, default 1.
# Requires a restart to become effective.
# https://data.stromzähler.eu/eastron/SDM72DM-manual.pdf
name => "Reset", # internal name of this register in the hardware doc
reading => "Reset", # name of the reading for this value
min => 3, # input validation for set: min value
max => 3, # input validation for set: max value
# format => '%u', # format string for sprintf
# poll => "once", # only poll once after define (or after a set)
set => 1, # this value can be set
},



Ich bekommen aber immer den Fehler "Timeout in Readanswer". Egal ob ich bei "defUnpack" v oder n einsetze. Bei f> bekam ich folgendes als Rückmeldung: 2.52435489670724e-29
Oder muß ich in der 98_Modbus.pm auch noch was ändern da ich ja die neue "Variabel" "s" hinzugfügt habe?

Im Anhang wieder die komplette geänderte Datei.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 25 Januar 2022, 13:21:20
Hallo zusammen,
ich stehe vor der Problematik, dass ich ein Gerät ersetzt bekomme, was jedoch einen Zähler für "Total" Werte hat. Dieser würde jedoch mit dem Austausch wieder bei null anfangen.
Könnte ich im ModBus reading die monotonic() Funktion mit einbauen, sodaß der Wert im FHEM Device einfach weiter zählt, ohne dass ich ein weiteres reading erzeuge?

EDIT:
Sorry, beim Modul ModBus funktioniert der modifier monotonic . Die Fehlermeldung betraf httpmod und ist dann dort zu finden.

VG
    Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 25 Januar 2022, 16:48:48
Blöde Frage: wieso addierst du nicht den alten Stand zum neuen Stand dazu (in einem Userreading z.B.)? Also ReadingsVal("$NAME","Statistic_Yield_Total",0)+123456}?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 25 Januar 2022, 17:04:20
Zitat von: ansgru am 25 Januar 2022, 16:48:48
Blöde Frage: wieso addierst du nicht den alten Stand zum neuen Stand dazu (in einem Userreading z.B.)? Also ReadingsVal("$NAME","Statistic_Yield_Total",0)+123456}?
Weil das dann bei jedem Wechsel und bei einigen Geräten bei jedem Reset (Shelly) gemacht werden müsste.

Mit modifier monotonic wird im Hintergrung genau das gemacht und man muss nicht mehr selber darauf achten.

Leider ist mir gerade aufgefallen, dass es beim Modul Modbus funktioniert. Das Device mit dem Fehler ist httpmod.
Ich ziehe dann mal mit meinem Post in den anderern Thread um und mache hier eine Verlinkung (https://forum.fhem.de/index.php/topic,45176.msg1203382.html#msg1203382).
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 25 Januar 2022, 17:07:29
Hallo Cybers,

da habe ich mich wohl nicht klar ausgedrückt. Wenn Du im Device-Info hash ein "s" hinzufügst, hat das erst mal gar keine Auswirkungen. Gültige Objekt-Typen sind nur h für holding register, i für input register, c für coil und d für digital inputs. Andere Werte sind im Basis-Modul nicht vorgesehen und werden hoffentlich immer ignoriert.
Im Device-Info-Hash stehen meist nur die Defaults. Für jedes einzelne Objekt kann man das im Objekt überschreiben. Statt defUnpack im Device-Info-Hash einfach unpack im jeweiligen Objekt benutzen. Die Namen entsprechen übrigens den Attributen von ModbusAttr. In dessen Doku findest Du hoffentlich alle Details. Zum Testen kannst Du auch die Werte jederzeit mit den Attributen von ModbusAttr überschreiben. Du kannst ModbusSDM72DM als vorkonfigurierte Variante von ModbusAttr betrachten. Bitte schau Dir die Doku dazu mal an.
Wenn es dann immer noch nicht klappt, hilft es das verbose-Attribut für Dein Device und sein IO-Device auf 5 zu setzen. Dann steht sehr viel im Log und wenn man das Zeile für Zeile liest, kann man sehen, was intern passiert. Wenn Du den Auszug aus dem Log postest, kann ich auch drauf schauen.

Gruss
   Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 25 Januar 2022, 17:46:59
Hallo Anton,

die Doku von Waveshare ist gruselig. Vermutlich hat da jemand die Modbus-Specs schlecht auf chinesisch übersetzt, dann was kreatives programmiert und am Schluss die chinesische Doku wieder schlecht auf englisch übersetzt...
Aber ganz so schlimm ist es vermutlich doch nicht. Wenn man die echte Spezifikation daneben legt, gibt es durchaus Parallelitäten ;-)
(siehe https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf)

Wenn Du die Relais schon mal einzeln schalten kannst und nur  dev-c-brokenFC5 65535 dafür nötig ist, dann fehlt ja nur die Sonderfunktion zum Toggeln. Das könntest Du drum herum bauen (abhängig vom bisherigen Status schließen oder öffnen) oder ich müsste es im Basismodul als Sonderfall ergänzen.

Dann fehlt noch das Lesen aller Coils gleichzeitig.
Mit korrektem Modbus-Befehl kann man bei fc1 die Länge angeben. Das Modbus-Modul macht das implizit über die Kombination von Lesebefehlen in einem Update-Zyklus. Explizit per get mehrere Objekte gleichzeitig zu lesen ist so im Modul nicht vorgesehen, aber wenn Das Gerät eh nur 8 Relais hat, könnte man mit set reread auch alle Objekte auf einmal lesen lassen und per combine sollte daraus ein einziger Lese-Befehl mit Länge 8 werden.

Das Schreiben von 8 Coils auf einmal ist ein anderes Thema. Function code 15 (0f) ist dafür vorgesehen, aber bisher hat das noch niemand benötigt. Im Modul ist der Befehl bisher nicht implementiert. Das kann man auch nicht mit holding-Registern hinbiegen. Jeder function code hat ja seine eigene Definition.
Ich müsste auch erst mal überlegen, wie man das sinnvoll abbilden kann. Das Modbus-Modul sieht ja bisher eine einzelne Definition je Objekt vor. In diesem Fall müste man z.B. beim Set mehrere Werte übergeben, die dann auf aufeinander folgende Objekte geschrieben werden...
Ich werde mal drüber nachdenken.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Cybers am 25 Januar 2022, 19:33:29
Zitat von: StefanStrobel am 25 Januar 2022, 17:07:29
Hallo Cybers,

da habe ich mich wohl nicht klar ausgedrückt. Wenn Du im Device-Info hash ein "s" hinzufügst, hat das erst mal gar keine Auswirkungen. Gültige Objekt-Typen sind nur h für holding register, i für input register, c für coil und d für digital inputs. Andere Werte sind im Basis-Modul nicht vorgesehen und werden hoffentlich immer ignoriert.
Im Device-Info-Hash stehen meist nur die Defaults. Für jedes einzelne Objekt kann man das im Objekt überschreiben. Statt defUnpack im Device-Info-Hash einfach unpack im jeweiligen Objekt benutzen. Die Namen entsprechen übrigens den Attributen von ModbusAttr. In dessen Doku findest Du hoffentlich alle Details. Zum Testen kannst Du auch die Werte jederzeit mit den Attributen von ModbusAttr überschreiben. Du kannst ModbusSDM72DM als vorkonfigurierte Variante von ModbusAttr betrachten. Bitte schau Dir die Doku dazu mal an.
Wenn es dann immer noch nicht klappt, hilft es das verbose-Attribut für Dein Device und sein IO-Device auf 5 zu setzen. Dann steht sehr viel im Log und wenn man das Zeile für Zeile liest, kann man sehen, was intern passiert. Wenn Du den Auszug aus dem Log postest, kann ich auch drauf schauen.

Gruss
   Stefan

Ich habe es mal wir folgt angelegt:
defmod Testzaehler ModbusAttr 1 10
attr Testzaehler dev-h-combine 10
attr Testzaehler dev-h-defLen 2
attr Testzaehler dev-h-defUnpack n
attr Testzaehler dev-h-read 3
attr Testzaehler dev-h-write 16
attr Testzaehler obj-h61456-max 3
attr Testzaehler obj-h61456-min 3
attr Testzaehler obj-h61456-name Reset
attr Testzaehler obj-h61456-reading Reset
attr Testzaehler obj-h61456-set 1
attr Testzaehler obj-h61456-showGet 1
attr Testzaehler room Photovoltaik

setstate Testzaehler opened
setstate Testzaehler 2022-01-25 10:23:38 Reset 4096
setstate Testzaehler 2022-01-25 10:36:12 state opened


Log:
request: id 1, write fc 16 h61456, len 2, value 0003, master device Testzaehler, reading Reset (set Reset)
2022.01.25 19:27:32 4: Testzaehler: DoRequest called from SetLDFn created new request, read buffer empty,
2022.01.25 19:27:32 5: Testzaehler: set packed hex 33 with n to hex 0003
2022.01.25 19:27:32 5: Testzaehler: checkRange for FormatSetVal checks 3 against max 3
2022.01.25 19:27:32 5: Testzaehler: checkRange for FormatSetVal checks 3 against min 3
2022.01.25 19:27:32 5: Testzaehler: GetSetChecks returns success
2022.01.25 19:27:32 5: Testzaehler: GetSetChecks with force
2022.01.25 19:27:32 4: Testzaehler: set called with Reset (h61456) setVal = 3
2022.01.25 19:27:29 4: Testzaehler: GetUpdate will now create requests for
2022.01.25 19:27:29 5: Testzaehler: CombineUpdateHash keys are now
2022.01.25 19:27:29 5: Testzaehler: CombineUpdateHash tries to combine read commands
2022.01.25 19:27:29 4: Testzaehler: CombineUpdateHash objHash keys before combine:
2022.01.25 19:27:29 5: Testzaehler: CreateUpdateList full object list: h61456
2022.01.25 19:27:29 4: Testzaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 19:27:39.873, interval 10
2022.01.25 19:27:29 4: Testzaehler: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2022.01.25 19:27:21 5: Testzaehler: UpdateSetList: getList=Reset:noArg
2022.01.25 19:27:21 5: Testzaehler: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects scanModbusId inactive active Reset
2022.01.25 19:27:19 4: Testzaehler: GetUpdate will now create requests for
2022.01.25 19:27:19 5: Testzaehler: CombineUpdateHash keys are now
2022.01.25 19:27:19 5: Testzaehler: CombineUpdateHash tries to combine read commands
2022.01.25 19:27:19 4: Testzaehler: CombineUpdateHash objHash keys before combine:
2022.01.25 19:27:19 5: Testzaehler: CreateUpdateList full object list: h61456
2022.01.25 19:27:19 4: Testzaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 19:27:29.872, interval 10
2022.01.25 19:27:19 4: Testzaehler: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer


Fehler: Timeout in Readanswer
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 25 Januar 2022, 21:53:26
Hallo Cybers,

ohne verbose 5 auch auf dem IO-Device fehlen leider die entscheidenden Details im Log :-)

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Cybers am 25 Januar 2022, 22:40:45
2022.01.25 22:31:54 3: Modbus: Timeout in Readanswer, read buffer empty,
2022.01.25 22:31:52 5: Modbus: ReadAnswer remaining timeout is 1.99214100837708
2022.01.25 22:31:52 5: Modbus: ReadAnswer called from SetLDFn
2022.01.25 22:31:52 5: Modbus: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.01.25 22:31:52 5: DevIo_SimpleWrite Modbus: 0110f0100002040003f48b
2022.01.25 22:31:52 5: Modbus: Send called from ProcessRequestQueue
request: id 1, write fc 16 h61456, len 2, value 0003, master device Testzaehler, reading Reset (set Reset), queued 0.00 secs ago
2022.01.25 22:31:52 4: Modbus: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 0110f0100002040003f48b via /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@9600, read buffer empty,
2022.01.25 22:31:52 5: Modbus: checkDelays sendDelay, last send to same device was 10662.815 secs ago, required delay is 0.1
2022.01.25 22:31:52 5: Modbus: checkDelays clientSwitchDelay is not relevant
2022.01.25 22:31:52 5: Modbus: checkDelays commDelay, last communication with same device was never, required delay is 0.1
2022.01.25 22:31:52 5: Modbus: checkDelays busDelayRead, last activity on bus was 0.117 secs ago, required delay is 0
2022.01.25 22:31:52 5: Modbus: ProcessRequestQueue called from QueueRequest as direct:Modbus, qlen 2, force, request: request: id 1, write fc 16 h61456, len 2, value 0003, master device Testzaehler, reading Reset (set Reset), queued 0.00 secs ago
2022.01.25 22:31:52 5: Modbus: QueueRequest called from DoRequest with h61456, qlen 1 from master Testzaehler through io device Modbus
request: id 1, write fc 16 h61456, len 2, value 0003, master device Testzaehler, reading Reset (set Reset)
2022.01.25 22:31:52 4: Testzaehler: DoRequest called from SetLDFn created new request, read buffer empty,
2022.01.25 22:31:52 5: Testzaehler: set packed hex 33 with n to hex 0003
2022.01.25 22:31:52 5: Testzaehler: checkRange for FormatSetVal checks 3 against max 3
2022.01.25 22:31:52 5: Testzaehler: checkRange for FormatSetVal checks 3 against min 3
2022.01.25 22:31:52 5: Testzaehler: GetSetChecks returns success
2022.01.25 22:31:52 5: Testzaehler: GetSetChecks with force
2022.01.25 22:31:52 4: Testzaehler: set called with Reset (h61456) setVal = 3
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 26 Januar 2022, 12:52:03
Hallo Cybers,

Du versuchst gleich zwei Register auf einmal zu schreiben.
Laut der Anleitung Deines Geräts möchte das aber nur ein Objekt gleichzeitig.
Setz doch mal die Länge auf 1 statt auf 2.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Cybers am 26 Januar 2022, 13:45:08
Hallo Stefan,

das war es. Jetzt läuft es. Vielen Dank für deine Hilfe.

Gruß, Sascha
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 26 Januar 2022, 21:16:09
Hallo Stefan,

besten Dank für deine Antwort!

Zitat von: StefanStrobel am 25 Januar 2022, 17:46:59
die Doku von Waveshare ist gruselig. Vermutlich hat da jemand die Modbus-Specs schlecht auf chinesisch übersetzt, dann was kreatives programmiert und am Schluss die chinesische Doku wieder schlecht auf englisch übersetzt...
100% einverstanden :-)

ZitatWenn Du die Relais schon mal einzeln schalten kannst und nur  dev-c-brokenFC5 65535 dafür nötig ist, dann fehlt ja nur die Sonderfunktion zum Toggeln. Das könntest Du drum herum bauen (abhängig vom bisherigen Status schließen oder öffnen) oder ich müsste es im Basismodul als Sonderfall ergänzen.

Das geht leider nicht weil einzelne Relais ein FF 00 erwarten als Befehl zum einschalten (resp. 55 00 für ein Toggle), das Schalten aller Relais aber ein FF FF. Mit dev-c-brokenFC5 kann ich ja nur global den zu senden Wert zum Aktivieren eines Coils festlegen wenn ich das richtig verstanden habe?

ZitatDann fehlt noch das Lesen aller Coils gleichzeitig.
Mit korrektem Modbus-Befehl kann man bei fc1 die Länge angeben. Das Modbus-Modul macht das implizit über die Kombination von Lesebefehlen in einem Update-Zyklus. Explizit per get mehrere Objekte gleichzeitig zu lesen ist so im Modul nicht vorgesehen, aber wenn Das Gerät eh nur 8 Relais hat, könnte man mit set reread auch alle Objekte auf einmal lesen lassen und per combine sollte daraus ein einziger Lese-Befehl mit Länge 8 werden.

Das Schreiben von 8 Coils auf einmal ist ein anderes Thema. Function code 15 (0f) ist dafür vorgesehen, aber bisher hat das noch niemand benötigt. Im Modul ist der Befehl bisher nicht implementiert. Das kann man auch nicht mit holding-Registern hinbiegen. Jeder function code hat ja seine eigene Definition.
Ich müsste auch erst mal überlegen, wie man das sinnvoll abbilden kann. Das Modbus-Modul sieht ja bisher eine einzelne Definition je Objekt vor. In diesem Fall müste man z.B. beim Set mehrere Werte übergeben, die dann auf aufeinander folgende Objekte geschrieben werden...
Ich werde mal drüber nachdenken.

Hmmm, ich habe noch einen völlig anderen Ansatz: wie wäre es, wenn ich pro Register mit einem zusätzlichen Flag angeben kann, welcher Function Code verwendet werden soll? Also ein obj-[ih][1-9][0-9]*-overrideFC? Die Funktionsweise wäre dann wie folgt: ich würde für das Schalten der Relais "Holding Register Objekte" definieren (also obj-h255-reading statt obj-c255-reading) und zusätzlich ein obj-h255-overrideFC 5. Also ähnlich wie dev-([cdih]-)*write|read ABER pro Register UND intern würde Modbus.pm in diesem Beispiel h255 intern als Holding Register behandeln und nur in der Kommunikation den gewählten FC verwenden. Bei dev*write|read ist es ja so, dass - wenn ich z.B. dev-h-write 5 definiere - alle Holding Registers fortan als Coils betrachtet werden und ich damit wieder keine individuellen Werte wie FF FF, FF 00 individuell pro Register definieren kann.

Der Pseudocode für das Erstellen der Pakete könnte dann wie folgt aussehen:


if ($fCode == 6) { // $fCode ist der Modbus.pm interne Function Code, hier also ein Holding Register
my $actualFC = $fCode;
if ($overrideFC) $actualFC = $overrideFC;
// Dann wird das Paket versandt mit $actualFC -> in unserem Beispiel also mit 05 statt 06
}


Der empfangende Code wüsste dann anhand der Registeradresse analog dazu, ob z.B. ein obj-h255-overrideFC 5 definiert ist und welcher FC entsprechend erwartet wird. Würde das so Sinn machen? Ich habe das Gefühl, das würde einige Flexibilität bieten für nicht normgerechte Implementationen?

Beste Grüsse, Anton
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Cybers am 27 Januar 2022, 12:30:52
Hallo Stefan,
ich habe doch noch ein kleines Problem. Ich habe die Werte aus dem Testdevice mit denen es dann lief in meine 98_ModbusSDM72DM.pm übernommen. Damit geht es dann nicht mehr. Irgendetwas habe ich noch falsch übertragen.
Hier mein funktionierender Testdevice:
defmod Testzaehler ModbusAttr 1 10
attr Testzaehler dev-h-combine 10
attr Testzaehler dev-h-defLen 1
attr Testzaehler dev-h-defUnpack n
attr Testzaehler dev-h-read 3
attr Testzaehler dev-h-write 16
attr Testzaehler obj-h61456-max 3
attr Testzaehler obj-h61456-min 3
attr Testzaehler obj-h61456-name Reset
attr Testzaehler obj-h61456-reading Reset
attr Testzaehler obj-h61456-set 1
attr Testzaehler obj-h61456-showGet 1
attr Testzaehler room Photovoltaik


Hier die Zeilen in meiner 98_ModbusSDM72DM.pm:
"h61456" => { # holding register 0x0014
# Write the network port node address: 1 to 247 for MODBUS Protocol, default 1.
# Requires a restart to become effective.
# https://data.stromzähler.eu/eastron/SDM72DM-manual.pdf
name => "Reset", # internal name of this register in the hardware doc
reading => "Reset", # name of the reading for this value
min => 3, # input validation for set: min value
max => 3, # input validation for set: max value
# format => '%u', # format string for sprintf
# poll => "once", # only poll once after define (or after a set)
defLen => 1, # default length (number of registers) per value (e.g. 2 for a float of 4 bytes that spans 2 registers)
set => 1, # this value can be set
# map => "3:Reset",
defUnpack => "n",
},


Im Anhang noch meine komplette 98_ModbusSDM72DM.pm

Edit: Fehler gefunden und Problem gelöst. Aus "defLen" und "defUnpack" muss "len" und "unpack" werden.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 28 Januar 2022, 12:08:28
Moin Stefan,
ich muss mich auch mal wieder mit einer Frage anschließen:

Kannst du mir helfen, diese Logmeldungen zu deuten und einen Fehler zu finden?
Ich bin der Meinung, dass es anfangs einwandfrei lief - jetzt hab ich immer größere Aussetzer in Fhem - und habe die Updaterate schon verringert...

Grüße,
Stephan
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: ProcessRequestQueue called from Fhem internal timer as queue:alfen_Socket_aussen, qlen 2, request: request: id
1, read fc 3 h1208, len 2, tid 87, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemaining len 2),
queued 6.17 secs ago
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: checkDelays sendDelay, last send to same device was 0.265 secs ago, required delay is 0.1
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: checkDelays commDelay, last communication with same device was 0.115 secs ago, required delay is 0.1
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: checkDelays clientSwitchDelay is not relevant
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: checkDelays busDelayRead, last activity on bus was 0.115 secs ago, required delay is 0
2022.01.28 12:46:19.486 4: alfen_Socket_aussen: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 005700000006010304b80002 via 192.168.0.49:502, read b
uffer empty,
request: id 1, read fc 3 h1208, len 2, tid 87, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemain
ing len 2), queued 6.17 secs ago
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: Send called from ProcessRequestQueue
2022.01.28 12:46:19.486 5: DevIo_SimpleWrite alfen_Socket_aussen: 005700000006010304b80002
2022.01.28 12:46:19.488 5: alfen_Socket_aussen: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.01.28 12:46:19.618 5: alfen_Socket_aussen: readFn buffer: 0057000000070103040000012b
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.01.28 12:46:19.619 4: alfen_Socket_aussen: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 87, dlen 7 and potential data 040000012b
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: HandleResponse called from ReadFn
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: ParseResponse called from HandleResponse
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: now parsing response data objects, master is alfen_Socket_aussen relay is undefined
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: ParseDataString called from HandleResponse with data hex 0000012b, type h, adr 1208, op read
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: SplitDataString called from ParseDataString with data hex 0000012b, type h, adr 1208, valuesLen 2, op read
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: CreateDataObjects called from ParseDataString with objList h1208
2022.01.28 12:46:19.620 5: alfen_Socket_aussen: CreateDataObjects sortedList h1208
2022.01.28 12:46:19.620 5: alfen_Socket_aussen: CreateDataObjects unpacked 0000012b with L> to 299
2022.01.28 12:46:19.620 4: alfen_Socket_aussen: CreateDataObjects assigns value 299 to MaxCurrentValidTimeRemaining
2022.01.28 12:46:19.636 4: alfen_Socket_aussen: set called with Charge_Current (h1210) setVal = 0
2022.01.28 12:46:19.636 5: alfen_Socket_aussen: GetSetChecks with force
2022.01.28 12:46:19.636 4: alfen_Socket_aussen: GetSetChecks calls ReadAnswer to take over async read, still waiting for response, current frame / read buffer:
0057000000070103040000012b, id 1, fCode 3, tid 87,
request: id 1, read fc 3 h1208, len 2, tid 87, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemain
ing len 2), queued 6.32 secs ago, sent 0.15 secs ago,
response: id 1, fc 3, h1208, len 2, values 0000012b
2022.01.28 12:46:19.636 5: alfen_Socket_aussen: ReadAnswer called from GetSetChecks
2022.01.28 12:46:19.636 5: alfen_Socket_aussen: ReadAnswer remaining timeout is 1.84963798522949
2022.01.28 12:46:21.488 3: alfen_Socket_aussen: Timeout in Readanswer, current frame / read buffer: 0057000000070103040000012b, id 1, fCode 3, tid 87,
request: id 1, read fc 3 h1208, len 2, tid 87, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemain
ing len 2), queued 8.17 secs ago, sent 2.00 secs ago,
response: id 1, fc 3, h1208, len 2, values 0000012b
2022.01.28 12:46:21.488 5: alfen_Socket_aussen: DropFrame called from ReadAnswer - drop 0057000000070103040000012b
2022.01.28 12:46:21.489 5: alfen_Socket_aussen: GetSetChecks returns success
2022.01.28 12:46:21.489 5: alfen_Socket_aussen: set packed hex 30 with f> to hex 00000000
2022.01.28 12:46:21.490 4: alfen_Socket_aussen: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 16 h1210, len 2, value 00000000, tid 98, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current),
response: id 1, fc 3, h1208, len 2, values 0000012b
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: QueueRequest called from DoRequest with h1210, qlen 1 from master alfen_Socket_aussen through io device alfen_Socket_aussen
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: ProcessRequestQueue called from QueueRequest as direct:alfen_Socket_aussen, qlen 2, force, request: request: id 1, write fc 16 h1210, len 2, value 00000000, tid 98, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current), queued 0.00 secs ago
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: checkDelays clientSwitchDelay is not relevant
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: checkDelays busDelayRead, last activity on bus was 1.871 secs ago, required delay is 0
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: checkDelays commDelay, last communication with same device was 1.871 secs ago, required delay is 0.1
2022.01.28 12:46:21.491 5: alfen_Socket_aussen: checkDelays sendDelay, last send to same device was 2.003 secs ago, required delay is 0.1
2022.01.28 12:46:21.491 4: alfen_Socket_aussen: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 00620000000b011004ba00020400000000 via 192.168.0.49:502, read buffer empty,
request: id 1, write fc 16 h1210, len 2, value 00000000, tid 98, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current), queued 0.00 secs ago,
response: id 1, fc 3, h1208, len 2, values 0000012b
2022.01.28 12:46:21.491 5: alfen_Socket_aussen: Send called from ProcessRequestQueue
2022.01.28 12:46:21.491 5: DevIo_SimpleWrite alfen_Socket_aussen: 00620000000b011004ba00020400000000
2022.01.28 12:46:21.493 5: alfen_Socket_aussen: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.01.28 12:46:21.493 5: alfen_Socket_aussen: StartQueueTimer called from SetLDFn sets internal timer to process queue in 0.000 seconds
2022.01.28 12:46:21.493 5: alfen_Socket_aussen: ReadAnswer called from SetLDFn
2022.01.28 12:46:21.494 5: alfen_Socket_aussen: ReadAnswer remaining timeout is 1.99603891372681
2022.01.28 12:46:21.593 5: alfen_Socket_aussen: ReadAnswer got: 006200000006011004ba0002
2022.01.28 12:46:21.593 5: alfen_Socket_aussen: ParseFrameStart called from ReadAnswer protocol TCP expecting id 1
2022.01.28 12:46:21.593 4: alfen_Socket_aussen: ParseFrameStart (TCP, master) extracted id 1, fCode 16, tid 98, dlen 6 and potential data 04ba0002
2022.01.28 12:46:21.593 5: alfen_Socket_aussen: HandleResponse called from ReadAnswer
2022.01.28 12:46:21.594 5: alfen_Socket_aussen: ParseResponse called from HandleResponse
2022.01.28 12:46:21.594 4: alfen_Socket_aussen: HandleResponse done, current frame / read buffer: 006200000006011004ba0002, id 1, fCode 16, tid 98,
request: id 1, write fc 16 h1210, len 2, value 00000000, tid 98, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current), queued 0.10 secs ago, sent 0.10 secs ago,
response: id 1, fc 16, c1210, len 2
2022.01.28 12:46:21.594 5: alfen_Socket_aussen: ResetExpect for HandleResponse from response to idle
2022.01.28 12:46:21.594 5: alfen_Socket_aussen: DropFrame called from ReadAnswer - drop 006200000006011004ba0002
2022.01.28 12:46:21.594 5: alfen_Socket_aussen: set is sending read after write
2022.01.28 12:46:21.595 4: alfen_Socket_aussen: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, read fc 3 h1210, len 2, tid 199, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current Rd),
response: no id, no fcode
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: QueueRequest called from DoRequest with h1210, qlen 1 from master alfen_Socket_aussen through io device alfen_Socket_aussen
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: ProcessRequestQueue called from QueueRequest as direct:alfen_Socket_aussen, qlen 2, force, request: request: id 1, read fc 3 h1210, len 2, tid 199, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current Rd), queued 0.00 secs ago
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: checkDelays sendDelay, last send to same device was 0.103 secs ago, required delay is 0.1
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: checkDelays clientSwitchDelay is not relevant
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: checkDelays busDelayRead, last activity on bus was 0.002 secs ago, required delay is 0
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: checkDelays commDelay, last communication with same device was 0.002 secs ago, required delay is 0.1
2022.01.28 12:46:21.596 4: alfen_Socket_aussen: checkDelays found commDelay not over, sleep for 0.098 forced
2022.01.28 12:46:21.694 4: alfen_Socket_aussen: checkDelays sleep done, go on with sending
2022.01.28 12:46:21.694 4: alfen_Socket_aussen: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 00c700000006010304ba0002 via 192.168.0.49:502, read buffer empty,
request: id 1, read fc 3 h1210, len 2, tid 199, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current Rd), queued 0.10 secs ago,
response: no id, no fcode
2022.01.28 12:46:21.694 5: alfen_Socket_aussen: Send called from ProcessRequestQueue
2022.01.28 12:46:21.694 5: DevIo_SimpleWrite alfen_Socket_aussen: 00c700000006010304ba0002
2022.01.28 12:46:21.696 5: alfen_Socket_aussen: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.01.28 12:46:21.697 5: alfen_Socket_aussen: ReadAnswer called from SetLDFn
2022.01.28 12:46:21.697 5: alfen_Socket_aussen: ReadAnswer remaining timeout is 1.89792394638062
2022.01.28 12:46:21.818 5: alfen_Socket_aussen: ReadAnswer got: 00c70000000701030400000000
2022.01.28 12:46:21.818 5: alfen_Socket_aussen: ParseFrameStart called from ReadAnswer protocol TCP expecting id 1
2022.01.28 12:46:21.818 4: alfen_Socket_aussen: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 199, dlen 7 and potential data 0400000000
2022.01.28 12:46:21.818 5: alfen_Socket_aussen: HandleResponse called from ReadAnswer
2022.01.28 12:46:21.818 5: alfen_Socket_aussen: ParseResponse called from HandleResponse
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: now parsing response data objects, master is alfen_Socket_aussen relay is undefined
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: ParseDataString called from HandleResponse with data hex 00000000, type h, adr 1210, op read
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: SplitDataString called from ParseDataString with data hex 00000000, type h, adr 1210, valuesLen 2, op read
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: CreateDataObjects called from ParseDataString with objList h1210
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: CreateDataObjects sortedList h1210
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: CreateDataObjects unpacked 00000000 with f> to 0
2022.01.28 12:46:21.820 4: alfen_Socket_aussen: CreateDataObjects assigns value 0 to Charge_Current
2022.01.28 12:46:21.822 5: alfen_Socket_aussen: ParseDataString created 1 readings






edit: Verbose level set to 5
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: tomix am 28 Januar 2022, 23:10:00
Keine Ahnung ob hier am richtigen Ort.

Ich habe einen DS3484, siehe auch:
https://forum.fhem.de/index.php?topic=109904.0

Aktuell nutze ich nur die 4 fest verbauten Relais, welche via FHEM geschaltet werden.
Funktioniert aber das Ding müllt mir das Logfile.voll, da die Vertbindung immer wieder umterbrochem wird (in der Praxis bemerke ich nichts davon):

2022.01.28 22:43:00 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:43:00 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:46:16 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:46:16 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:49:32 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:49:32 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:52:48 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:52:48 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:56:05 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:56:05 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:59:21 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:59:21 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 23:02:37 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 23:02:37 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 23:05:53 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 23:05:53 3: 192.168.178.15:502 reappeared (ds3484)


RAW-Listing

defmod ds3484 ModbusAttr 1 60 192.168.178.15:502 TCP
attr ds3484 icon lan_rs485
attr ds3484 obj-c0-hint 0,1
attr ds3484 obj-c0-reading LichtTreppe
attr ds3484 obj-c0-set 1
attr ds3484 obj-c1-hint 0,1
attr ds3484 obj-c1-reading LichtGarten
attr ds3484 obj-c1-set 1
attr ds3484 obj-c10-hint 0,1
attr ds3484 obj-c10-reading Relais11
attr ds3484 obj-c10-set 1
attr ds3484 obj-c11-hint 0,1
attr ds3484 obj-c11-reading Relais12
attr ds3484 obj-c11-set 1
attr ds3484 obj-c12-hint 0,1
attr ds3484 obj-c12-reading Relais13
attr ds3484 obj-c12-set 1
attr ds3484 obj-c13-hint 0,1
attr ds3484 obj-c13-reading Relais14
attr ds3484 obj-c13-set 1
attr ds3484 obj-c14-hint 0,1
attr ds3484 obj-c14-reading Relais15
attr ds3484 obj-c14-set 1
attr ds3484 obj-c15-hint 0,1
attr ds3484 obj-c15-reading Relais16
attr ds3484 obj-c15-set 1
attr ds3484 obj-c16-hint 0,1
attr ds3484 obj-c16-reading Relais17
attr ds3484 obj-c16-set 1
attr ds3484 obj-c17-hint 0,1
attr ds3484 obj-c17-reading Relais18
attr ds3484 obj-c17-set 1
attr ds3484 obj-c18-hint 0,1
attr ds3484 obj-c18-reading Relais19
attr ds3484 obj-c18-set 1
attr ds3484 obj-c19-hint 0,1
attr ds3484 obj-c19-reading Relais20
attr ds3484 obj-c19-set 1
attr ds3484 obj-c2-hint 0,1
attr ds3484 obj-c2-reading InvDoseEingang
attr ds3484 obj-c2-set 1
attr ds3484 obj-c20-hint 0,1
attr ds3484 obj-c20-reading Relais21
attr ds3484 obj-c20-set 1
attr ds3484 obj-c21-hint 0,1
attr ds3484 obj-c21-reading Relais22
attr ds3484 obj-c21-set 1
attr ds3484 obj-c22-hint 0,1
attr ds3484 obj-c22-reading Relais23
attr ds3484 obj-c22-set 1
attr ds3484 obj-c23-hint 0,1
attr ds3484 obj-c23-reading Relais24
attr ds3484 obj-c23-set 1
attr ds3484 obj-c24-hint 0,1
attr ds3484 obj-c24-reading Relais25
attr ds3484 obj-c24-set 1
attr ds3484 obj-c25-hint 0,1
attr ds3484 obj-c25-reading Relais26
attr ds3484 obj-c25-set 1
attr ds3484 obj-c26-hint 0,1
attr ds3484 obj-c26-reading Relais27
attr ds3484 obj-c26-set 1
attr ds3484 obj-c27-hint 0,1
attr ds3484 obj-c27-reading Relais28
attr ds3484 obj-c27-set 1
attr ds3484 obj-c28-hint 0,1
attr ds3484 obj-c28-reading Relais29
attr ds3484 obj-c28-set 1
attr ds3484 obj-c29-hint 0,1
attr ds3484 obj-c29-reading Relais30
attr ds3484 obj-c29-set 1
attr ds3484 obj-c3-hint 0,1
attr ds3484 obj-c3-reading InvSitzplatz
attr ds3484 obj-c3-set 1
attr ds3484 obj-c30-hint 0,1
attr ds3484 obj-c30-reading Relais31
attr ds3484 obj-c30-set 1
attr ds3484 obj-c31-hint 0,1
attr ds3484 obj-c31-reading Relais32
attr ds3484 obj-c31-set 1
attr ds3484 obj-c4-hint 0,1
attr ds3484 obj-c4-reading Relais5
attr ds3484 obj-c4-set 1
attr ds3484 obj-c5-hint 0,1
attr ds3484 obj-c5-reading Relais6
attr ds3484 obj-c5-set 1
attr ds3484 obj-c6-hint 0,1
attr ds3484 obj-c6-reading Relais7
attr ds3484 obj-c6-set 1
attr ds3484 obj-c7-hint 0,1
attr ds3484 obj-c7-reading Relais8
attr ds3484 obj-c7-set 1
attr ds3484 obj-c8-hint 0,1
attr ds3484 obj-c8-reading Relais9
attr ds3484 obj-c8-set 1
attr ds3484 obj-c9-hint 0,1
attr ds3484 obj-c9-reading Relais10
attr ds3484 obj-c9-set 1
attr ds3484 obj-d0-reading 1
attr ds3484 obj-d1-reading 1
attr ds3484 obj-d11-reading 1
attr ds3484 obj-d2-reading 1
attr ds3484 obj-d27-reading 1
attr ds3484 obj-d3-reading 1
attr ds3484 obj-d31-reading 1
attr ds3484 obj-d7-reading 1

setstate ds3484 opened
setstate ds3484 2022-01-28 22:00:00 InvDoseEingang 1
setstate ds3484 2022-01-28 22:26:39 InvSitzplatz 1
setstate ds3484 2021-12-05 18:24:34 LichtGarten 0
setstate ds3484 2022-01-28 17:15:24 LichtTreppe 1
setstate ds3484 2022-01-28 22:43:00 state opened
:

Irgendwelche Ideen was das Problem sein könnte?

Gruss
tomix
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 29 Januar 2022, 09:00:01
Zitat von: tomix am 28 Januar 2022, 23:10:00
Keine Ahnung ob hier am richtigen Ort.

Ich habe einen DS3484, siehe auch:
https://forum.fhem.de/index.php?topic=109904.0

Aktuell nutze ich nur die 4 fest verbauten Relais, welche via FHEM geschaltet werden.
Funktioniert aber das Ding müllt mir das Logfile.voll, da die Vertbindung immer wieder umterbrochem wird (in der Praxis bemerke ich nichts davon):

Hast du versucht, Verbose hochzusetzen auf 5? Ich würde die Definition auf "defmod ds3484 ModbusAttr 1 1 192.168.178.15:502 TCP" ändern und dann via "at" oder telnet und einem Script o.ä. die Relais im Sekundentakt ändern. Das ist das ein rechter Stresstest und du siehst wohl relativ schnell, wann es zu einem Disconnect kommt und was vorher das Problem war. So habe ich bei meinen Stromzählern (ABB B23) herausgefunden, dass sie ca. 200ms für eine Antwort benötigen und während dieser Zeit keine weiteren Modbusabfragen stattfinden dürfen, sonst gehen Antworten verloren.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: tomix am 29 Januar 2022, 12:48:40
Zitat von: ansgru am 29 Januar 2022, 09:00:01
Hast du versucht, Verbose hochzusetzen auf 5? Ich würde die Definition auf "defmod ds3484 ModbusAttr 1 1 192.168.178.15:502 TCP" ändern und dann via "at" oder telnet und einem Script o.ä. die Relais im Sekundentakt ändern. Das ist das ein rechter Stresstest und du siehst wohl relativ schnell, wann es zu einem Disconnect kommt und was vorher das Problem war. So habe ich bei meinen Stromzählern (ABB B23) herausgefunden, dass sie ca. 200ms für eine Antwort benötigen und während dieser Zeit keine weiteren Modbusabfragen stattfinden dürfen, sonst gehen Antworten verloren.
Ich schalte drei der Relais nur vier mal am Tag. Die Einträge treten aber dauern auf (jeweils unter 5 Minuten bis zum nächsten disconnected).

Gibt es eine Möglichkeit ein Device mal auf inaktiv zu stellen oder geht nur löschen und neu anzulegen (aktuell hängt FHEM regelmässig, was vorher nicht der Fall war, dies kann aber eigentlich nicht mit dem zusammenhängen, da dieses Problem schon länger besteht).

Gruss
tomix
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 29 Januar 2022, 13:26:07
Zitat von: tomix am 29 Januar 2022, 12:48:40
Ich schalte drei der Relais nur vier mal am Tag. Die Einträge treten aber dauern auf (jeweils unter 5 Minuten bis zum nächsten disconnected).

Hast du mal

silentReconnect
if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3


ausprobiert?
Zitat von: tomix am 29 Januar 2022, 12:48:40
Gibt es eine Möglichkeit ein Device mal auf inaktiv zu stellen oder geht nur löschen und neu anzulegen (aktuell hängt FHEM regelmässig, was vorher nicht der Fall war, dies kann aber eigentlich nicht mit dem zusammenhängen, da dieses Problem schon länger besteht).

disable?

disable
stop communication with the device while this attribute is set to 1. For Modbus over TCP this also closes the TCP connection.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: tomix am 29 Januar 2022, 22:10:56
Zitat von: ansgru am 29 Januar 2022, 13:26:07
Hast du mal

silentReconnect
if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3


ausprobiert?
disable?

disable
stop communication with the device while this attribute is set to 1. For Modbus over TCP this also closes the TCP connection.

Nein, habe ich nicht. Ich ging davon aus, dass sich die Verbindung nicht verabschieden sollte. Nach dem hier, passiert dies aber offenbar öfters:
https://forum.fhem.de/index.php?topic=97441.195

Nun mal folgendes gesetzt:

attr ds3484 silentReconnect 1


Werde mal gucken ob sich was ändert.

Gruss
tomix
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 Februar 2022, 16:11:28
Hallo tomix,

bei Modbus-TCP-Slaves ist es durchaus üblich, dass die TCP-Verbindung nach einer Weile geschlossen wird.
silentReconnect ist dann der richtige Weg.

Du kannst auch mit dem Attribut closeAfterResponse einstellen, dass die TCP-Verbindung nur bei Bedarf aufgebaut und nach der Antwort auch wieder geschlossen wird.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 Februar 2022, 20:31:41
Zitat von: ansgru am 26 Januar 2022, 21:16:09
Das geht leider nicht weil einzelne Relais ein FF 00 erwarten als Befehl zum einschalten (resp. 55 00 für ein Toggle), das Schalten aller Relais aber ein FF FF. Mit dev-c-brokenFC5 kann ich ja nur global den zu senden Wert zum Aktivieren eines Coils festlegen wenn ich das richtig verstanden habe?
ja, dev-c-brokenFC5 wirkt global.

Zitat
Hmmm, ich habe noch einen völlig anderen Ansatz: wie wäre es, wenn ich pro Register mit einem zusätzlichen Flag angeben kann, welcher Function Code verwendet werden soll? Also ein obj-[ih][1-9][0-9]*-overrideFC? Die Funktionsweise wäre dann wie folgt: ich würde für das Schalten der Relais "Holding Register Objekte" definieren (also obj-h255-reading statt obj-c255-reading) und zusätzlich ein obj-h255-overrideFC 5. Also ähnlich wie dev-([cdih]-)*write|read ABER pro Register UND intern würde Modbus.pm in diesem Beispiel h255 intern als Holding Register behandeln und nur in der Kommunikation den gewählten FC verwenden. Bei dev*write|read ist es ja so, dass - wenn ich z.B. dev-h-write 5 definiere - alle Holding Registers fortan als Coils betrachtet werden und ich damit wieder keine individuellen Werte wie FF FF, FF 00 individuell pro Register definieren kann.

Ja, das wäre keine größere Änderung. Bei FC5 und FC6 würde es sogar funktionieren. Bei anderen Codes aber nicht, da die Nachrichten nicht immer gleich aufgebaut sind. ich sollte dann zumindest in der Doku dazuschreiben, dass man dieses Attribut nur verwenden sollte, wenn man die Modbus-Spec gelesen und verstanden hat, was man damit tut ;-)

Ich versuche das demnächst mal einzubauen und poste dann eine Version zum Testen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 Februar 2022, 20:40:09
Hallo Stephan,

kannst Du Deine Konfiguration noch posten?

Wer triggert eigentlich den set Charge_Current?

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 Februar 2022, 15:48:00
Hallo,

anbei eine neue Version zum Testen.
es gibt neue Attribute obj-XX-overrideFCread und obj-XX-overrideFCwrite um die function codes für das Lesen und Schreiben eines einzelnen Objekts zu überschreiben.
Zudem habe ich das Handling von Timeouts so geändert, dass schon vor dem Parsen eines Replies der Timeout-zurückgesetzt wird. Eventuell hilft das bei dem von Stephan beschriebenen Problem.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RaKoHe am 10 Februar 2022, 10:10:01
Moin Stefan,

danke für die neue Version.

Wenn ich nur die beiden Module update(der Rest ist ziemlich alt) funktioniert es, hatte allerdings im Browser mehrere Lost Connection Meldungen.

Nach einem update all(exclude Modbus und ModbusAttr) bekomme ich Fehler beim Start.


2022.02.10 09:57:02 1: PERL WARNING: Subroutine TryCall redefined at ./FHEM/98_Modbus.pm line 4997, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ObjKey redefined at ./FHEM/98_Modbus.pm line 4974, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DevInfo redefined at ./FHEM/98_Modbus.pm line 4948, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ObjInfo redefined at ./FHEM/98_Modbus.pm line 4867, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ObjAttr redefined at ./FHEM/98_Modbus.pm line 4840, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine LRC redefined at ./FHEM/98_Modbus.pm line 4824, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CRC redefined at ./FHEM/98_Modbus.pm line 4804, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine compObjTA redefined at ./FHEM/98_Modbus.pm line 4790, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine compObjGroups redefined at ./FHEM/98_Modbus.pm line 4766, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine compObjCombi redefined at ./FHEM/98_Modbus.pm line 4750, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ResetExpect redefined at ./FHEM/98_Modbus.pm line 4736, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DropBuffer redefined at ./FHEM/98_Modbus.pm line 4720, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ShowBuffer redefined at ./FHEM/98_Modbus.pm line 4700, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DevLockingKey redefined at ./FHEM/98_Modbus.pm line 4683, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine GetLogHash redefined at ./FHEM/98_Modbus.pm line 4641, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine UnregAtIODev redefined at ./FHEM/98_Modbus.pm line 4580, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine RegisterAtIODev redefined at ./FHEM/98_Modbus.pm line 4552, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine IsRegisteredAtIODev redefined at ./FHEM/98_Modbus.pm line 4534, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CheckIOCompat redefined at ./FHEM/98_Modbus.pm line 4492, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine GetIOHash redefined at ./FHEM/98_Modbus.pm line 4471, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SetIODev redefined at ./FHEM/98_Modbus.pm line 4423, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CheckDisable redefined at ./FHEM/98_Modbus.pm line 4389, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine GetSetChecks redefined at ./FHEM/98_Modbus.pm line 4354, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ResponseTimeout redefined at ./FHEM/98_Modbus.pm line 4275, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ServerTimeout redefined at ./FHEM/98_Modbus.pm line 4250, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SetStates redefined at ./FHEM/98_Modbus.pm line 4220, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CountTimeouts redefined at ./FHEM/98_Modbus.pm line 4175, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CheckChecksum redefined at ./FHEM/98_Modbus.pm line 4105, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine AddFrameError redefined at ./FHEM/98_Modbus.pm line 4092, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DropFrame redefined at ./FHEM/98_Modbus.pm line 4057, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine LogFrame redefined at ./FHEM/98_Modbus.pm line 4045, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine FrameText redefined at ./FHEM/98_Modbus.pm line 4028, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ResponseText redefined at ./FHEM/98_Modbus.pm line 4014, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine RequestText redefined at ./FHEM/98_Modbus.pm line 3991, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine GetUpdate redefined at ./FHEM/98_Modbus.pm line 3948, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CombineUpdateHash redefined at ./FHEM/98_Modbus.pm line 3874, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CreateUpdateHash redefined at ./FHEM/98_Modbus.pm line 3773, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SendFrame redefined at ./FHEM/98_Modbus.pm line 3720, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine PackFrame redefined at ./FHEM/98_Modbus.pm line 3681, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine PackResponse redefined at ./FHEM/98_Modbus.pm line 3634, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine PackRequest redefined at ./FHEM/98_Modbus.pm line 3585, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine PackObj redefined at ./FHEM/98_Modbus.pm line 3477, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ProcessRequestQueue redefined at ./FHEM/98_Modbus.pm line 3388, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CheckDelays redefined at ./FHEM/98_Modbus.pm line 3304, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine NextRequestFromQueue redefined at ./FHEM/98_Modbus.pm line 3277, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine QueueRequest redefined at ./FHEM/98_Modbus.pm line 3215, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DoRequest redefined at ./FHEM/98_Modbus.pm line 3179, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine GetFC redefined at ./FHEM/98_Modbus.pm line 3132, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CreateResponse redefined at ./FHEM/98_Modbus.pm line 3084, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine RelayResponse redefined at ./FHEM/98_Modbus.pm line 3042, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine RelayRequest redefined at ./FHEM/98_Modbus.pm line 2978, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine GetRelayIO redefined at ./FHEM/98_Modbus.pm line 2924, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ParseRequest redefined at ./FHEM/98_Modbus.pm line 2822, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine HandleRequest redefined at ./FHEM/98_Modbus.pm line 2746, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ParseDataString redefined at ./FHEM/98_Modbus.pm line 2706, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CreateDataObjects redefined at ./FHEM/98_Modbus.pm line 2629, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine CreateParseInfoCache redefined at ./FHEM/98_Modbus.pm line 2604, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SplitDataString redefined at ./FHEM/98_Modbus.pm line 2527, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine WriteObject redefined at ./FHEM/98_Modbus.pm line 2477, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine arrayEncoding redefined at ./FHEM/98_Modbus.pm line 2458, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ScanFormat redefined at ./FHEM/98_Modbus.pm line 2416, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ScanReadingName redefined at ./FHEM/98_Modbus.pm line 2386, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ParseResponse redefined at ./FHEM/98_Modbus.pm line 2268, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine HandleResponse redefined at ./FHEM/98_Modbus.pm line 2165, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ParseFrameStart redefined at ./FHEM/98_Modbus.pm line 2107, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SkipGarbageCheck redefined at ./FHEM/98_Modbus.pm line 2058, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ReadAnswer redefined at ./FHEM/98_Modbus.pm line 1948, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ReadFn redefined at ./FHEM/98_Modbus.pm line 1844, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine HandleGaps redefined at ./FHEM/98_Modbus.pm line 1812, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine HandleServerConnection redefined at ./FHEM/98_Modbus.pm line 1774, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ReadyFn redefined at ./FHEM/98_Modbus.pm line 1746, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DoClose redefined at ./FHEM/98_Modbus.pm line 1685, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine OpenCB redefined at ./FHEM/98_Modbus.pm line 1666, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DoOpen redefined at ./FHEM/98_Modbus.pm line 1577, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine NotifyFn redefined at ./FHEM/98_Modbus.pm line 1530, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ScanIds redefined at ./FHEM/98_Modbus.pm line 1463, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ScanObjects redefined at ./FHEM/98_Modbus.pm line 1417, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SaveAsModule redefined at ./FHEM/98_Modbus.pm line 1345, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine createAttrsFromParseInfo redefined at ./FHEM/98_Modbus.pm line 1298, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine ControlSet redefined at ./FHEM/98_Modbus.pm line 1143, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SetLDFn redefined at ./FHEM/98_Modbus.pm line 1079, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine FormatSetVal redefined at ./FHEM/98_Modbus.pm line 1028, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine GetLDFn redefined at ./FHEM/98_Modbus.pm line 992, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine UpdateGetSetList redefined at ./FHEM/98_Modbus.pm line 939, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SetLDActive redefined at ./FHEM/98_Modbus.pm line 916, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine SetLDInactive redefined at ./FHEM/98_Modbus.pm line 897, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine AttrLDFn redefined at ./FHEM/98_Modbus.pm line 761, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine AttrFn redefined at ./FHEM/98_Modbus.pm line 735, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine UndefLDFn redefined at ./FHEM/98_Modbus.pm line 715, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine UndefFn redefined at ./FHEM/98_Modbus.pm line 691, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DefineLDFn redefined at ./FHEM/98_Modbus.pm line 570, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine DefineFn redefined at ./FHEM/98_Modbus.pm line 538, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine InitializeLD redefined at ./FHEM/98_Modbus.pm line 510, <$fh> line 1399.
2022.02.10 09:57:02 1: PERL WARNING: Subroutine Initialize redefined at ./FHEM/98_Modbus.pm line 488, <$fh> line 1399.


Mit sonnigen Grüßen

Ralf
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 10 Februar 2022, 22:21:01
Hallo Ralf,

starte doch einfach Dein Fhem mal neu.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RaKoHe am 11 Februar 2022, 10:04:40
Moin Stefan,

leider auch nach Shutdown restart und reboot noch vorhanden.
Jetzt wird line 1400 ausgegeben.
Auch nach 3x Neustart noch.

Nach Update inklusive Modbus und ModbusAttr funktioniert die Abfrage der Doepke Register nicht mehr weil scheinbar dev-d-brokenFC2
fehlt.

Mit sonnigen Grüßen

Ralf
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Februar 2022, 18:17:18
Hallo Ralf,

das ist seltsam. An dem Code für dev-d-brokenFC2 hat sich nichts geändert und die Warnings kann ich bei mir nicht nachvollziehen.
Um das zu klären bräuchte ich einen deutlich größeren Ausschnitt aus dem Log bei verbose 5. Am besten auch die Konfiguration Deiner Geräte, die etwas mit Modbus zu tun haben.
Der Fix für Doepke erzeugt ja auch einen Eintrag im Log wenn er ausgeführt wird.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RaKoHe am 13 Februar 2022, 10:33:37
Moin Stefan,

Danke für die Antwort.
Die Warnings werden scheinbar durch einen Fehler in der myUtils verursacht.
Ich suche den Fehler selber:-)

Die Versionen der Modbus Module vom 09.02. funktionieren bei mir.

Mit sonnigen Grüßen

Ralf
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 19 Februar 2022, 20:06:34
Hallo Stefan,

sorry für die späte Antwort, es ging einige Zeit bis ich die neue Version endlich testen konnte. Absolut phantastisch, jetzt klappt alles wie gewünscht :-) Hier als Referenz meine (absolut reduzierte) Config falls jemand zufällig auch das "Waveshare Modbus RTU Relay" verwenden möchte:


defmod Waveshare_Relay ModbusAttr 1 10
attr Waveshare_Relay obj-c0-reading Relay0
attr Waveshare_Relay obj-c0-set 1
attr Waveshare_Relay obj-c1-reading Relay1
attr Waveshare_Relay obj-c1-set 1

(weitere Relais analog....)

attr Waveshare_Relay obj-h255-overrideFCwrite 5
attr Waveshare_Relay obj-h255-reading Alle_Relais
attr Waveshare_Relay obj-h255-set 1


Mit set Waveshare_Relay Alle_Relais 65535 lassen sich alle Relais an- und mit set Waveshare_Relay Alle_Relais 0 alle Relais abschalten. Die einzelnen Relais lassen sich mit set Waveshare_Relay Relais[0-7] 1|0 schalten. Mehr brauche ich nicht. Vielen herzlichen Dank für die rasche Umsetzung!

Schade, dass sich das Waveshare Relay nicht an den Standard hält. Die Hardware ist nämlich super verarbeitet, auch vom Modbus/RS485 USB Adapter (dem hochwertigen im Metallgehäuse https://www.waveshare.com/product/iot-communication/wired-comm-converter/rs232-rs485-can/usb-to-rs232-485-ttl.htm (https://www.waveshare.com/product/iot-communication/wired-comm-converter/rs232-rs485-can/usb-to-rs232-485-ttl.htm)) bin ich sehr angetan, der funktioniert hervorragend und scheint auch sehr robust zu sein.

Beste Grüsse, Anton
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: abc2006 am 01 März 2022, 12:14:50
Hi Stefan,

danke für deine schnelle Reaktion und die neuen Dateien.

Ich hab die bei mir eingespielt, der Fehler tritt trotzdem auf.

meine Konfiguration (ich nehme an du meinst ein list):


Internals:
   DEF        1 5 192.168.0.49:502 TCP
   DeviceName 192.168.0.49:502
   EXPECT     response
   FD         28
   FUUID      62057813-f33f-4040-fc6d-0c6e8e9966865e61
   IODev      alfen_Socket_aussen
   Interval   5
   LASTOPEN   1646131815.17942
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       alfen_Socket_aussen
   NOTIFYDEV  global
   NR         597
   NTFY_ORDER 50-alfen_Socket_aussen
   PARTIAL   
   PROTOCOL   TCP
   STATE      charging in progress Ladestrom: 16 A Ladeleistung: 10317 W NoP: 3
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   nextOpenDelay 60
   nextQueueRun 1646132330.1194
   nextTimeout 1646132331.1171
   FRAME:
   QUEUE:
     HASH(0x559927b2f7b0)
     HASH(0x559927b11b90)
     HASH(0x5599280cfd00)
     HASH(0x5599281478d8)
     HASH(0x559927c431c0)
     HASH(0x559927b01cb8)
     HASH(0x559927ce3668)
     HASH(0x559927ee26a8)
     HASH(0x559927bc72c8)
   READ:
     BUFFER     
   READINGS:
     2022-03-01 11:58:45   ActualAppliedMaxCurrent 16
     2022-03-01 11:58:45   Availability    1
     2022-03-01 11:58:46   Charge_Current  16
     2022-03-01 11:58:46   Charge_with_1_or_3_phases 3
     2022-03-01 11:58:48   CurrentPhaseL1  15
     2022-03-01 11:58:48   CurrentPhaseL2  15.1
     2022-03-01 11:58:48   CurrentPhaseL3  15.2
     2022-03-01 11:58:49   Fzg_angeschlossen Fahrzeug angeschlossen
     2022-03-01 11:58:49   Laden_moeglich  Laden moeglich
     2022-03-01 11:58:45   MaxCurrentValidTimeRemaining 276
     2022-03-01 11:58:45   Mode3State      C2
     2022-03-01 11:58:49   Mode3State_     charging in progress
     2022-03-01 11:58:44   RealEnergyDeliveredSum 1158.737 Wh
     2022-03-01 11:58:44   RealEnergyDeliveredSumL1 NaN
     2022-03-01 11:58:44   RealEnergyDeliveredSumL2 NaN
     2022-03-01 11:58:44   RealEnergyDeliveredSumL3 NaN
     2022-03-01 11:58:49   RealPowerSum    10317
     2022-03-01 11:58:47   VoltPhase1      226.2
     2022-03-01 11:58:47   VoltPhase2      227.9
     2022-03-01 11:58:48   VoltPhase3      227.1
     2022-03-01 11:58:49   actual_charge_power 10286.21
     2022-03-01 11:50:15   state           opened
   REMEMBER:
     lid        1
     lname      alfen_Socket_aussen
     lrecv      1646132329.01702
     lsend      1646132329.11925
   REQUEST:
     ADR        362
     DBGINFO    getUpdate for RealEnergyDeliveredSumL1 len 4
     FCODE      3
     FRAME      �j
     LEN        4
     MODBUSID   1
     OPERATION  read
     QUEUED     1646132327.34868
     READING    RealEnergyDeliveredSumL1
     SENT       1646132329.1171
     TID        246
     TYPE       h
     MASTERHASH:
   defptr:
     alfen_Socket_aussen 1
   gotReadings:
     RealPowerSum 10317
   lastRead:
     h1200      1646132325.14273
     h1201      1646132325.36805
     h1206      1646132325.59799
     h1208      1646132325.81839
     h1210      1646132326.04309
     h1215      1646132326.26842
     h306       1646132327.56858
     h308       1646132327.81812
     h310       1646132328.06868
     h320       1646132328.31812
     h322       1646132328.56796
     h324       1646132328.79219
     h344       1646132329.01839
     h362       1646132324.24258
     h366       1646132324.46937
     h370       1646132324.69332
     h374       1646132324.91881
Attributes:
   dev-h-defPoll 1
   dev-type-FLOAT16-len 2
   dev-type-FLOAT16-unpack f>
   dev-type-FLOAT32-len 4
   dev-type-FLOAT32-unpack f>
   dev-type-FLOAT64-len 4
   dev-type-FLOAT64-unpack d>
   dev-type-SIGNED16-len 1
   dev-type-SIGNED16-unpack n!
   dev-type-STRING17-len 17
   dev-type-STRING17-unpack Z*
   dev-type-STRING5-len 5
   dev-type-STRING5-unpack Z*
   dev-type-UNSIGNED16-len 1
   dev-type-UNSIGNED16-unpack S>
   dev-type-UNSIGNED32-len 2
   dev-type-UNSIGNED32-unpack L>
   dev-type-UNSIGNED64-len 4
   dev-type-UNSIGNED64-unpack Q>
   event-on-change-reading RealEnergyDeliveredSum:0.1,RealPowerSum:10,ActualAppliedMaxCurrent
   event-on-update-reading MaxCurrentValidTimeRemaining,Mode3State
   obj-h1200-reading Availability
   obj-h1200-type UNSIGNED16
   obj-h1201-reading Mode3State
   obj-h1201-type STRING5
   obj-h1206-reading ActualAppliedMaxCurrent
   obj-h1206-type FLOAT32
   obj-h1208-reading MaxCurrentValidTimeRemaining
   obj-h1208-type UNSIGNED32
   obj-h1210-allowWrite 1
   obj-h1210-hint 0,6,7,8,9,10,11,12,13,14,15,16
   obj-h1210-reading Charge_Current
   obj-h1210-set 1
   obj-h1210-type FLOAT16
   obj-h1215-allowWrite 1
   obj-h1215-hint 1,3
   obj-h1215-reading Charge_with_1_or_3_phases
   obj-h1215-set 1
   obj-h1215-type UNSIGNED16
   obj-h256-expr int($val)/10
   obj-h306-expr int(10*$val)/10
   obj-h306-reading VoltPhase1
   obj-h306-type FLOAT32
   obj-h308-expr int(10*$val)/10
   obj-h308-reading VoltPhase2
   obj-h308-type FLOAT32
   obj-h310-expr int(10*$val)/10
   obj-h310-reading VoltPhase3
   obj-h310-type FLOAT32
   obj-h320-expr int(10*$val)/10
   obj-h320-reading CurrentPhaseL1
   obj-h320-type FLOAT32
   obj-h322-expr int(10*$val)/10
   obj-h322-reading CurrentPhaseL2
   obj-h322-type FLOAT32
   obj-h324-expr int(10*$val)/10
   obj-h324-reading CurrentPhaseL3
   obj-h324-type FLOAT32
   obj-h344-expr int($val)
   obj-h344-reading RealPowerSum
   obj-h344-type FLOAT32
   obj-h362-reading RealEnergyDeliveredSumL1
   obj-h362-type FLOAT64
   obj-h366-reading RealEnergyDeliveredSumL2
   obj-h366-type FLOAT64
   obj-h370-reading RealEnergyDeliveredSumL3
   obj-h370-type FLOAT64
   obj-h374-expr $val/1000
   obj-h374-format %.3f Wh
   obj-h374-reading RealEnergyDeliveredSum
   obj-h374-type FLOAT64
   room       tesla
   stateFormat Mode3State_ Ladestrom: ActualAppliedMaxCurrent A Ladeleistung: RealPowerSum W NoP: Charge_with_1_or_3_phases
   userReadings Mode3State_ {my $M3state = ReadingsVal($name,"Mode3State",-1);
if($M3state =~ /A/ ){
return "EVSE ready and standby";
} elsif($M3state =~ /B1/ ){
return "EV connected to EVSE";
} elsif($M3state =~ /B2/ ){
return "charging approved by EVSE";
} elsif($M3state =~ /C1/ ){
return "charging approved by EV, but not by EVSE";
} elsif($M3state =~ /C2/ ){
return "charging in progress";
} elsif($M3state =~ /D1/ ){
return "ventilated charging approved by EV, but not by EVSE";
} elsif($M3state =~ /D2/ ){
return "ventilated charging in progress";
} elsif($M3state =~ /E/ ){
return "Error inside Vehicle";
} elsif($M3state =~ /F/ ){
return "Error inside Wallbox";
}
},
Fzg_angeschlossen {my $M3state = ReadingsVal($name,"Mode3State",-1);
if($M3state =~ /A/ ){
return "Kein Fahrzeug angeschlossen";
} else{
return "Fahrzeug angeschlossen";
}
},
Laden_moeglich {my $M3state = ReadingsVal($name,"Mode3State",-1);
if($M3state =~ /[CD]/ ){
return "Laden moeglich";
} else{
return "Laden nicht moeglich";
}
},
energy_last_charge {
if(ReadingsVal($name,"Mode3State",-1) )
{}
},
actual_charge_power {
my $powerL1 = ReadingsVal($name,"CurrentPhaseL1",-1) * ReadingsVal($name,"VoltPhase1",-1);
my $powerL2 = ReadingsVal($name,"CurrentPhaseL2",-1) * ReadingsVal($name,"VoltPhase2",-1);
my $powerL3 = ReadingsVal($name,"CurrentPhaseL3",-1) * ReadingsVal($name,"VoltPhase3",-1);
my $power_total = $powerL1 + $powerL2 + $powerL3;

}
   verbose    3

Pre: Da ich jetzt mehrfach die Begriffe geändert hab, hier ein kurzes Wording: Aussen an meinem Parkplatz hängt eine Wallbox an der Wand. Diese wird durch ModbusAttr gesteuert. Ich nenn die jetzt einfach Wallbox, dann ist klar dass ich nichts in FHEM meine.

Das set Charge_Current wird von einem DOIF
https://github.com/abc2006/alfen/blob/main/DF_ueberschussladung_raw.pl (https://github.com/abc2006/alfen/blob/main/DF_ueberschussladung_raw.pl) 
gesetzt, welches aus diversen Faktoren den zulässigen Ladestrom berechnet.
Dabei ist mir aufgefallen, dass das ModbusAttr tatsächlich mehrfach mit den set's beschossen wurde - das habe ich in den letzten Tagen reduziert.
Versucht habe ich, es komplett zu beheben, ich bin aber nicht sicher, dass das geklappt hat.

[ kurz ein bisschen OT: ]
U.a. deswegen hätte ich eine Bitte:

Auf verbose 2 (laut Attr-Hilfe "2 - major events/alarms") würde ich erwarten, dass er loggt, wenn ein set-Befehl eingeht
Auf verbose 3 (laut Attr-Hilfe "3 - commands sent out will be logged") würde ich erwarten, dass er loggt, wenn er eine Abfrage (egal ob set oder get) an die Wallbox schickt

Leider bekomme ich auf Lvl 2 gar nichts, auf 3 nur die Timeouts und erst auf Lvl 4 dann mehr Infos - das sind dann aber bereits zuviele, um zb herauszufinden, wie oft tatsächlich ein set-Befehl bei ModbusAttr ankommt oder gar an die Wallbox gesendet wird.

Kannst du mir noch folgen? Evtl könnte man hier die verschiedenen level noch etwas anpassen oder ich habe das System dahinter noch nicht durchschaut.
[BTT]

Die Wallbox hat einen Timer (Reading MaxCurrentValidTimeRemaining). Dieser läuft von 300 Sekunden (konfigurierbar) abwärts auf 0. Mit jedem set Charge_Current, was bei der Wallbox ankommt, wird der Timer wieder auf 300 zurückgesetzt. Wenn der Timer bei 0 ankommt, schaltet die Wallbox in einen safe-Mode (konfigurierbar), weil sie annimmt, dass die Verbindung unterbrochen ist.  Durch den Timer kann ich relativ genau feststellen, wann ein set charge_current bei der Wallbox angekommen ist - allerdings nicht, ob es zwischendurch von ModbusAttr verschluckt wurde (durch den Timeout).

Jetzt wieder zu deiner Frage:
Nachdem ich jetzt die set Charge_Current stark reduziert habe, treten trotzdem  noch Timeouts (und freezes) auf. Hier nochmal ein Auszug aus dem Log:



2022.03.01 12:06:29.592 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 291
2022.03.01 12:06:29.596 5: set_charge_current() available_charge_current 12
2022.03.01 12:06:29.596 5: set_charge_current() ret_ueberschuss 0
2022.03.01 12:06:34.590 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 286
2022.03.01 12:06:34.597 5: set_charge_current() available_charge_current 13
2022.03.01 12:06:34.600 5: set_charge_current() ret_ueberschuss 0
2022.03.01 12:06:39.615 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 281
2022.03.01 12:06:39.620 5: set_charge_current() available_charge_current 15
2022.03.01 12:06:41.625 3: alfen_Socket_aussen: Timeout in Readanswer, current frame / read buffer: 00e50000000701030400000119, id 1, fCode 3, tid 229,
request: id 1, read fc 3 h1208, len 2, tid 229, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemaining len 2), queued 5.49 secs ago, sent 2.14 secs ago,
response: id 1, fc 3, h1208, len 2, values 00000119
2022.03.01 12:06:41.965 3: set_charge_current() set alfen_Socket_aussen Charge_Current 15
2022.03.01 12:06:41.965 5: set_charge_current() ret_ueberschuss 0
2022.03.01 12:06:41.971 1: Perfmon: possible freeze starting at 12:06:40, delay is 1.971
2022.03.01 12:06:45.966 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 295
2022.03.01 12:06:45.976 5: set_charge_current() available_charge_current 18
2022.03.01 12:06:45.978 5: set_charge_current() ret_ueberschuss 0
2022.03.01 12:06:50.467 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 291
2022.03.01 12:06:50.476 5: set_charge_current() available_charge_current 20
2022.03.01 12:06:50.478 5: set_charge_current() ret_ueberschuss 0
2022.03.01 12:06:55.489 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 286
2022.03.01 12:06:55.497 5: set_charge_current() available_charge_current 20
2022.03.01 12:06:55.497 5: set_charge_current() ret_ueberschuss 0
2022.03.01 12:07:00.464 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 281
2022.03.01 12:07:00.471 5: set_charge_current() available_charge_current 18
2022.03.01 12:07:02.475 3: alfen_Socket_aussen: Timeout in Readanswer, current frame / read buffer: 004b0000000701030400000119, id 1, fCode 3, tid 75,
request: id 1, read fc 3 h1208, len 2, tid 75, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemaining len 2), queued 5.48 secs ago, sent 2.13 secs ago,
response: id 1, fc 3, h1208, len 2, values 00000119
2022.03.01 12:07:02.813 3: set_charge_current() set alfen_Socket_aussen Charge_Current 16
2022.03.01 12:07:02.813 5: set_charge_current() ret_ueberschuss 0
2022.03.01 12:07:02.818 1: Perfmon: possible freeze starting at 12:07:01, delay is 1.818
2022.03.01 12:07:06.814 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 295
2022.03.01 12:07:06.819 5: set_charge_current() available_charge_current 18
2022.03.01 12:07:06.820 5: set_charge_current() ret_ueberschuss 0
2022.03.01 12:07:11.290 2: set_charge_current() EVENTS MaxCurrentValidTimeRemaining: 291


Hoffe das war jetzt nicht zu verwirrend, wird für mich selbst langsam ziemlich komplex.
Danke für deine Hilfe,

Stephan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 04 März 2022, 16:17:01
Hallo Stefan,

habe eine Frage zu
obj-[cdih][1-9][0-9]*-hint
    this is used for set options and tells fhemweb what selection to display for the set option (list or slider etc.)


wie bekomme ich das mit einem Slider hin ? Ich bekomme nur per Drop Down Zahlen zum auswählen.
Hast du dafür ein Beispiel ?  so das auch die min max werte berücksichtigt werden ?

EDIT:  2 Std. suchen Try&Error....
nach dem Post hier kam die Erleuchtung mit der Lösung:

slider,5,1,75

5= min,  1 = Schrittweite, 75 = max.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 März 2022, 13:59:56
Hallo Stephan,

Könntest Du bitte nochmal einen Log-Auszug mit Verbose 5 posten? In dem letzten sehe ich zwar den Timeout, aber leider nicht den Kontext drum herum.
Das mit dem set aus einem DOIF, der auf ein Event des selben Devices triggert, könnte ein Teil des Problems sein.
Ohne explizites nonPrioritizedSet "drängelt sich dann das set vor" während der letzte Request noch gar nicht fertig abgearbeitet ist.
In einem ausführlichen Log müsste ich das aber sehen können.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: R1F800 am 25 März 2022, 10:22:20
Hallo Stefan,

da ich nun eine PV aufs Dach bekomme will ich demnächst die WP entsprechend der Leistung meiner PV steuern.
Hat der ModBus eine Möglichkeit die Settings in der ECODAN zu den SG Inputklemmen auch als SET Befehl zu senden?

Sprich IN11/IN12 der Klemmen TBI.3-8/10 (Eingang SmartGrid) mittels SET Befehl über Modbus?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 25 März 2022, 10:46:31
Zitat von: R1F800 am 25 März 2022, 10:22:20
Hallo Stefan,

da ich nun eine PV aufs Dach bekomme will ich demnächst die WP entsprechend der Leistung meiner PV steuern.
Hat der ModBus eine Möglichkeit die Settings in der ECODAN zu den SG Inputklemmen auch als SET Befehl zu senden?

Sprich IN11/IN12 der Klemmen TBI.3-8/10 (Eingang SmartGrid) mittels SET Befehl über Modbus?
Das hängt davon ab, ob der ModBus der WP das unterstützt. Oft kann man Register nur lesen und nicht schreiben.
Dazu solltest Du in der ModBus spezifikation der WP etwas finden können.

Gruß
    Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 27 März 2022, 07:51:23
Guten Morgen,

ich habe für meinen SDM72DM-V2 MID basierend auf dem Modul für den SDM630 ein Modul 98_ModbusSDM72DMV2.pm erstellt.
Bei den Holding Registers habe ich aber noch ein paar Verständnisprobleme.
Wenn ich z.B. die Pulskonstante, Register 40023, ändern möchte, bekomme ich eine Fehlermeldung und zwar:
Zitatset value 1 did not match defined map
Auch klappt das Auslesen der Seriennummer im Register 464513 nicht.
Vielleicht kann sich das mal einer der Spezialisten ansehen?

Norbert

7.4.22  Dateianhang entfernt und neue Version eingstellt
neue Version hier: https://forum.fhem.de/index.php/topic,75638.msg1217182.html#msg1217182 (https://forum.fhem.de/index.php/topic,75638.msg1217182.html#msg1217182)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 März 2022, 13:55:43
Hallo Norbert,

mit der Map, die Du für h22 angegeben hast, wird der Wert im Register für die Ein- und Ausgabe umgewandelt.
1:100imp/kWh gibt statt dem Registerwert 1 ein 100imp/kWh aus. Bei der Benutzereingabe läuft es genau anders herum. Statt 1 verwendet man beim set 100imp/kWh. Das Modul übersetzt das dann in 1.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 27 März 2022, 20:54:51
Hallo Stefan,

soweit ist mir das schon klar. Aber woher kommt die Fehlermeldung?
Syntaxfehler im Modul?
Ich steh' ein wenig auf dem Schlauch.

Norbert
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 27 März 2022, 21:56:25
Ich habe noch ein wenig rumprobiert.
Dabei ist mir folgende Fehlermeldung aufgefallen:
2022.03.27 21:44:52 3: ModBusLine: Send function code 10 not yet implemented
2022.03.27 21:44:52 1: PERL WARNING: Use of uninitialized value $pdu in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3616.
2022.03.27 21:44:52 1: stacktrace:
2022.03.27 21:44:52 1:     main::__ANON__                      called by ./FHEM/98_Modbus.pm (3616)
2022.03.27 21:44:52 1:     Modbus::PackFrame                   called by ./FHEM/98_Modbus.pm (3364)
2022.03.27 21:44:52 1:     Modbus::ProcessRequestQueue         called by ./FHEM/98_Modbus.pm (3193)
2022.03.27 21:44:52 1:     Modbus::QueueRequest                called by ./FHEM/98_Modbus.pm (3133)
2022.03.27 21:44:52 1:     Modbus::DoRequest                   called by ./FHEM/98_Modbus.pm (1099)
2022.03.27 21:44:52 1:     Modbus::SetLDFn                     called by fhem.pl (3926)
2022.03.27 21:44:52 1:     main::CallFn                        called by fhem.pl (1955)
2022.03.27 21:44:52 1:     main::DoSet                         called by fhem.pl (1987)
2022.03.27 21:44:52 1:     main::CommandSet                    called by fhem.pl (1272)
2022.03.27 21:44:52 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2801)
2022.03.27 21:44:52 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2022.03.27 21:44:52 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (608)
2022.03.27 21:44:52 1:     main::FW_Read                       called by fhem.pl (3931)
2022.03.27 21:44:52 1:     main::CallFn                        called by fhem.pl (780)
2022.03.27 21:44:52 1: PERL WARNING: Use of uninitialized value $pdu in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3617.
2022.03.27 21:44:52 1: stacktrace:
2022.03.27 21:44:52 1:     main::__ANON__                      called by ./FHEM/98_Modbus.pm (3617)
2022.03.27 21:44:52 1:     Modbus::PackFrame                   called by ./FHEM/98_Modbus.pm (3364)
2022.03.27 21:44:52 1:     Modbus::ProcessRequestQueue         called by ./FHEM/98_Modbus.pm (3193)
2022.03.27 21:44:52 1:     Modbus::QueueRequest                called by ./FHEM/98_Modbus.pm (3133)
2022.03.27 21:44:52 1:     Modbus::DoRequest                   called by ./FHEM/98_Modbus.pm (1099)
2022.03.27 21:44:52 1:     Modbus::SetLDFn                     called by fhem.pl (3926)
2022.03.27 21:44:52 1:     main::CallFn                        called by fhem.pl (1955)
2022.03.27 21:44:52 1:     main::DoSet                         called by fhem.pl (1987)
2022.03.27 21:44:52 1:     main::CommandSet                    called by fhem.pl (1272)
2022.03.27 21:44:52 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2801)
2022.03.27 21:44:52 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2022.03.27 21:44:52 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (608)
2022.03.27 21:44:52 1:     main::FW_Read                       called by fhem.pl (3931)
2022.03.27 21:44:52 1:     main::CallFn                        called by fhem.pl (780)
2022.03.27 21:44:54 3: ModBusLine: Timeout in Readanswer, read buffer empty,
request: id 1, write fc 10 h58, len 2, value 41200000, master device SDM72, reading scrollDisplaytime (set scrollDisplaytime), queued 2.00 secs ago, sent 2.00 secs ago   


Die Angabe zum function code für das Schreiben der Holdings habe ich aus der Doku.
https://xn--stromzhler-v5a.eu/media/pdf/93/17/d7/SDM72DM-V2.pdf (https://xn--stromzhler-v5a.eu/media/pdf/93/17/d7/SDM72DM-V2.pdf)

Beim SDM630 ist dafür der code 16 angegeben.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 März 2022, 22:41:25
Hallo Norbert,

So wie Du die Map definiert hast, erwartet das Modul beim set einen Wert wie "100imp/kWh" und möchte den dann in eine 1 übersetzen. Wenn Du aber beim set eine 1 angeben möchtest, dann darfst Du keine Map verwenden. Oder eben beim set den Wert 100imp/kWh und nicht 1 angeben.
Die Meldung besagt genau das: Du hast einen Wert angegeben, der nicht zur Map passt.

Was den zweiten Fehler angeht, so hast Du scheinbar statt function code 16 fälschlicherweise function code 10 definiert. Die Meldung weist darauf hin dass der nicht implementiert ist. Den (Dezimal 10 bzw. Hex 0x0A) gibt es übrigens auch im Standard nicht.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 27 März 2022, 22:46:52
Zitat von: StefanStrobel am 27 März 2022, 22:41:25
Was den zweiten Fehler angeht, so hast Du scheinbar statt function code 16 fälschlicherweise function code 10 definiert. Die Meldung weist darauf hin dass der nicht implementiert ist. Den (Dezimal 10 bzw. Hex 0x0A) gibt es übrigens auch im Standard nicht.

Ahh, dann ist die Angabe für den code als Hex-Wert zu verstehen.
Das mit dem mapping schaue ich mir noch enmal an.

Norbert
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 28 März 2022, 06:18:14
Zitat von: StefanStrobel am 27 März 2022, 22:41:25
So wie Du die Map definiert hast, erwartet das Modul beim set einen Wert wie "100imp/kWh" und möchte den dann in eine 1 übersetzen. Wenn Du aber beim set eine 1 angeben möchtest, dann darfst Du tatt
Die Kombination aus map und hint habe ich so aus dem Modul SDM630 übernommen.
Daher hatte ich die Kombi daraus nicht weiter betrachtet und es verhält sich anders, als ich erwartet hatte.
Ich habe es geändert und jetzt funktioniert es.
Das Schreiben der holdings klappt jetzt auch.
Die Datei im Post#900 habe ich ausgetauscht.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 07 April 2022, 10:45:43
Hallo zusammen,

ich habe am meinem Modul zum SDM72DMv2 noch ein paar Änderungen vorgenommen.
Weiterhin habe ich noch ein Modul für den SDM120 erstellt.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 07 Mai 2022, 21:37:42
Guten Abend Zusammen,
es hat nun über ein Jahr gedauert um den Optidrive FU endlich anzuschliessen...
Ich habe im letztem Jahr einfach nicht mehr die Zeit gehabt - und brauchte ja die Pumpe des Pools um die Wasserqualität aufrecht zu erhalten.
Ausserdem musste ich ja auch noch den Pool benutzen.
Hier mein Beitrag vom letztem Jahr nochmal:

Zitat von: der-Lolo am 21 März 2021, 12:29:00
Hallo Stefan - und mitleser,
ich habe mir einen Invertek Optidrive E3 Frequenzumrichter gekauft - und möchte diesen mit dem Modbus/RTU Modul in FHEM einbinden.
Aus den gegebenen Daten werde ich allerdings nicht richtig schlau.

Ich benutze den USB-RS485 Adapter von IN-Circuit und bin schon unsicher was die Stellungen der DIP-Switches angeht.
Ich habe es auch noch nicht geschafft eine vernünftige Antwort des FUs zu bekommen.

Ich habe zwar vor etwa 5 Jahren schon eine Modbus/RTU definition für meinen Wärmemengenzähler erstellt, diese läuft aber so problemlos das ich da nie wieder ran musste und ich über die Jahre natürlich die vorgehensweise vergessen habe.

Als Anhang mal die Seite der BA des FUs auf der es um den Modbus geht...

Fühlt sich jemand in der lage mir zu helfen - sodass ich z.b. mal ein Beispiel Reading habe?
Das wäre toll!

Wir haben damals noch Beispielhaft ein erstes reading erstellt ung geschaut ob der Datentransfer funktioniert.

Heute habe ich nun den Pool wieder ausgewintert und die Pumpe diesesmal direkt mit FU in Betrieb genommen. Grundsätzlich bin ich begeistert wie gut die Pumpe mit dem FU funktioniert, auch darüber das das alles deutlich leider geworden ist.

Ich habe jetzt das Modbus Modul wieder auf den FU losgelassen, und erste readings hinzugefügt. Mir stellt sich aber noch die dringende frage wie ich den FU schalten kann. Ich könnte dem Ding einfach den Saft abdrehen, das ist aber nicht ganz in meinem Sinn...

Im FHEM Log habe ich nun einige eigenartige einträge die ich noch nicht verstehe, vielleicht könnt ihr mir was dazu sagen.

2022.05.07 20:55:56 1: OWXTHERM_BinValues:  PoolTemp: invalid CRC,  15.625  0xfa 0x00 0x4b 0x46 0x7f 0x7f 0x03 0x08 0xd2
2022.05.07 20:55:54 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  -113.3125  0xeb 0x80 0x25 0xa3 0xbf 0xff 0x02 0x08 0xf3
2022.05.07 20:55:13 1: OWXTHERM_BinValues:  SolarRLTemp: invalid CRC,  18.875  0x2e 0x01 0x4b 0xa6 0xbf 0x7f 0x01 0x08 0x9c
2022.05.07 20:54:47 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.75  0xec 0x00 0x4b 0x46 0x7f 0xff 0x04 0x08 0xf9
2022.05.07 20:54:40 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:54:36 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.75  0xec 0x00 0x4b 0x46 0x7f 0xff 0x04 0x10 0xf9
2022.05.07 20:54:29 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020029799abfbfbf
2022.05.07 20:54:18 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:54:17 1: OWXTHERM_BinValues:  SolarRLTemp: invalid CRC,  -109.125  0x2e 0x81 0x25 0xa3 0xbf 0x7f 0x01 0x08 0x9c
2022.05.07 20:54:02 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.875  0xee 0x00 0x4b 0x46 0x7f 0xff 0x02 0x08 0xef
2022.05.07 20:53:55 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020029799a
2022.05.07 20:53:53 1: OWXTHERM_BinValues:  PoolTemp: invalid CRC,  15.625  0xfa 0x00 0x4b 0xa3 0xbf 0x7f 0x03 0x08 0xd2
2022.05.07 20:53:44 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:53:40 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.75  0xec 0x00 0x4b 0x46 0x7f 0xff 0x04 0x10 0xf9
2022.05.07 20:53:22 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020029799a
2022.05.07 20:53:11 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:53:00 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:52:55 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.9375  0xef 0x00 0x4b 0x46 0x7f 0xff 0x01 0x10 0xe4
2022.05.07 20:52:48 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020028b85abfbfbfbfbfbfbfbfbfbfbfbfffbfbfbfbfbfbfbfbfbfbfbfbfbfbfbf
2022.05.07 20:52:37 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:52:26 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844bfbf
2022.05.07 20:51:41 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020028b85a
2022.05.07 20:51:37 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  15  0xf0 0x00 0x4b 0x46 0x7f 0x7f 0x08 0x88 0xd3
2022.05.07 20:51:30 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:50:57 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:50:43 1: OWXTHERM_BinValues:  PoolTemp: invalid CRC,  15.625  0xfa 0x00 0x4b 0x46 0x7f 0xff 0x06 0x10 0xd4
2022.05.07 20:50:35 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020028b85abfbfbfbfbfbfbfbfbfbf
2022.05.07 20:50:26 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:50:24 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:50:01 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020028b85a
2022.05.07 20:49:50 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:49:38 1: OWXTHERM_BinValues:  SolarRLTemp: invalid data,  18.875  0x2e 0x01 0x4b 0x46 0x7f 0xff 0x02 0x00 0x9c
2022.05.07 20:49:28 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020027f85e
2022.05.07 20:49:28 1: OWXTHERM_BinValues:  SolarRLTemp: invalid CRC,  18.875  0x2e 0x01 0x4b 0x46 0x7f 0xff 0x02 0x10 0xce
2022.05.07 20:49:23 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.9375  0xef 0x00 0x4b 0xa2 0xbf 0xff 0x00 0x08 0xe4
2022.05.07 20:49:12 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2022.05.07 20:49:01 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  15.0625  0xf1 0x00 0x4b 0x46 0x7f 0xff 0x07 0x88 0xfc
2022.05.07 20:48:54 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020027f85e
2022.05.07 20:48:46 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:48:43 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:48:32 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:47:03 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:46:52 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:46:18 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:45:56 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:45:51 1: OWXTHERM_BinValues:  AbsorberTemp: invalid data,  15  0xf0 0x00 0x4b 0x46 0x7f 0xff 0x10 0x00 0xa7
2022.05.07 20:45:18 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  15.125  0xf2 0x00 0x4b 0xa2 0xbf 0x7f 0x07 0x08 0xfc


Bevor ich den FU benutzt habe hatte ich keine CRC Fehler beim OWX - damit könnte ich aber wohl noch leben, ich vermute hier vielleicht einen zusammenhang mit den Frequenzen des Umrichters, obwohl natürlich ein abgeschirmtes Kabel zum Einsatz kommt.

Eigenartig sind aber auch die Meldungen des modbusRTU Moduls. Was haben die zu sagen?

Der vollständigkeit halber noch ein List des FUs bisher:

Internals:
   DEF        1 15
   FUUID      605728c9-f33f-cc16-22a8-16628e1f3a34f255
   IODev      modbusRTU
   Interval   15
   LeadingZeros 1
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       Optidrive
   NOTIFYDEV  global
   NR         25
   NTFY_ORDER 50-Optidrive
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   OLDREADINGS:
   READ:
   READINGS:
     2022-05-07 21:35:36   Frequenz        20
     2022-05-07 21:35:36   UmrichterTemperatur 30.8
     2022-05-07 21:35:47   Verzoegerungszeit 0
     2022-05-07 21:35:46   scan-h00001     0
     2022-05-07 21:35:47   scan-h00002     0
     2022-05-07 21:35:47   scan-h00005     0
     2022-05-07 21:35:47   scan-h00006     0
     2022-05-07 21:35:47   scan-h00007     0
     2022-05-07 21:35:47   scan-h00008     0
     2022-05-07 21:35:47   scan-h00010     0
     2022-05-07 21:35:47   scan-h00011     8769
     2022-05-07 21:35:47   scan-h00012     110
     2022-05-07 21:35:34   scan-h00013     230
     2022-05-07 21:35:34   scan-h00014     305
     2022-05-07 21:35:34   scan-h00015     305
     2022-05-07 21:35:34   scan-h00017     0
     2022-05-07 21:35:35   scan-h00018     0
     2022-05-07 21:35:35   scan-h00019     0
     2022-05-07 21:35:36   scan-h00020     0
     2022-05-07 21:35:36   scan-h00021     20
     2022-05-07 21:35:36   scan-h00023     30
     2022-05-07 21:35:36   scan-h00024     1
     2022-05-07 21:35:36   scan-h00025     2
     2022-05-07 21:35:36   scan-h00026     8762
     2022-05-07 21:35:36   scan-h00027     60
     2022-05-07 21:35:37   scan-h00028     0
     2022-05-07 21:35:37   scan-h00029     0
     2022-05-07 21:35:37   scan-h00030     0
     2022-05-07 21:35:37   scan-h00031     169
     2022-05-07 21:35:37   scan-h00032     0
     2022-05-07 21:35:37   scan-h00033     344
     2022-05-07 21:35:40   scan-h00035     6
     2022-05-07 21:35:43   scan-h00037     0
     2022-05-07 21:35:44   scan-h00038     39
     2022-05-07 17:22:45   state           opened
   REMEMBER:
     lrecv      1651952149.07814
     lsend      1651952149.0718
   gotReadings:
     scan-h00012 110
   lastRead:
     h00001     1651952146.95708
     h00002     1651952147.06438
     h00005     1651952147.17662
     h00006     1651952147.39997
     h00007     1651952147.51164
     h00008     1651952147.62375
     h00010     1651952147.73539
     h00011     1651952147.84935
     h00012     1651952147.95884
     h00013     1651952134.39338
     h00014     1651952134.50547
     h00015     1651952134.61772
     h00017     1651952134.72984
     h00018     1651952135.85269
     h00019     1651952135.95616
     h00020     1651952136.07154
     h00021     1651952136.18413
     h00023     1651952136.51883
     h00024     1651952136.63094
     h00025     1651952136.74303
     h00026     1651952136.85512
     h00027     1651952136.96732
     h00028     1651952137.08324
     h00029     1651952137.1903
     h00030     1651952137.30238
     h00031     1651952137.41448
     h00032     1651952137.52791
     h00033     1651952137.63758
     h00035     1651952140.85418
     h00037     1651952143.06529
     h00038     1651952144.26827
     h1         1651935531.60758
     h10        1651935551.37809
     h11        1651935551.48418
     h12        1651935552.43417
     h13        1651935554.05189
     h14        1651935555.04006
     h15        1651935561.21311
     h17        1651935562.53435
     h18        1651935563.43625
     h19        1651935565.03555
     h2         1651935532.59896
     h20        1651935566.04808
     h21        1651952136.29673
     h22        1651952136.40846
     h23        1651935573.87173
     h24        1651935574.89272
     h25        1651935575.88447
     h26        1651935577.69951
     h27        1651935584.91814
     h28        1651935585.01575
     h29        1651935585.1649
     h30        1651935585.99413
     h31        1651935587.56223
     h32        1651935588.55449
     h33        1651935593.71163
     h35        1651935596.0538
     h37        1651935598.5601
     h38        1651935599.57278
     h5         1651935540.41586
     h6         1651952147.29162
     h7         1651935542.38923
     h8         1651935544.21082
Attributes:
   dev-h-defPoll 1
   obj-h00001-reading scan-h00001
   obj-h00002-reading scan-h00002
   obj-h00005-reading scan-h00005
   obj-h00006-reading scan-h00006
   obj-h00007-reading scan-h00007
   obj-h00008-reading scan-h00008
   obj-h00010-reading scan-h00010
   obj-h00011-reading scan-h00011
   obj-h00012-reading scan-h00012
   obj-h00013-reading scan-h00013
   obj-h00014-reading scan-h00014
   obj-h00015-reading scan-h00015
   obj-h00017-reading scan-h00017
   obj-h00018-reading scan-h00018
   obj-h00019-reading scan-h00019
   obj-h00020-reading scan-h00020
   obj-h00021-reading scan-h00021
   obj-h00023-reading scan-h00023
   obj-h00024-reading scan-h00024
   obj-h00025-reading scan-h00025
   obj-h00026-reading scan-h00026
   obj-h00027-reading scan-h00027
   obj-h00028-reading scan-h00028
   obj-h00029-reading scan-h00029
   obj-h00030-reading scan-h00030
   obj-h00031-reading scan-h00031
   obj-h00032-reading scan-h00032
   obj-h00033-reading scan-h00033
   obj-h00035-reading scan-h00035
   obj-h00037-reading scan-h00037
   obj-h00038-reading scan-h00038
   obj-h21-expr $val / 10
   obj-h21-reading Frequenz
   obj-h21-unpack n
   obj-h22-expr $val / 10
   obj-h22-reading UmrichterTemperatur
   obj-h22-unpack n
   obj-h6-expr $val / 10
   obj-h6-reading Verzoegerungszeit
   obj-h6-unpack n


Könnt Ihr mir helfen den FU vollständig zu integrieren?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: hugomckinley am 08 Mai 2022, 22:53:51
Hallo Lolo,
ich kann dir zwar bei deinem eigentlichen Problem nicht helfen, aber bezüglich CRC Fehler des 1wire-Buses, hatte ich das "selbe" Problem.
Ich trau mich das als "Fachperson" fast nicht sagen, aber ich habe aus Faulheit versucht, den 1wire-Bus und den RS485-Bus auf dem selben CAT5 Kabel zu betreiben. Hat ja genug Adern ;-)
Ergbnis war, dass ich mich irrsinnig gefreut habe, dass der RS485 Bus auf Anhieb funktioniert hat, aber ich bin dann später draufgekommen, dass ich auch diese CRC Fehler habe.
Nachdem ich für den RS485 ein eigenes Kabel gezogen habe, waren die CRC-Fehler wieder weg. Ich konnte definitv nicht damit leben, denn mein 1wire-Bus hat nur mehr sporadisch funktioniert. (Obwohl auf dem RS485 eigentlich nichts los war, aber das habe ich dann nicht hinterfragt)
Ich nehme an, dass du deine Busse in getrennten Kabeln hast, aber ich bin mir ziemlich sicher, dass es auch an den Störungen eines der zusätzlichen Systemen (FU oder Bus) liegt.

Gruß,
Hugo
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 Mai 2022, 18:30:21
Hallo,

die Meldungen von modbusRTU deuten darauf hin, dass ein anderer Modbus-Master auf dem gleichen Kabel aktiv ist.
Das geht bei Modbus nicht. Es darf nur einen Master geben.

Um dem FU Befehle schicken zu können, brauchst Du die Registerbelegung des FU. Da wird es eines für die Frequenz bzw. für an / aus geben.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: der-Lolo am 10 Mai 2022, 22:50:29
Danke hugomckinley, Danke Stefan....
Am Sonntag habe ich den FU wieder abgeklemmt - es gab ein paar Seiteneffekte die offensichtlich vom FU verursacht wurden.
Da die Pumpe eh nicht "überdimensioniert" ist und somit wahrscheinlich meistens mit 50Hz laufen müsste, wir noch dazu kurz davor sind eine Solaranlage aufzubauen glaube ich das es besser ist auf den FU zu verzichten.

Schade, es hätte mir gefallen die Pumpe mit dem FU passend zur Spreizung der Durchlauf Solar-Warm-Wasser anlage zu regeln...

Aktuell kann ich den Fu wahrscheinlich sogar Gewinn bringend weiter verkaufen, es ist unglaublich was auf dem Markt bei solchem Material los ist.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 15 Mai 2022, 21:32:03
Hi,
ich habe eine Frage zum Modul ModbusAttr, welches ich zum Abfragen meines Sungrow Wechselrichters verwende:

Gibt es eine Obergrenze zu der Anzahl von Readings? Es werden offenbar nicht alle Register abgefragt, die ich konfiguriert habe und ich frage mich, woran das liegt bzw. ob das an einer Obergrenze liegt.

Ich habe ca. 250 Readings / Abfragen für Input Register / Holding Register mit Modbus TCP konfiguriert.
Das Intervall ist 30s. Von den 250 Readings sind 20 ohne polldelay, also mit Intervall 30s.
30 Readings sind mit poll-delay / Intervall 5min, 190 mit Intervall 8 Stunden definiert.

Beispiel:


defmod SH10rt_1 ModbusAttr 1 30 192.168.x.x:502 TCP
attr SH10rt_1 closeAfterResponse 0
attr SH10rt_1 dev-type-S16-len 1
attr SH10rt_1 dev-type-S16-unpack s>
attr SH10rt_1 dev-type-S32-len 2
attr SH10rt_1 dev-type-S32-revRegs 1
attr SH10rt_1 dev-type-S32-unpack l>
attr SH10rt_1 dev-type-SL_R2-len 2
attr SH10rt_1 dev-type-SL_R2-unpack l
attr SH10rt_1 dev-type-U16-len 1
attr SH10rt_1 dev-type-U16-unpack N
attr SH10rt_1 dev-type-U32-len 2
attr SH10rt_1 dev-type-U32-revRegs 1
attr SH10rt_1 dev-type-U32-unpack Na
attr SH10rt_1 dev-type-UL_R2-len 2
attr SH10rt_1 dev-type-UL_R2-revRegs 1
attr SH10rt_1 dev-type-UL_R2-unpack N
attr SH10rt_1 disable 0
attr SH10rt_1 event-on-change-reading .*
attr SH10rt_1 icon solar_icon
attr SH10rt_1 obj-i12999-poll 1
attr SH10rt_1 obj-i12999-reading 98_System_State
attr SH10rt_1 obj-i13000-poll 1
attr SH10rt_1 obj-i13000-reading 99_Running_State
attr SH10rt_1 obj-i13001-expr $val/10
attr SH10rt_1 obj-i13001-poll 1
attr SH10rt_1 obj-i13001-polldelay x10
attr SH10rt_1 obj-i13001-reading Daily_PV_Generation
attr SH10rt_1 obj-i13002-expr $val/10
...
attr SH10rt_1 obj-i6640-type U32
attr SH10rt_1 obj-i6642-expr $val/10
attr SH10rt_1 obj-i6642-polldelay x1000
attr SH10rt_1 obj-i6642-reading Yearly_Export_Energy_PV_18
attr SH10rt_1 obj-i6642-type U32
attr SH10rt_1 obj-i6644-expr $val/10
attr SH10rt_1 obj-i6644-polldelay x1000
attr SH10rt_1 obj-i6644-reading Yearly_Export_Energy_PV_19
attr SH10rt_1 obj-i6644-type U32
attr SH10rt_1 obj-i6646-expr $val/10
attr SH10rt_1 obj-i6646-polldelay x1000
attr SH10rt_1 obj-i6646-reading Yearly_Export_Energy_PV_20
attr SH10rt_1 obj-i6646-type U32
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Mai 2022, 16:52:20
Hallo FhemPiUser,

eigentlich gibt es keine Obergrenze.
Setz doch mal Verbose auf 5 und poste einen langen Auszug aus dem Log.
Da müsste man sehen was passiert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 22 Mai 2022, 19:41:24
Habe auf verbose 5 gesetzt und "tail -f ... | grep "i63" gemacht und die einzige Meldung die z.B. von Register i63xx bekomme ist immer wieder Folgende:


SH10rt_1: CreateUpdateList full object list: i12999 i13000 i13001 i13002 i13004 i13005 i13007 i13008 i13009 i13010 i13011 i13012 i13016 i13017 i13019 i13020 i13021 i13022 i13023 i13024 i13025 i13026 i13028 i13029 i13033 i13035 i13036 i13039 i13040 i13044 i13045 i13049 i13051 i13053 i13055 i13057 i13059 i13061 i13063 i13065 i13067 i13069 i13071 i13073 i13075 i13077 i5002 i5003 i5007 i5010 i5011 i5012 i5013 i5016 i5035 i6196 i6197 i6198 i6199 i6200 i6201 i6202 i6203 i6204 i6205 i6206 i6207 i6208 i6209 i6210 i6211 i6212 i6213 i6214 i6215 i6216 i6217 i6218 i6219 i6220 i6221 i6222 i6223 i6224 i6225 i6226 i6250 i6252 i6254 i6256 i6258 i6260 i6262 i6264 i6266 i6268 i6270 i6272 i6274 i6276 i6278 i6280 i6282 i6284 i6286 i6288 i6386 i6387 i6388 i6389 i6390 i6391 i6392 i6393 i6394 i6395 i6396 i6397 i6398 i6399 i6400 i6401 i6402 i6403 i6404 i6405 i6406 i6407 i6408 i6409 i6410 i6411 i6412 i6413 i6414 i6415 i6416 i6417 i6418 i6419 i6420 i6421 i6422 i6423 i6424 i6425 i6426 i6427 i6429 i6430 i6431 i6432 i6433 i6434 i6435 i6436 i6437 i6438 i6439 i6440 i6441 i6442 i6443 i6444 i6445 i6446 i6447 i6448 i6449 i6451 i6453 i6455 i6457 i6459 i6461 i6463 i6465 i6467 i6468 i6469 i6565 i6566 i6567 i6568 i6569 i6570 i6571 i6572 i6573 i6574 i6575 i6576 i6577 i6578 i6579 i6580 i6581 i6582 i6583 i6584 i6585 i6586 i6587 i6588 i6589 i6590 i6591 i6592 i6593 i6594 i6595 i6596 i6597 i6598 i6599 i6600 i6601 i6602 i6603 i6604 i6605 i6606 i6608 i6610 i6612 i6614 i6616 i6618 i6620 i6622 i6624 i6626 i6627 i6628 i6629 i6630 i6631 i6632 i6633 i6634 i6635 i6636 i6637 i6638 i6640 i6642 i6644 i6646


Er liest einfach nur bestimmte Register, das sieht dann z.B. für i13022 so aus:


2022.05.22 19:30:13.680 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 172, master device SH10rt_1, reading Battery_Level (getUpdate for Battery_Level len 1), queued 2.04 secs ago
2022.05.22 19:30:13.680 5: SH10rt_1: checkDelays sendDelay, last send to same device was 0.021 secs ago, required delay is 0.1
2022.05.22 19:30:13.680 5: SH10rt_1: checkDelays commDelay, last communication with same device was 0.012 secs ago, required delay is 0.1
2022.05.22 19:30:13.680 5: SH10rt_1: checkDelays clientSwitchDelay is not relevant
2022.05.22 19:30:13.681 5: SH10rt_1: checkDelays busDelayRead, last activity on bus was 0.012 secs ago, required delay is 0
2022.05.22 19:30:13.681 4: SH10rt_1: checkDelays found commDelay not over, set timer to try again in 0.088
2022.05.22 19:30:13.774 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 172, master device SH10rt_1, reading Battery_Level (getUpdate for Battery_Level len 1), queued 2.13 secs ago
2022.05.22 19:30:13.775 5: SH10rt_1: checkDelays clientSwitchDelay is not relevant
2022.05.22 19:30:13.775 5: SH10rt_1: checkDelays busDelayRead, last activity on bus was 0.106 secs ago, required delay is 0
2022.05.22 19:30:13.775 5: SH10rt_1: checkDelays commDelay, last communication with same device was 0.106 secs ago, required delay is 0.1
2022.05.22 19:30:13.775 5: SH10rt_1: checkDelays sendDelay, last send to same device was 0.116 secs ago, required delay is 0.1
2022.05.22 19:30:13.776 4: SH10rt_1: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 00ac00000006010432de0001 via 192.168.3.160:502, read buffer empty,
request: id 1, read fc 4 i13022, len 1, tid 172, master device SH10rt_1, reading Battery_Level (getUpdate for Battery_Level len 1), queued 2.13 secs ago
2022.05.22 19:30:13.776 5: SH10rt_1: Send called from ProcessRequestQueue
2022.05.22 19:30:13.776 5: DevIo_SimpleWrite SH10rt_1: 00ac00000006010432de0001
2022.05.22 19:30:13.781 5: SH10rt_1: readFn buffer: 00ac0000000501040203e8
2022.05.22 19:30:13.781 5: SH10rt_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.05.22 19:30:13.781 4: SH10rt_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 172, dlen 5 and potential data 0203e8
2022.05.22 19:30:13.782 5: SH10rt_1: HandleResponse called from ReadFn
2022.05.22 19:30:13.782 5: SH10rt_1: ParseResponse called from HandleResponse
2022.05.22 19:30:13.783 5: SH10rt_1: now parsing response data objects, master is SH10rt_1 relay is undefined
2022.05.22 19:30:13.783 5: SH10rt_1: ParseDataString called from HandleResponse with data hex 03e8, type i, adr 13022, op read
2022.05.22 19:30:13.783 5: SH10rt_1: SplitDataString called from ParseDataString with data hex 03e8, type i, adr 13022, valuesLen 1, op read
2022.05.22 19:30:13.784 5: SH10rt_1: CreateDataObjects called from ParseDataString with objList i13022
2022.05.22 19:30:13.785 5: SH10rt_1: CreateDataObjects sortedList i13022
2022.05.22 19:30:13.785 5: SH10rt_1: CreateDataObjects unpacked 03e8 with n to 1000
2022.05.22 19:30:13.787 5: SH10rt_1: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/10 to 100
2022.05.22 19:30:13.788 4: SH10rt_1: CreateDataObjects assigns value 100 to Battery_Level
2022.05.22 19:30:13.789 5: SH10rt_1: ParseDataString created 1 readings
2022.05.22 19:30:13.789 4: SH10rt_1: HandleResponse done, current frame / read buffer: 00ac0000000501040203e8, id 1, fCode 4, tid 172,
request: id 1, read fc 4 i13022, len 1, tid 172, master device SH10rt_1, reading Battery_Level (getUpdate for Battery_Level len 1), queued 2.14 secs ago, sent 0.02 secs ago,
response: id 1, fc 4, i13022, len 1, values 03e8
2022.05.22 19:30:13.790 5: SH10rt_1: ResetExpect for HandleResponse from response to idle
2022.05.22 19:30:13.794 5: SH10rt_1: DropFrame called from ReadFn - drop 00ac0000000501040203e8


Für andere Register wie z.B. i6389 kommt garnichts außer das "CreateUpdateList full object list" von oben.

Meine Config für das Register i6389 sieht wie folgt aus:


attr SH10rt_1 obj-i6389-expr $val/10
attr SH10rt_1 obj-i6389-polldelay x2
attr SH10rt_1 obj-i6389-reading Daily_Direct_Energy_Consumption_PV_4


Jemand eine Idee, woran das liegen kann?

Ich kann auch die ganze Config mal posten, aber die ist mit 250 Registern ziemlich lang...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 22 Mai 2022, 21:13:36
Ich habe mal ein neues Device angelegt mit nur einem Reading für Register i6399 und es geht auch nicht. Es liegt also nicht an einer Obergrenze. Aber warum kann er die Register dann nicht lesen?

Verbose 5 sagt Folgendes:

2022.05.22 21:09:28.603 4: SH10rt_1_LAN: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2022.05.22 21:09:28.604 4: SH10rt_1_LAN: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 30.0 sec at 21:09:58.604, interval 30
2022.05.22 21:09:28.607 5: SH10rt_1_LAN: CreateUpdateList full object list: i6399
2022.05.22 21:09:28.608 4: SH10rt_1_LAN: CombineUpdateHash objHash keys before combine:
2022.05.22 21:09:28.609 5: SH10rt_1_LAN: CombineUpdateHash tries to combine read commands
2022.05.22 21:09:28.610 5: SH10rt_1_LAN: CombineUpdateHash keys are now
2022.05.22 21:09:28.610 4: SH10rt_1_LAN: GetUpdate will now create requests for
2022.05.22 21:09:38.790 3: 192.168.x.x:502 disconnected, waiting to reappear (SH10rt_1_LAN)
2022.05.22 21:09:38.821 3: 192.168.x.x:502 reappeared (SH10rt_1_LAN)
2022.05.22 21:09:38.832 4: SH10rt_1_LAN: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 19.8 sec at 21:09:58.604, interval 30
2022.05.22 21:09:54.952 3: 192.168.x.x:502 disconnected, waiting to reappear (SH10rt_1_LAN)
2022.05.22 21:09:54.977 3: 192.168.x.x:502 reappeared (SH10rt_1_LAN)
2022.05.22 21:09:54.987 4: SH10rt_1_LAN: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 3.6 sec at 21:09:58.604, interval 30
2022.05.22 21:09:58.613 4: SH10rt_1_LAN: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2022.05.22 21:09:58.616 4: SH10rt_1_LAN: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 30.0 sec at 21:10:28.615, interval 30
2022.05.22 21:09:58.620 5: SH10rt_1_LAN: CreateUpdateList full object list: i6399
2022.05.22 21:09:58.623 4: SH10rt_1_LAN: CombineUpdateHash objHash keys before combine:
2022.05.22 21:09:58.624 5: SH10rt_1_LAN: CombineUpdateHash tries to combine read commands
2022.05.22 21:09:58.626 5: SH10rt_1_LAN: CombineUpdateHash keys are now
2022.05.22 21:09:58.627 4: SH10rt_1_LAN: GetUpdate will now create requests for
2022.05.22 21:10:11.730 3: 192.168.x.x:502 disconnected, waiting to reappear (SH10rt_1_LAN)
2022.05.22 21:10:11.854 3: 192.168.x.x:502 reappeared (SH10rt_1_LAN)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Mai 2022, 16:18:15
Hallo FhemPiUser,

hast Du denn die Register auch zum Pollen markiert bzw. sowas wie dev-i-defPoll gesetzt?
i6399 scheint jedenfalls nicht abgefragt zu werden ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 23 Mai 2022, 17:03:31
ohh, danke, natürlich fehlte das poll 1. 

Aber trotzdem erscheint kein Reading. Folgendes steht im Log mit verbose 5:


2022.05.23 16:58:26.160 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 21, request: request: id 1, read fc 4 i6399, len 1, tid 216, master device SH10rt_1, reading Daily_Direct_Energy_Consumption_PV_14 (getUpdate for Daily_Direct_Energy_Consumption_PV_14 len 1), queued 1.37 secs ago
2022.05.23 16:58:26.161 5: SH10rt_1: checkDelays sendDelay, last send to same device was 0.028 secs ago, required delay is 0.1
2022.05.23 16:58:26.161 5: SH10rt_1: checkDelays clientSwitchDelay is not relevant
2022.05.23 16:58:26.161 5: SH10rt_1: checkDelays busDelayRead, last activity on bus was 0.024 secs ago, required delay is 0
2022.05.23 16:58:26.162 5: SH10rt_1: checkDelays commDelay, last communication with same device was 0.024 secs ago, required delay is 0.1
2022.05.23 16:58:26.162 4: SH10rt_1: checkDelays found commDelay not over, set timer to try again in 0.076
2022.05.23 16:58:26.243 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 21, request: request: id 1, read fc 4 i6399, len 1, tid 216, master device SH10rt_1, reading Daily_Direct_Energy_Consumption_PV_14 (getUpdate for Daily_Direct_Energy_Consumption_PV_14 len 1), queued 1.45 secs ago
2022.05.23 16:58:26.244 5: SH10rt_1: checkDelays sendDelay, last send to same device was 0.111 secs ago, required delay is 0.1
2022.05.23 16:58:26.244 5: SH10rt_1: checkDelays busDelayRead, last activity on bus was 0.107 secs ago, required delay is 0
2022.05.23 16:58:26.244 5: SH10rt_1: checkDelays clientSwitchDelay is not relevant
2022.05.23 16:58:26.245 5: SH10rt_1: checkDelays commDelay, last communication with same device was 0.107 secs ago, required delay is 0.1
2022.05.23 16:58:26.245 4: SH10rt_1: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 21, sending 00d800000006010418ff0001 via 192.168.3.160:502, read buffer empty,
request: id 1, read fc 4 i6399, len 1, tid 216, master device SH10rt_1, reading Daily_Direct_Energy_Consumption_PV_14 (getUpdate for Daily_Direct_Energy_Consumption_PV_14 len 1), queued 1.45 secs ago
2022.05.23 16:58:26.245 5: SH10rt_1: Send called from ProcessRequestQueue
2022.05.23 16:58:26.245 5: DevIo_SimpleWrite SH10rt_1: 00d800000006010418ff0001
2022.05.23 16:58:26.248 5: SH10rt_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.05.23 16:58:26.251 5: SH10rt_1: readFn buffer: 00d800000002018402
2022.05.23 16:58:26.251 5: SH10rt_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.05.23 16:58:26.251 4: SH10rt_1: ParseFrameStart (TCP, master) extracted id 1, fCode 132, tid 216, dlen 2 and potential data 02
2022.05.23 16:58:26.252 5: SH10rt_1: HandleResponse called from ReadFn
2022.05.23 16:58:26.252 5: SH10rt_1: ParseResponse called from HandleResponse
2022.05.23 16:58:26.252 4: SH10rt_1: HandleResponse got response with error code 84 / 02, illegal data address
2022.05.23 16:58:26.253 4: SH10rt_1: HandleResponse done, current frame / read buffer: 00d800000002018402, id 1, fCode 132, tid 216,
request: id 1, read fc 4 i6399, len 1, tid 216, master device SH10rt_1, reading Daily_Direct_Energy_Consumption_PV_14 (getUpdate for Daily_Direct_Energy_Consumption_PV_14 len 1), queued 1.46 secs ago, sent 0.01 secs ago,
response: id 1, fc 132, error code 02, len 1
2022.05.23 16:58:26.253 5: SH10rt_1: ResetExpect for HandleResponse from response to idle
2022.05.23 16:58:26.254 5: SH10rt_1: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2022.05.23 16:58:26.256 5: SH10rt_1: DropFrame called from ReadFn - drop 00d800000002018402


Wenn ich das richtig lesen ist das Problem "error code 84 / 02, illegal data address", was auch immer das bedeutet, da ja laut Modbus-Protokolldefinition des SH10RT (https://www.photovoltaikforum.com/core/attachment/235914-ti-20211231-communication-protocol-of-residential-hybrid-inverter-v1-0-23-en-pdf/ (https://www.photovoltaikforum.com/core/attachment/235914-ti-20211231-communication-protocol-of-residential-hybrid-inverter-v1-0-23-en-pdf/)) die Adresse definiert ist...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Mai 2022, 18:46:50
Manchmal liegt es daran, dass in der Doku die Register nicht bei 0 beginnen sondern bei 1 und man immer 1 abziehen muss.
Manchmal kann man nicht einfach ein einzelnes Register lesen sondern muss mehrere gleichzeitig mit größerer Länge abfragen...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 23 Mai 2022, 19:48:30
danke, jetzt geht der Register auszulesen!

Es lag neben dem fehlendem Poll daran, dass er diese Register nur am zweiten LAN-Anschluß des Wechselrichters ausgibt.

Allerding geht er nun der device immer wieder in den State disconnect mit folgender Meldung:

2022.05.23 19:44:40.626 5: SH10rt_1: open ignored because DevIo has set NEXT_OPEN to 1653327885.44479 / 19:44:45.444 and now is 1653327880.62596 / 19:44:40.625


und

2022.05.23 19:46:38.558 4: SH10rt_1: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i6581, len 1, tid 180, master device SH10rt_1, reading Daily_Export_Energy_PV_17 (getUpdate for Daily_Export_Energy_PV_17 len 1)
2022.05.23 19:46:38.558 5: SH10rt_1: QueueRequest called from DoRequest with i6581, qlen 101 from master SH10rt_1 through io device SH10rt_1
2022.05.23 19:46:38.559 3: SH10rt_1: QueueRequest queue too long (101), dropping new request


Wie kommt es dazu?

Bedeutet "QueueRequest queue too long", dass es doch zu viele Register sind?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Mai 2022, 21:04:37
Hallo,

der Disconnect kommt entweder von Deiner Konfiguration (vielleicht solltest Du die doch mal posten) oder von Deinem Modbus Slave, der nach einem Timeout die Verbindung kappt. Ist nicht weiter tragisch, das Modul baut die Verbindung ja wieder auf.
Wenn der Log-Eintrag stört, kann man das mit silentReconnect lösen.

Der NextOpenDelay sorgt dafür, dass nach einem Open nicht gleich wieder einer kommt. Man kann das mit dem Attribut nextOpenDelay einstellen.

Wenn die Request-Queue überläuft, dann kommt das Modul entweder nicht so schnell zum Abarbeiten der Queue wie neue Requests eingestellt werden oder die Queue ist für die Anzahl der einzelnen Requests zu kurz. Dann kann man sie mit dem Attribut queueMax vergrößern.
Das solle jedoch nicht nötig sein wenn die Requests sinnvoll kombiniert werden. Siehe Attribut dev-([cdih]-)*combine.
Ich würde in Deinem Fall testweise mal dev-i-combine auf 16 setzen. Je größer umso effektiver (meistens), allerdings hat jeder Slave auch irgendwo sein individuelles Maximum. Das muss man austesten.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 23 Mai 2022, 21:09:10
Vielen Dank. Ja, "dev-i-combine 32" hatte ich getestet, aber das hat leider nicht geholfen. Die Verbindung ist immer wieder auf disconnect gegangen. Leider bisher keinen Erfolg.

Anbei ist die Konfiguration:


defmod SH10rt_1 ModbusAttr 1 30 192.168.x.x:502 TCP
attr SH10rt_1 dev-i-defPoll 1
attr SH10rt_1 closeAfterResponse 0
attr SH10rt_1 dev-type-S16-len 1
attr SH10rt_1 dev-type-S16-unpack s>
attr SH10rt_1 dev-type-S32-len 2
attr SH10rt_1 dev-type-S32-revRegs 1
attr SH10rt_1 dev-type-S32-unpack l>
attr SH10rt_1 dev-type-SL_R2-len 2
attr SH10rt_1 dev-type-SL_R2-unpack l
attr SH10rt_1 dev-type-U16-len 1
attr SH10rt_1 dev-type-U16-revRegs 0
attr SH10rt_1 dev-type-U16-unpack S>
attr SH10rt_1 dev-type-U32-len 2
attr SH10rt_1 dev-type-U32-revRegs 1
attr SH10rt_1 dev-type-U32-unpack N
attr SH10rt_1 dev-type-UL_R2-len 2
attr SH10rt_1 dev-type-UL_R2-revRegs 1
attr SH10rt_1 dev-type-UL_R2-unpack N
attr SH10rt_1 disable 0
attr SH10rt_1 event-on-change-reading .*
attr SH10rt_1 icon solar_icon
attr SH10rt_1 obj-i12999-poll 1
attr SH10rt_1 obj-i12999-reading 98_System_State
attr SH10rt_1 obj-i12999-type U16
attr SH10rt_1 obj-i13000-expr $val/10
attr SH10rt_1 obj-i13000-poll 1
attr SH10rt_1 obj-i13000-reading 99_Running_State
attr SH10rt_1 obj-i13000-type U16
attr SH10rt_1 obj-i13001-expr $val/10
attr SH10rt_1 obj-i13001-poll 1
attr SH10rt_1 obj-i13001-polldelay x10
attr SH10rt_1 obj-i13001-reading Daily_PV_Generation
attr SH10rt_1 obj-i13002-expr $val/10
attr SH10rt_1 obj-i13002-poll 1
attr SH10rt_1 obj-i13002-polldelay x199
attr SH10rt_1 obj-i13002-reading Total_PV_Generation
attr SH10rt_1 obj-i13002-type U32
attr SH10rt_1 obj-i13004-expr $val/10
attr SH10rt_1 obj-i13004-poll 1
attr SH10rt_1 obj-i13004-polldelay x10
attr SH10rt_1 obj-i13004-reading Daily_Export_Energy_PV
attr SH10rt_1 obj-i13005-expr $val/10
attr SH10rt_1 obj-i13005-poll 1
attr SH10rt_1 obj-i13005-polldelay x199
attr SH10rt_1 obj-i13005-reading Total_Export_Energy_PV
attr SH10rt_1 obj-i13005-type U32
attr SH10rt_1 obj-i13007-poll 1
attr SH10rt_1 obj-i13007-reading 02_Load_Power
attr SH10rt_1 obj-i13007-type S32
attr SH10rt_1 obj-i13008-poll 5
attr SH10rt_1 obj-i13008-reading Load_Power_1
attr SH10rt_1 obj-i13009-poll 1
attr SH10rt_1 obj-i13009-reading 04_Export_Power
attr SH10rt_1 obj-i13009-type S32
attr SH10rt_1 obj-i13010-poll 5
attr SH10rt_1 obj-i13010-reading Export_Power_1
attr SH10rt_1 obj-i13011-expr $val/10
attr SH10rt_1 obj-i13011-poll 1
attr SH10rt_1 obj-i13011-polldelay x10
attr SH10rt_1 obj-i13011-reading Daily_Battery_Charge_PV
attr SH10rt_1 obj-i13012-expr $val/10
attr SH10rt_1 obj-i13012-poll 1
attr SH10rt_1 obj-i13012-polldelay x199
attr SH10rt_1 obj-i13012-reading Total_Battery_Charge_PV
attr SH10rt_1 obj-i13012-type U32
attr SH10rt_1 obj-i13016-expr $val/10
attr SH10rt_1 obj-i13016-poll 1
attr SH10rt_1 obj-i13016-polldelay x10
attr SH10rt_1 obj-i13016-reading Daily_Direct_Energy_Consumption
attr SH10rt_1 obj-i13016-type S16
attr SH10rt_1 obj-i13017-expr $val/10
attr SH10rt_1 obj-i13017-poll 1
attr SH10rt_1 obj-i13017-polldelay x199
attr SH10rt_1 obj-i13017-reading Total_Direct_Energy_Consumption
attr SH10rt_1 obj-i13017-type U32
attr SH10rt_1 obj-i13019-expr $val/10
attr SH10rt_1 obj-i13019-poll 1
attr SH10rt_1 obj-i13019-reading Battery_Voltage
attr SH10rt_1 obj-i13020-expr $val/10
attr SH10rt_1 obj-i13020-poll 1
attr SH10rt_1 obj-i13020-reading Battery_Current
attr SH10rt_1 obj-i13021-poll 1
attr SH10rt_1 obj-i13021-reading 03_Battery_Power
attr SH10rt_1 obj-i13022-expr $val/10
attr SH10rt_1 obj-i13022-poll 1
attr SH10rt_1 obj-i13022-reading Battery_Level
attr SH10rt_1 obj-i13023-expr $val/10
attr SH10rt_1 obj-i13023-poll 1
attr SH10rt_1 obj-i13023-polldelay x10
attr SH10rt_1 obj-i13023-reading Battery_Health
attr SH10rt_1 obj-i13023-type U16
attr SH10rt_1 obj-i13024-expr $val/10
attr SH10rt_1 obj-i13024-poll 1
attr SH10rt_1 obj-i13024-polldelay x10
attr SH10rt_1 obj-i13024-reading Battery_Temperature
attr SH10rt_1 obj-i13024-type S16
attr SH10rt_1 obj-i13025-expr $val/10
attr SH10rt_1 obj-i13025-poll 1
attr SH10rt_1 obj-i13025-polldelay x10
attr SH10rt_1 obj-i13025-reading Daily_Battery_Discharge_PV
attr SH10rt_1 obj-i13026-expr $val/10
attr SH10rt_1 obj-i13026-poll 1
attr SH10rt_1 obj-i13026-polldelay x199
attr SH10rt_1 obj-i13026-reading Total_Battery_Discharge_PV
attr SH10rt_1 obj-i13026-type U32
attr SH10rt_1 obj-i13028-expr $val/10
attr SH10rt_1 obj-i13028-poll 1
attr SH10rt_1 obj-i13028-polldelay x10
attr SH10rt_1 obj-i13028-reading Daily_Self-Consumption_Perc
attr SH10rt_1 obj-i13028-type U16
attr SH10rt_1 obj-i13029-poll 1
attr SH10rt_1 obj-i13029-polldelay x10
attr SH10rt_1 obj-i13029-reading Grid_State
attr SH10rt_1 obj-i13029-type U16
attr SH10rt_1 obj-i13033-expr $val/10
attr SH10rt_1 obj-i13033-poll 1
attr SH10rt_1 obj-i13033-polldelay x10
attr SH10rt_1 obj-i13033-reading Total_Active_Power
attr SH10rt_1 obj-i13033-type S32
attr SH10rt_1 obj-i13035-expr $val/10
attr SH10rt_1 obj-i13035-poll 1
attr SH10rt_1 obj-i13035-polldelay x10
attr SH10rt_1 obj-i13035-reading Daily_Import_Energy
attr SH10rt_1 obj-i13036-expr $val/10
attr SH10rt_1 obj-i13036-poll 1
attr SH10rt_1 obj-i13036-polldelay x199
attr SH10rt_1 obj-i13036-reading Total_Import_Energy
attr SH10rt_1 obj-i13036-type U32
attr SH10rt_1 obj-i13039-expr $val/10
attr SH10rt_1 obj-i13039-poll 1
attr SH10rt_1 obj-i13039-polldelay x10
attr SH10rt_1 obj-i13039-reading Daily_Charge_Energy
attr SH10rt_1 obj-i13040-expr $val/10
attr SH10rt_1 obj-i13040-poll 1
attr SH10rt_1 obj-i13040-polldelay x199
attr SH10rt_1 obj-i13040-reading Total_Charge_Energy
attr SH10rt_1 obj-i13040-type U32
attr SH10rt_1 obj-i13044-expr $val/10
attr SH10rt_1 obj-i13044-poll 1
attr SH10rt_1 obj-i13044-polldelay x10
attr SH10rt_1 obj-i13044-reading Daily_Export_Energy
attr SH10rt_1 obj-i13045-expr $val/10
attr SH10rt_1 obj-i13045-poll 1
attr SH10rt_1 obj-i13045-polldelay x199
attr SH10rt_1 obj-i13045-reading Total_Export_Energy
attr SH10rt_1 obj-i13045-type U32
attr SH10rt_1 obj-i13049-poll 1
attr SH10rt_1 obj-i13049-polldelay x10
attr SH10rt_1 obj-i13049-reading Inverter_Alarm
attr SH10rt_1 obj-i13049-type U32
attr SH10rt_1 obj-i13051-poll 1
attr SH10rt_1 obj-i13051-polldelay x10
attr SH10rt_1 obj-i13051-reading Grid-side_fault
attr SH10rt_1 obj-i13051-type U32
attr SH10rt_1 obj-i13053-poll 1
attr SH10rt_1 obj-i13053-polldelay x10
attr SH10rt_1 obj-i13053-reading System_fault_1
attr SH10rt_1 obj-i13053-type U32
attr SH10rt_1 obj-i13055-poll 1
attr SH10rt_1 obj-i13055-polldelay x10
attr SH10rt_1 obj-i13055-reading System_fault_2
attr SH10rt_1 obj-i13055-type U32
attr SH10rt_1 obj-i13057-poll 1
attr SH10rt_1 obj-i13057-polldelay x10
attr SH10rt_1 obj-i13057-reading DC-side_fault
attr SH10rt_1 obj-i13057-type U32
attr SH10rt_1 obj-i13059-poll 1
attr SH10rt_1 obj-i13059-polldelay x10
attr SH10rt_1 obj-i13059-reading Permanent_fault
attr SH10rt_1 obj-i13059-type U32
attr SH10rt_1 obj-i13061-poll 1
attr SH10rt_1 obj-i13061-polldelay x10
attr SH10rt_1 obj-i13061-reading BDC-side_fault
attr SH10rt_1 obj-i13061-type U32
attr SH10rt_1 obj-i13063-poll 1
attr SH10rt_1 obj-i13063-polldelay x10
attr SH10rt_1 obj-i13063-reading BDC-side_permanent_fault
attr SH10rt_1 obj-i13063-type U32
attr SH10rt_1 obj-i13065-poll 1
attr SH10rt_1 obj-i13065-polldelay x10
attr SH10rt_1 obj-i13065-reading Battery_fault
attr SH10rt_1 obj-i13065-type U32
attr SH10rt_1 obj-i13067-poll 1
attr SH10rt_1 obj-i13067-polldelay x10
attr SH10rt_1 obj-i13067-reading Battery_alarm
attr SH10rt_1 obj-i13067-type U32
attr SH10rt_1 obj-i13069-poll 1
attr SH10rt_1 obj-i13069-polldelay x10
attr SH10rt_1 obj-i13069-reading BMS_alarm
attr SH10rt_1 obj-i13069-type U32
attr SH10rt_1 obj-i13071-poll 1
attr SH10rt_1 obj-i13071-polldelay x10
attr SH10rt_1 obj-i13071-reading BMS_protection
attr SH10rt_1 obj-i13071-type U32
attr SH10rt_1 obj-i13073-polldelay x10
attr SH10rt_1 obj-i13073-reading BMS_fault_1
attr SH10rt_1 obj-i13073-type U32
attr SH10rt_1 obj-i13075-polldelay x10
attr SH10rt_1 obj-i13075-reading BMS_fault_2
attr SH10rt_1 obj-i13075-type U32
attr SH10rt_1 obj-i13077-polldelay x10
attr SH10rt_1 obj-i13077-reading BMS_alarm_2
attr SH10rt_1 obj-i13077-type U32
attr SH10rt_1 obj-i5002-expr $val/10
attr SH10rt_1 obj-i5002-poll 1
attr SH10rt_1 obj-i5002-polldelay x10
attr SH10rt_1 obj-i5002-reading Daily_Output_PV_AKKU
attr SH10rt_1 obj-i5003-expr $val/10
attr SH10rt_1 obj-i5003-poll 1
attr SH10rt_1 obj-i5003-polldelay x199
attr SH10rt_1 obj-i5003-reading Total_Output_PV_AKKU
attr SH10rt_1 obj-i5003-type U32
attr SH10rt_1 obj-i5007-expr $val/10
attr SH10rt_1 obj-i5007-poll 1
attr SH10rt_1 obj-i5007-polldelay x10
attr SH10rt_1 obj-i5007-reading Inside_Temperature
attr SH10rt_1 obj-i5007-type S16
attr SH10rt_1 obj-i5010-expr $val/10
attr SH10rt_1 obj-i5010-poll 1
attr SH10rt_1 obj-i5010-reading MPPT_1_Voltage
attr SH10rt_1 obj-i5011-expr $val/10
attr SH10rt_1 obj-i5011-poll 1
attr SH10rt_1 obj-i5011-reading MPPT_1_Current
attr SH10rt_1 obj-i5012-expr $val/10
attr SH10rt_1 obj-i5012-poll 1
attr SH10rt_1 obj-i5012-reading MPPT_2_Voltage
attr SH10rt_1 obj-i5013-expr $val/10
attr SH10rt_1 obj-i5013-poll 1
attr SH10rt_1 obj-i5013-reading MPPT_2_Current
attr SH10rt_1 obj-i5016-poll 1
attr SH10rt_1 obj-i5016-reading 01_Total_DC_Power
attr SH10rt_1 obj-i5016-type U32
attr SH10rt_1 obj-i5035-expr $val/10
attr SH10rt_1 obj-i5035-poll 1
attr SH10rt_1 obj-i5035-polldelay x10
attr SH10rt_1 obj-i5035-reading Grid_Frequency
attr SH10rt_1 obj-i5035-type U16
attr SH10rt_1 obj-i6196-expr $val/10
attr SH10rt_1 obj-i6196-polldelay x1000
attr SH10rt_1 obj-i6196-reading Daily_PV_Energy_Yields_1
attr SH10rt_1 obj-i6196-type U16
attr SH10rt_1 obj-i6197-expr $val/10
attr SH10rt_1 obj-i6197-polldelay x1000
attr SH10rt_1 obj-i6197-reading Daily_PV_Energy_Yields_2
attr SH10rt_1 obj-i6197-type U16
attr SH10rt_1 obj-i6198-expr $val/10
attr SH10rt_1 obj-i6198-polldelay x1000
attr SH10rt_1 obj-i6198-reading Daily_PV_Energy_Yields_3
attr SH10rt_1 obj-i6198-type U16
attr SH10rt_1 obj-i6199-expr $val/10
attr SH10rt_1 obj-i6199-polldelay x1000
attr SH10rt_1 obj-i6199-reading Daily_PV_Energy_Yields_4
attr SH10rt_1 obj-i6199-type U16
attr SH10rt_1 obj-i6200-expr $val/10
attr SH10rt_1 obj-i6200-polldelay x1000
attr SH10rt_1 obj-i6200-reading Daily_PV_Energy_Yields_5
attr SH10rt_1 obj-i6200-type U16
attr SH10rt_1 obj-i6201-expr $val/10
attr SH10rt_1 obj-i6201-polldelay x1000
attr SH10rt_1 obj-i6201-reading Daily_PV_Energy_Yields_6
attr SH10rt_1 obj-i6201-type U16
attr SH10rt_1 obj-i6202-expr $val/10
attr SH10rt_1 obj-i6202-polldelay x1000
attr SH10rt_1 obj-i6202-reading Daily_PV_Energy_Yields_7
attr SH10rt_1 obj-i6202-type U16
attr SH10rt_1 obj-i6203-expr $val/10
attr SH10rt_1 obj-i6203-polldelay x1000
attr SH10rt_1 obj-i6203-reading Daily_PV_Energy_Yields_8
attr SH10rt_1 obj-i6203-type U16
attr SH10rt_1 obj-i6204-expr $val/10
attr SH10rt_1 obj-i6204-polldelay x1000
attr SH10rt_1 obj-i6204-reading Daily_PV_Energy_Yields_9
attr SH10rt_1 obj-i6204-type U16
attr SH10rt_1 obj-i6205-expr $val/10
attr SH10rt_1 obj-i6205-polldelay x1000
attr SH10rt_1 obj-i6205-reading Daily_PV_Energy_Yields_10
attr SH10rt_1 obj-i6205-type U16
attr SH10rt_1 obj-i6206-expr $val/10
attr SH10rt_1 obj-i6206-polldelay x1000
attr SH10rt_1 obj-i6206-reading Daily_PV_Energy_Yields_11
attr SH10rt_1 obj-i6206-type U16
attr SH10rt_1 obj-i6207-expr $val/10
attr SH10rt_1 obj-i6207-polldelay x1000
attr SH10rt_1 obj-i6207-reading Daily_PV_Energy_Yields_12
attr SH10rt_1 obj-i6207-type U16
attr SH10rt_1 obj-i6208-expr $val/10
attr SH10rt_1 obj-i6208-polldelay x1000
attr SH10rt_1 obj-i6208-reading Daily_PV_Energy_Yields_13
attr SH10rt_1 obj-i6208-type U16
attr SH10rt_1 obj-i6209-expr $val/10
attr SH10rt_1 obj-i6209-polldelay x1000
attr SH10rt_1 obj-i6209-reading Daily_PV_Energy_Yields_14
attr SH10rt_1 obj-i6209-type U16
attr SH10rt_1 obj-i6210-expr $val/10
attr SH10rt_1 obj-i6210-polldelay x1000
attr SH10rt_1 obj-i6210-reading Daily_PV_Energy_Yields_15
attr SH10rt_1 obj-i6210-type U16
attr SH10rt_1 obj-i6211-expr $val/10
attr SH10rt_1 obj-i6211-polldelay x1000
attr SH10rt_1 obj-i6211-reading Daily_PV_Energy_Yields_16
attr SH10rt_1 obj-i6211-type U16
attr SH10rt_1 obj-i6212-expr $val/10
attr SH10rt_1 obj-i6212-polldelay x1000
attr SH10rt_1 obj-i6212-reading Daily_PV_Energy_Yields_17
attr SH10rt_1 obj-i6212-type U16
attr SH10rt_1 obj-i6213-expr $val/10
attr SH10rt_1 obj-i6213-polldelay x1000
attr SH10rt_1 obj-i6213-reading Daily_PV_Energy_Yields_18
attr SH10rt_1 obj-i6213-type U16
attr SH10rt_1 obj-i6214-expr $val/10
attr SH10rt_1 obj-i6214-polldelay x1000
attr SH10rt_1 obj-i6214-reading Daily_PV_Energy_Yields_19
attr SH10rt_1 obj-i6214-type U16
attr SH10rt_1 obj-i6215-expr $val/10
attr SH10rt_1 obj-i6215-polldelay x1000
attr SH10rt_1 obj-i6215-reading Daily_PV_Energy_Yields_20
attr SH10rt_1 obj-i6215-type U16
attr SH10rt_1 obj-i6216-expr $val/10
attr SH10rt_1 obj-i6216-polldelay x1000
attr SH10rt_1 obj-i6216-reading Daily_PV_Energy_Yields_21
attr SH10rt_1 obj-i6216-type U16
attr SH10rt_1 obj-i6217-expr $val/10
attr SH10rt_1 obj-i6217-polldelay x1000
attr SH10rt_1 obj-i6217-reading Daily_PV_Energy_Yields_22
attr SH10rt_1 obj-i6217-type U16
attr SH10rt_1 obj-i6218-expr $val/10
attr SH10rt_1 obj-i6218-polldelay x1000
attr SH10rt_1 obj-i6218-reading Daily_PV_Energy_Yields_23
attr SH10rt_1 obj-i6218-type U16
attr SH10rt_1 obj-i6219-expr $val/10
attr SH10rt_1 obj-i6219-polldelay x1000
attr SH10rt_1 obj-i6219-reading Daily_PV_Energy_Yields_24
attr SH10rt_1 obj-i6219-type U16
attr SH10rt_1 obj-i6220-expr $val/10
attr SH10rt_1 obj-i6220-polldelay x1000
attr SH10rt_1 obj-i6220-reading Daily_PV_Energy_Yields_25
attr SH10rt_1 obj-i6220-type U16
attr SH10rt_1 obj-i6221-expr $val/10
attr SH10rt_1 obj-i6221-polldelay x1000
attr SH10rt_1 obj-i6221-reading Daily_PV_Energy_Yields_26
attr SH10rt_1 obj-i6221-type U16
attr SH10rt_1 obj-i6222-expr $val/10
attr SH10rt_1 obj-i6222-polldelay x1000
attr SH10rt_1 obj-i6222-reading Daily_PV_Energy_Yields_27
attr SH10rt_1 obj-i6222-type U16
attr SH10rt_1 obj-i6223-expr $val/10
attr SH10rt_1 obj-i6223-polldelay x1000
attr SH10rt_1 obj-i6223-reading Daily_PV_Energy_Yields_28
attr SH10rt_1 obj-i6223-type U16
attr SH10rt_1 obj-i6224-expr $val/10
attr SH10rt_1 obj-i6224-polldelay x1000
attr SH10rt_1 obj-i6224-reading Daily_PV_Energy_Yields_29
attr SH10rt_1 obj-i6224-type U16
attr SH10rt_1 obj-i6225-expr $val/10
attr SH10rt_1 obj-i6225-polldelay x1000
attr SH10rt_1 obj-i6225-reading Daily_PV_Energy_Yields_30
attr SH10rt_1 obj-i6225-type U16
attr SH10rt_1 obj-i6226-expr $val/10
attr SH10rt_1 obj-i6226-polldelay x1000
attr SH10rt_1 obj-i6226-reading Daily_PV_Energy_Yields_31
attr SH10rt_1 obj-i6226-type U16
attr SH10rt_1 obj-i6250-expr $val/10
attr SH10rt_1 obj-i6250-polldelay x1000
attr SH10rt_1 obj-i6250-reading Yearly_PV_Energy_Yields_1
attr SH10rt_1 obj-i6250-type U32
attr SH10rt_1 obj-i6252-expr $val/10
attr SH10rt_1 obj-i6252-polldelay x1000
attr SH10rt_1 obj-i6252-reading Yearly_PV_Energy_Yields_2
attr SH10rt_1 obj-i6252-type U32
attr SH10rt_1 obj-i6254-expr $val/10
attr SH10rt_1 obj-i6254-polldelay x1000
attr SH10rt_1 obj-i6254-reading Yearly_PV_Energy_Yields_3
attr SH10rt_1 obj-i6254-type U32
attr SH10rt_1 obj-i6256-expr $val/10
attr SH10rt_1 obj-i6256-polldelay x1000
attr SH10rt_1 obj-i6256-reading Yearly_PV_Energy_Yields_4
attr SH10rt_1 obj-i6256-type U32
attr SH10rt_1 obj-i6258-expr $val/10
attr SH10rt_1 obj-i6258-polldelay x1000
attr SH10rt_1 obj-i6258-reading Yearly_PV_Energy_Yields_5
attr SH10rt_1 obj-i6258-type U32
attr SH10rt_1 obj-i6260-expr $val/10
attr SH10rt_1 obj-i6260-polldelay x1000
attr SH10rt_1 obj-i6260-reading Yearly_PV_Energy_Yields_6
attr SH10rt_1 obj-i6260-type U32
attr SH10rt_1 obj-i6262-expr $val/10
attr SH10rt_1 obj-i6262-polldelay x1000
attr SH10rt_1 obj-i6262-reading Yearly_PV_Energy_Yields_7
attr SH10rt_1 obj-i6262-type U32
attr SH10rt_1 obj-i6264-expr $val/10
attr SH10rt_1 obj-i6264-polldelay x1000
attr SH10rt_1 obj-i6264-reading Yearly_PV_Energy_Yields_8
attr SH10rt_1 obj-i6264-type U32
attr SH10rt_1 obj-i6266-expr $val/10
attr SH10rt_1 obj-i6266-polldelay x1000
attr SH10rt_1 obj-i6266-reading Yearly_PV_Energy_Yields_9
attr SH10rt_1 obj-i6266-type U32
attr SH10rt_1 obj-i6268-expr $val/10
attr SH10rt_1 obj-i6268-polldelay x1000
attr SH10rt_1 obj-i6268-reading Yearly_PV_Energy_Yields_10
attr SH10rt_1 obj-i6268-type U32
attr SH10rt_1 obj-i6270-expr $val/10
attr SH10rt_1 obj-i6270-polldelay x1000
attr SH10rt_1 obj-i6270-reading Yearly_PV_Energy_Yields_11
attr SH10rt_1 obj-i6270-type U32
attr SH10rt_1 obj-i6272-expr $val/10
attr SH10rt_1 obj-i6272-polldelay x1000
attr SH10rt_1 obj-i6272-reading Yearly_PV_Energy_Yields_12
attr SH10rt_1 obj-i6272-type U32
attr SH10rt_1 obj-i6274-expr $val/10
attr SH10rt_1 obj-i6274-polldelay x1000
attr SH10rt_1 obj-i6274-reading Yearly_PV_Energy_Yields_13
attr SH10rt_1 obj-i6274-type U32
attr SH10rt_1 obj-i6276-expr $val/10
attr SH10rt_1 obj-i6276-polldelay x1000
attr SH10rt_1 obj-i6276-reading Yearly_PV_Energy_Yields_14
attr SH10rt_1 obj-i6276-type U32
attr SH10rt_1 obj-i6278-expr $val/10
attr SH10rt_1 obj-i6278-polldelay x1000
attr SH10rt_1 obj-i6278-reading Yearly_PV_Energy_Yields_15
attr SH10rt_1 obj-i6278-type U32
attr SH10rt_1 obj-i6280-expr $val/10
attr SH10rt_1 obj-i6280-polldelay x1000
attr SH10rt_1 obj-i6280-reading Yearly_PV_Energy_Yields_16
attr SH10rt_1 obj-i6280-type U32
attr SH10rt_1 obj-i6282-expr $val/10
attr SH10rt_1 obj-i6282-polldelay x1000
attr SH10rt_1 obj-i6282-reading Yearly_PV_Energy_Yields_17
attr SH10rt_1 obj-i6282-type U32
attr SH10rt_1 obj-i6284-expr $val/10
attr SH10rt_1 obj-i6284-polldelay x1000
attr SH10rt_1 obj-i6284-reading Yearly_PV_Energy_Yields_18
attr SH10rt_1 obj-i6284-type U32
attr SH10rt_1 obj-i6286-expr $val/10
attr SH10rt_1 obj-i6286-polldelay x1000
attr SH10rt_1 obj-i6286-reading Yearly_PV_Energy_Yields_19
attr SH10rt_1 obj-i6286-type U32
attr SH10rt_1 obj-i6288-expr $val/10
attr SH10rt_1 obj-i6288-polldelay x1000
attr SH10rt_1 obj-i6288-reading Yearly_PV_Energy_Yields_20
attr SH10rt_1 obj-i6288-type U32
attr SH10rt_1 obj-i6386-expr $val/10
attr SH10rt_1 obj-i6386-polldelay x1000
attr SH10rt_1 obj-i6386-reading Daily_Direct_Energy_Consumption_PV_1
attr SH10rt_1 obj-i6387-expr $val/10
attr SH10rt_1 obj-i6387-polldelay x1000
attr SH10rt_1 obj-i6387-reading Daily_Direct_Energy_Consumption_PV_2
attr SH10rt_1 obj-i6387-type U16
attr SH10rt_1 obj-i6388-expr $val/10
attr SH10rt_1 obj-i6388-polldelay x1000
attr SH10rt_1 obj-i6388-reading Daily_Direct_Energy_Consumption_PV_3
attr SH10rt_1 obj-i6388-type U16
attr SH10rt_1 obj-i6389-expr $val/10
attr SH10rt_1 obj-i6389-polldelay x2
attr SH10rt_1 obj-i6389-reading Daily_Direct_Energy_Consumption_PV_4
attr SH10rt_1 obj-i6390-expr $val/10
attr SH10rt_1 obj-i6390-polldelay x1000
attr SH10rt_1 obj-i6390-reading Daily_Direct_Energy_Consumption_PV_5
attr SH10rt_1 obj-i6390-type U16
attr SH10rt_1 obj-i6391-expr $val/10
attr SH10rt_1 obj-i6391-polldelay x1000
attr SH10rt_1 obj-i6391-reading Daily_Direct_Energy_Consumption_PV_6
attr SH10rt_1 obj-i6391-type U16
attr SH10rt_1 obj-i6392-expr $val/10
attr SH10rt_1 obj-i6392-polldelay x1000
attr SH10rt_1 obj-i6392-reading Daily_Direct_Energy_Consumption_PV_7
attr SH10rt_1 obj-i6392-type U16
attr SH10rt_1 obj-i6393-expr $val/10
attr SH10rt_1 obj-i6393-polldelay x1000
attr SH10rt_1 obj-i6393-reading Daily_Direct_Energy_Consumption_PV_8
attr SH10rt_1 obj-i6393-type U16
attr SH10rt_1 obj-i6394-expr $val/10
attr SH10rt_1 obj-i6394-polldelay x1000
attr SH10rt_1 obj-i6394-reading Daily_Direct_Energy_Consumption_PV_9
attr SH10rt_1 obj-i6394-type U16
attr SH10rt_1 obj-i6395-expr $val/10
attr SH10rt_1 obj-i6395-polldelay x1000
attr SH10rt_1 obj-i6395-reading Daily_Direct_Energy_Consumption_PV_10
attr SH10rt_1 obj-i6395-type U16
attr SH10rt_1 obj-i6396-expr $val/10
attr SH10rt_1 obj-i6396-polldelay x1000
attr SH10rt_1 obj-i6396-reading Daily_Direct_Energy_Consumption_PV_11
attr SH10rt_1 obj-i6396-type U16
attr SH10rt_1 obj-i6397-expr $val/10
attr SH10rt_1 obj-i6397-polldelay x1000
attr SH10rt_1 obj-i6397-reading Daily_Direct_Energy_Consumption_PV_12
attr SH10rt_1 obj-i6397-type U16
attr SH10rt_1 obj-i6398-expr $val/10
attr SH10rt_1 obj-i6398-polldelay x1000
attr SH10rt_1 obj-i6398-reading Daily_Direct_Energy_Consumption_PV_13
attr SH10rt_1 obj-i6398-type U16
attr SH10rt_1 obj-i6399-expr $val/10
attr SH10rt_1 obj-i6399-polldelay x1000
attr SH10rt_1 obj-i6399-reading Daily_Direct_Energy_Consumption_PV_14
attr SH10rt_1 obj-i6399-type U16
attr SH10rt_1 obj-i6400-expr $val/10
attr SH10rt_1 obj-i6400-polldelay x1000
attr SH10rt_1 obj-i6400-reading Daily_Direct_Energy_Consumption_PV_15
attr SH10rt_1 obj-i6400-type U16
attr SH10rt_1 obj-i6401-expr $val/10
attr SH10rt_1 obj-i6401-polldelay x1000
attr SH10rt_1 obj-i6401-reading Daily_Direct_Energy_Consumption_PV_16
attr SH10rt_1 obj-i6401-type U16
attr SH10rt_1 obj-i6402-expr $val/10
attr SH10rt_1 obj-i6402-polldelay x1000
attr SH10rt_1 obj-i6402-reading Daily_Direct_Energy_Consumption_PV_17
attr SH10rt_1 obj-i6402-type U16
attr SH10rt_1 obj-i6403-expr $val/10
attr SH10rt_1 obj-i6403-polldelay x1000
attr SH10rt_1 obj-i6403-reading Daily_Direct_Energy_Consumption_PV_18
attr SH10rt_1 obj-i6403-type U16
attr SH10rt_1 obj-i6404-expr $val/10
attr SH10rt_1 obj-i6404-polldelay x1000
attr SH10rt_1 obj-i6404-reading Daily_Direct_Energy_Consumption_PV_19
attr SH10rt_1 obj-i6404-type U16
attr SH10rt_1 obj-i6405-expr $val/10
attr SH10rt_1 obj-i6405-polldelay x1000
attr SH10rt_1 obj-i6405-reading Daily_Direct_Energy_Consumption_PV_20
attr SH10rt_1 obj-i6405-type U16
attr SH10rt_1 obj-i6406-expr $val/10
attr SH10rt_1 obj-i6406-polldelay x1000
attr SH10rt_1 obj-i6406-reading Daily_Direct_Energy_Consumption_PV_21
attr SH10rt_1 obj-i6406-type U16
attr SH10rt_1 obj-i6407-expr $val/10
attr SH10rt_1 obj-i6407-polldelay x1000
attr SH10rt_1 obj-i6407-reading Daily_Direct_Energy_Consumption_PV_22
attr SH10rt_1 obj-i6407-type U16
attr SH10rt_1 obj-i6408-expr $val/10
attr SH10rt_1 obj-i6408-polldelay x1000
attr SH10rt_1 obj-i6408-reading Daily_Direct_Energy_Consumption_PV_23
attr SH10rt_1 obj-i6408-type U16
attr SH10rt_1 obj-i6409-expr $val/10
attr SH10rt_1 obj-i6409-polldelay x1000
attr SH10rt_1 obj-i6409-reading Daily_Direct_Energy_Consumption_PV_24
attr SH10rt_1 obj-i6409-type U16
attr SH10rt_1 obj-i6410-expr $val/10
attr SH10rt_1 obj-i6410-polldelay x1000
attr SH10rt_1 obj-i6410-reading Daily_Direct_Energy_Consumption_PV_25
attr SH10rt_1 obj-i6410-type U16
attr SH10rt_1 obj-i6411-expr $val/10
attr SH10rt_1 obj-i6411-polldelay x1000
attr SH10rt_1 obj-i6411-reading Daily_Direct_Energy_Consumption_PV_26
attr SH10rt_1 obj-i6411-type U16
attr SH10rt_1 obj-i6412-expr $val/10
attr SH10rt_1 obj-i6412-polldelay x1000
attr SH10rt_1 obj-i6412-reading Daily_Direct_Energy_Consumption_PV_27
attr SH10rt_1 obj-i6412-type U16
attr SH10rt_1 obj-i6413-expr $val/10
attr SH10rt_1 obj-i6413-polldelay x1000
attr SH10rt_1 obj-i6413-reading Daily_Direct_Energy_Consumption_PV_28
attr SH10rt_1 obj-i6413-type U16
attr SH10rt_1 obj-i6414-expr $val/10
attr SH10rt_1 obj-i6414-polldelay x1000
attr SH10rt_1 obj-i6414-reading Daily_Direct_Energy_Consumption_PV_29
attr SH10rt_1 obj-i6414-type U16
attr SH10rt_1 obj-i6415-expr $val/10
attr SH10rt_1 obj-i6415-polldelay x1000
attr SH10rt_1 obj-i6415-reading Daily_Direct_Energy_Consumption_PV_30
attr SH10rt_1 obj-i6415-type U16
attr SH10rt_1 obj-i6416-expr $val/10
attr SH10rt_1 obj-i6416-polldelay x1000
attr SH10rt_1 obj-i6416-reading Daily_Direct_Energy_Consumption_PV_31
attr SH10rt_1 obj-i6416-type U16
attr SH10rt_1 obj-i6417-expr $val/10
attr SH10rt_1 obj-i6417-polldelay x1000
attr SH10rt_1 obj-i6417-reading Monthly_Direct_Energy_Consumption_PV_Feb
attr SH10rt_1 obj-i6417-type U16
attr SH10rt_1 obj-i6418-expr $val/10
attr SH10rt_1 obj-i6418-polldelay x1000
attr SH10rt_1 obj-i6418-reading Monthly_Direct_Energy_Consumption_PV_Mar
attr SH10rt_1 obj-i6418-type U16
attr SH10rt_1 obj-i6419-expr $val/10
attr SH10rt_1 obj-i6419-polldelay x1000
attr SH10rt_1 obj-i6419-reading Monthly_Direct_Energy_Consumption_PV_Apr
attr SH10rt_1 obj-i6419-type U16
attr SH10rt_1 obj-i6420-expr $val/10
attr SH10rt_1 obj-i6420-polldelay x1000
attr SH10rt_1 obj-i6420-reading Monthly_Direct_Energy_Consumption_PV_May
attr SH10rt_1 obj-i6420-type U16
attr SH10rt_1 obj-i6421-expr $val/10
attr SH10rt_1 obj-i6421-polldelay x1000
attr SH10rt_1 obj-i6421-reading Monthly_Direct_Energy_Consumption_PV_Jun
attr SH10rt_1 obj-i6421-type U16
attr SH10rt_1 obj-i6422-expr $val/10
attr SH10rt_1 obj-i6422-polldelay x1000
attr SH10rt_1 obj-i6422-reading Monthly_Direct_Energy_Consumption_PV_Jul
attr SH10rt_1 obj-i6422-type U16
attr SH10rt_1 obj-i6423-expr $val/10
attr SH10rt_1 obj-i6423-polldelay x1000
attr SH10rt_1 obj-i6423-reading Monthly_Direct_Energy_Consumption_PV_Aug
attr SH10rt_1 obj-i6423-type U16
attr SH10rt_1 obj-i6424-expr $val/10
attr SH10rt_1 obj-i6424-polldelay x1000
attr SH10rt_1 obj-i6424-reading Monthly_Direct_Energy_Consumption_PV_Sep
attr SH10rt_1 obj-i6424-type U16
attr SH10rt_1 obj-i6425-expr $val/10
attr SH10rt_1 obj-i6425-polldelay x1000
attr SH10rt_1 obj-i6425-reading Monthly_Direct_Energy_Consumption_PV_Oct
attr SH10rt_1 obj-i6425-type U16
attr SH10rt_1 obj-i6426-expr $val/10
attr SH10rt_1 obj-i6426-polldelay x1000
attr SH10rt_1 obj-i6426-reading Monthly_Direct_Energy_Consumption_PV_Nov
attr SH10rt_1 obj-i6426-type U16
attr SH10rt_1 obj-i6427-expr $val/10
attr SH10rt_1 obj-i6427-polldelay x1000
attr SH10rt_1 obj-i6427-reading Monthly_Direct_Energy_Consumption_PV_Dec
attr SH10rt_1 obj-i6427-type U16
attr SH10rt_1 obj-i6429-expr $val/10
attr SH10rt_1 obj-i6429-polldelay x1000
attr SH10rt_1 obj-i6429-reading Yearly_Direct_Energy_Consumption_PV_1
attr SH10rt_1 obj-i6429-type U32
attr SH10rt_1 obj-i6430-expr $val/10
attr SH10rt_1 obj-i6430-polldelay x1000
attr SH10rt_1 obj-i6430-reading Yearly_Direct_Energy_Consumption_PV_2
attr SH10rt_1 obj-i6430-type U32
attr SH10rt_1 obj-i6431-expr $val/10
attr SH10rt_1 obj-i6431-polldelay x1000
attr SH10rt_1 obj-i6431-reading Yearly_Direct_Energy_Consumption_PV_2
attr SH10rt_1 obj-i6431-type U32
attr SH10rt_1 obj-i6432-expr $val/10
attr SH10rt_1 obj-i6432-polldelay x1000
attr SH10rt_1 obj-i6432-reading Yearly_Direct_Energy_Consumption_PV_4
attr SH10rt_1 obj-i6432-type U32
attr SH10rt_1 obj-i6433-expr $val/10
attr SH10rt_1 obj-i6433-polldelay x1000
attr SH10rt_1 obj-i6433-reading Yearly_Direct_Energy_Consumption_PV_3
attr SH10rt_1 obj-i6433-type U32
attr SH10rt_1 obj-i6434-expr $val/10
attr SH10rt_1 obj-i6434-polldelay x1000
attr SH10rt_1 obj-i6434-reading Yearly_Direct_Energy_Consumption_PV_6
attr SH10rt_1 obj-i6434-type U32
attr SH10rt_1 obj-i6435-expr $val/10
attr SH10rt_1 obj-i6435-polldelay x1000
attr SH10rt_1 obj-i6435-reading Yearly_Direct_Energy_Consumption_PV_4
attr SH10rt_1 obj-i6435-type U32
attr SH10rt_1 obj-i6436-expr $val/10
attr SH10rt_1 obj-i6436-polldelay x1000
attr SH10rt_1 obj-i6436-reading Yearly_Direct_Energy_Consumption_PV_8
attr SH10rt_1 obj-i6436-type U32
attr SH10rt_1 obj-i6437-expr $val/10
attr SH10rt_1 obj-i6437-polldelay x1000
attr SH10rt_1 obj-i6437-reading Yearly_Direct_Energy_Consumption_PV_5
attr SH10rt_1 obj-i6437-type U32
attr SH10rt_1 obj-i6438-expr $val/10
attr SH10rt_1 obj-i6438-polldelay x1000
attr SH10rt_1 obj-i6438-reading Yearly_Direct_Energy_Consumption_PV_10
attr SH10rt_1 obj-i6438-type U32
attr SH10rt_1 obj-i6439-expr $val/10
attr SH10rt_1 obj-i6439-polldelay x1000
attr SH10rt_1 obj-i6439-reading Yearly_Direct_Energy_Consumption_PV_6
attr SH10rt_1 obj-i6439-type U32
attr SH10rt_1 obj-i6440-expr $val/10
attr SH10rt_1 obj-i6440-polldelay x1000
attr SH10rt_1 obj-i6440-reading Yearly_Direct_Energy_Consumption_PV_12
attr SH10rt_1 obj-i6440-type U32
attr SH10rt_1 obj-i6441-expr $val/10
attr SH10rt_1 obj-i6441-polldelay x1000
attr SH10rt_1 obj-i6441-reading Yearly_Direct_Energy_Consumption_PV_7
attr SH10rt_1 obj-i6441-type U32
attr SH10rt_1 obj-i6442-expr $val/10
attr SH10rt_1 obj-i6442-polldelay x1000
attr SH10rt_1 obj-i6442-reading Yearly_Direct_Energy_Consumption_PV_14
attr SH10rt_1 obj-i6442-type U32
attr SH10rt_1 obj-i6443-expr $val/10
attr SH10rt_1 obj-i6443-polldelay x1000
attr SH10rt_1 obj-i6443-reading Yearly_Direct_Energy_Consumption_PV_8
attr SH10rt_1 obj-i6443-type U32
attr SH10rt_1 obj-i6444-expr $val/10
attr SH10rt_1 obj-i6444-polldelay x1000
attr SH10rt_1 obj-i6444-reading Yearly_Direct_Energy_Consumption_PV_16
attr SH10rt_1 obj-i6444-type U32
attr SH10rt_1 obj-i6445-expr $val/10
attr SH10rt_1 obj-i6445-polldelay x1000
attr SH10rt_1 obj-i6445-reading Yearly_Direct_Energy_Consumption_PV_9
attr SH10rt_1 obj-i6445-type U32
attr SH10rt_1 obj-i6446-expr $val/10
attr SH10rt_1 obj-i6446-polldelay x1000
attr SH10rt_1 obj-i6446-reading Yearly_Direct_Energy_Consumption_PV_18
attr SH10rt_1 obj-i6446-type U32
attr SH10rt_1 obj-i6447-expr $val/10
attr SH10rt_1 obj-i6447-polldelay x1000
attr SH10rt_1 obj-i6447-reading Yearly_Direct_Energy_Consumption_PV_10
attr SH10rt_1 obj-i6447-type U32
attr SH10rt_1 obj-i6448-expr $val/10
attr SH10rt_1 obj-i6448-polldelay x1000
attr SH10rt_1 obj-i6448-reading Yearly_Direct_Energy_Consumption_PV_20
attr SH10rt_1 obj-i6448-type U32
attr SH10rt_1 obj-i6449-expr $val/10
attr SH10rt_1 obj-i6449-polldelay x1000
attr SH10rt_1 obj-i6449-reading Yearly_Direct_Energy_Consumption_PV_11
attr SH10rt_1 obj-i6449-type U32
attr SH10rt_1 obj-i6451-expr $val/10
attr SH10rt_1 obj-i6451-polldelay x1000
attr SH10rt_1 obj-i6451-reading Yearly_Direct_Energy_Consumption_PV_12
attr SH10rt_1 obj-i6451-type U32
attr SH10rt_1 obj-i6453-expr $val/10
attr SH10rt_1 obj-i6453-polldelay x1000
attr SH10rt_1 obj-i6453-reading Yearly_Direct_Energy_Consumption_PV_13
attr SH10rt_1 obj-i6453-type U32
attr SH10rt_1 obj-i6455-expr $val/10
attr SH10rt_1 obj-i6455-polldelay x1000
attr SH10rt_1 obj-i6455-reading Yearly_Direct_Energy_Consumption_PV_14
attr SH10rt_1 obj-i6455-type U32
attr SH10rt_1 obj-i6457-expr $val/10
attr SH10rt_1 obj-i6457-polldelay x1000
attr SH10rt_1 obj-i6457-reading Yearly_Direct_Energy_Consumption_PV_15
attr SH10rt_1 obj-i6457-type U32
attr SH10rt_1 obj-i6459-expr $val/10
attr SH10rt_1 obj-i6459-polldelay x1000
attr SH10rt_1 obj-i6459-reading Yearly_Direct_Energy_Consumption_PV_16
attr SH10rt_1 obj-i6459-type U32
attr SH10rt_1 obj-i6461-expr $val/10
attr SH10rt_1 obj-i6461-polldelay x1000
attr SH10rt_1 obj-i6461-reading Yearly_Direct_Energy_Consumption_PV_17
attr SH10rt_1 obj-i6461-type U32
attr SH10rt_1 obj-i6463-expr $val/10
attr SH10rt_1 obj-i6463-polldelay x1000
attr SH10rt_1 obj-i6463-reading Yearly_Direct_Energy_Consumption_PV_18
attr SH10rt_1 obj-i6463-type U32
attr SH10rt_1 obj-i6465-expr $val/10
attr SH10rt_1 obj-i6465-polldelay x1000
attr SH10rt_1 obj-i6465-reading Yearly_Direct_Energy_Consumption_PV_19
attr SH10rt_1 obj-i6465-type U32
attr SH10rt_1 obj-i6467-expr $val/10
attr SH10rt_1 obj-i6467-polldelay x1000
attr SH10rt_1 obj-i6467-reading Yearly_Direct_Energy_Consumption_PV_20
attr SH10rt_1 obj-i6467-type U32
attr SH10rt_1 obj-i6468-poll 5
attr SH10rt_1 obj-i6468-reading Test_1
attr SH10rt_1 obj-i6469-poll 5
attr SH10rt_1 obj-i6469-reading Test_2
attr SH10rt_1 obj-i6565-expr $val/10
attr SH10rt_1 obj-i6565-polldelay x1000
attr SH10rt_1 obj-i6565-reading Daily_Export_Energy_PV_1
attr SH10rt_1 obj-i6565-type U16
attr SH10rt_1 obj-i6566-expr $val/10
attr SH10rt_1 obj-i6566-polldelay x1000
attr SH10rt_1 obj-i6566-reading Daily_Export_Energy_PV_2
attr SH10rt_1 obj-i6566-type U16
attr SH10rt_1 obj-i6567-expr $val/10
attr SH10rt_1 obj-i6567-polldelay x1000
attr SH10rt_1 obj-i6567-reading Daily_Export_Energy_PV_3
attr SH10rt_1 obj-i6567-type U16
attr SH10rt_1 obj-i6568-expr $val/10
attr SH10rt_1 obj-i6568-polldelay x1000
attr SH10rt_1 obj-i6568-reading Daily_Export_Energy_PV_4
attr SH10rt_1 obj-i6568-type U16
attr SH10rt_1 obj-i6569-expr $val/10
attr SH10rt_1 obj-i6569-polldelay x1000
attr SH10rt_1 obj-i6569-reading Daily_Export_Energy_PV_5
attr SH10rt_1 obj-i6569-type U16
attr SH10rt_1 obj-i6570-expr $val/10
attr SH10rt_1 obj-i6570-polldelay x1000
attr SH10rt_1 obj-i6570-reading Daily_Export_Energy_PV_6
attr SH10rt_1 obj-i6570-type U16
attr SH10rt_1 obj-i6571-expr $val/10
attr SH10rt_1 obj-i6571-polldelay x1000
attr SH10rt_1 obj-i6571-reading Daily_Export_Energy_PV_7
attr SH10rt_1 obj-i6571-type U16
attr SH10rt_1 obj-i6572-expr $val/10
attr SH10rt_1 obj-i6572-polldelay x1000
attr SH10rt_1 obj-i6572-reading Daily_Export_Energy_PV_8
attr SH10rt_1 obj-i6572-type U16
attr SH10rt_1 obj-i6573-expr $val/10
attr SH10rt_1 obj-i6573-polldelay x1000
attr SH10rt_1 obj-i6573-reading Daily_Export_Energy_PV_9
attr SH10rt_1 obj-i6573-type U16
attr SH10rt_1 obj-i6574-expr $val/10
attr SH10rt_1 obj-i6574-polldelay x1000
attr SH10rt_1 obj-i6574-reading Daily_Export_Energy_PV_10
attr SH10rt_1 obj-i6574-type U16
attr SH10rt_1 obj-i6575-expr $val/10
attr SH10rt_1 obj-i6575-polldelay x1000
attr SH10rt_1 obj-i6575-reading Daily_Export_Energy_PV_11
attr SH10rt_1 obj-i6575-type U16
attr SH10rt_1 obj-i6576-expr $val/10
attr SH10rt_1 obj-i6576-polldelay x1000
attr SH10rt_1 obj-i6576-reading Daily_Export_Energy_PV_12
attr SH10rt_1 obj-i6576-type U16
attr SH10rt_1 obj-i6577-expr $val/10
attr SH10rt_1 obj-i6577-polldelay x1000
attr SH10rt_1 obj-i6577-reading Daily_Export_Energy_PV_13
attr SH10rt_1 obj-i6577-type U16
attr SH10rt_1 obj-i6578-expr $val/10
attr SH10rt_1 obj-i6578-polldelay x1000
attr SH10rt_1 obj-i6578-reading Daily_Export_Energy_PV_14
attr SH10rt_1 obj-i6578-type U16
attr SH10rt_1 obj-i6579-expr $val/10
attr SH10rt_1 obj-i6579-polldelay x1000
attr SH10rt_1 obj-i6579-reading Daily_Export_Energy_PV_15
attr SH10rt_1 obj-i6579-type U16
attr SH10rt_1 obj-i6580-expr $val/10
attr SH10rt_1 obj-i6580-polldelay x1000
attr SH10rt_1 obj-i6580-reading Daily_Export_Energy_PV_16
attr SH10rt_1 obj-i6580-type U16
attr SH10rt_1 obj-i6581-expr $val/10
attr SH10rt_1 obj-i6581-polldelay x1000
attr SH10rt_1 obj-i6581-reading Daily_Export_Energy_PV_17
attr SH10rt_1 obj-i6581-type U16
attr SH10rt_1 obj-i6582-expr $val/10
attr SH10rt_1 obj-i6582-polldelay x1000
attr SH10rt_1 obj-i6582-reading Daily_Export_Energy_PV_18
attr SH10rt_1 obj-i6582-type U16
attr SH10rt_1 obj-i6583-expr $val/10
attr SH10rt_1 obj-i6583-polldelay x1000
attr SH10rt_1 obj-i6583-reading Daily_Export_Energy_PV_19
attr SH10rt_1 obj-i6583-type U16
attr SH10rt_1 obj-i6584-expr $val/10
attr SH10rt_1 obj-i6584-polldelay x1000
attr SH10rt_1 obj-i6584-reading Daily_Export_Energy_PV_20
attr SH10rt_1 obj-i6584-type U16
attr SH10rt_1 obj-i6585-expr $val/10
attr SH10rt_1 obj-i6585-polldelay x1000
attr SH10rt_1 obj-i6585-reading Daily_Export_Energy_PV_21
attr SH10rt_1 obj-i6585-type U16
attr SH10rt_1 obj-i6586-expr $val/10
attr SH10rt_1 obj-i6586-polldelay x1000
attr SH10rt_1 obj-i6586-reading Daily_Export_Energy_PV_22
attr SH10rt_1 obj-i6586-type U16
attr SH10rt_1 obj-i6587-expr $val/10
attr SH10rt_1 obj-i6587-polldelay x1000
attr SH10rt_1 obj-i6587-reading Daily_Export_Energy_PV_23
attr SH10rt_1 obj-i6587-type U16
attr SH10rt_1 obj-i6588-expr $val/10
attr SH10rt_1 obj-i6588-polldelay x1000
attr SH10rt_1 obj-i6588-reading Daily_Export_Energy_PV_24
attr SH10rt_1 obj-i6588-type U16
attr SH10rt_1 obj-i6589-expr $val/10
attr SH10rt_1 obj-i6589-polldelay x1000
attr SH10rt_1 obj-i6589-reading Daily_Export_Energy_PV_25
attr SH10rt_1 obj-i6589-type U16
attr SH10rt_1 obj-i6590-expr $val/10
attr SH10rt_1 obj-i6590-polldelay x1000
attr SH10rt_1 obj-i6590-reading Daily_Export_Energy_PV_26
attr SH10rt_1 obj-i6590-type U16
attr SH10rt_1 obj-i6591-expr $val/10
attr SH10rt_1 obj-i6591-polldelay x1000
attr SH10rt_1 obj-i6591-reading Daily_Export_Energy_PV_27
attr SH10rt_1 obj-i6591-type U16
attr SH10rt_1 obj-i6592-expr $val/10
attr SH10rt_1 obj-i6592-polldelay x1000
attr SH10rt_1 obj-i6592-reading Daily_Export_Energy_PV_28
attr SH10rt_1 obj-i6592-type U16
attr SH10rt_1 obj-i6593-expr $val/10
attr SH10rt_1 obj-i6593-polldelay x1000
attr SH10rt_1 obj-i6593-reading Daily_Export_Energy_PV_29
attr SH10rt_1 obj-i6593-type U16
attr SH10rt_1 obj-i6594-expr $val/10
attr SH10rt_1 obj-i6594-polldelay x1000
attr SH10rt_1 obj-i6594-reading Daily_Export_Energy_PV_30
attr SH10rt_1 obj-i6594-type U16
attr SH10rt_1 obj-i6595-expr $val/10
attr SH10rt_1 obj-i6595-polldelay x1000
attr SH10rt_1 obj-i6595-reading Daily_Export_Energy_PV_31
attr SH10rt_1 obj-i6595-type U16
attr SH10rt_1 obj-i6596-expr $val/10
attr SH10rt_1 obj-i6596-polldelay x1000
attr SH10rt_1 obj-i6596-reading Monthly_Export_Energy_PV_Feb
attr SH10rt_1 obj-i6596-type U16
attr SH10rt_1 obj-i6597-expr $val/10
attr SH10rt_1 obj-i6597-polldelay x1000
attr SH10rt_1 obj-i6597-reading Monthly_Export_Energy_PV_Mar
attr SH10rt_1 obj-i6597-type U16
attr SH10rt_1 obj-i6598-expr $val/10
attr SH10rt_1 obj-i6598-polldelay x1000
attr SH10rt_1 obj-i6598-reading Monthly_Export_Energy_PV_Apr
attr SH10rt_1 obj-i6598-type U16
attr SH10rt_1 obj-i6599-expr $val/10
attr SH10rt_1 obj-i6599-polldelay x1000
attr SH10rt_1 obj-i6599-reading Monthly_Export_Energy_PV_May
attr SH10rt_1 obj-i6599-type U16
attr SH10rt_1 obj-i6600-expr $val/10
attr SH10rt_1 obj-i6600-polldelay x1000
attr SH10rt_1 obj-i6600-reading Monthly_Export_Energy_PV_Jun
attr SH10rt_1 obj-i6600-type U16
attr SH10rt_1 obj-i6601-expr $val/10
attr SH10rt_1 obj-i6601-polldelay x1000
attr SH10rt_1 obj-i6601-reading Monthly_Export_Energy_PV_Jul
attr SH10rt_1 obj-i6601-type U16
attr SH10rt_1 obj-i6602-expr $val/10
attr SH10rt_1 obj-i6602-polldelay x1000
attr SH10rt_1 obj-i6602-reading Monthly_Export_Energy_PV_Aug
attr SH10rt_1 obj-i6602-type U16
attr SH10rt_1 obj-i6603-expr $val/10
attr SH10rt_1 obj-i6603-polldelay x1000
attr SH10rt_1 obj-i6603-reading Monthly_Export_Energy_PV_Sep
attr SH10rt_1 obj-i6603-type U16
attr SH10rt_1 obj-i6604-expr $val/10
attr SH10rt_1 obj-i6604-polldelay x1000
attr SH10rt_1 obj-i6604-reading Monthly_Export_Energy_PV_Oct
attr SH10rt_1 obj-i6604-type U16
attr SH10rt_1 obj-i6605-expr $val/10
attr SH10rt_1 obj-i6605-polldelay x1000
attr SH10rt_1 obj-i6605-reading Monthly_Export_Energy_PV_Nov
attr SH10rt_1 obj-i6605-type U16
attr SH10rt_1 obj-i6606-expr $val/10
attr SH10rt_1 obj-i6606-polldelay x1000
attr SH10rt_1 obj-i6606-reading Monthly_Export_Energy_PV_Dec
attr SH10rt_1 obj-i6606-type U16
attr SH10rt_1 obj-i6608-expr $val/10
attr SH10rt_1 obj-i6608-polldelay x1000
attr SH10rt_1 obj-i6608-reading Yearly_Export_Energy_PV_1
attr SH10rt_1 obj-i6608-type U32
attr SH10rt_1 obj-i6610-expr $val/10
attr SH10rt_1 obj-i6610-polldelay x1000
attr SH10rt_1 obj-i6610-reading Yearly_Export_Energy_PV_2
attr SH10rt_1 obj-i6610-type U32
attr SH10rt_1 obj-i6612-expr $val/10
attr SH10rt_1 obj-i6612-polldelay x1000
attr SH10rt_1 obj-i6612-reading Yearly_Export_Energy_PV_3
attr SH10rt_1 obj-i6612-type U32
attr SH10rt_1 obj-i6614-expr $val/10
attr SH10rt_1 obj-i6614-polldelay x1000
attr SH10rt_1 obj-i6614-reading Yearly_Export_Energy_PV_4
attr SH10rt_1 obj-i6614-type U32
attr SH10rt_1 obj-i6616-expr $val/10
attr SH10rt_1 obj-i6616-polldelay x1000
attr SH10rt_1 obj-i6616-reading Yearly_Export_Energy_PV_5
attr SH10rt_1 obj-i6616-type U32
attr SH10rt_1 obj-i6618-expr $val/10
attr SH10rt_1 obj-i6618-polldelay x1000
attr SH10rt_1 obj-i6618-reading Yearly_Export_Energy_PV_6
attr SH10rt_1 obj-i6618-type U32
attr SH10rt_1 obj-i6620-expr $val/10
attr SH10rt_1 obj-i6620-polldelay x1000
attr SH10rt_1 obj-i6620-reading Yearly_Export_Energy_PV_7
attr SH10rt_1 obj-i6620-type U32
attr SH10rt_1 obj-i6622-expr $val/10
attr SH10rt_1 obj-i6622-polldelay x1000
attr SH10rt_1 obj-i6622-reading Yearly_Export_Energy_PV_8
attr SH10rt_1 obj-i6622-type U32
attr SH10rt_1 obj-i6624-expr $val/10
attr SH10rt_1 obj-i6624-polldelay x1000
attr SH10rt_1 obj-i6624-reading Yearly_Export_Energy_PV_9
attr SH10rt_1 obj-i6624-type U32
attr SH10rt_1 obj-i6626-expr $val/10
attr SH10rt_1 obj-i6626-polldelay x1000
attr SH10rt_1 obj-i6626-reading Yearly_Export_Energy_PV_10
attr SH10rt_1 obj-i6626-type U32
attr SH10rt_1 obj-i6627-expr $val/10
attr SH10rt_1 obj-i6627-polldelay x1000
attr SH10rt_1 obj-i6627-reading Monthly_PV_Energy_yields_Feb
attr SH10rt_1 obj-i6627-type U16
attr SH10rt_1 obj-i6628-expr $val/10
attr SH10rt_1 obj-i6628-polldelay x1000
attr SH10rt_1 obj-i6628-reading Yearly_Export_Energy_PV_11
attr SH10rt_1 obj-i6628-type U32
attr SH10rt_1 obj-i6629-expr $val/10
attr SH10rt_1 obj-i6629-polldelay x1000
attr SH10rt_1 obj-i6629-reading Monthly_PV_Energy_yields_Apr
attr SH10rt_1 obj-i6629-type U16
attr SH10rt_1 obj-i6630-expr $val/10
attr SH10rt_1 obj-i6630-polldelay x1000
attr SH10rt_1 obj-i6630-reading Yearly_Export_Energy_PV_12
attr SH10rt_1 obj-i6630-type U32
attr SH10rt_1 obj-i6631-expr $val/10
attr SH10rt_1 obj-i6631-polldelay x1000
attr SH10rt_1 obj-i6631-reading Monthly_PV_Energy_yields_Jun
attr SH10rt_1 obj-i6631-type U16
attr SH10rt_1 obj-i6632-expr $val/10
attr SH10rt_1 obj-i6632-polldelay x1000
attr SH10rt_1 obj-i6632-reading Yearly_Export_Energy_PV_13
attr SH10rt_1 obj-i6632-type U32
attr SH10rt_1 obj-i6633-expr $val/10
attr SH10rt_1 obj-i6633-polldelay x1000
attr SH10rt_1 obj-i6633-reading Monthly_PV_Energy_yields_Aug
attr SH10rt_1 obj-i6633-type U16
attr SH10rt_1 obj-i6634-expr $val/10
attr SH10rt_1 obj-i6634-polldelay x1000
attr SH10rt_1 obj-i6634-reading Yearly_Export_Energy_PV_14
attr SH10rt_1 obj-i6634-type U32
attr SH10rt_1 obj-i6635-expr $val/10
attr SH10rt_1 obj-i6635-polldelay x1000
attr SH10rt_1 obj-i6635-reading Monthly_PV_Energy_yields_Oct
attr SH10rt_1 obj-i6635-type U16
attr SH10rt_1 obj-i6636-expr $val/10
attr SH10rt_1 obj-i6636-polldelay x1000
attr SH10rt_1 obj-i6636-reading Yearly_Export_Energy_PV_15
attr SH10rt_1 obj-i6636-type U32
attr SH10rt_1 obj-i6637-expr $val/10
attr SH10rt_1 obj-i6637-polldelay x1000
attr SH10rt_1 obj-i6637-reading Monthly_PV_Energy_yields_Dec
attr SH10rt_1 obj-i6637-type U16
attr SH10rt_1 obj-i6638-expr $val/10
attr SH10rt_1 obj-i6638-polldelay x1000
attr SH10rt_1 obj-i6638-reading Yearly_Export_Energy_PV_16
attr SH10rt_1 obj-i6638-type U32
attr SH10rt_1 obj-i6640-expr $val/10
attr SH10rt_1 obj-i6640-polldelay x1000
attr SH10rt_1 obj-i6640-reading Yearly_Export_Energy_PV_17
attr SH10rt_1 obj-i6640-type U32
attr SH10rt_1 obj-i6642-expr $val/10
attr SH10rt_1 obj-i6642-polldelay x1000
attr SH10rt_1 obj-i6642-reading Yearly_Export_Energy_PV_18
attr SH10rt_1 obj-i6642-type U32
attr SH10rt_1 obj-i6644-expr $val/10
attr SH10rt_1 obj-i6644-polldelay x1000
attr SH10rt_1 obj-i6644-reading Yearly_Export_Energy_PV_19
attr SH10rt_1 obj-i6644-type U32
attr SH10rt_1 obj-i6646-expr $val/10
attr SH10rt_1 obj-i6646-polldelay x1000
attr SH10rt_1 obj-i6646-reading Yearly_Export_Energy_PV_20
attr SH10rt_1 obj-i6646-type U32
attr SH10rt_1 room PV-Anlage
attr SH10rt_1 userReadings Power_MPPT_1:MPPT.* {sprintf("%.0f", (ReadingsNum ("SH10rt_1","MPPT_1_Voltage", 0) * ReadingsNum ("SH10rt_1","MPPT_1_Current", 0)));;} ,\
Power_MPPT_2:MPPT.* {sprintf("%.0f", (ReadingsNum ("SH10rt_1","MPPT_2_Voltage", 0) * ReadingsNum ("SH10rt_1","MPPT_2_Current", 0)));;}
attr SH10rt_1 verbose 2
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Mai 2022, 22:56:46
Das kombinieren der Requests hat auch nichts mit den Disconnects zu tun. Das ist der Slave. Der macht die Verbindung zu.
Das sollte Dich auch nicht stören.
Mit dem Attribut silentReconnect kannst Du die Meldungen ausblenden.

Der Sinn des Kombinierens der Requests besteht darin, statt 100 kleiner Requests in der Queue nur noch z.B. 10 mit größerer Länge zu haben.

Gruss
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 24 Mai 2022, 11:02:00
danke.

Das Problem ist: Es gibt 2 LAN Ports vom Wechselrichter. Auf dem einen habe ich eine stabile Modbus-Verbindung, bekomme aber manche Register nicht (illegal address). Auf dem anderen gibt es ständig disconnects bzw. die Modbus-Verbindung ist nicht stabil, sodass auch die normalen Register nicht oder nur sehr selten gelesen werden. Ich fürchte das liegt einfach an der Firmware der Wechselrichter und ich muss auf ein Firmware-Update warten, um mein Problem zu lösen....
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 Mai 2022, 19:23:55
Das ein Modbus-TCP-Slave die TCP-Verbindung regelmäßig zu macht ist durchaus normal. Das ist nicht notwendigerweise ein Zeichen von Instabilität.
Wenn bestimmte Register nicht gelesen werden, dann kann das andere Gründe haben. Du müsstest es nur eingrenzen und im Log schauen.
Hast Du denn inzwischen einen korrekten Wert für combine gefunden? Oder hast Du die Queue vergrößert?
Wenn der combine-Wert zu klein ist, kann es sein, dass die Queue überläuft. Dann können Requests nicht abgeschickt werden.
Wenn er zu groß ist, kann es sein dass der Slave mit einer Fehlermeldung antwortet oder den Request einfach ignoriert.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 24 Mai 2022, 20:19:48
Ja, ich habe mit combine 32, combine 16 und ohne combine getestet, keine Änderung des Verhaltens. An der Queue-Länge scheint es also nicht zu liegen.

Wenn ich im Log nach der Ursache suche, finde ich immer wieder ein "busyOpenDev" (s.u.) und connection timed out. Was bedeutet das?


2022.05.24 10:24:08.876 5: HttpUtils url=http://192.168.x.x:502/ NonBlocking via http
2022.05.24 10:24:08.877 4: IP: 192.168.x.x-> 192.168.x.x
2022.05.24 10:24:09.125 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 7, request: request: id 1, read fc 4 i5002,
len 16, tid 52, master device SH10rt_1, reading Daily_Output_PV_AKKU (getUpdate for combined i5002 len 1 Daily_Output_PV_AKKU with i5007 len 1 Inside_Tempera
ture and i5010 len 1 MPPT_1_Voltage and i5011 len 1 MPPT_1_Current and i5012 len 1 MPPT_2_Voltage and i5013 len 1 MPPT_2_Current and i5016 len 2 01_Total_DC_
Power), queued 7.23 secs ago
2022.05.24 10:24:09.127 5: SH10rt_1: open called from ProcessRequestQueue, busyOpenDev 1
2022.05.24 10:24:09.128 5: SH10rt_1: ProcessRequestQueue will return, device is disconnected, qlen 7, try again in 1 seconds
2022.05.24 10:24:09.129 5: SH10rt_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.05.24 10:24:10.134 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 7, request: request: id 1, read fc 4 i5002,
len 16, tid 52, master device SH10rt_1, reading Daily_Output_PV_AKKU (getUpdate for combined i5002 len 1 Daily_Output_PV_AKKU with i5007 len 1 Inside_Tempera
ture and i5010 len 1 MPPT_1_Voltage and i5011 len 1 MPPT_1_Current and i5012 len 1 MPPT_2_Voltage and i5013 len 1 MPPT_2_Current and i5016 len 2 01_Total_DC_
Power), queued 8.24 secs ago
2022.05.24 10:24:10.135 5: SH10rt_1: open called from ProcessRequestQueue, busyOpenDev 1
2022.05.24 10:24:10.136 5: SH10rt_1: ProcessRequestQueue will return, device is disconnected, qlen 7, try again in 1 seconds
2022.05.24 10:24:10.136 5: SH10rt_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.05.24 10:24:11.147 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 7, request: request: id 1, read fc 4 i5002, len 16, tid 52, master device SH10rt_1, reading Daily_Output_PV_AKKU (getUpdate for combined i5002 len 1 Daily_Output_PV_AKKU with i5007 len 1 Inside_Temperature and i5010 len 1 MPPT_1_Voltage and i5011 len 1 MPPT_1_Current and i5012 len 1 MPPT_2_Voltage and i5013 len 1 MPPT_2_Current and i5016 len 2 01_Total_DC_Power), queued 9.25 secs ago
2022.05.24 10:24:11.149 5: SH10rt_1: open called from ProcessRequestQueue, busyOpenDev 1
2022.05.24 10:24:11.150 5: SH10rt_1: ProcessRequestQueue will return, device is disconnected, qlen 7, try again in 1 seconds
2022.05.24 10:24:11.151 5: SH10rt_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.05.24 10:24:11.889 5: SH10rt_1: Open callback: connect to http://192.168.x.x:502 timed out
2022.05.24 10:24:12.154 5: SH10rt_1: open ignored because DevIo has set NEXT_OPEN to 1653380656.88917 / 10:24:16.889 and now is 1653380652.15419 / 10:24:12.154


oder hier


2022.05.23 21:53:37.541 5: HttpUtils url=http://192.168.x.x:502/ NonBlocking via http
2022.05.23 21:53:37.543 4: IP: 192.168.x.x-> 192.168.x.x
2022.05.23 21:53:37.907 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 7, request: request: id 1, read fc 4 i5002, len 16, tid 162, master device SH10rt_1, reading Daily_Output_PV_AKKU (getUpdate for combined i5002 len 1 Daily_Output_PV_AKKU with i5007 len 1 Inside_Temperature and i5010 len 1 MPPT_1_Voltage and i5011 len 1 MPPT_1_Current and i5012 len 1 MPPT_2_Voltage and i5013 len 1 MPPT_2_Current and i5016 len 2 01_Total_DC_Power), queued 10.27 secs ago
2022.05.23 21:53:37.908 5: SH10rt_1: open called from ProcessRequestQueue, busyOpenDev 1
2022.05.23 21:53:37.909 5: SH10rt_1: ProcessRequestQueue will return, device is disconnected, qlen 7, try again in 1 seconds
2022.05.23 21:53:37.910 5: SH10rt_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.05.23 21:53:38.916 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 7, request: request: id 1, read fc 4 i5002, len 16, tid 162, master device SH10rt_1, reading Daily_Output_PV_AKKU (getUpdate for combined i5002 len 1 Daily_Output_PV_AKKU with i5007 len 1 Inside_Temperature and i5010 len 1 MPPT_1_Voltage and i5011 len 1 MPPT_1_Current and i5012 len 1 MPPT_2_Voltage and i5013 len 1 MPPT_2_Current and i5016 len 2 01_Total_DC_Power), queued 11.28 secs ago
2022.05.23 21:53:38.916 5: SH10rt_1: open called from ProcessRequestQueue, busyOpenDev 1
2022.05.23 21:53:38.924 5: SH10rt_1: ProcessRequestQueue will return, device is disconnected, qlen 7, try again in 1 seconds
2022.05.23 21:53:38.925 5: SH10rt_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.05.23 21:53:39.935 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 7, request: request: id 1, read fc 4 i5002, len 16, tid 162, master device SH10rt_1, reading Daily_Output_PV_AKKU (getUpdate for combined i5002 len 1 Daily_Output_PV_AKKU with i5007 len 1 Inside_Temperature and i5010 len 1 MPPT_1_Voltage and i5011 len 1 MPPT_1_Current and i5012 len 1 MPPT_2_Voltage and i5013 len 1 MPPT_2_Current and i5016 len 2 01_Total_DC_Power), queued 12.30 secs ago
2022.05.23 21:53:39.937 5: SH10rt_1: open called from ProcessRequestQueue, busyOpenDev 1
2022.05.23 21:53:39.938 5: SH10rt_1: ProcessRequestQueue will return, device is disconnected, qlen 7, try again in 1 seconds
2022.05.23 21:53:39.939 5: SH10rt_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.05.23 21:53:40.555 5: SH10rt_1: Open callback: connect to http://192.168.x.x:502 timed out
2022.05.23 21:53:40.568 5: SH10rt_1: open ignored because DevIo has set NEXT_OPEN to 1653335625.55522 / 21:53:45.555 and now is 1653335620.5676 / 21:53:40.567
2022.05.23 21:53:40.569 5: SH10rt_1: open ignored because DevIo has set NEXT_OPEN to 1653335625.55522 / 21:53:45.555 and now is 1653335620.5693 / 21:53:40.569
2022.05.23 21:53:40.941 5: SH10rt_1: open ignored because DevIo has set NEXT_OPEN to 1653335625.55522 / 21:53:45.555 and now is 1653335620.94083 / 21:53:40.940
2022.05.23 21:53:40.943 5: SH10rt_1: open ignored because DevIo has set NEXT_OPEN to 1653335625.55522 / 21:53:45.555 and now is 1653335620.94252 / 21:53:40.942
2022.05.23 21:53:40.952 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 7, request: request: id 1, read fc 4 i5002, len 16, tid 162, master device SH10rt_1, reading Daily_Output_PV_AKKU (getUpdate for combined i5002 len 1 Daily_Output_PV_AKKU with i5007 len 1 Inside_Temperature and i5010 len 1 MPPT_1_Voltage and i5011 len 1 MPPT_1_Current and i5012 len 1 MPPT_2_Voltage and i5013 len 1 MPPT_2_Current and i5016 len 2 01_Total_DC_Power), queued 13.32 secs ago
2022.05.23 21:53:40.953 5: SH10rt_1: open called from ProcessRequestQueue, busyOpenDev 0 NEXT_OPEN 21:53:45.555
2022.05.23 21:53:40.955 5: SH10rt_1: open ignored because DevIo has set NEXT_OPEN to 1653335625.55522 / 21:53:45.555 and now is 1653335620.95359 / 21:53:40.953
2022.05.23 21:53:40.955 5: SH10rt_1: ProcessRequestQueue will return, device is disconnected, qlen 7, try again in 1 seconds
2022.05.23 21:53:40.956 5: SH10rt_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.05.23 21:53:40.993 5: SH10rt_1: open ignored because DevIo has set NEXT_OPEN to 1653335625.55522 / 21:53:45.555 and now is 1653335620.99274 / 21:53:40.992


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 Mai 2022, 22:18:24
Das bedeutet, dass die TCP-Verbindung asynchron aufgebaut wird und dass beim Abarbeiten der Queue immer noch keine Verbindung offen ist und auch kein zweiter Open-Aufruf möglich ist, solange der erste noch läuft.
Nach dem Ablauf des Timeouts gibt Open dann auf.
Der Timeout steht per Default auf 3 Sekunden und kann mit dem Attribut openTimeout geändert werden.

Kann es sein, dass Du auf diesem Ethernet-Interface noch ein anderes Gerät angeschlossen hast, das mit dem Slave redet?
Es kommt vor, dass Modbus-TCP-Slaves nur mit einem Master gleichzeitig reden können. Wenn dann ein anderes Gerät gerade redet, hat Fhem das Nachsehen.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: FhemPiUser am 25 Mai 2022, 09:49:42
Vielen Dank für die Erläuterung! Das bestätigt meine Vermutung, dass es an den Wechselrichtern bzw. deren Firmware liegt.

Ja, die WR haben 2 LAN-Schlüsse. An einem hängt ein Dongle dazwischen (er bietet also selbst wieder einen LAN-Anschluß an), der die Daten in die Cloud sendet. Auch dieser Dongle fragt vermutlich per Modbus den WR ab. An beiden LAN-Anschlüsen habe ich die ModbusAttr Device getestet. Bei dem einen (LAN-Anschluß) gibt es die ständigen Disconnects, bei dem anderen können einige Register nicht abgefragt werdne (illegal address).

Des Weiteren habe ich 2 Sungrow Wechselrichter im Parallelmodus, d.h. sie kommunizieren miteinander und tauschen Daten aus zur Konsolidierung, damit die beiden WR  wie ein WR z.B. die Geamtstromproduktion über beide WR darstellen können. Ich vermute die beiden WR kommunizieren dabei über Modbus, allerdings über ein separates RS485-Kabel. Das könnte evtl. auch noch Auswirkungen haben.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Rampler am 02 Juli 2022, 06:50:49
Hallo,
ich habe erfolgreich via Modbusattr meine Solvis Heizung (SolvisBen) angebunden:
Internals:
   DEF        101 60 192.168.1.21:502 TCP
   DeviceName 192.168.1.21:502
   EXPECT     idle
   FD         96
   FUUID      62b762be-f33f-b6d9-496f-552c81839cc005db
   IODev      SolvisBen
   Interval   60
   LASTOPEN   1656707775.03854
   MODBUSID   101
   MODE       master
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       SolvisBen
   NOTIFYDEV  global
   NR         648
   NTFY_ORDER 50-SolvisBen
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   eventCount 6467
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2022-07-02 06:29:57   Aussentemperatur 13.7
     2022-07-02 06:35:57   Brennerleistung 0
     2022-07-02 06:37:58   Brennerstart_Stufe1 42
     2022-07-02 05:50:57   HKR1_Betriebsart Standby
     2022-07-02 05:51:57   HKR2_Betriebsart Standby
     2022-07-02 06:36:59   Heizungspuffer_oben 26.1
     2022-07-02 06:02:57   Kondensatüberwachung 65186
     2022-07-02 05:46:57   Laufzeit_Brennerstufe1 1
     2022-07-02 05:47:58   Laufzeit_Brennerstufe2 1
     2022-07-01 20:09:03   Meldung1_Code   23
     2022-07-01 20:09:11   Meldung1_Part1  0
     2022-07-01 15:34:44   Meldung2_Code   0
     2022-07-01 15:50:07   Meldungen_Anzahl 1
     2022-07-02 06:36:58   Speicher_oben   34.7
     2022-07-02 06:37:57   Speicherreferenz 25.1
     2022-06-30 23:58:11   Version_NBG     30100
     2022-06-30 23:58:16   Version_SC      30501
     2022-07-02 05:45:57   Volumenstrom    0
     2022-07-02 06:37:52   WP_Zirk_Mo_Start 137
     2022-07-02 06:37:58   WP_Zirk_Mo_Stop 137
     2022-07-02 06:01:58   WP_Zirk_Sa_Start 0
     2022-07-02 06:09:10   WP_Zirk_Sa_Stop 0
     2022-07-02 05:50:06   WP_Zirk_So_Start 0
     2022-07-02 05:50:12   WP_Zirk_So_Stop 0
     2022-07-01 15:49:55   WWSollTemp      50
     2022-07-02 06:24:58   WW_Modus        10
     2022-07-02 06:33:57   WW_NachheizStart Ein
     2022-07-02 06:36:58   Warmwassertemperatur 31.1
     2022-07-02 05:40:57   Zirkulation_Betriebsart Zeit
     2022-07-02 06:29:57   Zirkulationstemperatur 20.4
     2022-07-01 22:36:15   state           opened
   REMEMBER:
     lid        101
     lname      SolvisBen
     lrecv      1656736678.5965
     lsend      1656736678.48067
   RESPONSE:
   defptr:
     SolvisBen  101
   gotReadings:
     WP_Zirk_Mo_Stop 137
   lastRead:
     h2054      1656735898.00516
     h2305      1656683395.89206
     h2322      1656736437.47432
     h2818      1656733857.30189
     h3074      1656733917.29802
     h34216     1656736672.90267
     h34217     1656736678.60424
     h34246     1656734518.55489
     h34247     1656734950.18495
     h34252     1656733806.62891
     h34253     1656733812.14703
     i2049      1656733257.31438
     i33024     1656736618.54897
     i33025     1656736618.86972
     i33026     1656736678.00289
     i33027     1656736619.65727
     i33032     1656734577.3356
     i33033     1656736197.49217
     i33034     1656736197.79201
     i33041     1656733557.92391
     i33536     1656733617.32307
     i33537     1656736678.30107
     i33538     1656733678.01864
     i33539     1656736557.76038
     i33792     1656683407.5248
     i33793     1656698943.37399
     i33796     1656698951.49191
Attributes:
   obj-h2054-poll once
   obj-h2054-reading WW_Modus
   obj-h2054-showGet 1
   obj-h2305-hint slider,10,1,65
   obj-h2305-max 65
   obj-h2305-min 10
   obj-h2305-poll once
   obj-h2305-reading WWSollTemp
   obj-h2305-set 1
   obj-h2305-showGet 1
   obj-h2322-map 0:Aus, 1:Ein
   obj-h2322-max 1
   obj-h2322-min 0
   obj-h2322-poll 1
   obj-h2322-polldelay x10
   obj-h2322-reading WW_NachheizStart
   obj-h2322-set 1
   obj-h2322-showGet 1
   obj-h2818-map 2:Automatik, 3:Tagbetrieb, 4:Absenkbetrieb, 5:Standby, 6:Eco, 7:UrlaubshowGet 1
   obj-h2818-poll 1
   obj-h2818-polldelay x120
   obj-h2818-reading HKR1_Betriebsart
   obj-h2818-showGet 1
   obj-h3074-map 2:Automatik, 3:Tagbetrieb, 4:Absenkbetrieb, 5:Standby, 6:Eco, 7:UrlaubshowGet 1
   obj-h3074-poll 1
   obj-h3074-polldelay x120
   obj-h3074-reading HKR2_Betriebsart
   obj-h3074-showGet 1
   obj-h34216-reading WP_Zirk_Mo_Start
   obj-h34216-set 1
   obj-h34216-showGet 1
   obj-h34217-reading WP_Zirk_Mo_Stop
   obj-h34217-set 1
   obj-h34217-showGet 1
   obj-h34246-reading WP_Zirk_Sa_Start
   obj-h34246-showGet 1
   obj-h34247-reading WP_Zirk_Sa_Stop
   obj-h34247-showGet 1
   obj-h34252-reading WP_Zirk_So_Start
   obj-h34252-showGet 1
   obj-h34253-reading WP_Zirk_So_Stop
   obj-h34253-showGet 1
   obj-h34253-unpack s>
   obj-i2049-map 0:Aus, 1:Puls, 2:Zeit, 3:Beide
   obj-i2049-poll 1
   obj-i2049-polldelay once
   obj-i2049-reading Zirkulation_Betriebsart
   obj-i2049-showGet 1
   obj-i32770-reading Version_SC
   obj-i32770-showGet 1
   obj-i32771-reading Version_NBG
   obj-i32771-showGet 1
   obj-i33024-expr $val/10
   obj-i33024-name S1
   obj-i33024-poll 1
   obj-i33024-polldelay x10
   obj-i33024-reading Speicher_oben
   obj-i33025-expr $val/10
   obj-i33025-name S2
   obj-i33025-poll 1
   obj-i33025-polldelay x10
   obj-i33025-reading Warmwassertemperatur
   obj-i33026-expr $val/10
   obj-i33026-name S3
   obj-i33026-poll 1
   obj-i33026-polldelay x10
   obj-i33026-reading Speicherreferenz
   obj-i33027-expr $val/10
   obj-i33027-name S4
   obj-i33027-poll 1
   obj-i33027-polldelay x5
   obj-i33027-reading Heizungspuffer_oben
   obj-i33032-name S9
   obj-i33032-poll 1
   obj-i33032-polldelay x60
   obj-i33032-reading Kondensatüberwachung
   obj-i33033-expr $val/10
   obj-i33033-name S10
   obj-i33033-poll 1
   obj-i33033-polldelay x10
   obj-i33033-reading Aussentemperatur
   obj-i33034-expr $val/10
   obj-i33034-name S12
   obj-i33034-poll 1
   obj-i33034-polldelay x10
   obj-i33034-reading Zirkulationstemperatur
   obj-i33041-name S18
   obj-i33041-poll 1
   obj-i33041-polldelay once
   obj-i33041-reading Volumenstrom
   obj-i33536-poll 1
   obj-i33536-polldelay x60
   obj-i33536-reading Laufzeit_Brennerstufe1
   obj-i33537-poll 1
   obj-i33537-reading Brennerstart_Stufe1
   obj-i33538-poll 1
   obj-i33538-polldelay x60
   obj-i33538-reading Laufzeit_Brennerstufe2
   obj-i33539-poll 1
   obj-i33539-polldelay x5
   obj-i33539-reading Brennerleistung
   obj-i33792-poll 1
   obj-i33792-polldelay x1440
   obj-i33792-reading Meldungen_Anzahl
   obj-i33792-showGet 1
   obj-i33793-reading Meldung1_Code
   obj-i33793-showGet 1
   obj-i33796-reading Meldung1_Part1
   obj-i33796-showGet 1
   obj-i33798-reading Meldung2_Code
   obj-i33798-showGet 1
   room       ToDo


Beim Auslesen des Wochenplans für die Zirkulationspumpe bekomme ich falsche Werte. Laut Doku soll der Wert zwischen 0 und 95 sein.
Habe mal die Registerbeschreibung des Hertsellers angehängt.
Als Zirkulationspumpenschaltzeit in der Heizung habe ich für Montag EIN um 00:00 und AUS für 01:00 hinterlegt.

Hier mal den Debug:
2022.07.02 06:37:58 5: SolvisBen: ResetExpect for HandleResponse from response to idle
2022.07.02 06:37:58 5: SolvisBen: DropFrame called from ReadFn - drop 007000000005650402002a
2022.07.02 06:37:58 4: SolvisBen: get called with WP_Zirk_Mo_Stop (h34217)
2022.07.02 06:37:58 5: SolvisBen: GetSetChecks with force
2022.07.02 06:37:58 5: SolvisBen: GetSetChecks returns success
2022.07.02 06:37:58 4: SolvisBen: DoRequest called from GetLDFn created new request, read buffer empty,
request: id 101, read fc 3 h34217, len 1, tid 168, master device SolvisBen, reading WP_Zirk_Mo_Stop (get WP_Zirk_Mo_Stop)
2022.07.02 06:37:58 5: SolvisBen: QueueRequest called from DoRequest with h34217, qlen 0 from master SolvisBen through io device SolvisBen
2022.07.02 06:37:58 5: SolvisBen: ProcessRequestQueue called from QueueRequest as direct:SolvisBen, qlen 1, force, request: request: id 101, read fc 3 h34217, len 1, tid 168, master device SolvisBen, reading WP_Zirk_Mo_Stop (get WP_Zirk_Mo_Stop), queued 0.00 secs ago
2022.07.02 06:37:58 5: SolvisBen: checkDelays busDelayRead, last activity on bus was 0.180 secs ago, required delay is 0
2022.07.02 06:37:58 5: SolvisBen: checkDelays clientSwitchDelay is not relevant
2022.07.02 06:37:58 5: SolvisBen: checkDelays sendDelay, last send to same device was 0.369 secs ago, required delay is 0.1
2022.07.02 06:37:58 5: SolvisBen: checkDelays commDelay, last communication with same device was 0.180 secs ago, required delay is 0.1
2022.07.02 06:37:58 4: SolvisBen: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 1, sending 00a800000006650385a90001 via 192.168.1.21:502, read buffer empty,
request: id 101, read fc 3 h34217, len 1, tid 168, master device SolvisBen, reading WP_Zirk_Mo_Stop (get WP_Zirk_Mo_Stop), queued 0.00 secs ago
2022.07.02 06:37:58 5: SolvisBen: Send called from ProcessRequestQueue
2022.07.02 06:37:58 5: DevIo_SimpleWrite SolvisBen: 00a800000006650385a90001
2022.07.02 06:37:58 5: SolvisBen: ReadAnswer called from GetLDFn
2022.07.02 06:37:58 5: SolvisBen: ReadAnswer remaining timeout is 1.99140501022339
2022.07.02 06:37:58 5: SolvisBen: ReadAnswer got: 00a8000000056503020089
2022.07.02 06:37:58 5: SolvisBen: ParseFrameStart called from ReadAnswer protocol TCP expecting id 101
2022.07.02 06:37:58 4: SolvisBen: ParseFrameStart (TCP, master) extracted id 101, fCode 3, tid 168, dlen 5 and potential data 020089
2022.07.02 06:37:58 5: SolvisBen: HandleResponse called from ReadAnswer
2022.07.02 06:37:58 5: SolvisBen: ParseResponse called from HandleResponse
2022.07.02 06:37:58 5: SolvisBen: now parsing response data objects, master is SolvisBen relay is undefined
2022.07.02 06:37:58 5: SolvisBen: ParseDataString called from HandleResponse with data hex 0089, type h, adr 34217, op read
2022.07.02 06:37:58 5: SolvisBen: SplitDataString called from ParseDataString with data hex 0089, type h, adr 34217, valuesLen 1, op read
2022.07.02 06:37:58 5: SolvisBen: CreateDataObjects called from ParseDataString with objList h34217
2022.07.02 06:37:58 5: SolvisBen: CreateDataObjects sortedList h34217
2022.07.02 06:37:58 5: SolvisBen: CreateParseInfoCache called
2022.07.02 06:37:58 5: SolvisBen: CreateDataObjects unpacked 0089 with n to 137
2022.07.02 06:37:58 4: SolvisBen: CreateDataObjects assigns value 137 to WP_Zirk_Mo_Stop
2022.07.02 06:37:58 5: SolvisBen: ParseDataString created 1 readings
2022.07.02 06:37:58 4: SolvisBen: HandleResponse done, current frame / read buffer: 00a8000000056503020089, id 101, fCode 3, tid 168,
request: id 101, read fc 3 h34217, len 1, tid 168, master device SolvisBen, reading WP_Zirk_Mo_Stop (get WP_Zirk_Mo_Stop), queued 0.19 secs ago, sent 0.19 secs ago,
response: id 101, fc 3, h34217, len 1, values 0089
2022.07.02 06:37:58 5: SolvisBen: ResetExpect for HandleResponse from response to idle
2022.07.02 06:37:58 5: SolvisBen: DropFrame called from ReadAnswer - drop 00a8000000056503020089


Bin aktuell ziemlich ratlos, habe schon mit unpack rumgespielt, leider ohne Erfolg ..
Hat jemand einen Tipp für mich ?

VG Klaus


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 Juli 2022, 18:34:19
Ich würde mal weitere Register mit bekannten Zeiten auslesen und schauen ob man eine Korrelation findet.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 05 August 2022, 19:37:59
Mal ne Frage.

Ein Gerät das nach MODBUS V1.1 RTU arbeitet soll mir das Model beim holding Register 40000 liefern

lt. Doku ist das String (32 bytes),  also muss ich doch len 16 angeben damit ich die 32 bytes bekomme.
Jetzt ist die gretchenfrage nach dem unpack... was müsste ich da nehmen ? 

Achja da fällt mir wieder auf, wenn ich so schweinereien mache mit unpack a>  dann schmiert Fhem ab :)  wird nicht abgefangen..
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 06 August 2022, 22:45:36
Hallo,

für einen String wäre a* als unpack vermutlich das einfachste

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 07 August 2022, 10:46:08
Hallo Stefan,

Danke jetzt kommen wir der sache schon näher, das mit dem * wenn ich das richtig verstehe ist eine wiederholung.

Ich bekomme jetzt folgendes:

.0 6DCe agorStr wePo

richtig wäre aber:
Power Storage DC 6.0

Ich müsste das jetzt noch irgendwie in der Reihenfolge sortieren  < und > geht ja nicht, ist ja ein endian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 08 August 2022, 10:21:54
Versuch mal "obj-h40000-revRegs 1"
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 08 August 2022, 16:11:57
Zitat von: ansgru am 08 August 2022, 10:21:54
Versuch mal "obj-h40000-revRegs 1"

Danke du bist mein Held... ich hab in meinen Modul revRegs 1 global gesetzt und das hatte alles verdreht...

Jetzt wird es richtig angezeigt.

Noch was anderes, ich nutze an einem RS-485  zwei verschiedene Geräte die ich über TCP RTU anspreche.
Die beiden Devices kollidieren in Fhem und wechseln fleissig von opened auf disconnected

es wird eben auf der selben IP mit dem selben Port quasi die Verbindung aufgebaut. Ich müsste doch dann in Fhem ein device einrichten das die kommunikation macht und dann die modbusattr die darauf dann zugreifen.
Wie muss man das definieren gerade bei IP und RTU.

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 August 2022, 22:31:54
Hallo laserrichi,

könntest Du etwas genauer beschreiben, wie das bei Dir aussieht? TCP oder RS485? oder per TCP auf ein Gateway und daran dann per RS485 zwei Slaves?
Wenn Gateway: was für eines und wie ist das konfiguriert? Was für IDs haben die Clients? Kann das Gateway mehrere TCP Master bedienen? Wie ist Fhem konfiguriert?
Da gibt es leider sehr viele Varianten und Fehlerquellen ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 08 August 2022, 23:01:34
Hallo Stefan,

Espeasy mit Serial Server, und daran Pegel Converter auf RS-485,  also nur durchreiche quasi.  Ist also kein Gateway was 2 Master bedienen kann.
An der RS-485 hängen dann beide Devices dran mit unterschiedlichen Modbus ID's
Sprechen beide RTU.
Ein SDM630M Stromzähler und Wechselrichter wo ich gerade dabei bin das Modul zu basteln.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 August 2022, 18:03:53
Hallo laserrichi,

Das ist ein recht spezielles Setup, da Dein Converter eben nur eine TCP-Verbindung bedient, aber bei Modbus über TCP entweder ein Relay als Gegenstück oder ein einzelner Slave erreicht wird. Für so einen Fall hatte ich das Modul mal so erweitert, dass man ein "physisches" Modbus-Gerät als IO-Device auch per TCP mit so einem Converter verbinden kann und dann logische Modbus-Geräte darüber kommunizieren können. Siehe Antwort #840 und folgende

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 09 August 2022, 18:29:27
Danke,
das hatte ich probiert und gesucht aber nicht mitbekommen das es auch für TCP und RTU so funktioniert....
Sollte Doku vielleicht erweitert werden.

Sieht jetzt bei mir so aus:

Interface:
define ModbusProxy Modbus 192.168.10.7:23
Wechselrichter:
define RCTModbus ModbusRCT 1 65 RTU
Stromzähler:
define Hausstrom ModbusSDM630M 99 90 RTU


Scheint soweit zu laufen :-)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 22 August 2022, 21:14:12
Hallo zusammen, ich versuche gerade meine Nibe WP S320 mit fhem zu verbinden.
Ich versuche es mit ModbusAttr. Leider blicke ich da noch nicht durch. Ein define habe ich gemacht. Was für Attr ich brauche, welche nicht, was da rein gehört ist noch ein Buch mit mehr als 7 Siegeln ;-))
Ich frage mich z.B. wo die von der NIBE gelieferten Daten dann eigentlich angezeigt werden ;-((
Gibt es irgendein Dokument wo man sich einlesen könnte?

Habe meinen bisherigen Versuch mal beigefügt.


Internals:
   CFGFN     
   DEF        5 60 192.168.100.52:502 TCP
   DeviceName 192.168.100.52:502
   EXPECT     idle
   FUUID      6303c0b1-f33f-1fe0-2dc9-03dd2314a4d2d98c
   IODev      NIBE
   Interval   60
   LASTOPEN   1661195439.63033
   LeadingZeros 1
   MODBUSID   5
   MODE       master
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       NIBE
   NEXT_OPEN  1661195499.64065
   NOTIFYDEV  global
   NR         3043
   NTFY_ORDER 50-NIBE
   PARTIAL   
   PROTOCOL   TCP
   STATE      disconnected
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   eventCount 30
   nextOpenDelay 60
   FRAME:
   QUEUE:
   READ:
   READINGS:
     2022-08-22 21:10:39   state           disconnected
   defptr:
     NIBE       5
   lastRead:
Attributes:
   dev-h-defPoll 1
   obj-h00001-expr $val/10
   obj-h00001-len 2
   obj-h00001-poll 1
   obj-h00001-reading AussentemperaturBT1
   obj-h00001-showGet 1
   obj-h00001-unpack n
   obj-h1-expr $val/10
   obj-h1-len 2
   obj-h1-poll 1
   obj-h1-reading AussentemperaturBT1
   room       UG-Heizung
   verbose    5



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 22 August 2022, 21:32:22
Zitat von: Kruemel am 22 August 2022, 21:14:12
Hallo zusammen, ich versuche gerade meine Nibe WP S320 mit fhem zu verbinden.
Ich versuche es mit ModbusAttr. Leider blicke ich da noch nicht durch. Ein define habe ich gemacht. Was für Attr ich brauche, welche nicht, was da rein gehört ist noch ein Buch mit mehr als 7 Siegeln ;-))
Ich frage mich z.B. wo die von der NIBE gelieferten Daten dann eigentlich angezeigt werden ;-((
Gibt es irgendein Dokument wo man sich einlesen könnte?

Habe meinen bisherigen Versuch mal beigefügt.
Hallo Krümel,

bisher zeigt Deine Verbindung noch disconnected.
Es könnte sein, dass der Port 502 eventuell nicht richtig ist. Bei mir wird für ein anderes Gerät 1502 verwendet, vieleicht passt das ja.
Sobald das Device connected anzeigt kannst Du mal ein "set <Device> scanModbusObjects" versuchen, was mit einem "set <Device> scanStop" wieder angehalten werden kann.
Dann sollten diverse readings entstehen, die Dir einen Anhaltspunkt für die Kommunikation geben können.
Besser wäre natürlich, wenn Du eine Dokumentation der ModBus Register von Deinem Gerät hast, da sollte alles drin stehen.

Daraus entwickelt man dann z.B. type definitionen, die dann bei den Registern angewendet werden können

dev-type-INT16_Voltage-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Voltage_SF",0))
dev-type-INT16_Voltage-format %.2f
dev-type-INT16_Voltage-len 1
dev-type-INT16_Voltage-unpack s>

obj-h40077-reading M_AC_Voltage_AN
obj-h40077-type INT16_Voltage


VG
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 22 August 2022, 22:05:10
Hallo Christian, danke für Deine Antwort.
Den Port habe ich aus diesem Dokument der Firma Nibe.
https://www.nibe.eu/download/18.3db69dc1795e0d992c5722/1622634529178/Modbus%20S-series%20EN%20M12676EN-1.pdf (https://www.nibe.eu/download/18.3db69dc1795e0d992c5722/1622634529178/Modbus%20S-series%20EN%20M12676EN-1.pdf)

Gruß
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 23 August 2022, 08:41:07
Zitat von: Kruemel am 22 August 2022, 22:05:10
Hallo Christian, danke für Deine Antwort.
Den Port habe ich aus diesem Dokument der Firma Nibe.
https://www.nibe.eu/download/18.3db69dc1795e0d992c5722/1622634529178/Modbus%20S-series%20EN%20M12676EN-1.pdf (https://www.nibe.eu/download/18.3db69dc1795e0d992c5722/1622634529178/Modbus%20S-series%20EN%20M12676EN-1.pdf)

Gruß
Wolfgang
Hallo Wolfgang,
dann prüf doch mal ob Du das Gerät über einen pin auf die IP-Adresse erreichen kannst. Wenn Du die IP-Adresse jedoch schon aus dem Router oder dem Gerät bekommen hast, dann sollte das okay sein. Eventuell meldet sich ja noch Jemand wegend des connects.

Das mit dem HTTPMOD und der API (https://forum.fhem.de/index.php?topic=108102.0) kannst Du ja auch mal probieren, damit sollte sich das Gerät auch im Browser melden.


In dem Dokument sind dann ja auch schon alle Register aufgelistet, dann kannst Du Dir den Scan sparen und aus der Tabelle die Definition erzeugen. Wichtig ist insbesondere die size spalte, denn da steckt die Länge und der Type jedes registers drin.

VG
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 23 August 2022, 08:52:57
Hallo Christian,
ich habe gestern noch an den Timeouts etwas versucht zu erreichen. Scheinbar ohne Erfolg.
Heute morgen habe ich dann mal den Nibe myplink eingerichtet. Kurz danach ging dann die Verbindung im FHEM auf opened. Der Scan lieferte dann einige Register.
Hmm, kann es sein, das man die Kommunikation per Modbus erst durch den Uplink anschubsen musste?

z.B. das soll die Außentemperatur sein.
scan-h00001 hex=000a, string=.., s=2560, s>=10, S=2560, S>=102022-08-23 07:59:12

Ich versuche dann mal heute Abend die Daten entsprechend aufzubereiten.
Gruß
Wolfgang

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 23 August 2022, 09:48:12
Hallo Wolfgang
Zitat von: Kruemel am 23 August 2022, 08:52:57
Hallo Christian,
ich habe gestern noch an den Timeouts etwas versucht zu erreichen. Scheinbar ohne Erfolg.
Heute morgen habe ich dann mal den Nibe myplink eingerichtet. Kurz danach ging dann die Verbindung im FHEM auf opened. Der Scan lieferte dann einige Register.
Hmm, kann es sein, das man die Kommunikation per Modbus erst durch den Uplink anschubsen musste?
Das Gerät selber kenne ich nicht, aber das sieht dann ja schon mal prima aus.
Den Timeout würde ich wieder zurück nehmen, das wäre notwendig, wenn das gerät sehr langsam Antwortet.
Zitat
z.B. das soll die Außentemperatur sein.
scan-h00001 hex=000a, string=.., s=2560, s>=10, S=2560, S>=102022-08-23 07:59:12
Die Definition kannst Du ja im Dokument in der Tabelle finden.

VG
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 23 August 2022, 19:41:01
Hallo, leider war das heute morgen nicht von Dauer. Es kam nur ein Reading. Seit dem steht es wieder auf disconnect. Ich habe jetzt mal ein neues Device eingerichtet mit lediglich 2 Registern - i00001 und h00001. Im log sehe ich glaube ich, das regelmäßig ein Zugriff probiert wird. Es sind jedoch keine readings sichtbar ;-((
Hat jemand noch eine Idee?
Gruß
Wolfgang


nternals:
   CFGFN     
   DEF        5 60 192.168.100.52:502 TCP
   DeviceName 192.168.100.52:502
   EXPECT     idle
   FUUID      6304eedc-f33f-1fe0-af6d-612e9194103162a6
   IODev      EWWP
   Interval   60
   LASTOPEN   1661276270.00309
   LeadingZeros 1
   MODBUSID   5
   MODE       master
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       EWWP
   NEXT_OPEN  1661276330.1304
   NOTIFYDEV  global
   NR         3282
   NTFY_ORDER 50-EWWP
   PARTIAL   
   PROTOCOL   TCP
   STATE      disconnected
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   eventCount 17
   nextOpenDelay 60
   FRAME:
   QUEUE:
   READ:
   READINGS:
     2022-08-23 19:37:50   state           disconnected
   defptr:
     EWWP       5
   lastRead:
Attributes:
   closeAfterResponse 1
   dev-h-defPoll 1
   dev-i-defPoll 1
   obj-h00001-expr $val / 10
   obj-h00001-len 2
   obj-h00001-reading Aktuelle Außenlufttemperatur (BT1)
   obj-i00001-expr $val / 10
   obj-i00001-len 2
   obj-i00001-reading Aktuelle Außenlufttemperatur (BT1)
   room       UG-Heizung
   verbose    5

2022.08.23 19:54:52.089 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277292.08871 / 19:54:52.088
2022.08.23 19:54:52.089 5: EWWP: ProcessRequestQueue will return, device is disconnected, qlen 2, try again in 1 seconds
2022.08.23 19:54:52.090 5: EWWP: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.08.23 19:54:53.092 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277293.092 / 19:54:53.092
2022.08.23 19:54:53.094 5: EWWP: ProcessRequestQueue called from Fhem internal timer as queue:EWWP, qlen 2, request: request: id 5, read fc 3 h00001, len 2, tid 162, master device EWWP, reading Aktuelle Außenlufttemperatur (BT1) (getUpdate for Aktuelle Außenlufttemperatur (BT1) len 2), queued 16.12 secs ago
2022.08.23 19:54:53.095 5: EWWP: open called from ProcessRequestQueue, busyOpenDev 0 NEXT_OPEN 19:54:58.156
2022.08.23 19:54:53.095 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277293.09486 / 19:54:53.094
2022.08.23 19:54:53.096 5: EWWP: ProcessRequestQueue will return, device is disconnected, qlen 2, try again in 1 seconds
2022.08.23 19:54:53.097 5: EWWP: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.08.23 19:54:53.994 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277293.99431 / 19:54:53.994
2022.08.23 19:54:54.097 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277294.09727 / 19:54:54.097
2022.08.23 19:54:54.099 5: EWWP: ProcessRequestQueue called from Fhem internal timer as queue:EWWP, qlen 2, request: request: id 5, read fc 3 h00001, len 2, tid 162, master device EWWP, reading Aktuelle Außenlufttemperatur (BT1) (getUpdate for Aktuelle Außenlufttemperatur (BT1) len 2), queued 17.12 secs ago
2022.08.23 19:54:54.099 5: EWWP: open called from ProcessRequestQueue, busyOpenDev 0 NEXT_OPEN 19:54:58.156
2022.08.23 19:54:54.100 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277294.09963 / 19:54:54.099
2022.08.23 19:54:54.100 5: EWWP: ProcessRequestQueue will return, device is disconnected, qlen 2, try again in 1 seconds
2022.08.23 19:54:54.100 5: EWWP: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.08.23 19:54:55.103 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277295.10267 / 19:54:55.102
2022.08.23 19:54:55.110 5: EWWP: ProcessRequestQueue called from Fhem internal timer as queue:EWWP, qlen 2, request: request: id 5, read fc 3 h00001, len 2, tid 162, master device EWWP, reading Aktuelle Außenlufttemperatur (BT1) (getUpdate for Aktuelle Außenlufttemperatur (BT1) len 2), queued 18.13 secs ago
2022.08.23 19:54:55.111 5: EWWP: open called from ProcessRequestQueue, busyOpenDev 0 NEXT_OPEN 19:54:58.156
2022.08.23 19:54:55.111 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277295.11106 / 19:54:55.111
2022.08.23 19:54:55.112 5: EWWP: ProcessRequestQueue will return, device is disconnected, qlen 2, try again in 1 seconds
2022.08.23 19:54:55.112 5: EWWP: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.08.23 19:54:56.114 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277296.11436 / 19:54:56.114
2022.08.23 19:54:56.116 5: EWWP: ProcessRequestQueue called from Fhem internal timer as queue:EWWP, qlen 2, request: request: id 5, read fc 3 h00001, len 2, tid 162, master device EWWP, reading Aktuelle Außenlufttemperatur (BT1) (getUpdate for Aktuelle Außenlufttemperatur (BT1) len 2), queued 19.14 secs ago
2022.08.23 19:54:56.117 5: EWWP: open called from ProcessRequestQueue, busyOpenDev 0 NEXT_OPEN 19:54:58.156
2022.08.23 19:54:56.118 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277296.11731 / 19:54:56.117
2022.08.23 19:54:56.118 5: EWWP: ProcessRequestQueue will return, device is disconnected, qlen 2, try again in 1 seconds
2022.08.23 19:54:56.118 5: EWWP: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.08.23 19:54:56.295 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277296.29512 / 19:54:56.295
2022.08.23 19:54:56.297 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277296.29753 / 19:54:56.297





Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 23 August 2022, 20:22:01
Zitat von: Kruemel am 23 August 2022, 19:41:01
Hallo, leider war das heute morgen nicht von Dauer. Es kam nur ein Reading. Seit dem steht es wieder auf disconnect. Ich habe jetzt mal ein neues Device eingerichtet mit lediglich 2 Registern - i00001 und h00001. Im log sehe ich glaube ich, das regelmäßig ein Zugriff probiert wird. Es sind jedoch keine readings sichtbar ;-((
Hat jemand noch eine Idee?
Gruß
Wolfgang
Hallo Wolfgang,
bitte verwende für Deine Postings auch die code Tags, das ist der Lattenzaun bei den Symbolen über dem Eingabefeld.
Es wäre toll, wenn Du das auch in Deinen alten Postings noch nachträglich machen würdest.


2022.08.23 19:54:56.118 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now is 1661277296.11731 / 19:54:56.117

Als erstes solltest Du ein stabiles connected bekommen.
Die readings kommen dann im zweiten Schritt.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 23 August 2022, 20:47:43
Ich habe die postings bearbeitet.

2022.08.23 19:54:52.089 5: EWWP: open ignored because DevIo has set NEXT_OPEN to 1661277298.1563 / 19:54:58.156 and now


Wie ist denn diese Meldung zu verstehen? Ich kenne nur das Intervall von 60 sec.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 24 August 2022, 08:22:03
Hallo, hier ein update.
Ich habe mal die Wärmepumpe neu gestartet. In fhem ging das device dann auf opened und empfängt jetzt auch readings.
VG
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 25 August 2022, 15:13:42
Hallo, so das opened scheint jetzt stabil zu sein. Ich habe auch mal mit closeAfterResponse gespielt 1 und 0 liefern Werte.
Ich habe jetzt Register da bekomme ich mit den Attributen reading, len und expr einen nachvollziehbaren regelmäßigen Wert.
Das poll habe jeweils für i und h - Register auf 1 gesetzt.


dev-h-defPoll 1 deleteattr
dev-i-defPoll 1 deleteattr


Dann habe ich andere Register, da kommt ein Wert nur bei der Einrichtung oder bisher nicht.
Habt Ihr einen Tipp wie ich diese zum Leben erwecke? Die Infos zu den Registern kommen ja aus einer Doku des Herstellers. Letztendlich kann ich dort auch nachfragen ob die Regeister existieren. Ich möchte nur von meiner Seite alles mögliche abklären.

VG Wolfgang

P.S. hier noch Details zu funktionieren (ok) und nicht funktionieren (nok) Registern


ok
obj-i00001-expr $val / 10
obj-i00001-len 2
obj-i00001-reading Aktuelle Außenlufttemperatur (BT1)

nok
obj-i00005-expr $val
obj-i00005-len 2
obj-i00005-poll 1
obj-i00005-reading VorlaufBT2

ok
obj-i00007-expr $val / 10
obj-i00007-len 2
obj-i00007-reading Rücklauf (BT3)

nok
obj-i00008-expr $val / 10
obj-i00008-len 2
obj-i00008-reading Brauchwasser oben (BT7)

nok
obj-i00009-expr $val / 10
obj-i00009-len 2
obj-i00009-reading Brauchwasser (BT6)

nok
obj-i00037-expr $val / 10
obj-i00037-len 2
obj-i00037-reading mittlere Temperatur (BT1)

ok
obj-i00040-expr $val / 10
obj-i00040-len 2
obj-i00040-reading Volumenstrommesser (BF1)

nok
obj-i00351-expr 139+$val
obj-i00351-len 6
obj-i00351-poll 1
obj-i00351-reading AnzahlStarts(S135)

nok
obj-i01622-expr $val / 10
obj-i01622-len 2
obj-i01622-reading Verdampfer(EB101-BT16)

ok
obj-i01803-expr $val / 10
obj-i01803-len 2
obj-i01803-reading aktuelle Verdichterfrequenz (EB101)





Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 25 August 2022, 15:20:55
Zitat von: Kruemel am 25 August 2022, 15:13:42
Hallo, so das opened scheint jetzt stabil zu sein. Ich habe auch mal mit closeAfterResponse gespielt 1 und 0 liefern Werte.
Ich habe jetzt Register da bekomme ich mit den Attributen reading, len und expr einen nachvollziehbaren regelmäßigen Wert.
Das poll habe jeweils für i und h - Register auf 1 gesetzt.


dev-h-defPoll 1 deleteattr
dev-i-defPoll 1 deleteattr


Dann habe ich andere Register, da kommt ein Wert nur bei der Einrichtung oder bisher nicht.
Habt Ihr einen Tipp wie ich diese zum Leben erwecke? Die Infos zu den Registern kommen ja aus einer Doku des Herstellers. Letztendlich kann ich dort auch nachfragen ob die Regeister existieren. Ich möchte nur von meiner Seite alles mögliche abklären.

VG Wolfgang
Hallo Wolfgang,
eventuell werden einige Register ja nur gesendet, wenn es Änderungen gibt.
Ansonsten hatte ich bei mir am Anfang auch mal einen Scann gemacht und diesen mit der Beschreibung verglichen. Danach habe ich dann alles unnütze entfernt, bzw korrekt konfiguriert.

VG
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 25 August 2022, 15:26:18
Zitat von: ch.eick am 25 August 2022, 15:20:55
Hallo Wolfgang,
eventuell werden einige Register ja nur gesendet, wenn es Änderungen gibt.
Ansonsten hatte ich bei mir am Anfang auch mal einen Scann gemacht und diesen mit der Beschreibung verglichen. Danach habe ich dann alles unnütze entfernt, bzw korrekt konfiguriert.

VG
   Christian

Halllo Christian, der scan läuft gerade. Ich wollte das auch vergleichen.
Ich hatte irgendwo gelesen, das Klammer-Zeichen evt. ein Problem im reading sind. Sollte man darauf verzichten. Ein umbenennen hatte bei mir jedoch bisher keinen Effekt.
VG
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 25 August 2022, 15:31:50
Zitat von: Kruemel am 25 August 2022, 15:26:18
Halllo Christian, der scan läuft gerade. Ich wollte das auch vergleichen.
Ich hatte irgendwo gelesen, das Klammer-Zeichen evt. ein Problem im reading sind. Sollte man darauf verzichten. Ein umbenennen hatte bei mir jedoch bisher keinen Effekt.
Klammern vermeide ich im reading Namen, da gibt es auch immer Ärger wenn man Regex darauf anwendet.
Generell gebe ich für die register die Namen vor und beschränke mich auf "_+-".
Zu lang sollte es auch nicht werden, das wird dann auch zu unüberlichtlich.
Die zusammen geschriebene GroßKlein Schreibung finde ich recht nett.
Bei technischen Namen verwende ich auch Kürzel, Leistung wird P, Strom wird I, Spannung wird V, ...
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 25 August 2022, 15:36:00
Zitat von: ch.eick am 25 August 2022, 15:31:50
Klammern vermeide ich im reading Namen, da gibt es auch immer Ärger wenn man Regex darauf anwendet.
Generell gebe ich für die register die Namen vor und beschränke mich auf "_+-".
Zu lang sollte es auch nicht werden, das wird dann auch zu unüberlichtlich.
Die zusammen geschriebene GroßKlein Schreibung finde ich recht nett.
Bei technischen Namen verwende ich auch Kürzel, Leistung wird P, Strom wird I, Spannung wird V, ...
Hallo, ja dann werde ich das bei der nächsten Version auch überarbeiten. Ich hatte auch gesehen, das Leezeichen im reading-Namen dazu führen, das man es nicht mehr löschen kann. Daher werde ich sicher noch mehrer Versionen des devices haben bis es passt  :-\
VG
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Adimarantis am 29 August 2022, 09:45:30
Hallo,

Ich habe eine Frage zur Syntax von ignoreExpr:

Sowas wie $val>950 funktioniert ja ganz gut. Da ich einen Temperatursensor habe der manchmal spinnt, dieser sich aber eigentlich immer in der Nähe eines Referenzsensors bewegt, wollte ich Werte relativ zu diesem ausschliessen, also sowas wie
$val>ReadingsVal("Max1","temperature",0)*10+200

Da bekomme ich aber einen Syntax Error. Verschiedene Versuche mit Klammersetzung oder "if" Anweisung haben auch höchstens dazu geführt, dass alle Werte ignoriert wurden. Ist sowas überhaupt vorgesehen und wenn ja, wie stelle ich das an?

Danke,
Jörg
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kruemel am 29 August 2022, 10:29:37
Hallo, im Moment wäre da auch ein ) zu viel, oder?
Gruß
Wolfgang
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Adimarantis am 29 August 2022, 10:48:36
Copy&Paste Fehler von den Versuchen. Habs im Post korrigiert damit es keine Verwirrung gibt.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RobertSch am 13 September 2022, 08:15:04
Guten Tag Zusammen!

Ich bin noch recht frisch im Thema fhem und habe so meine ersten Schritte bereits gemacht und bin auch immer ganz gut klar gekommen. Allerdings habe ich nun doch ein Problem. Und zwar weiß ich gar nicht weiter, was das Thema Modbus betrifft. Habe mir viel durchgelesen, aber stehe immer noch auf dem Schlauch. Ich habe hier mehrere UMG604 von Janitza, teils noch mit Anbindung an UMG103. Wollte klein anfangen und erstmal einen einzelnen UMG604 anbinden und entsprechend auslesen. Mein Problem besteht darin, das ich keine Ahnung habe, wie ich das genau anstelle.

Bei meiner Recherche bin ich hier auf das 98_ModbusUMG604.pm Modul gestoßen und habe es eingebunden. Hier haben auch ein paar Leute geschrieben, wie das geht. Ich habe dazu das Modul wie folgt hinzugefügt:

define UMG604 ModbusUMG604 1 10 172.27.5.24:502 TCP

Die Verbindung zum Zähler scheint hiermit auch zu stehen und man kann die Stromwandler und Spannungswandler entsprechend einstellen. Allerdings ist das auch der Punkt, bei dem es bei mir aufhört. Ich möchte gerne gezielt die Werte auslesen, wie Spannung L1, L2, L3 sowie Leistung der einzelnen Phasen und Gesamtleistung etc.. In den Code Ausschnitten hier steht dann, das man entsprechend per attr die Daten abrufen/auslesen lassen kann.

Beispiel:
attr UMG604 poll-Voltage_L1 1

Dummerweise meckert da dann fhem mit mir rum und meint, das wäre nicht möglich. Daher hatte ich noch andere Dinge ausprobiert, aber irgendwie bin ich egal wie, nicht ans Ziel gelangt. Kann mir da jemand etwas helfen und mir vielleicht den passenden Hinweis geben, der mich weiter bringt? Muss ich noch ein zusätzliches Modbus Gerät anlegen? Oder läuft das irgendwie über die ModbusAttr? Ich bin hier leider nicht wirklich aus der Dokumentation schlau geworden und würde mich freuen, wenn ich hier weiter komme.

Ich hoffe es ist verständlich wo es genau hängt bei mir, aber wenn nicht, dann bitte einfach fragen.

Danke schonmal im Voraus für eure Hilfe.

LG
Robert
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: aikawa24 am 17 September 2022, 01:55:16
hallo,
ich Versucher eine Wallbox über das Modbusattr auszulesen,

mein Problem liegt bei den Unpack Codes

die werte die nur ein Register füllen kommen an aber wenn die 2 und mehr füllen bekomm ich das reading nicht angezeigt bzw nur 0

bei dem Namen und Serien Nummer hab ich es mit unpack a16 oder a8 hinbekommen, jenachdem wie viele Register der wert füllt.

eine doch gibts hier https://www.cfos-emobility.de/en/cfos-power-brain/modbus-registers.htm (https://www.cfos-emobility.de/en/cfos-power-brain/modbus-registers.htm)

ich habs schon mit den Standards s> f> und n probiert aber das bleibt immer 0

bei Register 8058 müsste zumindest 1307,2 kWh rauskommen
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 September 2022, 14:05:10
Hallo Adimarantis,

ist Deine letzte Nachricht so gemeint, dass das Problem gelöst ist?
In meinen Tests funktioniert das ignoreExpr problemlos auch bei Vergleichen gegen den bisherigen Readings-Wert.
Falls Du da noch ein Problem hast, poste doch mal Deine exakte Konfiguration und einen Auszug aus dem Log mit verbose 5, in dem man die Verarbeitung / Zuweisung der Readings sieht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 September 2022, 14:09:49
Hallo RobertSch,

Zitat von: RobertSch am 13 September 2022, 08:15:04
Bei meiner Recherche bin ich hier auf das 98_ModbusUMG604.pm Modul gestoßen und habe es eingebunden. Hier haben auch ein paar Leute geschrieben, wie das geht. Ich habe dazu das Modul wie folgt hinzugefügt:

define UMG604 ModbusUMG604 1 10 172.27.5.24:502 TCP

Die Verbindung zum Zähler scheint hiermit auch zu stehen und man kann die Stromwandler und Spannungswandler entsprechend einstellen. Allerdings ist das auch der Punkt, bei dem es bei mir aufhört. Ich möchte gerne gezielt die Werte auslesen, wie Spannung L1, L2, L3 sowie Leistung der einzelnen Phasen und Gesamtleistung etc.. In den Code Ausschnitten hier steht dann, das man entsprechend per attr die Daten abrufen/auslesen lassen kann.
woher hast Du denn das ModbusUMG604-Modul? Welche Werte da abgefragt werden, müsstest Du im Modulcode nachsehen oder per set Gerät CreateAttrsFromParseInfo das ganze wieder auf die ModbusAttr-Konfiguration zurückführen. Falls da dann Objekte definiert sind, die nicht abgefragt werden, dann fügst Du am besten ein Attribute für das entsprechende Register ein, z.B. obj-h100-poll o.ä. Die tatsächlichen Objekte / Adressen siehst Du nach set Gerät CreateAttrsFromParseInfo.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 September 2022, 14:11:31
Hallo aikawa24,

Zitat von: aikawa24 am 17 September 2022, 01:55:16
die werte die nur ein Register füllen kommen an aber wenn die 2 und mehr füllen bekomm ich das reading nicht angezeigt bzw nur 0
bei dem Namen und Serien Nummer hab ich es mit unpack a16 oder a8 hinbekommen, jenachdem wie viele Register der wert füllt.
eine doch gibts hier https://www.cfos-emobility.de/en/cfos-power-brain/modbus-registers.htm (https://www.cfos-emobility.de/en/cfos-power-brain/modbus-registers.htm)
ich habs schon mit den Standards s> f> und n probiert aber das bleibt immer 0
bei Register 8058 müsste zumindest 1307,2 kWh rauskommen

um Dir helfen zu können, müsste ich Deine tatsächliche Konfiguration kennen. Poste die doch mal zusammen mit einem Auszug aus dem Log bei verbose 5.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RobertSch am 28 September 2022, 08:18:27
Zitat von: StefanStrobel am 17 September 2022, 14:09:49
Hallo RobertSch,
woher hast Du denn das ModbusUMG604-Modul? Welche Werte da abgefragt werden, müsstest Du im Modulcode nachsehen oder per set Gerät CreateAttrsFromParseInfo das ganze wieder auf die ModbusAttr-Konfiguration zurückführen. Falls da dann Objekte definiert sind, die nicht abgefragt werden, dann fügst Du am besten ein Attribute für das entsprechende Register ein, z.B. obj-h100-poll o.ä. Die tatsächlichen Objekte / Adressen siehst Du nach set Gerät CreateAttrsFromParseInfo.

Gruss
   Stefan

Hallo Stefan!

Danke für deine Antwort. Ich stehe leider immer noch auf dem Schlauch. War zwar auch ne Woche im Urlaub und hatte gehofft, das mir die Auszeit vielleicht eine Idee bringt, aber leider ist dem nicht so.
Das Modul habe ich hier aus dem vorherigen Thread und es wurde von golem hier https://forum.fhem.de/index.php/topic,25315.msg268721.html#msg268721 (https://forum.fhem.de/index.php/topic,25315.msg268721.html#msg268721) geteilt.

Mein Problem liegt halt glaub ich darin, das ich wohl noch gar nicht verstanden habe, wie ich ein Modbus Gerät konfiguriere. Denn sowie ich das bisher verstehe sorgt das Modul von golem ja nur dafür, das man die Register etc. nicht mehr händisch heraussuchen muss. In dem Thread gibt es auch Einträge, wie es in der fhem.cfg konfiguriert wurde. Wenn ich die allerdings 1:1 mit passender IP versteht sich übernehme, habe ich zwar das Gerät in fhem, aber die Attribute sind nicht gesetzt. Das eine Verbindung zum Gerät steht ist mit "opened" denke ich klar, weil sonst ein "timeout" entstehen würde. Wie gesagt, im golem Modul kann ich auch mittels "set Gerät Spannungswandler_PrimärL1 Wert" entsprechend die Variablen für den Spannungswandler etc. einstellen. Ich bekomme lediglich keine Informationen zu den einzelnen Messwerten zurück. Ein "createAttrsFromParseInfo" gibt es auch, aber ich versteh nicht so ganz, was ich in das Wert/Variablen Feld dahinter setzen muss, damit was sinnvolles passiert.

Evtl. ist mein Weg, den ich bisher gegangen bin auch vollkommen falsch und es gibt andere bessere Wege. Ich wäre sehr froh, wenn ich hier weiter käme. Verstehe auch noch nicht so ganz, wie die Module modbus und mobusAttr. zusammenhängen. Vielleicht liegt da auch das Problem. Kannst du mir da bitte auch einmal den groben Zusammenhang erklären? Ich hoffe ja immernoch, das irgendwann der "Aha"-Moment kommt.

Danke im Voraus!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 September 2022, 09:43:16
Hallo RobertSch,

Der Status opened bedeutet zunächst mal nur dass die TCP-Verbindung steht, bzw. bei seriellen Verbindungen dass die Schnittstelle geöffnet wurde.
Ob Fhem tatsächlich mit dem Gerät kommunizieren kann, ist eine andere Frage.
Du hast geschrieben dass Du den Spannungswandler über Fhem einstellen kannst. Hast Du auch kontrolliert, ob die Werte im Gerät wirklich ankommen? Oder hat Fhem nur keine Fehlermeldung angezeigt?
Am besten sieht man das wenn man das Attribut verbose auf 5 setzt und dann im Log beobachtet, wie das Gerät antwortet.
Stimmt denn die Modbus-Id überhaupt?

Zum Auslesen:
Ich hab mir das Modul für den Zähler angesehen. Darin steht z. B.:


    "h10048"=>  {
name => "vt_priml1",
          defaultpoll => "once",
showget => 1,
reading => "Spannungswandler_PrimärL1",
          set => 1,
          min => 100,
max => 60000
          },
         



das holding register 10048 enthält offenbar den Wert für Spannungswandler_PrimärL1.
gelesen wird der Wert einmal beim Start von Fhem oder manuell per get Spannungswandler_PrimärL1
Klappt das mit dem get denn oder kommt da ein Fehler?
Auch hier hilft ein Blick ins Log.
Wenn das alles klappt und Du den Wert regelmäßig lesen möchtest, dann kannst Du das mit dem Attribut obj-h10948-poll überschreiben.
Im Prinzip ist das Modul für Deinen Zähler nur ein vorkonfigurierten ModbusAttr.

Gruß
    Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 28 September 2022, 16:43:19
Hallo Stefan,

ich versuche gerade mein Modul https://forum.fhem.de/index.php/topic,117416.0.html (https://forum.fhem.de/index.php/topic,117416.0.html) mit deinem Modbus RTU Modul zu ersetzen. Der Denkfehler an meinem Modul ist, dass ich natürlich ein Device (USB/RS485) nur einmal auf machen kann. Ich muss das ganze nun mit einem weiteren Teilnehmer erweitern...

Hier ein Teil der Modbus Definition:
defmod Mod_Pumpen ModbusAttr 2 1
attr Mod_Pumpen IODev Modbus_Dev
.
.
.
attr Mod_Pumpen obj-c3-map 0:off, 1:on
attr Mod_Pumpen obj-c3-reading Rel4
attr Mod_Pumpen obj-c3-set 1
attr Mod_Pumpen obj-d2-len 1
attr Mod_Pumpen obj-d2-poll 1
attr Mod_Pumpen obj-d2-reading In
attr Mod_Pumpen obj-d2-showGet 1
attr Mod_Pumpen obj-h16384-reading Adr
attr Mod_Pumpen obj-h16384-set 1
attr Mod_Pumpen room Modbus
.
.
.


Die Relais, welche über Coils angesteuert werden, funktionieren. Die Eingänge sollen sich über "Discrete Inputs" also mit der Funktion 02 lesen lassen. In der Beschreibung steht hierzu das:

Zitat
Read all interfaces input status
01 02 00 00 00 00 78 0a
return:
01 02 01 01 60 48 //IN1 pressed
01 02 01 02 20 49 //IN2 pressed
01 02 01 04 A0 4B //IN3 pressed
01 02 01 08 A0 4E //IN4 pressed

Wenn ich das richtig sehe, ist der Response kürzer als in der Spec.

Nun die Frage, was müsste ich tun, damit es mit deinem Modul funktioniert?

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 28 September 2022, 16:53:36
Hallo Axel,

So spontan würde ich sagen, dass die Antwort ok ist.
Id, fcode, bytecount, data und checksum.
Der bytecount ist ja selbst nur ein Byte.

Sollte also alles funktionieren.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 28 September 2022, 18:02:18
Hallo Stefan,

so verstehe ich das auch.
Wenn ich das so einbaue, geht es nur, wenn der Wert 01 = 1 oder 00 = 0 ist.
Der Wert (bzw. die Bits) 02, 04 oder 08 werden ignoriert.

Kann es sein, dass das Modus das Ergebnis mit 0x01 ausmaskiert, sodass nur das erste Bit bewertet wird?

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: franky08 am 28 September 2022, 21:56:24
Hallo, ich komme irgendwie nicht weiter und habe einen neuen Thread aufgemacht, kann da mal jemand drüber schauen?

https://forum.fhem.de/index.php/topic,129367.0.html

Vielen Dank
Frank
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 29 September 2022, 10:45:30
Hallo Stefan,

ich habe noch ein wenig geforscht. Die Antwort passt aber dein Modul ist sehr genau, was es mit Antworten auf sich hat ;)
In Zeile 2542 wird aus allem was größer als 0 ist eine 1 gemacht.
Zitat..SplitDataString shortened coil / input bit string to..
Nach Spec ist das richtig aber für mich nicht gut.

Ich habe das mal geändert und das if umgebaut.. es würde so gehen - bis ich das Modul updaten würde.

Nun meine Frage, würdest du ein Atttribut einführen, was auch Zahlen größer 1 für discrete zulässt?
Alternativ würde ich die Datei 98_Modbus.pm kopieren, umbenennen und anpassen .. Problem: Das ist mit dem Namespace (glaube es liegt an package..?) etwas kompliziert und auf die Schnelle so nicht machbar.
Oder: ich ändere die original 98_Modbus.pm für mich und nehme die aus dem Updatevorgang raus - gibt es diese Möglichkeit?

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 September 2022, 12:08:46
Hallo Axel,

Du hast recht, es hängt an der Längenangabe.
Das Modul verwendet die im Request angegebene Anzahl an discrete inputs (oder coils) um die relevanten Bits der Response in Readings zu setzen.
In Deinem Fall antwortet das Gerät bei Anzahl 0 mit allen Inputs und das Modul nimmt bei 0 wenigstens den ersten Eingang.
Was passiert eigentlich wenn Du im Request statt 0 eine 4 als echte Länge angibst?
Wenn das funktioniert (so wäre es vom Standard vorgesehen) dann wäre ja keine Änderung nötig.
Falls nicht kann ich gerne ein weiteres brokenFCxx Attribut für Sonderfälle / nicht korrekte Modbus-Implementationen hinzufügen.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 29 September 2022, 13:32:33
Hallo Stefan,

wenn ich eine Länge angebe, ändert das auch nichts. So wie ich verstanden habe, meinst du das so:


attr Mod_Pumpen dev-c-defLen 4
attr Mod_Pumpen dev-d-defLen 4
attr Mod_Pumpen obj-d2-len 4


Wenn ich aber den Code richtig verstehe, bringt das nichts, da mit Z2542: if ($type =~ '[cd]') und Z2556: $unpack  = 'a'; das wieder gekürzt wird. Die Länge wird hier nicht beachtet...

Ich habe es nur hinbekommen, als ich das d aus dem Z2542: if ($type =~ '[c]') {  #[cd] ausgenommen habe.
Gleichzeitig müsste dann aber weiter unten das Z2556: $unpack  = 'a'; in der while zu z.B. 'c' geändert werden...

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RobertSch am 29 September 2022, 14:12:13
Zitat von: StefanStrobel am 28 September 2022, 09:43:16
Hallo RobertSch,

Der Status opened bedeutet zunächst mal nur dass die TCP-Verbindung steht, bzw. bei seriellen Verbindungen dass die Schnittstelle geöffnet wurde.
Ob Fhem tatsächlich mit dem Gerät kommunizieren kann, ist eine andere Frage.
Du hast geschrieben dass Du den Spannungswandler über Fhem einstellen kannst. Hast Du auch kontrolliert, ob die Werte im Gerät wirklich ankommen? Oder hat Fhem nur keine Fehlermeldung angezeigt?
Am besten sieht man das wenn man das Attribut verbose auf 5 setzt und dann im Log beobachtet, wie das Gerät antwortet.
Stimmt denn die Modbus-Id überhaupt?

Zum Auslesen:
Ich hab mir das Modul für den Zähler angesehen. Darin steht z. B.:


    "h10048"=>  {
name => "vt_priml1",
          defaultpoll => "once",
showget => 1,
reading => "Spannungswandler_PrimärL1",
          set => 1,
          min => 100,
max => 60000
          },
         



das holding register 10048 enthält offenbar den Wert für Spannungswandler_PrimärL1.
gelesen wird der Wert einmal beim Start von Fhem oder manuell per get Spannungswandler_PrimärL1
Klappt das mit dem get denn oder kommt da ein Fehler?
Auch hier hilft ein Blick ins Log.
Wenn das alles klappt und Du den Wert regelmäßig lesen möchtest, dann kannst Du das mit dem Attribut obj-h10948-poll überschreiben.
Im Prinzip ist das Modul für Deinen Zähler nur ein vorkonfigurierten ModbusAttr.

Gruß
    Stefan

Vielen lieben Dank! Es wird so langsam. Also als erstes, die Daten gehen raus, werden geschrieben wenn ich den set-Befehl nutze und können auch per get-Befehl gelesen werden. Allerdings klappt das mit dem regelmäßigen Abruf nicht. Ich habe dazu die unterschiedlichsten Varianten versucht, aber unter Readings taucht am Ende keiner meiner Versuche auf. Darunter war auch dein obj-h10948-poll, wobei das glaub ich eigentlich obj-h10048-poll sein sollte, oder? Habe jedenfalls beides getestet und es gab keine Reaktion.

Im Log steht dann immer folgendes:
umg604: unknown attribute Real_energy_L2_Supply. Type 'attr umg604 ?' for a detailed list.

Heißt, dort ändert sich auch nur Wert des attribute, den ich zum testen vorher in der fhem.cfg eingebe. Über die fhem Leiste probiere ich es mittlerweile gar nicht erst, weil auch dort immer sofort die Fehlermeldung kommt. Ist auch egal, ob ich hier das Register h10048, deine Version mit poll am Ende, dasselbe mit poll davor, oder wie im Code direkt die Readings anspreche. Immer komt dieser Fehler.

Am Ende fehlt anscheinend nur noch ein kleines Puzzleteil um mein Problem zu beheben. Hast du da vielleicht noch eine Idee für mich, woran es haken könnte?

Gruß
Robert
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 September 2022, 15:33:42
Hallo Axel,

nein, ich dachte eher an einen Test mit einem normalen Modbus-Programm für Windows.
Wenn Dein Gerät dann auch korrekte Requests mit Längenangabe oder Abfrage von einzelnen Inputs mit Adresse > 0 akzeptiert, dann ist der Rest ohne Änderung machbar.

Im Fhem-Modul geht das dann so dass Du für jeden Eingang ein eigenes Objekt erzeugst. Jedes mit individueller Adresse I0, I1, ... und Länge 1.
Über combine oder group kann das Modul dann die Requests zu einem einzigen zusammenfassen.

Siehe z.B. auch https://forum.fhem.de/index.php/topic,129080.msg1234340.html#msg1234340

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 September 2022, 16:11:38
Zitat
Im Log steht dann immer folgendes:
umg604: unknown attribute Real_energy_L2_Supply. Type 'attr umg604 ?' for a detailed list.

Heißt, dort ändert sich auch nur Wert des attribute, den ich zum testen vorher in der fhem.cfg eingebe. Über die fhem Leiste probiere ich es mittlerweile gar nicht erst, weil auch dort immer sofort die Fehlermeldung kommt. Ist auch egal, ob ich hier das Register h10048, deine Version mit poll am Ende, dasselbe mit poll davor, oder wie im Code direkt die Readings anspreche. Immer komt dieser Fehler.

Am Ende fehlt anscheinend nur noch ein kleines Puzzleteil um mein Problem zu beheben. Hast du da vielleicht noch eine Idee für mich, woran es haken könnte?


Hallo Robert,

Ich vermute Du verwendest schlicht den attr-Befehl falsch.

attr UMG604 obj-h10048-poll 1

sollte funktionieren.
Wenn Du über die Fhem-Eingabezeile eine Fehlermeldung bekommst, dann machst Du definitiv etwas falsch.

Du kannst auch einfach ein set createAttrsFromParseInfo auswählen, dann werden die ganzen vorkonfigurierten Werte aus dem Modul als Attribute erzeugt und dann kannst Du das obj-h10048-poll einfach auswählen und von once auf 1 ändern.

Oder die öffnest die Moduldatei mit einem Editor und änderst es dort.

Gruß
    Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 29 September 2022, 17:27:13
Hallo Stefan,

welche Länge ich dem Request mitgebe, scheint dem Relayboard egal zu sein wie man auf dem Bild "Request mit L4" erkennt.
Die Antwort der jeweiligen Eingänge sieht man auf dem Bild "Response Eing 1 bis 4".

Das Datenbyte des discretes kann bei dem Board nicht nur 0 und 1 sondern auch 2, 4 und 8 - eben Bitcodiert. Ich schreibe es nur ungern aber die Lösung wäre hier nur, mit dem Attribut "brokenFCxx Attribut" alle Zahlen zuzulassen  :-\

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RobertSch am 30 September 2022, 07:09:01
Zitat von: StefanStrobel am 29 September 2022, 16:11:38
Hallo Robert,

Ich vermute Du verwendest schlicht den attr-Befehl falsch.

attr UMG604 obj-h10048-poll 1

sollte funktionieren.
Wenn Du über die Fhem-Eingabezeile eine Fehlermeldung bekommst, dann machst Du definitiv etwas falsch.

Du kannst auch einfach ein set createAttrsFromParseInfo auswählen, dann werden die ganzen vorkonfigurierten Werte aus dem Modul als Attribute erzeugt und dann kannst Du das obj-h10048-poll einfach auswählen und von once auf 1 ändern.

Oder die öffnest die Moduldatei mit einem Editor und änderst es dort.

Gruß
    Stefan


Erst einmal danke für deine Geduld. Ja genau das dachte ich halt auch. Aber selbst mit Copy & Paste deines Befehls gibt es halt die Fehlermeldung aus. (UMG musste ich allerdings klein schreiben, wegen case-sensitive)

umg604: unknown attribute obj-h10048-poll. Type 'attr umg604 ?' for a detailed list.

Wenn ich spaßeshalber das ? eingebe, dann gibt fhem mir folgendes zurück:

umg604: unknown attribute ?, choose one of alias comment eventMap group room suppressReading userattr userReadings verbose do_not_notify IODev queueMax alignTime enableControlSet enableSetInactive nonPrioritizedSet nonPrioritizedGet sortUpdate cacheUpdateHash cacheParseInfo propagateVerbose connectionsRoom serverIdExpr scanDelay disable event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat timestamp-on-change-reading queueDelay queueMax queueTimeout busDelay clientSwitchDelay frameGap dropQueueDoubles enableQueueLengthReading retriesAfterTimeout profileInterval openTimeout nextOpenDelay nextOpenDelay2 maxTimeoutsToReconnect skipGarbage timeoutLogLevel closeAfterResponse silentReconnect cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel widgetOverride

Bei
set umg604 createAttrsFromParseInfo
passiert sogar rein gar nichts. Da ist die Seite in fhem einfach nur frei. Egal, ob ich das über die Leiste in fhem eingebe, oder ob ich es im Gerät selbst aus dem Dropdown Menü auswähle. Vielleicht fehlt da was im umg604 Modul?

EDIT:
Hab jetzt gerade nochmal das mit dem createAttrsFormParseInfo durchgeführt, nachdem ich zuvor noch die Attr cacheParseInfo und cacheUpdateHash auf 1 gesetzt hatte. Und siehe da, da passiert zumindest laut Log doch etwas. Allerdings sagt er das sämtliche Attrs aus den ParseInfo "unknown" sind.

2022.09.30 08:57:11 4: umg604: GetUpdate is using cached object list
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10032-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10032-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10032-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10032-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10032-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10032-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10032-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10034-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10034-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10034-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10034-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10034-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10034-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10034-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10036-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10036-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10036-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10036-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10036-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10036-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10036-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10038-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10038-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10038-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10038-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10038-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10038-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10038-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10040-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10040-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10040-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10040-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10040-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10040-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10040-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10042-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10042-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10042-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10042-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10042-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10042-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10042-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10044-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10044-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10044-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10044-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10044-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10044-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10044-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10046-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10046-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10046-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10046-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10046-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10046-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10046-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10048-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10048-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10048-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10048-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10048-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10048-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10048-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10050-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10050-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10050-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10050-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10050-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10050-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10052-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10052-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10052-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10052-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10052-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10052-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10054-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10054-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10054-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10054-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10054-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10054-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10056-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10056-max. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10056-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10056-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10056-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10056-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10056-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10058-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10058-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10058-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10058-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10058-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10058-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10060-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10060-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10060-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10060-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10060-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10060-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10062-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10062-min. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10062-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10062-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10062-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10062-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10176-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10176-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10176-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10176-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10176-unpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10178-defaultpoll. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10178-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10178-len. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10178-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10178-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10178-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h10178-unpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19000-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19000-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19000-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19000-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19002-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19002-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19002-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19002-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19004-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19004-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19004-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19004-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19006-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19006-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19006-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19006-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19008-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19008-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19008-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19008-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19010-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19010-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19010-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19010-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19012-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19012-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19012-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19012-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19014-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19014-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19014-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19014-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19016-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19016-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19016-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19016-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19018-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19018-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19018-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19018-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19020-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19020-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19020-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19020-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19022-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19022-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19022-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19022-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19024-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19024-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19024-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19024-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19026-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19026-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19026-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19026-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19028-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19028-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19028-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19028-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19030-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19030-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19030-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19030-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19032-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19032-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19032-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19032-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19034-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19034-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19034-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19034-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19036-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19036-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19036-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19036-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19038-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19038-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19038-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19038-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19040-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19040-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19040-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19040-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19042-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19042-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19042-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19042-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19044-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19044-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19044-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19044-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19046-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19046-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19046-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19046-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19048-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19048-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19048-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19048-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19050-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19050-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19050-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19050-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19054-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19054-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19054-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19054-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19056-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19056-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19056-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19056-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19058-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19058-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19058-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19058-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19060-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19060-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19060-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19060-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19070-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19070-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19070-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19070-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19072-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19072-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19072-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19072-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19074-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19074-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19074-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19074-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19076-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19076-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19076-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19076-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19078-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19078-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19078-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19078-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19080-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19080-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19080-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19080-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19082-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19082-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19082-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19082-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19084-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19084-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19084-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19084-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19086-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19086-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19086-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19086-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19088-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19088-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19088-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19088-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19090-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19090-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19090-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19090-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19092-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19092-format. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19092-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h19092-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-len. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-setexpr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-setmax. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-setmin. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9997-unpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-len. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-setexpr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-setmax. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-setmin. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9998-unpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-expr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-len. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-name. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-reading. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-set. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-setexpr. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-setmax. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-setmin. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-showget. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute obj-h9999-unpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-c-defFormat. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-c-defLen. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-c-defUnpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-c-read. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-c-write. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-d-defFormat. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-d-defLen. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-d-defUnpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-d-read. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-h-combine. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-h-defLen. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-h-defShowGet. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-h-defUnpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-h-read. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-h-write. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-i-defFormat. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-i-defLen. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-i-defUnpack. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-i-read. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-timing-commDelay. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-timing-sendDelay. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: unknown attribute dev-timing-timeout. Type 'attr umg604 ?' for a detailed list.
2022.09.30 08:57:18 3: umg604: createAttrsFromParseInfo done



Ich habe es nun auch mal ohne dieses Submodul getestet und lande da beim selben Ergbenis. Verstehe leider nicht wirklich woran es noch hapert. Zumal die get Abfrage mit dem Submodul funktioniert wie hier im Beispiel:

get umg604 Spannungswandler_PrimärL1

Hier gibt er mir den Wert "400" aus, was auch korrekt ist. Per set kann ich den auch überschreiben und das wird halt auch im Gerät übernommen.

Falls dir/euch noch etwas einfällt, dann lass es mich bitte wissen.

Danke!

Gruß
Robert
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 September 2022, 16:29:40
Hallo Robert,

ich habe mir das UMG604-Modul mal angesehen. Da fehlt etwas und deshalb konnte es nicht gehen.
Schau doch mal die Funktion ModbusUMG604_Initialize im Code an und ergänze die letzten Zeilen mit der Zuweisung an $modHash->{AttrList}

Dann sollte es so aussehen:


sub ModbusUMG604_Initialize($)
{
    my ($modHash) = @_;
$modHash->{parseInfo}  = \%UMG604parseInfo; # defines registers, inputs, coils etc. for this Modbus Defive
$modHash->{deviceInfo} = \%deviceInfo; # defines properties of the device like
# defaults and supported function codes
ModbusLD_Initialize($modHash); # Generic function of the Modbus module does the rest

        $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
}


Zudem ist es recht unglücklich, dass die Variable deviceInfo nicht den Namen des Moduls enthält. Die sollte in UMG604deviceInfo umbenannt werden um weitere Probleme zu vermeiden.
Das sind 4 Stellen, die Du mit Suchen/ersetzen korrigieren kannst.
Ich habs auch einfach mal angehängt, aber nicht getestet.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 September 2022, 16:55:26
Hallo Axel,

ich bau den brokenFC2 ein. Hat das Gerät / Board denn einen Namen, den ich dafür verwenden kann?
Es gibt zum Beispiel schon brokenFC2 doepke.

Dennoch würde ich gerne Dein Beispiel verstehen.
02 02 00 02 00 04 d8 3a
würde ich als id2 fc2 Adresse 0002 Länge 0004 und crc d83a interpretieren. Hast Du Input 2 abgefragt?

02 a0 01 31
ist seltsam. Vermutlich soll das id2 sein, a0 wäre dann aber ein Error Code!
Wenn 01 dennoch die Antwort sein soll, dann fehlt hinten das zweite Byte des CRC...
Daher auch die Meldung von ModbusPoll, dass der CRC falsch ist.
Offenbar hat Dein Gerät noch mehr Spezialitäten auf Lager ;-)

Oder es liegt an der abgefragten Adresse 2, mit der das Board nicht klar kommt.
Wie sieht die Antwort denn bei Abfrage von Adresse 0 aus? also 02 02 00 00 00 00 + CRC
Was passiert wenn Du bei Adresse 0 eine Länge 4 abfragst? also 02 02 00 00 00 04 + CRC

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 September 2022, 19:15:32
Hallo Axel,

ich habe das mal bei mir nachgestellt.
Wenn Du es in etwa so konfigurierst:

attr Master dev-d-combine 4
attr Master dev-d-defPoll 1
attr Master obj-d0-reading in1
attr Master obj-d1-reading in2
attr Master obj-d2-reading in3
attr Master obj-d3-reading in4


dann wird beim automatischen Auslesen zyklisch ein kombinierter Request für alle 4 Inputs erzeugt:

2022.09.30 19:00:39.318 5: Master: CreateUpdateHash full object list: d0 d1 d2 d3
2022.09.30 19:00:39.319 5: Master: CreateUpdateHash will request d0 len 1 in1
2022.09.30 19:00:39.319 5: Master: CreateUpdateHash will request d1 len 1 in2
2022.09.30 19:00:39.319 5: Master: CreateUpdateHash will request d2 len 1 in3
2022.09.30 19:00:39.319 5: Master: CreateUpdateHash will request d3 len 1 in4
2022.09.30 19:00:39.319 4: Master: CombineUpdateHash objHash keys before combine: d1,d2,d3,d0
2022.09.30 19:00:39.319 5: Master: CombineUpdateHash tries to combine read commands
2022.09.30 19:00:39.319 5: Master: CombineUpdateHash combine d0 len 1 in1 with d1 len 1 in2 to span 2, drop read for d1
2022.09.30 19:00:39.319 5: Master: CombineUpdateHash combine d0 len 1 in1 with d2 len 1 in3 to span 3, drop read for d2
2022.09.30 19:00:39.320 5: Master: CombineUpdateHash combine d0 len 1 in1 with d3 len 1 in4 to span 4, drop read for d3
2022.09.30 19:00:39.320 5: Master: CombineUpdateHash keys are now d0
2022.09.30 19:00:39.320 4: Master: GetUpdate will now create requests for d0 len 4 (combined d0 len 1 in1 with d1 len 1 in2 and d2 len 1 in3 and d3 len 1 in4)
2022.09.30 19:00:39.320 4: Master: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 2 d0, len 4, master device Master, reading in1 (getUpdate for combined d0 len 1 in1 with d1 len 1 in2 and d2 len 1 in3 and d3 len 1 in4)
2022.09.30 19:00:39.320 5: MS: QueueRequest called from DoRequest with d0, qlen 0 from master Master through io device MS
2022.09.30 19:00:39.320 5: MS: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
Event: Master:reread
2022.09.30 19:00:39.320 1: Test step 1 (main::testStep1) done
2022.09.30 19:00:39.320 5: MS: ProcessRequestQueue called from Fhem internal timer as queue:MS, qlen 1, request: request: id 1, read fc 2 d0, len 4, master device Master, reading in1 (getUpdate for combined d0 len 1 in1 with d1 len 1 in2 and d2 len 1 in3 and d3 len 1 in4), queued 0.00 secs ago
2022.09.30 19:00:39.321 5: MS: checkDelays sendDelay, last send to same device was never, required delay is 0
2022.09.30 19:00:39.321 5: MS: checkDelays busDelayRead, last activity on bus was never, required delay is 0
2022.09.30 19:00:39.321 5: MS: checkDelays clientSwitchDelay is not relevant
2022.09.30 19:00:39.321 5: MS: checkDelays commDelay, last communication with same device was never, required delay is 0
2022.09.30 19:00:39.321 4: MS: ProcessRequestQueue (V4.4.06 - 17.9.2022) qlen 1, sending 01020000000479c9 via none, read buffer empty,
request: id 1, read fc 2 d0, len 4, master device Master, reading in1 (getUpdate for combined d0 len 1 in1 with d1 len 1 in2 and d2 len 1 in3 and d3 len 1 in4), queued 0.00 secs ago
2022.09.30 19:00:39.322 5: MS: Send called from ProcessRequestQueue
2022.09.30 19:00:39.322 4: MS: Simulate sending to none: 01020000000479c9


Wenn Dein Gerät das nicht mit einem Fehler beantwortet, dann werden aus der Antwort auch 4 Readings erzeugt ohne dass eine Änderung nötig wäre.
Die Länge 4 wird beim Parsen aus dem Request für die Response verwendet:

2022.09.30 19:00:39.322 1: Test simulate reception of 010201022049
2022.09.30 19:00:39.322 5: MS: readFn buffer: 010201022049
2022.09.30 19:00:39.322 5: MS: ParseFrameStart called from ReadFn protocol RTU expecting id 1
2022.09.30 19:00:39.322 4: MS: ParseFrameStart (RTU, master) extracted id 1, fCode 2 and potential data 0102
2022.09.30 19:00:39.322 5: MS: HandleResponse called from ReadFn
2022.09.30 19:00:39.323 5: MS: ParseResponse called from HandleResponse
2022.09.30 19:00:39.323 5: MS: CheckChecksum (called from ParseResponse): 2049 is valid
2022.09.30 19:00:39.323 5: MS: now parsing response data objects, master is Master relay is undefined
2022.09.30 19:00:39.323 5: Master: ParseDataString called from HandleResponse with data hex 02, type d, adr 0, op read
2022.09.30 19:00:39.323 5: Master: SplitDataString called from ParseDataString with data hex 02, type d, adr 0, valuesLen 4, op read
2022.09.30 19:00:39.323 5: Master: SplitDataString shortened coil / input bit string to 0100, start adr 0, valuesLen 4
2022.09.30 19:00:39.323 5: Master: CreateDataObjects called from ParseDataString with objList d0,d1,d2,d3
2022.09.30 19:00:39.323 5: Master: CreateDataObjects sortedList d0,d1,d2,d3
2022.09.30 19:00:39.323 5: Master: CreateParseInfoCache called
2022.09.30 19:00:39.323 5: Master: CreateDataObjects unpacked 30 with a to 0
2022.09.30 19:00:39.323 4: Master: CreateDataObjects assigns value 0 to in1
2022.09.30 19:00:39.324 5: Master: CreateParseInfoCache called
2022.09.30 19:00:39.324 5: Master: CreateDataObjects unpacked 31 with a to 1
2022.09.30 19:00:39.324 4: Master: CreateDataObjects assigns value 1 to in2
2022.09.30 19:00:39.324 5: Master: CreateParseInfoCache called
2022.09.30 19:00:39.324 5: Master: CreateDataObjects unpacked 30 with a to 0
2022.09.30 19:00:39.324 4: Master: CreateDataObjects assigns value 0 to in3
2022.09.30 19:00:39.324 5: Master: CreateParseInfoCache called
2022.09.30 19:00:39.324 5: Master: CreateDataObjects unpacked 30 with a to 0
2022.09.30 19:00:39.324 4: Master: CreateDataObjects assigns value 0 to in4
Event: Master:in1: 0
Event: Master:in2: 1
Event: Master:in3: 0
Event: Master:in4: 0
2022.09.30 19:00:39.325 5: Master: ParseDataString created 4 readings


Ich habe trotzdem mal angefangen, ein brokenFC2 relay1 für Deinen Fall einzubauen, Ergebnis anbei, aber in meinen Simulationen mit der von Dir geposteten Antwort aus der Doku war das nicht nötig.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 01 Oktober 2022, 00:29:30
Hallo Stefan,

sorry für die späte Antwort - bin aber erst jetzt dazu gekommen.

Die Konfiguration funktioniert mit folgender Definition:


defmod Mod_Pumpen ModbusAttr 2 1
attr Mod_Pumpen IODev Modbus_Dev
attr Mod_Pumpen dev-d-combine 4
attr Mod_Pumpen dev-d-defPoll 1
attr Mod_Pumpen devStateIcon 1.on:on:Rel1+off 1.off:off:Rel1+on\
2.on:on:Rel2+off 2.off:off:Rel2+on\
3.on:on:Rel3+off 3.off:off:Rel3+on\
4.on:on:Rel4+off 4.off:off:Rel4+on
attr Mod_Pumpen obj-c0-map 0:off, 1:on
attr Mod_Pumpen obj-c0-reading Rel1
attr Mod_Pumpen obj-c0-set 1
attr Mod_Pumpen obj-c1-map 0:off, 1:on
attr Mod_Pumpen obj-c1-reading Rel2
attr Mod_Pumpen obj-c1-set 1
attr Mod_Pumpen obj-c2-map 0:off, 1:on
attr Mod_Pumpen obj-c2-reading Rel3
attr Mod_Pumpen obj-c2-set 1
attr Mod_Pumpen obj-c3-map 0:off, 1:on
attr Mod_Pumpen obj-c3-reading Rel4
attr Mod_Pumpen obj-c3-set 1
attr Mod_Pumpen obj-d0-reading in1
attr Mod_Pumpen obj-d1-reading in2
attr Mod_Pumpen obj-d2-reading in3
attr Mod_Pumpen obj-d3-reading in4
attr Mod_Pumpen obj-h16384-reading Adr
attr Mod_Pumpen obj-h16384-set 1
attr Mod_Pumpen room Modbus
attr Mod_Pumpen stateFormat 1:Rel1\
2:Rel2\
3:Rel3\
4:Rel4


Response Beispiel: 01 02 01 01 60 48 //IN1 pressed
Jetzt habe ich endlich auch das mit dem Response für die Coils verstanden. Da stand ich auf dem Schlauch - Sorry dafür - das ist ja Byteweise organisiert und das unterstrichene 01 bedeutet, wieviel Bytes noch kommen...
Das combine tut für die Performance gut - sonst würde jedes Coil separat abgefragt werden...

Danke für die Hilfe und das brokenFC2 kannst du somit wieder löschen.  :D

Eine (nicht wichtige) Kleinigkeit noch:
das
"0:off, 1:on" und das "set 1"
wollte ich in ein
"attr Mod_Pumpen dev-type-tRelay-map 1:on, 0:off" und "attr Mod_Pumpen dev-type-tRelay-set 1"
zusammenfassen.
Ist das Absicht, dass das für die Discretes nicht zugelassen ist?

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 01 Oktober 2022, 09:18:03
Zitat von: ahermann86 am 01 Oktober 2022, 00:29:30
Eine (nicht wichtige) Kleinigkeit noch:
das
"0:off, 1:on" und das "set 1"
wollte ich in ein
"attr Mod_Pumpen dev-type-tRelay-map 1:on, 0:off" und "attr Mod_Pumpen dev-type-tRelay-set 1"
zusammenfassen.
Ist das Absicht, dass das für die Discretes nicht zugelassen ist?

gute Frage :-) ich erinnere mich nicht daran, warum ich das damals nicht auch für "cd" zugelassen habe. Eigentlich sollte das dort genauso gehen.
Was passiert denn wenn Du die Zeile 329 in der Attributliste ergänzt?

        'obj-[cdih][0-9]+-type',


Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 01 Oktober 2022, 12:15:42
Hi Stefan,

yup - das funktioniert   8)
Kannst es ja beim nächsten Release einpflegen  :)

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andy1981 am 03 Oktober 2022, 18:08:09
Hallo Stefan,

ich versuche mal wieder meine Pluggit Lüftungsanlage direkt mit FHEM über das Modbus Modul zu verbinden. Da die Daten der Pluggit AP300 nicht dem Modbus standard entsprechen und beispielweise 4 Temperaturen in 2 Registern gespeichert sind, würde ich gerne selber Readings über die "ModbusReadingsFN" Funktion erzeugen. Als Vorlage habe ich das ModbusElsnerWS von Klaus Scheuer verwendet, aktuell sieht das Modul so aus:


# $Id: 98_ModbusPluggitAP300.pm 24745 2022-10-02 16:40:26Z Andreas H $
# This modules handles the communication with a Pluggit AP190/300/400.

package main;

use strict;
use warnings;
use Time::HiRes qw( time );
use HttpUtils;

# deviceInfo defines properties of the device.
# some values can be overwritten in parseInfo, some defaults can even be overwritten by the user with attributes if a corresponding attribute is added to AttrList in _Initialize.
#

sub ModbusPluggit_Eval($$$);
sub ModbusPluggit_Initialize($);

my %ModbusPluggit_DeviceInfo = (
"timing" => {
timeout => 2, # 2 seconds timeout when waiting for a response
commDelay => 0.7, # 0.7 seconds minimal delay between two communications e.g. a read a the next write,
# can be overwritten with attribute commDelay if added to AttrList in _Initialize below
sendDelay => 0.7, # 0.7 seconds minimal delay between two sends, can be overwritten with the attribute
# sendDelay if added to AttrList in _Initialize function below
},
"h" => { # details for "holding registers" if the device offers them
read => 3, # use function code 3 to read holding registers.
write => 16, # use function code 6 to write holding registers (alternative could be 16)
defLen => 1, # default length (number of registers) per value (e.g. 2 for a float of 4 bytes that spans 2 registers)
# can be overwritten in parseInfo per reading by specifying the key "len"
combine => 10, # allow combined read of up to 10 adjacent registers during getUpdate
defUnpack => "f>", # default pack / unpack code to convert raw values, e.g. "n" for a 16 bit integer oder
# "f>" for a big endian float IEEE 754 floating-point numbers
# can be overwritten in parseInfo per reading by specifying the key "unpack"
defPoll => 1, # All defined Input Registers should be polled by default unless specified otherwise in parseInfo or by attributes
defShowGet => 1, # default für showget Key in parseInfo
},
);

# %parseInfo:
# r/c/i+adress => objHashRef (h = holding register, c = coil, i = input register, d = discrete input)
# the address is a decimal number without leading 0
#
# Explanation of the parseInfo hash sub-keys:
# name internal name of the value in the modbus documentation of the physical device
# reading name of the reading to be used in Fhem
# set can be set to 1 to allow writing this value with a Fhem set-command
# setmin min value for input validation in a set command
# setmax max value for input validation in a set command
# hint string for fhemweb to create a selection or slider
# expr perl expression to convert a string after it has bee read
# map a map string to convert an value from the device to a more readable output string
# or to convert a user input to the machine representation
# e.g. "0:mittig, 1:oberhalb, 2:unterhalb"
# setexpr per expression to convert an input string to the machine format before writing
# this is typically the reverse of the above expr
# format a format string for sprintf to format a value read
# len number of Registers this value spans
# poll defines if this value is included in the read that the module does every defined interval
# this can be changed by a user with an attribute
# unpack defines the translation between data in the module and in the communication frame
# see the documentation of the perl pack function for details.
# example: "n" for an unsigned 16 bit value or "f>" for a float that is stored in two registers
# showget can be set to 1 to allow a Fhem get command to read this value from the device
# polldelay if a value should not be read in each iteration after interval has passed,
# this value can be set to a multiple of interval

my %ModbusPluggit_ParseInfo = (
  'h1032'  => {reading => 'Temperaturen',
            name => 'Temperaturen',
            expr => 'sprintf("%d %d %d %d",
             $val[0],
             $val[1],
             $val[2],
             $val[3])',
        unpack => 'CCCC',
            len => 2,
            poll => 1
          }
);


#####################################

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

    $modHash->{parseInfo}  = \%ModbusPluggit_ParseInfo;  # defines registers, inputs, coils etc. for this Modbus Defive   
    $modHash->{deviceInfo} = \%ModbusPluggit_DeviceInfo; # 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} = "ModbusPluggit_Eval";    # 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
}



sub ModbusPluggit_Eval($$$) {
  my ($modHash, $readingName, $readingVal) = @_;
  my $name = $modHash->{NAME};
  my $ctrl = 1;
  my ($Frischluft, $Zuluft, $Abluft, $Fortluft) = split(' ', $readingVal);
  readingsSingleUpdate($modHash, "Frischluft", $Frischluft, 1);
  readingsSingleUpdate($modHash, "Zuluft", $Zuluft, 1);
  readingsSingleUpdate($modHash, "Abluft", $Abluft, 1);
  readingsSingleUpdate($modHash, "Fortluft", $Fortluft, 1);
  return $ctrl;
}
1;

=pod
=begin html

<a name="ModbusPluggit"></a>
<h3>ModbusPluggit</h3>
<ul>
    ModbusPluggit uses the low level Modbus module to provide a way to communicate with SDM221M smart electrical meter from B+G E-Tech & EASTON.
It defines the modbus input and holding registers and reads them in a defined interval.

<br>
    <b>Prerequisites</b>
    <ul>
        <li>
          This module requires the basic Modbus module which itsef requires Device::SerialPort or Win32::SerialPort module.
        </li>
    </ul>
    <br>

    <a name="ModbusPluggitDefine"></a>
    <b>Define</b>
    <ul>
        <code>define &lt;name&gt; ModbusPluggit &lt;Id&gt; &lt;Interval&gt;</code>
        <br><br>
        The module connects to the smart electrical meter with Modbus Id &lt;Id&gt; through an already defined modbus device and actively requests data from the
        smart electrical meter every &lt;Interval&gt; seconds <br>
        <br>
        Example:<br>
        <br>
        <ul><code>define SDM221M ModbusPluggit 1 60</code></ul>
    </ul>
    <br>

    <a name="ModbusPluggitConfiguration"></a>
    <b>Configuration of the module</b><br><br>
    <ul>
        apart from the modbus id and the interval which both are specified in the define command there is nothing that needs to be defined.
However there are some attributes that can optionally be used to modify the behavior of the module. <br><br>
       
        The attributes that control which messages are sent / which data is requested every &lt;Interval&gt; seconds are:

        <pre>
poll-Energy_total__kWh
poll-Energy_import__kWh
</pre>
       
        if the attribute is set to 1, the corresponding data is requested every &lt;Interval&gt; seconds. If it is set to 0, then the data is not requested.
        by default the temperatures are requested if no attributes are set.
        <br><br>
        Example:
        <pre>
        define SDM221M ModbusPluggit 1 60
        attr SDM221M poll-Energy_total__kWh 0
        </pre>
    </ul>

    <a name="ModbusPluggit"></a>
    <b>Set-Commands</b><br>
    <ul>
        The following set options are available:
        <pre>
        </pre>
    </ul>
<br>
    <a name="ModbusPluggitGet"></a>
    <b>Get-Commands</b><br>
    <ul>
        All readings are also available as Get commands. Internally a Get command triggers the corresponding
        request to the device and then interprets the data and returns the right field value. To avoid huge option lists in FHEMWEB, only the most important Get options
        are visible in FHEMWEB. However this can easily be changed since all the readings and protocol messages are internally defined in the modue in a data structure
        and to make a Reading visible as Get option only a little option (e.g. <code>showget => 1</code> has to be added to this data structure
    </ul>
<br>
    <a name="ModbusPluggitattr"></a>
    <b>Attributes</b><br><br>
    <ul>
<li><a href="#do_not_notify">do_not_notify</a></li>
        <li><a href="#readingFnAttributes">readingFnAttributes</a></li>
        <br>
<li><b>poll-Energy_total__kWh</b></li>
<li><b>poll-Energy_import__kWh</b></li>
            include a read request for the corresponding registers when sending requests every interval seconds <br>
        <li><b>timeout</b></li>
            set the timeout for reads, defaults to 2 seconds <br>
<li><b>minSendDelay</b></li>
minimal delay between two requests sent to this device
<li><b>minCommDelay</b></li> 
minimal delay between requests or receptions to/from this device
    </ul>
    <br>
</ul>

=end html
=cut


Anscheinend wird die Subroutine in meinem Modul "98_ModbusPluggit.pm" nicht aufgerufen, ich bekomme immer wieder die Meldung "Undefined subroutine &Modbus::ModbusPluggit_Eval". Hier mal der Auszug aus dem Logfile:


2022.10.03 13:18:09 5: AP300: CreateDataObjects unpacked 10151511 with CCCC to 16, 21, 21, 17
2022.10.03 13:18:09 5: AP300: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};sprintf("%d %d %d %d",
             $val[0],
             $val[1],
             $val[2],
             $val[3]) to 16 21 21 17
2022.10.03 13:18:09 5: AP300: CreateDataObjects is calling ModbusReadingsFn via TryCall for reading Temperaturen and val 16 21 21 17
2022.10.03 13:18:09 3: AP300: CreateDataObjects error calling ModbusReadingsFn: Undefined subroutine &Modbus::ModbusPluggit_Eval called at ./FHEM/98_Modbus.pm line 4995.

2022.10.03 13:18:09 4: AP300: CreateDataObjects assigns value 16 21 21 17 to Temperaturen
2022.10.03 13:18:09 5: AP300: ParseDataString created 1 readings
2022.10.03 13:18:09 4: AP300: HandleResponse done, current frame / read buffer: 0103041015151121ab, id 1, fCode 3,
request: id 1, read fc 3 h1032, len 2, master device AP300, reading Temperaturen (getUpdate for Temperaturen len 2), queued 0.12 secs ago, sent 0.11 secs ago,
response: id 1, fc 3, h1032, len 2, values 10151511
2022.10.03 13:18:09 5: AP300: ResetExpect for HandleResponse from response to idle
2022.10.03 13:18:09 5: AP300: DropFrame called from ReadFn - drop 0103041015151121ab


Zum testen habeich die subroutine "ModbusPluggit_Eval" in das Modbus Modul "98_Modbus.pm" kopiert, dann werden die 4 einzelnen Readings erzeugt und das reading "Temperaturen" wird nicht mehr aktualisiert, also so wie es eigentlich sein sollte.

Momentan komme ich mit meinen beschränkten perl Fähigkeiten nicht weiter, muss ich die subroutine noch irgendwie global bekannt machen?
Bin für jeden Tip dankbar.

Gruß Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 Oktober 2022, 21:54:07
Hallo Andreas,

Das liegt am Namespace. Das Modbus-Modul hat package Modbus, Du hast package main verwendet.
Wenn Du die Funktion als String zuweist, könntest Du main:: im String davor setzen. Sauberer ist aber eine Zuweisung als Referenz auf eine Funktion wie in der Initialize-Funktion von 98_Modbus.pm

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Andy1981 am 04 Oktober 2022, 21:00:46
Hallo Stefan,

danke für die schnelle Antwort, habe jetzt main:: in den String eingefügt und es funktioniert.
Werde mir in einer ruhigen Minute mal die Initialize Funktion anschauen. Mal schauen ob ich verstehe wie die Zuweisung als Referenz funktioniert.

Gruß Andreas
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: RobertSch am 05 Oktober 2022, 07:33:19
Zitat von: StefanStrobel am 30 September 2022, 16:29:40
Hallo Robert,

ich habe mir das UMG604-Modul mal angesehen. Da fehlt etwas und deshalb konnte es nicht gehen.
Schau doch mal die Funktion ModbusUMG604_Initialize im Code an und ergänze die letzten Zeilen mit der Zuweisung an $modHash->{AttrList}

Dann sollte es so aussehen:


sub ModbusUMG604_Initialize($)
{
    my ($modHash) = @_;
$modHash->{parseInfo}  = \%UMG604parseInfo; # defines registers, inputs, coils etc. for this Modbus Defive
$modHash->{deviceInfo} = \%deviceInfo; # defines properties of the device like
# defaults and supported function codes
ModbusLD_Initialize($modHash); # Generic function of the Modbus module does the rest

        $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
}


Zudem ist es recht unglücklich, dass die Variable deviceInfo nicht den Namen des Moduls enthält. Die sollte in UMG604deviceInfo umbenannt werden um weitere Probleme zu vermeiden.
Das sind 4 Stellen, die Du mit Suchen/ersetzen korrigieren kannst.
Ich habs auch einfach mal angehängt, aber nicht getestet.

Gruss
   Stefan

Moin Stefan!

Deine Änderungen haben Wunder bewirkt! Das Modul funktioniert nun wie es soll!

Vielen lieben Dank!

Gruß
Robert

EDIT: Ich musste nochmal das Modul editieren, damit vernünftige Werte ausgespuckt werden. Jetzt passt es. Ich hänge es an, falls es jemand gebrauchen kann.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 11 Oktober 2022, 22:39:54
Hallo Stefan,

ich versuche gerade den Stromzähler SDM72DM (v2) per Modbus einzubinden.

Mit der angehängten 98_ModbusSDM72DM.pm funktioniert das auch - allerdings nur mit combine => 2.
Mit 30 werden nicht mehr alle Werte geparsed. Ein Beispiel ist die Spannung der Phase 3, welches über das Register i04 kommen soll.

Als Gegenkontrolle habe ich das wieder mit einem Modbus RTU Windows Programm geprüft. Dabei sieht die Kommunikation so aus:

Req 01 04 00 00 00 12 70 07
Res 01 04 24 00 00 00 00 00 00 00 00 43 63 69 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2B 22

Reg i4: 43636929 --> 227.41 V


In FHEM sieht das im Log so aus:


2022.10.11 22:22:41 4: StromzaehlerSDM: GetUpdate (V4.4.11 - 5.10.2022) called from Fhem internal timer
2022.10.11 22:22:41 4: StromzaehlerSDM: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 22:22:51.026, interval 10
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash full object list: i00 i02 i04 i06 i08 i10 i12 i14 i16
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i00 len 2 L1_Voltage
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i02 len 2 L2_Voltage
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i04 len 2 L3_Voltage
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i06 len 2 L1_Current
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i08 len 2 L2_Current
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i10 len 2 L3_Current
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i12 len 2 L1_Active_Power
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i14 len 2 L2_Active_Power
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateUpdateHash will request i16 len 2 L3_Active_Power
2022.10.11 22:22:41 4: StromzaehlerSDM: CombineUpdateHash objHash keys before combine: i02,i16,i06,i12,i04,i14,i00,i10,i08
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash tries to combine read commands
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash combine i00 len 2 L1_Voltage with i02 len 2 L2_Voltage to span 4, drop read for i02
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash combine i00 len 2 L1_Voltage with i04 len 2 L3_Voltage to span 6, drop read for i04
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash combine i00 len 2 L1_Voltage with i06 len 2 L1_Current to span 8, drop read for i06
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash combine i00 len 2 L1_Voltage with i08 len 2 L2_Current to span 10, drop read for i08
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash combine i00 len 2 L1_Voltage with i10 len 2 L3_Current to span 12, drop read for i10
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash combine i00 len 2 L1_Voltage with i12 len 2 L1_Active_Power to span 14, drop read for i12
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash combine i00 len 2 L1_Voltage with i14 len 2 L2_Active_Power to span 16, drop read for i14
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash combine i00 len 2 L1_Voltage with i16 len 2 L3_Active_Power to span 18, drop read for i16
2022.10.11 22:22:41 5: StromzaehlerSDM: CombineUpdateHash keys are now i00
2022.10.11 22:22:41 4: StromzaehlerSDM: GetUpdate will now create requests for i00 len 18 (combined i00 len 2 L1_Voltage with i02 len 2 L2_Voltage and i04 len 2 L3_Voltage and i06 len 2 L1_Current and i08 len 2 L2_Current and i10 len 2 L3_Current and i12 len 2 L1_Active_Power and i14 len 2 L2_Active_Power and i16 len 2 L3_Active_Power)
2022.10.11 22:22:41 4: StromzaehlerSDM: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 4 i00, len 18, master device StromzaehlerSDM, reading L1_Voltage (getUpdate for combined i00 len 2 L1_Voltage with i02 len 2 L2_Voltage and i04 len 2 L3_Voltage and i06 len 2 L1_Current and i08 len 2 L2_Current and i10 len 2 L3_Current and i12 len 2 L1_Active_Power and i14 len 2 L2_Active_Power and i16 len 2 L3_Active_Power)
2022.10.11 22:22:41 5: StromzaehlerSDM: ParseDataString called from HandleResponse with data hex 000000000000000043641266000000000000000000000000000000000000000000000000, type i, adr 00, op read
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString called from ParseDataString with data hex 000000000000000043641266000000000000000000000000000000000000000000000000, type i, adr 00, valuesLen 18, op read
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString has no information about handling i2
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString has no information about handling i3
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString has no information about handling i4
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString has no information about handling i5
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString has no information about handling i6
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString has no information about handling i7
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString has no information about handling i8
2022.10.11 22:22:41 5: StromzaehlerSDM: SplitDataString has no information about handling i9
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateDataObjects called from ParseDataString with objList i00,i10,i12,i14,i16
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateDataObjects sortedList i00,i10,i12,i14,i16
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateParseInfoCache called
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateDataObjects unpacked 00000000 with f> to 0
2022.10.11 22:22:41 5: StromzaehlerSDM: FormatVal for CreateDataObjects formats 0 with format %.01f V, result is 0.0 V
2022.10.11 22:22:41 4: StromzaehlerSDM: CreateDataObjects assigns value 0.0 V to L1_Voltage
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateParseInfoCache called
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateDataObjects unpacked 00000000 with f> to 0
2022.10.11 22:22:41 5: StromzaehlerSDM: FormatVal for CreateDataObjects formats 0 with format %.03f A, result is 0.000 A
2022.10.11 22:22:41 4: StromzaehlerSDM: CreateDataObjects assigns value 0.000 A to L3_Current
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateParseInfoCache called
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateDataObjects unpacked 00000000 with f> to 0
2022.10.11 22:22:41 5: StromzaehlerSDM: FormatVal for CreateDataObjects formats 0 with format %.01f W, result is 0.0 W
2022.10.11 22:22:41 4: StromzaehlerSDM: CreateDataObjects assigns value 0.0 W to L1_Active_Power
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateParseInfoCache called
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateDataObjects unpacked 00000000 with f> to 0
2022.10.11 22:22:41 5: StromzaehlerSDM: FormatVal for CreateDataObjects formats 0 with format %.01f W, result is 0.0 W
2022.10.11 22:22:41 4: StromzaehlerSDM: CreateDataObjects assigns value 0.0 W to L2_Active_Power
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateParseInfoCache called
2022.10.11 22:22:41 5: StromzaehlerSDM: CreateDataObjects unpacked 00000000 with f> to 0
2022.10.11 22:22:41 5: StromzaehlerSDM: FormatVal for CreateDataObjects formats 0 with format %.01f W, result is 0.0 W
2022.10.11 22:22:41 4: StromzaehlerSDM: CreateDataObjects assigns value 0.0 W to L3_Active_Power
2022.10.11 22:22:41 5: StromzaehlerSDM: ParseDataString created 5 readings


.. hier scheint es, dass von der Schnittstelle Werte kommen:
000000000000000043641266000000000000000000000000000000000000000000000000
43641266 --> 228.07 V

Wieso wird i4 (..) nicht geparsed?

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 12 Oktober 2022, 06:06:55
Zitat von: ahermann86 am 11 Oktober 2022, 22:39:54
ich versuche gerade den Stromzähler SDM72DM (v2) per Modbus einzubinden.

Hast Du mal mein Modul zum SDM72DMv2 ausprobiert?
https://forum.fhem.de/index.php/topic,75638.msg1217182.html#msg1217182 (https://forum.fhem.de/index.php/topic,75638.msg1217182.html#msg1217182)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Oktober 2022, 14:15:17
Hallo Axel,

die Schreibweise mit führenden Nullen bei den Objekten (,,i04" statt ,,i4") funktioniert bei Attributen mit zusätzlichem Aufwand. Für Module geht das nicht. Da solltest Du die 0 weglassen.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 13 Oktober 2022, 00:34:09
Hallo zusammen

@StefanStrobel:
Ohne führende 0 geht es. Danke für den Hinweis  :)

@Nobbynews:
Das ist gut zu wissen - da kann ich mir noch ein paar Werte rausklauen und muss nicht alles aus dem PDF umsetzen.

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 13 Oktober 2022, 07:34:45
Zitat von: ahermann86 am 13 Oktober 2022, 00:34:09
@Nobbynews:
Das ist gut zu wissen - da kann ich mir noch ein paar Werte rausklauen und muss nicht alles aus dem PDF umsetzen.

Hallo Axel,
warum arbeitet Ihr nicht direkt zusammen?
VG   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 13 Oktober 2022, 18:24:32
Zitat von: ch.eick am 13 Oktober 2022, 07:34:45
warum arbeitet Ihr nicht direkt zusammen?
Mein Modul läuft hier seit Ende März aus meiner Sicht perfekt.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: curt am 18 Oktober 2022, 00:34:28
Hallo @StefanStrobel
Vor einigen Tagen wurde meine neue Weishaupt-Heizung eingebaut. Im Urzustand spricht die "WEM", hat aber optional Gateways auf KNX oder Modbus TCP.

Leider habe ich momentan gar keine Ahnung ... in der Anlage das Prinzipbild. Würde das mit dem Modul Modbus zusammenspielen?

In der mir vorliegenden Doku sind jede Menge Register (auch anderer Weishaupt-Anlagen) beschrieben. Bin ich der Erste damit und muss mit diesen Registern selbst irgendwie zurechtkommen? Ich kann Dir die Doku auch gern zeigen, es sind 1,3 MB.

Entschuldigt bitte meine dummen Fragen, ich mache das zum ersten Mal und habe im Moment keine Ahnung und auch wenig Peilung.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ahermann86 am 19 Oktober 2022, 23:21:58
Zitat von: ch.eick am 13 Oktober 2022, 07:34:45
Hallo Axel,
warum arbeitet Ihr nicht direkt zusammen?
VG   Christian

Hallo,

naja - das habe ich tatsächlich übersehen, dass das schon jemand gemacht hat.
Ich werde das von Nobbynews so übernehmen.

Danke für den Hinweis  :)

Gruß
Axel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dmq am 22 Oktober 2022, 22:11:37
Hallo,

vielleicht hat hier jemand eine gute Idee:

Ich würde gerne einen Temp. LF Sensor per Modbus TCP ansteuern. Der Sensor kann selbst nur Modbus RTU. Aus diesem Grund habe ich ein Waveshare RS485 TO ETH (B) Gateway im Einsatz.

TELEGRAMME
Function 04 Read Input Register
Register Parameter Data Type Value Range
3x0001 Temperatur Abtastung 4 s Signed 16 Bit – 350...+800 – 35.0...+80.0 °C
3x0002 Temperatur Filterung 32 s Signed 16 Bit – 350...+800 – 35.0...+80.0 °C
3x0003 Relative Feuchte Abtastung 4 s Signed 16 Bit 0...1000 0.0...100.0 % r.H.
3x0004 Relative Feuchte Filterung 32 s Signed 16 Bit 0...1000 0.0...100.0 % r.H.


Der Sensor bietet die o.a. Register an. Kann mir jemand sagen, wie diese als Objekt innerhalb ModbusAttr hinterlegt werden müssten (dec o. hex?)?

defmod modbus_wsgw_1_1 ModbusAttr 1 10 X.Y.Z.A:502 TCP
attr modbus_wsgw_1_1 obj-i30001-len 1
attr modbus_wsgw_1_1 obj-i30001-poll 1
attr modbus_wsgw_1_1 obj-i30001-reading Temp
attr modbus_wsgw_1_1 obj-i30001-unpack N
attr modbus_wsgw_1_1 obj-i30002-len 1
attr modbus_wsgw_1_1 obj-i30002-poll 1
attr modbus_wsgw_1_1 obj-i30002-reading Temp2
attr modbus_wsgw_1_1 obj-i30002-unpack N
attr modbus_wsgw_1_1 verbose 5


Ich bekomme leider keine Kommunikation zu dem Sensor hin.

Im Log sehe ich das hier:

2022.10.22 22:06:52 5: modbus_wsgw_1_1: checkDelays sendDelay, last send to same device was 5.987 secs ago, required delay is 0.1
2022.10.22 22:06:52 5: modbus_wsgw_1_1: checkDelays busDelayRead, last activity on bus was 10164.422 secs ago, required delay is 0
2022.10.22 22:06:52 5: modbus_wsgw_1_1: checkDelays clientSwitchDelay is not relevant
2022.10.22 22:06:52 5: modbus_wsgw_1_1: checkDelays commDelay, last communication with same device was 10164.422 secs ago, required delay is 0.1
2022.10.22 22:06:52 4: modbus_wsgw_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 3, sending 00ad00000006010430010001 via 172.23.23.143:502, read buffer empty,
request: id 1, read fc 4 i12289, len 1, tid 173, master device modbus_wsgw_1_1, reading Temp (getUpdate for Temp len 1), queued 0.01 secs ago
2022.10.22 22:06:52 5: modbus_wsgw_1_1: Send called from ProcessRequestQueue
2022.10.22 22:06:52 5: DevIo_SimpleWrite modbus_wsgw_1_1: 00ad00000006010430010001
2022.10.22 22:06:52 5: modbus_wsgw_1_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.10.22 22:06:53 5: modbus_wsgw_1_1: ProcessRequestQueue called from Fhem internal timer as queue:modbus_wsgw_1_1, qlen 2, request: request: id 1, read fc 4 i30001, len 1, tid 98, master device modbus_wsgw_1_1, reading Temp (getUpdate for Temp len 1), queued 1.01 secs ago
2022.10.22 22:06:53 5: modbus_wsgw_1_1: ProcessRequestQueue will return, Fhem is still waiting for response, read buffer empty,
request: id 1, read fc 4 i12289, len 1, tid 173, master device modbus_wsgw_1_1, reading Temp (getUpdate for Temp len 1), queued 1.01 secs ago, sent 1.01 secs ago, qlen 2, try again in 1 seconds
2022.10.22 22:06:53 5: modbus_wsgw_1_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds


Danke vorab
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dmq am 23 Oktober 2022, 12:29:23
Ich habe das Ganze jetzt auch mal ohne Gateway mit einem RS485 Adapter (9600,8,N,1) gemacht. Auch hier passiert nichts. Nur die rote LED beim Sensor leuchtet bei der Abfrage auf (falsches Telegram).
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 27 Oktober 2022, 11:47:39
Hallo zusammen,
ich versuche nun das erste mal einen ModBus Slave TCP zu definieren.
Hintergrund ist einen Wechselrichter am Energiemanager zu simulieren.
Die Definitionen müssen einem vorhandenen Wechselrichter entsprechen, damit der Energiemanager den Fake nicht merkt.
Somit habe ich die benötigten ModBus Register aus dem orignal WR in dem neuen ModBus Slave mit den selben Attributen als "holding Register" definiert.

Hier kommt der erste verbindungsversuch.
Zu beginn kam diese Meldung, woraufhin ich den falschen Port 71 auf 255 geändert habe

2022.10.27 11:10:19.134 3: WR_3_192.168.178.17_54130: _UnDef is closing WR_3_192.168.178.17_54130
2022.10.27 11:10:19.239 3: WR_3_192.168.178.17_54136: GetLogHash called from HandleRequest detected wrong Modbus Id 255, expecting 71
2022.10.27 11:10:19.725 3: WR_3_192.168.178.17_54136: read from TCP server connection got null -> closing
2022.10.27 11:10:19.726 3: WR_3_192.168.178.17_54136: _UnDef is closing WR_3_192.168.178.17_54136
2022.10.27 11:10:19.855 3: WR_3_192.168.178.17_54142: GetLogHash called from HandleRequest detected wrong Modbus Id 255, expecting 71


Nun kommen diese Meldungen, jedoch habe ich noch keine Ahnung worauf das hindeutet.

2022.10.27 11:12:18.139 3: WR_3: port 1502 opened
2022.10.27 11:12:18.232 3: WR_3_192.168.178.17_56106: read from TCP server connection got null -> closing
2022.10.27 11:12:18.232 3: WR_3_192.168.178.17_56106: _UnDef is closing WR_3_192.168.178.17_56106
2022.10.27 11:12:18.422 3: WR_3_192.168.178.17_56108: read from TCP server connection got null -> closing
2022.10.27 11:12:18.422 3: WR_3_192.168.178.17_56108: _UnDef is closing WR_3_192.168.178.17_56108
2022.10.27 11:12:18.607 3: WR_3_192.168.178.17_56110: read from TCP server connection got null -> closing
2022.10.27 11:12:18.607 3: WR_3_192.168.178.17_56110: _UnDef is closing WR_3_192.168.178.17_56110

Im Device finde ich dann noch das hier

stacktrace

TcpServer_Close:1712 Modbus::DoClose:903 Modbus::SetLDInactive:1196 Modbus::ControlSet:1090 Modbus::SetLDFn:3950 CallFn:1957 DoSet:1989 CommandSet:1274 AnalyzeCommand:2806 FW_fC:1028 FW_answerCall:609 FW_Read:3955 CallFn:782


Hat jemand eine Idee, wo ich weiter suchen könnte, oder was ich generell schon falsch gemacht haben?

EDIT:
Die ersten Register werden vom KSEM bereits richtig gelesen, womit ich ableite, dass die Kommunikation schon läuft, jedoch werden noch keine Leistungen gelesen.
Der Name und die Seriennummer werden im KSEM richtig angezeigt.


VG
   Christian

Hier mal das bisherige List

Internals:
   CFGFN     
   CONNECTS   78
   DEF        255 slave x.x.x.x:1502 TCP
   DeviceName x.x.x.x:1502
   EXPECT     request
   FUUID      635a4f93-f33f-61a8-de24-ef654445af0f3f58

   IODev      WR_3
   LASTCONN   WR_3_<IP des KSEM>_47132        <<<<< Der Energiemanager scheint hier schon aktiv das Device abzufragen :-)

   MODBUSID   255
   MODE       slave
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       WR_3
   NOTIFYDEV  global
   NR         555436
   NTFY_ORDER 50-WR_3
   PORT       1502
   PROTOCOL   TCP
   STATE      inactive
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   eventCount 35
   stacktrace  TcpServer_Close:1712 Modbus::DoClose:903 Modbus::SetLDInactive:1196 Modbus::ControlSet:1090 Modbus::SetLDFn:3950 CallFn:1957 DoSet:1989 CommandSet:1274 AnalyzeCommand:2806 FW_fC:1028 FW_answerCall:609 FW_Read:3955 CallFn:782
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1666862995.40365
           VALUE      opened
   READ:
   READINGS:
     2022-10-27 12:19:25   Active_P_L1     10.00
     2022-10-27 12:19:34   Active_P_L2     10.00
     2022-10-27 12:19:40   Active_P_L3     10.00
     2022-10-27 12:16:50   I_L1            0.00
     2022-10-27 12:17:01   I_L2            0.00
     2022-10-27 12:17:07   I_L3            0.00
     2022-10-27 10:56:32   Inverter_Article_number 12345678
     2022-10-27 10:56:32   Inverter_serial_number 87654321
     2022-10-27 10:56:32   Inverter_state  6
     2022-10-27 10:59:21   Productname     WR_3
     2022-10-27 10:56:32   Software-Version_IO-Controller_IOC 4711
     2022-10-27 10:56:32   Software-Version_Maincontroller_MC 0815
     2022-10-27 11:00:33   Total_AC_Active_P 0
     2022-10-27 12:17:24   U_L1            230.00
     2022-10-27 12:17:35   U_L2            230.00
     2022-10-27 12:17:44   U_L3            230.00
     2022-10-27 12:08:12   state           inactive
   REMEMBER:
     lsend      1666865292.28397
   defptr:
     WR_3       255
Attributes:
   DbLogExclude .*
   comment    Version 2022.10.27 09:00
Fremder WR am KSEM
   dev-h-combine 8
   dev-h-defFormat %.2f
   dev-h-defLen 2
   dev-h-defPoll 1
   dev-h-defRevRegs 1
   dev-h-defUnpack f>
   dev-type-STR-format %s
   dev-type-STR-len 8
   dev-type-STR-revRegs 0
   dev-type-STR-unpack a*
   disable    0
   group      PV Eigenverbrauch
   icon       sani_solar
   obj-h14-reading Inverter_serial_number
   obj-h14-type STR
   obj-h154-reading I_L1
   obj-h156-reading Active_P_L1
   obj-h158-reading U_L1
   obj-h160-reading I_L2
   obj-h162-reading Active_P_L2
   obj-h164-reading U_L2
   obj-h166-reading I_L3
   obj-h168-reading Active_P_L3
   obj-h170-reading U_L3
   obj-h172-reading Total_AC_Active_P
   obj-h38-reading Software-Version_Maincontroller_MC
   obj-h38-type STR
   obj-h46-reading Software-Version_IO-Controller_IOC
   obj-h46-type STR
   obj-h56-format %.0f
   obj-h56-reading Inverter_state
   obj-h56-unpack N
   obj-h6-reading Inverter_Article_number
   obj-h6-type STR
   obj-h768-len 32
   obj-h768-reading Productname
   obj-h768-type STR
   room       Strom->Photovoltaik
   sortby     311
   verbose    5
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: dmq am 30 Oktober 2022, 11:36:56
Zitat von: dmq am 23 Oktober 2022, 12:29:23
Ich habe das Ganze jetzt auch mal ohne Gateway mit einem RS485 Adapter (9600,8,N,1) gemacht. Auch hier passiert nichts. Nur die rote LED beim Sensor leuchtet bei der Abfrage auf (falsches Telegram).

Ich bin hartnäckig geblieben. Es funktioniert. Es hat nichts mit den Modulen oder seriellen Terminal Parametern zu tun. Eine Ader hatte keinen Kontakt. Sowohl modbus-tcp als auch modbus-rtu funktionieren nun gut.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 November 2022, 09:44:24
Hallo curt,

Wenn Du eine Dokumentation der Modbus-Schnittstelle (Register etc.) hast, sollte es kein Problem sein, die Heizung anzubinden.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 November 2022, 12:49:13
Hallo Christian,

die Meldungen mit closing zeigen nur dass der Master die Verbindung geschlossen hat.
Hast Du denn einen echten Wechselrichter, mit dem Du die gelieferten Werte und deren Format vergleichen kannst?
Ich würde im Log nachsehen, welche Requests mit welcher Länge der Energiemanager genau sendet und dann genau diese Requests zum Vergleich an den echten WR schicken.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 03 November 2022, 15:45:02
Zitat von: StefanStrobel am 03 November 2022, 12:49:13
die Meldungen mit closing zeigen nur dass der Master die Verbindung geschlossen hat.
Hast Du denn einen echten Wechselrichter, mit dem Du die gelieferten Werte und deren Format vergleichen kannst?
Ich würde im Log nachsehen, welche Requests mit welcher Länge der Energiemanager genau sendet und dann genau diese Requests zum Vergleich an den echten WR schicken.
Hallo Stefan,
ich bin mir nicht sicher, dass es ein Slave sein muss, da der original Kostal WR als Master fungiert und somit müsste auch mein Fake im FHEM ein Master sein.
Der Energiemanager muss die Daten nach meiner Kenntnis beim Master abholen.
In Node-Red hat die PV Community das ganze bereits am laufen, das habe ich auch bereits konfiguriert und werde da mal genauer rein schauen.
EDIT: Dort werden die Messwerte aktiv zum KSEM gesendet.

Ansonsten sind die ModBus Definitionen bereits eine Kopie des original WRs, den ich in FHEM konfiguriert habe.

Vielen Dank für die Rückmeldung
    Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 04 November 2022, 10:11:26
Zitat von: StefanStrobel am 03 November 2022, 12:49:13
die Meldungen mit closing zeigen nur dass der Master die Verbindung geschlossen hat.
Hast Du denn einen echten Wechselrichter, mit dem Du die gelieferten Werte und deren Format vergleichen kannst?
Ich würde im Log nachsehen, welche Requests mit welcher Länge der Energiemanager genau sendet und dann genau diese Requests zum Vergleich an den echten WR schicken.
Hallo zusammen,
leider komme ich nicht weiter.

im Node-Red habe ich eine lauffähige Konfiguration

- Dort ist ein "ModBus Server" definiert, der die eigene IP-Adresse und Port 1502 verwendet.
- Dann ist "ModBus-Flex-Write" definiert, dass die Werte anscheinen sendet.
  Auch dort ist die eigene IP-Adresse und Port 1502 konfiguriert, zusätzlich die UnitID


Mit meiner bisherigen Definition in FHEM als Slave bekomme ich den Productname und die Seriennummer meines Fakes im Energiemanger angezeigt, aber die gewünschten Werte werden nicht übermittelt/abgeholt. Der original WR ist als ModBus Master im Netz.
Testweise habe ich ein Register mit "obj-h172-set 1" versehen, was aber auch nicht weiter geholfen hat.

Wenn ich in FHEM einen Modbus Master TCP definiere bekomme ich kein connect.

Ich bräuchte da mal etwas Hilfe
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: curt am 05 November 2022, 02:54:24
Zitat von: StefanStrobel am 03 November 2022, 09:44:24
Wenn Du eine Dokumentation der Modbus-Schnittstelle (Register etc.) hast, sollte es kein Problem sein, die Heizung anzubinden.

Hallo Stefan,
ich bin mir nicht sicher, ob die mir vorliegende Doku ausreichend ist. Ich hänge einen Screenshot sowie  das komplette Dokument an.

Deine Einschätzung ist mir wichtig: Das zusätzliche Modul kostet inkl. Installation vmtl. über 1.000 Euro. Selbstverständlich ist das schlussendlich meine Verantwortung, diese delegiere ich NICHT an Dich. Aber mir wäre deutlich wohler, wenn Du da mal kurz drüber schaust. Und mir sagst, ob das in etwa so aussehen sollte.

Ich danke Dir sehr!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 06 November 2022, 22:42:15
Hallo,

ich habe jetzt schon vieles durchgelesen, komme aber nicht weiter.

Ich erhalte über MQTT Temperaturwerte.

define Temperatur_Heizung MQTT_DEVICE
attr Temperatur_Heizung IODev myBroker
attr Temperatur_Heizung devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Temperatur_Heizung room Heizung
attr Temperatur_Heizung subscribeReading_Temperatur_Heizung HC/Heizung/Temp_Heizung/SENSOR

define ej.Temperatur_Heizung expandJSON Temperatur_Heizung:.*:.{.*}
attr ej.Temperatur_Heizung room Heizung
attr ej.Temperatur_Heizung verbose 1


define MQTT_Heizung_Temp_senden MQTT_BRIDGE Temperatur_Heizung
attr MQTT_Heizung_Temp_senden IODev myBroker
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-1_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-1_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-2_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-2_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-3_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-3_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-4_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-4_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-5_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-5_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-6_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-6_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-7_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-7_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-8_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-8_Temperature
attr MQTT_Heizung_Temp_senden room Heizung



Diese Temperaturen sollen nun über Modbus TCP an eine Micro 820 gesendet werden.

Wie sieht die Definition für den Sendevorgang der Temperaturwerte aus?

Schon mal vielen Dank für die Antwort.

MfG Mario
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 November 2022, 18:17:46
Zitat von: ch.eick am 04 November 2022, 10:11:26
im Node-Red habe ich eine lauffähige Konfiguration

- Dort ist ein "ModBus Server" definiert, der die eigene IP-Adresse und Port 1502 verwendet.
- Dann ist "ModBus-Flex-Write" definiert, dass die Werte anscheinen sendet.
  Auch dort ist die eigene IP-Adresse und Port 1502 konfiguriert, zusätzlich die UnitID


Mit meiner bisherigen Definition in FHEM als Slave bekomme ich den Productname und die Seriennummer meines Fakes im Energiemanger angezeigt, aber die gewünschten Werte werden nicht übermittelt/abgeholt. Der original WR ist als ModBus Master im Netz.
Testweise habe ich ein Register mit "obj-h172-set 1" versehen, was aber auch nicht weiter geholfen hat.

Wenn ich in FHEM einen Modbus Master TCP definiere bekomme ich kein connect.

Hallo Christian,

zuerst müssen wir die Begriffe klären, sonst reden wir aneinander vorbei.
Ein Modbus-Master (neuerdings auch Client genannt) ist die aktive Komponente. Er fragt Werte von Slaves (neuerdings auch Server genannt) ab.
Ein Slave kann selbst keine Werte irgendwo hinschicken. Er beantwortet nur die Anfragen eines Masters.
Genauso liefert aber auch ein Master keine Werte sondern er holt sie von Slaves ab.

Wenn Dein Energiemanager (als Master = Client) Werte von dem Wechselrichter abfragt, dann muss Dein Wechselrichter ein Slave (=Server) sein.
Du kannst den Wechselrichter (Slave) von Fhem aus abfragen wenn Du mit ModbusAttr einen Master in Fhem erzeugst.

Wenn der Energiemanager (=Master) erfolgreich Werte von Fhem (=Slave) abholt und nur bestimmte Werte vom Energiemanager nicht abgeholt werden, dann wird es daran liegen, dass entweder Fhem die fehlenden Werte gar nicht liefert (unvollständige Konfiguration) oder dass Fhem die Werte nicht in dem vom Energiemanager erwarteten Format liefert (z.B. unpack code falsch, Länge falsch etc.).

Zitat
ich bin mir nicht sicher, dass es ein Slave sein muss, da der original Kostal WR als Master fungiert und somit müsste auch mein Fake im FHEM ein Master sein.
Der Energiemanager muss die Daten nach meiner Kenntnis beim Master abholen.
...
Der original WR ist als ModBus Master im Netz
Das passt so nicht. wie kommst Du darauf, dass der WR ein Master ist? Von welchem Slave fragt er Werte ab?
Ich würde vermuten, dass der WR ein Slave ist, den Du mit Fhem abfragen kannst, wenn Du ModbusAttr als Master definierst.
Ein Modbus-TCP-Master öffnet als TCP Client eine TCP-Verbindung zu einem Modbus-TCP-Slave als TCP-Server, der den Port 502 oder auch 1502 o.ä. geöffnet hat und dort auf eingehende Verbindungen wartet. Ein Slave kann von sich aus keine Verbindung zu einem Master aufbauen. Er beantwortet nur die Requests eines Masters.
Genau so wird Dein Energiemanager als Master den WR als Slave abfragen können.

Wenn wir mal davon ausgehen, dass dem so ist, dann bringt es auch nichts wenn Du die Attribute eines Fhem-Master-Devices, mit dem Du den WR abfragen kannst, zu einem Slave kopierst.
Satt dessen musst Du herausfinden, welche Requests der Energiemanager an den WR stellt und wie genau der WR darauf antwortet. Diese Antworten musst Du dann Deinem Fake beibringen.
Dazu würde ich folgendes tun:
1) den Slave in Fhem auf verbose 5 stellen und die eingehenden Requests vom Energiemanager mit Function code, Adresse und Länge notieren (z.B. fc4 auf i123 mit len 4, fc3 auf h234 mit len 1, ...)
2) Fhem als Master konfigurieren und genau solche Requests an den echten WR schicken. Ein input register muss dabei auch ein input register bleiben und darf kein holding register werden und wenn der Energiemanager 5 Register auf einmal - also Länge 5 - abfragt, dann musst Du das genauso mit len 5 machen. Dabei verbose auf 5
3) die Antworten des echten WR (Objekte mit Längen und Werten) im Fhem-Log suchen und notieren
4) daraus die Konfiguration des Fake WR Slaves in Fhem mit festen Werten (zum Testen) ableiten und Objekt für Objekt vergleichen, ob Fhem die gleichen Antworten schickt wie der der original WR.

Wenn Du das Schritt für Schritt machst und die vollständigen Konfigurationen und Logs postest, bekommen wir das hin :-)

Gruss
   Stefan




Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 November 2022, 18:25:31
Zitat von: curt am 05 November 2022, 02:54:24
Deine Einschätzung ist mir wichtig: Das zusätzliche Modul kostet inkl. Installation vmtl. über 1.000 Euro. Selbstverständlich ist das schlussendlich meine Verantwortung, diese delegiere ich NICHT an Dich. Aber mir wäre deutlich wohler, wenn Du da mal kurz drüber schaust. Und mir sagst, ob das in etwa so aussehen sollte.

Hallo curt,
meiner Meinung nach sollte das funktionieren.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 November 2022, 18:55:40
Zitat von: Mariomgn am 06 November 2022, 22:42:15
Diese Temperaturen sollen nun über Modbus TCP an eine Micro 820 gesendet werden.
Wie sieht die Definition für den Sendevorgang der Temperaturwerte aus?

Hallo Mario,

wenn Du die Werte wirklich "senden" möchtest, dann müsste Deine SPS als Modbus-Slave entsprechende Holding-Register bereitstellen, die Du dann von Fhem aus als Master per function code 6 oder 16 dort hineinschreibst.
Der übliche Weg bei Modbus wäre aber anders herum, dass Fhem als Modbus-Slave konfiguriert wird und die Werte als Input-Register Deiner Wahl anbietet. Die SPS würde dann als Master lesend auf diese Input-Register zugreifen.

siehe https://wiki.fhem.de/wiki/ModbusAttr#Define_as_Modbus_slave
und https://wiki.fhem.de/wiki/ModbusAttr#Configuration_of_the_module_as_Modbus_slave

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 07 November 2022, 22:39:26
Hallo Stefan,

danke für die Antwort.

ist das Ganze so richtig aufgebaut?

define Data4PLC ModbusAttr 6 slave 192.xxx.0.xxx:502 TCP
attr Data4PLC userattr obj-h101-len obj-h101-reading obj-h101-unpack
attr Data4PLC obj-h101-len 2
attr Data4PLC obj-h101-reading Temperatur_Heizung:DS18B20-7_Temperature
attr Data4PLC obj-h101-unpack f
attr Data4PLC room Modbus


Die SPS sagt mir folgenden Fehler "Network connection fail to establish before timeout"

Muss man bei dem Raspberry Pi noch den Port 502 freigeben?

mfg Mario
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 08 November 2022, 18:43:04
Hallo Mario,

normalerweise kann ein Prozess unter Unix/Linux keine Listening-Ports <= 1024 öffnen wenn er nicht als root läuft.
Die einfachste Lösung ist einen höheren Port wie 1502 zu nehmen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 12 November 2022, 23:30:55
also, nach langem testen und forschen, komme ich nun gar nicht mehr weiter :-(

Die Verbindung zwischen Fhem und Micro 820 scheint zu klappen.

Port 1502 habe ich auf beiden Seiten eingestellt.

Die SPS (Master) liest aus dem Register 40022. Das habe ich mit Modscan getestet.

In Fhem sieht das Ganze so aus:
define Data4PLC ModbusAttr 6 slave 192.xxx.0.xxx:1502 TCP
attr Data4PLC userattr obj-h40022-allowWrite obj-h40022-len obj-h40022-reading obj-h40022-unpack
attr Data4PLC obj-h40022-allowWrite 1
attr Data4PLC obj-h40022-len 2
attr Data4PLC obj-h40022-reading TEMP_GARTEN
attr Data4PLC obj-h40022-unpack f
attr Data4PLC room Modbus


oder

define Data4PLC ModbusAttr 4 slave 192.xxx.0.xxx:1502 TCP
attr Data4PLC userattr obj-h0022-allowWrite obj-h0022-len obj-h0022-reading obj-h0022-unpack
attr Data4PLC obj-h0022-allowWrite 1
attr Data4PLC obj-h0022-len 2
attr Data4PLC obj-h0022-reading TEMP_GARTEN
attr Data4PLC obj-h0022-unpack f
attr Data4PLC room Modbus


Das Kommuniziert irgend wie nicht richtig.


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 November 2022, 12:28:25
Hallo Mario,

wenn etwas nicht klappt, ist es meist hilfreich, verbose für Dein Data4PLC-Device auf 5 zu stellen und das Log anzusehen. Da solltest Du alle Antworten finden ;-)
Poste einfach mal einen großen Auszug aus dem Log, in dem man sieht, wie die Verbindung angenommen wird, was das Fhem-Modul damit macht etc.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 13 November 2022, 14:48:51
Hallo Stefan,

hier ein Auszug von dem Log.
2022.11.13 14:44:19 5: Data4PLC: Open called for listening to a TCP connection
2022.11.13 14:44:19 5: Data4PLC: Close called from Open with noState
2022.11.13 14:44:19 4: Data4PLC: Close TCP server socket, now look for active connections
2022.11.13 14:44:19 4: Data4PLC: Close deleted CONNECTHASH
2022.11.13 14:44:19 3: Data4PLC: port 1502 opened
2022.11.13 14:45:17 3: Data4PLC: defined with id 6, protocol TCP, mode slave, listening at 192.168.0.251:1502
2022.11.13 14:45:17 4: Data4PLC: Notify / Init: opening connection
2022.11.13 14:45:17 5: Data4PLC: Open called for listening to a TCP connection
2022.11.13 14:45:17 3: Data4PLC: TcpServerOpen returned Data4PLC: Can't open server port at 1502: Cannot assign requested address
2022.11.13 14:45:17 5: Data4PLC: UpdateSetList: setList=reconnect:noArg saveAsModule
2022.11.13 14:45:17 5: Data4PLC: UpdateSetList: getList=
2022.11.13 14:45:17 1: ERROR: Select error -1 (9), error count= 0
2022.11.13 14:45:17 1: Found and deleted bad fileno for Data4PLC.1502
2022.11.13 14:45:24 5: Data4PLC: Open called for listening to a TCP connection
2022.11.13 14:45:24 5: Data4PLC: Close called from Open with noState
2022.11.13 14:45:24 4: Data4PLC: Close TCP server socket, now look for active connections
2022.11.13 14:45:24 4: Data4PLC: Close deleted CONNECTHASH
2022.11.13 14:45:24 3: Data4PLC: TcpServerOpen returned Data4PLC: Can't open server port at 1502: Cannot assign requested address
2022.11.13 14:45:37 3: Data4PLC: defined with id 6, protocol TCP, mode slave, listening at 192.168.0.150:1502
2022.11.13 14:45:37 4: Data4PLC: Notify / Init: opening connection
2022.11.13 14:45:37 5: Data4PLC: Open called for listening to a TCP connection
2022.11.13 14:45:37 3: Data4PLC: port 1502 opened
2022.11.13 14:45:37 5: Data4PLC: UpdateSetList: setList=reconnect:noArg saveAsModule
2022.11.13 14:45:37 5: Data4PLC: UpdateSetList: getList=
2022.11.13 14:45:54 4: Connection accepted from Data4PLC_192.168.0.250_30134
2022.11.13 14:45:54 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30134
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30134: attr change set updateGetSetList to 1
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30134: read buffer: 008700000006ff0400000019
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30134: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 135, dlen 6 and data 00000019
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30134: HandleRequest called from Read
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30134: ParseRequest called from HandleRequest
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30134: HandleRequest request: id 255, fCode 4, tid 135, type i, adr 0, len 25, Current read buffer: 008700000006ff0400000019, Id 255, fCode 4, tid 135
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30134: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30134: 255 is not one of our Modbus Ids
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30134: RequestDone request: id 255, fCode 4, tid 135, type i, adr 0, len 25, Current read buffer: 008700000006ff0400000019, Id 255, fCode 4, tid 135
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30134: DropFrame - drop 008700000006ff0400000019
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30134: read from TCP server connection got null -> closing
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30134: _UnDef is closing Data4PLC_192.168.0.250_30134
2022.11.13 14:45:55 4: Connection accepted from Data4PLC_192.168.0.250_30135
2022.11.13 14:45:55 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30135
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30135: attr change set updateGetSetList to 1
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30135: read buffer: 008800000006ff0400000019
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30135: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 136, dlen 6 and data 00000019
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30135: HandleRequest called from Read
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30135: ParseRequest called from HandleRequest
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30135: HandleRequest request: id 255, fCode 4, tid 136, type i, adr 0, len 25, Current read buffer: 008800000006ff0400000019, Id 255, fCode 4, tid 136
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30135: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30135: 255 is not one of our Modbus Ids
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30135: RequestDone request: id 255, fCode 4, tid 136, type i, adr 0, len 25, Current read buffer: 008800000006ff0400000019, Id 255, fCode 4, tid 136
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30135: DropFrame - drop 008800000006ff0400000019
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30135: read from TCP server connection got null -> closing
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30135: _UnDef is closing Data4PLC_192.168.0.250_30135
2022.11.13 14:45:55 4: Connection accepted from Data4PLC_192.168.0.250_30136
2022.11.13 14:45:55 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30136
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30136: attr change set updateGetSetList to 1
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30136: read buffer: 008900000006ff0400000019
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30136: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 137, dlen 6 and data 00000019
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30136: HandleRequest called from Read
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30136: ParseRequest called from HandleRequest
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30136: HandleRequest request: id 255, fCode 4, tid 137, type i, adr 0, len 25, Current read buffer: 008900000006ff0400000019, Id 255, fCode 4, tid 137
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30136: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30136: 255 is not one of our Modbus Ids
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30136: RequestDone request: id 255, fCode 4, tid 137, type i, adr 0, len 25, Current read buffer: 008900000006ff0400000019, Id 255, fCode 4, tid 137
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30136: DropFrame - drop 008900000006ff0400000019
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30136: read from TCP server connection got null -> closing
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30136: _UnDef is closing Data4PLC_192.168.0.250_30136
2022.11.13 14:45:55 4: Connection accepted from Data4PLC_192.168.0.250_30137
2022.11.13 14:45:55 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30137
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30137: attr change set updateGetSetList to 1
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30137: read buffer: 008a00000006ff0400000019
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30137: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 138, dlen 6 and data 00000019
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30137: HandleRequest called from Read
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30137: ParseRequest called from HandleRequest
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30137: HandleRequest request: id 255, fCode 4, tid 138, type i, adr 0, len 25, Current read buffer: 008a00000006ff0400000019, Id 255, fCode 4, tid 138
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30137: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30137: 255 is not one of our Modbus Ids
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30137: RequestDone request: id 255, fCode 4, tid 138, type i, adr 0, len 25, Current read buffer: 008a00000006ff0400000019, Id 255, fCode 4, tid 138
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30137: DropFrame - drop 008a00000006ff0400000019
2022.11.13 14:45:56 3: Data4PLC_192.168.0.250_30137: read from TCP server connection got null -> closing
2022.11.13 14:45:56 3: Data4PLC_192.168.0.250_30137: _UnDef is closing Data4PLC_192.168.0.250_30137
2022.11.13 14:45:56 4: Connection accepted from Data4PLC_192.168.0.250_30138
2022.11.13 14:45:56 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30138
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30138: attr change set updateGetSetList to 1
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30138: read buffer: 008b00000006ff0400000019
2022.11.13 14:45:56 4: Data4PLC_192.168.0.250_30138: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 139, dlen 6 and data 00000019
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30138: HandleRequest called from Read
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30138: ParseRequest called from HandleRequest
2022.11.13 14:45:56 4: Data4PLC_192.168.0.250_30138: HandleRequest request: id 255, fCode 4, tid 139, type i, adr 0, len 25, Current read buffer: 008b00000006ff0400000019, Id 255, fCode 4, tid 139
2022.11.13 14:45:56 3: Data4PLC_192.168.0.250_30138: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:45:56 4: Data4PLC_192.168.0.250_30138: 255 is not one of our Modbus Ids
2022.11.13 14:45:56 4: Data4PLC_192.168.0.250_30138: RequestDone request: id 255, fCode 4, tid 139, type i, adr 0, len 25, Current read buffer: 008b00000006ff0400000019, Id 255, fCode 4, tid 139
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30138: DropFrame - drop 008b00000006ff0400000019
2022.11.13 14:45:56 3: Data4PLC_192.168.0.250_30138: read from TCP server connection got null -> closing
2022.11.13 14:45:56 3: Data4PLC_192.168.0.250_30138: _UnDef is closing Data4PLC_192.168.0.250_30138
2022.11.13 14:45:56 4: Connection accepted from Data4PLC_192.168.0.250_30139
2022.11.13 14:45:56 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30139
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30139: attr change set updateGetSetList to 1
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30139: read buffer: 008c00000006ff0400000019
2022.11.13 14:45:56 4: Data4PLC_192.168.0.250_30139: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 140, dlen 6 and data 00000019
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30139: HandleRequest called from Read
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30139: ParseRequest called from HandleRequest
2022.11.13 14:45:56 4: Data4PLC_192.168.0.250_30139: HandleRequest request: id 255, fCode 4, tid 140, type i, adr 0, len 25, Current read buffer: 008c00000006ff0400000019, Id 255, fCode 4, tid 140
2022.11.13 14:45:56 3: Data4PLC_192.168.0.250_30139: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:45:56 4: Data4PLC_192.168.0.250_30139: 255 is not one of our Modbus Ids
2022.11.13 14:45:56 4: Data4PLC_192.168.0.250_30139: RequestDone request: id 255, fCode 4, tid 140, type i, adr 0, len 25, Current read buffer: 008c00000006ff0400000019, Id 255, fCode 4, tid 140
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30139: DropFrame - drop 008c00000006ff0400000019
2022.11.13 14:45:56 3: Data4PLC_192.168.0.250_30139: read from TCP server connection got null -> closing
2022.11.13 14:45:56 3: Data4PLC_192.168.0.250_30139: _UnDef is closing Data4PLC_192.168.0.250_30139
2022.11.13 14:45:56 4: Connection accepted from Data4PLC_192.168.0.250_30140
2022.11.13 14:45:56 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30140
2022.11.13 14:45:56 5: Data4PLC_192.168.0.250_30140: attr change set updateGetSetList to 1
2022.11.13 14:45:59 3: Data4PLC_192.168.0.250_30140: read from TCP server connection got null -> closing
2022.11.13 14:45:59 3: Data4PLC_192.168.0.250_30140: _UnDef is closing Data4PLC_192.168.0.250_30140
2022.11.13 14:45:59 4: Connection accepted from Data4PLC_192.168.0.250_30141
2022.11.13 14:45:59 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30141
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30141: attr change set updateGetSetList to 1
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30141: read buffer: 008e00000006ff0400000019
2022.11.13 14:45:59 4: Data4PLC_192.168.0.250_30141: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 142, dlen 6 and data 00000019
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30141: HandleRequest called from Read
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30141: ParseRequest called from HandleRequest
2022.11.13 14:45:59 4: Data4PLC_192.168.0.250_30141: HandleRequest request: id 255, fCode 4, tid 142, type i, adr 0, len 25, Current read buffer: 008e00000006ff0400000019, Id 255, fCode 4, tid 142
2022.11.13 14:45:59 3: Data4PLC_192.168.0.250_30141: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:45:59 4: Data4PLC_192.168.0.250_30141: 255 is not one of our Modbus Ids
2022.11.13 14:45:59 4: Data4PLC_192.168.0.250_30141: RequestDone request: id 255, fCode 4, tid 142, type i, adr 0, len 25, Current read buffer: 008e00000006ff0400000019, Id 255, fCode 4, tid 142
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30141: DropFrame - drop 008e00000006ff0400000019
2022.11.13 14:45:59 3: Data4PLC_192.168.0.250_30141: read from TCP server connection got null -> closing
2022.11.13 14:45:59 3: Data4PLC_192.168.0.250_30141: _UnDef is closing Data4PLC_192.168.0.250_30141
2022.11.13 14:45:59 4: Connection accepted from Data4PLC_192.168.0.250_30142
2022.11.13 14:45:59 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30142
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30142: attr change set updateGetSetList to 1
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30142: read buffer: 008f00000006ff0400000019
2022.11.13 14:45:59 4: Data4PLC_192.168.0.250_30142: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 143, dlen 6 and data 00000019
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30142: HandleRequest called from Read
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30142: ParseRequest called from HandleRequest
2022.11.13 14:45:59 4: Data4PLC_192.168.0.250_30142: HandleRequest request: id 255, fCode 4, tid 143, type i, adr 0, len 25, Current read buffer: 008f00000006ff0400000019, Id 255, fCode 4, tid 143
2022.11.13 14:45:59 3: Data4PLC_192.168.0.250_30142: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:45:59 4: Data4PLC_192.168.0.250_30142: 255 is not one of our Modbus Ids
2022.11.13 14:45:59 4: Data4PLC_192.168.0.250_30142: RequestDone request: id 255, fCode 4, tid 143, type i, adr 0, len 25, Current read buffer: 008f00000006ff0400000019, Id 255, fCode 4, tid 143
2022.11.13 14:45:59 5: Data4PLC_192.168.0.250_30142: DropFrame - drop 008f00000006ff0400000019
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30142: read from TCP server connection got null -> closing
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30142: _UnDef is closing Data4PLC_192.168.0.250_30142
2022.11.13 14:46:00 4: Connection accepted from Data4PLC_192.168.0.250_30143
2022.11.13 14:46:00 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30143
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30143: attr change set updateGetSetList to 1
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30143: read buffer: 009000000006ff0400000019
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30143: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 144, dlen 6 and data 00000019
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30143: HandleRequest called from Read
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30143: ParseRequest called from HandleRequest
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30143: HandleRequest request: id 255, fCode 4, tid 144, type i, adr 0, len 25, Current read buffer: 009000000006ff0400000019, Id 255, fCode 4, tid 144
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30143: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30143: 255 is not one of our Modbus Ids
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30143: RequestDone request: id 255, fCode 4, tid 144, type i, adr 0, len 25, Current read buffer: 009000000006ff0400000019, Id 255, fCode 4, tid 144
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30143: DropFrame - drop 009000000006ff0400000019
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30143: read from TCP server connection got null -> closing
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30143: _UnDef is closing Data4PLC_192.168.0.250_30143
2022.11.13 14:46:00 4: Connection accepted from Data4PLC_192.168.0.250_30144
2022.11.13 14:46:00 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30144
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30144: attr change set updateGetSetList to 1
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30144: read buffer: 009100000006ff0400000019
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30144: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 145, dlen 6 and data 00000019
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30144: HandleRequest called from Read
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30144: ParseRequest called from HandleRequest
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30144: HandleRequest request: id 255, fCode 4, tid 145, type i, adr 0, len 25, Current read buffer: 009100000006ff0400000019, Id 255, fCode 4, tid 145
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30144: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30144: 255 is not one of our Modbus Ids
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30144: RequestDone request: id 255, fCode 4, tid 145, type i, adr 0, len 25, Current read buffer: 009100000006ff0400000019, Id 255, fCode 4, tid 145
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30144: DropFrame - drop 009100000006ff0400000019
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30144: read from TCP server connection got null -> closing
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30144: _UnDef is closing Data4PLC_192.168.0.250_30144
2022.11.13 14:46:00 4: Connection accepted from Data4PLC_192.168.0.250_30145
2022.11.13 14:46:00 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30145
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30145: attr change set updateGetSetList to 1
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30145: read buffer: 009200000006ff0400000019
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30145: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 146, dlen 6 and data 00000019
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30145: HandleRequest called from Read
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30145: ParseRequest called from HandleRequest
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30145: HandleRequest request: id 255, fCode 4, tid 146, type i, adr 0, len 25, Current read buffer: 009200000006ff0400000019, Id 255, fCode 4, tid 146
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30145: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30145: 255 is not one of our Modbus Ids
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30145: RequestDone request: id 255, fCode 4, tid 146, type i, adr 0, len 25, Current read buffer: 009200000006ff0400000019, Id 255, fCode 4, tid 146
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30145: DropFrame - drop 009200000006ff0400000019
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30145: read from TCP server connection got null -> closing
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30145: _UnDef is closing Data4PLC_192.168.0.250_30145
2022.11.13 14:46:00 4: Connection accepted from Data4PLC_192.168.0.250_30146
2022.11.13 14:46:00 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30146
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30146: attr change set updateGetSetList to 1
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30146: read buffer: 009300000006ff0400000019
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30146: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 147, dlen 6 and data 00000019
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30146: HandleRequest called from Read
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30146: ParseRequest called from HandleRequest
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30146: HandleRequest request: id 255, fCode 4, tid 147, type i, adr 0, len 25, Current read buffer: 009300000006ff0400000019, Id 255, fCode 4, tid 147
2022.11.13 14:46:00 3: Data4PLC_192.168.0.250_30146: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30146: 255 is not one of our Modbus Ids
2022.11.13 14:46:00 4: Data4PLC_192.168.0.250_30146: RequestDone request: id 255, fCode 4, tid 147, type i, adr 0, len 25, Current read buffer: 009300000006ff0400000019, Id 255, fCode 4, tid 147
2022.11.13 14:46:00 5: Data4PLC_192.168.0.250_30146: DropFrame - drop 009300000006ff0400000019
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30146: read from TCP server connection got null -> closing
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30146: _UnDef is closing Data4PLC_192.168.0.250_30146
2022.11.13 14:46:01 4: Connection accepted from Data4PLC_192.168.0.250_30147
2022.11.13 14:46:01 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30147
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30147: attr change set updateGetSetList to 1
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30147: read buffer: 009400000006ff0400000019
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30147: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 148, dlen 6 and data 00000019
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30147: HandleRequest called from Read
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30147: ParseRequest called from HandleRequest
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30147: HandleRequest request: id 255, fCode 4, tid 148, type i, adr 0, len 25, Current read buffer: 009400000006ff0400000019, Id 255, fCode 4, tid 148
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30147: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30147: 255 is not one of our Modbus Ids
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30147: RequestDone request: id 255, fCode 4, tid 148, type i, adr 0, len 25, Current read buffer: 009400000006ff0400000019, Id 255, fCode 4, tid 148
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30147: DropFrame - drop 009400000006ff0400000019
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30147: read from TCP server connection got null -> closing
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30147: _UnDef is closing Data4PLC_192.168.0.250_30147
2022.11.13 14:46:01 4: Connection accepted from Data4PLC_192.168.0.250_30148
2022.11.13 14:46:01 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30148
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30148: attr change set updateGetSetList to 1
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30148: read buffer: 009500000006ff0400000019
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30148: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 149, dlen 6 and data 00000019
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30148: HandleRequest called from Read
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30148: ParseRequest called from HandleRequest
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30148: HandleRequest request: id 255, fCode 4, tid 149, type i, adr 0, len 25, Current read buffer: 009500000006ff0400000019, Id 255, fCode 4, tid 149
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30148: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30148: 255 is not one of our Modbus Ids
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30148: RequestDone request: id 255, fCode 4, tid 149, type i, adr 0, len 25, Current read buffer: 009500000006ff0400000019, Id 255, fCode 4, tid 149
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30148: DropFrame - drop 009500000006ff0400000019
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30148: read from TCP server connection got null -> closing
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30148: _UnDef is closing Data4PLC_192.168.0.250_30148
2022.11.13 14:46:01 4: Connection accepted from Data4PLC_192.168.0.250_30149
2022.11.13 14:46:01 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30149
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30149: attr change set updateGetSetList to 1
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30149: read buffer: 009600000006ff0400000019
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30149: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 150, dlen 6 and data 00000019
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30149: HandleRequest called from Read
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30149: ParseRequest called from HandleRequest
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30149: HandleRequest request: id 255, fCode 4, tid 150, type i, adr 0, len 25, Current read buffer: 009600000006ff0400000019, Id 255, fCode 4, tid 150
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30149: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30149: 255 is not one of our Modbus Ids
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30149: RequestDone request: id 255, fCode 4, tid 150, type i, adr 0, len 25, Current read buffer: 009600000006ff0400000019, Id 255, fCode 4, tid 150
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30149: DropFrame - drop 009600000006ff0400000019
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30149: read from TCP server connection got null -> closing
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30149: _UnDef is closing Data4PLC_192.168.0.250_30149
2022.11.13 14:46:01 4: Connection accepted from Data4PLC_192.168.0.250_30150
2022.11.13 14:46:01 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30150
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30150: attr change set updateGetSetList to 1
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30150: read buffer: 009700000006ff0400000019
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30150: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 151, dlen 6 and data 00000019
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30150: HandleRequest called from Read
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30150: ParseRequest called from HandleRequest
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30150: HandleRequest request: id 255, fCode 4, tid 151, type i, adr 0, len 25, Current read buffer: 009700000006ff0400000019, Id 255, fCode 4, tid 151
2022.11.13 14:46:01 3: Data4PLC_192.168.0.250_30150: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30150: 255 is not one of our Modbus Ids
2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30150: RequestDone request: id 255, fCode 4, tid 151, type i, adr 0, len 25, Current read buffer: 009700000006ff0400000019, Id 255, fCode 4, tid 151
2022.11.13 14:46:01 5: Data4PLC_192.168.0.250_30150: DropFrame - drop 009700000006ff0400000019
2022.11.13 14:46:02 3: Data4PLC_192.168.0.250_30150: read from TCP server connection got null -> closing
2022.11.13 14:46:02 3: Data4PLC_192.168.0.250_30150: _UnDef is closing Data4PLC_192.168.0.250_30150
2022.11.13 14:46:02 4: Connection accepted from Data4PLC_192.168.0.250_30151
2022.11.13 14:46:02 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30151
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30151: attr change set updateGetSetList to 1
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30151: read buffer: 009800000006ff0400000019
2022.11.13 14:46:02 4: Data4PLC_192.168.0.250_30151: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 152, dlen 6 and data 00000019
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30151: HandleRequest called from Read
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30151: ParseRequest called from HandleRequest
2022.11.13 14:46:02 4: Data4PLC_192.168.0.250_30151: HandleRequest request: id 255, fCode 4, tid 152, type i, adr 0, len 25, Current read buffer: 009800000006ff0400000019, Id 255, fCode 4, tid 152
2022.11.13 14:46:02 3: Data4PLC_192.168.0.250_30151: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:02 4: Data4PLC_192.168.0.250_30151: 255 is not one of our Modbus Ids
2022.11.13 14:46:02 4: Data4PLC_192.168.0.250_30151: RequestDone request: id 255, fCode 4, tid 152, type i, adr 0, len 25, Current read buffer: 009800000006ff0400000019, Id 255, fCode 4, tid 152
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30151: DropFrame - drop 009800000006ff0400000019
2022.11.13 14:46:02 3: Data4PLC_192.168.0.250_30151: read from TCP server connection got null -> closing
2022.11.13 14:46:02 3: Data4PLC_192.168.0.250_30151: _UnDef is closing Data4PLC_192.168.0.250_30151
2022.11.13 14:46:02 4: Connection accepted from Data4PLC_192.168.0.250_30152
2022.11.13 14:46:02 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30152
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30152: attr change set updateGetSetList to 1
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30152: read buffer: 009900000006ff0400000019
2022.11.13 14:46:02 4: Data4PLC_192.168.0.250_30152: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 153, dlen 6 and data 00000019
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30152: HandleRequest called from Read
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30152: ParseRequest called from HandleRequest
2022.11.13 14:46:02 4: Data4PLC_192.168.0.250_30152: HandleRequest request: id 255, fCode 4, tid 153, type i, adr 0, len 25, Current read buffer: 009900000006ff0400000019, Id 255, fCode 4, tid 153
2022.11.13 14:46:02 3: Data4PLC_192.168.0.250_30152: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:02 4: Data4PLC_192.168.0.250_30152: 255 is not one of our Modbus Ids
2022.11.13 14:46:02 4: Data4PLC_192.168.0.250_30152: RequestDone request: id 255, fCode 4, tid 153, type i, adr 0, len 25, Current read buffer: 009900000006ff0400000019, Id 255, fCode 4, tid 153
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30152: DropFrame - drop 009900000006ff0400000019
2022.11.13 14:46:02 3: Data4PLC_192.168.0.250_30152: read from TCP server connection got null -> closing
2022.11.13 14:46:02 3: Data4PLC_192.168.0.250_30152: _UnDef is closing Data4PLC_192.168.0.250_30152
2022.11.13 14:46:02 4: Connection accepted from Data4PLC_192.168.0.250_30153
2022.11.13 14:46:02 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30153
2022.11.13 14:46:02 5: Data4PLC_192.168.0.250_30153: attr change set updateGetSetList to 1
2022.11.13 14:46:03 5: Data4PLC: Open called for listening to a TCP connection
2022.11.13 14:46:03 5: Data4PLC: Close called from Open with noState
2022.11.13 14:46:03 4: Data4PLC: Close TCP server socket, now look for active connections
2022.11.13 14:46:03 4: Data4PLC_192.168.0.250_30153: Close TCP server connection of parent Data4PLC and delete hash
2022.11.13 14:46:03 3: Data4PLC_192.168.0.250_30153: _UnDef is closing Data4PLC_192.168.0.250_30153
2022.11.13 14:46:03 4: Data4PLC: Close deleted CONNECTHASH
2022.11.13 14:46:03 3: Data4PLC: port 1502 opened
2022.11.13 14:46:05 4: Connection accepted from Data4PLC_192.168.0.250_30154
2022.11.13 14:46:05 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30154
2022.11.13 14:46:05 5: Data4PLC_192.168.0.250_30154: attr change set updateGetSetList to 1
2022.11.13 14:46:05 5: Data4PLC_192.168.0.250_30154: read buffer: 009b00000006ff0400000019
2022.11.13 14:46:05 4: Data4PLC_192.168.0.250_30154: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 155, dlen 6 and data 00000019
2022.11.13 14:46:05 5: Data4PLC_192.168.0.250_30154: HandleRequest called from Read
2022.11.13 14:46:05 5: Data4PLC_192.168.0.250_30154: ParseRequest called from HandleRequest
2022.11.13 14:46:05 4: Data4PLC_192.168.0.250_30154: HandleRequest request: id 255, fCode 4, tid 155, type i, adr 0, len 25, Current read buffer: 009b00000006ff0400000019, Id 255, fCode 4, tid 155
2022.11.13 14:46:05 3: Data4PLC_192.168.0.250_30154: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:05 4: Data4PLC_192.168.0.250_30154: 255 is not one of our Modbus Ids
2022.11.13 14:46:05 4: Data4PLC_192.168.0.250_30154: RequestDone request: id 255, fCode 4, tid 155, type i, adr 0, len 25, Current read buffer: 009b00000006ff0400000019, Id 255, fCode 4, tid 155
2022.11.13 14:46:05 5: Data4PLC_192.168.0.250_30154: DropFrame - drop 009b00000006ff0400000019
2022.11.13 14:46:05 3: Data4PLC_192.168.0.250_30154: read from TCP server connection got null -> closing
2022.11.13 14:46:05 3: Data4PLC_192.168.0.250_30154: _UnDef is closing Data4PLC_192.168.0.250_30154
2022.11.13 14:46:05 4: Connection accepted from Data4PLC_192.168.0.250_30155
2022.11.13 14:46:05 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30155
2022.11.13 14:46:05 5: Data4PLC_192.168.0.250_30155: attr change set updateGetSetList to 1
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30155: read buffer: 009c00000006ff0400000019
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30155: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 156, dlen 6 and data 00000019
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30155: HandleRequest called from Read
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30155: ParseRequest called from HandleRequest
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30155: HandleRequest request: id 255, fCode 4, tid 156, type i, adr 0, len 25, Current read buffer: 009c00000006ff0400000019, Id 255, fCode 4, tid 156
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30155: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30155: 255 is not one of our Modbus Ids
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30155: RequestDone request: id 255, fCode 4, tid 156, type i, adr 0, len 25, Current read buffer: 009c00000006ff0400000019, Id 255, fCode 4, tid 156
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30155: DropFrame - drop 009c00000006ff0400000019
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30155: read from TCP server connection got null -> closing
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30155: _UnDef is closing Data4PLC_192.168.0.250_30155
2022.11.13 14:46:06 4: Connection accepted from Data4PLC_192.168.0.250_30156
2022.11.13 14:46:06 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30156
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30156: attr change set updateGetSetList to 1
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30156: read buffer: 009d00000006ff0400000019
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30156: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 157, dlen 6 and data 00000019
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30156: HandleRequest called from Read
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30156: ParseRequest called from HandleRequest
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30156: HandleRequest request: id 255, fCode 4, tid 157, type i, adr 0, len 25, Current read buffer: 009d00000006ff0400000019, Id 255, fCode 4, tid 157
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30156: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30156: 255 is not one of our Modbus Ids
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30156: RequestDone request: id 255, fCode 4, tid 157, type i, adr 0, len 25, Current read buffer: 009d00000006ff0400000019, Id 255, fCode 4, tid 157
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30156: DropFrame - drop 009d00000006ff0400000019
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30156: read from TCP server connection got null -> closing
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30156: _UnDef is closing Data4PLC_192.168.0.250_30156
2022.11.13 14:46:06 4: Connection accepted from Data4PLC_192.168.0.250_30157
2022.11.13 14:46:06 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30157
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30157: attr change set updateGetSetList to 1
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30157: read buffer: 009e00000006ff0400000019
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30157: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 158, dlen 6 and data 00000019
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30157: HandleRequest called from Read
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30157: ParseRequest called from HandleRequest
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30157: HandleRequest request: id 255, fCode 4, tid 158, type i, adr 0, len 25, Current read buffer: 009e00000006ff0400000019, Id 255, fCode 4, tid 158
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30157: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30157: 255 is not one of our Modbus Ids
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30157: RequestDone request: id 255, fCode 4, tid 158, type i, adr 0, len 25, Current read buffer: 009e00000006ff0400000019, Id 255, fCode 4, tid 158
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30157: DropFrame - drop 009e00000006ff0400000019
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30157: read from TCP server connection got null -> closing
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30157: _UnDef is closing Data4PLC_192.168.0.250_30157
2022.11.13 14:46:06 4: Connection accepted from Data4PLC_192.168.0.250_30158
2022.11.13 14:46:06 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30158
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30158: attr change set updateGetSetList to 1
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30158: read buffer: 009f00000006ff0400000019
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30158: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 159, dlen 6 and data 00000019
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30158: HandleRequest called from Read
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30158: ParseRequest called from HandleRequest
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30158: HandleRequest request: id 255, fCode 4, tid 159, type i, adr 0, len 25, Current read buffer: 009f00000006ff0400000019, Id 255, fCode 4, tid 159
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30158: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30158: 255 is not one of our Modbus Ids
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30158: RequestDone request: id 255, fCode 4, tid 159, type i, adr 0, len 25, Current read buffer: 009f00000006ff0400000019, Id 255, fCode 4, tid 159
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30158: DropFrame - drop 009f00000006ff0400000019
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30158: read from TCP server connection got null -> closing
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30158: _UnDef is closing Data4PLC_192.168.0.250_30158
2022.11.13 14:46:06 4: Connection accepted from Data4PLC_192.168.0.250_30159
2022.11.13 14:46:06 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30159
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30159: attr change set updateGetSetList to 1
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30159: read buffer: 00a000000006ff0400000019
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30159: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 160, dlen 6 and data 00000019
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30159: HandleRequest called from Read
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30159: ParseRequest called from HandleRequest
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30159: HandleRequest request: id 255, fCode 4, tid 160, type i, adr 0, len 25, Current read buffer: 00a000000006ff0400000019, Id 255, fCode 4, tid 160
2022.11.13 14:46:06 3: Data4PLC_192.168.0.250_30159: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30159: 255 is not one of our Modbus Ids
2022.11.13 14:46:06 4: Data4PLC_192.168.0.250_30159: RequestDone request: id 255, fCode 4, tid 160, type i, adr 0, len 25, Current read buffer: 00a000000006ff0400000019, Id 255, fCode 4, tid 160
2022.11.13 14:46:06 5: Data4PLC_192.168.0.250_30159: DropFrame - drop 00a000000006ff0400000019
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30159: read from TCP server connection got null -> closing
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30159: _UnDef is closing Data4PLC_192.168.0.250_30159
2022.11.13 14:46:07 4: Connection accepted from Data4PLC_192.168.0.250_30160
2022.11.13 14:46:07 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30160
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30160: attr change set updateGetSetList to 1
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30160: read buffer: 00a100000006ff0400000019
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30160: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 161, dlen 6 and data 00000019
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30160: HandleRequest called from Read
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30160: ParseRequest called from HandleRequest
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30160: HandleRequest request: id 255, fCode 4, tid 161, type i, adr 0, len 25, Current read buffer: 00a100000006ff0400000019, Id 255, fCode 4, tid 161
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30160: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30160: 255 is not one of our Modbus Ids
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30160: RequestDone request: id 255, fCode 4, tid 161, type i, adr 0, len 25, Current read buffer: 00a100000006ff0400000019, Id 255, fCode 4, tid 161
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30160: DropFrame - drop 00a100000006ff0400000019
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30160: read from TCP server connection got null -> closing
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30160: _UnDef is closing Data4PLC_192.168.0.250_30160
2022.11.13 14:46:07 4: Connection accepted from Data4PLC_192.168.0.250_30161
2022.11.13 14:46:07 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30161
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30161: attr change set updateGetSetList to 1
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30161: read buffer: 00a200000006ff0400000019
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30161: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 162, dlen 6 and data 00000019
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30161: HandleRequest called from Read
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30161: ParseRequest called from HandleRequest
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30161: HandleRequest request: id 255, fCode 4, tid 162, type i, adr 0, len 25, Current read buffer: 00a200000006ff0400000019, Id 255, fCode 4, tid 162
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30161: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30161: 255 is not one of our Modbus Ids
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30161: RequestDone request: id 255, fCode 4, tid 162, type i, adr 0, len 25, Current read buffer: 00a200000006ff0400000019, Id 255, fCode 4, tid 162
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30161: DropFrame - drop 00a200000006ff0400000019
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30161: read from TCP server connection got null -> closing
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30161: _UnDef is closing Data4PLC_192.168.0.250_30161
2022.11.13 14:46:07 4: Connection accepted from Data4PLC_192.168.0.250_30162
2022.11.13 14:46:07 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30162
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30162: attr change set updateGetSetList to 1
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30162: read buffer: 00a300000006ff0400000019
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30162: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 163, dlen 6 and data 00000019
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30162: HandleRequest called from Read
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30162: ParseRequest called from HandleRequest
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30162: HandleRequest request: id 255, fCode 4, tid 163, type i, adr 0, len 25, Current read buffer: 00a300000006ff0400000019, Id 255, fCode 4, tid 163
2022.11.13 14:46:07 3: Data4PLC_192.168.0.250_30162: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30162: 255 is not one of our Modbus Ids
2022.11.13 14:46:07 4: Data4PLC_192.168.0.250_30162: RequestDone request: id 255, fCode 4, tid 163, type i, adr 0, len 25, Current read buffer: 00a300000006ff0400000019, Id 255, fCode 4, tid 163
2022.11.13 14:46:07 5: Data4PLC_192.168.0.250_30162: DropFrame - drop 00a300000006ff0400000019
2022.11.13 14:46:08 4: Connection accepted from Data4PLC_192.168.0.250_30163
2022.11.13 14:46:08 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30163
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30163: attr change set updateGetSetList to 1
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30162: read from TCP server connection got null -> closing
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30162: _UnDef is closing Data4PLC_192.168.0.250_30162
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30163: read buffer: 00a400000006ff0400000019
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30163: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 164, dlen 6 and data 00000019
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30163: HandleRequest called from Read
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30163: ParseRequest called from HandleRequest
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30163: HandleRequest request: id 255, fCode 4, tid 164, type i, adr 0, len 25, Current read buffer: 00a400000006ff0400000019, Id 255, fCode 4, tid 164
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30163: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30163: 255 is not one of our Modbus Ids
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30163: RequestDone request: id 255, fCode 4, tid 164, type i, adr 0, len 25, Current read buffer: 00a400000006ff0400000019, Id 255, fCode 4, tid 164
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30163: DropFrame - drop 00a400000006ff0400000019
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30163: read from TCP server connection got null -> closing
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30163: _UnDef is closing Data4PLC_192.168.0.250_30163
2022.11.13 14:46:08 4: Connection accepted from Data4PLC_192.168.0.250_30164
2022.11.13 14:46:08 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30164
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30164: attr change set updateGetSetList to 1
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30164: read buffer: 00a500000006ff0400000019
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30164: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 165, dlen 6 and data 00000019
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30164: HandleRequest called from Read
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30164: ParseRequest called from HandleRequest
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30164: HandleRequest request: id 255, fCode 4, tid 165, type i, adr 0, len 25, Current read buffer: 00a500000006ff0400000019, Id 255, fCode 4, tid 165
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30164: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30164: 255 is not one of our Modbus Ids
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30164: RequestDone request: id 255, fCode 4, tid 165, type i, adr 0, len 25, Current read buffer: 00a500000006ff0400000019, Id 255, fCode 4, tid 165
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30164: DropFrame - drop 00a500000006ff0400000019
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30164: read from TCP server connection got null -> closing
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30164: _UnDef is closing Data4PLC_192.168.0.250_30164
2022.11.13 14:46:08 4: Connection accepted from Data4PLC_192.168.0.250_30165
2022.11.13 14:46:08 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30165
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30165: attr change set updateGetSetList to 1
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30165: read buffer: 00a600000006ff0400000019
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30165: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 166, dlen 6 and data 00000019
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30165: HandleRequest called from Read
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30165: ParseRequest called from HandleRequest
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30165: HandleRequest request: id 255, fCode 4, tid 166, type i, adr 0, len 25, Current read buffer: 00a600000006ff0400000019, Id 255, fCode 4, tid 166
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30165: GetLogHash called from HandleRequest detected wrong Modbus Id
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30165: 255 is not one of our Modbus Ids
2022.11.13 14:46:08 4: Data4PLC_192.168.0.250_30165: RequestDone request: id 255, fCode 4, tid 166, type i, adr 0, len 25, Current read buffer: 00a600000006ff0400000019, Id 255, fCode 4, tid 166
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30165: DropFrame - drop 00a600000006ff0400000019
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30165: read from TCP server connection got null -> closing
2022.11.13 14:46:08 3: Data4PLC_192.168.0.250_30165: _UnDef is closing Data4PLC_192.168.0.250_30165
2022.11.13 14:46:08 4: Connection accepted from Data4PLC_192.168.0.250_30166
2022.11.13 14:46:08 4: Data4PLC: HandleServerConnection accepted new TCP connection as device Data4PLC_192.168.0.250_30166
2022.11.13 14:46:08 5: Data4PLC_192.168.0.250_30166: attr change set updateGetSetList to 1


Fhem hängt sich übrigens nach 5 min. auf wenn das Ganze eine Verbindung hat.

MfG Mario
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 13 November 2022, 15:08:21
Ich habe gerade das 2022.11.13 14:46:01 4: Data4PLC_192.168.0.250_30148: 255 is not one of our Modbus Ids gesehen und habe mal mit ein paar Id`s gespielt... der Fehler kommt immer wieder.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 November 2022, 15:43:40
Zitat
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30134: read buffer: 008700000006ff0400000019
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30134: ParseFrameStart (TCP) extracted id 255, fCode 4, tid 135, dlen 6 and data 00000019
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30134: HandleRequest called from Read
2022.11.13 14:45:55 5: Data4PLC_192.168.0.250_30134: ParseRequest called from HandleRequest
2022.11.13 14:45:55 4: Data4PLC_192.168.0.250_30134: HandleRequest request: id 255, fCode 4, tid 135, type i, adr 0, len 25, Current read buffer: 008700000006ff0400000019, Id 255, fCode 4, tid 135
2022.11.13 14:45:55 3: Data4PLC_192.168.0.250_30134: GetLogHash called from HandleRequest detected wrong Modbus Id

das ist ziemlich eindeutig.
Dein Master schickt 008700000006ff0400000019
Das ist ein Request an Modbus-ID 255 mit fc 4, Adresse 0 und Länge 25.

Du solltest Deinem Master beibringen, dass er die richtige Modbus-ID abfragt.

Falls sich Fhem aufhängt, wäre es auch hilfreich das Log in diesem Moment zu sehen.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 13 November 2022, 17:16:12
Hallo Stefan,

danke für deine Antwort.

Modbus-ID muss 6 sein?  fc 4? auf welchen Wert sollte das stehen? Adresse ist klar. Länge sollte auf 6 stehen?!


Den Log beim Aufhängen mache ich später.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 November 2022, 17:43:15
Hallo Mario,

Zitat
Modbus-ID muss 6 sein?  fc 4? auf welchen Wert sollte das stehen? Adresse ist klar. Länge sollte auf 6 stehen?!

Das kannst Du alles selbst wählen. Master und Slave sollten sich nur einig sein.
Die Modbus-ID wird meist auf dem Slave gewählt und der Master muss sie dann übernehmen.
FC 4 ist für das Lesen von Input-Registern. Wenn der Slave Holding-Register anbietet, muss der Master die mit FC 3 lesen.
Genauso ist es mit der Länge. Der Master kann einzelne Register mit Länge 1 lesen oder mehrere auf einmal.
Am besten schaust Du Dir mal das Modbus-Protokoll an: https://www.modbus.org/specs.php

Gruss
   Stefan




Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 13 November 2022, 20:03:24
Jetzt funktioniert das  8)


2022.11.13 19:50:37 5: Data4PLC: PackObj called from CreateResponse with h 22 and valuesLen 2
2022.11.13 19:50:37 5: Data4PLC: PackObj ObjInfo for h22: reading=Temperatur_Heizung:DS18B20-7_Temperature, expr=, format=, len=6, map=, unpack=f
2022.11.13 19:50:37 4: Data4PLC: PackObj for h22 is using reading DS18B20-7_Temperature of device Temperatur_Heizung with value 74.3
2022.11.13 19:50:37 5: Data4PLC: PackObj packed 74.3 with pack code f to 9a999442
2022.11.13 19:50:37 5: Data4PLC: PackObj padded / cut object to 9a9994420000000000000000
2022.11.13 19:50:37 5: Data4PLC: PackObj counter reached 6
2022.11.13 19:50:37 5: Data4PLC: PackObj full data string is 9a9994420000000000000000
2022.11.13 19:50:37 5: Data4PLC: PackObj padded / cut data string to 9a999442
2022.11.13 19:50:37 5: Data4PLC: prepare response pdu
2022.11.13 19:50:37 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 2723 for h 22, len 2, device Data4PLC (TCP), pdu 03049a999442, V 4.1.5 - 17.9.2019
2022.11.13 19:50:37 4: Data4PLC_192.168.0.250_31150: Send 0aa3000000070603049a999442
2022.11.13 19:50:37 4: Data4PLC_192.168.0.250_31150: RequestDone request: id 6, fCode 3, tid 2723, type h, adr 22, len 2 for device Data4PLC_192.168.0.250_31150, Current read buffer: 0aa300000006060300160002, Id 6, fCode 3, tid 2723, response: id 6, fCode 3, tid 2723, type h, adr 22, len 2, value 9a999442
2022.11.13 19:50:37 5: Data4PLC_192.168.0.250_31150: DropFrame - drop 0aa300000006060300160002
2022.11.13 19:50:37 5: Data4PLC_192.168.0.250_31150: read buffer: 0aa400000006060300160002
2022.11.13 19:50:37 4: Data4PLC_192.168.0.250_31150: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 2724, dlen 6 and data 00160002
2022.11.13 19:50:37 5: Data4PLC_192.168.0.250_31150: HandleRequest called from Read
2022.11.13 19:50:37 5: Data4PLC_192.168.0.250_31150: ParseRequest called from HandleRequest
2022.11.13 19:50:37 4: Data4PLC_192.168.0.250_31150: HandleRequest request: id 6, fCode 3, tid 2724, type h, adr 22, len 2, Current read buffer: 0aa400000006060300160002, Id 6, fCode 3, tid 2724
2022.11.13 19:50:37 5: Data4PLC: CreateResponse called from HandleRequest

nur leider ist die Temperatur nicht 73,9 ° sondern   52168  und 37698  :o

Muss jetzt noch irgend etwas berechnet oder umgerechnet werden?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 13 November 2022, 20:23:22
Fehler gefunden!

attr Data4PLC obj-h22-unpack f  ist falsch und muss attr Data4PLC obj-h22-unpack n sein.


Nun zum letzten Problem.

Im Register 22 habe ich nun die Möglichkeit 125 Werte zu empfangen.

auf Pos. 1 stehen nun die 73°C.
Wie wird das in Fhem weiter definiert, wenn man noch mehr Werte in das Register 22 schreiben möchte? 22X2 funktioniert nicht.  :-\


define Data4PLC ModbusAttr 6 slave 192.168.0.150:1502 TCP
setuuid Data4PLC 63713fba-f33f-3045-2110-88b318e9d470e9d9
attr Data4PLC userattr obj-h22-len obj-h22-reading obj-h22-unpack
attr Data4PLC obj-h22-len 2
attr Data4PLC obj-h22-reading Temperatur_Heizung:DS18B20-7_Temperature
attr Data4PLC obj-h22-unpack n
attr Data4PLC obj-h22x2-len 2
attr Data4PLC obj-h22x2-reading Temperatur_Heizung:DS18B20-4_Temperature
attr Data4PLC obj-h22x2-unpack n
attr Data4PLC room Modbus


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 17 November 2022, 11:56:01
Zitat von: StefanStrobel am 07 November 2022, 18:17:46
Hallo Christian,

zuerst müssen wir die Begriffe klären, sonst reden wir aneinander vorbei.
Ein Modbus-Master (neuerdings auch Client genannt) ist die aktive Komponente. Er fragt Werte von Slaves (neuerdings auch Server genannt) ab.
Ein Slave kann selbst keine Werte irgendwo hinschicken. Er beantwortet nur die Anfragen eines Masters.
Genauso liefert aber auch ein Master keine Werte sondern er holt sie von Slaves ab.

Wenn Dein Energiemanager (als Master = Client) Werte von dem Wechselrichter abfragt, dann muss Dein Wechselrichter ein Slave (=Server) sein.
Du kannst den Wechselrichter (Slave) von Fhem aus abfragen wenn Du mit ModbusAttr einen Master in Fhem erzeugst.

Wenn der Energiemanager (=Master) erfolgreich Werte von Fhem (=Slave) abholt und nur bestimmte Werte vom Energiemanager nicht abgeholt werden, dann wird es daran liegen, dass entweder Fhem die fehlenden Werte gar nicht liefert (unvollständige Konfiguration) oder dass Fhem die Werte nicht in dem vom Energiemanager erwarteten Format liefert (z.B. unpack code falsch, Länge falsch etc.).
Das passt so nicht. wie kommst Du darauf, dass der WR ein Master ist? Von welchem Slave fragt er Werte ab?
Ich würde vermuten, dass der WR ein Slave ist, den Du mit Fhem abfragen kannst, wenn Du ModbusAttr als Master definierst.
Ein Modbus-TCP-Master öffnet als TCP Client eine TCP-Verbindung zu einem Modbus-TCP-Slave als TCP-Server, der den Port 502 oder auch 1502 o.ä. geöffnet hat und dort auf eingehende Verbindungen wartet. Ein Slave kann von sich aus keine Verbindung zu einem Master aufbauen. Er beantwortet nur die Requests eines Masters.
Genau so wird Dein Energiemanager als Master den WR als Slave abfragen können.

Wenn wir mal davon ausgehen, dass dem so ist, dann bringt es auch nichts wenn Du die Attribute eines Fhem-Master-Devices, mit dem Du den WR abfragen kannst, zu einem Slave kopierst.
Satt dessen musst Du herausfinden, welche Requests der Energiemanager an den WR stellt und wie genau der WR darauf antwortet. Diese Antworten musst Du dann Deinem Fake beibringen.
Dazu würde ich folgendes tun:
1) den Slave in Fhem auf verbose 5 stellen und die eingehenden Requests vom Energiemanager mit Function code, Adresse und Länge notieren (z.B. fc4 auf i123 mit len 4, fc3 auf h234 mit len 1, ...)
2) Fhem als Master konfigurieren und genau solche Requests an den echten WR schicken. Ein input register muss dabei auch ein input register bleiben und darf kein holding register werden und wenn der Energiemanager 5 Register auf einmal - also Länge 5 - abfragt, dann musst Du das genauso mit len 5 machen. Dabei verbose auf 5
3) die Antworten des echten WR (Objekte mit Längen und Werten) im Fhem-Log suchen und notieren
4) daraus die Konfiguration des Fake WR Slaves in Fhem mit festen Werten (zum Testen) ableiten und Objekt für Objekt vergleichen, ob Fhem die gleichen Antworten schickt wie der der original WR.
Hallo Stefan,

ich versuche mal meinen Stand und mein Verständnis zusammen zu fassen.

In FHEM habe ich den Wechselrichter so definiert und bekomme dann über ModBus alle Daten
hier habe ich das ganze bereits eingekürzt, damit es lesbar bleibt.

Als Mode wird dann im Device "master" angezeigt.
Daraus leite ich dann ab, dass der Wechselrichter ein Master ist.

defmod WR_1 ModbusAttr 71 60 192.168.178.18:1502 TCP
attr WR_1 alias WR_1
attr WR_1 alignTime 00:00
attr WR_1 comment Version 2022.03.29 09:00\
Kostal Plenticore 10 Plus mit BYD Speicher
attr WR_1 room Strom->Photovoltaik
attr WR_1 sortby 111
attr WR_1 group PV Eigenverbrauch
attr WR_1 icon sani_solar

attr WR_1 verbose 0
attr WR_1 dev-h-combine 8
attr WR_1 dev-h-defFormat %.2f
attr WR_1 dev-h-defLen 2
attr WR_1 dev-h-defRevRegs 1
attr WR_1 dev-h-defUnpack f>
attr WR_1 dev-type-STR-format %s
attr WR_1 dev-type-STR-len 8
attr WR_1 dev-type-STR-revRegs 0
attr WR_1 dev-type-STR-unpack a*

attr WR_1 obj-h14-reading Inverter_serial_number
attr WR_1 obj-h14-type STR
attr WR_1 obj-h154-reading I_L1
attr WR_1 obj-h156-reading Active_P_L1
attr WR_1 obj-h158-reading U_L1
attr WR_1 obj-h160-reading I_L2
attr WR_1 obj-h162-reading Active_P_L2
attr WR_1 obj-h164-reading U_L2
attr WR_1 obj-h166-reading I_L3
attr WR_1 obj-h168-reading Active_P_L3
attr WR_1 obj-h170-reading U_L3
attr WR_1 obj-h172-reading Total_AC_Active_P
attr WR_1 obj-h172-set 1
attr WR_1 obj-h38-reading Software-Version_Maincontroller_MC
attr WR_1 obj-h38-type STR
attr WR_1 obj-h46-reading Software-Version_IO-Controller_IOC
attr WR_1 obj-h46-type STR
attr WR_1 obj-h56-format %.0f
attr WR_1 obj-h56-reading Inverter_state
attr WR_1 obj-h56-unpack N
attr WR_1 obj-h6-reading Inverter_Article_number
attr WR_1 obj-h6-type STR
attr WR_1 obj-h768-len 32
attr WR_1 obj-h768-reading Productname
attr WR_1 obj-h768-type STR


Schaue ich mir nun die lauffähige Umsetzung im Node-Red an, wird dort ein "ModBus Server" konfiguriert
Zitat
Ein Modbus-Master (neuerdings auch Client genannt) ist die aktive Komponente. Er fragt Werte von Slaves (neuerdings auch Server genannt) ab.
Das bedeutet für mich, ich muss im FHEM einen "ModBus Slave (Server)" definieren, wodurch aber wiederum meiner Annahme von oben, dass der WR ein Master ist, falsch wäre.
Ich bin endlos verwirrt :-(

Das Ziel ist, den Node-Red Workflow in FHEM nachzubilden, damit ich von FHEM aus Messwerte zum Energiemanager (KSEM) "senden" kann.

Zitat
Wenn Dein Energiemanager (als Master = Client) Werte von dem Wechselrichter abfragt, dann muss Dein Wechselrichter ein Slave (=Server) sein.
Du kannst den Wechselrichter (Slave) von Fhem aus abfragen wenn Du mit ModbusAttr einen Master in Fhem erzeugst.
Ahh, so scheint das zu passen

Der Wechselrichter ist im FHEM mit Mode master eingetragen, somit holt FHEM die Daten ab.
Folglich holt auch der Energiemanager die Daten vom Wechselrichter ab, kann aber auch die Messwerte zum Wechselrichter schicken, denn V/A/I/P werden ja auch als Messwerte vom KSEM im Wechselrichter angezeigt.

Um nun den Fake zu machen muss ich im FHEM einen Slave (=Server) konfigurieren.

Zitat
Wenn der Energiemanager (=Master) erfolgreich Werte von Fhem (=Slave) abholt und nur bestimmte Werte vom Energiemanager nicht abgeholt werden,
dann wird es daran liegen, dass entweder Fhem die fehlenden Werte gar nicht liefert (unvollständige Konfiguration) oder dass Fhem die Werte nicht
in dem vom Energiemanager erwarteten Format liefert (z.B. unpack code falsch, Länge falsch etc.).
Die Formate habe identisch zu meinem WR_1 Device übernommen (s.o) und dort werden sie korrekt gewandelt.
Ist bei der Umwandlung die Definition nicht in beide Richtungen die selbe?

Zitat
Wenn wir mal davon ausgehen, dass dem so ist, dann bringt es auch nichts wenn Du die Attribute eines Fhem-Master-Devices, mit dem Du den WR abfragen kannst, zu einem Slave kopierst.
Statt dessen musst Du herausfinden, welche Requests der Energiemanager an den WR stellt und wie genau der WR darauf antwortet. Diese Antworten musst Du dann Deinem Fake beibringen.
Dazu würde ich folgendes tun:
1) den Slave in Fhem auf verbose 5 stellen und die eingehenden Requests vom Energiemanager mit Function code, Adresse und Länge notieren (z.B. fc4 auf i123 mit len 4, fc3 auf h234 mit len 1, ...)
2) Fhem als Master konfigurieren und genau solche Requests an den echten WR schicken. Ein input register muss dabei auch ein input register bleiben und darf kein holding register werden und wenn der Energiemanager 5 Register auf einmal - also Länge 5 - abfragt, dann musst Du das genauso mit len 5 machen. Dabei verbose auf 5
3) die Antworten des echten WR (Objekte mit Längen und Werten) im Fhem-Log suchen und notieren
4) daraus die Konfiguration des Fake WR Slaves in Fhem mit festen Werten (zum Testen) ableiten und Objekt für Objekt vergleichen, ob Fhem die gleichen Antworten schickt wie der der original WR.

Wenn Du das Schritt für Schritt machst und die vollständigen Konfigurationen und Logs postest, bekommen wir das hin :-)
Ich hänge mal den Snapshot vom Node-Red mit an, da kann ich merkwürdigerweise mit einem click den gewünschten Wert zum Energiemanager schicken, obwohl der Wechselrichter als
ModBus Server das doch eigentlich nicht kann, sondern der Energiemanager als Master das doch abholen müsste.

Die Format Umwandlung wird im Node-Red als bit/string operation durchgeführt. Das könnte ich noch liefern, kann es jedoch selber nicht nach upack übersetzen :-(

Ich beginne dann mal Punkt 1) - 4) umzusetzen...

EDIT:
1) list vom WR_3 mit gesetzten readings für die Werte, die der KSEM bekommen soll.

Internals:
   CONNECTS   2482173
   DEF        71 slave 192.168.178.40:1502 TCP
   DeviceName 192.168.178.40:1502
   EXPECT     request
   FUUID      6364cadd-f33f-61a8-1e0c-833cf3c6c73bfa1d
   FVERSION   98_ModbusAttr.pm:0.259630/2022-04-14
   IODev      WR_3
   LASTCONN   WR_3_192.168.178.17_60854
   MODBUSID   71
   MODE       slave
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       WR_3
   NOTIFYDEV  global
   NR         496
   NTFY_ORDER 50-WR_3
   PORT       1502
   PROTOCOL   TCP
   STATE      inactive
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   eventCount 7
   stacktrace  TcpServer_Close:1712 Modbus::DoClose:903 Modbus::SetLDInactive:1196 Modbus::ControlSet:1090 Modbus::SetLDFn:3950 CallFn:1957 DoSet:1989 CommandSet:1274 AnalyzeCommand:2806 FW_fC:1028 FW_answerCall:609 FW_Read:3955 CallFn:782
   READ:
   READINGS:
     2022-10-27 12:19:25   Active_P_L1     10.00
     2022-10-27 12:19:34   Active_P_L2     10.00
     2022-10-27 12:19:40   Active_P_L3     10.00
     2022-10-27 15:43:17   I_L1            1.00
     2022-10-27 15:43:26   I_L2            1.00
     2022-10-27 15:43:34   I_L3            1.00
     2022-10-27 10:56:32   Inverter_Article_number 12345678
     2022-10-27 10:56:32   Inverter_serial_number 87654321
     2022-10-27 10:56:32   Inverter_state  6
     2022-10-27 10:59:21   Productname     WR_3
     2022-10-27 10:56:32   Software-Version_IO-Controller_IOC 4711
     2022-10-27 10:56:32   Software-Version_Maincontroller_MC 0815
     2022-11-17 12:27:40   Total_AC_Active_P 30
     2022-10-27 12:17:24   U_L1            230.00
     2022-10-27 12:17:35   U_L2            230.00
     2022-10-27 12:17:44   U_L3            230.00
     2022-11-17 12:28:15   state           inactive
   REMEMBER:
     lsend      1668684494.73977
   defptr:
     WR_3       71
Attributes:
   DbLogExclude .*
   comment    Version 2022.10.27 09:00
Fremder WR am KSEM
   dev-h-defFormat %.2f
   dev-h-defLen 2
   dev-h-defRevRegs 1
   dev-h-defUnpack f>
   dev-type-STR-format %s
   dev-type-STR-len 8
   dev-type-STR-revRegs 0
   dev-type-STR-unpack a*
   disable    0
   group      PV Eigenverbrauch
   icon       sani_solar
   obj-h14-reading Inverter_serial_number
   obj-h14-type STR
   obj-h154-reading I_L1
   obj-h156-reading Active_P_L1
   obj-h158-reading U_L1
   obj-h160-reading I_L2
   obj-h162-reading Active_P_L2
   obj-h164-reading U_L2
   obj-h166-reading I_L3
   obj-h168-reading Active_P_L3
   obj-h170-reading U_L3
   obj-h172-reading Total_AC_Active_P
   obj-h172-set 1
   obj-h38-reading Software-Version_Maincontroller_MC
   obj-h38-type STR
   obj-h46-reading Software-Version_IO-Controller_IOC
   obj-h46-type STR
   obj-h56-format %.0f
   obj-h56-reading Inverter_state
   obj-h56-unpack N
   obj-h6-reading Inverter_Article_number
   obj-h6-type STR
   obj-h768-len 32
   obj-h768-reading Productname
   obj-h768-type STR
   room       Strom->Photovoltaik
   sortby     311
   verbose    5

Im Log finde ich dann diese Anfrage

2022.11.17 12:28:04.719 5: WR_3_192.168.178.17_60726: readFn buffer: 0001000000064703009a0014
2022.11.17 12:28:04.720 5: WR_3_192.168.178.17_60726: ParseFrameStart called from ReadFn
2022.11.17 12:28:04.720 4: WR_3_192.168.178.17_60726: ParseFrameStart (TCP, slave) extracted id 71, fCode 3, tid 1, dlen 6 and potential data 009a0014
2022.11.17 12:28:04.721 5: WR_3_192.168.178.17_60726: HandleRequest called from ReadFn
2022.11.17 12:28:04.721 5: WR_3_192.168.178.17_60726: ParseRequest called from HandleRequest
2022.11.17 12:28:04.722 4: WR_3_192.168.178.17_60726: HandleRequest, current frame / read buffer: 0001000000064703009a0014, id 71, fCode 3, tid 1,
request: id 71 fc 3 h154, len 20, tid 1
2022.11.17 12:28:04.722 5: WR_3: CreateResponse called from HandleRequest
2022.11.17 12:28:04.723 5: WR_3: PackObj called from CreateResponse with h 154 and valuesLen 20
2022.11.17 12:28:04.724 4: WR_3: PackObj for h154 is using reading I_L1 of device WR_3 with value 1.00            <<<< hier ist das reading mit 1,0 Ampare, was ich gesetzt hatte.
2022.11.17 12:28:04.724 5: WR_3: FormatVal for PackObj formats 1.00 with format %.2f, result is 1.00
2022.11.17 12:28:04.725 5: WR_3: PackObj packed value 1.00 with pack code f> to 3f800000
2022.11.17 12:28:04.725 5: WR_3: PackObj padded / cut object to 3f800000
2022.11.17 12:28:04.726 5: WR_3: PackObj revRegs = 1, dplen = 4
2022.11.17 12:28:04.726 5: WR_3: ReverseWordOrder is reversing order of up to 2 registers
2022.11.17 12:28:04.726 5: WR_3: ReverseWordOrder for PackObj is transforming 3f800000 to 00003f80

Allerdings weiß ich jetzt nicht, was ich mit dem  fc 3 h154, len 20 machen soll :-)
Im Node-red steht für h154 dann folgendes.

payload=msg.payload
var value=payload;
buf=Buffer.alloc(4);
buf.writeFloatBE(value);
//buf.writeFloatBE(16001.5);
var values=[(buf[2]*256)+buf[3],(buf[0]*256+buf[1])]                 <<< hier werden wohl die bytes zusammen gesetzt

msg.payload={"value":values , 'fc': 16, 'unitid': 20, 'address': 154 , 'quantity': 2 };             <<< die unitid habe ich für die FHEM zu KSEM Kopplung auf 71 geändert
return msg;


Das Verbose 5 Log habe ich angehängt.
Die Node-Red Flow Definition ist auch als export im Anhang, da findet man die definition der bereit gestellten Werte.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 November 2022, 08:25:41
Hallo Mario,

Zitat von: Mariomgn am 13 November 2022, 20:23:22
Im Register 22 habe ich nun die Möglichkeit 125 Werte zu empfangen.

auf Pos. 1 stehen nun die 73°C.
Wie wird das in Fhem weiter definiert, wenn man noch mehr Werte in das Register 22 schreiben möchte? 22X2 funktioniert nicht.  :-\

define Data4PLC ModbusAttr 6 slave 192.168.0.150:1502 TCP
attr Data4PLC obj-h22-len 2
attr Data4PLC obj-h22-reading Temperatur_Heizung:DS18B20-7_Temperature
attr Data4PLC obj-h22-unpack n
attr Data4PLC obj-h22x2-len 2
attr Data4PLC obj-h22x2-reading Temperatur_Heizung:DS18B20-4_Temperature
attr Data4PLC obj-h22x2-unpack n


Ein Holding-Register enthält immer 16 Bit. Keine 125 Werte.
Ein Float-Wert, der mit Unpack-Code "f" kodiert wird, besteht aus 32 Bits und folglich muss der in zwei aufeinanderfolgenden Register (bei Dir 22 und 23) gespeichert werden.
Durch Angabe der Länge 2 wird das geregelt.

Wenn Du nach der ersten Temperatur (in den Registern 22 und 23) einen weiteren Float-Wert bereitstellen möchtest, dann muss der ab Register 24 mit Länge 2 und Unpack-Code "f" definiert werden.
Ein Register 22x2 gibt es nicht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 November 2022, 08:49:30
Hallo Christian,

Zitat von: ch.eick am 17 November 2022, 11:56:01
Als Mode wird dann im Device "master" angezeigt.
Daraus leite ich dann ab, dass der Wechselrichter ein Master ist.
Das ist das erste Missverständnis.
Mode "master" bedeutet dass Fhem als Master (= Modbus Client) arbeitet und somit aktiv einen Slave (=Modbus Server abfragen kann). Dein WR ist der Slave.

Zitat
...
Ich beginne dann mal Punkt 1) - 4) umzusetzen...
...
Im Log finde ich dann diese Anfrage

2022.11.17 12:28:04.722 4: WR_3_192.168.178.17_60726: HandleRequest, current frame / read buffer: 0001000000064703009a0014, id 71, fCode 3, tid 1,
request: id 71 fc 3 h154, len 20, tid 1

Allerdings weiß ich jetzt nicht, was ich mit dem  fc 3 h154, len 20 machen soll :-)

Punkt 1 in der Liste haben wir damit:
Zitat
1) den Slave in Fhem auf verbose 5 stellen und die eingehenden Requests vom Energiemanager mit Function code, Adresse und Länge notieren (z.B. fc4 auf i123 mit len 4, fc3 auf h234 mit len 1, ...)
2) Fhem als Master konfigurieren und genau solche Requests an den echten WR schicken. Ein input register muss dabei auch ein input register bleiben und darf kein holding register werden und wenn der Energiemanager 5 Register auf einmal - also Länge 5 - abfragt, dann musst Du das genauso mit len 5 machen. Dabei verbose auf 5
3) die Antworten des echten WR (Objekte mit Längen und Werten) im Fhem-Log suchen und notieren
4) daraus die Konfiguration des Fake WR Slaves in Fhem mit festen Werten (zum Testen) ableiten und Objekt für Objekt vergleichen, ob Fhem die gleichen Antworten schickt wie der der original WR.

Der Energiemanager liest 20 Register ab Register 154 in einem Request.

Jetzt würde ich mit Punkt 2 weiter machen, Fhem als Master konfigurieren und schauen, wie der WR auf so einen Request antwortet.
Die Register hast Du ja schon definiert. Wenn Du noch Combine auf 20 setzt, dann sollte Deine Master-Definition auch 20 Register auf einmal lesen und dann sehen wir bei verbose 5 wie der WR genau darauf antwortet.

Gruss
   Stefan




Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 18 November 2022, 10:08:55
Hallo Stefan,

vielen Dank für die Antwort.

Ich habe das Ganze nun am laufen.

Wo kann ich das Projekt bereitstellen, falls noch jemand Fhem mit einer Micro 820 verbinden möchte?


MfG Mario
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 18 November 2022, 10:24:31
Zitat von: Mariomgn am 18 November 2022, 10:08:55
Ich habe das Ganze nun am laufen.

Wo kann ich das Projekt bereitstellen, falls noch jemand Fhem mit einer Micro 820 verbinden möchte?
Wie wäre es im Wiki? Du kannst Dir da einen Zugriff geben lassen und mithelfen, dass es immer besser wird.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 18 November 2022, 11:50:16
Hallo,

ich möchte einen TFU-2000M per Modbus auslesen.

Register h1529  2 Stellen  "Electronic serial number"          BCD   High byte first

Im Log wird es auch angezeigt, aber ich bekomme es nicht ordenlich in FHEM angezeigt.
die S/N-Nummer ist: 21217195

im Log wird : response: id 5, fc 3, h1528, len 2, values 21219571 angezeigt. Die Stellen müssen auch noch getauscht werden.

in FHEM (ich habe die beiden Regsiter aufgeteilt).Und das wird angezeigt.
SN1: 8481
SN2: 29077

attr TUF2000M5 obj-h1528-len 1
attr TUF2000M5 obj-h1528-reading SN1
attr TUF2000M5 obj-h1528-unpack s

attr TUF2000M5 obj-h1529-len 1
attr TUF2000M5 obj-h1529-reading SN2
attr TUF2000M5 obj-h1529-unpack s

Vielleicht kann mir einer einmal einen Hinweis geben was bei unpack eingetragen werden muss und wie die Stellen getauscht werden können.
Vielen Dank.

log

2022.11.18 11:42:26 5: ioUltra: ResetExpect for HandleResponse from response to idle
2022.11.18 11:42:26 5: ioUltra: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2022.11.18 11:42:26 5: ioUltra: DropFrame called from ReadFn - drop 050304000300044e30
2022.11.18 11:42:26 5: ioUltra: ProcessRequestQueue called from Fhem internal timer as queue:ioUltra, qlen 1, request: request: id 5, read fc 3 h1528, len 2, master device TUF2000M5, reading SN1 (getUpdate for combined h1528 len 1 SN1 with h1529 len 1 SN2), queued 1.09 secs ago
2022.11.18 11:42:26 5: ioUltra: checkDelays clientSwitchDelay is not relevant
2022.11.18 11:42:26 5: ioUltra: checkDelays sendDelay, last send to same device was 0.046 secs ago, required delay is 0.1
2022.11.18 11:42:26 5: ioUltra: checkDelays busDelayRead, last activity on bus was 0.015 secs ago, required delay is 0
2022.11.18 11:42:26 5: ioUltra: checkDelays commDelay, last communication with same device was 0.013 secs ago, required delay is 0.1
2022.11.18 11:42:26 4: ioUltra: checkDelays found commDelay not over, set timer to try again in 0.087
2022.11.18 11:42:27 5: ioUltra: ProcessRequestQueue called from Fhem internal timer as queue:ioUltra, qlen 1, request: request: id 5, read fc 3 h1528, len 2, master device TUF2000M5, reading SN1 (getUpdate for combined h1528 len 1 SN1 with h1529 len 1 SN2), queued 1.18 secs ago
2022.11.18 11:42:27 5: ioUltra: checkDelays commDelay, last communication with same device was 0.104 secs ago, required delay is 0.1
2022.11.18 11:42:27 5: ioUltra: checkDelays busDelayRead, last activity on bus was 0.106 secs ago, required delay is 0
2022.11.18 11:42:27 5: ioUltra: checkDelays clientSwitchDelay is not relevant
2022.11.18 11:42:27 5: ioUltra: checkDelays sendDelay, last send to same device was 0.137 secs ago, required delay is 0.1
2022.11.18 11:42:27 4: ioUltra: ProcessRequestQueue (V4.4.11 - 5.10.2022) qlen 1, sending 050305f8000244b2 via /dev/rs485@9600,8,N,1, read buffer empty,
request: id 5, read fc 3 h1528, len 2, master device TUF2000M5, reading SN1 (getUpdate for combined h1528 len 1 SN1 with h1529 len 1 SN2), queued 1.18 secs ago
2022.11.18 11:42:27 5: ioUltra: Send called from ProcessRequestQueue
2022.11.18 11:42:27 5: DevIo_SimpleWrite ioUltra: 050305f8000244b2
2022.11.18 11:42:27 5: ioUltra: readFn buffer: 05
2022.11.18 11:42:27 5: ioUltra: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2022.11.18 11:42:27 5: ioUltra: readFn did not see a valid RTU frame start yet, wait for more data
2022.11.18 11:42:27 5: ioUltra: readFn buffer: 050304
2022.11.18 11:42:27 5: ioUltra: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2022.11.18 11:42:27 5: ioUltra: readFn did not see a valid RTU frame start yet, wait for more data
2022.11.18 11:42:27 5: ioUltra: readFn buffer: 0503042121
2022.11.18 11:42:27 5: ioUltra: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2022.11.18 11:42:27 4: ioUltra: ParseFrameStart (RTU, master) extracted id 5, fCode 3 and potential data 04
2022.11.18 11:42:27 5: ioUltra: HandleResponse called from ReadFn
2022.11.18 11:42:27 5: ioUltra: ParseResponse called from HandleResponse
2022.11.18 11:42:27 5: ioUltra: ParseResponse got incomplete frame. Got 5 but expecting 9 bytes
2022.11.18 11:42:27 5: ioUltra: readFn buffer: 050304212195714ab1
2022.11.18 11:42:27 5: ioUltra: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2022.11.18 11:42:27 4: ioUltra: ParseFrameStart (RTU, master) extracted id 5, fCode 3 and potential data 0421219571
2022.11.18 11:42:27 5: ioUltra: HandleResponse called from ReadFn
2022.11.18 11:42:27 5: ioUltra: ParseResponse called from HandleResponse
2022.11.18 11:42:27 5: ioUltra: CheckChecksum (called from ParseResponse): 4ab1 is valid
2022.11.18 11:42:27 5: ioUltra: now parsing response data objects, master is TUF2000M5 relay is undefined
2022.11.18 11:42:27 4: ioUltra: HandleResponse done, current frame / read buffer: 050304212195714ab1, id 5, fCode 3,
request: id 5, read fc 3 h1528, len 2, master device TUF2000M5, reading SN1 (getUpdate for combined h1528 len 1 SN1 with h1529 len 1 SN2), queued 1.23 secs ago, sent 0.05 secs ago,
response: id 5, fc 3, h1528, len 2, values 21219571
2022.11.18 11:42:27 5: ioUltra: ResetExpect for HandleResponse from response to idle
2022.11.18 11:42:27 5: ioUltra: DropFrame called from ReadFn - drop 050304212195714ab1


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 18 November 2022, 12:23:58
Zitat von: StefanStrobel am 18 November 2022, 08:49:30
Hallo Christian,
Das ist das erste Missverständnis.
Mode "master" bedeutet dass Fhem als Master (= Modbus Client) arbeitet und somit aktiv einen Slave (=Modbus Server abfragen kann). Dein WR ist der Slave.

Punkt 1 in der Liste haben wir damit:
Der Energiemanager liest 20 Register ab Register 154 in einem Request.

Jetzt würde ich mit Punkt 2 weiter machen, Fhem als Master konfigurieren und schauen, wie der WR auf so einen Request antwortet.
Die Register hast Du ja schon definiert. Wenn Du noch Combine auf 20 setzt, dann sollte Deine Master-Definition auch 20 Register auf einmal lesen und dann sehen wir bei verbose 5 wie der WR genau darauf antwortet.
Hallo Stefan,
ich habe empirisch mal eben Schritt 2-4 übersprungen und melde Erfolg :-)

Es war somit sehr wohl möglich, die ModBus Definition aus dem lesenden Device zu übernehmen.

Im verbose 5 Log habe ich noch einige fehlene Register gefunden, die ich mit der Definition aus dem orinal Wechselrichter Device und Wert 0 zusätzlich übernommen habe.
Auch das "attr WR_3 dev-h-combine 20" habe ich eingetragen.

Wie im Anhang zu sehen, wird der Leistungswert aus dem FHEM WR_3 Device nun angezeigt und auch der Status ist nun ein grünes Häckchen.
Wie immer vielen Dank für die unermüdliche unterstützung.

Mit dem Device geht es dann jetzt im Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV) (https://forum.fhem.de/index.php/topic,114849.0.html) Thread weiter.

VG
    Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 18 November 2022, 15:30:45
Hallo zusammen,
obwohl in meinem Device verbose 0 gesetzt ist, wird folgende Meldung im log angezeigt.

2022.11.18 14:56:52.402 5: WR_3_192.168.178.17_57082: ResetExpect for HandleServerConnection from undefined to request
2022.11.18 14:56:52.999 5: WR_3_192.168.178.17_57088: ResetExpect for HandleServerConnection from undefined to request

VG   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 November 2022, 15:51:11
Hallo Christian,

Wenn ein TCP-Server-Device eine Verbindung annimmt, dann wird daraus ein neues Verbindungs-Device.
Leider bedeutet das auch dass Attribute, die Du im WR_3 setzt, nicht automatisch auf WR_3_192.168.178.17_57082 übernommen werden. Dort steht verbose vermutlich immer noch auf 5, bis diese Verbindung geschlossen wurde.
Da ich das auch lästig fand, es aber niemandem aufzwingen wollte, habe ich ein Attribut mit Namen propagateVerbose eingebaut. Dann wird verbose weitergegeben ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 November 2022, 15:52:28
Hallo pejonp,

kannst Du es mit revRegs oder bswapRegs lösen?

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 19 November 2022, 21:15:53
Hallo Stefan,

vielen Dank für den Hinweis.
Habe es jetzt so gelöst:

attr TUF2000M5 obj-h1528-bswapRegs 1
attr TUF2000M5 obj-h1528-len 2
attr TUF2000M5 obj-h1528-reading SN
attr TUF2000M5 obj-h1528-unpack H*


pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 20 November 2022, 09:22:08
Zitat von: StefanStrobel am 18 November 2022, 15:51:11
Wenn ein TCP-Server-Device eine Verbindung annimmt, dann wird daraus ein neues Verbindungs-Device.
Leider bedeutet das auch dass Attribute, die Du im WR_3 setzt, nicht automatisch auf WR_3_192.168.178.17_57082 übernommen werden. Dort steht verbose vermutlich immer noch auf 5, bis diese Verbindung geschlossen wurde.
Da ich das auch lästig fand, es aber niemandem aufzwingen wollte, habe ich ein Attribut mit Namen propagateVerbose eingebaut. Dann wird verbose weitergegeben ...
Moin,
die nachfolgenden Meldungen sind dann jetzt verschwunden.
Vielen Dank
   Christian

2022.11.18 14:56:52.402 5: WR_3_192.168.178.17_57082: ResetExpect for HandleServerConnection from undefined to request
2022.11.18 14:56:52.999 5: WR_3_192.168.178.17_57088: ResetExpect for HandleServerConnection from undefined to request
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 21 November 2022, 07:01:16
Hallo Stefan,

ich habe nun einen Auszug aus dem Log, warum Fhem sich aufhängt.
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: read from TCP server connection got null -> closing
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: _UnDef is closing Data4PLC_192.168.0.250_53888
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53889: read from TCP server connection got null -> closing
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53889: _UnDef is closing Data4PLC_192.168.0.250_53889
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53890: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53890: _UnDef is closing Data4PLC_192.168.0.250_53890
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53892: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53892: _UnDef is closing Data4PLC_192.168.0.250_53892
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53893: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53893: _UnDef is closing Data4PLC_192.168.0.250_53893
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53894: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53894: _UnDef is closing Data4PLC_192.168.0.250_53894
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53896: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53896: _UnDef is closing Data4PLC_192.168.0.250_53896
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53898: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53898: _UnDef is closing Data4PLC_192.168.0.250_53898
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53899: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53899: _UnDef is closing Data4PLC_192.168.0.250_53899
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:


die Log datei ist 2,1 GB groß :o

Woran könnte das liegen?

MfG Mario
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 21 November 2022, 08:00:11
Zitat von: Mariomgn am 21 November 2022, 07:01:16
ich habe nun einen Auszug aus dem Log, warum Fhem sich aufhängt.
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: read from TCP server connection got null -> closing
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: _UnDef is closing Data4PLC_192.168.0.250_53888
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53889: read from TCP server connection got null -> closing

2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:


Woran könnte das liegen?
Hallo Mario,
bei mir kamen diese Meldungen bei einem anderen Gerät auch und es fehlten noch reading definitionen, die dann nicht beantwortet wurden.
Geh mal auf verbose 5 und such nach errors.
Wärend des suchens habe ich das Device dann immer auf inactive gesetzt, damit mir das Log nicht voll lief.
VG
   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 21 November 2022, 10:52:57
Ich habe ein paar Fehler gefunden, kann damit aber nichts anfangen
das Log File hat auch schon wieder 2 GB ::)

2022.11.21 09:53:41 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 43452 for h 40, len 2, device Data4PLC (TCP), pdu 0304002f0000, V 4.1.5 - 17.9.2019
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: Send a9bc00000007060304002f0000
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: RequestDone request: id 6, fCode 3, tid 43452, type h, adr 40, len 2 for device Data4PLC_192.168.0.250_46123, Current read buffer: a9bc00000006060300280002, Id 6, fCode 3, tid 43452, response: id 6, fCode 3, tid 43452, type h, adr 40, len 2, value 002f0000
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: DropFrame - drop a9bc00000006060300280002
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: read buffer: a9bd00000006060300180002
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 43453, dlen 6 and data 00180002
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: HandleRequest called from Read
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: ParseRequest called from HandleRequest
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: HandleRequest request: id 6, fCode 3, tid 43453, type h, adr 24, len 2, Current read buffer: a9bd00000006060300180002, Id 6, fCode 3, tid 43453
2022.11.21 09:53:41 5: Data4PLC: CreateResponse called from HandleRequest
2022.11.21 09:53:41 5: Data4PLC: PackObj called from CreateResponse with h 24 and valuesLen 2
2022.11.21 09:53:41 5: Data4PLC: PackObj ObjInfo for h24: reading=Temperatur_Heizung:DS18B20-2_Temperature, expr=, format=, len=2, map=, unpack=n
2022.11.21 09:53:41 4: Data4PLC: PackObj for h24 is using reading DS18B20-2_Temperature of device Temperatur_Heizung with value 47.4
2022.11.21 09:53:41 5: Data4PLC: PackObj packed 47.4 with pack code n to 002f
2022.11.21 09:53:41 5: Data4PLC: PackObj padded / cut object to 002f0000
2022.11.21 09:53:41 5: Data4PLC: PackObj counter reached 2
2022.11.21 09:53:41 5: Data4PLC: PackObj full data string is 002f0000
2022.11.21 09:53:41 5: Data4PLC: PackObj padded / cut data string to 002f0000
2022.11.21 09:53:41 5: Data4PLC: prepare response pdu
2022.11.21 09:53:41 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 43453 for h 24, len 2, device Data4PLC (TCP), pdu 0304002f0000, V 4.1.5 - 17.9.2019
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: Send a9bd00000007060304002f0000
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: RequestDone request: id 6, fCode 3, tid 43453, type h, adr 24, len 2 for device Data4PLC_192.168.0.250_46123, Current read buffer: a9bd00000006060300180002, Id 6, fCode 3, tid 43453, response: id 6, fCode 3, tid 43453, type h, adr 24, len 2, value 002f0000
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: DropFrame - drop a9bd00000006060300180002
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: read buffer: a9be000000110610010400050a00000000000000000000
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: ParseFrameStart (TCP) extracted id 6, fCode 16, tid 43454, dlen 17 and data 010400050a00000000000000000000
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: HandleRequest called from Read
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: ParseRequest called from HandleRequest
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: HandleRequest request: id 6, fCode 16, tid 43454, type h, adr 260, len 5, value 00000000000000000000, Current read buffer: a9be000000110610010400050a00000000000000000000, Id 6, fCode 16, tid 43454
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: passing value string of write request to ParseObj to set readings
2022.11.21 09:53:41 5: Data4PLC: ParseObj called with data 00000000000000000000, type h, adr 260, valuesLen 5
2022.11.21 09:53:41 5: Data4PLC: ParseObj ObjInfo for h260: reading=Ventil_Atmos:state, unpack=n, expr=, format=, map=
2022.11.21 09:53:41 5: Data4PLC: ParseObj unpacked 00000000000000000000 with n to 0 hex 30
2022.11.21 09:53:41 4: Data4PLC: ParseObj assigns value 0 to reading state of device Ventil_Atmos
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h261
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h261
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h262
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h262
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h263
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h263
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h264
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h264
2022.11.21 09:53:41 5: Data4PLC: HandleRequest got 1 readings from ParseObj
2022.11.21 09:53:41 5: Data4PLC: CreateResponse called from HandleRequest
2022.11.21 09:53:41 5: Data4PLC: prepare response pdu
2022.11.21 09:53:41 4: Data4PLC: CreateResponse sends fc 144 error code 2 to id 6, tid 43454 for h 260, len 5, device Data4PLC (TCP), pdu 9002, V 4.1.5 - 17.9.2019
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: Send a9be00000003069002
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: RequestDone request: id 6, fCode 16, tid 43454, type h, adr 260, len 5, value 00000000000000000000 for device Data4PLC_192.168.0.250_46123, Current read buffer: a9be000000110610010400050a00000000000000000000, Id 6, fCode 16, tid 43454, response: id 6, fCode 16, tid 43454, type h, adr 260, len 5
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: DropFrame - drop a9be000000110610010400050a00000000000000000000
2022.11.21 09:55:41 4: Data4PLC: closing connection after inactivity
2022.11.21 09:55:41 5: Data4PLC_192.168.0.250_46123: Close called from ServerTimeout
2022.11.21 09:55:41 4: Data4PLC_192.168.0.250_46123: Close TCP server connection and delete hash
2022.11.21 09:55:41 3: Data4PLC_192.168.0.250_46123: _UnDef is closing Data4PLC_192.168.0.250_46123




In der Config sieht das Ganze so aus :define Data4PLC ModbusAttr 6 slave 192.168.0.150:1502 TCP
setuuid Data4PLC 63713fba-f33f-3045-2110-88b318e9d470e9d9
attr Data4PLC userattr obj-h22-len obj-h22-reading obj-h22-unpack obj-h24-len obj-h24-reading obj-h24-unpack obj-h26-len obj-h26-reading obj-h26-unpack obj-h260-allowWrite obj-h260-len obj-h260-reading obj-h260-unpack obj-h28-len obj-h28-reading obj-h28-unpack obj-h30-len obj-h30-reading obj-h30-unpack obj-h32-len obj-h32-reading obj-h32-unpack obj-h34-len obj-h34-reading obj-h34-unpack obj-h36-len obj-h36-reading obj-h36-unpack obj-h38-len obj-h38-reading obj-h38-unpack obj-h40-len obj-h40-reading obj-h40-unpack obj-h60-len obj-h60-reading obj-h60-unpack
attr Data4PLC obj-h22-len 2
attr Data4PLC obj-h22-reading Temperatur_Heizung:DS18B20-7_Temperature
attr Data4PLC obj-h22-unpack n
attr Data4PLC obj-h24-len 2
attr Data4PLC obj-h24-reading Temperatur_Heizung:DS18B20-2_Temperature
attr Data4PLC obj-h24-unpack n
attr Data4PLC obj-h26-len 2
attr Data4PLC obj-h26-reading Temperatur_Heizung:DS18B20-6_Temperature
attr Data4PLC obj-h26-unpack n
attr Data4PLC obj-h260-allowWrite 1
attr Data4PLC obj-h260-len 1
attr Data4PLC obj-h260-reading Ventil_Atmos:state
attr Data4PLC obj-h260-unpack n
attr Data4PLC obj-h28-len 2
attr Data4PLC obj-h28-reading Temperatur_Heizung:DS18B20-3_Temperature
attr Data4PLC obj-h28-unpack n
attr Data4PLC obj-h30-len 2
attr Data4PLC obj-h30-reading Temperatur_Heizung:DS18B20-1_Temperature
attr Data4PLC obj-h30-unpack n
attr Data4PLC obj-h32-len 2
attr Data4PLC obj-h32-reading Temperatur_Heizung_2:DS18B20-1_Temperature
attr Data4PLC obj-h32-unpack n
attr Data4PLC obj-h34-len 2
attr Data4PLC obj-h34-reading Temperatur_Heizung_2:DS18B20-2_Temperature
attr Data4PLC obj-h34-unpack n
attr Data4PLC obj-h36-len 2
attr Data4PLC obj-h36-reading Temperatur_Heizung_2:DS18B20-3_Temperature
attr Data4PLC obj-h36-unpack n
attr Data4PLC obj-h38-len 2
attr Data4PLC obj-h38-reading Temperatur_Heizung:DS18B20-4_Temperature
attr Data4PLC obj-h38-unpack n
attr Data4PLC obj-h40-len 3
attr Data4PLC obj-h40-reading Temperatur_Heizung:DS18B20-5_Temperature
attr Data4PLC obj-h40-unpack n
attr Data4PLC obj-h60-len 2
attr Data4PLC obj-h60-reading WW_Zirkulation:cmd
attr Data4PLC obj-h60-unpack n
attr Data4PLC room Modbus
attr Data4PLC verbose 5


Habe ich etwas vergessen?

MfG Mario
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 21 November 2022, 11:02:02
Zitat von: Mariomgn am 21 November 2022, 10:52:57
Ich habe ein paar Fehler gefunden, kann damit aber nichts anfangen


2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: HandleRequest request: id 6, fCode 16, tid 43454, type h, adr 260, len 5, value 00000000000000000000, Current read buffer: a9be000000110610010400050a00000000000000000000, Id 6, fCode 16, tid 43454
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: passing value string of write request to ParseObj to set readings
2022.11.21 09:53:41 5: Data4PLC: ParseObj called with data 00000000000000000000, type h, adr 260, valuesLen 5
2022.11.21 09:53:41 5: Data4PLC: ParseObj ObjInfo for h260: reading=Ventil_Atmos:state, unpack=n, expr=, format=, map=
2022.11.21 09:53:41 5: Data4PLC: ParseObj unpacked 00000000000000000000 with n to 0 hex 30
2022.11.21 09:53:41 4: Data4PLC: ParseObj assigns value 0 to reading state of device Ventil_Atmos


Du hast z.B. für h260 eine Len von 1 angegeben. Im Log steht aber len 5 .

Auch werden h261 - h264 angeboten, sind aber bei Dir nicht definiert.

2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h261
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h261
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h262
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h262
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h263
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h263
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h264
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h264
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 November 2022, 18:52:06
Hallo Mario,

das sieht so aus als ob die TCP-Verbindungen nicht richtig geschlossen werden.
Ich versuche das mal bei mir nachzustellen.
In der Zwischenzeit könntest Du mal versuchen den Servertimeout so hoch zu stellen, dass Fhem die Verbindung nicht schließt (höher als das Abfrageintervall das Masters)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 November 2022, 20:23:23
Noch eine Idee:

In Deinem ersten Log-Auszug zu dem Thema waren ziemlich viele Verbindungen gleichzeitig offen. Kannst Du in dem Log mal weiter zurück schauen, wann / wie die Aufgebaut werden? Eigentlich sollte für einen Master nur eine Verbindung offen sein. Solange er die nicht schließt, sollte er sie weiter verwenden. Wenn der jedoch in schneller Folge für jeden Request neue Verbindungen aufmacht und Fhem mit dem Schließen nicht nachkommt, kann das auch das Problem sein.
Dann müsstest Du den Servertimeout deutlich kürzer einstellen, z.B. auf 5 Sekunden.

Zitat von: Mariomgn am 21 November 2022, 07:01:16
ich habe nun einen Auszug aus dem Log, warum Fhem sich aufhängt.
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: read from TCP server connection got null -> closing
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: _UnDef is closing Data4PLC_192.168.0.250_53888
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53889: read from TCP server connection got null -> closing
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53889: _UnDef is closing Data4PLC_192.168.0.250_53889
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53890: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53890: _UnDef is closing Data4PLC_192.168.0.250_53890
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53892: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53892: _UnDef is closing Data4PLC_192.168.0.250_53892
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53893: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53893: _UnDef is closing Data4PLC_192.168.0.250_53893
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53894: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53894: _UnDef is closing Data4PLC_192.168.0.250_53894
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53896: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53896: _UnDef is closing Data4PLC_192.168.0.250_53896
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53898: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53898: _UnDef is closing Data4PLC_192.168.0.250_53898
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53899: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53899: _UnDef is closing Data4PLC_192.168.0.250_53899
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:


Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 21 November 2022, 21:49:42
Hallo Stefan,

ich habe auf dem Master jetzt Connection Timeout auf 5000ms und Massage Timeout auf 1000ms gestellt und werde morgen noch einmal berichten.


MfG Mario
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 21 November 2022, 22:55:13
Ich nochmal :-)

Fehler hat sich gerade wieder aufgebaut....

Ich habe mir mein Programm in der SPS noch mal genauer angeschaut und ein SPS Analyzer das Ganze beobachten lassen.

Was soll ich sagen... Fhem ist zu langsam ;D ;D :-X

Durch einen kleinen Fehler wurden die ganze Zeit zehn Register alle zwei Millisekunden (Zykluszeit der SPS) abgefragt. 8)

Ich habe das jetzt auch auf fünf Sekunden Intervall geändert.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Taxor am 27 November 2022, 20:26:44
Hallo zusammen  :)

Ich integriere gerade eine Nibe S1255 Wärmepumpe per Modbus TCP/IP in FHEM. Aktuell komme ich mit dem Parameter -expr nicht zurecht bzw. fehlt mir mangels Perl-Kenntnissen wohl der richtige syntax.
Nibe gibt bei Prio (Register 1028) 5 verschiedene Werte zurück (10 - aus, 20 - Warmwasser, 30 - Heizung, 40 - Pool, 60 - Kühlung), je nachdem, was die Wärmepumpe gerade tut. Wie muss ich -expr verwenden, um statt der Zahlen die Entsprechung als Wort anzeigen zu lassen? In der Wiki bin ich leider nicht fündig geworden.

Viele Grüße
Taxor

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 November 2022, 20:38:38
Hallo Taxor,

dafür gibt es die -map Attribute.

Gruss
   Stefan


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Taxor am 28 November 2022, 17:25:48
Vielen Dank!!! Habs mit dem -map hinbekommen. Da war der notwendige Syntax ja deutlich einfacher als erwartet ;-)

Viele Grüße
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: spiderman am 02 Dezember 2022, 08:23:42
Ich habe meinen Wechselrichter per Modbus integriert inkl. ca. 3 Bildschirmseiten voll mit Readings und Attributen. Beim Löschen des Gerätes reagiert fhem nicht mehr und wird neu gestartet, ohne das das Device gelöscht wurde. Im Logfile ist folgendes zu finden:

2022.12.01 16:19:06 3: SH10rt_Fast: _UnDef is preparing SH10rt_Fast for deletion
2022.12.01 16:19:06 1: PERL WARNING: Deep recursion on subroutine "Modbus::DoClose" at ./FHEM/98_Modbus.pm line 4275.
2022.12.01 16:19:06 1: PERL WARNING: Deep recursion on subroutine "Modbus::SetStates" at ./FHEM/98_Modbus.pm line 1717.
Out of memory!

Folgende Version ist betroffen:

98_Modbus.pm     26497 2022-10-07 17:27:36Z StefanStrobel
98_ModbusAttr.pm 25963 2022-04-14 16:52:16Z StefanStrobel
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ch.eick am 02 Dezember 2022, 08:39:09
Zitat von: spiderman am 02 Dezember 2022, 08:23:42
Ich habe meine Wechselrichter per Modbus integriert inkl. ca. 3 Bildschirmseiten voll mit Readings und Attributen. Beim Löschen des Gerätes reagiert fhem nicht mehr und wird neu gestartet, ohne das das Device gelöscht wurde. Im Logfile ist folgendes zu finden:

2022.12.01 16:19:06 3: SH10rt_Fast: _UnDef is preparing SH10rt_Fast for deletion
2022.12.01 16:19:06 1: PERL WARNING: Deep recursion on subroutine "Modbus::DoClose" at ./FHEM/98_Modbus.pm line 4275.
2022.12.01 16:19:06 1: PERL WARNING: Deep recursion on subroutine "Modbus::SetStates" at ./FHEM/98_Modbus.pm line 1717.
Out of memory!

Folgende Version ist betroffen:

98_Modbus.pm     26497 2022-10-07 17:27:36Z StefanStrobel
98_ModbusAttr.pm 25963 2022-04-14 16:52:16Z StefanStrobel
Moin.

Hast Du denn wirklich zuwenig Speicher?

fhem@raspberrypi:~$ top
top - 08:38:29 up 58 days, 18:37,  3 users,  load average: 0,43, 0,41, 0,44
Tasks: 214 total,   1 running, 213 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2,6 us,  1,4 sy,  0,0 ni, 96,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   3794,0 total,   1081,7 free,   2126,0 used,    586,4 buff/cache
MiB Swap:    100,0 total,      0,0 free,    100,0 used.   1344,9 avail Mem


- Du könntest das Device zuerst mal deaktivieren
- im Anschluss eventuell die vielen Attribute mit einer Maske, in kleineren Gruppen löschen

Mein Wechselrichter Device geht ebenfalls als RAW Definition über 400 Zeilen und das kann ich einfach löschen.

FVERSION 98_ModbusAttr.pm:0.259630/2022-04-14


VG   Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: spiderman am 02 Dezember 2022, 18:04:41
Mein fhem läuft in einer VM unter Proxmox mit 8GB auf einem Intel Nuc i5. Deine oben aufgezeigte Löschstrategie habe ich dann auch gemacht und die Attribute nach und nach gelöscht und dann schlussendlich device. Die VM hat 1GB in gebrauch. Also eigentlich Speicher satt.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Dezember 2022, 18:12:30
Das sieht nach einem Bug aus.
Neue Version kommt.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Dezember 2022, 18:33:59
Anbei eine neue Version zum Testen.
ich habe auch das Handling von STATE vs. state (hoffentlich) in Ordnung gebracht.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ChristianA am 09 Dezember 2022, 21:16:41
Hallo,

seit einigen Tagen läuft bei mir die Modbus Verbindung nicht mehr stabil. Nach einem Neustart funktioniert es für 1-2 Stunden, dann können keine Werte mehr gelesen werden. Im Logfile bekomme ich folgende Meldungen

2022.12.09 20:33:50 3: PMR09: Timeout waiting for a modbus response, read buffer empty,
request: id 10, read fc 3 h709, len 1, master device WMZ, reading Ventilstellung (getUpdate for Ventilstellung len 1), queued 2.01 secs ago, sent 2.00 secs ago
...
2022.12.09 20:59:06 3: PMR09: Timeout waiting for a modbus response, read buffer empty,
request: id 10, read fc 3 h748, len 1, master device WMZ, reading FW_Spreizung (getUpdate for FW_Spreizung len 1), queued 18.03 secs ago, sent 2.00 secs ago


Habe momentan keine Plan wo ich ansetzen kann. Habe schon einen Teil der Abfragen abgeschalten, trotzdem funktioniert es nicht dauerhaft.

Schönen Gruß
Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 12 Dezember 2022, 21:53:32
Hi Stefan,
ich habe ein DC communication module PZEM-017, was Modbus spricht.
Ich kann mit ModbusAttr auch wunderbar alle Register lesen und die notwendigen schreiben.

Nur das Kommando zum Reset der Energy bekomme ich nicht hin.
Das Kommando hat nur 4 Bytes: <slave-Modbus-ID>+0x42+CRC high byte+CRC low byte

Kann man das mit ModbusAttr rausschicken?
Wenn ja, wie?

Vorab Dank (auch für das geniale Modul)
//Roger

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Dezember 2022, 18:42:53
Hallo Roger,

function code 0x42 bzw. 66 existiert nicht im Standard, aber ich könnte das vermutlich ins Modul einbauen.
Ich schau mal ob ich da einen eleganten Weg finde.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Dezember 2022, 18:44:48
Hallo Christian,

wenn etwas nicht funktioniert, solltest Du verbose auf 5 setzen und einen größeren Ausschnitt aus dem Log posten, damit man sehen kann, was passiert.
Zudem wäre Dein Konfiguration im Detail hilfreich.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 13 Dezember 2022, 20:33:46
Zitat von: StefanStrobel am 13 Dezember 2022, 18:42:53
Hallo Roger,
function code 0x42 bzw. 66 existiert nicht im Standard, aber ich könnte das vermutlich ins Modul einbauen.
Ich schau mal ob ich da einen eleganten Weg finde.
Gruss
   Stefan

Hi Stefan,
oh das wäre toll.  ;D
Ich hatte schon mit overrideFCwrite erfolglos versucht es hinzubekommen.
Vielleicht kannst Du ja raw read und write Kommandos einbauen. Nur CRC sollte automatisch gemacht werden und die Antwort irgendwie gespeichert werden.

Na Du wirst schon was zaubern.
//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ChristianA am 14 Dezember 2022, 06:27:51
Hallo Stefan,

ich habe verbose auf 5 gesetzt, und versucht die relevanten Stellen von der Definition und mit Lücke ab dem letzten gelungenen Versuch. Bei dem Befehl rawDEF bring er leider eine Fehlermeldung.

Das ganze hat bis vor ein paar Tagen schon ein paar Monate funktioniert.

So habe ich es für den Test definiert. Auch so tritt der Fehler auf.

define PMR09 Modbus /dev/ttyUSB0@19200,8,none,1
define ModbusTest ModbusAttr 10 60
attr ModbusTest dev-h-defPoll 1
attr ModbusTest obj-h600-reading T10_Außentemperatur


Im Log stehen folgende Einträge. Das letzte Mal habe ich einen Wert am um 2022.12.13 23:43:12

2022.12.13 20:37:27 5: PMR09: open called from AttrFn, busyOpenDev 0
2022.12.13 20:37:27 4: PMR09: open trying to open connection to /dev/ttyUSB0@19200,8,none,1
2022.12.13 20:37:27 3: Opening PMR09 device /dev/ttyUSB0
2022.12.13 20:37:27 3: Setting PMR09 serial parameters to 19200,8,N,1
2022.12.13 20:37:27 3: PMR09 device opened
2022.12.13 20:43:11 3: ModbusTest: defined master with id 1, protocol RTU and interval 60
2022.12.13 20:43:11 3: ModbusTest: RegisterAtIODev called from SetIODev registers ModbusTest at PMR09 with id 1, MODE master, PROTOCOL RTU
2022.12.13 20:43:11 3: ModbusTest: Notify / Init: using PMR09 for communication
2022.12.13 20:47:40 1: RMDIR: ./restoreDir/save/2022-11-19
2022.12.13 20:47:59 3: UWZ OUT_Unwetter: UWZ.1811 Done fetching data
2022.12.13 20:49:00 3: ModbusTest: defined master with id 10, protocol RTU and interval 60
2022.12.13 20:49:00 3: ModbusTest: RegisterAtIODev called from SetIODev registers ModbusTest at PMR09 with id 10, MODE master, PROTOCOL RTU
2022.12.13 20:49:00 3: ModbusTest: Notify / Init: using PMR09 for communication
2022.12.13 20:56:12 5: PMR09: QueueRequest called from DoRequest with h600, qlen 0 from master ModbusTest through io device PMR09
2022.12.13 20:56:12 5: PMR09: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.13 20:56:12 5: PMR09: ProcessRequestQueue called from Fhem internal timer as queue:PMR09, qlen 1, request: request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 20:56:12 5: PMR09: checkDelays sendDelay, last send to same device was never, required delay is 0.1
2022.12.13 20:56:12 5: PMR09: checkDelays busDelayRead, last activity on bus was 82246.113 secs ago, required delay is 0
2022.12.13 20:56:12 5: PMR09: checkDelays clientSwitchDelay is not relevant
2022.12.13 20:56:12 5: PMR09: checkDelays commDelay, last communication with same device was never, required delay is 0.1
2022.12.13 20:56:12 4: PMR09: ProcessRequestQueue (V4.3.15 - 23.1.2021) qlen 1, sending 0a0302580001051a via /dev/ttyUSB0@19200,8,none,1, read buffer empty,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 20:56:12 5: PMR09: Send called from ProcessRequestQueue
2022.12.13 20:56:12 5: SW: 0a0302580001051a
2022.12.13 20:56:12 5: PMR09: readFn buffer: 03
2022.12.13 20:56:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 20:56:12 5: PMR09: readFn did not see a valid RTU frame start yet, wait for more data
2022.12.13 20:56:12 5: PMR09: readFn buffer: 0302ff
2022.12.13 20:56:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 20:56:12 5: PMR09: readFn did not see a valid RTU frame start yet, wait for more data
2022.12.13 20:56:12 5: PMR09: readFn buffer: 0302ffdd9c2c
2022.12.13 20:56:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 20:56:12 4: PMR09: ParseFrameStart (RTU, master) extracted id 3, fCode 2 and potential data ffdd
2022.12.13 20:56:12 5: PMR09: HandleResponse called from ReadFn
2022.12.13 20:56:12 5: PMR09: ParseResponse called from HandleResponse
2022.12.13 20:56:12 5: PMR09: ParseResponse got incomplete frame. Got 6 but expecting 260 bytes
2022.12.13 20:56:14 3: PMR09: Timeout waiting for a modbus response, current frame / read buffer: 0302ffdd9c2c, id 3, fCode 2,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 2.00 secs ago, sent 2.00 secs ago, error: Modbus ID 3 of response does not match request ID 10, Function code 2 in Modbus response does not match request function code 3, Invalid checksum 9c2c received. Calculated 2009
2022.12.13 20:56:14 5: PMR09: DropFrame called from ResponseTimeout - drop 0302ffdd9c2c
2022.12.13 20:57:12 5: PMR09: QueueRequest called from DoRequest with h600, qlen 0 from master ModbusTest through io device PMR09
2022.12.13 20:57:12 5: PMR09: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.13 20:57:12 5: PMR09: ProcessRequestQueue called from Fhem internal timer as queue:PMR09, qlen 1, request: request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 20:57:12 5: PMR09: checkDelays clientSwitchDelay, last read with different id was 59.940 secs ago, required delay is 0
2022.12.13 20:57:12 5: PMR09: checkDelays commDelay, last communication with same device was 59.939 secs ago, required delay is 0.1
2022.12.13 20:57:12 5: PMR09: checkDelays busDelayRead, last activity on bus was 59.940 secs ago, required delay is 0
2022.12.13 20:57:12 5: PMR09: checkDelays sendDelay, last send to same device was 59.998 secs ago, required delay is 0.1
2022.12.13 20:57:12 4: PMR09: ProcessRequestQueue (V4.3.15 - 23.1.2021) qlen 1, sending 0a0302580001051a via /dev/ttyUSB0@19200,8,none,1, read buffer empty,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 20:57:12 5: PMR09: Send called from ProcessRequestQueue
2022.12.13 20:57:12 5: SW: 0a0302580001051a
2022.12.13 20:57:12 5: PMR09: readFn buffer: 0a
2022.12.13 20:57:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 20:57:12 5: PMR09: readFn did not see a valid RTU frame start yet, wait for more data
2022.12.13 20:57:12 5: PMR09: readFn buffer: 0a0302ff
2022.12.13 20:57:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 20:57:12 4: PMR09: ParseFrameStart (RTU, master) extracted id 10, fCode 3 and potential data
2022.12.13 20:57:12 5: PMR09: HandleResponse called from ReadFn
2022.12.13 20:57:12 5: PMR09: ParseResponse called from HandleResponse
2022.12.13 20:57:12 5: PMR09: readFn buffer: 0a0302ffdd9c
2022.12.13 20:57:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 20:57:12 4: PMR09: ParseFrameStart (RTU, master) extracted id 10, fCode 3 and potential data 02ff
2022.12.13 20:57:12 5: PMR09: HandleResponse called from ReadFn
2022.12.13 20:57:12 5: PMR09: ParseResponse called from HandleResponse
2022.12.13 20:57:12 5: PMR09: ParseResponse got incomplete frame. Got 6 but expecting 7 bytes
2022.12.13 20:57:12 5: PMR09: readFn buffer: 0a0302ffdd9c2c
2022.12.13 20:57:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 20:57:12 4: PMR09: ParseFrameStart (RTU, master) extracted id 10, fCode 3 and potential data 02ffdd
2022.12.13 20:57:12 5: PMR09: HandleResponse called from ReadFn
2022.12.13 20:57:12 5: PMR09: ParseResponse called from HandleResponse
2022.12.13 20:57:12 5: PMR09: CheckChecksum (called from ParseResponse): 9c2c is valid
2022.12.13 20:57:12 5: PMR09: now parsing response data objects, master is ModbusTest relay is undefined
2022.12.13 20:57:12 4: PMR09: HandleResponse done, current frame / read buffer: 0a0302ffdd9c2c, id 10, fCode 3,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.07 secs ago, sent 0.07 secs ago,
response: id 10, , fc 3, h . 600, len 1, values ffdd
2022.12.13 20:57:12 5: PMR09: ResetExpect for HandleResponse from response to idle
2022.12.13 20:57:12 5: PMR09: DropFrame called from ReadFn - drop 0a0302ffdd9c2c

...

2022.12.13 23:43:12 5: PMR09: QueueRequest called from DoRequest with h600, qlen 0 from master ModbusTest through io device PMR09
2022.12.13 23:43:12 5: PMR09: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.13 23:43:12 5: PMR09: ProcessRequestQueue called from Fhem internal timer as queue:PMR09, qlen 1, request: request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 23:43:12 5: PMR09: checkDelays commDelay, last communication with same device was 59.937 secs ago, required delay is 0.1
2022.12.13 23:43:12 5: PMR09: checkDelays clientSwitchDelay is not relevant
2022.12.13 23:43:12 5: PMR09: checkDelays sendDelay, last send to same device was 59.998 secs ago, required delay is 0.1
2022.12.13 23:43:12 5: PMR09: checkDelays busDelayRead, last activity on bus was 59.938 secs ago, required delay is 0
2022.12.13 23:43:12 4: PMR09: ProcessRequestQueue (V4.3.15 - 23.1.2021) qlen 1, sending 0a0302580001051a via /dev/ttyUSB0@19200,8,none,1, read buffer empty,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 23:43:12 5: PMR09: Send called from ProcessRequestQueue
2022.12.13 23:43:12 5: SW: 0a0302580001051a
2022.12.13 23:43:12 5: PMR09: readFn buffer: 0a03
2022.12.13 23:43:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 23:43:12 5: PMR09: readFn did not see a valid RTU frame start yet, wait for more data
2022.12.13 23:43:12 5: PMR09: readFn buffer: 0a0302ffdf
2022.12.13 23:43:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 23:43:12 4: PMR09: ParseFrameStart (RTU, master) extracted id 10, fCode 3 and potential data 02
2022.12.13 23:43:12 5: PMR09: HandleResponse called from ReadFn
2022.12.13 23:43:12 5: PMR09: ParseResponse called from HandleResponse
2022.12.13 23:43:12 5: PMR09: ParseResponse got incomplete frame. Got 5 but expecting 7 bytes
2022.12.13 23:43:12 5: PMR09: readFn buffer: 0a0302ffdf1ded
2022.12.13 23:43:12 5: PMR09: ParseFrameStart called from ReadFn protocol RTU expecting id 10
2022.12.13 23:43:12 4: PMR09: ParseFrameStart (RTU, master) extracted id 10, fCode 3 and potential data 02ffdf
2022.12.13 23:43:12 5: PMR09: HandleResponse called from ReadFn
2022.12.13 23:43:12 5: PMR09: ParseResponse called from HandleResponse
2022.12.13 23:43:12 5: PMR09: CheckChecksum (called from ParseResponse): 1ded is valid
2022.12.13 23:43:12 5: PMR09: now parsing response data objects, master is ModbusTest relay is undefined
2022.12.13 23:43:12 4: PMR09: HandleResponse done, current frame / read buffer: 0a0302ffdf1ded, id 10, fCode 3,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.07 secs ago, sent 0.07 secs ago,
response: id 10, , fc 3, h . 600, len 1, values ffdf
2022.12.13 23:43:12 5: PMR09: ResetExpect for HandleResponse from response to idle
2022.12.13 23:43:12 5: PMR09: DropFrame called from ReadFn - drop 0a0302ffdf1ded
2022.12.13 23:44:12 5: PMR09: QueueRequest called from DoRequest with h600, qlen 0 from master ModbusTest through io device PMR09
2022.12.13 23:44:12 5: PMR09: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.13 23:44:12 5: PMR09: ProcessRequestQueue called from Fhem internal timer as queue:PMR09, qlen 1, request: request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 23:44:12 5: PMR09: checkDelays sendDelay, last send to same device was 59.998 secs ago, required delay is 0.1
2022.12.13 23:44:12 5: PMR09: checkDelays busDelayRead, last activity on bus was 59.939 secs ago, required delay is 0
2022.12.13 23:44:12 5: PMR09: checkDelays commDelay, last communication with same device was 59.938 secs ago, required delay is 0.1
2022.12.13 23:44:12 5: PMR09: checkDelays clientSwitchDelay is not relevant
2022.12.13 23:44:12 4: PMR09: ProcessRequestQueue (V4.3.15 - 23.1.2021) qlen 1, sending 0a0302580001051a via /dev/ttyUSB0@19200,8,none,1, read buffer empty,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 23:44:12 5: PMR09: Send called from ProcessRequestQueue
2022.12.13 23:44:12 5: SW: 0a0302580001051a
2022.12.13 23:44:14 3: PMR09: Timeout waiting for a modbus response, read buffer empty,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 2.00 secs ago, sent 2.00 secs ago
2022.12.13 23:45:12 5: PMR09: QueueRequest called from DoRequest with h600, qlen 0 from master ModbusTest through io device PMR09
2022.12.13 23:45:12 5: PMR09: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.13 23:45:12 5: PMR09: ProcessRequestQueue called from Fhem internal timer as queue:PMR09, qlen 1, request: request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 23:45:12 5: PMR09: checkDelays sendDelay, last send to same device was 60.000 secs ago, required delay is 0.1
2022.12.13 23:45:12 5: PMR09: checkDelays busDelayRead, last activity on bus was 119.943 secs ago, required delay is 0
2022.12.13 23:45:12 5: PMR09: checkDelays commDelay, last communication with same device was 119.942 secs ago, required delay is 0.1
2022.12.13 23:45:12 5: PMR09: checkDelays clientSwitchDelay is not relevant
2022.12.13 23:45:12 4: PMR09: ProcessRequestQueue (V4.3.15 - 23.1.2021) qlen 1, sending 0a0302580001051a via /dev/ttyUSB0@19200,8,none,1, read buffer empty,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 23:45:12 5: PMR09: Send called from ProcessRequestQueue
2022.12.13 23:45:12 5: SW: 0a0302580001051a
2022.12.13 23:45:14 3: PMR09: Timeout waiting for a modbus response, read buffer empty,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 2.00 secs ago, sent 2.00 secs ago
2022.12.13 23:46:12 5: PMR09: QueueRequest called from DoRequest with h600, qlen 0 from master ModbusTest through io device PMR09
2022.12.13 23:46:12 5: PMR09: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.13 23:46:12 5: PMR09: ProcessRequestQueue called from Fhem internal timer as queue:PMR09, qlen 1, request: request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 23:46:12 5: PMR09: checkDelays busDelayRead, last activity on bus was 179.941 secs ago, required delay is 0
2022.12.13 23:46:12 5: PMR09: checkDelays sendDelay, last send to same device was 59.995 secs ago, required delay is 0.1
2022.12.13 23:46:12 5: PMR09: checkDelays commDelay, last communication with same device was 179.940 secs ago, required delay is 0.1
2022.12.13 23:46:12 5: PMR09: checkDelays clientSwitchDelay is not relevant
2022.12.13 23:46:12 4: PMR09: ProcessRequestQueue (V4.3.15 - 23.1.2021) qlen 1, sending 0a0302580001051a via /dev/ttyUSB0@19200,8,none,1, read buffer empty,
request: id 10, read fc 3 h600, len 1, master device ModbusTest, reading T10_Außentemperatur (getUpdate for T10_Außentemperatur len 1), queued 0.00 secs ago
2022.12.13 23:46:12 5: PMR09: Send called from ProcessRequestQueue
2022.12.13 23:46:12 5: SW: 0a0302580001051a
2022.12.13 23:46:14 3: PMR09: Timeout waiting for a modbus response, read buffer empty,


Ich hoffe damit kann man was anfangen. Vielen Dank für die Unterstützung.

*** 16.12.2022 editiert ***
Sowie es aussieht, kommen keine Antworten mehr. Deshalb habe ich mit Wireshark den USB mitgeschnitten. Es kommen schon dort keine Antworten mehr zurück wenn die Daten ausfallen. Werde erst mal den USB-RS232 Adapter austauschen und dann sehe ich weiter.
***

Schönen Gruß
Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 14 Dezember 2022, 13:21:01
Zitat von: StefanStrobel am 13 Dezember 2022, 18:42:53
Hallo Roger,
function code 0x42 bzw. 66 existiert nicht im Standard, aber ich könnte das vermutlich ins Modul einbauen.
Ich schau mal ob ich da einen eleganten Weg finde.
Gruss
   Stefan

Hi Stefan,
hier alle Infos zum Reset der Energy.

Das Kommando hat nur 4 Bytes: <slave-Modbus-ID>+0x42+CRC high byte+CRC low byte
Antwort bei Erfolg:           <slave-Modbus-ID>+0x42+CRC high byte+CRC low byte
Fehler Antwort:               <slave-Modbus-ID>+0xC2+<Error Code>+CRC high byte+CRC low byte


Dann gibt es noch ein Kommando für eine Kalibrierung (keine Ahnung, ob man das braucht).

Das Kommando hat 6 Bytes: 0xF8+0x41+0x37+0x21+CRC high byte+CRC low byte
Antwort bei Erfolg:       0xF8+0x41+0x37+0x21+CRC high byte+CRC low byte
Fehler Antwort:           0xF8+0xC1+<Error Code>+CRC high byte+CRC low byte

Die vermisse ich die Modbus-ID --> muss man wohl probieren.

Wenn Du Fragen hast --> bitte fragen. Ansonsten teste ich gern.  :)

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 15 Dezember 2022, 18:27:45
Hallo Roger,

ich hätte da eine experimentelle Erweiterung des Moduls für Dich.
Da gibt es jetzt ein set sendRaw. Dem kannst Du Hex-Werte übergeben und die werden dann zwischen die Modbus-Id und CRC gesetzt und rausgeschickt.
In Deinem Fall also sendRaw 42
Die Antwort kommt dann in einem Reading mit Namen rawResponse- mit angehängtem function code.
Teste das doch mal bei verbose 5. Ob es klappt kann ich nicht sagen, da ich kein passendes Gerät habe.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: rasti am 16 Dezember 2022, 19:50:05
Hallo,

ich hab unter Sonstiges hier => https://forum.fhem.de/index.php/topic,128695.0.html  schonmal dieselbe Anfrage gestellt. Leider hat da keiner geantwortet, vielleicht passt es in diesem Unterforum besser.

Ich habe auch einen Waveshare RS485/Modbus <=> Ethernet POE Modul,
den hier => https://www.waveshare.com/wiki/RS485_TO_POE_ETH_(B)
und mehrere Modbuszähler.
5xSDM72DM und 1x SDM230DM

Das hier habe ich verwendet als Code:

defmod System_Gateway_Modbus_TCP Modbus 192.168.178.20:502
attr System_Gateway_Modbus_TCP room Photovoltaik

defmod Haus_Strom_Meter1 ModbusSDM72DMV2 1 180 TCP
attr Haus_Strom_Meter1 event-on-change-reading .*
attr Haus_Strom_Meter1 room Photovoltaik


Konfig des Gateways ist im Screenshot.

Leider sehe ich keine Daten in FHEM.

System_Gateway_Modbus_TCP erscheint als "opened"
Haus_Strom_Meter1 erscheint als "disconnected"

Mit dem Hölldobler-Gateway => https://hoelldobler.net/Gateway/
funktioniert die Auslese, die Modbus-Verkabelung ist also OK.

Ist in der Konfig des Waveshare alles OK ?
Falls ja, wie mache ich mich hier nun auf Fehlersuche ?

Kann hier jemand helfen ?

Viele Grüße

Ralf

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 16 Dezember 2022, 22:07:45
Zitat von: StefanStrobel am 15 Dezember 2022, 18:27:45
Hallo Roger,
ich hätte da eine experimentelle Erweiterung des Moduls für Dich.
Da gibt es jetzt ein set sendRaw. Dem kannst Du Hex-Werte übergeben und die werden dann zwischen die Modbus-Id und CRC gesetzt und rausgeschickt.
In Deinem Fall also sendRaw 42
Die Antwort kommt dann in einem Reading mit Namen rawResponse- mit angehängtem function code.
Teste das doch mal bei verbose 5. Ob es klappt kann ich nicht sagen, da ich kein passendes Gerät habe.
Gruss  Stefan

Hi Stefan,
es funktioniert - fast.
Also das Kommando wird ausgeführt, da die Energie auf Null gesetzt wurde.
Aber das Reading rawResponse-66 ist leer.

Anbei das Log mit Loglevel 5.
HA_Modbus_1 ist das IO-Device.
HA_PZEM_1 ist das ModbusAttr-Device für das PZEM-003/017 DC-Modul, wo "set HA_PZEM_1 sendRaw 42" ausgeführt wurde.

2022.12.16 21:57:08.003 5: HA_Modbus_1: DropFrame called from ReadFn - drop 01428011
2022.12.16 21:57:07.999 5: HA_Modbus_1: Profiling add 0.025 to sum for Fhem (now is 21:57:07.995, start for Fhem was 21:57:07.970)
2022.12.16 21:57:07.997 5: HA_Modbus_1: Profiling Idle, before Fhem, now is 21:57:07.995, Idle started at 21:56:14.295, Fhem started at 21:57:07.970
2022.12.16 21:57:07.993 5: HA_Modbus_1: ResetExpect for HandleResponse from response to idle
response: id 1, fc 66
request: id 1 fc 999 0, value 3432, master device HA_PZEM_1, reading dummy, queued 0.31 secs ago, sent 0.16 secs ago,
2022.12.16 21:57:07.991 4: HA_Modbus_1: HandleResponse done, current frame / read buffer: 01428011, id 1, fCode 66,
2022.12.16 21:57:07.976 4: HA_Modbus_1: got reply to raw request:
2022.12.16 21:57:07.975 5: HA_Modbus_1: Profiling add 0.020 to sum for Read (now is 21:57:07.970, start for Read was 21:57:07.950)
2022.12.16 21:57:07.972 5: HA_Modbus_1: Profiling Fhem, before Read, now is 21:57:07.970, Fhem started at 21:56:14.276, Read started at 21:57:07.950
2022.12.16 21:57:07.968 5: HA_Modbus_1: CheckChecksum (called from ParseResponse): 8011 is valid
2022.12.16 21:57:07.966 5: HA_Modbus_1: ParseResponse called from HandleResponse
2022.12.16 21:57:07.964 5: HA_Modbus_1: HandleResponse called from ReadFn
2022.12.16 21:57:07.962 4: HA_Modbus_1: ParseFrameStart (RTU, master) extracted id 1, fCode 66 and potential data
2022.12.16 21:57:07.959 5: HA_Modbus_1: ParseFrameStart called from ReadFn protocol RTU expecting id 1
2022.12.16 21:57:07.958 5: HA_Modbus_1: readFn buffer: 01428011
2022.12.16 21:57:07.955 5: HA_Modbus_1: Profiling add 0.095 to sum for Wait (now is 21:57:07.950, start for Wait was 21:57:07.855)
2022.12.16 21:57:07.952 5: HA_Modbus_1: Profiling Read, before Wait, now is 21:57:07.950, Read started at 21:56:14.265, Wait started at 21:57:07.855
2022.12.16 21:57:07.860 5: HA_Modbus_1: Profiling add 0.010 to sum for Send (now is 21:57:07.855, start for Send was 21:57:07.845)
2022.12.16 21:57:07.857 5: HA_Modbus_1: Profiling Wait, before Send, now is 21:57:07.855, Wait started at 21:56:14.162, Send started at 21:57:07.845
2022.12.16 21:57:07.852 5: DevIo_SimpleWrite HA_Modbus_1: 01428011
2022.12.16 21:57:07.851 5: HA_Modbus_1: Profiling add 53.551 to sum for Idle (now is 21:57:07.845, start for Idle was 21:56:14.295)
2022.12.16 21:57:07.848 5: HA_Modbus_1: Profiling Send, before Idle, now is 21:57:07.845, Send started at 21:56:14.156, Idle started at 21:56:14.295
2022.12.16 21:57:07.844 5: HA_Modbus_1: Send called from ProcessRequestQueue
request: id 1 fc 999 0, value 3432, master device HA_PZEM_1, reading dummy, queued 0.16 secs ago
2022.12.16 21:57:07.841 4: HA_Modbus_1: ProcessRequestQueue (V4.4.14 - 14.12.2022) qlen 1, sending 01428011 via /dev/ttyUSB0@9600,8,0,2, read buffer empty,
2022.12.16 21:57:07.838 5: HA_Modbus_1: checkDelays busDelayRead, last activity on bus was 53.567 secs ago, required delay is 1
2022.12.16 21:57:07.836 5: HA_Modbus_1: checkDelays commDelay, last communication with same device was 53.558 secs ago, required delay is 0.7
2022.12.16 21:57:07.835 5: HA_Modbus_1: checkDelays sendDelay, last send to same device was 53.670 secs ago, required delay is 0.7
2022.12.16 21:57:07.833 5: HA_Modbus_1: checkDelays clientSwitchDelay is not relevant
2022.12.16 21:57:07.829 5: HA_Modbus_1: ProcessRequestQueue called from Fhem internal timer as queue:HA_Modbus_1, qlen 1, request: request: id 1 fc 999 0, value 3432, master device HA_PZEM_1, reading dummy, queued 0.14 secs ago
2022.12.16 21:57:07.685 5: HA_Modbus_1: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.16 21:57:07.682 5: HA_Modbus_1: QueueRequest called from ControlSet with 0, qlen 0 from master HA_PZEM_1 through io device HA_Modbus_1


Ich hatte vorher ein "set HA_PZEM_1 stop" ausgeführt, damit das Log sauber ist.

Was brauchst Du noch?

Nachtrag:
Ich finde es verwirrend eine 42 (hex) zu schicken und ein Reading 66 (dec) zu erhalten. Das sollte man gleich machen. (Wobei mir hex besser gefällt.)
Wie sende ich den ein längeres Kommando?
z.B. für die Kalibrierung: 0xF8+0x41+0x37+0x21

//Roger

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Dezember 2022, 11:19:24
Hallo Ralf,

Zitat von: rasti am 16 Dezember 2022, 19:50:05
defmod System_Gateway_Modbus_TCP Modbus 192.168.178.20:502
attr System_Gateway_Modbus_TCP room Photovoltaik

defmod Haus_Strom_Meter1 ModbusSDM72DMV2 1 180 TCP
attr Haus_Strom_Meter1 event-on-change-reading .*
attr Haus_Strom_Meter1 room Photovoltaik

probier doch erst mal einen einzelnen Zähler abzufragen, indem Du ModbusSDM72DMV2 gleich mit der Adresse des Gateways definierst.

Zitat
Konfig des Gateways ist im Screenshot.
was bedeutet dabei Destination IP?
Zitat
System_Gateway_Modbus_TCP erscheint als "opened"
Haus_Strom_Meter1 erscheint als "disconnected"
hast Du beim Haus_Strom_Meter1 ein IODev?
Zitat
Mit dem Hölldobler-Gateway => https://hoelldobler.net/Gateway/
funktioniert die Auslese, die Modbus-Verkabelung ist also OK.
von Fhem aus?
Zitat
Ist in der Konfig des Waveshare alles OK ?
keine Ahnung - ich kennen das Gateway nicht.
Zitat
Falls ja, wie mache ich mich hier nun auf Fehlersuche ?
Kann hier jemand helfen ?
Ein größerer Auszug aus dem Log bei verbose 5 wäre dafür hilfreich

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Dezember 2022, 12:16:51
Hallo Roger,

anbei eine verbesserte Version, bei der das Reading auch erzeugt wird, wenn nach dem function code keine Daten kommen. Zudem ist das Reading in Hex.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 17 Dezember 2022, 19:43:54
Zitat von: StefanStrobel am 17 Dezember 2022, 12:16:51
Hallo Roger,
anbei eine verbesserte Version, bei der das Reading auch erzeugt wird, wenn nach dem function code keine Daten kommen. Zudem ist das Reading in Hex.
Gruss Stefan

Hi Stefan,
etwas besser.
list IHA_PZEM_1 rawResponse-42
HA_PZEM_1            2022-12-17 19:33:49    no data

Aber der Befehl wird ausgeführt!

Hier das Log:

2022.12.17 19:33:49.677 5: HA_Modbus_1: DropFrame called from ReadFn - drop 01428011
2022.12.17 19:33:49.674 5: HA_Modbus_1: Profiling add 0.162 to sum for Fhem (now is 19:33:49.669, start for Fhem was 19:33:49.507)
2022.12.17 19:33:49.671 5: HA_Modbus_1: Profiling Idle, before Fhem, now is 19:33:49.669, Idle started at 19:33:49.669, Fhem started at 19:33:49.507
2022.12.17 19:33:49.668 5: HA_Modbus_1: ResetExpect for HandleResponse from response to idle
response: id 1, fc 66
request: id 1 fc 999 0, value 3432, master device HA_PZEM_1, reading dummy, queued 0.54 secs ago, sent 0.38 secs ago,
2022.12.17 19:33:49.666 4: HA_Modbus_1: HandleResponse done, current frame / read buffer: 01428011, id 1, fCode 66,
2022.12.17 19:33:49.514 4: HA_Modbus_1: got reply to raw request: fCode 42, no data
2022.12.17 19:33:49.512 5: HA_Modbus_1: Profiling add 0.020 to sum for Read (now is 19:33:49.507, start for Read was 19:33:49.488)
2022.12.17 19:33:49.509 5: HA_Modbus_1: Profiling Fhem, before Read, now is 19:33:49.507, Fhem started at 19:33:49.507, Read started at 19:33:49.488
2022.12.17 19:33:49.506 5: HA_Modbus_1: CheckChecksum (called from ParseResponse): 8011 is valid
2022.12.17 19:33:49.503 5: HA_Modbus_1: ParseResponse called from HandleResponse
2022.12.17 19:33:49.501 5: HA_Modbus_1: HandleResponse called from ReadFn
2022.12.17 19:33:49.499 4: HA_Modbus_1: ParseFrameStart (RTU, master) extracted id 1, fCode 66 and potential data
2022.12.17 19:33:49.497 5: HA_Modbus_1: ParseFrameStart called from ReadFn protocol RTU expecting id 1
2022.12.17 19:33:49.495 5: HA_Modbus_1: readFn buffer: 01428011
2022.12.17 19:33:49.493 5: HA_Modbus_1: Profiling add 0.111 to sum for Wait (now is 19:33:49.488, start for Wait was 19:33:49.377)
2022.12.17 19:33:49.490 5: HA_Modbus_1: Profiling Read, before Wait, now is 19:33:49.488, Read started at 19:33:49.488, Wait started at 19:33:49.377
2022.12.17 19:33:49.382 5: HA_Modbus_1: Profiling add 0.050 to sum for Send (now is 19:33:49.377, start for Send was 19:33:49.327)
2022.12.17 19:33:49.379 5: HA_Modbus_1: Profiling Wait, before Send, now is 19:33:49.377, Wait started at 19:33:49.377, Send started at 19:33:49.327
2022.12.17 19:33:49.374 5: DevIo_SimpleWrite HA_Modbus_1: 01428011
2022.12.17 19:33:49.372 5: HA_Modbus_1: Profiling set new sum for Idle to 29.327
2022.12.17 19:33:49.346 5: HA_Modbus_1: Profiling set reading for Idle to 918.424
2022.12.17 19:33:49.344 5: HA_Modbus_1: Profiling set reading for Read to 0.723
2022.12.17 19:33:49.341 5: HA_Modbus_1: Profiling set reading for Send to 0.495
2022.12.17 19:33:49.339 5: HA_Modbus_1: Profiling set reading for Wait to 7.257
2022.12.17 19:33:49.336 5: HA_Modbus_1: Profiling set reading for Fhem to 5.880
2022.12.17 19:33:49.334 5: HA_Modbus_1: Profiling set reading for Delay to 67.221
2022.12.17 19:33:49.332 5: HA_Modbus_1: Profiling add 147.074 to sum for Send
2022.12.17 19:33:49.331 5: HA_Modbus_1: Profiling pPeriod changed, last pPeriod was 1671301 now 1671302, total diff for Idle is 176.40131187439, 29.327 over the pPeriod
2022.12.17 19:33:49.329 5: HA_Modbus_1: Profiling Send, before Idle, now is 19:33:49.327, Send started at 19:30:52.779, Idle started at 19:30:52.925
2022.12.17 19:33:49.325 5: HA_Modbus_1: Send called from ProcessRequestQueue
request: id 1 fc 999 0, value 3432, master device HA_PZEM_1, reading dummy, queued 0.18 secs ago
2022.12.17 19:33:49.304 4: HA_Modbus_1: ProcessRequestQueue (V4.4.14 - 14.12.2022) qlen 1, sending 01428011 via /dev/ttyUSB0@9600,8,0,2, read buffer empty,
2022.12.17 19:33:49.300 5: HA_Modbus_1: checkDelays clientSwitchDelay is not relevant
2022.12.17 19:33:49.298 5: HA_Modbus_1: checkDelays sendDelay, last send to same device was 176.510 secs ago, required delay is 0.7
2022.12.17 19:33:49.297 5: HA_Modbus_1: checkDelays commDelay, last communication with same device was 176.416 secs ago, required delay is 0.7
2022.12.17 19:33:49.295 5: HA_Modbus_1: checkDelays busDelayRead, last activity on bus was 176.422 secs ago, required delay is 1
2022.12.17 19:33:49.291 5: HA_Modbus_1: ProcessRequestQueue called from Fhem internal timer as queue:HA_Modbus_1, qlen 1, request: request: id 1 fc 999 0, value 3432, master device HA_PZEM_1, reading dummy, queued 0.16 secs ago
2022.12.17 19:33:49.128 5: HA_Modbus_1: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.17 19:33:49.125 5: HA_Modbus_1: QueueRequest called from ControlSet with 0, qlen 0 from master HA_PZEM_1 through io device HA_Modbus_1


Vielen Dank für Deine Mühe.
//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Dezember 2022, 20:46:34
Hallo Roger,

Das Gerät schickt als Antwort nur den function code ohne Daten zurück. Deshalb no data.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 17 Dezember 2022, 22:33:04
Zitat von: StefanStrobel am 17 Dezember 2022, 20:46:34
Hallo Roger,
Das Gerät schickt als Antwort nur den function code ohne Daten zurück. Deshalb no data.
Gruss  Stefan

Hi Stefan,
OK verstanden.
Ich habe mal versucht andere FC zu schicken - aber da scheint keine Antwort zu erfolgen, wohl auch keine Fehlermeldung.

Wie schicke ich denn mehrere Bytes mit sendRaw?
Zur Vollständigkeit hätte ich gern noch die Kalibrierung mit : 0xF8+0x41+0x37+0x21
(Eventuell ist mit F8 die Modbus ID gemeint - muss ich aber probieren.)

Edit
Es erfolgt doch eine Fehlerantwort. Diese wird nur nicht in ein Reading geschrieben, da sie nicht mit dem ursprünglichen fc kommt sondern mit C1 (193 dec).
Log:

2022.12.17 22:27:45.858 5: HA_Modbus_1: DropFrame called from ReadFn - drop 01c1033191
2022.12.17 22:27:45.855 5: HA_Modbus_1: Profiling add 0.012 to sum for Fhem (now is 22:27:45.851, start for Fhem was 22:27:45.838)
2022.12.17 22:27:45.852 5: HA_Modbus_1: Profiling Idle, before Fhem, now is 22:27:45.851, Idle started at 22:27:02.599, Fhem started at 22:27:45.838
2022.12.17 22:27:45.849 5: HA_Modbus_1: ResetExpect for HandleResponse from response to idle
response: id 1, fc 193, error code 03
request: id 1 fc 999 0, value 343133373231, master device HA_PZEM_1, reading dummy, queued 0.62 secs ago, sent 0.48 secs ago,
2022.12.17 22:27:45.847 4: HA_Modbus_1: HandleResponse done, current frame / read buffer: 01c1033191, id 1, fCode 193,
2022.12.17 22:27:45.844 4: HA_Modbus_1: HandleResponse got response with error code c1 / 03, illegal data value
2022.12.17 22:27:45.843 5: HA_Modbus_1: Profiling add 0.020 to sum for Read (now is 22:27:45.838, start for Read was 22:27:45.818)
2022.12.17 22:27:45.840 5: HA_Modbus_1: Profiling Fhem, before Read, now is 22:27:45.838, Fhem started at 22:27:02.555, Read started at 22:27:45.818
2022.12.17 22:27:45.836 5: HA_Modbus_1: CheckChecksum (called from ParseResponse): 3191 is valid
2022.12.17 22:27:45.834 5: HA_Modbus_1: ParseResponse called from HandleResponse
2022.12.17 22:27:45.832 5: HA_Modbus_1: HandleResponse called from ReadFn
2022.12.17 22:27:45.830 4: HA_Modbus_1: ParseFrameStart (RTU, master) extracted id 1, fCode 193 and potential data 03
2022.12.17 22:27:45.828 5: HA_Modbus_1: ParseFrameStart called from ReadFn protocol RTU expecting id 1
2022.12.17 22:27:45.826 5: HA_Modbus_1: readFn buffer: 01c1033191
2022.12.17 22:27:45.824 5: HA_Modbus_1: Profiling add 0.423 to sum for Wait (now is 22:27:45.818, start for Wait was 22:27:45.396)
2022.12.17 22:27:45.821 5: HA_Modbus_1: Profiling Read, before Wait, now is 22:27:45.818, Read started at 22:27:02.547, Wait started at 22:27:45.396
2022.12.17 22:27:45.400 5: HA_Modbus_1: Profiling add 0.010 to sum for Send (now is 22:27:45.396, start for Send was 22:27:45.386)
2022.12.17 22:27:45.398 5: HA_Modbus_1: Profiling Wait, before Send, now is 22:27:45.396, Wait started at 22:27:02.471, Send started at 22:27:45.386
2022.12.17 22:27:45.392 5: DevIo_SimpleWrite HA_Modbus_1: 0141372187e4
2022.12.17 22:27:45.391 5: HA_Modbus_1: Profiling add 42.787 to sum for Idle (now is 22:27:45.386, start for Idle was 22:27:02.599)
2022.12.17 22:27:45.388 5: HA_Modbus_1: Profiling Send, before Idle, now is 22:27:45.386, Send started at 22:27:02.466, Idle started at 22:27:02.599
2022.12.17 22:27:45.384 5: HA_Modbus_1: Send called from ProcessRequestQueue
request: id 1 fc 999 0, value 343133373231, master device HA_PZEM_1, reading dummy, queued 0.15 secs ago
2022.12.17 22:27:45.382 4: HA_Modbus_1: ProcessRequestQueue (V4.4.14 - 14.12.2022) qlen 1, sending 0141372187e4 via /dev/ttyUSB0@9600,8,0,2, read buffer empty,
2022.12.17 22:27:45.378 5: HA_Modbus_1: checkDelays sendDelay, last send to same device was 42.901 secs ago, required delay is 0.7
2022.12.17 22:27:45.376 5: HA_Modbus_1: checkDelays clientSwitchDelay is not relevant
2022.12.17 22:27:45.375 5: HA_Modbus_1: checkDelays busDelayRead, last activity on bus was 42.826 secs ago, required delay is 1
2022.12.17 22:27:45.373 5: HA_Modbus_1: checkDelays commDelay, last communication with same device was 42.819 secs ago, required delay is 0.7
2022.12.17 22:27:45.370 5: HA_Modbus_1: ProcessRequestQueue called from Fhem internal timer as queue:HA_Modbus_1, qlen 1, request: request: id 1 fc 999 0, value 343133373231, master device HA_PZEM_1, reading dummy, queued 0.14 secs ago
2022.12.17 22:27:45.228 5: HA_Modbus_1: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2022.12.17 22:27:45.225 5: HA_Modbus_1: QueueRequest called from ControlSet with 0, qlen 0 from master HA_PZEM_1 through io device HA_Modbus_1


//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: rasti am 18 Dezember 2022, 00:58:42
Hallo Stefan,

vielen Dank es funzt nun !

Zitat von: StefanStrobel am 17 Dezember 2022, 11:19:24
Hallo Ralf,
probier doch erst mal einen einzelnen Zähler abzufragen, indem Du ModbusSDM72DMV2 gleich mit der Adresse des Gateways definierst.

Genau das war der richtige Hinweis, es funktioniert  ;D ;D ;D

define Haus_Strom_Meter1 ModbusSDM72DMV2 1 60 192.168.178.20:502 TCP
attr Haus_Strom_Meter1 room Photovoltaik

define Haus_Strom_Meter2 ModbusSDM72DMV2 2 60 192.168.178.20:502 TCP
attr Haus_Strom_Meter2 room Photovoltaik

define Haus_Strom_Meter3 ModbusSDM72DMV2 3 60 192.168.178.20:502 TCP
attr Haus_Strom_Meter3 room Photovoltaik

define Haus_Strom_Meter4 ModbusSDM72DMV2 4 60 192.168.178.20:502 TCP
attr Haus_Strom_Meter4 room Photovoltaik

define Haus_Strom_Meter5 ModbusSDM72DMV2 5 60 192.168.178.20:502 TCP
attr Haus_Strom_Meter5 room Photovoltaik

define Haus_Strom_Meter6 ModbusSDM72DMV2 1 60 192.168.178.20:502 TCP
attr Haus_Strom_Meter1 room Photovoltaik



Zitat
was bedeutet dabei Destination IP?

Gute Frage, keine Ahnung. Geht jetzt jedenfalls mit genau der Einstellung im Screenshot und dem obigen Code. :)

Übrigens habe ich 3phasige SDM72 und 1phasige SDM230 gemischt, geht alles mit o.g. SDM72 Modul, weil die Registerbelegung gleich ist.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: rasti am 18 Dezember 2022, 03:27:01
Hier ein wenig Code :

define Haus_Strom_Meter5 ModbusSDM72DMV2 5 60 192.168.178.20:502 TCP
attr Haus_Strom_Meter5 userattr stateFormat
attr Haus_Strom_Meter5 alias 5 - Wärmepumpe
attr Haus_Strom_Meter5 room Photovoltaik
attr Haus_Strom_Meter5 stateFormat {sprintf("Energy: %.0f kWh", (ReadingsVal($name,"Energy_import__kWh",0) ) )." / Power:". sprintf("%.0f W", ReadingsVal($name,"Power_Sum__W",0)). " / L1:" . sprintf("%.0f W", ReadingsVal($name,"Power_L1__W",0)). " / L2:" . sprintf("%.0f W", ReadingsVal($name,"Power_L2__W",0)). " / L3:" . sprintf("%.0f W", ReadingsVal($name,"Power_L3__W",0))}

define Haus_Strom_Meter6 ModbusSDM72DMV2 6 60 192.168.178.20:502 TCP
attr Haus_Strom_Meter6 userattr stateFormat
attr Haus_Strom_Meter6 alias 6 - Klima Wohnzimmer
attr Haus_Strom_Meter6 room Photovoltaik
attr Haus_Strom_Meter6 stateFormat {sprintf("Energy: %.0f kWh", (ReadingsVal($name,"Energy_import__kWh",0) ) )." / Power:". sprintf("%.0f W", ReadingsVal($name,"Power_L1__W",0))}



Haus_Strom_Meter5 ist für SDM72, Haus_Strom_Meter6 ist ein SDM230



Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 Dezember 2022, 08:56:54
Zitat von: Roger am 17 Dezember 2022, 22:33:04
Wie schicke ich denn mehrere Bytes mit sendRaw?
Zur Vollständigkeit hätte ich gern noch die Kalibrierung mit : 0xF8+0x41+0x37+0x21
(Eventuell ist mit F8 die Modbus ID gemeint - muss ich aber probieren.)

Edit
Es erfolgt doch eine Fehlerantwort. Diese wird nur nicht in ein Reading geschrieben, da sie nicht mit dem ursprünglichen fc kommt sondern mit C1 (193 dec).

Hallo Roger,

mehrere Bytes einfach als Hex-String: F8413721
wegen der Fehlermeldung müsste ich das ganze aber evt. doch noch mal umbauen.
Evt. als sendFC, damit man explizit einen function code setzen kann und die Antwort bzw. der zugehörige Fehler erkennbar ist.
Oder sogar als Definition des function codes mit Informationen zum Parsen ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 18 Dezember 2022, 11:28:42
Zitat von: StefanStrobel am 18 Dezember 2022, 08:56:54
Hallo Roger,
mehrere Bytes einfach als Hex-String: F8413721
wegen der Fehlermeldung müsste ich das ganze aber evt. doch noch mal umbauen.
Evt. als sendFC, damit man explizit einen function code setzen kann und die Antwort bzw. der zugehörige Fehler erkennbar ist.
Oder sogar als Definition des function codes mit Informationen zum Parsen ...
Gruss Stefan

Hi Stefan,
in diese Richtung gingen auch meine Überlegungen.  :)
So ein sendRaw ist in Modbus als IO besser aufgehoben. Dann aber als wirkliches RAW (ohne Modbus-ID, aber schon mit CRC?).
Dort könnten dann ev. nicht zuordenbare Empfänge (z.B. C1, C2) in Readings abgelegt werden.

Das sendFC wie bisher in ModbusAttr mit den Empfangs-Readings ResponseFC-xx.

Was hältst Du davon? Soll ja für viele User nutzbar sein und Mehrwert bringen (z.B. zum testen/probieren).

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: ChristianA am 22 Dezember 2022, 09:10:08
Hallo,

meine Vermutung scheint sich zu bestätigen. Seit dem Tausch des USB-Seriell Adapters ist die Verbindung seit 16 Stunden stabil.

Zitat von: ChristianA am 09 Dezember 2022, 21:16:41
seit einigen Tagen läuft bei mir die Modbus Verbindung nicht mehr stabil. Nach einem Neustart funktioniert es für 1-2 Stunden, dann können keine Werte mehr gelesen werden. Im Logfile bekomme ich folgende Meldungen


2022.12.09 20:33:50 3: PMR09: Timeout waiting for a modbus response, read buffer empty,


Auf Grund der Logmeldung habe ich den USB Port mit Wireshark mitgeschnitten. Damit war dann klar, die fehlende Antwort kam dort schon nicht durch.

Vielen Dank und schöne Weihnachten
Christian
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Kulli am 03 Januar 2023, 14:58:44
Hallo Stefan

Gibt es im Modbus Modul eine Möglichkeit, das Timeouts als Events gemeldet werden?
Bei mir scheint durch Blitz ein Modbusmodul hops gegangen zu sein und ich habe es nicht mitbekommen.
Aktuell sehe ich nur die Möglichkeit, den Loglevel auf 3 zu setzen um die Meldungen im Log zu sehen, da kann ich aber nicht darauf reagieren :-)

LG
Uwe

Ergänzung:
Der MAX485 ist gestorben. Ich habe am gleichen Bus 3 andere Slaves hängen mit dem LTC485, die haben alle überlebt.
Also ich muss mir etwas bzgl. Schirmung und Erdung überlegen.
Nichtsdestotrotz: Wie kann ich notifies triggern wenn Timeouts auftreten?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: mani am 03 Januar 2023, 19:52:59
Hallo,

ich habe von Waveshare das 2-CH-Rs485-Can-HAT gekauft und lt. Anleitung aktiviert. Nun habe ich die zwei neuen Schnittstellen  /dev/ttySC0 und /dev/ttySC1 aber wenn ich auf sie zugreifen möchte mit Modbusmodul bekomme ich nur die Fehlermeldung =>


2023.01.03 18:59:14 3 : modbus: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 4 i0, len 17, master device WS, reading raw (getUpdate for raw len 17), queued 9.01 secs ago, sent 2.00 secs ago
[/s]

Läuft war doch noch ein rechte Problem..... ::)

Mfg Mani
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 07 Januar 2023, 20:53:12
Zitat von: Kulli am 03 Januar 2023, 14:58:44
Hallo Stefan
Gibt es im Modbus Modul eine Möglichkeit, das Timeouts als Events gemeldet werden?
Bei mir scheint durch Blitz ein Modbusmodul hops gegangen zu sein und ich habe es nicht mitbekommen.
Aktuell sehe ich nur die Möglichkeit, den Loglevel auf 3 zu setzen um die Meldungen im Log zu sehen, da kann ich aber nicht darauf reagieren :-)
LG Uwe

Hi Stefan,
daran hätte ich auch Interesse. Wenn bei meinem Modulen keine Spannung anliegt, so werden keine Daten gesendet (timeout). Wäre schön, wenn man für diesen Zustand eine Möglichkeit hätte einen speziellen Wert zu setzen (n/a, 0, ...).

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 07 Januar 2023, 20:57:02
Zitat von: Roger am 18 Dezember 2022, 11:28:42
Hi Stefan,
in diese Richtung gingen auch meine Überlegungen.  :)
So ein sendRaw ist in Modbus als IO besser aufgehoben. Dann aber als wirkliches RAW (ohne Modbus-ID, aber schon mit CRC?).
Dort könnten dann ev. nicht zuordenbare Empfänge (z.B. C1, C2) in Readings abgelegt werden.
Das sendFC wie bisher in ModbusAttr mit den Empfangs-Readings ResponseFC-xx.
Was hältst Du davon? Soll ja für viele User nutzbar sein und Mehrwert bringen (z.B. zum testen/probieren).
//Roger

Hi Stefan,
ich wollte mal nachfragen wie Du zu der Änderung stehst? Ist die Idee zu aufwändig? Schafft es so eine Änderung ins offizielle Modul?

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 09 Januar 2023, 19:56:08
Hallo Roger,

klingt durchaus sinnvoll. Ich bin nur leider noch nicht dazu gekommen an dem Thema weiter zu machen.
Auch die Events im Fall von Timeouts werde ich einbauen.
Könnte aber noch ein paar Tage oder sogar Wochen dauern.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 23 Januar 2023, 20:38:26
Hallo,

unterstützt das Modul auch "Preset Single Register (FC=06)"?
Falls nein, kann man das irgendwie manuell schreiben?

In der Beschreibung ist nur die Rede von folgenden function codes:
holding registers (16 bit objects that can be read and written)
input registers (16 bit objects that can only be read)
coils (single bit objects that can be read and written)
discrete inputs (single bit objects that can only be read)


Danke vorab!

Hab's selbst kapiert: 06 sollte Holding Write sein, richtig?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Januar 2023, 22:21:58
Korrekt. FC6 schreibt ein Holding Register und wird ebenso wie FC16 zum Schreiben mehrerer Holding Register unterstützt.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 24 Januar 2023, 18:43:20
Danke Stefan für die Bestätigung.

Ich habe noch 2 Fragen zu dem Modul auch wenn ich es schon längere Zeit nutze...

1. ich würde gerne einen Wert in ein Holding Register schreiben und benutze folgende Definition (Master Mode):
attr Qcells obj-h97-allowWrite 1
attr Qcells obj-h97-len 1
attr Qcells obj-h97-poll 0
attr Qcells obj-h97-reading QC_WriteSelfUseMinBatSoC


Für QC_WriteSelfUseMinBatSoC habe ich ein Dummy angelegt. Wie kann ich den Schreibvorgang triggern? Reicht ein ändern des Wertes im dummy, oder muss ich sonst noch was machen?

2. Für ein anderes Reading muss ich ein Byte des int Wertes ausmaskieren, wie kann ich das realisieren? Im unpack Attribute, oder gibt es hierfür noch eine andere Möglichkeit?

Besten Dank vorab!


Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 24 Januar 2023, 20:13:02
Hallo Tomk,

zum Schreiben musst Du einen set-Befehl verwenden.

attr Qcells obj-h97-reading MeinWert
attr Qcells obj-h97-set 1


dann mit
set Qcells MeinWert 123
zum Manipulieren / Maskieren des Wertes würde ich eine setexpr verwenden.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 28 Januar 2023, 06:33:14
So ganz klappt es mit dem Schreiben bei mir noch nicht... Bekomme scheinbar keine Antwort. Lesen von Werten funktioniert...

Kann man am Log was verdächtiges erkennen:
2023.01.28 06:16:22 4: Qcells: set called with QC_WriteSelfUseMinBatSoC (h97) setVal = 28
2023.01.28 06:16:22 5: Qcells: GetSetChecks with force
2023.01.28 06:16:22 5: Qcells: GetSetChecks returns success
2023.01.28 06:16:22 5: Qcells: set packed hex 3238 with n to hex 001c
2023.01.28 06:16:22 4: Qcells: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC)
2023.01.28 06:16:22 5: Qcells: ParseDataString called from HandleResponse with data hex 001c, type h, adr 97, op write
2023.01.28 06:16:22 5: Qcells: SplitDataString called from ParseDataString with data hex 001c, type h, adr 97, valuesLen 1, op write
2023.01.28 06:16:22 5: Qcells: CreateDataObjects called from ParseDataString with objList h97
2023.01.28 06:16:22 5: Qcells: CreateDataObjects sortedList h97
2023.01.28 06:16:22 5: Qcells: CreateParseInfoCache called
2023.01.28 06:16:22 5: Qcells: CreateDataObjects unpacked 001c with n to 28
2023.01.28 06:16:22 4: Qcells: CreateDataObjects assigns value 28 to QC_WriteSelfUseMinBatSoC
2023-01-28 06:16:22 ModbusAttr Qcells QC_WriteSelfUseMinBatSoC: 28
2023.01.28 06:16:22 5: Qcells: ParseDataString created 1 readings
2023.01.28 06:16:22 4: Qcells: GetUpdate (V4.4.13 - 4.12.2022) called from Fhem internal timer
2023.01.28 06:16:22 4: Qcells: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 2.0 sec at 06:16:24.890, interval 2
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Januar 2023, 19:41:41
Hallo Tomk,

leider fehlen im Log ein paar Details. Vermutlich geht dein Qcells-Device über ein serielles IO-Device. Das müsstest Du auch auf verbose 5 setzen.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tomk am 29 Januar 2023, 21:34:48
Hallo Stefan,

danke für den Hinweis. Hätte ich auch drauf kommen können...

Hier sollte alles drin sein:
2023.01.29 21:23:45 4: Qcells: set called with QC_WriteSelfUseMinBatSoC (h97) setVal = 28
2023.01.29 21:23:45 5: Qcells: GetSetChecks with force
2023.01.29 21:23:45 4: Qcells: GetSetChecks calls ReadAnswer to take over async read, still waiting for response, read buffer empty,
request: id 1, read fc 3 h139, len 1, master device Qcells, reading QC_Mode (getUpdate for QC_Mode len 1), queued 6.54 secs ago, sent 0.01 secs ago
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer called from GetSetChecks
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer remaining timeout is 1.98934698104858
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer got: 0103020000b844
2023.01.29 21:23:45 5: QCellsModbus: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.01.29 21:23:45 4: QCellsModbus: ParseFrameStart (RTU, master) extracted id 1, fCode 3 and potential data 020000
2023.01.29 21:23:45 5: QCellsModbus: HandleResponse called from ReadAnswer
2023.01.29 21:23:45 5: QCellsModbus: ParseResponse called from HandleResponse
2023.01.29 21:23:45 5: QCellsModbus: CheckChecksum (called from ParseResponse): b844 is valid
2023.01.29 21:23:45 5: QCellsModbus: now parsing response data objects, master is Qcells relay is undefined
2023.01.29 21:23:45 5: Qcells: ParseDataString called from HandleResponse with data hex 0000, type h, adr 139, op read
2023.01.29 21:23:45 5: Qcells: SplitDataString called from ParseDataString with data hex 0000, type h, adr 139, valuesLen 1, op read
2023.01.29 21:23:45 5: Qcells: CreateDataObjects called from ParseDataString with objList h139
2023.01.29 21:23:45 5: Qcells: CreateDataObjects sortedList h139
2023.01.29 21:23:45 5: Qcells: CreateParseInfoCache called
2023.01.29 21:23:45 5: Qcells: CreateDataObjects unpacked 0000 with n to 0
2023.01.29 21:23:45 4: Qcells: CreateDataObjects assigns value 0 to QC_Mode
2023.01.29 21:23:45 5: Qcells: ParseDataString created 1 readings
2023.01.29 21:23:45 4: QCellsModbus: HandleResponse done, current frame / read buffer: 0103020000b844, id 1, fCode 3,
request: id 1, read fc 3 h139, len 1, master device Qcells, reading QC_Mode (getUpdate for QC_Mode len 1), queued 6.56 secs ago, sent 0.02 secs ago,
response: id 1, fc 3, h139, len 1, values 0000
2023.01.29 21:23:45 5: QCellsModbus: ResetExpect for HandleResponse from response to idle
2023.01.29 21:23:45 5: QCellsModbus: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2023.01.29 21:23:45 5: QCellsModbus: DropFrame called from ReadAnswer - drop 0103020000b844
2023.01.29 21:23:45 5: Qcells: GetSetChecks returns success
2023.01.29 21:23:45 5: Qcells: set packed hex 3238 with n to hex 001c
2023.01.29 21:23:45 4: Qcells: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC)
2023.01.29 21:23:45 5: QCellsModbus: QueueRequest called from DoRequest with h97, qlen 30 from master Qcells through io device QCellsModbus
2023.01.29 21:23:45 5: QCellsModbus: ProcessRequestQueue called from QueueRequest as direct:QCellsModbus, qlen 31, force, request: request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC), queued 0.00 secs ago
2023.01.29 21:23:45 5: QCellsModbus: checkDelays clientSwitchDelay is not relevant
2023.01.29 21:23:45 5: QCellsModbus: checkDelays commDelay, last communication with same device was 0.026 secs ago, required delay is 0.1
2023.01.29 21:23:45 5: QCellsModbus: checkDelays sendDelay, last send to same device was 0.037 secs ago, required delay is 0.1
2023.01.29 21:23:45 5: QCellsModbus: checkDelays busDelayRead, last activity on bus was 0.027 secs ago, required delay is 0
2023.01.29 21:23:45 4: QCellsModbus: checkDelays found commDelay not over, sleep for 0.074 forced
2023.01.29 21:23:45 4: QCellsModbus: checkDelays sleep done, go on with sending
2023.01.29 21:23:45 4: QCellsModbus: ProcessRequestQueue (V4.4.13 - 4.12.2022) qlen 31, sending 01060061001cd9dd via /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@19200,8,E,1, read buffer empty,
request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC), queued 0.08 secs ago,
response: no id, no fcode
2023.01.29 21:23:45 5: QCellsModbus: Send called from ProcessRequestQueue
2023.01.29 21:23:45 5: DevIo_SimpleWrite QCellsModbus: 01060061001cd9dd
2023.01.29 21:23:45 5: QCellsModbus: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer called from SetLDFn
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer remaining timeout is 1.90582013130188
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer got: 01060061001cd9dd
2023.01.29 21:23:45 5: QCellsModbus: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.01.29 21:23:45 4: QCellsModbus: ParseFrameStart (RTU, master) extracted id 1, fCode 6 and potential data 0061001c
2023.01.29 21:23:45 5: QCellsModbus: HandleResponse called from ReadAnswer
2023.01.29 21:23:45 5: QCellsModbus: ParseResponse called from HandleResponse
2023.01.29 21:23:45 5: QCellsModbus: CheckChecksum (called from ParseResponse): d9dd is valid
2023.01.29 21:23:45 5: QCellsModbus: now parsing response data objects, master is Qcells relay is undefined
2023.01.29 21:23:45 5: Qcells: ParseDataString called from HandleResponse with data hex 001c, type h, adr 97, op write
2023.01.29 21:23:45 5: Qcells: SplitDataString called from ParseDataString with data hex 001c, type h, adr 97, valuesLen 1, op write
2023.01.29 21:23:45 5: Qcells: CreateDataObjects called from ParseDataString with objList h97
2023.01.29 21:23:45 5: Qcells: CreateDataObjects sortedList h97
2023.01.29 21:23:45 5: Qcells: CreateParseInfoCache called
2023.01.29 21:23:45 5: Qcells: CreateDataObjects unpacked 001c with n to 28
2023.01.29 21:23:45 4: Qcells: CreateDataObjects assigns value 28 to QC_WriteSelfUseMinBatSoC
2023-01-29 21:23:45 ModbusAttr Qcells QC_WriteSelfUseMinBatSoC: 28
2023.01.29 21:23:45 5: Qcells: ParseDataString created 1 readings
2023.01.29 21:23:45 4: QCellsModbus: HandleResponse done, current frame / read buffer: 01060061001cd9dd, id 1, fCode 6,
request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC), queued 0.13 secs ago, sent 0.13 secs ago,
response: id 1, fc 6, h97, len 1, values 001c
2023.01.29 21:23:45 5: QCellsModbus: ResetExpect for HandleResponse from response to idle
2023.01.29 21:23:45 5: QCellsModbus: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2023.01.29 21:23:45 5: QCellsModbus: DropFrame called from ReadAnswer - drop 01060061001cd9dd


Ich habe noch einige andere zyklische Abfragen welche hier in die Quere gekommen sind, glaube ich.

Moment... es geht... konnte gerade in der App des Wechselrichter sehen das die 28% angenommen wurden... keine Ahnung warum das gestern nicht geklappt hat.

Super, danke dir trotzdem!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 29 Januar 2023, 21:39:39
Hallo zusammen!

Ich habe FHEM am 23.01. seit längerem (genauer: seit 02.10.22) wieder mal aktualisiert und jetzt werden einige Werte von meinem Fronius Gen24 nicht mehr gelesen. Ulkigerweise betrifft es nur einen Teil der Werte und mir fehlt komplett die Idee, woran es liegen kann.

Beispiel 1:


attr gen24 obj-h40267-format %d
attr gen24 obj-h40267-group 1-1
attr gen24 obj-h40267-len 1
attr gen24 obj-h40267-reading DCPowerScale
attr gen24 obj-h40267-unpack s>
attr gen24 obj-h40284-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr gen24 obj-h40284-group 1-2
attr gen24 obj-h40284-len 1
attr gen24 obj-h40284-reading DCPowerMPPT1
attr gen24 obj-h40284-unpack n
attr gen24 obj-h40304-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr gen24 obj-h40304-group 1-3
attr gen24 obj-h40304-len 1
attr gen24 obj-h40304-reading DCPowerMPPT2
attr gen24 obj-h40304-unpack n
attr gen24 obj-h40324-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr gen24 obj-h40324-group 1-4
attr gen24 obj-h40324-len 1
attr gen24 obj-h40324-reading BatteryChargeWatt
attr gen24 obj-h40324-unpack n
attr gen24 obj-h40344-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr gen24 obj-h40344-group 1-5
attr gen24 obj-h40344-len 1
attr gen24 obj-h40344-reading BatteryDischargeWatt
attr gen24 obj-h40344-unpack n


Hier funktionieren DCPowerScale und DCPowerMPPT1 einwandfrei, während die folgenden Werte DCPowerMPPT2, BatteryChargeWatt und BatteryDischargeWatt bei einem "set gen24 reread" nicht mehr aktualisiert werden.

Im Log sieht das dann so aus:


2023.01.29 20:42:14 4 : gen24: ProcessRequestQueue (V4.4.13 - 4.12.2022) qlen 1, sending 00db0000000601039d4b0064 via 192.168.YY.XX:502, read buffer empty,
request: id 1, read fc 3 h40267, len 100, tid 219, master device gen24, reading DCPowerScale (getUpdate for combined g1 len 78 (h40267 len 1 DCPowerScale and h40284 len 1 DCPowerMPPT1 and h40304 len 1 DCPowerMPPT2 and h40324 len 1 BatteryChargeWatt and h40344 len 1 BatteryDischargeWatt) with h40355 len 1 BatConfigMaxReferenceWatt and h40358 len 1 BatConfigMaxEnabled and h40360 len 1 BatConfigReserve and h40361 len 1 BatteryChargePercent and h40364 len 1 BatteryState and h40365 len 1 BatConfigMaxDischargeWatt and h40366 len 1 BatConfigMaxChargeWatt), queued 0.36 secs ago
2023.01.29 20:42:14 4 : gen24: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 219, dlen 203 and potential data c8fffefffeffffffff0004ffff00014d50505420310000000000000000000000000bf80000294b52722b6988958000ffffffffffff00024d505054203200000000000000000000000014f9000025898b4a2b6988958000ffffffffffff000353744368612033000000000000000000000000000000000000002b6988958000ffffffffffff00045374446973436861203400000000000026744d994c5908acfc7e2b6988958000ffffffffffff007c00181400006400640003ffff05dc064affffffff00030b710f42
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 5120.0 to BatConfigMaxReferenceWatt
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value bothMax to BatConfigMaxEnabled
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 16.1 to BatteryChargePercent
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value discharging to BatteryState
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 1499.6 to BatConfigMaxDischargeWatt
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 1999.9 to BatConfigMaxChargeWatt
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value -2 to DCPowerScale
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 0.0 to DCPowerMPPT1
2023.01.29 20:42:14 4 : gen24: HandleResponse done, current frame / read buffer: 00db000000cb0103c8fffefffeffffffff0004ffff00014d50505420310000000000000000000000000bf80000294b52722b6988958000ffffffffffff00024d505054203200000000000000000000000014f9000025898b4a2b6988958000ffffffffffff000353744368612033000000000000000000000000000000000000002b6988958000ffffffffffff00045374446973436861203400000000000026744d994c5908acfc7e2b6988958000ffffffffffff007c00181400006400640003ffff05dc064affffffff00030b710f42, id 1, fCode 3, tid 219,


Bei den "assigns value"-Zeilen taucht also nur noch DCPowerMPPT1 auf, dann ist Schluss, die folgenden Werte fehlen.

Es betrifft auch noch andere Werte, die nicht in einer Group sind:

attr gen24 obj-h40360-expr $val / 100
attr gen24 obj-h40360-len 1
attr gen24 obj-h40360-reading BatConfigReserve
attr gen24 obj-h40360-unpack n
attr gen24 obj-h40361-expr $val / 100
attr gen24 obj-h40361-len 1
attr gen24 obj-h40361-reading BatteryChargePercent
attr gen24 obj-h40361-unpack n


Hier funktioniert BatteryChargePercent, während BatConfigReserve nicht aktualisiert wird.

Seit meinem letzten Update am 2.10. gab es zwei Änderungen in 98_Modbus.pm, aber ich habe ein bisschen probiert und bin mir ziemlich sicher, dass das Problem durch die letzte Änderung reingekommen ist: https://svn.fhem.de/trac/changeset/26789/trunk/fhem/FHEM/98_Modbus.pm. Leider ist die Änderung halbwegs umfangreich und ich habe keine rechte Idee, was mein Problem auslösen könnte...

Ersetze ich bei mir die Datei durch die letzte Version https://svn.fhem.de/trac/export/26497/trunk/fhem/FHEM/98_Modbus.pm ("Modbus 4.4.11 - 5.10.2022"), gefolgt von einem "shutdown restart", dann funktioniert wieder alles einwandfrei:


2023.01.29 21:15:39 4 : gen24: ProcessRequestQueue (V4.4.11 - 5.10.2022) qlen 1, sending 00680000000601039d4b0064 via 192.168.YY.XX:502, read buffer empty,
request: id 1, read fc 3 h40267, len 100, tid 104, master device gen24, reading DCPowerScale (getUpdate for combined g1 len 78 (h40267 len 1 DCPowerScale and h40284 len 1 DCPowerMPPT1 and h40304 len 1 DCPowerMPPT2 and h40324 len 1 BatteryChargeWatt and h40344 len 1 BatteryDischargeWatt) with h40355 len 1 BatConfigMaxReferenceWatt and h40358 len 1 BatConfigMaxEnabled and h40360 len 1 BatConfigReserve and h40361 len 1 BatteryChargePercent and h40364 len 1 BatteryState and h40365 len 1 BatConfigMaxDischargeWatt and h40366 len 1 BatConfigMaxChargeWatt), queued 0.32 secs ago
2023.01.29 21:15:39 4 : gen24: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 104, dlen 203 and potential data c80000fffeffffffff0004ffff00014d5050542031000000000000000000000000188a0000294b52722b69906b8000ffffffffffff00024d5050542032000000000000000000000000171a000025898b4a2b69906b8000ffffffffffff000353744368612033000000000000000000000000000000000000002b69906b8000ffffffffffff00045374446973436861203400000000000000004d3b000008ad12fb2b69906b8000ffffffffffff007c00181400006400640003ffff05dc05dcffffffff00060b710f42
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 5120.0 to BatConfigMaxReferenceWatt
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value bothMax to BatConfigMaxEnabled
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 15.0 to BatConfigReserve
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 15.0 to BatteryChargePercent
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value holding to BatteryState
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 1499.6 to BatConfigMaxDischargeWatt
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 1999.9 to BatConfigMaxChargeWatt
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0 to DCPowerScale
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0.0 to DCPowerMPPT1
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0.0 to DCPowerMPPT2
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0.0 to BatteryChargeWatt
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0.0 to BatteryDischargeWatt
2023.01.29 21:15:39 4 : gen24: HandleResponse done, current frame / read buffer: 0068000000cb0103c80000fffeffffffff0004ffff00014d5050542031000000000000000000000000188a0000294b52722b69906b8000ffffffffffff00024d5050542032000000000000000000000000171a000025898b4a2b69906b8000ffffffffffff000353744368612033000000000000000000000000000000000000002b69906b8000ffffffffffff00045374446973436861203400000000000000004d3b000008ad12fb2b69906b8000ffffffffffff007c00181400006400640003ffff05dc05dcffffffff00060b710f42, id 1, fCode 3, tid 104,


Im Anhang erstmal die vollständige Definition und komplette Log-Auszüge im Gutfall und Fehlerfall. Ich bin für alle Hinweise und Ideen dankbar und kann auch gerne selbst Code-Änderungen ausprobieren, wenn jemand eine Idee hat, was es sein könnte!
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Januar 2023, 22:52:24
Hallo yoda_gh,

das sieht nach einem Bug aus.
Wenn Du auch für den funktionierenden Fall einen Auszug aus dem Log bei verbose 5 posten könntest, finde ich die Stelle sicher schneller (so ist es einmal mit verbose 4 und dann mit verbose 5).

Gruß
     Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 30 Januar 2023, 08:46:20
Hallo Stefan!

Zitat von: StefanStrobel am 29 Januar 2023, 22:52:24
das sieht nach einem Bug aus.
Wenn Du auch für den funktionierenden Fall einen Auszug aus dem Log bei verbose 5 posten könntest, finde ich die Stelle sicher schneller (so ist es einmal mit verbose 4 und dann mit verbose 5).

Oh, sorry. Ich habe zu spät gesehen, dass das nur verbose 4 war und dachte, es wäre nicht so wichtig im Gutfall. Hier ist es natürlich.

Wenn ich sonst irgendwie helfen kann, das einzugrenzen oder Du einen Verdacht hast, was ich testen könnte, sag Bescheid! Oder wenn es hilft und Du mir sagst, wo ich sie finde, probiere ich auch gerne Zwischenversionen, im SVN gibt es nur 4.4.11 und 4.4.13. :)

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 Januar 2023, 18:28:11
Hallo yoda_gh,

bitte probier doch mal das angehängte Modul. Ich hoffe dass es das Problem schon behebt, mir fehlt aber gerade die Zeit das vollständig nachzustellen.

Gruss / Thanx
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 30 Januar 2023, 22:00:43
Super, danke! Schaut schon mal besser aus - ob wirklich sinnvolle Werte kommen, kann ich morgen sagen, wenn die Sonne wieder scheint. :)
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 01 Februar 2023, 07:41:12
Hallo Stefan!

Zitat von: StefanStrobel am 30 Januar 2023, 18:28:11
bitte probier doch mal das angehängte Modul. Ich hoffe dass es das Problem schon behebt, mir fehlt aber gerade die Zeit das vollständig nachzustellen.

Sorry für die späte Antwort. Aber ich kann jetzt bestätigen, dass alles wieder rund läuft, danke!! Wenn ich noch irgendwie helfen kann, da was nachzustellen oder eine Code-Änderung zu verifzieren, sag gerne Bescheid! Ich verstehe leider noch nicht wirklich, wo Dein Patch das fixt, sonst hätte ich schon mehr Details geliefert. :)

VG,
Gernot
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 11 Februar 2023, 21:17:40
nach einen totalausfall von meinem Raspberry findet man dann wieder Fehler die scheinbar schon länger im System sind :-)

ich kann es Zeitlich schon etwas eingrenzen, vermutlich als ich modbusproxy eingerichtet habe bzw. meine PV Anlage mit angebunden habe. Kann aber auch sein das es ein anderes Modbus Modul ist.

Diese Meldungen treten immer nur einmalig auf wenn fhem startet:

2023.02.09 22:22:42 1: PERL WARNING: Subroutine Initialize redefined at ./FHEM/98_Modbus.pm line 492, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine InitializeLD redefined at ./FHEM/98_Modbus.pm line 514, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine DefineFn redefined at ./FHEM/98_Modbus.pm line 542, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine DefineLDFn redefined at ./FHEM/98_Modbus.pm line 574, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine UndefFn redefined at ./FHEM/98_Modbus.pm line 695, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine UndefLDFn redefined at ./FHEM/98_Modbus.pm line 721, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine AttrFn redefined at ./FHEM/98_Modbus.pm line 746, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine AttrLDFn redefined at ./FHEM/98_Modbus.pm line 771, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine UpdateGetSetList redefined at ./FHEM/98_Modbus.pm line 905, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine GetLDFn redefined at ./FHEM/98_Modbus.pm line 958, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine FormatSetVal redefined at ./FHEM/98_Modbus.pm line 994, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine SetLDFn redefined at ./FHEM/98_Modbus.pm line 1045, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine ControlSet redefined at ./FHEM/98_Modbus.pm line 1111, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine createAttrsFromParseInfo redefined at ./FHEM/98_Modbus.pm line 1264, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine SaveAsModule redefined at ./FHEM/98_Modbus.pm line 1311, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine ScanObjects redefined at ./FHEM/98_Modbus.pm line 1383, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine ScanIds redefined at ./FHEM/98_Modbus.pm line 1429, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine NotifyFn redefined at ./FHEM/98_Modbus.pm line 1496, <$fh> line 4747.


hab ich natürlich gekürzt, es ist vermutlich jede sub die hier erwähnt wird :-)

Jemand eine Idee wie ich dem ganzen auf die pelle rücken kann ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 Februar 2023, 22:12:08
Hallo laserrichi,

Du könntest mal schauen, welche Module, die Modbus verwenden, bei Dir eingebunden sind und wie die jeweils das Modbus-Modul in ihrer Initialize-Funktion laden.

In ModbusAttr sieht das z.B. so aus:


sub Initialize {
    my ($modHash) = @_;

    LoadModule "Modbus";
    Modbus::InitializeLD($modHash);                         # Generic function of the Modbus module does the rest


Gruß
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 11 Februar 2023, 23:38:56
hm, im prinzip sehen alle meine so aus:

sub ModbusEPEVER_Initialize($)
{
    my ($modHash) = @_;
    require "$attr{global}{modpath}/FHEM/98_Modbus.pm";
    $modHash->{parseInfo}  = \%ModbusEPEVERparseInfo;  # defines registers, inputs, coils etc. for this Modbus Defive
    $modHash->{deviceInfo} = \%ModbusEPEVERdeviceInfo; # defines properties of the device like defaults and supported function codes

    ModbusLD_Initialize($modHash);              # Generic function of the Modbus module does the rest
   
    $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
}


entsprechend die Namen immer anders.
Liegt das evtl an dem require ? würde da ein LoadModul reichen ?
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Februar 2023, 11:06:32
Hallo laserrichi,

beim require werden die Module mehrfach geladen. Daher die Warnungen.

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 12 Februar 2023, 16:29:54
Zitat von: StefanStrobel am 09 Januar 2023, 19:56:08
Hallo Roger,
klingt durchaus sinnvoll. Ich bin nur leider noch nicht dazu gekommen an dem Thema weiter zu machen.
Auch die Events im Fall von Timeouts werde ich einbauen.
Könnte aber noch ein paar Tage oder sogar Wochen dauern.
Gruss    Stefan

Hi Stefan,
ich wollte mich mal in Erinnerung bringen. Schaffen es die Änderungen ins offizielle Modul?

//Roger

Zitat von: Roger am 18 Dezember 2022, 11:28:42
Hi Stefan,
in diese Richtung gingen auch meine Überlegungen.  :)
So ein sendRaw ist in Modbus als IO besser aufgehoben. Dann aber als wirkliches RAW (ohne Modbus-ID, aber schon mit CRC?).
Dort könnten dann ev. nicht zuordenbare Empfänge (z.B. C1, C2) in Readings abgelegt werden.
Das sendFC wie bisher in ModbusAttr mit den Empfangs-Readings ResponseFC-xx.
Was hältst Du davon? Soll ja für viele User nutzbar sein und Mehrwert bringen (z.B. zum testen/probieren).
//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 Februar 2023, 16:54:26
Hallo Roger,

ich bin gerade am Testen eines neuen Features für custom function codes, die mit wenigen Attributen definiert werden können. Scheint zu funktionieren. Neues Modul zum Testen poste ich demnächst :-)

Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 12 Februar 2023, 18:28:56
Hi Stefan,
Klasse. Freue mich schon.  :)
//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: laserrichi am 12 Februar 2023, 23:00:01
Zitat von: StefanStrobel am 12 Februar 2023, 11:06:32
Hallo laserrichi,

beim require werden die Module mehrfach geladen. Daher die Warnungen.

Gruß
    Stefan

Hallo Stefan, danke... das war es !!  Da wäre ich nie drauf gekommen.
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 14 Februar 2023, 21:16:37
Hallo Roger,

hier ein erster Entwurf zum Testen.

Als Beispiel habe ich einen fiktiven function code 93 (dezimal) definiert, der das gleiche macht wie function code 3:

attr Master dev-fc93Request-unpack nn
attr Master dev-fc93Request-fieldList ADR, LEN

attr Master dev-fc93Response-unpack Ca*
attr Master dev-fc93Response-fieldList LEN, VALUES
attr Master dev-fc93Response-fieldExpr-PDULEXP $response->{LEN} + 2
attr Master dev-fc93Response-fieldExpr-TYPE 'h'
attr Master dev-fc93Response-fieldExpr-ADR $val + 0


das bedeutet:
Der Request besteht aus zwei 16-Bit-Wörtern (unpack nn)
Die werden mit der Adresse und der Länge aus dem Request-Hash gefüllt

Die Antwort besteht aus einem Byte und folgenden Werten, die 1:1 durchgereicht werden (unpack Ca*)
Das Ergebnis des unpacks geht in die Response-Felder LEN und VALUES
Die erwartete Länge der Response in Bytes berechnet sich aus der übermittelten Länge *2
Die Response wird als Felder vom Typ h (holding register) interpretiert und mit den definierten Objekten vom Typ h und Adresse des Requests + 0 geparsed. So könnte man auch auf virtuelle Objekte verweisen, die als obj-h10000 o.ä. definiert sind.

Um das selbst definieren zu können, sollte man den Aufbau des request- bzw. response-Hashes kennen. Darin gibt es die Felder TYPE, ADR, LEN, VALUES, FCODE etc.

Für Deinen einfachen function code x42 bzw. 66, bei dem es gar keine Felder gibt, würde das so aussehen:

attr Master dev-fc66Request-unpack none
attr Master dev-fc66Response-unpack none
attr Master dev-fc66Response-fieldExpr-PDULEXP 1


none steht für keine Felder.
Man kann das ganze auch für Slaves verwenden. Zum Testen kann das hilfreich sein.
Das ganze ist noch nicht final getestet und noch nicht weiter dokumentiert. Ich werde es vermutlich auch noch ein wenig umbauen, so dass man damit auch bestehende function codes umdefinieren kann. Damit könnte man in Zukunft fest reinkodierte "broken-fcxy" vermeiden und einfach den function code passend verbiegen.

Um den function code dann zu verwenden kann man ein virtuelles Objekt festlegen, z.B. obj-h9000-Reading reset und dafür dann overrideFCwrite setzen.
Bei einem set auf dieses Objekt wird dann der neue function code verwendet. Ob der sich für die Adresse und den Typ des Objekts überhaupt interessiert, ist Definitionssache.

Gruss
   Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 15 Februar 2023, 08:39:25
Hi Stefan,
besten Dank vorab. Ich komme aber erst morgen/übermorgen zum Testen.

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 16 Februar 2023, 21:28:26
Hi Stefan,
so habe getestet. Hier die Ergebnisse:

Definition:

# Definition send FC 0x42=66(decimal) zum Zuruecksetzen der Energie
attr HA_PZEM_B1 dev-fc66Request-unpack none
# Definition Empfang FC 0x42=66(decimal): Energie erfolgreich zurueckgesetzt
attr HA_PZEM_B1 dev-fc66Response-unpack none
attr HA_PZEM_B1 dev-fc66Response-fieldExpr-PDULEXP 1
# virtuelles Holding Register zum erfolgreichen Zuruecksetzen der Energie
attr HA_PZEM_B1 obj-h9042-reading Reset
attr HA_PZEM_B1 obj-h9042-set 1
attr HA_PZEM_B1 obj-h9042-overrideFCwrite 66


Dann Befehl: set   HA_PZEM_B1 Reset 1  abgesetzt.
Hierbei musste ich noch einen Wert nach dem Befehl angeben - unschön, aber nicht so schlimm.

Log File:

2023.02.16 21:02:20.781 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.16 21:02:20.781 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.16 21:02:27.348 4: HA_PZEM_B1: set called with Reset (h9042) setVal = 1
2023.02.16 21:02:27.350 5: HA_PZEM_B1: GetSetChecks with force
2023.02.16 21:02:27.350 5: HA_PZEM_B1: GetSetChecks returns success
2023.02.16 21:02:27.353 5: HA_PZEM_B1: set packed hex 31 with n to hex 0001
2023.02.16 21:02:27.356 4: HA_PZEM_B1: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset)
2023.02.16 21:02:27.357 5: HA_Modbus_1: QueueRequest called from DoRequest with h9042, qlen 0 from master HA_PZEM_B1 through io device HA_Modbus_1
2023.02.16 21:02:27.358 5: HA_Modbus_1: ProcessRequestQueue called from QueueRequest as direct:HA_Modbus_1, qlen 1, force, request: request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago
2023.02.16 21:02:27.359 5: HA_Modbus_1: checkDelays busDelayRead, last activity on bus was 206.532 secs ago, required delay is 1
2023.02.16 21:02:27.359 5: HA_Modbus_1: checkDelays sendDelay, last send to same device was 206.617 secs ago, required delay is 0.1
2023.02.16 21:02:27.360 5: HA_Modbus_1: checkDelays clientSwitchDelay is not relevant
2023.02.16 21:02:27.360 5: HA_Modbus_1: checkDelays commDelay, last communication with same device was 206.530 secs ago, required delay is 0.1
2023.02.16 21:02:27.361 3: HA_Modbus_1: Send custom request function code 66: request fields:  values:  results in packed pdu 42
2023.02.16 21:02:27.362 4: HA_Modbus_1: ProcessRequestQueue (V4.5.1 - 14.2.2023) qlen 1, sending 01428011 via /dev/ttyUSB0@9600,8,0,2, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago,
response: no id, no fcode
2023.02.16 21:02:27.369 5: HA_Modbus_1: Send called from ProcessRequestQueue
2023.02.16 21:02:27.370 5: HA_Modbus_1: Profiling Send, before Idle, now is 21:02:27.369, Send started at 21:02:27.369, Idle started at 21:00:57.165
2023.02.16 21:02:27.371 5: HA_Modbus_1: Profiling add 90.204 to sum for Idle (now is 21:02:27.369, start for Idle was 21:00:57.165)
2023.02.16 21:02:27.371 5: DevIo_SimpleWrite HA_Modbus_1: 01428011
2023.02.16 21:02:27.373 5: HA_Modbus_1: Profiling Wait, before Send, now is 21:02:27.373, Wait started at 21:02:27.373, Send started at 21:02:27.369
2023.02.16 21:02:27.374 5: HA_Modbus_1: Profiling add 0.004 to sum for Send (now is 21:02:27.373, start for Send was 21:02:27.369)
2023.02.16 21:02:27.375 5: HA_Modbus_1: ReadAnswer called from SetLDFn
2023.02.16 21:02:27.376 5: HA_Modbus_1: Profiling Read, before Wait, now is 21:02:27.376, Read started at 21:00:57.150, Wait started at 21:02:27.373
2023.02.16 21:02:27.377 5: HA_Modbus_1: Profiling add 0.003 to sum for Wait (now is 21:02:27.376, start for Wait was 21:02:27.373)
2023.02.16 21:02:27.377 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.9799370765686
2023.02.16 21:02:27.459 5: HA_Modbus_1: ReadAnswer got: 01
2023.02.16 21:02:27.460 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.16 21:02:27.461 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.16 21:02:27.461 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.89621615409851
2023.02.16 21:02:27.462 5: HA_Modbus_1: ReadAnswer got: 0142
2023.02.16 21:02:27.462 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.16 21:02:27.462 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.16 21:02:27.463 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.89439296722412
2023.02.16 21:02:27.463 5: HA_Modbus_1: ReadAnswer got: 01428011
2023.02.16 21:02:27.464 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.16 21:02:27.464 4: HA_Modbus_1: ParseFrameStart (RTU, master) extracted id 1, fCode 66 and potential data
2023.02.16 21:02:27.465 5: HA_Modbus_1: HandleResponse called from ReadAnswer
2023.02.16 21:02:27.465 5: HA_Modbus_1: ParseResponse called from HandleResponse
2023.02.16 21:02:27.466 3: HA_Modbus_1: parse custom response function code 66: data:  with unpack code none to fields  results in values:
2023.02.16 21:02:27.467 4: HA_Modbus_1: HandleResponse error, current frame / read buffer: 01428011, id 1, fCode 66,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.11 secs ago, sent 0.11 secs ago,
response: id 1, fc 66, len 1, error: Invalid checksum 4280 received. Calculated 7e80
2023.02.16 21:02:27.468 5: HA_Modbus_1: ResetExpect for HandleResponse from response to idle
2023.02.16 21:02:27.469 5: HA_Modbus_1: Profiling Idle, before Read, now is 21:02:27.469, Idle started at 21:00:57.165, Read started at 21:02:27.376
2023.02.16 21:02:27.470 5: HA_Modbus_1: Profiling add 0.093 to sum for Read (now is 21:02:27.469, start for Read was 21:02:27.376)
2023.02.16 21:02:27.471 5: HA_Modbus_1: DropFrame called from ReadAnswer - drop 01428011


Der Befehl wird wahrscheinlich ausgeführt, das eine Antwort mit dem positiven FC 66 kommt (sonst FC 194), aber bei der Auswertung kommt:
Invalid checksum 4280 received. Calculated 7e80 und die Antwort wird verworfen.
Auch die Angabe einer Länge in h9042 von 0 oder 1 hat keine Besserung gebracht.

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Februar 2023, 10:20:46
Hallo Roger,

aus irgendeinem Grund ignoriert er bei Dir die PDULEXP.
Probier es doch bitte nochmal mit der angehängten Version - da habe ich ein paar Logs aktiviert.
Zudem noch die aktuelle utils-Datei - evt. hast Du da eine andere. die gehört in lib/FHEM/HTTPMOD.

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: eldrik am 17 Februar 2023, 13:44:08
Zitat von: hasenhirn am 23 Oktober 2021, 12:11:18
Hallo und guten Morgen :-)

als erstes einmal danke an Stefan für das tolle Modbus-Modul und den super Support!!!

Nun zu meinem "Problem":
Nach einem Firmwareupdate kann meine Keba-Wallbox Modbus  ;D

Ich habe mich jetzt mal an die Umsetzung gemacht und dank dem Wiki, den Beiträgen und dem Forum bin ich ( wie ich finde ) schon ganz gut voran gekommen. An einer Stelle hakt es aber und da bräuchte ich einen guten Tipp.
Bei der Adresse 5014 - Enable/Disable charging station steht 0: Disable charging station und 1: Enable charging station.
Leider ist das der Punkt an dem ich nicht weiter komme. Die Wallbox läuft immer durch und ich bekomme den Ladevorgang nicht unterbrochen  >:(
Alle anderen Funktionen sind ok und bringen die Werte die ich erwarte.
Als Konfiguration habe ich schon obj-h05014-reading und obj-c05014-reading versucht wobei bei obj-c05014-reading die Fehlermeldung "Timeout in Readanswer" kommt.
Hier mal eine paar Informationen über meine Konfiguration und die Logeinträge.

defmod Keba_Stellplatz ModbusAttr 1 10 192.168.1.22:502 TCP
attr Keba_Stellplatz dev-h-defPoll 1
attr Keba_Stellplatz event-min-interval .*:60
attr Keba_Stellplatz event-on-change-reading .*
attr Keba_Stellplatz obj-h01000-len 2
attr Keba_Stellplatz obj-h01000-map 0:booting, 1:not ready for charging, 2:ready for chargin, 3:charging, 4:error, 5:charging process interrupted
attr Keba_Stellplatz obj-h01000-reading Chargingstate
attr Keba_Stellplatz obj-h01000-unpack N
attr Keba_Stellplatz obj-h01004-len 2
attr Keba_Stellplatz obj-h01004-map 0:no cable is plugged, 1:Cable is connected to charging station, 3:Cabel is connected to the charging station and locked, 5:Cable is connected to the charging station and the EV, 7:Cable is connected to the charging station and the EV an locked
attr Keba_Stellplatz obj-h01004-reading Cablestate
attr Keba_Stellplatz obj-h01004-unpack N
attr Keba_Stellplatz obj-h01006-len 2
attr Keba_Stellplatz obj-h01006-map 0:No error
attr Keba_Stellplatz obj-h01006-reading Error_code
attr Keba_Stellplatz obj-h01006-unpack N
attr Keba_Stellplatz obj-h01008-expr $val / 1000
attr Keba_Stellplatz obj-h01008-format %.3f A
attr Keba_Stellplatz obj-h01008-len 2
attr Keba_Stellplatz obj-h01008-reading Charging_current_phase_1
attr Keba_Stellplatz obj-h01008-unpack N
attr Keba_Stellplatz obj-h01010-expr $val / 1000
attr Keba_Stellplatz obj-h01010-format %.3f A
attr Keba_Stellplatz obj-h01010-len 2
attr Keba_Stellplatz obj-h01010-reading Charging_current_phase_2
attr Keba_Stellplatz obj-h01010-unpack N
attr Keba_Stellplatz obj-h01012-expr $val / 1000
attr Keba_Stellplatz obj-h01012-format %.3f A
attr Keba_Stellplatz obj-h01012-len 2
attr Keba_Stellplatz obj-h01012-reading Charging_current_phase_3
attr Keba_Stellplatz obj-h01012-unpack N
attr Keba_Stellplatz obj-h01014-len 2
attr Keba_Stellplatz obj-h01014-reading Serialnumber
attr Keba_Stellplatz obj-h01014-unpack N
attr Keba_Stellplatz obj-h01016-len 2
attr Keba_Stellplatz obj-h01016-reading Producttype
attr Keba_Stellplatz obj-h01016-unpack N
attr Keba_Stellplatz obj-h01018-len 2
attr Keba_Stellplatz obj-h01018-reading Firmwareversion
attr Keba_Stellplatz obj-h01018-unpack N
attr Keba_Stellplatz obj-h01020-expr $val / 1000
attr Keba_Stellplatz obj-h01020-format %.3f W
attr Keba_Stellplatz obj-h01020-len 2
attr Keba_Stellplatz obj-h01020-reading Active_power
attr Keba_Stellplatz obj-h01020-unpack N
attr Keba_Stellplatz obj-h01036-expr $val / 1000
attr Keba_Stellplatz obj-h01036-format %.3f kWh
attr Keba_Stellplatz obj-h01036-len 2
attr Keba_Stellplatz obj-h01036-reading Total_energy
attr Keba_Stellplatz obj-h01036-unpack N
attr Keba_Stellplatz obj-h01040-format %.1f V
attr Keba_Stellplatz obj-h01040-len 2
attr Keba_Stellplatz obj-h01040-reading Voltage_phase_1
attr Keba_Stellplatz obj-h01040-unpack N
attr Keba_Stellplatz obj-h01042-format %.1f V
attr Keba_Stellplatz obj-h01042-len 2
attr Keba_Stellplatz obj-h01042-reading Voltage_phase_2
attr Keba_Stellplatz obj-h01042-unpack N
attr Keba_Stellplatz obj-h01044-format %.1f V
attr Keba_Stellplatz obj-h01044-len 2
attr Keba_Stellplatz obj-h01044-reading Voltage_phase_3
attr Keba_Stellplatz obj-h01044-unpack N
attr Keba_Stellplatz obj-h01046-expr $val / 10
attr Keba_Stellplatz obj-h01046-format %.1f %
attr Keba_Stellplatz obj-h01046-len 2
attr Keba_Stellplatz obj-h01046-reading Powerfactor
attr Keba_Stellplatz obj-h01046-unpack N
attr Keba_Stellplatz obj-h01100-expr $val / 1000
attr Keba_Stellplatz obj-h01100-format %d A
attr Keba_Stellplatz obj-h01100-len 2
attr Keba_Stellplatz obj-h01100-reading Max_charging_current
attr Keba_Stellplatz obj-h01100-unpack N
attr Keba_Stellplatz obj-h01110-expr $val / 1000
attr Keba_Stellplatz obj-h01110-format %d A
attr Keba_Stellplatz obj-h01110-len 2
attr Keba_Stellplatz obj-h01110-reading Max_supported_current
attr Keba_Stellplatz obj-h01110-unpack N
attr Keba_Stellplatz obj-h05004-expr $val / 1000
attr Keba_Stellplatz obj-h05004-format %.3f A
attr Keba_Stellplatz obj-h05004-max 63
attr Keba_Stellplatz obj-h05004-min 6
attr Keba_Stellplatz obj-h05004-reading Set_charging_current
attr Keba_Stellplatz obj-h05004-set 1
attr Keba_Stellplatz obj-h05004-setexpr $val * 1000
attr Keba_Stellplatz obj-h05010-reading Set_energy
attr Keba_Stellplatz obj-h05010-set 1
attr Keba_Stellplatz obj-h05010-unpack N
attr Keba_Stellplatz obj-h05012-reading Unlock_plug
attr Keba_Stellplatz obj-h05012-set 1
attr Keba_Stellplatz obj-h05014-reading Enable/Disable_charging_station
attr Keba_Stellplatz obj-h05014-set 1
attr Keba_Stellplatz verbose 5

setstate Keba_Stellplatz opened
setstate Keba_Stellplatz 2021-10-23 11:58:57 Active_power 4205.857 W
setstate Keba_Stellplatz 2021-10-23 11:58:56 Cablestate Cable is connected to the charging station and the EV an locked
setstate Keba_Stellplatz 2021-10-23 11:58:56 Charging_current_phase_1 6.107 A
setstate Keba_Stellplatz 2021-10-23 11:58:56 Charging_current_phase_2 6.112 A
setstate Keba_Stellplatz 2021-10-23 11:58:56 Charging_current_phase_3 6.115 A
setstate Keba_Stellplatz 2021-10-23 11:58:56 Chargingstate charging
setstate Keba_Stellplatz 2021-10-23 11:58:44 Enable/Disable_charging_station 0
setstate Keba_Stellplatz 2021-10-23 11:58:56 Error_code No error
setstate Keba_Stellplatz 2021-10-23 11:58:57 Firmwareversion 50993920
setstate Keba_Stellplatz 2021-10-23 11:58:58 Max_charging_current 6 A
setstate Keba_Stellplatz 2021-10-23 11:58:58 Max_supported_current 16 A
setstate Keba_Stellplatz 2021-10-23 11:58:58 Powerfactor 99.5 %
setstate Keba_Stellplatz 2021-10-23 11:58:57 Producttype 314121
setstate Keba_Stellplatz 2021-10-23 11:58:57 Serialnumber 22218033
setstate Keba_Stellplatz 2021-10-23 11:54:48 Set_charging_current 6.000 A
setstate Keba_Stellplatz 2021-10-23 11:58:57 Total_energy 1127.018 kWh
setstate Keba_Stellplatz 2021-10-23 11:58:57 Voltage_phase_1 229.0 V
setstate Keba_Stellplatz 2021-10-23 11:58:57 Voltage_phase_2 230.0 V
setstate Keba_Stellplatz 2021-10-23 11:58:57 Voltage_phase_3 230.0 V
setstate Keba_Stellplatz 2021-10-23 11:56:14 state opened


Hier gibt es die Programmieranleitung zur Keba-Wallbox:
https://www.keba.com/download/x/dea7ae6b84/kecontactp30modbustcp_pgen.pdf (https://www.keba.com/download/x/dea7ae6b84/kecontactp30modbustcp_pgen.pdf)

Ich hoffe mit den Informationen kann mir jemand weiter helfen  :)

LG

Thomas

da ich mich, für meine Modbus TCP Integration meiner Keba P30 Deutschland Edition, bei diesem Codebeispiel bedient hatte, hier eine Ergänzung, dass Anfang dieses Jahres eine neue Firmware herausgekommen ist, mit der sich über das X2 Interface der Box ein Phasenumschalter (von Keba, S10, kann man aber auch genauso gut nachbauen) bedienen lässt was in Kombination mit solaren Überschuss, für den ein oder anderen Interessant sein könnte.

Folgende Attribute braucht es zusätzlich:

attr Keba_Stellplatz obj-h01550-len 2
attr Keba_Stellplatz obj-h01550-map 0:disabled, 1:OCPP, 2:REST, 3:Modbus TCP, 4:UDP
attr Keba_Stellplatz obj-h01550-reading Phase_switching_source
attr Keba_Stellplatz obj-h01550-unpack N
attr Keba_Stellplatz obj-h01552-len 2
attr Keba_Stellplatz obj-h01552-map 0:1Phasig, 1:3Phasig
attr Keba_Stellplatz obj-h01552-reading Phase_switching_state
attr Keba_Stellplatz obj-h01552-unpack N
attr Keba_Stellplatz obj-h05050-reading Set_phase_switch_toggle
attr Keba_Stellplatz obj-h05050-set 1
attr Keba_Stellplatz obj-h05052-reading Trigger_phase_switch
attr Keba_Stellplatz obj-h05052-set 1


Greetz
Eldrik
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 17 Februar 2023, 16:38:58
Zitat von: StefanStrobel am 17 Februar 2023, 10:20:46
Hallo Roger,
aus irgendeinem Grund ignoriert er bei Dir die PDULEXP.
Probier es doch bitte nochmal mit der angehängten Version - da habe ich ein paar Logs aktiviert.
Zudem noch die aktuelle utils-Datei - evt. hast Du da eine andere. die gehört in lib/FHEM/HTTPMOD.
Gruss Stefan

Hi Stefan,
utils-Datei nach lib/FHEM/HTTPMOD kopiert.
Ist aber nicht besser geworden.  :(

Hier das Log:

2023.02.17 16:27:47.325 3: HA_PZEM_B1: attr dev-fc66Request-unpack none set
2023.02.17 16:27:47.353 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc66Request-unpack none
2023.02.17 16:27:47.364 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A
2023.02.17 16:27:47.364 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.385 3: HA_PZEM_B1: attr dev-fc66Response-unpack none set
2023.02.17 16:27:47.411 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc66Response-unpack none
2023.02.17 16:27:47.420 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A
2023.02.17 16:27:47.421 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.442 3: HA_PZEM_B1: attr dev-fc66Response-fieldExpr-PDULEXP 1 set
2023.02.17 16:27:47.468 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc66Response-fieldExpr-PDULEXP 1
2023.02.17 16:27:47.477 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A
2023.02.17 16:27:47.478 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.485 3: HA_PZEM_B1: attr obj-h9042-reading Reset set
2023.02.17 16:27:47.511 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9042-reading Reset
2023.02.17 16:27:47.520 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A
2023.02.17 16:27:47.521 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.532 3: HA_PZEM_B1: attr obj-h9042-set 1 set
2023.02.17 16:27:47.557 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9042-set 1
2023.02.17 16:27:47.567 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.17 16:27:47.568 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.582 3: HA_PZEM_B1: attr obj-h9042-overrideFCwrite 66 set
2023.02.17 16:27:47.608 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9042-overrideFCwrite 66
2023.02.17 16:27:47.617 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.17 16:27:47.618 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.635 3: HA_PZEM_B1: attr dev-fc194Response-unpack none set
2023.02.17 16:27:47.661 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc194Response-unpack none
2023.02.17 16:27:47.670 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.17 16:27:47.671 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.691 3: HA_PZEM_B1: attr dev-fc194Response-fieldExpr-PDULEXP 1 set
2023.02.17 16:27:47.718 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc194Response-fieldExpr-PDULEXP 1
2023.02.17 16:27:47.727 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.17 16:27:47.728 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.736 3: HA_PZEM_B1: attr obj-h9194-reading Reset_Fehler set
2023.02.17 16:27:47.761 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9194-reading Reset_Fehler
2023.02.17 16:27:47.771 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.17 16:27:47.772 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:47.786 3: HA_PZEM_B1: attr obj-h9194-overrideFCread 194 set
2023.02.17 16:27:47.812 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9194-overrideFCread 194
2023.02.17 16:27:47.822 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.17 16:27:47.823 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.17 16:27:57.774 4: HA_PZEM_B1: set called with Reset (h9042) setVal = 1
2023.02.17 16:27:57.775 5: HA_PZEM_B1: GetSetChecks with force
2023.02.17 16:27:57.775 5: HA_PZEM_B1: GetSetChecks returns success
2023.02.17 16:27:57.778 5: HA_PZEM_B1: set packed hex 31 with n to hex 0001
2023.02.17 16:27:57.780 4: HA_PZEM_B1: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset)
2023.02.17 16:27:57.781 5: HA_Modbus_1: QueueRequest called from DoRequest with h9042, qlen 0 from master HA_PZEM_B1 through io device HA_Modbus_1
2023.02.17 16:27:57.782 5: HA_Modbus_1: ProcessRequestQueue called from QueueRequest as direct:HA_Modbus_1, qlen 1, force, request: request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago
2023.02.17 16:27:57.783 5: HA_Modbus_1: checkDelays clientSwitchDelay is not relevant
2023.02.17 16:27:57.783 5: HA_Modbus_1: checkDelays busDelayRead, last activity on bus was 71.045 secs ago, required delay is 1
2023.02.17 16:27:57.784 5: HA_Modbus_1: checkDelays sendDelay, last send to same device was 71.118 secs ago, required delay is 0.1
2023.02.17 16:27:57.784 5: HA_Modbus_1: checkDelays commDelay, last communication with same device was 71.043 secs ago, required delay is 0.1
2023.02.17 16:27:57.785 3: HA_Modbus_1: Send custom request function code 66: request fields:  values:  results in packed pdu 42
2023.02.17 16:27:57.786 4: HA_Modbus_1: ProcessRequestQueue (V4.5.1 - 14.2.2023) qlen 1, sending 01428011 via /dev/ttyUSB0@9600,8,0,2, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago,
response: no id, no fcode
2023.02.17 16:27:57.787 5: HA_Modbus_1: Send called from ProcessRequestQueue
2023.02.17 16:27:57.787 5: HA_Modbus_1: Profiling Send, before Idle, now is 16:27:57.787, Send started at 16:26:46.662, Idle started at 16:26:46.759
2023.02.17 16:27:57.788 5: HA_Modbus_1: Profiling add 71.028 to sum for Idle (now is 16:27:57.787, start for Idle was 16:26:46.759)
2023.02.17 16:27:57.788 5: DevIo_SimpleWrite HA_Modbus_1: 01428011
2023.02.17 16:27:57.791 5: HA_Modbus_1: Profiling Wait, before Send, now is 16:27:57.790, Wait started at 16:26:46.665, Send started at 16:27:57.787
2023.02.17 16:27:57.791 5: HA_Modbus_1: Profiling add 0.003 to sum for Send (now is 16:27:57.790, start for Send was 16:27:57.787)
2023.02.17 16:27:57.793 5: HA_Modbus_1: ReadAnswer called from SetLDFn
2023.02.17 16:27:57.794 5: HA_Modbus_1: Profiling Read, before Wait, now is 16:27:57.793, Read started at 16:26:46.668, Wait started at 16:27:57.790
2023.02.17 16:27:57.794 5: HA_Modbus_1: Profiling add 0.003 to sum for Wait (now is 16:27:57.793, start for Wait was 16:27:57.790)
2023.02.17 16:27:57.795 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.98667407035828
2023.02.17 16:27:57.873 5: HA_Modbus_1: ReadAnswer got: 01
2023.02.17 16:27:57.874 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.17 16:27:57.875 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.17 16:27:57.875 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.9062659740448
2023.02.17 16:27:57.876 5: HA_Modbus_1: ReadAnswer got: 014280
2023.02.17 16:27:57.876 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.17 16:27:57.877 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.17 16:27:57.877 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.90452098846436
2023.02.17 16:27:57.877 5: HA_Modbus_1: ReadAnswer got: 01428011
2023.02.17 16:27:57.878 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.17 16:27:57.879 4: HA_Modbus_1: ParseFrameStart (RTU, master) extracted id 1, fCode 66 and potential data
2023.02.17 16:27:57.879 5: HA_Modbus_1: HandleResponse called from ReadAnswer
2023.02.17 16:27:57.879 5: HA_Modbus_1: ParseResponse called from HandleResponse
2023.02.17 16:27:57.880 3: HA_Modbus_1: parse custom response function code 66: data:  with unpack code none to fields  results in values:
2023.02.17 16:27:57.881 1: PERL WARNING: Use of uninitialized value in addition (+) at /opt/fhem/FHEM/98_Modbus.pm line 4441.
2023.02.17 16:27:57.882 1: PERL WARNING: Use of uninitialized value in addition (+) at /opt/fhem/FHEM/98_Modbus.pm line 2579.
2023.02.17 16:27:57.882 4: HA_Modbus_1: HandleResponse error, current frame / read buffer: 01428011, id 1, fCode 66,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.10 secs ago, sent 0.10 secs ago,
response: id 1, fc 66, len 1, error: Invalid checksum 4280 received. Calculated 7e80
2023.02.17 16:27:57.883 5: HA_Modbus_1: ResetExpect for HandleResponse from response to idle
2023.02.17 16:27:57.884 5: HA_Modbus_1: Profiling Idle, before Read, now is 16:27:57.883, Idle started at 16:26:46.759, Read started at 16:27:57.793
2023.02.17 16:27:57.884 5: HA_Modbus_1: Profiling add 0.090 to sum for Read (now is 16:27:57.883, start for Read was 16:27:57.793)
2023.02.17 16:27:57.885 5: HA_Modbus_1: DropFrame called from ReadAnswer - drop 01428011


Immer noch Invalid checksum. Habe auch mal PDULEXP auf 0 oder 2 gestellt --> gleiches Ergebnis.

Edit: Hatte eine alte utils erwischt. Nun die aktuelle kopiert --> aber gleiches Ergebnis: Invalid checksum
//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 Februar 2023, 21:39:59
Hallo Roger,

ich glaube ich habe den Fehler gefunden.
Bei meinen Tests habe ich eine TCP-Verbindung verwendet und da gibt es nur ein Device.
Anbei eine neue Version.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 19 Februar 2023, 00:38:24
Hi Stefan,
es wir langsam besser. Hier das Log:

2023.02.19 00:24:59.428 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:24:59.429 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.522 3: HA_PZEM_B1: attr dev-fc66Request-unpack none set
2023.02.19 00:25:11.548 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc66Request-unpack none
2023.02.19 00:25:11.558 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:11.559 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.578 3: HA_PZEM_B1: attr dev-fc66Response-unpack none set
2023.02.19 00:25:11.603 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc66Response-unpack none
2023.02.19 00:25:11.614 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:11.615 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.634 3: HA_PZEM_B1: attr dev-fc66Response-fieldExpr-PDULEXP 1 set
2023.02.19 00:25:11.660 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc66Response-fieldExpr-PDULEXP 1
2023.02.19 00:25:11.670 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:11.670 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.677 3: HA_PZEM_B1: attr obj-h9042-reading Reset set
2023.02.19 00:25:11.703 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9042-reading Reset
2023.02.19 00:25:11.713 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:11.713 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.724 3: HA_PZEM_B1: attr obj-h9042-set 1 set
2023.02.19 00:25:11.750 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9042-set 1
2023.02.19 00:25:11.760 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:11.760 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.775 3: HA_PZEM_B1: attr obj-h9042-overrideFCwrite 66 set
2023.02.19 00:25:11.801 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9042-overrideFCwrite 66
2023.02.19 00:25:11.811 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:11.812 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.829 3: HA_PZEM_B1: attr dev-fc194Response-unpack none set
2023.02.19 00:25:11.854 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc194Response-unpack none
2023.02.19 00:25:11.864 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:11.865 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.934 3: HA_PZEM_B1: attr dev-fc194Response-fieldExpr-PDULEXP 1 set
2023.02.19 00:25:11.959 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 dev-fc194Response-fieldExpr-PDULEXP 1
2023.02.19 00:25:11.969 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:11.970 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:11.977 3: HA_PZEM_B1: attr obj-h9194-reading Reset_Fehler set
2023.02.19 00:25:12.003 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9194-reading Reset_Fehler
2023.02.19 00:25:12.013 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:12.014 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:12.036 3: HA_PZEM_B1: attr obj-h9194-overrideFCread 194 set
2023.02.19 00:25:12.061 3: Noti_Global_RPi3, Notify Zweck: Notify fuer global, Name: global, Ereignis: ATTR HA_PZEM_B1 obj-h9194-overrideFCread 194
2023.02.19 00:25:12.071 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.19 00:25:12.072 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.19 00:25:18.227 4: HA_PZEM_B1: set called with Reset (h9042) setVal = 1
2023.02.19 00:25:18.228 5: HA_PZEM_B1: GetSetChecks with force
2023.02.19 00:25:18.229 5: HA_PZEM_B1: GetSetChecks returns success
2023.02.19 00:25:18.231 5: HA_PZEM_B1: set packed hex 31 with n to hex 0001
2023.02.19 00:25:18.234 4: HA_PZEM_B1: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset)
2023.02.19 00:25:18.235 5: HA_Modbus_1: QueueRequest called from DoRequest with h9042, qlen 0 from master HA_PZEM_B1 through io device HA_Modbus_1
2023.02.19 00:25:18.236 5: HA_Modbus_1: ProcessRequestQueue called from QueueRequest as direct:HA_Modbus_1, qlen 1, force, request: request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago
2023.02.19 00:25:18.237 5: HA_Modbus_1: checkDelays clientSwitchDelay is not relevant
2023.02.19 00:25:18.237 5: HA_Modbus_1: checkDelays sendDelay, last send to same device was 54.661 secs ago, required delay is 0.1
2023.02.19 00:25:18.237 5: HA_Modbus_1: checkDelays commDelay, last communication with same device was 54.584 secs ago, required delay is 0.1
2023.02.19 00:25:18.238 5: HA_Modbus_1: checkDelays busDelayRead, last activity on bus was 54.586 secs ago, required delay is 1
2023.02.19 00:25:18.239 3: HA_Modbus_1: Send custom request function code 66: request fields:  values:  results in packed pdu 42
2023.02.19 00:25:18.240 4: HA_Modbus_1: ProcessRequestQueue (V4.5.3 - 18.2.2023) qlen 1, sending 01428011 via /dev/ttyUSB0@9600,8,0,2, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago,
response: no id, no fcode
2023.02.19 00:25:18.240 5: HA_Modbus_1: Send called from ProcessRequestQueue
2023.02.19 00:25:18.241 5: HA_Modbus_1: Profiling Send, before Idle, now is 00:25:18.241, Send started at 00:24:23.572, Idle started at 00:24:23.671
2023.02.19 00:25:18.242 5: HA_Modbus_1: Profiling add 54.570 to sum for Idle (now is 00:25:18.241, start for Idle was 00:24:23.671)
2023.02.19 00:25:18.242 5: DevIo_SimpleWrite HA_Modbus_1: 01428011
2023.02.19 00:25:18.244 5: HA_Modbus_1: Profiling Wait, before Send, now is 00:25:18.244, Wait started at 00:24:23.576, Send started at 00:25:18.241
2023.02.19 00:25:18.245 5: HA_Modbus_1: Profiling add 0.003 to sum for Send (now is 00:25:18.244, start for Send was 00:25:18.241)
2023.02.19 00:25:18.246 5: HA_Modbus_1: ReadAnswer called from SetLDFn
2023.02.19 00:25:18.247 5: HA_Modbus_1: Profiling Read, before Wait, now is 00:25:18.247, Read started at 00:24:23.579, Wait started at 00:25:18.244
2023.02.19 00:25:18.248 5: HA_Modbus_1: Profiling add 0.003 to sum for Wait (now is 00:25:18.247, start for Wait was 00:25:18.244)
2023.02.19 00:25:18.248 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.98718190193176
2023.02.19 00:25:18.328 5: HA_Modbus_1: ReadAnswer got: 01
2023.02.19 00:25:18.329 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.19 00:25:18.329 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.19 00:25:18.330 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.90549302101135
2023.02.19 00:25:18.330 5: HA_Modbus_1: ReadAnswer got: 01428011
2023.02.19 00:25:18.331 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.19 00:25:18.331 4: HA_Modbus_1: ParseFrameStart (RTU, master) extracted id 1, fCode 66 and potential data
2023.02.19 00:25:18.332 5: HA_Modbus_1: HandleResponse called from ReadAnswer
2023.02.19 00:25:18.332 5: HA_Modbus_1: ParseResponse called from HandleResponse
2023.02.19 00:25:18.334 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/98_Modbus.pm line 2523.
2023.02.19 00:25:18.334 5: HA_Modbus_1: exprHash key PDULEXP is
2023.02.19 00:25:18.336 5: HA_PZEM_B1: perl expression eval evaluated package main; my $response = $oRef->{'$response'};1 to 1
2023.02.19 00:25:18.336 5: HA_Modbus_1: extra field PDULEXP after expr (1) is 1
2023.02.19 00:25:18.336 3: HA_Modbus_1: parse custom response function code 66: data:  with unpack code none to fields  results in values:
2023.02.19 00:25:18.337 5: HA_Modbus_1: CheckChecksum (called from ParseResponse): 8011 is valid
2023.02.19 00:25:18.338 5: HA_Modbus_1: Profiling Fhem, before Read, now is 00:25:18.337, Fhem started at 00:24:23.653, Read started at 00:25:18.247
2023.02.19 00:25:18.339 5: HA_Modbus_1: Profiling add 0.091 to sum for Read (now is 00:25:18.337, start for Read was 00:25:18.247)
2023.02.19 00:25:18.339 4: HA_Modbus_1: HandleResponse done, current frame / read buffer: 01428011, id 1, fCode 66,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.10 secs ago, sent 0.10 secs ago,
response: id 1, fc 66, len 1
2023.02.19 00:25:18.340 5: HA_Modbus_1: ResetExpect for HandleResponse from response to idle
2023.02.19 00:25:18.341 5: HA_Modbus_1: Profiling Idle, before Fhem, now is 00:25:18.340, Idle started at 00:24:23.671, Fhem started at 00:25:18.337
2023.02.19 00:25:18.341 5: HA_Modbus_1: Profiling add 0.003 to sum for Fhem (now is 00:25:18.340, start for Fhem was 00:25:18.337)
2023.02.19 00:25:18.342 5: HA_Modbus_1: DropFrame called from ReadAnswer - drop 01428011


Es ist zwar kein Invalid checksum mehr zu sehen, aber der Frame wird trotzdem gedroppt und kein Reading angelegt.
Ich habe mal mit PDULEXP 0 und 2 probiert - hat er übernommen, aber bei 0 Frame gedropped und bei 2 timeout.

Danke für Deine Mühen.
//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 Februar 2023, 08:04:49
Hallo Roger,

das sieht doch gut aus.
PDULEXP 1 ist korrekt, das ist die erwartete Länge der Response ohne Checksumme und die besteht ja nur aus dem function code. Wenn PDULEXP 1 ist, solltest Du es inzwischen sogar weglassen können.
Dass kein Reading erzeugt wird liegt daran, dass die Response vom Gerät keine Daten enthält.
Was für ein Reading hättest Du denn gerne? So was wie fc66LastResponse valid?

Gruß
    Stefan

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 19 Februar 2023, 09:55:51
ZitatWas für ein Reading hättest Du denn gerne? So was wie fc66LastResponse valid?
Hi Stefan,
am liebsten etwas konfigurierbares.  ;D
Es gibt ja noch den FC 0xC2=194, welcher kommen soll, wenn beim Rücksetzen was schief ging. Da sollte dann was anderes drin stehen. Notfalls "no data".
Ich denke mal, dann ist auch die Meldung "Frame gedropped" weg.

So habe ich die Reading definiert:

# Definition send FC 0x42=66(decimal) zum Zuruecksetzen der Energie
attr HA_PZEM_B1 dev-fc66Request-unpack none
# Definition Empfang FC 0x42=66(decimal): Energie erfolgreich zurueckgesetzt
attr HA_PZEM_B1 dev-fc66Response-unpack none
attr HA_PZEM_B1 dev-fc66Response-fieldExpr-PDULEXP 1
# virtuelles Holding Register zum erfolgreichen Zuruecksetzen der Energie
attr HA_PZEM_B1 obj-h9042-reading Reset
attr HA_PZEM_B1 obj-h9042-set 1
attr HA_PZEM_B1 obj-h9042-overrideFCwrite 66
# Definition Empfang FC 0xC2=194(decimal): Fehler beim Zuruecksetzen der Energie
attr HA_PZEM_B1 dev-fc194Response-unpack none
attr HA_PZEM_B1 dev-fc194Response-fieldExpr-PDULEXP 1
# virtuelles Holding Register bei Fehler Zuruecksetzen der Energie
attr HA_PZEM_B1 obj-h9194-reading Reset_Fehler
attr HA_PZEM_B1 obj-h9194-overrideFCread 194


Kannst Du denn noch was sinnvolles gegen den notwendigen Parameter beim SET-Befehl machen?

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 19 Februar 2023, 21:42:21
Hallo Roger,

Zitat von: Roger am 19 Februar 2023, 09:55:51
Es gibt ja noch den FC 0xC2=194, welcher kommen soll, wenn beim Rücksetzen was schief ging. Da sollte dann was anderes drin stehen. Notfalls "no data".
Ich denke mal, dann ist auch die Meldung "Frame gedropped" weg.
Function codes dürfen nicht größer als 127 sein.
Wenn ein Slave einen Fehler melden möchte, dann antwortet er mit dem function code des Request +128. Da gibt es dann keine Zuweisung zu Objekten.

Zitat
Kannst Du denn noch was sinnvolles gegen den notwendigen Parameter beim SET-Befehl machen?

obj-...-noArg, z.B.

attr Master obj-h9042-noArg 1


anbei die neue Version.

wenn Du beim custom function code eine Expression für VALUES definierest, dann meint das Modul, dass in der Response Daten für das angefragte Objekt waren und setzt das Reading. Im Fehlerfall wird wie üblich kein Reading gesetzt.

Z.B.

attr Master dev-fc66Response-fieldExpr-VALUES pack ('n', 1)


Gruß
    Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 19 Februar 2023, 22:56:05
Hi Stefan,
alles geht.  :) set-Befehl ohne Parameter, das Reading wird angelegt - aber es kommt noch "DropFrame".
Aber vielleicht interpretiere ich es auch falsch und es ist gar kein Fehler.

ZitatFunction codes dürfen nicht größer als 127 sein.
Wenn ein Slave einen Fehler melden möchte, dann antwortet er mit dem function code des Request +128. Da gibt es dann keine Zuweisung zu Objekten.
Wie würde man denn einen solchen Fehler sehen? Nur im Log oder wird auch ein Reading/state gesetzt worauf man in einem notify reagieren kann?

Nur eine Warnung zu sehen: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/98_Modbus.pm line 2532
Hier das Log:

2023.02.19 22:44:07.368 4: HA_PZEM_B1: set called with Reset (h9042)
2023.02.19 22:44:07.369 3: HA_PZEM_B1: set with noArg for Reset, using value 1
2023.02.19 22:44:07.369 5: HA_PZEM_B1: GetSetChecks with force
2023.02.19 22:44:07.370 5: HA_PZEM_B1: GetSetChecks returns success
2023.02.19 22:44:07.372 5: HA_PZEM_B1: set packed hex 31 with n to hex 0001
2023.02.19 22:44:07.375 4: HA_PZEM_B1: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset)
2023.02.19 22:44:07.375 5: HA_Modbus_1: QueueRequest called from DoRequest with h9042, qlen 0 from master HA_PZEM_B1 through io device HA_Modbus_1
2023.02.19 22:44:07.376 5: HA_Modbus_1: ProcessRequestQueue called from QueueRequest as direct:HA_Modbus_1, qlen 1, force, request: request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago
2023.02.19 22:44:07.377 5: HA_Modbus_1: checkDelays clientSwitchDelay is not relevant
2023.02.19 22:44:07.378 5: HA_Modbus_1: checkDelays sendDelay, last send to same device was 158.941 secs ago, required delay is 0.1
2023.02.19 22:44:07.378 5: HA_Modbus_1: checkDelays commDelay, last communication with same device was 158.864 secs ago, required delay is 0.1
2023.02.19 22:44:07.379 5: HA_Modbus_1: checkDelays busDelayRead, last activity on bus was 158.865 secs ago, required delay is 1
2023.02.19 22:44:07.380 3: HA_Modbus_1: Send custom request function code 66: request fields:  values:  results in packed pdu 42
2023.02.19 22:44:07.380 4: HA_Modbus_1: ProcessRequestQueue (V4.5.4 - 19.2.2023) qlen 1, sending 01428011 via /dev/ttyUSB0@9600,8,0,2, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago,
response: no id, no fcode
2023.02.19 22:44:07.381 5: HA_Modbus_1: Send called from ProcessRequestQueue
2023.02.19 22:44:07.382 5: HA_Modbus_1: Profiling Send, before Idle, now is 22:44:07.381, Send started at 22:41:28.432, Idle started at 22:41:28.584
2023.02.19 22:44:07.383 5: HA_Modbus_1: Profiling add 158.797 to sum for Idle (now is 22:44:07.381, start for Idle was 22:41:28.584)
2023.02.19 22:44:07.383 5: DevIo_SimpleWrite HA_Modbus_1: 01428011
2023.02.19 22:44:07.385 5: HA_Modbus_1: Profiling Wait, before Send, now is 22:44:07.385, Wait started at 22:41:28.436, Send started at 22:44:07.381
2023.02.19 22:44:07.386 5: HA_Modbus_1: Profiling add 0.003 to sum for Send (now is 22:44:07.385, start for Send was 22:44:07.381)
2023.02.19 22:44:07.387 5: HA_Modbus_1: ReadAnswer called from SetLDFn
2023.02.19 22:44:07.388 5: HA_Modbus_1: Profiling Read, before Wait, now is 22:44:07.388, Read started at 22:41:28.439, Wait started at 22:44:07.385
2023.02.19 22:44:07.389 5: HA_Modbus_1: Profiling add 0.003 to sum for Wait (now is 22:44:07.388, start for Wait was 22:44:07.385)
2023.02.19 22:44:07.389 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.98696684837341
2023.02.19 22:44:07.467 5: HA_Modbus_1: ReadAnswer got: 01
2023.02.19 22:44:07.468 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.19 22:44:07.468 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.19 22:44:07.469 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.90718698501587
2023.02.19 22:44:07.470 5: HA_Modbus_1: ReadAnswer got: 014280
2023.02.19 22:44:07.470 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.19 22:44:07.471 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.19 22:44:07.471 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.90493488311768
2023.02.19 22:44:07.472 5: HA_Modbus_1: ReadAnswer got: 01428011
2023.02.19 22:44:07.472 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.19 22:44:07.472 4: HA_Modbus_1: ParseFrameStart (RTU, master) extracted id 1, fCode 66 and potential data
2023.02.19 22:44:07.473 5: HA_Modbus_1: HandleResponse called from ReadAnswer
2023.02.19 22:44:07.473 5: HA_Modbus_1: ParseResponse called from HandleResponse
2023.02.19 22:44:07.475 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/98_Modbus.pm line 2532.
2023.02.19 22:44:07.475 5: HA_Modbus_1: exprHash key PDULEXP is
2023.02.19 22:44:07.476 5: HA_Modbus_1: exprHash key VALUES is
2023.02.19 22:44:07.477 5: HA_PZEM_B1: perl expression eval evaluated package main; my $response = $oRef->{'$response'};1 to 1
2023.02.19 22:44:07.477 5: HA_Modbus_1: extra field PDULEXP after expr (1) is 1
2023.02.19 22:44:07.478 5: HA_PZEM_B1: perl expression eval evaluated package main; my $response = $oRef->{'$response'};pack('n',1) to 
2023.02.19 22:44:07.479 5: HA_Modbus_1: extra field VALUES after expr (pack('n',1)) is 
2023.02.19 22:44:07.479 3: HA_Modbus_1: parse custom response function code 66: data:  with unpack code none to fields  results in values:
2023.02.19 22:44:07.480 5: HA_Modbus_1: CheckChecksum (called from ParseResponse): 8011 is valid
2023.02.19 22:44:07.481 5: HA_Modbus_1: Profiling Fhem, before Read, now is 22:44:07.480, Fhem started at 22:41:28.515, Read started at 22:44:07.388
2023.02.19 22:44:07.481 5: HA_Modbus_1: Profiling add 0.093 to sum for Read (now is 22:44:07.480, start for Read was 22:44:07.388)
2023.02.19 22:44:07.482 5: HA_Modbus_1: now parsing response data objects, master is HA_PZEM_B1 relay is undefined
2023.02.19 22:44:07.482 5: HA_PZEM_B1: ParseDataString called from HandleResponse with data hex 0001, type h, adr 9042, op write
2023.02.19 22:44:07.483 5: HA_PZEM_B1: SplitDataString called from ParseDataString with data hex 0001, type h, adr 9042, valuesLen 1, op write
2023.02.19 22:44:07.484 5: HA_PZEM_B1: CreateDataObjects called from ParseDataString with objList h9042
2023.02.19 22:44:07.484 5: HA_PZEM_B1: CreateDataObjects sortedList h9042
2023.02.19 22:44:07.485 5: HA_PZEM_B1: CreateParseInfoCache called
2023.02.19 22:44:07.487 5: HA_PZEM_B1: CreateDataObjects unpacked 0001 with n to 1
2023.02.19 22:44:07.487 4: HA_PZEM_B1: CreateDataObjects assigns value 1 to Reset
2023.02.19 22:44:07.524 3: Noti_PZEM, Notify Zweck: Notify: PZEM DC-Modul, Name: HA_PZEM_B1, Ereignis: Reset: 1
2023.02.19 22:44:07.531 5: HA_PZEM_B1: ParseDataString created 1 readings
2023.02.19 22:44:07.532 4: HA_Modbus_1: HandleResponse done, current frame / read buffer: 01428011, id 1, fCode 66,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.16 secs ago, sent 0.16 secs ago,
response: id 1, fc 66, h9042, len 1, values 0001
2023.02.19 22:44:07.532 5: HA_Modbus_1: ResetExpect for HandleResponse from response to idle
2023.02.19 22:44:07.533 5: HA_Modbus_1: Profiling Idle, before Fhem, now is 22:44:07.533, Idle started at 22:41:28.584, Fhem started at 22:44:07.480
2023.02.19 22:44:07.534 5: HA_Modbus_1: Profiling add 0.053 to sum for Fhem (now is 22:44:07.533, start for Fhem was 22:44:07.480)
2023.02.19 22:44:07.535 5: HA_Modbus_1: DropFrame called from ReadAnswer - drop 01428011


Vielen, vielen Dank.
Wie geht es nun weiter? Kommt das ins offizielle Modul und ich benötige exclude_from_update nicht mehr? Wann?
//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Februar 2023, 14:51:58
Hallo Roger,

die Änderungen kommen sicher ins offizielle Modul, aber bevor ich das einchecke möchte ich die neuen Features noch ein wenig optimieren, testen und dokumentieren. Das wird noch ein paar Wochen dauern.

Gruß
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 20 Februar 2023, 17:53:26
Hi Stefan,
also warte ich mal ab - es geht ja alles. Vielen vielen Dank.  :)

ZitatZitat
Function codes dürfen nicht größer als 127 sein.
Wenn ein Slave einen Fehler melden möchte, dann antwortet er mit dem function code des Request +128. Da gibt es dann keine Zuweisung zu Objekten.
Wie würde man denn einen solchen Fehler sehen? Nur im Log oder wird auch ein Reading/state gesetzt worauf man in einem notify reagieren kann?
Wie würde man denn einen solchen Fehler sehen? Nur im Log oder wird auch ein Reading/state gesetzt worauf man in einem notify reagieren kann?
Kannst Du hier noch einen Hinweis geben?

Wenn Du mit Tests & Doku weiter bist --> teste ich wieder gern.
Vielen vielen Dank.  :)
//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bismosa am 21 Februar 2023, 18:25:18
Hallo!

Ich könnte mal ein wenig "Starthilfe" gebrauchen. Für mich ist das Thema Modbus ganz neu.
Ich habe einen Wechselrichter von Deye (sun 600 g3). Dieser lässt sich per Modbus auf Port 8899 TCP auslesen.
Ich habe ein Python-Script gefunden, das die Werte "problemlos" ausliest und als MQTT bereit stellt.
https://github.com/kbialek/deye-inverter-mqtt
Hier ist auch eine Liste der Modbus-Adressen (HEX).

Mir wäre es lieber, wenn ich es mit FHEM direkt umsetzen könnte. Von daher mache ich derzeit die ersten Versuche mit ModbusAttr.

Bisher habe ich nur die Definition
5 0 192.168.1.139:8899 TCP
Und habe versucht einen "scanModbusObjects" durchzuführen. Ich habe jedoch nur folgende Logeinträge:
2023.02.21 17:11:41 3: WP: Timeout waiting for a modbus response, read buffer empty,
request: id 3, scanobj fc 3 h131, len 1, tid 141, master device WP (scan objs), queued 21.21 secs ago, sent 2.00 secs ago


Also bisher konnte ich dem Ganzen keine Daten entlocken.
In der Python Version scheint es wichtig zu sein, dass die Seriennummer vom Logger in der Config angegeben wird.
Ich habe aber noch nicht verstanden wofür? Wird diese benötigt um überhaupt Daten auslesen zu können? Wie kann ich das dann im Modul machen?

Kann mir hier jemand Starthilfe geben?

Gruß
Bismosa
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 21 Februar 2023, 18:57:03
@bismosa

hier mal der Anfang

define PWP ModbusAttr 5 30 192.168.1.139:8899 TCP     // Modbusnummer + Zeitintervall + IP

oder

define PWP ModbusAttr 3 60 192.168.1.139:8899 RTU

attr PWP dev-h-combine 10
attr PWP dev-h-defPoll 1
attr PWP obj-h60-reading day_energy            // Adresse 0x3c
attr PWP obj-h60-len 4                                    // Länge noch feststellen
attr PWP obj-h60-unpack (a4)                         // Parameter zum entpacken  ... n oder F> oder f> ...
....



pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bismosa am 22 Februar 2023, 10:27:14
Hallo!

Danke für die Starthilfe  :)

Leider bekomme ich keine Daten ausgelesen. Auszug aus dem Log:

2023.02.22 09:29:28 3: WP: Timeout waiting for a modbus response, read buffer empty, id 86, fCode 222, tid 42241,
request: id 3, read fc 3 h60, len 4, tid 142, master device WP, reading day_energy (getUpdate for day_energy len 4), queued 2.13 secs ago, sent 2.00 secs ago
2023.02.22 09:30:28 3: WP: Timeout waiting for a modbus response, read buffer empty, id 86, fCode 222, tid 42241,
request: id 3, read fc 3 h60, len 4, tid 58, master device WP, reading day_energy (getUpdate for day_energy len 4), queued 2.01 secs ago, sent 2.00 secs ago
2023.02.22 09:31:28 3: WP: Timeout waiting for a modbus response, read buffer empty, id 86, fCode 222, tid 42241,
request: id 3, read fc 3 h60, len 4, tid 170, master device WP, reading day_energy (getUpdate for day_energy len 4), queued 2.10 secs ago, sent 2.05 secs ago
2023.02.22 09:32:28 3: WP: Timeout waiting for a modbus response, read buffer empty, id 86, fCode 222, tid 42241,
request: id 3, read fc 3 h60, len 4, tid 35, master device WP, reading day_energy (getUpdate for day_energy len 4), queued 2.08 secs ago, sent 2.00 secs ago


Dafür bekomme ich gelegentlich solche Einträge:

2023.02.22 09:29:18 3: WP: readfn got data while EXPECT was set to idle: a5010010475356de9747f800b515
2023.02.22 09:33:18 3: WP: readfn got data while EXPECT was set to idle: a5010010475559de9747f800ba15


Gibt es denn so etwas wie ein Login? Ich vermute das es noch irgendwie mit der Seriennummer zusammen hängen könnte?
In dem Python Modul wird ein "request_frame" für Abfragen gebildet:
https://github.com/kbialek/deye-inverter-mqtt/blob/0e6d1ecf24ad498b5f50ee98c4f4b2868a0c20b4/deye_modbus.py#L50
Dort wird dann u.a. auch die Inverter Seriennummer verwendet.
Oder liege ich hier völlig falsch?

Gruß
Bismosa
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 22 Februar 2023, 18:13:25
@Bismosa

Häng mal deine Konfiguration hier an
Pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bismosa am 22 Februar 2023, 19:43:12
Hallo!

das ist bisher nicht viel:

defmod WP ModbusAttr 5 60 192.168.1.139:8899 TCP
attr WP dev-h-combine 10
attr WP dev-h-defPoll 1
attr WP obj-h60-len 4
attr WP obj-h60-reading day_energy
attr WP obj-h60-unpack (a4)
attr WP room PV


Ich hatte es auch mit

defmod WP ModbusAttr 3 60 192.168.1.139:8899 RTU

probiert...

Gruß
Bismosa
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 23 Februar 2023, 09:37:29
@Bismosa

Stimmt die Modbus Adresse? Du hast einmal die 5 und dann die 3!?

Per Python kannst du etwas auslesen?


Pejonp
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: bismosa am 23 Februar 2023, 11:42:16
Hallo!

Die 5 und die 3 habe ich aus deinen Beispielen verwendet.
Ich glaube so einfach ist das Auslesen nicht. Weitere Infos gibt es hier:
https://pysolarmanv5.readthedocs.io/en/stable/solarmanv5_protocol.html

Ich glaube mir ist das dann doch etwas zu kompliziert. Da nutze ich dann doch lieber das fertige Python script und lasse mir die Daten per MQTT an FHEM senden.

Vielen Dank für die Hilfsbereitschaft!

Gruß
Bismosa
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 März 2023, 16:43:49
Das Solarman-Protokoll scheint kein Modubs zu sein sondern ein proprietäres Protokoll, bei dem Modbus-Frames nach einem eigenen Header eingefügt werden können ...

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 11 März 2023, 16:46:53
Anbei eine neue Version des Moduls zum Testen bevor ich es einchecke und es per update verteilt wird.
Man kann nun custom function codes selbst definieren, das Loglevel wurde bei einigen Events von 3 auf 4 erhöht und ein par Bugs gefixt.
Zudem sind einige Data types vordefiniert, so dass man meist keinen unpack code und keine len mehr angeben muss und der data type reicht.
Ich hoffe es funktioniert noch alles :-)

Gruss
   Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 11 März 2023, 17:43:57
Zitat von: StefanStrobel am 11 März 2023, 16:46:53
Anbei eine neue Version des Moduls zum Testen bevor ich es einchecke und es per update verteilt wird.
Man kann nun custom function codes selbst definieren, das Loglevel wurde bei einigen Events von 3 auf 4 erhöht und ein par Bugs gefixt.
Zudem sind einige Data types vordefiniert, so dass man meist keinen unpack code und keine len mehr angeben muss und der data type reicht.
Ich hoffe es funktioniert noch alles :-)
Gruss Stefan

Hi Stefan,
soll in dieser Version auch die dev-fc Erweiterung funktionieren?

Lesen/get von den Geräten klappt. Bei Ausführung vom set-Befehl erhalte ich:
2023.03.11 17:32:48.275 1: PERL WARNING: Use of uninitialized value $newType in substitution (s///) at 01_FHEMWEB.pm line 2377.
2023.03.11 17:32:48.277 1: PERL WARNING: Use of uninitialized value $newType in string ne at 01_FHEMWEB.pm line 2378.
2023.03.11 17:32:48.280 1: PERL WARNING: Use of uninitialized value $oldType in string ne at 01_FHEMWEB.pm line 2378.
Undefined subroutine &Modbus::HexIfNeeded called at 98_Modbus.pm line 2546.

und FHEM ist weg.

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 12 März 2023, 12:19:46
Ah, sorry - da gehört auch eine neue Version der Utils dazu.
Die muss wie üblich nach lib/FHEM/HTPMOD/

Gruss
  Stefan
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 12 März 2023, 14:58:35
So jetzt läuft es.  :)
Habe die Dateien auf allen meine FHEM-Servern und -Instanzen ersetzt - bisher nichts Auffälliges.

//Roger
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mad-at am 12 März 2023, 15:57:29
Hallo!

Ich würde ein wenig Hilfe brauchen. Ich habe erfolgreich meine drexel&weiss stratos mittels ModBus/ModbusAttr in FHEM integriert. Werte Lesen funktioniert einwandfrei. Aber beim Schreiben des Registers h5002, das ich korrekt auslesen kann, bekomme ich einen Error "illegal data value" ("Schreib- / lesezugriff auf Parameter verweigert, Wert ausserhalb des Bereichs") - siehe Log ganz unten (ich habs mit LF umgeben damit man es besser findet).
Ich verstehe nicht, warum Auslesen korrekt klappt, aber Setzen nicht? (Das Register ist explizit zum Schreiben gedacht). Wenn er vom aus dem Register gelesenen gelieferten Hexcode zum richtigen Wert kommt, müsste doch der Weg zurück auch klappen?
Edit: Es ist FC16 - würde das aber nicht durch "len 2" ohnehin vorgegeben? /Edit (ja es wird eh als FC16 geschrieben siehe Log)

Vielleich hat jemand einen Tipp?

Hier ein List des Devices:

Internals:
   DEF        0 60 192.168.1.201:8899 TCP
   DeviceName 192.168.1.201:8899
   EXPECT     idle
   FD         4
   FUUID      640a1936-f33f-db1a-c548-fc2cdc36d517c360
   IODev      DrexelWeissStratos
   Interval   60
   LASTOPEN   1678704516.98814
   LeadingZeros 1
   MODBUSID   0
   MODE       master
   MODULEVERSION Modbus 4.4.14 - 30.1.2023
   NAME       DrexelWeissStratos
   NOTIFYDEV  global
   NR         1427
   NTFY_ORDER 50-DrexelWeissStratos
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   eventCount 36
   nextOpenDelay 60
   Helper:
     DBLOG:
       AktuelleLuefterstufe:
         DBLogging:
           TIME       1678704879.74361
           VALUE      min
       CO2_Raumluft:
         DBLogging:
           TIME       1678704879.54451
           VALUE      633.0 ppm
       Luefterstufe_setzen:
         DBLogging:
           TIME       1678704879.94239
           VALUE      auto
       TemperaturAussenluft:
         DBLogging:
           TIME       1678704879.34492
           VALUE      15.1 °C
       TemperaturRaumluft:
         DBLogging:
           TIME       1678704879.14493
           VALUE      22.4 °C
       state:
         DBLogging:
           TIME       1678704518.90177
           VALUE      CONNECTED
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2023-03-13 11:54:39   AktuelleLuefterstufe min
     2023-03-13 11:54:39   CO2_Raumluft    633.0 ppm
     2023-03-13 11:54:39   Luefterstufe_setzen auto
     2023-03-13 11:54:39   TemperaturAußenluft 15.1 °C
     2023-03-13 11:54:39   TemperaturRaumluft 22.4 °C
     2023-03-13 11:48:38   state           opened
   REMEMBER:
     lid        0
     lname      DrexelWeissStratos
     lrecv      1678704879.94071
     lsend      1678704879.84382
   defptr:
     DrexelWeissStratos 0
   gotReadings:
     Luefterstufe_setzen auto
   lastRead:
     h00200     1678704879.14401
     h00202     1678704879.34399
     h00230     1678704879.54361
     h01066     1678704879.74289
     h05002     1678704879.94193
Attributes:
   dev-h-write 6
   dev-timing-timeout 2.6
   obj-h00200-expr $val / 1000
   obj-h00200-format %.1f °C
   obj-h00200-len 2
   obj-h00200-poll 1
   obj-h00200-reading TemperaturRaumluft
   obj-h00200-revRegs 1
   obj-h00202-expr $val / 1000
   obj-h00202-format %.1f °C
   obj-h00202-len 2
   obj-h00202-poll 1
   obj-h00202-reading TemperaturAußenluft
   obj-h00202-revRegs 1
   obj-h00230-format %.1f ppm
   obj-h00230-len 2
   obj-h00230-poll 1
   obj-h00230-reading CO2_Raumluft
   obj-h00230-revRegs 1
   obj-h01066-len 2
   obj-h01066-map 0:aus, 1:min, 2:normal, 3:max
   obj-h01066-poll 1
   obj-h01066-reading AktuelleLuefterstufe
   obj-h01066-revRegs 1
   obj-h05002-allowWrite 1
   obj-h05002-hint aus,min,normal,max,auto,party
   obj-h05002-len 2
   obj-h05002-map 0:aus, 1:min, 2:normal, 3:max, 4:auto, 5:party
   obj-h05002-max 5
   obj-h05002-min 0
   obj-h05002-poll 1
   obj-h05002-reading Luefterstufe_setzen
   obj-h05002-revRegs 1
   obj-h05002-set 1
   room       Heizung
   userReadings Luefterstufe_setzen:aus,min,normal,max,auto,party
   verbose    1
   webCmd     Luefterstufe_setzen



2023.03.12 15:15:03 4: DrexelWeissStratos: set called with Luefterstufe_setzen (h05002) setVal = 1
2023.03.12 15:15:03 5: DrexelWeissStratos: GetSetChecks with force
2023.03.12 15:15:03 5: DrexelWeissStratos: GetSetChecks returns success
2023.03.12 15:15:03 5: DrexelWeissStratos: checkRange for FormatSetVal checks 1 against min 0
2023.03.12 15:15:03 5: DrexelWeissStratos: checkRange for FormatSetVal checks 1 against max 5
2023.03.12 15:15:03 5: DrexelWeissStratos: set packed hex 31 with n to hex 0001
2023.03.12 15:15:03 4: DrexelWeissStratos: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 0, write fc 16 h05002, len 2, value 0001, tid 189, master device DrexelWeissStratos, reading Luefterstufe_setzen (set Luefterstufe_setzen)
2023.03.12 15:15:03 5: DrexelWeissStratos: QueueRequest called from DoRequest with h05002, qlen 0 from master DrexelWeissStratos through io device DrexelWeissStratos
2023.03.12 15:15:03 5: DrexelWeissStratos: ProcessRequestQueue called from QueueRequest as direct:DrexelWeissStratos, qlen 1, force, request: request: id 0, write fc 16 h05002, len 2, value 0001, tid 189, master device DrexelWeissStratos, reading Luefterstufe_setzen (set Luefterstufe_setzen), queued 0.00 secs ago
2023.03.12 15:15:03 5: DrexelWeissStratos: checkDelays busDelayRead, last activity on bus was 21.163 secs ago, required delay is 0
2023.03.12 15:15:03 5: DrexelWeissStratos: checkDelays sendDelay, last send to same device was 21.259 secs ago, required delay is 0.1
2023.03.12 15:15:03 5: DrexelWeissStratos: checkDelays commDelay, last communication with same device was 21.163 secs ago, required delay is 0.1
2023.03.12 15:15:03 5: DrexelWeissStratos: checkDelays clientSwitchDelay is not relevant
2023.03.12 15:15:03 4: DrexelWeissStratos: ProcessRequestQueue (V4.4.14 - 30.1.2023) qlen 1, sending 00bd000000090010138a0002040001 via 192.168.1.201:8899, read buffer empty,
request: id 0, write fc 16 h05002, len 2, value 0001, tid 189, master device DrexelWeissStratos, reading Luefterstufe_setzen (set Luefterstufe_setzen), queued 0.00 secs ago
2023.03.12 15:15:03 5: DrexelWeissStratos: Send called from ProcessRequestQueue
2023.03.12 15:15:03 5: DevIo_SimpleWrite DrexelWeissStratos: 00bd000000090010138a0002040001
2023.03.12 15:15:03 5: DrexelWeissStratos: ReadAnswer called from SetLDFn
2023.03.12 15:15:03 5: DrexelWeissStratos: ReadAnswer remaining timeout is 2.5950779914856
2023.03.12 15:15:04 5: DrexelWeissStratos: ReadAnswer got: 00bd00000003009003
2023.03.12 15:15:04 5: DrexelWeissStratos: ParseFrameStart called from ReadAnswer
2023.03.12 15:15:04 4: DrexelWeissStratos: ParseFrameStart (TCP, master) extracted id 0, fCode 144, tid 189, dlen 3 and potential data 03
2023.03.12 15:15:04 5: DrexelWeissStratos: HandleResponse called from ReadAnswer
2023.03.12 15:15:04 5: DrexelWeissStratos: ParseResponse called from HandleResponse


2023.03.12 15:15:04 4: DrexelWeissStratos: HandleResponse got response with error code 90 / 03, illegal data value


2023.03.12 15:15:04 4: DrexelWeissStratos: HandleResponse done, current frame / read buffer: 00bd00000003009003, fCode 144, tid 189,
request: id 0, write fc 16 h05002, len 2, value 0001, tid 189, master device DrexelWeissStratos, reading Luefterstufe_setzen (set Luefterstufe_setzen), queued 0.10 secs ago, sent 0.10 secs ago,
response: no id, fc 144, error code 03, len 2
2023.03.12 15:15:04 5: DrexelWeissStratos: ResetExpect for HandleResponse from response to idle
2023.03.12 15:15:04 5: DrexelWeissStratos: DropFrame called from ReadAnswer - drop 00bd00000003009003
2023.03.12 15:15:04 5: DrexelWeissStratos: set is sending read after write
2023.03.12 15:15:04 4: DrexelWeissStratos: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 0, read fc 3 h05002, len 2, tid 138, master device DrexelWeissStratos, reading Luefterstufe_setzen (set Luefterstufe_setzen Rd),
response: no id, no fcode


Edit2: Er schreibt ja "00bd000000090010138a0002040001". Sollte Er nicht eigentlich eher so etwas wie 00bd000000090010138a00020400000001 schreiben? Er muss doch zwei Register füllen? 138a ist das Register, dann 0002 für 2 Register, 04 für 4 Bytes die er schreiben will, dann kommen aber nur 2 Bytes nämlich 00 01. Verstehe ich nicht.  /Edit2

Falls benötigt:
Hier sind die Register dokumentiert: https://github.com/diresi/drexel-und-weiss/blob/master/900.6667_00_TI_Modbus_Parameter_V4.01_DE.pdf

Hier ist die Modbus Implementation von Drexel und Weiss dokumentiert: https://gasserenergy.ch/wp-content/uploads/2015/09/900.6660_01_TI_Modbus_RTU_DE.pdf

Danke!

Matthias
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 14 März 2023, 10:38:17
Hallo Matthias, kennst du QModMaster https://sourceforge.net/projects/qmodmaster/ (https://sourceforge.net/projects/qmodmaster/)? Ist ein super hilfreiches Tool für Modbus Verbindungen zu untersuchen. Wann immer ich ein komisches Modbusgerät habe teste ich es zuerst mit QModMaster da man damit nach einer kurzen Eingewöhnungszeit sehr rasch "rumspielen" kann. Es ist ein Monitor dabei, dort siehst du die übertragenen Bytes und die Antworten. So kannst du herausfinden, was dein DrexelWeissStratos genau möchte damit kein Fehler zurückgemeldet wird.

Beste Grüsse, Anton
Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mad-at am 14 März 2023, 17:26:04
Vielen Dank Anton!
Kannte ich nicht!
Tatsächlich kann ich die Register damit korrekt lesen:
[TCP]>Rx > 17:09:28:782 - 00  22  00  00  00  07  00  03  04  00  00  00  04 
und schreiben - und das Payload Muster ist genau jenes welches ich oben im Post schon "gewünscht" hatte: 00 00 00 0x


[TCP]>Tx > 17:13:04:916 - 00  29  00  00  00  0B  00  10  13  8A  00  02  04  00  00  00  04 
[TCP]>Rx > 17:13:05:084 - 00  29  00  00  00  06  00  10  13  8A  00  02 
Sys > 17:13:05:084 - values written correctly.
[TCP]>Tx > 17:21:36:754 - 00  2B  00  00  00  0B  00  10  13  8A  00  02  04  00  00  00  00 
[TCP]>Rx > 17:21:37:064 - 00  2B  00  00  00  06  00  10  13  8A  00  02 
Sys > 17:21:37:064 - values written correctly.


Und die DrexelWeiss richtet sich auch danach...  ;)

Aber wie entlocke ich das ModBusAttr? Das scheint unbedingt 00 0x schreiben zu wollen, obwohl len2 gesetzt ist und es dementsprechend korrekt FC16 meldet.

Auffällig auch: er will anscheinend dass das Register zuerste gelesen wird und dann geschrieben? Zumindest mit QModMaster gibt er mir sonst "invalid data". Manuell Lesen mit ModBusAttr und dann schreiben hilft aber nicht...

LG
Matthias

Titel: Antw:Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 17 März 2023, 22:02:07
Hmmm, hast du schon die unpack Option ausprobiert? Ich bin da zu wenig tief in der Materie drin, vielleicht hilft aber ein obj-h05002-unpack l ? Also l für long == 32bit, weil bei dir werden ja nur 16bit übertragen beim Set Befehl, also 00 0x statt 00 00 00 0x.

Das mit dem Register zuerst lesen und erst dann schreiben finde ich komisch. Wenn du direkt ein "set" absetzt mit QModMaster reklamiert er? Wie ist genau der Vorgang?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mad-at am 19 März 2023, 15:16:52
Ja, aber unpack l liefert beim Lesen 1024 anstelle von 4
unpack n liefert zusammen mit revregs 1 die derzeit richtige Antwort (00eb0000000700030400000004), aber ich bin beim Setzen (in diesem Fall von 0) wieder bei einem dem ursprünglichen Poblem sehr ähnlichen: "sending 0026000000090010138a0002040000" und bekomme zurück "HandleResponse got response with error code 90 / 03, illegal data value"

Mit QModMaster:
[TCP]>Tx > 15:14:47:267 - 00  10  00  00  00  0B  00  10  13  8A  00  02  04  00  00  00  00 
[TCP]>Rx > 15:14:47:372 - 00  10  00  00  00  06  00  10  13  8A  00  02
Sys > 15:14:47:372 - values written correctly.

Das mit dem read before write bei QmodMaster vergiss bitte wieder, Fehler zwischen Bildschirm und Tastatur  ;)

Aber vielleicht mache ich einen grundsätzlichen Fehler: Ich habe RevRegs aktiviert, weil FHEM mir sonst keine Werte ausspuckt. Wenn ich das Log aber nochmal genau anschaue, dann darf ich eigentlich nicht revRegs machen:

2023.03.19 15:19:36 5: DrexelWeissStratos: ParseDataString called from HandleResponse with data hex 00000004, type h, adr 05002, op read
2023.03.19 15:19:36 5: DrexelWeissStratos: SplitDataString called from ParseDataString with data hex 00000004, type h, adr 05002, valuesLen 2, op read
2023.03.19 15:19:36 5: DrexelWeissStratos: CreateDataObjects called from ParseDataString with objList h05002
2023.03.19 15:19:36 5: DrexelWeissStratos: CreateDataObjects sortedList h05002
2023.03.19 15:19:36 5: DrexelWeissStratos: CreateParseInfoCache called
2023.03.19 15:19:36 5: DrexelWeissStratos: ReverseWordOrder is reversing order of up to 2 registers

2023.03.19 15:19:36 5: DrexelWeissStratos: ReverseWordOrder for CreateDataObjects is transforming 00000004 to 00040000

2023.03.19 15:19:36 5: DrexelWeissStratos: CreateDataObjects unpacked 00040000 with n to 4
2023.03.19 15:19:36 5: DrexelWeissStratos: MapConvert called from CreateDataObjects converted 4 (4) to auto with map 0:aus, 1:min, 2:normal, 3:max, 4:auto, 5:party
2023.03.19 15:19:36 4: DrexelWeissStratos: CreateDataObjects assigns value auto to Luefterstufe_setzen
2023.03.19 15:19:36 5: DrexelWeissStratos: ParseDataString created 1 readings
2023.03.19 15:19:36 4: DrexelWeissStratos: HandleResponse done, current frame / read buffer: 00810000000700030400000004, fCode 3, tid 129,
request: id 0, read fc 3 h05002, len 2, tid 129, master device DrexelWeissStratos, reading Luefterstufe_setzen (getUpdate for Luefterstufe_setzen len 2), queued 2.20 secs ago, sent 0.11 secs ago,
response: no id, fc 3, h05002, len 2, values 00000004

Also habe ich das Ganze jetzt folgendermaßen zu Fuß gelöst:

revRegs 0
unpack H*

Damit bekomme ich die raw hex Werte, das ist vielleicht nicht so schön, aber lässt sich mit einem map wunderschön ausblenden. Und siehe da: jetzt kann ich auch korrekt setzen :)
Vielen Dank für Deine Hilfe und den entscheidenden Denkanstoß!
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 20 März 2023, 13:19:39
Es freut mich zu hören, dass es zumindest mit raw Hex und map geklappt hat :-) Tönt für mich weiterhin ein wenig nach einer pack/unpack & Endian Geschichte. Wenn es mit Hex klappt kann man es ja auch so laufen lassen ;-)
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 März 2023, 13:44:36
Hallo zusammen,

H* und map ist sicher ein gangbarer Weg, wenn es eh nur um ein paar mögliche Werte geht. Bei echten Messwerten braucht man aber doch den richtigen unpack-Code und ,,n" ist definitiv falsch, da n für unsigned short (16 Bit) steht und ein Code für 32 Bit benötigt wird. ,,l" steht für signed long (32 Bit), aber naheliegender wäre z.B. ,,L>" oder ,,L<,, für unsigned long in big bzw. little endian form.
Siehe https://perldoc.perl.org/functions/pack

Da hier jedes Gerät seine Daten anders darstellt, muss man das testen.

In der neuen Version des Moduls kann man übrigens auch statt unpack code und length direkt einen Typ wie ,,unsigned long little" oder ,,unsigned long big" angeben.
Z.B. attr obj-h5002-type unsigned long big
unpack code und len sollten dann weggelassen werden, da sie den type überschreiben würden.


Gruß
    Stefan

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mad-at am 20 März 2023, 15:02:07
Lieber Stefan,

vielen Dank! Ja, ausprobiert, "unpack L>" funktioniert großartig, Danke!

LG,
Matthias
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tueftler1983 am 26 April 2023, 13:57:03
Darf ich fragen welche Hardware ich am.Raspberry PI brauche um einen Zähler mit Modbus RTU an Fhem anzubinden?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Adimarantis am 26 April 2023, 19:57:39
Ein RS485 Modul oder USB Adapter.
Ich hab sowas an meinen Raspi angeschlossen, was prima funktioniert:
https://www.aliexpress.com/item/1005001346792286.html
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 April 2023, 16:43:23
Wenn es Modbus-RTU über RS485 ist, dann gibt es hunderte USB-zu-RS485-Adapter, die mal besser mal schlechter funktionieren. Ein (ggf. auch überflüssiges) Qualitätsmerkmal wäre dabei eine galvanische Trennung.
Manche Geräte machen aber auch Modbus-RTU über RS232, dann ist es ein normaler RS232-Adapter.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 02 Mai 2023, 22:17:28
Ich habe 3 der "Waveshare Industrial USB TO RS232/RS485/TTL Isolated Converter" https://www.aliexpress.com/item/1005004359061166.html (https://www.aliexpress.com/item/1005004359061166.html) seit über einem Jahr im Einsatz (an einem Raspberry), funktionieren einwandfrei. Sind etwas teurer als normale USB-to-RS485 Adapter.
Was ich darauf achten würde: ganz billige Adapter haben keine eindeutige USB ID, das heisst sie bekommen eventuell eine andere Gerätekennung wenn du sie an einem anderen USB Port ansteckst. Die Waveshare Adapter haben eine Kennung, d.h. man kann sie via "/dev/serial/by-id" finden und so in FHEM einbinden. Dann spielt es keine Rolle, an welchem USB Port sie hängen
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Sonnenwolf am 11 Mai 2023, 15:23:19
Hallo Stefan,

ich möchte mir ein ModBus Relay bauen auf das ich per loopbach 127.0.0.1 zugreifen kann. Hintergrund ist dass ich Aurora/ABB/Fimer Wechselrichter und CG-Zähler per Modbus USB-RS485- Adapter auslesen möchte wobei ich einen RPI mit FHEM und SolarView instalation nutze. Aktuel greift Solarview direkt auf den RS485-Adapter zu doch möchte ich gerne die CG-Zähler per ModBus-TCP einem anderen Logger verfügbar machen.
Meine Idee ist ich binde den RS485-Adapter in FHEM ein und erstelle ein Relay auf das ich per TCP zugreifen kann. Problem ist wenn ich in Solarview das loop back einstelle wird FHEM total überlastet so dass auch kein log mehr geschrieben wird. Bei externen zugriff ist das kein problem.

Mein Define:
defmod MB_485 Modbus /dev/ttyUSB1@19200,8,N,1
defmod MB_WR1 ModbusAttr 1 0
defmod MBBridge_WR1 ModbusAttr 1 relay 127.0.0.1:5021 RTU to MB_WR1
defmod MB_WR2 ModbusAttr 2 0
defmod MBBridge_WR2 ModbusAttr 2 relay 127.0.0.1:5021 RTU to MB_WR2
.
.
.
Mach ich hier grundsätzlch etwas falsch oder ist das nicht ohne tiefere eingriffe möglich?
Ich habe auch schon mit den IP-Adressen gespielt zB. "global" oder die des FHEM servers.


Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Hausrobot am 16 Mai 2023, 21:44:29
Hallo ihr,

ich habe einen Solaredge E30K Wechselrichter und eine Solaredge-Wallbox (aka keba P30x). Leider lässt der SE WR nur einen Modbus TCP-Client zu. Proof: Greife ich via FHEM zu, dann kann ein SolarMon (geniale App, Handy) nicht mehr auf den Modbus zugreifen. 3 SolarMon parallel dagegen schon.

Nun ist es so, dass aktuell das SE-eigene Überschussladen nur bis zu WR-Typ SE15k unterstützt wird. Das SE30k Firmware-Update offen  :'( .

Lösung? Vielleicht funktioniert das ÜS-Laden mit https://github.com/evcc-io/evcc . Dazu müsste ich aber eine zweiten Modbus-Client auf den SE30k schalten dürfen. NOP.

Gibt es einen Modbus TCP-Proxy (Multiclient)? Im Modul hier habe ich nichts gefunden. Und https://github.com/3cky/mbusd ist ein Protokollmapper TCP RTU, wenn ich es richtig verstehe.

Gesucht:
SE WR (Modbus TCP)
 ∟ modbus-Proxy
     ⊢ FHEM
     ⊢ EVCC
     ⊢ SolarMon
     ⊢ ...

Weiß jemand Rat?

Viele Grüße
Hausrobot
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Mai 2023, 19:46:03
Hallo Sonnenwolf,

Stell doch mal verbose auf 5 und starte dann erst Solarview. bevor nichts mehr geht, muss ja etwas im Log sichtbar sein.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 17 Mai 2023, 19:48:36
Zitat von: Hausrobot am 16 Mai 2023, 21:44:29Gibt es einen Modbus TCP-Proxy (Multiclient)? Im Modul hier habe ich nichts gefunden. Und https://github.com/3cky/mbusd ist ein Protokollmapper TCP RTU, wenn ich es richtig verstehe.

Hallo Hausrobot,

Du kannst Fhem als Modbus-Relay verwenden. Das evcc-Szenario kam hier auch schon mal vor - müsste im Forum zu finden sein...

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 21 Mai 2023, 17:21:41
Ihr Lieben, Mmh, gedacht Modbus bekomme ich jetzt easy hin. Stefan hatte mir ja schonmal geholfen, kann man verstehen und adaptieren. Denkste.

4 Stunden den Wechselrichter/RCC gequält. Den Modbus-Adapter (die Extra-Hardware am Wechselrichter) sogar mehrmals zum Neustart verleitet, so falsch müssen meine Anweisungen für das arme Gerät sein ;)

Andere Readings vom Wechselrichter bekomme ich wunderbar rein

So frage ich als Beispiel verkürzt Infos ab

defmod Studer485_XTM ModbusAttr 43 7
attr Studer485_XTM dev-defLen 2
attr Studer485_XTM dev-defShowGet 1
attr Studer485_XTM dev-defUnpack f>
attr Studer485_XTM dev-h-read 3
attr Studer485_XTM dev-h-write 16
attr Studer485_XTM dev-i-read 4
attr Studer485_XTM dev-timing-timeout 1
attr Studer485_XTM obj-i16-format %.2f
attr Studer485_XTM obj-i16-poll 1
attr Studer485_XTM obj-i16-reading Low_Voltage_disconnect

und das habe ich minimalst für die Messages versucht (andere ID weil anderes Gerät im Verbund)

defmod Studer485_Gateway ModbusAttr 33 55
attr Studer485_Gateway dev-defPoll 1
attr Studer485_Gateway dev-defShowGet 1
attr Studer485_Gateway dev-i-read 4
attr Studer485_Gateway dev-timing-timeout 1
attr Studer485_Gateway event-on-change-reading Last_Message
attr Studer485_Gateway group Xtender
attr Studer485_Gateway obj-i0-len 1
attr Studer485_Gateway obj-i0-reading Message_Count_must_read_first
attr Studer485_Gateway obj-i2-len 4
attr Studer485_Gateway obj-i2-reading Last_Message


Nach Anleitung müsste ich nach Register 0 die 1 Abfragen. Dann bekomme ich aber bei jeder Anfrage einen Neustart des Adapters. Hab ich mal Register 2 probiert. Bekomme ich auch Antwort, aber richtig/sinnig ist die nicht. Gemein ist, dass die Messages komplett anders als alle anderen Infos/Settings gelesen/geschrieben werden. Hat einer von euch das "Prinzip Modbus RTU" verstanden und kann mir anhand des 3 Seiten-Auszugs der Anleitung sagen, was ich falsch mache? Oder ein kleiner Schubs?

Grüsse!
H.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 21 Mai 2023, 18:38:55
Hallo Holle,

vermutlich musst Du nach dem Lesen von Input-Register 0 erst mal prüfen, ob auch Nachrichten zum Lesen anstehen.
Dann Input-Register 1 (nicht 2) mit Länge 4 lesen.
Was passiert denn dann?

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 21 Mai 2023, 18:53:44
Hallo Stefan, wenn ich statt

attr Studer485_Gateway obj-i2-len 4
attr Studer485_Gateway obj-i2-reading Last_Message

attr Studer485_Gateway obj-i1-len 4
attr Studer485_Gateway obj-i1-reading Last_Message

probiere (davon ausgehend, dass "len 4" length 4 ist) macht mein Adapter (das Teil was an die Solaranlage ageschlossen ist) einen Neustart. Passend ist, dass dann der Message_Count_must_read_first runterzählt. Laut Anleitung wird die Message gelöscht wenn ausgelesen. Das macht Sinn, aber diese Neustarts können nicht richtig sein.

Wie ich das Auslesen der Messages davon abhängig machen kann, dass auch welche existieren, ist mir auch schleierhaft.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 21 Mai 2023, 19:11:33
Es könnte sein, dass

1) das Teil abschmiert, weil ausgelesen wird, obwohl keine Messages da sind.

2) bekomme ich mit i1 nur immer das Reading "11" oder "54305". Allerdings hat es gerade keine Messages und ich stochere ein bißchen im Dunklen, was diese mal "11", mal "54305" bedeuten könnten.
Interessant wäre, wie ich die komplette Message entwursteln könnte. Oder es ist ein Platzhalter für keine Messages, oder, oder.
Allerdings habe ich mit i1 auch als es Messages gab dann nur eine "11" bekommen. Das könnte die ID des Gerätes sein, die die Message hinterlegt hat, aber dann müßte noch mehr Info im Reading kommen.

3) Wie kann man in Modbus ein IF THEN einbauen?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 22 Mai 2023, 15:43:00
Internals:
   DEF        33 55
   FUUID      646a39ea-f33f-6bb4-d3dc-f92f7fb67885441d
   IODev      Eastron
   Interval   55
   MODBUSID   33
   MODE       master
   MODULEVERSION Modbus 4.4.02 - 31.3.2021
   NAME       Studer485_Gateway
   NOTIFYDEV  global
   NR         591
   NTFY_ORDER 50-Studer485_Gateway
   PROTOCOL   RTU
   STATE      inactive
   TYPE       ModbusAttr
   FRAME:
   OLDREADINGS:
   READ:
   READINGS:
     2023-05-22 15:21:50   Last_Message    11
     2023-05-22 15:29:02   Message_Count_must_read_first 14
     2023-05-22 15:29:14   state           inactive
   REMEMBER:
     lrecv      1684762143.34253
     lsend      1684762143.3173
   gotReadings:
     Message_Count_must_read_first 14
   lastRead:
     i0         1684762142.69145
     i1         1684761710.9561
     i2         1684688427.30298
Attributes:
   dev-defPoll 1
   dev-defShowGet 1
   dev-defUnpack n
   dev-i-read 4
   dev-timing-timeout 1
   disable    0
   group      Xtender
   obj-i0-len 1
   obj-i0-reading Message_Count_must_read_first
   obj-i1-len 4
   obj-i1-reading Last_Message

inactive, weil ich mir die Messages "aufheben" möchte um weiter zu probieren. "11" könnte die ID des Wechselrichters sein. Die "54305" scheint zu kommen, wenn es keine Messages mehr gibt.

Es scheint er liest zwei Register statt 4? Könnte bedeuten, die anderen zwei sind leer? Das Ergebnis von i1 und i2 wird in ein Ergebnis gepackt? i2 sollte eigentlich die gesuchte Information (Errorcode) enthalten.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: fireball am 28 Mai 2023, 08:07:38
Moinsen und Frohe Pfingsten euch...

ich habe seit kurzem ein Problem mit meinem ModbusAttr Device, um meinen SunnyBoy 2.5 auszulesen.
Das auslesen selber klappt, aber im Sekundentakt wird connected und disconneced.

Ich habe mich erst gewundert, warum mein eigener Status in FHEM nicht mehr angezeigt wird, aber dann habe ich gesehen, dass permanent open/connected/disconneced im state steht.
Der Event-Monitor sagt:
2023-05-28 08:05:14 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:14 ModbusAttr SunnyBoy Temperatur: 0
2023-05-28 08:05:14 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:15 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:15 ModbusAttr SunnyBoy Netzstrom_Phase_L2: 0.00
2023-05-28 08:05:15 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:16 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:33 ModbusAttr SunnyBoy Status: 0
2023-05-28 08:05:33 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:33 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:33 ModbusAttr SunnyBoy Wirkleistung_Begrenzung: 0
2023-05-28 08:05:33 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:34 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:35 ModbusAttr SunnyBoy Gesamtertrag: 122
2023-05-28 08:05:35 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:36 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:36 ModbusAttr SunnyBoy Tagesertrag: 0.000
2023-05-28 08:05:36 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:37 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:37 ModbusAttr SunnyBoy DC_Strom_Eingang: 0.00
2023-05-28 08:05:37 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:38 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:38 ModbusAttr SunnyBoy DC_Spannung_Eingang: 0.00
2023-05-28 08:05:38 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:39 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:39 ModbusAttr SunnyBoy DC_Leistung_Eingang: 0.00
2023-05-28 08:05:39 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:40 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:40 ModbusAttr SunnyBoy Wirkleistung_Phase_L2: 0
2023-05-28 08:05:40 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:41 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:41 ModbusAttr SunnyBoy Netzspannung_Phase_L2: 0.00
2023-05-28 08:05:41 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:42 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:42 ModbusAttr SunnyBoy Nennfrequenz: 0.00
2023-05-28 08:05:42 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:43 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:43 ModbusAttr SunnyBoy Wirkleistung_Max: 0
2023-05-28 08:05:43 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:44 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:44 ModbusAttr SunnyBoy Temperatur: 0
2023-05-28 08:05:44 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:45 ModbusAttr SunnyBoy CONNECTED
2023-05-28 08:05:45 ModbusAttr SunnyBoy Netzstrom_Phase_L2: 0.00
2023-05-28 08:05:45 ModbusAttr SunnyBoy DISCONNECTED
2023-05-28 08:05:46 ModbusAttr SunnyBoy CONNECTED

Ich sehe aber auch, dass pro Abfrage eines Wertes des SunnyBoys hier sogar ein reconnect erfolgt, ansonsten scheint er im opened Status zu bleiben.

Anbei mal mein Device... lief bisher einwandfrei...

Internals:
  DEF        3  30  192.168.178.7:502  TCP
  DevIoJustClosed 1
  DeviceName 192.168.178.7:502
  EXPECT    idle
  FUUID      608005a6-f33f-0804-ef70-a711145ff3715ef4
  IODev      SunnyBoy
  Interval  30
  LASTOPEN  1685253194.75924
  LeadingZeros 1
  MODBUSID  3
  MODE      master
  MODULEVERSION Modbus 4.4.14 - 30.1.2023
  NAME      SunnyBoy
  NOTIFYDEV  global
  NR        596
  NTFY_ORDER 50-SunnyBoy
  PROTOCOL  TCP
  STATE      disconnected
  TCPConn    1
  TYPE      ModbusAttr
  devioLoglevel 3
  eventCount 271355
  nextOpenDelay 60
  nextQueueRun 1685253195.81792
  OLDREADINGS:
  QUEUE:
    HASH(0x7febf80)
    HASH(0x806f2c0)
    HASH(0x7f90f98)
    HASH(0x8019c30)
    HASH(0x8008058)
  READ:
    BUFFER   
  READINGS:
    2023-05-28 07:06:38  DC_Leistung_Eingang 159.00
    2023-05-28 07:07:59  DC_Spannung_Eingang 210.21
    2023-05-28 07:08:35  DC_Strom_Eingang 0.77
    2023-05-28 07:06:34  Gesamtertrag    8025288
    2023-05-28 07:06:41  Nennfrequenz    49.99
    2021-04-23 08:09:54  Nennleistung_im_Zustand_Ok 2500
    2023-05-28 07:08:00  Netzspannung_Phase_L2 225.21
    2023-05-28 07:06:44  Netzstrom_Phase_L2 0.69
    2023-05-28 07:09:07  Status          OK
    2023-05-28 07:07:22  Tagesertrag    0.137
    2023-05-28 07:08:01  Temperatur      21
    2023-05-28 07:08:34  Wirkleistung_Begrenzung 2500
    2023-05-28 07:08:37  Wirkleistung_Max 2500
    2023-05-28 07:08:36  Wirkleistung_Phase_L2 147
    2023-05-28 07:53:14  state          disconnected
  REMEMBER:
    lid        3
    lname      SunnyBoy
    lrecv      1685253194.79929
    lsend      1685253194.77371
  defptr:
    SunnyBoy  3
  gotReadings:
  helper:
    _98_statistics EnergieManagement
  lastRead:
Attributes:
  alias      SunnyBoy
  dev-h-defExpr $val & 0x1FFFFFFF
  dev-h-defIgnoreExpr ( ( $val==536870911 ) || ( $val==2147483648 ) || ( $val==4294967295 ) || ( $val==65535 ) || ( $val==15498 ))
  dev-h-defLen 2
  dev-h-defPoll 1
  dev-h-defUnpack N
  obj-h30201-map 35:Fehler, 303:Aus, 307:OK, 455:Warnung
  obj-h30201-reading Status
  obj-h30233-reading Wirkleistung_Begrenzung
  obj-h30529-reading Gesamtertrag
  obj-h30535-expr $val/1000
  obj-h30535-format %.3f
  obj-h30535-reading Tagesertrag
  obj-h30769-expr ($val)/1000
  obj-h30769-format %.2f
  obj-h30769-reading DC_Strom_Eingang
  obj-h30771-expr ($val)/100
  obj-h30771-format %.2f
  obj-h30771-reading DC_Spannung_Eingang
  obj-h30773-format %.2f
  obj-h30773-reading DC_Leistung_Eingang
  obj-h30775-reading Wirkleistung_Phase_L2
  obj-h30785-expr $val/100
  obj-h30785-format %.2f
  obj-h30785-reading Netzspannung_Phase_L2
  obj-h30803-expr ($val  & 0x13FF) / 100
  obj-h30803-format %2.2f
  obj-h30803-reading Nennfrequenz
  obj-h30837-reading Wirkleistung_Max
  obj-h30953-expr ($val  & 0xFFFF) / 10
  obj-h30953-format %.0f
  obj-h30953-reading Temperatur
  obj-h30979-expr ($val & 0x7FFF) /1000
  obj-h30979-format %.2f
  obj-h30979-reading Netzstrom_Phase_L2
  room      ENERGIE,HWR
  stateFormat Status
<br>
Tagesertrag kw/h Momentanertrag DC_Leistung_Eingang

  verbose    5


Update:
Hier habe ich grad das gleiche Problem gefunden:
https://forum.fhem.de/index.php?topic=123012.0
Aber alles Löschen als Lösung ...
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Juni 2023, 10:00:30
Hallo holle75,

wenn Du die Länge von i1 auf 4 setzt, dann wird das ein einziges Reading. Statt dessen musst Du mit obj-i1-group arbeiten (siehe https://forum.fhem.de/index.php?topic=75638.msg1129957#msg1129957)

if / then geht innerhalb des Moduls nicht. Das muss Fhem machen. Z.B. aus einem doif ein get auf ein Modbus-Objekt ...

Gruß   
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 02 Juni 2023, 10:07:24
Hallo fireball,

device löschen und neu anlegen erscheint mir nicht überzeugend als Lösung.
Es wäre schön zu verstehen, wer die Verbindung ständig schließt. Wenn das der Wechselrichter ist, dann kannst Du mit  closeAfterResponse verhindern, dass Fhem die Verbindung sofort wieder neu aufmacht.
Hilfreich wäre ein Auszug aus dem Log bei verbose 5.

Gruß
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: stobor am 02 Juni 2023, 13:28:31
Hallo,

ich habe gerade einen Eastron SDM630-Modbus V2 Energiezähler über ein USB-zu-RS482/ModBus Adapter (DSD TECH SH-U11H) in Betrieb genommen.
Die Verbidnung (ca. 2m Kabellänge) ist beidseitig mit 120ohm terminiert.

Meine derzeitige (minimale) Konfiguration in der fhem.cfg sieht so aus:
define ModBusUSBAdapter Modbus /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0@9600
setuuid ModBusUSBAdapter 6479081c-f33f-2cfb-4355-7c2c3d9340c8fada
attr ModBusUSBAdapter room ModBus

define HA_SDM630M_1 ModbusSDM630M 2 60
setuuid HA_SDM630M_1 6479081c-f33f-2cfb-cb6f-8dd2c90129580e77
attr HA_SDM630M_1 userattr IODev
attr HA_SDM630M_1 IODev ModBusUSBAdapter
attr HA_SDM630M_1 room ModBus

Zunächst bin ich überrascht, dass ich keinerlei weitere Parameter bzgl. der Verbindung angeben musste (Stopp-Bit, Parität, ...). Das wurde anscheinend automatisch ausgehandelt/ vom SDM übernommen.

Im Log finde ich derzeit (nur) das:
2023.06.02 07:57:39 3: HA_SDM630M_1: RegisterAtIODev called from SetIODev registers HA_SDM630M_1 at ModBusUSBAdapter with id 2, MODE master, PROTOCOL RTU
2023.06.02 07:57:39 3: HA_SDM630M_1: Notify / Init: using ModBusUSBAdapter for communication
2023.06.02 07:57:39 3: Opening ModBusUSBAdapter device /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0
2023.06.02 07:57:39 3: Setting ModBusUSBAdapter serial parameters to 9600,8,N,1
2023.06.02 07:57:39 3: ModBusUSBAdapter device opened

Ca 40min nach dem FHEM Neustart kommt dann auch das hier:
...
2023.06.02 16:34:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:34:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:06 3: delete PIR_CP_aus : Please define PIR_CP_aus first
2023.06.02 16:36:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i46, len 40, master device HA_SDM630M_1, reading Current_Avr__A (getUpdate for combined i46 len 2 Current_Avr__A with i48 len 2 Current_Sum__A and i52 len 2 Power_Sum__W and i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:29 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i224, len 2, master device HA_SDM630M_1, reading Current_N__A (getUpdate for Current_N__A len 2), queued 6.01 secs ago, sent 2.00 secs ago
2023.06.02 16:36:40 3: FS20 set Bewegungsmelder_Sued_West off
2023.06.02 16:37:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
...

Trotzdem werden mir schon die Readings angezeigt - siehe Screenshot anbei. Diese aktualisieren sich aber nach einiger Zeit nur noch sporadisch - vielleicht alle 40min-1h.

Leider werden die Readings nicht dauerhaft verlässlich und zeitnah aktualisiert. Was muss ich tun, damit diese immer aktuell sind?


Vielen Dank für eure Hilfe.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 08 Juni 2023, 10:07:02
Zitat von: StefanStrobel am 02 Juni 2023, 10:00:30wenn Du die Länge von i1 auf 4 setzt, dann wird das ein einziges Reading. Statt dessen musst Du mit obj-i1-group arbeiten (siehe https://forum.fhem.de/index.php?topic=75638.msg1129957#msg1129957)

Vielen Dank Stefan! Das wars.

Wer einen Studer Gateway abfragen möchte:
define Studer485_Gateway ModbusAttr 33 55
attr Studer485_Gateway dev-defPoll 1
attr Studer485_Gateway dev-defUnpack n
attr Studer485_Gateway dev-i-read 4
attr Studer485_Gateway dev-timing-timeout 1
attr Studer485_Gateway group Xtender
attr Studer485_Gateway obj-i0-len 1
attr Studer485_Gateway obj-i0-reading Message_Count_must_read_first
attr Studer485_Gateway obj-i1-group 1-1
attr Studer485_Gateway obj-i1-len 1
attr Studer485_Gateway obj-i1-map 11:XTM,21:VT,61:BSP
attr Studer485_Gateway obj-i1-reading Last_Message_Device
attr Studer485_Gateway obj-i2-group 1-2
attr Studer485_Gateway obj-i2-len 1
attr Studer485_Gateway obj-i2-map 0:Warning (000) - Battery too low,1:Warning (001) - Battery too high,2:Warning (002) - Bulk charge too long,3:(003) - AC-In synchronization in progress,4:Warning (004) - Input frequency AC-In wrong,5:Warning (005) - Input frequency AC-In wrong,6:Warning (006) - Input voltage AC-In too high,7:Warning (007) - Input voltage AC-In too low,8:Halted (008) - Inverter overload SC,9:Halted (009) - Charger short circuit,10:(010) - System start-up in progress,11:Warning (011) - AC-In Energy quota,12:(012) - Use of battery temperature sensor,13:(013) - Use of additional remote control,14:Halted (014) - Over temperature EL,15:Halted (015) - Inverter overload BL,16:Warning (016) - Fan error detected,17:(017) - Programing mode,18:Warning (018) - Excessive battery voltage ripple,19:Halted (019) - Battery undervoltage,20:Halted (020) - Battery overvoltage,21:(021) - Transfer not authorized, AC-Out current is higher than {1107},22:Halted (022) - Voltage presence on AC-Out,23:Halted (023) - Phase not defined,24:Warning (024) - Change the clock battery,25:Halted (025) - Unknown Command board. Software upgrade needed,26:Halted (026) - Unknown Power board. Software upgrade needed,27:Halted (027) - Unknown extension board. Software upgrade needed,28:Halted (028) - Voltage incompatibility Power - Command,29:Halted (029) - Voltage incompatibility Ext. - Command,30:Halted (030) - Power incompatibility Power - Command,31:Halted (031) - Command board software incompatibility,32:Halted (032) - Power board software incompatibility,33:Halted (033) - Extension board software incompatibility,34:Halted (034) - FID corruption, call factory,35:(035) - Memory structure modified,36:Halted (036) - Parameter file lacking,37:Warning (037) - Message file lack. SW upgrade advised,38:Warning (038) - Upgrade of the device software advised,39:Warning (039) - Upgrade of the device software advised,40:Warning (040) - Upgrade of the device software advised,41:Warning (041) - Over temperature TR,42:Halted (042) - Unauthorized energy source at the output,43:(043) - Start of monthly test,44:(044) - End of successfully monthly test,45:Warning (045) - Monthly autonomy test failed,46:(046) - Start of weekly test,47:(047) - End of successfully weekly test,48:Warning (048) - Weekly autonomy test failed,49:(049) - Transfer opened because AC-In max current exceeded {1107},50:Error (050) - Incomplete data transfer,51:(051) - The update is finished,52:(052) - Your installation is already updated,53:Halted (053) - Devices not compatible, software update required,54:(054) - Please wait. Data transfer in progress,55:Error (055) - No SD card inserted,56:Warning (056) - Upgrade of the RCC software advised,57:(057) - Operation finished successfully,58:Halted (058) - Master synchronization missing,59:Halted (059) - Inverter overload HW,60:Warning (060) - Time security 1512 AUX1,61:Warning (061) - Time security 1513 AUX2,62:Warning (062) - Genset, no AC-In coming after AUX command,63:(063) - Save parameter XT,64:(064) - Save parameter BSP,65:(065) - Save parameter VarioTrack,71:Error (071) - Insufficient disk space on SD card,72:Halted (072) - COM identification incorrect,73:(073) - Datalogger is enabled on this RCC,74:(074) - Save parameter Xcom-MS,75:(075) - MPPT MS address changed successfully,76:Error (076) - Error during change of MPPT MS address,77:Error (077) - Wrong MPPT MS DIP Switch position,78:(078) - SMS or email sent,79:Halted (079) - More than 9 XTs in the system,80:Halted (080) - No battery (or reverse polarity),81:Warning (081) - Earthing fault,82:Halted (082) - PV overvoltage,83:Warning (083) - No solar production in the last 48h,84:(084) - Equalization performed,85:Error (085) - Modem not available,86:Error (086) - Incorrect PIN code, unable to initiate the modem,87:Error (087) - Insufficient Signal from GSM modem,88:Error (088) - No connection to GSM network,89:Error (089) - No Xcom server access,90:(090) - Xcom server connected,91:Warning (091) - Update finished. Update software of other RCC/Xcom-232i,92:Error (092) - More than 4 RCC or Xcom in the system,93:Error (093) - More than 1 BSP in the system,94:Error (094) - More than 1 Xcom-MS in the system,95:Error (095) - More than 15 VarioTrack in the system,121:Error (121) - Impossible communication with target device,122:Error (122) - SD card corrupted,123:Error (123) - SD card not formatted,124:Error (124) - SD card not compatible,125:Error (125) - SD card format not recognized. Should be FAT,126:Error (126) - SD card write protected,127:Error (127) - SD card, file(s) corrupted,128:Error (128) - SD card file or directory could not be found,129:Error (129) - SD card has been prematurely removed,130:Error (130) - Update directory is empty,131:(131) - The VarioTrack is configured for 12V batteries,132:(132) - The VarioTrack is configured for 24V batteries,133:(133) - The VarioTrack is configured for 48V batteries,134:(134) - Reception level of the GSM signal,137:(137) - VarioTrack master synchronization lost,138:Error (138) - XT master synchronization lost,139:(139) - Synchronized on VarioTrack master,140:(140) - Synchronized on XT master,141:Error (141) - More than 1 Xcom-SMS in the system,142:Error (142) - More than 15 VarioString in the system,143:(143) - Save parameter Xcom-SMS,144:(144) - Save parameter VarioString,145:Error (145) - SIM card blocked, PUK code required,146:Error (146) - SIM card missing,147:Error (147) - Install R532 firmware release prior to install an older release,148:(148) - Datalogger function interrupted (SD card removed),149:Error (149) - Parameter setting incomplete,150:Error (150) - Cabling error between PV and VarioString,162:Error (162) - Communication loss with RCC or Xcom-232i,163:Error (163) - Communication loss with Xtender,164:Error (164) - Communication loss with BSP,165:Error (165) - Communication loss with Xcom-MS,166:Error (166) - Communication loss with VarioTrack,167:Error (167) - Communication loss with VarioString,168:(168) - Synchronized with VarioString master,169:(169) - Synchronization with VarioString master lost,170:Warning (170) - No solar production in the last 48h on PV1,171:Warning (171) - No solar production in the last 48h on PV2,172:Error (172) - FID change impossible. More than one unit.,173:Error (173) - Incompatible Xtender. Please contact Studer Innotec SA,174:(174) - Inaccessible parameter, managed by the Xcom-CAN,175:Halted (175) - Critical undervoltage,176:(176) - Calibration setting lost,177:(177) - An Xtender has started up,178:(178) - No BSP. Necessary for programming with SOC,179:(179) - No BTS or BSP. Necessary for programming with temperature,180:(180) - Command entry activated,181:Error (181) - Disconnection of BTS,182:(182) - BTS/BSP battery temperature measurement used by a device,183:Halted (183) - An Xtender has lost communication with the system,184:Error (184) - Check phase orientation or circuit breakers state on AC-In,185:Warning (185) - AC-In voltage level with delay too low,186:Halted (186) - Critical undervoltage (fast),187:Halted (187) - Critical overvoltage (fast),188:(188) - CAN stage startup,189:Error (189) - Incompatible configuration file,190:(190) - The Xcom-SMS is busy,191:(191) - Parameter not supported,192:(192) - Unknown reference,193:(193) - Invalid value,194:(194) - Value too low,195:(195) - Value too high,196:(196) - Writing error,197:(197) - Reading error,198:(198) - User level insufficient,199:(199) - No data for the report,200:Error (200) - Memory full,202:Warning (202) - Battery alarm arrives,203:(203) - Battery alarm leaves,204:Error (204) - Battery stop arrives,205:(205) - Battery stop leaves,206:Halted (206) - Board hardware incompatibility,207:(207) - AUX1 relay activation,208:(208) - AUX1 relay deactivation,209:(209) - AUX2 relay activation,210:(210) - AUX2 relay deactivation,211:(211) - Command entry deactivated,212:Error (212) - VarioTrack software incompatibility. Upgrade needed,213:(213) - Battery current limitation by the BSP stopped,214:Warning (214) - Half period RMS voltage limit exceeded, transfer opened,215:Warning (215) - UPS limit reached, transfer opened,216:Warning (216) - Scom watchdog caused the reset of Xcom-232i,217:Warning (217) - CAN problem at Xtender declaration,218:Warning (218) - CAN problem while writing parameters,222:(222) - Front ON/OFF button pressed,223:(223) - Main OFF detected,224:(224) - Delay before closing transfer relay in progress {1580},225:Error (225) - Communication with lithium battery lost,226:(226) - Communication with lithium battery restored,227:Error (227) - Overload on high voltage DC side,228:Error (228) - Startup error,229:Error (229) - Short-circuit on high voltage DC side
attr Studer485_Gateway obj-i2-reading Last_Message_Info
attr Studer485_Gateway obj-i3-group 1-3
attr Studer485_Gateway obj-i3-len 1
attr Studer485_Gateway obj-i3-reading Last_Message_ignore1
attr Studer485_Gateway obj-i4-group 1-4
attr Studer485_Gateway obj-i4-len 1
attr Studer485_Gateway obj-i4-reading Last_Message_ignore2


Edit: Mmh, nachdem ich jetzt freudig alle Messages ausgelesen habe (die jeweils danach gelöscht werden), ist mir die zweite Herausforderung (die ich verdrängt hatte) wieder bewußt geworden. Das Kästchen schmiert noch immer ab, wenn es keine Messages hat und ich sie trotzdem auslese. Ich werde mich mal mit deiner Empfehlung auseinandersetzen.

"if / then geht innerhalb des Moduls nicht. Das muss Fhem machen. Z.B. aus einem doif ein get auf ein Modbus-Objekt ..."

Stefan, könntest du hierzu ein ganz klein wenig elaborieren? get auf Modbus-Objekt klickt bei mir nicht ganz, resp. wie ich das getrennt bekomme.

- Abfrage wie jetzt auch, aber nur auf Anzahl Messages
- Anzahl 0 -> nichts tun
- Anzahl größer 0 -> DOIF triggern
- Aber wie dann im DOIF ein anderes Modbus-Device abfragen, was ansonsten nicht aktiv ist?

weitergedacht, allgemein poll aus und nur Message_Count regelmäßig abfragen. .....
- aber, da ich ja in einem Durchlauf immer erst Message_Count abfragen muss und danach erst die Message, wie kombiniere ich das in einem DOIF mit gets?
- erschwerend kommt hinzu, dass Message_Count, wenn leer, nicht brav 0 sondern 65535 liefert. Aber immerhin konstant und entspricht somit 0 .... und das Kästchen schmiert nicht ab wenn ich nur diesen Wert polle.

noch mehr weitergedacht. Vielleicht meint Studer mit ihrer Definition "must read first" nur, dass man eben Messages nur auslesen soll, wenn es welche gibt und gar nix von im selben Auslesevorgang oä ?! Also so hatte ich Trottel das verstanden.
kann ich ein get auf eine group absetzen? get Studer485_Gateway group 1

probiert, geht nicht (wär mal noch eine Idee)
wie kombiniere ich die gets im DOIF ?

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Juni 2023, 20:38:27
Hallo holle75,

get auf groups ist bisher nicht implementiert, aber das ist eine sinnvolle Erweiterung. Das baue ich demnächst mal ein.
Bis dahin könntest Du folgendes machen:

wenn das Intervall beim define 0 ist, dann wird nicht automatisch gelesen, sondern bei einem set Studer485_Gateway reread.
Somit kannst Du über ein at regelmäßig per get Studer485_Gateway Message_Count_must_read_first prüfen, ob es was zu lesen gibt und dann per doif ein set reread auslösen.

Gruss
  Stefan


Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Juni 2023, 20:44:05
Hallo stobor,

Zitat von: stobor am 02 Juni 2023, 13:28:31Zunächst bin ich überrascht, dass ich keinerlei weitere Parameter bzgl. der Verbindung angeben musste (Stopp-Bit, Parität, ...). Das wurde anscheinend automatisch ausgehandelt/ vom SDM übernommen.
Nein, das wird nicht ausgehandelt sondern der Default ist 8N1
ZitatCa 40min nach dem FHEM Neustart kommt dann auch das hier:
...
2023.06.02 16:34:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:34:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:06 3: delete PIR_CP_aus : Please define PIR_CP_aus first
2023.06.02 16:36:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i46, len 40, master device HA_SDM630M_1, reading Current_Avr__A (getUpdate for combined i46 len 2 Current_Avr__A with i48 len 2 Current_Sum__A and i52 len 2 Power_Sum__W and i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:29 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i224, len 2, master device HA_SDM630M_1, reading Current_N__A (getUpdate for Current_N__A len 2), queued 6.01 secs ago, sent 2.00 secs ago
2023.06.02 16:36:40 3: FS20 set Bewegungsmelder_Sued_West off
2023.06.02 16:37:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
...

Trotzdem werden mir schon die Readings angezeigt - siehe Screenshot anbei. Diese aktualisieren sich aber nach einiger Zeit nur noch sporadisch - vielleicht alle 40min-1h.
Leider werden die Readings nicht dauerhaft verlässlich und zeitnah aktualisiert. Was muss ich tun, damit diese immer aktuell sind?

Die Timeouts deuten auf Übertragungsfehler hin.
Evt. ist schon eine Terminierung eingebaut und doppelt terminiert kann Probleme verursachen. Oder mit dem Kabel stimmt was nicht.

Gruss
  Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 13 Juni 2023, 23:26:50
Danke Stefan, kleiner Ausflug zu "get". Habe jetzt das gebaut

define Studer485_Gateway_Trigger_AT at +*00:00:55 get Studer485_Gateway Message_Count_must_read_first
attr Studer485_Gateway_Trigger_AT group Xtender

define Studer485_Gateway_Trigger_DOIF DOIF ([Studer485_Gateway:Message_Count_must_read_first] > 0 and [Studer485_Gateway:Message_Count_must_read_first] < 129) (set Studer485_Gateway reread)
attr Studer485_Gateway_Trigger_DOIF do always
attr Studer485_Gateway_Trigger_DOIF group Xtender

allerdings wirft mir das at keinen Event?? Get seltenst benutzt (ist das nicht blocking?) und auch das Forum gibt wenig Info.
Manuell gibt mir das get aus dem at ein Popup, aber auch keinen Event

Intervall und Poll habe ich so verändert:

defmod Studer485_Gateway ModbusAttr 33 0
attr Studer485_Gateway dev-defPoll 1
attr Studer485_Gateway dev-defUnpack n
attr Studer485_Gateway dev-i-read 4
attr Studer485_Gateway dev-timing-timeout 1
attr Studer485_Gateway event-on-change-reading .*
attr Studer485_Gateway group Xtender
attr Studer485_Gateway obj-i0-len 1
attr Studer485_Gateway obj-i0-reading Message_Count_must_read_first
attr Studer485_Gateway obj-i1-group 1-1
attr Studer485_Gateway obj-i1-len 1
attr Studer485_Gateway obj-i1-map 11:XTM,21:VT,61:BSP
attr Studer485_Gateway obj-i1-reading Last_Message_Device
attr Studer485_Gateway obj-i2-group 1-2
attr Studer485_Gateway obj-i2-len 1
attr Studer485_Gateway obj-i2-reading Last_Message_Info
attr Studer485_Gateway obj-i3-group 1-3
attr Studer485_Gateway obj-i3-len 1
attr Studer485_Gateway obj-i3-reading Last_Message_ignore1
attr Studer485_Gateway obj-i4-group 1-4
attr Studer485_Gateway obj-i4-len 1
attr Studer485_Gateway obj-i4-reading Last_Message_ignore2

was mache ich falsch?

Edit: oh, stattdessen bekomme ich jetzt alle 55 Sekunden einen fhem logeintrag ;) ... ok, at auch nur seltenst genutzt. Muss mich wohl mal mit at schlau machen.
Edit2: DOIF gebaut, nicht wirklich erfolgreich. get scheint nicht mein Freund zu sein.
#define Studer485_Gateway_Trigger_Timer_DOIF DOIF {[00:00-23:59,+00:00:55];;fhem_set"get Studer485_Gateway Message_Count_must_read_first"}

#define Studer485_Gateway_Trigger_Timer_DOIF DOIF ([00:00-23:59,+00:00:55])(get Studer485_Gateway Message_Count_must_read_first)
Wie löst man fachgerecht ein get in fhem aus?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 14 Juni 2023, 11:39:43
Ha, das DOIF wirft errors, aber das AT funktioniert plötzlich ... sehr seltsam

Allerdings würde ich dem AT gerne sagen, dass es NICHT ins fhem log jedes Ergebnis schreibt. Wie lässt sich das vermeiden?

die Kombo funktioniert
define Studer485_Gateway_Trigger_AT at +*00:00:55 get Studer485_Gateway Message_Count_must_read_first

define Studer485_Gateway_Trigger_DOIF DOIF ([Studer485_Gateway:Message_Count_must_read_first] > 0 and [Studer485_Gateway:Message_Count_must_read_first] < 129) (set Studer485_Gateway reread)
attr Studer485_Gateway_Trigger_DOIF do always

aber schreibt mir ins fhem log jede Ausführungsschleife des AT. Warum macht das AT das?

fhem.log
2023.06.14 11:43:29 3: Studer485_Gateway_Trigger_AT: 66
2023.06.14 11:44:24 3: Studer485_Gateway_Trigger_AT: 65
2023.06.14 11:45:19 3: Studer485_Gateway_Trigger_AT: 64
2023.06.14 11:46:14 3: Studer485_Gateway_Trigger_AT: 63
2023.06.14 11:47:09 3: Studer485_Gateway_Trigger_AT: 62
2023.06.14 11:48:04 3: Studer485_Gateway_Trigger_AT: 61

EDIT: ja klar, verbose 2 ..... war mir entfallen
AT gefällt mir irgendwie nicht, das DOIF wär mir lieber. Falls jemand weiss, warum meine obige Konfi (post davor) nicht funktioniert, lasst gerne wissen. Werde auch mal im DOIF-Bereich nachhaken.
UND, falls jemand etwas zu get ist blocking oder nicht sagen kann, wär ich auch recht dankbar.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: stobor am 14 Juni 2023, 13:39:48
Zitat von: StefanStrobel am 13 Juni 2023, 20:44:05Hallo stobor,

Zitat von: stobor am 02 Juni 2023, 13:28:31Zunächst bin ich überrascht, dass ich keinerlei weitere Parameter bzgl. der Verbindung angeben musste (Stopp-Bit, Parität, ...). Das wurde anscheinend automatisch ausgehandelt/ vom SDM übernommen.
Nein, das wird nicht ausgehandelt sondern der Default ist 8N1
ZitatCa 40min nach dem FHEM Neustart kommt dann auch das hier:
...
2023.06.02 16:34:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:34:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:06 3: delete PIR_CP_aus : Please define PIR_CP_aus first
2023.06.02 16:36:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i46, len 40, master device HA_SDM630M_1, reading Current_Avr__A (getUpdate for combined i46 len 2 Current_Avr__A with i48 len 2 Current_Sum__A and i52 len 2 Power_Sum__W and i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:29 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i224, len 2, master device HA_SDM630M_1, reading Current_N__A (getUpdate for Current_N__A len 2), queued 6.01 secs ago, sent 2.00 secs ago
2023.06.02 16:36:40 3: FS20 set Bewegungsmelder_Sued_West off
2023.06.02 16:37:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
...

Trotzdem werden mir schon die Readings angezeigt - siehe Screenshot anbei. Diese aktualisieren sich aber nach einiger Zeit nur noch sporadisch - vielleicht alle 40min-1h.
Leider werden die Readings nicht dauerhaft verlässlich und zeitnah aktualisiert. Was muss ich tun, damit diese immer aktuell sind?

Die Timeouts deuten auf Übertragungsfehler hin.
Evt. ist schon eine Terminierung eingebaut und doppelt terminiert kann Probleme verursachen. Oder mit dem Kabel stimmt was nicht.

Gruss
  Stefan

Jetzt läuft es bei mir.
Ich habe Delays bei den Attributen definiert:
dev-timing-commDelay = 0.5
dev-timing-sendDelay = 0.5
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 15 Juni 2023, 21:18:15
Hi Stefan,
ich habe mal meine exclude_from_update für die Modbus-Module weggenommen und ein update gemacht.
Nun läuft die dev-fc.*-Erweiterung nicht mehr.
Hat es die Erweiterung noch nicht ins offizielle Modul geschafft?
Wann hat Du das geplant?

//Roger

[/quote]
Zitat von: StefanStrobel am 11 März 2023, 16:46:53Anbei eine neue Version des Moduls zum Testen bevor ich es einchecke und es per update verteilt wird.
Man kann nun custom function codes selbst definieren, das Loglevel wurde bei einigen Events von 3 auf 4 erhöht und ein par Bugs gefixt.
Zudem sind einige Data types vordefiniert, so dass man meist keinen unpack code und keine len mehr angeben muss und der data type reicht.
Ich hoffe es funktioniert noch alles :-)

Gruss
  Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Juni 2023, 16:35:58
Hallo Roger,

danke für die Erinnerung. Habe es gerade eingecheckt. Bisher gab es ja keine Problem-Meldungen zur neuen Version.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 23 Juni 2023, 16:37:43
Hallo holle75,

get ist bei ModbusAttr blocking, es sei denn man setzt das Attribut nonPrioritizedGet (hat in der Doku leider gefehlt, da war nur nonPrioritizedSet drin).

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 26 Juni 2023, 13:24:05
Zitat von: StefanStrobel am 23 Juni 2023, 16:35:58Hallo Roger,

danke für die Erinnerung. Habe es gerade eingecheckt. Bisher gab es ja keine Problem-Meldungen zur neuen Version.

Gruss
  Stefan
Hi Stefan,
habe neue Version eingespielt.

Bekomme (wie vorher manchmal auch):
Undefined subroutine &Modbus::HexIfNeeded called at 98_Modbus.pm line 2546

Was kann ich dagegen tun?
//Roger

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: m-d-ley am 29 Juni 2023, 13:25:29
Hallo, ich habe das Problem, dass ich einige Werte aus einem Zähler nicht ausgelesen bekomme.
Es scheint alle Werte zu betreffen, welche über das M-Bus-Protokoll an das ModbusTCP-Gateway mit Dezimalkomma übertragen werden. Das Log eines Registers sieht folgendermaßen aus:
2023.06.29 12:45:55 4: Test: GetUpdate (V4.5.5 - 9.5.2023) called from ControlSet
2023.06.29 12:45:55 5: Test: CreateUpdateHash full object list: h1560
2023.06.29 12:45:55 5: Test: CreateUpdateHash will request h1560 len 4 l1_volts_unscaled_UV100_V2
2023.06.29 12:45:55 4: Test: CombineUpdateHash objHash keys before combine: h1560
2023.06.29 12:45:55 5: Test: CombineUpdateHash tries to combine read commands
2023.06.29 12:45:55 5: Test: CombineUpdateHash keys are now h1560
2023.06.29 12:45:55 4: Test: GetUpdate will now create requests for h1560 len 4 (l1_volts_unscaled_UV100_V2)
2023.06.29 12:45:55 4: Test: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 10, read fc 3 h1560, len 4, tid 68, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 4)
2023.06.29 12:45:55 5: Test: QueueRequest called from DoRequest with h1560, qlen 0 from master Test through io device Test
2023.06.29 12:45:55 5: Test: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2023.06.29 12:45:55 5: Test: ProcessRequestQueue called from Fhem internal timer as queue:Test, qlen 1, request: request: id 10, read fc 3 h1560, len 4, tid 68, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 4), queued 0.00 secs ago
2023.06.29 12:45:55 5: Test: checkDelays sendDelay, last send to same device was 57.226 secs ago, required delay is 0.1
2023.06.29 12:45:55 5: Test: checkDelays commDelay, last communication with same device was 57.191 secs ago, required delay is 0.1
2023.06.29 12:45:55 5: Test: checkDelays clientSwitchDelay is not relevant
2023.06.29 12:45:55 5: Test: checkDelays busDelayRead is not required
2023.06.29 12:45:55 4: Test: ProcessRequestQueue (V4.5.5 - 9.5.2023) qlen 1, sending 0044000000060a0306180004 via 172.21.96.60:502, read buffer empty,
request: id 10, read fc 3 h1560, len 4, tid 68, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 4), queued 0.00 secs ago
2023.06.29 12:45:55 5: Test: Send called from ProcessRequestQueue
2023.06.29 12:45:55 5: DevIo_SimpleWrite Test: 0044000000060a0306180004
2023.06.29 12:45:55 5: Test: readFn buffer: 00440000000b0a03080000000000000000 mode master, expect response
2023.06.29 12:45:55 5: Test: ParseFrameStart called from ReadFn protocol TCP expecting id 10
2023.06.29 12:45:55 4: Test: ParseFrameStart (TCP, master) extracted id 10, fCode 3, tid 68, dlen 11 and potential data 080000000000000000
2023.06.29 12:45:55 5: Test: HandleResponse called from ReadFn
2023.06.29 12:45:55 5: Test: HandleResponse is now creating response hash, masterHash is HASH(0x55cb0caac600)
2023.06.29 12:45:55 5: Test: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55cb0caac600)
2023.06.29 12:45:55 5: Test: ParseResponse called from HandleResponse, fc 3
2023.06.29 12:45:55 5: Test: now parsing response data objects, master is Test relay is undefined
2023.06.29 12:45:55 5: Test: ParseDataString called from HandleResponse with data hex 0000000000000000, type h, adr 1560, op read
2023.06.29 12:45:55 5: Test: SplitDataString called from ParseDataString with data hex 0000000000000000, type h, adr 1560, valuesLen 4, op read
2023.06.29 12:45:55 5: Test: CreateDataObjects called from ParseDataString with objList h1560
2023.06.29 12:45:55 5: Test: CreateDataObjects sortedList h1560
2023.06.29 12:45:55 5: Test: CreateParseInfoCache called
2023.06.29 12:45:55 5: Test: CreateDataObjects unpacked 0000000000000000 with q> to 0
2023.06.29 12:45:55 4: Test: CreateDataObjects assigns value 0 to l1_volts_unscaled_UV100_V2
2023.06.29 12:45:55 5: Test: ParseDataString created 1 readings, errcode undef
2023.06.29 12:45:55 4: Test: HandleResponse done, current frame / read buffer: 00440000000b0a03080000000000000000, id 10, fCode 3, tid 68,
request: id 10, read fc 3 h1560, len 4, tid 68, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 4), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 10, fc 3, h1560, len 4, values 0000000000000000
2023.06.29 12:45:55 5: Test: ResetExpect for HandleResponse from response to idle
2023.06.29 12:45:55 5: Test: DropFrame called from ReadFn - drop 00440000000b0a03080000000000000000
2023.06.29 12:45:55 5: Test: readFn end buffer:  mode master, expect idle

Habt ihr einen Tip?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Juni 2023, 17:31:40
Hallo Roger,

gleicher Fehler wie beim letzten Mal. Die utils müssen auch aktualisiert werden. Ich hab sie zusammen mit einem Update von HTTPMOD jetzt auch eingecheckt.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 29 Juni 2023, 17:35:36
Hallo m-d-ley,

Zitat2023.06.29 12:45:55 5: Test: CreateUpdateHash full object list: h1560
...
2023.06.29 12:45:55 5: Test: CreateDataObjects unpacked 0000000000000000 with q> to 0
2023.06.29 12:45:55 4: Test: CreateDataObjects assigns value 0 to l1_volts_unscaled_UV100_V2

es wird nur dieses eine Reading abgefragt und das hat den Wert 0.
Was fehlt denn? Wie sieht denn die Konfiguration aus?

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Roger am 29 Juni 2023, 21:49:01
Zitat von: StefanStrobel am 29 Juni 2023, 17:31:40Hallo Roger,

gleicher Fehler wie beim letzten Mal. Die utils müssen auch aktualisiert werden. Ich hab sie zusammen mit einem Update von HTTPMOD jetzt auch eingecheckt.

Gruss
  Stefan
Danke  :) , soeben eingespielt.
//Roger
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: m-d-ley am 30 Juni 2023, 09:33:58
Das Reading sollte eigentlich die Spannung darstellen. Der Wert soll bei ~230V liegen. Allerdings wird er als kommagetrennte Dezimalzahl als Float32 schon im M-Bus übertragen. Ich vermute, dass das Modbbusattr den Wert aufgrund des Kommas verwirft. Alle Werte, welche kein Komma enthalten werden wunderbar ausgelesen. Ich lese mit dem Modul aktuell ca. 40 Zähler, zwei BHKWs und eine Druckluftanlage aus. Nun scheitere ich an einem Stromzähler von Siemens.

Anbei nochmal Bilder zur Config und den Werten im Gateway.

Vielen Dank für den Support.

https://ibb.co/zNLcW6v (https://ibb.co/zNLcW6v)

https://ibb.co/gwJy7rS (https://ibb.co/gwJy7rS)
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 30 Juni 2023, 14:48:14
Zitat von: m-d-ley am 30 Juni 2023, 09:33:58Das Reading sollte eigentlich die Spannung darstellen. Der Wert soll bei ~230V liegen. Allerdings wird er als kommagetrennte Dezimalzahl als Float32 schon im M-Bus übertragen. Ich vermute, dass das Modbbusattr den Wert aufgrund des Kommas verwirft.

laut Log kommt per Modbus nur 0 an:
Zitat2023.06.29 12:45:55 5: Test: readFn buffer: 00440000000b0a03080000000000000000 mode master
...
CreateDataObjects unpacked 0000000000000000 with q> to 0

welche Komponente macht denn die Umsetzung von MBus auf Modbus?

Gruss
  Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: m-d-ley am 30 Juni 2023, 20:41:54
Die Umsetzung wird durch ein Gateway von anybus erledigt:

https://www.anybus.com/de/produkte/gateway-index/specific-gateways/anybus-modbus-m-bus-gateway/anybus-m-bus-to-modbus-tcp-gateway (https://www.anybus.com/de/produkte/gateway-index/specific-gateways/anybus-modbus-m-bus-gateway/anybus-m-bus-to-modbus-tcp-gateway)


Ohne Einstellungen sieht der Log so aus:
2023.07.03 12:51:22 5: Test: Send called from ProcessRequestQueue
2023.07.03 12:51:22 5: DevIo_SimpleWrite Test: 002d000000060a0306180001
2023.07.03 12:51:22 5: Test: readFn buffer: 002d000000050a03020000 mode master, expect response
2023.07.03 12:51:22 5: Test: ParseFrameStart called from ReadFn protocol TCP expecting id 10
2023.07.03 12:51:22 4: Test: ParseFrameStart (TCP, master) extracted id 10, fCode 3, tid 45, dlen 5 and potential data 020000
2023.07.03 12:51:22 5: Test: HandleResponse called from ReadFn
2023.07.03 12:51:22 5: Test: HandleResponse is now creating response hash, masterHash is HASH(0x55cb0caac600)
2023.07.03 12:51:22 5: Test: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55cb0caac600)
2023.07.03 12:51:22 5: Test: createDevInfoCache fc 3 called
2023.07.03 12:51:22 5: Test: ParseResponse called from HandleResponse, fc 3
2023.07.03 12:51:22 5: Test: now parsing response data objects, master is Test relay is undefined
2023.07.03 12:51:22 5: Test: ParseDataString called from HandleResponse with data hex 0000, type h, adr 1560, op read
2023.07.03 12:51:22 5: Test: SplitDataString called from ParseDataString with data hex 0000, type h, adr 1560, valuesLen 1, op read
2023.07.03 12:51:22 5: Test: CreateDataObjects called from ParseDataString with objList h1560
2023.07.03 12:51:22 5: Test: CreateDataObjects sortedList h1560
2023.07.03 12:51:22 5: Test: CreateParseInfoCache called
2023.07.03 12:51:22 5: Test: CreateDataObjects unpacked 0000 with n to 0
2023.07.03 12:51:22 4: Test: CreateDataObjects assigns value 0 to l1_volts_unscaled_UV100_V2
2023.07.03 12:51:22 5: Test: ParseDataString created 1 readings, errcode undef
2023.07.03 12:51:22 4: Test: HandleResponse done, current frame / read buffer: 002d000000050a03020000, id 10, fCode 3, tid 45,
request: id 10, read fc 3 h1560, len 1, tid 45, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 1), queued 0.04 secs ago, sent 0.03 secs ago,
response: id 10, fc 3, h1560, len 1, values 0000
2023.07.03 12:51:22 5: Test: ResetExpect for HandleResponse from response to idle
2023.07.03 12:51:22 5: Test: DropFrame called from ReadFn - drop 002d000000050a03020000
2023.07.03 12:51:22 5: Test: readFn end buffer:  mode master, expect idle

Warum kommt am Ende ein DropFrame?

Gruß
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 Juli 2023, 21:05:59
Hallo,

Dein anybus-Gateway schickt offenbar 0.
DropFrame ist der Name der Funktion des Modbus-Moduls, die nach dem Verarbeiten eines Modbus-Frames (inkl. setzen der Readings) den Puffer wieder frei macht.
Das ist kein Fehler sondern der Abschluss der Verarbeitung.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: thomas.z am 13 Juli 2023, 11:23:14
Moin Gemeinde,
ich versuche meinen Wechselrichter (SMA STP-10.0 SE) per Modbus testweise zu steuern und habe ein Problem beim Schreiben von holding Registern im Format U32 und S32, weil ich mit den Optionen "revRegs" und "unpack" nicht wirklich zurechtkomme.

SMA spezifiziert:
Durch die Datenablage im Motorola-Format "Big-Endian" werden bei einer Datenübertragung erst das High-Byte und
dann das Low-Byte der Modbus-Register übertragen.

Meine Tests erfolgen z. Z. manuell über die FhemWeb mit der Set-Option für die Register.

Beispiel-Register:
attr stp obj-h40149-reading BatChargeMaxW
attr stp obj-h40149-type S32
attr stp obj-h40149-set 1
Verwende ich folgende Typdefinition:
attr stp dev-type-S32-format %d
attr stp dev-type-S32-len 2
attr stp dev-type-S32-unpack l>
attr stp dev-type-S32-revRegs 1
bekomme ich bei verbose=4, wenn ich den Wert "444" setze, folgendes im Log:
request: id 3, write fc 16 h40149, len 2, value 01bc0000, tid 243, master device stp, reading BatChargeMaxW (set BatChargeMaxW), queued 0.03 secs ago, sent 0.03 secs ago,
response: id 3, fc 16, c40149, len 2
444 entspricht 1bc in Hex, aber die Reihenfolge im "value" ist dann definitiv nicht big-endian.

Ändere ich die Typdefinition auf
attr stp dev-type-S32-format %d
attr stp dev-type-S32-len 2
attr stp dev-type-S32-unpack l>
- ohne revRegs, erscheint
request: id 3, write fc 16 h40149, len 2, value 000001bc, tid 80, master device stp, reading BatChargeMaxW (set BatChargeMaxW), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 3, fc 16, c40149, len 2
und der value ist aus meiner Sicht korrekt in big-endian gesetzt.

Das gleiche Problem hatte ich mit einem U32-Register:
attr stp obj-h40151-reading Kommunikation
attr stp obj-h40151-set 1
attr stp obj-h40151-type U32

Erst als ich mit dieser Typdefinition
attr stp dev-type-U32-format %u
attr stp dev-type-U32-len 2
attr stp dev-type-U32-unpack N
also ohne revRegs gearbeitet habe, konnte ich das Register tatsächlich korrekt (Wert 802) beschreiben:
request: id 3, write fc 16 h40151, len 2, value 00000322, tid 221, master device stp, reading Kommunikation (set Kommunikation),
Wenn ich jedoch ein 32bit RO Register auslesen will, benötige ich das revRegs, sonst funktioniert es nicht.
Registerbeispiel:
attr stp obj-i30771-reading DC-Spannung-A
attr stp obj-i30771-showGet 1
attr stp obj-i30771-type S32F2
und Typ
attr stp dev-type-S32F2-expr $val/100
attr stp dev-type-S32F2-format %.2f
attr stp dev-type-S32F2-len 2
attr stp dev-type-S32F2-revRegs 1

Das erscheint mir widersprüchlich und ich verstehe es nicht. Über eine erhellende Erklärung würde ich mich sehr freuen.

Danke und Gruß
Thomas
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Juli 2023, 12:53:14
Hallo Thomas,

kann es sein, dass Du bei dev-type-S32F2 den Unpack-Code 'N' vergessen hast und das Modul mangels eines anders definierten Default auf 'n' zurückfällt?
Dann würden nur die ersten 16 Bit vom unpack verwendet und durch revRegs schiebst Du zufällig den relevanten Bereich dahin ...
Hast Du https://forum.fhem.de/index.php?topic=103390.30 gesehen?

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: thomas.z am 13 Juli 2023, 13:21:12
Hallo Stefan,
danke für Deine schnelle Antwort! Durch einen Selektierfehler beim Copy der Typdefinition von S32F2 fehlte der Unpack-Code. Und der stand tatsächlich auf "n" und nicht auf "N" :). Das habe ich gerade korrigiert und getestet. Mit "N" bekam ich nur noch "Unfug" als Wert. Nach löschen des Attributes revRegs=1 war alles wieder o. K.

Da muss ich gestehen, dass ich offensichtlich den Verwendungszweck von "revRegs" völlig falsch verstanden habe. Bis jetzt habe ich angenommen, dass das immer für big-endian Bytefolge gemacht werden muss, damit beim get oder set die fhem- bzw. Perl-internen Variablen für Berechnungn als little-endian im Hauptspeicher landen, aber das ist ja offensichtlich nicht richtig. Hier muss ich mich noch ordentlich weiterbilden.

In welchen Fällen wäre revRegs dann einzusetzen? Die Sätze im Wiki ergeben nun keinen Hinweis mehr auf den möglichen Zweck.

Den Thread zum SMA-WR habe ich noch nicht gesehen bzw. gefunden. Ich habe nur nach modbusattr, signed integer etc. gesucht. Danke für den Link, den Thread werde ich mir jetzt mal zu Gemüte führen ... ;).

Danke nochmal und viele Grüße!
Thomas



Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Juli 2023, 19:29:06
Hallo Thomas,

Es gibt tatsächlich Geräte, bei denen unabhängig von der Byte-Order (big endian oder small endian) die Reihenfolge der Register  umgedreht ist. Ein String mit aufsteigenden Ziffern würde dann statt "123456" als "563412" dargestellt. Da Modbus hier keine Vorgaben macht, ist das alles von den Herstellern frei interpretierbar. Meine Wärmepumpensteuerung von Waterkotte macht das zum Beispiel so.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: thomas.z am 13 Juli 2023, 21:34:51
Hallo Stefan,
herzlichen Dank für Deine Erklärung. Auf die Idee, dass Hersteller einfach mal aus Jokus Register vertauschen, bin ich nicht gekommen, und habe revRegs einfach in die big-endian-Ecke positioniert. Mit etwas mehr Nachdenken hätte ich vielleicht drauf kommen können, dass bei big-endian ja nicht je 2x2 byte in umgekehrter Reihenfolge im Speicher stehen, sondern die 4 bytes insgesamt in umgekehrter Reihenfolge gespeichert sind.

Ich denke, nun habe ich's begriffen  ;) .

Gruß
Thomas
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: fireball am 15 Juli 2023, 19:14:55
Hi,

ich hab hier im Thread ein paar Suchtreffer gefunden, aber so richtig versteh ich die Hardware noch nicht.
Ich habe einen Stromzähler SDM72D-M V2 (https://www.eastroneurope.com/products/view/sdm72modbus) und der hat ja eine Modbusschnittstelle.

Meine Idee war, da ich schon einen WEMOS D1 mit Tasmota und mit optischem Lesekopf habe und damit meinen Hauszähler auslesen kann, dass ich einfach die Modbusschnittstelle hier noch von dem SDM72D mit auslese.
Tasmota unterstützt ja auch den SDM72D.

Versteh ich das aber richtig, ich kann nicht direkt die Modbus-Ausgänge an den Wemos hängen und kann die Werte auslesen?
Ich muss einen Modbus TTL Konverter (https://www.ebay.de/itm/255283295160?_trkparms=amclksrc%3DITM%26aid%3D777008%26algo%3DPERSONAL.TOPIC%26ao%3D1%26asc%3D20221115143057%26meid%3Dd75257737b554d5cacf22ef3f21fb1c9%26pid%3D101612%26rk%3D1%26rkt%3D1%26itm%3D255283295160%26pmt%3D1%26noa%3D1%26pg%3D4375194%26algv%3DRecentlyViewedItemsV2&_trksid=p4375194.c101612.m4236&_trkparms=parentrq%3A5a8b4bc01890a0d0042b3681ffff9ffe%7Cpageci%3Af4d01b1b-2332-11ee-a8ec-8ee5366ae3c3%7Ciid%3A1%7Cvlpname%3Avlp_homepage) dawischen hängen, richtig?!

Würde mich freuen, wenns kurz einer erklären kann?!
VG+Danke
René
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 16 Juli 2023, 12:17:11
Zitat von: StefanStrobel am 23 Juni 2023, 16:37:43Hallo holle75,

get ist bei ModbusAttr blocking, es sei denn man setzt das Attribut nonPrioritizedGet (hat in der Doku leider gefehlt, da war nur nonPrioritizedSet drin).

Gruss
  Stefan

vielen Dank!
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: CaptainHook am 18 Juli 2023, 13:00:59
Moin Zusammen,

ich versuche gerade das Modul 98_SolarEdge um die Funktion die Batterie bzw den Speicher zu steuern zu erweitern.

Aus der Sunspec von Solaredge:
Appendix C – Encoding and Decoding 32-bit Values in Modbus
In Modbus, 32-bit values span two registers. This appendix explains how to encode and decode these registers correctly.
Since 32-bit values span two registers, they must be written in a single transaction of Write Multiple Registers (Function code 10) and
not two consecutive Write Single Register (Function code 06) transactions.

In der Datei im SVN habe ich gesehen, das das Modul beim senden von Werten den Funktionscode 06 benutzt (%fcMap).
Gibt es eine Möglichkeit, zwei Register in einer Transaktion und mit Funktionscode 10 zu senden?

Viele Grüße,
Stephan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 22 Juli 2023, 09:49:12
Zitat von: fireball am 15 Juli 2023, 19:14:55Versteh ich das aber richtig, ich kann nicht direkt die Modbus-Ausgänge an den Wemos hängen und kann die Werte auslesen?

Hallo Rene,

Du müsstest einen RS485 auf RS232-Konverter haben oder Dein Wemos kann RS485 auf TTL-Level mit einem entsprechenden Konverter.
Dann bleibt aber noch die Frage, ob der Wemos dannn 1:1 das Modbus-RTU über Wifi / TCP hin und her schicken kann.

Gruss
  Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 August 2023, 00:06:48
Zitat von: CaptainHook am 18 Juli 2023, 13:00:59In der Datei im SVN habe ich gesehen, das das Modul beim senden von Werten den Funktionscode 06 benutzt (%fcMap).
Gibt es eine Möglichkeit, zwei Register in einer Transaktion und mit Funktionscode 10 zu senden?
Klar:
Zitatdev-([cdih]-)*write
specifies the function code to use for writing this type of object. The default is 6 for holding registers and 5 for coils. Discrete inputs and input registers can not be written by definition.

6 ist nur der Default, aber selbst der wird in der Funktion GetFc abhängig von der Länge geändert:
    $defFC       = 16 if ($defFC == 6 && $len > 1);                 # 6 becomes 16 for more than one register
Gruß
   Stefan

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 25 August 2023, 22:01:36
Zitat von: StefanStrobel am 02 Juni 2023, 10:07:24Hallo fireball,

device löschen und neu anlegen erscheint mir nicht überzeugend als Lösung.
Es wäre schön zu verstehen, wer die Verbindung ständig schließt. Wenn das der Wechselrichter ist, dann kannst Du mit  closeAfterResponse verhindern, dass Fhem die Verbindung sofort wieder neu aufmacht.
Hilfreich wäre ein Auszug aus dem Log bei verbose 5.

Gruß
  Stefan


Hallo zusammen!

Ich habe dasselbe Problem mit meiner Heizung ETA PelletsCompact 20 mit Modbus TCP, stateFormat funktioniert nicht, es stand nach kurzer Zeit wieder  "opened" da, sowie alle 30 Sekunden DISCONNECTED/CONNECTED-Events.

Wie gewünscht hier der Auszug mit verbose 5:

2023.08.25 21:44:22 3 : 192.168.0.83:502 disconnected, waiting to reappear (etapc20)
2023.08.25 21:44:22 5 : HttpUtils url=http://192.168.0.83:502/ NonBlocking via http
2023.08.25 21:44:22 4 : IP: 192.168.0.83 -> 192.168.0.83
2023.08.25 21:44:22 3 : 192.168.0.83:502 reappeared (etapc20)
2023.08.25 21:44:22 4 : etapc20: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 237.5 sec at 21:48:19.937, interval 300
2023-08-25 21:44:22 ModbusAttr etapc20 DISCONNECTED
2023-08-25 21:44:22 ModbusAttr etapc20 CONNECTED
2023.08.25 21:44:52 3 : 192.168.0.83:502 disconnected, waiting to reappear (etapc20)
2023.08.25 21:44:52 5 : HttpUtils url=http://192.168.0.83:502/ NonBlocking via http
2023.08.25 21:44:52 4 : IP: 192.168.0.83 -> 192.168.0.83
2023.08.25 21:44:52 3 : 192.168.0.83:502 reappeared (etapc20)
2023.08.25 21:44:52 4 : etapc20: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 207.5 sec at 21:48:19.937, interval 300
2023-08-25 21:44:52 ModbusAttr etapc20 DISCONNECTED
2023-08-25 21:44:52 ModbusAttr etapc20 CONNECTED

"attr closeAfterResponse 1" hat das Problem halb gelöst, die Events alle 30 Sek. sind weg, aber der Status funktioniert immer noch nicht, jetzt steht da meistens "disconnected".
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 25 August 2023, 22:16:20
Zitat von: yoda_gh am 25 August 2023, 22:01:36"attr closeAfterResponse 1" hat das Problem halb gelöst, die Events alle 30 Sek. sind weg, aber der Status funktioniert immer noch nicht, jetzt steht da meistens "disconnected".

Ich muss allerdings gestehen, dass ich noch auf dem Stand von Anfang Februar bin (ModuleVersion 4.4.14) und da ich in ein paar Tagen in Urlaub fahre, mag ich jetzt auch kein Update mehr starten.  :-[
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 26 August 2023, 23:14:39
Nebenbei, für alle, die mehrere Werte aus einem Register lesen müssen (oder andere Besitzer einer ETA-Heizung...): ich habe mich eine Weile gespielt, um den ETA-Modbus-Typ "TIMESLOT" in FHEM abzubilden. Damit packen sie drei Werte, die ein Schaltprogramm beschreiben, in zwei Holding-Register (Register N: Temperatur * 10, Register N+1: End- und Startzeitpunkt jeweils in einem Byte, kodiert in Viertelstunden seit Mitternacht - 19:30 wäre also 78...).

(Siehe auch https://www.eta.co.at/produkte/downloads/technische-dokumente/ > SYSTEMKOMPONENTEN > ETAtouch Schnittstellen > Modbus/TCP Interface, Kapitel "3.2.4 Time slot variables")

Mit folgender Attributschlacht bekommt man die in ein Reading, das dann so aussieht:

"06:00-19:30 57.0 °C"

attr etapc20 dev-type-VT_Timeslot-expr sprintf("%02d:%02d-%02d:%02d %.1f °C", int(($val >> 8 & 0xFF) / 4), (($val >> 8 & 0xFF) % 4) * 15, int(($val & 0xFF) / 4), (($val & 0xFF) % 4) * 15, (($val >> 16) / 10))
attr etapc20 dev-type-VT_Timeslot-format %s
attr etapc20 dev-type-VT_Timeslot-len 2
attr etapc20 dev-type-VT_Timeslot-unpack l>
attr etapc20 dev-type-VT_Timeslot-set 1

attr etapc20 obj-hNNNN-type VT_Timeslot
attr etapc20 obj-hNNNN-reading WWProg1_Mo-1
attr etapc20 obj-hNNNN-setexpr ( (($1*4+int($2/15))<<8) + ($3*4+int($4/15)) + (($5*10+$6)<<16) ) if $val =~ /(\d+):(\d+)-(\d+):(\d+) (\d+).(\d+) °C/
attr etapc20 obj-hNNNN-textArg 1

Dazu gleich zwei Fragen:


Wenn das so Sinn macht, würde ich das auch auf https://wiki.fhem.de/wiki/ModbusAttr dokumentieren, oder?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 27 August 2023, 10:31:23
Hallo yoda_gh,

Beim Define wird seit Dezember devioNoSTATE gesetzt. Die Intention war dass stateFormat auch beim close wirkt. Ich schau mir das aber nach den Ferien nochmal an.

Dass textArg in der Doku fehlt ist keine Absicht sondern ein Fehler.
TextArg und setexpr kann ich gerne auch noch in die Attributliste für Types hinzufügen. Mehr Aufwand ist es nicht. Vorübergehend müsste es auch schon funktionieren wenn man dev-type-VT_Timeslot-setexpr als userattr hinzufügt.

Gruß 
    Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 27 August 2023, 14:48:39
Zitat von: StefanStrobel am 27 August 2023, 10:31:23Beim Define wird seit Dezember devioNoSTATE gesetzt. Die Intention war dass stateFormat auch beim close wirkt. Ich schau mir das aber nach den Ferien nochmal an.

Dass textArg in der Doku fehlt ist keine Absicht sondern ein Fehler.
TextArg und setexpr kann ich gerne auch noch in die Attributliste für Types hinzufügen. Mehr Aufwand ist es nicht. Vorübergehend müsste es auch schon funktionieren wenn man dev-type-VT_Timeslot-setexpr als userattr hinzufügt.

Ah, interessant, vielleicht komme ich vor dem Urlaub auch noch dazu, das mit dem stateFormat zu debuggen. Gibt es etwas, was ich wegen dem DISCONNECTED noch nachschauen/testen sollte?

Hilft Dir ein Patch für TextArg und setexpr?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 28 August 2023, 21:47:30
Zitat von: StefanStrobel am 27 August 2023, 10:31:23Hallo yoda_gh,

Beim Define wird seit Dezember devioNoSTATE gesetzt. Die Intention war dass stateFormat auch beim close wirkt. Ich schau mir das aber nach den Ferien nochmal an.

Hab noch ein bisschen reingeschaut. Kann es sein, dass das devioNoSTATE im logischen Device gesetzt werden müsste? Ich habe es zumindest mal testhalber (zusätzlich) in DefineLDFn eingebaut und das Device neu angelegt. Jetzt sehe ich devioNoSTATE auch als INTERNAL und stateFormat funktioniert scheinbar jetzt auch korrekt.

Ich hab allerdings jetzt nur mit der alten Version vom Januar getestet - unmittelbar vor dem Urlaub mag ich kein Update mehr riskieren. :) Wenn es (dann noch) was bringt, kann ich Dir Mitte September gerne einen Patch vorbereiten. :)
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: JensS am 19 September 2023, 19:50:51
Hallo @Stefan,

lässt sich ein  SUN-M60/80/100G3-EU-Q0 mit ModbusAttr abfragen?
Mit der Definition von @bismosa https://forum.fhem.de/index.php?msg=1264999 (https://forum.fhem.de/index.php?msg=1264999) hatte ich es probiert aber keine Werte erhalten.

Gruß Jens
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 September 2023, 19:07:37
Hallo Jens,

ob der SUN-M60/80/100G3-EU-Q0 überhaupt Modbus unterstützt und falls ja, welche Register welche Werte liefern kann ich Dir nicht sagen.
Ich hab mal im Netz nach dem Datenblatt gesucht und dort stand nichts von Modbus.
Du müsstest Dich da rantasten und erstmal suchen ob es einen offenen Port gibt, der eventuell mit Modbus angesprochen werden kann. Dann könntest Du die Register scannen. Oder Du findest irgendwo eine Doku, in der das drinsteht.

Gruss
  Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 September 2023, 19:08:29
Zitat von: yoda_gh am 28 August 2023, 21:47:30Hab noch ein bisschen reingeschaut. Kann es sein, dass das devioNoSTATE im logischen Device gesetzt werden müsste? Ich habe es zumindest mal testhalber (zusätzlich) in DefineLDFn eingebaut und das Device neu angelegt. Jetzt sehe ich devioNoSTATE auch als INTERNAL und stateFormat funktioniert scheinbar jetzt auch korrekt.

so ist es. Ich ändere das in der nächsten Version.

Gruss / Thanx
    Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: bismosa am 20 September 2023, 19:15:34
Zitat von: JensS am 19 September 2023, 19:50:51Hallo @Stefan,

lässt sich ein  SUN-M60/80/100G3-EU-Q0 mit ModbusAttr abfragen?
Mit der Definition von @bismosa https://forum.fhem.de/index.php?msg=1264999 (https://forum.fhem.de/index.php?msg=1264999) hatte ich es probiert aber keine Werte erhalten.

Gruß Jens
Hallo!
Da es sich bei den Deye Geräten wohl um kein "echtes" Modbus handelt, hatte ich an der Stelle auch aufgegeben.
Es gibt ein sehr interessantes Projekt: https://github.com/kbialek/deye-inverter-mqtt
Läuft bei mir mit Docker einwandfrei. Und wenn ich das richtig verstanden habe, dann sogar schon mit der neuen Firmware, wenn man das Relais dazwischen geschaltet hat.

Gruß
Bismosa
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 21 September 2023, 10:30:32
Ein Fehlerbild im Log, was ich nicht ganz nachvollziehen kann, aber eine Idee habe, woran es liegen könnte.

Log Auszug:
2023.09.21 09:47:27 3: Studer485_Gateway: MapConvert called from CreateDataObjects did not find 90 (90) in map 0:Warning (000) - Battery too low, 1:Warning (001) - Battery too high, 2:Warning (002) - Bulk charge too long, 3:(003) - AC-In synchronization in progress, 4:Warning (004) - Input frequency AC-In wrong, 5:Warning (005) - Input frequency AC-In wrong, 6:Warning (006) - Input voltage AC-In too high, 7:Warning (007) - Input voltage AC-In too low, 8:Halted (008) - Inverter overload SC, 9:Halted (009) - Charger short circuit, 10:(010) - System start-up in progress, 11:Warning (011) - AC-In Energy quota, 12:(012) - Use of battery temperature sensor, 13:(013) - Use of additional remote control, 14:Halted (014) - Over temperature EL, 15:Halted (015) - Inverter overload BL, 16:Warning (016) - Fan error detected, 17:(017) - Programing mode, 18:Warning (018) - Excessive battery voltage ripple, 19:Halted (019) - Battery undervoltage, 20:Halted (020) - Battery overvoltage, 21:(021) - Transfer not authorized, AC-Out current is higher than {1107}, 22:Halted (022) - Voltage presence on AC-Out, 23:Halted (023) - Phase not defined, 24:Warning (024) - Change the clock battery, 25:Halted (025) - Unknown Command board. Software upgrade needed, 26:Halted (026) - Unknown Power board. Software upgrade needed, 27:Halted (027) - Unknown extension board. Software upgrade needed, 28:Halted (028) - Voltage incompatibility Power - Command, 29:Halted (029) - Voltage incompatibility Ext. - Command, 30:Halted (030) - Power incompatibility Power - Command, 31:Halted (031) - Command board software incompatibility, 32:Halted (032) - Power board software incompatibility, 33:Halted (033) - Extension board software incompatibility, 34:Halted (034) - FID corruption, call factory, 35:(035) - Memory structure modified, 36:Halted (036) - Parameter file lacking, 37:Warning (037) - Message file lack. SW upgrade advised, 38:Warning (038) - Upgrade of the device software advised, 39:Warning (039) - Upgrade of the device software advised, 40:Warning (040) - Upgrade of the device software advised, 41:Warning (041) - Over temperature TR, 42:Halted (042) - Unauthorized energy source at the output, 43:(043) - Start of monthly test, 44:(044) - End of successfully monthly test, 45:Warning (045) - Monthly autonomy test failed, 46:(046) - Start of weekly test, 47:(047) - End of successfully weekly test, 48:Warning (048) - Weekly autonomy test failed, 49:(049) - Transfer opened because AC-In max current exceeded {1107}, 50:Error (050) - Incomplete data transfer, 51:(051) - The update is finished, 52:(052) - Your installation is already updated, 53:Halted (053) - Devices not compatible, software update required, 54:(054) - Please wait. Data transfer in progress, 55:Error (055) - No SD card inserted, 56:Warning (056) - Upgrade of the RCC software advised, 57:(057) - Operation finished successfully, 58:Halted (058) - Master synchronization missing, 59:Halted (059) - Inverter overload HW, 60:Warning (060) - Time security 1512 AUX1, 61:Warning (061) - Time security 1513 AUX2, 62:Warning (062) - Genset, no AC-In coming after AUX command, 63:(063) - Save parameter XT, 64:(064) - Save parameter BSP, 65:(065) - Save parameter VarioTrack, 71:Error (071) - Insufficient disk space on SD card, 72:Halted (072) - COM identification incorrect, 73:(073) - Datalogger is enabled on this RCC, 74:(074) - Save parameter Xcom-MS, 75:(075) - MPPT MS address changed successfully, 76:Error (076) - Error during change of MPPT MS address, 77:Error (077) - Wrong MPPT MS DIP Switch position, 78:(078) - SMS or email sent, 79:Halted (079) - More than 9 XTs in the system, 80:Halted (080) - No battery (or reverse polarity), 81:Warning (081) - Earthing fault, 82:Halted (082) - PV overvoltage, 83:Warning (083) - No solar production in the last 48h, 84:(084) - Equalization performed, 85:Error (085) - Modem not available, 86:Error (086) - Incorrect PIN code, unable to initiate the modem, 87:Error (087) - Insufficient Signal from GSM modem, 88:Error (088) - No connection to GSM network, 89:Error (089) - No Xcom server access, 90:(090) - Xcom server connected, 91:Warning (091) - Update finished. Update software of other RCC/Xcom-232i, 92:Error (092) - More than 4 RCC or Xcom in the system, 93:Error (093) - More than 1 BSP in the system, 94:Error (094) - More than 1 Xcom-MS in the system, 95:Error (095) - More than 15 VarioTrack in the system, 121:Error (121) - Impossible communication with target device, 122:Error (122) - SD card corrupted, 123:Error (123) - SD card not formatted, 124:Error (124) - SD card not compatible
Ich bekomme trotzdem ein Reading im Device:

Last_Message_Info 90 2023-09-21 09:47:27
wenn ich den Teil des Fehler anschaue:
2023.09.21 09:47:27 3: Studer485_Gateway: MapConvert called from CreateDataObjects did not find 90 (90) in map
wird 90 (90) angezeigt. Ich weiß nicht, wo die (90) in Klammern herkommt. Ob das nur die Syntax des Fehlers ist?

Blöderweise werfen andere Werte keine Fehler im Log... will sagen ein zB 3 wird aufgelöst. Aber ich weiß nicht, ob das dann 3 (003) kommt.

Jemand eine Idee?

RAW vom Device:
defmod Studer485_Gateway ModbusAttr 33 0
attr Studer485_Gateway dev-defPoll 1
attr Studer485_Gateway dev-defUnpack n
attr Studer485_Gateway dev-i-read 4
attr Studer485_Gateway dev-timing-timeout 1
attr Studer485_Gateway event-on-change-reading .*
attr Studer485_Gateway group Xtender
attr Studer485_Gateway nonPrioritizedGet 1
attr Studer485_Gateway obj-i0-len 1
attr Studer485_Gateway obj-i0-reading Message_Count_must_read_first
attr Studer485_Gateway obj-i1-group 1-1
attr Studer485_Gateway obj-i1-len 1
attr Studer485_Gateway obj-i1-map 0:Gateway, 11:XTM, 21:VT, 61:BSP
attr Studer485_Gateway obj-i1-reading Last_Message_Device
attr Studer485_Gateway obj-i2-group 1-2
attr Studer485_Gateway obj-i2-len 1
attr Studer485_Gateway obj-i2-map 0:Warning (000) - Battery too low, 1:Warning (001) - Battery too high, 2:Warning (002) - Bulk charge too long, 3:(003) - AC-In synchronization in progress, 4:Warning (004) - Input frequency AC-In wrong, 5:Warning (005) - Input frequency AC-In wrong, 6:Warning (006) - Input voltage AC-In too high, 7:Warning (007) - Input voltage AC-In too low, 8:Halted (008) - Inverter overload SC, 9:Halted (009) - Charger short circuit, 10:(010) - System start-up in progress, 11:Warning (011) - AC-In Energy quota, 12:(012) - Use of battery temperature sensor, 13:(013) - Use of additional remote control, 14:Halted (014) - Over temperature EL, 15:Halted (015) - Inverter overload BL, 16:Warning (016) - Fan error detected, 17:(017) - Programing mode, 18:Warning (018) - Excessive battery voltage ripple, 19:Halted (019) - Battery undervoltage, 20:Halted (020) - Battery overvoltage, 21:(021) - Transfer not authorized,  AC-Out current is higher than {1107}, 22:Halted (022) - Voltage presence on AC-Out, 23:Halted (023) - Phase not defined, 24:Warning (024) - Change the clock battery, 25:Halted (025) - Unknown Command board. Software upgrade needed, 26:Halted (026) - Unknown Power board. Software upgrade needed, 27:Halted (027) - Unknown extension board. Software upgrade needed, 28:Halted (028) - Voltage incompatibility Power - Command, 29:Halted (029) - Voltage incompatibility Ext. - Command, 30:Halted (030) - Power incompatibility Power - Command, 31:Halted (031) - Command board software incompatibility, 32:Halted (032) - Power board software incompatibility, 33:Halted (033) - Extension board software incompatibility, 34:Halted (034) - FID corruption,  call factory, 35:(035) - Memory structure modified, 36:Halted (036) - Parameter file lacking, 37:Warning (037) - Message file lack. SW upgrade advised, 38:Warning (038) - Upgrade of the device software advised, 39:Warning (039) - Upgrade of the device software advised, 40:Warning (040) - Upgrade of the device software advised, 41:Warning (041) - Over temperature TR, 42:Halted (042) - Unauthorized energy source at the output, 43:(043) - Start of monthly test, 44:(044) - End of successfully monthly test, 45:Warning (045) - Monthly autonomy test failed, 46:(046) - Start of weekly test, 47:(047) - End of successfully weekly test, 48:Warning (048) - Weekly autonomy test failed, 49:(049) - Transfer opened because AC-In max current exceeded {1107}, 50:Error (050) - Incomplete data transfer, 51:(051) - The update is finished, 52:(052) - Your installation is already updated, 53:Halted (053) - Devices not compatible,  software update required, 54:(054) - Please wait. Data transfer in progress, 55:Error (055) - No SD card inserted, 56:Warning (056) - Upgrade of the RCC software advised, 57:(057) - Operation finished successfully, 58:Halted (058) - Master synchronization missing, 59:Halted (059) - Inverter overload HW, 60:Warning (060) - Time security 1512 AUX1, 61:Warning (061) - Time security 1513 AUX2, 62:Warning (062) - Genset,  no AC-In coming after AUX command, 63:(063) - Save parameter XT, 64:(064) - Save parameter BSP, 65:(065) - Save parameter VarioTrack, 71:Error (071) - Insufficient disk space on SD card, 72:Halted (072) - COM identification incorrect, 73:(073) - Datalogger is enabled on this RCC, 74:(074) - Save parameter Xcom-MS, 75:(075) - MPPT MS address changed successfully, 76:Error (076) - Error during change of MPPT MS address, 77:Error (077) - Wrong MPPT MS DIP Switch position, 78:(078) - SMS or email sent, 79:Halted (079) - More than 9 XTs in the system, 80:Halted (080) - No battery (or reverse polarity), 81:Warning (081) - Earthing fault, 82:Halted (082) - PV overvoltage, 83:Warning (083) - No solar production in the last 48h, 84:(084) - Equalization performed, 85:Error (085) - Modem not available, 86:Error (086) - Incorrect PIN code,  unable to initiate the modem, 87:Error (087) - Insufficient Signal from GSM modem, 88:Error (088) - No connection to GSM network, 89:Error (089) - No Xcom server access, 90:(090) - Xcom server connected, 91:Warning (091) - Update finished. Update software of other RCC/Xcom-232i, 92:Error (092) - More than 4 RCC or Xcom in the system, 93:Error (093) - More than 1 BSP in the system, 94:Error (094) - More than 1 Xcom-MS in the system, 95:Error (095) - More than 15 VarioTrack in the system, 121:Error (121) - Impossible communication with target device, 122:Error (122) - SD card corrupted, 123:Error (123) - SD card not formatted, 124:Error (124) - SD card not compatible, 125:Error (125) - SD card format not recognized. Should be FAT, 126:Error (126) - SD card write protected, 127:Error (127) - SD card,  file(s) corrupted, 128:Error (128) - SD card file or directory could not be found, 129:Error (129) - SD card has been prematurely removed, 130:Error (130) - Update directory is empty, 131:(131) - The VarioTrack is configured for 12V batteries, 132:(132) - The VarioTrack is configured for 24V batteries, 133:(133) - The VarioTrack is configured for 48V batteries, 134:(134) - Reception level of the GSM signal, 137:(137) - VarioTrack master synchronization lost, 138:Error (138) - XT master synchronization lost, 139:(139) - Synchronized on VarioTrack master, 140:(140) - Synchronized on XT master, 141:Error (141) - More than 1 Xcom-SMS in the system, 142:Error (142) - More than 15 VarioString in the system, 143:(143) - Save parameter Xcom-SMS, 144:(144) - Save parameter VarioString, 145:Error (145) - SIM card blocked,  PUK code required, 146:Error (146) - SIM card missing, 147:Error (147) - Install R532 firmware release prior to install an older release, 148:(148) - Datalogger function interrupted (SD card removed), 149:Error (149) - Parameter setting incomplete, 150:Error (150) - Cabling error between PV and VarioString, 162:Error (162) - Communication loss with RCC or Xcom-232i, 163:Error (163) - Communication loss with Xtender, 164:Error (164) - Communication loss with BSP, 165:Error (165) - Communication loss with Xcom-MS, 166:Error (166) - Communication loss with VarioTrack, 167:Error (167) - Communication loss with VarioString, 168:(168) - Synchronized with VarioString master, 169:(169) - Synchronization with VarioString master lost, 170:Warning (170) - No solar production in the last 48h on PV1, 171:Warning (171) - No solar production in the last 48h on PV2, 172:Error (172) - FID change impossible. More than one unit., 173:Error (173) - Incompatible Xtender. Please contact Studer Innotec SA, 174:(174) - Inaccessible parameter,  managed by the Xcom-CAN, 175:Halted (175) - Critical undervoltage, 176:(176) - Calibration setting lost, 177:(177) - An Xtender has started up, 178:(178) - No BSP. Necessary for programming with SOC, 179:(179) - No BTS or BSP. Necessary for programming with temperature, 180:(180) - Command entry activated, 181:Error (181) - Disconnection of BTS, 182:(182) - BTS/BSP battery temperature measurement used by a device, 183:Halted (183) - An Xtender has lost communication with the system, 184:Error (184) - Check phase orientation or circuit breakers state on AC-In, 185:Warning (185) - AC-In voltage level with delay too low, 186:Halted (186) - Critical undervoltage (fast), 187:Halted (187) - Critical overvoltage (fast), 188:(188) - CAN stage startup, 189:Error (189) - Incompatible configuration file, 190:(190) - The Xcom-SMS is busy, 191:(191) - Parameter not supported, 192:(192) - Unknown reference, 193:(193) - Invalid value, 194:(194) - Value too low, 195:(195) - Value too high, 196:(196) - Writing error, 197:(197) - Reading error, 198:(198) - User level insufficient, 199:(199) - No data for the report, 200:Error (200) - Memory full, 202:Warning (202) - Battery alarm arrives, 203:(203) - Battery alarm leaves, 204:Error (204) - Battery stop arrives, 205:(205) - Battery stop leaves, 206:Halted (206) - Board hardware incompatibility, 207:(207) - AUX1 relay activation, 208:(208) - AUX1 relay deactivation, 209:(209) - AUX2 relay activation, 210:(210) - AUX2 relay deactivation, 211:(211) - Command entry deactivated, 212:Error (212) - VarioTrack software incompatibility. Upgrade needed, 213:(213) - Battery current limitation by the BSP stopped, 214:Warning (214) - Half period RMS voltage limit exceeded,  transfer opened, 215:Warning (215) - UPS limit reached,  transfer opened, 216:Warning (216) - Scom watchdog caused the reset of Xcom-232i, 217:Warning (217) - CAN problem at Xtender declaration, 218:Warning (218) - CAN problem while writing parameters, 222:(222) - Front ON/OFF button pressed, 223:(223) - Main OFF detected, 224:(224) - Delay before closing transfer relay in progress {1580}, 225:Error (225) - Communication with lithium battery lost, 226:(226) - Communication with lithium battery restored, 227:Error (227) - Overload on high voltage DC side, 228:Error (228) - Startup error, 229:Error (229) - Short-circuit on high voltage DC side, 65535:(65535) - HDM_Garbage_keine Ahnung
attr Studer485_Gateway obj-i2-reading Last_Message_Info
attr Studer485_Gateway obj-i3-group 1-3
attr Studer485_Gateway obj-i3-len 1
attr Studer485_Gateway obj-i3-reading Last_Message_ignore1
attr Studer485_Gateway obj-i4-group 1-4
attr Studer485_Gateway obj-i4-len 1
attr Studer485_Gateway obj-i4-reading Last_Message_ignore2

setstate Studer485_Gateway opened
setstate Studer485_Gateway 2023-09-21 09:47:27 Last_Message_Device Gateway
setstate Studer485_Gateway 2023-09-21 09:47:27 Last_Message_Info 90
setstate Studer485_Gateway 2023-09-21 09:47:27 Last_Message_ignore1 0
setstate Studer485_Gateway 2023-09-21 09:47:27 Last_Message_ignore2 0
setstate Studer485_Gateway 2023-09-21 10:38:51 Message_Count_must_read_first 0
setstate Studer485_Gateway 2023-09-20 15:57:47 state opened
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 21 September 2023, 16:41:02
... habe das Gefühl meine Syntax im Mapping könnte falsch sein und das Problem ist gerade zufällig (resp. vorher bei anderen Fehlercodes nicht ersichtlich) . Sind Klammern oder Leerzeichen oder Bindestriche nutzbar?

Ich dachte ":" und "," sind die einzigen Delimiter die ausgewertet werden?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: JensS am 21 September 2023, 17:58:42
Zitat von: bismosa am 20 September 2023, 19:15:34Da es sich bei den Deye Geräten wohl um kein "echtes" Modbus handelt, hatte ich an der Stelle auch aufgegeben.
Es gibt ein sehr interessantes Projekt: https://github.com/kbialek/deye-inverter-mqtt
Läuft bei mir mit Docker einwandfrei. Und wenn ich das richtig verstanden habe, dann sogar schon mit der neuen Firmware, wenn man das Relais dazwischen geschaltet hat.

Gruß
Bismosa
Danke, hab's vorerst mit einem angepassten https://github.com/jedie/inverter-connect (https://github.com/jedie/inverter-connect) gelöst.
Gruß Jens
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 24 September 2023, 10:59:51
Zitat von: holle75 am 21 September 2023, 16:41:02... habe das Gefühl meine Syntax im Mapping könnte falsch sein und das Problem ist gerade zufällig (resp. vorher bei anderen Fehlercodes nicht ersichtlich) . Sind Klammern oder Leerzeichen oder Bindestriche nutzbar?

Ich dachte ":" und "," sind die einzigen Delimiter die ausgewertet werden?

habe eben im mapping, gut versteckt und beim Konvertieren unbemerkt,

21:(021) - Transfer not authorized, AC-Out current is higher than {1107}

gefunden. Die {1107} mit den geschweiften Klammern eliminiert. Das könnte erklären (just a hunch), warum die Codes kleiner als 21 funktionieren. Mal schauen, was jetzt passiert.

________________________________________

EDIT: DAMN, das war nicht das Problem :(

funktioniert nicht:
Last_Message_Info: 90

funktioniert:
Last_Message_Info: (003) - AC-In synchronization in progress
Last_Message_Info: (211) - Command entry deactivated
Last_Message_Info: (208) - AUX1 relay deactivation

vielleicht findet jemand eine Logik?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 28 September 2023, 16:50:50
Zitat von: holle75 am 21 September 2023, 16:41:02Ich dachte ":" und "," sind die einzigen Delimiter die ausgewertet werden?

Man sollte auf sich selber hören. Im mapping waren im Text "," versteckt. Test läuft. Entschuldigung wahrscheinlich eure Lese-Zeit unnötig geklaut zu haben.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: 300P am 12 Oktober 2023, 17:14:28
Hallo an die Modbus-User,

ich bin auf der Suche nach einer speziellen Routine und hoffe mir kann jemand dabei helfen sie zu finden oder zu erstellen:

Die Routine soll für einen SMA (SunnyBoyStorage) SBS25 die "richtigen" Register im "richtigen Format" zum zyklischen Beschreiben (ca. 15 Sekunden) setzen, um dadurch eine Be-Ladung des angeschlossenen Speichers zu erwirken. (zur evtl. Nutzung der dynamischen Tarife von Timber/Awatar&Co.)

Mittels ModbusAttr-Modul lese ich bereits diverse passenden Register des SBS25 bereits aus, aber für das beschreiben (der zuständigen WO-Register) mittels Routine fehlt mir die Erfahrung (und auch der Mut es einfach "so mal zu schreiben/machen").
Zum reinen experimentieren ist mir nun doch das mit meinen HV-Akkus und der WR einfach zu kostspielig wenn ich dort "etwas vergeige".

Hier mein aktuell genutztes Modul das soweit erst einmal alles liest:

defmod MB_SBS25 ModbusAttr 3  5   192.168.121.176:502  TCP
attr MB_SBS25 dev-h-defLen 2
attr MB_SBS25 dev-h-defPoll 1
attr MB_SBS25 dev-h-defUnpack N
attr MB_SBS25 dev-type-S16F0-expr $val/1
attr MB_SBS25 dev-type-S16F0-format %.0f
attr MB_SBS25 dev-type-S16F0-len 1
attr MB_SBS25 dev-type-S16F0-unpack N
attr MB_SBS25 dev-type-S16F1-expr $val/1
attr MB_SBS25 dev-type-S16F1-format %.1f
attr MB_SBS25 dev-type-S16F1-len 1
attr MB_SBS25 dev-type-S16F1-unpack N
attr MB_SBS25 dev-type-S16F2-expr $val/1
attr MB_SBS25 dev-type-S16F2-format %.2f
attr MB_SBS25 dev-type-S16F2-len 1
attr MB_SBS25 dev-type-S16F2-unpack N
attr MB_SBS25 dev-type-S32-format %d
attr MB_SBS25 dev-type-S32-len 2
attr MB_SBS25 dev-type-S32-unpack l>
attr MB_SBS25 dev-type-S32F0-expr $val
attr MB_SBS25 dev-type-S32F0-format %.0f
attr MB_SBS25 dev-type-S32F0-len 2
attr MB_SBS25 dev-type-S32F0-unpack i>
attr MB_SBS25 dev-type-S32F1-expr $val
attr MB_SBS25 dev-type-S32F1-format %.1f
attr MB_SBS25 dev-type-S32F1-len 2
attr MB_SBS25 dev-type-S32F1-revRegs 1
attr MB_SBS25 dev-type-S32F1-unpack i>
attr MB_SBS25 dev-type-S32F2-expr $val
attr MB_SBS25 dev-type-S32F2-format %.2f
attr MB_SBS25 dev-type-S32F2-len 2
attr MB_SBS25 dev-type-S32F2-revRegs 1
attr MB_SBS25 dev-type-S32F2-unpack i>
attr MB_SBS25 dev-type-S32F3-expr $val
attr MB_SBS25 dev-type-S32F3-format %.3f
attr MB_SBS25 dev-type-S32F3-len 2
attr MB_SBS25 dev-type-S32F3-unpack i>
attr MB_SBS25 dev-type-S32F4-expr $val
attr MB_SBS25 dev-type-S32F4-format %.4f
attr MB_SBS25 dev-type-S32F4-len 2
attr MB_SBS25 dev-type-S32F4-revRegs 1
attr MB_SBS25 dev-type-S32F4-unpack i>
attr MB_SBS25 dev-type-S32TEMP-expr ($val & 0xFFFF) / 10
attr MB_SBS25 dev-type-S32TEMP-format %.2f
attr MB_SBS25 dev-type-S32TEMP-len 2
attr MB_SBS25 dev-type-S32TEMP-unpack l>
attr MB_SBS25 dev-type-U32-format %u
attr MB_SBS25 dev-type-U32-len 2
attr MB_SBS25 dev-type-U32-unpack I
attr MB_SBS25 dev-type-U32F0-format %.0f
attr MB_SBS25 dev-type-U32F0-len 2
attr MB_SBS25 dev-type-U32F0-unpack N
attr MB_SBS25 dev-type-U32F1-format %.1f
attr MB_SBS25 dev-type-U32F1-len 2
attr MB_SBS25 dev-type-U32F1-unpack N
attr MB_SBS25 dev-type-U32F2-format %.2f
attr MB_SBS25 dev-type-U32F2-len 2
attr MB_SBS25 dev-type-U32F2-unpack N
attr MB_SBS25 dev-type-U32F3-format %.3f
attr MB_SBS25 dev-type-U32F3-len 2
attr MB_SBS25 dev-type-U32F3-unpack N
attr MB_SBS25 dev-type-U32F4-format %.4f
attr MB_SBS25 dev-type-U32F4-len 2
attr MB_SBS25 dev-type-U32F4-unpack N
attr MB_SBS25 dev-type-U32RAW-format %d
attr MB_SBS25 dev-type-U32RAW-len 2
attr MB_SBS25 devStateIcon {\
my $mode = 'measure_power@green';;;;\
$mode = 'measure_power@yellow' if (ReadingsVal($name, "Wirkleistung_W", "") < 1);;;;\
\
my $chargePw = ReadingsVal("SBS25", "state", "")*1000;;;;\
\
my $charge = '';;;;\
$charge = 'control_arrow_leftward@greenyellow' if ($chargePw < 0);;;;\
$charge = 'control_arrow_rightward@green' if ($chargePw > 0);;;;\
\
my $ChargeStatus = 'measure_battery_100@green';;;;\
$ChargeStatus = 'measure_battery_75@green' if (ReadingsVal($name, "BatterieLadezustand_%", "") < 80);;;;\
$ChargeStatus = 'measure_battery_50@yellow' if (ReadingsVal($name, "BatterieLadezustand_%", "") < 55);;;;\
$ChargeStatus = 'measure_battery_25@orange' if (ReadingsVal($name, "BatterieLadezustand_%", "") < 30);;;;\
$ChargeStatus = 'measure_battery_0@red' if (ReadingsVal($name, "BatterieLadezustand_%", "") < 6);;;;\
\
my $Cap = (ReadingsVal($name,"BatterieLadezustand_%",0) ) * 98;;\
\
\
"<div>" . \
FW_makeImage($mode,"measure_power") ." AC ". ReadingsVal($name,"Wirkleistung_W",0) ."W  ". \
FW_makeImage($ChargeStatus,"") . \
FW_makeImage($charge,"") ." ". $chargePw ."W   ". \
ReadingsVal($name,"BatterieLadezustand_%",0) ."% ".\
$Cap."wh  ".\
"</div>"}
attr MB_SBS25 event-min-interval .*:600
attr MB_SBS25 event-on-change-reading .*
attr MB_SBS25 obj-h30003-expr $val / 1
attr MB_SBS25 obj-h30003-format %.f
attr MB_SBS25 obj-h30003-len 2
attr MB_SBS25 obj-h30003-name SBS25_Nameplate.SusyId
attr MB_SBS25 obj-h30003-poll once
attr MB_SBS25 obj-h30003-reading TTTNameplate.SusyId
attr MB_SBS25 obj-h30003-type U32RAW
attr MB_SBS25 obj-h30003-unpack N
attr MB_SBS25 obj-h30005-expr $val / 1
attr MB_SBS25 obj-h30005-format %.f
attr MB_SBS25 obj-h30005-len 2
attr MB_SBS25 obj-h30005-name SBS25_Nameplate.SerNum
attr MB_SBS25 obj-h30005-poll once
attr MB_SBS25 obj-h30005-reading TTTNameplate.SerNum
attr MB_SBS25 obj-h30005-type U32RAW
attr MB_SBS25 obj-h30005-unpack N
attr MB_SBS25 obj-h30051-expr $val / 1
attr MB_SBS25 obj-h30051-format %.f
attr MB_SBS25 obj-h30051-len 2
attr MB_SBS25 obj-h30051-name SBS25_Nameplate.MainModel
attr MB_SBS25 obj-h30051-poll once
attr MB_SBS25 obj-h30051-reading TTTNameplate.MainModel
attr MB_SBS25 obj-h30051-unpack N
attr MB_SBS25 obj-h30053-expr $val / 1
attr MB_SBS25 obj-h30053-format %.f
attr MB_SBS25 obj-h30053-len 2
attr MB_SBS25 obj-h30053-name SBS25_Nameplate.Model
attr MB_SBS25 obj-h30053-poll once
attr MB_SBS25 obj-h30053-reading TTTNameplate.Model
attr MB_SBS25 obj-h30053-unpack N
attr MB_SBS25 obj-h30201-map 35:Fehler, 303:Aus, 307:OK, 455:Warnung
attr MB_SBS25 obj-h30201-name SBS25_StatusWR
attr MB_SBS25 obj-h30201-reading StatusWR
attr MB_SBS25 obj-h30211-map 336:Contact manufacturer, 337:Contact installer, 338:invalid, 887:none
attr MB_SBS25 obj-h30211-name SBS25_UserAction
attr MB_SBS25 obj-h30211-polldelay x1
attr MB_SBS25 obj-h30211-reading UserAction
attr MB_SBS25 obj-h30217-map 16777213:Fehler, 51:geschlossen, 311:offen
attr MB_SBS25 obj-h30217-name SBS25_Netzrelais
attr MB_SBS25 obj-h30217-polldelay x1
attr MB_SBS25 obj-h30217-reading Netzrelais
attr MB_SBS25 obj-h30235-expr $val / 1
attr MB_SBS25 obj-h30235-len 2
attr MB_SBS25 obj-h30235-map 1440: Netzbetrieb (ModGri), 1441: Inselnetzbetrieb (ModOffGri), 316777213: Information liegt nicht vor (NaNStt)
attr MB_SBS25 obj-h30235-name SBS25_TTTBatterie_Backup-Modus
attr MB_SBS25 obj-h30235-poll x13
attr MB_SBS25 obj-h30235-polldelay 1
attr MB_SBS25 obj-h30235-reading TTTBatterie_Backup-Modus
attr MB_SBS25 obj-h30235-unpack N
attr MB_SBS25 obj-h30529-format %.f
attr MB_SBS25 obj-h30529-name SBS25_NetzEMEinspeisungGesamt_Wh
attr MB_SBS25 obj-h30529-polldelay x7
attr MB_SBS25 obj-h30529-reading NetzEMEinspeisungGesamt_Wh
attr MB_SBS25 obj-h30529-type U32F0
attr MB_SBS25 obj-h30531-name SBS25_BatterieLadungTag_Wh
attr MB_SBS25 obj-h30531-polldelay x7
attr MB_SBS25 obj-h30531-reading BatterieLadungTag_Wh
attr MB_SBS25 obj-h30531-type U32F0
attr MB_SBS25 obj-h30535-name SBS25_BatterieEnladungTag_Wh
attr MB_SBS25 obj-h30535-polldelay x7
attr MB_SBS25 obj-h30535-reading BatterieEntladungTag_Wh
attr MB_SBS25 obj-h30535-type U32F0
attr MB_SBS25 obj-h30769-expr $val  / 1000
attr MB_SBS25 obj-h30769-format %.3f
attr MB_SBS25 obj-h30769-len 2
attr MB_SBS25 obj-h30769-name SBS25_DC_Strom_1_A
attr MB_SBS25 obj-h30769-poll 0
attr MB_SBS25 obj-h30769-polldelay x4
attr MB_SBS25 obj-h30769-reading DC_Strom_1_A
attr MB_SBS25 obj-h30771-expr $val  / 100
attr MB_SBS25 obj-h30771-format %.2f
attr MB_SBS25 obj-h30771-len 2
attr MB_SBS25 obj-h30771-name SBS25_DC_Spannung_1_V
attr MB_SBS25 obj-h30771-poll 0
attr MB_SBS25 obj-h30771-polldelay x4
attr MB_SBS25 obj-h30771-reading DC_Spannung_1_V
attr MB_SBS25 obj-h30773-name SBS25_DC_Leistung_1_W
attr MB_SBS25 obj-h30773-poll 0
attr MB_SBS25 obj-h30773-reading DC_Leistung_1_W
attr MB_SBS25 obj-h30775-expr $val
attr MB_SBS25 obj-h30775-name SBS25_Wirkleistung_W
attr MB_SBS25 obj-h30775-poll 1
attr MB_SBS25 obj-h30775-polldelay x3
attr MB_SBS25 obj-h30775-reading Wirkleistung_W
attr MB_SBS25 obj-h30775-type S32F0
attr MB_SBS25 obj-h30777-expr $val
attr MB_SBS25 obj-h30777-name SBS25_Wirkleistung_L1_W
attr MB_SBS25 obj-h30777-poll 0
attr MB_SBS25 obj-h30777-polldelay x3
attr MB_SBS25 obj-h30777-reading Wirkleistung_L1_W
attr MB_SBS25 obj-h30777-type S32F0
attr MB_SBS25 obj-h30779-expr $val
attr MB_SBS25 obj-h30779-name SBS25_Wirkleistung_L2_W
attr MB_SBS25 obj-h30779-poll 0
attr MB_SBS25 obj-h30779-polldelay x3
attr MB_SBS25 obj-h30779-reading Wirkleistung_L2_W
attr MB_SBS25 obj-h30779-type S32F0
attr MB_SBS25 obj-h30781-expr $val
attr MB_SBS25 obj-h30781-name SBS25_Wirkleistung_L3_W
attr MB_SBS25 obj-h30781-poll 0
attr MB_SBS25 obj-h30781-polldelay x3
attr MB_SBS25 obj-h30781-reading Wirkleistung_L3_W
attr MB_SBS25 obj-h30781-type S32F0
attr MB_SBS25 obj-h30783-expr $val
attr MB_SBS25 obj-h30783-format %.2f
attr MB_SBS25 obj-h30783-name SBS25_Grid_Spannung_V
attr MB_SBS25 obj-h30783-poll 0
attr MB_SBS25 obj-h30783-polldelay x7
attr MB_SBS25 obj-h30783-reading Grid_Spannung_V
attr MB_SBS25 obj-h30783-type U32F2
attr MB_SBS25 obj-h30843-expr ($val /1000)
attr MB_SBS25 obj-h30843-name BatterieStrom_DC__A
attr MB_SBS25 obj-h30843-poll 1
attr MB_SBS25 obj-h30843-polldelay x1
attr MB_SBS25 obj-h30843-reading BatterieStrom_DC__A
attr MB_SBS25 obj-h30843-type S32F3
attr MB_SBS25 obj-h30845-name SBS25_BatterieLadezustand_%
attr MB_SBS25 obj-h30845-polldelay x5
attr MB_SBS25 obj-h30845-reading BatterieLadezustand_%
attr MB_SBS25 obj-h30845-unpack N
attr MB_SBS25 obj-h30847-name SBS25_BatterieKapazitaetaktuell_%
attr MB_SBS25 obj-h30847-polldelay x5
attr MB_SBS25 obj-h30847-reading BatterieKapazitaetaktuell_%
attr MB_SBS25 obj-h30847-unpack i>
attr MB_SBS25 obj-h30849-name SBS25_BatterieTemperatur_C
attr MB_SBS25 obj-h30849-polldelay x13
attr MB_SBS25 obj-h30849-reading BatterieTemperatur_C
attr MB_SBS25 obj-h30849-type S32TEMP
attr MB_SBS25 obj-h30851-expr ($val  & 0xFFFF) / 100
attr MB_SBS25 obj-h30851-format %.2f
attr MB_SBS25 obj-h30851-name SBS25_BatterieSpannung_V
attr MB_SBS25 obj-h30851-polldelay x7
attr MB_SBS25 obj-h30851-reading BatterieSpannung_V
attr MB_SBS25 obj-h30851-type U32F2
attr MB_SBS25 obj-h30865-format %.2f
attr MB_SBS25 obj-h30865-name SBS25_Grid_Bezug_W
attr MB_SBS25 obj-h30865-poll 1
attr MB_SBS25 obj-h30865-polldelay x3
attr MB_SBS25 obj-h30865-reading Grid_Bezug_W
attr MB_SBS25 obj-h30865-type U32F2
attr MB_SBS25 obj-h30867-format %.2f
attr MB_SBS25 obj-h30867-name SBS25_Grid_Einspeisung_W
attr MB_SBS25 obj-h30867-poll 1
attr MB_SBS25 obj-h30867-polldelay x3
attr MB_SBS25 obj-h30867-reading Grid_Einspeisung_W
attr MB_SBS25 obj-h30867-type U32F2
attr MB_SBS25 obj-h30953-name SBS25_WR_Temperatur_C
attr MB_SBS25 obj-h30953-polldelay x13
attr MB_SBS25 obj-h30953-reading WR_Temperatur_C
attr MB_SBS25 obj-h30953-type S32TEMP
attr MB_SBS25 obj-h30955-map 16777213:Fehler, 303:Aus, 2291:standby, 2292:laden, 2293:entladen
attr MB_SBS25 obj-h30955-name SBS25_BatterieStatus
attr MB_SBS25 obj-h30955-reading BatterieStatus
attr MB_SBS25 obj-h30957-expr ($val  & 0xFFFF) / 1000
attr MB_SBS25 obj-h30957-format %.3f
attr MB_SBS25 obj-h30957-name SBS25_DC_Strom_2_A
attr MB_SBS25 obj-h30957-poll 0
attr MB_SBS25 obj-h30957-reading DC_Strom_2_A
attr MB_SBS25 obj-h30959-expr ($val  & 0xFFFF) / 100
attr MB_SBS25 obj-h30959-format %.2f
attr MB_SBS25 obj-h30959-name SBS25_DC_Spannung_2_V
attr MB_SBS25 obj-h30959-poll 0
attr MB_SBS25 obj-h30959-reading DC_Spannung_2_V
attr MB_SBS25 obj-h30961-name SBS25_DC_Leistung_2_W
attr MB_SBS25 obj-h30961-poll 0
attr MB_SBS25 obj-h30961-polldelay x1
attr MB_SBS25 obj-h30961-reading DC_Leistung_2_W
attr MB_SBS25 obj-h30977-expr ($val & 0xFFFF) / 1000
attr MB_SBS25 obj-h30977-len 2
attr MB_SBS25 obj-h30977-name SBS25_GridMs.A.phsA
attr MB_SBS25 obj-h30977-poll 0
attr MB_SBS25 obj-h30977-polldelay x1
attr MB_SBS25 obj-h30977-reading BatterieStrom_AC_Phase_L1_A
attr MB_SBS25 obj-h30977-type S32F3
attr MB_SBS25 obj-h30979-expr ($val & 0xFFFF) / 1000
attr MB_SBS25 obj-h30979-len 2
attr MB_SBS25 obj-h30979-name SBS25_GridMs.A.phsB
attr MB_SBS25 obj-h30979-poll 1
attr MB_SBS25 obj-h30979-polldelay x1
attr MB_SBS25 obj-h30979-reading BatterieStrom_AC_Phase_L2_A
attr MB_SBS25 obj-h30979-type S32F3
attr MB_SBS25 obj-h30981-expr ($val & 0xFFFF) / 1000
attr MB_SBS25 obj-h30981-len 2
attr MB_SBS25 obj-h30981-name SBS25_GridMs.A.phsC
attr MB_SBS25 obj-h30981-poll 0
attr MB_SBS25 obj-h30981-polldelay x1
attr MB_SBS25 obj-h30981-reading BatterieStrom_AC_Phase_L3_A
attr MB_SBS25 obj-h30981-type S32F3
attr MB_SBS25 obj-h31377-expr ($val & 0xFFFFFFFF)
attr MB_SBS25 obj-h31377-format %.f
attr MB_SBS25 obj-h31377-len 2
attr MB_SBS25 obj-h31377-name SBS25_Nameplate.Bat.Vendor
attr MB_SBS25 obj-h31377-poll once
attr MB_SBS25 obj-h31377-reading TTTNameplate.Bat.Vendor
attr MB_SBS25 obj-h31377-unpack N
attr MB_SBS25 obj-h31379-expr $val / 1
attr MB_SBS25 obj-h31379-format %.f
attr MB_SBS25 obj-h31379-len 2
attr MB_SBS25 obj-h31379-name SBS25_Nameplate.CmpBMS.Typ
attr MB_SBS25 obj-h31379-poll 1
attr MB_SBS25 obj-h31379-polldelay x5
attr MB_SBS25 obj-h31379-reading TTTNameplate.CmpBMS.Typ
attr MB_SBS25 obj-h31379-unpack N
attr MB_SBS25 obj-h31393-name SBS25_BatterieLadeleistung_W
attr MB_SBS25 obj-h31393-poll 1
attr MB_SBS25 obj-h31393-polldelay x2
attr MB_SBS25 obj-h31393-reading BatterieLadeleistung_W
attr MB_SBS25 obj-h31395-name SBS25_BatterieEntladeleistung_W
attr MB_SBS25 obj-h31395-poll 1
attr MB_SBS25 obj-h31395-polldelay x2
attr MB_SBS25 obj-h31395-reading BatterieEntladeleistung_W
attr MB_SBS25 obj-h31397-expr $val & 0xFFFFFFFFFFFFFFFF
attr MB_SBS25 obj-h31397-len 4
attr MB_SBS25 obj-h31397-name SBS25_BatterieLadungGesamt_Wh
attr MB_SBS25 obj-h31397-poll 1
attr MB_SBS25 obj-h31397-polldelay x2
attr MB_SBS25 obj-h31397-reading BatterieLadungGesamt_Wh
attr MB_SBS25 obj-h31397-unpack Q>
attr MB_SBS25 obj-h31401-expr $val & 0xFFFFFFFFFFFFFFFF
attr MB_SBS25 obj-h31401-len 4
attr MB_SBS25 obj-h31401-name SBS25_BatterieEntladungGesamt_Wh
attr MB_SBS25 obj-h31401-poll 1
attr MB_SBS25 obj-h31401-polldelay x2
attr MB_SBS25 obj-h31401-reading BatterieEntladungGesamt_Wh
attr MB_SBS25 obj-h31401-unpack Q>
attr MB_SBS25 obj-h34113-expr $val / 10
attr MB_SBS25 obj-h34113-name SBS25_WR_Innentemperatur_C
attr MB_SBS25 obj-h34113-poll 1
attr MB_SBS25 obj-h34113-polldelay x13
attr MB_SBS25 obj-h34113-reading WR_Innentemperatur_C
attr MB_SBS25 obj-h34113-type S32TEMP
attr MB_SBS25 obj-h40073-expr $val
attr MB_SBS25 obj-h40073-len 2
attr MB_SBS25 obj-h40073-name SBS25_BatterieUntereEntladegrenze_%
attr MB_SBS25 obj-h40073-poll 1
attr MB_SBS25 obj-h40073-polldelay x10
attr MB_SBS25 obj-h40073-reading BatterieUntereEntladegrenze_%
attr MB_SBS25 obj-h40149-expr $val
attr MB_SBS25 obj-h40149-len 2
attr MB_SBS25 obj-h40149-name SBS25_Set_Leistung_W
attr MB_SBS25 obj-h40149-poll once
attr MB_SBS25 obj-h40149-reading Set_Leistung_W
attr MB_SBS25 obj-h40149-set 1
attr MB_SBS25 obj-h40149-unpack I>
attr MB_SBS25 obj-h40151-expr $val
attr MB_SBS25 obj-h40151-name SBS25_Set_Aktiv
attr MB_SBS25 obj-h40151-poll once
attr MB_SBS25 obj-h40151-reading Set_Aktiv
attr MB_SBS25 obj-h40151-set 1
attr MB_SBS25 obj-h40187-expr $val
attr MB_SBS25 obj-h40187-name SBS25_BatterieNennkapazitaet_Wh
attr MB_SBS25 obj-h40187-poll once
attr MB_SBS25 obj-h40187-reading BatterieNennkapazitaet_Wh
attr MB_SBS25 obj-h40187-type U32F0
attr MB_SBS25 obj-h40236-expr $val / 1
attr MB_SBS25 obj-h40236-map 303:303Aus (Off), 308:308Ein (On), 1438:1438Automatik (Auto), 2289:2289Batterie laden (BatChaMod), 2290:2290Batterie entladen (BatDschMod), 2424:2424Voreinstellung (Dft), 16777213:16777213Information liegt nicht vor (NaNStt)
attr MB_SBS25 obj-h40236-name SBS25_Set_BMS_Mode
attr MB_SBS25 obj-h40236-poll once
attr MB_SBS25 obj-h40236-reading Set_BMS_Mode
attr MB_SBS25 obj-h40721-expr $val
attr MB_SBS25 obj-h40721-len 2
attr MB_SBS25 obj-h40721-name SBS25_BatterieTiefentladeschutzbereichMinimaleBreite_%
attr MB_SBS25 obj-h40721-poll once
attr MB_SBS25 obj-h40721-reading BatterieTiefentladeschutzbereichMinimaleBreite_%
attr MB_SBS25 obj-h40781-expr $val
attr MB_SBS25 obj-h40781-len 2
attr MB_SBS25 obj-h40781-name SBS25_Set_Netzaustauschleistung_W
attr MB_SBS25 obj-h40781-poll once
attr MB_SBS25 obj-h40781-reading Set_Netzaustauschleistung_W
attr MB_SBS25 obj-h40781-set 1
attr MB_SBS25 obj-h40793-expr $val
attr MB_SBS25 obj-h40793-len 2
attr MB_SBS25 obj-h40793-name SBS25_Set_LadeP_min_W
attr MB_SBS25 obj-h40793-poll once
attr MB_SBS25 obj-h40793-reading Set_LadeP_min_W
attr MB_SBS25 obj-h40793-set 1
attr MB_SBS25 obj-h40793-type U32F0
attr MB_SBS25 obj-h40795-expr $val
attr MB_SBS25 obj-h40795-len 2
attr MB_SBS25 obj-h40795-name SBS25_Set_LadeP_max_W
attr MB_SBS25 obj-h40795-poll once
attr MB_SBS25 obj-h40795-reading Set_LadeP_max_W
attr MB_SBS25 obj-h40795-set 1
attr MB_SBS25 obj-h40795-type U32F0
attr MB_SBS25 obj-h40797-expr $val
attr MB_SBS25 obj-h40797-len 2
attr MB_SBS25 obj-h40797-name SBS25_Set_EntladeP_min_W
attr MB_SBS25 obj-h40797-poll once
attr MB_SBS25 obj-h40797-reading Set_EntladeP_min_W
attr MB_SBS25 obj-h40797-set 1
attr MB_SBS25 obj-h40797-type U32F0
attr MB_SBS25 obj-h40799-expr $val
attr MB_SBS25 obj-h40799-len 2
attr MB_SBS25 obj-h40799-name SBS25_Set_EntladeP_max_W
attr MB_SBS25 obj-h40799-poll once
attr MB_SBS25 obj-h40799-reading Set_EntladeP_max_W
attr MB_SBS25 obj-h40799-set 1
attr MB_SBS25 obj-h40801-expr $val
attr MB_SBS25 obj-h40801-len 2
attr MB_SBS25 obj-h40801-name SBS25_Set_Sollwert_Netzaustauschleistung_W
attr MB_SBS25 obj-h40801-poll once
attr MB_SBS25 obj-h40801-reading Set_Sollwert_Netzaustauschleistung_W
attr MB_SBS25 obj-h40801-set 1
attr MB_SBS25 obj-h40801-type S32F0
attr MB_SBS25 obj-h44431-expr $val
attr MB_SBS25 obj-h44431-len 2
attr MB_SBS25 obj-h44431-name SBS25_TTTBatterie_Ladeleistung_Minimal
attr MB_SBS25 obj-h44431-poll 1
attr MB_SBS25 obj-h44431-polldelay x5
attr MB_SBS25 obj-h44431-reading TTTBatterie_Ladeleistung_Minimal
attr MB_SBS25 obj-h44431-type U32F0
attr MB_SBS25 obj-h44433-expr $val
attr MB_SBS25 obj-h44433-len 2
attr MB_SBS25 obj-h44433-name SBS25_TTTBatterie_Ladeleistung_Maximal
attr MB_SBS25 obj-h44433-poll 1
attr MB_SBS25 obj-h44433-polldelay x5
attr MB_SBS25 obj-h44433-reading TTTBatterie_Ladeleistung_Maximal
attr MB_SBS25 obj-h44433-type U32F0
attr MB_SBS25 obj-h44435-expr $val
attr MB_SBS25 obj-h44435-len 2
attr MB_SBS25 obj-h44435-name SBS25_TTTBatterie_Entladeleistung_Minimal
attr MB_SBS25 obj-h44435-poll 1
attr MB_SBS25 obj-h44435-polldelay x5
attr MB_SBS25 obj-h44435-reading TTTBatterie_Entladeleistung_Minimal
attr MB_SBS25 obj-h44435-type U32F0
attr MB_SBS25 obj-h44437-expr $val
attr MB_SBS25 obj-h44437-len 2
attr MB_SBS25 obj-h44437-name SBS25_TTTBatterie_Entladeleistung_Maximal
attr MB_SBS25 obj-h44437-poll 1
attr MB_SBS25 obj-h44437-polldelay x5
attr MB_SBS25 obj-h44437-reading TTTBatterie_Entladeleistung_Maximal
attr MB_SBS25 obj-h44437-type U32F0
attr MB_SBS25 obj-h44439-expr $val
attr MB_SBS25 obj-h44439-len 2
attr MB_SBS25 obj-h44439-name SBS25_TTTNetzaustauschleistung_Sollwert
attr MB_SBS25 obj-h44439-poll 1
attr MB_SBS25 obj-h44439-polldelay x5
attr MB_SBS25 obj-h44439-reading TTTNetzaustauschleistung_Sollwert
attr MB_SBS25 obj-h44439-type S32F0
attr MB_SBS25 room 011_MODBUS
attr MB_SBS25 verbose 2

setstate MB_SBS25 opened
setstate MB_SBS25 2023-10-12 17:06:53 BatterieEntladeleistung_W 146
setstate MB_SBS25 2023-10-12 17:06:59 BatterieEntladungGesamt_Wh 5041633
setstate MB_SBS25 2023-10-12 17:06:58 BatterieEntladungTag_Wh 4874
setstate MB_SBS25 2023-10-12 17:06:48 BatterieKapazitaetaktuell_% 95
setstate MB_SBS25 2023-10-12 17:06:53 BatterieLadeleistung_W 0
setstate MB_SBS25 2023-10-12 17:06:48 BatterieLadezustand_% 16
setstate MB_SBS25 2023-10-12 17:06:53 BatterieLadungGesamt_Wh 7032543
setstate MB_SBS25 2023-10-12 17:06:48 BatterieLadungTag_Wh 1075
setstate MB_SBS25 2023-10-11 21:48:06 BatterieNennkapazitaet_Wh 9800
setstate MB_SBS25 2023-10-12 17:06:38 BatterieSpannung_V 458.97
setstate MB_SBS25 2023-10-12 17:07:02 BatterieStatus entladen
setstate MB_SBS25 2023-10-12 17:06:58 BatterieStrom_AC_Phase_L2_A 0.759
setstate MB_SBS25 2023-10-12 17:06:58 BatterieStrom_DC__A 0.388
setstate MB_SBS25 2023-10-12 17:06:08 BatterieTemperatur_C 22.10
setstate MB_SBS25 2023-10-11 21:48:06 BatterieTiefentladeschutzbereichMinimaleBreite_% 3
setstate MB_SBS25 2023-10-12 17:06:18 BatterieUntereEntladegrenze_% 10
setstate MB_SBS25 2023-10-12 17:06:58 Grid_Bezug_W 0.00
setstate MB_SBS25 2023-10-12 17:06:58 Grid_Einspeisung_W 0.00
setstate MB_SBS25 2023-10-12 17:06:38 NetzEMEinspeisungGesamt_Wh 1074888
setstate MB_SBS25 2023-10-12 17:06:57 Netzrelais geschlossen
setstate MB_SBS25 2023-10-11 21:48:05 Set_Aktiv 16777213
setstate MB_SBS25 2023-10-11 21:48:06 Set_BMS_Mode 16777213Information liegt nicht vor (NaNStt)
setstate MB_SBS25 2023-10-11 21:48:07 Set_EntladeP_max_W 4294967295
setstate MB_SBS25 2023-10-11 21:48:06 Set_EntladeP_min_W 4294967295
setstate MB_SBS25 2023-10-11 21:48:06 Set_LadeP_max_W 4294967295
setstate MB_SBS25 2023-10-11 21:48:06 Set_LadeP_min_W 4294967295
setstate MB_SBS25 2023-10-11 21:48:05 Set_Leistung_W 2147483648
setstate MB_SBS25 2023-10-11 21:48:06 Set_Netzaustauschleistung_W 2147483648
setstate MB_SBS25 2023-10-11 21:48:07 Set_Sollwert_Netzaustauschleistung_W -2147483648
setstate MB_SBS25 2023-10-12 17:07:07 StatusWR OK
setstate MB_SBS25 2023-10-12 17:07:02 TTTBatterie_Backup-Modus  Netzbetrieb (ModGri)
setstate MB_SBS25 2023-10-12 17:06:59 TTTBatterie_Entladeleistung_Maximal 4294967295
setstate MB_SBS25 2023-10-12 17:06:59 TTTBatterie_Entladeleistung_Minimal 4294967295
setstate MB_SBS25 2023-10-12 17:06:59 TTTBatterie_Ladeleistung_Maximal 4294967295
setstate MB_SBS25 2023-10-12 17:06:39 TTTBatterie_Ladeleistung_Minimal 4294967295
setstate MB_SBS25 2023-10-11 21:48:04 TTTNameplate.Bat.Vendor 2340
setstate MB_SBS25 2023-10-12 17:06:58 TTTNameplate.CmpBMS.Typ 8610
setstate MB_SBS25 2023-10-11 21:47:56 TTTNameplate.MainModel 8007
setstate MB_SBS25 2023-10-11 21:47:56 TTTNameplate.Model 9326
setstate MB_SBS25 2023-10-11 21:47:55 TTTNameplate.SerNum 19XXXXXXXXXX
setstate MB_SBS25 2023-10-11 21:47:55 TTTNameplate.SusyId XXX
setstate MB_SBS25 2023-10-12 17:06:39 TTTNetzaustauschleistung_Sollwert -2147483648
setstate MB_SBS25 2023-10-12 17:06:57 UserAction none
setstate MB_SBS25 2023-10-12 17:06:28 WR_Innentemperatur_C 43.70
setstate MB_SBS25 2023-10-12 17:06:58 WR_Temperatur_C 43.70
setstate MB_SBS25 2023-10-12 17:06:48 Wirkleistung_W 143
setstate MB_SBS25 2023-10-11 21:47:55 state opened


Vielleicht hat ja jemand schon das nötige Wissen dazu und hilft !?!

Gruß
300P

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Bernd0066 am 27 Oktober 2023, 18:55:50
SDM220
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: sukram am 29 Oktober 2023, 21:20:25
Nachdem ich jetzt die Stromzähler (nach eingen Jahren ::) ) im Produktiveinsatz habe, gibt es mal noch ein Update zu der zugehörigen Registerdefinition.

Die folgende ist der alte Stand:

Zitat von: sukram am 31 Mai 2020, 14:39:11Saia ALE3 Modbus Stromzähler

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


Das hier ist der erprobte und fehlerbereinigte aktuelle Stand:

define MBZaehler03 ModbusAttr 3 30
attr MBZaehler03 IODev ModbusLineS1
attr MBZaehler03 alignTime 00:00:15
attr MBZaehler03 comment Modbus Register für Saia ALE3 Stromzähler\
\
Einschraenkungen:\
- nur alle 10sek neue Daten\
- max 20 Register auf einmal lesbar\
\
Subtotal 1+2 lassen sich mit 0 schreiben zurücksetzen\
\
Tarifumschaltung (Total 1/2, Subtotal 1/2) über 230V Schalteingang am Gerät\
\
Modbusaddresse lässt sich über schreiben auf das Adressregister neu setzen\
\
Verwendete Datentypen:\
Num10 - unsigned Integer (16 Bit), umgerechnet mit 1 Nachkommastelle\
Num100 - unsigned Integer (16 Bit), umgerechnet mit 2 Nachkommastellen\
dint - unsigned Integer (32 Bit) big Endian\
sint - signed Integer (16 Bit) big Endian, umgerechnet mit 2 Nachkommastellen\

attr MBZaehler03 dev-h-combine 19
attr MBZaehler03 dev-type-Num10-expr $val/10
attr MBZaehler03 dev-type-Num100-expr $val/100
attr MBZaehler03 dev-type-Total-expr $val/100
attr MBZaehler03 dev-type-Total-len 2
attr MBZaehler03 dev-type-dint-expr $val/100
attr MBZaehler03 dev-type-dint-len 2
attr MBZaehler03 dev-type-dint-unpack N
attr MBZaehler03 dev-type-sdint-expr $val/100
attr MBZaehler03 dev-type-sdint-len 1
attr MBZaehler03 dev-type-sdint-unpack s
attr MBZaehler03 dev-type-sint-expr $val/100
attr MBZaehler03 dev-type-sint-unpack s>
attr MBZaehler03 obj-h00-reading Firmwareversion
attr MBZaehler03 obj-h01-reading Registercount
attr MBZaehler03 obj-h02-reading Flagcount
attr MBZaehler03 obj-h03-reading Baudrate
attr MBZaehler03 obj-h03-type dint
attr MBZaehler03 obj-h06-len 8
attr MBZaehler03 obj-h06-reading Type
attr MBZaehler03 obj-h06-unpack a*
attr MBZaehler03 obj-h14-reading Hardwareversion
attr MBZaehler03 obj-h15-reading Serialnumber
attr MBZaehler03 obj-h15-type dint
attr MBZaehler03 obj-h21-reading Status
attr MBZaehler03 obj-h22-reading Modbustimeout
attr MBZaehler03 obj-h23-reading ModbusAddress
attr MBZaehler03 obj-h24-poll 1
attr MBZaehler03 obj-h24-reading Error
attr MBZaehler03 obj-h26-poll 1
attr MBZaehler03 obj-h26-reading Tarif
attr MBZaehler03 obj-h27-poll 1
attr MBZaehler03 obj-h27-reading Total1
attr MBZaehler03 obj-h27-type dint
attr MBZaehler03 obj-h29-poll 1
attr MBZaehler03 obj-h29-reading Subtotal1
attr MBZaehler03 obj-h29-set 1
attr MBZaehler03 obj-h29-type dint
attr MBZaehler03 obj-h31-reading Total2
attr MBZaehler03 obj-h31-type dint
attr MBZaehler03 obj-h33-reading Subtotal2
attr MBZaehler03 obj-h33-type dint
attr MBZaehler03 obj-h35-poll 1
attr MBZaehler03 obj-h35-reading Urms_L1
attr MBZaehler03 obj-h36-poll 1
attr MBZaehler03 obj-h36-reading Irms_L1
attr MBZaehler03 obj-h36-type Num10
attr MBZaehler03 obj-h37-poll 1
attr MBZaehler03 obj-h37-reading Prms_L1
attr MBZaehler03 obj-h37-type Num100
attr MBZaehler03 obj-h38-poll 1
attr MBZaehler03 obj-h38-reading Qrms_L1
attr MBZaehler03 obj-h38-type sint
attr MBZaehler03 obj-h39-poll 1
attr MBZaehler03 obj-h39-reading CosPhi_L1
attr MBZaehler03 obj-h39-type Num100
attr MBZaehler03 obj-h40-poll 1
attr MBZaehler03 obj-h40-reading Urms_L2
attr MBZaehler03 obj-h41-poll 1
attr MBZaehler03 obj-h41-reading Irms_L2
attr MBZaehler03 obj-h41-type Num10
attr MBZaehler03 obj-h42-poll 1
attr MBZaehler03 obj-h42-reading Prms_L2
attr MBZaehler03 obj-h42-type Num100
attr MBZaehler03 obj-h43-poll 1
attr MBZaehler03 obj-h43-reading Qrms_L2
attr MBZaehler03 obj-h43-type sint
attr MBZaehler03 obj-h44-poll 1
attr MBZaehler03 obj-h44-reading CosPhi_L2
attr MBZaehler03 obj-h44-type Num100
attr MBZaehler03 obj-h45-poll 1
attr MBZaehler03 obj-h45-reading Urms_L3
attr MBZaehler03 obj-h46-poll 1
attr MBZaehler03 obj-h46-reading Irms_L3
attr MBZaehler03 obj-h46-type Num10
attr MBZaehler03 obj-h47-poll 1
attr MBZaehler03 obj-h47-reading Prms_L3
attr MBZaehler03 obj-h47-type Num100
attr MBZaehler03 obj-h48-poll 1
attr MBZaehler03 obj-h48-reading Qrms_L3
attr MBZaehler03 obj-h48-type sint
attr MBZaehler03 obj-h49-poll 1
attr MBZaehler03 obj-h49-reading CosPhi_L3
attr MBZaehler03 obj-h49-type Num100
attr MBZaehler03 obj-h50-poll 1
attr MBZaehler03 obj-h50-reading Prms_total
attr MBZaehler03 obj-h50-type Num100
attr MBZaehler03 obj-h51-poll 1
attr MBZaehler03 obj-h51-reading Qrms_total
attr MBZaehler03 obj-h51-type sint
attr MBZaehler03 room Geraete
attr MBZaehler03 stateFormat <b>Summe:</b> Total1 kWh <b>Aktuell:</b> Prms_total kW Qrms_total kvar\
<br /><b>L1</b> Urms_L1 V Irms_L1 A Prms_L1 kW Qrms_L1 kvar Cos Phi CosPhi_L1\
<br /><b>L2</b> Urms_L2 V Irms_L2 A Prms_L2 kW Qrms_L2 kvar Cos Phi CosPhi_L2\
<br /><b>L3</b> Urms_L3 V Irms_L3 A Prms_L3 kW Qrms_L3 kvar Cos Phi CosPhi_L3


Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Marlon am 05 November 2023, 13:18:24
Hallo Stefan,

im Forum habe ich Timeout nur im Zusammenhang mit Fehlern gefunden.
Im Gegensatz dazu würde ich bei Auftreten eines Timeouts gerne eine Funktion ausführen.

Normalerweise wird mein Deye-Wechselrichter mit ModbusAttr minütlich abgefragt und dann ausgewertet mit:
defmod DeyeMacro notify Mod_Deye:PV4_Leistung_W:.* {appendDeye()}Bei leerer Batterie ohne Sonne deaktiviere ich den Wechselrichter normalerweise, um Energie zu sparen.
Dann gibt es natürlich bei den minütlichen Polls des ModbusAttr timeouts.
Nun würde ich gerne bei Auftreten der Timeouts eine alternative Funktion ausführen, mit der ich z.B. den Betriebszustand "Deaktiviert" detektieren kann.

Zunächst hatte ich dafür folgendes vorgesehen:
defmod DeyeTimeout notify <pattern> {appendDeyeTimeout()}
Allerdings konnte ich nirgends finden, welcher Event bei einem Timout von ModbusAttr ausgeführt wird.
Einen Event muss es ja geben, der auch zum Eintrag des Timeouts ins Log dient.
Was müsste man hier also bei <pattern> einsetzen?

Alternativ hatte ich folgendes mit watchdog vorgesehen:
define DeyeDog watchdog <regexp1> 00:01:05 Mod_Deye:PV4_Leistung_W:.* {appendDeyeTimeout()}Allerdings konnte ich auch nirgends finden, welcher Event beim Pollen von ModbusAttr generiert wird.
Was müsste man hier also bei <regexp1> einsetzen?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: kaiman am 05 November 2023, 16:04:26
Hallo zusammen,
Ich habe eine Frage:

Ich habe zwei PE11 Modbus LAN Adapter und jeweils einen Zähler angeschlossen, jeweils SDM72D-M.

Kann ich die Zählerstände und den aktuellen Verbrauch mit dem Modul in FHEM anzeigen? Gibt es dazu eine Anleitung? Dieser Thread ist schon ziemlich lang geworden.

Beide Zähler werden aktuell von einer openWB schon ausgewertet, ich würde die Zählerstände aber zusätzlich noch in FHEM sehen.

LG Kaiman
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 November 2023, 17:02:42
Hallo Marlon,

es gibt z.B. das Attribut showError. Wenn das auf dem physischen Device auf 1 steht, dann wird im Fehlerfall und auch bei Timouts ein Reading und Event mit Namen LAST_ERROR" erzeugt.

Gruß
    Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 05 November 2023, 17:11:59
Hallo kaiman,

Hilft das:
https://forum.fhem.de/index.php?topic=128695.0

Gruß
    Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Marlon am 05 November 2023, 22:37:33
Zitat von: StefanStrobel am 05 November 2023, 17:02:42es gibt z.B. das Attribut showError. Wenn das auf dem physischen Device auf 1 steht, dann wird im Fehlerfall und auch bei Timouts ein Reading und Event mit Namen LAST_ERROR" erzeugt.
Hallo Stefan,
danke für den Hinweis. Nach update auf FHEM 6.2 gab es bei mir auch das Attribut showError.
Allerdings ist dies nicht in der Modbus-Hilfe beschrieben.
Mit diesem notify wird nun die gewünschte Funktion aufgerufen:
defmod DeyeTimeout notify Modbus_Deye:LAST_ERROR:.* {appendDeyeTimeout()}
attr DeyeTimeout disabledAfterTrigger 30
Kann man mit LAST_ERROR auch auf bestimmte Readings filtern bzw. wie geht das?
Da die Abfrage aller Readings in 8 Blöcke aufgeteilt wird, gibt es 8 Timeout-Events in 2-Sekunden-Abständen.
Lieber wäre mir, wenn man statt disabledAfterTrigger von vornherein nur auf den Timeout des ersten Blocks ab h500 filtern könnte.
Ohne Filterung sieht das im Logging so aus:
2023.11.05 22:00:02 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h500, len 20, master device Mod_Deye, reading Deye_Betriebszustand (getUpdate for combined h500 len 1 Deye_Betriebszustand with h503 len 1 Grid_Tagesverbindungszeit_s and h514 len 1 Batt_Tagesladung_kWh and h515 len 1 Batt_Tagesentladung_kWh and h516 len 2 Batt_Gesamtladung_kWh and h518 len 2 Batt_Gesamtentladung_kWh), queued 2.01 secs ago, sent 2.00 secs ago
2023.11.05 22:00:02 3: DeyeTimeout return value: <xml><exec>/GET /x.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: fhem</httpUserAgent><antwort>true</antwort></xml>
2023.11.05 22:00:04 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h520, len 16, master device Mod_Deye, reading Netz_Tagesbezug_kWh (getUpdate for combined h520 len 1 Netz_Tagesbezug_kWh with h521 len 1 Netz_Tageseinspeisung_kWh and h522 len 2 Netz_Gesamtbezug_kWh and h524 len 2 Netz_Gesamteinspeisung_kWh and h525 len 1 Load_Tagesverbrauch_kWh and h526 len 2 Load_Gesamtverbrauch_kWh and h529 len 1 PV_Tagesertrag_kWh and h534 len 2 PV_Gesamtertrag_kWh), queued 4.03 secs ago, sent 2.00 secs ago
2023.11.05 22:00:04 3: DeyeTimeout return value: <xml><exec>/GET /x.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: fhem</httpUserAgent><antwort>true</antwort></xml>
2023.11.05 22:00:06 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h541, len 12, master device Mod_Deye, reading Deye_Kuehlkoerpertemperatur (getUpdate for combined h541 len 1 Deye_Kuehlkoerpertemperatur with h550 len 1 Deye_LCD_Test_Flag and h551 len 1 Deye_Schalterstatus and h552 len 1 Deye_Relaisstatus), queued 6.05 secs ago, sent 2.00 secs ago
2023.11.05 22:00:06 3: DeyeTimeout return value: <xml><exec>/GET /x.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: fhem</httpUserAgent><antwort>true</antwort></xml>
2023.11.05 22:00:08 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h586, len 20, master device Mod_Deye, reading Batt_Temperatur (getUpdate for combined h586 len 1 Batt_Temperatur with h587 len 1 Batt_Spannung_V and h588 len 1 Batt_SOC and h590 len 1 Batt_Leistung_W and h591 len 1 Batt_Strom_A and h592 len 1 Batt_Kap_korrigiert_Ah and h604 len 1 Grid_L1_Leistung_W and h605 len 1 Grid_L2_Leistung_W), queued 8.07 secs ago, sent 2.00 secs ago
2023.11.05 22:00:08 3: DeyeTimeout return value: <xml><exec>/GET /x.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: fhem</httpUserAgent><antwort>true</antwort></xml>
2023.11.05 22:00:10 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h606, len 20, master device Mod_Deye, reading Grid_L3_Leistung_W (getUpdate for combined h606 len 1 Grid_L3_Leistung_W with h607 len 1 Grid_Wirkleistung_W and h616 len 1 Netz_L1_Leistung_W and h617 len 1 Netz_L2_Leistung_W and h618 len 1 Netz_L3_Leistung_W and h619 len 1 Netz_Wirkleistung_W and h622 len 1 GN_L1_Leistung_W and h623 len 1 GN_L2_Leistung_W and h624 len 1 GN_L3_Leistung_W and h625 len 1 GN_Wirkleistung_W), queued 10.10 secs ago, sent 2.00 secs ago
2023.11.05 22:00:10 3: DeyeTimeout return value: <xml><exec>/GET /x.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: fhem</httpUserAgent><antwort>true</antwort></xml>
2023.11.05 22:00:12 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h633, len 20, master device Mod_Deye, reading Deye_L1_Leistung_W (getUpdate for combined h633 len 1 Deye_L1_Leistung_W with h634 len 1 Deye_L2_Leistung_W and h635 len 1 Deye_L3_Leistung_W and h636 len 1 Deye_Wirkleistung_W and h640 len 1 USV_L1_Leistung_W and h641 len 1 USV_L2_Leistung_W and h642 len 1 USV_L3_Leistung_W and h643 len 1 USV_Leistung_W and h650 len 1 Load_L1_Leistung_W and h651 len 1 Load_L2_Leistung_W and h652 len 1 Load_L3_Leistung_W), queued 12.13 secs ago, sent 2.00 secs ago
2023.11.05 22:00:12 3: DeyeTimeout return value: <xml><exec>/GET /x.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: fhem</httpUserAgent><antwort>true</antwort></xml>
2023.11.05 22:00:14 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h653, len 20, master device Mod_Deye, reading Load_Wirkleistung_W (getUpdate for combined h653 len 1 Load_Wirkleistung_W with h654 len 1 Load_Scheinleistung_VA and h664 len 1 Gen_L1_Leistung_W and h665 len 1 Gen_L2_Leistung_W and h666 len 1 Gen_L3_Leistung_W and h667 len 1 Gen_Leistung_W and h672 len 1 PV1_Leistung_W), queued 14.15 secs ago, sent 2.00 secs ago
2023.11.05 22:00:14 3: DeyeTimeout return value: <xml><exec>/GET /x.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: fhem</httpUserAgent><antwort>true</antwort></xml>
2023.11.05 22:00:16 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h673, len 3, master device Mod_Deye, reading PV2_Leistung_W (getUpdate for combined h673 len 1 PV2_Leistung_W with h674 len 1 PV3_Leistung_W and h675 len 1 PV4_Leistung_W), queued 16.18 secs ago, sent 2.00 secs ago
2023.11.05 22:00:16 3: DeyeTimeout return value: <xml><exec>/GET /x.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: fhem</httpUserAgent><antwort>true</antwort></xml>
Gruß
Marlon
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: kaiman am 06 November 2023, 08:35:18
Super vielen Dank!

Habe die Zähler eingebunden bekommen.

Die nächste Nuss wird wohl nicht mit dem Modbus-Modul machbar sein. Ich habe vom Elektriker noch zwei DSZ15DE-3x80A Zähler verbaut bekommen. Diese haben ja nur einen S0 Ausgang. Wenn ich das richtig verstanden habe, bekomme ich bei denen nicht so gut die Werte ausgelesen.

Was ist sinnvoller? Umbau auf die SDM Zähler oder versuchen auszulesen?
Könnte ich bei einem Umbau auf SDM72 Zähler den Zählerstand im SDM72 Zähler anpassen, so dass dieser mit dem gleichen Startwert weiter zählt, oder geht das nicht und ich würde wieder mit 0khw beginnen?

LG

Zitat von: StefanStrobel am 05 November 2023, 17:11:59Hilft das:
https://forum.fhem.de/index.php?topic=128695.0

Gruß
    Stefan

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Nobbynews am 06 November 2023, 09:00:44
Zitat von: kaiman am 06 November 2023, 08:35:18Könnte ich bei einem Umbau auf SDM72 Zähler den Zählerstand im SDM72 Zähler anpassen, so dass dieser mit dem gleichen Startwert weiter zählt, oder geht das nicht und ich würde wieder mit 0khw beginnen?
Die Zählerstände im SDM72 selbst kannst Du nicht verändern.
Allenfalls in fhem über ein userreading und Addition eines Startwertes.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 07 November 2023, 19:13:53
Hallo Marlon,

vermutlich ist es dann am einfachsten das ganze mit dem Modul readingsWatcher zu machen.
Wenn im aktiven Zeitraum definierte Readings länger als x Sekunden nicht aktualisiert werden, dann kannst Du damit reagieren.
ModbusAttr hat bisher kein Feature um bei Timeouts für einzelne Readings einen Event zu erzeugen.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 14 November 2023, 16:32:38
Zitat von: kaiman am 06 November 2023, 08:35:18Die nächste Nuss wird wohl nicht mit dem Modbus-Modul machbar sein. Ich habe vom Elektriker noch zwei DSZ15DE-3x80A Zähler verbaut bekommen. Diese haben ja nur einen S0 Ausgang. Wenn ich das richtig verstanden habe, bekomme ich bei denen nicht so gut die Werte ausgelesen.
Was ist sinnvoller? Umbau auf die SDM Zähler oder versuchen auszulesen?

Das hängt von deinen Bedürfnissen ab: wenn du möglichst "Echtzeitwerte" möchtest und auch weitergehende Infos (Gesamtzählerstand, Spannung etc) wirst du mit S0 nicht so recht glücklich. Für einen Kühlschrank oder sonst irgendeinen voraussagbaren Verbraucher reicht wohl S0 (und ein Arduino Counter um ihn auszulesen).
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holsteiner-kiel am 14 November 2023, 20:11:51
Moin Moin,

Ich hoffe, ich stelle nun keine Frage doppelt, aber dieser thread ist mittlerweile etwas unübersichtlich;)

Ich habe eine tecalor Wärmepumpe und lese per modbusattr erfolgreich Werte aus.

Den Betriebsstatus lese ich per
obj-i02000-reading BETRIEBSSTATUS
aus.

Mit
obj-i02000-unpack B16
bekomme ich als Ergebnis eine bitmaske wie zum Beispiel

0000010000000111

Die letzte 1 steht zum Beispiel für "Schaltprogramm aktiv", die vorletzte für "Verdichter" und so weiter.

Wie kann ich diesen Wert nun in einzelne zerlegen und dann entsprechend zu "Klartext Mappen"?

Die map Funktion kenne und nutze ich. Bin aber unsicher in Bezug auf die "Zerlegung".

Hat jemand eine Idee?

Vielen Dank vorab und viele Grüße aus dem hohen Norden!

Markus
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Marlon am 14 November 2023, 20:44:54
Zitat von: StefanStrobel am 07 November 2023, 19:13:53Hallo Marlon,

vermutlich ist es dann am einfachsten das ganze mit dem Modul readingsWatcher zu machen.
Wenn im aktiven Zeitraum definierte Readings länger als x Sekunden nicht aktualisiert werden, dann kannst Du damit reagieren.
ModbusAttr hat bisher kein Feature um bei Timeouts für einzelne Readings einen Event zu erzeugen.

Gruss
  Stefan
Hallo Stefan,
die Auswertung der Timeouts ist doch komplexer als zunächst gedacht.
Das Problem ist, dass es auch bei eingeschaltetem Wechselrichter ab und zu Timeouts gibt.
Zusätzlich habe ich im LOG bereits zwei Tage gesehen, wo offenbar das Modbus-Modul einmal am Tag das parametrierte minütliche Abfragen der Daten vom Wechselrichter unterlässt. An einer Überlastung des Raspi 4b kann es nicht liegen, da er fast nie mehr als 1 % ausgelastet ist.
Um möglichst schnell das Ausschalten des WR sicher zu detektieren und trotzdem false Positives zuverlässig zu vermeiden, habe ich es nun bei der Auswertung aller Timeouts belassen. Bei LAST_ERROR ruft ein notify eine Perl-Funktion auf, die wiederum ein notify triggert, welches dann weiteres Triggern für 30 s unterbindet.
Die Perl-Funktion triggert das Timeout-notify, wenn seit den letzten vom Wechselrichter empfangenen Daten mehr als 150 s vergangen sind. Zusätzlich triggert sie das Timeout-notify, wenn seit den letzten vom Wechselrichter empfangenen Daten mehr als 30 s vergangen sind und mindestens 15 s der laufenden Minute um sind.
Damit wird erstmals 16 s nach Abfragen des ausgeschalteten Wechselrichters, wenn es für alle acht Datenblöcke LAST_ERROR gab, ein Timeout festgestellt und später immer 2 s nach jeder vollen Minute, solange der WR ausgeschaltet ist. Das ist zwar gefühlt umständlich, aber nach mehr als einer Woche mit zahlreichen Änderungen funktioniert es nun so, wie ich mir das vorgestellt hatte. :)  Danke für die Hilfe.
Gruß
Marlon
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 15 November 2023, 10:36:40
Zitat von: holsteiner-kiel am 14 November 2023, 20:11:51Moin Moin,

Ich hoffe, ich stelle nun keine Frage doppelt, aber dieser thread ist mittlerweile etwas unübersichtlich;)

Ich habe eine tecalor Wärmepumpe und lese per modbusattr erfolgreich Werte aus.

Den Betriebsstatus lese ich per
obj-i02000-reading BETRIEBSSTATUS
aus.

Mit
obj-i02000-unpack B16
bekomme ich als Ergebnis eine bitmaske wie zum Beispiel

0000010000000111

Die letzte 1 steht zum Beispiel für "Schaltprogramm aktiv", die vorletzte für "Verdichter" und so weiter.

Wie kann ich diesen Wert nun in einzelne zerlegen und dann entsprechend zu "Klartext Mappen"?

Die map Funktion kenne und nutze ich. Bin aber unsicher in Bezug auf die "Zerlegung".

Hat jemand eine Idee?

Spontan sehe ich 2 Möglichkeiten: entweder, du interpretierst die Bitmask via ModBusAttr unpack als int etc. Dann bekommst du für jeden möglichen Zustand eine Zahl, die kannst du dann via map auf einen Text mappen. Ist etwas unübersichtlich denke ich da du quasi manuell jeden möglichen Zustand für alle betroffenen Bits durchrechnen müsstest und in map eintragen.
Oder: du machst UserReadings z.B. "Schaltprogramm aktiv" wo du mit Bitwise & alle anderen Bits ausser das letzte ausblendest "$wert & 0000000000000001".

Beides nicht getestet, vielleicht hat jemand noch eine andere Lösung oder eine konkrete Implementation?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holsteiner-kiel am 15 November 2023, 19:35:49
Guter Ansatz!

Vielen Dank dir!

Kleinigkeit fehlt noch zum sauberen Ergebnis:
HEIZEN { ReadingsVal("WP","BETRIEBSSTATUS",0) & 0000000000000100 } ergibt im Reading 64 wenn der Wert für BETRIEBSSTATUS 0000010000000101 ist. Ich denke, er interpretiert das als Zahl und daher kommt das. Evtl. noch eine Idee, wie ich ganz simpel 1 raus bekomme?

Besten Dank!
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: yoda_gh am 15 November 2023, 20:36:43
Zitat von: holsteiner-kiel am 15 November 2023, 19:35:49Kleinigkeit fehlt noch zum sauberen Ergebnis:
HEIZEN { ReadingsVal("WP","BETRIEBSSTATUS",0) & 0000000000000100 } ergibt im Reading 64 wenn der Wert für BETRIEBSSTATUS 0000010000000101 ist. Ich denke, er interpretiert das als Zahl und daher kommt das. Evtl. noch eine Idee, wie ich ganz simpel 1 raus bekomme?

userReading mit Bitmaske wäre auch mein Ansatz gewesen. :-) Zwei Sachen dazu:


Also wenn ich Deine Anforderung richtig verstehe, sollte das folgende hoffentlich funktionieren:

{ (ReadingsVal("WP","BETRIEBSSTATUS",0) & 0b100) >> 2 }
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holsteiner-kiel am 16 November 2023, 07:28:28
Mega! Das funktioniert! Vielen Dank an euch beiden!
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 28 November 2023, 09:47:48
Hallo Stefan,

nach einem fhem-update ist jetz bei mir die Modbus Version vom 7.11. im Einsatz. Jetzt geschehen merkwürdige Dinge:

Screenshot 2023-11-28 at 08-59-09 Home Sweet Home.png

Die meisten Werte sind unsinnig und einfach falsch. Und 40 Sekunden später ist wieder alles ok-Screenshot 2023-11-28 at 08-59-47 Home Sweet Home.png

Ein Blick ins Logfile zeigt auffällig viele Checksum error. Hier ist ein Logfile verbose 5:
modbus-1.log

Sind bei mir jetzt Änderungen erforderlich?

Beste Grüße
Basil


Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Guzzi-Charlie am 29 November 2023, 18:49:55
Ich versuche gerade einen Modbuszähler vom Typ DS100 (B+G E-Tech) einzubinden. Dazu habe ich (wie schonmal erfolgreich praktiziert) das vorhandene Modul für den SDM630-Zähler verwendet und lediglich die Adressen angepaßt. Leider klappt das diesmal so einfach nicht. Das Modul redet wohl mit dem Zähler, aber die Register passen nicht und die Werte sind ebenfalls unplausibel. Irgendwie muß der "DS100"-Zähler ein anderes Datenhandling haben. Ich habe zwar eine Komplettliste der Registerbelegung, aber zu den Abfragebedingungen habe ich keine weiteren Angaben.

Es gibt ein Windows-Tool mit dem man die Daten problemlos auslesen kann. Da kann man auch die gesendeten Hex-Werte (Senden/Empfangen) sehen, aber mir fehlt leider das Wissen um damit etwas anfangen zu können.

DS100 (1).JPGDS100 (2).JPGDS100 (3).JPG   

Das Tool zeigt hier die original Hex-Werte an die gesendet, bzw. empfangen werden.

01 => Geräte-Adresse
04 => Function-Code (Lesen Input Register)
04 00 => Modbus Register-Adresse
00 02 70 FB => ?
Die Werte für L1 und L2 sind "0" weil ich den Zähler zum Testen nur 1-phasig angeschlossen hatte.

Leider kann ich damit nicht wirklich etwas anfangen. Zumindest scheint die Registerbelegung der Tabelle mit der Realität übereinzustimmen.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: appi am 30 November 2023, 19:16:52
Hallo
ich bräuchte bitte etwas Unterstützung bei der Fertigstellung meines Moduls für die Auswertung per Modbus meiner Heliotherm WP. Es funktioniert eigentlich bereits alles ausser der Umsetzung der Leistungsregister welche 32 Bit lang sind:



Ich bekomme mit der folgenden Definition alle Werte welche vom Format "int16*10" sind perfekt decodiert in die Readings:
'i10' => { reading => 'T_Aussen',
              name => 'Temp. Aussen',
              expr => '$val/10',
              format => '%.1f',
              unpack => 's>',
              poll => 1
},
'i11' => { reading => 'T_Brauchwasser',
              name => 'Temp. Brauchwasser',
              expr => '$val/10',
              format => '%.1f',
              unpack => 's>',
              poll => 1
}, .........etc.

Ergibt die Readings mit den korrekten Werten



Nun zu meinen Problem Registern:

Die Registerdefinition vom Hersteller:
Register  z.B.
68 - 69  0x04     uint32    Stromz_Gesamt
 
Ich bekomme mit der folgenden Definition leider nur die ganzen Zahlen richtig angezeigt aber eben ohne Nachkommastellen:

'i68' => { reading => ' Stromz_Gesamt' ',
              name => ' Stromz_Gesamt' ',
              format => '%.1f',
              len        =>  2,         
              unpack => 'I>',
              poll => 1
},

'i66' => { reading => 'Stromz_Brauchwasser,
              name => 'Stromz_Brauchwasser',
              format => '%.1f',
              len        =>  2,         
              unpack => 'I>',
              poll => 1
},

'i62' => { reading => 'Stromz_Heizung,
              name => 'Stromz_Heizung',
              format => '%.1f',
              len        =>  2,         
              unpack => 'I>',
              poll => 1
}, ..........etc.

Ich glaube alle Varianten getestet zu haben und komm einfach nicht dahinter..... wäre froh um eine Hilfestellung

danke und Gruss
Remo

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 01 Dezember 2023, 11:09:03
Zitat von: Guzzi-Charlie am 29 November 2023, 18:49:55Das Tool zeigt hier die original Hex-Werte an die gesendet, bzw. empfangen werden.

01 => Geräte-Adresse
04 => Function-Code (Lesen Input Register)
04 00 => Modbus Register-Adresse
00 02 70 FB => ?
Die Werte für L1 und L2 sind "0" weil ich den Zähler zum Testen nur 1-phasig angeschlossen hatte.

Leider kann ich damit nicht wirklich etwas anfangen. Zumindest scheint die Registerbelegung der Tabelle mit der Realität übereinzustimmen.

Bei Modbus kommst du um ein wenig rumprobieren kaum herum. Solange du nur lesend auf das Device zugreifst richtest du (soweit ich weiss) auch keinen Schaden an. Schau dir mal meine älteren Posts an, ich würde dir unbedingt QModMaster empfehlen: das ist eine kleine Software, die einen Modbus Server nachstellt. Dort kannst du mit den Registern und den zurückgelieferten Werten spielen. Nach 5-10 Minuten ist die Sache meist selbsterklärend und das übertragen nach FHEM nur noch Fleissarbeit. Beachte, dass bei QModMaster die Registeradressen bei 1 beginnen und bei ModBusAttr bei 0.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 01 Dezember 2023, 11:13:29
Zitat von: appi am 30 November 2023, 19:16:52Hallo
ich bräuchte bitte etwas Unterstützung bei der Fertigstellung meines Moduls für die Auswertung per Modbus meiner Heliotherm WP. Es funktioniert eigentlich bereits alles ausser der Umsetzung der Leistungsregister welche 32 Bit lang sind:

Nun zu meinen Problem Registern:

Die Registerdefinition vom Hersteller:
Register  z.B.
68 - 69  0x04     uint32    Stromz_Gesamt
 
Ich bekomme mit der folgenden Definition leider nur die ganzen Zahlen richtig angezeigt aber eben ohne Nachkommastellen:

'i68' => { reading => ' Stromz_Gesamt' ',
              name => ' Stromz_Gesamt' ',
              format => '%.1f',
              len        =>  2,         
              unpack => 'I>',
              poll => 1
},



Ähm, das ist ja ein uint32 gemäss Hersteller und damit (positive) Ganzzahl ohne Nachkomma? Damit ist deine format Definition unsinnig. Wenn der Hersteller hier eine Float Zahl mit einer bestimmten Anzahl Nachkommastellen als int liefert, so macht er das meist mit einer Multiplikation vom Originalwert in 10er Potenzen. Sprich: 1 Nachkommastelle == der int Wert ist 10x grösser. Dann müsstest du - so wie du das bei den anderen Registern ja bereits gemacht hast - expr => '$val/10' verwenden um den tatsächlichen Wert mit 1 Nachkommastelle zu erhalten.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: appi am 01 Dezember 2023, 14:59:43
Besten Dank

1. Tool QModMaster installiert, wirklich gut, danke.
   - zeigt genau die Werte welche ich im Webinterface der WP sehe, ohne Nachkommastellen.....
   - die Readings welche in FHEM gefüllt werden stimmen
   - die Nachkommastellen kann ich auch mit QModMaster nicht finden

Es gibt eine Implementierung für Home Assistant welche funktioniert und dort habe ich den selben Fehler wie bei mir in den Issues gefunden mit der Lösung:
https://github.com/mbuchber/ha_heliotherm/issues/3#issuecomment-1401513640

[line 378] decoder = BinaryPayloadDecoder.fromRegisters(
[line 379] modbusdata2.registers, byteorder=Endian.Big <----changed wordorder to byteorder
[line 380] )

Daraus die Fregestellung:  Wie kann ich im FHEM Modul  entscheiden ob wordorder oder byteorder benutzt werden soll?
   
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 01 Dezember 2023, 17:45:58
Ich habe die Anleitung rasch überflogen. Ich beziehe mich auch auf deinen Screenshot. Die Registergrösse ist z.B. für die Spannung 2, d.h. du musst 2 ModBus Register auslesen. Als Datentype geben sie INT32(3+3) an, ich glaube damit ist gemeint, dass du im ersten Register die Stellen vor- und im 2 Register die Stellen nach dem Komma hast (je 3). Stell doch mal im QModMaster die Registergrösse auf 2 um und schaue, was passiert. Dann geht es nur noch darum, diese beiden Register in FHEM zusammenzustelllen. Das macht man normalerweise mit "len":

Zitatobj-[cdih][0-9]+-len
defines the length of the data object in registers (16 Bits). It defaults to 1.
Some devices store e.g. 32 bit floating point values in two registers. In this case you should set this attribute to two.
This setting is relevant both in master and in slave mode. The lenght has to match the length implied by the unpack code.
Example: attr MBTest obj-h225-len 2

Falls wirklich die Vor- und Nachkommastellen in 2 aufeinanderfolgenden Register verteilt sind wird das etwas kniffelig, das kenne ich so noch nicht. ABER: ModbusAttr ist super mächtig, irgendwie bekommen wir das hin :-)
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 Dezember 2023, 18:26:59
Hallo Aurel_B und appi,

wenn man Readings aus mehreren Registerwerten zusammenbauen muss, dann ist es wichtig, dass die Register gleichzeitig gelesen werden, sonst bekommt man möglicherweise zwei Werte, die gar nicht zusammen gehören. Über die group-Attribute kann man das steuern.

Gruss
    Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 04 Dezember 2023, 18:29:29
Hallo McBasil,

es würde mich wundern, wenn aufgrund eines Fhem-Updates auf einmal Checksum-Fehler kommen. Kannst Du mal auf eine ältere Version zurückgehen um zu verifizieren, ob es wirklich an der Version liegt?
Ist es wirklich das richtige Device und der richtige Adapter, mit denen Du redest?
Wie sieht die Konfiguration aus?

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 12 Dezember 2023, 22:11:13
Hallo zusammen,

gibt es die Möglichkeit einzelne Bits in einem Register zu beschreiben/lesen?

z.B.
attr Data4PLC obj-h30[1]-len 2
attr Data4PLC obj-h30[1]-reading Temperatur_Heizung:DS18B20-3_Temperature
attr Data4PLC obj-h30[1]-unpack n
attr Data4PLC obj-h30[3]-len 2
attr Data4PLC obj-h30[3]-reading Temperatur_Heizung:DS18B20-1_Temperature
attr Data4PLC obj-h30[3]-unpack n

ich habe schon verschiedene Schreibweisen ausprobiert, leider ohne erfolg


MfG Mario
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 12 Dezember 2023, 23:04:07
Hallo Stefan,

sicher hast Du Recht, dass ein Versionswechsel nicht Ursache für die crc-Fehler ist. Es ist wohl mehr so, dass bei mir  normal
verbose auf 1 oder 2 steht und somit diese Fehler nicht protokolliert werden. Und dann fällt mir das natürlich nicht auf. Jetzt war es aber so, dass mit der neuen Version auf einmal jede Menge fehlerhafte Anzeigen erschienen. So wurde mir beispielsweise gleichzeitig angezeigt, dass die Wärmepumpe laufe, aber die Unterwasserpumpe nicht laufe, dass die Warmwassersolltemperatur auf 218 °C eingestellt sei und die Brunneneinlauftemperatur bei 0 °C liege und die Brunnenausgangstemperatur über der Vorlauftemperatur liegt.

Spätestens da setzt man verbose höher und auf einmal werden die Fehler protokolliert und sichtbar.

Jetzt habe ich Ursachenforschung betrieben und die Protokolle ausgewertet. Für mein besseres Verständnis habe ich verschiedene Log-Ausgaben optisch etwas anders aufbereitet. Die Ursache konnte ich ermitteln und beheben. Entscheidend für die Berechnung des CRC-Wertes ist die PDU-Länge. In die Berechnung geht die Anzahl der übermittelten Bytes ein plus 1 für das Längenfeld. In der Funktion   

sub ParseResponse {    wird bei der Berechnung das fcode Byte mitgerechnet und das ist der Auslöser für die fehlerhafte Berechnung.
......
       my ($len, $values) = unpack ('Ca*', $data);
......
       $frame->{PDULEXP}  = $len + 2;                      # 1 Byte fCode + 1 Byte len + len of expected values
muss ersetzt werden durch
       $frame->{PDULEXP}  = $len + 1;                      # 1 Byte len + len of expected values
......
}

Nach dieser Anpassung erfolgt dann die Kontrolle mit der Funktion

sub CheckChecksum {  
....   
    my $data  = $frame->{DATA};
....   
    my $readLen  = length($hash->{READ}{BUFFER});
....   
    if ($proto eq 'RTU') {
        $readLen = length($data);
        my $frLenExp = $frame->{PDULEXP} + $PDUOverhead{$hash->{PROTOCOL}};     # everything including id to crc
        # for RTU Overhead is 3 (id ... 2 Bytes CRC)
        my $crcInputLen = ($readLen < $frLenExp ? $readLen : $frLenExp) + 2;    # PDU plus 2 bytes crc
        my $sent = unpack('v', substr($hash->{READ}{BUFFER}, $crcInputLen, 2));
        my $calc = CRC(substr($hash->{READ}{BUFFER}, 0, $crcInputLen));
        Log3 $name, 4, "$name: CheckChecksum readLen=$readLen, frameLen=$frLenExp (exp $frame->{PDULEXP}, " . 
             "ovr $PDUOverhead{$hash->{PROTOCOL}}), crcdata " . unpack ('H4', pack ('v', $sent)) . " \nBuffer " . ShowBuffer($hash);
....
}      und jetzt werden die CRC fehlerfrei berechnet.

Danach sind die mysteriösen Anzeigen beseitigt, im Protokoll erscheinen keine Fehler mehr und und die Requestquew qlen pendelt sich bei 70 ein.  So ist alles zufriedenstellend.

Beigefügt ist ein Logfile über 6 Minuten und das bei mir aktuell laufende 98_Modbus.pm. 

An dieser Stelle ganz herzlichen Dank für Deine großartige Arbeit.

Beste Grüße
Basil

98_Modbus.pm
fhem-2023-12.log.txt
 
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 13 Dezember 2023, 17:17:53
Zitat von: Mariomgn am 12 Dezember 2023, 22:11:13Hallo zusammen,

gibt es die Möglichkeit einzelne Bits in einem Register zu beschreiben/lesen?

z.B.
attr Data4PLC obj-h30[1]-len 2
attr Data4PLC obj-h30[1]-reading Temperatur_Heizung:DS18B20-3_Temperature
attr Data4PLC obj-h30[1]-unpack n
attr Data4PLC obj-h30[3]-len 2
attr Data4PLC obj-h30[3]-reading Temperatur_Heizung:DS18B20-1_Temperature
attr Data4PLC obj-h30[3]-unpack n

ich habe schon verschiedene Schreibweisen ausprobiert, leider ohne erfolg


MfG Mario

Hallo Mario,

das Modbus-Protokoll sieht dafür so genannte Coils vor. Die kann man Bit für Bit ändern.
Bei Holding-Register kann man nur ein ganzes Register (16 Bit) schreiben.
Wenn sich nur ein Bit eines Holding-Registers ändern soll, dann musst Du das ganze Register erst lesen, ein Bit ändern und dann das ganze Register wieder schreiben.

Gruss
  Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 14 Dezember 2023, 20:56:49
Hallo Stefan,

Ist das so richtig?
attr Data4PLC obj-c28[3]-len 2
attr Data4PLC obj-c28[3]-reading Temperatur_Heizung:DS18B20-3_Temperature
attr Data4PLC obj-c28[3]-unpack n


Leider erhalte ich nur diese Fehlermeldung

Modbus
Data4PLC: unknown attribute obj-c28[3]-len. Type 'attr Data4PLC ?' for a detailed list.
Data4PLC: unknown attribute obj-c28[3]-reading. Type 'attr Data4PLC ?' for a detailed list.
Data4PLC: unknown attribute obj-c28[3]-unpack. Type 'attr Data4PLC ?' for a detailed list.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 15 Dezember 2023, 09:57:41
Zitat von: Mariomgn am 14 Dezember 2023, 20:56:49Hallo Stefan,

Ist das so richtig?
attr Data4PLC obj-c28[3]-len 2
attr Data4PLC obj-c28[3]-reading Temperatur_Heizung:DS18B20-3_Temperature
attr Data4PLC obj-c28[3]-unpack n


Leider erhalte ich nur diese Fehlermeldung

Modbus
Data4PLC: unknown attribute obj-c28[3]-len. Type 'attr Data4PLC ?' for a detailed list.
Data4PLC: unknown attribute obj-c28[3]-reading. Type 'attr Data4PLC ?' for a detailed list.
Data4PLC: unknown attribute obj-c28[3]-unpack. Type 'attr Data4PLC ?' for a detailed list.

Da bringst du einige Sachen durcheinander. Coils haben eine Länge von 1 und unpack macht auch keinen Sinn. Auch das "[3]" passt so meiner Meinung nach nicht. Ohne genaueren Angaben wird es schwierig, dir weiterzuhelfen. Was für ein Gerät möchtest du denn auslesen und wie sieht die Registertabelle aus? Poste doch auch mal die Definition von deinem ModbusAttr Device.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 15 Dezember 2023, 22:30:31
Hallo,

Sorry, klar wäre es sinnvoll alles zu zeigen.

Noch eine kurze Erklärung: z.B. H22 wird von Allen- Bradley Micro 820(MASTER) gelesen und auch verarbeitet.
Das sind insgesamt 21 Werte, welche gelesen werden.

Um das zu realisieren musste ich 21 Verbindungen Modbus TCP aufbauen. Das ist ganz schlecht!

Ich möchte nun das Ganze in eine Verbindung packen.

Ausschnitt aus Fhem Cfg:
define Data4PLC ModbusAttr 6 slave 192.168.0.150:1502 TCP
attr Data4PLC userattr obj-h22-len obj-h22-reading obj-h22-unpack obj-h24-len obj-h24-reading obj-h24-unpack obj-h26-len obj-h26-reading obj-h26-unpack obj-h260-allowWrite obj-h260-len obj-h260-reading obj-h260-unpack obj-h262-allowWrite obj-h262-len obj-h262-reading obj-h262-unpack obj-h28-len obj-h28-reading obj-h28-unpack obj-h30-len obj-h30-reading obj-h30-unpack obj-h32-len obj-h32-reading obj-h32-unpack obj-h34-len obj-h34-reading obj-h34-unpack obj-h36-len obj-h36-reading obj-h36-unpack obj-h38-len obj-h38-reading obj-h38-unpack obj-h40-len obj-h40-reading obj-h40-unpack obj-h42-len obj-h42-reading obj-h42-unpack obj-h44-len obj-h44-reading obj-h44-unpack obj-h46-len obj-h46-reading obj-h46-unpack obj-h48-len obj-h48-reading obj-h48-unpack obj-h50-len obj-h50-reading obj-h50-unpack obj-h52-len obj-h52-reading obj-h52-unpack obj-h54-len obj-h54-reading obj-h54-unpack obj-h56-len obj-h56-reading obj-h56-unpack obj-h58-len obj-h58-reading obj-h58-unpack obj-h60-len obj-h60-reading obj-h60-unpack obj-h62-len obj-h62-reading obj-h62-unpack
attr Data4PLC obj-h22-len 2
attr Data4PLC obj-h22-reading Temperatur_Heizung:DS18B20-7_Temperature
attr Data4PLC obj-h22-unpack n
attr Data4PLC obj-h24-len 2
attr Data4PLC obj-h24-reading Temperatur_Heizung:DS18B20-2_Temperature
attr Data4PLC obj-h24-unpack n
attr Data4PLC obj-h26-len 2
attr Data4PLC obj-h26-reading Temperatur_Heizung:DS18B20-6_Temperature
attr Data4PLC obj-h26-unpack n



Auf der Micro 820 Seite, ist es möglich, z.B. auf Adresse 22, bis zu 125 werte zu empfangen.

MfG
Mario
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 15 Dezember 2023, 22:43:32
Ok, das sieht schonmal vernünftiger aus. Das "userattr" kannst du weglassen, das braucht es nicht. Natürlich brauchst du auch nicht 21 separate Verbindungen um verschiedene Werte vom gleichen Modbus Slave abzufragen, 1 reicht und dann 21 separate Register definieren so wie du das angefangen hast.

Zitat von: Mariomgn am 15 Dezember 2023, 22:30:31Auf der Micro 820 Seite, ist es möglich, z.B. auf Adresse 22, bis zu 125 werte zu empfangen.

Diese Aussage macht für mich so wenig Sinn. Pro Adresse, also in deinem Beispiel "22" für ein Holdingregister werden erst mal nur 16bit gespeichert. Ich nehme an, deine Temperaturen sind in float und damit 32bit. Da brauchst du schon 2 Register, daher macht deine Definition von z.B. obj-h22-len und -unpack durchaus schonmal Sinn. Der nächste Wert ist wohl 2 Register weiter oben im "24" (das ist je nach Modbusgerät völlig unterschiedlich!).

Was zeigt denn nun dein Data4PLC Device für Readings an und was ist im Moment deine Frage?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 15 Dezember 2023, 23:11:44
Ich möchte aus einem Holding Register mehrere Werte auslesen.

In dem Video Modbus Micro 820 (https://www.youtube.com/watch?v=F0R90ZiI1Mg&t=761s)sieht man ab Min. 11, dass es auf Seite Micro 820 möglich ist, diese so auszulesen.

Ich versuche nun das Ganze in Fhem zu realisieren.


Ich hoffe, dass es so verständlich ist.  :)

P.S. vielen Dank schonmal für die Bemühung.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 16 Dezember 2023, 08:41:24
Das sind nach meinem Verständnis MEHRERE Register die jeweils einen Wert haben. Du hast - wie gesagt - pro Holding Register nur 16bit Platz, da passt nichtmal 1 Float Zahl hinein, daher ist z.B. ein Float Wert sogar über 2 Register verteilt.
Wie gesagt, was sind denn nun deine Readings? Ohne weitere Infos wird es schwierig, dir weiterzuhelfen. Deine Definition sieht - abgesehen von der userattrs - vernünftig aus. Wenn dein Micro 820 (ich kenne das Gerät nicht) richtig konfiguriert ist und an diesen Adressen auch wirklich Daten hinterlegt sind, so sollte zumindest irgend etwas in FHEM ankommen.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Mariomgn am 16 Dezember 2023, 21:25:39
ok, ich fange noch einmal neu an.

Aktuell funktioniert die Kommunikation zwischen Fhem und Micro 820.

Das eigentliche Problem ist, das immer wieder Fehlermeldung im Fhem log auftauchen.
Zu diesem Problem habe ich schonmal was geschrieben, leider gab es keine richtige Lösung.

Diese Fehlermeldung sind manchmal nur 20 pro Tag, was nicht auffällt oder stört, an einem anderen Tag, legen diese Fehlermeldungen Fhem komplett lahm. Das Logfile hat dann teilweise eine Größe von 2Gb oder auch mehr.

Auszug aus Log mit verbose 5
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32607, type h, adr 62, len 2, Current read buffer: 7f5f000000060603003e0002, Id 6, fCode 3, tid 32607
2023.12.16 21:05:38 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:38 5: Data4PLC: PackObj called from CreateResponse with h 62 and valuesLen 2
2023.12.16 21:05:38 5: Data4PLC: PackObj ObjInfo for h62: reading=Palletbrenner:cmd, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:38 4: Data4PLC: PackObj for h62 is using reading cmd of device Palletbrenner with value 1
2023.12.16 21:05:38 5: Data4PLC: PackObj packed 1 with pack code n to 0001
2023.12.16 21:05:38 5: Data4PLC: PackObj padded / cut object to 00010000
2023.12.16 21:05:38 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:38 5: Data4PLC: PackObj full data string is 00010000
2023.12.16 21:05:38 5: Data4PLC: PackObj padded / cut data string to 00010000
2023.12.16 21:05:38 5: Data4PLC: prepare response pdu
2023.12.16 21:05:38 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32607 for h 62, len 2, device Data4PLC (TCP), pdu 030400010000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: Send 7f5f0000000706030400010000
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32607, type h, adr 62, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7f5f000000060603003e0002, Id 6, fCode 3, tid 32607, response: id 6, fCode 3, tid 32607, type h, adr 62, len 2, value 00010000
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7f5f000000060603003e0002
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: read buffer: 7f6000000006060300300002
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32608, dlen 6 and data 00300002
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32608, type h, adr 48, len 2, Current read buffer: 7f6000000006060300300002, Id 6, fCode 3, tid 32608
2023.12.16 21:05:38 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:38 5: Data4PLC: PackObj called from CreateResponse with h 48 and valuesLen 2
2023.12.16 21:05:38 5: Data4PLC: PackObj ObjInfo for h48: reading=Heizstab:cmd, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:38 4: Data4PLC: PackObj for h48 is using reading cmd of device Heizstab with value 1
2023.12.16 21:05:38 5: Data4PLC: PackObj packed 1 with pack code n to 0001
2023.12.16 21:05:38 5: Data4PLC: PackObj padded / cut object to 00010000
2023.12.16 21:05:38 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:38 5: Data4PLC: PackObj full data string is 00010000
2023.12.16 21:05:38 5: Data4PLC: PackObj padded / cut data string to 00010000
2023.12.16 21:05:38 5: Data4PLC: prepare response pdu
2023.12.16 21:05:38 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32608 for h 48, len 2, device Data4PLC (TCP), pdu 030400010000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: Send 7f600000000706030400010000
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32608, type h, adr 48, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7f6000000006060300300002, Id 6, fCode 3, tid 32608, response: id 6, fCode 3, tid 32608, type h, adr 48, len 2, value 00010000
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7f6000000006060300300002
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: read buffer: 7f6c0000000b06100103000204003f0000
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 16, tid 32620, dlen 11 and data 0103000204003f0000
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 16, tid 32620, type h, adr 259, len 2, value 003f0000, Current read buffer: 7f6c0000000b06100103000204003f0000, Id 6, fCode 16, tid 32620
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: passing value string of write request to ParseObj to set readings
2023.12.16 21:05:38 5: Data4PLC: ParseObj called with data 003f0000, type h, adr 259, valuesLen 2
2023.12.16 21:05:38 5: Data4PLC: ParseObj has no information about parsing h259
2023.12.16 21:05:38 5: Data4PLC: ParseObj moves to next object, skip 1 to h260
2023.12.16 21:05:38 5: Data4PLC: ParseObj ObjInfo for h260: reading=Ventil_Atmos:state, unpack=n, expr=, format=, map=
2023.12.16 21:05:38 5: Data4PLC: ParseObj unpacked 0000 with n to 0 hex 30
2023.12.16 21:05:38 4: Data4PLC: ParseObj assigns value 0 to reading state of device Ventil_Atmos
2023.12.16 21:05:38 5: Data4PLC: HandleRequest got 1 readings from ParseObj
2023.12.16 21:05:38 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:38 5: Data4PLC: prepare response pdu
2023.12.16 21:05:38 4: Data4PLC: CreateResponse sends fc 144 error code 2 to id 6, tid 32620 for h 259, len 2, device Data4PLC (TCP), pdu 9002, V 4.1.5 - 17.9.2019
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: Send 7f6c00000003069002
2023.12.16 21:05:38 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 16, tid 32620, type h, adr 259, len 2, value 003f0000 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7f6c0000000b06100103000204003f0000, Id 6, fCode 16, tid 32620, response: id 6, fCode 16, tid 32620, type h, adr 259, len 2
2023.12.16 21:05:38 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7f6c0000000b06100103000204003f0000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read gap is twice timeout -> expecting a new request now
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fc300000006060300160002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32707, dlen 6 and data 00160002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32707, type h, adr 22, len 2, Current read buffer: 7fc300000006060300160002, Id 6, fCode 3, tid 32707
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 22 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h22: reading=Temperatur_Heizung:DS18B20-7_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h22 is using reading DS18B20-7_Temperature of device Temperatur_Heizung with value 46.3
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 46.3 with pack code n to 002e
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 002e0000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 002e0000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 002e0000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32707 for h 22, len 2, device Data4PLC (TCP), pdu 0304002e0000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fc300000007060304002e0000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32707, type h, adr 22, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fc300000006060300160002, Id 6, fCode 3, tid 32707, response: id 6, fCode 3, tid 32707, type h, adr 22, len 2, value 002e0000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fc300000006060300160002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fc400000006060300180002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32708, dlen 6 and data 00180002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32708, type h, adr 24, len 2, Current read buffer: 7fc400000006060300180002, Id 6, fCode 3, tid 32708
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 24 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h24: reading=Temperatur_Heizung:DS18B20-2_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h24 is using reading DS18B20-2_Temperature of device Temperatur_Heizung with value 33.3
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 33.3 with pack code n to 0021
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00210000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00210000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00210000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32708 for h 24, len 2, device Data4PLC (TCP), pdu 030400210000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fc40000000706030400210000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32708, type h, adr 24, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fc400000006060300180002, Id 6, fCode 3, tid 32708, response: id 6, fCode 3, tid 32708, type h, adr 24, len 2, value 00210000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fc400000006060300180002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fc5000000060603001a0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32709, dlen 6 and data 001a0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32709, type h, adr 26, len 2, Current read buffer: 7fc5000000060603001a0002, Id 6, fCode 3, tid 32709
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 26 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h26: reading=Temperatur_Heizung:DS18B20-6_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h26 is using reading DS18B20-6_Temperature of device Temperatur_Heizung with value 37.3
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 37.3 with pack code n to 0025
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00250000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00250000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00250000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32709 for h 26, len 2, device Data4PLC (TCP), pdu 030400250000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fc50000000706030400250000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32709, type h, adr 26, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fc5000000060603001a0002, Id 6, fCode 3, tid 32709, response: id 6, fCode 3, tid 32709, type h, adr 26, len 2, value 00250000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fc5000000060603001a0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fc6000000060603001c0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32710, dlen 6 and data 001c0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32710, type h, adr 28, len 2, Current read buffer: 7fc6000000060603001c0002, Id 6, fCode 3, tid 32710
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 28 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h28: reading=Temperatur_Heizung:DS18B20-3_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h28 is using reading DS18B20-3_Temperature of device Temperatur_Heizung with value 32.4
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 32.4 with pack code n to 0020
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00200000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00200000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00200000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32710 for h 28, len 2, device Data4PLC (TCP), pdu 030400200000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fc60000000706030400200000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32710, type h, adr 28, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fc6000000060603001c0002, Id 6, fCode 3, tid 32710, response: id 6, fCode 3, tid 32710, type h, adr 28, len 2, value 00200000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fc6000000060603001c0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fc7000000060603001e0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32711, dlen 6 and data 001e0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32711, type h, adr 30, len 2, Current read buffer: 7fc7000000060603001e0002, Id 6, fCode 3, tid 32711
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 30 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h30: reading=Temperatur_Heizung:DS18B20-1_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h30 is using reading DS18B20-1_Temperature of device Temperatur_Heizung with value 71.9
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 71.9 with pack code n to 0047
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00470000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00470000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00470000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32711 for h 30, len 2, device Data4PLC (TCP), pdu 030400470000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fc70000000706030400470000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32711, type h, adr 30, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fc7000000060603001e0002, Id 6, fCode 3, tid 32711, response: id 6, fCode 3, tid 32711, type h, adr 30, len 2, value 00470000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fc7000000060603001e0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fc800000006060300200002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32712, dlen 6 and data 00200002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32712, type h, adr 32, len 2, Current read buffer: 7fc800000006060300200002, Id 6, fCode 3, tid 32712
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 32 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h32: reading=Temperatur_Heizung_2:DS18B20-1_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h32 is using reading DS18B20-1_Temperature of device Temperatur_Heizung_2 with value 37.4
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 37.4 with pack code n to 0025
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00250000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00250000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00250000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32712 for h 32, len 2, device Data4PLC (TCP), pdu 030400250000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fc80000000706030400250000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32712, type h, adr 32, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fc800000006060300200002, Id 6, fCode 3, tid 32712, response: id 6, fCode 3, tid 32712, type h, adr 32, len 2, value 00250000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fc800000006060300200002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fc900000006060300220002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32713, dlen 6 and data 00220002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32713, type h, adr 34, len 2, Current read buffer: 7fc900000006060300220002, Id 6, fCode 3, tid 32713
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 34 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h34: reading=Temperatur_Heizung_2:DS18B20-2_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h34 is using reading DS18B20-2_Temperature of device Temperatur_Heizung_2 with value 37.8
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 37.8 with pack code n to 0025
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00250000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00250000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00250000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32713 for h 34, len 2, device Data4PLC (TCP), pdu 030400250000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fc90000000706030400250000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32713, type h, adr 34, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fc900000006060300220002, Id 6, fCode 3, tid 32713, response: id 6, fCode 3, tid 32713, type h, adr 34, len 2, value 00250000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fc900000006060300220002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fca00000006060300240002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32714, dlen 6 and data 00240002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32714, type h, adr 36, len 2, Current read buffer: 7fca00000006060300240002, Id 6, fCode 3, tid 32714
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 36 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h36: reading=Temperatur_Heizung_2:DS18B20-3_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h36 is using reading DS18B20-3_Temperature of device Temperatur_Heizung_2 with value 52.1
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 52.1 with pack code n to 0034
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00340000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00340000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00340000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32714 for h 36, len 2, device Data4PLC (TCP), pdu 030400340000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fca0000000706030400340000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32714, type h, adr 36, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fca00000006060300240002, Id 6, fCode 3, tid 32714, response: id 6, fCode 3, tid 32714, type h, adr 36, len 2, value 00340000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fca00000006060300240002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fcb00000006060300260002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32715, dlen 6 and data 00260002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32715, type h, adr 38, len 2, Current read buffer: 7fcb00000006060300260002, Id 6, fCode 3, tid 32715
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 38 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h38: reading=Temperatur_Heizung:DS18B20-4_Temperature, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h38 is using reading DS18B20-4_Temperature of device Temperatur_Heizung with value 5.4
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 5.4 with pack code n to 0005
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00050000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00050000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00050000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32715 for h 38, len 2, device Data4PLC (TCP), pdu 030400050000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fcb0000000706030400050000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32715, type h, adr 38, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fcb00000006060300260002, Id 6, fCode 3, tid 32715, response: id 6, fCode 3, tid 32715, type h, adr 38, len 2, value 00050000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fcb00000006060300260002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fcc00000006060300280002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32716, dlen 6 and data 00280002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32716, type h, adr 40, len 2, Current read buffer: 7fcc00000006060300280002, Id 6, fCode 3, tid 32716
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 40 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h40: reading=Temperatur_Heizung:DS18B20-5_Temperature, expr=, format=, len=3, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h40 is using reading DS18B20-5_Temperature of device Temperatur_Heizung with value 36.1
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 36.1 with pack code n to 0024
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 002400000000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 3
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 002400000000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00240000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32716 for h 40, len 2, device Data4PLC (TCP), pdu 030400240000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fcc0000000706030400240000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32716, type h, adr 40, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fcc00000006060300280002, Id 6, fCode 3, tid 32716, response: id 6, fCode 3, tid 32716, type h, adr 40, len 2, value 00240000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fcc00000006060300280002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fcd000000060603002a0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32717, dlen 6 and data 002a0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32717, type h, adr 42, len 2, Current read buffer: 7fcd000000060603002a0002, Id 6, fCode 3, tid 32717
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 42 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h42: reading=SPH10000_BH_UP:Temp, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h42 is using reading Temp of device SPH10000_BH_UP with value 41
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 41 with pack code n to 0029
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00290000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00290000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00290000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32717 for h 42, len 2, device Data4PLC (TCP), pdu 030400290000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fcd0000000706030400290000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32717, type h, adr 42, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fcd000000060603002a0002, Id 6, fCode 3, tid 32717, response: id 6, fCode 3, tid 32717, type h, adr 42, len 2, value 00290000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fcd000000060603002a0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fce000000060603002c0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32718, dlen 6 and data 002c0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32718, type h, adr 44, len 2, Current read buffer: 7fce000000060603002c0002, Id 6, fCode 3, tid 32718
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 44 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h44: reading=SPH_BH_5000:Temp, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h44 is using reading Temp of device SPH_BH_5000 with value 36.2
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 36.2 with pack code n to 0024
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00240000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00240000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00240000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32718 for h 44, len 2, device Data4PLC (TCP), pdu 030400240000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fce0000000706030400240000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32718, type h, adr 44, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fce000000060603002c0002, Id 6, fCode 3, tid 32718, response: id 6, fCode 3, tid 32718, type h, adr 44, len 2, value 00240000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fce000000060603002c0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fcf000000060603002e0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32719, dlen 6 and data 002e0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32719, type h, adr 46, len 2, Current read buffer: 7fcf000000060603002e0002, Id 6, fCode 3, tid 32719
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 46 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h46: reading=SPH_BH_5000:PVPower, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h46 is using reading PVPower of device SPH_BH_5000 with value 0
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 0 with pack code n to 0000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00000000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32719 for h 46, len 2, device Data4PLC (TCP), pdu 030400000000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fcf0000000706030400000000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32719, type h, adr 46, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fcf000000060603002e0002, Id 6, fCode 3, tid 32719, response: id 6, fCode 3, tid 32719, type h, adr 46, len 2, value 00000000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fcf000000060603002e0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fd000000006060300320002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32720, dlen 6 and data 00320002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32720, type h, adr 50, len 2, Current read buffer: 7fd000000006060300320002, Id 6, fCode 3, tid 32720
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 50 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h50: reading=SPH10000_BH_UP:PtoG, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h50 is using reading PtoG of device SPH10000_BH_UP with value 0
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 0 with pack code n to 0000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00000000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32720 for h 50, len 2, device Data4PLC (TCP), pdu 030400000000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fd00000000706030400000000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32720, type h, adr 50, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fd000000006060300320002, Id 6, fCode 3, tid 32720, response: id 6, fCode 3, tid 32720, type h, adr 50, len 2, value 00000000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fd000000006060300320002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fd100000006060300340002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32721, dlen 6 and data 00340002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32721, type h, adr 52, len 2, Current read buffer: 7fd100000006060300340002, Id 6, fCode 3, tid 32721
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 52 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h52: reading=SPH10000_BH_UP:PVPower, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h52 is using reading PVPower of device SPH10000_BH_UP with value 0
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 0 with pack code n to 0000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00000000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32721 for h 52, len 2, device Data4PLC (TCP), pdu 030400000000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fd10000000706030400000000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32721, type h, adr 52, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fd100000006060300340002, Id 6, fCode 3, tid 32721, response: id 6, fCode 3, tid 32721, type h, adr 52, len 2, value 00000000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fd100000006060300340002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fd200000006060300360002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32722, dlen 6 and data 00360002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32722, type h, adr 54, len 2, Current read buffer: 7fd200000006060300360002, Id 6, fCode 3, tid 32722
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 54 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h54: reading=SPH10000_BH_UP:PDiC, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h54 is using reading PDiC of device SPH10000_BH_UP with value 0
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 0 with pack code n to 0000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00000000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32722 for h 54, len 2, device Data4PLC (TCP), pdu 030400000000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fd20000000706030400000000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32722, type h, adr 54, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fd200000006060300360002, Id 6, fCode 3, tid 32722, response: id 6, fCode 3, tid 32722, type h, adr 54, len 2, value 00000000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fd200000006060300360002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fd300000006060300380002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32723, dlen 6 and data 00380002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32723, type h, adr 56, len 2, Current read buffer: 7fd300000006060300380002, Id 6, fCode 3, tid 32723
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 56 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h56: reading=SPH10000_BH_UP:PC, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h56 is using reading PC of device SPH10000_BH_UP with value 0
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 0 with pack code n to 0000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00000000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00000000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32723 for h 56, len 2, device Data4PLC (TCP), pdu 030400000000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fd30000000706030400000000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32723, type h, adr 56, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fd300000006060300380002, Id 6, fCode 3, tid 32723, response: id 6, fCode 3, tid 32723, type h, adr 56, len 2, value 00000000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fd300000006060300380002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fd4000000060603003a0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32724, dlen 6 and data 003a0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32724, type h, adr 58, len 2, Current read buffer: 7fd4000000060603003a0002, Id 6, fCode 3, tid 32724
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 58 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h58: reading=SPH10000_BH_UP:PtoU, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h58 is using reading PtoU of device SPH10000_BH_UP with value 1580
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 1580 with pack code n to 062c
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 062c0000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 062c0000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 062c0000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32724 for h 58, len 2, device Data4PLC (TCP), pdu 0304062c0000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fd400000007060304062c0000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32724, type h, adr 58, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fd4000000060603003a0002, Id 6, fCode 3, tid 32724, response: id 6, fCode 3, tid 32724, type h, adr 58, len 2, value 062c0000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fd4000000060603003a0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fd5000000060603003c0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32725, dlen 6 and data 003c0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32725, type h, adr 60, len 2, Current read buffer: 7fd5000000060603003c0002, Id 6, fCode 3, tid 32725
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 60 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj doesn't have reading or expr information for h60, set error code to 2
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 131 error code 2 to id 6, tid 32725 for h 60, len 2, device Data4PLC (TCP), pdu 8302, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fd500000003068302
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32725, type h, adr 60, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fd5000000060603003c0002, Id 6, fCode 3, tid 32725, response: id 6, fCode 3, tid 32725, type h, adr 60, len 2
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fd5000000060603003c0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fd6000000060603003e0002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32726, dlen 6 and data 003e0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32726, type h, adr 62, len 2, Current read buffer: 7fd6000000060603003e0002, Id 6, fCode 3, tid 32726
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 62 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h62: reading=Palletbrenner:cmd, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h62 is using reading cmd of device Palletbrenner with value 1
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 1 with pack code n to 0001
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00010000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00010000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00010000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32726 for h 62, len 2, device Data4PLC (TCP), pdu 030400010000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fd60000000706030400010000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32726, type h, adr 62, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fd6000000060603003e0002, Id 6, fCode 3, tid 32726, response: id 6, fCode 3, tid 32726, type h, adr 62, len 2, value 00010000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fd6000000060603003e0002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fd700000006060300300002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 32727, dlen 6 and data 00300002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 3, tid 32727, type h, adr 48, len 2, Current read buffer: 7fd700000006060300300002, Id 6, fCode 3, tid 32727
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: PackObj called from CreateResponse with h 48 and valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: PackObj ObjInfo for h48: reading=Heizstab:cmd, expr=, format=, len=2, map=, unpack=n
2023.12.16 21:05:44 4: Data4PLC: PackObj for h48 is using reading cmd of device Heizstab with value 1
2023.12.16 21:05:44 5: Data4PLC: PackObj packed 1 with pack code n to 0001
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut object to 00010000
2023.12.16 21:05:44 5: Data4PLC: PackObj counter reached 2
2023.12.16 21:05:44 5: Data4PLC: PackObj full data string is 00010000
2023.12.16 21:05:44 5: Data4PLC: PackObj padded / cut data string to 00010000
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 32727 for h 48, len 2, device Data4PLC (TCP), pdu 030400010000, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fd70000000706030400010000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 3, tid 32727, type h, adr 48, len 2 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fd700000006060300300002, Id 6, fCode 3, tid 32727, response: id 6, fCode 3, tid 32727, type h, adr 48, len 2, value 00010000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fd700000006060300300002
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: read buffer: 7fe30000000b06100103000204003f0000
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: ParseFrameStart (TCP) extracted id 6, fCode 16, tid 32739, dlen 11 and data 0103000204003f0000
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: HandleRequest called from Read
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: ParseRequest called from HandleRequest
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: HandleRequest request: id 6, fCode 16, tid 32739, type h, adr 259, len 2, value 003f0000, Current read buffer: 7fe30000000b06100103000204003f0000, Id 6, fCode 16, tid 32739
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: passing value string of write request to ParseObj to set readings
2023.12.16 21:05:44 5: Data4PLC: ParseObj called with data 003f0000, type h, adr 259, valuesLen 2
2023.12.16 21:05:44 5: Data4PLC: ParseObj has no information about parsing h259
2023.12.16 21:05:44 5: Data4PLC: ParseObj moves to next object, skip 1 to h260
2023.12.16 21:05:44 5: Data4PLC: ParseObj ObjInfo for h260: reading=Ventil_Atmos:state, unpack=n, expr=, format=, map=
2023.12.16 21:05:44 5: Data4PLC: ParseObj unpacked 0000 with n to 0 hex 30
2023.12.16 21:05:44 4: Data4PLC: ParseObj assigns value 0 to reading state of device Ventil_Atmos
2023.12.16 21:05:44 5: Data4PLC: HandleRequest got 1 readings from ParseObj
2023.12.16 21:05:44 5: Data4PLC: CreateResponse called from HandleRequest
2023.12.16 21:05:44 5: Data4PLC: prepare response pdu
2023.12.16 21:05:44 4: Data4PLC: CreateResponse sends fc 144 error code 2 to id 6, tid 32739 for h 259, len 2, device Data4PLC (TCP), pdu 9002, V 4.1.5 - 17.9.2019
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: Send 7fe300000003069002
2023.12.16 21:05:44 4: Data4PLC_192.168.0.250_34331: RequestDone request: id 6, fCode 16, tid 32739, type h, adr 259, len 2, value 003f0000 for device Data4PLC_192.168.0.250_34331, Current read buffer: 7fe30000000b06100103000204003f0000, Id 6, fCode 16, tid 32739, response: id 6, fCode 16, tid 32739, type h, adr 259, len 2
2023.12.16 21:05:44 5: Data4PLC_192.168.0.250_34331: DropFrame - drop 7fe30000000b06100103000204003f0000


Fehler in Log ohne verbose 5
2023.12.16 20:47:29 3: Data4PLC_192.168.0.250_34282: read from TCP server connection got null -> closing
2023.12.16 20:47:29 3: Data4PLC_192.168.0.250_34282: _UnDef is closing Data4PLC_192.168.0.250_34282
2023.12.16 20:47:29 3: Data4PLC_192.168.0.250_34284: read from TCP server connection got null -> closing
2023.12.16 20:47:29 3: Data4PLC_192.168.0.250_34284: _UnDef is closing Data4PLC_192.168.0.250_34284
2023.12.16 20:47:29 3: Data4PLC_192.168.0.250_34285: read from TCP server connection got null -> closing
2023.12.16 20:47:29 3: Data4PLC_192.168.0.250_34285: _UnDef is closing Data4PLC_192.168.0.250_34285
2023.12.16 20:47:29 3: Data4PLC_192.168.0.250_34286: read from TCP server connection got null -> closing
2023.12.16 20:47:29 3: Data4PLC_192.168.0.250_34286: _UnDef is closing Data4PLC_192.168.0.250_34286
2023.12.16 20:50:16 3: Data4PLC_192.168.0.250_34287: read from TCP server connection got null -> closing
2023.12.16 20:50:16 3: Data4PLC_192.168.0.250_34287: _UnDef is closing Data4PLC_192.168.0.250_34287
2023.12.16 20:50:16 3: Data4PLC_192.168.0.250_34288: read from TCP server connection got null -> closing
2023.12.16 20:50:16 3: Data4PLC_192.168.0.250_34288: _UnDef is closing Data4PLC_192.168.0.250_34288
2023.12.16 20:50:16 3: Data4PLC_192.168.0.250_34290: read from TCP server connection got null -> closing
2023.12.16 20:50:16 3: Data4PLC_192.168.0.250_34290: _UnDef is closing Data4PLC_192.168.0.250_34290
2023.12.16 20:50:16 3: Data4PLC_192.168.0.250_34291: read from TCP server connection got null -> closing
2023.12.16 20:50:16 3: Data4PLC_192.168.0.250_34291: _UnDef is closing Data4PLC_192.168.0.250_34291

Das Ganze läuft auf einen Pi 4.

Ich habe nun in der Doku der Micro 820 noch einmal nachgelesen und habe einen Punkt entdeckt, welcher mich stutzig macht.





[color=red]ConnClose

BOOL

Verhalten der TCP-Verbindungstrennung.

True – Die TCP-Verbindung nach Abschluss der Nachricht trennen.
False – Die TCP-Verbindung nach Abschluss der Nachricht nicht trennen [Standard].
Siehe Modbus-/TCP-Nachrichtenverbindungen.
[/color]
Szenario

Nachrichtenanforderung ist aktiviert und es besteht keine Verbindung zum Ziel.

Ergebnisse
Wenn keine Verbindung mit dem Ziel besteht, wird eine neue Verbindung aufgebaut.

Wenn bereits eine Verbindung mit dem Ziel besteht, wird die vorhandene Verbindung verwendet.


Szenario
Die Nachrichtenausführung wurde abgeschlossen und ConnClose wird auf ,,True" gesetzt.

Ergebnisse
Es besteht nur eine Verbindung zum Ziel, die Verbindung wird geschlossen.

Falls mehr als eine Verbindung zum Ziel besteht, wird die Verbindung getrennt, sobald die letzte Nachrichtenausführung abgeschlossen wurde.

Szenario
Die Nachrichtenausführung wurde abgeschlossen und ConnClose wird auf False gesetzt.

Ergebnisse
Die Verbindung wurde nicht getrennt.


Szenario
Die Verbindung ist mit keiner aktiven Nachricht verknüpft und bleibt für den Zeitraum, der im ConnTimeOut-Parameter angegeben ist, inaktiv.

Ergebnisse
Die Verbindung wurde getrennt.


Szenario
Wechsel des Controllers von einem Ausführungsmodus (Betrieb, Remotelauf, Remotetestlauf, Remote-Kontaktplan) in einen Nicht-Ausführungsmodus.

Ergebnisse
   
Alle aktiven Verbindungen wurden getrennt.


Irgend wie werde ich aus der Sache nicht schlau.
Ich denke, dass der Fehler auf der Seite von Micro 820 liegt, weis aber nicht wo.

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 18 Dezember 2023, 20:05:11
Hallo Basil,

ich habe mir Deine Logs und Deine Änderungen mal genauer angesehen und komme zu anderen Ergebnissen.

Zitat von: McBasil am 12 Dezember 2023, 23:04:07sicher hast Du Recht, dass ein Versionswechsel nicht Ursache für die crc-Fehler ist. Es ist wohl mehr so, dass bei mir  normal
verbose auf 1 oder 2 steht und somit diese Fehler nicht protokolliert werden. Und dann fällt mir das natürlich nicht auf.

Jetzt war es aber so, dass mit der neuen Version auf einmal jede Menge fehlerhafte Anzeigen erschienen.
So wurde mir beispielsweise gleichzeitig angezeigt, dass die Wärmepumpe laufe, aber die Unterwasserpumpe nicht laufe, dass die Warmwassersolltemperatur auf 218 °C eingestellt sei
und die Brunneneinlauftemperatur bei 0 °C liege und die Brunnenausgangstemperatur über der Vorlauftemperatur liegt.

Wenn man das von Dir gepostete Log genauer ansieht, dann fallen vor allem Einträge auf, bei denen auf eine Anfrage für Holding Register 1 mit Function Code 3 eine Antwort mit Function Code 1 kommt - also Coil 1.
Das hat nichts mit CRC-Berechnungen zu tun sondern da ist etwas grundsätzlich durcheinander.

Hier ein paar relevante Einträge aus Deinem Log:
Zitat2023.11.28 01:34:31 4: Wi18Tu: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 6, sending 01030001006415e1 via ECS-AP:8899, read buffer empty,
request: id 1, read fc 3 h1, len 100, master device Wi18Tu, reading tp_aussen (getUpdate for combined h1 len 1 tp_aussen with h2 len 1 tp_wp_rl and h3 len 1 tp_ww_ist and h5 len 1 tp_wp_vl and h6 len 1 tp_br_ein and h7 len 1 tp_br_aus and h8 len 1 tp_wp_heissgas and h9 len 1 tp_wp_rl_h and h42 len 1 wp_disp_stoerung and h43 len 1 wp_disp_anzeige and h45 len 1 wp_typ and h46 len 1 wp_Solltemp_1.HK_Raumregelung and h47 len 1 tp_wp_hys and h53 len 1 tp_wp_rl_s and h58 len 1 tp_ww_ruecklauf_soll and h59 len 1 wp_disp_sperre and h98 len 1 sensor_Sgg_temp and h99 len 1 sensor_Sggueh and h100 len 1 sensor_Sietemp), queued 1.70 secs ago

2023.11.28 01:34:31 4: Wi18Tu: HandleResponse error, current frame / read buffer: 0101021401773c0103c8002400f701e6ff7a00f9008e0088017500ebd8f100000000ffe7ffe7000000000000000000000000000000000000000000000000000000000000000000000000003202920000004601f401f401f401f401f40000000a0000000300c8000a00140000000a00000000010500fd00fd0000000001f4002400010000027301f50001000c0014000700000000000029f7189000001dd300474e2002840000000000000000000000000000000000000000000000000000000000000000000000000014d8f100e9007c006ddaab, id 1, fCode 1,
request: id 1, read fc 3 h1, len 100, master device Wi18Tu, reading tp_aussen (getUpdate for combined h1 len 1 tp_aussen with h2 len 1 tp_wp_rl and h3 len 1 tp_ww_ist and h5 len 1 tp_wp_vl and h6 len 1 tp_br_ein and h7 len 1 tp_br_aus and h8 len 1 tp_wp_heissgas and h9 len 1 tp_wp_rl_h and h42 len 1 wp_disp_stoerung and h43 len 1 wp_disp_anzeige and h45 len 1 wp_typ and h46 len 1 wp_Solltemp_1.HK_Raumregelung and h47 len 1 tp_wp_hys and h53 len 1 tp_wp_rl_s and h58 len 1 tp_ww_ruecklauf_soll and h59 len 1 wp_disp_sperre and h98 len 1 sensor_Sgg_temp and h99 len 1 sensor_Sggueh and h100 len 1 sensor_Sietemp), queued 1.94 secs ago, sent 0.24 secs ago,
response: id 1, fc 1, c1, len 100, values 1401, error: Function code 1 in Modbus response does not match request function code 3


2023.11.28 01:34:32 4: Wi18Tu: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 9, sending 01030065004b15e2 via ECS-AP:8899, read buffer empty,
request: id 1, read fc 3 h101, len 75, master device Wi18Tu, reading sensor_Sggdruck (getUpdate for combined h101 len 1 sensor_Sggdruck with h102 len 1 sensor_EVD_oe and h103 len 1 wp_dis_Statusmeldungen and h104 len 1 wp_dis_Waermepumpe_Sperre and h105 len 1 wp_dis_Stoermeldungen and h106 len 1 wp_dis_Sensorik and h131 len 1 Sprache and h132 len 1 Anzeige_Zeitmodus and h133 len 1 stunde and h134 len 1 minute and h135 len 1 monat and h136 len 1 wochentag and h137 len 1 tag and h138 len 1 jahr and h139 len 1 Betriebsmodus_Zeitverzoegerung and h140 len 1 Betriebsmodus_schalt_temp_kuehlen and h141 len 1 Betriebsmodus_schalt_temp_heizen and h142 len 1 Betriebsmodus and h143 len 1 partystunden and h144 len 1 urlaubstage and h163 len 1 tp_wp_par_ver and h165 len 1 tp_wp_hk_end and h172 len 1 tp_ww_hyst and h174 len 1 tp_ww_soll and h175 len 1 tp_ww_max), queued 2.64 secs ago

2023.11.28 01:34:32 4: Wi18Tu: HandleResponse error, current frame / read buffer: 01010104504b010396006a0147001e000900000000ff0600000000ffebffd50000000000000000ffb5fd6f0000000000000000000000000000000000000001000000010000000100010001002c000b0002001c001700010019001400010004000f00060003fffb000400010000000a00050023000600550008000a000c0016001e0000000400160028001a003200000016003c000f00000002ffe70032003c08e8, id 1, fCode 1,
request: id 1, read fc 3 h101, len 75, master device Wi18Tu, reading sensor_Sggdruck (getUpdate for combined h101 len 1 sensor_Sggdruck with h102 len 1 sensor_EVD_oe and h103 len 1 wp_dis_Statusmeldungen and h104 len 1 wp_dis_Waermepumpe_Sperre and h105 len 1 wp_dis_Stoermeldungen and h106 len 1 wp_dis_Sensorik and h131 len 1 Sprache and h132 len 1 Anzeige_Zeitmodus and h133 len 1 stunde and h134 len 1 minute and h135 len 1 monat and h136 len 1 wochentag and h137 len 1 tag and h138 len 1 jahr and h139 len 1 Betriebsmodus_Zeitverzoegerung and h140 len 1 Betriebsmodus_schalt_temp_kuehlen and h141 len 1 Betriebsmodus_schalt_temp_heizen and h142 len 1 Betriebsmodus and h143 len 1 partystunden and h144 len 1 urlaubstage and h163 len 1 tp_wp_par_ver and h165 len 1 tp_wp_hk_end and h172 len 1 tp_ww_hyst and h174 len 1 tp_ww_soll and h175 len 1 tp_ww_max), queued 2.88 secs ago, sent 0.24 secs ago,
response: id 1, fc 1, c101, len 75, values 04, error: Function code 1 in Modbus response does not match request function code 3


ZitatJetzt habe ich Ursachenforschung betrieben und die Protokolle ausgewertet. Für mein besseres Verständnis habe ich verschiedene Log-Ausgaben optisch etwas anders aufbereitet.
Die Ursache konnte ich ermitteln und beheben.

sub ParseResponse {    wird bei der Berechnung das fcode Byte mitgerechnet und das ist der Auslöser für die fehlerhafte Berechnung.
......
       my ($len, $values) = unpack ('Ca*', $data);
......
       $frame->{PDULEXP}  = $len + 2;                      # 1 Byte fCode + 1 Byte len + len of expected values
muss ersetzt werden durch
       $frame->{PDULEXP}  = $len + 1;                      # 1 Byte len + len of expected values
......
}

Das sehe ich anders. Die von Dir geposteten Änderungen bewirken nicht das was Du meinst:
$frame->{PDULEXP} ist die erwartete Länge der PDU. Da geht es nicht um die CRC-Berechnung sondern um die Frage ob ein Frame schon vollständig empfangen sein kann.
Die CRC wird bei Modbus-RTU vor und nach Deiner Änderung immer noch von id über fcode und len bis Ende der Daten berechnet. Das ist auch korrekt so.
Die Frage ist nur was bei der Verifikation als CRC betrachtet wird. Wenn eigentlich eine Response erwartet wird, statt dessen aber ein Request empfangen wird,
dann ist das Frame-Format ein anderes. Als Response interpretiert wäre die CRC an einer anderen Stelle und damit falsch.
Insbesondere wenn Dein Gerät mit ganz anderen Function Codes antwortet, wird das Ergebnis dadurch nicht besser.
Mit Deiner Änderung wird ggf. das Ende der empfangenen Daten als CRC interpretiert. Ein Request würde so fälschlicherweise als gültige Response gesehen - das wäre aber falsch und würde erst recht falsche Daten liefern.

Die Modul-Tests liefern nach Deiner Änderung viele Fehler, auch wenn es in Deinem Fall zunächst so aussehen mag, als ob weniger Fehler im Log stehen.
Ich vermute dass das Problem in Deinem Fall an ganz anderer Stelle zu suchen ist.

Was für Geräte setzt Du denn ein und wie sind die Geräte bei Dir miteinander verbunden? Gibt es neben Fhem noch andere Modbus-Master oder andere Slaves?

Bitte poste doch mal Deine vollständige Konfiguration und eine Beschreibung wie welche Geräte bei Dir miteinander verbunden sind.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: McBasil am 19 Dezember 2023, 04:30:54
Hallo Stefan,

zuerst ganz ganz herzlichen Dank für Deine Mühen mit meinem Problem. Wahrscheinlich wird es nicht möglich sein die Ursache zu finden.

Meine Konfiguration ist recht simpel, fhem läuft auf einem Pi 3b und greift über RS485_To_WIFI auf eine Dimplex Wi18Tu zu. Das Ganze ist 2016 in Betrieb gegangen und läuft eigendlich sehr zufriedenstellend. Ich war über 6 Jahre keine Auffälligkeiten gewohnt.

Als ich jetzt nach dem Fehler das log angeschaut habe, fiel mir auf, dass diese crc Fehler nur dann aufzutreten schienen, wenn das CRC in Abhängigkeit des Längenfeldes aus PDU gebildet wurde, und dann auch nur unregelmäßig. Das verleitete mich an dieser Schraube zu drehen, denn wenn zur CRC-Berechnung nicht die richtige Länge angegeben wird, muss ja das Ergebnis falsch sein. Und was will ich mehr, ich änderte und der Fehler ist verschwunden. Ich muss zugeben, dass ich übereifrig einiges an Unsinn verzapft habe und bitte dafür um Nachsicht.

Seid meiner Änderung sind bei mir keine Fehler mehr aufgetreten. Das hat mich gereitzt nachzuweisen, dass tatsächlich meine Änderung der große Durchbruch war. Das fehlerhafte Verhalten erneut zu provozieren ist mir nicht mehr gelungen. Meine Änderungen haben ganz offensichtlich nichts bewirkt und ich habe auch wieder die Originalfassung von Dir im Einsatz.

Mein aktuelles Logfile schicke ich mit. Die wenigen protokollierten Fehler sind mir zwar nicht verständlich, aber ich denke, die sind auch nicht störend. Für mich läuft alles zufriedenstellend.

Gruß
  Basil


fhem-2023-12_log.txt
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 20 Dezember 2023, 20:07:17
Hallo Basil,

irgendwo ist aber doch der Wurm drin. In dem ersten größeren Log, dass Du gepostet hast, sieht man dass der Request für Holding Register 0 oft gar nicht oder unsinnig beantwortet wird. Entweder die Dimplex oder Dein RS385-Wifi-gateway hat ein Problem.
Brauchst Du die Daten wirklich im Sekundentakt?
Ich könnte mir gut vorstellen, dass eines der Geräte damit einfach überlastet ist.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 29 Dezember 2023, 17:22:04
Hallo Ihr, ich habe mal eine Verständnisfrage.

So

define Studer485_CAN ModbusAttr 93 6
attr Studer485_CAN dev-defLen 2
attr Studer485_CAN dev-defPoll 1
attr Studer485_CAN dev-defShowGet 1
attr Studer485_CAN dev-defUnpack f>
attr Studer485_CAN dev-h-read 3
attr Studer485_CAN dev-h-write 16
attr Studer485_CAN dev-i-read 4
attr Studer485_CAN dev-timing-timeout 1
attr Studer485_CAN event-min-interval .*:900
attr Studer485_CAN event-on-change-reading Charge_Discharge_W:50,SoC,Temp_Batt:0.2,BATT_Priority_RAM
attr Studer485_CAN event-on-update-reading .*
attr Studer485_CAN group Xtender
attr Studer485_CAN obj-i4-format %.1f
attr Studer485_CAN obj-i4-polldelay 30
attr Studer485_CAN obj-i4-reading SoC
attr Studer485_CAN obj-i58-format %.1f
attr Studer485_CAN obj-i58-polldelay 600
attr Studer485_CAN obj-i58-reading Temp_Batt
attr Studer485_CAN obj-i6-format %2d
attr Studer485_CAN obj-i6-reading Charge_Discharge_W

attr Studer485_CAN obj-h6142-reading BATT_Priority_RAM
attr Studer485_CAN obj-h6142-set 1
attr Studer485_CAN obj-h6142-hint Ja,Nein
attr Studer485_CAN obj-h6142-map 1:Ja,0:Nein

frage und setze ich gerade Infos und Parameter in meiner Solaranlage.

Was ich nicht hinbekomme ist, die GESETZTEN Parameter (in diesem Beispiel BATT_Priority_RAM) auch als Reading anzuzeigen.

Ist das generell nicht machbar? Oder wie müsste ich den Parameter auch als Reading anlegen?

Danke und Gruß!
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 29 Dezember 2023, 20:59:56
Das verstehe ich nicht ganz. Wird das Reading "BATT_Priority_RAM" gar nicht angezeigt oder werden die gesetzen Werte dann nicht aktualisiert? Bei mir ist es so: wenn ich ein Register mit "set" setze, so übernimmt auch sofort das entsprechende Reading den neuen Wert. Das Reading kann sich dann wieder ändern, wenn beim nächsten Poll das Gerät das entsprechende Register verändert hat.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: holle75 am 29 Dezember 2023, 21:35:38
Hallo Aurel, so wie du das beschreibst, hätte ich es erwartet. Habe mich die letzten Monate/Jahre damit abgefunden, dass es nicht so ist. Jetzt wollte ich da nochmal ran.

Ja, schreiben funktioniert, nur ein Reading bekomme ich nicht. Ich muss mich nochmal in die Manuals von Studer vertiefen. Wollte nur gerne wissen, ob das ein allgemeingültiges Verhalten ist. Scheint nicht so.

weitergedacht:

Ich kann mit zusätzlich

attr Studer485_CAN obj-h142-reading BATT_Priority
attr Studer485_CAN obj-h142-map 1:Ja,0:Nein

sehr wohl das Holding Register auslesen. Das ist die selbe Adresse wie

attr Studer485_CAN obj-h6142-reading BATT_Priority_RAM
attr Studer485_CAN obj-h6142-set 1
attr Studer485_CAN obj-h6142-hint Ja,Nein
attr Studer485_CAN obj-h6142-map 1:Ja,0:Nein

ohne den 6000 Offset um nur ins RAM zu schreiben und nicht ins Flash.
Das erklärt dann aber wiederum warum sich der Wert in h142 nicht verändert ;)

Ok. Glaube, ich habs verstanden. Muss das Reading explizit anlegen, bringt nur nix, weil sich der Wert nicht verändert weil nur ins RAM geschieben wird. Da beißt sich eine Katze in den Schwanz.
Wäre noch interessant, ob das Reading automatisch angelegt werden würde, wenn ich ins Flash schreibe. Aber da das keine langfristige Option ist, brauch ichs auch nicht auszuprobieren.

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tabadorer am 31 Dezember 2023, 12:26:28
THEMA: Beim Schreiben von Registern in Batterieinverter werden die Werte in HEX umgewandelt.
Dieser Post ist von hier (https://forum.fhem.de/index.php?topic=136353.0) kopiert worden.


Ich habe von SMA den Batterieinverter Sunny Island SI6.0H-11. Diesen habe ich über ModBus TCP in fhem eingebunden. Das Lesen der Register ist bisher meist unproblematisch, aber beim schreiben wird mir der neue Sollwert durch fhem immer in einen HEX-Wert konvertiert.  >:(

Hier vorab meine Definition für meinen Batterieinverter:
defmod SMASI ModbusAttr 3 10 <IP>:502 TCP
attr SMASI busDelay 5
attr SMASI closeAfterResponse 0
attr SMASI dev-h-defLen 2
attr SMASI dev-h-defPoll 0
attr SMASI dev-h-defRevRegs 1
attr SMASI dev-i-defLen 2
attr SMASI dev-i-defPoll 1
attr SMASI dev-i-defRevRegs 1
attr SMASI dev-type-ENUM_JN-hint ja,nein
attr SMASI dev-type-ENUM_JN-map 1129:ja, 1130:nein
attr SMASI enableControlSet 1
attr SMASI icon batterie
attr SMASI obj-h40075-name Eigenverbraucherhoehung eingeschaltet
attr SMASI obj-h40075-polldelay 310
attr SMASI obj-h40075-reading EigenverbraucherhoehungAktiv
attr SMASI obj-h40075-set 1
attr SMASI obj-h40075-showGet 1
attr SMASI obj-h40075-unpack n
attr SMASI obj-h40075-type ENUM_JN
attr SMASI obj-i30775-expr $val*-1
attr SMASI obj-i30775-ignoreExpr $val < -8000
attr SMASI obj-i30775-max 5000
attr SMASI obj-i30775-min -5000
attr SMASI obj-i30775-reading BatteryPower
attr SMASI obj-i30775-revRegs 1
attr SMASI obj-i30845-reading StateOfCharge
attr SMASI obj-i30847-polldelay 1800
attr SMASI obj-i30847-reading StateOfHealth
attr SMASI obj-i30849-expr $val/10
attr SMASI obj-i30849-format %.1f
attr SMASI obj-i30849-polldelay 600
attr SMASI obj-i30849-reading BatteryTemp
attr SMASI obj-i30849-revRegs 1
attr SMASI obj-i30851-expr $val/100
attr SMASI obj-i30851-format %.2f
attr SMASI obj-i30851-polldelay 180
attr SMASI obj-i30851-reading BatteryVoltage
attr SMASI obj-i30993-expr $val/1000
attr SMASI obj-i30993-format %.3f
attr SMASI obj-i30993-name Ladefaktor: Verhältnis Batterieladung/-endladung
attr SMASI obj-i30993-reading Ladefaktor
attr SMASI obj-i31009-reading DischargeBoundary
attr SMASI obj-i31009-showGet 0
attr SMASI obj-i31057-name Status Batterienutzungsbereich
attr SMASI obj-i31057-reading BatteryUsageType
attr SMASI room Energie
attr SMASI silentReconnect 1
attr SMASI stateFormat <div>BatteryPower W / StateOfCharge %</div>
attr SMASI verbose 5


Hier das Logging mit Verboselevel 5. In Zeile 4 sieht man das hier etwas in 046a konvertiert wird.
2023.12.24 12:13:15.153 4: SMASI: set called with EigenverbraucherhoehungAktiv (h40075) setVal = 1130
2023.12.24 12:13:15.154 5: SMASI: GetSetChecks with force
2023.12.24 12:13:15.154 5: SMASI: GetSetChecks returns success
2023.12.24 12:13:15.154 5: SMASI: set packed hex 31313330 with n to hex 046a
2023.12.24 12:13:15.155 4: SMASI: DoRequest called from SetLDFn created new request, read buffer empty, id 3, fCode 3, tid 56,
request: id 3, write fc 16 h40075, len 2, value 046a, tid 228, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv),
response: no id, no fcode
2023.12.24 12:13:15.155 5: SMASI: QueueRequest called from DoRequest with h40075, qlen 0 from master SMASI through io device SMASI
2023.12.24 12:13:15.155 5: SMASI: ProcessRequestQueue called from QueueRequest as direct:SMASI, qlen 1, force, request: request: id 3, write fc 16 h40075, len 2, value 046a, tid 228, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv), queued 0.00 secs ago
2023.12.24 12:13:15.155 5: SMASI: checkDelays sendDelay, last send to same device was 53.591 secs ago, required delay is 0.1
2023.12.24 12:13:15.156 5: SMASI: checkDelays commDelay, last communication with same device was 53.578 secs ago, required delay is 0.1
2023.12.24 12:13:15.156 5: SMASI: checkDelays busDelayRead, last activity on bus was 53.578 secs ago, required delay is 5
2023.12.24 12:13:15.156 5: SMASI: checkDelays clientSwitchDelay is not relevant
2023.12.24 12:13:15.156 4: SMASI: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 00e40000000903109c8b000204046a via 192.168.1.34:502, read buffer empty, id 3, fCode 3, tid 56,
request: id 3, write fc 16 h40075, len 2, value 046a, tid 228, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv), queued 0.00 secs ago,
response: no id, no fcode
2023.12.24 12:13:15.157 5: SMASI: Send called from ProcessRequestQueue
2023.12.24 12:13:15.157 5: DevIo_SimpleWrite SMASI: 00e40000000903109c8b000204046a
2023.12.24 12:13:15.158 5: SMASI: ReadAnswer called from SetLDFn
2023.12.24 12:13:15.159 5: SMASI: ReadAnswer remaining timeout is 1.99646210670471
2023.12.24 12:13:15.174 5: SMASI: ReadAnswer got: 00e400000003039003
2023.12.24 12:13:15.174 5: SMASI: ParseFrameStart called from ReadAnswer protocol TCP expecting id 3
2023.12.24 12:13:15.174 4: SMASI: ParseFrameStart (TCP, master) extracted id 3, fCode 144, tid 228, dlen 3 and potential data 03
2023.12.24 12:13:15.175 5: SMASI: HandleResponse called from ReadAnswer
2023.12.24 12:13:15.175 5: SMASI: HandleResponse is now creating response hash, masterHash is HASH(0x55f377d1a198)
2023.12.24 12:13:15.175 5: SMASI: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55f377d1a198)
2023.12.24 12:13:15.175 5: SMASI: ParseResponse called from HandleResponse, fc 144
2023.12.24 12:13:15.176 4: SMASI: HandleResponse got response with error code 90 / 03, illegal data value
2023.12.24 12:13:15.176 4: SMASI: HandleResponse done, current frame / read buffer: 00e400000003039003, id 3, fCode 144, tid 228,
request: id 3, write fc 16 h40075, len 2, value 046a, tid 228, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 3, fc 144, error code 03, h40075, len 2
2023.12.24 12:13:15.176 5: SMASI: ResetExpect for HandleResponse from response to idle
2023.12.24 12:13:15.176 5: SMASI: DropFrame called from ReadAnswer - drop 00e400000003039003
2023.12.24 12:13:15.177 5: SMASI: set is sending read after write
2023.12.24 12:13:15.177 4: SMASI: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 3, read fc 3 h40075, len 2, tid 48, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv Rd),
response: no id, no fcode
2023.12.24 12:13:15.177 5: SMASI: QueueRequest called from DoRequest with h40075, qlen 0 from master SMASI through io device SMASI
2023.12.24 12:13:15.177 5: SMASI: ProcessRequestQueue called from QueueRequest as direct:SMASI, qlen 1, force, request: request: id 3, read fc 3 h40075, len 2, tid 48, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv Rd), queued 0.00 secs ago
2023.12.24 12:13:15.178 5: SMASI: checkDelays commDelay, last communication with same device was 0.003 secs ago, required delay is 0.1
2023.12.24 12:13:15.178 5: SMASI: checkDelays sendDelay, last send to same device was 0.019 secs ago, required delay is 0.1
2023.12.24 12:13:15.178 5: SMASI: checkDelays busDelayRead, last activity on bus was 0.003 secs ago, required delay is 5
2023.12.24 12:13:15.178 5: SMASI: checkDelays clientSwitchDelay is not relevant
2023.12.24 12:13:15.179 4: SMASI: checkDelays found busDelayRead not over, sleep for 4.997 forced
2023.12.24 12:13:20.176 4: SMASI: checkDelays sleep done, go on with sending
2023.12.24 12:13:20.177 4: SMASI: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 00300000000603039c8b0002 via 192.168.1.34:502, read buffer empty,
request: id 3, read fc 3 h40075, len 2, tid 48, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv Rd), queued 5.00 secs ago,
response: no id, no fcode

Die dem Commandline Tool ModPoll.exe (https://www.modbusdriver.com/modpoll.html) kann ich den Wert beispielsweise mit dieser Zeile richtig schreiben

modpoll -m tcp -p 502 -a 3 -t4 -r 40075 -c 2 -10 192.168.1.34 0 1130

Wenn ich nun den Wert für Eigenverbraucherhöhung auf NEIN ändern möchte, muss die Zahl 1130 per ModBus in das Register 40075 geschrieben werde. Bei SMA ist noch die Eigenart, das ein Wert immer auf zwei Register verteilt ist. Am ehesten kann man das in WireShark zeigen → Siehe Screenshot. Dort habe ich jedoch den Wert 1129 verwendet, was dem HEX Wert 469 entspricht.


Die ModBus Register von SMA kennen diese Datentypen:
TypBeschreibungNaN-Wert
S16Vorzeichenbehaftetes Wort (16 Bit).0x8000
S32Vorzeichenbehaftetes Doppelwort (32 Bit).0x8000 0000
STR3232-Byte-Datenfeld, im Format UTF8.NULL
U16Ein Wort (16 Bit).0xFFFF
U32Ein Doppelwort (32 Bit).0xFFFF FFFF
U32F&uuml;r Statuswerte werden nur die unteren 24 Bit eines Doppelworts (32 Bit) verwendet.0xFFFF FD
U64Ein Vierfachwort (64 Bit).0xFFFF FFFF FFFF
FFFF

Und das Register h40075 ist als U32 →Doppelwort deklariert.


Ich habe die starke Vermutung, das es etwas mit
unpak zu tun haben muss. Zumal hier Werte zulässig sind, die nicht in der fhem Doku gelistet sind (C,a,usw.)




::) Was muss in in fhem einstellen, damit er den Wert so schreibt, wie es im dem Bild zu sehen ist?

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: sukram am 01 Januar 2024, 21:33:12
Hallo,

dein
unpack nmacht Probleme, weil "n" nur für 16-Bit Werte gilt. Probiere mal

unpack N
Zitat von: Tabadorer am 31 Dezember 2023, 12:26:28Ich habe die starke Vermutung, das es etwas mit
Code Auswählen Erweitern
unpak zu tun haben muss. Zumal hier Werte zulässig sind, die nicht in der fhem Doku gelistet sind (C,a,usw.)

Mehr Informationen, was pack/unpack alles kann, hier: https://perldoc.perl.org/functions/pack

Man bekommt hier ganz leicht einen Knoten im Hirn, weil Perl (bzw. PC im allgemeinen) eine andere Byte-Order als Modbus bzw. die Modbus Geräte machen. Ich bin damit auch öfter gestolpert, auch weil die Darstellung negativer Zahlenwerte mitunter unterschiedlich gehandhabt wird.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tabadorer am 02 Januar 2024, 18:55:46
Zitat von: sukram am 01 Januar 2024, 21:33:12Probiere mal

unpack N

Ja der Tipp ist schon gut. Jedoch wird beim schreiben die beiden Bytes vertauscht
In meiner Definition musste ich daher diese Zeilen ändern:
attr SMASI dev-h-defUnpack N
attr SMASI dev-type-ENUM_JN-revRegs 0

Mit aktivem revRegs schreibt er den Wert 1130 statt in 40076 in das Register 40075.


Also für das Lesen benötige ich das Attribut revRegs. Beim Schreiben muss ich es weglassen, damit das klappt.


Nun bekomme nach dem erfolgreichen Schreibvorgang den Fehler
Timeout in Readanswer (in read after write for FCode 16)
Dadurch, das ich showGet aktiv habe, kann ich mit get aktiv den Wert eintragen. Und das funktioniert in dem Fall auch ohne revRegs ganz normal.
attr SMASI obj-h40075-name Eigenverbraucherhoehung eingeschaltet
attr SMASI obj-h40075-polldelay 310
attr SMASI obj-h40075-reading EigenverbraucherhoehungAktiv
attr SMASI obj-h40075-set 1
attr SMASI obj-h40075-showGet 1
attr SMASI obj-h40075-type ENUM_JN

Ich habe hier nochmal das Log vom Schreibvorgang angehängt.
2024.01.02 18:53:30.441 4: SMASI: set called with EigenverbraucherhoehungAktiv (h40075) setVal = ja
2024.01.02 18:53:30.441 5: SMASI: GetSetChecks with force
2024.01.02 18:53:30.441 5: SMASI: GetSetChecks returns success
2024.01.02 18:53:30.442 5: SMASI: MapConvert called from FormatSetVal converted ja (ja) to 1129 with reversed map ja:1129, nein:1130,
2024.01.02 18:53:30.442 5: SMASI: set packed hex 31313239 with N to hex 00000469
2024.01.02 18:53:30.442 4: SMASI: DoRequest called from SetLDFn created new request, read buffer empty, id 3, fCode 3, tid 229,
request: id 3, write fc 16 h40075, len 2, value 00000469, tid 112, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv),
response: no id, no fcode
2024.01.02 18:53:30.443 5: SMASI: QueueRequest called from DoRequest with h40075, qlen 0 from master SMASI through io device SMASI
2024.01.02 18:53:30.443 5: SMASI: ProcessRequestQueue called from QueueRequest as direct:SMASI, qlen 1, force, request: request: id 3, write fc 16 h40075, len 2, value 00000469, tid 112, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv), queued 0.00 secs ago
2024.01.02 18:53:30.443 5: SMASI: checkDelays busDelayRead, last activity on bus was 50.695 secs ago, required delay is 5
2024.01.02 18:53:30.443 5: SMASI: checkDelays sendDelay, last send to same device was 50.708 secs ago, required delay is 0.1
2024.01.02 18:53:30.444 5: SMASI: checkDelays commDelay, last communication with same device was 50.695 secs ago, required delay is 0.1
2024.01.02 18:53:30.444 5: SMASI: checkDelays clientSwitchDelay is not relevant
2024.01.02 18:53:30.444 4: SMASI: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 00700000000b03109c8b00020400000469 via 192.168.1.34:502, read buffer empty, id 3, fCode 3, tid 229,
request: id 3, write fc 16 h40075, len 2, value 00000469, tid 112, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv), queued 0.00 secs ago,
response: no id, no fcode
2024.01.02 18:53:30.444 5: SMASI: Send called from ProcessRequestQueue
2024.01.02 18:53:30.445 5: DevIo_SimpleWrite SMASI: 00700000000b03109c8b00020400000469
2024.01.02 18:53:30.446 5: SMASI: ReadAnswer called from SetLDFn
2024.01.02 18:53:30.446 5: SMASI: ReadAnswer remaining timeout is 1.99660897254944
2024.01.02 18:53:30.520 5: SMASI: ReadAnswer got: 00700000000603109c8b0002
2024.01.02 18:53:30.520 5: SMASI: ParseFrameStart called from ReadAnswer protocol TCP expecting id 3
2024.01.02 18:53:30.521 4: SMASI: ParseFrameStart (TCP, master) extracted id 3, fCode 16, tid 112, dlen 6 and potential data 9c8b0002
2024.01.02 18:53:30.521 5: SMASI: HandleResponse called from ReadAnswer
2024.01.02 18:53:30.521 5: SMASI: HandleResponse is now creating response hash, masterHash is HASH(0x55f0acfe54c0)
2024.01.02 18:53:30.521 5: SMASI: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55f0acfe54c0)
2024.01.02 18:53:30.522 5: SMASI: ParseResponse called from HandleResponse, fc 16
2024.01.02 18:53:30.522 4: SMASI: HandleResponse done, current frame / read buffer: 00700000000603109c8b0002, id 3, fCode 16, tid 112,
request: id 3, write fc 16 h40075, len 2, value 00000469, tid 112, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv), queued 0.08 secs ago, sent 0.08 secs ago,
response: id 3, fc 16, c40075, len 2
2024.01.02 18:53:30.522 5: SMASI: ResetExpect for HandleResponse from response to idle
2024.01.02 18:53:30.522 5: SMASI: DropFrame called from ReadAnswer - drop 00700000000603109c8b0002
2024.01.02 18:53:30.523 5: SMASI: set is sending read after write
2024.01.02 18:53:30.523 4: SMASI: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 3, read fc 3 h40075, len 2, tid 176, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv Rd),
response: no id, no fcode
2024.01.02 18:53:30.523 5: SMASI: QueueRequest called from DoRequest with h40075, qlen 0 from master SMASI through io device SMASI
2024.01.02 18:53:30.524 5: SMASI: ProcessRequestQueue called from QueueRequest as direct:SMASI, qlen 1, force, request: request: id 3, read fc 3 h40075, len 2, tid 176, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv Rd), queued 0.00 secs ago
2024.01.02 18:53:30.524 5: SMASI: checkDelays clientSwitchDelay is not relevant
2024.01.02 18:53:30.524 5: SMASI: checkDelays busDelayRead, last activity on bus was 0.003 secs ago, required delay is 5
2024.01.02 18:53:30.524 5: SMASI: checkDelays sendDelay, last send to same device was 0.078 secs ago, required delay is 0.1
2024.01.02 18:53:30.525 5: SMASI: checkDelays commDelay, last communication with same device was 0.003 secs ago, required delay is 0.1
2024.01.02 18:53:30.525 4: SMASI: checkDelays found busDelayRead not over, sleep for 4.997 forced
2024.01.02 18:53:35.522 4: SMASI: checkDelays sleep done, go on with sending
2024.01.02 18:53:35.523 4: SMASI: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 00b00000000603039c8b0002 via 192.168.1.34:502, read buffer empty,
request: id 3, read fc 3 h40075, len 2, tid 176, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv Rd), queued 5.00 secs ago,
response: no id, no fcode
2024.01.02 18:53:35.523 5: SMASI: Send called from ProcessRequestQueue
2024.01.02 18:53:35.523 5: DevIo_SimpleWrite SMASI: 00b00000000603039c8b0002
2024.01.02 18:53:35.525 5: SMASI: ReadAnswer called from SetLDFn
2024.01.02 18:53:35.525 5: SMASI: ReadAnswer remaining timeout is -3.00150990486145
2024.01.02 18:53:35.525 3: SMASI: Timeout in Readanswer, read buffer empty,
request: id 3, read fc 3 h40075, len 2, tid 176, master device SMASI, reading EigenverbraucherhoehungAktiv (set EigenverbraucherhoehungAktiv Rd), queued 5.00 secs ago, sent 5.00 secs ago,
response: no id, no fcode
2024.01.02 18:53:35.538 5: SMASI: readFn buffer: 00b00000000703030400000469 mode master, expect idle
2024.01.02 18:53:35.538 5: SMASI: ParseFrameStart called from ReadFn
2024.01.02 18:53:35.538 4: SMASI: ParseFrameStart (TCP, master) extracted id 3, fCode 3, tid 176, dlen 7 and potential data 0400000469
2024.01.02 18:53:35.539 3: SMASI: readfn got data while EXPECT was set to idle: 00b00000000703030400000469
2024.01.02 18:53:35.539 5: SMASI: DropBuffer for ReadFn clears the reception buffer with 00b00000000703030400000469



Das direkte Lesen nach dem schreiben müsste abgeschaltet werden, dann ist alles chique - denke ich. Oder übersehe ich da etwas?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: StefanStrobel am 03 Januar 2024, 19:25:48
Hallo,

der timeout ist ein Bug, der bisher noch nie bemerkt wurde, da Verzögerungen von mehreren Sekunden doch sehr unüblich sind (Du hast ein busDelay von 5 Sekunden eingestellt).
Hier eine neue Version zum Testen, die den Timeout bei großen Delays beseitigen sollte.

Gruss
   Stefan
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Tabadorer am 04 Januar 2024, 17:48:24
Danke. Ich habe vor dem Update den busDelay entfernt → funktioniert. Und nach dem Update geht es auch mit dem busDelay von 5s. Aber ich werden den busDelay weglassen, da ich diesen Parameter offenlichtlich nicht benötige.
Top!   :D
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: beaune am 19 Januar 2024, 11:45:58
Hallo,
ich hab einen Fall, wo beim Lesen eine anderes Modbus Holding Register anzugeben ist als beim Schreiben. Mir ist nicht ganz klar, wie ich das korrekt angeben muß, bzw. so wie ich es dachte klappt es zumindest nicht.

Im Detail sehen die Attribute für das zu schreibende Register so aus:
attr PV obj-h0037-expr $val / 10
attr PV obj-h0037-max 30
attr PV obj-h0037-min 0
attr PV obj-h0037-name 0x25
attr PV obj-h0037-poll 0
attr PV obj-h0037-reading BatteryDischargeMaxCurrent
attr PV obj-h0037-set 1
attr PV obj-h0037-setexpr $val * 10
attr PV obj-h0037-showGet 0
attr PV obj-h0037-type unsigned short
Das funktioniert so auch, mache ich z.B. ein set PV BatteryDischargeMaxCurrent 28, dann kommt 280 im Register an und im Reading steht 28. Alles gut.

Wenn ich nun aber diesen Wert explizit lesen möchte, muß ich das über eine andere Registernummer tun. Das sieht so aus:
attr PV obj-h0145-expr $val / 10
attr PV obj-h0145-name 0x91
attr PV obj-h0145-poll 0
attr PV obj-h0145-reading BatteryDischargeMaxCurrent
attr PV obj-h0145-showGet 1
attr PV obj-h0145-type unsigned short

Und dann gibts ein Problem:

Ich möchte natürlich nur ein Reading verwenden, weil es sich aus Gerätesicht um denselben Parameter handelt. Aber das scheint zumindest so, wie ich es gemacht habe, nicht zu gehen. Mache ich was falsch, oder geht das schlicht nicht?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 19 Januar 2024, 21:07:46
Ich kenne eine ähnliche Situation von HTTPMOD wo ich auch bei einem Gerät Werte nur auf unterschiedliche Wegen lesen und schreiben kann. Ich denke nicht, dass du das innerhalb vom Modbus Modul auflösen kannst. Was ich gemacht habe: alles in ein Dummy ausgelagert (resp. DOIF), dort habe ich dann mein Reading welches dann via Notifies mit meinen HTTPMOD Devices abgeglichen wird. Im ersten Moment erscheint das umständlich, wenn du allerdings sowieso eine gewisse Logik einbauen möchtest (z.B. dein BatteryDischargeMaxCurrent abhängig von anderen Zuständen zu setzen) wird dieses Auslagern plötzlich hilfreich.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: ukdirk am 14 Februar 2024, 14:13:40
Zitat von: Tedious am 01 Oktober 2021, 16:23:01Hallo Stefan,

vielen Dank für Deine Geduld. Ich hab den Schritt vom Schlauch runter hinbekommen, läuft jetzt. Zur Doku für die Nachwelt, falls jemand mal einen Herz Pelletstar Condendation einbinden will hier ein Teil der Konfig als Guideline. Ist noch nicht komplett, aber das Muster ist klar, insofern kann ich jetzt nach und nach alle Parameter reinbauen.

defmod Pelletheizung ModbusAttr 1 60 192.168.192.86:502 TCP
attr Pelletheizung group Pelletheizung
attr Pelletheizung obj-h00000-expr $val/10
attr Pelletheizung obj-h00000-len 2
attr Pelletheizung obj-h00000-poll 1
attr Pelletheizung obj-h00000-reading Kesseltemperatur
attr Pelletheizung obj-h00000-unpack N
attr Pelletheizung obj-h00002-expr $val/10
attr Pelletheizung obj-h00002-len 2
attr Pelletheizung obj-h00002-poll 1
attr Pelletheizung obj-h00002-reading Bedarfstemperatur_Kessel
attr Pelletheizung obj-h00002-unpack N
attr Pelletheizung obj-h00004-len 2
attr Pelletheizung obj-h00004-poll 1
attr Pelletheizung obj-h00004-reading Kesselstatus
attr Pelletheizung obj-h00004-unpack N
attr Pelletheizung obj-h00006-expr $val/10
attr Pelletheizung obj-h00006-len 2
attr Pelletheizung obj-h00006-poll 1
attr Pelletheizung obj-h00006-reading Kesselleistung
attr Pelletheizung obj-h00006-unpack N
attr Pelletheizung obj-h01362-expr $val/10
attr Pelletheizung obj-h01362-len 2
attr Pelletheizung obj-h01362-poll 1
attr Pelletheizung obj-h01362-reading Kollektor-Rücklauf
attr Pelletheizung obj-h01362-unpack N
attr Pelletheizung obj-h01364-expr $val/10
attr Pelletheizung obj-h01364-len 2
attr Pelletheizung obj-h01364-poll 1
attr Pelletheizung obj-h01364-reading Kollektor-Vorlauf
attr Pelletheizung obj-h01364-unpack N
attr Pelletheizung obj-h01366-expr $val/10
attr Pelletheizung obj-h01366-len 2
attr Pelletheizung obj-h01366-poll 1
attr Pelletheizung obj-h01366-reading Speichertemperatur
attr Pelletheizung obj-h01366-unpack N
attr Pelletheizung obj-h01368-reading scan-h01368
attr Pelletheizung obj-h01370-expr $val/10
attr Pelletheizung obj-h01370-len 2
attr Pelletheizung obj-h01370-poll 1
attr Pelletheizung obj-h01370-reading Pumpendrehzahl
attr Pelletheizung obj-h01370-unpack N
attr Pelletheizung obj-h01378-expr $val/10
attr Pelletheizung obj-h01378-len 2
attr Pelletheizung obj-h01378-poll 1
attr Pelletheizung obj-h01378-reading Ertrag-aktuell
attr Pelletheizung obj-h01378-unpack N
attr Pelletheizung room Heizung

Hi Tedious,

vielen Dank für die Arbeit. Das hilft sehr weiter. Hast Du noch mehr Register hinzugefügt?

Viele Grüße,
Dirk
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: WW am 18 Februar 2024, 21:35:42
Zitat von: oniT am 15 Oktober 2019, 21:58:59Hallo 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



Ich habe ein ähnliches Problem und komme hier nicht weiter. Um bei meinem Azzurro-Wechselrichter die max. Entladetiefe zu setzen, muss ein Block von 16 Registern in einem geschrieben werden.

Ich lese die 16 Register aus und schreibe sie in ein Reading:

attr myWechselrichter obj-h04164-len 16
attr myWechselrichter obj-h04164-poll 0
attr myWechselrichter obj-h04164-reading Bat1_Config
attr myWechselrichter obj-h04164-showGet Bat1_Config
attr myWechselrichter obj-h04164-unpack H*

Das Reading "Bat1_Config" wird auch angelegt:
setstate myWechselrichter 2024-02-18 21:06:38 Bat1_Config 00000000000113880000000001a409c409c400500050006411940000000a0000

Die 64 Zeichen repräsentieren die 16 gelesenen Register. Ich müsste nun das 9. Register mit der neuen Entladetiefe ersetzen und im letzten Register die "0000" in "0001" ändern. Und dann die ganzen 16 Register beginnend ab Adresse 4164 zurückschreiben. Und genau an dieser Stelle scheitere ich. Wie kann ich die Änderungen vornehmen und dann schreiben. Hängt vermutlich an meinen mangelnden Kenntnissen bezüglich pack/unpack.

Vielen Dank für Anregungen
Willi
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: WW am 27 Februar 2024, 19:34:31
Niemand eine Anregung für mich?

MfG
Willi
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 27 Februar 2024, 21:06:53
Naja, die Lösung steht ja schon (fast) in deinem zitierten Post. Mit einem

attr myWechselrichter obj-h04164-setexpr '00000000000113880000000001a409c409c40'.unpack("H4", pack("n", $val)).'00050006411940000000a0001'
könnte es klappen.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: WW am 27 Februar 2024, 21:17:28
Zitat von: Aurel_B am 27 Februar 2024, 21:06:53Naja, die Lösung steht ja schon (fast) in deinem zitierten Post. Mit einem

attr myWechselrichter obj-h04164-setexpr '00000000000113880000000001a409c409c40'.unpack("H4", pack("n", $val)).'00050006411940000000a0001'
könnte es klappen.

Leider ist es nicht ganz so einfach: Die Werte der anderen 14 Register ist nicht fest, sondern von anderen Parametern abhängig. Ich müsste also erst die 16 Register lesen, das 9. und das letze Register anpassen und dann die so modifizierten 16 Register zurückschreiben. Also Register 1-8 und 10-15 irgendwie auch mit unpack/pack behandeln(?)
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: 300P am 27 Februar 2024, 21:33:30
schau mal hier, da war es ähnlich....:  ;)

https://forum.fhem.de/index.php?topic=75638.350
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: WW am 27 Februar 2024, 21:47:12
Zitat von: WW am 18 Februar 2024, 21:35:42...
attr myWechselrichter obj-h04164-len 16
attr myWechselrichter obj-h04164-poll 0
attr myWechselrichter obj-h04164-reading Bat1_Config
attr myWechselrichter obj-h04164-showGet Bat1_Config
attr myWechselrichter obj-h04164-unpack H*

Das Reading "Bat1_Config" wird auch angelegt:
setstate myWechselrichter 2024-02-18 21:06:38 Bat1_Config 00000000000113880000000001a409c409c400500050006411940000000a0000
....

Ich stehe immer noch auf dem Schlauch: Im Reading "Bat1_Config" habe ich ja meine 16 Register als Hex-String. Wie kann ich denn hieraus Teile extrahieren (z.B. Register 1-8 bzw. 10-15)? DIe normalen String-Operationen scheinen hier nicht zu funktionieren. Mir ist nicht klar, was ein Hex-String überhaupt ist.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 27 Februar 2024, 23:00:04
Hmmmm, das tönt in der Tat nicht ganz einfach. Was ich machen würde: die ganze Logik in ein separates DOIF auslagen (im Perl Modus) und mir dort Stück für Stück das ganze Register zusammenbauen, so à la

defmod RegisterKonstruieren DOIF {
my $register = unpack("H4", pack("n", ReadingsVal("Foo", "Register1", undef)));
$register .= unpack("H4", pack("n", ReadingsVal("Bar", "Register2", undef)));
}

etc. etc. Macht das so Sinn?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: Aurel_B am 27 Februar 2024, 23:09:30
Zitat von: WW am 27 Februar 2024, 21:47:12Ich stehe immer noch auf dem Schlauch: Im Reading "Bat1_Config" habe ich ja meine 16 Register als Hex-String. Wie kann ich denn hieraus Teile extrahieren (z.B. Register 1-8 bzw. 10-15)? DIe normalen String-Operationen scheinen hier nicht zu funktionieren. Mir ist nicht klar, was ein Hex-String überhaupt ist.


Ein Hex-String würde ich mal einfach als einen String voller Hex-Werten betrachten :-) Im Prinzip müsste irgendwo in der Dokus deines Wechselrichters stehen, was denn genau für Werte in diesem String stecken. Wenn z.B. immer 4 Hex-Werte für einen Wert stehen, so hast du 4x4bit == 16bit, könnte z.B. ein signed short sein. Schau dir z.B. Bitoperationen an, damit kannst du jeweils 16bit aus deinem String extrahieren und dann mit der unpack Funktion in einen vernünftigen Wert umwandeln.

Vielleicht wäre es hilfreich, wenn du uns einen Link zur Modbus Beschreibung deines Wechselrichters posten könntest damit wir mehr verstehen. Generell scheint es mir schade, dass scheinbar alles in ein übergrosses Register gepackt wurde. Dieser riesige Hex-Wert gehört IMHO eigentlich alles in separate Register, das ist ja Sinn und Zweck der Register! Und für einzelne Bits gibt/gäbe es Coils!
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 22 März 2024, 10:10:00
Hallo zusammen.

Nachdem mehreren vergeblichen Versuche mit dem Modul SMAInverter möchte ich nun nun ModbusAttr ausprobieren, um endlich auf meinen Wechselrichter SMA SB3600 zugreifen zu können.
Grundsätzlich muss das via Modbus möglich sein, denn ich habe ich im Loxone-Forum (https://www.loxforum.com/forum/faqs-tutorials-howto-s/203-sma-wechselrichter-per-modbus-auslesen-am-beispiel-sma-sb3600-se) genau dazu etwas dazu gefunden.

Allerdings mir ist überhaupt nicht klar, wie ich das in FHEM eingebunden bekomme.
Dazu zunächst zwei fundamentale Fragen:

Es würde mir zunächst reichen, die erzeugte Leistung vom WR abrufen zu können.
Dafür wäre es toll, wenn mir jemand die notwendige Starthilfe geben könnte.
Hier ist noch die SMA-Modbus Dokumentation (https://files.sma.de/downloads/EDMx-Modbus-TI-de-16.pdf) dazu.

Vielen Dank vorab!
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: 300P am 22 März 2024, 13:25:28
Hallo DocCyber,

A:
Netzwerkkabel reicht - nur musst du im WR das Modbusprotokoll einschalten. (Meist Port 502)

B:
Hier ein kurzes Beispiel für dich das auch funktioniert.
Den Rest bzw. weitere Adressen solltest du dann selber anpassen:
(Bei mir ist es aber ein SB30 ->> Wirkleistung = Adr. h30775 - sollte bei dir auch passen)

defmod MB_SB30 ModbusAttr 3 60 192.168.YYY.XXX:502 TCP
attr MB_SB30 DbLogExclude .*
attr MB_SB30 dev-h-defExpr $val
attr MB_SB30 dev-h-defIgnoreExpr (( $val==536870911 ) || ( $val ==2147483648 ) || ( $val ==4294967295 ))
attr MB_SB30 dev-h-defLen 2
attr MB_SB30 dev-h-defPoll 1
attr MB_SB30 dev-h-defUnpack N
attr MB_SB30 dev-type-S32F0-expr $val
attr MB_SB30 dev-type-S32F0-format %.0f
attr MB_SB30 dev-type-S32F0-len 2
attr MB_SB30 dev-type-S32F0-unpack i>
attr MB_SB30 enableControlSet 1
attr MB_SB30 obj-h30775-reading Wirkleistung
attr MB_SB30 obj-h30775-type S32F0
attr MB_SB30 obj-h30775-poll 1
attr MB_SB30 room 011_MODBUS
attr MB_SB30 verbose 2


Gruß
300P
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 22 März 2024, 14:07:35
Super!
Das klappt nach kleinen Anpassungen auf Anhieb!
Hat zwar etwas gedauert, bis der erste Leistungswert kam, aber es funktioniert!

Vielen herzlichen Dank!
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: 300P am 22 März 2024, 15:22:27
Zitat von: DocCyber am 22 März 2024, 14:07:35Hat zwar etwas gedauert, bis der erste Leistungswert kam, aber es funktioniert!

Ja - dauert immer ein paar "Sekunden/Minuten" ehe die erste saubere Antwort kommt, scheinbar "schlafen" die Modbusregister bei SMA-WR immer sehr tief ehe sie reagieren.  :o
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 22 März 2024, 16:09:45
Zitat von: 300P am 22 März 2024, 15:22:27scheinbar "schlafen" die Modbusregister bei SMA-WR immer sehr tief
:)
Hauptsache, es funktioniert überhaupt.

Nachdem ModbusAttr also beim SMA WR funktioniert, habe ich das selbe nun bei meinem zweiten WR (Solis) auch probiert.
Die Verbindung als solche scheint zu stehen (State: opened)
In der -etwas spärlichen- Doku von Solis werden aber word, dword, int und smallInt als Datentypen genannt, während in der ModbusAttr-CommandRef deutlich mehr / andere Datentypen genannt werden.
Wie kann ich die Datentypen von Solis in die von ModbusAttr "übersetzen"?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 23 März 2024, 11:23:54
@DocCyber

schau mal hier, da gibt es schon einige Infos.
 
https://forum.fhem.de/index.php?topic=134167.0 (https://forum.fhem.de/index.php?topic=134167.0)

pejonp
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 23 März 2024, 16:53:47
Zitat von: pejonp am 23 März 2024, 11:23:54da gibt es schon einige Infos.
Danke, das seh ich mir an.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 25 März 2024, 19:34:50
Zitat von: 300P am 22 März 2024, 13:25:28Hier ein kurzes Beispiel für dich das auch funktioniert.

Es hatte funktioniert .. aber jetzt?

Ich möchte ein sehr merkwürdiges Phänomen beschreiben.
Zunächst habe ich - dank deiner Starthilfe - noch einige weitere Readings eingebaut, und alles lief gut.
Heute Mittag - ich war zuvor außer Haus - kamen dann plötzlich keine Daten mehr: State disconnected.
Nach einigem Forschen habe ich dann herausgefunden, dass der SMA und mein Handy merkwürdigerweise die selbe IP-Adresse hatten (sollte eig. nicht vorkommen).
Also habe ich das Handy auf eine andere IP gesetzt, und siehe da: State opened

Aber das ist die einzig positive Meldung, denn seitdem erhalte ich keinerlei Readings mehr vom SMA.
Ich habe dann das SMA-Modbus-Device gelöscht und neu angelegt; später auch nochmal mit einer absoluten Minimalkonfiguration, auch den fhem Server neu gestartet...
Aber nichts!

Ich habe keinerlei Erklärung.
Weiß jemand Rat?
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 25 März 2024, 19:56:47
Zitat von: pejonp am 23 März 2024, 11:23:54schau mal hier, da gibt es schon einige Infos.
Sehr guter Tipp: Solisabfrage per Modbus läuft prima.

Falls es noch jemanden interessiert:
Mein Modell ist ein S5-GR3P8K, und hier meine ModbusAttr-Definition
define solis ModbusAttr 1 60 192.168.xxx.xxx:502 TCP
attr solis comment Readings Units\
* energyDay      Energie heute kWh\
* energyDay-1    Energie Vortag kWh\
* energyMonth    Energie Monat kWh\
* energyMonth-1  Energie Vormonat kWh\
* energyYear     Energie Jahr kWh\
* energyYear-1   Energie Vorjahr kWh\
* energyTotal    Energie ingesamt kWh\
* power          aktuelle solare Leistung W\
* inverterTemperature  Temperatur °C
attr solis dev-h-combine 5
attr solis dev-h-defLen 2
attr solis dev-h-defShowGet 1
attr solis dev-h-defUnpack f>
attr solis dev-h-read 3
attr solis dev-h-write 16
attr solis dev-i-combine 5
attr solis dev-i-defLen 2
attr solis dev-i-defPoll 1
attr solis dev-i-defShowGet 1
attr solis dev-i-defUnpack f>
attr solis dev-i-read 4
attr solis dev-timing-commDelay 0.7
attr solis dev-timing-sendDelay 0.7
attr solis dev-timing-timeout 2
attr solis event-min-interval state:900
attr solis event-on-change-reading .*
attr solis group Inverter
attr solis obj-i3004-len 2
attr solis obj-i3004-poll 1
attr solis obj-i3004-reading power
attr solis obj-i3004-unpack N
attr solis obj-i3008-len 2
attr solis obj-i3008-poll 1
attr solis obj-i3008-reading energyTotal
attr solis obj-i3008-unpack N
attr solis obj-i3010-len 2
attr solis obj-i3010-poll 1
attr solis obj-i3010-reading energyMonth
attr solis obj-i3010-unpack N
attr solis obj-i3012-len 2
attr solis obj-i3012-poll 1
attr solis obj-i3012-reading energyMonth-1
attr solis obj-i3012-unpack N
attr solis obj-i3014-expr $val/10
attr solis obj-i3014-format %.1f
attr solis obj-i3014-poll 1
attr solis obj-i3014-reading energyDay
attr solis obj-i3014-unpack n
attr solis obj-i3015-expr $val/10
attr solis obj-i3015-format %.1f
attr solis obj-i3015-poll 1
attr solis obj-i3015-reading energyDay-1
attr solis obj-i3015-unpack n
attr solis obj-i3016-format %.0f
attr solis obj-i3016-len 2
attr solis obj-i3016-poll 1
attr solis obj-i3016-reading energyYear
attr solis obj-i3016-unpack N
attr solis obj-i3018-format %.0f
attr solis obj-i3018-len 2
attr solis obj-i3018-poll 1
attr solis obj-i3018-reading energyYear-1
attr solis obj-i3018-unpack N
attr solis obj-i3041-expr $val/10
attr solis obj-i3041-format %.1f
attr solis obj-i3041-poll 1
attr solis obj-i3041-reading inverterTemperature
attr solis obj-i3041-unpack n
attr solis obj-i3043-len 2
attr solis obj-i3043-map 0:Generating,1:OpenRun,2:Waiting,3:Initializing,4:GridOff
attr solis obj-i3043-poll 1
attr solis obj-i3043-reading inverterStatus
attr solis obj-i3043-revRegs 1
attr solis obj-i3043-unpack n
attr solis room 50_PV
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: 300P am 25 März 2024, 20:13:54
Zitat von: DocCyber am 25 März 2024, 19:34:50
Zitat von: 300P am 22 März 2024, 13:25:28Hier ein kurzes Beispiel für dich das auch funktioniert.

Es hatte funktioniert .. aber jetzt?

Ich möchte ein sehr merkwürdiges Phänomen beschreiben.
Zunächst habe ich - dank deiner Starthilfe - noch einige weitere Readings eingebaut, und alles lief gut.
Heute Mittag - ich war zuvor außer Haus - kamen dann plötzlich keine Daten mehr: State disconnected.
Nach einigem Forschen habe ich dann herausgefunden, dass der SMA und mein Handy merkwürdigerweise die selbe IP-Adresse hatten (sollte eig. nicht vorkommen).
Also habe ich das Handy auf eine andere IP gesetzt, und siehe da: State opened

Aber das ist die einzig positive Meldung, denn seitdem erhalte ich keinerlei Readings mehr vom SMA.
Ich habe dann das SMA-Modbus-Device gelöscht und neu angelegt; später auch nochmal mit einer absoluten Minimalkonfiguration, auch den fhem Server neu gestartet...
Aber nichts!

Ich habe keinerlei Erklärung.
Weiß jemand Rat?

Du solltest für alle Geräte - die zu der PV-Anlage gehören bzw. auch die die von FHEM angesprochen werden - immer eine feste IP-Adresse in deinem DHCP/Server (?Fritzbox?!) ausserhalb des frei verfügbaren IP-Bereiches reservieren / festlegen. Dann passiert dies nicht.

Ansonsten gibt es immer wieder Probleme wenn sich diese ,,mal wieder" ändern.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 26 März 2024, 08:03:05
Zitat von: 300P am 25 März 2024, 20:13:54Du solltest für alle Geräte - die zu der PV-Anlage gehören bzw. auch die die von FHEM angesprochen werden - immer eine feste IP-Adresse in deinem DHCP/Server (?Fritzbox?!) ausserhalb des frei verfügbaren IP-Bereiches reservieren / festlegen. Dann passiert dies nicht.
Das war auch vorher schon klar, aber es ist keine Lösung des Problems:
Es gibt keine Zugriff mehr auf das Gerät, obwohl der IP-Adresskonflikt nicht mehr besteht, und obwohl zuvor alles lief.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: pejonp am 26 März 2024, 09:29:00
@doccyber

Kannst du den Sma anpingen ?
Sma neu gestartet damit er sich die ip neu zieht?
Hat der sma eine weboberfläche ?
Zufällig noch ein wechselrichter im Netz?

Pejonp
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: 300P am 26 März 2024, 10:35:57
@DocCyber:

Evtl. mal vor Ort am Gerät Direkt-Verbindung versuchen:


Per WLAN vor Ort am WR verbinden:

WLAN-Passwortsiehe hier:
SMA-WLAN-Direktverbindung Passwort.png

und dann :
Standard-IP-Adresse des Wechselrichters für Direktverbindung via WLAN: =>> 192.168.12.3

oder auch:

In die Adresszeile des Webbrowsers, wenn Ihr Gerät mDNS-Dienste unterstützt, SMA[Seriennummer].local oder https://SMA[Seriennummer] eingeben und die Eingabetaste drücken.

Alternative per Ethernet (Kabel-Verbindung)

Standard-IP-Adresse des Wechselrichters für Direktverbindung via Ethernet: =>> 169.254.12.3

oder auch hier versuchen:

In die Adresszeile des Webbrowsers, wenn Ihr Gerät mDNS-Dienste unterstützt, SMA[Seriennummer].local oder https://SMA[Seriennummer] eingeben und die Eingabetaste drücken.

Dann kannst du auf der Weboberfläche sehen welche IP-Adressen der WR sich selbst "automatisch geholt halt".

Gruß
300P
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 26 März 2024, 19:54:23
Zitat von: pejonp am 26 März 2024, 09:29:00@doccyber

Kannst du den Sma anpingen ?
Sma neu gestartet damit er sich die ip neu zieht?
Hat der sma eine weboberfläche ?
Zufällig noch ein wechselrichter im Netz?

Pejonp

Es funktioniert wieder!

Ich hatte den WR schon gestern ausgeschaltet, weil ich mir dadurch die Lösung erwartet hatte.
Nur: Ausschalten reichte nicht! Man muss den WR vollständig vom Stromnetz nehmen, also Sicherungen raus!
Das war's...

Hier noch ein paar Antworten auf die gestellten Frage:
Nein, mein SMA WR hat kein WebInterface und kein WLAN.
Ja, es ist noch ein zweiter WR im Netz, aber einer von Solis. (Der Modbus-Zugriff darauf war zu keiner Zeit gestört)


Nochmals kurz zusammengefasst:
Ein IP-Adresskonflikt (unbekannte Gründe) mit dem SMA WR hatte dazu geführt, dass dessen Modbus nicht mehr ansprechbar war. Hard-Reset des Wechselrichters hat das Problem schließlich gelöst.
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 28 März 2024, 14:01:37
Hallo zusammen,

ich möchte euch gern nochmal um Hilfe bitte, diesmal für den Abruf von Daten vom Elgris Smart Meter.
Zunächst hatte ich SMAEM verwendet. Das funktioniert, aber es werden für meine Zwecke unnötig viele Daten abgerufen. Aktuelle mache ich es mit HHTPMod. Das funktioniert auch.

Da ich aber mittlerweile - nicht zuletzt durch eure Hilfe - meine beiden Wchselrichter von SMA und Solis erfolgreich mit ModbusAttr auslesen kann, möchte ich das auch für Elgris machen.

Doch offenbar ist ModbusAttr nicht mein bester Freund, denn ich bekomme es nicht hin.
Allerdings ist der Port wohl geöffnet:
define elgris ModbusAttr 1 60 192.168.178.29:502 TCP
attr elgris group Energie
attr elgris obj-h40052-len 16
attr elgris obj-h40052-reading serialNumber
attr elgris obj-h40085-reading I_AC_Frequency
attr elgris obj-h40087-len 2
attr elgris obj-h40087-reading power
attr elgris obj-h40087-unpack i>
attr elgris obj-i40052-len 16
attr elgris obj-i40052-reading serialNumber
attr elgris obj-i40087-len 2
attr elgris obj-i40087-reading power
attr elgris room 50_PV
attr elgris showError 1
attr elgris verbose 5
#   CFGFN     
#   DEF        1 60 192.168.xxx.xxx:502 TCP
#   DeviceName 192.168.xxx.xxx:502
#   EXPECT     idle
#   FD         18
#   FUUID      66042320-f33f-8be1-c8f8-c094144c85c08eca
#   IODev      elgris
#   Interval   60
#   LASTOPEN   1711630652.40479
#   MODBUSID   1
#   MODE       master
#   MODULEVERSION Modbus 4.5.6 - 7.11.2023
#   NAME       elgris
#   NOTIFYDEV  global
#   NR         986
#   NTFY_ORDER 50-elgris
#   PARTIAL   
#   PROTOCOL   TCP
#   STATE      opened
#   TCPConn    1
#   TYPE       ModbusAttr
#   devioLoglevel 3
#   devioNoSTATE 1
#   eventCount 4186
#   nextOpenDelay 60
#   READ:
#     BUFFER    
#   READINGS:
#     2024-03-28 13:57:32   state           opened
#   REMEMBER:
#     lid        130
#     lname      elgris
#     lrecv      1711563843.78974
#     lsend      1711563842.78221
#   UPDATECACHE:
#   defptr:
#     elgris     1
#   lastRead:
#
setstate elgris opened
setstate elgris 2024-03-28 13:57:32 state opened

Der Wert an Adresse 40087 (Total real power) reicht mir aus.

Vielen Dank vorab!

Elgris Doku angehängt
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: 300P am 28 März 2024, 16:08:21
Ich habe es zwar aktuell nicht mehr aktiv im FHEM eingebunden.....

Aber hier mein Ergebnis bei einem set elgris scanModbusObjects h40000-h40150:
==>Modbus TCP sollte also mit ELGRIS funktionieren!

defmod elgris ModbusAttr 1 30 192.168.XXX.YYY:502 TCP
attr elgris group Elgris
attr elgris obj-h40000-reading scan-h40000
attr elgris obj-h40001-reading scan-h40001
attr elgris obj-h40002-reading scan-h40002
attr elgris obj-h40003-reading scan-h40003
attr elgris obj-h40004-reading scan-h40004
attr elgris obj-h40005-reading scan-h40005
attr elgris obj-h40006-reading scan-h40006
attr elgris obj-h40007-reading scan-h40007
attr elgris obj-h40008-reading scan-h40008
attr elgris obj-h40009-reading scan-h40009
attr elgris obj-h40010-reading scan-h40010
attr elgris obj-h40011-reading scan-h40011
attr elgris obj-h40012-reading scan-h40012
attr elgris obj-h40013-reading scan-h40013
attr elgris obj-h40014-reading scan-h40014
attr elgris obj-h40015-reading scan-h40015
attr elgris obj-h40016-reading scan-h40016
attr elgris obj-h40017-reading scan-h40017
attr elgris obj-h40018-reading scan-h40018
attr elgris obj-h40019-reading scan-h40019
attr elgris obj-h40020-reading scan-h40020
attr elgris obj-h40021-reading scan-h40021
attr elgris obj-h40022-reading scan-h40022
attr elgris obj-h40023-reading scan-h40023
attr elgris obj-h40024-reading scan-h40024
attr elgris obj-h40025-reading scan-h40025
attr elgris obj-h40026-reading scan-h40026
attr elgris obj-h40027-reading scan-h40027
attr elgris obj-h40028-reading scan-h40028
attr elgris obj-h40029-reading scan-h40029
attr elgris obj-h40030-reading scan-h40030
attr elgris obj-h40031-reading scan-h40031
attr elgris obj-h40032-reading scan-h40032
attr elgris obj-h40033-reading scan-h40033
attr elgris obj-h40034-reading scan-h40034
attr elgris obj-h40035-reading scan-h40035
attr elgris obj-h40036-reading scan-h40036
attr elgris obj-h40037-reading scan-h40037
attr elgris obj-h40038-reading scan-h40038
attr elgris obj-h40039-reading scan-h40039
attr elgris obj-h40040-reading scan-h40040
attr elgris obj-h40041-reading scan-h40041
attr elgris obj-h40042-reading scan-h40042
attr elgris obj-h40043-reading scan-h40043
attr elgris obj-h40044-reading scan-h40044
attr elgris obj-h40045-reading scan-h40045
attr elgris obj-h40046-reading scan-h40046
attr elgris obj-h40047-reading scan-h40047
attr elgris obj-h40048-reading scan-h40048
attr elgris obj-h40049-reading scan-h40049
attr elgris obj-h40050-reading scan-h40050
attr elgris obj-h40051-reading scan-h40051
attr elgris obj-h40052-reading scan-h40052
attr elgris obj-h40053-reading scan-h40053
attr elgris obj-h40054-reading scan-h40054
attr elgris obj-h40055-reading scan-h40055
attr elgris obj-h40056-reading scan-h40056
attr elgris obj-h40057-reading scan-h40057
attr elgris obj-h40058-reading scan-h40058
attr elgris obj-h40059-reading scan-h40059
attr elgris obj-h40060-reading scan-h40060
attr elgris obj-h40061-reading scan-h40061
attr elgris obj-h40062-reading scan-h40062
attr elgris obj-h40063-reading scan-h40063
attr elgris obj-h40064-reading scan-h40064
attr elgris obj-h40065-reading scan-h40065
attr elgris obj-h40066-reading scan-h40066
attr elgris obj-h40067-reading scan-h40067
attr elgris obj-h40068-reading scan-h40068
attr elgris obj-h40069-reading scan-h40069
attr elgris obj-h40070-reading scan-h40070
attr elgris obj-h40071-reading scan-h40071
attr elgris obj-h40072-reading scan-h40072
attr elgris obj-h40073-reading scan-h40073
attr elgris obj-h40074-reading scan-h40074
attr elgris obj-h40075-reading scan-h40075
attr elgris obj-h40076-reading scan-h40076
attr elgris obj-h40077-reading scan-h40077
attr elgris obj-h40078-reading scan-h40078
attr elgris obj-h40079-reading scan-h40079
attr elgris obj-h40080-reading scan-h40080
attr elgris obj-h40081-reading scan-h40081
attr elgris obj-h40082-reading scan-h40082
attr elgris obj-h40083-reading scan-h40083
attr elgris obj-h40084-reading scan-h40084
attr elgris obj-h40085-reading I_AC_Frequency
attr elgris obj-h40086-reading Hz_Sf
attr elgris obj-h40087-reading scan-h40087
attr elgris obj-h40088-reading Leistung_A
attr elgris obj-h40089-reading Leistung_B
attr elgris obj-h40090-reading Leistung_C
attr elgris obj-h40091-reading scan-h40091
attr elgris obj-h40092-reading scan-h40092
attr elgris obj-h40093-reading scan-h40093
attr elgris obj-h40094-reading scan-h40094
attr elgris obj-h40095-reading scan-h40095
attr elgris obj-h40096-reading scan-h40096
attr elgris obj-h40097-reading scan-h40097
attr elgris obj-h40098-reading scan-h40098
attr elgris obj-h40099-reading scan-h40099
attr elgris obj-h40100-reading scan-h40100
attr elgris obj-h40101-reading scan-h40101
attr elgris obj-h40102-reading scan-h40102
attr elgris obj-h40103-reading scan-h40103
attr elgris obj-h40104-reading scan-h40104
attr elgris obj-h40105-reading scan-h40105
attr elgris obj-h40106-reading scan-h40106
attr elgris obj-h40107-reading scan-h40107
attr elgris obj-h40108-reading scan-h40108
attr elgris obj-h40109-reading scan-h40109
attr elgris obj-h40110-reading scan-h40110
attr elgris obj-h40111-reading scan-h40111
attr elgris obj-h40112-reading scan-h40112
attr elgris obj-h40113-reading scan-h40113
attr elgris obj-h40114-reading scan-h40114
attr elgris obj-h40115-reading scan-h40115
attr elgris obj-h40116-reading scan-h40116
attr elgris obj-h40117-reading scan-h40117
attr elgris obj-h40118-reading scan-h40118
attr elgris obj-h40119-reading scan-h40119
attr elgris obj-h40120-reading scan-h40120
attr elgris obj-h40121-reading scan-h40121
attr elgris obj-h40122-reading scan-h40122
attr elgris obj-h40123-reading scan-h40123
attr elgris obj-h40124-reading scan-h40124
attr elgris obj-h40125-reading scan-h40125
attr elgris obj-h40126-reading scan-h40126
attr elgris obj-h40127-reading scan-h40127
attr elgris obj-h40128-reading scan-h40128
attr elgris obj-h40129-reading scan-h40129
attr elgris obj-h40130-reading scan-h40130
attr elgris obj-h40131-reading scan-h40131
attr elgris obj-h40132-reading scan-h40132
attr elgris obj-h40133-reading scan-h40133
attr elgris obj-h40134-reading scan-h40134
attr elgris obj-h40135-reading scan-h40135
attr elgris obj-h40136-reading scan-h40136
attr elgris obj-h40137-reading scan-h40137
attr elgris obj-h40138-reading scan-h40138
attr elgris obj-h40139-reading scan-h40139
attr elgris obj-h40140-reading scan-h40140
attr elgris obj-h40141-reading scan-h40141
attr elgris obj-h40142-reading scan-h40142
attr elgris obj-h40143-reading scan-h40143
attr elgris obj-h40144-reading scan-h40144
attr elgris obj-h40145-reading scan-h40145
attr elgris obj-h40146-reading scan-h40146
attr elgris obj-h40147-reading scan-h40147
attr elgris obj-h40148-reading scan-h40148
attr elgris obj-h40149-reading scan-h40149
attr elgris obj-h40150-reading scan-h40150
attr elgris obj-i40052-len 16
attr elgris obj-i40052-reading serialNumber
attr elgris obj-i40087-len 1
attr elgris obj-i40087-reading power
attr elgris room 011_MODBUS,Energie
attr elgris showError 1

setstate elgris 2024-03-28 15:59:29 Hz_Sf hex=fffe, string=.., s=-257, s>=-2, S=65279, S>=65534
setstate elgris 2024-03-28 15:59:28 I_AC_Frequency hex=1388, string=.., s=-30701, s>=5000, S=34835, S>=5000
setstate elgris 2024-03-28 15:36:04 LAST_ERROR slave replied with error code 83 / 02, illegal data address
setstate elgris 2024-03-28 15:59:31 Leistung_A hex=002f, string=./, s=12032, s>=47, S=12032, S>=47
setstate elgris 2024-03-28 15:59:32 Leistung_B hex=00dd, string=.., s=-8960, s>=221, S=56576, S>=221
setstate elgris 2024-03-28 15:59:33 Leistung_C hex=fef5, string=.., s=-2562, s>=-267, S=62974, S>=65269
setstate elgris 2024-03-28 15:58:01 scan-h40000 hex=5375, string=Su, s=30035, s>=21365, S=30035, S>=21365
setstate elgris 2024-03-28 15:58:02 scan-h40001 hex=6e53, string=nS, s=21358, s>=28243, S=21358, S>=28243
setstate elgris 2024-03-28 15:58:03 scan-h40002 hex=0001, string=.., s=256, s>=1, S=256, S>=1
setstate elgris 2024-03-28 15:58:04 scan-h40003 hex=0041, string=.A, s=16640, s>=65, S=16640, S>=65
setstate elgris 2024-03-28 15:58:05 scan-h40004 hex=656c, string=el, s=27749, s>=25964, S=27749, S>=25964
setstate elgris 2024-03-28 15:58:06 scan-h40005 hex=6772, string=gr, s=29287, s>=26482, S=29287, S>=26482
setstate elgris 2024-03-28 15:58:07 scan-h40006 hex=6973, string=is, s=29545, s>=26995, S=29545, S>=26995
setstate elgris 2024-03-28 15:58:08 scan-h40007 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:09 scan-h40008 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:10 scan-h40009 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:11 scan-h40010 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:12 scan-h40011 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:13 scan-h40012 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:14 scan-h40013 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:15 scan-h40014 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:16 scan-h40015 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:17 scan-h40016 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:18 scan-h40017 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:19 scan-h40018 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:20 scan-h40019 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:21 scan-h40020 hex=534d, string=SM, s=19795, s>=21325, S=19795, S>=21325
setstate elgris 2024-03-28 15:58:22 scan-h40021 hex=4152, string=AR, s=21057, s>=16722, S=21057, S>=16722
setstate elgris 2024-03-28 15:58:23 scan-h40022 hex=5420, string=T., s=8276, s>=21536, S=8276, S>=21536
setstate elgris 2024-03-28 15:58:24 scan-h40023 hex=4d45, string=ME, s=17741, s>=19781, S=17741, S>=19781
setstate elgris 2024-03-28 15:58:25 scan-h40024 hex=5445, string=TE, s=17748, s>=21573, S=17748, S>=21573
setstate elgris 2024-03-28 15:58:26 scan-h40025 hex=5200, string=R., s=82, s>=20992, S=82, S>=20992
setstate elgris 2024-03-28 15:58:27 scan-h40026 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:28 scan-h40027 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:29 scan-h40028 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:30 scan-h40029 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:31 scan-h40030 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:32 scan-h40031 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:33 scan-h40032 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:35 scan-h40033 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:36 scan-h40034 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:36 scan-h40035 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:37 scan-h40036 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:39 scan-h40037 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:40 scan-h40038 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:40 scan-h40039 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:41 scan-h40040 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:42 scan-h40041 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:44 scan-h40042 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:45 scan-h40043 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:47 scan-h40044 hex=312e, string=1., s=11825, s>=12590, S=11825, S>=12590
setstate elgris 2024-03-28 15:58:48 scan-h40045 hex=3130, string=10, s=12337, s>=12592, S=12337, S>=12592
setstate elgris 2024-03-28 15:58:48 scan-h40046 hex=2e33, string=.3, s=13102, s>=11827, S=13102, S>=11827
setstate elgris 2024-03-28 15:58:49 scan-h40047 hex=3500, string=5., s=53, s>=13568, S=53, S>=13568
setstate elgris 2024-03-28 15:58:51 scan-h40048 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:51 scan-h40049 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:52 scan-h40050 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:53 scan-h40051 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:58:54 scan-h40052 hex=3139, string=19, s=14641, s>=12601, S=14641, S>=12601
setstate elgris 2024-03-28 15:58:55 scan-h40053 hex=3030, string=00, s=12336, s>=12336, S=12336, S>=12336
setstate elgris 2024-03-28 15:58:56 scan-h40054 hex=3031, string=01, s=12592, s>=12337, S=12592, S>=12337
setstate elgris 2024-03-28 15:58:57 scan-h40055 hex=3033, string=03, s=13104, s>=12339, S=13104, S>=12339
setstate elgris 2024-03-28 15:58:58 scan-h40056 hex=3635, string=65, s=13622, s>=13877, S=13622, S>=13877
setstate elgris 2024-03-28 15:58:59 scan-h40057 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:00 scan-h40058 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:02 scan-h40059 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:03 scan-h40060 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:04 scan-h40061 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:05 scan-h40062 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:06 scan-h40063 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:07 scan-h40064 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:08 scan-h40065 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:09 scan-h40066 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:10 scan-h40067 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:11 scan-h40068 hex=00f0, string=.., s=-4096, s>=240, S=61440, S>=240
setstate elgris 2024-03-28 15:59:12 scan-h40069 hex=00cb, string=.., s=-13568, s>=203, S=51968, S>=203
setstate elgris 2024-03-28 15:59:13 scan-h40070 hex=0069, string=.i, s=26880, s>=105, S=26880, S>=105
setstate elgris 2024-03-28 15:59:14 scan-h40071 hex=048c, string=.., s=-29692, s>=1164, S=35844, S>=1164
setstate elgris 2024-03-28 15:59:15 scan-h40072 hex=007a, string=.z, s=31232, s>=122, S=31232, S>=122
setstate elgris 2024-03-28 15:59:16 scan-h40073 hex=01d9, string=.., s=-9983, s>=473, S=55553, S>=473
setstate elgris 2024-03-28 15:59:17 scan-h40074 hex=023a, string=.:, s=14850, s>=570, S=14850, S>=570
setstate elgris 2024-03-28 15:59:18 scan-h40075 hex=fffd, string=.., s=-513, s>=-3, S=65023, S>=65533
setstate elgris 2024-03-28 15:59:19 scan-h40076 hex=5c03, string=\., s=860, s>=23555, S=860, S>=23555
setstate elgris 2024-03-28 15:59:20 scan-h40077 hex=5bd1, string=[., s=-11941, s>=23505, S=53595, S>=23505
setstate elgris 2024-03-28 15:59:21 scan-h40078 hex=5b8d, string=[., s=-29349, s>=23437, S=36187, S>=23437
setstate elgris 2024-03-28 15:59:22 scan-h40079 hex=5cad, string=\., s=-21156, s>=23725, S=44380, S>=23725
setstate elgris 2024-03-28 15:59:23 scan-h40080 hex=0fe4, string=.., s=-7153, s>=4068, S=58383, S>=4068
setstate elgris 2024-03-28 15:59:24 scan-h40081 hex=9efb, string=.., s=-1122, s>=-24837, S=64414, S>=40699
setstate elgris 2024-03-28 15:59:25 scan-h40082 hex=9e5c, string=.\, s=23710, s>=-24996, S=23710, S>=40540
setstate elgris 2024-03-28 15:59:26 scan-h40083 hex=a07c, string=.|, s=31904, s>=-24452, S=31904, S>=41084
setstate elgris 2024-03-28 15:59:27 scan-h40084 hex=fffe, string=.., s=-257, s>=-2, S=65279, S>=65534
setstate elgris 2024-03-28 15:59:30 scan-h40087 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:34 scan-h40091 hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
setstate elgris 2024-03-28 15:59:35 scan-h40092 hex=0228, string=.(, s=10242, s>=552, S=10242, S>=552
setstate elgris 2024-03-28 15:59:36 scan-h40093 hex=003a, string=.:, s=14848, s>=58, S=14848, S>=58
setstate elgris 2024-03-28 15:59:37 scan-h40094 hex=00c3, string=.., s=-15616, s>=195, S=49920, S>=195
setstate elgris 2024-03-28 15:59:38 scan-h40095 hex=010f, string=.., s=3841, s>=271, S=3841, S>=271
setstate elgris 2024-03-28 15:59:39 scan-h40096 hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
setstate elgris 2024-03-28 15:59:40 scan-h40097 hex=ffd3, string=.., s=-11265, s>=-45, S=54271, S>=65491
setstate elgris 2024-03-28 15:59:41 scan-h40098 hex=fff8, string=.., s=-1793, s>=-8, S=63743, S>=65528
setstate elgris 2024-03-28 15:59:42 scan-h40099 hex=fff1, string=.., s=-3585, s>=-15, S=61951, S>=65521
setstate elgris 2024-03-28 15:59:43 scan-h40100 hex=ffeb, string=.., s=-5121, s>=-21, S=60415, S>=65515
setstate elgris 2024-03-28 15:59:44 scan-h40101 hex=ffff, string=.., s=-1, s>=-1, S=65535, S>=65535
setstate elgris 2024-03-28 15:59:45 scan-h40102 hex=0001, string=.., s=256, s>=1, S=256, S>=1
setstate elgris 2024-03-28 15:59:46 scan-h40103 hex=031c, string=.., s=7171, s>=796, S=7171, S>=796
setstate elgris 2024-03-28 15:59:47 scan-h40104 hex=03e0, string=.., s=-8189, s>=992, S=57347, S>=992
setstate elgris 2024-03-28 15:59:48 scan-h40105 hex=fc23, string=.#, s=9212, s>=-989, S=9212, S>=64547
setstate elgris 2024-03-28 15:59:49 scan-h40106 hex=fffd, string=.., s=-513, s>=-3, S=65023, S>=65533
setstate elgris 2024-03-28 15:59:50 scan-h40107 hex=0002, string=.., s=512, s>=2, S=512, S>=2
setstate elgris 2024-03-28 15:59:51 scan-h40108 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:52 scan-h40109 hex=0091, string=.., s=-28416, s>=145, S=37120, S>=145
setstate elgris 2024-03-28 15:59:53 scan-h40110 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:54 scan-h40111 hex=0126, string=.&, s=9729, s>=294, S=9729, S>=294
setstate elgris 2024-03-28 15:59:55 scan-h40112 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:56 scan-h40113 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:57 scan-h40114 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:59:58 scan-h40115 hex=0034, string=.4, s=13312, s>=52, S=13312, S>=52
setstate elgris 2024-03-28 15:59:59 scan-h40116 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:00 scan-h40117 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:02 scan-h40118 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:03 scan-h40119 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:04 scan-h40120 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:05 scan-h40121 hex=01e9, string=.., s=-5887, s>=489, S=59649, S>=489
setstate elgris 2024-03-28 16:00:06 scan-h40122 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:07 scan-h40123 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:08 scan-h40124 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:09 scan-h40125 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:10 scan-h40126 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:11 scan-h40127 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:12 scan-h40128 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:13 scan-h40129 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:14 scan-h40130 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:15 scan-h40131 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:16 scan-h40132 hex=0214, string=.., s=5122, s>=532, S=5122, S>=532
setstate elgris 2024-03-28 16:00:17 scan-h40133 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:18 scan-h40134 hex=0214, string=.., s=5122, s>=532, S=5122, S>=532
setstate elgris 2024-03-28 16:00:19 scan-h40135 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:20 scan-h40136 hex=00ad, string=.., s=-21248, s>=173, S=44288, S>=173
setstate elgris 2024-03-28 16:00:21 scan-h40137 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:22 scan-h40138 hex=0100, string=.., s=1, s>=256, S=1, S>=256
setstate elgris 2024-03-28 16:00:23 scan-h40139 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:24 scan-h40140 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:25 scan-h40141 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:26 scan-h40142 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:27 scan-h40143 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:28 scan-h40144 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:29 scan-h40145 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:30 scan-h40146 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:31 scan-h40147 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:32 scan-h40148 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:33 scan-h40149 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 16:00:34 scan-h40150 hex=0000, string=.., s=0, s>=0, S=0, S>=0
setstate elgris 2024-03-28 15:56:44 state opened


Gruß
300P
Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: DocCyber am 28 März 2024, 19:13:47
Zitat von: 300P am 28 März 2024, 16:08:21==>Modbus TCP sollte also mit ELGRIS funktionieren!
Ja, das ist richtig, habe ich auch festgestellt.

Aber ich habe Schwierigkeiten bei der korrekten Darstellung negativer Leistungswerte. (obj-h40087)

attr elgris obj-h40087-poll 1
attr elgris obj-h40087-reading power
attr elgris obj-h40087-revRegs 1  # auch schon mit revRegs 0 probiert
attr elgris obj-h40087-unpack n

Titel: Aw: Neue Versionen und Support zum Modbus-Modul
Beitrag von: 300P am 28 März 2024, 21:03:16
Versuche es mal mit:

attr elgris obj-h40087-unpack s

oder

attr elgris obj-h40087-unpack s>

anstatt mit:

attr elgris obj-h40087-unpack n

und dabei ohne bzw. lösche dies:

attr elgris obj-h40087-revRegs



Weitere Infos auch hier:
Hinweise Pearl zu unpack / pack (https://perldoc.perl.org/functions/pack)



PS:
Bei mir wird so ein "-" Wert angezeigt