[weewx-user] Re: Recurrence of unique constraint issues - Weewx 4.3.0, HP1000

[icoj...@gmail.com]

Thanks Susan, sent a PM

On Wednesday, 19 January 2022 at 01:42:10 UTC vk3...@gmail.com wrote:

> The folks that know the WeeWx code better than I may have other ideas but 
> what I do is to use your favourite SQLLite database tool to delete from 
> where the duplications start (1612865736 in your case) to the end and then 
> delete and rebuild the daily summary records.
> What the HP1000 driver does is to ask WeeWx for the date of the last 
> record and then checks with the console for any records that are *after* 
> that date and treats those as 'historic' records.
> Can you look at the database and see if there are records (possibly with 
> dateTime values that don't seem to follow the general trend - for example 
> nearly all of mine end in '0') that might be causing the issue.
> Also can you please provide the traceback for the error, not just the 
> error itself. I'd like to see where the error is originating in the driver 
> source file.
> Susan
>
> On Tuesday, 18 January 2022 at 7:56:56 pm UTC+11 icoj...@gmail.com wrote:
>
>> Hi All,
>>
>> I'm seeing a recurrence of catastrophic failures with my setup that I 
>> last saw around this time last year.
>>
>> There are numerous unique constraint errors that appear to be due to the 
>> HP1000 trying to insert historical data when there is already data there.  
>> This results in reports and data never being updated and showing as offline.
>>
>> Jan 18 08:40:15 weatherpi weewx[1780] ERROR weewx.manager: Unable to add 
>> record 2021-02-09 10:15:36 GMT (1612865736) to database 'weewx.sdb': UNIQUE 
>> constraint failed: archive.dateTime
>>
>> The solution I used last year was to do a full clean install.  I'd rather 
>> not go down that path this year as I've reconfigured weewx to the simulator 
>> and all is well.  So that suggests the issue is with the HP1000 driver.  I 
>> reinstalled the driver but still see the same issue.
>>
>> My next guess would be to uninstall the driver but I don't know how to do 
>> that.
>>
>> My original post is here 
>> 
>>
>> Any guidance would be very much appreciated.
>>
>> Thank you,
>>
>> Matt
>>
>

-- 
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/9c02ffe8-8ab5-41a1-9702-4b3fafc1956an%40googlegroups.com.

Re: [weewx-user] Disable database and reports?

[Tom Keffer]

Disabling archive_services will disable writes to the database, but it will
also prevent archive records from being generated.

On Tue, Jan 18, 2022 at 6:13 PM DrTron  wrote:

> Thanks!
> Disabling the report_services definitively stops the write into
> /var/www/html.
> Additionally, I found that disabling archive_services disables writes to
> the database. So exactly what I wanted.
>
> On Tuesday, January 18, 2022 at 7:08:48 PM UTC-6 tke...@gmail.com wrote:
>
>> Disabling report generation is simple enough: simply
>> remove weewx.engine.StdReport from the option report_services
>> .
>>
>> However, the database is pretty integral to the running of the engine,
>> and cannot be easily disabled. Just use the sqlite database and ignore it.
>>
>> On Tue, Jan 18, 2022 at 4:58 PM DrTron  wrote:
>>
>>> All,
>>> As probably many here do, I intend to use weewx not to display weather
>>> data on a webserver, but just to collect data from a weather station and
>>> feed the data into an existing database. That is working now, at least with
>>> the Simulator.
>>> So the whole sqlite database, archive, report generation etc. are not
>>> needed.
>>>
>>> Is there a way to disable these services without digging too deep into
>>> the python scripts?
>>>
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/1ade102c-5937-4357-8bab-e5621ce78e4en%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/26794405-70b7-431d-9833-12a07c8830fbn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEAi8j0zktjdKW%2BK77n1B7urHrnn6Q-y0_TS8vhHZNgA7w%40mail.gmail.com.

Re: [weewx-user] Is there a way to force a fresh upload of all HTML files?

[Jo Hunter]

Ah brilliant, that worked a treat.
Thank you!

Jo

On Tuesday, January 18, 2022 at 5:11:40 PM UTC-6 tke...@gmail.com wrote:

> Yes, that's possible. Remove the file #FTP.last from either 
> /home/weewx/public_html or /var/www/html, depending on how you installed 
> WeeWX.
>
> On Tue, Jan 18, 2022 at 2:57 PM Jo Hunter  wrote:
>
>> Hi,
>>
>> I'm trying to get the FTP upload working and it's basically there, but I 
>> would like Weewx to upload everything from scratch; it's currently missing 
>> the older month/year files and the CSS, amongst other things.
>> I could manually copy them all over, but can it be forced to do all of it?
>>
>> Thanks,
>> Jo
>>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/bd723544-dd2b-4803-8a43-5c6f642ec8abn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/1c887268-e8e3-47ea-807d-00f02f178b36n%40googlegroups.com.

Re: [weewx-user] Re: Chill Hours Extension

[Chuck Rhode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 18 Jan 2022 17:05:33 -0800
Tom Deffer  wrote:

> Upon reflection, the biggest difference seems to be that
> cooling-degree days are weighted by the temperature difference from
> the baseline. You just want the total number of hours.

> This is best done as an XTypes extension
> .

I've fooled around with XTypes for my Phenology extension.

* [weewx-phenology](HTTP://LacusVeris.com/Phenology) — Growing
  Degree-Days development models for various insect pests, showing
  when to apply control strategies to minimize crop damage.

The Growing Degree-Days calculation(s) are compute-intensive relative
to the Cooling Degree-Days calculation.  XTypes exposes three entry
points that return values: scalar, series, and aggregate.  I implement
only the "series" entry point, and I keep a running tally of
cumulative Degree-Days.  It seems that, if I had implemented
"aggregate," each cumulative step would have meant recalculating
previous steps at factorial cost, but that's just me.

I agree the Chilling Hours calculations seem relatively simple, but
never let it be said that researchers in the Life Sciences can leave
any particularly elegant concept uncluttered.  Here is a more or less
grammatical overview of various kinds of Chilling Hours calculations.
You may overlook the Climate Change hysteria at the end.  The Utah
method obviously requires quite a few machine cycles, but matching the
Queensland method's curve might require quite a few more.

* [Chill Hours and Fruit
  Trees](https://practicalprimate.com/chill-hours/) — Many deciduous
  fruit trees will not give you the fruit yields you want unless your
  property receives adequate chill hours. But what are chill hours and
  why are they so important?

... so both Chill Hours and Growing Degree-Days potentially challenge
WeeWX's data collection, calculation, reporting, and image generation
capabilities.  I developed a kludge to handle Growing Degree-Days
because treating orchard insects and disease is a season-to-season
battle and many treatments depend on such calculations.  I am not so
interested in Chill Hours because that has more to do with orchard
siting and choice of cultivars, which tend to be one-off decisions.
However, Chill Hours (in whatever manifestation) does keep coming up
here and on the other discussion group I frequent.  Perhaps this is
due to ongoing Climate-Change concerns.

* [Growing Fruit](https://growingfruit.org/search?q=chill%20hours)

I wonder whether I have gone down the right chute with the Phenology
Extension's Growing Degree-Days calculation and imaging capacity.
Does adding Chill Hours call for a more general approach?

I sadly fear the appetite for reporting Chill Hours does not
necessarily imply the desire or ability to configure WeeWX to do the
appropriate calculations or interpret the results.  These are not
straightforward things.

- -- 
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather:  http://LacusVeris.com/WX
.. 15° — Wind WNW 22 mph — Sky mostly clear.

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCYegsMQAKCRBg2/xipKOW
UuoSAJ4kvvWrCWqDkEZ8tl2yDzAPXU3LnQCeO5z01CamBSnFAr677iJNzwgf15U=
=aptL
-END PGP SIGNATURE-

-- 
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/20220119091910.5661af6a%40wealthy.

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

[morr...@gmail.com]

On Wednesday, January 19, 2022 at 12:42:04 a.m. UTC-4 Cameron D wrote:

>
>- as you get closer to the equator, tidal changes dominate the 
>baseline in that timescale - I tried higher order polynomials, but they 
> are 
>next to useless.
>
> I also had little luck with higher order polynomials to remove the general 
trend.

I've put the script here: https://github.com/morrowwm/weewx_tonga_browse

-- 
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/4f1993c1-e300-47d4-9ebc-cb2a43128d0bn%40googlegroups.com.

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Your Phenology extension is actually what got me thinking about how to 
implement the chilling hours in a more generic way, such that more than one 
metric (or one set of temperature thresholds) can be used. 

The "simplest" way that came to mind was using some sort of modified Daily 
Summary table in the database. I haven't yet figured out how WeeWX 
populates those tables, but if the columns and calculation methods are 
customizable, then the daily (or nightly) data could be compiled at the end 
of the day and loaded into the table. That way every time you want to 
display the information, it's just a straight query from that summary 
table, rather than running the calculations every time for every archive 
entry. This also allows for multiple calculation methods, all stored in the 
summary table. 

So as an example, at the end of the day, whenever WeeWX normally populates 
the summary tables, this new extension could run multiple algorithms (one 
for basic chill hours, one for the Utah Model, one for the phenology table 
on your website, etc) and store the resultant value in the respective 
column (one for Utah, one for basic, one for phenology, etc) in the new 
daily summary row for this extension. No new specific types are required in 
the loop or archive packets, so the processing power is only required once 
per day. When the data is viewed, it is only pulling values from a table 
rather than doing the calculations each time.

But I'm not sure such customizations to the daily-table-creation-process is 
possible. 

Thoughts?






On Wednesday, January 19, 2022 at 9:20:30 AM UTC-6 charlescu...@gmail.com 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 18 Jan 2022 17:05:33 -0800
> Tom Deffer  wrote:
>
> > Upon reflection, the biggest difference seems to be that
> > cooling-degree days are weighted by the temperature difference from
> > the baseline. You just want the total number of hours.
>
> > This is best done as an XTypes extension
> > .
>
> I've fooled around with XTypes for my Phenology extension.
>
> * [weewx-phenology](HTTP://LacusVeris.com/Phenology) — Growing
> Degree-Days development models for various insect pests, showing
> when to apply control strategies to minimize crop damage.
>
> The Growing Degree-Days calculation(s) are compute-intensive relative
> to the Cooling Degree-Days calculation. XTypes exposes three entry
> points that return values: scalar, series, and aggregate. I implement
> only the "series" entry point, and I keep a running tally of
> cumulative Degree-Days. It seems that, if I had implemented
> "aggregate," each cumulative step would have meant recalculating
> previous steps at factorial cost, but that's just me.
>
> I agree the Chilling Hours calculations seem relatively simple, but
> never let it be said that researchers in the Life Sciences can leave
> any particularly elegant concept uncluttered. Here is a more or less
> grammatical overview of various kinds of Chilling Hours calculations.
> You may overlook the Climate Change hysteria at the end. The Utah
> method obviously requires quite a few machine cycles, but matching the
> Queensland method's curve might require quite a few more.
>
> * [Chill Hours and Fruit
> Trees](https://practicalprimate.com/chill-hours/) — Many deciduous
> fruit trees will not give you the fruit yields you want unless your
> property receives adequate chill hours. But what are chill hours and
> why are they so important?
>
> ... so both Chill Hours and Growing Degree-Days potentially challenge
> WeeWX's data collection, calculation, reporting, and image generation
> capabilities. I developed a kludge to handle Growing Degree-Days
> because treating orchard insects and disease is a season-to-season
> battle and many treatments depend on such calculations. I am not so
> interested in Chill Hours because that has more to do with orchard
> siting and choice of cultivars, which tend to be one-off decisions.
> However, Chill Hours (in whatever manifestation) does keep coming up
> here and on the other discussion group I frequent. Perhaps this is
> due to ongoing Climate-Change concerns.
>
> * [Growing Fruit](https://growingfruit.org/search?q=chill%20hours)
>
> I wonder whether I have gone down the right chute with the Phenology
> Extension's Growing Degree-Days calculation and imaging capacity.
> Does adding Chill Hours call for a more general approach?
>
> I sadly fear the appetite for reporting Chill Hours does not
> necessarily imply the desire or ability to configure WeeWX to do the
> appropriate calculations or interpret the results. These are not
> straightforward things.
>
> - -- 
> .. Be Seeing You,
> .. Chuck Rhode, Sheboygan, WI, USA
> .. Weather: http://LacusVeris.com/WX
> .. 15° — Wind WNW 22 mph — Sky mostly clear.
>
> -BEGIN PGP SIGNATURE-
>
> iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCYegsMQAKCRBg2/xipKOW
> UuoSAJ4kvvWrCWqDkEZ8tl2yDzAPXU3LnQCeO5z01CamBSnFAr677iJNzwgf15U=
> =aptL
> -END PGP S

Re: [weewx-user] Re: Chill Hours Extension

[Tom Keffer]

"Premature optimization is the root of all evil."

Your proposal sounds complicated and incompatible with the existing daily
summaries. You would have to replicate a lot of what it already does.

Make it work first, then worry about making it fast. You don't know yet
whether the calculation will take a long time.



On Wed, Jan 19, 2022 at 9:38 AM Seth Ratner  wrote:

> Your Phenology extension is actually what got me thinking about how to
> implement the chilling hours in a more generic way, such that more than one
> metric (or one set of temperature thresholds) can be used.
>
> The "simplest" way that came to mind was using some sort of modified Daily
> Summary table in the database. I haven't yet figured out how WeeWX
> populates those tables, but if the columns and calculation methods are
> customizable, then the daily (or nightly) data could be compiled at the end
> of the day and loaded into the table. That way every time you want to
> display the information, it's just a straight query from that summary
> table, rather than running the calculations every time for every archive
> entry. This also allows for multiple calculation methods, all stored in the
> summary table.
>
> So as an example, at the end of the day, whenever WeeWX normally populates
> the summary tables, this new extension could run multiple algorithms (one
> for basic chill hours, one for the Utah Model, one for the phenology table
> on your website, etc) and store the resultant value in the respective
> column (one for Utah, one for basic, one for phenology, etc) in the new
> daily summary row for this extension. No new specific types are required in
> the loop or archive packets, so the processing power is only required once
> per day. When the data is viewed, it is only pulling values from a table
> rather than doing the calculations each time.
>
> But I'm not sure such customizations to the daily-table-creation-process
> is possible.
>
> Thoughts?
>
>
>
>
>
>
> On Wednesday, January 19, 2022 at 9:20:30 AM UTC-6 charlescu...@gmail.com
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Tue, 18 Jan 2022 17:05:33 -0800
>> Tom Deffer  wrote:
>>
>> > Upon reflection, the biggest difference seems to be that
>> > cooling-degree days are weighted by the temperature difference from
>> > the baseline. You just want the total number of hours.
>>
>> > This is best done as an XTypes extension
>> > .
>>
>> I've fooled around with XTypes for my Phenology extension.
>>
>> * [weewx-phenology](HTTP://LacusVeris.com/Phenology) — Growing
>> Degree-Days development models for various insect pests, showing
>> when to apply control strategies to minimize crop damage.
>>
>> The Growing Degree-Days calculation(s) are compute-intensive relative
>> to the Cooling Degree-Days calculation. XTypes exposes three entry
>> points that return values: scalar, series, and aggregate. I implement
>> only the "series" entry point, and I keep a running tally of
>> cumulative Degree-Days. It seems that, if I had implemented
>> "aggregate," each cumulative step would have meant recalculating
>> previous steps at factorial cost, but that's just me.
>>
>> I agree the Chilling Hours calculations seem relatively simple, but
>> never let it be said that researchers in the Life Sciences can leave
>> any particularly elegant concept uncluttered. Here is a more or less
>> grammatical overview of various kinds of Chilling Hours calculations.
>> You may overlook the Climate Change hysteria at the end. The Utah
>> method obviously requires quite a few machine cycles, but matching the
>> Queensland method's curve might require quite a few more.
>>
>> * [Chill Hours and Fruit
>> Trees](https://practicalprimate.com/chill-hours/) — Many deciduous
>> fruit trees will not give you the fruit yields you want unless your
>> property receives adequate chill hours. But what are chill hours and
>> why are they so important?
>>
>> ... so both Chill Hours and Growing Degree-Days potentially challenge
>> WeeWX's data collection, calculation, reporting, and image generation
>> capabilities. I developed a kludge to handle Growing Degree-Days
>> because treating orchard insects and disease is a season-to-season
>> battle and many treatments depend on such calculations. I am not so
>> interested in Chill Hours because that has more to do with orchard
>> siting and choice of cultivars, which tend to be one-off decisions.
>> However, Chill Hours (in whatever manifestation) does keep coming up
>> here and on the other discussion group I frequent. Perhaps this is
>> due to ongoing Climate-Change concerns.
>>
>> * [Growing Fruit](https://growingfruit.org/search?q=chill%20hours)
>>
>> I wonder whether I have gone down the right chute with the Phenology
>> Extension's Growing Degree-Days calculation and imaging capacity.
>> Does adding Chill Hours call for a more general approach?
>>
>> I sadly fear the appetite for reporting Chill Hours does not
>> necessarily imply the desire or abilit

Re: [weewx-user] Disable database and reports?

[DrTron]

That's entirely possible. But as I only need to feed data in realtime from 
my sensors to my (influx) database, that is totally acceptable for me.

On Wednesday, January 19, 2022 at 6:12:17 AM UTC-6 tke...@gmail.com wrote:

> Disabling archive_services will disable writes to the database, but it 
> will also prevent archive records from being generated.
>
> On Tue, Jan 18, 2022 at 6:13 PM DrTron  wrote:
>
>> Thanks!
>> Disabling the report_services definitively stops the write into 
>> /var/www/html.
>> Additionally, I found that disabling archive_services disables writes to 
>> the database. So exactly what I wanted.
>>
>> On Tuesday, January 18, 2022 at 7:08:48 PM UTC-6 tke...@gmail.com wrote:
>>
>>> Disabling report generation is simple enough: simply 
>>> remove weewx.engine.StdReport from the option report_services 
>>> .
>>>
>>> However, the database is pretty integral to the running of the engine, 
>>> and cannot be easily disabled. Just use the sqlite database and ignore it.
>>>
>>> On Tue, Jan 18, 2022 at 4:58 PM DrTron  wrote:
>>>
 All,
 As probably many here do, I intend to use weewx not to display weather 
 data on a webserver, but just to collect data from a weather station and 
 feed the data into an existing database. That is working now, at least 
 with 
 the Simulator.
 So the whole sqlite database, archive, report generation etc. are not 
 needed.

 Is there a way to disable these services without digging too deep into 
 the python scripts?

 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.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/1ade102c-5937-4357-8bab-e5621ce78e4en%40googlegroups.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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/26794405-70b7-431d-9833-12a07c8830fbn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/cb43c07f-85c3-4cd9-8739-8fa91b6bee54n%40googlegroups.com.

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Yeah, That's what it looks like

For something simple it will work perfectly. If a make an xtype for 
chillHours that works like the ET type, except use either the Utah model 
(https://practicalprimate.com/chill-hours/) or just < 45F to calculate the 
number of chill_seconds and put it into the archive, and the daily summary 
will populate the sum/wsum which will allow for easy calculation of 
cumulative chill hours, average chill hours, etc. 

Part of the problem I'm having is conceptualizing how types work *without* 
being 
in the archive. I'm writing a program that will automatically monitor and 
manage a small orchard, to include modifying watering routines based on 
things like ET, ripening windows, and rain received. This is the entire 
reason I set up a WeeWX station in the orchard, for the incredible database.

If my chill hours xtype is in the archive (or daily_summary) then accessing 
the db data from my irrigation program seems trivial.   I unsure if there's 
a way for an outside program to query WeeWX (as opposed to going directly 
to the database). If there is, that could be a way to use an xtype that 
isn't in the archive. It would also allow for more dynamic creation of 
similar types. For example, if you decided you wanted to change the 
definition of chill hours to <40F then you would only have to adjust the 
formula used in the xType, since nothing is stored in the db. Future 
queries to WeeWX from the irrigation program would immediately apply the 
new formula periods before the change.

I was also trying to think of a way to allow for multiple chillHours-style 
calculations without adding a new xtype for each calculation, but I don't 
think there's a way to do that smartly. And besides, I suppose what's a few 
more columns in a table with 100+ different observation types?

Also, do I understand the code correctly that DaySummaryManager takes care 
of both adding archive entries as well as updating the Daily Summary tables?

Thank you for helping a plodding hobbyist!
Seth
On Wednesday, January 19, 2022 at 2:21:03 PM UTC-6 tke...@gmail.com wrote:

> "Premature optimization is the root of all evil."
>
> Your proposal sounds complicated and incompatible with the existing daily 
> summaries. You would have to replicate a lot of what it already does.
>
> Make it work first, then worry about making it fast. You don't know yet 
> whether the calculation will take a long time. 
>
>
>
> On Wed, Jan 19, 2022 at 9:38 AM Seth Ratner  wrote:
>
>> Your Phenology extension is actually what got me thinking about how to 
>> implement the chilling hours in a more generic way, such that more than one 
>> metric (or one set of temperature thresholds) can be used. 
>>
>> The "simplest" way that came to mind was using some sort of modified 
>> Daily Summary table in the database. I haven't yet figured out how WeeWX 
>> populates those tables, but if the columns and calculation methods are 
>> customizable, then the daily (or nightly) data could be compiled at the end 
>> of the day and loaded into the table. That way every time you want to 
>> display the information, it's just a straight query from that summary 
>> table, rather than running the calculations every time for every archive 
>> entry. This also allows for multiple calculation methods, all stored in the 
>> summary table. 
>>
>> So as an example, at the end of the day, whenever WeeWX normally 
>> populates the summary tables, this new extension could run multiple 
>> algorithms (one for basic chill hours, one for the Utah Model, one for the 
>> phenology table on your website, etc) and store the resultant value in the 
>> respective column (one for Utah, one for basic, one for phenology, etc) in 
>> the new daily summary row for this extension. No new specific types are 
>> required in the loop or archive packets, so the processing power is only 
>> required once per day. When the data is viewed, it is only pulling values 
>> from a table rather than doing the calculations each time.
>>
>> But I'm not sure such customizations to the daily-table-creation-process 
>> is possible. 
>>
>> Thoughts?
>>
>>
>>
>>
>>
>>
>> On Wednesday, January 19, 2022 at 9:20:30 AM UTC-6 charlescu...@gmail.com 
>> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE- 
>>> Hash: SHA1 
>>>
>>> On Tue, 18 Jan 2022 17:05:33 -0800 
>>> Tom Deffer  wrote: 
>>>
>>> > Upon reflection, the biggest difference seems to be that 
>>> > cooling-degree days are weighted by the temperature difference from 
>>> > the baseline. You just want the total number of hours. 
>>>
>>> > This is best done as an XTypes extension 
>>> > . 
>>>
>>> I've fooled around with XTypes for my Phenology extension. 
>>>
>>> * [weewx-phenology](HTTP://LacusVeris.com/Phenology) — Growing 
>>> Degree-Days development models for various insect pests, showing 
>>> when to apply control strategies to minimize crop damage. 
>>>
>>> The Growing Degree-Days calculation(s) are compute-intensive relative 
>>> to the Coolin

Re: [weewx-user] Re: Chill Hours Extension

[Tom Keffer]

If you want to add the type to the main archive table, then go for it. That
is way less risky. In fact, as I recall, Gary R used a similar strategy for
calculating temperature extremes at night and during the day. He created a
new field outTempDay that held the temperature during the day, and None for
night. Similar, but opposite, for outTempNight. That way, he could easily
calculate the hottest night temperature.

You could do something similar by creating a field chillHours that would
hold the number of seconds the temperature was below 45ºF during that
archive interval. Then, once the daily summaries have done their magic, the
field 'sum' in the daily summaries would hold the total number of seconds
since midnight that the temperature was below 45.

No need to modify the summaries, and no xtype necessary. Just a new service
that calculates chillHours for the current record. Simple.

-tk


On Wed, Jan 19, 2022 at 1:57 PM Seth Ratner  wrote:

> Yeah, That's what it looks like
>
> For something simple it will work perfectly. If a make an xtype for
> chillHours that works like the ET type, except use either the Utah model (
> https://practicalprimate.com/chill-hours/) or just < 45F to calculate the
> number of chill_seconds and put it into the archive, and the daily summary
> will populate the sum/wsum which will allow for easy calculation of
> cumulative chill hours, average chill hours, etc.
>
> Part of the problem I'm having is conceptualizing how types work *without* 
> being
> in the archive. I'm writing a program that will automatically monitor and
> manage a small orchard, to include modifying watering routines based on
> things like ET, ripening windows, and rain received. This is the entire
> reason I set up a WeeWX station in the orchard, for the incredible database.
>
> If my chill hours xtype is in the archive (or daily_summary) then
> accessing the db data from my irrigation program seems trivial.   I unsure
> if there's a way for an outside program to query WeeWX (as opposed to going
> directly to the database). If there is, that could be a way to use an xtype
> that isn't in the archive. It would also allow for more dynamic creation of
> similar types. For example, if you decided you wanted to change the
> definition of chill hours to <40F then you would only have to adjust the
> formula used in the xType, since nothing is stored in the db. Future
> queries to WeeWX from the irrigation program would immediately apply the
> new formula periods before the change.
>
> I was also trying to think of a way to allow for multiple chillHours-style
> calculations without adding a new xtype for each calculation, but I don't
> think there's a way to do that smartly. And besides, I suppose what's a few
> more columns in a table with 100+ different observation types?
>
> Also, do I understand the code correctly that DaySummaryManager takes
> care of both adding archive entries as well as updating the Daily Summary
> tables?
>
> Thank you for helping a plodding hobbyist!
> Seth
> On Wednesday, January 19, 2022 at 2:21:03 PM UTC-6 tke...@gmail.com wrote:
>
>> "Premature optimization is the root of all evil."
>>
>> Your proposal sounds complicated and incompatible with the existing daily
>> summaries. You would have to replicate a lot of what it already does.
>>
>> Make it work first, then worry about making it fast. You don't know yet
>> whether the calculation will take a long time.
>>
>>
>>
>> On Wed, Jan 19, 2022 at 9:38 AM Seth Ratner  wrote:
>>
>>> Your Phenology extension is actually what got me thinking about how to
>>> implement the chilling hours in a more generic way, such that more than one
>>> metric (or one set of temperature thresholds) can be used.
>>>
>>> The "simplest" way that came to mind was using some sort of modified
>>> Daily Summary table in the database. I haven't yet figured out how WeeWX
>>> populates those tables, but if the columns and calculation methods are
>>> customizable, then the daily (or nightly) data could be compiled at the end
>>> of the day and loaded into the table. That way every time you want to
>>> display the information, it's just a straight query from that summary
>>> table, rather than running the calculations every time for every archive
>>> entry. This also allows for multiple calculation methods, all stored in the
>>> summary table.
>>>
>>> So as an example, at the end of the day, whenever WeeWX normally
>>> populates the summary tables, this new extension could run multiple
>>> algorithms (one for basic chill hours, one for the Utah Model, one for the
>>> phenology table on your website, etc) and store the resultant value in the
>>> respective column (one for Utah, one for basic, one for phenology, etc) in
>>> the new daily summary row for this extension. No new specific types are
>>> required in the loop or archive packets, so the processing power is only
>>> required once per day. When the data is viewed, it is only pulling values
>>> from a table rather

Re: [weewx-user] Skin with webcam?

[DaveStLou]

Hello!

I've been away for a bit and am trying to update my website using the 
information above. After downloading and installing the master.zip 
mentioned in issue 703, my MQTT live connection is failing. Using 
?debug=true, I see "Cannot connect to MQTT broker" in the browser console. 
I'd really like to take advantage of all the progress since I last visited 
this thread, but I don't want to lose MQTT live updates.

Any thoughts on what might be breaking the MQTT connection?

 When I roll back the files to prior to this update (still 1.3b1), MQTT 
connection resumes as usual (OakvilleWX.com }.

Thanks in advance for assistance!

On Thursday, December 16, 2021 at 8:12:09 AM UTC-6 ra...@norecords.org 
wrote:

> Hi everyone, just to notice you that my mod is a part of Belchertown skin 
> right now, you can update your installation with the latest github version 
> and use the radar_index.inc.example or see other taste at this issue 
> https://github.com/poblabs/weewx-belchertown/issues/703
> Cheers and have nice and happy Christmas
>
> Le lundi 30 août 2021 à 23:50:12 UTC+2, donnie...@gmail.com a écrit :
>
>> The incoming mqtt web sockets is running with SSL but the outgoing to 
>> mqtt broker is not. That is the part I can’t get to work.
>> I am not terribly concerned but it would tie everything up.
>>
>> The stills on the livestream work well. Those are actually snapshots 
>> generated by surveillance station on Synology. I have inotifywait running 
>> on pi to grab them and send to webfoot when a new one arrives. The 
>> time-lapse using one created by Synology did not work well as an mp4. I 
>> have instead converted the mp4 to an animated gif using ffmpeg which works 
>> much better. That is all done in a bash script using inotifywait.
>>
>> Thanks for your help.
>>
>> On Aug 30, 2021, at 3:20 PM, Doug Jenkins  wrote:
>>
>> Don:
>>
>> Sorry for the late reply. I checked your site and it appears to be up and 
>> running with SSL on both the Belchertown skin as well as your MQTT broker. 
>> I also see your live streams are working well too. 
>>
>> You have an interesting setup setting up a VPN to your synology NAS then 
>> NGINX as your proxy to the Pi. I understand why you have the setup given 
>> the Starlink dependency and using the Synology as the main ingress for your 
>> setup. 
>>
>> anyways I hope my approach helped. Just reach out on the user group again 
>> if you have any questions. There is a lot of great technical folks here 
>> that can assist.
>>
>> Doug Jenkins
>>
>> -- 
>> 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/y-RQmnoqcqQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx-user+...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/CACC0i0yj3gLt%3DfOZaz5YUAqAeMc8XQWv-su%3DzjX_DzcnOCk_DQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/04377d30-e47d-4460-989d-a11776ec5877n%40googlegroups.com.

RE: [weewx-user] Skin with webcam?

[purchase]

I am far from an expert at updating, but I do know the mqtt settings can get 
erased if they are located in the skin.conf and not in the weewx.conf, maybe 
that is what happened? Have you checked the backup config it makes to see if 
the statements are there or erased?

 

From: weewx-user@googlegroups.com  On Behalf Of 
DaveStLou
Sent: Wednesday, January 19, 2022 6:37 PM
To: weewx-user 
Subject: Re: [weewx-user] Skin with webcam?

 

Hello!

 

I've been away for a bit and am trying to update my website using the 
information above. After downloading and installing the master.zip mentioned in 
issue 703, my MQTT live connection is failing. Using ?debug=true, I see "Cannot 
connect to MQTT broker" in the browser console. I'd really like to take 
advantage of all the progress since I last visited this thread, but I don't 
want to lose MQTT live updates.

 

Any thoughts on what might be breaking the MQTT connection?

 

 When I roll back the files to prior to this update (still 1.3b1), MQTT 
connection resumes as usual (OakvilleWX.com  }.

 

Thanks in advance for assistance!

 

On Thursday, December 16, 2021 at 8:12:09 AM UTC-6 ra...@norecords.org 
  wrote:

Hi everyone, just to notice you that my mod is a part of Belchertown skin right 
now, you can update your installation with the latest github version and use 
the radar_index.inc.example or see other taste at this issue 
https://github.com/poblabs/weewx-belchertown/issues/703

Cheers and have nice and happy Christmas

 

Le lundi 30 août 2021 à 23:50:12 UTC+2, donnie...@gmail.com 
  a écrit :

The incoming mqtt web sockets is running with SSL but the outgoing to mqtt 
broker is not. That is the part I can’t get to work.

I am not terribly concerned but it would tie everything up.

 

The stills on the livestream work well. Those are actually snapshots generated 
by surveillance station on Synology. I have inotifywait running on pi to grab 
them and send to webfoot when a new one arrives. The time-lapse using one 
created by Synology did not work well as an mp4. I have instead converted the 
mp4 to an animated gif using ffmpeg which works much better. That is all done 
in a bash script using inotifywait.

 

Thanks for your help.





On Aug 30, 2021, at 3:20 PM, Doug Jenkins mailto:do...@dougjenkins.com> > wrote:

 

Don:

 

Sorry for the late reply. I checked your site and it appears to be up and 
running with SSL on both the Belchertown skin as well as your MQTT broker. I 
also see your live streams are working well too. 

You have an interesting setup setting up a VPN to your synology NAS then NGINX 
as your proxy to the Pi. I understand why you have the setup given the Starlink 
dependency and using the Synology as the main ingress for your setup. 

 

anyways I hope my approach helped. Just reach out on the user group again if 
you have any questions. There is a lot of great technical folks here that can 
assist.

 

Doug Jenkins

 

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

To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CACC0i0yj3gLt%3DfOZaz5YUAqAeMc8XQWv-su%3DzjX_DzcnOCk_DQ%40mail.gmail.com
 

 .

 

-- 
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/y-RQmnoqcqQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
weewx-user+unsubscr...@googlegroups.com 
 .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/04377d30-e47d-4460-989d-a11776ec5877n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0b3901d80da0%2406c28750%24144795f0%24%40maladomini.com.

[weewx-user] Re: Recurrence of unique constraint issues - Weewx 4.3.0, HP1000

[Susan Mackay]

I have received the PM but I think the discussion is better served by 
getting everyone's understanding of the situation.

The PM contains a rather long log file and the important excerpt is:

Jan 19 09:28:13 weatherpi weewx[608] INFO root: HP100: Established contact 
at 19/01/22 09:28:13
Jan 19 09:28:13 weatherpi weewx[608] INFO root: HP100: Retrieving startup 
records
Jan 19 09:28:30 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-18 16:39:15 GMT (1642523955) to database 'weewx.sdb'
Jan 19 09:28:30 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-18 16:39:15 GMT (1642523955) to daily summary in 'weewx.sdb'
Jan 19 09:28:30 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-18 16:44:15 GMT (1642524255) to database 'weewx.sdb'
Jan 19 09:28:30 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-18 16:44:15 GMT (1642524255) to daily summary in 'weewx.sdb'
Jan 19 09:28:30 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-18 16:49:15 GMT (1642524555) to database 'weewx.sdb'
Jan 19 09:28:30 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-18 16:49:15 GMT (1642524555) to daily summary in 'weewx.sdb'
...
Jan 19 09:29:32 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 07:54:15 GMT (1642578855)
Jan 19 09:29:32 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-19 09:14:15 GMT (1642583655) to database 'weewx.sdb'
Jan 19 09:29:32 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-19 09:14:15 GMT (1642583655) to daily summary in 'weewx.sdb'
Jan 19 09:29:32 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 07:59:15 GMT (1642579155)
Jan 19 09:29:32 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:04:15 GMT (1642579455)
Jan 19 09:29:32 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:09:15 GMT (1642579755)
Jan 19 09:29:33 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:14:15 GMT (1642580055)
Jan 19 09:29:33 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:19:15 GMT (1642580355)
Jan 19 09:29:33 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-19 09:19:15 GMT (1642583955) to database 'weewx.sdb'
Jan 19 09:29:33 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:24:15 GMT (1642580655)
Jan 19 09:29:33 weatherpi weewx[608] INFO weewx.manager: Added record 
2022-01-19 09:19:15 GMT (1642583955) to daily summary in 'weewx.sdb'
Jan 19 09:29:33 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:29:15 GMT (1642580955)
Jan 19 09:29:33 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:34:15 GMT (1642581255)
Jan 19 09:29:34 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:39:15 GMT (1642581555)
Jan 19 09:29:34 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:44:15 GMT (1642581855)
Jan 19 09:29:34 weatherpi weewx[608] INFO weewx.restx: PWSWeather: 
Published record 2022-01-19 08:49:15 GMT (1642582155)
Jan 19 09:29:34 weatherpi weewx[608] ERROR weewx.manager: Unable to add 
record 2021-01-24 08:53:12 GMT (1611478392) to database 'weewx.sdb': UNIQUE 
constraint failed: archive.dateTime
Jan 19 09:29:34 weatherpi weewx[608] ERROR weewx.manager: Unable to add 
record 2021-01-24 08:58:12 GMT (1611478692) to database 'weewx.sdb': UNIQUE 
constraint failed: archive.dateTime
Jan 19 09:29:34 weatherpi weewx[608] ERROR weewx.manager: Unable to add 
record 2021-01-24 09:03:12 GMT (1611478992) to database 'weewx.sdb': UNIQUE 
constraint failed: archive.dateTime
Jan 19 09:29:34 weatherpi weewx[608] ERROR weewx.manager: Unable to add 
record 2021-01-24 09:08:12 GMT (1611479292) to database 'weewx.sdb': UNIQUE 
constraint failed: archive.dateTime
Jan 19 09:29:34 weatherpi weewx[608] ERROR weewx.manager: Unable to add 
record 2021-01-24 09:13:12 GMT (1611479592) to database 'weewx.sdb': UNIQUE 
constraint failed: archive.dateTime

The driver gets access to the console at local time 2022-01-19 09:28:13 (to 
use the date/time format of the other records)

What I see is that the driver is correctly retrieving historical records 
from the console up to and including the one with the timestamp "2022-01-19 
09:19:15 GMT".  There is then a jump back in time to 2021-01-24 08:53:12 or 
nearly a year before! This is where the records become duplicated.

I must admit I can't understand what is happening other than the data being 
held in your console has become corrupted in some way. 

Normally the driver simply asks the console for the 'HISTORY_DATA' records 
starting from a specific date. The log shows that it is somehow jumping 
back a year and asking for those records, which are already in the database.

I know the area of the code where it retrieves these records and I'll see 
if the

Re: [weewx-user] Skin with webcam?

[vince]

On Wednesday, January 19, 2022 at 5:37:02 PM UTC-8 DaveStLou wrote:

> After downloading and installing the master.zip mentioned in issue 703, my 
> MQTT live connection is failing. Using ?debug=true, I see "Cannot connect 
> to MQTT broker" in the browser console. I'd really like to take advantage 
> of all the progress since I last visited this thread, but I don't want to 
> lose MQTT live updates.
>
> Any thoughts on what might be breaking the MQTT connection?
>
>
Not without seeing your logs.
 

>  When I roll back the files to prior to this update (still 1.3b1), MQTT 
> connection resumes as usual (OakvilleWX.com }.
>
>  
When you say 'roll back' did you uninstall/reinstall, or restore a backup 
of the skins/Belchertown directory, or something else ?


-- 
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/2f75c66e-8d99-42fc-be42-9af97790a530n%40googlegroups.com.

[weewx-user] Re: WeeWX and pv?

[kludo]

 

Since I only want to display a few PV data, I decided to use the two 
database fields "signal1" and "signal2" as storage location for the output 
data of my two inverters.
In principle, this also works, but I do not receive totalized yield data. 
This means that at the end of the day, I can display the history, but not 
the daily output.

Another issue is the subsequent import of the stored data into the WeeWX 
database. I wanted, to have the year 2022 complete, to transfer the data 
saved as csv to the WeeWX database afterwards using wee_import. 

I have prepared the csv accordingly and assigned "signal1" and "signal2" to 
the group group_energy in the units.py file. If I start the import with the 
parameter "--dry-run" everything is fine. Without "--dry-run" the process 
also runs without errors, but the data is not included in the database due 
to a UNIQUE problem.

However, I would like to add the PV values to the respective existing data 
record and not create a new data record. Is there no way to keep the 
existing record and only save the additional values?

I am very thankful for any tip
kludo schrieb am Sonntag, 9. Januar 2022 um 16:22:25 UTC+1:

> Thank you for the answers, I will have to look into the subject more 
> intensively. My PV system is already very old and there is no support from 
> the manufacturer, but I can tap the harvest data via serial interface. 
> Let's see which solution brings me the faster success.
>
> kk44...@gmail.com schrieb am Freitag, 7. Januar 2022 um 15:56:14 UTC+1:
>
>> There is no general solution to include PV values in WeeWX. As far as I 
>> know, an extension is available for one single german manufacturer, only.
>>
>> Peter Fletcher schrieb am Freitag, 7. Januar 2022 um 15:11:26 UTC+1:
>>
>>> You have at least two options. One is to keep your detailed solar 
>>> records separately and pull the data items you want to display into either 
>>> new fields or 'spare' fields in the weewx database. The other, of course, 
>>> is to add all the fields you need to the weewx database. AFAIK, there is no 
>>> ready-made 'package' that does this.
>>>
>>> I don't incorporate my solar data in weewx, because I created a separate 
>>> application that records all the data locally before I got into weather, 
>>> and my solar provider has an excellent web-based App which displays the 
>>> real-time data. I do, however, use the first approach to combine some of 
>>> the data from my ecobee thermostat with weewx's weather data for display. 
>>> Assuming that you have some degree of comfort with database design and 
>>> Python programming, the weewx documentation will help you greatly with 
>>> either approach, but you will also be able to get useful help and advice 
>>> about implementation details here.
>>>
>>> On Friday, January 7, 2022 at 5:05:13 AM UTC-5 udo.kl...@gmail.com 
>>> wrote:
>>>
 I have installed WeeWX in the last few weeks and have come to know and 
 appreciate the software.

 But now i would like to add the solar yield of my pv system to the 
 weewx database as well. Unfortunately, I have not found any suitable 
 database fields for this. Do I have to adapt the database schema for this? 
 Is there possibly already a ready-made solution for this?

 Thanks

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/53dfb00a-a463-48cc-9918-bdbad226fc48n%40googlegroups.com.