Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of Home › Forums › Monitor My Watershed › Plotting calculated values
- This topic has 11 replies, 2 voices, and was last updated 2020-01-28 at 7:14 PM by
Sara Damiano.
-
AuthorPosts
-
-
2019-11-12 at 5:59 PM #13326How do I set up a calculated value to plot to my site at data.envirodiy.org? I’m using the example code here: https://github.com/EnviroDIY/ModularSensors/blob/master/examples/baro_rho_correctionHow do I set up a calculated value to plot to my site at data.envirodiy.org? I’m using the example code here: https://github.com/EnviroDIY/ModularSensors/blob/master/examples/baro_rho_correction/baro_rho_correction.ino to do the calculation, set up the variable, units, etc., but I can’t seem to figure out how to set up the portal to accept the calculated data. How do you add a calculated value as a “sensor” to your site?
Thanks,
Matt -
2019-11-13 at 10:43 AM #13327
Select “All” as the manufacturer and “Calculated” as the sensor model.
Attachments:
-
2019-11-15 at 6:59 PM #13356Thank you Sara. I see that the list of calculated variables is curated, so this avenue may not be the best fit for my use case. In particular, what is a non-hacky way for me to display a sensor’Thank you Sara. I see that the list of calculated variables is curated, so this avenue may not be the best fit for my use case. In particular, what is a non-hacky way for me to display a sensor’s measurements in different units? I’m using the ModularSensors library. Would I need to customize the code for that sensor to do the units conversion?
This is not a critical need for us, so I don’t want to ask you to spend any substantial time on it. I am curious whether there is an existing hook somewhere in the code for doing units conversion, or, if not, whether there is enough interest in creating one in the future.
Best,
Matt -
2019-11-18 at 1:28 PM #13360Right 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 thRight 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”.
-
2019-11-18 at 7:24 PM #13368Thanks Sara. I was plotting air temperature from the Maxim DS3231 and wanted to display it in F, but that option is not available that I can see. I hope I didn’t make it sound like I thought anyThanks Sara. I was plotting air temperature from the Maxim DS3231 and wanted to display it in F, but that option is not available that I can see. I hope I didn’t make it sound like I thought anything about the portal was hacky; my use of calculated variables to do a unit conversion was. 🙂
-
2019-11-21 at 6:17 PM #13388I’m unclear on what changing the units of a temperature variable on MMW does for me; it seems to label the data as degrees F, but the values are still in deg C, as it appears that the Decagon CTI’m unclear on what changing the units of a temperature variable on MMW does for me; it seems to label the data as degrees F, but the values are still in deg C, as it appears that the Decagon CTD-10 (in this case) can only report in deg C. Assuming that is the case, could we get a calculated variable set up on MMW for temperature in deg F? Our users are also wanting to see depth in inches, so I’d like to have a calculated variable set up for that as well, if possible.
Thanks,
Matt -
2019-11-22 at 10:54 AM #13389I’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, incI’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).
-
2019-11-27 at 5:42 PM #13403
Sweet – I’ve got it now. Thanks Sara!
-
2020-01-27 at 3:18 PM #13735I’m converting the temp value coming from the DS3231 from C to F and reporting the F value to MMW. However, unless I also add the C value to the variableList array, the F value being reported isI’m converting the temp value coming from the DS3231 from C to F and reporting the F value to MMW. However, unless I also add the C value to the variableList array, the F value being reported is -17966.2, which doesn’t make any sense. What am I missing?1234567891011121314151617181920212223242526272829303132333435363738// Create a DS3231 sensor objectMaximDS3231 ds3231(1);// Create a temperature variable pointer for the DS3231Variable *ds3231Temp = new MaximDS3231_Temp(&ds3231, "d3a573b9-294a-4c5e-bef8-41b61ccb2197");// Units conversion functionsfloat convertDegCtoF(float tempIn){ // Simple deg C to deg F conversionreturn tempIn * 1.8 + 32;}// ==========================================================================// Creating the Variable Array[s] and Filling with Variable Objects// ==========================================================================float getRTCTempinF(void){ // Convert temp for the DS3231return convertDegCtoF(ds3231Temp->getValue());}// Constructing calculated variables. (Used baro_rho_correction.ino and VariableBase.h from enviroDIY.) -M.Barney// Create the calculated temperature Variable object and return a variable pointer to itVariable *calcRTCTemp = new Variable(getRTCTempinF,1,"temperatureDatalogger","degreeFahrenheit","TempInF","22f72fe8-ac24-4773-b9e9-92f204a726ed");Variable *variableList[] = {calcRTCTemp,ds3231Temp, // If I remove this line, the value for calcRTCTemp gets reported as -17966.2. With this line in place, calcRTCTemp gets reported correctly.new Modem_RSSI(&modem, "c280d8aa-c334-45b9-8d02-8b913038b69e"),new Modem_SignalPercent(&modem, "79c60153-41ab-4801-9dda-e80c02af25b8"),new ProcessorStats_Battery(&mcuBoard, "2f34e2e3-fa7d-4b30-a4e5-af0db5337fbf")};
-
2020-01-27 at 6:28 PM #13737The 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
ds3231TempThe loop that requests values from sensors only queries sensors that have an associated variable in the variable list. So if you don’t put theds3231Tempin your variable list, the program will never actually ask the DS32321 for the temperature. In that case, the value returned byds3231Temp->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 wordtrueto 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.
-
2020-01-28 at 5:15 PM #13741Hi Sara, Thanks very much for those details. I will set the updateValue flag to true for values calculated from sensor readings where we’re not also sending the non-calculated reading of the samHi Sara, Thanks very much for those details. I will set the updateValue flag to true for values calculated from sensor readings where we’re not also sending the non-calculated reading of the same variable. I’m doing this on the DS3231 temp as well as the Hydros-21 depth, which I’m converting from mm to inches. If you anticipate this causing any timing issues for the Hydros, let me know, and I will implement the dual array solution you’ve described.
Best,
Matt
-
2020-01-28 at 7:14 PM #13743I 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-pokeI 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.
-
-
AuthorPosts
- You must be logged in to reply to this topic.
