Cumulus Support

BCJKiwi wrote:Did you ever get around to the 'extra timers' that were requested?

Sorry, you'll have to remind me what those are.

Have been looking at the Astronomy page in the Saratoge PHP templates.
It relies on UTC date/time values for the moonphases and UTC date/time values for the equinox/soltices.

What exactly is required for these? I might be able to provide those if the library I use provides them. It looks like it will do things like 'date/time of next/previous full moon' etc, and 'date/time of winter/summer equinox', and I believe it supplies them in UTC.

Did you make any changes to the B/L file to assist with loading solar data from external an source?

No, and I don't propose to just now.

Would you please advise the sequencing of the live data on the PC screen, the creation of realtime and the sending of realtime.

The display on the main screen and the realtime.txt updates are independent. The realtime.txt file is updated with the current data at the configured interval, and then uploaded immediately to the web site, if configured to do so.

HansR wrote:As 1.9.3 is apparently still open, would it be considered small to have the current weather status being sent along in realtime.txt?

Do you mean the 'current conditions'? I don't like adding things to realtime.txt, particularly text, as it increases the size for everyone. You can create your own file using web tags, assuming what you need has a web tag. If it doesn't, I could look at adding one.

OK, I'll look into the webtags.

steve wrote:

BCJKiwi wrote:Did you ever get around to the 'extra timers' that were requested?

Sorry, you'll have to remind me what those are.?

See here:- https://cumulus.hosiene.co.uk/viewtopic.php?f=20&t=8376

steve wrote:

Have been looking at the Astronomy page in the Saratoge PHP templates.
It relies on UTC date/time values for the moonphases and UTC date/time values for the equinox/soltices.

What exactly is required for these? I might be able to provide those if the library I use provides them. It looks like it will do things like 'date/time of next/previous full moon' etc, and 'date/time of winter/summer equinox', and I believe it supplies them in UTC..

These are the tagnames and the data that WD sends. Have tested these (manually added tags and data to a static test version CUtags.php) and they work with the wxastronomy.php script in the Saratoga templates.
firstquarter|14:19 UTC 20 November 2012:|:
fullmoon|14:46 UTC 28 November 2012:|:
lastquarter|15:32 UTC 6 December 2012:|:
nextnewmoon|8:42 UTC 12 December 2012:|:
marchequinox|05:14 UTC 20 March 2012:|:
junesolstice|23:08 UTC 20 June 2012:|:
sepequinox|14:48 UTC 22 September 2012:|:
decsolstice|11:11 UTC 21 December 2012:|:
So whatever is available would be a big help. Have atached a snippet from the WD testags.php of the non weather specific tags section. The ones listed above are those used in the astronomy script but why not send whatever is available?

steve wrote:

Did you make any changes to the B/L file to assist with loading solar data from external an source?

No, and I don't propose to just now.

OK. What format does B/L use? Is it the same as Davis sends which I understand is w/m2. This seems to be the standard.

steve wrote:

Would you please advise the sequencing of the live data on the PC screen, the creation of realtime and the sending of realtime.

The display on the main screen and the realtime.txt updates are independent. The realtime.txt file is updated with the current data at the configured interval, and then uploaded immediately to the web site, if configured to do so.

OK, thanks.

BCJKiwi wrote:See here:- https://cumulus.hosiene.co.uk/viewtopic.php?f=20&t=8376

Ah, right. Sorry, but I'm looking for small changes just now.

firstquarter|14:19 UTC 20 November 2012:|:
fullmoon|14:46 UTC 28 November 2012:|:
lastquarter|15:32 UTC 6 December 2012:|:
nextnewmoon|8:42 UTC 12 December 2012:|:
marchequinox|05:14 UTC 20 March 2012:|:
junesolstice|23:08 UTC 20 June 2012:|:
sepequinox|14:48 UTC 22 September 2012:|:
decsolstice|11:11 UTC 21 December 2012:|:

I think I can do all of those directly from the library I use. I'll put them in and we'll see how it goes.

OK. What format does B/L use? Is it the same as Davis sends which I understand is w/m2. This seems to be the standard.

I can't remember. But the file has four lines, like this:

0.00
0.00
6.26
True

Cumulus only uses the 1st line, which is hours of sunshine today so far, and the 4th line, which is whether or not the sun is currently shining.

I don't know what a 'small and simple chance ' is, so I'm not asking for anything....

Add "Sunshine hours" to All-time monthly records, so that for example "sunniest April" on record could be viewed.
Total monthly sunshine hours are already viewable in the "this month" view, so perhaps this will make it easier to add this function?

Peter

Tonky wrote:I don't know what a 'small and simple chance ' is, so I'm not asking for anything....

That's because it is a "small and simple CHANGE"!!

steve wrote:

BCJKiwi wrote:See here:- https://cumulus.hosiene.co.uk/viewtopic.php?f=20&t=8376

Ah, right. Sorry, but I'm looking for small changes just now.

firstquarter|14:19 UTC 20 November 2012:|:
fullmoon|14:46 UTC 28 November 2012:|:
lastquarter|15:32 UTC 6 December 2012:|:
nextnewmoon|8:42 UTC 12 December 2012:|:
marchequinox|05:14 UTC 20 March 2012:|:
junesolstice|23:08 UTC 20 June 2012:|:
sepequinox|14:48 UTC 22 September 2012:|:
decsolstice|11:11 UTC 21 December 2012:|:

I think I can do all of those directly from the library I use. I'll put them in and we'll see how it goes.

Great - looking forward to it.

steve wrote:

OK. What format does B/L use? Is it the same as Davis sends which I understand is w/m2. This seems to be the standard.

I can't remember. But the file has four lines, like this:

0.00
0.00
6.26
True

Cumulus only uses the 1st line, which is hours of sunshine today so far, and the 4th line, which is whether or not the sun is currently shining.

1st & 4th or 3rd and 4th?
OK Thanks. If data is not w/m2 then presumably Cumulus won't be able to produce the solar graph.

steve wrote:

captzero wrote:Would adding a 30 day graph for Daily Wind Run (similar to existing rain graph) be considered a small enhancement?

No, sorry; I'm talking about changes of a few lines of code, not a week's work.

Hi Steve,

Do you regret starting this thread yet?

Yes, adding a graph would seem a lot of work, but what about "Yesterday's Windrun"? However, I can't suggest where you'd squeeze it in on the display (and one of my regular uses of Cumulus is on a 1080 x 600 Netbook, so I certainly wouldn't want to the see the layout compromised).

The current issue is that the windrun accumulates during the day and unless you happen to look at the screen at around 23.59, the day's value is "lost". It just resets to zero and AFAIK (unless it's a new record) can only be viewed then via the dayfile/editor.

Cheers, Alan.

BCJKiwi, most of the moon related data you are requesting can be produced with PHP scripts, such as those from the PHP/AJAX Website Template Set.

For example, all moon related information (such as the moon phase , the new moon, the first quarter, the full moon, the last quarter and the new moon) is produce by the 'cGetMoonInfo' function, all season information (and both equinox/solstice) is produced by the 'cGetSeasonInfo' function - check the 'common.php' template. The 'sunrise, sunset, transit, civil_twilight_begin/dawn, civil_twilight_end/dusk, nautical_twilight_begin, nautical_twilight_end, astronomical_twilight_begin and astronomical_twilight_end' can all be extracted from the PHP 'date_sun_info' function.

If you use any of those functions, the time/date value will be produced into an easy to adapt/convert Unix time stamp format rather than in one of the numerous non-standard time formats used by Cumulus...

So why burden Cumulus with new lines of code producing data that only a few people would use...

Thanks Ray
I thought I'd seen some big tables of that sort of stuff around somewhere before but did not find it when I looked.
Don't know how much code is required in Cumulus - if it's all in the standard libraries I would not have expected much extra burden on Cumulus. The original request was based around the possibility that Davis was delivering this data.

I still feel it would be more efficient overall to just read in a variable than troll thru the tables and do the extra conversion processing at the website.

The astronomy script I have does not use those functions but instead uses the tags from WD.
Have now found another version which does call those functions but still just displays the current date and time - it is assuming WD is in use, not anything else. I will have to tweak that script to put back the better graphic that Cumulus provides and to use Cumulus supplied today moonrise/moonset data (which varies slightly but not significantly (from the PHP values) but that should not be too hard (since i 've done it already for the earlier script). However if Cumulus delivered the tags then the first one I was using would work without modification and not need to call those functions.

It's over to you Steve.

OK been working on this and it works with one Xdebug warning.

The page displays all the correct data but Xdebug is showing
Warning: Creating default object from empty value ..

This is coming from the second line (664 right at the bottom of common.php) Since it is a warning and the the correct result is achieved I presume this is a minor? issue.
Interestingly it does not repeat the warning for the following 3 lines (for summer, fall and winter)
Any suggestions?

So much easier with the tags!

Added note:-
Steve - Apologies for sidetracking the thread.
Issue resolved with the generous assistance of Gemini06720 (Ray) so the wxastronomy.php script is now working.

Tonky wrote:I don't know what a 'small and simple chance ' is, so I'm not asking for anything....

I realise that it's not always obvious, and I did hesitate before asking. It doesn't include anything which changes the way Cumulus works, or new facilities (new graphs, or new highs and lows, for example). I'm talking about simple additions that I can do in half a dozen lines of code that don't change anything that already exists in Cumulus. You can always ask and I can say no. I'm trying hard not to at some of the suggestions so far

BCJKiwi wrote:1st & 4th or 3rd and 4th?

Definitely 1st and 4th; I don't know what the 6.26 is in that example (I don't have a sun recorder any more, that's the last file that the one I had created).

If data is not w/m2 then presumably Cumulus won't be able to produce the solar graph.

The only thing Cumulus does with the B/L file is take sunshine hours and whether it's currently sunny or not.