Re: [weewx-user] Re: GW1000 output and database

[Graham Eddy]

it will be interesting to see what gary concludes.
it looks to me like the fields are correctly identified and mapped (i presume; 
the data is there but i don't see the mapped result) but not inserted into 
packet by augmentation. one reason for not inserting the data would be if it is 
stale - do the timestamps of the weatherflowudp driver (datetime in packet) 
line up with the gw1000 service (datetime in mapped_data) within age toleration?

> On 24 Aug 2020, at 11:48 pm, Timothy Buchanan  
> wrote:
> 
> field_map used with debug 3.
> 
> On Sunday, August 23, 2020 at 6:07:35 PM UTC-6 gjr80 wrote:
> Thanks, from the log it looks like the GW1000 service thread has silently 
> died (which it shouldn't, it should die loudly if it dies!). Let's step the 
> debug level up, leaving everything else as it is edit weewx.conf and set 
> debug = 3, save weewx.conf and restart WeeWX. Let WeeWX run for about five 
> minutes and again take a log extract from when you just started WeeWX. Post 
> the log here.
> 
> Gary
> 
> On Monday, 24 August 2020 at 09:55:21 UTC+10 timothye...@gmail.com 
>  wrote:
> debug=2 GW options so (pasted):
> 
> # Options for extension 'GW1000'
> [GW1000]
> driver = user.gw1000
> [[field_map]]
> extraTemp2 = intemp
> extraHumid2 = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1

-- 
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/7C0BECA8-6F4C-447C-B0B8-3DA34B927E72%40gmail.com.

Re: [weewx-user] Re: GW1000 output and database

[Timothy Buchanan]

field_map used with debug 3.

On Sunday, August 23, 2020 at 6:07:35 PM UTC-6 gjr80 wrote:

> Thanks, from the log it looks like the GW1000 service thread has silently 
> died (which it shouldn't, it should die loudly if it dies!). Let's step the 
> debug level up, leaving everything else as it is edit weewx.conf and set 
> debug 
> = 3, save weewx.conf and restart WeeWX. Let WeeWX run for about five 
> minutes and again take a log extract from when you just started WeeWX. Post 
> the log here.
>
> Gary
>
> On Monday, 24 August 2020 at 09:55:21 UTC+10 timothye...@gmail.com wrote:
>
>> debug=2 GW options so (pasted):
>>
>> # Options for extension 'GW1000'
>> [GW1000]
>> driver = user.gw1000
>> [[field_map]]
>> extraTemp2 = intemp
>> extraHumid2 = inhumid
>> extraTemp1 = temp1
>> extraHumid1 = humid1
>> soilMoist1 = soilmoist1
>>
>> Syslog extract and debug.txt attached. Output from this is null. Thanks 
>> again.
>>
>>
>>
>> On Sunday, August 23, 2020 at 3:11:24 PM UTC-6 gjr80 wrote:
>>
>>> Please don’t use [[field map]], it is ignored by the GW1000 
>>> driver/service and will result in the default field map being used which 
>>> will map intemp to inTemp; it definitely will not map intemp to extraTemp2. 
>>> Plus we are left trying to work out if you made a typo or not.
>>>
>>> So we know the field map is being read and used (when [[field_map]] is 
>>> used) and the GW1000 is emitting intemp and inhumidity. Now we need to look 
>>> closer at how the data is processed through the GW1000 service. Can you 
>>> please edit weewx.conf, set debug = 2 and make sure the [GW1000] stanza 
>>> has [[field_map]] and that it is set to:
>>>
>>> [[field_map]]
>>> extraTemp2 = intemp
>>> extraHumid2 = inhumid
>>> extraTemp1 = temp1
>>> extraHumid1 = humid1
>>> soilMoist1 = soilmoist1
>>>
>>> Then save weewx.conf and restart WeeWX. Let WeeWX run for 10 minutes 
>>> then take a log extract from when WeeWX was restarted through until 10 
>>> minutes elapsed and post the extract here. 
>>>
>>> Can you also run wee_debug 
>>>  and post the 
>>> wee_debug output, do check the wee_debug out for sensitive info such as 
>>> usernames, passwords and api keys etc, wee_debug should obfuscate such 
>>> entries but it is not perfect.
>>>
>>> Gary
>>> On Monday, 24 August 2020 at 05:37:46 UTC+10 timothye...@gmail.com 
>>> wrote:
>>>
 With bme280wx uninstalled and GW1000 set to [[field_map]], I get all 
 nulls in the database.
 With bme280wx uninstalled and GW1000 set to [[field map]], I get all GW 
 values, but intemp and inhumid are sent to inTemp and inHumidity. 
 I have switched back and forth repeatedly and this is what I get.
 With bme280wx installed, I get values from the bme280, but not from 
 GW1000, no matter what settings I use. So it seems that bme280wx and 
 GW1000 
 are incompatible. But maybe someone who is running a bme280 and GW1000 
 successfully will chime in here.

 Timothy

 On Sunday, August 23, 2020 at 9:54:13 AM UTC-6 graha...@gmail.com 
 wrote:

> this is still incorrect. it should be [[field_map]] ← note the 
> underscore
>
> On 24 Aug 2020, at 1:22 am, Timothy Buchanan  
> wrote:
>
> This morning, I deleted the other service and restarted weewx. GW1000 
> not reports intemp and inhumid, but mapped to inTemp and inHumidity. Here 
> is the field_map:
>
> [[field map]]
> extraTemp2 = intemp
> extraHumid2 = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1
>
>
>

-- 
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/a469af93-d6d8-4863-a168-3dbd65e9bfd2n%40googlegroups.com.
Aug 24 07:30:37 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Aug 24 07:30:37 raspberrypi systemd[1]: Starting LSB: weewx weather system...
Aug 24 07:30:37 raspberrypi weewx[1148] INFO __main__: Initializing weewx 
version 4.1.1
Aug 24 07:30:37 raspberrypi weewx[1148] INFO __main__: Using Python 2.7.16 
(default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
Aug 24 07:30:37 raspberrypi weewx[1148] INFO __main__: Platform 
Linux-5.4.51-v7l+-armv7l-with-debian-10.4
Aug 24 07:30:37 raspberrypi weewx[1148] INFO __main__: Locale is 'en_US.UTF-8'
Aug 24 07:30:37 raspberrypi weewx[1148] INFO __main__: PID file is 
/var/run/weewx.pid
Aug 24 07:30:37 raspberrypi weewx[1136]: Starting weewx weather system: weewx.
Aug 24 07:30:37 raspberrypi systemd[1]: Started LSB: weewx weather system.
Aug 24 07:30:37 raspberrypi weewx[1152] INFO __main__: Using configu

Re: [weewx-user] Re: GW1000 output and database

[gjr80]

Thanks, from the log it looks like the GW1000 service thread has silently 
died (which it shouldn't, it should die loudly if it dies!). Let's step the 
debug level up, leaving everything else as it is edit weewx.conf and set debug 
= 3, save weewx.conf and restart WeeWX. Let WeeWX run for about five 
minutes and again take a log extract from when you just started WeeWX. Post 
the log here.

Gary

On Monday, 24 August 2020 at 09:55:21 UTC+10 timothye...@gmail.com wrote:

> debug=2 GW options so (pasted):
>
> # Options for extension 'GW1000'
> [GW1000]
> driver = user.gw1000
> [[field_map]]
> extraTemp2 = intemp
> extraHumid2 = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1
>
> Syslog extract and debug.txt attached. Output from this is null. Thanks 
> again.
>
>
>
> On Sunday, August 23, 2020 at 3:11:24 PM UTC-6 gjr80 wrote:
>
>> Please don’t use [[field map]], it is ignored by the GW1000 
>> driver/service and will result in the default field map being used which 
>> will map intemp to inTemp; it definitely will not map intemp to extraTemp2. 
>> Plus we are left trying to work out if you made a typo or not.
>>
>> So we know the field map is being read and used (when [[field_map]] is 
>> used) and the GW1000 is emitting intemp and inhumidity. Now we need to look 
>> closer at how the data is processed through the GW1000 service. Can you 
>> please edit weewx.conf, set debug = 2 and make sure the [GW1000] stanza 
>> has [[field_map]] and that it is set to:
>>
>> [[field_map]]
>> extraTemp2 = intemp
>> extraHumid2 = inhumid
>> extraTemp1 = temp1
>> extraHumid1 = humid1
>> soilMoist1 = soilmoist1
>>
>> Then save weewx.conf and restart WeeWX. Let WeeWX run for 10 minutes then 
>> take a log extract from when WeeWX was restarted through until 10 minutes 
>> elapsed and post the extract here. 
>>
>> Can you also run wee_debug 
>>  and post the 
>> wee_debug output, do check the wee_debug out for sensitive info such as 
>> usernames, passwords and api keys etc, wee_debug should obfuscate such 
>> entries but it is not perfect.
>>
>> Gary
>> On Monday, 24 August 2020 at 05:37:46 UTC+10 timothye...@gmail.com wrote:
>>
>>> With bme280wx uninstalled and GW1000 set to [[field_map]], I get all 
>>> nulls in the database.
>>> With bme280wx uninstalled and GW1000 set to [[field map]], I get all GW 
>>> values, but intemp and inhumid are sent to inTemp and inHumidity. 
>>> I have switched back and forth repeatedly and this is what I get.
>>> With bme280wx installed, I get values from the bme280, but not from 
>>> GW1000, no matter what settings I use. So it seems that bme280wx and GW1000 
>>> are incompatible. But maybe someone who is running a bme280 and GW1000 
>>> successfully will chime in here.
>>>
>>> Timothy
>>>
>>> On Sunday, August 23, 2020 at 9:54:13 AM UTC-6 graha...@gmail.com wrote:
>>>
 this is still incorrect. it should be [[field_map]] ← note the 
 underscore

 On 24 Aug 2020, at 1:22 am, Timothy Buchanan  
 wrote:

 This morning, I deleted the other service and restarted weewx. GW1000 
 not reports intemp and inhumid, but mapped to inTemp and inHumidity. Here 
 is the field_map:

 [[field map]]
 extraTemp2 = intemp
 extraHumid2 = inhumid
 extraTemp1 = temp1
 extraHumid1 = humid1
 soilMoist1 = soilmoist1




-- 
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/e6a1fb85-900b-4ccf-8435-c9e80c7fbaf7n%40googlegroups.com.

Re: [weewx-user] Re: GW1000 output and database

[Timothy Buchanan]

debug=2 GW options so (pasted):

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

Syslog extract and debug.txt attached. Output from this is null. Thanks 
again.



On Sunday, August 23, 2020 at 3:11:24 PM UTC-6 gjr80 wrote:

> Please don’t use [[field map]], it is ignored by the GW1000 driver/service 
> and will result in the default field map being used which will map intemp 
> to inTemp; it definitely will not map intemp to extraTemp2. Plus we are 
> left trying to work out if you made a typo or not.
>
> So we know the field map is being read and used (when [[field_map]] is 
> used) and the GW1000 is emitting intemp and inhumidity. Now we need to look 
> closer at how the data is processed through the GW1000 service. Can you 
> please edit weewx.conf, set debug = 2 and make sure the [GW1000] stanza 
> has [[field_map]] and that it is set to:
>
> [[field_map]]
> extraTemp2 = intemp
> extraHumid2 = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1
>
> Then save weewx.conf and restart WeeWX. Let WeeWX run for 10 minutes then 
> take a log extract from when WeeWX was restarted through until 10 minutes 
> elapsed and post the extract here. 
>
> Can you also run wee_debug 
>  and post the 
> wee_debug output, do check the wee_debug out for sensitive info such as 
> usernames, passwords and api keys etc, wee_debug should obfuscate such 
> entries but it is not perfect.
>
> Gary
> On Monday, 24 August 2020 at 05:37:46 UTC+10 timothye...@gmail.com wrote:
>
>> With bme280wx uninstalled and GW1000 set to [[field_map]], I get all 
>> nulls in the database.
>> With bme280wx uninstalled and GW1000 set to [[field map]], I get all GW 
>> values, but intemp and inhumid are sent to inTemp and inHumidity. 
>> I have switched back and forth repeatedly and this is what I get.
>> With bme280wx installed, I get values from the bme280, but not from 
>> GW1000, no matter what settings I use. So it seems that bme280wx and GW1000 
>> are incompatible. But maybe someone who is running a bme280 and GW1000 
>> successfully will chime in here.
>>
>> Timothy
>>
>> On Sunday, August 23, 2020 at 9:54:13 AM UTC-6 graha...@gmail.com wrote:
>>
>>> this is still incorrect. it should be [[field_map]] ← note the underscore
>>>
>>> On 24 Aug 2020, at 1:22 am, Timothy Buchanan  
>>> wrote:
>>>
>>> This morning, I deleted the other service and restarted weewx. GW1000 
>>> not reports intemp and inhumid, but mapped to inTemp and inHumidity. Here 
>>> is the field_map:
>>>
>>> [[field map]]
>>> extraTemp2 = intemp
>>> extraHumid2 = inhumid
>>> extraTemp1 = temp1
>>> extraHumid1 = humid1
>>> soilMoist1 = soilmoist1
>>>
>>>
>>>

-- 
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/ef8df6d2-25f7-4764-82eb-003a04c0ed70n%40googlegroups.com.
LOOP:   2020-08-22 08:10:35 MDT (1598105435) altimeter: 30.429894128, dateTime: 
1598105435, extraHumid1: 37, extraTemp1: 63.86, inDewpoint: 42.2044328587, 
inHumidity: 32, inTemp: 73.94, lux: 20105, pressure: 22.2095035988, radiation: 
167, rain: 0.0, rainRate: 0, relbarometer: 752.1, soilMoist1: 28, usUnits: 1, 
UV: 1.78, wh31_ch1_batt: 0, wh51_ch1_batt: 0, windBatteryStatus: 3.275, 
windGust: 5.90552648912
LOOP:   2020-08-22 08:10:37 MDT (1598105437) dateTime: 1598105437, rainRate: 0, 
usUnits: 1, windDir: 273, windSpeed: 3.31067394087
LOOP:   2020-08-22 08:10:37 MDT (1598105437) altimeter: 30.2965008953, 
avg_distance: 0, barometer: 29.9037865166, dateTime: 1598105437, dewpoint: 
35.9378281214, heatindex: 66.74, lightning_strikes: 0, outHumidity: 32, 
outTemp: 66.74, outTempBatteryStatus: 2.944, pressure: 22.1061486425, rainRate: 
0, usUnits: 1
LOOP:   2020-08-22 08:10:43 MDT (1598105443) dateTime: 1598105443, rainRate: 0, 
usUnits: 1, windDir: 264, windSpeed: 4.80942498167
LOOP:   2020-08-22 08:10:46 MDT (1598105446) dateTime: 1598105446, rainRate: 0, 
usUnits: 1, windDir: 241, windSpeed: 5.59235462985
LOOP:   2020-08-22 08:10:49 MDT (1598105449) dateTime: 1598105449, rainRate: 0, 
usUnits: 1, windDir: 273, windSpeed: 4.29492835572
LOOP:   2020-08-22 08:10:52 MDT (1598105452) dateTime: 1598105452, rainRate: 0, 
usUnits: 1, windDir: 279, windSpeed: 1.78955348155
LOOP:   2020-08-22 08:10:55 MDT (1598105455) dateTime: 1598105455, rainRate: 0, 
usUnits: 1, windDir: 261, windSpeed: 4.80942498167
LOOP:   2020-08-22 08:10:58 MDT (1598105458) dateTime: 1598105458, rainRate: 0, 
usUnits: 1, windDir: 266, windSpeed: 3.4896292890

Re: [weewx-user] Re: GW1000 output and database

[gjr80]

Please don’t use [[field map]], it is ignored by the GW1000 driver/service 
and will result in the default field map being used which will map intemp 
to inTemp; it definitely will not map intemp to extraTemp2. Plus we are 
left trying to work out if you made a typo or not.

So we know the field map is being read and used (when [[field_map]] is 
used) and the GW1000 is emitting intemp and inhumidity. Now we need to look 
closer at how the data is processed through the GW1000 service. Can you 
please edit weewx.conf, set debug = 2 and make sure the [GW1000] stanza has 
[[field_map]] and that it is set to:

[[field_map]]
extraTemp2 = intemp
extraHumid2 = inhumid
extraTemp1 = temp1
extraHumid1 = humid1
soilMoist1 = soilmoist1

Then save weewx.conf and restart WeeWX. Let WeeWX run for 10 minutes then 
take a log extract from when WeeWX was restarted through until 10 minutes 
elapsed and post the extract here. 

Can you also run wee_debug 
 and post the 
wee_debug output, do check the wee_debug out for sensitive info such as 
usernames, passwords and api keys etc, wee_debug should obfuscate such 
entries but it is not perfect.

Gary
On Monday, 24 August 2020 at 05:37:46 UTC+10 timothye...@gmail.com wrote:

> With bme280wx uninstalled and GW1000 set to [[field_map]], I get all nulls 
> in the database.
> With bme280wx uninstalled and GW1000 set to [[field map]], I get all GW 
> values, but intemp and inhumid are sent to inTemp and inHumidity. 
> I have switched back and forth repeatedly and this is what I get.
> With bme280wx installed, I get values from the bme280, but not from 
> GW1000, no matter what settings I use. So it seems that bme280wx and GW1000 
> are incompatible. But maybe someone who is running a bme280 and GW1000 
> successfully will chime in here.
>
> Timothy
>
> On Sunday, August 23, 2020 at 9:54:13 AM UTC-6 graha...@gmail.com wrote:
>
>> this is still incorrect. it should be [[field_map]] ← note the underscore
>>
>> On 24 Aug 2020, at 1:22 am, Timothy Buchanan  
>> wrote:
>>
>> This morning, I deleted the other service and restarted weewx. GW1000 not 
>> reports intemp and inhumid, but mapped to inTemp and inHumidity. Here is 
>> the field_map:
>>
>> [[field map]]
>> extraTemp2 = intemp
>> extraHumid2 = inhumid
>> extraTemp1 = temp1
>> extraHumid1 = humid1
>> soilMoist1 = soilmoist1
>>
>>
>>

-- 
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/e5160eb6-7750-4558-8662-3a93bdcd1de5n%40googlegroups.com.

Re: [weewx-user] Re: GW1000 output and database

[Timothy Buchanan]

With bme280wx uninstalled and GW1000 set to [[field_map]], I get all nulls 
in the database.
With bme280wx uninstalled and GW1000 set to [[field map]], I get all GW 
values, but intemp and inhumid are sent to inTemp and inHumidity. 
I have switched back and forth repeatedly and this is what I get.
With bme280wx installed, I get values from the bme280, but not from GW1000, 
no matter what settings I use. So it seems that bme280wx and GW1000 are 
incompatible. But maybe someone who is running a bme280 and GW1000 
successfully will chime in here.

Timothy

On Sunday, August 23, 2020 at 9:54:13 AM UTC-6 graha...@gmail.com wrote:

> this is still incorrect. it should be [[field_map]] ← note the underscore
>
> On 24 Aug 2020, at 1:22 am, Timothy Buchanan  
> wrote:
>
> This morning, I deleted the other service and restarted weewx. GW1000 not 
> reports intemp and inhumid, but mapped to inTemp and inHumidity. Here is 
> the field_map:
>
> [[field map]]
> extraTemp2 = intemp
> extraHumid2 = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1
>
>
>

-- 
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/0d220098-ae11-4c9c-9c84-66ab342ce598n%40googlegroups.com.

Re: [weewx-user] Re: GW1000 output and database

[Graham Eddy]

this is still incorrect. it should be [[field_map]] ← note the underscore

> On 24 Aug 2020, at 1:22 am, Timothy Buchanan  
> wrote:
> 
> This morning, I deleted the other service and restarted weewx. GW1000 not 
> reports intemp and inhumid, but mapped to inTemp and inHumidity. Here is the 
> field_map:
> 
> [[field map]]
> extraTemp2 = intemp
> extraHumid2 = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1

-- 
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/395512E5-AEA5-4E04-ABC3-3F1ED0202B77%40gmail.com.

Re: [weewx-user] Re: GW1000 output and database

[Timothy Buchanan]

Here is live data:

GW1000 live sensor data: absbarometer: 753.4, datetime: 1598189179, humid1: 
42, inhumid: 30, intemp: 21.7,
 relbarometer: 753.4, soilmoist1: 26, temp1: 12.8, wh31_ch1_batt: 0, 
wh51_ch1_batt: 0

This morning, I deleted the other service and restarted weewx. GW1000 not 
reports intemp and inhumid, but mapped to inTemp and inHumidity. Here is 
the field_map:

[[field map]]
extraTemp2 = intemp
extraHumid2 = inhumid
extraTemp1 = temp1
extraHumid1 = humid1
soilMoist1 = soilmoist1

GW1000 intemp is mapped to extraTemp2, but is reported in the database as 
inTemp, as if it is hard coded to do so. 

Timothy


On Saturday, August 22, 2020 at 8:39:59 PM UTC-6 gjr80 wrote:

> The GW1000 data is being picked up every 60 seconds as it should but it is 
> sans extraHumid2/extraTemp2. Time to look a little closer at what the 
> GW1000 is picking up. Can you run the GW1000 driver directly with the 
> --live-data command line option. For a setup.py install something like:
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --live-data
>
> or for a package install:
>
> $ PYTHONPATH=/usr/share/weewx python -m user.gw1000 --live-data
>
> This will show us what data is available for use from the GW1000 and its 
> connected sensors.
>
> Gary
> On Sunday, 23 August 2020 at 00:29:36 UTC+10 timothye...@gmail.com wrote:
>
>> Here is the output from one archive period; the REC loop is near the end.
>>
>> Timothy
>>
>> On Friday, August 21, 2020 at 11:51:41 PM UTC-6 gjr80 wrote:
>>
>>> Actually, now that we have the GW1000 field mapping set I suspect the 
>>> answer may be in the loop packets. Tim has three sources contributing to 
>>> loop packets, and on top of that I believe the Weatherflow driver emits 
>>> partial packets which further complicates the process. that being said it 
>>> should be possible to have all three work co-operatively, perhaps with some 
>>> judicious config settings. As Graham said you need to run WeeWX directly 
>>> , once it is 
>>> running directly let it run for at least a full archive interval and then 
>>> post the entire console output making sure you include at least one REC: 
>>> line.
>>>
>>> Gary
>>>
>>>
>>> On Saturday, 22 August 2020 13:19:37 UTC+10, Graham Eddy wrote:
>>>
 when you run weewx in foreground (not as daemon) so you can see the 
 weewx records, looking at the REC records (not LOOP records), what are the 
 fields being offered to archive service? then looking in weewx db, which 
 of 
 these fields are actally being populated in db?

>>> On 22 Aug 2020, at 12:24 pm, Timothy Buchanan  
 wrote:

 I think you're being helpful, not harping, and I appreciate it. I just 
 restarted weewx with [[field_map]] and found the following line in syslog:

 Aug 21 19:51:10 raspberrypi weewx[22309] INFO gw1000: user.gw1000: 
 field map is {'extraHumid1': 'humid1', 'extraHumid2': 'inhumid',
  'extraTemp1': 'temp1', 'extraTemp2': 'intemp', 'soilMoist1': 
 'soilmoist1'}

 so yes, it is mapping correctly but something is preventing these 
 values from being placed in the database, where they are all null. 
 Incidentally, if I use [[field_map_extension]] it is ignored and I get the 
 latter three values as before. So what could be keeping the mapped GW1000 
 service from the database?

 On Friday, August 21, 2020 at 2:31:05 PM UTC-6 gjr80 wrote:

> Sorry if you think I am harping on the [[field_map]] issue but I need 
> to understand if we are trying to track down a field map issue or 
> something 
> else. Is the log extract you just posted with [[field map]] or 
> [[field_map]]? because again it shows the setting was ignored.
>
> The reason that [[field map]] partially works is that it is completely 
> ignored and the default map used, this results in GW1000 fields intemp 
> and 
> in humid being discarded because their mapped locations (WeeWX fields 
> inTemp and inHumidity) are already populated. The GW1000 driver is coded 
> to 
> use two field map type stanzas; [[field_map]] and 
> [[field_map_extensions]]. 
> As far as the field map is concerned anything else is ignored.
>
> Gary
>
> On Saturday, 22 August 2020 at 02:59:26 UTC+10 timothye...@gmail.com 
> wrote:
>
>> Yes, the GW1000 disconnected and I moved it close to the router for 
>> testing, where I can see it. the router reserves an ip for it. I decided 
>> to 
>> start over. I uninstalled the extension, went back to an earlier 
>> weewx.conf 
>> then reinstalled the extension. I modified weewx.conf as shown in the 
>> github page, and placed this in weewx.conf:
>>
>> # Options for extension 'GW1000'
>> [GW1000]
>> driver = user.gw1000
>> [[field map]]
>> extraTemp2  = intemp
>> extraHumid2 

Re: [weewx-user] Re: GW1000 output and database

[gjr80]

The GW1000 data is being picked up every 60 seconds as it should but it is 
sans extraHumid2/extraTemp2. Time to look a little closer at what the 
GW1000 is picking up. Can you run the GW1000 driver directly with the 
--live-data command line option. For a setup.py install something like:

$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --live-data

or for a package install:

$ PYTHONPATH=/usr/share/weewx python -m user.gw1000 --live-data

This will show us what data is available for use from the GW1000 and its 
connected sensors.

Gary
On Sunday, 23 August 2020 at 00:29:36 UTC+10 timothye...@gmail.com wrote:

> Here is the output from one archive period; the REC loop is near the end.
>
> Timothy
>
> On Friday, August 21, 2020 at 11:51:41 PM UTC-6 gjr80 wrote:
>
>> Actually, now that we have the GW1000 field mapping set I suspect the 
>> answer may be in the loop packets. Tim has three sources contributing to 
>> loop packets, and on top of that I believe the Weatherflow driver emits 
>> partial packets which further complicates the process. that being said it 
>> should be possible to have all three work co-operatively, perhaps with some 
>> judicious config settings. As Graham said you need to run WeeWX directly 
>> , once it is 
>> running directly let it run for at least a full archive interval and then 
>> post the entire console output making sure you include at least one REC: 
>> line.
>>
>> Gary
>>
>>
>> On Saturday, 22 August 2020 13:19:37 UTC+10, Graham Eddy wrote:
>>
>>> when you run weewx in foreground (not as daemon) so you can see the 
>>> weewx records, looking at the REC records (not LOOP records), what are the 
>>> fields being offered to archive service? then looking in weewx db, which of 
>>> these fields are actally being populated in db?
>>>
>> On 22 Aug 2020, at 12:24 pm, Timothy Buchanan  
>>> wrote:
>>>
>>> I think you're being helpful, not harping, and I appreciate it. I just 
>>> restarted weewx with [[field_map]] and found the following line in syslog:
>>>
>>> Aug 21 19:51:10 raspberrypi weewx[22309] INFO gw1000: user.gw1000: field 
>>> map is {'extraHumid1': 'humid1', 'extraHumid2': 'inhumid',
>>>  'extraTemp1': 'temp1', 'extraTemp2': 'intemp', 'soilMoist1': 
>>> 'soilmoist1'}
>>>
>>> so yes, it is mapping correctly but something is preventing these values 
>>> from being placed in the database, where they are all null. Incidentally, 
>>> if I use [[field_map_extension]] it is ignored and I get the latter three 
>>> values as before. So what could be keeping the mapped GW1000 service from 
>>> the database?
>>>
>>> On Friday, August 21, 2020 at 2:31:05 PM UTC-6 gjr80 wrote:
>>>
 Sorry if you think I am harping on the [[field_map]] issue but I need 
 to understand if we are trying to track down a field map issue or 
 something 
 else. Is the log extract you just posted with [[field map]] or 
 [[field_map]]? because again it shows the setting was ignored.

 The reason that [[field map]] partially works is that it is completely 
 ignored and the default map used, this results in GW1000 fields intemp and 
 in humid being discarded because their mapped locations (WeeWX fields 
 inTemp and inHumidity) are already populated. The GW1000 driver is coded 
 to 
 use two field map type stanzas; [[field_map]] and 
 [[field_map_extensions]]. 
 As far as the field map is concerned anything else is ignored.

 Gary

 On Saturday, 22 August 2020 at 02:59:26 UTC+10 timothye...@gmail.com 
 wrote:

> Yes, the GW1000 disconnected and I moved it close to the router for 
> testing, where I can see it. the router reserves an ip for it. I decided 
> to 
> start over. I uninstalled the extension, went back to an earlier 
> weewx.conf 
> then reinstalled the extension. I modified weewx.conf as shown in the 
> github page, and placed this in weewx.conf:
>
> # Options for extension 'GW1000'
> [GW1000]
> driver = user.gw1000
> [[field map]]
> extraTemp2  = intemp
> extraHumid2  = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1
>
> I've attached a syslog extract. I tried using [[field_map]], and that 
> made all values null. Using [[field map]] gives the last three values. 
> Maybe you could post a working GW Options field, and I will paste that 
> into 
> my weewx.conf and see what happens.
>
> On Thursday, August 20, 2020 at 8:37:57 PM UTC-6 gjr80 wrote:
>
>> 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 weew

Re: [weewx-user] Re: GW1000 output and database

[Timothy Buchanan]

Here is the output from one archive period; the REC loop is near the end.

Timothy

On Friday, August 21, 2020 at 11:51:41 PM UTC-6 gjr80 wrote:

> Actually, now that we have the GW1000 field mapping set I suspect the 
> answer may be in the loop packets. Tim has three sources contributing to 
> loop packets, and on top of that I believe the Weatherflow driver emits 
> partial packets which further complicates the process. that being said it 
> should be possible to have all three work co-operatively, perhaps with some 
> judicious config settings. As Graham said you need to run WeeWX directly 
> , once it is 
> running directly let it run for at least a full archive interval and then 
> post the entire console output making sure you include at least one REC: 
> line.
>
> Gary
>
>
> On Saturday, 22 August 2020 13:19:37 UTC+10, Graham Eddy wrote:
>
>> when you run weewx in foreground (not as daemon) so you can see the weewx 
>> records, looking at the REC records (not LOOP records), what are the fields 
>> being offered to archive service? then looking in weewx db, which of these 
>> fields are actally being populated in db?
>>
> On 22 Aug 2020, at 12:24 pm, Timothy Buchanan  
>> wrote:
>>
>> I think you're being helpful, not harping, and I appreciate it. I just 
>> restarted weewx with [[field_map]] and found the following line in syslog:
>>
>> Aug 21 19:51:10 raspberrypi weewx[22309] INFO gw1000: user.gw1000: field 
>> map is {'extraHumid1': 'humid1', 'extraHumid2': 'inhumid',
>>  'extraTemp1': 'temp1', 'extraTemp2': 'intemp', 'soilMoist1': 
>> 'soilmoist1'}
>>
>> so yes, it is mapping correctly but something is preventing these values 
>> from being placed in the database, where they are all null. Incidentally, 
>> if I use [[field_map_extension]] it is ignored and I get the latter three 
>> values as before. So what could be keeping the mapped GW1000 service from 
>> the database?
>>
>> On Friday, August 21, 2020 at 2:31:05 PM UTC-6 gjr80 wrote:
>>
>>> Sorry if you think I am harping on the [[field_map]] issue but I need to 
>>> understand if we are trying to track down a field map issue or something 
>>> else. Is the log extract you just posted with [[field map]] or 
>>> [[field_map]]? because again it shows the setting was ignored.
>>>
>>> The reason that [[field map]] partially works is that it is completely 
>>> ignored and the default map used, this results in GW1000 fields intemp and 
>>> in humid being discarded because their mapped locations (WeeWX fields 
>>> inTemp and inHumidity) are already populated. The GW1000 driver is coded to 
>>> use two field map type stanzas; [[field_map]] and [[field_map_extensions]]. 
>>> As far as the field map is concerned anything else is ignored.
>>>
>>> Gary
>>>
>>> On Saturday, 22 August 2020 at 02:59:26 UTC+10 timothye...@gmail.com 
>>> wrote:
>>>
 Yes, the GW1000 disconnected and I moved it close to the router for 
 testing, where I can see it. the router reserves an ip for it. I decided 
 to 
 start over. I uninstalled the extension, went back to an earlier 
 weewx.conf 
 then reinstalled the extension. I modified weewx.conf as shown in the 
 github page, and placed this in weewx.conf:

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

 I've attached a syslog extract. I tried using [[field_map]], and that 
 made all values null. Using [[field map]] gives the last three values. 
 Maybe you could post a working GW Options field, and I will paste that 
 into 
 my weewx.conf and see what happens.

 On Thursday, August 20, 2020 at 8:37:57 PM UTC-6 gjr80 wrote:

> 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': 'le

Re: [weewx-user] Re: GW1000 output and database

[gjr80]

Actually, now that we have the GW1000 field mapping set I suspect the 
answer may be in the loop packets. Tim has three sources contributing to 
loop packets, and on top of that I believe the Weatherflow driver emits 
partial packets which further complicates the process. that being said it 
should be possible to have all three work co-operatively, perhaps with some 
judicious config settings. As Graham said you need to run WeeWX directly 
, once it is running 
directly let it run for at least a full archive interval and then post the 
entire console output making sure you include at least one REC: line.

Gary

On Saturday, 22 August 2020 13:19:37 UTC+10, Graham Eddy wrote:
>
> when you run weewx in foreground (not as daemon) so you can see the weewx 
> records, looking at the REC records (not LOOP records), what are the fields 
> being offered to archive service? then looking in weewx db, which of these 
> fields are actally being populated in db?
>
> On 22 Aug 2020, at 12:24 pm, Timothy Buchanan  
> wrote:
>
> I think you're being helpful, not harping, and I appreciate it. I just 
> restarted weewx with [[field_map]] and found the following line in syslog:
>
> Aug 21 19:51:10 raspberrypi weewx[22309] INFO gw1000: user.gw1000: field 
> map is {'extraHumid1': 'humid1', 'extraHumid2': 'inhumid',
>  'extraTemp1': 'temp1', 'extraTemp2': 'intemp', 'soilMoist1': 'soilmoist1'}
>
> so yes, it is mapping correctly but something is preventing these values 
> from being placed in the database, where they are all null. Incidentally, 
> if I use [[field_map_extension]] it is ignored and I get the latter three 
> values as before. So what could be keeping the mapped GW1000 service from 
> the database?
>
> On Friday, August 21, 2020 at 2:31:05 PM UTC-6 gjr80 wrote:
>
>> Sorry if you think I am harping on the [[field_map]] issue but I need to 
>> understand if we are trying to track down a field map issue or something 
>> else. Is the log extract you just posted with [[field map]] or 
>> [[field_map]]? because again it shows the setting was ignored.
>>
>> The reason that [[field map]] partially works is that it is completely 
>> ignored and the default map used, this results in GW1000 fields intemp and 
>> in humid being discarded because their mapped locations (WeeWX fields 
>> inTemp and inHumidity) are already populated. The GW1000 driver is coded to 
>> use two field map type stanzas; [[field_map]] and [[field_map_extensions]]. 
>> As far as the field map is concerned anything else is ignored.
>>
>> Gary
>>
>> On Saturday, 22 August 2020 at 02:59:26 UTC+10 timothye...@gmail.com 
>> wrote:
>>
>>> Yes, the GW1000 disconnected and I moved it close to the router for 
>>> testing, where I can see it. the router reserves an ip for it. I decided to 
>>> start over. I uninstalled the extension, went back to an earlier weewx.conf 
>>> then reinstalled the extension. I modified weewx.conf as shown in the 
>>> github page, and placed this in weewx.conf:
>>>
>>> # Options for extension 'GW1000'
>>> [GW1000]
>>> driver = user.gw1000
>>> [[field map]]
>>> extraTemp2  = intemp
>>> extraHumid2  = inhumid
>>> extraTemp1 = temp1
>>> extraHumid1 = humid1
>>> soilMoist1 = soilmoist1
>>>
>>> I've attached a syslog extract. I tried using [[field_map]], and that 
>>> made all values null. Using [[field map]] gives the last three values. 
>>> Maybe you could post a working GW Options field, and I will paste that into 
>>> my weewx.conf and see what happens.
>>>
>>> On Thursday, August 20, 2020 at 8:37:57 PM UTC-6 gjr80 wrote:
>>>
 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

Re: [weewx-user] Re: GW1000 output and database

[Graham Eddy]

when you run weewx in foreground (not as daemon) so you can see the weewx 
records, looking at the REC records (not LOOP records), what are the fields 
being offered to archive service? then looking in weewx db, which of these 
fields are actally being populated in db?

> On 22 Aug 2020, at 12:24 pm, Timothy Buchanan  
> wrote:
> 
> I think you're being helpful, not harping, and I appreciate it. I just 
> restarted weewx with [[field_map]] and found the following line in syslog:
> 
> Aug 21 19:51:10 raspberrypi weewx[22309] INFO gw1000: user.gw1000: field map 
> is {'extraHumid1': 'humid1', 'extraHumid2': 'inhumid',
>  'extraTemp1': 'temp1', 'extraTemp2': 'intemp', 'soilMoist1': 'soilmoist1'}
> 
> so yes, it is mapping correctly but something is preventing these values from 
> being placed in the database, where they are all null. Incidentally, if I use 
> [[field_map_extension]] it is ignored and I get the latter three values as 
> before. So what could be keeping the mapped GW1000 service from the database?
> 
> On Friday, August 21, 2020 at 2:31:05 PM UTC-6 gjr80 wrote:
> Sorry if you think I am harping on the [[field_map]] issue but I need to 
> understand if we are trying to track down a field map issue or something 
> else. Is the log extract you just posted with [[field map]] or [[field_map]]? 
> because again it shows the setting was ignored.
> 
> The reason that [[field map]] partially works is that it is completely 
> ignored and the default map used, this results in GW1000 fields intemp and in 
> humid being discarded because their mapped locations (WeeWX fields inTemp and 
> inHumidity) are already populated. The GW1000 driver is coded to use two 
> field map type stanzas; [[field_map]] and [[field_map_extensions]]. As far as 
> the field map is concerned anything else is ignored.
> 
> Gary
> 
> On Saturday, 22 August 2020 at 02:59:26 UTC+10 timothye...@gmail.com 
>  wrote:
> Yes, the GW1000 disconnected and I moved it close to the router for testing, 
> where I can see it. the router reserves an ip for it. I decided to start 
> over. I uninstalled the extension, went back to an earlier weewx.conf then 
> reinstalled the extension. I modified weewx.conf as shown in the github page, 
> and placed this in weewx.conf:
> 
> # Options for extension 'GW1000'
> [GW1000]
> driver = user.gw1000
>   [[field map]]
>   extraTemp2  = intemp
>   extraHumid2  = inhumid
>   extraTemp1 = temp1
>   extraHumid1 = humid1
>   soilMoist1 = soilmoist1
> 
> I've attached a syslog extract. I tried using [[field_map]], and that made 
> all values null. Using [[field map]] gives the last three values. Maybe you 
> could post a working GW Options field, and I will paste that into my 
> weewx.conf and see what happens.
> 
> On Thursday, August 20, 2020 at 8:37:57 PM UTC-6 gjr80 wrote:
> 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': '