[weewx-user] WS1 help

[Dj Merrill]

Hi all,
I am attempting to setup an Argent Data Systems WS1 weather station 
attached to a Raspberry Pi running Weewx.  I have the basics working, but 
am seeing a couple of oddities that I would like to request help with.

The first is that I'm seeing errors on the logs saying:

LOOP value 'pressure' 19.7555616375 outside limits (24.0, 34.5)

I suspect this is due to the Weewx software expecting to see values in Hg 
but the weather station is sending in Pa.  How do I correct this?

The values for the other sensors look normal and show the correct units.

The second is that Weewx is reporting the temperature sent from the WS1 as 
"internal temperature".  While technically this is the temperature inside 
the WS1 control box, the box is supposed to be mounted outside so it is 
really an outside temperature reading.  How do I get Weewx to read this as 
an outside temperature value?

Thanks,

-Dj

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Steel Gauges question

[gjr80]

PPS. You should then be able to redo the changes to the ss/skin.conf so 
that the mouseover plots are generated and upload by FTP.

Gary

On Saturday, 27 October 2018 09:33:52 UTC+10, gjr80 wrote:
>
> They just keep coming don't they!
>
> What is happening with the FtpGenerator error is that when rtgd creates 
> gauge-data.txt it actually builds the file in gauge-data.txt.tmp and once 
> the file is complete it is copied to gauge-data.txt. This is known as an 
> atomic write and is done to lessen the chance that gauge-data.txt is open 
> for writing (by rtgd) and thus unavailable for access by other processes. 
> The .tmp file is created in the same directory as gauge-data.txt. When 
> FtpGenerator kicks off it gathers the details of the files it is to 
> upload and then works its way through uploading each in turn (so it could 
> be some seconds after gathering the list that the file is uploaded), if the 
> .tmp file exists when the FtpGenerator gathers its list of files it is 
> included for upload but if the .tmp file is subsequently removed you get 
> the FtpGenerator error you are seeing. If you like, the holes in the 
> swiss cheese are aligning to cause the error, the more frequent 
> gauge-data.txt is produced and the more frequent the FtpGenerator is run 
> the more chance of the holes aligning and the error occurring.
>
> The long term fix is for me to change rtgd to create the .tmp file 
> somewhere that is unlikely to be uploaded by the FtpGenerator. You can 
> work around the issue by changing the location in which that 
> gauge-data.txt is created. Edit weewx.conf and under [RealtimeGaugeData] 
> comment out the rtgd_path setting (it will then use the default of 
> /var/tmp) or change it to something else not used by weeWX. Save 
> weewx.conf and restart weeWX or do a config reload. If you are 
> transferring the rtgd generated gauge-data.txt to a remote server the 
> location of gauge-data.txt is not important, it's location is only 
> important if using the file on the weeWX machine (eg your weeWX machine is 
> also your web server) but in such cases chances are you are not uploading 
> via FTP.
>
> Gary
>
> PS. I'll drop you an email sometime re astronomy to hear what you are up 
> to.
>
> On Saturday, 27 October 2018 00:07:29 UTC+10, Steve2Q wrote:
>>
>> Hi Gary.
>>
>> The gauge 2 second loops are working perfectly now.
>>
>> I did the changes, however that started throwing errors (I always watch 
>> syslog for a bit to see if anything obvious happens).
>>
>> Attached is syslog. Once I saw the errors I did the following: Put the 
>> comments back in weewx.conf in[StandartReport][[SteelGauges]], and changed 
>> to debug = 1. I left in the change you recommended in skins/ss/skin.conf. I 
>> restarted weewx at 9:11 and let in run until 9:43. 
>>
>> Next I uncommented the [[SteelGauges]] section in weewx.conf, and 
>> restarted at 9:45. I only let in run for a few minutes because weewx would 
>> not start. I then recommented [[SteelGauges]], set debug = 0, and that is 
>> where I am now.
>>
>> Besides the "parsing" error at 9:45, I find the "unrecoverable exception" 
>> at 9:17:13 of interest (and you can see it occurred earlier before I made 
>> ANY of the changes like at 6:43.
>>
>> Steve
>>
>> Seems like we have some other common interests. Astronomy is also one of 
>> mine.
>>
>> Steve
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Steel Gauges question

[gjr80]

They just keep coming don't they!

What is happening with the FtpGenerator error is that when rtgd creates 
gauge-data.txt it actually builds the file in gauge-data.txt.tmp and once 
the file is complete it is copied to gauge-data.txt. This is known as an 
atomic write and is done to lessen the chance that gauge-data.txt is open 
for writing (by rtgd) and thus unavailable for access by other processes. 
The .tmp file is created in the same directory as gauge-data.txt. When 
FtpGenerator kicks off it gathers the details of the files it is to upload 
and then works its way through uploading each in turn (so it could be some 
seconds after gathering the list that the file is uploaded), if the .tmp 
file exists when the FtpGenerator gathers its list of files it is included 
for upload but if the .tmp file is subsequently removed you get the 
FtpGenerator error you are seeing. If you like, the holes in the swiss 
cheese are aligning to cause the error, the more frequent gauge-data.txt is 
produced and the more frequent the FtpGenerator is run the more chance of 
the holes aligning and the error occurring.

The long term fix is for me to change rtgd to create the .tmp file 
somewhere that is unlikely to be uploaded by the FtpGenerator. You can work 
around the issue by changing the location in which that gauge-data.txt is 
created. Edit weewx.conf and under [RealtimeGaugeData] comment out the 
rtgd_path setting (it will then use the default of /var/tmp) or change it 
to something else not used by weeWX. Save weewx.conf and restart weeWX or 
do a config reload. If you are transferring the rtgd generated 
gauge-data.txt to a remote server the location of gauge-data.txt is not 
important, it's location is only important if using the file on the weeWX 
machine (eg your weeWX machine is also your web server) but in such cases 
chances are you are not uploading via FTP.

Gary

PS. I'll drop you an email sometime re astronomy to hear what you are up to.

On Saturday, 27 October 2018 00:07:29 UTC+10, Steve2Q wrote:
>
> Hi Gary.
>
> The gauge 2 second loops are working perfectly now.
>
> I did the changes, however that started throwing errors (I always watch 
> syslog for a bit to see if anything obvious happens).
>
> Attached is syslog. Once I saw the errors I did the following: Put the 
> comments back in weewx.conf in[StandartReport][[SteelGauges]], and changed 
> to debug = 1. I left in the change you recommended in skins/ss/skin.conf. I 
> restarted weewx at 9:11 and let in run until 9:43. 
>
> Next I uncommented the [[SteelGauges]] section in weewx.conf, and 
> restarted at 9:45. I only let in run for a few minutes because weewx would 
> not start. I then recommented [[SteelGauges]], set debug = 0, and that is 
> where I am now.
>
> Besides the "parsing" error at 9:45, I find the "unrecoverable exception" 
> at 9:17:13 of interest (and you can see it occurred earlier before I made 
> ANY of the changes like at 6:43.
>
> Steve
>
> Seems like we have some other common interests. Astronomy is also one of 
> mine.
>
> Steve
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: WS-3000

[olivier . guyotot]

Glad to hear that you got it working! And thanks for howto, much 
appreciated. That's really something that I should have done long ago, but 
I never found the time/motivation to do 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: No humidity - Davis Vantage Pro 2

[dhampikian]

On Thursday, October 25, 2018 at 5:21:45 PM UTC-7, dhamp...@gmail.com wrote:
>
> I have successfully got weewx working on my home computer under Ubuntu 
> 18.04 Mate. I am using a Davis Vantage Pro 2 with  Weatherlink data logger 
> (6510USB). On the console that came with Davis which is also wireless I get 
> both inside and outside humidity readings.
> On the weewx I get no humidity readings. I assume that the indoor humidity 
> readings are in the Davis console, thus I don't expect to see them from 
> weewx. However, I get nothing from weewx for outside humidity. I looked 
> into the database and the humidity readings are 0.
> I checked the log and see no errors. Is there something I need to adjust 
> in config files? I assume it is a software related problem. Don't know what 
> to check next.
>
> Regards,
> Dick
>

Thomas,

Thanks for the suggestions. I gave you wrong info. I do not get Humidity on 
console. I checked db and humidity are null. I conclude that temp/humidity 
module  has ceased operating correctly. I have ordered a replacement. Sorry 
to have wasted you time.

Regards,
Dick

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Raspberry kernels later than 4.4 hang when running weewx.

[Ruben Navarro Huedo]

7 days now with wmr300x and 4.4.50 kernel.

Let's continue testing.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: WS-3000

[Risto H. Kurppa]

Hi,

No, I didn't try that, didn't realize that would also apply.
So now I have a fresh Stretch install and will next try to set everything
up.
I'll try to collect the required steps here..
https://etherpad.net/p/weewx_raspi  (feel free to help to turn it to a
step-by-step tutorial..)

r


On Fri, Oct 26, 2018 at 4:29 PM  wrote:

> Just to clarify, I was referring to the following post:
>
> - edit the file ws3000.py
> - on lines 316 (return self.device.write(self.OUT_ep, data=buf, timeout=
> 100)) and 320 (buf = self.device.read(self.IN_ep, self.packet_size, 100))
> increase the last parameter of the device.write and device.read function
> to 1000 instead of 100.
> - restart weewx
>
> --
> 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/qDe-El03C2k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
| risto h. kurppa
| risto at kurppa dot fi
| http://risto.kurppa.fi

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Vantage Pro and end of DST clock change

[Thomas Keffer]

If you're resolved to get all the records then, yes, that's the process.

Otherwise, just count on losing an hour's worth of data --- that's what I'm
gonna do!

-tk

On Fri, Oct 26, 2018 at 7:08 AM Andrew Milner 
wrote:

> Since we turn the clocks back tomorrow night, and this is my first year
> with a Vantage Pro (FO always worked without any action being required) -
> am I correct in thinking that the 'correct' mechanism for handling a
> Vantage Pro and weewx is to:
>
> a) stop weewx before the clock change
> b) edit weewx.conf to switch to software record generation in the
> [StdArchive] section
> c) restart weewx and run through the clock change transition
> d) stop weewx
> e) edit weewx.conf and change back to hardware record generation
> f) restart weewx
>
> or is there another/better way to avoid any issues caused by what I
> understand to be the Davis logger using local time?
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Modbus connection WEEWX Vantage through KTA-282 module

[Guido]

Good morning ,

I have a Vantage Pro 2 weather station with the Envoy logger and through 
the serial connection a KTA-282 Modbus module from Ocean Controls. 

Now I would like to access from Weewx on raspberry the Davis, but the 
Vantage driver have not the right access parameters to do that : there is 
someone that already have solved this problem ? Or someone the knows the 
driver could suggest the modification to do ?

The modbus module answer as a client on an local ip address and the port 
502 with the mode3 ( read registers from location 4+1).

Thanks 

Guido

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Modbus connection WEEWX Vantage through KTA-282 module (Read 146 times)

[Guido]

Good morning ,

I have a Vantage Pro 2 weather station with the Envoy logger and through 
the serial connection a KTA-282 Modbus module from Ocean Controls. 

Now I would like to access from Weewx on raspberry the Davis, but the 
Vantage driver have not the right access parameters to do that : there is 
someone that already have solved this problem ? Or someone the knows the 
driver could suggest the modification to do ?

The modbus module answer as a client on an local ip address and the port 
502 with the mode3 ( read registers from location 4+1).

Thanks 

Guido

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Vantage Pro and end of DST clock change

[Andrew Milner]

Since we turn the clocks back tomorrow night, and this is my first year 
with a Vantage Pro (FO always worked without any action being required) -  
am I correct in thinking that the 'correct' mechanism for handling a 
Vantage Pro and weewx is to:

a) stop weewx before the clock change
b) edit weewx.conf to switch to software record generation in the 
[StdArchive] section 
c) restart weewx and run through the clock change transition
d) stop weewx
e) edit weewx.conf and change back to hardware record generation
f) restart weewx

or is there another/better way to avoid any issues caused by what I 
understand to be the Davis logger using local time?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeatherLink and wlink driver not pulling data

[trrisner]

*SOLUTION FOUND* 
just for anyone else that might run into this issue. 
Since I'm using an "amazon linux" machine that is "red hat like," 

I fully removed everything weewx related. 

reinstalled weewx using setup.py (NOT REHAT PACKAGE)

used amazon's suggestion 
in how 
to change the machines time zone (since wlink needs the machine and weather 
station in the same time zone)

dowloaded the wlink.py and put it in /home/weewx/bin/user

Used the wlink instructions HERE 
 

and now have data 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WS-3000

[olivier . guyotot]

Just to clarify, I was referring to the following post:

- edit the file ws3000.py
- on lines 316 (return self.device.write(self.OUT_ep, data=buf, timeout=100)) 
and 320 (buf = self.device.read(self.IN_ep, self.packet_size, 100)) 
increase the last parameter of the device.write and device.read function to 
1000 instead of 100.
- restart weewx

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Record time delay

[Thomas Keffer]

Definitely something odd going on with the interceptor driver. As Gary
notes, it regularly stores data to the database at five minute intervals,
but it falls farther and farther behind real-time as weewx runs.

One for Matthew...

-tk

On Thu, Oct 25, 2018 at 11:40 PM  wrote:

> Record time has been delayed
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WS-3000

[olivier . guyotot]

Did you do the change suggested in my post from Aug 29th?

On RPi, you need to increase the usb timeout. I actually updated my code, 
but I never uploaded the modified files... so unless you manually made the 
change, you probably still have a 100 ms timeout, which isn't enough on RPi.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WS-3000

[RistoK]

Thanks for your input!!

I updated my Raspbian to Jessie (took about 24 hours or so :D) and log 
below tells where I'm at now. 
It's still possible that there are issues with Python packages. Still using 
the weewx.deb that requires python-usb from package management. It's 
possible that compiling weewx from source is the next option.. 

And now that I checked Debian releaseses I see that I'm so behind.. I 
thought Jessie was the latest stable but I see it's Stretch already.. -> 
upgrading/fresh install to that next..

Oct 26 15:07:23 ripapi weewx[17576]: engine: Starting up weewx version 3.8.2
Oct 26 15:07:23 ripapi weewx[17576]: engine: Station does not support 
reading the time
Oct 26 15:07:23 ripapi weewx[17576]: engine: Starting main packet loop.
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: sending request for 
sensor_values
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: write: 7b 03 40 7d (len=4)
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: reading results...
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: reading 64 bytes
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: read: 7b 00 25 56 00 da 23 00 
cc 28 00 cd 27 00 dc 26 00 b4 28 00 db 27 7f ff ff 40 7d 00 f1 25 c4 05 80 
fc c5 8a 4e 14 2f 2c d1 d7 e7 70 9c 7b e5 e1 3e 17 5f 4e 19 72 97 5e 02 1a 
0e 52 33 f6 80 ce (len=64)
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: extracting values for 
sensor_values
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: raw: array('B', [123, 0, 37, 
86, 0, 218, 35, 0, 204, 40, 0, 205, 39, 0, 220, 38, 0, 180, 40, 0, 219, 39, 
127, 255, 255, 64, 125])
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: data: {'h_6': 40, 'h_7': 39, 
'h_4': 39, 'h_5': 38, 'h_2': 35, 'h_3': 40, 'h_1': 86, 't_6': 18.0, 't_2': 
21.8, 't_3': 20.4, 't_1': 3.7, 'type': 'sensor_values', 't_7': 21.9, 't_4': 
20.5, 't_5': 22.0}
Oct 26 15:07:23 ripapi weewx[17576]: ws3000: packet: {'dateTime': 
1540555644, 'extraHumid6': 40, 'extraHumid7': 39, 'extraHumid4': 39, 
'extraHumid5': 38, 'extraHumid2': 35, 'extraHumid3': 40, 'extraHumid1': 86, 
'extraTemp6': 18.0, 'extraTemp7': 21.9, 'extraTemp4': 20.5, 'extraTemp5': 
22.0, 'extraTemp2': 21.8, 'extraTemp3': 20.4, 'usUnits': 17, 'extraTemp1': 
3.7}
Oct 26 15:07:53 ripapi weewx[17576]: ws3000: sending request for 
sensor_values
Oct 26 15:07:53 ripapi weewx[17576]: ws3000: write: 7b 03 40 7d (len=4)
Oct 26 15:07:53 ripapi weewx[17576]: engine: Main loop exiting. Shutting 
engine down.
Oct 26 15:07:53 ripapi weewx[17576]: engine: Caught unrecoverable exception 
in engine:
Oct 26 15:07:53 ripapi weewx[17576]:   'int' object is not callable
Oct 26 15:07:53 ripapi weewx[17576]:   Traceback (most recent call 
last):
Oct 26 15:07:53 ripapi weewx[17576]: File 
"/usr/share/weewx/weewx/engine.py", line 877, in main
Oct 26 15:07:53 ripapi weewx[17576]:   engine.run()
Oct 26 15:07:53 ripapi weewx[17576]: File 
"/usr/share/weewx/weewx/engine.py", line 188, in run
Oct 26 15:07:53 ripapi weewx[17576]:   for packet in 
self.console.genLoopPackets():
Oct 26 15:07:53 ripapi weewx[17576]: File 
"/usr/share/weewx/user/ws3000.py", line 292, in genLoopPackets
Oct 26 15:07:53 ripapi weewx[17576]:   loop_packet = 
self.getCurrentValues()
Oct 26 15:07:53 ripapi weewx[17576]: File 
"/usr/share/weewx/user/ws3000.py", line 267, in getCurrentValues
Oct 26 15:07:53 ripapi weewx[17576]:   raw_data = 
self._get_raw_data(read_sensors_command)
Oct 26 15:07:53 ripapi weewx[17576]: File 
"/usr/share/weewx/user/ws3000.py", line 359, in _get_raw_data
Oct 26 15:07:53 ripapi weewx[17576]:   raise 
weewx.IO_ERROR("Error while fetching " + self._get_cmd_name(hex_command))
Oct 26 15:07:53 ripapi weewx[17576]:   TypeError: 'int' object is 
not callable
Oct 26 15:07:53 ripapi weewx[17576]:   Exiting.

-> Can you point out what's possibly wrong?

usbtest.py:

rhk@ripapi ~ $ sudo python usbtest.py
Starting tests...
ws3000_write: entry
Detecting device...
Device found
Sending control packet
Sending command:  [123, 65, 64, 125, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
An error occurred: (, USBError(110, u'Operation 
timed out'), )
Traceback (most recent call last):
  File "usbtest.py", line 54, in ws3000_write
data = device.read(0x82, 64, 100)
  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 988, in 
read
self.__get_timeout(timeout))
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", 
line 851, in intr_read
timeout)
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", 
line 936, in __read
_check(retval)
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", 
line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
USBError: [Errno 110] Operation timed out
Tests completed

[weewx-user] Re: Connect Froggit WH3000SE weatherstation to weewx

[Bernd Mohr]

Hey Ronald,

sorry, I was on vacation the past two weeks :-) 

Ok, I´ll give it a try to explain you my method in English. (I´m from 
Germany, so please have indulgence if one or the other sentence sounds 
funny for you) :-)

Let´s try with the Basics: Your Froggit WH4000 is up and running and 
connected to your router, correct? And you are running weewx somewhere in 
your network.
For the installation of weewx I do not go into detail now, because there 
are enough instructions on the internet ;-)

if so, you have to "catch" the Wifi Packages between your console and your 
router. In my case I had to buy another router (Asus rt-66u) because my 
actual router can´t handle ip tables.
Your console send´s the data packages via port 80 to your router. After I 
know that, I installed wrt Merlin Firmware to my Asus router. 
After that, logon to your router and enable under administration --> system 
--> JFFS custom scripts or in case of another router, the ability to handle 
iptables. 
now you have to send the weather data packages to your weewx server. (In my 
case Raspberry Pi 3+).
it is important to send both kinds of packages like this:

iptables -t mangle -A PREROUTING  -s 192.168.1.33 -j ROUTE --tee --gw 
192.168.1.76

iptables -t mangle -A POSTROUTING -d 192.168.1.33 -j ROUTE --tee --gw 
192.168.1.76


In this case the first ip is my WH3000 Console, and the second one is my 
weewx server. Please replace it to your ip adresses ;-) 

Of course, at this point it is very useful if you give your router in your 
router and the weewx server a fixed ip address.


To be able to parse this weather packages on your weewx server, you habe to 
install and enable the interceptor driver. 

I hope you are familiar with Linux console? If so, it is easy for you to 
install the interceptor driver. In my case I used the following manual:


https://github.com/matthewwall/weewx-interceptor


Little hint: At point 2, as I remember, the name of the package was wrong. 
Maybe you have to delete the last word -master to install the driver. 

Please, give it a try ;-) 


Now you have to configure the weewx interceptor driver in your weewx.conf 
You have to change station_type like this:

 station_type = Interceptor


and at the end of weewx.conf copy and paste this part here: (Replace the ip 
adress of your console)


[Interceptor]

# This section is for the network traffic interceptor driver.



# The driver to use:

driver = user.interceptor



# Specify the hardware device to capture.  Options include:

#   acurite-bridge - acurite internet bridge

#   observer - fine offset WH2600/HP1000/HP1003, aka 'observer'

#   lw30x - oregon scientific LW301/LW302

#   lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge

device_type = observer

mode = sniff

iface = eth0

pcap_filter = src 192.168.1.33 and dst port 80


To check if everything is working fine, you can set the parameter: debug = 
1 in your weewx.conf

In best case, when you have a look at your syslog, you can see a lot of 
weather data packages ;-)

To have a look at syslog --> tail -f /var/log/syslog 


Please remember you have to restart weewx after changing the weewx.conf to 
take effect.


i think, this is the most important part for the beginning. I optimized 
other little things for a durable running. 

Please do not hesitate to ask further questions, I´ll try to help you if I 
can :-)


Cheers,


Bernd 



22/5000

-- 
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.
For more options, visit https://groups.google.com/d/optout.