-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: Setoption to disable boot count for deep sleeping devices #6930
Comments
Did you try the latest deepsleep code? It postpones teleperiod unitl wifi is connected. Then enables the user configured teleperiod, which is at least 10 seconds. Then once MQTT is connected it set teleperiod to 5 seconds and reports teleperiod data after which it goes to sleep. As bootcount is saved 10 seconds after restart it should be saved always UNLESS your wifi AND MQTT connection are settled within 4 seconds. Are they? Mine take at least 8 seconds although I always do wifi scan on restart which can take some seconds too. Considering this it may indeed be faster than 4 to 5 seconds skipping bootcount write. (I tend to come to conclusions while I write. Not sure if that's a good thing though...) Any way. I'll add a setoption for this. Default no bootcount. Bootcount only on setoption is 1. |
Add command SetOption76 0/1 to enable incrementing bootcount when deepsleep is enabled (#6930)
Here is what I get on teleperiod 10
And this is what I get on teleperiod 15
I don't think the sleep code was changed after my pull:
|
And yes, the 42.13 in the ip address is intentional :) |
That's strange. It seems indeed 10 seconds of uptime will send your teleperiod message. That shouldn't happen with my latest changes where teleperiod is set to 9999 after restart and once wifi is connected it is set to 10 in your case. It then should be initiated at 15 seconds uptime as expected. Investigating |
That was before your last commit so let me try to reproduce it now with the SO76 |
Bugger. I guess the change slipped true while making other changes. Pls try the one from today which does contain the correct changes. |
I think the issue was on my side... perhaps flashed a stale bin which was solved by removing all the platform and package folders to force migration to 2.6.1 In my pastes above it always ended with |
De-bugger. The fix was in indeed. Rest my mind. So now it should work as expected independant of minimal teleperiod as it will always take more than 10 seconds before the initial teleperiod kicks in. |
So now with SO76 enabled and teleperiod 15 it still writes to flash
But with SO76 disabled it works as expected not writing to flash
|
Same with teleperiod 10 - Only SO76 enabled results in flash write for boot count :) I think that solves this one since it is disabled by default. Thanks! |
Correct. |
Would like a setoption to disable the boot count for special cases like deepsleep.
When teleperiod is 10 it does not appear to save the boot count to flash.
My observation is that when teleperiod > 14 the device will output the following on the seriallog
Although this is useful for diagnostic purposes it would be nice to conditionally disable this specific write if deepsleep is enabled by either a setoption or compiler directive.
This is to avoid an unwanted number of flash cycles when deep sleep is being used.
Have you looked for this feature in other issues and in the wiki?
Is your feature request related to a problem? Please describe.
Unwanted flash cycles.
Describe the solution you'd like
Be able to set this using a setoption.
Describe alternatives you've considered
Using teleperiod of < 11 but then the device does not always get NTP time.
The text was updated successfully, but these errors were encountered: