Re: [weewx-user] Re: Te923 driver is not starting anymore.
Den 04-10-2016 kl. 16:53 skrev mwall:
please defer doing the changes i suggested in my last post.
OK.
first try using the attached te923-0.22rc1.py
run it as is (reset is commented)
Tried that - it works :-)
It did log the same first error again:
Oct 5 08:21:22 mail2 weewx[3819]: te923: Failed attempt 1 of 5 to read
data: [Errno None] Opkoblingen overskred tidsgrænsen
The Danish text means connection timeout
but this time it recovered nicely for it.
I tried to stop and start weewx a few more times - same 1 error each
time, but it recovered from it each time too. Nice to see it finally
working :-)
full log here:
Oct 5 08:21:20 mail2 weewx[3819]: engine: Initializing weewx version 3.5.0
Oct 5 08:21:20 mail2 weewx[3819]: engine: Using Python 2.7.5 (default,
Sep 15 2016, 22:37:39) #012[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)]
Oct 5 08:21:20 mail2 weewx[3819]: engine: Platform
Linux-3.10.0-327.36.1.el7.x86_64-x86_64-with-centos-7.2.1511-Core
Oct 5 08:21:21 mail2 weewx[3819]: engine: Using configuration file
/etc/weewx/weewx.conf
Oct 5 08:21:21 mail2 weewx[3819]: engine: Loading station type TE923
(weewx.drivers.te923)
Oct 5 08:21:21 mail2 weewx[3819]: te923: driver version is 0.22rc1
Oct 5 08:21:21 mail2 weewx[3819]: te923: polling interval is 10
Oct 5 08:21:21 mail2 weewx[3819]: te923: observation map is {'bat_1':
'outTempBatteryStatus', 'bat_3': 'extraBatteryStatus2', 'bat_2':
'extraBatteryStatus1', 'bat_5': 'extraBatteryStatus4', 'bat_4':
'extraBatteryStatus3', 'bat_wind': 'windBatteryStatus', 't_in':
'inTemp', 'link_rain': 'rainLinkStatus', 't_5': 'extraTemp4', 'h_in':
'inHumidity', 'h_4': 'extraHumid3', 'h_5': 'extraHumid4', 'h_2':
'extraHumid1', 'h_3': 'extraHumid2', 'h_1': 'outHumidity', 't_2':
'extraTemp1', 'link_2': 'extraLinkStatus1', 'link_uv': 'uvLinkStatus',
'link_wind': 'windLinkStatus', 'uv': 'UV', 'bat_uv': 'uvBatteryStatus',
'link_5': 'extraLinkStatus4', 'bat_rain': 'rainBatteryStatus', 'link_3':
'extraLinkStatus2', 't_3': 'extraTemp2', 'link_1': 'outLinkStatus',
't_1': 'outTemp', 't_4': 'extraTemp3', 'link_4': 'extraLinkStatus3'}
Oct 5 08:21:21 mail2 weewx[3819]: te923: Found device on USB bus= device=
Oct 5 08:21:22 mail2 weewx[3819]: te923: Failed attempt 1 of 5 to read
data: [Errno None] Opkoblingen overskred tidsgrænsen
Oct 5 08:21:26 mail2 weewx[3819]: te923: logger capacity 3442 records
Oct 5 08:21:26 mail2 weewx[3819]: te923: station time is 144927.0,
computer time is 1475648486
Oct 5 08:21:26 mail2 weewx[3819]: engine: StdConvert target unit is 0x1
Oct 5 08:21:26 mail2 weewx[3819]: wxcalculate: The following values
will be calculated:
barometer=prefer_hardware,windchill=prefer_hardware,dewpoint=prefer_hardware,appTemp=prefer_hardware,rainRate=prefer_hardware,windrun=prefer_hardware,heatindex=prefer_hardware,maxSolarRad=prefer_hardware,humidex=prefer_hardware,pressure=prefer_hardware,inDewpoint=prefer_hardware,ET=prefer_hardware,altimeter=prefer_hardware,cloudbase=prefer_hardware
Oct 5 08:21:26 mail2 weewx[3819]: wxcalculate: The following algorithms
will be used for calculations: altimeter=aaNOAA,maxSolarRad=RS
Oct 5 08:21:26 mail2 weewx[3819]: engine: Archive will use data binding
wx_binding
Oct 5 08:21:26 mail2 weewx[3819]: engine: Record generation will be
attempted in 'hardware'
Oct 5 08:21:26 mail2 weewx[3819]: engine: Using archive interval of 60
seconds
Oct 5 08:21:28 mail2 weewx[3819]: engine: Using binding 'wx_binding' to
database 'weewx.sdb'
Oct 5 08:21:28 mail2 weewx[3819]: manager: Starting backfill of daily
summaries
Oct 5 08:21:28 mail2 weewx[3819]: manager: Daily summaries up to date
Oct 5 08:21:30 mail2 weewx[3819]: alarm: Alarm set for expression:
'outTemp < ((8.0*9/5)+32)'
Oct 5 08:21:30 mail2 weewx[3819]: lowBattery: LowBattery alarm turned
on. Count threshold is 2
Oct 5 08:21:30 mail2 weewx[3819]: engine: Starting up weewx version 3.5.0
Oct 5 08:21:30 mail2 weewx[3819]: te923: reading records from logger
since 1475645940
Oct 5 08:21:31 mail2 weewx[3819]: te923: read 0 records from logger
Oct 5 08:21:31 mail2 weewx[3819]: manager: added record 2016-10-05
07:50:00 CEST (1475646600) to database 'weewx.sdb'
Oct 5 08:21:31 mail2 weewx[3819]: manager: added record 2016-10-05
07:50:00 CEST (1475646600) to daily summary in 'weewx.sdb'
Oct 5 08:21:36 mail2 weewx[3819]: alarm: Alarm expression "outTemp <
((8.0*9/5)+32)" evaluated True at 2016-10-05 07:50:00 CEST (1475646600)
Oct 5 08:21:37 mail2 weewx[3819]: manager: added record 2016-10-05
07:55:00 CEST (1475646900) to database 'weewx.sdb'
Oct 5 08:21:37 mail2 weewx[3819]: manager: added record 2016-10-05
07:55:00 CEST (1475646900) to daily summary in 'weewx.sdb'
Oct 5 08:21:37 mail2 weewx[3819]: manager: added record 2016-10-05
08:00:00 CEST (1475647200) to database 'weewx.sdb'
Oct 5 08:21:37 mail2 weewx[3819]: manager: added record 2016-10-05
08:00:00 CEST (1475647200) to daily summary in 'weewx.sdb'
Oct 5 08:21:37 mail2 weewx
Re: [weewx-user] Re: Te923 driver is not starting anymore.
allan, please defer doing the changes i suggested in my last post. first try using the attached te923-0.22rc1.py run it as is (reset is commented) if that fails, uncomment the reset after you have tried that we can revisit the pyusb version and error handling m -- 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. #!/usr/bin/env python # # Copyright 2013-2015 Matthew Wall, Andrew Miles # See the file LICENSE.txt for your full rights. # # Thanks to Andrew Miles for figuring out how to read history records # and many station parameters. # Thanks to Sebastian John for the te923tool written in C (v0.6.1): # http://te923.fukz.org/ # Thanks to Mark Teel for the te923 implementation in wview: # http://www.wviewweather.com/ # Thanks to mrbalky: # http://www.mrbalky.com/tag/te923/ """Classes and functions for interfacing with te923 weather stations. These stations were made by Hideki and branded as Honeywell, Meade, IROX Pro X, Mebus TE923, and TFA Nexus. They date back to at least 2007 and are still sold (sparsely in the US, more commonly in Europe) as of 2013. Apparently there are at least two different memory sizes. One version can store about 200 records, a newer version can store about 3300 records. The firmware version of each component can be read by talking to the station, assuming that the component has a wireless connection to the station, of course. To force connection between station and sensors, press and hold DOWN button. To reset all station parameters: - press and hold SNOOZE and UP for 4 seconds - press SET button; main unit will beep - wait until beeping stops - remove batteries and wait 10 seconds - reinstall batteries >From the Meade TE9233W manual (TE923W-M_IM(ENG)_BK_010511.pdf): Remote temperature/humidty sampling interval: 10 seconds Remote temperature/humidity transmit interval: about 47 seconds Indoor temperature/humidity sampling interval: 10 seconds Indoor pressure sampling interval: 20 minutes Rain counter transmitting interval: 183 seconds Wind direction transmitting interval: 33 seconds Wind/Gust speed display update interval: 33 seconds Wind/Gust sampling interval: 11 seconds UV transmitting interval: 300 seconds Rain counter resolution: 0.03 in (0.6578 mm) Battery status of each sensor is checked every hour This implementation polls the station for data. Use the polling_interval to control the frequency of polling. Default is 10 seconds. The manual says that a single bucket tip is 0.03 inches. In reality, a single bucket tip is between 0.02 and 0.03 in (0.508 to 0.762 mm). This driver uses a value of 0.02589 in (0.6578 mm) per bucket tip. The station has altitude, latitude, longitude, and time. Setting the time does not persist. If you set the station time using weewx, the station initially indicates that it is set to the new time, but then it reverts. Notes From/About Other Implementations Apparently te923tool came first, then wview copied a bit from it. te923tool provides more detail about the reason for invalid values, for example, values out of range versus no link with sensors. However, these error states have not yet been corroborated. There are some disagreements between the wview and te923tool implementations. >From the te923tool: - reading from usb in 8 byte chunks instead of all at once - length of buffer is 35, but reads are 32-byte blocks - windspeed and windgust state can never be -1 - index 29 in rain count, also in wind dir >From wview: - wview does the 8-byte reads using interruptRead - wview ignores the windchill value from the station - wview treats the pressure reading as barometer (SLP), then calculates the station pressure and altimeter pressure Memory Map 0x02 - Last sample: [00] = Month (Bits 0-3), Weekday (1 = Monday) (Bits 7:4) [01] = Day [02] = Hour [03] = Minute [04] ... reading as below 0x020001 - Current readings: [00] = Temp In Low BCD [01] = Temp In High BCD (Bit 5 = 0.05 deg, Bit 7 = -ve) [02] = Humidity In [03] = Temp Channel 1 Low (No link = Xa) [04] = Temp Channel 1 High (Bit 6 = 1, Bit 5 = 0.05 deg, Bit 7 = +ve) [05] = Humidity Channel 1 (No link = Xa) [06] = Temp Channel 2 Low (No link = Xa) [07] = Temp Channel 2 High (Bit 6 = 1, Bit 5 = 0.05 deg, Bit 7 = +ve) [08] = Humidity Channel 2 (No link = Xa) [09] = Temp Channel 3 Low (No link = Xa) [10] = Temp Channel 3 High (Bit 6 = 1, Bit 5 = 0.05 deg, Bit 7 = +ve) [11] = Humidity Channel 3 (No link = Xa) [12] = Temp Channel 4 Low (No link = Xa) [13] = Temp Channel 4 High (Bit 6 = 1, Bit 5 = 0.05 deg, Bit 7 = +ve) [14] = Humidity Channel 4 (No link = Xa) [15] = Temp Channel 5 Low (No link = Xa) [16] = Temp Channel 5 High (Bit 6 = 1, Bit 5 = 0.05 deg, Bit 7 = +ve) [17] = Humidity Channel 5 (No lin
Re: [weewx-user] Re: Te923 driver is not starting anymore.
On Monday, October 3, 2016 at 10:35:53 PM UTC-4, Allan H wrote:
>
> Den 04-10-2016 kl. 03:22 skrev mwall:
> > there already is exception handling (and retries) happening in the _read
>
> really ? Doesn't seem to work
>
> Here is what I added in the driver:
>
> def read_memory_size(self):
> loginf("Entry read_memory")
> buf = self._read(0xfc)
> loginf("After self_read")
>
> Output in syslog is:
> (when reset is disabled))
>
> Oct 4 02:17:08 mail2 weewx[25331]: engine: Loading station type TE923
> (weewx.drivers.te923)
> Oct 4 02:17:08 mail2 weewx[25331]: te923: driver version is 0.21
> Oct 4 02:17:08 mail2 weewx[25331]: te923: polling interval is 10
> Oct 4 02:17:08 mail2 weewx[25331]: te923: observation map is {'bat_1':
> 'outTempBatteryStatus', 'bat_3': 'extraBatteryStatus2', 'bat_2':
> 'extraBatteryStatus1', 'bat_5': 'extraBatteryStatus4', 'bat_4':
> 'extraBatteryStatus3', 'bat_wind': 'windBatteryStatus', 't_in':
> 'inTemp', 'link_rain': 'rainLinkStatus', 't_5': 'extraTemp4', 'h_in':
> 'inHumidity', 'h_4': 'extraHumid3', 'h_5': 'extraHumid4', 'h_2':
> 'extraHumid1', 'h_3': 'extraHumid2', 'h_1': 'outHumidity', 't_2':
> 'extraTemp1', 'link_2': 'extraLinkStatus1', 'link_uv': 'uvLinkStatus',
> 'link_wind': 'windLinkStatus', 'uv': 'UV', 'bat_uv': 'uvBatteryStatus',
> 'link_5': 'extraLinkStatus4', 'bat_rain': 'rainBatteryStatus', 'link_3':
> 'extraLinkStatus2', 't_3': 'extraTemp2', 'link_1': 'outLinkStatus',
> 't_1': 'outTemp', 't_4': 'extraTemp3', 'link_4': 'extraLinkStatus3'}
> Oct 4 02:17:08 mail2 weewx[25331]: te923: Found device on USB bus=
> device=
> Oct 4 02:17:08 mail2 weewx[25331]: te923: Entry read_memory
> Oct 4 02:17:10 mail2 weewx[25331]: engine: Unable to load driver:
> [Errno None] Opkoblingen overskred tidsgrænsen
> Oct 4 02:17:10 mail2 weewx[25331]: Waiting 60 seconds then
> retrying...
>
allan,
thank you for the detailed response.
the _read method does a number of retries, and it logs each failure. only
after failing multiple times will it raise the exception that causes the
'Unable to load driver' message.
you should see even more log messages if you set debug=1 in weewx.conf
if you have been running with debug=1, and what you posted is untouched log
output, then please check the logging configuration for your system -
either systemd logging or rsyslog configuration is hiding weewx log
messages.
another possibility is that your pyusb version is raising a timeout error
that is not a usb.USBError, so it slips through the error handling in
_read. in the _read method in te923.py try changing this:
except (BadRead, BadHeader, usb.USBError), e:
logerr("Failed attempt %d of %d to read data: %s" %
(cnt + 1, self.max_tries, e))
to this:
except (BadRead, BadHeader, usb.USBError, Exception), e:
logerr("Failed attempt %d of %d to read data: %s (%s)" %
(cnt + 1, self.max_tries, e, type(e)))
finally, you are using pyusb 1.0.0-11. after you have tried the code
change above and gotten its output, you might try reverting the code then
installing pyusb 0.4 to see what difference that makes.
m
--
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: [weewx-user] Re: Te923 driver is not starting anymore.
Den 04-10-2016 kl. 03:22 skrev mwall:
I kind of wonder, what really was changed. In older releases of weewx
(2.7, 3.0, 3.1 ) I never had any problems with connection to the
station.
the first significant changes happened in 3.2. reading from the logger
was added in 3.4
Well, I'm unsure about if I even tested versions between 3.1 and 3.4;
the station is in my summer house.
I could try to find those old version and test, if you think it makes
any sense.
I have tried the newer drivers, and 0.21 still doesn't work at all,
unless I uncomment the #reset
so you are saying that on centos 7, reset works but no reset does not work?
Yes, you fixed this in 0.18rc8 for me (in another thread here).
please post the following info:
- which operating system and version?
Centos 7 fully updated on PC AMD64 hw
- which version of libusb?
libusb: 0.1.4-3
libusbx: 1.0.15-4
- which version of pyusb?
1.0.0-011
- which version of udev?
Can't find that - any clues :-)
there already is exception handling (and retries) happening in the _read
really ? Doesn't seem to work
Here is what I added in the driver:
def read_memory_size(self):
loginf("Entry read_memory")
buf = self._read(0xfc)
loginf("After self_read")
Output in syslog is:
(when reset is disabled))
Oct 4 02:17:08 mail2 weewx[25331]: engine: Loading station type TE923
(weewx.drivers.te923)
Oct 4 02:17:08 mail2 weewx[25331]: te923: driver version is 0.21
Oct 4 02:17:08 mail2 weewx[25331]: te923: polling interval is 10
Oct 4 02:17:08 mail2 weewx[25331]: te923: observation map is {'bat_1':
'outTempBatteryStatus', 'bat_3': 'extraBatteryStatus2', 'bat_2':
'extraBatteryStatus1', 'bat_5': 'extraBatteryStatus4', 'bat_4':
'extraBatteryStatus3', 'bat_wind': 'windBatteryStatus', 't_in':
'inTemp', 'link_rain': 'rainLinkStatus', 't_5': 'extraTemp4', 'h_in':
'inHumidity', 'h_4': 'extraHumid3', 'h_5': 'extraHumid4', 'h_2':
'extraHumid1', 'h_3': 'extraHumid2', 'h_1': 'outHumidity', 't_2':
'extraTemp1', 'link_2': 'extraLinkStatus1', 'link_uv': 'uvLinkStatus',
'link_wind': 'windLinkStatus', 'uv': 'UV', 'bat_uv': 'uvBatteryStatus',
'link_5': 'extraLinkStatus4', 'bat_rain': 'rainBatteryStatus', 'link_3':
'extraLinkStatus2', 't_3': 'extraTemp2', 'link_1': 'outLinkStatus',
't_1': 'outTemp', 't_4': 'extraTemp3', 'link_4': 'extraLinkStatus3'}
Oct 4 02:17:08 mail2 weewx[25331]: te923: Found device on USB bus= device=
Oct 4 02:17:08 mail2 weewx[25331]: te923: Entry read_memory
Oct 4 02:17:10 mail2 weewx[25331]: engine: Unable to load driver:
[Errno None] Opkoblingen overskred tidsgrænsen
Oct 4 02:17:10 mail2 weewx[25331]: Waiting 60 seconds then
retrying...
the problem seems to be getting the usb into a sane state for communication
I agree.
as far as i can tell, the reset should happen *before* the claim
interface. what happens if you put the reset before the claimInterface
try block?
Currently, there is no reset in driver. It works, if I just uncomment
it, where it is
I think you tried to do it before in 0.18 before RC7, and that didn't
work here either.
from direct testing, it seems like the reset should only be necessary if
the usb is wedged somehow, for example if the firmware is confused, or
waiting for a read/write, etc.
I don't know why it fails as it do; but for sure, the reset should
happen, when communication fails.
Allan.
--
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: [weewx-user] Re: Te923 driver is not starting anymore.
On Monday, October 3, 2016 at 8:41:06 PM UTC-4, Allan H wrote: > > Den 12-09-2016 kl. 16:03 skrev mwall: > > On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote: > > Den 11-09-2016 kl. 16:33 skrev Allan: > > > > > Well, without the resets, it doesn't seem to load here. > > > > Follow-up: > > > > I just tried to uncomment line 1562 to get the reset back, and the > > driver immediately started to work again > > > > well that is annoying. apparently the reset is required on some > > systems, but on other systems it causes the driver to fail. > > I kind of wonder, what really was changed. In older releases of weewx > (2.7, 3.0, 3.1 ) I never had any problems with connection to the station. > the first significant changes happened in 3.2. reading from the logger was added in 3.4 > I have tried the newer drivers, and 0.21 still doesn't work at all, > unless I uncomment the #reset > so you are saying that on centos 7, reset works but no reset does not work? please post the following info: - which operating system and version? - which version of libusb? - which version of pyusb? - which version of udev? there already is exception handling (and retries) happening in the _read the problem seems to be getting the usb into a sane state for communication as far as i can tell, the reset should happen *before* the claim interface. what happens if you put the reset before the claimInterface try block? from direct testing, it seems like the reset should only be necessary if the usb is wedged somehow, for example if the firmware is confused, or waiting for a read/write, etc. m -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
Den 12-09-2016 kl. 16:03 skrev mwall: On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote: Den 11-09-2016 kl. 16:33 skrev Allan: > Well, without the resets, it doesn't seem to load here. Follow-up: I just tried to uncomment line 1562 to get the reset back, and the driver immediately started to work again well that is annoying. apparently the reset is required on some systems, but on other systems it causes the driver to fail. I kind of wonder, what really was changed. In older releases of weewx (2.7, 3.0, 3.1 ) I never had any problems with connection to the station. I have tried the newer drivers, and 0.21 still doesn't work at all, unless I uncomment the #reset This is bad, as I can't be the only PC user running Centos 7. Now, I don't know anything about Python, but I tried to hack a bit around, to figure out where it fails. That seems to happen on next line :-) more specific in the line of that function: buf = self._read(0xfc) Can you somehow try to catch the error happening here, and do the reset - and retry it ? I added a lonentry just before and after that line, and the second never shows up in log. Allan. -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
I also enabled rapidfire. Seems to be working fine. -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
Just a quick update: I updated to the current build 3.6.1 and everything seems to be working now. Using init_on_loop = True in the conf and increased the timeout to 10 seconds in the driver (aborted too often with 5 seconds). The driver still sometimes complains about not being able to claim the device, but a reboot fixed that issue (for now). I'm currently running a test over a few hours with 2 Pis and 2 stations (TFA Nexus) to see if any issues arise. If you want me to I can downgrade to 3.5.0 and try out the stuff you posted. I'll post a log later with some of the errors, none of them critical though so far. Have a nice day. :) -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
I'll get back to you once I'm at work and can test it. :) -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [weewx-user] Re: Te923 driver is not starting anymore.
I'll get back to you once I'm at work and can test it. :) -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [weewx-user] Re: Te923 driver is not starting anymore.
patrick, 0) what happens when you run when the reset is commented out? 1) do you have some other software running that is claiming the station? what does 'ps aux' tell you? 2) are you running weewx as root? 3) is the log from running weewx directly or as a daemon? 4) is the log you posted with the reset or without the reset in te923.py? (it looks like it is with reset) 5) please post the following info: os, udev, libusb, pyusb *uname -a*Linux feta 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux *cat /etc/issue*Raspbian GNU/Linux 7 *dpkg -l | grep udev*ii libgudev-1.0-0:armhf 175-7.2 armhf GObject-based wrapper library for libudev ii libudev0:armhf175-7.2 armhf libudev shared library ii udev 175-7.2 armhf /dev/ and hotplug management daemon *dpkg -l | grep libusb*ii libusb-0.1-4:armhf2:0.1.12-20+nmu1 armhf userspace USB programming library ii libusb-1.0-0:armhf2:1.0.11-1armhf userspace USB programming library *dpkg -l | grep python-usb*ii python-usb 0.4.3-1 armhf USB interface for Python try forcing the kernel to release the station: option 1: unload the hid kernel module. *warning!* this will make any mouse, keyboard, or other usb hid device stop functioning! sudo rmmod usbhid option 2: try to get usbhid to release just the station sudo bash -c "echo -n XXX > /sys/bus/usb/drivers/usbhid/unbind" where XXX is something like 2-1:1.0 - it is the usb device number for your station. you can see them all at /sys/bus/usb/devices. the easiest way to figure out the number for your station is to ls /sys/bus/usb/devices before your station is plugged in, then again after you plug in the station. after you do either option 1 or option 2, start weewx and see if you still get the 'device or resource busy' failure. the 'device or resource busy' message typically indicates one of these conditions: a) there is another process running that has claimed the usb device, e.g., another instance of weewx or some modem software b) the kernel has claimed the device, typically via usbhid, and the calls to release it in the driver code are not working c) the user running weewx does not have permission to claim the usb device (more often this is 'permission denied') d) the usb reset is invoked in the driver after claiming the interface, which causes the driver to release its claim of the interface m -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
Sorry for the messed up post. -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
On Monday, September 12, 2016 at 4:03:16 PM UTC+2, mwall wrote:
>
> On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote:
>>
>> Den 11-09-2016 kl. 16:33 skrev Allan:
>>
>> > Well, without the resets, it doesn't seem to load here.
>>
>> Follow-up:
>>
>> I just tried to uncomment line 1562 to get the reset back, and the
>> driver immediately started to work again
>>
>
> well that is annoying. apparently the reset is required on some systems,
> but on other systems it causes the driver to fail.
>
> allan, the logs you posted show bus= driver=, i.e., no value for bus or
> driver, but that was with an error of undefined symbol.
>
> when the driver is working, do you see values for bus and driver?
>
> it looks like we are in a version quagmire - some combinations of udev,
> libusb, and pyusb work, but others do not. and the usb reset seems to
> trigger it.
>
> i think we now have a unit test:
>
> - which operating system and version?
> - which version of libusb?
> - which version of pyusb?
> - which version of udev?
> - which version of te923 driver (use 0.19 if possible)
>
> with reset un-commented:
> - what happens when you run the driver directly for --readings?
> - what happens when you run the driver directly for --records=5?
> - what happens when you run weewxd directly?
> - what happens when you run weewx as daemon?
> - what happens whey you run weewx as daemon at system startup?
>
> then the same again with reset commented.
>
> for each os/libusb/udev configuration it would also be nice to know
> whether te923tool runs properly.
>
> m
>
On Monday, September 12, 2016 at 4:03:16 PM UTC+2, mwall wrote:
>
> On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote:
>>
>> Den 11-09-2016 kl. 16:33 skrev Allan:
>>
>> > Well, without the resets, it doesn't seem to load here.
>>
>> Follow-up:
>>
>> I just tried to uncomment line 1562 to get the reset back, and the
>> driver immediately started to work again
>>
>
> well that is annoying. apparently the reset is required on some systems,
> but on other systems it causes the driver to fail.
>
> allan, the logs you posted show bus= driver=, i.e., no value for bus or
> driver, but that was with an error of undefined symbol.
>
> when the driver is working, do you see values for bus and driver?
>
> it looks like we are in a version quagmire - some combinations of udev,
> libusb, and pyusb work, but others do not. and the usb reset seems to
> trigger it.
>
> i think we now have a unit test:
>
> - which operating system and version?
> - which version of libusb?
> - which version of pyusb?
> - which version of udev?
> - which version of te923 driver (use 0.19 if possible)
>
> with reset un-commented:
> - what happens when you run the driver directly for --readings?
> - what happens when you run the driver directly for --records=5?
> - what happens when you run weewxd directly?
> - what happens when you run weewx as daemon?
> - what happens whey you run weewx as daemon at system startup?
>
> then the same again with reset commented.
>
> for each os/libusb/udev configuration it would also be nice to know
> whether te923tool runs properly.
>
> m
>
Cheers,
Having the same issues. Tried doctoring the driver and -r, as daemon and
not. System is as Pi2 with Raspbian, newest stable firmware and everything
driver wise up-to-date. Weewx version is 3.5. Here's part of my log:
Sep 22 07:36:22 raspberrypi weewx[4123]: engine: Using configuration file
> /home/weewx/weewx.conf
> Sep 22 07:36:22 raspberrypi weewx[4123]: engine: Loading station type
> TE923 (weewx.drivers.te923)
> Sep 22 07:36:22 raspberrypi weewx[4123]: te923: driver version is 0.19
> Sep 22 07:36:22 raspberrypi weewx[4123]: te923: polling interval is 10
> Sep 22 07:36:22 raspberrypi weewx[4123]: te923: observation map is
> {'bat_1': 'outTempBatteryStatus', 'bat_3': 'extraBatteryStatus2', 'bat_2':
> 'extraBatteryStatus1', 'bat_5': 'extraBatteryStatus4', 'bat_4':
> 'extraBatteryStatus3', 'bat_wind': 'windBatteryStatus', 't_in': 'inTemp',
> 'link_rain': 'rainLinkStatus', 't_5': 'extraTemp4', 'h_in': 'inHumidity',
> 'h_4': 'extraHumid3', 'h_5': 'extraHumid4', 'h_2': 'extraHumid1', 'h_3':
> 'extraHumid2', 'h_1': 'outHumidity', 't_2': 'extraTemp1', 'link_2':
> 'extraLinkStatus1', 'link_uv': 'uvLinkStatus', 'link_wind':
> 'windLinkStatus', 'uv': 'UV', 'bat_uv': 'uvBatteryStatus', 'link_5':
> 'extraLinkStatus4', 'bat_rain': 'rainBatteryStatus', 'link_3':
> 'extraLinkStatus2', 't_3': 'extraTemp2', 'link_1': 'outLinkStatus', 't_1':
> 'outTemp', 't_4': 'extraTemp3', 'link_4': 'extraLinkStatus3'}
> Sep 22 07:36:22 raspberrypi weewx[4123]: te923: Found device on USB
> bus=001 device=007
> Sep 22 07:36:23 raspberrypi kernel: [ 3630.838597] usb 1-1.4: reset
> low-speed USB device number 7 using dwc_otg
> Sep 22 07:36:23 raspberrypi weewx[4123]: te923: Failed attempt 1 of 5 to
> read data: error sending control message: Device or resource busy
> Sep 22 07:36:23
Re: [weewx-user] Re: Te923 driver is not starting anymore.
On Monday, September 12, 2016 at 4:03:16 PM UTC+2, mwall wrote:
>
> On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote:
>>
>> Den 11-09-2016 kl. 16:33 skrev Allan:
>>
>> > Well, without the resets, it doesn't seem to load here.
>>
>> Follow-up:
>>
>> I just tried to uncomment line 1562 to get the reset back, and the
>> driver immediately started to work again
>>
>
> well that is annoying. apparently the reset is required on some systems,
> but on other systems it causes the driver to fail.
>
> allan, the logs you posted show bus= driver=, i.e., no value for bus or
> driver, but that was with an error of undefined symbol.
>
> when the driver is working, do you see values for bus and driver?
>
> it looks like we are in a version quagmire - some combinations of udev,
> libusb, and pyusb work, but others do not. and the usb reset seems to
> trigger it.
>
> i think we now have a unit test:
>
> - which operating system and version?
> - which version of libusb?
> - which version of pyusb?
> - which version of udev?
> - which version of te923 driver (use 0.19 if possible)
>
> with reset un-commented:
> - what happens when you run the driver directly for --readings?
> - what happens when you run the driver directly for --records=5?
> - what happens when you run weewxd directly?
> - what happens when you run weewx as daemon?
> - what happens whey you run weewx as daemon at system startup?
>
> then the same again with reset commented.
>
> for each os/libusb/udev configuration it would also be nice to know
> whether te923tool runs properly.
>
> m
>
On Monday, September 12, 2016 at 4:03:16 PM UTC+2, mwall wrote:
>
> On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote:
>>
>> Den 11-09-2016 kl. 16:33 skrev Allan:
>>
>> > Well, without the resets, it doesn't seem to load here.
>>
>> Follow-up:
>>
>> I just tried to uncomment line 1562 to get the reset back, and the
>> driver immediately started to work again
>>
>
> well that is annoying. apparently the reset is required on some systems,
> but on other systems it causes the driver to fail.
>
> allan, the logs you posted show bus= driver=, i.e., no value for bus or
> driver, but that was with an error of undefined symbol.
>
> when the driver is working, do you see values for bus and driver?
>
> it looks like we are in a version quagmire - some combinations of udev,
> libusb, and pyusb work, but others do not. and the usb reset seems to
> trigger it.
>
> i think we now have a unit test:
>
> - which operating system and version?
> - which version of libusb?
> - which version of pyusb?
> - which version of udev?
> - which version of te923 driver (use 0.19 if possible)
>
> with reset un-commented:
> - what happens when you run the driver directly for --readings?
> - what happens when you run the driver directly for --records=5?
> - what happens when you run weewxd directly?
> - what happens when you run weewx as daemon?
> - what happens whey you run weewx as daemon at system startup?
>
> then the same again with reset commented.
>
> for each os/libusb/udev configuration it would also be nice to know
> whether te923tool runs properly.
>
> m
>
Cheers,
Having the same issues. Tried doctoring the driver and -r, as daemon and
not. System is as Pi2 with Raspbian, newest stable firmware and everything
driver wise up-to-date. Weewx version is 3.5. Here's part of my log:
[quote]
Sep 22 07:36:22 raspberrypi weewx[4123]: engine: Using configuration file
/home/weewx/weewx.conf
Sep 22 07:36:22 raspberrypi weewx[4123]: engine: Loading station type TE923
(weewx.drivers.te923)
Sep 22 07:36:22 raspberrypi weewx[4123]: te923: driver version is 0.19
Sep 22 07:36:22 raspberrypi weewx[4123]: te923: polling interval is 10
Sep 22 07:36:22 raspberrypi weewx[4123]: te923: observation map is
{'bat_1': 'outTempBatteryStatus', 'bat_3': 'extraBatteryStatus2', 'bat_2':
'extraBatteryStatus1', 'bat_5': 'extraBatteryStatus4', 'bat_4':
'extraBatteryStatus3', 'bat_wind': 'windBatteryStatus', 't_in': 'inTemp',
'link_rain': 'rainLinkStatus', 't_5': 'extraTemp4', 'h_in': 'inHumidity',
'h_4': 'extraHumid3', 'h_5': 'extraHumid4', 'h_2': 'extraHumid1', 'h_3':
'extraHumid2', 'h_1': 'outHumidity', 't_2': 'extraTemp1', 'link_2':
'extraLinkStatus1', 'link_uv': 'uvLinkStatus', 'link_wind':
'windLinkStatus', 'uv': 'UV', 'bat_uv': 'uvBatteryStatus', 'link_5':
'extraLinkStatus4', 'bat_rain': 'rainBatteryStatus', 'link_3':
'extraLinkStatus2', 't_3': 'extraTemp2', 'link_1': 'outLinkStatus', 't_1':
'outTemp', 't_4': 'extraTemp3', 'link_4': 'extraLinkStatus3'}
Sep 22 07:36:22 raspberrypi weewx[4123]: te923: Found device on USB bus=001
device=007
Sep 22 07:36:23 raspberrypi kernel: [ 3630.838597] usb 1-1.4: reset
low-speed USB device number 7 using dwc_otg
Sep 22 07:36:23 raspberrypi weewx[4123]: te923: Failed attempt 1 of 5 to
read data: error sending control message: Device or resource busy
Sep 22 07:36:23 raspberrypi kernel: [ 3631.141743] hid-gene
Re: [weewx-user] Re: Te923 driver is not starting anymore.
On Monday, September 12, 2016 at 4:03:16 PM UTC+2, mwall wrote:
>
> On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote:
>>
>> Den 11-09-2016 kl. 16:33 skrev Allan:
>>
>> > Well, without the resets, it doesn't seem to load here.
>>
>> Follow-up:
>>
>> I just tried to uncomment line 1562 to get the reset back, and the
>> driver immediately started to work again
>>
>
> well that is annoying. apparently the reset is required on some systems,
> but on other systems it causes the driver to fail.
>
> allan, the logs you posted show bus= driver=, i.e., no value for bus or
> driver, but that was with an error of undefined symbol.
>
> when the driver is working, do you see values for bus and driver?
>
> it looks like we are in a version quagmire - some combinations of udev,
> libusb, and pyusb work, but others do not. and the usb reset seems to
> trigger it.
>
> i think we now have a unit test:
>
> - which operating system and version?
> - which version of libusb?
> - which version of pyusb?
> - which version of udev?
> - which version of te923 driver (use 0.19 if possible)
>
> with reset un-commented:
> - what happens when you run the driver directly for --readings?
> - what happens when you run the driver directly for --records=5?
> - what happens when you run weewxd directly?
> - what happens when you run weewx as daemon?
> - what happens whey you run weewx as daemon at system startup?
>
> then the same again with reset commented.
>
> for each os/libusb/udev configuration it would also be nice to know
> whether te923tool runs properly.
>
> m
>
Cheers,
Having the same issues. Tried doctoring the driver and -r, as daemon and
not. System is as Pi2 with Raspbian, newest stable firmware and everything
driver wise up-to-date. Weewx version is 3.5. Here's part of my log:
[code]
Sep 22 07:36:22 raspberrypi weewx[4123]: engine: Using configuration file
/home/weewx/weewx.conf
Sep 22 07:36:22 raspberrypi weewx[4123]: engine: Loading station type TE923
(weewx.drivers.te923)
Sep 22 07:36:22 raspberrypi weewx[4123]: te923: driver version is 0.19
Sep 22 07:36:22 raspberrypi weewx[4123]: te923: polling interval is 10
Sep 22 07:36:22 raspberrypi weewx[4123]: te923: observation map is
{'bat_1': 'outTempBatteryStatus', 'bat_3': 'extraBatteryStatus2', 'bat_2':
'extraBatteryStatus1', 'bat_5': 'extraBatteryStatus4', 'bat_4':
'extraBatteryStatus3', 'bat_wind': 'windBatteryStatus', 't_in': 'inTemp',
'link_rain': 'rainLinkStatus', 't_5': 'extraTemp4', 'h_in': 'inHumidity',
'h_4': 'extraHumid3', 'h_5': 'extraHumid4', 'h_2': 'extraHumid1', 'h_3':
'extraHumid2', 'h_1': 'outHumidity', 't_2': 'extraTemp1', 'link_2':
'extraLinkStatus1', 'link_uv': 'uvLinkStatus', 'link_wind':
'windLinkStatus', 'uv': 'UV', 'bat_uv': 'uvBatteryStatus', 'link_5':
'extraLinkStatus4', 'bat_rain': 'rainBatteryStatus', 'link_3':
'extraLinkStatus2', 't_3': 'extraTemp2', 'link_1': 'outLinkStatus', 't_1':
'outTemp', 't_4': 'extraTemp3', 'link_4': 'extraLinkStatus3'}
Sep 22 07:36:22 raspberrypi weewx[4123]: te923: Found device on USB bus=001
device=007
Sep 22 07:36:23 raspberrypi kernel: [ 3630.838597] usb 1-1.4: reset
low-speed USB device number 7 using dwc_otg
Sep 22 07:36:23 raspberrypi weewx[4123]: te923: Failed attempt 1 of 5 to
read data: error sending control message: Device or resource busy
Sep 22 07:36:23 raspberrypi kernel: [ 3631.141743] hid-generic
0003:1130:6801.000E: hiddev0,hidraw1: USB HID v1.10 Device [ ] on
usb-3f98.usb-1.4/input0
Sep 22 07:36:23 raspberrypi kernel: [ 3631.142215] usb 1-1.4: usbfs:
process 4123 (weewxd) did not claim interface 0 before use
Sep 22 07:36:26 raspberrypi weewx[4123]: te923: Failed attempt 2 of 5 to
read data: error sending control message: Device or resource busy
Sep 22 07:36:26 raspberrypi kernel: [ 3634.145927] usb 1-1.4: usbfs:
process 4123 (weewxd) did not claim interface 0 before use
Sep 22 07:36:29 raspberrypi weewx[4123]: te923: Failed attempt 3 of 5 to
read data: error sending control message: Device or resource busy
Sep 22 07:36:29 raspberrypi kernel: [ 3637.149716] usb 1-1.4: usbfs:
process 4123 (weewxd) did not claim interface 0 before use
Sep 22 07:36:32 raspberrypi weewx[4123]: te923: Failed attempt 4 of 5 to
read data: error sending control message: Device or resource busy
Sep 22 07:36:32 raspberrypi kernel: [ 3640.156489] usb 1-1.4: usbfs:
process 4123 (weewxd) did not claim interface 0 before use
Sep 22 07:36:35 raspberrypi weewx[4123]: te923: Failed attempt 5 of 5 to
read data: error sending control message: Device or resource busy
Sep 22 07:36:35 raspberrypi kernel: [ 3643.160304] usb 1-1.4: usbfs:
process 4123 (weewxd) did not claim interface 0 before use
Sep 22 07:36:38 raspberrypi weewx[4123]: import of driver failed: Read
failed after 5 tries ()
Sep 22 07:36:38 raspberrypi weewx[4123]: engine: Unable to load driver:
Read failed after 5 tries
Sep 22 07:36:38 raspberrypi weewx[4123]: Waiting 60 seconds then
retrying...
[/code]
Re: [weewx-user] Re: Te923 driver is not starting anymore.
Den 12-09-2016 kl. 16:03 skrev mwall: On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote: I just tried to uncomment line 1562 to get the reset back, and the driver immediately started to work again well that is annoying. apparently the reset is required on some systems, but on other systems it causes the driver to fail. allan, the logs you posted show bus= driver=, i.e., no value for bus or driver, but that was with an error of undefined symbol. when the driver is working, do you see values for bus and driver? No, there is never any values, no matter if driver is working or not. Allan. -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
On Sunday, September 11, 2016 at 11:44:15 AM UTC-4, Allan H wrote: > > Den 11-09-2016 kl. 16:33 skrev Allan: > > > Well, without the resets, it doesn't seem to load here. > > Follow-up: > > I just tried to uncomment line 1562 to get the reset back, and the > driver immediately started to work again > well that is annoying. apparently the reset is required on some systems, but on other systems it causes the driver to fail. allan, the logs you posted show bus= driver=, i.e., no value for bus or driver, but that was with an error of undefined symbol. when the driver is working, do you see values for bus and driver? it looks like we are in a version quagmire - some combinations of udev, libusb, and pyusb work, but others do not. and the usb reset seems to trigger it. i think we now have a unit test: - which operating system and version? - which version of libusb? - which version of pyusb? - which version of udev? - which version of te923 driver (use 0.19 if possible) with reset un-commented: - what happens when you run the driver directly for --readings? - what happens when you run the driver directly for --records=5? - what happens when you run weewxd directly? - what happens when you run weewx as daemon? - what happens whey you run weewx as daemon at system startup? then the same again with reset commented. for each os/libusb/udev configuration it would also be nice to know whether te923tool runs properly. m -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
Den 11-09-2016 kl. 16:33 skrev Allan: Den 09-09-2016 kl. 14:46 skrev mwall: On Friday, September 9, 2016 at 8:31:07 AM UTC-4, Paul Bartholdi wrote: i pushed driver version 0.19 yesterday (commit 760d55d4a318402698e28f09a56b67db338a644f) https://github.com/weewx/weewx/commit/760d55d4a318402698e28f09a56b67db338a644f the reset seems to cause problems on more configurations than the minor improvement it makes on one arm configuration. the sleep timings seem to make no difference at all. the udev hid release command posted earlier is a no-op - it probably *would* help, but on linux systems we can release the kernel from the code so there is no need to do it via udev script. Well, without the resets, it doesn't seem to load here. Follow-up: I just tried to uncomment line 1562 to get the reset back, and the driver immediately started to work again Allan. -- 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: [weewx-user] Re: Te923 driver is not starting anymore.
Den 09-09-2016 kl. 14:46 skrev mwall:
On Friday, September 9, 2016 at 8:31:07 AM UTC-4, Paul Bartholdi wrote:
i pushed driver version 0.19 yesterday (commit
760d55d4a318402698e28f09a56b67db338a644f)
https://github.com/weewx/weewx/commit/760d55d4a318402698e28f09a56b67db338a644f
the reset seems to cause problems on more configurations than the minor
improvement it makes on one arm configuration. the sleep timings seem
to make no difference at all. the udev hid release command posted
earlier is a no-op - it probably *would* help, but on linux systems we
can release the kernel from the code so there is no need to do it via
udev script.
Well, without the resets, it doesn't seem to load here.
unfortunately i have only one configuration on which to test. so
feedback from other te923 users is *greatly* appreciated. but that
feedback needs to be about the latest driver and the configuration on
which it is running.
just downloaded 0.19. Running on Centos 7 X86_64 here.
Sep 11 16:30:38 mail2 weewx[5891]: engine: Initializing weewx version 3.5.0
Sep 11 16:30:38 mail2 weewx[5891]: engine: Using Python 2.7.5 (default,
Aug 18 2016, 15:58:25) #012[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)]
Sep 11 16:30:38 mail2 weewx[5891]: engine: Platform
Linux-3.10.0-327.28.3.el7.x86_64-x86_64-with-centos-7.2.1511-Core
Sep 11 16:30:38 mail2 weewx[5891]: engine: Using configuration file
/etc/weewx/weewx.conf
Sep 11 16:30:38 mail2 weewx[5891]: engine: Loading station type TE923
(weewx.drivers.te923)
Sep 11 16:30:38 mail2 weewx[5891]: te923: driver version is 0.19
Sep 11 16:30:38 mail2 weewx[5891]: te923: polling interval is 10
Sep 11 16:30:38 mail2 weewx[5891]: te923: observation map is {'bat_1':
'outTempBatteryStatus', 'bat_3': 'extraBatteryStatus2', 'bat_2':
'extraBatteryStatus1', 'bat_5': 'extraBatteryStatus4', 'bat_4':
'extraBatteryStatus3', 'bat_wind': 'windBatteryStatus', 't_in':
'inTemp', 'link_rain': 'rainLinkStatus', 't_5': 'extraTemp4', 'h_in':
'inHumidity', 'h_4': 'extraHumid3', 'h_5': 'extraHumid4', 'h_2':
'extraHumid1', 'h_3': 'extraHumid2', 'h_1': 'outHumidity', 't_2':
'extraTemp1', 'link_2': 'extraLinkStatus1', 'link_uv': 'uvLinkStatus',
'link_wind': 'windLinkStatus', 'uv': 'UV', 'bat_uv': 'uvBatteryStatus',
'link_5': 'extraLinkStatus4', 'bat_rain': 'rainBatteryStatus', 'link_3':
'extraLinkStatus2', 't_3': 'extraTemp2', 'link_1': 'outLinkStatus',
't_1': 'outTemp', 't_4': 'extraTemp3', 'link_4': 'extraLinkStatus3'}
Sep 11 16:30:39 mail2 weewx[5891]: te923: Found device on USB bus= device=
Sep 11 16:30:39 mail2 kernel: usb 3-4: ep 0x81 - rounding interval to 64
microframes, ep desc says 80 microframes
Sep 11 16:30:40 mail2 weewx[5891]: engine: Unable to load driver: [Errno
None] Opkoblingen overskred tidsgrænsen
Sep 11 16:30:40 mail2 weewx[5891]: Waiting 60 seconds then
retrying...
Sep 11 16:31:01 mail2 systemd: Started Session 32137 of user root.
Sep 11 16:31:01 mail2 systemd: Starting Session 32137 of user root.
Sep 11 16:31:40 mail2 weewx[5891]: engine: retrying...
Sep 11 16:31:40 mail2 weewx[5891]: engine: Using configuration file
/etc/weewx/weewx.conf
Sep 11 16:31:40 mail2 weewx[5891]: engine: Loading station type TE923
(weewx.drivers.te923)
Sep 11 16:31:40 mail2 weewx[5891]: te923: driver version is 0.19
Sep 11 16:31:40 mail2 weewx[5891]: te923: polling interval is 10
Sep 11 16:31:40 mail2 weewx[5891]: te923: observation map is {'bat_1':
'outTempBatteryStatus', 'bat_3': 'extraBatteryStatus2', 'bat_2':
'extraBatteryStatus1', 'bat_5': 'extraBatteryStatus4', 'bat_4':
'extraBatteryStatus3', 'bat_wind': 'windBatteryStatus', 't_in':
'inTemp', 'link_rain': 'rainLinkStatus', 't_5': 'extraTemp4', 'h_in':
'inHumidity', 'h_4': 'extraHumid3', 'h_5': 'extraHumid4', 'h_2':
'extraHumid1', 'h_3': 'extraHumid2', 'h_1': 'outHumidity', 't_2':
'extraTemp1', 'link_2': 'extraLinkStatus1', 'link_uv': 'uvLinkStatus',
'link_wind': 'windLinkStatus', 'uv': 'UV', 'bat_uv': 'uvBatteryStatus',
'link_5': 'extraLinkStatus4', 'bat_rain': 'rainBatteryStatus', 'link_3':
'extraLinkStatus2', 't_3': 'extraTemp2', 'link_1': 'outLinkStatus',
't_1': 'outTemp', 't_4': 'extraTemp3', 'link_4': 'extraLinkStatus3'}
Sep 11 16:31:40 mail2 weewx[5891]: te923: Found device on USB bus= device=
Sep 11 16:31:40 mail2 weewx[5891]: engine: Unable to load driver:
/lib64/libusb-1.0.so.0: undefined symbol: libusb_strerror
Sep 11 16:31:40 mail2 weewx[5891]: Waiting 60 seconds then
retrying...
Allan.
--
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.
