Question

I am trying to figure out a way to determine the best way that communication status with a modbus device,
either via TCP or Serial  RS485/232 can be read or inferred.
Currently, it appears there are NO modbus status registers available.
Ideally, _each_ modbus requestor should have an individual status register associated with it which can be queried

Alternatively a status register for each modbus slave device should be available to be queried.
It appears that when using the Test Button in the WebUI, that the status is read and displayed, but not made available for
IoT status
As it is when comms die, the last read data values remain forever.
I was thinking one could come up with some shell-script kludgeware to do some error checking, but I know of no hooks in shell-script land...
I'm thinking those data points could be klobbered to zero periodically in thingsboard, but that's super-ugly and puts a lot of needless noise into the data.

Any ideas ?

I suggest setting aside 2 chunks of modbus registers
1 chunk of 32 registers into which overall status for all defined slave devices would be written
0xffff denotes device not configured
0x0000 denotes status OK
0xttss denotes tt=seconds since non-zero status, ss=last modbus status code

for keener-points 1 more chunk of 128 registers into which status for individual requestors would be written

- same scheme as above

Answer 1

I started poking around more in the ThingsBoard config and found that one can do something like this in an IO postprocess config

if ((time - timePrev) < 100000 ) {

    return value;

} else {

    return -1;

}

So I decided to look at what the update rate was - which normally is undetectable unless the values change

by putting this into the postprocessing:
return (time - timePrev) / 1000;

I can see the update rate - which now raises another can or worms...
I often observed periods in which there appeared to be no updating, the portal data was waaaaay behind the actual live data

Now I'm seeing portal update rates wander between 12s, 45s, 56s

I have the modbus requestor periods set to 29,30,31 (I assume seconds) and the Data to Server Period set to 60 (I assume seconds)

First I was puzzled why the portal data was lagging behind - now all of a sudden - through the power of focused (and coded) observation
the apparent update rate is now faster than the Teltonika periods...
This stuff is just weird. and indeterminate.

I'll post the periods thing as a separate question