I don’t really understand what you mean.
On the Modbus transaction side, if a poll takes place then the binding must get a value for every included register. There is no concept in Modbus of returning voids or “no change” or anything like that.
So if you think you’re missing data, first thing to look at is when your Things are configured to poll? Can’t comment, can’t see your Things.
Next likely stumbling block might be if the device fails to respond? This will leave errors in your logs about failed polls. The device cannot opt to miss data out; it either responds with all the data or it fails with none. You can see which is happening here, but I can’t.
If we assume the poll works, next step is for the registers to get interpreted by the data Things that you defined. Obviously, there could be mistakes there, but this configuration is static - it’s not going to work sometimes but not other times. Can’t comment, can’t see your Things.
It’s possible to construct a read transform that only messes up with some data patterns. I’m pretty sure that any such thing would show up in your events.log. Don’t know if you’re using transforms, can’t see your Things.
The data Thing has a setting that allows you to reduce the number of openHAB Item updates when the data changes. By default, that updates the Item whenever the state changes, successive polls resulting in the same state only update at most every one second. Don’t know if you’ve changed that setting, can’t see your Things.
Of course it’s not much use getting data to channels if there is no Item to receive it, so finally we must consider the Item links. Again, it is easy to mess these up (say linking one type channel to a different Item type) but it’s a static configuration, not something that works sometimes but not others. Can’t comment, can’t see your Items or links.
Profiles add complication to links, sometimes people select them in PaperUI inadvertently. Once again that’s pretty static work / not work, but also possible here to construct a transform that works sometimes. Can’t comment, can’t see your links.
We should also consider outside influence - it’s possible to get all the Modbus configuring correct but something else comes along and updates the Items unexpectedly.
You’d probably know if you had any rules doing that.
Less obvious is having multilple links to invalid channels or other bindings, so that they’re having a fight over Item updating. You would see evidence of that fight in your events.log. Can’t comment, can’t see your links or logs.
When you’re ready, pick just one of your suspect Items and follow the chain of Item - link - channel - data Thing - poller Bridge and if you cannot see anything wrong for heaven’s sake show us what you got.
as OH3 latest will likely be UI only based so you can either get screendumps or config exports like the one I gave. Yes there’ll be possibilities to still import text but probably not to write things/items back to text format, so once you change them you don’t have the input text representation any more).
Thanks again.