[weewx-user] Re: Radiation, maxSolarRad and ET/Evapotranspiration calculation - weewx/Belchertown skin

[Xant]

Pat & All

Apologies as I thought Acurite Atlas to be capable of acquiring Radiation 
data... apparently not.

Although, SolarRad & UV Belchertown skin has 3 variants: Radiation, 
Theoretical Max Solar Radiation, UV. Lets disregard Radiation and still try 
[[solarRadGraph]] to plot Theo Max Solar Rad and UV.

For this "test":

Try 1) Commenting
In weewx.conf [[Calculations]], post maxSolarRad = software
In graph.conf [[solarRadGraph]], commented the section of Radiation
--> didn't work, Error

Try 2) Rad zero
In weewx.conf [[Calculations]], post maxSolarRad = software; and in 
[[[Generic]]] radiation = 0 ("zero')
In graph.conf [[solarRadGraph]], as posted (no commeting on Radiation 
section)
--> didn't work, Error

root@raspberrypi:~# wee_reports
Using configuration file /etc/weewx/weewx.conf
Generating for all time
Traceback (most recent call last):
  File "/usr/share/weewx/weewx/reportengine.py", line 204, in run
obj.start()
  File "/usr/share/weewx/weewx/reportengine.py", line 300, in start
self.run()
  File "/usr/share/weewx/user/belchertown.py", line 1133, in run
series_data = self._getObservationData(observation_type, minstamp, 
maxstamp, aggregate_type, aggregate_interval, time_length, xaxis_groupby, 
xaxis_categories, mirrored_value)
  File "/usr/share/weewx/user/belchertown.py", line 1530, in 
_getObservationData
(time_start_vt, time_stop_vt, obs_vt) = 
self.db_lookup().getSqlVectors(TimeSpan(start_ts, end_ts), obs_lookup, 
aggregate_type, aggregate_interval)
  File "/usr/share/weewx/weewx/manager.py", line 513, in getSqlVectors
aggregate_type, aggregate_interval)
  File "/usr/share/weewx/weewx/manager.py", line 790, in _getSqlVectors
for _rec in _cursor.execute(sql_str, (startstamp, stopstamp)):
  File "/usr/share/weewx/weedb/sqlite.py", line 41, in guarded_fn
raise weedb.NoColumnError(e)
NoColumnError: no such column: maxSolarRad


Bottom line, if Radiation not available through Acurite Atlas, I would not 
mind having Theo Max Theo Solar Rad x UV...



Thanks for any suggestions.

Best, AE

-- 
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/fa7f8df8-f2da-44bc-b5a4-37338a79cb4e%40googlegroups.com.

[weewx-user] Re: WS-1001 connection to Raspberry PI for Weewx

[Susan Mackay]

In the weewx.conf file, you can uncomment the 'ip_address_mask' line and 
set it to whatever is the correct address mask for your network.
The HP1000 code must be running on a computer that is on the same network 
sub-net as the weather console. Setting the 'ip_address_mask' overrides the 
automatic selection of the computers IP address as the default.
Failing that,if you know Python, then go into the HP1000.py code and remove 
the stat of the 'connectToWeatherStation' function and set 'self.ws_socket' 
to be an open connection to the remote IP address.
Susan

On Tuesday, July 30, 2019 at 4:55:44 AM UTC+10, Bill Volz wrote:
>
> I had this working for 2 years but it stopped Saturday. I got it working 2 
> years ago and don't quite recall what I did. I think I used EasyWeatherIP 
> to change web page in the setup page from "www.wunderground.com' to 
> 'www.***.com". Now when I try to change it with EWIP, it doesn't make the 
> change - it has made other changes. Not sure if there is a trick. I've 
> tried to install HP1001 but it times out and can't find the WS-1001. Is 
> there a way to tell HP1001 what the IP address of the WS_1001 is - I have 
> it on a static address using the MAC address on my router. I tried to 
> install ObserverIP and that's not working either. Current WS-1001 firmware 
> is 2.4.3 and would prefer to not have to upgrade that since it's a pain in 
> a$$ to get everything update again.
>
> Any hints on how to get it connected again would be appreciated. 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9fe7134f-26c6-4e82-bae1-457acb777a98%40googlegroups.com.

[weewx-user] Re: Amusing interference with wind speed

[Andrew Milner]

Birds love them!!  If they 'push off' to launch themselves you may even get 
a gust recorded



On Tuesday, 30 July 2019 04:50:44 UTC+3, Chris Richmond wrote:
>
> The other day my wife and I were enjoying the Oregon weather on the deck, 
> and happened to catch a
> small bird that landed on the Vantage Vue's anemometer.  He spun around 
> 3-4 times and flew off.  Too
> bad we didn't catch it on video.
>
> Chris
>
>

-- 
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/d28e4544-5bef-49bf-9c33-f641055f057f%40googlegroups.com.

[weewx-user] Re: Amount of rain multiplied by 2, 3 ...

[Andrew Milner]

so are you saying that during this restart there was not a problem??  If so 
then the log is not much use and explains why everything looks OK apart 
from the fact that the report generator is reporting it cannot find the 
RSYNC.conf file.

There is so much other stuff in your log I would recommend putting weewx 
log messages into a seperate file.  See the wiki for how to put weewx 
messages in a seperate file and logrotate to compress/save the log files.

What is needed is a log from startup of when the rain goes wrong on a 
restart.

On Monday, 29 July 2019 23:12:11 UTC+3, Jlou 43 wrote:
>
> Hello and thanks for your help.
>
> I use weewx with a VP2 station, for the moment the month of July is correct, 
> and from the beginning until November 2016, for the rest we have 4 times more 
> rain ... We installed a circuit DS3231 (RTC ). I tried to update weewx, 
> unsuccessfully for now (he replied that I already have the latest version 
> installed when I type "sudo apt-get install weewx" under raspbian.
>
>
> I attach the syslog file when I restarted the pi3
>
>
> Le samedi 27 juillet 2019 12:03:44 UTC+2, Andrew Milner a écrit :
>>
>> is there any information in the log when you restart?
>>
>> what kind of station?
>>
>> which amount of rain is wrong - today, this week, this month, this year??
>>
>> what is recorded in the database?
>>
>> usually the answer to problems can be found in the log and the log is 
>> always the first place to look.
>>
>> when weewx starts up it tries to retrieve data from the weather station 
>> between the last recorded archive record and the current time - so the time 
>> on the station AND ON THE PI must be correct.  If you are using the fake 
>> hardware clock you are probably asking for trouble.  Weewx should not be 
>> started until the rpi has got the correct time set.  Later versions of 
>> weewx are pretty good at this - but the issue is only really resolved by 
>> having an RTC installed.
>>
>> Sorry to waffle on a lot - start with looking at the log.
>>
>>
>>
>> On Saturday, 27 July 2019 11:23:38 UTC+3, Jlou 43 wrote:
>>>
>>> I use weewx version 3.5.0 on a raspberry pi3 and I have a problem with the 
>>> amount of rain: when weewx restarts or when the raspberry restarts, I do 
>>> not know too much, the amount of rain is multiplied by 2, by 3 ...
>>>
>>> Do you have any idea where this may come from?
>>>
>>> Thank you.
>>>
>>>

-- 
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/fa7c9f1e-dff8-4acb-ac2e-584aabbee4a4%40googlegroups.com.

[weewx-user] Re: Radiation, maxSolarRad and ET/Evapotranspiration calculation - weewx/Belchertown skin

[Xant]

Pat

Thank you for support and Belchertown skin.

1) What expecting to see?
Starting with the basics, obtain Radiation, maxSolarRad, ET, and ultimately 
been able to post your (nice) Solar Radiation and UV Index Plot/Graph.

2) Do you have a Radiation sensor on your station?
Puzzles me. My Identifiers as follows:

% PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/interceptor.py 
--device=wu-client --mode=listen --port=80 --debug

identifiers: {}
raw data: 
ID=KNYCLIFT14=X=myAcuRite=now=updateraw=1=35=30.05=0=78=75.1=3=291=4=55=67.8=0.06=0.06
raw packet: {'wind_speed': 3.0, 'barometer': 30.05, 'wind_gust': 4.0, 
'dewpoint': 67.8, 'humidity_out': 78.0, 'uv': 0.0, 'rain': None, 
'dateTime': 1564448985, 'temperature_out': 75.1, 'wind_dir': 291.0, 
'rain_total': 0.06, 'wind_gust_dir': 55.0, 'usUnits': 1}
mapped packet: {'barometer': 30.05, 'dewpoint': 67.8, 'outHumidity': 78.0, 
'UV': 0.0, 'rain': None, 'dateTime': 1564448985, 'windDir': 291.0, 
'outTemp': 75.1, 'windSpeed': 3.0, 'windGust': 4.0, 'usUnits': 1, 
'windGustDir': 55.0}

'UV' can be identified, but not other "light" info.

But, MyAcurite (Acurite pws webserver and data) shows the following"


So, besides UV, not certain if Light Intensity just extrapolated from UV 
(or not) as can not match Identifier.

>From the above, plus location/altitude etc, can weewx calculate 
Radiation/maxSolarRad to use in Rad/UV Graph?

3) Syslog 
There is no errors in SysLog (besides "rainin" from Acurite Identifiers 
above not been recognized; there are "rainin", "rain", "rain_total"... 
trying to figure out rainin X rain...).
No error other than plain Rad=NA and ET=NA.

Best, AE


PS: while you here, just to feedback that Belchertown website link to Windy 
has a problem (no PWS data and msg: There is duplicate station E8484)

-- 
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/38c21c4d-b599-45d2-8f90-1c7908b0fcb1%40googlegroups.com.

[weewx-user] Amusing interference with wind speed

[Chris Richmond]

The other day my wife and I were enjoying the Oregon weather on the deck, 
and happened to catch a
small bird that landed on the Vantage Vue's anemometer.  He spun around 3-4 
times and flew off.  Too
bad we didn't catch it on video.

Chris

-- 
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/90f2a7a6-1948-478e-aa19-c5e84a6dca4a%40googlegroups.com.

[weewx-user] Re: Acurite Atlas/Access with interceptor and wunderground

[Xant]

Chris

As I also have an Acurite Atlas, and "rainin" error as well, wondering if 
you figured out the many variations of 'rain' (?!)

My identifiers:
identifiers: {}
raw data: 
ID=KNYCLIFT14==myAcuRite=now=updateraw=1=35=30.05=0=78=75.1=3=291=4=55=67.8=0.06=0.06
raw packet: {'wind_speed': 3.0, 'barometer': 30.05, 'wind_gust': 4.0, 
'dewpoint': 67.8, 'humidity_out': 78.0, 'uv': 0.0, 'rain': None, 
'dateTime': 1564448985, 'temperature_out': 75.1, 'wind_dir': 291.0, 
'rain_total': 0.06, 'wind_gust_dir': 55.0, 'usUnits': 1}
mapped packet: {'barometer': 30.05, 'dewpoint': 67.8, 'outHumidity': 78.0, 
'UV': 0.0, 'rain': None, 'dateTime': 1564448985, 'windDir': 291.0, 
'outTemp': 75.1, 'windSpeed': 3.0, 'windGust': 4.0, 'usUnits': 1, 
'windGustDir': 55.0}

As the above, there is 'rainin', 'rain' (twice) and 'total_rain'.

Thanks,
Xant

-- 
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/e213bd81-4c39-4d69-ba12-fc9ac501c31a%40googlegroups.com.

[weewx-user] Re: Radiation, maxSolarRad and ET/Evapotranspiration calculation - weewx/Belchertown skin

[Pat]

Xant this seems like a weewx issue and maybe not a Belchertown issue?

Do you have a radiation sensor on your station? pyephem will not tell you 
radiation, you will need a sensor for this. 

How did you install pyephem? Did you follow one of the weewx guides 
?

Are there any logs in your syslog? 

What is failing? Where is it failing? What are you expecting to see?


On Monday, July 29, 2019 at 5:07:14 PM UTC-4, Xant wrote:
>
>
> WeeWX Forum
>
> Installed "pyephem", along with required libraries and posted in 
> weewx/pyephem installation instructions. Pyephem seems successful and WeeWX 
> syslog has no errors. Still, can not acquire *Radiation, maxSolarRad and 
> ET*/*Evapotranspiration* (or calculations). May someone assist and advice.
>
> Thanks,
> Xant
>

-- 
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/6bb71a2e-8cf7-4cbb-9842-a2e335f39e39%40googlegroups.com.

[weewx-user] Re: Belchertown skin 1.0 released!

[Pat]

Yes, you can remove this line to delete the 

 
Google Font that's loaded. You can load another one in it's place if you 
want.

Then here 
,
 
and here 
,
 
needs to be updated with the new web font that you've chosen. 

On Monday, July 29, 2019 at 4:35:48 PM UTC-4, Radek Dohnal wrote:
>
> Hi, is it possible to change font used in this skin? I translated it to 
> czech, but there is a problem with some special character (i.e. ě). For 
> example in weather forecast.
>
>
> On Saturday, 1 June 2019 18:57:56 UTC+2, Pat wrote:
>>
>> Belchertown skin 1.0 is released!
>>
>> This update contains a lot of updates and changes including *an entire 
>> rewrite of the Highcharts system* which allows you to make almost any 
>> graph you want for almost any time span you want. You can see some examples 
>> of the charts you can make on the BelchertownWeather.com website graphs 
>> page .
>>
>> You can add/remove/change/reorder any chart, change colors, add 
>> observation plots, categorize for all time. Almost anything you want to do 
>> is available! The skin comes with the standard 4 charts ready to go, but 
>> there's extensive Belchertown Charts Documentation 
>> 
>>  
>> which can help you get started. 
>>
>> In addition to the Charts there's now a dark mode (which has an 
>> auto-switching mode based on sunset/sunrise), more flexibility for 
>> translations, user customized station observation table which is updated in 
>> real time if the MQTT Websockets are enabled, and a lot more. Check the 
>> release notes for all the details! 
>>
>> You can download the latest release here 
>> ,
>>  
>> and read all of the details on the changes here: 
>> https://github.com/poblabs/weewx-belchertown/releases
>>
>> *Note: You cannot upgrade from Belchertown 0.9 and older*. You must 
>> uninstall everything and reinstall new. This is due to the Chart system 
>> being fully rewritten and the potential for conflicts. Please read this 
>> upgrade guide if you are upgrading from an older version of Belchertown skin 
>> 
>> . 
>>
>> Thanks to all the beta testers and translators over the last couple of 
>> months help me iron out all the kinks and shape the skin in a way that can 
>> be translated a little easier! 
>>
>> Attached are some examples of the charts that can be made. If you find 
>> any issues, you can reply here or open an issue on the Belchertown skin 
>> GitHub page . 
>>
>

-- 
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/10b3d95f-c9c1-4bc0-a51f-a8e7616ea5c9%40googlegroups.com.

[weewx-user] Radiation, maxSolarRad and ET/Evapotranspiration calculation - weewx/Belchertown skin

[Xant]

WeeWX Forum

Installed "pyephem", along with required libraries and posted in 
weewx/pyephem installation instructions. Pyephem seems successful and WeeWX 
syslog has no errors. Still, can not acquire *Radiation, maxSolarRad and ET*
/*Evapotranspiration* (or calculations). May someone assist and advice.

Thanks,
Xant

-- 
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/67783827-70ea-4676-b973-6d83c5f70440%40googlegroups.com.

[weewx-user] Re: AS3935 database issue

[Mikael Fredriksson]

Ok so now I made my first table! 
But can't figure out how to get the 4-5 last strikes to fill out the table 
in orderand that it updates the table as new strikes appears.
I use Sqlite and have these two observations in weewx.sdb, Lightning 
strikes and Avg distance

The very advanced code:


  Last strikes (<40km)


   Strike
   Distance
   Time

  
   a
   b
   c

 
   d
   e
   f

 
   g
   h
   i

 
   j
   k
   l




Gives me this:

[image: Striketable.jpg]

So how could I get it populated with the numbers from my database file?

Mikael

-- 
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/c049fdea-1b75-4bfa-8af3-46322bb0c40e%40googlegroups.com.

[weewx-user] Re: Belchertown skin 1.0 released!

[Radek Dohnal]

Hi, is it possible to change font used in this skin? I translated it to 
czech, but there is a problem with some special character (i.e. ě). For 
example in weather forecast.


On Saturday, 1 June 2019 18:57:56 UTC+2, Pat wrote:
>
> Belchertown skin 1.0 is released!
>
> This update contains a lot of updates and changes including *an entire 
> rewrite of the Highcharts system* which allows you to make almost any 
> graph you want for almost any time span you want. You can see some examples 
> of the charts you can make on the BelchertownWeather.com website graphs 
> page .
>
> You can add/remove/change/reorder any chart, change colors, add 
> observation plots, categorize for all time. Almost anything you want to do 
> is available! The skin comes with the standard 4 charts ready to go, but 
> there's extensive Belchertown Charts Documentation 
> 
>  
> which can help you get started. 
>
> In addition to the Charts there's now a dark mode (which has an 
> auto-switching mode based on sunset/sunrise), more flexibility for 
> translations, user customized station observation table which is updated in 
> real time if the MQTT Websockets are enabled, and a lot more. Check the 
> release notes for all the details! 
>
> You can download the latest release here 
> ,
>  
> and read all of the details on the changes here: 
> https://github.com/poblabs/weewx-belchertown/releases
>
> *Note: You cannot upgrade from Belchertown 0.9 and older*. You must 
> uninstall everything and reinstall new. This is due to the Chart system 
> being fully rewritten and the potential for conflicts. Please read this 
> upgrade guide if you are upgrading from an older version of Belchertown skin 
> 
> . 
>
> Thanks to all the beta testers and translators over the last couple of 
> months help me iron out all the kinks and shape the skin in a way that can 
> be translated a little easier! 
>
> Attached are some examples of the charts that can be made. If you find any 
> issues, you can reply here or open an issue on the Belchertown skin 
> GitHub page . 
>

-- 
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/537a1f57-cd9b-4ff3-b681-1a21ece38c4f%40googlegroups.com.

Re: [weewx-user] Re: thnigspeak - API

[Xant]

Thank you Sathish and Andrew

Note to WeeWX & Extension Developers 


ThingSpeak Extension weewx.conf install patch and Extension howto/wiki has 
mistakes:

1) weewx.conf, wee_extension install writes:

[StdRESTful]

[[ThingSpeak]]
 TOKEN =  

2) Extension howto/wiki:

[StdRESTful]
[[ThingSpeak]]
api_key = API_KEY


also

[StdRESTful]
[[ThingSpeak]]
api_key = TOKEN



So, 3 versions mixed. While the right context is the latest, ie:


*[StdRESTful]
[[ThingSpeak]]
api_key = TOKEN #(Write to Token)*


-- 
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/2367378d-5d89-4d67-9f8a-04e2ddf3461f%40googlegroups.com.

[weewx-user] WS-1001 connection to Raspberry PI for Weewx

[Bill Volz]

I had this working for 2 years but it stopped Saturday. I got it working 2 
years ago and don't quite recall what I did. I think I used EasyWeatherIP 
to change web page in the setup page from "www.wunderground.com' to 
'www.***.com". Now when I try to change it with EWIP, it doesn't make the 
change - it has made other changes. Not sure if there is a trick. I've 
tried to install HP1001 but it times out and can't find the WS-1001. Is 
there a way to tell HP1001 what the IP address of the WS_1001 is - I have 
it on a static address using the MAC address on my router. I tried to 
install ObserverIP and that's not working either. Current WS-1001 firmware 
is 2.4.3 and would prefer to not have to upgrade that since it's a pain in 
a$$ to get everything update again.

Any hints on how to get it connected again would be appreciated. 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/528a2670-894b-42f9-a156-08d6238d3cbc%40googlegroups.com.

[weewx-user] Re: Did someone test Weewx in Raspbian Buster?

[Dr__Bob]

Hi, I just recently upgraded to Buster and also weewx 3.9.1.  I'm using the 
HP1000 driver (contributed by AussieSusan).  All works fine except for the 
cpu_temp in the cmon skin.  I had to flip the order of an "if-elif" block 
in cmon.py to get it to work.  I've let Matthew Wall know.  It's probably a 
change going from Jessie to Buster adding a directory in the /sys tree. 
 After that change, the system is running very nicely.


-- 
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/8360d026-3064-478f-8321-56e27b86daed%40googlegroups.com.

[weewx-user] Re: RAM disc for web server data

[R A Lichtensteiger]

I wrote:


Killing three birds with one stone ... I have an init script
(attached) that:


OFFFS ... first post and I screw up by failing to attach the script


R
--
R A Lichtensteiger

   “Don’t make something unless it is both necessary and useful; but if it is
both necessary and useful, don’t hesitate to make it beautiful.”
  —Shaker philosophy

--
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/20190729164129.GC10844%40mta.tifosi.com.
#!/bin/sh 

# Startup script to sync to/from a ramdisk for WeeWX for Debian derivatives
#
### BEGIN INIT INFO
# Provides:  weewx-ramdisk
# Required-Start:$local_fs $remote_fs $syslog $time
# Required-Stop: $local_fs $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: weewx weather system ramdisk
# Description:   Manages a ramdisk for the web output of weewx
### END INIT INFO

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="weewx weather system ramdisk"
NAME=weewx-ramdisk

TARGET="/var/www/weather"
BACKUP="/var/backups/weewx-webdir"
LOGFILE="/var/log/weewx/webdir-sync.log"

RSYNC_BIN="/usr/bin/rsync"

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Exit if the rsync package is not installed
[ -x "$RSYNC_BIN" ] || exit 0

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

if [ "$START_WEEWX" = no ]
then
  log_action_msg "Not starting $DESC, see /etc/default/$NAME"
  exit 0
fi

case "$1" in
  start)
echo "Copying files to ramdisk"
$RSYNC_BIN -av ${BACKUP}/ ${TARGET}/
echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk restored from HD >> ${LOGFILE}
;;
  stop|sync|reload)
echo "Synching files from ramdisk to Harddisk"
echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk backed up to HD >> ${LOGFILE}
$RSYNC_BIN -av --delete --recursive --force ${TARGET}/ ${BACKUP}/
;;
  *)
echo "Usage: /etc/init.d/$NAME {start|stop|sync|reload}"
exit 1
;;
esac

exit 0

[weewx-user] Re: RAM disc for web server data

[R A Lichtensteiger]

("Long time listener, first time caller")

vince wrote:


On Wednesday, July 24, 2019 at 6:55:42 AM UTC-7, James Muirhead wrote


As the web server data is written to the SD every 5 minutes, I felt it
would be appropriate to create a RAM disc for it. Should, in theory,
improve lifespan of the SD card.
[...]


One thing you might think about is stashing your NOAA files to disk
periodically (couple times a day) and restoring them, as they take a long
time to regenerate as you get more and more data.  The other stuff will
regenerate quickly on firstboot of course.


Like many, I stumbled onto the tmpfs ram drive solution a while ago.

Killing three birds with one stone ... I have an init script
(attached) that:

  o  Backs up the web directory on shutdown or when called with
 "sync" or "reload"
  o  Restores the web directory on startup

Cron entry runs the "sync" nightly, the other two modes are self
explanatory.

R

People using systemd are on their own
--
R A Lichtensteiger

Power corrupts. Absolute power corrupts absolutely. But it rocks
absolutely, too.

--
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/20190729163747.GA10844%40mta.tifosi.com.

Re: [weewx-user] Re: WU Wind graphs

[Praveen Chandrasekaran]

Thanks. Posted in weewx-development group also.

On Mon, 29 Jul 2019 at 16:11, Andrew Milner 
wrote:

> I suspect there is some history involved.  As far as I can make out, if
> LOOP2 data were to be read then the packets are alternated with LOOP -
> which would result in LOOP packets being received every 5 seconds instead
> of every 2.5 seconds - perhaps that is why they are not being read!!!  As
> to whether they should or should not be why not make a posting on the
> development group!!
>
> What I mean was that dewpoint and heatindex and other items which are
> actually in LOOP2 packets I believe are software generated in weewx, and
> not read from the station.
>
>
> On Monday, 29 July 2019 13:24:00 UTC+3, Praveen Chandrasekaran wrote:
>>
>> Understand that weewx does not read LOOP2 packets. Did not get the part
>> about " LOOP2 data is more than likely software generated by weewx"
>>
>> The LOOP2 packet format is specified in Davis protocol and it seems to be
>> containing some data that WU is expecting. Shouldnt weewx be reading it
>> then? Not sure if something changed in WU upload protocol as well. The
>> earlier wiki link with upload protocol no longer works! So I am not sure
>> what the protocol was before.
>>
>> On Mon, 29 Jul 2019 at 15:49, Andrew Milner  wrote:
>>
>>> slight correction - the LOOP2 data is more than likely software
>>> generated by weewx
>>>
>>> On Monday, 29 July 2019 13:18:22 UTC+3, Andrew Milner wrote:

 I do not think weewx reads LOOP2 packets - so none of the LOOP2 data is
 available.



 On Monday, 29 July 2019 12:54:52 UTC+3, Praveen Chandrasekaran wrote:
>
> Looking at below:
>
>
> https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298
>
>
> WU expects wind speed average over 2 min average and 10 min gusts and
> instantaneous speed. Did something change in this recently? Looking at
> weewx code from restx.py I am not sure if weewx uploads all these?
>
> https://github.com/weewx/weewx/blob/master/bin/weewx/restx.py
>
> winddir - [0-360 instantaneous wind direction]
> windspeedmph - [mph instantaneous wind speed]
> windgustmph - [mph current wind gust, using software specific time period]
> windgustdir - [0-360 using software specific time period]
> windspdmph_avg2m  - [mph 2 minute average wind speed mph]
> winddir_avg2m - [0-360 2 minute average wind direction]
> windgustmph_10m - [mph past 10 minutes wind gust mph ]
> windgustdir_10m - [0-360 past 10 minutes wind gust direction]
>
>
> On Mon, 29 Jul 2019 at 15:10, Praveen Chandrasekaran <
> prave...@gmail.com> wrote:
>
>> Hmm. Will try. Before the WU overhaul it was showing them separately
>> on the graph though. The gust value from LOOP2 seems to be 10 min wind 
>> gust
>> while the wind speed sent out is the instantaneous wind speed from LOOP
>> packet I believe? This may explain why wind speed and wind gust are same 
>> in
>> graph. But then how does the table have different values. U never know 
>> with
>> WU! :)
>>
>> As you mentioned will set debug=1 and observe sometime.
>>
>> On Mon, 29 Jul 2019 at 12:29, Andrew Milner 
>> wrote:
>>
>>> I really do not see how you can have a meaningful gust value from
>>> readings submitted every few seconds!!  I see from the Davis comms 
>>> protocol
>>> the gust values are in LOOP2 packets and the smallest appears to be a 2
>>> minute gust value.
>>>
>>> Setting debug=1 may shed more light on what is actually being sent
>>> to WU
>>>
>>>
>>>
>>> On Monday, 29 July 2019 09:24:19 UTC+3, Praveen Chandrasekaran wrote:

 My weather station is Davis Vantage Vue. I believe it never emits
 partial packets.

 On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:
>
> i doubt it very much.  what weather station do you have?
> changing the rf frequency changes the upload to wu interval but
> the station will still be being polled as before.  Does the station 
> provide
> the gust value in the LOOP data?  If not then the gust value is an
> artificial one created by weewx from loop records wind speeds 
> received.  If
> your station provides partial packets as LOOP data you could always 
> try and
> set the wu flag that set specifies windGust must be present before rf 
> is
> uploaded
>
> On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran
> wrote:
>>
>> If I set rtfreq to a higher value like 5 seconds, should that
>> resolve the issue?
>>
>> On Fri, 26 Jul 2019 at 11:57, Andrew Milner 
>> wrote:
>>
>>> if from rf it has no gusts it cannot graph them.  non rf sites

[weewx-user] Re: ws28xx: no backfill of values when contact to console is lost and regained

[Andrew Milner]

are you certain it has reconnected??

the archive records are only being generated at 1 hr intervals - is this 
correct??

there does not appear to be any communication between archive events - very 
strange.
The log message instructs you to resynch by pressing SET - did you do that??

I am far from convinced this is running as you intend - generating updates 
only once per hour??



On Monday, 29 July 2019 14:01:30 UTC+3, Michi Kaa wrote:
>
> Nothing?

-- 
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/2abd17ae-00aa-48da-ae1d-7f4011bfa6f9%40googlegroups.com.

[weewx-user] Re: ws28xx: no backfill of values when contact to console is lost and regained

[Michi Kaa]

Nothing?

-- 
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/2f45488d-bbda-4723-9a8e-af0a520749b0%40googlegroups.com.

Re: [weewx-user] Re: WU Wind graphs

[Andrew Milner]

I suspect there is some history involved.  As far as I can make out, if 
LOOP2 data were to be read then the packets are alternated with LOOP - 
which would result in LOOP packets being received every 5 seconds instead 
of every 2.5 seconds - perhaps that is why they are not being read!!!  As 
to whether they should or should not be why not make a posting on the 
development group!!

What I mean was that dewpoint and heatindex and other items which are 
actually in LOOP2 packets I believe are software generated in weewx, and 
not read from the station.


On Monday, 29 July 2019 13:24:00 UTC+3, Praveen Chandrasekaran wrote:
>
> Understand that weewx does not read LOOP2 packets. Did not get the part 
> about " LOOP2 data is more than likely software generated by weewx"
>
> The LOOP2 packet format is specified in Davis protocol and it seems to be 
> containing some data that WU is expecting. Shouldnt weewx be reading it 
> then? Not sure if something changed in WU upload protocol as well. The 
> earlier wiki link with upload protocol no longer works! So I am not sure 
> what the protocol was before. 
>
> On Mon, 29 Jul 2019 at 15:49, Andrew Milner  > wrote:
>
>> slight correction - the LOOP2 data is more than likely software generated 
>> by weewx
>>
>> On Monday, 29 July 2019 13:18:22 UTC+3, Andrew Milner wrote:
>>>
>>> I do not think weewx reads LOOP2 packets - so none of the LOOP2 data is 
>>> available.
>>>
>>>
>>>
>>> On Monday, 29 July 2019 12:54:52 UTC+3, Praveen Chandrasekaran wrote:

 Looking at below:


 https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298
  

 WU expects wind speed average over 2 min average and 10 min gusts and 
 instantaneous speed. Did something change in this recently? Looking at 
 weewx code from restx.py I am not sure if weewx uploads all these? 

 https://github.com/weewx/weewx/blob/master/bin/weewx/restx.py  

 winddir - [0-360 instantaneous wind direction]
 windspeedmph - [mph instantaneous wind speed]
 windgustmph - [mph current wind gust, using software specific time period]
 windgustdir - [0-360 using software specific time period]
 windspdmph_avg2m  - [mph 2 minute average wind speed mph]
 winddir_avg2m - [0-360 2 minute average wind direction]
 windgustmph_10m - [mph past 10 minutes wind gust mph ]
 windgustdir_10m - [0-360 past 10 minutes wind gust direction]


 On Mon, 29 Jul 2019 at 15:10, Praveen Chandrasekaran <
 prave...@gmail.com> wrote:

> Hmm. Will try. Before the WU overhaul it was showing them separately 
> on the graph though. The gust value from LOOP2 seems to be 10 min wind 
> gust 
> while the wind speed sent out is the instantaneous wind speed from LOOP 
> packet I believe? This may explain why wind speed and wind gust are same 
> in 
> graph. But then how does the table have different values. U never know 
> with 
> WU! :)  
>
> As you mentioned will set debug=1 and observe sometime.  
>
> On Mon, 29 Jul 2019 at 12:29, Andrew Milner  
> wrote:
>
>> I really do not see how you can have a meaningful gust value from 
>> readings submitted every few seconds!!  I see from the Davis comms 
>> protocol 
>> the gust values are in LOOP2 packets and the smallest appears to be a 2 
>> minute gust value.
>>
>> Setting debug=1 may shed more light on what is actually being sent to 
>> WU
>>
>>
>>
>> On Monday, 29 July 2019 09:24:19 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> My weather station is Davis Vantage Vue. I believe it never emits 
>>> partial packets.
>>>
>>> On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:

 i doubt it very much.  what weather station do you have?
 changing the rf frequency changes the upload to wu interval but the 
 station will still be being polled as before.  Does the station 
 provide the 
 gust value in the LOOP data?  If not then the gust value is an 
 artificial 
 one created by weewx from loop records wind speeds received.  If your 
 station provides partial packets as LOOP data you could always try and 
 set 
 the wu flag that set specifies windGust must be present before rf is 
 uploaded

 On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran 
 wrote:
>
> If I set rtfreq to a higher value like 5 seconds, should that 
> resolve the issue? 
>
> On Fri, 26 Jul 2019 at 11:57, Andrew Milner  
> wrote:
>
>> if from rf it has no gusts it cannot graph them.  non rf sites 
>> will provide a gust value per archive interval.  who knows what wu 
>> do when 
>> they receive both rf and archive record data!!  The tables may well 
>> 

Re: [weewx-user] Re: WU Wind graphs

[Praveen Chandrasekaran]

Understand that weewx does not read LOOP2 packets. Did not get the part
about " LOOP2 data is more than likely software generated by weewx"

The LOOP2 packet format is specified in Davis protocol and it seems to be
containing some data that WU is expecting. Shouldnt weewx be reading it
then? Not sure if something changed in WU upload protocol as well. The
earlier wiki link with upload protocol no longer works! So I am not sure
what the protocol was before.

On Mon, 29 Jul 2019 at 15:49, Andrew Milner 
wrote:

> slight correction - the LOOP2 data is more than likely software generated
> by weewx
>
> On Monday, 29 July 2019 13:18:22 UTC+3, Andrew Milner wrote:
>>
>> I do not think weewx reads LOOP2 packets - so none of the LOOP2 data is
>> available.
>>
>>
>>
>> On Monday, 29 July 2019 12:54:52 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> Looking at below:
>>>
>>>
>>> https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298
>>>
>>>
>>> WU expects wind speed average over 2 min average and 10 min gusts and
>>> instantaneous speed. Did something change in this recently? Looking at
>>> weewx code from restx.py I am not sure if weewx uploads all these?
>>>
>>> https://github.com/weewx/weewx/blob/master/bin/weewx/restx.py
>>>
>>> winddir - [0-360 instantaneous wind direction]
>>> windspeedmph - [mph instantaneous wind speed]
>>> windgustmph - [mph current wind gust, using software specific time period]
>>> windgustdir - [0-360 using software specific time period]
>>> windspdmph_avg2m  - [mph 2 minute average wind speed mph]
>>> winddir_avg2m - [0-360 2 minute average wind direction]
>>> windgustmph_10m - [mph past 10 minutes wind gust mph ]
>>> windgustdir_10m - [0-360 past 10 minutes wind gust direction]
>>>
>>>
>>> On Mon, 29 Jul 2019 at 15:10, Praveen Chandrasekaran 
>>> wrote:
>>>
 Hmm. Will try. Before the WU overhaul it was showing them separately on
 the graph though. The gust value from LOOP2 seems to be 10 min wind gust
 while the wind speed sent out is the instantaneous wind speed from LOOP
 packet I believe? This may explain why wind speed and wind gust are same in
 graph. But then how does the table have different values. U never know with
 WU! :)

 As you mentioned will set debug=1 and observe sometime.

 On Mon, 29 Jul 2019 at 12:29, Andrew Milner 
 wrote:

> I really do not see how you can have a meaningful gust value from
> readings submitted every few seconds!!  I see from the Davis comms 
> protocol
> the gust values are in LOOP2 packets and the smallest appears to be a 2
> minute gust value.
>
> Setting debug=1 may shed more light on what is actually being sent to
> WU
>
>
>
> On Monday, 29 July 2019 09:24:19 UTC+3, Praveen Chandrasekaran wrote:
>>
>> My weather station is Davis Vantage Vue. I believe it never emits
>> partial packets.
>>
>> On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:
>>>
>>> i doubt it very much.  what weather station do you have?
>>> changing the rf frequency changes the upload to wu interval but the
>>> station will still be being polled as before.  Does the station provide 
>>> the
>>> gust value in the LOOP data?  If not then the gust value is an 
>>> artificial
>>> one created by weewx from loop records wind speeds received.  If your
>>> station provides partial packets as LOOP data you could always try and 
>>> set
>>> the wu flag that set specifies windGust must be present before rf is
>>> uploaded
>>>
>>> On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:

 If I set rtfreq to a higher value like 5 seconds, should that
 resolve the issue?

 On Fri, 26 Jul 2019 at 11:57, Andrew Milner 
 wrote:

> if from rf it has no gusts it cannot graph them.  non rf sites
> will provide a gust value per archive interval.  who knows what wu do 
> when
> they receive both rf and archive record data!!  The tables may well 
> create
> an artificial gust value from rf speeds, but again who knows what wu 
> use to
> create the graphs!!
>
>
>
> On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran
> wrote:
>>
>> The table somehow has it right. The graph alone is wrong.
>>
>> On Fri, 26 Jul 2019 at 11:29, Andrew Milner 
>> wrote:
>>
>>> I would suspect WU ignore windgust on rapidfire because you need
>>> a sustained period of I think 3 seconds for the gust to count as a 
>>> gust in
>>> metereological definitions - and the rf interval is probably too 
>>> short - so
>>> gust will always equal speed in rf situations.
>>>
>>> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen 

Re: [weewx-user] Re: WU Wind graphs

[Andrew Milner]

slight correction - the LOOP2 data is more than likely software generated 
by weewx

On Monday, 29 July 2019 13:18:22 UTC+3, Andrew Milner wrote:
>
> I do not think weewx reads LOOP2 packets - so none of the LOOP2 data is 
> available.
>
>
>
> On Monday, 29 July 2019 12:54:52 UTC+3, Praveen Chandrasekaran wrote:
>>
>> Looking at below:
>>
>>
>> https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298
>>  
>>
>> WU expects wind speed average over 2 min average and 10 min gusts and 
>> instantaneous speed. Did something change in this recently? Looking at 
>> weewx code from restx.py I am not sure if weewx uploads all these? 
>>
>> https://github.com/weewx/weewx/blob/master/bin/weewx/restx.py  
>>
>> winddir - [0-360 instantaneous wind direction]
>> windspeedmph - [mph instantaneous wind speed]
>> windgustmph - [mph current wind gust, using software specific time period]
>> windgustdir - [0-360 using software specific time period]
>> windspdmph_avg2m  - [mph 2 minute average wind speed mph]
>> winddir_avg2m - [0-360 2 minute average wind direction]
>> windgustmph_10m - [mph past 10 minutes wind gust mph ]
>> windgustdir_10m - [0-360 past 10 minutes wind gust direction]
>>
>>
>> On Mon, 29 Jul 2019 at 15:10, Praveen Chandrasekaran  
>> wrote:
>>
>>> Hmm. Will try. Before the WU overhaul it was showing them separately on 
>>> the graph though. The gust value from LOOP2 seems to be 10 min wind gust 
>>> while the wind speed sent out is the instantaneous wind speed from LOOP 
>>> packet I believe? This may explain why wind speed and wind gust are same in 
>>> graph. But then how does the table have different values. U never know with 
>>> WU! :)  
>>>
>>> As you mentioned will set debug=1 and observe sometime.  
>>>
>>> On Mon, 29 Jul 2019 at 12:29, Andrew Milner  
>>> wrote:
>>>
 I really do not see how you can have a meaningful gust value from 
 readings submitted every few seconds!!  I see from the Davis comms 
 protocol 
 the gust values are in LOOP2 packets and the smallest appears to be a 2 
 minute gust value.

 Setting debug=1 may shed more light on what is actually being sent to WU



 On Monday, 29 July 2019 09:24:19 UTC+3, Praveen Chandrasekaran wrote:
>
> My weather station is Davis Vantage Vue. I believe it never emits 
> partial packets.
>
> On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:
>>
>> i doubt it very much.  what weather station do you have?
>> changing the rf frequency changes the upload to wu interval but the 
>> station will still be being polled as before.  Does the station provide 
>> the 
>> gust value in the LOOP data?  If not then the gust value is an 
>> artificial 
>> one created by weewx from loop records wind speeds received.  If your 
>> station provides partial packets as LOOP data you could always try and 
>> set 
>> the wu flag that set specifies windGust must be present before rf is 
>> uploaded
>>
>> On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> If I set rtfreq to a higher value like 5 seconds, should that 
>>> resolve the issue? 
>>>
>>> On Fri, 26 Jul 2019 at 11:57, Andrew Milner  
>>> wrote:
>>>
 if from rf it has no gusts it cannot graph them.  non rf sites will 
 provide a gust value per archive interval.  who knows what wu do when 
 they 
 receive both rf and archive record data!!  The tables may well create 
 an 
 artificial gust value from rf speeds, but again who knows what wu use 
 to 
 create the graphs!!



 On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran 
 wrote:
>
> The table somehow has it right. The graph alone is wrong.
>
> On Fri, 26 Jul 2019 at 11:29, Andrew Milner  
> wrote:
>
>> I would suspect WU ignore windgust on rapidfire because you need 
>> a sustained period of I think 3 seconds for the gust to count as a 
>> gust in 
>> metereological definitions - and the rf interval is probably too 
>> short - so 
>> gust will always equal speed in rf situations.  
>>
>> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran 
>> wrote:
>>>
>>> Related wxforum post:
>>>
>>> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>>>
>>>
>>> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen 
>>> Chandrasekaran wrote:

 Hi,

 I am seeing that on stations with rapdifire, WU is not 
 differentiating wind speed and wind gust in graph correctly. 
 However in 
 stations without rapidfire it is fine.

 Example my 

Re: [weewx-user] Re: WU Wind graphs

[Andrew Milner]

I do not think weewx reads LOOP2 packets - so none of the LOOP2 data is 
available.



On Monday, 29 July 2019 12:54:52 UTC+3, Praveen Chandrasekaran wrote:
>
> Looking at below:
>
>
> https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298
>  
>
> WU expects wind speed average over 2 min average and 10 min gusts and 
> instantaneous speed. Did something change in this recently? Looking at 
> weewx code from restx.py I am not sure if weewx uploads all these? 
>
> https://github.com/weewx/weewx/blob/master/bin/weewx/restx.py  
>
> winddir - [0-360 instantaneous wind direction]
> windspeedmph - [mph instantaneous wind speed]
> windgustmph - [mph current wind gust, using software specific time period]
> windgustdir - [0-360 using software specific time period]
> windspdmph_avg2m  - [mph 2 minute average wind speed mph]
> winddir_avg2m - [0-360 2 minute average wind direction]
> windgustmph_10m - [mph past 10 minutes wind gust mph ]
> windgustdir_10m - [0-360 past 10 minutes wind gust direction]
>
>
> On Mon, 29 Jul 2019 at 15:10, Praveen Chandrasekaran  > wrote:
>
>> Hmm. Will try. Before the WU overhaul it was showing them separately on 
>> the graph though. The gust value from LOOP2 seems to be 10 min wind gust 
>> while the wind speed sent out is the instantaneous wind speed from LOOP 
>> packet I believe? This may explain why wind speed and wind gust are same in 
>> graph. But then how does the table have different values. U never know with 
>> WU! :)  
>>
>> As you mentioned will set debug=1 and observe sometime.  
>>
>> On Mon, 29 Jul 2019 at 12:29, Andrew Milner > > wrote:
>>
>>> I really do not see how you can have a meaningful gust value from 
>>> readings submitted every few seconds!!  I see from the Davis comms protocol 
>>> the gust values are in LOOP2 packets and the smallest appears to be a 2 
>>> minute gust value.
>>>
>>> Setting debug=1 may shed more light on what is actually being sent to WU
>>>
>>>
>>>
>>> On Monday, 29 July 2019 09:24:19 UTC+3, Praveen Chandrasekaran wrote:

 My weather station is Davis Vantage Vue. I believe it never emits 
 partial packets.

 On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:
>
> i doubt it very much.  what weather station do you have?
> changing the rf frequency changes the upload to wu interval but the 
> station will still be being polled as before.  Does the station provide 
> the 
> gust value in the LOOP data?  If not then the gust value is an artificial 
> one created by weewx from loop records wind speeds received.  If your 
> station provides partial packets as LOOP data you could always try and 
> set 
> the wu flag that set specifies windGust must be present before rf is 
> uploaded
>
> On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:
>>
>> If I set rtfreq to a higher value like 5 seconds, should that resolve 
>> the issue? 
>>
>> On Fri, 26 Jul 2019 at 11:57, Andrew Milner  
>> wrote:
>>
>>> if from rf it has no gusts it cannot graph them.  non rf sites will 
>>> provide a gust value per archive interval.  who knows what wu do when 
>>> they 
>>> receive both rf and archive record data!!  The tables may well create 
>>> an 
>>> artificial gust value from rf speeds, but again who knows what wu use 
>>> to 
>>> create the graphs!!
>>>
>>>
>>>
>>> On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:

 The table somehow has it right. The graph alone is wrong.

 On Fri, 26 Jul 2019 at 11:29, Andrew Milner  
 wrote:

> I would suspect WU ignore windgust on rapidfire because you need a 
> sustained period of I think 3 seconds for the gust to count as a gust 
> in 
> metereological definitions - and the rf interval is probably too 
> short - so 
> gust will always equal speed in rf situations.  
>
> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran 
> wrote:
>>
>> Related wxforum post:
>>
>> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>>
>>
>> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran 
>> wrote:
>>>
>>> Hi,
>>>
>>> I am seeing that on stations with rapdifire, WU is not 
>>> differentiating wind speed and wind gust in graph correctly. 
>>> However in 
>>> stations without rapidfire it is fine.
>>>
>>> Example my station with rapidfire:
>>>
>>> https://www.wunderground.com/dashboard/pws/IBANGALO9
>>>
>>> Another station without rapidfire:
>>>
>>> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>>>
>>> Is this issue arising from weewx by any 

Re: [weewx-user] Re: WU Wind graphs

[Praveen Chandrasekaran]

Looking at below:

https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298


WU expects wind speed average over 2 min average and 10 min gusts and
instantaneous speed. Did something change in this recently? Looking at
weewx code from restx.py I am not sure if weewx uploads all these?

https://github.com/weewx/weewx/blob/master/bin/weewx/restx.py

winddir - [0-360 instantaneous wind direction]
windspeedmph - [mph instantaneous wind speed]
windgustmph - [mph current wind gust, using software specific time period]
windgustdir - [0-360 using software specific time period]
windspdmph_avg2m  - [mph 2 minute average wind speed mph]
winddir_avg2m - [0-360 2 minute average wind direction]
windgustmph_10m - [mph past 10 minutes wind gust mph ]
windgustdir_10m - [0-360 past 10 minutes wind gust direction]


On Mon, 29 Jul 2019 at 15:10, Praveen Chandrasekaran 
wrote:

> Hmm. Will try. Before the WU overhaul it was showing them separately on
> the graph though. The gust value from LOOP2 seems to be 10 min wind gust
> while the wind speed sent out is the instantaneous wind speed from LOOP
> packet I believe? This may explain why wind speed and wind gust are same in
> graph. But then how does the table have different values. U never know with
> WU! :)
>
> As you mentioned will set debug=1 and observe sometime.
>
> On Mon, 29 Jul 2019 at 12:29, Andrew Milner 
> wrote:
>
>> I really do not see how you can have a meaningful gust value from
>> readings submitted every few seconds!!  I see from the Davis comms protocol
>> the gust values are in LOOP2 packets and the smallest appears to be a 2
>> minute gust value.
>>
>> Setting debug=1 may shed more light on what is actually being sent to WU
>>
>>
>>
>> On Monday, 29 July 2019 09:24:19 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> My weather station is Davis Vantage Vue. I believe it never emits
>>> partial packets.
>>>
>>> On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:

 i doubt it very much.  what weather station do you have?
 changing the rf frequency changes the upload to wu interval but the
 station will still be being polled as before.  Does the station provide the
 gust value in the LOOP data?  If not then the gust value is an artificial
 one created by weewx from loop records wind speeds received.  If your
 station provides partial packets as LOOP data you could always try and set
 the wu flag that set specifies windGust must be present before rf is
 uploaded

 On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:
>
> If I set rtfreq to a higher value like 5 seconds, should that resolve
> the issue?
>
> On Fri, 26 Jul 2019 at 11:57, Andrew Milner 
> wrote:
>
>> if from rf it has no gusts it cannot graph them.  non rf sites will
>> provide a gust value per archive interval.  who knows what wu do when 
>> they
>> receive both rf and archive record data!!  The tables may well create an
>> artificial gust value from rf speeds, but again who knows what wu use to
>> create the graphs!!
>>
>>
>>
>> On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> The table somehow has it right. The graph alone is wrong.
>>>
>>> On Fri, 26 Jul 2019 at 11:29, Andrew Milner 
>>> wrote:
>>>
 I would suspect WU ignore windgust on rapidfire because you need a
 sustained period of I think 3 seconds for the gust to count as a gust 
 in
 metereological definitions - and the rf interval is probably too short 
 - so
 gust will always equal speed in rf situations.

 On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran
 wrote:
>
> Related wxforum post:
>
> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>
>
> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran
> wrote:
>>
>> Hi,
>>
>> I am seeing that on stations with rapdifire, WU is not
>> differentiating wind speed and wind gust in graph correctly. However 
>> in
>> stations without rapidfire it is fine.
>>
>> Example my station with rapidfire:
>>
>> https://www.wunderground.com/dashboard/pws/IBANGALO9
>>
>> Another station without rapidfire:
>>
>> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>>
>> Is this issue arising from weewx by any chance?
>>
>> Regards,
>> Praveen
>>
> --
 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/E5uzJiv_ThY/unsubscribe
 .
 To unsubscribe from 

Re: [weewx-user] Re: WU Wind graphs

[Praveen Chandrasekaran]

Hmm. Will try. Before the WU overhaul it was showing them separately on the
graph though. The gust value from LOOP2 seems to be 10 min wind gust while
the wind speed sent out is the instantaneous wind speed from LOOP packet I
believe? This may explain why wind speed and wind gust are same in graph.
But then how does the table have different values. U never know with WU!
:)

As you mentioned will set debug=1 and observe sometime.

On Mon, 29 Jul 2019 at 12:29, Andrew Milner 
wrote:

> I really do not see how you can have a meaningful gust value from readings
> submitted every few seconds!!  I see from the Davis comms protocol the gust
> values are in LOOP2 packets and the smallest appears to be a 2 minute gust
> value.
>
> Setting debug=1 may shed more light on what is actually being sent to WU
>
>
>
> On Monday, 29 July 2019 09:24:19 UTC+3, Praveen Chandrasekaran wrote:
>>
>> My weather station is Davis Vantage Vue. I believe it never emits partial
>> packets.
>>
>> On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:
>>>
>>> i doubt it very much.  what weather station do you have?
>>> changing the rf frequency changes the upload to wu interval but the
>>> station will still be being polled as before.  Does the station provide the
>>> gust value in the LOOP data?  If not then the gust value is an artificial
>>> one created by weewx from loop records wind speeds received.  If your
>>> station provides partial packets as LOOP data you could always try and set
>>> the wu flag that set specifies windGust must be present before rf is
>>> uploaded
>>>
>>> On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:

 If I set rtfreq to a higher value like 5 seconds, should that resolve
 the issue?

 On Fri, 26 Jul 2019 at 11:57, Andrew Milner 
 wrote:

> if from rf it has no gusts it cannot graph them.  non rf sites will
> provide a gust value per archive interval.  who knows what wu do when they
> receive both rf and archive record data!!  The tables may well create an
> artificial gust value from rf speeds, but again who knows what wu use to
> create the graphs!!
>
>
>
> On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:
>>
>> The table somehow has it right. The graph alone is wrong.
>>
>> On Fri, 26 Jul 2019 at 11:29, Andrew Milner 
>> wrote:
>>
>>> I would suspect WU ignore windgust on rapidfire because you need a
>>> sustained period of I think 3 seconds for the gust to count as a gust in
>>> metereological definitions - and the rf interval is probably too short 
>>> - so
>>> gust will always equal speed in rf situations.
>>>
>>> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:

 Related wxforum post:

 https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071


 On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran
 wrote:
>
> Hi,
>
> I am seeing that on stations with rapdifire, WU is not
> differentiating wind speed and wind gust in graph correctly. However 
> in
> stations without rapidfire it is fine.
>
> Example my station with rapidfire:
>
> https://www.wunderground.com/dashboard/pws/IBANGALO9
>
> Another station without rapidfire:
>
> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>
> Is this issue arising from weewx by any chance?
>
> Regards,
> Praveen
>
 --
>>> 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/E5uzJiv_ThY/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> weewx...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/51caf745-7385-40f9-ad35-81cfed29553e%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/E5uzJiv_ThY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/e1c86274-2f2a-4005-a3e3-8ac0d9028b66%40googlegroups.com
> 

Re: [weewx-user] Re: WU Wind graphs

[Andrew Milner]

I really do not see how you can have a meaningful gust value from readings 
submitted every few seconds!!  I see from the Davis comms protocol the gust 
values are in LOOP2 packets and the smallest appears to be a 2 minute gust 
value.

Setting debug=1 may shed more light on what is actually being sent to WU



On Monday, 29 July 2019 09:24:19 UTC+3, Praveen Chandrasekaran wrote:
>
> My weather station is Davis Vantage Vue. I believe it never emits partial 
> packets.
>
> On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:
>>
>> i doubt it very much.  what weather station do you have?
>> changing the rf frequency changes the upload to wu interval but the 
>> station will still be being polled as before.  Does the station provide the 
>> gust value in the LOOP data?  If not then the gust value is an artificial 
>> one created by weewx from loop records wind speeds received.  If your 
>> station provides partial packets as LOOP data you could always try and set 
>> the wu flag that set specifies windGust must be present before rf is 
>> uploaded
>>
>> On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> If I set rtfreq to a higher value like 5 seconds, should that resolve 
>>> the issue? 
>>>
>>> On Fri, 26 Jul 2019 at 11:57, Andrew Milner  
>>> wrote:
>>>
 if from rf it has no gusts it cannot graph them.  non rf sites will 
 provide a gust value per archive interval.  who knows what wu do when they 
 receive both rf and archive record data!!  The tables may well create an 
 artificial gust value from rf speeds, but again who knows what wu use to 
 create the graphs!!



 On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:
>
> The table somehow has it right. The graph alone is wrong.
>
> On Fri, 26 Jul 2019 at 11:29, Andrew Milner  
> wrote:
>
>> I would suspect WU ignore windgust on rapidfire because you need a 
>> sustained period of I think 3 seconds for the gust to count as a gust in 
>> metereological definitions - and the rf interval is probably too short - 
>> so 
>> gust will always equal speed in rf situations.  
>>
>> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> Related wxforum post:
>>>
>>> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>>>
>>>
>>> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran 
>>> wrote:

 Hi,

 I am seeing that on stations with rapdifire, WU is not 
 differentiating wind speed and wind gust in graph correctly. However 
 in 
 stations without rapidfire it is fine.

 Example my station with rapidfire:

 https://www.wunderground.com/dashboard/pws/IBANGALO9

 Another station without rapidfire:

 https://www.wunderground.com/dashboard/pws/IMUMBAI16

 Is this issue arising from weewx by any chance?

 Regards,
 Praveen

>>> -- 
>> 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/E5uzJiv_ThY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/51caf745-7385-40f9-ad35-81cfed29553e%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
 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/E5uzJiv_ThY/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 weewx...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/e1c86274-2f2a-4005-a3e3-8ac0d9028b66%40googlegroups.com
  
 
 .

>>>

-- 
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/7d2e07d8-d98a-41b3-a3b4-0c9cdcea6f25%40googlegroups.com.

Re: [weewx-user] Re: WU Wind graphs

[Praveen Chandrasekaran]

My weather station is Davis Vantage Vue. I believe it never emits partial 
packets.

On Friday, 26 July 2019 15:02:51 UTC+5:30, Andrew Milner wrote:
>
> i doubt it very much.  what weather station do you have?
> changing the rf frequency changes the upload to wu interval but the 
> station will still be being polled as before.  Does the station provide the 
> gust value in the LOOP data?  If not then the gust value is an artificial 
> one created by weewx from loop records wind speeds received.  If your 
> station provides partial packets as LOOP data you could always try and set 
> the wu flag that set specifies windGust must be present before rf is 
> uploaded
>
> On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:
>>
>> If I set rtfreq to a higher value like 5 seconds, should that resolve the 
>> issue? 
>>
>> On Fri, 26 Jul 2019 at 11:57, Andrew Milner  wrote:
>>
>>> if from rf it has no gusts it cannot graph them.  non rf sites will 
>>> provide a gust value per archive interval.  who knows what wu do when they 
>>> receive both rf and archive record data!!  The tables may well create an 
>>> artificial gust value from rf speeds, but again who knows what wu use to 
>>> create the graphs!!
>>>
>>>
>>>
>>> On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:

 The table somehow has it right. The graph alone is wrong.

 On Fri, 26 Jul 2019 at 11:29, Andrew Milner  
 wrote:

> I would suspect WU ignore windgust on rapidfire because you need a 
> sustained period of I think 3 seconds for the gust to count as a gust in 
> metereological definitions - and the rf interval is probably too short - 
> so 
> gust will always equal speed in rf situations.  
>
> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:
>>
>> Related wxforum post:
>>
>> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>>
>>
>> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran 
>> wrote:
>>>
>>> Hi,
>>>
>>> I am seeing that on stations with rapdifire, WU is not 
>>> differentiating wind speed and wind gust in graph correctly. However in 
>>> stations without rapidfire it is fine.
>>>
>>> Example my station with rapidfire:
>>>
>>> https://www.wunderground.com/dashboard/pws/IBANGALO9
>>>
>>> Another station without rapidfire:
>>>
>>> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>>>
>>> Is this issue arising from weewx by any chance?
>>>
>>> Regards,
>>> Praveen
>>>
>> -- 
> 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/E5uzJiv_ThY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/51caf745-7385-40f9-ad35-81cfed29553e%40googlegroups.com
>  
> 
> .
>
 -- 
>>> 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/E5uzJiv_ThY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> weewx...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/e1c86274-2f2a-4005-a3e3-8ac0d9028b66%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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/7a1bdbd3-fbcb-4649-a3b2-86b645caab2b%40googlegroups.com.