Question about latitude/longitude

[k_her...@yahoo.com]

weewx is running great, however on the index.html page the latitude and longitude are incorrect for my location. weewx.conf has latitude at 34.010731 and longitude as -96.425720 which is my station location.The web page shows lat. as 34° 00.60' and long. 096° 25.50' W.

I can change it to another location and it still reports incorrect.

Any suggestions? 

Keith

[gjr80]

Hi,

I am not quite understanding your problem. weewx.conf uses decimal lat/long, positive lat for northern hemisphere, negative for southern. Positive longtitude for east and negative for west. index.html will display degrees and decimal minutes. The figures you quote are a few hundredths of a minute out, is that the problem?

Gary

[k_her...@yahoo.com]

Hi Gary,

I guess no major problem, about 15 or so miles from here, just like things to look right. Thought I might be inputting the info wrong.

By the way, I've been reading a lot in the group and really appreciate all your work and patients.

Keith

[gjr80]

On Tuesday, 9 January 2018 18:34:13 UTC+10, k_her...@yahoo.com wrote:

Hi Gary,

I guess no major problem, about 15 or so miles from here, just like things to look right. Thought I might be inputting the info wrong.

Understand Keith, weeWX should be converting decimal degrees to degrees and decimal minutes much more accurate than that. I will have a look to see what the code is doing, though I doubt anything has changed with the lat/long conversion. Out of interest which weeWX version are you using?

Gary

[gjr80]

Keith,

I looked at the lat long code and no change for well over a year, its pretty simple and appears functional to me. On my site I am using 6 digit decimal lat/long and my displayed values are spot on to at least 1/100th of a minute. I just ran up a VM with weeWX 3.8.0 and put in latitude = 34.010731 longtitude = -96.425720 and index.html displays

Latitude:	34° 00.64' N
Longitude:	096° 25.54' W

which is slightly different to your results. Are you sure that you have those figures you listed in your first post set in weewx.conf? You did stop then start weeWX or do a config reload after changing any weewx.conf setting didn't you? You can do a wee_debug run and post the output, that will show us the weewx.conf that weeWX is using (in case there is more than one or you have an editor problem). Not too much else I can think of off hand. Does not appear to be a problem with the weeWX code though.

Gary

[k_her...@yahoo.com]

Gary,

I'm running 3.8.0 on a Mac. I ran debug and have attached the output results. 

   I did have SteelSeries gauges working with weewx  but tried to set up the realtime updates  and screwed something up and killed weewx. So I started over. The instructions for long polling is a little confusing to me. I'm fairly new (relatively speaking) to this whole thing of terminal, paths and permissions but stumbling along. I was running wview with ss-gauges for about 3 years. Did some code changes to add some different gauges and that was trial and error but got it working with some help from other users.

  Decided to give weewx a try and been very pleased with the outcome.

Thanks again.

Keith

[gjr80]

None of those things should really mess with something as fundamental as lat and long in weewx.conf. If you have been making substantial changes to weewx.conf and/or editing the Standard skin config file (skins/Standard/skin.conf) then you could cause lat long problems, though any changes in skin.conf would more likely be a formatting problem not one of accuracy.

Also, did you mean to attach something?

Gary

[k_her...@yahoo.com]

Yes I did. Here it is!

I haven't edited any thing in the skin.conf file. 

I thought that something like lat and long would be fairly simple. In my previous wview installation, it was spot on. As a matter of fact I had ran weewv for about a week to 10 days before I noticed it.

Keith

[Glenn McKechnie]

Keith,

What I see at http://www.herriage.com/weewx/ are the values that Gary gets

About this weather station:
Location

Latitude: 34° 00.64' N
Longitude: 096° 25.54' W

Altitude: 685 feet

using the values from your weedebug.txt file.

latitude = 34.010731
longitude = -96.425720

Browser caching? Fonts? Gremlins?



Cheers
Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie


On 10 January 2018 at 18:40, k_herriage via weewx-user

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

[k_her...@yahoo.com]

Gleen,

Yes, that's what i get. I made a typo in the original post.

Keith

[k_her...@yahoo.com]

Gary,

My apologies for not seeing the forest for the trees.

After I found a formula for decoding decimal degrees to deg, min, seconds what you said was correct. What I hadn't noticed was the 00.64'. This was in minutes, not minutes and seconds as wview was.

Sorry for my lack of attention to details.

At almost 71 yr old, I get distracted easily. :-)

Have gauges working, now starting on realtime gauges.

Thanks again for trying to set me straight.

Keith

 

On Tuesday, January 9, 2018 at 12:21:17 PM UTC-6, gjr80 wrote:

[gjr80]

No problems Keith, plenty of younger folk here miss things just as plain :)

Gary

[k_her...@yahoo.com]

Thanks Gary,

I have started working on rtgd and have a few questions.

1. in the gauge.js located in weewx/skins/ss/scripts directory where the comment says to change to the location of the gauge-data.txt. How do I do this? I tried the full path from /Users/keith/Sites/weewx to either  gauge-data.txt in public_html and public_html/ss but it kills gauges.

2. in the github download i pulled down a post_gauge-data.php file along with the tar.gz . Where do I put this or do I not need it?  I haven't seen it mentioned anywhere.

Probably dumb questions but it kinda has me stuck.

Also, out of curiosity, where do you live?

Keith

[gjr80]

Keith, some answers below

On Monday, 15 January 2018 18:06:34 UTC+10, k_her...@yahoo.com wrote:

Thanks Gary,

I have started working on rtgd and have a few questions.

1. in the gauge.js located in weewx/skins/ss/scripts directory where the comment says to change to the location of the gauge-data.txt. How do I do this? I tried the full path from /Users/keith/Sites/weewx to either  gauge-data.txt in public_html and public_html/ss but it kills gauges.

The realTimeUrlWeewx setting in gauges.js needs to be set so that your webserver can find gauge-data.txt. You can use a relative or absolute path but remember that any absolute path is relative to your web root (not the root directory of your web server). So if you web server is set to use /var/www/html as its web root and gauge-data.txt is in the /var/www/html/ss directory you could use '/ss/gauge-data.txt'. If you want to use a relative path for realTimeUrlWeewx then the path is relative to gauges.js (which by default is in the ss/scripts directory in your web root) and you might use '../gauge-data.txt'. Its a personal choice (though I am sure some will have good reason for one or the other), I tend to prefer relative paths but it really is your choice.

 

2. in the github download i pulled down a post_gauge-data.php file along with the tar.gz . Where do I put this or do I not need it?  I haven't seen it mentioned anywhere.

post_gauge-data.php is only used if your web server and weeWX are on different machines AND you wish to use http post to transfer gauge-data.txt to from your weeWX machine to your web server. If this is not the case then you can ignore post_gauge-data.php as it is not needed. If your weeWX and web servers are different machines let me know and I will talk you through its use.

Probably dumb questions but it kinda has me stuck.

Also, out of curiosity, where do you live?

I am just outside of Brisbane, Australia. 

Gary

[k_her...@yahoo.com]

Thanks Gary,

That was what I was doing wrong. I'll fix and see how it goes.

I was wondering why that .php file wasn't in the gz directory. Ok so now I know.

You probably know from the earlier past of my lat and long, but I'm in Oklahoma. USA

Keith

[gjr80]

I did have a look when the the lat/long issue first came up. I guess we weren't too far away a while back, 2 years ago we flew into Dallas for New Year, bit of a climate shock after mid-summer in Australia.

Gary

[k_her...@yahoo.com]

Gary,

That's about 100 miles south of here. You would really be shocked now. The low last night here was 8.7° F. 

I have some more questions, first a little background.

I’m using a iMac running High Sierra 10.13.2.

I have weewx running well and some rtgd working so-so.

The firs thing. I’ve seen in several post about showing what the log files displays. I’m assuming System log. I see very little in the log file other than when I start and stop and when the data base is up dated every 5 mins.

If i do ‘ ps aux|grep weewx ‘  results in 

root              1236 100.1  0.2  4401200  70564   ??  Rs    7:36AM 207:32.45 /usr/bin/python /Users/keith/Sites/weewx/bin/weewxd /Users/keith/Sites/weewx/weewx.conf

‘ top ‘ = python running but nothing else for weewx.

If I run ‘tail -f /private/var/log/system.log’ in one terminal window and start weewx in another window, I only see when I start weewx and like any data that needs to be updated in weewx sdb. I don’t know how to look at everything that’s loading as i’ve seen in some posts. Maybe I’m not looking at the correct log.

Now as for as getting rtgd up and going. After getting the steel series running well then install rtgd as mentioned before. I set the realTimeUrlWeewx file (like you explained before) to ‘/ss/gauge-data.txt’ and that kills gauges. All gauges return to the ‘0’ position(fully CCW).

I tried ‘ss/gauge-data.txt’ and ‘../gauge-data.txt’ but the same results. If I leave it as ‘gauge-data.txt’ the file is updated in public_html. the data file in public_html/ss is up dated also but they appear different. I guess that because only the changed data in placed there. The gauges do update but instead of 2.5 sec. as I have set in realtiemInterval, it only updated ever 5 mins.

I’m sure I have multiple things wrong but I all looks correct.

AND just one more question. Does the [RealtimeGaugeData] info go at the end of weewx.conf or some other location?

Sorry for the long post and the many questions!!!

Keith

[gjr80]

On Thursday, 18 January 2018 03:46:09 UTC+10, k_her...@yahoo.com wrote:

That's about 100 miles south of here. You would really be shocked now. The low last night here was 8.7° F.

Yes, a bit cooler, think we had days of about 10C and around 0C overnight while in Dallas.

 

I’m using a iMac running High Sierra 10.13.2.

I'll be up front here, Macs are foreign to me, my daughter has one and the few occassions I have ever touched it I have struggled to do the basics. WeeWX should be the leveller though, as a lot of weeWX is the same whether it is Mac or PC, though I think log locations are a little different....

I have weewx running well and some rtgd working so-so.

The firs thing. I’ve seen in several post about showing what the log files displays. I’m assuming System log. I see very little in the log file other than when I start and stop and when the data base is up dated every 5 mins.

If i do ‘ ps aux|grep weewx ‘  results in 

root              1236 100.1  0.2  4401200  70564   ??  Rs    7:36AM 207:32.45 /usr/bin/python /Users/keith/Sites/weewx/bin/weewxd /Users/keith/Sites/weewx/weewx.conf

‘ top ‘ = python running but nothing else for weewx.

If I run ‘tail -f /private/var/log/system.log’ in one terminal window and start weewx in another window, I only see when I start weewx and like any data that needs to be updated in weewx sdb. I don’t know how to look at everything that’s loading as i’ve seen in some posts. Maybe I’m not looking at the correct log.

Half the battle in monitoring your logs is finding where the data is going. Under linux that is /var/log/syslog by default, though there are instructions in the wiki on how to change this to another file (the example uses /var/log/weewx.log) so these are the two obvious places to look, under linux. I believe the Mac is the same but the location is different. You appear to have found the location, /private/var/log/system.log, and are doing the right thing in monitoring it with tail in another terminal window. If I read correctly, you are seeing the weeWX startup and data being updated in weewx.sdb (and I presume the reports being run and the plots being generated). Probably something like this:

Jan 18 11:57:27 stretch22 weewx[16365]: engine: Initializing weewx version 3.8.0a1
Jan 18 11:57:27 stretch22 weewx[16365]: engine: Using Python 2.7.13 (default, Nov 24 2017, 17:33:09) #012[GCC 6.3.0 20170516]
Jan 18 11:57:27 stretch22 weewx[16365]: engine: Platform Linux-4.9.0-5-amd64-x86_64-with-debian-9.3
Jan 18 11:57:27 stretch22 weewx[16365]: engine: Locale is 'en_AU.UTF-8'
Jan 18 11:57:27 stretch22 weewx[16365]: engine: pid file is /var/run/weewx.pid
Jan 18 11:57:27 stretch22 weewx[16355]: Starting weewx weather system: weewx.
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Using configuration file /home/weewx/weewx.conf
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Loading station type Simulator (weewx.drivers.simulator)
Jan 18 11:57:27 stretch22 weewx[16369]: engine: StdConvert target unit is 0x1
Jan 18 11:57:27 stretch22 weewx[16369]: wxcalculate: The following values will be calculated: barometer=prefer_hardware, windchill=prefer_hardware, dewpoint=prefer_hardware, appTemp=prefer_hardware, rainRate=prefer_hardware, windrun=prefer_hardware, heatindex=prefer_hardware, maxSolarRad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware, inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, cloudbase=prefer_hardware
Jan 18 11:57:27 stretch22 weewx[16369]: wxcalculate: The following algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Archive will use data binding wx_binding
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Record generation will be attempted in 'hardware'
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Using archive interval of 300 seconds (specified in weewx configuration)
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Using binding 'wx_binding' to database 'weewx.sdb'
Jan 18 11:57:27 stretch22 weewx[16369]: manager: Starting backfill of daily summaries
Jan 18 11:57:27 stretch22 weewx[16369]: restx: StationRegistry: Registration not requested.
Jan 18 11:57:27 stretch22 weewx[16369]: restx: Wunderground: Posting not enabled.
Jan 18 11:57:27 stretch22 weewx[16369]: restx: PWSweather: Posting not enabled.
Jan 18 11:57:27 stretch22 weewx[16369]: restx: CWOP: Posting not enabled.
Jan 18 11:57:27 stretch22 weewx[16369]: restx: WOW: Posting not enabled.
Jan 18 11:57:27 stretch22 weewx[16369]: restx: AWEKAS: Posting not enabled.
Jan 18 11:57:27 stretch22 weewx[16369]: rtgd: RealTimeGaugeData will generate gauge-data.txt. min_interval is None
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Starting up weewx version 3.8.0a1
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Clock error is -0.03 seconds (positive is fast)
Jan 18 11:57:27 stretch22 weewx[16369]: engine: Starting main packet loop.
Jan 18 12:00:14 stretch22 weewx[16369]: manager: Added record 2018-01-18 12:00:00 AEST (1516240800) to database 'weewx.sdb'
Jan 18 12:00:14 stretch22 weewx[16369]: manager: Added record 2018-01-18 12:00:00 AEST (1516240800) to daily summary in 'weewx.sdb'
Jan 18 12:00:16 stretch22 weewx[16369]: cheetahgenerator: Generated 14 files for report StandardReport in 1.18 seconds
Jan 18 12:00:18 stretch22 weewx[16369]: imagegenerator: Generated 49 images for StandardReport in 1.81 seconds
Jan 18 12:00:18 stretch22 weewx[16369]: copygenerator: copied 14 files to /home/weewx/public_html

To see details of what is being loaded etc during the weeWX startup we need to raise the debug level from 0 to 1, in weewx.conf locate the line debug = 0 and change it from 0 to 1. Save the file then stop then start weeWX. You should now see a lot more detail in your log, similar to:

Jan 18 12:01:22 stretch22 weewx[16427]: engine: Initializing weewx version 3.8.0a1
Jan 18 12:01:22 stretch22 weewx[16427]: engine: Using Python 2.7.13 (default, Nov 24 2017, 17:33:09) #012[GCC 6.3.0 20170516]
Jan 18 12:01:22 stretch22 weewx[16427]: engine: Platform Linux-4.9.0-5-amd64-x86_64-with-debian-9.3
Jan 18 12:01:22 stretch22 weewx[16427]: engine: Locale is 'en_AU.UTF-8'
Jan 18 12:01:22 stretch22 weewx[16427]: engine: pid file is /var/run/weewx.pid
Jan 18 12:01:22 stretch22 weewx[16417]: Starting weewx weather system: weewx.
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Using configuration file /home/weewx/weewx.conf
Jan 18 12:01:22 stretch22 weewx[16431]: engine: debug is 1
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Initializing engine
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading station type Simulator (weewx.drivers.simulator)
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.engine.StdTimeSynch
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.engine.StdTimeSynch
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.engine.StdConvert
Jan 18 12:01:22 stretch22 weewx[16431]: engine: StdConvert target unit is 0x1
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.engine.StdConvert
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.engine.StdCalibrate
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.engine.StdCalibrate
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.engine.StdQC
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.engine.StdQC
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.wxservices.StdWXCalculate
Jan 18 12:01:22 stretch22 weewx[16431]: wxcalculate: The following values will be calculated: barometer=prefer_hardware, windchill=prefer_hardware, dewpoint=prefer_hardware, appTemp=prefer_hardware, rainRate=prefer_hardware, windrun=prefer_hardware, heatindex=prefer_hardware, maxSolarRad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware, inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, cloudbase=prefer_hardware
Jan 18 12:01:22 stretch22 weewx[16431]: wxcalculate: The following algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.wxservices.StdWXCalculate
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.engine.StdArchive
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Archive will use data binding wx_binding
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Record generation will be attempted in 'hardware'
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Using archive interval of 300 seconds (specified in weewx configuration)
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Use LOOP data in hi/low calculations: 1
Jan 18 12:01:22 stretch22 weewx[16431]: manager: Daily summary version is 2.0
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Using binding 'wx_binding' to database 'weewx.sdb'
Jan 18 12:01:22 stretch22 weewx[16431]: manager: Starting backfill of daily summaries
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.engine.StdArchive
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.restx.StdStationRegistry
Jan 18 12:01:22 stretch22 weewx[16431]: restx: StationRegistry: Registration not requested.
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.restx.StdStationRegistry
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.restx.StdWunderground
Jan 18 12:01:22 stretch22 weewx[16431]: restx: Wunderground: Posting not enabled.
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.restx.StdWunderground
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.restx.StdPWSweather
Jan 18 12:01:22 stretch22 weewx[16431]: restx: PWSweather: Posting not enabled.
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.restx.StdPWSweather
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.restx.StdCWOP
Jan 18 12:01:22 stretch22 weewx[16431]: restx: CWOP: Posting not enabled.
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.restx.StdCWOP
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.restx.StdWOW
Jan 18 12:01:22 stretch22 weewx[16431]: restx: WOW: Posting not enabled.
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.restx.StdWOW
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.restx.StdAWEKAS
Jan 18 12:01:22 stretch22 weewx[16431]: restx: AWEKAS: Posting not enabled.
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.restx.StdAWEKAS
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.engine.StdPrint
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.engine.StdPrint
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service weewx.engine.StdReport
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service weewx.engine.StdReport
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Loading service user.rtgd.RealtimeGaugeData
Jan 18 12:01:22 stretch22 weewx[16431]: manager: Daily summary version is 2.0
Jan 18 12:01:22 stretch22 weewx[16431]: rtgd: RealTimeGaugeData will generate gauge-data.txt. min_interval is None
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Finished loading service user.rtgd.RealtimeGaugeData
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Starting up weewx version 3.8.0a1
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Clock error is -0.04 seconds (positive is fast)
Jan 18 12:01:22 stretch22 weewx[16431]: engine: Starting main packet loop.
Jan 18 12:01:22 stretch22 weewx[16431]: manager: Daily summary version is 2.0
Jan 18 12:01:22 stretch22 weewx[16431]: manager: Daily summary version is 2.0
Jan 18 12:01:22 stretch22 weewx[16431]: rtgdthread: Zambretti is installed: False
Jan 18 12:05:15 stretch22 weewx[16431]: manager: Added record 2018-01-18 12:05:00 AEST (1516241100) to database 'weewx.sdb'
Jan 18 12:05:15 stretch22 weewx[16431]: manager: Added record 2018-01-18 12:05:00 AEST (1516241100) to daily summary in 'weewx.sdb'
Jan 18 12:05:15 stretch22 weewx[16431]: reportengine: Running reports for latest time in the database.
Jan 18 12:05:15 stretch22 weewx[16431]: reportengine: Running report StandardReport
Jan 18 12:05:15 stretch22 weewx[16431]: reportengine: Found configuration file /home/weewx/skins/Standard/skin.conf for report StandardReport
Jan 18 12:05:15 stretch22 weewx[16431]: cheetahgenerator: using search list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']
Jan 18 12:05:15 stretch22 weewx[16431]: manager: Daily summary version is 2.0
Jan 18 12:05:16 stretch22 weewx[16431]: cheetahgenerator: Generated 14 files for report StandardReport in 1.10 seconds
Jan 18 12:05:16 stretch22 weewx[16431]: manager: Daily summary version is 2.0
Jan 18 12:05:16 stretch22 weewx[16431]: imagegenerator: Generated 12 images for StandardReport in 0.17 seconds
Jan 18 12:05:16 stretch22 weewx[16431]: copygenerator: copied 14 files to /home/weewx/public_html
Jan 18 12:05:16 stretch22 weewx[16431]: reportengine: Running report FTP
Jan 18 12:05:16 stretch22 weewx[16431]: reportengine: Found configuration file /home/weewx/skins/Ftp/skin.conf for report FTP
Jan 18 12:05:16 stretch22 weewx[16431]: ftpgenerator: FTP upload not requested. Skipped.
Jan 18 12:05:16 stretch22 weewx[16431]: reportengine: Running report RSYNC
Jan 18 12:05:16 stretch22 weewx[16431]: reportengine: Found configuration file /home/weewx/skins/Rsync/skin.conf for report RSYNC
Jan 18 12:05:16 stretch22 weewx[16431]: rsyncgenerator: rsync upload not requested. Skipped.

Some drivers/extensions support debug = 2 or 3, this provides more detail, usually details of low level data being handled by the driver/extension. Seldom required except when developing or troubleshooting.

Now as for as getting rtgd up and going. After getting the steel series running well then install rtgd as mentioned before. I set the realTimeUrlWeewx file (like you explained before) to ‘/ss/gauge-data.txt’ and that kills gauges. All gauges return to the ‘0’ position(fully CCW).

I tried ‘ss/gauge-data.txt’ and ‘../gauge-data.txt’ but the same results. If I leave it as ‘gauge-data.txt’ the file is updated in public_html. the data file in public_html/ss is up dated also but they appear different. I guess that because only the changed data in placed there. The gauges do update but instead of 2.5 sec. as I have set in realtiemInterval, it only updated ever 5 mins.

I’m sure I have multiple things wrong but I all looks correct.

I think before we go on to sort out the gauges it would help to get a clear picture of what weeWX is doing. Could you post a copy of your weewx.conf, sanitised of any sensitive info. wee_debug can do this for you, but check its output before posting, its good but not perfect. Also, if you get that startup log working with debug = 1 posting a copy of that log from weeWX startup for say about 10 minutes worth of activity would be helpful too.

AND just one more question. Does the [RealtimeGaugeData] info go at the end of weewx.conf or some other location?

It really doesn't matter, as long as it does not appear in the middle of another [xxxxx] config section. The extension installer will typically place new [xxxxx] sections at the end of the file.

Sorry for the long post and the many questions!!!

Don't worry about that, you will find people here are happy to help where they can.

Gary

[k_her...@yahoo.com]

Gary,

I get nothing like you log post.  I have looked at everything in /private/var/log and only system.log had anything and that was very little.

Example 

Here’s where I stop weewx with debug set to 0 or 1

Jan 18 00:04:40 Keiths-new-iMac sudo[2691]:    keith : TTY=ttys001 ; PWD=/Users/keith/Sites/weewx ; USER=root ; COMMAND=/bin/launchctl unload /Library/LaunchDaemons/com.weewx.weewxd.plist

Jan 18 00:04:40 Keiths-new-iMac com.apple.xpc.launchd[1] (com.weewx.weewxd[1236]): Service exited with abnormal code: 1

restarted it here, still with debug = 0 or 1 

Jan 18 00:04:49 Keiths-new-iMac sudo[2693]:    keith : TTY=ttys001 ; PWD=/Users/keith/Sites/weewx ; USER=root ; COMMAND=/bin/launchctl load /Library/LaunchDaemons/com.weewx.weewxd.plist

Jan 18 00:05:16 Keiths-new-iMac weewx[2695]: manager: Added record 2018-01-18 00:05:00 CST (1516255500) to database 'weewx.sdb'

Jan 18 00:05:16 Keiths-new-iMac weewx[2695]: manager: Added record 2018-01-18 00:05:00 CST (1516255500) to daily summary in 'weewx.sdb'

Just no difference. That is what has me confused.

Here is about 25 mins. of the system.log (I removed some apple system stuff) No matter what debug is set to. This listing is with debug = 1

Jan 18 00:35:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:35:00 CST (1516257300) to database 'weewx.sdb'

Jan 18 00:35:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:35:00 CST (1516257300) to daily summary in 'weewx.sdb'

Jan 18 00:40:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:40:00 CST (1516257600) to database 'weewx.sdb'

Jan 18 00:40:16 Keiths-new-iMac syslogd[57]: ASL Sender Statistics

Jan 18 00:40:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:40:00 CST (1516257600) to daily summary in 'weewx.sdb'

Jan 18 00:45:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:45:00 CST (1516257900) to database 'weewx.sdb'

Jan 18 00:45:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:45:00 CST (1516257900) to daily summary in 'weewx.sdb'

Jan 18 00:50:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:50:00 CST (1516258200) to database 'weewx.sdb'

Jan 18 00:50:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:50:00 CST (1516258200) to daily summary in 'weewx.sdb'

Jan 18 00:55:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:55:00 CST (1516258500) to database 'weewx.sdb'

Jan 18 00:55:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 00:55:00 CST (1516258500) to daily summary in 'weewx.sdb'

Jan 18 01:00:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 01:00:00 CST (1516258800) to database 'weewx.sdb'

Jan 18 01:00:16 Keiths-new-iMac weewx[2729]: manager: Added record 2018-01-18 01:00:00 CST (1516258800) to daily summary in 'weewx.sdb'

The wee_debug output is attached. 

I going for a few more hours sleep and will check in the morning.

Thanks,

[gjr80]

Keith,

Hmm, that log is not very helpful. Like I said I know next to nothing of Macs, though on thinking some more I thought I remember someone else have issues obtaining logs on a Mac. Did some searching and I think this is the thread, not very encouraging when you read the last post in the thread. The macOS install instructions in the User's Guide mentions 'Run the Console application and select All Messages' to view the log, I guess you went to this section to do your install so I don't know if it will help.

Not to worry, let's work on weewx.conf. At the moment you have two copies of gauge-data.txt being produced; one copy is produced during each report cycle (ie every 5 minutes) by the weeWX SteelSeries Gauges skin and a second copy is produced by the realtime gauge data (rtgd) extension. The rtgd extensions produces a loop based gauge-data.txt every loop period. No problems with both being there, as long as they are not trying to write to the same location. Ultimately though, when we get the guages working with one or the other you should (at the very least) disable the other or uninstall it.

I would like to try to work out where the two gauge-data.txt files are being generated. I suspect the SteelSeries Gauges skin is placing gauge-data.txt in /Users/keith/Sites/weewx/public_html/ss, if so this file would be being updated every 5 minutes. I suspect that the rtgd extension should be placing gauge-data.txt in /Users/keith/Sites/weewx/public_html and this file would be being updated every 2 odd seconds. Can you confirm that these files are where I suspect and that they are being updated as stated? The files will be similar but have some differences as there are some fields in gauge-data.txt that the SteelSeries Gauges skins does not provide but the rtgd extension does.

Now as for as getting rtgd up and going. After getting the steel series running well then install rtgd as mentioned before. I set the realTimeUrlWeewx file (like you explained before) to ‘/ss/gauge-data.txt’ and that kills gauges. All gauges return to the ‘0’ position(fully CCW).

I tried ‘ss/gauge-data.txt’ and ‘../gauge-data.txt’ but the same results. If I leave it as ‘gauge-data.txt’ the file is updated in public_html. the data file in public_html/ss is up dated also but they appear different. I guess that because only the changed data in placed there. The gauges do update but instead of 2.5 sec. as I have set in realtiemInterval, it only updated ever 5 mins.

In trying various realTimeUrlWeewx settings did you find one that correctly displayed data on the gauges? If so what setting worked, I would have expected 'gauge-data.txt' to work.

Gary

[mwall]

On Thursday, January 18, 2018 at 2:31:14 AM UTC-5, k_herriage wrote:

I get nothing like you log post.  I have looked at everything in /private/var/log and only system.log had anything and that was very little.

system.log is the nominal place to look on macos, but what you find will depend on the macos version.  you might have to make adjustments to the system's logging settings before you get anything useful.

there is some discussion about macos system logging here:

https://groups.google.com/forum/#!searchin/weewx-user/macos|sort:date/weewx-user/nXXjPberp3Y/VQY233vPCQAJ

we probably need a wiki page to summarize the macos logging quirks and how to work with them...

m

[k_her...@yahoo.com]

Gary,

On Thursday, January 18, 2018 at 5:43:29 AM UTC-6, gjr80 wrote:

Keith,

Hmm, that log is not very helpful. Like I said I know next to nothing of Macs, though on thinking some more I thought I remember someone else have issues obtaining logs on a Mac. Did some searching and I think this is the thread, not very encouraging when you read the last post in the thread. The macOS install instructions in the User's Guide mentions 'Run the Console application and select All Messages' to view the log, I guess you went to this section to do your install so I don't know if it will help.

I ran Console / All Messages and it look pretty much the same as system.log

 

Not to worry, let's work on weewx.conf. At the moment you have two copies of gauge-data.txt being produced; one copy is produced during each report cycle (ie every 5 minutes) by the weeWX SteelSeries Gauges skin and a second copy is produced by the realtime gauge data (rtgd) extension. The rtgd extensions produces a loop based gauge-data.txt every loop period. No problems with both being there, as long as they are not trying to write to the same location. Ultimately though, when we get the guages working with one or the other you should (at the very least) disable the other or uninstall it.

I would like to try to work out where the two gauge-data.txt files are being generated. I suspect the SteelSeries Gauges skin is placing gauge-data.txt in /Users/keith/Sites/weewx/ 

public_html/ss, if so this file would be being updated every 5 minutes. I suspect that the rtgd extension should be placing gauge-data.txt in /Users/keith/Sites/weewx/public_html and this file would be being updated every 2 odd seconds. Can you confirm that these files are where I suspect and that they are being updated as stated? The files will be similar but have some differences as there are some fields in gauge-data.txt that the SteelSeries Gauges skins does not provide but the rtgd extension does.

Yes, your right on both locations. I was hoping to use both so as to have the standard on one web page and realtime on another. I've seen that on a couple to sites. 

 Now as for as getting rtgd up and going. After getting the steel series running well then install rtgd as mentioned before. I set the realTimeUrlWeewx file (like you explained before) to ‘/ss/gauge-data.txt’ and that kills gauges. All gauges return to the ‘0’ position(fully CCW).

I tried ‘ss/gauge-data.txt’ and ‘../gauge-data.txt’ but the same results. If I leave it as ‘gauge-data.txt’ the file is updated in public_html. the data file in public_html/ss is up dated also but they appear different. I guess that because only the changed data in placed there. The gauges do update but instead of 2.5 sec. as I have set in realtiemInterval, it only updated ever 5 mins.

In trying various realTimeUrlWeewx settings did you find one that correctly displayed data on the gauges? If so what setting worked, I would have expected 'gauge-data.txt' to work.

Yes, 'gauge-data.txt works just updates the gauges every 5 mins.

I was looking at my Sites/logs/access.log where I have apache reporting and it was doing this...

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/index.html HTTP/1.1" 200 9749

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/css/gauges-ss.css HTTP/1.1" 200 15722

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/scripts/language.min.js HTTP/1.1" 200 79862

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/scripts/RGraph.rose.min.js HTTP/1.1" 200 21244

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/scripts/RGraph.common.core.min.js HTTP/1.1" 200 36577

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/scripts/steelseries_tween.min.js HTTP/1.1" 304 -

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/scripts/gauges.js HTTP/1.1" 304 -

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787619 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/dayinouttemp.png?1516281787763 HTTP/1.1" 200 4075

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/dayouttemphum.png?1516281787763 HTTP/1.1" 200 6395

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/dayrain.png?1516281787763 HTTP/1.1" 200 2623

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/dayrainrate.png?1516281787763 HTTP/1.1" 200 2444

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/dayinouthum.png?1516281787763 HTTP/1.1" 200 4265

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/daywind.png?1516281787763 HTTP/1.1" 200 5313

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/daywinddir.png?1516281787763 HTTP/1.1" 200 4477

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/daywindvec.png?1516281787763 HTTP/1.1" 200 5660

10.254.70.1 - - [18/Jan/2018:07:23:07 -0600] "GET /weewx/ss/daybarometer.png?1516281787763 HTTP/1.1" 200 4324

10.254.70.1 - - [18/Jan/2018:07:23:10 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787620 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:12 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787621 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:15 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787622 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:17 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787623 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:20 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787624 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:22 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787625 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:25 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787626 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:28 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787627 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:30 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787628 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:33 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787629 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:35 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787630 HTTP/1.1" 200 2319

10.254.70.1 - - [18/Jan/2018:07:23:38 -0600] "GET /weewx/ss/gauge-data.txt?_=1516281787631 HTTP/1.1" 200 2319

So various parts seem to be working. I checked the error.log for that time and saw no errors.

I've looked at all of the suggested links the new logging system, still can't see weewx messages. Another thing to work on.

Yes, Apple in their divine wisdom makes a lot of changes. As they did when the upgrade to Sierra came along, they had change the command to start processes. Say WHAT??

Took a while to dig that out.

Thanks all,

Keith

  

 

 

[k_her...@yahoo.com]

HURRAY!!!!

Found a link that explained Console app on High Sierra.  https://support.omnigroup.com/console-osx/


After playing around with it a little (see Attached file).

 

 

[gjr80]

Well done Keith, and I thought everything was supposed to be easier on the Mac :)  As Matthew said we probably need a wiki page about this but at least for now we have the link you found.

Everything in the log extract you posted seems to be as it should.

Gary

[gjr80]

Sorry, got tied up elsewhere yesterday and not too much weeWX time.

On Friday, 19 January 2018 01:18:01 UTC+10, k_her...@yahoo.com wrote:

Gary,

On Thursday, January 18, 2018 at 5:43:29 AM UTC-6, gjr80 wrote:

 

Not to worry, let's work on weewx.conf. At the moment you have two copies of gauge-data.txt being produced; one copy is produced during each report cycle (ie every 5 minutes) by the weeWX SteelSeries Gauges skin and a second copy is produced by the realtime gauge data (rtgd) extension. The rtgd extensions produces a loop based gauge-data.txt every loop period. No problems with both being there, as long as they are not trying to write to the same location. Ultimately though, when we get the guages working with one or the other you should (at the very least) disable the other or uninstall it.

I would like to try to work out where the two gauge-data.txt files are being generated. I suspect the SteelSeries Gauges skin is placing gauge-data.txt in /Users/keith/Sites/weewx/ 

public_html/ss, if so this file would be being updated every 5 minutes. I suspect that the rtgd extension should be placing gauge-data.txt in /Users/keith/Sites/weewx/public_html and this file would be being updated every 2 odd seconds. Can you confirm that these files are where I suspect and that they are being updated as stated? The files will be similar but have some differences as there are some fields in gauge-data.txt that the SteelSeries Gauges skins does not provide but the rtgd extension does.

Yes, your right on both locations. I was hoping to use both so as to have the standard on one web page and realtime on another. I've seen that on a couple to sites. 

Ok, so the files are where I suspect, and I can tell from your new found console log the that gauge-data.txt in public_html/ss is being updated every 5 minutes but is the gauge-data.txt in public_html being updated every few seconds? You will need to look at the files timestamp and perhaps refresh the display to see if the timestamp is updating.

Getting both standard and realtime to display should be easy enough, once we get realtime working that is.

Yes it appears Apache is OK, 200 codes mean the web server read the file successfully, 304 means it was not modified.

I really cannot understand why in gauges.js

 realTimeUrlWeewx: 'gauge-data.txt',

 

works (and reads the gauge-data.txt in public_html/ss) but

realTimeUrlWeewx: '../gauge-data.txt',

does not work and will not read the gauge-data.txt in public_html.

Can I get you to edit public_html/ss/scripts/gauges.js and set it to use the gauge-data.txt in public_html ie change the realtimeUrlWeewx setting to be:

realTimeUrlWeewx: '../gauge-data.txt',

Now refresh your gauges page in your browser and confirm this still does not work (ie gauges do not show correct data and/or do not update every few seconds). Now can you get hold of a similar Apache extract as you posted above, that shuld show us what Apache is getting/not getting.

Also, I gather you gauges page is not publicly viewable, its internal to your LAN only?

Gary

[k_her...@yahoo.com]

Gary,

Here's what I have.

On Friday, January 19, 2018 at 7:27:23 PM UTC-6, gjr80 wrote:

Sorry, got tied up elsewhere yesterday and not too much weeWX time.

On Friday, 19 January 2018 01:18:01 UTC+10, k_her...@yahoo.com wrote:

Gary,

On Thursday, January 18, 2018 at 5:43:29 AM UTC-6, gjr80 wrote:

 

Not to worry, let's work on weewx.conf. At the moment you have two copies of gauge-data.txt being produced; one copy is produced during each report cycle (ie every 5 minutes) by the weeWX SteelSeries Gauges skin and a second copy is produced by the realtime gauge data (rtgd) extension. The rtgd extensions produces a loop based gauge-data.txt every loop period. No problems with both being there, as long as they are not trying to write to the same location. Ultimately though, when we get the guages working with one or the other you should (at the very least) disable the other or uninstall it.

I would like to try to work out where the two gauge-data.txt files are being generated. I suspect the SteelSeries Gauges skin is placing gauge-data.txt in /Users/keith/Sites/weewx/ 

public_html/ss, if so this file would be being updated every 5 minutes. I suspect that the rtgd extension should be placing gauge-data.txt in /Users/keith/Sites/weewx/public_html and this file would be being updated every 2 odd seconds. Can you confirm that these files are where I suspect and that they are being updated as stated? The files will be similar but have some differences as there are some fields in gauge-data.txt that the SteelSeries Gauges skins does not provide but the rtgd extension does.

Yes, your right on both locations. I was hoping to use both so as to have the standard on one web page and realtime on another. I've seen that on a couple to sites. 

Ok, so the files are where I suspect, and I can tell from your new found console log the that gauge-data.txt in public_html/ss is being updated every 5 minutes but is the gauge-data.txt in public_html being updated every few seconds? You will need to look at the files timestamp and perhaps refresh the display to see if the timestamp is updating.

The time stamp on the public-data.txt seems to be updating every 1 min.  The timestamp on the file and inside of the file are the same. Did 'cat' on the file every few seconds and the data was the same.

Enclosed file show the content of both public-data.txt files.

The gauges appear to be working correctly now. I've done this many times and it wouldn't work. Go figure!!!  It took a few minutes (maybe 5 or 10) before they started working. NOW i'm getting the windrosedata that i wasn't before. Maybe I didn't wait long enough for them to activate. I thought it would happen a lot faster.

 

Also, I gather you gauges page is not publicly viewable, its internal to your LAN only?

It should be available publicly.  www.herriage.com  and click on ss gauges on the main page

Do I need to change this in weewx/skins/ss/scripts/gauge.js? That was where I was changing the script thinking that when I restarted weewx it would over write the public_html/ss files. Is that wrong?

May have found the error in my understanding how the worked.

 

Gary

 Keith

[k_her...@yahoo.com]

I've also noticed that with rtgd going, python in system.log running 'top', uses a lot of cpu %.

So with this working I'm thinking about moving this to a Raspberry Pi 3 to get a load off the iMac. I really don't notice any slow down but just know the cpu% is up there might be something to play with.

 

keith

[gjr80]

Keith,

You know I was thinking this morning when I typed that reply, I wonder if he's editing the gauges.js in the skins folder. No matter, it's working now, updating every few seconds. You can tell by looking at the wind, if there is wind blowing it will likely change every few seconds. Having windrose data is confirmation you are using the rtgd generated gauge-data.txt, rtgd provides windrose data but the skin version does not.

I am away from home tonite, hopefully some stargazing but as usual clouds are around. I'll post some details on getting two gauges pages up, one with each gauge-data.txt if that still interests you.

Page comes up fine from the internet, that's a nice looking area where you are. Looks a bit like our area, though we have more bush (trees and undergrowth).

Gary

[gjr80]

Yep, this is a known and now fixed issue. You can download rtgd v0.3.2 and it will fix the issue, you can just extract rtgd.py from the v0.3.2 package and save it over your exiting rtgd.py in the user directory. You will have to restart weeWX of course.

Gary

[k_her...@yahoo.com]

Gary,

Ok, I try that this morning. Maybe I did make my self clear. I wanted the standard page that comes with weewx installation and ss gauges page. And I have that now. The standard report has been working for a while. I was thinking of the Standard vs rtgd, I didn't understand that rtgd and the regular gauges were totally different animals. Now after all this I understand a bit more.

Thanks for all your help.

Keith

[gjr80]

Ah, now I understand. I have seen people want all sorts of things when it comes to displaying their weather info so most requests don't throw me these days.

Gary

[k_her...@yahoo.com]

Downloaded 0.3.2, Fixed the cpu%. 

Thanks again.

How did the stargazing go?

Keith

[gjr80]

On Saturday, 20 January 2018 23:20:36 UTC+10, k_her...@yahoo.com wrote:

Downloaded 0.3.2, Fixed the cpu%. 

Thanks again.

Good, and no problems.

How did the stargazing go?

Good, clouds cleared for a good couple of hours and saw some excellent nebula and clusters in telescopes far bigger than mine. Then clouds rolled in right on 9PM as forecast. 3rd attempt going to this venue and previous two were clouded out so I am happy.

 Gary

[k_her...@yahoo.com]

Very nice to have a clear night.

By the way I just noticed that gauges stopped updating after I installed rtgd.py and restarted weewx. Really strong that it takes a while to start updating every 3 sec. after a change in gauges.js.

I had to reedit that file for ../gauge-data.txt and then wait for it to start.

Does rtgd pull a copy of weewx/skins/ss/scripts/gauges.js when it restarts? That's what it appears unless it gets it from somewhere else.

Keith 

[Gary Roderick]

Yes, suggest you edit weewx.conf and under [StdReport] comment out the SteelSeries skin. The SteelSeries skin is set to copy all the necessary web server files(including gauges.js) as part of the first report cycle after a WeeWX start. Commenting out the skin will prevent this occurring in the future.

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[k_her...@yahoo.com]

Done and Done.

thanks again.

keith

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

[k_her...@yahoo.com]

Gary,

Noticed something odd on the Standard  OutsideHumidity Chart.

I remember seeing something about extra characters on some gauges but not on a chart. I've looked but can't find it. 

I've attached a png to look at. Appears to be the only chart that's affected. 

What do you thing is the problem?

Ketih

[Andrew Milner]

Check the labels secti9on of the skin.conf and if necessary delete and re-enter the line giving the label for outHumidity

[k_her...@yahoo.com]

Hi Andrew,

The line looked ok but I readied it anyway. Still incorrect.

Different but incorrect.

Keith

[Andrew Milner]

are you using nano or a similar unix text editor to do the edits, or a graphical editor??  I strongly suspect it is a character inserted by your editor - especially if you deleted the whole line and re-inserted it and got different results!!

[k_her...@yahoo.com]

I'm using vim(console on a mac)

The text after "Outside Humidity" changes as the humidity rises or lowers.

[Andrew Milner]

That makes no sense.  There should be no text after Outside Humidity in the [labels] [[generic]] section of skin.conf which is used as the title at the top of the graph - it is a fixed string used as the graph's title.  I am assuming we are talking about the standard skin here.  It seems that there may be two labels for outHumidity lurking in your skin - one with the value appended and one without ... only a shot in the dark .....

I'll leave this for Tom and gary I think.

[k_her...@yahoo.com]

This is excepts of weewx/skins/Standart/skin.conf

[Andrew Milner]

That bit of file does not help at all!!

Can you attach the whole skin by any chance as a file attachment??

[gjr80]

Keith,

The first thing I think of when I hear odd characters in plots is a font issue; however, font issues usually manifest themselves as changes to extended characters such as degree signs etc. That doesn't appear to be the case here. When I look at your site just now I see the title of your yearly humidity plot as 'Outside HumidityMIN(usUnits)', whilst your daily plot has an umlaut, cents symbol and Y umlaut appended to 'Outside Humidity'. Week and month plot labels are correct. Given the different labels I am not sure this is a case of extra characters being added by incorrect editing of skin.conf, if that was the case the labels would all be identical. One thing to keep in mind though is that by default the yearly plots are only generated at midnight each day so you need to delete them to force reeneration to show up any changes.

Notwithstanding could you post your Standard skin.conf in its entirety as Andrew asked. Please don't open or edit the file but rather include the file as an attachment, note you may need to append .txt to the file name to let you post it if google gets upset. Otherwise feel free to email it to me at gjroderick (at) gmail.com

Gary

[k_her...@yahoo.com]

Gary, Andrew,

Sorry it took so long to get back here. Been busy with another project.

Here's the skin.conf file. 

keith

[Glenn McKechnie]

In case they have gone back to umlauts or whatever by the time someone else visits http://www.herriage.com/weewx/index.html.

I copied 2 outHumidity images from there that have sql strings after the title, or in its place. Specifically ', sum(windspeed) FROM archive WHERE dateTime>' and 'SELECT * FROM archive_day_windGustDir WHERE d'
Something is bleeding over but I can't find those strings in my /usr/share/weewx or /etc/weewx directories? Another skin perhaps, or an errant paste into one of weewx files?

Images are attached

Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

[Andrew Milner]

Just out of curiosity, and starting to clutch at straws ....

 

a) do you get the same result if you run wee_reports manually???

b) can you run manually with radar image commented out (that is a very long URL)

http://weewx.com/docs/utilities.htm#wee_reports_utility

[k_her...@yahoo.com]

Andrew

On Wednesday, January 24, 2018 at 4:02:38 AM UTC-6, Andrew Milner wrote:

Just out of curiosity, and starting to clutch at straws ....

 

a) do you get the same result if you run wee_reports manually???

Yes, same results. 

b) can you run manually with radar image commented out (that is a very long URL)

Commented it out and no difference.'

Keith  

[Thomas Keffer]

Wow. This is disturbing. The daily summaries are not even used by the plots, so I'm not sure where those SQL statements could be coming from. 

A few questions:

1. Is the problem confined to the outside humidity plot? Or, does it ever occur on another plot?
2. Is this a stock weeWX install? Or, have you installed any extensions?
3. Could you please post the StdReport section of your weewx.conf file?

-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.

[k_her...@yahoo.com]

Tom,

On Wednesday, January 24, 2018 at 2:09:52 PM UTC-6, Tom Keffer wrote:

Wow. This is disturbing. The daily summaries are not even used by the plots, so I'm not sure where those SQL statements could be coming from. 

A few questions:

1. Is the problem confined to the outside humidity plot? Or, does it ever occur on another plot?

It appears to be only on the outside humidity plot. I've checked week, month and year. Year is incorrect also. 

1. Is this a stock weeWX install? Or, have you installed any extensions?

It is a stock install WITH ss gauges and realtime gauges installed 

1. Could you please post the StdReport section of your weewx.conf file?

file is attached

 

[gjr80]

I actually sat watching this for about an hour last night noting the change as each new plot was generated. The majority of plots had parts of an SQL statement in the plot label, some had seemingly random characters and one had what looked like a file path, I took note of the path as it clearly had nothing to do with weeWX '/System/Library/Frameworks/VideoToolbox'. Occasionally the plot label had no extra (visible) characters added to it ie it appeared correct.

I also noted similar things happening with the week, month and year humidity plots though they are generated less frequently so the changes in label occur less often. I can't say I have seen anything else obviously wrong on the site.

Gary

[k_her...@yahoo.com]

Thanks Gary and Tom,

I haven't changed anything on purpose but some of the html tmpl files for appearance. However, you never know about me. :-).   

[Thomas Keffer]

1. Save your old version of weeplot/genplot.py someplace.
2. Replace it with the attached version. It has been instrumented to log the label values the plotting engine is receiving. 
3. Then run wee_reports
4. Post the resultant log. The instrumented version posts "LOG_ERR" to make it easy to find the posts in the log on the Mac! Should be in /var/log/system.log.
5. Restore your original version of genplot.py

Hopefully we can localize where the problem is.

-tk

--

[Thomas Keffer]

Oops. Forgot to attach the file.

[k_her...@yahoo.com]

Tom,

Here's what I found in system.log with console.

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

[Thomas Keffer]

That one looks normal. Did you check to see whether the image had a bad label?

-tk

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

[k_her...@yahoo.com]

I ran it again just to make sure and it still had the extra letters.

keith

[Andrew Milner]

If you change the order of the plots in the skin does it change which graph gets corrupted or is it always the outside humidity wherever the plot is placed in the skin??

 

 

 

Sent from Mail for Windows 10

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

[k_her...@yahoo.com]

On Thursday, January 25, 2018 at 8:13:50 AM UTC-6, k_her...@yahoo.com wrote:

I ran it again just to make sure and it still had the extra letters.

sorry, forgot to refresh the screen.

I stand corrected, I forgot to refresh and there was no extra letters. However that has happened before and then returned. 

I'll run this several times this morning and  see if it stays clean.

[k_her...@yahoo.com]

Andrew,

let me get done with Toms testing file and I'll check that.

keith

[Thomas Keffer]

Just to be clear: What we're trying to do is capture the log when the plot had the extra letters. Sounds like you're on to it!

-tk

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

[k_her...@yahoo.com]

Tom,

I've run the test 7 times and the text is different every time. Didn't think about grabbing the pngs till later.

the first four had text similar to (but not exactly) like the  out humidity3

I thought 1 and 2 were interesting.

Keith 

[Thomas Keffer]

Thanks, Keith. What does the log show for these three plots? Look for timestamps around 0840, 0845, and 0850.

-tk

[k_her...@yahoo.com]

On Thursday, January 25, 2018 at 9:10:43 AM UTC-6, Tom Keffer wrote:

Thanks, Keith. What does the log show for these three plots? Look for timestamps around 0840, 0845, and 0850.

Tom,

Jan 25 08:40:39 Keiths-new-iMac sudo[7906]:    keith : TTY=ttys000 ; PWD=/Users/keith/Sites/weewx/bin/weeplot ; USER=root ; COMMAND=/Users/keith/Sites/weewx/bin/wee_reports

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Barometer, or unicode Barometer

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Outside Temperature, or unicode Outside Temperature

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Dew Point, or unicode Dew Point

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Wind Chill, or unicode Wind Chill

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Heat Index, or unicode Heat Index

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Outside Humidity, or unicode Outside Humidity

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Rain (hourly total), or unicode Rain (hourly total)

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of ISS Signal Quality, or unicode ISS Signal Quality

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Wind Speed, or unicode Wind Speed

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Gust Speed, or unicode Gust Speed

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Inside Temperature, or unicode Inside Temperature

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Wind Direction, or unicode Wind Direction

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Wind Vector, or unicode Wind Vector

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of Radiation, or unicode Radiation

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of max, or unicode max

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of UV Index, or unicode UV Index

Jan 25 08:40:39 Keiths-new-iMac wee_reports[7907]: Received label of max, or unicode max

Jan 25 08:45:24 Keiths-new-iMac sudo[7911]:    keith : TTY=ttys000 ; PWD=/Users/keith/Sites/weewx/bin/weeplot ; USER=root ; COMMAND=/Users/keith/Sites/weewx/bin/wee_reports

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Barometer, or unicode Barometer

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Outside Temperature, or unicode Outside Temperature

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Dew Point, or unicode Dew Point

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Wind Chill, or unicode Wind Chill

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Heat Index, or unicode Heat Index

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Outside Humidity, or unicode Outside Humidity

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Rain (hourly total), or unicode Rain (hourly total)

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of ISS Signal Quality, or unicode ISS Signal Quality

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Wind Speed, or unicode Wind Speed

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Gust Speed, or unicode Gust Speed

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Inside Temperature, or unicode Inside Temperature

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Wind Direction, or unicode Wind Direction

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Wind Vector, or unicode Wind Vector

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of Radiation, or unicode Radiation

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of max, or unicode max

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of UV Index, or unicode UV Index

Jan 25 08:45:25 Keiths-new-iMac wee_reports[7912]: Received label of max, or unicode max

Jan 25 08:50:35 Keiths-new-iMac sudo[7918]:    keith : TTY=ttys000 ; PWD=/Users/keith/Sites/weewx/bin/weeplot ; USER=root ; COMMAND=/Users/keith/Sites/weewx/bin/wee_reports

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Barometer, or unicode Barometer

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Outside Temperature, or unicode Outside Temperature

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Dew Point, or unicode Dew Point

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Wind Chill, or unicode Wind Chill

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Heat Index, or unicode Heat Index

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Outside Humidity, or unicode Outside Humidity

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Rain (hourly total), or unicode Rain (hourly total)

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of ISS Signal Quality, or unicode ISS Signal Quality

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Wind Speed, or unicode Wind Speed

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Gust Speed, or unicode Gust Speed

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Inside Temperature, or unicode Inside Temperature

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Wind Direction, or unicode Wind Direction

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Wind Vector, or unicode Wind Vector

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of Radiation, or unicode Radiation

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of max, or unicode max

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of UV Index, or unicode UV Index

Jan 25 08:50:36 Keiths-new-iMac wee_reports[7919]: Received label of max, or unicode max

I’ve captured another png that might point somewhere.

[gjr80]

This couldn't be an Apple PIL or pillow thing could it? Having watched these plots on and off for a couple of days almost all have some extra text in the outHumidity label. Given the number of instrumented outputs posted by Keith I am sure at least one must have been from a 'bad' plot. Mind you when I had a look last night when Keith posted his first log, the plot I happened to look at was perfect (some 45 minutes after Keith's log).

Gary

[k_her...@yahoo.com]

The one I just looked at 10:40 was correct.

[k_her...@yahoo.com]

at 10:45 correct.

[Thomas Keffer]

OK, in the three instances you posted, the plots were bad, but the incoming label is correct. So, we know the problem lies somewhere in the image generation, and not in the weeWX configuration.

Try this version of genplot.py. Same drill: run wee_reports, check for a bad image, post the log that goes along with that bad image.

-tk

--

[k_her...@yahoo.com]

Here is the latest report. Also image.

debug 00:36:18.266998 -0600 Python reportengine: Running reports for latest time in the database.

debug 00:36:18.267110 -0600 Python reportengine: Running report StandardReport

debug 00:36:18.271117 -0600 Python reportengine: Found configuration file /Users/keith/Sites/weewx/skins/Standard/skin.conf for report StandardReport

debug 00:36:18.308277 -0600 Python cheetahgenerator: using search list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']

debug 00:36:18.314462 -0600 Python manager: Daily summary version is 2.0

debug 00:36:18.908574 -0600 cfprefsd Process 9277 sent a request related to { org.python.python, user: kCFPreferencesAnyUser, kCFPreferencesCurrentHost, no container, managed: 1 }

debug 00:36:18.908574 -0600 cfprefsd Process 9277 sent a request related to { org.python.python, user: root, kCFPreferencesCurrentHost, no container, managed: 1 }

debug 00:36:18.908580 -0600 cfprefsd Process 9277 sent a request related to { org.python.python, user: root, kCFPreferencesCurrentHost, no container, managed: 0 }

debug 00:36:18.908621 -0600 cfprefsd Process 9277 sent a request related to { org.python.python, user: kCFPreferencesAnyUser, kCFPreferencesCurrentHost, no container, managed: 0 }

debug 00:36:18.908621 -0600 cfprefsd Process 9277 sent a request related to { org.python.python, user: root, kCFPreferencesAnyHost, no container, managed: 0 }

info 00:36:18.979680 -0600 Python cheetahgenerator: Generated 14 files for report StandardReport in 0.67 seconds

debug 00:36:18.998489 -0600 Python manager: Daily summary version is 2.0

default 00:36:19.025224 -0600 Python Rendering label Barometer

default 00:36:19.031351 -0600 Python Rendering label Outside Temperature

default 00:36:19.031466 -0600 Python Rendering label Dew Point

default 00:36:19.037174 -0600 Python Rendering label Wind Chill

default 00:36:19.037275 -0600 Python Rendering label Heat Index

default 00:36:19.042297 -0600 Python Rendering label Outside Humidity

default 00:36:19.047749 -0600 Python Rendering label Rain (hourly total)

default 00:36:19.051935 -0600 Python Rendering label ISS Signal Quality

default 00:36:19.057467 -0600 Python Rendering label Wind Speed

default 00:36:19.057553 -0600 Python Rendering label Gust Speed

default 00:36:19.063139 -0600 Python Rendering label Inside Temperature

default 00:36:19.067978 -0600 Python Rendering label Wind Direction

default 00:36:19.072593 -0600 Python Rendering label Wind Vector

default 00:36:19.079569 -0600 Python Rendering label Radiation

default 00:36:19.079646 -0600 Python Rendering label max

default 00:36:19.085010 -0600 Python Rendering label UV Index

default 00:36:19.085082 -0600 Python Rendering label max

info 00:36:19.097047 -0600 Python imagegenerator: Generated 12 images for StandardReport in 0.10 seconds

info 00:36:19.101432 -0600 Python copygenerator: copied 14 files to /Users/keith/Sites/weewx/public_html

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

[Thomas Keffer]

This shows pretty conclusively that the problem is in your version of PIL or Pillow, the Python Imaging Library. Do you know where you got your copy? Did it come with your version of Python, or did you install it?

Most likely, you installed a version of Pillow (that's what I did). Let's find out the version. Run the following command:

python -c "import PIL; print PIL.PILLOW_VERSION"

I have Version 3.0.0 installed on my Mac (released 6-Oct-2015). If you have a significantly older version, you could try upgrading. The latest version is 5.0.0

-tk

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

[k_her...@yahoo.com]

I used the weewx:Instalation on MscOS system and did " sudo easy_install Pillow" as I did for all the other packages.

my version is 4.3.0

keith

[k_her...@yahoo.com]

Tom,

I upgraded Pillow to 5.0.0 and haven't seen an error. Watched it for 12  5 minute intervals.

Looks like you called it. 

Gary had mentioned he was wondering if it was a pillow problem.

I'm still wondering why it just affected Outside Humidity. Strange. Seems it would use same code to generate all of the charts.

Thanks very much to both you and Gary.

Sorry to put you both through this.

Keith

[Thomas Keffer]

No problem. I'm just relieved it wasn't some horribly subtle weeWX bug!

-tk

--

[k_her...@yahoo.com]

Well, I was hoping it wasn't something i screwed up :-)

You have written a great piece of software. I used wview for several years and this is a lot easier to setup and use.

Thanks again.

Keith

[Thomas Keffer]

We all learned a lot from Mark's pioneering efforts.

-tk

--