Re: [weewx-user] Re: Did someone test Weewx in Raspbian Buster?

[steeple ian]

Susan,
The install instructions seem to be confusing as they stand. (sudo cd sudo
python ./bin/wee_extension --install /HP1000 sudo python ./bin/wee_config
--reconfigure) and do not work.

I think they should read something like: -

cd ./bin
sudo python wee_extension --install /[path_to]/HP1000-master.zip
sudo python wee_config --reconfigure

This works for me.

Thanks,
Ian

On Thu, 17 Oct 2019 at 03:47, Susan Mackay  wrote:

> Could you elaborate a bit more for the sake of others trying to do the
> same? (Also for me - lets me know what problems others have overcome
> if/when I come to update the code.)
> Susan
>
> --
> 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/4bfbb7f6-dc47-43dd-8e88-5bc60e0e428f%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/CADASSaRiSWx2nsYp%2BnfDDmQ7PdtEP3L0P-k4OE5Dv6HRUA3eyA%40mail.gmail.com.

[weewx-user] MQTTSubscriber not saving values to database

[jmltech]

HI,
Downloaded the MQTTSubscriber so that I can grab some extra temp and 
humidity readings from a couple of Arduinos.  They are being published 
correctly via MQTT, as verified by MQTT-Explorer.
Got the subscription configured okay (no configuration errors) on weewx, 
however I'm getting an awfull lot of this type of error in the log file:

Oct 16 23:32:23 salida1 weewx[25885]: MQTTSubscribeService: Ignoring record 
outside of interval 1571290342.00 1571290344.00 1571290341.905635 
dateTime: 1571290341.91, extraHum4: 8.0, usUnits: 1
Oct 16 23:32:39 salida1 weewx[25885]: MQTTSubscribeService: Ignoring record 
outside of interval 1571290358.00 1571290360.00 1571290357.808515 
dateTime: 1571290357.81, extraHum4: 8.0, usUnits: 1
Oct 16 23:32:39 salida1 weewx[25885]: MQTTSubscribeService: Ignoring record 
outside of interval 1571290358.00 1571290360.00 1571290357.866821 
dateTime: 1571290357.87, mqttSignal1: -64.0, usUnits: 1

Consequently, I'm not seeing any of the values being written to the database.

Here is what I have in my weewx.conf:
 Options for extension 'MQTTSubscribe'
[MQTTSubscribeService]
 # This section is for the MQTTSubscribe service.
 
 # Turn the service on and off.
 # Default is: true
 # Only used by the service.
 enable = True
 
 # The MQTT server.
 # Default is: localhost
 host = localhost
 
 # The port to connect to.
 # Default is: 1883
 port = 1883
 
 # Maximum period in seconds allowed between communications with the broker.
 # Default is: 60
 keepalive = 50
 
 # The binding, loop or archive.
 # Default is: loop
 # Only used by the service.
 binding = loop

 # The clientid to connect with.
 clientid = weewxMQTT
 
 # The message handler to use
 [[message_callback]]
 # The format of the MQTT payload.
 # Currently support: individual, json, keyword
 # Must be specified.
 type = individual

 # When it is True, the full topic will be the fieldname. The default will be 
false.
 full_topic_fieldname = True

 [[[label_map]]]
 WX/RVGarage/Temperature = extraTemp4
 WX/JoeWorkshop/Temperature = extraTemp5
 WX/RVGarage/Humidity = extraHum4
 WX/JoeWorkshop/Humidity = extraHum5
 WX/RVGarage/Signal = mqttSignal1
 WX/JoeWorkshop/Signal = mqttSignal2
 
 # The topics to subscribe to.
 [[topics]]
 # Units for MQTT payloads without unit value.
 # Valid values: US, METRIC, METRICWX
 # Default is: US
 unit_system = US

 # Even if the payload has a datetime, ignore it and use the server datetime
 # Default is False
 use_server_time = True

 # When True, the MQTT datetime will be not be checked that is greater than the 
last packet processed.
 # Default is False
 # Only used by the service.
 #ignore_start_time = True

 # When the True, the MQTT data will continue to be processed even if its 
datetime is greater than the packet's datetime.
 # Default is False
 # Only used by the service.
 ignore_end_time = True

 # When it is True, the full topic will be the fieldname. The default will be 
false.
 full_topic_fieldname = True

 [[[WX/#]]]

It appears that every published packet is being ignored because of the 
timestamp.  My log file is growing like crazy.
Anyone have any ideas?
Thanks
Joe




-- 
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/a0c6f662-de41-43d1-86eb-caec2ae2a657%40googlegroups.com.

Re: [weewx-user] Re: Did someone test Weewx in Raspbian Buster?

[Susan Mackay]

Could you elaborate a bit more for the sake of others trying to do the 
same? (Also for me - lets me know what problems others have overcome 
if/when I come to update the code.)
Susan

-- 
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/4bfbb7f6-dc47-43dd-8e88-5bc60e0e428f%40googlegroups.com.

Re: [weewx-user] Re: Weather station recommendations?

[Xant]

Greg

Back to the Solar Radiation, UV and Illuminance.

There are indeed debate regarding direct conversion from Radiation to 
Illumination (as definitely different entities). Although, extrapolation by 
a multiplier seems to provide close results (Lux ~ 119.*Rad), per related 
following references:


   - US Dept of Commerce / National Bureau of Standards, Solar Radiation 
   and Illumination [1981]: 
   
https://www.govinfo.gov/content/pkg/GOVPUB-C13-42a9d8afbf69d850c07ab73935aef0ab/pdf/GOVPUB-C13-42a9d8afbf69d850c07ab73935aef0ab.pdf
   - Watts to Luxes Ratio for Sollar Radiation by TMY Data for Odessa 
   [2017]: 
   
https://www.researchgate.net/publication/318260849_Watts_to_Luxes_Ratio_for_Sollar_Radiation_by_TMY_Data_for_Odessa
   
Per your previous posting and statement: "One might even be convinced that 
the errors are small relative to the claimed accuracy", as building a table 
of interpolation points.

The above references indeed certify your correct comments... therefore, 
much credits to you.

Xant

-- 
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/153c9e21-3dfc-4884-98b6-7508e607352a%40googlegroups.com.

Re: [weewx-user] Re: Weather station recommendations?

[Xant]

Ok... don't want to make this a tug-of-war, but my "un-scientific" fell is 
that you can bring any PWS hardware to anywhere, and expectations that they 
would communicate just fine (regardless of local regulations).

Then, there is the upload to usual OEM Weather website, which by my 
previous posting, some don't make much easy (which they should still 
puzzles me why they would care to restrict). But you are free with WeeWX.

I had a previous run with Ambient Weather WS-1550-IP, which it seems 
actually a Chinese brand, and sold under diverse brand names. The system 
itself is much affordable, with extra sensors, but much trouble with 
ObserverIP "overload". If frequency is of concern, I may assume that some 
version may exist.

Also assuming that most US brands to refers to 915 MHz, regardless if sold 
in different markets.

But honestly... is frequency a concern regardless of location?

Again, this is "un-scientific", so I can take some educated criticism...

-- 
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/efa03832-903b-45d9-a6eb-2a5bcd9a02d2%40googlegroups.com.

Re: [weewx-user] Re: Random Stoppages

[K Weaver]

# WEEWX CONFIGURATION FILE
#
# Copyright (c) 2009-2019 Tom Keffer 
# See the file LICENSE.txt for your rights.

##

# This section is for general configuration information.

# Set to 1 for extra debug info, otherwise comment it out or set to zero
debug = 1

# Root directory of the weewx data file hierarchy for this station
WEEWX_ROOT = /

# Whether to log successful operations
log_success = True

# Whether to log unsuccessful operations
log_failure = True

# How long to wait before timing out a socket (FTP, HTTP) connection
socket_timeout = 20

# Do not modify this. It is used when installing and updating weewx.
version = 3.9.2

##

#   This section is for information about the station.

[Station]

# Description of the station location
location = Concord, NC

# Latitude and longitude in decimal degrees
latitude = 35.436
longitude = -80.737

# Altitude of the station, with unit it is in. This is downloaded from
# from the station if the hardware supports it.
altitude = 675, foot

# Set to type of station hardware. There must be a corresponding stanza
# in this file with a 'driver' parameter indicating the driver to be
used.
station_type = Interceptor

# If you have a website, you may specify an URL
station_url = http://mosscreekweather.org/weewx

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from the station if the hardware supports it.
rain_year_start = 1

# Start of week (0=Monday, 6=Sunday)
week_start = 6

##

[Simulator]
# This section is for the weewx weather station simulator

# The time (in seconds) between LOOP packets.
loop_interval = 2.5

# The simulator mode can be either 'simulator' or 'generator'.
# Real-time simulator. Sleep between each LOOP packet.
mode = simulator
# Generator.  Emit LOOP packets as fast as possible (useful for
testing).
#mode = generator

# The start time. Format is -mm-ddTHH:MM. If not specified, the
default
# is to use the present time.
#start = 2011-01-01T00:00
# The driver to use:
driver = weewx.drivers.simulator

##

[Interceptor]
# This section is for the network traffic interceptor driver.

# The driver to use:
driver = user.interceptor
# Specify the hardware device to capture.  Options include:
#   acurite-bridge - acurite internet bridge, smarthub, or access
#   observer - fine offset WH2600/HP1000/HP1003, ambient WS2902
#   lw30x - oregon scientific LW301/LW302
#   lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge
#   wu-client - any hardware that uses the weather underground protocol
device_type = acurite-bridge
mode = listen
iface = eth0
port = 80
##

#   This section is for uploading data to Internet sites

[StdRESTful]

[[StationRegistry]]
# To register this weather station with weewx, set this to true
register_this_station = true



[[AWEKAS]]
# This section is for configuring posts to AWEKAS.

# If you wish to do this, set the option 'enable' to true,
# and specify a username and password.
# To guard against parsing errors, put the password in quotes.
enable = true
username = Kweaver66
password =

[[CWOP]]
# This section is for configuring posts to CWOP.

# If you wish to do this, set the option 'enable' to true,
# and specify the station ID (e.g., CW1234).
enable = true
station = FW0975

# If this is an APRS (radio amateur) station, uncomment
# the following and replace with a passcode (e.g., 12345).
#passcode = replace_me (APRS stations only)

[[PWSweather]]
# This section is for configuring posts to PWSweather.com.
# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = true
station = KNCCONCO67
password =

[[WOW]]
# This section is for configuring posts to WOW.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

[[Wunderground]]
# This section is for configuring posts to the Weather Underground.

# If you wish to do this, set the option 'enable' to true,
# and specify a station (e.g., 'KORHOODR3') and passwor

Re: [weewx-user] Re: Weather station recommendations?

[vince]

On Wednesday, October 16, 2019 at 9:45:15 AM UTC-7, Sean Jahnig wrote:
>
> I contacted weatherflow regarding their station and they said they're not 
> selling it outside of the us and Canada because of frequencies etc. That 
> are designed only to work in those places. I guess that means it won't have 
> full functionality outside of us and Canada 
>
 
>
 
>

That's not quite completely accurate.   They initially did a run of over 
3000 units for their kickstarter supporters, split between US and European 
frequency compatible gear.   After that they did additional hardware runs 
for the US market only, if I recall correctly.

Their 'rain check' functionality was initially rolled out US only as well, 
so it's possible that they simply delayed non-US additional units until 
they could support everybody just as well.

They also pre-announced a coming revision of the station on their website 
just the other day, which from the picture looks like it's all going to be 
in one unit seemingly built on the same kind of technology.  Of course with 
(another) kickstarter it's very hard to predict what the actual hardware 
will look like or how good it will be, especially initially.  But that's 
the risk of saving some money and going the kickstarter initial supporter 
route rather than waiting for the generally available gear to become 
available.
 

-- 
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/4fa39165-7cb4-4e20-a02d-123739f6bbf0%40googlegroups.com.

Re: [weewx-user] Re: Davis Datalogger bug

[Thomas Keffer]

If you care about data integrity, the $50 for a modest UPS is money well
spent!

On Wed, Oct 16, 2019 at 5:00 PM gjr80  wrote:

> Yes, the price you pay for using software record generation. Also, I
> forgot about no_catchup being introduced in 3.9.1. That changes the logic
> during a startup catchup, now software record generation will also get
> caught up in the 'timestamp less than final' issue unless you set no_catchup
> = False. But then, as you say, you will miss out on any catchup records
> in timea when you do not have corrupt station memory.
>
> Guess that's why I have a UPS as well :)
>
> Gary
>
> On Thursday, 17 October 2019 09:35:21 UTC+10, Thomas Keffer wrote:
>>
>> Immune, yes, but you also won't get any archive records stored on the
>> logger while your computer is down!
>>
>> On Wed, Oct 16, 2019 at 4:33 PM gjr80  wrote:
>>
>>> One other thing to keep in mind; the de facto standard mode of operation
>>> of a Davis station under WeeWX is to use hardware record generation, in
>>> other words WeeWX obtains and stores archive records from from the
>>> console/logger. WeeWX can also operate using software record generation
>>> where only loop packets are obtained from the logger/console and archive
>>> records are synthesised by WeeWX from this data. When the logger
>>> experiences corrupted memory/temporal displacement it almost always
>>> continues to emit loop packets but emits old archive records. So when
>>> operated in software record generation mode WeeWX will essentially be
>>> immune from the corrupted station memory issue. Similarly, other PWS
>>> software that only use loop packets will not be affected by the corrupted
>>> station memory issue.
>>>
>>> I don't see this as a WeeWX bug, rather a limitation of operating in
>>> hardware record generation mode that can be mitigated by reliable power and
>>> clock.
>>>
>>> Gary
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/e4475612-bb76-4fd2-8e53-dc00286f878d%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/d91c9ec6-6c02-481d-ac73-54675c772b20%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/CAPq0zECKhp6CP6WybUnYWivZzi-wQG3p03MZ39A_pC8Z4qyZeA%40mail.gmail.com.

Re: [weewx-user] Re: Davis Datalogger bug

[gjr80]

Yes, the price you pay for using software record generation. Also, I forgot 
about no_catchup being introduced in 3.9.1. That changes the logic during a 
startup catchup, now software record generation will also get caught up in 
the 'timestamp less than final' issue unless you set no_catchup = False. 
But then, as you say, you will miss out on any catchup records in timea 
when you do not have corrupt station memory.

Guess that's why I have a UPS as well :)

Gary

On Thursday, 17 October 2019 09:35:21 UTC+10, Thomas Keffer wrote:
>
> Immune, yes, but you also won't get any archive records stored on the 
> logger while your computer is down!
>
> On Wed, Oct 16, 2019 at 4:33 PM gjr80 > 
> wrote:
>
>> One other thing to keep in mind; the de facto standard mode of operation 
>> of a Davis station under WeeWX is to use hardware record generation, in 
>> other words WeeWX obtains and stores archive records from from the 
>> console/logger. WeeWX can also operate using software record generation 
>> where only loop packets are obtained from the logger/console and archive 
>> records are synthesised by WeeWX from this data. When the logger 
>> experiences corrupted memory/temporal displacement it almost always 
>> continues to emit loop packets but emits old archive records. So when 
>> operated in software record generation mode WeeWX will essentially be 
>> immune from the corrupted station memory issue. Similarly, other PWS 
>> software that only use loop packets will not be affected by the corrupted 
>> station memory issue.
>>
>> I don't see this as a WeeWX bug, rather a limitation of operating in 
>> hardware record generation mode that can be mitigated by reliable power and 
>> clock.
>>
>> Gary
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/e4475612-bb76-4fd2-8e53-dc00286f878d%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/d91c9ec6-6c02-481d-ac73-54675c772b20%40googlegroups.com.

[weewx-user] Re: CSV extension writing bad data

[gjr80]

Can't comment on what changed on your install from 3.5.0 to 3.9.2. The only 
WeeWX code that could affect the csv output would be the AcuRite driver, 
and I see there have been no changes to this driver since the 3.5.0 release 
that could account for the changed behaviour. Perhaps you are using a 
different csv extension version. The logic for creating the csv output is 
wholly within the csv extension.

In any case, given the old sample output below you could mimic that output 
by making a simple alteration to the csv extension code. In csv.py you 
could change (untested):

header = None
if self.emit_header and (
not os.path.exists(filename) or flag == "w"):
header = '# %s\n' % ','.join(self.sort_keys(data))

to

header = '# %s\n' % ','.join(self.sort_keys(data))

be aware that this change will mean that the header is always written 
before each loop packet is written, none of the config options in 
weewx.conf will change this. Of course the other issue is that you now have 
an orphan version of the csv extension and any subsequent upgrades/installs 
of the extension will overwrite your changes.

Gary

On Thursday, 17 October 2019 02:03:41 UTC+10, Dave wrote:
>
> On Tuesday, October 15, 2019 at 11:39:03 PM UTC-7, gjr80 wrote:
>>
>> Hi,
>>
>> The problem you are experiencing is due an incompatibility between your 
>> station emitting what is known as partial loop packets (ie not all obs are 
>> included in all loop packets) and the mode in which you are operating the 
>> csv extension.
>>
>> You are running the CSV extension such that it emits loop data to file 
>> and includes a header line. Subsequent loop packets are appended to the 
>> file. The header line is only written (1) when the csv output file is first 
>> created or (2) on each loop packet but only if mode = 'overwrite'. In 
>> your case you are using 'append' mode so the header line is only written 
>> when the csv output file is first created. Think now of the situation where 
>> the first loop packet has, say, observation outTemp but the next loop 
>> packet does not. So the header line is written and includes 'outTemp' in 
>> the relevant place. The line of csv data for that packet is written to file 
>> and each field matches with the header line. When the next loop packet is 
>> processed there is no outTemp field in the loop packet so nothing is 
>> written in outTemp's place in the line of csv data (well in fact something 
>> will be written it will be the next field if there is one). Consequently 
>> when your parser parses that line it expects to see outTemp data when in 
>> fact it sees the next value instead (perhaps it was outTempBatteryStatus) 
>> and hence you get nonsense values from your parser.
>>
>
> Thank you very much for this explanation. I am familiar with this idea but 
> It seems the behavior changed between 3.5.0 and 3.9.2. It used to write 
> each header line when mode was 'append'. Since part of the upgrade was 
> moving weewx to another server, I still have the old server's data and 
> binaries available. If you look in the weewx.csv for the 3.5.0 server:
>
>
> dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,maxSolarRad,outHumidity,outTemp,rainRate,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windSpeed,windchill
>
> 1571075730,None,71.4621394073,None,None,3276.5581345,56.6531442082,70.3,76.0399971396,None,None,62,70.3,0,3,100.0,0,1228,0,1,1.65011333748,70.3
>
> dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,maxSolarRad,rain,rainRate,rain_total,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windDir,windSpeed,windchill
>
> 1571075748,None,None,None,None,None,None,None,None,None,None,0.0,0,110.4646,3,100.0,0,1228,0,1,180.0,2.16448441021,None
>
> dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,inTemp,maxSolarRad,outHumidity,outTemp,pressure,rainRate,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windSpeed,windchill
>
> 1571075766,29.9423211803,71.4621394073,29.9470837144,None,3276.5581345,56.6531442082,70.3,76.0399971396,None,74.39,None,62,70.3,29.7622563497,0,3,100.0,0,1228,0,1,1.65011333748,70.3
>
>
> ...it's writing a header line each time, even in 'append' mode. My config 
> for that server was:
>
> [CSV]
> filename = /var/db/weewx/weewx.csv
> header = true
>
>
> So it's clear that something changed to exhibit the behavior you describe 
> above instead of the old behavior.
>
>
>> Solutions, there are a few possibilities:
>>
>> 1. use 'overwrite' mode instead of append, in this mode the header line 
>> is written each time a packet is processed but there is only ever one line 
>> in your csv output file
>> 2. delete the csv output file after each loop packet is read by your 
>> parser (this is a pretty lame solution)
>> 3. rewrite the csv extension 

Re: [weewx-user] Re: Davis Datalogger bug

[Thomas Keffer]

Immune, yes, but you also won't get any archive records stored on the
logger while your computer is down!

On Wed, Oct 16, 2019 at 4:33 PM gjr80  wrote:

> One other thing to keep in mind; the de facto standard mode of operation
> of a Davis station under WeeWX is to use hardware record generation, in
> other words WeeWX obtains and stores archive records from from the
> console/logger. WeeWX can also operate using software record generation
> where only loop packets are obtained from the logger/console and archive
> records are synthesised by WeeWX from this data. When the logger
> experiences corrupted memory/temporal displacement it almost always
> continues to emit loop packets but emits old archive records. So when
> operated in software record generation mode WeeWX will essentially be
> immune from the corrupted station memory issue. Similarly, other PWS
> software that only use loop packets will not be affected by the corrupted
> station memory issue.
>
> I don't see this as a WeeWX bug, rather a limitation of operating in
> hardware record generation mode that can be mitigated by reliable power and
> clock.
>
> 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/e4475612-bb76-4fd2-8e53-dc00286f878d%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/CAPq0zEALVcG10M8ACqqUhx2kBJdVHky6Bpq_hyt2VGKgbMORQQ%40mail.gmail.com.

Re: [weewx-user] Re: Davis Datalogger bug

[gjr80]

One other thing to keep in mind; the de facto standard mode of operation of 
a Davis station under WeeWX is to use hardware record generation, in other 
words WeeWX obtains and stores archive records from from the 
console/logger. WeeWX can also operate using software record generation 
where only loop packets are obtained from the logger/console and archive 
records are synthesised by WeeWX from this data. When the logger 
experiences corrupted memory/temporal displacement it almost always 
continues to emit loop packets but emits old archive records. So when 
operated in software record generation mode WeeWX will essentially be 
immune from the corrupted station memory issue. Similarly, other PWS 
software that only use loop packets will not be affected by the corrupted 
station memory issue.

I don't see this as a WeeWX bug, rather a limitation of operating in 
hardware record generation mode that can be mitigated by reliable power and 
clock.

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/e4475612-bb76-4fd2-8e53-dc00286f878d%40googlegroups.com.

[weewx-user] Re: CSV extension writing bad data

[Pat]

It's probably not too bad to fork the extension and add the CachedValues 
method as seen in the restx extension 
 
(read: 
copy/paste). Once tested and working this should satisfy option 3.

Other important information found for CachedValues are here 
, 
and here 
. 
You can see on every loop it updates the cached dictionary of those values 
with the update() function. Then it outputs the observations that just came 
in, plus the missing ones from Cached values, to the LOOP with 
the get_packet() function.

On Wednesday, October 16, 2019 at 12:03:41 PM UTC-4, Dave wrote:
>
> On Tuesday, October 15, 2019 at 11:39:03 PM UTC-7, gjr80 wrote:
>>
>> Hi,
>>
>> The problem you are experiencing is due an incompatibility between your 
>> station emitting what is known as partial loop packets (ie not all obs are 
>> included in all loop packets) and the mode in which you are operating the 
>> csv extension.
>>
>> You are running the CSV extension such that it emits loop data to file 
>> and includes a header line. Subsequent loop packets are appended to the 
>> file. The header line is only written (1) when the csv output file is first 
>> created or (2) on each loop packet but only if mode = 'overwrite'. In 
>> your case you are using 'append' mode so the header line is only written 
>> when the csv output file is first created. Think now of the situation where 
>> the first loop packet has, say, observation outTemp but the next loop 
>> packet does not. So the header line is written and includes 'outTemp' in 
>> the relevant place. The line of csv data for that packet is written to file 
>> and each field matches with the header line. When the next loop packet is 
>> processed there is no outTemp field in the loop packet so nothing is 
>> written in outTemp's place in the line of csv data (well in fact something 
>> will be written it will be the next field if there is one). Consequently 
>> when your parser parses that line it expects to see outTemp data when in 
>> fact it sees the next value instead (perhaps it was outTempBatteryStatus) 
>> and hence you get nonsense values from your parser.
>>
>
> Thank you very much for this explanation. I am familiar with this idea but 
> It seems the behavior changed between 3.5.0 and 3.9.2. It used to write 
> each header line when mode was 'append'. Since part of the upgrade was 
> moving weewx to another server, I still have the old server's data and 
> binaries available. If you look in the weewx.csv for the 3.5.0 server:
>
>
> dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,maxSolarRad,outHumidity,outTemp,rainRate,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windSpeed,windchill
>
> 1571075730,None,71.4621394073,None,None,3276.5581345,56.6531442082,70.3,76.0399971396,None,None,62,70.3,0,3,100.0,0,1228,0,1,1.65011333748,70.3
>
> dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,maxSolarRad,rain,rainRate,rain_total,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windDir,windSpeed,windchill
>
> 1571075748,None,None,None,None,None,None,None,None,None,None,0.0,0,110.4646,3,100.0,0,1228,0,1,180.0,2.16448441021,None
>
> dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,inTemp,maxSolarRad,outHumidity,outTemp,pressure,rainRate,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windSpeed,windchill
>
> 1571075766,29.9423211803,71.4621394073,29.9470837144,None,3276.5581345,56.6531442082,70.3,76.0399971396,None,74.39,None,62,70.3,29.7622563497,0,3,100.0,0,1228,0,1,1.65011333748,70.3
>
>
> ...it's writing a header line each time, even in 'append' mode. My config 
> for that server was:
>
> [CSV]
> filename = /var/db/weewx/weewx.csv
> header = true
>
>
> So it's clear that something changed to exhibit the behavior you describe 
> above instead of the old behavior.
>
>
>> Solutions, there are a few possibilities:
>>
>> 1. use 'overwrite' mode instead of append, in this mode the header line 
>> is written each time a packet is processed but there is only ever one line 
>> in your csv output file
>> 2. delete the csv output file after each loop packet is read by your 
>> parser (this is a pretty lame solution)
>> 3. rewrite the csv extension to cache loop packet data so that a 
>> 'complete' loop packet is written each time
>> 4. emit archive record data rather than loop packet data
>>
>
> IMO option 3 provides the best solution as there's zero way to parse a 
> partial packet without keys for the values. ;) This would also restore my 
> nagios plugin's proper functionality. Unfortunately, I've too little 
> experience in python to attempt 3 in a public software r

Re: [weewx-user] Re: Weather station recommendations?

[Xant]

Greg

Your interpretation of Radio Frequencies seems correct. Although, my note 
regarding OEM data upload still to consider as a personal experience in 
other sides of the Globe.

By other posting, it seems that Sean Jahnig already decided and bought an 
Acurite... which I also think (not sure if frequency to other markets), 
only provides to 915 MHz.

-- 
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/9aad6e84-5479-474f-ba5d-d69e2d1afc52%40googlegroups.com.

Re: [weewx-user] Re: Weather station recommendations?

[Greg Troxel]

Sean Jahnig  writes:

> I contacted weatherflow regarding their station and they said they're not
> selling it outside of the us and Canada because of frequencies etc. That
> are designed only to work in those places. I guess that means it won't have
> full functionality outside of us and canada

I don't think that's the right interpretation.

There is a notion of unlicensed radiofrequency usage, typically for
short-range communications, and many countries have regulations about
this.  However, a lot of them are different and in particular the
frequencies that are allowed are different.  My understanding is that US
and Canadian rules are very similar.

In the US this goes by the name "Part 15" (from 47 CFR 15), and you will
find hobbyist parts that operate on 915 MHz here but in Europe are
supposed to be operated on 868 MHz.

https://en.wikipedia.org/wiki/ISM_band
https://www.adafruit.com/product/3070


WiFi has similar issues, with different channels in different countries.

I really don't know the details  of WF, but if they say they're only
selling it in US/CAN because of "frequencies", that's a huge clue that
the device transmits on frequencies that are not necessarily authorized
in other countries.

-- 
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/rmitv881oa3.fsf%40s1.lexort.com.

Re: [weewx-user] Re: Weather station recommendations?

[Xant]

Not sure where is your weather pole location, but here is a bit of debate 
to consider.

I previously took an Acurite 5x1 to family in Brazil. Upon installing and 
connecting, the Acurite website was not registering "Brazil" as a location, 
so we had to register as US based. The result is that uploaded data was all 
correct (per measurements), but the forecast was to be ignored as it not 
really reflects the right location. 

That shows dependency of your PWS hardware OEM againt their Website and 
controls.

But for us "WeeWX enthusiasts" this debate is futile, as all PWS data are 
under our control.

-- 
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/99890fc2-9e27-4867-991d-5d9d36135adb%40googlegroups.com.

Re: [weewx-user] Re: Weather station recommendations?

[Sean Jahnig]

Thanks for the update.

I contacted weatherflow regarding their station and they said they're not
selling it outside of the us and Canada because of frequencies etc. That
are designed only to work in those places. I guess that means it won't have
full functionality outside of us and canada

Thanks,

Sean Jahnig

m.  +97150 475 4234
e.  seanocas...@gmail.com

On Wed, 16 Oct 2019, 19:51 Xant,  wrote:

>
> After the above reference regarding Windguru, I implemented the plugin
> service into WeeWX and start uploading to Windguru website (easy process,
> and uploading in minutes).
>
> Upon uploading PWS data to Windguru, said that account would be upgraded
> to PRO (as incentive for contribution and removal of Ads). It didn't
> happened "automatically" and I sent email to Vaclav Hornik (Czech
> Republic), whom seen to do it all - Windguru creator, webmaster and
> winsurfer (as said himself).
>
>
> --
> 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/46dbbba4-cf78-4966-9d00-d83d4093e645%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/CALeSoZnRPFLJtLRYO0gzVf0Fjxn4fbO1Qn7oRoK8RrU65S-V1Q%40mail.gmail.com.

[weewx-user] Re: CSV extension writing bad data

[Dave]

On Tuesday, October 15, 2019 at 11:39:03 PM UTC-7, gjr80 wrote:
>
> Hi,
>
> The problem you are experiencing is due an incompatibility between your 
> station emitting what is known as partial loop packets (ie not all obs are 
> included in all loop packets) and the mode in which you are operating the 
> csv extension.
>
> You are running the CSV extension such that it emits loop data to file and 
> includes a header line. Subsequent loop packets are appended to the file. 
> The header line is only written (1) when the csv output file is first 
> created or (2) on each loop packet but only if mode = 'overwrite'. In 
> your case you are using 'append' mode so the header line is only written 
> when the csv output file is first created. Think now of the situation where 
> the first loop packet has, say, observation outTemp but the next loop 
> packet does not. So the header line is written and includes 'outTemp' in 
> the relevant place. The line of csv data for that packet is written to file 
> and each field matches with the header line. When the next loop packet is 
> processed there is no outTemp field in the loop packet so nothing is 
> written in outTemp's place in the line of csv data (well in fact something 
> will be written it will be the next field if there is one). Consequently 
> when your parser parses that line it expects to see outTemp data when in 
> fact it sees the next value instead (perhaps it was outTempBatteryStatus) 
> and hence you get nonsense values from your parser.
>

Thank you very much for this explanation. I am familiar with this idea but 
It seems the behavior changed between 3.5.0 and 3.9.2. It used to write 
each header line when mode was 'append'. Since part of the upgrade was 
moving weewx to another server, I still have the old server's data and 
binaries available. If you look in the weewx.csv for the 3.5.0 server:

dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,maxSolarRad,outHumidity,outTemp,rainRate,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windSpeed,windchill
1571075730,None,71.4621394073,None,None,3276.5581345,56.6531442082,70.3,76.0399971396,None,None,62,70.3,0,3,100.0,0,1228,0,1,1.65011333748,70.3
dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,maxSolarRad,rain,rainRate,rain_total,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windDir,windSpeed,windchill
1571075748,None,None,None,None,None,None,None,None,None,None,0.0,0,110.4646,3,100.0,0,1228,0,1,180.0,2.16448441021,None
dateTime,altimeter,appTemp,barometer,channel,cloudbase,dewpoint,heatindex,humidex,inDewpoint,inTemp,maxSolarRad,outHumidity,outTemp,pressure,rainRate,rssi,rxCheckPercent,sensor_battery,sensor_id,txTempBatteryStatus,usUnits,windSpeed,windchill
1571075766,29.9423211803,71.4621394073,29.9470837144,None,3276.5581345,56.6531442082,70.3,76.0399971396,None,74.39,None,62,70.3,29.7622563497,0,3,100.0,0,1228,0,1,1.65011333748,70.3


...it's writing a header line each time, even in 'append' mode. My config 
for that server was:

[CSV]
filename = /var/db/weewx/weewx.csv
header = true


So it's clear that something changed to exhibit the behavior you describe 
above instead of the old behavior.


> Solutions, there are a few possibilities:
>
> 1. use 'overwrite' mode instead of append, in this mode the header line is 
> written each time a packet is processed but there is only ever one line in 
> your csv output file
> 2. delete the csv output file after each loop packet is read by your 
> parser (this is a pretty lame solution)
> 3. rewrite the csv extension to cache loop packet data so that a 
> 'complete' loop packet is written each time
> 4. emit archive record data rather than loop packet data
>

IMO option 3 provides the best solution as there's zero way to parse a 
partial packet without keys for the values. ;) This would also restore my 
nagios plugin's proper functionality. Unfortunately, I've too little 
experience in python to attempt 3 in a public software repo. 

Those other solutions, for various reasons, are non-optimal. 1 and 2 will 
suffer from the lack of caching of data. 4 makes some sense, but for this 
comment:

# If the station hardware supports data logging then the archive 
interval
# will be downloaded from the station. Otherwise, specify it (in 
seconds).
archive_interval = 300


I have a need for immediate data. Not knowing what my archive interval will 
be is a deal breaker. 

Sadly, it seems I will have to use weewx within my own script and parse 
it's stdout myself. Thanks for all the insight and responses. :D

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

Re: [weewx-user] Re: Weather station recommendations?

[Xant]

After the above reference regarding Windguru, I implemented the plugin 
service into WeeWX and start uploading to Windguru website (easy process, 
and uploading in minutes).

Upon uploading PWS data to Windguru, said that account would be upgraded to 
PRO (as incentive for contribution and removal of Ads). It didn't happened 
"automatically" and I sent email to Vaclav Hornik (Czech Republic), whom 
seen to do it all - Windguru creator, webmaster and winsurfer (as said 
himself).


-- 
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/46dbbba4-cf78-4966-9d00-d83d4093e645%40googlegroups.com.

Re: [weewx-user] Re: Davis Datalogger bug

[Thomas Keffer]

This has been my solution as well: a real-time clock, plus a UPS.

But, if the power outage is severe enough to drain the UPS battery, my
setup still recovers. At least, the last time that happened (about a year
ago).

-tk

On Wed, Oct 16, 2019 at 8:14 AM David VE3STI 
wrote:

> I had somewhat similar issues - WeeWX couldn't read from the Vantage Vue
> after boot up. I needed to do the "memory clear" command then all was well.
> However, it was a giant pain if I was away/busy/etc and not available to
> run the command. I thought that it should be possible to "fix" this issue
> in software but my feeble efforts failed. I installed a RTC. That didn't
> fix it either so I gave up and now use a UPS to run the RPi. As long as my
> RPi never reboots, I'm OK.
>
> I don't have much to contribute but I'll watch from the sidelines. I'd
> love to see where this leads.
>
> David Beach
>
> On Wednesday, 16 October 2019 07:40:59 UTC-4, Thomas Keffer wrote:
>>
>> This is likely a case of memory corruption, brought on by time not being
>> synced during the reboot, due to the lack of an on-board clock. It was not
>> a problem with Weatherlink because you were not running it on an RPi.
>>
>> See the section *WeeWX generated HTML pages, but does not update them
>> * in
>> the User's Guide.
>>
>> But, as Andrew suggested, we would have to see the log from startup to be
>> sure.
>>
>> -tk
>>
>> On Wed, Oct 16, 2019 at 4:04 AM Andrew Milner 
>> wrote:
>>
>>> what came just before the log you posted?  why is weewx attempting to do
>>> a catchup? had weewx just been started?  had communications been lost for
>>> some reason? We need to know what is causing weewx to attempt a catchup in
>>> the first place.  You can never post too much log
>>>
>>>
>>>
>>>
>>> On Wednesday, 16 October 2019 13:52:51 UTC+3, Andrea Cecilia wrote:

 here it is. As you can see, there is no "added record [...] to
 weewx.sdb" line, which indicates that it is not downloading data from the
 datalogger, and the reson (I think) is explained in the highlighted line.

 Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Getting archive
 packets since 2019-10-16 09:05:00 CEST (1571209500)
 Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of
 console successful
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Retrieving 5 page(
 s); starting index= 4
 *Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: DMPAFT complete:
 page timestamp 2019-10-15 13:20:00 CEST (1571138400) less than final
 timestamp 2019-10-16 09:05:00 CEST (1571209500)*
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Catch up complete.
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running
 reports for latest time in the database.
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Requesting 200
 LOOP packets.
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running
 report 'StandardReport'
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of
 console successful
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Found
 configuration file /home/weewx/skins/Standard/skin.conf for report
 'StandardReport'
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: cheetahgenerator: using
 search list ['weewx.cheetahgenerator.Almanac',
 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', '
 weewx.ch
 eetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo',
 'weewx.cheetahgenerator.Extras']
 Oct 16 10:30:15 raspberrypi weewx-vp2[511]: manager: Daily summary
 version is 2.0
 Oct 16 10:30:17 raspberrypi weewx-vp2[511]: cheetahgenerator: Generated
 16 files for report StandardReport in 2.31 seconds
 Oct 16 10:30:17 raspberrypi weewx-vp2[511]: manager: Daily summary
 version is 2.0
 Oct 16 10:30:18 raspberrypi weewx-vp2[511]: imagegenerator: Generated
 15 images for StandardReport in 1.36 seconds
 Oct 16 10:30:18 raspberrypi weewx-vp2[511]: copygenerator: copied 0
 files to /home/weewx/public_html/vp2
 Oct 16 10:30:18 raspberrypi weewx-vp2[511]: reportengine: Running
 report 'FTP'
 Oct 16 10:30:19 raspberrypi weewx-vp2[511]: reportengine: Found
 configuration file /home/weewx/skins/Ftp/skin.conf for report 'FTP'
 Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Attempting
 connection to ftp.meteoregionelazio.it
 Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Connected to ftp
 .meteoregionelazio.it
 Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Uploaded file /
 www.meteoregionelazio.it/stazioni/soriano/weewx/vp2/daypond.png


 --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an 

Re: [weewx-user] Re: Weather Underground Upload Fails

[Thomas Keffer]

Most likely this is being caused because you are missing the necessary
certificates on your RPi to certify the https connection.

I'm definitely not a certificates expert, but try this on your RPi:

*sudo apt-get update*
*sudo apt-get install --reinstall ca-certificates*

This will refresh your cache of certificates.

-tk

On Wed, Oct 16, 2019 at 6:37 AM Ford Smith  wrote:

> weewx 3.9.2
>
> python 2.7.16
>
> On Wednesday, October 16, 2019 at 8:51:35 AM UTC-4, Ford Smith wrote:
>>
>> Until a brief power failure the other day, my weewx reading an Accurite
>> weather station was performing perfectly on a Raspberry Pi 4. Since then,
>> the upload to Weather Underground has failed. I've reinstalled weewx, even
>> created a new PWS on Underground, and finally turned Debug on. Apparently,
>> the problem  is:
>>
>> *Oct 16 08:40:25 raspberrypi weewx[3114]: restx: Wunderground-PWS: Failed
>> upload attempt 2: > certificate verify*
>> I've searched for how to correct this Certificate problem and can find no
>> answers.
>> Help!!
>>
> --
> 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/0da2fbea-457b-40d4-9f95-214e57e9ff36%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/CAPq0zECJX_FGC2%2BCohoPaRZmTvhY3Y%2BvYXcq_MeAGpP-uui%3DKA%40mail.gmail.com.

Re: [weewx-user] Re: Davis Datalogger bug

[David VE3STI]

I had somewhat similar issues - WeeWX couldn't read from the Vantage Vue 
after boot up. I needed to do the "memory clear" command then all was well. 
However, it was a giant pain if I was away/busy/etc and not available to 
run the command. I thought that it should be possible to "fix" this issue 
in software but my feeble efforts failed. I installed a RTC. That didn't 
fix it either so I gave up and now use a UPS to run the RPi. As long as my 
RPi never reboots, I'm OK.

I don't have much to contribute but I'll watch from the sidelines. I'd love 
to see where this leads.

David Beach

On Wednesday, 16 October 2019 07:40:59 UTC-4, Thomas Keffer wrote:
>
> This is likely a case of memory corruption, brought on by time not being 
> synced during the reboot, due to the lack of an on-board clock. It was not 
> a problem with Weatherlink because you were not running it on an RPi.
>
> See the section *WeeWX generated HTML pages, but does not update them 
> * in 
> the User's Guide.
>
> But, as Andrew suggested, we would have to see the log from startup to be 
> sure.
>
> -tk
>
> On Wed, Oct 16, 2019 at 4:04 AM Andrew Milner  > wrote:
>
>> what came just before the log you posted?  why is weewx attempting to do 
>> a catchup? had weewx just been started?  had communications been lost for 
>> some reason? We need to know what is causing weewx to attempt a catchup in 
>> the first place.  You can never post too much log
>>
>>
>>
>>
>> On Wednesday, 16 October 2019 13:52:51 UTC+3, Andrea Cecilia wrote:
>>>
>>> here it is. As you can see, there is no "added record [...] to 
>>> weewx.sdb" line, which indicates that it is not downloading data from the 
>>> datalogger, and the reson (I think) is explained in the highlighted line.
>>>
>>> Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Getting archive 
>>> packets since 2019-10-16 09:05:00 CEST (1571209500)
>>> Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of 
>>> console successful
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Retrieving 5 page(s
>>> ); starting index= 4
>>> *Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: DMPAFT complete: 
>>> page timestamp 2019-10-15 13:20:00 CEST (1571138400) less than final 
>>> timestamp 2019-10-16 09:05:00 CEST (1571209500)*
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Catch up complete.
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running 
>>> reports for latest time in the database.
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Requesting 200 
>>> LOOP packets.
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running 
>>> report 'StandardReport'
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of 
>>> console successful
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Found 
>>> configuration file /home/weewx/skins/Standard/skin.conf for report 
>>> 'StandardReport'
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: cheetahgenerator: using 
>>> search list ['weewx.cheetahgenerator.Almanac', 
>>> 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', '
>>> weewx.ch
>>> eetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 
>>> 'weewx.cheetahgenerator.Extras']
>>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: manager: Daily summary 
>>> version is 2.0
>>> Oct 16 10:30:17 raspberrypi weewx-vp2[511]: cheetahgenerator: Generated 
>>> 16 files for report StandardReport in 2.31 seconds
>>> Oct 16 10:30:17 raspberrypi weewx-vp2[511]: manager: Daily summary 
>>> version is 2.0
>>> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: imagegenerator: Generated 15 
>>> images for StandardReport in 1.36 seconds
>>> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: copygenerator: copied 0 
>>> files to /home/weewx/public_html/vp2
>>> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: reportengine: Running 
>>> report 'FTP'
>>> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: reportengine: Found 
>>> configuration file /home/weewx/skins/Ftp/skin.conf for report 'FTP'
>>> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Attempting 
>>> connection to ftp.meteoregionelazio.it
>>> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Connected to ftp.
>>> meteoregionelazio.it
>>> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Uploaded file /
>>> www.meteoregionelazio.it/stazioni/soriano/weewx/vp2/daypond.png
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/33dfe43a-f6d8-4131-b7d3-b5d4e8415b4d%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 

[weewx-user] Re: Weather Underground Upload Fails

[Ford Smith]

weewx 3.9.2

python 2.7.16

On Wednesday, October 16, 2019 at 8:51:35 AM UTC-4, Ford Smith wrote:
>
> Until a brief power failure the other day, my weewx reading an Accurite 
> weather station was performing perfectly on a Raspberry Pi 4. Since then, 
> the upload to Weather Underground has failed. I've reinstalled weewx, even 
> created a new PWS on Underground, and finally turned Debug on. Apparently, 
> the problem  is:
>
> *Oct 16 08:40:25 raspberrypi weewx[3114]: restx: Wunderground-PWS: Failed 
> upload attempt 2:  certificate verify*
> I've searched for how to correct this Certificate problem and can find no 
> answers.
> Help!!
>

-- 
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/0da2fbea-457b-40d4-9f95-214e57e9ff36%40googlegroups.com.

Re: [weewx-user] Weather Underground Upload Fails

[Wade Graham]

When my unattended Pi 3B running weewx goes down for a longer time it takes
a while until Wunderground starts displaying data after the Pi boots up.

I think Wunderground may blocks data for a period of time until there is a
steady transmit rate.
Weewx is set to Rapid Fire.

On Wed, Oct 16, 2019 at 8:51 AM Ford Smith  wrote:

> Until a brief power failure the other day, my weewx reading an Accurite
> weather station was performing perfectly on a Raspberry Pi 4. Since then,
> the upload to Weather Underground has failed. I've reinstalled weewx, even
> created a new PWS on Underground, and finally turned Debug on. Apparently,
> the problem  is:
>
> *Oct 16 08:40:25 raspberrypi weewx[3114]: restx: Wunderground-PWS: Failed
> upload attempt 2:  certificate verify*
> I've searched for how to correct this Certificate problem and can find no
> answers.
> Help!!
>
> --
> 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/6a094f7e-ee95-4dcc-9dbe-076314d118bf%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/CAA%2B5DqwUXpHnCLSy5JZ1WWNo%2B1TpNeRqXzgC%3DecupZ2zof-63Q%40mail.gmail.com.

[weewx-user] Re: Sunshine Time

[Andrew Milner]

check your file - it looks as though there is now a 'stray' letter v in the 
file as a result of your editing!!  A typo of somekind clearly!!



On Wednesday, 16 October 2019 14:57:33 UTC+3, Stefan wrote:
>
> Thx Gary.
> I made the change. However, it does not work either. There is still the 
> error message:
>
> Oct 16 13:54:28 raspberrypi weewx[12153]: engine: Caught unrecoverable 
> exception in engine:
> Oct 16 13:54:28 raspberrypi weewx[12153]:   name 'v' is not defined
> Oct 16 13:54:28 raspberrypi weewx[12153]:   Traceback (most recent 
> call last):
> Oct 16 13:54:28 raspberrypi weewx[12153]: File 
> "/usr/share/weewx/weewx/engine.py", line 884, in main
> Oct 16 13:54:28 raspberrypi weewx[12153]:   engine = 
> engine_class(config_dict)
> Oct 16 13:54:28 raspberrypi weewx[12153]: File 
> "/usr/share/weewx/weewx/engine.py", line 78, in __init__
> Oct 16 13:54:28 raspberrypi weewx[12153]:   
> self.loadServices(config_dict)
> Oct 16 13:54:28 raspberrypi weewx[12153]: File 
> "/usr/share/weewx/weewx/engine.py", line 142, in loadServices
> Oct 16 13:54:28 raspberrypi weewx[12153]:   
> self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))
> Oct 16 13:54:28 raspberrypi weewx[12153]: File 
> "/usr/share/weewx/weeutil/weeutil.py", line 1130, in _get_object
> Oct 16 13:54:28 raspberrypi weewx[12153]:   mod = 
> __import__(module)
> Oct 16 13:54:28 raspberrypi weewx[12153]: File 
> "/usr/share/weewx/user/radiationhours.py", line 174, in 
> Oct 16 13:54:28 raspberrypi weewx[12153]:   v
> Oct 16 13:54:28 raspberrypi weewx[12153]:   NameError: name 'v' is 
> not defined
> Oct 16 13:54:28 raspberrypi weewx[12153]:   Exiting.
>
>
> Am Mittwoch, 16. Oktober 2019 09:27:48 UTC+2 schrieb gjr80:
>>
>> OK, essentially the same file but double spaced. The problem looks like 
>> it is due to field radiation being either missing or None. Try changing 
>> the following line:
>>
>> syslog.syslog(syslog.LOG_DEBUG, "Calculated sunshine_hours = %f, based 
>> on radiation = %f, and min_sunshine = %f" %
>>
>> to
>>
>> syslog.syslog(syslog.LOG_DEBUG, "Calculated sunshine_hours = %f, based 
>> on radiation = %s, and min_sunshine = %f" %
>>
>> You will need to restart WeeWX for the change to take effect.
>>
>> Gary
>>
>> On Wednesday, 16 October 2019 16:50:00 UTC+10, Stefan wrote:
>>>
>>> Hello Gray.
>>>
>>> Here is the Script. Thx for Help.
>>>
>>> Am Mittwoch, 16. Oktober 2019 07:47:43 UTC+2 schrieb gjr80:

 Chances are field radiation does not exist in an archive record or it 
 is set to None. I am afraid if you want any further help you are going to 
 have to post the copy of radiationhours.py that you are using; the 
 version in the repo you linked only has 106 lines of code and the error 
 trace you posted indicates the error is at line 203.

 Gary

 On Wednesday, 16 October 2019 15:26:42 UTC+10, Stefan wrote:
>
> Hello.
>
> The problem has reappeared today. Weewx stops the work. I have not 
> changed the script, not adjusted to the threshold. This is still on 
> 120W min. It ran until this morning without problems. But again this 
> error message.
>
> Oct 16 07:22:48 raspberrypi weewx[14709]: engine: Caught unrecoverable 
> exception in engine:
> Oct 16 07:22:48 raspberrypi weewx[14709]:   float argument 
> required, not NoneType
> Oct 16 07:22:48 raspberrypi weewx[14709]:   Traceback (most 
> recent call last):
> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
> "/usr/share/weewx/weewx/engine.py", line 890, in main
> Oct 16 07:22:48 raspberrypi weewx[14709]:   engine.run()
> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
> "/usr/share/weewx/weewx/engine.py", line 160, in run
> Oct 16 07:22:48 raspberrypi weewx[14709]:   
> self.dispatchEvent(weewx.Event(weewx.STARTUP))
> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
> "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
> Oct 16 07:22:48 raspberrypi weewx[14709]:   callback(event)
> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
> "/usr/share/weewx/weewx/engine.py", line 520, in startup
> Oct 16 07:22:48 raspberrypi weewx[14709]:   
> self._catchup(self.engine.console.genStartupRecords)
> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
> "/usr/share/weewx/weewx/engine.py", line 635, in _catchup
> Oct 16 07:22:48 raspberrypi weewx[14709]:   
> origin='hardware'))
> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
> "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
> Oct 16 07:22:48 raspberrypi weewx[14709]:   callback(event)
> Oct 16 07:22:

Re: [weewx-user] Weather Underground Upload Fails

[Thomas Keffer]

What version of WeeWX?

What version of Python?

Earlier version of WeeWX posted using http instead of https.

On Wed, Oct 16, 2019 at 5:51 AM Ford Smith  wrote:

> Until a brief power failure the other day, my weewx reading an Accurite
> weather station was performing perfectly on a Raspberry Pi 4. Since then,
> the upload to Weather Underground has failed. I've reinstalled weewx, even
> created a new PWS on Underground, and finally turned Debug on. Apparently,
> the problem  is:
>
> *Oct 16 08:40:25 raspberrypi weewx[3114]: restx: Wunderground-PWS: Failed
> upload attempt 2:  certificate verify*
> I've searched for how to correct this Certificate problem and can find no
> answers.
> Help!!
>
> --
> 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/6a094f7e-ee95-4dcc-9dbe-076314d118bf%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/CAPq0zEB6vyPUiYWgC8XnG-aJ_9MZugPs2mrm6SstwvD-qaHnZQ%40mail.gmail.com.

[weewx-user] Weather Underground Upload Fails

[Ford Smith]

Until a brief power failure the other day, my weewx reading an Accurite 
weather station was performing perfectly on a Raspberry Pi 4. Since then, 
the upload to Weather Underground has failed. I've reinstalled weewx, even 
created a new PWS on Underground, and finally turned Debug on. Apparently, 
the problem  is:

*Oct 16 08:40:25 raspberrypi weewx[3114]: restx: Wunderground-PWS: Failed 
upload attempt 2: https://groups.google.com/d/msgid/weewx-user/6a094f7e-ee95-4dcc-9dbe-076314d118bf%40googlegroups.com.

[weewx-user] Re: Sunshine Time

[Stefan]

Thx Gary.
I made the change. However, it does not work either. There is still the 
error message:

Oct 16 13:54:28 raspberrypi weewx[12153]: engine: Caught unrecoverable 
exception in engine:
Oct 16 13:54:28 raspberrypi weewx[12153]:   name 'v' is not defined
Oct 16 13:54:28 raspberrypi weewx[12153]:   Traceback (most recent 
call last):
Oct 16 13:54:28 raspberrypi weewx[12153]: File 
"/usr/share/weewx/weewx/engine.py", line 884, in main
Oct 16 13:54:28 raspberrypi weewx[12153]:   engine = 
engine_class(config_dict)
Oct 16 13:54:28 raspberrypi weewx[12153]: File 
"/usr/share/weewx/weewx/engine.py", line 78, in __init__
Oct 16 13:54:28 raspberrypi weewx[12153]:   
self.loadServices(config_dict)
Oct 16 13:54:28 raspberrypi weewx[12153]: File 
"/usr/share/weewx/weewx/engine.py", line 142, in loadServices
Oct 16 13:54:28 raspberrypi weewx[12153]:   
self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))
Oct 16 13:54:28 raspberrypi weewx[12153]: File 
"/usr/share/weewx/weeutil/weeutil.py", line 1130, in _get_object
Oct 16 13:54:28 raspberrypi weewx[12153]:   mod = 
__import__(module)
Oct 16 13:54:28 raspberrypi weewx[12153]: File 
"/usr/share/weewx/user/radiationhours.py", line 174, in 
Oct 16 13:54:28 raspberrypi weewx[12153]:   v
Oct 16 13:54:28 raspberrypi weewx[12153]:   NameError: name 'v' is 
not defined
Oct 16 13:54:28 raspberrypi weewx[12153]:   Exiting.


Am Mittwoch, 16. Oktober 2019 09:27:48 UTC+2 schrieb gjr80:
>
> OK, essentially the same file but double spaced. The problem looks like it 
> is due to field radiation being either missing or None. Try changing the 
> following line:
>
> syslog.syslog(syslog.LOG_DEBUG, "Calculated sunshine_hours = %f, based on 
> radiation = %f, and min_sunshine = %f" %
>
> to
>
> syslog.syslog(syslog.LOG_DEBUG, "Calculated sunshine_hours = %f, based on 
> radiation = %s, and min_sunshine = %f" %
>
> You will need to restart WeeWX for the change to take effect.
>
> Gary
>
> On Wednesday, 16 October 2019 16:50:00 UTC+10, Stefan wrote:
>>
>> Hello Gray.
>>
>> Here is the Script. Thx for Help.
>>
>> Am Mittwoch, 16. Oktober 2019 07:47:43 UTC+2 schrieb gjr80:
>>>
>>> Chances are field radiation does not exist in an archive record or it 
>>> is set to None. I am afraid if you want any further help you are going to 
>>> have to post the copy of radiationhours.py that you are using; the 
>>> version in the repo you linked only has 106 lines of code and the error 
>>> trace you posted indicates the error is at line 203.
>>>
>>> Gary
>>>
>>> On Wednesday, 16 October 2019 15:26:42 UTC+10, Stefan wrote:

 Hello.

 The problem has reappeared today. Weewx stops the work. I have not 
 changed the script, not adjusted to the threshold. This is still on 
 120W min. It ran until this morning without problems. But again this 
 error message.

 Oct 16 07:22:48 raspberrypi weewx[14709]: engine: Caught unrecoverable 
 exception in engine:
 Oct 16 07:22:48 raspberrypi weewx[14709]:   float argument 
 required, not NoneType
 Oct 16 07:22:48 raspberrypi weewx[14709]:   Traceback (most 
 recent call last):
 Oct 16 07:22:48 raspberrypi weewx[14709]: File 
 "/usr/share/weewx/weewx/engine.py", line 890, in main
 Oct 16 07:22:48 raspberrypi weewx[14709]:   engine.run()
 Oct 16 07:22:48 raspberrypi weewx[14709]: File 
 "/usr/share/weewx/weewx/engine.py", line 160, in run
 Oct 16 07:22:48 raspberrypi weewx[14709]:   
 self.dispatchEvent(weewx.Event(weewx.STARTUP))
 Oct 16 07:22:48 raspberrypi weewx[14709]: File 
 "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
 Oct 16 07:22:48 raspberrypi weewx[14709]:   callback(event)
 Oct 16 07:22:48 raspberrypi weewx[14709]: File 
 "/usr/share/weewx/weewx/engine.py", line 520, in startup
 Oct 16 07:22:48 raspberrypi weewx[14709]:   
 self._catchup(self.engine.console.genStartupRecords)
 Oct 16 07:22:48 raspberrypi weewx[14709]: File 
 "/usr/share/weewx/weewx/engine.py", line 635, in _catchup
 Oct 16 07:22:48 raspberrypi weewx[14709]:   
 origin='hardware'))
 Oct 16 07:22:48 raspberrypi weewx[14709]: File 
 "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
 Oct 16 07:22:48 raspberrypi weewx[14709]:   callback(event)
 Oct 16 07:22:48 raspberrypi weewx[14709]: File 
 "/usr/share/weewx/user/radiationhours.py", line 203, in newArchiveRecord
 Oct 16 07:22:48 raspberrypi weewx[14709]:   
 (event.record['sunshine_hours'], radiation, self.min_sunshine))
 Oct 16 07:22:48 raspberrypi weewx[14709]:   TypeError: float 
 argume

Re: [weewx-user] Re: Davis Datalogger bug

[Thomas Keffer]

This is likely a case of memory corruption, brought on by time not being
synced during the reboot, due to the lack of an on-board clock. It was not
a problem with Weatherlink because you were not running it on an RPi.

See the section *WeeWX generated HTML pages, but does not update them
* in
the User's Guide.

But, as Andrew suggested, we would have to see the log from startup to be
sure.

-tk

On Wed, Oct 16, 2019 at 4:04 AM Andrew Milner 
wrote:

> what came just before the log you posted?  why is weewx attempting to do a
> catchup? had weewx just been started?  had communications been lost for
> some reason? We need to know what is causing weewx to attempt a catchup in
> the first place.  You can never post too much log
>
>
>
>
> On Wednesday, 16 October 2019 13:52:51 UTC+3, Andrea Cecilia wrote:
>>
>> here it is. As you can see, there is no "added record [...] to weewx.sdb"
>> line, which indicates that it is not downloading data from the datalogger,
>> and the reson (I think) is explained in the highlighted line.
>>
>> Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Getting archive
>> packets since 2019-10-16 09:05:00 CEST (1571209500)
>> Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of
>> console successful
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Retrieving 5 page(s
>> ); starting index= 4
>> *Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: DMPAFT complete:
>> page timestamp 2019-10-15 13:20:00 CEST (1571138400) less than final
>> timestamp 2019-10-16 09:05:00 CEST (1571209500)*
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Catch up complete.
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running
>> reports for latest time in the database.
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Requesting 200 LOOP
>> packets.
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running report
>> 'StandardReport'
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of
>> console successful
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Found
>> configuration file /home/weewx/skins/Standard/skin.conf for report
>> 'StandardReport'
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: cheetahgenerator: using
>> search list ['weewx.cheetahgenerator.Almanac',
>> 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', '
>> weewx.ch
>> eetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo',
>> 'weewx.cheetahgenerator.Extras']
>> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: manager: Daily summary
>> version is 2.0
>> Oct 16 10:30:17 raspberrypi weewx-vp2[511]: cheetahgenerator: Generated
>> 16 files for report StandardReport in 2.31 seconds
>> Oct 16 10:30:17 raspberrypi weewx-vp2[511]: manager: Daily summary
>> version is 2.0
>> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: imagegenerator: Generated 15
>> images for StandardReport in 1.36 seconds
>> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: copygenerator: copied 0
>> files to /home/weewx/public_html/vp2
>> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: reportengine: Running report
>> 'FTP'
>> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: reportengine: Found
>> configuration file /home/weewx/skins/Ftp/skin.conf for report 'FTP'
>> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Attempting
>> connection to ftp.meteoregionelazio.it
>> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Connected to ftp.
>> meteoregionelazio.it
>> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Uploaded file /www
>> .meteoregionelazio.it/stazioni/soriano/weewx/vp2/daypond.png
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/33dfe43a-f6d8-4131-b7d3-b5d4e8415b4d%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/CAPq0zEC3U_XKBVetAPa%3DehsaPmDKxiDem4xVp9yDZnZrBiEXJw%40mail.gmail.com.

Re: [weewx-user] weatherlink live

[Thomas Keffer]

No, but you are reminding me to call Davis.

On Wed, Oct 16, 2019 at 1:20 AM Pierre Chevallier 
wrote:

> Do you have any date for the release?
>
> Many thanks for your work.
> Regards.
>
> Le dimanche 30 juin 2019 14:00:22 UTC+2, Thomas Keffer a écrit :
>>
>> Unfortunately, no. It will get done, but it may take some time. See issue
>> #412 .
>>
>> -tk
>>
>> On Fri, Jun 28, 2019 at 7:06 PM parallelsys  wrote:
>>
>>> Is there a driver for weatherlink live?
>>>
>>> Thanks!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/375c1afc-0f96-4de0-a4e9-21038aec918d%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/323a5b70-ad40-4fb6-a31e-5a1b26d00431%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/CAPq0zEDP4Xbq7-9MNvGxZqRT%3DKn3ALWhbGvQxyo1VtNrkxJ5fw%40mail.gmail.com.

[weewx-user] Re: Davis Datalogger bug

[Andrew Milner]

what came just before the log you posted?  why is weewx attempting to do a 
catchup? had weewx just been started?  had communications been lost for 
some reason? We need to know what is causing weewx to attempt a catchup in 
the first place.  You can never post too much log




On Wednesday, 16 October 2019 13:52:51 UTC+3, Andrea Cecilia wrote:
>
> here it is. As you can see, there is no "added record [...] to weewx.sdb" 
> line, which indicates that it is not downloading data from the datalogger, 
> and the reson (I think) is explained in the highlighted line.
>
> Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Getting archive 
> packets since 2019-10-16 09:05:00 CEST (1571209500)
> Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of 
> console successful
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Retrieving 5 page(s); 
> starting index= 4
> *Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: DMPAFT complete: 
> page timestamp 2019-10-15 13:20:00 CEST (1571138400) less than final 
> timestamp 2019-10-16 09:05:00 CEST (1571209500)*
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Catch up complete.
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running reports 
> for latest time in the database.
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Requesting 200 LOOP 
> packets.
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running report 
> 'StandardReport'
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of 
> console successful
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Found 
> configuration file /home/weewx/skins/Standard/skin.conf for report 
> 'StandardReport'
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: cheetahgenerator: using 
> search list ['weewx.cheetahgenerator.Almanac', 
> 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', '
> weewx.ch
> eetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 
> 'weewx.cheetahgenerator.Extras']
> Oct 16 10:30:15 raspberrypi weewx-vp2[511]: manager: Daily summary 
> version is 2.0
> Oct 16 10:30:17 raspberrypi weewx-vp2[511]: cheetahgenerator: Generated 16 
> files for report StandardReport in 2.31 seconds
> Oct 16 10:30:17 raspberrypi weewx-vp2[511]: manager: Daily summary 
> version is 2.0
> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: imagegenerator: Generated 15 
> images for StandardReport in 1.36 seconds
> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: copygenerator: copied 0 files 
> to /home/weewx/public_html/vp2
> Oct 16 10:30:18 raspberrypi weewx-vp2[511]: reportengine: Running report 
> 'FTP'
> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: reportengine: Found 
> configuration file /home/weewx/skins/Ftp/skin.conf for report 'FTP'
> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Attempting 
> connection to ftp.meteoregionelazio.it
> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Connected to ftp.
> meteoregionelazio.it
> Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Uploaded file /www.
> meteoregionelazio.it/stazioni/soriano/weewx/vp2/daypond.png
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/33dfe43a-f6d8-4131-b7d3-b5d4e8415b4d%40googlegroups.com.

[weewx-user] Re: Davis Datalogger bug

[Andrea Cecilia]

here it is. As you can see, there is no "added record [...] to weewx.sdb" 
line, which indicates that it is not downloading data from the datalogger, 
and the reson (I think) is explained in the highlighted line.

Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Getting archive 
packets since 2019-10-16 09:05:00 CEST (1571209500)
Oct 16 10:30:14 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of 
console successful
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Retrieving 5 page(s); 
starting index= 4
*Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: DMPAFT complete: page 
timestamp 2019-10-15 13:20:00 CEST (1571138400) less than final timestamp 
2019-10-16 09:05:00 CEST (1571209500)*
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Catch up complete.
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running reports 
for latest time in the database.
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Requesting 200 LOOP 
packets.
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Running report 
'StandardReport'
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: vantage: Gentle wake up of 
console successful
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: reportengine: Found 
configuration file /home/weewx/skins/Standard/skin.conf for report 
'StandardReport'
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: cheetahgenerator: using search 
list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 
'weewx.cheetahgenerator.Current', 'weewx.ch
eetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 
'weewx.cheetahgenerator.Extras']
Oct 16 10:30:15 raspberrypi weewx-vp2[511]: manager: Daily summary version 
is 2.0
Oct 16 10:30:17 raspberrypi weewx-vp2[511]: cheetahgenerator: Generated 16 
files for report StandardReport in 2.31 seconds
Oct 16 10:30:17 raspberrypi weewx-vp2[511]: manager: Daily summary version 
is 2.0
Oct 16 10:30:18 raspberrypi weewx-vp2[511]: imagegenerator: Generated 15 
images for StandardReport in 1.36 seconds
Oct 16 10:30:18 raspberrypi weewx-vp2[511]: copygenerator: copied 0 files 
to /home/weewx/public_html/vp2
Oct 16 10:30:18 raspberrypi weewx-vp2[511]: reportengine: Running report 
'FTP'
Oct 16 10:30:19 raspberrypi weewx-vp2[511]: reportengine: Found 
configuration file /home/weewx/skins/Ftp/skin.conf for report 'FTP'
Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Attempting 
connection to ftp.meteoregionelazio.it
Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Connected to ftp.
meteoregionelazio.it
Oct 16 10:30:19 raspberrypi weewx-vp2[511]: ftpupload: Uploaded file /www.
meteoregionelazio.it/stazioni/soriano/weewx/vp2/daypond.png


-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/655889ce-dbe2-475a-8bc3-5b253a512bc2%40googlegroups.com.

[weewx-user] Re: Davis Datalogger bug

[Andrew Milner]

attaching the log not just a line may let people offer more advice.




On Wednesday, 16 October 2019 13:05:21 UTC+3, Andrea Cecilia wrote:
>
> Hi there,
> I'm working with lot of Davis stations connected to weewx, and I noticed 
> that there exists a frequent bug which I'm trying to describe now:
>
> sometimes it is like the datalogger gest freezed, so that tweewx cannot 
> download data from it. The only way I tried which is working is banally 
> giving a
>
> /home/weewx/bin/wee_device --clear-memory
>
> but in this way I lose the data inside the datalogger.
>
> In syslog I can see a string like
>
> page timestamp less than final timestamp
>
> which is what I think the problem is. Is there a way to solve this without 
> clearing the data inside the datalogger?
>
> This must be a bug of weewx, because with Weatherlink I never had a 
> problem like this.
>
> Thank you
>
>
>
>
>

-- 
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/f231bb25-9d51-4c2b-a8e7-d8a00b357edc%40googlegroups.com.

[weewx-user] Davis Datalogger bug

[Andrea Cecilia]

Hi there,
I'm working with lot of Davis stations connected to weewx, and I noticed 
that there exists a frequent bug which I'm trying to describe now:

sometimes it is like the datalogger gest freezed, so that tweewx cannot 
download data from it. The only way I tried which is working is banally 
giving a

/home/weewx/bin/wee_device --clear-memory

but in this way I lose the data inside the datalogger.

In syslog I can see a string like

page timestamp less than final timestamp

which is what I think the problem is. Is there a way to solve this without 
clearing the data inside the datalogger?

This must be a bug of weewx, because with Weatherlink I never had a problem 
like this.

Thank you




-- 
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/83c98e4c-b7e8-4cff-8ea9-f4c766cb6528%40googlegroups.com.

[weewx-user] Davis Datalogger freezing bug

[Andrea Cecilia]

Hi there,
I'm working with lot of Davis stations connected to weewx, and I noticed 
that there exists a frequent bug which I'm trying to describe now:
if for some reason the current goes down and so the Raspberry Pi 3 turns 
off, when it gets turned on again 

sometimes it is like the datalogger gest freezed, so that tweewx cannot 
download data from it. The only way I tried which is working is banally 
giving a

/home/weewx/bin/wee_device --clear-memory

but in this way I lose the data inside the datalogger.

In syslog I can see a string like

page timestamp less than final timestamp

which is what I think the problem is. Is there a way to solve this without 
clearing the data inside the datalogger?

Thank you




-- 
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/3c07d909-ab0f-43aa-b5fc-e04223ae71dd%40googlegroups.com.

Re: [weewx-user] weatherlink live

[Pierre Chevallier]

Do you have any date for the release?

Many thanks for your work.
Regards.

Le dimanche 30 juin 2019 14:00:22 UTC+2, Thomas Keffer a écrit :
>
> Unfortunately, no. It will get done, but it may take some time. See issue 
> #412 .
>
> -tk
>
> On Fri, Jun 28, 2019 at 7:06 PM parallelsys  > wrote:
>
>> Is there a driver for weatherlink live?
>>
>> Thanks!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/375c1afc-0f96-4de0-a4e9-21038aec918d%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/323a5b70-ad40-4fb6-a31e-5a1b26d00431%40googlegroups.com.

Re: [weewx-user] Re: Did someone test Weewx in Raspbian Buster?

[Matt]

Thanks Susan. I managed to get it working using Ian's suggestions and a bit
of trial and error.  It's great by the way!

On Wed, 16 Oct 2019, 02:48 Susan Mackay,  wrote:

> Hi Matt,
>
> I have not tried the driver on anything but Rasbian Stretch and against
> V3.6.2. (Still on the 'to do' list as is re-writing for Python 3.)
>
> Perhaps Ian Rich can provide some details of what he did as he seems to
> have this configuration working.
>
> Having said that the "sudo" should be the first part of each command.
>
> Susan
>
> --
> 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/d213d203-41ab-4725-8cbd-9c5bddd10954%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/CAMz6Xq59%2B48YDDUNm8UawaD5q5PEAW_w%3D1gxdDk4Nn47tZgLXg%40mail.gmail.com.

[weewx-user] Re: Sunshine Time

[gjr80]

OK, essentially the same file but double spaced. The problem looks like it 
is due to field radiation being either missing or None. Try changing the 
following line:

syslog.syslog(syslog.LOG_DEBUG, "Calculated sunshine_hours = %f, based on 
radiation = %f, and min_sunshine = %f" %

to

syslog.syslog(syslog.LOG_DEBUG, "Calculated sunshine_hours = %f, based on 
radiation = %s, and min_sunshine = %f" %

You will need to restart WeeWX for the change to take effect.

Gary

On Wednesday, 16 October 2019 16:50:00 UTC+10, Stefan wrote:
>
> Hello Gray.
>
> Here is the Script. Thx for Help.
>
> Am Mittwoch, 16. Oktober 2019 07:47:43 UTC+2 schrieb gjr80:
>>
>> Chances are field radiation does not exist in an archive record or it is 
>> set to None. I am afraid if you want any further help you are going to have 
>> to post the copy of radiationhours.py that you are using; the version in 
>> the repo you linked only has 106 lines of code and the error trace you 
>> posted indicates the error is at line 203.
>>
>> Gary
>>
>> On Wednesday, 16 October 2019 15:26:42 UTC+10, Stefan wrote:
>>>
>>> Hello.
>>>
>>> The problem has reappeared today. Weewx stops the work. I have not 
>>> changed the script, not adjusted to the threshold. This is still on 
>>> 120W min. It ran until this morning without problems. But again this 
>>> error message.
>>>
>>> Oct 16 07:22:48 raspberrypi weewx[14709]: engine: Caught unrecoverable 
>>> exception in engine:
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   float argument 
>>> required, not NoneType
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   Traceback (most 
>>> recent call last):
>>> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 890, in main
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   engine.run()
>>> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 160, in run
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   
>>> self.dispatchEvent(weewx.Event(weewx.STARTUP))
>>> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   callback(event)
>>> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 520, in startup
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   
>>> self._catchup(self.engine.console.genStartupRecords)
>>> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 635, in _catchup
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   
>>> origin='hardware'))
>>> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   callback(event)
>>> Oct 16 07:22:48 raspberrypi weewx[14709]: File 
>>> "/usr/share/weewx/user/radiationhours.py", line 203, in newArchiveRecord
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   
>>> (event.record['sunshine_hours'], radiation, self.min_sunshine))
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   TypeError: float 
>>> argument required, not NoneType
>>> Oct 16 07:22:48 raspberrypi weewx[14709]:   Exiting.
>>>
>>>
>>> Am Samstag, 12. Oktober 2019 11:46:57 UTC+2 schrieb gjr80:

 If you must modify the code then yes that will do what you want 
 provided there is no min_sunshine setting in weewx.conf.

 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/dcf9ca43-ef36-4699-bd75-2d705133c54f%40googlegroups.com.