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 > it....etc. 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 work....but 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 >>>>>> <https://github.com/gjr80/weewx-gw1000> and can be downloaded as an >>>>>> extension package from the releases tab >>>>>> <https://github.com/gjr80/weewx-gw1000/releases>. 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/4f4c5584-18be-4273-a74b-5f0780da771ao%40googlegroups.com.
