Modbus stops and polling times

[rossko57]

@DDS90

In fact, the PC with SSD is much faster than the RPi with only SD

From a quick look at openhab.log sample, you’ve got DEBUG set for everything so I think this going to impact performance just by amount of log generated.

@DDS90

when I press a button connected to a slave, the corresponding bit is set, then the master resets the bit via rule

Well, I don’t suppose you are pressing buttons very often, so it’s not going to amount to a great deal of additional traffic compared to your polling.

@DDS90

I hope they can be useful.

From ERRORE.txt -

2021-01-14 22:58:08.377 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Sent: 03 01 00 10 01 00 3d bd 
2021-01-14 22:58:08.379 [TRACE] [t.wimpi.modbus.io.ModbusRTUTransport] - Managed to read at least one byte
2021-01-14 22:58:08.396 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Response: 03 01 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c8 20

A normal transfer seems to take place promptly.
2mS after logging read poll sent, we begin to get data back.
Within 20mS we have the whole packet available, seems about right 10mS for wire transfer plus some system overhead.
Looks good in turnaround time.

2021-01-14 22:58:08.417 [DEBUG] [bus.handler.ModbusPollerThingHandler] - Thing modbus:poller:Scheda_IN_03:S3_Digital_IN received response PollResult(result=AsyncModbusReadResult(request = ModbusReadRequestBlueprint@3a934cac[slaveId=3,functionCode=READ_COILS,start=16,length=256,maxTries=3], bits = BitArray(bits=0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)))

Another 20mS to process bytes to 256 coil bits and pass up the chain, ready to update channels.

2021-01-14 22:58:08.493 [TRACE] [ernal.handler.ModbusDataThingHandler] - Channel switch will be updated to 'OFF' (type OnOffType). Input data: number value 0 (value type 'bit' taken into account) and bool value false. Transformation: <identity>

A further 85mS to update all those channels.
This is going to hammer your openHAB bus with Item updates,more on that in a minute.

2021-01-14 22:58:08.509 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Sent: 04 01 00 10 01 00 3c 0a

After about 130mS altogether, we’re ready to send off the next request to the serial modbus.
This timing seems to match up with the gaps you see in your polling traffic trace.
The bottleneck seems to be the volume of data to be processed.

Okay, so returning to Item updates - we realized a while ago that that generating Item updates on the openHAB event bus is costly in processing. Also can have knock-on effects by triggering rules, persistence records, etc.
It’s really easy with a non-trivial Modbus configuration like yours to generate thousands of Item updates per second - and all to an unchanged value.

@ssalonen provided the Modbus binding with a way to circumvent that, essentially update only changes.
Once again I’ll refer you to this thread -

Modbus performance management in openHAB 2

Event bus overheads Large numbers of Item updates on openHAB event bus will obviously cause system workload to increase - while it carries out the actual update, looks to see if any rules should be triggered, performs logging, etc. There is little that we, as users, can do to make this part more efficient. Logging I do not suggest reducing logging levels just to try and lighten the load. In any case, openHAB2 does not log “same state” Item updates with ordinary settings, only changes. You’ve…

and suggest looking hard at updateUnchangedValuesEveryMillis= parameter.

I don’t think this will make much difference to how much processing the binding actually has to do. But - I suspect it will greatly reduce the overheads on the rest of your system and so make available resources for faster polling.