from:"Paul Ward"

[weewx-user] Re: GW-1000 API battery reading issues with GW1000 V1.6.6

2021-03-15 Thread Paul Ward

Ah Gary I now realise this is a known change in the API for v1.6.6... Happy 
to beta test any updated driver s/w on my setup if you want, let me know... 
Not the end of the world as the Ecowitt.net sees the levels anyway 
correctly.

On Monday, March 15, 2021 at 8:09:34 PM UTC Paul Ward wrote:

> Hi @gjr80 I think I have a problem with the battery level extraction since 
> the GW1000 updated firmware to V1.6.6... Everything was working fine 
> beforehand and I can see the battery levels in the Weewx loop data and use 
> it downstream.
>
> Since V1.6.6 the battery statuses seem to have vanished from the Weewx 
> loop data. So I checked API output. Here is the output below of running the 
> driver directly. Battery levels seems to have gone. I'm running API 
> v.0.2.0. I've double checked I'm using the latest Accumulator stanza just 
> in case.
>
> I'm pretty sure it's something in the API workings or what the GW1000 is / 
> is not exposing via the API, because the battery level are coming through 
> fine to (a) Ecowitt.net and (b) my other data recording via the Customer 
> Server push route. I can see (b) reports the battery data as I'm using the 
> FOSHKplugin and interrogate that output, and the battery info is there.
>
> "Using configuration file /etc/weewx/weewx.conf
>
>  Interrogating GW1000 at x.x.x.x:45000
>
>  2021-03-15 19:54:15 GMT (1615838055): UV: 0, co2: 721, co2_24h_avg: 683, 
> dateTime: 1615838055, dayRain: 4.0, daymaxwind: 9.7, extraHumid1: 57, 
> extraHumid17: 53, extraHumid2: 75, extraTemp1: 17.9, extraTemp17: 18.9, 
> extraTemp2: 11.3, inHumidity: 45, inTemp: 21.8, lightning_distance: None, 
> lightning_last_det_time: None, lightning_strike_count: None, luminosity: 
> 0.0, monthRain: 24.0, outHumidity: 84, outTemp: 7.5, pm10: 3.3, 
> pm10_24h_avg: 3.2, pm2_5: 21.0, pm2_51_24h_avg: 24.3, pm2_55: 3.3, 
> pm2_55_24h_avg: 2.6, pressure: 1010.3, rain: None, rainRate: 0.0, 
> relbarometer: 1012.6, soilMoist1: 47, stormRain: 4.0, usUnits: 17, 
> uvradiation: 0.0, weekRain: 5.3, wh26_sig: 4, wh31_ch1_sig: 4, 
> wh31_ch2_sig: 4, wh40_sig: 3, wh41_ch1_sig: 4, wh51_ch1_sig: 4, wh57_sig: 
> 4, wh68_sig: 4, windDir: 279, windGust: 1.0, windSpeed: 0.5, yearRain: 
> 102.6"
>

-- 
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/872b12bf-dc77-48af-b958-755c697f39dbn%40googlegroups.com.

[weewx-user] GW-1000 API battery reading issues with GW1000 V1.6.6

2021-03-15 Thread Paul Ward

Hi @gjr80 I think I have a problem with the battery level extraction since 
the GW1000 updated firmware to V1.6.6... Everything was working fine 
beforehand and I can see the battery levels in the Weewx loop data and use 
it downstream.

Since V1.6.6 the battery statuses seem to have vanished from the Weewx loop 
data. So I checked API output. Here is the output below of running the 
driver directly. Battery levels seems to have gone. I'm running API 
v.0.2.0. I've double checked I'm using the latest Accumulator stanza just 
in case.

I'm pretty sure it's something in the API workings or what the GW1000 is / 
is not exposing via the API, because the battery level are coming through 
fine to (a) Ecowitt.net and (b) my other data recording via the Customer 
Server push route. I can see (b) reports the battery data as I'm using the 
FOSHKplugin and interrogate that output, and the battery info is there.

"Using configuration file /etc/weewx/weewx.conf

 Interrogating GW1000 at x.x.x.x:45000

 2021-03-15 19:54:15 GMT (1615838055): UV: 0, co2: 721, co2_24h_avg: 683, 
dateTime: 1615838055, dayRain: 4.0, daymaxwind: 9.7, extraHumid1: 57, 
extraHumid17: 53, extraHumid2: 75, extraTemp1: 17.9, extraTemp17: 18.9, 
extraTemp2: 11.3, inHumidity: 45, inTemp: 21.8, lightning_distance: None, 
lightning_last_det_time: None, lightning_strike_count: None, luminosity: 
0.0, monthRain: 24.0, outHumidity: 84, outTemp: 7.5, pm10: 3.3, 
pm10_24h_avg: 3.2, pm2_5: 21.0, pm2_51_24h_avg: 24.3, pm2_55: 3.3, 
pm2_55_24h_avg: 2.6, pressure: 1010.3, rain: None, rainRate: 0.0, 
relbarometer: 1012.6, soilMoist1: 47, stormRain: 4.0, usUnits: 17, 
uvradiation: 0.0, weekRain: 5.3, wh26_sig: 4, wh31_ch1_sig: 4, 
wh31_ch2_sig: 4, wh40_sig: 3, wh41_ch1_sig: 4, wh51_ch1_sig: 4, wh57_sig: 
4, wh68_sig: 4, windDir: 279, windGust: 1.0, windSpeed: 0.5, yearRain: 
102.6"

-- 
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/2614d04f-2a9d-4f18-9d63-4942264cd102n%40googlegroups.com.

[weewx-user] GW1000 poll interval settings / limitations

2021-01-20 Thread Paul Ward

Question about shortening the poll interval an implications /
recommendations...
My setup is I’ve got 2x GW1000’s both reading lots of “shared” sensors but
one reading at WS80 and one reading a WS68. I then have 2x Raspberry Pi’s
concurrently, both running the API in driver mode and receiving data from
each GW1000 separately into separate Weewx 4 DBs on each Pi.

My objective is to ensure that all the wind sensor’s data at the reporting
frequency it is produced (I mean seconds, not MHz) is captured and loaded
into weewx, so that it can get the statistics correct for max/mean etc over
the standard 5 min report periods. Otherwise AFAIK some sensor dat is lost
as the GW1000’s only make available the latest sensor data readings to own
stream services, if the frequency of that push/pull is lower than the
sensor frequency (see https://www.wxforum.net/index.php?topic=41201.0).

So... I was planning to set the poll_interval of the API pointing at the
“WS80’s GW1000” to say 4s or 5s (WS80 updates every 4.8s), and the “WS68’s
GW1000” to 16s (WS68 updates every 16.5s).

I could not see any restrictions on doing this in the wiki/docs, but I was
potentially concerned in overloading the servers particularly the GW1000’s.
I was wondering
- if this is feasible (e.g. no lower limit?),
- if you have tested this at higher frequencies, and
- if you have any recommendations on doing this or not, or other settings
changes with higher frequencies? E.g. socket_timeout, max_tries, retry_wait
(all which I was planning on leaving as-is)

Thanks!

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

[weewx-user] Re: GW1000 driver v0.2.0 release

2021-01-18 Thread Paul Ward

I've just got my WH45 and its working great with new driver thanks Gary. 
I've noticed that the CO2 internal temp & humidity are coming through as 
the curiously named "extraTemp17" and "extraHumid17" does that sound right? 
Also FYI at some point wiki sensor map page will need updating :-)

On Saturday, January 9, 2021 at 11:47:59 AM UTC gjr80 wrote:

> I have released v0.2.0 on GitHub 
> . 
>
> This main feature of this release is support for the WH45 Indoor CO2 PM2.5 
> PM10 Temperature and Humidity 5-in-1 Air Quality Sensor. If you have a WH45 
> sensor and it has been linked to your GW1000 v0.2.0 of the driver should 
> automatically pick up and emit the WH45 sensor data.
>
> v0.2.0 also sees changes in the naming of the 24 hour average particulate 
> concentration fields. Unfortunately this will mean anyone that is using 
> these fields will need to make one or more changes to their WeeWX 
> installation. I have outlined the changes and which users need to make 
> changes and how to make the necessary changes in a wiki article Changes 
> to 24 hour average particulate concentration field names 
> .
>  
> If you have a WH41, WH43 or WH45 sensor and use the 24 hour average 
> particulate concentration fields in any way I strongly suggest you 
> thoroughly read the linked wiki article.
>
> The majority of the other changes in v0.2.0 relate to running the driver 
> directly, in particular displaying the GW1000 and sensor configuration 
> information currently only available through the WS View app.
>
> Those that installed v0.1.0 via wee_extension can upgrade to v0.2.0 as 
> follows:
>
> $ wget -P /var/tmp 
> https://github.com/gjr80/weewx-gw1000/releases/download/v0.2.0/gw1000-0.2.0.tar.gz
> $ wee_extension --install=/var/tmp/gw1000-0.2.0.tar.gz
>
> Note: wee_extension may require the use of sudo the path to wee_extension 
> as applicable.
>
> 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/6a98ac83-e73a-46b2-8154-44fcf565cc9fn%40googlegroups.com.

Re: [weewx-user] Re: weewx crashed - issue with gw1000.py when Ecowitt WH45 5-in-1 combo sensor gets activated (5= T+PM2.5+PM10) [2b]

2021-01-01 Thread Paul Ward

Gary I have a WH45 on order so subject to shipping delays I’m happy to test 
the code too in couple of weeks when I get it, if you don’t release 
beforehand.

On Friday, January 1, 2021 at 1:26:45 AM UTC gjr80 wrote:

> WH45 support was coded some time ago though of course not tested with an 
> actual device. Have had a number of other features I was working on to add 
> at the same time which delayed release of the WH45 compatible version of 
> the driver. Rainer now has a copy of a compatible version of the driver to 
> test and once he confirms it works I will shortly afterwards release the 
> WH45 compatible version.
>
> As an aside, and on a technical note, this did highlight that I need to 
> change the approach the driver uses to dealing with sensor data from the 
> GW1000. Ideally adding an new sensor type should not cause a driver that 
> does not know about that new sensor type to crash; rather the driver should 
> continue to operate but just not provide data for the (to it) unknown 
> sensor. This will be something to work on for the next version of the 
> driver, fortunately Ecowitt is not releasing new sensors that often.
>
> 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/afcd4401-6b46-421f-a25c-e74aa235e870n%40googlegroups.com.

Re: [weewx-user] GW1000 output and database

2021-01-01 Thread Paul Ward

Thanks Gary and others on this thread - I'm using the GW1000 API driver 
mode and have re-purposed one of my internal multi-channel WH31 sensors for 
main outdoor temp/humidity use temporarily (whilst I await return of WS80). 
Very simple once I'd figured out I needed to use the 
[[field_map_extensions]] and get the correct field names from the driver 
output. Is it documented somewhere what the entire list of fields your API 
driver/service can handle is and default mapping into weewx? I couldn't see 
a link in the GitHub notes.

On Tuesday, August 25, 2020 at 8:27:19 AM UTC+1 gjr80 wrote:

> Actually, looking at the code I can see that timestamps of the GW1000 data 
> are handled differently when operated as a driver and as a service. In this 
> case adding dateTime = datetime to [[field_map]] will get things 
> operating as expected. 
>
> I need to revisit the handling of GW1000 data timestamps, the need for 
> dateTime 
> = datetime may or may not be the final solution. Either way the final 
> version will be backwards compatible with a dateTime = datetime entry in 
> the field map.This issue has also highlighted the need for some better 
> debug output around the processing of loop packets.
>
> Gary
> On Tuesday, 25 August 2020 at 16:34:25 UTC+10 graha...@gmail.com wrote:
>
>> add ‘dateTime = datetime’ back to field_map.
>> worth a go while gary works on it
>>
>> On 25 Aug 2020, at 8:37 am, Timothy Buchanan  
>> wrote:
>>
>> How would I add dateTime to the field_map?
>>
>> On Monday, August 24, 2020 at 9:59:17 AM UTC-6 graha...@gmail.com wrote:
>>
>>> try adding ‘dateTime’ to the field_map. i think augmentations are 
>>> skipped (gw1000 fields are not added) because on its absence the service 
>>> assumes the offered data is infinitely old
>>>
>>> On 25 Aug 2020, at 12:47 am, Graham Eddy  wrote:
>>>
>>> it will be interesting to see what gary concludes.
>>> it looks to me like the fields are correctly identified and mapped (i 
>>> presume; the data is there but i don't see the mapped result) but not 
>>> inserted into packet by augmentation. one reason for not inserting the data 
>>> would be if it is stale - do the timestamps of the weatherflowudp driver 
>>> (datetime in packet) line up with the gw1000 service (datetime in 
>>> mapped_data) within age toleration?
>>>
>>> On 24 Aug 2020, at 11:48 pm, Timothy Buchanan  
>>> wrote:
>>>
>>> field_map used with debug 3.
>>>
>>> On Sunday, August 23, 2020 at 6:07:35 PM UTC-6 gjr80 wrote:
>>>
 Thanks, from the log it looks like the GW1000 service thread has 
 silently died (which it shouldn't, it should die loudly if it dies!). 
 Let's 
 step the debug level up, leaving everything else as it is edit 
 weewx.conf and set debug = 3, save weewx.conf and restart WeeWX. Let 
 WeeWX run for about five minutes and again take a log extract from when 
 you 
 just started WeeWX. Post the log here.

 Gary

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

> debug=2 GW options so (pasted):
>
> # Options for extension 'GW1000'
> [GW1000]
> driver = user.gw1000
> [[field_map]]
> extraTemp2 = intemp
> extraHumid2 = inhumid
> extraTemp1 = temp1
> extraHumid1 = humid1
> soilMoist1 = soilmoist1
>

>>>
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/fb279140-dd76-4767-92b8-1cdb780a2e30n%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/1d8e0e25-8ec2-4090-a0fd-acd35659aa30n%40googlegroups.com.

Re: [weewx-user] ecowitt extra sensor data parameters

2020-10-07 Thread Paul Ward

Do you think that would work even direct from the HP2551? If I'd understood 
it right the GW1000 driver uses an API that the consoles don't support 
directly but the GW1000 does.

On Wednesday, October 7, 2020 at 5:52:33 AM UTC+1 ti...@skybase.net wrote:

> Hi Paul,
>
> You could try swapping from the Interceptor plugin to the GW1000 driver 
> which captures more of the data than the Interceptor does rather than 
> trying to modify things to fit.
>
> https://github.com/gjr80/weewx-gw1000
>
> cheers
>
> Tim
> On 7/10/20 9:57 am, Paul Ward wrote:
>
> HI forum! I'm running 4.1.1 on a Pi connecting directly to a HP2551 with 
> sensors of WS80 ultrasonic, WH40 rain, WH31 indoor, WH41 pm2.5 AQ, WH51 
> soil, WH57 lightning (from Froggit in UK). It's using weewx-interceptor in 
> ecowitt-client mode, default config. It seems to find most of the sensors 
> but it's not recognising the lighting detector os some of the battery info. 
> Does anyone know how I can add this, do I need to modify the interceptor 
> and/or weewx.conf somehow? Also where can I find to display all the extra 
> sensor data? I'm new to the weewx infrastructure but proficient in 
> unix/code in general. Have read basics in wiki. Thank you! Paul 
>
> /var/log/syslog entries below, only these, repeated:
>
> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
> unrecognized parameter wh40batt=1.6
> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
> unrecognized parameter lightning_time=
> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
> unrecognized parameter wh80batt=3.28
> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
> unrecognized parameter lightning_num=0
> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
> unrecognized parameter wh57batt=5
> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
> unrecognized parameter lightning=
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/7ceefed8-5aa4-4d51-be21-3b03bb256522n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/7ceefed8-5aa4-4d51-be21-3b03bb256522n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/3261017b-4d22-455a-945d-c43f5b98744en%40googlegroups.com.

[weewx-user] Re: ecowitt extra sensor data parameters

2020-10-07 Thread Paul Ward

Ah no thanks - dunno why that didn't pop up in a search - thanks I'll look 
into it

On Wednesday, October 7, 2020 at 5:13:57 AM UTC+1 gert.a...@gmail.com wrote:

> Hi
>
> Have You seen this 
> 
> ?
>
> Gert
> On Wednesday, October 7, 2020 at 12:57:53 AM UTC+2 ward...@gmail.com 
> wrote:
>
>> HI forum! I'm running 4.1.1 on a Pi connecting directly to a HP2551 with 
>> sensors of WS80 ultrasonic, WH40 rain, WH31 indoor, WH41 pm2.5 AQ, WH51 
>> soil, WH57 lightning (from Froggit in UK). It's using weewx-interceptor in 
>> ecowitt-client mode, default config. It seems to find most of the sensors 
>> but it's not recognising the lighting detector os some of the battery info. 
>> Does anyone know how I can add this, do I need to modify the interceptor 
>> and/or weewx.conf somehow? Also where can I find to display all the extra 
>> sensor data? I'm new to the weewx infrastructure but proficient in 
>> unix/code in general. Have read basics in wiki. Thank you! Paul
>>
>> /var/log/syslog entries below, only these, repeated:
>>
>> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
>> unrecognized parameter wh40batt=1.6
>> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
>> unrecognized parameter lightning_time=
>> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
>> unrecognized parameter wh80batt=3.28
>> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
>> unrecognized parameter lightning_num=0
>> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
>> unrecognized parameter wh57batt=5
>> Oct  6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: 
>> unrecognized parameter lightning=
>>
>>

-- 
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/991e160f-50c6-4ed3-8542-71d287706943n%40googlegroups.com.

[weewx-user] ecowitt extra sensor data parameters

2020-10-06 Thread Paul Ward

HI forum! I'm running 4.1.1 on a Pi connecting directly to a HP2551 with
sensors of WS80 ultrasonic, WH40 rain, WH31 indoor, WH41 pm2.5 AQ, WH51
soil, WH57 lightning (from Froggit in UK). It's using weewx-interceptor in
ecowitt-client mode, default config. It seems to find most of the sensors
but it's not recognising the lighting detector os some of the battery info.
Does anyone know how I can add this, do I need to modify the interceptor
and/or weewx.conf somehow? Also where can I find to display all the extra
sensor data? I'm new to the weewx infrastructure but proficient in
unix/code in general. Have read basics in wiki. Thank you! Paul

/var/log/syslog entries below, only these, repeated:

Oct 6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: unrecognized
parameter wh40batt=1.6
Oct 6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: unrecognized
parameter lightning_time=
Oct 6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: unrecognized
parameter wh80batt=3.28
Oct 6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: unrecognized
parameter lightning_num=0
Oct 6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: unrecognized
parameter wh57batt=5
Oct 6 23:31:43 blueberrypi weewx[2710] INFO user.interceptor: unrecognized
parameter lightning=

--
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/7ceefed8-5aa4-4d51-be21-3b03bb256522n%40googlegroups.com.

Re: [weewx-user] How to display pm2.5 & lightning graphs?