Cumulus Support

API approved and I have it working (yes, a typo).

http://www.komokaweather.com/komokaweather-ca/wxFWI.php

Prediction of Days Since Last Rain match the current weather forecast of 3 days rain and then none. Well done
I have started a log and hopefully won't forget to keep it up...

Enjoy,
Paul

1.8.0 is installed. http://weather.inverellit.com/fwi.php

No issues & up & running in minutes.
Do notice two anomalies,

Your demo is 1.8.1, obviously yet to be released,
& secondly, I'm missing 30th Oct.
I'm sure that is very likely explained as it's 7:45am on the 31st as I post this and my 9:00am roll over time has not yet arrived.

As it's already the 31st, the api returns no forecast for the 30th.

Looks excellent though!

I'd guess it's tracking pretty well as we are hopefully heading for rain.

Phil.

The above has me wondering what data is available that could be applied to "Today", regardless of the rollover time.

Obviously Today, does not exist in a dayfile until the rollover in either case, so it's only the JSON's used for graphing that could be considered.

Other thing I did read across in the Wiki a few day back was some scripting that read realtime.txt & created another file called realtime.log.
Think it mentioned logging at 10 minute intervals & the ability to specify the logs size.

Phil.

@Hans ..

Paul running 'original' layout still has corrupted degree symbol.

OK, thanks to all so far.

@Phil: Yes I think your explanation is correct. My advice is to schedule a pwsFWI run 1 hour after the rollover run and see where we are then. You could check (put the URL in the browser you get some readable thing) if the prediction date changes between 00h00 and 01h00 or that it changes around UTC (which I think would be incorrect). Problem is rollover time puts the date in dayfile.txt which is an entity the API does not know of course. Dates switch at midnight not at 9 am.

@meteosangonera & @all: I will work the minimal humidity ASAP issue. Expect a versions 1.8.1 soon (yes @Phil, that's the one )

@PaulMy: Also I noticed that still not all degree signs are correct. Apparently have to create a different approach for the generated javascript than the generated HTML. It's a nuisance. I'll try to get that out the same time with the other issue.

You'll be hearing from me ASAP with - yes - a new release

Phil23 wrote: ↑Wed 30 Oct 2019 9:02 pm The above has me wondering what data is available that could be applied to "Today", regardless of the rollover time.

None, we build on Cumulus and have to deal with that.

Phil23 wrote: ↑Wed 30 Oct 2019 9:02 pm Obviously Today, does not exist in a dayfile until the rollover in either case, so it's only the JSON's used for graphing that could be considered.

Other thing I did read across in the Wiki a few day back was some scripting that read realtime.txt & created another file called realtime.log.
Think it mentioned logging at 10 minute intervals & the ability to specify the logs size.

Really you're a nice guy, but believe me, I will not do such tricks
I think the system as it stand works fine, you work with 9 am roll over, that has consequences. Just run utils after the rollover and you'll probably be fine.
Dates, rollovers, Cumulus and external API's ...

beteljuice wrote: ↑Wed 30 Oct 2019 9:13 pm Paul running 'original' layout still has corrupted degree symbol.

Yes, noticed. Thnx.

@PaulMy: Looks good. Thanks for doing the log as well.

Just to make it clear, I tried both and the corrupted degree symbol shows on both the Standard and Beteljuice Results format.

In looking at Phil's View source likely using standard Cumulus template has - <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Where mine using the Saratoga sample new script template has <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />

Enjoy,
Paul

Something else to put on the todo list?
Try the XML and CSS validation links from Paul's page.

HansR wrote: ↑Wed 30 Oct 2019 9:17 pm My advice is to schedule a pwsFWI run 1 hour after the rollover run and see where we are then.

My scheduled run has now taken place just after the 9:00am roll over & the 30th is now reported as expected.

Will run it again just after 10:00am & post the comparison to see if the figures move.

9:00am Readings.

10:00am Readings.


To come.

Re. degree symbol problem in table ...

What I think is happening is that although Hans prog is producing a .txt file, it is in fact encoded as UTF-8 and the symbol has been 'created' in the file.

So if the symbol is replaced by &#x00B0; it should be alright.
(There have been a few strange problems with ftp / servers corrupting &deg;)

HansR wrote: ↑Wed 30 Oct 2019 9:22 pm

Phil23 wrote: ↑Wed 30 Oct 2019 9:02 pm The above has me wondering what data is available that could be applied to "Today", regardless of the rollover time.

None, we build on Cumulus and have to deal with that.

Think that thought got lost in translation. I was not thinking of going outside Cumulus.

The point I am looking at as it hits 12:00 mid-day here is the variation between the still current forecast & the actual Cumulus readings.

Forecast has Temp @ 26°C & Humidity @ 42% for 12:00pm

Actual is at Temp 28.8°C & Humidity @ 35% as at 12:00pm.

Wind & Pressure pretty much the same. Cloud cover (while irrelevant) more like 20% as opposed to 72%.
Not huge differences I know, but on other occasions more significant.

Not intending to be argumentative, just trying to clarify my previous comment as I'm aware language differences can cause miss-communication.

Cheers.

beteljuice wrote: ↑Thu 31 Oct 2019 12:08 am Re. degree symbol problem in table ...

What I think is happening is that although Hans prog is producing a .txt file, it is in fact encoded as UTF-8 and the symbol has been 'created' in the file.

So if the symbol is replaced by &#x00B0; it should be alright.
(There have been a few strange problems with ftp / servers corrupting &deg;)

Ehm... almost.
It was a problem with VS/C# translating / interpreting the string with the code when transferring to another string, to another string and again to another string. Don't ask why has to do with caring for all kinds of possible units. But it now seems under control. Don't worry, be happy.

I still have to use two string arrays though for the degree units: one for plain HTML generation and one for javascript/HighCharts. So HTML can handle &deg; &#186; and &#x00B0; but javascript can only handle \u00B0 (no ampersand code allowed). I use now &deg; for HTML generation and \00B0 for javascript/Highcharts generation. But websites within websites within websites may have a problem with that.

After few problems that solved themselves and I don't know how now everything seems to be working OK.
http://www.pogoda-niesiolowice.kaszuby. ... isknew.php
Now is the time to watch how the predictions match calculations.
Piotr

Version 1.8.1 is online.
Famous last words: last bug has been fixed

@pernaczy: thanks! Our PMs and this message crossed. Everything is OK now!
@Phil: OK. Now we're going to keep the log as I asked and then we can determine how much the prediction will differ from the actual calculated value.
@beteljuice: Unicode is a bitch.
@mcrossley: Todo is a great concept
@meteosangonera: H/T thanks for looking to the system with some depth, highly appreciated.
@PaulMy: Surprise me with a bug.
@hvd51: Thanks for the complimentful silence (btw: remarkable that your prediction is generated at midnight rollover and does not have a gap of date)