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
...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
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.
Gibt auch USB-Hubs, welche mit "Linux-Bordmitteln" schaltbar sind ...
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?
Hast du "make install" als root ausgeführt?
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Ja
Was war denn die Letzte Ausgabe? Hat den das compilieren geklappt?
root@raspberrypi:~/uhubctl# make
make: 'uhubctl' is up to date.
root@raspberrypi:~/uhubctl#
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/"
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.
Das funktioniert super, es lassen sich z.B. im laufenden fhem-Betrieb CULs stromlos machen und wieder anschalten, falls mal was hängt...
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?
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.
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.
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/....
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?
Nein ... es ist wichtig, des fhem (oder ein anderes Proggi), das Device wirklich abklemmt
Meinst Du mit ,,abklemmen" ein delete des Device (und folgendes Neuanlegen)? Bim Rumprobieren scheint es auch durch ein rereadcfg wieder gefunden zu werden...?
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/....
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...
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 ...
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"?
Zitatwie kann man fhem zur Freigabe des CUL "zwingen"?
Dad weiß ich nicht ...