[gelöst] Stromversorgung eines USB-Geräts am Raspi über GPIO schalten?

Begonnen von dadoc, 12 August 2018, 11:14:24

Vorheriges Thema - Nächstes Thema

dadoc

Guten Morgen,
Vielleicht hat's ja schon mal jemand umgesetzt: Ich würde gern über fhem, das auf einem RPi 3 läuft, die Stromversorgung von an diesem RPi angeschlossenen USB-Geräte aus- und wieder einschalten können.
Spontan würde ich eine USB-Verlängerung aufschneiden und den 5-Volt-Draht über ein Relais laufen lassen, das über die GPIO geschaltet wird.
Aber vielleicht hat jemand eine elegantere Lösung...?
Danke & Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Papa Romeo

...Kabel aufschneiden ist ne Möglichkeit, aber wie du sagst nicht "elegant". Ich würd ne kleine Adapterplatine basteln, wo das Relais drauf sitzt, bzw. anstatt dem Relais eventuell auch ein P-Kanal-MOSFET. Eine USB-Buchse am Ausgang, USB-Stecker am Eingang, ein Steuerkabel mit Pin, dann wäre das Ding sogar dann auch universell einsetzbar.

Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

Stütti

Eventuell das hier: https://wiki.fhem.de/wiki/Relaisplatine-Homebrew-MySensors

Ansonsten, anstatt das Kabel aufzuschneiden habe ich es über einen schaltbaren USB-Hub gelöst. Ich habe einen von Sabrent, den konnte ich sauber öffnen, die Schaltkontakte rauslegen und wieder schließen.
FHEM auf Pi 4 + FTUI auf Pi 3, Eltako 14, SignalESP, JeeLink, EasyESP, ArduCounter, eBus-Koppler, openDTU

Wernieman

Gibt auch USB-Hubs, welche mit "Linux-Bordmitteln" schaltbar sind ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dadoc

Danke für die Tipps, deren Nachverfolgung mich zu https://github.com/mvp/uhubctl geführt haben, was anscheinend auch auf einem Pi 3B die Stromversorgung der USB Ports rein softwaremäßig steuern kann. Bekomme allerdings nach Compilen nur ein ,,Command not found" auf uhubctl.
Hat jemand damit Erfahrungen?
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

micky0867

Hast du "make install" als root ausgeführt?

Gesendet von meinem ONEPLUS A3003 mit Tapatalk


dadoc

Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Wernieman

Was war denn die Letzte Ausgabe? Hat den das compilieren geklappt?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dadoc

root@raspberrypi:~/uhubctl# make
make: 'uhubctl' is up to date.
root@raspberrypi:~/uhubctl#
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Wernieman

dann gucke doch mal in dem Pfad, ob eine uhubctl existiert ...

Wenn ja, kannst Du es mit "./uhubctl" starten. Wenn Nein .. gucke mal nach mit "find . -name uhubctl". Ich würde es dann erstmal testen von dem Ort, wo Du es findest.

Zur Bugsuche, ist es ausführbar? "chmod +x uhubctl"

Wenn es läuft, kannst Du es per Hand "Installieren".
"cp uhubctl /usr/local/bin/"
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dadoc

Vielen Dank für die Tipps, jetzt lässt es sich starten. Next step: mal testen, ob es tatsächlich ein USB-Device stromlos macht und dann wieder connected.
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

dadoc

Das funktioniert super, es lassen sich z.B. im laufenden fhem-Betrieb CULs stromlos machen und wieder anschalten, falls mal was hängt...
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Frank_Huber

Zitat von: dadoc am 15 August 2018, 11:18:23
Das funktioniert super, es lassen sich z.B. im laufenden fhem-Betrieb CULs stromlos machen und wieder anschalten, falls mal was hängt...
alle 4 Ports zusammen oder auch einzeln?

dadoc

Einzeln. Besonders praktisch ist cycle.
Aus der Beschreibung:
ZitatYou can control the power on a USB port(s) like this:

uhubctl -a off -p 2
This means operate on default smart hub and turn power off (-a off, or -a 0) on port 2 (-p 2). Supported actions are off/on/cycle (or 0/1/2). cycle means turn power off, wait some delay (configurable with -d) and turn it back on.
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

dadoc

Nun, das Reconnecten scheint nicht immer problemlos zu klappen:

2018.08.15 12:14:08 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2018.08.15 12:14:08 1: Perfmon: possible freeze starting at 12:14:06, delay is 2.971
2018.08.15 12:14:08 3: Setting CUL_0 serial parameters to 9600,8,N,1
2018.08.15 12:14:18 1: Cannot init /dev/ttyACM0, ignoring it (CUL_0)

Vielleicht weil init mit einem freeze zusammenfiel, aber vielleicht ist ja auch der Reconnect der Grund für den freeze.
Da ist wohl noch ein wenig Forschungsarbeit nötig.
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Wernieman

Wenn Du den CUL Stromlos machst und Strom gibt, aber FHEM in der Zeit das Device /dev/ttyACM0 noch nicht freigab, wird der Kernel genau das Device nicht nehmen, sondern /dev/ttyACM1 (oder 2 oder 3....)

Btw: Besser /dev/serial/by-id/....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dadoc

Hast Du da einen Tipp für das Timing? Bzw. hängt die Freigabe des Device seitens fhem von der Länge der Stromlos-Zeit ab?
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Wernieman

Nein ... es ist wichtig, des fhem (oder ein anderes Proggi), das Device wirklich abklemmt
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dadoc

Meinst Du mit ,,abklemmen" ein delete des Device (und folgendes Neuanlegen)? Bim Rumprobieren scheint es auch durch ein rereadcfg wieder gefunden zu werden...?
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Wernieman

Nein ich minte das technische dahinter. Mal platt ausgedrückt: Der "Filehandel" /dev/ttyACM0 muß freigegeben werden.

Was ich wiederholen möchte:
ZitatBtw: Besser /dev/serial/by-id/....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dadoc

Zitat von: Wernieman am 15 August 2018, 20:04:26
Nein ich minte das technische dahinter. Mal platt ausgedrückt: Der "Filehandel" /dev/ttyACM0 muß freigegeben werden.
Ich habe trotz längerer Suche nicht herausgefunden, wie ich diese Freigabe anstoßen könnte.
Zitat
Was ich wiederholen möchte:
Das habe ich in der CUL-DEF entsprechend geändert. Steht das im Zusammenhang mit der Freigabe des Filehandle? Sorry, da stoßen meine noch limitierten Linux-Kenntnisse an ihre Grenzn...
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Wernieman

Nein. Es geht darum, das bei /dev/serial/by-id der Devicename nach der ID-des Geräts gewählt wird. Also wird *), jedes mal der gleiche Name verwendet. bei /dev/ttyACM0 (genauso bei ttyUSB etc) wird dagegen per Nummer hochgezählt. also anstatt der 0 eine 1 oder 2 oder eben n bei N Geräten. Wenn man nun z.B. 2 Serielle Geräte hat, kommt es auf die Reihenfolge beim booten an, welches Gerät welche Nummer bekommt. Eben wie bi Windows mit COM1,2,3 ..

*) Es gibt eine Ausnahme:
z.B. bei Billig FTTI spart sich der "Hersteller" meist eine Anpassung der ID. Wenn man nun2 solche Geräte hat, sieht Linux jedes mal den gleichen Devicenamen ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dadoc

Danke, jetzt hab ich's verstanden. Damit dürfte dann das "Cannot init..."-Problem nicht mehr auftreten, oder hat der Kernel auch ein Problem, wenn fhem  /dev/serial/by-id/xyz-busware... noch nicht freigegeben hat, wenn wieder Strom draufkommt? Falls ja: wie kann man fhem zur Freigabe des CUL "zwingen"?
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Wernieman

Zitatwie kann man fhem zur Freigabe des CUL "zwingen"?
Dad weiß ich nicht ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html