[weewx-user] Re: Resource busy - raspbian buster, weewx 4 and WMR200

[Joseph TOMEH]

Hello all, 

Almost same error message too.
I used with Weewx 3.9.1(Python2) for a long time and it worked well with no 
issues.
I have just updated to version Weewx 4.1.1 (python3), and this error occurs 
several time a day.
This is the only change I have done

:(

Regards


2854 Jun 10 11:02:01 raspberrypi weewx[21331] INFO weewx.drivers.wmr200: 
sensor map is {'altimeter': 'altimeter', 'pressure': 'pressure', 
'windSpeed': 'wind_speed', 'windDir': 'wind_dir', 'windGust': 
'wind_gust$2855 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL 
weewx.drivers.wmr200: open_device() Unable to claim USB interface. Reason: 
[Errno 16] Resource busy
2856 Jun 10 11:02:01 raspberrypi weewx[21331] ERROR weewx.engine: Import of 
driver failed: [Errno 16] Resource busy ()
2857 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   Traceback (most recent call last):
2858 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 File "/home/weewx/bin/weewx/drivers/wmr200.py", line 193, in 
open_device
2859 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   self.handle.claimInterface(self.interface)
2860 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 File "/usr/local/lib/python3.7/dist-packages/usb/legacy.py", line 
230, in claimInterface
2861 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   util.claim_interface(self.dev, interface)
2862 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 File "/usr/local/lib/python3.7/dist-packages/usb/util.py", line 
205, in claim_interface
2863 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   device._ctx.managed_claim_interface(device, interface)
2864 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 File "/usr/local/lib/python3.7/dist-packages/usb/core.py", line 
102, in wrapper
2865 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   return f(self, *args, **kwargs)
2866 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 File "/usr/local/lib/python3.7/dist-packages/usb/core.py", line 
167, in managed_claim_interface
2867 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   self.backend.claim_interface(self.handle, i)
2868 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 File 
"/usr/local/lib/python3.7/dist-packages/usb/backend/libusb1.py", line 811, 
in claim_interface
2869 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   _check(self.lib.libusb_claim_interface(dev_handle.handle, intf))
2870 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 File 
"/usr/local/lib/python3.7/dist-packages/usb/backend/libusb1.py", line 595, 
in _check
2871 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   raise USBError(_strerror(ret), ret, _libusb_errno[ret])
2872 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   usb.core.USBError: [Errno 16] Resource busy
2873 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 
2874 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
   During handling of the above exception, another exception occurred:
2875 Jun 10 11:02:01 raspberrypi weewx[21331] CRITICAL weewx.engine:
 


-- 
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/893d46d9-2b6d-47ba-8d0f-75acfe151cfdo%40googlegroups.com.

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" <cman...@gmail.com>
À: "weewx-user" <weewx-user@googlegroups.com>
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" <andrew.s...@gmail.com>
À: "weewx-user" <weewx...@googlegroups.com>
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" <tke...@gmail.com>
À: "weewx-user" <weewx...@googlegroups.com>
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 <http://weewx.com/docs/customizing.htm#General_guidelines>. 
One of the guidelines of that model is, "The driver should emit 
only data it receives from the hardware (no "filling 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" <andrew.s.r.mil...@gmail.com>
À: "weewx-user" <weewx-user@googlegroups.com>
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" <tke...@gmail.com>
À: "weewx-user" <weewx...@googlegroups.com>
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 <http://weewx.com/docs/customizing.htm#General_guidelines>. 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 
<https://github.com/weewx/weewx/issues/31>. 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, <jto...@gmail.com> 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 m

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,