How to Implement a Clock in OpenBeken Devices Without Using NTP Protocol

fresh flash. nothing set. will set to powersave 0 to be sure. is powersave on by default on W600?

Added after 5 [minutes]:

no matter. powersave 0

Currently powersave is never on by default, but I am considering enabling it.

@divadiow thanks for your "long term" tests and especially the new input on W600!

divadiow wrote:

I have a W600 now. Sadly, it's not happy very quickly

Seems this platform is using another tick rate like Beken platforms.

Hopefully I finally got it right now (factor "portTICK_RATE_MS" should be present on all platforms, equals to 2 on Beken and W600/W800 and 1 for LN882H and BL602).
Now the code is:

so I think I'm counting ms now on all platforms.

🤩

Added after 8 [hours] 6 [minutes]:



Added after 7 [hours] 45 [minutes]:

@max4elektroda do all platforms need flashing again for a fresh round using latest changes?

It would be great if you could confirm its still working right on Beken (OpenBK7231T/N) and BL602 after my recent change (I did the tests for LN882H here).
I just finished the first try on a configurable daylight saving time in my local code, but it need some cleanup to include it.
After this I think it should be ready to include, but there is still some work to do to separate the generic clock functions from ntp-driver to a general "clock-driver".

And up to now I only managed to build an image to use "#define" for the javascript code with some "handcrafted" code like this in "new_http.c":

This is exactly what I wanted, thank you! This is beginning to look very professional, i hope we can merge it soon. Very good job on supporting other platforms as well.

damn. watchdog kicked the BL602

BL602 died again. the rest seem like a success though? LN jumped ahead slightly? Maybe not enough to care about.

Thank you so much for your tests @divadiow, the clocks are all in the expected range of precision.
That should work for all cases of calculating "daily values" and even work for most of the switching purposes, when it doesn't matter if the clock differs one minute after a month.
Maybe in the future we can even add kind of a correction factor to add/subtract a second every xxx seconds ...
From my side, these tests are successful and don't need to be continued.
What's currently untested is the case of "overflow" of the tick counter, but it will happen only every 50 days...
So thanks again for your support, it helped a lot!

Awesome. No probs 👍

So, after the test is before the (next) test, so if you (or other brave guys) are willing to take another try:

I just finished a universal daylight saving handling, heavily relying on the Tasmota code:

You are no longer bound to the settings during compilation, but can set DST freely.
So if this could be tested on other platforms with some other configuration tests, that would be great.
I attached a file with all the DST settings on Tasmota DST page "rewritten" for my approach.


And I would appreciate if @p.kaczmarek2 could have a look at the PR, too, especially on the change to "new_pins.h":
I added a uint64 to config to be able to save the clock settings (at least, I tried , not sure if padding is needed and if my calculation is right)

In the meantime, I did some tests about xTicks overflow by defining a 16-bit TickType_t locally and could verify (on my LH882H) that this works as intended (with 16-bit the overflow is after 1 minute and some seconds, not every 50 days as with 32-bit counter).

So, if the tests are successful, I can disable some "chatty" information, disable the functions tested and then I would expect it ready for merging...

The new_pins.h config change look okay, but if you want to be sure, just try flashing built binaries to any BK7231 or other device. So far your changes are looking good, keep it up!

well, they all flash and set timer from browser OK as before



I also set PC time to next daylight savings change and saw it go back an hour and switch to GMT from BST. Only watched it on BK7231T though. Do you want all? Is that part of the test required?



Added after 4 [minutes]:

Now that our balcony unit is working again (thanks to p.kaczmarek2), I'm really looking forward to implement a silent NTP update for rickbronson great sunrise/set function.

This is what I have

// Turn off/on Balcony by Sunrise/rise
PowerSave 1
startDriver ntp
ntp_timeZoneOfs -8
ntp_setLatlong 44.002130 -123.091473
removeClockEvent 12
removeClockEvent 13
waitFor NTPState 1
addClockEvent sunrise 0x7f 12 POWER2 OFF
addClockEvent sunset 0x7f 13 POWER2 ON

But in order for the above to work I must allow internet access for the NTP update, hope I can avoid that with your fine clock implementation.
Thank you guys, really great work here!!

That should be possible in the future. ATM the split of general time functions like sunrise/sunset and timed events are somehow "glued" to ntp.
Splitting this will need to add additional source files to every platform (but I can try to give you a "preview" if I know your platform).
There still is one drawback: every loss of power will need setting of the clock.
This can be done easily from another device but needs some "process" like another device checks the clock of the module regularly and then sets it via http, if unset.
Or (it's just a hacked proof of concept which would need some deeper testing) if the beken device can reach an http server (e.g router) sending a "date:" header, you can let the device get its time from a locally reachable webserver.

Added after 11 [minutes]:

And again a big thanks to @divadiow for your tests. I think this proves its working o.k. now.
I will try to prepare the PR for merging, mainly set all #defines to 0 in obk_config.h