[weewx-user] Re: Skin pws added rain over 15 minutes

[gjr80]

Hi,

Well the date time now makes sense but there is still a fundamental problem 
here. If you have this:

$span($time_delta=900).rain.sum.formatted


in your .tmpl file then the generated file will have 



in there somewhere, irrespective of whether the $span tag is right, wrong 
or indifferent. I do not see this text anywhere in your generated file.


For all those who have the same problem:
>
> > realtime="tempanneemax">$month.outTemp.max.formatted
>> > realtime="tempanneemax">$year.outTemp.max.formatted
>> > realtime="tempanneemini">$month.outTemp.min.formatted
>> > realtime="tempanneemini">$year.outTemp.min.formatted
>>
>
> > realtime="rainheure">$hour.rain.min.formatted
>
>
> On the rain I do not know if it is correct, it does not rain often in 
> Provence
>

Have you made more changes to weewx_pws.xml.tmpl? Did these changes come 
through in your generated weewx_pws.xml? What about the $span line?

The tag $hour.rain.min.formatted will display the minimum archive period 
rainfall from all of the archive periods in the current hour. So if there 
was rainfall in each archive period in the current hour you will get the 
minimum of these values, if there was an archive period in the current hour 
during which it did not rain you will get 0. Is this really what you are 
trying to display,  seems to imply you want the 
rainfall in the last immediate 1 hour period? 
$span($time_delta=3600).rain.sum.formatted will display the rainfall in the 
last immediate 1 hour period. ($hour works on x:00 hour boundaries).

On the other hand it returns only the minimum and maximum temperature of 
> the current month.
>
> I extract this data via a php page, are you able to specify the desired 
> month?
>

I assume you are referring to $month.outTemp.max.formatted ? If so, as you 
rightly say this will provide the max outTemp seen in the current calendar 
month, so at 06:00 on 1 August it will return the max outTemp seen in the 
last 6 hours, $month works on the the period since midnight on the 1st of 
the current month. If you want the max outTemp from some other month in the 
past, say March, then this is not easily done with the current weeWX tags, 
it can be done but it will require some python coding either in a template 
or as a search list extension.

It might help if you could describe exactly what you want in each of your 
fields.

Gary

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

[weewx-user] Re: Problem with drivers for ULTIMETER 2100. OrangePi PC. Armbian.

[gjr80]

Hi,

I think a good starting point will be to see what is in weewx.conf. Can you 
please post a copy of weewx.conf with any sensitive info (eg passwords/user 
names etc) removed.

Gary

On Monday, 7 August 2017 01:23:05 UTC+10, Arkadiusz Z. wrote:
>
> Hello
> Sorry i do not know english so i am using google translator.
> I have a problem:
> Installation on OrangePi PC system of 
> Armbian_5.30_Orangepipc_Ubuntu_xenial_default_3.4.113
> By the command:
> Sudo apt-get install weewx
> The weather station is ULTIMETER 2100.
> Data from the station sent rs232 / ethernet converter.
> Port created with the command:
>
> *Orangepi @ orangepipc: ~ $ sudo socat PTY, link = / dev / netcom0, raw, 
> echo = 0, waitslave TCP4: 192.168.0.118 : 23*
>  
> *In the / dev / directory there is a file @ netcom0 on which is the data 
> when you connect to the terminal program:*
>
> *Welcome to minicom 2.7*
>
> *OPTIONS: I18n*
> *Compiled on Feb 7 2016, 14:00:34.*
> *Port / dev / netcom0, 14:01:20*
>   
>
> *Press CTRL-A Z for help on special keys*
>   
> 
> *YY? YY !! 009100EF02F2070A275202CA  00DA025F0085*
> *009100EF02F2070A275202CA 00DA025F0085  !!*
> *008F00F902F2070A275202CA 00DA025F0085  !!*
> *008F00F902F2070A275202CA 00DA025F0085  !!*
> *008F00F902F2070A275202CA 00DA025F0085  !!*
> *008D00EE02F2070A275202CA 00DA025F0085  !!*
> *008D00EE02F2070A275202CA 00DA025F0085  !!*
> *009900F002F2070A275202CA 00DA025F0085  !!*
>
> It looks like the station is sending weather data.
> Ultimeter is set to "data loger mode"
>
> Sataus looks like this:
>
> *Orangepi @ orangepipc: ~ $ sudo /etc/init.d/weewx status*
> *● weewx.service - LSB: weewx weather system*
> *   Loaded: loaded (/etc/init.d/weewx; bad; vendor preset: enabled)*
> *   Active: active (exited) since Sun 2017-08-06 14:01:50 UTC; 36min ago*
> * Docs: man: systemd-sysv-generator (8)*
> *  Process: 4153 ExecStop = / etc / init.d / weewx stop (code = exited, 
> status = 0 / SUCCESS)*
> *  Process: 4193 ExecStart = / etc / init.d / weewx start (code = exited, 
> status = 0 / SUCCESS)*
>
> *Aug 06 14:01:50 orangepipc weewx [4207]: engine: Initializing engine*
> *Aug 06 14:01:50 orangepipc weewx [4207]: engine: Loading station type 
> Ultimeter (weewx.drivers.ultimeter)*
> *Aug 06 14:01:50 orangepipc weewx [4193]: ... done.*
> *Aug 06 14:01:50 orangepipc systemd [1]: Started LSB: weewx weather 
> system.*
> *Aug 06 14:01:50 orangepipc weewx [4207]: ultimeter: driver version is 
> 0.18*
> *Aug 06 14:01:50 orangepipc weewx [4207]: ultimeter: using serial port / 
> dev / netcom0*
> *Aug 06 14:01:50 orangepipc weewx [4207]: ultimeter: open serial port / 
> dev / netcom0*
> *Aug 06 14:01:50 orangepipc weewx [4207]: import of driver failed: [Errno 
> 22] Invalid argument ()*
> *Aug 06 14:01:50 orangepipc weewx [4207]: engine: Unable to load driver: 
> [Errno 22] Invalid argument*
> *Aug 06 14:01:50 orangepipc weewx [4207]:  Exiting ...*
> *orangepi orangepipc @: ~ $*
>
> After restart weewx:
>
> *Orangepi @ orangepipc: ~ $ sudo /etc/init.d/weewx stop*
> *[Ok] stopping weewx (via systemctl): weewx.service.*
> *Orangepi @ orangepipc: ~ $ sudo /etc/init.d/weewx restart*
> *[Ok] Restarting weewx (via systemctl): weewx.service.*
> *Orangepi @ orangepipc: ~ $ sudo tail -f / var / log / syslog*
> *Aug 6 15:02:23 localhost weewx [4585]: engine: Initializing engine*
> *Aug 6 15:02:23 localhost weewx [4585]: engine: Loading station type 
> Ultimeter (weewx.drivers.ultimeter)*
> *Aug 6 15:02:23 localhost weewx [4571]: ... done.*
> *Aug 6 15:02:23 localhost systemd [1]: Started LSB: weewx weather system.*
> *Aug 6 15:02:23 localhost weewx [4585]: ultimeter: driver version is 0.18*
> *Aug 6 15:02:23 localhost weewx [4585]: ultimeter: using serial port / dev 
> / netcom0*
> *Aug 6 15:02:23 localhost weewx [4585]: ultimeter: open serial port / dev 
> / netcom0*
> *Aug 6 15:02:23 localhost weewx [4585]: import of driver failed: [Errno 
> 22] Invalid argument ()*
> *Aug 6 15:02:23 localhost weewx [4585]: engine: Unable to load driver: 
> [Errno 22] Invalid argument*
> *Aug 6 15:02:23 localhost weewx [4585]:  Exiting ...*
>
> I set debug = 1 in the configuration file in weewx.conf
>
> I will add that I have already reinstalled the weewx breed before removing 
> it, including the configuration files.
> I also installed a pyserial package.
> I also switched modes COMPLETE RECORD MODE, DATA LOGGER MODE, MODEM MODE.
> Currently set to Data Logger mode.
>
>
> Please help.
>

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

[weewx-user] Re: wmr300: possible missed rain event: new=43.688 old=None

[Juan Antonio Mosquera]

Thanks for your answer!

Greetings.

El viernes, 28 de julio de 2017, 2:07:10 (UTC+2), gjr80 escribió:
>
> Hi,
>
> The message you saw can most likely be ignored. The WMR300 reports a 
> cumulative rain total rather than an incremental rain value (ie rainfall 
> per period). WeeWX stores 'rainfall per archive period' so the WMR300 
> driver needs to calculate an incremental rainfall value from the cumulative 
> value reported by the station. This is done by keeping track of the last 
> cumulative rain value from the station and calculating the incremental 
> value as the difference between the current cumulative rain value and the 
> last cumulative rain value. This works fine once the driver has been 
> running long enough to have received two packets with cumulative rain data. 
> However, when the driver (read weeWX) first starts, the driver has no idea 
> what the last cumulative rain value (ie the 'old' value) was so it is set 
> to None. When the first packet is received by the driver with cumulative 
> rain data (let's say 43.688) the driver cannot calculate the incremental 
> rainfall as it does not know the 'old' value. Consequently, you get a 
> message like you saw. When the next packet arrives with cumulative rainfall 
> data it should work fine as the driver now has an 'old' value.
>
> So if you are seeing the message you saw when you first startup weeWX then 
> that is normal operation and nothing to worry about. However, if you are 
> seeing this message regularly and it's not associated with a weeWX 
> start/restart then something is wrong.
>
> Gary
>
> On Wednesday, 26 July 2017 02:02:58 UTC+10, Juan Antonio Mosquera wrote:
>>
>> What does this log message mean in the WMR300 ?, I searched the net and 
>> found nothing (for now)
>>
>> wmr300: possible missed rain event: new=43.688 old=None
>> wmr300: rain=None rain_total=43.688 last_rain=None
>>
>>
>>
>> Thank you!
>>
>

-- 
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[6]: [weewx-user] WMR 200 and weewx 3.1 missing values

[Joseph Tomeh]

Hello,

I agree with you, it could be a good idea to offer  to enable/disable 
this feature in the conf file.
I let weewx's github senior members to decide to agree and to add it or 
not in conf file.


Here is a proposed patch to check if the weatherstation transmits wrong 
live record data, i have republished it because i have not find the 
previous patch.


https://github.com/weewx/weewx/commit/d237c7468dd15b2fd385a9ce8c27341a70031998

replaced in restx.py
self.process_record(_record, dbmanager)

by
if _record['outTemp']: self.process_record(_record, dbmanager) except 
KeyError: _time_str = timestamp_to_string(_record['dateTime']) 
syslog.syslog(syslog.LOG_INFO, "restx: %s: Skipped record %s because of 
outTemp error." % (self.protocol_name, _time_str)) pass


regards


-- Message d'origine --
De: "Chris Manton" 
À: "weewx-user" 
Cc : andrew.s.r.mil...@gmail.com; jto...@gmail.com
Envoyé : 06/08/2017 19:13:37
Objet : Re: Re[4]: [weewx-user] WMR 200 and weewx 3.1 missing values

I cannot view the patch, but sounds like you have some familiarity with 
this weatherstation.


I suggest you provide a well-named configuration value for the 
configuration file to enable/disable this feature of restricting 
out-of-bounds values, such that the end user may enable or disable 
appropriately.


Chris
--


On Sunday, August 6, 2017 at 6:58:22 AM UTC-7, Joseph Tomeh wrote:

Hello,

I am talking about records captured in live. I agree there is no wrong 
datas recorded in the WMR200 datalogger and retrived from WMR200's 
archive.


I have this station since 7 years ago and i know very well its 
limitations (bad wind speed measure, wrong data, ...).


I had already wrote a C# software for managing this station because of 
 Oregon software given with the station which had retrieved bad data 
too.
I have migrated to weewx because I wanted to connect it permanently 
using a Raspberrypi.
With weewx i have now the same troubleshootings i had met when I 
started to write my first C# driver for WMR200.


My opinion is we need to consider data from WMR200 not reliable and 
check them. This why I proposed to check "outTemp" value.
if i don't make this check in restx.py, I have splitted graphs (non 
continuous curve) and errors message from wunderground telling my 
station is not reporting data.


My proposed fix (please see today's github proposed patch) for restx 
is working well and it has solved the issue reported before.


Regards


-- Message d'origine --
De: "Andrew Milner" 
À: "weewx-user" 
Cc : jto...@gmail.com
Envoyé : 06/08/2017 12:49:08
Objet : Re: Re[2]: [weewx-user] WMR 200 and weewx 3.1 missing values

Are you talking about Loop data or REC data??  Since the archive is 
normally over 300 seconds, and contains the average reading for the 
interval, it is unlikely that there will be any missing or wrong data 
in the archive (which is also used for the graphs).  The issue only 
arises when the archive interval is too short to contain at least one 
reading for all sensors, or if loop data is being output.


On Sunday, 6 August 2017 11:35:37 UTC+3, Joseph Tomeh wrote:

Hello,

Thanks a lot for your quick answer and sorry for my late response, i 
was very busy and not at home since last time.


 i studied the weewx python code. I'dont know very well this 
programming language and I'am not able to write a weewx service. But 
I think, we can solve easyly this issue without modifying the driver 
code and writing a weewx service.


First of all, i proposed a patch (please see my today's github 
contribution).
This patch avoid to send bad records for instance for Wunderground 
et produce splittered graphs. I hope i will be accepted, i have 
tested it, it is working well.


In second time, i think, it could be possible to do the same test 
"if record['outTemp']"  in the 2 functions "_addSingleRecord" in 
manager.py.
if we prevent from adding bad records into the archive and daily 
tables the database will be still consistent


what do you think about these proposals ?

Best regards

-- Message d'origine --
De: "Thomas Keffer" 
À: "weewx-user" 
Envoyé : 21/07/2017 16:32:27
Objet : Re: [weewx-user] WMR 200 and weewx 3.1 missing values

In weewx, if a driver detects a bad value, it should replace it 
with a null. I'm not sure whether the existing driver does this (I 
did not write it).


One of the reasons weewx is able to support so many different types 
of hardware is that it has a very simple, and very consistent, data 
model . 
One of the guidelines of that model is, "The driver should emit 
only data it receives from the hardware (no "filling in the 
gaps")." If you want to do that, that would be the job of a weewx 
service.


However, we looked into caching values about a year ago and decided 
not to 

[weewx-user] Re: Skin pws added rain over 15 minutes

[Nicolas Cazan]

On the other hand it returns only the minimum and maximum temperature of 
the current month.

I extract this data via a php page, are you able to specify the desired 
month?

Le dimanche 6 août 2017 17:56:22 UTC+2, Nicolas Cazan a écrit :
>
> For all those who have the same problem:
>
> > realtime="tempanneemax">$month.outTemp.max.formatted
>> > realtime="tempanneemax">$year.outTemp.max.formatted
>> > realtime="tempanneemini">$month.outTemp.min.formatted
>> > realtime="tempanneemini">$year.outTemp.min.formatted
>>
>
> > realtime="rainheure">$hour.rain.min.formatted
>
>
> On the rain I do not know if it is correct, it does not rain often in 
> Provence 
>
> Le dimanche 6 août 2017 15:20:30 UTC+2, Nicolas Cazan a écrit :
>>
>> oups ...
>>
>> Le dimanche 6 août 2017 15:01:02 UTC+2, gjr80 a écrit :
>>>
>>> Are you sure that this file has just been generated? The date time at 
>>> line 7 does not seem correct, as I write this it is 5 minutes before the 
>>> hour, but the date time in the file is 5 minutes after the hour?
>>>
>>> 14:05 CEST
>>>
>>> I am also suspicious given that that none of the xml tags from the line 
>>> you are trying to add are appearing in the file you posted. Are you sure 
>>> you are editing the correct weewx_pws.xml.tmpl and/or are you sure you 
>>> are posting the most recently generated weewx_pws.xml ?
>>>
>>> Gary
>>>
>>> On Sunday, 6 August 2017 22:50:34 UTC+10, Nicolas Cazan wrote:



 Le dimanche 6 août 2017 14:36:15 UTC+2, gjr80 a écrit :
>
> Ok, so what does the generated weewx_pws.xml look like now?
>
> Gary
>


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

Re: Re[4]: [weewx-user] WMR 200 and weewx 3.1 missing values

[Chris Manton]

I cannot view the patch, but sounds like you have some familiarity with 
this weatherstation.

I suggest you provide a well-named configuration value for the 
configuration file to enable/disable this feature of restricting 
out-of-bounds values, such that the end user may enable or disable 
appropriately.

Chris
--


On Sunday, August 6, 2017 at 6:58:22 AM UTC-7, Joseph Tomeh wrote:
>
> Hello, 
>
> I am talking about records captured in live. I agree there is no wrong 
> datas recorded in the WMR200 datalogger and retrived from WMR200's archive.
>
> I have this station since 7 years ago and i know very well its limitations 
> (bad wind speed measure, wrong data, ...).
>
> I had already wrote a C# software for managing this station because of  
> Oregon software given with the station which had retrieved bad data too. 
> I have migrated to weewx because I wanted to connect it permanently using 
> a Raspberrypi.
> With weewx i have now the same troubleshootings i had met when I started 
> to write my first C# driver for WMR200.
>
> My opinion is we need to consider data from WMR200 not reliable and check 
> them. This why I proposed to check "outTemp" value. 
> if i don't make this check in restx.py, I have splitted graphs (non 
> continuous curve) and errors message from wunderground telling my station 
> is not reporting data. 
>
> My proposed fix (please see today's github proposed patch) for restx is 
> working well and it has solved the issue reported before.
>
> Regards
>
>
> -- Message d'origine --
> De: "Andrew Milner" 
> À: "weewx-user" 
> Cc : jto...@gmail.com 
> Envoyé : 06/08/2017 12:49:08
> Objet : Re: Re[2]: [weewx-user] WMR 200 and weewx 3.1 missing values
>
> Are you talking about Loop data or REC data??  Since the archive is 
> normally over 300 seconds, and contains the average reading for the 
> interval, it is unlikely that there will be any missing or wrong data in 
> the archive (which is also used for the graphs).  The issue only arises 
> when the archive interval is too short to contain at least one reading for 
> all sensors, or if loop data is being output.
>
> On Sunday, 6 August 2017 11:35:37 UTC+3, Joseph Tomeh wrote:
>>
>> Hello, 
>>
>> Thanks a lot for your quick answer and sorry for my late response, i was 
>> very busy and not at home since last time.
>>
>>  i studied the weewx python code. I'dont know very well this programming 
>> language and I'am not able to write a weewx service. But I think, we can 
>> solve easyly this issue without modifying the driver code and writing a 
>> weewx service.
>>
>> First of all, i proposed a patch (please see my today's github 
>> contribution).
>> This patch avoid to send bad records for instance for Wunderground et 
>> produce splittered graphs. I hope i will be accepted, i have tested it, it 
>> is working well.
>>
>> In second time, i think, it could be possible to do the same test "if 
>> record['outTemp']"  in the 2 functions "_addSingleRecord" in manager.py.
>> if we prevent from adding bad records into the archive and daily tables 
>> the database will be still consistent
>>
>> what do you think about these proposals ? 
>>
>> Best regards
>>
>> -- Message d'origine --
>> De: "Thomas Keffer" 
>> À: "weewx-user" 
>> Envoyé : 21/07/2017 16:32:27
>> Objet : Re: [weewx-user] WMR 200 and weewx 3.1 missing values
>>
>> In weewx, if a driver detects a bad value, it should replace it with a 
>> null. I'm not sure whether the existing driver does this (I did not write 
>> it).
>>
>> One of the reasons weewx is able to support so many different types of 
>> hardware is that it has a very simple, and very consistent, data model 
>> . One of the 
>> guidelines of that model is, "The driver should emit only data it receives 
>> from the hardware (no "filling in the gaps")." If you want to do that, that 
>> would be the job of a weewx service. 
>>
>> However, we looked into caching values about a year ago and decided not 
>> to do it for reasons given in the Issue thread 
>> . What you're proposing is a 
>> little simpler, but could run into some of the same problems.
>>
>> -tk
>>
>>
>>
>> On Fri, Jul 21, 2017 at 1:20 AM,  wrote:
>>
>>> Hello, 
>>>
>>> I have read this topic because i have the same trouble too. I used the 
>>> latest version of weewx  (3.7.1)  and the latest driver version for wmr200 
>>> (3.3.2).
>>>
>>> I have a WMR200 station since 2010. 
>>> I wrote my own driver with c#. But I decided this year to plug my 
>>> station to a Raspberrypi and my c# app not working. Then I decided to use 
>>> Weewx.
>>>
>>> The WMR200 is well known to produce sometime bad values (NA ou null 
>>> values) sometime the pressure, sometime temperature, ... 
>>>
>>> In my c# driver, I used the following strategy, if i 

[weewx-user] Re: Skin pws added rain over 15 minutes

[Nicolas Cazan]

For all those who have the same problem:

 realtime="tempanneemax">$month.outTemp.max.formatted
>  realtime="tempanneemax">$year.outTemp.max.formatted
>  realtime="tempanneemini">$month.outTemp.min.formatted
>  realtime="tempanneemini">$year.outTemp.min.formatted
>

 realtime="rainheure">$hour.rain.min.formatted


On the rain I do not know if it is correct, it does not rain often in 
Provence 

Le dimanche 6 août 2017 15:20:30 UTC+2, Nicolas Cazan a écrit :
>
> oups ...
>
> Le dimanche 6 août 2017 15:01:02 UTC+2, gjr80 a écrit :
>>
>> Are you sure that this file has just been generated? The date time at 
>> line 7 does not seem correct, as I write this it is 5 minutes before the 
>> hour, but the date time in the file is 5 minutes after the hour?
>>
>> 14:05 CEST
>>
>> I am also suspicious given that that none of the xml tags from the line 
>> you are trying to add are appearing in the file you posted. Are you sure 
>> you are editing the correct weewx_pws.xml.tmpl and/or are you sure you 
>> are posting the most recently generated weewx_pws.xml ?
>>
>> Gary
>>
>> On Sunday, 6 August 2017 22:50:34 UTC+10, Nicolas Cazan wrote:
>>>
>>>
>>>
>>> Le dimanche 6 août 2017 14:36:15 UTC+2, gjr80 a écrit :

 Ok, so what does the generated weewx_pws.xml look like now?

 Gary

>>>

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

[weewx-user] Problem with drivers for ULTIMETER 2100. OrangePi PC. Armbian.

[Arkadiusz Z.]

Hello
Sorry i do not know english so i am using google translator.
I have a problem:
Installation on OrangePi PC system of 
Armbian_5.30_Orangepipc_Ubuntu_xenial_default_3.4.113
By the command:
Sudo apt-get install weewx
The weather station is ULTIMETER 2100.
Data from the station sent rs232 / ethernet converter.
Port created with the command:

*Orangepi @ orangepipc: ~ $ sudo socat PTY, link = / dev / netcom0, raw, 
echo = 0, waitslave TCP4: 192.168.0.118: 23*
 
*In the / dev / directory there is a file @ netcom0 on which is the data 
when you connect to the terminal program:*

*Welcome to minicom 2.7*

*OPTIONS: I18n*
*Compiled on Feb 7 2016, 14:00:34.*
*Port / dev / netcom0, 14:01:20*

 
*Press CTRL-A Z for help on special keys*

  
*YY? YY !! 009100EF02F2070A275202CA  00DA025F0085*
*009100EF02F2070A275202CA 00DA025F0085  !!*
*008F00F902F2070A275202CA 00DA025F0085  !!*
*008F00F902F2070A275202CA 00DA025F0085  !!*
*008F00F902F2070A275202CA 00DA025F0085  !!*
*008D00EE02F2070A275202CA 00DA025F0085  !!*
*008D00EE02F2070A275202CA 00DA025F0085  !!*
*009900F002F2070A275202CA 00DA025F0085  !!*

It looks like the station is sending weather data.
Ultimeter is set to "data loger mode"

Sataus looks like this:

*Orangepi @ orangepipc: ~ $ sudo /etc/init.d/weewx status*
*● weewx.service - LSB: weewx weather system*
*   Loaded: loaded (/etc/init.d/weewx; bad; vendor preset: enabled)*
*   Active: active (exited) since Sun 2017-08-06 14:01:50 UTC; 36min ago*
* Docs: man: systemd-sysv-generator (8)*
*  Process: 4153 ExecStop = / etc / init.d / weewx stop (code = exited, 
status = 0 / SUCCESS)*
*  Process: 4193 ExecStart = / etc / init.d / weewx start (code = exited, 
status = 0 / SUCCESS)*

*Aug 06 14:01:50 orangepipc weewx [4207]: engine: Initializing engine*
*Aug 06 14:01:50 orangepipc weewx [4207]: engine: Loading station type 
Ultimeter (weewx.drivers.ultimeter)*
*Aug 06 14:01:50 orangepipc weewx [4193]: ... done.*
*Aug 06 14:01:50 orangepipc systemd [1]: Started LSB: weewx weather system.*
*Aug 06 14:01:50 orangepipc weewx [4207]: ultimeter: driver version is 0.18*
*Aug 06 14:01:50 orangepipc weewx [4207]: ultimeter: using serial port / 
dev / netcom0*
*Aug 06 14:01:50 orangepipc weewx [4207]: ultimeter: open serial port / dev 
/ netcom0*
*Aug 06 14:01:50 orangepipc weewx [4207]: import of driver failed: [Errno 
22] Invalid argument ()*
*Aug 06 14:01:50 orangepipc weewx [4207]: engine: Unable to load driver: 
[Errno 22] Invalid argument*
*Aug 06 14:01:50 orangepipc weewx [4207]:  Exiting ...*
*orangepi orangepipc @: ~ $*

After restart weewx:

*Orangepi @ orangepipc: ~ $ sudo /etc/init.d/weewx stop*
*[Ok] stopping weewx (via systemctl): weewx.service.*
*Orangepi @ orangepipc: ~ $ sudo /etc/init.d/weewx restart*
*[Ok] Restarting weewx (via systemctl): weewx.service.*
*Orangepi @ orangepipc: ~ $ sudo tail -f / var / log / syslog*
*Aug 6 15:02:23 localhost weewx [4585]: engine: Initializing engine*
*Aug 6 15:02:23 localhost weewx [4585]: engine: Loading station type 
Ultimeter (weewx.drivers.ultimeter)*
*Aug 6 15:02:23 localhost weewx [4571]: ... done.*
*Aug 6 15:02:23 localhost systemd [1]: Started LSB: weewx weather system.*
*Aug 6 15:02:23 localhost weewx [4585]: ultimeter: driver version is 0.18*
*Aug 6 15:02:23 localhost weewx [4585]: ultimeter: using serial port / dev 
/ netcom0*
*Aug 6 15:02:23 localhost weewx [4585]: ultimeter: open serial port / dev / 
netcom0*
*Aug 6 15:02:23 localhost weewx [4585]: import of driver failed: [Errno 22] 
Invalid argument ()*
*Aug 6 15:02:23 localhost weewx [4585]: engine: Unable to load driver: 
[Errno 22] Invalid argument*
*Aug 6 15:02:23 localhost weewx [4585]:  Exiting ...*

I set debug = 1 in the configuration file in weewx.conf

I will add that I have already reinstalled the weewx breed before removing 
it, including the configuration files.
I also installed a pyserial package.
I also switched modes COMPLETE RECORD MODE, DATA LOGGER MODE, MODEM MODE.
Currently set to Data Logger mode.


Please help.

-- 
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[4]: [weewx-user] WMR 200 and weewx 3.1 missing values

[Joseph Tomeh]

Hello,

I am talking about records captured in live. I agree there is no wrong 
datas recorded in the WMR200 datalogger and retrived from WMR200's 
archive.


I have this station since 7 years ago and i know very well its 
limitations (bad wind speed measure, wrong data, ...).


I had already wrote a C# software for managing this station because of  
Oregon software given with the station which had retrieved bad data too.
I have migrated to weewx because I wanted to connect it permanently 
using a Raspberrypi.
With weewx i have now the same troubleshootings i had met when I started 
to write my first C# driver for WMR200.


My opinion is we need to consider data from WMR200 not reliable and 
check them. This why I proposed to check "outTemp" value.
if i don't make this check in restx.py, I have splitted graphs (non 
continuous curve) and errors message from wunderground telling my 
station is not reporting data.


My proposed fix (please see today's github proposed patch) for restx is 
working well and it has solved the issue reported before.


Regards


-- Message d'origine --
De: "Andrew Milner" 
À: "weewx-user" 
Cc : jto...@gmail.com
Envoyé : 06/08/2017 12:49:08
Objet : Re: Re[2]: [weewx-user] WMR 200 and weewx 3.1 missing values

Are you talking about Loop data or REC data??  Since the archive is 
normally over 300 seconds, and contains the average reading for the 
interval, it is unlikely that there will be any missing or wrong data 
in the archive (which is also used for the graphs).  The issue only 
arises when the archive interval is too short to contain at least one 
reading for all sensors, or if loop data is being output.


On Sunday, 6 August 2017 11:35:37 UTC+3, Joseph Tomeh wrote:

Hello,

Thanks a lot for your quick answer and sorry for my late response, i 
was very busy and not at home since last time.


 i studied the weewx python code. I'dont know very well this 
programming language and I'am not able to write a weewx service. But I 
think, we can solve easyly this issue without modifying the driver 
code and writing a weewx service.


First of all, i proposed a patch (please see my today's github 
contribution).
This patch avoid to send bad records for instance for Wunderground et 
produce splittered graphs. I hope i will be accepted, i have tested 
it, it is working well.


In second time, i think, it could be possible to do the same test "if 
record['outTemp']"  in the 2 functions "_addSingleRecord" in 
manager.py.
if we prevent from adding bad records into the archive and daily 
tables the database will be still consistent


what do you think about these proposals ?

Best regards

-- Message d'origine --
De: "Thomas Keffer" 
À: "weewx-user" 
Envoyé : 21/07/2017 16:32:27
Objet : Re: [weewx-user] WMR 200 and weewx 3.1 missing values

In weewx, if a driver detects a bad value, it should replace it with 
a null. I'm not sure whether the existing driver does this (I did not 
write it).


One of the reasons weewx is able to support so many different types 
of hardware is that it has a very simple, and very consistent, data 
model . One 
of the guidelines of that model is, "The driver should emit only data 
it receives from the hardware (no "filling in the gaps")." If you 
want to do that, that would be the job of a weewx service.


However, we looked into caching values about a year ago and decided 
not to do it for reasons given in the Issue thread 
. What you're proposing is 
a little simpler, but could run into some of the same problems.


-tk



On Fri, Jul 21, 2017 at 1:20 AM,  wrote:

Hello,

I have read this topic because i have the same trouble too. I used 
the latest version of weewx  (3.7.1)  and the latest driver version 
for wmr200 (3.3.2).


I have a WMR200 station since 2010.
I wrote my own driver with c#. But I decided this year to plug my 
station to a Raspberrypi and my c# app not working. Then I decided 
to use Weewx.


The WMR200 is well known to produce sometime bad values (NA ou null 
values) sometime the pressure, sometime temperature, ...


In my c# driver, I used the following strategy, if i receive a null 
record for a field, i replace it with the previous recorded value 
(only the erreneous field, not the whole record)


I think that could be done too in weewx. An other strategy could be 
done in StdQC an could allow us to reject a whole record if some 
values are errouneous eg NULL ou NA;


Do you think that could be done in next version of the WMR200's 
driver. I don't know Python, I can't help to change the python 
WMR200 driver


Congratulation for this very good job.
Best regards


Le samedi 28 mars 2015 02:21:26 UTC+1, Markus Roth a écrit :

Works not i have the first N/A by the UV sensor.

Other thinks to test ?

Am 

[weewx-user] Re: Skin pws added rain over 15 minutes

[Nicolas Cazan]

oups ...

Le dimanche 6 août 2017 15:01:02 UTC+2, gjr80 a écrit :
>
> Are you sure that this file has just been generated? The date time at line 
> 7 does not seem correct, as I write this it is 5 minutes before the hour, 
> but the date time in the file is 5 minutes after the hour?
>
> 14:05 CEST
>
> I am also suspicious given that that none of the xml tags from the line 
> you are trying to add are appearing in the file you posted. Are you sure 
> you are editing the correct weewx_pws.xml.tmpl and/or are you sure you 
> are posting the most recently generated weewx_pws.xml ?
>
> Gary
>
> On Sunday, 6 August 2017 22:50:34 UTC+10, Nicolas Cazan wrote:
>>
>>
>>
>> Le dimanche 6 août 2017 14:36:15 UTC+2, gjr80 a écrit :
>>>
>>> Ok, so what does the generated weewx_pws.xml look like now?
>>>
>>> Gary
>>>
>>

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


weewx_pws.xml
Description: XML document

[weewx-user] Re: Skin pws added rain over 15 minutes

[gjr80]

Are you sure that this file has just been generated? The date time at line 
7 does not seem correct, as I write this it is 5 minutes before the hour, 
but the date time in the file is 5 minutes after the hour?

14:05 CEST

I am also suspicious given that that none of the xml tags from the line you 
are trying to add are appearing in the file you posted. Are you sure you 
are editing the correct weewx_pws.xml.tmpl and/or are you sure you are 
posting the most recently generated weewx_pws.xml ?

Gary

On Sunday, 6 August 2017 22:50:34 UTC+10, Nicolas Cazan wrote:
>
>
>
> Le dimanche 6 août 2017 14:36:15 UTC+2, gjr80 a écrit :
>>
>> Ok, so what does the generated weewx_pws.xml look like now?
>>
>> Gary
>>
>

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

[weewx-user] Re: Skin pws added rain over 15 minutes

[Nicolas Cazan]

Le dimanche 6 août 2017 14:36:15 UTC+2, gjr80 a écrit :
>
> Ok, so what does the generated weewx_pws.xml look like now?
>
> Gary
>

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


weewx_pws.xml
Description: XML document

[weewx-user] Re: Skin pws added rain over 15 minutes

[gjr80]

Ok, so what does the generated weewx_pws.xml look like now?

Gary

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

[weewx-user] Re: Skin pws added rain over 15 minutes

[Nicolas Cazan]

ok.

No, it does not work, the file is generated, but the value does not appear.

Le dimanche 6 août 2017 14:27:45 UTC+2, gjr80 a écrit :
>
> No need to restart if changing a .tmpl or skin.conf. Just make the change, 
> save the file and it will be use on the next report cycle. 
>
> Simple rule of thumb. Change a .py file and you must stop then start 
> weeWX, change weewx.conf you need to stop then start weeWX or do a config 
> reload, change a .tmpl or skin.conf and you don't need to do anything other 
> than save the changes.
>
> Gary
>
>

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


weewx_pws.xml.tmpl
Description: Binary data

[weewx-user] Re: Skin pws added rain over 15 minutes

[gjr80]

No need to restart if changing a .tmpl or skin.conf. Just make the change, save 
the file and it will be use on the next report cycle. 

Simple rule of thumb. Change a .py file and you must stop then start weeWX, 
change weewx.conf you need to stop then start weeWX or do a config reload, 
change a .tmpl or skin.conf and you don't need to do anything other than save 
the changes.

Gary

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

[weewx-user] Re: Skin pws added rain over 15 minutes

[Nicolas Cazan]

Should i restart weewx with each modification?

Le dimanche 6 août 2017 14:13:06 UTC+2, gjr80 a écrit :
>
> You have a typo in weewx_pws.xml.tmpl. You have:
>
> $day.barometer.min.formatted
> 
> 
> $time_delta=900).rain.sum.formatted
> 
> $day.rain.sum.formatted
> 
>
> it should read:
>
> $day.barometer.min.formatted
> 
> 
> $span(
> $time_delta=900).rain.sum.formatted
> $day.rain.sum.formatted
> 
>
> Gary
>

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

[weewx-user] Re: Skin pws added rain over 15 minutes

[gjr80]

You have a typo in weewx_pws.xml.tmpl. You have:

$day.barometer.min.formatted


$time_delta=900).rain.sum.formatted

$day.rain.sum.formatted


it should read:

$day.barometer.min.formatted


$span($time_delta=900).rain.sum.formatted

$day.rain.sum.formatted


Gary

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

[weewx-user] Re: Skin pws added rain over 15 minutes

[Nicolas Cazan]

Le dimanche 6 août 2017 13:46:58 UTC+2, gjr80 a écrit :
>
> Hi,
>
> If the following line is what is in weewx_pws.xml then it indicates that 
> there is an error in the syntax of the $span tag in your template.
>
> > realtime="minrain">$day_delta=900).rain.sum.formatted
>>
>
> Could you please post copies of:
>
> skins/PWS/weewx_pws.xml.tmpl
> skins/PWS/skin.conf
> the generated weewx_pws.xml
>
> Please attach the files in their entirety, do not copy one or two lines, 
> we need to see the entire files.
>
> Gary
>

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

#   
   #
#   
   #
#  WEEWX-WD PWS SKIN CONFIGURATION FILE 
   #
#   
   #
# Version: 1.0.0 Date: 10 
January 2015 #
#   
   #


[Extras]



[Units]

#
# This section is for managing the selection and formatting of units.
#

[[Groups]]
#
# For each group of measurements, this section sets what units to use 
for it.
# NB: The unit is always in the singular. I.e., 'mile_per_hour', NOT 
'miles_per_hour'
#
group_altitude = meter  # Options are 'foot' or 'meter'
group_degree_day   = degree_C_day   # Options are 'degree_F_day' or 
'degree_C_day'
group_direction= degree_compass
group_moisture = centibar
group_percent  = percent
group_pressure = hPa# Weewx options are 'inHg', 'mmHg', 
'mbar', or 'hPa'
# Saratoga templates expect 'inHg', 
'mbar', or 'hPa'
group_radiation= watt_per_meter_squared
group_rain = mm # Weewx options are 'inch', 'cm', 
or 'mm'
# Saratoga templates expect 'inch' 
or 'mm'
group_rainrate = mm_per_hour# Weewx options are 
'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
# Saratoga templates expect 
'inch_per_hour' or 'mm_per_hour'
group_speed= km_per_hour# Options are 'mile_per_hour', 
'km_per_hour', 'knot', or 'meter_per_second'
group_speed2   = km # Options are 'mi', 'km'
group_temperature  = degree_C   # Options are 'degree_F' or 
'degree_C'
group_temperature2 = C  # Options are 'F' or 'C'
group_uv   = uv_index
group_volt = volt

# The following unit groups are used internally and should not be 
changed:
group_count= count
group_interval = minute
group_time = unix_epoch
group_elapsed  = second

[[StringFormats]]
#
# This section sets the string formatting for each type of unit.
#
centibar   = %.0f
cm = %.2f
cm_per_hour= %.2f
degree_C   = %.1f
degree_F   = %.1f
degree_compass = %.0f
foot   = %.0f
hPa= %.1f
inHg   = %.3f
inch   = %.2f
inch_per_hour  = %.2f
km_per_hour= %.0f
km_per_hour2   = %.1f
knot   = %.0f
knot2  = %.1f
mbar   = %.1f
meter  = %.0f
meter_per_second   = %.1f
meter_per_second2  = %.1f
mile_per_hour  = %.0f
mile_per_hour2 = %.1f
mm = %.1f
mmHg   = %.1f
mm_per_hour= %.1f
percent= %.0f
uv_index   = %.1f
volt   = %.1f
watt_per_meter_squared = %.0f
NONE   = "N/A"

[[Labels]]
#
# This section sets a label to be used for each type of unit.
#
centibar  = " cb"
cm= " cm"
cm_per_hour   = " cm/hr"
degree_C  = " C"
degree_F  = " F"
degree_compass=   
foot  = " 

[weewx-user] Re: Skin pws added rain over 15 minutes

[gjr80]

Hi,

If the following line is what is in weewx_pws.xml then it indicates that 
there is an error in the syntax of the $span tag in your template.

 realtime="minrain">$day_delta=900).rain.sum.formatted
>

Could you please post copies of:

skins/PWS/weewx_pws.xml.tmpl
skins/PWS/skin.conf
the generated weewx_pws.xml

Please attach the files in their entirety, do not copy one or two lines, we 
need to see the entire files.

Gary

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

[weewx-user] Re: Skin pws added rain over 15 minutes

[Nicolas Cazan]

Hello,
The weewx_pws.xml file is generated, but the line does not appear, here is 
the last modification.

 realtime="minrain">$day_delta=900).rain.sum.formatted
>

-- 
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: Re[2]: [weewx-user] WMR 200 and weewx 3.1 missing values

[Andrew Milner]

Are you talking about Loop data or REC data??  Since the archive is 
normally over 300 seconds, and contains the average reading for the 
interval, it is unlikely that there will be any missing or wrong data in 
the archive (which is also used for the graphs).  The issue only arises 
when the archive interval is too short to contain at least one reading for 
all sensors, or if loop data is being output.

On Sunday, 6 August 2017 11:35:37 UTC+3, Joseph Tomeh wrote:
>
> Hello, 
>
> Thanks a lot for your quick answer and sorry for my late response, i was 
> very busy and not at home since last time.
>
>  i studied the weewx python code. I'dont know very well this programming 
> language and I'am not able to write a weewx service. But I think, we can 
> solve easyly this issue without modifying the driver code and writing a 
> weewx service.
>
> First of all, i proposed a patch (please see my today's github 
> contribution).
> This patch avoid to send bad records for instance for Wunderground et 
> produce splittered graphs. I hope i will be accepted, i have tested it, it 
> is working well.
>
> In second time, i think, it could be possible to do the same test "if 
> record['outTemp']"  in the 2 functions "_addSingleRecord" in manager.py.
> if we prevent from adding bad records into the archive and daily tables 
> the database will be still consistent
>
> what do you think about these proposals ? 
>
> Best regards
>
> -- Message d'origine --
> De: "Thomas Keffer" 
> À: "weewx-user" 
> Envoyé : 21/07/2017 16:32:27
> Objet : Re: [weewx-user] WMR 200 and weewx 3.1 missing values
>
> In weewx, if a driver detects a bad value, it should replace it with a 
> null. I'm not sure whether the existing driver does this (I did not write 
> it).
>
> One of the reasons weewx is able to support so many different types of 
> hardware is that it has a very simple, and very consistent, data model 
> . One of the 
> guidelines of that model is, "The driver should emit only data it receives 
> from the hardware (no "filling in the gaps")." If you want to do that, that 
> would be the job of a weewx service. 
>
> However, we looked into caching values about a year ago and decided not to 
> do it for reasons given in the Issue thread 
> . What you're proposing is a 
> little simpler, but could run into some of the same problems.
>
> -tk
>
>
>
> On Fri, Jul 21, 2017 at 1:20 AM,  wrote:
>
>> Hello, 
>>
>> I have read this topic because i have the same trouble too. I used the 
>> latest version of weewx  (3.7.1)  and the latest driver version for wmr200 
>> (3.3.2).
>>
>> I have a WMR200 station since 2010. 
>> I wrote my own driver with c#. But I decided this year to plug my station 
>> to a Raspberrypi and my c# app not working. Then I decided to use Weewx.
>>
>> The WMR200 is well known to produce sometime bad values (NA ou null 
>> values) sometime the pressure, sometime temperature, ... 
>>
>> In my c# driver, I used the following strategy, if i receive a null 
>> record for a field, i replace it with the previous recorded value (only the 
>> erreneous field, not the whole record)
>>
>> I think that could be done too in weewx. An other strategy could be done 
>> in StdQC an could allow us to reject a whole record if some values are 
>> errouneous eg NULL ou NA;
>>
>> Do you think that could be done in next version of the WMR200's driver. I 
>> don't know Python, I can't help to change the python WMR200 driver 
>>
>> Congratulation for this very good job.
>> Best regards
>>
>>
>> Le samedi 28 mars 2015 02:21:26 UTC+1, Markus Roth a écrit :
>>>
>>> Works not i have the first N/A by the UV sensor.
>>>
>>> Other thinks to test ?
>>>
>>> Am Samstag, 28. März 2015 01:11:24 UTC+1 schrieb Thomas Keffer:

 My apologies. I am not very familiar with the WMR200 driver. It appears 
 that it gets the archive interval from the [WMR200] section of weewx.conf. 
 Try this:

 [WMR200]
 # This section is for the Oregon Scientific WMR200
 
 # The station model, e.g., WMR200, WMR200A, Radio Shack W200
 model = WMR200

 archive_interval = 300
 
 # The driver to use:
 driver = weewx.drivers.wmr200


 -tk

 On Fri, Mar 27, 2015 at 4:44 PM, Markus Roth  
 wrote:

 i have set it to 300 but the webside update comes every 60 sec.
 Is that ok ?

 Am Freitag, 27. März 2015 22:17:53 UTC+1 schrieb Thomas Keffer:

 Try changing the record_generation option to 'software':

 [StdArchive]
 ...
 archive_interval = 300
 ...
 record_generation = software

 -tk


 On Fri, Mar 27, 2015 at 2:03 PM, Markus Roth  
 wrote:

 interesting at the 

[weewx-user] Skin pws added rain over 15 minutes

[Nicolas Cazan]

Hello I have a question: I try to add the rain fell on the last fifteen 
minutes in the XML/weewx_pws.xml file so I modified 
skins/PWS/weewx_pws.xml.tmpl and added in line rain . 

 realtime="minrain">$span($time_delta=900).rain.sum.formatted

 
But it does not work nothing adds, can you help me, thanks in advance

-- 
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[2]: [weewx-user] WMR 200 and weewx 3.1 missing values

[Joseph Tomeh]

Hello,

Thanks a lot for your quick answer and sorry for my late response, i was 
very busy and not at home since last time.


 i studied the weewx python code. I'dont know very well this programming 
language and I'am not able to write a weewx service. But I think, we can 
solve easyly this issue without modifying the driver code and writing a 
weewx service.


First of all, i proposed a patch (please see my today's github 
contribution).
This patch avoid to send bad records for instance for Wunderground et 
produce splittered graphs. I hope i will be accepted, i have tested it, 
it is working well.


In second time, i think, it could be possible to do the same test "if 
record['outTemp']"  in the 2 functions "_addSingleRecord" in manager.py.
if we prevent from adding bad records into the archive and daily tables 
the database will be still consistent


what do you think about these proposals ?

Best regards

-- Message d'origine --
De: "Thomas Keffer" 
À: "weewx-user" 
Envoyé : 21/07/2017 16:32:27
Objet : Re: [weewx-user] WMR 200 and weewx 3.1 missing values

In weewx, if a driver detects a bad value, it should replace it with a 
null. I'm not sure whether the existing driver does this (I did not 
write it).


One of the reasons weewx is able to support so many different types of 
hardware is that it has a very simple, and very consistent, data model 
. One of the 
guidelines of that model is, "The driver should emit only data it 
receives from the hardware (no "filling in the gaps")." If you want to 
do that, that would be the job of a weewx service.


However, we looked into caching values about a year ago and decided not 
to do it for reasons given in the Issue thread 
. What you're proposing is a 
little simpler, but could run into some of the same problems.


-tk



On Fri, Jul 21, 2017 at 1:20 AM,  wrote:

Hello,

I have read this topic because i have the same trouble too. I used the 
latest version of weewx  (3.7.1)  and the latest driver version for 
wmr200 (3.3.2).


I have a WMR200 station since 2010.
I wrote my own driver with c#. But I decided this year to plug my 
station to a Raspberrypi and my c# app not working. Then I decided to 
use Weewx.


The WMR200 is well known to produce sometime bad values (NA ou null 
values) sometime the pressure, sometime temperature, ...


In my c# driver, I used the following strategy, if i receive a null 
record for a field, i replace it with the previous recorded value 
(only the erreneous field, not the whole record)


I think that could be done too in weewx. An other strategy could be 
done in StdQC an could allow us to reject a whole record if some 
values are errouneous eg NULL ou NA;


Do you think that could be done in next version of the WMR200's 
driver. I don't know Python, I can't help to change the python WMR200 
driver


Congratulation for this very good job.
Best regards


Le samedi 28 mars 2015 02:21:26 UTC+1, Markus Roth a écrit :

Works not i have the first N/A by the UV sensor.

Other thinks to test ?

Am Samstag, 28. März 2015 01:11:24 UTC+1 schrieb Thomas Keffer:
My apologies. I am not very familiar with the WMR200 driver. It 
appears that it gets the archive interval from the [WMR200] section 
of weewx.conf. Try this:



[WMR200]
# This section is for the Oregon Scientific WMR200

# The station model, e.g., WMR200, WMR200A, Radio Shack W200
model = WMR200

archive_interval = 300

# The driver to use:
driver = weewx.drivers.wmr200


-tk

On Fri, Mar 27, 2015 at 4:44 PM, Markus Roth  
wrote:

i have set it to 300 but the webside update comes every 60 sec.
Is that ok ?

Am Freitag, 27. März 2015 22:17:53 UTC+1 schrieb Thomas Keffer:

Try changing the record_generation option to 'software':

[StdArchive]
...
archive_interval = 300
...
record_generation = software

-tk


On Fri, Mar 27, 2015 at 2:03 PM, Markus Roth  
wrote:

interesting at the confic stand :

[StdArchive]
# This section is for configuring the archive service.

# If your station hardware supports data logging then the 
archive interval

# will be downloaded from the station.
# Otherwise, you must specify it below (in seconds):
archive_interval = 300

but i have not cange anything on it.
Or you mean any other ?


Am Freitag, 27. März 2015 21:27:39 UTC+1 schrieb Thomas Keffer:

Thank you, Markus

The problem is that you have a one minute archive interval. This 
is very short. There will be occasions where you temperature 
sensor will not emit a value within such a short time, and so 
you will get a null value for outTemp.


Either live with the problem, or increase your archive interval 
to 5 minutes.


-tk

On Fri, Mar 27, 2015 at 1:20 PM, Markus Roth 
 wrote:





484540.0,