[weewx-user] Re: mqtt extension TLS required ?

[Andreas Landixus]

TLS is only required if you use client user/pass authentication.

MQTT post on a topic for example  "weather" is the topic "tempOut 12.02" is 
the output 
MQTT is not for human friendly output :) more for exchange data. 

Am Mittwoch, 24. Januar 2018 01:42:03 UTC+1 schrieb vince:
>
> In looking at the MQTT extension at 
> https://github.com/weewx/weewx/wiki/mqtt the code is a little unclear to 
> me.  Is TLS required for uploading weewx data to a MQTT broker ?   At line 
> 214 in the mqtt.py it "seems" like it's optional ()
>
>
> Also, is there a clean way of dumping out a what it posts to the broker in 
> some pretty(ish) human-friendly format ?   
>

-- 
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: Adding data from homemade wireless sensors to weewx

[Andreas Landixus]

https://github.com/Landixus/mqttpondWeewx 
is not working right now, but could be that i have server and client 
running on same raspberry pi
But when you test it and post errors we can investigate deeper.

Otherwise mwall has write a driver for mqtt that works i hear:
https://github.com/morrowwm/weewxMQTT

Am Dienstag, 23. Januar 2018 23:27:44 UTC+1 schrieb Steve Chiz:
>
> I, too, would be interested in this, as it seems like it would be a much 
> better way than parsing txt or xml files as I currently do for additional 
> sensors.
>
> On Thursday, January 18, 2018 at 9:04:53 AM UTC-5, Andreas Landixus wrote:
>>
>> Oh i am high interested in this service, because i want to add some 
>> sensors that publish mqtt messages.
>> Please post it.
>>
>> Am Dienstag, 12. September 2017 02:39:09 UTC+2 schrieb Dan Verbus:
>>>
>>> I've got a service written that works, if you want a copy. Each sensor 
>>> publishes to it's own MQTT topic and the service reads off the queue 
>>> whenever it receives a loop packet and appends whatever data it finds. Let 
>>> me know and I'll post it.
>>>
>>> Dan
>>>
>>>
>>> On Wednesday, June 21, 2017 at 7:37:28 PM UTC-4, Craig Thom wrote:

 Thanks.  I'm using the sdr driver, so I'm leaning toward a service, and 
 I've already got a little experience writing one.

 On Tuesday, June 20, 2017 at 6:05:12 PM UTC-4, Neville Davis wrote:
>
> In getting the data into weewx.I have a number of different 
> sensors i2C one wire and data from a web sever (json) from my 
> Airconditioner...all being input to weewx.
>
> My basic method is to get data as a csv file by running scripts from 
> boot ( i have 3 of these files being generated in a ramdisk) and then I 
> use 
> 2 methods...a driver the get all the weather data and a weewx service to 
> get the data from the aircon. The following is a screen shot of the 
> current 
> conditions.
>
>
>
> On Monday, June 19, 2017 at 10:43:33 PM UTC+10, Craig Thom wrote:
>>
>> Thanks.  My question is really about getting the data into weewx, but 
>> I'll worry about that later.
>>
>> After another message about the sensors themselves, I've decided to 
>> go with low power 915MHz radio using the mysensors org protocol.  I 
>> should 
>> be able to get many months from 3xAA batteries.  The parts are coming 
>> from 
>> China, so I've got a month or two to think about getting them into 
>> weewx. 
>>  It will probably be after the eclipse, since I'll be spending 
>> increasing 
>> time testing the hardware and software to photograph it.
>>
>> So sensors through mysensors hub to MQTT broker, and then somehow 
>> into weewx.  In August.
>>
>> On Wednesday, June 14, 2017 at 11:28:27 AM UTC-4, Paul Bartholdi 
>> wrote:
>>>
>>> Hello,
>>>
>>> It could be good to have a look at "http://www.yoctopuce.com;. The 
>>> company is based in Geneva, Switzerland, but send products worldwide, 
>>> with 
>>> typical Swiss high quality. They have extremely low power hubs usb --> 
>>> Ethernet, gsm or WiFi, which can put all the boards asleep and wake up 
>>> only 
>>> on command from central PC. Boards include barometer, temperature(s), 
>>> humidity, light and many other possibilities not so much related to 
>>> weather 
>>> station. Software exists for most high level languages (C, C++, Java, 
>>> Python, shell (bash) etc.).
>>> MQTT looks very interesting, but I had no time yet to play with it.  
>>> To interface other programs with weewx data, I simply interrogate the 
>>> database (mysql).
>>> Hope this helps. Paul
>>>
>>> On Tuesday, June 13, 2017 at 3:53:48 PM UTC+2, Craig Thom wrote:

 tl;dr What's the best way of getting home brew wireless sensor data 
 into weewx?

 I plan to build a soil moisture (and temperature) sensor for my 
 garden bed.  I'll likely build another for leaf wetness and UV index, 
 because the sensors are cheap and it will be fun.

 The question is how best to get this data to weewx.  I am already 
 using the SDR driver for my Acurite 5-in-1 and additional sensors.

 I could use a 433MHz transmitter.  I think, though, I'd have to 
 decide on how to make a packet, then modify rtl_433 to recognize that 
 packet, then modify SDR.py to use that new rtl_433 packet.  This seems 
 pretty complicated.

 Or, since these sensors will be within range of wifi, I could use 
 an ESP2866.  This is attractive because the microcontroller for 
 reading the 
 sensor and processing the data is in the same package.  I really like 
 this 
 idea.

 But how do I get the data to weewx?

 Because the sensor will be running 

[weewx-user] Re: WMR300 testing LAST Driver

[mwall]

On Tuesday, January 23, 2018 at 2:13:07 PM UTC-5, Ruben Navarro Huedo wrote:
>
>
> Again "LOOP" and shutdown :-(
>

ruben,

please try v0.19rc5

https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/wmr300.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.

Re: [weewx-user] Distance on the sky between planets

[Thomas Keffer]

Included as commit 16e0c5d

.

-tk

On Tue, Jan 23, 2018 at 5:57 PM, Thomas Keffer  wrote:

> It was such an easy extension, I'd say yes. Thanks for "testing" it!
>
> -tk
>
> On Tue, Jan 23, 2018 at 3:07 PM, Paul Bartholdi 
> wrote:
>
>> Thank you very much Thomas, as usual it works immediately!
>> Will the "new" alamanac.py be part of the next version?
>> Regards,Paul
>>
>> On 23 January 2018 at 20:14, Thomas Keffer  wrote:
>>
>>> ​Separation is not supported in v3.8, but it would not be hard to add.
>>> Try the attached version of almanac.py
>>>
>>> -tk​
>>>
>>> On Tue, Jan 23, 2018 at 11:26 AM, Paul Bartholdi <
>>> paul.bartho...@gmail.com> wrote:
>>>
 Hello,

 I would like to add in the "almanac" part of the main weewx page the
 distance on the sky between planets, as between Mars and Jupiter these
 days. I know how to use "IF...THEN" to select only the interesting ones.

 I know more or less how to play with almanac and ephem (see my page "
 http://shire-bdi.gotdns.com/weewx;), though I have very little
 experience with python.
 I am aware in ephem of the "separation" on the sky between two
 celestial bodies, but have not been able to got anything working.

 I tried something like

#set $dvm = $almanac.separation(($almanac.venus.alt,$
 almanac.venus.az), ($almanac.mars.alt,$almanac.mars.az))

 but all attempts have been rejected because it uses 3 (!) parameters
 which is not supported.

 Most probably I started in the wrong direction. Could you put me back
 on the right rails?

 Thank you very much in advance,   Paul

 --
 You received this message because you are subscribed to the Google
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to weewx-user+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "weewx-user" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/weewx-user/_G26k2zKxuM/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> weewx-user+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-user+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Distance on the sky between planets

[Thomas Keffer]

It was such an easy extension, I'd say yes. Thanks for "testing" it!

-tk

On Tue, Jan 23, 2018 at 3:07 PM, Paul Bartholdi 
wrote:

> Thank you very much Thomas, as usual it works immediately!
> Will the "new" alamanac.py be part of the next version?
> Regards,Paul
>
> On 23 January 2018 at 20:14, Thomas Keffer  wrote:
>
>> ​Separation is not supported in v3.8, but it would not be hard to add.
>> Try the attached version of almanac.py
>>
>> -tk​
>>
>> On Tue, Jan 23, 2018 at 11:26 AM, Paul Bartholdi <
>> paul.bartho...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I would like to add in the "almanac" part of the main weewx page the
>>> distance on the sky between planets, as between Mars and Jupiter these
>>> days. I know how to use "IF...THEN" to select only the interesting ones.
>>>
>>> I know more or less how to play with almanac and ephem (see my page "
>>> http://shire-bdi.gotdns.com/weewx;), though I have very little
>>> experience with python.
>>> I am aware in ephem of the "separation" on the sky between two celestial
>>> bodies, but have not been able to got anything working.
>>>
>>> I tried something like
>>>
>>>#set $dvm = $almanac.separation(($almanac.venus.alt,$almanac.venus.az),
>>> ($almanac.mars.alt,$almanac.mars.az))
>>>
>>> but all attempts have been rejected because it uses 3 (!) parameters
>>> which is not supported.
>>>
>>> Most probably I started in the wrong direction. Could you put me back on
>>> the right rails?
>>>
>>> Thank you very much in advance,   Paul
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-user+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/weewx-user/_G26k2zKxuM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> weewx-user+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] mqtt extension TLS required ?

[vince]

In looking at the MQTT extension 
at https://github.com/weewx/weewx/wiki/mqtt the code is a little unclear to 
me.  Is TLS required for uploading weewx data to a MQTT broker ?   At line 
214 in the mqtt.py it "seems" like it's optional ()


Also, is there a clean way of dumping out a what it posts to the broker in 
some pretty(ish) human-friendly format ?   

-- 
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: Adding data from homemade wireless sensors to weewx

[Steve Chiz]

I, too, would be interested in this, as it seems like it would be a much 
better way than parsing txt or xml files as I currently do for additional 
sensors.

On Thursday, January 18, 2018 at 9:04:53 AM UTC-5, Andreas Landixus wrote:
>
> Oh i am high interested in this service, because i want to add some 
> sensors that publish mqtt messages.
> Please post it.
>
> Am Dienstag, 12. September 2017 02:39:09 UTC+2 schrieb Dan Verbus:
>>
>> I've got a service written that works, if you want a copy. Each sensor 
>> publishes to it's own MQTT topic and the service reads off the queue 
>> whenever it receives a loop packet and appends whatever data it finds. Let 
>> me know and I'll post it.
>>
>> Dan
>>
>>
>> On Wednesday, June 21, 2017 at 7:37:28 PM UTC-4, Craig Thom wrote:
>>>
>>> Thanks.  I'm using the sdr driver, so I'm leaning toward a service, and 
>>> I've already got a little experience writing one.
>>>
>>> On Tuesday, June 20, 2017 at 6:05:12 PM UTC-4, Neville Davis wrote:

 In getting the data into weewx.I have a number of different sensors 
 i2C one wire and data from a web sever (json) from my Airconditioner...all 
 being input to weewx.

 My basic method is to get data as a csv file by running scripts from 
 boot ( i have 3 of these files being generated in a ramdisk) and then I 
 use 
 2 methods...a driver the get all the weather data and a weewx service to 
 get the data from the aircon. The following is a screen shot of the 
 current 
 conditions.



 On Monday, June 19, 2017 at 10:43:33 PM UTC+10, Craig Thom wrote:
>
> Thanks.  My question is really about getting the data into weewx, but 
> I'll worry about that later.
>
> After another message about the sensors themselves, I've decided to go 
> with low power 915MHz radio using the mysensors org protocol.  I should 
> be 
> able to get many months from 3xAA batteries.  The parts are coming from 
> China, so I've got a month or two to think about getting them into weewx. 
>  It will probably be after the eclipse, since I'll be spending increasing 
> time testing the hardware and software to photograph it.
>
> So sensors through mysensors hub to MQTT broker, and then somehow into 
> weewx.  In August.
>
> On Wednesday, June 14, 2017 at 11:28:27 AM UTC-4, Paul Bartholdi wrote:
>>
>> Hello,
>>
>> It could be good to have a look at "http://www.yoctopuce.com;. The 
>> company is based in Geneva, Switzerland, but send products worldwide, 
>> with 
>> typical Swiss high quality. They have extremely low power hubs usb --> 
>> Ethernet, gsm or WiFi, which can put all the boards asleep and wake up 
>> only 
>> on command from central PC. Boards include barometer, temperature(s), 
>> humidity, light and many other possibilities not so much related to 
>> weather 
>> station. Software exists for most high level languages (C, C++, Java, 
>> Python, shell (bash) etc.).
>> MQTT looks very interesting, but I had no time yet to play with it.  
>> To interface other programs with weewx data, I simply interrogate the 
>> database (mysql).
>> Hope this helps. Paul
>>
>> On Tuesday, June 13, 2017 at 3:53:48 PM UTC+2, Craig Thom wrote:
>>>
>>> tl;dr What's the best way of getting home brew wireless sensor data 
>>> into weewx?
>>>
>>> I plan to build a soil moisture (and temperature) sensor for my 
>>> garden bed.  I'll likely build another for leaf wetness and UV index, 
>>> because the sensors are cheap and it will be fun.
>>>
>>> The question is how best to get this data to weewx.  I am already 
>>> using the SDR driver for my Acurite 5-in-1 and additional sensors.
>>>
>>> I could use a 433MHz transmitter.  I think, though, I'd have to 
>>> decide on how to make a packet, then modify rtl_433 to recognize that 
>>> packet, then modify SDR.py to use that new rtl_433 packet.  This seems 
>>> pretty complicated.
>>>
>>> Or, since these sensors will be within range of wifi, I could use an 
>>> ESP2866.  This is attractive because the microcontroller for reading 
>>> the 
>>> sensor and processing the data is in the same package.  I really like 
>>> this 
>>> idea.
>>>
>>> But how do I get the data to weewx?
>>>
>>> Because the sensor will be running on batteries (and maybe solar 
>>> cells for the UV/leaf wetness one), I do not want to turn on the wifi 
>>> radio 
>>> except when absolutely necessary, so weewx will not be able to initiate 
>>> contact.
>>>
>>> My first thought was to use ftp, so the sensor connects to an FTP 
>>> server on my network, probably on the RPi running weewx, and dumps a 
>>> file. 
>>>  Then I could write a service within weewx to check for that file, read 
>>> it, 
>>> and add the 

Re: [weewx-user] Distance on the sky between planets

[Paul Bartholdi]

Thank you very much Thomas, as usual it works immediately!
Will the "new" alamanac.py be part of the next version?
Regards,Paul

On 23 January 2018 at 20:14, Thomas Keffer  wrote:

> ​Separation is not supported in v3.8, but it would not be hard to add. Try
> the attached version of almanac.py
>
> -tk​
>
> On Tue, Jan 23, 2018 at 11:26 AM, Paul Bartholdi  > wrote:
>
>> Hello,
>>
>> I would like to add in the "almanac" part of the main weewx page the
>> distance on the sky between planets, as between Mars and Jupiter these
>> days. I know how to use "IF...THEN" to select only the interesting ones.
>>
>> I know more or less how to play with almanac and ephem (see my page "
>> http://shire-bdi.gotdns.com/weewx;), though I have very little
>> experience with python.
>> I am aware in ephem of the "separation" on the sky between two celestial
>> bodies, but have not been able to got anything working.
>>
>> I tried something like
>>
>>#set $dvm = $almanac.separation(($almanac.venus.alt,$almanac.venus.az),
>> ($almanac.mars.alt,$almanac.mars.az))
>>
>> but all attempts have been rejected because it uses 3 (!) parameters
>> which is not supported.
>>
>> Most probably I started in the wrong direction. Could you put me back on
>> the right rails?
>>
>> Thank you very much in advance,   Paul
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-user+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/weewx-user/_G26k2zKxuM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Distance on the sky between planets

[Thomas Keffer]

​Separation is not supported in v3.8, but it would not be hard to add. Try
the attached version of almanac.py

-tk​

On Tue, Jan 23, 2018 at 11:26 AM, Paul Bartholdi 
wrote:

> Hello,
>
> I would like to add in the "almanac" part of the main weewx page the
> distance on the sky between planets, as between Mars and Jupiter these
> days. I know how to use "IF...THEN" to select only the interesting ones.
>
> I know more or less how to play with almanac and ephem (see my page "
> http://shire-bdi.gotdns.com/weewx;), though I have very little experience
> with python.
> I am aware in ephem of the "separation" on the sky between two celestial
> bodies, but have not been able to got anything working.
>
> I tried something like
>
>#set $dvm = $almanac.separation(($almanac.venus.alt,$almanac.venus.az),
> ($almanac.mars.alt,$almanac.mars.az))
>
> but all attempts have been rejected because it uses 3 (!) parameters
> which is not supported.
>
> Most probably I started in the wrong direction. Could you put me back on
> the right rails?
>
> Thank you very much in advance,   Paul
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#
#Copyright (c) 2009-2015 Tom Keffer 
#
#See the file LICENSE.txt for your full rights.
#
"""Almanac data

This module can optionally use PyEphem, which offers high quality
astronomical calculations. See http://rhodesmill.org/pyephem. """

import time
import sys
import math
import copy

import weeutil.Moon
import weewx.units

# If the user has installed ephem, use it. Otherwise, fall back to the weeutil algorithms:
try:
import ephem
except ImportError:
import weeutil.Sun

# NB: Have Almanac inherit from 'object'. However, this will cause 
# an 'autocall' bug in Cheetah versions before 2.1.
class Almanac(object):
"""Almanac data.

ATTRIBUTES.

As a minimum, the following attributes are available:

sunrise: Time (local) upper limb of the sun rises above the horizon, formatted using the format 'timeformat'.
sunset: Time (local) upper limb of the sun sinks below the horizon, formatted using the format 'timeformat'.
moon_phase: A description of the moon phase(eg. "new moon", Waxing crescent", etc.)
moon_fullness: Percent fullness of the moon (0=new moon, 100=full moon)

If the module 'ephem' is used, them many other attributes are available.
Here are a few examples:

sun.rise: Time upper limb of sun will rise above the horizon today in unix epoch time
sun.transit: Time of transit today (sun over meridian) in unix epoch time
sun.previous_sunrise: Time of last sunrise in unix epoch time
sun.az: Azimuth (in degrees) of sun
sun.alt: Altitude (in degrees) of sun
mars.rise: Time when upper limb of mars will rise above horizon today in unix epoch time
mars.ra: Right ascension of mars
etc.

EXAMPLES:

These examples are designed to work in the Pacific timezone
>>> import os
>>> os.environ['TZ'] = 'America/Los_Angeles'
>>> t = 1238180400
>>> print timestamp_to_string(t)
2009-03-27 12:00:00 PDT (1238180400)

Test conversions to Dublin Julian Days
>>> t_djd = timestamp_to_djd(t)
>>> print "%.5f" % t_djd
39898.29167

Test the conversion back
>>> print "%.0f" % djd_to_timestamp(t_djd)
1238180400

>>> almanac = Almanac(t, 46.0, -122.0)

Test backwards compatibility with attribute 'moon_fullness':
>>> print "Fullness of the moon (rounded) is %.2f%% [%s]" % (almanac.moon_fullness, almanac.moon_phase)
Fullness of the moon (rounded) is 2.00% [new (totally dark)]

Now get a more precise result for fullness of the moon:
>>> print "Fullness of the moon (more precise) is %.2f%%" % almanac.moon.moon_fullness
Fullness of the moon (more precise) is 1.70%

Test backwards compatibility with attributes 'sunrise' and 'sunset'
>>> print "Sunrise, sunset:", almanac.sunrise, almanac.sunset
Sunrise, sunset: 06:56 19:30

Get sunrise, sun transit, and sunset using the new 'ephem' syntax:
>>> print "Sunrise, sun transit, sunset:", almanac.sun.rise, almanac.sun.transit, almanac.sun.set
Sunrise, sun transit, sunset: 06:56 13:13 19:30

Do the same with the moon:
>>> print "Moon rise, transit, set:", almanac.moon.rise, almanac.moon.transit, almanac.moon.set
Moon rise, 

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

Again "LOOP" and shutdown :-(

Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:18 CET (1516635078) (last_index=21390 latest_index=21391)
Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:18 CET (1516635078) (last_index=21390 latest_index=21391)
Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:19 CET (1516635079) (last_index=21390 latest_index=21391)
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:19 CET (1516635079) (last_index=21390 latest_index=21391)
Jan 22 16:31:20 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:20 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:20 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:20 CET (1516635080) (last_index=21390 latest_index=21391)
Jan 22 16:31:20 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:21 CET (1516635081) (last_index=21390 latest_index=21391)
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:21 CET (1516635081) (last_index=21390 latest_index=21391)
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:21 MeteoElche systemd[1]: Stopping LSB: weewx weather system...
Jan 22 16:31:21 MeteoElche weewx[15491]: engine: Shutting down StdReport 
thread
Jan 22 16:31:28 MeteoElche weewx[15491]: ftpgenerator: ftp'd 126 files in 
52.22 seconds
Jan 22 16:31:28 MeteoElche weewx[15491]: engine: Terminating weewx version 
3.8.0
Jan 22 16:31:32 MeteoElche weewx[15718]: Stopping weewx weather system: 
weewx...

El martes, 23 de enero de 2018, 16:01:50 (UTC+1), sina...@gmail.com 
escribió:
>
> hey, can you upload to wunderground with rapidfire? Im too far from my 
> wmr300 I cant remote control and give me wu ıd please, thanks a lot
>
> 22 Ocak 2018 Pazartesi 14:48:27 UTC+3 tarihinde Ruben Navarro Huedo yazdı:
>>
>> Hello:
>>
>> Testing last WMR300 driver:
>>
>> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: dump history
>> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: reading records since 
>> 2018-01-22 12:45:42 CET (1516621542) (last_index=21345 latest_index=21346)
>> Jan 22 12:45:47 MeteoElche weewx[1500]: engine: Caught unrecoverable 
>> exception in engine:
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   list index out of range
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   Traceback (most recent 
>> call last):
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/engine.py", line 871, in main
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   engine.run()
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/engine.py", line 187, in run
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   for packet in 
>> self.console.genLoopPackets():
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1263, in genLoopPackets
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   self.dump_history()
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1147, in dump_history
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   for rec in 
>> self.get_history(time.time(), clear_logger=True):
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1160, in get_history
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   
>> self.init_history(clear_logger)
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1089, in init_history
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   if buf is None or 
>> buf[0] != 0x41:
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   IndexError: list index 
>> out of range
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   Exiting.
>>
>>
>>
>>

-- 
You received this 

[weewx-user] Distance on the sky between planets

[Paul Bartholdi]

Hello,

I would like to add in the "almanac" part of the main weewx page the 
distance on the sky between planets, as between Mars and Jupiter these 
days. I know how to use "IF...THEN" to select only the interesting ones.

I know more or less how to play with almanac and ephem (see my page 
"http://shire-bdi.gotdns.com/weewx;), though I have very little experience 
with python.  
I am aware in ephem of the "separation" on the sky between two celestial 
bodies, but have not been able to got anything working.

I tried something like

   #set $dvm = $almanac.separation(($almanac.venus.alt,$almanac.venus.az), 
($almanac.mars.alt,$almanac.mars.az))

but all attempts have been rejected because it uses 3 (!) parameters which 
is not supported.

Most probably I started in the wrong direction. Could you put me back on 
the right rails?

Thank you very much in advance,   Paul

-- 
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: Davis Vantage Pro2 on RPI, problem with console time adjustment

[Thomas Keffer]

A pull request that does this, while not breaking compatibility with other
weather stations that do not have this feature (i.e., most), would be
welcome.

-tk

On Tue, Jan 23, 2018 at 9:55 AM, John  wrote:

> IMO, adding a RTC to an internet connected device seems redundant and
> doubly redundant when already connected to a device with a battery backed
> RTC like the Davis Vantage console.
>
> browsing the vantage drive source there is already code for retrieving the
> console time.
>
> compare the retrieved time from the console to rpi system time, if more
> than max_drift make a call to set system time. this would remedy the OP's
> problem.
>
> when the rpi gets a time update from an NTP source weewx will compare and
> update the time on the console.
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Davis Vantage Pro2 on RPI, problem with console time adjustment

[vince]

On Monday, January 22, 2018 at 7:06:48 PM UTC-8, John wrote:
>
> for setups with a Davis console it would be nice to configure the rpi to 
> get time from the console as an alternate option to a RTC.  
>
> Once time is updated from an NTP source, then both the rpi and the console 
> could be updated.
>

Just disable fake-hwclock on the pi and run a NTP client.  Done and done.

-- 
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: Davis Vantage Pro2 on RPI, problem with console time adjustment

[John]

IMO, adding a RTC to an internet connected device seems redundant and 
doubly redundant when already connected to a device with a battery backed 
RTC like the Davis Vantage console. 

browsing the vantage drive source there is already code for retrieving the 
console time. 

compare the retrieved time from the console to rpi system time, if more 
than max_drift make a call to set system time. this would remedy the OP's 
problem.  

when the rpi gets a time update from an NTP source weewx will compare and 
update the time on the console. 

-- 
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 avg winddir and wind

[Andrew Milner]

If you are seeing odd things on the WU site - it is their problem!!

I output only archive data every 5 minutes

I just watched my site on WU and in the space of 2 minutes WU said I last 
reported 6 inutes ago, 3 minutes ago, 6 seconds ago, 1 minute ago, 2 
minutes ago and so on
During that same period the wind direction changed, the gust speed changed, 
and the wind average speed changed

How WU managed to do all this in a 2 minute period, with at most one extra 
report from me defies all logic!!  I do not use rapidfire at all.  Where 
these other values were coming from I have no idea!!

The only convincing information is the contents of LOOP, REC and as Gary 
suggested the debug info to see what data is actually being sent to WU



On Tuesday, 23 January 2018 16:56:25 UTC+2, sina...@gmail.com wrote:

> my english is not good enough fyi, alright then. in wunderground rapidfire 
> wind gust updates every 2.5 seconds but I cant say this stuff for wind and 
> wind direction. I hope we can understand each other easily, thanks a lot.
>
> 23 Ocak 2018 Salı 11:09:16 UTC+3 tarihinde Andrew Milner yazdı:
>>
>> I still do not understand exactly.  The wmr300 outputs what is known as 
>> 'partial packets' - this means it does not output every reading in every 
>> packet.  See the weewx hardware manual for more information.
>>
>> windgust updates every 2.5 seconds - where??  On console?? in weewx LOOP 
>> packet??, in weewx REC packet??, in wunderground rapidfire??  in 
>> wunderground table??
>> wind and wind direction update every 5 minutes - where??  On console??  
>> in weewx LOOP packet??  In weewx REC packet??  in archive database??  On 
>> wunderground table??
>>
>> the wind and winddir should indeed be updated in LOOP data every 2-3 
>> seconds, but weewx only updates pages every archive interval ie every 5 
>> minutes if that is your archive period.  Weewx does not do a realtime 
>> display although there is the meso extension and others that can provide 
>> real time displays from LOOP data.
>>
>> Normally weewx only updates wunderground every archive interval also, but 
>> rapidfire can be invoked.  wunderground do however say to use either 
>> rapidfire or archive interval, and not both.  |Rapidfire with wmr300 can be 
>> problematic as not all data is in every loop packet, and weewx has had to 
>> implement a form of cache to try and cope with the wmr300 and rapidfire.
>>
>> Perhaps you could try and explain in more detail what the problem is 
>> please, what you are trying to achieve and what is happening that is not 
>> correct.  The more detail you give us the more chance we have of explaining 
>> or helping.
>>
>>
>>
>> On Tuesday, 23 January 2018 09:52:07 UTC+2, 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 disable send avg winddir 
 and wind speed to wunderground. How can I send wind direction what it 
 measures in every 2.5 seconds? 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: WMR300 testing LAST Driver

[sinantc34]

hey, can you upload to wunderground with rapidfire? Im too far from my 
wmr300 I cant remote control and give me wu ıd please, thanks a lot

22 Ocak 2018 Pazartesi 14:48:27 UTC+3 tarihinde Ruben Navarro Huedo yazdı:
>
> Hello:
>
> Testing last WMR300 driver:
>
> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: dump history
> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: reading records since 
> 2018-01-22 12:45:42 CET (1516621542) (last_index=21345 latest_index=21346)
> Jan 22 12:45:47 MeteoElche weewx[1500]: engine: Caught unrecoverable 
> exception in engine:
> Jan 22 12:45:47 MeteoElche weewx[1500]:   list index out of range
> Jan 22 12:45:47 MeteoElche weewx[1500]:   Traceback (most recent 
> call last):
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/engine.py", line 871, in main
> Jan 22 12:45:47 MeteoElche weewx[1500]:   engine.run()
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/engine.py", line 187, in run
> Jan 22 12:45:47 MeteoElche weewx[1500]:   for packet in 
> self.console.genLoopPackets():
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1263, in genLoopPackets
> Jan 22 12:45:47 MeteoElche weewx[1500]:   self.dump_history()
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1147, in dump_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   for rec in 
> self.get_history(time.time(), clear_logger=True):
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1160, in get_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   
> self.init_history(clear_logger)
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1089, in init_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   if buf is None or 
> buf[0] != 0x41:
> Jan 22 12:45:47 MeteoElche weewx[1500]:   IndexError: list index 
> out of range
> Jan 22 12:45:47 MeteoElche weewx[1500]:   Exiting.
>
>
>
>

-- 
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 avg winddir and wind

[sinantc34]

my english is not good enough fyi, alright then. in wunderground rapidfire 
wind gust updates every 2.5 seconds but I cant say this stuff for wind and 
wind direction. I hope we can understand each other easily, thanks a lot.

23 Ocak 2018 Salı 11:09:16 UTC+3 tarihinde Andrew Milner yazdı:
>
> I still do not understand exactly.  The wmr300 outputs what is known as 
> 'partial packets' - this means it does not output every reading in every 
> packet.  See the weewx hardware manual for more information.
>
> windgust updates every 2.5 seconds - where??  On console?? in weewx LOOP 
> packet??, in weewx REC packet??, in wunderground rapidfire??  in 
> wunderground table??
> wind and wind direction update every 5 minutes - where??  On console??  in 
> weewx LOOP packet??  In weewx REC packet??  in archive database??  On 
> wunderground table??
>
> the wind and winddir should indeed be updated in LOOP data every 2-3 
> seconds, but weewx only updates pages every archive interval ie every 5 
> minutes if that is your archive period.  Weewx does not do a realtime 
> display although there is the meso extension and others that can provide 
> real time displays from LOOP data.
>
> Normally weewx only updates wunderground every archive interval also, but 
> rapidfire can be invoked.  wunderground do however say to use either 
> rapidfire or archive interval, and not both.  |Rapidfire with wmr300 can be 
> problematic as not all data is in every loop packet, and weewx has had to 
> implement a form of cache to try and cope with the wmr300 and rapidfire.
>
> Perhaps you could try and explain in more detail what the problem is 
> please, what you are trying to achieve and what is happening that is not 
> correct.  The more detail you give us the more chance we have of explaining 
> or helping.
>
>
>
> On Tuesday, 23 January 2018 09:52:07 UTC+2, 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 disable send avg winddir 
>>> and wind speed to wunderground. How can I send wind direction what it 
>>> measures in every 2.5 seconds? 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: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

Now is running fine with no modification:

Jan 23 13:20:52 MeteoElche weewx[16384]: restx: WeatherCloud: service 
version is 0.10
Jan 23 13:20:52 MeteoElche weewx[16384]: restx: WeatherCloud: Data will be 
uploaded for id=82ffe1c4671ee036
Jan 23 13:20:52 MeteoElche weewx[16384]: engine: Starting up weewx version 
3.8.0
Jan 23 13:20:52 MeteoElche weewx[16384]: wmr300: reading records since 
2018-01-23 13:20:00 CET (151671) (last_index=31 latest_index=314)
Jan 23 13:20:53 MeteoElche weewx[16384]: wmr300: catchup complete: count=0 
last_index=313 latest_index=314
Jan 23 13:20:53 MeteoElche weewx[16384]: engine: Starting main packet loop.
Jan 23 13:20:55 MeteoElche weewx[16384]: wmr300: possible missed rain 
event: new=195.58 old=None
Jan 23 13:20:55 MeteoElche weewx[16384]: wmr300: rain=None 
rain_total=195.58 last_rain=None
Jan 23 13:21:12 MeteoElche weewx[16384]: wmr300: history buffer at 0.9%


El lunes, 22 de enero de 2018, 21:33:23 (UTC+1), Ruben Navarro Huedo 
escribió:
>
> Attached text file.
>
> El lunes, 22 de enero de 2018, 17:52:21 (UTC+1), mwall escribió:
>>
>> On Monday, January 22, 2018 at 10:31:05 AM UTC-5, Ruben Navarro Huedo 
>> wrote:
>>>
>>> A lot of thank's to you.
>>> It has started but i think we have a loop:
>>>
>>
>> not an infinite loop.  but your hardware is not responding the way other 
>> hardware has responded.
>>
>> please post the entire log from the time that weewx starts up.
>>
>> it would also help if you set debug like this:
>>
>> debug=1
>> [WMR300]
>> debug_comm = 1
>> debug_packet = 0
>> debug_counts = 0
>> debug_decode = 0
>> debug_history = 1
>> debug_rain = 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 avg winddir and wind

[gjr80]

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 


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 
 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 disable send avg winddir 
>> and wind speed to wunderground. How can I send wind direction what it 
>> measures in every 2.5 seconds? 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: wmr300 avg winddir and wind

[Andrew Milner]

I still do not understand exactly.  The wmr300 outputs what is known as 
'partial packets' - this means it does not output every reading in every 
packet.  See the weewx hardware manual for more information.

windgust updates every 2.5 seconds - where??  On console?? in weewx LOOP 
packet??, in weewx REC packet??, in wunderground rapidfire??  in 
wunderground table??
wind and wind direction update every 5 minutes - where??  On console??  in 
weewx LOOP packet??  In weewx REC packet??  in archive database??  On 
wunderground table??

the wind and winddir should indeed be updated in LOOP data every 2-3 
seconds, but weewx only updates pages every archive interval ie every 5 
minutes if that is your archive period.  Weewx does not do a realtime 
display although there is the meso extension and others that can provide 
real time displays from LOOP data.

Normally weewx only updates wunderground every archive interval also, but 
rapidfire can be invoked.  wunderground do however say to use either 
rapidfire or archive interval, and not both.  |Rapidfire with wmr300 can be 
problematic as not all data is in every loop packet, and weewx has had to 
implement a form of cache to try and cope with the wmr300 and rapidfire.

Perhaps you could try and explain in more detail what the problem is 
please, what you are trying to achieve and what is happening that is not 
correct.  The more detail you give us the more chance we have of explaining 
or helping.



On Tuesday, 23 January 2018 09:52:07 UTC+2, 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 disable send avg winddir 
>> and wind speed to wunderground. How can I send wind direction what it 
>> measures in every 2.5 seconds? 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.