Te923 driver is not starting anymore.

[J.L. Blom]

From the start of the new driver I have had problems with it. I begin
however, to get the suspicion that something in the TFA Nexus has gone
but I'm not sure as the console display is strictly normal.
However, yesterday (localtime) morning the program stopped suddenly
receiving packets .
This the excerpt of the log:
_________________________________________
Mar 15 06:35:30 kangoo weewx[2420]: reportengine: ftp'd 49 files in 6.67
seconds
Mar 15 06:40:21 kangoo weewx[2420]: manager: added record 2016-03-15
06:40:00 CET (1458020400) to database 'weewx.sdb'
Mar 15 06:40:21 kangoo weewx[2420]: manager: added record 2016-03-15
06:40:00 CET (1458020400) to daily summary in 'weewx.sdb'
Mar 15 06:40:23 kangoo weewx[2420]: te923: Failed attempt 1 of 5 to read
data: Timeout after 0 bytes
Mar 15 06:40:24 kangoo weewx[2420]: cheetahgenerator: Generated 14 files
for report StandardReport in 2.15 seconds
Mar 15 06:40:25 kangoo weewx[2420]: genimages: Generated 12 images for
StandardReport in 1.11 seconds
Mar 15 06:40:25 kangoo weewx[2420]: reportengine: copied 0 files to
/home/weewx/public_html
Mar 15 06:40:26 kangoo weewx[2420]: GaugeGenerator: windDir has no
reading (None)
Mar 15 06:40:26 kangoo weewx[2420]: GaugeGenerator: windRose has no
reading (None)
Mar 15 06:40:27 kangoo weewx[2420]: GaugeGenerator: Generated 7 images
for HTMLPages in 1.68 seconds
Mar 15 06:40:27 kangoo weewx[2420]: historygenerator.pyc: Generated 5
tables in 0.12 seconds
Mar 15 06:40:27 kangoo weewx[2420]: te923: Failed attempt 2 of 5 to read
data: Timeout after 15 bytes
Mar 15 06:40:29 kangoo weewx[2420]: cheetahgenerator: Generated 10 files
for report HTMLPages in 1.62 seconds
Mar 15 06:40:29 kangoo weewx[2420]: reportengine: copied 0 files to
/home/weewx/public_html/Bootstrap
Mar 15 06:40:29 kangoo weewx[2420]: genimages: Generated 6 images for
SmallImages in 0.90 seconds
Mar 15 06:40:31 kangoo weewx[2420]: te923: Failed attempt 3 of 5 to read
data: Timeout after 14 bytes
Mar 15 06:40:35 kangoo weewx[2420]: te923: Failed attempt 4 of 5 to read
data: Timeout after 14 bytes
Mar 15 06:40:36 kangoo weewx[2420]: reportengine: ftp'd 49 files in 6.65
seconds
Mar 15 06:40:40 kangoo weewx[2420]: te923: Failed attempt 5 of 5 to read
data: Timeout after 14 bytes
Mar 15 06:40:43 kangoo weewx[2420]: engine: Shutting down StdReport thread
Mar 15 06:40:43 kangoo weewx[2420]: engine: Caught WeeWxIOError: Read
failed after 5 tries
Mar 15 06:40:43 kangoo weewx[2420]: **** Waiting 60 seconds then
retrying...
Mar 15 06:41:43 kangoo weewx[2420]: engine: retrying...
Mar 15 06:41:43 kangoo weewx[2420]: engine: Using configuration file
/home/weewx/weewx.conf
Mar 15 06:41:43 kangoo weewx[2420]: engine: Loading station type TE923
(weewx.drivers.te923)
Mar 15 06:41:43 kangoo weewx[2420]: te923: driver version is 0.17
Mar 15 06:41:43 kangoo weewx[2420]: te923: polling interval is 10
Mar 15 06:41:43 kangoo weewx[2420]: te923: observation map is {'bat_1':
'outBatteryStatus', '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': 'extraHumid3', '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'}
Mar 15 06:41:43 kangoo weewx[2420]: te923: Found device on USB bus=001
device=005
Mar 15 06:41:43 kangoo weewx[2420]: te923: read: wrong number of bytes:
35 != 34
Mar 15 06:41:43 kangoo weewx[2420]: te923: Failed attempt 1 of 5 to read
data: Bad header byte: 03 != 5a
Mar 15 06:41:47 kangoo weewx[2420]: te923: Failed attempt 2 of 5 to read
data: Timeout after 7 bytes
Mar 15 06:41:52 kangoo weewx[2420]: te923: Failed attempt 3 of 5 to read
data: Timeout after 14 bytes
Mar 15 06:41:56 kangoo weewx[2420]: te923: Failed attempt 4 of 5 to read
data: Timeout after 14 bytes
Mar 15 06:42:00 kangoo weewx[2420]: te923: Failed attempt 5 of 5 to read
data: Timeout after 14 bytes
Mar 15 06:42:03 kangoo weewx[2420]: engine: Unable to load driver: Read
failed after 5 tries
Mar 15 06:42:03 kangoo weewx[2420]: **** Exiting...
Mar 15 08:23:57 kangoo weewx[15842]: engine: Initializing weewx version
3.4.0
etc., etc.
......
____________________________________________________
From that moment on weewx refused to get packages.
I would like to find out why the packets are in error but I have no idea
how to troubleshoot.
I took the console from the power (removing the batteries also) and
waited a few minutes but nothing happened.
The last trial gave:
___________________________________
Mar 15 10:13:16 kangoo weewx[18145]: te923: Found device on USB bus=001
device=005
Mar 15 10:13:17 kangoo weewx[18145]: te923: read: wrong number of bytes:
35 != 34
Mar 15 10:13:17 kangoo weewx[18145]: te923: Failed attempt 1 of 5 to
read data: Bad header byte: 05 != 5a
Mar 15 10:13:21 kangoo weewx[18145]: te923: Failed attempt 2 of 5 to
read data: Timeout after 7 bytes
Mar 15 10:13:25 kangoo weewx[18145]: te923: Failed attempt 3 of 5 to
read data: Timeout after 7 bytes
Mar 15 10:13:29 kangoo weewx[18145]: te923: Failed attempt 4 of 5 to
read data: Timeout after 7 bytes
Mar 15 10:13:33 kangoo weewx[18145]: te923: Failed attempt 5 of 5 to
read data: Timeout after 7 bytes
Mar 15 10:13:36 kangoo weewx[18145]: engine: Unable to load driver: Read
failed after 5 tries
Mar 15 10:13:36 kangoo weewx[18145]: **** Exiting...
________________________________________

Is this a case of a defunct console-link?
Hope somebody can give some advice how to proceed (OK, a new console or
complete new system is a possibility, I know).
Joep

[J.L. Blom]

Replying on my own mail, I think I found the problem.
When I removed the USB-changed the cable from the console and used
another USB-port on the Raspberry the system responded correctly. It is
now running for > 3 hours so I hope it was such a simple thing as a
dirty connector.
Sorry for the noise,
Joep

[Matthias Jahn]

Hallo Joep, I had the same problem. Thanks for the solution :)

[J.L. Blom]

On 17/03/16 20:24, Matthias Jahn wrote:
>
> Hallo Joep, I had the same problem. Thanks for the solution :)
>

Thanks,
Pleased to be of assistance,
Joep

[Sandro Rabitti]

I have the same problem with a LaCrosse WS1640 with standard configuration (temp, hum, wind, rain) (Raspberry Pi mod. B, raspbian jessie, weewx 3.5.0). The TE923 driver stops with the same messages of Joep L. Blom (te923: read: wrong number of bytes: 35 != 34.)

The proposed solution does not work for me.

I tried various USB cables, changed port, rebooted several times, but no way.

With previous versions of weewx, with the same hardware configuration, I had more than 1 year uptime.

If I restart weewx by hand (sudo weewxd /etc/weewx/weewx.conf)  it works, but if I start the weewx service (sudo /etc/init.d/weewx start) it stops, exiting.

All the sensor batteries are fresh.

What happened with version 3.5.0 ? Is the TE923 driver changed ?

Sandro

[mwall]

On Tuesday, March 29, 2016 at 8:44:13 AM UTC-4, Sandro Rabitti wrote:

I have the same problem with a LaCrosse WS1640 with standard configuration (temp, hum, wind, rain) (Raspberry Pi mod. B, raspbian jessie, weewx 3.5.0). The TE923 driver stops with the same messages of Joep L. Blom (te923: read: wrong number of bytes: 35 != 34.)

The proposed solution does not work for me.

I tried various USB cables, changed port, rebooted several times, but no way.

hello sandro,

the only reason to reboot the computer is to test whether everything works when power goes down and is restored.

otherwise, rebooting the computer is a waste of time and only makes it more difficult to diagnose the problem.

this is not windows!
 

With previous versions of weewx, with the same hardware configuration, I had more than 1 year uptime.

If I restart weewx by hand (sudo weewxd /etc/weewx/weewx.conf)  it works, but if I start the weewx service (sudo /etc/init.d/weewx start) it stops, exiting.

All the sensor batteries are fresh.

is weewx stopping at times other than during startup?

is the startup behaviour you describe repeatable?  can you start by hand 10 times and every time it works?  can you start using rc script 10 times and every time it exits?

please post the log from at least one time when it exits.

there were extensive changes to the te923 driver in weewx 3.4.  some of the drivers (at least acurite, te923) are known to have initialization issues - they use libusb (rather than hid libraries) and there is not (yet) implemented a reliable way to flush the usb buffer so that the driver starts communication in a known state.  this has *always* been an issue for the te923 driver.

if your problem is this buffer flushing issue and you are getting the failures at startup (show us the logs!), then one workaround is to use the loop_on_init option in weewx.conf:

loop_on_init = True

 

What happened with version 3.5.0 ? Is the TE923 driver changed ?

changed since when?

changes are listed in the changelog, included in the docs directory of your weewx source or at github:

https://github.com/weewx/weewx/blob/master/docs/changes.txt

you can see changes specific to the te923 driver by browsing the repository - select the 'history' option here:

https://github.com/weewx/weewx/blob/master/bin/weewx/drivers/te923.py

m

[J.L. Blom]

> --
> 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+...@googlegroups.com
> <mailto:weewx-user+...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
Matt,
Did you see my logfile that I sent on 27-03 (local time 00:26) there in
is all info when restarting with debug=1.
(I have a problem with gmail as it refuse to sent me back the mail I
post to the group. I only see my own mail when it is repeated in mail by
others and I don't know how to cure that).
Sandro, I know that especially with the raspberry 1 the power is rather
critical. You need to use a power supply of at least 2 A but preferrably
3. The TFA Nexus is a completely different build from the Lacrosse
stations which I owned a long time ago.(WS-2310). I had that problem 2
times and I assume it's a bad connection in the weather station although
it's strange that the problem arises only when starting although I'm not
quite sure as the weather station stops for no reason.
Joep

[Sandro Rabitti]

Thank you for your replies.

For the moment I solved coming back to weewx 3.4, where everything run smoothly.

As soon as possible I'll explore better version 3.5 and I'll acclude my logs.

Thank you.

Sandro 

> <mailto:weewx-user+unsub...@googlegroups.com>.

[hen...@skjaerbaek.net]

Hi 

I also use weewx with at Te923 based weatherstation, after upgrading til 0.35 I experianced the same problems as listed in this thread.

after rolling back to 0.34.1 everything world again.. so thanks for the idea og hopefully the next version has a fix, but right now I am staying on 0.34.1

best regards

 Henrik

[mwall]

On Tuesday, April 5, 2016 at 2:56:14 AM UTC-4, henrik wrote:

Hi 

I also use weewx with at Te923 based weatherstation, after upgrading til 0.35 I experianced the same problems as listed in this thread.

after rolling back to 0.34.1 everything world again.. so thanks for the idea og hopefully the next version has a fix, but right now I am staying on 0.34.1

best regards

 Henrik

henrik,

when you say 'same problems', do you mean "weewx fails to start" or something else?  what messages from the te923 driver do you see in the log?

between weewx 3.4.0 (te923 driver version 0.16) and weewx 3.5.0 (driver version 0.17), the only change to driver logic was a timeout value.  at line 1587 in te923.py, the timeout was changed from 5 seconds to 1 second.

this change might result in more timeout failures - you'll see "Timeout after X bytes" in the log.  if they happen when weewx is starting up, then weewx will quit.

weewx is designed to quit when a driver fails at startup.  the intent is that if a driver cannot communicate with the hardware, you want to know about it so you can fix it.

however, there are cases where you want weewx to loop forever during startup, even if the driver fails to communicate with hardware.  setting 'loop_on_init=True' in weewx.conf will make weewx loop forever during startup, even if the driver fails.

in the case of the te923 driver, it has *always* had initialization problems.  most of the time (at least with the hardware i have tested on), startup works fine.  but occasionally the driver is not able to synchronize communication over the usb.  when this happens it can take two or three attempts before the driver communicates properly.  typically this is manifested by "Not enough bytes" or "Bad header byte" messages, but occasionally it will be "Timeout after ...".

there also seem to be some timing issues related to communicating with a te923 station over usb (or possibly even with respect to the system usb).

if you are having problems with te923 driver and weewx 3.5.0, here are two things to try:

1) if the problem is that weewx exits soon after startup, with messages in the log from the te923 driver, then try setting loop_on_init=True in weewx.conf

2) if you are seeing timeout messages in the log from the te923 driver, then try changing the timeout value to 5 seconds instead of 1 second.  this will make reading historical records slower, but it might make your system less vulnerable to usb timing issues.

m

[mwall]

On Tuesday, March 29, 2016 at 6:03:30 PM UTC-4, Joep L. Blom wrote:

Matt,
Did you see my logfile that I sent on 27-03 (local time 00:26) there in
is all info when restarting with debug=1.
(I have a problem with gmail as it refuse to sent me back the mail I
post to the group. I only see my own mail when it is repeated in mail by
others and I don't know how to cure that).

please see the response in that thread:

https://groups.google.com/forum/#!topic/weewx-user/ssu-R3XJapk

that is a completely different problem from the problem discussed in this thread.

m

[Henrik Skjærbæk]

Weeex starts up but is unable to communicate with the weather station.

Sometimes data is transfered once if the USB cabel is replugged.

I have added the relevant part of the log here:  http://pastebin.com/v3mTQAiV

loop_on_init=True is added to the configuration, so weeex no longer exits after 5 attempts but no data was transfered on 0.35. I Will try to change the timeout to 1 sec on 0.34.1 and report back

Best regards

   Henrik

Sendt fra min iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/bkpjiNkdeko/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Bartholdi]

Hello,  I am using the TE923 driver with an IROX PRO X and weewx 3.5 . I almost never had this problem, BUT when I restart weewx, I can wait for more than an hour before collecting new data. Very strange, this delay varies from minutes up to 3 hours... Nothing visible on the log file.
When weewx didn’t started, the log file says weewx could not find the driver, even after the suggested correction.
Paul

[hen...@skjaerbaek.net]

I am now running on 0.35 without problems. The issue was the change timeout. 

If I changed the timeout in 0.34.1 to 1 sec. weewx started failing like in 0.35. so I installed 0.35 and changed the timeout to 5 sec. and the system have now been running for 2 day without problems.

Thanks for the assistance

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Nico Gulden]

Hello,

I experienced the same issues as described in this thread. During the
last four days I had the problem that my station ran into timeouts after
startup and during follow-up of the history from the hardware:

May 6 11:46:10 pi2 weewx[4631]: te923: read: wrong number of bytes: 35 != 34
May 6 11:46:10 pi2 weewx[4631]: te923: Failed attempt 1 of 5 to read
data: Bad header byte: c0 != 5a
May 6 11:46:14 pi2 weewx[4631]: te923: Failed attempt 2 of 5 to read
data: Timeout after 14 bytes
May 6 11:46:18 pi2 weewx[4631]: te923: Failed attempt 3 of 5 to read

data: Timeout after 14 bytes

May 6 11:46:18 pi2 systemd[1]: Stopped LSB: weewx weather system.
May 6 11:46:22 pi2 weewx[4631]: te923: Failed attempt 4 of 5 to read

data: Timeout after 14 bytes

May 6 11:46:26 pi2 weewx[4631]: te923: Failed attempt 5 of 5 to read

data: Timeout after 14 bytes

May 6 11:46:29 pi2 weewx[4631]: engine: Unable to load driver: Read
failed after 5 tries
May 6 11:46:29 pi2 weewx[4631]: **** Waiting 60 seconds then retrying...

Always the same pattern. I stopped weewx, unplugged the usb cable,
replugged again and started weewx. While reading the hardware history,
weewx ran into the timout again and could not fully catch up.

For about two hours now, my station is running again. I added the
loop_on_init=True setting and I increased the timeout to 3 seconds. So
far, the history is followed up and saved to the database. Operations
seems to be as expected.

I have a TFA Nexus, run weewx 3.5.0 and have now the timeout set to 3
seconds in line 1587 of the te923.py driver file. The weather station is
connected to a Raspberry Pi 2 with Raspbian 8 aka Jessie running on it.

I hope this helps.

Best regards,
Nico

[fraban]

Nico 

we have same problems here ... 

now we test 

loop_on_init = True    in the weewx.conf 

line 1587 you wrote is: 

    while time.time() - start_ts < 1:

we will change 

    while time.time() - start_ts < 3:

we will test -  thanks for the hint.  I will report later if it works 

-frank

[fraban]

Hi all

actually no luck with 

loop_on_init = True    in the weewx.conf 

and with setting 

    while time.time() - start_ts < 3:   in file /usr/share/weewx/weewx/drivers/te923.py  

still the same errors with 

... read: wrong number of bytes:   35 != 34 

-- 

any ideas ? 

-frank

[mwall]

On Friday, May 13, 2016 at 8:18:21 AM UTC-4, fraban wrote:

Hi all

actually no luck with 

loop_on_init = True    in the weewx.conf 

and with setting 

    while time.time() - start_ts < 3:   in file /usr/share/weewx/weewx/drivers/te923.py  

still the same errors with 

... read: wrong number of bytes:   35 != 34 

-- 

any ideas ? 

frank,

neither loop_on_init or the timeout will eliminate the 'wrong number of bytes' warnings, so do not expect those warnings to go away.  loop_on_init will make weewx continue to retry (instead of exiting).  the timeout change *might* reduce the chance of the buffer/read problem happening.

does weewx eventually start reading data properly?  you might have to let it run for some time, perhaps as much as 15-30 minutes.

the root cause seems to be an improper initialization/flushing of the usb.  it has been difficult for me to test alternative implementations because the problem is not repeatable on the test equipment i have available.

m

[fraban]

Matthew 

yes it seems to be a USB problem. Actually I have no contact to the raspberry - it´s a system of our network-members testing with us. I must wait until I have access to the pi again. As I remember I read "slow USB connection" in the syslog before the system crashes. May be it´s a raspberry problem - its a pi2 . We will change it with a new one and see what happens . 

Thanks for quick answer.

-frank 

[fraban]

Ok here we are - I got the following messages after restarting weewx. 

[....] Restarting weewx (via systemctl): weewx.service.

May 13 16:32:52 raspberrypi weewx[1171]: engine: pid file is /var/run/weewx.pid

May 13 16:32:53 raspberrypi weewx[1161]: Starting weewx weather system: weewx.

May 13 16:32:53 raspberrypi systemd[1]: Started LSB: weewx weather system.

May 13 16:32:53 raspberrypi weewx[1175]: engine: Using configuration file /etc/weewx/weewx.conf

May 13 16:32:53 raspberrypi weewx[1175]: engine: Loading station type TE923 (weewx.drivers.te923)

May 13 16:32:53 raspberrypi weewx[1175]: te923: driver version is 0.17

May 13 16:32:53 raspberrypi weewx[1175]: te923: polling interval is 10

May 13 16:32:53 raspberrypi weewx[1175]: te923: observation map is {'bat_1': 'outBatteryStatus', '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': 'extraHumid3', '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'}

May 13 16:32:53 raspberrypi weewx[1175]: te923: Found device on USB bus=001 device=004

May 13 16:32:53 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Fri May 13 16:33:23 2016 [try http://www.rsyslog.com/e/2007 ]

May 13 16:32:53 raspberrypi kernel: [ 1014.144293] usb 1-1.4: reset low-speed USB device number 4 using dwc_otg

May 13 16:32:54 raspberrypi weewx[1175]: te923: read: wrong number of bytes: 35 != 34

May 13 16:32:54 raspberrypi weewx[1175]: te923: Failed attempt 1 of 5 to read data: Bad header byte: aa != 5a

May 13 16:32:58 raspberrypi weewx[1175]: te923: Failed attempt 2 of 5 to read data: Timeout after 14 bytes

May 13 16:33:02 raspberrypi weewx[1175]: te923: Failed attempt 3 of 5 to read data: Timeout after 14 bytes

May 13 16:33:06 raspberrypi weewx[1175]: te923: Failed attempt 4 of 5 to read data: Timeout after 14 bytes

May 13 16:33:10 raspberrypi weewx[1175]: te923: Failed attempt 5 of 5 to read data: Timeout after 14 bytes

May 13 16:33:13 raspberrypi weewx[1175]: engine: Unable to load driver: Read failed after 5 tries

---

after a 2nd restart and the try to edit weewx.conf -  raspberry crashed with some kernel panic. 

I guess it´s also problem with the pi-hardware.  - We´ll check a new one - 

....

-frank

Am Freitag, 13. Mai 2016 15:38:10 UTC+2 schrieb mwall:

[Andy Harrold]

I'm needing to update the te923 driver to the latest version 0.18

Where is this file located so I can update it ?

I have the latest version from https://github.com/weewx/weewx/blob/master/bin/weewx/drivers/te923.py

How do I instal it? (Newbie on Raspbian!)

Thanks

[mwall]

On Thursday, September 8, 2016 at 5:47:49 PM UTC-4, Andy Harrold wrote:

I'm needing to update the te923 driver to the latest version 0.18

Where is this file located so I can update it ?

I have the latest version from https://github.com/weewx/weewx/blob/master/bin/weewx/drivers/te923.py

How do I instal it? (Newbie on Raspbian!)

Thanks

assuming a setup.py installation, it looks something like this:

1) stop weewx

sudo /etc/init.d/weewx stop

2) move the old driver aside

sudo mv /home/weewx/bin/weewx/drivers/te923.py /home/weewx/bin/weewx/drivers/te923-0.17.py

3) put the new driver in place

sudo cp ~/Downloads/te923.py /home/weewx/bin/weewx/drivers/te923.py

4) start weewx

sudo /etc/init.d/weewx start
 

[Paul Bartholdi]

Concerning "te923", I had "te923.py-0.18r6", which I assumed to be the latest "te923.py-0.18". It was 100 % OK with Ubuntu 14.04 LTS.
When I installed U 16.04 LTS however, weewx started to work very erratically and soon stopped completely.
Then I realised that the "r6" version was just temporary and is now replaced with "te923.py-0.18", I installed the latest and now weewx runs perfectly, better than ever!

Is there a way to be informed when a new version of such a sensible driver comes out?

Thanks of all!     Paul

[mwall]

On Friday, September 9, 2016 at 8:31:07 AM UTC-4, Paul Bartholdi wrote:

Concerning "te923", I had "te923.py-0.18r6", which I assumed to be the latest "te923.py-0.18". It was 100 % OK with Ubuntu 14.04 LTS.
When I installed U 16.04 LTS however, weewx started to work very erratically and soon stopped completely.
Then I realised that the "r6" version was just temporary and is now replaced with "te923.py-0.18", I installed the latest and now weewx runs perfectly, better than ever!

Is there a way to be informed when a new version of such a sensible driver comes out?

you'll have to watch the repository.

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.

the functionality/features of the te923 driver is quite stable.  unfortunately, the implementation seems to be stable on some platforms, but not on others.  for example, the usb reset was helpful on an arm based system running debian 7, but when i started testing on a different type of arm running ubuntu 14.04, the reset caused problems.  there are also some timing issues when doing repeated interrupt reads, and these might be due to ubuntu/debian differences, or they might be due to differences in the underlying libusb/pyusb implementations.

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.

it would be nice to configure a bunch of virtual machines or containers and set up automated unit tests for the driver...

m

[Guido Albers]

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.

it would be nice to configure a bunch of virtual machines or containers and set up automated unit tests for the driver...

m

Hello,

a small feedback. I'm using weewx with a Raspberry PI and "Raspbian GNU/Linux 8 (jessie)".
Currently only the driver version 0.17 works for me.
Driver 0.18 throws following errors:

Sep 11 02:30:03 weewx weewx[695]:     ****  Waiting 60 seconds then retrying...
Sep 11 02:31:03 weewx weewx[695]: engine: retrying...
Sep 11 02:31:03 weewx weewx[695]: engine: Using configuration file /etc/weewx/weewx.conf
Sep 11 02:31:03 weewx weewx[695]: engine: Loading station type TE923 (weewx.drivers.te923)
Sep 11 02:31:03 weewx weewx[695]: te923: driver version is 0.18
Sep 11 02:31:03 weewx weewx[695]: te923: polling interval is 10
Sep 11 02:31:03 weewx weewx[695]: te923: observation map is {'t_in': 'inTemp', 't_1': 'ch1Temp', 't_2': 'outTemp', 't_3': 'ch3Temp', 't_4': 'ch4Temp', 't_5': 'ch5Temp', 'h_in': 'inHumidity', 'h_1': 'ch1Humidity', 'h_2': 'outHumidity', 'h_3': 'ch3Humidity', 'h_4': 'ch4Humidity', 'h_5': 'ch5Humidity', 'bat_1': 'ch1Batt', 'bat_2': 'ch2Batt', 'bat_3': 'ch3Batt', 'bat_4': 'ch4Batt', 'bat_5': 'ch5Batt', 'windchill': 'windchill', 'winddir': 'windDir', 'windgust': 'windGust', 'windspeed': 'windSpeed', 'bat_wind': 'windBatt', 'bat_rain': 'rainBatt', 'uv': 'UV', 'bat_uv': 'uvBatt'}
Sep 11 02:31:03 weewx weewx[695]: te923: Found device on USB bus=001 device=004
Sep 11 02:31:03 weewx weewx[695]: te923: Failed attempt 1 of 5 to read data: error sending control message: Das Gerät oder die Ressource ist belegt
Sep 11 02:31:06 weewx weewx[695]: te923: Failed attempt 2 of 5 to read data: error sending control message: Das Gerät oder die Ressource ist belegt
Sep 11 02:31:09 weewx weewx[695]: te923: Failed attempt 3 of 5 to read data: error sending control message: Das Gerät oder die Ressource ist belegt
Sep 11 02:31:12 weewx weewx[695]: te923: Failed attempt 4 of 5 to read data: error sending control message: Das Gerät oder die Ressource ist belegt
Sep 11 02:31:15 weewx weewx[695]: te923: Failed attempt 5 of 5 to read data: error sending control message: Das Gerät oder die Ressource ist belegt
Sep 11 02:31:18 weewx weewx[695]: engine: Unable to load driver: Read failed after 5 tries
Sep 11 02:31:18 weewx weewx[695]:     ****  Waiting 60 seconds then retrying...
Sep 11 02:32:18 weewx weewx[695]: engine: retrying...

The driver 0.19 throws this:

Sep 11 01:50:01 weewx weewx[5424]:     ****  Waiting 60 seconds then retrying...
Sep 11 01:50:58 weewx weewx[5465]: Stopping weewx weather system: weewx.
Sep 11 01:53:04 weewx weewx[5640]: engine: Initializing weewx version 3.5.0
Sep 11 01:53:04 weewx weewx[5640]: engine: Using Python 2.7.9 (default, Mar  8 2015, 00:52:26) #012[GCC 4.9.2]
Sep 11 01:53:04 weewx weewx[5640]: engine: Platform Linux-4.4.13-v7+-armv7l-with-debian-8.0
Sep 11 01:53:04 weewx weewx[5640]: engine: pid file is /var/run/weewx.pid
Sep 11 01:53:04 weewx weewx[5644]: engine: Using configuration file /etc/weewx/weewx.conf
Sep 11 01:53:04 weewx weewx[5644]: engine: Loading station type TE923 (weewx.drivers.te923)
Sep 11 01:53:04 weewx weewx[5644]: te923: driver version is 0.19
Sep 11 01:53:04 weewx weewx[5644]: te923: polling interval is 10
Sep 11 01:53:04 weewx weewx[5644]: te923: observation map is {'t_in': 'inTemp', 't_1': 'ch1Temp', 't_2': 'outTemp', 't_3': 'ch3Temp', 't_4': 'ch4Temp', 't_5': 'ch5Temp', 'h_in': 'inHumidity', 'h_1': 'ch1Humidity', 'h_2': 'outHumidity', 'h_3': 'ch3Humidity', 'h_4': 'ch4Humidity', 'h_5': 'ch5Humidity', 'bat_1': 'ch1Batt', 'bat_2': 'ch2Batt', 'bat_3': 'ch3Batt', 'bat_4': 'ch4Batt', 'bat_5': 'ch5Batt', 'windchill': 'windchill', 'winddir': 'windDir', 'windgust': 'windGust', 'windspeed': 'windSpeed', 'bat_wind': 'windBatt', 'bat_rain': 'rainBatt', 'uv': 'UV', 'bat_uv': 'uvBatt'}
Sep 11 01:53:04 weewx weewx[5644]: te923: Found device on USB bus=001 device=004
Sep 11 01:53:04 weewx weewx[5629]: Starting weewx weather system: weewx.
Sep 11 01:53:06 weewx weewx[5644]: import of driver failed: could not detach kernel driver from interface 0: Keine Daten verfügbar (<class 'weewx.WeeWxIOError'>)
Sep 11 01:53:06 weewx weewx[5644]: engine: Unable to load driver: could not detach kernel driver from interface 0: Keine Daten verfügbar
Sep 11 01:53:06 weewx weewx[5644]:     ****  Waiting 60 seconds then retrying...

I hope it's helps. A working driver greater than 0.18 is important for me, because I'm currently working on the database schema and the skin. Special for the link and battery output are some important changes in the driver since version 0.18

Guido

[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.

> 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.

[Allan]

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.

[mwall]

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

[Allan]

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.

[Patrick Klein]

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 raspberrypi kernel: [ 3631.141743] hid-generic 0003:1130:6801.000E: hiddev0,hidraw1: USB HID v1.10 Device [ ] on usb-3f980000.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 (<class 'weewx.RetriesExceeded'>)

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...

 

[Patrick Klein]

Sorry for the messed up post.

[mwall]

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:armhf        175-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:armhf    2:0.1.12-20+nmu1  armhf  userspace USB programming library
ii  libusb-1.0-0:armhf    2:1.0.11-1        armhf  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

[Patrick Klein]

I'll get back to you once I'm at work and can test it. :)

[Patrick Klein]

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. :)

[Patrick Klein]

I also enabled rapidfire. Seems to be working fine.

[Allan]

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.

[mwall]

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

[Allan]

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.

[mwall]

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

[mwall]

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

[Allan]

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 1449270000.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[3819]: manager: added record 2016-10-05
08:05:00 CEST (1475647500) to database 'weewx.sdb'
Oct 5 08:21:37 mail2 weewx[3819]: manager: added record 2016-10-05
08:05:00 CEST (1475647500) to daily summary in 'weewx.sdb'
Oct 5 08:21:38 mail2 weewx[3819]: manager: added record 2016-10-05
08:10:00 CEST (1475647800) to database 'weewx.sdb'
Oct 5 08:21:38 mail2 weewx[3819]: manager: added record 2016-10-05
08:10:00 CEST (1475647800) to daily summary in 'weewx.sdb'
Oct 5 08:21:38 mail2 weewx[3819]: manager: added record 2016-10-05
08:15:00 CEST (1475648100) to database 'weewx.sdb'
Oct 5 08:21:38 mail2 weewx[3819]: manager: added record 2016-10-05
08:15:00 CEST (1475648100) to daily summary in 'weewx.sdb'
Oct 5 08:21:38 mail2 weewx[3819]: te923: read 6 records from logger
Oct 5 08:21:38 mail2 weewx[3819]: engine: Starting main packet loop.
Oct 5 08:21:38 mail2 weewx[3819]: **** email sent to: ['xx...@yyyyy.dk']
Oct 5 08:22:01 mail2 systemd: Started Session 36628 of user root.
Oct 5 08:22:01 mail2 systemd: Starting Session 36628 of user root.
Oct 5 08:22:20 mail2 weewx[3819]: manager: added record 2016-10-05
08:22:00 CEST (1475648520) to database 'weewx.sdb'
Oct 5 08:22:20 mail2 weewx[3819]: manager: added record 2016-10-05
08:22:00 CEST (1475648520) to daily summary in 'weewx.sdb'
Oct 5 08:22:25 mail2 weewx[3819]: cheetahgenerator: Generated 13 files
for report StandardReport in 4.20 seconds
Oct 5 08:22:28 mail2 weewx[3819]: genimages: Generated 27 images for
StandardReport in 3.22 seconds
Oct 5 08:22:28 mail2 weewx[3819]: reportengine: copied 10 files to
/var/www/clients/client0/web3/web
Oct 5 08:22:29 mail2 weewx[3819]: cheetahgenerator: Generated 13 files
for report BigReport in 1.32 seconds
Oct 5 08:22:33 mail2 weewx[3819]: genimages: Generated 27 images for
BigReport in 4.03 seconds
Oct 5 08:22:33 mail2 weewx[3819]: reportengine: copied 10 files to
/var/www/html/weewx/big
Oct 5 08:22:33 mail2 weewx[3819]: imageStackedWindRose: Generated 1
images for StackedWindRose in 0.09 seconds


Allan.