Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Es wäre super wenn noch ein paar Leute die neue Version des Moduls (siehe Post 1341) testen könnten.
Am besten auch gleich mit der neuen Attribut-Syntax (set upgradeAttributes konvertiert sie).
Wenn es keine Beschwerden gibt würde ich die neue bald Version einchecken.

Gruss und vielen Dank
   Stefan

[Tomk]

Ich nutze die neue Version seit letzter Woche und konnte keine Probleme feststellen, allerdings habe ich die neuen Features nur angetestet. Vielleicht schaffe ich es am Wochenende...

[Kulli]

Moin moin
Ich habe öfters mal Probleme weil mir unter Linux das USB2Modbus Modul verloren geht.
Nach ein paar Sekunden wir das Modul wieder erkannt und eingehängt, aber der LL Treiber zickt danach rum und verbindet sich nicht mehr.
Ich starte im moment Fhem dann einmal neu, dann läuft alles wieder.

Da das LL Modul keine Setbefehle kennt, wie kann ich ohne Fhem neu zu starten diese Schnittstelle "resetten"?

LG
Uwe

[meldelinie]

Hallo,

ich nutze ModbusAttr und Modbus. Ich regele damit meinen netztparallelen PV Akku.

Ich lese den Stromzähler via OBIS aus und sobald ein neuer Messwert kommt (alle 1 bis 10sec - ja nach Stromverbrauch) hole ich die aktuelle Ein/Ausspeisung des Speichers ab.

Dazu habe ich mir einen Event gebaut der den GET Befehl nutzt. Leider führt jeder Aufruf von GET zu einem Logfileeintrag mit Level 3.

Ich habe im Modul, im Eventhandler überall wo es geht verbose auf 2 gesetzt, auch propagateVerbose ist eingeschaltet, damit verbose 2 von ModbusAttr beim IOModul ankommt:

Code Auswählen Erweitern

attr global verbose 3

define ModbusLine Modbus /dev/ttyAMA1@115200
attr ModbusLine verbose 2
attr ModbusLine clientSwitchDelay 0.1
attr ModbusLine showError 1
attr ModbusLine queueDelay 0
attr ModbusLine dropQueueDoubles 1
...

define VenusE ModbusAttr 1 2
attr VenusE propagateVerbose 1
attr VenusE verbose 2
attr VenusE dev-h-defPoll 1
attr VenusE dev-h-defUnpack n
attr VenusE event-on-change-reading nothing
attr VenusE event-on-update-reading nothing
...

attr VenusE obj-h32202-reading ac_power
attr VenusE obj-h32202-type signed long big
attr VenusE obj-h32202-format %.0f W
attr VenusE obj-h32202-polldelay once
attr VenusE obj-h32202-showGet 0
...

## Speicher regeln
define Venus_regeln notify Strom_EG_Obis:power.* { \
fhem "get VenusE ac_power" ;; \
...
...
} }
attr Venus_regeln disabledAfterTrigger 8
attr Venus_regeln verbose 2


Die ... sind Platzhalter für weiteren Code.

ich bekomme trotz verbose 2 alle paar Sekunden den Logileeintrag:

Code Auswählen Erweitern

2025.07.28 14:40:34 3: get VenusE ac_power : -620 W
Der Workaround das GET nicht zu benutzen und per polldelay jede Sekunde ac_power pollen geht nicht weil das den Bus vollstopft.

Einzige Notfallabhilfe bevor das Logfile volläuft

Code Auswählen Erweitern

attr global verbose 2
Aber damit bin ich "blind" untwerwegs und sehe keine Probleme im Logfile mehr.

Ich habe heute morgen frisch fhem upgedated und auch die Module explizit updagedated:

Code Auswählen Erweitern

update
update FHEM/98_ModbusAttr.pm
update FHEM/98_Modbus.pm

Zum debuggen habe ich mir das 98_Modbus.pm angesehen, dort waren die Log Zeilen für "vebose" und "propagateVerbose" teilweise auskommentiert, also habe ich das # von Hand entfernt, fhem neugestartet und Loglevel 4 eingeschaltet und für andere Module Logvelel 2 gelassen:

Laut Logfile wird das auch weitergeleitet:

Code Auswählen Erweitern

2025.07.28 15:49:21 3: VenusE: verbose 4 propagated to ModbusLine
2025.07.28 15:49:21 3: VenusE2: verbose 2 propagated to ModbusLine
...

Als allerletzten Strohalm habe ich versucht die verursachende Log3 Zeile in 98_Modbus.pm zu finden. Aber ich fand nichts passendes. Nach Sub DoRequest bzw.  QueueReuqest geht es in DevIo.pm aber auch dort finde ich keine Log3 Zeile.

[meldelinie]

ich bekomme trotz verbose 2 alle paar Sekunden den Logileeintrag:

Code Auswählen Erweitern

2025.07.28 14:40:34 3: get VenusE ac_power : -620 W

Als ich merkte das der Get Aufruf auf der Kommandozeile keinen Logfile erzeugt -  habe ich von dort weiter in den Quellen nach unten gebohrt ...

*trommelwirbel*

Wenn ich statt

Code Auswählen Erweitern

fhem "get VenusE ac_power"
den Parameter 1 anhänge

Code Auswählen Erweitern

fhem ("get VenusE ac_power",1)
der eigentlich dafür gedacht ist, das der Aufruf keinen Rückgabewert liefert - dann ist das logfile ruhig.

Vielleicht kann ja jemand mit mehr Hintergrundwissen mich trotzdem aufgleisen wieso es mit dem verbose nicht funktioniert ?

[300P]

Wie wärs einfach mal attr global verbose 2 zu nutzen solange alles okay ist?

Code Auswählen Erweitern

verbose
Set the verbosity level. Possible values:
0 - server start/stop
1 - error messages or unknown packets
2 - major events/alarms.
3 - commands sent out will be logged.
4 - you'll see whats received by the different devices.
5 - debugging.
The value for the global device is a default for other devices without own verbose attribute set.

Nur wenn man einen Fehler sucht wird im Normalfall im jeweiligen Device das attr <Device> verbose auf 3/4/5 erhöht.

Ansonsten wird nicht ständig hin und her per Code geschaltet 🤔.

[meldelinie]

...
Wie wärs einfach mal attr global verbose 2 zu nutzen solange alles okay ist?
...

Das hatte ich doch oben schon geschrieben:

Einzige Notfallabhilfe bevor das Logfile volläuft
...
attr global verbose 2
...
Aber damit bin ich "blind" untwerwegs und sehe keine Probleme im Logfile mehr.

Sehr viele Module sind bei Problemen mit verbose 2 still und erst mit verbose 3 sieht man dass es ein Problem gibt.