OPEnSLab-OSU / Loom-V4

Open Source Internet Of Things Rapid Prototyping Framework For Environmental Sensing Applications
5 stars 1 forks source link

NTP sync inverts local time and UTC time #144

Closed Sarvesh-Thiruppathi closed 2 months ago

Sarvesh-Thiruppathi commented 3 months ago

Describe the bug When using NTP to obtain time on WeatherChime boards, the local time and UTC time are inverted when calling manager.display_data() or previewing the data on MongoDB

Hardware in Use WeatherChime PCB, Hypnos Board, Feather M0, TSL2591, Atlas Scientific EZO DO Probe, Sparkfun LTE Board (This issue persists on other WeatherChimes hardware with different sensors too!)

To Reproduce Steps to reproduce the behavior:

  1. Upload the below code onto a Feather M0 board with Hypnos and Sparkfun LTE board.
  2. Open the Serial monitor and cross-check time_local and time_utc on the serial output with the actual time

Expected behavior A clear and concise description of what you expected to happen.

Code

#include <Loom_Manager.h>
#include <Internet/Connectivity/Loom_LTE/Loom_LTE.h>
#include <Sensors/I2C/Loom_EZODO/Loom_EZODO.h>
#include <Hardware/Loom_Hypnos/Loom_Hypnos.h>

Manager manager("Device", 1);

Loom_Hypnos hypnos(manager, HYPNOS_VERSION::V3_3, TIME_ZONE::PST);
Loom_LTE lte(manager, "hologram", "", "");
Loom_EZODO ezoDO(manager, 0x61, false);

void setup() {

  manager.beginSerial();

  hypnos.enable();

  hypnos.setNetworkInterface(&lte);

  manager.initialize();

  hypnos.networkTimeUpdate();
}

void loop() {
  // Measure and package the data from the sensors
  manager.measure();

  // Package the data into JSON
  manager.package();

  // Print the current JSON document to the Serial monitor
  manager.display_data();  

  // Wait for 2 seconds
  manager.pause(2000);  
  hypnos.networkTimeUpdate();
}

Output

19:36:51.957 ->     "name": "Device",
19:36:51.957 ->     "instance": 1
19:36:51.957 ->   },
19:36:51.957 ->   "contents": [
19:36:51.957 ->     {
19:36:51.957 ->       "module": "Packet",
19:36:51.957 ->       "data": {
19:36:51.957 ->         "Number": 65
19:36:51.957 ->       }
19:36:51.957 ->     },
19:36:51.957 ->     {
19:36:51.957 ->       "module": "LTE",
19:36:51.957 ->       "data": {
19:36:51.957 ->         "RSSI": 19
19:36:51.957 ->       }
19:36:51.957 ->     },
19:36:51.957 ->     {
19:36:51.957 ->       "module": "EZO-DO",
19:36:51.957 ->       "data": {
19:36:51.957 ->         "D-Ox": 1.980000019,
19:36:51.957 ->         "Sat": 21.79999924
19:36:51.957 ->       }
19:36:51.957 ->     }
19:36:51.957 ->   ],
19:36:51.957 ->   "timestamp": {
19:36:51.957 ->     "time_utc": "2024-03-26T19:36:50Z",
19:36:51.957 ->     "time_local": "2024-03-26T11:36:50Z"
19:36:51.957 ->   }
19:36:51.957 -> }

Additional context The correct time when this was being tested was roughly Mar 26, 2024 - 7:36 PM

WL-Richards commented 3 months ago

I believe this was a bug with how timezones were being handled the fixes to hypnos using UTC as our reference time should fix this