[weewx-user] Allow user-selectable image formats #758

[Paul R Anderson]

Just posted a comment on Issue #758
 which is marked as a stall and
will be removed soon.
Hopeful that it might get reconsidered.

Thanks Paul

-- 
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/CAOAVAecTX%3DGxLOvFxEG-UUC-2ywuFBu8FiqywV2z2UgJknPdMQ%40mail.gmail.com.

Re: [weewx-user] Upgraded to V5 - will not run automaticly

[Paul R Anderson]

Vince,
Your confusion is probably caused by the enormous popularity of Docker. At
this point most of us hear the word Container and only think of Docker.
This is also a huge reason why LXC Containers are nowhere near as popular
as Docker containers , no one knows they exist, let alone what they are.
*LXC Containers are system containers*
*Docker Containers are Application containers*
There are generally at least two types of containers: Application
containers, and System containers
There's a good blog post from Ubuntu that explains it much better than I
can.
What are Linux containers?


Brief excerpt from the blog post:

" Application vs system containers
Application containers (such as Docker) are containers running a single
process per container. They run stateless types of workloads so that you
can ramp up and down as needed – create new containers and delete them at
any time. Usually, you don’t need to care about the lifecycle of those
containers, as they are meant to be ephemeral.

The other type of containers, system containers, are much closer to a
virtual or a physical machine. They run a full operating system inside
them, and you manage them exactly as you would a virtual or a physical
machine. That means you can install packages inside them, you can manage
services, define backup policies, monitoring, and all other aspects as you
usually would with a virtual machine. These containers are usually very
long-lasting. If you need to update them, you can do so with the normal
tooling of the Linux distribution you are using. It also means that you
will get normal security updates from distributions for those containers,
so you wouldn’t need to wait for any image to be published to get the
security fixes. "



Paul

On Wed, May 8, 2024 at 8:10 PM vince  wrote:

> I have to admit being a little confused.  A container running multiple
> processes that you can ssh into isn't a container, it's a virtual machine.
>
> On Wednesday, May 8, 2024 at 4:42:00 AM UTC-7 Graham Eddy wrote:
>
>> i suggest testing before publishing..
>> that won’t work without the permissions towards end of my lxc/105.conf
>> file
>> *⊣GE⊢*
>>
>> On 8 May 2024, at 9:25 PM, G7LTT  wrote:
>>
>> Updated to add USB device to the container.
>>
>>
>> --
> 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/dd2f4126-94ec-4456-b7c1-fc0fce4a6d3an%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/CAOAVAefo5H3zdsacvrtZkvLFxkkD-eAzmpTCKX8hprUpOxzNYg%40mail.gmail.com.

Re: [weewx-user] I'm desperate to fix my NOAA reports. Can I please pay someone to help fix my database and recover this data?

[Paul R Anderson]

This was really fun to track down! Thanks for the challenge !
I have been able to reproduce your issue... it's a  little complicated, but
it can be fixed  easily :)
It's caused by 2 factors
*1. Your station seems to have stopped reporting Barometric Pressure on or
about 2019-12-31 @ 16:45 *
*No idea why, hopefully you are aware of this and know the cause.*

*2. Your using an older version of  NOAA-%Y-%m.txt.tmpl*
The older version used this statement to determine if there was data for
each day
#for $day in $month.days
#if $day.barometer.count.raw
So it fails because there is no  $day.barometer.count.raw
Your Monthly Report will look like this:

   MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020

   TEMPERATURE (F), RAIN (in), WIND SPEED (mph)

 HEAT   COOL AVG
  MEAN   DEGDEG  WIND
DOM
DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   HIGH
TIMEDIR

---
 01
 02
 03
 04
 05
 06
 07
 08
 09
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31

---
  55.4   81.3 31   44.4 12  294.20.7   0.150.4   14.0
  29302

*Newer version of NOAA-%Y-%m.txt.tmp*
Changed how it determines if there was data for each day
#for $day in $month.days
#if $day.outTemp.has_data or $day.rain.has_data or $day.wind.has_data
So it will pass even if there is no  $day.barometer.count.raw
Your Monthly Report will now look like this:

 MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020

   TEMPERATURE (F), RAIN (in), WIND SPEED (mph)

 HEAT   COOL AVG
  MEAN   DEGDEG  WIND
DOM
DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   HIGH
TIMEDIR
---
 01   55.7   63.8  10:55   47.4  03:409.30.0   0.000.39.0
 08:00294
 02   55.9   64.1  06:30   51.5  03:109.10.0   0.000.34.0
 05:45322
 03   62.5   72.2  16:55   52.5  23:152.50.0   0.000.66.0
 14:50301
 04   57.3   71.7  16:55   48.7  07:207.70.0   0.000.46.0
 13:30297
 05   56.9   70.0  16:45   47.8  10:158.10.0   0.000.46.0
 16:50302
 06   64.5   80.7  16:20   53.1  10:250.50.0   0.000.26.0
 14:50297
 07   60.8   79.3  15:40   50.5  00:404.20.0   0.000.37.0
 15:55299
 08   51.9   62.5  15:05   47.1  08:30   13.10.0   0.000.59.0
 15:30317
 09   50.9   60.8  14:20   46.6  01:25   14.10.0   0.000.6   11.0
 15:35301
 10   51.6   64.1  16:30   44.9  09:35   13.40.0   0.010.57.0
 15:50294
 11   51.0   60.6  15:20   45.0  07:25   14.00.0   0.000.7   13.0
 15:25325
 12   51.2   62.5  15:10   44.4  09:15   13.80.0   0.000.5   10.0
 16:25298
 13   51.2   59.8  17:45   46.3  08:50   13.80.0   0.000.58.0
 17:30300
 14   50.4   60.5  16:35   45.2  10:00   14.60.0   0.010.49.0
 17:00294
 15   51.1   65.1  16:00   44.4  09:40   13.90.0   0.000.48.0
 17:25296
 16   50.3   58.4  15:20   45.4  10:00   14.70.0   0.050.8   11.0
 01:25315
 17   51.2   60.1  16:55   45.5  10:20   13.80.0   0.050.6   12.0
 03:40316
 18   56.1   69.6  17:30   46.9  06:108.90.0   0.000.26.0
 16:10294
 19   58.6   76.1  14:50   49.0  10:056.40.0   0.000.29.0
 15:10300
 20   54.9   59.3  15:45   52.4  04:50   10.10.0   0.000.3   11.0
 15:50306
 21   52.0   56.8  14:20   47.7  02:15   13.00.0   0.030.37.0
 14:35310
 22   52.6   61.1  14:25   47.6  04:35   12.40.0   0.000.58.0
 16:25296
 23   59.9   73.0  16:20   50.0  07:205.10.0   0.000.47.0
 15:40306
 24   59.0   74.2  16:55   51.0  02:056.00.0   0.000.35.0
 13:05297
 25   54.9   69.8  17:10   46.9  08:45   10.10.0   0.000.37.0
 14:20296
 26   51.2   57.1  17:10   47.4  00:45   13.80.0   0.000.17.0
 17:10299
 27   55.4   70.4  16:55   45.7  08:259.60.0   0.000.38.0
 17:15284
 28   58.9   73.9  17:15   50.9  08:156.10.0   0.000.67.0
 15:15296
 29   58.9   71.3  18:15   45.7  08:356.10.0   0.000.1   14.0
 16:10176
 30   59.0   71.3  16:50   48.9  09:506.00.0   0.000.59.0
 15:30302
 31   65.7   81.3  17:50   53.1  08:550.00.7   0.000.27.0
 15:25304
---
  55.4   81.3 31   44.4 12  

Re: [weewx-user] Certificate Verify failed

[Paul R Anderson]

Thanks Tom
Set my "station key" as the password and uploads are working. Funny it was
set to the old password for years without issue.



On Sat, Aug 5, 2023 at 4:22 PM gary@gmail.com 
wrote:

> Since they just consolidated several sites/services, I just 'reset' my
> password to the current one.
> If there is anything tied to the WU password, it'll be fine.
>
> On Saturday, August 5, 2023 at 3:46:06 PM UTC-4 Paul R Anderson wrote:
>
>> 2 days ago I changed my password on Weather Underground after they
>> requested I do so. My new password is accepted when logging on to their
>> site. However  if I update my weewx.conf with the new password uploads
>> fail. Setting weewx.conf with the old password uploading works. I'm
>> assuming that Weather Underground doesn't sync new passwords across their
>> services on a timely basis. So just check my log daily and when uploads
>> stop working then it's time to set weewx.conf to the new password.
>>
>> Classic Weather Underground behavior actually they have always had flaky
>> api's and services, and things have gone from bad to worse since IBM bought
>> them. Often wonder why I still bother uploading my data to them and the
>> only reason is that I've been doing so for about 20 years.
>>
>> Paul
>>
>> On Fri, Aug 4, 2023 at 6:07 PM Tom Keffer  wrote:
>>
>>> Sorry. I missed that piece of information.
>>>
>>> I believe the WU uses DigiCert, so if an expired certificate is the
>>> problem, your goal is to update the DigiCert root certificate. I'm not sure
>>> how to do that on a Mac, although I'm sure there are instructions
>>> somewhere. Perhaps you can download a .pem file directly from their
>>> website. Check around.
>>>
>>> One thing to try is the app Keychain Access. Click on "System Roots" and
>>> look for the DigiCert certificates and see how old they are.
>>>
>>> Sorry I don't have anything more helpful.
>>>
>>> On Fri, Aug 4, 2023 at 2:33 PM David Barto  wrote:
>>>
>>>> This is a MacOS install, apt-get doesn’t exist. 8^(
>>>>
>>>> David
>>>>
>>>> On Aug 4, 2023, at 2:25 PM, Tom Keffer  wrote:
>>>>
>>>> Can't speak for the problem with forecast, but for your
>>>> CERTIFICATE_VERIFY_FAILED error, try refreshing the certificates on your
>>>> machine:
>>>>
>>>> *sudo apt-get update*
>>>> *sudo apt-get install --reinstall ca-certificates*
>>>>
>>>>
>>>> On Fri, Aug 4, 2023 at 2:13 PM David Barto  wrote:
>>>>
>>>>> But only after I changed my password on the Wunderground.com
>>>>> <http://wunderground.com/> site because they asked me to. (Bas..rds)
>>>>>
>>>>> So it went from fine:
>>>>> Aug  1 20:43:15 Magrathea weewx[58335]: manager: Added record
>>>>> 2023-08-01 20:43:00 PDT (1690947780) to database 'weewx.sdb'
>>>>> Aug  1 20:43:15 Magrathea weewx[58335]: manager: Added record
>>>>> 2023-08-01 20:43:00 PDT (1690947780) to daily summary in 'weewx.sdb'
>>>>> Aug  1 20:43:15 Magrathea weewx[58335]: restx: CWOP: wait interval
>>>>> (240 < 600) has not passed for record 2023-08-01 20:43:00 PDT (1690947780)
>>>>> Aug  1 20:43:15 Magrathea weewx[58335]: restx: StationRegistry: wait
>>>>> interval (85440 < 604800) has not passed for record 2023-08-01 20:43:00 
>>>>> PDT
>>>>> (1690947780)
>>>>> Aug  1 20:43:16 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>>>> attempt 1 to download forecast: HTTP Error 503: Service Unavailable
>>>>> Aug  1 20:43:18 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>>>> attempt 2 to download forecast: HTTP Error 503: Service Unavailable
>>>>> Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>>>> attempt 3 to download forecast: HTTP Error 503: Service Unavailable
>>>>> Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>>>> to download forecast
>>>>> Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: no
>>>>> forecast data for KCAPOWAY187 from http://api.wunderground.com/api
>>>>>
>>>>> to this:
>>>>>
>>>>> Aug  4 00:57:18 Magrathea weewx[58335]: manager: Added record
>>>>> 2023-08-04 00:57:00 PDT (1691135820) to database 'weewx.sdb'
>>>>> Aug  4 00

Re: [weewx-user] Certificate Verify failed

[Paul R Anderson]

2 days ago I changed my password on Weather Underground after they
requested I do so. My new password is accepted when logging on to their
site. However  if I update my weewx.conf with the new password uploads
fail. Setting weewx.conf with the old password uploading works. I'm
assuming that Weather Underground doesn't sync new passwords across their
services on a timely basis. So just check my log daily and when uploads
stop working then it's time to set weewx.conf to the new password.

Classic Weather Underground behavior actually they have always had flaky
api's and services, and things have gone from bad to worse since IBM bought
them. Often wonder why I still bother uploading my data to them and the
only reason is that I've been doing so for about 20 years.

Paul

On Fri, Aug 4, 2023 at 6:07 PM Tom Keffer  wrote:

> Sorry. I missed that piece of information.
>
> I believe the WU uses DigiCert, so if an expired certificate is the
> problem, your goal is to update the DigiCert root certificate. I'm not sure
> how to do that on a Mac, although I'm sure there are instructions
> somewhere. Perhaps you can download a .pem file directly from their
> website. Check around.
>
> One thing to try is the app Keychain Access. Click on "System Roots" and
> look for the DigiCert certificates and see how old they are.
>
> Sorry I don't have anything more helpful.
>
> On Fri, Aug 4, 2023 at 2:33 PM David Barto  wrote:
>
>> This is a MacOS install, apt-get doesn’t exist. 8^(
>>
>> David
>>
>> On Aug 4, 2023, at 2:25 PM, Tom Keffer  wrote:
>>
>> Can't speak for the problem with forecast, but for your
>> CERTIFICATE_VERIFY_FAILED error, try refreshing the certificates on your
>> machine:
>>
>> *sudo apt-get update*
>> *sudo apt-get install --reinstall ca-certificates*
>>
>>
>> On Fri, Aug 4, 2023 at 2:13 PM David Barto  wrote:
>>
>>> But only after I changed my password on the Wunderground.com
>>>  site because they asked me to. (Bas..rds)
>>>
>>> So it went from fine:
>>> Aug  1 20:43:15 Magrathea weewx[58335]: manager: Added record 2023-08-01
>>> 20:43:00 PDT (1690947780) to database 'weewx.sdb'
>>> Aug  1 20:43:15 Magrathea weewx[58335]: manager: Added record 2023-08-01
>>> 20:43:00 PDT (1690947780) to daily summary in 'weewx.sdb'
>>> Aug  1 20:43:15 Magrathea weewx[58335]: restx: CWOP: wait interval (240
>>> < 600) has not passed for record 2023-08-01 20:43:00 PDT (1690947780)
>>> Aug  1 20:43:15 Magrathea weewx[58335]: restx: StationRegistry: wait
>>> interval (85440 < 604800) has not passed for record 2023-08-01 20:43:00 PDT
>>> (1690947780)
>>> Aug  1 20:43:16 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>> attempt 1 to download forecast: HTTP Error 503: Service Unavailable
>>> Aug  1 20:43:18 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>> attempt 2 to download forecast: HTTP Error 503: Service Unavailable
>>> Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>> attempt 3 to download forecast: HTTP Error 503: Service Unavailable
>>> Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>> to download forecast
>>> Aug  1 20:43:19 Magrathea weewx[58335]: forecast: WUThread: WU: no
>>> forecast data for KCAPOWAY187 from http://api.wunderground.com/api
>>>
>>> to this:
>>>
>>> Aug  4 00:57:18 Magrathea weewx[58335]: manager: Added record 2023-08-04
>>> 00:57:00 PDT (1691135820) to database 'weewx.sdb'
>>> Aug  4 00:57:18 Magrathea weewx[58335]: manager: Added record 2023-08-04
>>> 00:57:00 PDT (1691135820) to daily summary in 'weewx.sdb'
>>> Aug  4 00:57:18 Magrathea weewx[58335]: restx: StationRegistry: wait
>>> interval (273480 < 604800) has not passed for record 2023-08-04 00:57:00
>>> PDT (1691135820)
>>> Aug  4 00:57:18 Magrathea weewx[58335]: restx: CWOP: wait interval (480
>>> < 600) has not passed for record 2023-08-04 00:57:00 PDT (1691135820)
>>> Aug  4 00:57:19 Magrathea weewx[58335]: restx
>>> *alert: Wunderground-PWS: Failed upload attempt 1: >> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)>*Aug
>>> 4 00:57:19 Magrathea weewx[58335]: forecast: WUThread: WU: failed attempt 1
>>> to download forecast: HTTP Error 503: Service Unavailable
>>> Aug  4 00:57:20 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>> attempt 2 to download forecast: HTTP Error 503: Service Unavailable
>>> Aug  4 00:57:20 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>> attempt 3 to download forecast: HTTP Error 503: Service Unavailable
>>> Aug  4 00:57:20 Magrathea weewx[58335]: forecast: WUThread: WU: failed
>>> to download forecast
>>> Aug  4 00:57:20 Magrathea weewx[58335]: forecast: WUThread: WU: no
>>> forecast data for KCAPOWAY187 from http://api.wunderground.com/api
>>>
>>> And I stopped publishing.
>>>
>>> Which certificate is it complaining about and how would I find/create a
>>> proper certificate.
>>> Note: Version 3.9.2 (yeah, old and my Mac I’m using has a very old
>>> python on it)
>>> Local 

Re: [weewx-user] VantageVue rain collector delay

[Paul R Anderson]

Very strange blocked rain funnel would be the number one suspect. Only
other thing that comes to mind is residual 'rain' falling from a tree
canopy, or any other object that could hold rain droplets, and release them
long after the rain shower has ended. Wondering if any trees have started
to encroach on the area above your rain gauge?

Paul

On Mon, May 1, 2023 at 7:03 AM Steve C  wrote:

> I removed it again yesterday and checked the tip bucket and entrance and
> exit paths for blockages but found none. The rain ended several hours ago,
> but my Vue is still counting .01" every few minutes this morning.
>
> http://livefreeorpi.com
>
> On Sunday, April 30, 2023 at 1:27:57 PM UTC-4 Karen K wrote:
>
>> I remember such behavior when a spider let the remains of her meals drop
>> into the rain bucket.
>>
>> Graham Eddy schrieb am Sonntag, 30. April 2023 um 02:46:00 UTC+2:
>>
>>> is the outlet from rain bucket partially blocked?
>>> *⊣GE⊢*
>>>
>>> On 29 Apr 2023, at 11:48 pm, Steve C  wrote:
>>>
>>> Important distinction! I meant to mention that. Yes, the software seems
>>> perfectly fine. The console is reporting the 'slow drip' and WeeWX logs it
>>> accordingly. Being a hardware issue I can move this to a Davis forum if it
>>> is inappropriate here.
>>>
>>> On Saturday, April 29, 2023 at 9:42:42 AM UTC-4 Tom Keffer wrote:
>>>
  What does the console show?

 On Sat, Apr 29, 2023 at 6:27 AM Steve C  wrote:

> Sorry for the long post, but the details might matter. We had a
> significant rain event last weekend and my rain gauge responded in a very
> weird way (which it has done before). It was raining when I got up in the
> AM, 1/2 inch collected already. After about 3/4in, it POURED and the rain
> rate slowed to something like .07in/hour. I replaced the rain gauge (with
> the Davis rehab kit) last fall and went out in the downpour to check the
> bucket/collector. No blockages, not full of water...
>
> My next door neighbor's device report 2.19" of rain when it ended that
> day. Mine reported 1.90", however it continued to report .01 or .02 clicks
> at a time until it finally stopped at .42" the next day (although we had 
> no
> rainfall) for a storm total of 2.32", not terribly far off from my
> neighbor's 2.19".  I have attached the chart that illustrates the slow
> collection- as if the collection was full of water that slowly leaked out
> (can't be the case).
>
> The very next day we had a brief, heavy thunderstorm. Both my neighbor
> and I reported the same .30" for the even[image:
> Screenshot2023-04-24.png]t.
>
> Weewx  4.9.1
> Vantage Vue with an IPconnect.
>
> We're looking at another 1-3" of rain this weekend, and I'd love to
> hear any suggestions!
>
> Thanks,
> Steve
>
> --
> You received this message because you are subscribed to the Google
> Groups "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/f4c19b77-1dd3-4573-9bec-ac5098a68158n%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/47944903-4d2a-4ca7-94d9-a3e0add0fd86n%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/8bed9005-ec36-4258-8acd-0d392c00d0a1n%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/CAOAVAefq4iT8ij-Xy0%3D%3D9zcCs_U_HUe16OLq8wtcz4E2MFqM-g%40mail.gmail.com.

Re: [weewx-user] No logs at *ALL*??!

[Paul R Anderson]

Seems like your system uses systemd since you state that you tried "I run
systemctl start weewx"
Based on that weewx seems to have a unit file name of "weewx"
Under Systemd you can use journalctl to query the contents of the systemd
journal.
You can pass it a unit file name, and start stop ranges alone with a lot of
other options.
You should be able to see all logging activity since 2023 02 01 with:

sudo journalctl -u weewx.service --since "2023-02-01"

where -u is the unit name, --since is a date in -MM-DD format
Also you can redirect output to a file to save it
 sudo journalctl -u weewx.service --since "2023-02-01">/var/tmp/weewx.log


On Tue, Mar 14, 2023 at 7:40 AM Tom Keffer  wrote:

> Take a look at the section *Where to find things
> * in the
> User's Guide to locate your log.
>
> On Mon, Mar 13, 2023 at 7:27 PM MrPete  wrote:
>
>> My weewx was running reasonably well for a year.
>> In Feb we left on a trip.
>> I returned, and learned weewx stopped working back on Feb 22
>> Here's the strange part: NOTHING is being logged.
>>
>> /var/log/weewx.log has been empty since the end of January.
>>
>> I run systemctl start weewx and it blows up early on (the exact reason
>> doesn't matter at this point -- a server communication failure)
>>
>> What seems important: systemctl status weewx sees the most recent error
>> messages.
>>
>> But *I simply cannot find the log file!!*
>>
>> Any hints would be most welcome!
>> Pete
>>
>> --
>> 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/fbd5b10d-53b7-4d19-a611-42b227c5adabn%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/CAPq0zEC9ZP%3DuLa47ZYwXtYh%3DR28Eheg%3DAu3DYqvCuGbo-UJz7g%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/CAOAVAefX33n8z-Q08nOSGHCpSd5t0%3D8bz1GDxLeL8Q-vXSj0%3DA%40mail.gmail.com.

Re: [weewx-user] Re: Power outage without RTC module

[Paul R Anderson]

fake-hwclock is just plain silly, by design it sets the OS time to a known
wrong state with the premise that it's a better than nothing choice.
Funny the further down the rabbit hole I go the more I see that I don't
like.  Such as debian setting NTPD or timesyncd to use debian.pool.ntp.org
ntp servers.
I certainly don't trust their list of rotating servers to all be accurate.
Always set systems to use known highly available servers I trust.
It's a jungle out there a minimum you need, Belt, Suspenders, and of
course a good quality Tin Foil Hat.

Paul









so strange that a simple thing lige starting

On Mon, Aug 22, 2022 at 5:28 PM vince  wrote:

> On Monday, August 22, 2022 at 10:12:59 AM UTC-7 pa...@pauland.net wrote:
>
>> Problem I've seen in the past was that on a Rasberry Pi installrd NTP ,
>> like I have on every system I've installed since 2004, yet after a power
>> outage weeWx started with a bad Os Time. Investigated and found that if I
>> removed purged fake-hwclock the expected wait for ntp worked. Now on some
>> systems I install ntp others I don't, if it's a PI remove fake-hwclock and
>> even if the machine has a RTC I enable systemd-time-wait-sync.
>>
>
> Yes - but be careful there.  Lots of os now have that blasted fake-hwclock
> kludge.
>
> I remove fake-hwclock and install/enable ntpd everywhere and it's nice and
> simple and reliable.  No need to edit anything in weewx at all, which is an
> added plus.
>
> The pi time-related details are in the FAQ
>  and wiki
> .
>
>
>
> --
> 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/221eacc6-2833-420d-ad00-0d6cb4d56c00n%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/CAOAVAec%2B%2BvLaDmERcpg%2Bum8EP0A5T1K1myebemUpgPn7KVvd0Q%40mail.gmail.com.

Re: [weewx-user] Re: Power outage without RTC module

[Paul R Anderson]

Problem I've seen in the past was that on a Rasberry Pi installrd NTP ,
like I have on every system I've installed since 2004, yet after a power
outage weeWx started with a bad Os Time. Investigated and found that if I
removed purged fake-hwclock the expected wait for ntp worked. Now on some
systems I install ntp others I don't, if it's a PI remove fake-hwclock and
even if the machine has a RTC I enable systemd-time-wait-sync.
Also change weewx.service to:

Requires=systemd-time-wait-sync.service
After=systemd-time-wait-sync.service

Many ways to get there

On Mon, Aug 22, 2022 at 12:02 PM vince  wrote:

> Easier yet - just install ntp and use that instead, and systemd won't do
> anything time related.
>
> FWIW - I've found ntp handles drift better by far, and I've been using it
> happily everywhere for well over 20 years across all unixy platforms of all
> vintages so I know what I'm getting.  You never know what systemd is going
> to do or change os to os and version to version.  You gotta fight the
> systemd borg whenever possible :-)
>
> Here's the logs from a pi4 using ntp that I am running the simulator on
> which was powered down overnight.  Note how the system boots up initial
> with a Mar-26 date and weewx waits gracefully for the system to get the
> correct date+time before proceeding.  You'll see the syslog show the system
> switch to today's date when ntpd updates things and weewx starts up pretty
> much immediately after.
>
> Mar 26 22:42:16 pi4 kernel: [0.00] Booting Linux on physical CPU
> 0x0
> Mar 26 22:42:16 pi4 kernel: [0.00] Linux version 5.15.56-v7l+
> (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1)
> 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1575 SMP Fri Jul 22 20:29:46
> BST 2022
> Mar 26 22:42:16 pi4 kernel: [0.00] CPU: ARMv7 Processor [410fd083]
> revision 3 (ARMv7), cr=30c5383d
> Mar 26 22:42:16 pi4 kernel: [0.00] CPU: div instructions
> available: patching division code
> Mar 26 22:42:16 pi4 kernel: [0.00] CPU: PIPT / VIPT nonaliasing
> data cache, PIPT instruction cache
> Mar 26 22:42:16 pi4 kernel: [0.00] OF: fdt: Machine model:
> Raspberry Pi 4 Model B Rev 1.1
> [...]
> Mar 26 22:42:16 pi4 kernel: [7.491386] uart-pl011 fe201000.serial: no
> DMA platform data
> Mar 26 22:42:16 pi4 kernel: [7.806915] Adding 102396k swap on
> /var/swap.  Priority:-2 extents:1 across:102396k SSFS
> Mar 26 22:42:17 pi4 kernel: [8.223906] brcmfmac:
> brcmf_cfg80211_set_power_mgmt: power save enabled
> Mar 26 22:42:17 pi4 kernel: [8.590674] bcmgenet fd58.ethernet:
> configuring instance for external RGMII (RX delay)
> Mar 26 22:42:17 pi4 kernel: [8.592910] bcmgenet fd58.ethernet
> eth0: Link is Down
>
>
>
>
>
>
> *Mar 26 22:42:17 pi4 weewx[415] INFO __main__: Initializing weewx version
> 4.8.0Mar 26 22:42:17 pi4 weewx[415] INFO __main__: Using Python 3.9.2
> (default, Mar 12 2021, 04:06:34) #012[GCC 10.2.1 20210110]Mar 26 22:42:17
> pi4 weewx[415] INFO __main__: Platform
> Linux-5.15.56-v7l+-armv7l-with-glibc2.31Mar 26 22:42:17 pi4 weewx[415] INFO
> __main__: Locale is 'en_US.UTF-8'Mar 26 22:42:17 pi4 weewx[415] INFO
> __main__: Using configuration file /home/weewx/weewx.confMar 26 22:42:17
> pi4 weewx[415] INFO __main__: Debug is 0Mar 26 22:42:17 pi4 weewx[415] INFO
> __main__: Waiting for sane time. Current time is 2022-03-26 22:42:17 PDT
> (1648359737)*
> Mar 26 22:42:23 pi4 kernel: [   14.316585] IPv6: ADDRCONF(NETDEV_CHANGE):
> wlan0: link becomes ready
> Mar 26 22:42:23 pi4 kernel: [   14.383527] Bluetooth: Core ver 2.22
> Mar 26 22:42:23 pi4 kernel: [   14.383597] NET: Registered PF_BLUETOOTH
> protocol family
> [...]
> Mar 26 22:42:23 pi4 kernel: [   14.700205] Bluetooth: BNEP socket layer
> initialized
> Mar 26 22:42:23 pi4 kernel: [   14.714801] NET: Registered PF_ALG protocol
> family
> Mar 26 22:42:23 pi4 kernel: [   14.735599] cryptd: max_cpu_qlen set to 1000
>
>
>
> *Aug 22 08:34:37 pi4 kernel: [   31.832505] cam-dummy-reg: disablingAug 22
> 08:34:37 pi4 weewx[415] INFO weewx.engine: Loading station type Simulator
> (weewx.drivers.simulator)Aug 22 08:34:37 pi4 weewx[415] INFO
> user.MQTTSubscribe: (Service) Version is 2.1.0*Aug 22 08:34:37 pi4
> weewx[415] INFO user.MQTTSubscribe: (Service) Log level: 0
> Aug 22 08:34:37 pi4 weewx[415] INFO user.MQTTSubscribe: (Service) Log
> debug setting: 0
> Aug 22 08:34:37 pi4 weewx[415] INFO user.MQTTSubscribe: (Service) Log
> console: False
> Aug 22 08:34:37 pi4 weewx[415] INFO user.MQTTSubscribe: (Service) Log
> file: None
>
>
> --
> 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/0d091386-1e68-4f64-9c7b-44e67de544afn%40googlegroups.com
> 

Re: [weewx-user] Re: Power outage without RTC module

[Paul R Anderson]

By the way there is an easy solution to stop this whole calamity of events
from occurring.
In the case that for some reason you can not install a RTC, which is
very desirable, and highly recommended.
You can enable the systemd-time-wait-sync service on your system.
sudo systemctl status systemd-time-wait-sync
sudo systemctl start systemd-time-wait-sync

The systemd service for weewx located at  /util/systemd/weewx.service
Has this in it:
Requires=time-sync.target
After=time-sync.target
The problem is that time-sync.target starts thes ynchronization process ,
but doesn't wait for it to complete, so WeeWx starts before the OS
clock gets synchronized .
Once you enable systemd-time-wait-sync Service
systemd-time-wait-sync will wait infinitely till it can synchronize time.
Now services that depend on time-sync target , such as WeeWx ,will not
start until the OS time is synchronized.

Which all means that now when the power comes back on the system starts, It
tries to synchronize system OS time,
It might need to wait for a Wi-Fi connection, a router to start, an
internet connection or something else.
Until the OS time get's synchronized WeeWx won't start.
Meanwhile your davis logger , if running on batteries during the whole
power outage , will continue to log data.
Once WeeWx starts it will get all the data from the logger for the period
of the power outage to present .
All should be well and looking at the WeeWx data, you would never know
there was a power outage.

Hope this helps, and is't to confusing to follow.

Paul







On Mon, Aug 22, 2022 at 8:29 AM Paul R Anderson  wrote:

> For hardware that supports WeeWx can set the onboard clock of the hardware.
> In your case the davis data logger supports setting of its onboard clock.
>
> This is controlled in the  [StdTimeSynch] section of weewx.config
> I believe WeeWx ships with this as default:
>
> ##
>
> #   For hardware that supports it, this section controls how often the
> #   onboard clock gets updated.
>
> [StdTimeSynch]
>
> # How often to check the weather station clock for drift (in seconds)
> clock_check = 14400
>
> # How much it can drift before we will correct it (in seconds)
> max_drift = 5
>
>
> ##
> So unless you changed it most likely WeeWx set the davis datalogger
> onboard clock, while your OS was running with the incorrect time.
>
> On Mon, Aug 22, 2022 at 6:15 AM Andrea Di Saverio <
> disaverio.and...@gmail.com> wrote:
>
>> I was able to restore all the data, doing as I planned: (i) the records
>> collected during the power outage have been recovered from davis data
>> logger, (ii) the subsequent records were already in the database but with
>> wrong dateTime, so I just fixed its value shifting it 118m in the future.
>> Then, as solid definitive solution for the future, I have also bought an
>> RTC module for the rasp.
>>
>> What is still puzzling me, is how is possible that the same wrong data
>> (the wrong time value) was in the davis datalogger as well, for all the
>> records in the period from after the power outage to the restoration of the
>> correct time.
>>
>>
>> Il giorno domenica 21 agosto 2022 alle 19:50:23 UTC+2 MikeQ ha scritto:
>>
>>> I have had a similar issue twice but not since January 2021.  I have my
>>> Davis console on wall power plus batteries, assuming the batteries would
>>> work like a UPS but that might not be reliable.
>>>
>>> Look at the weewx wiki:
>>>
>>> https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station#weewx-generates-html-pages-but-it-does-not-update-them
>>>
>>> I shut down weewx and inspected my database using DB Browser for SQLite
>>> on a desktop and there are no issues in the DB so clock slew was not my
>>> issue.
>>>
>>> If I follow the instructions in 'Corrupt station memory' using debug
>>> mode i see exactly the same results as the wiki shows with the DMPACT
>>> command indicating the download is complete while I still have 197 pages in
>>> the datalogger.
>>>
>>> Rebooting the console did not work for me and I had to use the dump &
>>> clear commands.  That resulted in the loss of records for a 25 minute
>>> period the last time around.
>>>
>>>
>>>
>>> On Saturday, August 20, 2022 at 4:46:11 PM UTC-6 disaveri...@gmail.com
>>> wrote:
>>>
>>>> Today I had a power outage, from the 06:01 CEST to the 07:51 CEST.
>>>> So the last record added by weewx before the outage was 

Re: [weewx-user] Re: Power outage without RTC module

[Paul R Anderson]

For hardware that supports WeeWx can set the onboard clock of the hardware.
In your case the davis data logger supports setting of its onboard clock.

This is controlled in the  [StdTimeSynch] section of weewx.config
I believe WeeWx ships with this as default:
##

#   For hardware that supports it, this section controls how often the
#   onboard clock gets updated.

[StdTimeSynch]

# How often to check the weather station clock for drift (in seconds)
clock_check = 14400

# How much it can drift before we will correct it (in seconds)
max_drift = 5

##
So unless you changed it most likely WeeWx set the davis datalogger
onboard clock, while your OS was running with the incorrect time.

On Mon, Aug 22, 2022 at 6:15 AM Andrea Di Saverio <
disaverio.and...@gmail.com> wrote:

> I was able to restore all the data, doing as I planned: (i) the records
> collected during the power outage have been recovered from davis data
> logger, (ii) the subsequent records were already in the database but with
> wrong dateTime, so I just fixed its value shifting it 118m in the future.
> Then, as solid definitive solution for the future, I have also bought an
> RTC module for the rasp.
>
> What is still puzzling me, is how is possible that the same wrong data
> (the wrong time value) was in the davis datalogger as well, for all the
> records in the period from after the power outage to the restoration of the
> correct time.
>
>
> Il giorno domenica 21 agosto 2022 alle 19:50:23 UTC+2 MikeQ ha scritto:
>
>> I have had a similar issue twice but not since January 2021.  I have my
>> Davis console on wall power plus batteries, assuming the batteries would
>> work like a UPS but that might not be reliable.
>>
>> Look at the weewx wiki:
>>
>> https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station#weewx-generates-html-pages-but-it-does-not-update-them
>>
>> I shut down weewx and inspected my database using DB Browser for SQLite
>> on a desktop and there are no issues in the DB so clock slew was not my
>> issue.
>>
>> If I follow the instructions in 'Corrupt station memory' using debug mode
>> i see exactly the same results as the wiki shows with the DMPACT command
>> indicating the download is complete while I still have 197 pages in the
>> datalogger.
>>
>> Rebooting the console did not work for me and I had to use the dump &
>> clear commands.  That resulted in the loss of records for a 25 minute
>> period the last time around.
>>
>>
>>
>> On Saturday, August 20, 2022 at 4:46:11 PM UTC-6 disaveri...@gmail.com
>> wrote:
>>
>>> Today I had a power outage, from the 06:01 CEST to the 07:51 CEST.
>>> So the last record added by weewx before the outage was at 06:01 CEST.
>>> From logs (reporting here only last two lines):
>>>
>>> pi@raspberrypi:~ $ journalctl -b -1
>>> Aug 20 06:01:14 raspberrypi python3[16243]: weewx[16243] INFO
>>> weewx.manager: Added record 2022-08-20 06:01:00 CEST (1660968060) to
>>> database 'weewx.sdb'
>>> Aug 20 06:01:14 raspberrypi python3[16243]: weewx[16243] INFO
>>> weewx.manager: Added record 2022-08-20 06:01:00 CEST (1660968060) to daily
>>> summary in 'weewx.s>
>>>
>>> When the power came back, the wifi was not available, so the raspberry's
>>> time (I have no RTC module) was automatically set to a previously recorded
>>> timestamp: 05:53:32 CEST (118 mins before real time).
>>> So when weewx re-started recording, it discarded first 8 samples and
>>> then started going. From logs:
>>>
>>> Aug 20 06:01:19 raspberrypi python3[600]: weewx[600] ERROR
>>> weewx.manager: Unable to add record 2022-08-20 05:54:00 CEST (1660967640)
>>> to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
>>> Aug 20 06:01:19 raspberrypi python3[600]: weewx[600] ERROR
>>> weewx.manager: Unable to add record 2022-08-20 05:55:00 CEST (1660967700)
>>> to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
>>> Aug 20 06:01:19 raspberrypi python3[600]: weewx[600] ERROR
>>> weewx.manager: Unable to add record 2022-08-20 05:56:00 CEST (1660967760)
>>> to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
>>> Aug 20 06:01:19 raspberrypi python3[600]: weewx[600] ERROR
>>> weewx.manager: Unable to add record 2022-08-20 05:57:00 CEST (1660967820)
>>> to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
>>> Aug 20 06:01:19 raspberrypi python3[600]: weewx[600] ERROR
>>> weewx.manager: Unable to add record 2022-08-20 05:58:00 CEST (1660967880)
>>> to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
>>> Aug 20 06:01:19 raspberrypi python3[600]: weewx[600] ERROR
>>> weewx.manager: Unable to add record 2022-08-20 05:59:00 CEST (1660967940)
>>> to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
>>> Aug 20 06:01:19 raspberrypi python3[600]: 

Re: [weewx-user] Re: WeeWX WebP image plot test

[Paul R Anderson]

Totally agree with Tom rsync is incredible if your hosted server supports
it try it, you'll never go back.
Spoiled here with fiber 300 Mbps upload and download here but here are
WeeWX rsync transfers for my site here 10 North of Boston Massachusetts, to
my host in Newark, NJ

Mar  8 10:30:25 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 34
files (259,081 bytes) in 0.60 seconds
Mar  8 10:35:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 39
files (1,431,654 bytes) in 0.65 seconds
Mar  8 10:40:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 34
files (259,557 bytes) in 0.65 seconds
Mar  8 10:45:23 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 36
files (278,303 bytes) in 0.58 seconds
Mar  8 10:50:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 39
files (1,431,670 bytes) in 0.66 seconds
Mar  8 10:55:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 34
files (259,994 bytes) in 0.62 seconds
Mar  8 11:00:24 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 45
files (296,208 bytes) in 0.63 seconds
Mar  8 11:05:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 39
files (1,431,828 bytes) in 0.66 seconds
Mar  8 11:10:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 34
files (259,759 bytes) in 0.61 seconds
Mar  8 11:15:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 34
files (260,131 bytes) in 0.66 seconds
Mar  8 11:20:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 39
files (1,431,817 bytes) in 0.64 seconds
Mar  8 11:25:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 34
files (260,418 bytes) in 0.61 seconds
Mar  8 11:30:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 34
files (260,343 bytes) in 0.61 seconds
Mar  8 11:35:22 webserver weewx[18755] INFO weeutil.rsyncupload: rsync'd 39
files (1,432,512 bytes) in 0.64 seconds

On Tue, Mar 8, 2022 at 11:13 AM Tom Keffer  wrote:

> About 10 years ago, I switched to rsync and was astonished at how much
> faster it is. Maybe an order of magnitude! It completely solved my upload
> problem.
>
>
> On Tue, Mar 8, 2022 at 7:33 AM Tom Hogland  wrote:
>
>> It does serve a purpose. My Vantage Pro is in my yard and weewx is in my
>> basement, but my webpage to display it is hosted in a datacenter somewhere
>> far, far away, so I have to sftp it there. A full batch of data uploading
>> typically takes almost a minute to go, besides the overhead, connection
>> time, etc. and the time weewx takes to do all it's processing. Since that
>> happens every 5 minutes, it's not impossible for my 5-minute workload to
>> overlap the next 5 minute interval.  If I can reduce it, then everything
>> works better.
>>
>> Tom
>> http://www.alaskatech.org/weewx/index.html
>>
>> On Tue, Mar 8, 2022 at 1:58 AM Paul R Anderson  wrote:
>>
>>> Strange state of support for WebP that's for sure. Wish it was 100%
>>> supported but it's not. Was just on a quest , for no good reason, to reduce
>>> the download size of my main index.html file. It's been a fun learning
>>> experience. Reduced page download size from around 450kB to  70kb , and
>>> request from 45 to 15. In today's world of fast unlimited internet
>>> connections it serves little purpose I guess, other than reducing server
>>> load and page load time by a small amount.
>>>
>>> Thanks
>>> Paul
>>>
>>> --
>> 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/CAMwKJErNwkUektGgYrw%3DVQPMbGqTUKxwHrcBx%3DJZVhvH4yb7iw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/weewx-user/CAMwKJErNwkUektGgYrw%3DVQPMbGqTUKxwHrcBx%3DJZVhvH4yb7iw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAPq0zEC8BLBrxqieuE9F5MC2ZW5-CL-v3Ap5vvv%2BwhSyn6PJKA%40mail.gmail.com
> <https://groups.google.com/d/msgid/weewx-user/CAPq0zEC8BLBrxqieuE9F5MC2ZW5-CL-v3Ap5vvv%2BwhSyn6PJKA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAOAVAecbp3W%3Drsm2N1xN7iiPXyU%2BGY2HUOCRiGm4tja3M1ECXQ%40mail.gmail.com.

[weewx-user] Seasons skin woff2 font type fix

[Paul R Anderson]

I've created issue #760
 to look into
getting Seasons skin to use woff2 fonts. Currently all websites running
WeeWX with default Seasons skin use woff font type.
Just mentioning here because on Github my id is my ham radio call N1OTX
rather than myname. Wanted everyone to know who to blame.
Thanks
Paul

-- 
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/CAOAVAedwRhpQkSqWBuHELn7zJhGSXAiXkpb9R1rX5qRtrWtP9w%40mail.gmail.com.

Re: [weewx-user] Re: WeeWX WebP image plot test

[Paul R Anderson]

Strange state of support for WebP that's for sure. Wish it was 100%
supported but it's not. Was just on a quest , for no good reason, to reduce
the download size of my main index.html file. It's been a fun learning
experience. Reduced page download size from around 450kB to  70kb , and
request from 45 to 15. In today's world of fast unlimited internet
connections it serves little purpose I guess, other than reducing server
load and page load time by a small amount.

Thanks
Paul

On Mon, Mar 7, 2022 at 1:14 PM vince  wrote:

> Looks ok if I use chrome on the same iPad.
>
> --
> 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/dce97591-4519-4736-a30c-66182a8ac433n%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/CAOAVAefTyicKxSk%3DdY5noaTCPe_Sj1j9OnUTnn50OPCO-fFLJQ%40mail.gmail.com.

Re: [weewx-user] Re: WeeWX WebP image plot test

[Paul R Anderson]

Hi Vince,
Thanks for trying. So I see from the can I use site that Safari is a
problem for sure.
 15.3 - Partial support in Safari  limited to macOS 11 Big Sur and later
So there's that. :)
Thanks,
Paul

On Sat, Mar 5, 2022 at 11:57 AM vince  wrote:

> I get no images shown in Safari 15.3 on an Intel MacBook Air.
>
> --
> 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/1a681fa7-a449-4311-aa8e-ee38c51d4134n%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/CAOAVAecLLFCZchCCN_CAJsjKFDd_TCZtuuQVe%2BBRTU9hzONgUA%40mail.gmail.com.

Re: [weewx-user] WeeWX WebP image plots should they be an option?

[Paul R Anderson]

Hi Tom,
Glad you like the idea. Really impressed with the file size and image
quality using WebP.
Only had to hack two changes to imagegenerator.py
Change hard coded  '%s.png'  'to  '%s.webp'
And because I needed to pass in a option
# Now save the image
image.save(img_file,lossless = True)
ngen += 1
Sorry for duplicate messages, sometimes google groups hates me and blocks
my post :)

Thanks,
Paul







On Fri, Mar 4, 2022 at 5:57 PM Tom Keffer  wrote:

> I like this idea.
>
> I've created issue #758   to
> look into allowing user-selectable formats.
>
> On Fri, Mar 4, 2022 at 2:45 PM pa...@pauland.net  wrote:
>
>> What is WebP
>>
>> WebP is an image file format that Google developed in 2010
>>
>> Google Says:
>>
>> "WebP is a modern image format that provides superior lossless and lossy
>> compression for images on the web. Using WebP, webmasters and web
>> developers can create smaller, richer images that make the web faster"
>>
>> Sounds great but the web has been slow to support WebP images in desktop
>> and mobile browsers. At this point in 2022 according to data at
>> https://caniuse.com/webp about 95% of user devices support it.
>>
>> So I decided to try to have WeeWX produce all plot images in WebP format
>> rather than png. Results were impressive, image size was reduced by roughly
>> 50% , and I can't see any noticeably difference in image quality.
>>
>> Switched my website to all WebP  images a few days ago, and no ones
>> complaining, but it doesn’t get much traffic.
>>
>> Would really appreciate it if you take a look at my site , and let me
>> know if you have difficulties viewing the images, and your comments on
>> image quality.
>>
>> https://pauland.net
>>
>> Thanks,
>>
>> Paul
>>
>> --
>> 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/cf52ee8e-65a1-403b-8d4d-dde3670403d8n%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/CAPq0zEC2kNdEsypZah-6Wv1ci94DFd9eoU1_a8tSf_V819aUUw%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/CAOAVAedCjkEPtgfnaAVJEJmxs%2BZZhMTyqzBQohpXbsiy0qXPdQ%40mail.gmail.com.

[weewx-user] WeeWX WebP image plot test

[Paul R Anderson]

 What is WebP ?

An image format developed by Google in 2010. Quote from Google “WebP is a
modern image format that provides superior lossless and lossy compression
for images on the web. Using WebP, webmasters and web developers can create
smaller, richer images that make the web faster.” WebP adoption has been
slow but as of now in 2022 it appears that around 95% of user devices such
as desktop PC’s and phones support the file format. One article here has
some data on supporting browsers https://caniuse.com/webp

Given the adoption rate I thought it was time to see if WeeWX could produce
plots in WebP format. It was very easy to get WeeWX to produce WebP format
plots. Results were an average file size reduction of 50% percent, with
little if any discernible image quality differences.

Been using only WebP plot images on my very low traffic website for a few
days and haven’t heard any complaints. Would love if you could take some to
try to view the site and let me know of any browser, device issues. Also
what you think of image quality, to me they look like normal WeeWX plots.

Site:

https://pauland.net

Thank You,

Paul

-- 
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/CAOAVAeep0DWakf-8%3DDxNy7P%2BSmus6b2LD3Tp3EsCnfyRhcLFAA%40mail.gmail.com.

Re: [weewx-user] Re: Belchertown skin - large rsync uploads?

[Paul R Anderson]

If I understand correctly you're concerned about exceeding your monthly
bandwidth of your web host. On some web hosts only outbound data transfer
in excess of your plan's data transfer allowance is subject  to overage
charges. Your rsync uploads from the local host to the web server would not
count toward your limit. I know this to be true with AWS Lightsail, and
Linode. Both AWS and Linode have plans for $5.00 a month that might be
enough to host your site.
Thanks,
Paul

On Fri, Feb 4, 2022 at 8:20 AM gszla...@gmail.com 
wrote:

> Thanks vince. You are right - all my sensors update every 60 seconds
> except the anemometer which is every 16.5 secs so for "realtime",  I chose
> 20 secs. However I expected rsync to upload only the file differences
> rather than re-copying the entire local skin. I think the whole template
> as-is without adding any extra graphs - is about 1.2 MB to 1.3 MB. Rsync is
> uploading the whole she-bang at a time. Definitely "heavy" on resources
> when you add a few instances of weewx and a bunch of weather templates plus
> GW1000 custom upload.(realtime)...Not complaining though..rsync is still
> the way to go. Many thanks for all the suggestions and
> recommendations..much appreciated!
>
> On Thursday, February 3, 2022 at 7:18:33 PM UTC-5 vince wrote:
>
>> rsync syncs whatever you have it configured to sync and does so every
>> archive interval.
>>
>> A 20-second archive interval is very quick especially since your ecowitt
>> gear only changes readings once per minute probably for most of the
>> readings other than wind.   You might want to look into the websockets
>> setup for Belchertown if you are looking for realtime updates.
>>
>> FWIW - mine rsyncs a bit under 3 MB every 5-minute period but I have a
>> lot of skins and images to upload.
>>
>> You could probably get there via a cron entry that runs less often if you
>> wanted to dial back how often you rsync, assuming you turned it off in
>> weewx of course.
>>
>> --
> 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/1e0ea0d2-cb84-4e25-82f9-610fae5c4d98n%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/CAOAVAed3vB3fLZqiNJbtPqgXd_dF5FAmQEANLMi-1CfRvCd%2BXw%40mail.gmail.com.

Re: [weewx-user] Weatherlink IP no function

[Paul R Anderson]

Hello Herbert,
My choice would be the USB Data Logger . Because the Raspberry PI , and
many other modern computers,does not have a COMM port, you would have to
add a COMM port or use a SERIAL to USB adapter. Many years ago the Davis
USB Data Logger seemed to have issues and it seemed better to get SERIAL,
even if you had to add a SERIAL to USB adapter. Thankfully nowadays the
Davis USB Data Logger seems very reliable, and much more versatile for use
with modern computers lacking COMM ports.
2 Years ago I replaced a complete 13 Year old  VP PRO system with a serial
data logger, with a new VP Pro  with a USB data logger. I have had
absolutely no problem whatsoever with the USB Data Logger.
Thanks,
Paul

On Tue, Apr 20, 2021 at 10:27 AM Herbert Eberhardt 
wrote:

> Hallo, after many years the Weatherlink IP no function, no LED, no answer.
> I tried many time to plug off and on, wait 30min and more.
>
> I have a Vantage Pro 2 and use an Raspberry Pi for weewx.
>
> I have to buy a new communication port, the Weatherlink IP ist old and not
> avvailable.
>
> I see the Davis Datenlogger LIVE 6100, the Davis WeatherLink Datenlogger
> 6510 Seriell Software PC COM-Port
> 
>  and Davis Weatherlink Datenlogger 6510 USB Software PC
> 
>
> which is the best choice?
>
>
> --
> 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/38f80755-2d3e-43f5-9d06-3df5288614ben%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/CAOAVAedZTNjBr%3DJYsF6KQKwTBPxWjfHYFGBLz1MG5A%2B8UgJEiw%40mail.gmail.com.

Re: [weewx-user] Re: Beta of V4.5.0 available

[Paul R Anderson]

Hi Tom
Verified that when adding a column it now gets created with the backquotes.
The 2nd issue that I mentioned was that when renaming a column it gets
renamed to a  name enclosed in double quotes.

So when running my example of adding  a column named addedcolumn,  and
renaming column heatindex to renamedheatindex we get:
sqlite> .schema archive
CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY,
`usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `altimeter` REAL,
`barometer` REAL, `dewpoint` REAL, `ET` REAL, "renamedheatindex" REAL,
`addedcolumn`
REAL);

I tried modifying line 478 manager.py from:
cursor.execute("ALTER TABLE %s RENAME COLUMN %s TO %s"
to:
cursor.execute("ALTER TABLE %s RENAME COLUMN %s TO `%s`"
But that made no difference, wish I had better python skills!
Thanks,
Paul





On Sat, Mar 27, 2021 at 9:13 AM Tom Keffer  wrote:

> When the database is created, the column names are put in backquotes. This
> is because, under MySQL, the name "interval" is a reserved keyword, so it
> must be "escaped" with backquotes.
>
> However, when adding a column, the name is not put in backquotes.
>
> I've changed the "add column" code to include the backquotes. Hopefully,
> the results will be consistent now!
>
> commit 2e7f146
> <https://github.com/weewx/weewx/commit/2e7f146eff654ed64a51ed854f71ba27e0b204cb>
>
>
>
> On Fri, Mar 26, 2021 at 8:12 AM Paul R Anderson  wrote:
>
>> Column naming curiosity
>>
>> Tried the add, and rename columns feature of the wee_database utility.
>> Both seemed to work fine, however I noticed a peculiarity in the column
>> names that were renamed, or created .
>> Normally a sqlite3 query of .schema archive shows ALL column names
>> surrounded by what seems to be the U+0060 GRAVE ACCENT Character.
>> However a sqlite3 query after --rename-column shows the added column
>> surrounded by double quotes.
>> Also a sqlite3 query after --add-column shows a naked column name not
>> surrounded at all?
>> Please note that what I perceive as a column naming peculiarity, seems to
>> have no noticeable effect on the database, it functions normally.
>> My wild speculation is that there's an inconsistency between handing of
>> string to unicode in the table create and new add column rename column
>> function.
>> Spied this in /weedb/sqlite.py
>>  # Extract the table name. Sqlite returns unicode, so always
>>  # convert to a regular string:
>>
>> I am sure this is hard to follow, so here is an outline of my test
>> methodology hopefully it helps,and doesn't make it more confusing!
>>
>> Let WeeWx create new database with a few fields using wview_small.py
>> reduced to these fields:
>>
>> table = [('dateTime', 'INTEGER NOT NULL UNIQUE PRIMARY KEY'),
>>  ('usUnits',  'INTEGER NOT NULL'),
>>  ('interval', 'INTEGER NOT NULL'),
>>  ('altimeter','REAL'),
>>  ('barometer','REAL'),
>>  ('dewpoint', 'REAL'),
>>  ('ET',   'REAL'),
>>  ('heatindex','REAL'),
>>  ]
>>
>> *sqlite3 query of .schema archive after database creation*
>>
>> sqlite> .schema archive
>> CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY,
>> `usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `altimeter` REAL,
>> `barometer` REAL, `dewpoint` REAL, `ET` REAL, `heatindex` REAL);
>>
>> *** Note what seems to be the U+0060 GRAVE ACCENT Character surrounding
>> the column names.
>>
>> Rename heatindex to renamedheatindex
>> wee_database --rename-column=heatindex --to-name=renamedheatindex
>> Added addedcolumn
>> wee_database --add-column=addedcolumn
>>
>> sqlite3 query of .schema archive after the Rename and add column operation
>>
>> sqlite> .schema archive
>> CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY,
>> `usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `altimeter` REAL,
>> `barometer` REAL, `dewpoint` REAL, `ET` REAL, "renamedheatindex" REAL,
>> addedcolumn REAL);
>>
>> *** Note the name of the renamedheatindex column is surrounded by double
>> quotes, and the added column addedcolumn isn't surrounded by anything.
>> Thanks!
>> Paul
>>
>> On Thu, Mar 25, 2021 at 9:12 PM Tom Keffer  wrote:
>>
>>> Well, MySQL calls it "DROP COLUMN." SQLite doesn't offer it at all.
>>>
>>> Rather than invent new terminology, I'd like to stick with what

Re: [weewx-user] Re: Beta of V4.5.0 available

[Paul R Anderson]

Column naming curiosity

Tried the add, and rename columns feature of the wee_database utility. Both
seemed to work fine, however I noticed a peculiarity in the column names
that were renamed, or created .
Normally a sqlite3 query of .schema archive shows ALL column names
surrounded by what seems to be the U+0060 GRAVE ACCENT Character.
However a sqlite3 query after --rename-column shows the added column
surrounded by double quotes.
Also a sqlite3 query after --add-column shows a naked column name not
surrounded at all?
Please note that what I perceive as a column naming peculiarity, seems to
have no noticeable effect on the database, it functions normally.
My wild speculation is that there's an inconsistency between handing of
string to unicode in the table create and new add column rename column
function.
Spied this in /weedb/sqlite.py
 # Extract the table name. Sqlite returns unicode, so always
 # convert to a regular string:

I am sure this is hard to follow, so here is an outline of my test
methodology hopefully it helps,and doesn't make it more confusing!

Let WeeWx create new database with a few fields using wview_small.py
reduced to these fields:

table = [('dateTime', 'INTEGER NOT NULL UNIQUE PRIMARY KEY'),
 ('usUnits',  'INTEGER NOT NULL'),
 ('interval', 'INTEGER NOT NULL'),
 ('altimeter','REAL'),
 ('barometer','REAL'),
 ('dewpoint', 'REAL'),
 ('ET',   'REAL'),
 ('heatindex','REAL'),
 ]

*sqlite3 query of .schema archive after database creation*

sqlite> .schema archive
CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY,
`usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `altimeter` REAL,
`barometer` REAL, `dewpoint` REAL, `ET` REAL, `heatindex` REAL);

*** Note what seems to be the U+0060 GRAVE ACCENT Character surrounding the
column names.

Rename heatindex to renamedheatindex
wee_database --rename-column=heatindex --to-name=renamedheatindex
Added addedcolumn
wee_database --add-column=addedcolumn

sqlite3 query of .schema archive after the Rename and add column operation

sqlite> .schema archive
CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY,
`usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `altimeter` REAL,
`barometer` REAL, `dewpoint` REAL, `ET` REAL, "renamedheatindex" REAL,
addedcolumn REAL);

*** Note the name of the renamedheatindex column is surrounded by double
quotes, and the added column addedcolumn isn't surrounded by anything.
Thanks!
Paul

On Thu, Mar 25, 2021 at 9:12 PM Tom Keffer  wrote:

> Well, MySQL calls it "DROP COLUMN." SQLite doesn't offer it at all.
>
> Rather than invent new terminology, I'd like to stick with what's already
> in use.
>
> On Thu, Mar 25, 2021 at 1:26 PM vince  wrote:
>
>> oops - I meant 'drop-field' and 'rebuild-field' there of course in the
>> last paragraph...intent was to handle the case where somebody doesn't want
>> to drop all summary tables, just the one matching the field they cleaned up
>> in the archive table.
>>
>> On Thursday, March 25, 2021 at 12:17:15 PM UTC-7 vince wrote:
>>
>>> I know 'drop' is a database term, but I'm wondering if --delete-column
>>> might be better wording here generically.
>>>
>>> We have drop-daily and rebuild-daily for dealing with summary tables, so
>>> I'm thinking maybe the terminology meaning different things in different
>>> context might be confusing.  Just a thought.
>>>
>>> Similarly, we have lots of cases where folks get bad data in their
>>> archive for rain/whatever and need to clean those items up.  Is there a
>>> "drop-field" or "rename-field" or the like to help people drop/rebuild just
>>> the summary tables for a particular database element ?   Apologies if that
>>> already exists...
>>>
>>>
>>> On Wednesday, March 24, 2021 at 2:10:23 PM UTC-7 Tom Keffer wrote:
>>>
 Several interesting new features. Most notably, you can add, remove, or
 rename columns in the main database with the utility wee_database. No need
 to use --reconfigure with all the database shuffling involved! For
 example, to remove the type soilMoist2:

 wee_database --drop-columns=soilMoist2


 If you use this feature, remember that this is a beta release. Be sure
 to do a backup first!!

 There is also support for using *series* in the templates, including
 generating JSON. For example, a JSON series of the maximum temperature for
 each day of the month would be:

 $month.outTemp.series(aggregate_type='max',
 aggregate_interval='day').json


 This generates something like:

 [[1614585600, 1614672000, 58.2], [1614672000, 1614758400, 55.8],
 [1614758400, 1614844800, 59.6], ... ]


 This is a series of 3-way tuples, where each tuple consists of the
 start time of the day, stop time of the day, and (in this case) 

Re: [weewx-user] Re: Vantage Pro suddenly stopped working

[Paul R Anderson]

Per Tom's answer of Corrupt station memory...
You mentioned issue began at " 3 A.M.  the other morning" Daylight Saving
Time in most of the US began on Sunday, March 14, 2021 at 2:00 A.M wonder
if some weird issue may have happen due when your system clock jumping
forward. Note that normally WeeWX handles this just fine :)

On Wed, Mar 17, 2021 at 9:19 AM Tom Keffer  wrote:

> No need. This is pretty clearly a case of memory corruption on the logger.
> The clue is
>
> Mar 16 07:04:29 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
> Retrieving 513 page(s); starting index= 1
> Mar 16 07:04:29 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
> DMPAFT complete: page timestamp 2021-02-26 11:30:00 PST (1614367800) less
> than final timestamp 2021-03-14 03:00:00 PDT (1615716000)
>
> It asks for 513 pages, then proceeds to get ... nothing.
>
> See the section *Corrupt station memory
> *
>  for
> how to clear the logger.
>
> -tk
>
> On Tue, Mar 16, 2021 at 2:17 PM gjr80  wrote:
>
>> Hi,
>>
>> I suggest you edit weewx.conf, set debug = 2, save weewx.conf and restart
>> WeeWX. Let WeeWX run for a few archive periods and then take an extract
>> from the log covering the entire WeeWX startup through until the few
>> archive periods have passed. It’s important to get the entire startup
>> sequence as it has important config info. Post the log extract here and we
>> can see exactly what is (or is not) happening. If you need help obtaining
>> and posting the log extract you might find the Help! posting to
>> weewx-user
>>  wiki
>> article helpful.
>>
>> Gary
>> On Wednesday, 17 March 2021 at 00:10:30 UTC+10 ksmol...@gmail.com wrote:
>>
>>> After years and years, at 3am the other morning my Vantage Pro stopped
>>> posting to CWOP.I've done all the usual, reboot PC, replace the
>>> USB-Serial cable, still nothing.   Not sure how else to troubleshoot, the
>>> logs "look like" it's reading data from the unit.   Any help appreciated.
>>>
>>> Mar 16 07:04:27 pvweatherbox weewx[7369] INFO __main__: Starting up
>>> weewx version 4.1.0
>>> Mar 16 07:04:27 pvweatherbox weewx[7369] DEBUG weewx.manager: Daily
>>> summary version is 2.0
>>> Mar 16 07:04:27 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> Gentle wake up of console successful
>>> Mar 16 07:04:27 pvweatherbox weewx[7369] INFO weewx.engine: Clock error
>>> is 0.13 seconds (positive is fast)
>>> Mar 16 07:04:27 pvweatherbox weewx[7369] INFO weewx.engine: Using
>>> binding 'wx_binding' to database 'weewx.sdb'
>>> Mar 16 07:04:27 pvweatherbox weewx[7369] INFO weewx.manager: Starting
>>> backfill of daily summaries
>>> Mar 16 07:04:27 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> Getting archive packets since 2021-03-14 03:00:00 PDT (1615716000)
>>> Mar 16 07:04:27 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> Gentle wake up of console successful
>>> Mar 16 07:04:29 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> Retrieving 513 page(s); starting index= 1
>>> Mar 16 07:04:29 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> DMPAFT complete: page timestamp 2021-02-26 11:30:00 PST (1614367800) less
>>> than final timestamp 2021-03-14 03:00:00 PDT (1615716000)
>>> Mar 16 07:04:29 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> Catch up complete.
>>> Mar 16 07:04:29 pvweatherbox weewx[7369] INFO weewx.engine: Starting
>>> main packet loop.
>>> Mar 16 07:04:29 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> Gentle wake up of console successful
>>> Mar 16 07:04:29 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> Requesting 200 LOOP packets.
>>> Mar 16 07:04:29 pvweatherbox weewx[7369] DEBUG weewx.drivers.vantage:
>>> Gentle wake up of console successful
>>>
>>> --
>> 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/7790cbaa-9f25-4091-bee8-f721cd363b6fn%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/CAPq0zEDBDM-FrhM03_TSnktyoqhbZ9G1HivDGdqvJAYR5pweAg%40mail.gmail.com
> 
> .
>

-- 
You 

Re: [weewx-user] Ecowitt WH55 leak detector

[Paul R Anderson]

Hi Gary,
Just installed a WH55 leak detector yesterday. I have GW1000 driver
Version: 0.2.0 running with WeeWX Version: 4.3.0. More than happy to help,
let me know what I can do.

Thanks,
Paul

On Sun, Jan 10, 2021 at 1:37 AM gjr80  wrote:

> Was hoping to find somebody who has a WH55 connected to a GW1000 that
> could obtain some raw WH55 data from the GW1000 to help me tidy up a few
> things in the GW1000 driver. You don't need to be running the GW1000 driver
> with WeeWX but you do need to have WeeWX 3.7.0 or later installed and would
> have to run the GW1000 WeeWX driver directly (independent to WeeWX and
> without the need to stop WeeWX if it is running).
>
> If anyone can help please post back here.
>
> thanks,
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/c2b9540f-7c87-4266-95a6-464e7b61901dn%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/CAOAVAeeOm9zKfdFMUreLhyOOEgC_Wak2Z-SNZcxeC%2BApxrj7hg%40mail.gmail.com.

Re: [weewx-user] Data Precision for Dewpoint

[Paul R Anderson]

For more info on loop2 the davis portal document
<https://www.davisinstruments.com/support/weather/download/VantageSerialProtocolDocs_v261.pdf>
is
the definitive word on the fields and their definition.
Forgot that I have a little test file that shows what you get from Loop2:

ALL LOOP2 DATA
trendIcon -20.00
barometer 29.913 inHg
inTemp 73.8F
inHumidity 63%
outTemp 65.1F
windSpeed 1 mph
windDir 338
windSpeed10 2 mph
windSpeed2 2.00
windGust10 0.90
windGustDir10 67.00
dewpoint 62.0F
outHumidity 89%
heatindex 66.0F
windchill 65.0F
THSW 64.0F
rainRate 0.00 in/h
UV 0.0
radiation 0 W/m
stormRain 0.00 in
stormStart ?'stormStart'?
dayRain 0.00 in
rain15 0.00
hourRain 0.00 in
dayET 0.038000
rain24 0.00 in
bar_reduction 0.002000
bar_offset 0.028000
bar_calibration 17.606000
pressure_raw 29.716000
pressure 29.744 inHg
altimeter 29.918 inHg

Paul

On Sun, Aug 16, 2020 at 8:06 PM Paul R Anderson  wrote:

> Alternative method would be to set Vantage driver loop_request to 3 so
> that you would get loop1 and loop2 data. Vantage loop2 provides dewpoint to
> 1 decimal point . Please review User Guide
> <http://www.weewx.com/docs/usersguide.htm#[Vantage]> and be sure you
> understand how to set it up , further changes are required.
>
> On a system here that is set up to alternate loop1 and loop2 here is a
> database query for dewpoint:
>
> sqlite> select datetime(dateTime,'unixepoch','localtime'),dewpoint from
> archive ORDER BY datetime desc limit 10;
> 2020-08-16 20:00:00|62.0
> 2020-08-16 19:55:00|62.0
> 2020-08-16 19:50:00|62.0
> 2020-08-16 19:45:00|62.0
> 2020-08-16 19:40:00|62.0
> 2020-08-16 19:35:00|62.0
> 2020-08-16 19:30:00|62.0
> 2020-08-16 19:25:00|62.0
> 2020-08-16 19:20:00|62.0
> 2020-08-16 19:15:00|62.0
>
> Paul
>
> On Sun, Aug 16, 2020 at 7:24 PM Tom Keffer  wrote:
>
>> Archive records are what are stored in the database. A Vantage station
>> produces its own archive record (unless record_generation is set to
>> 'software'). However, for whatever reason, Vantage stations do not include
>> dewpoint in the hardware generated record, so WeeWX must calculate it. By
>> default, WeeWX calculates the average dewpoint seen over the archive
>> interval. If dewpoint changes over the interval, the average is not
>> necessarily an even number.
>>
>> One way around this is to have WeeWX calculate the last value seen,
>> instead of the average. Add this to the end of your weewx.conf file:
>>
>> [Accumulator]
>>   [[dewpoint]]
>> extractor = last
>>
>> Alternatively, what sort of external programs are you writing? Does the
>> language you are using provide a way to format decimal output?
>>
>> -tk
>>
>>
>> On Sun, Aug 16, 2020 at 3:16 PM satwa...@gmail.com 
>> wrote:
>>
>>> Hi,
>>>
>>> I searched the group for this subject and couldn't find anything so I am
>>> posting.
>>>
>>> I have the Vantage Pro 2, serial interface to Weewx 3.9.2 run on an
>>> Ubuntu server.
>>>
>>> Below is a sample line from the archive database (broke into individual
>>> lines due to width) using the command:
>>>sqlite3 -header -csv /var/lib/weewx/weewx.sdb "select * from archive;"
>>>
>>> One line from the output:
>>> 1597612740,1,1,29.617,28.0238601652778,29.7814033867068,83.7,*115.4*,
>>> 38.0,18.0,0.0,,1.0,225.0,0.0,0.0,*61.1737982063856*,115.4,
>>> 115.4,0.093.95833,0.0,5.31,,
>>>
>>> Note the temperature is reported as 115.4 degs (ugh...this is Arizona).
>>> The dewpoint is reported as 61.1737982063856.  All dewpoint values in the
>>> database have a decimal precision of 13 places, clearly outside the sensor
>>> quality range. The sensor documentation indicates that it provides Relative
>>> Humidity values so apparently the console software derives the dewpoint
>>> value as it can be displayed on the console. I write a lot of external
>>> programs and have to repeatedly reduce the precision for this variable.
>>>
>>> Is there an easy way to modify my Weewx to store only 1 decimal place
>>> for dewpoint or other variables?  I did check /etc/weewx/weewx.conf and
>>> could not find any obvious setting for this.
>>>
>>> Thanks for any assistance,
>>>
>>> Ken
>>>
>>> --
>>> 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...@googleg

Re: [weewx-user] Data Precision for Dewpoint

[Paul R Anderson]

Alternative method would be to set Vantage driver loop_request to 3 so that
you would get loop1 and loop2 data. Vantage loop2 provides dewpoint to 1
decimal point . Please review User Guide
 and be sure you
understand how to set it up , further changes are required.

On a system here that is set up to alternate loop1 and loop2 here is a
database query for dewpoint:

sqlite> select datetime(dateTime,'unixepoch','localtime'),dewpoint from
archive ORDER BY datetime desc limit 10;
2020-08-16 20:00:00|62.0
2020-08-16 19:55:00|62.0
2020-08-16 19:50:00|62.0
2020-08-16 19:45:00|62.0
2020-08-16 19:40:00|62.0
2020-08-16 19:35:00|62.0
2020-08-16 19:30:00|62.0
2020-08-16 19:25:00|62.0
2020-08-16 19:20:00|62.0
2020-08-16 19:15:00|62.0

Paul

On Sun, Aug 16, 2020 at 7:24 PM Tom Keffer  wrote:

> Archive records are what are stored in the database. A Vantage station
> produces its own archive record (unless record_generation is set to
> 'software'). However, for whatever reason, Vantage stations do not include
> dewpoint in the hardware generated record, so WeeWX must calculate it. By
> default, WeeWX calculates the average dewpoint seen over the archive
> interval. If dewpoint changes over the interval, the average is not
> necessarily an even number.
>
> One way around this is to have WeeWX calculate the last value seen,
> instead of the average. Add this to the end of your weewx.conf file:
>
> [Accumulator]
>   [[dewpoint]]
> extractor = last
>
> Alternatively, what sort of external programs are you writing? Does the
> language you are using provide a way to format decimal output?
>
> -tk
>
>
> On Sun, Aug 16, 2020 at 3:16 PM satwa...@gmail.com 
> wrote:
>
>> Hi,
>>
>> I searched the group for this subject and couldn't find anything so I am
>> posting.
>>
>> I have the Vantage Pro 2, serial interface to Weewx 3.9.2 run on an
>> Ubuntu server.
>>
>> Below is a sample line from the archive database (broke into individual
>> lines due to width) using the command:
>>sqlite3 -header -csv /var/lib/weewx/weewx.sdb "select * from archive;"
>>
>> One line from the output:
>> 1597612740,1,1,29.617,28.0238601652778,29.7814033867068,83.7,*115.4*,
>> 38.0,18.0,0.0,,1.0,225.0,0.0,0.0,*61.1737982063856*,115.4,
>> 115.4,0.093.95833,0.0,5.31,,
>>
>> Note the temperature is reported as 115.4 degs (ugh...this is Arizona).
>> The dewpoint is reported as 61.1737982063856.  All dewpoint values in the
>> database have a decimal precision of 13 places, clearly outside the sensor
>> quality range. The sensor documentation indicates that it provides Relative
>> Humidity values so apparently the console software derives the dewpoint
>> value as it can be displayed on the console. I write a lot of external
>> programs and have to repeatedly reduce the precision for this variable.
>>
>> Is there an easy way to modify my Weewx to store only 1 decimal place for
>> dewpoint or other variables?  I did check /etc/weewx/weewx.conf and could
>> not find any obvious setting for this.
>>
>> Thanks for any assistance,
>>
>> Ken
>>
>> --
>> 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/20d1b87c-afd9-4f1c-b00c-88f9011057d8n%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/CAPq0zEBuz-FwYAt2z6YT4mZ39WipiBhLny4zwnbd3FZYkRci1Q%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/CAOAVAecvOtnCNZA37B9H37qhUTj%3D3MeejoMG1mCDh_9ouXDrTA%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Paul R Anderson]

It's a beautiful day!
Verified backed out my silly mod and tis works perfectly:

# Options for extension 'GW1000'
[GW1000]
driver = user.gw1000
[[field_map]]
inTemp = intemp
inHumidity = inhumid
pressure = absbarometer
dateTime = datetime
extraTemp2 = temp2
extraTemp3 = temp3
extraTemp4 = temp4
extraTemp5 = temp5
extraHumid2 = humid2
extraHumid3 = humid3
extraHumid4 = humid4
extraHumid5 = humid5
lightning_distance = lightningdist
lightning_last_det_time = lightningdettime
lightning_strike_count = lightning_strike_count
wh31_ch2_batt = wh31_ch2_batt
wh31_ch3_batt = wh31_ch3_batt
wh31_ch4_batt = wh31_ch4_batt
wh31_ch5_batt = wh31_ch5_batt
wh57_batt = wh57_batt
##
[Accumulator]
[[lightning_strike_count]]
extractor = sum
[[lightning_last_det_time]]
extractor = last
[[lightning_distance]]
extractor = last
[[wh31_ch2_batt]]
extractor = last
[[wh31_ch3_batt]]
extractor = last
[[wh31_ch4_batt]]
extractor = last
[[wh31_ch5_batt]]
extractor = last
[[wh57_batt]]
extractor = last
Gary sorry to be a pain in the neck, and big thank you for all your hard
work,

Paul

On Mon, Aug 3, 2020 at 5:59 PM Paul Anderson  wrote:

> Duh sorry I missed your point Gary! So all I have to do is move my fields
> from battery field map up to field map in weeex.conf and all will be.
> Sorry sometimes I can't see the forest for the trees.
>
> --
> 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/ae7bf7f2-44c1-4e1f-ba4f-49b92a405685o%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/CAOAVAee2nWi-hA1bOrDq1V%2B1A_ytX00LXPE8B3CXbbgQasKh9w%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Paul R Anderson]

Hi Gary,
So I guess I'm a perdoid control freak but when run as a service it's just
to supplement data provided by my normal driver, and other services. I get
paranoid over what the service has the ability to map too. Because I only
have 4 WH31 , 1 WH 57, and the Gw 1000 itself it is way easier to tell it
what I want versus what I don't want. Owning the mapping and being able to
keep it in weewx.config is exactly what I want. However without the
modification I suggested no battery_field_map is loaded from weewx.conf or
the driver code.
So with this in weewx.conf

[GW1000]
driver = user.gw1000

[[field_map]]
inTemp = intemp
inHumidity = inhumid
pressure = absbarometer
dateTime = datetime
extraTemp2 = temp2
extraTemp3 = temp3
extraTemp4 = temp4
extraTemp5 = temp5
extraHumid2 = humid2
extraHumid3 = humid3
extraHumid4 = humid4
extraHumid5 = humid5
lightning_distance = lightningdist
lightning_last_det_time = lightningdettime
lightning_strike_count = lightning_strike_count

[[battery_field_map]]
   wh31_ch2_batt = wh31_ch2_batt
   wh31_ch3_batt = wh31_ch3_batt
   wh31_ch4_batt = wh31_ch4_batt
   wh31_ch5_batt = wh31_ch5_batt
   wh57_batt = wh57_batt
[Accumulator]
[[lightning_strike_count]]
extractor = sum
[[lightning_last_det_time]]
extractor = last
[[lightning_distance]]
extractor = last
[[wh31_ch2_batt]]
extractor = last
[[wh31_ch3_batt]]
extractor = last
[[wh31_ch4_batt]]
extractor = last
[[wh31_ch5_batt]]
extractor = last
[[wh57_batt]]
extractor = last

No battery_field_map is applied at all.
 The other point of concern is over blindly pasting the full  [Accumulator]
stanza into weewx.conf when running as a service. Feel it's really easy for
someone not to realize the unattended consequences caused by the fact that
this will affect the Accumulator type for fields generated by the normal
driver and other services in use in addition to the GW1000 service.





On Mon, Aug 3, 2020 at 4:51 PM gjr80  wrote:

> Paul,
>
> The current field_map behaviour is deliberate, it probably doesn’t help
> that I have not documented the behaviour yet. The expected behaviour is:
>
> 1. If the user specifies nothing the default field map is used. (The
> default field map can be viewed by running the driver directly with the
> —default-map command line option. The default field map happens to be
> constructed from the field map dict and battery map dict)
>
> 2. The user can specify a mapping under [field_map], in this case the user
> specified field map replaces the default field map, in other words the user
> takes full responsibility for the field map. You can run the driver
> directly using the —live-data command line option to see what data ,
> including battery state data, is available from the GW1000 for mapping. You
> can extend the [field_map] with [field_map_extensions] but why would you.
>
> 3. If the user is happy with the default field map but wants to map a few
> fields differently they can use [field_map_extensions] to modify the field
> map rathe4 than having to specify every mapping with [field_map].
> [field_map_extensions] are used to modify the field map (typically the
> default field map), basically any GW1000 ‘fields’ in the
> [field_map_extensions] are removed from the field map then the
> [field_map_extensions] entries are added to the field map.
>
> The behaviour above is fairly much standard among drivers that use
> field/sensor maps with [field_map] and [field_map_extensions].
>
> I will document this in the driver wiki shortly.
>
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/9cfb56c1-fc22-4281-b4a5-4e0bf84efcabo%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/CAOAVAeecEVWzPDyZRkn%3D4U_xX5Xc4mO2kvQNM48yyUy5e%2BumRg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Paul R Anderson]

Forgot to say that user would need to add [[battery_field_map]] to
weewx.conf as well

On Mon, Aug 3, 2020 at 12:13 PM Paul R Anderson  wrote:

> Gary
> V 10 as a service is almost 100% there.
> However if you add a
> [[field_map]] stanza to weewx.config, it gets honored correctly,
> however with the current logic we don't get a battery_field_map added at
> all.
> One way to fix, altho you probably have a more eloquent solution is:
>"""Initialise a GW1000 object."""
> # construct the field map, first obtain the field map from our
> config
> field_map = gw1000_config.get('field_map')
> # construct the battery state field map
> battery_field_map = gw1000_config.get('battery_field_map')
> # now add in the battery state field map
> field_map.update(battery_field_map)
> # obtain any field map extensions from our config
> No changes after that.
> Wow this thing is getting more complicated by the day 
>
>
>
>
> On Mon, Aug 3, 2020 at 10:41 AM gjr80  wrote:
>
>> I have released v0.1.0b10 on Github
>> <https://github.com/gjr80/weewx-gw1000/releases>. The changes include:
>>
>> - renamed --ip command line option to --ip-address
>> - reworked field map processing, field_map_extensions entries should no
>> longer result in multiple mapping for GW1000 'fields'
>> - --system-params command line option should now show the correct GW1000
>> time
>> - reworked up front installation/setup comments in gw1000.py
>> - GW1000 driver and service now use the same [GW1000] config stanza in
>> weewx.conf
>> - when run directly the source of the IP address and port settings is
>> printed to console if debug >= 1
>> - when run directly any --ip-address and --port command line options
>> override any IP address and port settings in weewx.conf,  if --ip-address
>> and/or --port are not specified ip_address and/or port from the [G1000]
>> stanza in weewx.conf are used otherwise the address of the first
>> discovered GW1000 is used
>>
>> b10 only changes weewx.conf if you were using the GW1000 driver as a
>> service; however, upgrading to b10 by downloading the b10 extension package
>> and installing with the wee_extension utility is the preferred means of
>> installing/upgrading to b10. If you are using the GW1000 driver as a
>> service upgrading with wee_extension will see a [GW1000] stanza with
>> default install settings added to weewx.conf, after upgrading just copy
>> your [Gw1000Service] settings to [GW1000] then delete [Gw1000Service] in
>> toto.
>>
>> Gary
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-user+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/280188a8-eb94-401a-95af-5f0d36196774o%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-user/280188a8-eb94-401a-95af-5f0d36196774o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAOAVAedO3_MneViVdHZyBGWJ4H20qKfw5sE4J0gpy5CqzALwaA%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Paul R Anderson]

Gary
V 10 as a service is almost 100% there.
However if you add a
[[field_map]] stanza to weewx.config, it gets honored correctly,
however with the current logic we don't get a battery_field_map added at
all.
One way to fix, altho you probably have a more eloquent solution is:
   """Initialise a GW1000 object."""
# construct the field map, first obtain the field map from our
config
field_map = gw1000_config.get('field_map')
# construct the battery state field map
battery_field_map = gw1000_config.get('battery_field_map')
# now add in the battery state field map
field_map.update(battery_field_map)
# obtain any field map extensions from our config
No changes after that.
Wow this thing is getting more complicated by the day 




On Mon, Aug 3, 2020 at 10:41 AM gjr80  wrote:

> I have released v0.1.0b10 on Github
> . The changes include:
>
> - renamed --ip command line option to --ip-address
> - reworked field map processing, field_map_extensions entries should no
> longer result in multiple mapping for GW1000 'fields'
> - --system-params command line option should now show the correct GW1000
> time
> - reworked up front installation/setup comments in gw1000.py
> - GW1000 driver and service now use the same [GW1000] config stanza in
> weewx.conf
> - when run directly the source of the IP address and port settings is
> printed to console if debug >= 1
> - when run directly any --ip-address and --port command line options
> override any IP address and port settings in weewx.conf,  if --ip-address
> and/or --port are not specified ip_address and/or port from the [G1000]
> stanza in weewx.conf are used otherwise the address of the first
> discovered GW1000 is used
>
> b10 only changes weewx.conf if you were using the GW1000 driver as a
> service; however, upgrading to b10 by downloading the b10 extension package
> and installing with the wee_extension utility is the preferred means of
> installing/upgrading to b10. If you are using the GW1000 driver as a
> service upgrading with wee_extension will see a [GW1000] stanza with
> default install settings added to weewx.conf, after upgrading just copy
> your [Gw1000Service] settings to [GW1000] then delete [Gw1000Service] in
> toto.
>
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/280188a8-eb94-401a-95af-5f0d36196774o%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/CAOAVAee9mc1bGwo3GGweCuavmw_kaJf17STP7M2ViMPbW%3DRRxg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Paul R Anderson]

Only had my GW1000 and a few sensors since Last Saturday, just had some
minor Thunderstorm activity, so first time seeing WH57 Lighting Detector
work.

Lightning Last Distance 0.6 miles
Lightning Last Time 07/30/2020 06:53:04 PM
Lightning Strikes Today 73

Seemed to detect strikes within maybe at least 12 miles. Knew that it was a
low end device, so I am very happy with the way it performed. And yes I Am
like a little kid... doesn't take a lot to amuse 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAOAVAee-mrvbVMrwmzQTfucADk8so0d_bjwOoVd%2Bm%3Dvmxt-z7g%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Paul R Anderson]

Well aware that the manner in which the Rel Offset is determined does not
apply the proper standard temperature profile. That's why I said it may
have been more appropriate to map it to altimeter. Reasoning was at least
it was a static numeric offset, coming closer to altimeter , and certainly
not even close to being proper for barometer.
Totally happy with only using the gw1000 value from Absolute Pressure as
weewx key pressure. Actually had considered this option, but didn't want to
raise hysteria at the thought of letting WeeWx calculate a value in
software that was available in hardware.
As Tom Keffer has pointed out in the past there are many times that given
the fact that some hardware has undocumeted, incorrect, or sketchy, ways of
generating some variables, that WeeWx can do a much better job in software
than the hardware can. But I think as users most of us are hesitant to
acknowledge this and want to defer to the hardware.


>
>

-- 
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/CAOAVAecsF3Cy-MeS36WW8tpx%3DLjSsVu9%2BUCQg8%3D8i7pvVFsy4A%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Paul R Anderson]

Should we map  'altimeter': 'relbarometer' ?

Gw1000 produces 2 pressure readings:
As defined by Ecowitt Calibration of barometric pressure settings

*Absolute Pressure*
"Absolute barometric pressure, can be calibrated at manufacturing time by
comparing with a precise instrument that measures pressure at the same
location. In practice, sometimes small adjustments of a few hPa may be
needed"
*Relative Pressure*
"The relative pressure represents what the air pressure would indicate if
your station was at sea level and depends on the altitude of your console
and cannot be known in advance. This is why it needs an adjustment"

If you work your way thru there cal procedure you will see that you use
the  WS View app to set 2 offsets:
Abs Offset
Rel Offset
To set Rel Offset they have you determine station elevation and direct you
to a site that produces a offset based solely on elevation. So *Rel Offset* is
a *STATIC *offset applied against your Absolute Pressure. It never changes
if we set a Rel Offset of 6.0 hPa then Relative Pressure will always
read 6.0 hPa higher than Absolute Pressure.
As we see in WeeWX Wiki

Station or Gauge Pressure (key *pressure*): This is the absolute, raw
pressure as measured by your instrument. It is not corrected for altitude
or pressure. Pilots call this QFE
Sea-level Pressure (*barometer*): This is the pressure corrected for
altitude, temperature, and (frequently) humidity. Pilots call this QFF.
This is the value displayed by the standard skin.
Altimeter Pressure (*altimeter*) : This is the pressure corrected for
altitude, using a standard temperature profile. Pilots call this QNH.

Because we are on a very limited device which does not attempt in any way
to apply a temperature compensation I believe that mapping   'altimeter':
'relbarometer' may be more appropriate. StdWXCalculate will calculate
barometer for us when it appears in a template.
Thanks
Paul


>
> 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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.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/CAOAVAefsj387Cx%2B8ffLt%2BjLS3vhnrwGp2%2Bpy3zUeuc2h7etKDg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Paul R Anderson]

Gary
First just a note that I was running v0.1.0b6 as a service and my GW1000
lost it's WIFI connection. Actual dropped WIFI connecting by the GW1000.
Looking at the log I see that  the driver worked perfectly, it logged a
connection failure after 3 attempts, but weewx itself kept running so that
only the supplemental data from the GW1000 was lost. Once I relocated the
GW1000 to a better location , without restarting WeeWX, the GW1000 data
started flowing again. Perfect just the behavior I would want.

Just updated to v0.1.0b7 here is what is returned for battery status:
wh31_ch2_batt: 0, wh31_ch4_batt: 0, wh31_ch5_batt: 0, wh31_ch7_batt: 0,
wh57_batt: 5
So all sensors recognized, not sure of the meaning of "0" and "5" and why
wh57 returns "5" All sensors installed with new batteries 3 days ago .

On Tue, Jul 28, 2020 at 9:52 AM gjr80  wrote:

> I have released v0.1.0b7 on Github
> . b7 adds the battery
> states to the default field map which should see battery states appear in
> the loop packets. I expect there will still be some naming issues,
> especially with WH65 and WH32. b7 also fixes a n issue where wind direction
> was wrongly decoded..
>
> Those that have already installed the driver can download and install
> v0.1.0b7 using the following commands depending on your WeeWX install type:
>
> for setup.py installs:
>
> $ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig.
> py
> $ sudo wget -P /home/weewx/bin/user https://
> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py
> 
>
> for package installs:
>
> $ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/
> gw1000_orig.py
> $ sudo wget -P /usr/share/weewx/user https://
> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py
> 
>
> There has been no change to the [GW1000] structure so you can just
> restart WeeWX/run v0.1.0b7 directly without further changes.
>
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/4636d1ee-f397-4679-907c-45981a165199o%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/CAOAVAedB3RQLG80PLywoTPiz%3Dombk0AJcN8iUiX8CXUzyir6ag%40mail.gmail.com.

Re: [weewx-user] Re: WeeWX Beta 4.0.0b10 + vantage + LOOP1 = missing altimeter value

[Paul R Anderson]

Verified Gary's commit fixed altimeter issue under Python 2.7.16,
and  Python 3.7.3 values now being saved to database. Ever if the method
changes i'am sure it will be fine.

Sidenote seemed like the perfect time to try the new  wee_database
--calc-missing utility It of course worked perfectly and calculated all the
missing altimeter fields in my database. Great job!

Paul

On Thu, Jan 30, 2020 at 7:44 AM Thomas Keffer  wrote:

> Good sleuthing!
>
> The solution is a lot simpler: svc_dict is actually an ordered dictionary
> (specifically, a ConfigObj.section). So, all we have to do is make sure
> they are listed in the correct order in DEFAULTS_INI. Right now, they are
> in alphabetical order.
>
> -tk
>
> On Thu, Jan 30, 2020 at 1:00 AM gjr80  wrote:
>
>> OK, had another look and I see the problem; the changes in the 'Bad
>> commit' inadvertently caused WeeWX to try to calculate altimeter before
>> pressure and since altimeter is dependent on pressure that causes a
>> problem if pressure does not exist (as is the case on a Davis system
>> using other than LOOP2). I have applied a fix to the 4.0 code base, guess
>> we will see if that survives Tom's critical eye, but either way 4.0 will
>> have the problem fixed.
>>
>> Well spotted and thanks.
>>
>> Gary
>>
>> On Thursday, 30 January 2020 14:05:24 UTC+10, gjr80 wrote:
>>>
>>> I just updated to the latest 4.0 code and ran it under python3 with the
>>> simulator providing only barometer out of the three pressures (for the
>>> purposes of this exercise this is closely resembles the Davis loop packet).
>>> altimeter was not calculated for each loop packet; however, it was
>>> calculated for and appeared in each archive record. Coupled with the
>>> changes in the 'First_Know_Bad_commit' being of a cosmetic nature only I am
>>> not convinced yet there is an issue in the code base. Nothing seems out of
>>> place in your log or config, can you run WeeWX directly
>>>  and provide
>>> screen captures of the console output making sure we see at least one
>>> archive record (lines starting with REC:) and the loop packets (lines
>>> starting with LOOP:) leading up to the archive record.
>>>
>>> Gary
>>>
>>> On Wednesday, 29 January 2020 13:04:54 UTC+10, Paul Anderson wrote:

 Hi All,
 First off huge fan of WeeWx it is amazing software written by an
 unbelievable group of developers ! Thank you all for your tireless effects
 and dedication.

 Running Beta 4  version  4.0.0b10
 Hardware Vantage Pro 2
 Set to use LOOP1 so WeeWx needs to calculate altimeter as it's not in
 LOOP1.
 Unfortunately it seems to silently fail to calculate altimeter, if used
 in a tag it returns as na.
 And a sqlite query returns:
 Note the missing altimeter values.
 sqlite> select datetime, barometer,altimeter,pressure from archive
 order by datetime desc limit 5;
 1580259900|29.792||29.6113663568201

 I know this is going to sound crazy, the issue seems to have began at
 this commit:
 I'm sure that Halloween Goblins were somehow involved :)

 First Know Bad commit
 Document parameters of WXCalculate.__init__

 https://github.com/weewx/weewx/commit/bb130bb55c3c941c9160388161198ada199b3032
 @tkeffer
 tkeffer committed on Oct 31, 2019

 Last Know Good commit
 Don't bail on a type until you have to.

 https://github.com/weewx/weewx/commit/2286aece0abdaa2d1fc67e7da0627a620b9673ff
 @tkeffer
 tkeffer committed on Oct 30, 2019

 Ran each commit with the same weewx.conf
 Logged the run and put a sqlite query at the bottom.

 Because I had such a difficult time believing it has gone unnoticed so
 long looked for some evidence beyond my own setup. TK your DW3693 station
 stopped sending altimeter data to CWOP on 2019-11-09T23:10:00Z
 CWOP hasn't seen a Pressure reading from DW3693 since then.
 I'm guessing that you updated to First Know Bad commit at that time or
 Switched from LOOP2 to LOOP1 at that time?
 LAST Barometric Pressure to CWOP Nov 9 23:00 Z

 Station Date_Time  altimeter   air_temp
 _ID
 D3693,2019-11-09T22:20:00Z,30.16,55.99,71.0
 D3693,2019-11-09T22:30:00Z,30.16,55.99,70.0
 D3693,2019-11-09T22:40:00Z,30.17,55.99,70.0
 D3693,2019-11-09T22:50:00Z,30.16,55.99,70.0
 D3693,2019-11-09T23:00:00Z,30.16,55.99,70.0
 D3693,2019-11-09T23:10:00Z,,55.99,70.0
 D3693,2019-11-09T23:15:00Z,,55.99,71.0
 D3693,2019-11-09T23:25:00Z,,55.0,71.0
 D3693,2019-11-09T23:35:00Z,,55.0,71.0
 D3693,2019-11-09T23:45:00Z,,55.0,73.0


 Thanks,
 Paul

 Attached
 4.0.0b10.log.txt
 Last_Know_Good_Commit_2286a.log.txt
 First_Know_Bad_commit_bb130.log.txt
 weewx.conf.txt









 --
>> You received this message because you are subscribed to the Google 

Re: [weewx-user] Re: Reporting - NOAA file generation

[Paul R Anderson]

Hello Richard,
On a debian install I use the template below to generate a NOAA style daily
record.
An example of the output can be seen on my website here:
http://pauland.net/NOAA/NOAA-2018-05-27.txt
PLEASE NOTE ! It's the first template I wrote for WEEWX after switching
from wview. Am sure it could be done better, as I just guessed my way until
things worked. However it's been working well for me for 6 months with no
issues.Notice it has hard codes station name rather than variable in a
couple places.

/etc/weewx/skins/Standard/NOAA/NOAA--MM-DD.txt.tmpl


#errorCatcher Echo
#set $YM="%Y%m"
#set $D="%d"
#set $M="%b"
#set $Time="%H:%M"
#set $TimeM="%I:%M %p"
#set $Temp="%6.1f"
#set $Wind="%6.0f"
#set $Dir="%6.0f"
#set $Humid="%6.0f"
#set $Press="%6.1f"
#set $NONE="   N/A"
#set $Rain="%6.2f"

WOBURN WEATHER CENTER
DAILY CLIMATOLOGICAL SUMMARY FOR $month_name $day.dateTime.format($D)
$year_name
Location: Woburn, Massachusetts, U.S.A.
ELEV: $station.altitudeLAT: $station.latitude[0]-$station.latitude[1]
$station.latitude[2]LONG: $station.longitude[0]-$station.longitude[1]
$station.longitude[2]

 Time   Wind Dir   Wind Spd   Wind Gust   Humidity TempBarometer
 Rain
 Degmph mph  %Deg F   mb
 in

#for $record in $day.records
$record.dateTime.format($Time) $record.windDir.nolabel($Dir,$NONE)
 $record.windSpeed.nolabel($Wind,$NONE)
$record.windGust.nolabel($Wind,$NONE)
 $record.outHumidity.nolabel($Humid,$NONE)
 $record.outTemp.nolabel($Temp,$None)
 $record.barometer.nolabel($Press,$NONE) $record.rain.nolabel($Rain,$NONE)
#end for

WOBURN WEATHER CENTER
Summary For $month_name $day.dateTime.format($D) $year_name
--
 Max Temp: $day.outTemp.max At: $day.outTemp.maxtime.format($TimeM)
 Min Temp: $day.outTemp.min At: $day.outTemp.mintime.format($TimeM)
Mean Temp: $day.outTemp.avg
Max Wind Gust: $day.windGust.max At: $day.windGust.maxtime.format($TimeM)
Heat Deg Days: $day.heatdeg.sum
Cool Deg Days: $day.cooldeg.sum
   Daily Rain: $day.rain.sum
--




On Mon, May 28, 2018 at 2:27 PM,  wrote:

> Cheers!!
>
>
> On Monday, May 28, 2018 at 12:22:47 PM UTC-5, reba...@gmail.com wrote:
>>
>> All,
>>
>> First let me say that I have been a long time wview user and I have spent
>> some time getting adapted to the new interface.  I have the system up and
>> running on a Pi with my Vantage Pro2 and have even successfully managed to
>> port my old wview pages to the new platform.  I have a couple of questions
>> with some things I did not quite find in the documentation.
>>
>>1. NOAA File generation:  Does weeWX create or can it create the NOAA
>>daily files like wview did?  Not a problem if it does not but just more
>>changes to my custom web pages.
>>2. Is there a way to get the webpages to update at a faster rate?  I
>>am currently using the default value for the archiving (300s).  If 
>> possible
>>I would like them to update every minute if possible.  The documentation
>>implies that you are stuck at the data archiving rate.
>>3. Can you force weeWX to generate a new set of reports on command
>>and publish to the web server?  If so I will just add an update button to
>>the webpage
>>
>> Thanks In advance and to all that contributed to the code.  Nice Work!
>>
>> Richard
>>
> --
> 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.
>

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