Hi Tom. When I saw that the key I had was no longer working, I went through
the steps as stated in your email to generate a new key (I have been
registered with WU as a PWS for several years). When I plugged this new key
into the rtgd configuration, I still had no info in the scroller. Maybe I
had
Hi Steve,
If you supply data to WU then you can get a new API from them. Gary has update
RTGD to use the new API and properly display the forecast on the LED ticker.
Here are the instructions for getting a new key:
> First, if you are not logged into Weather Underground, you will need to do
>
G'day Gary! Its been a while. As you know I was having a memory leak
problem which seems to be coming from the driver used with my Ultimeter.
Although the memory still increases, it is much less using an old version
rather than the one included with the Weewx update. Anyway, in trying to
track thin
On Thursday, 24 May 2018 09:20:00 UTC+10, gjr80 wrote:
>
> Yes, will be interesting to see. I have already started work on sourcing
> the forecast text from elsewhere. Would ideally like to support our own
> Bureau of Meteorology (not much use for those outside of Australia though)
> but unfortu
On Thursday, 24 May 2018 08:37:50 UTC+10, Steve2Q wrote:
>
> Gary..its working now!! Thank you. I plugged in my zipcode,
>
That's good to hear, ended up taking a bit longer than we thought but got
there in the end. I need to make sure I capture all of this in the rtgd
wiki.
> and also added
Gary..its working now!! Thank you. I plugged in my zipcode, and also added
units = us as it appears to default to metric. Now let see how long WU
keeps sending out the data!
Steve
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe f
Steve,
Apologies, I have not provided very much guidance on how to specify a
location. rtgd uses the same location formats as the forecast extension.
Any of the following should work:
- US state/city eg
location = CA/San_Francisco
- US zip code eg
location = 60290
- Country/City eg
Gary..I am giving the console a full 24 hours to check the clock. On this
subject, are the times shown on the tables on a weewx page derived from the
console clock? So for example the high wind occurs at time will be off
as much as the console clock is off? I would assume so as they are bei
On Sunday, 20 May 2018 08:16:34 UTC+10, Steve2Q wrote:
>
> Hi Gary..I did the upgrade to 3.8.0 and so far all is well. I will have to
> check the clock on my console (Peet Bros Ultimeter) after 24 hours or so to
> see if the autocorrection in the driver is working. Up till now, I have
> been us
Hi Gary..I did the upgrade to 3.8.0 and so far all is well. I will have to
check the clock on my console (Peet Bros Ultimeter) after 24 hours or so to
see if the autocorrection in the driver is working. Up till now, I have
been using an older version of the Ultimeter driver as the newer ones did
Well, some of the problem may have been typos on my end. I know just enough
about Linux to be dangerous. While i have no problem with weewx and have
nothing but kudos for you, Tom, Andrew, Vince and others that spend so much
time helping, I always thought it would be nice if there was some
"cookboo
Yes, appears to be working. Whilst upgrading the SteelSeries Gauges themselves
threw the spanner in the works this time, upgrading the Gauges and rtgd should
haven far easier than it was, will look at that. Re WU, if you have an API key
it will work, for the time being, if you don't have an API
THANK YOU!! Every thing looks great now. My next step will be to do the
upgrade of Weewx itself (I still haven't convinced myself it I should). As
for the banner in the Steel Gauges; I was thinking of activating the
section to show forecasts from WU, but from reading some other posts, it
seems
Steve,
Looking at gauges.js all I think you need do is change the realTimeUrlWeewx
setting so that it picks up you rtgd generated gauge-data.txt in the gauges
directory, perhaps setting it to '../gauges/gauge-data.txt'
Make sure you make the change to gauges.js in your skins/ss/scripts director
Hi Gary..I'm back! Finally got the web server back on line. All I have done
so far was to change gauges.js to change the update internal from 15
seconds to 2, added the wind rose, and deleted the two solar gauges. As you
can see, there are still problems, but I am not going to touch anything
el
Ok Steve, we are having a bad run here. I will wait to hear from you.
Gary
On Wednesday, 16 May 2018 07:47:42 UTC+10, Steve2Q wrote:
>
> Gary..the install went properly with the 2.6.3 extension listed. Gauges.js
> also says it it is 2.6.3. Unfortunately, my web server crashed this AM, so
> unti
Gary..the install went properly with the 2.6.3 extension listed. Gauges.js
also says it it is 2.6.3. Unfortunately, my web server crashed this AM, so
until I get it back up I wont be able to run further tests. I will let you
know when it is back up.
Steve
--
You received this message because
Gary..thanks. I will try tomorrow (almost midnight here). I may have left
off the = sign. I didn't know about the "--dry run" switch..I'll give that
a go first.
Steve
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group
I prefer to use full paths when running the utilities and passing files. I
would use (I run a setup.py install)
$ /home/weewx/bin/wee_extension --install=/path/to/extension_file/
steelseries-2.6.3.tar.gz
or for a .deb or dpkg install
$ /usr/share/weewx/wee_extension --install=/path/to/extension
As a follow up...I may have not used the correct syntax when I tried the
install. How do I make sure that it goes to the proper directory/s?
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails
Gary: you are correct, the versions installed are not 2.6.3. If I go
through the usual extension installation, should this install the correct
version?
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop recei
Steve,
Just noticed some odd version numbers in some scripts. I can look at your
gauges.js at http://www.photokinetics.org/Weather/ss/scripts/gauges.js and
it says gauges.js is version 2.5.1 (circa line 33). The weewx-steelseries
extension contains v2.6.3 and the current release version on the
Gary; Here are the settings:
# Options for extension 'Rtgd'
[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]]
Gary; here are the settings:
# Options for extension 'Rtgd'
[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]]
Steve,
I used your data file on my gauges page and it works fine, so I know
gauge-data.txt is OK. It will be a mis-configuration somewhere I suspect.
Could you post your [RealtimeGaugeData] config settings from weewx.conf, I
know you posted it earlier but we have since added a few settings to
Steve, I wouldn't be too worried about weeWX. WeeWX will leave bin/user and
your skins alone, the biggest issue is whether any changes in the weeWX code
base might break any extras/addons but there really have not been any earth
shattering changes between 3.6.2 and 3.8.0 so should be smooth sail
No problem, Gary. Once we, or should I say you, get this fixed..I'll be a
bit apprehensive about updating Weewx itself. But, I'll probably do it.
On Mon, May 14, 2018, 8:12 PM gjr80 wrote:
> Just looked at the file myself and it is valid JSON so am not sure what
> the gauges are choking on. Am o
Just looked at the file myself and it is valid JSON so am not sure what the
gauges are choking on. Am out at the moment and need to get on my desktop
rather than this iPad. Give us an hour or two and I will be home.
Gary
--
You received this message because you are subscribed to the Google Gro
Gary, I tried that this AM, and that gives me an error visible in the
scroll bar; .parse error at line 1 column 1...
Steve
--
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, s
Steve,
Ok, we were looking for gauge-data.txt in the wrong place. In
skins/ss/scripts/gauges.js locate the realTimeUrlWeewx setting and add gauges/
before gauge-data.txt at the end of the line. You will probably have something
like:
realTimeUrlWeewx = '../gauges/gauge-data.txt';
Save, stop, s
Gary, I am not sure if this info will help, but I decided to check what is
happening on the web server. Maybe this will be of some value.
I found there are 3 gauge-data.txt files. The first one is in
/photokinetics/Weather. It updates every 2 minutes with a file size of
1,511.
The second is in
Gary..here is syslog from 2225 thru 2226:
May 13 22:25:00 raspi2 weewx[6840]: engine: Initializing weewx version 3.6.2
May 13 22:25:00 raspi2 weewx[6840]: engine: Using Python 2.7.3 (default,
Jun 22 2016, 03:14:32) #012[GCC 4.6.3]
May 13 22:25:00 raspi2 weewx[6840]: engine: Platform
Linux-4.9.33
Ok, so the issue is the posting to your web server. Edit weewx.conf and set
debug=1, save then stop/start weeWX. Monitor the log, there should be some
debug info posted once the startup is complete and on each post to your web
server. Can you post a log extract, no need to wait for a report cycl
Gary; commenting out the [[forecast]] stanza did the trick..no more errors.
I checked 3 gauge-data.txt files I opened in rapid succession, and yes, the
timeUTC is different on each one, so it is being generated.
Steve
--
You received this message because you are subscribed to the Google Groups
Ok, those errors are due to the forecast skin, for the purposes of getting the
gauges working you can either ignore them (they have no effect on the gauges)
or you can comment out the [[forecast]] stanza and its settings in weewx.conf.
Did you check if public_html/gauge-data.txt is being regular
Gary: here it is:
[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.
dat
That indicates an error under [StdReport] in weewx.conf, can you post
[StdReport]?
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+unsubscr...@go
Gary: I just did a running log (sudo tail -f /var/log/syslog) and it
contains lots of errors. Following is a snip...should I set weewx.conf
debug -1 and let it run for an archive period??
May 13 20:52:10 raspi2 weewx[22216]: self.run()
May 13 20:52:10 raspi2 weewx[22216]:
Yes, not updating as it should. Let's take a step back and confirm
gauge-data.txt is being generated as often as it should. Have a look at
public_html/gauge-data.txt on your weeWX machine (not the web server), is it
being updated every few seconds? The last 3 groups in timeUTC should tell you
w
Gary: I copied the lines from the backup weewx.conf file, but that did not
seem to make a difference.
Under [[FTP]] is:
# 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
Steve,
I don't think that file is significant.
Do you recall how you were getting the rtgd generated huge-data.txt from your
weeWX machine to your web server? I am guessing these are separate machines?
Were you using post_gauge-data.php to do the transfer via http post? If you
were doing it th
Gary: another observation that may be important: there is a gauge-data.txt
file on my internet server, but it has not been updated since this AM.
Steve
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop recei
Gary:
I changed the realTimeUrlWeewx option to '../gauge-data.txt' This has
made things better, but I still (as you observed) have a 2 minute update
period (= archive period), and I still don't have the windrose gauge even
though I have the settings as true. I cannot find a setting in weewx.c
Steve,
Wasn't aware you were updating the SteelSeries Gauges themselves (via the
SteelSeries extension), thought you were just upgrading weeWX and the realtime
gauge data extension. When upgrading the SteelSeries Gauges themselves there
are a few extra steps involved and it's likely this is the
Gary..well I must have messed something up. Now my update period is correct
(2 seconds) but as you can see, the temp gauges are going crazy, while the
wind gauges are stuck. Also, the wind rose is gone. At least I got rid of
the two unused solar gauges!
Is it possible that the [[SteelSeries]] e
Gary..first I installed (using wee_extension) SteelSeries v 2.6.3. Now my
gauges are working (sort of; I have two; UV and Solar radiation that I
don't need, and temperature goes from -1800 to 2000 degrees!!), and next I
will install rtgd. I'll let you know how that goes.
Steve
--
You received
Gary
First I made backups of all files including my steelgauges directory. I
then downloaded steelseries-2.6.3.tar.gz to my Raspberry Pi. I can only
download files into the /home/pi directory. I then logged in using Putty
and ran the following command:
/home/weewx/bin/wee_extension --install /
Yep, been there done that...
As for upgrading realtime gauge data, given the version differences I would
uninstall then install the newer version. You will lose any customisation
you may have done to [RealtimeGaugeData] in weewx.conf, but that is easy
enough to fix, the installer should have ke
Gary...stupid me...that is what happens when I try to do this at
midnight!! Thanks.
To upgrade to the newest data extension for steel gauges, do I just
download and install the newest version or do I have to uninstall anything
first? I will do this before updating Weewx itself (and I won't do
On Sunday, 13 May 2018 13:14:53 UTC+10, Steve2Q wrote:
>
> Gary..my version of RTGD.py is 0.2.13
>
Definitely worth upgrading, big change is ability to display WU forecast
text in the scroller
> I assume (maybe incorrectly) that to start fresh with forecasting I should
> uninstall the extens
Gary..my version of RTGD.py is 0.2.13
I assume (maybe incorrectly) that to start fresh with forecasting I should
uninstall the extension. I first ran wee-extension --list which says that I
have
forecast 3.2.14 installed.
I then ran wee-extension --uninstall forecast and I get the following:
Steve,
On Sunday, 13 May 2018 12:46:17 UTC+10, Steve2Q wrote:
>
> Gary..thank you. Not sure which version of the realtime gauge data
> extension I have. Cn you tell how to find it?
>
Have a look for the RTGD_VERSION variable declaration in rtgd.py, about
line 420 after the comments. It is set t
Gary..thank you. Not sure which version of the realtime gauge data
extension I have. Cn you tell how to find it?
Another question on a different topic. Where can I find the most recent
version of weewx-forecast-x.x.xx.tgz? The one I downloaded a long time ago
is 3.2.14. Also, is there a descriptio
Hi Steve,
You appear to be still using the realtime gauge data extension to drive the
SteelSeries Gauges, it will continue to work fine under 3.8.0. Not sure
what version of the realtime gauge data extension you are using but I would
be using at least v0.3.2 as that release fixed an issue that
54 matches
Mail list logo
