Lots of mistaken information being posted here
For a class A node, the timing-critical part of LMiC is between transmit and receive. Delaying transmit by waiting for something is really not an issue.
Scheduling a another job could be a cleaner solution, but LMiC’s scheduler is cooperative and does not account for the time which jobs will take, thus anything that could result in the sensor job getting run in between transmit and receive would often break things, and there isn’t a real easy way to avoid that with the existing code. Doing your sensor readings on th way to transmitting may be simplest…
In terms of updating millis(), this is primarily an issue if you sleep between transmit and receive - so it’s simplest if you just stay awake for that second.
The second reason for wanting millis() to keep advancing is that if you are in a region where LMiC needs to do duty cycle limiting, not having millis() advance during the sleep will cause it to think time is passing very slowly, and absurdly limit itself compared to the actual advance a time.
Simple solution to avoid advancing of
millis() could be to restart the device every time it wakes up from sleep.
This is a truly terrible idea. It fixes the problem with rate limiting only by throwing away the rate limiting history.
Worse, cold-restarting LMiC has to be avoided - a compliant LoRaWAN node must track and not repeat its frame count within a session, so you’d have to have a place to save that and restore it.
Some will try to use OTAA to create a new session instead, but this simply moves the problem and creates a new one. Each join request must use a fresh not-previously-used join nonce, so you then have to keep track of those. And you can only join so many times before the device EUI itself is worn out. Plus joining is very expensive for the network as it costs a bare minimum of one downlink, often more. So don’t do a cold restart and rejoin after each sleep, either.