Re: [weewx-user] re: "AttributeError: tuype object 'ImageDraw' has no attribute 'textsize'"

[Sam Finn]

Thanks again. Backing-off to 9.4.0, and using the modified sqlite.py to 
take care of the missing RADIAN function, has apparently done the trick!

Best - 

Sam

On Sunday, July 2, 2023 at 5:50:12 PM UTC-6 Tom Keffer wrote:

> Oops. Foiled by Issue #862 <https://github.com/weewx/weewx/issues/862>!
>
> Try an even earlier version of Pillow. Say, 9.4.0.
>
> -tk
>
> On Sun, Jul 2, 2023 at 4:39 PM Sam Finn  wrote:
>
>> Hi Tom - 
>>
>> Thanks much! I was running w/Pillow 10.0. I backed-off to 9.5.0 but am 
>> not getting a different error: 
>>
>> *weewx* sudo bin/wee_reports weewx.conf
>>
>> Generating as of last timestamp in the database.
>>
>> Using configuration file weewx.conf
>>
>> Traceback (most recent call last):
>>
>>   File "/Users/Shared/weewx/bin/weewx/reportengine.py", line 197, in run
>>
>> obj.start()
>>
>>   File "/Users/Shared/weewx/bin/weewx/reportengine.py", line 385, in start
>>
>> self.run()
>>
>>   File "/Users/Shared/weewx/bin/weewx/imagegenerator.py", line 42, in run
>>
>> self.gen_images(self.gen_ts)
>>
>>   File "/Users/Shared/weewx/bin/weewx/imagegenerator.py", line 114, in 
>> gen_images
>>
>> image = plot.render()
>>
>>   File "/Users/Shared/weewx/bin/weeplot/genplot.py", line 222, in render
>>
>> self._renderDayNight(sdraw)
>>
>>   File "/Users/Shared/weewx/bin/weeplot/genplot.py", line 266, in 
>> _renderDayNight
>>
>> sdraw.rectangle(((xleft,self.yscale[0]),
>>
>>   File "/Users/Shared/weewx/bin/weeplot/utilities.py", line 442, in 
>> rectangle
>>
>> self.draw.rectangle(box_scaled, **options)
>>
>>   File "/Library/Python/3.9/site-packages/PIL/ImageDraw.py", line 294, in 
>> rectangle
>>
>> self.draw.draw_rectangle(xy, fill, 1)
>>
>> ValueError: y1 must be greater than or equal to y0
>>
>> Are there further suggestions? 
>>
>> Again, thanks!
>>
>> Sam
>> On Sunday, July 2, 2023 at 4:10:30 PM UTC-6 Tom Keffer wrote:
>>
>>> This is a known problem caused by a change in Pillow, the imaging 
>>> library used by WeeWX.
>>>
>>> If you're on a Mac, you probably installed Pillow using pip. See what 
>>> version of Pillow you have by using these two methods.
>>>
>>> *python3 -m pip list -v*
>>>
>>> *python3 -c "import PIL;print(PIL.__version__)"*
>>>
>>>
>>> If it's 10.0, then this is the problem. The solution is to downgrade 
>>> your copy:
>>>
>>> *python3 -m pip install Pillow==9.5.0*
>>>
>>>
>>> If it's earlier than 10.0, then it's some other problem.
>>>
>>> -tk
>>>
>>>
>>> On Sun, Jul 2, 2023 at 2:30 PM Sam Finn  wrote:
>>>
>>>> Hi - 
>>>>
>>>> I'm hoping someone can help me get my weewx install working again. 
>>>>
>>>> Some time ago (last April) weewx stopped updating my web page. [Many 
>>>> things have been going on and I am only now and able to get to this.] 
>>>> There 
>>>> might have been a Mac OS update at that time; however, I simply don't 
>>>> know. 
>>>> The weewx.log file is showing the error message "AttributeError: tuype 
>>>> object 'ImageDraw' has no attribute 'textsize'". 
>>>>
>>>> I've updated my weewx installation to 4.9.1 and am using the vanilla 
>>>> weewx.conf file with the minimum system (Vantage) configuration: i.e., no 
>>>> special skins, etc. The weewx.log file shows the same error. 
>>>>
>>>> To my untrained eye I've checked that my python3 installation is 
>>>> complete, at least as far as packages specified in the docs go. 
>>>>
>>>> Attached are
>>>> * the section of the weewx.log file for the most recent weewx run; 
>>>> * the [Station] section of the weewx.conf file
>>>>
>>>> I'm running Vantage Vue h/w (2018) with an old-style weatherlink 
>>>> console connected to my desktop over ethernet via a Davis datalogger (also 
>>>> 2018 vintage). 
>>>>
>>>> Thanks much for any help/guidance. 
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "weewx-user"

Re: [weewx-user] re: "AttributeError: tuype object 'ImageDraw' has no attribute 'textsize'"

[Sam Finn]

Hi Tom - 

Thanks much! I was running w/Pillow 10.0. I backed-off to 9.5.0 but am not 
getting a different error: 

*weewx* sudo bin/wee_reports weewx.conf

Generating as of last timestamp in the database.

Using configuration file weewx.conf

Traceback (most recent call last):

  File "/Users/Shared/weewx/bin/weewx/reportengine.py", line 197, in run

obj.start()

  File "/Users/Shared/weewx/bin/weewx/reportengine.py", line 385, in start

self.run()

  File "/Users/Shared/weewx/bin/weewx/imagegenerator.py", line 42, in run

self.gen_images(self.gen_ts)

  File "/Users/Shared/weewx/bin/weewx/imagegenerator.py", line 114, in 
gen_images

image = plot.render()

  File "/Users/Shared/weewx/bin/weeplot/genplot.py", line 222, in render

self._renderDayNight(sdraw)

  File "/Users/Shared/weewx/bin/weeplot/genplot.py", line 266, in 
_renderDayNight

sdraw.rectangle(((xleft,self.yscale[0]),

  File "/Users/Shared/weewx/bin/weeplot/utilities.py", line 442, in 
rectangle

self.draw.rectangle(box_scaled, **options)

  File "/Library/Python/3.9/site-packages/PIL/ImageDraw.py", line 294, in 
rectangle

self.draw.draw_rectangle(xy, fill, 1)

ValueError: y1 must be greater than or equal to y0

Are there further suggestions? 

Again, thanks!

Sam
On Sunday, July 2, 2023 at 4:10:30 PM UTC-6 Tom Keffer wrote:

> This is a known problem caused by a change in Pillow, the imaging library 
> used by WeeWX.
>
> If you're on a Mac, you probably installed Pillow using pip. See what 
> version of Pillow you have by using these two methods.
>
> *python3 -m pip list -v*
>
> *python3 -c "import PIL;print(PIL.__version__)"*
>
>
> If it's 10.0, then this is the problem. The solution is to downgrade your 
> copy:
>
> *python3 -m pip install Pillow==9.5.0*
>
>
> If it's earlier than 10.0, then it's some other problem.
>
> -tk
>
>
> On Sun, Jul 2, 2023 at 2:30 PM Sam Finn  wrote:
>
>> Hi - 
>>
>> I'm hoping someone can help me get my weewx install working again. 
>>
>> Some time ago (last April) weewx stopped updating my web page. [Many 
>> things have been going on and I am only now and able to get to this.] There 
>> might have been a Mac OS update at that time; however, I simply don't know. 
>> The weewx.log file is showing the error message "AttributeError: tuype 
>> object 'ImageDraw' has no attribute 'textsize'". 
>>
>> I've updated my weewx installation to 4.9.1 and am using the vanilla 
>> weewx.conf file with the minimum system (Vantage) configuration: i.e., no 
>> special skins, etc. The weewx.log file shows the same error. 
>>
>> To my untrained eye I've checked that my python3 installation is 
>> complete, at least as far as packages specified in the docs go. 
>>
>> Attached are
>> * the section of the weewx.log file for the most recent weewx run; 
>> * the [Station] section of the weewx.conf file
>>
>> I'm running Vantage Vue h/w (2018) with an old-style weatherlink console 
>> connected to my desktop over ethernet via a Davis datalogger (also 2018 
>> vintage). 
>>
>> Thanks much for any help/guidance. 
>>
>>
>>
>>
>> -- 
>> 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/704f5d10-8c3a-4727-85bb-ec3e616aeba5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/704f5d10-8c3a-4727-85bb-ec3e616aeba5n%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/749c7cc7-aa01-4aa8-83fa-55dca8d06619n%40googlegroups.com.

[weewx-user] re: "AttributeError: tuype object 'ImageDraw' has no attribute 'textsize'"

[Sam Finn]

Hi - 

I'm hoping someone can help me get my weewx install working again. 

Some time ago (last April) weewx stopped updating my web page. [Many things 
have been going on and I am only now and able to get to this.] There might 
have been a Mac OS update at that time; however, I simply don't know. The 
weewx.log file is showing the error message "AttributeError: tuype object 
'ImageDraw' has no attribute 'textsize'". 

I've updated my weewx installation to 4.9.1 and am using the vanilla 
weewx.conf file with the minimum system (Vantage) configuration: i.e., no 
special skins, etc. The weewx.log file shows the same error. 

To my untrained eye I've checked that my python3 installation is complete, 
at least as far as packages specified in the docs go. 

Attached are
* the section of the weewx.log file for the most recent weewx run; 
* the [Station] section of the weewx.conf file

I'm running Vantage Vue h/w (2018) with an old-style weatherlink console 
connected to my desktop over ethernet via a Davis datalogger (also 2018 
vintage). 

Thanks much for any help/guidance. 




-- 
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/704f5d10-8c3a-4727-85bb-ec3e616aeba5n%40googlegroups.com.
weewx[6831] DEBUG weewx.drivers.vantage: Getting archive packets since 
2023-07-02 14:30:00 MDT (1688329800)
weewx[6831] DEBUG weewx.drivers.vantage: Gentle wake up of console successful
weewx[6831] DEBUG weewx.drivers.vantage: Retrieving 1 page(s); starting index= 3
weewx[6831] INFO weewx.manager: Added record 2023-07-02 15:00:00 MDT 
(1688331600) to database 'weewx.sdb'
weewx[6831] INFO weewx.manager: Added record 2023-07-02 15:00:00 MDT 
(1688331600) to daily summary in 'weewx.sdb'
weewx[6831] DEBUG weewx.drivers.vantage: DMPAFT complete: page timestamp 
2023-05-10 06:00:00 MDT (168372) less than final timestamp 2023-07-02 
15:00:00 MDT (1688331600)
weewx[6831] DEBUG weewx.drivers.vantage: Catch up complete.
weewx[6831] DEBUG weewx.reportengine: Running reports for latest time in the 
database.
weewx[6831] DEBUG weewx.drivers.vantage: Requesting 200 LOOP packets.
weewx[6831] DEBUG weewx.reportengine: Running report 'SeasonsReport'
weewx[6831] DEBUG weewx.reportengine: Found configuration file 
/Users/Shared/weewx/skins/Seasons/skin.conf for report 'SeasonsReport'
weewx[6831] DEBUG weewx.reportengine: Cannot read localization file 
/Users/Shared/weewx/skins/Seasons/lang/en.conf for report 'SeasonsReport': 
Config file not found: "/Users/Shared/weewx/skins/Seasons/lang/en.conf".
weewx[6831] DEBUG weewx.reportengine:  Using defaults instead.
weewx[6831] DEBUG weewx.cheetahgenerator: Using search list 
['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Current', 
'weewx.cheetahgenerator.DisplayOptions', 'weewx.cheetahgenerator.Extras', 
'weewx.cheetahgenerator.Gettext', 'weewx.cheetahgenerator.JSONHelpers', 
'weewx.cheetahgenerator.PlotInfo', 'weewx.cheetahgenerator.SkinInfo', 
'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats', 
'weewx.cheetahgenerator.UnitInfo']
weewx[6831] DEBUG weewx.manager: Daily summary version is 4.0
weewx[6831] DEBUG weewx.drivers.vantage: Gentle wake up of console successful
weewx[6831] INFO weewx.cheetahgenerator: Generated 8 files for report 
SeasonsReport in 0.59 seconds
weewx[6831] DEBUG weewx.manager: Daily summary version is 4.0
weewx[6831] ERROR weewx.reportengine: Caught unrecoverable exception in 
generator 'weewx.imagegenerator.ImageGenerator'
weewx[6831] ERROR weewx.reportengine:   type object 'ImageDraw' has 
no attribute 'textsize'
weewx[6831] ERROR weewx.reportengine:   Traceback (most recent call 
last):

weewx[6831] ERROR weewx.reportengine: File 
"/Users/Shared/weewx/bin/weewx/reportengine.py", line 197, in run

weewx[6831] ERROR weewx.reportengine:   obj.start()

weewx[6831] ERROR weewx.reportengine: File 
"/Users/Shared/weewx/bin/weewx/reportengine.py", line 385, in start

weewx[6831] ERROR weewx.reportengine:   self.run()

weewx[6831] ERROR weewx.reportengine: File 
"/Users/Shared/weewx/bin/weewx/imagegenerator.py", line 42, in run

weewx[6831] ERROR weewx.reportengine:   
self.gen_images(self.gen_ts)

weewx[6831] ERROR weewx.reportengine: File 
"/Users/Shared/weewx/bin/weewx/imagegenerator.py", line 114, in gen_images

weewx[6831] ERROR weewx.reportengine:   image = plot.render()

weewx[6831] ERROR weewx.reportengine: File 
"/Users/Shared/weewx/bin/weeplot/genplot.py", line 212, in render

weewx[6831] ERROR weewx.reportengine:   self._renderBottom(draw)

weewx[6831] ERROR weewx.reportengine: File 

[weewx-user] Re: Suggestions for solar irradiance calculator on arbitrary tilted surface

[sam . ley]

 I work in the PV industry, though I don't have much experience with weewx 
yet, and limited experience with python. That said, the calculation you are 
looking for is called a "transposition", and you are transposing from GHI 
(Global Horizontal Irradiance) from your horizontal sensor to what is 
called POA (Plane of Array) irradiance. That may help a bit with your 
searching.

Sandia's PV Array Performance Model is a set of equations that can describe 
nearly every part of a PV system's behavior: 
https://pvpmc.sandia.gov/modeling-steps/1-weather-design-inputs/plane-of-array-poa-irradiance/

It is partially (completely?) implemented in Python in the pvlib library: 
https://pvlib-python.readthedocs.io/en/stable/

I haven't used the library, though I do use a lot of tools that include 
calculations from the Sandia PVAPM.

-- 
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] Internal Temp - WunderStation

[Sam Walton]

Hi All,

I have an IPad with Wunderstation installed, Has anyone successfully 
outputted the Internal Temp into Wunderground so I can see it in the app?

My Station details are:

Weewx 3.8
Oregon Scientific WMR300
Pi running Ubuntu Mate (Latest Version)
https://www.wunderground.com/personal-weather-station/dashboard?ID=INEWSOUT1234


Thanks!

Sam

-- 
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: WMR300 - Ubuntu Weather Undergroud wind direction

[Sam Walton]

Mwall,

Thanks so much! Seems to be displaying now! I'll test and let you know.

Thanks again

Sam

On Tuesday, March 6, 2018 at 4:45:03 PM UTC+11, mwall wrote:
>
> i thought this smelled familiar.  i think this problem was fixed at commit 
> 9164c08 on 24 dec 2017.
>
> please replace your wxservices.py with the latest:
>
>
> https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/wxservices.py
>
> then restart weewx.
>
> m
>

-- 
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: WMR300 - Ubuntu Weather Undergroud wind direction

[Sam Walton]

Thanks for the response. I noticed that too, It's weird when i was running 
Weewx on Raspbian i had no issues with rapid fire on. 

Happy to turn off and test!

Sam

On Tuesday, March 6, 2018 at 3:26:14 PM UTC+11, Andrew Milner wrote:
>
> From the logs the wind direction appears to be being uploaded when it is 
> available.  I know the wmr300 produces partial packets which do not always 
> seem to work well with rapid fire at WU.  I also see that you are giving 
> rapid fire updates at 1 second (or even less) intervals - yet the upload 
> says the interval is 2.5 seconds - this could be causing issues at the WU 
> end, and resulting in lost data (just a theory, since it does not take much 
> for WU to lose/drop data).
>
> Does it work OK if you turn rapid fire off and go to a 5 minute archive 
> interval??
>
> I'll leave this to Matthew as he knows FAR FAR more than me!!
>
>
>
> On Tuesday, 6 March 2018 06:13:39 UTC+2, Sam Walton wrote:
>
>> Attached are hopefully the correct logs!
>>
>> Thanks
>>
>> Sam
>>
>> On Tue, Mar 6, 2018 at 2:43 PM, Sam Walton <samuel@gmail.com> wrote:
>>
>>> My bad! I read the error again and noticed line 1 had the fault (must of 
>>> deleted the #) It is running now!
>>>
>>> I'll upload the logs asap
>>>
>>> Sam
>>>
>>>
>>> On Tuesday, March 6, 2018 at 2:40:24 PM UTC+11, Sam Walton wrote:
>>>>
>>>> Hi Andrew,
>>>>
>>>> I searched for debug_decode and could not find it. I added it to the 
>>>> section WMR300 and now when i start the service i get the error
>>>>
>>>> swalton@weather-station:~$ sudo /etc/init.d/weewx start
>>>> [ ok ] Starting weewx (via systemctl): weewx.service.
>>>> swalton@weather-station:~$ sudo /etc/init.d/weewx status
>>>> ● weewx.service - LSB: weewx weather system
>>>>Loaded: loaded (/etc/init.d/weewx; bad; vendor preset: enabled)
>>>>Active: active (exited) since Tue 2018-03-06 14:32:00 AEDT; 2s ago
>>>>  Docs: man:systemd-sysv-generator(8)
>>>>   Process: 2465 ExecStop=/etc/init.d/weewx stop (code=exited, 
>>>> status=0/SUCCESS)
>>>>   Process: 2522 ExecStart=/etc/init.d/weewx start (code=exited, 
>>>> status=0/SUCCESS)
>>>>
>>>> Mar 06 14:32:00 weather-station weewx[2522]:  * Starting weewx weather 
>>>> system weewx
>>>> Mar 06 14:32:00 weather-station weewx[2534]: engine: Initializing weewx 
>>>> version 3.8.0
>>>> Mar 06 14:32:00 weather-station weewx[2534]: engine: Using Python 
>>>> 2.7.12 (default, Dec  4 2017, 14:50:18)
>>>>  [GCC 5.4.0 20160609]
>>>> Mar 06 14:32:00 weather-station weewx[2534]: engine: Platform 
>>>> Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
>>>> Mar 06 14:32:00 weather-station weewx[2534]: engine: Locale is 
>>>> 'en_AU.UTF-8'
>>>> Mar 06 14:32:00 weather-station weewx[2534]: engine: pid file is 
>>>> /var/run/weewx.pid
>>>> Mar 06 14:32:00 weather-station weewx[2538]: engine: Error while 
>>>> parsing configuration file /etc/weewx/w...conf
>>>> Mar 06 14:32:00 weather-station weewx[2538]: Reason: 'Invalid 
>>>> line (' WEEWX CONFIGURATION FILE')... 1.'
>>>> Mar 06 14:32:00 weather-station weewx[2522]:...done.
>>>> Mar 06 14:32:00 weather-station systemd[1]: Started LSB: weewx weather 
>>>> system.
>>>> Hint: Some lines were ellipsized, use -l to show in full.
>>>> swalton@weather-station:~$ sudo tail -f /var/log/syslog
>>>> Mar  6 14:32:00 weather-station weewx[2534]: engine: Initializing weewx 
>>>> version 3.8.0
>>>> Mar  6 14:32:00 weather-station weewx[2534]: engine: Using Python 
>>>> 2.7.12 (default, Dec  4 2017, 14:50:18) #012[GCC 5.4.0 20160609]
>>>> Mar  6 14:32:00 weather-station weewx[2534]: engine: Platform 
>>>> Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
>>>> Mar  6 14:32:00 weather-station weewx[2534]: engine: Locale is 
>>>> 'en_AU.UTF-8'
>>>> Mar  6 14:32:00 weather-station weewx[2534]: engine: pid file is 
>>>> /var/run/weewx.pid
>>>> Mar  6 14:32:00 weather-station weewx[2538]: engine: Error while 
>>>> parsing configuration file /etc/weewx/weewx.conf
>>>> Mar  6 14:32:00 weather-station weewx[2538]: Reason: 'Invalid 
>>>> line (' WEEWX CONFIGURATION FILE') (matched as neither section nor

[weewx-user] Re: WMR300 - Ubuntu Weather Undergroud wind direction

[Sam Walton]

My bad! I read the error again and noticed line 1 had the fault (must of 
deleted the #) It is running now!

I'll upload the logs asap

Sam

On Tuesday, March 6, 2018 at 2:40:24 PM UTC+11, Sam Walton wrote:
>
> Hi Andrew,
>
> I searched for debug_decode and could not find it. I added it to the 
> section WMR300 and now when i start the service i get the error
>
> swalton@weather-station:~$ sudo /etc/init.d/weewx start
> [ ok ] Starting weewx (via systemctl): weewx.service.
> swalton@weather-station:~$ sudo /etc/init.d/weewx status
> ● weewx.service - LSB: weewx weather system
>Loaded: loaded (/etc/init.d/weewx; bad; vendor preset: enabled)
>Active: active (exited) since Tue 2018-03-06 14:32:00 AEDT; 2s ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 2465 ExecStop=/etc/init.d/weewx stop (code=exited, 
> status=0/SUCCESS)
>   Process: 2522 ExecStart=/etc/init.d/weewx start (code=exited, 
> status=0/SUCCESS)
>
> Mar 06 14:32:00 weather-station weewx[2522]:  * Starting weewx weather 
> system weewx
> Mar 06 14:32:00 weather-station weewx[2534]: engine: Initializing weewx 
> version 3.8.0
> Mar 06 14:32:00 weather-station weewx[2534]: engine: Using Python 2.7.12 
> (default, Dec  4 2017, 14:50:18)
>  [GCC 5.4.0 20160609]
> Mar 06 14:32:00 weather-station weewx[2534]: engine: Platform 
> Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
> Mar 06 14:32:00 weather-station weewx[2534]: engine: Locale is 
> 'en_AU.UTF-8'
> Mar 06 14:32:00 weather-station weewx[2534]: engine: pid file is 
> /var/run/weewx.pid
> Mar 06 14:32:00 weather-station weewx[2538]: engine: Error while parsing 
> configuration file /etc/weewx/w...conf
> Mar 06 14:32:00 weather-station weewx[2538]: Reason: 'Invalid line 
> (' WEEWX CONFIGURATION FILE')... 1.'
> Mar 06 14:32:00 weather-station weewx[2522]:...done.
> Mar 06 14:32:00 weather-station systemd[1]: Started LSB: weewx weather 
> system.
> Hint: Some lines were ellipsized, use -l to show in full.
> swalton@weather-station:~$ sudo tail -f /var/log/syslog
> Mar  6 14:32:00 weather-station weewx[2534]: engine: Initializing weewx 
> version 3.8.0
> Mar  6 14:32:00 weather-station weewx[2534]: engine: Using Python 2.7.12 
> (default, Dec  4 2017, 14:50:18) #012[GCC 5.4.0 20160609]
> Mar  6 14:32:00 weather-station weewx[2534]: engine: Platform 
> Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
> Mar  6 14:32:00 weather-station weewx[2534]: engine: Locale is 
> 'en_AU.UTF-8'
> Mar  6 14:32:00 weather-station weewx[2534]: engine: pid file is 
> /var/run/weewx.pid
> Mar  6 14:32:00 weather-station weewx[2538]: engine: Error while parsing 
> configuration file /etc/weewx/weewx.conf
> Mar  6 14:32:00 weather-station weewx[2538]: Reason: 'Invalid line 
> (' WEEWX CONFIGURATION FILE') (matched as neither section nor keyword) at 
> line 1.'
> Mar  6 14:32:00 weather-station weewx[2522]:...done.
> Mar  6 14:32:00 weather-station systemd[1]: Started LSB: weewx weather 
> system.
> Mar  6 14:33:44 weather-station rsyslogd-2007: action 'action 10' 
> suspended, next retry is Tue Mar  6 14:34:14 2018 [v8.16.0 try 
> http://www.rsyslog.com/e/2007 ]
>
>
> Here is the snippet from the config
>
>
> ##
>
> # This section is for general configuration information.
>
> # Set to 1 for extra debug info, otherwise comment it out or set to zero
> debug = 2
>
> # Root directory of the weewx data file hierarchy for this station
> WEEWX_ROOT = /
>
> # How long to wait before timing out a socket (FTP, HTTP) connection
> socket_timeout = 20
>
> # Do not modify this. It is used when installing and updating weewx.
> version = 3.8.0
>
>
> ##
>
>
> ##
>
> [WMR300]
> # This section is for WMR300 weather stations.
>
> # The station model, e.g., WMR300A
> model = WMR300
>
> # The driver to use:
> driver = weewx.drivers.wmr300
>
> debug_decode = 1
>
> ##
>
> Sorry i'm quite new to Weewx!
>
> Sam
>
>
> On Tuesday, March 6, 2018 at 2:02:28 PM UTC+11, Andrew Milner wrote:
>>
>> Sam - I think Matthew is saying that:
>> a)  The main weewx.conf debug statement near the start of weewx.conf 
>> should say debug = 2 to invoke more detailed weewx logging
>> AND
>> b) There should be a line within the WMR300 section - add it if necessary 
>> - saying debug_decode = 1 to force

[weewx-user] Re: WMR300 - Ubuntu Weather Undergroud wind direction

[Sam Walton]

Hi Andrew,

I searched for debug_decode and could not find it. I added it to the 
section WMR300 and now when i start the service i get the error

swalton@weather-station:~$ sudo /etc/init.d/weewx start
[ ok ] Starting weewx (via systemctl): weewx.service.
swalton@weather-station:~$ sudo /etc/init.d/weewx status
● weewx.service - LSB: weewx weather system
   Loaded: loaded (/etc/init.d/weewx; bad; vendor preset: enabled)
   Active: active (exited) since Tue 2018-03-06 14:32:00 AEDT; 2s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 2465 ExecStop=/etc/init.d/weewx stop (code=exited, 
status=0/SUCCESS)
  Process: 2522 ExecStart=/etc/init.d/weewx start (code=exited, 
status=0/SUCCESS)

Mar 06 14:32:00 weather-station weewx[2522]:  * Starting weewx weather 
system weewx
Mar 06 14:32:00 weather-station weewx[2534]: engine: Initializing weewx 
version 3.8.0
Mar 06 14:32:00 weather-station weewx[2534]: engine: Using Python 2.7.12 
(default, Dec  4 2017, 14:50:18)
 [GCC 5.4.0 20160609]
Mar 06 14:32:00 weather-station weewx[2534]: engine: Platform 
Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
Mar 06 14:32:00 weather-station weewx[2534]: engine: Locale is 'en_AU.UTF-8'
Mar 06 14:32:00 weather-station weewx[2534]: engine: pid file is 
/var/run/weewx.pid
Mar 06 14:32:00 weather-station weewx[2538]: engine: Error while parsing 
configuration file /etc/weewx/w...conf
Mar 06 14:32:00 weather-station weewx[2538]: Reason: 'Invalid line 
(' WEEWX CONFIGURATION FILE')... 1.'
Mar 06 14:32:00 weather-station weewx[2522]:...done.
Mar 06 14:32:00 weather-station systemd[1]: Started LSB: weewx weather 
system.
Hint: Some lines were ellipsized, use -l to show in full.
swalton@weather-station:~$ sudo tail -f /var/log/syslog
Mar  6 14:32:00 weather-station weewx[2534]: engine: Initializing weewx 
version 3.8.0
Mar  6 14:32:00 weather-station weewx[2534]: engine: Using Python 2.7.12 
(default, Dec  4 2017, 14:50:18) #012[GCC 5.4.0 20160609]
Mar  6 14:32:00 weather-station weewx[2534]: engine: Platform 
Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
Mar  6 14:32:00 weather-station weewx[2534]: engine: Locale is 'en_AU.UTF-8'
Mar  6 14:32:00 weather-station weewx[2534]: engine: pid file is 
/var/run/weewx.pid
Mar  6 14:32:00 weather-station weewx[2538]: engine: Error while parsing 
configuration file /etc/weewx/weewx.conf
Mar  6 14:32:00 weather-station weewx[2538]: Reason: 'Invalid line 
(' WEEWX CONFIGURATION FILE') (matched as neither section nor keyword) at 
line 1.'
Mar  6 14:32:00 weather-station weewx[2522]:...done.
Mar  6 14:32:00 weather-station systemd[1]: Started LSB: weewx weather 
system.
Mar  6 14:33:44 weather-station rsyslogd-2007: action 'action 10' 
suspended, next retry is Tue Mar  6 14:34:14 2018 [v8.16.0 try 
http://www.rsyslog.com/e/2007 ]


Here is the snippet from the config

##

# This section is for general configuration information.

# Set to 1 for extra debug info, otherwise comment it out or set to zero
debug = 2

# Root directory of the weewx data file hierarchy for this station
WEEWX_ROOT = /

# How long to wait before timing out a socket (FTP, HTTP) connection
socket_timeout = 20

# Do not modify this. It is used when installing and updating weewx.
version = 3.8.0

##

##

[WMR300]
# This section is for WMR300 weather stations.

# The station model, e.g., WMR300A
model = WMR300

# The driver to use:
driver = weewx.drivers.wmr300

debug_decode = 1
##

Sorry i'm quite new to Weewx!

Sam


On Tuesday, March 6, 2018 at 2:02:28 PM UTC+11, Andrew Milner wrote:
>
> Sam - I think Matthew is saying that:
> a)  The main weewx.conf debug statement near the start of weewx.conf 
> should say debug = 2 to invoke more detailed weewx logging
> AND
> b) There should be a line within the WMR300 section - add it if necessary 
> - saying debug_decode = 1 to force more detailed logging from the driver 
> itself
>
>
> On Tuesday, 6 March 2018 03:47:48 UTC+2, Sam Walton wrote:
>
>> Hi Mwall,
>>
>> I don't have the line in the config file for "debug_decode" do i add it 
>> in? I tried to add the line into the config under the driver section but 
>> the service fails to start.
>>
>> Sam
>>
>> On Tuesday, March 6, 2018 at 12:32:59 PM UTC+11, mwall wrote:
>>>
>>>
>>>
>>> On Monday, March 5, 2018 at 8:46:45 AM UTC-5, Sam Walton wrote:
>>>>
>>>> Hi Mwall,
>>>>
>>>> I've set the config to debug_decode = 1 Attached is the putty

[weewx-user] Re: WMR300 - Ubuntu Weather Undergroud wind direction

[Sam Walton]

Hi Mwall,

I don't have the line in the config file for "debug_decode" do i add it in? 
I tried to add the line into the config under the driver section but the 
service fails to start.

Sam

On Tuesday, March 6, 2018 at 12:32:59 PM UTC+11, mwall wrote:
>
>
>
> On Monday, March 5, 2018 at 8:46:45 AM UTC-5, Sam Walton wrote:
>>
>> Hi Mwall,
>>
>> I've set the config to debug_decode = 1 Attached is the putty dump. I've 
>> also attached a screen shot of the Weewx local site.
>>
>> Sam 
>>
>
> sam,
>
> i am confused.  
>
> that does not look like the previous log output - there are no messages 
> about wu uploads, and there are no messages from the wmr300 driver.
>
> your weewx.conf should have the following in it:
>
> debug = 2
> ...
> [WMR300]
> ...
> debug_decode = 1
>
> m
>  
>
>

-- 
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: WMR300 - Ubuntu Weather Undergroud wind direction

[Sam Walton]

Hi Mwall,

I've set the config to debug_decode = 1 Attached is the putty dump. I've 
also attached a screen shot of the Weewx local site.

Sam 

On Monday, March 5, 2018 at 11:37:00 PM UTC+11, mwall wrote:
>
> sam,
>
> in weewx.conf, enable debug_decode like this:
>
> [WMR300]
> debug_decode = 1
>
> then restart weewx and post about 10 minutes of the resulting log.
>
> it is odd that winddir would be reported for regular weewx reports but not 
> for wu, so lets find out exactly what the driver is sending out.
>
> m
>

-- 
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.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2018.03.06 00:32:39 =~=~=~=~=~=~=~=~=~=~=~=
login as: swalton
swalton@192.168.1.3's password: 
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.38-v7+ armv7l)

 * Documentation:  https://help.ubuntu.com
 * Management: https://landscape.canonical.com
 * Support:https://ubuntu.com/advantage

34 packages can be updated.
2 updates are security updates.

Last login: Tue Mar  6 00:10:19 2018 from 192.168.1.8

]0;swalton@weather-station: ~swalton@weather-station:~$ 
]0;swalton@weather-station: ~swalton@weather-station:~$ 
]0;swalton@weather-station: ~swalton@weather-station:~$ 
]0;swalton@weather-station: ~swalton@weather-station:~$ sudo nano 
/etc/weewx/weewx.conf/etc/init.d/weewx 
stoptail -f /var/log/syslog 
[sudo] password for swalton: 
Mar  6 00:31:19 weather-station weewx[3350]: wmr300: rain=0.254 rain_total=8.89 
last_rain=8.636
Mar  6 00:31:19 weather-station rsyslogd-2007: action 'action 10' suspended, 
next retry is Tue Mar  6 00:32:49 2018 [v8.16.0 try 
http://www.rsyslog.com/e/2007 ]
Mar  6 00:31:54 weather-station systemd[1]: Stopping LSB: weewx weather 
system...
Mar  6 00:31:54 weather-station weewx[3401]:  * Stopping weewx weather system 
weewx
Mar  6 00:31:54 weather-station weewx[3350]: engine: Shutting down StdReport 
thread
Mar  6 00:31:54 weather-station weewx[3350]: engine: Terminating weewx version 
3.8.0
Mar  6 00:31:59 weather-station weewx[3401]: .   ...done.
Mar  6 00:31:59 weather-station systemd[1]: Stopped LSB: weewx weather system.
Mar  6 00:32:46 weather-station systemd[1]: Started Session c5 of user swalton.
Mar  6 00:33:23 weather-station rsyslogd-2007: action 'action 10' suspended, 
next retry is Tue Mar  6 00:34:53 2018 [v8.16.0 try 
http://www.rsyslog.com/e/2007 ]
Mar  6 00:33:30 weather-station systemd[1]: Starting LSB: weewx weather 
system...
Mar  6 00:33:30 weather-station weewx[3534]:  * Starting weewx weather system 
weewx
Mar  6 00:33:30 weather-station weewx[3546]: engine: Initializing weewx version 
3.8.0
Mar  6 00:33:30 weather-station weewx[3546]: engine: Using Python 2.7.12 
(default, Dec  4 2017, 14:50:18) #012[GCC 5.4.0 20160609]
Mar  6 00:33:30 weather-station weewx[3546]: engine: Platform 
Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
Mar  6 00:33:30 weather-station weewx[3546]: engine: Locale is 'en_AU.UTF-8'
Mar  6 00:33:30 weather-station weewx[3546]: engine: pid file is 
/var/run/weewx.pid
Mar  6 00:33:30 weather-station weewx[3550]: engine: Using configuration file 
/etc/weewx/weewx.conf
Mar  6 00:33:30 weather-station weewx[3550]: engine: debug is 1
Mar  6 00:33:30 weather-station weewx[3550]: engine: Initializing engine
Mar  6 00:33:30 weather-station weewx[3550]: engine: Loading station type 
WMR300 (weewx.drivers.wmr300)
Mar  6 00:33:30 weather-station weewx[3534]:...done.
Mar  6 00:33:30 weather-station systemd[1]: Started LSB: weewx weather system.
Mar  6 00:33:30 weather-station weewx[3550]: wmr300: driver version is 0.19rc5
Mar  6 00:33:30 weather-station weewx[3550]: wmr300: usb info: 
pyusb_version=1.0.0b2
Mar  6 00:33:30 weather-station weewx[3550]: wmr300: sensor map is 
{'outHumidity': 'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 
'windchill', 'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 
'heatindex': 'heatindex_1', 'inTemp': 'temperature_0', 'windGustDir': 
'wind_gust_dir', 'extraDewpoint2': 'dewpoint_3', 'extraDewpoint3': 
'dewpoint_4', 'extraDewpoint1': 'dewpoint_2', 'barometer': 'barometer', 
'extraDewpoint7': 'dewpoint_8', 'dewpoint': 'dewpoint_1', 'extraDewpoint5': 
'dewpoint_6', 'extraHumid6': 'humidity_7', 'pressure': 'pressure', 
'extraHumid4': 'humidity_5', 'extraHumid5': 'humidity_6', 'extraHumid2': 
'humidity_3', 'extraHumid3': 'humidity_4', 'extraHumid1': 'humidity_2', 
'extraTemp6': 'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4': 
'temperature_5', 'extraTemp5': 'temperature_6', 'extraTemp2': 'temperature_3', 
'extraTemp3': 'temperature_4', 'extraTemp1': 'temperature_2', 
'extraHeatindex3': 'heatindex_4', 'extraHeati

[weewx-user] WMR300 - Ubuntu Weather Undergroud wind direction

[Sam Walton]

Hi Guys

I've noticed that WU is not displaying wind direction. It seems to be 
displaying on the weewx local site but not WU. I did not have this problem 
running Weewx on Raspbian before and I'm guessing its a driver issue.  I've 
run: sudo wget 
https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/wmr300.py
 
and downloaded the latest driver.

Attached is some debug logs and I've noticed that rapid fire isn't sending 
the direction logs all the time.

PI: Ubuntu 16.04.4 LTS (GNU/Linux 4.4.38-v7+ armv7l)
The Weatherstation is: Oregon Scientific WMR300
WU Link: 
https://www.wunderground.com/personal-weather-station/dashboard?ID=INEWSOUT1234 

Thanks again

Sam

-- 
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.
Feb 26 22:08:03 weather-station systemd
Feb 26 22:31:13 weather-station systemd[1]: Starting LSB: weewx weather 
system...
Feb 26 22:31:13 weather-station weewx[2196]:  * Starting weewx weather system 
weewx
Feb 26 22:31:13 weather-station weewx[2208]: engine: Initializing weewx version 
3.8.0
Feb 26 22:31:13 weather-station weewx[2208]: engine: Using Python 2.7.12 
(default, Dec  4 2017, 14:50:18) #012[GCC 5.4.0 20160609]
Feb 26 22:31:13 weather-station weewx[2208]: engine: Platform 
Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
Feb 26 22:31:13 weather-station weewx[2208]: engine: Locale is 'en_AU.UTF-8'
Feb 26 22:31:13 weather-station weewx[2208]: engine: pid file is 
/var/run/weewx.pid
Feb 26 22:31:13 weather-station weewx[2212]: engine: Using configuration file 
/etc/weewx/weewx.conf
Feb 26 22:31:13 weather-station weewx[2212]: engine: debug is 2
Feb 26 22:31:13 weather-station weewx[2212]: engine: Initializing engine
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading station type 
WMR300 (weewx.drivers.wmr300rc3)
Feb 26 22:31:13 weather-station weewx[2196]:...done.
Feb 26 22:31:13 weather-station systemd[1]: Started LSB: weewx weather system.
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: driver version is 0.19rc3
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: usb info: 
pyusb_version=1.0.0b2
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: sensor map is 
{'outHumidity': 'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 
'windchill', 'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 'hea', 
'inTemp': 'temperature_0', 'windGustDir': 'wind_gust_dir', 'extraDewpoint2': 
'dewpoint_3', 'extraDewpoint3': 'dewpoint_4', 'extraDewpoint1': 'dewpoint_2', 
'barometer': 'barometer', 'extraDewpoint7': 'dewpoint_8', _1', 
'extraDewpoint5': 'dewpoint_6', 'extraHumid6': 'humidity_7', 'pressure': 
'pressure', 'extraHumid4': 'humidity_5', 'extraHumid5': 'humidity_6', 
'extraHumid2': 'humidity_3', 'extraHumid3': 'humidity_4', 'extraHumixtraTemp6': 
'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4': 'temperature_5', 
'extraTemp5': 'temperature_6', 'extraTemp2': 'temperature_3', 'extraTemp3': 
'temperature_4', 'extraTemp1': 'temperature_2', 'atindex_4', 'extraHeatindex2': 
'heatindex_3', 'extraHeatindex1': 'heatindex_2', 'extraHeatindex7': 
'heatindex_8', 'extraHeatindex6': 'heatindex_7', 'extraHeatindex5': 
'heatindex_6', 'extraHumid7': 'humidity_8', 'extrdex_5', 'windDir': 'wind_dir', 
'outTemp': 'temperature_1', 'windSpeed': 'wind_avg', 'inHumidity': 
'humidity_0', 'windGust': 'wind_gust'}
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: history limit is 20%
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: Found station at bus= 
device=
Feb 26 22:31:13 weather-station kernel: [ 1088.247613] usb 1-1.3: reset 
full-speed USB device number 9 using dwc_otg
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: communication established: 
{'station_model': 'A004', 'latest_index': 65, 'station_type': 'WMR300', 
'mystery1': 44, 'mystery0': 82, 'history_cleared': False, 'magic6, 
'packet_type': 87}
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading service 
weewx.engine.StdTimeSynch
Feb 26 22:31:13 weather-station weewx[2212]: engine: Finished loading service 
weewx.engine.StdTimeSynch
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading service 
weewx.engine.StdConvert
Feb 26 22:31:13 weather-station weewx[2212]: engine: StdConvert target unit is 
0x1
Feb 26 22:31:13 weather-station weewx[2212]: engine: Finished loading service 
weewx.engine.StdConvert
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading service 
weewx.engine.StdCalibrate
Feb 26 22:31:13 weather-station weewx[2212]: engine: Finished loading service 
weewx.engine.StdCalibrate
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading service 
weewx.engine.StdQC
Feb 26 22:31:13 weather-station weewx[2212]: engine: Finished loading service 
weewx.engine.StdQC
Feb 26 22:31:13 weather-station weewx[221

[weewx-user] Re: wmr300 avg winddir and wind

[Sam Walton]

Hi Gary

I've noticed that WU is not displaying wind direction too. It seems to be 
displaying on the weewx local site but not WU. I did not have this problem 
running Weewx on Raspbian before and I'm guessing its a driver issue. I've 
followed your instructions and downloaded the latest update to the driver. 

Attached is some debug logs and I've noticed that rapid fire isn't sending 
the direction logs all the time.

PI: Ubuntu 16.04.4 LTS (GNU/Linux 4.4.38-v7+ armv7l)
The Weatherstation is: Oregon Scientific WMR300
WU Link: 
https://www.wunderground.com/personal-weather-station/dashboard?ID=INEWSOUT1234 

Thanks again

Sam

On Tuesday, January 23, 2018 at 7:29:40 PM UTC+11, gjr80 wrote:
>
> Hi,
>
> A few things to consider:
>
> (1) The WMR300 driver is still being actively worked on so there is a 
> possibility it may still have some bugs.
>
> (2) Noting point 1, are you using the latest version of the WMR300 driver 
> or just the version included in the weeWX release you are using? The WMR300 
> driver in the latest weeWX release was v0.18 (not sure what version of 
> weeWX you are using), there have been 4 commits since then and the driver 
> is currenly at v0.19rc4. You can use something like this to download the 
> latest version of the driver:
>
> $ cd /usr/share/weewx/weewx/drivers
> $ sudo mv wmr300.py wmr300.py.orig
> $ sudo wget https:
> //raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/wmr300.py 
> <https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/almanac.py>
>
> to use the new driver just stop then start weeWX. If you have problems 
> just delete wmr300.py and rename the .orig copy to revert to your original 
> driver.
>
> (3) The WMR300 emits what is known as partial loop packets ie the loop 
> packets do not contain all observations. WU has issues if it receives data 
> that does not contain all fields, so when using rapidfire partial packet 
> stations usually do not produce the desired result. In an attempt to deal 
> with this the weeWX WU uploader uses caching of loop packets so even though 
> the WMR300 emits partial packets rapidfire should work. There have been 
> some issue with this caching since it was implemented so it is possible 
> some issues remain.
>
> (4) The real test is to monitor the data being sent to WU by weeWX. This 
> can achieved by editing weewx.conf and setting debug = 2, save weewx.conf 
> then stop/start weeWX. If you monitor the log you will see the data being 
> sent by weeWX to WU. If the correct data is there the issue is WU, if not 
> then its most likely the driver/station. If in any doubt post the log from 
> weeWX startup, don't delete anything.
>
> (5) You can run weeWX directly 
> <http://weewx.com/docs/usersguide.htm#Running_directly> to monitor the 
> loop data being generated by weeWX and the driver. It might be worthwhile 
> to do this and see whether you are getting the 2.5 second wind updates you 
> think you are. The loop data is on the lines starting with LOOP:, feel free 
> to post a screen capture of the output if you have trouble interpreting it.
>
> Gary 
>
> On Tuesday, 23 January 2018 17:52:07 UTC+10, sina...@gmail.com wrote:
>>
>> weewx and underground im talking about, the wind gust updates every 2.5 
>> seconds but wind and wind direction updates every 5 minute..
>>
>> 22 Ocak 2018 Pazartesi 14:19:48 UTC+3 tarihinde Andrew Milner yazdı:
>>>
>>> are you talking about a problem between the weather station and weewx, 
>>> or between weewx and wunderground? 
>>>
>>> since the wmr300 emits partial packets it is not really the best station 
>>> to be using rapid fire - I would suggest uploading just the archive 
>>> records, and not use rapidfire to get more consistent results.
>>>
>>> On Monday, 22 January 2018 13:14:56 UTC+2, Andrew Milner wrote:
>>>
>>>> i don't understand your exact problem - can you explain more please
>>>>
>>>>
>>>> On Monday, 22 January 2018 12:56:36 UTC+2, sina...@gmail.com wrote:
>>>>
>>>>> It is true, wind gust sends every 2.5 second but I cant say this for 
>>>>> wind and direction... :(
>>>>>
>>>>> 22 Ocak 2018 Pazartesi 12:17:03 UTC+3 tarihinde Andrew Milner yazdı:
>>>>>>
>>>>>> set rapidfire = True in wunderground section of weewx.conf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Monday, 22 January 2018 08:32:31 UTC+2, sina...@gmail.com wrote:
>>>>>>
>>>>>>> Hi, I am senior school student and I cant d

[weewx-user] Re: Oregon scientific WMR300 issues

[Sam Walton]

Hi Mwall,

Thanks for the driver. I've installed driver wmr300-0.19rc3 on my Ubuntu pi 
tonight and it is working well! 

Have you or anyone else noticed that WU is not displaying wind direction at 
the top? It seems to be recording it in the history and also on the weewx 
local site but not WU. I did not have this problem running Weewx on 
Raspbian before. 

Attached is some debug logs and I've noticed that rapid fire isn't sending 
the direction logs all the time.

The Weatherstation is: Oregon Scientific WMR300
WU Link: 
https://www.wunderground.com/personal-weather-station/dashboard?ID=INEWSOUT1234
 

Thanks again

Sam

On Tuesday, January 2, 2018 at 3:05:59 AM UTC+11, mwall wrote:
>
> alberto,
>
> thank you for testing!
>
> please try the attached wmr300-0.19rc3.py
>
> m
>
>
>

-- 
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.
Feb 26 22:08:03 weather-station systemd
Feb 26 22:31:13 weather-station systemd[1]: Starting LSB: weewx weather 
system...
Feb 26 22:31:13 weather-station weewx[2196]:  * Starting weewx weather system 
weewx
Feb 26 22:31:13 weather-station weewx[2208]: engine: Initializing weewx version 
3.8.0
Feb 26 22:31:13 weather-station weewx[2208]: engine: Using Python 2.7.12 
(default, Dec  4 2017, 14:50:18) #012[GCC 5.4.0 20160609]
Feb 26 22:31:13 weather-station weewx[2208]: engine: Platform 
Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
Feb 26 22:31:13 weather-station weewx[2208]: engine: Locale is 'en_AU.UTF-8'
Feb 26 22:31:13 weather-station weewx[2208]: engine: pid file is 
/var/run/weewx.pid
Feb 26 22:31:13 weather-station weewx[2212]: engine: Using configuration file 
/etc/weewx/weewx.conf
Feb 26 22:31:13 weather-station weewx[2212]: engine: debug is 2
Feb 26 22:31:13 weather-station weewx[2212]: engine: Initializing engine
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading station type 
WMR300 (weewx.drivers.wmr300rc3)
Feb 26 22:31:13 weather-station weewx[2196]:...done.
Feb 26 22:31:13 weather-station systemd[1]: Started LSB: weewx weather system.
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: driver version is 0.19rc3
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: usb info: 
pyusb_version=1.0.0b2
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: sensor map is 
{'outHumidity': 'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 
'windchill', 'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 'hea', 
'inTemp': 'temperature_0', 'windGustDir': 'wind_gust_dir', 'extraDewpoint2': 
'dewpoint_3', 'extraDewpoint3': 'dewpoint_4', 'extraDewpoint1': 'dewpoint_2', 
'barometer': 'barometer', 'extraDewpoint7': 'dewpoint_8', _1', 
'extraDewpoint5': 'dewpoint_6', 'extraHumid6': 'humidity_7', 'pressure': 
'pressure', 'extraHumid4': 'humidity_5', 'extraHumid5': 'humidity_6', 
'extraHumid2': 'humidity_3', 'extraHumid3': 'humidity_4', 'extraHumixtraTemp6': 
'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4': 'temperature_5', 
'extraTemp5': 'temperature_6', 'extraTemp2': 'temperature_3', 'extraTemp3': 
'temperature_4', 'extraTemp1': 'temperature_2', 'atindex_4', 'extraHeatindex2': 
'heatindex_3', 'extraHeatindex1': 'heatindex_2', 'extraHeatindex7': 
'heatindex_8', 'extraHeatindex6': 'heatindex_7', 'extraHeatindex5': 
'heatindex_6', 'extraHumid7': 'humidity_8', 'extrdex_5', 'windDir': 'wind_dir', 
'outTemp': 'temperature_1', 'windSpeed': 'wind_avg', 'inHumidity': 
'humidity_0', 'windGust': 'wind_gust'}
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: history limit is 20%
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: Found station at bus= 
device=
Feb 26 22:31:13 weather-station kernel: [ 1088.247613] usb 1-1.3: reset 
full-speed USB device number 9 using dwc_otg
Feb 26 22:31:13 weather-station weewx[2212]: wmr300: communication established: 
{'station_model': 'A004', 'latest_index': 65, 'station_type': 'WMR300', 
'mystery1': 44, 'mystery0': 82, 'history_cleared': False, 'magic6, 
'packet_type': 87}
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading service 
weewx.engine.StdTimeSynch
Feb 26 22:31:13 weather-station weewx[2212]: engine: Finished loading service 
weewx.engine.StdTimeSynch
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading service 
weewx.engine.StdConvert
Feb 26 22:31:13 weather-station weewx[2212]: engine: StdConvert target unit is 
0x1
Feb 26 22:31:13 weather-station weewx[2212]: engine: Finished loading service 
weewx.engine.StdConvert
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading service 
weewx.engine.StdCalibrate
Feb 26 22:31:13 weather-station weewx[2212]: engine: Finished loading service 
weewx.engine.StdCalibrate
Feb 26 22:31:13 weather-station weewx[2212]: engine: Loading service 
weewx.engine.StdQC

[weewx-user] Re: WMR300 driver - deleting history and other misc changes.

[Sam Walton]

Hi Cameron,

Thanks for the driver. I've installed it on my Ubuntu pi tonight and it is 
working well! 

Have you or anyone else noticed that WU is not displaying wind direction at 
the top? It seems to be recording it in the history and also on the weewx 
local site but not WU. I did not have this problem running Weewx on 
Raspbian before. 

Attached is some debug logs and I've noticed that rapid fire isn't sending 
the direction logs all the time.

The Weatherstation is: Oregon Scientific WMR300
WU 
Link: 
https://www.wunderground.com/personal-weather-station/dashboard?ID=INEWSOUT1234 

Thanks again

Sam



On Saturday, May 20, 2017 at 10:42:40 AM UTC+10, Cameron D wrote:
>
> Here is a version with the previous problem fixed.
>
> I have also included some diagnostic code that checks for the console 
> stopping reporting (as noted in the second post in this thread)
> If it gets no useful data in the 20 seconds between a6 hearbeats then it 
> sends a packet that I think restarts sending.
> This is redundant in most cases but it does not seem to cause a problem. 
> So far I have seen it triggered between zero and 5 times in a day.
>
> The diagnostics exposed some behaviour that I cannot explain. The normal 
> number of loop data packets sent within the 20 seconds heartbeat interval 
> is around 130. But every so often it drops dramatically and with a fairly 
> consistent pattern:
>
>- it is only the first 20 second block in each minute where loop data 
>stops, the 2nd and 3rd are normal
>- the number of loop data packets in the first block of the minute 
>gradually increases until it is similar to the other blocks, then the 
> cycle 
>restarts
>- the time interval of the long cycle is not constant, but varies 
>between 70 and 100 minutes.
>- at the moment I cannot tell if it is something in the driver that is 
>causing it, or if it is normal. At some time I will do some experimenting 
>and check the windows captures.
>
>
> Here is an edited snippet from my log file to illustrate the point:
>
> 18:21:53  Packets in heartbeat interval = 134
> 18:22:13  Packets in heartbeat interval = 135
> 18:22:34  Packets in heartbeat interval = 129
> 18:22:54  Packets in heartbeat interval = 135
> 18:23:14  Packets in heartbeat interval = 136
> 18:23:34  Packets in heartbeat interval = 133
> 18:23:54  Packets in heartbeat interval = 134
> 18:24:14  Packets in heartbeat interval = 134
> 18:24:34  Packets in heartbeat interval = 133
> 18:24:54  Packets in heartbeat interval = 134
> 18:25:14  Packets in heartbeat interval = 1
> 18:25:35  Packets in heartbeat interval = 137
> 18:25:55  Packets in heartbeat interval = 135
> 18:26:15  Packets in heartbeat interval = 6
> 18:26:35  Packets in heartbeat interval = 135
> 18:26:55  Packets in heartbeat interval = 135
> 18:27:15  Packets in heartbeat interval = 8
> 18:27:35  Packets in heartbeat interval = 134
> 18:27:55  Packets in heartbeat interval = 134
> 18:28:15  Packets in heartbeat interval = 8
> 18:28:35  Packets in heartbeat interval = 134
> 18:28:55  Packets in heartbeat interval = 134
> 18:29:15  Packets in heartbeat interval = 9
> 18:29:35  Packets in heartbeat interval = 134
> 18:29:55  Packets in heartbeat interval = 135
> 18:30:15  Packets in heartbeat interval = 9
> 18:30:36  Packets in heartbeat interval = 134
> 18:30:56  Packets in heartbeat interval = 135
> 18:31:16  Packets in heartbeat interval = 11
> 18:31:36  Packets in heartbeat interval = 135
> 18:31:56  Packets in heartbeat interval = 135
> 18:32:16  Packets in heartbeat interval = 14
> 18:32:36  Packets in heartbeat interval = 135
> 18:32:56  Packets in heartbeat interval = 134
>
>
>
>

-- 
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.
Feb 26 22:08:03 weather-station systemd
Feb 26 22:31:13 weather-station systemd[1]: Starting LSB: weewx weather 
system...
Feb 26 22:31:13 weather-station weewx[2196]:  * Starting weewx weather system 
weewx
Feb 26 22:31:13 weather-station weewx[2208]: engine: Initializing weewx version 
3.8.0
Feb 26 22:31:13 weather-station weewx[2208]: engine: Using Python 2.7.12 
(default, Dec  4 2017, 14:50:18) #012[GCC 5.4.0 20160609]
Feb 26 22:31:13 weather-station weewx[2208]: engine: Platform 
Linux-4.4.38-v7+-armv7l-with-Ubuntu-16.04-xenial
Feb 26 22:31:13 weather-station weewx[2208]: engine: Locale is 'en_AU.UTF-8'
Feb 26 22:31:13 weather-station weewx[2208]: engine: pid file is 
/var/run/weewx.pid
Feb 26 22:31:13 weather-station weewx[2212]: engine: Using configuration file 
/etc/weewx/weewx.conf
Feb 

[weewx-user] Re: New (re)install. Weewx running and reporting-no webpage

[Sam Roza]

Thank you, Gary and Andrew! You both contributed to me unwinding the 
problem.

Looks like the old install published to /var/www/weewx for whatever reason. 
This new stock install copies to /var/www/html/weewx for the HTML_ROOT. I 
changed the HTML_ROOT and copied the existing files over to the proper 
directory. I'm waiting for it to cycle through the report again to see if 
it's actually fixed, or if I need to change anything else.

Will upload files if I can't figure it out from here.

-SR

On Saturday, February 10, 2018 at 12:19:06 AM UTC-8, Andrew Milner wrote:
>
> Sam
>
> Your original post had two possible locations mentioned - 
>
> /var/www/html/weewx 
> and
> /var/html/weewx
>
> This could just have been a typing error - or perhaps you are using the 
> 'wrong' directory somewhere in the skin.conf and/or weewx.conf files
>
> Which is correct, and which are you actually using/trying to use??
>
>
> On Saturday, 10 February 2018 03:03:57 UTC+2, Sam Roza wrote:
>
>> Hello All,
>>
>> I re-installed due to a memory card issue, and I have weewx running and 
>> reporting out to CWOP and WU, etc. That's all good.
>>
>> What it's not doing is creating (more accurately copying) files to the 
>> /var/www/html/weewx directory. I see this in my logs:
>>
>> Feb  9 08:20:51 raspberrypi weewx[512]: cheetahgenerator: Generated 14 
>> files for report StandardReport in 1.22 seconds
>> Feb  9 08:20:51 raspberrypi weewx[512]: manager: Daily summary version is 
>> 2.0
>> >>>Feb  9 08:20:51 raspberrypi weewx[512]: imagegenerator: Generated 12 
>> images for StandardReport in 0.69 seconds
>> >>>Feb  9 08:20:51 raspberrypi weewx[512]: copygenerator: copied 0 files 
>> to /var/www/weewx
>> Feb  9 08:20:51 raspberrypi weewx[512]: reportengine: Running report 
>> BigReport
>> Feb  9 08:20:51 raspberrypi weewx[512]: reportengine: Found configuration 
>> file /etc/weewx/skins/Standard/skin.conf for report BigReport
>> Feb  9 08:20:52 raspberrypi weewx[512]: cheetahgenerator: using search 
>> list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 
>> 'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.Stats', 
>> 'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']
>> Feb  9 08:20:52 raspberrypi weewx[512]: manager: Daily summary version is 
>> 2.0
>> Feb  9 08:20:53 raspberrypi weewx[512]: cheetahgenerator: Generated 14 
>> files for report BigReport in 1.18 seconds
>> Feb  9 08:20:53 raspberrypi weewx[512]: manager: Daily summary version is 
>> 2.0
>> Feb  9 08:20:54 raspberrypi weewx[512]: imagegenerator: Generated 12 
>> images for BigReport in 1.25 seconds
>> Feb  9 08:20:54 raspberrypi weewx[512]: copygenerator: copied 0 files to 
>> /public_html/big
>>
>>
>> Yet there are no files in the /var/html/weewx directory:
>>
>> root@raspberrypi:/etc/weewx# ls -lh /var/www/html/weewx/
>> total 0
>>
>> Part of me thought it might be permissions, but they look pretty wide 
>> open:
>>
>> root@raspberrypi:/etc/weewx# ls -l /var/www/html/
>> total 16
>> -rw-r--r-- 1 root root 10701 Feb  8 10:12 index.html
>> drwxr-xr-x 2 root root  4096 Feb  8 12:19 weewx
>>
>> I even modified to 777 perms and restarted and it is not updating.
>>
>> I installed this a year or two ago, so I'm admittedly a bit rusty. What 
>> am I missing?
>>
>>

-- 
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: Most reliable mini computer for weeWX?

[Sam Roza]

Given the cost and resource use, you really con't go wrong with a RPi. I am 
using a 3b. So cheap, and easy, and weewx installs and runs perfectly. 

-SR

On Wednesday, January 24, 2018 at 11:38:36 AM UTC-8, Alec Bennett wrote:
>
> I've been running weeWX on a Beaglebone Black for about a year now, and 
> the thing has been freezing about once a month. It's running headless so is 
> hard to diagnose.
>
> I'm probably going to switch to a Pi, but thought I'd see if anyone has 
> any other suggestions for a very reliable mini computer that plays nice 
> with 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.

[weewx-user] New (re)install. Weewx running and reporting-no webpage

[Sam Roza]

Hello All,

I re-installed due to a memory card issue, and I have weewx running and 
reporting out to CWOP and WU, etc. That's all good.

What it's not doing is creating (more accurately copying) files to the 
/var/www/html/weewx directory. I see this in my logs:

Feb  9 08:20:51 raspberrypi weewx[512]: cheetahgenerator: Generated 14 
files for report StandardReport in 1.22 seconds
Feb  9 08:20:51 raspberrypi weewx[512]: manager: Daily summary version is 
2.0
>>>Feb  9 08:20:51 raspberrypi weewx[512]: imagegenerator: Generated 12 
images for StandardReport in 0.69 seconds
>>>Feb  9 08:20:51 raspberrypi weewx[512]: copygenerator: copied 0 files to 
/var/www/weewx
Feb  9 08:20:51 raspberrypi weewx[512]: reportengine: Running report 
BigReport
Feb  9 08:20:51 raspberrypi weewx[512]: reportengine: Found configuration 
file /etc/weewx/skins/Standard/skin.conf for report BigReport
Feb  9 08:20:52 raspberrypi weewx[512]: cheetahgenerator: using search list 
['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 
'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.Stats', 
'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras']
Feb  9 08:20:52 raspberrypi weewx[512]: manager: Daily summary version is 
2.0
Feb  9 08:20:53 raspberrypi weewx[512]: cheetahgenerator: Generated 14 
files for report BigReport in 1.18 seconds
Feb  9 08:20:53 raspberrypi weewx[512]: manager: Daily summary version is 
2.0
Feb  9 08:20:54 raspberrypi weewx[512]: imagegenerator: Generated 12 images 
for BigReport in 1.25 seconds
Feb  9 08:20:54 raspberrypi weewx[512]: copygenerator: copied 0 files to 
/public_html/big


Yet there are no files in the /var/html/weewx directory:

root@raspberrypi:/etc/weewx# ls -lh /var/www/html/weewx/
total 0

Part of me thought it might be permissions, but they look pretty wide open:

root@raspberrypi:/etc/weewx# ls -l /var/www/html/
total 16
-rw-r--r-- 1 root root 10701 Feb  8 10:12 index.html
drwxr-xr-x 2 root root  4096 Feb  8 12:19 weewx

I even modified to 777 perms and restarted and it is not updating.

I installed this a year or two ago, so I'm admittedly a bit rusty. What am 
I missing?

-- 
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: Bootstrap Skin chart labels: Unreadable

[Sam Roza]

Thanks, Andrew!

I will perhaps go on the hunt for a different skin.

-SR

On Sunday, September 3, 2017 at 10:43:28 PM UTC-7, Andrew Milner wrote:
>
> the settings must be either in skins/Bootstrap/skin.conf or 
> skins/Images/skin.conf or even possibly skins/BigImages/skin.conf - has to 
> be in one of those I would have thought, unless being overridden by a 
> setting in weewx.conf
>
> I use the standard weewx image .png files even though I am using the 
> bootstrap skin - so my settings probably wont help you very much.  I cannot 
> remember why I did not use the bootstrap .pngs - maybe for the very reason 
> that you have discovered!!!  I just cannot remember!!
> .
>
> On Monday, 4 September 2017 08:11:53 UTC+3, Sam Roza wrote:
>
>> Andrew,
>>
>> All I did to Bootstrap was install it using the wee_extension command and 
>> restarted the app. So my skin.conf is a stock bootstrap conf file.
>>
>> Charts are attached. One from Bootstrap, and one from the standard skin. 
>>
>> If I knew where the settings for chart generation were, I might be able 
>> to fix this on my own. I can't see any explicit config changes to be made. 
>> I will read over your conf files in the meantime.
>>
>> Thanks.
>>
>> -SR
>>
>> On Sunday, September 3, 2017 at 7:15:58 PM UTC-7, Andrew Milner wrote:
>>>
>>> perhaps attaching an example of an incorrect plot would help diagnose 
>>> your problem
>>>
>>> I am using Bootstrap, and use fontsizes of 14 - 18 with no problems.  
>>> Have attached my skins/Images/skin.conf file, and also 
>>> skins/Bootstrap/skin.conf
>>>
>>>
>>>
>>>
>>>
>>> On Monday, 4 September 2017 01:32:21 UTC+3, Sam Roza wrote:
>>>
>>>> Hello All,
>>>>
>>>> Working with the Bootstrap skin so that I could get some additional 
>>>> historical info out of WeeWx. I have loaded it and the skin page renders, 
>>>> and I have graphs and charts and historical data.
>>>>
>>>> Unfortunately, the labels and measurements on both X and Y axes are so 
>>>> tiny that I cannot discern it at all.
>>>>
>>>> I tried to change the settings:
>>>>
>>>> digitfontsize = 24
>>>> labelfontsize = 25
>>>>
>>>> To 24 and 25 respectively (from 14, 15), but that doesn't appear to 
>>>> have impacted it like I thought it would.
>>>>
>>>> Anybody know what conf changes I need to make?
>>>>
>>>

-- 
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: Bootstrap Skin chart labels: Unreadable

[Sam Roza]

Andrew,

All I did to Bootstrap was install it using the wee_extension command and 
restarted the app. So my skin.conf is a stock bootstrap conf file.

Charts are attached. One from Bootstrap, and one from the standard skin. 

If I knew where the settings for chart generation were, I might be able to 
fix this on my own. I can't see any explicit config changes to be made. I 
will read over your conf files in the meantime.

Thanks.

-SR

On Sunday, September 3, 2017 at 7:15:58 PM UTC-7, Andrew Milner wrote:
>
> perhaps attaching an example of an incorrect plot would help diagnose your 
> problem
>
> I am using Bootstrap, and use fontsizes of 14 - 18 with no problems.  Have 
> attached my skins/Images/skin.conf file, and also skins/Bootstrap/skin.conf
>
>
>
>
>
> On Monday, 4 September 2017 01:32:21 UTC+3, Sam Roza wrote:
>
>> Hello All,
>>
>> Working with the Bootstrap skin so that I could get some additional 
>> historical info out of WeeWx. I have loaded it and the skin page renders, 
>> and I have graphs and charts and historical data.
>>
>> Unfortunately, the labels and measurements on both X and Y axes are so 
>> tiny that I cannot discern it at all.
>>
>> I tried to change the settings:
>>
>> digitfontsize = 24
>> labelfontsize = 25
>>
>> To 24 and 25 respectively (from 14, 15), but that doesn't appear to have 
>> impacted it like I thought it would.
>>
>> Anybody know what conf changes I need to make?
>>
>

-- 
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] Bootstrap Skin chart labels: Unreadable

[Sam Roza]

Hello All,

Working with the Bootstrap skin so that I could get some additional 
historical info out of WeeWx. I have loaded it and the skin page renders, 
and I have graphs and charts and historical data.

Unfortunately, the labels and measurements on both X and Y axes are so tiny 
that I cannot discern it at all.

I tried to change the settings:

digitfontsize = 24
labelfontsize = 25

To 24 and 25 respectively (from 14, 15), but that doesn't appear to have 
impacted it like I thought it would.

Anybody know what conf changes I need to make?

-- 
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: SteelSeries gauges .....No gauges are displayed

[Sam]

Gary Thank you so much.  I learned a little bit as well. Thanks for that 
too.

On Wednesday, March 15, 2017 at 5:23:49 PM UTC-4, gjr80 wrote:
>
> And there it is, missing comma at the end of line 38.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: SteelSeries gauges .....No gauges are displayed

[Sam]

Gary,
gauges.js is in /var/www/html/weewx/ss/scripts.

The console throws out Uncaught SyntaxError: Unexpected identifier 
  gauges.js:39link address is   
http://192.168.1.125/weewx/ss/scripts/gauges.js
I am assuming that means there is a problem at line 39 in  gauges.js
Line 39 reads  oldGauges  : 'gauges.htm', //*** Change this 
to the relative path for your 'old' gauges page.



On Wednesday, March 15, 2017 at 3:22:29 AM UTC-4, gjr80 wrote:
>
> Ok, interesting. I just did a clean install of 3.7.0 via deb and followed 
> the instructions you listed and everything works fine. Now that I think 
> back not being able to find gauges.js can lead to no gauges being rendered 
> on screen. Can you confirm that gauges.js is in 
> /var/www/html/weewx/ss/scripts ?
>
> If it is we need to see if any javascript errors are being thrown. Can you 
> open the Browser Console in your browser, what this will be called varies I 
> think from browser to browser. I use firefox and it is under Developer, 
> Browser Console. Edge it is under F12 Developer Tools. You will need to 
> find it for your browser. Have a look at the Javascript console, are there 
> any errors there that apprear to relate to gauges.js etc.  Clear the log 
> and refresh your weewx/ss/index.html page in your broswer to see if any 
> errors come up.  If so what do they say?.
>
> Gary
>
>
> On Wednesday, 15 March 2017 14:17:34 UTC+10, Sam wrote:
>>
>>   Line 73 says   realTimeUrlWeewx   : 'gauge-data.txt', 
>>
>> On Tuesday, March 14, 2017 at 10:50:46 PM UTC-4, gjr80 wrote:
>>>
>>> Hi,
>>>
>>> I see nothing obviously wrong there. It's possible that the SteelSeries 
>>> Weather Gauges can't find you data file (gauge-data.txt), what do you 
>>> have against realTimeURL_weewx in gauges.js (it about line 68). This 
>>> tells the Steel Series Weatehr Gauges where to find you gauge-data.txt 
>>> file.
>>>
>>> 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: SteelSeries gauges .....No gauges are displayed

[Sam]

  Line 73 says   realTimeUrlWeewx   : 'gauge-data.txt', 

On Tuesday, March 14, 2017 at 10:50:46 PM UTC-4, gjr80 wrote:
>
> Hi,
>
> I see nothing obviously wrong there. It's possible that the SteelSeries 
> Weather Gauges can't find you data file (gauge-data.txt), what do you 
> have against realTimeURL_weewx in gauges.js (it about line 68). This 
> tells the Steel Series Weatehr Gauges where to find you gauge-data.txt 
> file.
>
> Gary
>
> On Wednesday, 15 March 2017 12:33:46 UTC+10, Sam wrote:
>>
>> Hi, and thanks to all in advance,
>>
>>
>> I am trying to install SteelSeries gauges  to my weewx raspberry pi. 
>> Weewx was installed  from a DEB package. It is partly working in that I see 
>> a web page at http://192.168.1.125/weewx/ss/  that mentions  at the 
>> bottom...
>>
>>
>> Interval: 5 minutes
>> Station: Simulator
>> Software: WeeWX 3.7.0 <http://www.weewx.com/>
>> Scripts: by Mark Crossley
>> Gauges: SteelSeries <https://github.com/HanSolo/SteelSeries-Canvas> by 
>> Gerrit Grunwald
>>
>>
>> But that is it. No gauges are displayed.  Included are some Log files.
>>
>> Here is what I have done.  
>>
>> copy weather_server/WeeWX/skin.conf WEEWX_SKINS_DIR/ss/
>>
>> copy weather_server/WeeWX/index.html.tmpl WEEWX_SKINS_DIR/ss/
>>
>> copy weather_server/WeeWX/gauge-data.txt.tmpl WEEWX_SKINS_DIR/ss/
>>
>> copy web_server/css folder to WEEWX_SKINS_DIR/ss/
>>
>> copy web_server/scripts folder to WEEWX_SKINS_DIR/ss/
>>
>> edied  WEEWX_SKINS_DIR/ss/scripts/gauges.js
>>
>> weatherProgram : 6
>>
>> imgPathURL : ''
>>
>> stationTimeout : 10 // set to twice archive interval, in minutes
>>
>> showUvGauge : false // false if there is no UV sensor
>>
>> showSolarGauge : false  // false if there is no solar radiation sensor
>>
>> add a SteelSeries section to StdReport in weewx.conf
>>
>> [StdReport]
>>
>> ...
>>
>> [[SteelSeries]]
>>
>> skin = ss
>>
>> HTML_ROOT = /var/www/html/weewx/ss
>>
>>  
>>
>>  
>>
>>  
>>
>>  wee_debug output
>>
>>  
>>
>> pi@raspberrypi:~ $ wee_debug --info
>>
>> Using verbosity=1, displaying most info
>>
>>  
>>
>> wee_debug output will be sent to stdout(console)
>>
>>  
>>
>> Using configuration file /etc/weewx/weewx.conf
>>
>> Using database binding 'wx_binding', which is bound to database 
>> 'archive_sqlite'
>>
>>  
>>
>> System info
>>
>>   CPU implementer:0x41
>>
>>   Features:   half thumb fastmult vfp edsp neon vfpv3 tls 
>> vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
>>
>>   CPU architecture:   7
>>
>>   BogoMIPS:   76.80
>>
>>   Hardware:   BCM2709
>>
>>   CPU revision:   4
>>
>>   CPU part:   0xd03
>>
>>   model name: ARMv7 Processor rev 4 (v7l)
>>
>>   Serial: 0eccebc4
>>
>>   processor:  3
>>
>>   CPU variant:0x0
>>
>>   Revision:   a02082
>>
>>  
>>
>>   Operating system:   debian 8.0
>>
>>   Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 
>> 20 19:18:29 GMT 2017 armv7l
>>
>>   1 minute load average:  0.00
>>
>>   5 minute load average:  0.03
>>
>>   15 minute load average: 0.00
>>
>>  
>>
>> General weewx info
>>
>>   Weewx version 3.7.0 detected.
>>
>>  
>>
>> Station info
>>
>>   Station type: Simulator
>>
>>   Driver:   weewx.drivers.simulator
>>
>>  
>>
>> Driver info
>>
>> [Simulator]
>>
>> # This section is for the weewx weather station simulator
>>
>>  
>>
>> # The time (in seconds) between LOOP packets.
>>
>> loop_interval = 2.5
>>
>>  
>>
>> # The simulator mode can be either 'simulator' or 'generator'.
>>
>> # Real-time simulator. Sleep between each LOOP packet.
>>
>> mode = simulator
>>
>> # Generator.  Emit LOOP packets as fast as possible (useful for 
>> testing).
>>
>> #mode = generator
>>
>>  
>>
>> # The start time. If not specified, the default is to use the present 
>> ti

[weewx-user] SteelSeries gauges .....No gauges are displayed

[Sam]

Hi, and thanks to all in advance,


I am trying to install SteelSeries gauges  to my weewx raspberry pi. Weewx 
was installed  from a DEB package. It is partly working in that I see a web 
page at http://192.168.1.125/weewx/ss/  that mentions  at the bottom...


Interval: 5 minutes
Station: Simulator
Software: WeeWX 3.7.0 
Scripts: by Mark Crossley
Gauges: SteelSeries  by 
Gerrit Grunwald


But that is it. No gauges are displayed.  Included are some Log files.

Here is what I have done.  

copy weather_server/WeeWX/skin.conf WEEWX_SKINS_DIR/ss/

copy weather_server/WeeWX/index.html.tmpl WEEWX_SKINS_DIR/ss/

copy weather_server/WeeWX/gauge-data.txt.tmpl WEEWX_SKINS_DIR/ss/

copy web_server/css folder to WEEWX_SKINS_DIR/ss/

copy web_server/scripts folder to WEEWX_SKINS_DIR/ss/

edied  WEEWX_SKINS_DIR/ss/scripts/gauges.js

weatherProgram : 6

imgPathURL : ''

stationTimeout : 10 // set to twice archive interval, in minutes

showUvGauge : false // false if there is no UV sensor

showSolarGauge : false  // false if there is no solar radiation sensor

add a SteelSeries section to StdReport in weewx.conf

[StdReport]

...

[[SteelSeries]]

skin = ss

HTML_ROOT = /var/www/html/weewx/ss

 

 

 

 wee_debug output

 

pi@raspberrypi:~ $ wee_debug --info

Using verbosity=1, displaying most info

 

wee_debug output will be sent to stdout(console)

 

Using configuration file /etc/weewx/weewx.conf

Using database binding 'wx_binding', which is bound to database 
'archive_sqlite'

 

System info

  CPU implementer:0x41

  Features:   half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm crc32

  CPU architecture:   7

  BogoMIPS:   76.80

  Hardware:   BCM2709

  CPU revision:   4

  CPU part:   0xd03

  model name: ARMv7 Processor rev 4 (v7l)

  Serial: 0eccebc4

  processor:  3

  CPU variant:0x0

  Revision:   a02082

 

  Operating system:   debian 8.0

  Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 
19:18:29 GMT 2017 armv7l

  1 minute load average:  0.00

  5 minute load average:  0.03

  15 minute load average: 0.00

 

General weewx info

  Weewx version 3.7.0 detected.

 

Station info

  Station type: Simulator

  Driver:   weewx.drivers.simulator

 

Driver info

[Simulator]

# This section is for the weewx weather station simulator

 

# The time (in seconds) between LOOP packets.

loop_interval = 2.5

 

# The simulator mode can be either 'simulator' or 'generator'.

# Real-time simulator. Sleep between each LOOP packet.

mode = simulator

# Generator.  Emit LOOP packets as fast as possible (useful for 
testing).

#mode = generator

 

# The start time. If not specified, the default is to use the present 
time.

#start = 2011-01-01 00:00

 

# The driver to use:

driver = weewx.drivers.simulator

 

Currently installed extensions

No extensions installed

 

Archive info

  Database name:weewx.sdb

  Table name:   archive

  Unit system:  1 (US)

  First good timestamp: 2017-03-13 22:35:00 EDT (1489458900)

  Last good timestamp:  2017-03-14 21:35:00 EDT (1489541700)

  Number of records:274

  weewx (weewx.conf) is set to use an archive interval of 300 seconds.

  The station hardware was not interrogated in determining archive interval.

 

Databases configured in weewx.conf

  Database name:weewx.sdb

  Database driver:  weedb.sqlite

 

  Database name:weewx

  Database driver:  weedb.mysql

  Database host:localhost

 

 

Parsed and obfuscated weewx.conf

# WEEWX CONFIGURATION FILE

#

# Copyright (c) 2009-2015 Tom Keffer 

# See the file LICENSE.txt for your rights.

 

##

 

# This section is for general configuration information.

 

# Set to 1 for extra debug info, otherwise comment it out or set to zero

debug = 1

 

# Root directory of the weewx data file hierarchy for this station

WEEWX_ROOT = /

 

# How long to wait before timing out a socket (FTP, HTTP) connection

socket_timeout = 20

 

# Do not modify this. It is used when installing and updating weewx.

version = 3.7.0

 

##

 

#   This section is for information about the station.

 

[Station]

 

# Description of the station location

location = Up on the Pole

 

# Latitude and longitude in decimal degrees

latitude = 43.149

longitude = -74.6863

 

# Altitude of the station, with unit it is in. This is downloaded from

# from the station if the hardware supports it.

altitude = 710, foot

 

# Set to type 

[weewx-user] Re: Interceptor parse failed messages

[Sam Roza]

That fixed it, Matt.

Many thanks, again.

-SR

On Sunday, December 11, 2016 at 11:59:30 AM UTC-8, mwall wrote:
>
> On Sunday, December 11, 2016 at 2:24:53 PM UTC-5, Sam Roza wrote:
>>
>> I'm very thankful for the attentiveness you show when issues come up.
>>
>> Where can I find the sensor map? I've combed weewx.conf, and looked in 
>> all the directories, and searched online for where this can be modified, 
>> but haven't come up with it.
>>
>
> the sensor map associates the names/identifiers of each sensor with a 
> field in the database.  for simple weather stations, these are hard-coded 
> into the driver.  for hardware that supports multiple types and 
> configurations of sensors, the driver has a default map, but that map can 
> be overridden in weewx.conf.
>
> for the interceptor driver and the LW30x hardware, the map looks like this:
>
> [Interceptor]
> ...
> [[sensor_map]]
> pressure = baro.*.*
> outTemp = ot.?:*.*
> outHumidity = oh.?:*.*
> windSpeed = ws.?:*.*
> windGust = wg.?:*.*
> windDir = wd.?:*.*
> rainRate = rr.?:*.*
> rain = rain.?:*.*
> UV = uvh.?:*.*
>
> the left-hand side is the database field, the right-hand side is a tuple 
> consisting of
>
> ..
>
> glob matching works for each part of the tuple.
>
> you can put this in your weewx.conf.  or you could update to 0.21, which 
> fixes the 'pressure' value in the default sensor map for LW30x.
>
> m
>

-- 
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: Interceptor parse failed messages

[Sam Roza]

I'm very thankful for the attentiveness you show when issues come up.

Where can I find the sensor map? I've combed weewx.conf, and looked in all 
the directories, and searched online for where this can be modified, but 
haven't come up with it.

-SR

On Sunday, December 11, 2016 at 8:35:47 AM UTC-8, mwall wrote:
>
> On Sunday, December 11, 2016 at 11:23:51 AM UTC-5, Sam Roza wrote:
>>
>> But the issue of proper processing is still there. I see the POST and to 
>> my eye it looks good. There are no errors and indeed-interceptor and weewx 
>> seem to say they are adding the measurement to weewx and the db, but I get 
>> nothing logged, and nothing sent to APRS/WU, etc.
>>
>> Here's a relevant excerpt from the log:
>>
>> ~~~
>> Dec 11 07:21:55 raspberrypi weewx[10289]: interceptor: ServerThread: 
>> POST: 
>> mac=0004a369e0d6=c2=0=0=0=1809==1015=0=1=1
>> Dec 11 07:21:55 raspberrypi weewx[10289]: interceptor: MainThread: raw 
>> data: 
>> mac=0004a369e0d6=c2=0=0=0=1809==1015=0=1=1
>> Dec 11 07:21:55 raspberrypi weewx[10289]: interceptor: MainThread: raw 
>> packet: {'lost.:.0004a369e0d6': '', 'ac.:.0004a369e0d6': '0', 
>> 'wfor.:.0004a369e0d6': '1', 'ptr.:.0004a369e0d6
>> ': '0', 'lb.:.0004a369e0d6': '0', 'baro.:.0004a369e0d6': 1015.0, 
>> 'dateTime': 1481469716, 'id.:.0004a369e0d6': 'c2', 'p.:.0004a369e0d6': '1', 
>> 'pv.:.0004a369e0d6': '0', 'reg.:.0004a369e0
>> d6': '1809', 'usUnits': 17, 'mac.:.0004a369e0d6': '0004a369e0d6'}
>>
>>>
>>>>
> the observation baro.:.0004a369e0d6 is not matching.
>
> update your sensor map to change this:
>
> pressure = baro..*
>
> to this:
>
> pressure = baro.*.*
>
> i have updated the default sensor map in v0.21 at commit 7c1a38f
>
> m
>

-- 
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: Interceptor parse failed messages

[Sam Roza]

Hey Matt,

Here's the current iteration of the script:

~~~
#!/bin/sh

#ngrep -l -q -d eth0 '0004a369e0d6' | sed -u '/mac=/!d' | xargs -n 1 curl 
http://localhost: -s -d
ngrep -l -q -d eth0 '0004a369e0d6' | tee /var/tmp/dump.txt | sed -u 
'/mac=/!d' | xargs -n 1 curl http://localhost: -s -d
~~~

I think I might have found *a* problem. Not sure yet if it's *the* problem:

ps -ef output:

~~~

pi 776   774  0 08:35 pts/000:00:00 -bash
root   786   776  0 08:35 pts/000:00:00 su
root   795   786  0 08:35 pts/000:00:00 bash
nobody 797 1  0 08:35 pts/000:00:07 ngrep -l -q -d eth0 
0004a369e0d6
root   798 1  0 08:35 pts/000:00:00 tee /var/tmp/dump.txt
root   799 1  0 08:35 pts/000:00:00 sed -u /mac=/!d
root   800 1  0 08:35 pts/000:00:00 xargs -n 1 curl 
http://localhost: -s -d
root   801 2  0 08:35 ?00:00:00 [kworker/1:1H]
root   883 2  0 08:40 ?00:00:02 [kworker/0:0]
nobody 947 1  0 08:42 pts/000:00:10 ngrep -l -q -d eth0 
0004a369e0d6
root   948 1  0 08:42 pts/000:00:00 sed -u /mac=/!d
root   949 1  0 08:42 pts/000:00:00 xargs -n 1 curl 
http://localhost: -s -d
root  1049 2  0 08:50 ?00:00:00 [kworker/2:1]
root  1176   795  0 08:59 pts/000:00:00 /bin/sh ./capture.sh
nobody1177  1176  0 08:59 pts/000:00:07 ngrep -l -q -d eth0 
0004a369e0d6
root  1178  1176  0 08:59 pts/000:00:00 tee /var/tmp/dump.txt
root  1179  1176  0 08:59 pts/000:00:00 sed -u /mac=/!d
root  1180  1176  0 08:59 pts/000:00:00 xargs -n 1 curl 
http://localhost: -s -d
root  1229   795  0 09:02 pts/000:00:00 tail -f /var/tmp/dump.txt

~~~

Looks like multiple scripts are running, to me...

Let me clean this up and see if it works everything out.

-SR

On Saturday, December 10, 2016 at 3:13:16 PM UTC-8, mwall wrote:
>
> On Saturday, December 10, 2016 at 4:46:15 PM UTC-5, Sam Roza wrote:
>>
>> Hi Matt, 
>>
>> I use a simple ngrep script that you and I worked out. I worked reliably 
>> for the last few months. I have been teeing the packets out to a file,  and 
>> in my previous reply,  you can see the 'wfor'  shows up in there. After the 
>> tee,  it's sent to interceptor. Looking at the weewx.log the POST shows the 
>> packet with the 'wfor' tacked to the end. But then it looks to me as if the 
>> packet is processed several times by interceptor. The tee file doesn't show 
>> multi packets. 
>>
>> Let me know if I'm unclear, or if the log snippet included isn't making 
>> sense. 
>>
>
> sam,
>
> based on the log snippet you posted, the interceptor is doing exactly what 
> it is supposed to do.
>
> the interceptor is not processing a single POST multiple times - based on 
> the log, something is *posting* what appears to be the same data multiple 
> times, and some of those POSTs contain incomplete data.
>
> the interceptor uses a standard do_POST handler on 
> BaseHTTPServer.BaseHTTPRequestHandler.  i don't know how that handler could 
> be duplicating POSTs - it simply puts the data it receives onto a queue.  
> and i don't know how the BaseHTTPServer could be duplicating POSTs.
>
> i know we went through the ngrep stuff in a different thread, but that was 
> awhile ago and i have no way of knowing what, if anything, has changed in 
> your setup.  are you using this (from a posting in october, in thread 
> "weewx with OS LW301 and interceptor driver"):
>
> #!/bin/sh
> ngrep -l -q -d eth0 '0004a369e0d6' | sed -u '/mac=/!d' | xargs -n 1 curl 
> http://localhost: -s -d
>
> how are you tee-ing to file?
>
> perhaps you could have curl send to a web server that simply logs every 
> POST - that might help us track down where the duplication is coming from.
>
> m
>
>

-- 
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: Interceptor parse failed messages

[Sam Roza]

Hi Matt, 

I use a simple ngrep script that you and I worked out. I worked reliably for 
the last few months. I have been teeing the packets out to a file,  and in my 
previous reply,  you can see the 'wfor'  shows up in there. After the tee,  
it's sent to interceptor. Looking at the weewx.log the POST shows the packet 
with the 'wfor' tacked to the end. But then it looks to me as if the packet is 
processed several times by interceptor. The tee file doesn't show multi 
packets. 

Let me know if I'm unclear, or if the log snippet included isn't making sense. 

-SR

-- 
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: Interceptor parse failed messages

[Sam Roza]

K, so resetting the rig was never going to help, and did not.

I switched capture strings, hoping that something about teeing the output 
was the problem, and it was not.

I went and looked at the tee'd output, and the POSTs it is intercepting 
appear correct:

~~~
T 192.168.1.73:4909 -> 54.228.205.188:80 [AP]
  
mac=0004a369e0d6=c2=0=0=0=1809==1012=0=3=1
 
 
T 192.168.1.73:4916 -> 54.228.205.188:80 [AP]
  
mac=0004a369e0d6=c2=0=0=0=1809==1012=0=3=1
 
  
~~~

But by the time interceptor is done with it, it seems to be lacking the 
wfor arg. Ten, as I'm sitting there watching it, it starts to behave:


Tee'd packet: 
T 192.168.1.73:4924 -> 54.228.205.188:80 [AP]
  
mac=0004a369e0d6=c2=0=0=0=1809==1012=0=3=1
 
 

Interceptor log:
ec 10 09:09:55 raspberrypi weewx[563]: interceptor: ServerThread: POST: 
mac=0004a369e0d6=c2=0=0=0=1809==1012=0=3=1
Dec 10 09:09:55 raspberrypi weewx[563]: interceptor: ServerThread: POST: 
mac=0004a369e0d6=c2=0=0=0=1809==1012=0=3=1
Dec 10 09:09:55 raspberrypi weewx[563]: interceptor: MainThread: raw data: 
mac=0004a369e0d6=c2=0=0=0=1809==1012=0=3=1
Dec 10 09:09:55 raspberrypi weewx[563]: interceptor: MainThread: raw 
packet: {'lost.:.0004a369e0d6': '', 'ac.:.0004a369e0d6': '0', 
'wfor.:.0004a369e0d6': '3', 'ptr.:.0004a369e0d6': '0', 'lb.:.0004a369e0d6': 
'0', 'baro.:.0004a369e0d6': 1012.0, 'dateTime': 1481389796, 
'id.:.0004a369e0d6': 'c2', 'p.:.0004a369e0d6': '1', 'pv.:.0004a369e0d6': 
'0', 'reg.:.0004a369e0d6': '1809', 'usUnits': 17, 'mac.:.0004a369e0d6': 
'0004a369e0d6'}
Dec 10 09:09:55 raspberrypi weewx[563]: interceptor: MainThread: mapped 
packet: {'usUnits': 17, 'dateTime': 1481389796}
Dec 10 09:09:55 raspberrypi weewx[563]: interceptor: MainThread: raw data: 
mac=0004a369e0d6=c2=0=0=0=1809==1012=0=3=1
Dec 10 09:09:55 raspberrypi weewx[563]: interceptor: MainThread: raw 
packet: {'lost.:.0004a369e0d6': '', 'ac.:.0004a369e0d6': '0', 
'wfor.:.0004a369e0d6': '3', 'ptr.:.0004a369e0d6': '0', 'lb.:.0004a369e0d6': 
'0', 'baro.:.0004a369e0d6': 1012.0, 'dateTime': 1481389796, 
'id.:.0004a369e0d6': 'c2', 'p.:.0004a369e0d6': '1', 'pv.:.0004a369e0d6': 
'0', 'reg.:.0004a369e0d6': '1809', 'usUnits': 17, 'mac.:.0004a369e0d6': 
'0004a369e0d6'}
Dec 10 09:09:55 raspberrypi weewx[563]: interceptor: MainThread: mapped 
packet: {'usUnits': 17, 'dateTime': 1481389796}

I'll watch this a bit longer today and see if I can't unravel this.

-SR




On Saturday, December 10, 2016 at 8:34:32 AM UTC-8, Sam Roza wrote:
>
> Ah yeah. It wasn't obvious earlier what was missing, but there it is:
>
> Dec  4 10:40:04 raspberrypi weewx[17396]: interceptor: ServerThread: POST: 
> mac=0004a369e0d6=c2=0=0=0=1809==1015=0=2=1
>
> Let me reset the rig and see what happens. I don't recall any changfes 
> being made to it 6 days ago that would have led to this occurring.
>
> -SR
>
> On Saturday, December 10, 2016 at 8:27:37 AM UTC-8, Sam Roza wrote:
>>
>> Hi Matt, 
>>
>> I am on weewx 3.6.2, interceptor .20 as of yesterday with no change. I 
>> might reboot all and see if that fixes things.
>>
>
>  
>

-- 
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] Interceptor parse failed messages

[Sam Roza]

I am having a baro problem:

~~~
Dec  4 21:33:03 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1013=0: 
dictionary update sequence element #9 has length 1; 2 is required
Dec  4 21:56:03 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1013=0: 
dictionary update sequence element #9 has length 1; 2 is required
...
Dec  6 07:22:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1012=0: 
dictionary update sequen
ce element #9 has length 1; 2 is required
Dec  6 07:25:20 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for Length:: dictionary update sequence element #0 has length 1; 2 
is required
Dec  6 07:25:20 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 68..User-Agent:: dictionary update sequence element #0 has 
length 1; 2 is required
Dec  6 07:25:20 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for BlackBox/1.0.08..Connection:: dictionary update sequence element 
#0 has length 1; 2 is required
Dec  6 07:28:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1012=0: 
dictionary update sequen
ce element #9 has length 1; 2 is required
Dec  6 07:34:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1011=0: 
dictionary update sequence element #9 has length 1; 2 is required
Dec  6 07:40:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1011=0: 
dictionary update sequence element #9 has length 1; 2 is required
Dec  6 07:47:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1011=0: 
dictionary update sequence element #9 has length 1; 2 is required
Dec  6 07:53:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1011=0: 
dictionary update sequence element #9 has length 1; 2 is required
Dec  6 07:59:56 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for Length:: dictionary update sequence element #0 has length 1; 2 
is required
Dec  6 07:59:56 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 62..User-Agent:: dictionary update sequence element #0 has 
length 1; 2 is required
Dec  6 07:59:56 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for BlackBox/1.0.08..Connection:: dictionary update sequence element 
#0 has length 1; 2 is required
Dec  6 08:11:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1011=0: 
dictionary update sequence element #9 has length 1; 2 is required
Dec  6 08:17:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1011=0: 
dictionary update sequence element #9 has length 1; 2 is required
Dec  6 08:21:50 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for Length:: dictionary update sequence element #0 has length 1; 2 
is required
Dec  6 08:21:50 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 62..User-Agent:: dictionary update sequence element #0 has 
length 1; 2 is required
Dec  6 08:21:50 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for BlackBox/1.0.08..Connection:: dictionary update sequence element 
#0 has length 1; 2 is required
Dec  6 08:28:01 raspberrypi weewx[4795]: interceptor: MainThread: parse 
failed for 
mac=0004a369e0d6=c2=0=0=0=1809==1011=0: 
dictionary update sequence element #9 has length 1; 2 is required
~~~

But I do not know the cause. It's been doing this for about 5 days, now. 

-SR

-- 
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: Lost all data overnight...

[Sam Roza]

Cool, I will upgrade soon.

As for the hardware sending "less frequently", it looks more like it being 
sent randomly, and not at any regular interval:

~~~
Nov 27 00:12:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1006.0, 'usUnits': 17, 'dateTime': 1480234336}
Nov 27 01:00:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1006.0, 'usUnits': 17, 'dateTime': 1480237216}
Nov 27 01:17:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1006.0, 'usUnits': 17, 'dateTime': 1480238236}
Nov 27 02:34:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1007.0, 'usUnits': 17, 'dateTime': 1480242856}
Nov 27 05:57:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1008.0, 'usUnits': 17, 'dateTime': 1480255036}
Nov 27 07:26:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1009.0, 'usUnits': 17, 'dateTime': 1480260376}
Nov 27 08:15:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1010.0, 'usUnits': 17, 'dateTime': 1480263316}
Nov 27 12:16:16 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1011.0, 'usUnits': 17, 'dateTime': 148026}
Nov 27 12:27:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1011.0, 'usUnits': 17, 'dateTime': 1480278436}
Nov 27 13:57:13 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1011.0, 'usUnits': 17, 'dateTime': 1480283834}
Nov 27 14:03:13 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1012.0, 'usUnits': 17, 'dateTime': 1480284194}
Nov 27 18:10:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1012.0, 'usUnits': 17, 'dateTime': 1480299016}
~~~

-SR

On Sunday, November 27, 2016 at 3:44:04 PM UTC-8, mwall wrote:
>
> On Sunday, November 27, 2016 at 6:28:41 PM UTC-5, Sam Roza wrote:
>>
>> BTW, I find it interesting that you ask about readings. I'm at 220M. The 
>> data the equipment reports is never the same as the data that WU reports. 
>> For instance, the final reading above is 1012 from the station, but WU 
>> reports is as what is probably a more accurate 30.08". 1012 looks to be 
>> 29.77"...
>>
>
> fixed in v0.18 at commit ecd02b1.  the value received from lw30x is now 
> treated as pressure instead of barometer.
>
> you might want to check the frequency of packets that contain a 'baro' 
> entry.  other oregon scientific hardware sends the pressure reading much 
> less frequently than other sensor readings.  for example, the wmr300 sends 
> pressure only every 15 minutes!
>
> find out whether you are missing packets or just receiving packets 
> infrequently
>
> m
>

-- 
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: Lost all data overnight...

[Sam Roza]

So the TEE file, the weewx.log file, and WU table seem to jive. I'm just 
not capturing baro data with regularity.

WU 
site: 
https://www.wunderground.com/personal-weather-station/dashboard?ID=KCASANJO594#history
TEE file: 

~~~
  
mac=0004a369e0d6=c2=0=0=0=1809==1010=0=1=1
 

  
mac=0004a369e0d6=c2=0=0=0=1809==1011=1=1=1
 

  
mac=0004a369e0d6=c2=0=0=0=1809==1011=0=1=1
 

  
mac=0004a369e0d6=c2=0=0=0=1809==1011=0=1=1
 

  
mac=0004a369e0d6=c2=0=0=0=1809==1012=0=1=1
 
~~~

weewx.log:

~~~
Nov 27 08:15:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1010.0, 'usUnits': 17, 'dateTime': 1480263316}
Nov 27 12:16:16 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1011.0, 'usUnits': 17, 'dateTime': 148026}
Nov 27 12:27:15 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1011.0, 'usUnits': 17, 'dateTime': 1480278436}
Nov 27 13:57:13 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1011.0, 'usUnits': 17, 'dateTime': 1480283834}
Nov 27 14:03:13 raspberrypi weewx[17396]: interceptor: MainThread: mapped 
packet: {'barometer': 1012.0, 'usUnits': 17, 'dateTime': 1480284194}
~~~

BTW, I find it interesting that you ask about readings. I'm at 220M. The 
data the equipment reports is never the same as the data that WU reports. 
For instance, the final reading above is 1012 from the station, but WU 
reports is as what is probably a more accurate 30.08". 1012 looks to be 
29.77"...

-SR

On Sunday, November 27, 2016 at 1:26:38 PM UTC-8, Sam Roza wrote:
>
> THis is currently happening to my barometric pressure, so I'm actively 
> looking into it. 
>
> What does the POST for pressure look like? I'm trying to remember if is 
> shows in mb or what?
>
> I'm getting wind data and thermo/hygro data, but can't tell if the 
> pressure is buried in the thgr POST or not?
>
> ~~~
> T 192.168.1.73:2850 -> 54.228.205.96:80 [AP]
>   
> mac=0004a369e0d6=84=d6=0=0=0=54=0=16.0=3=1 
>  
> ~~~
>
> _SR
>
> On Thursday, November 24, 2016 at 10:03:44 AM UTC-8, Sam Roza wrote:
>>
>> OK, so there were several hours again where I recorded no data into 
>> weewx, out to WU/CWOP, but looking a tthe logs, I see packets arriving, 
>> being processed, and being sent out to external services. I looked at the 
>> tee'd file after some time thinking about it, and I see a big gap in the 
>> data where the temp sensor doesn't report (I think that's 'ttr' in the POST 
>> data). Wind is an issue, too. 
>>
>> Any clue what would cause 2 pieces of hardware to stop reporting at 
>> basically the same time? Lost data starts after 0443 and begins at 0746. 
>>
>> I'm including the following files:
>>
>> - unadulterated syslog
>> - filtered syslog
>> - tee file (no timestamps, so hard for me to see value/know when the 
>> issue occurred)
>>
>> Hmm. Will think on this over turkey and alcohol.
>>
>> -SR
>>
>> The system just started working on its own, with no action on my part.
>>
>> On Friday, November 18, 2016 at 1:50:18 PM UTC-8, Sam Roza wrote:
>>>
>>> I will try it with the tee. I couldn't get this to work without the sed 
>>> command, IIRC.
>>>
>>> -SR
>>>
>>> On Friday, November 18, 2016 at 12:00:49 PM UTC-8, mwall wrote:
>>>>
>>>> On Friday, November 18, 2016 at 2:37:28 PM UTC-5, Sam Roza wrote:
>>>>>
>>>>> I use interceptor with the following script:
>>>>>
>>>>> ~~~
>>>>> ngrep -l -q -d eth0 '0004a369e0d6' | sed -u '/mac=/!d' | xargs -n 1 
>>>>> curl http://localhost: -s -d
>>>>> ~~~
>>>>>
>>>>> I can tee it into a file if you think we're losing data.
>>>>>
>>>>
>>>> when debug=1, the interceptor will report any data it receives via POST 
>>>> or GET
>>>>
>>>> so the question is whether the ngrep-sed-curl process is filtering out 
>>>> data from the gateway
>>>>
>>>> the sed command
>>>>
>>>> sed -u '/mac=/!d'
>>>>
>>>> skips any line tha

[weewx-user] Re: Lost all data overnight...

[Sam Roza]

THis is currently happening to my barometric pressure, so I'm actively 
looking into it. 

What does the POST for pressure look like? I'm trying to remember if is 
shows in mb or what?

I'm getting wind data and thermo/hygro data, but can't tell if the pressure 
is buried in the thgr POST or not?

~~~
T 192.168.1.73:2850 -> 54.228.205.96:80 [AP]
  
mac=0004a369e0d6=84=d6=0=0=0=54=0=16.0=3=1 
 
~~~

_SR

On Thursday, November 24, 2016 at 10:03:44 AM UTC-8, Sam Roza wrote:
>
> OK, so there were several hours again where I recorded no data into weewx, 
> out to WU/CWOP, but looking a tthe logs, I see packets arriving, being 
> processed, and being sent out to external services. I looked at the tee'd 
> file after some time thinking about it, and I see a big gap in the data 
> where the temp sensor doesn't report (I think that's 'ttr' in the POST 
> data). Wind is an issue, too. 
>
> Any clue what would cause 2 pieces of hardware to stop reporting at 
> basically the same time? Lost data starts after 0443 and begins at 0746. 
>
> I'm including the following files:
>
> - unadulterated syslog
> - filtered syslog
> - tee file (no timestamps, so hard for me to see value/know when the issue 
> occurred)
>
> Hmm. Will think on this over turkey and alcohol.
>
> -SR
>
> The system just started working on its own, with no action on my part.
>
> On Friday, November 18, 2016 at 1:50:18 PM UTC-8, Sam Roza wrote:
>>
>> I will try it with the tee. I couldn't get this to work without the sed 
>> command, IIRC.
>>
>> -SR
>>
>> On Friday, November 18, 2016 at 12:00:49 PM UTC-8, mwall wrote:
>>>
>>> On Friday, November 18, 2016 at 2:37:28 PM UTC-5, Sam Roza wrote:
>>>>
>>>> I use interceptor with the following script:
>>>>
>>>> ~~~
>>>> ngrep -l -q -d eth0 '0004a369e0d6' | sed -u '/mac=/!d' | xargs -n 1 
>>>> curl http://localhost: -s -d
>>>> ~~~
>>>>
>>>> I can tee it into a file if you think we're losing data.
>>>>
>>>
>>> when debug=1, the interceptor will report any data it receives via POST 
>>> or GET
>>>
>>> so the question is whether the ngrep-sed-curl process is filtering out 
>>> data from the gateway
>>>
>>> the sed command
>>>
>>> sed -u '/mac=/!d'
>>>
>>> skips any line that does not contain mac=, so if somehow the lines from 
>>> the t/h and wind sensor were scrambled/shifted, that command might remove 
>>> them.
>>>
>>> you could temporarily try a tee before the sed:
>>>
>>> ngrep -l -q -d eth0 '0004a369e0d6' | tee /var/tmp/dump.txt | sed -u 
>>> '/mac=/!d' | xargs -n 1 curl http://localhost: -s -d
>>>
>>> if you see another lapse in data, check the tee output file for strings 
>>> that contain x=y=b data but no mac=
>>>
>>> or you could simply eliminate the sed altogether, but i'm not sure how 
>>> curl would handle that, and although i have made the interceptor more 
>>> robust to funky inputs that it used to be, it is still probably not robust 
>>> enough.
>>>
>>> m
>>>
>>>

-- 
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: Lost all data overnight...

[Sam Roza]

Matt,

I use interceptor with the following script:

~~~
ngrep -l -q -d eth0 '0004a369e0d6' | sed -u '/mac=/!d' | xargs -n 1 curl 
http://localhost: -s -d
~~~

I can tee it into a file if you think we're losing data.

-SR

On Friday, November 18, 2016 at 10:43:15 AM UTC-8, mwall wrote:
>
> On Friday, November 18, 2016 at 1:28:25 PM UTC-5, Sam Roza wrote:
>>
>> I find it odd that both devices were experiencing difficulties at exactly 
>> the same time, don't you? That's way too coincidental. Devices having 
>> issues shouldn't have issues together. 
>>
>
> agreed.
>
> how are you obtaining the GET string?  is the interceptor in sniff mode, 
> or listen mode?
>
> if it is in listen mode, what sniff/capture/redirect are you using to 
> obtain the GET?
>
> you might want to tee the capture to file so you can see whether the 
> problem is rf comm between sensors and gateway, or something in the packet 
> capture, filtering, and/or processing.
>
> m 
>

-- 
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: UV data not reporting in Standard skin

[Sam Roza]

Looks like there's a problem with this version:

~~~
Nov 17 09:56:34 raspberrypi weewx[9989]: interceptor: ServerThread: POST: 
mac=0004a369e0d6=8e=63=0=0=0=377=1=1
Nov 17 09:56:34 raspberrypi weewx[9989]: interceptor: MainThread: raw data: 
mac=0004a369e0d6=8e=63=0=0=0=377=1=1
Nov 17 09:56:34 raspberrypi weewx[9989]: interceptor: MainThread: raw 
packet: {'mac.1:63.0004a369e0d6': '0004a369e0d6', 'rid.1:63.0004a369e0d6': 
'63', 'ch.1:63.0004a369e0d6': '1', 'uvh.1:63.0004a369e0d6': '0', 
'id.1:63.0004a369e0d6': '8e', 'uv.1:63.0004a369e0d6': 377.0, 'dateTime': 
1479405394, 'pwr.1:63.0004a369e0d6': '0', 'p.1:63.0004a369e0d6': '1', 
'usUnits': 17, 'or.1:63.0004a369e0d6': '0'}
Nov 17 09:56:34 raspberrypi weewx[9989]: interceptor: MainThread: mapped 
packet: {'UV': '0', 'usUnits': 17, 'dateTime': 1479405394}
Nov 17 09:56:34 raspberrypi weewx[9989]: engine: Main loop exiting. 
Shutting engine down.
Nov 17 09:56:34 raspberrypi weewx[9989]: engine: Shutting down StdReport 
thread
Nov 17 09:56:34 raspberrypi weewx[9989]: engine: StdReport thread has been 
terminated
Nov 17 09:56:34 raspberrypi weewx[9989]: restx: Shut down CWOP thread.
Nov 17 09:56:34 raspberrypi weewx[9989]: restx: Shut down Wunderground-PWS 
thread.
Nov 17 09:56:34 raspberrypi weewx[9989]: interceptor: MainThread: shutting 
down server thread
Nov 17 09:56:34 raspberrypi weewx[9989]: interceptor: MainThread: stop tcp 
server
Nov 17 09:56:34 raspberrypi weewx[9989]: engine: Caught unrecoverable 
exception in engine:
Nov 17 09:56:34 raspberrypi weewx[9989]:   unsupported operand 
type(s) for +=: 'float' and 'str'
Nov 17 09:56:34 raspberrypi weewx[9989]:   Traceback (most recent 
call last):
Nov 17 09:56:34 raspberrypi weewx[9989]: File 
"/usr/share/weewx/weewx/engine.py", line 847, in main
Nov 17 09:56:34 raspberrypi weewx[9989]:   engine.run()
Nov 17 09:56:34 raspberrypi weewx[9989]: File 
"/usr/share/weewx/weewx/engine.py", line 189, in run
Nov 17 09:56:34 raspberrypi weewx[9989]:  
 self.dispatchEvent(weewx.Event(weewx.NEW_LOOP_PACKET, packet=packet))
Nov 17 09:56:34 raspberrypi weewx[9989]: File 
"/usr/share/weewx/weewx/engine.py", line 222, in dispatchEvent
Nov 17 09:56:34 raspberrypi weewx[9989]:   callback(event)
Nov 17 09:56:34 raspberrypi weewx[9989]: File 
"/usr/share/weewx/weewx/engine.py", line 528, in new_loop_packet
Nov 17 09:56:34 raspberrypi weewx[9989]:  
 self.accumulator.addRecord(event.packet, self.loop_hilo)
Nov 17 09:56:34 raspberrypi weewx[9989]: File 
"/usr/share/weewx/weewx/accum.py", line 240, in addRecord
Nov 17 09:56:34 raspberrypi weewx[9989]:   func(self, record, 
obs_type, add_hilo)
Nov 17 09:56:34 raspberrypi weewx[9989]: File 
"/usr/share/weewx/weewx/accum.py", line 310, in add_value
Nov 17 09:56:34 raspberrypi weewx[9989]:  
 self[obs_type].addSum(val)
Nov 17 09:56:34 raspberrypi weewx[9989]: File 
"/usr/share/weewx/weewx/accum.py", line 87, in addSum
Nov 17 09:56:34 raspberrypi weewx[9989]:   self.sum += val
Nov 17 09:56:34 raspberrypi weewx[9989]:   TypeError: unsupported 
operand type(s) for +=: 'float' and 'str'
Nov 17 09:56:34 raspberrypi weewx[9989]:   Exiting.
~~~

I've reverted for now.

-SR

On Thursday, November 17, 2016 at 9:52:23 AM UTC-8, Sam Roza wrote:
>
> Gotcha. Just updated. Will report back.
>
> -SR
>
> On Thursday, November 17, 2016 at 8:31:19 AM UTC-8, mwall wrote:
>>
>> Sam, 
>>
>> update to the latest interceptor. It has the right uv mapping for lw30x
>>
>> m
>>
>>

-- 
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: UV data not reporting in Standard skin

[Sam Roza]

Gotcha. Just updated. Will report back.

-SR

On Thursday, November 17, 2016 at 8:31:19 AM UTC-8, mwall wrote:
>
> Sam, 
>
> update to the latest interceptor. It has the right uv mapping for lw30x
>
> m
>
>

-- 
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: UV data not reporting in Standard skin

[Sam Roza]

Matt, it looks like I am running interceptor .12.

-SR


On Wednesday, November 16, 2016 at 7:13:38 PM UTC-8, mwall wrote:
>
> sam,
>
> the database field names are case sensitive.
>
> the default mapping for the oregon scientific lw30x is UV = uvh.?:*.*
>
> which version of the driver are you using?
>
> did you define your own sensor map?
>
> m
>

-- 
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] UV data not reporting in Standard skin

[Sam Roza]

Hello All,

I have weewx 3.6.2 running. All is well, but I don't seem to have graphs 
produced for UV data collected. Is there something that needs to be done? I 
see the if statements in the skin.conf, and the data is collected by the 
interceptor ( I can see the collected packets in syslog).

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

[weewx-user] Re: weewx with OS LW301 and interceptor driver

[Sam Roza]

On Sunday, October 9, 2016 at 4:11:39 AM UTC-7, mwall wrote:
>
>
>
> On Sunday, October 9, 2016 at 2:12:51 AM UTC-4, Sam Roza wrote:
>>
>> So, while it started working and that was great-we figured out how to get 
>> all that lw301 data into weewx (yay!)-this issue with the unsupported 
>> operand crops up often, and once it does that, I don't seem to be able to 
>> properly restart weewx using systemctl.
>>
>>
> sam,
>
> please install the latest interceptor - it includes a fix for the 
> unsupported operand (conversion of the 'uv' value) as well as a proper 
> shutdown of the sockserver.
>
> m 
>

Sorry, didn't see that. 12 dropped. I will get, that loaded...

I've had it sucvcessfully collecting data for about an hour, now. It's 
publishing to Wunderground and CWOP, too. So all is well!

Note that I needed to make a change to the capture script in order for it 
to work without barfing 20 minutes of data at once, and that was the '-u' 
flag on the sed command:

~~~
#!/bin/sh

ngrep -l -q -d eth0 '0004a369e0d6' | sed -u '/mac=/!d' | xargs -n 1 curl 
http://localhost: -s -d
~~~

Thanks for all the great assistance! I'm happy to have a reporting 
weatherstation, again.

-Sam

-- 
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: weewx with OS LW301 and interceptor driver

[Sam Roza]

t  8 22:57:43 raspberrypi weewx[1905]: interceptor: MainThread: raw data: 
mac=0004a369e0d6=90=d0=0=0=0=90=0.9=0.0=1=1
Oct  8 22:57:43 raspberrypi weewx[1905]: interceptor: MainThread: raw 
packet: {'wd.1d0.0004a369e0d6': 90.0, 'id.1d0.0004a369e0d6': '90', 
'wg.1d0.0004a369e0d6': 0.9, 'ch.1d0.0004a369e0d6': '1', 
'pwr.1d0.0004a369e0d6': '0', 'av.1d0.0004a369e0d6': '0', 'dateTime': 
1475992664, 'ws.1d0.0004a369e0d6': 0.0, 'rid.1d0.0004a369e0d6': 'd0', 
'mac.1d0.0004a369e0d6': '0004a369e0d6', 'p.1d0.0004a369e0d6': '1', 
'gw.1d0.0004a369e0d6': '0', 'usUnits': 17}
Oct  8 22:57:43 raspberrypi weewx[1905]: interceptor: MainThread: mapped 
packet: {'windDir': 90.0, 'windSpeed': 0.0, 'windGust': 0.9, 'usUnits': 17, 
'dateTime': 1475992664}
Oct  8 22:57:53 raspberrypi weewx[1905]: interceptor: MainThread: empty 
queue
Oct  8 22:58:03 raspberrypi weewx[1905]: interceptor: MainThread: empty 
queue
Oct  8 22:58:13 raspberrypi weewx[1905]: interceptor: MainThread: empty 
queue
Oct  8 22:58:16 raspberrypi weewx[1905]: interceptor: ServerThread: POST: 
mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1
Oct  8 22:58:16 raspberrypi weewx[1905]: interceptor: MainThread: raw data: 
mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1
Oct  8 22:58:16 raspberrypi weewx[1905]: interceptor: MainThread: raw 
packet: {'id..0004a369e0d6': 'c2', 'baro..0004a369e0d6': 1005.0, 
'mac..0004a369e0d6': '0004a369e0d6', 'ptr..0004a369e0d6': '0', 
'pv..0004a369e0d6': '0', 'lost..0004a369e0d6': '', 'dateTime': 
1475992696, 'reg..0004a369e0d6': '1009', 'wfor..0004a369e0d6': '0', 
'ac..0004a369e0d6': '0', 'p..0004a369e0d6': '1', 'usUnits': 17, 
'lb..0004a369e0d6': '0'}
Oct  8 22:58:16 raspberrypi weewx[1905]: interceptor: MainThread: mapped 
packet: {'barometer': 1005.0, 'usUnits': 17, 'dateTime': 1475992696}
Oct  8 22:58:26 raspberrypi weewx[1905]: interceptor: MainThread: empty 
queue
~~~

-Sam

-- 
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: weewx with OS LW301 and interceptor driver

[Sam Roza]

On Saturday, October 8, 2016 at 6:57:49 PM UTC-7, mwall wrote:
>
> btw, here it is with a better sed expression for the filter:
>
> ngrep -l -q -d eth0 '0004a369e0d6' | sed '/mac=/!d' | xargs -n 1 curl 
> http://localhost: -s -d
>
> m
>

Ah yes. That filter is a bit more efficient, isn't it? I've confirmed it 
works, too.

Unfortunately, I get nothing but empty queue messages in syslog. :

~~~
root@raspberrypi:/home/pi# ngrep -l -q -d eth0 '0004a369e0d6' | sed 
'/mac=/!d' | xargs -n 1 curl http://localhost: -s -d
~~~

Oct  8 20:09:20 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:09:30 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:09:40 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:09:50 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:09:50 raspberrypi rsyslogd-2007: action 'action 17' suspended, 
next retry is Sat Oct  8 20:11:20 2016 [try http://www.rsyslog.com/e/2007 ]
Oct  8 20:10:00 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:10:10 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:10:20 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:10:30 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:10:40 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:10:50 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:11:00 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:11:10 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:11:20 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:11:20 raspberrypi rsyslogd-2007: action 'action 17' suspended, 
next retry is Sat Oct  8 20:12:50 2016 [try http://www.rsyslog.com/e/2007 ]
Oct  8 20:11:30 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:11:40 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:11:50 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:12:00 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:12:10 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:12:20 raspberrypi weewx[676]: interceptor: MainThread: empty queue
Oct  8 20:12:30 raspberrypi weewx[676]: interceptor: MainThread: empty queue

I rebooted, just to be sure something wasn't being stupid, and it made no 
difference. I did try to unbuffer curl, but that didn't work, either. 

-- 
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: weewx with OS LW301 and interceptor driver

[Sam Roza]

On Saturday, October 8, 2016 at 2:44:15 PM UTC-7, mwall wrote:
>
>
>
> On Saturday, October 8, 2016 at 5:23:30 PM UTC-4, Sam Roza wrote:
>>
>>
>>
>> On Saturday, October 8, 2016 at 1:53:31 PM UTC-7, mwall wrote:
>>>
>>> On Saturday, October 8, 2016 at 4:29:20 PM UTC-4, Sam Roza wrote:
>>>>
>>>>
>>>> With sed command, it strips the unwanted data from the output, but for 
>>>> some reason, it's not working. I've tried with both curl and nc, but I 
>>>> don't see any issues. Is there a way to debug this?
>>>>
>>>
>>> take it one step at a time.
>>>
>>> make sure that the interceptor is actually responding.  with weewx 
>>> running and debug=1, tail the log file in one shell while you do this in 
>>> another:
>>>
>>> curl -s -d 
>>> 'mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1'
>>>  
>>> http://localhost: 
>>> <http://www.google.com/url?q=http%3A%2F%2Flocalhost%3A=D=1=AFQjCNH3GTDQFsI-ROBznvcn8KMGT66stQ>
>>>
>>> you should see a response from the interceptor in the weewx log output.  
>>> what output do you see from curl?
>>>
>>
>> >>>Here is the Interceptor response to the curl command:
>>
>> ~~~
>> Oct  8 14:02:40 raspberrypi weewx[6718]: interceptor: ServerThread: POST: 
>> mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1
>> Oct  8 14:02:40 raspberrypi weewx[6718]: interceptor: MainThread: raw 
>> data: 
>> mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1
>> Oct  8 14:02:40 raspberrypi weewx[6718]: interceptor: MainThread: raw 
>> packet: {'id..0004a369e0d6': 'c2', 'baro..0004a369e0d6': 1005.0, 
>> 'mac..0004a369e0d6': '0004a369e0d6', 'ptr..0004a369e0d6': '0', 
>> 'pv..0004a369e0d6': '0', 'lost..0004a369e0d6': '', 'dateTime': 
>> 1475960561, 'reg..0004a369e0d6': '1009', 'wfor..0004a369e0d6': '0', 
>> 'ac..0004a369e0d6': '0', 'p..0004a369e0d6': '1', 'usUnits': 17, 
>> 'lb..0004a369e0d6': '0'}
>> Oct  8 14:02:40 raspberrypi weewx[6718]: interceptor: MainThread: mapped 
>> packet: {'barometer': 1005.0, 'usUnits': 17, 'dateTime': 1475960561}
>> ~~~
>>
>> Curl just presents the screen with a new line, so the command completes.
>>  
>>
>>>
>>> from the other end, make sure that the ngrep-sed-curl chain is working.  
>>> the main thing we are looking for here is that we get one curl connection 
>>> for each line of data from ngrep.  with weewx *not* running, run 'nc -l 
>>> ' as a fake server in one shell, then do this as a 'client' in another 
>>> shell:
>>>
>>> ngrep -l -q -d eth0 '0004a369e0d6'| sed -e 's/T.*//;/^\s*$/d' | curl -s 
>>> -d @- http://localhost:
>>>
>>> what do you see in the 'server' shell, and what do you see in the 
>>> 'client' shell?  i suspect we'll have to use xargs to split the newlines 
>>> into separate curl invocations.
>>>
>>> m
>>>
>>> So, the ngrep-sed-curl chain is where it breaks down. The manual push of 
>> data using curl works. The ngrep-sed command works. Putting them together 
>> doesn't.
>>
>> I ran this command:
>>
>> # ngrep -l -q -d eth0 '0004a369e0d6'| sed -e 's/T.*//;/^\s*$/d' | curl -s 
>> -d @- http://localhost:
>>
>> While tailing /var/log/syslog:
>>
>> ~~~
>> Oct  8 14:16:03 raspberrypi weewx[6718]: interceptor: MainThread: empty 
>> queue
>> Oct  8 14:16:03 raspberrypi rsyslogd-2007: action 'action 17' suspended, 
>> next retry is Sat Oct  8 14:17:03 2016 [try http://www.rsyslog.com/e/2007 
>> ]
>> Oct  8 14:16:13 raspberrypi weewx[6718]: interceptor: MainThread: empty 
>> queue
>> Oct  8 14:16:23 raspberrypi weewx[6718]: interceptor: MainThread: empty 
>> queue
>> Oct  8 14:16:33 raspberrypi weewx[6718]: interceptor: MainThread: empty 
>> queue
>> Oct  8 14:16:43 raspberrypi weewx[6718]: interceptor: MainThread: empty 
>> queue
>> ~~~
>>
>> So during the same time, I ran another ngrep command to make sure it was 
>> picking up packets during the same period of time:
>>
>> ~~~
>> ^Croot@raspberrypi:/etc/weewx# ngrep -l -q -d eth0 '0004a369e0d6'| sed -e 
>> 's/T.*//;/^\s*$/d' 
>> interface: eth0 (192.168.1.0/255.255.255.0)
>> match: 0004a369e0d6
>>   
>> mac=0004a369e0d6=c2=0=0=0=1009==1004=0=3=1
>>  
>>  
>>   
>> mac=0004a369e0d6=90=d0=0=0=0=225=0.9=0.0=1=1 
>

[weewx-user] Re: weewx with OS LW301 and interceptor driver

[Sam Roza]

On Saturday, October 8, 2016 at 1:53:31 PM UTC-7, mwall wrote:
>
> On Saturday, October 8, 2016 at 4:29:20 PM UTC-4, Sam Roza wrote:
>>
>>
>> With sed command, it strips the unwanted data from the output, but for 
>> some reason, it's not working. I've tried with both curl and nc, but I 
>> don't see any issues. Is there a way to debug this?
>>
>
> take it one step at a time.
>
> make sure that the interceptor is actually responding.  with weewx running 
> and debug=1, tail the log file in one shell while you do this in another:
>
> curl -s -d 
> 'mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1'
>  
> http://localhost: 
> <http://www.google.com/url?q=http%3A%2F%2Flocalhost%3A=D=1=AFQjCNH3GTDQFsI-ROBznvcn8KMGT66stQ>
>
> you should see a response from the interceptor in the weewx log output.  
> what output do you see from curl?
>

>>>Here is the Interceptor response to the curl command:

~~~
Oct  8 14:02:40 raspberrypi weewx[6718]: interceptor: ServerThread: POST: 
mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1
Oct  8 14:02:40 raspberrypi weewx[6718]: interceptor: MainThread: raw data: 
mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1
Oct  8 14:02:40 raspberrypi weewx[6718]: interceptor: MainThread: raw 
packet: {'id..0004a369e0d6': 'c2', 'baro..0004a369e0d6': 1005.0, 
'mac..0004a369e0d6': '0004a369e0d6', 'ptr..0004a369e0d6': '0', 
'pv..0004a369e0d6': '0', 'lost..0004a369e0d6': '', 'dateTime': 
1475960561, 'reg..0004a369e0d6': '1009', 'wfor..0004a369e0d6': '0', 
'ac..0004a369e0d6': '0', 'p..0004a369e0d6': '1', 'usUnits': 17, 
'lb..0004a369e0d6': '0'}
Oct  8 14:02:40 raspberrypi weewx[6718]: interceptor: MainThread: mapped 
packet: {'barometer': 1005.0, 'usUnits': 17, 'dateTime': 1475960561}
~~~

Curl just presents the screen with a new line, so the command completes.
 

>
> from the other end, make sure that the ngrep-sed-curl chain is working.  
> the main thing we are looking for here is that we get one curl connection 
> for each line of data from ngrep.  with weewx *not* running, run 'nc -l 
> ' as a fake server in one shell, then do this as a 'client' in another 
> shell:
>
> ngrep -l -q -d eth0 '0004a369e0d6'| sed -e 's/T.*//;/^\s*$/d' | curl -s -d 
> @- http://localhost:
>
> what do you see in the 'server' shell, and what do you see in the 'client' 
> shell?  i suspect we'll have to use xargs to split the newlines into 
> separate curl invocations.
>
> m
>
> So, the ngrep-sed-curl chain is where it breaks down. The manual push of 
data using curl works. The ngrep-sed command works. Putting them together 
doesn't.

I ran this command:

# ngrep -l -q -d eth0 '0004a369e0d6'| sed -e 's/T.*//;/^\s*$/d' | curl -s 
-d @- http://localhost:

While tailing /var/log/syslog:

~~~
Oct  8 14:16:03 raspberrypi weewx[6718]: interceptor: MainThread: empty 
queue
Oct  8 14:16:03 raspberrypi rsyslogd-2007: action 'action 17' suspended, 
next retry is Sat Oct  8 14:17:03 2016 [try http://www.rsyslog.com/e/2007 ]
Oct  8 14:16:13 raspberrypi weewx[6718]: interceptor: MainThread: empty 
queue
Oct  8 14:16:23 raspberrypi weewx[6718]: interceptor: MainThread: empty 
queue
Oct  8 14:16:33 raspberrypi weewx[6718]: interceptor: MainThread: empty 
queue
Oct  8 14:16:43 raspberrypi weewx[6718]: interceptor: MainThread: empty 
queue
~~~

So during the same time, I ran another ngrep command to make sure it was 
picking up packets during the same period of time:

~~~
^Croot@raspberrypi:/etc/weewx# ngrep -l -q -d eth0 '0004a369e0d6'| sed -e 
's/T.*//;/^\s*$/d' 
interface: eth0 (192.168.1.0/255.255.255.0)
match: 0004a369e0d6
  
mac=0004a369e0d6=c2=0=0=0=1009==1004=0=3=1
 
 
  
mac=0004a369e0d6=90=d0=0=0=0=225=0.9=0.0=1=1 
  
~~~

I saw a note about adding the unbuffered option to sed, but that doesn't 
seem to be the issue. No change with -u option enabled.

I did want to be sure interceptor was still working, so I pushed that curl 
command again and here was the log response:

~~~
Oct  8 14:21:07 raspberrypi weewx[6718]: interceptor: ServerThread: POST: 
mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1
Oct  8 14:21:07 raspberrypi weewx[6718]: interceptor: MainThread: raw data: 
mac=0004a369e0d6=c2=0=0=0=1009==1005=0=0=1
Oct  8 14:21:07 raspberrypi weewx[6718]: interceptor: MainThread: raw 
packet: {'id..0004a369e0d6': 'c2', 'baro..0004a369e0d6': 1005.0, 
'mac..0004a369e0d6': '0004a369e0d6', 'ptr..0004a369e0d6': '0', 
'pv..0004a369e0d6': '0', 'lost..0004a369e0d6': '', 'dateTime': 
1475961667, 'reg..0004a369e0d6': '1009', 'wfor..0004a369e0d6': '0', 
'ac..0004a369e0d6': '0', 'p..0004a369e0d6': '1', 'usUnits': 17, 
'lb..0004a369e0d6': '0'}
Oct  8 14:21:07 raspberrypi weewx[6718]: interceptor: MainThread: mapped 
packet: {'barometer': 1005.0, 'usUnits': 17, 'dateTime': 1475961667}
Oct  

[weewx-user] weewx with OS LW301 and interceptor driver

[Sam Roza]

Hello All!

I've got weewx running on an rPi3, and I have the interceptor set up. All 
starts correctly, and the port is open, etc. The issue is that none of the 
packet collection methods seems to work. I am receiving error 400 from both 
tcpdump as well as ngrep commands that are piped to nc:

# tcpdump -i eth0 dst port 80 | nc 127.0.0.1 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

Error response


Error response
Error code 400.
Message: Bad request syntax ('17:12:30.097480 IP ypestis2.46860  
192.168.1.93.http: Flags [S], seq 2708070981, win 29200, options [mss 
1460,sackOK,TS val 240293608 ecr 0,nop,wscale 7], length 0').
Error code explanation: 400 = Bad request syntax or unsupported method.

85 packets captured
85 packets received by filter
0 packets dropped by kernel


Here's an example from ngrep:

~~~
 ngrep -l -q -d eth0 '0004a369e0d6'|nc localhost 

Error response


Error response
Error code 400.
Message: Bad request version ('(192.168.1.0/255.255.255.0)').
Error code explanation: 400 = Bad request syntax or unsupported method.

~~~

One of the things I'm unsure of is the format of the data expected by 
Interceptor. There aren't notes besides how to install, and how to lightly 
configure the device. I was working with Matthew on some of those things, 
and got it running on a non-standard port, which was good, but now I don't 
seem to be able to get it the last mile (to collecting actual data). I've 
been playing with the individual commands used to collect the packets, 
because Matthew's examples are for 'www.acurite.com' and Oregon Scientific 
is using AWS nodes for their cloud hosting. The plaintext mac address ngrep 
command returns nice, clean data:

~~~
T 192.168.1.73:3555 -> 54.228.205.96:80 [AP]
  
mac=0004a369e0d6=90=d0=0=0=0=270=0.9=0.0=1=1 

 

T 192.168.1.73:3556 -> 54.228.205.188:80 [AP]
  
mac=0004a369e0d6=c2=0=0=0=1009==1011=0=2=1
 
 

T 192.168.1.73:3557 -> 54.228.205.96:80 [AP]
  mac=0004a369e0d6=8e=63=0=0=1=386=1=1   


~~~

But something still seems to be wrong.

Any help that can be offered would be greatly appreciated. 

Thanks!

-Sam

-- 
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.