[OpenBeken] Setting NTP Server Based on Network Conditions

Hi,

I have some smart plugs flashed with OpenBeken and I was hoping to set up their NTP server. These smart plugs will be used on one of two networks, each with their own NTP server. I was hoping not to have to reconfigure them every time they switch between the networks. I thought of a couple ideas, would any of these work?

1) Set two NTP servers, it will just use whichever one it can contact. Looking at the OpenBK source code it looks like only one IP can be set for this, so not an option.

2) Conditional -- I saw that there's an command, would there be a way to check the current network and use that to determine which NTP address to set? Or to try contacting each NTP server and set the NTP server to the one that is available?

3) DHCP -- will OpenBeken respect the NTP option set in DHCP?

Will any of these work for making my autoexec.bat set NTPServer to the appropriate one? Or some other way?

Thank you, and feel free to send me to the documentation if I missed something.

This seems like a very specific use case. I haven't heard anything like that yet and we already had quite a lot of users.

Current our scripting language operates on numbers, so there is no way to use the conditional, but I may try to extended that in the future.

How much of C do you know? We could try to make some kind of a custom build for you that matches your requirement.

Thanks for the quick response!

I don't know any C, just enough to look through your source code and get an idea for how things worked.

I can just hardcode for now.

One more thing since you mentioned that the scripts work on numbers...are there any numerical operations I can do, since the NTP server will always be .1 on the current subnet? Like extract the first 24 bits of the device's IP address, then append 00000001 to it, and set the NtpServer to that?

Here is a detailed sample showing how to create a driver that can do something like what you want:
https://www.elektroda.com/rtvforum/topic4056286.html
Just create a simple driver and in "oneverysecond" check the string.

p.kaczmarek2 wrote:

This seems like a very specific use case.

Indeed, but it sounds challenging. Did I understand this right: both networks are using the same WiFi SSID but different IP ranges?
So you only know the network you are in after the plugs are connected to WiFi?

@max4elektroda I think doing what he wants is like 5 minutes with custom driver, see the tutorial I linked. To be honest, I made this tutorial mostly because of his question. I think it should be a good enough answer.

I am indeed planning to extend the scripting language in the future, but his use case is so specific that I am not sure if I ever add something like that... script would need to be able to split the IP address string by dots and then parse each substring as a number?

No offence, I was just curious.
First, because I liked the idea of respecting DHCP options - but to be honest, I didn't figure out, if "our" code really uses dhcp or if it's all handled by the closed source wifi libs. E.G. for OpenLN882H there is:

https://github.com/openshwprojects/OpenLN882H...s/net/lwip-2.1.3/src/include/lwip/dhcp.h#L124

And I was thinking about the NTP IP in configuration some time ago, when I played with my idea of the NTP-less clock: Why it's saved as a char but not as four chars/bytes or a 32bit number?
(My idea was "misusing" some of the chars for my code, but that's another story ...)
Depending on the format, "splitting" would be not the problem. If saved as 32bit number, even fiddling around with the network (IP and mask) would be just some simple calculation (network = IP & MASK ... ) .
But of course, it would need quite some changes to the functions using the IP ...

No problem, any suggestions are welcome. I didn't mean to sound like it's otherwise.

max4elektroda wrote:

it's all handled by the closed source wifi libs.

All platforms have their own DHCP implementations, they are outside of the scope of OBK.

max4elektroda wrote:

Why it's saved as a char but not as four chars/bytes or a 32bit number?

We are (or at least we are supposed to) supporting host names as NTP servers as well.

max4elektroda wrote:

saved as 32bit number, even fiddling around with the network (IP and mask) would be just some simple calculation (network = IP & MASK ... ) .
But of course, it would need quite some changes to the functions using the IP ...

You are right, it might be a bit easier than I expected. I will try to look into scripting stuff soon. I was also hoping to maybe support more advanced math expressions and/or conditionals.

@Beken_Call Maybe you can achieve your goal even without changing the device image, if you can control and "script" your network?

E.g. if your DHCP can do some scripts if an OBK plug got its IP, you can just set the NTP server address "from remote"

If NTP isn't started on startup, you first need to start it to be able to set the IP of the server:

and then actually set the server:

Added after 9 [minutes]:

p.kaczmarek2 wrote:

We are (or at least we are supposed to) supporting host names as NTP servers as well.

Hostnames - sure, why didn't I think of that obvious reason?

Thanks! Both the driver idea and remotely setting the NTP server are good options. I might end up going with a third option, just re-addressing the networks so the NTP server has the same IP address on both

Sometimes it takes some time to realize things: My last post, addressing two, people could be combined

So, let me suggest another "trivial" possibility: DNS.
If you can configure the DNS accordingly, it should be possible to return the correct IP of the local NTP-Server to a special name e.g. "ntp.not.for.others"

I am not sure how good the current Beken code works with domain names instead of IPs of NTP servers.

To be honest, I wasn't, too, and first tried it: At least my LN882H works fine when providing a hostname (even after restart!):


Added after 12 [minutes]:

By the way: What would you think about registering NTP related commands even before the start of NTP driver?
If I e.g. want to change NTP server or set offset, I first have to start the driver with "unwanted" values to change them afterwards.
No problem if doing it scripted, but if entering commands "by hand" the more intuitive way (in my opinion) would be first set parameters, than start the service

I'm afraid our standard would not allow that. We're assuming that you need to start driver in order to register the commands, and starting driver in this case starts the service. We could do something like we did for SM16703P, where you have a separate, let's say, "NTP_Start" command within a driver, but we can't really do that without breaking compatibility with older scripts...