[weewx-development] Re: GW1000 driver

2020-07-23 Thread George Alfert
For remote WeeWX server I recommend using the GW1000 Ecowitt upload 
protocol "Customized" server upload feature and the WeeWX Interceptor 
driver configured for ecowitt-client.

On Thursday, July 23, 2020 at 2:27:11 PM UTC-4, George Alfert wrote:
>
> I just tested a remote WAN connection using the GW1000 API. It works! You 
> can open and forward TCP port 45000 and then you should be able to point 
> the WeeWX GW1000 API driver to your WAN IP address. I'm still not sure I 
> would recommend this even though it works. You are essentially opening up 
> your GW1000 to the outside world. Hackers could find and mess with your 
> GW1000, or change your GW1000 settings and calibration or factory reset 
> itetc. I would still just recommend a site to site VPN.
>
> Realize that this test that I performed was not with WeeWX and the new 
> GW1000 API driver. The test that I performed was a raw test using my 
> knowledge of the API and how it works. To test I did the following; opened 
> and forwarded the correct port on my cable service firewall, I then put my 
> laptop on a different Internet service (cellular network hotspot). I then 
> initiated a terminal connection using the API protocol and I got live data 
> while my laptop was on the Internet using cellular hotspot.
>
>
> On Thursday, July 23, 2020 at 2:09:26 PM UTC-4, George Alfert wrote:
>>
>> I have not tested to see if the GW1000 API will work across a WAN 
>> connection if you open ports. It might workbut this would not work to 
>> manage it via WS View. The WS View requires that both devices be local on 
>> the same LAN. I still would not recommend to open up your firewall to 
>> enable this API over WAN. You invite who knows what to also have at your 
>> GW1000 and it might not be hardened for this type of installation. I just 
>> wouldn't trust it. What you could do is create a site to site VPN tunnel if 
>> you needed the WeeWX to be at a remote location.
>>
>> On Thursday, July 23, 2020 at 1:21:30 PM UTC-4, Gert Andersen wrote:
>>>
>>> Hi George
>>>
>>> Thanks for your answer.
>>>
>>> Does this imply that the GW1000 and WeeWx is on the same network?
>>>
>>> My configuration is GW1000 local and WeeWx running remote. Can this 
>>> configuration work? You mention that the API should know the IP address, 
>>> but the ip address of the GW1000 is local(192.168.xxx.xxx) and can't be  
>>> seen from outside.
>>>
>>> Gert
>>>
>>> On Thursday, July 23, 2020 at 6:55:45 PM UTC+2, George Alfert wrote:

 Gert,
 "How do I set up Ecowitt WsView to send information to the GW1000 
 driver?"
 answer- you don't do anything in WS View. The beauty of the GW1000 API 
 driver is that all the magic happens in the API driver. The API driver 
 just 
 needs to know the IP address of your GW1000 and that is it. The GW1000 
 does 
 not need to be configured to send data anywhere. The function of the API 
 is 
 for the API driver to hit the GW1000 via its IP address and speak directly 
 to the GW1000 and basically say to the GW1000, "Hey, send me data" and the 
 GW1000 takes note of where the request came from and it responds. This is 
 what allows applications that speak with the API to all run 
 simultaneously. 
 I currently have one GW1000 and several different applications use the API 
 to all talk to the GW1000 at the same time having not done a thing on the 
 GW1000 side.




 On Thursday, July 23, 2020 at 12:39:44 PM UTC-4, Gert Andersen wrote:
>
> Hi Gary
>
> I have installed Interceptor for Ecowitt client and it has worked 
> fine. However, there have been minor issues with new sensors from 
> Ecowitt. 
> I am therefore interested in trying the new extension.
>
> I therefore have a few questions:
> How do I set up Ecowitt WsView to send information to the GW1000 
> driver?
> Should WsView send to a port? Is the driver listening to a port?
> Is the Ecowitt passkey implemented?
>
> Many thanks for this initiative.
>
> Gert
>
> On Tuesday, July 21, 2020 at 4:50:23 AM UTC+2, gjr80 wrote:
>>
>> I have developed an API based driver for the Ecowitt GW1000 WiFi 
>> Gateway. So what? Well the current means of receiving data from the 
>> GW1000 
>> involves the GW1000 pushing data that is then parsed/processed by the 
>> interceptor driver and loop packets emitted. This API based driver uses 
>> a 
>> pull methodology where the GW1000 API is polled at a user specified 
>> interval and the API response is then used to generate loop packets. Use 
>> of 
>> the API also gives access to sensor battery data and allows some 
>> interrogation of the GW1000/sensor state.
>>
>> I have developed the driver without direct access to the API so I am 
>> sure there will be some issues with it, most likely to do with 
>> device/sensor state info and 

[weewx-development] Re: GW1000 driver

2020-07-23 Thread George Alfert
I just tested a remote WAN connection using the GW1000 API. It works! You 
can open and forward TCP port 45000 and then you should be able to point 
the WeeWX GW1000 API driver to your WAN IP address. I'm still not sure I 
would recommend this even though it works. You are essentially opening up 
your GW1000 to the outside world. Hackers could find and mess with your 
GW1000, or change your GW1000 settings and calibration or factory reset 
itetc. I would still just recommend a site to site VPN.

Realize that this test that I performed was not with WeeWX and the new 
GW1000 API driver. The test that I performed was a raw test using my 
knowledge of the API and how it works. To test I did the following; opened 
and forwarded the correct port on my cable service firewall, I then put my 
laptop on a different Internet service (cellular network hotspot). I then 
initiated a terminal connection using the API protocol and I got live data 
while my laptop was on the Internet using cellular hotspot.


On Thursday, July 23, 2020 at 2:09:26 PM UTC-4, George Alfert wrote:
>
> I have not tested to see if the GW1000 API will work across a WAN 
> connection if you open ports. It might workbut this would not work to 
> manage it via WS View. The WS View requires that both devices be local on 
> the same LAN. I still would not recommend to open up your firewall to 
> enable this API over WAN. You invite who knows what to also have at your 
> GW1000 and it might not be hardened for this type of installation. I just 
> wouldn't trust it. What you could do is create a site to site VPN tunnel if 
> you needed the WeeWX to be at a remote location.
>
> On Thursday, July 23, 2020 at 1:21:30 PM UTC-4, Gert Andersen wrote:
>>
>> Hi George
>>
>> Thanks for your answer.
>>
>> Does this imply that the GW1000 and WeeWx is on the same network?
>>
>> My configuration is GW1000 local and WeeWx running remote. Can this 
>> configuration work? You mention that the API should know the IP address, 
>> but the ip address of the GW1000 is local(192.168.xxx.xxx) and can't be  
>> seen from outside.
>>
>> Gert
>>
>> On Thursday, July 23, 2020 at 6:55:45 PM UTC+2, George Alfert wrote:
>>>
>>> Gert,
>>> "How do I set up Ecowitt WsView to send information to the GW1000 
>>> driver?"
>>> answer- you don't do anything in WS View. The beauty of the GW1000 API 
>>> driver is that all the magic happens in the API driver. The API driver just 
>>> needs to know the IP address of your GW1000 and that is it. The GW1000 does 
>>> not need to be configured to send data anywhere. The function of the API is 
>>> for the API driver to hit the GW1000 via its IP address and speak directly 
>>> to the GW1000 and basically say to the GW1000, "Hey, send me data" and the 
>>> GW1000 takes note of where the request came from and it responds. This is 
>>> what allows applications that speak with the API to all run simultaneously. 
>>> I currently have one GW1000 and several different applications use the API 
>>> to all talk to the GW1000 at the same time having not done a thing on the 
>>> GW1000 side.
>>>
>>>
>>>
>>>
>>> On Thursday, July 23, 2020 at 12:39:44 PM UTC-4, Gert Andersen wrote:

 Hi Gary

 I have installed Interceptor for Ecowitt client and it has worked fine. 
 However, there have been minor issues with new sensors from Ecowitt. I am 
 therefore interested in trying the new extension.

 I therefore have a few questions:
 How do I set up Ecowitt WsView to send information to the GW1000 driver?
 Should WsView send to a port? Is the driver listening to a port?
 Is the Ecowitt passkey implemented?

 Many thanks for this initiative.

 Gert

 On Tuesday, July 21, 2020 at 4:50:23 AM UTC+2, gjr80 wrote:
>
> I have developed an API based driver for the Ecowitt GW1000 WiFi 
> Gateway. So what? Well the current means of receiving data from the 
> GW1000 
> involves the GW1000 pushing data that is then parsed/processed by the 
> interceptor driver and loop packets emitted. This API based driver uses a 
> pull methodology where the GW1000 API is polled at a user specified 
> interval and the API response is then used to generate loop packets. Use 
> of 
> the API also gives access to sensor battery data and allows some 
> interrogation of the GW1000/sensor state.
>
> I have developed the driver without direct access to the API so I am 
> sure there will be some issues with it, most likely to do with 
> device/sensor state info and possibly sensors I don't have access to. I 
> have tested it against GW1000/WH31/WH32/WH41/WH51/WH57 sensors. The 
> driver 
> can be operated as a traditional WeeWX driver that emits loop packets but 
> can also be operated as a WeeWX service that augments loop packets with 
> GW1000 data. The driver will operate under WeeWX 4.x python 2 and 3 and 
> under WeeWX 3.9.x (probably some 

[weewx-development] Re: GW1000 driver

2020-07-23 Thread George Alfert
I have not tested to see if the GW1000 API will work across a WAN 
connection if you open ports. It might workbut this would not work to 
manage it via WS View. The WS View requires that both devices be local on 
the same LAN. I still would not recommend to open up your firewall to 
enable this API over WAN. You invite who knows what to also have at your 
GW1000 and it might not be hardened for this type of installation. I just 
wouldn't trust it. What you could do is create a site to site VPN tunnel if 
you needed the WeeWX to be at a remote location.

On Thursday, July 23, 2020 at 1:21:30 PM UTC-4, Gert Andersen wrote:
>
> Hi George
>
> Thanks for your answer.
>
> Does this imply that the GW1000 and WeeWx is on the same network?
>
> My configuration is GW1000 local and WeeWx running remote. Can this 
> configuration work? You mention that the API should know the IP address, 
> but the ip address of the GW1000 is local(192.168.xxx.xxx) and can't be  
> seen from outside.
>
> Gert
>
> On Thursday, July 23, 2020 at 6:55:45 PM UTC+2, George Alfert wrote:
>>
>> Gert,
>> "How do I set up Ecowitt WsView to send information to the GW1000 driver?"
>> answer- you don't do anything in WS View. The beauty of the GW1000 API 
>> driver is that all the magic happens in the API driver. The API driver just 
>> needs to know the IP address of your GW1000 and that is it. The GW1000 does 
>> not need to be configured to send data anywhere. The function of the API is 
>> for the API driver to hit the GW1000 via its IP address and speak directly 
>> to the GW1000 and basically say to the GW1000, "Hey, send me data" and the 
>> GW1000 takes note of where the request came from and it responds. This is 
>> what allows applications that speak with the API to all run simultaneously. 
>> I currently have one GW1000 and several different applications use the API 
>> to all talk to the GW1000 at the same time having not done a thing on the 
>> GW1000 side.
>>
>>
>>
>>
>> On Thursday, July 23, 2020 at 12:39:44 PM UTC-4, Gert Andersen wrote:
>>>
>>> Hi Gary
>>>
>>> I have installed Interceptor for Ecowitt client and it has worked fine. 
>>> However, there have been minor issues with new sensors from Ecowitt. I am 
>>> therefore interested in trying the new extension.
>>>
>>> I therefore have a few questions:
>>> How do I set up Ecowitt WsView to send information to the GW1000 driver?
>>> Should WsView send to a port? Is the driver listening to a port?
>>> Is the Ecowitt passkey implemented?
>>>
>>> Many thanks for this initiative.
>>>
>>> Gert
>>>
>>> On Tuesday, July 21, 2020 at 4:50:23 AM UTC+2, gjr80 wrote:

 I have developed an API based driver for the Ecowitt GW1000 WiFi 
 Gateway. So what? Well the current means of receiving data from the GW1000 
 involves the GW1000 pushing data that is then parsed/processed by the 
 interceptor driver and loop packets emitted. This API based driver uses a 
 pull methodology where the GW1000 API is polled at a user specified 
 interval and the API response is then used to generate loop packets. Use 
 of 
 the API also gives access to sensor battery data and allows some 
 interrogation of the GW1000/sensor state.

 I have developed the driver without direct access to the API so I am 
 sure there will be some issues with it, most likely to do with 
 device/sensor state info and possibly sensors I don't have access to. I 
 have tested it against GW1000/WH31/WH32/WH41/WH51/WH57 sensors. The driver 
 can be operated as a traditional WeeWX driver that emits loop packets but 
 can also be operated as a WeeWX service that augments loop packets with 
 GW1000 data. The driver will operate under WeeWX 4.x python 2 and 3 and 
 under WeeWX 3.9.x (probably some earlier 3.x versions as well).

 The driver can be found on GitHub 
  and can be downloaded as an 
 extension package from the releases tab 
 . Installation and 
 configuration is covered in the readme on the GitHub site or as included 
 in 
 the package as well as in the up front comments in the driver file 
 gw1000.py. The driver can be run directly without the overheads of a 
 running instance of WeeWX (WeeWX must be installed though). You can also 
 run the driver directly while WeeWX continues to operate without 
 interfering with the running WeeWX instance.

 I would welcome anyone who wants to try the driver. If you do want to 
 try it I would recommend installing the driver extension package or just 
 the driver file (gw1000.py), and then running the driver directly with 
 the various command line options (I would not reconfigure WeeWX to use the 
 driver until you have confirmed it configured and operating as expected). 
 Once gw1000.py is in the user directory (/home/weewx/bin/user or 
 

Re: [weewx-development] Re: GW1000 driver

2020-07-23 Thread George Alfert
Initial configuration of the GW1000 requires a mobile device to get it 
connected to WiFi and to set other things up like WU, calibration...etc. 
You'll also want to do regular firmware updates. This requires a mobile 
device running Android or iOS. You install and run the WS View app from 
Fine Offset/Ecowitt to do this. This is required.

You can't get data via a browser directly from the GW1000. The GW1000 will 
upload to various services; Ecowitt.net, WU...etc. Then you can use a 
browser to pull up those sites to see your weather data.

The GW1000 will need to talk to the Internet to synchronize its clock. I 
don't recommend using a GW1000 without Internet access. You'll need 
Internet access to do firmware updates also.

Yes, all GW1000 support this local network API. This local network API is 
only a feature on the GW1000the other display consoles like HP2551-C, 
WH2910 ...etc...do not have this API.


On Thursday, July 23, 2020 at 1:05:53 PM UTC-4, Greg Troxel wrote:
>
> George Alfert > writes: 
>
> > I think what people should realize is that there are 3 methods to get 
> data 
> > from the GW1000. 
> > 
> > 1. Customized server upload WU protocol 
> > 2. Customized server upload Ecowitt protocol (this is not the same as 
> API) 
> > 3. GW1000 API (nothing needs configuring in WS View) 
>
> Do you mean that I can, without running any ecowitt software on any kind 
> of phone, perhaps using a web browser 
>
>   - buy a GW1000 and plug it in 
>   - configure it to my wifi (how?) 
> including firewall config so it can't talk to the internet 
>   - (pair it to listen to a soil moisture sensor, if necessary) 
>   - run the new weewx code and get data 
>
> ? 
>
> Do all shipping GW1000 units support the API? 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/1bddf2b1-ff42-4246-a6b8-a2f2add7c7d2o%40googlegroups.com.


[weewx-development] Re: GW1000 driver

2020-07-23 Thread Gert Andersen
Hi George

Thanks for your answer.

Does this imply that the GW1000 and WeeWx is on the same network?

My configuration is GW1000 local and WeeWx running remote. Can this 
configuration work? You mention that the API should know the IP address, 
but the ip address of the GW1000 is local(192.168.xxx.xxx) and can't be  
seen from outside.

Gert

On Thursday, July 23, 2020 at 6:55:45 PM UTC+2, George Alfert wrote:
>
> Gert,
> "How do I set up Ecowitt WsView to send information to the GW1000 driver?"
> answer- you don't do anything in WS View. The beauty of the GW1000 API 
> driver is that all the magic happens in the API driver. The API driver just 
> needs to know the IP address of your GW1000 and that is it. The GW1000 does 
> not need to be configured to send data anywhere. The function of the API is 
> for the API driver to hit the GW1000 via its IP address and speak directly 
> to the GW1000 and basically say to the GW1000, "Hey, send me data" and the 
> GW1000 takes note of where the request came from and it responds. This is 
> what allows applications that speak with the API to all run simultaneously. 
> I currently have one GW1000 and several different applications use the API 
> to all talk to the GW1000 at the same time having not done a thing on the 
> GW1000 side.
>
>
>
>
> On Thursday, July 23, 2020 at 12:39:44 PM UTC-4, Gert Andersen wrote:
>>
>> Hi Gary
>>
>> I have installed Interceptor for Ecowitt client and it has worked fine. 
>> However, there have been minor issues with new sensors from Ecowitt. I am 
>> therefore interested in trying the new extension.
>>
>> I therefore have a few questions:
>> How do I set up Ecowitt WsView to send information to the GW1000 driver?
>> Should WsView send to a port? Is the driver listening to a port?
>> Is the Ecowitt passkey implemented?
>>
>> Many thanks for this initiative.
>>
>> Gert
>>
>> On Tuesday, July 21, 2020 at 4:50:23 AM UTC+2, gjr80 wrote:
>>>
>>> I have developed an API based driver for the Ecowitt GW1000 WiFi 
>>> Gateway. So what? Well the current means of receiving data from the GW1000 
>>> involves the GW1000 pushing data that is then parsed/processed by the 
>>> interceptor driver and loop packets emitted. This API based driver uses a 
>>> pull methodology where the GW1000 API is polled at a user specified 
>>> interval and the API response is then used to generate loop packets. Use of 
>>> the API also gives access to sensor battery data and allows some 
>>> interrogation of the GW1000/sensor state.
>>>
>>> I have developed the driver without direct access to the API so I am 
>>> sure there will be some issues with it, most likely to do with 
>>> device/sensor state info and possibly sensors I don't have access to. I 
>>> have tested it against GW1000/WH31/WH32/WH41/WH51/WH57 sensors. The driver 
>>> can be operated as a traditional WeeWX driver that emits loop packets but 
>>> can also be operated as a WeeWX service that augments loop packets with 
>>> GW1000 data. The driver will operate under WeeWX 4.x python 2 and 3 and 
>>> under WeeWX 3.9.x (probably some earlier 3.x versions as well).
>>>
>>> The driver can be found on GitHub 
>>>  and can be downloaded as an 
>>> extension package from the releases tab 
>>> . Installation and 
>>> configuration is covered in the readme on the GitHub site or as included in 
>>> the package as well as in the up front comments in the driver file 
>>> gw1000.py. The driver can be run directly without the overheads of a 
>>> running instance of WeeWX (WeeWX must be installed though). You can also 
>>> run the driver directly while WeeWX continues to operate without 
>>> interfering with the running WeeWX instance.
>>>
>>> I would welcome anyone who wants to try the driver. If you do want to 
>>> try it I would recommend installing the driver extension package or just 
>>> the driver file (gw1000.py), and then running the driver directly with 
>>> the various command line options (I would not reconfigure WeeWX to use the 
>>> driver until you have confirmed it configured and operating as expected). 
>>> Once gw1000.py is in the user directory (/home/weewx/bin/user or 
>>> /usr/share/weewx/user) you can run the driver directly by using:
>>>
>>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000
>>>
>>> or
>>>
>>> $ python -m user.gw1000
>>>
>>> depending on your WeeWX install. This should display the driver help. 
>>> Depending on what python version(s) are installed on your system, and how 
>>> your system is configured, you may need/want to change python to python2 or 
>>> python3 in the above commands.
>>>
>>> I would recommend exercising the various command line options before 
>>> building up to --test-driver or --test-service. Only once you see the 
>>> data you expect  should you move to reconfiguring WeeWX to use the 
>>> driver/service. If some sensor data is missing or just plain wrong then 
>>> that 

Re: [weewx-development] Re: GW1000 driver

2020-07-23 Thread Greg Troxel
George Alfert  writes:

> I think what people should realize is that there are 3 methods to get data 
> from the GW1000.
>
> 1. Customized server upload WU protocol
> 2. Customized server upload Ecowitt protocol (this is not the same as API)
> 3. GW1000 API (nothing needs configuring in WS View)

Do you mean that I can, without running any ecowitt software on any kind
of phone, perhaps using a web browser

  - buy a GW1000 and plug it in
  - configure it to my wifi (how?)
including firewall config so it can't talk to the internet
  - (pair it to listen to a soil moisture sensor, if necessary)
  - run the new weewx code and get data

?

Do all shipping GW1000 units support the API?


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


[weewx-development] Re: GW1000 driver

2020-07-23 Thread George Alfert
I think what people should realize is that there are 3 methods to get data 
from the GW1000.

1. Customized server upload WU protocol
2. Customized server upload Ecowitt protocol (this is not the same as API)
3. GW1000 API (nothing needs configuring in WS View)



On Thursday, July 23, 2020 at 12:55:45 PM UTC-4, George Alfert wrote:
>
> Gert,
> "How do I set up Ecowitt WsView to send information to the GW1000 driver?"
> answer- you don't do anything in WS View. The beauty of the GW1000 API 
> driver is that all the magic happens in the API driver. The API driver just 
> needs to know the IP address of your GW1000 and that is it. The GW1000 does 
> not need to be configured to send data anywhere. The function of the API is 
> for the API driver to hit the GW1000 via its IP address and speak directly 
> to the GW1000 and basically say to the GW1000, "Hey, send me data" and the 
> GW1000 takes note of where the request came from and it responds. This is 
> what allows applications that speak with the API to all run simultaneously. 
> I currently have one GW1000 and several different applications use the API 
> to all talk to the GW1000 at the same time having not done a thing on the 
> GW1000 side.
>
>
>
>
> On Thursday, July 23, 2020 at 12:39:44 PM UTC-4, Gert Andersen wrote:
>>
>> Hi Gary
>>
>> I have installed Interceptor for Ecowitt client and it has worked fine. 
>> However, there have been minor issues with new sensors from Ecowitt. I am 
>> therefore interested in trying the new extension.
>>
>> I therefore have a few questions:
>> How do I set up Ecowitt WsView to send information to the GW1000 driver?
>> Should WsView send to a port? Is the driver listening to a port?
>> Is the Ecowitt passkey implemented?
>>
>> Many thanks for this initiative.
>>
>> Gert
>>
>> On Tuesday, July 21, 2020 at 4:50:23 AM UTC+2, gjr80 wrote:
>>>
>>> I have developed an API based driver for the Ecowitt GW1000 WiFi 
>>> Gateway. So what? Well the current means of receiving data from the GW1000 
>>> involves the GW1000 pushing data that is then parsed/processed by the 
>>> interceptor driver and loop packets emitted. This API based driver uses a 
>>> pull methodology where the GW1000 API is polled at a user specified 
>>> interval and the API response is then used to generate loop packets. Use of 
>>> the API also gives access to sensor battery data and allows some 
>>> interrogation of the GW1000/sensor state.
>>>
>>> I have developed the driver without direct access to the API so I am 
>>> sure there will be some issues with it, most likely to do with 
>>> device/sensor state info and possibly sensors I don't have access to. I 
>>> have tested it against GW1000/WH31/WH32/WH41/WH51/WH57 sensors. The driver 
>>> can be operated as a traditional WeeWX driver that emits loop packets but 
>>> can also be operated as a WeeWX service that augments loop packets with 
>>> GW1000 data. The driver will operate under WeeWX 4.x python 2 and 3 and 
>>> under WeeWX 3.9.x (probably some earlier 3.x versions as well).
>>>
>>> The driver can be found on GitHub 
>>>  and can be downloaded as an 
>>> extension package from the releases tab 
>>> . Installation and 
>>> configuration is covered in the readme on the GitHub site or as included in 
>>> the package as well as in the up front comments in the driver file 
>>> gw1000.py. The driver can be run directly without the overheads of a 
>>> running instance of WeeWX (WeeWX must be installed though). You can also 
>>> run the driver directly while WeeWX continues to operate without 
>>> interfering with the running WeeWX instance.
>>>
>>> I would welcome anyone who wants to try the driver. If you do want to 
>>> try it I would recommend installing the driver extension package or just 
>>> the driver file (gw1000.py), and then running the driver directly with 
>>> the various command line options (I would not reconfigure WeeWX to use the 
>>> driver until you have confirmed it configured and operating as expected). 
>>> Once gw1000.py is in the user directory (/home/weewx/bin/user or 
>>> /usr/share/weewx/user) you can run the driver directly by using:
>>>
>>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000
>>>
>>> or
>>>
>>> $ python -m user.gw1000
>>>
>>> depending on your WeeWX install. This should display the driver help. 
>>> Depending on what python version(s) are installed on your system, and how 
>>> your system is configured, you may need/want to change python to python2 or 
>>> python3 in the above commands.
>>>
>>> I would recommend exercising the various command line options before 
>>> building up to --test-driver or --test-service. Only once you see the 
>>> data you expect  should you move to reconfiguring WeeWX to use the 
>>> driver/service. If some sensor data is missing or just plain wrong then 
>>> that needs to be dealt with.
>>>
>>> If you do run into problems, in particular if the 

[weewx-development] Re: GW1000 driver

2020-07-23 Thread George Alfert
Gert,
"How do I set up Ecowitt WsView to send information to the GW1000 driver?"
answer- you don't do anything in WS View. The beauty of the GW1000 API 
driver is that all the magic happens in the API driver. The API driver just 
needs to know the IP address of your GW1000 and that is it. The GW1000 does 
not need to be configured to send data anywhere. The function of the API is 
for the API driver to hit the GW1000 via its IP address and speak directly 
to the GW1000 and basically say to the GW1000, "Hey, send me data" and the 
GW1000 takes note of where the request came from and it responds. This is 
what allows applications that speak with the API to all run simultaneously. 
I currently have one GW1000 and several different applications use the API 
to all talk to the GW1000 at the same time having not done a thing on the 
GW1000 side.




On Thursday, July 23, 2020 at 12:39:44 PM UTC-4, Gert Andersen wrote:
>
> Hi Gary
>
> I have installed Interceptor for Ecowitt client and it has worked fine. 
> However, there have been minor issues with new sensors from Ecowitt. I am 
> therefore interested in trying the new extension.
>
> I therefore have a few questions:
> How do I set up Ecowitt WsView to send information to the GW1000 driver?
> Should WsView send to a port? Is the driver listening to a port?
> Is the Ecowitt passkey implemented?
>
> Many thanks for this initiative.
>
> Gert
>
> On Tuesday, July 21, 2020 at 4:50:23 AM UTC+2, gjr80 wrote:
>>
>> I have developed an API based driver for the Ecowitt GW1000 WiFi Gateway. 
>> So what? Well the current means of receiving data from the GW1000 involves 
>> the GW1000 pushing data that is then parsed/processed by the interceptor 
>> driver and loop packets emitted. This API based driver uses a pull 
>> methodology where the GW1000 API is polled at a user specified interval and 
>> the API response is then used to generate loop packets. Use of the API also 
>> gives access to sensor battery data and allows some interrogation of the 
>> GW1000/sensor state.
>>
>> I have developed the driver without direct access to the API so I am sure 
>> there will be some issues with it, most likely to do with device/sensor 
>> state info and possibly sensors I don't have access to. I have tested it 
>> against GW1000/WH31/WH32/WH41/WH51/WH57 sensors. The driver can be operated 
>> as a traditional WeeWX driver that emits loop packets but can also be 
>> operated as a WeeWX service that augments loop packets with GW1000 data. 
>> The driver will operate under WeeWX 4.x python 2 and 3 and under WeeWX 
>> 3.9.x (probably some earlier 3.x versions as well).
>>
>> The driver can be found on GitHub  
>> and can be downloaded as an extension package from the releases tab 
>> . Installation and 
>> configuration is covered in the readme on the GitHub site or as included in 
>> the package as well as in the up front comments in the driver file 
>> gw1000.py. The driver can be run directly without the overheads of a 
>> running instance of WeeWX (WeeWX must be installed though). You can also 
>> run the driver directly while WeeWX continues to operate without 
>> interfering with the running WeeWX instance.
>>
>> I would welcome anyone who wants to try the driver. If you do want to try 
>> it I would recommend installing the driver extension package or just the 
>> driver file (gw1000.py), and then running the driver directly with the 
>> various command line options (I would not reconfigure WeeWX to use the 
>> driver until you have confirmed it configured and operating as expected). 
>> Once gw1000.py is in the user directory (/home/weewx/bin/user or 
>> /usr/share/weewx/user) you can run the driver directly by using:
>>
>> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000
>>
>> or
>>
>> $ python -m user.gw1000
>>
>> depending on your WeeWX install. This should display the driver help. 
>> Depending on what python version(s) are installed on your system, and how 
>> your system is configured, you may need/want to change python to python2 or 
>> python3 in the above commands.
>>
>> I would recommend exercising the various command line options before 
>> building up to --test-driver or --test-service. Only once you see the 
>> data you expect  should you move to reconfiguring WeeWX to use the 
>> driver/service. If some sensor data is missing or just plain wrong then 
>> that needs to be dealt with.
>>
>> If you do run into problems, in particular if the driver is not returning 
>> expected data, run the driver with the --debug=3 command line option and 
>> post details of the problem and a log extract showing the driver debug info.
>>
>> Gary
>>
>>

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

[weewx-development] Re: GW1000 driver

2020-07-23 Thread Gert Andersen
Hi Gary

I have installed Interceptor for Ecowitt client and it has worked fine. 
However, there have been minor issues with new sensors from Ecowitt. I am 
therefore interested in trying the new extension.

I therefore have a few questions:
How do I set up Ecowitt WsView to send information to the GW1000 driver?
Should WsView send to a port? Is the driver listening to a port?
Is the Ecowitt passkey implemented?

Many thanks for this initiative.

Gert

On Tuesday, July 21, 2020 at 4:50:23 AM UTC+2, gjr80 wrote:
>
> I have developed an API based driver for the Ecowitt GW1000 WiFi Gateway. 
> So what? Well the current means of receiving data from the GW1000 involves 
> the GW1000 pushing data that is then parsed/processed by the interceptor 
> driver and loop packets emitted. This API based driver uses a pull 
> methodology where the GW1000 API is polled at a user specified interval and 
> the API response is then used to generate loop packets. Use of the API also 
> gives access to sensor battery data and allows some interrogation of the 
> GW1000/sensor state.
>
> I have developed the driver without direct access to the API so I am sure 
> there will be some issues with it, most likely to do with device/sensor 
> state info and possibly sensors I don't have access to. I have tested it 
> against GW1000/WH31/WH32/WH41/WH51/WH57 sensors. The driver can be operated 
> as a traditional WeeWX driver that emits loop packets but can also be 
> operated as a WeeWX service that augments loop packets with GW1000 data. 
> The driver will operate under WeeWX 4.x python 2 and 3 and under WeeWX 
> 3.9.x (probably some earlier 3.x versions as well).
>
> The driver can be found on GitHub  
> and can be downloaded as an extension package from the releases tab 
> . Installation and 
> configuration is covered in the readme on the GitHub site or as included in 
> the package as well as in the up front comments in the driver file 
> gw1000.py. The driver can be run directly without the overheads of a 
> running instance of WeeWX (WeeWX must be installed though). You can also 
> run the driver directly while WeeWX continues to operate without 
> interfering with the running WeeWX instance.
>
> I would welcome anyone who wants to try the driver. If you do want to try 
> it I would recommend installing the driver extension package or just the 
> driver file (gw1000.py), and then running the driver directly with the 
> various command line options (I would not reconfigure WeeWX to use the 
> driver until you have confirmed it configured and operating as expected). 
> Once gw1000.py is in the user directory (/home/weewx/bin/user or 
> /usr/share/weewx/user) you can run the driver directly by using:
>
> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000
>
> or
>
> $ python -m user.gw1000
>
> depending on your WeeWX install. This should display the driver help. 
> Depending on what python version(s) are installed on your system, and how 
> your system is configured, you may need/want to change python to python2 or 
> python3 in the above commands.
>
> I would recommend exercising the various command line options before 
> building up to --test-driver or --test-service. Only once you see the 
> data you expect  should you move to reconfiguring WeeWX to use the 
> driver/service. If some sensor data is missing or just plain wrong then 
> that needs to be dealt with.
>
> If you do run into problems, in particular if the driver is not returning 
> expected data, run the driver with the --debug=3 command line option and 
> post details of the problem and a log extract showing the driver debug info.
>
> Gary
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/6bdfb2c6-775a-4fca-8a18-2cfef5f4201do%40googlegroups.com.


[weewx-development] Re: GW1000 driver

2020-07-23 Thread George Alfert
Nice work Gary! Matthew Wall has informed me that Gary is considered core 
WeeWX developer. I've sent him official GW1000 API documentation to be able 
to further refine the driver. This will allow the driver to be ready for 
yet unreleased future sensors.


On Thursday, July 23, 2020 at 9:22:23 AM UTC-4, gjr80 wrote:
>
> To the best of my knowledge there is no logging capability in the GW1000. 
> If there was I think we would have heard someone on wxforum.net spruiking 
> about it by now.
>
> Gary
>
> On Thursday, 23 July 2020 20:33:20 UTC+10, Graham Eddy wrote:
>>
>> so the rumour of an API for GW1000 and an early adopter program was true!
>>
>> with news of your API-based driver-in-making i have just placed an order 
>> for GW1003 + lightning range + 2*soil moisture + 2*air quality sensors, and 
>> i'll be happy to help with the testing
>>
>> i saw that the API supports multiple clients so i can help with testing 
>> on my old mac server as well as my new raspberry
>>
>> does gw1000 have a data logger like my very aged vp2 which allows 
>> catch-up after an outage? (i've looked at driver header comments but not 
>> delved the code as yet)
>>
>> On Tuesday, 21 July 2020 12:50:23 UTC+10, gjr80 wrote:
>>>
>>> I have developed an API based driver for the Ecowitt GW1000 WiFi 
>>> Gateway. So what? Well the current means of receiving data from the GW1000 
>>> involves the GW1000 pushing data that is then parsed/processed by the 
>>> interceptor driver and loop packets emitted. This API based driver uses a 
>>> pull methodology where the GW1000 API is polled at a user specified 
>>> interval and the API response is then used to generate loop packets. Use of 
>>> the API also gives access to sensor battery data and allows some 
>>> interrogation of the GW1000/sensor state.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/be736e44-019f-49e9-a25b-c07559477f53o%40googlegroups.com.


[weewx-development] Re: GW1000 driver

2020-07-23 Thread gjr80
To the best of my knowledge there is no logging capability in the GW1000. 
If there was I think we would have heard someone on wxforum.net spruiking 
about it by now.

Gary

On Thursday, 23 July 2020 20:33:20 UTC+10, Graham Eddy wrote:
>
> so the rumour of an API for GW1000 and an early adopter program was true!
>
> with news of your API-based driver-in-making i have just placed an order 
> for GW1003 + lightning range + 2*soil moisture + 2*air quality sensors, and 
> i'll be happy to help with the testing
>
> i saw that the API supports multiple clients so i can help with testing on 
> my old mac server as well as my new raspberry
>
> does gw1000 have a data logger like my very aged vp2 which allows catch-up 
> after an outage? (i've looked at driver header comments but not delved the 
> code as yet)
>
> On Tuesday, 21 July 2020 12:50:23 UTC+10, gjr80 wrote:
>>
>> I have developed an API based driver for the Ecowitt GW1000 WiFi Gateway. 
>> So what? Well the current means of receiving data from the GW1000 involves 
>> the GW1000 pushing data that is then parsed/processed by the interceptor 
>> driver and loop packets emitted. This API based driver uses a pull 
>> methodology where the GW1000 API is polled at a user specified interval and 
>> the API response is then used to generate loop packets. Use of the API also 
>> gives access to sensor battery data and allows some interrogation of the 
>> GW1000/sensor state.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/f4807368-266d-41b4-a9b3-a7be494ca7e3o%40googlegroups.com.


[weewx-development] Re: GW1000 driver

2020-07-23 Thread Graham Eddy
so the rumour of an API for GW1000 and an early adopter program was true!

with news of your API-based driver-in-making i have just placed an order 
for GW1003 + lightning range + 2*soil moisture + 2*air quality sensors, and 
i'll be happy to help with the testing

i saw that the API supports multiple clients so i can help with testing on 
my old mac server as well as my new raspberry

does gw1000 have a data logger like my very aged vp2 which allows catch-up 
after an outage? (i've looked at driver header comments but not delved the 
code as yet)

On Tuesday, 21 July 2020 12:50:23 UTC+10, gjr80 wrote:
>
> I have developed an API based driver for the Ecowitt GW1000 WiFi Gateway. 
> So what? Well the current means of receiving data from the GW1000 involves 
> the GW1000 pushing data that is then parsed/processed by the interceptor 
> driver and loop packets emitted. This API based driver uses a pull 
> methodology where the GW1000 API is polled at a user specified interval and 
> the API response is then used to generate loop packets. Use of the API also 
> gives access to sensor battery data and allows some interrogation of the 
> GW1000/sensor state.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/af86eb50-2a7c-4174-bfa0-6437d60e4f40o%40googlegroups.com.