Re: [weewx-user] Thanks a Lot Darksky (NOT!!)

[Philip Kutzenco]

Hmm. I think galfert is correct. I believe as long as your weewx 
implementation is sending "quality data to pwsweather.com monthly, use of 
the API is free. Sorry for the false alarm.

On Friday, April 24, 2020 at 12:49:03 PM UTC-4, Philip Kutzenco wrote:
>
> I signed up. However, it looks to me that having a PWSweather account lets 
> you get an Aeris Weather account (which is linked), but when I go to the 
> API site with that account, they only offer a 30 day free trial. After that 
> there is a monthly or annual cost.for the API subscription. Am I missing 
> something?
>
> On Thursday, April 23, 2020 at 1:25:18 PM UTC-4, galfert wrote:
>>
>> Aeris Weather seems to be a replacement for Dark Sky that people are 
>> going with. If you upload to PWSweather then you can get a free API key to 
>> Aeris Weather.
>> https://www.aerisweather.com/signup/pws/
>>
>>

-- 
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/91518c36-c95e-4daa-8741-b33ed0a06638%40googlegroups.com.

Re: [weewx-user] Thanks a Lot Darksky (NOT!!)

[Philip Kutzenco]

I signed up. However, it looks to me that having a PWSweather account lets 
you get an Aeris Weather account (which is linked), but when I go to the 
API site with that account, they only offer a 30 day free trial. After that 
there is a monthly or annual cost.for the API subscription. Am I missing 
something?

On Thursday, April 23, 2020 at 1:25:18 PM UTC-4, galfert wrote:
>
> Aeris Weather seems to be a replacement for Dark Sky that people are going 
> with. If you upload to PWSweather then you can get a free API key to Aeris 
> Weather.
> https://www.aerisweather.com/signup/pws/
>
>

-- 
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/ef73fd6a-0d5b-4494-9d88-87274b891274%40googlegroups.com.

[weewx-user] Re: it misses the time display and forecasts

[Philip Kutzenco]

OK. Great that it is working for you!
phil

On Monday, May 13, 2019 at 1:58:58 PM UTC-4, Patrick Tranchant wrote:
>
> sorry, 
>
> I don't know that he did but it works .
>
>
> On Monday, May 13, 2019 at 7:55:30 PM UTC+2, Patrick Tranchant wrote:
>>
>> hello Philip
>>
>> see end pf page of code source  : 
>>
>>   
>>
>> but it is OK now, PAT watched my website the last week, I don't know that I 
>> done but it works .
>> Thanks for you
>> Patrick
>>
>>
>> On Monday, May 13, 2019 at 7:02:14 PM UTC+2, Philip Kutzenco wrote:
>>>
>>> Patrick,
>>>
>>> What version of the Belchertown skin are you using? If you restart WeeWX 
>>> and capture the syslog, it should show the version the first time the skin 
>>> executes. Alternatively, on your web page do a View Page Source and scroll 
>>> to the bottom. You'll see the version there.
>>>
>>> On Monday, May 6, 2019 at 2:03:48 PM UTC-4, Patrick Tranchant wrote:
>>>>
>>>> hi every body,
>>>>
>>>> since yesterday , I had this with skin "Belchertown"; it is ok with 
>>>> skin "Seasons".
>>>>
>>>> it misses the time display and forecasts and graphs on home page !!!
>>>> an idea, the logs are corrects for Belchertown
>>>>
>>>> May  6 20:00:16 raspberrypi weewx[22084]: manager: Added record 
>>>> 2019-05-06 20:00:00 CEST (1557165600) to database 'weewx.sdb'
>>>> May  6 20:00:16 raspberrypi weewx[22084]: manager: Added record 
>>>> 2019-05-06 20:00:00 CEST (1557165600) to daily summary in 'weewx.sdb'
>>>> May  6 20:00:19 raspberrypi weewx[22084]: cheetahgenerator: Generated 8 
>>>> files for report SeasonsReport in 2.81 seconds
>>>> May  6 20:00:26 raspberrypi weewx[22084]: imagegenerator: Generated 28 
>>>> images for SeasonsReport in 6.47 seconds
>>>> May  6 20:00:26 raspberrypi weewx[22084]: copygenerator: copied 0 files 
>>>> to /var/www/html/weewx
>>>> May  6 20:00:26 raspberrypi weewx[22084]: cheetahgenerator: Generated 7 
>>>> files for report SmartphoneReport in 0.23 seconds
>>>> May  6 20:00:29 raspberrypi weewx[22084]: imagegenerator: Generated 14 
>>>> images for SmartphoneReport in 2.88 seconds
>>>> May  6 20:00:29 raspberrypi weewx[22084]: copygenerator: copied 0 files 
>>>> to /var/www/html/weewx/smartphone
>>>> May  6 20:00:29 raspberrypi weewx[22084]: cheetahgenerator: Generated 1 
>>>> files for report MobileReport in 0.08 seconds
>>>> May  6 20:00:30 raspberrypi weewx[22084]: imagegenerator: Generated 4 
>>>> images for MobileReport in 0.53 seconds
>>>> May  6 20:00:30 raspberrypi weewx[22084]: copygenerator: copied 0 files 
>>>> to /var/www/html/weewx/mobile
>>>> May  6 20:00:31 raspberrypi weewx[22084]: Belchertown Extension: New 
>>>> forecast file downloaded to 
>>>> /var/www/html/weewx/belchertown/json/darksky_forecast.json
>>>> May  6 20:00:34 raspberrypi weewx[22084]: cheetahgenerator: Generated 
>>>> 14 files for report Belchertown in 3.73 seconds
>>>> May  6 20:00:34 raspberrypi weewx[22084]: copygenerator: copied 1 files 
>>>> to /var/www/html/weewx/belchertown
>>>> May  6 20:00:50 raspberrypi weewx[22084]: cheetahgenerator: Generated 4 
>>>> files for report Highcharts_Belchertown in 16.39 seconds
>>>> May  6 20:00:50 raspberrypi weewx[22084]: copygenerator: copied 0 files 
>>>> to /var/www/html/weewx/belchertown
>>>>
>>>>
>>>> Patrick
>>>>
>>>

-- 
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/1796024b-b50f-4d40-822b-a62d5bc4bf88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: it misses the time display and forecasts

[Philip Kutzenco]

Patrick,

What version of the Belchertown skin are you using? If you restart WeeWX 
and capture the syslog, it should show the version the first time the skin 
executes. Alternatively, on your web page do a View Page Source and scroll 
to the bottom. You'll see the version there.

On Monday, May 6, 2019 at 2:03:48 PM UTC-4, Patrick Tranchant wrote:
>
> hi every body,
>
> since yesterday , I had this with skin "Belchertown"; it is ok with skin 
> "Seasons".
>
> it misses the time display and forecasts and graphs on home page !!!
> an idea, the logs are corrects for Belchertown
>
> May  6 20:00:16 raspberrypi weewx[22084]: manager: Added record 2019-05-06 
> 20:00:00 CEST (1557165600) to database 'weewx.sdb'
> May  6 20:00:16 raspberrypi weewx[22084]: manager: Added record 2019-05-06 
> 20:00:00 CEST (1557165600) to daily summary in 'weewx.sdb'
> May  6 20:00:19 raspberrypi weewx[22084]: cheetahgenerator: Generated 8 
> files for report SeasonsReport in 2.81 seconds
> May  6 20:00:26 raspberrypi weewx[22084]: imagegenerator: Generated 28 
> images for SeasonsReport in 6.47 seconds
> May  6 20:00:26 raspberrypi weewx[22084]: copygenerator: copied 0 files to 
> /var/www/html/weewx
> May  6 20:00:26 raspberrypi weewx[22084]: cheetahgenerator: Generated 7 
> files for report SmartphoneReport in 0.23 seconds
> May  6 20:00:29 raspberrypi weewx[22084]: imagegenerator: Generated 14 
> images for SmartphoneReport in 2.88 seconds
> May  6 20:00:29 raspberrypi weewx[22084]: copygenerator: copied 0 files to 
> /var/www/html/weewx/smartphone
> May  6 20:00:29 raspberrypi weewx[22084]: cheetahgenerator: Generated 1 
> files for report MobileReport in 0.08 seconds
> May  6 20:00:30 raspberrypi weewx[22084]: imagegenerator: Generated 4 
> images for MobileReport in 0.53 seconds
> May  6 20:00:30 raspberrypi weewx[22084]: copygenerator: copied 0 files to 
> /var/www/html/weewx/mobile
> May  6 20:00:31 raspberrypi weewx[22084]: Belchertown Extension: New 
> forecast file downloaded to 
> /var/www/html/weewx/belchertown/json/darksky_forecast.json
> May  6 20:00:34 raspberrypi weewx[22084]: cheetahgenerator: Generated 14 
> files for report Belchertown in 3.73 seconds
> May  6 20:00:34 raspberrypi weewx[22084]: copygenerator: copied 1 files to 
> /var/www/html/weewx/belchertown
> May  6 20:00:50 raspberrypi weewx[22084]: cheetahgenerator: Generated 4 
> files for report Highcharts_Belchertown in 16.39 seconds
> May  6 20:00:50 raspberrypi weewx[22084]: copygenerator: copied 0 files to 
> /var/www/html/weewx/belchertown
>
>
> Patrick
>

-- 
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/7cc836a1-a8d2-4665-8fb5-9eb89e101eb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] one computer to retrieve/store data, another to process/generate reports

[kutzenco]

Pat O'Brien's Belchertown skin has an option in his soon-to-be released V1 
that allows you to display a Wind Rose! You can see what that looks like at 
his site - https://belchertownweather.com/ and also at mine - 
https://wx.kutzenco.com both of which running V1rc7 of the Belchertown skin.

Belchertown V1rc (still in testing) is available at 
https://github.com/poblabs/weewx-belchertown/tree/development. 
Please note 
that if you are currently running the Belchertown skin and wish to upgrade 
to the Version 1 release candidate, you should remove the old version first.

Lots has changed and documentation is still being written - some of it is 
now on the wiki page for the skin - in particular see this wiki page for 
information on how to upgrade to V1 
https://github.com/poblabs/weewx-belchertown/wiki/Upgrading-to-Belchertown-skin-1.0.
 
This wiki page describes how to define and format the graphs - 
https://github.com/poblabs/weewx-belchertown/wiki/Belchertown-Charts-Documentation
 
in the skin. 

phil


On Thursday, April 11, 2019 at 5:04:27 AM UTC-4, gjr80 wrote:
>
> On Wednesday, 10 April 2019 11:30:53 UTC+10, Your Name Here wrote:
>>
>> Okay, since my attempts aren't showing but this is:
>>
>>  I am still trying to figure out how to get a wind rose scatter plot like 
>> Weather Display has (like this 
>> 
>>  and this ). 
>>
>> This MathWorks site has an entry 
>> 
>>  for 
>> the math to make a very nice wind rose scatter plot 
>> 
>> . 
>>
>> Can someone please help me out?
>>
>
> The only currently available polar wind plot generator for WeeWX that I am 
> aware is the stackedwindrose generator that we included as part of 
> WeeWX-WD. It generates a traditional windrose plot as shown at the bottom 
> of this page . 
> Despite it being included in WeeWX-WD it is very simple to extract and use 
> just the windrose generator if you want.
>
> Neil and I have been working on a polar wind plot generator 
>  that will also produce 
> various other polar wind plots (what we call scatter, trail and spiral 
> plots). Unfortunately I don't have any example plots to hand to show you. 
> We've been working on and off on the polar wind plot generator for the last 
> couple of years and whilst it mostly works there are still a few issues to 
> iron out before release. At the moment I don't have much time to take it 
> further so I can't say when it will be in a state fit for release.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Belchertown Skin and CWOP Pressure Difference

[kutzenco]

I see that you upload to several other services (PWS, WU and Weathercloud). 
Are they getting the same barometer values as CWOP? 

I would also look at the weewx.sdb database with sqlite3 to see what the 
actual archived value is at a particular time (like 8pm tonight) and 
compare it to the values on the Belchertown skin and on the various 
external services you've uploaded to.

Is there some offset you've applied to the barometric pressure on your 
Accurite?

For what it is worth, my upload to CWOP gives a barometric pressure reading 
within .01 inHg of what my Belchertown skin shows (https://wx.kutzenco.com). 
I attribute the difference to conversion. I think CWOP stores data as 
millibar and the findU display converts that to inHg (I may be wrong). 

phil

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

[weewx-user] Re: Belchertown Skin and CWOP Pressure Difference

[kutzenco]

So the Belchertown skin is showing the MQTT return, which is the latest 
LOOP value. I could be wrong, but I suspect the Standard skin, and the 
upload to CWOP are values from the last archive value stored in weewx.sdb.

phil

On Thursday, March 28, 2019 at 5:12:51 PM UTC-4, Chris Plant wrote:
>
> Hello, 
>
> [image: belchertownbarometer.JPG]
>
> [image: cwopbarometer.JPG]
> Just wondering if someone could clue me in as to why the Belchertown skin 
> is showing my barometer .03 more inHg than the data thats being uploaded to 
> CWOP and other providers. When i change my skin to the "Standard", they 
> then match.  Is it something in the programming or are they values not 
> really the same thing?
>
> Chris
> https://www.knowltonweather.com
>
>
>
>

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

Re: [weewx-user] web page not updating under 3.9.1

[kutzenco]

Orv, For me, adding   under the 
 section of index.html.tmpl for the Seasons skin does, indeed refresh 
the page every 60 seconds. Not sure why it doesn't for you.

phil


On Wednesday, March 27, 2019 at 3:13:30 PM UTC-4, Orv Beach wrote:
>
> OK, Seasons skins use javascript.  In order to make the Seasons page 
> refresh every 5 minutes, I had to put this code at the end of seasons.js:
>
> 
> 
> 
>
> Orv
>
> On Wednesday, March 27, 2019 at 11:29:30 AM UTC-7, Orv Beach wrote:
>>
>> Nope still not working - still investigating...
>>
>> On Wednesday, March 27, 2019 at 11:24:55 AM UTC-7, Orv Beach wrote:
>>>
>>> I found the issue.  This freshly installed version of weewx defaults to 
>>> the Seasons skin rather than the Standard skin.
>>>
>>> So in order to refresh the main page every fine minutes the line 
>>>
>>> 
>>>
>>> had to go in to the file /etc/weewx/skins/Seasons/index.html.tmpl
>>>
>>> instead of the index template for the Standard skin.
>>>
>>> Orv
>>>
>>>
>>> On Sunday, March 24, 2019 at 5:32:21 AM UTC-7, Thomas Keffer wrote:

 We'll need more information than this. Please post your log. See the 
 wiki *Help! 
 * for 
 how to post a good log.

 Also, what do you mean by "nor does the page source show that line as 
 it used to"?

 -tk

 On Sat, Mar 23, 2019 at 9:01 PM Orv Beach  wrote:

> With this line in index.html.tmpl:
>
> 
>
> my main weewx page (vers 3.9.1 running on Raspbian Stretch), Standard 
> skin, updated just fine.
>
> After migrating to version 3.9.1 running under Debian Stretch, with 
> that same line in /etc/weewx/skins/Standard/index.html.tmpl the main page 
> no longer updates every 300 seconds, nor does the page source show that 
> line as it used to.  It's still the Standard skin, but it no longer looks 
> like it did under Raspbian.
>
> Any suggestions?
>
> 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+...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown skin 0.9 now available

[kutzenco]

Patrick, Note that your syslog shows:

Mar 11 20:31:20 raspberrypi weewx[27077]: engine: Launch of report thread 
> aborted: existing report thread still running
>

You may have an issue where weewx is unable to complete it's work between 
archive intervals. What is your archive interval and what hardware are you 
running weewx on?

Phil

On Monday, March 11, 2019 at 3:34:18 PM UTC-4, Patrick Tranchant wrote:
>
>  no, nothings for me
>
> Mar 11 20:31:18 raspberrypi weewx[27077]: Belchertown Extension: version 
> 0.9.1
> Mar 11 20:31:20 raspberrypi weewx[27077]: manager: Added record 2019-03-11 
> 20:31:00 CET (1552332660) to database 'weewx.sdb'
> Mar 11 20:31:20 raspberrypi weewx[27077]: manager: Added record 2019-03-11 
> 20:31:00 CET (1552332660) to daily summary in 'weewx.sdb'
> Mar 11 20:31:20 raspberrypi weewx[27077]: engine: Launch of report thread 
> aborted: existing report thread still running
> Mar 11 20:31:38 raspberrypi weewx[27077]: cheetahgenerator: Generated 14 
> files for report Belchertown in 20.23 seconds
> Mar 11 20:31:38 raspberrypi weewx[27077]: copygenerator: copied 31 files 
> to /var/www/html/weewx/belchertown
> Mar 11 20:32:18 raspberrypi weewx[27077]: manager: Added record 2019-03-11 
> 20:32:00 CET (1552332720) to database 'weewx.sdb'
> Mar 11 20:32:18 raspberrypi weewx[27077]: manager: Added record 2019-03-11 
> 20:32:00 CET (1552332720) to daily summary in 'weewx.sdb'
> Mar 11 20:32:23 raspberrypi weewx[27077]: cheetahgenerator: Generated 8 
> files for report SeasonsReport in 4.31 seconds
> Mar 11 20:32:26 raspberrypi weewx[27077]: imagegenerator: Generated 14 
> images for SeasonsReport in 2.51 seconds
> Mar 11 20:32:26 raspberrypi weewx[27077]: copygenerator: copied 0 files to 
> /var/www/html/weewx
> Mar 11 20:32:26 raspberrypi weewx[27077]: cheetahgenerator: Generated 7 
> files for report SmartphoneReport in 0.33 seconds
> Mar 11 20:32:27 raspberrypi weewx[27077]: imagegenerator: Generated 7 
> images for SmartphoneReport in 1.08 seconds
> Mar 11 20:32:27 raspberrypi weewx[27077]: copygenerator: copied 0 files to 
> /var/www/html/weewx/smartphone
> Mar 11 20:32:27 raspberrypi weewx[27077]: cheetahgenerator: Generated 1 
> files for report MobileReport in 0.11 seconds
> Mar 11 20:32:28 raspberrypi weewx[27077]: imagegenerator: Generated 4 
> images for MobileReport in 0.69 seconds
> Mar 11 20:32:28 raspberrypi weewx[27077]: copygenerator: copied 0 files to 
> /var/www/html/weewx/mobile
> Mar 11 20:32:52 raspberrypi weewx[27077]: cheetahgenerator: Generated 4 
> files for report Highcharts_Belchertown in 23.26 seconds
> Mar 11 20:32:52 raspberrypi weewx[27077]: copygenerator: copied 0 files to 
> /var/www/html/weewx/belchertown
> Mar 11 20:32:56 raspberrypi weewx[27077]: cheetahgenerator: Generated 14 
> files for report Belchertown in 4.60 seconds
> Mar 11 20:32:56 raspberrypi weewx[27077]: copygenerator: copied 1 files to 
> /var/www/html/weewx/belchertown
>
> patrick
>

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

[weewx-user] Re: Belchertown skin 0.9 now available

[kutzenco]

Patrick, a good place to put it is in your about.inc file. It should be in 
/home/weewx/skins/Belchertown (at least if you used setup..py) That's the 
page that you see when you click the About menu. See mine: 
https://wx.kutzenco.com/about/. 

Phil

On Saturday, March 9, 2019 at 2:45:56 PM UTC-5, Patrick Tranchant wrote:
>
> hello PAT
> in which file , I put that "Make sure you place the "Powered by DarkSky" 
> somewhere on your website. Like the About page (see below after install for 
> customizing the About page)."
>
> skin.conf or an other ?
> thanks
>
> Patrick
>
> On Friday, March 1, 2019 at 1:50:34 AM UTC+1, Pat wrote:
>>
>> I've just released Belchertown skin 0.9. You can read the updates and 
>> download it here: https://github.com/poblabs/weewx-belchertown/releases
>>
>> A lot of work went into this release. I've learned a lot through feedback 
>> on the skin. 
>>
>> This release fixes a major bug with the rain charts which were taking a 
>> very long time to generate. This release also brings a lot of updates to 
>> locale formats. 
>>
>> *There's 1 breaking change if you are upgrading*. Please take special 
>> note to a few MQTT variable names which have changed to mqtt_websockets_. 
>> This is to reduce confusion and offer clarity on new user installations. 
>>
>> Please let me know if you've upgraded and share your site. I'd love to 
>> see it out there!
>>
>>

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

Re: [weewx-user] Belchertown skin 0.9 now available

[kutzenco]

I have disconnect_live_website_visitor = 0 set in weewx.conf. That prevents 
timing out live updates with MQTT per your README.

The number of seconds after a visitor has loaded your page that we 
> disconnect them from the live streaming updates. The idea here is to save 
> your broker from a streaming connection that never ends. Time is in 
> milliseconds. 0 = disabled. 30 = 5 minutes. 180 = 30 minutes
>

On Sunday, March 3, 2019 at 12:20:53 PM UTC-5, Pat wrote:
>
> Paul, are you using MQTT for live updates? 
>
> If so, set the disconnect_live_website_visitor 
> option
>  
> to something very long like 9 or try the Pi page and see if 
> it looks OK on your template. I should probably make the option of 
> disconnect_live_website_visitor 
> = -1 to disable it. Maybe I'll give that a try for 0.9.1. 
>
>
>
> On Sunday, March 3, 2019 at 11:48:32 AM UTC-5, Paul Lacatus wrote:
>>
>> Hi, Pat 
>>
>> Very nice job with the Belchertown skin. It is possible to add in the 
>> next versions   a refresh clause in the header.html.tmpl ? I am using a 
>> android tablet as a meteo panel using chrome and to have always updated 
>> info i am adding after each update this line in the header.html.tmpl: 
>>
>>  
>>
>> I think it can be useful for other users of your skin too 
>>
>>
>> thanks for your good work 
>>
>> Paul 
>>
>> On 03/03/2019 14:30, Pat wrote: 
>> > I made those changes to the graphs page too. Available on GitHub if you 
>> want to download it. 
>> > 
>>
>

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

[weewx-user] Re: Belchertown skin 0.9 now available

[kutzenco]

The skin version is not in the footer. You should see the skin version by 
right clicking on any Belchertown page and selecting "View Page Source" (or 
equivalent for your browser). Then scroll to the bottom.

Phil

On Friday, March 1, 2019 at 10:01:07 AM UTC-5, rich T wrote:
>
> Pat
>
> This update works, I do not get any errors. Only item missing is the skin 
> version number in the footer, which could be a configuration error on my 
> side.  
>
> How would you reload a webcam snapshot image, without reloading the whole 
> page?
>
> Thanks
> Rich
>
> On Friday, March 1, 2019 at 9:24:31 AM UTC-5, Pat wrote:
>
>> Rich, try this update to see if it works for you? It does for me on weewx 
>> 3.8.2, but I'd rather someone else test it before pushing a release. 
>>
>> Replace your skins/Belchertown/index.html.tmpl with this --> 
>> https://raw.githubusercontent.com/poblabs/weewx-belchertown/master/skins/Belchertown/index.html.tmpl
>>
>> Replace your skins/Belchertown/pi/index.html.tmpl with this --> 
>> https://raw.githubusercontent.com/poblabs/weewx-belchertown/master/skins/Belchertown/pi/index.html.tmpl
>>
>> Restart weewx and see how it goes. 
>>
>> On Friday, March 1, 2019 at 8:33:13 AM UTC-5, rich T wrote:
>>>
>>> Yes planning to upgrade at later date.
>>>
>>>
>>> On Friday, March 1, 2019 at 8:22:57 AM UTC-5, Pat wrote:
>>>
 I see the error and I think it's because you're not on weewx 3.9.1. I 
 thought I backed that change out but I guess I didn't. 

 Do you have plans to update to weewx 3.9.1? 


 On Thursday, February 28, 2019 at 10:49:26 PM UTC-5, rich T wrote:
>
> But I get an "TypeError: format() got an unexpected keyword argument 
> 'None_string''  error.
>
>
>
> On Thursday, February 28, 2019 at 10:15:31 PM UTC-5, rich T wrote:
>>
>> Pat
>>
>> Installed without any issues.
>>
>> Rich
>>
>> On Thursday, February 28, 2019 at 7:50:34 PM UTC-5, Pat wrote:
>>
>>> I've just released Belchertown skin 0.9. You can read the updates 
>>> and download it here: 
>>> https://github.com/poblabs/weewx-belchertown/releases
>>>
>>> A lot of work went into this release. I've learned a lot through 
>>> feedback on the skin. 
>>>
>>> This release fixes a major bug with the rain charts which were 
>>> taking a very long time to generate. This release also brings a lot of 
>>> updates to locale formats. 
>>>
>>> *There's 1 breaking change if you are upgrading*. Please take 
>>> special note to a few MQTT variable names which have changed to 
>>> mqtt_websockets_. This is to reduce confusion and offer clarity on 
>>> new user installations. 
>>>
>>> Please let me know if you've upgraded and share your site. I'd love 
>>> to see it out there!
>>>
>>>

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

Re: [weewx-user] Moon phase & pyephem question

[kutzenco]

So the visible % is now 26% for both the new and old versions of 
almanac.py/Moon.py and the new version now lists the phase as Waning 
Crescent (as does the old version and WU). 

Phil

On Thursday, February 28, 2019 at 11:29:28 AM UTC-5, kutz...@gmail.com 
wrote:
>
> Here's an interesting piece of data. I'm using Tom's new almanac.py and 
> Moon.py on a testbed version of WeeWX. On my "production" instance of 
> WeeWX, I have the versions of those files originally installed with WeeWX 
> 3.9.1.
>
> On my production instance the moon is listed as 29% visible and is 
> described as "Waning Crescent" (which matches what WU says). On my testbed 
> instance, the moon is listed at 29% visible but is described as "Last 
> Quarter". 
>
> So it looks like the version that Tom updated hasn't yet updated the 
> description from Last Quarter to Waning Crescent. That should have occurred 
> as the visible amount decreased to 40%. I'm not sure if that's due to the 
> variability Tom mentioned or something in the new version that should be 
> changed.
>
> Phil
>
>
> On Wednesday, February 27, 2019 at 9:53:10 PM UTC-5, kutz...@gmail.com 
> wrote:
>>
>> Ah. Right you are. I had put it in the right place, but somehow, I ended 
>> up saving it as moon.py instead of Moon.py. I'm not sure how I did that, 
>> since I thought I copied it, name and all, from the GitHub repository. I 
>> renamed it (after removing the old Moon.py, which was still there) and all 
>> works fine now.
>>
>> Thanks for helping me out.
>>
>> Phil
>>
>> On Wednesday, February 27, 2019 at 8:13:23 PM UTC-5, Thomas Keffer wrote:
>>>
>>> You probably still have the old copy of weeutil/Moon.py. You need this 
>>> one 
>>> . 
>>> Or, you accidentally put it in the weewx directory, instead of the weeutil 
>>> directory.
>>>
>>> -tk
>>>
>>> On Wed, Feb 27, 2019 at 1:31 PM  wrote:
>>>
 Understood. In the meantime, I did try copying your new version of 
 almanac.py into the bin/weewx directory on my testbed weewx (I copied 
 moon.py into the bin/weeutil directory also, though I don't think that 
 matters). I got the attached errors complaining about moon_phase_ts. Did I 
 miss a file updated in an earlier commit?

 Phil



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

Re: [weewx-user] Moon phase & pyephem question

[kutzenco]

Here's an interesting piece of data. I'm using Tom's new almanac.py and 
Moon.py on a testbed version of WeeWX. On my "production" instance of 
WeeWX, I have the versions of those files originally installed with WeeWX 
3.9.1.

On my production instance the moon is listed as 29% visible and is 
described as "Waning Crescent" (which matches what WU says). On my testbed 
instance, the moon is listed at 29% visible but is described as "Last 
Quarter". 

So it looks like the version that Tom updated hasn't yet updated the 
description from Last Quarter to Waning Crescent. That should have occurred 
as the visible amount decreased to 40%. I'm not sure if that's due to the 
variability Tom mentioned or something in the new version that should be 
changed.

Phil


On Wednesday, February 27, 2019 at 9:53:10 PM UTC-5, kutz...@gmail.com 
wrote:
>
> Ah. Right you are. I had put it in the right place, but somehow, I ended 
> up saving it as moon.py instead of Moon.py. I'm not sure how I did that, 
> since I thought I copied it, name and all, from the GitHub repository. I 
> renamed it (after removing the old Moon.py, which was still there) and all 
> works fine now.
>
> Thanks for helping me out.
>
> Phil
>
> On Wednesday, February 27, 2019 at 8:13:23 PM UTC-5, Thomas Keffer wrote:
>>
>> You probably still have the old copy of weeutil/Moon.py. You need this 
>> one 
>> . 
>> Or, you accidentally put it in the weewx directory, instead of the weeutil 
>> directory.
>>
>> -tk
>>
>> On Wed, Feb 27, 2019 at 1:31 PM  wrote:
>>
>>> Understood. In the meantime, I did try copying your new version of 
>>> almanac.py into the bin/weewx directory on my testbed weewx (I copied 
>>> moon.py into the bin/weeutil directory also, though I don't think that 
>>> matters). I got the attached errors complaining about moon_phase_ts. Did I 
>>> miss a file updated in an earlier commit?
>>>
>>> Phil
>>>
>>>

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

Re: [weewx-user] Moon phase & pyephem question

[kutzenco]

Ah. Right you are. I had put it in the right place, but somehow, I ended up 
saving it as moon.py instead of Moon.py. I'm not sure how I did that, since 
I thought I copied it, name and all, from the GitHub repository. I renamed 
it (after removing the old Moon.py, which was still there) and all works 
fine now.

Thanks for helping me out.

Phil

On Wednesday, February 27, 2019 at 8:13:23 PM UTC-5, Thomas Keffer wrote:
>
> You probably still have the old copy of weeutil/Moon.py. You need this one 
> . 
> Or, you accidentally put it in the weewx directory, instead of the weeutil 
> directory.
>
> -tk
>
> On Wed, Feb 27, 2019 at 1:31 PM > wrote:
>
>> Understood. In the meantime, I did try copying your new version of 
>> almanac.py into the bin/weewx directory on my testbed weewx (I copied 
>> moon.py into the bin/weeutil directory also, though I don't think that 
>> matters). I got the attached errors complaining about moon_phase_ts. Did I 
>> miss a file updated in an earlier commit?
>>
>> Phil
>>
>>

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

Re: [weewx-user] Moon phase & pyephem question

[kutzenco]

Understood. In the meantime, I did try copying your new version of 
almanac.py into the bin/weewx directory on my testbed weewx (I copied 
moon.py into the bin/weeutil directory also, though I don't think that 
matters). I got the attached errors complaining about moon_phase_ts. Did I 
miss a file updated in an earlier commit?

Phil

On Wednesday, February 27, 2019 at 4:01:29 PM UTC-5, Thomas Keffer wrote:
>
> The problem with skyfield is that it is dependent on numpy, a very large 
> package. I'm reluctant to introduce a new dependency, especially such a 
> large one, just to do almanac calculations.
>
> And, as awkward as the pyephem API is, skyfield's is even worse. It 
> requires loading multi-megabyte ephemeris tables before starting. This will 
> complicate the install.
>
> Haven't decided yet.
>
> -tk
>
> On Wed, Feb 27, 2019 at 12:41 PM > wrote:
>
>> Tom,
>>
>> My understanding is that pyephem is now deprecated (though it will 
>> continue to be available and receive critical bug fixes). See 
>> https://rhodesmill.org/pyephem/. The original developer has a 
>> replacement package called skyfield (https://rhodesmill.org/skyfield/. He 
>> says it is only missing Kelperian orbital elements for comets and 
>> asteroids currently and that he is working to add that. Since you are 
>> working on a Python3 compliant version of WeeWX, is that an opportunity to 
>> have WeeWX use skyfield instead of pyephem?
>>
>> phil
>>
>> On Wednesday, February 27, 2019 at 2:08:39 PM UTC-5, Thomas Keffer wrote:
>>>
>>> I looked into this and found a couple of small issues, which I've 
>>> corrected in commit c696e4 
>>> 
>>> .
>>>
>>> Be aware that the function you are using does the calculation in local 
>>> time. This has now been changed, and the almanac now uses UTC.
>>>
>>> Finally, it uses a very simple algorithm, which assumes a constant 
>>> synodic month of 29.530588 days. In practice, it can vary by 1% or more 
>>> over the years. So, all results will necessarily be approximate.
>>>
>>> -tk
>>>
>>> On Wed, Feb 27, 2019 at 6:26 AM HoracioDos  wrote:
>>>
 Hello.
 I have pyephem installed and Weewx shows "Last quarter" for today Feb 
 27, 2019 but it was yestarday (Feb 26, 2019). I guess it should be "Waning 
 Crescent" for today.  When does moon phases change? 
 if i run: 
 python -c "import weeutil.Moon;print weeutil.Moon.moon_phase(2019,2,27)"
 I get this
 (6, 38)
 Thanks in advance!

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

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

-- 
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.
For more options, visit https://groups.google.com/d/optout.
Feb 27 16:20:17 Lab-pi weewx[14777]: reportengine: Caught unrecoverable 
exceptio   n in generator 
'weewx.cheetahgenerator.CheetahGenerator'
Feb 27 16:20:17 Lab-pi weewx[14777]:   'module' object has no 
attrib   ute 'moon_phase_ts'
Feb 27 16:20:17 Lab-pi weewx[14777]: forecast: ZambrettiThread: Zambretti: 
saved1 forecast records
Feb 27 16:20:17 Lab-pi weewx[14777]: forecast: ZambrettiThread: Zambretti: 
delet   ed forecasts prior to 1550697617
Feb 27 16:20:17 Lab-pi weewx[14777]:   Traceback (most recent call 
l   ast):
Feb 27 16:20:17 Lab-pi weewx[14777]: File 
"/home/weewx/bin/weewx   /reportengine.py", line 204, in run
Feb 27 16:20:17 Lab-pi weewx[14777]:   obj.start()
Feb 27 16:20:17 Lab-pi weewx[14777]: File 
"/home/weewx/bin/weewx   /reportengine.py", line 300, in 
start
Feb 27 16:20:17 Lab-pi weewx[14777]:   self.run()
Feb 27 16:20:17 Lab-pi weewx[14777]: File 
"/home/weewx/bin/weewx   /cheetahgenerator.py", line 157, 
in run
Feb 27 16:20:17 Lab-pi weewx[14777]:   
self.initExtensions(gen_d   ict[section_name])
Feb 27 16:20:17 Lab-pi weewx[14777]: File 
"/home/weewx/bin/weewx   /cheetahgenerator.py", line 201, 
in initExtensions
Feb 27 16:20:17 Lab-pi weewx[14777]:   

Re: [weewx-user] Moon phase & pyephem question

[kutzenco]

Tom,

My understanding is that pyephem is now deprecated (though it will continue 
to be available and receive critical bug fixes). See 
https://rhodesmill.org/pyephem/. The original developer has a replacement 
package called skyfield (https://rhodesmill.org/skyfield/. He says it is 
only missing Kelperian orbital elements for comets and asteroids currently 
and that he is working to add that. Since you are working on a Python3 
compliant version of WeeWX, is that an opportunity to have WeeWX use 
skyfield instead of pyephem?

phil

On Wednesday, February 27, 2019 at 2:08:39 PM UTC-5, Thomas Keffer wrote:
>
> I looked into this and found a couple of small issues, which I've 
> corrected in commit c696e4 
> 
> .
>
> Be aware that the function you are using does the calculation in local 
> time. This has now been changed, and the almanac now uses UTC.
>
> Finally, it uses a very simple algorithm, which assumes a constant synodic 
> month of 29.530588 days. In practice, it can vary by 1% or more over the 
> years. So, all results will necessarily be approximate.
>
> -tk
>
> On Wed, Feb 27, 2019 at 6:26 AM HoracioDos  > wrote:
>
>> Hello.
>> I have pyephem installed and Weewx shows "Last quarter" for today Feb 27, 
>> 2019 but it was yestarday (Feb 26, 2019). I guess it should be "Waning 
>> Crescent" for today.  When does moon phases change? 
>> if i run: 
>> python -c "import weeutil.Moon;print weeutil.Moon.moon_phase(2019,2,27)"
>> I get this
>> (6, 38)
>> Thanks in advance!
>>
>> -- 
>> 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.
>>
>

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

Re: [weewx-user] Re: Getting the RPi 3 with Davis Vantage up and running

[kutzenco]

Just a quick question. Do you have a monitor (like the Pi 7 in touch 
screen) attached that is running off the same power supply as the Pi? I had 
a setup like that which used a splitter to power both the monitor and Pi 
from one power pack. My setup kept complaining of undervolting until I 
removed the splitter and plugged the monitor and pi each into their own 
power supply.

phil

On Monday, January 28, 2019 at 3:41:15 PM UTC-5, monmul wrote:
>
> I have replaced the power unit, taken it off the power strip an plugged 
> both it and the Vanatage into the mains. I have replaced the powered hub 
> (official RPi one...with another official RPi one) ...and here is what I am 
> getting...very dispirited! I have another Davis Weather Envoy which I 
> will soon substitute for the one I am currently using.but nothing seems 
> to make a difference and the Envoy just will not wake up!
>
> pi@raspberrypi:~ $ sudo tail -f /var/log/syslog
> Jan 29 09:14:05 raspberrypi udisksd[766]: Mounted /dev/sda1 at 
> /media/pi/e78ab10a-51d2-40f0-aa6d-5f2d2b0f27b7 on behalf of uid 1000
> Jan 29 09:14:05 raspberrypi vncserver-x11[453,root]: SPrintConnMgr: Failed 
> to add printer: server-error-service-unavailable
> Jan 29 09:14:07 raspberrypi dhcpcd[338]: wlan0: no IPv6 Routers available
> Jan 29 09:14:10 raspberrypi kernel: [   22.871754] Voltage normalised 
> (0x)
> Jan 29 09:14:12 raspberrypi weewx[506]: vantage: Unable to wake up console
> Jan 29 09:14:12 raspberrypi weewx[506]: import of driver failed: Unable to 
> wake up Vantage console ()
> Jan 29 09:14:12 raspberrypi weewx[506]: engine: Unable to load driver: 
> Unable to wake up Vantage console
> Jan 29 09:14:12 raspberrypi weewx[506]:   Exiting...
> Jan 29 09:14:27 raspberrypi kernel: [   39.511958] Under-voltage detected! 
> (0x00050005)
> Jan 29 09:14:31 raspberrypi kernel: [   43.671921] Voltage normalised 
> (0x)
> Jan 29 09:15:00 raspberrypi ntpd[467]: Soliciting pool server 103.239.8.22
> Jan 29 09:15:00 raspberrypi ntpd[467]: Soliciting pool server 202.46.185.18
> Jan 29 09:15:01 raspberrypi ntpd[467]: Soliciting pool server 203.99.128.48
> Jan 29 09:15:01 raspberrypi ntpd[467]: Soliciting pool server 
> 103.106.66.123
> Jan 29 09:15:02 raspberrypi ntpd[467]: Soliciting pool server 103.242.68.69
> Jan 29 09:15:02 raspberrypi ntpd[467]: Soliciting pool server 
> 103.106.65.219
> Jan 29 09:15:02 raspberrypi ntpd[467]: Soliciting pool server 103.242.70.5
> Jan 29 09:15:02 raspberrypi ntpd[467]: Soliciting pool server 
> 122.252.188.99
> Jan 29 09:15:03 raspberrypi ntpd[467]: Soliciting pool server 
> 130.217.226.51
> Jan 29 09:15:03 raspberrypi ntpd[467]: Soliciting pool server 103.242.68.68
> Jan 29 09:15:03 raspberrypi ntpd[467]: Soliciting pool server 203.99.128.34
> Jan 29 09:15:04 raspberrypi ntpd[467]: Soliciting pool server 202.46.177.18
> Jan 29 09:15:04 raspberrypi ntpd[467]: Soliciting pool server 
> 2407:f100:0:4::3
> Jan 29 09:15:06 raspberrypi ntpd[467]: Soliciting pool server 202.46.178.18
> Jan 29 09:17:41 raspberrypi systemd[584]: Time has been changed
> Jan 29 09:17:41 raspberrypi systemd[1]: Time has been changed
> Jan 29 09:17:41 raspberrypi systemd[1]: apt-daily.timer: Adding 9h 28min 
> 39.184756s random time.
> Jan 29 09:17:41 raspberrypi systemd[1]: apt-daily-upgrade.timer: Adding 
> 27min 17.961005s random time.
> Jan 29 09:18:28 raspberrypi kernel: [  126.872661] Under-voltage detected! 
> (0x00050005)
> Jan 29 09:18:34 raspberrypi kernel: [  133.112736] Voltage normalised 
> (0x)
> Jan 29 09:18:34 raspberrypi CRON[1276]: (root) CMD (   cd / && run-parts 
> --report /etc/cron.hourly)
> Jan 29 09:22:29 raspberrypi kernel: [  368.155297] 
> rpi_firmware_get_throttled: 2 callbacks suppressed
> Jan 29 09:22:29 raspberrypi kernel: [  368.155304] Under-voltage detected! 
> (0x00050005)
> Jan 29 09:22:33 raspberrypi kernel: [  372.315315] 
> rpi_firmware_get_throttled: 2 callbacks suppressed
> Jan 29 09:22:33 raspberrypi kernel: [  372.315322] Voltage normalised 
> (0x)
> Jan 29 09:24:27 raspberrypi kernel: [  486.716533] Under-voltage detected! 
> (0x00050005)
> Jan 29 09:24:34 raspberrypi kernel: [  492.956607] Voltage normalised 
> (0x)
> Jan 29 09:26:28 raspberrypi kernel: [  607.357755] Under-voltage detected! 
> (0x00050005)
> Jan 29 09:26:32 raspberrypi kernel: [  611.517793] Voltage normalised 
> (0x)
> Jan 29 09:26:45 raspberrypi ntpd[467]: 203.99.128.34 local addr 10.1.1.7 
> -> 
> Jan 29 09:30:13 raspberrypi ntpd[467]: 103.239.8.22 local addr 10.1.1.7 -> 
> 
> Jan 29 09:30:45 raspberrypi ntpd[467]: 203.99.128.48 local addr 10.1.1.7 
> -> 
> Jan 29 09:31:18 raspberrypi ntpd[467]: 122.252.188.99 local addr 10.1.1.7 
> -> 
> Jan 29 09:31:23 raspberrypi systemd[1]: Starting Cleanup of Temporary 
> Directories...
> Jan 29 09:31:23 raspberrypi systemd[1]: Started Cleanup of Temporary 
> Directories.
> Jan 29 09:32:22 raspberrypi ntpd[467]: 130.217.226.51 local addr 10.1.1.7 
> -> 

[weewx-user] Re: weewx.sdb backups

[kutzenco]

Currently I use the weewx rsync extension (
https://github.com/weewx/weewx/wiki/Using-the-RSYNC-skin-as-a-backup-solution) 
to copy my weewx.sdb to a Synology NAS every night at midnight (in between 
archive writes). I then use Synology's "Backup and Restore" facility to 
copy from that NAS to another NAS on my network (yes, I have several 
Synology NAS's). "Backup and Restore" keeps up to 30 snapshots. So, I have 
the most recent 30 days of weewx.sdb. Since my Davis data logger keeps 
about a week's data, I have that much time to notice any corruption and 
recover with no data loss.

Once you use the rsync skin to get a copy of weewx.sdb off your weewx 
machine, you can use any strategy you like to ensure access to a good 
version if disaster strikes.

I know that Dave Harper has a pretty sophisticated setup that checks for 
database integrity prior to backing it up. See 
https://groups.google.com/d/msg/weewx-user/K7aViEOIimg/dnoz1_25CAAJ. I may 
look to incorporate some of his work to my scheme.

phil

On Wednesday, January 23, 2019 at 1:31:20 AM UTC-5, Scott Grayban wrote:
>
> How is everyone doing backups for weewx.sdb ?
>
> I thought about doing a aws backup using a fuse setup.
>
> Are there easier ways to do this ?
>

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

Re: [weewx-user] One archive database - two weewx implementations

[kutzenco]

Gary,

Thanks for your advice. I shall take it and set up my development instance 
as you suggest!

Also, thanks to Thomas for the info on the Raspberry Pi SD Card writes. I'd 
heard some time ago that a high quality SD Card is important when running a 
Pi. So, similar to Thomas' test setup, I am using a SanDisk Extreme Pro 
card on my production instance. I back the database up nightly (using the 
weewx rsync extension to ensure the database is between accesses) and keep 
a months worth of versions. So, it looks like there isn't any urgency for 
me to change my production instance setup- one less thing to do.

phil

On Monday, January 21, 2019 at 6:19:38 PM UTC-5, gjr80 wrote:
>
> Gee, this sound like a whole lot of trouble for a development instance of 
> WeeWX. Why not just have a separate simulator install, use the simulator in 
> generator mode to generate a few years of data then keep a copy of this 
> data for when you hose your development data. Switch the simulator back to 
> simulate mode and do your development. Sure it's nice to see the same data 
> but canned data is fine for 99% of development work. The risk with having 
> access to your production data is that sooner or later something is going 
> to do something it shouldn't.
>
> Gary
>
> On Tuesday, 22 January 2019 08:52:12 UTC+10, kutz...@gmail.com wrote:
>>
>> Thanks Thomas. I was worried the answer to my first question was going to 
>> be no.
>>
>> My fallback on the LAN-based database was going to be to use the rsync 
>> extension to copy the database from the production weewx instance to the 
>> development instance. A third option would be to mount the database on the 
>> production Pi onto the development Pi. Then the LAN instance is only being 
>> read. Since LAN access is only to a development instance, it would be no 
>> big deal if it dropped some records in reports. But requiring a device 
>> driver nixes those ideas also. 
>>
>> Does the driver need to generate ARCHIVE packets and try to store them? 
>> Or are just empty LOOP packets ok? I was actually planning to get LOOP 
>> packets from MQTT which my production weewx instance publishes. So, I 
>> wouldn't even want the development instance to grab LOOP packets other than 
>> the MQTT ones.
>>
>> phil
>>
>> On Monday, January 21, 2019 at 5:30:53 PM UTC-5, Thomas Keffer wrote:
>>>
>>> 1. Unfortunately, no. WeeWX expects a device driver. I suppose you could 
>>> create a dummy device driver that emits empty LOOP packets at regular 
>>> intervals, but I've never tried that.
>>> 2. Would not make any difference. Sqlite does quite well locking around 
>>> reads and writes.
>>> 3. The problem using a database on your LAN is that it exposes yourself 
>>> to network errors. WeeWX does not do very well recovering from these kinds 
>>> of errors. It won't crash, but it can drop a record. Still, lots of people 
>>> have used a database on another machine. Personally, I think the problem of 
>>> SD card writes is overstated. I have been running an instance of WeeWX 
>>>  on an RPi with a 
>>> Sandisk Extreme Plus SD card. It has been up for well over 4 years without 
>>> a disk crash.
>>>
>>> -tk
>>>
>>> On Mon, Jan 21, 2019 at 12:24 PM  wrote:
>>>
 I am currently running weewx (on a Raspberry Pi) inputting data from a 
 Vantage Vue station, using a sqlite3 database to archive the data. I 
 publish the generated webpages via an external web hosting service. I want 
 to set up a development weewx instance on a second Raspberry Pi and point 
 it to the existing database to get generated output. This would allow me 
 to 
 have the output from my development instance display current data gathered 
 from the production instance. But, if I hose my output while making 
 changes 
 in the development instance, I won't impact the published webpages.

 I'm looking for advice and have a few questions:

 1. Is there a way to run a weewx instance that skips the device 
 input (since that will be handled by the production instance) but goes 
 through the output items a skin would do including generating html pages 
 and copying them into the public_html directory?

 2. Is migrating to MySQL a better choice for this kind of setup? I 
 would think that using MySQL will solve any issues of locking caused 
 if/when both instances access the database simultaneously (though one is 
 is 
 reading and writing while the other is only reading).

 3. I am also thinking of moving the database (and maybe other weewx 
 directories) to a Synology NAS and mapping those locations to my two weewx 
 instances to reduce SDCard writes. Are there any significant gotchas or 
 warnings I should take heed of regarding this?

 phil

 -- 



-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" 

[weewx-user] One archive database - two weewx implementations

[kutzenco]

I am currently running weewx (on a Raspberry Pi) inputting data from a 
Vantage Vue station, using a sqlite3 database to archive the data. I 
publish the generated webpages via an external web hosting service. I want 
to set up a development weewx instance on a second Raspberry Pi and point 
it to the existing database to get generated output. This would allow me to 
have the output from my development instance display current data gathered 
from the production instance. But, if I hose my output while making changes 
in the development instance, I won't impact the published webpages.

I'm looking for advice and have a few questions:

1. Is there a way to run a weewx instance that skips the device input 
(since that will be handled by the production instance) but goes through 
the output items a skin would do including generating html pages and 
copying them into the public_html directory?

2. Is migrating to MySQL a better choice for this kind of setup? I 
would think that using MySQL will solve any issues of locking caused 
if/when both instances access the database simultaneously (though one is is 
reading and writing while the other is only reading).

3. I am also thinking of moving the database (and maybe other weewx 
directories) to a Synology NAS and mapping those locations to my two weewx 
instances to reduce SDCard writes. Are there any significant gotchas or 
warnings I should take heed of regarding this?

phil

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

[weewx-user] Re: RPI and Saving Files to NAS

[kutzenco]

I would appreciate seeing the relevant parts of your weewx.conf file for 
this.

I assume that with this setup, you don't permit your NAS drives to spin 
down (as they are written to every archive period) assuming they are HDDs 
and not SSDs. If they are, indeed, HDDs I guess it would be best to use 
ones optimized for this kind of activity like Western Digital Purple drives 
(instead of Western Digital Red drives, for example). Is that right?

phil

On Friday, January 18, 2019 at 8:10:41 AM UTC-5, ge...@cusick.org.uk wrote:
>
> I’ve been using the combiation of RPi and Synology NAS for some time now. 
>  I’ve taken a slightly different approach, though. 
>
> I’ve configured weewx to use a MySQL database, hosted on the NAS under 
> MariaDB.  Pretty simple to set up, and seems to have been reliable.  On the 
> RPi, the log is stored in a local memory buffer (using Busybox’s syslogd, 
> qv), and public-html is placed on a ramdisk (tmpfs).  Thus, wrires to the 
> SD card are minimised.  Happy to share bits of weewx.conf if it would be 
> helpful. 
>
> Geoff

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

Re: [weewx-user] Any chance for MQTT instead of RTGD for SteelSeries Gauges?

[kutzenco]

Gary, I already moved it. If I delete from weewx-development now, it 
probably won't go away. Sorry, I know you shouldn't cross-post.
phil

On Tuesday, January 15, 2019 at 7:02:47 PM UTC-5, gjr80 wrote:
>
> I would leave it here, probably going to be seen by more that way. i don't 
> think we are that hard and fast as to what gets posted where.
>
> Colin is right though, this is one for Mark Crossley the SteelSeries 
> Weather Gauges developer.
>
> Gary
>
> On Wednesday, 16 January 2019 09:54:50 UTC+10, kutz...@gmail.com wrote:
>>
>> I apologize. I realized this topic should be on weewx-development, not 
>> weewx-user. I deleted it from weewx-user when it was listed as having 0 
>> views and posted it on weewx-development, but obviously wasn't quick 
>> enough. Please post any other comments to it on weewx-development.
>> phil
>>
>> On Tuesday, January 15, 2019 at 6:31:32 PM UTC-5, Colin Larsen wrote:
>>>
>>> Sou D's like that's probably a question for the developer of the SS 
>>> Gauges, they just need to be rewritten to read the available MQTT data 
>>> rather than the txt file?
>>>
>>> Colin
>>>
>>> On Wed, 16 Jan 2019, 11:58 >>
 Gary's rtgd code (https://github.com/gjr80/weewx-realtime_gauge-data) 
 provides near-real-time updates to SteelSeries gauges using HTTP POST to 
 load the latest data file generated from LOOP data. At least, that's my 
 understanding. I imagine that it should be possible to leverage MQTT 
 updates to the SteelSeries page as a lighter-weight method of providing 
 updated data. I'm using MQTT already and it would be great if I could 
 leverage it to add some SteelSeries gauge visuals without a major load on 
 my Raspberry Pi weewx setup.

 Is coding this alternative a big task? Mind you, I'm not volunteering 
 :-). I'm pretty sure my coding skills aren't up to it. But is anyone 
 working on this? I did a quick search on this group and didn't find 
 anything indicating it.

 phil

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

>>>

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

Re: [weewx-user] Any chance for MQTT instead of RTGD for SteelSeries Gauges?

[kutzenco]

I apologize. I realized this topic should be on weewx-development, not 
weewx-user. I deleted it from weewx-user when it was listed as having 0 
views and posted it on weewx-development, but obviously wasn't quick 
enough. Please post any other comments to it on weewx-development.
phil

On Tuesday, January 15, 2019 at 6:31:32 PM UTC-5, Colin Larsen wrote:
>
> Sou D's like that's probably a question for the developer of the SS 
> Gauges, they just need to be rewritten to read the available MQTT data 
> rather than the txt file?
>
> Colin
>
> On Wed, 16 Jan 2019, 11:58  wrote:
>
>> Gary's rtgd code (https://github.com/gjr80/weewx-realtime_gauge-data) 
>> provides near-real-time updates to SteelSeries gauges using HTTP POST to 
>> load the latest data file generated from LOOP data. At least, that's my 
>> understanding. I imagine that it should be possible to leverage MQTT 
>> updates to the SteelSeries page as a lighter-weight method of providing 
>> updated data. I'm using MQTT already and it would be great if I could 
>> leverage it to add some SteelSeries gauge visuals without a major load on 
>> my Raspberry Pi weewx setup.
>>
>> Is coding this alternative a big task? Mind you, I'm not volunteering 
>> :-). I'm pretty sure my coding skills aren't up to it. But is anyone 
>> working on this? I did a quick search on this group and didn't find 
>> anything indicating it.
>>
>> phil
>>
>> -- 
>> 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.
>>
>

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

[weewx-user] Re: HOWTO wiki page for hostapd setup for Interceptor driver

[kutzenco]

I claim no vast knowledge, but 
https://frillip.com/using-your-raspberry-pi-3-as-a-wifi-access-point-with-hostapd/
 
uses dnsmasq, but also states:

If you want something a little more 'heavyweight', you can use the 
isc-dhcp-server and bind9 packages for DHCP and DNS respectively, but for 
our purposes, dnsmasq works just fine.

So, likely, bind9 is a usable alternative for DNS with hostapad.

phil

On Friday, January 4, 2019 at 4:24:31 PM UTC-5, Scott Grayban wrote:
>
> If I'm not mistaken hostapd requires dnsmasq unless your vast knowledge 
> knows of a different way then you can have bind9 running.
>
> On Friday, January 4, 2019 at 7:27:58 AM UTC-8, vince wrote:
>>
>> On Thursday, January 3, 2019 at 6:22:02 PM UTC-8, Scott Grayban wrote:
>>>
>>> Bind uses port 53 so does dnsmasq. You can't have both.
>>>
>>>
>> Sure - I'm well aware of dnsmasq and bind.
>>
>> My question was why that has anything to do with hostapd working or not.
>>
>

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

[weewx-user] Re: Way OT but how do you copy your sdcard(s) ?

[kutzenco]

vince,

Would you be willing to share the ansible playbook you developed for this?

On Friday, January 4, 2019 at 10:26:18 AM UTC-5, vince wrote:
>
> On Thursday, January 3, 2019 at 6:56:20 PM UTC-8, Scott Grayban wrote:
>>
>> I know you can use DD and there is the SDcopy in raspian.
>>
>> But how do YOU do it ?
>>
>
> for me, I don'tI automate building a new one in a couple steps via 
> ansible.
>

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

[weewx-user] Re: Belchertown Skin 0.8.2 Released

[kutzenco]

Two things I might add to Pat's great tutorial:


   1. Mosquitto not only hates extra spaces at the end of lines in config 
   files, it also hates not having a newline at the end of each config file. 
   Also, if Mosquitto exits due to a config file format issue, it doesn’t 
   respond to a systemctl start command properly. I think that when it 
   tries to restart, it sees that there is a PID file in existence and just 
   exits. Even restarting the server (ugh) didn’t help me. What I found to get 
   by that is to issue a systemctl stop command first. I think that clears 
   the PID file. Then I issue the systemctl start command.
   2. I set up an Nginx webserver on my external website (which is running 
   Ubuntu) to serve the pages. I used Let’s Encrypt to set up my certs (used 
   for both Mosquitto and Nginx web pages). Rather than use the certbot 
   certonly command as suggested by Pat, I used the Nginx plug-in for 
   Ubuntu:

 sudo apt-get update

sudo apt-get install software-properties-common

sudo add-apt-repository ppa:certbot/certbot

sudo apt-get update

sudo apt-get install python-certbot-nginx 

  sudo certbot --nginx

This really automates the cert installs. It edits the Nginx 
config files, sets up the cron job for renewing the certs and even 
automates redirecting http://URL’s to https:// ones if you want it to. Very 
cool. 

phil

On Wednesday, January 2, 2019 at 11:49:49 AM UTC-5, kutz...@gmail.com wrote:
>
> Check out Pat's tutorial on doing this on his website (
> https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/). That's what I 
> used to set up MQTT for my website.
> phil
>
> On Wednesday, January 2, 2019 at 9:55:22 AM UTC-5, WILWetter25 wrote:
>>
>> Ive got some questions: I read about MQTT in your readme. The 
>> weatherstation I use, is a Ambient Weather WS 2902. I am using the 
>> Interceptor Driver that sniffs the data, when the weatherstation sends data 
>> to Wundergound. The skin will be uploaded via FTP to my Website.
>>
>> My questions: Which Soft- and Hardware do I need to create a 
>> MQTT-Live-Website?
>>
>> Is it possible for me?
>>
>>

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

[weewx-user] Re: Belchertown Skin 0.8.2 Released

[kutzenco]

Check out Pat's tutorial on doing this on his website (
https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/). That's what I 
used to set up MQTT for my website.
phil

On Wednesday, January 2, 2019 at 9:55:22 AM UTC-5, WILWetter25 wrote:
>
> Ive got some questions: I read about MQTT in your readme. The 
> weatherstation I use, is a Ambient Weather WS 2902. I am using the 
> Interceptor Driver that sniffs the data, when the weatherstation sends data 
> to Wundergound. The skin will be uploaded via FTP to my Website.
>
> My questions: Which Soft- and Hardware do I need to create a 
> MQTT-Live-Website?
>
> Is it possible for me?
>
>

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

[weewx-user] Re: Belchertown skin for weewx now available!

[kutzenco]

Even better check out 
https://groups.google.com/d/msg/weewx-user/6Sa3vfzsH6k/cEQJ6ASXDQAJ and 
post updates there.

phil

On Tuesday, January 1, 2019 at 8:11:02 AM UTC-5, kutz...@gmail.com wrote:
>
> See Scott's note a couple of posts above. Check out 
> https://groups.google.com/d/topic/weewx-user/XwkT_hCBsLc/discussion for 
> the fix. Also post future discussion at 
> https://groups.google.com/d/topic/weewx-user/ARBHWDXiDpQ/discussion and 
> not here.
>
> phil
>
> On Tuesday, January 1, 2019 at 7:25:56 AM UTC-5, Juan Antonio Mosquera 
> wrote:
>
> me too... i use 0.8.1  since 0:00AM fails.
>
> Jan 01 13:23:05 meteomontaos weewx[6865]: reportengine: Caught 
> unrecoverable exception in generator weewx.cheetahgenerator.CheetahGenerator
> Jan 01 13:23:05 meteomontaos weewx[6865]:   'NoneType' object 
> has no attribute '__getitem__'
> Jan 01 13:23:05 meteomontaos weewx[6865]:   Traceback (most 
> recent call last):
> Jan 01 13:23:05 meteomontaos weewx[6865]: File 
> "/usr/share/weewx/weewx/reportengine.p
>
> ...

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

[weewx-user] Re: Belchertown skin for weewx now available!

[kutzenco]

See Scott's note a couple of posts above. Check out 
https://groups.google.com/d/topic/weewx-user/XwkT_hCBsLc/discussion for the 
fix. Also post future discussion at 
https://groups.google.com/d/topic/weewx-user/ARBHWDXiDpQ/discussion and not 
here.

phil

On Tuesday, January 1, 2019 at 7:25:56 AM UTC-5, Juan Antonio Mosquera 
wrote:
>
> me too... i use 0.8.1  since 0:00AM fails.
>
> Jan 01 13:23:05 meteomontaos weewx[6865]: reportengine: Caught 
> unrecoverable exception in generator weewx.cheetahgenerator.CheetahGenerator
> Jan 01 13:23:05 meteomontaos weewx[6865]:   'NoneType' object 
> has no attribute '__getitem__'
> Jan 01 13:23:05 meteomontaos weewx[6865]:   Traceback (most 
> recent call last):
> Jan 01 13:23:05 meteomontaos weewx[6865]: File 
> "/usr/share/weewx/weewx/reportengine.py", line 239, in run
> Jan 01 13:23:05 meteomontaos weewx[6865]:   obj.start()
> Jan 01 13:23:05 meteomontaos weewx[6865]: File 
> "/usr/share/weewx/weewx/reportengine.py", line 273, in start
> Jan 01 13:23:05 meteomontaos weewx[6865]:   self.run()
> Jan 01 13:23:05 meteomontaos weewx[6865]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 158, in run
> Jan 01 13:23:05 meteomontaos weewx[6865]:   ngen = 
> self.generate(gen_dict[section_name], self.gen_ts)
> Jan 01 13:23:05 meteomontaos weewx[6865]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 232, in generate
> Jan 01 13:23:05 meteomontaos weewx[6865]:   ngen += 
> self.generate(section[subsection], gen_ts)
> Jan 01 13:23:05 meteomontaos weewx[6865]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 232, in generate
> Jan 01 13:23:05 meteomontaos weewx[6865]:   ngen += 
> self.generate(section[subsection], gen_ts)
> Jan 01 13:23:05 meteomontaos weewx[6865]: File 
> "/usr/share/weewx/weewx/cheetahgenerat
> ...

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

Re: [weewx-user] Re: Start of 2019 not so smooth

[kutzenco]

Thanks Pat!

phil

On Monday, December 31, 2018 at 10:15:46 PM UTC-5, Pat wrote:
>
> For those with Belchertown skin, if you get hit with the new year bug grab 
> an updated copy of the bin/user/belchertown.py file 
> 
>  
> and place it into your bin/user folder and restart weewx.
>
> The bug is when there's no data populated in certain tables yet because of 
> the new year, which breaks the records page - thus breaking the whole skin. 
>
> Should be fixed now!
>
> On Monday, December 31, 2018 at 8:00:08 PM UTC-5, Pat wrote:
>>
>> Starting to look now
>>
>> On Monday, December 31, 2018 at 7:52:55 PM UTC-5, Colin Larsen wrote:
>>>
>>> Ah well, if you're quick you'll fix it before it strikes there :)
>>>
>>> On Tue, Jan 1, 2019 at 1:48 PM Pat  wrote:
>>>
 I'm awake! But it's 7:30pm here, not 2019 yet. Hmm... 

 On Monday, December 31, 2018 at 6:39:02 PM UTC-5, Colin Larsen wrote:
>
> sqllite here
>
> On Tue, Jan 1, 2019 at 12:34 PM  wrote:
>
>> Colin,
>>
>> Out of curiosity, are you using mySQL or sqlite? Pat tailors the SQL 
>> statements to the database. I'm running weeWX and the Belchertown skin 
>> on 
>> sqlite. I'm in the US Eastern timezone, so will see if the skin coughs 
>> up 
>> for me after the year roll over.
>>
>> phil
>>
>> On Monday, December 31, 2018 at 6:08:19 PM UTC-5, Colin Larsen wrote:
>>>
>>> Thanks Greg and HNY to you.
>>>
>>> Yep I just did a reboot and got a better look at the error, it 
>>> certainly looks like a skin problem. I'll have to wait for Pat to wake 
>>> up :)
>>>
>>> Jan  1 12:05:15 raspberrypi weewx[1004]: manager: Added record 
>>> 2019-01-01 12:05:00 NZDT (1546297500) to database 'weewx.sdb'
>>>
>>> Jan  1 12:05:15 raspberrypi weewx[1004]: manager: Added record 
>>> 2019-01-01 12:05:00 NZDT (1546297500) to daily summary in 'weewx.sdb'
>>>
>>> Jan  1 12:05:20 raspberrypi weewx[1004]: cheetahgenerator: 
>>> Generated 14 files for report StandardReport in 4.36 seconds
>>>
>>> Jan  1 12:05:25 raspberrypi weewx[1004]: imagegenerator: Generated 
>>> 36 images for StandardReport in 3.78 seconds
>>>
>>> Jan  1 12:05:25 raspberrypi weewx[1004]: copygenerator: copied 9 
>>> files to /var/www/html/weewx
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: cheetahgenerator: 
>>> Generated 4 files for report Highcharts_Belchertown in 5.74 seconds
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: copygenerator: copied 0 
>>> files to /var/www/html/weewx/belchertown
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: Belchertown Extension: 
>>> version 0.8.1
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: reportengine: Caught 
>>> unrecoverable exception in generator 
>>> weewx.cheetahgenerator.CheetahGenerator
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]:   'NoneType' 
>>> object has no attribute '__getitem__'
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]:   Traceback 
>>> (most recent call last):
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
>>> "/usr/share/weewx/weewx/reportengine.py", line 239, in run
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]:   
>>> obj.start()
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
>>> "/usr/share/weewx/weewx/reportengine.py", line 273, in start
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]:   
>>> self.run()
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
>>> "/usr/share/weewx/weewx/cheetahgenerator.py", line 158, in run
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]:   ngen = 
>>> self.generate(gen_dict[section_name], self.gen_ts)
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
>>> "/usr/share/weewx/weewx/cheetahgenerator.py", line 232, in generate
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]:   ngen += 
>>> self.generate(section[subsection], gen_ts)
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
>>> "/usr/share/weewx/weewx/cheetahgenerator.py", line 232, in generate
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]:   ngen += 
>>> self.generate(section[subsection], gen_ts)
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
>>> "/usr/share/weewx/weewx/cheetahgenerator.py", line 320, in generate
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]:   
>>> default_binding)
>>>
>>> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
>>> "/usr/share/weewx/weewx/cheetahgenerator.py", line 372, in 
>>> 

Re: [weewx-user] Re: Start of 2019 not so smooth

[kutzenco]

Colin,

Out of curiosity, are you using mySQL or sqlite? Pat tailors the SQL 
statements to the database. I'm running weeWX and the Belchertown skin on 
sqlite. I'm in the US Eastern timezone, so will see if the skin coughs up 
for me after the year roll over.

phil

On Monday, December 31, 2018 at 6:08:19 PM UTC-5, Colin Larsen wrote:
>
> Thanks Greg and HNY to you.
>
> Yep I just did a reboot and got a better look at the error, it certainly 
> looks like a skin problem. I'll have to wait for Pat to wake up :)
>
> Jan  1 12:05:15 raspberrypi weewx[1004]: manager: Added record 2019-01-01 
> 12:05:00 NZDT (1546297500) to database 'weewx.sdb'
>
> Jan  1 12:05:15 raspberrypi weewx[1004]: manager: Added record 2019-01-01 
> 12:05:00 NZDT (1546297500) to daily summary in 'weewx.sdb'
>
> Jan  1 12:05:20 raspberrypi weewx[1004]: cheetahgenerator: Generated 14 
> files for report StandardReport in 4.36 seconds
>
> Jan  1 12:05:25 raspberrypi weewx[1004]: imagegenerator: Generated 36 
> images for StandardReport in 3.78 seconds
>
> Jan  1 12:05:25 raspberrypi weewx[1004]: copygenerator: copied 9 files to 
> /var/www/html/weewx
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: cheetahgenerator: Generated 4 
> files for report Highcharts_Belchertown in 5.74 seconds
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: copygenerator: copied 0 files to 
> /var/www/html/weewx/belchertown
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: Belchertown Extension: version 
> 0.8.1
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: reportengine: Caught 
> unrecoverable exception in generator weewx.cheetahgenerator.CheetahGenerator
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   'NoneType' object 
> has no attribute '__getitem__'
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   Traceback (most 
> recent call last):
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
> "/usr/share/weewx/weewx/reportengine.py", line 239, in run
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   obj.start()
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
> "/usr/share/weewx/weewx/reportengine.py", line 273, in start
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   self.run()
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 158, in run
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   ngen = 
> self.generate(gen_dict[section_name], self.gen_ts)
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 232, in generate
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   ngen += 
> self.generate(section[subsection], gen_ts)
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 232, in generate
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   ngen += 
> self.generate(section[subsection], gen_ts)
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 320, in generate
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   
> default_binding)
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 372, in _getSearchList
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   searchList += 
> obj.get_extension_list(timespan, db_lookup)
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: File 
> "/usr/share/weewx/user/belchertown.py", line 297, in get_extension_list
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   
> year_rainiest_month_tuple 
> = (year_rainiest_month_query[1], rain_unit, 'group_rain')
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   TypeError: 
> 'NoneType' object has no attribute '__getitem__'
>
> Jan  1 12:05:30 raspberrypi weewx[1004]:   Generator 
> terminated
>
> Jan  1 12:05:30 raspberrypi weewx[1004]: copygenerator: copied 22 files 
> to /var/www/html/weewx/belchertown
>
> On Tue, Jan 1, 2019 at 11:52 AM Greg from Oz  > wrote:
>
>> I am in Oz and mine is OK.
>> Probably the skin.
>> https://weather.ubeaut.work/
>>
>> On Tuesday, 1 January 2019 09:00:43 UTC+11, Colin Larsen wrote:
>>>
>>> Happy New Year all
>>>
>>> I awoke this morning (2019 here in NZ) to find this;
>>>
>>> Jan  1 10:55:29 raspberrypi weewx[9736]: reportengine: Caught 
>>> unrecoverable exception in generator weewx.cheetahgenerator.CheetahGenerator
>>>
>>> Jan  1 10:55:29 raspberrypi weewx[9736]:   'NoneType' 
>>> object has no attribute '__getitem__'
>>>
>>> Jan  1 10:55:29 raspberrypi weewx[9736]:   Traceback (most 
>>> recent call last):
>>>
>>> Jan  1 10:55:29 raspberrypi weewx[9736]: File 
>>> "/usr/share/weewx/weewx/reportengine.py", line 239, in run
>>>
>>> Jan  1 10:55:29 raspberrypi weewx[9736]:   obj.start()
>>>
>>> Jan  1 

Re: [weewx-user] Re: Belchertown DarkSky Alerts

[kutzenco]

Pat,
Yes, the alerts update automatically! I have a few that disappeared and new 
ones were added without my doing a refresh. I now have *7 *alerts showing! 
We've gotten a huge amount of rain and I'm showing flood alerts for several 
nearby rivers as well as alerts for the county. So, alerts are working 
great for me.

We've had a total of 3.3 inches of rain since the storm started yesterday - 
2.6 inches of that has been since midnight ☔. Hopefully it's over for now 
(radar looks clear). But there is some more rain forecast for Monday night.
phil

On Friday, December 28, 2018 at 11:38:49 AM UTC-5, Pat wrote:
>
> It should clear on archive intervals. Keep an eye on it and let me know
>
> On Friday, December 28, 2018 at 10:56:58 AM UTC-5, kutz...@gmail.com 
> wrote:
>>
>> Pat,
>>
>> Do the alerts update automatically on archive refresh like the graphs? Or 
>> do you need to manually refresh the page. I disabled timeout for my page as 
>> I want people to be able to leave it up always on a tablet, if they like. 
>> It would be nice if the alerts went away when withdrawn or update if 
>> changed. If they don't update automatically, could that feature be added?
>>
>> phil
>>
>

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

RE: [weewx-user] Re: Belchertown DarkSky Alerts

[kutzenco]

Done. Issue #31.

 

phil

 

From: weewx-user@googlegroups.com  On Behalf Of Pat
Sent: Friday, December 28, 2018 1:08 PM
To: weewx-user 
Subject: Re: [weewx-user] Re: Belchertown DarkSky Alerts

 

I could have sworn I looked at this. Can you put in a quick issue for me on the 
GitHub page so I don't forget it again?

On Friday, December 28, 2018 at 11:52:28 AM UTC-5, kutz...@gmail.com 
  wrote:

Sounds great Pat! I'll watch it and let you know.

 

Speaking of updates, I notice that the "Current Day" under "Weather Record 
Snapshots" on the main page (see attached screenshot) doesn't update 
automatically on archive intervals. The data in that block does update on 
archive intervals, but you need to refresh the page to get the day to change if 
you leave the website up overnight.

 

Can that be changed?

 

phil


On Friday, December 28, 2018 at 11:38:49 AM UTC-5, Pat wrote:

It should clear on archive intervals. Keep an eye on it and let me know

On Friday, December 28, 2018 at 10:56:58 AM UTC-5, kutz...@gmail.com 
  wrote:

Pat,

 

Do the alerts update automatically on archive refresh like the graphs? Or do 
you need to manually refresh the page. I disabled timeout for my page as I want 
people to be able to leave it up always on a tablet, if they like. It would be 
nice if the alerts went away when withdrawn or update if changed. If they don't 
update automatically, could that feature be added?

 

phil


On Friday, December 28, 2018 at 9:03:04 AM UTC-5, Pat wrote:

Wow that is a lot of alerts!


On Friday, December 28, 2018 at 8:59:30 AM UTC-5, kutz...@gmail.com 
  wrote:

Pat, Nice addition!!

 

It seems to be working great for me. We're in the middle of a major rainstorm - 
we currently have an embarrassment of alerts! See the attached jpg.

 

phil

-- 
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/sEd4sVkjpZw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
weewx-user+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Belchertown DarkSky Alerts

[kutzenco]

Sounds great Pat! I'll watch it and let you know.

Speaking of updates, I notice that the "Current Day" under "Weather Record 
Snapshots" on the main page (see attached screenshot) doesn't update 
automatically on archive intervals. The data in that block does update on 
archive intervals, but you need to refresh the page to get the day to 
change if you leave the website up overnight.

Can that be changed?

phil

On Friday, December 28, 2018 at 11:38:49 AM UTC-5, Pat wrote:
>
> It should clear on archive intervals. Keep an eye on it and let me know
>
> On Friday, December 28, 2018 at 10:56:58 AM UTC-5, kutz...@gmail.com 
> wrote:
>>
>> Pat,
>>
>> Do the alerts update automatically on archive refresh like the graphs? Or 
>> do you need to manually refresh the page. I disabled timeout for my page as 
>> I want people to be able to leave it up always on a tablet, if they like. 
>> It would be nice if the alerts went away when withdrawn or update if 
>> changed. If they don't update automatically, could that feature be added?
>>
>> phil
>>
>> On Friday, December 28, 2018 at 9:03:04 AM UTC-5, Pat wrote:
>>>
>>> Wow that is a lot of alerts!
>>>
>>> On Friday, December 28, 2018 at 8:59:30 AM UTC-5, kutz...@gmail.com 
>>> wrote:

 Pat, Nice addition!!

 It seems to be working great for me. We're in the middle of a major 
 rainstorm - we currently have an embarrassment of alerts! See the attached 
 jpg.

 phil

>>>

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

Re: [weewx-user] Re: Belchertown DarkSky Alerts

[kutzenco]

Pat,

Do the alerts update automatically on archive refresh like the graphs? Or 
do you need to manually refresh the page. I disabled timeout for my page as 
I want people to be able to leave it up always on a tablet, if they like. 
It would be nice if the alerts went away when withdrawn or update if 
changed. If they don't update automatically, could that feature be added?

phil

On Friday, December 28, 2018 at 9:03:04 AM UTC-5, Pat wrote:
>
> Wow that is a lot of alerts!
>
> On Friday, December 28, 2018 at 8:59:30 AM UTC-5, kutz...@gmail.com wrote:
>>
>> Pat, Nice addition!!
>>
>> It seems to be working great for me. We're in the middle of a major 
>> rainstorm - we currently have an embarrassment of alerts! See the attached 
>> jpg.
>>
>> phil
>>
>

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

Re: [weewx-user] Re: Belchertown Skin 0.8.1 released

[kutzenco]

I just checked your website and it's working for me. Congratulations!
phil

On Thursday, December 27, 2018 at 8:50:25 PM UTC-5, Scott Grayban wrote:
>
> ok I did a test from the outside seems to work but of course it 
> doesn't work in-house but I can live with that.
>
> Can everyone else check again please ?
>
> On Thursday, December 27, 2018 at 5:40:04 PM UTC-8, Scott Grayban wrote:
>>
>> Ahh so use my router IP instead and port forward 
>>
>> On Thursday, December 27, 2018 at 5:33:59 PM UTC-8, Colin Larsen wrote:
>>>
>>> My MQTT settings in skin.conf look like this - with my public web site 
>>> name in there
>>>
>>> # MQTT Defaults
>>>
>>> mqtt_enabled = 1
>>>
>>> mqtt_host = "41south.net.nz"
>>>
>>> mqtt_port = 9001
>>>
>>> mqtt_ssl = 0
>>>
>>> mqtt_topic = "weather/41south/loop"
>>>
>>> disconnect_live_website_visitor = 180
>>>
>>> On Fri, Dec 28, 2018 at 2:31 PM Colin Larsen  
>>> wrote:
>>>

 On Fri, Dec 28, 2018 at 2:29 PM Colin Larsen  
 wrote:

> My browser won't connect to your data, which is due to the fact that 
> you need to port forward the 9001 in your router - otherwise other users 
> outside your network can't access the MQTT data. You'll also need to 
> provide your public ip address or use your FQDN in that setting
>
> On Fri, Dec 28, 2018 at 2:25 PM Scott Grayban  
> wrote:
>
>> Got it !!!
>>
>> See if it works on your end 
>> http://www.nettletondistrict.com/Nettleton/
>>
>> On Thursday, December 27, 2018 at 5:14:02 PM UTC-8, Pat wrote:
>>>
>>> Also, Belchertown uses websockets, so you should change your 
>>> [[[Extras]]] mqtt_port to 9001 since that's what you have defined in 
>>> myconfig.conf. I didn't catch that earlier. 
>>>
>>> On Thursday, December 27, 2018 at 8:13:12 PM UTC-5, Pat wrote:

 Ok, so thinking about this. I'm an outside person, and I cannot 
 reach your 192.168.0.4 from the outside world. This is a problem 
 because I 
 need to reach that in order to get MQTT data on your website. 

 You need to port forward 9001 to 192.168.0.4 so I can reach it from 
 the outside 

 On Thursday, December 27, 2018 at 8:11:12 PM UTC-5, Scott Grayban 
 wrote:
>
> 192.168.0.4 is a local IP that has the weewx installed and data 
> pulled from the station but the website itself is served to the 
> public with 
> a outside IP 63.230.134.161 via a reverse proxy
>
> see http://www.nettletondistrict.com/Nettleton/ it works fine 
> doing a reverse proxy for everything but the MQTT so far.
>
> On Thursday, December 27, 2018 at 5:03:34 PM UTC-8, Pat wrote:
>>
>> I'm not sure what is causing that. Might be best to start from 
>> the basics again. Check out my article to compare your settings, 
>> read the 
>> descriptions again, and also check out the skin options to make sure 
>> you're 
>> not missing something. 
>>
>> Is your broker or weewx available to the public?
>>
>>
>> On Thursday, December 27, 2018 at 7:56:44 PM UTC-5, Scott Grayban 
>> wrote:
>>>
>>> Shit.mosquitto.log is showing Socket error on client 
>>> , disconnecting.
>>>
>>> 1545958518: New connection from 192.168.0.4 on port 1883.
>>> 1545958518: New client connected from 192.168.0.4 as 
>>> d413f626-b78b-4bca-8e99-43861d26dc6a (c1, k60, u'weewx').
>>> 1545958518: Client d413f626-b78b-4bca-8e99-43861d26dc6a 
>>> disconnected.
>>> 1545958520: New connection from 63.230.134.161 on port 1883.
>>> 1545958520: *Socket error on client , disconnecting.*
>>> 1545958533: New connection from 192.168.0.4 on port 1883.
>>>
>>>
>>> On Thursday, December 27, 2018 at 4:52:22 PM UTC-8, Pat wrote:

 Looks good

 On Thursday, December 27, 2018 at 7:50:49 PM UTC-5, Scott 
 Grayban wrote:
>
> Is my /etc/mosquitto/acl correct ? Or do I need to change 
> those values ?
>
> # Allow anonymous access to the sys
> topic read $SYS/#
> # Allow anonymous to read weather
> topic read weather/#
> # weewx readwrite to the loop
> user weewx
> topic weather/#
>
>
> On Thursday, December 27, 2018 at 4:43:02 PM UTC-8, Pat wrote:
>>
>> Ok, there's a few more things not quite right. 
>>
>> 1. MQTT is very picky about it's config file. Change your 
>> myconfig.conf so that there is no space between listener 1883 
>> and protocol 
>> mqtt. See 

[weewx-user] Re: problem with wind in WMR300

[kutzenco]

The loop data (at least the ones I looked at in the file you downloaded) 
are reporting windSpeed as 0.0. Is the console showing something different? 
If the console shows 0.0 for windSpeed also (and it is windy :-)), then 
maybe there is an issue with the anemometer or the wind sensor in the 
weatherstation.
phil

On Tuesday, December 25, 2018 at 6:58:02 AM UTC-5, Juan Antonio Mosquera 
wrote:
>
> Attach data...
>
>
> No wind data :(
>
> Standard weewx pages without windData too.
>
> Problem with statation console ¿
>
> Thanks...
>
>
>
> El lunes, 24 de diciembre de 2018, 11:43:26 (UTC+1), Andrew Milner 
> escribió:
>>
>> Can you run weewx directly to get the LOOP and REC records on the screen 
>> do you get wind readings??  Can you show us the result of running weewx 
>> directly??
>>
>> Do the standard weewx pages give wind values??
>>
>>
>>
>>
>> On Monday, 24 December 2018 10:10:06 UTC+2, Juan Antonio Mosquera wrote:
>>>
>>> I have updated belchertown to its version 0.8.0 and now to its version 
>>> 0.8.1. I do not understand what happens. Even with the old theme, it does 
>>> not show the wind data either.
>>>
>>> Belchertown:
>>> www.meteomontaos.es
>>>
>>> Sofaskin:
>>> www.meteomontaos2.ga
>>>
>>> Greetings and thanks.
>>>
>>> El lunes, 24 de diciembre de 2018, 3:26:01 (UTC+1), Andrew Milner 
>>> escribió:

 In your other thread you reported that wind speed and direction were 
 correctly being downloaded to weewx from the wmr300.  What happened to 
 make 
 you lose the wind data again??




 On Sunday, 23 December 2018 21:52:35 UTC+2, Juan Antonio Mosquera wrote:
>
> For months I have observed that I have problems in the measurement of 
> wind speed and direction. Even though I have data in the console, they do 
> not reach weewx. I am using the driver:
>
> wmr300-v19rc6 + f3
>
> They have tried to help me in other posts but now it has been several 
> weeks without any wind data.
>
> Greetings and 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Neowx

[kutzenco]

Ah. Maybe you were asking where to download the Neowx skin files to. If so, 
it shouldn't matter where you put them, as long as you point wee_extension 
to that directory (where you put the downloaded neowx-latest.zip file) with 
the command wee_extension --install='put directory path here'. 
Wee_extension will then place the files in the correct weewx directories 
when installing the skin.

Anyway, sounds like you sorted it out.
phil

On Monday, December 24, 2018 at 10:19:41 AM UTC-5, ve2se wrote:
>
> Have to install Neowx on the download directory 
> Tnx to all ,  Merry Christmas 

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

[weewx-user] Re: Neowx

[kutzenco]

I believe he's asking how to download the latest version of the neowx skin, 
not the latest version of weeWX. He can download the skin by going to 
https://projects.neoground.com/neowx and selecting Free Download.
phil

On Friday, December 21, 2018 at 10:12:46 PM UTC-5, Andrew Milner wrote:
>
> does this help:
> http://weewx.com/docs/upgrading.htm
>
>
>
> On Friday, 21 December 2018 21:02:39 UTC+2, ve2se wrote:
>>
>> Neowx 
>> First download the latest version and put it on your linux machine where 
>> weewx is running.
>> There so many directories for weewx . witch one i have to download neowx ?
>> tnx 
>>
>

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

[weewx-user] Re: table archive_day_barometer already exists

[kutzenco]

Dave,

Thanks for doing this and sharing it. I plan to try it out over the 
weekend. I'll let you know how it works in my setup!
phil

On Friday, December 14, 2018 at 5:46:26 PM UTC-5, Dave Harper wrote:
>
> Phil (and anyone else interested),
>
> The script is now written and I have spent most of the day testing it.  It 
> has currently been running for about three hours now and seems to be 
> running correctly.  I'm attaching the script and a set of instructions on 
> how to configure and run it.  The script creates and maintains a "last 
> known good" copy of the weewx.sdb database at whatever interval the user 
> specifies.  It also attempts to be as robust as possible, notifying the 
> user (via email) of any exception conditions rather than simply "failing 
> silently".  If you (or anyone else) runs it, I'd be interested in getting 
> feedback as to any issues discovered.
>
> Dave
>

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

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[kutzenco]

Ian,
Have you posted your syslog showing the errors? Are they the same as 
Hector's?
phil

On Thursday, December 13, 2018 at 4:50:21 PM UTC-5, steeple ian wrote:
>
> I am running a Pi 3 B+
>
> Sent from my iPhone
>
> On 13 Dec 2018, at 21:25, kutz...@gmail.com  wrote:
>
> Your log indicates that the database is becoming locked, causing weewx to 
> terminate the Generator. 
>
> What are you running weewx on? 
> Is it a Raspberry Pi? 
> If so, what model?
>
> I had similar problems when I was running weewx with the Belchertown skin 
> on a Raspberry Pi Zero W. The Pi Zero W took over 240 seconds to render the 
> graphs. My archive period is 5 minutes (300 seconds). When I added another 
> task to the Pi, it slowed down enough that weewx hung because the 
> Belchertown skin was trying to read the database at the same time that 
> weewx was trying to write archive data to the database.
>
> I moved my weewx implementation to a Raspberry Pi 3B+ and the Belchertown 
> graph rendering dropped to about 45 seconds and my problems went away.
>
> I suspect that's what's happening. to you.
>
> phil
>
>
On Thursday, December 13, 2018 at 4:50:21 PM UTC-5, steeple ian wrote:
>
> I am running a Pi 3 B+
>
> Sent from my iPhone
>
>

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

[weewx-user] Re: Belchertown skin for weewx now available!

[kutzenco]

Your log indicates that the database is becoming locked, causing weewx to 
terminate the Generator. 

What are you running weewx on? 
Is it a Raspberry Pi? 
If so, what model?

I had similar problems when I was running weewx with the Belchertown skin 
on a Raspberry Pi Zero W. The Pi Zero W took over 240 seconds to render the 
graphs. My archive period is 5 minutes (300 seconds). When I added another 
task to the Pi, it slowed down enough that weewx hung because the 
Belchertown skin was trying to read the database at the same time that 
weewx was trying to write archive data to the database.

I moved my weewx implementation to a Raspberry Pi 3B+ and the Belchertown 
graph rendering dropped to about 45 seconds and my problems went away.

I suspect that's what's happening. to you.

phil

On Thursday, December 13, 2018 at 2:50:16 PM UTC-5, Hector Valenzuela wrote:
>
> Hi Pat this is my problem. Most of the time weewx works well but there is 
> a moment when the following error occurs, the page loses all graphics and 3 
> minutes later it works normally again.
>
> Dec 13 12:38:21 san_martin weewx[25357]: engine: Shutting down StdReport 
> thread
> Dec 13 12:38:21 san_martin weewx[25357]: reportengine: Caught 
> unrecoverable exception in generator weewx.cheetahgenerator.CheetahGenerator
> Dec 13 12:38:21 san_martin weewx[25357]:   database is locked
> Dec 13 12:38:21 san_martin weewx[25357]:   Traceback (most 
> recent call last):
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/reportengine.py", line 140, in run
> Dec 13 12:38:21 san_martin weewx[25357]:   obj.start()
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/reportengine.py", line 170, in start
> Dec 13 12:38:21 san_martin weewx[25357]:   self.run()
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/cheetahgenerator.py", line 143, in run
> Dec 13 12:38:21 san_martin weewx[25357]:   ngen = 
> self.generate(gen_dict[option_section_name], self.gen_ts)
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/cheetahgenerator.py", line 206, in generate
> Dec 13 12:38:21 san_martin weewx[25357]:   ngen += 
> self.generate(section[subsection], gen_ts)
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/cheetahgenerator.py", line 206, in generate
> Dec 13 12:38:21 san_martin weewx[25357]:   ngen += 
> self.generate(section[subsection], gen_ts)
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/cheetahgenerator.py", line 290, in generate
> Dec 13 12:38:21 san_martin weewx[25357]:   default_binding)
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/cheetahgenerator.py", line 332, in _getSearchList
> Dec 13 12:38:21 san_martin weewx[25357]:   searchList += 
> obj.get_extension_list(timespan, db_lookup)
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/user/belchertown_highchartsSearchX.py", line 1084, in 
> get_extension_list
> Dec 13 12:38:21 san_martin weewx[25357]:   (time_start_vt, 
> time_stop_vt, radiation_vt) = db_lookup().getSqlVectors(TimeSpan(_start_ts, 
> _end_ts), 'radiation', 'max', 86400)
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/manager.py", line 496, in getSqlVectors
> Dec 13 12:38:21 san_martin weewx[25357]:   aggregate_type, 
> aggregate_interval)
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weewx/manager.py", line 723, in _getSqlVectors
> Dec 13 12:38:21 san_martin weewx[25357]:  
>  _cursor.execute(sql_str, stamp)
> Dec 13 12:38:21 san_martin weewx[25357]: File 
> "/home/weewx/bin/weedb/sqlite.py", line 37, in guarded_fn
> Dec 13 12:38:21 san_martin weewx[25357]:   raise 
> weedb.OperationalError(e)
> Dec 13 12:38:21 san_martin weewx[25357]:   OperationalError: 
> database is locked
> Dec 13 12:38:21 san_martin weewx[25357]:   Generator 
> terminated...
> Dec 13 12:38:23 san_martin weewx[25357]: reportengine: copied 0 files to 
> /home/weewx/public_html/belchertown/images
> Dec 13 12:38:29 san_martin weewx[25357]: reportengine: Caught 
> unrecoverable exception in generator weewx.cheetahgenerator.CheetahGenerator
> Dec 13 12:38:29 san_martin weewx[25357]:   database is locked
> Dec 13 12:38:29 san_martin weewx[25357]: reportengine: Caught 
> unrecoverable exception in generator weewx.cheetahgenerator.CheetahGenerator
> Dec 13 12:38:29 san_martin weewx[25357]:   database is locked
> Dec 13 12:38:29 san_martin weewx[25357]:   Traceback (most 
> recent call last):
> Dec 13 12:38:29 

[weewx-user] Re: table archive_day_barometer already exists

[kutzenco]

Dave,

That sounds like a great feature addition. I'd appreciate you sharing a 
copy of the script with me after you write it. In my implementation, the 
rsync "skin" gives me an offline copy of the database each night (or more 
or less often) and I can set a scheduled job to run your script against the 
offline copy automatically. If if finds that the database is corrupted, I 
can go back to an earlier database snapshot created by the Synology 
software. I like it!
phil

On Wednesday, December 12, 2018 at 4:16:43 PM UTC-5, Dave Harper wrote:
>
> Phil,
>
> One of the things I will be implementing in my new backup strategy is a 
> check to make sure the database isn't corrupted.  This can be done using 
> command line parameters to sqlite3.  When run manually, it looks something 
> like:
> pi@Weather:~ $ sqlite3 weewx.sdb 'pragma integrity_check'
> ok
> pi@Weather:~ $
> I will be including this in a new Python script which will send me an 
> email if it detects corruption.  Otherwise, it will archive that database 
> as "known good".  This should give me an early warning if something goes 
> wrong.  
>
> Dave
>   
>
> On Wednesday, December 12, 2018 at 10:36:09 AM UTC-6, kutz...@gmail.com 
> wrote:
>>
>> In the meantime, I can increase the time between rsync copies, as my 
>> Davis console should buffer about  a week's worth of archive data. That 
>> would give me more time to react to any database corruption.
>>
>> phil
>>
>>

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

[weewx-user] Re: table archive_day_barometer already exists

[kutzenco]

What I do is outlined in the weewx wiki here: 
https://github.com/weewx/weewx/wiki/Using-the-RSYNC-skin-as-a-backup-solution

I added the following to weewx.conf:













*[[RSYNCSQL]]# This backs up the sqlite databases to Diskstation 
skin = RsyncHTML_ROOT = /home/weewx/archive
server = 10.0.10.225user = weewxpath = 
/volume1/homes/weewx/archive_backup# every night at 
midnight, run this reportreport_timing = @daily
delete = 0*

The nice thing is that the backup is run synchronously within weewx 
ensuring the database is not being written to during the copy. From here - 
on my Synology NAS - I can set up a cron-driven backup script as you do, or 
utilize a purpose-written backup program like Duplicity. 

I haven't done that last part yet, so I need to catch any corruption within 
24 hours or my copy is overwritten by the corrupted database file. But, I 
plan to implement a backup that gives me multiple snapshots to choose from 
if I need to do a restore. I'm pretty sure Synology has a couple of backup 
packages that I could use.

In the meantime, I can increase the time between rsync copies, as my Davis 
console should buffer about  a week's worth of archive data. That would 
give me more time to react to any database corruption.

phil


On Wednesday, December 12, 2018 at 2:34:24 AM UTC-5, Dave Harper wrote:
>
> Gary,
>
> The backup strategy I use is a Python script I wrote that is started by 
> cron every night.  I had read that there could be a problem if the database 
> is copied while it's being updated.  The database is updated once a minute 
> by weeWX so the script monitors the mtime of the weewx.sdb file, waits for 
> the timestamp to change then waits about 15 seconds more before copying it 
> to a subdirectory off my home directory.  I also copy the /etc/weewx 
> directory into the same backup subdirectory and then the script calls 
> Duplicity to do the actual backup.  Duplicity works by starting with a full 
> backup the first time around and then doing incrementals from then on.  A 
> restore starts with the original full backup and then applies all 
> incremental changes to get to the target restore date.  To keep a restore 
> process within reason, I only do a month of incrementals and on the first 
> of each month the script creates a new monthly directory on the NAS.  This 
> strategy has seemed to work well over the past year or so and looking into 
> why it failed this time around will be one of the top priorities for 
> tomorrow.
>
> Dave
>

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

[weewx-user] Re: table archive_day_barometer already exists

[kutzenco]

Whoops. Someone who really knows crossposted at the same time I did. Happy 
to see my advice was good!
phil

On Tuesday, December 11, 2018 at 8:04:57 PM UTC-5, kutz...@gmail.com wrote:
>
> I'm not a database nor a weewx expert. But I'd try using the wee_database 
> utility trying first the --rebuild-daily option first (you could limit it 
> to only today). If that fails, I'd then do a wee_database --drop-daily 
> followed by a wee_database --rebuild-daily. See the Utlilities Guide on 
> this: http://weewx.com/docs/utilities.htm#wee_database_utility. Make sure 
> to stop weewx before using these commands and keep a backup of the database 
> if my advice hoses it :-).
> phil
>
> On Tuesday, December 11, 2018 at 7:03:48 PM UTC-5, Dave Harper wrote:
>>
>> Over the past year I've had numerous cases of a corrupted database.  I 
>> learned early on to have a good backup scheme in place and it has served me 
>> well - up until today.  After I noticed that the web page was no longer 
>> updating I checked the /var/sys/logfile and found the message 
>> "DatabaseError: database disk image is malformed".  Shortly after that I 
>> discovered my backups for the past month were not working, so I've been 
>> faced with trying to repair the weewx.sdb file.  I've found several posts 
>> describing how to recover from problems like this and ended up using the 
>> repairsdb.sh script that I found in one of them.  That fixed the 
>> "malformed" error and I am now able to load the database but when weewx 
>> starts it now aborts with the error that "table archive_day_barometer 
>> already exists".  I had never used sqlite3 prior to weewx and am not really 
>> familiar with what to try now.  Anybody have any ideas I can try?
>>
>> Thanks
>> Dave
>>
>

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

[weewx-user] Re: table archive_day_barometer already exists

[kutzenco]

I'm not a database nor a weewx expert. But I'd try using the wee_database 
utility trying first the --rebuild-daily option first (you could limit it 
to only today). If that fails, I'd then do a wee_database --drop-daily 
followed by a wee_database --rebuild-daily. See the Utlilities Guide on 
this: http://weewx.com/docs/utilities.htm#wee_database_utility. Make sure 
to stop weewx before using these commands and keep a backup of the database 
if my advice hoses it :-).
phil

On Tuesday, December 11, 2018 at 7:03:48 PM UTC-5, Dave Harper wrote:
>
> Over the past year I've had numerous cases of a corrupted database.  I 
> learned early on to have a good backup scheme in place and it has served me 
> well - up until today.  After I noticed that the web page was no longer 
> updating I checked the /var/sys/logfile and found the message 
> "DatabaseError: database disk image is malformed".  Shortly after that I 
> discovered my backups for the past month were not working, so I've been 
> faced with trying to repair the weewx.sdb file.  I've found several posts 
> describing how to recover from problems like this and ended up using the 
> repairsdb.sh script that I found in one of them.  That fixed the 
> "malformed" error and I am now able to load the database but when weewx 
> starts it now aborts with the error that "table archive_day_barometer 
> already exists".  I had never used sqlite3 prior to weewx and am not really 
> familiar with what to try now.  Anybody have any ideas I can try?
>
> Thanks
> Dave
>

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

Re: [weewx-user] Re: Belchertown Skin 0.8.1 released

[kutzenco]

That should do it.

If you have sqlite3 installed, you can open the database with the command 
sqlite3 
weewx.sdb and then issue the command:

 .schema archive

You should see `appTemp` REAL at the end of the list.

The command:

 .tables

should show archive_day_appTemp somewhere in the list.

 .exit

will exit the program

It's best to have weewx stopped prior to opening the database with sqlite3.
phil


On Monday, December 10, 2018 at 5:41:02 PM UTC-5, G Hammer wrote:

> Hmmm, well then I'm at a loss.
> I though the database had been extended.
>
> Here's what I did:
>
> Edit extensions.py to be:
> import schemas.wview
> schema_apptemp = schemas.wview.schema + [('appTemp',   'REAL')]
> Stop weewx
> Edit weewx.conf to have:
> [DataBindings]
> 
> [[wx_binding]]
> # The database must match one of the sections in [Databases].
> # This is likely to be the only option you would want to change.
> database = archive_sqlite
> # The name of the table within the database
> table_name = archive
> # The manager handles aggregation of data for historical summaries
> manager = weewx.wxmanager.WXDaySummaryManager
> # The schema defines the structure of the database.
> # It is *only* used when the database is created.
> #schema = schemas.wview.schema
> schema = user.extensions.schema_apptemp
> Ran wee_database weewx.conf --reconfigure
> Renamed weewx.sdb to weewx.sdb.org
> Renamed the new file to weewx.sdb
> Ran wee_database --rebuild-daily
>
> Start weewx
>
>
> On Monday, December 10, 2018 at 1:30:05 PM UTC-5, Colin Larsen wrote:
>>
>> If you haven't extended the database as per the Weewx wiki you will get 
>> those errors. I haven't written a guide but it is reasonably straightforward
>>
>> On Tue, 11 Dec 2018, 07:05 G Hammer >
>>> Yes, in fact followed your guide above. 
>>> The Feels like shows in the temp display, but when enabled in charts you 
>>> get the error. 
>>>
>>> -- 
>>> 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.
>>>
>>

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

[weewx-user] Re: Database not updating - any advice to minimize data loss?

[kutzenco]

Gary,

I'm all set! Thanks for the advice on doing the dump first. I did that and 
it loaded all of the archive data into the database - as you said, dump 
generated tons of "duplicate record" errors in the log. After the dump, I 
then tried unplugging and pulling the batteries out of the console. After 
starting weewx again, the log showed errors reading LOOP data, so I stopped 
weewx again and ran wee_device --clear-memory as instructed in the link you 
sent. I restarted weewx and all is better. WooHoo! Doesn't look like I lost 
anything except app_Temp (we just discussed that on the new Belchertown 
topic thread!) over that period. Since weewx calculates appTemp on the fly 
as it writes the archive values and it is not in the console memory, I 
wouldn't expect it to be written when a dump is used. It's not really a 
concern to have missed some of those values. I'm really interested in 
Apparent Temperature as a real time number, not so much its historical 
values.

Interestingly, the reason I didn't notice the console data hang-up for 30 
hours is that I see realtime data on my web page fed from MQTT. That and 
the fact that I live in Western North Carolina in the US where we just had 
our winter storm of the decade that dropped more snow in a day than we 
normally get in a year! So, I wasn't looking much at the graphs.

Thanks again.
phil

On Monday, December 10, 2018 at 3:56:07 PM UTC-5, gjr80 wrote:
>
> Hi,
>
> If it's a Davis and there has been a power outage chances are it is 
> corrupt station memory. Hopefully though you won't have lost 30 hours of 
> data (assuming you had batteries in the console), perhaps just one or two 
> records. You can sometimes get a pretty good indicator from the log if this 
> is the issue; typically the station will still emit loop packets but not 
> archive records, so if you are using hardware record generation there will 
> be no archive records being saved (so you won't see such entries in the 
> log) but anything based on loop packets will still be working; eg WU RF 
> updates or any services that are bound to new loop packets arriving.
>
> In any case the solution is the same, follow the steps, in order, for 
> corrupt station memory under WeeWX generates HTML pages, but it does not 
> update them 
> <http://weewx.com/docs/usersguide.htm#html_generated_but_not_updated>. 
> Note the comment about dumping station memory at the end of the section. 
> Make sure you do this first, this is what may well save you missing data. 
> If the logger memory can be accessed you will likely see a lot of duplicate 
> record errors in your log, that is fine and expected, but it should also 
> get the missing records and save them to database.
>
> Good luck.
>
> Gary
>
> On Tuesday, 11 December 2018 06:01:39 UTC+10, Philip Kutzenco wrote:
>>
>> I had a power outage about 30 hours ago and just realized that, since 
>> then, my weewx.sdb database is not being updated. I first thought that the 
>> database was damaged when the Raspberry Pi running weewx took the hit. 
>> However, I can open the database in sqlite3 and it looks ok. I also ran 
>> wee_database --reconfigure. I renamed the newly built database, but it's 
>> still not being updated by weewx.
>>
>> So, I'm assuming my Davis Vantage Vue console (with a USB data module 
>> connected to the Raspberry Pi) is what got hung. That console, while 
>> plugged in, does also have batteries, but I'm still guessing it took a hit 
>> from the power outage. I know that I can reset the memory in the 
>> console/data module, but I'd lose 30 hours of data (not really the end of 
>> the world). However, is there anything I can do to avoid losing that data?
>>
>> Thanks in advance.
>> phil
>>
>

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

[weewx-user] Database not updating - any advice to minimize data loss?

[Philip Kutzenco]

I had a power outage about 30 hours ago and just realized that, since then, 
my weewx.sdb database is not being updated. I first thought that the 
database was damaged when the Raspberry Pi running weewx took the hit. 
However, I can open the database in sqlite3 and it looks ok. I also ran 
wee_database --reconfigure. I renamed the newly built database, but it's 
still not being updated by weewx.

So, I'm assuming my Davis Vantage Vue console (with a USB data module 
connected to the Raspberry Pi) is what got hung. That console, while 
plugged in, does also have batteries, but I'm still guessing it took a hit 
from the power outage. I know that I can reset the memory in the 
console/data module, but I'd lose 30 hours of data (not really the end of 
the world). However, is there anything I can do to avoid losing that data?

Thanks in advance.
phil

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

[weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

See my post above in this topic : 
https://groups.google.com/d/msg/weewx-user/ARBHWDXiDpQ/7cz4m-Q7BAAJ. 
<https://groups.google.com/d/msg/weewx-user/ARBHWDXiDpQ/7cz4m-Q7BAAJ>

phil


On Monday, December 10, 2018 at 11:22:58 AM UTC-5, Wes Witt wrote:
>
> following. i'm interested in using apptemp to but would like to know what 
> is necessary to get the archive table configured properly.
>
> On Monday, December 10, 2018 at 7:54:39 AM UTC-8, Philip Kutzenco wrote:
>>
>> This is likely a naive question on my part. But did you extend the schema 
>> on the archive table for your database to include appTemp? Assuming so, did 
>> you rebuild the daily value tables? Are the values in the archive table and 
>> the archive_day_appTemp table being populated? When I look at your website, 
>> your daily.json data shows appTemp with a value of "N/A".phil
>>
>>
>> On Monday, December 10, 2018 at 10:09:52 AM UTC-5, G Hammer wrote:
>>>
>>> Here's the rest of the pertinent log entries that Groups cut off:
>>> Dec 10 09:55:50 ftp weewx[13683]:   raise weedb.
>>> NoColumnError(e)
>>> Dec 10 09:55:50 ftp weewx[13683]:   NoColumnError: no such 
>>> column: appTemp
>>> Dec 10 09:55:50 ftp weewx[13683]:   Generator terminated
>>> Dec 10 09:55:50 ftp weewx[13683]: copygenerator: copied 0 files to /home
>>> /weewx/public_html/weather
>>>
>>>
>>>
>>> On Monday, December 10, 2018 at 10:07:01 AM UTC-5, G Hammer wrote:
>>>>
>>>> Pat,
>>>>
>>>> When I have show_apptemp=1 I do see the Feels like temp as I expect.
>>>> If I set highcharts_show_apptemp = 1 I do not get an apptemp plot, the 
>>>> report generator errors out:
>>>> Dec 10 09:55:50 ftp weewx[13683]: reportengine: Caught unrecoverable 
>>>> exception in generator weewx.cheetahgenerator.CheetahGenerator
>>>> Dec 10 09:55:50 ftp weewx[13683]:   no such column: appTemp
>>>> Dec 10 09:55:50 ftp weewx[13683]:   Traceback (most recent 
>>>> call last):
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/reportengine.py", line 239, in run
>>>> Dec 10 09:55:50 ftp weewx[13683]:   obj.start()
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/reportengine.py", line 273, in start
>>>> Dec 10 09:55:50 ftp weewx[13683]:   self.run()
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 158, in run
>>>> Dec 10 09:55:50 ftp weewx[13683]:   ngen = self.
>>>> generate(gen_dict[section_name], self.gen_ts)
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 232, in generate
>>>> Dec 10 09:55:50 ftp weewx[13683]:   ngen += self.
>>>> generate(section[subsection], gen_ts)
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 232, in generate
>>>> Dec 10 09:55:50 ftp weewx[13683]:   ngen += self.
>>>> generate(section[subsection], gen_ts)
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 320, in generate
>>>> Dec 10 09:55:50 ftp weewx[13683]:   default_binding)
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 372, in 
>>>> _getSearchList
>>>> Dec 10 09:55:50 ftp weewx[13683]:   searchList += obj.
>>>> get_extension_list(timespan, db_lookup)
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/user/belchertown_highchartsSearchX.py", line 85, in 
>>>> get_extension_list
>>>> Dec 10 09:55:50 ftp weewx[13683]:   (time_start_vt, 
>>>> time_stop_vt, appTemp_vt) = db_lookup().getSqlVectors(TimeSpan(
>>>> _start_ts, _end_ts), 'appTemp')
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/manager.py", line 512, in getSqlVectors
>>>> Dec 10 09:55:50 ftp weewx[13683]:   aggregate_type, 
>>>> aggregate_interval)
>>>> Dec 10 09:55:50 ftp weewx[13683]: File 
>>>> "/home/weewx/bin/weewx/manager.py", line 775, in _getSqlVectors
>>>> Dec 10 09:55:50 ftp weewx[13683]:   for _rec in _cursor
>>>> .execute(sql_str, (startstamp, stopstamp)):
>>>> Dec 10 09:55https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

This is likely a naive question on my part. But did you extend the schema 
on the archive table for your database to include appTemp? Assuming so, did 
you rebuild the daily value tables? Are the values in the archive table and 
the archive_day_appTemp table being populated? When I look at your website, 
your daily.json data shows appTemp with a value of "N/A".phil


On Monday, December 10, 2018 at 10:09:52 AM UTC-5, G Hammer wrote:
>
> Here's the rest of the pertinent log entries that Groups cut off:
> Dec 10 09:55:50 ftp weewx[13683]:   raise weedb.
> NoColumnError(e)
> Dec 10 09:55:50 ftp weewx[13683]:   NoColumnError: no such 
> column: appTemp
> Dec 10 09:55:50 ftp weewx[13683]:   Generator terminated
> Dec 10 09:55:50 ftp weewx[13683]: copygenerator: copied 0 files to /home/
> weewx/public_html/weather
>
>
>
> On Monday, December 10, 2018 at 10:07:01 AM UTC-5, G Hammer wrote:
>>
>> Pat,
>>
>> When I have show_apptemp=1 I do see the Feels like temp as I expect.
>> If I set highcharts_show_apptemp = 1 I do not get an apptemp plot, the 
>> report generator errors out:
>> Dec 10 09:55:50 ftp weewx[13683]: reportengine: Caught unrecoverable 
>> exception in generator weewx.cheetahgenerator.CheetahGenerator
>> Dec 10 09:55:50 ftp weewx[13683]:   no such column: appTemp
>> Dec 10 09:55:50 ftp weewx[13683]:   Traceback (most recent 
>> call last):
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/reportengine.py", line 239, in run
>> Dec 10 09:55:50 ftp weewx[13683]:   obj.start()
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/reportengine.py", line 273, in start
>> Dec 10 09:55:50 ftp weewx[13683]:   self.run()
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 158, in run
>> Dec 10 09:55:50 ftp weewx[13683]:   ngen = self.generate(
>> gen_dict[section_name], self.gen_ts)
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 232, in generate
>> Dec 10 09:55:50 ftp weewx[13683]:   ngen += self.generate
>> (section[subsection], gen_ts)
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 232, in generate
>> Dec 10 09:55:50 ftp weewx[13683]:   ngen += self.generate
>> (section[subsection], gen_ts)
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 320, in generate
>> Dec 10 09:55:50 ftp weewx[13683]:   default_binding)
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/cheetahgenerator.py", line 372, in _getSearchList
>> Dec 10 09:55:50 ftp weewx[13683]:   searchList += obj.
>> get_extension_list(timespan, db_lookup)
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/user/belchertown_highchartsSearchX.py", line 85, in 
>> get_extension_list
>> Dec 10 09:55:50 ftp weewx[13683]:   (time_start_vt, 
>> time_stop_vt, appTemp_vt) = db_lookup().getSqlVectors(TimeSpan(_start_ts, 
>> _end_ts), 'appTemp')
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/manager.py", line 512, in getSqlVectors
>> Dec 10 09:55:50 ftp weewx[13683]:   aggregate_type, 
>> aggregate_interval)
>> Dec 10 09:55:50 ftp weewx[13683]: File 
>> "/home/weewx/bin/weewx/manager.py", line 775, in _getSqlVectors
>> Dec 10 09:55:50 ftp weewx[13683]:   for _rec in _cursor.
>> execute(sql_str, (startstamp, stopstamp)):
>> Dec 10 09:55https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

First, let me apologize for hijacking this Belchertown thread to get 
educated on Apparent Temperature.

Second, thanks Gary, your explanation clarifies it for me. It seems I was 
fixed on a simplistic definition of Apparent Temperature sometimes used in 
the US which yields the same value as either Wind Chill, Temperature, or 
Heat Index depending upon the value of "actual temperature". In contrast, 
the weewx calculation relies on the more sophisticated model developed by 
Steadman.

I actually like that the weewx calculated value is different than what I 
thought it should be. The simplistic definition doesn't add any new 
information as you could just look at Wind Chill, Heat Index and 
Temperature to get the same information the simple definition provides. In 
addition, I don't actually know what formula Vantage uses to calculate Wind 
Chill and Heat Index (I'll look it up), which my station hardware 
calculates and provides. 

The Steadman model gives a more nuanced value probably closer to what is 
intended - that is, what the human body perceives the temperature to be.

I'll move any further questions I have on this to a separate topic.
phil

On Sunday, December 9, 2018 at 6:05:08 PM UTC-5, gjr80 wrote:
>
> As you point out weeWX windchill and heatindex values track outTemp below 
> certain minimums and above certain maximums respectively. The weeWX 
> calculated appTemp uses the formulas mentioned in the post you linked and 
> is quite different to a composite heatindex and windchill (by composite I 
> mean windchill below 50F and heatindex above 81F). The key difference 
> (other than the formula) is that appTemp is valid across all temperatures. 
> appTemp is certainly affected by wind speed (just look at the formula), I 
> often notice appTemp moving in time (and quite markedly) with wind speed 
> changes on my realtime gauges.
>
> I like to think of 'feels like' as being a term that means different 
> things to different people and without an agreed understanding can be a 
> source of confusion. It really is just a general term that tries to better 
> approximate the effect of current weather conditions on the body, it could 
> be based on a measure of heatindex, windchill, humidex, wet bulb globe 
> temperature or apparent temperature. For me in Australia I think of 
> apparent temperature, I expect in Canada humidex may be a more accepted 
> measurement.
>
> The use of the term 'apparent temperature' can also be confusing at times; 
> does it refer to the accepted formula for Apparent Temperature (as you 
> linked or as used by weeWX) or is it the more literal meaining. For this 
> reason I prefer to refer to something like the 'weeWX appTemp field' or 
> 'Apparent Temperature' to make it clear I am referring to the calculated 
> value.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

Dj,

Check out this link for details: 
https://groups.google.com/d/msg/weewx-user/bNz3ymPNHHc/caYi1nqlAgAJ

I must say that I have been a bit confused about the appTemp value weewx 
calculates. My understanding is that the Apparent Temperature is equal to 
the Wind Chill number when the temp is 50 degrees F or below. It is equal 
to the Heat Index with the temp is 81 degrees F or above. My Vantage Vue 
transmits Wind Chill and Heat Index values. But the weewx calculated 
appTemp value doesn't match my understanding of what it should equal (or at 
least closely equal).

I wonder if it has to do with Loop Values for wind speed (which drives Wind 
Chill) and humidity (which drives Heat Index) vs. archive values for for 
those measures (which are aggregates). I don't know. Maybe someone else  
knows?
phil

On Sunday, December 9, 2018 at 5:04:01 PM UTC-5, Dj Merrill wrote:
>
> That worked beautifully, thank you Philip!
>
> I don't believe the data it is showing is correct, though.  Outside temp 
> is 23.5 F currently, with no wind.  It is showing a "feels like" 
> temperature of 18.1 F.  Other sources  are showing the feels like temp in 
> my area being the same as the outside temp.
>
> How is it calculating the data?
>
> Thanks,
>
> -Dj
>
>

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

[weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

One more thing:

extensions.py could be in /home/weewx/bin/user if you installed weewx with 
setup.py rather than with apt-get.
phil


On Sunday, December 9, 2018 at 4:51:15 PM UTC-5, Philip Kutzenco wrote:
>
> Dj,
>
> (I deleted the first version of this post as I left out a trailing "]" in 
> step 1).
>
> This is from instructions Pat gave me in the past to extend the schema:
>
> 1) Extend the database
>
> nano /usr/share/weewx/user/extensions.py
>
> then add the following:
>
>
> *import schemas.wviewschema_apptemp = schemas.wview.schema + 
> [('appTemp',   'REAL')]*
>
>
>
> 2) Stop weewx and edit weewx.conf to tell it to use this new schema 
> extension by adding the *schema = line* below to the [DataBindings] 
> stanza:
>
>
>
>
> *[DataBindings][[wx_binding]]...schema = 
> user.extensions.schema_apptemp*
>
>
>
> 3) Create a new copy of the database with the extended schema
>
> *wee_database weewx.conf --reconfigure*
> and then rename the databases
>
>
>
> 4) Rebuild the database with new daily values
>
> *Sudo wee_database --rebuild-daily*
>
>
>
> 5) restart weewx
>
> phil
>
>

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

[weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

Dj,

(I deleted the first version of this post as I left out a trailing "]" in 
step 1).

This is from instructions Pat gave me in the past to extend the schema:

1) Extend the database

nano /usr/share/weewx/user/extensions.py

then add the following:


*import schemas.wviewschema_apptemp = schemas.wview.schema + [('appTemp',   
'REAL')]*



2) Stop weewx and edit weewx.conf to tell it to use this new schema 
extension by adding the *schema = line* below to the [DataBindings] stanza:




*[DataBindings][[wx_binding]]...schema = 
user.extensions.schema_apptemp*



3) Create a new copy of the database with the extended schema

*wee_database weewx.conf --reconfigure*
and then rename the databases



4) Rebuild the database with new daily values

*Sudo wee_database --rebuild-daily*



5) restart weewx

phil

On Sunday, December 9, 2018 at 4:27:23 PM UTC-5, Dj Merrill wrote:
>
> Please forgive my ignorance.  It is not clear after reading the 
> instructions on extending the database precisely what I should do in this 
> case.  Obviously we don't have an "user/electricity.py" file, but we do 
> have a "user/belchertown.py" file.
>
> Should I modify the "belchertown.py" file with something like:
>
> import schemas.wview
> schema_with_apptemp = schemas.wview.schema + [('appTemp', 'REAL')]
>
>
> Then modify weewx.conf to have:
>
> [DataBindings]
> [[wx_binding]]
> database = archive_sqlite
> table_name = archive
> manager = weewx.wxmanager.WXDaySummaryManager
> schema = user.belchertown.schema_with_apptemp
>
>
> I am using SQLlite so I believe I can skip step 3.
>
> Then, "wee_database weewx.conf --reconfigure" and rename the databases?
>
> Thanks,
>
> -Dj
>
>

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

[weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

Dj,

This is from instructions Pat gave me in the past to extend the schema:

1) Extend the database

nano /usr/share/weewx/user/extensions.py

then add the following:


*import schemas.wviewschema_apptemp = schemas.wview.schema + [('appTemp',   
'REAL')*



2) Stop weewx and edit weewx.conf to tell it to use this new schema 
extension by adding the *schema = line* below to the [DataBindings] stanza:




*[DataBindings][[wx_binding]]...schema = 
user.extensions.schema_apptemp*



3) Create a new copy of the database with the extended schema

*wee_database weewx.conf --reconfigure*
and then rename the databases



4) Rebuild the database with new daily values

*Sudo wee_database --rebuild-daily*



5) restart weewx

phil

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

[weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

Dj,

In addition to extending the schema for your database to include appTemp, 
as Pat notes (this is a requirement), I recommend you add the line 
mentioned by Rich

show apptemp = 1

in the [[[Extras]]] stanza of the [[Belchertown]] stanza in weewx.conf 
(instead of adding it to skin.conf). This will ensure that the change 
"sticks" after installs of new Belchertown skin versions.
phil

On Sunday, December 9, 2018 at 3:49:43 PM UTC-5, Pat wrote:
>
> Thanks Dj! As mentioned in the general options guide 
> , your 
> database will need to be extended for the appTemp 
>  observations. 
>
> On Sunday, December 9, 2018 at 3:44:00 PM UTC-5, rich T wrote:
>>
>> Dj
>>
>> In the skin.conf file located in the Belchertown folder, set 
>> "show_apptemp = 1". Restart weewx.
>>
>> Rich 
>>
>> On Sunday, December 9, 2018 at 3:27:35 PM UTC-5, Dj Merrill wrote:
>>
>>> Pat, what a beautiful piece of work!  Thank you for sharing this with us!
>>>
>>> I notice on your site there is a "Feels like" temperature shown under 
>>> the outside temperature and above the high/low temps on the top of the main 
>>> page.  I don't see that on my site, and am wondering how to enable that?
>>>
>>> Thanks!
>>>
>>> -Dj
>>>
>>>

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

Re: [weewx-user] Re: Belchertown Skin 0.8.1 released

[Philip Kutzenco]

Also upgraded and working great (wx.kutzenco.com).
phil

On Friday, December 7, 2018 at 9:46:05 PM UTC-5, Colin Larsen wrote:
>
> Upgraded 41south.net.nz 
> 
>  
> and working great. In my footer I've added the version and updated date 
> just for reference.
>
> Colin
>
> On Sat, 8 Dec 2018, 12:25 Hector Valenzuela   wrote:
>
>> I installed version 0.1.  I'll have to try another version
>>
>> El viernes, 7 de diciembre de 2018, 15:12:23 (UTC-7), Pat escribió:
>>>
>>> The last thread was getting a bit long. So I've started a new one. 
>>>
>>> Belchertown Skin 0.8.1 has been released which fixes a couple of bugs. 
>>> See the release notes, and install instructions here:
>>>
>>> https://github.com/poblabs/weewx-belchertown/releases
>>>
>>>
>>> -- 
>> 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.
>>
>

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

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

In your weew.conf file (which you attached earlier), HTML_ROOT shoud be the 
same under the [[Belchertown]] stanza and the [Highcharts_Belchertown]] 
stanza. Yours are different. I think they should also be pointing to the 
weewx/belchertown folder (though I'm not sure).

I don't know if that would fix it, but give it a try.
phil

On Thursday, December 6, 2018 at 7:08:26 PM UTC-5, Teva MERVIN wrote:
>
> I use the apt-get.
> my web structure /var/www/html/weewx/belchertown
> All the files and directories are created (about / index.html ), but 
> not the index.html from the beginning
>
> I have this as an error message (message1.txt)
> Le vendredi 7 décembre 2018 10:57:01 UTC+11, Philip Kutzenco a écrit :
>
> I think that normally the Apache server should be serving up the files 
> located in public_html/belchertown. On my weewx system, that is 
> /home/weewx/public_html/belchertown. Did you install weewx with setup.py or 
> apt-get. That will determine where that directory actually is (I used 
> setup.py).
>
> What are the files in that directory? There should be an index.html file 
> (among all of the others) there.
> phil
>
> On Thursday, December 6, 2018 at 5:53:38 PM UTC-5, Teva MERVIN wrote:
>
> The web page is raw, without html, as on the file belchertown01.png
> I did not touch the skin.conf.
> I put it in an attached file.
>
> Le vendredi 7 décembre 2018 09:37:42 UTC+11, Colin Larsen a écrit :
>
> In what way does it not work properly? Do you have no web pages at all or 
> partial page? Have you set
>
> ...

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

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

I think that normally the Apache server should be serving up the files 
located in public_html/belchertown. On my weewx system, that is 
/home/weewx/public_html/belchertown. Did you install weewx with setup.py or 
apt-get. That will determine where that directory actually is (I used 
setup.py).

What are the files in that directory? There should be an index.html file 
(among all of the others) there.
phil

On Thursday, December 6, 2018 at 5:53:38 PM UTC-5, Teva MERVIN wrote:
>
> The web page is raw, without html, as on the file belchertown01.png
> I did not touch the skin.conf.
> I put it in an attached file.
>
> Le vendredi 7 décembre 2018 09:37:42 UTC+11, Colin Larsen a écrit :
>>
>> In what way does it not work properly? Do you have no web pages at all or 
>> partial page? Have you set up skin.conf Belchertown? Can you post that 
>> please.
>>
>> Colin
>>
>>
>> On Fri, 7 Dec 2018, 10:53 Teva MERVIN >
>>> Hello, and sorry for my approximate english ;)
>>>
>>> I'm trying to install your skin, I have:
>>> - 1 single debian server 4.18.10-2
>>> - Apache2 2.4.37-1
>>> - weewx v3.8.2
>>>
>>> and I have problems installing weewx-belchertown-0.8.tar.gz
>>> I think I have correctly followed your procedure, but the belchertown 
>>> web page does not display correctly
>>> See attach : belchertown01
>>>
>>> I am attaching my file weewx.conf
>>>
>>> What is the problem ?
>>> Thank you for your job's.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: New to WeeWX not sure where to go next

[Philip Kutzenco]

There are lots of terrific skins. The Standard one is a great one to start 
with.Then you can look around and see if there is another you'd prefer. 
Many like SteelSeries Gauges. I am personally fond of the Belchertown skin, 
developed by Pat O'Brien. It is available here: 
https://github.com/poblabs/weewx-belchertown/releases. My website using it 
is https://wx.kutzenco.com. 

I'm sure you'll enjoy weewx!
phil

On Tuesday, December 4, 2018 at 11:24:26 AM UTC-5, Robbie Lister wrote:
>
> Thank's Gary I will give that a go. By the sounds of things the built in 
> default template will be a god starting point.
>
> On Tuesday, 4 December 2018 15:40:39 UTC, Gary Hopkins wrote:
>>
>> sudo apt-get install nginx
>>
>> sudo /etc/init.d/nginx start
>>
>> NGINX defaults its web page location to /var/www/html on Raspbian so if you 
>> want to change that you need to edit
>>
>> /etc/nginx/sites-available/default
>>
>> and edit the line 
>>
>> root /var/www/html/;
>>
>> to
>>
>> root /var/www/html/weewx/;
>>
>>
>> After that you should be able to point a browser at the IP address of the 
>> Pi (hostname -I on the Pi if you want to know its IP address)
>>
>>
>> As for remote website, auto FTP upload is built into weewx. Edit the FTP 
>> section in weewx.conf it's faily self explanatory. There is a basic default 
>> template included - you don't have to do anything it just works.
>>
>> Cheers
>>
>> G
>>
>>

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

[weewx-user] Re: New to WeeWX not sure where to go next

[Philip Kutzenco]

There are lots of terrific skins. The Standard one is a great one to start 
with.Then you can look around and see if there is another you'd prefer. 
Many like SteelSeries Gauges. I am personally fond of the Belchertown skin, 
developed by Pat O'Brien. It is available here: 
https://github.com/poblabs/weewx-belchertown/releases.  My website using it 
is https://wx.kutzenco.com.

I'm sure you'll enjoy weewx!
phil

On Tuesday, December 4, 2018 at 11:24:26 AM UTC-5, Robbie Lister wrote:
>
> Thank's Gary I will give that a go. By the sounds of things the built in 
> default template will be a god starting point.
>
> On Tuesday, 4 December 2018 15:40:39 UTC, Gary Hopkins wrote:
>>
>> sudo apt-get install nginx
>>
>> sudo /etc/init.d/nginx start
>>
>> NGINX defaults its web page location to /var/www/html on Raspbian so if you 
>> want to change that you need to edit
>>
>> /etc/nginx/sites-available/default
>>
>> and edit the line 
>>
>> root /var/www/html/;
>>
>> to
>>
>> root /var/www/html/weewx/;
>>
>>
>> After that you should be able to point a browser at the IP address of the 
>> Pi (hostname -I on the Pi if you want to know its IP address)
>>
>>
>> As for remote website, auto FTP upload is built into weewx. Edit the FTP 
>> section in weewx.conf it's faily self explanatory. There is a basic default 
>> template included - you don't have to do anything it just works.
>>
>> Cheers
>>
>> G
>>
>>

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

[weewx-user] Re: Using a ProData WiFi Logger?

[Philip Kutzenco]

I don't have one of these. But it should work fine with the weeWX Vantage 
driver. It appears to emulate the Davis WeatherLinkIP interface (without 
having a Davis registered "DID", preventing free uploads to Davis own 
weatherlink.com website. FWIW, the Davis DID is the MAC address of the 
device.

In weewx.conf (in the [Vantage] stanza) you would set the "Connection type" 
to ethernet. You also need to set the "host" in that stanza to the IP 
address of the wifi-logger. One thing you need though is to set the 
IPaddress in the wifi-logger device to be the same every time it is 
rebooted. You can do that by specifying a static IP address for the device 
in your router. The device itself, may have a way to set a static IP 
address rather than pick up a new one via DHCP, I'm not sure. 
phil

On Saturday, November 17, 2018 at 11:00:26 PM UTC-5, cfor...@gmail.com 
wrote:
>
> Hello weewx-ers!
>
> Perhaps this is a naive question, but searching isn't turning up any 
> answers. Can I use weewx with this logger:
>
> https://www.weatherstations.co.uk/wifi-logger.htm
>
> It claims that it offers TCP/IP access to LOOP packets, so I presume weewx 
> would work with it, but has anyone tried it yet?
>
>
>
> Charlie
> -- 
> Earth, USA, GA, Atlanta
>

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

Re: [weewx-user] Vantage Vue wind cup size setting with wee_device

[Philip Kutzenco]

Thomas,

Thanks for the reply. I won't worry about it. The reason I asked is that 
the help file for Davis' Weatherlink software shows three options. See the 
attached screen shot I took for setting that in the console with 
Weatherlink. Evidently, you can set a VantagePro to use small cups or 
Vue/Other cups. I'll just leave the value as it is set in the console 
without setting it explicitly.
phil

On Saturday, October 20, 2018 at 8:22:26 PM UTC-4, Thomas Keffer wrote:
>
> A Vantage (whether a Vue or a VantagePro) ships with a value in the EEPROM 
> firmware that matches its cup size. Unless you change the cups, there is no 
> reason to mess with this value. The wee_device utility option is there if, 
> for some reason, you have to change the cups.
>
> To answer your question, the Davis documentation lists only two sizes: 
> small and large. If there's a third "Vue" sized, I haven't heard of it. 
> You'd have to ask Davis.
>
> -tk
>
> On Sat, Oct 20, 2018 at 7:35 AM Philip Kutzenco  > wrote:
>
>> Now that I have my external website operational (https://wx.kutzenco.com) 
>> with a Mosquitto MQTT broker and Belchertown skin, I'm spending a bit more 
>> time reviewing the weeWX documentation to get a deeper understanding of my 
>> system. I'm hoping to do some customization.
>>
>> I have a Davis Vantage Vue weather station and weeWX running on a 
>> Raspberry Pi Zero W. I see that the Davis Weatherlink software gives the 
>> options for wind cup size as Small, Large or Vue/Other. That Davis 
>> documentation says that Vantage Pro systems generally ship with large cups, 
>> and that (obviously) Vantage Vue systems ship with Vue cups.
>>
>> The wee_device --help command mentions only Small and Large options for 
>> wind cup size. Is there an option for Vue/other cups? I don't know what is 
>> adjusted in the readings/calculations by specifying different cup sizes. I 
>> didn't see that called out in the weeWX documention. I suspect the 
>> difference is minimal, but, just to ensure that everything can be set 
>> properly with weeWX does that option need to be added to wee_device for 
>> Vantage systems, if it isn't there?
>>
>> phil
>>
>> -- 
>> 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.
>>
>

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

[weewx-user] Vantage Vue wind cup size setting with wee_device

[Philip Kutzenco]

Now that I have my external website operational (https://wx.kutzenco.com) 
with a Mosquitto MQTT broker and Belchertown skin, I'm spending a bit more 
time reviewing the weeWX documentation to get a deeper understanding of my 
system. I'm hoping to do some customization.

I have a Davis Vantage Vue weather station and weeWX running on a Raspberry 
Pi Zero W. I see that the Davis Weatherlink software gives the options for 
wind cup size as Small, Large or Vue/Other. That Davis documentation says 
that Vantage Pro systems generally ship with large cups, and that 
(obviously) Vantage Vue systems ship with Vue cups.

The wee_device --help command mentions only Small and Large options for 
wind cup size. Is there an option for Vue/other cups? I don't know what is 
adjusted in the readings/calculations by specifying different cup sizes. I 
didn't see that called out in the weeWX documention. I suspect the 
difference is minimal, but, just to ensure that everything can be set 
properly with weeWX does that option need to be added to wee_device for 
Vantage systems, if it isn't there?

phil

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

[weewx-user] Re: Belchertown [[[Extras]]] not working?

[Philip Kutzenco]

I put my [[[Extras]]] stanza under [[Belchertown]] in weewx.conf and it's 
working in my implementation.
phil

On Tuesday, October 16, 2018 at 11:12:42 AM UTC-4, Gabe wrote:
>
> I had to put extras at the same level as Units. The github readme is 
> confusing (or maybe I'm just too dumb)
>
> skin = Belchertown
> [[[Units]]]
> Groups
> group_altitude = meter
> group_speed2 = meter_per_second2
> group_pressure = mbar
> group_rain = mm
> group_rainrate = mm_per_hour
> group_temperature = degree_C
> group_degree_day = degree_C_day
> group_speed = meter_per_second
> [[[Extras]]]
> footer_copyright_text = "Main Copyright"
> [[neowx]]
> HTML_ROOT = /var/www/html/weewx/neowx
> skin = neowx
> [[Highcharts_Belchertown]]
> HTML_ROOT = /var/www/html/weewx/belchertown
> skin = Highcharts_Belchertown
> [[Belchertown]]
> HTML_ROOT = /var/www/html/weewx/belchertown
> skin = Belchertown
>
>
> On Tuesday, October 16, 2018 at 10:59:25 AM UTC-4, Gabe wrote:
>>
>> I noticed that if I modify weewx.conf with [[[Extras]]], nothing happens 
>> in the skin. If I modify skin.conf, then it works (footer_copyright_text 
>> for example). Is this normal?
>>
>> skin = Belchertown
>> [[[Units]]]
>> Groups
>> group_altitude = meter
>> group_speed2 = meter_per_second2
>> group_pressure = mbar
>> group_rain = mm
>> group_rainrate = mm_per_hour
>> group_temperature = degree_C
>> group_degree_day = degree_C_day
>> group_speed = meter_per_second
>> [[neowx]]
>> HTML_ROOT = /var/www/html/weewx/neowx
>> skin = neowx
>> [[Highcharts_Belchertown]]
>> HTML_ROOT = /var/www/html/weewx/belchertown
>> skin = Highcharts_Belchertown
>> [[Belchertown]]
>> HTML_ROOT = /var/www/html/weewx/belchertown
>> skin = Belchertown
>> [[[Extras]]]
>> footer_copyright_text = "Test Copyright"
>>
>>

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

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

I think that version 0.7 is the most recent complete release. Pat has 
issued commits for updates to some files, mostly to address those using 
Metric units. So, individual files can be downloaded to implement those. I 
don't think he has yet packaged them all into a later version.
phil

On Tuesday, October 16, 2018 at 10:40:12 AM UTC-4, Paul Lacatus wrote:
>
> Is there a procedure to update the running belchertown skin 0.7 to the 
> last version on the github ? 
>
>

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

Re: [weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[Philip Kutzenco]

I think I found it.

In weewx.conf, you have:

[[tls]]
tls_version = tlsv1
ca_certs = /etc/ssl/certs/ca-certificates.crt

It should be:

[[[tls]]]
tls_version = tlsv1
ca_certs = /etc/ssl/certs/ca-certificates.crt

Note 3 brackets around tls. Try that.

BTW. I do have the extra lines you note in 
/etc/mosquitto/conf.d/myconfig.conf. I was in a huury when posting last 
night.

phil

On Friday, October 12, 2018 at 6:42:41 AM UTC-4, David Hindley wrote:
>
> Not sure it will help solve this or not, but the Mosquitto log shows the 
> following:
>
>  New connection from 86.27.145.159 on port 8883.
> 1539340809: OpenSSL Error: error:1408F10B:SSL 
> routines:ssl3_get_record:wrong version number
> 1539340809: Socket error on client , disconnecting.
> 1539340811: Client connection from 86.27.145.159 failed: 
> error:1408F10B:SSL routines:ssl3_get_record:wrong version number.
> 1539340814: New connection from 86.27.145.159 on port 8883.
>
> So, it does seem to be SSL related, but I am not sure how to solve this.  
> Any ideas please anyone?
>
> David.
>
> On Fri, 12 Oct 2018 at 10:01, David Hindley  > wrote:
>
>> Phil/Pat
>>
>> Many Thanks for you reply. 
>>
>> I did set up a password for Mosquitto and also the acl file, as per your 
>> email below.
>>
>> However, my myconfig.conf file is different to the one you listed below, 
>> as I am using Let's Encrypt SSL, so followed the format towards the end of 
>> Pat's post ( MQTT "tutorial" 
>>  ), as 
>> follows:
>>
>> persistence false
>>
>> allow_anonymous true
>> password_file /etc/mosquitto/passwd
>>
>> acl_file /etc/mosquitto/acl
>>
>> #Insecure mqtt to localhost only and secure mqtt with ssl
>> listener 1883 localhost
>> listener 8883
>> certfile /etc/letsencrypt/live/mqttdh.uk/cert.pem
>> cafile /etc/letsencrypt/live/mqttdh.uk/chain.pem
>> keyfile /etc/letsencrypt/live/mqttdh.uk/privkey.pem
>> protocol mqtt
>>
>> # websockets
>> listener 9001
>> certfile /etc/letsencrypt/live/mqttdh.uk/cert.pem
>> cafile /etc/letsencrypt/live/mqttdh.uk/chain.pem
>> keyfile /etc/letsencrypt/live/mqttdh.uk/privkey.pem
>> protocol websockets
>>
>> Did you not use SSL on your set up for  https://wx.kutzenco.com? Maybe I 
>> have done something wrong with trying to set this part up.  It is really 
>> frustrating, as the syslog reports that MQTT is sending records, as it 
>> contains several lines like:
>>
>> Oct 12 09:58:27 raspberrypi weewx[1147]: restx: MQTT: Published record 
>> 2018-10-12 09:58:28 BST (1539334708)
>>
>> Pat - if you see this, do you have any ideas what I might be doing wrong 
>> - my hunch is that it is something to do with the settings for SSL for MQTT 
>> in weewx.conf, which are shown below.  Do I need to create the 
>> ca-certificates.crt file?  Or I guess it could be some issue with my web 
>> host for www.ashteadweather.com which is 1&1 (with SSL).
>>
>> Thanks
>>
>> David.
>>
>> *weewx.conf file*
>>
>>   [[MQTT]]
>> server_url = mqtt://x:...@mqttdh.uk:8883/
>> topic = weather
>> unit_system = METRIC
>> aggregation = aggregate
>> binding = archive,loop
>> # log_success = False
>> # log_failure = True
>> [[tls]]
>>tls_version = tlsv1
>>ca_certs = /etc/ssl/certs/ca-certificates.crt
>>
>> The Belchertown skin.conf MQTT content is as follows:
>>
>>  # MQTT Defaults
>> mqtt_enabled = 1
>> mqtt_host = mqttdh.uk
>> mqtt_port = 9001
>> mqtt_ssl = 1
>> mqtt_topic = "weather/loop"
>> disconnect_live_website_visitor = 0
>>
>>

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

Re: [weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[Philip Kutzenco]

I may have found it.

in weewx.conf, you have a stanza:

[[tls]]
tls_version = tlsv1
ca_certs = /etc/ssl/certs/ca-certificates.crt

It should be:

[[[tls]]]
tls_version = tlsv1
ca_certs = /etc/ssl/certs/ca-certificates.crt

with 3 brackets.

Try that.

BTW: I do have the added lines in myconfig.conf that you do. I was in 
hurray when I posted last night.

phil


On Friday, October 12, 2018 at 6:42:41 AM UTC-4, David Hindley wrote:
>
> Not sure it will help solve this or not, but the Mosquitto log shows the 
> following:
>
>  New connection from 86.27.145.159 on port 8883.
> 1539340809: OpenSSL Error: error:1408F10B:SSL 
> routines:ssl3_get_record:wrong version number
> 1539340809: Socket error on client , disconnecting.
> 1539340811: Client connection from 86.27.145.159 failed: 
> error:1408F10B:SSL routines:ssl3_get_record:wrong version number.
> 1539340814: New connection from 86.27.145.159 on port 8883.
>
> So, it does seem to be SSL related, but I am not sure how to solve this.  
> Any ideas please anyone?
>
> David.
>
> On Fri, 12 Oct 2018 at 10:01, David Hindley  > wrote:
>
>> Phil/Pat
>>
>> Many Thanks for you reply. 
>>
>> I did set up a password for Mosquitto and also the acl file, as per your 
>> email below.
>>
>> However, my myconfig.conf file is different to the one you listed below, 
>> as I am using Let's Encrypt SSL, so followed the format towards the end of 
>> Pat's post ( MQTT "tutorial" 
>>  ), as 
>> follows:
>>
>> persistence false
>>
>> allow_anonymous true
>> password_file /etc/mosquitto/passwd
>>
>> acl_file /etc/mosquitto/acl
>>
>> #Insecure mqtt to localhost only and secure mqtt with ssl
>> listener 1883 localhost
>> listener 8883
>> certfile /etc/letsencrypt/live/mqttdh.uk/cert.pem
>> cafile /etc/letsencrypt/live/mqttdh.uk/chain.pem
>> keyfile /etc/letsencrypt/live/mqttdh.uk/privkey.pem
>> protocol mqtt
>>
>> # websockets
>> listener 9001
>> certfile /etc/letsencrypt/live/mqttdh.uk/cert.pem
>> cafile /etc/letsencrypt/live/mqttdh.uk/chain.pem
>> keyfile /etc/letsencrypt/live/mqttdh.uk/privkey.pem
>> protocol websockets
>>
>> Did you not use SSL on your set up for  https://wx.kutzenco.com? Maybe I 
>> have done something wrong with trying to set this part up.  It is really 
>> frustrating, as the syslog reports that MQTT is sending records, as it 
>> contains several lines like:
>>
>> Oct 12 09:58:27 raspberrypi weewx[1147]: restx: MQTT: Published record 
>> 2018-10-12 09:58:28 BST (1539334708)
>>
>> Pat - if you see this, do you have any ideas what I might be doing wrong 
>> - my hunch is that it is something to do with the settings for SSL for MQTT 
>> in weewx.conf, which are shown below.  Do I need to create the 
>> ca-certificates.crt file?  Or I guess it could be some issue with my web 
>> host for www.ashteadweather.com which is 1&1 (with SSL).
>>
>> Thanks
>>
>> David.
>>
>> *weewx.conf file*
>>
>>   [[MQTT]]
>> server_url = mqtt://x:...@mqttdh.uk:8883/
>> topic = weather
>> unit_system = METRIC
>> aggregation = aggregate
>> binding = archive,loop
>> # log_success = False
>> # log_failure = True
>> [[tls]]
>>tls_version = tlsv1
>>ca_certs = /etc/ssl/certs/ca-certificates.crt
>>
>> The Belchertown skin.conf MQTT content is as follows:
>>
>>  # MQTT Defaults
>> mqtt_enabled = 1
>> mqtt_host = mqttdh.uk
>> mqtt_port = 9001
>> mqtt_ssl = 1
>> mqtt_topic = "weather/loop"
>> disconnect_live_website_visitor = 0
>>
>>
>>>

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

Re: [weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[Philip Kutzenco]

David,

You don't need to specify a username/password to receive data if you have 
sett up your broker as Pat detailed in his post 
<https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/>. The weewx.conf 
stanzas in the file I attached in my earlier post are working fine at 
https://wx.kutzenco.com. One minor change is that I changed the 
subscription to "weather/loop" instead of "weather/#". It works with #, but 
I think best practice is to only subscribe to loop.

Here are some things to look at:

1. Did you set up a password for Mosquitto? It is done as follows:
*sudo mosquitto_passwd -c /etc/mosquitto/passwd *
Note that the username is just for Mosquitto. It doesn't need to be a linux 
account name.

1.  Did you set up an acl file (*/etc/mosquitto/acl)*? It should contain:



*# Allow anonymous access to the systopic read $SYS/# # Allow anonymous to 
read weathertopic read weather/#*


*# weewx readwrite to the loopuser topic 
weather/#*

2. Does your Mosquitto myconfig.conf (*/etc/mosquitto/conf.d/myconfig.conf) 
*file contain the following? It should have:





*persistence falseallow_anonymous truepassword_file 
/etc/mosquitto/passwdacl_file /etc/mosquitto/acllistener 1883protocol mqtt*



*# websocketslistener 9001protocol websocket *

I am far from an expert on this, but if you post copies of those files. I 
will look at them in addition to the weewx.conf stanzas you already 
published, ans see if I can spot a reason for it not working for you. (I 
probably won't get a chance to look until tomorrow).

phil

On Thursday, October 11, 2018 at 5:13:23 PM UTC-4, Colin Larsen wrote:
>
> You'll also need to supply the username and password to "receive" the MQTT 
> data (in skin.conf or Belchertown) but that is not yet supported as far as 
> I know.
>
> Colin
>
>
> On Fri, 12 Oct 2018, 07:59 , > wrote:
>
>> Hi 
>>
>>  
>>
>> I am trying to set up MQTT on the Belchertown skin, and just can't get it 
>> to work, but think I am very nearly there.  Like Philip Kutzenco, I am 
>> using Digital Ocean to host my MQTT broker, with my own domain name, and 
>> have followed Pat's guide to set up the MQTT broker with SSL using Let's 
>> Encrypt.   MQTT all seems to be working, as per Pat's guide.  My weather 
>> website (ashteadweather.com hosted at 1&1 with SSL certificate) says 
>> "Connected.  Waiting for data", which sounds promising, but it just stays 
>> at that message.  I copied the weewx.conf settings format for MQTT and the 
>> skin.conf format for Belchertown skin, as suggested by Philip Kutzenco, as 
>> per below:
>>
>>  
>>
>>  
>>
>>  
>>
>> weewx.conf:
>>
>>  
>>
>>  
>>
>> [[MQTT]]
>>
>> server_url = mqtt://:zz...@mqttdh.uk:8883/
>>
>> topic = weather
>>
>> unit_system = METRIC
>>
>> aggregation = aggregate
>>
>> binding = archive,loop
>>
>> log_success = False
>>
>> log_failure = True
>>
>> [[tls]]
>>
>>tls_version = tlsv1
>>
>>ca_certs = /etc/ssl/certs/ca-certificates.crt
>>
>>  
>>
>>  
>>
>>  
>>
>> Belchertown:
>>
>>  # MQTT Defaults
>>
>> mqtt_enabled = 1
>>
>> mqtt_host = mqttdh.uk
>>
>> mqtt_port = 9001
>>
>> mqtt_ssl = 1
>>
>> mqtt_topic = "weather/#"
>>
>> disconnect_live_website_visitor = 0
>>
>>  
>> Syslog does give any clues as to what is going wrong - no errors 
>> reported, for example.  Any suggestions from those that have got a similar 
>> set up.  I must be doing something basic wrong.  For example, do I need to 
>> put any certificates to follow the line   "ca_certs = 
>> /etc/ssl/certs/ca-certificates.crt" in weewx.conf?  Or is it something to 
>> with needing user names and passwords on publishing/subscribing perhaps?
>>
>> Many Thanks 
>>
>> David.
>>
>> On Tuesday, 9 October 2018 12:53:40 UTC+1, G Hammer wrote:
>>>
>>> I rarely cut & paste when configuring. 
>>>
>>> I too have found that restarting any service doesn’t always produce good 
>>> results.  I just stop then start things. 
>>>
>>> I’ll post my config files later as an example for others. 
>>>
>>> I’m just happy to have it running in house at long last. 
>>>
>>> The public test.mosquitto.org was not real reliable.  
>>>
>>> On Tue, Oct 9, 2018 at 7:45 AM Philip Kutzenco  
>>

Re: [weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[Philip Kutzenco]

Mosquitto is fussy, especially about its config files. In Pat's guide, he 
mentions that extra spaces at the end of lines messes things up. He says 
Mosquitto sometimes needs to be restarted completely. I found that 
Mosquitto also requires a newline at the end of config files. If you start 
(or restart) Mosquitto and it sees something it doesn't like in a config 
file, it immediately exits. Starting Mosquitto again, even if you first fix 
any errors in the config files, causes it to fail immediately again. 

For me, issuing a stop command first (sudo /etc/init.d/mosquitto stop) and 
then starting it (sudo /etc/init.d/mosquitto start) works. My theory  (with 
no real evidence :-)) is that when Mosquitto exits badly, it leaves its pid 
file, or some other flag, in place. When you try to start Mosquitto again, 
it sees that the pid file is there and won't start. If you first issue the 
stop command, Mosquitto clears the pid (or some other flag) which allows it 
to start when issued a start command.

I wonder if Mosquitto was unhappy about starting or restarting cleanly for 
you because of a leftover artifact, which cleared itself after time? Just 
speculation with no evidence.

Glad you have it running, at least.

phil

On Tuesday, October 9, 2018 at 6:27:24 AM UTC-4, G Hammer wrote:
>
> Well, I have followed Pat's guide and reconfigured my server's mosquitto 
> install.
> Websockets is a mysterious beast.
> This is what I get when I open my weather webpage:
> 1539079347: SNI: Unknown ServerName: ftp.ghammer.net
> 1539079348: Socket error on client , disconnecting.
> 1539079348: SNI: Unknown ServerName: ftp.ghammer.net
> 1539079368: SNI: Unknown ServerName: ftp.ghammer.net
>
> However, that is the server's name and the name in the SSL cert.
> 1539077963: Initial logging level 5
> 1539077963: Libwebsockets version: 2.0.3 unknown-build-hash
> 1539077963: IPV6 not compiled in
> 1539077963: libev support compiled in but disabled
> 1539077963: libuv support compiled in but disabled
> 1539077963:  Threads: 1 each 1024 fds
> 1539077963:  mem: platform fd map:  8192 bytes
> 1539077963:  Compiled with OpenSSL support
> 1539077963: Creating Vhost 'default' port 9001, 3 protocols
> 1539077963:  Using SSL mode
> 1539077963:  SSL ECDH curve 'prime256v1'
> 1539077963:  Listening on port 9001
> 1539077963:  mem: per-conn:  920 bytes + protocol rx buf
> 1539077963:  canonical_hostname = ftp.ghammer.net
> 1539077964: lws_protocol_init
>
> After about 15 minutes, voila!
> All is working with zero changes to any config.
> Quite puzzled, but not touching a thing.
>
> On Monday, October 8, 2018 at 5:52:39 PM UTC-4, Philip Kutzenco wrote:
>>
>> The answer to that question is no. I've attached a file with sanitized 
>> excerpts of my weewx.conf file showing the stanzas related to:
>>
>> 1. MQTT (publishing) - which specifies a username and password but not 
>> websocket (port 8883 - SSL not websocket)
>> 2. Belchertown Highcharts
>> 3. Belchertown (subscribing) - which specifies websockets but no 
>> username/password (port 9001 - SSL and websocket)
>>
>> You'll need to check with Pat, but I expect he saw no reason to lock down 
>> the subscriptions with username/password when programming his skin, only 
>> locking down the publishing (which is done by MWall's MQTT extension). I 
>> think the rationale is you don't care who sees the output (after all, it's 
>> being published on an open web site), but you don't want any unauthorized 
>> uploading of data which you'll be outputting and displaying to others.
>>
>> So, if the MQTT broker requires a username/password for subscribing over 
>> websockets, I don't know if the skin provides for that. I assume you've 
>> tried to prepend :@ to the host name in the Belchertown 
>> Extras stanza without success.
>>
>> Hopefully Pat can weigh in here.
>>
>> phil
>>
>>
>> On Monday, October 8, 2018 at 4:54:41 PM UTC-4, G Hammer wrote:
>>>
>>> Do you connect the client (skin) via websockets or any other way using a 
>>> username and password?
>>>
>>> That is the question.
>>>
>>>  
>>>
>>> *From:* weewx...@googlegroups.com  *On 
>>> Behalf Of *Philip Kutzenco
>>> *Sent:* Monday, October 8, 2018 3:32 PM
>>> *To:* weewx-user 
>>> *Subject:* [weewx-user] Re: Belchertown Skin and MQTT With Username Not 
>>> Working
>>>
>>>  
>>>
>>> I have it working on my own externally hosted Mosquitto server (on 
>>> Digital Ocean). My Mosquiutto MQTT broker is set up requiring a username 
>>> and password for publishing. Additionally it has TLS/SSL implemented (with 

[weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[Philip Kutzenco]

 I have it working on my own externally hosted Mosquitto server (on Digital 
Ocean). My Mosquitto MQTT broker is set up requiring a username and 
password for publishing. Additionally it has TLS/SSL implemented (with 
Let's Encrypt certificates). It allows subscribing anonymously and also 
runs Websockets so that it can feedthe Belchertown skin. I used Pat's MQTT 
"tutorial"  to 
do this. My website is https://wx.kutzenco.com.

phil

On Monday, October 8, 2018 at 10:21:50 AM UTC-4, G Hammer wrote:
>
>
> Does anyone have the Belchertown skin working with MQTT using a server 
> that requires a username and password such as CloudMQTT?
>
> I have tried several different ways of configuring the skin and it fails 
> to connect or it shows 'Connecting to weather station real time data' 
> forever without connecting.
> The data is being sent to the server fine and I have subscribed to it 
> using client software (see below).
>
> Thanks for any input, I'm at a loss here.
>
> [image: wxmqtt.png]
>
>

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

[weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[Philip Kutzenco]

I have it working on my own externally hosted Mosquitto server (on Digital 
Ocean). My Mosquiutto MQTT broker is set up requiring a username and 
password for publishing. Additionally it has TLS/SSL implemented (with 
Let's Encrypt certificates). It allows subscribing anonymously and also 
runs Websockets so that it can feedthe Belchertown skin. I used Pat's MQTT 
"tutorial"  to 
do this. My website is https://wx.kutzenco.com.

phil

On Monday, October 8, 2018 at 10:21:50 AM UTC-4, G Hammer wrote:
>
>
> Does anyone have the Belchertown skin working with MQTT using a server 
> that requires a username and password such as CloudMQTT?
>
> I have tried several different ways of configuring the skin and it fails 
> to connect or it shows 'Connecting to weather station real time data' 
> forever without connecting.
> The data is being sent to the server fine and I have subscribed to it 
> using client software (see below).
>
> Thanks for any input, I'm at a loss here.
>
> [image: wxmqtt.png]
>
>

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

[weewx-user] Re: Rsync vs FTP - which to choose/what are the pros and cons?

[Philip Kutzenco]

Thomas,

Can I make a request that the Rsync block in the initially default 
weewx.conf file be updated (for the next version) to include the following 
lines (which are included in the default weewx.conf FTP block but not the 
default weewx.conf RSYNC block):

# To upload files from something other than what HTML_ROOT is set
# to above, specify a different HTML_ROOT here.
#HTML_ROOT = public_html

It may be obvious to others, but it wasn't to me initially, that you need 
to specify that variable in the block to upload files generated by a 
specific skin. If you don't add an explicit HTML_ROOT definition in that 
block, the default HTML_ROOT definition from the beginning of weewx.conf is 
used.

By the way, I've gotten my external website set up and working great using 
Rsync to feed my weewx output files there. Thanks to everyone for weewx 
help and to you, in particular, for the terrific weewx software!!

phil

On Friday, October 5, 2018 at 5:26:09 PM UTC-4, Philip Kutzenco wrote:
>
> I am moving my weewx web server output to an outside hoster. What 
> considerations should I take into account to decide whether to use Rsync or 
> FTP (both should be available to me). I've looked at the user guide 
> sections for both options and (optimistically) believe I will be able to 
> set up either.
>
> What are the pros & cons of each method?
>
> Apologies if this question has been asked/answered before. If so, please 
> point me to the discussion or wiki topic.
>
> phil
>

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

Re: [weewx-user] Rsync vs FTP - which to choose/what are the pros and cons?

[Philip Kutzenco]

Perfect. Thanks!
phil

On Friday, October 5, 2018 at 5:35:07 PM UTC-4, Thomas Keffer wrote:
>
> rsync is superior in every way. It's secure, faster, and uses less 
> bandwidth. The only reason to use FTP is if your web host does not offer 
> rsync.
>
> -tk
>
> On Fri, Oct 5, 2018 at 2:26 PM Philip Kutzenco  > wrote:
>
>> I am moving my weewx web server output to an outside hoster. What 
>> considerations should I take into account to decide whether to use Rsync or 
>> FTP (both should be available to me). I've looked at the user guide 
>> sections for both options and (optimistically) believe I will be able to 
>> set up either.
>>
>> What are the pros & cons of each method?
>>
>> Apologies if this question has been asked/answered before. If so, please 
>> point me to the discussion or wiki topic.
>>
>> phil
>>
>> -- 
>> 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.
>>
>

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

[weewx-user] Rsync vs FTP - which to choose/what are the pros and cons?

[Philip Kutzenco]

I am moving my weewx web server output to an outside hoster. What 
considerations should I take into account to decide whether to use Rsync or 
FTP (both should be available to me). I've looked at the user guide 
sections for both options and (optimistically) believe I will be able to 
set up either.

What are the pros & cons of each method?

Apologies if this question has been asked/answered before. If so, please 
point me to the discussion or wiki topic.

phil

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

Re: [weewx-user] Date error on some historic data graphs using Belchertown skin

[Philip Kutzenco]

Pat's new .py file seems to fix some of the charts. But, I think not all. 
I'm gathering details and will send them to him to check and see if there 
is still an issue to address. I'll post what I find here.
phil

On Saturday, September 29, 2018 at 9:47:24 PM UTC-4, Pat wrote:
>
> Hi everyone, I think this has been resolved in a latest commit. In 0.6 I 
> was using timespan but also highcharts was packaged as 1 skin. The 
> timespans were giving me some problems, so I reverted to time.time and that 
> was causing the problems you see. Thanks Gary for taking the time to check 
> my code! 
>
> I've pushed an updated commit here 
> <https://github.com/poblabs/weewx-belchertown/commit/5ac7b8d7165737c2f3ffd7dcfb22fa6fbcb0801d>and
>  
> you can view the new file in full here 
> <https://github.com/poblabs/weewx-belchertown/blob/5ac7b8d7165737c2f3ffd7dcfb22fa6fbcb0801d/bin/user/belchertown_highchartsSearchX.py>.
>  
> Those here are welcome to try it. If I don't hear back it'll be rolled into 
> my 0.8 update when I release that. 
>
>
> On Tuesday, September 25, 2018 at 9:48:21 PM UTC-4, Philip Kutzenco wrote:
>>
>> Yes, same for me. The week.json datafile has the last point for each 
>> measurement associated with the beginning of the 60 minute period following 
>> the current time. So, it is the same cause. As you say, it's likely related 
>> to the timestamp Pat chose to use.
>>
>> Phil
>>
>> On Tuesday, September 25, 2018 at 7:12:57 PM UTC-4, Colin Larsen wrote:
>>>
>>> I've just noticed that the end of the Week chart is an hour ahead of my 
>>> current time - probably all related
>>>
>>> On Wed, Sep 26, 2018 at 7:40 AM Colin Larsen  
>>> wrote:
>>>
>>>> Thanks Gary and Phil for finding and sorting this :)
>>>>
>>>> On Wed, 26 Sep 2018, 04:19 Philip Kutzenco,  wrote:
>>>>
>>>>> Gary,
>>>>>
>>>>> Excellent. Thanks for sussing this out! I'll look forward to Pat's 
>>>>> next release.
>>>>>
>>>>> Phil
>>>>>
>>>>> On Tuesday, September 25, 2018 at 10:04:07 AM UTC-4, gjr80 wrote:
>>>>>>
>>>>>> OK, I think I have handle on what is happening here. The cause is as 
>>>>>> Phil has noted, the last timestamp in each data series in month.json 
>>>>>> is midnight at the end of the current local day. A commit by Pat on 4 
>>>>>> September changed that timestamp from being the last timestamp in the 
>>>>>> archive to being the midnight timestamp. Looking at the releases that 
>>>>>> Pat 
>>>>>> has made I think 0.7 will exhibit this behaviour but 0.6 does not. I 
>>>>>> will 
>>>>>> drop Pat a line with the details.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Tuesday, 25 September 2018 22:14:20 UTC+10, Philip Kutzenco wrote:
>>>>>>>
>>>>>>> So, looking at the data in the json file, the last epoch date in the 
>>>>>>> series is 153793440 and translates to September 26 at 4:00 AM UTC. 
>>>>>>> So 
>>>>>>> that is midnight on September 26 EDT (my time zone). So it sounds like 
>>>>>>> the 
>>>>>>> aggregated temperature data displayed is for the period prior to that 
>>>>>>> date/time. But it definitely makes the plot seem inaccurate, especially 
>>>>>>> when you look at past dates. You'd expect that the aggregated data 
>>>>>>> point to 
>>>>>>> correspond to the data gathered from the start of the date to midnight 
>>>>>>> just 
>>>>>>> before the next date starts. I hope that is clear (and that I'm not 
>>>>>>> confused). 
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, September 25, 2018 at 7:59:03 AM UTC-4, Philip Kutzenco 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Gary,
>>>>>>>>
>>>>>>>> I think this is the file you want me to post. It is timestamped 
>>>>>>>> September 25, 2108 at 7:46 AM. I am in the US Eastern Time Zone 
>>>>>>>> currently 
>>>>>>>> observing Daylight Saving Time. So my time zone is EDT. I checked 

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

You need to specify the full url, including http://

Best,

Phil

> On Sep 26, 2018, at 3:49 PM, Juan Antonio Mosquera 
>  wrote:
> 
> yesss
> 
>> On Wed, Sep 26, 2018, 21:43 Thomas Sch  wrote:
>> Thanks for the answer :) How do I do this? in weewx.conf ?
>> 
>> Am Mittwoch, 26. September 2018 21:31:46 UTC+2 schrieb Juan Antonio Mosquera:
>>> 
>>> Set station_url OK for css routes.
>>> 
>>> Hi.
>>> 
>>> El miércoles, 26 de septiembre de 2018, 21:14:18 (UTC+2), Thomas Sch 
>>> escribió:
 
> 
 
 Hey I installed the beautiful skin. But my generated website is not very 
 looking good. Is there a solution? I hope anyone can help me :D
 
  http://wilwetter.bplaced.net/wetterdaten/screenshot1.png
>> 
>> -- 
>> 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/GSrKZEiPqsc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx-user+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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/GSrKZEiPqsc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] NOAA data question

[Philip Kutzenco]

What skin are you using? I am using the belchertown skin. It copies the 
NOAA reports and displays them from the new location. I needed to delete 
the copy it made to force it to re-copy it before it would show the updated 
report. Again, my corrected data was from an older monthly NOAA report. I 
would go and check the actual NOAA report that the Standard report creates 
in /home/weewx/public_html/NOAA. If that's wrong, I'm sure Thomas will have 
a better suggestion.


Phil


On Wednesday, September 26, 2018 at 8:43:52 AM UTC-4, Charles Ross wrote:
>
> Yes I did, I followed that web page exactly yesterday.
>
>
> On Wednesday, September 26, 2018 at 8:37:22 AM UTC-4, Thomas Keffer wrote:
>>
>> Did you follow the directions in the Wiki entry, *Cleaning up old 'bad' 
>> data *?
>>
>> -tk
>>
>> On Wed, Sep 26, 2018 at 5:18 AM Charles Ross  wrote:
>>
>>> Hi all,
>>>
>>> Yesterday two pieces of bad temperature and dewpoint data made it's way 
>>> into the weewx.sdb archive database.   I removed the bad data but my NOAA 
>>> September and yearly files are still corrupt this morning.
>>>
>>> Can someone please guide me on how to fix the reports so I can have 
>>> correct NOAA reports?
>>>
>>> Thank you for taking the time to help,
>>>
>>> Chuck Ross 
>>>
>>> -- 
>>> 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.
>>>
>>

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

[weewx-user] Re: NOAA data question

[Philip Kutzenco]

I'll let those with more experience and knowledge weigh in, if this is more 
to this. But have you followed the steps in this link 
https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data? It worked 
for me. You shouldn't need to delete the existing NOAA reports as the 
latest monthly and yearly files should be re-created automatically (I had 
fixed older data and deleted the relevant monthly report to force 
re-creation). I think that dropping and rebuilding the old daily-summary 
tables is required.
Phil

On Wednesday, September 26, 2018 at 8:17:59 AM UTC-4, Charles Ross wrote:
>
> Hi all,
>
> Yesterday two pieces of bad temperature and dewpoint data made it's way 
> into the weewx.sdb archive database.   I removed the bad data but my NOAA 
> September and yearly files are still corrupt this morning.
>
> Can someone please guide me on how to fix the reports so I can have 
> correct NOAA reports?
>
> Thank you for taking the time to help,
>
> Chuck Ross 
>

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

Re: [weewx-user] Date error on some historic data graphs using Belchertown skin

[Philip Kutzenco]

Yes, same for me. The week.json datafile has the last point for each 
measurement associated with the beginning of the 60 minute period following 
the current time. So, it is the same cause. As you say, it's likely related 
to the timestamp Pat chose to use.

Phil

On Tuesday, September 25, 2018 at 7:12:57 PM UTC-4, Colin Larsen wrote:
>
> I've just noticed that the end of the Week chart is an hour ahead of my 
> current time - probably all related
>
> On Wed, Sep 26, 2018 at 7:40 AM Colin Larsen  > wrote:
>
>> Thanks Gary and Phil for finding and sorting this :)
>>
>> On Wed, 26 Sep 2018, 04:19 Philip Kutzenco, > > wrote:
>>
>>> Gary,
>>>
>>> Excellent. Thanks for sussing this out! I'll look forward to Pat's next 
>>> release.
>>>
>>> Phil
>>>
>>> On Tuesday, September 25, 2018 at 10:04:07 AM UTC-4, gjr80 wrote:
>>>>
>>>> OK, I think I have handle on what is happening here. The cause is as 
>>>> Phil has noted, the last timestamp in each data series in month.json 
>>>> is midnight at the end of the current local day. A commit by Pat on 4 
>>>> September changed that timestamp from being the last timestamp in the 
>>>> archive to being the midnight timestamp. Looking at the releases that Pat 
>>>> has made I think 0.7 will exhibit this behaviour but 0.6 does not. I will 
>>>> drop Pat a line with the details.
>>>>
>>>> Gary
>>>>
>>>> On Tuesday, 25 September 2018 22:14:20 UTC+10, Philip Kutzenco wrote:
>>>>>
>>>>> So, looking at the data in the json file, the last epoch date in the 
>>>>> series is 153793440 and translates to September 26 at 4:00 AM UTC. So 
>>>>> that is midnight on September 26 EDT (my time zone). So it sounds like 
>>>>> the 
>>>>> aggregated temperature data displayed is for the period prior to that 
>>>>> date/time. But it definitely makes the plot seem inaccurate, especially 
>>>>> when you look at past dates. You'd expect that the aggregated data point 
>>>>> to 
>>>>> correspond to the data gathered from the start of the date to midnight 
>>>>> just 
>>>>> before the next date starts. I hope that is clear (and that I'm not 
>>>>> confused). 
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, September 25, 2018 at 7:59:03 AM UTC-4, Philip Kutzenco 
>>>>> wrote:
>>>>>>
>>>>>> Gary,
>>>>>>
>>>>>> I think this is the file you want me to post. It is timestamped 
>>>>>> September 25, 2108 at 7:46 AM. I am in the US Eastern Time Zone 
>>>>>> currently 
>>>>>> observing Daylight Saving Time. So my time zone is EDT. I checked the 
>>>>>> date 
>>>>>> and time with the date command on my Raspberry Pi running running weewx 
>>>>>> and 
>>>>>> it is correct.
>>>>>>
>>>>>> Let me know if you wanted a different file.
>>>>>>
>>>>>> Thanks. I appreciate the help.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> On Monday, September 24, 2018 at 11:33:58 PM UTC-4, gjr80 wrote:
>>>>>>>
>>>>>>> I suspect the issue will be related to how highcharts is 
>>>>>>> interpreting timestamps in the plot data rather then the wrong data 
>>>>>>> being 
>>>>>>> in the plot data files. I have seen something like this before but it 
>>>>>>> was 
>>>>>>> related to the timezone of the client computer viewing the plots, would 
>>>>>>> seem that is not the issue here though. I am rather pushed for time at 
>>>>>>> the 
>>>>>>> moment but will have a look when I can, though it's been a while though 
>>>>>>> since I have delved into highcharts.
>>>>>>>
>>>>>>> Phil, can you post one of the generated  highcharts data files that 
>>>>>>> is displaying the issue. Would help to know your timezone and at  what 
>>>>>>> time 
>>>>>>> the file was generated as well.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com .
>>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Date error on some historic data graphs using Belchertown skin

[Philip Kutzenco]

Gary,

Excellent. Thanks for sussing this out! I'll look forward to Pat's next 
release.

Phil

On Tuesday, September 25, 2018 at 10:04:07 AM UTC-4, gjr80 wrote:
>
> OK, I think I have handle on what is happening here. The cause is as Phil 
> has noted, the last timestamp in each data series in month.json is 
> midnight at the end of the current local day. A commit by Pat on 4 
> September changed that timestamp from being the last timestamp in the 
> archive to being the midnight timestamp. Looking at the releases that Pat 
> has made I think 0.7 will exhibit this behaviour but 0.6 does not. I will 
> drop Pat a line with the details.
>
> Gary
>
> On Tuesday, 25 September 2018 22:14:20 UTC+10, Philip Kutzenco wrote:
>>
>> So, looking at the data in the json file, the last epoch date in the 
>> series is 153793440 and translates to September 26 at 4:00 AM UTC. So 
>> that is midnight on September 26 EDT (my time zone). So it sounds like the 
>> aggregated temperature data displayed is for the period prior to that 
>> date/time. But it definitely makes the plot seem inaccurate, especially 
>> when you look at past dates. You'd expect that the aggregated data point to 
>> correspond to the data gathered from the start of the date to midnight just 
>> before the next date starts. I hope that is clear (and that I'm not 
>> confused). 
>>
>> Phil
>>
>>
>>
>> On Tuesday, September 25, 2018 at 7:59:03 AM UTC-4, Philip Kutzenco wrote:
>>>
>>> Gary,
>>>
>>> I think this is the file you want me to post. It is timestamped 
>>> September 25, 2108 at 7:46 AM. I am in the US Eastern Time Zone currently 
>>> observing Daylight Saving Time. So my time zone is EDT. I checked the date 
>>> and time with the date command on my Raspberry Pi running running weewx and 
>>> it is correct.
>>>
>>> Let me know if you wanted a different file.
>>>
>>> Thanks. I appreciate the help.
>>>
>>> Phil
>>>
>>> On Monday, September 24, 2018 at 11:33:58 PM UTC-4, gjr80 wrote:
>>>>
>>>> I suspect the issue will be related to how highcharts is interpreting 
>>>> timestamps in the plot data rather then the wrong data being in the plot 
>>>> data files. I have seen something like this before but it was related to 
>>>> the timezone of the client computer viewing the plots, would seem that is 
>>>> not the issue here though. I am rather pushed for time at the moment but 
>>>> will have a look when I can, though it's been a while though since I have 
>>>> delved into highcharts.
>>>>
>>>> Phil, can you post one of the generated  highcharts data files that is 
>>>> displaying the issue. Would help to know your timezone and at  what time 
>>>> the file was generated as well.
>>>>
>>>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Date error on some historic data graphs using Belchertown skin

[Philip Kutzenco]

So, looking at the data in the json file, the last epoch date in the series 
is 153793440 and translates to September 26 at 4:00 AM UTC. So that is 
midnight on September 26 EDT (my time zone). So it sounds like the 
aggregated temperature data displayed is for the period prior to that 
date/time. But it definitely makes the plot seem inaccurate, especially 
when you look at past dates. You'd expect that the aggregated data point to 
correspond to the data gathered from the start of the date to midnight just 
before the next date starts. I hope that is clear (and that I'm not 
confused). 

Phil



On Tuesday, September 25, 2018 at 7:59:03 AM UTC-4, Philip Kutzenco wrote:
>
> Gary,
>
> I think this is the file you want me to post. It is timestamped September 
> 25, 2108 at 7:46 AM. I am in the US Eastern Time Zone currently observing 
> Daylight Saving Time. So my time zone is EDT. I checked the date and time 
> with the date command on my Raspberry Pi running running weewx and it is 
> correct.
>
> Let me know if you wanted a different file.
>
> Thanks. I appreciate the help.
>
> Phil
>
> On Monday, September 24, 2018 at 11:33:58 PM UTC-4, gjr80 wrote:
>>
>> I suspect the issue will be related to how highcharts is interpreting 
>> timestamps in the plot data rather then the wrong data being in the plot 
>> data files. I have seen something like this before but it was related to 
>> the timezone of the client computer viewing the plots, would seem that is 
>> not the issue here though. I am rather pushed for time at the moment but 
>> will have a look when I can, though it's been a while though since I have 
>> delved into highcharts.
>>
>> Phil, can you post one of the generated  highcharts data files that is 
>> displaying the issue. Would help to know your timezone and at  what time 
>> the file was generated as well.
>>
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Date error on some historic data graphs using Belchertown skin

[Philip Kutzenco]

OK. More info. I checked Pat O'Brien's website and also  Juan Antonio 
Mosquera's website. Neither shows the date offset that my website shows. 
So, It looks like I've got a problem with my implementation or my database. 
But, since the NOAA reports for monthly min and max seem to be correct, 
that argues, I think, that the database is ok.

Where should I look? I considered time zone offsets, but Pat and I are in 
the same time zone and his website doesn't exhibit the issue. Is it in the 
calculation of daily min and max? Is there a way to clear them and 
recalculate/store them in the database?

Best,
Phil

On Monday, September 24, 2018 at 10:24:30 PM UTC-4, Philip Kutzenco wrote:
>
> Ah, yes. Gary is correct. It appears that only rainfall is aggregated (two 
> hour aggregates for the Monthly plot). The others seem to be Min or Max at 
> a discrete time.
>
> Phil
>
> On Monday, September 24, 2018 at 10:19:34 PM UTC-4, Philip Kutzenco wrote:
>>
>> Thomas,
>>
>> I think you are correct about aggregated data. Unfortunately, my website 
>> isn't externally available (yet). But I attached a couple of screenshots 
>> (monthly temperature and rainfall). On the monthly plots, each point seems 
>> to represent a 2 hour aggregate. You can see how the latest temperature 
>> data is associated with tomorrow's date, while the latest rainfall data is 
>> labeled with today's date.
>>
>> I don't have any other skins with Highcharts. So, I don't know if my 
>> issue is confined to my implementation, or the Belchertown skin, or if it 
>> is caused by the Highcharts code itself.
>>
>> Phil
>>
>> On Monday, September 24, 2018 at 9:19:10 PM UTC-4, Thomas Keffer wrote:
>>>
>>> You're probably right. Plus, I gather that you are working with 
>>> aggregated plots, not the raw data?
>>>
>>> It was just a thought...
>>>
>>> -tk
>>>
>>> On Mon, Sep 24, 2018 at 6:11 PM Philip Kutzenco  
>>> wrote:
>>>
>>>> If that's so, wouldn't rainfall also exhibit the offset?
>>>>
>>>> Even if Thomas is correct (and something about rainfall calculation 
>>>> keeps it from being offset), the call out numbers (showing data values and 
>>>> date) you see when you move the cursor across the graph are wrong because 
>>>> of the date offset. So, it may be a bug, but the graphs are definitely 
>>>> wrong, at least in my implementation of the Belchertown skin. 
>>>>
>>>> Phil
>>>>
>>>> On Monday, September 24, 2018 at 8:14:19 PM UTC-4, Thomas Keffer wrote:
>>>>>
>>>>> In WeeWX, records are timestamped with the *end* of the record. 
>>>>> Perhaps Highcharts uses the beginning?
>>>>>
>>>>> -tk
>>>>>
>>>>> On Mon, Sep 24, 2018 at 10:28 AM Philip Kutzenco  
>>>>> wrote:
>>>>>
>>>>>> I notice that, for me, some of the historic data graphs supplied with 
>>>>>> the Belchertown skin are off by one day. In particular, if you go to the 
>>>>>> "Graphs" page and select either "Month" or "Year", the temperature graph 
>>>>>> data are labeled as being one day beyond what they should be. For 
>>>>>> instance 
>>>>>> at the right end of the plot, today's data is shown, but the date on the 
>>>>>> y-axis is tomorrow's date.
>>>>>>
>>>>>> This is also true for the Wind/Wind Gust graph, the Wind Direction 
>>>>>> graph and also the Barometer graph. The Rainfall graph is fine.
>>>>>>
>>>>>> If you select "Week" all of the graphs are fine; of course the data 
>>>>>> on the "Today" and "Week" are actual recorded data points, while the 
>>>>>> "Month" and "Year" data are max and min data for each date.
>>>>>>
>>>>>> For some more context, the Standard skin shows the correct max and 
>>>>>> min temperature data for the month of September (I didn't check 
>>>>>> further). 
>>>>>> Also, I did need to NULL some anomalous temperature data in the database 
>>>>>> for June 14 (the guy who stained my back deck through a plastic sheet 
>>>>>> over 
>>>>>> my weather station for  hours). I followed the directions in the Wiki 
>>>>>> and 
>>>>>> had weewx recalculate the summaries without inc

Re: [weewx-user] Date error on some historic data graphs using Belchertown skin

[Philip Kutzenco]

Ah, yes. Gary is correct. It appears that only rainfall is aggregated (two 
hour aggregates for the Monthly plot). The others seem to be Min or Max at 
a discrete time.

Phil

On Monday, September 24, 2018 at 10:19:34 PM UTC-4, Philip Kutzenco wrote:
>
> Thomas,
>
> I think you are correct about aggregated data. Unfortunately, my website 
> isn't externally available (yet). But I attached a couple of screenshots 
> (monthly temperature and rainfall). On the monthly plots, each point seems 
> to represent a 2 hour aggregate. You can see how the latest temperature 
> data is associated with tomorrow's date, while the latest rainfall data is 
> labeled with today's date.
>
> I don't have any other skins with Highcharts. So, I don't know if my issue 
> is confined to my implementation, or the Belchertown skin, or if it is 
> caused by the Highcharts code itself.
>
> Phil
>
> On Monday, September 24, 2018 at 9:19:10 PM UTC-4, Thomas Keffer wrote:
>>
>> You're probably right. Plus, I gather that you are working with 
>> aggregated plots, not the raw data?
>>
>> It was just a thought...
>>
>> -tk
>>
>> On Mon, Sep 24, 2018 at 6:11 PM Philip Kutzenco  
>> wrote:
>>
>>> If that's so, wouldn't rainfall also exhibit the offset?
>>>
>>> Even if Thomas is correct (and something about rainfall calculation 
>>> keeps it from being offset), the call out numbers (showing data values and 
>>> date) you see when you move the cursor across the graph are wrong because 
>>> of the date offset. So, it may be a bug, but the graphs are definitely 
>>> wrong, at least in my implementation of the Belchertown skin. 
>>>
>>> Phil
>>>
>>> On Monday, September 24, 2018 at 8:14:19 PM UTC-4, Thomas Keffer wrote:
>>>>
>>>> In WeeWX, records are timestamped with the *end* of the record. 
>>>> Perhaps Highcharts uses the beginning?
>>>>
>>>> -tk
>>>>
>>>> On Mon, Sep 24, 2018 at 10:28 AM Philip Kutzenco  
>>>> wrote:
>>>>
>>>>> I notice that, for me, some of the historic data graphs supplied with 
>>>>> the Belchertown skin are off by one day. In particular, if you go to the 
>>>>> "Graphs" page and select either "Month" or "Year", the temperature graph 
>>>>> data are labeled as being one day beyond what they should be. For 
>>>>> instance 
>>>>> at the right end of the plot, today's data is shown, but the date on the 
>>>>> y-axis is tomorrow's date.
>>>>>
>>>>> This is also true for the Wind/Wind Gust graph, the Wind Direction 
>>>>> graph and also the Barometer graph. The Rainfall graph is fine.
>>>>>
>>>>> If you select "Week" all of the graphs are fine; of course the data on 
>>>>> the "Today" and "Week" are actual recorded data points, while the "Month" 
>>>>> and "Year" data are max and min data for each date.
>>>>>
>>>>> For some more context, the Standard skin shows the correct max and min 
>>>>> temperature data for the month of September (I didn't check further). 
>>>>> Also, 
>>>>> I did need to NULL some anomalous temperature data in the database for 
>>>>> June 
>>>>> 14 (the guy who stained my back deck through a plastic sheet over my 
>>>>> weather station for  hours). I followed the directions in the Wiki and 
>>>>> had 
>>>>> weewx recalculate the summaries without incident. I also deleted the June 
>>>>> NOAA report, which was properly re-created. I did look at that June NOAA 
>>>>> report which shows the correct min and max temperatures for each date, 
>>>>> while the Belchertown "Year" graph is off by one day for the June 
>>>>> temperature data. So none of what I did seems to me to be causal for a 
>>>>> Monthly graph to list today's data with a Y-axis of tomorrow. 
>>>>>
>>>>> I know that Pat is using code from Highcharts for these graphs but I 
>>>>> don't know if this is occurring in all Highcharts, only those in the 
>>>>> Belchertown skin, or only for me.
>>>>>
>>>>> Does anyone else see this? Where should I look to identify the cause? 
>>>>> Is there any other information I should post to help the group guide me?
>>>>>
>>>>> Phil
>>>>>
>>>>> -- 
>>>>> 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.
>>>>>
>>>> -- 
>>> 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.
>>>
>>

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

Re: [weewx-user] Values displayed by WeeWX skins from DarkSky API and moon phase calculations don't seem correct - Anyone else notice this?

[Philip Kutzenco]

Thomas,

Thanks for improving the fallback moon phase calculation for those who 
haven't installed pyephem. Happily, with the help of Gary, you, and others, 
I've done that.

Reading your post, though, I find it interesting that something as well 
studied and modeled as moon phases doesn't have a well accepted algorithm 
that can be applied. The different values provided by different web sites 
who offer the result of calculating it shows that lack. It makes you wonder 
about the accuracy of other astronomical calculations, often provided with 
many significant digits. It reminds us that precision doesn't guarantee 
accuracy!

Best,
Phil

On Monday, September 17, 2018 at 10:04:00 AM UTC-4, Thomas Keffer wrote:
>
> I've changed the formula used to calculate the moon phase if you have not 
> installed pyephem. For 15-Sept-2018, this version gives 37% illumination 
> (versus 24% for the old version).
>
> Interesting project. I learned a lot about lunations and how to calculate 
> the phases of the moon. The root problem is that the time between new moons 
> is not a constant value. So, as time marches on, the approximations get 
> worse and worse.
>
> This new version starts with the first new moon of 2018 (16-Jan-2018) and 
> calculates forward from that.
>
> Commit 0220656 
> <https://github.com/weewx/weewx/commit/0220656bc86785b51684d7eb20dfd3a991dee8f7>
>
> -tk
>
> On Sun, Sep 16, 2018 at 4:45 AM Philip Kutzenco  > wrote:
>
>> Gary,
>>
>> OK. It's working now! 
>>
>> Interestingly - "sudo pip uninstall ephem" and "sudo pip uninstall 
>> pyephem" gave not-installed errors. However, "pip uninstall ephem" and "pip 
>> uninstall pyephem" both did uninstalls. It appears that installing without 
>> privileges puts the files in /home/pi/.local/lib/python2.7/site-packages/ .
>> After uninstalling both, I installed pyephem with sudo, restarted weewx 
>> and now am showing 46% moon illumination on both the standard skin and the 
>> belchertown skin.
>>
>> Thanks for your (and everyone else's) help.
>>
>> Now if someone can help explain the inconsistency between the DarkSky API 
>> download and the DarkSky.net forecast for my location I'd be grateful. 
>> If I see no answer to that, I can move that question to a new topic. 
>>
>> Best,
>> Phil
>>
>> On Sunday, September 16, 2018 at 1:14:28 AM UTC-4, gjr80 wrote:
>>>
>>> On Sunday, 16 September 2018 12:39:53 UTC+10, Philip Kutzenco wrote:
>>>>
>>>>
>>>> Plus that doesn't explain why weewx is still indicating 24% on Standard 
>>>> and Belchertown skins for me.
>>>>
>>>>
>>> Let's deal with the second problem first. It appears that installing 
>>> ephem and pyephem as an unprivileged causes issues, particularly for 
>>> WeeWX (well it does on my Debian stretch VM). I would also be using 
>>> pyephem and not ephem. First off let's uninstall ephem and pyephem:
>>>
>>> $ sudo pip uninstall ephem
>>> $ sudo pip uninstall pyephem
>>>
>>> answer y to any y/n prompts
>>>
>>> Now install pyephem making sure you have privileges:
>>>
>>> $ sudo pip install pyephem
>>>
>>> and finally restart WeeWX:
>>>
>>> $ sudo systemctl restart weewx
>>>
>>> Wait for a report cycle to complete then check you pages again.
>>>
>>> Gary
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com .
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Values displayed by WeeWX skins from DarkSky API and moon phase calculations don't seem correct - Anyone else notice this?

[Philip Kutzenco]

Gary,

OK. It's working now! 

Interestingly - "sudo pip uninstall ephem" and "sudo pip uninstall pyephem" 
gave not-installed errors. However, "pip uninstall ephem" and "pip 
uninstall pyephem" both did uninstalls. It appears that installing without 
privileges puts the files in /home/pi/.local/lib/python2.7/site-packages/ .
After uninstalling both, I installed pyephem with sudo, restarted weewx and 
now am showing 46% moon illumination on both the standard skin and the 
belchertown skin.

Thanks for your (and everyone else's) help.

Now if someone can help explain the inconsistency between the DarkSky API 
download and the DarkSky.net forecast for my location I'd be grateful. If I 
see no answer to that, I can move that question to a new topic. 

Best,
Phil

On Sunday, September 16, 2018 at 1:14:28 AM UTC-4, gjr80 wrote:
>
> On Sunday, 16 September 2018 12:39:53 UTC+10, Philip Kutzenco wrote:
>>
>>
>> Plus that doesn't explain why weewx is still indicating 24% on Standard 
>> and Belchertown skins for me.
>>
>>
> Let's deal with the second problem first. It appears that installing ephem 
> and pyephem as an unprivileged causes issues, particularly for WeeWX 
> (well it does on my Debian stretch VM). I would also be using pyephem and 
> not ephem. First off let's uninstall ephem and pyephem:
>
> $ sudo pip uninstall ephem
> $ sudo pip uninstall pyephem
>
> answer y to any y/n prompts
>
> Now install pyephem making sure you have privileges:
>
> $ sudo pip install pyephem
>
> and finally restart WeeWX:
>
> $ sudo systemctl restart weewx
>
> Wait for a report cycle to complete then check you pages again.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Values displayed by WeeWX skins from DarkSky API and moon phase calculations don't seem correct - Anyone else notice this?

[Philip Kutzenco]

So just now, following your code I entered:

>>> import ephem
>>> moon = ephem.Moon()
>>> moon.compute()
>>> print moon.phase
*and got*
41.6761169434

When I enter:

>>> import datetime
>>> import ephem
>>> print(ephem.Moon(datetime.date.today()).moon_phase)
*now I get*
0.31187416036

That's too large a difference between midnight and the actual time.

I'm clearly confused or doing something wrong (or both).

Plus that doesn't explain why weewx is still indicating 24% on Standard and 
Belchertown skins for me.

Best,
Phil

On Saturday, September 15, 2018 at 7:53:44 PM UTC-4, gjr80 wrote:
>
> Likewise on the first part.
>
> Just now my pyephem enabled page shows 41%, a non-pyephem enabled VM shows 
> 34%, timeanddate.com shows 40.5%, best I could get from USNO is 41% but I 
> am not sure as of what time that is, it is just shown as a 'day' figure. 
> Pyephem gives me 40.5641403198% but that is using:
>
> >>> import ephem
> >>> moon = ephem.Moon()
> >>> moon.compute()
> >>> print moon.phase
> 40.5641403198
>
> Your pyephem code gives me
>
> >>> import ephem
> >>> print(ephem.Moon(datetime.date.today()).moon_phase)
> 0.408785965463
> >>> datetime.date.today()
> datetime.date(2018, 9, 16)
>
> but I suspect the variance there is because datetime.date.today() returns 
> a date with no time so I suspect that will mean pyephem returns the moon 
> phase at midnight today whereas ephem.Moon()  will cause the current time 
> to be used instead. 
>
> Might need to look into the non-pyephem page 34% value but all the others 
> seem completely consistent to me.
>
> Gary
>
> On Sunday, 16 September 2018 09:26:30 UTC+10, Thomas Keffer wrote:
>>
>> Can't help you with the first of your two questions.
>>
>> Regarding the second, when I look at my own skin 
>> <http://www.threefools.org/weewx/>, it shows 41% for today. Are you sure 
>> you're not looking at an old, perhaps cached, version?
>>
>> -tk
>>
>> On Sat, Sep 15, 2018 at 2:45 PM Philip Kutzenco  
>> wrote:
>>
>>> I've noticed that some information from the DarkSky API as well as 
>>> calculated moon phase don't seem to be correct or consistent with other 
>>> sources of data on WeeWX. Here's what I have seen:
>>>
>>> *DarkSky API* - I display a minimal 8 day forecast on the Belchertown 
>>> Skin. When I pull down the values using the SPI directly with my lat and 
>>> long, the values pulled down match what the skin shows. However, If I go to 
>>> DarkSky.net using the same location, the values (like min & max temp, 
>>> weather icon, precip probability etc.) are usually very different. I'm 
>>> pretty tuned into the weather right now as I live in Western North Carolina 
>>> and will be impacted by the remains of Florence over the next several days. 
>>> What's going on with the DarkSky API?
>>>
>>> *Moon phase* - WeeWX shows the moon phase for today to be a waxing 
>>> crescent - 24% (I think that means 24% visible or illuminated). When I do 
>>> the calculation using python's ephem module - 
>>> *print(ephem.Moon(datetime.date.today()).moon_phase)* - the answer I 
>>> get for moon phase is 31.19%. I thought that WeeWX used ephem for that 
>>> calculation. On timeanddate.com today's moon phase is 39.5%. At 
>>> http://aa.usno.navy.mil, 37% of the moon is illuminated today. Why such 
>>> a variation?
>>>
>>> These two items are vexing me. Can someone help explain these anomalies?
>>>
>>> Phil
>>>
>>> -- 
>>> 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.
>>>
>>

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

Re: [weewx-user] Values displayed by WeeWX skins from DarkSky API and moon phase calculations don't seem correct - Anyone else notice this?

[Philip Kutzenco]

I am also using MQTT realtime data - my Belchertown skin continues to show 
24%. The my Standard skin also shows 24% for me. As I'm in the US, I am 
using US for the units. As I mentioned earlier I ran pip install pyephem, 
then stopped and started weewx. 

Also, I'm running weewx on a Raspberry Pi Zero W. It's got the latest 
version of Raspbian and weewx 3.8.2.

For what it's worth I had previously installed ephem (not pyephem) with pip 
install ephem. I was obviously confused about the two (still am, I guess). 
But after Thomas said to install pyephem and you indicated success when 
doing that, I installed that package.

Best,
Phil

On Saturday, September 15, 2018 at 9:22:21 PM UTC-4, Colin Larsen wrote:
>
> Philip, interestingly although at one stage I did see the 34% value I 
> reported it then changed to the 24% that you have (and I did have) - not 
> sure what that's about.
>
> I did nothing other than installing, restarting Weewx and waiting an 
> archive period
>
> In terms of difference between your site and mine (both running 
> Belchertown skins) I have metric set and am using the mqtt real-time update 
> system. I have no idea if either of those is pertinent or if the Moon data 
> is even included in the real-time data.
>
> Cheers
> Colin
>
> On Sun, Sep 16, 2018 at 1:02 PM Philip Kutzenco  > wrote:
>
>> No joy for me. I must be doing something wrong. I installed pyephem (pip 
>> install pyephem). Then I stopped and started weewx. My standard and 
>> belchertown skins still show 24% even after waiting for a couple of archive 
>> intervals. Is there someplace I tell weewx to use pyephem? I did clear the 
>> cache on my browser to be sure it isn't that.
>>
>> Phil
>>
>> On Saturday, September 15, 2018 at 8:14:57 PM UTC-4, Thomas Keffer wrote:
>>>
>>> Yes, like Colin, you must not be using pyephem. As mentioned earlier in 
>>> this thread, I've created issue #342 
>>> <https://github.com/weewx/weewx/issues/342> to track this.
>>>
>>> In the meantime, try installing pyephem.
>>>
>>> -tk
>>>
>>> On Sat, Sep 15, 2018 at 5:11 PM Philip Kutzenco  
>>> wrote:
>>>
>>>> Thomas,
>>>>
>>>> Thanks for replying. My website isn't published externally, but I've 
>>>> attached a screenshot of part of the Standard skin display. I'm pretty 
>>>> sure 
>>>> it isn't cached. Also, take a look at Pat's 
>>>> http://www.belchertownweather.com website. Both my standard skin (as 
>>>> well as my implementation of the belchertown skin) and Pat's skin show 24% 
>>>> today.
>>>>
>>>> Phil
>>>>
>>>> On Saturday, September 15, 2018 at 7:26:30 PM UTC-4, Thomas Keffer 
>>>> wrote:
>>>>>
>>>>> Can't help you with the first of your two questions.
>>>>>
>>>>> Regarding the second, when I look at my own skin 
>>>>> <http://www.threefools.org/weewx/>, it shows 41% for today. Are you 
>>>>> sure you're not looking at an old, perhaps cached, version?
>>>>>
>>>>> -tk
>>>>>
>>>>> On Sat, Sep 15, 2018 at 2:45 PM Philip Kutzenco  
>>>>> wrote:
>>>>>
>>>>>> I've noticed that some information from the DarkSky API as well as 
>>>>>> calculated moon phase don't seem to be correct or consistent with other 
>>>>>> sources of data on WeeWX. Here's what I have seen:
>>>>>>
>>>>>> *DarkSky API* - I display a minimal 8 day forecast on the 
>>>>>> Belchertown Skin. When I pull down the values using the SPI directly 
>>>>>> with 
>>>>>> my lat and long, the values pulled down match what the skin shows. 
>>>>>> However, 
>>>>>> If I go to DarkSky.net using the same location, the values (like min 
>>>>>> & max temp, weather icon, precip probability etc.) are usually very 
>>>>>> different. I'm pretty tuned into the weather right now as I live in 
>>>>>> Western 
>>>>>> North Carolina and will be impacted by the remains of Florence over the 
>>>>>> next several days. What's going on with the DarkSky API?
>>>>>>
>>>>>> *Moon phase* - WeeWX shows the moon phase for today to be a waxing 
>>>>>> crescent - 24% (I think that means 24% visible or illuminated). When I 
>>>>>> do 
>>>>>> the calculation using python's ephem 

Re: [weewx-user] Values displayed by WeeWX skins from DarkSky API and moon phase calculations don't seem correct - Anyone else notice this?

[Philip Kutzenco]

No joy for me. I must be doing something wrong. I installed pyephem (pip 
install pyephem). Then I stopped and started weewx. My standard and 
belchertown skins still show 24% even after waiting for a couple of archive 
intervals. Is there someplace I tell weewx to use pyephem? I did clear the 
cache on my browser to be sure it isn't that.

Phil

On Saturday, September 15, 2018 at 8:14:57 PM UTC-4, Thomas Keffer wrote:
>
> Yes, like Colin, you must not be using pyephem. As mentioned earlier in 
> this thread, I've created issue #342 
> <https://github.com/weewx/weewx/issues/342> to track this.
>
> In the meantime, try installing pyephem.
>
> -tk
>
> On Sat, Sep 15, 2018 at 5:11 PM Philip Kutzenco  > wrote:
>
>> Thomas,
>>
>> Thanks for replying. My website isn't published externally, but I've 
>> attached a screenshot of part of the Standard skin display. I'm pretty sure 
>> it isn't cached. Also, take a look at Pat's 
>> http://www.belchertownweather.com website. Both my standard skin (as 
>> well as my implementation of the belchertown skin) and Pat's skin show 24% 
>> today.
>>
>> Phil
>>
>> On Saturday, September 15, 2018 at 7:26:30 PM UTC-4, Thomas Keffer wrote:
>>>
>>> Can't help you with the first of your two questions.
>>>
>>> Regarding the second, when I look at my own skin 
>>> <http://www.threefools.org/weewx/>, it shows 41% for today. Are you 
>>> sure you're not looking at an old, perhaps cached, version?
>>>
>>> -tk
>>>
>>> On Sat, Sep 15, 2018 at 2:45 PM Philip Kutzenco  
>>> wrote:
>>>
>>>> I've noticed that some information from the DarkSky API as well as 
>>>> calculated moon phase don't seem to be correct or consistent with other 
>>>> sources of data on WeeWX. Here's what I have seen:
>>>>
>>>> *DarkSky API* - I display a minimal 8 day forecast on the Belchertown 
>>>> Skin. When I pull down the values using the SPI directly with my lat and 
>>>> long, the values pulled down match what the skin shows. However, If I go 
>>>> to 
>>>> DarkSky.net using the same location, the values (like min & max temp, 
>>>> weather icon, precip probability etc.) are usually very different. I'm 
>>>> pretty tuned into the weather right now as I live in Western North 
>>>> Carolina 
>>>> and will be impacted by the remains of Florence over the next several 
>>>> days. 
>>>> What's going on with the DarkSky API?
>>>>
>>>> *Moon phase* - WeeWX shows the moon phase for today to be a waxing 
>>>> crescent - 24% (I think that means 24% visible or illuminated). When I do 
>>>> the calculation using python's ephem module - 
>>>> *print(ephem.Moon(datetime.date.today()).moon_phase)* - the answer I 
>>>> get for moon phase is 31.19%. I thought that WeeWX used ephem for that 
>>>> calculation. On timeanddate.com today's moon phase is 39.5%. At 
>>>> http://aa.usno.navy.mil, 37% of the moon is illuminated today. Why 
>>>> such a variation?
>>>>
>>>> These two items are vexing me. Can someone help explain these anomalies?
>>>>
>>>> Phil
>>>>
>>>> -- 
>>>> 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.
>>>>
>>> -- 
>> 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.
>>
>

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

[weewx-user] Values displayed by WeeWX skins from DarkSky API and moon phase calculations don't seem correct - Anyone else notice this?

[Philip Kutzenco]

I've noticed that some information from the DarkSky API as well as 
calculated moon phase don't seem to be correct or consistent with other 
sources of data on WeeWX. Here's what I have seen:

*DarkSky API* - I display a minimal 8 day forecast on the Belchertown Skin. 
When I pull down the values using the SPI directly with my lat and long, 
the values pulled down match what the skin shows. However, If I go to 
DarkSky.net using the same location, the values (like min & max temp, 
weather icon, precip probability etc.) are usually very different. I'm 
pretty tuned into the weather right now as I live in Western North Carolina 
and will be impacted by the remains of Florence over the next several days. 
What's going on with the DarkSky API?

*Moon phase* - WeeWX shows the moon phase for today to be a waxing crescent 
- 24% (I think that means 24% visible or illuminated). When I do the 
calculation using python's ephem module - 
*print(ephem.Moon(datetime.date.today()).moon_phase)* - the answer I get 
for moon phase is 31.19%. I thought that WeeWX used ephem for that 
calculation. On timeanddate.com today's moon phase is 39.5%. At 
http://aa.usno.navy.mil, 37% of the moon is illuminated today. Why such a 
variation?

These two items are vexing me. Can someone help explain these anomalies?

Phil

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

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

Strange. I now see your old skin on your website. When I last looked, I saw 
the Belchertown skin with wind data apparently shown properly.

I see you are using a WMR300 station. I know that Pat made some changes for 
the charts, at least where he was gathering windgust data instead of wind 
data to fix errors that others (including me) saw. I wonder if that is 
causing issues when you use the WMR300 driver to gather data. As I said 
earlier, I use the vantage driver to gather data from my Vantage Vue 
station.

On Tuesday, September 11, 2018 at 8:08:14 AM UTC-4, Juan Antonio Mosquera 
wrote:
>
> Now i have wind data because uninstall extension:
>
> http://www.meteomontaos.es/
>
>
> http://www.meteomontaos2.ga/ is for try... not updated.
>
> With belchertown extension enabled, not recieved Wind data... but... i wil 
> try again  for confirm.
>
> Greetings.
>
> El martes, 11 de septiembre de 2018, 14:03:40 (UTC+2), Philip Kutzenco 
> escribió:
>
> I am running version 0.7 with the vantage driver getting data from my 
> Davis Vantage Vue. My setup gets wind data. I looked at your web site and 
> you also seem to be getting wind data. I see a wind gust and wind charted 
> on the main page and wind data in the reports.
>
> What issue are you having with wind?
>
> On Tuesday, September 11, 2018 at 3:48:44 AM UTC-4, Juan Antonio Mosquera 
> wrote:
>
> I installed 0.7 version... all ok... but no data of Wind...
>
>
> http://www.meteomontaos2.ga/
>
> any problem?
>
> Thanks.
>
> El sábado, 8 de septiembre de 2018, 20:48:04 (UTC+2), Pat escribió:
>
> ...

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

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

I am running version 0.7 with the vantage driver getting data from my Davis 
Vantage Vue. My setup gets wind data. I looked at your web site and you 
also seem to be getting wind data. I see a wind gust and wind charted on 
the main page and wind data in the reports.

What issue are you having with wind?

On Tuesday, September 11, 2018 at 3:48:44 AM UTC-4, Juan Antonio Mosquera 
wrote:
>
> I installed 0.7 version... all ok... but no data of Wind...
>
>
> http://www.meteomontaos2.ga/
>
> any problem?
>
> Thanks.
>
> El sábado, 8 de septiembre de 2018, 20:48:04 (UTC+2), Pat escribió:
>
> To all who are subscribed, Belchertown skin 0.7 is out!
>
> *There are a lot of changes and an uninstall and re-install of the skin is 
> advised.* 
>
> This is due to the charts generator being split into it's own skin to 
> speed up generation time. The 2 skins are linked together and released as 1 
> skin. 
>
> *Be sure to have a backup of all your custom skin settings! *
>
> Read more details here: 
> https://github.com/poblabs/weewx-belchertown/releases/tag/weewx-belchertown-0.7
>
>
>
> On Saturday, September 8, 2018 at 1:58:23 PM UTC-4, Andrew Milner wrote:
>
> Why not create a skin to transfer only Belchertown yearly via FTP, and 
> remove yearly from other skins and then run wee_reports with just the 
> Belchertown ftp skin via cron once per day.
>
> ...

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

[weewx-user] Potential extension for Belchertown skin

[Philip Kutzenco]

Pat,
I am using your Belchertown skin to display data from a Davis Vantage Vue 
weather station. The Vantage Vue does not have a UV sensor, so the Charts 
feature of the Belchertown skin shows an empty chart for solar radiation.

I would like to replace the solar radiation chart and history with a chart 
of humidity and history. I assume that change would require a change to 
belchertown_highchartsSearchX.py. It appears that Gary's original 
highchartsSearchX.py does, in fact, include humidity data.

The most flexible solution would be to add humidity data to the 
belchertown_highcharts and set things up so that choices about which charts 
are included would be options in the [[EXTRAS]] part of weewx.conf for 
Belchertown. Things like calculated cloud base could also be an added 
option. Any chance you would be willing to do that? If not, could you point 
me to the way to what I would need to change in 
belchertown_highchartsSearchX.py (and any other scripts required) to 
replace solar radiation with humidity (I've done programming in the past, 
but never Python coding). I guess I could also try implementing the 
flexible solution of allowing choices in weewx.conf, though that may be 
beyond my abilities at this point.

I'm still working to implement MQTT updating on my Belchertown installation 
and will then publish my website externally.

Phil

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

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

Pat,

Gotcha. I'm disabling the highcharts portion. Will be glad to test any 
changes you make.

Best,
Phil

On Monday, September 3, 2018 at 8:46:44 PM UTC-4, Pat wrote:
>
> That's what looks like is going on. Your reports are stepping on each 
> other and the database is locked. 
>
> You can either disable the highcharts portion by setting highcharts_enabled 
> = 0 <https://github.com/poblabs/weewx-belchertown#general-options> in 
> options or disable the skin all together. I'm going to be tinkering around 
> with the chart generations this week. I'll keep you updated on anything 
> that needs some testing
>
>
> On Monday, September 3, 2018 at 8:04:07 PM UTC-4, Philip Kutzenco wrote:
>
> Pat
>
> It actually may be running a bit better now, though the Belchertown web 
> page update time is behind my SteelSeries web page. And both are behind my 
> archive period. I'm not using mqtt at this point. Just want to get this 
> running. 
>
> So maybe it's now just that report generation is extremely slow. I hope 
> there is a way to resolve that without buying a new box to run weewx on.
>
> It looks like it's taking about 575 seconds to generate the files for the 
> Belchertown report. I am also still seeing notes about report thread launch 
> being aborted as one is already running. My archive period is 300 seconds.
>
>
> Best,
> Phil
>
> On Monday, September 3, 2018 at 7:46:07 PM UTC-4, Philip Kutzenco wrote:
>
> Pat,
>
> I installed WeeWX with install.py. So everything lives underneath 
> /home/weewx/.
>
> I replaced the file in /Belchertown/records folder with the one you gave 
> me. Then I re-enabled the Belchertown skin in weewx.conf, restarted WeeWX 
> and ran wee_reports. Per the log extract below, after about 8 minutes, 
> weewx hung with the database locked. WeeWX automatically restarted 2 
> minutes later.
>
> In between my efforts to run Belchertown, I've been disabling the 
> Belchertown extension by commenting out the three lines in weewx.conf 
> starting with [[Belchertown]] and then stopping and then starting weewx 
> again. I re-enable it to test the next change.
>
> I wonder if locking the file is also the cause of the complaints that 
> header.html.tmpl doesn't exist in earlier efforts. I noticed that a 
> report thread couldn't be started as one was already running. Maybe that 
> running report thread locked the file as it (or something) locked the 
> archive database?
>
> Also, it seems that typing sudo /etc/init.d/weewx stop doesn't always stop 
> weewx when Belchertown is running. Even though I return to the prompt, when 
> I looked at ps, WeeWX was still running. I ended up rebooting once and 
> Killing the PID the last time.
>
> Will the Belchertown report generation time decrease after the initial run 
> through the database? Or will it take the same time each report generation 
> cycle?
>
> Thoughts? I saw a note on disabling the charts to speed things up, but I'd 
> really hate to do that.
>
> Best,
> Phil
>
> Sep  3 19:02:38 Weather-pi wee_reports[3281]: cheetahgenerator: Generated 
> 14 files for report StandardReport in 19.27 seconds
> Sep  3 19:02:51 Weather-pi systemd[1]: Started Session c7 of user pi.
> Sep  3 19:02:53 Weather-pi wee_reports[3281]: imagegenerator: Generated 24 
> images for StandardReport in 14.84 seconds
> Sep  3 19:02:53 Weather-pi wee_reports[3281]: copygenerator: copied 14 
> files to /home/weewx/public_html
> Sep  3 19:02:53 Weather-pi wee_reports[3281]: copygenerator: copied 6 
> files to /home/weewx/public_html/ss
> Sep  3 19:02:58 Weather-pi wee_reports[3281]: cheetahgenerator: Generated 
> 2 files for report SteelSeries in 4.53 seconds
> Sep  3 19:03:01 Weather-pi wee_reports[3281]: imagegenerator: Generated 11 
> images for SteelSeries in 3.43 seconds
> Sep  3 19:03:16 Weather-pi wee_reports[3281]: cheetahgenerator: Generated 
> 12 files for report forecast in 14.73 seconds
> Sep  3 19:03:16 Weather-pi wee_reports[3281]: copygenerator: copied 87 
> files to /home/weewx/public_html/forecast
> Sep  3 19:03:17 Weather-pi wee_reports[3281]: Belchertown Extension: 
> version 0.6
> Sep  3 19:05:15 Weather-pi weewx[3254]: manager: Added record 2018-09-03 
> 19:05:00 EDT (1536015900) to database 'weewx.sdb'
> Sep  3 19:05:15 Weather-pi weewx[3254]: manager: Added record 2018-09-03 
> 19:05:00 EDT (1536015900) to daily summary in 'weewx.sdb'
> Sep  3 19:05:56 Weather-pi weewx[3254]: cheetahgenerator: Generated 14 
> files for report StandardReport in 39.86 seconds
> Sep  3 19:06:03 Weather-pi weewx[3254]: imagegenerator: Generated 12 
> images for StandardReport in 7.67 seconds
> Sep  3 19:06:04 Weather-pi weewx[3254]: copygenerator: copied 14 files to 
> /h

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

Pat

It actually may be running a bit better now, though the Belchertown web 
page update time is behind my SteelSeries web page. And both are behind my 
archive period. I'm not using mqtt at this point. Just want to get this 
running. 

So maybe it's now just that report generation is extremely slow. I hope 
there is a way to resolve that without buying a new box to run weewx on.

It looks like it's taking about 575 seconds to generate the files for the 
Belchertown report. I am also still seeing notes about report thread launch 
being aborted as one is already running. My archive period is 300 seconds.


Best,
Phil

On Monday, September 3, 2018 at 7:46:07 PM UTC-4, Philip Kutzenco wrote:

> Pat,
>
> I installed WeeWX with install.py. So everything lives underneath 
> /home/weewx/.
>
> I replaced the file in /Belchertown/records folder with the one you gave 
> me. Then I re-enabled the Belchertown skin in weewx.conf, restarted WeeWX 
> and ran wee_reports. Per the log extract below, after about 8 minutes, 
> weewx hung with the database locked. WeeWX automatically restarted 2 
> minutes later.
>
> In between my efforts to run Belchertown, I've been disabling the 
> Belchertown extension by commenting out the three lines in weewx.conf 
> starting with [[Belchertown]] and then stopping and then starting weewx 
> again. I re-enable it to test the next change.
>
> I wonder if locking the file is also the cause of the complaints that 
> header.html.tmpl doesn't exist in earlier efforts. I noticed that a 
> report thread couldn't be started as one was already running. Maybe that 
> running report thread locked the file as it (or something) locked the 
> archive database?
>
> Also, it seems that typing sudo /etc/init.d/weewx stop doesn't always stop 
> weewx when Belchertown is running. Even though I return to the prompt, when 
> I looked at ps, WeeWX was still running. I ended up rebooting once and 
> Killing the PID the last time.
>
> Will the Belchertown report generation time decrease after the initial run 
> through the database? Or will it take the same time each report generation 
> cycle?
>
> Thoughts? I saw a note on disabling the charts to speed things up, but I'd 
> really hate to do that.
>
> Best,
> Phil
>
> Sep  3 19:02:38 Weather-pi wee_reports[3281]: cheetahgenerator: Generated 
> 14 files for report StandardReport in 19.27 seconds
> Sep  3 19:02:51 Weather-pi systemd[1]: Started Session c7 of user pi.
> Sep  3 19:02:53 Weather-pi wee_reports[3281]: imagegenerator: Generated 24 
> images for StandardReport in 14.84 seconds
> Sep  3 19:02:53 Weather-pi wee_reports[3281]: copygenerator: copied 14 
> files to /home/weewx/public_html
> Sep  3 19:02:53 Weather-pi wee_reports[3281]: copygenerator: copied 6 
> files to /home/weewx/public_html/ss
> Sep  3 19:02:58 Weather-pi wee_reports[3281]: cheetahgenerator: Generated 
> 2 files for report SteelSeries in 4.53 seconds
> Sep  3 19:03:01 Weather-pi wee_reports[3281]: imagegenerator: Generated 11 
> images for SteelSeries in 3.43 seconds
> Sep  3 19:03:16 Weather-pi wee_reports[3281]: cheetahgenerator: Generated 
> 12 files for report forecast in 14.73 seconds
> Sep  3 19:03:16 Weather-pi wee_reports[3281]: copygenerator: copied 87 
> files to /home/weewx/public_html/forecast
> Sep  3 19:03:17 Weather-pi wee_reports[3281]: Belchertown Extension: 
> version 0.6
> Sep  3 19:05:15 Weather-pi weewx[3254]: manager: Added record 2018-09-03 
> 19:05:00 EDT (1536015900) to database 'weewx.sdb'
> Sep  3 19:05:15 Weather-pi weewx[3254]: manager: Added record 2018-09-03 
> 19:05:00 EDT (1536015900) to daily summary in 'weewx.sdb'
> Sep  3 19:05:56 Weather-pi weewx[3254]: cheetahgenerator: Generated 14 
> files for report StandardReport in 39.86 seconds
> Sep  3 19:06:03 Weather-pi weewx[3254]: imagegenerator: Generated 12 
> images for StandardReport in 7.67 seconds
> Sep  3 19:06:04 Weather-pi weewx[3254]: copygenerator: copied 14 files to 
> /home/weewx/public_html
> Sep  3 19:06:04 Weather-pi weewx[3254]: copygenerator: copied 6 files to 
> /home/weewx/public_html/ss
> Sep  3 19:06:12 Weather-pi weewx[3254]: cheetahgenerator: Generated 2 
> files for report SteelSeries in 8.29 seconds
> Sep  3 19:06:19 Weather-pi weewx[3254]: imagegenerator: Generated 11 
> images for SteelSeries in 6.76 seconds
> Sep  3 19:06:49 Weather-pi weewx[3254]: cheetahgenerator: Generated 12 
> files for report forecast in 30.19 seconds
> Sep  3 19:06:50 Weather-pi weewx[3254]: copygenerator: copied 87 files to 
> /home/weewx/public_html/forecast
> Sep  3 19:06:50 Weather-pi weewx[3254]: Belchertown Extension: version 0.6
> Sep  3 19:09:01 Weather-pi CRON[3321]: (root) CMD (  [ -x 
> /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/syst

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

estx: CWOP: Posting not enabled.
Sep  3 19:12:30 Weather-pi weewx[3254]: restx: WOW: Posting not enabled.
Sep  3 19:12:30 Weather-pi weewx[3254]: restx: AWEKAS: Posting not enabled.
Sep  3 19:12:30 Weather-pi weewx[3254]: engine: Starting up weewx version 
3.8.2
Sep  3 19:12:30 Weather-pi weewx[3254]: engine: Clock error is -0.69 
seconds (positive is fast)
Sep  3 19:12:30 Weather-pi weewx[3254]: manager: Added record 2018-09-03 
19:10:00 EDT (1536016200) to database 'weewx.sdb'
Sep  3 19:12:31 Weather-pi weewx[3254]: manager: Added record 2018-09-03 
19:10:00 EDT (1536016200) to daily summary in 'weewx.sdb'
Sep  3 19:12:31 Weather-pi weewx[3254]: engine: Starting main packet loop.
Sep  3 19:12:31 Weather-pi weewx[3254]: forecast: ZambrettiThread: 
Zambretti: generated 1 forecast record
Sep  3 19:12:31 Weather-pi weewx[3254]: forecast: ZambrettiThread: 
Zambretti: saved 1 forecast records
Sep  3 19:12:31 Weather-pi weewx[3254]: forecast: ZambrettiThread: 
Zambretti: deleted forecasts prior to 1535411551
Sep  3 19:15:15 Weather-pi weewx[3254]: manager: Added record 2018-09-03 
19:15:00 EDT (1536016500) to database 'weewx.sdb'
Sep  3 19:15:15 Weather-pi weewx[3254]: manager: Added record 2018-09-03 
19:15:00 EDT (1536016500) to daily summary in 'weewx.sdb'
Sep  3 19:15:22 Weather-pi weewx[3254]: cheetahgenerator: Generated 14 
files for report StandardReport in 6.59 seconds
Sep  3 19:15:25 Weather-pi weewx[3254]: imagegenerator: Generated 12 images 
for StandardReport in 3.52 seconds
Sep  3 19:15:25 Weather-pi weewx[3254]: copygenerator: copied 14 files to 
/home/weewx/public_html
Sep  3 19:15:26 Weather-pi weewx[3254]: copygenerator: copied 6 files to 
/home/weewx/public_html/ss
Sep  3 19:15:26 Weather-pi weewx[3254]: cheetahgenerator: Generated 2 files 
for report SteelSeries in 0.59 seconds
Sep  3 19:15:29 Weather-pi weewx[3254]: imagegenerator: Generated 11 images 
for SteelSeries in 3.25 seconds
Sep  3 19:15:31 Weather-pi weewx[3254]: cheetahgenerator: Generated 12 
files for report forecast in 1.56 seconds
Sep  3 19:15:31 Weather-pi weewx[3254]: copygenerator: copied 87 files to 
/home/weewx/public_html/forecast
Sep  3 19:17:01 Weather-pi CRON[3382]: (root) CMD (   cd / && run-parts 
--report /etc/cron.hourly)
Sep  3 19:18:08 Weather-pi systemd[1]: Started Session c8 of user pi.


On Monday, September 3, 2018 at 6:03:13 PM UTC-4, Pat wrote:
>
> Thanks! It's my day off work, so in between my daughter's naps I've been 
> able to get a few things done :)
>
> The station hardware shouldn't matter since it's weewx that is doing the 
> middle-man work to make them all speak the same language in the skin files. 
>
> My archive is 261,459 records (not on a Pi) but it shouldn't matter either 
> way. The Pi might take a while longer to process those 106,000 records - 
> which is why you see 571.39 seconds. 
>
> I'm not sure why it's said your header.html.tmpl is missing. I wonder if 
> there's something else going on and that's just an effect of it.
>
> How did you install? Using apt or using setup.py? 
>
> There are 4 places .wind is used on the records page. Let's try this out. 
> Take this attached file, and copy it to the skins/Belchertown/records 
> folder overwriting the one there. Then run sudo wee_reports and see if it 
> helps?
>
>
>
> On Monday, September 3, 2018 at 5:51:29 PM UTC-4, Philip Kutzenco wrote:
>
> Pat,
>
> I tried David's fix and get the errors below. Maybe something different 
> for me? I'm using a Davis Vantage Vue.
>
> Regarding your question:
> 2. How did you install the skin? header.html.tmpl should be in 
> skins/Belchertown.  - *I used sudo wee_extension --install. I checked and 
> header.html.tmpl is, indeed in skins/Belchertown*
>
> You should know that my archive database has about 106,000 records. I 
> wouldn't think that's particularly large. Also, I am running weewx on a Pi 
> Zero W. So, it's a pretty weak system processing-wise.
>
> You're really multi-tasking today - I see lots of posts from you. You're 
> supposed to be enjoying Labor Day, not laboring on it :-).
> I owe you coffee. Will do that!
>
> Looking forward to your guidance.
>
> Best,
> Phil
>
> Sep  3 15:46:02 Weather-pi weewx[1669]: Belchertown Extension: version 0.6
> Sep  3 15:50:15 Weather-pi weewx[1669]: manager: Added record 2018-09-03 
> 15:50:00 EDT (1536004200) to database 'weewx.sdb'
> Sep  3 15:50:15 Weather-pi weewx[1669]: manager: Added record 2018-09-03 
> 15:50:00 EDT (1536004200) to daily summary in 'weewx.sdb'
> Sep  3 15:50:15 Weather-pi weewx[1669]: engine: Launch of report thread 
> aborted: existing report thread still running
> Sep  3 15:53:35 Weather-pi weewx[1669]: cheetahgenerator: Generate failed 
> with exception ''
> Sep  3 15:53:35 Weather-pi weewx[1669]: cheetahgenerator:  Ignoring 
> template /home/we

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

qsc/k6ErSz6sAgAJ> The 
> file you want to change is in skins/Belchertown/records/index.html.tmpl
>
> 2. How did you install the skin? header.html.tmpl should be in 
> skins/Belchertown. 
>
> 3. This is a sort-of known issue and no real fix at this time. Has to do 
> with archive interval, database size, and length of time it takes to 
> generate the graphs. Gary is the original author of the highcharts 
> extension, which I've extended and re-packaged with the skin. I've been 
> thinking about ways to optimize it, and I believe he is too.
>
>
>
> On Monday, September 3, 2018 at 12:17:23 PM UTC-4, Philip Kutzenco wrote:
>
> Pat,
>
> OK. I'm making progress. I put in about.inc and records.inc files.
>
> Now I am seeing a number of errors. Syslog output with debug=1 is 
> attached. 
>
> 1. First it says I'm getting errors from the Cheetahgenerator saying that 
> it is ignoring index.html.tmpl in the Belchertown records directory because 
> no column called wind exists.
> 2. Later errors say it is ignoring index.html.tmpl because 
> /home/weewx/skins/Standard/header.html.tmpl doesn't exist.
> 3. Finally report generation is exceeding my 5 minute archive time and I 
> get errors saying report thread not start because of an existing one. 
>
> Regarding 3. I remember reading something about excessive report time in 
> the thread on weewx-user, but couldn't find the particular post just now.
>
> I hope you can point me in the right direction. I did get one web page 
> generated that looked nice, but it didn't get updated.
>
> Phil
>
>
>
> On Monday, September 3, 2018 at 7:30:42 AM UTC-4, Pat wrote:
>
> Hi Phil, 
>
> Your post actually made me update the readme to be a little more clearer 
> :) 
>
> T 
> <https://github.com/poblabs/weewx-belchertown/blob/master/skins/Belchertown/about.inc>here
>  
> are about.inc 
> <https://github.com/poblabs/weewx-belchertown/blob/master/skins/Belchertown/about.inc>
>  
> and records.inc 
> <https://github.com/poblabs/weewx-belchertown/blob/master/skins/Belchertown/records.inc>
>  
> samples in the GitHub. I'll update the readme with those l
>
> ...

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

Re: [weewx-user] Re: Belchertown skin for weewx now available!

[Philip Kutzenco]

Pat,

OK. I'm making progress. I put in about.inc and records.inc files.

Now I am seeing a number of errors. Syslog output with debug=1 is attached. 

1. First it says I'm getting errors from the Cheetahgenerator saying that 
it is ignoring index.html.tmpl in the Belchertown records directory because 
no column called wind exists.
2. Later errors say it is ignoring index.html.tmpl because 
/home/weewx/skins/Standard/header.html.tmpl doesn't exist.
3. Finally report generation is exceeding my 5 minute archive time and I 
get errors saying report thread not start because of an existing one. 

Regarding 3. I remember reading something about excessive report time in 
the thread on weewx-user, but couldn't find the particular post just now.

I hope you can point me in the right direction. I did get one web page 
generated that looked nice, but it didn't get updated.

Phil



On Monday, September 3, 2018 at 7:30:42 AM UTC-4, Pat wrote:
>
> Hi Phil, 
>
> Your post actually made me update the readme to be a little more clearer 
> :) 
>
> T 
> <https://github.com/poblabs/weewx-belchertown/blob/master/skins/Belchertown/about.inc>here
>  
> are about.inc 
> <https://github.com/poblabs/weewx-belchertown/blob/master/skins/Belchertown/about.inc>
>  
> and records.inc 
> <https://github.com/poblabs/weewx-belchertown/blob/master/skins/Belchertown/records.inc>
>  
> samples in the GitHub. I'll update the readme with those links for future 
> reference. 
>
> Sadly, the installer seems basic at this point in time where it'll 
> overwrite everything you have listed to install. So this was a work-around 
> for the time being. 
>
>
> On Sunday, September 2, 2018 at 9:47:49 PM UTC-4, Philip Kutzenco wrote:
>
> Pat,
> Ah. When I downloaded the skin from GitHub this afternoon (US Eastern 
> time), I also printed out a copy of the README.md. It's listed as being 
> created 3 days ago. That version has a section called "Customizing About 
> Page and Records Page" which says create (or edit) the about.inc and 
> records.inc files.
>
> It looks like I printed that shortly before you updated it :-). The 
> section in the new version is called "Creating About Page and Records Page" 
> and has a line that says in version 0.6+ you need to create these files if 
> you are installing the skin for the first time.
>
> I'll create those files. BTW, I know you suggest looking at 
> www.BelchertownWeather.com for examples of what they can contain. You may 
> want to post starter files on GitHub, though, for those just starting out 
> to download and use.
>
> Thanks.
> Phil
>
> On Sunday, September 2, 2018 at 7:30:21 PM UTC-4, Pat wrote:
>
> Looks like you may have skipped this step 
> <https://github.com/poblabs/weewx-belchertown#customizing-about-page-and-records-page>
> .
>
> On Sunday, September 2, 2018 at 5:05:54 PM UTC-4, Philip Kutzenco wrote:
>
> Pat,
>
> I finally got a chance to install your skin (V 0.6). And I'm seeing 
> errors: What have I done wrong?
>
> Phil
>
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: manager: Added record 2018-09-02 
> 16:35:00 EDT (1535920500) to database 'weewx.sdb'
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: manager: Added record 2018-09-02 
> 16:35:00 EDT (1535920500) to daily summary in 'weewx.sdb'
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: manager: Added record 2018-09-02 
> 16:40:00 EDT (1535920800) to database 'weewx.sdb'
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: forecast: ZambrettiThread: 
> Zambretti: generated 1 forecast record
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: forecast: ZambrettiThread: 
> Zambretti: saved 1 forecast records
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: forecast: ZambrettiThread: 
> Zambretti: deleted forecasts prior to 1535316382
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: manager: Added record 2018-09-02 
> 16:40:00 EDT (1535920800) to daily summary in 'weewx.sdb'
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: manager: Added record 2018-09-02 
> 16:45:00 EDT (1535921100) to database 'weewx.sdb'
> Sep  2 16:46:22 WeeWX-pi weewx[24513]: manager: Added record 2018-09-02 
> 16:45:00 EDT
>
> ...

-- 
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.
For more options, visit https://groups.google.com/d/optout.
Sep  3 10:47:18 WeeWX-pi weewx[413]: engine: Using configuration file 
/home/weewx/weewx.conf
Sep  3 10:47:18 WeeWX-pi weewx[413]: engine: Debug is 1
Sep  3 10:47:18 WeeWX-pi weewx[413]: engine: Initializing engine
Sep  3 10:47:18 WeeWX-pi weewx[413]: engine: Loading station type Vantage 
(weewx.drivers.vantage)
Sep  3 10:47:18 WeeWX-pi dh