Replies: 3 comments
-
I think the Interval caldclation is correct, the issue is just that an constant offset is missing. If you start eg deepsleep 3600 at 8:32am the first trigger time will be 9:00 and by design and documentation it's exacly 9:00, 10:00,... so if drift is lower the trigger will be to early. So if you target by an fixed offset (eg 180sec in an 3600 deepsleep than even if you're device will drift too short, wakeup will still be > 9:00 and < 9:03 |
Beta Was this translation helpful? Give feedback.
-
The 5% calculation was a first guess. I also admit that for a very long time (eg 1 day) the offset is quite huge, so this should be capped. BUT with #20042 the 5% fix was just commented ( ) and for this the issue #13955 is back again.So i will enable this again (at least for me) but I think the best solution would be a constant offset as described above. |
Beta Was this translation helpful? Give feedback.
-
again back to 13.2.0, last before DeepSleep was refactored, perfect for me:
|
Beta Was this translation helpful? Give feedback.
-
Hello all, starting with commit #479b8f40 this was working quite a while for me, and meanwhile also added two additional devices relying on deepsleep, so I have 3 devices actually:
I had to update for new features for a third device and also updated my M3, running on 11.x for nearly 2ys now.
I know that since 5% fix (#13955) there was a ongoing discussion on Deepsleep Timers #20042
First of all 13.4 is working perfect for 5 min.
But for the 3600 device I noticed the same too short run as in #13955 but now the code seems to check the short period and seems to stay longer online to adjust and to make a second measurement in the expected interval. But this means that the wake period is often longer than the necessary 15 second, which means battery live could decrease.
I know the 5% calculation was a fix which was working perfectly for me, but there are drawbacks as mentioned, since this sums up to more than an hour if you sleep for very long period, eg 24 hours, which might nor acceptable, so I think "capping" this to +3minutes will be a good idea.
Some things to correct: the issue reported in my bug is not a HA problem. I have also a parallel TIG stack running, and some Dashboards are also not working well if there are more than one measurement in an interval which is the case with the new algorithm.
I think this will best illustrate this:
As seen there is at least one measurement in an intervall, but not exacly one and you can see by the uptime that the device is simply waiting.
This were the measurements with the old firmware, 1 by hour, but ~ 3 minutes later than full hour:
This here is for the 300 second interval, perfect:
Maybe this is due to the fact that I have ESP-32 and M3, where maybe the ESP-32 timer drift is better? -- I have not checked ESP-32 with 1h but I will do...
Beta Was this translation helpful? Give feedback.
All reactions