Glitch in month.ini

[BCJKiwi]

There appears to be glitch in C:\CumulusMX\data\month.ini [Rain]
at
LongestWetPeriod=-9999
LongestWetPeriodTime=2022-03-01T00:00:00

However there is no such number in Mar2022log.txt
We have had no rain this month and Mar2022log.txt has 0.0 in every row of the file for the longest dry and longest we fields (according to the layout in the Wiki)

Longest dry period is 6 days (today being the 6th)
Charts show 0 rain for the month.

The MX User interface dashboard Records This Month page shows:-
High rain rate 0.0 mm/hr Tuesday, 1 March 2022 00:00
High hourly rain 0.0 mm Tuesday, 1 March 2022 00:00
High daily rain 0.0 mm Tuesday, 1 March 2022
Longest dry period 6 days Saturday, 5 March 2022
Longest wet period - days Tuesday, 1 March 2022

The default MX website shows
Longest Dry Period 6 days to 05 March
Longest Wet Period -9999 days to 01 March

[freddie]

Looks like the "undefined" value. As you have had no rain this month then the "longest wet period" is undefined. In an ideal world they would be null values (or perhaps 0).

[sfws]

What Freddie calls the "undefined value" is used for initialisation when Cumulus software (even the legacy releases) internally handles any derived value that is determined during a day, month, year, monthly-all-time, or all-time. I have not seen it described as a "glitch" before, but there have been references to seeing "999" in several previous forum posts over the last twenty years. It remains a shame that Steve Loft did not include nulls in his design. There are so many posts in this forum about invalid data issues.

I am no expert on the C# code used for MX, but it appears each "variable" is initialised and processed separately, so whilst Steve and Mark may have (in response to previous posts) translated some of these initialisations into "---" for output in "no occurrence" cases, others can still show the internal code value. I saw these reappear in MX after the massive July 2021 internal code rewrite for MX 3.12.0 b3134 - Beta. The announcement talks merely of simplifying code to minimise time for rewrites of the various files, but it may be that code rewrite also lost some translation of initialisations into non-occurrences. I think some may have been "corrected" in response to other posts, but longest dry/wet period can still produce a -999 until the first occurence for monthly, yearly, and longer periods. For a daily based example, look at almost any "today" web tag where you can have a non-occurrence, e.g. <#chillhoursToday>.

I validate everything before it gets to my database tables or web pages, I use custom SQL update, and my own PHP scripts for all .ini file and web tag processing. I introduced code that translated "±999" (the number of digits varies depending on max value) into zero or null as appropriate in my PHP when I first wrote a script to load dayfile.txt into a database table back in 2014; and took a similar approach when I subsequently introduced a database table equivalent of month.ini and when I wrote a set of Cumulus template files that include web tags used to initialise PHP variables. I can't remember what changes I made last July to all of these, although it did (in some cases) involve a replace of nonsensical MX values with my own calculations.

[mcrossley]

As has been surmised, CMX does not use null values, so initialised values use large positive or negative numbers. These are stored in the ini files (for technical reasons), but should be translated to "dashed" or zero values for output on the console/web tags

[BCJKiwi]

It seems this has not been resolved in the last couple of updates.
Is it on the list of things to be done?

We have just had some rain (lots of it !) so can't really tell if it has been fixed or not but it does not show up in the updates file.

Thanks

[freddie]

It's on the list, but hasn't been done just yet. Nothing to be "fixed" as such, just the usage of null values in place of initial values.

[mcrossley]

As @sfws says, I don't think there is anything to fix really. MX is using the values 9999 and -9999 (some were/still are 999) internally to represent uninitialized values.

So -9999 has a different meaning from zero.

These values should not appear in your data or dashboard - if they do, then that is a 'glitch' - they are for internal use. I consider the .ini files as "internal use" as well as they store internal variables across invocations of MX.

[sfws]

Mark, you slightly misunderstood me, some initialisations in various .in files DO appear in web tags, as I said before.
Which is why I validate what MX generates.

[mcrossley]

If you can let me know which ones, then I can get them fixed, thanks.

[sfws]

If you can let me know which ones, then I can get them fixed, thanks.

I can't give you a definitive list.
This discussion is about initialisation values, to test all of those requires a test system set up to run tests on the very first day Cumulus is being run.
You should have a better knowledge than me of which web tags involving counting, but (as I said each is handled separately) some may have already been fixed.

Let me recap the earlier posts:
In the very last line of the very first post - the web tag for Longest Wet Period in a Month is the example that started this topic.
Freddie's post says it seems a non-occurrence is being reported in this way.
My first post in this topic - I can understand minimum/maximum extremes being initialised at ±999, but it appears from release 3.12.0 that this sort of initialisation is also now being used (instead of zero) for counts. The specific examples I gave of web tags that could have non-occurrences were Longest dry/wet periods for month/year/all-time, and <#chillhoursToday>.

[mcrossley]

OK, I have fixed the "longest dry/wet" count web tags for the next release.
The #chillhourstoday I do not understand, as neither the ChillHours and YestChillHours variables (which can both be used to determine the today value) are ever initialised to the "null" 9999 values, always to -1 or 0. If the value is still -1 the tag outputs "n/a"

[sfws]

I found time to scan every web tag produced by MX (using the script at viewtopic.php?p=156602#p156602, and I cannot spot any more initialisation figures, but a proper check will have to wait until 1 January!

The default MX website shows
Longest Dry Period 6 days to 05 March
Longest Wet Period -9999 days to 01 March

OK, I have fixed the "longest dry/wet" count web tags for the next release.

Thinking about these tags, in Brian's example, the last day of his previous month was dry, and so were the first five days of March. This is why the web tag reports on 5 March, there have been 6 dry days.
There have been no wet days in the same 6 days, so surely the tag should report zero days as the longest wet period. Your top tens web page has a query to count longest dry/wet period and that will output zero IIRC in the same circumstances.

Looks like the "undefined" value. As you have had no rain this month then the "longest wet period" is undefined. In an ideal world they would be null values (or perhaps 0).

Freddie says no rain means the period is undefined.
Is no days really an undefined period? I have not yet caught Covid, although I know some people have caught it more than once, does that mean I should be telling people that the longest number of days I have been ill with Covid (reporting for this month, this year, and all-time) is undefined?

I would see "--" as being used when there are no rain measurements due to a missing sensor, just like
<#AirLinkAqiPm10_1hrIn > reports "--" as I have no airlink sensor.

I understand you have already coded it to report "--", but my illness example, shows zero would be better.

The #chillhourstoday I do not understand, as neither the ChillHours and YestChillHours variables (which can both be used to determine the today value) are ever initialised to the "null" 9999 values, always to -1 or 0. If the value is still -1 the tag outputs "n/a"

There is a definite bug in your code.

I find the naming of these new Chill Hours tags confuses my brain. It would be better if names included words like "Cumulative" and "Increment", then it would be clear what they are supposed to be reporting.

There are 4 tags now, this is a recent snapshot of their contents for me
<#chillhours> reports "1692.2"
<#chillhoursToday> reports "1692.2"
<#chillhoursYest> reports "4.0"
<#Ychillhours> reports "1692.2";
So far today has been mild, therefore the increment today should be reporting as zero, this reporting of the cumulative number in error (when there are no chill hours in the day) means it can report 99 or 999, or any other number. It is just a coincidence that it was reporting the number you use for initilisation when I made previous check for you.
When there are some chill hours in the day, it shows a number between 0.1 and 24.0. I prefer 2 decimal places, but you provide a decimal place output modification parameter, so I use that.

When Steve introduced chill hours, there was quite a bit of interest, and for those still using the legacy software there probably still is, as the cumulative figure shows both on the "this year" screen, and the "this year" web page.

No chill hours figure appears in any MX interface page nor any .json file. So it is possible I am the only gardener still appreciating this output. Perhaps other people look at alldailydegdaydata.json?

[mcrossley]

Regarding the Longest Dry/Wet values, looking at the various stations it is impossible to determine across all of them if a rain sensor is reporting or not. So the "current" values I'll initialise to zero. The monthly records I'll leave to initialise at the "null" value, so new users will see dashed records for months that they have no data for yet.

The chill hours, yes if the chill hours are not currently incrementing the web tags for hours Today and Yesterday give errors.
The hours were incrementing when I tested the code

There was also a rounding error on the Yesterday hours as it relies on the values from the dayfile which are only recorded to 1 dp. So if you are looking for 2 dp, then the yesterday figure may be a little suspect. The Today figure uses the full precision.

The changes will be in v3.16.