Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Devonian]

I have just invested in a Davis Vantage Pro2, which replaced my WS2300 and have installed Weewx 3.6.2 on Debian ver8 replacing my previous weewx ver 2.7 for the WS2300.

I would like to get the Steel Series gauges performing real time updates at the Davis loop interval of 2.5 seconds.

I have them installed OK, but it uses my current archive interval of 5 minutes - not quite real time!

I tried mesowx, but can't get the data to display - the page appears, but no graphs.  Data is getting saved into my MySQL 'raw' database at regular 2.5 second loop intervals.  I'll continue trying to figure this one out.

So, my thoughts turned to using the raw database for Steel Series and to use raw data instead of archive data.

I'm primarily interested in wind speed/direction, so if I could only get that to update @ 2.5 seconds, I'd be happy with the others at 5 minutes.

Anyone got any ideas on how to use this raw data instead of archive?

Maybe there's a better/simpler way to achieve this 2.5 second update?

Regards,

Nigel.

[gjr80]

Nigel,

I think a more elegant solution is to create a custom Service, bound to NEW_LOOP_PACKET event, that creates the JSON file used by the SteelSeries gauges after every loop packet arrives. I wrote such a service a couple of years back to produce customclientraw.txt on every x'th loop packet, put it away though when tracking down some issues and never got back to it. At the time the SteelSeries gauges did not directly support weewx, now that weewx is supported it would be a simple matter to rework the service to produce gauge-data.txt - its much the same data as customclientraw.txt and still JSON format. The only real issue is to what depth do you to populate the data file, for example, to get the current wind speed is trivial, getting todays max wind speed requires a little more effort, the windrose data a little more complex again and "the 'lowest' clockwise bearing in the last 10 minutes rounded down to nearest 10 degrees" is getting right up there.

Give me a few days to see what I can resurrect.

Gary

[Devonian]

Hi Gary,

That sounds like a perfect solution.

I did have Steel Series running since 2013-ish, when the first incarnations with weewx got going and it has worked well ever since on my WS2300 (albeit with 1 minute update).

I'm not too bothered about the wind rose, although it would be nice ;-)

I also have the Davis Solar and UV sensors, so for me, it would be great to have those included in the 2.5 sec update.

I am no software guru by any stretch of the imagination, but if I can be of any help, let me know.

Appreciate the help - have a virtual beer on me <cheers>

Nigel.

[Devonian]

Hi Gary,

Any luck on your 'custom' service?

Nigel.

[gjr80]

Hi Nigel,

Yes, I have all the important bits working it was updating the SteelSeries gauges on a VM just fine. Just want to get some forecast text from the Zambretti forecaster if its installed and then package it up. That's where I was on Friday when a couple of other things came up. Should be able to get the rest dorted today or tomorrow.

Gary

[Devonian]

Hi Gary,

Today for you is tomorrow for me ;-)

Thanks, really appreciate the effort.

g'night (or is that g'day?!)

Nigel

[Dan'l B]

Gary,

Any chance you could use the NWS or WU current forecast for the tickertape/scroller in place of the Zambretti?

An example is here, though it is accomplished using php.

[gjr80]

Any chance you could use the NWS or WU current forecast for the tickertape/scroller in place of the Zambretti?

At the moment all I can do is pull the Zambretti forecast from the forecast database (provided the forecast extension is installed), unfortunately the WU and NWS forecast text is not saved in the forecast database. I have had the WU forecast text being pulled in through weewx-WD but that is something for the next version of weewx-WD and that is going to be weeks away (at least).

I might have a chat with Matthew and see what he may be prepared to do, though I know he has a lot on at present.

Gary

[tempus]

Has there been more progress on your new custom Service bound to the NEW_LOOP_PACKET event?  It would be great to have even a partially-functioning beta-version as a stop-gap solution.

Zambretti forecast data doesn't seem important, because those forecasts are so poor compared to forecasts readily available from multiple other sources as to reflect poorly on the likely reliability of everything being displayed.  Why not eliminate the Zambretti forecast and let users who want a forecast above the gauges include webpage code that will display a professional forecast obtained via the Forecast extension or other means?

Bob

[mwall]

On Monday, February 13, 2017 at 11:49:48 AM UTC-5, tempus wrote:

Has there been more progress on your new custom Service bound to the NEW_LOOP_PACKET event?  It would be great to have even a partially-functioning beta-version as a stop-gap solution.

bob,

you could install the crt extension (cumulus realtime), and set its binding to loop.  then install steel series and configure it to use the cumulus realtime file for its input.

https://github.com/weewx/weewx/wiki/crt

this would work if weewx and the web/php server are on the same host.

if they are on different hosts, then you'll need something to get the realtime.txt file from the weewx host to the web/php host each time the realtime.txt file changes.

unfortunately the ftp and rsync in weewx are designed to run as 'reports' on each archive interval, not on loop changes.

someone should write an rsync and an ftp service that can be bound to NEW_LOOP_PACKET.  it could use the same code used by the ftp/rsync reports, just wrapped in a StdService instead of report generator.

fwiw, a much cleaner way to do this would be to eliminate gauge-data.txt, realtime.txt, customraw.txt, and all of the php cruft.  just write a skin that uses the javascript gauges directly.

m

[Thomas Keffer]

someone should write an rsync and an ftp service that can be bound to NEW_LOOP_PACKET.  it could use the same code used by the ftp/rsync reports, just wrapped in a StdService instead of report generator.

​

The problem with this approach is that then you need some sort of lock for the FTP service, so it knows when the reporting thread is done.

Hence the decision to put the FTP and reporting in the same thread, run by the same generator.

But, maybe there's some other clever way around this. I couldn't come up with one...

I hate locks.

-tk​

[mwall]

On Monday, February 13, 2017 at 12:19:40 PM UTC-5, Tom Keffer wrote:

someone should write an rsync and an ftp service that can be bound to NEW_LOOP_PACKET.  it could use the same code used by the ftp/rsync reports, just wrapped in a StdService instead of report generator.

​

The problem with this approach is that then you need some sort of lock for the FTP service, so it knows when the reporting thread is done.

Hence the decision to put the FTP and reporting in the same thread, run by the same generator.

that makes sense.  and it works really well for reports.

but there is a need for a general approach to doing transfer/sync outside of the StdReport framework.

what if the ftp/rsync were a black box that any service could initiate?  for example, as soon as it finished its 'work', the crt extension could start an ftp/rsync process.  or a json or csv extension, as soon as they finish writing, could start an ftp/rsync process.

so the notion of a transfer/sync could be a feature that any service could easily implement, and there would be a standard 'transfer/sync-parameters' stanza analogous to database bindings.

(doing real-time feeds with mqtt, influx, emoncms, etc gets the job done but with a totally different approach)

m

[Thomas Keffer]

That could work. With this thinking, we could even do away with the report generator. Instead, image generation and file generation would be separate weewx services. Each would invoke its own FTP session when done. Because the set of generated files are disjoint, there would be no duplicated effort (although there could be multiple simultaneous FTP sessions).

I believe the module ftpupload is pretty standalone. There's nothing in there that depends on the report generator framework.

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[tempus]

Thanks for letting me know about that.

I have a Vantage Pro2 Plus interfaced to weewx 3.6.2 via a USB data-logger.  SteelSeries Weather Gauges 2.5.18 was already installed with the following 'gauges.js' settings:

  weatherProgram : 6,
  realTimeUrlWeewx : 'gauge-data.txt',

The gauges updated normally at five-minute intervals with that configuration.

After seeing your post I installed 'weewx-crt-0.18.tgz' and modified 'weewx.conf' to create a realtime.txt file in the /ss/ directory of a test website, like this:

[CumulusRealTime]
   filename = /var/www/www.domain.com/ss/realtime.txt
   unit_system = US
   binding = loop

When I restarted weewx a 'realtime.txt' file that appeared to contain valid data was being written to the /ss/ directory at about three second intervals, as expected.  That file can be remotely loaded in web browser, so the Apache web server obviously has read-access.

I then modified '/etc/weewx/skins/ss/scripts/gauges.js' by setting:

    weatherProgram : 0,
    realTimeUrlCumulus : 'realtime.txt',

and deleted gauges.js at the website, so it would be replaced by the modified version after weewx was restarted.

A few minutes after restart I first verified that the modified 'gauges.js' file had been copied to the website and then loaded the gauges webpage in a web browser.  The gauges displayed, but had no data. Temperatures were -20 degrees, Pressure was 990, and everything else was zero.  '/ss/realtime.txt' still existed and was still updating at about three-second intervals, but data in that file wasn't making it to the gauges.

The Apache access.log has '/ss/realtime.txt' successful access records at about three-second intervals whenever the gauges webpage is loaded in a web browser, so the file is being successfully accessed by webpage JavaScript code, but data in the file has no effect on any of the gauges.

Is the Cumulus-style 'realtime.txt' file produced by weewx-crt-0.18 known to be compatible with SteelSeries Weather Gauges 2.5.18?

Bob

On Monday, February 13, 2017 at 9:16:48 AM UTC-8, mwall wrote:

On Monday, February 13, 2017 at 11:49:48 AM UTC-5, tempus wrote:

Has there been more progress on your new custom Service bound to the NEW_LOOP_PACKET event?  It would be great to have even a partially-functioning beta-version as a stop-gap solution.

bob,

you could install the crt extension (cumulus realtime), and set its binding to loop.  then install steel series and configure it to use the cumulus realtime file for its input.

https://github.com/weewx/weewx/wiki/crt

this would work if weewx and the web/php server are on the same host....

[mwall]

On Tuesday, February 14, 2017 at 3:13:05 AM UTC-5, tempus wrote:

Thanks for letting me know about that.

I have a Vantage Pro2 Plus interfaced to weewx 3.6.2 via a USB data-logger.  SteelSeries Weather Gauges 2.5.18 was already installed with the following 'gauges.js' settings:

  weatherProgram : 6,
  realTimeUrlWeewx : 'gauge-data.txt',

The gauges updated normally at five-minute intervals with that configuration.

After seeing your post I installed 'weewx-crt-0.18.tgz' and modified 'weewx.conf' to create a realtime.txt file in the /ss/ directory of a test website, like this:

[CumulusRealTime]
   filename = /var/www/www.domain.com/ss/realtime.txt
   unit_system = US
   binding = loop

When I restarted weewx a 'realtime.txt' file that appeared to contain valid data was being written to the /ss/ directory at about three second intervals, as expected.  That file can be remotely loaded in web browser, so the Apache web server obviously has read-access.

I then modified '/etc/weewx/skins/ss/scripts/gauges.js' by setting:

    weatherProgram : 0,
    realTimeUrlCumulus : 'realtime.txt',

and deleted gauges.js at the website, so it would be replaced by the modified version after weewx was restarted.

A few minutes after restart I first verified that the modified 'gauges.js' file had been copied to the website and then loaded the gauges webpage in a web browser.  The gauges displayed, but had no data. Temperatures were -20 degrees, Pressure was 990, and everything else was zero.  '/ss/realtime.txt' still existed and was still updating at about three-second intervals, but data in that file wasn't making it to the gauges.

The Apache access.log has '/ss/realtime.txt' successful access records at about three-second intervals whenever the gauges webpage is loaded in a web browser, so the file is being successfully accessed by webpage JavaScript code, but data in the file has no effect on any of the gauges.

Is the Cumulus-style 'realtime.txt' file produced by weewx-crt-0.18 known to be compatible with SteelSeries Weather Gauges 2.5.18?

bob,

i misled you, but all is not lost.  the implementation got finished in my head, but not in the code :/

please try the attached crt-0.20rc1.py

just put it in place of your existing user/crt.py

you will need to add this to your weewx config:

[CumulusRealTime]
    ...
    realtimegauges_txt = /var/www/www.domain.com/ss/realtimegaugesT.txt

and in /etc/weewx/skins/ss/scripts/gauges.js reset the cumulus url to:

    realTimeUrlCumulus : 'realtimegaugesT.txt'

this implements many of the gauges fields, but not all of them.  the remaining ones can easily be added, but it was not clear to me whether that should be done using local running avg/min/max or repeated database queries.  you're welcome to hack on it until i have time to finish it up!

m

[mwall]

sorry, again.  please use crt-0.20rc2.py

[tempus]

Gosh - First mistake you ever made!!!

I will try the fix. Thanks for your quick response.

Bob

[Devonian]

I have been working with Gary (gjr80) - well, Gary has done all the work and I am beta testing.

We have a working real-time-gauge-data py file that creates a gauge-data.txt file on definable loop packets, upto every 2.5 seconds on a VP2.

Gary will no doubt update when he is happy to release it, in the meantime, mine is on test here (on 5 second updates, at every other loop)

http://www.nthead.co.uk/ss/index.html

Nigel.

[tempus]

 I like the wind direction indicator a lot, but wonder why the Pressure normal-range is red.

Bob

 

[tempus]

crt-0.20rc2.py has only been running a few minutes, but seems to work. Thanks for the fix..
 
Bob

[Devonian]

@Bob,

Maybe the gauge is angry or embarrassed ;-)

It's not polished yet and Gary will no doubt fix it up in due course as it's just cosmetics.

The wind direction colours are a little wrong as well as they progress from pale blue to red in a continuous colour change as opposed to reflecting the direction of predominant wind with variables either side, as you might expect.

Nigel.

 

[gjr80]

One of the challenges when driving the SteelSeries gauges is that there is a lot of information being conveyed by the gauges other than just the simple gauge value. In the case of the red faced gauge it was simply a case of a mis-constructed query that was returning incorrect pressL and pressH values. These contribute to part of the shading of the pressure gauge.

I had not noticed the linear shading of the wind direction gauge, I would expect to see something like that under the simulator but not in real life. I implemented a revised method of producing the windrose data, and whilst the windrose gauge is not being displayed, the windrose data may have an effect on the wind direction gauge. This one I will need to look at more closely.

Gary

[gjr80]

Quite some time ago when I produced a loop based clientraw.txt (for realtime update of the Saratoga dashboard). All was well whilst weeWX and my web server were on the same machine. About 18 months ago I moved weeWX to a new machine and I was left with no means of realtime transfer of clientraw.txt to my web server. I did create a loop based rsync service that rsync'ed clientraw.txt every loop period, the service essentially consisted of putting the the rsync code into its own service with a binding to NEW_LOOP_PACKET to fire the rsync. It was a little crude but worked, although some of its limitations came through when I created a loop based customclientraw.txt (superseded by gauge-data.txt) to drive the SteelSeries Gauges. I had intended to redo the my rsync service such that rsync ran in its own thread monitoring a queue for 'rsync jobs' and recently I had the impetous to finish it off. It seems to work well, any of the services that generate realtime files just place a file name in the queue and the rsync service takes care of it.Whilst running in a thread is a little more complex, performance is much better with little impact during the (substantial) report cycle on my weeWX machine.

Gary

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[tempus]

I left on a trip right after upgrading to 0.20 rc2 and the gauges had starting working.  Since arriving back last night gauge temperatures are -20 degrees, pressure is 990, and everything else is zero, like before the upgrade.  realtimegaugesT.txt is still updating at approximately 2.5 second intervals and the data looks valid, but it isn't getting to the gauges.

Any ideas?

-Bob
 

[tempus]

On Tuesday, February 14, 2017 at 7:30:53 AM UTC-8, Devonian wrote:

I noticed that the temperature gauge scaling is wrong if Fahrenheit is selected.

[tempus]

Gary, let me know if you would like an additional beta tester.

Bob

[tempus]

On Tuesday, February 14, 2017 at 3:34:29 PM UTC-8, gjr80 wrote:

One of the challenges when driving the SteelSeries gauges is that there is a lot of information being conveyed by the gauges other than just the simple gauge value. In the case of the red faced gauge it was simply a case of a mis-constructed query that was returning incorrect pressL and pressH values. These contribute to part of the shading of the pressure gauge.

I had not noticed the linear shading of the wind direction gauge, I would expect to see something like that under the simulator but not in real life. I implemented a revised method of producing the windrose data, and whilst the windrose gauge is not being displayed, the windrose data may have an effect on the wind direction gauge. This one I will need to look at more closely.

Gary

Gary, it is obvious from watching the gauges for a while that the linear shading of the wind direction gauge is due to the wind direction being falsely reported as North when the wind speed is zero. The shading could be fixed by simply leaving the direction indication unchanged whenever the wind speed is zero.

Bob

[Nigel Head]

Hadn't noticed that - 'wind chill' etc is the same when selecting Fahrenheit.

When selecting 'inside' for Fahrenheit temp, it scales fine.

Gary has fixed the 'red face' problem now.

Nigel.

--
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/f4qQyOJ1C-M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[gjr80]

Bob,

If you want to try the realtime gauge-gate.txt you can find it here:

https://github.com/gjr80/weewx-realtime_gauge-data

Extension package is under the releases tab, install instructions are in the readme.

Gary

[gjr80]

That F behaviour is somewhat bizarre, especially as indoor works. There is no difference in how indoor is produced compared to outdoor. I will have a look at that later today.

Not so convinced about the wind cause, still looking at that one.

Gary

[tempus]

Thanks. I will give it a try.

Bob

[tempus]

It is installed and running with the same F scaling problem.

Bob

[Gary Roderick]

Yes,  thought it would, my gauges exhibit the same behaviour. The SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I need to sit down and work through the data.

Of course,  we could just disable F :)

Gary

> --

> You received this message because you are subscribed to the Google Groups "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[tempus]

On Saturday, February 18, 2017 at 5:43:42 PM UTC-8, gjr80 wrote:

Yes,  thought it would, my gauges exhibit the same behaviour. The SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I need to sit down and work through the data.

Of course,  we could just disable F :)

Gary

I will have a look at the code myself when I have time.

While you are looking, I noticed another issue. The gauge wind speed is 0.1 MPH less than shown on the Davis console.

1 MPH shows as 0.9 MPH
2 MPH shows as 1.9 MPH
3 MPH shows as 2.9 MPH
etc.

Bob

[tempus]

Maybe the Davis console display rounds-up. I just saw the gauge and Davis both display 2 MPH after several times where Davis displayed 2 and the gauge displayed 1.9.

Bob

[gjr80]

I had a suspicion the issue was with apptemp and gauge autoscaling; since weeWX (by default) calculates appTemp and adds it to each loop/archive packet but does not natively archive appTemp, there are no stats available for appTemp, just the current value. I knew the SteelSeries gauges do not like null values in its data feed yet I foolishly left the day high and low apptemp fields in gauge-data.txt go to None (which results in null in the gauge-data.txt JSON format). This messed up the autoscaling that is triggerred when switching to F (I suspect that if you set rtgd to output F it would work fine but when you then change display to C it would exhibit similar bad behaviour). There are a few options:

1. customise weeWX to archive appTemp, ie follow the instructions at Adding a new observation type in the Customization Guide. Note that there is no need to add a service as appTemp is already calaculated, the only real change is that you need to add appTemp to the db and set its units. Pretty easy stuff.

2. set apptempL and apptempH both to 0. The light red wedge on the apparent temp gauge that shows the appTemp day range would not show, we can't make up data so no problems there. The mouseover plot would show the day low and high to be 0 (or maybe 32 deending on source and display units) - that will be wrong but at least it is largely hidden from the user. The autoscaling could have some issues if you were in a very hot location where all your temps (outTemp, windchill, heatindex, humidex, dewpoint, appTemp) were relatively high; the apptempL and apptempH values may skew the autoscaling to the lower end. But the nonsense behaviour currently happening would not occur.

3. set apptempL and apptempH both to the current appTemp value. Again the light red wedge on the apparent temp gauge that shows the appTemp day range would not show. The mouseover plot would show the day low and high to be whatever the current appTemp value is - again that will be wrong but at least it is largely hidden from the user. The autoscaling would not be uspet (ie skewed) under any circumstances.

4. use weeWX-WD to record appTemp in a separate database. This has all the advantages of 1. without the need to chnage the weeWX database (which is not really an issue). I don't think this is a practical solution, its a bit like buying a Mack truck just to take a trip to the corner store for the paper each day (and finding your truck probably breaks down once a month!).

At the moment I am leaning towards a hybrid; look for a day low/high appTemp, if they are available use them, otherwise set both to the current appTemp value. I could probably include a silent option in the rtgd config to specify a binding from where to get appTemp data which would default to wx_binding (the weeWX default binding) (I have my appTemp data in a separate datbase so this ability will almost certainly be included :) )

Gary

[gjr80]

I am sorry, I did not see this post with the flurry of activity on the 14th.

I appreciate the limitations of the Zambretti forecast, but I prefer it to 'forecast not available'. I am not sure exactly what you mean by 'include webpage code that will display a professional forecast obtained via the Forecast extension or other means', when I said I would have a chat with Matthew I should have said that was in regards to getting the forecast extension to make available forecast text other than the Zambretti text. I am loathed to try to include other (internet based) lookups in rtgd, it already runs in its own thread generating output potentially every 2.5 seconds. Pullling data from the internet or caching internet content is added time (through timeouts etc)/complexity that I don't think is warranted if we can get suitable info out of the forecast extension.

Gary

On Tuesday, 14 February 2017 02:49:48 UTC+10, tempus wrote:

Has there been more progress on your new custom Service bound to the NEW_LOOP_PACKET event?  It would be great to have even a partially-functioning beta-version as a stop-gap solution.

Zambretti forecast data doesn't seem important, because those forecasts are so poor compared to forecasts readily available from multiple other sources as to reflect poorly on the likely reliability of everything being displayed.  Why not eliminate the Zambretti forecast and let users who want a forecast above the gauges include webpage code that will display a professional forecast obtained via the Forecast extension or other means?

Bob

On Monday, January 9, 2017 at 4:27:44 PM UTC-8, gjr80 wrote:

Any chance you could use the NWS or WU current forecast for the tickertape/scroller in place of the Zambretti?

At the moment all I can do is pull the Zambretti forecast from the forecast database (provided the forecast extension is installed), unfortunately the WU and NWS forecast text is not saved in the forecast database. I have had the WU forecast text being pulled in through weewx-WD but that is something for the next version of weewx-WD and that is going to be weeks away (at least).

I might have a chat with Matthew and see what he may be prepared to do, though I know he has a lot on at present.

Gary

[tempus]

On Saturday, February 18, 2017 at 10:30:08 PM UTC-8, gjr80 wrote:

I am sorry, I did not see this post with the flurry of activity on the 14th.

I appreciate the limitations of the Zambretti forecast, but I prefer it to 'forecast not available'. I am not sure exactly what you mean by 'include webpage code that will display a professional forecast obtained via the Forecast extension or other means', when I said I would have a chat with Matthew I should have said that was in regards to getting the forecast extension to make available forecast text other than the Zambretti text. I am loathed to try to include other (internet based) lookups in rtgd, it already runs in its own thread generating output potentially every 2.5 seconds. Pullling data from the internet or caching internet content is added time (through timeouts etc)/complexity that I don't think is warranted if we can get suitable info out of the forecast extension.

Gary

Sorry, I should have been more explicit. I didn't mean to suggest that you should include a better forecast in rtgd, but instead that if rtgd users want to display a forecast along with current conditions they can include a better forecast in their webpages by some means outside of rtgd (php include, HTML Server Side Include, widget on a WordPress page, HTML link to a forecast page, or whatever).

Current conditions and forecasts are, of course, much different.  Current conditions are facts, whereas forecasts are guesses about the future.  Regardless of whether a forecast is based on rolling dice, the "educated guess" of a meteorologist, the output of a trained artificial neural net, an evolutionary algorithm, or other artificial intelligence engine of some kind, they are guesses that shouldn't be entangled with or mentally-confused with facts.  If guesses are going to be displayed along with facts, because they are far less accurate and potentially even grossly wrong, they should come after facts with clear demarcation and identification.

Where Zambretti forecasts are only marginally better than rolling dice, why degrade a page displaying facts by including them at the top?  Of course, rtgd users can easily disable or hide Zambretti forecasts if they don't want to display them, but why even bother to include them where they are not accurate and have nothing to do with current conditions displayed by the gauges?

Bob
 

[tempus]

On Saturday, February 18, 2017 at 5:56:41 PM UTC-8, tempus wrote:

This was found to be due to a loss of precision resulting from Rtgd converting F to C and JavaScript then converting C back to F.  This and other issues were fixed by specifying US units in weewx, like this:

[RealtimeGaugeData]
    ...

    [[Groups]]
        group_pressure = inHg
        group_rain = inch
        group_rainrate = inch_per_hour
        group_speed = mile_per_hour
        group_distance = mile
        group_temperature = degree_F
        group_percent = percent
        group_uv = uv_index
        group_direction = degree_compass

And by adding US 'StringFomats', like this:

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

Bob

[tempus]

Setting rtgd to output F doesn't correct the problem.

I have no personal interest in windchill, heatindex, humidex, or appTemp and want to set that gauge to always display dewpoint.

Bob

[tempus]

Your Option 3 below seems best to me.  Where is the best place to set apptempL and apptempH both to the current appTemp value?

Bob

On Saturday, February 18, 2017 at 9:50:54 PM UTC-8, gjr80 wrote:

[Devonian]

I have implemented Gary's latest updated file (no other changes to my system).

Seems OK now.

I have no desire to display a forecast in the gauges.

I use a link on my main weewx page to link to the UK Met Office for 'professional' forecasting.

Nigel.

[tempus]

I also just installed Gary's new rtgd-0.2.2 which fixed the Fahrenheit gauge-scaling issue. Thanks very much for finding and fixing that problem so promptly.

Bob

[tempus]

This is a link to a page at a test-site if you want to see the gauges updating at 3-second intervals.

http://www.lablibrary.com/ss/

There are no developer-credits or anything else other than gauges on that page, because access is normally blocked at the firewall. I am just playing around with ideas with the general intention to eventually embed that page within another one at a public website.

The Wind Rose still needs attention, but otherwise the gauges seem to be working.

Bob

[tempus]

Sorry if you aren't able load the test page. I have taken it down to fix an issue.

Bob

[gjr80]

Option 3 was implemented in v0.2.3. No need to do anything with appTemp, rtgd taes care of it.

Gary

[gjr80]

Unfortunately the issue will remain whilst the gauge-data.txt values are formatted to the likes of 1 decimal place. This issue also exists with other PWS software that produce a similarly formatted data file for use by the SteelSeries Weather Gauges. Changing the underlying units to the units normally used by the user will eliminate the issue for those units, but the issue will eventually recur if different units are selected for display (for example, your MPH values will now be accurate but someone observing your gauges in km/h will eventually see a similar small error, admittedly they won't have a console in front of them to highlight the discrepancy :) )

Gary

[Devonian]

Dropped the new file in place, stop/start weewx and it looks good to me Gary.

Online in the usual place if anyone is interested...

http://www.nthead.co.uk/ss/index.html

Nigel.

[stefano siega]

Hi

I have integrated the update to 2.5 seconds for steelseries gauges using the same system that uses Mesowx.

I read from mysql database just the values ​​that make sense to be updated every two seconds. All other values ​​are read in the gauge-data.txt file

Here my page at 2.5 second update: http://www.flysohigh.net/weather/weewx/oseacco/steelseries/index

Here my station: http://www.flysohigh.net/meteo-val-resia/

Il giorno lunedì 2 gennaio 2017 14:12:43 UTC+1, Devonian ha scritto:

I have just invested in a Davis Vantage Pro2, which replaced my WS2300 and have installed Weewx 3.6.2 on Debian ver8 replacing my previous weewx ver 2.7 for the WS2300.

I would like to get the Steel Series gauges performing real time updates at the Davis loop interval of 2.5 seconds.

I have them installed OK, but it uses my current archive interval of 5 minutes - not quite real time!

I tried mesowx, but can't get the data to display - the page appears, but no graphs.  Data is getting saved into my MySQL 'raw' database at regular 2.5 second loop intervals.  I'll continue trying to figure this one out.

So, my thoughts turned to using the raw database for Steel Series and to use raw data instead of archive data.

I'm primarily interested in wind speed/direction, so if I could only get that to update @ 2.5 seconds, I'd be happy with the others at 5 minutes.

Anyone got any ideas on how to use this raw data instead of archive?

Maybe there's a better/simpler way to achieve this 2.5 second update?

Regards,

Nigel.

[Devonian]

Hi Stefano,

Well done and nice site.

Interesting to see you also did a HAB.

Nigel

[Steve2Q]

Hello: I presently have the Steel Gauges working with Weewx (v 3.6.2). They are currently updating at my archive interval of 2 minutes. I would like to have them work at my Ultimeter console loop interval of 2.5 seconds, and like Nigel would only want the windspeed/direction to have such a quick update: I have a few questions:

1. I need a cookbook approach as I read thru the thread and can't quite get my head around it. Do I just have to replace some of the Steel Gauge files, or is it more complex?

2. If I am successful will the new set of gauges have the wind rose?

3. Will the update be writing to my .sdb file (or any others) at the increased rate?

Thank you in advance,  Steve

[gjr80]

Hi Steve,

One of my earlier posts gave a link to the GitHub repo that contains the realtime gauge data extension. Here it is again: https://github.com/gjr80/weewx-realtime_gauge-data

1. I need a cookbook approach as I read thru the thread and can't quite get my head around it. Do I just have to replace some of the Steel Gauge files, or is it more complex?

The readme that displays on the GitHub link above has step by step instructions, hopefully they will do the job. If you are currently running the skin that generates gauge-data.txt you will need to disable that skin (comment it out in weewx.conf) or you will likely have have 2 services trying to write the same file.

2. If I am successful will the new set of gauges have the wind rose?

Yes

Will the update be writing to my .sdb file (or any others) at the increased rate?

No, the realtime gauge data extension intercepts loop data and generates (and writes) a gauge-data.txt file using a period defined by you (in weewx.conf). The database is not touched.

and like Nigel would only want the windspeed/direction to have such a quick update

Not sure exactly what you want here. All fields, not just wind related ones, are updated from the latest data each time a gauge-data.txt file is generated, I presume this is acceptable.

The realtime extension can generate a gauge-data.txt file on arrival of each loop packet or (less frequently if required). I am not familiar with your stations loop packets, but the info in the Hardware Guide seems to indicate loop packets could occur as frequently as every 0.5 seconds. If you generate gauge-data.txt at that rate you could run into some issues because the extension may still be generating a file when the next loop packet comes in (how long it takes to generate will depend on you PC). You can certainly 'slow down' the extension so that it generates, at best, every x seconds (using the min_interval option under [RealtimeGaugeData] in weewx.conf). Note that the documentation, other than the quick start instuctions, is still a work in progress. However, if you have a look at the comments at the start of the installed rtgd.py file you should see all the available options documented.

One limitation though, if the web server you are using is another PC or external and you were using FTP or RSYNC to transfer gauge-data.txt that approach is not supported with the realtime gauge data extension. The extension can save the file anywhere on the weeWX PC or use HTTP POST to send the file to a remote URL. HTTP POST should be easy enough to setup if needed, though it's not yet documented.

Gary

[Steve2Q]

Gary..thank you very much for the very detailed reply. I will start working on it this week and keep you posted on my progress.
Steve

[Steve2Q]

Gary..I am making some notes for myself to follow based on the information you provided. I have been looking for references to HTTP POST, but have not yet found anything. I am currently using FTP to upload to my website. Is it as simple as just changing the FTP section in weewx.conf to say FTP POST? (probably not! :))

steve

[Steve2Q]

Gary..I think I answered my own question. I didn't search deep enough yesterday, but I found the info on some separate posts dealing with making a Wunderground type windspeed/direction gauge.
I will start tomorrow.
Steve

[gjr80]

Steve,

I have been looking for references to HTTP POST, but have not yet found anything. I am currently using FTP to upload to my website. Is it as simple as just changing the FTP section in weewx.conf to say FTP POST? (probably not! :))

HTTP POST is a method of communications over HTTP between a client and a server, in this case between your weeWX machine and the web server that hosts your site. It is similar to how weeWX sends data/rapid fire data to WU (well WU actually uses HTTP GET but the concept is the same). Practically, it entails storing a PHP script on your web server and each time the realtime gauge-data service generates the data for the gauge-data.txt file, the service contacts the script on your web server via a HTTP POST request and transfers the gauge-data.txt data to your web server and all being well the script then saves the data to gauge-data.txt on your web server.

I use HTTP POST to transfer gauge-data.txt on my LAN, I have not set it up with a hosted server though it should not be difficult. Provided your web server supports PHP (I think most hosted services do/can) the (broad) steps involved are (1) upload the PHP script to your web server (2) change a few settings in the [RealtimeGaugeData] section of weewx.conf (3) adjust the SteelSeries config (gauges.js)on your web server to pickup the new gauge-data.txt file. There may be some permission issues to deal with on your web server but they should not be too onerous.

Gary..I think I answered my own question. I didn't search deep enough yesterday, but I found the info on some separate posts dealing with making a Wunderground type windspeed/direction gauge.

Hmm, interesting concept, post your data to WU so you can pull it down to display on your web page. If you want to try to get the HTTP POST up and running let me know and I will knock up some instructions, as I said above other than the standard install documentation the documentation is still a work in progress.

Gary

[Steve2Q]

Gary..." If you want to try to get the HTTP POST up and running let me know and I will knock up some instructions.."

That would be appreciated. While I understand some of the concepts and can do minor modifications, I am in no way proficient in programming, but I am great at following instructions.

The post I referred to did not mention posting data to Wunderground, but I think he figured out how the WU rapidfire windspeed/direction indicator worked and then put the same on his website.

Steve

[gjr80]

On Tuesday, 20 June 2017 10:01:55 UTC+10, Steve2Q wrote:

Gary..." If you want to try to get the HTTP POST up and running let me know and I will knock up some instructions.."

That would be appreciated. While I understand some of the concepts and can do minor modifications, I am in no way proficient in programming, but I am great at following instructions.

Have drafted some instructions but just need to run through them for completeness. Will be a tomorrow (for me) job.

 

The post I referred to did not mention posting data to Wunderground, but I think he figured out how the WU rapidfire windspeed/direction indicator worked and then put the same on his website.

 

Correct, my mistake, I remember that now, he was imitating a WU like wind speed/dir display. (the data transfer for which is being done by a HTTP POST or GET I believe).

Gary
 

Steve

[gjr80]

Steve,

Have a look at the instructions here. The basic formula is to get the extension installed and generating a loop based gauge-data.txt locally first then implement the HTTP POST - this will simplify any troubleshooting when/if the HTTP POST does not work.

I will preface these instructions with the caveat that I have not set this up with external hosting. I beleive that others may have, but my setup has been on my own host here at home. The overall process is correct but some of the precise steps may need fine tuning. See how you go.

Gary

[Steve2Q]

Gary,  I have been plodding along but no joy. What is happening is after I make the changes to weewx.conf, post_gauge-data.php, etc., Weewx wont even start, so I don't have a syslog file for you to look at.

If you have the time, maybe you could look over some files and see if you can find what I am doing wrong.

This is my web server structure:
root directory
 |
  -photokinetics.org
   |
 -Weather
      |
- all my weather data in which I created a folder called gauges (which is empty)

On my Weewx machine (RaspberryPi) I used setup.py to do the initial install of weewx.

 First attachment is my post_gauge-data.php file.

Next is my weewx.conf file renamed weewx.conf.modded.txt

rtg.py is in /home/weewx/bin/user

My web server has a folder called .php which contains folders labeled 7.0, 5.6, 5.5, 5.4 and 5.3  Does this mean that my server has php installed and configured?

Anyway, Gary, I really appreciate your time in trying to help me out.

Steve

[gjr80]

Steve,

Comments below.

Gary

On Thursday, 22 June 2017 11:37:20 UTC+10, Steve2Q wrote:

Gary,  I have been plodding along but no joy. What is happening is after I make the changes to weewx.conf, post_gauge-data.php, etc., Weewx wont even start, so I don't have a syslog file for you to look at.

Looking at the weewx.conf you posted you have two [RealtimeGaugeData] stanzas:

# This is the stanza for Real Time Guage Data

[RealtimeGaugeData]
    [RealtimeGaugeData]

This will certainly cause weeWX to hiccup very early in the startup, though it should give some output to log. I put the same config on a test system and received the following in the log:

Jun 22 15:24:17 jessie114 weewx[2288]: engine: Initializing weewx version 3.7.1
Jun 22 15:24:17 jessie114 weewx[2288]: engine: Using Python 2.7.9 (default, Jun 29 2016, 13:08:31) #012[GCC 4.9.2]
Jun 22 15:24:17 jessie114 weewx[2288]: engine: Platform Linux-3.16.0-4-amd64-x86_64-with-debian-8.8
Jun 22 15:24:17 jessie114 weewx[2288]: engine: Locale is 'en_AU.UTF-8'
Jun 22 15:24:17 jessie114 weewx[2288]: engine: pid file is /var/run/weewx.pid
Jun 22 15:24:17 jessie114 weewx[2279]: Starting weewx weather system: weewx.
Jun 22 15:24:17 jessie114 weewx[2292]: engine: Error while parsing configuration file /home/weewx/weewx.conf
Jun 22 15:24:17 jessie114 weewx[2292]: ****    Reason: 'Duplicate section name at line 407.'

You need to remove the second [RealtimeGaugeData] heading. I had a look through your posted weewx.conf and nothing else jumps out at me, though the proof will be in the pudding so to speak. Once you have made that change stop then start weeWX and see how it goes. If weeWX still appears not to start, and nothing seems to be in the log, then run weeWX directly; that should give you some output direct to screen and hopefully it will indicate what the problem is.

Before we worry about the HTTP POST side of things we need to make sure gauge-data.txt is being generated by weeWX, if it isn't we will likely end up chasing our tails trying to sort out HTTP POST.
 

If you have the time, maybe you could look over some files and see if you can find what I am doing wrong.

This is my web server structure:
root directory
 |
  -photokinetics.org
   |
 -Weather
      |
- all my weather data in which I created a folder called gauges (which is empty)

On my Weewx machine (RaspberryPi) I used setup.py to do the initial install of weewx.

 First attachment is my post_gauge-data.php file.

Next is my weewx.conf file renamed weewx.conf.modded.txt

rtg.py is in /home/weewx/bin/user

My web server has a folder called .php which contains folders labeled 7.0, 5.6, 5.5, 5.4 and 5.3  Does this mean that my server has php installed and configured?

Would seem to be a good sign, if I go to http://photokinetics.org/Weather/post_gauge-data.php in my browser I get the following error message displayed:

Parse error: syntax error, unexpected '/' in /home/n2qlq/photokinetics.org/Weather/post_gauge-data.php on line 28

That tells me 2 things. Firstly, PHP is installed because line 28 is trying to be executed (rather than 'displayed' which is what would happen if PHP was not enabled). Secondly, there is an error at line 28 in the file. Looking at the post_gauge-data.php you posted line 28 is:

$json_file = /photokinetics.org/Weather/gauges/gauge-data.txt

whereas the original was:

$json_file = "data/gauge-data.txt";

so you need to put the quotes back in and end the line with a semi-colon. If I am reading your server directory structure correctly (some of those lines don't line up to well on a web page) you probably want $json_file to be set as follows:

$json_file = "gauges/gauge-data.txt";

[Steve2Q]

Gary...making progress!! I made the corrections you suggested and one I found myself :); there was a duplicate line under [[Engine]] and when I removed it it started. If you look at my site;  http://photokinetics.org/Weather/index.html and go to the Steel Gauges button at the bottom you will see that the gauges don't "know" that weewx is back online.

At the present time I have this entry for [[SteelSeries]] in weewx.conf under [StandardReport]. Perhaps it is not commented and/or indented properly (I am slowly learning that is important)

[[StandardReport]]
        # See the customizing guide to change the units, plot types and line
        # colors, modify the fonts, display additional sensor data, and other
        # customizations. Many of those changes can be made here by overriding
        # parameters, or by modifying templates within the skin itself.
       
        # The StandardReport uses the 'Standard' skin, which contains the
        # images, templates and plots for the report.
        skin = Standard
   
    #[[SteelSeries]]
        #skin = ss
        #HTML_ROOT = public_html/ss

There is also a /skins/ss directory from when I first added the gauges which were updating at my 2 minute archive interval.

That is where it is now. Are there any specific log files and/or should I stop weewx, turn on debug and let it run?

Also, a side question; /var/log is filled with various type of log, gz files etc. Can all or some be deleted?

I am in your debt...Steve
   


  
  

[gjr80]

Steve,

Missed that duplicate, didn't see the woods for the trees. No need to look in any weeWX logs, I can see that everything is working as it should as there is a gauge-data.txt appearing in your Weather/gauges directory on your web server and it is current and updating. Since gauge-data.txt is in a different location to where the previous ss skin generated gauge-data.txt, you will need to make a change in one of the SteelSeries scripts so that the SteelSeries Gauges know where to find gauge-data.txt.

You need to edit the file gauges.js on your web server, you should find it in the Weather/ss/scripts directory. The following line (about line 68):

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

needs to be changed to

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

While you are at it, you should turn on display of the windrose since we now have windrose data in gauge-data.txt. Go down to line 323, it should be:

config.showRoseGauge = false;       // FIXME: add wind histogram to weewx SLE

and change it to

config.showRoseGauge = true;       // FIXME: add wind histogram to weewx SLE

Make the changes, save the file and try refreshing your gauges page. It should update on each loop packet and it should also show the windrose gauge.

Gary

[Steve2Q]

Gary..take a look at my gauges; it says "error not found" and the counter is going backwards.

I probably made another typo..attached is my .js file.

Steve

[gjr80]

Steve,

The issue is that the SteelSeries Gauges cannot find your gauge-data.txt file. When I point my browser at http://photokinetics.org/Weather/ss/scripts/gauges.js I see the following:

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

which is different to what you posted. I think you want

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

Interestingly enough your change to display the windrose took, but the one above did not. Try making the change again.

Gary

[gjr80]

Just noticed in gauges.js at about line 37 it shows

weatherProgram : 0, //Set 0=Cumulus, 1=Weather Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX

not sure how this ever worked as it needs to be 6 for it to work with weeWX. You will need to change it to (note no quotes)

weatherProgram : 6, //Set 0=Cumulus, 1=Weather Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX

Gary

[Steve2Q]

Gary: It appears to be working fine now! I I made the last two changes you recommended, and that did the trick. I do notice one thing: I use WindChill and HeatIndex on my main page. Using the formulas, it either or both are not defined, Current Conditions show "undefined" and nothing is plotted on the graphs. The gauge shows 32 degrees when the formulas are not met. Is there a way to link what the gauge shows to the weewx calculation formula results? Perhaps have "Undefined" displayed in the gauge window, with the indicator equal to the outside temperature?

I certainly appreciate all your patience in helping a NOOB. Maybe I should write up a "Real Time Gauges for Dummies" for the Wiki, because my unfamiliarity with programming means I had to first learn the basics like the best way(s) to edit different types of files to obtain my goal (along with trying to have a little understanding of the programming itself).

Anyway, kudos to you, Tom, Matthew, and the many others who developed Weewx and lend all of this support.o

Steve

[gjr80]

Good to see it is working Steve.

I do notice one thing: I use WindChill and HeatIndex on my main page. Using the formulas, it either or both are not defined, Current Conditions show "undefined" and nothing is plotted on the graphs. The gauge shows 32 degrees when the formulas are not met. Is there a way to link what the gauge shows to the weewx calculation formula results? Perhaps have "Undefined" displayed in the gauge window, with the indicator equal to the outside temperature?

Unfortunately there is not much you can do. A similar issue arises if a sensor drops for some reason. The SteelSeries code is such that it takes the value for a given observation and tries to interpret it as a number, if it can then the number is displayed in the selected units, if it can't be converted to a number then 0 is displayed. There is no ability to display anything other than a number on the gauge LCD and the pointer just reflects what is on the LCD (or is it vice versa?). I guess you could say that I have contributed a little to the issue as rtgd.py will set a field to 0 in the applicable Metric units if the observation in non-numeric or undefined (or None in python parlance). So for temperature type fields that have a misisng or undefined value, 0C or 32F will be displayed. Why? I guess because I use Metric and I find that if a field is missing data displaying a 0 is better than a display of 32. I could probably make the units in such a case user selectable, so folks that display F will see 0F rather than 32F. UInfortunately not much else that can be done short of modifying the SteelSeries code and I won't be embarking on that.

Maybe I should write up a "Real Time Gauges for Dummies" for the Wiki, because my unfamiliarity with programming means I had to first learn the basics like the best way(s) to edit different types of files to obtain my goal (along with trying to have a little understanding of the programming itself).

By all means, I will update the wiki on the realtime_gauge-data GitHub site and referece it on the weeWX wiki, but that will be a work in progress for a little while.

As a final thought a couple of things you might want to consider doing to fine tune your SteelSeries setup.

1. gauge-data.txt units. A default install of the realtime_gauge-data extension will result in gauge-data.txt containing Metric units. Whilst the SteelSeries Gauges page gives you the ability to change display units dynamically, anyone going to your page the first time will see the units used in gauge-data.txt. (as an aside the SteelSeries gauges stores a cookie that keeps your display units settings for subsequent page visits). Given you are in the US you might want to switch your gauge-data.txt units to US customary so that visitors will see US customary by default (I expect most of your visitors are US based). To do this you need to edit the [RealtimeGaugeData] [[Groups]] config options in weewx.conf. Just change the options to the units desired, the unit codes are the same as used in weeWX skins ie degree_C, degree_F etc. Be aware that the SteelSeries Gauges do not support all units that weeWX does (eg mmHg).

2. Mouseover plots. Given the changes made the mouseover plots are broken, I suspect a chnage is requried to gauges.js, the plots are still in Weather/ss on your web server but they are not being updated (refer point 3 below). Try changing the following line (line 38) to read:

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

3. Disabling the [[SteelSeries]] skin was done as an easy way to prevent there being conflicting gauge-data.txt files on your web server. There are a few side issues to disabling the skin. One is that the ss/index.html file is no longer generated each report cycle, this means that things like weeWX version etc will never update on this page is you happen to upgrade weeWX. Another is that the mouseover plots for the gauges are not generated so your mouseover plots are empty. So you probably should re-enable the SteelSeries skin but disable couple of its features. I suggest you:

a. edit weewx.conf and remove the comments against the [[SteelSeries]] skin
b. edit skins/ss/skin.conf, locate [CheetahGenerator] and disable the generation of gauge-data.txt eg:

[CheetahGenerator]
    encoding = html_entities
    [[ToDate]]
        [[[index]]]
            template = index.html.tmpl
        #[[[data]]]
        #    template = gauge-data.txt.tmpl

c. edit skins/ss/scripts/gauges.js and make the same changes to it that you made to gauges.js on your web server. We do this as once the skin is enabled again any restart of weeWX would see the gauges.js on your web server overwritten.
d. stop then start weeWX
e. check that it all still works!


Gary

[Steve2Q]

Gary:  Ok..I did the changes (I hope correctly). Now what is happening is the gauges think the station "is offline . Last update 2 days ago". And the time counter is back to 2 minutes. BUT, the graphs are back!

This is what I think may be a relevant snip from syslog:

Jun 24 14:06:09 raspi2 weewx[30683]: reportengine: Running report forecast
Jun 24 14:06:09 raspi2 weewx[30683]: reportengine: Found configuration file /home/weewx/skins/Standard/skin.conf for report forecast
Jun 24 14:06:09 raspi2 weewx[30683]: cheetahgenerator: using search list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']
Jun 24 14:06:09 raspi2 weewx[30683]: ultimeter: close serial port /dev/ttyUSB0
Jun 24 14:06:09 raspi2 weewx[30683]: reportengine: Caught unrecoverable exception in generator weewx.cheetahgenerator.CheetahGenerator
Jun 24 14:06:09 raspi2 weewx[30683]:         ****  'skin'
Jun 24 14:06:09 raspi2 weewx[30683]:         ****  Traceback (most recent call last):
Jun 24 14:06:09 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/reportengine.py", line 238, in run
Jun 24 14:06:09 raspi2 weewx[30683]:         ****      obj.start()
Jun 24 14:06:09 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/reportengine.py", line 271, in start
Jun 24 14:06:09 raspi2 weewx[30683]:         ****      self.run()
Jun 24 14:06:09 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/cheetahgenerator.py", line 150, in run
Jun 24 14:06:09 raspi2 weewx[30683]:         ****      ngen = self.generate(gen_dict[section_name], self.gen_ts)
Jun 24 14:06:09 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/cheetahgenerator.py", line 219, in generate
Jun 24 14:06:09 raspi2 weewx[30683]:         ****      ngen += self.generate(section[subsection], gen_ts)
Jun 24 14:06:09 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/cheetahgenerator.py", line 219, in generate
Jun 24 14:06:09 raspi2 weewx[30683]:         ****      ngen += self.generate(section[subsection], gen_ts)
Jun 24 14:06:09 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/cheetahgenerator.py", line 234, in generate
Jun 24 14:06:09 raspi2 weewx[30683]:         ****      self.skin_dict['skin']))
Jun 24 14:06:09 raspi2 weewx[30683]:         ****    File "/usr/lib/python2.7/dist-packages/configobj.py", line 567, in __getitem__
Jun 24 14:06:09 raspi2 weewx[30683]:         ****      val = dict.__getitem__(self, key)
Jun 24 14:06:09 raspi2 weewx[30683]:         ****  KeyError: 'skin'
Jun 24 14:06:09 raspi2 weewx[30683]:         ****  Generator terminated
Jun 24 14:06:11 raspi2 weewx[30683]: genimages: Generated 12 images for forecast in 2.00 seconds
Jun 24 14:06:11 raspi2 weewx[30683]: reportengine: Caught unrecoverable exception in generator weewx.reportengine.CopyGenerator
Jun 24 14:06:11 raspi2 weewx[30683]:         ****  'skin'
Jun 24 14:06:11 raspi2 weewx[30683]:         ****  Traceback (most recent call last):
Jun 24 14:06:11 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/reportengine.py", line 238, in run
Jun 24 14:06:11 raspi2 weewx[30683]:         ****      obj.start()
Jun 24 14:06:11 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/reportengine.py", line 271, in start
Jun 24 14:06:11 raspi2 weewx[30683]:         ****      self.run()
Jun 24 14:06:11 raspi2 weewx[30683]:         ****    File "/home/weewx/bin/weewx/reportengine.py", line 415, in run
Jun 24 14:06:11 raspi2 weewx[30683]:         ****      self.skin_dict['skin']))
Jun 24 14:06:11 raspi2 weewx[30683]:         ****    File "/usr/lib/python2.7/dist-packages/configobj.py", line 567, in __getitem__
Jun 24 14:06:11 raspi2 weewx[30683]:         ****      val = dict.__getitem__(self, key)
Jun 24 14:06:11 raspi2 weewx[30683]:         ****  KeyError: 'skin'
Jun 24 14:06:11 raspi2 weewx[30683]:         ****  Generator terminated
Jun 24 14:06:11 raspi2 weewx[30683]: reportengine: Running report SteelSeries
Jun 24 14:06:11 raspi2 weewx[30683]: reportengine: Found configuration file /home/weewx/skins/ss/skin.conf for report SteelSeries
Jun 24 14:06:11 raspi2 weewx[30683]: reportengine: copied 0 files to /home/weewx/public_html/ss
Jun 24 14:06:11 raspi2 weewx[30683]: cheetahgenerator: using search list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']
Jun 24 14:06:11 raspi2 weewx[30683]: cheetahgenerator: Generated 1 files for report SteelSeries in 0.05 seconds
Jun 24 14:06:11 raspi2 weewx[30683]: ultimeter: open serial port /dev/ttyUSB0
Jun 24 14:06:12 raspi2 weewx[30683]: ultimeter: close serial port /dev/ttyUSB0
Jun 24 14:06:13 raspi2 weewx[30683]: genimages: Generated 9 images for SteelSeries in 1.67 seconds
Jun 24 14:06:13 raspi2 weewx[30683]: reportengine: Running report FTP
Jun 24 14:06:13 raspi2 weewx[30683]: reportengine: Found configuration file /home/weewx/skins/Ftp/skin.conf for report FTP
Jun 24 14:06:13 raspi2 weewx[30683]: ftpupload: Attempting connection to www.photokinetics.org
Jun 24 14:06:13 raspi2 weewx[30683]: ftpupload: Connected to www.photokinetics.org
Jun 24 14:06:14 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/dayrx.png
Jun 24 14:06:14 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/index.html
Jun 24 14:06:14 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/daypond.png
Jun 24 14:06:14 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/daytempdew.png
Jun 24 14:06:14 raspi2 weewx[30683]: ultimeter: open serial port /dev/ttyUSB0
Jun 24 14:06:15 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/daybarometer.png
Jun 24 14:06:15 raspi2 weewx[30683]: ultimeter: close serial port /dev/ttyUSB0
Jun 24 14:06:15 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/dayrain.png
Jun 24 14:06:15 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/gauge-data.txt
Jun 24 14:06:15 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/mobile.html
Jun 24 14:06:15 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/week.html
Jun 24 14:06:16 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/daytempchill.png
Jun 24 14:06:16 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/daywinddir.png
Jun 24 14:06:16 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/month.html
Jun 24 14:06:16 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/daywindvec.png
Jun 24 14:06:17 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/dayinside.png
Jun 24 14:06:17 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/dayradiation.png
Jun 24 14:06:17 raspi2 weewx[30683]: ultimeter: open serial port /dev/ttyUSB0
Jun 24 14:06:17 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/year.html
Jun 24 14:06:17 raspi2 weewx[30683]: ultimeter: close serial port /dev/ttyUSB0
Jun 24 14:06:17 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/dayuv.png
Jun 24 14:06:17 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/daywind.png
Jun 24 14:06:18 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/NOAA/NOAA-2017.txt
Jun 24 14:06:18 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/NOAA/NOAA-2017-06.txt
Jun 24 14:06:18 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/dayrainrate.png
Jun 24 14:06:19 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/index.html
Jun 24 14:06:19 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/daybarometer.png
Jun 24 14:06:19 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/dayrain.png
Jun 24 14:06:19 raspi2 weewx[30683]: ultimeter: open serial port /dev/ttyUSB0
Jun 24 14:06:19 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/dayouttemphum.png
Jun 24 14:06:19 raspi2 weewx[30683]: ultimeter: close serial port /dev/ttyUSB0
Jun 24 14:06:20 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/daywinddir.png
Jun 24 14:06:20 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/daywindvec.png
Jun 24 14:06:20 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/dayinouthum.png
Jun 24 14:06:20 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/dayinouttemp.png
Jun 24 14:06:21 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/ss/daywind.png
Jun 24 14:06:21 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/RSS/weewx_rss.xml
Jun 24 14:06:21 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/smartphone/index.html
Jun 24 14:06:22 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/smartphone/wind.html
Jun 24 14:06:22 raspi2 weewx[30683]: ultimeter: open serial port /dev/ttyUSB0
Jun 24 14:06:22 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/smartphone/barometer.html
Jun 24 14:06:22 raspi2 weewx[30683]: ultimeter: close serial port /dev/ttyUSB0
Jun 24 14:06:22 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/smartphone/temp_outside.html
Jun 24 14:06:22 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/smartphone/rain.html
Jun 24 14:06:22 raspi2 weewx[30683]: ftpupload: Uploaded file photokinetics.org/Weather/smartphone/radar.html
Jun 24 14:06:23 raspi2 weewx[30683]: reportengine: ftp'd 37 files in 9.44 seconds
Jun 24 14:06:23 raspi2 weewx[30683]: reportengine: Running report RSYNC
Jun 24 14:06:23 raspi2 weewx[30683]: reportengine: Found configuration file /home/weewx/skins/Rsync/skin.conf for report RSYNC
Jun 24 14:06:23 raspi2 weewx[30683]: reportengine: rsync upload not requested.

Let me know if you want to look at the different files I changed.

Thanks,   Steve

[gjr80]

Ok, a few issues. An old gauge-data.txt from 22 June is being uploaded from your weeWX machine to your web server, that is why you are seeing the 'your station is offline' message. It also seems that some of the old gauges.js settings have returned. Here is what you need to do.

On your weeWX machine:
1. Delete gauge-data.txt from directory /home/weewx/public_html/ss
2. Edit skins/ss/script/gauges.js and make sure the following lines are as indicated:

line 34

weatherProgram    : 6,                      //Set 0=Cumulus, 1=Weather Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX

line 35

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

line 37 (not sure what you had here before, was it 2 or 3 or 5?, puyt back whatever it was before when the gauges were updating in realtime)

realtimeInterval  : 2,                      //*** Download data interval, set to your realtime data update interval in seconds

line 68

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

line 323

config.showRoseGauge = true;       // FIXME: add wind histogram to weewx SLE

3. Stop then start weewx. After the next report cycle an updated gauges.js should be uploaded to your web server. This should get your gauges back updating in realtime.

As for the weeWX log errors, it looks like there may be a typo in the [StdReport] section of weewx.conf. I am guessing these log errors only occurred after the latest changes to weewx.conf? Look closely at the [StdReport] section, based on the weewx.conf you posted a few days ago it should now look something like:

[StdReport]
   
    # Where the skins reside, relative to WEEWX_ROOT
    SKIN_ROOT = skins
   
    # Where the generated reports should go, relative to WEEWX_ROOT
    HTML_ROOT = public_html
   
    # The database binding indicates which data should be used in reports.
    data_binding = wx_binding
   
    # Each of the following subsections defines a report that will be run.

   
    [[StandardReport]]
        # See the customizing guide to change the units, plot types and line
        # colors, modify the fonts, display additional sensor data, and other
        # customizations. Many of those changes can be made here by overriding
        # parameters, or by modifying templates within the skin itself.
       
        # The StandardReport uses the 'Standard' skin, which contains the
        # images, templates and plots for the report.
        skin = Standard

   
    [[SteelSeries]]
        skin = ss
        HTML_ROOT = public_html/ss
   
    [[FTP]]
        # FTP'ing the results to a webserver is treated as just another report,
        # albeit one with an unusual report generator!
        skin = Ftp
       
        # If you wish to use FTP, uncomment and fill out the next four lines.
        #user = replace with the ftp username
        #password = replace with the ftp password
        #server = replace with the ftp server name, e.g, www.threefools.org
        #path = replace with the ftp destination directory (e.g., /weather)
       
        # Set to True for a secure FTP (SFTP) connection. Not all servers
        # support this.
        secure_ftp = False
       
        # To upload files from something other than what HTML_ROOT is set
        # to above, specify a different HTML_ROOT here.
        #HTML_ROOT = public_html
       
        # Most FTP servers use port 21
        port = 21
       
        # Set to 1 to use passive mode, zero for active mode
        passive = 0
        max_tries = 3
        user = XXXXXX
        password = XXXXXX
        server = www.photokinetics.org
        path = photokinetics.org/Weather
   
    [[RSYNC]]

is that what you have or is it different? If you need to make changes do so, save then stop/start weeWX. If in doubt post a sanitised weewx.conf again.

Gary

[Steve2Q]

Gary..It's working properly again WITH the charts. Apparently what was happening is when I entered changes in the editor, they weren't being uploaded properly to the web server even though it said the transfer was completed. I think the editor was holding the unedited version in memory and just uploaded that.

Many thanks, Steve

[gjr80]

Steve, good to see. The other good outcome is that I should be able to touch up those original instructions I provided.

Gary