Re: [weewx-user] Re: Belchertown Skin and CWOP Pressure Difference

[gjr80]

Hi.

Make sure you are comparing apples with apples and not oranges. The CWOP 
uploader uploads WeeWX field altimeter in mbar (WeeWX does the 
conversion/rounding to mbar not CWOP). The PWS uploader uploads WeeWX field 
barometer. I can't access the WeatherCloud uploader at the moment but I am 
suspecting it will be uploading barometer as well. I haven't looked at 
Belchertown but I am guessing it will likely be barometer. What any of 
these external services do with the 'pressure' value that is uploaded is 
anyone's guess so even the fact you are uploading different values is no 
guarantee of what they display.

If you want to see what is being uploaded to CWOP and PWS set debug=2 in 
weewx.conf then restart WeeWX, you should the data being uploaded in the 
log. Can't speak for WeatherCloud but debug=2 may well cause it's data to 
be logged as well.

Gary

On Friday, 29 March 2019 12:33:09 UTC+10, Chris Plant wrote:
>
> Well I’ll be. It appears CWOP is the only one that’s different. The 
> Belchertown skin amount is the same as PwsWeather and Weathercloud. So it 
> must be something with how CWOP calculates it as you mentioned. Well thanks 
> for helping me with this at least. 

-- 
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: Belchertown Skin and CWOP Pressure Difference

[kutzenco]

I see that you upload to several other services (PWS, WU and Weathercloud). 
Are they getting the same barometer values as CWOP? 

I would also look at the weewx.sdb database with sqlite3 to see what the 
actual archived value is at a particular time (like 8pm tonight) and 
compare it to the values on the Belchertown skin and on the various 
external services you've uploaded to.

Is there some offset you've applied to the barometric pressure on your 
Accurite?

For what it is worth, my upload to CWOP gives a barometric pressure reading 
within .01 inHg of what my Belchertown skin shows (https://wx.kutzenco.com). 
I attribute the difference to conversion. I think CWOP stores data as 
millibar and the findU display converts that to inHg (I may be wrong). 

phil

-- 
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] weewx-purpleair

[vince]

On Sunday, March 24, 2019 at 6:30:39 PM UTC-7, parallelsys wrote:
>
> Got it all working.
>

Me too !

Got my purpleair today.  The extension was a snap to install.
Hardest part was reading the code to see what 'hostname' meant for 
weewx.conf

Cool code incidentally - love the querying the unit directly for its data.
Great stuff.
 

-- 
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: Dual thermometers - how can I programmatically choose the right one

[peterquinn925]

Thanks to everyone for their help. I'm going to leave it in StdCalibrate 
for a day or two. I'm curious to see if it works. I'll most likely follow 
your advice and do it in a service. 


On Thursday, March 28, 2019 at 4:29:34 PM UTC-7, Thomas Keffer wrote:
>
> If you really want to do this, you would be better off writing a simple 
> WeeWX service, rather than trying to squeeze it into StdCalibrate. It's 
> really pretty simple. Something like this (NOT TESTED):
>
> *File user/temperature_fix.py:*
>
> import datetime
> import weewx
> from weewx.engine import StdService
>
> def fix_temp(record):
> hour = 
> int(datetime.datetime.utcfromtimestamp(record['dateTime']).strftime("%H"))
> if record['outTemp'] > record['extraTemp1] + 4 and 16 < hour < 20:
> record['outTemp'] = record['extraTemp1']
>
> class FixMyTemperature(StdService):
> """Service that switches between temperature sensors"""
> 
> def __init__(self, engine, config_dict):
> super(FixMyTemperature, self).__init__(engine, config_dict)
>
> self.bind(weewx.NEW_LOOP_PACKET, self.new_loop_packet)
> self.bind(weewx.NEW_ARCHIVE_RECORD, self.new_archive_record)
> 
> def new_loop_packet(self, event):
> fix_temp(event.packet)
> 
> def new_archive_record(self, event):
> fix_temp(event.record)
>
> Add this new service to the end of the process_services:
> process_services = weewx.engine.StdConvert, 
> weewx.engine.StdCalibrate, weewx.engine.StdQC, 
> weewx.wxservices.StdWXCalculate, user.temperature_fix.FixMyTemperature
>
>
> But, do you really want to do this? There is no substitute for a properly 
> calibrated and sited instrument. 
>
> -tk
>
>
> On Thu, Mar 28, 2019 at 4:09 PM p q > 
> wrote:
>
>> What do you mean in-line python in a template? Do you mean change the 
>> skin to do the calculation when displaying the data? I'm mostly concerned 
>> about having erroneous high temps in my historical data.
>>
>> I agree it's getting complex, but I don't see a better way short of 
>> moving my thermometer to a new enclosure.
>>
>> On Thu, Mar 28, 2019 at 4:03 PM gjr80 > 
>> wrote:
>>
>>> On Friday, 29 March 2019 08:56:27 UTC+10, peterq...@gmail.com wrote:

 Ok. I made multiple errors and the try/catch was swallowing them. I 
 still don't know if I found and fixed them all, but I think I did.

 Mistake #1
 I need to add datetime import into the engine python code


>>> Just remember if you make a change to engine.py then you are opening 
>>> yourself up to having your changes overwritten when upgrading. You can 
>>> always pickup the date-time requirements with a couple of lines of in-line 
>>> python in a template. Also remmeber the zen 
>>> :
>>>
>>> Simple is better than complex.
>>> Complex is better than complicated.
>>>
>>>
>>> I'm guessing your are bordering on the complicated
>>>
>>> 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...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Peter Quinn
>> (415)794-2264
>>
>> -- 
>> 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...@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] Re: Dual thermometers - how can I programmatically choose the right one

[gjr80]

On Friday, 29 March 2019 09:09:17 UTC+10, p q wrote:
>
> What do you mean in-line python in a template? Do you mean change the skin 
> to do the calculation when displaying the data? I'm mostly concerned about 
> having erroneous high temps in my historical data.
>

In a WeeWX template (.tmpl file) you will tend to see a lot of literal text 
and WeeWX tags. After being processed by the Cheetah templating engine a 
file is produced from each template where the literal text remains and the 
WeeWX tags are substituted with the applicable statistical data, for 
example something like:

The temperature is: $current.outTemp

might result in:

The temperature is: 23.4CEnter code here

You can actually embed python code in-line in the template and Cheetah will 
execute the code, so something like (untested):

#import datetime
#if int(datetime.utcfromtimestamp($current.dateTime.raw).strftime('%H')) >16
#set $temp = $current.outTemp
#else
#set $temp = $current.extraTemp1
The temperature is: $temp

would display the string 'The temperature is: ' but display $current.outTemp 
from midnight to 5pm and $current.extraTemp1 from 5pm to midnight.

In-line code uses most of the python vocabulary but things like indenting 
are not required, each line starts with a # and 'variables' start with a $. 
Its handy for fine tuning what is displayed in the report. No reason you 
couldn't touch the database but I would say it is almost always easier to 
do that elsewhere.

If you have a hard and fast requirement to create a composite field in your 
database then in-line template code is not the way to go. If you are 
getting to the stage where you need to modify the core WeeWX code then 
maybe you should consider writing a custom service to do what you want. The 
beauty of a custom service is that it survives across upgrades, the 
downside is its a bit more work but in your case I would expect it could 
easily be done in 15-20 lines of code. Or of course you live with having to 
patch the core code after an upgrade.

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.

Re: [weewx-user] Re: Dual thermometers - how can I programmatically choose the right one

[gjr80]

Hah, 17 lines of code, right in the target zone!

Gary

On Friday, 29 March 2019 09:29:34 UTC+10, Thomas Keffer wrote:
>
> If you really want to do this, you would be better off writing a simple 
> WeeWX service, rather than trying to squeeze it into StdCalibrate. It's 
> really pretty simple. Something like this (NOT TESTED):
>
> *File user/temperature_fix.py:*
>
> import datetime
> import weewx
> from weewx.engine import StdService
>
> def fix_temp(record):
> hour = 
> int(datetime.datetime.utcfromtimestamp(record['dateTime']).strftime("%H"))
> if record['outTemp'] > record['extraTemp1] + 4 and 16 < hour < 20:
> record['outTemp'] = record['extraTemp1']
>
> class FixMyTemperature(StdService):
> """Service that switches between temperature sensors"""
> 
> def __init__(self, engine, config_dict):
> super(FixMyTemperature, self).__init__(engine, config_dict)
>
> self.bind(weewx.NEW_LOOP_PACKET, self.new_loop_packet)
> self.bind(weewx.NEW_ARCHIVE_RECORD, self.new_archive_record)
> 
> def new_loop_packet(self, event):
> fix_temp(event.packet)
> 
> def new_archive_record(self, event):
> fix_temp(event.record)
>
> Add this new service to the end of the process_services:
> process_services = weewx.engine.StdConvert, 
> weewx.engine.StdCalibrate, weewx.engine.StdQC, 
> weewx.wxservices.StdWXCalculate, user.temperature_fix.FixMyTemperature
>
>
> But, do you really want to do this? There is no substitute for a properly 
> calibrated and sited instrument. 
>
> -tk
>
>
> On Thu, Mar 28, 2019 at 4:09 PM p q > 
> wrote:
>
>> What do you mean in-line python in a template? Do you mean change the 
>> skin to do the calculation when displaying the data? I'm mostly concerned 
>> about having erroneous high temps in my historical data.
>>
>> I agree it's getting complex, but I don't see a better way short of 
>> moving my thermometer to a new enclosure.
>>
>> On Thu, Mar 28, 2019 at 4:03 PM gjr80 > 
>> wrote:
>>
>>> On Friday, 29 March 2019 08:56:27 UTC+10, peterq...@gmail.com wrote:

 Ok. I made multiple errors and the try/catch was swallowing them. I 
 still don't know if I found and fixed them all, but I think I did.

 Mistake #1
 I need to add datetime import into the engine python code


>>> Just remember if you make a change to engine.py then you are opening 
>>> yourself up to having your changes overwritten when upgrading. You can 
>>> always pickup the date-time requirements with a couple of lines of in-line 
>>> python in a template. Also remmeber the zen 
>>> :
>>>
>>> Simple is better than complex.
>>> Complex is better than complicated.
>>>
>>>
>>> I'm guessing your are bordering on the complicated
>>>
>>> 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...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Peter Quinn
>> (415)794-2264
>>
>> -- 
>> 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...@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] Re: Dual thermometers - how can I programmatically choose the right one

[Thomas Keffer]

If you really want to do this, you would be better off writing a simple
WeeWX service, rather than trying to squeeze it into StdCalibrate. It's
really pretty simple. Something like this (NOT TESTED):

*File user/temperature_fix.py:*

import datetime
import weewx
from weewx.engine import StdService

def fix_temp(record):
hour =
int(datetime.datetime.utcfromtimestamp(record['dateTime']).strftime("%H"))
if record['outTemp'] > record['extraTemp1] + 4 and 16 < hour < 20:
record['outTemp'] = record['extraTemp1']

class FixMyTemperature(StdService):
"""Service that switches between temperature sensors"""

def __init__(self, engine, config_dict):
super(FixMyTemperature, self).__init__(engine, config_dict)

self.bind(weewx.NEW_LOOP_PACKET, self.new_loop_packet)
self.bind(weewx.NEW_ARCHIVE_RECORD, self.new_archive_record)

def new_loop_packet(self, event):
fix_temp(event.packet)

def new_archive_record(self, event):
fix_temp(event.record)

Add this new service to the end of the process_services:
process_services = weewx.engine.StdConvert,
weewx.engine.StdCalibrate, weewx.engine.StdQC,
weewx.wxservices.StdWXCalculate, user.temperature_fix.FixMyTemperature


But, do you really want to do this? There is no substitute for a properly
calibrated and sited instrument.

-tk


On Thu, Mar 28, 2019 at 4:09 PM p q  wrote:

> What do you mean in-line python in a template? Do you mean change the skin
> to do the calculation when displaying the data? I'm mostly concerned about
> having erroneous high temps in my historical data.
>
> I agree it's getting complex, but I don't see a better way short of moving
> my thermometer to a new enclosure.
>
> On Thu, Mar 28, 2019 at 4:03 PM gjr80  wrote:
>
>> On Friday, 29 March 2019 08:56:27 UTC+10, peterq...@gmail.com wrote:
>>>
>>> Ok. I made multiple errors and the try/catch was swallowing them. I
>>> still don't know if I found and fixed them all, but I think I did.
>>>
>>> Mistake #1
>>> I need to add datetime import into the engine python code
>>>
>>>
>> Just remember if you make a change to engine.py then you are opening
>> yourself up to having your changes overwritten when upgrading. You can
>> always pickup the date-time requirements with a couple of lines of in-line
>> python in a template. Also remmeber the zen
>> :
>>
>> Simple is better than complex.
>> Complex is better than complicated.
>>
>>
>> I'm guessing your are bordering on the complicated
>>
>> 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.
>>
>
>
> --
> Peter Quinn
> (415)794-2264
>
> --
> 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] Re: Dual thermometers - how can I programmatically choose the right one

[p q]

What do you mean in-line python in a template? Do you mean change the skin
to do the calculation when displaying the data? I'm mostly concerned about
having erroneous high temps in my historical data.

I agree it's getting complex, but I don't see a better way short of moving
my thermometer to a new enclosure.

On Thu, Mar 28, 2019 at 4:03 PM gjr80  wrote:

> On Friday, 29 March 2019 08:56:27 UTC+10, peterq...@gmail.com wrote:
>>
>> Ok. I made multiple errors and the try/catch was swallowing them. I still
>> don't know if I found and fixed them all, but I think I did.
>>
>> Mistake #1
>> I need to add datetime import into the engine python code
>>
>>
> Just remember if you make a change to engine.py then you are opening
> yourself up to having your changes overwritten when upgrading. You can
> always pickup the date-time requirements with a couple of lines of in-line
> python in a template. Also remmeber the zen
> :
>
> Simple is better than complex.
> Complex is better than complicated.
>
>
> I'm guessing your are bordering on the complicated
>
> 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.
>


-- 
Peter Quinn
(415)794-2264

-- 
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: Dual thermometers - how can I programmatically choose the right one

[gjr80]

On Friday, 29 March 2019 08:56:27 UTC+10, peterq...@gmail.com wrote:
>
> Ok. I made multiple errors and the try/catch was swallowing them. I still 
> don't know if I found and fixed them all, but I think I did.
>
> Mistake #1
> I need to add datetime import into the engine python code
>
>
Just remember if you make a change to engine.py then you are opening 
yourself up to having your changes overwritten when upgrading. You can 
always pickup the date-time requirements with a couple of lines of in-line 
python in a template. Also remmeber the zen 
:

Simple is better than complex.
Complex is better than complicated.


I'm guessing your are bordering on the complicated

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: Dual thermometers - how can I programmatically choose the right one

[peterquinn925]

Ok. I made multiple errors and the try/catch was swallowing them. I still 
don't know if I found and fixed them all, but I think I did.

Mistake #1
I need to add datetime import into the engine python code

Mistake #2
Double quotes inside an eval statement cause syntax errors because they are 
themselves inside double quotes. Use single quotes instead. This was a 
problem when testing, it might not be a problem when reading from a file.

Mistake #3
It's not , dummy! it's %H

I still don't know if it's actually working. We'll see soon.

On Wednesday, March 27, 2019 at 9:25:19 PM UTC-7, gjr80 wrote:
>
> Hmm, that is getting complex. Just be careful, you have introduced a 
> dependency on python module datetime and looking at the WeeWX module 
> weewx.engine (that contains the StdCalibrate code) it does not import 
> datetime. The line that performs the evaluation for StdCalibrate is 
> wrapped in a try..except but I believe it will raise and error so you 
> will know if datetime is an issue. I could be wrong and it is possible the 
> import error could come up and be swallowed and you would not be aware. 
> Best bet would be to pay particular attention to the corner cases to make 
> sure your expression performs as expected.
>
> Gary
>
> On Thursday, 28 March 2019 12:04:43 UTC+10, peterq...@gmail.com wrote:
>>
>> Well, It seems to work, meaning that I don't get any syntax errors. I'll 
>> have to wait until tomorrow afternoon if it's sunny to see for sure. I 
>> tried to put in a time specific fix -
>>
>> outTemp = extraTemp1 if outTemp>(extraTemp1 + 4) and 
>> datetime.utcfromtimestamp(dateTime).strftime("")>16 and 
>> datetime.utcfromtimestamp(dateTime).strftime("")<20 else outTemp
>>
>> There's a pretty good chance I've screwed up the logic but at least the 
>> syntax works in stdCalibrate
>>
>> Thanks for your help/
>>
>> On Wednesday, March 27, 2019 at 6:25:33 PM UTC-7, gjr80 wrote:
>>>
>>> Meant to link the relevant section 
>>>  from the Users Guide 
>>>  but forgot. It does not say it 
>>> in so many words but you can anything that can 'evaluated' in a single 
>>> line. Most folks tend to think of simple formulae involving one or more 
>>> variables but the single line version of the python if..then..else 
>>> statement lets you bring in conditional evaluation as well.
>>>
>>> If you are interested in the python behind [StdCalibrate] then anything 
>>> that you can do in the python eval() 
>>>  function can be 
>>> used. The available variables are observation field names in the loop 
>>> packet or archive record being processed, eg: outTemp, outHumidity, rain 
>>> etc
>>>
>>> Gary
>>>
>>> On Thursday, 28 March 2019 11:15:28 UTC+10, peterq...@gmail.com wrote:

 That's exactly what I was looking for.

 I want to set outTemp, but otherwise exactly what I need. I didn't know 
 that I could put an if statement there. Can I use other python code there 
 to be able to look up the time? Is this in the documentation someplace?

 I'll try it out now.

 On Wednesday, March 27, 2019 at 6:03:35 PM UTC-7, gjr80 wrote:
>
> Hi,
>
> You could put an entry in [StdCalibrate] in weewx.conf to set outTemp 
> or extraTemp1 to whatever you want. Something like:
>
> [StdCalibrate]
> [[Corrections]]
> extraTemp1 = extraTemp1 if outTemp > extraTemp1 + 6 else 
> outTemp
>
> or you could flip the equation around and change outTemp. Another 
> approach would be to put your composite temperature in another field such 
> as extraTemp2:
>
> [StdCalibrate]
> [[Corrections]]
> extraTemp2 = extraTemp1 if outTemp > extraTemp1 + 6 else 
> outTemp
>
> The 2nd approach will preserve you outTemp or extraTemp1 data and 
> should see extraTemp2 saved to the database. 
>
> Note that the above is untested and the '6' assumes you are using US 
> customary units in your database - if not then 6 needs to be converted to 
> C.
>
> Also, depending on your requirements you could achieve a similar 
> result with some in line python code in your template. This would work 
> fine 
> for displaying current data but will not give you the aggregates that you 
> get from having the composite data in the database. You could easily work 
> in your time based requirements as well (pseudo code  - if 17 < hour < 19 
> display extraTemp1 else display outTemp). You could even use a 
> combination 
> of [StdCalibrate] and some python inline code to get the best of both 
> worlds.
>
> Gary
>
> On Thursday, 28 March 2019 10:28:29 UTC+10, peterq...@gmail.com wrote:
>>
>> Hi,
>>
>> I have been using Weewx v3.5.0 for a few years now. I have an 
>> Accurite weather station with the 

[weewx-user] Realtime gauge data extension

[gjr80]

The Realtime Gauge Data extension 
 provides a loop based 
gauge-data.txt that can be used to drive the SteelSeries Weather Gauges. 
With the demise of the old WU API I have updated the Realtime Gauge Data 
extension to work with the new WU API. Further, as free keys to the new API 
are limited to WU uploaders I have also added Dark Sky support. Thanks very 
much to Tom R in helping debug the latest version.

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] noaa dropdown not populated

[Ferran Vidal Marginet]

Hello,

After installing the forecast extension noaa dropdown is not being 
populated. I know the files for each month and year are correcly generated 
what the values in the dropdown don't.

I'm not seeing any clue in the log file. Somebody knows how can I debug 
this? I've seen that there are some dedicated posts here in this forum but 
I haven't seen the solution.

I'm adding you my configuration files.

I'm using the 3.3.2 version of the forecast extension and the latest 
version of weewx, 3.9.1

Thanks!
Ferran

-- 
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 CONFIGURATION FILE
#
# Copyright (c) 2009-2019 Tom Keffer 
# See the file LICENSE.txt for your rights.

##

# This section is for general configuration information.

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

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

# Whether to log successful operations
log_success = True

# Whether to log unsuccessful operations
log_failure = True

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

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

##

#   This section is for information about the station.

[Station]

# Description of the station location
location = Estació meteorològica del barri del Congres i els indians(beta)

# Latitude and longitude in decimal degrees
latitude = 41.426
longitude = 2.179

# Altitude of the station, with unit it is in. This is downloaded from
# from the station if the hardware supports it.
altitude = 41, meter

# Set to type of station hardware. There must be a corresponding stanza
# in this file with a 'driver' parameter indicating the driver to be used.
station_type = netatmo

# If you have a website, you may specify an URL
#station_url = http://www.example.com

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from the station if the hardware supports it.
rain_year_start = 1

# Start of week (0=Monday, 6=Sunday)
week_start = 0

##

[netatmo]
username = 
client_secret = 
password = 
driver = user.netatmo
client_id = 
mode = cloud


##

#   This section is for uploading data to Internet sites

[StdRESTful]

[[StationRegistry]]
# To register this weather station with weewx, set this to true
register_this_station = false

[[AWEKAS]]
# This section is for configuring posts to AWEKAS.

# If you wish to do this, set the option 'enable' to true,
# and specify a username and password.
# To guard against parsing errors, put the password in quotes.
enable = false
username = replace_me
password = replace_me

[[CWOP]]
# This section is for configuring posts to CWOP.

# If you wish to do this, set the option 'enable' to true,
# and specify the station ID (e.g., CW1234).
enable = false
station = replace_me

# If this is an APRS (radio amateur) station, uncomment
# the following and replace with a passcode (e.g., 12345).
#passcode = replace_me (APRS stations only)

[[PWSweather]]
# This section is for configuring posts to PWSweather.com.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

[[WOW]]
# This section is for configuring posts to WOW.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

[[Wunderground]]
# This section is for configuring posts to the Weather Underground.

# If you wish to do this, set the option 'enable' to true,
# and specify a station (e.g., 'KORHOODR3') and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

# Set the following to 

Re: [weewx-user] Re: Belchertown Skin and CWOP Pressure Difference

[Chris Plant]

Hmmm.  Ok. I’ll have to try it with the MQTT off and see if they are the
same or different.

On Thu, Mar 28, 2019 at 4:42 PM  wrote:

> So the Belchertown skin is showing the MQTT return, which is the latest
> LOOP value. I could be wrong, but I suspect the Standard skin, and the
> upload to CWOP are values from the last archive value stored in weewx.sdb.
>
> phil
>
> On Thursday, March 28, 2019 at 5:12:51 PM UTC-4, Chris Plant wrote:
>>
>> Hello,
>>
>> [image: belchertownbarometer.JPG]
>>
>> [image: cwopbarometer.JPG]
>> Just wondering if someone could clue me in as to why the Belchertown skin
>> is showing my barometer .03 more inHg than the data thats being uploaded to
>> CWOP and other providers. When i change my skin to the "Standard", they
>> then match.  Is it something in the programming or are they values not
>> really the same thing?
>>
>> Chris
>> https://www.knowltonweather.com
>>
>>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/ghJterBw32A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Chris Plant
Sent from Gmail Mobile

-- 
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: Belchertown Skin and CWOP Pressure Difference

[kutzenco]

So the Belchertown skin is showing the MQTT return, which is the latest 
LOOP value. I could be wrong, but I suspect the Standard skin, and the 
upload to CWOP are values from the last archive value stored in weewx.sdb.

phil

On Thursday, March 28, 2019 at 5:12:51 PM UTC-4, Chris Plant wrote:
>
> Hello, 
>
> [image: belchertownbarometer.JPG]
>
> [image: cwopbarometer.JPG]
> Just wondering if someone could clue me in as to why the Belchertown skin 
> is showing my barometer .03 more inHg than the data thats being uploaded to 
> CWOP and other providers. When i change my skin to the "Standard", they 
> then match.  Is it something in the programming or are they values not 
> really the same thing?
>
> Chris
> https://www.knowltonweather.com
>
>
>
>

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

[weewx-user] Belchertown Skin and CWOP Pressure Difference

[Chris Plant]

Hello, 

[image: belchertownbarometer.JPG]

[image: cwopbarometer.JPG]
Just wondering if someone could clue me in as to why the Belchertown skin 
is showing my barometer .03 more inHg than the data thats being uploaded to 
CWOP and other providers. When i change my skin to the "Standard", they 
then match.  Is it something in the programming or are they values not 
really the same thing?

Chris
https://www.knowltonweather.com



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

Re: [weewx-user] Re: how to round values before archive

[Thomas Keffer]

Sorry. I don't know. It works for me.

-tk

On Thu, Mar 28, 2019 at 12:24 PM Martin  wrote:

> Good evening, Thomas.
> Thank you for the answer. I'am quite a newbie at sqlite (and python), so I
> didn't know, that my idea doesn't save space.
> But I still wonder, why round(inTemp) and int(inTemp) do work, but
> round(inTemp,3) doesn't.
>
> Have a nice weekend,
> Martin
>
> --
> 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: how to round values before archive

[Martin]

Good evening, Thomas.
Thank you for the answer. I'am quite a newbie at sqlite (and python), so I 
didn't know, that my idea doesn't save space.
But I still wonder, why round(inTemp) and int(inTemp) do work, but 
round(inTemp,3) doesn't.

Have a nice weekend,
Martin

-- 
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] how to round values before archive

[Thomas Keffer]

What makes you think this will save any space? Truncated or not, sqlite
always stores a float as an 8-byte IEEE number.

Also, good data practice requires not messing with primary data. It will
bite you somewhere down the road.

-tkd


On Thu, Mar 28, 2019 at 8:15 AM Martin  wrote:

> Hi there!
>
> My archive database is target_unit = METRICWX and it contains a lot of
> values with too much decimals.
> For example: inTemp = 14.4086206896552
> To save space, I only need one decimal, so that weewx.sdb contains the
> number 14.4 for inTemp.
> In weewx.conf I tried:
> [StdCalibrate]
> [[Corrections]]
> inTemp = round(inTemp,1)
>
> but then I get the error message:
> File "/usr/share/weewx/weewx/engine.py", line 365, in __init__
>   'StdCalibrate', 'eval')
>   TypeError: expected a readable buffer object
>   Exiting.
>
> I have found out, that for example
> inTemp = round(inTemp)   and
> inTemp = int(inTemp)
> in weewx.conf work correct! But then I have no digit after the coma.
>
> So, any ideas?
>
> Springfeelings from Austra,
> Martin
>
> --
> 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] how to round values before archive

[Martin]

Hi there!

My archive database is target_unit = METRICWX and it contains a lot of 
values with too much decimals.
For example: inTemp = 14.4086206896552
To save space, I only need one decimal, so that weewx.sdb contains the 
number 14.4 for inTemp.
In weewx.conf I tried:
[StdCalibrate]
[[Corrections]]
inTemp = round(inTemp,1)

but then I get the error message:
File "/usr/share/weewx/weewx/engine.py", line 365, in __init__
  'StdCalibrate', 'eval')
  TypeError: expected a readable buffer object
  Exiting.

I have found out, that for example
inTemp = round(inTemp)   and
inTemp = int(inTemp)
in weewx.conf work correct! But then I have no digit after the coma.

So, any ideas?

Springfeelings from Austra,
Martin

-- 
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: sftp

[WindnFog]

UPDATE:

I had to modify the weewx-sftp extension a bit to use a keyed login instead 
of a password.  It meant, in sftp.py, changing all references of passwordto 
private_key, changing the hard-wired port number from  to  (my new 
provider uses ), and changing the entry 'password' in the config file 
to:

private_key = /home//.ssh/id_rsa

Unrelated, and probably due to my implementation of Python, I got an error 
related to GSS_EXCEPTIONS.  I Googled the error and found others (non-weewx 
related software) were getting the same error.  They recommended 
uninstalling python-gssapi and I did so.  Now everything works fine.

- Paul VE1DX

On Tuesday, March 26, 2019 at 5:17:58 PM UTC-3, WindnFog wrote:
>
> Hi guys,
>
> I am pondering switiching providers and hosting my web page on another 
> server that doesn't support SSH, just sftp.  I am currently transferring 
> the contents of /home/weewx/public_html/ to it as a test using sftp in a 
> cron job that runs 1 minute after the standart weewx upload.  I notice the 
> documentation says weewx suppots FTPS (which I'm using with my current 
> provider), add then goes on to say "*not* to be confused with SFTP, which 
> uses a Secure Socket Shell protocol."  
>
> I don't think I can convince the potential new host to allow me to do it 
> via FTPS.  They seem fairly rigid about sftp only.  Does weewx support 
> sftp, and if not, are there any plans to implement it?  If the answer is 
> no, I'll stay with my current provider and use FTPS.
>
> - Paul VE1DX
>

-- 
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: Crash with log info

[AsgeirK]

I have a similar issue since I upgraded to the latest version:

Mar 27 18:07:48 PI-W4 weewx[507]: wmr200: MainThread: W Exiting with 
packets still in live queue cnt:2
Mar 27 18:07:48 PI-W4 weewx[507]: wmr200: MainThread: I Driver gracefully 
exiting
Mar 27 18:07:48 PI-W4 weewx[507]: engine: Caught unrecoverable exception in 
engine:
Mar 27 18:07:48 PI-W4 weewx[507]:   Non-positive value for record 
field 'interval': 0
Mar 27 18:07:48 PI-W4 weewx[507]:   Traceback (most recent call 
last):
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/engine.py", line 890, in main
Mar 27 18:07:48 PI-W4 weewx[507]:   engine.run()
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/engine.py", line 160, in run
Mar 27 18:07:48 PI-W4 weewx[507]:   
self.dispatchEvent(weewx.Event(weewx.STARTUP))
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
Mar 27 18:07:48 PI-W4 weewx[507]:   callback(event)
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/engine.py", line 520, in startup
Mar 27 18:07:48 PI-W4 weewx[507]:   
self._catchup(self.engine.console.genStartupRecords)
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/engine.py", line 635, in _catchup
Mar 27 18:07:48 PI-W4 weewx[507]:   origin='hardware'))
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
Mar 27 18:07:48 PI-W4 weewx[507]:   callback(event)
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/engine.py", line 601, in new_archive_record
Mar 27 18:07:48 PI-W4 weewx[507]:   
dbmanager.addRecord(event.record, accumulator=self.old_accumulator)
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/manager.py", line 246, in addRecord
Mar 27 18:07:48 PI-W4 weewx[507]:   
self._addSingleRecord(record, cursor, log_level)
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/manager.py", line 1212, in _addSingleRecord
Mar 27 18:07:48 PI-W4 weewx[507]:   _weight = 
self._calc_weight(record)
Mar 27 18:07:48 PI-W4 weewx[507]: File 
"/usr/share/weewx/weewx/manager.py", line 1582, in _calc_weight
Mar 27 18:07:48 PI-W4 weewx[507]:   raise 
ValueError("Non-positive value for record field 'interval': %s" % 
(record['interval'], ))
Mar 27 18:07:48 PI-W4 weewx[507]:   ValueError: Non-positive value 
for record field 'interval': 0
Mar 27 18:07:48 PI-W4 weewx[507]:   Exiting.
Mar 27 18:08:45 PI-W4 systemd[1]: Started Session c427 of user pi.
Mar 27 18:09:45 PI-W4 systemd[1]: Started Session c428 of user pi.

 

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