I am trying to read the sensor data via the API. I recently connected my water probe and am trying to read its realtime data.
Is it possible to specify any other unit as "watt" to read from the Fluksometer? When reading the manual (topic 3.6 in https://www.flukso.net/files/flm02/manual.pdf) it seems the Fluksometer only knows one unit. I can see why, the gas and water probes are probably too new and not yet in the firmware. Are there any plans for a new firmware and would it be possible to upgrade the current Fluksometers?
Thanks again!
Bart will answer you in a more correct manner - but as I'm aware of you'll get the liter pulses read out of the api. So it doesn't matter what unit the meter is counting. (IMHO the 'unit' in which the meter counts isn't important at all ... only when you start making graphs and calculations, then the unit is having it's place in the equation ;-)
oops ... sry - above answer was probably not the one you were looking for.
In regards to the api request you can specify 2 units : "watt" and "lperday" as specified in https://github.com/flukso/flm02/blob/develop/openwrt/package/flukso/luas...
I hope this answered your request...
Thanks for you answer gallon_kbms, you are right, both "watt" and "lperday" are accepted. I know the readings are the same but it feels wrong to pass "watt" in the wrapper script I'm writing when you are querying a water sensor.
The documentation only notes the "watt" unit and should probably be updated. Anyway, thanks for reminding me I should trust code over documentation. :)
The API is now used by the Flukso dash and indeed uses lperday for water and gas sensors. Make sure you always pass the correct unit for each call. You're right about the documentation not being up to date though. Will be corrected.
For future reference: when querying a water sensor (and I guess any pulse sensor for that matter) you might get "nan" as the value for the reading when nothing is happening. Could probably be improved a little and return 0 but guess it divides by 0 somewhere in the FLM code causing the "nan" value to appear.
In the case of a pulse port, we cannot determine any value since the last pulse. We have to wait for the next pulse to arrive so that we can calculate the value using the time difference between the two pulses. It's not correct to set the value to zero as it will most likely be different from zero. So not-a-number is the more appropriate 'value' here. I know this calls for more coding on the client side. A nan on the dash is interpreted as 'do not plot anything at that timestamp'.