should not use the partial daily data from wattdepot if the data not completed

[yongwen]

currently Makahiki retrieves the wattdepot data in a set interval and stores it in a daily basis. But in the event of wattdepot data service failure, such as the meter unreachable in the middle of the day, the daily data stored in Makahiki for that meter is not completed and does not reflect the correct daily energy usage for the team. In this case, Makahiki should not use the in-completed daily data for calculating the energy goal or energy scoreboard.

How to adequately determine the validity of the wattdepot data could be complicated.

If the meter reboot during the day, the meter may lost some data points and the total usage for the day may not be correct because of those lost data points. We could define an acceptable data missing period, say 30 minutes, if the data missing period is longer than 30 minutes, we consider the data for the day is invalid.

In the event of meter functioning correctly but wattdepot had delayed the storing for any reason, the wattdepot data timestamp might have a gap of beyond the acceptable data missing period.
In this case, the final daily wattdepot data might be correct.

Currently Makahiki use the REST url "sources/%s/energy/?startTime=&endTime=" to get data from Wattdepot. If REST API has some kind of status indicating the data returned has a data missing period of X if any, so that, Makahiki can determine if the data is suitable for its purpose.

In the case of wattdepot storing delay, as long as the last retrieval of the day from wattdepot has valid data (no missing period), makahiki will consider the data of the day is valid and could be used for goal calculation.

[rbrewer]

Yes, this seems like it really should be taken care of on the WattDepot side somehow. However, as you point out, this is actually hard to do in the real world, since a meter could be dead (i.e. not collecting data) or just unreachable (energy counter data is good once it can be retrieved). A WattDepot sensor could track when a Source becomes unresponsive, and then once it becomes reachable again it could compare the counters with the last stored data point. If the counters are "close" then probably the meter was dead, if they are not "close" then the meter was probably OK, just unreachable. But the desired parameters for these checks might be different for different client applications.