Version 2.5.9 update

[PaulMy]

I have 2 installs of the gauges-ss:

Have successfully updated to version 2.5.9 on my Saratoga template http://www.komokaweather.ca/wxssgauges.php

But not in my Cumulus template http://www.komokaweather.com/gauges-ss/gauges-ss.htm

In checking I've found version 2.5.8 was the same, ok in the Saratoga template but not in the Cumulus.

I thought I was pretty good on getting the updates installed and working, but not sure what I may have missed?

Paul

Edited for correct SS-gauges versions

[BCJKiwi]

Presumably you mean 2.5.9 ??

I see it running in C1 at http://www.komokaweather.com/gauges-ss/gauges-ss.htm - what is the issue or have you fixed it?
I have it running in Saratoga and MX - not installed it in C1
There appears to be no difference (for Cumulus users) between 2.5.8 and 2.5.9 noted in the GitHub changelog but I do note the addition of a 'data.' for the cloudbase section in gauges.js.

Did you compare what ever the last working version was with the current version?

[water01]

2.5.9 was released to fix a bug with WView Users only other than that it is exactly the same as 2.5.8.

[PaulMy]

Well, the wonders of time!?! Now at another location it is working as expected without me doing anything. I will check from my weather computer when at home this evening and see what it shows now as well. It definitely was not displaying the gauges after I updated to 2.5.9 last night and I then also tried with going back to 2.5.8 (which I though had previously worked fine) so maybe a computer issue.

Thanks for looking... and the version number error is just another sign of age and doing without double checking. I have edited the original post.

Paul

[Nykita]

I thought I had some problems with my gauges in CMX a while back, but it was just "old timers disease", after I was told to clear my cache, I did and everything was fine ....

You didn't pull one of my stunts, did you? I'm sure glad stupid don't hurt!!!!

[PaulMy]

I don't think it is a cache thing, but it is an IE10 thing

Works fine in FF on the weather computer.

Any idea why it would work with the Saratoga PHP template set but not on my modified Cumulus template htm all on the same computer and IE10? The gauges-ss had worked fine on both in the past but perhaps the MS updates have caused some issues.

Paul

[mcrossley]

Paul, I'll have to see if I can find a copy of IE 10 somewhere later today, I may have a VM with it loaded somewhere...

[mcrossley]

Sorry all the vms I checked had either ie8 or ie11.

[BCJKiwi]

Have an intermittent issue which has been around for a while.
Trying to troubleshoot and have located the area of the problem but do not understand the code.

The issue;
Frequently when loading the gauges page, the red led will display and the marquee will say the system is offline and has not been updated for xxx days - this may be 200+ or 90 something etc.
realtimegauges is updating and the gauge needles are moving. After a time the led will go green and the forecast will display, then a while later it will say offline again.

If I rem out part of this section of code thus;

Code: Select all

                // Check for station off-line
                now = Date.now();   // millisecs from Jan 1, 1970
                tmp = data.timeUTC.split(',');
                _sampleDate = Date.UTC(tmp[0], tmp[1] - 1, tmp[2], tmp[3], tmp[4], tmp[5]); // yyyy,mm-1,dd,hh,mm,ss
                if (now - _sampleDate > config.stationTimeout * 60 * 1000) {
                    elapsedMins = Math.floor((now - _sampleDate) / (1000 * 60));
                    // the realtimegauges.txt file isn't being updated
/* BCJ Kiwi - Constant errors displaying this portion even though realtimegauges.txt updating regularly.
                    ledIndicator.setLedColor(steelseries.LedColor.RED_LED);
                    ledIndicator.setTitle(strings.led_title_offline);
                    ledIndicator.blink(true); */
                    if (elapsedMins < 120) {

The problem goes away.
In trying to see what is going on, I added a

Code: Select all

document.write(data.timeUTC);

which output 2015,35,19,3,9,8 - clearly a fallacious month.

Whlie writing this post and repeating the document write I got an output of 2015,9,19,3,9,8 which still does not make sense as the month should be 7 as we are in the 8th month and tmp[1] - 1 should reduce 8 to 7.
Also I do not understand the .timeUTC() as I cannot find any reference to it.

Any suggestions as to what is going on here?

Thanks

[mcrossley]

I have seen this too, I haven't got to the bottom of it yet (I haven't been looking too hard though), but your post gives an area to look at...

It is not .timeUTC() but data.timeUTC, i.e. the timeUTC string from the JSON data.

[steve]

Is this specific to MX? A problem with the processing of the format parameter on the <#timeUTC> web tag?

[water01]

Mark, this sounds like the problem I emailed you about.

I also investigated it but then it seemed to go away and I couldn't reliable reproduce the problem. In my case it seemed to start at 210 days old and reduce in 30 days after a refresh until the station was online but the gauges etc. were all reading correctly, it was just the banner saying it was offline for xxx days.

In my case as I use PHP to drive the site I am also using the "long polling" code.

[BCJKiwi]

Yes, my mistake as per the document write, data.timeUTC
By json data I presume you mean realtimegauges.txt ?
There does seem to be something wrong there as right now, when I look at realtimeguages.txt, that data line reads;
"timeUTC":"2015,13,19,12,13,45", which is not right. The month is not right, the rest are right.
The timeUTC webtag reads 12:10 on 19 August 2015 so MX is processing that correctly.
However the realtimegaugesT.txt file is requesting "timeUTC":"<#timeUTC format=yyyy,m,d,H,m,s>", so I presume the month 'm' should be M else it is actually putting in minutes instead of months so have changed the m to M for now and will see how that goes ( it is delivering the month but will have to see how the redlight goes as it does not always appear - just most of the time - which would be consistent with a varying number of minutes being in that data item instead of the current month.

It is the same for me with or without longpolling.
Also when it is in this 'mode', it the gauge needles take a very long time rotate into position as if it is either stepping through a long history, or perhaps something is in a loop of some sort which slows things down massively.

Remming out those 3 lines of code fix all these problems and I don't see doing this as an issue as there are the <2hr, <48hr and days ago error messages which cover any lack of data.

[steve]

However the realtimegaugesT.txt file is requesting "timeUTC":"<#timeUTC format=yyyy,m,d,H,m,s>", so I presume the 'm' should be M so have changed the m to M for now and will see how that goes.

The realtimegaugesT.txt file supplied with Cumulus MX has this:

"timeUTC":"<#timeUTC format=yyyy,M,d,H,m,s>"

If you're trying to use 'm' for the month, it's not surprising that you're having problems.

[water01]

Well spotted Steve. Because I was using the gauges before I switched to MX I still had the original realtimegaugesT.txt in place for Cumulus as I copied the original Cumulus directory across when I switched, so not only is #timeUTC wrong for MX but so is the #date tag.

Fixed them now and will see if this re-occurs.