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

[peterquinn925]

The StdCalibrate code didn't work but didn't throw any error messages. I 
thought about implementing a service but thought about the advice to better 
locate the thermometer. I can't find a better place to put it, but I did 
make a sun shield out of a scrap piece of aluminum that seems to be 
helping. 

On Thursday, March 28, 2019 at 4:56:14 PM UTC-7, peterq...@gmail.com wrote:
>
> 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

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

[gjr80]

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 thermometer, rain gauge and anemometer in a 
> single 
> unit. In order to get the rain gauge and anemometer to give useful 
> readings, I mounted it on the roof where it's away from all the trees. 
> It's 
> the best location for wind and rain, but it sucks for the temperature 
> much 
> of the time. I have a white roof and the temp up there is often 10degF 
> warmer than ambient.
>
> To get around that, I built my own wifi thermometer and put it in a 
> much better location. Details of the build here 
> 
> . 
>
> The new thermometer gives more accurate readings almost all the time. 

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

[peterquinn925]

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 thermometer, rain gauge and anemometer in a 
 single 
 unit. In order to get the rain gauge and anemometer to give useful 
 readings, I mounted it on the roof where it's away from all the trees. 
 It's 
 the best location for wind and rain, but it sucks for the temperature much 
 of the time. I have a white roof and the temp up there is often 10degF 
 warmer than ambient.

 To get around that, I built my own wifi thermometer and put it in a 
 much better location. Details of the build here 
 
 . 

 The new thermometer gives more accurate readings almost all the time. 
 However, a few minutes in the late afternoon, I get direct sunshine on it 
 and the temp spikes. It can spike by 20 degrees sometimes and is screwing 
 with my long term high temp data. It's worst this time of year, before the 
 oak trees leaf out and block the afternoon sun.

 I'm recording the Accurite data in extraTemp1 and my thermometer in 
 outTemp. I want to write some code to put the extraTemp1 value in outTemp 
 if outTemp is more than 6 degF higher than extraTemp1. Ideally I'd only do 
 this between 5-7pm local time, but doing it all the time would be ok. The 
 problem I'm having is finding a good place to do the comparison. The 
 service that reads outTemp doesn't have the extraTemp1 value. The code 
 that 
 reads the Accurite data and stuffs it into 

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

[gjr80]

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 thermometer, rain gauge and anemometer in a single 
>>> unit. In order to get the rain gauge and anemometer to give useful 
>>> readings, I mounted it on the roof where it's away from all the trees. It's 
>>> the best location for wind and rain, but it sucks for the temperature much 
>>> of the time. I have a white roof and the temp up there is often 10degF 
>>> warmer than ambient.
>>>
>>> To get around that, I built my own wifi thermometer and put it in a much 
>>> better location. Details of the build here 
>>> 
>>> . 
>>>
>>> The new thermometer gives more accurate readings almost all the time. 
>>> However, a few minutes in the late afternoon, I get direct sunshine on it 
>>> and the temp spikes. It can spike by 20 degrees sometimes and is screwing 
>>> with my long term high temp data. It's worst this time of year, before the 
>>> oak trees leaf out and block the afternoon sun.
>>>
>>> I'm recording the Accurite data in extraTemp1 and my thermometer in 
>>> outTemp. I want to write some code to put the extraTemp1 value in outTemp 
>>> if outTemp is more than 6 degF higher than extraTemp1. Ideally I'd only do 
>>> this between 5-7pm local time, but doing it all the time would be ok. The 
>>> problem I'm having is finding a good place to do the comparison. The 
>>> service that reads outTemp doesn't have the extraTemp1 value. The code that 
>>> reads the Accurite data and stuffs it into extraTemp1 doesn't have the 
>>> outTemp data. Does anyone have a suggestion on where to do this comparison?
>>>
>>> I've tried fixing it up after the fact with a SQL query. It works, but 
>>> I'd like to do it in real time rather than go back and fix the data later.
>>>
>>

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

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 thermometer, rain gauge and anemometer in a single 
>> unit. In order to get the rain gauge and anemometer to give useful 
>> readings, I mounted it on the roof where it's away from all the trees. It's 
>> the best location for wind and rain, but it sucks for the temperature much 
>> of the time. I have a white roof and the temp up there is often 10degF 
>> warmer than ambient.
>>
>> To get around that, I built my own wifi thermometer and put it in a much 
>> better location. Details of the build here 
>> 
>> . 
>>
>> The new thermometer gives more accurate readings almost all the time. 
>> However, a few minutes in the late afternoon, I get direct sunshine on it 
>> and the temp spikes. It can spike by 20 degrees sometimes and is screwing 
>> with my long term high temp data. It's worst this time of year, before the 
>> oak trees leaf out and block the afternoon sun.
>>
>> I'm recording the Accurite data in extraTemp1 and my thermometer in 
>> outTemp. I want to write some code to put the extraTemp1 value in outTemp 
>> if outTemp is more than 6 degF higher than extraTemp1. Ideally I'd only do 
>> this between 5-7pm local time, but doing it all the time would be ok. The 
>> problem I'm having is finding a good place to do the comparison. The 
>> service that reads outTemp doesn't have the extraTemp1 value. The code that 
>> reads the Accurite data and stuffs it into extraTemp1 doesn't have the 
>> outTemp data. Does anyone have a suggestion on where to do this comparison?
>>
>> I've tried fixing it up after the fact with a SQL query. It works, but 
>> I'd like to do it in real time rather than go back and fix the data later.
>>
>

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

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 thermometer, rain gauge and anemometer in a single 
> unit. In order to get the rain gauge and anemometer to give useful 
> readings, I mounted it on the roof where it's away from all the trees. It's 
> the best location for wind and rain, but it sucks for the temperature much 
> of the time. I have a white roof and the temp up there is often 10degF 
> warmer than ambient.
>
> To get around that, I built my own wifi thermometer and put it in a much 
> better location. Details of the build here 
> 
> . 
>
> The new thermometer gives more accurate readings almost all the time. 
> However, a few minutes in the late afternoon, I get direct sunshine on it 
> and the temp spikes. It can spike by 20 degrees sometimes and is screwing 
> with my long term high temp data. It's worst this time of year, before the 
> oak trees leaf out and block the afternoon sun.
>
> I'm recording the Accurite data in extraTemp1 and my thermometer in 
> outTemp. I want to write some code to put the extraTemp1 value in outTemp 
> if outTemp is more than 6 degF higher than extraTemp1. Ideally I'd only do 
> this between 5-7pm local time, but doing it all the time would be ok. The 
> problem I'm having is finding a good place to do the comparison. The 
> service that reads outTemp doesn't have the extraTemp1 value. The code that 
> reads the Accurite data and stuffs it into extraTemp1 doesn't have the 
> outTemp data. Does anyone have a suggestion on where to do this comparison?
>
> I've tried fixing it up after the fact with a SQL query. It works, but I'd 
> like to do it in real time rather than go back and fix the data later.
>

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