-
|
I think I understand how the DeepSleepTime works now, but it was quite difficult to decipher as the document suggests there is a max sleep time of 86400 and that value wakes at 00:00, somewhat implying that you can only sleep until midnight as a maximum. But this documentation is incorrect as you can specify up to 10 years of sleep time. Also, depending on what you specify and when you perform the sleep - specifying a smaller sleep time can actually result in waking later. It also hints that there's no way to 'shift' the wake up time and the difficulties of targeting a particular time - but really that is referring to the next wake up time in a recurring set. If you don't care about the recurring period you can certainly target a given first wake up time if you happen on just the right value. You can always ignore the recurring period and recalculate the next wake up time yourself. This is combined with the fact the documentation doesn't mention the 5% fudge factor, which I believe is a bit buggy/excessive as 86400 actually wakes at 01:12 the next day. I think this is quite excessive buffer amount. I've listed below some relatively random sleep times and the local time that they were performed. Something like this might be useful in the doco.
It would be great if Tasmota had a "DeepSleepFor" or "DeepSleepUntil" command that slept for x seconds or slept until a given local time. But anyway, I will work with this current command which is really more like a "DeepSleepSchedule". My question is whether anyone has a formula for calculating this "first wake time" given a current time and deep sleep time? Or even better, calculate the largest deep sleep time given a current time and target wake time? I would like to specify a target wake time for just a once off wake - I can then recalculate the next deep sleep amount as required for the next wake (e.g in berry). I understand it is periods of deep sleep time from the epoch up until it exceeds the current time, then 1 more deep sleep time unit after that. But I cannot think of a way to calculate this. I believe calculating the ideal deep sleep time might be finding the largest factor of 'floor(timestamp(target_time) + x mins)'. The reason I want to use the largest value is to avoid any interim wakes between now and the target time. I can round the target time up/down 10 minutes or so if that makes finding a suitable factor easier. Any other ideas? |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 17 replies
-
|
I thought that taking the target timestamp and dividing by 8.4 (getting a factor within the valid range, then reducing by the 5%) would give you an appropriate "deep sleep time". But that doesn't seem to work. I believe the formula is more or less: waketime = ((curtime / dsleep) + 1) * dsleep) + (dsleep * 0.05) based on : https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_29_deepsleep.ino#L117 but I am not maths enough to figure it out :( dsleep = (waketime - curtime) / 1.05 but it's not quite right for me. |
Beta Was this translation helpful? Give feedback.
-
|
The formula is correct because there is a temperature correction that takes into account what the actual sleep time was with the corresponding factor and calculate a new one. Your suggestion of the formula does not work as far as I can see. There where requests to shift the time or make something on top for timezones because the sleeptime is always compared to the UNIX time in seconds since epoch. This makes is impossible to wake up daily at 3am. The wakeup time with SHIFT over time because with every run it get a bit better in prediction how long it has to sleep. Because this is temperature dependent there are limits. The is a graph in the docu that shows the compensation benefits over time. It need some cycles to get the correct one. The table you provided seems wrong to me. The 1.05 has a total different meaning. It is just to see if it was a full cycle or a manual wakeup or just a fraction of the cycle to calculate the correct compensation factor. 3600 will always try to wakeup exactly at 1:00am, 2:00am and so on. |
Beta Was this translation helpful? Give feedback.
-
|
The table is based on actually running "DeepSleepTime x" at the given current time and taking note of the "WakeupTime" as reported via the MQTT message. I may have made the odd copy-paste mistake, but for the most part it should reflect the actuals, at least as far as the self-reporting is concerned. My link to the code was wrong, it should have been: https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_29_deepsleep.ino#L127 and indeed if you look at the wake times they are all increased by 5%, as per the code. (86400 x 5% = 1h 12min) I am not too concerned about "every run" or the slipping or waking up at 3am daily. I am only concerned about the "first wake". After that point I will cancel the deep sleep and calculate the next wake. Essentially I am abusing the 'deep sleep schedule period' functionality to perform a 'deep sleep wake once at x'. From what I can see in the code after calling "DeepSleepTime x" the nextwakeup is 0, which causes it to go into this code: https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_29_deepsleep.ino#L127 At which point the formula seems to be : waketime = (((floor((1700188097+ 5) / 16200)) + 1) * 16200) + (16200* 0.05) But I am obviously missing something as this doesn't seem to calculate out correctly. Possibly a time zone issue. |
Beta Was this translation helpful? Give feedback.
-
|
deepsleep 16200 is a bad choice because this in epoch seconds is every day a different time. Anyhow the time between the wakeups is more or less exactly 16200 seconds. You get the current epoch time here: https://www.epochconverter.com/ e.g. now: 1700206164 --> 1700206164/16200 = 104.950 full cycle -> wakeup at 104.951 * 16200 timestamp Your time zone: Freitag, 17. November 2023 08:28:38 [GMT+01:00] -> wakeup : Freitag, 17. November 2023 08:30:00 [GMT+01:00] |
Beta Was this translation helpful? Give feedback.
-
|
16200 is a bad choice for waking 2 or more times, but as far as waking once all I care about is the first wake time. After that I will cancel the sleep schedule and issue a new deep sleep command with a new value. I think your calculation is more or less what I was performing (except I was also taking into account the 5% bump)- but I was not getting the same values as "DeepSleepTime x" was reporting. |
Beta Was this translation helpful? Give feedback.
-
|
EDIT: ChatGPT is a terrible math tool. Using a excel I get the correct value = (( ( floor ((1700224097+ 5) / 16200)) + 1) * 16200) + (16200* 0.05) |
Beta Was this translation helpful? Give feedback.
-
|
I don't have an issue with the slip, I assume this is required between cycles. It is the very first wake that is getting offset by 5% that is potentially an issue. If you perform a "DeepSleepTime 86400" intending to wake up at midnight each night (as per doco) - it will actually wake up at 01:12 each night instead, an hour and 12 minutes late. Or at least, that is what the first nextwakup calculation and logging suggests will happen. Maybe this reported wakeup time is actually incorrect and the real wakeup time gets corrected during the mandatory "mini"-wakes? There are two expression blocks in the code - one for the slip, another for the 'first wake'. The 5% bump was added to offset wakes to ensure they are always ahead, to fix some home assistant integration issue. IMHO it probably should have been either capped to ~3 minutes or fixed on the home assistant end.
Is this in reference to the current implementation, or a limitation of the ESP hardware? Couldn't an end user use that berry code I posted below to perform a sleep for current_time+3600 to effectively achieve this? I am ignoring the interval/cycles - you'd need to have an init rule to calculate a new deepsleep time each wake. (I am doing this for #19977 and it appears to work ok). In other words - if we were to expose esp_sleep_enable_timer_wakeup to berry could we conceivably sleep until any time and not have this 'floor based' interval scheduling? I think that would be very useful if so. |
Beta Was this translation helpful? Give feedback.
-
|
For reference, my use case is I want to "full wake" twice a day and only twice a day to save power. Ideally at 5:00am and 4:30pm (or possibly sunrise and sunset). I believe the best way to achieve this is with a bit of berry code that calculates the sleep time for the next "DeepSleepTime" command on each wake. I believe the "sleep_until" bit of code I posted below could be used to achieve the "sleep until specific time" side of things. I have implemented this under #19977 and it seems to work ok, only waking at the appropriate target time from an arbitrary starting time. |
Beta Was this translation helpful? Give feedback.
-
|
We checked a few month ago to get this into the timer config. So you have on/off/toggle/rule/deepsleep as an event. This would 100% match your requirements. In this case you can also make use of the sunset. But.... |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that would be ideal, and I imagine quite useful for many other applications. Although I guess it's more of a 'wake' setting than a sleep setting. You could put the device to sleep with 'Restart 9' or whatever, and that timer would ideally dictate when it gets configured to wake again. Not sure if the 2bit limit you are referring to is this: https://github.com/arendst/Tasmota/blob/development/tasmota/include/tasmota_types.h#L333 |
Beta Was this translation helpful? Give feedback.
-
|
Yes line 333 is the issue kid. If we can store the wake-up time here it is easy to calculate on demand the deepsleep time based on current time and the timers. The timers in this case are just used as an UI and a bucket to save the information. Calculation will be externalized in the deepsleep driver with a Formular similar to yours. |
Beta Was this translation helpful? Give feedback.
-
|
Here is a spreadsheet that takes a given 'current time' and shows the 'first wake time' values for various values of 'deep sleep time'. Ideally I need a way to do the reverse - calculate the deep sleep time given a desired wake time. As you can see, unless I am mistaken, things get pretty weird and unpredictable with values above 20,000 or so. |
Beta Was this translation helpful? Give feedback.
-
|
This is a bit of berry code that will sleep until a specific time: import math
import string
def sleep_until(target)
var curtime = tasmota.rtc()["local"]
var ds = 60
for i: 1 .. 10000
var wake = (((curtime / ds) + 1) * ds ) + (ds * 0.05)
if (math.abs(wake - target) < 600)
# print('sleep time: ', ds, i)
tasmota.cmd(string.format("DeepSleepTime %d", ds))
return i
end
if (i % 1000 == 0)
tasmota.yield()
end
ds += 60
end
print('not found..')
end
# Sleep until 12 hours after the current time
sleep_until(tasmota.rtc()["local"] + (3600 * 12))It's not that efficient, and would need some tuning of the search iteration depending on how long you needed to sleep for. But it works ok for < 24hr sleeps. The sleep time chosen is unlikely to be suitable for the "next" period. You will need to have a rule that immediately disables DeepSleepTime on init, or immediately sets it to the new desired value. If Tasmota ever changes the sleep time algo it will likely break. Would be nice to have native support for this functionality in Tasmota, but alas this is ok for now. |
Beta Was this translation helpful? Give feedback.
-
|
Long loops of 10000 is strongly not recommended in Berry, as code should always return quickly for Tasmota to be responsive, ideally under 50 ms. Using You cannot make a good |
Beta Was this translation helpful? Give feedback.
-
|
Yeah fair enough - although it typically only loops 1000 times or so before it finds a suitable value and early exits. It's just doing a quick maths operation and returning, so hopefully under 50ms. (I timed this and it's generally only 15ms or so to find a value). If there was a way to inverse that equation the loop wouldn't be required at all. But I haven't figured out a way to do that (I'm not sure it's possible). It also end with a deepsleep, so may not be that critical if it blocks tasmota in it's final ms before shutting down.
While it's named 'sleep until', keep in mind it isn't really "sleeping", it's just calculating a value to pass to deepsleeptime. You could rework it to use the 'fast_driver' functionality with a counter kept in state if it exceeds 50ms. |
Beta Was this translation helpful? Give feedback.
-
|
Christmas is comming!! @smhc Added a new pull request to use TIMERS for wakeup from deepsleep. The new add on calculates the next wakeup based on the TIMERS. You can use nearly all TIMERS functionality beside the RANDOM change. Pull request: #20117 How does it work (must be rule1 ther rules 2,3 do not work): Define TIMERS with action RULE New functionality: On power restart and reset Deepsleepcountdown is 60seconds. after deepsleep wakeup 4 seconds |
Beta Was this translation helpful? Give feedback.
-
|
I also removed the 5% add on on the initial run and just take care that there are more than 15 seconds before the next wakeup. |
Beta Was this translation helpful? Give feedback.
-
|
Documentation updated: https://github.com/tasmota/docs/blob/master/docs/DeepSleep.md |
Beta Was this translation helpful? Give feedback.
-
|
#20165 submitted to add "restart 9" as an option to send the device to deepsleep. Documentation will follow. |
Beta Was this translation helpful? Give feedback.
-
|
Documentation updated: https://tasmota.github.io/docs/DeepSleep/#deepsleep-wakeup-based-on-timer-events |
Beta Was this translation helpful? Give feedback.
This is a bit of berry code that will sleep until a specific time:
It's not that efficient, and would need…