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

[Chris Manton]

It looks like the initial error was a read failure from the device.

The second error is despite retries the resource is not reset to re-open and 
re-claim.


Since the system worked for a long time without this failure, I would think 
something about the new installation.


If the initial error 'froze' the usb bus, no amount of software tries will  
jiggle it lose.


mai 08 13:08:10 domo python3[322]: weewx[322] ERROR weewx.drivers.wmr200: USB 
read_device overflow error
mai 08 13:08:10 domo python3[322]: weewx[322] ERROR weewx.drivers.wmr200: USB 
device read error
mai 08 13:08:11 domo python3[322]: weewx[322] ERROR weewx.drivers.wmr200: USB 
polling thread unexpectedly 


I think we'd need to know the state of the wmr200 and/or usb bus at the time of 
failure, or understand exactly what kind of read_device overflow error occurred.


On Friday, May 8, 2020 at 7:28:21 AM UTC-7, Tom Keffer wrote:
>
> I've asked the author of the driver for help.
>
> On Fri, May 8, 2020 at 6:49 AM CloDi > 
> wrote:
>
>> Hi.
>>
>> Same error. I have activated the debug and joined the log.
>>
>> I don't know python to help to debug. But I can test any script...
>>
>> Thanks!
>>
>>
>> Le 07/05/2020 à 16:29, Tom Keffer a écrit :
>>
>> I am guessing the problem is that the WMR200 driver is not always 
>> releasing the USB interface, despite saying it has.
>>
>> One thing you can try is run weewxd with the loop_on_init flag. This 
>> will cause it to keep trying. See the section *General 
>> * in the User's Guide.
>>
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/c1e74582-84d6-8108-1f38-629238f1f67e%40gmail.com
>>  
>> 
>> .
>>
>

-- 
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/004c441a-22d9-47b4-804f-efda94a83866%40googlegroups.com.

[weewx-user] Re: Weewx "off line"

[Chris Manton]

Hi,

Do you have a longer stack trace of the log prior to failure and could you 
provide your configuration file for this set up ?

thx,


On Wednesday, November 20, 2019 at 7:01:44 PM UTC-8, Teva MERVIN wrote:
>
> OK tk.
>
> Le mardi 19 novembre 2019 16:36:37 UTC+11, Teva MERVIN a écrit :
>>
>> Hello.
>> I have a problem that I can not identify.
>> It happens at least once a day, and I have to restart weewx.
>> Do you have ideas?
>>
>> root@Nas:~# service weewx status
>> ● weewx.service - LSB: weewx weather system 
>>   Loaded: loaded (/etc/init.d/weewx; generated) 
>>   Active: active (exited) since Sun 2019-11-17 19:09:21 +11; 1 day 21h 
>> ago 
>> Docs: man:systemd-sysv-generator(8) 
>>  Process: 2094 ExecStart=/etc/init.d/weewx start (code=exited, 
>> status=0/SUCCESS) 
>>
>> nov. 19 13:34:26 Nas weewx[2110]: File 
>> "/usr/share/weewx/weewx/engine.py", line 601, in new_archive_record 
>> nov. 19 13:34:26 Nas weewx[2110]:  
>>  dbmanager.addRecord(event.record, accumulator=self.old_accumulator) 
>> nov. 19 13:34:26 Nas weewx[2110]: File 
>> "/usr/share/weewx/weewx/manager.py", line 246, in addRecord 
>> nov. 19 13:34:26 Nas weewx[2110]:  
>>  self._addSingleRecord(record, cursor, log_level) 
>> nov. 19 13:34:26 Nas weewx[2110]: File 
>> "/usr/share/weewx/weewx/manager.py", line 1212, in _addSingleRecord 
>> nov. 19 13:34:26 Nas weewx[2110]:   _weight = 
>> self._calc_weight(record) 
>> nov. 19 13:34:26 Nas weewx[2110]: File 
>> "/usr/share/weewx/weewx/manager.py", line 1582, in _calc_weight 
>> nov. 19 13:34:26 Nas weewx[2110]:   raise 
>> ValueError("Non-positive value for record field 'interval': %s" % 
>> (record['interval'], )) 
>> nov. 19 13:34:26 Nas weewx[2110]:   ValueError: Non-positive 
>> value for record field 'interval': 0 
>> nov. 19 13:34:26 Nas weewx[2110]:   Exiting.
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a43888d1-975a-48d3-9543-8d42053df1e0%40googlegroups.com.

Re: [weewx-user] Cheetahgenerator gives "math domain error" while processing Seasons skin

[Chris Manton]

I suppose if the archived packets are presented out of order there could be 
a negative interval...

I have not seen this but the wmr200 is full of wonderful surprises.

One potential drive-by fix is to drop all packets satisfying this failing 
condition...here is one untested fix:


$ git diff
diff --git a/bin/weewx/drivers/wmr200.py b/bin/weewx/drivers/wmr200.py
index eaab5a14..62b743e0 100644
--- a/bin/weewx/drivers/wmr200.py
+++ b/bin/weewx/drivers/wmr200.py
@@ -1943,7 +1943,13 @@ class WMR200(weewx.drivers.AbstractDevice):
 timestamp_packet_interval = timestamp_packet_current \
 - timestamp_packet_previous

-if pkt.timestamp_record() > (timestamp_packet_previous
+if timestamp_packet_interval < 0:
+loginf(('genStartup() Discarding received archive'
+' record that presented out-of-order'
+' current_threshold:%s previous_timestamp:%s')
+% 
(weeutil.weeutil.timestamp_to_string(pkt.timestamp_record())
+   
 weeutil.weeutil.timestamp_to_string(timestamp_packet_previous)))
+elif pkt.timestamp_record() > (timestamp_packet_previous
  + self._archive_threshold):
 loginf(('genStartup() Discarding received archive'
 ' record exceeding archive interval cnt:%d'

On Friday, September 14, 2018 at 6:07:48 AM UTC-7, Thomas Keffer wrote:
>
> Good.
>
> Looking through the WMR200 driver code (I didn't write it), it appears 
> that a positive value for 'interval' is not guaranteed. I'll ask the author 
> to take a look at it.
>
> -tk
>
> On Fri, Sep 14, 2018 at 5:44 AM Rahul Bedi > 
> wrote:
>
>> Yup found a record with -ve interval, changed that to 5 as thats what I 
>> am using. 
>>
>> And problem fixed !!
>>
>> Thanks a lot.
>>
>> Not sure how this bad data entered into the db.
>>
>> Will be great if there is utility that finds such errors in the db and 
>> flags them.
>>
>> - Rahul
>>
>> On Fri, Sep 14, 2018 at 5:48 PM Thomas Keffer > > wrote:
>>
>>> I think the thing to do is to figure out how a negative value got in 
>>> there, fix that, then rebuild the daily summaries.
>>>
>>> One possibility is that a record in your database has a negative value 
>>> for 'interval' --- the time length of an archive record. Let's check that.
>>>
>>> *sqlite3 /var/lib/weewx/weewx.sdb*
>>> sqlite> *SELECT datetime(dateTime, 'unixepoch','localtime'), interval 
>>> FROM archive WHERE interval<0;*
>>>
>>> -tk
>>>
>>> On Fri, Sep 14, 2018 at 5:06 AM Rahul Bedi >> > wrote:
>>>
 Here is what I get:

 2018-08-02 00:00:00|2851473.0|86400
 2018-08-03 00:00:00|2139447.0|86400
 2018-08-04 00:00:00|2867211.0|86400
 2018-08-05 00:00:00|3306195.0|86400
 2018-08-06 00:00:00|3167394.0|86400
 2018-08-07 00:00:00|2924283.0|86400
 2018-08-08 00:00:00|2255208.0|86400
 2018-08-09 00:00:00|2797065.0|86400
 2018-08-10 00:00:00|2693187.0|86400
 2018-08-11 00:00:00|2981601.0|86400
 2018-08-12 00:00:00|3869136.0|86400
 2018-08-13 00:00:00|3632787.0|86400
 2018-08-14 00:00:00|2651829.0|86400
 2018-08-15 00:00:00|2104410.0|86400
 2018-08-16 00:00:00|3682674.0|86400
 2018-08-17 00:00:00|342.0|86400
 2018-08-18 00:00:00|3855531.0|86400
 2018-08-19 00:00:00|3875121.0|86400
 2018-08-20 00:00:00|3915861.0|86400
 2018-08-21 00:00:00|3523719.0|86400
 2018-08-22 00:00:00|1637909.95179334|85620
 2018-08-23 00:00:00|506702.215048778|25380
 2018-08-24 00:00:00|523285.18735593|101340
 2018-08-25 00:00:00|2047231.90482286|92280
 2018-08-26 00:00:00|2207680.59885907|85800
 2018-08-27 00:00:00|2112653.43729687|78000
 2018-08-28 00:00:00|1927695.38113441|85200
 2018-08-29 00:00:00|1696867.80614767|76740
 2018-08-30 00:00:00|1892572.6564943|85500
 2018-08-31 00:00:00|1669207.56530998|86100
 2018-09-01 00:00:00|1882876.90336366|85080
 2018-09-02 00:00:00|1552040.97205686|86100
 2018-09-03 00:00:00|1550916.37957731|86100
 2018-09-04 00:00:00|1093704.34743737|85740
 2018-09-05 00:00:00|1688380.4274756|86100
 2018-09-06 00:00:00|2349485.94738889|86100
 2018-09-07 00:00:00|2676307.36370007|85560
 2018-09-08 00:00:00|2198034.86178985|86100
 2018-09-09 00:00:00|-7107216.29856356|-302280
 2018-09-10 00:00:00|288713.672694377|85560
 2018-09-11 00:00:00|351094.880509644|85860
 2018-09-12 00:00:00|441249.222795585|85500
 2018-09-13 00:00:00|60033.1634844758|85620
 2018-09-14 00:00:00|21222.2555021576|62820

 I am guessing that the negative values above may be the culprit. How 
 are these populated in the archive_day_wind table or should I just edit 
 these values out ?

 - Rahul


 On Fri, Sep 14, 2018 at 5:19 PM Thomas Keffer >>> > wrote:

> You're on the right track: 

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