Neue Versionen und Support zum Modbus-Modul

[claudio]

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

[StefanStrobel]

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

[claudio]

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.

[StefanStrobel]

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

[Tomk]

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

Code: [Auswählen]

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:*"?

[StefanStrobel]

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

[Tomk]

Vielen Dank für deine Antwort!
Richtig, ModbusAttr ist als Slave konfiguriert und ich stelle verschiedene Daten bereit. Vielleicht einfach ein default attr?

[StefanStrobel]

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

[Tomk]

Super, vielen Dank vorab... Werde ich testen :-)

[StefanStrobel]

Hallo,

hier eine neue Version zum Testen mit den angekündigten ..-mapDefault und ..-rmapDefault Attributen.

Gruss
   Stefan

[Tomk]

Vielen Dank Stefan! Das ging ja schnell... Ich habe es gleich mal übernommen und starte den Test...

[StefanStrobel]

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.

[Tomk]

Ist mir nicht nicht aufgefallen... bis jetzt sieht's auch ohne die Utils gut aus. Wann sollte sich das fehlende Update auswirken!

[StefanStrobel]

Ohne die Utils ist nur die Fehlermeldung weg.
Ein expliziter Default-Wert ist aber erst in der neuen Version der Utils implementiert.

Gruss
   Stefan

[Tomk]

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