The sensors do not have a valid "time and date" so the server is replacing the invalid time/date with the time/date that the reading is entered into the database on the server. When data is stored in a offline gateway and uploaded "in bulk" when the gateway is online that results in many readings having time/date that are very close in time to each other as the readings get uploaded quickly. That makes it appear as if data is missing which its not. For example, assuming the sensor has a bad date/time and if the sensor is set to read once per hour and sent 24 readings to the gateway in a day and the gateway uploaded those 24 readings "in bulk" at 13:01 then all of those reading would have a "read date" of 13:01 and on a graph would all be graphed on top of each other since they had almost the same date and time. So it looks like 1 data point but there really are 24 data points.
Some causes of this are:
1. The S-16 sensors are running older than rev 2.12 firmware that could be causing the "bad date" problem.
2. The gateway has a bad battery. The battery keeps the time/date clock running when power is off. If the sensors talk to a gateway with a bad date then the sensors will sync to that gateways date/time and all readings from that sensor will have a bad date.
3. The sensor battery was removed and reinserted, and the sensor has not talked to a gateway since then. Sensors MUST talk to a gateway in order to set their internal clocks.
Some causes of this are:
1. The S-16 sensors are running older than rev 2.12 firmware that could be causing the "bad date" problem.
2. The gateway has a bad battery. The battery keeps the time/date clock running when power is off. If the sensors talk to a gateway with a bad date then the sensors will sync to that gateways date/time and all readings from that sensor will have a bad date.
3. The sensor battery was removed and reinserted, and the sensor has not talked to a gateway since then. Sensors MUST talk to a gateway in order to set their internal clocks.
0