[weewx-user] Re: Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

2024-01-19 Thread 'michael.k...@gmx.at' via weewx-user
The empty queue is probably because of running it in WSL and being in a 
different IP range than the Console:
2024-01-19 18:47:39 weewxd[13771] DEBUG user.interceptor: empty queue

$ ip addr
2: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:15:5d:a1:b2:53 brd ff:ff:ff:ff:ff:ff
inet 172.19.239.191/20 brd 172.19.239.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::215:5dff:fea1:b253/64 scope link 
   valid_lft forever preferred_lft forever

And the console has 10.0.1.106

I need to set up WSL to be in the same network or try this on another 
machine.

Anyway, @grj80: have you ever considered collecting data from more than one 
ecowitt console device with the driver? For me this would make perfect 
sense, but I can very well understand, if it doesn't to you :D
michael.k...@gmx.at schrieb am Freitag, 19. Januar 2024 um 18:48:05 UTC+1:

> Yes, it's possible. 
> 2024-01-19 18:27:35 weewxd[5855] DEBUG user.gw1000: Next update in 9 
> seconds
> 2024-01-19 18:27:35 weewxd[5855] DEBUG user.gw1000: Next update in 9 
> seconds
> LOOP:   2024-01-19 18:27:35 CET (1705685255) 'altimeter': 
> '1023.2565915245989', 'appTemp': '-4.6378894597484965', 'barometer': 
> '1026.3446847507096', 'cloudbase': '972.4294835518078', 'dateTime': 
> '1705685255', 'daymaxwind': '2.1', 'dayRain': '4.7', 'dewpoint': 
> '-6.267050581532717', 'ET': 'None', 'extraHumid6': '62', 'extraHumid7': 
> '61', 'extraHumid8': '58', 'extraTemp6': '14.8', 'extraTemp7': '19.9', 
> 'extraTemp8': '20.6', 'heatindex': '-1.9008', 'humidex': 
> '-1.9', 'inDewpoint': '12.462345522375951', 'inHumidity': '60', 'inTemp': 
> '20.5', 'lightning_distance': 'None', 'lightning_last_det_time': 
> '1705345360', 'lightning_strike_count': '0', 'lightningcount': '0', 
> 'luminosity': '0.0', 'maxSolarRad': '0.0', 'monthRain': '50.4', 
> 'outHumidity': '72', 'outTemp': '-1.9', 'p_dayRain': '0.0', 'p_monthRain': 
> '26.5', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '0.0', 
> 'p_weekRain': '11.8', 'p_yearRain': '26.5', 'pressure': '971.0', 
> 'radiation': '0.0', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': 
> '1023.8', 'stormRain': '0.0', 'usUnits': '17', 'UV': '0', 'uvradiation': 
> '0.0', 'weekRain': '15.2', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 
> 'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 
> 'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': 
> '1.45', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windchill': 
> '-1.9008', 'windDir': 'None', 'windGust': '1.3', 'windrun': 
> 'None', 'windSpeed': '0.0', 'ws90_batt': '3.28', 'ws90_sig': '4', 
> 'yearRain': '50.4'
>
> But why would anybody want to do this? I have two GW2000 devices and want 
> to store and show data of as many of my sensor possible in a single weewx 
> instance. Yet configuring the driver both, as driver and a service at the 
> same time, seems to work as I hoped at least foor LOOP: two device queries, 
> on LOOP data.
>
> The question now: is it possible to configure the driver/service in a way, 
> they uses their own ip_address and is it possible to map the Wind/Dir/Gust 
> of the WS90 bound to the one GW2000, to e.g. 
> us_windSpeed/us_windDir/us_windGust (us for ultrasonic) just like p_rain 
> for the haptic array?
>
> Or isn't this possible and do I have to combine the Interceptor driver 
> with the Ecowitt Gateway Driver, one as a service, the other as a Driver to 
> achieve this? If yes, how could this be possible, I tried it with 
> Interceptor as a driver and Ecowitt Gateway Driver as a Service and get not 
> device data:
> 2024-01-19 18:46:59 weewxd[13771] DEBUG user.interceptor: empty queue
> 2024-01-19 18:47:07 weewxd[13771] DEBUG user.gw1000: Next update in 9 
> seconds
> 2024-01-19 18:47:09 weewxd[13771] DEBUG user.interceptor: empty queue
> 2024-01-19 18:47:16 weewxd[13771] DEBUG user.gw1000: Next update in 9 
> seconds
> 2024-01-19 18:47:19 weewxd[13771] DEBUG user.interceptor: empty queue
> 2024-01-19 18:47:25 weewxd[13771] DEBUG user.gw1000: Next update in 9 
> seconds
> 2024-01-19 18:47:29 weewxd[13771] DEBUG user.interceptor: empty queue
> 2024-01-19 18:47:34 weewxd[13771] DEBUG user.gw1000: Next update in 9 
> seconds
> 2024-01-19 18:47:39 weewxd[13771] DEBUG user.interceptor: empty queue
> 2024-01-19 18:47:43 weewxd[13771] DEBUG user.gw1000: Next update in 9 
> seconds
> 2024-01-19 18:47:49 weewxd[13771] DEBUG user.interceptor: empty queue
>
>
>

-- 
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/ea0690b6-7c35-46b1-ba44-a11abfb68dc2n%40googlegroups.com.


Re: [weewx-user] Slow Report Generation after Upgrade from 4.10.2 to 5..0

2024-01-19 Thread Richard Whitcombe
Actually follow up that ive only just noticed.
Since performing this fix ive lost the "Feels like" temperature display on 
my skin on all pages.

On Friday 19 January 2024 at 19:47:31 UTC+9 Richard Whitcombe wrote:

> I just did AppTemperature but its working for me.
> Although i dont think i use any of the other columns as my station doesnt 
> provide it.
>
> Missing data calculations took about 8 minutes for 7 years of data on a 
> Pi4.
>
> On Friday 19 January 2024 at 19:14:09 UTC+9 mh081...@gmail.com wrote:
>
>> Hi,
>>
>> as i read in the other posts about this Problem i doing now following.
>>
>> weectl database add-column appTemp
>> weectl database add-column cloudbase
>> weectl database add-column visibility
>> weectl database add-column windrun
>> weectl database add-column cloud_cover
>> weectl database add-column aqi
>>
>> weectl database calc-missing
>>
>> Answer all wit 'y'
>>
>> Now it seems that the Problem was solved. Belchertown Reports was 
>> generated in about 6 seconds. Thanks @vince for your right direction.
>> ##
>> Jan 19 11:09:50 wetter weewxd[293936]: INFO weewx.engine: Loading station 
>> type Vantage (weewx.drivers.vantage)
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: StdConvert 
>> target unit is 0x1
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.wxservices: 
>> StdWXCalculate will use data binding wx_binding
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Archive will 
>> use data binding wx_binding
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Record 
>> generation will be attempted in 'hardware'
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Using archive 
>> interval of 300 seconds (specified by hardware)
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: StationRegistry: 
>> Registration not requested.
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: 
>> Wunderground-PWS: Data for station IMECKLEN47 will be posted
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: Data 
>> for station MHROSTOCK will be posted
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: CWOP: Posting 
>> not enabled.
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: WOW: Posting not 
>> enabled.
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: AWEKAS: Posting 
>> not enabled.
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: service version is 
>> 0.23
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: binding to 
>> ['archive', 'loop']
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: topic is weather
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: desired unit 
>> system is METRIC
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: data will be 
>> uploaded to mqtt://pi:x...@gw.martenhinrichs.de:8883/ 
>> 
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: network 
>> encryption/authentication will be attempted
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: 'pyephem' 
>> detected, extended almanac data is available
>> Jan 19 11:09:53 wetter weewxd[293936]: INFO __main__: Starting up weewx 
>> version 5.0.0
>> Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.engine: Clock error is 
>> 2.69 seconds (positive is fast)
>> Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.engine: Using binding 
>> 'wx_binding' to database 'weewx.sdb'
>> Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.manager: Starting 
>> backfill of daily summaries
>> Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.manager: Daily 
>> summaries up to date
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.wxxtypes: Type beaufort 
>> has been deprecated. Use unit beaufort instead.
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
>> 2024-01-19 10:50:00 CET (1705657800) to database 'weewx.sdb'
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
>> 2024-01-19 10:50:00 CET (1705657800) to daily summary in 'weewx.sdb'
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
>> 2024-01-19 10:55:00 CET (1705658100) to database 'weewx.sdb'
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
>> 2024-01-19 10:55:00 CET (1705658100) to daily summary in 'weewx.sdb'
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
>> 2024-01-19 11:00:00 CET (1705658400) to database 'weewx.sdb'
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
>> 2024-01-19 11:00:00 CET (1705658400) to daily summary in 'weewx.sdb'
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: 
>> Published record 2024-01-19 10:50:00 CET (1705657800)
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
>> 2024-01-19 11:05:00 CET (1705658700) to database 'weewx.sdb'
>> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
>> 

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

2024-01-19 Thread Richard Whitcombe
I have an Aercus Weathsleuth so not sure (run via the interceptor driver).  
Backup the DB and theres nothing to lose by trying the solution really.
On Saturday 20 January 2024 at 01:33:14 UTC+9 Michael Sanphillipo wrote:

> Richard, just curious do you have an Acurite weather station and using 
> Belcherstown? I'm just trying to see if we have the same type of setup 
> before going back to V5 and trying your solution. Thanks!
>
> On Friday, January 19, 2024 at 5:49:18 AM UTC-5 Richard Whitcombe wrote:
>
>> FWIW i just needed to add appTemp and its worked - report generation now 
>> takes 3 seconds not 190.
>> I would caveat that by saying im not using the other missing columns at 
>> all as my station doesnt provide the data so maybe if you are they need to 
>> be added too.
>> Missing data calculations took about 8 mins for 2017 - 2024 on a Pi4.
>>
>> On Friday 19 January 2024 at 15:59:15 UTC+9 vince wrote:
>>
>>> Re: the Belchertown issue many seem to be facing, I notice that Blaine's 
>>> db uses the original old wview schema, not the newer bigger 
>>> 'wview_extended' schema that came out a few years ago.  I suspect this is 
>>> the pattern we've missed.  Folks who have the old schema do not have any of 
>>> the elements for many of the Extended Observations in Belchertown's 
>>> skin.conf file. 
>>>
>>> Blaine's db schema misses these items in Belchertown's skin.conf 
>>> extended observations list
>>> appTemp  = Apparent Temperature
>>> cloudbase= Cloud Base
>>> visibility   = Visibility
>>> windrun  = Wind Run
>>> cloud_cover  = Cloud Cover
>>> aqi  = AQI
>>>
>>> The wview_extended schema is missing these, so I'd expect users with 
>>> data in those somehow might have the same slowness issue until they add db 
>>> elements and calc-missing to generate summary tables for them.
>>> visibility   = Visibility
>>> cloud_cover  = Cloud Cover
>>>
>>> Re: Michael's question about what to do about the NOAA files, I'd 
>>> suggest pre-calculating them offline and dropping them into place in his 
>>> NOAA subdirectory with the appropriate owner/group/mode so they don't have 
>>> to be recalculated.  I'd omit the current month+year which should 
>>> regenerate quickly on weewx startup.  That would be a good thing to try. 
>>>  We've verified the db is ok, so it 'should' work on Blaine's system too 
>>> (hopefully).  The test then would be to simply look at the date+time last 
>>> modified for the current month and year NOAA file.  It should change every 
>>> archive period as StdReport runs.
>>>
>>> (reminder - if you have Belchertown 'and' Seasons, you need to drop the 
>>> pre-calculated NOAA files into both places to preseed both skin output 
>>> directories)
>>>
>>> On Thursday, January 18, 2024 at 8:36:20 PM UTC-8 michael.k...@gmx.at 
>>> wrote:
>>>
 Or, to speed things up, do the "calc-missing" on another machine with a 
 more potent CPU.

 Back to Blaine's problem: if the NOAA files are generated on other 
 installations with his database, there is obviously another problem with 
 his installation.I don't have an idea what to look for, if deleted NOAA 
 data will be regenerated in the same way, as before.

 vince schrieb am Freitag, 19. Januar 2024 um 04:55:13 UTC+1:

> Docs are at https://www.weewx.com/docs/5.0/utilities/weectl-database/ 
> but what I did for a pip installation using Blaine's db was:
>
> source ~/weewx-venv/bin/activate
> weectl database add-column appTemp
> weectl calc-missing
> (answer y when prompted above)
>
> If you have a packaged install of weewx you can skip the activate step 
> above.
>
> Note - the calc-missing takes quite a while and will peg your cpu 
> while working, so if you have a lot of data so you might need to use the 
> --from and --to options or even the --tranche option to split up the 
> processing a bit into pieces.  I got lucky with this db on pi3plus with a 
> bit of patience waiting for calc-missing to complete
>
> (weewx-venv) pi@pi3plus:~/weewx-data $ weectl database calc-missing -y
> Using configuration file /home/pi/weewx-data/weewx.conf
> Missing derived observations will be calculated for all records.
> Calculating missing derived observations...
> Processing record: 959536; Last record: 2024-01-19 00:00:00 PST 
> (1705651200)
> Recalculating daily summaries...
> Records processed: 959000; time: 2024-01-16 15:55:00 PST (1705449300)
> Finished recalculating daily summaries
> Missing derived observations calculated in 2986.21 seconds
>
> And after restarting weewx things look good 
>
> 2024-01-18T19:45:15.438555-08:00 pi3plus weewxd[1797]: INFO 
> weewx.manager: Added record 2024-01-18 19:45:00 PST (1705635900) to 
> 

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

2024-01-19 Thread Tom Keffer
We've seen this problem with largish databases. Try setting the option
--tranche to 5, or even 1

weectl database calc-missing --tranch=1


On Fri, Jan 19, 2024 at 4:03 PM Michael Sanphillipo 
wrote:

> What happens when the sudo weectl database calc-missing command stops on a
> date and seems to stall?
>
> On Friday, January 19, 2024 at 5:53:11 PM UTC-5 Tom Keffer wrote:
>
>> Good sleuthing, Paul!
>>
>> On Fri, Jan 19, 2024 at 10:23 AM Paul R Anderson 
>> wrote:
>>
>>> This was really fun to track down! Thanks for the challenge !
>>> I have been able to reproduce your issue... it's a  little complicated,
>>> but it can be fixed  easily :)
>>> It's caused by 2 factors
>>> *1. Your station seems to have stopped reporting Barometric Pressure on
>>> or about 2019-12-31 @ 16:45 *
>>> *No idea why, hopefully you are aware of this and know the cause.*
>>>
>>> *2. Your using an older version of  NOAA-%Y-%m.txt.tmpl*
>>> The older version used this statement to determine if there was data for
>>> each day
>>> #for $day in $month.days
>>> #if $day.barometer.count.raw
>>> So it fails because there is no  $day.barometer.count.raw
>>> Your Monthly Report will look like this:
>>>
>>>MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>>>
>>>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>>>
>>>  HEAT   COOL AVG
>>>   MEAN   DEGDEG  WIND
>>> DOM
>>> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED
>>> HIGH   TIMEDIR
>>> 
>>> ---
>>>  01
>>>  02
>>>  03
>>>  04
>>>  05
>>>  06
>>>  07
>>>  08
>>>  09
>>>  10
>>>  11
>>>  12
>>>  13
>>>  14
>>>  15
>>>  16
>>>  17
>>>  18
>>>  19
>>>  20
>>>  21
>>>  22
>>>  23
>>>  24
>>>  25
>>>  26
>>>  27
>>>  28
>>>  29
>>>  30
>>>  31
>>> 
>>> ---
>>>   55.4   81.3 31   44.4 12  294.20.7   0.150.4
>>> 14.0 29302
>>>
>>> *Newer version of NOAA-%Y-%m.txt.tmp*
>>> Changed how it determines if there was data for each day
>>> #for $day in $month.days
>>> #if $day.outTemp.has_data or $day.rain.has_data or $day.wind.has_data
>>> So it will pass even if there is no  $day.barometer.count.raw
>>> Your Monthly Report will now look like this:
>>>
>>>  MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>>>
>>>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>>>
>>>  HEAT   COOL AVG
>>>   MEAN   DEGDEG  WIND
>>> DOM
>>> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED
>>> HIGH   TIMEDIR
>>>
>>> ---
>>>  01   55.7   63.8  10:55   47.4  03:409.30.0   0.000.3
>>>  9.0  08:00294
>>>  02   55.9   64.1  06:30   51.5  03:109.10.0   0.000.3
>>>  4.0  05:45322
>>>  03   62.5   72.2  16:55   52.5  23:152.50.0   0.000.6
>>>  6.0  14:50301
>>>  04   57.3   71.7  16:55   48.7  07:207.70.0   0.000.4
>>>  6.0  13:30297
>>>  05   56.9   70.0  16:45   47.8  10:158.10.0   0.000.4
>>>  6.0  16:50302
>>>  06   64.5   80.7  16:20   53.1  10:250.50.0   0.000.2
>>>  6.0  14:50297
>>>  07   60.8   79.3  15:40   50.5  00:404.20.0   0.000.3
>>>  7.0  15:55299
>>>  08   51.9   62.5  15:05   47.1  08:30   13.10.0   0.000.5
>>>  9.0  15:30317
>>>  09   50.9   60.8  14:20   46.6  01:25   14.10.0   0.000.6
>>> 11.0  15:35301
>>>  10   51.6   64.1  16:30   44.9  09:35   13.40.0   0.010.5
>>>  7.0  15:50294
>>>  11   51.0   60.6  15:20   45.0  07:25   14.00.0   0.000.7
>>> 13.0  15:25325
>>>  12   51.2   62.5  15:10   44.4  09:15   13.80.0   0.000.5
>>> 10.0  16:25298
>>>  13   51.2   59.8  17:45   46.3  08:50   13.80.0   0.000.5
>>>  8.0  17:30300
>>>  14   50.4   60.5  16:35   45.2  10:00   14.60.0   0.010.4
>>>  9.0  17:00294
>>>  15   51.1   65.1  16:00   44.4  09:40   13.90.0   0.000.4
>>>  8.0  17:25296
>>>  16   50.3   58.4  15:20   45.4  10:00   14.70.0   0.050.8
>>> 11.0  01:25315
>>>  17   51.2   60.1  16:55   45.5  10:20   13.80.0   0.050.6
>>> 12.0  03:40316
>>>  18   56.1   69.6  17:30   46.9  06:108.90.0   0.000.2
>>>  6.0  16:10294
>>>  19   58.6   76.1  14:50   49.0  10:056.40.0   0.000.2
>>>  9.0  15:10300
>>>  20   54.9   59.3  15:45   52.4  04:50   10.10.0   0.000.3
>>> 11.0  15:50306
>>>  21   52.0   56.8  14:20   47.7  02:15   13.00.0   0.030.3
>>>  7.0  14:35310
>>>  22   52.6   61.1  14:25   47.6  04:35   12.40.0   0.000.5
>>>  8.0  16:25  

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

2024-01-19 Thread vince
Providing logs always helps folks try to helpbut you can add the --from 
and --to switches to do a range of dates.  Possibly add the --tranche 
option to set the number of records in a batch it runs.

On Friday, January 19, 2024 at 4:03:44 PM UTC-8 Michael Sanphillipo wrote:

> What happens when the sudo weectl database calc-missing command stops on a 
> date and seems to stall?
>
> On Friday, January 19, 2024 at 5:53:11 PM UTC-5 Tom Keffer wrote:
>
>> Good sleuthing, Paul!
>>
>> On Fri, Jan 19, 2024 at 10:23 AM Paul R Anderson  
>> wrote:
>>
>>> This was really fun to track down! Thanks for the challenge !
>>> I have been able to reproduce your issue... it's a  little complicated, 
>>> but it can be fixed  easily :)
>>> It's caused by 2 factors
>>> *1. Your station seems to have stopped reporting Barometric Pressure on 
>>> or about 2019-12-31 @ 16:45 *
>>> *No idea why, hopefully you are aware of this and know the cause.*
>>>
>>> *2. Your using an older version of  NOAA-%Y-%m.txt.tmpl*
>>> The older version used this statement to determine if there was data for 
>>> each day
>>> #for $day in $month.days
>>> #if $day.barometer.count.raw
>>> So it fails because there is no  $day.barometer.count.raw
>>> Your Monthly Report will look like this:
>>>
>>>MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>>>
>>>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>>>
>>>  HEAT   COOL AVG
>>>   MEAN   DEGDEG  WIND   
>>> DOM
>>> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   
>>> HIGH   TIMEDIR
>>> 
>>> ---
>>>  01
>>>  02
>>>  03
>>>  04
>>>  05
>>>  06
>>>  07
>>>  08
>>>  09
>>>  10
>>>  11
>>>  12
>>>  13
>>>  14
>>>  15
>>>  16
>>>  17
>>>  18
>>>  19
>>>  20
>>>  21
>>>  22
>>>  23
>>>  24
>>>  25
>>>  26
>>>  27
>>>  28
>>>  29
>>>  30
>>>  31
>>> 
>>> ---
>>>   55.4   81.3 31   44.4 12  294.20.7   0.150.4   
>>> 14.0 29302
>>>
>>> *Newer version of NOAA-%Y-%m.txt.tmp*
>>> Changed how it determines if there was data for each day
>>> #for $day in $month.days
>>> #if $day.outTemp.has_data or $day.rain.has_data or $day.wind.has_data
>>> So it will pass even if there is no  $day.barometer.count.raw
>>> Your Monthly Report will now look like this:
>>>  
>>>  MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>>>
>>>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>>>
>>>  HEAT   COOL AVG
>>>   MEAN   DEGDEG  WIND   
>>> DOM
>>> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   
>>> HIGH   TIMEDIR
>>>
>>> ---
>>>  01   55.7   63.8  10:55   47.4  03:409.30.0   0.000.3   
>>>  9.0  08:00294
>>>  02   55.9   64.1  06:30   51.5  03:109.10.0   0.000.3   
>>>  4.0  05:45322
>>>  03   62.5   72.2  16:55   52.5  23:152.50.0   0.000.6   
>>>  6.0  14:50301
>>>  04   57.3   71.7  16:55   48.7  07:207.70.0   0.000.4   
>>>  6.0  13:30297
>>>  05   56.9   70.0  16:45   47.8  10:158.10.0   0.000.4   
>>>  6.0  16:50302
>>>  06   64.5   80.7  16:20   53.1  10:250.50.0   0.000.2   
>>>  6.0  14:50297
>>>  07   60.8   79.3  15:40   50.5  00:404.20.0   0.000.3   
>>>  7.0  15:55299
>>>  08   51.9   62.5  15:05   47.1  08:30   13.10.0   0.000.5   
>>>  9.0  15:30317
>>>  09   50.9   60.8  14:20   46.6  01:25   14.10.0   0.000.6   
>>> 11.0  15:35301
>>>  10   51.6   64.1  16:30   44.9  09:35   13.40.0   0.010.5   
>>>  7.0  15:50294
>>>  11   51.0   60.6  15:20   45.0  07:25   14.00.0   0.000.7   
>>> 13.0  15:25325
>>>  12   51.2   62.5  15:10   44.4  09:15   13.80.0   0.000.5   
>>> 10.0  16:25298
>>>  13   51.2   59.8  17:45   46.3  08:50   13.80.0   0.000.5   
>>>  8.0  17:30300
>>>  14   50.4   60.5  16:35   45.2  10:00   14.60.0   0.010.4   
>>>  9.0  17:00294
>>>  15   51.1   65.1  16:00   44.4  09:40   13.90.0   0.000.4   
>>>  8.0  17:25296
>>>  16   50.3   58.4  15:20   45.4  10:00   14.70.0   0.050.8   
>>> 11.0  01:25315
>>>  17   51.2   60.1  16:55   45.5  10:20   13.80.0   0.050.6   
>>> 12.0  03:40316
>>>  18   56.1   69.6  17:30   46.9  06:108.90.0   0.000.2   
>>>  6.0  16:10294
>>>  19   58.6   76.1  14:50   49.0  10:056.40.0   0.000.2   
>>>  9.0  15:10300
>>>  20   54.9   59.3  15:45   52.4  04:50   10.10.0   0.000.3   
>>> 11.0  15:50306
>>>  21   

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

2024-01-19 Thread Michael Sanphillipo
What happens when the sudo weectl database calc-missing command stops on a 
date and seems to stall?

On Friday, January 19, 2024 at 5:53:11 PM UTC-5 Tom Keffer wrote:

> Good sleuthing, Paul!
>
> On Fri, Jan 19, 2024 at 10:23 AM Paul R Anderson  
> wrote:
>
>> This was really fun to track down! Thanks for the challenge !
>> I have been able to reproduce your issue... it's a  little complicated, 
>> but it can be fixed  easily :)
>> It's caused by 2 factors
>> *1. Your station seems to have stopped reporting Barometric Pressure on 
>> or about 2019-12-31 @ 16:45 *
>> *No idea why, hopefully you are aware of this and know the cause.*
>>
>> *2. Your using an older version of  NOAA-%Y-%m.txt.tmpl*
>> The older version used this statement to determine if there was data for 
>> each day
>> #for $day in $month.days
>> #if $day.barometer.count.raw
>> So it fails because there is no  $day.barometer.count.raw
>> Your Monthly Report will look like this:
>>
>>MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>>
>>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>>
>>  HEAT   COOL AVG
>>   MEAN   DEGDEG  WIND 
>>   DOM
>> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   HIGH 
>>   TIMEDIR
>> 
>> ---
>>  01
>>  02
>>  03
>>  04
>>  05
>>  06
>>  07
>>  08
>>  09
>>  10
>>  11
>>  12
>>  13
>>  14
>>  15
>>  16
>>  17
>>  18
>>  19
>>  20
>>  21
>>  22
>>  23
>>  24
>>  25
>>  26
>>  27
>>  28
>>  29
>>  30
>>  31
>> 
>> ---
>>   55.4   81.3 31   44.4 12  294.20.7   0.150.4   14.0 
>> 29302
>>
>> *Newer version of NOAA-%Y-%m.txt.tmp*
>> Changed how it determines if there was data for each day
>> #for $day in $month.days
>> #if $day.outTemp.has_data or $day.rain.has_data or $day.wind.has_data
>> So it will pass even if there is no  $day.barometer.count.raw
>> Your Monthly Report will now look like this:
>>  
>>  MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>>
>>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>>
>>  HEAT   COOL AVG
>>   MEAN   DEGDEG  WIND 
>>   DOM
>> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   HIGH 
>>   TIMEDIR
>>
>> ---
>>  01   55.7   63.8  10:55   47.4  03:409.30.0   0.000.39.0 
>>  08:00294
>>  02   55.9   64.1  06:30   51.5  03:109.10.0   0.000.34.0 
>>  05:45322
>>  03   62.5   72.2  16:55   52.5  23:152.50.0   0.000.66.0 
>>  14:50301
>>  04   57.3   71.7  16:55   48.7  07:207.70.0   0.000.46.0 
>>  13:30297
>>  05   56.9   70.0  16:45   47.8  10:158.10.0   0.000.46.0 
>>  16:50302
>>  06   64.5   80.7  16:20   53.1  10:250.50.0   0.000.26.0 
>>  14:50297
>>  07   60.8   79.3  15:40   50.5  00:404.20.0   0.000.37.0 
>>  15:55299
>>  08   51.9   62.5  15:05   47.1  08:30   13.10.0   0.000.59.0 
>>  15:30317
>>  09   50.9   60.8  14:20   46.6  01:25   14.10.0   0.000.6   11.0 
>>  15:35301
>>  10   51.6   64.1  16:30   44.9  09:35   13.40.0   0.010.57.0 
>>  15:50294
>>  11   51.0   60.6  15:20   45.0  07:25   14.00.0   0.000.7   13.0 
>>  15:25325
>>  12   51.2   62.5  15:10   44.4  09:15   13.80.0   0.000.5   10.0 
>>  16:25298
>>  13   51.2   59.8  17:45   46.3  08:50   13.80.0   0.000.58.0 
>>  17:30300
>>  14   50.4   60.5  16:35   45.2  10:00   14.60.0   0.010.49.0 
>>  17:00294
>>  15   51.1   65.1  16:00   44.4  09:40   13.90.0   0.000.48.0 
>>  17:25296
>>  16   50.3   58.4  15:20   45.4  10:00   14.70.0   0.050.8   11.0 
>>  01:25315
>>  17   51.2   60.1  16:55   45.5  10:20   13.80.0   0.050.6   12.0 
>>  03:40316
>>  18   56.1   69.6  17:30   46.9  06:108.90.0   0.000.26.0 
>>  16:10294
>>  19   58.6   76.1  14:50   49.0  10:056.40.0   0.000.29.0 
>>  15:10300
>>  20   54.9   59.3  15:45   52.4  04:50   10.10.0   0.000.3   11.0 
>>  15:50306
>>  21   52.0   56.8  14:20   47.7  02:15   13.00.0   0.030.37.0 
>>  14:35310
>>  22   52.6   61.1  14:25   47.6  04:35   12.40.0   0.000.58.0 
>>  16:25296
>>  23   59.9   73.0  16:20   50.0  07:205.10.0   0.000.47.0 
>>  15:40306
>>  24   59.0   74.2  16:55   51.0  02:056.00.0   0.000.35.0 
>>  13:05297
>>  25   54.9   69.8  17:10   46.9  08:45   

[weewx-user] Re: Web page will not refresh after update to 5.0

2024-01-19 Thread Jim Wilkerson
Fixed.

So when I upgraded from 4.10.2 to 5.0 via openSUSE YaST, the previously 
populated /etc/weewx/skins folder, under which held the Seasons folder and 
then the required index.html.tmpl file; was wiped out and replaced with 
just a Seasons folder that has an index.html.tmpl.rpmsave file only in it.

So I rolled back to 4.10.2, which restored the /skins contents, then tar'd 
it up; reinstalled 5.0, then restored the /skins folder contents.

Edited the restored /etc/weewx/skins/Seasons/index.html.tmpl and added as 
shown



  
   <<<--- Line that was 
recommended

$station.location


#if $station.station_url

#end if

  

The web page is now working/refreshing as expected.

On Thursday, January 18, 2024 at 9:42:53 PM UTC-5 vince wrote:

> Ignore the version in weewx.conf, it's where your .conf file started with 
> (notionally)  - the one you see in syslog is the running version.
>
> I'd suggest you install rsyslog and copy the util/rsyslog/weewx.conf file 
> into place (and reset rsyslog) and then you'll have traditional syslogging 
> rather than the systemd hell requiring journalctl and the like.  If you 
> enable rsyslog your logs will be old-school and present in 
> /var/log/weewx/weewx.log which is much easier to find things in.  Highly 
> recommend doing that.
>
> On Thursday, January 18, 2024 at 4:16:20 PM UTC-8 Jim Wilkerson wrote:
>
>> The logs I attached from my previous post are from a 5.0 installation.  
>> My one point is that I sue the openSUSE normal installation update via YaST 
>> but the config file is still showing version 4.10.2.
>>
>> ~> weewxd --version
>> 5.0.0
>>
>> shows the current running version.
>>
>> Also, I see debug enabled:
>>
>> 2024-01-17T21:18:28.763125-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Initializing weewxd version 5.0.0
>> 2024-01-17T21:18:28.763396-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Command line: /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
>> 2024-01-17T21:18:28.763495-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Using Python 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]
>> 2024-01-17T21:18:28.763590-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Located at /usr/bin/python3
>> 2024-01-17T21:18:28.773695-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Platform Linux-5.14.21-150500.55.39-default-x86_64-with-glibc2.3.4
>> 2024-01-17T21:18:28.773884-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Locale: 'en_US.UTF-8'
>> 2024-01-17T21:18:28.774001-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Entry path: /usr/share/weewx/weewxd.py
>> 2024-01-17T21:18:28.774104-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> WEEWX_ROOT: /
>> 2024-01-17T21:18:28.774196-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Configuration file: /etc/weewx/weewx.conf
>> 2024-01-17T21:18:28.774289-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> User module: /etc/weewx/bin/user
>> 2024-01-17T21:18:28.774790-05:00 linux-3wjh weewxd[31248]: INFO __main__: 
>> Debug: 1
>>
>> but I do not see any debug level entries when I run
>>
>> sudo journalctl -r -u weewx
>>
>> Reverting back to 4.10.2, then running that command with debug=1, I do 
>> see entries:
>>
>> Jan 17 23:01:49 linux-3wjh python3[17385]: weewx[17385] DEBUG __main__:   
>>     _recv = self.socket.recv(_N)
>>
>> So, what config file is 5.0.0 using on openSUSE Leap 15.5?
>>
>>
>>
>>
>>
>>
>> On Thursday, January 18, 2024 at 1:02:58 AM UTC-5 vince wrote:
>>
>>> Files seem to be in /var/www/html/weewx for 4.10.2 but you are not 
>>> providing enough logs to see where they are being written to for v5.
>>>
>>> Try "sudo journalctl -xe -n 200 -u weewx" with v5 running.  Hit 'q' 
>>> since you'll be in a pager.
>>>
>>> Basically I'm looking for the reportengine lines.  Mine looks like this 
>>> (your path will differ but hopefully it's /var/www/html/weewx for v5 as 
>>> well)
>>> Jan 17 21:50:23 pi4 weewxd[11819]: INFO weewx.cheetahgenerator: 
>>> Generated 12 files for report Belchertown in 4.35 seconds
>>> Jan 17 21:50:23 pi4 weewxd[11819]: INFO weewx.reportengine: Copied 3 
>>> files to /home/pi/weewx-data/public_html/vp2/belchertown
>>>
>>>
>>> On Wednesday, January 17, 2024 at 7:10:16 PM UTC-8 Jim Wilkerson wrote:
>>>
 Set debug=1   in /etc/weewx/weewx.conf

 (2) reports, 21:30 and 22:00 EST

 Attached are the requested outputs.

 The database appears to have been updated in the same place:

 /var/lib/weewx # ls  -l
 total 22452
 -rw-r--r-- 1 root root 22990848 Jan 17 22:00 weewx.sdb


 On Wednesday, January 17, 2024 at 9:01:43 PM UTC-5 vince wrote:

> Jim please set debug=1 and restart weewx. For logs you might try to do 
> ‘sudo journalctl -u weewx -n 200’ so we see the last 200 lines and not a 
> truncated log,. We need to see your reports actually run and where they 
> are 
> being written to. My wild guess is your v5 is writing to a different 
> 

Re: [weewx-user] Rain Rate error

2024-01-19 Thread Tom Keffer
You can use the StdQC
 service as
a filter.

If your hardware does not supply it (check!), rainRate is calculated by class
RainRater .

On Fri, Jan 19, 2024 at 10:45 AM Luis  wrote:

> Hi all,
> I have errors for rain rate showing illogical values:
> I also have problems with the battery and there are a couple of hours
> before dawn with no data transmission.
> [image: rainrate_error.png]
> The rain rate value shown here must be the product of some zero division.
> Any ideas?
> I would be happy if someone points me to the place of code where this
> value is computed for adding a control to avoid this absurd value.
> Any ideas?
> Thanks so much
> Luis Rosety
>
> --
> 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/f6283484-f8e4-4ac1-aaa4-38097def1772n%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/CAPq0zEDL3fFYL72by9pmEGok%3DQSkT9yVXX0AVspuoCZxkXp7Vw%40mail.gmail.com.


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

2024-01-19 Thread Tom Keffer
Good sleuthing, Paul!

On Fri, Jan 19, 2024 at 10:23 AM Paul R Anderson  wrote:

> This was really fun to track down! Thanks for the challenge !
> I have been able to reproduce your issue... it's a  little complicated,
> but it can be fixed  easily :)
> It's caused by 2 factors
> *1. Your station seems to have stopped reporting Barometric Pressure on or
> about 2019-12-31 @ 16:45 *
> *No idea why, hopefully you are aware of this and know the cause.*
>
> *2. Your using an older version of  NOAA-%Y-%m.txt.tmpl*
> The older version used this statement to determine if there was data for
> each day
> #for $day in $month.days
> #if $day.barometer.count.raw
> So it fails because there is no  $day.barometer.count.raw
> Your Monthly Report will look like this:
>
>MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>
>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>
>  HEAT   COOL AVG
>   MEAN   DEGDEG  WIND
>   DOM
> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   HIGH
>   TIMEDIR
> 
> ---
>  01
>  02
>  03
>  04
>  05
>  06
>  07
>  08
>  09
>  10
>  11
>  12
>  13
>  14
>  15
>  16
>  17
>  18
>  19
>  20
>  21
>  22
>  23
>  24
>  25
>  26
>  27
>  28
>  29
>  30
>  31
> 
> ---
>   55.4   81.3 31   44.4 12  294.20.7   0.150.4   14.0
> 29302
>
> *Newer version of NOAA-%Y-%m.txt.tmp*
> Changed how it determines if there was data for each day
> #for $day in $month.days
> #if $day.outTemp.has_data or $day.rain.has_data or $day.wind.has_data
> So it will pass even if there is no  $day.barometer.count.raw
> Your Monthly Report will now look like this:
>
>  MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>
>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>
>  HEAT   COOL AVG
>   MEAN   DEGDEG  WIND
>   DOM
> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   HIGH
>   TIMEDIR
>
> ---
>  01   55.7   63.8  10:55   47.4  03:409.30.0   0.000.39.0
>  08:00294
>  02   55.9   64.1  06:30   51.5  03:109.10.0   0.000.34.0
>  05:45322
>  03   62.5   72.2  16:55   52.5  23:152.50.0   0.000.66.0
>  14:50301
>  04   57.3   71.7  16:55   48.7  07:207.70.0   0.000.46.0
>  13:30297
>  05   56.9   70.0  16:45   47.8  10:158.10.0   0.000.46.0
>  16:50302
>  06   64.5   80.7  16:20   53.1  10:250.50.0   0.000.26.0
>  14:50297
>  07   60.8   79.3  15:40   50.5  00:404.20.0   0.000.37.0
>  15:55299
>  08   51.9   62.5  15:05   47.1  08:30   13.10.0   0.000.59.0
>  15:30317
>  09   50.9   60.8  14:20   46.6  01:25   14.10.0   0.000.6   11.0
>  15:35301
>  10   51.6   64.1  16:30   44.9  09:35   13.40.0   0.010.57.0
>  15:50294
>  11   51.0   60.6  15:20   45.0  07:25   14.00.0   0.000.7   13.0
>  15:25325
>  12   51.2   62.5  15:10   44.4  09:15   13.80.0   0.000.5   10.0
>  16:25298
>  13   51.2   59.8  17:45   46.3  08:50   13.80.0   0.000.58.0
>  17:30300
>  14   50.4   60.5  16:35   45.2  10:00   14.60.0   0.010.49.0
>  17:00294
>  15   51.1   65.1  16:00   44.4  09:40   13.90.0   0.000.48.0
>  17:25296
>  16   50.3   58.4  15:20   45.4  10:00   14.70.0   0.050.8   11.0
>  01:25315
>  17   51.2   60.1  16:55   45.5  10:20   13.80.0   0.050.6   12.0
>  03:40316
>  18   56.1   69.6  17:30   46.9  06:108.90.0   0.000.26.0
>  16:10294
>  19   58.6   76.1  14:50   49.0  10:056.40.0   0.000.29.0
>  15:10300
>  20   54.9   59.3  15:45   52.4  04:50   10.10.0   0.000.3   11.0
>  15:50306
>  21   52.0   56.8  14:20   47.7  02:15   13.00.0   0.030.37.0
>  14:35310
>  22   52.6   61.1  14:25   47.6  04:35   12.40.0   0.000.58.0
>  16:25296
>  23   59.9   73.0  16:20   50.0  07:205.10.0   0.000.47.0
>  15:40306
>  24   59.0   74.2  16:55   51.0  02:056.00.0   0.000.35.0
>  13:05297
>  25   54.9   69.8  17:10   46.9  08:45   10.10.0   0.000.37.0
>  14:20296
>  26   51.2   57.1  17:10   47.4  00:45   13.80.0   0.000.17.0
>  17:10299
>  27   55.4   70.4  16:55   45.7  08:259.60.0   0.000.38.0
>  17:15284
>  28   58.9   73.9  17:15   50.9  08:156.10.0   0.000.67.0
>  15:15296
>  29   58.9   71.3  18:15   45.7  

[weewx-user] Re: WeeWX 5 on a Mac

2024-01-19 Thread vince
see 
if 
https://github.com/weewx/weewx/wiki/WeeWX-Frequently-Asked-Questions#why-do-i-get-command-not-found-when-i-type-weewx-commands
 
helps any

On Friday, January 19, 2024 at 12:09:23 PM UTC-8 John Jacklin wrote:

> Many thanks for your help 
>
> I have install WeeWx and it seems to be running Ok
>
> However if I open a terminal and type
> weectrl  extension --help
>
> I get 
> zsh: command not found weectl
> On Friday 19 January 2024 at 14:36:54 UTC michael.k...@gmx.at wrote:
>
>> The Ecowitt Gateway Driver ist just "yet another extension" and installed 
>> like any other. Simply refer to the documentation. 
>> https://weewx.com/docs/5.0/utilities/weectl-extension/ 
>> I don't know the SFTP driver, but I am pretty sure this also applies for 
>> installing the SFTP driver.
>> John Jacklin schrieb am Freitag, 19. Januar 2024 um 15:12:52 UTC+1:
>>
>>> I would like to have another go at setting up WeeWX on a Mac (running 
>>> Ventura)
>>>
>>> I have read how to install WeeWX on using the instruction in the 
>>> documentation and this seems straightforward .
>>>
>>> I would need to install the SFTP drivers and the Ecowitt Gateway Drivers 
>>> and I am not sure how to go about this with WeeWX 5
>>>
>>> Many 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/162d40e5-511a-451b-bebb-d89fced0cf5cn%40googlegroups.com.


[weewx-user] Re: WeeWX 5 on a Mac

2024-01-19 Thread John Jacklin
Many thanks for your help 

I have install WeeWx and it seems to be running Ok

However if I open a terminal and type
weectrl  extension --help

I get 
zsh: command not found weectl
On Friday 19 January 2024 at 14:36:54 UTC michael.k...@gmx.at wrote:

> The Ecowitt Gateway Driver ist just "yet another extension" and installed 
> like any other. Simply refer to the documentation. 
> https://weewx.com/docs/5.0/utilities/weectl-extension/ 
> I don't know the SFTP driver, but I am pretty sure this also applies for 
> installing the SFTP driver.
> John Jacklin schrieb am Freitag, 19. Januar 2024 um 15:12:52 UTC+1:
>
>> I would like to have another go at setting up WeeWX on a Mac (running 
>> Ventura)
>>
>> I have read how to install WeeWX on using the instruction in the 
>> documentation and this seems straightforward .
>>
>> I would need to install the SFTP drivers and the Ecowitt Gateway Drivers 
>> and I am not sure how to go about this with WeeWX 5
>>
>> Many 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/c7e3a5bb-8dab-4fc5-9d40-ba9fabe7e1efn%40googlegroups.com.


Re: [weewx-user] Slow Report Generation after Upgrade from 4.10.2 to 5..0

2024-01-19 Thread vince
Just a quick followup re: how long it takes to reconfigure things to the 
new default extended schema using Blaine's db as a test...

Rather than grow old(er) trying it on a pi3+ again, I threw compute on it 
and did the updates in a vagrant/Parallels vm on a m1 mac mini.

weectl station reconfigure
(answer y - takes 35 secs to do this step)

mv weewx.sdb weewx.sdb.keepme
mv weewx.sdb_new weewx.sdb

weectl database rebuild-daily
(answer y - takes 88 secs to do this step)

And done.  About 3 minutes end to end on a m1 mac mini.  Pretty cool.
Initial startup and subsequent report runs were blazing fast and 
Belchertown worked fine.
You gotta love throwing compute at problems

Geez these are fast.  Initial creation of a zillion NOAA files in just a 
few seconds.
Next runs in a fraction of a second.  Wow the m1 chip is fast.

2024-01-19T10:50:15.235599-08:00 deb12pip weewxd[3084]: INFO weewx.manager: 
Added record 2024-01-19 10:50:00 PST (1705690200) to database 'weewx.sdb'
2024-01-19T10:50:15.246551-08:00 deb12pip weewxd[3084]: INFO weewx.manager: 
Added record 2024-01-19 10:50:00 PST (1705690200) to daily summary in 
'weewx.sdb'
2024-01-19T10:50:18.956902-08:00 deb12pip weewxd[3084]: INFO 
weewx.cheetahgenerator: Generated 128 files for report SeasonsReport in 
3.67 seconds
2024-01-19T10:50:19.630892-08:00 deb12pip weewxd[3084]: INFO 
weewx.imagegenerator: Generated 60 images for report SeasonsReport in 0.67 
seconds
2024-01-19T10:50:19.631922-08:00 deb12pip weewxd[3084]: INFO 
weewx.reportengine: Copied 5 files to /home/vagrant/weewx-data/public_html
2024-01-19T10:50:19.636177-08:00 deb12pip weewxd[3084]: INFO 
user.belchertown: version 1.3.1
2024-01-19T10:50:25.326411-08:00 deb12pip weewxd[3084]: INFO 
weewx.cheetahgenerator: Generated 132 files for report Belchertown in 5.69 
seconds
2024-01-19T10:50:25.329042-08:00 deb12pip weewxd[3084]: INFO 
weewx.reportengine: Copied 40 files to 
/home/vagrant/weewx-data/public_html/belchertown

2024-01-19T10:55:15.234969-08:00 deb12pip weewxd[3084]: INFO weewx.manager: 
Added record 2024-01-19 10:55:00 PST (1705690500) to database 'weewx.sdb'
2024-01-19T10:55:15.244564-08:00 deb12pip weewxd[3084]: INFO weewx.manager: 
Added record 2024-01-19 10:55:00 PST (1705690500) to daily summary in 
'weewx.sdb'
2024-01-19T10:55:15.412840-08:00 deb12pip weewxd[3084]: INFO 
weewx.cheetahgenerator: Generated 8 files for report SeasonsReport in 0.15 
seconds
2024-01-19T10:55:15.507428-08:00 deb12pip weewxd[3084]: INFO 
weewx.imagegenerator: Generated 15 images for report SeasonsReport in 0.09 
seconds
2024-01-19T10:55:15.507714-08:00 deb12pip weewxd[3084]: INFO 
weewx.reportengine: Copied 0 files to /home/vagrant/weewx-data/public_html
2024-01-19T10:55:15.794254-08:00 deb12pip weewxd[3084]: INFO 
weewx.cheetahgenerator: Generated 12 files for report Belchertown in 0.28 
seconds
2024-01-19T10:55:15.794966-08:00 deb12pip weewxd[3084]: INFO 
weewx.reportengine: Copied 3 files to 
/home/vagrant/weewx-data/public_html/belchertown

On Thursday, January 18, 2024 at 11:32:51 PM UTC-8 vince wrote:

> Followup on this one - If the original poster can check to see if their 
> database uses the old original (small) wview schema that would likely help. 
>  Easiest way is to look to see how many elements are in the database. One 
> way to see how many elements you have in your db would be:
>
>- cp weewx.sdb /var/tmp/test.sdb
>- echo "select count(*) from pragma_table_info('archive');" | sqlite3 
>/var/tmp/test.sdb
>   - (my db with the extended schema returns "114" as the count)
>   - (a db with the original wview schema returns "52" as the count)
>
>
> Switching to the extended schema is a bit of work and takes some time. 
>  The details are documented at 
> http://www.weewx.com/docs/5.0/custom/database/ with the procedure for how 
> to switch to the new bigger schema in 
> http://www.weewx.com/docs/5.0/custom/database/#reconfigure-using-new-schema 
> - but be CAREFUL doing this and ALWAYS work off a copy of your db so if 
> anything happens you can revert to a known good db.   I've done it so many 
> years ago at this point that I'll have to defer to others for pitfalls and 
> how they do it, but the links above are how the current docs recommend 
> doing so.
>
> Short description to the original Belchertown problem reporters - check 
> your db schema.  Hopefully that's the pattern of which systems will need to 
> take action.
>
>
>

-- 
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/606145b5-d890-4ff5-9006-4d6bf6cd355an%40googlegroups.com.


[weewx-user] Rain Rate error

2024-01-19 Thread Luis
Hi all,
I have errors for rain rate showing illogical values:
I also have problems with the battery and there are a couple of hours 
before dawn with no data transmission.
[image: rainrate_error.png]
The rain rate value shown here must be the product of some zero division.
Any ideas?
I would be happy if someone points me to the place of code where this value 
is computed for adding a control to avoid this absurd value.
Any ideas?
Thanks so much
Luis Rosety

-- 
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/f6283484-f8e4-4ac1-aaa4-38097def1772n%40googlegroups.com.


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

2024-01-19 Thread 'michael.k...@gmx.at' via weewx-user
Next time I won't wait until the weekend! Great job!

Paul R Anderson schrieb am Freitag, 19. Januar 2024 um 19:23:48 UTC+1:

> This was really fun to track down! Thanks for the challenge !
> I have been able to reproduce your issue... it's a  little complicated, 
> but it can be fixed  easily :)
> It's caused by 2 factors
> *1. Your station seems to have stopped reporting Barometric Pressure on or 
> about 2019-12-31 @ 16:45 *
> *No idea why, hopefully you are aware of this and know the cause.*
>
> *2. Your using an older version of  NOAA-%Y-%m.txt.tmpl*
> The older version used this statement to determine if there was data for 
> each day
> #for $day in $month.days
> #if $day.barometer.count.raw
> So it fails because there is no  $day.barometer.count.raw
> Your Monthly Report will look like this:
>
>MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>
>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>
>  HEAT   COOL AVG
>   MEAN   DEGDEG  WIND 
>   DOM
> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   HIGH 
>   TIMEDIR
> 
> ---
>  01
>  02
>  03
>  04
>  05
>  06
>  07
>  08
>  09
>  10
>  11
>  12
>  13
>  14
>  15
>  16
>  17
>  18
>  19
>  20
>  21
>  22
>  23
>  24
>  25
>  26
>  27
>  28
>  29
>  30
>  31
> 
> ---
>   55.4   81.3 31   44.4 12  294.20.7   0.150.4   14.0 
> 29302
>
> *Newer version of NOAA-%Y-%m.txt.tmp*
> Changed how it determines if there was data for each day
> #for $day in $month.days
> #if $day.outTemp.has_data or $day.rain.has_data or $day.wind.has_data
> So it will pass even if there is no  $day.barometer.count.raw
> Your Monthly Report will now look like this:
>  
>  MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020
>
>TEMPERATURE (F), RAIN (in), WIND SPEED (mph)
>
>  HEAT   COOL AVG
>   MEAN   DEGDEG  WIND 
>   DOM
> DAY   TEMP   HIGH   TIMELOW   TIME   DAYS   DAYS   RAIN  SPEED   HIGH 
>   TIMEDIR
>
> ---
>  01   55.7   63.8  10:55   47.4  03:409.30.0   0.000.39.0 
>  08:00294
>  02   55.9   64.1  06:30   51.5  03:109.10.0   0.000.34.0 
>  05:45322
>  03   62.5   72.2  16:55   52.5  23:152.50.0   0.000.66.0 
>  14:50301
>  04   57.3   71.7  16:55   48.7  07:207.70.0   0.000.46.0 
>  13:30297
>  05   56.9   70.0  16:45   47.8  10:158.10.0   0.000.46.0 
>  16:50302
>  06   64.5   80.7  16:20   53.1  10:250.50.0   0.000.26.0 
>  14:50297
>  07   60.8   79.3  15:40   50.5  00:404.20.0   0.000.37.0 
>  15:55299
>  08   51.9   62.5  15:05   47.1  08:30   13.10.0   0.000.59.0 
>  15:30317
>  09   50.9   60.8  14:20   46.6  01:25   14.10.0   0.000.6   11.0 
>  15:35301
>  10   51.6   64.1  16:30   44.9  09:35   13.40.0   0.010.57.0 
>  15:50294
>  11   51.0   60.6  15:20   45.0  07:25   14.00.0   0.000.7   13.0 
>  15:25325
>  12   51.2   62.5  15:10   44.4  09:15   13.80.0   0.000.5   10.0 
>  16:25298
>  13   51.2   59.8  17:45   46.3  08:50   13.80.0   0.000.58.0 
>  17:30300
>  14   50.4   60.5  16:35   45.2  10:00   14.60.0   0.010.49.0 
>  17:00294
>  15   51.1   65.1  16:00   44.4  09:40   13.90.0   0.000.48.0 
>  17:25296
>  16   50.3   58.4  15:20   45.4  10:00   14.70.0   0.050.8   11.0 
>  01:25315
>  17   51.2   60.1  16:55   45.5  10:20   13.80.0   0.050.6   12.0 
>  03:40316
>  18   56.1   69.6  17:30   46.9  06:108.90.0   0.000.26.0 
>  16:10294
>  19   58.6   76.1  14:50   49.0  10:056.40.0   0.000.29.0 
>  15:10300
>  20   54.9   59.3  15:45   52.4  04:50   10.10.0   0.000.3   11.0 
>  15:50306
>  21   52.0   56.8  14:20   47.7  02:15   13.00.0   0.030.37.0 
>  14:35310
>  22   52.6   61.1  14:25   47.6  04:35   12.40.0   0.000.58.0 
>  16:25296
>  23   59.9   73.0  16:20   50.0  07:205.10.0   0.000.47.0 
>  15:40306
>  24   59.0   74.2  16:55   51.0  02:056.00.0   0.000.35.0 
>  13:05297
>  25   54.9   69.8  17:10   46.9  08:45   10.10.0   0.000.37.0 
>  14:20296
>  26   51.2   57.1  17:10   47.4  00:45   13.80.0   0.000.17.0 
>  17:10299
>  27   55.4   70.4  16:55   45.7  08:259.60.0   0.000.38.0 
>  17:15284
>  28   58.9   73.9  17:15   

[weewx-user] Re: import data into Weewx 5.0 error

2024-01-19 Thread bhouseski
yes, this worked (only tried part one).  Thank-you.

On Thursday, January 18, 2024 at 7:54:31 p.m. UTC-5 gjr80 wrote:

> This problem is due to small bug in our version comparison. This will be 
> fixed in the next release. If you wish to use weectl import before the 
> next release you have a couple of options:
>
> 1. you can download a file containing the fix for this problem and replace 
> your v5.0.0 version of this file. To do this:
>
> - download the patched file using:
>
>   wget -P /var/tmp 
> https://raw.githubusercontent.com/weewx/weewx/master/src/weectllib/import_actions.py
>
> - locate your installed v5.0.0 version of import_actions.py, it will be 
> in the weectllib directory, but where that is depends on your WeeWX 
> install type. Where to find things 
>  in the User's Guide will 
> help. For a package install it should be in /usr/share/weewx/. For a pip 
> install it could be in any one of a number of locations, refer to Location 
> of executables in a pip install 
> 
>  
> for help. For a pip/git install it will be in the src directory of the 
> directory in which you cloned the WeeWX repo.
>
> - once located replace your existing import_actions.py with the 
> downloaded version:
>
>   cp /var/tmp/import_actions.py /usr/share/weewx/weectllib/
>
>  adjusting the destination directory to suit.
>
> - try the import again
>
> 2. you can apply the fix yourself to your installed import_actions.py. To 
> do this:
>
> - locate your installed import_actions.py using the second step above.
>
> - once found, open import_actions.py for editing, locate the following 
> line (circa line 26):
>
>   REQUIRED_WEEWX = "5.0.0b15"
>
>  and change it to read:
>
>   REQUIRED_WEEWX = "5.0.0"
>
> - save import_actions.py
>
> - try the import again
>
> Alternatively, you can wait and update to the next release (likely a bug 
> fix in the not too distant future) and perform your import then.
>
> Gary
> On Friday 19 January 2024 at 08:40:14 UTC+10 bhouseski wrote:
>
>> Hey all, I am trying to get old weatherlink data into my Weewx 5.0 setup. 
>>  the I run the appropriate command:
>>
>> 'weectl import --import-config=/var/tmp/csv.conf --dry-run'
>>
>>  I get the following:
>>
>> 'WeeWX 5.0.0b15 or greater is required, found 5.0.0. Nothing done, 
>> exiting.'
>>
>>
>> Not sure what this means.  isn't 5.0.0b15 a beta version?  I updated to 
>> the latest version when I did a general update on my RPi 4.
>>
>>
>> Mike
>>
>

-- 
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/fed7885e-f940-4cc4-abe2-096c52de10bfn%40googlegroups.com.


Re: [weewx-user] Weewx and Meteobridge - website update

2024-01-19 Thread bhouseski
yes, this is what I needed.  Thank-you.

On Sunday, January 7, 2024 at 2:18:29 p.m. UTC-5 John Smith wrote:

> You need to add a meta refresh to the top of the template
>
> 
>
>
> On Mon, 8 Jan 2024 at 05:36, bhouseski  wrote:
>
>> Recently I was able to get Weewx running on a Raspberry Pi 4B, pulling 
>> data from a Vantage Pro2 connected to a D-Link DIR-505 loaded with 
>> Meteobridge (vantage is connected to the Meteobridge via USB).  All is well 
>> except I cannot get the website to autoload new data (I have to keep 
>> hitting refresh on my web browser).  I have played around with the archive 
>> interval, but have had no success.
>>
>> any idea's how to make this work?
>>
>> -- 
>> 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/599d5fa4-74f4-4cdb-93ac-9882021c2c91n%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/2688da54-cedf-4a8a-9602-d6dba9360925n%40googlegroups.com.


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

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

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

   MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020

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

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

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

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

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

 MONTHLY CLIMATOLOGICAL SUMMARY for Jan 2020

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

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

[weewx-user] Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

2024-01-19 Thread 'michael.k...@gmx.at' via weewx-user
Yes, it's possible. 
2024-01-19 18:27:35 weewxd[5855] DEBUG user.gw1000: Next update in 9 seconds
2024-01-19 18:27:35 weewxd[5855] DEBUG user.gw1000: Next update in 9 seconds
LOOP:   2024-01-19 18:27:35 CET (1705685255) 'altimeter': 
'1023.2565915245989', 'appTemp': '-4.6378894597484965', 'barometer': 
'1026.3446847507096', 'cloudbase': '972.4294835518078', 'dateTime': 
'1705685255', 'daymaxwind': '2.1', 'dayRain': '4.7', 'dewpoint': 
'-6.267050581532717', 'ET': 'None', 'extraHumid6': '62', 'extraHumid7': 
'61', 'extraHumid8': '58', 'extraTemp6': '14.8', 'extraTemp7': '19.9', 
'extraTemp8': '20.6', 'heatindex': '-1.9008', 'humidex': 
'-1.9', 'inDewpoint': '12.462345522375951', 'inHumidity': '60', 'inTemp': 
'20.5', 'lightning_distance': 'None', 'lightning_last_det_time': 
'1705345360', 'lightning_strike_count': '0', 'lightningcount': '0', 
'luminosity': '0.0', 'maxSolarRad': '0.0', 'monthRain': '50.4', 
'outHumidity': '72', 'outTemp': '-1.9', 'p_dayRain': '0.0', 'p_monthRain': 
'26.5', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '0.0', 
'p_weekRain': '11.8', 'p_yearRain': '26.5', 'pressure': '971.0', 
'radiation': '0.0', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': 
'1023.8', 'stormRain': '0.0', 'usUnits': '17', 'UV': '0', 'uvradiation': 
'0.0', 'weekRain': '15.2', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 
'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 
'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': 
'1.45', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windchill': 
'-1.9008', 'windDir': 'None', 'windGust': '1.3', 'windrun': 
'None', 'windSpeed': '0.0', 'ws90_batt': '3.28', 'ws90_sig': '4', 
'yearRain': '50.4'

But why would anybody want to do this? I have two GW2000 devices and want 
to store and show data of as many of my sensor possible in a single weewx 
instance. Yet configuring the driver both, as driver and a service at the 
same time, seems to work as I hoped at least foor LOOP: two device queries, 
on LOOP data.

The question now: is it possible to configure the driver/service in a way, 
they uses their own ip_address and is it possible to map the Wind/Dir/Gust 
of the WS90 bound to the one GW2000, to e.g. 
us_windSpeed/us_windDir/us_windGust (us for ultrasonic) just like p_rain 
for the haptic array?

Or isn't this possible and do I have to combine the Interceptor driver with 
the Ecowitt Gateway Driver, one as a service, the other as a Driver to 
achieve this? If yes, how could this be possible, I tried it with 
Interceptor as a driver and Ecowitt Gateway Driver as a Service and get not 
device data:
2024-01-19 18:46:59 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:07 weewxd[13771] DEBUG user.gw1000: Next update in 9 
seconds
2024-01-19 18:47:09 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:16 weewxd[13771] DEBUG user.gw1000: Next update in 9 
seconds
2024-01-19 18:47:19 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:25 weewxd[13771] DEBUG user.gw1000: Next update in 9 
seconds
2024-01-19 18:47:29 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:34 weewxd[13771] DEBUG user.gw1000: Next update in 9 
seconds
2024-01-19 18:47:39 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:43 weewxd[13771] DEBUG user.gw1000: Next update in 9 
seconds
2024-01-19 18:47:49 weewxd[13771] DEBUG user.interceptor: empty queue


-- 
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/0417240b-fb99-477a-b599-98fdb5969357n%40googlegroups.com.


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

2024-01-19 Thread Michael Sanphillipo
Richard, just curious do you have an Acurite weather station and using 
Belcherstown? I'm just trying to see if we have the same type of setup 
before going back to V5 and trying your solution. Thanks!

On Friday, January 19, 2024 at 5:49:18 AM UTC-5 Richard Whitcombe wrote:

> FWIW i just needed to add appTemp and its worked - report generation now 
> takes 3 seconds not 190.
> I would caveat that by saying im not using the other missing columns at 
> all as my station doesnt provide the data so maybe if you are they need to 
> be added too.
> Missing data calculations took about 8 mins for 2017 - 2024 on a Pi4.
>
> On Friday 19 January 2024 at 15:59:15 UTC+9 vince wrote:
>
>> Re: the Belchertown issue many seem to be facing, I notice that Blaine's 
>> db uses the original old wview schema, not the newer bigger 
>> 'wview_extended' schema that came out a few years ago.  I suspect this is 
>> the pattern we've missed.  Folks who have the old schema do not have any of 
>> the elements for many of the Extended Observations in Belchertown's 
>> skin.conf file. 
>>
>> Blaine's db schema misses these items in Belchertown's skin.conf extended 
>> observations list
>> appTemp  = Apparent Temperature
>> cloudbase= Cloud Base
>> visibility   = Visibility
>> windrun  = Wind Run
>> cloud_cover  = Cloud Cover
>> aqi  = AQI
>>
>> The wview_extended schema is missing these, so I'd expect users with data 
>> in those somehow might have the same slowness issue until they add db 
>> elements and calc-missing to generate summary tables for them.
>> visibility   = Visibility
>> cloud_cover  = Cloud Cover
>>
>> Re: Michael's question about what to do about the NOAA files, I'd suggest 
>> pre-calculating them offline and dropping them into place in his NOAA 
>> subdirectory with the appropriate owner/group/mode so they don't have to be 
>> recalculated.  I'd omit the current month+year which should regenerate 
>> quickly on weewx startup.  That would be a good thing to try.  We've 
>> verified the db is ok, so it 'should' work on Blaine's system too 
>> (hopefully).  The test then would be to simply look at the date+time last 
>> modified for the current month and year NOAA file.  It should change every 
>> archive period as StdReport runs.
>>
>> (reminder - if you have Belchertown 'and' Seasons, you need to drop the 
>> pre-calculated NOAA files into both places to preseed both skin output 
>> directories)
>>
>> On Thursday, January 18, 2024 at 8:36:20 PM UTC-8 michael.k...@gmx.at 
>> wrote:
>>
>>> Or, to speed things up, do the "calc-missing" on another machine with a 
>>> more potent CPU.
>>>
>>> Back to Blaine's problem: if the NOAA files are generated on other 
>>> installations with his database, there is obviously another problem with 
>>> his installation.I don't have an idea what to look for, if deleted NOAA 
>>> data will be regenerated in the same way, as before.
>>>
>>> vince schrieb am Freitag, 19. Januar 2024 um 04:55:13 UTC+1:
>>>
 Docs are at https://www.weewx.com/docs/5.0/utilities/weectl-database/ 
 but what I did for a pip installation using Blaine's db was:

 source ~/weewx-venv/bin/activate
 weectl database add-column appTemp
 weectl calc-missing
 (answer y when prompted above)

 If you have a packaged install of weewx you can skip the activate step 
 above.

 Note - the calc-missing takes quite a while and will peg your cpu while 
 working, so if you have a lot of data so you might need to use the --from 
 and --to options or even the --tranche option to split up the processing a 
 bit into pieces.  I got lucky with this db on pi3plus with a bit of 
 patience waiting for calc-missing to complete

 (weewx-venv) pi@pi3plus:~/weewx-data $ weectl database calc-missing -y
 Using configuration file /home/pi/weewx-data/weewx.conf
 Missing derived observations will be calculated for all records.
 Calculating missing derived observations...
 Processing record: 959536; Last record: 2024-01-19 00:00:00 PST 
 (1705651200)
 Recalculating daily summaries...
 Records processed: 959000; time: 2024-01-16 15:55:00 PST (1705449300)
 Finished recalculating daily summaries
 Missing derived observations calculated in 2986.21 seconds

 And after restarting weewx things look good 

 2024-01-18T19:45:15.438555-08:00 pi3plus weewxd[1797]: INFO 
 weewx.manager: Added record 2024-01-18 19:45:00 PST (1705635900) to 
 database 'weewx.sdb'
 2024-01-18T19:45:15.458841-08:00 pi3plus weewxd[1797]: INFO 
 weewx.manager: Added record 2024-01-18 19:45:00 PST (1705635900) to daily 
 summary in 'weewx.sdb'
 2024-01-18T19:45:19.659002-08:00 pi3plus weewxd[1797]: INFO 
 weewx.cheetahgenerator: Generated 8 files for report 

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

2024-01-19 Thread 'michael.k...@gmx.at' via weewx-user
Good news: let the provided tools do the job, no need to touch that nasty 
thing with your own hands :D :D :D Maybe Tom can add an alias for 
"database" when "weectl database" is called ;) Or I might create an PR for 
this :D

WindnFog schrieb am Freitag, 19. Januar 2024 um 16:47:39 UTC+1:

> No need to be gentle, Tom.  My approach was probably the most complicated 
> (worst?) solution possible.  Without going into detail, when I was working, 
> I messed up a mission-critical Oracle database by trying to change 
> something I didn't understand. I can program fairly well, but I'm still 
> paranoid about databases!  So, I need to get my head around adding fields 
> to the weeWX database and not devise these complex ways to avoid touching 
> it.  :-)
>
> On Friday, January 19, 2024 at 10:55:50 AM UTC-4 Tom Keffer wrote:
>
>> I mean this in the gentlest way, but this is basically what the SQLite 
>> database is doing for you: saving various values in a file where they can 
>> be retrieved via a general query statement.
>>
>> On Fri, Jan 19, 2024 at 6:16 AM WindnFog  wrote:
>>
>>> I encountered the same problem trying to calculate the all time humidex 
>>> in the index.html.tmpl template.  This was taking about 3 minutes on a Pi 
>>> 4. Rather than add humidex to the database (probably the best solution), I 
>>> calculated all-time humidex once a day using a small program and invoking 
>>> it with cron. I saved it in a text file that I could then use the Cheetah 
>>> include statement to read it into index.the html.tmpl template.  This runs 
>>> in 2 seconds on a Pi 4 and 1 second on a pi 5; if you have an algorithm for 
>>> appTemp, a similar approach might work.  I was not comfortable with 
>>> modifying the database because that's not my area of expertise:
>>>
>>> #!/usr/bin/env python3
>>> # -*- coding: utf-8 -*-
>>>
>>> """
>>> Program:WeeWX Humidex calculator
>>> Author: Paul M Dunphy
>>> Date:   12 December 2023
>>> Version:1.0.0
>>> Description:This script sweeps through the Weewx database and 
>>> calculates the 
>>> derived parameter humidex for each record.  It then 
>>> returns the
>>> maximum humidex and the date/time when it occured.  This 
>>> takes
>>> about 1.5 seconds on a 900,000 record database as 
>>> opposed to 3.5
>>> minutes by the WeeWX system if the recommended aggregate 
>>> values
>>> are implemented in the Standard/index.html.tmpl file:
>>> 
>>> $alltime.humidex.max ($alltime.humidex.max.degree_F) 
>>> $alltime.humidex.maxtime.format($ALLTIMEFMT)
>>>
>>> It's not clear why the weeWX system takes so long.  
>>> Possibly
>>> because it's doing many other things at the same time.  
>>>
>>> This runs on a Raspberry Pi 4B (4 GB Ram) using Debian 12
>>> """
>>>
>>> # Required Libraries
>>>
>>> import sqlite3
>>> import math
>>> from datetime import datetime
>>> import pytz
>>> from pytz import timezone
>>>
>>>
>>> def calculate_humidex(temperature, dewpoint):
>>> # Constants for the formula
>>> k = 273.15  # Conversion factor for Celsius to Kelvin
>>>
>>> # Convert temperatures to Kelvin
>>> temperature + k
>>> dewpoint_k = dewpoint + k
>>>
>>> # Calculate vapor pressure in hPa
>>> vapor_pressure = 6.112 * math.exp(5417.7530 * ((1 / 273.16) - (1 / 
>>> dewpoint_k)))
>>>
>>> # Humidex calculation
>>> humidex = temperature + ((vapor_pressure - 10) * 0.)
>>> return humidex
>>>
>>>
>>> def get_max_humidex(database_path):
>>> # Connect to the WeeWX database
>>> conn = sqlite3.connect(database_path)
>>> cursor = conn.cursor()
>>>
>>> # Query for temperature, dewpoint, and dateTime for all records
>>> query = "SELECT outTemp, dewpoint, dateTime FROM archive"
>>> cursor.execute(query)
>>>
>>> # Variables to track the maximum humidex and its date
>>> maximum_humidex = None
>>> maximum_humidex_date = None
>>>
>>> for row in cursor:
>>> temperature, dewpoint, date_time = row
>>> if temperature is not None and dewpoint is not None:
>>> humidex = calculate_humidex(temperature, dewpoint)
>>> if maximum_humidex is None or humidex > maximum_humidex:
>>> maximum_humidex = humidex
>>> maximum_humidex_date = date_time
>>>
>>> conn.close()
>>> return maximum_humidex, maximum_humidex_date
>>>
>>>
>>> def convert_utc_to_ast_adt(utc_datetime):
>>> """
>>> Convert a UTC datetime to AST or ADT depending on the date.
>>>
>>> Parameters:
>>> utc_datetime (datetime): UTC datetime object.
>>>
>>> Returns:
>>> datetime: Datetime object in AST or ADT.
>>> """
>>> # Define the time zone for AST/ADT
>>> ast_tz = timezone('America/Halifax')
>>>
>>> # Localize the UTC datetime to the AST/ADT timezone
>>> 

Re: [weewx-user] ftpupload suddenly stopped working, but....

2024-01-19 Thread Tom Hogland
I can answer this as I went though something similar. Weewx supports FTPS 
natively, not SFTP. However, there's a SFTP extension you can load that 
will work correctly. If they use FTPS then what you described is correct - 
change secure_ftp to true and it'll work. If they use SFTP then you can 
load the extension and use a similar stanza in the config file to enable 
it. 

On Thursday, January 18, 2024 at 11:23:49 AM UTC-9 Steve2Q wrote:

> Tom. I finally got a support tech who was able to solve the problem. 
> Apparently Dreamhost has made some OS changes which can cause problems with 
> FTP. I would like to change to SFTP,  but I am not sure  how to go about 
> it. The options you referred to do not exist in my weewx.conf file, and I 
> really don't want to upgrade as I don't want to break the Steel Gauges 
> which took me a LONG time to get operating properly. Is there a guide to 
> changing over to SFTP for a "legacy" version of Weewx. Is it as simple as 
> changing secure_ftp to True, and port to 22?
>
> The following is the {FTP} section of my weewx.conf file:
>  [[FTP]]
> # FTP'ing the results to a webserver is treated as just another 
> report,
> # albeit one with an unusual report generator!
> skin = Ftp
> 
> # If you wish to use FTP, uncomment and fill out the next four 
> lines.
> # Use quotes around passwords to guard against parsing errors.
> server = www.xxx
> path = xxx/yyy
> user = aaa
> password = bbb
> 
> # Set to True for an FTP over TLS (FTPS) connection. Not all 
> servers
> # support this.
> secure_ftp = False
> 
> # To upload files from something other than what HTML_ROOT is set
> # to above, specify a different HTML_ROOT here.
> #HTML_ROOT = public_html
> 
> # Most FTP servers use port 21
> port = 21
> 
> # Set to 1 to use passive mode, zero for active mode
> passive = 0
>
> Thanks, Steve
>
>

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


[weewx-user] Davis Vantage Pro2 - Weather Wing WS-2

2024-01-19 Thread Massimiliano Buldrini
I have a Weather Wing WS-2 connected to a Davis Vantage Pro2.
My console is connected with the serial data logger.
I want to connect my console to weewx with raspberry. Do I have to connect 
it with a USB/serial adapter to my raspberry or can I use Weather Wing WS-2 
which has an ethernet port?

Regards
MB

-- 
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/1100f0ce-a3ec-4899-971d-fa9b75a80bf7n%40googlegroups.com.


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

2024-01-19 Thread WindnFog
No need to be gentle, Tom.  My approach was probably the most complicated 
(worst?) solution possible.  Without going into detail, when I was working, 
I messed up a mission-critical Oracle database by trying to change 
something I didn't understand. I can program fairly well, but I'm still 
paranoid about databases!  So, I need to get my head around adding fields 
to the weeWX database and not devise these complex ways to avoid touching 
it.  :-)

On Friday, January 19, 2024 at 10:55:50 AM UTC-4 Tom Keffer wrote:

> I mean this in the gentlest way, but this is basically what the SQLite 
> database is doing for you: saving various values in a file where they can 
> be retrieved via a general query statement.
>
> On Fri, Jan 19, 2024 at 6:16 AM WindnFog  wrote:
>
>> I encountered the same problem trying to calculate the all time humidex 
>> in the index.html.tmpl template.  This was taking about 3 minutes on a Pi 
>> 4. Rather than add humidex to the database (probably the best solution), I 
>> calculated all-time humidex once a day using a small program and invoking 
>> it with cron. I saved it in a text file that I could then use the Cheetah 
>> include statement to read it into index.the html.tmpl template.  This runs 
>> in 2 seconds on a Pi 4 and 1 second on a pi 5; if you have an algorithm for 
>> appTemp, a similar approach might work.  I was not comfortable with 
>> modifying the database because that's not my area of expertise:
>>
>> #!/usr/bin/env python3
>> # -*- coding: utf-8 -*-
>>
>> """
>> Program:WeeWX Humidex calculator
>> Author: Paul M Dunphy
>> Date:   12 December 2023
>> Version:1.0.0
>> Description:This script sweeps through the Weewx database and 
>> calculates the 
>> derived parameter humidex for each record.  It then 
>> returns the
>> maximum humidex and the date/time when it occured.  This 
>> takes
>> about 1.5 seconds on a 900,000 record database as opposed 
>> to 3.5
>> minutes by the WeeWX system if the recommended aggregate 
>> values
>> are implemented in the Standard/index.html.tmpl file:
>> 
>> $alltime.humidex.max ($alltime.humidex.max.degree_F) 
>> $alltime.humidex.maxtime.format($ALLTIMEFMT)
>>
>> It's not clear why the weeWX system takes so long.  
>> Possibly
>> because it's doing many other things at the same time.  
>>
>> This runs on a Raspberry Pi 4B (4 GB Ram) using Debian 12
>> """
>>
>> # Required Libraries
>>
>> import sqlite3
>> import math
>> from datetime import datetime
>> import pytz
>> from pytz import timezone
>>
>>
>> def calculate_humidex(temperature, dewpoint):
>> # Constants for the formula
>> k = 273.15  # Conversion factor for Celsius to Kelvin
>>
>> # Convert temperatures to Kelvin
>> temperature + k
>> dewpoint_k = dewpoint + k
>>
>> # Calculate vapor pressure in hPa
>> vapor_pressure = 6.112 * math.exp(5417.7530 * ((1 / 273.16) - (1 / 
>> dewpoint_k)))
>>
>> # Humidex calculation
>> humidex = temperature + ((vapor_pressure - 10) * 0.)
>> return humidex
>>
>>
>> def get_max_humidex(database_path):
>> # Connect to the WeeWX database
>> conn = sqlite3.connect(database_path)
>> cursor = conn.cursor()
>>
>> # Query for temperature, dewpoint, and dateTime for all records
>> query = "SELECT outTemp, dewpoint, dateTime FROM archive"
>> cursor.execute(query)
>>
>> # Variables to track the maximum humidex and its date
>> maximum_humidex = None
>> maximum_humidex_date = None
>>
>> for row in cursor:
>> temperature, dewpoint, date_time = row
>> if temperature is not None and dewpoint is not None:
>> humidex = calculate_humidex(temperature, dewpoint)
>> if maximum_humidex is None or humidex > maximum_humidex:
>> maximum_humidex = humidex
>> maximum_humidex_date = date_time
>>
>> conn.close()
>> return maximum_humidex, maximum_humidex_date
>>
>>
>> def convert_utc_to_ast_adt(utc_datetime):
>> """
>> Convert a UTC datetime to AST or ADT depending on the date.
>>
>> Parameters:
>> utc_datetime (datetime): UTC datetime object.
>>
>> Returns:
>> datetime: Datetime object in AST or ADT.
>> """
>> # Define the time zone for AST/ADT
>> ast_tz = timezone('America/Halifax')
>>
>> # Localize the UTC datetime to the AST/ADT timezone
>> local_datetime = ast_tz.normalize(utc_datetime.astimezone(ast_tz))
>>
>> return local_datetime
>>
>>
>> def format_date(unix_timestamp):
>> """
>> Format a UNIX timestamp into a human-readable string in AST or ADT.
>>
>> Parameters:
>> unix_timestamp (int): UNIX timestamp.
>>
>> Returns:
>> str: Formatted date string.
>> """
>> # Create a UTC datetime from the UNIX timestamp
>> 

Re: [weewx-user] Slow Report Generation after Upgrade from 4.10.2 to 5..0

2024-01-19 Thread 'Cameron D' via weewx-user


On Friday 19 January 2024 at 4:37:05 am UTC+10 vince wrote:


The pattern so far seems to be (a) Belchertown and (b) certain drivers that 
might not have complete measurement sets.   I see Acurite and Interceptor 
in a couple reports if I remember correctly.


 No, it is *any *skin that tries to plot the derived parameters - the 
common factor is if they are not in the DB. I reported the same with the 
default standard Seasons skin.

-- 
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/0283c3df-33c9-4318-93a0-123c411083a2n%40googlegroups.com.


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

2024-01-19 Thread Tom Keffer
I mean this in the gentlest way, but this is basically what the SQLite
database is doing for you: saving various values in a file where they can
be retrieved via a general query statement.

On Fri, Jan 19, 2024 at 6:16 AM WindnFog  wrote:

> I encountered the same problem trying to calculate the all time humidex in
> the index.html.tmpl template.  This was taking about 3 minutes on a Pi 4.
> Rather than add humidex to the database (probably the best solution), I
> calculated all-time humidex once a day using a small program and invoking
> it with cron. I saved it in a text file that I could then use the Cheetah
> include statement to read it into index.the html.tmpl template.  This runs
> in 2 seconds on a Pi 4 and 1 second on a pi 5; if you have an algorithm for
> appTemp, a similar approach might work.  I was not comfortable with
> modifying the database because that's not my area of expertise:
>
> #!/usr/bin/env python3
> # -*- coding: utf-8 -*-
>
> """
> Program:WeeWX Humidex calculator
> Author: Paul M Dunphy
> Date:   12 December 2023
> Version:1.0.0
> Description:This script sweeps through the Weewx database and
> calculates the
> derived parameter humidex for each record.  It then
> returns the
> maximum humidex and the date/time when it occured.  This
> takes
> about 1.5 seconds on a 900,000 record database as opposed
> to 3.5
> minutes by the WeeWX system if the recommended aggregate
> values
> are implemented in the Standard/index.html.tmpl file:
>
> $alltime.humidex.max ($alltime.humidex.max.degree_F)
> $alltime.humidex.maxtime.format($ALLTIMEFMT)
>
> It's not clear why the weeWX system takes so long.
> Possibly
> because it's doing many other things at the same time.
>
> This runs on a Raspberry Pi 4B (4 GB Ram) using Debian 12
> """
>
> # Required Libraries
>
> import sqlite3
> import math
> from datetime import datetime
> import pytz
> from pytz import timezone
>
>
> def calculate_humidex(temperature, dewpoint):
> # Constants for the formula
> k = 273.15  # Conversion factor for Celsius to Kelvin
>
> # Convert temperatures to Kelvin
> temperature + k
> dewpoint_k = dewpoint + k
>
> # Calculate vapor pressure in hPa
> vapor_pressure = 6.112 * math.exp(5417.7530 * ((1 / 273.16) - (1 /
> dewpoint_k)))
>
> # Humidex calculation
> humidex = temperature + ((vapor_pressure - 10) * 0.)
> return humidex
>
>
> def get_max_humidex(database_path):
> # Connect to the WeeWX database
> conn = sqlite3.connect(database_path)
> cursor = conn.cursor()
>
> # Query for temperature, dewpoint, and dateTime for all records
> query = "SELECT outTemp, dewpoint, dateTime FROM archive"
> cursor.execute(query)
>
> # Variables to track the maximum humidex and its date
> maximum_humidex = None
> maximum_humidex_date = None
>
> for row in cursor:
> temperature, dewpoint, date_time = row
> if temperature is not None and dewpoint is not None:
> humidex = calculate_humidex(temperature, dewpoint)
> if maximum_humidex is None or humidex > maximum_humidex:
> maximum_humidex = humidex
> maximum_humidex_date = date_time
>
> conn.close()
> return maximum_humidex, maximum_humidex_date
>
>
> def convert_utc_to_ast_adt(utc_datetime):
> """
> Convert a UTC datetime to AST or ADT depending on the date.
>
> Parameters:
> utc_datetime (datetime): UTC datetime object.
>
> Returns:
> datetime: Datetime object in AST or ADT.
> """
> # Define the time zone for AST/ADT
> ast_tz = timezone('America/Halifax')
>
> # Localize the UTC datetime to the AST/ADT timezone
> local_datetime = ast_tz.normalize(utc_datetime.astimezone(ast_tz))
>
> return local_datetime
>
>
> def format_date(unix_timestamp):
> """
> Format a UNIX timestamp into a human-readable string in AST or ADT.
>
> Parameters:
> unix_timestamp (int): UNIX timestamp.
>
> Returns:
> str: Formatted date string.
> """
> # Create a UTC datetime from the UNIX timestamp
> utc_datetime =
> datetime.utcfromtimestamp(unix_timestamp).replace(tzinfo=pytz.utc)
>
> # Convert UTC to AST or ADT
> local_datetime = convert_utc_to_ast_adt(utc_datetime)
>
> # Format the local datetime
> return local_datetime.strftime("%I:%M %p on %d %b %Y")
>
>
> db_path = '/home/pdunphy/weewx-data/archive/weewx.sdb'
> max_humidex, max_humidex_date = get_max_humidex(db_path)
>
> # Convert Humidex to Fahrenheit
> max_humidex_f = max_humidex * 9 / 5 + 32
>
> # Format and print the result
> print(f"{max_humidex:.1f} C ({max_humidex_f:.1f} F) at
> {format_date(max_humidex_date)}")
>
> # Format the result
> output = f"{max_humidex:.1f} C ({max_humidex_f:.1f} F) at
> 

[weewx-user] Re: WeeWX 5 on a Mac

2024-01-19 Thread 'michael.k...@gmx.at' via weewx-user
The Ecowitt Gateway Driver ist just "yet another extension" and installed 
like any other. Simply refer to the 
documentation. https://weewx.com/docs/5.0/utilities/weectl-extension/ 
I don't know the SFTP driver, but I am pretty sure this also applies for 
installing the SFTP driver.
John Jacklin schrieb am Freitag, 19. Januar 2024 um 15:12:52 UTC+1:

> I would like to have another go at setting up WeeWX on a Mac (running 
> Ventura)
>
> I have read how to install WeeWX on using the instruction in the 
> documentation and this seems straightforward .
>
> I would need to install the SFTP drivers and the Ecowitt Gateway Drivers 
> and I am not sure how to go about this with WeeWX 5
>
> Many 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/7ed5c78f-7f7d-426d-9abd-47828528d9c0n%40googlegroups.com.


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

2024-01-19 Thread WindnFog
I encountered the same problem trying to calculate the all time humidex in 
the index.html.tmpl template.  This was taking about 3 minutes on a Pi 4. 
Rather than add humidex to the database (probably the best solution), I 
calculated all-time humidex once a day using a small program and invoking 
it with cron. I saved it in a text file that I could then use the Cheetah 
include statement to read it into index.the html.tmpl template.  This runs 
in 2 seconds on a Pi 4 and 1 second on a pi 5; if you have an algorithm for 
appTemp, a similar approach might work.  I was not comfortable with 
modifying the database because that's not my area of expertise:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

"""
Program:WeeWX Humidex calculator
Author: Paul M Dunphy
Date:   12 December 2023
Version:1.0.0
Description:This script sweeps through the Weewx database and 
calculates the 
derived parameter humidex for each record.  It then returns 
the
maximum humidex and the date/time when it occured.  This 
takes
about 1.5 seconds on a 900,000 record database as opposed 
to 3.5
minutes by the WeeWX system if the recommended aggregate 
values
are implemented in the Standard/index.html.tmpl file:

$alltime.humidex.max ($alltime.humidex.max.degree_F) 
$alltime.humidex.maxtime.format($ALLTIMEFMT)

It's not clear why the weeWX system takes so long.  Possibly
because it's doing many other things at the same time.  

This runs on a Raspberry Pi 4B (4 GB Ram) using Debian 12
"""

# Required Libraries

import sqlite3
import math
from datetime import datetime
import pytz
from pytz import timezone


def calculate_humidex(temperature, dewpoint):
# Constants for the formula
k = 273.15  # Conversion factor for Celsius to Kelvin

# Convert temperatures to Kelvin
temperature + k
dewpoint_k = dewpoint + k

# Calculate vapor pressure in hPa
vapor_pressure = 6.112 * math.exp(5417.7530 * ((1 / 273.16) - (1 / 
dewpoint_k)))

# Humidex calculation
humidex = temperature + ((vapor_pressure - 10) * 0.)
return humidex


def get_max_humidex(database_path):
# Connect to the WeeWX database
conn = sqlite3.connect(database_path)
cursor = conn.cursor()

# Query for temperature, dewpoint, and dateTime for all records
query = "SELECT outTemp, dewpoint, dateTime FROM archive"
cursor.execute(query)

# Variables to track the maximum humidex and its date
maximum_humidex = None
maximum_humidex_date = None

for row in cursor:
temperature, dewpoint, date_time = row
if temperature is not None and dewpoint is not None:
humidex = calculate_humidex(temperature, dewpoint)
if maximum_humidex is None or humidex > maximum_humidex:
maximum_humidex = humidex
maximum_humidex_date = date_time

conn.close()
return maximum_humidex, maximum_humidex_date


def convert_utc_to_ast_adt(utc_datetime):
"""
Convert a UTC datetime to AST or ADT depending on the date.

Parameters:
utc_datetime (datetime): UTC datetime object.

Returns:
datetime: Datetime object in AST or ADT.
"""
# Define the time zone for AST/ADT
ast_tz = timezone('America/Halifax')

# Localize the UTC datetime to the AST/ADT timezone
local_datetime = ast_tz.normalize(utc_datetime.astimezone(ast_tz))

return local_datetime


def format_date(unix_timestamp):
"""
Format a UNIX timestamp into a human-readable string in AST or ADT.

Parameters:
unix_timestamp (int): UNIX timestamp.

Returns:
str: Formatted date string.
"""
# Create a UTC datetime from the UNIX timestamp
utc_datetime = 
datetime.utcfromtimestamp(unix_timestamp).replace(tzinfo=pytz.utc)

# Convert UTC to AST or ADT
local_datetime = convert_utc_to_ast_adt(utc_datetime)

# Format the local datetime
return local_datetime.strftime("%I:%M %p on %d %b %Y")


db_path = '/home/pdunphy/weewx-data/archive/weewx.sdb'
max_humidex, max_humidex_date = get_max_humidex(db_path)

# Convert Humidex to Fahrenheit
max_humidex_f = max_humidex * 9 / 5 + 32

# Format and print the result
print(f"{max_humidex:.1f} C ({max_humidex_f:.1f} F) at 
{format_date(max_humidex_date)}")

# Format the result
output = f"{max_humidex:.1f} C ({max_humidex_f:.1f} F) at 
{format_date(max_humidex_date)}"

# Write the result to a file
output_file_path = 
'/home/pdunphy/weewx-data/skins/Standard/Standard_all_time_humidex.txt'
with open(output_file_path, 'w') as file:
file.write(output)

print(f"Output written to {output_file_path}") 



On Thursday, January 18, 2024 at 7:12:14 PM UTC-4 Tom Keffer wrote:

> Using Blaine's database, I was able to isolate the performance problems.
>
> It's in the template records/index.html.tmpl

[weewx-user] WeeWX 5 on a Mac

2024-01-19 Thread John Jacklin
I would like to have another go at setting up WeeWX on a Mac (running 
Ventura)

I have read how to install WeeWX on using the instruction in the 
documentation and this seems straightforward .

I would need to install the SFTP drivers and the Ecowitt Gateway Drivers 
and I am not sure how to go about this with WeeWX 5

Many 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/14d237da-5782-4b5b-b245-cb34b5fb44bfn%40googlegroups.com.


Re: [weewx-user] Re: Why the rain 'spikes'?

2024-01-19 Thread John Smith
On Thu, 18 Jan 2024 at 13:26, Tom Keffer  wrote:

> You say that the "spikes" occur after power outages. I'm thinking the
> value for "dayRain" also changes.
>

Maybe he should get a UPS and put a big battery on it so it doesn't die
during blackouts.

-- 
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/CAGTinV7We1N7vOWPK7YZuERZwvdyNZv7_-CHMaWVo3kMEWS%3DJw%40mail.gmail.com.


Re: [weewx-user] Re: Weewx and Meteobridge - website update

2024-01-19 Thread John Smith
Depends on the skin you are using, and installation method, you could do a
search for index.html.tmpl and add it to the head section

On Thu, 18 Jan 2024 at 11:56, Jim Wilkerson  wrote:

> When you say to add the meta refresh to the "top of the template", which
> configuration file are you referring to please?
>
> Thanks..
>
> On Tuesday, January 9, 2024 at 9:22:27 AM UTC-5 gary@gmail.com wrote:
>
>> What skin are you using?
>>
>> On Sunday, January 7, 2024 at 1:36:16 PM UTC-5 bhouseski wrote:
>>
>>> Recently I was able to get Weewx running on a Raspberry Pi 4B, pulling
>>> data from a Vantage Pro2 connected to a D-Link DIR-505 loaded with
>>> Meteobridge (vantage is connected to the Meteobridge via USB).  All is well
>>> except I cannot get the website to autoload new data (I have to keep
>>> hitting refresh on my web browser).  I have played around with the archive
>>> interval, but have had no success.
>>>
>>> any idea's how to make this work?
>>>
>> --
> 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/b73d8ddc-0118-4b68-bf60-802838802898n%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/CAGTinV6POf2uJMfw_Yd%2BdDPAbf-NsvM08LT-zgvkvCOodnFU1A%40mail.gmail.com.


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

2024-01-19 Thread Richard Whitcombe
FWIW i just needed to add appTemp and its worked - report generation now 
takes 3 seconds not 190.
I would caveat that by saying im not using the other missing columns at all 
as my station doesnt provide the data so maybe if you are they need to be 
added too.
Missing data calculations took about 8 mins for 2017 - 2024 on a Pi4.

On Friday 19 January 2024 at 15:59:15 UTC+9 vince wrote:

> Re: the Belchertown issue many seem to be facing, I notice that Blaine's 
> db uses the original old wview schema, not the newer bigger 
> 'wview_extended' schema that came out a few years ago.  I suspect this is 
> the pattern we've missed.  Folks who have the old schema do not have any of 
> the elements for many of the Extended Observations in Belchertown's 
> skin.conf file. 
>
> Blaine's db schema misses these items in Belchertown's skin.conf extended 
> observations list
> appTemp  = Apparent Temperature
> cloudbase= Cloud Base
> visibility   = Visibility
> windrun  = Wind Run
> cloud_cover  = Cloud Cover
> aqi  = AQI
>
> The wview_extended schema is missing these, so I'd expect users with data 
> in those somehow might have the same slowness issue until they add db 
> elements and calc-missing to generate summary tables for them.
> visibility   = Visibility
> cloud_cover  = Cloud Cover
>
> Re: Michael's question about what to do about the NOAA files, I'd suggest 
> pre-calculating them offline and dropping them into place in his NOAA 
> subdirectory with the appropriate owner/group/mode so they don't have to be 
> recalculated.  I'd omit the current month+year which should regenerate 
> quickly on weewx startup.  That would be a good thing to try.  We've 
> verified the db is ok, so it 'should' work on Blaine's system too 
> (hopefully).  The test then would be to simply look at the date+time last 
> modified for the current month and year NOAA file.  It should change every 
> archive period as StdReport runs.
>
> (reminder - if you have Belchertown 'and' Seasons, you need to drop the 
> pre-calculated NOAA files into both places to preseed both skin output 
> directories)
>
> On Thursday, January 18, 2024 at 8:36:20 PM UTC-8 michael.k...@gmx.at 
> wrote:
>
>> Or, to speed things up, do the "calc-missing" on another machine with a 
>> more potent CPU.
>>
>> Back to Blaine's problem: if the NOAA files are generated on other 
>> installations with his database, there is obviously another problem with 
>> his installation.I don't have an idea what to look for, if deleted NOAA 
>> data will be regenerated in the same way, as before.
>>
>> vince schrieb am Freitag, 19. Januar 2024 um 04:55:13 UTC+1:
>>
>>> Docs are at https://www.weewx.com/docs/5.0/utilities/weectl-database/ 
>>> but what I did for a pip installation using Blaine's db was:
>>>
>>> source ~/weewx-venv/bin/activate
>>> weectl database add-column appTemp
>>> weectl calc-missing
>>> (answer y when prompted above)
>>>
>>> If you have a packaged install of weewx you can skip the activate step 
>>> above.
>>>
>>> Note - the calc-missing takes quite a while and will peg your cpu while 
>>> working, so if you have a lot of data so you might need to use the --from 
>>> and --to options or even the --tranche option to split up the processing a 
>>> bit into pieces.  I got lucky with this db on pi3plus with a bit of 
>>> patience waiting for calc-missing to complete
>>>
>>> (weewx-venv) pi@pi3plus:~/weewx-data $ weectl database calc-missing -y
>>> Using configuration file /home/pi/weewx-data/weewx.conf
>>> Missing derived observations will be calculated for all records.
>>> Calculating missing derived observations...
>>> Processing record: 959536; Last record: 2024-01-19 00:00:00 PST 
>>> (1705651200)
>>> Recalculating daily summaries...
>>> Records processed: 959000; time: 2024-01-16 15:55:00 PST (1705449300)
>>> Finished recalculating daily summaries
>>> Missing derived observations calculated in 2986.21 seconds
>>>
>>> And after restarting weewx things look good 
>>>
>>> 2024-01-18T19:45:15.438555-08:00 pi3plus weewxd[1797]: INFO 
>>> weewx.manager: Added record 2024-01-18 19:45:00 PST (1705635900) to 
>>> database 'weewx.sdb'
>>> 2024-01-18T19:45:15.458841-08:00 pi3plus weewxd[1797]: INFO 
>>> weewx.manager: Added record 2024-01-18 19:45:00 PST (1705635900) to daily 
>>> summary in 'weewx.sdb'
>>> 2024-01-18T19:45:19.659002-08:00 pi3plus weewxd[1797]: INFO 
>>> weewx.cheetahgenerator: Generated 8 files for report SeasonsReport in 3.92 
>>> seconds
>>> 2024-01-18T19:45:20.884377-08:00 pi3plus weewxd[1797]: INFO 
>>> weewx.imagegenerator: Generated 15 images for report SeasonsReport in 1.14 
>>> seconds
>>> 2024-01-18T19:45:20.893901-08:00 pi3plus weewxd[1797]: INFO 
>>> weewx.reportengine: Copied 5 files to /home/pi/weewx-data/public_html
>>> 2024-01-18T19:45:20.967437-08:00 pi3plus weewxd[1797]: 

Re: [weewx-user] Slow Report Generation after Upgrade from 4.10.2 to 5..0

2024-01-19 Thread Richard Whitcombe
I just did AppTemperature but its working for me.
Although i dont think i use any of the other columns as my station doesnt 
provide it.

Missing data calculations took about 8 minutes for 7 years of data on a Pi4.

On Friday 19 January 2024 at 19:14:09 UTC+9 mh081...@gmail.com wrote:

> Hi,
>
> as i read in the other posts about this Problem i doing now following.
>
> weectl database add-column appTemp
> weectl database add-column cloudbase
> weectl database add-column visibility
> weectl database add-column windrun
> weectl database add-column cloud_cover
> weectl database add-column aqi
>
> weectl database calc-missing
>
> Answer all wit 'y'
>
> Now it seems that the Problem was solved. Belchertown Reports was 
> generated in about 6 seconds. Thanks @vince for your right direction.
> ##
> Jan 19 11:09:50 wetter weewxd[293936]: INFO weewx.engine: Loading station 
> type Vantage (weewx.drivers.vantage)
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: StdConvert 
> target unit is 0x1
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.wxservices: 
> StdWXCalculate will use data binding wx_binding
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Archive will use 
> data binding wx_binding
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Record 
> generation will be attempted in 'hardware'
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Using archive 
> interval of 300 seconds (specified by hardware)
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: StationRegistry: 
> Registration not requested.
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: Wunderground-PWS: 
> Data for station IMECKLEN47 will be posted
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: Data 
> for station MHROSTOCK will be posted
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: CWOP: Posting not 
> enabled.
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: WOW: Posting not 
> enabled.
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: AWEKAS: Posting 
> not enabled.
> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: service version is 
> 0.23
> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: binding to 
> ['archive', 'loop']
> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: topic is weather
> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: desired unit system 
> is METRIC
> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: data will be 
> uploaded to mqtt://pi:x...@gw.martenhinrichs.de:8883/ 
> 
> Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: network 
> encryption/authentication will be attempted
> Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: 'pyephem' 
> detected, extended almanac data is available
> Jan 19 11:09:53 wetter weewxd[293936]: INFO __main__: Starting up weewx 
> version 5.0.0
> Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.engine: Clock error is 
> 2.69 seconds (positive is fast)
> Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.engine: Using binding 
> 'wx_binding' to database 'weewx.sdb'
> Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.manager: Starting 
> backfill of daily summaries
> Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.manager: Daily summaries 
> up to date
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.wxxtypes: Type beaufort 
> has been deprecated. Use unit beaufort instead.
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
> 2024-01-19 10:50:00 CET (1705657800) to database 'weewx.sdb'
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
> 2024-01-19 10:50:00 CET (1705657800) to daily summary in 'weewx.sdb'
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
> 2024-01-19 10:55:00 CET (1705658100) to database 'weewx.sdb'
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
> 2024-01-19 10:55:00 CET (1705658100) to daily summary in 'weewx.sdb'
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
> 2024-01-19 11:00:00 CET (1705658400) to database 'weewx.sdb'
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
> 2024-01-19 11:00:00 CET (1705658400) to daily summary in 'weewx.sdb'
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: 
> Published record 2024-01-19 10:50:00 CET (1705657800)
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
> 2024-01-19 11:05:00 CET (1705658700) to database 'weewx.sdb'
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
> 2024-01-19 11:05:00 CET (1705658700) to daily summary in 'weewx.sdb'
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.engine: Starting main 
> packet loop.
> Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: 
> Published record 2024-01-19 10:55:00 CET (1705658100)
> Jan 19 11:09:56 wetter 

[weewx-user] Interceptor proxy and forwarder

2024-01-19 Thread Alex Slaets
Dear friends, 
I'm considering an upgrade to V5 . 
In order to keep my existing weewx 4.1 running whilst working on a fresh V5 
installation I wanted to solve a problem. 
I use a wifi station, an alecto WS-5500 which sends to 
weewx.aslaets.be:8000 , or if you want 192.168.1.55:8000 . 
But I need to have this information sent to my production weewx  AND to my 
weewx being configured.
That is why I wrote this tool I share with you. It can listen, forward to 
an arbitrary list of servers or none and save the data from the wifi 
console to a text file. 
I hope it is helpful for you too. 

-- 
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/e2f300ca-a560-4df4-a778-c9616cf80d9dn%40googlegroups.com.

# Ecowitt Proxy Server
# Developed by Alex Slaets
#
# This Python script functions as a proxy server designed to receive HTTP POST requests
# and forward them to one or more specified target servers. It's particularly useful for
# applications like WeeWX where data from weather stations like Ecowitt needs to be
# sent to multiple endpoints for processing and analysis.
# A typical use case would be an upgrade situation where you need to keep running the old weewx installation while configuring new one or to test changes
# #
# The script supports command line arguments for specifying the listening port, target servers,
# and options for verbose output and logging received data to a file. It's designed to be
# easy to use and integrate into existing WeeWX setups, aiding in weather data collection and testing.
# Command Line Arguments:
# -p, --port: Specifies the port on which the server listens (default is 8000).
# -t, --targets: A list of target servers to which the POST requests will be forwarded.
#This argument is optional; if not provided, the script will only log the received data.
# -v, --verbose: Enables verbose mode, printing the received data to the console.
# -o, --output: Specifies a file to which the received data will be logged. This is useful for analyzing the data.
#
# Example usage:
# python ecowitt_proxy.py -p 8000 -t http://weewx.home:8000 http://weewxdevel.home:8000 -v
# This command will start the server on port 8000, forward data to two target servers, and enable verbose mode.
# python ecowitt_proxy.py -p 8012 -o ~/stationdata.txt  
# this command will listen to a console that transmits to port 8012 on your server and log the data without forwarding


import argparse
import requests
from http.server import BaseHTTPRequestHandler, HTTPServer
import signal

class ProxyHandler(BaseHTTPRequestHandler):
def __init__(self, target_urls, verbose, output_file, *args, **kwargs):
self.target_urls = target_urls
self.verbose = verbose
self.output_file = output_file
super().__init__(*args, **kwargs)

def do_POST(self):
# Read incoming request
content_length = int(self.headers['Content-Length'])
post_data = self.rfile.read(content_length)

# Write data to file if asked
if self.output_file:
with open(self.output_file, 'ab') as file:
file.write(post_data)
file.write(b'\n')  # add a newline

# process targets and verbose option
if self.target_urls:
for url in self.target_urls:
try:
response = requests.post(url, data=post_data)
if self.verbose:
print(f"Data sent to {url}, status code: {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"Error transmitting to {url}: {e}")
elif self.verbose:
print("Received data:", post_data)

# Send a simpele response back to client
self.send_response(200)
self.end_headers()

def run(server_class=HTTPServer, handler_class=ProxyHandler, port=8000, target_urls=None, verbose=False, output_file=None):
server_address = ('', port)
handler = lambda *args, **kwargs: handler_class(target_urls, verbose, output_file, *args, **kwargs)

try: 
httpd = server_class(server_address, handler)
print(f"Server listening on port {port}...")
except  OSError as e:
print(f"Error: Cannot listen on port {port}. This port may be in use (weewx running on this host?). System error: {e}")
exit(1)

try:
httpd.serve_forever()
except KeyboardInterrupt:
print("\nStopping server ...")
httpd.server_close()
print("Server stopped.")

if __name__ == '__main__':
parser = argparse.ArgumentParser(description="HTTP Proxy Server")
parser.add_argument('-p', '--port', type=int, default=8000, help='Port listening')

Re: [weewx-user] Slow Report Generation after Upgrade from 4.10.2 to 5..0

2024-01-19 Thread mh081...@gmail.com
Hi,

as i read in the other posts about this Problem i doing now following.

weectl database add-column appTemp
weectl database add-column cloudbase
weectl database add-column visibility
weectl database add-column windrun
weectl database add-column cloud_cover
weectl database add-column aqi

weectl database calc-missing

Answer all wit 'y'

Now it seems that the Problem was solved. Belchertown Reports was generated 
in about 6 seconds. Thanks @vince for your right direction.
##
Jan 19 11:09:50 wetter weewxd[293936]: INFO weewx.engine: Loading station 
type Vantage (weewx.drivers.vantage)
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: StdConvert target 
unit is 0x1
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.wxservices: 
StdWXCalculate will use data binding wx_binding
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Archive will use 
data binding wx_binding
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Record generation 
will be attempted in 'hardware'
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: Using archive 
interval of 300 seconds (specified by hardware)
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: StationRegistry: 
Registration not requested.
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: Wunderground-PWS: 
Data for station IMECKLEN47 will be posted
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: Data 
for station MHROSTOCK will be posted
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: CWOP: Posting not 
enabled.
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: WOW: Posting not 
enabled.
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.restx: AWEKAS: Posting 
not enabled.
Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: service version is 
0.23
Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: binding to 
['archive', 'loop']
Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: topic is weather
Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: desired unit system 
is METRIC
Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: data will be 
uploaded to mqtt://pi:x...@gw.martenhinrichs.de:8883/
Jan 19 11:09:53 wetter weewxd[293936]: INFO user.mqtt: network 
encryption/authentication will be attempted
Jan 19 11:09:53 wetter weewxd[293936]: INFO weewx.engine: 'pyephem' 
detected, extended almanac data is available
Jan 19 11:09:53 wetter weewxd[293936]: INFO __main__: Starting up weewx 
version 5.0.0
Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.engine: Clock error is 
2.69 seconds (positive is fast)
Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'
Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.manager: Starting 
backfill of daily summaries
Jan 19 11:09:54 wetter weewxd[293936]: INFO weewx.manager: Daily summaries 
up to date
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.wxxtypes: Type beaufort 
has been deprecated. Use unit beaufort instead.
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
2024-01-19 10:50:00 CET (1705657800) to database 'weewx.sdb'
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
2024-01-19 10:50:00 CET (1705657800) to daily summary in 'weewx.sdb'
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
2024-01-19 10:55:00 CET (1705658100) to database 'weewx.sdb'
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
2024-01-19 10:55:00 CET (1705658100) to daily summary in 'weewx.sdb'
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
2024-01-19 11:00:00 CET (1705658400) to database 'weewx.sdb'
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
2024-01-19 11:00:00 CET (1705658400) to daily summary in 'weewx.sdb'
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: 
Published record 2024-01-19 10:50:00 CET (1705657800)
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
2024-01-19 11:05:00 CET (1705658700) to database 'weewx.sdb'
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.manager: Added record 
2024-01-19 11:05:00 CET (1705658700) to daily summary in 'weewx.sdb'
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.engine: Starting main 
packet loop.
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: 
Published record 2024-01-19 10:55:00 CET (1705658100)
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: 
Published record 2024-01-19 11:00:00 CET (1705658400)
Jan 19 11:09:56 wetter weewxd[293936]: INFO weewx.restx: Wunderground-PWS: 
Published record 2024-01-19 10:50:00 CET (1705657800)
Jan 19 11:09:57 wetter weewxd[293936]: INFO weewx.restx: Wunderground-PWS: 
Published record 2024-01-19 10:55:00 CET (1705658100)
Jan 19 11:09:57 wetter weewxd[293936]: INFO weewx.restx: PWSWeather: 
Published record 2024-01-19 11:05:00 CET (1705658700)
Jan 19 11:09:57 wetter 

Re: [weewx-user] Slow Report Generation after Upgrade from 4.10.2 to 5..0

2024-01-19 Thread mh081...@gmail.com
Hi,

as you wish. I have no extra/extended schema in my database.
#
root@wetter:~# echo "select count(*) from pragma_table_info('archive');" | 
sqlite3 /var/tmp/test.sdb
52
#


vince schrieb am Freitag, 19. Januar 2024 um 08:32:51 UTC+1:

> Followup on this one - If the original poster can check to see if their 
> database uses the old original (small) wview schema that would likely help. 
>  Easiest way is to look to see how many elements are in the database. One 
> way to see how many elements you have in your db would be:
>
>- cp weewx.sdb /var/tmp/test.sdb
>- echo "select count(*) from pragma_table_info('archive');" | sqlite3 
>/var/tmp/test.sdb
>   - (my db with the extended schema returns "114" as the count)
>   - (a db with the original wview schema returns "52" as the count)
>
>
> Switching to the extended schema is a bit of work and takes some time. 
>  The details are documented at 
> http://www.weewx.com/docs/5.0/custom/database/ with the procedure for how 
> to switch to the new bigger schema in 
> http://www.weewx.com/docs/5.0/custom/database/#reconfigure-using-new-schema 
> - but be CAREFUL doing this and ALWAYS work off a copy of your db so if 
> anything happens you can revert to a known good db.   I've done it so many 
> years ago at this point that I'll have to defer to others for pitfalls and 
> how they do it, but the links above are how the current docs recommend 
> doing so.
>
> Short description to the original Belchertown problem reporters - check 
> your db schema.  Hopefully that's the pattern of which systems will need to 
> take action.
>
>
>

-- 
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/483c21ff-56b7-49a9-84bb-e2d3442a181cn%40googlegroups.com.


Re: [weewx-user] Slow Report Generation after Upgrade from 4.10.2 to 5..0

2024-01-19 Thread Richard Whitcombe
In my case with the same problem, im NOT using the extended schema - it 
returns 52.

On Friday 19 January 2024 at 16:32:51 UTC+9 vince wrote:

> Followup on this one - If the original poster can check to see if their 
> database uses the old original (small) wview schema that would likely help. 
>  Easiest way is to look to see how many elements are in the database. One 
> way to see how many elements you have in your db would be:
>
>- cp weewx.sdb /var/tmp/test.sdb
>- echo "select count(*) from pragma_table_info('archive');" | sqlite3 
>/var/tmp/test.sdb
>   - (my db with the extended schema returns "114" as the count)
>   - (a db with the original wview schema returns "52" as the count)
>
>
> Switching to the extended schema is a bit of work and takes some time. 
>  The details are documented at 
> http://www.weewx.com/docs/5.0/custom/database/ with the procedure for how 
> to switch to the new bigger schema in 
> http://www.weewx.com/docs/5.0/custom/database/#reconfigure-using-new-schema 
> - but be CAREFUL doing this and ALWAYS work off a copy of your db so if 
> anything happens you can revert to a known good db.   I've done it so many 
> years ago at this point that I'll have to defer to others for pitfalls and 
> how they do it, but the links above are how the current docs recommend 
> doing so.
>
> Short description to the original Belchertown problem reporters - check 
> your db schema.  Hopefully that's the pattern of which systems will need to 
> take action.
>
>
>

-- 
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/a9f501bc-35a6-453e-a8ba-a558d7958103n%40googlegroups.com.


Re: [weewx-user] Re: Why the rain 'spikes'?

2024-01-19 Thread Bob Atchley
Interesting, I hadn't noticed that, and I see the same pattern on the other 
days you have posted.
I suspect what is happening is that if the data buffer is full, the final 
data item is continually over written with that days accumulated rain which 
the WS6.in1 driver then assumes is a normal value.
I will test this - I need to wait for the buffer on my weather station to 
be full (late Feb) and then wait for a rainy day.  Depending on what is 
output by the weather station to the driver I will update the driver.
But again for you the simple solution is to regularly manually reset the 
data buffer following the instructions in the (on line) user manual - this 
should ensure you have no gaps in your data and will remove the spikes - a 
double win.

Hope this helps

Bob

On Friday 19 January 2024 at 01:12:41 UTC Ξ wrote:

> Hi Bob,
>
> You've already explained to me about the buffer in another thread, but I 
> haven't got around to to empty it or change the setting, I'll go there 
> tomorrow and do just that! Thanks again!
>
> When looking at the data for 15-Dec-23 specifically, it does appear that 
> 14 is the sum of all the previous values for the day since midnight, I'd 
> imagine the buffer would have more values stores, no!? Basically as Tom 
> says these are the dayRain values aggregated and inserted into the db once 
> it's up again:
> (I've removed the rows with 0)
>
> [image: s.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/84ebe1d4-b8f0-456b-955c-bb5fc9fe0b62n%40googlegroups.com.