Verify monsoon_data() raw Parameter Functionality

[reyg3]

I'm not sure the bool values being passed for the optional raw parameter in monsoon_data() are processed correctly. This gets processed by TypeScript but the data returned for passing either True or False does not appear to be different.

The comment for that param reads:
Default is False. If True the data will run through our delta calculation to return totals for all sensors during the monsoon period. When used raw adds datetime to return.

This comment can probably be written better but what I think is supposed to happen is:
True: the delta calculation between each sensor's readings is returned
False: the raw data is returned ex. the total amount of water currently being stored is reported at each report interval

[lboeman]

Hmm, do you think this is a problem with this codebase or the api itself?

The logic of this flag also seems a little backwards to me, and it feels like if you pass raw=True the data shouldn't be processed at all?

[lboeman]

Oh, I think this is the problem (in the monsoon-backend-api code):
https://github.com/UAEnvironmentIT/monsoon-backend-api/blob/11574d919488abb07f4f1cdef38357a21786c710/api.ts#L178

This logic checks sets the raw = !(query.raw == "false" or query.raw == "False") if query.raw is truthy, else query.raw. The problem is that if you don't pass a raw query parameter, the query.raw will be undefined which is falsey. Then it gets interpretted as "false" below where we expect the default to be true. We should just update that logic at the api to be something like:
const raw = query.raw? !(query.raw == "false" or query.raw=="False) : True;

Which defaults to true when the query parameter is undefined, otherwise evaluates it against the False/false strings.

[lboeman]

Since this is in the API logic, I don't think we should adjust the behavior of the raw parameter to avoid breaking things that consume this API.

[reyg3]

Agreed. I figured it was the backend API logic since this API package is only passing the value to be processed.

I was working off of the comment and figured that's how the backend logic handled those bool values. This flag seemed backwards to me too. I'm all for switching it up and can add that line to the API package.

We do still have the issue with the data return for both bool values being passed returning the same data. I still think there is something missing in that backend API logic somewhere preventing that delta calculation. Based on this discussion, when raw = False we should be returning the delta per reading/sensor report and not total like in the True return.

raw = False:
{
"sensor_name": "1030",
"reading_value": 21.69,
"lat": 32.532799,
"lon": -110.756248,
"date": "2020-08-29 10:10:15",
"network": "pima_fcd"
},
{
"sensor_name": "1030",
"reading_value": 21.73,
"lat": 32.532799,
"lon": -110.756248,
"date": "2020-08-29 17:06:21",
"network": "pima_fcd"
},
{
"sensor_name": "1030",
"reading_value": 21.77,
"lat": 32.532799,
"lon": -110.756248,
"date": "2020-08-29 17:08:56",
"network": "pima_fcd"
},

raw = True:
{
"sensor_name": "1030",
"reading_value": 21.69,
"lat": 32.532799,
"lon": -110.756248,
"date": "2020-08-29 10:10:15",
"network": "pima_fcd"
},
{
"sensor_name": "1030",
"reading_value": 21.73,
"lat": 32.532799,
"lon": -110.756248,
"date": "2020-08-29 17:06:21",
"network": "pima_fcd"
},
{
"sensor_name": "1030",
"reading_value": 21.77,
"lat": 32.532799,
"lon": -110.756248,
"date": "2020-08-29 17:08:56",
"network": "pima_fcd"
},