You didn’t mention which binding you were using. This is a known issue. When the binding starts up it subscribes to the configured topics. If there is no value on those topics it sets the Item to UNDEF.
When restoreOnStartup runs, it only restores those Items that are NULL. So no matter what, as long as your sensors are not using retained messages, the MQTT2 binding will set the Items to UNDEF until such time that the sensor publishes a new reading.
At first I too was annoyed by this but as I think about it, it really makes a lot of sense. If a sensor reading should persist, then a retained message should be used in the first place. If one is worried about stale data then UNDEF is the correct state for the Item to be in until a new reading is published.
But, it does break the expected behavior of restoreOnStartup. David is aware of the situation but doesn’t really have an idea for a fix yet. I think this is a case where being flexible is our best option.
Unfortunately the order that things get loaded is not terribly well defined and there are some real problems with startup order. But I do something almost exactly as you describe to reset my Expire binding timers and it works 99% of the time. Periodically it will run before things are ready and I’ll get exceptions in the log during startup so I do have to monitor that when I reboot.
It doesn’t occur often enough for me where I’ve tried to see if putting the code in a timer and running it later would fix it. I’m pretty sure it wouldn’t but I’ve never tried.