Hallo,
bei mir hängt ein Jee-Link mit einem 5 M USB Kabel am RPi (geht nicht kürzer, wegen Empfang von der WS1600 (Wetterstation).
Hin und wieder hängt sich die Kommunikation auf USB auf und es hilft ein automatischer USB reset.
Das Problem war die fehlende Unterscheidung zwischen den einzelnen USB-Devices. (siehe hier:)
pi@RPI_FHEM:/opt/fhem/log $ lsusb
Bus 001 Device 009: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 008: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 006: ID 2a03:0043 dog hunter AG Arduino Uno Rev3
Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Für den USB Reset benötige ich die Devicenummer, aber welche der drei mit der ID 0403:6001 ist es?
Dummerweise sind das alles USB-Teile mit dem gleichen 232 UART chipsatz.
Ein ls -la auf /dev/serial/by-id zeigt den Jee-Link an:
pi@RPI_FHEM:/opt/fhem/log $ ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 140 May 8 19:43 .
drwxr-xr-x 4 root root 80 May 8 19:43 ..
lrwxrwxrwx 1 root root 13 May 8 19:43 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB3
lrwxrwxrwx 1 root root 13 May 8 19:43 usb-Arduino_Srl_Arduino_Uno_8543130363635110E0D2-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 May 8 19:43 usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 May 8 19:43 usb-FTDI_FT232R_USB_UART_AI04PGKK-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 May 8 19:43 usb-FTDI_FT232R_USB_UART_DAE06aa8-if00-port0 -> ../../ttyUSB2
Es ist der mit dem Devicenamen AI04PGKK, jedoch fehlt die Zuordnung zum Devicenamen.
Eine Abfrage mit
sudo cat /sys/kernel/debug/usb/devices | grep -E "^([TS]:.*|)$"
wirft folgende Liste aus, in der die Verknüpfung zu finden ist:
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
S: Manufacturer=Linux 4.14.79-v7+ dwc_otg_hcd
S: Product=DWC OTG Controller
S: SerialNumber=3f980000.usb
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
S: Manufacturer=FTDI
S: Product=FT232R USB UART
S: SerialNumber=AI04PGKK
T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=03 Dev#= 5 Spd=480 MxCh= 4
S: Manufacturer=GenesysLogic
S: Product=USB2.0 Hub
T: Bus=01 Lev=03 Prnt=05 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
S: Manufacturer=Arduino Srl
S: Product=Arduino Uno
S: SerialNumber=8543130363635110E0D2
T: Bus=01 Lev=03 Prnt=05 Port=01 Cnt=02 Dev#= 7 Spd=12 MxCh= 0
S: Manufacturer=FTDI
S: Product=FT232R USB UART
S: SerialNumber=AH065FCR
T: Bus=01 Lev=03 Prnt=05 Port=02 Cnt=03 Dev#= 8 Spd=12 MxCh= 0
S: Manufacturer=FTDI
S: Product=FT232R USB UART
S: SerialNumber=DAE06aa8
T: Bus=01 Lev=03 Prnt=05 Port=03 Cnt=04 Dev#= 9 Spd=12 MxCh= 0
S: Product=USB2.0-Serial
Es ist das Device Nummer 4:
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
S: Manufacturer=FTDI
S: Product=FT232R USB UART
S: SerialNumber=AI04PGKK.
So, nach jedem reboot des Pis ändert sich die Devicenummer.
Ich möchte daher vor einem automatischen reboot des USB-Ports (an dem der Jee-Link hängt) die korrekte Nummer ermitteln und bräuchte eine Hilfestellung.
Das skript müsste alle Zeilen der o. g. Datei (geht nur mit root) absuchen, bis der Suchbegriff "AI04PGKK" auftaucht, dann die Zeile, welche 3 Zeilen oberhalb ist einlesen und den Wert bei Dev#= isolieren und zurückliefern. Habe es schon mit RegEx uber mehrere Zeilen versucht, komme aber nicht weiter.
Ist bestimmt hilfreich, da unter linux das mapping nur sehr kompliziert zu erreichen scheint.
Kann da jemand helfen?
Vielen dank im voraus
VG
Alex
Hi Alex,
das serial/by-id reicht nicht ?
Wie sähe der Reset-Befehl konkret aus ?
Grüße Markus
/Dev#=\s*(\d+).*(?:\r\n|\r|\n).*(?:\r\n|\r|\n).*(?:\r\n|\r|\n).*AI04PGKK/m
Nicht schön aber selten...
Kleine Frage .. wie Resettest Du denn "eine" Device?
Hallo,
@mumpitzstuff: Danke für die Regex: Frage: Wie bau ich die in ein script (perl oder bash ?) ein?
Hatte bislang für die RegEx nur auf shell-Ebene experimentiert, also:
cat <dateipfad/dateiname> | grep -E "RegEx"
und die Ausgabe erstmal im Terminalfenster verfolgt, weiter bin ich nicht gekommen.
@KölnSolar + Wernieman:
Der USB-Reset erfolgt durch ein kompiliertes c-Prg. , welches folgenden Sourcecode hat:
/* usbreset -- send a USB port reset to a USB device */
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>
int main(int argc, char **argv)
{
const char *filename;
int fd;
int rc;
if (argc != 2) {
fprintf(stderr, "Usage: usbreset device-filename\n");
return 1;
}
filename = argv[1];
fd = open(filename, O_WRONLY);
if (fd < 0) {
perror("Error opening output file");
return 1;
}
printf("Resetting USB device %s\n", filename);
rc = ioctl(fd, USBDEVFS_RESET, 0);
if (rc < 0) {
perror("Error in ioctl");
return 1;
}
printf("Reset successful\n");
close(fd);
return 0;
}
Es wird als Argument die Devicenummer übergeben.
Funktioniert einwandfrei, nur ich muss bisher nach einem RPi Restart immer die entsprechende Devicenummer händisch ermitteln und in die Aufruf-Sequenz (via watchdog getriggert eintragen. Und genau das soll automatisch erfolgen.
VG
Alex
Interessant. So etwas suchte ich auch immer mal.
Basiert auf libusb. Die gibt es mittlerweile auch für Perl USB::LibUSB mit Funktion reset_device(). Lief mir schon mal in FHEM über die Füße...hier (https://forum.fhem.de/index.php?topic=86364.0).
Das müsste sich doch glatt in ein Modul packen lassen. :-\
@Köln-Solar:
Dafür ;D
(Sorry fürs OT werden ...)
Du überforderst mich. Verstehe nicht, was Du meinst. :-[
Ich hab mir mal mit CPAN das Paket installiert. Dann das attachte Skript zusammengeschustert: Scheint zu klappen. Zumindest steht im Kernellog, dass der USB-Stick resettet wurde. Im laufenden Betrieb von FHEM keine Auffälligkeiten mit dem device. 8)
Edit: Attachement wg. neuerer Version(s.u.) gelöscht.
Meine Antwort bezog sich auf:
ZitatDas müsste sich doch glatt in ein Modul packen lassen. :-\
Das Script sieht interessant aus .. muß ich mir mal übers Wochenende ansehen ...
Ah. Dann war es doch gar nicht so OT. ;)
Das Skript ist eigentlich sehr simpel. Nur die Vendor- und Product-Id eintragen. Wenn es mehrere devices zu der Kombination gibt, auch noch die Serialno.(sofern es die gibt). Dann aber den Zugriff ...vid_pid_serial aktivieren und vid_pid deaktivieren. Scheinbar muss bei "eingebundenen" devices mit sudo gestartet werden.
So sieht das dann beispielhaft bei meinem RFXTRX aus:
pi@raspberrypi:/opt $ sudo perl testUSBreset.pl
USBResetUSB : device vendor 1027 and product 24577 opened
USBResetUSB : device vendor 1027 and product 24577 resetted
im FHEM-Log:2019.05.10 09:47:12 1: /dev/serial/by-id/usb-RFXCOM_RFXtrx433_02VEJQFT-if00-port0 disconnected, waiting to reappear (TRXUSB)
2019.05.10 09:47:13 3: Setting TRXUSB serial parameters to 38400,8,N,1
2019.05.10 09:47:16 1: TRX: Init OK
2019.05.10 09:47:16 1: TRX: Init status: 'RFXrec433 433.92MHz transceiver, hardware=1.0, output power=10dBm, firmware=1025, protocols enabled: Lighting4,RSL,Hideki/TFA/Cresta/UPM,AC,ARC,Oregon,'
2019.05.10 09:47:16 1: /dev/serial/by-id/usb-RFXCOM_RFXtrx433_02VEJQFT-if00-port0 reappeared (TRXUSB)
und PI-Log[ 3302.924423] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 3302.924468] ftdi_sio 1-1.4.1:1.0: device disconnected
[ 3303.021274] usb 1-1.4.1: reset full-speed USB device number 7 using dwc_otg
[ 3303.164863] ftdi_sio 1-1.4.1:1.0: FTDI USB Serial Device converter detected
[ 3303.164973] usb 1-1.4.1: Detected FT232RL
[ 3303.165822] usb 1-1.4.1: FTDI USB Serial Device converter now attached to ttyUSB0
Scheint also zu machen, was es soll. So richtig kann ich es dann erst testen, wenn ich mal wieder einen "Hänger" an einem der USB-devices habe.
Attached eine etwas erweiterte Version.
Ein Modul wäre vielleicht etwas oversized, aber als Funktion ließe es sich ja in der myUtils nutzen.
Also ich hab zwischenzeitlich etwas gebastelt, was funktioniert.
Ich verwende weiterhin das kompiliete c-Script.
Also bei mir geht es wie erwähnt um den Reset der Wetterdaten Schnittstelle (Jee-Link)
Wenn also mehr als 30 Min. keine Änderung der Daten erfolgt, wird der watchdog aktiv und
(WS_1600) 00:30 SAME {
Log3sub("JeeLinkDown_watchdog","JeeLinkDown","WS_1600 empfängt keine Daten mehr");
my $res = Jee_Link_Reset(); # USB-Reset
fhem("trigger JeeLinkDown .");
if($res) {
mailout("FHEM-Service","JeeLink Ausfall\nReset wurde durch USB-Reset behoben");
}
else {
mailout("FHEM-Service","JeeLink Ausfall\nReset konnte durch USB-Reset nicht behoben werden");
}
}
ruft folgende Routine in der 99_myUtils.pm auf:
sub USB_Reset($)
{
my ($usbdevnr) = @_;
my $name ="USB_Reset";
my $cmd = sprintf("sudo /opt/fhem/scripts/usbreset/usbreset /dev/bus/usb/001/%s",$usbdevnr);
system("$cmd");
#Log3 undef, 3,"$name: String: $cmd wurde ausgeführt";
return;
} # End USB_Reset()
sub Jee_Link_Reset() {
my $name = "Jee_Link_Reset"; # name of sub
my $file = "/opt/fhem/log/usblist.txt"; # define File for pre-filtered USB device list
my $USB_devno; # USB device number
system("/opt/fhem/scripts/usblist/usblist.scr $file"); # generate this list via shellscript into log dir
open(my $fh, '<', $file) or die "Can't open '$file' for read: $!"; # open the USB device list
my @lines;
while (my $line = <$fh>) {
push (@lines, $line); # line by line into array
}
close $fh or die "Cannot close $file: $!";
my $str; # linecontent
my $i=0; # linecounter
foreach my $n (@lines) {
$str = $lines[$i];
if($str =~ m/AI04PGKK/) { # if line contents of devicename of Jee-Link
#Log3 undef, 3,"$i: $lines[$i-3]";
if ($lines[$i-3] =~ m/Dev#=(.*)\sSpd/) { # if 3 lines before contains of "Dev#=", take value
$USB_devno = sprintf("%03d",$1);
USB_Reset($USB_devno);
Log3 undef, 3,"$name: JeeLink Ausfall wurde durch Reset von USB: $USB_devno getriggert";
return 1;
}
}
$i++;
}
return 0;
} # End Jee_Link_Reset()
Dabei wird vor dem reset mit usblist.scr eine gefilterte USB device Liste erstellt, welche im Anschluss dann von Jee_Link_Reset() eingelesen und das entsprechende Device ermittelt wird.
Der eigentliche USB reset erfolgt mit USB_Reset($)
Script usblist.scr:
sudo cat /sys/kernel/debug/usb/devices | grep -E "^([TS]:.*|)$" > $1
VG
Alex
Hi Alex,
viele Wege führen nach Rom. ;)
Ich wollte eine Perllösung anbieten. Wenn Du mein Skript/Funktion nutzt, müsste es mit # Jeelink(FTDI) use with vid_pid_serial
my $VENDOR = 0x0403;
my $PRODUCT = 0x6001;
my $SERIAL = "AI04PGKK";
funktionieren und Du sparst die Systembefehle, file....
Grüße Markus
Hallo Markus,
vielen Dank. Hat sich irgendwie überschnitten. Deine Lösung klingt interessant. Kannst Du mir diese mal zustellen?
Dann werde ich diese verwenden, da meine ziemlich umständlich ist.
VG
Alex
Hi Alex,
ich hab doch oben beschrieben, wie man die Grundlage schafft und auch das Skript attached.
Wenn Du es als Funktion in Deine myutils einbaust, kannst Du es ähnlich Deiner Vorgehensweise nutzen.
Grüße Markus
Ich habe ein ähnliches Problem, ein paar IR Leseköpfe hängen an einem USB-Hub, der über ca. 10m Cat.7 Kabel und Pegelwandler angebunden ist.
Funktioniert eigentlich top, aber alle paar Tage hängt sich die mit dem Hub Kommunikation auf.
Wenn man in udev die Rechte des Geräts passend setzt, könnte man den USB Reset auch direkt in FHEM ausführen, ohne ein kompiliertes C-Programm dazwischen.
"ioctl" ist in Perl drin, und "USBDEVFS_RESET" ist eine Konstante mit dem Wert 21780.
# use constant USBDEVFS_RESET => 21780;
perl -w -e 'use Fcntl; sysopen(U, "/dev/bus/usb/001/003", O_WRONLY) or die "$!"; print fileno(U)." ".ioctl(U, 21780, 0)."\n";'
funktioniert bei mir, dort ist der betroffene Hub das 3. Gerät am 1. Bus.
Und dafür muss man einen fünf Jahre alten Thread ausgraben?
Das ist doch ziemlich sinnfrei.
Und sag nicht, Du wärst nicht vor dem Abschicken darauf hingewiesen worden!
*Kopfschütteln*
Das Problem ist nach wie vor aktuell, und es ist sicherlich kein Einzelfall, dass sich der Rechner mit FHEM weiter als 5m von der Zähleranlage entfernt befindet, sondern wird mit zunehmender Anzahl an eHz-Messstellen eher häufiger (mbMn).
Das hier war der aktuellste Thread, in dem ich auch den passenden Lösungs-Ansatz gefunden hatte (besser als die nächtlichen Reboots zuvor!), nur der C-Code hat mich etwas 'gestört'.
Neueren Thread gabs nicht. Also:
1. trotz der dicken roten Warnung hier antworten, oder
2. in Code-Schnipsel posten, falls ich mit dem Problem nicht alleine bin.
50:50 Chance. War dann wohl falsch. :-[ Das nächste mal weiss ichs...
Zitat von: jw2013 am 28 Januar 2024, 22:18:18Neueren Thread gabs nicht. Also:
1. trotz der dicken roten Warnung hier antworten, oder
2. in Code-Schnipsel posten, falls ich mit dem Problem nicht alleine bin.
3. Einen neuen Thread in einem passenden Forumbereich eröffnen.
Vielleicht irgendwo mit Bezug zu Hardware allgemein oder zu Bastelprojekten.
Jetzt ist die Leiche schon geschändet :)) jetzt will ich auch noch mein Senf dazu sagen.
USB ist Gleichstrom, der Querschnitt der meisten Kabel eher gering dadurch ergibt sich ein hoher Verlust (spannungsfall).
Diese hinlänglich bekannte Problem lässt sich relativ simpel lösen, durch anheben des Pegel. Durch z.b. nenn aktiven usb hub oder was in der Art. Grundvorrausgesetzt es liegen nicht noch andere arge Probleme vor (z.b. Elektrosmog)
Sei's wie es ist, ich liebe es immer wenn ein Programmierer hardwareprobleme lösen will.
Mir hat man beigebracht, alles was man nicht programmieren kann, muß man löten.
Sorry aber mußte jetzt einfach sein.
Ja, das ursächliche Problem ist sicherlich die Spannungsversorgung.
Manche sind aber weder noch und nur Anwender. Denen hilft die Softwarelösung.(Oder denen, die trotz Hardwaremaßnahmen den Fehler im gewachsenen Irrgarten nicht finden)
ZitatWar dann wohl falsch.
Sehe ich nicht so. So sieht man(ich) gut den Zusammenhang zwischen den Alternativlösungen. Und wenn man, wie ich, über ungelesene Beiträge "selektiert", ist nur der neue Beitrag entscheidend.
Natürlich hätte der TE ein anderes Subforum wählen sollen.
Grüße Markus
Zitat von: DasQ am 29 Januar 2024, 08:04:18Sei's wie es ist, ich liebe es immer wenn ein Programmierer hardwareprobleme lösen will.
Mir hat man beigebracht, alles was man nicht programmieren kann, muß man löten.
:)) Oder man bestellts für wenige Münzen beim Ali, die Pegelwandler hier hab ich verwendet: https://de.aliexpress.com/item/1005002747560169.html
Frei nach dem Motto, warum löten, wenn ich 7(!) Kabel hintereinander friemeln kann :-)
Das Problem in meinem Fall ist eindeutig die Spannungsversorgung vom Hub, der hinter dem Pegelwandler kommt. Der andere Hub hängt mit baugleicher Platine direkt am Raspberry, dort gibts keine Aussetzer.
Natürlich könnte ich in die Hubs auch 5V einspeisen (Eingang ist vorhanden), und das Problem wäre auch weg. Aber warum ein Netzteil installieren, wenn der Software-Reset alle 1-2 Tage perfekt funktioniert?
Der Hub im Zählerschrank (für die IR Leseköpfe) ist wie folgt angebunden:
- RPi
- Kurzes USB-Patchkabel
- Kurzes Kabel mit Pegelwandler
- Kurzes Cat7-Patchkabel
- Keystone-Buchse auf Hutschiene
- 10m Cat7-Verlegekabel zwischen Zählerschrank und Allgemein-Unterverteilung
- Keystone-Buchse auf Hutschiene
- Kurzes Cat7-Patchkabel
- Kurzes Kabel mit Pegelwandler (Gegenstück)
- Kurzes USB-Patchkabel
- Hutschienen-USB-Hub (7-fach)
- USB-IR-Leseköpfe zu eHz Zählern
Anbei hab ich ein paar Bilder eingefügt, damit man sich den Aufbau mal besser vorstellen kann.
Tatsächlich funktioniert der Quatsch ziemlich gut ;D
Hübsch, sehr hübsch ... da will man dann eigentlich garnix mehr sagen. Gefällt mir gut.
Schonmal drüber nachgedacht, das ganze auf tasmota zu Portieren?
Ich müßt jetzt gerade lügen, mein aber ein tasmota kann mehrere SML lese schreibköpfe. (Notiz an mich, die Sache mit dem Schreiben wollte ich mal angehen, nicht manipulieren, sondern in den untermenus durchwurschteln.)
Ich hab noch, nur einen Zähler. Plane aber gerade am zweiten.
Mit tasmota hab ich bis jetzt keinen einzigen Aussetzer, der esp32 werkelt störrisch vor sich hin. Und bedient nebenbei den Türöffner.
Wie gesagt, deins gefällt mir sehr gut, und auch ein alter Mann hat mal gesagt, Never Touch usw usf.
Zitat von: DasQ am 29 Januar 2024, 15:39:00Hübsch, sehr hübsch ... da will man dann eigentlich garnix mehr sagen. Gefällt mir gut.
Schonmal drüber nachgedacht, das ganze auf tasmota zu Portieren?
Vielen Dank! :)
Tasmota hab ich bisher nur für Funksteckdosen und "IR-Blaster" eingesetzt. Bei Infrastruktur-Installationen versuche ich generell, Funk zu vermeiden.
Bis auf die o.g. Probleme halte ich USB für ein geniales Bus-System für Messstellen und Gebäude-Automation, mit passenden Hubs kann man alles sehr sauber strukturieren. Einzig die Kabel-Länge und 5V Spannung limitieren halt ein wenig.
Da könntest Du fast ein "Modul" draus machen ... ;o)