Re: [weewx-user] New Install - Debian 9 Stretch

[Michael9778]

I had the same problem, searched and tried dozens of threads, the "su -" vs 
"su" made all the difference!

On Thursday, 9 November 2017 13:45:58 UTC-8, Glenn McKechnie wrote:
>
> Dave, 
>
> Try using su - rather than just su. Note the dash (-) after su, that 
> dash fully sets your environment for root which should help with the 
> gpg issue and the remaining errors to disappear. 
>
> Don't worry about the squeeze line in the weewx repo , it should work 
> regardless. 
> Cheers 
>  Glenn 
>
> rorpi - read only raspberry pi & various weewx addons 
> https://github.com/glennmckechnie 
>
>
> On 10 November 2017 at 08:31, Dave Walker  > wrote: 
> > 
> > My new install on a Debian 9 PC is off to a rocky start. I used the 
> > instructions at the link below: 
> > 
> > http://www.weewx.com/docs/debian.htm 
> > 
> > Sudo is not installed in a fresh version of Debian 9, so I began as 
> root. 
> > 
> > davew@debian:~$ su 
> > Password: 
> > root@debian:/home/davew# wget -qO - http://weewx.com/keys.html | apt- 
> > key add - 
> > gpg: keydb_get_keyblock failed: Value not found 
> > gpg: keydb_get_keyblock failed: Value not found 
> > root@debian:/home/davew# wget -qO - http://weewx.com/keys.html | sudo 
> > apt-key add - 
> > gpg: keydb_get_keyblock failed: Value not found 
> > gpg: keydb_get_keyblock failed: Value not found 
> > root@debian:/home/davew# wget -qO - http://weewx.com/apt/weewx.list | 
> > sudo tee /etc/apt/sources.list.d/weewx.list 
> > deb [arch=all] http://weewx.com/apt/ squeeze main 
> > 
> > root@debian:/home/davew# whoami 
> > root 
> > root@debian:/home/davew# apt-get update 
> > Ign:1 http://ftp.ca.debian.org/debian stretch 
> > InRelease 
> > Hit:2 http://ftp.ca.debian.org/debian stretch-updates 
> > InRelease 
> > Hit:3 http://security.debian.org/debian-security stretch/updates 
> > InRelease 
> > Hit:4 http://ftp.ca.debian.org/debian stretch 
> > Release 
> > Get:5 http://weewx.com/apt squeeze InRelease [2,537 
> > B] 
> > Ign:5 http://weewx.com/apt squeeze 
> > InRelease 
> > 
> > Get:7 http://weewx.com/apt squeeze/main all Packages [2,581 
> > B] 
> > Fetched 5,118 B in 7s (730 
> > B/s) 
> > 
> > Reading package lists... Done 
> > W: http://ftp.ca.debian.org/debian/dists/stretch-updates/InRelease: The 
> > key(s) in the keyring /etc/apt/trusted.gpg are ignored as the file is 
> > not readable by user '_apt' executing apt-key. 
> > W: http://security.debian.org/debian-security/dists/stretch/updates/InR 
> > elease: The key(s) in the keyring /etc/apt/trusted.gpg are ignored as 
> > the file is not readable by user '_apt' executing apt-key. 
> > W: http://ftp.ca.debian.org/debian/dists/stretch/Release.gpg: The 
> > key(s) in the keyring /etc/apt/trusted.gpg are ignored as the file is 
> > not readable by user '_apt' executing apt-key. 
> > W: http://weewx.com/apt/dists/squeeze/InRelease: The key(s) in the 
> > keyring /etc/apt/trusted.gpg are ignored as the file is not readable by 
> > user '_apt' executing apt-key. 
> > W: GPG error: http://weewx.com/apt squeeze InRelease: The following 
> > signatures couldn't be verified because the public key is not 
> > available: NO_PUBKEY ED444FCCF0E2B09E 
> > W: The repository 'http://weewx.com/apt squeeze InRelease' is not 
> > signed. 
> > N: Data from such a repository can't be authenticated and is therefore 
> > potentially dangerous to use. 
> > N: See apt-secure(8) manpage for repository creation and user 
> > configuration details. 
> > 
> > 
> > It appears that Weewx is expecting access to the squeeze repository. but 
> I 
> > am running stretch?? 
> > 
> > Can anybody set me on the right path. I sure didn't get far on my own. 
> Help 
> > would be appreciated! 
> > 
> > Dave W. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "weewx-user" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to weewx-user+...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [weewx-user] Re: Manually adding historical data to weewx database

[dhindley]

Great.  Thanks.  I will try that.

On Thursday, 12 April 2018 02:30:27 UTC+1, Andrew Milner wrote:
>
> if you can massage the data into a suitable format you can always use 
> wee_import
>
> http://weewx.com/docs/utilities.htm#wee_import_utility
>
>
>
> On Wednesday, 11 April 2018 20:58:21 UTC+3, David Hindley wrote:
>
>> The data has been downloaded to a text file from the WeatherLink 
>> software, stores in a txt file on my Windows PC. 
>>
>> David. 
>>
>> On Wed, 11 Apr 2018 at 18:05, Andrew Milner  
>> wrote:
>>
>>> where is the historical data kept??
>>>
>>>
>>>
>>> On Wednesday, 11 April 2018 19:45:19 UTC+3, dhin...@djhindley.com wrote:
>>>
 Hi

 I have just started using weewx on a Raspberry Pi with a Davis Vantage 
 using Weatherlink IP. The weather station has been running for 2 years, 
 but 
 I only got weewx working from today. All is working fine, except that 
 since 
 I updated my archive record to 5mins immediately prior to the 
 installation, 
 weewx only shows the recent records. Does anyone know if there is a way I 
 can manually add the historical data to the weewx database, so that the 
 full history is shown on my weewx webpage? 

 Thanks

>>> -- 
>>> 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/VCwuWaT2kwY/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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: Using WeeWxMQTT - problems

[Bill Morrow]

On Thursday, 12 April 2018 00:23:13 UTC-3, Ralph Underwood wrote:
>
> *IT WORKS!*
>
> I added: TIME = dateTime to wxMesh stanza of weewx.conf the stopped and 
> restarted WeeWx - waited a few minutes and I now have values showing up in 
> /var/www/html/weewx/index.html
>
>
Hurray!

This line in your earlier log file excerpt :

Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: label map is {'INTE': 
'inTemp', 'INHU': 'outHumidity'}

was our clue that we had nothing mapped to dateTime. 

I put the blame on my genLoopPackets code. It always *replaces* an incoming 
dateTime/TIME value. It should just create it regardless of what is 
provided. In my defense, I have plans to add a real time clock in the 
field, and use an NTP derived time on the networked inside node.

I've updated the wiki at github  
with this finding.
 

-- 
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: Using WeeWxMQTT - problems

[gjr80]

Just as an aside, as of weeWX 3.7.0 a couple of changes were made to the 
included drivers that use a mapping to map a sensor (read output from some 
external device/system) to a weeWX schema field (read a field in the loop 
packet or archive record generated by the driver). In a nutshell, when 
defined in a driver stanza in weewx.conf, the map is placed in a stanza 
named [[sensor_map]]. The sensor mappings are then included using the 
format schema_name = hardware_name (or you can think of it as weeWX 
loop/archive field = sensor name). So a sensor map might look like

...
[ABC123]
# driver stanza for ABC123 weather station
[[sensor_map]]
outTemp = sensor25
outHumidity = ABCDEFG.123456
windSpeed = wind_speed
...


Not a change that will cause any driver that uses a different construct to 
fail, but it may be useful to adopt such a construct in a future release 
(if nothing else helps us all speak the same language when talking 
drivers). I expect in due course this will be included in the developer 
notes somewhere.

Gary


On Thursday, 12 April 2018 20:51:18 UTC+10, Bill Morrow wrote:
>
> On Thursday, 12 April 2018 00:23:13 UTC-3, Ralph Underwood wrote:
>>
>> *IT WORKS!*
>>
>> I added: TIME = dateTime to wxMesh stanza of weewx.conf the stopped and 
>> restarted WeeWx - waited a few minutes and I now have values showing up in 
>> /var/www/html/weewx/index.html
>>
>>
> Hurray!
>
> This line in your earlier log file excerpt :
>
> Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: label map is {'INTE': 
> 'inTemp', 'INHU': 'outHumidity'}
>
> was our clue that we had nothing mapped to dateTime. 
>
> I put the blame on my genLoopPackets code. It always *replaces* an 
> incoming dateTime/TIME value. It should just create it regardless of what 
> is provided. In my defense, I have plans to add a real time clock in the 
> field, and use an NTP derived time on the networked inside node.
>
> I've updated the wiki at github 
>  with this finding.
>  
>

-- 
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: Manually adding historical data to weewx database

[dhindley]

The import facility looks like the right way to go - but unfortunately my 
source data has variable archive intervals. Is there any way of dealing 
with this in the weewx import utlility, or is it best to convert all the 
source data to have the same archive interval (painful!)?

Thanks.

On Wednesday, 11 April 2018 17:45:19 UTC+1, dhin...@djhindley.com wrote:
>
> Hi
>
> I have just started using weewx on a Raspberry Pi with a Davis Vantage 
> using Weatherlink IP. The weather station has been running for 2 years, but 
> I only got weewx working from today. All is working fine, except that since 
> I updated my archive record to 5mins immediately prior to the installation, 
> weewx only shows the recent records. Does anyone know if there is a way I 
> can manually add the historical data to the weewx database, so that the 
> full history is shown on my weewx webpage? 
>
> Thanks
>

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

[weewx-user] Re: Manually adding historical data to weewx database

[Andrew Milner]

As far as I know the latest version of weewx casn handle variable 
intervals- so just let wee_import derive the interval from the time stamps* 
should* work (I think!!)

someone more knowledgeable maywish to comment 



On Thursday, 12 April 2018 17:59:03 UTC+3, dhin...@djhindley.com wrote:

> The import facility looks like the right way to go - but unfortunately my 
> source data has variable archive intervals. Is there any way of dealing 
> with this in the weewx import utlility, or is it best to convert all the 
> source data to have the same archive interval (painful!)?
>
> Thanks.
>
> On Wednesday, 11 April 2018 17:45:19 UTC+1, dhin...@djhindley.com wrote:
>>
>> Hi
>>
>> I have just started using weewx on a Raspberry Pi with a Davis Vantage 
>> using Weatherlink IP. The weather station has been running for 2 years, but 
>> I only got weewx working from today. All is working fine, except that since 
>> I updated my archive record to 5mins immediately prior to the installation, 
>> weewx only shows the recent records. Does anyone know if there is a way I 
>> can manually add the historical data to the weewx database, so that the 
>> full history is shown on my weewx webpage? 
>>
>> Thanks
>>
>

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

[weewx-user] Re: Using WeeWxMQTT - problems

[Bill Morrow]

On Thursday, 12 April 2018 08:13:51 UTC-3, gjr80 wrote:
>
> Just as an aside, as of weeWX 3.7.0 a couple of changes were made to the 
> included drivers that use a mapping to map a sensor (read output from some 
> external device/system) to a weeWX schema field (read a field in the loop 
> packet or archive record generated by the driver). In a nutshell, when 
> defined in a driver stanza in weewx.conf, the map is placed in a stanza 
> named [[sensor_map]]. The sensor mappings are then included using the 
> format schema_name = hardware_name (or you can think of it as weeWX 
> loop/archive field = sensor name). So a sensor map might look like
>
> ...
> [ABC123]
> # driver stanza for ABC123 weather station
> [[sensor_map]]
> outTemp = sensor25
> outHumidity = ABCDEFG.123456
> windSpeed = wind_speed
> ...
>
>
> Not a change that will cause any driver that uses a different construct to 
> fail, but it may be useful to adopt such a construct in a future release 
> (if nothing else helps us all speak the same language when talking 
> drivers). I expect in due course this will be included in the developer 
> notes somewhere.
>
> Gary
>

Good to know, Gary. Thanks. I'm looking at the effort to change the driver 
to be a service in my fork. So might tackle this construct after or during 
that.

-- 
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: Using WeeWxMQTT - problems

[Ralph Underwood]

What's involved in changing the driver to a service?  My coding skills are 
just above minimal, however I would be happy to be involved in testing. I 
frequently fall asleep reading my 1,540 page "Learning Python" - using it 
as a pillow has only raised by knowledge level slightly.

I have one station in the wild that uses owfs and file parse. I would like 
to add mqtt capability to that one. I was going to experiment with using 
mqtt as driver and both fileparse and owfs as services. One option I have 
been thinking about would be to convert the sensors I use file parse for to 
mqtt - then only having one driver and one service for sensors. That option 
would have two (or more) mqtt clients publishing and WxMesh magically 
sorting it out.

The station at my vacation home has a Ultimeter 2100 and to add mqtt based 
sensors I think I would need to run wxMesh as a service.

Again thanks so much for the help getting this working.

-- 
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] Problem with RTG max and min stats when using software driver

[Alec Bennett]

My weather station is in an area with unstable power and internet, and I
found that often after an internet outage I'd need to clear the console
memory on my Vantage Pro2 before it would start sending data again. I
switched over to the software record generation
(record_generation=software) and haven't had an outage in months now.

The only problem I'm having now is with the real time gauge (RTG)
extension's daily maximum and minimum stats. For example the day's maximum
wind gust (wgustTM), daily maximum temperature (tempTH), and daily minimum
temperature (tempTL) are all locked on some data in the past.

However the reports generated by the cheetah engine have the correct daily
maximums and minimums.

Before I dig farther into the RTG, I was wondering if anyone might have
some insight off-hand?

-- 
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] Unit conversion options

[vigilancewx]

hi

I normally run weewx with a vantage and a few 1 wire sensors

standardreport units are set to metric

but the target units in weewx.conf set to US
   # DO NOT MODIFY THIS VALUE UNLESS YOU KNOW WHAT YOU ARE DOING!
target_unit = US# Options are 'US', 'METRICWX', or 'METRIC'



all temperatures and other readings displayed on the html pages as they 
should be

I have tried to create my own extension to read my electricity meter and it 
should work (this version is in simulator mode just now) 

the current sensor collects the power and temp readings to a txt file and 
my extension imports it in to weewx.sdb
the imported power readings are in watts however the temperature is in C'

Checking the weewxsdb all the temp readings are stored in F and then 
displayed on the html pages in C'

this particular reading cctemp is being parsed and stored in weewx.sdb as 
deg C so when its shown on the html pages its incorrect  

i have tried to convert it back to 'C under stdcalibrate/corrections but it 
has no effect?


is it possible to display this temperature back to 'C

Unit conversion options 

The tag optional_unit_conversion can be used with either current 
observations or aggregations. If supplied, the results will be converted to 
the specified units. For example, if you have set group_pressure to inches 
of mercury (inHg), then the tag 

Today's average pressure=$day.barometer.avg 

would normally give a result such as

Today's average pressure=30.05 inHg 

However, if you add mbar to the end, 

$day.barometer.avg.mbar 

then the results will be in millibars:


i have tried to convert with the above but unsure how to implement it


thanks for any advice

-- 
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: Unit conversion options

[gjr80]

Hi,

The first thing you need to do is forget about target_units = XXX, it has 
nothing to do with how or what your sensors (via respective 
driver/services) feed weeWX nor does it have any real effect of the unit 
formatting in reports. target_units merely sets the unit system that weeWX 
uses to store obs in the database - you could equally use apples for 
temperature and oranges for humidity, as long as weeWX knows how to convert 
apples to C/F and oranges to % :)

The secret to getting weeWX unit conversion working error free is to follow 
a few simple rules:

1. weeWX recognises 3 different unit systems; US customary, Metric and 
MetricWx. The units used for individual obs in these unit systems are 
covered in the Units appendix  
to the Customization guide.
2. Each loop packet or archive record either generated by a driver or in 
use within weeWX must have a field usUnits that is set to either weewx.US 
(value 0x01), weewx.METRIC (value 0x10) or weewx.METRICWX (value 0x11).
3. The obs fields in loop packets/archive records must be in the applicable 
units specified by the usUnits field in the loop packet/archive record 
concerned.
4. Any services that add fields to loop packets/archive records must ensure 
any added fields are in the respective units defined by the usUnits field 
in the packet/record concerned.

A driver can emit packets/records using whatever unit system you want; US 
customary, Metric or MetricWX. When it comes time so save that data to the 
database the weeWX internals will do the necessary conversion (if required) 
to save to the target_units. If you have a service that pulls data from an 
external sensor and adds it to a loop or archive record then your service 
must check the usUnits field of the packet/record to which the data is to 
be added and the service needs to do the conversion, if required, before 
adding the data to the packet/record. This is easily done with the through 
a weeWX API call, you don't have to reinvent unit conversions. If you don't 
make sure that the obs you add are in the correct units then chances are 
somewhere along the line (storing to db, converting for display/reports) 
your data will be assumed to be in particular units when it is not and 
incorrectly converted.

If you follow this approach report unit conversion/formatting should work 
without issue. If you get your units mixed up internally no amount of unit 
conversion in reports will resolve the issue.

The above being said, if you are using the OWFS Service you should be able 
to set I up appropriately, of course if you are using something else or 
have modified its operation you will need to make sure that it is 
respecting  the usUnits value in of any packets/records it modifies.

Gary

On Friday, 13 April 2018 06:34:22 UTC+10, vigilancewx wrote:
>
> hi
>
> I normally run weewx with a vantage and a few 1 wire sensors
>
> standardreport units are set to metric
>
> but the target units in weewx.conf set to US
># DO NOT MODIFY THIS VALUE UNLESS YOU KNOW WHAT YOU ARE DOING!
> target_unit = US# Options are 'US', 'METRICWX', or 'METRIC'
>
>
>
> all temperatures and other readings displayed on the html pages as they 
> should be
>
> I have tried to create my own extension to read my electricity meter and 
> it should work (this version is in simulator mode just now) 
>
> the current sensor collects the power and temp readings to a txt file and 
> my extension imports it in to weewx.sdb
> the imported power readings are in watts however the temperature is in C'
>
> Checking the weewxsdb all the temp readings are stored in F and then 
> displayed on the html pages in C'
>
> this particular reading cctemp is being parsed and stored in weewx.sdb as 
> deg C so when its shown on the html pages its incorrect  
>
> i have tried to convert it back to 'C under stdcalibrate/corrections but 
> it has no effect?
>
>
> is it possible to display this temperature back to 'C
>
> Unit conversion options 
>
> The tag optional_unit_conversion can be used with either current 
> observations or aggregations. If supplied, the results will be converted to 
> the specified units. For example, if you have set group_pressure to 
> inches of mercury (inHg), then the tag 
>
> Today's average pressure=$day.barometer.avg 
>
> would normally give a result such as
>
> Today's average pressure=30.05 inHg 
>
> However, if you add mbar to the end, 
>
> $day.barometer.avg.mbar 
>
> then the results will be in millibars:
>
>
> i have tried to convert with the above but unsure how to implement it
>
>
> thanks for any advice
>

-- 
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: Manually adding historical data to weewx database

[gjr80]

David,

Variable archive intervals have been supported since weeWX v3.0.0, though I 
believe there was a display/report calculation bug that was addressed in 
3.7.0 (of course we are all running 3.8.0 so neither of these should be an 
issue :))

One thing to be mindful of when using wee_import to import data is that 
when you are deriving the archive interval from the source data (ie finding 
the difference between successive timestamps) missing records can skew this 
significantly. A single missing record in a data set with an interval of 5 
minutes will likely have negligible effect but if you have several hours or 
days missing it may be a different matter. For this reason when importing 
from WeatherUnderground if your WeatherUndergroud data was posted every 10 
minutes it is quite often handy to force wee_import to use a 10 minute 
archive interval as WeatherUnderground often does not return all available 
data, plus it is not unusual for users to have large gaps in their 
WeatherUnderground data.

If you have a changing archive interval in your data and are concerned 
about data gaps, it might be useful to break the import down into smaller 
chunks that use a single archive interval and import that data with a set 
rather derived interval.

Gary

PS. If there is significant reformatting required to import the 
ex-WeatherLink data I am happy to put together a WeatherLink module for 
wee_import, I will just need to know the data format. Only thing is it will 
take time for me to put the module together, though I guess your old data 
is not going anywhere :)

On Friday, 13 April 2018 01:16:54 UTC+10, Andrew Milner wrote:
>
> As far as I know the latest version of weewx casn handle variable 
> intervals- so just let wee_import derive the interval from the time stamps* 
> should* work (I think!!)
>
> someone more knowledgeable maywish to comment 
>
>
>
> On Thursday, 12 April 2018 17:59:03 UTC+3, dhin...@djhindley.com wrote:
>
>> The import facility looks like the right way to go - but unfortunately my 
>> source data has variable archive intervals. Is there any way of dealing 
>> with this in the weewx import utlility, or is it best to convert all the 
>> source data to have the same archive interval (painful!)?
>>
>> Thanks.
>>
>> On Wednesday, 11 April 2018 17:45:19 UTC+1, dhin...@djhindley.com wrote:
>>>
>>> Hi
>>>
>>> I have just started using weewx on a Raspberry Pi with a Davis Vantage 
>>> using Weatherlink IP. The weather station has been running for 2 years, but 
>>> I only got weewx working from today. All is working fine, except that since 
>>> I updated my archive record to 5mins immediately prior to the installation, 
>>> weewx only shows the recent records. Does anyone know if there is a way I 
>>> can manually add the historical data to the weewx database, so that the 
>>> full history is shown on my weewx webpage? 
>>>
>>> Thanks
>>>
>>

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

[weewx-user] Re: Problem with RTG max and min stats when using software driver

[gjr80]

Alec,

Reports will be getting daily maxima and minima from the daily summaries 
whereas the rtgd extension will be keeping its own maxima/minima. That 
being said it should not be affected by the record generation setting, the 
rtgd extension just runs off the loop packets though there may be some 
optimisations in there that are misbehaving. I'll have a look at it, in the 
meantime is the offending gauges page available publicly?

Gary

On Friday, 13 April 2018 06:13:24 UTC+10, Alec Bennett wrote:
>
> My weather station is in an area with unstable power and internet, and I 
> found that often after an internet outage I'd need to clear the console 
> memory on my Vantage Pro2 before it would start sending data again. I 
> switched over to the software record generation 
> (record_generation=software) and haven't had an outage in months now. 
>
> The only problem I'm having now is with the real time gauge (RTG) 
> extension's daily maximum and minimum stats. For example the day's maximum 
> wind gust (wgustTM), daily maximum temperature (tempTH), and daily minimum 
> temperature (tempTL) are all locked on some data in the past. 
>
> However the reports generated by the cheetah engine have the correct daily 
> maximums and minimums. 
>
> Before I dig farther into the RTG, I was wondering if anyone might have 
> some insight off-hand?
>
>
>

-- 
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: WU Import failed

[gjr80]

Andre,

I have reworked wee_import and have it here on my test system importing 
data from your WU station without issue. Just having a few GitHub issues, 
once I sort them out later today I will post some instructions for you or 
failing that I will email you the updated wee_import file(s).

Gary

On Wednesday, 11 April 2018 21:56:08 UTC+10, Andre wrote:
>
> Gary, I wish you a speedy recovery.
> I know that as well. Unfortunately.
>
> Regards, Andre
>
> Am Dienstag, 3. April 2018 17:16:46 UTC+2 schrieb Andre:
>>
>> Hi,
>>
>> First I have to say I'm not Linux professional and all my 'know-how' is 
>> based on reading a lot of tutorials.
>>
>> My weather station is a Davis Vantage Vue. WeeWX is running on a 
>> Raspberry Pi 2. This setup is running and all data are fine.
>>
>> My problem is I can't import any data from WU with wee_import.
>>
>> ---log---
>> wee_import --import-config=/var/tmp/wu.conf --from=2018-01-01T00:30 --to=
>> 2018-01-31T00:00 --dry-run
>> Starting wee_import...
>> Observation history for Weather Underground station 'INORDERS99' will be 
>> imported.
>> Using database binding 'wx_binding', which is bound to database 
>> 'weewx.sdb'
>> Destination table 'archive' unit system is '0x01' (US).
>> Observations timestamped after 2018-01-01 00:30:00 CET (1514763000) and 
>> up to and
>> including 2018-01-31 00:00:00 CET (1517353200) will be imported.
>> This is a dry run, imported data will not be saved to archive.
>> * radiation: cannot convert '---' to float at timestamp '2018-01-01 
>> 00:30:00 CET (1514763000)'.*
>>  Nothing done, exiting.
>> ---log---
>>
>> What does it mean "radiation: cannot convert '---' to float at timestamp 
>> '2018-01-01 00:30:00 CET (1514763000)'?
>> Is there data mismatch on WU? What can I do to solv this issue?
>>
>> Regards, Andre
>>
>

-- 
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] negative value in rain display

[stef 942]

Hi,

yesterday i had a power failure, when i restart weewx it shows negative 
value in rain display : my page 

i tried to reset my station (WMR200) , i reset also the datalogger but 
still same negative value :(

i dont know what to do to reset rain values, can you help me please? thanks.

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