[weewx-user] Re: cm or Zoll

[gjr80]

Hi,

I presume you are talking about the add sensor 
 entry in the wiki? 

Assuming this is the case. There are 3 places in weewx where units are 
critical. The data coming from the station, the data being stored in the 
database and the data displayed on reports. weewx uses 3 unit systems; US, 
METRIC or METRICWX. These 3 unit systems define the units used by the 
different observation groups, for example, under the US unit system all 
temperatures are in degrees F, but under METRIC and METRICWX all 
temperatures are in degrees C. Records coming from the station will be in 
one of these 3 unit systems, what system it is largely depends on the 
driver, the driver author or what side of the bed the author got out of the 
day he wrote the driver. Once weewx has the record from the driver and is 
ready to save it to the database, the unit system of the record is checked 
against the unit system in the database and if necessary the record is 
converted to the unit system used by the database. So if the station 
emitted a record using the METRIC unit system, and the database uses the US 
unit system (the default), the record would be converted to the US unit 
system (so all temperatures are converted from C to F, speeds from km/h to 
mph etc) and the record is then saved to the database. When it comes to 
reporting the report generation system has its own system of formatting and 
converting to display the underlying data (which may in US units, or METRIC 
or METRICWX) in whatever units you wish. If you understand this basic 
concept you will better understand what is happening to your data in 
pond.txt and more importantly why.

In your case, it sounds like you have decided to use a METRIC database, 
that is fine there is no particular advantage to this (in fact it can be a 
hindrance in some situations). It depends on what driver/station you have, 
but I suspect that the records coming from your station us the US unit 
system. So the 'add sensor' code simply reads a number from the file, in 
this case 1.0, and then places that number in a field in the record. That 
field, by the sounds of it, will be a group_rain or group_length field that 
when used under the US unit system is in inches. So weewx believes you have 
added a value of 1.0 inches (remember your record uses the US unit system). 
When the time comes to store that data in your database, weewx checks the 
unit system of the record, sees it is US which is different to the METRIC 
unit system used by the database and weewx converts the values. weewx 
believes it is converting your 1.0 value from inches to cm and hence it 
becomes 2.54cm (1.0 inch = 2.54cm).

So how to you fix your problem. There are a few options that vary in 
complexity and simplicity. These are:
1. Make sure the value you put in /var/tmp/pond.txt is in inches. This is 
the simplest but perhaps not acceptable to you - you would have to convert 
the 34cm of snow to inches!
2. Continue to put cm values in var/tmp/pond.txt but put some code in your 
read_file() method to do the conversion. Something like this (untested):

import syslog
import weewx
from weewx.wxengine import StdService
from weewx.units import ValueTuple, convert

class PondService(StdService):
def __init__(self, engine, config_dict):
super(PondService, self).__init__(engine, config_dict)  
d = config_dict.get('PondService', {})
self.filename = d.get('filename', '/var/tmp/pond.txt')
syslog.syslog(syslog.LOG_INFO, "pond: using %s" % self.filename)
self.bind(weewx.NEW_ARCHIVE_RECORD, self.read_file)

def read_file(self, event):
try:
with open(self.filename) as f:
value = f.read()
syslog.syslog(syslog.LOG_DEBUG, "pond: found value of %s" % 
value)
# Convert our value to a type ValueTuple. We know it is in cm 
and
# let's use group_rain (could use group_length too)
value_vt = ValueTuple(float(value), 'cm', 'group_rain')
# Now convert the cm value to the same units as used in our 
record
# The unit system of the record is in the records 'usUnits' 
field
value_conv = convert(value_vt, event.record['usUnits'])
event.record['some_field_name'] = value_conv
except Exception, e:
syslog.syslog(syslog.LOG_ERR, "pond: cannot read value: %s" % e)

Hopefully that gets the point across. You could further refine this in a 
number of ways. You could have it read the units from pond.txt, so when 
your US friends read your snow and use inches it still works (rather than 
doing a double conversion). You could add some conditional checks or 
try..except statements to handle invalid data or None coming in from your 
file (ie what to do if you get a non-numeric answer).

If it was me I would be going down the path of option 2. It is far more 
elegant and capable.

Gary


On Saturday, 14 January 

[weewx-user] Re: ultimeter setup troubles

[Steve2Q]

If you try what Matthew suggests and everything appears ok, may try a 
different driver. There were several iterations of the Ultimeter driver, 
and I had problems with the last one (it would not keep proper time on my 
2100 console). I am not saying this will take care of your problem, as 
Matthew is a Weewx god, but maybe it is worth a try.

Steve


-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#!/usr/bin/env python
# $Id: ultimeter.py 2842 2015-01-10 16:12:02Z mwall $
# Copyright 2014 Matthew Wall
# Copyright 2014 Nate Bargmann 
# See the file LICENSE.txt for your full rights.
#
# Credit to and contributions from:
#   Jay Nugent (WB8TKL) and KRK6 for weather-2.kr6k-V2.1
# http://server1.nuge.com/~weather/
#   Steve (sesykes71) for testing the first implementations of this driver
#   Garret Power for decoding improvements and testing

"""Driver for Peet Bros Ultimeter weather stations except the Ultimeter II

This driver assumes the Ultimeter is emitting data in Peet Bros Data Logger
mode format.

Resources for the Ultimeter stations

Ultimeter Models 2100, 2000, 800, & 100 serial specifications:
  http://www.peetbros.com/shop/custom.aspx?recid=29

Ultimeter 2000 Pinouts and Parsers:
  http://www.webaugur.com/ham-radio/52-ultimeter-2000-pinouts-and-parsers.html

Ultimeter II
  not supported by this driver

All models communicate over an RS-232 compatible serial port using three
wires--RXD, TXD, and Ground (except Ultimeter II which omits TXD).  Port
parameters are 2400, 8N1, with no flow control.

The Ultimeter hardware supports several "modes" for providing station data
to the serial port.  This driver utilizes the "modem mode" to set the date
and time of the Ultimeter upon initialization and then sets it into Data
Logger mode for continuous updates.

Modem Mode commands used by the driver
>A  Set Date and Time (decimal digits  = day of year,
 = minute of day; Jan 1 = , Midnight = )

>I  Set output mode to Data Logger Mode (continuous output)

"""

from __future__ import with_statement
import serial
import syslog
import time

import weewx.drivers

DRIVER_NAME = 'Ultimeter'
DRIVER_VERSION = '0.11rc3'

INHG_PER_MBAR = 0.0295333727
METER_PER_FOOT = 0.3048
MILE_PER_KM = 0.621371

def loader(config_dict, engine):
return Ultimeter(**config_dict[DRIVER_NAME])

def confeditor_loader():
return UltimeterConfEditor()


DEFAULT_PORT = '/dev/ttyS0'
DEBUG_READ = 0

def logmsg(level, msg):
syslog.syslog(level, 'ultimeter: %s' % msg)

def logdbg(msg):
logmsg(syslog.LOG_DEBUG, msg)

def loginf(msg):
logmsg(syslog.LOG_INFO, msg)

def logerr(msg):
logmsg(syslog.LOG_ERR, msg)


class Ultimeter(weewx.drivers.AbstractDevice):
"""weewx driver that communicates with a Peet Bros Ultimeter station

model: station model, e.g., 'Ultimeter 2000' or 'Ultimeter 100'
[Optional. Default is 'Ultimeter']

port - serial port
[Required. Default is /dev/ttyS0]

polling_interval - how often to query the serial interface, seconds
[Optional. Default is 1]

max_tries - how often to retry serial communication before giving up
[Optional. Default is 5]
"""
def __init__(self, **stn_dict):
self.model = stn_dict.get('model', 'Ultimeter')
self.port = stn_dict.get('port', DEFAULT_PORT)
self.polling_interval = float(stn_dict.get('polling_interval', 1))
self.max_tries = int(stn_dict.get('max_tries', 5))
self.retry_wait = int(stn_dict.get('retry_wait', 10))
self.last_rain = None
loginf('driver version is %s' % DRIVER_VERSION)
loginf('using serial port %s' % self.port)
loginf('polling interval is %s' % str(self.polling_interval))
global DEBUG_READ
DEBUG_READ = int(stn_dict.get('debug_read', DEBUG_READ))

def genLoopPackets(self):
ntries = 0
while ntries < self.max_tries:
ntries += 1
try:
packet = {'dateTime': int(time.time() + 0.5),
  'usUnits': weewx.US}
# open a new connection to the station for each reading
with Station(self.port) as station:
readings = station.get_readings()
data = Station.parse_readings(readings)
packet.update(data)
self._augment_packet(packet)
ntries = 0
yield packet
if self.polling_interval:
time.sleep(self.polling_interval)
except (serial.serialutil.SerialException, weewx.WeeWxIOError), e:
logerr("Failed attempt %d of %d to get LOOP data: %s" %
   (ntries, self.max_tries, e))
  

Re: [weewx-user] Matching rain corrections with weewx and Weather Underground

[Thomas Keffer]

I have no idea how they factor in RapidFire values: they don't publish that.

RF is a black box, that they don't seem to be paying much attention to.

-tk

On Fri, Jan 13, 2017 at 6:56 PM, J  wrote:

> Hmm, perhaps I just didn't wait long enough then. My values definitely
> diverged, so I removed the correction so avoid having to correct a lot of
> data.  Does wunderground calculate an intermediate value from uncorrected
> values sent via rapidfire, which then get replaced once per hour by the
> database values? Or is the 60-minute sum sent with each update? If the
> latter, perhaps it was just a difference in wunderground's rounding (or
> lack thereof).
>
> On Friday, January 13, 2017 at 6:40:17 PM UTC-8, Tom Keffer wrote:
>>
>> The value sent to wunderground is calculated directly from the database.
>> It's the sum of all rain that fell during the last 60 minutes. So, if
>> you're happy with the values of 'rain' in the database, then you should
>> be getting the same at wunderground.
>>
>> -tk
>>
>> On Fri, Jan 13, 2017 at 6:21 PM, J  wrote:
>>
>>> Hi,
>>>
>>> I'm trying to apply some corrections to my rain data but am running into
>>> an issue with getting Wunderground data to match.
>>>
>>> I want to adjust my rain corrections based on wind data -- I'm
>>> compensating for undercatch during high winds due to my rain bucket's
>>> higher than typical elevation above ground. I'm using a Davis VantagePro2.
>>>
>>> Making corrections to rain and rainRate using windGust works great in
>>> weewx. Each 0.01" tip is adjusted by current wind conditions. However,
>>> Wunderground values are uncorrected. From some reading of past threads, it
>>> sounds like Wunderground data may instead use dayRain and hourRain values
>>> directly from archive records, instead of simply pushing up the weewx
>>> values. I run into the issue that if I try to adjust dayRain and/or
>>> hourRain based on wind from the archive records, not only will the totals
>>> differ because of wind values from different periods, but it seems like the
>>> entire day total would be repeatedly scaled up and down based on whatever
>>> the last wind reading was.
>>>
>>> Is there a way to have the data sent to Wunderground based on the totals
>>> stored by weewx? Or otherwise keep them synced in a sane manner?
>>>
>>> Thanks!
>>> Jesse
>>>
>>> P.S. I'd also love to be able to use windDirection and rainRate as
>>> factors in the corrections, but that's probably overly ambitious without
>>> support for conditionals in corrections.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-user+...@googlegroups.com.
>>> 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] Matching rain corrections with weewx and Weather Underground

[J]

Hmm, perhaps I just didn't wait long enough then. My values definitely 
diverged, so I removed the correction so avoid having to correct a lot of 
data.  Does wunderground calculate an intermediate value from uncorrected 
values sent via rapidfire, which then get replaced once per hour by the 
database values? Or is the 60-minute sum sent with each update? If the 
latter, perhaps it was just a difference in wunderground's rounding (or 
lack thereof).

On Friday, January 13, 2017 at 6:40:17 PM UTC-8, Tom Keffer wrote:
>
> The value sent to wunderground is calculated directly from the database. 
> It's the sum of all rain that fell during the last 60 minutes. So, if 
> you're happy with the values of 'rain' in the database, then you should 
> be getting the same at wunderground. 
>
> -tk
>
> On Fri, Jan 13, 2017 at 6:21 PM, J  
> wrote:
>
>> Hi,
>>
>> I'm trying to apply some corrections to my rain data but am running into 
>> an issue with getting Wunderground data to match.
>>
>> I want to adjust my rain corrections based on wind data -- I'm 
>> compensating for undercatch during high winds due to my rain bucket's 
>> higher than typical elevation above ground. I'm using a Davis VantagePro2.
>>
>> Making corrections to rain and rainRate using windGust works great in 
>> weewx. Each 0.01" tip is adjusted by current wind conditions. However, 
>> Wunderground values are uncorrected. From some reading of past threads, it 
>> sounds like Wunderground data may instead use dayRain and hourRain values 
>> directly from archive records, instead of simply pushing up the weewx 
>> values. I run into the issue that if I try to adjust dayRain and/or 
>> hourRain based on wind from the archive records, not only will the totals 
>> differ because of wind values from different periods, but it seems like the 
>> entire day total would be repeatedly scaled up and down based on whatever 
>> the last wind reading was.
>>
>> Is there a way to have the data sent to Wunderground based on the totals 
>> stored by weewx? Or otherwise keep them synced in a sane manner?
>>
>> Thanks!
>> Jesse
>>
>> P.S. I'd also love to be able to use windDirection and rainRate as 
>> factors in the corrections, but that's probably overly ambitious without 
>> support for conditionals in corrections.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com .
>> 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] Matching rain corrections with weewx and Weather Underground

[Thomas Keffer]

The value sent to wunderground is calculated directly from the database.
It's the sum of all rain that fell during the last 60 minutes. So, if
you're happy with the values of 'rain' in the database, then you should be
getting the same at wunderground.

-tk

On Fri, Jan 13, 2017 at 6:21 PM, J  wrote:

> Hi,
>
> I'm trying to apply some corrections to my rain data but am running into
> an issue with getting Wunderground data to match.
>
> I want to adjust my rain corrections based on wind data -- I'm
> compensating for undercatch during high winds due to my rain bucket's
> higher than typical elevation above ground. I'm using a Davis VantagePro2.
>
> Making corrections to rain and rainRate using windGust works great in
> weewx. Each 0.01" tip is adjusted by current wind conditions. However,
> Wunderground values are uncorrected. From some reading of past threads, it
> sounds like Wunderground data may instead use dayRain and hourRain values
> directly from archive records, instead of simply pushing up the weewx
> values. I run into the issue that if I try to adjust dayRain and/or
> hourRain based on wind from the archive records, not only will the totals
> differ because of wind values from different periods, but it seems like the
> entire day total would be repeatedly scaled up and down based on whatever
> the last wind reading was.
>
> Is there a way to have the data sent to Wunderground based on the totals
> stored by weewx? Or otherwise keep them synced in a sane manner?
>
> Thanks!
> Jesse
>
> P.S. I'd also love to be able to use windDirection and rainRate as factors
> in the corrections, but that's probably overly ambitious without support
> for conditionals in corrections.
>
> --
> 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] Matching rain corrections with weewx and Weather Underground

[J]

Hi,

I'm trying to apply some corrections to my rain data but am running into an 
issue with getting Wunderground data to match.

I want to adjust my rain corrections based on wind data -- I'm compensating 
for undercatch during high winds due to my rain bucket's higher than 
typical elevation above ground. I'm using a Davis VantagePro2.

Making corrections to rain and rainRate using windGust works great in 
weewx. Each 0.01" tip is adjusted by current wind conditions. However, 
Wunderground values are uncorrected. From some reading of past threads, it 
sounds like Wunderground data may instead use dayRain and hourRain values 
directly from archive records, instead of simply pushing up the weewx 
values. I run into the issue that if I try to adjust dayRain and/or 
hourRain based on wind from the archive records, not only will the totals 
differ because of wind values from different periods, but it seems like the 
entire day total would be repeatedly scaled up and down based on whatever 
the last wind reading was.

Is there a way to have the data sent to Wunderground based on the totals 
stored by weewx? Or otherwise keep them synced in a sane manner?

Thanks!
Jesse

P.S. I'd also love to be able to use windDirection and rainRate as factors 
in the corrections, but that's probably overly ambitious without support 
for conditionals in corrections.

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

[weewx-user] Re: WeeWx-WD SS gauges config

[gjr80]

Ok, I what has happened now.

The wxssgauges.php page is distributed with the WD plugin for the Saratoga 
templates, wxssgauges.php has a variable that is set to refer to the 
location of the SteelSeries Weather Gauages scripts. When I donwloaded and 
installed the gauges some time ago (v2.4.4 - pre-GitHub version) the 
included gauges-ss-basic-inc.php was slightly different, it used $ssgDir:

  

  
  http://code.jquery.com/jquery-1.11.1.min.js";>
  
  
  

  
  


  
  
  

  
  

   

whereas the version on GitHub now does not make use of $ssgDir in 
gauges-ss-basic-inc.php.

So what to do? I think you have 3 choices:

1. Get rid of the web-server directory (move its contents, both files and 
folders, to st/ssg). This shoul dresult in the scripts being found and the 
page loading
2. Change the "src=scripts/..." entries in gauges-ss-basic-inc.php to 
"src=scripts/...". You now have an orphan file, though it is unlikely to 
chnage too much in the future.
3. Get hold of the old gauges-ss-basic-inc.php and use it. probably best to 
go with the latest version though.

I would be doing 1.

Gary

On Saturday, 14 January 2017 07:27:26 UTC+10, Dan'l B wrote:
>
> Attached. I am assuming you meant the contents of gauges-ss-basic-inc.php, 
> which is what I have attached.
>
> On Friday, January 13, 2017 at 4:03:56 PM UTC-5, gjr80 wrote:
>>
>> Ok, the setup seems OK as far as I can tell; I can see all your scripts 
>> just where you say they are. However, there is a path issue. If you do a 
>> view source when you have wxssgauges.php open in your browser you will 
>> see the following lines (circa line 570):
>>
>>   > src="http://code.jquery.com/jquery-1.11.1.min.js";>
>>   > src="scripts/steelseries_tween.min.js">> src="scripts/language.min.js">  > src="scripts/gauges.js">
>>   > src="scripts/RGraph.rose.min.js">
>> changeLang(LANG.EN);  // change SteelSeries language
>>
>>
>> The problem is the value of $ssgDir should have been prepended to all or 
>> the src strings for each of the scripts. (eg I have $ssg=./ssg/ and my src 
>> settings are src="./ssg/scripts/gauges.js" etc). So the bottom line is 
>> the browser cannot find the sripts so no gauges are drawn. All I can think 
>> is that something is going astray in the php code. Can you post the 
>> contents of your st/wxssgauges.php and 
>> st/ssg/web_server/gauges-ss-basic.php files, I can't see the php source. 
>> Google groups might not let you post php files, either just rename as .txt 
>> files or post the contents
>>
>> Gary
>>
>>
>> On Saturday, 14 January 2017 02:20:44 UTC+10, Dan'l B wrote:
>>>
>>> With the Saratoga templates in /st, the ss gauges dir is /st/ssg.
>>>
 $ssgDir is set to '/ssg/web_server/'

>>> $ssgDir = './ssg/web_server/';
>>>
>>>  
>>> All the files generated by WeeWx-WD are uploaded to /st
>>> And the path to the ccr file in gauges.js is:
>>>
 realTimeUrlWD  : '../../../../customclientraw.txt',

>>>
>>> gauges-ss-basic.inc and gauges-ss-basic.htm are in the web_server 
>>> directory.
>>>
>>> On Thursday, January 12, 2017 at 11:00:34 PM UTC-5, gjr80 wrote:

 No Andrew, 6 is for when you are using SteelSeries with gauge-data.txt, 
 the above question relates to weewx-WD where you are mimicing WD (and 
 using 
 customclientraw.txt).

 The issue is almost certainly an issue of incorrect paths. Your 
 saratoga php pages seem to be in the st directory on your web server, 
 where do the SteelSeries files sit in respect to the st directory? You 
 should have a directory that contains gauges-ss-basic-inc.php, 
 gauges-ss-basic.htm etc. What is the name of this directory and where 
 does it sit on the server? In wxssgauges.php what is $ssgDir set to in 
 the following line (circa line 44)

 $ssgDir = './ssg/'; // set to relative directory location of the 
 SteelSeries gauge directory

 Gary

 On Friday, 13 January 2017 13:37:03 UTC+10, Andrew Milner wrote:
>
> Shouldn't it be set to 6 for weewx??
>
>
>
> On Friday, 13 January 2017 05:15:20 UTC+2, Dan'l B wrote:
>
>> I seem to be almost there on getting the SS gauges working in the 
>> Saratoga Templates but not quite:
>>
>> http://suiattle.net/DinkinsBayouWeather/st/wxssgauges.php
>>
>> Can someone point me to what I am missing here?
>>
>> in gauges.js:
>> Weather Program is set to 1
>>
>>>  weatherProgram : 1,  //Set 0=Cumulus, 
 1=Weather Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX
>>>
>>> imgPathURL : ''',//*** Change this 
 to the relative path for your 'Trend' graph images
>>>
>>> oldGauges  : '',  
>>>
>>>
>> and the path to the customclientraw.txt is correct:

[weewx-user] Re: ultimeter setup troubles

[Eelco F]

Allright, thanx for your quick reply. This is what I got:


Jan 13 22:19:50 server weewx[3331]:  * Starting weewx weather system weewx
Jan 13 22:19:51 server weewx[3344]: engine: Initializing weewx version 3.6.2
Jan 13 22:19:51 server weewx[3344]: engine: Using Python 2.7.12 (default, 
Nov 19 2016, 06:48:10) #012[GCC 5.4.0 20160609]
Jan 13 22:19:51 server weewx[3344]: engine: Platform 
Linux-4.4.0-59-generic-x86_64-with-Ubuntu-16.04-xenial
Jan 13 22:19:51 server weewx[3344]: engine: pid file is /var/run/weewx.pid
Jan 13 22:19:51 server weewx[3348]: engine: Using configuration file 
/etc/weewx/weewx.conf
Jan 13 22:19:51 server weewx[3348]: engine: Initializing engine
Jan 13 22:19:51 server weewx[3348]: engine: Loading station type Ultimeter 
(weewx.drivers.ultimeter)
Jan 13 22:19:51 server weewx[3331]:...done.
Jan 13 22:19:51 server systemd[1]: Started LSB: weewx weather system.
Jan 13 22:19:51 server weewx[3348]: ultimeter: driver version is 0.16
Jan 13 22:19:51 server weewx[3348]: ultimeter: using serial port /dev/ttyS0
Jan 13 22:19:51 server weewx[3348]: ultimeter: open serial port /dev/ttyS0
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.engine.StdTimeSynch
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.engine.StdTimeSynch
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.engine.StdConvert
Jan 13 22:19:51 server weewx[3348]: engine: StdConvert target unit is 0x1
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.engine.StdConvert
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.engine.StdCalibrate
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.engine.StdCalibrate
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.engine.StdQC
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.engine.StdQC
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.wxservices.StdWXCalculate
Jan 13 22:19:51 server weewx[3348]: wxcalculate: The following values will 
be calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
dewpoint=prefer_hardware, appTemp=prefer_hardware, 
rainRate=prefer_hardware, windrun=prefer_hardware, 
heatindex=prefer_hardware, maxSolarRad=prefer_hardware, 
humidex=prefer_hardware, pressure=prefer_hardware, 
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
cloudbase=prefer_hardware
Jan 13 22:19:51 server weewx[3348]: wxcalculate: The following algorithms 
will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.wxservices.StdWXCalculate
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.engine.StdArchive
Jan 13 22:19:51 server weewx[3348]: engine: Archive will use data binding 
wx_binding
Jan 13 22:19:51 server weewx[3348]: engine: Record generation will be 
attempted in 'hardware'
Jan 13 22:19:51 server weewx[3348]: engine: Using archive interval of 300 
seconds (specified in weewx configuration)
Jan 13 22:19:51 server weewx[3348]: engine: Use LOOP data in hi/low 
calculations: 1
Jan 13 22:19:51 server weewx[3348]: engine: Using binding 'wx_binding' to 
database 'weewx.sdb'
Jan 13 22:19:51 server weewx[3348]: manager: Starting backfill of daily 
summaries
Jan 13 22:19:51 server weewx[3348]: manager: Daily summaries up to date
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.engine.StdArchive
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.restx.StdStationRegistry
Jan 13 22:19:51 server weewx[3348]: restx: StationRegistry: Registration 
not requested.
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.restx.StdStationRegistry
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.restx.StdWunderground
Jan 13 22:19:51 server weewx[3348]: restx: Wunderground: Posting not 
enabled.
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.restx.StdWunderground
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.restx.StdPWSweather
Jan 13 22:19:51 server weewx[3348]: restx: PWSweather: Posting not enabled.
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.restx.StdPWSweather
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.restx.StdCWOP
Jan 13 22:19:51 server weewx[3348]: restx: CWOP: Posting not enabled.
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.restx.StdCWOP
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.restx.StdWOW
Jan 13 22:19:51 server weewx[3348]: restx: WOW: Posting not enabled.
Jan 13 22:19:51 server weewx[3348]: engine: Finished loading service 
weewx.restx.StdWOW
Jan 13 22:19:51 server weewx[3348]: engine: Loading service 
weewx.restx.StdAWEKAS
Jan 13 22:19:51 server weewx[3348]: restx: AWEKAS: Posting not enabled.
Jan 13 22:19:51 server weewx[3348]: engine: 

[weewx-user] Re: WeeWx-WD SS gauges config

[Dan'l B]

Attached. I am assuming you meant the contents of gauges-ss-basic-inc.php, 
which is what I have attached.

On Friday, January 13, 2017 at 4:03:56 PM UTC-5, gjr80 wrote:
>
> Ok, the setup seems OK as far as I can tell; I can see all your scripts 
> just where you say they are. However, there is a path issue. If you do a 
> view source when you have wxssgauges.php open in your browser you will 
> see the following lines (circa line 570):
>
>src="http://code.jquery.com/jquery-1.11.1.min.js";>
>src="scripts/steelseries_tween.min.js"> src="scripts/language.min.js">   src="scripts/gauges.js">
>src="scripts/RGraph.rose.min.js"> 
> changeLang(LANG.EN);  // change SteelSeries language
>
>
> The problem is the value of $ssgDir should have been prepended to all or 
> the src strings for each of the scripts. (eg I have $ssg=./ssg/ and my src 
> settings are src="./ssg/scripts/gauges.js" etc). So the bottom line is 
> the browser cannot find the sripts so no gauges are drawn. All I can think 
> is that something is going astray in the php code. Can you post the 
> contents of your st/wxssgauges.php and 
> st/ssg/web_server/gauges-ss-basic.php files, I can't see the php source. 
> Google groups might not let you post php files, either just rename as .txt 
> files or post the contents
>
> Gary
>
>
> On Saturday, 14 January 2017 02:20:44 UTC+10, Dan'l B wrote:
>>
>> With the Saratoga templates in /st, the ss gauges dir is /st/ssg.
>>
>>> $ssgDir is set to '/ssg/web_server/'
>>>
>> $ssgDir = './ssg/web_server/';
>>
>>  
>> All the files generated by WeeWx-WD are uploaded to /st
>> And the path to the ccr file in gauges.js is:
>>
>>> realTimeUrlWD  : '../../../../customclientraw.txt',
>>>
>>
>> gauges-ss-basic.inc and gauges-ss-basic.htm are in the web_server 
>> directory.
>>
>> On Thursday, January 12, 2017 at 11:00:34 PM UTC-5, gjr80 wrote:
>>>
>>> No Andrew, 6 is for when you are using SteelSeries with gauge-data.txt, 
>>> the above question relates to weewx-WD where you are mimicing WD (and using 
>>> customclientraw.txt).
>>>
>>> The issue is almost certainly an issue of incorrect paths. Your saratoga 
>>> php pages seem to be in the st directory on your web server, where do 
>>> the SteelSeries files sit in respect to the st directory? You should 
>>> have a directory that contains gauges-ss-basic-inc.php, 
>>> gauges-ss-basic.htm etc. What is the name of this directory and where 
>>> does it sit on the server? In wxssgauges.php what is $ssgDir set to in 
>>> the following line (circa line 44)
>>>
>>> $ssgDir = './ssg/'; // set to relative directory location of the 
>>> SteelSeries gauge directory
>>>
>>> Gary
>>>
>>> On Friday, 13 January 2017 13:37:03 UTC+10, Andrew Milner wrote:

 Shouldn't it be set to 6 for weewx??



 On Friday, 13 January 2017 05:15:20 UTC+2, Dan'l B wrote:

> I seem to be almost there on getting the SS gauges working in the 
> Saratoga Templates but not quite:
>
> http://suiattle.net/DinkinsBayouWeather/st/wxssgauges.php
>
> Can someone point me to what I am missing here?
>
> in gauges.js:
> Weather Program is set to 1
>
>>  weatherProgram : 1,  //Set 0=Cumulus, 
>>> 1=Weather Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX
>>
>> imgPathURL : ''',//*** Change this to 
>>> the relative path for your 'Trend' graph images
>>
>> oldGauges  : '',  
>>
>>
> and the path to the customclientraw.txt is correct:
>
>> realTimeUrlWD  : '../../../../WD/customclientraw.txt',//*** 
>> WD Users: Change to your location of the ccr file *** 
>
>
>  
>


-- 
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.
  
  
This pages requires 
JavaScript enabling in your browser.Please enable scripting 
it to enjoy this site at its best.
  
  



  
  

  

  
  Outside
  Inside


  

  
  Dew 
Point
  Apparent
  
  Wind 
Chill
  Heat 
Index
  
  Humidex


  

  
  Outside
  Inside

  
  

  


  


  

  
  

  


  


  

  
  

  


  


  

  

  

  
Temperature:
  
  
C
  
  
F
  


  
Rainfall:
  
  
mm
  
  
Inch
  


  
Pressure:
  
  
hPa
  

[weewx-user] Re: WeeWx-WD SS gauges config

[gjr80]

Ok, the setup seems OK as far as I can tell; I can see all your scripts 
just where you say they are. However, there is a path issue. If you do a 
view source when you have wxssgauges.php open in your browser you will see 
the following lines (circa line 570):

  http://code.jquery.com/jquery-1.11.1.min.js";>
 
changeLang(LANG.EN);  // change SteelSeries language


The problem is the value of $ssgDir should have been prepended to all or 
the src strings for each of the scripts. (eg I have $ssg=./ssg/ and my src 
settings 
are src="./ssg/scripts/gauges.js" etc). So the bottom line is the browser 
cannot find the sripts so no gauges are drawn. All I can think is that 
something is going astray in the php code. Can you post the contents of 
your st/wxssgauges.php and st/ssg/web_server/gauges-ss-basic.php files, I 
can't see the php source. Google groups might not let you post php files, 
either just rename as .txt files or post the contents

Gary


On Saturday, 14 January 2017 02:20:44 UTC+10, Dan'l B wrote:
>
> With the Saratoga templates in /st, the ss gauges dir is /st/ssg.
>
>> $ssgDir is set to '/ssg/web_server/'
>>
> $ssgDir = './ssg/web_server/';
>
>  
> All the files generated by WeeWx-WD are uploaded to /st
> And the path to the ccr file in gauges.js is:
>
>> realTimeUrlWD  : '../../../../customclientraw.txt',
>>
>
> gauges-ss-basic.inc and gauges-ss-basic.htm are in the web_server 
> directory.
>
> On Thursday, January 12, 2017 at 11:00:34 PM UTC-5, gjr80 wrote:
>>
>> No Andrew, 6 is for when you are using SteelSeries with gauge-data.txt, 
>> the above question relates to weewx-WD where you are mimicing WD (and using 
>> customclientraw.txt).
>>
>> The issue is almost certainly an issue of incorrect paths. Your saratoga 
>> php pages seem to be in the st directory on your web server, where do 
>> the SteelSeries files sit in respect to the st directory? You should 
>> have a directory that contains gauges-ss-basic-inc.php, 
>> gauges-ss-basic.htm etc. What is the name of this directory and where 
>> does it sit on the server? In wxssgauges.php what is $ssgDir set to in 
>> the following line (circa line 44)
>>
>> $ssgDir = './ssg/'; // set to relative directory location of the 
>> SteelSeries gauge directory
>>
>> Gary
>>
>> On Friday, 13 January 2017 13:37:03 UTC+10, Andrew Milner wrote:
>>>
>>> Shouldn't it be set to 6 for weewx??
>>>
>>>
>>>
>>> On Friday, 13 January 2017 05:15:20 UTC+2, Dan'l B wrote:
>>>
 I seem to be almost there on getting the SS gauges working in the 
 Saratoga Templates but not quite:

 http://suiattle.net/DinkinsBayouWeather/st/wxssgauges.php

 Can someone point me to what I am missing here?

 in gauges.js:
 Weather Program is set to 1

>  weatherProgram : 1,  //Set 0=Cumulus, 
>> 1=Weather Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX
>
> imgPathURL : ''',//*** Change this to 
>> the relative path for your 'Trend' graph images
>
> oldGauges  : '',  
>
>
 and the path to the customclientraw.txt is correct:

> realTimeUrlWD  : '../../../../WD/customclientraw.txt',//*** WD 
> Users: Change to your location of the ccr file *** 


  

>>>

-- 
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: ultimeter setup troubles

[mwall]

On Friday, January 13, 2017 at 3:38:05 PM UTC-5, Eelco F wrote:
>
>
> I just can get it to work. Am I missing some point here? 
> Or should I put the ultimeter in modem mode device first so the driver can 
> set the correct setting?
>

the drive will attempt to put the ultimeter in modem mode, so you should 
not have to do that.
 

> any thoughts are appreciated.
>

enable additional debug logging like this:

[Ultimeter]
driver = weewx.drivers.ultimeter
port = /dev/ttyS0
debug_serial = 1

then start weewx.  then check the log.

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] ultimeter setup troubles

[Eelco F]

Hi all,

I'm trying to setup my second weatherstation project (first was a Davis). 
This time it's an ultimeter 2100. weewx is 3.6.2-1
I connect the serial interface and put the ultimeter in datalogger mode. I 
ran weewx both directly, and as a service. weewx.conf is almost out of the 
box, except for the setiings for the ultimeter off course.
However, nothing shows up. I set debug =1 in weewx .conf, and the log shows 
the following:

Jan 13 20:51:36 server weewx[6536]: engine: Initializing weewx version 3.6.2
Jan 13 20:51:36 server weewx[6536]: engine: Using Python 2.7.12 (default, 
Nov 19 2016, 06:48:10) #012[GCC 5.4.0 20160609]
Jan 13 20:51:36 server weewx[6536]: engine: Platform 
Linux-4.4.0-57-generic-x86_64-with-Ubuntu-16.04-xenial
Jan 13 20:51:36 server weewx[6536]: engine: Using configuration file 
/etc/weewx/weewx.conf
Jan 13 20:51:36 server weewx[6536]: engine: Initializing engine
Jan 13 20:51:36 server weewx[6536]: engine: Loading station type Ultimeter 
(weewx.drivers.ultimeter)
Jan 13 20:51:36 server weewx[6536]: ultimeter: driver version is 0.16
Jan 13 20:51:36 server weewx[6536]: ultimeter: using serial port /dev/ttyS0
Jan 13 20:51:36 server weewx[6536]: ultimeter: open serial port /dev/ttyS0
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.engine.StdTimeSynch
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.engine.StdTimeSynch
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.engine.StdConvert
Jan 13 20:51:36 server weewx[6536]: engine: StdConvert target unit is 0x1
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.engine.StdConvert
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.engine.StdCalibrate
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.engine.StdCalibrate
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.engine.StdQC
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.engine.StdQC
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.wxservices.StdWXCalculate
Jan 13 20:51:36 server weewx[6536]: wxcalculate: The following values will 
be calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
dewpoint=prefer_hardware, appTemp=prefer_hardware, 
rainRate=prefer_hardware, windrun=prefer_hardware, 
heatindex=prefer_hardware, maxSolarRad=prefer_hardware, 
humidex=prefer_hardware, pressure=prefer_hardware, 
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
cloudbase=prefer_hardware
Jan 13 20:51:36 server weewx[6536]: wxcalculate: The following algorithms 
will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.wxservices.StdWXCalculate
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.engine.StdArchive
Jan 13 20:51:36 server weewx[6536]: engine: Archive will use data binding 
wx_binding
Jan 13 20:51:36 server weewx[6536]: engine: Record generation will be 
attempted in 'hardware'
Jan 13 20:51:36 server weewx[6536]: engine: Using archive interval of 300 
seconds (specified in weewx configuration)
Jan 13 20:51:36 server weewx[6536]: engine: Use LOOP data in hi/low 
calculations: 1
Jan 13 20:51:36 server weewx[6536]: engine: Using binding 'wx_binding' to 
database 'weewx.sdb'
Jan 13 20:51:36 server weewx[6536]: manager: Starting backfill of daily 
summaries
Jan 13 20:51:36 server weewx[6536]: manager: Daily summaries up to date
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.engine.StdArchive
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.restx.StdStationRegistry
Jan 13 20:51:36 server weewx[6536]: restx: StationRegistry: Registration 
not requested.
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.restx.StdStationRegistry
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.restx.StdWunderground
Jan 13 20:51:36 server weewx[6536]: restx: Wunderground: Posting not 
enabled.
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.restx.StdWunderground
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.restx.StdPWSweather
Jan 13 20:51:36 server weewx[6536]: restx: PWSweather: Posting not enabled.
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.restx.StdPWSweather
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.restx.StdCWOP
Jan 13 20:51:36 server weewx[6536]: restx: CWOP: Posting not enabled.
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.restx.StdCWOP
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.restx.StdWOW
Jan 13 20:51:36 server weewx[6536]: restx: WOW: Posting not enabled.
Jan 13 20:51:36 server weewx[6536]: engine: Finished loading service 
weewx.restx.StdWOW
Jan 13 20:51:36 server weewx[6536]: engine: Loading service 
weewx.restx.StdAWEKAS
Jan 

Re: [weewx-user] Re: rapidfire work on usb conected acurite display and 5-1 sensor?

[Thomas Keffer]

If you're just experimenting, you need not install it at all. Just go into
the directory where you cloned weewx, and run it directly from there,
giving a path to your weewx.conf file. For example,

cd ~/git/weewx
./bin/weewxd /etc/weewx.conf

-tk

On Fri, Jan 13, 2017 at 9:58 AM, wxwatching  wrote:

> Ok, I installed git and cloned a copy of Weewx to my RPi2. Do I install it
> using the setup.py method?
>
> Thanks,
> Anthony
>
> On Friday, January 13, 2017 at 9:00:05 AM UTC-5, mwall wrote:
>
>> On Friday, January 13, 2017 at 8:12:22 AM UTC-5, wxwatching wrote:
>>>
>>> mwall,
>>>
>>> Thanks for the info. I don't suppose there is a date set yet for that
>>> release? If it is still sometime away, I am not adverse to install a
>>> development version, although I have never installed from github and am not
>>> quite sure how to go about that.



>> usually it is pretty safe to use what is on the master branch.  we try to
>> never 'break' the master, but sometimes bugs happen.
>>
>> really disruptive changes happen on a branch so they can be tested
>> first.  for example, there is a lot of activity right now on the
>> 'development' branch.
>>
>> there is not yet a date set for the 3.7 release.  there will probably be
>> a lengthy public testing period before 3.7 is ready to replace 3.6.
>>
>> if you want to run from code directly from master, download the zip file
>> from github (click the green 'clone or download' button and select
>> 'Download ZIP').  unzip it, then install using the setup.py approach.  deb
>> and rpm packages are only available once we get into the last stages of
>> testing a release.
>>
>> if you want to keep updated with the latest changes from master, then use
>> 'git' to clone the repository and to update your copy over time.  details
>> for doing that would take more than a couple of sentences.
>>
>> if you are playing with unstable code (yours or that of someone else), be
>> sure to backup your database, and keep a copy of your working weewx around
>> in case you want to roll back.
>>
>> its pretty easy to switch back and forth from one version of weewx to
>> another, but probably not something you want to do on a production system.
>>
>> 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.
>

-- 
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: rapidfire work on usb conected acurite display and 5-1 sensor?

[Andrew Milner]

That's what Matthew said to do .


On Friday, 13 January 2017 19:58:01 UTC+2, wxwatching wrote:

> Ok, I installed git and cloned a copy of Weewx to my RPi2. Do I install it 
> using the setup.py method?
>
> Thanks,
> Anthony
>
> On Friday, January 13, 2017 at 9:00:05 AM UTC-5, mwall wrote:
>>
>> On Friday, January 13, 2017 at 8:12:22 AM UTC-5, wxwatching wrote:
>>>
>>> mwall,
>>>
>>> Thanks for the info. I don't suppose there is a date set yet for that 
>>> release? If it is still sometime away, I am not adverse to install a 
>>> development version, although I have never installed from github and am not 
>>> quite sure how to go about that.



>> usually it is pretty safe to use what is on the master branch.  we try to 
>> never 'break' the master, but sometimes bugs happen.
>>
>> really disruptive changes happen on a branch so they can be tested 
>> first.  for example, there is a lot of activity right now on the 
>> 'development' branch.
>>
>> there is not yet a date set for the 3.7 release.  there will probably be 
>> a lengthy public testing period before 3.7 is ready to replace 3.6.
>>
>> if you want to run from code directly from master, download the zip file 
>> from github (click the green 'clone or download' button and select 
>> 'Download ZIP').  unzip it, then install using the setup.py approach.  deb 
>> and rpm packages are only available once we get into the last stages of 
>> testing a release.
>>
>> if you want to keep updated with the latest changes from master, then use 
>> 'git' to clone the repository and to update your copy over time.  details 
>> for doing that would take more than a couple of sentences.
>>
>> if you are playing with unstable code (yours or that of someone else), be 
>> sure to backup your database, and keep a copy of your working weewx around 
>> in case you want to roll back.
>>
>> its pretty easy to switch back and forth from one version of weewx to 
>> another, but probably not something you want to do on a production system.
>>
>> 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: WeeWx-WD SS gauges config

[Dan'l B]

With the Saratoga templates in /st, the ss gauges dir is /st/ssg.

> $ssgDir is set to '/ssg/web_server/'
>
$ssgDir = './ssg/web_server/';

 
All the files generated by WeeWx-WD are uploaded to /st
And the path to the ccr file in gauges.js is:

> realTimeUrlWD  : '../../../../customclientraw.txt',
>

gauges-ss-basic.inc and gauges-ss-basic.htm are in the web_server directory.

On Thursday, January 12, 2017 at 11:00:34 PM UTC-5, gjr80 wrote:
>
> No Andrew, 6 is for when you are using SteelSeries with gauge-data.txt, 
> the above question relates to weewx-WD where you are mimicing WD (and using 
> customclientraw.txt).
>
> The issue is almost certainly an issue of incorrect paths. Your saratoga 
> php pages seem to be in the st directory on your web server, where do the 
> SteelSeries files sit in respect to the st directory? You should have a 
> directory that contains gauges-ss-basic-inc.php, gauges-ss-basic.htm etc. 
> What is the name of this directory and where does it sit on the server? In 
> wxssgauges.php what is $ssgDir set to in the following line (circa line 
> 44)
>
> $ssgDir = './ssg/'; // set to relative directory location of the 
> SteelSeries gauge directory
>
> Gary
>
> On Friday, 13 January 2017 13:37:03 UTC+10, Andrew Milner wrote:
>>
>> Shouldn't it be set to 6 for weewx??
>>
>>
>>
>> On Friday, 13 January 2017 05:15:20 UTC+2, Dan'l B wrote:
>>
>>> I seem to be almost there on getting the SS gauges working in the 
>>> Saratoga Templates but not quite:
>>>
>>> http://suiattle.net/DinkinsBayouWeather/st/wxssgauges.php
>>>
>>> Can someone point me to what I am missing here?
>>>
>>> in gauges.js:
>>> Weather Program is set to 1
>>>
  weatherProgram : 1,  //Set 0=Cumulus, 
> 1=Weather Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX

 imgPathURL : ''',//*** Change this to 
> the relative path for your 'Trend' graph images

 oldGauges  : '',  


>>> and the path to the customclientraw.txt is correct:
>>>
 realTimeUrlWD  : '../../../../WD/customclientraw.txt',//*** WD 
 Users: Change to your location of the ccr file *** 
>>>
>>>
>>>  
>>>
>>

-- 
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: Possible calculation error?

[Andrew Milner]

Tom
Mine seems to be correct - data from wh2800 via fineoffsetusb

Showing rows 0 - 19 (20 total, Query took 0.0017 seconds.) [dt: *1484258400 
- 1482616800*]

SELECT archive_day_windSpeed.dateTime as dt, 
date(archive_day_windSpeed.dateTime), archive_day_windSpeed.max, 
archive_day_windGust.max
FROM archive_day_windSpeed
INNER JOIN archive_day_windGust
ON archive_day_windSpeed.dateTime=archive_day_windGust.dateTime order by dt 
desc limit 20

*SELECT* 

 
archive_day_windSpeed.dateTime as dt, *date* 

(archive_day_windSpeed.dateTime), archive_day_windSpeed.max, 
archive_day_windGust.max FROM archive_day_windSpeed INNER JOIN 
archive_day_windGust ON archive_day_windSpeed.dateTime=archive_day_windGust
.dateTime order by dt desc limit 20 
Profiling [ *Inline*  ] [ *Edit* 

 
] [ *Explain SQL* 

 
] [ *Create PHP Code* 

 
] [ *Refresh* 

 
]



Partial texts
Full texts
Relational key
Relational display column
Show binary contents
Show BLOB contents
Show binary contents as HEX
Hide browser transformation
Geometry
Well Known Text
Well Known Binary

*dt [image: Descending] [image: Ascending] **1* 

 
*date(archive_day_windSpeed.dateTime)* 

 
*max* 

 
*max* 

 
1484258400 *NULL* 23.4000581604882  27.0001342166779
1484172000 *NULL* 

Re: [weewx-user] Re: Possible calculation error?

[Andrew Milner]

Tom
Mine seems to be correct:


*+ Options* 
Partial texts
Full texts
Relational key
Relational display column
Show binary contents
Show BLOB contents
Show binary contents as HEX
Hide browser transformation
Geometry
Well Known Text
Well Known Binary
*dt [image: Descending] [image: Ascending] **1* 

 
*date(archive_day_windSpeed.dateTime)* 

 
*max* 

 
*max* 

 
1484258400 *NULL* 23.4000581604882  27.0001342166779
1484172000 *NULL* 29.5200733716927  33.1201646391249
1484085600 *NULL* 19.440048317944  24.480121689788
1483999200 *NULL* 58.6801458486088  68.4003400155841
1483912800 *NULL* 34.2000850037904  42.840212957129
1483826400 *NULL* 34.2000850037904  41.7602075884619
148374 *NULL* 41.7601037941019  51.4802559064659
1483653600 *NULL* 21.9600545813812  25.5601270584551
1483567200 *NULL* 31.6800787403532  37.8001879033491
1483480800 *NULL* 17.2800429492836  20.8801037942309
1483394400 *NULL* 27.671082556  33.1201646391249
1483308000 *NULL* 36.7200912672276  47.8802380109088
1483221600 *NULL* 17.2800429492836  20.8801037942309
1483135200 *NULL* 37.8000939515578  46.440230852686
1483048800 *NULL* 35.6400885828973  43.9202183257961
1482962400 *NULL* 51.4801279530739  70.920352542474
1482876000 *NULL* 36.7200912672276  42.840212957129
1482789600 *NULL* 41.7601037941019  60.1202988558028
1482703200 *NULL* 36.7200912672276  45.3602254840189
1482616800 *NULL* 18.3600456336138  20.8801037942309

hard to see the columns, but they are different.  I have a fineoffset, 
using fousb - but weewx seems to have handled things correctly.  I messed 
up getting the date correct in MySQL though from your sql statement!!!





On Friday, 13 January 2017 16:53:55 UTC+2, Tom Keffer wrote:

> Marked as issue #195 .
>
> -tk
>
> On Fri, Jan 13, 2017 at 6:49 AM, Thomas Keffer  > wrote:
>
>> "dwhile" I have been able to replicate the problem where 
>> archive_day_windSpeed.max is always equal to archive_day_windGust.max. Let 
>> me dig into it deeper.
>>
>> -tk
>>
>> On Fri, Jan 13, 2017 at 6:48 AM, dwhile839 via weewx-user <
>> weewx...@googlegroups.com > wrote:
>>
>>> Ok Added that code and turned debug on. Will monitor to see if it occurs.
>>>
>>> Interestingly the following appears:
>>>
>>> Jan 13 14:46:50 weather weewx[8513]: wmr100: Bad USB report received.
>>> Jan 13 14:46:50 weather weewx[8513]: * could not detach kernel 
>>> driver from interface 0: No data available
>>> Jan 13 14:46:55 weather weewx[8513]: wmr100: Bad USB report received.
>>> Jan 13 14:46:55 weather weewx[8513]: * tuple index out of range
>>> Jan 13 14:47:00 weather weewx[8513]: wmr100: Bad USB report received.
>>> Jan 13 14:47:00 weather weewx[8513]: * tuple index out of range
>>> Jan 13 14:47:05 weather weewx[8513]: wmr100: Bad checksum on buffer of 
>>> length 26
>>> Jan 13 14:47:05 weather weewx[8513]: wmr100: Bad checksum on buffer of 
>>> length 7
>>>
>>> Although everything seems to work OK. Note that the hardware is actually 
>>> a WMR180 not a 100.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from 

[weewx-user] Re: Possible calculation error?

[dwhile839 via weewx-user]

Ok Added that code and turned debug on. Will monitor to see if it occurs.

Interestingly the following appears:

Jan 13 14:46:50 weather weewx[8513]: wmr100: Bad USB report received.
Jan 13 14:46:50 weather weewx[8513]: * could not detach kernel driver 
from interface 0: No data available
Jan 13 14:46:55 weather weewx[8513]: wmr100: Bad USB report received.
Jan 13 14:46:55 weather weewx[8513]: * tuple index out of range
Jan 13 14:47:00 weather weewx[8513]: wmr100: Bad USB report received.
Jan 13 14:47:00 weather weewx[8513]: * tuple index out of range
Jan 13 14:47:05 weather weewx[8513]: wmr100: Bad checksum on buffer of 
length 26
Jan 13 14:47:05 weather weewx[8513]: wmr100: Bad checksum on buffer of 
length 7

Although everything seems to work OK. Note that the hardware is actually a 
WMR180 not a 100.

-- 
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: rapidfire work on usb conected acurite display and 5-1 sensor?

[wxwatching]

Thanks for the info. I will read up on git and install on my RPi2. Having 
programmed in VB, ASP, PHP, and even a little WebDelphi for years, perhaps 
the learning curve won't be too steep.

Anthony

On Friday, January 13, 2017 at 9:00:05 AM UTC-5, mwall wrote:
>
> On Friday, January 13, 2017 at 8:12:22 AM UTC-5, wxwatching wrote:
>>
>> mwall,
>>
>> Thanks for the info. I don't suppose there is a date set yet for that 
>> release? If it is still sometime away, I am not adverse to install a 
>> development version, although I have never installed from github and am not 
>> quite sure how to go about that.
>>>
>>>
>>>
> usually it is pretty safe to use what is on the master branch.  we try to 
> never 'break' the master, but sometimes bugs happen.
>
> really disruptive changes happen on a branch so they can be tested first.  
> for example, there is a lot of activity right now on the 'development' 
> branch.
>
> there is not yet a date set for the 3.7 release.  there will probably be a 
> lengthy public testing period before 3.7 is ready to replace 3.6.
>
> if you want to run from code directly from master, download the zip file 
> from github (click the green 'clone or download' button and select 
> 'Download ZIP').  unzip it, then install using the setup.py approach.  deb 
> and rpm packages are only available once we get into the last stages of 
> testing a release.
>
> if you want to keep updated with the latest changes from master, then use 
> 'git' to clone the repository and to update your copy over time.  details 
> for doing that would take more than a couple of sentences.
>
> if you are playing with unstable code (yours or that of someone else), be 
> sure to backup your database, and keep a copy of your working weewx around 
> in case you want to roll back.
>
> its pretty easy to switch back and forth from one version of weewx to 
> another, but probably not something you want to do on a production system.
>
> m
>

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

Re: [weewx-user] Re: Possible calculation error?

[Thomas Keffer]

"dwhile" I have been able to replicate the problem where
archive_day_windSpeed.max is always equal to archive_day_windGust.max. Let
me dig into it deeper.

-tk

On Fri, Jan 13, 2017 at 6:48 AM, dwhile839 via weewx-user <
weewx-user@googlegroups.com> wrote:

> Ok Added that code and turned debug on. Will monitor to see if it occurs.
>
> Interestingly the following appears:
>
> Jan 13 14:46:50 weather weewx[8513]: wmr100: Bad USB report received.
> Jan 13 14:46:50 weather weewx[8513]: * could not detach kernel driver
> from interface 0: No data available
> Jan 13 14:46:55 weather weewx[8513]: wmr100: Bad USB report received.
> Jan 13 14:46:55 weather weewx[8513]: * tuple index out of range
> Jan 13 14:47:00 weather weewx[8513]: wmr100: Bad USB report received.
> Jan 13 14:47:00 weather weewx[8513]: * tuple index out of range
> Jan 13 14:47:05 weather weewx[8513]: wmr100: Bad checksum on buffer of
> length 26
> Jan 13 14:47:05 weather weewx[8513]: wmr100: Bad checksum on buffer of
> length 7
>
> Although everything seems to work OK. Note that the hardware is actually a
> WMR180 not a 100.
>
> --
> 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: Possible calculation error?

[Andrew Milner]

well my windspeed max and windgust max are different.



On Friday, 13 January 2017 16:26:27 UTC+2, gjr80 wrote:

> Doubt it is a station issue, I have a VP2 and get the same results. I 
> think this is more likely and issue of how the accumualtors work and 
> process the various wind obs.
>
> On Saturday, 14 January 2017 00:21:09 UTC+10, Andrew Milner wrote:
>>
>> That is correct - we are in agreement.  They are different in the 
>> archive, but are both the same value and time in the archive_day tables.  
>> Looks to me as though either the station or the driver could be the source 
>> of the problem and running with debug set may shed some more light.
>>
>>
>> On Friday, 13 January 2017 16:17:12 UTC+2, gjr80 wrote:
>>
>>> No problems Andrew.
>>>
>>> As I see it the issue is (put succinctly):
>>>
>>> why does $day.windSpeed.max == $day.windGust.max ?
>>>
>>> I do not believe they should.
>>>
>>> Gary
>>>
>>

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

[weewx-user] Re: Possible calculation error?

[dwhile839 via weewx-user]

I have been monitoring the loop packets and the data appears to be correct. 
It is providing windGust and windSpeed and these are being correctly 
reported for the archive interval.

I believe Gary has the same results with a different station type so it is 
unlikely to be a station problem.

-- 
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: Possible calculation error?

[Andrew Milner]

That is correct - we are in agreement.  They are different in the archive, 
but are both the same value and time in the archive_day tables.  Looks to 
me as though either the station or the driver could be the source of the 
problem and running with debug set may shed some more light.


On Friday, 13 January 2017 16:17:12 UTC+2, gjr80 wrote:

> No problems Andrew.
>
> As I see it the issue is (put succinctly):
>
> why does $day.windSpeed.max == $day.windGust.max ?
>
> I do not believe they should.
>
> Gary
>

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

[weewx-user] Re: Possible calculation error?

[Andrew Milner]

Gary - my humble apologies indeed

I just saw that there was another page to archive on my phpmyadmin screen - 
which had two more tables - archive_day_windSpeed and 
archive_day__metadata!!!
had never noticed the additional page prompt before!!!

I really am grovelling now and apologising most profusely

substitute archive_day_windSpeed wherever I said archive_day_wind before, 
because I never meant archive_day_wind.





On Friday, 13 January 2017 16:00:06 UTC+2, Andrew Milner wrote:

> Gary - the daily table for windSpeed is called archive_day_wind not 
> archive_day_windSpeed
>
>
>
> On Friday, 13 January 2017 15:52:55 UTC+2, gjr80 wrote:
>
>> Andrew,
>>
>> The issue here is windSpeed and windGust being identical. 
>> $day.windSpeed.max and $day.windGust.max come from archive_day_windSpeed 
>> and archive_day_windGust respectively, archive_day_wind shoudl have nothing 
>> to do with either. At a guess I would say that somehow windGust is 
>> polluting archive_day_windSpeed. How that is happening is the question. The 
>> handling of wind by weewx is complex. I have just spent the last hour 
>> trying to get my head around it and I am still not there. Something I will 
>> ask Tom about.
>>
>> Gary
>>
>> On Friday, 13 January 2017 23:38:12 UTC+10, Andrew Milner wrote:
>>>
>>> Gary - as far as I can see from the results from the queries I asked for 
>>> the issue seems to be resolving why day_archive_wind has the same value AND 
>>> time as day_archive_windGust when in the archive the max for windSpeed and 
>>> windGust are different values.
>>>
>>>
>>> On Friday, 13 January 2017 15:30:36 UTC+2, gjr80 wrote:
>>>
 The SteelSeries Gauges template fields are correct (well the 10 min 
 average actually uses a 1 hour average but that is either here nor there). 

 The fact the maximum windSpeed recorded in the archive is lower than 
 the what you get with $day.windSpeed.max is not surprising. The windSpeed 
 values in your archive are the average of the loop windSpeed values seen 
 over that archive period. So if over the first 5 minute archive period of 
 the day your station saw (loop) windSpeed values of 6,8,8,10,12 the value 
 8.8 (44/5) would be recorded in the archive as windSpeed for that archive 
 period. The daily summaries keep track of the Highs and Lows. So the 
 windSpeed daily summary would record 12 as the max. As subsequent archive 
 periods roll over and loop packets come in additional records are added to 
 the archive (ie windSpeed will contain the average of the loop windSpeed 
 values over the archive period) and the Highs and Lows in the daily 
 summaries will be updated *if a new* High or Low was seen during that 
 archive period. So it is quite possible that the maximum windSpeed value 
 seen in all of the day's archive records is lower than that returned by 
 $day.windSpeed.max ($day.windSpeed.max pulls the max windSpeed value from 
 the daily summaries). In fact for windSpeed i woudl almost guarantee that 
 the max value in the archive will be less than $day.windSpeed.max. The 
 exception is when the daily summaries are rebuilt all of the accumulated 
 detail of highs and lows and their times are lost (ie the detail of the 
 loop data is lost) and the daily summaries are rebuilt frome the (largely) 
 'averaged' archive data.

 The real tell will be a query of both the windSpeed and windGust daily 
 summaries. If you do:

 SELECT * FROM archive_day_windSpeed ORDER BY dateTime DESC LIMIT 1;

 and then 

 SELECT * FROM archive_day_windGust ORDER BY dateTime DESC LIMIT 1;

 I'll bet the values in both of the max columns are the same (the 
 maxtimes will likely be different). That is not right and that is why 
 $day.windSpeed.max and $day.windGust.max are returning the same values. 
 (coincidentally, I get the exact same results on my system with a 
 different 
 station so it is not an issue with the station). How weewx handles wind 
 obs 
 is complex, and whilst the issue has been identified I think a bit more 
 analysis will be required to work any possible fix.

 Gary

>>>

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

[weewx-user] Re: Possible calculation error?

[gjr80]

No problems Andrew.

As I see it the issue is (put succinctly):

why does $day.windSpeed.max == $day.windGust.max ?

I do not believe they should.

Gary

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

[weewx-user] Re: Possible calculation error?

[gjr80]

On Saturday, 14 January 2017 00:00:06 UTC+10, Andrew Milner wrote:
>
> Gary - the daily table for windSpeed is called archive_day_wind not 
> archive_day_windSpeed
>

Um, actually it is called archive_day_windSpeed. archive_day_wind is the 
daily sumamry for the vector wind.

mysql> SELECT * FROM archive_day_windSpeed ORDER BY dateTime DESC LIMIT 1;
++--++--++--+---+--+-+
| dateTime   | min  | mintime| max  | maxtime| sum 
 | count | wsum | sumtime |
++--++--++--+---+--+-+
| 1484229600 |0 | 1484229602 | 20.9215240001292 | 1484274119 | 
975.264888006056 |   288 | 975.264888006056 | 288 |
++--++--++--+---+--+-+
1 row in set (0.00 sec)

mysql> SELECT * FROM archive_day_windGust ORDER BY dateTime DESC LIMIT 1;
++--++--++--+---+--+-+
| dateTime   | min  | mintime| max  | maxtime| sum 
 | count | wsum | sumtime |
++--++--++--+---+--+-+
| 1484229600 |0 | 1484229604 | 20.9215240001292 | 1484274301 | 
2335.16394801449 |   288 | 2335.16394801449 | 288 |
++--++--++--+---+--+-+
1 row in set (0.01 sec)

mysql> show tables;
+--+
| Tables_in_weewx  |
+--+
| archive  |
| archive_day_ET   |
| archive_day_UV   |
| archive_day__metadata|
| archive_day_altimeter|
| archive_day_barometer|
| archive_day_consBatteryVoltage   |
| archive_day_dewpoint |
| archive_day_extraHumid1  |
| archive_day_extraHumid2  |
| archive_day_extraTemp1   |
| archive_day_extraTemp2   |
| archive_day_extraTemp3   |
| archive_day_hail |
| archive_day_hailRate |
| archive_day_heatindex|
| archive_day_heatingTemp  |
| archive_day_heatingVoltage   |
| archive_day_inHumidity   |
| archive_day_inTemp   |
| archive_day_inTempBatteryStatus  |
| archive_day_leafTemp1|
| archive_day_leafTemp2|
| archive_day_leafWet1 |
| archive_day_leafWet2 |
| archive_day_outHumidity  |
| archive_day_outTemp  |
| archive_day_outTempBatteryStatus |
| archive_day_pressure |
| archive_day_radiation|
| archive_day_rain |
| archive_day_rainBatteryStatus|
| archive_day_rainRate |
| archive_day_referenceVoltage |
| archive_day_rxCheckPercent   |
| archive_day_soilMoist1   |
| archive_day_soilMoist2   |
| archive_day_soilMoist3   |
| archive_day_soilMoist4   |
| archive_day_soilTemp1|
| archive_day_soilTemp2|
| archive_day_soilTemp3|
| archive_day_soilTemp4|
| archive_day_supplyVoltage|
| archive_day_txBatteryStatus  |
| archive_day_wind |
| archive_day_windBatteryStatus|
| archive_day_windDir  |
| archive_day_windGust |
| archive_day_windGustDir  |
| archive_day_windSpeed|
| archive_day_windchill|
+--+
52 rows in set (0.00 sec)

mysql>



-- 
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: Possible calculation error?

[Andrew Milner]

Gary - the daily table for windSpeed is called archive_day_wind not 
archive_day_windSpeed



On Friday, 13 January 2017 15:52:55 UTC+2, gjr80 wrote:

> Andrew,
>
> The issue here is windSpeed and windGust being identical. 
> $day.windSpeed.max and $day.windGust.max come from archive_day_windSpeed 
> and archive_day_windGust respectively, archive_day_wind shoudl have nothing 
> to do with either. At a guess I would say that somehow windGust is 
> polluting archive_day_windSpeed. How that is happening is the question. The 
> handling of wind by weewx is complex. I have just spent the last hour 
> trying to get my head around it and I am still not there. Something I will 
> ask Tom about.
>
> Gary
>
> On Friday, 13 January 2017 23:38:12 UTC+10, Andrew Milner wrote:
>>
>> Gary - as far as I can see from the results from the queries I asked for 
>> the issue seems to be resolving why day_archive_wind has the same value AND 
>> time as day_archive_windGust when in the archive the max for windSpeed and 
>> windGust are different values.
>>
>>
>> On Friday, 13 January 2017 15:30:36 UTC+2, gjr80 wrote:
>>
>>> The SteelSeries Gauges template fields are correct (well the 10 min 
>>> average actually uses a 1 hour average but that is either here nor there). 
>>>
>>> The fact the maximum windSpeed recorded in the archive is lower than the 
>>> what you get with $day.windSpeed.max is not surprising. The windSpeed 
>>> values in your archive are the average of the loop windSpeed values seen 
>>> over that archive period. So if over the first 5 minute archive period of 
>>> the day your station saw (loop) windSpeed values of 6,8,8,10,12 the value 
>>> 8.8 (44/5) would be recorded in the archive as windSpeed for that archive 
>>> period. The daily summaries keep track of the Highs and Lows. So the 
>>> windSpeed daily summary would record 12 as the max. As subsequent archive 
>>> periods roll over and loop packets come in additional records are added to 
>>> the archive (ie windSpeed will contain the average of the loop windSpeed 
>>> values over the archive period) and the Highs and Lows in the daily 
>>> summaries will be updated *if a new* High or Low was seen during that 
>>> archive period. So it is quite possible that the maximum windSpeed value 
>>> seen in all of the day's archive records is lower than that returned by 
>>> $day.windSpeed.max ($day.windSpeed.max pulls the max windSpeed value from 
>>> the daily summaries). In fact for windSpeed i woudl almost guarantee that 
>>> the max value in the archive will be less than $day.windSpeed.max. The 
>>> exception is when the daily summaries are rebuilt all of the accumulated 
>>> detail of highs and lows and their times are lost (ie the detail of the 
>>> loop data is lost) and the daily summaries are rebuilt frome the (largely) 
>>> 'averaged' archive data.
>>>
>>> The real tell will be a query of both the windSpeed and windGust daily 
>>> summaries. If you do:
>>>
>>> SELECT * FROM archive_day_windSpeed ORDER BY dateTime DESC LIMIT 1;
>>>
>>> and then 
>>>
>>> SELECT * FROM archive_day_windGust ORDER BY dateTime DESC LIMIT 1;
>>>
>>> I'll bet the values in both of the max columns are the same (the 
>>> maxtimes will likely be different). That is not right and that is why 
>>> $day.windSpeed.max and $day.windGust.max are returning the same values. 
>>> (coincidentally, I get the exact same results on my system with a different 
>>> station so it is not an issue with the station). How weewx handles wind obs 
>>> is complex, and whilst the issue has been identified I think a bit more 
>>> analysis will be required to work any possible fix.
>>>
>>> Gary
>>>
>>

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

[weewx-user] Re: rapidfire work on usb conected acurite display and 5-1 sensor?

[mwall]

On Friday, January 13, 2017 at 8:12:22 AM UTC-5, wxwatching wrote:
>
> mwall,
>
> Thanks for the info. I don't suppose there is a date set yet for that 
> release? If it is still sometime away, I am not adverse to install a 
> development version, although I have never installed from github and am not 
> quite sure how to go about that.
>>
>>
>>
usually it is pretty safe to use what is on the master branch.  we try to 
never 'break' the master, but sometimes bugs happen.

really disruptive changes happen on a branch so they can be tested first.  
for example, there is a lot of activity right now on the 'development' 
branch.

there is not yet a date set for the 3.7 release.  there will probably be a 
lengthy public testing period before 3.7 is ready to replace 3.6.

if you want to run from code directly from master, download the zip file 
from github (click the green 'clone or download' button and select 
'Download ZIP').  unzip it, then install using the setup.py approach.  deb 
and rpm packages are only available once we get into the last stages of 
testing a release.

if you want to keep updated with the latest changes from master, then use 
'git' to clone the repository and to update your copy over time.  details 
for doing that would take more than a couple of sentences.

if you are playing with unstable code (yours or that of someone else), be 
sure to backup your database, and keep a copy of your working weewx around 
in case you want to roll back.

its pretty easy to switch back and forth from one version of weewx to 
another, but probably not something you want to do on a production system.

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: Data from imported db not showing up

[Ξ]

Ah, nice, that was an easy one, thanks a lot! :)

-- 
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: Possible calculation error?

[dwhile839 via weewx-user]

The first - I think Andrew has succinctly stated the problem above:

"Gary - as far as I can see from the results from the queries I asked for 
the issue seems to be resolving why day_archive_wind has the same value AND 
time as day_archive_windGust when in the archive the max for windSpeed and 
windGust are different values."

I believe there is a calculation/programming error somewhere. 

-- 
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: Possible calculation error?

[Andrew Milner]

When you say setting loop_hilo has had no effect - what happened?

You need to restart weewx after changing weewx.conf, and it will only 
affect new values processed after the change, and would only be seen if you 
have a higher average wind in an archive period than the already recorded 
high or did you delete or zeroise todays data already in the daily tables 
to make the new values become visible?


On Friday, 13 January 2017 15:43:44 UTC+2, dwhi...@googlemail.com wrote:

> Just to confirm setting loop_hilo to false has had no effect.
>
> If you want me to try anything please let me know - I was until recently 
> an Associate Professor in Computer Science so programming isn't a problem 
> for me!!
>

-- 
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: Possible calculation error?

[Thomas Keffer]

The documentation for $day.windSpeed.max is wrong. It should read:

The max average wind speed. The wind is averaged over each of
the archive intervals. Then the maximum of these values is taken.

It has been changed in commit 35ad31

.

"dwhile", I am no longer sure what problem we are chasing. Is it:

   - You think there is a problem in the aggregation calculations in weewx;
   or
   - You're having troubles coming up with the right template to display
   those calculations.

I get the feeling you feel it's the first. If so, could you distill down
what you think the error is, without using your templates? It's very hard
to see through the thicket of your templates, with all its novel naming
conventions, and see what you're doing.

-tk


On Fri, Jan 13, 2017 at 5:43 AM, dwhile839 via weewx-user <
weewx-user@googlegroups.com> wrote:

> Just to confirm setting loop_hilo to false has had no effect.
>
> If you want me to try anything please let me know - I was until recently
> an Associate Professor in Computer Science so programming isn't a problem
> for me!!
>
> --
> 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: Possible calculation error?

[dwhile839 via weewx-user]

Just to confirm setting loop_hilo to false has had no effect.

If you want me to try anything please let me know - I was until recently an 
Associate Professor in Computer Science so programming isn't a problem for 
me!!

-- 
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: Possible calculation error?

[Andrew Milner]

Gary - as far as I can see from the results from the queries I asked for 
the issue seems to be resolving why day_archive_wind has the same value AND 
time as day_archive_windGust when in the archive the max for windSpeed and 
windGust are different values.


On Friday, 13 January 2017 15:30:36 UTC+2, gjr80 wrote:

> The SteelSeries Gauges template fields are correct (well the 10 min 
> average actually uses a 1 hour average but that is either here nor there). 
>
> The fact the maximum windSpeed recorded in the archive is lower than the 
> what you get with $day.windSpeed.max is not surprising. The windSpeed 
> values in your archive are the average of the loop windSpeed values seen 
> over that archive period. So if over the first 5 minute archive period of 
> the day your station saw (loop) windSpeed values of 6,8,8,10,12 the value 
> 8.8 (44/5) would be recorded in the archive as windSpeed for that archive 
> period. The daily summaries keep track of the Highs and Lows. So the 
> windSpeed daily summary would record 12 as the max. As subsequent archive 
> periods roll over and loop packets come in additional records are added to 
> the archive (ie windSpeed will contain the average of the loop windSpeed 
> values over the archive period) and the Highs and Lows in the daily 
> summaries will be updated *if a new* High or Low was seen during that 
> archive period. So it is quite possible that the maximum windSpeed value 
> seen in all of the day's archive records is lower than that returned by 
> $day.windSpeed.max ($day.windSpeed.max pulls the max windSpeed value from 
> the daily summaries). In fact for windSpeed i woudl almost guarantee that 
> the max value in the archive will be less than $day.windSpeed.max. The 
> exception is when the daily summaries are rebuilt all of the accumulated 
> detail of highs and lows and their times are lost (ie the detail of the 
> loop data is lost) and the daily summaries are rebuilt frome the (largely) 
> 'averaged' archive data.
>
> The real tell will be a query of both the windSpeed and windGust daily 
> summaries. If you do:
>
> SELECT * FROM archive_day_windSpeed ORDER BY dateTime DESC LIMIT 1;
>
> and then 
>
> SELECT * FROM archive_day_windGust ORDER BY dateTime DESC LIMIT 1;
>
> I'll bet the values in both of the max columns are the same (the maxtimes 
> will likely be different). That is not right and that is why 
> $day.windSpeed.max and $day.windGust.max are returning the same values. 
> (coincidentally, I get the exact same results on my system with a different 
> station so it is not an issue with the station). How weewx handles wind obs 
> is complex, and whilst the issue has been identified I think a bit more 
> analysis will be required to work any possible fix.
>
> Gary
>

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

[weewx-user] Re: Possible calculation error?

[dwhile839 via weewx-user]

Hi you are correct both return the same value and the same dateTime stamp.

-- 
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: Possible calculation error?

[gjr80]

The SteelSeries Gauges template fields are correct (well the 10 min average 
actually uses a 1 hour average but that is either here nor there). 

The fact the maximum windSpeed recorded in the archive is lower than the 
what you get with $day.windSpeed.max is not surprising. The windSpeed 
values in your archive are the average of the loop windSpeed values seen 
over that archive period. So if over the first 5 minute archive period of 
the day your station saw (loop) windSpeed values of 6,8,8,10,12 the value 
8.8 (44/5) would be recorded in the archive as windSpeed for that archive 
period. The daily summaries keep track of the Highs and Lows. So the 
windSpeed daily summary would record 12 as the max. As subsequent archive 
periods roll over and loop packets come in additional records are added to 
the archive (ie windSpeed will contain the average of the loop windSpeed 
values over the archive period) and the Highs and Lows in the daily 
summaries will be updated *if a new* High or Low was seen during that 
archive period. So it is quite possible that the maximum windSpeed value 
seen in all of the day's archive records is lower than that returned by 
$day.windSpeed.max ($day.windSpeed.max pulls the max windSpeed value from 
the daily summaries). In fact for windSpeed i woudl almost guarantee that 
the max value in the archive will be less than $day.windSpeed.max. The 
exception is when the daily summaries are rebuilt all of the accumulated 
detail of highs and lows and their times are lost (ie the detail of the 
loop data is lost) and the daily summaries are rebuilt frome the (largely) 
'averaged' archive data.

The real tell will be a query of both the windSpeed and windGust daily 
summaries. If you do:

SELECT * FROM archive_day_windSpeed ORDER BY dateTime DESC LIMIT 1;

and then 

SELECT * FROM archive_day_windGust ORDER BY dateTime DESC LIMIT 1;

I'll bet the values in both of the max columns are the same (the maxtimes 
will likely be different). That is not right and that is why 
$day.windSpeed.max and $day.windGust.max are returning the same values. 
(coincidentally, I get the exact same results on my system with a different 
station so it is not an issue with the station). How weewx handles wind obs 
is complex, and whilst the issue has been identified I think a bit more 
analysis will be required to work any possible fix.

Gary

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

[weewx-user] Re: Possible calculation error?

[Andrew Milner]

If you set loop_hilo in std archive section of weewx.conf then only the 
archive data will be used for the daily high/low figures.  If loop_hilo is 
set true then both loop and archive data can affect the stats.  It looks as 
though you have it set to true, and the loop data from a gust is managing 
to set the windspeed.  I do not know what kind of station you have got and 
how it is supplying the wind data - maybe you need to run with debug=1 set 
and monitor your wind speed and wind gust readings as supplied by the 
station.



On Friday, 13 January 2017 14:51:38 UTC+2, dwhi...@googlemail.com wrote:

> select max(windSpeed) from archive where dataTime > x; (for 
> today)13.8690394820237
>
> select max(windGust) from archive where dateTime > xx;(for 
> today)   15.4348987783812
>
> select max, maxtime from archive_day_wind where dateTime = xx;
>  (for today)  15.4348987783812 | 1484308500
>
> select max, maxtime from archive_day_windGust where dateTime = 
> x; (for today)  15.4348987783812 | 1484308500
>
> a) miles_per_hour is %.0f
>
> b) I looked in both tables
>
> c) archive interval is 5 minutes
>

-- 
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: Possible calculation error?

[dwhile839 via weewx-user]

select max(windSpeed) from archive where dataTime > x; (for 
today)13.8690394820237

select max(windGust) from archive where dateTime > xx;(for 
today)   15.4348987783812

select max, maxtime from archive_day_wind where dateTime = xx;
 (for today)  15.4348987783812 | 1484308500

select max, maxtime from archive_day_windGust where dateTime = 
x; (for today)  15.4348987783812 | 1484308500

a) miles_per_hour is %.0f

b) I looked in both tables

c) archive interval is 5 minutes

-- 
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: Data from imported db not showing up

[Andrew Milner]

Stop weewx, backup (just in case) and delete ALL your NOAA files, restart 
weewx and the old ones from 2014 together with the later ones will be 
recreated



On Friday, 13 January 2017 14:21:37 UTC+2, Ξ wrote:

> Hello,
>
> I had an separate weewx.sdb with some data from 2014, I imported it in my 
> current weewx.sdb the following way:
> 1. stopped weewx
>
> 2.1. sqlite> .output weewx.sql
> 2.2. sqlite> .dump
> 2.3. sqlite> .read weewx.sql
>
> 3. Just in case (wasn't sure if necessary) I dropped and rebuilt the 
> daily summaries.
>
> When I query the current db I see that the data from 2014 is there:
> sqlite> select * from archive where dateTime >=1413983100 and dateTime <= 
> 1418033700;
>
> 1413983100|17|5|1016.28791671632|1006.6|1017.04448274591|14.5|19.0|62.0|65.0|2.1000168|67.0|3.1000248|67.0||0.0|12.2664431411618|19.0|19.0|
>
> 1413983400|17|5|1016.28791671632|1006.6|1017.04448274591|14.5|19.0|62.0|64.0|0.756|157.0|1.8000144|157.0||0.0|12.0306771978198|19.0|19.0|
>
> 1413983700|17|5|1016.18214153765|1006.5|1016.93974200736|14.5|19.0|62.0|64.0|0.972|247.0|1.296|247.0||0.0|12.0306771978198|19.0|19.0|
>
> 1413984000|17|5|1016.18214153765|1006.5|1016.93974200736|14.6|19.0|62.0|64.0|1.188|202.0|1.8000144|202.0||0.0|12.0306771978198|19.0|19.0|
>
> 1413984300|17|5|1016.07636635897|1006.4|1016.83500117321|14.5|19.0|62.0|64.0|0.864|337.0|1.8000144|337.0||0.0|12.0306771978198|19.0|19.0|
>
> [.]
>
> 1418032800|17|15|1022.65069022701|1010.7037037037|1021.34264997858|8.21|9.05185185185185|69.0|86.7037037037037|0.60740740789|333.939464968401|1.8000144|292.0|0.0|0.0|6.95351969435926|9.03829467906817|9.05185185185185|99.8148148148148|0.0|0.0|0.0|1.0
>
> 1418033700|17|15|1022.41118044111|1010.48|1021.10834967871|8.20|9.06|69.0|86.0|0.46333704|334.922637326266|1.8000144|270.0|0.0|0.0|6.84622281651449|9.047413980332|9.06|100.0|0.0|0.0|0.0|1.0
> sqlite>
>
> However, in the generated reports there's nothing: 
> http://wwx.oe.ftp.sh/NOAA/NOAA-2014-10.txt 
> Same for Nov-2014 and Dec-2014.
>
> I'm running weewx3.6.2, on Arch Linux, R-Pi.
>
> Have I done something terribly wrong? Am I missing something obvious?! How 
> do I make the data show up?
>
>

-- 
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] Data from imported db not showing up

[Ξ]

Hello,

I had an separate weewx.sdb with some data from 2014, I imported it in my 
current weewx.sdb the following way:
1. stopped weewx

2.1. sqlite> .output weewx.sql
2.2. sqlite> .dump
2.3. sqlite> .read weewx.sql

3. Just in case (wasn't sure if necessary) I dropped and rebuilt the daily 
summaries.

When I query the current db I see that the data from 2014 is there:
sqlite> select * from archive where dateTime >=1413983100 and dateTime <= 
1418033700;
1413983100|17|5|1016.28791671632|1006.6|1017.04448274591|14.5|19.0|62.0|65.0|2.1000168|67.0|3.1000248|67.0||0.0|12.2664431411618|19.0|19.0|
1413983400|17|5|1016.28791671632|1006.6|1017.04448274591|14.5|19.0|62.0|64.0|0.756|157.0|1.8000144|157.0||0.0|12.0306771978198|19.0|19.0|
1413983700|17|5|1016.18214153765|1006.5|1016.93974200736|14.5|19.0|62.0|64.0|0.972|247.0|1.296|247.0||0.0|12.0306771978198|19.0|19.0|
1413984000|17|5|1016.18214153765|1006.5|1016.93974200736|14.6|19.0|62.0|64.0|1.188|202.0|1.8000144|202.0||0.0|12.0306771978198|19.0|19.0|
1413984300|17|5|1016.07636635897|1006.4|1016.83500117321|14.5|19.0|62.0|64.0|0.864|337.0|1.8000144|337.0||0.0|12.0306771978198|19.0|19.0|

[.]
1418032800|17|15|1022.65069022701|1010.7037037037|1021.34264997858|8.21|9.05185185185185|69.0|86.7037037037037|0.60740740789|333.939464968401|1.8000144|292.0|0.0|0.0|6.95351969435926|9.03829467906817|9.05185185185185|99.8148148148148|0.0|0.0|0.0|1.0
1418033700|17|15|1022.41118044111|1010.48|1021.10834967871|8.20|9.06|69.0|86.0|0.46333704|334.922637326266|1.8000144|270.0|0.0|0.0|6.84622281651449|9.047413980332|9.06|100.0|0.0|0.0|0.0|1.0
sqlite>

However, in the generated reports there's nothing: 
http://wwx.oe.ftp.sh/NOAA/NOAA-2014-10.txt 
Same for Nov-2014 and Dec-2014.

I'm running weewx3.6.2, on Arch Linux, R-Pi.

Have I done something terribly wrong? Am I missing something obvious?! How 
do I make the data show up?

-- 
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: Possible calculation error?

[Andrew Milner]

a) What formatting is specified in skin.conf - for use by .formatted? 

b) when you say "as recorded in the database" - are you referring to the 
archive table or the archive_day_windspeed table?

c) what is your archive interval?

d) what is the result of the following sql commands:
select max(windSpeed) from archive where dataTime > x; (for 
today)
and
select max(windGust) from archive where dateTime > xx;(for 
today)
and
select max, maxtime from archive_day_wind where dateTime = xx;
 (for today)
and
select max, maxtime from archive_day_windGust where dateTime = 
x; (for today)


On Friday, 13 January 2017 13:25:44 UTC+2, dwhi...@googlemail.com wrote:

> Ok Assuming that weewx does rounding in the normal way (anything below .5 
> rounded down and .5 and above rounded up) then there is definitely a 
> calculation error. 
>
> I have looked at the source data in the database and for today the maximum 
> wind speed recorded (up to now) is 13.421656358 (as recorded in the 
> database). This is correctly shown in the text above the graph as a maximum 
> gust of 13mph. The maximum average speed over an interval for today 
> is 12.3031801856662 which when rounded should be 12mph but is showing 
> (using $day.windSpeed.max) as 13mph.
>

-- 
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: Possible calculation error?

[dwhile839 via weewx-user]

Ok Assuming that weewx does rounding in the normal way (anything below .5 
rounded down and .5 and above rounded up) then there is definitely a 
calculation error. 

I have looked at the source data in the database and for today the maximum 
wind speed recorded (up to now) is 13.421656358 (as recorded in the 
database). This is correctly shown in the text above the graph as a maximum 
gust of 13mph. The maximum average speed over an interval for today 
is 12.3031801856662 which when rounded should be 12mph but is showing 
(using $day.windSpeed.max) as 13mph.

-- 
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: Possible calculation error?

[dwhile839 via weewx-user]

Here is the relevant bit from the template (the template is large!)

"wlatest":"$current.windSpeed.formatted",
   "lastestmax": "$current.windSpeed.max.formatted",
"wspeed":"$hour.windSpeed.avg.formatted",
  "test":"$hour.windSpeed.max.formatted",
"dayavg": "$day.windSpeed.avg.formatted",
"windTM":"$day.windSpeed.max.formatted",
 "wgust":"$current.windGust.formatted",
   "wgustTM":"$day.windGust.max.formatted",
  "TwgustTM":"$day.windGust.maxtime",

I have added a few others in to do some testing e.g. test, latestmax, dayavg

-- 
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: Possible calculation error?

[dwhile839 via weewx-user]

I wouldn't expect the lines to be the same as that is not the problem. The 
gust figure will normally be higher than the average.

The problem lies with $day.windSpeed.max - this is a single figure so not 
plotted on the graph. The docs say that this is calculated by averaging the 
windspeed over the interval and then averaging all the intervals. This is 
wrong. It should be averaging over the interval and then selecting the 
highest figure (hence max). 

I don't know whether the error is in the documentation or in the coding but 
the value produced is wrong. It appears that the value produced is always 
the same as the maximum gust speed ($day.windGust.max)


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