[weewx-user] Re: csv.py don't add radiation and UV

[JanC]

Gary, thanks for your reply,i will add it right now.

Op maandag 27 mei 2019 04:41:44 UTC+2 schreef gjr80:
>
> Hi,
>
> Your 'fix' has merely forced the csv service to always generate data.csv 
> based on archive records rather than the default loop packets. Using 
> archive records rather than loop packets would make sense for a station 
> that emits partial loop packets (ie a station that does not include 
> radiation and UV in every loop packet) but based on the log extract you 
> provided your station does not appear to be a partial packet type. In any 
> case, if generating data.csv based on archive records rather than loop 
> packets solves your problem a far better approach would be to return 
> csv.py to its original state and change your [CSV] stanza in weewx.conf 
> to read:
>
> [CSV]
> filename = /var/tmp/tmp/data.csv
> binding = archive
>
> This will require a WeeWX restart. This achieves the same effect as your 
> changes whilst ensuring your system will continue to work across future 
> upgrades.
>
> Gary
>
>
> On Sunday, 26 May 2019 16:48:16 UTC+10, JanC wrote:
>>
>> I found the solution myself.
>>
>> In csv.py :
>>
>> if self.binding == 'binding':
>>
>>
>> self.binding = d.get('binding', 'loop')
>>  ##   if self.binding == 'loop':
>> if self.binding == 'binding':
>> self.bind(weewx.NEW_LOOP_PACKET, self.handle_new_loop)
>> else:
>> self.bind(weewx.NEW_ARCHIVE_RECORD, self.handle_new_archive)
>>
>> janc
>>
>> Op zaterdag 25 mei 2019 11:39:11 UTC+2 schreef JanC:
>>>
>>> I use a WH2600 weatherstation with a raspberry pi
>>>
>>> debian8
>>> weewx 3.9.1
>>> driver interceptor observer
>>> csv.py to collect the data to a csv-file
>>>
>>> with weewx 3.8 it works ok, after upgrade to 3.9 it fails
>>>
>>> I have some things overlooked?
>>>
>>> JanC
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e4b4375e-b47d-4433-8459-392cfa9aa00f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Add additional rain gauge via second data source

[gjr80]

The number one rule when augmenting archive records or loop packets with 
data is that you must check the unit system used in the record or packet 
(ie check the usUnits field) you are adding data to and make sure that any 
data you do add is in the same units as used by that unit system. If you 
fail to do this you may be fortunate to have something that works, but it 
will be good luck rather than good planning and the resulting system will 
be fragile with any future changes likely to result in unit conversion 
inconsistencies. For example, say you have a service that is adding a rain 
value to an archive record and your service produces a variable rainfall 
that contains the rain data to be added in mm. The archive record field you 
wish to create is 'our_new_field'. You might use some code in your service 
like the following to actually augment the archive record (untested):

import weewx

if event.record['usUnits'] == weewx.US:
# archive record uses US unit system so we need rainfall in inches
event.record['our_new_field'] = rainfall/25.4 if rainfall is not None 
else None
elif event.record['usUnits'] == weewx.METRIC:
# archive record uses the Metric unit system so we need rainfall in cm
event.record['our_new_field'] = rainfall/10.0 if rainfall is not None 
else None
elif event.record['usUnits'] == weewx.METRICWX:
# archive record uses the MetricWX unit system so we need rainfall in 
mm - leave as is
event.record['our_new_field'] = rainfall if rainfall is not None else 
None

or if you want to be a bit more sophisticated you can use the internal 
WeeWX unit conversion routines to do the unit conversion for you (much more 
compact code and useful for more complex/less well known conversions) 
(again untested):

import weewx.units

# express our rainfall value as a ValueTuple
rainfall_vt = weewx.units.ValueTuple(rainfall, 'mm', 'group_rain')
# now augment the archive record with the appropriately converted value 
event.record['our_new_field'] = weewx.units.convertStd(rainfall_vt, event.
record['usUnits'])

The above examples augment an archive record but they apply equally to loop 
packets. In the cases above we knew the incoming data was always in mm, if 
that is not the case and you need to handle the incoming data being in any 
one of a number of units then you will need some extra code to identify the 
incoming units and ensure the corect conversions are applied.

Gary

On Thursday, 23 May 2019 07:20:08 UTC+10, engolling wrote:
>
> Hello,
>
> of course I can give more details :-)
>
> So as you know I'm augmenting some extra data to my archive records which 
> I get from emulated davis loop packaged.
> My file whichs contains always the latest data looks like this:
>
> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_Exp.txt
> So there is written a signal name, a unit group and the actual data as csv.
>
> The data is then augmented with the following script:
>
> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_WeatherDuino_Logger_plugin.py
> called as data service in the weewx.conf
>
> record_generation is set to software, target_unit is set to metric.
>
> The augmented data is in °C and most of the time it is saved to the 
> database without being converted but sometimes a few datasets are double 
> converted.
>
> When record_generation is set to hardware the data is always converted, so 
> I'm exporting the data in US units and weewx converts it back. This is no 
> problem either.
> But it is hard to handle when weewx jumps between no conversion and 
> conversion.
>
> Hopefully it is more clear now what I mean.
>
> Regards,
> engolling
>
>
> Am Montag, 20. Mai 2019 00:49:56 UTC+2 schrieb gjr80:
>>
>> Hi,
>>
>> Perhaps you could give us some more details as to how the extra 
>> temperature data is being obtained/provided/added to WeeWX, happy to see 
>> code/data formats etc - code usually gives an unambiguous picture, 
>> descriptions are often open to interpretation. I am having a little 
>> difficulty understanding how the numeric data is always being received but 
>> not the units, but perhaps that will become clear once you provide some 
>> more detail.
>>
>> Gary
>>
>> On Monday, 20 May 2019 05:55:18 UTC+10, engolling wrote:
>>>
>>> Hello,
>>>
>>> me again :).
>>> Thank you for your last answer Thomas. Works fine.
>>>
>>> Now I have a new "thing" I do not understand.
>>> As discussed above I'm augmenting different data - also rain data to the 
>>> archive records as described in the customization guide.
>>>
>>> I also augment temperature signals and sometimes they are converted to 
>>> metric variables and sometimes not. The problem is the signal is already in 
>>> °C and should be in °C, but if it is converted it looks like this:
>>>
>>>
>>> 
>>> The database is mertric. If I get for examp

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

Gary,

It's late, so I'll respond to the rest later, but...

The problem here is that if we compare our local every 1-minute records to WU's 
query that only shows every 5-minute records, then we'll keep re-uploading the 
the "missing" 1-minute records every time wunderfixer is called.  This amounts 
to pointless hits against WU's infrastructure, since pragmatically it's very 
clear they almost always drop all records not closely aligned to 5-minute 
"buckets."

I'm trying to get to the heart of the matter re: what wunderfixer was really 
designed to do, which is to make sure what we have locally is consistent with 
what WU will actually REPORT, and when there are gaps in what WU *should* 
report, and we have local data to fill in those gaps, then re-upload.  BUT to 
not gratuitously re-upload data that WU generally throws away (they just don't 
seem to care about storing data at < 5-minute intervals).

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 27, 2019, at 12:12 AM, gjr80  wrote:
> 
>> On Monday, 27 May 2019 13:16:53 UTC+10, Leon Shaner wrote:
>> Gary,
>> 
>> In practice, WU seems to discard data that is not close to their APPARENTly 
>> preferred 5-minute "normalization buckets."
>> 
>> I upload via rapidfire *and* regular loop on 1-minute intervals, and 
>> irregardless of same, the queries only ever show the records most closely 
>> aligned to their "preferred" 5-minute "buckets."
>> 
>> I would love to see them preserve the same interval that I upload, but 
>> either by design or omission or bug, they simply don't.  :-(
>> Could be the layers in-between are dropping data by code-exception.
>> Could be it's deliberate.
>> I'm not here to debug their code unless they want to start paying me a 
>> worthy salary. ;-)
>> 
>> Well...  MOST of the time the behavior I have described seems to be true.  
>> :-/
>> 
>> While WU normally SEEMS to only keeps records on 5-minute boundaries, I have 
>> seen where if wunderfixer is used persistently enough (say more than 10 
>> times spread out every 20 minutes across a total span of 200 minutes) then 
>> it will keep records that are more frequent than every 5-minutes.
>> 
>> Right now / especially lately, things are so sporadic with WU that I don't 
>> even want to spend cycles chasing what's really going on there.  I would 
>> rather just only have wunderfixer ignore most records except those nearest 
>> the 5-minute boundaries that WU seems to most care about.
>> 
> 
> Show Quoted Content
>> Gary,
>> 
>> In practice, WU seems to discard data that is not close to their APPARENTly 
>> preferred 5-minute "normalization buckets."
>> 
>> I upload via rapidfire *and* regular loop on 1-minute intervals, and 
>> irregardless of same, the queries only ever show the records most closely 
>> aligned to their "preferred" 5-minute "buckets."
>> 
>> I would love to see them preserve the same interval that I upload, but 
>> either by design or omission or bug, they simply don't.  :-(
>> Could be the layers in-between are dropping data by code-exception.
>> Could be it's deliberate.
>> I'm not here to debug their code unless they want to start paying me a 
>> worthy salary. ;-)
>> 
>> Well...  MOST of the time the behavior I have described seems to be true.  
>> :-/
>> 
>> While WU normally SEEMS to only keeps records on 5-minute boundaries, I have 
>> seen where if wunderfixer is used persistently enough (say more than 10 
>> times spread out every 20 minutes across a total span of 200 minutes) then 
>> it will keep records that are more frequent than every 5-minutes.
>> 
>> Right now / especially lately, things are so sporadic with WU that I don't 
>> even want to spend cycles chasing what's really going on there.  I would 
>> rather just only have wunderfixer ignore most records except those nearest 
>> the 5-minute boundaries that WU seems to most care about.
>> 
> I am not suggesting we/you/anyone should try to solve WU 
> issues/problems/whatever, merely making the point that WU is a blackbox, 
> nobody seems to really know what it does with the data that it is fed. If we 
> are going to have WU recreate/create 'missing' data then the logical approach 
> would be to feed it with the data it was orignally fed rather than trying to 
> guess what it wants.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/8B0BFD31-7D91-4A3D-BDED-8923E8AF0C04%40isylum.org.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Weather34 Template for WeeWX - New Major Update

[Jd D]

Hi Ian,
Also notice some left-over debug code in shared.php that prevents 
Fahrenheit temps from displaying correctly.

*$weather["temp_units"]='C'; *
if ($weather["temp_units"] == 'C'){
$heatIndex = fToCDirect($heatIndex);

Thanks Jerry
 
On Sunday, May 26, 2019 at 7:28:06 PM UTC-7, Jd D wrote:
>
> Hi Ian,
>
> Noticed this in weewxcron.php
>
> if ($position6=="forecast3ds.php" || $position6=='forecast3wu.php' || 
> $position6=='forecast3wularge.php' || *$position4   = "advisory.php")*{
>
> I think you want ==
>
> Also I cleaned up most of my apache errors by making small changes to 
> livedata.php
>
> Thanks Jerry
>
> On Sunday, May 26, 2019 at 11:47:25 AM UTC-7, Jd D wrote:
>>
>> Hi Ian,
>> Right now just using the template for my local weather station and my 
>> nearby metar. 
>> Here is my settings1.php. 
>> I XXed out personal stuff. 
>> Also I tried to use the least number of sections so to reduce the number 
>> of apache errors I am logging.
>> Since I cut and pasted the file into the replay so you can see where the 
>> cut and pastes happen. :-)
>> I can send my w34stats.php file if that would help.
>> I can work these issues if you rather and just send you what I find if 
>> that is a better. I have the time and experience with php/javascript and 
>> python.
>> Thanks Jerry
>>
>>  $apikey = ""; 
>>  $wuapikey = "";
>>  $weatherflowID = "";
>>  $weatherflowoption   = "no";
>>  $weatherflowlightning = "";
>>  $weatherflowmapzoom   = "";
>>  $id = "";
>>  $purpleairID = "";
>>  $purpleairhardware   = "no";
>>  $metarapikey ="";
>>  $TZ = "X";
>>  $UTC = "XX";
>>  $lon = X;
>>  $lat = ;
>>  $darkskyunit   = "us";
>>  $wuapiunit   = "h";
>>  $stationlocation = "XXX";
>>  $stationName = "X";
>>  $moonadj = "";
>>  $minmag = "3";
>>  $unit = "english";
>>  $metric = false;
>>  $elevation = "1792";
>>  $uk = false;
>>  $usa = true;
>>  $scandinavia = false;
>>  $restoftheworld = false;
>>  $windunit = "mph";
>>  $distanceunit = "mi";
>>  $tempunit = "F";
>>  $rainunit  = "in";
>>  $rainrate = "/h";
>>  $pressureunit  = "inHg";
>>  $livedataFormat = "WeeWX-CRT";
>>  $livedata   = "demodata/realtime.txt";
>>  $currentconditions   = "currentconditionsds.php";
>>  $chartsource   = "mbcharts";
>>  $extralinks   = "yes";
>>  $languages   = "no";
>>  $dateFormat   = "m-d-Y";
>>  $timeFormat= "g:i:s a";
>>  $timeFormatShort= "g:i";
>>  $clockformat= "12";
>>  $showDate = false;
>>  $temperaturemodule   = "temperaturein.php";
>>  $position1   = "temperatureyear.php";
>>  $position2   = "temperatureyear.php";
>>  $position3   = "temperatureyear.php";
>>  $position4   = "temperatureyear.php";
>>  $position1title   = "1";
>>  $position2title   = "2"; 
>>  $position3title   = "3";
>>  $position4title   = "4"
>>  $position6title   = "6";
>> $position6   = "";
>>
>>> $position12title   = "12";
>>> $position12   = "indoortemperature.php";
>>> $positionlastmoduletitle   = "l";
>>> $positionlastmodule   = "indoortemperature.php";
>>> $webcamurl   = "";
>>> $email= "";
>>> $twitter   = "";
>>> $theme1   = "dark";
>>> $since= "2016";
>>> $weatherhardware   = "La Crosse";
>>> $mbplatform   = "WeeWX";
>>> $davis   = "No";
>>> $db_host   = "localhost";
>>> $db_user= "root";
>>> $db_pass  = "";
>>> $db_name   = "weatherstation";
>>> $notifications = "yes";
>>> $sunoption = "";
>>> $hemisphere   = "";
>>> $metar   = "yes";
>>> $icao1   = "";
>>> $airport1   = "";
>>> $airport1dist   = "10";
>>> $defaultlanguage   = "en";
>>> $language= "en";
>>> $password= "";
>>> $flag   = "us";
>>> $dshourly   = "no";
>>> $manifestShortName = "";
>>>
>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4ebf7f6b-a6d7-4e89-89b2-d50d1b44d3cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[gjr80]

On Monday, 27 May 2019 13:16:53 UTC+10, Leon Shaner wrote:
>
> Gary,
>
> In practice, WU seems to discard data that is not close to their 
> APPARENTly preferred 5-minute "normalization buckets."
>
> I upload via rapidfire *and* regular loop on 1-minute intervals, and 
> irregardless of same, the queries only ever show the records most closely 
> aligned to their "preferred" 5-minute "buckets."
>
> I would love to see them preserve the same interval that I upload, but 
> either by design or omission or bug, they simply don't.  :-(
> Could be the layers in-between are dropping data by code-exception.
> Could be it's deliberate.
> I'm not here to debug their code unless they want to start paying me a 
> worthy salary. ;-)
>
> Well...  MOST of the time the behavior I have described seems to be true. 
>  :-/
>
> While WU normally SEEMS to only keeps records on 5-minute boundaries, I 
> have seen where if wunderfixer is used persistently enough (say more than 
> 10 times spread out every 20 minutes across a total span of 200 minutes) 
> then it will keep records that are more frequent than every 5-minutes.
>
> Right now / especially lately, things are so sporadic with WU that I don't 
> even want to spend cycles chasing what's really going on there.  I would 
> rather just only have wunderfixer ignore most records except those nearest 
> the 5-minute boundaries that WU seems to most care about.
>
> I am not suggesting we/you/anyone should try to solve WU 
issues/problems/whatever, merely making the point that WU is a blackbox, 
nobody seems to really know what it does with the data that it is fed. If 
we are going to have WU recreate/create 'missing' data then the logical 
approach would be to feed it with the data it was orignally fed rather than 
trying to guess what it wants.
 

> I have just now solved the "align to 5-minute boundaries" exercise with:
>
> _gen_rows =  dbmanager.genSql("""SELECT dateTime FROM archive WHERE 
> dateTime>=? AND dateTime   (start_ts, end_ts))
>
> Example:
>
> $ /usr/share/weewx4/bin/wunderfixer_403 --epsilon=125 --date=2019-05-25 
> --test --verbose | head -30
> Using configuration file /usr/share/weewx4/weewx.conf.
> Using database binding 'wx_binding', which is bound to database 
> 'archive_sqlite'
> Weather Underground Station:   KMIDEARB5
> Date to check: 2019-05-25
> Number of archive records: 289
> Number of WU records:  260
> Number of missing records: 288
>
> Missing records:
> 2019-05-25 00:05:00 EDT (1558757100); 29.326";  61.3F;  76%; 0.0 mph; N/A 
> deg; 3.6 mph gust;  53.7F; 0.00" rain  ... skipped.
> 2019-05-25 00:10:00 EDT (1558757400); 29.326";  61.2F;  76%; 0.0 mph; N/A 
> deg; 2.0 mph gust;  53.5F; 0.00" rain  ... skipped.
> 2019-05-25 00:15:00 EDT (1558757700); 29.326";  61.2F;  76%; 1.3 mph;  93 
> deg; 3.1 mph gust;  53.5F; 0.00" rain  ... skipped.
> 2019-05-25 00:20:00 EDT (1558758000); 29.317";  61.1F;  76%; 1.3 mph;  93 
> deg; 2.5 mph gust;  53.5F; 0.00" rain  ... skipped.
> 2019-05-25 00:25:00 EDT (1558758300); 29.317";  61.0F;  77%; 1.3 mph; 121 
> deg; 4.3 mph gust;  53.7F; 0.00" rain  ... skipped.
> 2019-05-25 00:30:00 EDT (1558758600); 29.317";  61.0F;  76%; 1.3 mph; 121 
> deg; 3.6 mph gust;  53.4F; 0.00" rain  ... skipped.
> 2019-05-25 00:35:00 EDT (1558758900); 29.309";  61.0F;  77%; 1.8 mph; 112 
> deg; 4.0 mph gust;  53.7F; 0.00" rain  ... skipped.
> 2019-05-25 00:40:00 EDT (1558759200); 29.309";  60.9F;  76%; 1.8 mph; 112 
> deg; 3.1 mph gust;  53.3F; 0.00" rain  ... skipped.
> 2019-05-25 00:45:00 EDT (1558759500); 29.309";  60.7F;  77%; 1.8 mph; 116 
> deg; 5.8 mph gust;  53.3F; 0.00" rain  ... skipped.
> 2019-05-25 00:50:00 EDT (1558759800); 29.306";  60.6F;  77%; 1.8 mph; 116 
> deg; 5.1 mph gust;  53.4F; 0.00" rain  ... skipped.
> 2019-05-25 00:55:00 EDT (1558760100); 29.306";  60.6F;  77%; 2.5 mph; 113 
> deg; 2.9 mph gust;  53.4F; 0.00" rain  ... skipped.
> 2019-05-25 01:00:00 EDT (1558760400); 29.306";  60.5F;  77%; 2.5 mph; 113 
> deg; 2.5 mph gust;  53.3F; 0.00" rain  ... skipped.
> 2019-05-25 01:05:00 EDT (1558760700); 29.303";  60.5F;  77%; 1.3 mph; 120 
> deg; 3.6 mph gust;  53.2F; 0.00" rain  ... skipped.
> 2019-05-25 01:10:00 EDT (1558761000); 29.303";  60.4F;  78%; 1.3 mph; 120 
> deg; 1.3 mph gust;  53.5F; 0.00" rain  ... skipped.
> 2019-05-25 01:15:00 EDT (1558761300); 29.303";  60.4F;  78%; 1.3 mph; 110 
> deg; 4.7 mph gust;  53.5F; 0.00" rain  ... skipped.
> 2019-05-25 01:20:00 EDT (1558761600); 29.285";  60.4F;  78%; 1.3 mph; 110 
> deg; 5.1 mph gust;  53.5F; 0.00" rain  ... skipped.
> 2019-05-25 01:25:00 EDT (1558761900); 29.285";  60.3F;  78%; 2.0 mph; 102 
> deg; 3.1 mph gust;  53.4F; 0.00" rain  ... skipped.
> 2019-05-25 01:30:00 EDT (1558762200); 29.285";  60.3F;  78%; 2.0 mph; 102 
> deg; 5.4 mph gust;  53.4F; 0.00" rain  ... skipped.
> 2019-05-25 01:35:00 EDT (1558762500); 29.282";  60.2F;  78%; 2.5 mph; 123 
> deg; 2.5 mph gust;  53.3F; 0.00" rain  ... 

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

Gary,

In practice, WU seems to discard data that is not close to their APPARENTly 
preferred 5-minute "normalization buckets."

I upload via rapidfire *and* regular loop on 1-minute intervals, and 
irregardless of same, the queries only ever show the records most closely 
aligned to their "preferred" 5-minute "buckets."

I would love to see them preserve the same interval that I upload, but either 
by design or omission or bug, they simply don't.  :-(
Could be the layers in-between are dropping data by code-exception.
Could be it's deliberate.
I'm not here to debug their code unless they want to start paying me a worthy 
salary. ;-)

Well...  MOST of the time the behavior I have described seems to be true.  :-/

While WU normally SEEMS to only keeps records on 5-minute boundaries, I have 
seen where if wunderfixer is used persistently enough (say more than 10 times 
spread out every 20 minutes across a total span of 200 minutes) then it will 
keep records that are more frequent than every 5-minutes.

Right now / especially lately, things are so sporadic with WU that I don't even 
want to spend cycles chasing what's really going on there.  I would rather just 
only have wunderfixer ignore most records except those nearest the 5-minute 
boundaries that WU seems to most care about.

I have just now solved the "align to 5-minute boundaries" exercise with:

_gen_rows =  dbmanager.genSql("""SELECT dateTime FROM archive WHERE dateTime>=? 
AND dateTime On May 26, 2019, at 10:59 PM, gjr80  wrote:
> 
>> On Saturday, 25 May 2019 22:54:25 UTC+10, Leon Shaner wrote:
>> 
>> There is no point re-uploading 00:00:00, then 00:01:00, then 00:02:00, 
>> because WU is only going to keep 00:00:00, and then later it will keep 
>> whatever is closest to 00:05:00.   That's been the behavior of wunderfixer 
>> vs. WU for as long as I've been working with it, however.  :-/
> 
> Maybe, maybe not. The problem is WU acts as a black box that accepts your 
> data at (more or less) whatever interval you choose WU then does who knows 
> what with the data and (usually) 5 minute interval records appear. You could 
> argue that re-uploading of data should be done in the same manner as it was 
> originally uploaded.
> 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/c3476bc2-674f-4928-bf58-55f2150159b2%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/309313C3-2AD2-43B4-941C-7BBD90DB35C8%40isylum.org.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[gjr80]

On Saturday, 25 May 2019 22:54:25 UTC+10, Leon Shaner wrote:
>
>
> There is no point re-uploading 00:00:00, then 00:01:00, then 00:02:00, 
> because WU is only going to keep 00:00:00, and then later it will keep 
> whatever is closest to 00:05:00.   That's been the behavior of wunderfixer 
> vs. WU for as long as I've been working with it, however.  :-/
>

Maybe, maybe not. The problem is WU acts as a black box that accepts your 
data at (more or less) whatever interval you choose WU then does who knows 
what with the data and (usually) 5 minute interval records appear. You 
could argue that re-uploading of data should be done in the same manner as 
it was originally uploaded.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c3476bc2-674f-4928-bf58-55f2150159b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: csv.py don't add radiation and UV

[gjr80]

Hi,

Your 'fix' has merely forced the csv service to always generate data.csv 
based on archive records rather than the default loop packets. Using 
archive records rather than loop packets would make sense for a station 
that emits partial loop packets (ie a station that does not include 
radiation and UV in every loop packet) but based on the log extract you 
provided your station does not appear to be a partial packet type. In any 
case, if generating data.csv based on archive records rather than loop 
packets solves your problem a far better approach would be to return csv.py 
to its original state and change your [CSV] stanza in weewx.conf to read:

[CSV]
filename = /var/tmp/tmp/data.csv
binding = archive

This will require a WeeWX restart. This achieves the same effect as your 
changes whilst ensuring your system will continue to work across future 
upgrades.

Gary


On Sunday, 26 May 2019 16:48:16 UTC+10, JanC wrote:
>
> I found the solution myself.
>
> In csv.py :
>
> if self.binding == 'binding':
>
>
> self.binding = d.get('binding', 'loop')
>  ##   if self.binding == 'loop':
> if self.binding == 'binding':
> self.bind(weewx.NEW_LOOP_PACKET, self.handle_new_loop)
> else:
> self.bind(weewx.NEW_ARCHIVE_RECORD, self.handle_new_archive)
>
> janc
>
> Op zaterdag 25 mei 2019 11:39:11 UTC+2 schreef JanC:
>>
>> I use a WH2600 weatherstation with a raspberry pi
>>
>> debian8
>> weewx 3.9.1
>> driver interceptor observer
>> csv.py to collect the data to a csv-file
>>
>> with weewx 3.8 it works ok, after upgrade to 3.9 it fails
>>
>> I have some things overlooked?
>>
>> JanC
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ce9f2ae8-f603-4189-a6e3-139dfeaec064%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Weather34 Template for WeeWX - New Major Update

[Jd D]

Hi Ian,

Noticed this in weewxcron.php

if ($position6=="forecast3ds.php" || $position6=='forecast3wu.php' || 
$position6=='forecast3wularge.php' || *$position4   = "advisory.php")*{

I think you want ==

Also I cleaned up most of my apache errors by making small changes to 
livedata.php

Thanks Jerry

On Sunday, May 26, 2019 at 11:47:25 AM UTC-7, Jd D wrote:
>
> Hi Ian,
> Right now just using the template for my local weather station and my 
> nearby metar. 
> Here is my settings1.php. 
> I XXed out personal stuff. 
> Also I tried to use the least number of sections so to reduce the number 
> of apache errors I am logging.
> Since I cut and pasted the file into the replay so you can see where the 
> cut and pastes happen. :-)
> I can send my w34stats.php file if that would help.
> I can work these issues if you rather and just send you what I find if 
> that is a better. I have the time and experience with php/javascript and 
> python.
> Thanks Jerry
>
>  $apikey = ""; 
>  $wuapikey = "";
>  $weatherflowID = "";
>  $weatherflowoption   = "no";
>  $weatherflowlightning = "";
>  $weatherflowmapzoom   = "";
>  $id = "";
>  $purpleairID = "";
>  $purpleairhardware   = "no";
>  $metarapikey ="";
>  $TZ = "X";
>  $UTC = "XX";
>  $lon = X;
>  $lat = ;
>  $darkskyunit   = "us";
>  $wuapiunit   = "h";
>  $stationlocation = "XXX";
>  $stationName = "X";
>  $moonadj = "";
>  $minmag = "3";
>  $unit = "english";
>  $metric = false;
>  $elevation = "1792";
>  $uk = false;
>  $usa = true;
>  $scandinavia = false;
>  $restoftheworld = false;
>  $windunit = "mph";
>  $distanceunit = "mi";
>  $tempunit = "F";
>  $rainunit  = "in";
>  $rainrate = "/h";
>  $pressureunit  = "inHg";
>  $livedataFormat = "WeeWX-CRT";
>  $livedata   = "demodata/realtime.txt";
>  $currentconditions   = "currentconditionsds.php";
>  $chartsource   = "mbcharts";
>  $extralinks   = "yes";
>  $languages   = "no";
>  $dateFormat   = "m-d-Y";
>  $timeFormat= "g:i:s a";
>  $timeFormatShort= "g:i";
>  $clockformat= "12";
>  $showDate = false;
>  $temperaturemodule   = "temperaturein.php";
>  $position1   = "temperatureyear.php";
>  $position2   = "temperatureyear.php";
>  $position3   = "temperatureyear.php";
>  $position4   = "temperatureyear.php";
>  $position1title   = "1";
>  $position2title   = "2"; 
>  $position3title   = "3";
>  $position4title   = "4"
>  $position6title   = "6";
> $position6   = "";
>
>> $position12title   = "12";
>> $position12   = "indoortemperature.php";
>> $positionlastmoduletitle   = "l";
>> $positionlastmodule   = "indoortemperature.php";
>> $webcamurl   = "";
>> $email= "";
>> $twitter   = "";
>> $theme1   = "dark";
>> $since= "2016";
>> $weatherhardware   = "La Crosse";
>> $mbplatform   = "WeeWX";
>> $davis   = "No";
>> $db_host   = "localhost";
>> $db_user= "root";
>> $db_pass  = "";
>> $db_name   = "weatherstation";
>> $notifications = "yes";
>> $sunoption = "";
>> $hemisphere   = "";
>> $metar   = "yes";
>> $icao1   = "";
>> $airport1   = "";
>> $airport1dist   = "10";
>> $defaultlanguage   = "en";
>> $language= "en";
>> $password= "";
>> $flag   = "us";
>> $dshourly   = "no";
>> $manifestShortName = "";
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e0799a00-01e7-4f85-9364-a61a8ebb5cc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Add additional rain gauge via second data source

[engolling]

Hello Andrew,
indeed it actually is only augmenting.
But in case the archive data is gained from a DMPAFT packet it seems to be 
converted complete after augmenting. If the archive data is gained from a 
LOOP packet it converted before.

So the following things would probably solve the issue:
 - Only using record generation hardare
 - Database in US units

My intention is that my plugin works with any configuration, so I would 
like to work out an solution for this. So my idea would be to find an 
indicator of the archive data is gained from an LOOP packet or a DMPAFT 
packet - so conversion could be done if necessary.

Regards,
engolling

Am Sonntag, 26. Mai 2019 13:53:46 UTC+2 schrieb Andrew Milner:
>
> The script you posted SHOULD only be augmenting  REC packets, and not be 
> affected by any LOOP packets.
>
> Maybe you should set record generation to either use hardware or use 
> software and not prefer hardware or prefer software.  Your augmented data 
> should be use software I would have thought
>
>
>
>
>
> On Sunday, 26 May 2019 13:37:27 UTC+3, engolling wrote:
>>
>> Hallo,
>> think I tracked the issue down.
>> First it starts with record generation software.
>>
>> So each time a archive dataset is retreivedn form the hardware logger my 
>> data is augmented and then it runs apparently through the unit converter, 
>> converting it to metric units (in case of my augmented data coming in 
>> metric this is bad).
>> This happens whenn WeeWx was off for some time.
>> Each time an archive paket is gained from the LOOP data it was seemingly 
>> already converted my data is augmented and it is saved correctly to the 
>> database.
>>
>> So my question is simplified. Is it possible to determine if a archive 
>> record is archived of hardware logger data or LOOP data or can I influence 
>> the order of augmenting and converting?
>>
>> Best regards, 
>> engolling
>>
>> Am Mittwoch, 22. Mai 2019 23:20:08 UTC+2 schrieb engolling:
>>>
>>> Hello,
>>>
>>> of course I can give more details :-)
>>>
>>> So as you know I'm augmenting some extra data to my archive records 
>>> which I get from emulated davis loop packaged.
>>> My file whichs contains always the latest data looks like this:
>>>
>>> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_Exp.txt
>>> So there is written a signal name, a unit group and the actual data as 
>>> csv.
>>>
>>> The data is then augmented with the following script:
>>>
>>> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_WeatherDuino_Logger_plugin.py
>>> called as data service in the weewx.conf
>>>
>>> record_generation is set to software, target_unit is set to metric.
>>>
>>> The augmented data is in °C and most of the time it is saved to the 
>>> database without being converted but sometimes a few datasets are double 
>>> converted.
>>>
>>> When record_generation is set to hardware the data is always converted, 
>>> so I'm exporting the data in US units and weewx converts it back. This is 
>>> no problem either.
>>> But it is hard to handle when weewx jumps between no conversion and 
>>> conversion.
>>>
>>> Hopefully it is more clear now what I mean.
>>>
>>> Regards,
>>> engolling
>>>
>>>
>>> Am Montag, 20. Mai 2019 00:49:56 UTC+2 schrieb gjr80:

 Hi,

 Perhaps you could give us some more details as to how the extra 
 temperature data is being obtained/provided/added to WeeWX, happy to see 
 code/data formats etc - code usually gives an unambiguous picture, 
 descriptions are often open to interpretation. I am having a little 
 difficulty understanding how the numeric data is always being received but 
 not the units, but perhaps that will become clear once you provide some 
 more detail.

 Gary

 On Monday, 20 May 2019 05:55:18 UTC+10, engolling wrote:
>
> Hello,
>
> me again :).
> Thank you for your last answer Thomas. Works fine.
>
> Now I have a new "thing" I do not understand.
> As discussed above I'm augmenting different data - also rain data to 
> the archive records as described in the customization guide.
>
> I also augment temperature signals and sometimes they are converted to 
> metric variables and sometimes not. The problem is the signal is already 
> in 
> °C and should be in °C, but if it is converted it looks like this:
>
>
> 
> The database is mertric. If I get for example a temperature of 22.61°C 
> which should be imported into the database directly and it is most time. 
> But sometimes I get -5.21°C (which is the result of the Farenheit Celsius 
> conversion of 22.61°C).
>
> My Raspberry Pi has a bad WIFI internet connection and FTP often fails 
> and it seems to be related to this.
>
> Could this be a reason and do you know how

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

Tested on 4.x (python 2 and 3) and 3.9.x. (python 2).

Ultimately went with apikey instead of apiKey in weewx.conf, which was to be 
more consistent with other parameter names.

If you are willing to pass "--apikey=0123456789012345678901" on wunderfixer 
command-line, then you only need wunderfixer.

Unrelated to these changes, FYI you probably also want --epsilon=125 because of 
silly WU "rounding" errors on fractional minutes.

If you wish to put "apikey=0123456789012345678901" in the WU section of 
weewx.conf, then you also need restx.py.

API Key is generated in the "Member Settings" section of wunderground.com ("My 
Profile" > "Member Settings" > "API Keys").

3.9.x:
https://github.com/UberEclectic/weewx/blob/master/bin/wunderfixer

https://github.com/UberEclectic/weewx/blob/master/bin/weewx/restx.py

4.x:
https://github.com/UberEclectic/weewx/blob/development/bin/wunderfixer

https://github.com/UberEclectic/weewx/blob/development/bin/weewx/restx.py

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 25, 2019, at 8:54 AM, Leon Shaner  wrote:
> 
> So this is where I am...
> These all seem reasonable (but then scroll for the problem which starts with 
> yesterday's date):
> 
> pi@nixie:/usr/share/weewx4/bin $ ./wunderfixer --epsilon=125 
> --date=2019-05-21 --test --verbose | more
> Using configuration file /usr/share/weewx4/weewx.conf.
> Using database binding 'wx_binding', which is bound to database 
> 'archive_sqlite'
> Weather Underground Station:   KMIDEARB5
> Date to check: 2019-05-21
> Number of archive records: 1440
> Number of WU records:  288
> Number of missing records: 4
> 
> Missing records:
> 2019-05-21 00:00:00 EDT (1558411200); 29.379";  49.8F;  78%; 0.0 mph; N/A 
> deg; 0.0 mph gust;  43.2F; 0.00" rain  ... skipped.
> 2019-05-21 00:01:00 EDT (1558411260); 29.379";  49.7F;  78%; 0.0 mph; N/A 
> deg; 0.0 mph gust;  43.2F; 0.00" rain  ... skipped.
> 2019-05-21 00:02:00 EDT (1558411320); 29.379";  49.6F;  78%; 0.0 mph; N/A 
> deg; 0.0 mph gust;  43.1F; 0.00" rain  ... skipped.
> 2019-05-21 22:42:00 EDT (1558492920); 29.406";  55.4F;  67%; 1.3 mph;  68 
> deg; 0.0 mph gust;  44.6F; 0.00" rain  ... skipped.
> pi@nixie:/usr/share/weewx4/bin $ ./wunderfixer --epsilon=125 
> --date=2019-05-22 --test --verbose | more
> Using configuration file /usr/share/weewx4/weewx.conf.
> Using database binding 'wx_binding', which is bound to database 
> 'archive_sqlite'
> Weather Underground Station:   KMIDEARB5
> Date to check: 2019-05-22
> Number of archive records: 1440
> Number of WU records:  288
> Number of missing records: 3
> 
> Missing records:
> 2019-05-22 00:00:00 EDT (1558497600); 29.406";  54.0F;  65%; 2.0 mph;  76 
> deg; 3.6 mph gust;  42.5F; 0.00" rain  ... skipped.
> 2019-05-22 00:01:00 EDT (1558497660); 29.406";  54.0F;  65%; 2.3 mph;  64 
> deg; 2.5 mph gust;  42.5F; 0.00" rain  ... skipped.
> 2019-05-22 00:02:00 EDT (1558497720); 29.406";  54.0F;  65%; 2.5 mph;  61 
> deg; 2.9 mph gust;  42.5F; 0.00" rain  ... skipped.
> pi@nixie:/usr/share/weewx4/bin $ ./wunderfixer --epsilon=125 
> --date=2019-05-23 --test --verbose | more
> Using configuration file /usr/share/weewx4/weewx.conf.
> Using database binding 'wx_binding', which is bound to database 
> 'archive_sqlite'
> Weather Underground Station:   KMIDEARB5
> Date to check: 2019-05-23
> Number of archive records: 1438
> Number of WU records:  288
> Number of missing records: 4
> 
> Missing records:
> 2019-05-23 00:00:00 EDT (1558584000); 29.244";  59.9F;  90%; 1.3 mph; 158 
> deg; 1.8 mph gust;  56.9F; 0.00" rain  ... skipped.
> 2019-05-23 00:01:00 EDT (1558584060); 29.244";  59.8F;  90%; 1.3 mph; 159 
> deg; 1.8 mph gust;  56.8F; 0.00" rain  ... skipped.
> 2019-05-23 00:02:00 EDT (1558584120); 29.244";  59.7F;  90%; 1.3 mph; 160 
> deg; 1.3 mph gust;  56.8F; 0.00" rain  ... skipped.
> 2019-05-23 14:52:00 EDT (1558637520); 29.161";  83.8F;  46%; 3.6 mph; 248 
> deg;12.3 mph gust;  60.8F; 0.00" rain  ... skipped.
> 
> 
> Using configuration file /usr/share/weewx4/weewx.conf.
> Using database binding 'wx_binding', which is bound to database 
> 'archive_sqlite'
> Weather Underground Station:   KMIDEARB5
> Date to check: 2019-05-24
> Number of archive records: 1436
> Number of WU records:  260
> Number of missing records: 149
> 
> Missing records:
> 2019-05-24 00:00:00 EDT (1558670400); 29.320";  63.0F;  70%; 0.0 mph; N/A 
> deg; 0.0 mph gust;  52.9F; 0.00" rain  ... skipped.
> 2019-05-24 00:01:00 EDT (1558670460); 29.320";  63.0F;  70%; 0.0 mph; N/A 
> deg; 0.0 mph gust;  52.9F; 0.00" rain  ... skipped.
> 2019-05-24 00:02:00 EDT (1558670520); 29.320";  63.0F;  70%; 0.0 mph; N/A 
> deg; 0.0 mph gust;  52.9F; 0.00" rain  ... skipped.
> 2019-05-24 18:22:00 EDT (1558736520); 29.359";  67.5F;  68%; 2.5 mph;  99 
> deg; 5.1 mph gust;  56.5F; 0.00" rain  ... skipped.
> 2019-05-24 18:40:00 EDT (15587376

Re: [weewx-user] Re: Weather34 Template for WeeWX - New Major Update

[Jd D]

Hi Ian,
Right now just using the template for my local weather station and my 
nearby metar. 
Here is my settings1.php. 
I XXed out personal stuff. 
Also I tried to use the least number of sections so to reduce the number of 
apache errors I am logging.
Since I cut and pasted the file into the replay so you can see where the 
cut and pastes happen. :-)
I can send my w34stats.php file if that would help.
I can work these issues if you rather and just send you what I find if that 
is a better. I have the time and experience with php/javascript and python.
Thanks Jerry

 $apikey = ""; 
 $wuapikey = "";
 $weatherflowID = "";
 $weatherflowoption   = "no";
 $weatherflowlightning = "";
 $weatherflowmapzoom   = "";
 $id = "";
 $purpleairID = "";
 $purpleairhardware   = "no";
 $metarapikey ="";
 $TZ = "X";
 $UTC = "XX";
 $lon = X;
 $lat = ;
 $darkskyunit   = "us";
 $wuapiunit   = "h";
 $stationlocation = "XXX";
 $stationName = "X";
 $moonadj = "";
 $minmag = "3";
 $unit = "english";
 $metric = false;
 $elevation = "1792";
 $uk = false;
 $usa = true;
 $scandinavia = false;
 $restoftheworld = false;
 $windunit = "mph";
 $distanceunit = "mi";
 $tempunit = "F";
 $rainunit  = "in";
 $rainrate = "/h";
 $pressureunit  = "inHg";
 $livedataFormat = "WeeWX-CRT";
 $livedata   = "demodata/realtime.txt";
 $currentconditions   = "currentconditionsds.php";
 $chartsource   = "mbcharts";
 $extralinks   = "yes";
 $languages   = "no";
 $dateFormat   = "m-d-Y";
 $timeFormat= "g:i:s a";
 $timeFormatShort= "g:i";
 $clockformat= "12";
 $showDate = false;
 $temperaturemodule   = "temperaturein.php";
 $position1   = "temperatureyear.php";
 $position2   = "temperatureyear.php";
 $position3   = "temperatureyear.php";
 $position4   = "temperatureyear.php";
 $position1title   = "1";
 $position2title   = "2"; 
 $position3title   = "3";
 $position4title   = "4"
 $position6title   = "6";
$position6   = "";

> $position12title   = "12";
> $position12   = "indoortemperature.php";
> $positionlastmoduletitle   = "l";
> $positionlastmodule   = "indoortemperature.php";
> $webcamurl   = "";
> $email= "";
> $twitter   = "";
> $theme1   = "dark";
> $since= "2016";
> $weatherhardware   = "La Crosse";
> $mbplatform   = "WeeWX";
> $davis   = "No";
> $db_host   = "localhost";
> $db_user= "root";
> $db_pass  = "";
> $db_name   = "weatherstation";
> $notifications = "yes";
> $sunoption = "";
> $hemisphere   = "";
> $metar   = "yes";
> $icao1   = "";
> $airport1   = "";
> $airport1dist   = "10";
> $defaultlanguage   = "en";
> $language= "en";
> $password= "";
> $flag   = "us";
> $dshourly   = "no";
> $manifestShortName = "";
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5d103a7d-28ba-43cb-a962-d09c32ce46f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Weather34 Template for WeeWX - New Major Update

[steeple ian]

Can you expand on that please. Do you mean that you are deliberately not using 
WU or DS for forecasting, just your local metar?

Sent from my iPhone

> On 26 May 2019, at 18:25, Jd D  wrote:
> 
> Hi,
> No WU
> No DS
> Just local metar.
> 
> Thanks Jerry
> 
>> On Sunday, May 26, 2019 at 9:35:48 AM UTC-7, steeple ian wrote:
>> Hi Jerry,
>> 
>> Are you using the Weather Underground forecasts? If so have you got one of 
>> the new API keys? If so have you entered correctly in the settings?
>> 
>> Ian
>> 
>>> On Sun, May 26, 2019 at 6:09 AM Jd D  wrote:
>>> Hi Ian,
>>> 
>>> So I decided to do a new install of both weewx and the very latest 
>>> Weather34 Template (just got tonight) on another raspberry Pi to test 
>>> things. Since I have only one weather station I choose the interceptor 
>>> driver on the new system (did some minor changes to it so it could handle 
>>> 2316 weather data) and then wrote a weewx service called post_loop_packet 
>>> to send the loop data to the interceptor driver. All works just fine and 
>>> have two different versions of the weewx running. I also check the 
>>> w34stats.php and the issue with the format function is gone and the 
>>> template does work in some places. But there is a flood of errors in the 
>>> apache error log. I will include part of the log after this. Some of errors 
>>> seems to be not handling data that N/A. Like in the solar section, I do not 
>>> have solar but the php tries to convert N/A to a number. Here are some log 
>>> snippets.
>>> Hope this helps.
>>> Jerry
>>> 
 [Sat May 25 06:25:08.334215 2019] [mpm_prefork:notice] [pid 703] AH00163: 
 Apache/2.4.25 (Raspbian) c[Sat May 25 21:46:52.967308 2019] [:error] [pid 
 10633] [client 192.168.0.39:61452] PHP Warning:  number_format() expects 
 parameter 1 to be float, string given in /var/www/html/pws/livedata.php on 
 line 92, referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967308 2019] [:error] [pid 10586] [client 
 192.168.0.39:61456] PHP Warning:  number_format() expects parameter 1 to 
 be float, string given in /var/www/html/pws/livedata.php on line 92, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967406 2019] [:error] [pid 10583] [client 
 192.168.0.39:61457] PHP Warning:  number_format() expects parameter 1 to 
 be float, string given in /var/www/html/pws/livedata.php on line 92, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967545 2019] [:error] [pid 10633] [client 
 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 96, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967575 2019] [:error] [pid 10586] [client 
 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 96, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967613 2019] [:error] [pid 10583] [client 
 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 96, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967617 2019] [:error] [pid 10633] [client 
 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 97, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967642 2019] [:error] [pid 10586] [client 
 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 97, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967680 2019] [:error] [pid 10583] [client 
 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 97, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967700 2019] [:error] [pid 10633] [client 
 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 98, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967718 2019] [:error] [pid 10586] [client 
 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 98, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967743 2019] [:error] [pid 10583] [client 
 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be 
 integer, string given in /var/www/html/pws/livedata.php on line 98, 
 referer: http://192.168.0.21:88/pws/?units=us
 [Sat May 25 21:46:52.967763 2019] [:error] [pid 10633] [client 
 192.168.0.39:61452] PHP Warning:  date() expect

Re: [weewx-user] Re: Fresh install of weewx 3.9.1 with WMR300A on RPI, Non-positive value for record field 'interval': 0.0

[Miguel Angel Peña Morales]

Also, are there any other USB devices connected?
No
How long is your USB cable that connects to the WMR300?
Is a standard cable. 1m or so. It worked before with a weather 
display setup.
Are you using an official Raspberry Pi power supply or another brand?
Im using a Samsung brand PS. Shoud be enough to run as no message 
of not enough juice is showing.
(Newer RPI's draw up to 2.5amps, so it matters)...

pi@raspberrypi:~ $ dmesg | grep "Machine model"
[0.00] OF: fdt: Machine model: Raspberry Pi 3 Model B Rev 1.2

pi@raspberrypi:~ $  uname -a
Linux raspberrypi 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l 
GNU/Linux

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/";
SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";

pi@raspberrypi:~ $ cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4


processor   : 1
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4


processor   : 2
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4


processor   : 3
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4


Hardware: BCM2835
Revision: a22082
Serial  : e4f0db99

pi@raspberrypi:~ $ head -3 /proc/meminfo
MemTotal: 948304 kB
MemFree:  548404 kB
MemAvailable: 723760 kB
pi@raspberrypi:~ $ htop



  1  [|||   2.9%]   Tasks: 62, 
59 thr; 1 running
  2  [| 0.7%]   Load average
: 0.41 0.54 0.50
  3  [  0.0%]   Uptime: 05:
46:29
  4  [  0.0%]
  Mem[|||  169M/926M]
  Swp[ 0K/100.0M]


  PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
1 root   20   0 27136  6132  4880 S  0.0  0.6  0:06.25 /sbin/init
 1245 root   20   0  108M 69052  8748 S 32.0  7.3  2h23:24 ├─ python /
usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /e
 1252 root   20   0  108M 69052  8748 S  0.0  7.3  0:03.03 │  ├─ python 
/usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid
 1251 root   20   0  108M 69052  8748 S  0.0  7.3  0:00.05 │  ├─ python 
/usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid
 1250 root   20   0  108M 69052  8748 S  0.0  7.3  0:00.00 │  └─ python 
/usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid
  794 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.34 ├─ /usr/lib/
udisks2/udisksd --no-debug
  802 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.00 │  ├─ /usr/
lib/udisks2/udisksd --no-debug
  801 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.00 │  ├─ /usr/
lib/udisks2/udisksd --no-debug
  800 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.01 │  ├─ /usr/
lib/udisks2/udisksd --no-debug
  796 root   20   0 59220  8680  7148 S  0.0  0.9  0:00.00 │  └─ /usr/
lib/udisks2/udisksd --no-debug
  733 pi 20   0 28440  6136  5640 S  0.0  0.6  0:00.08 ├─ /usr/lib/
menu-cache/menu-cached /run/user/1000/menu-cached-:0
  736 pi 20   0 28440  6136  5640 S  0.0  0.6  0:00.00 │  ├─ /usr/
lib/menu-cache/menu-cached /run/user/1000/menu-cached-:
  735 pi 20   0 28440  6136  5640 S  0.0  0.6  0:00.00 │  └─ /usr/
lib/menu-cache/menu-cached /run/user/1000/menu-cached-:
  716 root   20   0 40196  7420  6696 S  0.0  0.8  0:00.15 ├─ /usr/lib/
policykit-1/polkitd --no-debug
  719 root   20   0 40196  7420  6696 S  0.0  0.8  0:00.02 │  ├─ /usr/
lib/policykit-1/polkitd --no-debug
  717 root   20   0 40196  7420  6696 S  0.0  0.8  0:00.00 │  └─ /usr/
lib/policykit-1/polkitd --no-debug
  708 pi 20   0  3788   22016 S  0.0  0.0  0:00.00 ├─ /usr/bin/
ssh-agent -s
  604 root   20   0 35044  3520  320

[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2

[kobuki]

That's an interesting idea. You might be able to use the console connector 
present on every SIM board to capture the same packets that are sent out on 
radio - *if* it's only the original radio that's dead. The only issue is 
the power consumption of the ESP32. Whatever ULP mode it has, WiFi will 
always consume orders of magnitude higher than an RFM module.

On Sunday, May 26, 2019 at 7:20:36 PM UTC+2, John wrote:
>
> Thanks for the pointer to the RFM69 discussions.
>>>
>>
> Now I am thinking of a change in strategy and just putting one of the 
> ESP32+RFM95W dev boards into the ISS and send the data out directly, 
> alternating between moderate range LoRa <-> LoRa peers and occasionally to 
> a distant LoRaWAN gateway.  The ESP32/LoRa module looks to have a very low 
> power mode (ULP) suitable for battery / solar operation. I have an dead ISS 
> that I thought was only good for parts that I may be able to bring back to 
> life with a new cpu/radio and deploy to the ranch cabin. 
>
>
> https://github.com/LilyGO/TTGO-LORA32-V2.0
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/00d635fd-742f-4fac-b542-3dc61c5f2c59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Weather34 Template for WeeWX - New Major Update

[Jd D]

Hi,
No WU
No DS
Just local metar.

Thanks Jerry

On Sunday, May 26, 2019 at 9:35:48 AM UTC-7, steeple ian wrote:
>
> Hi Jerry,
>
> Are you using the Weather Underground forecasts? If so have you got one of 
> the new API keys? If so have you entered correctly in the settings?
>
> Ian
>
> On Sun, May 26, 2019 at 6:09 AM Jd D > 
> wrote:
>
>> Hi Ian,
>>
>> So I decided to do a new install of both weewx and the very latest 
>> Weather34 Template (just got tonight) on another raspberry Pi to test 
>> things. Since I have only one weather station I choose the interceptor 
>> driver on the new system (did some minor changes to it so it could handle 
>> 2316 weather data) and then wrote a weewx service called post_loop_packet 
>> to send the loop data to the interceptor driver. All works just fine and 
>> have two different versions of the weewx running. I also check the 
>> w34stats.php and the issue with the format function is gone and the 
>> template does work in some places. But there is a flood of errors in the 
>> apache error log. I will include part of the log after this. Some of errors 
>> seems to be not handling data that N/A. Like in the solar section, I do not 
>> have solar but the php tries to convert N/A to a number. Here are some log 
>> snippets.
>> Hope this helps.
>> Jerry
>>
>> [Sat May 25 06:25:08.334215 2019] [mpm_prefork:notice] [pid 703] AH00163: 
>>> Apache/2.4.25 (Raspbian) c[Sat May 25 21:46:52.967308 2019] [:error] [pid 
>>> 10633] [client 192.168.0.39:61452] PHP Warning:  number_format() 
>>> expects parameter 1 to be float, string given in 
>>> /var/www/html/pws/livedata.php on line 92, referer: 
>>> http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967308 2019] [:error] [pid 10586] [client 
>>> 192.168.0.39:61456] PHP Warning:  number_format() expects parameter 1 
>>> to be float, string given in /var/www/html/pws/livedata.php on line 92, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967406 2019] [:error] [pid 10583] [client 
>>> 192.168.0.39:61457] PHP Warning:  number_format() expects parameter 1 
>>> to be float, string given in /var/www/html/pws/livedata.php on line 92, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967545 2019] [:error] [pid 10633] [client 
>>> 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 96, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967575 2019] [:error] [pid 10586] [client 
>>> 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 96, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967613 2019] [:error] [pid 10583] [client 
>>> 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 96, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967617 2019] [:error] [pid 10633] [client 
>>> 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 97, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967642 2019] [:error] [pid 10586] [client 
>>> 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 97, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967680 2019] [:error] [pid 10583] [client 
>>> 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 97, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967700 2019] [:error] [pid 10633] [client 
>>> 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 98, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967718 2019] [:error] [pid 10586] [client 
>>> 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 98, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967743 2019] [:error] [pid 10583] [client 
>>> 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 98, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967763 2019] [:error] [pid 10633] [client 
>>> 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be 
>>> integer, string given in /var/www/html/pws/livedata.php on line 99, 
>>> referer: http://192.168.0.21:88/pws/?units=us
>>> [Sat May 25 21:46:52.967857 2019] [:error] [pid 10586] [client 
>>> 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be 

[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2

[John]

>
> Thanks for the pointer to the RFM69 discussions.
>>
>
Now I am thinking of a change in strategy and just putting one of the 
ESP32+RFM95W dev boards into the ISS and send the data out directly, 
alternating between moderate range LoRa <-> LoRa peers and occasionally to 
a distant LoRaWAN gateway.  The ESP32/LoRa module looks to have a very low 
power mode (ULP) suitable for battery / solar operation. I have an dead ISS 
that I thought was only good for parts that I may be able to bring back to 
life with a new cpu/radio and deploy to the ranch cabin. 


https://github.com/LilyGO/TTGO-LORA32-V2.0

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/caca4b3d-9559-4db8-be5f-479d8af0ce3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Weather34 Template for WeeWX - New Major Update

[steeple ian]

Hi Jerry,

Are you using the Weather Underground forecasts? If so have you got one of
the new API keys? If so have you entered correctly in the settings?

Ian

On Sun, May 26, 2019 at 6:09 AM Jd D  wrote:

> Hi Ian,
>
> So I decided to do a new install of both weewx and the very latest
> Weather34 Template (just got tonight) on another raspberry Pi to test
> things. Since I have only one weather station I choose the interceptor
> driver on the new system (did some minor changes to it so it could handle
> 2316 weather data) and then wrote a weewx service called post_loop_packet
> to send the loop data to the interceptor driver. All works just fine and
> have two different versions of the weewx running. I also check the
> w34stats.php and the issue with the format function is gone and the
> template does work in some places. But there is a flood of errors in the
> apache error log. I will include part of the log after this. Some of errors
> seems to be not handling data that N/A. Like in the solar section, I do not
> have solar but the php tries to convert N/A to a number. Here are some log
> snippets.
> Hope this helps.
> Jerry
>
> [Sat May 25 06:25:08.334215 2019] [mpm_prefork:notice] [pid 703] AH00163:
>> Apache/2.4.25 (Raspbian) c[Sat May 25 21:46:52.967308 2019] [:error] [pid
>> 10633] [client 192.168.0.39:61452] PHP Warning:  number_format() expects
>> parameter 1 to be float, string given in /var/www/html/pws/livedata.php on
>> line 92, referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967308 2019] [:error] [pid 10586] [client
>> 192.168.0.39:61456] PHP Warning:  number_format() expects parameter 1 to
>> be float, string given in /var/www/html/pws/livedata.php on line 92,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967406 2019] [:error] [pid 10583] [client
>> 192.168.0.39:61457] PHP Warning:  number_format() expects parameter 1 to
>> be float, string given in /var/www/html/pws/livedata.php on line 92,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967545 2019] [:error] [pid 10633] [client
>> 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 96,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967575 2019] [:error] [pid 10586] [client
>> 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 96,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967613 2019] [:error] [pid 10583] [client
>> 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 96,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967617 2019] [:error] [pid 10633] [client
>> 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 97,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967642 2019] [:error] [pid 10586] [client
>> 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 97,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967680 2019] [:error] [pid 10583] [client
>> 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 97,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967700 2019] [:error] [pid 10633] [client
>> 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 98,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967718 2019] [:error] [pid 10586] [client
>> 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 98,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967743 2019] [:error] [pid 10583] [client
>> 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 98,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967763 2019] [:error] [pid 10633] [client
>> 192.168.0.39:61452] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 99,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967857 2019] [:error] [pid 10586] [client
>> 192.168.0.39:61456] PHP Warning:  date() expects parameter 2 to be
>> integer, string given in /var/www/html/pws/livedata.php on line 99,
>> referer: http://192.168.0.21:88/pws/?units=us
>> [Sat May 25 21:46:52.967881 2019] [:error] [pid 10583] [client
>> 192.168.0.39:61457] PHP Warning:  date() expects parameter 2 to be
>> intege

[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2

[kobuki]

The radio should be capable on paper, but the RFM9x series is only used for 
LoRa in the wild. The main problem is that there's no suitable driver for 
these modules for FSK mode. The RFM69 is cheaper for FSK and there are 
several FSK/OOK libs to choose from, plus it already has several working 
implementations for the Davis radio protocol. There's nothing keeping you 
from writing an implementation and a driver, but I'm not sure it's worth 
the effort.

On Sunday, May 26, 2019 at 1:47:40 AM UTC+2, John wrote:
>
> I have recently picked up a couple inexpensive  ESP32 / LoRa dev boards 
> with an integrated RFM95W rf module in the 902-928 MHz range. I haven't 
> delved into the radio capabilities outside of the LoRa modes but perusing 
> the specs it seems like these might be a candidate for talking to the Davis 
> Vantage Pro 2 ISS.  
>
> A search for RFM95W in the forum was empty.  Has anyone else evaluated 
> these i2c modules as a way to read the ISS directly with a raspberry pi ?
>
> The ESP32 core on these dev boards has integrated Wifi and Bluetooth 
> radios, making them a candidate for bridging the ISS directly to the lan 
> and wan, or even to a distant LoRaWAN gateway using the RFM95W module.
>
>
>
> https://www.digikey.com/en/datasheets/rf-solutions/rf-solutions-rfm95_96_97_98w
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/84e02d11-3d5d-4e2d-9133-ca0d9cc72a7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Davis Vantage Pro2 no data

[David Beach]

I spent a fair bit of time on what I believe is the same issue. I even 
installed an Adafruit RTC and that didn't seem to solve the issue. At the 
moment, I have the system on a UPS (which is huge and probably uses more 
power than my Console, Adapter/Logger module and the RPi Zero W). My UPS 
battery is dying so I will have to replace it soon if I plan to continue to 
use it.

I am not so much worried about losing data - though I can understand 
preserving the data is important for many people - but I just want the darn 
thing to start working again when the power comes back on. If I'm not 
around, it may go for many hours after the power has been restored, not 
working properly, until I clear the logger memory.

I'll be interested in seeing the comments!

David

On Saturday, 25 May 2019 13:13:16 UTC-4, John wrote:
>
> I have been experiencing similar problems recently with my Vantage Pro 2 
> console and RPI (Zero W) setup, typically after a prolonged (1+ hours) 
> power outage.  My only recovery method so far has been to clear the logger 
> which unfortunately leaves me without the storm data that initiated the 
> power outage.
>
> I have a theory, uninvestigated, that upon restart the logger is getting 
> corrupted with date-time changes as the RPI starts up with the incorrect 
> time and communicates with the logger, trying to sync time,  before 
> obtaining the correct time from a time server.  When I have extended power 
> outages, my internet provider is often offline as well so getting my lan 
> back to the correct time has been problematic. I think I have remedied this 
> by adding a battery backed RTC into my lan setup. One of my recovery 
> problems was rooted in DNS queries for time servers failing because of 
> gross time differences.   I briefly explored using the vantage console as a 
> battery backed time source.
>
> John
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e261da94-039a-4549-852f-6f7982eec27d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Add additional rain gauge via second data source

[Andrew Milner]

The script you posted SHOULD only be augmenting  REC packets, and not be 
affected by any LOOP packets.

Maybe you should set record generation to either use hardware or use 
software and not prefer hardware or prefer software.  Your augmented data 
should be use software I would have thought





On Sunday, 26 May 2019 13:37:27 UTC+3, engolling wrote:
>
> Hallo,
> think I tracked the issue down.
> First it starts with record generation software.
>
> So each time a archive dataset is retreivedn form the hardware logger my 
> data is augmented and then it runs apparently through the unit converter, 
> converting it to metric units (in case of my augmented data coming in 
> metric this is bad).
> This happens whenn WeeWx was off for some time.
> Each time an archive paket is gained from the LOOP data it was seemingly 
> already converted my data is augmented and it is saved correctly to the 
> database.
>
> So my question is simplified. Is it possible to determine if a archive 
> record is archived of hardware logger data or LOOP data or can I influence 
> the order of augmenting and converting?
>
> Best regards, 
> engolling
>
> Am Mittwoch, 22. Mai 2019 23:20:08 UTC+2 schrieb engolling:
>>
>> Hello,
>>
>> of course I can give more details :-)
>>
>> So as you know I'm augmenting some extra data to my archive records which 
>> I get from emulated davis loop packaged.
>> My file whichs contains always the latest data looks like this:
>>
>> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_Exp.txt
>> So there is written a signal name, a unit group and the actual data as 
>> csv.
>>
>> The data is then augmented with the following script:
>>
>> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_WeatherDuino_Logger_plugin.py
>> called as data service in the weewx.conf
>>
>> record_generation is set to software, target_unit is set to metric.
>>
>> The augmented data is in °C and most of the time it is saved to the 
>> database without being converted but sometimes a few datasets are double 
>> converted.
>>
>> When record_generation is set to hardware the data is always converted, 
>> so I'm exporting the data in US units and weewx converts it back. This is 
>> no problem either.
>> But it is hard to handle when weewx jumps between no conversion and 
>> conversion.
>>
>> Hopefully it is more clear now what I mean.
>>
>> Regards,
>> engolling
>>
>>
>> Am Montag, 20. Mai 2019 00:49:56 UTC+2 schrieb gjr80:
>>>
>>> Hi,
>>>
>>> Perhaps you could give us some more details as to how the extra 
>>> temperature data is being obtained/provided/added to WeeWX, happy to see 
>>> code/data formats etc - code usually gives an unambiguous picture, 
>>> descriptions are often open to interpretation. I am having a little 
>>> difficulty understanding how the numeric data is always being received but 
>>> not the units, but perhaps that will become clear once you provide some 
>>> more detail.
>>>
>>> Gary
>>>
>>> On Monday, 20 May 2019 05:55:18 UTC+10, engolling wrote:

 Hello,

 me again :).
 Thank you for your last answer Thomas. Works fine.

 Now I have a new "thing" I do not understand.
 As discussed above I'm augmenting different data - also rain data to 
 the archive records as described in the customization guide.

 I also augment temperature signals and sometimes they are converted to 
 metric variables and sometimes not. The problem is the signal is already 
 in 
 °C and should be in °C, but if it is converted it looks like this:


 
 The database is mertric. If I get for example a temperature of 22.61°C 
 which should be imported into the database directly and it is most time. 
 But sometimes I get -5.21°C (which is the result of the Farenheit Celsius 
 conversion of 22.61°C).

 My Raspberry Pi has a bad WIFI internet connection and FTP often fails 
 and it seems to be related to this.

 Could this be a reason and do you know how to handle the conversion?

 Regards,
 engolling

 Am Dienstag, 7. Mai 2019 23:30:27 UTC+2 schrieb Thomas Keffer:
>
> Yes. That's certainly possible. 
>
> -tk
>
> On Tue, May 7, 2019 at 1:35 PM engolling  wrote:
>
>> Hello together,
>>
>> it's me again with hopefully a last question...
>> As you know I'm augmenting some extra data from my service to the 
>> WeeWx archive records. But if archive records are loaded of the stations 
>> logger this data (which is in the future) is also augmented.
>> Is it possible to read the timestamp of the archive record beeing 
>> saved at the moment and then decide if data should be augmented or not?
>> Im thinking of a code like this:
>> if dateTime_AugmentedData - event.record[dateTime] < 300:
>>

Re: [weewx-user] Re: Add additional rain gauge via second data source

[engolling]

Hallo,
think I tracked the issue down.
First it starts with record generation software.

So each time a archive dataset is retreivedn form the hardware logger my 
data is augmented and then it runs apparently through the unit converter, 
converting it to metric units (in case of my augmented data coming in 
metric this is bad).
This happens whenn WeeWx was off for some time.
Each time an archive paket is gained from the LOOP data it was seemingly 
already converted my data is augmented and it is saved correctly to the 
database.

So my question is simplified. Is it possible to determine if a archive 
record is archived of hardware logger data or LOOP data or can I influence 
the order of augmenting and converting?

Best regards, 
engolling

Am Mittwoch, 22. Mai 2019 23:20:08 UTC+2 schrieb engolling:
>
> Hello,
>
> of course I can give more details :-)
>
> So as you know I'm augmenting some extra data to my archive records which 
> I get from emulated davis loop packaged.
> My file whichs contains always the latest data looks like this:
>
> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_Exp.txt
> So there is written a signal name, a unit group and the actual data as csv.
>
> The data is then augmented with the following script:
>
> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_WeatherDuino_Logger_plugin.py
> called as data service in the weewx.conf
>
> record_generation is set to software, target_unit is set to metric.
>
> The augmented data is in °C and most of the time it is saved to the 
> database without being converted but sometimes a few datasets are double 
> converted.
>
> When record_generation is set to hardware the data is always converted, so 
> I'm exporting the data in US units and weewx converts it back. This is no 
> problem either.
> But it is hard to handle when weewx jumps between no conversion and 
> conversion.
>
> Hopefully it is more clear now what I mean.
>
> Regards,
> engolling
>
>
> Am Montag, 20. Mai 2019 00:49:56 UTC+2 schrieb gjr80:
>>
>> Hi,
>>
>> Perhaps you could give us some more details as to how the extra 
>> temperature data is being obtained/provided/added to WeeWX, happy to see 
>> code/data formats etc - code usually gives an unambiguous picture, 
>> descriptions are often open to interpretation. I am having a little 
>> difficulty understanding how the numeric data is always being received but 
>> not the units, but perhaps that will become clear once you provide some 
>> more detail.
>>
>> Gary
>>
>> On Monday, 20 May 2019 05:55:18 UTC+10, engolling wrote:
>>>
>>> Hello,
>>>
>>> me again :).
>>> Thank you for your last answer Thomas. Works fine.
>>>
>>> Now I have a new "thing" I do not understand.
>>> As discussed above I'm augmenting different data - also rain data to the 
>>> archive records as described in the customization guide.
>>>
>>> I also augment temperature signals and sometimes they are converted to 
>>> metric variables and sometimes not. The problem is the signal is already in 
>>> °C and should be in °C, but if it is converted it looks like this:
>>>
>>>
>>> 
>>> The database is mertric. If I get for example a temperature of 22.61°C 
>>> which should be imported into the database directly and it is most time. 
>>> But sometimes I get -5.21°C (which is the result of the Farenheit Celsius 
>>> conversion of 22.61°C).
>>>
>>> My Raspberry Pi has a bad WIFI internet connection and FTP often fails 
>>> and it seems to be related to this.
>>>
>>> Could this be a reason and do you know how to handle the conversion?
>>>
>>> Regards,
>>> engolling
>>>
>>> Am Dienstag, 7. Mai 2019 23:30:27 UTC+2 schrieb Thomas Keffer:

 Yes. That's certainly possible. 

 -tk

 On Tue, May 7, 2019 at 1:35 PM engolling  wrote:

> Hello together,
>
> it's me again with hopefully a last question...
> As you know I'm augmenting some extra data from my service to the 
> WeeWx archive records. But if archive records are loaded of the stations 
> logger this data (which is in the future) is also augmented.
> Is it possible to read the timestamp of the archive record beeing 
> saved at the moment and then decide if data should be augmented or not?
> Im thinking of a code like this:
> if dateTime_AugmentedData - event.record[dateTime] < 300:
>--> augment_data
>
>
>
>
>
> Am Mittwoch, 3. April 2019 00:54:17 UTC+2 schrieb gjr80:
>>
>> Good that you have tracked down the issue. Running hardware record 
>> generation on a Davis station has it advantages, though maybe not so 
>> advantageous on emulated hardware.
>>
>> Regards plotting rain data from two sensors. The current WeeWX plot 
>> engine will certainly allow you to plot two obs in a bar graph plot, 
>> though 
>> I 

[weewx-user] Re: Can't get interceptor to read data in sniff mode

[Roelof Schuiling]

Just chiming in because I am stuck with the same result running the interceptor 
driver directly: identifiers {}. My question is here:
https://groups.google.com/forum/m/#!topic/weewx-user/DHDNdfX6ZVw

If you learn anything I'd love to hear about it :) 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c4ca3d00-9f17-40a2-a4fd-c34bf51f9a10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.