Can you make auto reboot scheduler?

[lynxchat4]

The Feature

Hello! Can you make auto reboot sheulder? After 1 week working can be stop to send MQTT data and no log data. In web all working normaly. version Release: v13.0.7 (Commit: 304b9e0) After reboot - work normaly.

[caco3]

what means sheulder?

And please provide a logfile

[github-actions[bot]]

Please provide a logfile! Make sure to first enable the DEBUG level in Settings->Configuration->Debug->Logfile Log Level! Then wait until the issue arises again. When you copy the log into here, please make sure to use Fenced code blocks by wrapping it into separate lines with ```, see https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks#fenced-code-blocks

[lynxchat4]

what means sheulder?

And please provide a logfile

Sorry. I meant: " schedule"

Now all work fine. LOG Data Viewer - is normal.

LOG "Log Viewer" files are missing after the problem started. Now put DEBUG

[caco3]

Why do you want to periodically reboot it? Unless there are random crashes as some people experience, it runs stable over days..weeks..!

Eg. my 2 devices are now running since > 7 resp. 8 days.

[lynxchat4]

7-8 days works for me too. But already 2 times it stops sending data and has to be rebooted manually. Everything is recognized and logged, but not sent by MQTT. I would like it to work 24/7 365 days a year, without human intervention.

[caco3]

Then that could to be a bug, please provide the logfiles with DEBUG level so we can try to understand and fix it!

[lynxchat4]

Yes, I changed the settings. As soon as there is an error, I will write here

[nliaudat]

Perhaps the idea is not bad to add an option to reboot after X rounds (a round is defined by auto timer Interval) and stored in memory (sorry, I have no access to the source code actually to give you the variable, that should be in classflow...)

[alfista2600]

mine stopped responding or reporting but still responded to pings. It was over the holidays and I was too busy to notice. Would love to be able to send a reboot command via MQTT... not sure what the issue was...

[caco3]

I had this issue before, ping still working but UI not. But I never had it when I was debugging. And I am not sure if a reboot over MQTT still would work. In your case, did the device still send messages over MQTT when the UI was dead?

[nliaudat]

reboot after X rounds is the best way to go. Can be disabled or set very high (1y)

Every onboard chips needs to be rebooted at intervall.

[caco3]

Every onboard chips needs to be rebooted at intervall.

Duuh, only if you don't do a proper design! The customers of my company would not accept this... :smiley_cat:

[jaegerschnitzel]

I would also opt in for such a periodic reboot option. Once a week cannot be wrong.

[TA257]

Any update on this topic? I set it up two weeks ago and the recognition works very well. But it stops sending data via MQTT after one or two days. A manual reboot fixes that issue every time, but an automation would very nice.

[Slider0007]

A reboot triggered by REST API is already possible: http://IP/reboot

[caco3]

@TA257 Do you have different hardware you could try? Such instability is very unusual! Also try reduce the log level. Or use a different/better SD card. Also the power supply can be a weak point.