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.
