Page 1 of 1

Bug? Solar radiation values truncated to integer? **no bug - solved**

Posted: Tue Sep 26, 2017 8:33 pm
by dolfs
I noticed something strange today and investigated. Setup: Ambient ObserverIP connected to MB running 3.2 (latest version of that).

I see that the ObserverIP is reporting solar radiation values in its Live Data page (where MB gets its information) with two decimals and those decimals are often non-zero. Yet, when observing these values on the MB Live Data screen, the values are always integers. Further investigation by logging values to my server using a template that has this expression:

Code: Select all

[sol0rad-act=.2:-999]
The formatting request for two decimals is honored, but the decimals are always .00. Further logging and inspection also shows that the values from the ObserverIP appear to be truncated, and not rounded, as would be more proper if MB for some reason has to insist on integer values.

So the questions:
  • Why is MB only doing integer values?
  • Why, given the use of integers, is MB not rounding but truncating?
  • Should it not be the responsibility of the user/template that uploads to determine (through formatting options) to control the number of decimals? In other words: can this be fixed please?

Re: Bug? Solar radiation values truncated to integer?

Posted: Tue Sep 26, 2017 11:42 pm
by admin
MB stores solar radiation as plain integers. Decimals do not make any sense here, as you get values between 0 and about 2000. Adding decimals to that is like rolling dice.

There is nothing to fix.

Re: Bug? Solar radiation values truncated to integer? **no bug - solved**

Posted: Fri Sep 29, 2017 7:53 am
by dolfs
You conveniently skipped over the truncation vs rounding issue.

As far as usefulness of decimals, that would be a matter of opinion (and therefore perhaps left to the end-user), and you clearly state your's although it is not like rolling dice. These decimals, while arguably insignificant in the scheme of things, are NOT random. Rounding would be appropriate.

I just *love* how you frequently decide, unilaterally that something is **solved**, even if you decide to not do anything and possibly skip issues presented. In most forums, the original poster is the one deciding whether they consider their issue "solved". Perhaps you should just slam a **closed** label. That would more appropriately reflect what you are doing.

Re: Bug? Solar radiation values truncated to integer? **no bug - solved**

Posted: Fri Sep 29, 2017 9:28 am
by Mattk
What would anybody want to include 2 decimals to integer type values that cover a range from like 0-2000, rather meaningless in the overall context of Solar Radiation values. It's much the same with those that want to time stamp readings to the exact second from sensors measuring over several to many seconds, again rather meaningless. Rounding (in decimal terms) is ridiculous over a range of values from 0-2000

Re: Bug? Solar radiation values truncated to integer? **no bug - solved**

Posted: Fri Sep 29, 2017 6:20 pm
by admin
dolfs wrote:
Fri Sep 29, 2017 7:53 am
You conveniently skipped over the truncation vs rounding issue.
Come on, when your consumer-market station shows 1234 also 1250 or 1200 can be right for solar radiation (if you are lucky). I can't believe that you really want to discuss rounding vs truncating with me given that error range. :roll:
dolfs wrote:
Fri Sep 29, 2017 7:53 am
I just *love* how you frequently decide, unilaterally that something is **solved**, even if you decide to not do anything and possibly skip issues presented. In most forums, the original poster is the one deciding whether they consider their issue "solved". Perhaps you should just slam a **closed** label. That would more appropriately reflect what you are doing.
I will continue to mark discussions as "solved" that have an answer to the problem raised in the subject. This helps others who might face a similar problem to see at once that this thread will help them and show a solution or work-around. In this particular case my solved-remark does also state that it is not a bug as suggested in the subject.

Re: Bug? Solar radiation values truncated to integer? **no bug - solved**

Posted: Fri Sep 29, 2017 11:42 pm
by dolfs
Come on, when your consumer-market station shows 1234 also 1250 or 1200 can be right for solar radiation (if you are lucky). I can't believe that you really want to discuss rounding vs truncating with me given that error range. :roll:
I do not question the fact that a station may deliver more digits than can be considered significant for their sensor's abilities. In my particular case I am actually trying to use MB functions to build a record of the values reported by my station, exactly so I can study sensor stability, quality of data etc. In other words, I would like to record values, as received from the station, not truncated, or manipulated.

Are you saying that because I have a "consumer station" MeteoBridge's approach is justifiable? Are you having different code for those of us who have "pro" stations? I doubt it, but if you do I would highly question it.

Based on your reasoning you might also consider adding a random number ±50 in that range to our station's numbers, or deciding to only deliver multiples of 100. Seems you think that all would not matter. The only thing I am discussing is MeteoBridge not making decisions for us, rounding wise. If our stations are reporting certain values, we should be allowed to be responsible for how we treat them and how want to deal with them.

Now, if memory constraints then dictate that for the various modifiers over 60 minutes etc. you can only store integer values, so be it and nobody can create memory that does not exist, but basic science dictates that you should round, unless you want to introduce further bias in the numbers.

Re: Bug? Solar radiation values truncated to integer? **no bug - solved**

Posted: Sat Sep 30, 2017 10:09 am
by admin
I do not agree. Could you please lecture people who ask for it. Thanks!