Plotting calculated values

Select “All” as the manufacturer and “Calculated” as the sensor model.

Right now there’s no ability to do units conversions in either ModularSensors or on Monitor My Watershed. Your only option in ModularSensors would be to create a calculated variable that did the units conversion.

On Monitor My Watershed, I think almost all of the temperature variables have the option of being in either C or F, but nearly everything else will only give you the option right now of the “default” unit any given sensor spits out. Those lists are curated, but it’s not difficult for us to add any new output variables/units you need. Let me know what you’d like to have added and I can do it. If the only “calculation” you’re doing is a unit conversion, then the output should still be tied to a specific sensor make/model. Once I add the extra unit, you’d be able to select that unit from the drop down in the same way you see the Celsius/Fahrenheit option now.

The “all/calculated” was really put in place for values that are calculated using the outputs of more than one sensor – like that barometric correction that uses atmospheric pressure from one sensor, water pressure from another, and temperature from a third. It feels really “hacky” because the Monitor My Watershed portal is primarily intended for “level 0” (totally raw) data that hasn’t had any calculations or QC applied. But, if you want to have a new calculated option, just let me know what you need to have added and, within reason, I can put it in. Just be aware that inside the database, no matter how polished that calculation is, the data on MonitorMW is still tagged as “raw”.

I’m sorryfor the confusion. The unit selected on MonitorMW should be the unit you are sending data in. The MonitorMW data portal never does any calcu lation of any type on the posted data, including unit conversions. If you select different units from those units sent in your post request, the website will simply be wrong. If you modify an existing variable on MonitorMW to select different units, the label will change but the values will not. By “calculated variable” MonitorMW means “someone else calculated this and posted the results” not “this was calculated by MonitorMW.”

You *can* create a calculated variable in ModularSensors where you give the equation that will convert C to F or mm to inches and then report that calculated value to MonitorMW. In that case, when you’re creating the variable on MonitorMW you would select your sensor make/model in the same way you normally would, but then select the alternate units (ie, F or inches, which I will add shortly).

The loop that requests values from sensors only queries sensors that have an associated variable in the variable list.  So if you don’t put the ds3231Temp in your variable list, the program will never actually ask the DS32321 for the temperature.  In that case, the value returned by ds3231Temp->getValue() in your calculation equation will just be whatever junk was in that memory slot when the board booted up.  You’re actually kind-of lucky the program ran instead of just crashing or locking up.

You can force a sensor update from within the calculated variable by calling getValue(true) – that is set the “updateValue” flag to true instead of letting it default to false.  This will give you a brand new value to do the calculation from, but you lose all of the timing optimizations that can happen when the getValue() is called from within the array instead of from within the calculation equation.  For something like the temperature from DS3231 (which is actually the real-time-clock) the process of getting a new value from the sensor takes a trivial amount of time, so you can just add the word true to your calculation equation, deleted the variable you don’t care about and call it done.  That’s what I recommend you do.

If you wanted to do it “right” and have the sensors all update in the array but only output the calculated result to MonitorMW you should do something like in the “data saving” example where you put the raw value in the full array but only the calculated value in the “to go” array.  That is what I would recommend if you wanted were using multiple sensors and wanted to do a calculation based on the results of a “slow” sensor like turbidity.  Doing it that way you would allow the VariableArray to attempt to optimize the order in which it gets values from sensors and then your calculation equation would use the value saved in memory when all the sensor are finished.  But what you’re gaining in speed of update and possibly long battery life is at the expense of having to understand and write out a large portion of the logging routine yourself.  Which is why, since you’re only talking about the DS3231, I would not recommend you bother.

I think the Hydros 21 takes half a second or so to warm up and take a sample, so it’s probably fine.  It’s turbidity sensors, sondes, and anything Yosemitech that are really the slow-pokes.

If you’re not worried about the small amount of extra data consumed on your cellular plan by those few extra characters, you could also just include the extra variable and send it with the empty UUID just like you’re doing now.  If you’re right at the edge of a price change on your cell plan, it might make a difference, but it’s not going to be huge.  [~10ish characters * 1 byte/character * 288 posts/day (5min intervals) * 30 days = 0.0864MB/month per junk variable]   A lot of the cellular data consumed is in overhead as the unit opens the connection to the server, does the TCP three-way-handshake, and repeats any packets that don’t get acknowledged by the server.