Steel Gauges question

[Steve2Q]

Hello. I was able to get the Steel Gauges working, thanks to some help from Chris T. I do have one glitch, however.

Go to my website at:     http://photokinetics.org/Weather/index.html         and click on the Steel Gauges button at the bottom.

Both the temperature (outside) and all of the selections under the windchill, humidex, etc. gauge have wrong scale readings for the gauge "needle". The digital readout on both gauges? is correct, as is the scale on the indoor temperature gauge.

Any ideas?

Thanks, Steve

[vince]

On Friday, June 26, 2015 at 10:23:05 AM UTC-7, Steve2Q wrote:

Both the temperature (outside) and all of the selections under the windchill, humidex, etc. gauge have wrong scale readings for the gauge "needle". The digital readout on both gauges? is correct, as is the scale on the indoor temperature gauge.

Any ideas?

Hard to say without seeing your page source - isn't there minValue, maxValue setting you need to provide in your weewx templates ? It's been a while, but there are a zillion settings in the sources at https://github.com/HanSolo/SteelSeries-Canvas/blob/master/steelseries.js if this is the version of Steel Gauges you're using.

Also, you spelled 'Gauges' wrong on your weewx skin pages :-)
 

[Radoslav Drdla]

I do not know for you, but my gauges is a bad figure at cloud base. When they switch from meters to feet and back, showing badly, but after updating the page's OK.
Perhaps there is an error in java script.

Dne pátek 26. června 2015 20:21:30 UTC+2 vince napsal(a):

[vince]

I might add that I don't use Steel Gauges - too slow (for me).

I use a variant from https://github.com/Mikhus/canv-gauge that seems much faster on my systems, and is very easy to set up.   Examples at http://www.skahan.net/weewx/ - the colored shades are the borders of my $alltime high/low for that measurement, the white borders on the inside are the $week high and low ranges.

[Steve2Q]

Vince: the min and max values appear OK in the template; and the indoor temperature scale corresponds to these values; not the outdoor. I checked the steelseries.js file and it is newer than my gauges.js file, but it appears completely different so I don't think I can use it.

Since my update interval is two minutes, I don't have a problem with the Steel Gauges being too slow. I do wish that they worked real time like my old  Windows Virtual Weather Station program.

Thanks for pointed out my speling missteak! :) For some strange reason "gauges" seems to be one of the few words I consistently misspell. 

Radoslav: I have tried multiple times to update my page thinking that was the problem, but it didn't work.

Steve

[gjr80]

Hmm, somewhat bizarre... I cast the mark 1 eyeball over your gauge-data.txt and it looked fine to me. Nonetheless I downloaded a copy, put it on my server in place of my (working) gauge-data.txt and I get the exact same symptoms.... Would indicate the issue is in the data. Best, get the mark 2 eyeball I think...

Gary

[gjr80]

Aha, it does not like having wchillTL left blank (though it seems fine with "wchill" being blank). If I put "0" in for "wchillTL" the gauges come up fine (as an aside I can sort of see the logic as ss gauges autoscales based on day high/lows, though it appears the autoscaling may not be too tolerant of missing values). I see that your main site says wind chill is undefined as temp > 50 or V (wind speed) < 3. I guess this (the ss gauges problem) is an unintended consequence of setting windchill to None when it is outside the parameter bounds for which it is valid; if windchill would have tracked outTemp as per weewx out of the box all would be fine. There appears to be no simple way to 'turn off' the windchill gauge when windchill is not valid so I think the easiest solution will be to modify the gauge-data.txt.tmpl to output "0" (or some other numeric when wchillTL would other wise be None (or N/A)) and accept that the windchill gauge will still have a reading albeit invalid. A possible change to gauge-data.txt.tmpl could be: 

replace
         

"wchillTL":"$day.windchill.min.raw",

with

#if $day.windchill.min.raw is None
          "wchillTL":"0",
#else
          "wchillTL":"$day.windchill.min.raw",
#end if

Note, above code is untested, I don't use this template nor do I set windchill to None when it is 'out of bounds'

Gary

[Steve2Q]

Gary..that is freaking brilliant! Your code made the range on the gauges correct!  Thank you very much.

Now, (realizing I know very little about python or any other languages) since I see you have made the correction using "if, then, else"  type of syntax, do you think it possible for me to code in something that will make the gauge somehow yield an "out of range" indication if windchill and heat index do not follow the equations that define them? I did the coding myself for that on the "basic" Weewx home page.

Steve

ps: I generally like to put comments in when I change something in case I want to change it back. It appears that the # is not used in gauge.data.html.tmpl as a comment marker; what else can I use?

[Thomas Keffer]

On Fri, Jun 26, 2015 at 5:03 PM, Steve2Q <ste...@gmail.com> wrote:

ps: I generally like to put comments in when I change something in case I want to change it back. It appears that the # is not used in gauge.data.html.tmpl as a comment marker; what else can I use?

​##

-tk​

 

[Steve Meltz]

Thanks, Tom!

[gjr80]

Steve,

easy one first; I am big on comments too, sometimes too much so. Double hash ## will comment a single line in a .tmpl eg

## this code handles windchill==None

#* and *# can be used for multi line comments eg

#*
The following code handles windchill == 0
Don't forget to add it to future updates
*#

As for an 'out of range' indication, I am not sure it will be too easy. The issue is that weewx is the holder of the 'windchill is out of range info' and the steelseries javascript is the code that controls the gauges. I am not sure if the steelseries gauages even support an out of range type indicator. About the limit I have seen is the ability to turn on or off gauges via gauges.js but that is a config setting not a dynamic control, plus it does not appear to be available for the windchill gauge).

Gary

[Steve Meltz]

Thanks, Gary.  Yes, I see your point about the problems having the gauges show out of range readings.  Maybe a way  to turn off the corresponding "button" under the gauge would be something to investigate. Of course  this is just an interesting academic exercise.

Steve

[Steve2Q]

This is a VERY old thread, but I bumped it back up because I ran into a problem. I have been trying to track down what may be a memory leak, and in doing so I started from scratch with a new installation on a new RPi. After a couple of days, the memory use leveled off, so I started to re-install some extensions with the first being Steel Gauges. It went Ok, but then I ran into an old problem. Look at the page here:  http://photokinetics.org/Weather/ss/

You can see that the two temp gauges are wonky. The indoor temp displays properly when selected, but that is it it. I went back to Gary's suggestion of 6/26/16, but that did not seem to work this time. One thing I noticed is a difference where "wchillTL":"$day.windchill.min.raw"   instead reads "WchillTL":$day.windchill.min.formatted"




So,I just used his suggested code change replacing the word raw with formatted, but that was a no go.




I shudder to think what will happen when this gets sorted out and I install RTG.!!




Steve

[gjr80]

Steve,

Your post highlights two issues; the temperature gauge and windchill. When I look at your site just now the temperature gauge is displaying 27.1C for both inside and outside temperature. Other than both obs being the same value I see nothing unusual. Changing between inside and outside works fine. If I look at your gauge-data.txt temp and intemp are both 27.1. The mouse over plots look ok and appear consistent with the gauge displays at the moment. Have I missed something obvious, or is the a different meaning to 'wonky' over your way :)

Wind chill wise your gauge-data.txt is showing N/A for windchill and the gauges are displaying that as -20C. So the issue is with the windchill value in gauge-data.txt. The use of .raw or .formatted is of no consequence, .raw will display windchill with a whole lot of decimal places, .formatted will format windchill as per skin.conf/weewx.conf (typically 1 decimal place) without a unit label. If I look at your main page I see windchill is 'Undefined: T>50 F or V<=3 mph' (would seem to tie in with N/A in gauge-data.txt) so I suspect the SteelSeries Gauges extension is not the issue. I am guessing the narrative about T and V is just some formatting you have added to index.html.tmpl or is there something else you have changed re windchill?

Gary

[Steve Meltz]

Gary..if you switch to Fahrenheit, look at the scale on the gauges:

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/BNTMCfeC30E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gjr80]

Ok, I see. Simple solution is to just display C, but I am guessing that is not a practical solution for you :)

Seriously, I believe the issue is due to the absence of numeric values for windchill and heatindex. I would have to look at the auto scale routines in the SteelSeries Gauges code but I suspect lack of windchill and heatindex messes up the temperature auto scale calculations when changing units. I guess that takes us back to my second point from my last post; have you made any changes to how windchill and heatindex are stored? The default weeWX approach is to track outTemp when the temperature and wind conditions are not met.

Gary

[Steve2Q]

Gary, I changed wxformulas.py as follows:

For windchill and heat index (in Fahrenheit of course!), I changed both   Return T   and    Return t_f   to   Return None. I did this before getting involved with Steel Gauges to prevent out of range values from being plotted in the charts. I am still investigating what happened in the re-installation. I did a backup of /weewks/skins before doing it, so I don't know why it didn't stick.

Steve

[Steve2Q]

I should add that while the windrun "odometer" is working, there is no graphic on the windrose gauge.

[gjr80]

A few more thoughts. There are two publicly available ways of generating gauge-data.txt that I know of; the SteelSeries Gauges extension which produces a gauge-data.txt on each report cycle and my realtime gauge data (RTGD) extension that produces a loop based gauge-data.txt. I cannot recall, but it is possible that the RTGD extension handles obs with None values differently to the SteelSeries Gauges extension. I do remember you mentioning making changes to have weeWX emit None for windchill and heatindex rather than track outTemp when the pre-conditions are not met. Is it possible you made this change after installing RTGD? That could explain why your gauges did not show this behaviour just before your re-install. To delve any deeper I will need to look into the code, I am travelling at the moment but will have a look later this week when I am home. At the end of the day both extensions should handle None values in such a manner that it does not adversely impact the gauge displays.

The lack of windrose data is expected; the SteelSeries Gauges extension has never populated the windrose field nor does it provide the forecast text in the scroller. You need RTGD for both of these features.

Gary

[Steve2Q]

Gary..I did make the change to wxformulas.py bfore installing Steel Gauges or RTG. What i am going to do is uninstall SG then reinstall the newest version followed by RTG. Ill let you know what happens.

Steve

[Steve2Q]

Hi Gary..when it is convenient for you (I'm sure you have a real life!!), I am still flummoxed (bushed?)! I did several uninstall/re-install cycles of Steel Gauges and Rtgd. Right now I am back to just having SG version 2.6.3 with no changes to any of the files. You can see what this looks like on my site. I am sure you know that there is version 2.7.1 of SG available here:  https://github.com/mcrossley/SteelSeries-Weather-Gauges

I tried installing this newer version (I did it manually as there is no extension available) but it was no different. I don't know if Rtgd doesn't play well with it.

I have even gone back and looked at my backups, and when I changed things in gauges.js  to correspond it made no difference other than at one point giving me no gauges at all.

One observation: is it a normal part of the installation of 2.6.3 as an extension to have the /ss in two places? It is under /weewx/skins   and    weewx/public_html

Thanks, Steve

[gjr80]

Hi Steve,

Ah, the penny has just dropped. Can you uninstall rtgd. Now that I think back I saw an issue like this sometime ago (not sure if it was you) and I seem to remember the constant rescaling/redrawing of gauges was due to both the SteelSeries extension and rtgd producing gauge-data.txt thus confusing the SteelSeries Gauges. In any case I have sat here this morning on a VM and the SteelSeries Gauges handle None values for windchill etc quite OK, so I don't think that is the problem. In any case let's take rtgd out of the equation, get the SteelSeries Gauges working OK and then move to rtgd.

Gary

[Steve2Q]

Hi Gary. Here is what I did. Uninstalled rtgd using wee_extension. Then did the same with steelseries-2.6.3. Stopped/start Weewx.  I then went through /weewx looking for any folders; I found and removed weewx/skins/ss and weewx/public_html/ss. I also removed any directories from my web server. I then reinstalled steelseries-2.6.3, and that is where I am right now...no changes made to any files at this point. One thing is the two /ss folders; one under /skins and the other under /public_html. There is only on gauge-data.txt file and that is in /public_html/ss

Awaiting further instructions!!

Steve

[gjr80]

Ok, I can see the same problem still exists so it would seem it is with the extension and not rtgd. I can access your gauge-data.txt and gauges.js so I should be able to track down the failure mechanism and hopefully the root cause. Will get back to you tomorrow your time.

Gary

[Steve Meltz]

Thank you Gary..this should not be at the top of your to do list...

--

[gjr80]

Steve,

Sat down with your gauge-data.txt and a VM and was able to reproduce your issue. I was right in as much as it is the N/A entries in gauge-data.txt that cause the bad behaviour of the gauges, but rather than the windchill and heatindex etc values (fields wchill and heatindex in gauge-data.txt) being the problem it is having N/A in the daily extremes (fields TwchillL and TheatindexL) that was the cause. The scaling routine takes note of the daily extremes and a value of N/A causes the incorrect scaling.

rtgd does things slightly differently, rtgd will not put N/A in any observation/aggregate field, if an observation is None rtgd will use 0 rather than 'N/A'. So that is why your gauges were previously working, you were using rtgd and it is immune from the issue.

So what of a way ahead? I suggest that you disable (rather than uninstall) the SteelSeries Gauges extension and install rtgd:

1. edit weewx.conf, locate [[SteelSeries]] under [StdReport] and comment out [[SteelSeries]] and all its subordinate settings

2. do a config reload or restart weeWX and confirm that gauge-data.txt is no longer being produced

3. delete gauge-data.txt from your weeWX machine and web server. On your weeWX machine gauge-data.txt will be in public_html/ss, on your web server in will be in the Weather/ss directory relative to your web root directory. This is important, we don't want to be chasing our tails with multiple gauge-data.txt files in existence.

4. install rtgd and confirm that a loop based gauge-gauge-data.txt onto your web server, because it is loop based we can't use the normal weeWX FTP/rsync mechanism. Chances are your previous rtgd install used HTPP POST to transfer the file, if you copied over your old [RealtimeGaugeData] config settings this will likely already be setup correctly. The way to check is to see if gauge-data.txt in being regularly updated on your web server, if it is all should be good, if not let me know.

I will look into getting the gauge-data.txt template used by the SteelSeries Gauges extension changed so that it can appropriately handle None values.

Gary

[Steve2Q]

Gary..I followed your steps 1 through 4. I have not yet  uncomment the [[SteelSeries]] section of weewx.conf

I now have (on the Weewx machine) gauge_data.txt under /weewx/public_htm

gauge-data.txt is on the web server under /Weather and is being updated on my 2 minute archive period.  I cannot find a any real time gauge data config settings.

Steve

[gjr80]

Steve,

I should have read all of this old thread, the answer to the wild gauge scaling issue was at this post. Thought I had a sense of déjà vu.

On Thursday, 25 October 2018 01:47:15 UTC+10, Steve2Q wrote:

Gary..I followed your steps 1 through 4. I have not yet  uncomment the [[SteelSeries]] section of weewx.conf

Not quite sure what you mean here, you say you have not yet uncommented the [[SteelSeries]] section but step 1 asked you to comment out the section? No matter, when I look at your site I notice that gauge-data.txt is not in Weather/ss. That is what we want so I guess you did comment out or otherwise disable the [[SteelSeries]] section.

 

I now have (on the Weewx machine) gauge_data.txt under /weewx/public_htm

 

gauge-data.txt is on the web server under /Weather and is being updated on my 2 minute archive period.

This gauge-data.txt is being produced by rtgd and as you say is being updated every 2 minutes - something to come back to later but rtgd should be producing gauge-data.txt on every loop packet (though you can slow it down) but yours appears to be produced every archive period - we can come back to this later. Bottom line is we have the rtgd produced gauge-data.txt making its way to your web server, that is what we want. We just need to make a change to gauges.js to point to this gauge-data.txt and all should be good. To point gauges.js to the rtgd produced gauge-data.txt:

1. on your web server edit Weather/ss/scripts/gauges.js

2. locate the following line (circa line 62) :

realTimeUrlWeewx : 'gauge-data.txt', // *** WeeWX Users: Change to your location of the gauge data file ***

and change it to:

realTimeUrlWeewx : '../gauge-data.txt', // *** WeeWX Users: Change to your location of the gauge data file ***

3. save gauges.js
4. refresh your gauges page in your browser

I cannot find a any real time gauge data config settings.

Have a look in weewx.conf, you should find a stanza similar to the following (it usually ends up at the bottom of the file):

[RealtimeGaugeData]
    date_format = %Y.%m.%d %H:%M
    rtgd_path = /home/weewx/public_html
    rtgd_file_name = gauge-data.txt
    remote_server_url = http://remote/address
    timeout = 1
    response_text = success
    [[StringFormats]]
        degree_C = %.1f
        degree_F = %.1f
        degree_compass = %.0f
        foot = %.0f
        hPa = %.1f
        inHg = %.2f
        inch = %.2f
        inch_per_hour = %.2f
        km_per_hour = %.1f
        km = %.1f
        mbar = %.1f
        meter = %.0f
        meter_per_second = %.1f
        mile = %.1f
        mile_per_hour = %.1f
        mm = %.1f
        mm_per_hour = %.1f
        percent = %.0f
        uv_index = %.1f
        watt_per_meter_squared = %.0f
    [[Groups]]
        group_altitude = foot
        group_pressure = hPa
        group_rain = mm
        group_speed = km_per_hour
        group_temperature = degree_C
    [[WU]]
        enable = false
        api_key = XXXXXXXXXXXXXXXXXXX
        location = XXXXXXXXXXXXX

Gary

[Steve2Q]

Gary..its working!. Thanks! I think part of the problem was that I made the weewx url change in gauges.js on the local weewx machine rather than on the webserver. I changed the update time to two seconds, but i need some wind to tell if it is working. My WUnderground API still appears to bw working but its showing C rather than F.
Will work on that later today..its 18 after midnight here.

[Steve2Q]

Progress is being made. I now have the units  F and MPH rather than C and KmPH in the Wunderground scroll bar. The background charts were not updating, but I got that going. Now the only things left are: 1. Gauges are only updating at my archive interval of 2 minutes instead of my 2 second loop interval, 2. The windchill and heat index buttons aren't' working the way they did before (but this is not very important), and 3. I want to do modify some of the appearance, but I will get to that in the future.

Now, I will watch cmon for the memory usage (remember, that was my original problem!), and see if it levels off.

Steve

[gjr80]

Steve,

A few thoughts on some of your remaining gauges issues:

1. Gauges are only updating at my archive interval of 2 minutes instead of my 2 second loop interval,

This could be a case of gauge-data.txt being generated every loop packet but only being uploaded to your web server every archive period. You can tell what is happening by observing gauge-data.txt on your weeWX machine (not the web server). If it is being generated every 2 seconds then the issue is one of uploading to the web server, if the file is only generated every archive period then the issue is within rtgd. I'm inclined to think it is the former.

2. The windchill and heat index buttons aren't' working the way they did before (but this is not very important), and

Can you elaborate on this? Do you mean the value displayed on the gauges when windchill or heatindex is None? If so the gauges will display 0 in the corresponding METRIC units for the observation shown on the gauge, ie 0C for anything that is a 'temperature'. So when displaying F this will be 32. This has been the behaviours since v0.1.2 in January 2017. Of course if you mean something else....

Gary

[Steve Meltz]

I just checked the weeWX machine, and gauge-data.txt is updating every 2 seconds. As for the windchill and heat index, The windchill used to read 0 when either calculation was not met. It now reads 32 F as you said. I think (and this is from a previous post from you) the behavior may be different now as I made the change to wxformulas before installing the gauges. Previouslys, I may have made that change after the installation, but who remembers? It is fine the way it is. Just have to get the 2 second loops working again.

Steve

--

[gjr80]

Ok, easy fix for the windchill/heatindex gauge display. I oversimplified the default values in my previous post. You can specify what units are used in gauge-data.txt, this is somewhat superfluous as the SteelSeries Gauges have radio buttons on the page to select the display units so in that regard it really does not matter what units are used. There are a few hidden effects though. The units used in gauge-data.txt are what a new user will see when they first open your gauges page, once a user has been to the page (I think) a cookie is saved with their display units settings, thus when they next visit the page the same display units are used. When I said a value of 0 is used when an obs is None, the units used for that 0 are whatever units are being used in your gauge-data.txt but it is then displayed in the display units. Confused? I have made the default units weeWX METRIC, you can override this though. In weewx.conf locate the [RealtimeGaugeData] stanza and set the [[Groups]] as required, something like following will probably suit:

[RealtimeGaugeData]
    ...
    [[Groups]]
        group_altitude = foot
        group_pressure = inHg
        group_rain = inch
        group_speed = mile_per_hour
        group_temperature = degree_F

Regarding the 2 minute/ second updates. rtgd is generating as it should, this issue is with the uploading. I don't know how this was done on your install before, there should be clues in your [RealtimeGaugeData] stanza from your old install - do you still have a copy of your old weewx.conf? if so can you post the [RealtimeGaugeData] stanza, removing an sensitive info, API keys etc that may be in there.

Gary

[Steve2Q]

Gary..here is the [RealTimeGaugeData] Stanza from an old weewx.conf file: I will add that the first three lines were not in my present weewx.conf, so I added them but it still is not doing the loop updates.

[RealtimeGaugeData]
    remote_server_url = http://photokinetics.org/Weather/post_gauge-data.php
    timeout = 2
    response_text = success

    date_format = %Y.%m.%d %H:%M
    rtgd_path = /home/weewx/public_html

       [[StringFormats]]
        inch_per_hour = %.2f
        mile_per_hour = %.1f
        degree_compass = %.0f
        km_per_hour = %.1f
        inHg = %.2f
        mm = %.1f
        meter_per_second = %.1f
        percent = %.0f
        km = %.1f
        uv_index = %.1f
        inch = %.2f
        degree_F = %.1f
        meter = %.0f
        degree_C = %.1f
        mile = %.1f

        foot = %.0f
        hPa = %.1f

        mbar = %.1f
        watt_per_meter_squared = %.0f
        mm_per_hour = %.1f
    [[WU]]
        api_key = xxxxxxxxxxxxxxxxxx
        enable = true
        location =xxxxxx
        units = us
    [[Groups]]
        group_altitude = foot

[gjr80]

Yep, those 3 lines are necessary for http post to work. You don't seem to to have the file post_gauge-data.php on your web server - this file accepts the http post and saves the loop based gauge-data.txt to your web server. You can download it from the rtgd releases page. It should be a simple case of copying it to the Weather directory on your web server.

Gary

[Steve Meltz]

I uploaded the .php file to the web server. Since this afternoon, it now appears that the background images stopped uploading to the web server at 2:15 pm..and I thought it was corrected. I can only find .png files that were uploaded to that time. I will wait till tomorrow morning to see if adding the .php file has worked for the loops..then try to find where the images are.

Steve

--

[gjr80]

I can see gauge-data.txt is now being uploaded every loop packet but the realTimeUrlWeewx setting in gauges.js has reverted to an old value and consequently the gauges page can't find gauge-data.txt.

Gary

[Steve2Q]

Gary...the following two lines in gauges.js have me very confused:

 imgPathURL         : '',          // *** Change this to the relative path for your 'Trend' graph images

realTimeUrlWeewx   : '../gauges/gauge-data.txt',         // *** WeeWX Users: Change to your location of the gauge data file ***

I assume that the "Trend graph images" are those you can see if you hover over a gauge? If so those are the ones that have not been updating and on the web server the last ones are in   /Weather/ss

Regarding the second line '../gauges/gauge-data.txt  there is no /gauges directory on the web server or the weeWx machine.

Does the gauges.js file on the webserver change to whatever the .js file is on the weewx machine every time weeWx is stopped and restarted?

[Steve2Q]

ok..found the error in the realTimeUrlWeewx line..so now the gauges appear to be functioning. Graphs are still stopped at 214 pm, and I wont' know until I get some wind if the gauges are looping or still on the archive interval.

Steve

[gjr80]

First up let's deal with the changing gauges.js.

The rtgd extension generates a loop based gauges-data.txt and optionally uploads this to your web server. rtgd knows nothing about gauges.js.

The SteelSeries Gauges extension generates an archive based gauge-data.txt plus it copies all of the SteelSeries gauges javascript/css etc (this includes a default gauges.js) required to render the gauges. The copying of the SteelSeries gauges javascript/css is done as a 'copy once' which means it is copied once on weeWX startup only (have a look in skins/ss/skin.conf under [CopyGenerator]). Assuming you have and upload report (FTP or rsync) uploading files to your web server then the SteelSeries Gauges extension generated gauges-data.txt is uploaded each archive period. Similarly the javascript/css is uploaded once on weeWX start up and then they are not uploaed again. So this is why it can be dangerous to edit gauges.js on your web server, if the SteelSeries Gauges extension is left active then gauges.js will be overwritten on the web server the next time weeWX is started. There are a number of solutions (1) make your changes to gauges.js in the skins/ss/scripts directory and then restart weeWX or (2) disable the SteelSeries gauges extension and make your changes to gauges.js on the web server.

I cannot explain where

realTimeUrlWeewx   : '../gauges/gauge-data.txt',       // *** WeeWX Users: Change to your location of the gauge data file ***

came from, it should be

realTimeUrlWeewx   : '../gauge-data.txt',     // *** WeeWX Users: Change to your location of the gauge data file ***

as far as I can tell. If you have disabled the SteelSeries Gauges extension then you can safely edit gauges.js on your web server.

Gary

[gjr80]

Easy to tell, just open http://www.photokinetics.org/Weather/gauge-data.txt and refresh the page a few times while observing the timeUTC value, you will see the seconds ticking over if it is loop.

Gary

[Steve2Q]

The timeUTC is changing so the loops are working. Now to find why the background graphs stopped. Is that a problem in the line

 imgPathURL         : '',          // *** Change this to the relative path for your 'Trend' graph images 

should '', be changed to '/ss/',  or something like that? And now I understand why my changes to gauges.js weren't' sticking.

Steve

[gjr80]

Thinking just now I suspect this is because we disabled the SteelSeries Gauges extension. Am out for the rest of the day so going to have to leave this for now. Have a long train ride so plenty of time to give it some more thought and post a solution, probably a tomorrow job for you though :)

Gary

[Steve Meltz]

No worries! Have a pleasant journey wherever you are heading. I'll be in  and out all weekend..I'm busier now that i am retired than when I was working.

[gjr80]

Likewise since I retired, and the best thing is most things I do now are fun. Astronomy club meeting in the city tonite.

Anyway, back to the gauges. I was mistaken in thinking we could disable the whole SteelSeries Gauges extension, we need to keep the image generator going to produce the plots. To do this:

1. Edit skins/ss/skin.conf and locate the following lines:

[Generators]
generator_list = weewx.reportengine.CopyGenerator, weewx.cheetahgenerator.CheetahGenerator, weewx.imagegenerator.ImageGenerator

And change it to read

[Generators]
generator_list = weewx.imagegenerator.ImageGenerator

This disables everything in the SteelSeries Gauges extension except for the ImageGenerator that generates the plots

2. Edit weewx.conf and remove the comments against [StdReport] [[SteelSeries]], this will re-enable the SteelSeries Gauges extension but this time only the ImageGenerator will be run.

3. Restart WeeWX or do a config reload.

The plots should be produced on the next report cycle and uploaded to the web server. Provided they are going to the right directory and he SteelSeries Gauges is looking in the right place for them it should work.

I really should package rtgd with a skin to produce the images and copy over the SteelSeries Gauges javascript/CSS just as the SteelSeries Extension does, this really should be a heck of a lot easier than it is at the moment. I have resisted doing this in the past but I think I don't have much choice now.

Gary

[Steve2Q]

Hi Gary.

The gauge 2 second loops are working perfectly now.

I did the changes, however that started throwing errors (I always watch syslog for a bit to see if anything obvious happens).

Attached is syslog. Once I saw the errors I did the following: Put the comments back in weewx.conf in[StandartReport][[SteelGauges]], and changed to debug = 1. I left in the change you recommended in skins/ss/skin.conf. I restarted weewx at 9:11 and let in run until 9:43.

Next I uncommented the [[SteelGauges]] section in weewx.conf, and restarted at 9:45. I only let in run for a few minutes because weewx would not start. I then recommented [[SteelGauges]], set debug = 0, and that is where I am now.

Besides the "parsing" error at 9:45, I find the "unrecoverable exception" at 9:17:13 of interest (and you can see it occurred earlier before I made ANY of the changes like at 6:43.

Steve

Seems like we have some other common interests. Astronomy is also one of mine.

Steve

[gjr80]

They just keep coming don't they!

What is happening with the FtpGenerator error is that when rtgd creates gauge-data.txt it actually builds the file in gauge-data.txt.tmp and once the file is complete it is copied to gauge-data.txt. This is known as an atomic write and is done to lessen the chance that gauge-data.txt is open for writing (by rtgd) and thus unavailable for access by other processes. The .tmp file is created in the same directory as gauge-data.txt. When FtpGenerator kicks off it gathers the details of the files it is to upload and then works its way through uploading each in turn (so it could be some seconds after gathering the list that the file is uploaded), if the .tmp file exists when the FtpGenerator gathers its list of files it is included for upload but if the .tmp file is subsequently removed you get the FtpGenerator error you are seeing. If you like, the holes in the swiss cheese are aligning to cause the error, the more frequent gauge-data.txt is produced and the more frequent the FtpGenerator is run the more chance of the holes aligning and the error occurring.

The long term fix is for me to change rtgd to create the .tmp file somewhere that is unlikely to be uploaded by the FtpGenerator. You can work around the issue by changing the location in which that gauge-data.txt is created. Edit weewx.conf and under [RealtimeGaugeData] comment out the rtgd_path setting (it will then use the default of /var/tmp) or change it to something else not used by weeWX. Save weewx.conf and restart weeWX or do a config reload. If you are transferring the rtgd generated gauge-data.txt to a remote server the location of gauge-data.txt is not important, it's location is only important if using the file on the weeWX machine (eg your weeWX machine is also your web server) but in such cases chances are you are not uploading via FTP.

Gary

PS. I'll drop you an email sometime re astronomy to hear what you are up to.

[gjr80]

PPS. You should then be able to redo the changes to the ss/skin.conf so that the mouseover plots are generated and upload by FTP.

Gary

[Steve2Q]

Good Morning, Gary. I implemented your changes from last night, and with the exception of gauge-data.txt now in /var, there is no other change. Here are two observations from today:

1. With debug = 1 there is no record of any of the charts (such as dayinouttemp.png) being uploaded to any location on the web server. The only .png files that are there are those from October 25 located in Weather/ss.

2. This has nothing to do with the aforementioned files, but I made some changes in gauges.js to try and change the colors on the gauges. I shut down weewx, made the changes on the weewx machine then restarted weewx. From your previous note, I expected gauges,js to change on the web server, but this did not happen. Do I have to manually upload the .js file while weewx is turned off? I thought the copy once would take care of this on a restart.

Steve

[gjr80]

Gday Steve,

some comments below

Gary

On Sunday, 28 October 2018 00:18:16 UTC+10, Steve2Q wrote:

Good Morning, Gary. I implemented your changes from last night, and with the exception of gauge-data.txt now in /var, there is no other change. Here are two observations from today:

1. With debug = 1 there is no record of any of the charts (such as dayinouttemp.png) being uploaded to any location on the web server. The only .png files that are there are those from October 25 located in Weather/ss.

First we need to determine if weeWX is generating the charts each report cycle, they should be in public_html/ss. If they are not being generated each report cycle then we need to (1) check weewx.conf [StdReport] to make sure the [[SteelSeries]] stanza is fully enabled (ie not commented out) and (2) check the SteelSeries skin.conf to make sure the ImageGenerator is enabled in the generator_list setting under [Generators]. If you have no luck post a log extract covering at least one full report cycle with debug=1. If they are being generated each report cycle then we need to look at why the FtpGenerator is not uploading them.

 

2. This has nothing to do with the aforementioned files, but I made some changes in gauges.js to try and change the colors on the gauges. I shut down weewx, made the changes on the weewx machine then restarted weewx. From your previous note, I expected gauges,js to change on the web server, but this did not happen. Do I have to manually upload the .js file while weewx is turned off? I thought the copy once would take care of this on a restart.

The copying of gauges.js (and for that matter any SteelSeries .js or .css) is controlled by the CopyGenerator in the SteelSeries skin. Earlier I advised you to disable the CopyGenerator and CheetahGenerator in the SteelSeries skin.conf. This has the effect of stopping the SteelSeries skin generating gauge-data.txt and copying the .js and .css files on weeWX startup but allows the ImageGenerator to continue to generate the charts. The net effect of this is that you now need to edit gauges.js on your web server rather than on weeWX because it is no longer copied on weeWX start. Alternatively, you can re-enable CopyGenerator in the generator_list setting in skin.conf (just disable CheetahGenerator) and now you will need to edit gauges.js on your weeWX machine and restart weeWX for gauges.js on your web server to be updated. My apologies I probably did not make this very clear when I advised you to disable CopyGenerator.

[Steve2Q]

Just wanted to thank Gary for all of his help. Had to take the thread offline and through regular email as I could not send an attachment. Turned out that after setting everything up, there were a few typos that were finally found and corrected. SteelGauges with real time (2 second) updating are now working great.

Thanks again..

Steve