USB compendium
Several fhem users are plagued by spontaneous disconnects/reconnects of USB
devices. This is not an issue of fhem but a problem of hardware and/or USB
drivers.
This document summarizes some findings on the issue. They are taken from
users' experience and from a web research. This USB compendium is written for Linux
users.
A. Problem description
USB devices spontaneously disconnect from the bus. They are reconnected after
some time ranging from zero to many seconds. fhem global log shows messages like
2009.01.12 19:22:14 1: USB device /dev/elv_fhz1300pc disconnected, waiting to reappear
2009.01.12 19:22:19 1: USB device /dev/elv_fhz1300pc reappeared
A look into the kernel message log with
grep usb /var/log/messages | tail -n 100 | less
shows messages like
Jan 12 19:22:14 bunkertor kernel: usb 10-2.1: USB disconnect, address 59
Jan 12 19:22:14 bunkertor kernel: usb 10-2.1.1: USB disconnect, address 61
Jan 12 19:22:14 bunkertor kernel: usb 10-2.4: USB disconnect, address 60
Jan 12 19:22:14 bunkertor kernel: usb 10-2: reset full speed USB device using uhci_hcd and address 2
Jan 12 19:22:14 bunkertor kernel: usb 10-2.1: new full speed USB device using uhci_hcd and address 62
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1: not running at top speed; connect to a high speed hub
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1: configuration #1 chosen from 1 choice
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1: New USB device found, idVendor=04b4, idProduct=6560
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: new full speed USB device using uhci_hcd and address 63
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: configuration #1 chosen from 1 choice
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: FTDI USB Serial Device converter now attached to ttyUSB0
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: New USB device found, idVendor=0403, idProduct=e0ef
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: Product: ELV EM 1010 PC
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: Manufacturer: ELV AG
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1.1: new full speed USB device using uhci_hcd and address 64
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: configuration #1 chosen from 1 choice
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: FTDI USB Serial Device converter now attached to ttyUSB1
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: New USB device found, idVendor=0403, idProduct=e0e8
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: Product: ELV FHZ 1300 PC
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: Manufacturer: ELV AG
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: SerialNumber: xxxxxxxxxxx
B. Possible reasons and remedies
1. Not enough power on the bus
FHZ1300PC directly connected to the computer's built-in USB ports does not work
at all or seizes to work after short time. This is likely due to the USB's
inability to provide sufficient power to the connected
devices. Use of a powered hub seems to cure the problem in some cases
(confirmed, see [6]).
2. Mixture of USB 1.1 and USB 2.0 devices
Use of an USB 1.1 hub to connect USB 2.0 devices and vice versa might lead to
timing problems (see [3]). Consistent use of either USB 1.1 or USB 2.0 devices
might be a cure (unconfirmed).
3. Timing problems
It was suggested that late answers from a device make the driver think that it
has gone away. This would lead to a disconnect. followed by a reconnect when
the device's reply arrives. Changing the timeouts
might be a cure. It is not known how to achieve this (see [5]).
4. Electromagnetic interferences
EMI appears to be a large issue with FHZ1x00 (for one thing, there are MANY reports
of people mysteriously unable to pair some FHT80b, despite trying very hard).
For many details, see
Electro-magnetic interference below.
5. USB Power management
The linux kernel USB driver supports power management. If there is no activity
on the USB for a certain time, the port is switched to powersaving which leads
to a disconnect of the device (see [3]). Details on
linux power management are found in [4]. In short, you can turn off power
management in general if you do
echo -1 >/sys/module/usbcore/parameters/autosuspend
or, for a specific device,
echo on > /sys/bus/usb/devices/DEVICEID/power/level
with DEVICEID substituted by the device's ID.
6. USB extenders
To increase the maximum cable length from 5 meters to 10 meters, so-called
USB extenders are on sale. They consist of a fixed passive 1-port hub at the end of
an USB cable. This drives the USB to its limits and may cause all sorts of
problems on the bus. Either do not use USB extenders (confirmed, see [10]) at all
or put an active (self-powered) hub in the middle (unconfirmed).
Electro-magnetic interference (EMI) compendium
Bad shielding of cables or devices might lead to interferences with electric
devices nearby (fridges, light switches, fluorescent lamps, ...).
A computer can cope with this problem better or worse.
Changing the computer's hardware helps (confirmed, see [7]).
If this is not feasible, use a ferrite ring (see [8] for instance)
or two around the ends of the FHZ cable (semi-confirmed).
(or on other interference-inducing cables!)
Confirmed, AndiM: MANY issues with interference on FHZ1300PC,
which can be observed via drastically increased receiver LED activity
e.g. when a nearby (1m) PC is running - despite some countermeasures.
Symptoms of trouble with interference:
- Almost no successful bi-di communication (almost never
ack:s received when sending values),
(re-)pairing FHT80b units was pretty much impossible, too,
but many can-rcv: 50 from several FHTs received while pairing was not successful
(hmm, perhaps this is a special ID for indication of pairing protocol issues,
since it's exactly half of FHTID 100??)
- FS20 button reception does work directly after an
initFS20 or rereadcfg or other
reset command is executed, but as soon as the first other LED activity
(interference? FHT traffic?) happens, any FS20 reception whatsoever drops dead again.
And this specifically affects FS20 handling in FHZ1300PC,
since specifically initFS20 does correct it (IIRC initHMS doesn't)
and (some parts of) FHT protocol reception still does work in the meantime.
Swapping the 1m USB cable with a 1.5m cable (but not overly long - this is said to be problematic as well!)
and adding a ferrite ring (currently at the FHZ1300PC-side cable end) did do wonders,
it completely eliminated all problems (although not sure yet which of these measures contributed by how much,
the increase of the distance from interference-causing parts or the ferrite ring).
Please also note that it is recommended to keep an FHT at least 1.5m from a FHZ, otherwise
people experienced pairing problems.
Misc. issues / hints
C. Suggested reading
[1]
http://www.mikrocontroller.net/topic/116263
[2]
http://www.ti.com/sc/docs/apps/msp/intrface/usb/emitest.pdf
[3]
http://forum.soft32.com/linux/solution-usb-disconnect-problems-usb-ftopict345989.html
[4] /usr/src/linux/Documentation/usb/power-management.txt
[5] Google group FHZ1000 users on Linux, Message-ID: beb1c8d2-ec08-4ded-bc9b-2c0fc856fa09@e1g2000pra.googlegroups.com
[6] Google group FHZ1000 users on Linux, Message-ID: 200812241129.01819.omega@online.de
[7] Google group FHZ1000 users on Linux, Message-ID: 930a1555-3eda-49ce-82d9-3ecc617f5e9c@a26g2000prf.googlegroups.com
[8]
http://www.reichelt.de/?;ACTION=3;LA=4;GROUP=B522;GROUPID=3187;ARTICLE=7674;START=0;SORT=preis;OFFSET=1000;SID=26j@QMWawQARoAAFcmBVM2b30b32eb7a0d90a6833475d294db8c2
[9]
http://www.usb.org/developers/usbfaq/
[10] Google group FHZ1000 users on Linux, Message-ID: 2aac5192-1966-4939-a8ff-73d1e0b67506@w24g2000prd.googlegroups.com
