subject:"Re\: \[weewx\-user\] Re\: New GW1000 Driver available for testing"

Google Groups does NOT like a file names syslog. Perhaps syslog.txt will 
get through.

On Tuesday, August 4, 2020 at 2:24:23 PM UTC-5 Bill Arthur wrote:

> Gary,
> I'll grab and post the info this evening. 
> It looks like this happens only when booting, as if weewx starts before 
> the WiFi has stabilized. 
>
> On Tuesday, August 4, 2020 at 3:30:09 AM UTC-5 gjr80 wrote:
>
>> Bill,
>>
>> For some reason the driver was unable to communicate with (one of) your 
>> GW1000(s). Before you get the log could you set debug = 3 in weewx.conf, 
>> restart WeeWX then post the log from startup through until the error. Would 
>> also help if you could post your [GW1000] stanza from WeeWX.conf.
>>
>> Gary
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5e7aaf86-ebc7-47b1-9bf1-95c92aeeb088n%40googlegroups.com.

Aug  4 22:29:24 OpiQ-12 fake-hwclock[69]: Wed 05 Aug 2020 03:29:09 AM UTC
Aug  4 22:29:24 OpiQ-12 systemd-fsck[93]: e2fsck 1.44.5 (15-Dec-2018)
Aug  4 22:29:24 OpiQ-12 systemd-fsck[93]: rootfs: clean, 45622/1899328 files, 
450859/7725184 blocks
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started File System Check on Root Device.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Starting Remount Root and Kernel File 
Systems...
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started udev Coldplug all Devices.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Starting Helper to synchronize boot up for 
ifupdown...
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started Helper to synchronize boot up for 
ifupdown.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started Remount Root and Kernel File 
Systems.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Starting Create System Users...
Aug  4 22:29:24 OpiQ-12 systemd[1]: Starting Load/Save Random Seed...
Aug  4 22:29:24 OpiQ-12 systemd[1]: Condition check resulted in Rebuild 
Hardware Database being skipped.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Starting Flush Journal to Persistent 
Storage...
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started Set the console keyboard layout.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started Create System Users.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started Load/Save Random Seed.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Starting Create Static Device Nodes in 
/dev...
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started Flush Journal to Persistent Storage.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started Create Static Device Nodes in /dev.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Reached target Local File Systems (Pre).
Aug  4 22:29:24 OpiQ-12 systemd[1]: Starting udev Kernel Device Manager...
Aug  4 22:29:24 OpiQ-12 systemd[1]: Started udev Kernel Device Manager.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Found device /dev/serial1.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Found device 
/dev/disk/by-partuuid/c595048a-01.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Starting File System Check on 
/dev/disk/by-partuuid/c595048a-01...
Aug  4 22:29:24 OpiQ-12 systemd[1]: Condition check resulted in Huge Pages File 
System being skipped.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Condition check resulted in FUSE Control 
File System being skipped.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Condition check resulted in Set Up 
Additional Binary Formats being skipped.
Aug  4 22:29:24 OpiQ-12 systemd[1]: Condition check resulted in Rebuild 
Hardware Database being skipped.
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] Booting Linux on physical CPU 0x0
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] Linux version 5.4.51+ 
(dom@buildbot) (gcc version 4.9.3 (crosstool-NG 
crosstool-ng-1.22.0-88-g8460611)) #1327 Thu Jul 23 10:53:06 BST 2020
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] CPU: ARMv6-compatible processor 
[410fb767] revision 7 (ARMv7), cr=00c5387d
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] CPU: PIPT / VIPT nonaliasing 
data cache, VIPT nonaliasing instruction cache
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] OF: fdt: Machine model: 
Raspberry Pi Zero W Rev 1.1
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] Memory policy: Data cache 
writeback
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] Reserved memory: created CMA 
memory pool at 0x17c0, size 64 MiB
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] OF: reserved mem: initialized 
node linux,cma, compatible id shared-dma-pool
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] On node 0 totalpages: 114688
Aug  4 22:29:24 OpiQ-12 kernel: [0.00]   Normal zone: 896 pages used 
for memmap
Aug  4 22:29:24 OpiQ-12 kernel: [0.00]   Normal zone: 0 pages reserved
Aug  4 22:29:24 OpiQ-12 kernel: [0.00]   Normal zone: 114688 pages, 
LIFO batch:31
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] pcpu-alloc: s0 r0 d32768 u32768 
alloc=1*32768
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] pcpu-alloc: [0] 0 
Aug  4 22:29:24 OpiQ-12 kernel: [0.00] Built 1 z

Re: [weewx-user] Re: New GW1000 Driver available for testing

Gary,
Here's the log and stanza. As I suspected, wlan0 was not stable until after 
WeeWx exited.
Perhaps this is specific to the Pi Zero W.

-- 
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/3f235da3-a20a-4f10-9392-57e9fe44694en%40googlegroups.com.
[GW1000]
driver = user.gw1000

poll_interval = 32  
ip_address = 192.168.0.104  

port = 45000  

At the time of the test which is recorded in the syslog, I had commented out 
the IP address.

Re: [weewx-user] Re: New GW1000 Driver available for testing

Gary,
I'll grab and post the info this evening. 
It looks like this happens only when booting, as if weewx starts before the 
WiFi has stabilized. 

On Tuesday, August 4, 2020 at 3:30:09 AM UTC-5 gjr80 wrote:

> Bill,
>
> For some reason the driver was unable to communicate with (one of) your 
> GW1000(s). Before you get the log could you set debug = 3 in weewx.conf, 
> restart WeeWX then post the log from startup through until the error. Would 
> also help if you could post your [GW1000] stanza from WeeWX.conf.
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7ff02b43-ffe2-4e1e-b44b-827cf2daf5d1n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-04 Thread gjr80

Bill,

For some reason the driver was unable to communicate with (one of) your 
GW1000(s). Before you get the log could you set debug = 3 in weewx.conf, 
restart WeeWX then post the log from startup through until the error. Would 
also help if you could post your [GW1000] stanza from WeeWX.conf.

Gary

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

I hope I'm not making rookie mistakes, but I get the following when doing a 
fresh install on a Pi-zero. Nothing else is added, just weewx and the 
GW-1000 driver. I'll pull all the required logs tomorrow, but here is what 
I'm seeing on a reboot:

Aug  4 02:00:48 OpiQ-12 dhcpcd[261]: wlan0: soliciting an IPv6 router
Aug  4 02:00:48 OpiQ-12 weewx[367] INFO weewx.engine: Loading station type 
GW1000 (user.gw1000)
Aug  4 02:00:48 OpiQ-12 weewx[367] ERROR gw1000: user.gw1000: Failed to 
send command 'CMD_READ_' after 3 attempts
Aug  4 02:00:48 OpiQ-12 weewx[367] ERROR weewx.engine: Import of driver 
failed: 'NoneType' object has no attribute '__getitem__' ()
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine:   
Traceback (most recent call last):
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine: File 
"/usr/share/weewx/weewx/engine.py", line 103, in setupStation
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine:   
self.console = loader_function(config_dict, self)
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 1021, in loader
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine:   
return Gw1000Driver(**config_dict[DRIVER_NAME])
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 1271, in __init__
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine:   
super(Gw1000Driver, self).__init__(**stn_dict)
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 728, in __init__
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine:   
use_th32=use_th32)
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine: File 
"/usr/share/weewx/user/gw1000.py", line 1463, in __init__
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine:   
is_wh24 = six.indexbytes(_sys_params, 5) == 0
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine: File 
"/usr/share/weewx/six.py", line 661, in indexbytes
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine:   
return ord(buf[i])
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL weewx.engine:   
TypeError: 'NoneType' object has no attribute '__getitem__'
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL __main__: Unable to load 
driver: 'NoneType' object has no attribute '__getitem__'
Aug  4 02:00:48 OpiQ-12 weewx[367] CRITICAL __main__:   Exiting...


On Monday, August 3, 2020 at 10:25:47 PM UTC-5 gjr80 wrote:

> On Tuesday, 4 August 2020 07:44:37 UTC+10, Paul Anderson wrote:
>>
>> So I guess I'm a perdoid control freak
>>
>
> I hope that is not too painful :)
>
> The other point of concern is over blindly pasting the full  [Accumulator] 
>> stanza into weewx.conf when running as a service. Feel it's really easy for 
>> someone not to realize the unattended consequences caused by the fact that 
>> this will affect the Accumulator type for fields generated by the normal 
>> driver and other services in use in addition to the GW1000 service.
>>
>
> Just to be clear let's work through this when using the GW1000 driver as a 
> service. Every field accumulated by the accumulator has a default extractor 
> of 'avg' (which gives the average of all loop values seen in the archive 
> period to date). If the field concerned is populated and is being mapped 
> through from the GW1000 to WeeWX under the default field map then all is 
> good, the appropriate extractor is being/will be used. If the field is 
> populated by the (non-GW1000) driver or some other service and if that 
> field was relying on the default extractor, then the GW1000 installer would 
> clobber that default extractor. If the other field had an explicit 
> extractor in weewx.conf then wee_extension would respect that existing 
> setting and it would not be clobbered. If the user defines a field map 
> using [[field_map]] or alters the default field map with 
> [[field_map_extensions]] then wee_extension will not know about these 
> changes and potentially the newly mapped field will have the wrong 
> extractor. So there are a couple of corner cases that could cause issues, 
> though the latter case is just as much of an issue when using the GW1000 
> driver as a driver as it is when using it as a service.
>
> One thing to remember, the existence of an extractor entry for a field 
> that does not exist has no affect on the operation of WeeWX other than 
> taking up a few more bytes of memory/disk space.
>
> I'll put this down as an issue to look at later, for now I think it can be 
> handled with a note or two in the install instructions. In fact that may be 
> the final solution, the extension installer is only capable of so much. I 
> am hesitant to fully remove populating the extractors, I suspect doing that 
> and the follow on need for users to manually the extractors wi

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-03 Thread gjr80

On Tuesday, 4 August 2020 07:44:37 UTC+10, Paul Anderson wrote:
>
> So I guess I'm a perdoid control freak
>

I hope that is not too painful :)

The other point of concern is over blindly pasting the full  [Accumulator] 
> stanza into weewx.conf when running as a service. Feel it's really easy for 
> someone not to realize the unattended consequences caused by the fact that 
> this will affect the Accumulator type for fields generated by the normal 
> driver and other services in use in addition to the GW1000 service.
>

Just to be clear let's work through this when using the GW1000 driver as a 
service. Every field accumulated by the accumulator has a default extractor 
of 'avg' (which gives the average of all loop values seen in the archive 
period to date). If the field concerned is populated and is being mapped 
through from the GW1000 to WeeWX under the default field map then all is 
good, the appropriate extractor is being/will be used. If the field is 
populated by the (non-GW1000) driver or some other service and if that 
field was relying on the default extractor, then the GW1000 installer would 
clobber that default extractor. If the other field had an explicit 
extractor in weewx.conf then wee_extension would respect that existing 
setting and it would not be clobbered. If the user defines a field map 
using [[field_map]] or alters the default field map with 
[[field_map_extensions]] then wee_extension will not know about these 
changes and potentially the newly mapped field will have the wrong 
extractor. So there are a couple of corner cases that could cause issues, 
though the latter case is just as much of an issue when using the GW1000 
driver as a driver as it is when using it as a service.

One thing to remember, the existence of an extractor entry for a field that 
does not exist has no affect on the operation of WeeWX other than taking up 
a few more bytes of memory/disk space.

I'll put this down as an issue to look at later, for now I think it can be 
handled with a note or two in the install instructions. In fact that may be 
the final solution, the extension installer is only capable of so much. I 
am hesitant to fully remove populating the extractors, I suspect doing that 
and the follow on need for users to manually the extractors will cause just 
as many support issues.

On Tuesday, 4 August 2020 08:28:11 UTC+10, Paul Anderson wrote:

> Gary sorry to be a pain in the neck
>

Not at all, this driver is complex and has a lot of corner cases that I 
likely won't find without the help of others, thank you for your input.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/6a5421de-8aff-4353-8ae5-08868bde6282o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

It's a beautiful day!
Verified backed out my silly mod and tis works perfectly:

# Options for extension 'GW1000'
[GW1000]
driver = user.gw1000
[[field_map]]
inTemp = intemp
inHumidity = inhumid
pressure = absbarometer
dateTime = datetime
extraTemp2 = temp2
extraTemp3 = temp3
extraTemp4 = temp4
extraTemp5 = temp5
extraHumid2 = humid2
extraHumid3 = humid3
extraHumid4 = humid4
extraHumid5 = humid5
lightning_distance = lightningdist
lightning_last_det_time = lightningdettime
lightning_strike_count = lightning_strike_count
wh31_ch2_batt = wh31_ch2_batt
wh31_ch3_batt = wh31_ch3_batt
wh31_ch4_batt = wh31_ch4_batt
wh31_ch5_batt = wh31_ch5_batt
wh57_batt = wh57_batt
##
[Accumulator]
[[lightning_strike_count]]
extractor = sum
[[lightning_last_det_time]]
extractor = last
[[lightning_distance]]
extractor = last
[[wh31_ch2_batt]]
extractor = last
[[wh31_ch3_batt]]
extractor = last
[[wh31_ch4_batt]]
extractor = last
[[wh31_ch5_batt]]
extractor = last
[[wh57_batt]]
extractor = last
Gary sorry to be a pain in the neck, and big thank you for all your hard
work,

Paul

On Mon, Aug 3, 2020 at 5:59 PM Paul Anderson  wrote:

> Duh sorry I missed your point Gary! So all I have to do is move my fields
> from battery field map up to field map in weeex.conf and all will be.
> Sorry sometimes I can't see the forest for the trees.
>
> --
> 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/ae7bf7f2-44c1-4e1f-ba4f-49b92a405685o%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/CAOAVAee2nWi-hA1bOrDq1V%2B1A_ytX00LXPE8B3CXbbgQasKh9w%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-03 Thread Paul Anderson

Duh sorry I missed your point Gary! So all I have to do is move my fields from 
battery field map up to field map in weeex.conf and all will be.
Sorry sometimes I can't see the forest for the trees.

-- 
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/ae7bf7f2-44c1-4e1f-ba4f-49b92a405685o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

Hi Gary,
So I guess I'm a perdoid control freak but when run as a service it's just
to supplement data provided by my normal driver, and other services. I get
paranoid over what the service has the ability to map too. Because I only
have 4 WH31 , 1 WH 57, and the Gw 1000 itself it is way easier to tell it
what I want versus what I don't want. Owning the mapping and being able to
keep it in weewx.config is exactly what I want. However without the
modification I suggested no battery_field_map is loaded from weewx.conf or
the driver code.
So with this in weewx.conf

[GW1000]
driver = user.gw1000

[[field_map]]
inTemp = intemp
inHumidity = inhumid
pressure = absbarometer
dateTime = datetime
extraTemp2 = temp2
extraTemp3 = temp3
extraTemp4 = temp4
extraTemp5 = temp5
extraHumid2 = humid2
extraHumid3 = humid3
extraHumid4 = humid4
extraHumid5 = humid5
lightning_distance = lightningdist
lightning_last_det_time = lightningdettime
lightning_strike_count = lightning_strike_count

[[battery_field_map]]
   wh31_ch2_batt = wh31_ch2_batt
   wh31_ch3_batt = wh31_ch3_batt
   wh31_ch4_batt = wh31_ch4_batt
   wh31_ch5_batt = wh31_ch5_batt
   wh57_batt = wh57_batt
[Accumulator]
[[lightning_strike_count]]
extractor = sum
[[lightning_last_det_time]]
extractor = last
[[lightning_distance]]
extractor = last
[[wh31_ch2_batt]]
extractor = last
[[wh31_ch3_batt]]
extractor = last
[[wh31_ch4_batt]]
extractor = last
[[wh31_ch5_batt]]
extractor = last
[[wh57_batt]]
extractor = last

No battery_field_map is applied at all.
 The other point of concern is over blindly pasting the full  [Accumulator]
stanza into weewx.conf when running as a service. Feel it's really easy for
someone not to realize the unattended consequences caused by the fact that
this will affect the Accumulator type for fields generated by the normal
driver and other services in use in addition to the GW1000 service.





On Mon, Aug 3, 2020 at 4:51 PM gjr80  wrote:

> Paul,
>
> The current field_map behaviour is deliberate, it probably doesn’t help
> that I have not documented the behaviour yet. The expected behaviour is:
>
> 1. If the user specifies nothing the default field map is used. (The
> default field map can be viewed by running the driver directly with the
> —default-map command line option. The default field map happens to be
> constructed from the field map dict and battery map dict)
>
> 2. The user can specify a mapping under [field_map], in this case the user
> specified field map replaces the default field map, in other words the user
> takes full responsibility for the field map. You can run the driver
> directly using the —live-data command line option to see what data ,
> including battery state data, is available from the GW1000 for mapping. You
> can extend the [field_map] with [field_map_extensions] but why would you.
>
> 3. If the user is happy with the default field map but wants to map a few
> fields differently they can use [field_map_extensions] to modify the field
> map rathe4 than having to specify every mapping with [field_map].
> [field_map_extensions] are used to modify the field map (typically the
> default field map), basically any GW1000 ‘fields’ in the
> [field_map_extensions] are removed from the field map then the
> [field_map_extensions] entries are added to the field map.
>
> The behaviour above is fairly much standard among drivers that use
> field/sensor maps with [field_map] and [field_map_extensions].
>
> I will document this in the driver wiki shortly.
>
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/9cfb56c1-fc22-4281-b4a5-4e0bf84efcabo%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/CAOAVAeecEVWzPDyZRkn%3D4U_xX5Xc4mO2kvQNM48yyUy5e%2BumRg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-03 Thread gjr80

Paul,

The current field_map behaviour is deliberate, it probably doesn’t help that I
have not documented the behaviour yet. The expected behaviour is:

1. If the user specifies nothing the default field map is used. (The default
field map can be viewed by running the driver directly with the —default-map
command line option. The default field map happens to be constructed from the
field map dict and battery map dict)

2. The user can specify a mapping under [field_map], in this case the user
specified field map replaces the default field map, in other words the user
takes full responsibility for the field map. You can run the driver directly
using the —live-data command line option to see what data , including battery
state data, is available from the GW1000 for mapping. You can extend the
[field_map] with [field_map_extensions] but why would you.

3. If the user is happy with the default field map but wants to map a few
fields differently they can use [field_map_extensions] to modify the field map
rathe4 than having to specify every mapping with [field_map].
[field_map_extensions] are used to modify the field map (typically the default
field map), basically any GW1000 ‘fields’ in the [field_map_extensions] are
removed from the field map then the [field_map_extensions] entries are added to
the field map.

The behaviour above is fairly much standard among drivers that use field/sensor
maps with [field_map] and [field_map_extensions].

I will document this in the driver wiki shortly.

Gary

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

Forgot to say that user would need to add [[battery_field_map]] to
weewx.conf as well

On Mon, Aug 3, 2020 at 12:13 PM Paul R Anderson  wrote:

> Gary
> V 10 as a service is almost 100% there.
> However if you add a
> [[field_map]] stanza to weewx.config, it gets honored correctly,
> however with the current logic we don't get a battery_field_map added at
> all.
> One way to fix, altho you probably have a more eloquent solution is:
>"""Initialise a GW1000 object."""
> # construct the field map, first obtain the field map from our
> config
> field_map = gw1000_config.get('field_map')
> # construct the battery state field map
> battery_field_map = gw1000_config.get('battery_field_map')
> # now add in the battery state field map
> field_map.update(battery_field_map)
> # obtain any field map extensions from our config
> No changes after that.
> Wow this thing is getting more complicated by the day 😁
>
>
>
>
> On Mon, Aug 3, 2020 at 10:41 AM gjr80  wrote:
>
>> I have released v0.1.0b10 on Github
>> . The changes include:
>>
>> - renamed --ip command line option to --ip-address
>> - reworked field map processing, field_map_extensions entries should no
>> longer result in multiple mapping for GW1000 'fields'
>> - --system-params command line option should now show the correct GW1000
>> time
>> - reworked up front installation/setup comments in gw1000.py
>> - GW1000 driver and service now use the same [GW1000] config stanza in
>> weewx.conf
>> - when run directly the source of the IP address and port settings is
>> printed to console if debug >= 1
>> - when run directly any --ip-address and --port command line options
>> override any IP address and port settings in weewx.conf,  if --ip-address
>> and/or --port are not specified ip_address and/or port from the [G1000]
>> stanza in weewx.conf are used otherwise the address of the first
>> discovered GW1000 is used
>>
>> b10 only changes weewx.conf if you were using the GW1000 driver as a
>> service; however, upgrading to b10 by downloading the b10 extension package
>> and installing with the wee_extension utility is the preferred means of
>> installing/upgrading to b10. If you are using the GW1000 driver as a
>> service upgrading with wee_extension will see a [GW1000] stanza with
>> default install settings added to weewx.conf, after upgrading just copy
>> your [Gw1000Service] settings to [GW1000] then delete [Gw1000Service] in
>> toto.
>>
>> Gary
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-user+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/280188a8-eb94-401a-95af-5f0d36196774o%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/CAOAVAedO3_MneViVdHZyBGWJ4H20qKfw5sE4J0gpy5CqzALwaA%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

Gary
V 10 as a service is almost 100% there.
However if you add a
[[field_map]] stanza to weewx.config, it gets honored correctly,
however with the current logic we don't get a battery_field_map added at
all.
One way to fix, altho you probably have a more eloquent solution is:
   """Initialise a GW1000 object."""
# construct the field map, first obtain the field map from our
config
field_map = gw1000_config.get('field_map')
# construct the battery state field map
battery_field_map = gw1000_config.get('battery_field_map')
# now add in the battery state field map
field_map.update(battery_field_map)
# obtain any field map extensions from our config
No changes after that.
Wow this thing is getting more complicated by the day 😁




On Mon, Aug 3, 2020 at 10:41 AM gjr80  wrote:

> I have released v0.1.0b10 on Github
> . The changes include:
>
> - renamed --ip command line option to --ip-address
> - reworked field map processing, field_map_extensions entries should no
> longer result in multiple mapping for GW1000 'fields'
> - --system-params command line option should now show the correct GW1000
> time
> - reworked up front installation/setup comments in gw1000.py
> - GW1000 driver and service now use the same [GW1000] config stanza in
> weewx.conf
> - when run directly the source of the IP address and port settings is
> printed to console if debug >= 1
> - when run directly any --ip-address and --port command line options
> override any IP address and port settings in weewx.conf,  if --ip-address
> and/or --port are not specified ip_address and/or port from the [G1000]
> stanza in weewx.conf are used otherwise the address of the first
> discovered GW1000 is used
>
> b10 only changes weewx.conf if you were using the GW1000 driver as a
> service; however, upgrading to b10 by downloading the b10 extension package
> and installing with the wee_extension utility is the preferred means of
> installing/upgrading to b10. If you are using the GW1000 driver as a
> service upgrading with wee_extension will see a [GW1000] stanza with
> default install settings added to weewx.conf, after upgrading just copy
> your [Gw1000Service] settings to [GW1000] then delete [Gw1000Service] in
> toto.
>
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/280188a8-eb94-401a-95af-5f0d36196774o%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/CAOAVAee9mc1bGwo3GGweCuavmw_kaJf17STP7M2ViMPbW%3DRRxg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-03 Thread Graham Eddy

that fixed mappings using gw1000 as service - thanks

> On 4 Aug 2020, at 12:41 am, gjr80  wrote:
> 
> I have released v0.1.0b10 on Github 
> . The changes include:
> 
> - renamed --ip command line option to --ip-address
> - reworked field map processing, field_map_extensions entries should no 
> longer result in multiple mapping for GW1000 'fields'
> - --system-params command line option should now show the correct GW1000 time
> - reworked up front installation/setup comments in gw1000.py
> - GW1000 driver and service now use the same [GW1000] config stanza in 
> weewx.conf
> - when run directly the source of the IP address and port settings is printed 
> to console if debug >= 1
> - when run directly any --ip-address and --port command line options override 
> any IP address and port settings in weewx.conf,  if --ip-address and/or 
> --port are not specified ip_address and/or port from the [G1000] stanza in 
> weewx.conf are used otherwise the address of the first discovered GW1000 is 
> used
> 
> b10 only changes weewx.conf if you were using the GW1000 driver as a service; 
> however, upgrading to b10 by downloading the b10 extension package and 
> installing with the wee_extension utility is the preferred means of 
> installing/upgrading to b10. If you are using the GW1000 driver as a service 
> upgrading with wee_extension will see a [GW1000] stanza with default install 
> settings added to weewx.conf, after upgrading just copy your [Gw1000Service] 
> settings to [GW1000] then delete [Gw1000Service] in toto.
> 
> Gary
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/280188a8-eb94-401a-95af-5f0d36196774o%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/42BE3D28-143F-469B-9A06-CB8884E47064%40gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-03 Thread gjr80

I have released v0.1.0b10 on Github 
. The changes include:

- renamed --ip command line option to --ip-address
- reworked field map processing, field_map_extensions entries should no 
longer result in multiple mapping for GW1000 'fields'
- --system-params command line option should now show the correct GW1000 
time
- reworked up front installation/setup comments in gw1000.py
- GW1000 driver and service now use the same [GW1000] config stanza in 
weewx.conf
- when run directly the source of the IP address and port settings is 
printed to console if debug >= 1
- when run directly any --ip-address and --port command line options 
override any IP address and port settings in weewx.conf,  if --ip-address 
and/or --port are not specified ip_address and/or port from the [G1000] 
stanza in weewx.conf are used otherwise the address of the first discovered 
GW1000 is used

b10 only changes weewx.conf if you were using the GW1000 driver as a 
service; however, upgrading to b10 by downloading the b10 extension package 
and installing with the wee_extension utility is the preferred means of 
installing/upgrading to b10. If you are using the GW1000 driver as a 
service upgrading with wee_extension will see a [GW1000] stanza with 
default install settings added to weewx.conf, after upgrading just copy 
your [Gw1000Service] settings to [GW1000] then delete [Gw1000Service] in 
toto.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/280188a8-eb94-401a-95af-5f0d36196774o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-03 Thread galfert

Ok, thank you for the explanation. Good to hear that WeeWX has some 
controls for non-responding stations and that you were already thinking 
about utilizing them. 


On Sunday, August 2, 2020 at 11:41:15 PM UTC-4 gjr80 wrote:

> Answers/comments below.
>
> Gary
>
> On Monday, 3 August 2020 13:05:31 UTC+10, galfert wrote:
>>
>> If you only have one GW1000 is there an advantage to still specifying the 
>> IP address in weewx.conf? 
>
>
> Only in as much as it will save half a second during initialisation.
>  
>
>> I'm wondering if specifying the IP address allows for more timely data 
>> access, as the driver doesn't need to find the GW1000. Also once the GW1000 
>> is found by 'auto' setting, how long does it keep that found address set 
>> for? 
>>
>
> Not really, refer to my previous comment. The GW1000 is discovered once 
> during initialisation and the (chosen) IP address retained.
>
> What happens if the DHCP sever decides to renew the GW1000 IP address with 
>> a different IP address, like for example the GW1000 gets restarted and it 
>> ends up with a new IP address but WeeWX never stopped running? Is there a 
>> potential to lose the GW1000 connection if 'auto' is used if the IP address 
>> changes unexpectedly? Or does the driver only search for a new IP address 
>> if there is no response from the previous found IP address?
>>
>
> If the GW1000 is allocated a different address by DHCP for some reason 
> then at present the connection to the GW1000 will be lost until WeeWX is 
> restarted/reloaded. 
>
> In short what is the programmed logic behind finding, using, and finding 
>> again if needed a GW1000 if set to 'auto'?
>>
>
> At the moment it is very basic, unless an IP address is specified by the 
> user a one off discovery occurs and an IP address chosen, retained and used 
> until WeeWX restart/reload. 
>
> Perhaps there is a better way than this below logic...but in my likely 
>> short sighted view I would expect for the 'auto' setting the following 
>> behavior (I think).
>> - Search for IP and continue to search indefinitely until GW1000 found
>> - Store IP address of found GW1000
>> - Repeatedly Continue querying GW1000 for data using found IP address 
>> unless no response to weather data request occurs
>> - If no response from found IP address then go back to search again for 
>> IP address
>>
>
> Yes, there certainly is a better way of doing things. It was always my 
> intent that something would be done if contact with the GW1000 was lost, 
> exactly what that is I don't know and it was something I planned to tackle 
> later. I am hesitant to have the driver continually search for a device, I 
> would much rather have the driver conduct a search limited in time or 
> attempts and then hand things back to WeeWX for WeeWX to make the decision 
> whether to continue or exit (WeeWX has some logic/controls built in to it 
> to handle stations that don't respond/lose connectivity). But that is yet 
> to be determined implementation detail.
>
>>
>> If that in fact in the logic then using 'auto' or configuring a static IP 
>> in weewx.conf probably doesn't matter and it doesn't really add overhead to 
>> the system looking for a GW1000...unless one is never found. But if setting 
>> it to 'auto' somehow makes it so that it often (every 5 minutes or some 
>> other interval) or perhaps before every new weather data request is 
>> received it needs to be checked for what IP address to query then that to 
>> me seems like overhead that probably could better be avoided by just using 
>> a static IP in the weewx.conf.
>>
>
> If anything auto will cause a new discovery upon a timeout occurring when 
> the driver tries to obtain data from the GW1000, there will be no 
> regular/scheduled connectivity check, other than checking that a response 
> is received to any command from driver to GW1000. But that is something the 
> driver does already anyway.
>
>
>> On Sunday, August 2, 2020 at 10:33:47 PM UTC-4 gjr80 wrote:
>>
>>> Hi Bill,
>>>
>>> Yes that will cause problems. I have two GW1000 on my network and the 
>>> when run as a driver/service the ip_address setting has always been 
>>> honoured in my testing. Running the driver directly is a little different, 
>>> I thought i had coded the driver such that it would take the IP address 
>>> from weewx.conf or the command line, seems I never included weewx.conf and 
>>> it was being ignored. b9 and earlier exhibited the following behaviour:
>>>
>>>- when run as a driver/service as part of a running WeeWX install:
>>>
>>>
>>>1. if an IP address is specified at [GW1000] ip_address that IP 
>>>   address is used
>>>   2. if [GW1000] ip_address is 'auto' or the setting is omitted the 
>>>   driver searches for GW1000 on the local network and uses the address 
>>> of the 
>>>   first GW1000 that responds
>>>
>>>
>>>- when run directly:
>>>
>>>
>>>1. if --ip is specified  on the command line that IP address is used
>>>

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-02 Thread gjr80

Answers/comments below.

Gary

On Monday, 3 August 2020 13:05:31 UTC+10, galfert wrote:
>
> If you only have one GW1000 is there an advantage to still specifying the 
> IP address in weewx.conf? 

Only in as much as it will save half a second during initialisation.

> I'm wondering if specifying the IP address allows for more timely data 
> access, as the driver doesn't need to find the GW1000. Also once the GW1000 
> is found by 'auto' setting, how long does it keep that found address set 
> for? 
>

Not really, refer to my previous comment. The GW1000 is discovered once 
during initialisation and the (chosen) IP address retained.

What happens if the DHCP sever decides to renew the GW1000 IP address with 
> a different IP address, like for example the GW1000 gets restarted and it 
> ends up with a new IP address but WeeWX never stopped running? Is there a 
> potential to lose the GW1000 connection if 'auto' is used if the IP address 
> changes unexpectedly? Or does the driver only search for a new IP address 
> if there is no response from the previous found IP address?
>

If the GW1000 is allocated a different address by DHCP for some reason then 
at present the connection to the GW1000 will be lost until WeeWX is 
restarted/reloaded. 

In short what is the programmed logic behind finding, using, and finding 
> again if needed a GW1000 if set to 'auto'?
>

At the moment it is very basic, unless an IP address is specified by the 
user a one off discovery occurs and an IP address chosen, retained and used 
until WeeWX restart/reload. 

Perhaps there is a better way than this below logic...but in my likely 
> short sighted view I would expect for the 'auto' setting the following 
> behavior (I think).
> - Search for IP and continue to search indefinitely until GW1000 found
> - Store IP address of found GW1000
> - Repeatedly Continue querying GW1000 for data using found IP address 
> unless no response to weather data request occurs
> - If no response from found IP address then go back to search again for IP 
> address
>

Yes, there certainly is a better way of doing things. It was always my 
intent that something would be done if contact with the GW1000 was lost, 
exactly what that is I don't know and it was something I planned to tackle 
later. I am hesitant to have the driver continually search for a device, I 
would much rather have the driver conduct a search limited in time or 
attempts and then hand things back to WeeWX for WeeWX to make the decision 
whether to continue or exit (WeeWX has some logic/controls built in to it 
to handle stations that don't respond/lose connectivity). But that is yet 
to be determined implementation detail.

>
> If that in fact in the logic then using 'auto' or configuring a static IP 
> in weewx.conf probably doesn't matter and it doesn't really add overhead to 
> the system looking for a GW1000...unless one is never found. But if setting 
> it to 'auto' somehow makes it so that it often (every 5 minutes or some 
> other interval) or perhaps before every new weather data request is 
> received it needs to be checked for what IP address to query then that to 
> me seems like overhead that probably could better be avoided by just using 
> a static IP in the weewx.conf.
>

If anything auto will cause a new discovery upon a timeout occurring when 
the driver tries to obtain data from the GW1000, there will be no 
regular/scheduled connectivity check, other than checking that a response 
is received to any command from driver to GW1000. But that is something the 
driver does already anyway.

> On Sunday, August 2, 2020 at 10:33:47 PM UTC-4 gjr80 wrote:
>
>> Hi Bill,
>>
>> Yes that will cause problems. I have two GW1000 on my network and the 
>> when run as a driver/service the ip_address setting has always been 
>> honoured in my testing. Running the driver directly is a little different, 
>> I thought i had coded the driver such that it would take the IP address 
>> from weewx.conf or the command line, seems I never included weewx.conf and 
>> it was being ignored. b9 and earlier exhibited the following behaviour:
>>
>>- when run as a driver/service as part of a running WeeWX install:
>>
>>
>>1. if an IP address is specified at [GW1000] ip_address that IP 
>>   address is used
>>   2. if [GW1000] ip_address is 'auto' or the setting is omitted the 
>>   driver searches for GW1000 on the local network and uses the address 
>> of the 
>>   first GW1000 that responds
>>
>>
>>- when run directly:
>>
>>
>>1. if --ip is specified  on the command line that IP address is used
>>   2. if --ip is not specified on the command line the driver 
>>   searches for GW1000 on the local network and uses the address of the 
>> first 
>>   GW1000 that responds
>>
>> Under b10 the behaviour will change when run directly:
>>
>>1. if --ip is specified  on the command line that IP address will be 
>>used
>>2. if --ip is not specif

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-02 Thread galfert

If you only have one GW1000 is there an advantage to still specifying the 
IP address in weewx.conf? 

I'm wondering if specifying the IP address allows for more timely data 
access, as the driver doesn't need to find the GW1000. Also once the GW1000 
is found by 'auto' setting, how long does it keep that found address set 
for? 

What happens if the DHCP sever decides to renew the GW1000 IP address with 
a different IP address, like for example the GW1000 gets restarted and it 
ends up with a new IP address but WeeWX never stopped running? Is there a 
potential to lose the GW1000 connection if 'auto' is used if the IP address 
changes unexpectedly? Or does the driver only search for a new IP address 
if there is no response from the previous found IP address?

In short what is the programmed logic behind finding, using, and finding 
again if needed a GW1000 if set to 'auto'?

Perhaps there is a better way than this below logic...but in my likely 
short sighted view I would expect for the 'auto' setting the following 
behavior (I think).
- Search for IP and continue to search indefinitely until GW1000 found
- Store IP address of found GW1000
- Repeatedly Continue querying GW1000 for data using found IP address 
unless no response to weather data request occurs
- If no response from found IP address then go back to search again for IP 
address

If that in fact in the logic then using 'auto' or configuring a static IP 
in weewx.conf probably doesn't matter and it doesn't really add overhead to 
the system looking for a GW1000...unless one is never found. But if setting 
it to 'auto' somehow makes it so that it often (every 5 minutes or some 
other interval) or perhaps before every new weather data request is 
received it needs to be checked for what IP address to query then that to 
me seems like overhead that probably could better be avoided by just using 
a static IP in the weewx.conf.

On Sunday, August 2, 2020 at 10:33:47 PM UTC-4 gjr80 wrote:

> Hi Bill,
>
> Yes that will cause problems. I have two GW1000 on my network and the when 
> run as a driver/service the ip_address setting has always been honoured 
> in my testing. Running the driver directly is a little different, I thought 
> i had coded the driver such that it would take the IP address from 
> weewx.conf or the command line, seems I never included weewx.conf and it 
> was being ignored. b9 and earlier exhibited the following behaviour:
>
>- when run as a driver/service as part of a running WeeWX install:
>
>
>1. if an IP address is specified at [GW1000] ip_address that IP 
>   address is used
>   2. if [GW1000] ip_address is 'auto' or the setting is omitted the 
>   driver searches for GW1000 on the local network and uses the address of 
> the 
>   first GW1000 that responds
>
>
>- when run directly:
>
>
>1. if --ip is specified  on the command line that IP address is used
>   2. if --ip is not specified on the command line the driver searches 
>   for GW1000 on the local network and uses the address of the first 
> GW1000 
>   that responds
>
> Under b10 the behaviour will change when run directly:
>
>1. if --ip is specified  on the command line that IP address will be 
>used
>2. if --ip is not specified on the command line weewx.conf is checked 
>and [GW1000] ip_address will be used if set
>3. if --ip is not specified on the command line and there is nothing 
>under [GW1000] in weewx.conf the driver searches for GW1000 on the 
>local network and uses the address of the first GW1000 that responds
>
> The behaviour when run as part of a running WeeWX install will not change.
>
> Gary
>
> On Sunday, 2 August 2020 13:09:34 UTC+10, Bill Arthur wrote:
>>
>> Hi Gary,
>> I believe I found my problem. Sorry to have caused any confusion.
>> After I ran wee_install I saw the GW1000 stanzas at the end of weewx.conf 
>> and I falsely assumed it was configured.
>> I had a ton of problems because I didn't run wee_config.
>>
>> On Saturday, August 1, 2020 at 12:41:19 AM UTC-5 Bill Arthur wrote:
>>
>>> Hi Gary,
>>> I wasn't able to make time to get the logs tonight. I'll try again 
>>> tomorrow.
>>> But I did test running the driver directly. I have three GW-1000s, 
>>> 192.168.0.104, 204 and 205.
>>> Out of ten runs it chooses 204 four times, 205 four times and 104 two 
>>> times.
>>>
>>> # Options for extension 'GW1000'
>>> 
>>> [Accumulator]
>>>
>>> [[lightning_strike_count]]  
>>> 
>>> extractor = sum  
>>> 
>>> [[lightning_last_det_time]]

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-02 Thread gjr80

Hi Bill,

Yes that will cause problems. I have two GW1000 on my network and the when 
run as a driver/service the ip_address setting has always been honoured in 
my testing. Running the driver directly is a little different, I thought i 
had coded the driver such that it would take the IP address from weewx.conf 
or the command line, seems I never included weewx.conf and it was being 
ignored. b9 and earlier exhibited the following behaviour:

   - when run as a driver/service as part of a running WeeWX install:

   1. if an IP address is specified at [GW1000] ip_address that IP address 
  is used
  2. if [GW1000] ip_address is 'auto' or the setting is omitted the 
  driver searches for GW1000 on the local network and uses the address of 
the 
  first GW1000 that responds

   - when run directly:

   1. if --ip is specified  on the command line that IP address is used
  2. if --ip is not specified on the command line the driver searches 
  for GW1000 on the local network and uses the address of the first GW1000 
  that responds

Under b10 the behaviour will change when run directly:

   1. if --ip is specified  on the command line that IP address will be used
   2. if --ip is not specified on the command line weewx.conf is checked 
   and [GW1000] ip_address will be used if set
   3. if --ip is not specified on the command line and there is nothing 
   under [GW1000] in weewx.conf the driver searches for GW1000 on the local 
   network and uses the address of the first GW1000 that responds

The behaviour when run as part of a running WeeWX install will not change.

Gary

On Sunday, 2 August 2020 13:09:34 UTC+10, Bill Arthur wrote:
>
> Hi Gary,
> I believe I found my problem. Sorry to have caused any confusion.
> After I ran wee_install I saw the GW1000 stanzas at the end of weewx.conf 
> and I falsely assumed it was configured.
> I had a ton of problems because I didn't run wee_config.
>
> On Saturday, August 1, 2020 at 12:41:19 AM UTC-5 Bill Arthur wrote:
>
>> Hi Gary,
>> I wasn't able to make time to get the logs tonight. I'll try again 
>> tomorrow.
>> But I did test running the driver directly. I have three GW-1000s, 
>> 192.168.0.104, 204 and 205.
>> Out of ten runs it chooses 204 four times, 205 four times and 104 two 
>> times.
>>
>> # Options for extension 'GW1000'  
>>   
>> [Accumulator]
>>
>> [[lightning_strike_count]]
>>   
>> extractor = sum  
>> 
>> [[lightning_last_det_time]]  
>>
>> extractor = last  
>> 
>> 
>>   
>> ##
>>   
>> 
>> 
>> 
>> # Options for extension 'GW1000'  
>>  
>>  [GW1000]
>>
>>  driver = user.gw1000
>> 
>> ip_address = 192.168.0.104
>> 
>> 
>>   
>> 
>>
>> On Friday, July 31, 2020 at 4:21:43 PM UTC-5 gjr80 wrote:
>>
>>> Bill,
>>>
>>> Does this occur every time or occasionally? Could you post your [GW1000] 
>>> stanza, the output from my previous post should contain everything else I 
>>> need to troubleshoot this issue.
>>>
>>> Gary
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2f27f67e-cbf7-496d-8cea-89946c81b315o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-08-01 Thread Bill Arthur

Hi Gary,
I believe I found my problem. Sorry to have caused any confusion.
After I ran wee_install I saw the GW1000 stanzas at the end of weewx.conf 
and I falsely assumed it was configured.
I had a ton of problems because I didn't run wee_config.

On Saturday, August 1, 2020 at 12:41:19 AM UTC-5 Bill Arthur wrote:

> Hi Gary,
> I wasn't able to make time to get the logs tonight. I'll try again 
> tomorrow.
> But I did test running the driver directly. I have three GW-1000s, 
> 192.168.0.104, 204 and 205.
> Out of ten runs it chooses 204 four times, 205 four times and 104 two 
> times.
>
> # Options for extension 'GW1000'  
>   
> [Accumulator]  
>  
> [[lightning_strike_count]]
>   
> extractor = sum
>   
> [[lightning_last_det_time]]
>  
> extractor = last  
> 
> 
>   
> ##
>   
> 
> 
> 
> # Options for extension 'GW1000'  
>  
>  [GW1000]  
>  
>  driver = user.gw1000  
>   
> ip_address = 192.168.0.104
> 
> 
>   
> 
>
> On Friday, July 31, 2020 at 4:21:43 PM UTC-5 gjr80 wrote:
>
>> Bill,
>>
>> Does this occur every time or occasionally? Could you post your [GW1000] 
>> stanza, the output from my previous post should contain everything else I 
>> need to troubleshoot this issue.
>>
>> Gary
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/465c1476-163a-4c83-8328-11edd280bedfn%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-31 Thread Bill Arthur

Hi Gary,
I wasn't able to make time to get the logs tonight. I'll try again tomorrow.
But I did test running the driver directly. I have three GW-1000s, 
192.168.0.104, 204 and 205.
Out of ten runs it chooses 204 four times, 205 four times and 104 two times.

# Options for extension 'GW1000'

[Accumulator]  
 
[[lightning_strike_count]]  

extractor = sum
  
[[lightning_last_det_time]]
 
extractor = last



##  



# Options for extension 'GW1000'
   
 [GW1000]  
 
 driver = user.gw1000  
  
ip_address = 192.168.0.104  





On Friday, July 31, 2020 at 4:21:43 PM UTC-5 gjr80 wrote:

> Bill,
>
> Does this occur every time or occasionally? Could you post your [GW1000] 
> stanza, the output from my previous post should contain everything else I 
> need to troubleshoot this issue.
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/47a025f1-210c-4f21-ace1-c90b3f9cee42n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-31 Thread Larry

I installed this using wee_extension as described and all seems to be 
working correctly now - the barometer the didn't display properly in b7  is 
now displaying properly in graph  on Weewx. 
Thanks 
Larry 

On Friday, July 31, 2020 at 3:54:51 AM UTC-5, gjr80 wrote:
>
> I have released v0.1.0b9 on Github 
> . The main change is the 
> (I hope) final resolution of the pressures issue. In short, the GW1000 
> Absolute Pressure is now mapped to WeeWX field pressure with WeeWX to 
> calculate barometer and altimeter via StdWXCalculate. GW1000 Relative 
> Pressure will be passed through to WeeWX as field relbarometer for those 
> that may wish to access it. The default behaviour can be changed by 
> suitable field map entries in weewx.conf.
>
> b9 includes requires no changes to weewx.conf; however, upgrading to b9 
> by downloading the b9 extension package and installing with the 
> wee_extension utility is the preferred means of installing/upgrading to 
> b9.
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/d4bb4c1a-3f43-4217-95c0-2aa02df1976fo%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-31 Thread gjr80

Bill,

Does this occur every time or occasionally? Could you post your [GW1000] 
stanza, the output from my previous post should contain everything else I need 
to troubleshoot this issue.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/8b171940-5eb6-44dc-b883-eea2aece13a5o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-31 Thread gjr80

Bill,

I doubt a fresh install will change things, either gw1000.py is there and being 
run or it isn’t. Could you do a few things for me please to try and 
troubleshoot. Could you run the driver directly with —live-data —debug=3 and 
post the console and log output. How does temperature on screen relate to what 
is shown in the WS View app? Could you also post a —sensors —debug=3 output and 
log as well.

Gary

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-31 Thread Bill Arthur

One other thing I noticed
Even though I had set the ip_address in weewx.conf it chose to use a 
different one.
This will be hard to troubleshoot unless you have several GW-1000s to work 
with.

On Friday, July 31, 2020 at 2:53:30 PM UTC-5 Bill Arthur wrote:

> The first time I set this up (on a fresh install) I had low barometer and 
> two digit wind direction. Wednesday I did a fresh install (on a Pi Zero) 
> and the barometer and wind direction were OK but the outside temp was about 
> 30 degrees low.
> I'm going to try another fresh install tonight.
>
>
> On Friday, July 31, 2020 at 3:54:51 AM UTC-5 gjr80 wrote:
>
>> I have released v0.1.0b9 on Github 
>> . The main change is the 
>> (I hope) final resolution of the pressures issue. In short, the GW1000 
>> Absolute Pressure is now mapped to WeeWX field pressure with WeeWX to 
>> calculate barometer and altimeter via StdWXCalculate. GW1000 Relative 
>> Pressure will be passed through to WeeWX as field relbarometer for those 
>> that may wish to access it. The default behaviour can be changed by 
>> suitable field map entries in weewx.conf.
>>
>> b9 includes requires no changes to weewx.conf; however, upgrading to b9 
>> by downloading the b9 extension package and installing with the 
>> wee_extension utility is the preferred means of installing/upgrading to 
>> b9.
>>
>> Gary
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/3f32f9c6-cfe8-46d2-89c5-1904589190a7n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-31 Thread Bill Arthur

The first time I set this up (on a fresh install) I had low barometer and 
two digit wind direction. Wednesday I did a fresh install (on a Pi Zero) 
and the barometer and wind direction were OK but the outside temp was about 
30 degrees low.
I'm going to try another fresh install tonight.


On Friday, July 31, 2020 at 3:54:51 AM UTC-5 gjr80 wrote:

> I have released v0.1.0b9 on Github 
> . The main change is the 
> (I hope) final resolution of the pressures issue. In short, the GW1000 
> Absolute Pressure is now mapped to WeeWX field pressure with WeeWX to 
> calculate barometer and altimeter via StdWXCalculate. GW1000 Relative 
> Pressure will be passed through to WeeWX as field relbarometer for those 
> that may wish to access it. The default behaviour can be changed by 
> suitable field map entries in weewx.conf.
>
> b9 includes requires no changes to weewx.conf; however, upgrading to b9 
> by downloading the b9 extension package and installing with the 
> wee_extension utility is the preferred means of installing/upgrading to 
> b9.
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0bb6a6ad-85b4-4d0b-abd2-183c30a9c34an%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-31 Thread gjr80

I have released v0.1.0b9 on Github 
. The main change is the (I 
hope) final resolution of the pressures issue. In short, the GW1000 
Absolute Pressure is now mapped to WeeWX field pressure with WeeWX to 
calculate barometer and altimeter via StdWXCalculate. GW1000 Relative 
Pressure will be passed through to WeeWX as field relbarometer for those 
that may wish to access it. The default behaviour can be changed by 
suitable field map entries in weewx.conf.

b9 includes requires no changes to weewx.conf; however, upgrading to b9 by 
downloading the b9 extension package and installing with the wee_extension 
utility is the preferred means of installing/upgrading to b9.

Gary

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread Paul Anderson

Sounds like a good plan I like it! Restarted my test system here today with 
previous version of driver but only mapping pressure. Just checked and 
barometer, pressure and altimeter between that system and one of the VP2 
stations I run still tracking within .1 millibar on all three parameters. 
Obviously one day is not a very good test but looks good so far.

-- 
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/2dee0c53-3b9e-4430-b210-cb2d20f826d8o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread galfert

Perfect. I agree. 

Thank you


On Thursday, July 30, 2020 at 9:57:53 PM UTC-4 gjr80 wrote:

> To complete the trifecta b9 will (by default) map the GW1000 Absolute 
> Pressure to WeeWX field pressure and the StdWXCalculate service can then 
> be used to calculate WeeWX fields barometer and altimeter. GW1000 
> Relative Pressure will be mapped through (again by default) to WeeWX field 
> relbarometer. As such it will be available for use by folks in reports 
> via the $current.relbarometer tag but will essentially have no other 
> affect unless folks include relbarometer in their db schema. Should 
> anyone want to map GW1000 Relative Pressure to WeeWX field barometer or 
> altimeter (or for that matter any other field) they can do so by adding 
> an appropriate field map entry entry under [GW1000] in weewx.conf.
>
> I think this gives us a practical and realistic default supported by 
> precedent whilst giving users the ability to tailor the behaviour to suit 
> their tastes.
>
> Gary
>
> On Friday, 31 July 2020 02:01:28 UTC+10, galfert wrote:
>>
>> I believe that this is exactly how Meteobridge also works. It just uses 
>> Absolute. I think this is probably the best solution.
>>
>> On Thursday, July 30, 2020 at 8:22:46 AM UTC-4 gjr80 wrote:
>>
>>> Looking at the WeeWX fousb driver it actually discards Relative Pressure 
>>> and uses Absolute Pressure as WeeWX field pressure. WeeWX fields barometer 
>>> and altimeter are calculated (by WeeWX). The interceptor driver when 
>>> processing Ecowitt format messages does the same, Relative Pressure is 
>>> ignored.
>>>

>

-- 
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/4a99712c-c111-459c-a386-35d8e1e5ee14n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

To complete the trifecta b9 will (by default) map the GW1000 Absolute 
Pressure to WeeWX field pressure and the StdWXCalculate service can then be 
used to calculate WeeWX fields barometer and altimeter. GW1000 Relative 
Pressure will be mapped through (again by default) to WeeWX field 
relbarometer. As such it will be available for use by folks in reports via 
the $current.relbarometer tag but will essentially have no other affect 
unless folks include relbarometer in their db schema. Should anyone want to 
map GW1000 Relative Pressure to WeeWX field barometer or altimeter (or for 
that matter any other field) they can do so by adding an appropriate field 
map entry entry under [GW1000] in weewx.conf.

I think this gives us a practical and realistic default supported by 
precedent whilst giving users the ability to tailor the behaviour to suit 
their tastes.

Gary

On Friday, 31 July 2020 02:01:28 UTC+10, galfert wrote:
>
> I believe that this is exactly how Meteobridge also works. It just uses 
> Absolute. I think this is probably the best solution.
>
> On Thursday, July 30, 2020 at 8:22:46 AM UTC-4 gjr80 wrote:
>
>> Looking at the WeeWX fousb driver it actually discards Relative Pressure 
>> and uses Absolute Pressure as WeeWX field pressure. WeeWX fields barometer 
>> and altimeter are calculated (by WeeWX). The interceptor driver when 
>> processing Ecowitt format messages does the same, Relative Pressure is 
>> ignored.
>>
>>>

-- 
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/254cab65-52cf-46b9-8f60-37795176a928o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread Paul R Anderson

Only had my GW1000 and a few sensors since Last Saturday, just had some
minor Thunderstorm activity, so first time seeing WH57 Lighting Detector
work.

Lightning Last Distance 0.6 miles
Lightning Last Time 07/30/2020 06:53:04 PM
Lightning Strikes Today 73

Seemed to detect strikes within maybe at least 12 miles. Knew that it was a
low end device, so I am very happy with the way it performed. And yes I Am
like a little kid... doesn't take a lot to amuse me 😁

-- 
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/CAOAVAee-mrvbVMrwmzQTfucADk8so0d_bjwOoVd%2Bm%3Dvmxt-z7g%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread galfert

I believe that this is exactly how Meteobridge also works. It just uses 
Absolute. I think this is probably the best solution.

On Thursday, July 30, 2020 at 8:22:46 AM UTC-4 gjr80 wrote:

> Looking at the WeeWX fousb driver it actually discards Relative Pressure 
> and uses Absolute Pressure as WeeWX field pressure. WeeWX fields barometer 
> and altimeter are calculated (by WeeWX). The interceptor driver when 
> processing Ecowitt format messages does the same, Relative Pressure is 
> ignored.
>
>>
>>>

-- 
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/cbae0af6-9e46-4df6-b74f-1c70f9f38e78n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread galfert

I can see it both ways as to how to deal with data from hardware versus 
having WeeWX calculate it. Some users that use WeeWX would surely go nuts 
if what they see on their display consoles does not match what they see in 
WeeWX. It would certainly make calibration very difficult. Certainly I 
think this is not something that should be a decision for the driver to do. 
I feel that some controls in WeeWX are the appropriate method to deal with 
this as other weather software also employ this method to deal with these 
issues. The software should allow the user to decide if to use data as 
provided by the hardware of if to have WeeWX calculate it.  I think 
therefore the only point to debate is what should be the default action. 
But then again I think that is not up the driver to decide but rather for 
core WeeWX to decided that based on what data is available from hardware 
what should be the default.

On Thursday, July 30, 2020 at 10:22:42 AM UTC-4 pa...@pauland.net wrote:

>
> Well aware that the manner in which the Rel Offset is determined does not 
> apply the proper standard temperature profile. That's why I said it may 
> have been more appropriate to map it to altimeter. Reasoning was at least 
> it was a static numeric offset, coming closer to altimeter , and certainly 
> not even close to being proper for barometer.
> Totally happy with only using the gw1000 value from Absolute Pressure as 
> weewx key pressure. Actually had considered this option, but didn't want to 
> raise hysteria at the thought of letting WeeWx calculate a value in 
> software that was available in hardware.
> As Tom Keffer has pointed out in the past there are many times that given 
> the fact that some hardware has undocumeted, incorrect, or sketchy, ways of 
> generating some variables, that WeeWx can do a much better job in software 
> than the hardware can. But I think as users most of us are hesitant to 
> acknowledge this and want to defer to the hardware.
>
>
>>
>>

-- 
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/4ee1ffce-1a30-43f0-a4f9-5c5e894aef95n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread Paul R Anderson

Well aware that the manner in which the Rel Offset is determined does not
apply the proper standard temperature profile. That's why I said it may
have been more appropriate to map it to altimeter. Reasoning was at least
it was a static numeric offset, coming closer to altimeter , and certainly
not even close to being proper for barometer.
Totally happy with only using the gw1000 value from Absolute Pressure as
weewx key pressure. Actually had considered this option, but didn't want to
raise hysteria at the thought of letting WeeWx calculate a value in
software that was available in hardware.
As Tom Keffer has pointed out in the past there are many times that given
the fact that some hardware has undocumeted, incorrect, or sketchy, ways of
generating some variables, that WeeWx can do a much better job in software
than the hardware can. But I think as users most of us are hesitant to
acknowledge this and want to defer to the hardware.


>
>

-- 
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/CAOAVAecsF3Cy-MeS36WW8tpx%3DLjSsVu9%2BUCQg8%3D8i7pvVFsy4A%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

They won't cause any harm other than taking up room, you will need to 
manually delete the old ones.

Gary

On Thursday, 30 July 2020 23:40:22 UTC+10, gary@gmail.com wrote:
>
> I have reinstall b8 and now have both the old and new rain related entries 
> in weewx.conf
>
>
> [[stormRain]][[hourRain]][[dayRain]][[weekRain]][[monthRain]][[yearRain]][[totalRain]]
> 
>
> [[rainevent]][[rainhour]][[rainday]][[rainweek]][[rainmonth]][[rainyear]][[raintotals]]
>
> On Thursday, July 30, 2020 at 7:07:10 AM UTC-4 gjr80 wrote:
>
>> Good, just check that you have [Accumulator] entries for hourRain, 
>> dayRain etc and not rainhour, rainday etc. If you don’t download the b8 
>> extension package again and re-install. I had an upload issue with the 
>> package earlier today. 
>>
>> Gary
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/24223721-4ab4-4927-98fe-47398d5bb221o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

Same data just different field name. There would be no lasting damage 
unless you had hourRain, dayRain, weekRain monthRain, yearRain, stormRain 
or totalRain in you database schema. You would have noticed some temporary 
errors on pages if you were using tags such as $current.hourRain, 
$current.dayRain etc. I suspect few if any will have noticed let alone been 
adversely affected.

Gary

On Thursday, 30 July 2020 23:26:00 UTC+10, Gary Hammer wrote:
>
> I have the incorrect entries and will reinstall. Luckily, my rainfall 
> occurred before installing this morning. 
>
>
> On 7/30/2020 7:07 AM, gjr80 wrote: 
> > Good, just check that you have [Accumulator] entries for hourRain, 
> dayRain etc and not rainhour, rainday etc. If you don’t download the b8 
> extension package again and re-install. I had an upload issue with the 
> package earlier today. 
> > 
> > Gary 
> > 
>
>

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread gary....@gmail.com

I have reinstall b8 and now have both the old and new rain related entries 
in weewx.conf

[[stormRain]][[hourRain]][[dayRain]][[weekRain]][[monthRain]][[yearRain]][[totalRain]]

[[rainevent]][[rainhour]][[rainday]][[rainweek]][[rainmonth]][[rainyear]][[raintotals]]

On Thursday, July 30, 2020 at 7:07:10 AM UTC-4 gjr80 wrote:

> Good, just check that you have [Accumulator] entries for hourRain, dayRain 
> etc and not rainhour, rainday etc. If you don’t download the b8 extension 
> package again and re-install. I had an upload issue with the package 
> earlier today.
>
> Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/30a5d402-8e45-4bc5-98c4-91e57a9f7d7an%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread Gary Hammer

I have the incorrect entries and will reinstall. Luckily, my rainfall 
occurred before installing this morning.



On 7/30/2020 7:07 AM, gjr80 wrote:

Good, just check that you have [Accumulator] entries for hourRain, dayRain etc 
and not rainhour, rainday etc. If you don’t download the b8 extension package 
again and re-install. I had an upload issue with the package earlier today.

Gary



--
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/3b9ccd3d-9d98-9339-c69a-acf47719cebb%40gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing


>
> The Customized upload in WU format only includes baromin. It is only when 
> you use Ecowitt format that you see baromrelin and baromabsin. 
>
 
Don't know what happened this afternoon, must have been tongue tied 
switching between Ecowitt and WU.

Yes the Relative Pressure out these stations is not technically totally 
> accurate Sea Level Pressure but perhaps that is why they call it Relative 
> pressure and they don't try to pass it up as Sea Level Pressure.
>
But it is good enough to pass off as Sea Level Pressure for WU though. :)

Looking at the WeeWX fousb driver it actually discards Relative Pressure 
and uses Absolute Pressure as WeeWX field pressure. WeeWX fields barometer 
and altimeter are calculated (by WeeWX). The interceptor driver when 
processing Ecowitt format messages does the same, Relative Pressure is 
ignored.

So it seems we have take 3 coming up.

Gary

On Thursday, 30 July 2020 21:22:26 UTC+10, galfert wrote:
>
> Gary,
> WU expects you to upload Sea Level Pressure. The best that is an 
> equivalence to is Relative pressure if the station has been properly 
> calibrated. 
>
> The Customized upload in WU format only includes baromin. It is only when 
> you use Ecowitt format that you see baromrelin and baromabsin. 
>
>
> On Thu, Jul 30, 2020, 1:19 AM gjr80  wrote:
>
>> Thanks for the input Paul, I believe your are correct. As soon as you see 
>> Rel Offset being calculated as an altitude only offset it is pretty clear 
>> it is altimeter and that means the pressure you are offsetting from must be 
>> pressure. I am not sure why I put down barometer, perhaps it was the 
>> liberal of the word barometer throughout the Ecowitt calibration 
>> instructions.Will be fixed in b8.
>>
>> One nagging thought I have have had this afternoon is what pressure value 
>> is the GW1000 uploading to WU, WU expects what WeeWX calls barometer but on 
>> the face of it that is the one pressure value the GW1000 does not have. I 
>> did set my GW1000 to do a customised upload in WU protocol to one of my VMs 
>> and it included fields named baromabsin and baromrelin being the two GW1000 
>> pressure values in inches Hg. If I had the time I would intercept the 
>> GW1000 actual upload to WU but I somehow suspect it will be the same.
>>
>> Gary
>>
>> On Thursday, 30 July 2020 10:50:16 UTC+10, Paul Anderson wrote:
>>>
>>> Should we map  'altimeter': 'relbarometer' ?
>>>
>>> Gw1000 produces 2 pressure readings:
>>> As defined by Ecowitt Calibration of barometric pressure settings 
>>> 
>>> *Absolute Pressure*
>>> "Absolute barometric pressure, can be calibrated at manufacturing time 
>>> by comparing with a precise instrument that measures pressure at the same 
>>> location. In practice, sometimes small adjustments of a few hPa may be 
>>> needed"
>>> *Relative Pressure*
>>> "The relative pressure represents what the air pressure would indicate 
>>> if your station was at sea level and depends on the altitude of your 
>>> console and cannot be known in advance. This is why it needs an adjustment"
>>>
>>> If you work your way thru there cal procedure you will see that you use 
>>> the  WS View app to set 2 offsets:
>>> Abs Offset
>>> Rel Offset
>>> To set Rel Offset they have you determine station elevation and direct 
>>> you to a site that produces a offset based solely on elevation. So *Rel 
>>> Offset* is a *STATIC *offset applied against your Absolute Pressure. It 
>>> never changes if we set a Rel Offset of 6.0 hPa then Relative Pressure will 
>>> always read 6.0 hPa higher than Absolute Pressure.
>>> As we see in WeeWX Wiki
>>>
>>> Station or Gauge Pressure (key *pressure*): This is the absolute, raw 
>>> pressure as measured by your instrument. It is not corrected for altitude 
>>> or pressure. Pilots call this QFE
>>> Sea-level Pressure (*barometer*): This is the pressure corrected for 
>>> altitude, temperature, and (frequently) humidity. Pilots call this QFF. 
>>> This is the value displayed by the standard skin.
>>> Altimeter Pressure (*altimeter*) : This is the pressure corrected for 
>>> altitude, using a standard temperature profile. Pilots call this QNH.
>>>
>>> Because we are on a very limited device which does not attempt in any 
>>> way to apply a temperature compensation I believe that mapping  
>>>  'altimeter': 'relbarometer' may be more appropriate. StdWXCalculate will 
>>> calculate barometer for us when it appears in a template. 
>>> Thanks
>>> Paul
>>>
>>>

 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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.com
 .

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google G

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread George Alfert

Gary,
WU expects you to upload Sea Level Pressure. The best that is an
equivalence to is Relative pressure if the station has been properly
calibrated.

The Customized upload in WU format only includes baromin. It is only when
you use Ecowitt format that you see baromrelin and baromabsin.


On Thu, Jul 30, 2020, 1:19 AM gjr80  wrote:

> Thanks for the input Paul, I believe your are correct. As soon as you see
> Rel Offset being calculated as an altitude only offset it is pretty clear
> it is altimeter and that means the pressure you are offsetting from must be
> pressure. I am not sure why I put down barometer, perhaps it was the
> liberal of the word barometer throughout the Ecowitt calibration
> instructions.Will be fixed in b8.
>
> One nagging thought I have have had this afternoon is what pressure value
> is the GW1000 uploading to WU, WU expects what WeeWX calls barometer but on
> the face of it that is the one pressure value the GW1000 does not have. I
> did set my GW1000 to do a customised upload in WU protocol to one of my VMs
> and it included fields named baromabsin and baromrelin being the two GW1000
> pressure values in inches Hg. If I had the time I would intercept the
> GW1000 actual upload to WU but I somehow suspect it will be the same.
>
> Gary
>
> On Thursday, 30 July 2020 10:50:16 UTC+10, Paul Anderson wrote:
>>
>> Should we map  'altimeter': 'relbarometer' ?
>>
>> Gw1000 produces 2 pressure readings:
>> As defined by Ecowitt Calibration of barometric pressure settings
>> 
>> *Absolute Pressure*
>> "Absolute barometric pressure, can be calibrated at manufacturing time by
>> comparing with a precise instrument that measures pressure at the same
>> location. In practice, sometimes small adjustments of a few hPa may be
>> needed"
>> *Relative Pressure*
>> "The relative pressure represents what the air pressure would indicate if
>> your station was at sea level and depends on the altitude of your console
>> and cannot be known in advance. This is why it needs an adjustment"
>>
>> If you work your way thru there cal procedure you will see that you use
>> the  WS View app to set 2 offsets:
>> Abs Offset
>> Rel Offset
>> To set Rel Offset they have you determine station elevation and direct
>> you to a site that produces a offset based solely on elevation. So *Rel
>> Offset* is a *STATIC *offset applied against your Absolute Pressure. It
>> never changes if we set a Rel Offset of 6.0 hPa then Relative Pressure will
>> always read 6.0 hPa higher than Absolute Pressure.
>> As we see in WeeWX Wiki
>>
>> Station or Gauge Pressure (key *pressure*): This is the absolute, raw
>> pressure as measured by your instrument. It is not corrected for altitude
>> or pressure. Pilots call this QFE
>> Sea-level Pressure (*barometer*): This is the pressure corrected for
>> altitude, temperature, and (frequently) humidity. Pilots call this QFF.
>> This is the value displayed by the standard skin.
>> Altimeter Pressure (*altimeter*) : This is the pressure corrected for
>> altitude, using a standard temperature profile. Pilots call this QNH.
>>
>> Because we are on a very limited device which does not attempt in any way
>> to apply a temperature compensation I believe that mapping   'altimeter':
>> 'relbarometer' may be more appropriate. StdWXCalculate will calculate
>> barometer for us when it appears in a template.
>> Thanks
>> Paul
>>
>>
>>>
>>> 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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.com
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/3KF7XMLQGsA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/a9efe943-d23e-4458-b475-3daed4d3cac5o%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/CAG91bKyEJzwBLmFKhSd4Rx4STVzQsUTuLmmgcCAk3OHk31j5%3Dg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread Greg Troxel

George Alfert  writes:

> I disagree. Simply adding a constant offset to Absolute does not give you
> Altimeter. I understand your point in that Altimeter is a similar thing
> that uses a temperature constant, but Altimeter should be something that is
> properly calculated from Absolute using a proper formula. I'm sure that
> WeeWX already has a built in conversion to get from Absolute to Altimeter.

I was going to point this out too, that just adding a fixed offset in
hPa is not the same as applying the altitude formula.

So, from a hard-core viewpoint, perhaps the best approach is:

  map absolute pressure to station pressure

  ignore "relative pressure" as unsound

  let StdCalculate computer altimiter pressure and barometer pressure

with an implicit

  let the user calibrate the GW1000's absolute pressure, or enter in a
  calibtration in StdCalibrate (or just not worry about it)
  

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread George Alfert

Paul,
I disagree. Simply adding a constant offset to Absolute does not give you
Altimeter. I understand your point in that Altimeter is a similar thing
that uses a temperature constant, but Altimeter should be something that is
properly calculated from Absolute using a proper formula. I'm sure that
WeeWX already has a built in conversion to get from Absolute to Altimeter.

The only online weather service that requires Altimeter sent to them that I
know of is CWOP.

Yes there are some people that prefer to only use Altimeter and for those
people there are other means to accomplish this and that would be to zero
out their elevation on their consoles.

Yes the Relative Pressure out these stations is not technically totally
accurate Sea Level Pressure but perhaps that is why they call it Relative
pressure and they don't try to pass it up as Sea Level Pressure. The
Relative Pressure Offset is an average offset. If you were to calibrate to
the exact offset for a given pressure amount you would notice that when the
pressure changes that your Relative would no long match as well the Sea
Level Of that you calibrated against. That is why when you figure out your
Relative Offset you should be using 1013.25 hPa as your Sea Level Pressure.
You can read a great deal about how to best calibrate these a Fine Offset
stations on wxforum.net.


On Wed, Jul 29, 2020, 8:50 PM Paul R Anderson  wrote:

> Should we map  'altimeter': 'relbarometer' ?
>
> Gw1000 produces 2 pressure readings:
> As defined by Ecowitt Calibration of barometric pressure settings
> 
> *Absolute Pressure*
> "Absolute barometric pressure, can be calibrated at manufacturing time by
> comparing with a precise instrument that measures pressure at the same
> location. In practice, sometimes small adjustments of a few hPa may be
> needed"
> *Relative Pressure*
> "The relative pressure represents what the air pressure would indicate if
> your station was at sea level and depends on the altitude of your console
> and cannot be known in advance. This is why it needs an adjustment"
>
> If you work your way thru there cal procedure you will see that you use
> the  WS View app to set 2 offsets:
> Abs Offset
> Rel Offset
> To set Rel Offset they have you determine station elevation and direct you
> to a site that produces a offset based solely on elevation. So *Rel
> Offset* is a *STATIC *offset applied against your Absolute Pressure. It
> never changes if we set a Rel Offset of 6.0 hPa then Relative Pressure will
> always read 6.0 hPa higher than Absolute Pressure.
> As we see in WeeWX Wiki
>
> Station or Gauge Pressure (key *pressure*): This is the absolute, raw
> pressure as measured by your instrument. It is not corrected for altitude
> or pressure. Pilots call this QFE
> Sea-level Pressure (*barometer*): This is the pressure corrected for
> altitude, temperature, and (frequently) humidity. Pilots call this QFF.
> This is the value displayed by the standard skin.
> Altimeter Pressure (*altimeter*) : This is the pressure corrected for
> altitude, using a standard temperature profile. Pilots call this QNH.
>
> Because we are on a very limited device which does not attempt in any way
> to apply a temperature compensation I believe that mapping   'altimeter':
> 'relbarometer' may be more appropriate. StdWXCalculate will calculate
> barometer for us when it appears in a template.
> Thanks
> Paul
>
>
>>
>> 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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.com
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/3KF7XMLQGsA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAOAVAefsj387Cx%2B8ffLt%2BjLS3vhnrwGp2%2Bpy3zUeuc2h7etKDg%40mail.gmail.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/CAG91bKzfswzZ-FDZQfAG%3DJbMoDx2YW%3DzpRi7FVHDycFuP2neOg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

Good, just check that you have [Accumulator] entries for hourRain, dayRain etc 
and not rainhour, rainday etc. If you don’t download the b8 extension package 
again and re-install. I had an upload issue with the package earlier today.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9002bb08-effd-484b-af08-efcfbfbfd694o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-30 Thread gary....@gmail.com

I have installed b8 successfully and note that nothing was changed in my 
weewx.conf except the addition of the extractors.



On Thursday, July 30, 2020 at 2:08:46 AM UTC-4 gjr80 wrote:

> I have released v0.1.0b8 on Github 
>  which:
>
> - fixes an incorrect mapping of GW1000 field relbarometer that will have 
> resulted in incorrect barometer and altimeter fields in WeeWX
> - changes default field mappings of GW1000 fields rainhour, rainday, 
> rainweek, rainmonth, rainyear, raintotals and rainevent to hourRain, 
> dayRain, weekRain, monthRain, yearRain, totalRain and stormRain respectively
> - changes default field mapping of GW1000 field uv from uvRadiaition to 
> uvradiation
> - fixes a bug that resulted in battery state mappings not being included 
> in the default field map displayed with the --default-map command line 
> option
> - adds extractors for all fields from default field map (incl battery 
> state map) that need an extractor function other than avg
>
> As b8 includes extractor functions for a number of fields b8 requires 
> changes to weewx.conf. For this reason the best way to upgrade to or 
> install b8 is by downloading the extension package and installing using 
> wee_extension. I will update the manual install instructions on the GW1000 
> driver wiki shortly. Upgrading by installing the extension package should 
> retain any customised settings you may have made to weewx.conf, in any case 
> a timestamped backup copy of weewx.conf is made by wee_extension and it 
> might pay to check that any customisations in the [GW1000] stanza have been 
> retained.
>
> For those that may have incorrect barometer/altimeter data as a result of 
> the incorrect relbarometer mapping, users of WeeWX 4.0.0 or later should be 
> able to recalculate the incorrect data by first deleting the incorrect 
> barometer and altimeter data from the archive and then running wee_database 
> using the --calc-missing action. You will then need to rebuild your daily 
> summaries using --rebuild-daily. i will publish some detailed instructions 
> later tonite.
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/996540e6-1c7c-45e8-a29b-9b43f2718d71n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-29 Thread gjr80

I have released v0.1.0b8 on Github 
 which:

- fixes an incorrect mapping of GW1000 field relbarometer that will have 
resulted in incorrect barometer and altimeter fields in WeeWX
- changes default field mappings of GW1000 fields rainhour, rainday, 
rainweek, rainmonth, rainyear, raintotals and rainevent to hourRain, 
dayRain, weekRain, monthRain, yearRain, totalRain and stormRain respectively
- changes default field mapping of GW1000 field uv from uvRadiaition to 
uvradiation
- fixes a bug that resulted in battery state mappings not being included in 
the default field map displayed with the --default-map command line option
- adds extractors for all fields from default field map (incl battery state 
map) that need an extractor function other than avg

As b8 includes extractor functions for a number of fields b8 requires 
changes to weewx.conf. For this reason the best way to upgrade to or 
install b8 is by downloading the extension package and installing using 
wee_extension. I will update the manual install instructions on the GW1000 
driver wiki shortly. Upgrading by installing the extension package should 
retain any customised settings you may have made to weewx.conf, in any case 
a timestamped backup copy of weewx.conf is made by wee_extension and it 
might pay to check that any customisations in the [GW1000] stanza have been 
retained.

For those that may have incorrect barometer/altimeter data as a result of 
the incorrect relbarometer mapping, users of WeeWX 4.0.0 or later should be 
able to recalculate the incorrect data by first deleting the incorrect 
barometer and altimeter data from the archive and then running wee_database 
using the --calc-missing action. You will then need to rebuild your daily 
summaries using --rebuild-daily. i will publish some detailed instructions 
later tonite.

Gary

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-29 Thread gjr80

Thanks for the input Paul, I believe your are correct. As soon as you see 
Rel Offset being calculated as an altitude only offset it is pretty clear 
it is altimeter and that means the pressure you are offsetting from must be 
pressure. I am not sure why I put down barometer, perhaps it was the 
liberal of the word barometer throughout the Ecowitt calibration 
instructions.Will be fixed in b8.

One nagging thought I have have had this afternoon is what pressure value 
is the GW1000 uploading to WU, WU expects what WeeWX calls barometer but on 
the face of it that is the one pressure value the GW1000 does not have. I 
did set my GW1000 to do a customised upload in WU protocol to one of my VMs 
and it included fields named baromabsin and baromrelin being the two GW1000 
pressure values in inches Hg. If I had the time I would intercept the 
GW1000 actual upload to WU but I somehow suspect it will be the same.

Gary

On Thursday, 30 July 2020 10:50:16 UTC+10, Paul Anderson wrote:
>
> Should we map  'altimeter': 'relbarometer' ?
>
> Gw1000 produces 2 pressure readings:
> As defined by Ecowitt Calibration of barometric pressure settings 
> 
> *Absolute Pressure*
> "Absolute barometric pressure, can be calibrated at manufacturing time by 
> comparing with a precise instrument that measures pressure at the same 
> location. In practice, sometimes small adjustments of a few hPa may be 
> needed"
> *Relative Pressure*
> "The relative pressure represents what the air pressure would indicate if 
> your station was at sea level and depends on the altitude of your console 
> and cannot be known in advance. This is why it needs an adjustment"
>
> If you work your way thru there cal procedure you will see that you use 
> the  WS View app to set 2 offsets:
> Abs Offset
> Rel Offset
> To set Rel Offset they have you determine station elevation and direct you 
> to a site that produces a offset based solely on elevation. So *Rel 
> Offset* is a *STATIC *offset applied against your Absolute Pressure. It 
> never changes if we set a Rel Offset of 6.0 hPa then Relative Pressure will 
> always read 6.0 hPa higher than Absolute Pressure.
> As we see in WeeWX Wiki
>
> Station or Gauge Pressure (key *pressure*): This is the absolute, raw 
> pressure as measured by your instrument. It is not corrected for altitude 
> or pressure. Pilots call this QFE
> Sea-level Pressure (*barometer*): This is the pressure corrected for 
> altitude, temperature, and (frequently) humidity. Pilots call this QFF. 
> This is the value displayed by the standard skin.
> Altimeter Pressure (*altimeter*) : This is the pressure corrected for 
> altitude, using a standard temperature profile. Pilots call this QNH.
>
> Because we are on a very limited device which does not attempt in any way 
> to apply a temperature compensation I believe that mapping   'altimeter': 
> 'relbarometer' may be more appropriate. StdWXCalculate will calculate 
> barometer for us when it appears in a template. 
> Thanks
> Paul
>
>
>>
>> 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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.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/a9efe943-d23e-4458-b475-3daed4d3cac5o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-29 Thread Paul R Anderson

Should we map  'altimeter': 'relbarometer' ?

Gw1000 produces 2 pressure readings:
As defined by Ecowitt Calibration of barometric pressure settings

*Absolute Pressure*
"Absolute barometric pressure, can be calibrated at manufacturing time by
comparing with a precise instrument that measures pressure at the same
location. In practice, sometimes small adjustments of a few hPa may be
needed"
*Relative Pressure*
"The relative pressure represents what the air pressure would indicate if
your station was at sea level and depends on the altitude of your console
and cannot be known in advance. This is why it needs an adjustment"

If you work your way thru there cal procedure you will see that you use
the  WS View app to set 2 offsets:
Abs Offset
Rel Offset
To set Rel Offset they have you determine station elevation and direct you
to a site that produces a offset based solely on elevation. So *Rel Offset* is
a *STATIC *offset applied against your Absolute Pressure. It never changes
if we set a Rel Offset of 6.0 hPa then Relative Pressure will always
read 6.0 hPa higher than Absolute Pressure.
As we see in WeeWX Wiki

Station or Gauge Pressure (key *pressure*): This is the absolute, raw
pressure as measured by your instrument. It is not corrected for altitude
or pressure. Pilots call this QFE
Sea-level Pressure (*barometer*): This is the pressure corrected for
altitude, temperature, and (frequently) humidity. Pilots call this QFF.
This is the value displayed by the standard skin.
Altimeter Pressure (*altimeter*) : This is the pressure corrected for
altitude, using a standard temperature profile. Pilots call this QNH.

Because we are on a very limited device which does not attempt in any way
to apply a temperature compensation I believe that mapping   'altimeter':
'relbarometer' may be more appropriate. StdWXCalculate will calculate
barometer for us when it appears in a template.
Thanks
Paul


>
> 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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.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/CAOAVAefsj387Cx%2B8ffLt%2BjLS3vhnrwGp2%2Bpy3zUeuc2h7etKDg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-29 Thread Graham Eddy

> Not sure why you think ‘uvi’ is mapped to ‘uv’, it is and always has been 
> mapped to ‘UV’.

i misread the code and thought the case was wrong (it isn’t). i blame my 
spectacles. cheers

-- 
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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-29 Thread gjr80

I must admit that I only looked at the wview-extended schema when developing
the default field map and did not consider weewx.units.obs_group_dict, though
it makes sense to use weewx.units.obs_group_dict where possible. Will change
the default mapping for the three rain fields as suggested.

Not sure why you think ‘uvi’ is mapped to ‘uv’, it is and always has been
mapped to ‘UV’.

The GW1000 API supports two UV related observations, these are labelled UV and
UVI with supporting comments that UV is in micro watts/sq metre and UVI is an
index from 0 to 15. UVI is mapped to WeeWX field UV. The GW1000 UV value is not
what WeeWX knows as radiation. The discussion at
https://github.com/gjr80/weewx-gw1000/issues/6 revealed the GW1000 derives what
WeeWX knows as radiation from a luminosity observation. Also, the units don’t
gel, the GW1000 UV field uses 2 bytes and thus a maximum of 65536 micro
watts/sq metre, solar isolation on the other hand is of the order of hundreds
of watts/sq metre. I am happy to be corrected but for now will be leaving
uvRadiation mapping as is (actually will change uvRadiation to uvradiation).

Changes will appear in b8.

Gary

--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/e7a4355e-6eab-4b64-aea5-3445be39906do%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-29 Thread Graham Eddy

i expect my new GW1000 (to augment my vp2) to arrive monday so have started 
planning…

looking at gw1000 driver default_field_map, there seem to be a few mislabelled 
mappings into wview_extended.schema and weewx.units.obs_group_dict, they should 
be:
gw1000 → weewx
rainday → dayRain   (not passed thru unchanged)
rainhour → hourRain (not passed thru unchanged)
rainmonth → monthRain   (not passed thru unchanged)
uvi → UV(misspelt as uv)
uv → radiation  (misspelt as uvRadiation)

-- 
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/56AE06A5-AB87-4755-9AFA-86DD72C95C74%40gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

I have added a page to the GW1000 driver wiki 
 with details of the battery 
state information provided by the driver. The details on the page a a 
combination of details specified in the API, information posted on 
wxforum.net and anecdotal evidence obtained during development of the 
driver. Please let me know if you observe/notice any discrepancies.

On Wednesday, 29 July 2020 08:13:10 UTC+10, gjr80 wrote:
>
> I will put a battery state table in the driver wiki today.
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/83400714-45ef-46fb-86e8-b5b3a7ee277co%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

I will put a battery state table in the driver wiki today.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0a3a9b5c-8b0b-4875-b469-a33258efe0deo%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-28 Thread 'NanoG5Kite' via weewx-user


Battery status on different devices:

https://www.wxforum.net/index.php?topic=37373.msg408190#msg408190

Matthias

Am Dienstag, 28. Juli 2020 18:34:34 UTC+2 schrieb NanoG5Kite:
>
> Regarding Evowitt Battery Status. There are new Sensors like the WH 57 
> which report the battery status from 0-5 (5=fully charged), but former 
> sensors like the 7in1 with 0 or 1 (1=empty, to be replaced asap). There was 
> a useful threat in the wxforum.net telleing which sensors show which kind 
> of level, but can‘t find it back currently...
>
> Am Dienstag, 28. Juli 2020 18:04:55 UTC+2 schrieb Paul Anderson:
>>
>> Gary
>> First just a note that I was running v0.1.0b6 as a service and my GW1000 
>> lost it's WIFI connection. Actual dropped WIFI connecting by the GW1000.
>> Looking at the log I see that  the driver worked perfectly, it logged a 
>> connection failure after 3 attempts, but weewx itself kept running so that 
>> only the supplemental data from the GW1000 was lost. Once I relocated the 
>> GW1000 to a better location , without restarting WeeWX, the GW1000 data 
>> started flowing again. Perfect just the behavior I would want.
>>
>> Just updated to v0.1.0b7 here is what is returned for battery status:
>> wh31_ch2_batt: 0, wh31_ch4_batt: 0, wh31_ch5_batt: 0, wh31_ch7_batt: 0, 
>> wh57_batt: 5
>> So all sensors recognized, not sure of the meaning of "0" and "5" and why 
>> wh57 returns "5" All sensors installed with new batteries 3 days ago .
>>
>> On Tue, Jul 28, 2020 at 9:52 AM gjr80  wrote:
>>
>>> I have released v0.1.0b7 on Github 
>>> . b7 adds the battery 
>>> states to the default field map which should see battery states appear in 
>>> the loop packets. I expect there will still be some naming issues, 
>>> especially with WH65 and WH32. b7 also fixes a n issue where wind direction 
>>> was wrongly decoded..
>>>
>>> Those that have already installed the driver can download and install 
>>> v0.1.0b7 using the following commands depending on your WeeWX install type:
>>>
>>> for setup.py installs:
>>>
>>> $ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/
>>> gw1000_orig.py
>>> $ sudo wget -P /home/weewx/bin/user https://
>>> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py 
>>> 
>>>
>>> for package installs:
>>>
>>> $ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/
>>> gw1000_orig.py
>>> $ sudo wget -P /usr/share/weewx/user https://
>>> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py 
>>> 
>>>
>>> There has been no change to the [GW1000] structure so you can just 
>>> restart WeeWX/run v0.1.0b7 directly without further changes.
>>>
>>> Gary
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/4636d1ee-f397-4679-907c-45981a165199o%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/3a110944-2de1-4c17-8fec-df056ddfd6ffo%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-28 Thread 'NanoG5Kite' via weewx-user

Regarding Evowitt Battery Status. There are new Sensors like the WH 57 
which report the battery status from 0-5 (5=fully charged), but former 
sensors like the 7in1 with 0 or 1 (1=empty, to be replaced asap). There was 
a useful threat in the wxforum.net telleing which sensors show which kind 
of level, but can‘t find it back currently...

Am Dienstag, 28. Juli 2020 18:04:55 UTC+2 schrieb Paul Anderson:
>
> Gary
> First just a note that I was running v0.1.0b6 as a service and my GW1000 
> lost it's WIFI connection. Actual dropped WIFI connecting by the GW1000.
> Looking at the log I see that  the driver worked perfectly, it logged a 
> connection failure after 3 attempts, but weewx itself kept running so that 
> only the supplemental data from the GW1000 was lost. Once I relocated the 
> GW1000 to a better location , without restarting WeeWX, the GW1000 data 
> started flowing again. Perfect just the behavior I would want.
>
> Just updated to v0.1.0b7 here is what is returned for battery status:
> wh31_ch2_batt: 0, wh31_ch4_batt: 0, wh31_ch5_batt: 0, wh31_ch7_batt: 0, 
> wh57_batt: 5
> So all sensors recognized, not sure of the meaning of "0" and "5" and why 
> wh57 returns "5" All sensors installed with new batteries 3 days ago .
>
> On Tue, Jul 28, 2020 at 9:52 AM gjr80 > 
> wrote:
>
>> I have released v0.1.0b7 on Github 
>> . b7 adds the battery 
>> states to the default field map which should see battery states appear in 
>> the loop packets. I expect there will still be some naming issues, 
>> especially with WH65 and WH32. b7 also fixes a n issue where wind direction 
>> was wrongly decoded..
>>
>> Those that have already installed the driver can download and install 
>> v0.1.0b7 using the following commands depending on your WeeWX install type:
>>
>> for setup.py installs:
>>
>> $ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig
>> .py
>> $ sudo wget -P /home/weewx/bin/user https://
>> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py 
>> 
>>
>> for package installs:
>>
>> $ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/
>> gw1000_orig.py
>> $ sudo wget -P /usr/share/weewx/user https://
>> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py 
>> 
>>
>> There has been no change to the [GW1000] structure so you can just 
>> restart WeeWX/run v0.1.0b7 directly without further changes.
>>
>> Gary
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/4636d1ee-f397-4679-907c-45981a165199o%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/3d61d7d9-8ba1-4095-9d05-0d3101afba33o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-28 Thread Paul R Anderson

Gary
First just a note that I was running v0.1.0b6 as a service and my GW1000
lost it's WIFI connection. Actual dropped WIFI connecting by the GW1000.
Looking at the log I see that  the driver worked perfectly, it logged a
connection failure after 3 attempts, but weewx itself kept running so that
only the supplemental data from the GW1000 was lost. Once I relocated the
GW1000 to a better location , without restarting WeeWX, the GW1000 data
started flowing again. Perfect just the behavior I would want.

Just updated to v0.1.0b7 here is what is returned for battery status:
wh31_ch2_batt: 0, wh31_ch4_batt: 0, wh31_ch5_batt: 0, wh31_ch7_batt: 0,
wh57_batt: 5
So all sensors recognized, not sure of the meaning of "0" and "5" and why
wh57 returns "5" All sensors installed with new batteries 3 days ago .

On Tue, Jul 28, 2020 at 9:52 AM gjr80  wrote:

> I have released v0.1.0b7 on Github
> . b7 adds the battery
> states to the default field map which should see battery states appear in
> the loop packets. I expect there will still be some naming issues,
> especially with WH65 and WH32. b7 also fixes a n issue where wind direction
> was wrongly decoded..
>
> Those that have already installed the driver can download and install
> v0.1.0b7 using the following commands depending on your WeeWX install type:
>
> for setup.py installs:
>
> $ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig.
> py
> $ sudo wget -P /home/weewx/bin/user https://
> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py
> 
>
> for package installs:
>
> $ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/
> gw1000_orig.py
> $ sudo wget -P /usr/share/weewx/user https://
> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py
> 
>
> There has been no change to the [GW1000] structure so you can just
> restart WeeWX/run v0.1.0b7 directly without further changes.
>
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/4636d1ee-f397-4679-907c-45981a165199o%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/CAOAVAedB3RQLG80PLywoTPiz%3Dombk0AJcN8iUiX8CXUzyir6ag%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-28 Thread gary....@gmail.com

My wind results have been corrected.

On Tuesday, July 28, 2020 at 9:55:22 AM UTC-4 gjr80 wrote:

> Bill, the incorrect wind direction decode likely accounts for your wind 
> direction discrepancies. Not sure about the pressure issues, as far as I am 
> aware pressure is being correctly decoded. I will look into it further in 
> the morning.
>
> Gary
>
> On Monday, 27 July 2020 20:03:01 UTC+10, Bill Arthur wrote:
>>
>> Thanks Gary.  
>> Your instructions worked perfectly.
>>
>> I'm still seeing a couple of things. Here are links to two reporting 
>> stations. They both receive data from the same GW-1000
>> The -1 station uses the old push method. The -5 station uses the new API 
>> method.  I'm seeing differences in wind direction and barometer
>> -1 Station 
>> -5 Station 
>>
>

-- 
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/640a1857-01a3-498d-9819-ab152372ae2fn%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

Bill, the incorrect wind direction decode likely accounts for your wind 
direction discrepancies. Not sure about the pressure issues, as far as I am 
aware pressure is being correctly decoded. I will look into it further in 
the morning.

Gary

On Monday, 27 July 2020 20:03:01 UTC+10, Bill Arthur wrote:
>
> Thanks Gary.  
> Your instructions worked perfectly.
>
> I'm still seeing a couple of things. Here are links to two reporting 
> stations. They both receive data from the same GW-1000
> The -1 station uses the old push method. The -5 station uses the new API 
> method.  I'm seeing differences in wind direction and barometer
> -1 Station 
> -5 Station 
>

-- 
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/5d0095b0-4d36-499b-be81-53c83a48a0b1o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

I have released v0.1.0b7 on Github 
. b7 adds the battery 
states to the default field map which should see battery states appear in 
the loop packets. I expect there will still be some naming issues, 
especially with WH65 and WH32. b7 also fixes a n issue where wind direction 
was wrongly decoded..

Those that have already installed the driver can download and install 
v0.1.0b7 using the following commands depending on your WeeWX install type:

for setup.py installs:

$ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig.py
$ sudo wget -P /home/weewx/bin/user https://
raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py 


for package installs:

$ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/gw1000_orig.
py
$ sudo wget -P /usr/share/weewx/user https://
raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b7/bin/user/gw1000.py 


There has been no change to the [GW1000] structure so you can just restart 
WeeWX/run v0.1.0b7 directly without further changes.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4636d1ee-f397-4679-907c-45981a165199o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

Thanks Ian, that confirms the last one.

Gary

On Tuesday, 28 July 2020 16:41:53 UTC+10, steeple ian wrote:
>
> Gary,
>
> This is my output (my GW1000 is 868MHz): -
>
> Using configuration file /home/weewx/weewx.conf
>
> Interrogating GW1000 at 192.168.1.234:45000
>
> GW1000 frequency: 1 (Unknown)
> GW1000 sensor type: 1 (WH65)
> GW1000 decoded UTC: 2020-07-28 07:37:39 UTC (1595921859)
> GW1000 timezone: 39
>
>
>
> On Tue, 28 Jul 2020 at 02:41, gjr80  wrote:
>
>> Yes, not surprised, am still working through sensor names and the API to 
>> get the code right. Fortunately, this disconnect does not affect the 
>> observational data only battery state field names and some of the 
>> 'informational' commands such as --system-params. Once I get the battery 
>> states into the loop packets they can be easily fixed (temporarily) with a 
>> few field map extensions.
>>
>> Gary
>>
>> On Tuesday, 28 July 2020 11:04:45 UTC+10, gary@gmail.com wrote:
>>>
>>> Though this is not a WH65
>>>
>>> I have a GW1000, WS68, WH40, WH32-EP, WH32B
>>>
>>> On Monday, July 27, 2020 at 8:58:54 PM UTC-4 gary@gmail.com wrote:
>>>
 This is a 915 MHz unit

 Interrogating GW1000 at 10.10.100.125:45000

 GW1000 frequency: 2 (Unknown)
 GW1000 sensor type: 1 (WH65)
 GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
 GW1000 timezone: 19


 On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:

> v0.1.0b6 added the --system-params command line option to the driver 
> to display a number of GW1000 system parameters, eg:
>
> GW1000 frequency: 0 (433MHz)
> GW1000 sensor type: 0 (WH24)
> GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
> GW1000 timezone: 94
>
> Whilst I know which byte to look at for the frequency, and what value 
> represents 433MHz as used on my GW1000, I do not know what value is used 
> to 
> represent operation on 868MHZ and 915MHz. Was wondering if any users of 
> v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the 
> frequency their GW1000 uses as well as the output from the following 
> command (adjusting python version and path as required):
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params
>
> I don't believe any of the information is particularly sensitive, but 
> if you are concerned I really just need to know the frequncy your GW1000 
> operates on as well as the line starting 'GW1000 frequency'. If you don't 
> know what frequency your GW1000 operates on it should be printed on the 
> back of your GW1000 (well at least mine is like that!)
>
> thanks,
> Gary
>
 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/d6b32000-d7a8-483d-9822-6b47d24e1b23o%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/40dfa6ce-c878-42b4-aa9b-ea72730acf29o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread steeple ian

So with a modification to the parameters section I get: -

Using configuration file /home/weewx/weewx.conf

Interrogating GW1000 at 192.168.1.234:45000

GW1000 frequency: 1 (868Mhz)
GW1000 sensor type: 1 (WH65)
GW1000 decoded UTC: 2020-07-28 07:52:28 UTC (1595922748)
GW1000 timezone: 39


On Tue, 28 Jul 2020 at 07:41, steeple ian  wrote:

> Gary,
>
> This is my output (my GW1000 is 868MHz): -
>
> Using configuration file /home/weewx/weewx.conf
>
> Interrogating GW1000 at 192.168.1.234:45000
>
> GW1000 frequency: 1 (Unknown)
> GW1000 sensor type: 1 (WH65)
> GW1000 decoded UTC: 2020-07-28 07:37:39 UTC (1595921859)
> GW1000 timezone: 39
>
>
>
> On Tue, 28 Jul 2020 at 02:41, gjr80  wrote:
>
>> Yes, not surprised, am still working through sensor names and the API to
>> get the code right. Fortunately, this disconnect does not affect the
>> observational data only battery state field names and some of the
>> 'informational' commands such as --system-params. Once I get the battery
>> states into the loop packets they can be easily fixed (temporarily) with a
>> few field map extensions.
>>
>> Gary
>>
>> On Tuesday, 28 July 2020 11:04:45 UTC+10, gary@gmail.com wrote:
>>>
>>> Though this is not a WH65
>>>
>>> I have a GW1000, WS68, WH40, WH32-EP, WH32B
>>>
>>> On Monday, July 27, 2020 at 8:58:54 PM UTC-4 gary@gmail.com wrote:
>>>
 This is a 915 MHz unit

 Interrogating GW1000 at 10.10.100.125:45000

 GW1000 frequency: 2 (Unknown)
 GW1000 sensor type: 1 (WH65)
 GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
 GW1000 timezone: 19


 On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:

> v0.1.0b6 added the --system-params command line option to the driver
> to display a number of GW1000 system parameters, eg:
>
> GW1000 frequency: 0 (433MHz)
> GW1000 sensor type: 0 (WH24)
> GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
> GW1000 timezone: 94
>
> Whilst I know which byte to look at for the frequency, and what value
> represents 433MHz as used on my GW1000, I do not know what value is used 
> to
> represent operation on 868MHZ and 915MHz. Was wondering if any users of
> v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the
> frequency their GW1000 uses as well as the output from the following
> command (adjusting python version and path as required):
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params
>
> I don't believe any of the information is particularly sensitive, but
> if you are concerned I really just need to know the frequncy your GW1000
> operates on as well as the line starting 'GW1000 frequency'. If you don't
> know what frequency your GW1000 operates on it should be printed on the
> back of your GW1000 (well at least mine is like that!)
>
> thanks,
> Gary
>
 --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-user+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/d6b32000-d7a8-483d-9822-6b47d24e1b23o%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/CADASSaQBfUKcoBGaCz9aSQXdCXyHisWMujCMqRefMmh5qjYkKg%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread steeple ian

Gary,

This is my output (my GW1000 is 868MHz): -

Using configuration file /home/weewx/weewx.conf

Interrogating GW1000 at 192.168.1.234:45000

GW1000 frequency: 1 (Unknown)
GW1000 sensor type: 1 (WH65)
GW1000 decoded UTC: 2020-07-28 07:37:39 UTC (1595921859)
GW1000 timezone: 39



On Tue, 28 Jul 2020 at 02:41, gjr80  wrote:

> Yes, not surprised, am still working through sensor names and the API to
> get the code right. Fortunately, this disconnect does not affect the
> observational data only battery state field names and some of the
> 'informational' commands such as --system-params. Once I get the battery
> states into the loop packets they can be easily fixed (temporarily) with a
> few field map extensions.
>
> Gary
>
> On Tuesday, 28 July 2020 11:04:45 UTC+10, gary@gmail.com wrote:
>>
>> Though this is not a WH65
>>
>> I have a GW1000, WS68, WH40, WH32-EP, WH32B
>>
>> On Monday, July 27, 2020 at 8:58:54 PM UTC-4 gary@gmail.com wrote:
>>
>>> This is a 915 MHz unit
>>>
>>> Interrogating GW1000 at 10.10.100.125:45000
>>>
>>> GW1000 frequency: 2 (Unknown)
>>> GW1000 sensor type: 1 (WH65)
>>> GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
>>> GW1000 timezone: 19
>>>
>>>
>>> On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:
>>>
 v0.1.0b6 added the --system-params command line option to the driver
 to display a number of GW1000 system parameters, eg:

 GW1000 frequency: 0 (433MHz)
 GW1000 sensor type: 0 (WH24)
 GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
 GW1000 timezone: 94

 Whilst I know which byte to look at for the frequency, and what value
 represents 433MHz as used on my GW1000, I do not know what value is used to
 represent operation on 868MHZ and 915MHz. Was wondering if any users of
 v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the
 frequency their GW1000 uses as well as the output from the following
 command (adjusting python version and path as required):

 $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params

 I don't believe any of the information is particularly sensitive, but
 if you are concerned I really just need to know the frequncy your GW1000
 operates on as well as the line starting 'GW1000 frequency'. If you don't
 know what frequency your GW1000 operates on it should be printed on the
 back of your GW1000 (well at least mine is like that!)

 thanks,
 Gary

>>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/d6b32000-d7a8-483d-9822-6b47d24e1b23o%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/CADASSaTz_2cwJWpabn%2BLpG8wdt%3D-QEVijSUkE_XbDmXWYpZw6g%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread gjr80

Yes, not surprised, am still working through sensor names and the API to 
get the code right. Fortunately, this disconnect does not affect the 
observational data only battery state field names and some of the 
'informational' commands such as --system-params. Once I get the battery 
states into the loop packets they can be easily fixed (temporarily) with a 
few field map extensions.

Gary

On Tuesday, 28 July 2020 11:04:45 UTC+10, gary@gmail.com wrote:
>
> Though this is not a WH65
>
> I have a GW1000, WS68, WH40, WH32-EP, WH32B
>
> On Monday, July 27, 2020 at 8:58:54 PM UTC-4 gary@gmail.com wrote:
>
>> This is a 915 MHz unit
>>
>> Interrogating GW1000 at 10.10.100.125:45000
>>
>> GW1000 frequency: 2 (Unknown)
>> GW1000 sensor type: 1 (WH65)
>> GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
>> GW1000 timezone: 19
>>
>>
>> On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:
>>
>>> v0.1.0b6 added the --system-params command line option to the driver to 
>>> display a number of GW1000 system parameters, eg:
>>>
>>> GW1000 frequency: 0 (433MHz)
>>> GW1000 sensor type: 0 (WH24)
>>> GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
>>> GW1000 timezone: 94
>>>
>>> Whilst I know which byte to look at for the frequency, and what value 
>>> represents 433MHz as used on my GW1000, I do not know what value is used to 
>>> represent operation on 868MHZ and 915MHz. Was wondering if any users of 
>>> v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the 
>>> frequency their GW1000 uses as well as the output from the following 
>>> command (adjusting python version and path as required):
>>>
>>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params
>>>
>>> I don't believe any of the information is particularly sensitive, but if 
>>> you are concerned I really just need to know the frequncy your GW1000 
>>> operates on as well as the line starting 'GW1000 frequency'. If you don't 
>>> know what frequency your GW1000 operates on it should be printed on the 
>>> back of your GW1000 (well at least mine is like that!)
>>>
>>> thanks,
>>> Gary
>>>
>>

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread gjr80

Thanks, I am guessing 868MHz will be 1 but we shall see.

Gary

On Tuesday, 28 July 2020 10:58:54 UTC+10, gary@gmail.com wrote:
>
> This is a 915 MHz unit
>
> Interrogating GW1000 at 10.10.100.125:45000
>
> GW1000 frequency: 2 (Unknown)
> GW1000 sensor type: 1 (WH65)
> GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
> GW1000 timezone: 19
>
>
> On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:
>
>> v0.1.0b6 added the --system-params command line option to the driver to 
>> display a number of GW1000 system parameters, eg:
>>
>> GW1000 frequency: 0 (433MHz)
>> GW1000 sensor type: 0 (WH24)
>> GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
>> GW1000 timezone: 94
>>
>> Whilst I know which byte to look at for the frequency, and what value 
>> represents 433MHz as used on my GW1000, I do not know what value is used to 
>> represent operation on 868MHZ and 915MHz. Was wondering if any users of 
>> v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the 
>> frequency their GW1000 uses as well as the output from the following 
>> command (adjusting python version and path as required):
>>
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params
>>
>> I don't believe any of the information is particularly sensitive, but if 
>> you are concerned I really just need to know the frequncy your GW1000 
>> operates on as well as the line starting 'GW1000 frequency'. If you don't 
>> know what frequency your GW1000 operates on it should be printed on the 
>> back of your GW1000 (well at least mine is like that!)
>>
>> thanks,
>> Gary
>>
>

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread gary....@gmail.com

Though this is not a WH65

I have a GW1000, WS68, WH40, WH32-EP, WH32B

On Monday, July 27, 2020 at 8:58:54 PM UTC-4 gary@gmail.com wrote:

> This is a 915 MHz unit
>
> Interrogating GW1000 at 10.10.100.125:45000
>
> GW1000 frequency: 2 (Unknown)
> GW1000 sensor type: 1 (WH65)
> GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
> GW1000 timezone: 19
>
>
> On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:
>
>> v0.1.0b6 added the --system-params command line option to the driver to 
>> display a number of GW1000 system parameters, eg:
>>
>> GW1000 frequency: 0 (433MHz)
>> GW1000 sensor type: 0 (WH24)
>> GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
>> GW1000 timezone: 94
>>
>> Whilst I know which byte to look at for the frequency, and what value 
>> represents 433MHz as used on my GW1000, I do not know what value is used to 
>> represent operation on 868MHZ and 915MHz. Was wondering if any users of 
>> v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the 
>> frequency their GW1000 uses as well as the output from the following 
>> command (adjusting python version and path as required):
>>
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params
>>
>> I don't believe any of the information is particularly sensitive, but if 
>> you are concerned I really just need to know the frequncy your GW1000 
>> operates on as well as the line starting 'GW1000 frequency'. If you don't 
>> know what frequency your GW1000 operates on it should be printed on the 
>> back of your GW1000 (well at least mine is like that!)
>>
>> thanks,
>> Gary
>>
>

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread gary....@gmail.com

This is a 915 MHz unit

Interrogating GW1000 at 10.10.100.125:45000

GW1000 frequency: 2 (Unknown)
GW1000 sensor type: 1 (WH65)
GW1000 decoded UTC: 2020-07-27 20:57:43 UTC (1595883463)
GW1000 timezone: 19


On Monday, July 27, 2020 at 8:53:36 PM UTC-4 gjr80 wrote:

> v0.1.0b6 added the --system-params command line option to the driver to 
> display a number of GW1000 system parameters, eg:
>
> GW1000 frequency: 0 (433MHz)
> GW1000 sensor type: 0 (WH24)
> GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
> GW1000 timezone: 94
>
> Whilst I know which byte to look at for the frequency, and what value 
> represents 433MHz as used on my GW1000, I do not know what value is used to 
> represent operation on 868MHZ and 915MHz. Was wondering if any users of 
> v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the 
> frequency their GW1000 uses as well as the output from the following 
> command (adjusting python version and path as required):
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params
>
> I don't believe any of the information is particularly sensitive, but if 
> you are concerned I really just need to know the frequncy your GW1000 
> operates on as well as the line starting 'GW1000 frequency'. If you don't 
> know what frequency your GW1000 operates on it should be printed on the 
> back of your GW1000 (well at least mine is like that!)
>
> thanks,
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/1e253425-6509-4538-9dfe-3a44c80f2e14n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread gjr80

v0.1.0b6 added the --system-params command line option to the driver to 
display a number of GW1000 system parameters, eg:

GW1000 frequency: 0 (433MHz)
GW1000 sensor type: 0 (WH24)
GW1000 decoded UTC: 2020-07-28 10:31:46 UTC (1595932306)
GW1000 timezone: 94

Whilst I know which byte to look at for the frequency, and what value 
represents 433MHz as used on my GW1000, I do not know what value is used to 
represent operation on 868MHZ and 915MHz. Was wondering if any users of 
v0.1.0b6 that use a GW1000 operating on 868MHz or 915MHZ could post the 
frequency their GW1000 uses as well as the output from the following 
command (adjusting python version and path as required):

$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --system-params

I don't believe any of the information is particularly sensitive, but if 
you are concerned I really just need to know the frequncy your GW1000 
operates on as well as the line starting 'GW1000 frequency'. If you don't 
know what frequency your GW1000 operates on it should be printed on the 
back of your GW1000 (well at least mine is like that!)

thanks,
Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/61de1f96-e437-44c2-8d94-f69dbcd4cb18o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread steeple ian

Bill,

I will send you the sensor mapping that you need to use later today when I
am near my computer.

Ian

On Mon, 27 Jul 2020 at 11:03, Bill Arthur  wrote:

> Thanks Gary.
> Your instructions worked perfectly.
>
> I'm still seeing a couple of things. Here are links to two reporting
> stations. They both receive data from the same GW-1000
> The -1 station uses the old push method. The -5 station uses the new API
> method.  I'm seeing differences in wind direction and barometer
> -1 Station 
> -5 Station 
> On Monday, July 27, 2020 at 12:58:20 AM UTC-5 gjr80 wrote:
>
>> I have released v0.1.0b6 on Github
>> . A summary of the
>> significant changes can be found against the v0.1.0b6 release on Github. It
>> has not (fully) addressed the issue of some battery states not making their
>> way through to the loop packets, unfortunately that is still a  work in
>> progress.
>>
>> Those that have already installed the driver can download and install
>> v0.1.0b6 using the following commands depending on your WeeWX install type:
>>
>> for setup.py installs:
>>
>> $ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig
>> .py
>> $ sudo wget -P /home/weewx/bin/user https://
>> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py
>>
>> for package installs:
>>
>> $ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/
>> gw1000_orig.py
>> $ sudo wget -P /usr/share/weewx/user https://
>> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py
>>
>> There has been no change to the [GW1000] structure so you can just
>> restart WeeWX/run v0.1.0b6 directly without further changes.
>>
>> Gary
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/871c9da9-3218-4bcf-9b14-321678e4e8f0n%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/CADASSaTA06p5ZZqWsPDO3Knac_Q%2BL%2Bw3a07ZeH9PzCSLr8pRkw%40mail.gmail.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-27 Thread Bill Arthur

Thanks Gary.  
Your instructions worked perfectly.

I'm still seeing a couple of things. Here are links to two reporting 
stations. They both receive data from the same GW-1000
The -1 station uses the old push method. The -5 station uses the new API 
method.  I'm seeing differences in wind direction and barometer
-1 Station 
-5 Station 
On Monday, July 27, 2020 at 12:58:20 AM UTC-5 gjr80 wrote:

> I have released v0.1.0b6 on Github 
> . A summary of the 
> significant changes can be found against the v0.1.0b6 release on Github. It 
> has not (fully) addressed the issue of some battery states not making their 
> way through to the loop packets, unfortunately that is still a  work in 
> progress.
>
> Those that have already installed the driver can download and install 
> v0.1.0b6 using the following commands depending on your WeeWX install type:
>
> for setup.py installs:
>
> $ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig.
> py
> $ sudo wget -P /home/weewx/bin/user https://
> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py
>
> for package installs:
>
> $ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/
> gw1000_orig.py
> $ sudo wget -P /usr/share/weewx/user https://
> raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py
>
> There has been no change to the [GW1000] structure so you can just 
> restart WeeWX/run v0.1.0b6 directly without further changes.
>
> Gary
>
>
>

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-26 Thread gjr80

I have released v0.1.0b6 on Github 
. A summary of the 
significant changes can be found against the v0.1.0b6 release on Github. It 
has not (fully) addressed the issue of some battery states not making their 
way through to the loop packets, unfortunately that is still a  work in 
progress.

Those that have already installed the driver can download and install 
v0.1.0b6 using the following commands depending on your WeeWX install type:

for setup.py installs:

$ sudo mv /home/weewx/bin/user/gw1000.py /home/weewx/bin/user/gw1000_orig.py
$ sudo wget -P /home/weewx/bin/user https:
//raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py

for package installs:

$ sudo mv /usr/share/weewx/user/gw1000.py /usr/share/weewx/user/gw1000_orig.
py
$ sudo wget -P /usr/share/weewx/user https:
//raw.githubusercontent.com/gjr80/weewx-gw1000/v0.1.0b6/bin/user/gw1000.py

There has been no change to the [GW1000] structure so you can just restart 
WeeWX/run v0.1.0b6 directly without further changes.

Gary


-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a88dee6c-8fb5-4a44-91f6-51549374a18eo%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-26 Thread 'NanoG5Kite' via weewx-user

It´s in process on Github now... better to post there.

https://github.com/gjr80/weewx-gw1000/issues/6

Am Sonntag, 26. Juli 2020 14:15:18 UTC+2 schrieb Vetti52:
>
> That's the output:
> root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 
> -m user.gw1000 --debug=3 --sensors
> Using configuration file /etc/weewx/weewx.conf
>
> Interrogating GW1000 at 192.168.100.150:45000
>
> Sensor Status
> WH65   sensor ID: f9  signal: 0  battery: 4
> WS68   sensor is registering...
> WS80   sensor is registering...
> WH40   sensor is registering...
> WH32   sensor is registering...
> WH31 ch1   sensor is registering...
> WH31 ch2   sensor is registering...
> WH31 ch3   sensor is registering...
> WH31 ch4   sensor is registering...
> WH31 ch5   sensor is registering...
> WH31 ch6   sensor is registering...
> WH31 ch7   sensor is registering...
> WH31 ch8   sensor is registering...
> WH51 ch1   sensor is registering...
> WH51 ch2   sensor is registering...
> WH51 ch3   sensor is registering...
> WH51 ch4   sensor is registering...
> WH51 ch5   sensor is registering...
> WH51 ch6   sensor is registering...
> WH51 ch7   sensor is registering...
> WH51 ch8   sensor is registering...
> WH41 ch1   sensor is registering...
> WH41 ch2   sensor is registering...
> WH41 ch3   sensor is registering...
> WH41 ch4   sensor is registering...
> WH57   sensor is registering...
> WH55 ch1   sensor is registering...
> WH55 ch2   sensor is registering...
> WH55 ch3   sensor is registering...
> WH55 ch4   sensor is registering...
>
> root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 
> -m user.gw1000 --debug=3 --live-data
> Using configuration file /etc/weewx/weewx.conf
>
> Interrogating GW1000 at 192.168.100.150:45000
>
> GW1000 live sensor data: absbarometer: 1005.9, datetime: 1595765605, 
> daymaxwind: 8.4, gustspeed: 3.0, inhumid: 76, intemp: 20.7, light: 
> 117722.0, outhumid: 82, outtemp: 19.8, rainday: 10.2, rainevent: 10.2, 
> rainmonth: 83.9, rainrate: 0.0, rainweek: 10.2, rainyear: 85.7, 
> relbarometer: 1008.1, uv: 367.5, uvi: 9, winddir: 27.8, windspeed: 1.8
>
>
>
>
> Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:
>>
>> Can you please issue the following two commands(assuming a setyp.py 
>> install) and post the console output and (WeeWX) log output from each:
>>
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data
>>
>> If possible, would also help to know what solar radiation value you are 
>> seeing at the time the commands were executed. Also, no need to stop the 
>> interceptor, gw1000 will happily interrogate the GW100 even while the 
>> GW1000 sends to the interceptor. Note you may have to change the python 
>> command to python2 or python3 if WeeWX is set to run under a different 
>> python version to the default on your system.
>>
>> Gary
>>
>> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>>>
>>> The setting 'radiation': 'solar_radiation', is copied from 
>>> interceptor.py, which is propagated into radiation in weewx. When changing 
>>> to gw1000 api driver, the data are lost. So I went back to the 
>>> interceptor.py. You can see the little gap in the graph during my test of 
>>> the gw1000 driver:
>>>
>>> [image: radiation.jpg]
>>> I have changed the title into German in Weewx.conf 
>>>
>>> Generic
>>> radiation = Sonnenstrahlung
>>>
>>> So, somewhere the observation type radiation has to be filled with data. 
>>> In interceptor.py, this is done by 'solar_radiation' which comes from 
>>> the ecowitt-customized upload. I would just like to continue with these 
>>> data.
>>>
>>> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:

 Whilst there definitely is nothing in the API for retrieving what WeeWX 
 knows as 'radiation', there is a calibration setting labelled 'SolarRad 
 Gain' in the WS View app (interestingly there is no gain setting for 
 anything to do with 'light', luminosity, illuminance etc so it could be a 
 mis-labelling/inconsistent labelling of the parameter in the app). If you 
 have been obtaining 'radiation' data via the interceptor driver can you 
 please give me some further details, it may be a case of the GW1000 
 deriving a radiation value suitable for on-line weather services such as 
 WU 
 and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
 it may be that there is something else available in the API that is not 
 documented.

 Gary

 On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>
> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>
>> When running reconfigure with prompts, there are two changes, that 
>> occured in my case without asking:
>> group_pressure turns to inHg, and group_speed and group_speed2 turn 
>> to mile_per_hour and ~2 respective

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-26 Thread Vetti52

Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

GW1000 live sensor data: absbarometer: 1006.2, datetime: 1595765980, 
daymaxwind: 8.4, gustspeed: 0.7, inhumid: 76, intemp: 20.7, light: 24226.0, 
outhumid: 82, outtemp: 19.7, rainday: 10.2, rainevent: 10.2, rainmonth: 83.9
, rainrate: 0.0, rainweek: 10.2, rainyear: 85.7, relbarometer: 1008.4, uv: 
49.1, uvi: 1, winddir: 27.4, windspeed: 0.3


solar radiation acutally is
853 W/m²

Sorry, I forgot

Peter

Am Sonntag, 26. Juli 2020 10:18:52 UTC+2 schrieb NanoG5Kite:
>
> Several samples posted on Github seems to be e.g. uv: 9.1 x 10 = 
> 91,9w/m²
>
> Matthias
>
> Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:
>>
>> Can you please issue the following two commands(assuming a setyp.py 
>> install) and post the console output and (WeeWX) log output from each:
>>
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data
>>
>> If possible, would also help to know what solar radiation value you are 
>> seeing at the time the commands were executed. Also, no need to stop the 
>> interceptor, gw1000 will happily interrogate the GW100 even while the 
>> GW1000 sends to the interceptor. Note you may have to change the python 
>> command to python2 or python3 if WeeWX is set to run under a different 
>> python version to the default on your system.
>>
>> Gary
>>
>> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>>>
>>> The setting 'radiation': 'solar_radiation', is copied from 
>>> interceptor.py, which is propagated into radiation in weewx. When changing 
>>> to gw1000 api driver, the data are lost. So I went back to the 
>>> interceptor.py. You can see the little gap in the graph during my test of 
>>> the gw1000 driver:
>>>
>>> [image: radiation.jpg]
>>> I have changed the title into German in Weewx.conf 
>>>
>>> Generic
>>> radiation = Sonnenstrahlung
>>>
>>> So, somewhere the observation type radiation has to be filled with data. 
>>> In interceptor.py, this is done by 'solar_radiation' which comes from 
>>> the ecowitt-customized upload. I would just like to continue with these 
>>> data.
>>>
>>> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:

 Whilst there definitely is nothing in the API for retrieving what WeeWX 
 knows as 'radiation', there is a calibration setting labelled 'SolarRad 
 Gain' in the WS View app (interestingly there is no gain setting for 
 anything to do with 'light', luminosity, illuminance etc so it could be a 
 mis-labelling/inconsistent labelling of the parameter in the app). If you 
 have been obtaining 'radiation' data via the interceptor driver can you 
 please give me some further details, it may be a case of the GW1000 
 deriving a radiation value suitable for on-line weather services such as 
 WU 
 and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
 it may be that there is something else available in the API that is not 
 documented.

 Gary

 On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>
> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>
>> When running reconfigure with prompts, there are two changes, that 
>> occured in my case without asking:
>> group_pressure turns to inHg, and group_speed and group_speed2 turn 
>> to mile_per_hour and ~2 respectively.You better diff old and new 
>> version before restarting.
>>
>
> This almost certainly is an issue with wee_config and your config; 
> the GW1000 driver has no ability to change WeeWX units/unit system. I do 
> have a vague recollection that there was a previous issue that was raised 
> (and fixed) regarding unexpected unit changes (it may have been on 
> upgrade). I will make a note to look into this.
>  
>
>> In addition, 'radiation': 'solar_radiation', is missing in 
>> default_field_map 
>> in gw1000.py. 
>>
>
> This is intentional. Unfortunately the GW1000 API has no ability to 
> obtain what in WeeWX parlance we know as field radiation (solar 
> insolation). The API can return what the API terms 'light' or luminosity 
> in 
> Lux as well as UV index and what the API terms 'UV' in microWatts per 
> square metre. Some folks derive field radiation from luminosity 
> though I believe the relationship is somewhat complex. It's not the place 
> for the GW1000 driver to derive obs such as radiation from other obs, 
> rather derived observations should be derived by the StdWXCalculate 
> service. Whilst the StdWXCalculate service does not really lend 
> itself at present to the addition of user defined derived obs, a user can 
> add simple derived obs by adding appropriate entries under [StdCalibrate] 
> [[Corrections]] in weewx.conf, for example:
>>>

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-26 Thread Vetti52

That's the output:
root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 -m 
user.gw1000 --debug=3 --sensors
Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

Sensor Status
WH65   sensor ID: f9  signal: 0  battery: 4
WS68   sensor is registering...
WS80   sensor is registering...
WH40   sensor is registering...
WH32   sensor is registering...
WH31 ch1   sensor is registering...
WH31 ch2   sensor is registering...
WH31 ch3   sensor is registering...
WH31 ch4   sensor is registering...
WH31 ch5   sensor is registering...
WH31 ch6   sensor is registering...
WH31 ch7   sensor is registering...
WH31 ch8   sensor is registering...
WH51 ch1   sensor is registering...
WH51 ch2   sensor is registering...
WH51 ch3   sensor is registering...
WH51 ch4   sensor is registering...
WH51 ch5   sensor is registering...
WH51 ch6   sensor is registering...
WH51 ch7   sensor is registering...
WH51 ch8   sensor is registering...
WH41 ch1   sensor is registering...
WH41 ch2   sensor is registering...
WH41 ch3   sensor is registering...
WH41 ch4   sensor is registering...
WH57   sensor is registering...
WH55 ch1   sensor is registering...
WH55 ch2   sensor is registering...
WH55 ch3   sensor is registering...
WH55 ch4   sensor is registering...

root@RaspBee:/usr/share/weewx/user# PYTHONPATH=/usr/share/weewx python3 -m 
user.gw1000 --debug=3 --live-data
Using configuration file /etc/weewx/weewx.conf

Interrogating GW1000 at 192.168.100.150:45000

GW1000 live sensor data: absbarometer: 1005.9, datetime: 1595765605, 
daymaxwind: 8.4, gustspeed: 3.0, inhumid: 76, intemp: 20.7, light: 117722.0, 
outhumid: 82, outtemp: 19.8, rainday: 10.2, rainevent: 10.2, rainmonth: 83.9
, rainrate: 0.0, rainweek: 10.2, rainyear: 85.7, relbarometer: 1008.1, uv: 
367.5, uvi: 9, winddir: 27.8, windspeed: 1.8




Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:
>
> Can you please issue the following two commands(assuming a setyp.py 
> install) and post the console output and (WeeWX) log output from each:
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data
>
> If possible, would also help to know what solar radiation value you are 
> seeing at the time the commands were executed. Also, no need to stop the 
> interceptor, gw1000 will happily interrogate the GW100 even while the 
> GW1000 sends to the interceptor. Note you may have to change the python 
> command to python2 or python3 if WeeWX is set to run under a different 
> python version to the default on your system.
>
> Gary
>
> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>>
>> The setting 'radiation': 'solar_radiation', is copied from 
>> interceptor.py, which is propagated into radiation in weewx. When changing 
>> to gw1000 api driver, the data are lost. So I went back to the 
>> interceptor.py. You can see the little gap in the graph during my test of 
>> the gw1000 driver:
>>
>> [image: radiation.jpg]
>> I have changed the title into German in Weewx.conf 
>>
>> Generic
>> radiation = Sonnenstrahlung
>>
>> So, somewhere the observation type radiation has to be filled with data. 
>> In interceptor.py, this is done by 'solar_radiation' which comes from 
>> the ecowitt-customized upload. I would just like to continue with these 
>> data.
>>
>> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>>>
>>> Whilst there definitely is nothing in the API for retrieving what WeeWX 
>>> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
>>> Gain' in the WS View app (interestingly there is no gain setting for 
>>> anything to do with 'light', luminosity, illuminance etc so it could be a 
>>> mis-labelling/inconsistent labelling of the parameter in the app). If you 
>>> have been obtaining 'radiation' data via the interceptor driver can you 
>>> please give me some further details, it may be a case of the GW1000 
>>> deriving a radiation value suitable for on-line weather services such as WU 
>>> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
>>> it may be that there is something else available in the API that is not 
>>> documented.
>>>
>>> Gary
>>>
>>> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:

 On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>
> When running reconfigure with prompts, there are two changes, that 
> occured in my case without asking:
> group_pressure turns to inHg, and group_speed and group_speed2 turn 
> to mile_per_hour and ~2 respectively.You better diff old and new 
> version before restarting.
>

 This almost certainly is an issue with wee_config and your config; the 
 GW1000 driver has no ability to change WeeWX units/unit system. I do have 
 a 
 vague recollection that there was a previous issue that was raised (and 
 fixed)

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-26 Thread 'NanoG5Kite' via weewx-user

Several samples posted on Github seems to be e.g. uv: 9.1 x 10 = 
91,9w/m²

Matthias

Am Sonntag, 26. Juli 2020 10:00:15 UTC+2 schrieb gjr80:
>
> Can you please issue the following two commands(assuming a setyp.py 
> install) and post the console output and (WeeWX) log output from each:
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --sensors
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --debug=3 --live-data
>
> If possible, would also help to know what solar radiation value you are 
> seeing at the time the commands were executed. Also, no need to stop the 
> interceptor, gw1000 will happily interrogate the GW100 even while the 
> GW1000 sends to the interceptor. Note you may have to change the python 
> command to python2 or python3 if WeeWX is set to run under a different 
> python version to the default on your system.
>
> Gary
>
> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>>
>> The setting 'radiation': 'solar_radiation', is copied from 
>> interceptor.py, which is propagated into radiation in weewx. When changing 
>> to gw1000 api driver, the data are lost. So I went back to the 
>> interceptor.py. You can see the little gap in the graph during my test of 
>> the gw1000 driver:
>>
>> [image: radiation.jpg]
>> I have changed the title into German in Weewx.conf 
>>
>> Generic
>> radiation = Sonnenstrahlung
>>
>> So, somewhere the observation type radiation has to be filled with data. 
>> In interceptor.py, this is done by 'solar_radiation' which comes from 
>> the ecowitt-customized upload. I would just like to continue with these 
>> data.
>>
>> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>>>
>>> Whilst there definitely is nothing in the API for retrieving what WeeWX 
>>> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
>>> Gain' in the WS View app (interestingly there is no gain setting for 
>>> anything to do with 'light', luminosity, illuminance etc so it could be a 
>>> mis-labelling/inconsistent labelling of the parameter in the app). If you 
>>> have been obtaining 'radiation' data via the interceptor driver can you 
>>> please give me some further details, it may be a case of the GW1000 
>>> deriving a radiation value suitable for on-line weather services such as WU 
>>> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
>>> it may be that there is something else available in the API that is not 
>>> documented.
>>>
>>> Gary
>>>
>>> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:

 On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>
> When running reconfigure with prompts, there are two changes, that 
> occured in my case without asking:
> group_pressure turns to inHg, and group_speed and group_speed2 turn 
> to mile_per_hour and ~2 respectively.You better diff old and new 
> version before restarting.
>

 This almost certainly is an issue with wee_config and your config; the 
 GW1000 driver has no ability to change WeeWX units/unit system. I do have 
 a 
 vague recollection that there was a previous issue that was raised (and 
 fixed) regarding unexpected unit changes (it may have been on upgrade). I 
 will make a note to look into this.

> In addition, 'radiation': 'solar_radiation', is missing in 
> default_field_map 
> in gw1000.py. 
>

 This is intentional. Unfortunately the GW1000 API has no ability to 
 obtain what in WeeWX parlance we know as field radiation (solar 
 insolation). The API can return what the API terms 'light' or luminosity 
 in 
 Lux as well as UV index and what the API terms 'UV' in microWatts per 
 square metre. Some folks derive field radiation from luminosity though 
 I believe the relationship is somewhat complex. It's not the place for the 
 GW1000 driver to derive obs such as radiation from other obs, rather 
 derived observations should be derived by the StdWXCalculate service. 
 Whilst the StdWXCalculate service does not really lend itself at 
 present to the addition of user defined derived obs, a user can add simple 
 derived obs by adding appropriate entries under [StdCalibrate] 
 [[Corrections]] in weewx.conf, for example:

 [StdCalibrate]
 [[Corrections]]
 new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)

 would create the field new_obs using the (nonsense) formula shown. The 
 default GW1000 driver mapping passes the light, UV and UV index 
 observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
 field UV) so they are available for use in StdCalibrate as required.

 Gary

>>>

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-26 Thread gjr80

Can you please issue the following two commands(assuming a setyp.py 
install) and post the console output and (WeeWX) log output from each:

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

If possible, would also help to know what solar radiation value you are 
seeing at the time the commands were executed. Also, no need to stop the 
interceptor, gw1000 will happily interrogate the GW100 even while the 
GW1000 sends to the interceptor. Note you may have to change the python 
command to python2 or python3 if WeeWX is set to run under a different 
python version to the default on your system.

Gary

On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote:
>
> The setting 'radiation': 'solar_radiation', is copied from 
> interceptor.py, which is propagated into radiation in weewx. When changing 
> to gw1000 api driver, the data are lost. So I went back to the 
> interceptor.py. You can see the little gap in the graph during my test of 
> the gw1000 driver:
>
> [image: radiation.jpg]
> I have changed the title into German in Weewx.conf 
>
> Generic
> radiation = Sonnenstrahlung
>
> So, somewhere the observation type radiation has to be filled with data. 
> In interceptor.py, this is done by 'solar_radiation' which comes from the 
> ecowitt-customized upload. I would just like to continue with these data.
>
> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>>
>> Whilst there definitely is nothing in the API for retrieving what WeeWX 
>> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
>> Gain' in the WS View app (interestingly there is no gain setting for 
>> anything to do with 'light', luminosity, illuminance etc so it could be a 
>> mis-labelling/inconsistent labelling of the parameter in the app). If you 
>> have been obtaining 'radiation' data via the interceptor driver can you 
>> please give me some further details, it may be a case of the GW1000 
>> deriving a radiation value suitable for on-line weather services such as WU 
>> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
>> it may be that there is something else available in the API that is not 
>> documented.
>>
>> Gary
>>
>> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>>>
>>> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:

 When running reconfigure with prompts, there are two changes, that 
 occured in my case without asking:
 group_pressure turns to inHg, and group_speed and group_speed2 turn to 
 mile_per_hour 
 and ~2 respectively.You better diff old and new version before 
 restarting.

>>>
>>> This almost certainly is an issue with wee_config and your config; the 
>>> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
>>> vague recollection that there was a previous issue that was raised (and 
>>> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
>>> will make a note to look into this.
>>>  
>>>
 In addition, 'radiation': 'solar_radiation', is missing in 
 default_field_map 
 in gw1000.py. 

>>>
>>> This is intentional. Unfortunately the GW1000 API has no ability to 
>>> obtain what in WeeWX parlance we know as field radiation (solar 
>>> insolation). The API can return what the API terms 'light' or luminosity in 
>>> Lux as well as UV index and what the API terms 'UV' in microWatts per 
>>> square metre. Some folks derive field radiation from luminosity though 
>>> I believe the relationship is somewhat complex. It's not the place for the 
>>> GW1000 driver to derive obs such as radiation from other obs, rather 
>>> derived observations should be derived by the StdWXCalculate service. 
>>> Whilst the StdWXCalculate service does not really lend itself at 
>>> present to the addition of user defined derived obs, a user can add simple 
>>> derived obs by adding appropriate entries under [StdCalibrate] 
>>> [[Corrections]] in weewx.conf, for example:
>>>
>>> [StdCalibrate]
>>> [[Corrections]]
>>> new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>>>
>>> would create the field new_obs using the (nonsense) formula shown. The 
>>> default GW1000 driver mapping passes the light, UV and UV index 
>>> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
>>> field UV) so they are available for use in StdCalibrate as required.
>>>
>>> Gary
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c9e4338c-492c-41e4-a81a-57599a6c22eao%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-26 Thread Vetti52



The setting 'radiation': 'solar_radiation', is copied from interceptor.py, 
which is propagated into radiation in weewx. When changing to gw1000 api 
driver, the data are lost. So I went back to the interceptor.py. You can 
see the little gap in the graph during my test of the gw1000 driver:

[image: radiation.jpg]
I have changed the title into German in Weewx.conf 

Generic
radiation = Sonnenstrahlung

So, somewhere the observation type radiation has to be filled with data. In 
interceptor.py, this is done by 'solar_radiation' which comes from the 
ecowitt-customized upload. I would just like to continue with these data.

Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>
> Whilst there definitely is nothing in the API for retrieving what WeeWX 
> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
> Gain' in the WS View app (interestingly there is no gain setting for 
> anything to do with 'light', luminosity, illuminance etc so it could be a 
> mis-labelling/inconsistent labelling of the parameter in the app). If you 
> have been obtaining 'radiation' data via the interceptor driver can you 
> please give me some further details, it may be a case of the GW1000 
> deriving a radiation value suitable for on-line weather services such as WU 
> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
> it may be that there is something else available in the API that is not 
> documented.
>
> Gary
>
> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>>
>> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>>
>>> When running reconfigure with prompts, there are two changes, that 
>>> occured in my case without asking:
>>> group_pressure turns to inHg, and group_speed and group_speed2 turn to 
>>> mile_per_hour 
>>> and ~2 respectively.You better diff old and new version before 
>>> restarting.
>>>
>>
>> This almost certainly is an issue with wee_config and your config; the 
>> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
>> vague recollection that there was a previous issue that was raised (and 
>> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
>> will make a note to look into this.
>>  
>>
>>> In addition, 'radiation': 'solar_radiation', is missing in 
>>> default_field_map 
>>> in gw1000.py. 
>>>
>>
>> This is intentional. Unfortunately the GW1000 API has no ability to 
>> obtain what in WeeWX parlance we know as field radiation (solar 
>> insolation). The API can return what the API terms 'light' or luminosity in 
>> Lux as well as UV index and what the API terms 'UV' in microWatts per 
>> square metre. Some folks derive field radiation from luminosity though I 
>> believe the relationship is somewhat complex. It's not the place for the 
>> GW1000 driver to derive obs such as radiation from other obs, rather 
>> derived observations should be derived by the StdWXCalculate service. 
>> Whilst the StdWXCalculate service does not really lend itself at present 
>> to the addition of user defined derived obs, a user can add simple derived 
>> obs by adding appropriate entries under [StdCalibrate] [[Corrections]] 
>> in weewx.conf, for example:
>>
>> [StdCalibrate]
>> [[Corrections]]
>> new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>>
>> would create the field new_obs using the (nonsense) formula shown. The 
>> default GW1000 driver mapping passes the light, UV and UV index 
>> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
>> field UV) so they are available for use in StdCalibrate as required.
>>
>> Gary
>>
>

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-26 Thread gjr80

Hmm, seems GitHub has decided not to notify me of new issues/posts to 
issues on my own repos. I have noticed a few there now and will work 
through them IDC.

Gary

On Sunday, 26 July 2020 16:59:01 UTC+10, gjr80 wrote:
>
> I don't mind, Github is probably easier for tracking and hopefully keeps 
> one problem per issue unlike posts here which tend to grow many heads. All 
> I ask is that some appropriate details of the problem are included (eg an 
> explanation of the problem and a startup debug log extract - a list of 
> attached sensors/stations would help too) rather than ' does not work'
>
> Gary
>
> On Sunday, 26 July 2020 16:39:19 UTC+10, NanoG5Kite wrote:
>>
>> Is‘t it better to post possible errors on Githup? In addition to 
>> Radiation I‘m also missing rain and current rain rate now.
>> Will open issues on Github now.
>>
>>

-- 
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/009d4653-48ae-4c66-9c86-48a1d0e15322o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

I don't mind, Github is probably easier for tracking and hopefully keeps 
one problem per issue unlike posts here which tend to grow many heads. All 
I ask is that some appropriate details of the problem are included (eg an 
explanation of the problem and a startup debug log extract - a list of 
attached sensors/stations would help too) rather than ' does not work'

Gary

On Sunday, 26 July 2020 16:39:19 UTC+10, NanoG5Kite wrote:
>
> Is‘t it better to post possible errors on Githup? In addition to Radiation 
> I‘m also missing rain and current rain rate now.
> Will open issues on Github now.
>
> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>>
>> Whilst there definitely is nothing in the API for retrieving what WeeWX 
>> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
>> Gain' in the WS View app (interestingly there is no gain setting for 
>> anything to do with 'light', luminosity, illuminance etc so it could be a 
>> mis-labelling/inconsistent labelling of the parameter in the app). If you 
>> have been obtaining 'radiation' data via the interceptor driver can you 
>> please give me some further details, it may be a case of the GW1000 
>> deriving a radiation value suitable for on-line weather services such as WU 
>> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
>> it may be that there is something else available in the API that is not 
>> documented.
>>
>> Gary
>>
>> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>>>
>>> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:

 When running reconfigure with prompts, there are two changes, that 
 occured in my case without asking:
 group_pressure turns to inHg, and group_speed and group_speed2 turn to 
 mile_per_hour 
 and ~2 respectively.You better diff old and new version before 
 restarting.

>>>
>>> This almost certainly is an issue with wee_config and your config; the 
>>> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
>>> vague recollection that there was a previous issue that was raised (and 
>>> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
>>> will make a note to look into this.
>>>  
>>>
 In addition, 'radiation': 'solar_radiation', is missing in 
 default_field_map 
 in gw1000.py. 

>>>
>>> This is intentional. Unfortunately the GW1000 API has no ability to 
>>> obtain what in WeeWX parlance we know as field radiation (solar 
>>> insolation). The API can return what the API terms 'light' or luminosity in 
>>> Lux as well as UV index and what the API terms 'UV' in microWatts per 
>>> square metre. Some folks derive field radiation from luminosity though 
>>> I believe the relationship is somewhat complex. It's not the place for the 
>>> GW1000 driver to derive obs such as radiation from other obs, rather 
>>> derived observations should be derived by the StdWXCalculate service. 
>>> Whilst the StdWXCalculate service does not really lend itself at 
>>> present to the addition of user defined derived obs, a user can add simple 
>>> derived obs by adding appropriate entries under [StdCalibrate] 
>>> [[Corrections]] in weewx.conf, for example:
>>>
>>> [StdCalibrate]
>>> [[Corrections]]
>>> new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>>>
>>> would create the field new_obs using the (nonsense) formula shown. The 
>>> default GW1000 driver mapping passes the light, UV and UV index 
>>> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
>>> field UV) so they are available for use in StdCalibrate as required.
>>>
>>> Gary
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/98df7446-1562-4186-8f9b-fd6da1eabd9do%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-25 Thread 'NanoG5Kite' via weewx-user


https://github.com/gjr80/weewx-gw1000/issues

Am Sonntag, 26. Juli 2020 08:39:19 UTC+2 schrieb NanoG5Kite:
>
> Is‘t it better to post possible errors on Githup? In addition to Radiation 
> I‘m also missing rain and current rain rate now.
> Will open issues on Github now.
>
> Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>>
>> Whilst there definitely is nothing in the API for retrieving what WeeWX 
>> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
>> Gain' in the WS View app (interestingly there is no gain setting for 
>> anything to do with 'light', luminosity, illuminance etc so it could be a 
>> mis-labelling/inconsistent labelling of the parameter in the app). If you 
>> have been obtaining 'radiation' data via the interceptor driver can you 
>> please give me some further details, it may be a case of the GW1000 
>> deriving a radiation value suitable for on-line weather services such as WU 
>> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
>> it may be that there is something else available in the API that is not 
>> documented.
>>
>> Gary
>>
>> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>>>
>>> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:

 When running reconfigure with prompts, there are two changes, that 
 occured in my case without asking:
 group_pressure turns to inHg, and group_speed and group_speed2 turn to 
 mile_per_hour 
 and ~2 respectively.You better diff old and new version before 
 restarting.

>>>
>>> This almost certainly is an issue with wee_config and your config; the 
>>> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
>>> vague recollection that there was a previous issue that was raised (and 
>>> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
>>> will make a note to look into this.
>>>  
>>>
 In addition, 'radiation': 'solar_radiation', is missing in 
 default_field_map 
 in gw1000.py. 

>>>
>>> This is intentional. Unfortunately the GW1000 API has no ability to 
>>> obtain what in WeeWX parlance we know as field radiation (solar 
>>> insolation). The API can return what the API terms 'light' or luminosity in 
>>> Lux as well as UV index and what the API terms 'UV' in microWatts per 
>>> square metre. Some folks derive field radiation from luminosity though 
>>> I believe the relationship is somewhat complex. It's not the place for the 
>>> GW1000 driver to derive obs such as radiation from other obs, rather 
>>> derived observations should be derived by the StdWXCalculate service. 
>>> Whilst the StdWXCalculate service does not really lend itself at 
>>> present to the addition of user defined derived obs, a user can add simple 
>>> derived obs by adding appropriate entries under [StdCalibrate] 
>>> [[Corrections]] in weewx.conf, for example:
>>>
>>> [StdCalibrate]
>>> [[Corrections]]
>>> new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>>>
>>> would create the field new_obs using the (nonsense) formula shown. The 
>>> default GW1000 driver mapping passes the light, UV and UV index 
>>> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
>>> field UV) so they are available for use in StdCalibrate as required.
>>>
>>> Gary
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/36981b0c-54d7-44f6-81c2-4089771e75e8o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-25 Thread 'NanoG5Kite' via weewx-user

Is‘t it better to post possible errors on Githup? In addition to Radiation 
I‘m also missing rain and current rain rate now.
Will open issues on Github now.

Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>
> Whilst there definitely is nothing in the API for retrieving what WeeWX 
> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
> Gain' in the WS View app (interestingly there is no gain setting for 
> anything to do with 'light', luminosity, illuminance etc so it could be a 
> mis-labelling/inconsistent labelling of the parameter in the app). If you 
> have been obtaining 'radiation' data via the interceptor driver can you 
> please give me some further details, it may be a case of the GW1000 
> deriving a radiation value suitable for on-line weather services such as WU 
> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
> it may be that there is something else available in the API that is not 
> documented.
>
> Gary
>
> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>>
>> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>>
>>> When running reconfigure with prompts, there are two changes, that 
>>> occured in my case without asking:
>>> group_pressure turns to inHg, and group_speed and group_speed2 turn to 
>>> mile_per_hour 
>>> and ~2 respectively.You better diff old and new version before 
>>> restarting.
>>>
>>
>> This almost certainly is an issue with wee_config and your config; the 
>> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
>> vague recollection that there was a previous issue that was raised (and 
>> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
>> will make a note to look into this.
>>  
>>
>>> In addition, 'radiation': 'solar_radiation', is missing in 
>>> default_field_map 
>>> in gw1000.py. 
>>>
>>
>> This is intentional. Unfortunately the GW1000 API has no ability to 
>> obtain what in WeeWX parlance we know as field radiation (solar 
>> insolation). The API can return what the API terms 'light' or luminosity in 
>> Lux as well as UV index and what the API terms 'UV' in microWatts per 
>> square metre. Some folks derive field radiation from luminosity though I 
>> believe the relationship is somewhat complex. It's not the place for the 
>> GW1000 driver to derive obs such as radiation from other obs, rather 
>> derived observations should be derived by the StdWXCalculate service. 
>> Whilst the StdWXCalculate service does not really lend itself at present 
>> to the addition of user defined derived obs, a user can add simple derived 
>> obs by adding appropriate entries under [StdCalibrate] [[Corrections]] 
>> in weewx.conf, for example:
>>
>> [StdCalibrate]
>> [[Corrections]]
>> new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>>
>> would create the field new_obs using the (nonsense) formula shown. The 
>> default GW1000 driver mapping passes the light, UV and UV index 
>> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
>> field UV) so they are available for use in StdCalibrate as required.
>>
>> Gary
>>
>

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

Whilst there definitely is nothing in the API for retrieving what WeeWX 
knows as 'radiation', there is a calibration setting labelled 'SolarRad 
Gain' in the WS View app (interestingly there is no gain setting for 
anything to do with 'light', luminosity, illuminance etc so it could be a 
mis-labelling/inconsistent labelling of the parameter in the app). If you 
have been obtaining 'radiation' data via the interceptor driver can you 
please give me some further details, it may be a case of the GW1000 
deriving a radiation value suitable for on-line weather services such as WU 
and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
it may be that there is something else available in the API that is not 
documented.

Gary

On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>
> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>
>> When running reconfigure with prompts, there are two changes, that 
>> occured in my case without asking:
>> group_pressure turns to inHg, and group_speed and group_speed2 turn to 
>> mile_per_hour 
>> and ~2 respectively.You better diff old and new version before 
>> restarting.
>>
>
> This almost certainly is an issue with wee_config and your config; the 
> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
> vague recollection that there was a previous issue that was raised (and 
> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
> will make a note to look into this.
>  
>
>> In addition, 'radiation': 'solar_radiation', is missing in default_field_map 
>> in gw1000.py. 
>>
>
> This is intentional. Unfortunately the GW1000 API has no ability to obtain 
> what in WeeWX parlance we know as field radiation (solar insolation). The 
> API can return what the API terms 'light' or luminosity in Lux as well as 
> UV index and what the API terms 'UV' in microWatts per square metre. Some 
> folks derive field radiation from luminosity though I believe the 
> relationship is somewhat complex. It's not the place for the GW1000 driver 
> to derive obs such as radiation from other obs, rather derived 
> observations should be derived by the StdWXCalculate service. Whilst the 
> StdWXCalculate service does not really lend itself at present to the 
> addition of user defined derived obs, a user can add simple derived obs by 
> adding appropriate entries under [StdCalibrate] [[Corrections]] in 
> weewx.conf, for example:
>
> [StdCalibrate]
> [[Corrections]]
> new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>
> would create the field new_obs using the (nonsense) formula shown. The 
> default GW1000 driver mapping passes the light, UV and UV index 
> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
> field UV) so they are available for use in StdCalibrate as required.
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4c8c99bb-3a88-411e-bd70-41ff4bfc6de5o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

Agreed completely :)

Gary

On Sunday, 26 July 2020 09:37:41 UTC+10, Greg Troxel wrote:
>
> gjr80 writes: 
>
> > You will notice the highlight on the word radiation (but not the word 
> > field) in my original post, this was in reference to the WeeWX field 
> named 
> > radiation, not to something known as 'field radiation'. 
>
> Sorry, reading in plain text so I did not actually notice that :-) 
>
> > I don't disagree but irrespective the GW1000 API has no ability to 
> return 
> > data that is suitable to be placed in the WeeWX field called radiation. 
> If 
>
> Sure, didn't mean to come across as questioning that as all. 
>
> > the user wishes to derive values to place in any WeeWX fields that of 
> > course is their call and whilst WeeWX has the machinery to do such 
> things 
> > it is left as an exercise for the user. 
>
> In the glorious future, there might be a stdconvert routine to create 
> radiation from illuminace, perhaps enabled with a config variable 
> becusae 1) not everybody wants it and 2) it's not really sound.  I meant 
> to be in agreement and offer pointers to further info for people looking 
> into this. 
>

-- 
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/26657fff-83ac-4d07-b396-19ea0757829do%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-25 Thread Greg Troxel

gjr80  writes:

> You will notice the highlight on the word radiation (but not the word 
> field) in my original post, this was in reference to the WeeWX field named 
> radiation, not to something known as 'field radiation'.

Sorry, reading in plain text so I did not actually notice that :-)

> I don't disagree but irrespective the GW1000 API has no ability to return 
> data that is suitable to be placed in the WeeWX field called radiation. If 

Sure, didn't mean to come across as questioning that as all.

> the user wishes to derive values to place in any WeeWX fields that of 
> course is their call and whilst WeeWX has the machinery to do such things 
> it is left as an exercise for the user.

In the glorious future, there might be a stdconvert routine to create
radiation from illuminace, perhaps enabled with a config variable
becusae 1) not everybody wants it and 2) it's not really sound.  I meant
to be in agreement and offer pointers to further info for people looking
into this.

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

On Sunday, 26 July 2020 08:55:08 UTC+10, Greg Troxel wrote:
>
> gjr80 writes: 
>
> > Some folks derive field radiation from luminosity though I believe the 
> > relationship is somewhat complex. 
>
> I'm not at all clear on what labels the various stations use. 
>
> I would use "solar irradiance" or less pedantically "solar radiation". 
> The term "field radiation" is interesting and I have not previously 
> encountered it. 
>
>
You will notice the highlight on the word radiation (but not the word 
field) in my original post, this was in reference to the WeeWX field named 
radiation, not to something known as 'field radiation'.
 

> For the arriving light per unit area, the term is Illuminance. 
> Luminosity strictly refers to total power departing a light source. 
>
> https://en.wikipedia.org/wiki/Solar_irradiance 
> https://en.wikipedia.org/wiki/Illuminance 
>
> One cannot accurately convert illuminance to irradiance, because 
> illuminance applies wavelength-based weights to power based on human 
> visual response.  So, two light sources arriiving at a surface, having 
> the same illuminance, will in general have differenrt irradiances.  But 
> people assume "sunlight" and then onc can make a reasonable 
> approximation. 
>
> My previous rant: 
>
>   https://github.com/weewx/weewx/wiki/Watts-and-lux 
>
> and something I just found that seems interesting 
>
>   
> https://ieee-dataport.org/open-access/conversion-guide-solar-irradiance-and-lux-illuminance
>  
>
>
I don't disagree but irrespective the GW1000 API has no ability to return 
data that is suitable to be placed in the WeeWX field called radiation. If 
the user wishes to derive values to place in any WeeWX fields that of 
course is their call and whilst WeeWX has the machinery to do such things 
it is left as an exercise for the user.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0ca7e6ae-39d5-4d9f-982b-6e487473a4d4o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

2020-07-25 Thread Greg Troxel

gjr80  writes:

> Some folks derive field radiation from luminosity though I believe the
> relationship is somewhat complex.

I'm not at all clear on what labels the various stations use.

I would use "solar irradiance" or less pedantically "solar radiation".
The term "field radiation" is interesting and I have not previously
encountered it.

For the arriving light per unit area, the term is Illuminance.
Luminosity strictly refers to total power departing a light source.

https://en.wikipedia.org/wiki/Solar_irradiance
https://en.wikipedia.org/wiki/Illuminance

One cannot accurately convert illuminance to irradiance, because
illuminance applies wavelength-based weights to power based on human
visual response.  So, two light sources arriiving at a surface, having
the same illuminance, will in general have differenrt irradiances.  But
people assume "sunlight" and then onc can make a reasonable
approximation.

My previous rant:

  https://github.com/weewx/weewx/wiki/Watts-and-lux

and something I just found that seems interesting

https://ieee-dataport.org/open-access/conversion-guide-solar-irradiance-and-lux-illuminance

> It's not the place for the GW1000 driver to derive obs such as
> radiation from other obs, rather derived observations should be
> derived by the StdWXCalculate service.

Agreed.

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

Re: [weewx-user] Re: New GW1000 Driver available for testing

I am not sure if this impacts on the WH65 issue mentioned below but I now 
have the driver distinguishing whether there is a WH65 or WH24 connected to 
the GW1000. This will (I hope) have a flow on affect on battery status 
fields but given the manner in which the API works I don't believe it will 
impact any weather related observations. I should have b6 in the next 
couple of days.

Gary
On Saturday, 25 July 2020 04:50:38 UTC+10, steeple ian wrote:
>
> That’s exactly what I am seeing. I am going to look at the interceptor map 
> for WH65 and see where things appear to deviate.
>
> On Fri, 24 Jul 2020 at 19:43, Bill Arthur  wrote:
>
>> I started as you and later added a WiFi-less console.  I'm not sure where 
>> to look for the WH65 designation. 
>> No, I didn't change the map. I was unable to run the driver directly to 
>> test, so I just launched it blindly... and it worked.
>> I am seeing an anomaly with pressure, too. I'm looking at the output as 
>> reported to CWOP. I'm seeing 989mb where I expect 1019mb
>> So...I have some work to do.
>> On Friday, July 24, 2020 at 1:28:27 PM UTC-5 steep...@gmail.com wrote:
>>
>>> That is the same array that I am using with gw1000 except I do not have 
>>> a console. Does this show up as WH65? I have anomaly with the barometer but 
>>> I cannot understand why. Have you changed the sensor map at all?
>>>
>>>
>>> On Fri, 24 Jul 2020 at 19:17, Bill Arthur  wrote:
>>>
 Hi Ian,
 I have the Ambient Weather WS-2902 array:  temperature, rainfall, 
 humidity, wind speed & direction, UV and solar.  Indoor and pressure is 
 from the GW-1000

 On Friday, July 24, 2020 at 1:07:41 PM UTC-5 steep...@gmail.com wrote:

> Hi Bill,
> What sensors do you have connected?
>
> On Fri, 24 Jul 2020 at 19:06, Bill Arthur  wrote:
>
>> Ian,
>> Yes, just the simple Seasons skin for now. I now have 12 hours of 
>> data and it's looking good. 
>> I've compared it to my weather station console and the data all looks 
>> correct.
>>
>> On Friday, July 24, 2020 at 12:56:01 PM UTC-5 steep...@gmail.com 
>> wrote:
>>
>>> Hi Bill,
>>> No need to be sorry. Just wanted to exchange notes on experiences. I 
>>> assume you then using the default Seasons skin. How is that looking?
>>> Ian
>>>
>>> On Fri, 24 Jul 2020 at 18:12, Bill Arthur  wrote:
>>>
 Hi Ian
 No, I don't have Weather34 on the RasPi that I'm testing the GW1000 
 extension, it's a fresh install.
 It'll be a while until I'm ready to modify the RasPi that has 
 Weather34. Sorry.

 On Friday, July 24, 2020 at 10:09:08 AM UTC-5 steep...@gmail.com 
 wrote:

> Hi Bill,
>
> Are you still using the Weather34 skin. If so, I am interested 
> what barometer reading you are displaying when using the gw1000 
> driver.
>
> Thanks,
> Ian 
>
>
> On Friday, July 24, 2020 at 4:02:17 AM UTC+1, Bill Arthur wrote:
>>
>> I couldn't get it to run from the command line.
>> When I  did   python -m user.gw1000 --help
>> I get   /usr/bin/python: No module named user.gw1000
>>
>> But I have it up and running, everything looks good on my Seasons 
>> page.
>> I'll give the data a closer look tomorrow.
>>
>> But I'm scratching my head trying to find how to specify the IP 
>> address in weewx.conf
>> I have three GW1000s here, I have no idea which one is being 
>> used  
>> On Thursday, July 23, 2020 at 9:06:47 PM UTC-5 Bill Arthur wrote:
>>
>>> This link works: 
>>> https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/gw1000-0.1.0b4.tar.gz
>>>
>>> On Thursday, July 23, 2020 at 8:57:49 PM UTC-5 Bill Arthur wrote:
>>>
 FYI:
 wget -P /var/tmp 
 https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/weewx-gw1000-0.1.0b4.tar.gz
  
 gives me an Error 404 

>>>

-- 
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/4297800f-cd83-414a-aa3a-9e395c9f599co%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing