Re: [weewx-user] Fwd: weewx wx data not updating to display html files

[Graham Eddy]

could you turn on debug (try level 2) and repost log?
also, could you post last ten entries of archive table? (only dateTime and 
outTemp needed)
cheers

> On 21 Aug 2020, at 3:39 pm, VE4PER / Andy  
> wrote:
> 
> Aug 20 22:24:22 {w/s ID} weewx[13049] INFO __main__: Debug is 0

-- 
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/5BB82252-6288-4334-B4B6-7FE349588987%40gmail.com.

[weewx-user] Fwd: weewx wx data not updating to display html files

[VE4PER / Andy]

It would appear that attachments prevent distribution so here is text 
contents of original message syslog info minus png of html page display.


* Forwarded Message *

Subject:*weewx wx data not updating to display html files*
Date:   *Thu, 20 Aug 2020 23:07:33 -0500*
From:   *VE4PER / Andy *
To: *weewx-user *

***
**
**I just began having problem with weewx suddenly not inserting data 
into files properly.**

**
**I tried stopping and restarting weewx, then rebooting the PC, to no 
avail them remove weewx software saving config files and reinstalling 
weewx software**

**
**still no joy. The output html files I use to monitor stn output (ie 
local html copy and ftp'd cop to my personal web site) get generated 
properly as the date time is updated correctly with each update every 
300 secs but all data slots display N/A.**

**
**The SQL database using phpmyadmin  shows data normal as do syslog 
message indications (see att docx) and the AcuRite display shows data is 
being updated correctly from the 5 in 1 sensor. lsusb shows the display 
unit is being properly detected and proper driver loaded yet no data is 
being inserted.**

**
**Attached docx file shows syslog sequence for  start stop of weewx and 
two successive update sequences with apparently no tech errors.**

**
**Any assistance would be appreciated; thanks**
**
**73 & Gud DX Andy*

{user ID}@{w/s ID}:~$ sudo tail -f /var/log/syslog


Aug 20 22:23:56 {w/s ID} weewx[12963]: ...done.

Aug 20 22:23:56 {w/s ID} systemd[1]: weewx.service: Succeeded.

Aug 20 22:23:56 {w/s ID} systemd[1]: Stopped LSB: weewx weather system.

Aug 20 22:24:22 {w/s ID} systemd[1]: Starting LSB: weewx weather system...

Aug 20 22:24:22 {w/s ID} weewx[13017]: * Starting weewx weather system weewx

Aug 20 22:24:22 {w/s ID} weewx[13046] INFO __main__: Initializing weewx 
version 4.1.1


Aug 20 22:24:22 {w/s ID} weewx[13046] INFO __main__: Using Python 3.8.2 
(default, Jul 16 2020, 14:00:26) #012[GCC 9.3.0]


Aug 20 22:24:22 {w/s ID} weewx[13046] INFO __main__: Platform 
Linux-5.4.0-42-lowlatency-x86_64-with-glibc2.29


Aug 20 22:24:22 {w/s ID} weewx[13046] INFO __main__: Locale is 'en_CA.UTF-8'

Aug 20 22:24:22 {w/s ID} weewx[13046] INFO __main__: PID file is 
/var/run/weewx.pid


Aug 20 22:24:22 {w/s ID} weewx[13049] INFO __main__: Using configuration 
file /etc/weewx/weewx.conf


Aug 20 22:24:22 {w/s ID} weewx[13049] INFO __main__: Debug is 0

Aug 20 22:24:22 {w/s ID} weewx[13049] INFO weewx.engine: Loading station 
type AcuRite (weewx.drivers.acurite)


Aug 20 22:24:22 {w/s ID} weewx[13049] INFO weewx.drivers.acurite: driver 
version is 0.4


Aug 20 22:24:22 {w/s ID} weewx[13049] INFO weewx.drivers.acurite: R2 
will be decoded using sensor constants


Aug 20 22:24:22 {w/s ID} weewx[13049] INFO weewx.engine: StdConvert 
target unit is 0x10


Aug 20 22:24:22 {w/s ID} weewx[13017]: ...done.

Aug 20 22:24:22 {w/s ID} systemd[1]: Started LSB: weewx weather system.

Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.wxservices: The 
following values will be calculated: pressure=prefer_hardware, 
barometer=prefer_hardware, altimeter=prefer_hardware, 
windchill=prefer_hardware, heatindex=prefer_hardware, 
dewpoint=prefer_hardware, inDewpoint=prefer_hardware, 
rainRate=prefer_hardware, maxSolarRad=prefer_hardware, 
cloudbase=prefer_hardware, humidex=prefer_hardware, 
appTemp=prefer_hardware, ET=prefer_hardware, windrun=prefer_hardware


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.wxservices: The 
following algorithms will be used for calculations: altimeter=aaASOS, 
maxSolarRad=RS


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.engine: Archive will 
use data binding wx_binding


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.engine: Record 
generation will be attempted in 'hardware'


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.engine: Using archive 
interval of 300 seconds (specified in weewx configuration)


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.restx: StationRegistry: 
Station will be registered.


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.restx: 
Wunderground-PWS: Data for station IPORTAGE5 will be posted


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.restx: PWSWeather: Data 
for station VE4PER will be posted


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.restx: CWOP: Data for 
station VE4PER will be posted


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.restx: WOW: Posting not 
enabled.


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.restx: AWEKAS: Data 
will be uploaded for user VE4PER


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO __main__: Starting up weewx 
version 4.1.1


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx'


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.manager: Starting 
backfill of daily summaries


Aug 20 22:24:23 {w/s ID} weewx[13049] INFO weewx.engine: Starting main 
packet loop.


Aug 20 22:25:17 {w/s ID} weewx[13049] INFO we

[weewx-user] Re: whew and gw1000

[rich T]

In the weewx.config file, is your FTP section setup?

On Friday, August 21, 2020 at 12:35:51 AM UTC-4, Luke Marcum wrote:
>
> Its out on the internet and I used the Saratoga Template!
>
> On Friday, August 21, 2020 at 12:34:54 AM UTC-4, rich T wrote:
>>
>> Is it local (on local network) or  out on internet?
>>
>> On Friday, August 21, 2020 at 12:04:54 AM UTC-4, Luke Marcum wrote:
>>>
>>> Ok, now that Ive finished configuration, how to I get weewx-wd to send 
>>> the testtags file to my website?
>>>  
>>>
>>

-- 
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/6cf348aa-a7d4-4870-88a1-592501e300a6o%40googlegroups.com.

[weewx-user] Re: whew and gw1000

[Luke Marcum]

Its out on the internet and I used the Saratoga Template!

On Friday, August 21, 2020 at 12:34:54 AM UTC-4, rich T wrote:
>
> Is it local (on local network) or  out on internet?
>
> On Friday, August 21, 2020 at 12:04:54 AM UTC-4, Luke Marcum wrote:
>>
>> Ok, now that Ive finished configuration, how to I get weewx-wd to send 
>> the testtags file to my website?
>>  
>>
>

-- 
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/084a82dc-9dae-46fa-a36f-8d529bf5882co%40googlegroups.com.

[weewx-user] Re: whew and gw1000

[rich T]

Is it local (on local network) or  out on internet?

On Friday, August 21, 2020 at 12:04:54 AM UTC-4, Luke Marcum wrote:
>
> Ok, now that Ive finished configuration, how to I get weewx-wd to send the 
> testtags file to my website?
>  
>

-- 
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/d85e3a26-26dc-4ace-9aae-45a8b1d32409o%40googlegroups.com.

[weewx-user] Re: WH1080 sender / receiver appears to have died, suggestions?

[Andrew Milner]

read the manual - there is a button to press (i forget which) to regain 
communications.  Just looked - press and hold the down key for 4 seconds 
until the console beeps.

Register transmitter If no outdoor weather data is displayed or the signal 
to the sensors is lost during setting up, mounting, changing of batteries 
to the sensor or plugging or unplugging cables, simply press and hold the 
DOWN/- key for 4 seconds and a short beep will sound to synchronize the 
base station to sensors. Without being synchronized, weather data will not 
be received. NOTE: Wait two minutes before re-insert the batteries of 
transmitter for proper reset. Note: The best condition for reception is at 
night, between midnight and 6:00am – when there is less atmospheric 
interference.



On Thursday, 20 August 2020 21:10:43 UTC+3, James Muirhead wrote:
>
> My WH1080 sender / receiver appears to have died. 
>
> The battery low indicator had been on for some time and died about 0130 
> this morning.
>
> I changed out the batteries in the sender today and it does not want to 
> communicate with the receiver now. LED in the sender comes on and receiver 
> appears normal.
>
> I've reset receiver and sender in both orders and left for an hour, etc, 
> etc. WeeWX WebUI shows no signal (but I don't know how this is generated).
>
> The communication icon on receiver comes up sporadically for a minute at 
> start and for quarter of a second once in a while.
>
> I'm gonna take apart the sender tomorrow and give everything a good clean, 
> see if it helps.
>
> Has anyone got a suggestion, other than "buy a new weather station"?
>
> Thanks.
>
> PS - WeeWX is working perfectly. But I have WeeWX installed on an Orange 
> Pi PC (1.3GHz Quad, 1GB RAM). Shout if you want anymore information.
>

-- 
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/7cffbaeb-c08c-4ddc-b0cc-ce4cda005b6do%40googlegroups.com.

[weewx-user] Re: whew and gw1000

[Luke Marcum]

Ok, now that Ive finished configuration, how to I get weewx-wd to send the 
testtags file to my website?

On Wednesday, August 19, 2020 at 9:41:09 PM UTC-4, gjr80 wrote:
>
> That is good to hear.
>
> Gary
>
> On Thursday, 20 August 2020 11:20:20 UTC+10, Luke Marcum wrote:
>>
>> Thanks so much! Just tried it out and it worked!
>>
>> On Wednesday, August 19, 2020 at 9:15:45 PM UTC-4, Luke Marcum wrote:
>>>
>>> Its fine!
>>>
>>> On Wednesday, August 19, 2020 at 7:35:56 PM UTC-4, gjr80 wrote:

 Have published the WeeWX-WD 
  v2.0.0 release 
 just now. Download and installation should work as per the readme. My 
 apologies for the delay.

 Gary

 On Tuesday, 18 August 2020 22:41:09 UTC+10, gjr80 wrote:
>
> Rich, thanks, indeed I did not publish a 2.0.0 release package and 
> hence the 404 error. 
>
> Luke. As Rich points out you can download a zip of the repo and that 
> will install, my concern is whether there are any outstanding issues with 
> 2.0.0. From memory I had them all sorted and then other things took me 
> away 
> from publishing the release. Give me day to have a look over 2.0.0 and 
> publish the release.
>
> Gary
>
> On Tuesday, 18 August 2020 21:22:09 UTC+10, rich T wrote:
>>
>> Gary
>>
>> Believe this is the issue that Luke is having:
>>
>> pi@raspberrypi:~ $ wget -P /var/tmp 
>> https://github.com/gjr80/weewx-weewx-wd/releases/download/v2.0.0/weewxwd-2.0.0.tar.gz
>> --2020-08-18 07:17:01--  
>> https://github.com/gjr80/weewx-weewx-wd/releases/download/v2.0.0/weewxwd-2.0.0.tar.gz
>> Resolving github.com (github.com)... 140.82.112.4
>> Connecting to github.com (github.com)|140.82.112.4|:443... connected.
>> HTTP request sent, awaiting response... 404 Not Found
>> 2020-08-18 07:17:02 ERROR 404: Not Found.
>>
>> Now if you go to https://github.com/gjr80/weewx-weewx-wd, cloning or 
>> downloading the zip file seems to work.
>>
>> Rich
>>
>> On Sunday, August 16, 2020 at 6:26:16 PM UTC-4, Luke Marcum wrote:
>>>
>>> Im trying to set up weewx to obtain data from my gw1000, running on 
>>> my pi4.  Im using these instructions to set it up: 
>>> https://github.com/weewx/weewx/wiki/gw1000-recipe and I've made it 
>>> to the part where I have to update the interceptor settings in 
>>> weewx.conf 
>>> but I can't seem to find where this part of the settings is.  I have 
>>> been 
>>> able to run interceptor.py from the interceptor download and it gets my 
>>> current weather data, but I can't seem to connect it to weewx.  HELP!!!
>>>
>>

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

[weewx-user] Re: next-gen WeatherFlow kickstarter

[Xant]

WeatherFlow/Tempest Weewx driver link already provided in my previous post 
(github by Captain-Coredump).

No need to search...

On Thursday, August 20, 2020 at 5:39:00 PM UTC-4 vince wrote:

> On Thursday, August 20, 2020 at 8:13:47 AM UTC-7, jerry.si...@gmail.com 
> wrote:
>>
>> I've had my Tempest up for about 6 weeks ago and loving it. Is there a 
>> way to get the data into WEEWX ?
>
>
> I'd try to google "WeatherFlow weewx" and see what it returns.
>

-- 
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/f01d3b75-2c06-4cc7-be3f-00dac5833b60n%40googlegroups.com.

[weewx-user] Re: GW1000 output and database

[gjr80]

The highlighted line tells me the default field map is being used and not 
[[field_map]]:

Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Loading 
service user.gw1000.Gw1000Service
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: GW1000 
was found at 192.168.1.6:45000
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: field 
map is {'UV': 'uvi', 'dateTime': 'datetime', 'dayRain': 'rainday', 
'daymaxwind': 'daymaxwind', 'dewpoint': 'dewpoint', 'extraHumid1': 'humid1', 
'extraHumid2': 'humid2', 'extraHumid3': 'humid3', 'extraHumid4': 'humid4', 
'extraHumid5': 'humid5', 'extraHumid6': 'humid6', 'extraHumid7': 'humid7', 
'extraHumid8': 'humid8', 'extraTemp1': 'temp1', 'extraTemp2': 'temp2', 
'extraTemp3': 'temp3', 'extraTemp4': 'temp4', 'extraTemp5': 'temp5', 
'extraTemp6': 'temp6', 'extraTemp7': 'temp7', 'extraTemp8': 'temp8', 
'heatindex': 'heatindex', 'hourRain': 'rainhour', 'inHumidity': 'inhumid', 
'inTemp': 'intemp', 'leak1': 'leak1', 'leak2': 'leak2', 'leak3': 'leak3', 
'leak4': 'leak4', 'lightning_distance': 'lightningdist', 
'lightning_last_det_time': 'lightningdettime', 'lightning_strike_count': 
'lightning_strike_count', 'luminosity': 'light', 'monthRain': 'rainmonth', 
'outHumidity': 'outhumid', 'outTemp': 'outtemp', 'pm2_5': 'pm251', 
'pm2_51_24hav': 'pm251_24hav', 'pm2_52': 'pm252', 'pm2_52_24hav': 
'pm252_24hav', 'pm2_53': 'pm253', 'pm2_53_24hav': 'pm253_24hav', 'pm2_54': 
'pm254', 'pm2_54_24hav': 'pm254_24hav', 'pressure': 'absbarometer', 'rain': 
'rain', 'rainRate': 'rainrate', 'relbarometer': 'relbarometer', 'soilMoist1'
: 'soilmoist1', 'soilMoist2': 'soilmoist2', 'soilMoist3': 'soilmoist3', 
'soilMoist4': 'soilmoist4', 'soilMoist5': 'soilmoist5', 'soilMoist6': 
'soilmoist6', 'soilMoist7': 'soilmoist7', 'soilMoist8': 'soilmoist8', 
'soilMoist9': 'soilmoist9', 'soilMoist10': 'soilmoist10', 'soilMoist11': 
'soilmoist11', 'soilMoist12': 'soilmoist12', 'soilMoist13': 'soilmoist13', 
'soilMoist14': 'soilmoist14', 'soilMoist15': 'soilmoist15', 'soilMoist16': 
'soilmoist16', 'soilTemp1': 'soiltemp1', 'soilTemp2': 'soiltemp2', 
'soilTemp3': 'soiltemp3', 'soilTemp4': 'soiltemp4', 'soilTemp5': 'soiltemp5'
, 'soilTemp6': 'soiltemp6', 'soilTemp7': 'soiltemp7', 'soilTemp8': 
'soiltemp8', 'soilTemp9': 'soiltemp9', 'soilTemp10': 'soiltemp10', 
'soilTemp11': 'soiltemp11', 'soilTemp12': 'soiltemp12', 'soilTemp13': 
'soiltemp13', 'soilTemp14': 'soiltemp14', 'soilTemp15': 'soiltemp15', 
'soilTemp16': 'soiltemp16', 'stormRain': 'rainevent', 'totalRain': 
'raintotals', 'uvradiation': 'uv', 'weekRain': 'rainweek', 'wh25_batt': 
'wh25_batt', 'wh26_batt': 'wh26_batt', 'wh31_ch1_batt': 'wh31_ch1_batt', 
'wh31_ch2_batt': 'wh31_ch2_batt', 'wh31_ch3_batt': 'wh31_ch3_batt', 
'wh31_ch4_batt': 'wh31_ch4_batt', 'wh31_ch5_batt': 'wh31_ch5_batt', 
'wh31_ch6_batt': 'wh31_ch6_batt', 'wh31_ch7_batt': 'wh31_ch7_batt', 
'wh31_ch8_batt': 'wh31_ch8_batt', 'wh40_batt': 'wh40_batt', 'wh41_ch1_batt': 
'wh41_ch1_batt', 'wh41_ch2_batt': 'wh41_ch2_batt', 'wh41_ch3_batt': 
'wh41_ch3_batt', 'wh41_ch4_batt': 'wh41_ch4_batt', 'wh51_ch1_batt': 
'wh51_ch1_batt', 'wh51_ch2_batt': 'wh51_ch2_batt', 'wh51_ch3_batt': 
'wh51_ch3_batt', 'wh51_ch4_batt': 'wh51_ch4_batt', 'wh51_ch5_batt': 
'wh51_ch5_batt', 'wh51_ch6_batt': 'wh51_ch6_batt', 'wh51_ch7_batt': 
'wh51_ch7_batt', 'wh51_ch8_batt': 'wh51_ch8_batt', 'wh51_ch9_batt': 
'wh51_ch9_batt', 'wh51_ch10_batt': 'wh51_ch10_batt', 'wh51_ch11_batt': 
'wh51_ch11_batt', 'wh51_ch12_batt': 'wh51_ch12_batt', 'wh51_ch13_batt': 
'wh51_ch13_batt', 'wh51_ch14_batt': 'wh51_ch14_batt', 'wh51_ch15_batt': 
'wh51_ch15_batt', 'wh51_ch16_batt': 'wh51_ch16_batt', 'wh55_ch1_batt': 
'wh55_ch1_batt', 'wh55_ch2_batt': 'wh55_ch2_batt', 'wh55_ch3_batt': 
'wh55_ch3_batt', 'wh55_ch4_batt': 'wh55_ch4_batt', 'wh57_batt': 'wh57_batt', 
'wh65_batt': 'wh65_batt', 'wh68_batt': 'wh68_batt', 'windDir': 'winddir', 
'windGust': 'gustspeed', 'windSpeed': 'windspeed', 'windchill': 'windchill', 
'ws80_batt': 'ws80_batt', 'yearRain': 'rainyear'}
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: version 
is 0.1.0b11
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: GW1000 
IP address not specified, attempting to discover GW1000...
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: GW1000 
address is 192.168.1.6:45000
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: poll 
interval is 60 seconds
Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG gw1000: user.gw1000: max 
tries is 3, retry wait time is 10 seconds
Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG gw1000: user.gw1000: 
broadcast address 255.255.255.255:46000, socket timeout is 2 seconds
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: max age 
of API data to be used is 60 seconds
Aug 20 20:01:32 raspberrypi weewx[31556] DEBUG weewx.engine: Finished 
loading service user.gw1000.Gw1000Service

What was your [GW1000] stanza when this was log was taken, if you did 

[weewx-user] Re: GW1000 output and database

[Timothy Buchanan]

[[field_map]] makes all values null, including the ones that worked before. 
Syslog follows

-- 
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/d81fe0ba-3b93-4e3a-a7bb-5d8364d7641dn%40googlegroups.com.
Aug 20 20:01:29 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Aug 20 20:01:29 raspberrypi systemd[1]: Starting LSB: weewx weather system...
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: Initializing weewx 
version 4.1.1
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: Using Python 2.7.16 
(default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: Platform 
Linux-5.4.51-v7l+-armv7l-with-debian-10.4
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: Locale is 'en_US.UTF-8'
Aug 20 20:01:29 raspberrypi weewx[31552] INFO __main__: PID file is 
/var/run/weewx.pid
Aug 20 20:01:29 raspberrypi weewx[31540]: Starting weewx weather system: weewx.
Aug 20 20:01:29 raspberrypi systemd[1]: Started LSB: weewx weather system.
Aug 20 20:01:29 raspberrypi weewx[31556] INFO __main__: Using configuration 
file /etc/weewx/weewx.conf
Aug 20 20:01:29 raspberrypi weewx[31556] INFO __main__: Debug is 1
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG __main__: Initializing engine
Aug 20 20:01:29 raspberrypi weewx[31556] INFO weewx.engine: Loading station 
type WeatherFlowUDP (user.weatherflowudp)
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: driver version 
is 1.03
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: sensor map is 
{u'outTemp': u'air_temperature.AR-00017660.obs_air', u'outHumidity': 
u'relative_humidity.AR-00017660.obs_air', u'pressure': 
u'station_pressure.AR-00017660.obs_air', u'lightning_strikes': 
u'lightning_strike_count.AR-00017660.obs_air', u'avg_distance': 
u'lightning_strike_avg_distance.AR-00017660.obs_air', u'outTempBatteryStatus': 
u'battery.AR-00017660.obs_air', u'windSpeed': 
u'wind_speed.SK-00017445.rapid_wind', u'windDir': 
u'wind_direction.SK-00017445.rapid_wind', u'windGust': 
u'wind_gust.SK-00017445.obs_sky', u'lux': u'illuminance.SK-00017445.obs_sky', 
u'UV': u'uv.SK-00017445.obs_sky', u'rain': 
u'rain_accumulated.SK-00017445.obs_sky', u'windBatteryStatus': 
u'battery.SK-00017445.obs_sky', u'radiation': 
u'solar_radiation.SK-00017445.obs_sky', u'lightningYYY': 
u'distance.AR-00017660.evt_strike', u'lightningZZZ': 
u'energy.AR-00017660.evt_strike'}
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: *** Sensor 
names per packet type
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet 
rapid_wind: ('time_epoch', 'wind_speed', 'wind_direction')
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet obs_sky: 
('time_epoch', 'illuminance', 'uv', 'rain_accumulated', 'wind_lull', 
'wind_avg', 'wind_gust', 'wind_direction', 'battery', 'report_interval', 
'solar_radiation', 'local_day_rain_accumulation', 'precipitation_type', 
'wind_sample_interval')
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet obs_air: 
('time_epoch', 'station_pressure', 'air_temperature', 'relative_humidity', 
'lightning_strike_count', 'lightning_strike_avg_distance', 'battery', 
'report_interval')
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet 
evt_precip: time_epoch
Aug 20 20:01:29 raspberrypi weewxd: weatherflowudp: MainThread: packet 
evt_strike: ('time_epoch', 'distance', 'energy')
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Loading service 
weewx.engine.StdTimeSynch
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Finished loading 
service weewx.engine.StdTimeSynch
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Loading service 
user.bme280wx.Bme280wx
Aug 20 20:01:29 raspberrypi weewxd: bme280: bme280wx configuration 
{u'temperature_must_have': u'', u'humidityKeys': u'inHumidity', 
u'pressureKeys': u'', u'pressure_must_have': u'', u'i2c_port': u'1', 
u'humidity_must_have': u'', u'i2c_address': u'0x76', u'usUnits': u'US', 
u'temperatureKeys': u'inTemp'}
Aug 20 20:01:29 raspberrypi weewxd: bme280: I2C port: 1
Aug 20 20:01:29 raspberrypi weewxd: bme280: I2C address: 0x76
Aug 20 20:01:29 raspberrypi weewxd: bme280: fallback default units: US
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Finished loading 
service user.bme280wx.Bme280wx
Aug 20 20:01:29 raspberrypi weewx[31556] DEBUG weewx.engine: Loading service 
user.gw1000.Gw1000Service
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: GW1000 was 
found at 192.168.1.6:45000
Aug 20 20:01:32 raspberrypi weewx[31556] INFO gw1000: user.gw1000: field map is 
{'UV': 'uvi', 'dateTime': 'datetime', 'dayRain': 'rainday', 'daymaxwind': 
'daymaxwind', 'dewpoint': 'dew

[weewx-user] Re: Proper/Best Way to Add Additional Ecowitt Sensors

[gjr80]

Hi Rob,

To take the second part of your question first, I am currently putting 
together a page to go in the GW1000 driver wiki on how to extend the 
Seasons skin to include additional observations such as provided by the 
GW1000 driver. This will also cover adding plots and will complement the 
page re displaying GW1000 sensor battery states in Seasons 

.

Now for the db shema. As a general rule of thumb you should *avoid* 
modifying any of the WeeWX files except for weewx.conf, files in 
/home/weewx/bin/user (or /usr/share/weewx/user for package installs) and 
files in the skins directory. Those files/locations are preserved during 
WeeWX upgrades whereas other WeeWX files are liable to be overwritten 
during an upgrade meaning your changes may be lost, or at best may need to 
be re-applied. However, what you want to do can easily be done without 
running foul of future upgrades.

There are two basic ways you can add a new observation to your database, 
first you can re-purpose an existing field. For example, someone with a 
second rain gauge might re-purpose the field hailRate as the rain rate 
field for the second rain gauge. Most easily done if the re-purposed field 
uses the same units as the data you wish to store in the re-purposed field 
but you can essentially use any field. The upside is you don't need to 
change your schema, the downside is it may not be obvious from the field 
name as to what observation is stored in that field.

The second approach is to modify your database schema by adding a new 
field. This is more involved, thought the process is straight forward. 
Adding another field will not substantially increase the size of the 
database or adversely affect performance and I think the benefits of 
self-evident field names count for a lot, especially if you are going to be 
making changes to skins etc to display your data. At the end of the day the 
choice is yours.

I will assume you are going down the second path. The process you need to 
follow is not so much 'modifying wview_extended.py' (remember the rule of 
thumb I mentioned) but rather creating your own schema based on the schema 
in wview_extended.py which you then extend with your new fields. The 
process is covered in Adding a new type to the database 
 in the 
Customization Guide though you will need to make a couple of slight 
changes. The first change you need to make is instead of inserting the 
lines of code at step 1 in the process in the file user/electricity.py (the 
user directory is in /home/weewx/bin or /usr/share/weewx depending on your 
WeeWX install type), you should add the lines to the end of the special 
file users/extensions.py, something like this (untested):

import schemas.wview_extended

my_schema = { 
'table': schemas.wview_extended.table + [('soilMoist5', 'REAL')],
'day_summaries' : schemas.wview_extended.day_summaries + [('soilMoist5', 
'SCALAR')]
}


The second change is that you will need to tell WeeWX what unit group your 
new field belongs to so WeeWX knows what units to use and how to format the 
field in reports. This is done by adding the following to the end of 
user/extensions.py (untested):

import weewx.units

weewx.units.obs_group_dict['soilMoist5'] = 'group_moisture'

Otherwise follow the steps as is and once complete you should find your 
database now includes a field soilMoist5.

Gary

On Thursday, 20 August 2020 12:10:39 UTC+10, Blaze wrote:
>
> I think this is really a multipart question, but I am trying to understand 
> the best/proper way to add Ecowitt soil sensors to my reports. Keeping in 
> mind that I want to be able to upgrade to future releases as they come 
> available with the least amount of post upgrade effort. 
>
> *Setup*
> Ubuntu 20.04.1 LTS
> WeeWx v4.1.1 using setup.py
> gw1000-0.1.0b11
> sqlite db
> Seasons skin
> Ecowitt GW1000 WiFi Gateway
> 1 Outdoor Temp Sensor
> 1 Indoor Temp Sensor
> 5 Soil Moisture Sensors (temporarily 5th sensor is broken while waiting 
> for replacement)  
>
> Out of the box everything is showing up in the Seasons' report except my 
> soil moisture sensors. I do have data for the first 4 soil moisture sensors 
> in the sqlite db, but nothing for 5th one.  And I can see there is no entry 
> in the db for SoilMoisture sensors 5-8. So begins my adventure of learning 
> more about this awesome project called WeeWx.
>
> So I am thinking I have at least 3 tasks.
>
> First I need to extend the db to accommodate SoilMoisture sensors 5-8?
> For this task do I extend the schema by modifying the wview_extended.py 
> and the wview.py to include these extra sensors in the db? Or is the better 
> approach to use something like adding a new type to the database as 
> described in the Customization Guide?
>
> Second modify the reporting mechanism to show SoilMoisture in my Seasons' 
> report.
> 

[weewx-user] Re: GW1000 output and database

[gjr80]

try [[field_map]] instead of [[field map]]. If that does not work edit 
weewx.conf, set debug = 1, save weewx.conf and then restart WeeWX. Let 
WeeWX run for five minutes or so then post a log extract from when you 
restarted WeeWX through until the five minutes elapsed. post the log 
extract here.

Gary

On Friday, 21 August 2020 10:12:52 UTC+10, Timothy Buchanan wrote:
>
> OK, I placed this at the end of weewx.conf:
>
> # Options for extension 'GW1000'
> [GW1000]
> driver = user.gw1000
> [[field map]]
> extraTemp2  = intemp
> extraHumid2  = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1
>
> Result is the same as before; the first two lines produce null values in 
> the database, and the latter three appear in the correct fields. In fact, 
> it doesn't seem to matter what I put in this file. For example:
>
>
> # Options for extension 'GW1000'
> [GW1000]
> driver = user.gw1000
> [[field map]]
> extraTemp2  = intemp
> extraHumid2  = inhumid
> extraTemp1 = foobar1
> extraHumid1 = foobar2
> soilMoist1 = foobar3
>
> produces the same results! The first two lines give nulls; foobar lines 
> work. Is this the correct format and location for a field map?
>
> On Thursday, August 20, 2020 at 2:41:03 PM UTC-6 gjr80 wrote:
>
>> Thanks, now I understand. You have the right approach but unfortunately 
>> the execution is not quite correct. Did you run the driver directly with 
>> the —live-data command line option? The output will detail all of the 
>> available GW1000 ‘fields’ and their current values. Those field names are 
>> what should be used on the right hand side of the = in the field map 
>> entries. You will notice the GW1000 ‘fields’ are all in lowercase. So you 
>> should be using:
>>
>> extraTemp2 = intemp
>>
>> Likewise extraHumid2 and soilMoist1. Your extraTemp1 mapping should be:
>>
>> extraTemp1 = temp1
>>
>> Likewise extraHumid1.
>>
>> Gary
>>
>> On Friday, 21 August 2020 at 05:41:47 UTC+10 timothye...@gmail.com wrote:
>>
>>> Thanks for the detailed reply; I'll try to be more clear. I have two 
>>> services running, as indicated by this line:
>>>
>>> data_services = user.bme280wx.Bme280wx, user.gw1000.Gw1000Service
>>>
>>> The first service is an i2c sensor providing temp/humidity at the 
>>> raspberry pi. It's options are so:
>>>
>>> [Bme280wx]
>>> temperature_must_have = ""
>>> humidityKeys = inHumidity
>>> pressureKeys = ""
>>> pressure_must_have = ""
>>> i2c_port = 1
>>> humidity_must_have = ""
>>> i2c_address = 0x76
>>> usUnits = US
>>> temperatureKeys = inTemp
>>>
>>> The sensor data are humidityKeys and temperatureKeys and they are mapped 
>>> to inHumidity and inTemp. This service runs and reports properly; where my 
>>> skin uses inTemp the data from the sensor is displayed.
>>>
>>> The GW1000 options are currently set so, following the instructions in 
>>> your reply:
>>>
>>>
>>> [GW1000]
>>> driver = user.gw1000
>>> [[field map]]
>>> extraTemp2  = inTemp
>>> extraHumid2  = inHumidity
>>> extraTemp1 = extraTemp1
>>> extraHumid1 = extraHumid1
>>> soilMoist1 = soilMoist1
>>>
>>> Three of the fields provided by the GW1000 are the same in the database 
>>> (the latter three), and they are reporting correctly. I want the GW1000 
>>> fields inTemp and inHumidity to map to the weewx database fields extraTemp2 
>>> and extraHumid2. That is not working with the field map as shown. Have I 
>>> missed something?
>>>
>>>
>>> On Wednesday, August 19, 2020 at 6:03:58 PM UTC-6 gjr80 wrote:
>>>
 Hi,

 I think we might need a bit of clarification as to what it is you are 
 trying to do. You say "inTemp is being used by another service", do you 
 mean that WeeWX field inTemp is being *provided* by another 
 service/driver (which has consequences for running the  GW1000 driver as 
 as 
 service) or do you mean WeeWX field inTemp is being *used* by another 
 service (which has no consequences for the GW1000 driver when run as a 
 service). Does the same apply for inHumidity? When you ran the GW1000 
 driver directly with --test-service there was no extraTemp2 or 
 extraHumid2 fields and your field map does not map anything to these 
 fields so I would expect extraTemp2 and extraHumid2 to show as N/A in 
 any reports.

 Perhaps you have a misunderstanding re the field map. The field map 
 maps GW000 'fields' to WeeWX fields. The GW1000 driver uses a default 
 field 
 map. The default field map can be altered in two ways; you can replace the 
 entire default field map by defining your own field map using a 
 [[field_map]] stanza, or you can alter the default field map by 
 listing changes to the default field map in a [[field_map_extensions]] 
 stanza. It is not clear if you were attempting one of these approaches as 
 you have no [[ ]] level stanza in the config extra you posted. Also 
 when defining a field map entry the format

[weewx-user] Re: GW1000 output and database

[Timothy Buchanan]

OK, I placed this at the end of weewx.conf:

# Options for extension 'GW1000'
[GW1000]
driver = user.gw1000
[[field map]]
extraTemp2  = intemp
extraHumid2  = inhumid
extraTemp1 = temp1
extraHumid1 = humid1
soilMoist1 = soilmoist1

Result is the same as before; the first two lines produce null values in 
the database, and the latter three appear in the correct fields. In fact, 
it doesn't seem to matter what I put in this file. For example:


# Options for extension 'GW1000'
[GW1000]
driver = user.gw1000
[[field map]]
extraTemp2  = intemp
extraHumid2  = inhumid
extraTemp1 = foobar1
extraHumid1 = foobar2
soilMoist1 = foobar3

produces the same results! The first two lines give nulls; foobar lines 
work. Is this the correct format and location for a field map?

On Thursday, August 20, 2020 at 2:41:03 PM UTC-6 gjr80 wrote:

> Thanks, now I understand. You have the right approach but unfortunately 
> the execution is not quite correct. Did you run the driver directly with 
> the —live-data command line option? The output will detail all of the 
> available GW1000 ‘fields’ and their current values. Those field names are 
> what should be used on the right hand side of the = in the field map 
> entries. You will notice the GW1000 ‘fields’ are all in lowercase. So you 
> should be using:
>
> extraTemp2 = intemp
>
> Likewise extraHumid2 and soilMoist1. Your extraTemp1 mapping should be:
>
> extraTemp1 = temp1
>
> Likewise extraHumid1.
>
> Gary
>
> On Friday, 21 August 2020 at 05:41:47 UTC+10 timothye...@gmail.com wrote:
>
>> Thanks for the detailed reply; I'll try to be more clear. I have two 
>> services running, as indicated by this line:
>>
>> data_services = user.bme280wx.Bme280wx, user.gw1000.Gw1000Service
>>
>> The first service is an i2c sensor providing temp/humidity at the 
>> raspberry pi. It's options are so:
>>
>> [Bme280wx]
>> temperature_must_have = ""
>> humidityKeys = inHumidity
>> pressureKeys = ""
>> pressure_must_have = ""
>> i2c_port = 1
>> humidity_must_have = ""
>> i2c_address = 0x76
>> usUnits = US
>> temperatureKeys = inTemp
>>
>> The sensor data are humidityKeys and temperatureKeys and they are mapped 
>> to inHumidity and inTemp. This service runs and reports properly; where my 
>> skin uses inTemp the data from the sensor is displayed.
>>
>> The GW1000 options are currently set so, following the instructions in 
>> your reply:
>>
>>
>> [GW1000]
>> driver = user.gw1000
>> [[field map]]
>> extraTemp2  = inTemp
>> extraHumid2  = inHumidity
>> extraTemp1 = extraTemp1
>> extraHumid1 = extraHumid1
>> soilMoist1 = soilMoist1
>>
>> Three of the fields provided by the GW1000 are the same in the database 
>> (the latter three), and they are reporting correctly. I want the GW1000 
>> fields inTemp and inHumidity to map to the weewx database fields extraTemp2 
>> and extraHumid2. That is not working with the field map as shown. Have I 
>> missed something?
>>
>>
>> On Wednesday, August 19, 2020 at 6:03:58 PM UTC-6 gjr80 wrote:
>>
>>> Hi,
>>>
>>> I think we might need a bit of clarification as to what it is you are 
>>> trying to do. You say "inTemp is being used by another service", do you 
>>> mean that WeeWX field inTemp is being *provided* by another 
>>> service/driver (which has consequences for running the  GW1000 driver as as 
>>> service) or do you mean WeeWX field inTemp is being *used* by another 
>>> service (which has no consequences for the GW1000 driver when run as a 
>>> service). Does the same apply for inHumidity? When you ran the GW1000 
>>> driver directly with --test-service there was no extraTemp2 or 
>>> extraHumid2 fields and your field map does not map anything to these 
>>> fields so I would expect extraTemp2 and extraHumid2 to show as N/A in 
>>> any reports.
>>>
>>> Perhaps you have a misunderstanding re the field map. The field map maps 
>>> GW000 'fields' to WeeWX fields. The GW1000 driver uses a default field map. 
>>> The default field map can be altered in two ways; you can replace the 
>>> entire default field map by defining your own field map using a 
>>> [[field_map]] stanza, or you can alter the default field map by listing 
>>> changes to the default field map in a [[field_map_extensions]] stanza. 
>>> It is not clear if you were attempting one of these approaches as you have 
>>> no [[ ]] level stanza in the config extra you posted. Also when 
>>> defining a field map entry the format is:
>>>
>>> WeeWX field name = GW1000 field name
>>>
>>> where:
>>> GW1000 field name is the name of the GW1000 'field' that you 
>>> wish to map 
>>> WeeWX field name is the WeeWX field name you wish to contain 
>>> the data from the GW1000 'field' concerned. The WeeWX field name is the the 
>>> field name you will use in reports etc
>>>
>>> You can see what fields your GW1000 emits by running the GW1000 driver 
>>> directly with the --live-data command line option (the fields shown 
>>> when running t

Re: [weewx-user] Decimal Place Changes

[Tom Keffer]

The types WindSpeed2Avg and WindGust10Avg don't exist in WeeWX, so, unless
you attached them to a unit group, they will use default formatting, which
is "%f", the Python generic formatting for floating point numbers. That
hasn't changed since v2.5.0, which came out seven years ago.

To give them a default formatting, they must be attached to a unit group.
In this case, group_speed would probably be most appropriate. Put this
somewhere where it will get run before use (user/extensions.py will do):

import weewx.units
weewx.units.obs_group_dict['WindSpeed2Avg'] = 'group_speed'
weewx.units.obs_group_dict['WindSpeed10Avg'] = 'group_speed'

I don't have an explanation for why formatting for wind direction would
have changed. I assume you are talking about the tag $current.windDir? The
unit for wind direction is "degree_compass". Its formatting is set in
weewx.conf:

[StdReports]
  ...
  [[Defaults]]
...
[[[Units]]]
  ...
  StringFormats
...
degree_compass = "%.0f"

If you have formatting issues, you would do well to read the section
*Formatting
options * in
the Customizing Guide.

-tk

On Thu, Aug 20, 2020 at 12:33 PM 'Ron Walker' via weewx-user <
weewx-user@googlegroups.com> wrote:

>
> Hi All,
>
> I am running Weewx 4.1.1 on a Raspberry Pi Model 3.  I am using an Arduino
> microcontroller to capture sensor data and a python program on the Pi to
> capture the data and write it to a csv file.  I am using the fileparse to
> read that file to pass data to Weewx.
>
> While my Weewx version was still 3.9.1, I added two observations,
> WindSpeed2Avg and WindGust10Avg. The weather station is located at our RC
> flying field and since we upload the data to a web server, wind and gust
> observations are as old as 5 minutes.  The averages help to determine
> actual conditions over the average times.  It was displayed properly with
> no decimal places as was the wind direction.
>
> Since upgrading to version 4.1.1 those observations now display with 6
> decimal places!!  The wind direction degrees also display this way.  Can
> anyone direct me to where I can change this back to displaying no decimal
> places?
>
> Thanks in advance!!
>
> --
> 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/be00c4a2-71ca-46b1-aeb4-5a093531cfe5n%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/CAPq0zECGy3BM7XENU_%2BY9nD81R-WyaJuApksq_6-5G_jgS7t8Q%40mail.gmail.com.

[weewx-user] Re: next-gen WeatherFlow kickstarter

[vince]

On Thursday, August 20, 2020 at 8:13:47 AM UTC-7, jerry.si...@gmail.com 
wrote:
>
> I've had my Tempest up for about 6 weeks ago and loving it. Is there a way 
> to get the data into WEEWX ?


I'd try to google "WeatherFlow weewx" and see what it returns.

-- 
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/086cdf81-841e-440e-ac19-0c3b42082152o%40googlegroups.com.

[weewx-user] Re: Decimal Place Changes

[vince]

http://weewx.com/docs/customizing.htm#Formatting_examples

-- 
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/b48b0b20-99ae-4536-9fd0-4c5b43156a0bo%40googlegroups.com.

[weewx-user] Re: GW1000 output and database

[gjr80]

Thanks, now I understand. You have the right approach but unfortunately the 
execution is not quite correct. Did you run the driver directly with the 
—live-data command line option? The output will detail all of the available 
GW1000 ‘fields’ and their current values. Those field names are what should 
be used on the right hand side of the = in the field map entries. You will 
notice the GW1000 ‘fields’ are all in lowercase. So you should be using:

extraTemp2 = intemp

Likewise extraHumid2 and soilMoist1. Your extraTemp1 mapping should be:

extraTemp1 = temp1

Likewise extraHumid1.

Gary

On Friday, 21 August 2020 at 05:41:47 UTC+10 timothye...@gmail.com wrote:

> Thanks for the detailed reply; I'll try to be more clear. I have two 
> services running, as indicated by this line:
>
> data_services = user.bme280wx.Bme280wx, user.gw1000.Gw1000Service
>
> The first service is an i2c sensor providing temp/humidity at the 
> raspberry pi. It's options are so:
>
> [Bme280wx]
> temperature_must_have = ""
> humidityKeys = inHumidity
> pressureKeys = ""
> pressure_must_have = ""
> i2c_port = 1
> humidity_must_have = ""
> i2c_address = 0x76
> usUnits = US
> temperatureKeys = inTemp
>
> The sensor data are humidityKeys and temperatureKeys and they are mapped 
> to inHumidity and inTemp. This service runs and reports properly; where my 
> skin uses inTemp the data from the sensor is displayed.
>
> The GW1000 options are currently set so, following the instructions in 
> your reply:
>
>
> [GW1000]
> driver = user.gw1000
> [[field map]]
> extraTemp2  = inTemp
> extraHumid2  = inHumidity
> extraTemp1 = extraTemp1
> extraHumid1 = extraHumid1
> soilMoist1 = soilMoist1
>
> Three of the fields provided by the GW1000 are the same in the database 
> (the latter three), and they are reporting correctly. I want the GW1000 
> fields inTemp and inHumidity to map to the weewx database fields extraTemp2 
> and extraHumid2. That is not working with the field map as shown. Have I 
> missed something?
>
>
> On Wednesday, August 19, 2020 at 6:03:58 PM UTC-6 gjr80 wrote:
>
>> Hi,
>>
>> I think we might need a bit of clarification as to what it is you are 
>> trying to do. You say "inTemp is being used by another service", do you 
>> mean that WeeWX field inTemp is being *provided* by another 
>> service/driver (which has consequences for running the  GW1000 driver as as 
>> service) or do you mean WeeWX field inTemp is being *used* by another 
>> service (which has no consequences for the GW1000 driver when run as a 
>> service). Does the same apply for inHumidity? When you ran the GW1000 
>> driver directly with --test-service there was no extraTemp2 or 
>> extraHumid2 fields and your field map does not map anything to these 
>> fields so I would expect extraTemp2 and extraHumid2 to show as N/A in 
>> any reports.
>>
>> Perhaps you have a misunderstanding re the field map. The field map maps 
>> GW000 'fields' to WeeWX fields. The GW1000 driver uses a default field map. 
>> The default field map can be altered in two ways; you can replace the 
>> entire default field map by defining your own field map using a 
>> [[field_map]] stanza, or you can alter the default field map by listing 
>> changes to the default field map in a [[field_map_extensions]] stanza. 
>> It is not clear if you were attempting one of these approaches as you have 
>> no [[ ]] level stanza in the config extra you posted. Also when defining 
>> a field map entry the format is:
>>
>> WeeWX field name = GW1000 field name
>>
>> where:
>> GW1000 field name is the name of the GW1000 'field' that you 
>> wish to map 
>> WeeWX field name is the WeeWX field name you wish to contain the 
>> data from the GW1000 'field' concerned. The WeeWX field name is the the 
>> field name you will use in reports etc
>>
>> You can see what fields your GW1000 emits by running the GW1000 driver 
>> directly with the --live-data command line option (the fields shown when 
>> running the driver directly using the --test-service or --test-driver 
>> command line options are WeeWX field names, ie they have been mapped using 
>> the field map, fields shown using --live-data are GW1000 'fields' ie 
>> they are unmapped).
>>
>> Gary
>>
>> On Thursday, 20 August 2020 08:15:29 UTC+10, Timothy Buchanan wrote:
>>>
>>> I installed GW1000 as a service and the test-service command gives this 
>>> output:
>>>
>>> dateTime: 1597861672, dummyTemp: 96.3, extraHumid1: 26, extraTemp1: 
>>> 85.1, inHumidity: 33, inTemp: 75.74, pressure: 22.2360805875, relbarometer: 
>>> 753.0, soilMoist1: 15, usUnits: 1, wh31_ch1_batt: 0, wh51_ch1_batt: 0
>>>
>>> In weewx.conf, I put this list of options:
>>>
>>> [GW1000]
>>> driver = user.gw1000
>>> inTemp = extraTemp2
>>> inHumidity = extraHumid2
>>> extraTemp1 = extraTemp1
>>> extraHumid1 = extraHumid1
>>> soilMoist1 = soilMoist1
>>> pressure = ""
>>>
>>> I chose these because inTemp is being used by

Re: [weewx-user] MacOS syntax error on launch

[Chris Alemany]

Yup seeing that now. I actually went and fixed the syntax errors and after 
upgrading the forecast module, it looks like things are functional again.

On Thursday, August 20, 2020 at 12:50:55 PM UTC-7 tke...@gmail.com wrote:

> Your copy of the crt extension has not been ported to Python 3. Either 
> upgrade the extension, or use Python 2.
>
> On Thu, Aug 20, 2020 at 11:50 AM Chris Alemany  wrote:
>
>> Hi all,
>>
>> Trying to upgrade from 3.9.2.
>>
>> Have python3 installed and everything is in /Users/Shared/weewx as 
>> normal.  I get the below message when I run the daemon after installation. 
>> I do have a number of extensions in play as well including crt.
>>
>> Cheers
>> Chris
>>
>> Traceback (most recent call last):
>>
>>   File "./bin/weewxd", line 261, in 
>>
>> main()
>>
>>   File "./bin/weewxd", line 148, in main
>>
>> engine = weewx.engine.StdEngine(config_dict)
>>
>>   File "/Users/Shared/weewx/bin/weewx/engine.py", line 75, in __init__
>>
>> self.loadServices(config_dict)
>>
>>   File "/Users/Shared/weewx/bin/weewx/engine.py", line 138, in 
>> loadServices
>>
>> obj = weeutil.weeutil.get_object(svc)(self,config_dict)
>>
>>   File "/Users/Shared/weewx/bin/weeutil/weeutil.py", line 1093, in 
>> get_object
>>
>> mod = __import__(module)
>>
>>   File "/Users/Shared/weewx/bin/user/crt.py", line 376
>>
>> except Exception, e:
>>
>> ^
>>
>> SyntaxError: invalid syntax
>>
>> -- 
>> 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/7f6f42da-5420-46a4-aaeb-c720a13f1900n%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/eba0743d-dab9-4760-8790-cbb4261f0eecn%40googlegroups.com.

Re: [weewx-user] MacOS syntax error on launch

[Tom Keffer]

Your copy of the crt extension has not been ported to Python 3. Either
upgrade the extension, or use Python 2.

On Thu, Aug 20, 2020 at 11:50 AM Chris Alemany  wrote:

> Hi all,
>
> Trying to upgrade from 3.9.2.
>
> Have python3 installed and everything is in /Users/Shared/weewx as
> normal.  I get the below message when I run the daemon after installation.
> I do have a number of extensions in play as well including crt.
>
> Cheers
> Chris
>
> Traceback (most recent call last):
>
>   File "./bin/weewxd", line 261, in 
>
> main()
>
>   File "./bin/weewxd", line 148, in main
>
> engine = weewx.engine.StdEngine(config_dict)
>
>   File "/Users/Shared/weewx/bin/weewx/engine.py", line 75, in __init__
>
> self.loadServices(config_dict)
>
>   File "/Users/Shared/weewx/bin/weewx/engine.py", line 138, in loadServices
>
> obj = weeutil.weeutil.get_object(svc)(self,config_dict)
>
>   File "/Users/Shared/weewx/bin/weeutil/weeutil.py", line 1093, in
> get_object
>
> mod = __import__(module)
>
>   File "/Users/Shared/weewx/bin/user/crt.py", line 376
>
> except Exception, e:
>
> ^
>
> SyntaxError: invalid syntax
>
> --
> 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/7f6f42da-5420-46a4-aaeb-c720a13f1900n%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/CAPq0zEAdkdx0UDwq%3Dwpt8LxkqsRsR7TRF2xwaZEY%2BG3_ww7SeQ%40mail.gmail.com.

[weewx-user] Re: GW1000 output and database

[Timothy Buchanan]

Thanks for the detailed reply; I'll try to be more clear. I have two 
services running, as indicated by this line:

data_services = user.bme280wx.Bme280wx, user.gw1000.Gw1000Service

The first service is an i2c sensor providing temp/humidity at the raspberry 
pi. It's options are so:

[Bme280wx]
temperature_must_have = ""
humidityKeys = inHumidity
pressureKeys = ""
pressure_must_have = ""
i2c_port = 1
humidity_must_have = ""
i2c_address = 0x76
usUnits = US
temperatureKeys = inTemp

The sensor data are humidityKeys and temperatureKeys and they are mapped to 
inHumidity and inTemp. This service runs and reports properly; where my 
skin uses inTemp the data from the sensor is displayed.

The GW1000 options are currently set so, following the instructions in your 
reply:


[GW1000]
driver = user.gw1000
[[field map]]
extraTemp2  = inTemp
extraHumid2  = inHumidity
extraTemp1 = extraTemp1
extraHumid1 = extraHumid1
soilMoist1 = soilMoist1

Three of the fields provided by the GW1000 are the same in the database 
(the latter three), and they are reporting correctly. I want the GW1000 
fields inTemp and inHumidity to map to the weewx database fields extraTemp2 
and extraHumid2. That is not working with the field map as shown. Have I 
missed something?


On Wednesday, August 19, 2020 at 6:03:58 PM UTC-6 gjr80 wrote:

> Hi,
>
> I think we might need a bit of clarification as to what it is you are 
> trying to do. You say "inTemp is being used by another service", do you 
> mean that WeeWX field inTemp is being *provided* by another 
> service/driver (which has consequences for running the  GW1000 driver as as 
> service) or do you mean WeeWX field inTemp is being *used* by another 
> service (which has no consequences for the GW1000 driver when run as a 
> service). Does the same apply for inHumidity? When you ran the GW1000 
> driver directly with --test-service there was no extraTemp2 or extraHumid2 
> fields and your field map does not map anything to these fields so I would 
> expect extraTemp2 and extraHumid2 to show as N/A in any reports.
>
> Perhaps you have a misunderstanding re the field map. The field map maps 
> GW000 'fields' to WeeWX fields. The GW1000 driver uses a default field map. 
> The default field map can be altered in two ways; you can replace the 
> entire default field map by defining your own field map using a 
> [[field_map]] stanza, or you can alter the default field map by listing 
> changes to the default field map in a [[field_map_extensions]] stanza. It 
> is not clear if you were attempting one of these approaches as you have no [[ 
> ]] level stanza in the config extra you posted. Also when defining a 
> field map entry the format is:
>
> WeeWX field name = GW1000 field name
>
> where:
> GW1000 field name is the name of the GW1000 'field' that you wish 
> to map 
> WeeWX field name is the WeeWX field name you wish to contain the 
> data from the GW1000 'field' concerned. The WeeWX field name is the the 
> field name you will use in reports etc
>
> You can see what fields your GW1000 emits by running the GW1000 driver 
> directly with the --live-data command line option (the fields shown when 
> running the driver directly using the --test-service or --test-driver 
> command line options are WeeWX field names, ie they have been mapped using 
> the field map, fields shown using --live-data are GW1000 'fields' ie they 
> are unmapped).
>
> Gary
>
> On Thursday, 20 August 2020 08:15:29 UTC+10, Timothy Buchanan wrote:
>>
>> I installed GW1000 as a service and the test-service command gives this 
>> output:
>>
>> dateTime: 1597861672, dummyTemp: 96.3, extraHumid1: 26, extraTemp1: 85.1, 
>> inHumidity: 33, inTemp: 75.74, pressure: 22.2360805875, relbarometer: 
>> 753.0, soilMoist1: 15, usUnits: 1, wh31_ch1_batt: 0, wh51_ch1_batt: 0
>>
>> In weewx.conf, I put this list of options:
>>
>> [GW1000]
>> driver = user.gw1000
>> inTemp = extraTemp2
>> inHumidity = extraHumid2
>> extraTemp1 = extraTemp1
>> extraHumid1 = extraHumid1
>> soilMoist1 = soilMoist1
>> pressure = ""
>>
>> I chose these because inTemp is being used by another service. When I 
>> tried to use the data in my skin (modified exfoliation), I found that 
>> extraTemp2 and extraHumid2 are shown as NA. The other values are displayed. 
>> What did I do wrong here? Thanks for any help.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9c04de5f-49b4-47f0-989f-7afd2f86fe0cn%40googlegroups.com.

[weewx-user] Decimal Place Changes

['Ron Walker' via weewx-user]

Hi All,

I am running Weewx 4.1.1 on a Raspberry Pi Model 3.  I am using an Arduino 
microcontroller to capture sensor data and a python program on the Pi to 
capture the data and write it to a csv file.  I am using the fileparse to 
read that file to pass data to Weewx.

While my Weewx version was still 3.9.1, I added two observations, 
WindSpeed2Avg and WindGust10Avg. The weather station is located at our RC 
flying field and since we upload the data to a web server, wind and gust 
observations are as old as 5 minutes.  The averages help to determine 
actual conditions over the average times.  It was displayed properly with 
no decimal places as was the wind direction.

Since upgrading to version 4.1.1 those observations now display with 6 
decimal places!!  The wind direction degrees also display this way.  Can 
anyone direct me to where I can change this back to displaying no decimal 
places?

Thanks in advance!!

-- 
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/be00c4a2-71ca-46b1-aeb4-5a093531cfe5n%40googlegroups.com.

[weewx-user] MacOS syntax error on launch

[Chris Alemany]

Hi all,

Trying to upgrade from 3.9.2.

Have python3 installed and everything is in /Users/Shared/weewx as normal. 
 I get the below message when I run the daemon after installation. I do 
have a number of extensions in play as well including crt.

Cheers
Chris

Traceback (most recent call last):

  File "./bin/weewxd", line 261, in 

main()

  File "./bin/weewxd", line 148, in main

engine = weewx.engine.StdEngine(config_dict)

  File "/Users/Shared/weewx/bin/weewx/engine.py", line 75, in __init__

self.loadServices(config_dict)

  File "/Users/Shared/weewx/bin/weewx/engine.py", line 138, in loadServices

obj = weeutil.weeutil.get_object(svc)(self,config_dict)

  File "/Users/Shared/weewx/bin/weeutil/weeutil.py", line 1093, in 
get_object

mod = __import__(module)

  File "/Users/Shared/weewx/bin/user/crt.py", line 376

except Exception, e:

^

SyntaxError: invalid syntax

-- 
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/7f6f42da-5420-46a4-aaeb-c720a13f1900n%40googlegroups.com.

Re: [weewx-user] wsum and sumtime are different after upgrading to 4.1.1

[David Geiger]

That fixed it, thank you!

On Thursday, August 20, 2020 at 8:03:01 AM UTC-4 tke...@gmail.com wrote:

> Daily summaries created by versions earlier than v3.7.0 did not weight the 
> sums with the length archive interval. See issue #61 
> . Summaries created by v3.7.0 
> or later, do weight the sums. You can tell the difference  between the two 
> types of summaries by examining some metadata. 
>
> *echo "select value from archive_day__metadata where name='Version'" | 
> sqlite3 weewx.sdb*
>
> The intention is that the daily summaries are either one or the other: the 
> sums are either not weighted (version=1), or they are weighted (version=2). 
> I don't know why your database would be a little of each. It should not be.
>
> This can all be fixed by dropping 
> , then 
> rebuilding 
> , the 
> daily summaries. The utility wee_database can do this.
>
> -tk
>
> On Wed, Aug 19, 2020 at 5:57 PM David Geiger  
> wrote:
>
>> I have been a long time user of weewx, great software!
>>
>> I recently updated from 3.9.2 to 4.1.1. After the update, I noticed that 
>> my average yearly outTemp was different. I took a look in the database and 
>> noticed that after the upgrade, my wsum and sumtime are a factor of 300 
>> times greater than before the upgrade. Before, sumtime = 288 each day, 
>> after the upgrade it = 86400 each day. I noticed it in the 
>> archive_day_outTemp table. The average for the day is still correct, but 
>> when you run for a span that includes 3.9.2 and 4.1.1, the 4.1.1 far out 
>> weighs the 3.9.2.
>>
>> I have my archive interval set to 300. It was not changed between 3.9.2 
>> and 4.1.1
>>
>> -- 
>> 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/b9f624ae-fcb7-40ab-bada-263a3d665300n%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/232bd847-abd2-4b8b-85fc-98933063b15an%40googlegroups.com.

[weewx-user] WH1080 sender / receiver appears to have died, suggestions?

[James Muirhead]

My WH1080 sender / receiver appears to have died. 

The battery low indicator had been on for some time and died about 0130 
this morning.

I changed out the batteries in the sender today and it does not want to 
communicate with the receiver now. LED in the sender comes on and receiver 
appears normal.

I've reset receiver and sender in both orders and left for an hour, etc, 
etc. WeeWX WebUI shows no signal (but I don't know how this is generated).

The communication icon on receiver comes up sporadically for a minute at 
start and for quarter of a second once in a while.

I'm gonna take apart the sender tomorrow and give everything a good clean, 
see if it helps.

Has anyone got a suggestion, other than "buy a new weather station"?

Thanks.

PS - WeeWX is working perfectly. But I have WeeWX installed on an Orange Pi 
PC (1.3GHz Quad, 1GB RAM). Shout if you want anymore information.

-- 
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/99c4797c-433e-4e5b-9237-84464e7ca107n%40googlegroups.com.

[weewx-user] Re: next-gen WeatherFlow kickstarter

[Xant]

https://github.com/captain-coredump/weatherflow-udp


On Thursday, August 20, 2020 at 11:13:47 AM UTC-4, jerry.si...@gmail.com 
wrote:
>
> I've had my Tempest up for about 6 weeks ago and loving it. Is there a way 
> to get the data into WEEWX ?
>
> Jerry
>
> On Tuesday, November 26, 2019 at 2:08:22 PM UTC-5 Xant wrote:
>
>> Just to post my positive feedback for WF here.
>>
>> 1) Cost/Performance
>>
>> Mid-range system that provides Temperature, Humidity, Barometric 
>> Pressure, Wind speed/direction, Rainfall, Illuminance, UV, Lightning 
>> count/distance.
>>
>> Most competitors does not provide all those features at this price range.
>>
>>
>> 2) Extra notable features
>>
>> No moving parts! Sonic wind sensor and haptic rain sensor (those features 
>> by itself, only available at high-end cost systems).
>>
>> Sure, there is debate regarding the Haptic rain sensor, especially for 
>> those that requires much accuracy in this variable. So, this to be 
>> considered.
>>
>> Reporting interval: "sonic anemometer actually samples wind every 1sec, 
>> then reports the 3sec average to the hub. The hub makes the 3sec data 
>> immediately available to the app, via UDP multicast, and via BLE spec". 
>> That is of upmost importance regarding MQTT updates (most systems have much 
>> longer interval; Davis Instruments average 2.5sec).
>>
>>
>> 3) Current vs New Model
>>
>> Interesting enough, as posted in their own website: "Why did you separate 
>> a weather station into two devices? Better siting, better data. In order to 
>> accurately measure wind, rain, and UV you need to place the SKY in an open 
>> area with a clear view of the sky above (like on your roof). As you can 
>> imagine, placing a temperature sensor in the full sun presents issues. 
>> That’s why we made the AIR a separate device to be placed in the shade — 
>> more accurate data."
>>
>> Not too longer afterwards, they "changing their minds and design".
>>
>> Sure new is new, and the new system may provide updated features. But 
>> yet, I'm still stand for the 2 units systems (as posted in their own 
>> words), and the embedded solar "round window" seems not in line with the 
>> clean looking of the original model.
>>
>>
>> 4) Support
>>
>> Just recently, my couple of months unit was not been charged by the solar 
>> panel. Their is no live chat in WF support, but they were very responsive 
>> through email and after some quick external monitoring, they immediately 
>> replaced the battery/solar panel unit (no questions ask).
>>
>>  
>>
>>  X
>>
>>

-- 
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/18326231-6456-4e98-8a89-924a843ff32co%40googlegroups.com.

[weewx-user] Re: next-gen WeatherFlow kickstarter

[jerry.si...@gmail.com]

I've had my Tempest up for about 6 weeks ago and loving it. Is there a way 
to get the data into WEEWX ?

Jerry

On Tuesday, November 26, 2019 at 2:08:22 PM UTC-5 Xant wrote:

> Just to post my positive feedback for WF here.
>
> 1) Cost/Performance
>
> Mid-range system that provides Temperature, Humidity, Barometric Pressure, 
> Wind speed/direction, Rainfall, Illuminance, UV, Lightning count/distance.
>
> Most competitors does not provide all those features at this price range.
>
>
> 2) Extra notable features
>
> No moving parts! Sonic wind sensor and haptic rain sensor (those features 
> by itself, only available at high-end cost systems).
>
> Sure, there is debate regarding the Haptic rain sensor, especially for 
> those that requires much accuracy in this variable. So, this to be 
> considered.
>
> Reporting interval: "sonic anemometer actually samples wind every 1sec, 
> then reports the 3sec average to the hub. The hub makes the 3sec data 
> immediately available to the app, via UDP multicast, and via BLE spec". 
> That is of upmost importance regarding MQTT updates (most systems have much 
> longer interval; Davis Instruments average 2.5sec).
>
>
> 3) Current vs New Model
>
> Interesting enough, as posted in their own website: "Why did you separate 
> a weather station into two devices? Better siting, better data. In order to 
> accurately measure wind, rain, and UV you need to place the SKY in an open 
> area with a clear view of the sky above (like on your roof). As you can 
> imagine, placing a temperature sensor in the full sun presents issues. 
> That’s why we made the AIR a separate device to be placed in the shade — 
> more accurate data."
>
> Not too longer afterwards, they "changing their minds and design".
>
> Sure new is new, and the new system may provide updated features. But yet, 
> I'm still stand for the 2 units systems (as posted in their own words), and 
> the embedded solar "round window" seems not in line with the clean looking 
> of the original model.
>
>
> 4) Support
>
> Just recently, my couple of months unit was not been charged by the solar 
> panel. Their is no live chat in WF support, but they were very responsive 
> through email and after some quick external monitoring, they immediately 
> replaced the battery/solar panel unit (no questions ask).
>
>  
>
>  X
>
>

-- 
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/ae40808a-dbce-4211-9783-678d6169daefn%40googlegroups.com.

[weewx-user] Re: Replacement for WMR200 ?

[galfert]

Ecowitt or Froggit stations.
Just about any model from either of these with some minor exceptions... 
with the Ecowitt GW1000 or the Froggit DP1500. These are the same hardware. 
The DP1500 is a GW1000.


On Thursday, August 20, 2020 at 7:24:04 AM UTC-4, Invisible Man wrote:
>
>
> Hi,
> I've had a (Oregon Scientific) WMR200 weather station for years and been 
> very happy with it. Lately, I've been encountering several hardware issues 
> with it, and I fear it is perhaps going to be the end of it, soon or later.
> What replacement weather station would you recommend? I'm looking for 
> something below 500 euros, and of course supported by weewx. 
> Thanks,
> Axelle.
>

-- 
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/f714c592-0592-4472-9268-1e33f1b6e09bo%40googlegroups.com.

RE: [weewx-user] UnicodeDecodeError in database

[David Marshall]

Solved thanks. More stupid me I think – a clear case of RTFM!

Sent from Mail for Windows 10

From: Tom Keffer
Sent: 20 August 2020 14:07
To: David Marshall
Cc: weewx-user@googlegroups.com
Subject: Re: [weewx-user] UnicodeDecodeError in database

Stupid me. The answer is in how you are invoking wee_database. Any positional 
argument is interpreted as the path to weewx.conf, so wee_database is thinking 
that /home/weewx/archive/weewx.sdb is your configuration file, weewx.conf. 
Naturally, it being a sqlite database, it has all sorts of unusual byte 
sequences.

wee_database finds your database from the information in the configuration 
file, not from the command line. This way, it can work on MySQL databases, 
which do not use a single file. So, you want

wee_database --reconfigure /home/weewx/weewx.conf



On Thu, Aug 20, 2020 at 4:43 AM David Marshall  wrote:
1. Yes
2. Seemed to work ok
3. Syslog attached – but seems to me to be ok.
 
The problem only occurs when using wee_database -interestingly the offending 
byte has moved from position 26 to 31!
 
pi@raspberrypi:~ $ /home/weewx/bin/wee_database --reconfigure 
/home/weewx/archive/weewx.sdb
Traceback (most recent call last):
  File "/home/weewx/bin/wee_database", line 974, in 
    main()
  File "/home/weewx/bin/wee_database", line 128, in main
    config_path, config_dict = weecfg.read_config(options.config_path, args)
  File "/home/weewx/bin/weecfg/__init__.py", line 179, in read_config
    default_encoding='utf-8')
  File "/usr/lib/python3/dist-packages/configobj.py", line 1229, in __init__
    self._load(infile, configspec)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1287, in _load
    content = self._handle_bom(content)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1437, in _handle_bom
    return self._decode(infile, self.encoding)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1517, in _decode
    infile[i] = line.decode(encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf2 in position 31: 
invalid continuation byte
 
Sent from Mail for Windows 10
 
From: Tom Keffer
Sent: 20 August 2020 00:51
To: weewx-user
Subject: Re: [weewx-user] UnicodeDecodeError in database
 
I don't have any problem with either copy of weewx.conf that you sent to me. 
Things to try:
 
1. This is /home/weewx/weewx.conf, right?  
 
2. Try reading it directly:
 
python -c "import configobj; c=configobj.ConfigObj('/home/weewx/weewx.conf')"
 
3. Set debug=1 in weewx.conf, then try running weewxd, then send us the log. 
 
-tk
 
 
 
On Wed, Aug 19, 2020 at 7:19 AM David Marshall  wrote:
Hi Tom
 
1. Yes wee_database
2. Yes same path different  copies
3. No edits – in fact I tried not to change anything in the final install apart 
from setting it to simulator.
 
I attach the last version of weewx.conf, which is still producing the error.
 
David
 
Sent from Mail for Windows 10
 
From: Tom Keffer
Sent: 19 August 2020 15:59
To: weewx-user
Subject: Re: [weewx-user] UnicodeDecodeError in database
 
1. All these attempts were with running wee_database? Or, something else?
 
2. I assume all these different attempts used the same path, namely 
/home/weewx/weewx.conf. And, we're sure they used different copies (albeit, at 
the same path location)? 
 
3. It's hard to explain how fresh, untouched versions of weewx.conf are all 
getting the same error. Are you editing these copies before running?
 
Can you send me the offending weewx.conf to my personal email? tkeffer at 
gmail.com
 
-tk
 
On Wed, Aug 19, 2020 at 6:35 AM David Marshall  wrote:
Thanks Tom
 
Tried your code to show the offending line but nothing appears. Then tried a 
clean weewx.conf from the install folder but still the same error message. Then 
tried a full reinstall, but still the same error.
Then tried it with the the default database using simulator and still the same 
error - so you are right it is not my database. What next?

On Wednesday, August 19, 2020 at 2:51:31 PM UTC+2, Tom Keffer wrote:
The decode error is actually in your configuration file, weewx.conf, and not in 
the database.
 
Somehow, your copy of weewx.conf got corrupted. One of the lines has a 
character sequence that starts out as a utf-8 encoding, but the following byte 
is not what was expected. 
 
Unfortunately, the error does not tell you which line the bad character 
sequence is in, only that it is in byte position 26 of that line. Perhaps this 
will help (NOT TESTED):
 
od -x -A d weewx.conf | grep e0
 
This should print out the line and offending sequence.
 
-tk
 
 
 
On Wed, Aug 19, 2020 at 5:25 AM David Marshall  wrote:
Hi
 
Installed a fresh version of weewx 4.1.1 without problem using setup.py on a 
raspberry.
 
Transferred my existing sqlite database from weewx 3.9.1. It is big, about 3 
years of data. This worked fine.
 
But when I tried to use reconfigure I got the following error
 
pi@raspberrypi:~ $ /home/weewx/bin/wee_database --reconfigure 
/home/weewx/archive/weewx.sdb
Traceback (most 

Re: [weewx-user] UnicodeDecodeError in database

[Tom Keffer]

Stupid me. The answer is in how you are invoking wee_database. Any
positional argument is interpreted as the path to weewx.conf, so
wee_database is thinking that /home/weewx/archive/weewx.sdb is your
configuration file, weewx.conf. Naturally, it being a sqlite database, it
has all sorts of unusual byte sequences.

wee_database finds your database from the information in the configuration
file, not from the command line. This way, it can work on MySQL databases,
which do not use a single file. So, you want

*wee_database --reconfigure /home/weewx/weewx.conf*



On Thu, Aug 20, 2020 at 4:43 AM David Marshall 
wrote:

>
>1. Yes
>2. Seemed to work ok
>3. Syslog attached – but seems to me to be ok.
>
>
>
> The problem only occurs when using wee_database -interestingly the
> offending byte has moved from position 26 to 31!
>
>
>
> pi@raspberrypi:~ $ /home/weewx/bin/wee_database --reconfigure
> /home/weewx/archive/weewx.sdb
>
> Traceback (most recent call last):
>
>   File "/home/weewx/bin/wee_database", line 974, in 
>
> main()
>
>   File "/home/weewx/bin/wee_database", line 128, in main
>
> config_path, config_dict = weecfg.read_config(options.config_path,
> args)
>
>   File "/home/weewx/bin/weecfg/__init__.py", line 179, in read_config
>
> default_encoding='utf-8')
>
>   File "/usr/lib/python3/dist-packages/configobj.py", line 1229, in
> __init__
>
> self._load(infile, configspec)
>
>   File "/usr/lib/python3/dist-packages/configobj.py", line 1287, in _load
>
> content = self._handle_bom(content)
>
>   File "/usr/lib/python3/dist-packages/configobj.py", line 1437, in
> _handle_bom
>
> return self._decode(infile, self.encoding)
>
>   File "/usr/lib/python3/dist-packages/configobj.py", line 1517, in _decode
>
> infile[i] = line.decode(encoding)
>
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf2 in position 31:
> invalid continuation byte
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Tom Keffer 
> *Sent: *20 August 2020 00:51
> *To: *weewx-user 
> *Subject: *Re: [weewx-user] UnicodeDecodeError in database
>
>
>
> I don't have any problem with either copy of weewx.conf that you sent to
> me. Things to try:
>
>
>
> 1. This is /home/weewx/weewx.conf, right?
>
>
>
> 2. Try reading it directly:
>
>
>
> *python -c "import configobj;
> c=configobj.ConfigObj('/home/weewx/weewx.conf')"*
>
>
>
> 3. Set debug=1 in weewx.conf, then try running weewxd, then send us the
> log.
>
>
>
> -tk
>
>
>
>
>
>
>
> On Wed, Aug 19, 2020 at 7:19 AM David Marshall 
> wrote:
>
> Hi Tom
>
>
>
>1. Yes wee_database
>2. Yes same path different  copies
>3. No edits – in fact I tried not to change anything in the final
>install apart from setting it to simulator.
>
>
>
> I attach the last version of weewx.conf, which is still producing the
> error.
>
>
>
> David
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Tom Keffer 
> *Sent: *19 August 2020 15:59
> *To: *weewx-user 
> *Subject: *Re: [weewx-user] UnicodeDecodeError in database
>
>
>
> 1. All these attempts were with running wee_database? Or, something else?
>
>
>
> 2. I assume all these different attempts used the same path, namely
> /home/weewx/weewx.conf. And, we're sure they used different copies (albeit,
> at the same path location)?
>
>
>
> 3. It's hard to explain how fresh, untouched versions of weewx.conf are
> all getting the same error. Are you editing these copies before running?
>
>
>
> Can you send me the offending weewx.conf to my personal email? tkeffer at
> gmail.com
>
>
>
> -tk
>
>
>
> On Wed, Aug 19, 2020 at 6:35 AM David Marshall 
> wrote:
>
> Thanks Tom
>
>
>
> Tried your code to show the offending line but nothing appears. Then tried
> a clean weewx.conf from the install folder but still the same error
> message. Then tried a full reinstall, but still the same error.
>
> Then tried it with the the default database using simulator and still the
> same error - so you are right it is not my database. What next?
>
> On Wednesday, August 19, 2020 at 2:51:31 PM UTC+2, Tom Keffer wrote:
>
> The decode error is actually in your configuration file, weewx.conf, and
> not in the database.
>
>
>
> Somehow, your copy of weewx.conf got corrupted. One of the lines has a
> character sequence that starts out as a utf-8 encoding, but the following
> byte is not what was expected.
>
>
>
> Unfortunately, the error does not tell you which line the bad character
> sequence is in, only that it is in byte position 26 of that line. Perhaps
> this will help (NOT TESTED):
>
>
>
> *od -x -A d weewx.conf | grep e0*
>
>
>
> This should print out the line and offending sequence.
>
>
>
> -tk
>
>
>
>
>
>
>
> On Wed, Aug 19, 2020 at 5:25 AM David Marshall 
> wrote:
>
> Hi
>
>
>
> Installed a fresh version of weewx 4.1.1 without problem using setup.py on
> a raspberry.
>
>
>
> Transferred my existing sqlite database from weewx 3.

Re: [weewx-user] wsum and sumtime are different after upgrading to 4.1.1

[Tom Keffer]

Daily summaries created by versions earlier than v3.7.0 did not weight the
sums with the length archive interval. See issue #61
. Summaries created by v3.7.0 or
later, do weight the sums. You can tell the difference  between the two
types of summaries by examining some metadata.

*echo "select value from archive_day__metadata where name='Version'" |
sqlite3 weewx.sdb*

The intention is that the daily summaries are either one or the other: the
sums are either not weighted (version=1), or they are weighted (version=2).
I don't know why your database would be a little of each. It should not be.

This can all be fixed by dropping
, then
rebuilding ,
the daily summaries. The utility wee_database can do this.

-tk

On Wed, Aug 19, 2020 at 5:57 PM David Geiger  wrote:

> I have been a long time user of weewx, great software!
>
> I recently updated from 3.9.2 to 4.1.1. After the update, I noticed that
> my average yearly outTemp was different. I took a look in the database and
> noticed that after the upgrade, my wsum and sumtime are a factor of 300
> times greater than before the upgrade. Before, sumtime = 288 each day,
> after the upgrade it = 86400 each day. I noticed it in the
> archive_day_outTemp table. The average for the day is still correct, but
> when you run for a span that includes 3.9.2 and 4.1.1, the 4.1.1 far out
> weighs the 3.9.2.
>
> I have my archive interval set to 300. It was not changed between 3.9.2
> and 4.1.1
>
> --
> 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/b9f624ae-fcb7-40ab-bada-263a3d665300n%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/CAPq0zEDBqsoEje_7cbVy81J8W2g6JEByLi85ye-kZiVQpBRiiw%40mail.gmail.com.

RE: [weewx-user] UnicodeDecodeError in database

[David Marshall]

1. Yes
2. Seemed to work ok
3. Syslog attached – but seems to me to be ok.

The problem only occurs when using wee_database -interestingly the offending 
byte has moved from position 26 to 31!

pi@raspberrypi:~ $ /home/weewx/bin/wee_database --reconfigure 
/home/weewx/archive/weewx.sdb
Traceback (most recent call last):
  File "/home/weewx/bin/wee_database", line 974, in 
main()
  File "/home/weewx/bin/wee_database", line 128, in main
config_path, config_dict = weecfg.read_config(options.config_path, args)
  File "/home/weewx/bin/weecfg/__init__.py", line 179, in read_config
default_encoding='utf-8')
  File "/usr/lib/python3/dist-packages/configobj.py", line 1229, in __init__
self._load(infile, configspec)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1287, in _load
content = self._handle_bom(content)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1437, in _handle_bom
return self._decode(infile, self.encoding)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1517, in _decode
infile[i] = line.decode(encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf2 in position 31: 
invalid continuation byte

Sent from Mail for Windows 10

From: Tom Keffer
Sent: 20 August 2020 00:51
To: weewx-user
Subject: Re: [weewx-user] UnicodeDecodeError in database

I don't have any problem with either copy of weewx.conf that you sent to me. 
Things to try:

1. This is /home/weewx/weewx.conf, right?  

2. Try reading it directly:

python -c "import configobj; c=configobj.ConfigObj('/home/weewx/weewx.conf')"

3. Set debug=1 in weewx.conf, then try running weewxd, then send us the log. 

-tk



On Wed, Aug 19, 2020 at 7:19 AM David Marshall  wrote:
Hi Tom
 
1. Yes wee_database
2. Yes same path different  copies
3. No edits – in fact I tried not to change anything in the final install apart 
from setting it to simulator.
 
I attach the last version of weewx.conf, which is still producing the error.
 
David
 
Sent from Mail for Windows 10
 
From: Tom Keffer
Sent: 19 August 2020 15:59
To: weewx-user
Subject: Re: [weewx-user] UnicodeDecodeError in database
 
1. All these attempts were with running wee_database? Or, something else?
 
2. I assume all these different attempts used the same path, namely 
/home/weewx/weewx.conf. And, we're sure they used different copies (albeit, at 
the same path location)? 
 
3. It's hard to explain how fresh, untouched versions of weewx.conf are all 
getting the same error. Are you editing these copies before running?
 
Can you send me the offending weewx.conf to my personal email? tkeffer at 
gmail.com
 
-tk
 
On Wed, Aug 19, 2020 at 6:35 AM David Marshall  wrote:
Thanks Tom
 
Tried your code to show the offending line but nothing appears. Then tried a 
clean weewx.conf from the install folder but still the same error message. Then 
tried a full reinstall, but still the same error.
Then tried it with the the default database using simulator and still the same 
error - so you are right it is not my database. What next?

On Wednesday, August 19, 2020 at 2:51:31 PM UTC+2, Tom Keffer wrote:
The decode error is actually in your configuration file, weewx.conf, and not in 
the database.
 
Somehow, your copy of weewx.conf got corrupted. One of the lines has a 
character sequence that starts out as a utf-8 encoding, but the following byte 
is not what was expected. 
 
Unfortunately, the error does not tell you which line the bad character 
sequence is in, only that it is in byte position 26 of that line. Perhaps this 
will help (NOT TESTED):
 
od -x -A d weewx.conf | grep e0
 
This should print out the line and offending sequence.
 
-tk
 
 
 
On Wed, Aug 19, 2020 at 5:25 AM David Marshall  wrote:
Hi
 
Installed a fresh version of weewx 4.1.1 without problem using setup.py on a 
raspberry.
 
Transferred my existing sqlite database from weewx 3.9.1. It is big, about 3 
years of data. This worked fine.
 
But when I tried to use reconfigure I got the following error
 
pi@raspberrypi:~ $ /home/weewx/bin/wee_database --reconfigure 
/home/weewx/archive/weewx.sdb
Traceback (most recent call last):
  File "/home/weewx/bin/wee_database", line 974, in 
    main()
  File "/home/weewx/bin/wee_database", line 128, in main
    config_path, config_dict = weecfg.read_config(options.config_path, args)
  File "/home/weewx/bin/weecfg/__init__.py", line 179, in read_config
    default_encoding='utf-8')
  File "/usr/lib/python3/dist-packages/configobj.py", line 1229, in __init__
    self._load(infile, configspec)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1287, in _load
    content = self._handle_bom(content)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1437, in _handle_bom
    return self._decode(infile, self.encoding)
  File "/usr/lib/python3/dist-packages/configobj.py", line 1517, in _decode
    infile[i] = line.decode(encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 26: 
invalid continuation byte
 

[weewx-user] Replacement for WMR200 ?

[Invisible Man]

Hi,
I've had a (Oregon Scientific) WMR200 weather station for years and been 
very happy with it. Lately, I've been encountering several hardware issues 
with it, and I fear it is perhaps going to be the end of it, soon or later.
What replacement weather station would you recommend? I'm looking for 
something below 500 euros, and of course supported by weewx. 
Thanks,
Axelle.

-- 
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/2161d06d-97db-4491-96c9-f851ee20d078n%40googlegroups.com.