Re: [weewx-user] Re: have a prob with a not loaded or installed Python package

[John Kline]

Sorry about that.  I see now that he has added two packages to the requires 
section; apparently rather than installing them.

> On Jun 2, 2019, at 8:48 PM, gjr80  wrote:
> 
> I am not sure what was done either. However, the setup.py that was included 
> in the post is a modified version of the WeeWX setup.py, I can only surmise 
> it was modified and used. Agree 100% that for setup.py you need to manually 
> install any additional packages, the recommended way to do that is to 
> manually install them from the command line and not by modifying setup.py
> 
> Gary
> 
>> On Monday, 3 June 2019 13:37:27 UTC+10, John Kline wrote:
>> I’m not so sure he modified anything.  The packages need to be installed 
>> manually when using setup.py for installation.
>> 
>> See: http://www.weewx.com/docs/setup.htm
>> In particular, look at the Install Prerequisites section.
>> 
>>> On Jun 2, 2019, at 8:33 PM, gjr80  wrote:
>>> 
>>> Hi,
>>> 
>>> It looks like you have modified the WeeWX installer and it has not done 
>>> what you want. I cannot help with that but I suggest the easiest way to fix 
>>> your requests import error is to manually install the python requests 
>>> library. To install requests try (untested):
>>> 
>>> 1. install pip:
>>> 
>>> $ sudo apt-get install python-dev
>>> $ sudo apt-get install python-pip
>>> 
>>> 2. install the requests library:
>>> $ sudo pip install requests
>>> 
>>> Note that if your modified installer did not work as expected it is 
>>> possible you will have other unmet dependencies (ie errors). You will need 
>>> to deal with them as they occur and you may well have to install other 
>>> libraries.
>>> 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/0a9b6a73-fdba-4ab5-acf2-ad30d2456d0f%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/e2601499-8147-4f9a-8a06-d7664ebbea95%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5D622E86-F80F-4C02-B707-677580AA9D10%40johnkline.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: have a prob with a not loaded or installed Python package

[gjr80]

I am not sure what was done either. However, the setup.py that was included 
in the post is a modified version of the WeeWX setup.py, I can only surmise 
it was modified and used. Agree 100% that for setup.py you need to manually 
install any additional packages, the recommended way to do that is to 
manually install them from the command line and not by modifying setup.py

Gary

On Monday, 3 June 2019 13:37:27 UTC+10, John Kline wrote:
>
> I’m not so sure he modified anything.  The packages need to be installed 
> manually when using setup.py for installation.
>
> See: http://www.weewx.com/docs/setup.htm
> In particular, look at the Install Prerequisites section.
>
> On Jun 2, 2019, at 8:33 PM, gjr80 > 
> wrote:
>
> Hi,
>
> It looks like you have modified the WeeWX installer and it has not done 
> what you want. I cannot help with that but I suggest the easiest way to fix 
> your requests import error is to manually install the python requests 
> library. To install requests try (untested):
>
> 1. install pip:
>
> $ sudo apt-get install python-dev
> $ sudo apt-get install python-pip
>
>
> 2. install the requests library:
> $ sudo pip install requests
>
> Note that if your modified installer did not work as expected it is possible 
> you will have other unmet dependencies (ie errors). You will need to deal 
> with them as they occur and you may well have to install other libraries.
>
> 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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0a9b6a73-fdba-4ab5-acf2-ad30d2456d0f%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e2601499-8147-4f9a-8a06-d7664ebbea95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: have a prob with a not loaded or installed Python package

[John Kline]

I’m not so sure he modified anything.  The packages need to be installed 
manually when using setup.py for installation.

See: http://www.weewx.com/docs/setup.htm
In particular, look at the Install Prerequisites section.

> On Jun 2, 2019, at 8:33 PM, gjr80  wrote:
> 
> Hi,
> 
> It looks like you have modified the WeeWX installer and it has not done what 
> you want. I cannot help with that but I suggest the easiest way to fix your 
> requests import error is to manually install the python requests library. To 
> install requests try (untested):
> 
> 1. install pip:
> 
> $ sudo apt-get install python-dev
> $ sudo apt-get install python-pip
> 
> 2. install the requests library:
> $ sudo pip install requests
> 
> Note that if your modified installer did not work as expected it is possible 
> you will have other unmet dependencies (ie errors). You will need to deal 
> with them as they occur and you may well have to install other libraries.
> 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0a9b6a73-fdba-4ab5-acf2-ad30d2456d0f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/393713DB-C403-44C5-93F0-36C9C0E566E6%40johnkline.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: have a prob with a not loaded or installed Python package

[gjr80]

Hi,

It looks like you have modified the WeeWX installer and it has not done 
what you want. I cannot help with that but I suggest the easiest way to fix 
your requests import error is to manually install the python requests 
library. To install requests try (untested):

1. install pip:

$ sudo apt-get install python-dev
$ sudo apt-get install python-pip


2. install the requests library:
$ sudo pip install requests

Note that if your modified installer did not work as expected it is possible 
you will have other unmet dependencies (ie errors). You will need to deal with 
them as they occur and you may well have to install other libraries.

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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0a9b6a73-fdba-4ab5-acf2-ad30d2456d0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Need Help with Best Configuration - Rasberry Pi, Weewx, Acurite smartHub, Interceptor Driver, Google Wifi

[Radar]

you have web server running on port 80
this will help https://github.com/matthewwall/weewx-interceptor

On Sunday, June 2, 2019 at 4:03:37 PM UTC-5, Thomas Chapin wrote:
>
> Hoping someone smarter than I can help...
>
> Like others, I was fried when after 3 months told by Acurite that they 
> were discontinuing smartHub and I could pay another $129 for its 
> replacement...I read about Weewx and Rasberry Pi.
>
> Finally bought the Pi and got started.  Quickly underestimated the 
> networking knowledge I would need.
>
> Basically, I need help connecting Weewx to the data coming from the 
> smartHub.  I think it's mostly a DNS networking and interceptor driver 
> config challenge.  
>
> Here's my current state, let me know if any other info (e.g. weewx config) 
> is needed.
>
> **888
>
> Rasberry Pi 3 B+ running Debian
> Wireless connection to Internet through Google Wifi (see below)
> Nothing plugged into ethernet jack on Pi (at this time)
> SSH - enabled
> I2C - enabled for RTC below
> RTC (SunFounder PCF8563 IIC I2C Real Time Clock RTC) installed and 
> functioning
>
> ***
> Network Settings:
> Google Wifi Mesh Router
> DNS set to automatic 8.8.8.8 (Google)
> On Google wifi, have configured DHCP reservations for both the SmartHub 
> and Pi IP numbers (below)
> SmartHub ethernet plugged into one of the wifi pucks, IP: 192.168.xx
> Rasberry Pi IP:: 192.168.yy
>
> 
> Acurite smartHub - v224 (boot firmware v210) - server targeted - 
> hubapi.myacurite.com - can see it at its IP number
>
> *
> Weewx
> Have downloaded and installed Weewx
> Have downloaded and configured Interceptor Driver
> Have configured Weewx for interceptor driver, device acurite
> Have downloaded and installed apache - web server running on port 80: 
> Apache/2.4.25 (Raspbian) Server at 192.168.86.yy Port 80
>
> pi@raspberrypi:~ $ sudo tail -f /var/log/syslog
> Jun 2 16:18:53 raspberrypi systemd[1]: Started LSB: weewx weather system.
> Jun 2 16:18:53 raspberrypi weewx[25630]: engine: Loading station type 
> Interceptor (user.interceptor)
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: driver 
> version is 0.45
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: device 
> type: acurite-bridge
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: sensor 
> map: None
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: mode is 
> listen
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: listen 
> on :80
> Jun 2 16:18:53 raspberrypi weewx[25630]: import of driver failed: [Errno 
> 98] Address already in use ()
> Jun 2 16:18:53 raspberrypi weewx[25630]: engine: Unable to load driver: 
> [Errno 98] Address already in use
> Jun 2 16:18:53 raspberrypi weewx[25630]:  Exiting...
>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/b74bebbe-b708-4113-9b99-36d13c65f9f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] We have finally put the last nail on the coffin for Wunderfixer?

[Rod Yager]

The “today" result works as desired when I am ahead of the UTC date (as I am at 
the moment and will be for the next 33 minutes)

[root@moses bin]# date
Mon Jun  3 09:25:10 AEST 2019
[root@moses bin]# /home/weewx/bin/wunderdates3 --epsilon=125 --station 
ISYDNEY155 --test --verbose | (head -n 9 ; tail -n 1)
Using configuration file /home/weewx/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-06-03
epoch: 1559484000 date_epoch_local: 2019-06-03 00:00:00 utcepoch: 1559483000 
date_epoch_utc: 2019-06-02 14:00:00 tz: Australia/Sydney obsTimeUtc: 
2019-06-02T14:00:00Z obsTimeLocal: 2019-06-03 00:00:00
epoch: 1559484300 date_epoch_local: 2019-06-03 00:05:00 utcepoch: 1559483300 
date_epoch_utc: 2019-06-02 14:05:00 tz: Australia/Sydney obsTimeUtc: 
2019-06-02T14:05:00Z obsTimeLocal: 2019-06-03 00:05:00
epoch: 1559484600 date_epoch_local: 2019-06-03 00:10:00 utcepoch: 1559483600 
date_epoch_utc: 2019-06-02 14:10:00 tz: Australia/Sydney obsTimeUtc: 
2019-06-02T14:10:00Z obsTimeLocal: 2019-06-03 00:10:00
epoch: 1559484900 date_epoch_local: 2019-06-03 00:15:00 utcepoch: 1559483900 
date_epoch_utc: 2019-06-02 14:15:00 tz: Australia/Sydney obsTimeUtc: 
2019-06-02T14:15:00Z obsTimeLocal: 2019-06-03 00:15:00
epoch: 1559485200 date_epoch_local: 2019-06-03 00:20:00 utcepoch: 1559484200 
date_epoch_utc: 2019-06-02 14:20:00 tz: Australia/Sydney obsTimeUtc: 
2019-06-02T14:20:00Z obsTimeLocal: 2019-06-03 00:20:00
epoch: 1559485500 date_epoch_local: 2019-06-03 00:25:00 utcepoch: 1559484500 
date_epoch_utc: 2019-06-02 14:25:00 tz: Australia/Sydney obsTimeUtc: 
2019-06-02T14:25:00Z obsTimeLocal: 2019-06-03 00:25:00
Number of WU records:  112


So the problem only exists for 6 days [ yesterday and the preceeding days]

Rod

On 3 Jun 2019, at 9:12 am, Leon Shaner 
mailto:l...@isylum.org>> wrote:

Rod,

Thanks again for the added validation of what I saw earlier.
Never minding for now the issues with last week's data, what I am now most 
concerned to know is whether there is any point throughout the PRESENT day 
(your local time) that the latest wunderdates is showing the wrong results?

Recall that for the present day I am using a 'today' API which is for the 
'today' results.
That method is working for my station at all times during the PRESENT day (even 
within my UTC offset of local midnight).

I thought I understood you to say that those changes were no good for you at 
certain times of the PRESENT day, such as before 10 a.m. your local time, was 
it?

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

On Jun 2, 2019, at 5:50 PM, Rod Yager 
mailto:r...@yager.net.au>> wrote:

Well, it turns out that the East of the UTC date line bug only occurs for the 
latest week. (I’d assumed that testing involving requests for the last few days 
would show the behaviour, but that turned out to be wrong.)

At the moment, I’m a day ahead of UTC.  Here is the output for requests for 
2019-05-27 (within the last week and giving data for the 2019-05-28) and for 
2019-05-26 (not within the last week and giving the correct data for 
2019-05-06)  [I repeated the 2019-05-27 responses to show that they hadn’t 
happened coincidentally at a time where WU fixed the problem.]  All dates I’ve 
tested prior to 2019-05-27 also work as we would like. All dates within the 
last week give data for the day following the day in the request.

[rodyager@moses ~]$ date
Mon Jun  3 07:32:55 AEST 2019
[rodyager@moses ~]$ /home/weewx/bin/wunderdates --epsilon=125 --date 2019-05-27 
--station ISYDNEY155 --test --verbose | (head -n 8 ; tail -n 1)
Using configuration file /home/weewx/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-05-27
epoch: 1558965600 date_epoch_local: 2019-05-28 00:00:00 utcepoch: 1558964600 
date_epoch_utc: 2019-05-27 14:00:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:00:00Z obsTimeLocal: 2019-05-28 00:00:00
epoch: 1558965900 date_epoch_local: 2019-05-28 00:05:00 utcepoch: 1558964900 
date_epoch_utc: 2019-05-27 14:05:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:05:00Z obsTimeLocal: 2019-05-28 00:05:00
epoch: 1558966200 date_epoch_local: 2019-05-28 00:10:00 utcepoch: 1558965200 
date_epoch_utc: 2019-05-27 14:10:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:10:00Z obsTimeLocal: 2019-05-28 00:10:00
epoch: 1558966500 date_epoch_local: 2019-05-28 00:15:00 utcepoch: 1558965500 
date_epoch_utc: 2019-05-27 14:15:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:15:00Z obsTimeLocal: 2019-05-28 00:15:00
epoch: 1558966800 date_epoch_local: 2019-05-28 00:20:00 utcepoch: 1558965800 
date_epoch_utc: 2019-05-27 14:20:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:20:00Z obsTimeLocal: 2019-05-28 00:20:00
Number of WU records:  288
[rodyager@moses ~]$ /home/weewx/bin/wunderdates --epsilon=125 --date 2019-05-26 
--station ISYDNEY155 --test --verbose | (head -n 8 ; tail -n 1)
Using configuration file /home/weewx/weewx.conf.
Weather 

Re: [weewx-user] We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

Rod,

Thanks again for the added validation of what I saw earlier.
Never minding for now the issues with last week's data, what I am now most 
concerned to know is whether there is any point throughout the PRESENT day 
(your local time) that the latest wunderdates is showing the wrong results?

Recall that for the present day I am using a 'today' API which is for the 
'today' results.
That method is working for my station at all times during the PRESENT day (even 
within my UTC offset of local midnight).

I thought I understood you to say that those changes were no good for you at 
certain times of the PRESENT day, such as before 10 a.m. your local time, was 
it?

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On Jun 2, 2019, at 5:50 PM, Rod Yager  wrote:
> 
> Well, it turns out that the East of the UTC date line bug only occurs for the 
> latest week. (I’d assumed that testing involving requests for the last few 
> days would show the behaviour, but that turned out to be wrong.)
> 
> At the moment, I’m a day ahead of UTC.  Here is the output for requests for 
> 2019-05-27 (within the last week and giving data for the 2019-05-28) and for 
> 2019-05-26 (not within the last week and giving the correct data for 
> 2019-05-06)  [I repeated the 2019-05-27 responses to show that they hadn’t 
> happened coincidentally at a time where WU fixed the problem.]  All dates 
> I’ve tested prior to 2019-05-27 also work as we would like. All dates within 
> the last week give data for the day following the day in the request.
> 
> [rodyager@moses ~]$ date
> Mon Jun  3 07:32:55 AEST 2019
> [rodyager@moses ~]$ /home/weewx/bin/wunderdates --epsilon=125 --date 
> 2019-05-27 --station ISYDNEY155 --test --verbose | (head -n 8 ; tail -n 1)
> Using configuration file /home/weewx/weewx.conf.
> Weather Underground Station:   ISYDNEY155
> Date to check: 2019-05-27
> epoch: 1558965600 date_epoch_local: 2019-05-28 00:00:00 utcepoch: 1558964600 
> date_epoch_utc: 2019-05-27 14:00:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-27T14:00:00Z obsTimeLocal: 2019-05-28 00:00:00
> epoch: 1558965900 date_epoch_local: 2019-05-28 00:05:00 utcepoch: 1558964900 
> date_epoch_utc: 2019-05-27 14:05:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-27T14:05:00Z obsTimeLocal: 2019-05-28 00:05:00
> epoch: 1558966200 date_epoch_local: 2019-05-28 00:10:00 utcepoch: 1558965200 
> date_epoch_utc: 2019-05-27 14:10:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-27T14:10:00Z obsTimeLocal: 2019-05-28 00:10:00
> epoch: 1558966500 date_epoch_local: 2019-05-28 00:15:00 utcepoch: 1558965500 
> date_epoch_utc: 2019-05-27 14:15:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-27T14:15:00Z obsTimeLocal: 2019-05-28 00:15:00
> epoch: 1558966800 date_epoch_local: 2019-05-28 00:20:00 utcepoch: 1558965800 
> date_epoch_utc: 2019-05-27 14:20:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-27T14:20:00Z obsTimeLocal: 2019-05-28 00:20:00
> Number of WU records:  288
> [rodyager@moses ~]$ /home/weewx/bin/wunderdates --epsilon=125 --date 
> 2019-05-26 --station ISYDNEY155 --test --verbose | (head -n 8 ; tail -n 1)
> Using configuration file /home/weewx/weewx.conf.
> Weather Underground Station:   ISYDNEY155
> Date to check: 2019-05-26
> epoch: 1558792800 date_epoch_local: 2019-05-26 00:00:00 utcepoch: 1558791800 
> date_epoch_utc: 2019-05-25 14:00:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-25T14:00:00Z obsTimeLocal: 2019-05-26 00:00:00
> epoch: 1558793100 date_epoch_local: 2019-05-26 00:05:00 utcepoch: 1558792100 
> date_epoch_utc: 2019-05-25 14:05:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-25T14:05:00Z obsTimeLocal: 2019-05-26 00:05:00
> epoch: 1558793400 date_epoch_local: 2019-05-26 00:10:00 utcepoch: 1558792400 
> date_epoch_utc: 2019-05-25 14:10:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-25T14:10:00Z obsTimeLocal: 2019-05-26 00:10:00
> epoch: 1558793700 date_epoch_local: 2019-05-26 00:15:00 utcepoch: 1558792700 
> date_epoch_utc: 2019-05-25 14:15:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-25T14:15:00Z obsTimeLocal: 2019-05-26 00:15:00
> epoch: 1558794000 date_epoch_local: 2019-05-26 00:20:00 utcepoch: 1558793000 
> date_epoch_utc: 2019-05-25 14:20:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-25T14:20:00Z obsTimeLocal: 2019-05-26 00:20:00
> Number of WU records:  288
> [rodyager@moses ~]$ /home/weewx/bin/wunderdates --epsilon=125 --date 
> 2019-05-27 --station ISYDNEY155 --test --verbose | (head -n 8 ; tail -n 1)
> Using configuration file /home/weewx/weewx.conf.
> Weather Underground Station:   ISYDNEY155
> Date to check: 2019-05-27
> epoch: 1558965600 date_epoch_local: 2019-05-28 00:00:00 utcepoch: 1558964600 
> date_epoch_utc: 2019-05-27 14:00:00 tz: Australia/Sydney obsTimeUtc: 
> 2019-05-27T14:00:00Z obsTimeLocal: 2019-05-28 00:00:00
> epoch: 1558965900 date_epoch_local: 2019-05-28 00:05:00 utcepoch: 1558964900 
> date_epoch_utc: 2019-05-27 14:05:00 tz: Australia/Sydney 

Re: [weewx-user] We have finally put the last nail on the coffin for Wunderfixer?

[Rod Yager]

Well, it turns out that the East of the UTC date line bug only occurs for the 
latest week. (I’d assumed that testing involving requests for the last few days 
would show the behaviour, but that turned out to be wrong.)

At the moment, I’m a day ahead of UTC.  Here is the output for requests for 
2019-05-27 (within the last week and giving data for the 2019-05-28) and for 
2019-05-26 (not within the last week and giving the correct data for 
2019-05-06)  [I repeated the 2019-05-27 responses to show that they hadn’t 
happened coincidentally at a time where WU fixed the problem.]  All dates I’ve 
tested prior to 2019-05-27 also work as we would like. All dates within the 
last week give data for the day following the day in the request.

[rodyager@moses ~]$ date
Mon Jun  3 07:32:55 AEST 2019
[rodyager@moses ~]$ /home/weewx/bin/wunderdates --epsilon=125 --date 2019-05-27 
--station ISYDNEY155 --test --verbose | (head -n 8 ; tail -n 1)
Using configuration file /home/weewx/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-05-27
epoch: 1558965600 date_epoch_local: 2019-05-28 00:00:00 utcepoch: 1558964600 
date_epoch_utc: 2019-05-27 14:00:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:00:00Z obsTimeLocal: 2019-05-28 00:00:00
epoch: 1558965900 date_epoch_local: 2019-05-28 00:05:00 utcepoch: 1558964900 
date_epoch_utc: 2019-05-27 14:05:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:05:00Z obsTimeLocal: 2019-05-28 00:05:00
epoch: 1558966200 date_epoch_local: 2019-05-28 00:10:00 utcepoch: 1558965200 
date_epoch_utc: 2019-05-27 14:10:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:10:00Z obsTimeLocal: 2019-05-28 00:10:00
epoch: 1558966500 date_epoch_local: 2019-05-28 00:15:00 utcepoch: 1558965500 
date_epoch_utc: 2019-05-27 14:15:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:15:00Z obsTimeLocal: 2019-05-28 00:15:00
epoch: 1558966800 date_epoch_local: 2019-05-28 00:20:00 utcepoch: 1558965800 
date_epoch_utc: 2019-05-27 14:20:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:20:00Z obsTimeLocal: 2019-05-28 00:20:00
Number of WU records:  288
[rodyager@moses ~]$ /home/weewx/bin/wunderdates --epsilon=125 --date 2019-05-26 
--station ISYDNEY155 --test --verbose | (head -n 8 ; tail -n 1)
Using configuration file /home/weewx/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-05-26
epoch: 1558792800 date_epoch_local: 2019-05-26 00:00:00 utcepoch: 1558791800 
date_epoch_utc: 2019-05-25 14:00:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-25T14:00:00Z obsTimeLocal: 2019-05-26 00:00:00
epoch: 1558793100 date_epoch_local: 2019-05-26 00:05:00 utcepoch: 1558792100 
date_epoch_utc: 2019-05-25 14:05:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-25T14:05:00Z obsTimeLocal: 2019-05-26 00:05:00
epoch: 1558793400 date_epoch_local: 2019-05-26 00:10:00 utcepoch: 1558792400 
date_epoch_utc: 2019-05-25 14:10:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-25T14:10:00Z obsTimeLocal: 2019-05-26 00:10:00
epoch: 1558793700 date_epoch_local: 2019-05-26 00:15:00 utcepoch: 1558792700 
date_epoch_utc: 2019-05-25 14:15:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-25T14:15:00Z obsTimeLocal: 2019-05-26 00:15:00
epoch: 1558794000 date_epoch_local: 2019-05-26 00:20:00 utcepoch: 1558793000 
date_epoch_utc: 2019-05-25 14:20:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-25T14:20:00Z obsTimeLocal: 2019-05-26 00:20:00
Number of WU records:  288
[rodyager@moses ~]$ /home/weewx/bin/wunderdates --epsilon=125 --date 2019-05-27 
--station ISYDNEY155 --test --verbose | (head -n 8 ; tail -n 1)
Using configuration file /home/weewx/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-05-27
epoch: 1558965600 date_epoch_local: 2019-05-28 00:00:00 utcepoch: 1558964600 
date_epoch_utc: 2019-05-27 14:00:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:00:00Z obsTimeLocal: 2019-05-28 00:00:00
epoch: 1558965900 date_epoch_local: 2019-05-28 00:05:00 utcepoch: 1558964900 
date_epoch_utc: 2019-05-27 14:05:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:05:00Z obsTimeLocal: 2019-05-28 00:05:00
epoch: 1558966200 date_epoch_local: 2019-05-28 00:10:00 utcepoch: 1558965200 
date_epoch_utc: 2019-05-27 14:10:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:10:00Z obsTimeLocal: 2019-05-28 00:10:00
epoch: 1558966500 date_epoch_local: 2019-05-28 00:15:00 utcepoch: 1558965500 
date_epoch_utc: 2019-05-27 14:15:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:15:00Z obsTimeLocal: 2019-05-28 00:15:00
epoch: 1558966800 date_epoch_local: 2019-05-28 00:20:00 utcepoch: 1558965800 
date_epoch_utc: 2019-05-27 14:20:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-27T14:20:00Z obsTimeLocal: 2019-05-28 00:20:00
Number of WU records:  288


Rod


On 3 Jun 2019, at 5:47 am, Leon Shaner 
mailto:l...@isylum.org>> wrote:

Rod,

I've spent quite a bit of time working on a "cleaner" workaround for the WU 
bugs.
But just when I thought I had landed on the 

[weewx-user] Re: Need Help with Best Configuration - Rasberry Pi, Weewx, Acurite smartHub, Interceptor Driver, Google Wifi

[rich T]

Did you read the following post?

https://groups.google.com/forum/#!searchin/weewx-user/smarthub%7Csort:date/weewx-user/0e2E3F7EG7Y/mVv7oUZ1BgAJ



On Sunday, June 2, 2019 at 5:03:37 PM UTC-4, Thomas Chapin wrote:

> Hoping someone smarter than I can help...
>
> Like others, I was fried when after 3 months told by Acurite that they 
> were discontinuing smartHub and I could pay another $129 for its 
> replacement...I read about Weewx and Rasberry Pi.
>
> Finally bought the Pi and got started.  Quickly underestimated the 
> networking knowledge I would need.
>
> Basically, I need help connecting Weewx to the data coming from the 
> smartHub.  I think it's mostly a DNS networking and interceptor driver 
> config challenge.  
>
> Here's my current state, let me know if any other info (e.g. weewx config) 
> is needed.
>
> **888
>
> Rasberry Pi 3 B+ running Debian
> Wireless connection to Internet through Google Wifi (see below)
> Nothing plugged into ethernet jack on Pi (at this time)
> SSH - enabled
> I2C - enabled for RTC below
> RTC (SunFounder PCF8563 IIC I2C Real Time Clock RTC) installed and 
> functioning
>
> ***
> Network Settings:
> Google Wifi Mesh Router
> DNS set to automatic 8.8.8.8 (Google)
> On Google wifi, have configured DHCP reservations for both the SmartHub 
> and Pi IP numbers (below)
> SmartHub ethernet plugged into one of the wifi pucks, IP: 192.168.xx
> Rasberry Pi IP:: 192.168.yy
>
> 
> Acurite smartHub - v224 (boot firmware v210) - server targeted - 
> hubapi.myacurite.com - can see it at its IP number
>
> *
> Weewx
> Have downloaded and installed Weewx
> Have downloaded and configured Interceptor Driver
> Have configured Weewx for interceptor driver, device acurite
> Have downloaded and installed apache - web server running on port 80: 
> Apache/2.4.25 (Raspbian) Server at 192.168.86.yy Port 80
>
> pi@raspberrypi:~ $ sudo tail -f /var/log/syslog
> Jun 2 16:18:53 raspberrypi systemd[1]: Started LSB: weewx weather system.
> Jun 2 16:18:53 raspberrypi weewx[25630]: engine: Loading station type 
> Interceptor (user.interceptor)
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: driver 
> version is 0.45
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: device 
> type: acurite-bridge
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: sensor 
> map: None
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: mode is 
> listen
> Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: listen 
> on :80
> Jun 2 16:18:53 raspberrypi weewx[25630]: import of driver failed: [Errno 
> 98] Address already in use ()
> Jun 2 16:18:53 raspberrypi weewx[25630]: engine: Unable to load driver: 
> [Errno 98] Address already in use
> Jun 2 16:18:53 raspberrypi weewx[25630]:  Exiting...
>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/298a4b0d-2b88-4dd9-aac2-221a2c3b20c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Need Help with Best Configuration - Rasberry Pi, Weewx, Acurite smartHub, Interceptor Driver, Google Wifi

[Thomas Chapin]

Hoping someone smarter than I can help...

Like others, I was fried when after 3 months told by Acurite that they were 
discontinuing smartHub and I could pay another $129 for its replacement...I 
read about Weewx and Rasberry Pi.

Finally bought the Pi and got started.  Quickly underestimated the 
networking knowledge I would need.

Basically, I need help connecting Weewx to the data coming from the 
smartHub.  I think it's mostly a DNS networking and interceptor driver 
config challenge.  

Here's my current state, let me know if any other info (e.g. weewx config) 
is needed.

**888

Rasberry Pi 3 B+ running Debian
Wireless connection to Internet through Google Wifi (see below)
Nothing plugged into ethernet jack on Pi (at this time)
SSH - enabled
I2C - enabled for RTC below
RTC (SunFounder PCF8563 IIC I2C Real Time Clock RTC) installed and 
functioning

***
Network Settings:
Google Wifi Mesh Router
DNS set to automatic 8.8.8.8 (Google)
On Google wifi, have configured DHCP reservations for both the SmartHub and 
Pi IP numbers (below)
SmartHub ethernet plugged into one of the wifi pucks, IP: 192.168.xx
Rasberry Pi IP:: 192.168.yy


Acurite smartHub - v224 (boot firmware v210) - server targeted - 
hubapi.myacurite.com - can see it at its IP number

*
Weewx
Have downloaded and installed Weewx
Have downloaded and configured Interceptor Driver
Have configured Weewx for interceptor driver, device acurite
Have downloaded and installed apache - web server running on port 80: 
Apache/2.4.25 (Raspbian) Server at 192.168.86.yy Port 80

pi@raspberrypi:~ $ sudo tail -f /var/log/syslog
Jun 2 16:18:53 raspberrypi systemd[1]: Started LSB: weewx weather system.
Jun 2 16:18:53 raspberrypi weewx[25630]: engine: Loading station type 
Interceptor (user.interceptor)
Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: driver 
version is 0.45
Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: device 
type: acurite-bridge
Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: sensor 
map: None
Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: mode is 
listen
Jun 2 16:18:53 raspberrypi weewx[25630]: interceptor: MainThread: listen on 
:80
Jun 2 16:18:53 raspberrypi weewx[25630]: import of driver failed: [Errno 
98] Address already in use ()
Jun 2 16:18:53 raspberrypi weewx[25630]: engine: Unable to load driver: 
[Errno 98] Address already in use
Jun 2 16:18:53 raspberrypi weewx[25630]:  Exiting...

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9ec2bbb8-587d-4ab6-bebc-3a1b50e0da5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

Rod,

I've spent quite a bit of time working on a "cleaner" workaround for the WU 
bugs.
But just when I thought I had landed on the "reasonable" approach, I hit a snag.

As a reminder, with the latest approach, all is fine for stations west of the 
UTC date line.   What I am working on now is a workaround for stations east of 
the UTC date line, where the data returned is a day after the date requested.

The wall that I just hit is that the WU behavior around this latest bug 
changes, when looking historically.  :-(

>From today's date going back to 2019-05-28, the query returns obsTimeLocal 
>data from the day after the date requested.  This is the bug we are trying to 
>workaround.
To compensate, I can ask for the prior date to get the date we really want.

HOWEVER, starting with 2019-05-26 (and prior), the query returns obsTimeLocal 
data for the date that was actually requested.

This leads to the inability to get data for 2019-05-27, because the actual 
query for that date returns 2019-05-28 datum, and the compensation date of 
2019-05-26 returns actual data for 2019-05-26.

I think I am done trying to work around this bug.  IBM needs to own it.

See here -- scroll to second to last example where 2019-05-27 is requested, but 
when I tried 2019-05-26, I got back data for the actual 2019-05-26, so 
compensation did not work.  :-(

pi@nixie:/usr/share/weewx4/bin $ /usr/share/weewx4/bin/wunderdates 
--epsilon=125 --date 2019-06-02 --station ISYDNEY155 --test --verbose | (head 
-n 9 ; tail -n 1)
Using configuration file /usr/share/weewx4/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-06-02
WU API obsTimeLocal:   2019-06-03
WU API WRONG DATE !!!
WU API COMPENSATION DATE:  2019-06-01
WU API obsTimeLocal:   2019-06-02
epoch: 1559397600 date_epoch_local: 2019-06-01 10:00:00 tz: Australia/Sydney 
obsTimeUtc: 2019-06-01T14:00:00Z obsTimeLocal: 2019-06-02 00:00:00
epoch: 1559397900 date_epoch_local: 2019-06-01 10:05:00 tz: Australia/Sydney 
obsTimeUtc: 2019-06-01T14:05:00Z obsTimeLocal: 2019-06-02 00:05:00
Number of WU records:  288

pi@nixie:/usr/share/weewx4/bin $ /usr/share/weewx4/bin/wunderdates 
--epsilon=125 --date 2019-06-01 --station ISYDNEY155 --test --verbose | (head 
-n 9 ; tail -n 1)
Using configuration file /usr/share/weewx4/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-06-01
WU API obsTimeLocal:   2019-06-02
WU API WRONG DATE !!!
WU API COMPENSATION DATE:  2019-05-31
WU API obsTimeLocal:   2019-06-01
epoch: 1559311200 date_epoch_local: 2019-05-31 10:00:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-31T14:00:00Z obsTimeLocal: 2019-06-01 00:00:00
epoch: 1559311500 date_epoch_local: 2019-05-31 10:05:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-31T14:05:00Z obsTimeLocal: 2019-06-01 00:05:00
Number of WU records:  288

pi@nixie:/usr/share/weewx4/bin $ /usr/share/weewx4/bin/wunderdates 
--epsilon=125 --date 2019-05-31 --station ISYDNEY155 --test --verbose | (head 
-n 9 ; tail -n 1)
Using configuration file /usr/share/weewx4/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-05-31
WU API obsTimeLocal:   2019-06-01
WU API WRONG DATE !!!
WU API COMPENSATION DATE:  2019-05-30
WU API obsTimeLocal:   2019-05-31
epoch: 1559224800 date_epoch_local: 2019-05-30 10:00:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T14:00:00Z obsTimeLocal: 2019-05-31 00:00:00
epoch: 1559225100 date_epoch_local: 2019-05-30 10:05:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T14:05:00Z obsTimeLocal: 2019-05-31 00:05:00
Number of WU records:  288

pi@nixie:/usr/share/weewx4/bin $ /usr/share/weewx4/bin/wunderdates 
--epsilon=125 --date 2019-05-30 --station ISYDNEY155 --test --verbose | (head 
-n 9 ; tail -n 1)
Using configuration file /usr/share/weewx4/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-05-30
WU API obsTimeLocal:   2019-05-31
WU API WRONG DATE !!!
WU API COMPENSATION DATE:  2019-05-29
WU API obsTimeLocal:   2019-05-30
epoch: 1559138400 date_epoch_local: 2019-05-29 10:00:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-29T14:00:00Z obsTimeLocal: 2019-05-30 00:00:00
epoch: 1559138700 date_epoch_local: 2019-05-29 10:05:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-29T14:05:00Z obsTimeLocal: 2019-05-30 00:05:00
Number of WU records:  288

pi@nixie:/usr/share/weewx4/bin $ /usr/share/weewx4/bin/wunderdates 
--epsilon=125 --date 2019-05-29 --station ISYDNEY155 --test --verbose | (head 
-n 9 ; tail -n 1)
Using configuration file /usr/share/weewx4/weewx.conf.
Weather Underground Station:   ISYDNEY155
Date to check: 2019-05-29
WU API obsTimeLocal:   2019-05-30
WU API WRONG DATE !!!
WU API COMPENSATION DATE:  2019-05-28
WU API 

[weewx-user] Re: Belchertown skin 1.0 released!

[vince]

yes - 8813 was of course a typo in my post, I'm using the default 1883 for 
mosquitto which was fine all the time.

The problem was I didn't know what MQTT topic to subscribe Belchertown to.
Using weather/loop made it work.  Thanks.

(also - Rich's snippet that sets log_success = false for MQTT is really 
helpful, that'll quiet down the syslogs nicely)

Only issue I can find is the skin can't find anything other than the 
top-level page if you run the webserver on an alternate port, but that's 
just an issue for me using Vagrant and mapping ports.  Dunno if it will 
affect too many folks in reality.

Time to move this one to the pi3+ and watch some real data from the 
WeatherFlow.

Thanks !

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2b144e06-efa0-441c-a7cd-ae6d6d103bf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SOLVED - Re: [weewx-user] Re: Dirty shutdown of my Fitlet, can't pull records from VantagePro2 data logger

[John Canfield]

Ah, now that's interesting. Thanks.

John
WB5THT

On 6/2/2019 11:48 AM, John wrote:
I seem to have found another solution, just disable weewx from 
updating the console's clock. It is a setting in the weewx 
configuration file.


On Sunday, June 2, 2019 at 8:55:45 AM UTC-5, John Canfield wrote:

Yes, it does have something to do with timestamps. Boy was I
chasing my tail for several days - bought a new Davis logger and
even bought the WiFi logger to try. I was on the verge of
rebuilding the entire Fitlet and then stumbled on a solution (a
blind chicken finds a piece of corn once in a while .)

My permanent (hopefully) 'fix' is I now have significantly more
UPS reserve minutes that should take me from about 60 minutes to
120-180 minutes.

John
WB5THT

On 6/1/2019 5:47 PM, John wrote:

I think I chased the same ghost a couple times.  What I believe
the underlying problem is has to do with weewx incorrectly
changing the console's clock to an earlier time.  The result is
that the console eventually appends a record to the datalogger
with an earlier timestamp than the previous record.   Weewx
aborts reading the datalogger when it comes across the out of
order timestamp.  Clearing the logger's memory, changing the
recording interval, etc ... gets around the problem, until it
happens again.


On Thursday, May 2, 2019 at 11:13:35 AM UTC-5, John Canfield wrote:

Finally. I've fiddled around so much with this my head is
spinning. weather.janeandjohn.org
 is current again. Hooray!

The short story:

- *the original Davis VP2 console is good*
- *the original Davis USB logger is good*
- did an upgrade to the latest weewx release
- I performed a sudo wee_database --update which caught my
webpage up to April 30, 2019
- restarted weewx and rebooted several times while trying
database commands (wee_database --drop-daily, sudo
wee_database --to=2019-05-02, sudo wee_device --set-interval=1)
- the magic seemed to be sudo wee_device --set-interval=1
which Tom said in another thread cleared the data logger (and
I rebooted again)

So apparently if the database gets screwed up as in not
current with the logger, you (at least me) can go off on a
tangent chasing an interface problem

John (WB5THT)

On Wednesday, May 1, 2019 at 2:34:32 PM UTC-5, John Canfield
wrote:

*This is driving me CRAZY!*
*
*
I thought I found the problem with a UPS monitor daemon
running (I had unplugged the USB cable from the
CyberPower box) - I stopped the process and set it to not
start at boot. Then it looked like weewx was talking to
the console but we had some kind of database problem
since I've been down for several days. It was updating my
web page with old data. Now I'm getting errors like it
can't talk to the logger. I did manage to do a logger
text dump but after fiddling around that won't work now.
I'm really frustrated and it's time to leave it alone and
come back later.

Sigh.

On Wednesday, May 1, 2019 at 12:23:23 PM UTC-5, vince wrote:

On Wednesday, May 1, 2019 at 10:21:15 AM UTC-7, John
Canfield wrote:

The enigma for me then is why does weewx report
the console woke up? A USB problem is the first
thing I thought of as well but the Fitlet does
report when ttyUSB0 is attached to a new port. G.

Thanks Vince, I need all of the help I can get
even though I'm not a weewx newbie - I was one of
Tom's beta testers with one of his first releases.



I think the minicom approach of trying to connect to
the console 'without' weewx is a good one, it's just
that the device might not match the one you're trying
to use.

Try disconnecting the usb then reconnecting it, then
use 'dmesg' to see what device it allocated.

-- 
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/-aw7xfmK7_4/unsubscribe
.
To unsubscribe from this group and all its topics, send an email
to weewx...@googlegroups.com .
To view this discussion on the web visit

https://groups.google.com/d/msgid/weewx-user/7469e457-d7df-4b4e-bdb5-7fc11de81f7f%40googlegroups.com

[weewx-user] Re: Unexpected text traffic

[rich T]

What you are seeing is the data from the ISS every 2.5 seconds (Loop Data) 
and every 5 minutes you see the archive data which is being written to the 
archive database.  

On Sunday, June 2, 2019 at 11:35:37 AM UTC-4, gch...@juno.com wrote:
>
> Hi there.  I'm a newbie to WeeWx.  I have a Davis Instruments Vantage Pro2.
>
> Firstly, let me say, that it seems to be working perfectly. However ...
>
> Since this is my first time using it, I decided to try "Installation using 
> setup.py." This says to "Download the source archive weewx-X.Y.Z.tar.gz 
> from weewx.com/downloads."  I did that and found X.Y.Z == 3.9.1.  I am 
> running Ubuntu 18.04, where the default version of python is 2.7.  Some 
> additional python libraries did need to be downloaded/installed.  
> Thereafter, WeeWx build and install worked fine.  So far, so good.
>
> However, "sudo ./bin/weewxd weewx.conf" produced a Dictionary dump for 
> LOOP every two seconds on the terminal, and for another dictionary less 
> frequently.   I could fix this by doing "sudo ./bin/weewxd weewx.conf 
> >/dev/null 2>&1 &" instead.  However, I don't think I should have to.  I 
> looked at drivers/vantage.py and I couldn't see where it was coming from, 
> so I assume it is coming from the caller.  Perhaps someone on this list can 
> help me track it back?
>
> It looks like the sort of thing that I have done when updating code: 
> adding a debug statement and then forgetting to remove it before submitting 
> the changes.  More likely, I'm doing something wrong.  What is it?
>
> Thanks,
> Gareth.
>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/14b1a4cf-f3a8-4de9-97d6-8c874d4daee1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SOLVED - Re: [weewx-user] Re: Dirty shutdown of my Fitlet, can't pull records from VantagePro2 data logger

[John]

I seem to have found another solution, just disable weewx from updating the 
console's clock. It is a setting in the weewx configuration file.

On Sunday, June 2, 2019 at 8:55:45 AM UTC-5, John Canfield wrote:
>
> Yes, it does have something to do with timestamps. Boy was I chasing my 
> tail for several days - bought a new Davis logger and even bought the WiFi 
> logger to try. I was on the verge of rebuilding the entire Fitlet and then 
> stumbled on a solution (a blind chicken finds a piece of corn once in a 
> while .)
>
> My permanent (hopefully) 'fix' is I now have significantly more UPS 
> reserve minutes that should take me from about 60 minutes to 120-180 
> minutes.
>
> John
> WB5THT
> On 6/1/2019 5:47 PM, John wrote:
>
> I think I chased the same ghost a couple times.  What I believe the 
> underlying problem is has to do with weewx incorrectly changing the 
> console's clock to an earlier time.  The result is that the console 
> eventually appends a record to the datalogger with an earlier timestamp 
> than the previous record.   Weewx aborts reading the datalogger when it 
> comes across the out of order timestamp.  Clearing the logger's memory, 
> changing the recording interval, etc ... gets around the problem, until it 
> happens again.  
>
>
> On Thursday, May 2, 2019 at 11:13:35 AM UTC-5, John Canfield wrote: 
>>
>> Finally. I've fiddled around so much with this my head is spinning. 
>> weather.janeandjohn.org is current again. Hooray!
>>
>> The short story:
>>
>> - *the original Davis VP2 console is good*
>> - *the original Davis USB logger is good*
>> - did an upgrade to the latest weewx release
>> - I performed a sudo wee_database --update which caught my webpage up to 
>> April 30, 2019
>> - restarted weewx and rebooted several times while trying database 
>> commands (wee_database --drop-daily, sudo wee_database --to=2019-05-02, 
>> sudo wee_device --set-interval=1)
>> - the magic seemed to be sudo wee_device --set-interval=1 which Tom said 
>> in another thread cleared the data logger (and I rebooted again)
>>
>> So apparently if the database gets screwed up as in not current with the 
>> logger, you (at least me) can go off on a tangent chasing an interface 
>> problem
>>
>> John (WB5THT)
>>
>> On Wednesday, May 1, 2019 at 2:34:32 PM UTC-5, John Canfield wrote: 
>>>
>>> *This is driving me CRAZY!*
>>>
>>> I thought I found the problem with a UPS monitor daemon running (I had 
>>> unplugged the USB cable from the CyberPower box) - I stopped the process 
>>> and set it to not start at boot. Then it looked like weewx was talking to 
>>> the console but we had some kind of database problem since I've been down 
>>> for several days. It was updating my web page with old data. Now I'm 
>>> getting errors like it can't talk to the logger. I did manage to do a 
>>> logger text dump but after fiddling around that won't work now. I'm really 
>>> frustrated and it's time to leave it alone and come back later.
>>>
>>> Sigh.
>>>
>>> On Wednesday, May 1, 2019 at 12:23:23 PM UTC-5, vince wrote: 

 On Wednesday, May 1, 2019 at 10:21:15 AM UTC-7, John Canfield wrote: 
>
> The enigma for me then is why does weewx report the console woke up? A 
> USB problem is the first thing I thought of as well but the Fitlet does 
> report when ttyUSB0 is attached to a new port. G.
>
> Thanks Vince, I need all of the help I can get even though I'm not a 
> weewx newbie - I was one of Tom's beta testers with one of his first 
> releases.
>
>
>
 I think the minicom approach of trying to connect to the console 
 'without' weewx is a good one, it's just that the device might not match 
 the one you're trying to use.

 Try disconnecting the usb then reconnecting it, then use 'dmesg' to see 
 what device it allocated.

>>> -- 
> 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/-aw7xfmK7_4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/7469e457-d7df-4b4e-bdb5-7fc11de81f7f%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/cd5188c9-06b3-4a85-a9ab-93a7e9f9b62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Unexpected text traffic

[Graham Eddy]

to stop the LOOP packet being printed every couple seconds: in weewx.conf, 
remove weewx.engine.StdPrint from report_services. you almost certainly do not 
want to do this while testing and running weewx in foreground, as seeing the 
LOOP packets is important to debugging

when you are happy weewx is running as you want, set it up as a daemon per 
instructions (details depend on your operating system e.g. linux derivatives, 
macOS) - daemons have no stdin/stdout/stderr

Graham Eddy

> On 3 Jun 2019, at 1:51 am, Jardi Martínez  wrote:
> 
> On Sun, Jun 2, 2019, 8:35 AM gch...@juno.com  
> mailto:gch...@juno.com>> wrote:
> Hi there.  I'm a newbie to WeeWx.  I have a Davis Instruments Vantage Pro2.
> 
> Firstly, let me say, that it seems to be working perfectly. However ...
> 
> Since this is my first time using it, I decided to try "Installation using 
> setup.py." This says to "Download the source archive weewx-X.Y.Z.tar.gz from 
> weewx.com/downloads ."  I did that and found 
> X.Y.Z == 3.9.1.  I am running Ubuntu 18.04, where the default version of 
> python is 2.7.  Some additional python libraries did need to be 
> downloaded/installed.  Thereafter, WeeWx build and install worked fine.  So 
> far, so good.
> 
> However, "sudo ./bin/weewxd weewx.conf" produced a Dictionary dump for LOOP 
> every two seconds on the terminal, and for another dictionary less 
> frequently.   I could fix this by doing "sudo ./bin/weewxd weewx.conf 
> >/dev/null 2>&1 &" instead.  However, I don't think I should have to.  I 
> looked at drivers/vantage.py and I couldn't see where it was coming from, so 
> I assume it is coming from the caller.  Perhaps someone on this list can help 
> me track it back?
> 
> 
> Run it as a daemon, the instructions are on the same page as the installation 
> instructions:
> http://www.weewx.com/docs/setup.htm 
> 
> Jardi.
> 
> 
> -- 
> 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...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAETA7dS8Zj824-aTR-e3COMg-YenSVNeySH7Gd7MnGFGyn9T%2Bw%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2CC21A50-E356-4BC2-A631-BE989776EF50%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Unexpected text traffic

[Jardi Martínez]

On Sun, Jun 2, 2019, 8:35 AM gch...@juno.com  wrote:

> Hi there.  I'm a newbie to WeeWx.  I have a Davis Instruments Vantage Pro2.
>
> Firstly, let me say, that it seems to be working perfectly. However ...
>
> Since this is my first time using it, I decided to try "Installation using
> setup.py." This says to "Download the source archive weewx-X.Y.Z.tar.gz
> from weewx.com/downloads."  I did that and found X.Y.Z == 3.9.1.  I am
> running Ubuntu 18.04, where the default version of python is 2.7.  Some
> additional python libraries did need to be downloaded/installed.
> Thereafter, WeeWx build and install worked fine.  So far, so good.
>
> However, "sudo ./bin/weewxd weewx.conf" produced a Dictionary dump for
> LOOP every two seconds on the terminal, and for another dictionary less
> frequently.   I could fix this by doing "sudo ./bin/weewxd weewx.conf
> >/dev/null 2>&1 &" instead.  However, I don't think I should have to.  I
> looked at drivers/vantage.py and I couldn't see where it was coming from,
> so I assume it is coming from the caller.  Perhaps someone on this list can
> help me track it back?
>


Run it as a daemon, the instructions are on the same page as the
installation instructions:
http://www.weewx.com/docs/setup.htm

Jardi.

>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAETA7dS8Zj824-aTR-e3COMg-YenSVNeySH7Gd7MnGFGyn9T%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Unexpected text traffic

[gch...@juno.com]

Hi there.  I'm a newbie to WeeWx.  I have a Davis Instruments Vantage Pro2.

Firstly, let me say, that it seems to be working perfectly. However ...

Since this is my first time using it, I decided to try "Installation using 
setup.py." This says to "Download the source archive weewx-X.Y.Z.tar.gz from 
weewx.com/downloads."  I did that and found X.Y.Z == 3.9.1.  I am running 
Ubuntu 
18.04, where the default version of python is 2.7.  Some additional python 
libraries did need to be downloaded/installed.  Thereafter, WeeWx build and 
install worked fine.  So far, so good.

However, "sudo ./bin/weewxd weewx.conf" produced a Dictionary dump for LOOP 
every two seconds on the terminal, and for another dictionary less 
frequently.   I could fix this by doing "sudo ./bin/weewxd weewx.conf 
>/dev/null 2>&1 &" instead.  However, I don't think I should have to.  I 
looked at drivers/vantage.py and I couldn't see where it was coming from, 
so I assume it is coming from the caller.  Perhaps someone on this list can 
help me track it back?

It looks like the sort of thing that I have done when updating code: adding 
a debug statement and then forgetting to remove it before submitting the 
changes.  More likely, I'm doing something wrong.  What is it?

Thanks,
Gareth.

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/cfc4b7d9-08f0-4b5a-b7b7-7559ff1f08b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Vaisala WXT520

[Andrej B.]

Hello,

Looking for Vaisala configuration tool for WXT520 weather transmitter.

Thanks

Andrej

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/39cf4b12-c840-4930-88d9-11e64b192ed9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SOLVED - Re: [weewx-user] Re: Dirty shutdown of my Fitlet, can't pull records from VantagePro2 data logger

[John Canfield]

Yes, it does have something to do with timestamps. Boy was I chasing my 
tail for several days - bought a new Davis logger and even bought the 
WiFi logger to try. I was on the verge of rebuilding the entire Fitlet 
and then stumbled on a solution (a blind chicken finds a piece of corn 
once in a while .)


My permanent (hopefully) 'fix' is I now have significantly more UPS 
reserve minutes that should take me from about 60 minutes to 120-180 
minutes.


John
WB5THT

On 6/1/2019 5:47 PM, John wrote:
I think I chased the same ghost a couple times. What I believe the 
underlying problem is has to do with weewx incorrectly changing the 
console's clock to an earlier time. The result is that the console 
eventually appends a record to the datalogger with an earlier 
timestamp than the previous record.   Weewx aborts reading the 
datalogger when it comes across the out of order timestamp.  Clearing 
the logger's memory, changing the recording interval, etc ... gets 
around the problem, until it happens again.



On Thursday, May 2, 2019 at 11:13:35 AM UTC-5, John Canfield wrote:

Finally. I've fiddled around so much with this my head is
spinning. weather.janeandjohn.org 
is current again. Hooray!

The short story:

- *the original Davis VP2 console is good*
- *the original Davis USB logger is good*
- did an upgrade to the latest weewx release
- I performed a sudo wee_database --update which caught my webpage
up to April 30, 2019
- restarted weewx and rebooted several times while trying database
commands (wee_database --drop-daily, sudo wee_database
--to=2019-05-02, sudo wee_device --set-interval=1)
- the magic seemed to be sudo wee_device --set-interval=1 which
Tom said in another thread cleared the data logger (and I rebooted
again)

So apparently if the database gets screwed up as in not current
with the logger, you (at least me) can go off on a tangent chasing
an interface problem

John (WB5THT)

On Wednesday, May 1, 2019 at 2:34:32 PM UTC-5, John Canfield wrote:

*This is driving me CRAZY!*
*
*
I thought I found the problem with a UPS monitor daemon
running (I had unplugged the USB cable from the CyberPower
box) - I stopped the process and set it to not start at boot.
Then it looked like weewx was talking to the console but we
had some kind of database problem since I've been down for
several days. It was updating my web page with old data. Now
I'm getting errors like it can't talk to the logger. I did
manage to do a logger text dump but after fiddling around that
won't work now. I'm really frustrated and it's time to leave
it alone and come back later.

Sigh.

On Wednesday, May 1, 2019 at 12:23:23 PM UTC-5, vince wrote:

On Wednesday, May 1, 2019 at 10:21:15 AM UTC-7, John
Canfield wrote:

The enigma for me then is why does weewx report the
console woke up? A USB problem is the first thing I
thought of as well but the Fitlet does report when
ttyUSB0 is attached to a new port. G.

Thanks Vince, I need all of the help I can get even
though I'm not a weewx newbie - I was one of Tom's
beta testers with one of his first releases.



I think the minicom approach of trying to connect to the
console 'without' weewx is a good one, it's just that the
device might not match the one you're trying to use.

Try disconnecting the usb then reconnecting it, then use
'dmesg' to see what device it allocated.

--
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/-aw7xfmK7_4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
weewx-user+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7469e457-d7df-4b4e-bdb5-7fc11de81f7f%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/10c90cb3-4a2e-31ed-1456-42f5fe2d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Connect Froggit WH3000SE weatherstation to weewx

[METEO SANTA SUSANNA]

Hallo

ich habe eine Froggit WH3000 und leider ständig Probleme mit WU. Wie kann 
ich meine Wetterdaten zb. per Weewx selbst auf eine eigene Website spielen. 
Mein Router ist eine FRITZBOX. Wie macht man da das mit dem weiterleiten 
der ip Adresse?

mfg

Otmar Schuster


El viernes, 26 de octubre de 2018, 14:01:27 (UTC+2), Bernd Mohr escribió:
>
> Hey Ronald,
>
> sorry, I was on vacation the past two weeks :-) 
>
> Ok, I´ll give it a try to explain you my method in English. (I´m from 
> Germany, so please have indulgence if one or the other sentence sounds 
> funny for you) :-)
>
> Let´s try with the Basics: Your Froggit WH4000 is up and running and 
> connected to your router, correct? And you are running weewx somewhere in 
> your network.
> For the installation of weewx I do not go into detail now, because there 
> are enough instructions on the internet ;-)
>
> if so, you have to "catch" the Wifi Packages between your console and your 
> router. In my case I had to buy another router (Asus rt-66u) because my 
> actual router can´t handle ip tables.
> Your console send´s the data packages via port 80 to your router. After I 
> know that, I installed wrt Merlin Firmware to my Asus router. 
> After that, logon to your router and enable under administration --> 
> system --> JFFS custom scripts or in case of another router, the ability to 
> handle iptables. 
> now you have to send the weather data packages to your weewx server. (In 
> my case Raspberry Pi 3+).
> it is important to send both kinds of packages like this:
>
> iptables -t mangle -A PREROUTING  -s 192.168.1.33 -j ROUTE --tee --gw 
> 192.168.1.76
>
> iptables -t mangle -A POSTROUTING -d 192.168.1.33 -j ROUTE --tee --gw 
> 192.168.1.76
>
>
> In this case the first ip is my WH3000 Console, and the second one is my 
> weewx server. Please replace it to your ip adresses ;-) 
>
> Of course, at this point it is very useful if you give your router in your 
> router and the weewx server a fixed ip address.
>
>
> To be able to parse this weather packages on your weewx server, you habe 
> to install and enable the interceptor driver. 
>
> I hope you are familiar with Linux console? If so, it is easy for you to 
> install the interceptor driver. In my case I used the following manual:
>
>
> https://github.com/matthewwall/weewx-interceptor
>
>
> Little hint: At point 2, as I remember, the name of the package was wrong. 
> Maybe you have to delete the last word -master to install the driver. 
>
> Please, give it a try ;-) 
>
>
> Now you have to configure the weewx interceptor driver in your weewx.conf 
> You have to change station_type like this:
>
>  station_type = Interceptor
>
>
> and at the end of weewx.conf copy and paste this part here: (Replace the 
> ip adress of your console)
>
>
> [Interceptor]
>
> # This section is for the network traffic interceptor driver.
>
> 
>
> # The driver to use:
>
> driver = user.interceptor
>
> 
>
> # Specify the hardware device to capture.  Options include:
>
> #   acurite-bridge - acurite internet bridge
>
> #   observer - fine offset WH2600/HP1000/HP1003, aka 'observer'
>
> #   lw30x - oregon scientific LW301/LW302
>
> #   lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge
>
> device_type = observer
>
> mode = sniff
>
> iface = eth0
>
> pcap_filter = src 192.168.1.33 and dst port 80
>
>
> To check if everything is working fine, you can set the parameter: debug = 
> 1 in your weewx.conf
>
> In best case, when you have a look at your syslog, you can see a lot of 
> weather data packages ;-)
>
> To have a look at syslog --> tail -f /var/log/syslog 
>
>
> Please remember you have to restart weewx after changing the weewx.conf to 
> take effect.
>
>
> i think, this is the most important part for the beginning. I optimized 
> other little things for a durable running. 
>
> Please do not hesitate to ask further questions, I´ll try to help you if I 
> can :-)
>
>
> Cheers,
>
>
> Bernd 
>
>
>
> 22/5000
>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2cf45b81-63b0-46e3-84c6-f305d9717e4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Trouble setting up Highcharts

[steeple ian]

Hi Gary,

All working thanks to your hints.

It did not like these two lines in graphs.html: -




I dropped the ../ in front and hey presto! I knew it would be something so
obvious that I had not spotted.

Thanks once again.

Ian



On Sun, Jun 2, 2019 at 7:27 AM steeple ian  wrote:

> Gary,
>
> Thanks for your detailed response. It is on my test server which it is no
> public facing. I will give it another go using your hints. If I continue to
> fail I will install on my public server to let you have a look.
>
> Thanks again,
> Ian
>
> On Sun, 2 Jun 2019 at 02:38, gjr80  wrote:
>
>> Ian,
>>
>> The two main parts to the Highcharts extension are the WeeWX skin that
>> generates the json format data file and the html/javascript that displays
>> the plot(s). WeeWX only real involvement is the generation of the json
>> format data file, nothing fancy there and 3.9.1 should be compatible with
>> the skin. The only issue I can think of here is perhaps the new skin config
>> sitting hierarchy introduced in WeeWX 3.9.0, but that would likely only (at
>> worst) result in unexpected number formats or units. If your json file is
>> being generated without error it should be usable (a useful tool for
>> checking your json output is one of the online json validators, I use
>> jsonlint.com, just open the validator page, copy the contents f your
>> json format file and paste into the validator, hit the button and it gives
>> you a yay or nay.
>>
>> Given your description, it sounds like a javascript issue on your page.
>> Easiest way to troubleshoot Highcharts is to through your browsers
>> console/web console. where you can see any javascript errors. Where to find
>> the console is browser dependent, I mainly use Firefox and it is under Web
>> Developer -> Web Console or Web Developer -> Browser Console.Under Chrome
>> it is under More Tools -> Developer Tools. Once you have the console open,
>> clear it if it has any content and then force a reload of your html. Then
>> its a case of looking for any (relevant) errors in the console output.
>> Likely errors are a script (including Highcharts) loaded by the page being
>> unable to be found, a script being unable to locate a file or Highcharts
>> choking on incorrect data/settings in a file.
>>
>> If your graph page is public facing if you are happy to give us the
>> address I can look at the javascript console myself.
>>
>> Gary
>>
>> On Saturday, 1 June 2019 19:14:12 UTC+10, steeple ian wrote:
>>>
>>> Gary,
>>>
>>> I installed Highcharts extension a couple of years ago without any
>>> problem. Since then after a couple or so of re-builds of my system, the
>>> extension was never re-installed. I now want to revisit some of what I did
>>> before and re-installed the extension. For the life of me I cannot get it
>>> to work. The generation of the json data files is happening, but when it
>>> comes to using the example graphs.html web page, no charts are rendered.
>>>
>>> I have gone through the logs and nothing jumps out at me. I have
>>> uninstalled/reinstalled a couple of times to no avail. Have checked all the
>>> paths, again nothing obvious turns up. The only difference from my previous
>>> set up was obviously an older version of WeeWX via a Deb install, whereas
>>> now I am using 3.9.1 via a setup.py install.
>>>
>>> It looks like I am missing something very obvious, but its just not
>>> jumping out at me.
>>>
>>> Thanks,
>>> Ian
>>>
>>>
>>>
>>>
>>>
>>> --
>> 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...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/43f50af3-38c6-41a4-84e6-e8eb58c3599e%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CADASSaQYkEaeh16%3DXrrNkkPKsgyq9Az5gq%3DRA-%2Bv8RSE-uE5kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Trouble setting up Highcharts

[steeple ian]

Gary,

Thanks for your detailed response. It is on my test server which it is no
public facing. I will give it another go using your hints. If I continue to
fail I will install on my public server to let you have a look.

Thanks again,
Ian

On Sun, 2 Jun 2019 at 02:38, gjr80  wrote:

> Ian,
>
> The two main parts to the Highcharts extension are the WeeWX skin that
> generates the json format data file and the html/javascript that displays
> the plot(s). WeeWX only real involvement is the generation of the json
> format data file, nothing fancy there and 3.9.1 should be compatible with
> the skin. The only issue I can think of here is perhaps the new skin config
> sitting hierarchy introduced in WeeWX 3.9.0, but that would likely only (at
> worst) result in unexpected number formats or units. If your json file is
> being generated without error it should be usable (a useful tool for
> checking your json output is one of the online json validators, I use
> jsonlint.com, just open the validator page, copy the contents f your json
> format file and paste into the validator, hit the button and it gives you a
> yay or nay.
>
> Given your description, it sounds like a javascript issue on your page.
> Easiest way to troubleshoot Highcharts is to through your browsers
> console/web console. where you can see any javascript errors. Where to find
> the console is browser dependent, I mainly use Firefox and it is under Web
> Developer -> Web Console or Web Developer -> Browser Console.Under Chrome
> it is under More Tools -> Developer Tools. Once you have the console open,
> clear it if it has any content and then force a reload of your html. Then
> its a case of looking for any (relevant) errors in the console output.
> Likely errors are a script (including Highcharts) loaded by the page being
> unable to be found, a script being unable to locate a file or Highcharts
> choking on incorrect data/settings in a file.
>
> If your graph page is public facing if you are happy to give us the
> address I can look at the javascript console myself.
>
> Gary
>
> On Saturday, 1 June 2019 19:14:12 UTC+10, steeple ian wrote:
>>
>> Gary,
>>
>> I installed Highcharts extension a couple of years ago without any
>> problem. Since then after a couple or so of re-builds of my system, the
>> extension was never re-installed. I now want to revisit some of what I did
>> before and re-installed the extension. For the life of me I cannot get it
>> to work. The generation of the json data files is happening, but when it
>> comes to using the example graphs.html web page, no charts are rendered.
>>
>> I have gone through the logs and nothing jumps out at me. I have
>> uninstalled/reinstalled a couple of times to no avail. Have checked all the
>> paths, again nothing obvious turns up. The only difference from my previous
>> set up was obviously an older version of WeeWX via a Deb install, whereas
>> now I am using 3.9.1 via a setup.py install.
>>
>> It looks like I am missing something very obvious, but its just not
>> jumping out at me.
>>
>> Thanks,
>> Ian
>>
>>
>>
>>
>>
>> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/43f50af3-38c6-41a4-84e6-e8eb58c3599e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CADASSaRF0jZg%2BJC2ZtRkkQmQnEz7i%3DD7R7cx1r%3DPJufcL%3D-drA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.