Tempest Date/Time Management

Greetings,

I noticed today that the timestamps on the data coming out of my Tempest is slow by nearly a minute. This leads me to ask how time is managed and set on the hub/tempest and what I can do to control that? I presume it uses some kind of NTP to get the time, and maintain it, but how is that configured? I ask as I block outbound NTP on the subnet I have my hub on, and the router itself is a NTP server for propagating time. In DHCP responses I send clients the router IP as the NTP server, will the hub recognize and use that option? If not, what servers is it trying to use for time sync?

Thanks!

There is a proposed update to add ability for Hub to use NTP server specified by the DHCP server. Stay tuned for further updates.

4 Likes

Thanks for the info, if there is a feature request, or something, that I can +1, let me know, time keeping is a topic I feel strongly about.

After doing some traffic snooping, I think I see how time keeping is handled now. It looks like once a minute a time message is published to the hub, so I presume the hub syncs to that. I also see my previous minute slowness is down to ~3 seconds, so that’s looking better.

What exactly did you snoop and see ?

Are you looking at the device_status UDP broadcasts that come out every minute ‘from’ the hub perhaps ?

Nope, I used Wireshark to capture the MQTT packets coming out to of the Hub to WF’s servers. They’re not encrypted, so you can read all the messages being passed back and forth.

Hmmm that’s pretty interesting. I thought we looked at one time and it was encrypted, but my recollection might be hazy (or a later firmware update changed things).

I’d be interested in seeing some of that traffic if there’s a way to provide a binary attachment or a pointer to it without too much work. Unfortunately I don’t have any WF gear any more so I can’t do the wireshark thing here any more.

Any idea what happens if you ‘blocked’ the MQTT traffic from leaving your LAN? Would a watchdog timer start things rebooting (like EcoWitt does) ?

I’ll see about recording a packet capture tomorrow. They’re pretty small, so I might be able to attach it to a PM.

As for blocking the MQTT traffic, I’m pretty sure that is would trigger the Red LED on the Hub, but I have no idea if it forces reboots or anything like that.

Thanks. Where I’m going with this one is that ‘if’ the MQTT stuff was a stable interface we could code around, it’s possible to do a little sleight of hand on the network (probably) to grab that traffic and store locally the unmodified data our stations send to WF. That would be a good thing, as many of us have asked for this kind of feature.

Identifying what watchdog things exist here would be good too. There was a lot of investigation and back+forth on wxforum.net about what the Ecowitt gateway does, and eventually the folks reverse engineered how the watchdogs on that gear work, and how to fake the watchdogs out and run locally, which eventually they got confirmed with that vendor’s engineering.

Lots of folks here have expressed a desire to run LAN-only, so if similar magic is doable on WF gear there are definitely going to be some happy people (plus/minus sensor calibrations drifting over time I guess, but that’s a different issue).

Anyway, more info would be appreciated if you have the time to spend on digging a bit (or if others do).

I think you will find it’s the same data as seen in UDP.