Re: [weewx-user] Re: Skins

[Pat]

What kind of skin are you looking for? 

For what it's worth, I'm working on porting my site 
 to a skin. It has a couple years of 
custom code I've created that I need to port over to weewx skins. Hope to 
have it in a beta form soon. 

On Wednesday, August 8, 2018 at 3:04:27 AM UTC-4, Bengt Carlsson wrote:
>
> Yes, but cant find any similar.
>
> Bengt C
>
>  
>
> *Från:* weewx...@googlegroups.com   > *För *Andrew Milner
> *Skickat:* den 8 augusti 2018 08:44
> *Till:* weewx-user >
> *Ämne:* [weewx-user] Re: Skins
>
>  
>
> Have you looked in the wiki??
>
>  
>
>  
>
>
> On Wednesday, 8 August 2018 09:05:19 UTC+3, John Clark wrote:
>
> Is there a "repository" of various "Standard" skins that may be 
> downloaded? Or a "how-to" manual? So far, understanding "skin theory" has 
> been problematic. I have seen a few I love, but have no idea on how to 
> reproduce them. Need to "get my foot in the door" so to speak.
>
> -- 
> *John Clark*
>
> -- 
> 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.

[weewx-user] Re: Skins

[Greg from Oz]

I love mine:
https://weather.ubeaut.work/


On Wednesday, 8 August 2018 16:05:19 UTC+10, John Clark wrote:
>
> Is there a "repository" of various "Standard" skins that may be 
> downloaded? Or a "how-to" manual? So far, understanding "skin theory" has 
> been problematic. I have seen a few I love, but have no idea on how to 
> reproduce them. Need to "get my foot in the door" so to speak.
> -- 
> *John Clark *
>

-- 
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: High Wind Direction always shows as N/A

[gjr80]

Yes, thought that as I hit send about 1am :) I guess I need to have a look at 
the exact mechanism of the 'issue' but on first thoughts, given this is 
software record generation, I would have expected it to fall outside that 
issue. Now given Bernard's station failure we may never know.

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: High Wind Direction always shows as N/A

[Thomas Keffer]

Gary,

It's possible this problem is related to the windDir problem (Issue #336
).

-tk

On Fri, Aug 10, 2018 at 8:00 AM gjr80  wrote:

> Bernhard,
>
> Could I get you to try the attached accum.py, I have put a couple of
> lines of code in there so we can see what wind direction is going into the
> accumulators and what is being extracted at the end of the archive period.
> What I would like you to do is to use this accum.py and run WeeWX directly
> for a couple of archive periods capturing both the console output and the
> log. To use:
>
> 1. Rename the existing bin/weewx/accum.py:
>
> $ mv /home/weewx/bin/weewx/accum.py /home/weewx/bin/weewx/accum_orig.py
>
> 2. Download the attached accum.py and save in /home/weewx/bin/weewx
>
> 3. Edit weewx.conf and set debug=1
>
> 4. Stop WeeWx if it was running and run WeeWX directly
>  and let it run
> for at least two archive periods, preferably when there is some wind around
> so that we get wind speed and direction
>
> 5. Capture the console output and take a log extract from when you ran
> WeeWX directly. Post both here.
>
> 6. You can revert to the original accum.py by deleting accum.py and then
> renaming the backup copy we made:
>
> $ rm /home/weewx/bin/weewx/accum.py
> $ mv /home/weewx/bin/weewx/accum_orig.py /home/weewx/bin/weewx/accum.py
>
> Gary
>
> On Wednesday, 8 August 2018 05:54:43 UTC+10, bernhard.fr...@gmail.com
> wrote:
>>
>> Hi Gary,
>>
>> No need for a hurry! Many thanks in advance for your continued support!
>>
>> Best regards
>>
>> Bernhard
>>
>> --
> 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: High Wind Direction always shows as N/A

[bernhard . friess . privat]

Hi Gary,

Many thanks for the effort you puting in this issue!

Unfortunately my station's outdoor sender died during yesterday's 
thunderstorm and since then the station didn't report anymore wind 
direction. I changed the batteries in the sender and now it's reporting 
again except the wind direction. Even on the base unit it doesn't show any 
wind direction. 

Tomorrow I plan to unmount the wind direction sensor from the top of my 
pole and see what's going on there. It might take a while until the station 
is up and running again and until I can do the testing. Sorry!

Best regards

Bernhard


Am Freitag, 10. August 2018 17:00:33 UTC+2 schrieb gjr80:
>
> Bernhard,
>
> Could I get you to try the attached accum.py, I have put a couple of 
> lines of code in there so we can see what wind direction is going into the 
> accumulators and what is being extracted at the end of the archive period. 
> What I would like you to do is to use this accum.py and run WeeWX directly 
> for a couple of archive periods capturing both the console output and the 
> log. To use:
>
> 1. Rename the existing bin/weewx/accum.py:
>
> $ mv /home/weewx/bin/weewx/accum.py /home/weewx/bin/weewx/accum_orig.py
>
> 2. Download the attached accum.py and save in /home/weewx/bin/weewx
>
> 3. Edit weewx.conf and set debug=1
>
> 4. Stop WeeWx if it was running and run WeeWX directly 
>  and let it run 
> for at least two archive periods, preferably when there is some wind around 
> so that we get wind speed and direction
>
> 5. Capture the console output and take a log extract from when you ran 
> WeeWX directly. Post both here.
>
> 6. You can revert to the original accum.py by deleting accum.py and then 
> renaming the backup copy we made:
>
> $ rm /home/weewx/bin/weewx/accum.py
> $ mv /home/weewx/bin/weewx/accum_orig.py /home/weewx/bin/weewx/accum.py
>
> Gary
>
> On Wednesday, 8 August 2018 05:54:43 UTC+10, bernhard.fr...@gmail.com 
> wrote:
>>
>> Hi Gary,
>>
>> No need for a hurry! Many thanks in advance for your continued support!
>>
>> Best regards 
>>
>> Bernhard 
>>
>>

-- 
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: Is there a port switching USB hub currently available.

['Rich Altmaier' via weewx-user]

A completely different approach, when you get tired of the Raspberry Pi 
locking up, is to e-waste it and go with the Intel NUC.   I've measured my 
NUC at 10x the speed of the Pi, and it is rock solid.   Just saying...
Rich



On Saturday, July 19, 2014 at 6:15:43 AM UTC-7, Robin wrote:
>
> The weewx wiki article
>
> What to do when your Fine Offset station locks up
> says
>
> Hubs that are known to work:
>
> LINKSYS USB2HUB4 (NEC Corp. HighSpeed Hub)
> D-Link Corp. DUB-H7 7-port USB 2.0 hub [grey]
>
>
> However neither of these hubs seem to be currently available.
>
> Can anybody suggest a suitable hub that is currently in production or do 
> you have any suggestions or further ideas?
>

-- 
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: Oregon Scientific and SDR issue

[Andy]

[SDR]
# This section is for the software-defined radio driver.

# The driver to use
driver = user.sdr

log_unknown_sensors = True
log_unmapped_sensors = True   

Uncomment log_unknown_sensors and log_unmapped_sensors in weewx.conf
Try the attached version 0.45 of the SDR driver.
Restart weewx
Post some more syslog after weewx has run long enough to see data from 
those sensors.

Andy

-- 
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
# Copyright 2016-2017 Matthew Wall
# Distributed under the terms of the GNU Public License (GPLv3)
"""
Collect data from stl-sdr.  Run rtl_433 on a thread and push the output onto
a queue.

The SDR detects many different sensors and sensor types, so this driver
includes a mechanism to filter the incoming data, and to map the filtered
data onto the weewx database schema and identify the type of data from each
sensor.

Sensors are filtered based on a tuple that identifies uniquely each sensor.
A tuple consists of the observation name, a unique identifier for the hardware,
and the packet type, separated by periods:

  ..

The filter and data types are specified in a sensor_map stanza in the driver
stanza.  For example:

[SDR]
driver = user.sdr
[[sensor_map]]
inTemp = temperature.25A6.AcuriteTowerPacket
outTemp = temperature.24A4.AcuriteTowerPacket
rain_total = rain_total.A52B.Acurite5n1Packet

If no sensor_map is specified, no data will be collected.

The deltas stanza indicates which observations are cumulative measures and
how they should be split into delta measures.

[SDR]
...
[[deltas]]
rain = rain_total

In this case, the value for rain will be a delta calculated from sequential
rain_total observations.

To identify sensors, run the driver directly.  Alternatively, use the options
log_unknown_sensors and log_unmapped_sensors to see data from the SDR that are
not yet recognized by your configuration.

[SDR]
driver = user.sdr
log_unknown_sensors = True
log_unmapped_sensors = True

The default for each of these is False.

Eventually we would prefer to have all rtl_433 output as json.  Unfortunately,
many of the rtl_433 decoders do not emit this format yet (as of January 2017).
So this driver is designed to look for json first, then fall back to single-
or multi-line plain text format.

WARNING: Handling of units and unit systems in rtl_433 is a mess, but it is
getting better.  Although there is an option to request SI units, there is no
indicate in the decoder output whether that option is respected, nor does
rtl_433 specify exactly which SI units are used for various types of measure.
There seems to be a pattern of appending a unit label to the observation name
in the JSON data, for example 'wind_speed_mph' instead of just 'wind_speed'.
"""

from __future__ import with_statement
from calendar import timegm
import Queue
import fnmatch
import os
import re
import subprocess
import syslog
import threading
import time

try:
import cjson as json
setattr(json, 'dumps', json.encode)
setattr(json, 'loads', json.decode)
except (ImportError, AttributeError):
try:
import simplejson as json
except ImportError:
import json

import weewx.drivers
from weeutil.weeutil import tobool


DRIVER_NAME = 'SDR'
DRIVER_VERSION = '0.44'

# The default command requests json output from every decoder
# -q - suppress non-data messages
# -U - print timestamps in UTC
# -F json - emit data in json format (not all rtl_433 decoders support this)
# -G - emit data for all rtl decoder (only available in newer rtl_433)
# Use the -R option instead of -G to indicate specific decoders.
DEFAULT_CMD = 'rtl_433 -q -U -F json -G'


def loader(config_dict, _):
return SDRDriver(**config_dict[DRIVER_NAME])

def confeditor_loader():
return SDRConfigurationEditor()


def logmsg(level, msg):
syslog.syslog(level, 'sdr: %s: %s' %
  (threading.currentThread().getName(), 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 AsyncReader(threading.Thread):

def __init__(self, fd, queue, label):
threading.Thread.__init__(self)
self._fd = fd
self._queue = queue
self._running = False
self.setDaemon(True)
self.setName(label)

def run(self):
logdbg("start async reader for %s" % self.getName())
self._running = True
for line in iter(self._fd.readline, ''):
self._queue.put(line)
if not self._running:
break

def stop_running(self):
self._running = False


class ProcManager():
TS = 

[weewx-user] Re: All-time and delta rain.max not correct

[Phil Owers]

On Friday, August 10, 2018 at 5:33:47 PM UTC+1, Phil Owers wrote:
>
>
>
> On Friday, August 10, 2018 at 5:08:13 PM UTC+1, Phil Owers wrote:
>>
>>
>>
>> On Friday, August 10, 2018 at 4:26:32 PM UTC+1, Phil Owers wrote:
>>>
>>>
>>>
>>> On Friday, August 10, 2018 at 3:19:57 PM UTC+1, gjr80 wrote:

 In the daily summaries the 'max' field stores the max value of the obs 
 for the day (the row of the daily summary table) concerned. So for point 
 in 
 time obs like temperature, humidity etc $year.outTemp.max will indeed 
 give the max outTemp value seen since 1 January of the current year 
 and $year.outTemp.maxtime will give the date-time it occurred. The 
 same tag will certainly work with rain, ie $year.rain.max but what 
 that tag is returning is not the max daily rainfall in the year to date 
 but 
 rather the max rainfall seen in an archive period in the year to date, you 
 are treating rainfall more as a point in time observation. The 
 $year.rain.sum tag will give you the total rainfall in the year to date so 
 it does not help (it sums the daily summaries sum field). If you are 
 looking for the max daily rainfall in the year you want to look at the max 
 of the sum fields and to find the max value of the sum field you use the 
 .maxsum aggregation type in your tag ie $year.rain.maxsum. Date-time 
 wise $year.rain.maxtime may well provide the correct date-time that 
 the highest daily rainfall occurred (chances are high that the highest 
 archive period rainfall occurred on the day of highest total rainfall) but 
 the corresponding 'time' aggregate for .maxsum is .maxsumtime ie 
 $year.rain.maxsumtime.

 This may make a bit more sense if you refer to the Aggregation types 
  appendix in 
 the Customization Guide.

 Assuming you are using the alltime period provided by the xstats 
 example search list extension, the $alltime portion of the tag simply 
 allows the underlying query to use the entire daily summary table rather 
 than just the current year, month etc so $alltime.rain.maxsum and 
 $alltime.rain.maxsumtime should give you the results you are after.

 Gary

>>>
>>> Have  just compared the 2018 NOOA reports from weewx and weatherview. 
>> Now 99% was imported to weewx but the Temp and Wind are spot on with each 
>> other but the rain totals are about 25% lower in weewx compared 
>> to weatherview. for all 7 completed months, not sure why yet ???
>>
>  

> And thanks for your help so far.
>>
>  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.

[weewx-user] Re: All-time and delta rain.max not correct

[Phil Owers]

On Friday, August 10, 2018 at 5:08:13 PM UTC+1, Phil Owers wrote:
>
>
>
> On Friday, August 10, 2018 at 4:26:32 PM UTC+1, Phil Owers wrote:
>>
>>
>>
>> On Friday, August 10, 2018 at 3:19:57 PM UTC+1, gjr80 wrote:
>>>
>>> In the daily summaries the 'max' field stores the max value of the obs 
>>> for the day (the row of the daily summary table) concerned. So for point in 
>>> time obs like temperature, humidity etc $year.outTemp.max will indeed 
>>> give the max outTemp value seen since 1 January of the current year and 
>>> $year.outTemp.maxtime will give the date-time it occurred. The same tag 
>>> will certainly work with rain, ie $year.rain.max but what that tag is 
>>> returning is not the max daily rainfall in the year to date but rather the 
>>> max rainfall seen in an archive period in the year to date, you are 
>>> treating rainfall more as a point in time observation. The $year.rain.sum 
>>> tag will give you the total rainfall in the year to date so it does not 
>>> help (it sums the daily summaries sum field). If you are looking for the 
>>> max daily rainfall in the year you want to look at the max of the sum 
>>> fields and to find the max value of the sum field you use the .maxsum 
>>> aggregation type in your tag ie $year.rain.maxsum. Date-time wise 
>>> $year.rain.maxtime may well provide the correct date-time that the 
>>> highest daily rainfall occurred (chances are high that the highest archive 
>>> period rainfall occurred on the day of highest total rainfall) but the 
>>> corresponding 'time' aggregate for .maxsum is .maxsumtime ie 
>>> $year.rain.maxsumtime.
>>>
>>> This may make a bit more sense if you refer to the Aggregation types 
>>>  appendix in 
>>> the Customization Guide.
>>>
>>> Assuming you are using the alltime period provided by the xstats example 
>>> search list extension, the $alltime portion of the tag simply allows 
>>> the underlying query to use the entire daily summary table rather than just 
>>> the current year, month etc so $alltime.rain.maxsum and 
>>> $alltime.rain.maxsumtime should give you the results you are after.
>>>
>>> Gary
>>>
>>
>> Have checked my weewx.sdb and ALL rain records have a lot of decimal 
>> places, not just the historical records but live records to
>> As an example 0.2mm looks always to be 0.00787405
>> 0.4mm = 0.015748031 
>> Is this expected 
>> Phil
>>
> Have also just compared the 2018 NOOA reports from weewx and weatherview. 
> Now 99% was imported to weewx but the Temp and Wind are spot on with each 
> other but the rain totals are about 25% lower in weewx compared 
> to weatherview. for all 7 completed months. Just thought I would mention it.
> And thanks for your help so far.
> Just worked out your conversion for above, but not sure yet why the rain 
> should always be about 25% lower
>
 

-- 
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: All-time and delta rain.max not correct

[Phil Owers]

On Friday, August 10, 2018 at 4:26:32 PM UTC+1, Phil Owers wrote:
>
>
>
> On Friday, August 10, 2018 at 3:19:57 PM UTC+1, gjr80 wrote:
>>
>> In the daily summaries the 'max' field stores the max value of the obs 
>> for the day (the row of the daily summary table) concerned. So for point in 
>> time obs like temperature, humidity etc $year.outTemp.max will indeed 
>> give the max outTemp value seen since 1 January of the current year and 
>> $year.outTemp.maxtime will give the date-time it occurred. The same tag 
>> will certainly work with rain, ie $year.rain.max but what that tag is 
>> returning is not the max daily rainfall in the year to date but rather the 
>> max rainfall seen in an archive period in the year to date, you are 
>> treating rainfall more as a point in time observation. The $year.rain.sum 
>> tag will give you the total rainfall in the year to date so it does not 
>> help (it sums the daily summaries sum field). If you are looking for the 
>> max daily rainfall in the year you want to look at the max of the sum 
>> fields and to find the max value of the sum field you use the .maxsum 
>> aggregation type in your tag ie $year.rain.maxsum. Date-time wise 
>> $year.rain.maxtime may well provide the correct date-time that the 
>> highest daily rainfall occurred (chances are high that the highest archive 
>> period rainfall occurred on the day of highest total rainfall) but the 
>> corresponding 'time' aggregate for .maxsum is .maxsumtime ie 
>> $year.rain.maxsumtime.
>>
>> This may make a bit more sense if you refer to the Aggregation types 
>>  appendix in 
>> the Customization Guide.
>>
>> Assuming you are using the alltime period provided by the xstats example 
>> search list extension, the $alltime portion of the tag simply allows the 
>> underlying query to use the entire daily summary table rather than just the 
>> current year, month etc so $alltime.rain.maxsum and 
>> $alltime.rain.maxsumtime should give you the results you are after.
>>
>> Gary
>>
>
> Have checked my weewx.sdb and ALL rain records have a lot of decimal 
> places, not just the historical records but live records to
> As an example 0.2mm looks always to be 0.00787405
> 0.4mm = 0.015748031 
> Is this expected 
> Phil
>
Have also just compared the 2018 NOOA reports from weewx and weatherview. 
Now 99% was imported to weewx but the Temp and Wind are spot on with each 
other but the rain totals are about 25% lower in weewx compared 
to weatherview. for all 7 completed months. Just thought I would mention it.
And thanks for your help so far.
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.

[weewx-user] Re: Degrees measurement in exact figures

[Antonis Katsonis]

If you fix it, will it work with version 3.4.0 that I have?

Installed with setup.py

-- 
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: Watches and Warnings NWS text only?

[James Greiner]

Thanks guys... You've given me some items to try...

Jim

On Fri, Aug 10, 2018, 11:27 AM Pat  wrote:

> My WU key is still working too, but sounds like they're going to shut it
> down in the future. I transferred all my forecast data to DarkSky API, but
> they don't have the watches, warnings and advisories. The here.com site
> does and I saw Aeris does too. Haven't tried either one yet. I'll have to
> add that onto the Python project pile :)
>
>
> On Thursday, August 9, 2018 at 6:08:11 PM UTC-4, Andy wrote:
>>
>> My WU free key is still working but would like to move away from WU. I
>> just got a free key at Aeris
>> , but have not tried it.
>> I don't think it expires. Alerts are documented here
>>  and
>> Aeris is tied to PWS
>> 
>>
>> --
> 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/BMjY9qrauMM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[weewx-user] Re: Watches and Warnings NWS text only?

[Pat]

My WU key is still working too, but sounds like they're going to shut it 
down in the future. I transferred all my forecast data to DarkSky API, but 
they don't have the watches, warnings and advisories. The here.com site 
does and I saw Aeris does too. Haven't tried either one yet. I'll have to 
add that onto the Python project pile :)


On Thursday, August 9, 2018 at 6:08:11 PM UTC-4, Andy wrote:
>
> My WU free key is still working but would like to move away from WU. I 
> just got a free key at Aeris 
> , but have not tried it. 
> I don't think it expires. Alerts are documented here 
>  and 
> Aeris is tied to PWS 
> 
>
>

-- 
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: All-time and delta rain.max not correct

[Phil Owers]

On Friday, August 10, 2018 at 3:19:57 PM UTC+1, gjr80 wrote:
>
> In the daily summaries the 'max' field stores the max value of the obs for 
> the day (the row of the daily summary table) concerned. So for point in 
> time obs like temperature, humidity etc $year.outTemp.max will indeed 
> give the max outTemp value seen since 1 January of the current year and 
> $year.outTemp.maxtime will give the date-time it occurred. The same tag 
> will certainly work with rain, ie $year.rain.max but what that tag is 
> returning is not the max daily rainfall in the year to date but rather the 
> max rainfall seen in an archive period in the year to date, you are 
> treating rainfall more as a point in time observation. The $year.rain.sum 
> tag will give you the total rainfall in the year to date so it does not 
> help (it sums the daily summaries sum field). If you are looking for the 
> max daily rainfall in the year you want to look at the max of the sum 
> fields and to find the max value of the sum field you use the .maxsum 
> aggregation type in your tag ie $year.rain.maxsum. Date-time wise 
> $year.rain.maxtime may well provide the correct date-time that the 
> highest daily rainfall occurred (chances are high that the highest archive 
> period rainfall occurred on the day of highest total rainfall) but the 
> corresponding 'time' aggregate for .maxsum is .maxsumtime ie 
> $year.rain.maxsumtime.
>
> This may make a bit more sense if you refer to the Aggregation types 
>  appendix in the 
> Customization Guide.
>
> Assuming you are using the alltime period provided by the xstats example 
> search list extension, the $alltime portion of the tag simply allows the 
> underlying query to use the entire daily summary table rather than just the 
> current year, month etc so $alltime.rain.maxsum and 
> $alltime.rain.maxsumtime should give you the results you are after.
>
> Gary
>

Have checked my weewx.sdb and ALL rain records have a lot of decimal 
places, not just the historical records but live records to
As an example 0.2mm looks always to be 0.00787405
0.4mm = 0.015748031 
Is this expected 
Temp 

-- 
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: Acurite 00592tx Tower Sensor info

[Andy]

Let me know if you find the humidity sensor, I have a 592x  needs one.

On Friday, August 10, 2018 at 12:24:40 AM UTC-7, Gazza wrote:
>
> Hi Andy,
>
> From the pictures at wxforum it looks like an analogue capacitive humidity 
> sensor, if I can find one I'll try it out. 
>
> Now that the Digoo (Nexus) sensor works and the other cheap ebay Prologue 
> sensor I got also works I have enough dual temp/humidity for what I want.
>
>
> 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: High Wind Direction always shows as N/A

[gjr80]

Bernhard,

Could I get you to try the attached accum.py, I have put a couple of lines 
of code in there so we can see what wind direction is going into the 
accumulators and what is being extracted at the end of the archive period. 
What I would like you to do is to use this accum.py and run WeeWX directly 
for a couple of archive periods capturing both the console output and the 
log. To use:

1. Rename the existing bin/weewx/accum.py:

$ mv /home/weewx/bin/weewx/accum.py /home/weewx/bin/weewx/accum_orig.py

2. Download the attached accum.py and save in /home/weewx/bin/weewx

3. Edit weewx.conf and set debug=1

4. Stop WeeWx if it was running and run WeeWX directly 
 and let it run for 
at least two archive periods, preferably when there is some wind around so 
that we get wind speed and direction

5. Capture the console output and take a log extract from when you ran 
WeeWX directly. Post both here.

6. You can revert to the original accum.py by deleting accum.py and then 
renaming the backup copy we made:

$ rm /home/weewx/bin/weewx/accum.py
$ mv /home/weewx/bin/weewx/accum_orig.py /home/weewx/bin/weewx/accum.py

Gary

On Wednesday, 8 August 2018 05:54:43 UTC+10, bernhard.fr...@gmail.com wrote:
>
> Hi Gary,
>
> No need for a hurry! Many thanks in advance for your continued support!
>
> Best regards 
>
> Bernhard 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#
#Copyright (c) 2009-2016 Tom Keffer 
#
#See the file LICENSE.txt for your full rights.
#
"""Statistical accumulators. They accumulate the highs, lows, averages,
etc., of a sequence of records."""

import math

import configobj

import weewx

class OutOfSpan(ValueError):
"""Raised when attempting to add a record outside of the timespan held by an accumulator"""

#===
# ScalarStats
#===

class ScalarStats(object):
"""Accumulates statistics (min, max, average, etc.) for a scalar value.

Property 'last' is the last non-None value seen. Property 'lasttime' is
the time it was seen. """

default_init = (None, None, None, None, 0.0, 0, 0.0, 0)

def __init__(self, stats_tuple=None):
self.setStats(stats_tuple)
self.last = None
self.lasttime = None
 
def setStats(self, stats_tuple=None):
(self.min, self.mintime,
 self.max, self.maxtime,
 self.sum, self.count,
 self.wsum,self.sumtime) = stats_tuple if stats_tuple else ScalarStats.default_init
 
def getStatsTuple(self):
"""Return a stats-tuple. That is, a tuple containing the gathered statistics.
This tuple can be used to update the stats database"""
return (self.min, self.mintime, self.max, self.maxtime, 
self.sum, self.count, self.wsum, self.sumtime)

def mergeHiLo(self, x_stats):
"""Merge the highs and lows of another accumulator into myself."""
if x_stats.min is not None:
if self.min is None or x_stats.min < self.min:
self.min = x_stats.min
self.mintime = x_stats.mintime
if x_stats.max is not None:
if self.max is None or x_stats.max > self.max:
self.max = x_stats.max
self.maxtime = x_stats.maxtime
if x_stats.lasttime is not None:
if self.lasttime is None or x_stats.lasttime >= self.lasttime:
self.lasttime = x_stats.lasttime
self.last = x_stats.last

def mergeSum(self, x_stats):
"""Merge the sum and count of another accumulator into myself."""
self.sum += x_stats.sum
self.count   += x_stats.count
self.wsum+= x_stats.wsum
self.sumtime += x_stats.sumtime

def addHiLo(self, val, ts):
"""Include a scalar value in my highs and lows.
val: A scalar value
ts:  The timestamp.
"""
if val is not None:
if self.min is None or val < self.min:
self.min = val
self.mintime = ts
if self.max is None or val > self.max:
self.max = val
self.maxtime = ts
if self.lasttime is None or ts >= self.lasttime:
self.last= val
self.lasttime= ts

def addSum(self, val, weight=1):
"""Add a scalar value to my running sum and count."""
if val is not None:
self.sum += val
self.count   += 1
self.wsum+= val * weight

Re: [weewx-user] Re: Degrees measurement in exact figures

[Thomas Keffer]

I think I see the problem. It was indeed introduced by the change to
extract any extra information out of the accumulators.

The problem is that 'wind' is not in the archive record as emitted by the
Davis logger, so the accumulator sets to work. Unfortunately, while
extracting 'wind', it extracts windDir as the vector average of the wind
and overwrites the value from the logger.

Fix shouldn't be very hard, but it will have to wait until later today.

-tk

On Thu, Aug 9, 2018 at 7:57 PM gjr80  wrote:

> Indeed I suspect something has changed. The start of my archive has
> windDir and windGustDir that are all multiples of 22.5. However, the most
> recent portion of my archive has values all over the place. Maybe Tom might
> know what changed otherwise it will have to wait until I have free time to
> investigate. Two things that come to mind though, were some changes to the
> vantage driver around 3.7.0 (I think) and also a change to wring whatever
> we could out of the accumulators (also around 3.7.0 I think). Maybe be
> nothing to do with it but two areas of change that could be relevant.
>
> Gary
>
> On Friday, 10 August 2018 12:50:35 UTC+10, gjr80 wrote:
>>
>> Well that is interesting, according to the Davis Serial Communications
>> Reference Manual
>> 
>> the archive record format tables on pages 31-33 say that prevailing wind
>> direction (and high wind direction - read windgustDir) is provided as a
>> code representing one of the 16 compass points. And when you use hardware
>> record generation WeeWX uses the archive record from the station. Would
>> seem something is polluting the hardware archive record.
>>
>> Gary
>>
>> On Friday, 10 August 2018 12:36:49 UTC+10, Andrew Milner wrote:
>>>
>>> I am now confused Gary
>>>
>>> Here is my archive and also my weewx.conf.  From your post I should only
>>> have the 16 cardinal points, but don't
>>>
>>>
>>>
>>> On Friday, 10 August 2018 02:14:05 UTC+3, gjr80 wrote:

 Archive records generated by Davis hardware use a single byte for wind
 direction (both windDir and windGustDir) with 4 bits being used to
 represent 16 points of the compass ie N, NNE, NE etc. Loop packets on the
 other hand use provide a wind direction in two bytes that provides integer
 degrees from 1 to 360 degrees.

 So the bottom line is that a system using a Davis station using
 hardware record generation will only see discrete 16 point compass values
 for any point in time windDir (and windgustDir) tags (aggregates that
 average over a time or min/max values that have been based on loop data
 will/may show value other than the 16 compass point equivalents). Of course
 if you decide to use software record generation then WeeWX will calculate
 the wind directions based on accumulated loop data and that will result in
 values other than the 16 compass point equivalents.

 Only seeing degree equivalents of the 16 compass points for windDir/
 windGustDir from my Davis station always seemed like a shortcoming to
 me, but when you think of windDir and windGustDir as averages over an
 archive period (say 5 minutes) it makes much more sense.

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

-- 
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] Davis driver: weewx & sending data to Davis weatherlink.com

[Thomas Keffer]

The WeeWX vantage driver needs to  control the state the logger is in. In
particular, to switch it back and forth between LOOP and archive mode.

So does WeatherLink.com.

Unfortunately, this means you have to choose between one or the other. They
both can't control the state.

It's not so much about the socket (although that's an issue, too), as the
logger state.

-tk

On Fri, Aug 10, 2018 at 4:33 AM Premle  wrote:

> Hi,
>
>  I noticed weewx keeps the IP data logger from sending data to
> weatherllink.com
>
> On
> https://www.davisinstruments.com/resource/how-do-i-communicate-directly-with-my-weatherlinkip-data-logger/
> I found the following info:
>
> Please note that in order to allow the IP logger to send to
>> WeatherLink.com, you must release the TCP socket for about 5 seconds once
>> per minute for the current conditions (loop packet) to be sent and about 60
>> seconds once per hour for the archive records to be sent up.
>>
>
> Could it be the current davis driver does not take this suggestion into
> account? At least there is no configuration option to trigger such
> behaviour.
> The alternative would probably be weewx forwarding the data to
> weatherlink.com
>
> Did anyone else run into this issue?
>
>
>
>
>
>
> --
> 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: All-time and delta rain.max not correct

[gjr80]

In the daily summaries the 'max' field stores the max value of the obs for 
the day (the row of the daily summary table) concerned. So for point in 
time obs like temperature, humidity etc $year.outTemp.max will indeed give 
the max outTemp value seen since 1 January of the current year and 
$year.outTemp.maxtime will give the date-time it occurred. The same tag 
will certainly work with rain, ie $year.rain.max but what that tag is 
returning is not the max daily rainfall in the year to date but rather the 
max rainfall seen in an archive period in the year to date, you are 
treating rainfall more as a point in time observation. The $year.rain.sum 
tag will give you the total rainfall in the year to date so it does not 
help (it sums the daily summaries sum field). If you are looking for the 
max daily rainfall in the year you want to look at the max of the sum 
fields and to find the max value of the sum field you use the .maxsum 
aggregation type in your tag ie $year.rain.maxsum. Date-time wise 
$year.rain.maxtime may well provide the correct date-time that the highest 
daily rainfall occurred (chances are high that the highest archive period 
rainfall occurred on the day of highest total rainfall) but the 
corresponding 'time' aggregate for .maxsum is .maxsumtime ie 
$year.rain.maxsumtime.

This may make a bit more sense if you refer to the Aggregation types 
 appendix in the 
Customization Guide.

Assuming you are using the alltime period provided by the xstats example 
search list extension, the $alltime portion of the tag simply allows the 
underlying query to use the entire daily summary table rather than just the 
current year, month etc so $alltime.rain.maxsum and $alltime.rain.maxsumtime 
should give you the results you are after.

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

[Kalli]

Danke


Am Freitag, 10. August 2018 13:41:33 UTC+2 schrieb Kalli:
>
> Hallo
>
> bei mir ist der Windchill gleich wie die Aussentemperatur.
>
> normal muss der Windchill doch andere werte liefern.
>
> mfg. Kalli
>

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

[Andrew Milner]

windchill is only different when temp is below 50F and wind speed above 3 
mph

Wind chill kicks in only for temperatures less than 50°F and wind speeds 
over 3mph. Ref: http://www.nws.noaa.gov/om/winter/windchill.shtml

Heat index kicks in for temperatures above 80°F and humidities above 40%. 
Ref: http://www.wpc.ncep.noaa.gov/html/heatindex_equation.shtml

Otherwise, you get regular temperatures.


On Friday, 10 August 2018 14:41:33 UTC+3, Kalli wrote:
>
> Hallo
>
> bei mir ist der Windchill gleich wie die Aussentemperatur.
>
> normal muss der Windchill doch andere werte liefern.
>
> mfg. Kalli
>

-- 
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: All-time and delta rain.max not correct

[Andrew Milner]

is alltime.rain.max giving rain total or maximum rainrate??

NOAA just gives daily rain total doesn't it?

Have you tried just adding up the rain values in the database for the 
specific date?   Is NOAA correct or incorrect for that date?
Have you tried looking for the highest rainrate in the database
select dateTime, max(rainrate) from archive where 1;  does it give 15.6 by 
any chance??

I assume the alltime tag is returning a rainrate value since a time is 
specified - if it was a rain total then I would expect time to always be 
midnight.



On Friday, 10 August 2018 12:53:01 UTC+3, Phil Owers wrote:
>
> Sorry to bother you all again.
> When using $alltime.rain.max at $alltime.rain.maxtime.format(%d %b %Y(
> I get a figure of 15.6mm at 16 July returned. This date is my wettest day 
> so that part is correct but checking via the nooa monthly and yearly 
> reports it should be 29.6mm. Have also used the delta command and it gave 
> the same reading. 
> Have today done a wee_database weewx.conf --drop-daily as changed some 
> historical wind speeds in the sdb, deleted all nooa reports and they all 
> corrected ok but didn't make any difference to the rain total above. Any 
> help would be appreciated. Thanks 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.

[weewx-user] Re: Davis driver: weewx & sending data to Davis weatherlink.com

[Philip Kutzenco]

This has been true for me. AFAIK it is an issue with pretty much every 
program that gets data from the Davis IP Data Logger other than Davis' own 
Weatherlink software. Cumulus, for instance, has a setting that releases 
the driver periodically to allow the IP Data Logger to upload. In the 
Cumulus MX version, though, using that setting doesn't work reliably in my 
experience - usually crashing Cumulus MX periodically.

There is a WeeWX extension (wlink) that connects to weatherlink.com and 
downloads data from the website, rather than from your onsite data logger. 
My experience with it is that it only provides "archive" updates (every 30 
minutes) rather than LOOP data (which is every minute for me). I ended up 
purchasing a second console and a USB data logger which I connected to a 
Raspberry Pi Zero W running WeeWX. My first console has a Davis IP Data 
Logger and updates weatherlink.com.

On Friday, August 10, 2018 at 7:33:31 AM UTC-4, Premle wrote:
>
> Hi,
>
>  I noticed weewx keeps the IP data logger from sending data to 
> weatherllink.com
>
> On 
> https://www.davisinstruments.com/resource/how-do-i-communicate-directly-with-my-weatherlinkip-data-logger/
>  
> I found the following info:
>
> Please note that in order to allow the IP logger to send to 
>> WeatherLink.com, you must release the TCP socket for about 5 seconds once 
>> per minute for the current conditions (loop packet) to be sent and about 60 
>> seconds once per hour for the archive records to be sent up.
>>
>
> Could it be the current davis driver does not take this suggestion into 
> account? At least there is no configuration option to trigger such 
> behaviour.
> The alternative would probably be weewx forwarding the data to 
> weatherlink.com
>
> Did anyone else run into this issue?
>
>
>
>
>
>
>

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

[Kalli]

Hallo

bei mir ist der Windchill gleich wie die Aussentemperatur.

normal muss der Windchill doch andere werte liefern.

mfg. Kalli

-- 
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] Davis driver: weewx & sending data to Davis weatherlink.com

[Premle]

Hi,

 I noticed weewx keeps the IP data logger from sending data to 
weatherllink.com

On 
https://www.davisinstruments.com/resource/how-do-i-communicate-directly-with-my-weatherlinkip-data-logger/
 
I found the following info:

Please note that in order to allow the IP logger to send to 
> WeatherLink.com, you must release the TCP socket for about 5 seconds once 
> per minute for the current conditions (loop packet) to be sent and about 60 
> seconds once per hour for the archive records to be sent up.
>

Could it be the current davis driver does not take this suggestion into 
account? At least there is no configuration option to trigger such 
behaviour.
The alternative would probably be weewx forwarding the data to 
weatherlink.com

Did anyone else run into this issue?






-- 
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] All-time and delta rain.max not correct

[Phil Owers]

Sorry to bother you all again.
When using $alltime.rain.max at $alltime.rain.maxtime.format(%d %b %Y(
I get a figure of 15.6mm at 16 July returned. This date is my wettest day so 
that part is correct but checking via the nooa monthly and yearly reports it 
should be 29.6mm. Have also used the delta command and it gave the same 
reading. 
Have today done a wee_database weewx.conf --drop-daily as changed some 
historical wind speeds in the sdb, deleted all nooa reports and they all 
corrected ok but didn't make any difference to the rain total above. Any help 
would be appreciated. Thanks 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.

[weewx-user] Re: Is there a port switching USB hub currently available.

[Greg from Oz]

This is how I get around it:
https://groups.google.com/forum/#!searchin/weewx-user/home$20automation|sort:date/weewx-user/WETchOWLPsE/oa4xsgVLCQAJ


On Saturday, 19 July 2014 23:15:43 UTC+10, Robin wrote:
>
> The weewx wiki article
>
> What to do when your Fine Offset station locks up
> says
>
> Hubs that are known to work:
>
> LINKSYS USB2HUB4 (NEC Corp. HighSpeed Hub)
> D-Link Corp. DUB-H7 7-port USB 2.0 hub [grey]
>
>
> However neither of these hubs seem to be currently available.
>
> Can anybody suggest a suitable hub that is currently in production or do 
> you have any suggestions or further ideas?
>

-- 
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: Acurite 00592tx Tower Sensor info

[Gazza]

Hi Andy,

>From the pictures at wxforum it looks like an analogue capacitive humidity 
sensor, if I can find one I'll try it out. 

Now that the Digoo (Nexus) sensor works and the other cheap ebay Prologue 
sensor I got also works I have enough dual temp/humidity for what I want.


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: Oregon Scientific and SDR issue

[Linda Eriksson]

That seems to have done half the trick.
I don't get the wind measurements into weewx, but it stopped 'punting' at 
it.
I suppose the pcr800 needs to have the same thing, but with rain-related 
values?

-- 
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.
LOOP:   2018-08-10 08:35:56 CEST (1533882956) altimeter: None, appTemp: None, 
barometer: None, cloudbase: 1560.2756576, dateTime: 1533882956, dewpoint: 
60.8920595288, heatindex: 66.92, humidex: 75.2766992628, inDewpoint: None, 
maxSolarRad: 317.939292511, outBatteryStatus: 0, outHumidity: 81.0, outTemp: 
66.92, pressure: None, rainRate: 0, usUnits: 1, windchill: None, windDir: None, 
windGustDir: None
LOOP:   2018-08-10 08:36:10 CEST (1533882970) altimeter: None, appTemp: None, 
barometer: None, cloudbase: None, dateTime: 1533882970, dewpoint: None, 
heatindex: None, humidex: None, inBatteryStatus: 0, inDewpoint: 63.5162478819, 
inHumidity: 83.0, inTemp: 68.9, maxSolarRad: 318.536236661, pressure: None, 
rainRate: 0, usUnits: 1, windchill: None, windDir: None, windGustDir: None
LOOP:   2018-08-10 08:36:48 CEST (1533883008) altimeter: None, appTemp: None, 
barometer: None, cloudbase: 1560.2756576, dateTime: 1533883008, dewpoint: 
60.8920595288, heatindex: 66.92, humidex: 75.2766992628, inDewpoint: None, 
maxSolarRad: 320.155995096, outBatteryStatus: 0, outHumidity: 81.0, outTemp: 
66.92, pressure: None, rainRate: 0, usUnits: 1, windchill: None, windDir: None, 
windGustDir: None
LOOP:   2018-08-10 08:37:09 CEST (1533883029) altimeter: None, appTemp: None, 
barometer: None, cloudbase: None, dateTime: 1533883029, dewpoint: None, 
heatindex: None, humidex: None, inBatteryStatus: 0, inDewpoint: 63.5162478819, 
inHumidity: 83.0, inTemp: 68.9, maxSolarRad: 321.050817585, pressure: None, 
rainRate: 0, usUnits: 1, windchill: None, windDir: None, windGustDir: None
LOOP:   2018-08-10 08:37:41 CEST (1533883061) altimeter: None, appTemp: None, 
barometer: None, cloudbase: 1561.33464136, dateTime: 1533883061, dewpoint: 
61.067402, heatindex: 67.1, humidex: 75.5728505385, inDewpoint: None, 
maxSolarRad: 322.414071075, outBatteryStatus: 0, outHumidity: 81.0, outTemp: 
67.1, pressure: None, rainRate: 0, usUnits: 1, windchill: None, windDir: None, 
windGustDir: None


syslog
Description: Binary data

[weewx-user] Re: SDR and Digoo DG-R8H Temp & Humidity sensor

[Gazza]

Hi Andy

I now get a parsed output like this:

parsed: {
'temperature.1:180.NexusTemperaturePacket': 16.6, 
'humidity.1:180.NexusTemperaturePacket': 49.0, 
'battery.1:180.NexusTemperaturePacket': 0, 
'usUnits': 16, 
'dateTime': 1533881039
}

So your edit worked, my version of sdr.py is not exactly the same as what 
you posted but close enough to work out where to put the extra lines.


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.