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 

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