well last received message to mqtt broker was exatly at 4:17 so I assuming thats also a time when networking got stuck. Eventho system works for some time, and then there is complete gap from
Feb 8 04:27:02 garden CRON: (dietpi) CMD (sudo python3 ~/scripts/lux.py &)
till hard restart
which means roughly 10mins before triggered 4:17 whatever it is.
these scripts (lux.py, temp.py) just saves some data for usage later on, and on change of those files data gets published to the network.
there is a python script which is publishing those data, so might be that because of missing networking this script somehow blocks whole system? not sure it's just an mqtt publishing python via paho.mqtt.client
Isn't this Feb 8 04:25:15 garden wpa_supplicant: wlan0: CTRL-EVENT-BEACON-LOSS just wifi got disconnected from AP and wifi manager tries to find new one? or is it something different?
Have some feedback, questions, suggestions, or just fancy a chat? Pop it in here.
Hmm, actually fake-hwclock should as well store the system time on regular shutdown+reboot (instead of hourly only), hence there should be only a minimal time shift on reboot. I'm not sure if the system keeps the system clock on reboots (since power is there, hence possible), but probably logs become more nice when disabling the FORCE option in /etc/default/fake-hwclock. We enable it by default since a long time, which means that fake-hwclock will apply its stored system time as well if it is older than current system time, but that actually rarely makes any sense. This only makes sense if by accident the system time was changed to be far in the future on shutdown... but even then, network time sync will fix it anyway .