Please explain a little bit more about the use case for this.
In the mean time, see Thing Status Reporting [4.0.0.0;4.9.9.9]. That would require minimal rules coding to handle most use cases.
There is already a REFRESH command supported by some bindings for this purpose (I know Zwve and Zigbee to, I suspect KNX does). Unfortunately I don’t think it’s well documented. When you send this command to an Item, the binding will attempt to go read the current state of the device and update the Item. Not all technologies can support this and not all binding authors have implemented this.
Given the nature of MQTT, REFRESH isn’t supported and I’m not sure how it could ever be supported and what the point would be. MQTT messages are either retained or not. MQTT is a push technology, not a pull technology. It’s the end device that decides when and how to publish any message. Clients can’t force them to publish.
Given that, there’s nothing to refresh.
As long as the connection to the broker is up, your Item will always reflect the latest message received.
If messages are sent while OH is not connected that are not retained, those messages are gone and not recoverable.
If messages are sent while OH is not connected that are retained, the latest retained message will be delivered to OH as soon as it connects.