Mögliche Reduzierung bzgl. RaspberryPi4 Funkwolkenproblematik

[jmaus]

Hallo Zusammen,

wie einige von euch wissen haben wir ja leider das leidige Problem, das bei der Nutzung eines RaspberryPi4 in Kombination mit einem Funkmodul (RPI-RF-MOD/HM-MOD-RPI-PCB) auf dem GPIO Port es zu mitunter heftigen Einschränkungen bzgl. der Sende-/Empfangsqualität zu homematic Geräten im 868MHz Bereich kommt. Oft äußert sich das ja vor allem dadurch, das z.B. HmIP Geräte mitunter gar nicht mehr angelernt oder bedient werden können. Wir wir ja feststellen mussten, liegt das leider wohl an RaspberryPi4 spezifischen Hardwareeinschränkungen die den Pi4 mitunter zu einem heftigen "Störstrahler" in seiner näheren Umgebung machen. Und so ist und war ja unsere bisherige Herangehensweise Nutzern eines Pi4 zu raten das Funkmodul mittels HB-RF-USB-2 oder HB-RF-ETH Platine so weit wie möglich abseits vom eigentlichen RaspberryPi4 zu betreiben.

Nun experimentiere ich gerade mit der Idee in RaspberryMatic eine Funktionalität anzubieten die es erlaubt die (meines Wissens) vor allem dafür verantwortlichen USB Ports des RaspberryPi4 gänzlich via Software deaktivieren zu lassen - in der Hoffnung, das das bereits ausreicht um die Störwolke soweit zu reduzieren, das damit dann vielleicht doch noch eine Kommunikation möglich ist.

Leider ist meine eigene Pi4 Testumgebung diesbzgl. sehr limitiert und zumindest momentan nehme ich keine Probleme diesbzgl. wahr. Deshalb würde ich interessierte Nutzer hier im Forum die das Problem bereits gesehen bzw. aktuell haben bitten, zu versuchen das noch einmal nachzustellen. D.h. zu versuchen genau das Problem (kann keine HmIP Geräte mit einem Pi4 anlernen) versuchen zu reproduzieren und dann als mögliche Lösung einfach mal den folgenden Befehle via einer SSH verbindung auszuführen:

Code: Alles auswählen

echo '1-1' >/sys/bus/usb/drivers/usb/unbind
echo '2-2' >/sys/bus/usb/drivers/usb/unbind

oder Alternativ:

Code: Alles auswählen

echo 1 >/sys/bus/pci/devices/0000\:01\:00.0/remove

Diese Befehle sollte dafür sorgen das alle USB Ports des Pi4 (USB2+USB3) deaktiviert und folglich auch stromlos gemacht werden. Und dann sollte man (ohne weitere dinge zu verändern) bitte noch einmal probieren ob danach das Anlernen bzw. bedienen der HmIP Geräte dann (besser) geht oder das Problem weiterhin besteht.

Die Hoffnung ist wie gesagt, vllt. nicht gänzlich das Problem damit zu beseitigen, aber eben genauso wie durch das abschalten des HDMI Ports eine gewisse "Entlastung" hinzubekommen in dem man eben die USB Ports (und vllt. auch noch andere Dinge) abschalten lässt bis der Pi4 ein zumindest akzeptables Nutzungsverhalten diesbzgl. zeigt.

Und wenn jemand natürlich ein Spektrum-Analyzer hat um hier ggf. das Problem und die eventl. Lösung durch Abschaltung der USB-Ports auch besser objektivieren zu können (in dem man schaut ob die Störwolke eben nachweislich nachlässt) dann wäre das sicherlich auch hilfreich

In diesem Sinne, Freiwillige bitte vortreten!

[deimos]

Hi,

zumindest der eigentliche Controller Chip wird dadurch nicht stromlos gemacht, der wird weiter am PCIe Bus hängen und zumindest mal lauschen.
Allgemein sorgt der Befehl auch nicht für ein komplettes Abschalten der Spannung, je nach Layout und Controller hat man weiter Spannung auf dem Bus, teilweise aufgrund von schlechtem Design, teilweise aber auch gewollt um einen externen Wakeup durch USB Geräte zu ermöglichen.

Aber einen Versuch ist es auf jeden Fall mal wert.

Viele Grüße
Alex

[jmaus]

Also ich bin auch skeptisch und bei weitem nicht überzeugt ob das wirklich zum Erfolg führt, aber das die Probleme aus der richtung des USB Controllers bzw. der USB Ports kommt scheint wohl breit bekannt zu sein.

In meiner Pi4 Testumgebung konnte ich es nun zumindest dieses verhalten feststellen:

1. Habe ich nichts an den USB Ports angeschlossen ist der CarrierSense im wenigen Prozentbereich und ich kann HmIP Geräte anlernen
2. Stecke ich eine USB2 Tastatur an den Pi4 geht auch hier weiterhin das Anlernen und das CS steigt unwesentlich an
3. Stecke ich zusätzlich einen USB3 MemoryStick an (der dann an Port '2-2' gesetzt wird), dann steight der CS schlagartig auf >50% und folglich ist dann auch kein Anlernen mehr möglich
4. Die von mir vorgeschlagenen Kommandos deaktivieren wohl in der Tat die USB Konnektivität, aber die USB Power wird (wie von dir vermutet) wohl nicht gänzlich abgeschalten, denn der MemoryStick z.B. lässt brav seine blaue LED an, d.h. er wird weiterhin mit Strom versorgt. Und leider führt die alleine wohl in der Tat nicht zum gewünschten Erfolg - Aber vllt. kann das jemand anders noch verifizieren?

Die Frage wäre also ob es noch andere Methoden gibt (z.B. nutzung von "uhubctl") die wir in erwägung ziehen könnten um die USB Ports gänzlich via Software deaktivieren zu lassen (inkl. USB Power) oder ob das vllt. sogar gar nicht geht. Zumindest die "uhubctl" Variante versuche ich gerade nochmal durchzutesten.

[Daimler]

Hi,

und was ist, wenn man mal per Tastatur drauf will / muss, weil übers Netz nichts mehr geht?

[jmaus]

und was ist, wenn man mal per Tastatur drauf will / muss, weil übers Netz nichts mehr geht?

Dann ist das natürlich nicht mehr möglich - ist ja logisch. Soll ja auch (wenn es denn geht) eine optionale Abschaltung aller USB Ports werden und nicht generell. Aber noch ist diesbzgl. nichts spruchreif, also ruhig Blut

[Daimler]

also ruhig Blut

Warum sollte mein Blut deswegen unruhig werden - ich habe ja gar kein ...

War nur als Hinweis gedacht - eine Tastatur wird man 99,9 %ig iwann benötigen.

[jmaus]

Die Frage wäre also ob es noch andere Methoden gibt (z.B. nutzung von "uhubctl") die wir in erwägung ziehen könnten um die USB Ports gänzlich via Software deaktivieren zu lassen (inkl. USB Power) oder ob das vllt. sogar gar nicht geht. Zumindest die "uhubctl" Variante versuche ich gerade nochmal durchzutesten.

So, also hier noch ein kurzes Statusupdate. Auch der folgende Befehl scheint zwar softwaretechnisch aufzuräumen und dann selbst via "lsusb" keinerlei Geräte mehr im System übrig zu lassen, aber auch das scheint bisher keine Besserung zu bringen:

Code: Alles auswählen

echo 1 >/sys/bus/pci/devices/0000\:01\:00.0/remove

Damit wird wohl der komplette PCIe controller aus dem System entfernt (der wohl nur am USB hängt). Aber leider bringt das auch nicht den gewünschten Erfolg und auch danach bleibt die LED des USB-Sticks aktiv und der CarrierSense im Bereichn von 40-50%.

[jp112sdl]

AFAIK tritt das Problem doch nur auf, wenn die USB 3.0 Ports verwendet werden.

Wenn nur die beiden USB 2.0 Ports verwendet werden, sollte es doch keine Probleme geben, oder?

Da man USB 2 und 3 leider nicht getrennt abschalten kann, wäre eine komplette Controller-Abschaltung doch schon schlecht für an den USB 2.0 angesteckte Sticks (Diagramme, Backups).

Ich betreibe einen RPi4 mit einem direkt angesteckten HM-UART als hmlangw und einem SDR für Wettersatellitenempfang ohne Probleme.

Es darf halt nur nichts am USB 3 Port stecken.

Ich weiß nicht, ob es sinnvoll ist, den USB Controller ganz abzuschalten, oder lieber darauf hinzuweisen, "die blauen Buchsen" bitte nicht zu benutzen - denn die beiden anderen Ports gehen ja doch eigentlich?

[jmaus]

AFAIK tritt das Problem doch nur auf, wenn die USB 3.0 Ports verwendet werden.

Wenn nur die beiden USB 2.0 Ports verwendet werden, sollte es doch keine Probleme geben, oder?

[...]
Es darf halt nur nichts am USB 3 Port stecken.

Ich weiß nicht, ob es sinnvoll ist, den USB Controller ganz abzuschalten, oder lieber darauf hinzuweisen, "die blauen Buchsen" bitte nicht zu benutzen - denn die beiden anderen Ports gehen ja doch eigentlich?

Das ist ein guter Hinweis der mir bis dato noch nicht so bewusst war bzw. den ich nicht mehr so auf dem Schirm hatte, ja. Hab das gerade mal bei mir getestet und den USB3 Stick und die Tastatur auf die schwarzen USB2 Ports des Pi4 umgesteckt und in der Tat tritt hier (egal ob ich den PCIe controller komplett abschalte oder nicht) bei mir eine wesentliche Besserung ein und ich kann nicht nur jetzt meine Testgeräte anlernen, sondern auch der CS ist so zwischen 0-10% "nur".

Ein Test hab ich noch offen (mittels des "uhubctl" tools), aber in der Tat wäre das natürlich mitunter ein akzeptabler Weg, d.h. lediglich in der Doku irgendwo zu vermerken das bei Nutzung eines Pi4 mit GPIO Funkmodul man sicherstellen muss das die USB3 Ports nicht verwendet werden. Ggf. könnte man ja sogar darüber nachdenken einen WatchDog Alarm losgehen zu lassen wenn jemand mit einem Pi4 und GPIO Funkmodul etwas an die USB3 Ports steckt, oder was meint ihr/du? Erkennen könnte ich das hier in der Tat zumindest wenn es sich dabei um ein USB3 Gerät handelt.

Zu testen wäre auch noch was passiert wenn man ein reines USB2 Gerät an die USB3 Buchsen anschließst, ob das dann ein problem darstellt?!?

[MichaelN]

Ist USB3 nicht auch dafür bekannt WLAN oder DECT zu stören? Vielleicht kannst Du ganz pragmatisch eine Prüfung vornehmen, ob an USB3 etwas angeschlossen ist und dann eine Warnmeldung erzeugen.