[weewx-user] Re: Exclude list or Overwrite behaviour for RSync Report

[Chris Alemany]

Thanks for the hints Vince. I ended up looking through the old Wiki and 
came upon this page about backing up databases with the rsync report and 
how you can spit rsync into multiple skins.

https://github.com/weewx/weewx/wiki/Using-the-RSYNC-skin-as-a-backup-solution

My use case is that I'm using divumWX/weather34 which has its own builtin 
rsync so there seems to be some conflict between the two as divumWX is a 
subdirectory of the main htmlroot.

Like you said, it does not appear that there is any way to add options to 
the builtin weewx rsync.py file or any extra options in the skin or 
weewx.conf. So the alternative is to narrow what weewx is uploading by 
pointing it to subdirectories rather than updating the entire public_html 
directory and in that way excluding the directory I don't want weewx to 
deal with.

I might add a feature request to the GitHub to add options like you 
suggested.
Thanks!
Chris
On Thursday, March 21, 2024 at 11:15:03 AM UTC-7 vince wrote:

> Check out the options in https://ss64.com/bash/rsync_options.htm 
> l and see if you can make 
> vanilla rsync from the shell do (or not do) what you want.  If that doesn't 
> solve it, I'd doubt weewx can help much there as a wrapper over rsync.   
> The -u option might be what you're looking for possibly.
>
> But the rsync uploader (rsyncupload.py) doesn't seem to have the ability 
> to provide additional flags to the underlying rsync command.  I'm sure Tom 
> would appreciate a PR to add more functionality if you can figure out an 
> incantation works and some more general purpose thing to add to weewx 
> (possibly something like a rsync_options = "whatever" thing?).
>
> That said - if you're trying to use weewx as the source of the 
> authoritative file to upload something, why would you externally mess with 
> the file(s) on the far side after that ?  I'm sure there's some use case 
> you have but I can't think of a reason why it would be necessary
>
> On Thursday, March 21, 2024 at 9:34:27 AM UTC-7 Chris Alemany wrote:
>
>> And just to be complete, this is on weewx 5.0.2, pip install on Debian.
>>
>> On Thursday, March 21, 2024 at 9:19:55 AM UTC-7 Chris Alemany wrote:
>>
>>> Good morning all, 
>>>
>>> I’m having some trouble with the weewx RSync report overwriting files 
>>> that have changed on the remote side independent of weewx. Are there any 
>>> provisions in the RSync report to exclude a list of files and/or folders 
>>> (including in skins) or otherwise change the way the process operates so 
>>> that files that exist on both ends but with a newer timestamp on the remote 
>>> side don’t get overwritten by the older local file? 
>>> Thanks very much 
>>>
>>> Chris 
>>> https://alberniweather.ca 
>>>
>>>

-- 
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/d7d4cf73-3729-4793-91de-780b334fa6cdn%40googlegroups.com.

Re: [weewx-user] Re: New install rtldavis & weewx 5

[vince]

No - I don't think multiple rtldavis processes are normal.  Mine only shows 
one.

pi@pi5:~ $ sudo systemctl status weewx
● weewx.service - WeeWX weather system
 Loaded: loaded (/etc/systemd/system/weewx.service; enabled; preset: 
enabled)
 Active: active (running) since Mon 2024-04-01 13:47:45 PDT; 2min 17s 
ago
   Docs: https://weewx.com/docs
   Main PID: 871 (python3)
  Tasks: 14 (limit: 4388)
CPU: 5.050s
 CGroup: /system.slice/weewx.service
 ├─871 /home/pi/weewx-venv/bin/python3 
/home/pi/weewx-venv/lib/python3.11/site-packages/weewxd.py 
/home/pi/weewx-data/weewx.conf
 └─911 /home/pi/work/bin/rtldavis -tf US -tr 1

Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: 13:47:45.728787 
BlockSize: 512
Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: 13:47:45.728790 
BufferLength: 2048
Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: Detached kernel 
driver
Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: Found Rafael 
Micro R820T tuner
Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: Exact sample 
rate is: 268800.001367 Hz
Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: 13:47:46.323864 
GetTunerGain: 0 Db
Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: 13:47:46.323879 
SetFreqCorrection 0 ppm Successful
Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: Allocating 1 
zero-copy buffers
Apr 01 13:47:46 pi5 weewxd[871]: DEBUG user.rtldavis: info: 13:47:46.327138 
Init channels: wait max 135 seconds for a message of each transmitter
Apr 01 13:49:45 pi5 weewxd[871]: DEBUG user.rtldavis: info: 13:49:45.776726 
TRANSMITTER 0 SEEN

I would stop weewx and kill any rtldavis process(es) that still remain. 
 Sometimes they keep running unless you kill -9 them.

If you needed to use sudo manually then you probably need to add the weewx 
user to the correct groups to be able to attach to the rtlsdr dongle 
hardware. This might help if you wanted to give it a try.

#--- add weewx to all the groups typical 'pi' is in
# which should permit binding to non-privileged ports and typical hardware
for g in adm dialout cdrom sudo audio video plugdev games users input 
render netdev gpio i2c spi
do
  sudo usermod -aG $g weewx
done

Then 'sudo systemctl start weewx' and look at your logs for errors as 
always..

On Monday, April 1, 2024 at 1:08:06 PM UTC-7 Pierre Decamps wrote:

> Yes complete path was full.
>
> I tried adding sudo before the command in weewx.conf and it works !
>
>  
>
> Now I have two instances of rtldavis running, is it normal ?
>
>  
>
> pi@weatherpi:~/work/bin $ sudo systemctl status weewx
>
> weewx.service - WeeWX
>
>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
> preset: enabled)
>
>  Active: active (running) since Mon 2024-04-01 22:05:24 CEST; 2s ago
>
>Docs: https://weewx.com/docs
>
>Main PID: 7138 (weewxd)
>
>   Tasks: 15 (limit: 1595)
>
> CPU: 1.130s
>
>  CGroup: /system.slice/weewx.service
>
>  ├─7138 /usr/bin/python3 /usr/local/bin/weewxd 
> /etc/weewx/weewx.conf
>
>  ├─7141 sudo /home/pi/work/bin/rtldavis -fc 5 -ppm 1 -tf 
> EU -tr 1
>
>  └─7144 /home/pi/work/bin/rtldavis -fc 5 -ppm 1 -tf EU -tr 
> 1
>
>  
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.restx: PWSweather: 
> Posting not enabled.
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.restx: CWOP: Posting 
> not enabled.
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.restx: WOW: Posting not 
> enabled.
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.restx: AWEKAS: Posting 
> not enabled.
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.engine: 'pyephem' 
> detected, extended almanac data is available
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewxd: Starting up weewx 
> version 5.0.2
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.engine: Using binding 
> 'wx_binding' to database 'weewx.sdb'
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.manager: Starting 
> backfill of daily summaries
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.manager: Daily 
> summaries up to date
>
> Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.engine: Starting main 
> packet loop.
>
>  
>
> *De : * au nom de vince 
> *Répondre à : *"weewx...@googlegroups.com" 
> *Date : *lundi 1 avril 2024 à 20:48
> *À : *weewx-user 
> *Objet : *[weewx-user] Re: New install rtldavis & weewx 5
>
>  
>
> Did you set the full path to the rtldavis binary in your weewx.conf file ? 
>
>  
>
> Mine that worked here (US) is here (link) 
>  
> if 
> you wanted to compare with yours
>
>  
>
> On Monday, April 1, 2024 at 9:36:00 AM UTC-7 Pierre Decamps wrote:
>
> Hi everybody,
>
>  
>
> I installed a Davis VP2 Pro Plus Wireless last week and made a fresh 
> install of weewx and rtldavis plugin.
>
>  
>
> 

Re: [weewx-user] Re: New install rtldavis & weewx 5

[Pierre Decamps]

Yes complete path was full.
I tried adding sudo before the command in weewx.conf and it works !

Now I have two instances of rtldavis running, is it normal ?

pi@weatherpi:~/work/bin $ sudo systemctl status weewx
weewx.service - WeeWX
 Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor preset: 
enabled)
 Active: active (running) since Mon 2024-04-01 22:05:24 CEST; 2s ago
   Docs: https://weewx.com/docs
   Main PID: 7138 (weewxd)
  Tasks: 15 (limit: 1595)
CPU: 1.130s
 CGroup: /system.slice/weewx.service
 ├─7138 /usr/bin/python3 /usr/local/bin/weewxd /etc/weewx/weewx.conf
 ├─7141 sudo /home/pi/work/bin/rtldavis -fc 5 -ppm 1 -tf EU -tr 
1
 └─7144 /home/pi/work/bin/rtldavis -fc 5 -ppm 1 -tf EU -tr 1

Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.restx: PWSweather: Posting 
not enabled.
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.restx: CWOP: Posting not 
enabled.
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.restx: WOW: Posting not 
enabled.
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.restx: AWEKAS: Posting not 
enabled.
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.engine: 'pyephem' detected, 
extended almanac data is available
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewxd: Starting up weewx version 
5.0.2
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.manager: Starting backfill 
of daily summaries
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.manager: Daily summaries up 
to date
Apr 01 22:05:25 weatherpi weewxd[7138]: INFO weewx.engine: Starting main packet 
loop.

De :  au nom de vince 
Répondre à : "weewx-user@googlegroups.com" 
Date : lundi 1 avril 2024 à 20:48
À : weewx-user 
Objet : [weewx-user] Re: New install rtldavis & weewx 5

Did you set the full path to the rtldavis binary in your weewx.conf file ?

Mine that worked here (US) is here 
(link)
 if you wanted to compare with yours

On Monday, April 1, 2024 at 9:36:00 AM UTC-7 Pierre Decamps wrote:
Hi everybody,

I installed a Davis VP2 Pro Plus Wireless last week and made a fresh install of 
weewx and rtldavis plugin.

When I checked status of weewx, I see it :

Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewxd: Starting up weewx version 
5.0.2
Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'
Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewx.manager: Starting backfill 
of daily summaries
Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.manager: Daily summaries up 
to date
Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.engine: Starting main packet 
loop.
Apr 01 18:21:32 weatherpi weewxd[2247]: ERROR user.rtldavis: err: 
Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.engine: Main loop exiting. 
Shutting engine down.
Apr 01 18:21:33 weatherpi weewxd[2247]: INFO user.rtldavis: shutdown process 
/home/pi/work/bin/rtldavis -fc 5 -ppm 1 -tf EU -tr 1
Apr 01 18:21:33 weatherpi weewxd[2247]: CRITICAL weewxd: Caught WeeWxIOError: 
rtldavis process is not running
Apr 01 18:21:33 weatherpi weewxd[2247]: CRITICAL weewxd:   Waiting 60.0 
seconds then retrying...

If I start /home/weewx/bin/user/rtldavis.py

18:25:42.266024 rtldavis.go VERSION=0.15
18:25:42.266426 tr=1 fc=5 ppm=0 gain=0 maxmissed=51 ex=0 receiveWindow=300 
actChan=[0] maxChan=1
18:25:42.266448 undefined=false verbose=false disableAfc=false deviceString=0
18:25:42.266690 BitRate: 19200
18:25:42.266708 SymbolLength: 14
18:25:42.266718 SampleRate: 268800
18:25:42.266726 Preamble: 1100101110001001
18:25:42.266734 PreambleSymbols: 16
18:25:42.266742 PreambleLength: 224
18:25:42.266750 PacketSymbols: 80
18:25:42.266758 PacketLength: 1120
18:25:42.266766 BlockSize: 512
18:25:42.266774 BufferLength: 2048
Found Rafael Micro R820T tuner
18:25:42.681319 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:0 
Transmitter:0}
Exact sample rate is: 268800.001367 Hz
18:25:42.854909 GetTunerGain: 0 Db
18:25:42.854949 SetFreqCorrection 0 ppm Successful
18:25:42.858456 Init channels: wait max 17 seconds for a message of each 
transmitter
Allocating 1 zero-copy buffers
Traceback (most recent call last):
  File "/etc/weewx/bin/user/./rtldavis.py", line 1366, in 
payload = lines[0].strip()
IndexError: list index out of range


And if I start the /home/pi/work/bin/rtldavis :

Found Rafael Micro R820T tuner
18:28:13.224537 tr=0 ch=0 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 0 0 
0 0 0 0 0 0]
18:28:13.224608 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:0 
Transmitter:0}
Exact sample rate is: 268800.001367 Hz
18:28:13.397912 GetTunerGain: 0 Db
18:28:13.397946 SetFreqCorrection 0 ppm Successful
Allocating 1 zero-copy buffers
18:28:13.401414 Init channels: wait max 17 seconds for a message of each 

Re: [weewx-user] Re: Change to daylight saving time stops data update

['John Kline' via weewx-user]

> If the key is to not mess with the console time near the DST boundary, why not just arrange for> clock synchronization to only happen once a day at noon?It is not the key.  You have to get unlucky to check the time during the window.  The main problem is when time is set back one hour (leaving DST).  I’ve found the archive record code creating a timestamp from Vantage time gets it wrong in the “fall back” hour—thinking we’re still in DST, thus getting duplicates when trying to insert archive records.On Apr 1, 2024, at 11:02 AM, Tom Keffer  wrote:If the key is to not mess with the console time near the DST boundary, why not just arrange for clock synchronization to only happen once a day at noon?On Monday, April 1, 2024 at 6:34:46 AM UTC-7 jo...@johnkline.com wrote:I’ve successfully fixed the time change issue on a fork of the vantage driver:chaunceygardiner/weewx-vantagenext: VantageNext is a WeeWX driver based on the Vantage driver that ships with WeeWX.github.comIt assumes a one hour change for daylight savings and one is required to enter DST enter and exit times in the VantageNext section of weewx.conf.During the time change window, set time is a no-op (since one cannot specify whether the time is in DST or not).  Also, during the window, get time will auto correct if the time is about 1 hour off.  Lastly, when the driver converts the archive records time, it is auto-adjusted if about an hour off.I don’t recommend switching to this driver as the vantage driver in weewx is better supported; but perhaps a similar approach could be taken.  It is tricky because it is hard to test this stuff. On Apr 1, 2024, at 8:00 AM, Simon Duane  wrote:From what I've read, it involves an interaction between a Weewx service which adjusts the VP2 console clock to eliminate drift  - by default, it checks every 5 hours and applies the correction when the error is bigger than 5 seconds. I would suggest that if the error is close to 1 hour rather than a little more than 5 seconds, then the correction should simply not be applied, because of the risk of this happening. Fixing it on the next cycle will be good enough.It happened to my Weewx v 4.9.1 + VP2 (for the first time) yesterday too and, because I have that archive parameter set to hardware, clearing the datalogger memory meant I lost about a day's data.On Sunday 31 March 2024 at 23:56:23 UTC+1 Stephen wrote:I have two Davis Vantage Pro 2 weather stations at different locations. Both stations stopped updating their web pages at 2.00am last night, the moment daylight saving started.I'm running Weewx v5.0.1 at both locations.  Both Vantage Pro2 consoles are configured to automatically change to DST.There is an old thread from 2017 about this problem here https://groups.google.com/g/weewx-user/c/rM2IDREAWiI/m/oloGcj7aAAAJ.Taking the advice in that thread I've got one of the stations working again by executing  weectl device --dump.  I've left the other station as it is at the moment.This has never happened before, but I wasn't running v5.0.1 this time last year.Any idea what's going on?



-- 
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/09e0d95f-ec44-4782-989f-d4ef3217ddadn%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/241ad3cb-213d-44d3-937a-bea2dabbb441n%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/EB142EE0-83B8-43DF-A251-5574AC3EACDC%40johnkline.com.

Re: [weewx-user] Re: weatherflowpdp timeout

[Glen Briggs]

To correct the issues, I had to use the correct sensor map (note the new
map for tempest) and I had to move the install to a new computer. The old
computer I was trying first was not working at all.



Glen Briggs
Grundy County MO

On Mon, Apr 1, 2024, 1:37 PM vince  wrote:

> And for others who'll run into this, what did you do ?
> Did you just need to line up your actual sensor id(s) correctly to match
> your hardware ?
>
> On Monday, April 1, 2024 at 5:41:56 AM UTC-7 Glen Briggs wrote:
>
>> I got it going. Thank you.
>>
>> Now to learn how to customize and setup things.
>>
>> On Sunday, March 31, 2024 at 10:28:40 PM UTC-5 vince wrote:
>>
>>>
>>> The usual mistake is people putting in their station id (not the sensor
>>> id) or removing the leading zeroes in the sensor id. In your case you have
>>> it configured to use an air and sky original old station with both having
>>> the same id numbers which is impossible.
>>>
>>> AR-00091987 and.SK-00091987 are clearly incorrect.
>>>
>>> You might to install my wfudptools app via pip and run the listener with
>>> the —raw option to tell you your correct sensor id(s). See
>>> https://pypi.org/project/wfudptools/ which has a link to the github
>>> page for usage examples
>>>
>>> On Sunday, March 31, 2024 at 8:02:13 PM UTC-7 Glen Briggs wrote:
>>>
 it appears to be running now, but i am getting nothing. no webpages, no
 data, no time outs, it just does nothing



 2024-03-31T21:30:54.734273-05:00 frost systemd[1]: Started
 weewx.service - WeeWX.
 2024-03-31T21:30:54.958929-05:00 frost weewxd[7210]: INFO __main__:
 Initializing weewxd version 5.0.2
 2024-03-31T21:30:54.959612-05:00 frost weewxd[7210]: INFO __main__:
 Command line: /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
 2024-03-31T21:30:54.959979-05:00 frost weewxd[7210]: INFO __main__:
 Using Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
 2024-03-31T21:30:54.960361-05:00 frost weewxd[7210]: INFO __main__:
 Located at /usr/bin/python3
 2024-03-31T21:30:54.965927-05:00 frost weewxd[7210]: INFO __main__:
 Platform Linux-6.1.0-12-686-i686-with-glibc2.36
 2024-03-31T21:30:54.966200-05:00 frost weewxd[7210]: INFO __main__:
 Locale: 'en_US.UTF-8'
 2024-03-31T21:30:54.966522-05:00 frost weewxd[7210]: INFO __main__:
 Entry path: /usr/share/weewx/weewxd.py
 2024-03-31T21:30:54.966718-05:00 frost weewxd[7210]: INFO __main__:
 WEEWX_ROOT: /etc/weewx
 2024-03-31T21:30:54.966902-05:00 frost weewxd[7210]: INFO __main__:
 Configuration file: /etc/weewx/weewx.conf
 2024-03-31T21:30:54.972439-05:00 frost weewxd[7210]: INFO __main__:
 User module: /etc/weewx/bin/user
 2024-03-31T21:30:54.972699-05:00 frost weewxd[7210]: INFO __main__:
 Debug: 1
 2024-03-31T21:30:54.972902-05:00 frost weewxd[7210]: DEBUG __main__:
 Initializing engine
 2024-03-31T21:30:54.973165-05:00 frost weewxd[7210]: INFO weewx.engine:
 Loading station type WeatherFlowUDP (user.weatherflowudp)
 2024-03-31T21:30:54.978061-05:00 frost weewxd.py: weatherflowudp:
 MainThread: driver version is 1.10
 2024-03-31T21:30:54.978421-05:00 frost weewxd.py: weatherflowudp:
 MainThread: sensor map is {'outTemp':
 'air_temperature.AR-00091987.obs_air', 'outHumidity':
 'relative_humidity.AR-00091987.obs_air', 'pressure':
 'station_pressure.AR-00091987.obs_air', 'lightning_strikes':
 'lightning_strike_count.AR-00091987.obs_air', 'avg_distance':
 'lightning_strike_avg_distance.AR-00091987.obs_air',
 'outTempBatteryStatus': 'battery.AR-00091987.obs_air', 'windSpeed':
 'wind_speed.SK-00091987.rapid_wind', 'windDir':
 'wind_direction.SK-00091987.rapid_wind', 'lux':
 'illuminance.SK-00091987.obs_sky', 'UV': 'uv.SK-00091987.obs_sky', 'rain':
 'rain_accumulated.SK-00091987.obs_sky', 'windBatteryStatus':
 'battery.SK-00091987.obs_sky', 'radiation':
 'solar_radiation.SK-00091987.obs_sky', 'lightningYYY':
 'distance.AR-00091987.evt_strike', 'lightningZZZ':
 'energy.AR-00091987.evt_strike'}
 2024-03-31T21:30:54.988145-05:00 frost weewxd.py: weatherflowudp:
 MainThread: *** Sensor names per packet type
 2024-03-31T21:30:54.988531-05:00 frost weewxd.py: weatherflowudp:
 MainThread: packet obs_air: ('time_epoch', 'station_pressure',
 'air_temperature', 'relative_humidity', 'lightning_strike_count',
 'lightning_strike_avg_distance', 'battery', 'report_interval')
 2024-03-31T21:30:54.988855-05:00 frost weewxd.py: weatherflowudp:
 MainThread: packet obs_sky: ('time_epoch', 'illuminance', 'uv',
 'rain_accumulated', 'wind_lull', 'wind_avg', 'wind_gust', 'wind_direction',
 'battery', 'report_interval', 'solar_radiation',
 'local_day_rain_accumulation', 'precipitation_type', 
 'wind_sample_interval')
 2024-03-31T21:30:54.989234-05:00 frost weewxd.py: weatherflowudp:
 MainThread: packet rapid_wind: ('time_epoch', 

[weewx-user] Re: New install rtldavis & weewx 5

[vince]

Did you set the full path to the rtldavis binary in your weewx.conf file ?

Mine that worked here (US) is here (link) 
 if 
you wanted to compare with yours

On Monday, April 1, 2024 at 9:36:00 AM UTC-7 Pierre Decamps wrote:

> Hi everybody,
>
>  
>
> I installed a Davis VP2 Pro Plus Wireless last week and made a fresh 
> install of weewx and rtldavis plugin.
>
>  
>
> When I checked status of weewx, I see it :
>
>  
>
> Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewxd: Starting up weewx 
> version 5.0.2
>
> Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewx.engine: Using binding 
> 'wx_binding' to database 'weewx.sdb'
>
> Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewx.manager: Starting 
> backfill of daily summaries
>
> Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.manager: Daily 
> summaries up to date
>
> Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.engine: Starting main 
> packet loop.
>
> Apr 01 18:21:32 weatherpi weewxd[2247]: ERROR user.rtldavis: err: 
> 
>
> Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.engine: Main loop 
> exiting. Shutting engine down.
>
> Apr 01 18:21:33 weatherpi weewxd[2247]: INFO user.rtldavis: shutdown 
> process /home/pi/work/bin/rtldavis -fc 5 -ppm 1 -tf EU -tr 1
>
> Apr 01 18:21:33 weatherpi weewxd[2247]: CRITICAL weewxd: Caught 
> WeeWxIOError: rtldavis process is not running
>
> Apr 01 18:21:33 weatherpi weewxd[2247]: CRITICAL weewxd:   Waiting 
> 60.0 seconds then retrying...
>
>  
>
> If I start /home/weewx/bin/user/rtldavis.py
>
>  
>
> 18:25:42.266024 rtldavis.go VERSION=0.15
>
> 18:25:42.266426 tr=1 fc=5 ppm=0 gain=0 maxmissed=51 ex=0 
> receiveWindow=300 actChan=[0] maxChan=1
>
> 18:25:42.266448 undefined=false verbose=false disableAfc=false 
> deviceString=0
>
> 18:25:42.266690 BitRate: 19200
>
> 18:25:42.266708 SymbolLength: 14
>
> 18:25:42.266718 SampleRate: 268800
>
> 18:25:42.266726 Preamble: 1100101110001001
>
> 18:25:42.266734 PreambleSymbols: 16
>
> 18:25:42.266742 PreambleLength: 224
>
> 18:25:42.266750 PacketSymbols: 80
>
> 18:25:42.266758 PacketLength: 1120
>
> 18:25:42.266766 BlockSize: 512
>
> 18:25:42.266774 BufferLength: 2048
>
> Found Rafael Micro R820T tuner
>
> 18:25:42.681319 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:0 
> Transmitter:0}
>
> Exact sample rate is: 268800.001367 Hz
>
> 18:25:42.854909 GetTunerGain: 0 Db
>
> 18:25:42.854949 SetFreqCorrection 0 ppm Successful
>
> 18:25:42.858456 Init channels: wait max 17 seconds for a message of each 
> transmitter
>
> Allocating 1 zero-copy buffers
>
> Traceback (most recent call last):
>
>   File "/etc/weewx/bin/user/./rtldavis.py", line 1366, in 
>
> payload = lines[0].strip()
>
> IndexError: list index out of range
>
>  
>
>  
>
> And if I start the /home/pi/work/bin/rtldavis : 
>
>  
>
> Found Rafael Micro R820T tuner
>
> 18:28:13.224537 tr=0 ch=0 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
> 0 0 0 0 0 0 0 0]
>
> 18:28:13.224608 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:0 
> Transmitter:0}
>
> Exact sample rate is: 268800.001367 Hz
>
> 18:28:13.397912 GetTunerGain: 0 Db
>
> 18:28:13.397946 SetFreqCorrection 0 ppm Successful
>
> Allocating 1 zero-copy buffers
>
> 18:28:13.401414 Init channels: wait max 17 seconds for a message of each 
> transmitter
>
> 18:28:16.590622 m1: -0.057257 l: 224 c: 16 x: [-0.11 0.30 -0.13 -0.08 0.29 
> -0.07 -0.18 -0.16 -0.14 -0.12 -0.09 -0.08 -0.08 -0.09 -0.08 -0.08]
>
> 18:28:16.590820 TRANSMITTER 0 SEEN
>
> 18:28:16.591143 tr=0 ch=2 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
> 0 0 0 0 0 0 0 0]
>
> 18:28:16.591507 Hop: {ChannelIdx:2 ChannelFreq:868317250 FreqError:0 
> Transmitter:0}
>
> 18:28:16.591582 applied freqCorrection=0
>
> 18:28:19.152466 m1: -0.053535 l: 224 c: 16 x: [0.23 -0.07 0.34 -0.16 -0.16 
> -0.04 0.27 -0.12 -0.20 -0.15 -0.10 -0.10 -0.13 -0.15 -0.14 -0.16]
>
> 18:28:19.152891 5001CBFF71008375 2 0 0 0 0 msg.ID=0
>
> 18:28:19.153198 tr=0 ch=4 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
> 0 0 0 0 0 0 0 0]
>
> 18:28:19.153409 Hop: {ChannelIdx:4 ChannelFreq:868557250 FreqError:0 
> Transmitter:0}
>
> 18:28:19.153443 applied freqCorrection=0
>
> 18:28:21.714449 m1: -0.033016 l: 224 c: 16 x: [-0.14 0.23 0.31 0.34 -0.19 
> -0.12 0.30 -0.18 -0.11 -0.16 -0.16 -0.10 -0.09 -0.14 -0.16 -0.15]
>
> 18:28:21.714587 9000CB0701591E62 3 0 0 0 0 msg.ID=0
>
> 18:28:21.714705 tr=0 ch=1 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
> 0 0 0 0 0 0 0 0]
>
> 18:28:21.714798 Hop: {ChannelIdx:1 ChannelFreq:868197250 FreqError:0 
> Transmitter:0}
>
> 18:28:21.714828 applied freqCorrection=0
>
> 18:28:24.276257 m1: 0.015400 l: 224 c: 16 x: [0.02 0.37 0.37 0.37 0.33 
> 0.12 -0.19 -0.18 -0.16 -0.12 -0.10 -0.09 -0.09 -0.11 -0.14 -0.16]
>
> 18:28:24.276400 8001CB21D900CD83 4 0 0 0 0 msg.ID=0
>
> 18:28:24.276507 tr=0 ch=3 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
> 0 0 0 0 0 0 0 0]
>
> 18:28:24.276628 Hop: 

[weewx-user] Re: weatherflowpdp timeout

[vince]

And for others who'll run into this, what did you do ?
Did you just need to line up your actual sensor id(s) correctly to match 
your hardware ?

On Monday, April 1, 2024 at 5:41:56 AM UTC-7 Glen Briggs wrote:

> I got it going. Thank you. 
>
> Now to learn how to customize and setup things.
>
> On Sunday, March 31, 2024 at 10:28:40 PM UTC-5 vince wrote:
>
>>
>> The usual mistake is people putting in their station id (not the sensor 
>> id) or removing the leading zeroes in the sensor id. In your case you have 
>> it configured to use an air and sky original old station with both having 
>> the same id numbers which is impossible.
>>
>> AR-00091987 and.SK-00091987 are clearly incorrect.
>>
>> You might to install my wfudptools app via pip and run the listener with 
>> the —raw option to tell you your correct sensor id(s). See 
>> https://pypi.org/project/wfudptools/ which has a link to the github page 
>> for usage examples
>>
>> On Sunday, March 31, 2024 at 8:02:13 PM UTC-7 Glen Briggs wrote:
>>
>>> it appears to be running now, but i am getting nothing. no webpages, no 
>>> data, no time outs, it just does nothing
>>>
>>>
>>>
>>> 2024-03-31T21:30:54.734273-05:00 frost systemd[1]: Started weewx.service 
>>> - WeeWX.
>>> 2024-03-31T21:30:54.958929-05:00 frost weewxd[7210]: INFO __main__: 
>>> Initializing weewxd version 5.0.2
>>> 2024-03-31T21:30:54.959612-05:00 frost weewxd[7210]: INFO __main__: 
>>> Command line: /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
>>> 2024-03-31T21:30:54.959979-05:00 frost weewxd[7210]: INFO __main__: 
>>> Using Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
>>> 2024-03-31T21:30:54.960361-05:00 frost weewxd[7210]: INFO __main__: 
>>> Located at /usr/bin/python3
>>> 2024-03-31T21:30:54.965927-05:00 frost weewxd[7210]: INFO __main__: 
>>> Platform Linux-6.1.0-12-686-i686-with-glibc2.36
>>> 2024-03-31T21:30:54.966200-05:00 frost weewxd[7210]: INFO __main__: 
>>> Locale: 'en_US.UTF-8'
>>> 2024-03-31T21:30:54.966522-05:00 frost weewxd[7210]: INFO __main__: 
>>> Entry path: /usr/share/weewx/weewxd.py
>>> 2024-03-31T21:30:54.966718-05:00 frost weewxd[7210]: INFO __main__: 
>>> WEEWX_ROOT: /etc/weewx
>>> 2024-03-31T21:30:54.966902-05:00 frost weewxd[7210]: INFO __main__: 
>>> Configuration file: /etc/weewx/weewx.conf
>>> 2024-03-31T21:30:54.972439-05:00 frost weewxd[7210]: INFO __main__: User 
>>> module: /etc/weewx/bin/user
>>> 2024-03-31T21:30:54.972699-05:00 frost weewxd[7210]: INFO __main__: 
>>> Debug: 1
>>> 2024-03-31T21:30:54.972902-05:00 frost weewxd[7210]: DEBUG __main__: 
>>> Initializing engine
>>> 2024-03-31T21:30:54.973165-05:00 frost weewxd[7210]: INFO weewx.engine: 
>>> Loading station type WeatherFlowUDP (user.weatherflowudp)
>>> 2024-03-31T21:30:54.978061-05:00 frost weewxd.py: weatherflowudp: 
>>> MainThread: driver version is 1.10
>>> 2024-03-31T21:30:54.978421-05:00 frost weewxd.py: weatherflowudp: 
>>> MainThread: sensor map is {'outTemp': 
>>> 'air_temperature.AR-00091987.obs_air', 'outHumidity': 
>>> 'relative_humidity.AR-00091987.obs_air', 'pressure': 
>>> 'station_pressure.AR-00091987.obs_air', 'lightning_strikes': 
>>> 'lightning_strike_count.AR-00091987.obs_air', 'avg_distance': 
>>> 'lightning_strike_avg_distance.AR-00091987.obs_air', 
>>> 'outTempBatteryStatus': 'battery.AR-00091987.obs_air', 'windSpeed': 
>>> 'wind_speed.SK-00091987.rapid_wind', 'windDir': 
>>> 'wind_direction.SK-00091987.rapid_wind', 'lux': 
>>> 'illuminance.SK-00091987.obs_sky', 'UV': 'uv.SK-00091987.obs_sky', 'rain': 
>>> 'rain_accumulated.SK-00091987.obs_sky', 'windBatteryStatus': 
>>> 'battery.SK-00091987.obs_sky', 'radiation': 
>>> 'solar_radiation.SK-00091987.obs_sky', 'lightningYYY': 
>>> 'distance.AR-00091987.evt_strike', 'lightningZZZ': 
>>> 'energy.AR-00091987.evt_strike'}
>>> 2024-03-31T21:30:54.988145-05:00 frost weewxd.py: weatherflowudp: 
>>> MainThread: *** Sensor names per packet type
>>> 2024-03-31T21:30:54.988531-05:00 frost weewxd.py: weatherflowudp: 
>>> MainThread: packet obs_air: ('time_epoch', 'station_pressure', 
>>> 'air_temperature', 'relative_humidity', 'lightning_strike_count', 
>>> 'lightning_strike_avg_distance', 'battery', 'report_interval')
>>> 2024-03-31T21:30:54.988855-05:00 frost weewxd.py: weatherflowudp: 
>>> MainThread: packet obs_sky: ('time_epoch', 'illuminance', 'uv', 
>>> 'rain_accumulated', 'wind_lull', 'wind_avg', 'wind_gust', 'wind_direction', 
>>> 'battery', 'report_interval', 'solar_radiation', 
>>> 'local_day_rain_accumulation', 'precipitation_type', 'wind_sample_interval')
>>> 2024-03-31T21:30:54.989234-05:00 frost weewxd.py: weatherflowudp: 
>>> MainThread: packet rapid_wind: ('time_epoch', 'wind_speed', 
>>> 'wind_direction')
>>> 2024-03-31T21:30:54.989563-05:00 frost weewxd.py: weatherflowudp: 
>>> MainThread: packet evt_precip: time_epoch
>>> 2024-03-31T21:30:54.989877-05:00 frost weewxd.py: weatherflowudp: 
>>> MainThread: packet evt_strike: ('time_epoch', 'distance', 'energy')
>>> 2024-03-31T21:30:54.990189-05:00 frost 

Re: [weewx-user] show old nooa data in pulldown

[Tom Keffer]

Skins are updated only if you update them explicitly.

See the documentation for weectl station upgrade

.

On Mon, Apr 1, 2024 at 9:35 AM WindnFog  wrote:

> I'm modifying titlebar.inc for a different reason. I'm curious if it will
> be overwritten in subsequent pip weewx updates or treated like weewx.conf,
> etc. Does the user decide which version to keep if these .inc files are
> user modified?
>
> On Sunday, March 31, 2024 at 10:23:45 AM UTC-3 Tom Keffer wrote:
>
>> Unfortunately, there is no easy way to do this. The list of months is
>> generated dynamically when the reports are run.
>>
>> If you are familiar with HTML, something you could do is modify the
>> select statement in the template titlebar.inc to include the extra dates.
>> For example, say you had extra months 2010-08 and 2010-09, contained in
>> files NOAA/NOAA-2010-08.txt and  NOAA/NOAA-2010-09.txt, respectively. When
>> done, this would look like (NOT TESTED):
>>
>> 
>>   2010-08
>>   2010-09
>>   #for $monthYear in $SummaryByMonth
>>   $monthYear
>>   #end for
>>   - $gettext("select month") -
>> 
>>
>> This would make the extra dates available in the drop down list.
>>
>> On Sun, Mar 31, 2024 at 4:12 AM simon  wrote:
>>
>>> hello all, i have old nooa txt files with datas which are not in the
>>> database.
>>> is it possible to bring the old files into the pulldown menu to select
>>> them ?[image: weewx nooa.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+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/4d41dea9-4785-43d9-b67e-2c7c34c659b8n%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/26bed7e3-3b1e-4887-804f-8731ff408eb3n%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/CAPq0zECZzetoD0gmKB9b6YO6j97yastQrKiCtuQvauTQpMbE0w%40mail.gmail.com.

[weewx-user] New install rtldavis & weewx 5

[Pierre]

Hi everybody,

 

I installed a Davis VP2 Pro Plus Wireless last week and made a fresh 
install of weewx and rtldavis plugin.

 

When I checked status of weewx, I see it :

 

Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewxd: Starting up weewx 
version 5.0.2

Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'

Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewx.manager: Starting 
backfill of daily summaries

Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.manager: Daily summaries 
up to date

Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.engine: Starting main 
packet loop.

Apr 01 18:21:32 weatherpi weewxd[2247]: ERROR user.rtldavis: err: 


Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.engine: Main loop 
exiting. Shutting engine down.

Apr 01 18:21:33 weatherpi weewxd[2247]: INFO user.rtldavis: shutdown 
process /home/pi/work/bin/rtldavis -fc 5 -ppm 1 -tf EU -tr 1

Apr 01 18:21:33 weatherpi weewxd[2247]: CRITICAL weewxd: Caught 
WeeWxIOError: rtldavis process is not running

Apr 01 18:21:33 weatherpi weewxd[2247]: CRITICAL weewxd:   Waiting 
60.0 seconds then retrying...

 

If I start /home/weewx/bin/user/rtldavis.py

 

18:25:42.266024 rtldavis.go VERSION=0.15

18:25:42.266426 tr=1 fc=5 ppm=0 gain=0 maxmissed=51 ex=0 
receiveWindow=300 actChan=[0] maxChan=1

18:25:42.266448 undefined=false verbose=false disableAfc=false 
deviceString=0

18:25:42.266690 BitRate: 19200

18:25:42.266708 SymbolLength: 14

18:25:42.266718 SampleRate: 268800

18:25:42.266726 Preamble: 1100101110001001

18:25:42.266734 PreambleSymbols: 16

18:25:42.266742 PreambleLength: 224

18:25:42.266750 PacketSymbols: 80

18:25:42.266758 PacketLength: 1120

18:25:42.266766 BlockSize: 512

18:25:42.266774 BufferLength: 2048

Found Rafael Micro R820T tuner

18:25:42.681319 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:0 
Transmitter:0}

Exact sample rate is: 268800.001367 Hz

18:25:42.854909 GetTunerGain: 0 Db

18:25:42.854949 SetFreqCorrection 0 ppm Successful

18:25:42.858456 Init channels: wait max 17 seconds for a message of each 
transmitter

Allocating 1 zero-copy buffers

Traceback (most recent call last):

  File "/etc/weewx/bin/user/./rtldavis.py", line 1366, in 

payload = lines[0].strip()

IndexError: list index out of range

 

 

And if I start the /home/pi/work/bin/rtldavis :

 

Found Rafael Micro R820T tuner

18:28:13.224537 tr=0 ch=0 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
0 0 0 0 0 0 0 0]

18:28:13.224608 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:0 
Transmitter:0}

Exact sample rate is: 268800.001367 Hz

18:28:13.397912 GetTunerGain: 0 Db

18:28:13.397946 SetFreqCorrection 0 ppm Successful

Allocating 1 zero-copy buffers

18:28:13.401414 Init channels: wait max 17 seconds for a message of each 
transmitter

18:28:16.590622 m1: -0.057257 l: 224 c: 16 x: [-0.11 0.30 -0.13 -0.08 0.29 
-0.07 -0.18 -0.16 -0.14 -0.12 -0.09 -0.08 -0.08 -0.09 -0.08 -0.08]

18:28:16.590820 TRANSMITTER 0 SEEN

18:28:16.591143 tr=0 ch=2 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
0 0 0 0 0 0 0 0]

18:28:16.591507 Hop: {ChannelIdx:2 ChannelFreq:868317250 FreqError:0 
Transmitter:0}

18:28:16.591582 applied freqCorrection=0

18:28:19.152466 m1: -0.053535 l: 224 c: 16 x: [0.23 -0.07 0.34 -0.16 -0.16 
-0.04 0.27 -0.12 -0.20 -0.15 -0.10 -0.10 -0.13 -0.15 -0.14 -0.16]

18:28:19.152891 5001CBFF71008375 2 0 0 0 0 msg.ID=0

18:28:19.153198 tr=0 ch=4 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
0 0 0 0 0 0 0 0]

18:28:19.153409 Hop: {ChannelIdx:4 ChannelFreq:868557250 FreqError:0 
Transmitter:0}

18:28:19.153443 applied freqCorrection=0

18:28:21.714449 m1: -0.033016 l: 224 c: 16 x: [-0.14 0.23 0.31 0.34 -0.19 
-0.12 0.30 -0.18 -0.11 -0.16 -0.16 -0.10 -0.09 -0.14 -0.16 -0.15]

18:28:21.714587 9000CB0701591E62 3 0 0 0 0 msg.ID=0

18:28:21.714705 tr=0 ch=1 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
0 0 0 0 0 0 0 0]

18:28:21.714798 Hop: {ChannelIdx:1 ChannelFreq:868197250 FreqError:0 
Transmitter:0}

18:28:21.714828 applied freqCorrection=0

18:28:24.276257 m1: 0.015400 l: 224 c: 16 x: [0.02 0.37 0.37 0.37 0.33 0.12 
-0.19 -0.18 -0.16 -0.12 -0.10 -0.09 -0.09 -0.11 -0.14 -0.16]

18:28:24.276400 8001CB21D900CD83 4 0 0 0 0 msg.ID=0

18:28:24.276507 tr=0 ch=3 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 
0 0 0 0 0 0 0 0]

18:28:24.276628 Hop: {ChannelIdx:3 ChannelFreq:868437250 FreqError:0 
Transmitter:0}

18:28:24.276692 applied freqCorrection=0

18:28:26.840325 m1: -0.004463 l: 224 c: 16 x: [-0.04 0.34 -0.06 0.39 0.35 
0.29 -0.20 -0.12 -0.17 -0.16 -0.16 -0.13 -0.11 -0.10 -0.08 -0.11]

18:28:26.840408 E000CB9001006D8B 5 0 0 0 0 msg.ID=0

18:28:26.840537 tr=0 ch=0 freqCorr=222 lastFreqError=2449, 
freqerrTrChList=[2449 0 0 0 0 0 0 0 0 0]

18:28:26.840618 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:222 
Transmitter:0}

18:28:26.840648 applied freqCorrection=222

18:28:29.402215 m1: 0.025469 l: 224 c: 16 x: [0.36 -0.10 

Re: [weewx-user] Change to daylight saving time stops data update

[James Taylor]

Hello

I just have a cronjob that runs that works for European clock changes.

02 02 25-31 3,10 * [ $(date +\%w) -eq '0' ] && /bin/weectl device 
--clear-memory >/dev/null 2>&1

James
On Monday, April 1, 2024 at 10:43:35 AM UTC+1 Devonian wrote:

> Regular 'issue' for me in UK too.
> I do this as I'm not yet on v5...amend as req'd.
>
> sudo service weewx stop
>
> sudo /home/weewx/bin/wee_device --dump  (or wherever your wee_device (or 
> weectl device --dump) command is located)
>
> sudo /home/weewx/bin/wee_device --clear  (or wherever your wee_device (or 
> weectl device --clear) command is located)
>
> sudo service weewx start
>
> Never lost any data yet and to speed things up after clocks change. I try 
> to remember the night before clocks change to clear the logger if all 
> current data is saved to the db.
>
> HTH
>
> Nigel
>
> On Monday 1 April 2024 at 00:05:08 UTC+1 Tom Keffer wrote:
>
>> Issue #247  explains the 
>> problem.
>>
>> On Sun, Mar 31, 2024 at 3:56 PM Stephen  wrote:
>>
>>> I have two Davis Vantage Pro 2 weather stations at different locations. 
>>> Both stations stopped updating their web pages at 2.00am last night, the 
>>> moment daylight saving started.
>>>
>>> I'm running Weewx v5.0.1 at both locations.  Both Vantage Pro2 consoles 
>>> are configured to automatically change to DST.
>>>
>>> There is an old thread from 2017 about this problem here 
>>> https://groups.google.com/g/weewx-user/c/rM2IDREAWiI/m/oloGcj7aAAAJ.
>>>
>>> Taking the advice in that thread I've got one of the stations working 
>>> again by executing  weectl device --dump.  I've left the other station as 
>>> it is at the moment.
>>>
>>> This has never happened before, but I wasn't running v5.0.1 this time 
>>> last year.
>>>
>>> Any idea what's going on?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/bc83e9f6-5231-4702-8afc-758c645061cdn%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/a53a7b90-5284-4ddf-bc09-311d6f75f007n%40googlegroups.com.

[weewx-user] New install rtldavis & weewx 5

[Pierre Decamps]

Hi everybody,

I installed a Davis VP2 Pro Plus Wireless last week and made a fresh install of 
weewx and rtldavis plugin.

When I checked status of weewx, I see it :

Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewxd: Starting up weewx version 
5.0.2
Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'
Apr 01 18:21:31 weatherpi weewxd[2247]: INFO weewx.manager: Starting backfill 
of daily summaries
Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.manager: Daily summaries up 
to date
Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.engine: Starting main packet 
loop.
Apr 01 18:21:32 weatherpi weewxd[2247]: ERROR user.rtldavis: err: 
Apr 01 18:21:32 weatherpi weewxd[2247]: INFO weewx.engine: Main loop exiting. 
Shutting engine down.
Apr 01 18:21:33 weatherpi weewxd[2247]: INFO user.rtldavis: shutdown process 
/home/pi/work/bin/rtldavis -fc 5 -ppm 1 -tf EU -tr 1
Apr 01 18:21:33 weatherpi weewxd[2247]: CRITICAL weewxd: Caught WeeWxIOError: 
rtldavis process is not running
Apr 01 18:21:33 weatherpi weewxd[2247]: CRITICAL weewxd:   Waiting 60.0 
seconds then retrying...

If I start /home/weewx/bin/user/rtldavis.py

18:25:42.266024 rtldavis.go VERSION=0.15
18:25:42.266426 tr=1 fc=5 ppm=0 gain=0 maxmissed=51 ex=0 receiveWindow=300 
actChan=[0] maxChan=1
18:25:42.266448 undefined=false verbose=false disableAfc=false deviceString=0
18:25:42.266690 BitRate: 19200
18:25:42.266708 SymbolLength: 14
18:25:42.266718 SampleRate: 268800
18:25:42.266726 Preamble: 1100101110001001
18:25:42.266734 PreambleSymbols: 16
18:25:42.266742 PreambleLength: 224
18:25:42.266750 PacketSymbols: 80
18:25:42.266758 PacketLength: 1120
18:25:42.266766 BlockSize: 512
18:25:42.266774 BufferLength: 2048
Found Rafael Micro R820T tuner
18:25:42.681319 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:0 
Transmitter:0}
Exact sample rate is: 268800.001367 Hz
18:25:42.854909 GetTunerGain: 0 Db
18:25:42.854949 SetFreqCorrection 0 ppm Successful
18:25:42.858456 Init channels: wait max 17 seconds for a message of each 
transmitter
Allocating 1 zero-copy buffers
Traceback (most recent call last):
  File "/etc/weewx/bin/user/./rtldavis.py", line 1366, in 
payload = lines[0].strip()
IndexError: list index out of range


And if I start the /home/pi/work/bin/rtldavis :

Found Rafael Micro R820T tuner
18:28:13.224537 tr=0 ch=0 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 0 0 
0 0 0 0 0 0]
18:28:13.224608 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:0 
Transmitter:0}
Exact sample rate is: 268800.001367 Hz
18:28:13.397912 GetTunerGain: 0 Db
18:28:13.397946 SetFreqCorrection 0 ppm Successful
Allocating 1 zero-copy buffers
18:28:13.401414 Init channels: wait max 17 seconds for a message of each 
transmitter
18:28:16.590622 m1: -0.057257 l: 224 c: 16 x: [-0.11 0.30 -0.13 -0.08 0.29 
-0.07 -0.18 -0.16 -0.14 -0.12 -0.09 -0.08 -0.08 -0.09 -0.08 -0.08]
18:28:16.590820 TRANSMITTER 0 SEEN
18:28:16.591143 tr=0 ch=2 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 0 0 
0 0 0 0 0 0]
18:28:16.591507 Hop: {ChannelIdx:2 ChannelFreq:868317250 FreqError:0 
Transmitter:0}
18:28:16.591582 applied freqCorrection=0
18:28:19.152466 m1: -0.053535 l: 224 c: 16 x: [0.23 -0.07 0.34 -0.16 -0.16 
-0.04 0.27 -0.12 -0.20 -0.15 -0.10 -0.10 -0.13 -0.15 -0.14 -0.16]
18:28:19.152891 5001CBFF71008375 2 0 0 0 0 msg.ID=0
18:28:19.153198 tr=0 ch=4 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 0 0 
0 0 0 0 0 0]
18:28:19.153409 Hop: {ChannelIdx:4 ChannelFreq:868557250 FreqError:0 
Transmitter:0}
18:28:19.153443 applied freqCorrection=0
18:28:21.714449 m1: -0.033016 l: 224 c: 16 x: [-0.14 0.23 0.31 0.34 -0.19 -0.12 
0.30 -0.18 -0.11 -0.16 -0.16 -0.10 -0.09 -0.14 -0.16 -0.15]
18:28:21.714587 9000CB0701591E62 3 0 0 0 0 msg.ID=0
18:28:21.714705 tr=0 ch=1 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 0 0 
0 0 0 0 0 0]
18:28:21.714798 Hop: {ChannelIdx:1 ChannelFreq:868197250 FreqError:0 
Transmitter:0}
18:28:21.714828 applied freqCorrection=0
18:28:24.276257 m1: 0.015400 l: 224 c: 16 x: [0.02 0.37 0.37 0.37 0.33 0.12 
-0.19 -0.18 -0.16 -0.12 -0.10 -0.09 -0.09 -0.11 -0.14 -0.16]
18:28:24.276400 8001CB21D900CD83 4 0 0 0 0 msg.ID=0
18:28:24.276507 tr=0 ch=3 freqCorr=0 lastFreqError=0, freqerrTrChList=[0 0 0 0 
0 0 0 0 0 0]
18:28:24.276628 Hop: {ChannelIdx:3 ChannelFreq:868437250 FreqError:0 
Transmitter:0}
18:28:24.276692 applied freqCorrection=0
18:28:26.840325 m1: -0.004463 l: 224 c: 16 x: [-0.04 0.34 -0.06 0.39 0.35 0.29 
-0.20 -0.12 -0.17 -0.16 -0.16 -0.13 -0.11 -0.10 -0.08 -0.11]
18:28:26.840408 E000CB9001006D8B 5 0 0 0 0 msg.ID=0
18:28:26.840537 tr=0 ch=0 freqCorr=222 lastFreqError=2449, 
freqerrTrChList=[2449 0 0 0 0 0 0 0 0 0]
18:28:26.840618 Hop: {ChannelIdx:0 ChannelFreq:868077250 FreqError:222 
Transmitter:0}
18:28:26.840648 applied freqCorrection=222
18:28:29.402215 m1: 0.025469 l: 224 c: 16 x: [0.36 -0.10 0.25 0.32 -0.14 0.33 
0.34 -0.07 -0.21 -0.10 -0.09 -0.09 -0.08 -0.10 -0.11 -0.11]

Re: [weewx-user] Change to daylight saving time stops data update

[Simon Duane]

my weewx 4.9.1 + VP2 also stopped logging yesterday at 2am as well - it was 
ok at the previous two DST changes (I'm in the UK).

The 
sudo service weewx stop
sudo /home/weewx/bin/wee_device --dump
sudo /home/weewx/bin/wee_device --clear
sudo service weewx start
trick got things going again for me too (thanks!), albeit at the expense of 
losing the intervening several hours of data.

I've read TF's suggestion to use software record generation, but I'm 
wondering - if the problem only happens if/when weewx tries to adjust the 
VP2 console clock during the hour change, would it make sense *never* to 
try doing that between 1am and 2am?
Or not to do that if the  change would be much bigger than 5 seconds (or 
whatever the chosen tolerance is)?
I'm guessing that the problem is partly that weewx and the console are 
applying the DST change at slightly different times and, honestly, if one's 
made the change and the other hasn't, the fact that the difference is not 
slightly more than 5 seconds should be an obvious warning sign: be patient, 
and only tweak the clock when the difference is back to a few seconds.
What I'm saying boils down to: the logger might not make the DST status 
explicit, but regular comparison with another clock, as weewx is doing, 
should make it pretty obvious.

Simon
On Monday 1 April 2024 at 10:43:35 UTC+1 Devonian wrote:

> Regular 'issue' for me in UK too.
> I do this as I'm not yet on v5...amend as req'd.
>
> sudo service weewx stop
>
> sudo /home/weewx/bin/wee_device --dump  (or wherever your wee_device (or 
> weectl device --dump) command is located)
>
> sudo /home/weewx/bin/wee_device --clear  (or wherever your wee_device (or 
> weectl device --clear) command is located)
>
> sudo service weewx start
>
> Never lost any data yet and to speed things up after clocks change. I try 
> to remember the night before clocks change to clear the logger if all 
> current data is saved to the db.
>
> HTH
>
> Nigel
>
> On Monday 1 April 2024 at 00:05:08 UTC+1 Tom Keffer wrote:
>
>> Issue #247  explains the 
>> problem.
>>
>> On Sun, Mar 31, 2024 at 3:56 PM Stephen  wrote:
>>
>>> I have two Davis Vantage Pro 2 weather stations at different locations. 
>>> Both stations stopped updating their web pages at 2.00am last night, the 
>>> moment daylight saving started.
>>>
>>> I'm running Weewx v5.0.1 at both locations.  Both Vantage Pro2 consoles 
>>> are configured to automatically change to DST.
>>>
>>> There is an old thread from 2017 about this problem here 
>>> https://groups.google.com/g/weewx-user/c/rM2IDREAWiI/m/oloGcj7aAAAJ.
>>>
>>> Taking the advice in that thread I've got one of the stations working 
>>> again by executing  weectl device --dump.  I've left the other station as 
>>> it is at the moment.
>>>
>>> This has never happened before, but I wasn't running v5.0.1 this time 
>>> last year.
>>>
>>> Any idea what's going on?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/bc83e9f6-5231-4702-8afc-758c645061cdn%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/4b659e1f-c152-4b01-b659-2854bb6d3b13n%40googlegroups.com.

Re: [weewx-user] show old nooa data in pulldown

[simon]

Hello tom,

Many thanks forbthis fast response and your help.
After i have test it i give a feedback.

Tom Keffer schrieb am Sonntag, 31. März 2024 um 15:23:45 UTC+2:

> Unfortunately, there is no easy way to do this. The list of months is 
> generated dynamically when the reports are run.
>
> If you are familiar with HTML, something you could do is modify the select 
> statement in the template titlebar.inc to include the extra dates. For 
> example, say you had extra months 2010-08 and 2010-09, contained in files 
> NOAA/NOAA-2010-08.txt and  NOAA/NOAA-2010-09.txt, respectively. When done, 
> this would look like (NOT TESTED):
>
> 
>   2010-08
>   2010-09
>   #for $monthYear in $SummaryByMonth
>   $monthYear
>   #end for
>   - $gettext("select month") -
> 
>
> This would make the extra dates available in the drop down list.
>
> On Sun, Mar 31, 2024 at 4:12 AM simon  wrote:
>
>> hello all, i have old nooa txt files with datas which are not in the 
>> database.
>> is it possible to bring the old files into the pulldown menu to select 
>> them ?[image: weewx nooa.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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/4d41dea9-4785-43d9-b67e-2c7c34c659b8n%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/fde2fa07-7012-4454-ba57-7d5aaba40a48n%40googlegroups.com.

Re: [weewx-user] show old nooa data in pulldown

[WindnFog]

I'm modifying titlebar.inc for a different reason. I'm curious if it will 
be overwritten in subsequent pip weewx updates or treated like weewx.conf, 
etc. Does the user decide which version to keep if these .inc files are 
user modified?

On Sunday, March 31, 2024 at 10:23:45 AM UTC-3 Tom Keffer wrote:

> Unfortunately, there is no easy way to do this. The list of months is 
> generated dynamically when the reports are run.
>
> If you are familiar with HTML, something you could do is modify the select 
> statement in the template titlebar.inc to include the extra dates. For 
> example, say you had extra months 2010-08 and 2010-09, contained in files 
> NOAA/NOAA-2010-08.txt and  NOAA/NOAA-2010-09.txt, respectively. When done, 
> this would look like (NOT TESTED):
>
> 
>   2010-08
>   2010-09
>   #for $monthYear in $SummaryByMonth
>   $monthYear
>   #end for
>   - $gettext("select month") -
> 
>
> This would make the extra dates available in the drop down list.
>
> On Sun, Mar 31, 2024 at 4:12 AM simon  wrote:
>
>> hello all, i have old nooa txt files with datas which are not in the 
>> database.
>> is it possible to bring the old files into the pulldown menu to select 
>> them ?[image: weewx nooa.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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/4d41dea9-4785-43d9-b67e-2c7c34c659b8n%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/26bed7e3-3b1e-4887-804f-8731ff408eb3n%40googlegroups.com.

Re: [weewx-user] Re: Weewx und Renkforce WH2315

[Tom Keffer]

Two things:

1. You are still using the original version of the driver. You want my
patched version at  https://github.com/tkeffer/weewx-wh23xx
2. What version of weewx are you using? Early beta versions of v5.0 could
not recognize a zip file, but current releases do.

*weectl --version*


On Mon, Apr 1, 2024 at 8:48 AM Günther Wrana  wrote:

> Hello, this is the message when I install the driver and try to select
> when reconfiguring
>
> Thanks Günther
>
> Hallo das ist die Meldung wenn ich den Treiber installiere und versuche
> bei der Rekonfiguration auszuwählen
>
> Danke Günther
>
>
>
> 64GB@64GB:~/Downloads $ wget -O weewx-wh23xx.zip
> https://github.com/matthewwall/weewx-wh23xx/archive/master.zip
> --2024-04-01 17:27:53--
> https://github.com/matthewwall/weewx-wh23xx/archive/master.zip
> Resolving github.com (github.com)... 140.82.121.3
> Connecting to github.com (github.com)|140.82.121.3|:443... connected.
> HTTP request sent, awaiting response... 302 Found
> Location:
> https://codeload.github.com/matthewwall/weewx-wh23xx/zip/refs/heads/master
> [following]
> --2024-04-01 17:27:53--
> https://codeload.github.com/matthewwall/weewx-wh23xx/zip/refs/heads/master
> Resolving codeload.github.com (codeload.github.com)... 140.82.121.9
> Connecting to codeload.github.com (codeload.github.com)|140.82.121.9|:443...
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [application/zip]
> Saving to: ‘weewx-wh23xx.zip’
>
> weewx-wh23xx.zip[ <=>]  23.64K  --.-KB/sin
> 0.03s
>
> 2024-04-01 17:27:54 (837 KB/s) - ‘weewx-wh23xx.zip’ saved [24210]
>
> 64GB@64GB:~/Downloads $ weectl extension install weewx-wh23xx-master.zip
> Using configuration file /etc/weewx/weewx.conf
> Install extension 'weewx-wh23xx-master.zip' (y/n)? y
> Traceback (most recent call last):
>   File "/usr/share/weewx/weectl.py", line 74, in 
> main()
>   File "/usr/share/weewx/weectl.py", line 66, in main
> namespace.func(namespace)
>   File "/usr/share/weewx/weectllib/__init__.py", line 121, in dispatch
> namespace.action_func(config_dict, namespace)
>   File "/usr/share/weewx/weectllib/extension_cmd.py", line 116, in
> install_extension
> ext.install_extension(namespace.source, no_confirm=namespace.yes)
>   File "/usr/share/weewx/weecfg/extension.py", line 143, in
> install_extension
> raise InstallError(f"Unrecognized type for {extension_path}")
> weecfg.extension.InstallError: Unrecognized type for
> weewx-wh23xx-master.zip
> 64GB@64GB:~/Downloads $ weectl station reconfigure
> Using configuration file /etc/weewx/weewx.conf
> Processing configuration file /etc/weewx/weewx.conf
>
> Give a description of the station. This will be used for the title of
> reports.
> description [2243 Matzen,Österreich Niederösterreich ]:
>
> Specify altitude, with units 'foot' or 'meter'.  For example:
>   35, foot
>   12, meter
> altitude [199, meter]:
>
> Specify latitude in decimal degrees, negative for south.
> latitude [48.401826]:
> Specify longitude in decimal degrees, negative for west.
> longitude [16.686539]:
>
> Choose a unit system for the reports. Later, you can modify
> your choice, or choose a combination of units. Unit systems
> include:
>   us (ºF, inHg, in, mph)
>   metricwx   (ºC, mbar, mm, m/s)
>   metric (ºC, mbar, cm, km/h)
> unit system [metricwx]:
>
> Choose a driver. Installed drivers include:
>   0) ?   (user.wh23xx) invalid syntax (wh23xx.py,
> line 427)
>   1) AcuRite (weewx.drivers.acurite)
>   2) CC3000  (weewx.drivers.cc3000)
>   3) FineOffsetUSB   (weewx.drivers.fousb)
>   4) Simulator   (weewx.drivers.simulator)
>   5) TE923   (weewx.drivers.te923)
>   6) Ultimeter   (weewx.drivers.ultimeter)
>   7) Vantage (weewx.drivers.vantage)
>   8) WMR100  (weewx.drivers.wmr100)
>   9) WMR300  (weewx.drivers.wmr300)
>  10) WMR9x8  (weewx.drivers.wmr9x8)
>  11) WS1 (weewx.drivers.ws1)
>  12) WS23xx  (weewx.drivers.ws23xx)
>  13) WS28xx  (weewx.drivers.ws28xx)
> driver [4]:
>
> Tom Keffer schrieb am Sonntag, 31. März 2024 um 17:48:37 UTC+2:
>
>> I did a quick port of the driver. It has *not* been tested!
>>
>> Find it here: https://github.com/tkeffer/weewx-wh23xx
>>
>> If it works for you, I'll ask Matthew to incorporate the changes.
>>
>> -tk
>>
>> On Sun, Mar 31, 2024 at 2:12 AM Tom Keffer  wrote:
>>
>>> It appears that the wh23xx driver has not been ported to Python 2.
>>>
>>> On Sun, Mar 31, 2024 at 1:33 AM Günther Wrana  wrote:
>>>
 Ladies and Gentlemen

 Once again I need your help, how is it possible to use the weather
 station I use with weewx version 5.0.
 I managed to install the new version of weewx and also the driver. It
 only shows an error message during reconfiguration.
 With this command I installed the driver
 weektl extension install weewx-wh23xx-master.zip


 What have I 

Re: [weewx-user] Re: Change to daylight saving time stops data update

[Tom Keffer]

If the key is to not mess with the console time near the DST boundary, why 
not just arrange for clock synchronization to only happen once a day at 
noon?

On Monday, April 1, 2024 at 6:34:46 AM UTC-7 jo...@johnkline.com wrote:

> I’ve successfully fixed the time change issue on a fork of the vantage 
> driver:
> [image: weewx-vantagenext.png]
>
> chaunceygardiner/weewx-vantagenext: VantageNext is a WeeWX driver based on 
> the Vantage driver that ships with WeeWX. 
> 
> github.com 
> 
>
> It assumes a one hour change for daylight savings and one is required to 
> enter DST enter and exit times in the VantageNext section of weewx.conf.
>
> During the time change window, set time is a no-op (since one cannot 
> specify whether the time is in DST or not).  Also, during the window, get 
> time will auto correct if the time is about 1 hour off.  Lastly, when the 
> driver converts the archive records time, it is auto-adjusted if about an 
> hour off.
>
> I don’t recommend switching to this driver as the vantage driver in weewx 
> is better supported; but perhaps a similar approach could be taken.  It is 
> tricky because it is hard to test this stuff.
>
>  
>
> On Apr 1, 2024, at 8:00 AM, Simon Duane  wrote:
>
> 
>
> From what I've read, it involves an interaction between a Weewx service 
> which adjusts the VP2 console clock to eliminate drift  - by default, it 
> checks every 5 hours and applies the correction when the error is bigger 
> than 5 seconds. I would suggest that if the error is close to 1 hour rather 
> than a little more than 5 seconds, then the correction should simply not be 
> applied, because of the risk of this happening. Fixing it on the next cycle 
> will be good enough.
> It happened to my Weewx v 4.9.1 + VP2 (for the first time) yesterday too 
> and, because I have that archive parameter set to hardware, clearing the 
> datalogger memory meant I lost about a day's data.
>
> On Sunday 31 March 2024 at 23:56:23 UTC+1 Stephen wrote:
>
>> I have two Davis Vantage Pro 2 weather stations at different locations. 
>> Both stations stopped updating their web pages at 2.00am last night, the 
>> moment daylight saving started.
>>
>> I'm running Weewx v5.0.1 at both locations.  Both Vantage Pro2 consoles 
>> are configured to automatically change to DST.
>>
>> There is an old thread from 2017 about this problem here 
>> https://groups.google.com/g/weewx-user/c/rM2IDREAWiI/m/oloGcj7aAAAJ.
>>
>> Taking the advice in that thread I've got one of the stations working 
>> again by executing  weectl device --dump.  I've left the other station as 
>> it is at the moment.
>>
>> This has never happened before, but I wasn't running v5.0.1 this time 
>> last year.
>>
>> Any idea what's going on?
>>
> -- 
>
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/09e0d95f-ec44-4782-989f-d4ef3217ddadn%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/241ad3cb-213d-44d3-937a-bea2dabbb441n%40googlegroups.com.

Re: [weewx-user] Re: Weewx und Renkforce WH2315

[Günther Wrana]

Hello, this is the message when I install the driver and try to select when 
reconfiguring

Thanks Günther

Hallo das ist die Meldung wenn ich den Treiber installiere und versuche bei 
der Rekonfiguration auszuwählen

Danke Günther



64GB@64GB:~/Downloads $ wget -O weewx-wh23xx.zip 
https://github.com/matthewwall/weewx-wh23xx/archive/master.zip
--2024-04-01 17:27:53-- 
 https://github.com/matthewwall/weewx-wh23xx/archive/master.zip
Resolving github.com (github.com)... 140.82.121.3
Connecting to github.com (github.com)|140.82.121.3|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: 
https://codeload.github.com/matthewwall/weewx-wh23xx/zip/refs/heads/master 
[following]
--2024-04-01 17:27:53-- 
 https://codeload.github.com/matthewwall/weewx-wh23xx/zip/refs/heads/master
Resolving codeload.github.com (codeload.github.com)... 140.82.121.9
Connecting to codeload.github.com 
(codeload.github.com)|140.82.121.9|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: ‘weewx-wh23xx.zip’

weewx-wh23xx.zip[ <=>]  23.64K  --.-KB/sin 
0.03s   

2024-04-01 17:27:54 (837 KB/s) - ‘weewx-wh23xx.zip’ saved [24210]

64GB@64GB:~/Downloads $ weectl extension install weewx-wh23xx-master.zip
Using configuration file /etc/weewx/weewx.conf
Install extension 'weewx-wh23xx-master.zip' (y/n)? y
Traceback (most recent call last):
  File "/usr/share/weewx/weectl.py", line 74, in 
main()
  File "/usr/share/weewx/weectl.py", line 66, in main
namespace.func(namespace)
  File "/usr/share/weewx/weectllib/__init__.py", line 121, in dispatch
namespace.action_func(config_dict, namespace)
  File "/usr/share/weewx/weectllib/extension_cmd.py", line 116, in 
install_extension
ext.install_extension(namespace.source, no_confirm=namespace.yes)
  File "/usr/share/weewx/weecfg/extension.py", line 143, in 
install_extension
raise InstallError(f"Unrecognized type for {extension_path}")
weecfg.extension.InstallError: Unrecognized type for weewx-wh23xx-master.zip
64GB@64GB:~/Downloads $ weectl station reconfigure
Using configuration file /etc/weewx/weewx.conf
Processing configuration file /etc/weewx/weewx.conf

Give a description of the station. This will be used for the title of 
reports.
description [2243 Matzen,Österreich Niederösterreich ]: 

Specify altitude, with units 'foot' or 'meter'.  For example:
  35, foot
  12, meter
altitude [199, meter]: 

Specify latitude in decimal degrees, negative for south.
latitude [48.401826]: 
Specify longitude in decimal degrees, negative for west.
longitude [16.686539]: 

Choose a unit system for the reports. Later, you can modify
your choice, or choose a combination of units. Unit systems
include:
  us (ºF, inHg, in, mph)
  metricwx   (ºC, mbar, mm, m/s)
  metric (ºC, mbar, cm, km/h)
unit system [metricwx]: 

Choose a driver. Installed drivers include:
  0) ?   (user.wh23xx) invalid syntax (wh23xx.py, 
line 427)
  1) AcuRite (weewx.drivers.acurite)   
  2) CC3000  (weewx.drivers.cc3000)
  3) FineOffsetUSB   (weewx.drivers.fousb) 
  4) Simulator   (weewx.drivers.simulator) 
  5) TE923   (weewx.drivers.te923) 
  6) Ultimeter   (weewx.drivers.ultimeter) 
  7) Vantage (weewx.drivers.vantage)   
  8) WMR100  (weewx.drivers.wmr100)
  9) WMR300  (weewx.drivers.wmr300)
 10) WMR9x8  (weewx.drivers.wmr9x8)
 11) WS1 (weewx.drivers.ws1)   
 12) WS23xx  (weewx.drivers.ws23xx)
 13) WS28xx  (weewx.drivers.ws28xx)
driver [4]: 

Tom Keffer schrieb am Sonntag, 31. März 2024 um 17:48:37 UTC+2:

> I did a quick port of the driver. It has *not* been tested!
>
> Find it here: https://github.com/tkeffer/weewx-wh23xx
>
> If it works for you, I'll ask Matthew to incorporate the changes.
>
> -tk
>
> On Sun, Mar 31, 2024 at 2:12 AM Tom Keffer  wrote:
>
>> It appears that the wh23xx driver has not been ported to Python 2.
>>
>> On Sun, Mar 31, 2024 at 1:33 AM Günther Wrana  wrote:
>>
>>> Ladies and Gentlemen
>>>
>>> Once again I need your help, how is it possible to use the weather 
>>> station I use with weewx version 5.0.
>>> I managed to install the new version of weewx and also the driver. It 
>>> only shows an error message during reconfiguration.
>>> With this command I installed the driver
>>> weektl extension install weewx-wh23xx-master.zip
>>>
>>>
>>> What have I done wrong again?
>>>
>>> Thanks for the help and have a nice Easter holidays!
>>>
>>> [image: Bildschirmfoto von 2024-03-31 10-27-33.png]
>>>
>>> Sehr geehrte Damen und Herren
>>>
>>> Wieder einmal brauche ich eure Hilfe, wie ist es möglich die von mir 
>>> verwendete Wetterstation mit weewx Version 5.0 zu verwenden.
>>> Ich habe es geschaft die neue Version von weewx zu installieren und auch 
>>> den Treiber. Nur bei der Rekonfiguration zeigt es eine Fehlermeldung an.
>>>
>>> 

[weewx-user] Re: Move WeeWx database to external drive

['Jon Fear' via weewx-user]

I am doing something similar using my NAS.

I have mounted the NAS and then created symbolic links to the appropriately 
named folders or directories on the NAS. When mounting the NAS, I needed to 
make sure that the permissions were correct for weewx which was eventually 
quite simple to achieve. If you are mounting the complete drive via say USB 
then it should be simple, just remember to create the appropriate 
directories and make sure the permissions are set correctly.

Best of luck..

Jon

On Monday 1 April 2024 at 13:54:43 UTC+1 Ben W. wrote:

> Hello!
>
> My setup is slowly coming together. Currently, I am able to see the data 
> on my local network via browser at 192.168.7.201/weewx. I feel pretty 
> accomplished so far, but I know I have a long ways to go. Before I get too 
> far, my intent is to use my attached external hard drive to store the data 
> for WeeWx. I'm pretty sure the data is being saved to the microSD card 
> right now.
>
> Would someone be able to direct me on how to move the database to my 
> external drive and instruct WeeWx to use that location going forward?
>
> I installed WeeWX V5 using 'apt' and the instructions here: 
> https://weewx.com/docs/5.0/quickstarts/debian/
>
> What I'm using:
> Ambient Weather WS-5000 weather station
> Ecowitt GW1100 hub
> RPi 5 8GB "headless"
> 2TB HDD drive
>
>
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/23310773-ac13-4bde-b440-9db61a8da551n%40googlegroups.com.

[weewx-user] Re: Change to daylight saving time stops data update

[Simon Duane]

>From what I've read, it involves an interaction between a Weewx service 
which adjusts the VP2 console clock to eliminate drift  - by default, it 
checks every 5 hours and applies the correction when the error is bigger 
than 5 seconds. I would suggest that if the error is close to 1 hour rather 
than a little more than 5 seconds, then the correction should simply not be 
applied, because of the risk of this happening. Fixing it on the next cycle 
will be good enough.
It happened to my Weewx v 4.9.1 + VP2 (for the first time) yesterday too 
and, because I have that archive parameter set to hardware, clearing the 
datalogger memory meant I lost about a day's data.

On Sunday 31 March 2024 at 23:56:23 UTC+1 Stephen wrote:

> I have two Davis Vantage Pro 2 weather stations at different locations. 
> Both stations stopped updating their web pages at 2.00am last night, the 
> moment daylight saving started.
>
> I'm running Weewx v5.0.1 at both locations.  Both Vantage Pro2 consoles 
> are configured to automatically change to DST.
>
> There is an old thread from 2017 about this problem here 
> https://groups.google.com/g/weewx-user/c/rM2IDREAWiI/m/oloGcj7aAAAJ.
>
> Taking the advice in that thread I've got one of the stations working 
> again by executing  weectl device --dump.  I've left the other station as 
> it is at the moment.
>
> This has never happened before, but I wasn't running v5.0.1 this time last 
> year.
>
> Any idea what's going on?
>

-- 
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/09e0d95f-ec44-4782-989f-d4ef3217ddadn%40googlegroups.com.

[weewx-user] Move WeeWx database to external drive

[Ben W.]

Hello!

My setup is slowly coming together. Currently, I am able to see the data on 
my local network via browser at 192.168.7.201/weewx. I feel pretty 
accomplished so far, but I know I have a long ways to go. Before I get too 
far, my intent is to use my attached external hard drive to store the data 
for WeeWx. I'm pretty sure the data is being saved to the microSD card 
right now.

Would someone be able to direct me on how to move the database to my 
external drive and instruct WeeWx to use that location going forward?

I installed WeeWX V5 using 'apt' and the instructions here: 
https://weewx.com/docs/5.0/quickstarts/debian/

What I'm using:
Ambient Weather WS-5000 weather station
Ecowitt GW1100 hub
RPi 5 8GB "headless"
2TB HDD drive


Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/81b7299f-f8bf-4325-804a-1cba50fbe4dbn%40googlegroups.com.

[weewx-user] Re: weatherflowpdp timeout

[Glen Briggs]

I got it going. Thank you. 

Now to learn how to customize and setup things.

On Sunday, March 31, 2024 at 10:28:40 PM UTC-5 vince wrote:

>
> The usual mistake is people putting in their station id (not the sensor 
> id) or removing the leading zeroes in the sensor id. In your case you have 
> it configured to use an air and sky original old station with both having 
> the same id numbers which is impossible.
>
> AR-00091987 and.SK-00091987 are clearly incorrect.
>
> You might to install my wfudptools app via pip and run the listener with 
> the —raw option to tell you your correct sensor id(s). See 
> https://pypi.org/project/wfudptools/ which has a link to the github page 
> for usage examples
>
> On Sunday, March 31, 2024 at 8:02:13 PM UTC-7 Glen Briggs wrote:
>
>> it appears to be running now, but i am getting nothing. no webpages, no 
>> data, no time outs, it just does nothing
>>
>>
>>
>> 2024-03-31T21:30:54.734273-05:00 frost systemd[1]: Started weewx.service 
>> - WeeWX.
>> 2024-03-31T21:30:54.958929-05:00 frost weewxd[7210]: INFO __main__: 
>> Initializing weewxd version 5.0.2
>> 2024-03-31T21:30:54.959612-05:00 frost weewxd[7210]: INFO __main__: 
>> Command line: /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
>> 2024-03-31T21:30:54.959979-05:00 frost weewxd[7210]: INFO __main__: Using 
>> Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
>> 2024-03-31T21:30:54.960361-05:00 frost weewxd[7210]: INFO __main__: 
>> Located at /usr/bin/python3
>> 2024-03-31T21:30:54.965927-05:00 frost weewxd[7210]: INFO __main__: 
>> Platform Linux-6.1.0-12-686-i686-with-glibc2.36
>> 2024-03-31T21:30:54.966200-05:00 frost weewxd[7210]: INFO __main__: 
>> Locale: 'en_US.UTF-8'
>> 2024-03-31T21:30:54.966522-05:00 frost weewxd[7210]: INFO __main__: Entry 
>> path: /usr/share/weewx/weewxd.py
>> 2024-03-31T21:30:54.966718-05:00 frost weewxd[7210]: INFO __main__: 
>> WEEWX_ROOT: /etc/weewx
>> 2024-03-31T21:30:54.966902-05:00 frost weewxd[7210]: INFO __main__: 
>> Configuration file: /etc/weewx/weewx.conf
>> 2024-03-31T21:30:54.972439-05:00 frost weewxd[7210]: INFO __main__: User 
>> module: /etc/weewx/bin/user
>> 2024-03-31T21:30:54.972699-05:00 frost weewxd[7210]: INFO __main__: 
>> Debug: 1
>> 2024-03-31T21:30:54.972902-05:00 frost weewxd[7210]: DEBUG __main__: 
>> Initializing engine
>> 2024-03-31T21:30:54.973165-05:00 frost weewxd[7210]: INFO weewx.engine: 
>> Loading station type WeatherFlowUDP (user.weatherflowudp)
>> 2024-03-31T21:30:54.978061-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: driver version is 1.10
>> 2024-03-31T21:30:54.978421-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: sensor map is {'outTemp': 
>> 'air_temperature.AR-00091987.obs_air', 'outHumidity': 
>> 'relative_humidity.AR-00091987.obs_air', 'pressure': 
>> 'station_pressure.AR-00091987.obs_air', 'lightning_strikes': 
>> 'lightning_strike_count.AR-00091987.obs_air', 'avg_distance': 
>> 'lightning_strike_avg_distance.AR-00091987.obs_air', 
>> 'outTempBatteryStatus': 'battery.AR-00091987.obs_air', 'windSpeed': 
>> 'wind_speed.SK-00091987.rapid_wind', 'windDir': 
>> 'wind_direction.SK-00091987.rapid_wind', 'lux': 
>> 'illuminance.SK-00091987.obs_sky', 'UV': 'uv.SK-00091987.obs_sky', 'rain': 
>> 'rain_accumulated.SK-00091987.obs_sky', 'windBatteryStatus': 
>> 'battery.SK-00091987.obs_sky', 'radiation': 
>> 'solar_radiation.SK-00091987.obs_sky', 'lightningYYY': 
>> 'distance.AR-00091987.evt_strike', 'lightningZZZ': 
>> 'energy.AR-00091987.evt_strike'}
>> 2024-03-31T21:30:54.988145-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: *** Sensor names per packet type
>> 2024-03-31T21:30:54.988531-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: packet obs_air: ('time_epoch', 'station_pressure', 
>> 'air_temperature', 'relative_humidity', 'lightning_strike_count', 
>> 'lightning_strike_avg_distance', 'battery', 'report_interval')
>> 2024-03-31T21:30:54.988855-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: packet obs_sky: ('time_epoch', 'illuminance', 'uv', 
>> 'rain_accumulated', 'wind_lull', 'wind_avg', 'wind_gust', 'wind_direction', 
>> 'battery', 'report_interval', 'solar_radiation', 
>> 'local_day_rain_accumulation', 'precipitation_type', 'wind_sample_interval')
>> 2024-03-31T21:30:54.989234-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: packet rapid_wind: ('time_epoch', 'wind_speed', 
>> 'wind_direction')
>> 2024-03-31T21:30:54.989563-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: packet evt_precip: time_epoch
>> 2024-03-31T21:30:54.989877-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: packet evt_strike: ('time_epoch', 'distance', 'energy')
>> 2024-03-31T21:30:54.990189-05:00 frost weewxd.py: weatherflowudp: 
>> MainThread: packet obs_st: ('time_epoch', 'wind_lull', 'wind_avg', 
>> 'wind_gust', 'wind_direction', 'wind_sample_interval', 'station_pressure', 
>> 'air_temperature', 'relative_humidity', 'illuminance', 'uv', 
>> 'solar_radiation', 'rain_accumulated', 

Re: [weewx-user] Change to daylight saving time stops data update

[Devonian]

Regular 'issue' for me in UK too.
I do this as I'm not yet on v5...amend as req'd.

sudo service weewx stop

sudo /home/weewx/bin/wee_device --dump  (or wherever your wee_device (or 
weectl device --dump) command is located)

sudo /home/weewx/bin/wee_device --clear  (or wherever your wee_device (or 
weectl device --clear) command is located)

sudo service weewx start

Never lost any data yet and to speed things up after clocks change. I try 
to remember the night before clocks change to clear the logger if all 
current data is saved to the db.

HTH

Nigel

On Monday 1 April 2024 at 00:05:08 UTC+1 Tom Keffer wrote:

> Issue #247  explains the 
> problem.
>
> On Sun, Mar 31, 2024 at 3:56 PM Stephen  wrote:
>
>> I have two Davis Vantage Pro 2 weather stations at different locations. 
>> Both stations stopped updating their web pages at 2.00am last night, the 
>> moment daylight saving started.
>>
>> I'm running Weewx v5.0.1 at both locations.  Both Vantage Pro2 consoles 
>> are configured to automatically change to DST.
>>
>> There is an old thread from 2017 about this problem here 
>> https://groups.google.com/g/weewx-user/c/rM2IDREAWiI/m/oloGcj7aAAAJ.
>>
>> Taking the advice in that thread I've got one of the stations working 
>> again by executing  weectl device --dump.  I've left the other station as 
>> it is at the moment.
>>
>> This has never happened before, but I wasn't running v5.0.1 this time 
>> last year.
>>
>> Any idea what's going on?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/bc83e9f6-5231-4702-8afc-758c645061cdn%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/b91d7f0d-e207-4953-b4d0-3340f8832640n%40googlegroups.com.