Please explain in more detail what this option is for. Thanks.
It reconnect to a WiFi if connection is lost
Yes it is, but why isn’t this option turned on by default. I want more details. I have controllers built on RPI Zero 2W that work normally within a year. This particular one I installed six months ago (on a new network etc.) Within those six months twice I can’t access the device (in this case) It has to be manually rebooted. The site’s power supply goes out several times a week. Why is the connection restored in most cases without this option turned on? When and why should it be included? Greetings.
More details. All controllers are mounted on emmc UUGear cards 16 Gb.
If set to on the service dietpi-wifi-monitor get’s enabled and here you can find what this service does.
It tries to ping the default gateway you set, if there is no repsonse the wifi connection might be lost and it tries to reconnect. This option would make sense if you use it as a mobile device, which is not your use case.
On reboot it connects to the wifi automatically. The reconnect option is only working when you loose connection after this.
I didn’t quite understand what you were trying to explain to me. You mean the device moves around the site and if it loses connection then recovers?
Typically a stationary device does not loose connection when the AP is also stationary, so I imagine the reconnect feature is more suited to a case, where you use the RPi as a mobile device.
On the other hand this feature needs a systemd service to function, so this is could be a reason why it’s not enabled by default.
Theoretically, we imagine that the RPI Zero 2 W charges faster than the network recovery time. What is happening? No network - no connection? What do you recommend. This option is on or off. We can practically consider this device as mobile! Thanks.
I have no idea what is happening in this case, but if you want that your network reconnects automatically, activate “auto reconnect”. 
1 Like
simply activate the option and see if it helps.
Basically, the option is taking effect during normal operation to reconnect if network connection is lost. It doesn’t have anything to do with connecting to a network during reboot or after power loss.
1 Like
Hi, Today the device is offline again with reconnect option enabled. It turns out that the home internet system is built from Unifi brand devices. Turns out they did an update overnight then rebooted but my device didn’t reconnect to the network. Any ideas?
Does your wifi use a visible SSID? With a hidden SSID it will not work.
And can you check:
systemctl status dietpi-wifi-monitor.service
Yes, the network is visible. when I’m there and the phone connects and the laptop. Will reboot my device in a few hours and see what the response is.
it’s too late now, but best would be to enable permanent logs and to check what happen during night.
How to turn on these logs. Do they take up a lot of disk space, and are they written to a lot? One of the main reasons I switched to Dietpi is that it has a ramlog and doesn’t write to disk.
enable persistent system logs:
dietpi-software uninstall 103 # uninstalls DIetPi-RAMlog
mkdir /var/log/journal # triggers systemd-journald logs to disk
reboot # required to finalise the RAMlog uninstallThen you can check system logs via:
journalctlwhich will then show as well logs from previous boot sessions. To limit the size, you can additionally e.g. apply the following:
mkdir -p /etc/systemd/journald.conf.d
cat << '_EOF_' > /etc/systemd/journald.conf.d/99-custom.conf
[Journal]
SystemMaxFiles=2
MaxFileSec=7day
_EOF_This will limit logs to 14 days split across two journal files, so that with rotation you will always have between 7 and 14 days of logs available.
should not be that much but depends on the amount of system logs generated.
Understood, but how to troubleshoot system behavior if logs are gone after reboot?
1 Like
Did I miss that the DietPi system did a reboot (as well) or what for persistent system logs on DietPi?
If the AP gets rebootet and the DietPi system is not reconnected despite the setting enabled:
journalctl -u dietpi-wifi-monitor
systemctl status prints only a small number of log lines, often not sufficient to see the whole picture.
Not 100% sure when and why, but at least if the AP is the same and only the connection is a bit flaky or it reboots quickly, the WiFi interface does not need to be restarted for the connection to resume. So the auto-reconnect is meant for cases where this does not work, with the downside of an additional process with some constant CPU utilisation. In fact, there are also cases where the auto-reconnect leads to regular longer disconnects (it restarts the whole interface, including new DHCP lease in case) while without it, the connection would have been there again in a fraction of a second. Hence it is not enabled by default.
As I understood, OP is going to reboot to gain back access. Therefore I was thinking about permanent logs to have something in further if similar happen again.
Ah okay. Probably we can find out why it does not auto-reconnect in the same session. In case, also doing this manually should be equal to a reboot:
ifdown wlan0
ifup wlan0
And there one also sees all output on the console, in case something fails for some reason.