Cumulus Support

steve wrote:

mcrossley wrote:I have a cpp library if that is any use?

Possibly; I suspect there's a lot of code involved though, because of the way these things are built.

Yes, it's a full astro library, picking out the components you need as a subset may be tricky.

Aha! I came across a port of that library to C#. I hadn't got as far as working out how to use it, but it sounds like it might be worth it.

This step change in theoretical max as discussed above appeared to get fixed in b3020 and I changed my Trans Factor setting back to 0.87 but now in b3021 it seems to be less than C1 again.

Is this feasible?

The code didn't change at 3020 (and your first post in this thread was after 3020 had been released).

As I mentioned earlier in this thread, I fixed an issue in my code (a small numerical error introduced in converting between degrees and radians) and in my tests that made the calculated figure closer to the C1 and original spreadsheet figures. That change was in 3021. The difference is down to the calculated position of the sun in the different libraries being slightly different.

OK, Must have got confused somewhere, I had made the adjustment from 0.87 to 0.89 back at b3018 - never downloaded 3019.
Found in b3020 I had to change it back to 0.87 so assumed there had been a change.

I can't explain why with b3021 I now have to change it back to 0.89. It's no problem now that I know it won't change, I'll just make the slight adjustment to the factor so it matches up to C1.

Interface Charts Sunshine Hours.

Have noticed something strange with this and only this chart.
It was showing the same value for two days even thought the second day value was actually different.
I first noticed this yesterday when I found the 3rd and 4th had the same value and subsequent days were one day offset with yesterday showing the value for the day before yesterday.

I ran updates on windows and restarted the PC and the chart then showed the correct info.
This morning I find the same thing has happened with the 7th and 8th both showing the same value even thought there was much more sun on the 8th.

I see this is reflected in the sunhours.json file in C:\CumulusMX which is sent to the website.
However I do not use this file on the website as an 8 day file is built on the website which includes the current days sunhours. I only mention this to indicate that I have no idea how often nor how long this may have been happening and to indicate that it is only this json file that is affected - the Dayfile is correct and the monthfile shows the value changing to 0.0 at 00:00 each day.

The sunshine hours figure is stored in an internal data structure along with other daily data for the other daily graphs. A new set of items gets added once a day, at rollover time. I'm not seeing this problem, but I use an 0900/1000 start of day, and I'm guessing that you don't? So that figure is available for 0900/1000 users, the sunshine figure is stored in a 'sunshine to midnight' variable, which is the one that gets added to the data structure for the graphs. I'm thinking that it could be a timing issue and that sometimes the rollover is done before the 'sunshine to midnight' item is set for the current day.

The code which writes the sunshine hours to dayfile.txt has a check for 0900/1000 and only uses the 'sunshine to midnight' item for that, otherwise it uses the current total, so that explains why dayfile.txt is correct. I'll add the same check to the code for the graph json files and that should fix it.

Yes I have Log Rollover set to midnight.

I'll keep an eye on it and see how often it happens and check again after the next build.

Thanks

Steve

Your post appears to be the answer to something that puzzled me with C1.

Recently I made changes to some sun hours values in the dayfile, but the graph didn’t change. After investigation I came to the conclusion that C1 was storing data internally. I assume C1 uses a similar system to MX.

Colin

The data is held within the graph itself in Cumulus 1. The effect is similar, but the mechanism is different. The purpose is to avoid loading and scanning dayfile.txt every time the graph is viewed.

The Interface sun hours chart is continuing 1 day behind - i.e. it has not duplicated/lost another day.
I am wondering if the issue arises as a result of restarting MX during the day. This last event certainly happened after a restart i.e. the day the restart occurred is replicated.

I cannot be certain but it looks like the diags indicate MX was also restarted the last time it happened.

Perhaps the code which pre-loads the data from dayfile.txt gets the dates wrong - I'll check. I'd expect the other data (daily rainfall, for example) to show similar symptoms, though, if that were the case. I suspect that what happens is that restarting actually corrects everything, but then at the end of the day yesterday's value gets added again (because of the issue I originally identified), and it continues to be one day out after that.

I am seeing a discrepency too, the web tag for total sun hours yesterday is 11.3, but CMX has put a value of 9.8 into my database. I use a 00:00 rollover

The SQL code does the same as the json graph data code; I changed that as well when I change the graph data code.

Can confirm that after a restart yesterday (more windows updates!!), the earlier data has corrected but yesterday is again repeating the day before.