Venus OS, inaccurate time

I have a problem with the time display in Venus OS.

The displayed time differs from all other clocks here by about 3 minutes. Rebooting did not help either. But another Raspi Pi shows the correct time

Any idea what the problem could be?

Does anyone have any ideas about this problem?

The gx syncs it’s time with pool.ntp.org (UDP port 123). So, make sure you allow this communication in your firewall / router.

Hi dognose

Thanks for the tip :wink:

So, I’m a little further along…The installation is a little unusual:

VM-3P75CT connected directly to the Ethernet port via LAN cable, VRM/Internet via WLAN

See also

In this configuration, the GX device does not seem to be able to reach an NTP server.

If you pull the network cable to the VM-3P75CT and repower the Raspi Pi , you will have the correct time.

The deviations described above are probably due to the fact that no NTP server could be reached for a long time and the time ran out.

There seems to be a difference between rebooting and disconnecting the Raspi Pi from the power supply.

Please recreate the scenario for a complete error analysis.

Dirk

Hi,

That is a good hint there. You should do some research in the internet, how you could reconfigure the busy boxs ntpd daemon to use the wifi interface for ntp-requests. It eventually tries to use the non-internet-ethernet interface with precedence, when two connections are present.

Got no gx at hand, but chat says:

ps | grep ntpd

Example Output:

1234 root ntpd -n -p pool.ntp.org -I eth0

If -I eth0 is present, it’s bound to that interface. If no -I is specified, it usually listens on all interfaces.

But that would only be true, if the -I switch is used explicit, it may be configured to eth0 through other ways as well. (Ntpd.conf?)

But better read some docs, I think the binding path should only have impact, when running ntpd as server, while as a client, it should just follow regular routing to reach it’s target server. Not sure on that, tho.

Hello dognose,

Thanks for your reply.

I get around the problem as follows (since many command line commands often get lost after the next fw update).

I simply connected a second Canbus interface for the VM-3P75CT grid meter.

Can0 VM-3P75CT
Can1, BMS
WLAN Internet/VRM.

This is not the desired solution, but it works without having to invest any more time.