Posts by Michdo93

    Hi,


    jetzt fragt sich sicherlich jemand, warum ich bei Stromversorgung das Thema Wake on LAN aufmache. Diejenigen, die sich damit schon ein wenig näher befasst haben wissen, dass dies zusammenhängt. Eine Wake on LAN Funktionalität würde nur funktionieren, wenn die Netzwerkkarte dauerhaft mit Strom versorgt wird. Dies ist bei den Raspberry Pi Modellen standardmäßig nicht der Fall. Die Netzwerkkarte ist mit dem USB-Hub verbunden. Bedeutet eine Raspberry Pi startet erst, wenn ich den Stecker (wieder) einstecke.


    Softwareseitig bin ich nicht sicher, was ich lösen müsste. Ich müsste vermutlich den Kernel umschreiben, oder? Die Konfiguration wäre wie bei jedem Gerät bspw. wie folgt machbar:


    Code
    sudo apt-get install ethtool
    sudo apt-get install etherwake
    
    sudo ethtool -s eth0 wol g


    Kann man auch tatsächlich so installieren und konfigurieren. Jedoch kann man nicht über


    Code
    sudo etherwake -i eth0 [MAC]


    die Raspberry Pi aufwecken, da eben die Netzwerkkarte nicht mit Strom versorgt ist oder eine eingeschaltene Raspberry Pi noch einmal aufgeweckt werden kann.


    Eine Lösung sind Funkschaltsteckdosen, die man davor setzt (bzw. die Raspberry Pi in einer dieser einsteckt und diese in die eigentliche Steckdose steckt) und entsprechend anschält. Das ist für mich aber nicht der Punkt. Alternativen für eine USV wären sicherlich auch mal interessant, löst aber nicht die Problematik, dass die Raspberry Pi, nachdem sie (versehentlich) heruntergefahren wurde, wieder angeschalten werden kann.


    Klar kann man sagen: "Junge, steh auf, beweg dich und ziehe den Stecker und stecke ihn wieder ein!"


    Haha, denkst du. Ich spreche hier von Raspberry Pi`s, die unter Umständen gar nicht so leicht erreichbar sind, je nachdem, wo sie installiert wurden. Da kommt man entsprechend nur einmal hin oder nur ungeschickt usw. und die LAN-Verkabelung würde in diesem Szenario einmal installiert werden und bleiben. Meinetwegen müsste man sonst jedes mal eine Leiter holen oder hinter einer (künstlichen) Wand klettern oder sonst etwas.


    Genug Motivation und hätte, wäre, wenn für dieses Thema. Was nicht geht und warum es nicht geht, ist jetzt jedem klar und welche Vorteile man sich erhoffen könnte. Eine Raspberry Pi kostet vielleicht nur 6 bis 7 € Strom pro Jahr. Schaltsteckdosen würden dahingehend den Preis noch einmal erhöhen.


    Ich spreche ja nicht grundlos an, dass man softwareseitig vermutlich den Kernel umschreiben müsste. Der entscheidenere Part ist jedoch, was könnte ich auf der Hardwareseite tun? Wir basteln doch alle an Raspberry Pi`s öfter rum. Löten irgendwelche Stecker oder auch meinetwegen Platinen oder sonst etwas, was wir mit der Raspberry Pi verbinden. Wenn ich die Raspberry Pi herunterfahre (über SSH), dann stecke ich den Stecker ja nicht aus und wenn ich Stunden oder Tage später wieder ran will, dann wäre es ja durchaus elegant, wenn ich eben den Stecker nicht noch einmal einstecken müsste. Kurz: Die rote LED leuchtet ja weiterhin und die Raspberry Pi hat in gewissermaßen doch auch eine Stromversorgung. Nur eben nicht der USB-Hub bzw. für diesen Use Case die Netzwerkkarte. Mein theoretischer Ansatz wäre es, dass ich die Stromversorgung der Netzwerkkarte eben nicht mehr über den USB-Hub realisiere. Bleiben wir einfach mal in diesem Szenario ohne mögliche Nachteile zu bedenken. Was müsste ich genau dafür tun? Welche Bauteile würde ich benötigen? Und an welchem Punkt, müsste ich einen Schalter oder einen Widerstand umgehen und wo entsprechend neu anlegen? (Ich kann ja unmöglich der Erste sein, der sich darüber Gedanken macht). Und als nächstes müsste man dann doch auch bedenken, wie schaffe ich es, die Netzwerkkarte sauber mit dem Rest der Raspberry Pi zu integrieren. Hätte die Abkapselung der Stromversorgung zur Folge, dass Daten nicht mehr mit der Raspberry Pi ausgetauscht werden würden? Daten- und Stromleitungen liegen ja manchmal zusammen. Kann ich dies separat voneinander verkabeln? Wenn ja, wie? Wenn Daten- und Stromleitung nicht voneinander trennbar wären, was wäre die Folge? Normalerweise würde ich ja davon ausgehen, dass dies geht. Im Zweifel Kabel aus der Isolierung rausnehmen und die Ader für die Stromversorung abzwicken. Die Datenleitung nutzt ja auch verschiedene Spannungen für die Signale, nur die Stromleitung würde konstant genug Spannung zur Verfügung stellen, dass die Netzwerkkarte betrieben werden kann. Was würde aber passieren, wenn es wirklich nicht trennbar wäre, ich eine zweite Stromleitung anlege, die die Netzwerkkarte dauerhaft mit Strom versorgt? Ich müsste nach dem Einschalten diese Stromzufuhr wieder unterbinden, da die Netzwerkkarte nun wieder über den USB-Hub mit Strom versorgt werden würde. Ergo müsste ich ebenfalls einen "Schalter" berücksichtigen. Und wie erkennt dieser, dass die Raspberry Pi nun geweckt werden würde? Ich meine man sollte ja vermeiden, dass man die Netzwerkkarte grillt... Das wäre jetzt aber nur die Überlegung zur Stromversorgung der Netzwerkkarte. Eine weitere Kleinigkeit dürfte man nicht außer Acht lassen. Die Platine ist ja grundlegend nicht dafür konzipiert worden. Was müsste sich ändern, dass die Netzwerkkarte dann tatsächlich die Raspberry Pi aufwecken könnte? Sie alleine mit Strom zu versorgen, wäre ja vermutlich nicht die Lösung. Da fehlt noch etwas.


    Mich interessiert daher die technische Frage, wie ich die Platine "umbauen" müsste. Und vielleicht hat da sogar jemand mal die Lust gehabt, ein wenig zu experimentieren. Für verschiedene Lösungen, bin ich gerne offen. Bevor jetzt jemand sagt, dass man einfach den Stecker ziehen könnte, an dem später die Raspberry Pi eingesteckt wird, wie bspw. bei Verlängerungskabeln oder Mehrfachsteckdosenleisten, dem verneine ich schon direkt. Auch wenn man Wände oder was weiß ich hochzieht, sind manchmal schon auch Steckdosen an "unmöglichen" Stellen verbaut.


    Mir geht es da um die Alternative und ehrlicherweise verstehe ich auch nicht, warum man dies nicht gleich von Werk aus bedacht hat. Wenn wir jetzt an Smart Home denken, dann wird dies ja auch bei jedem noch so unbedeutendem Kleingerät (gewisse Wecker, Uhren etc.) berücksichtigt. Warum also nicht auch bei Raspberry Pi`s.


    (Trotz einiger Einwände, ein ernst gemeintes Thema. Ich meine ich weiß ja schon vorab, was da teilweise wie kommen würde).


    Liebe Grüße

    hast Du vielleicht eine Echtzeituhr verbaut ? Falls ja prüfe doch mal auf welchem I2C-Platz die liegt (46), meine liegt auf 65, aber es gibt andere ...

    Ansonsten würde ich trotzdem probeweise die I2C Adresse des Sense HAT ändern, falls möglich.

    Das habe ich glaube ich auch irgendwo online mal auf Englisch gelesen gehabt. Wenn ich die Sense HAT nicht anschließe, ist aber die 46 "leer". Ich habe mir aber auch überlegt, ob dafür einfach das Treibermodul geladen wird.


    Bei der rasclock könnte es zu einem "UU" kommen.

    https://raspberrypi.stackexcha…does-uu-mean-for-rasclock


    Wenn ich google, finde ich aber, dass pcf8523 dieselbe Adresse verwendet. Auch der Gassensor SCD30. Sicherlich noch weitere Geräte. Wenn man über UU sich informiert, dann findet man eben Aussagen wie, dass ein Gerät busy ist oder nicht erkannt wird oder eben, dass mehrere Treibermodule geladen sind. Wie kann ich herausfinden, welche Treibermodule entsprechend das Problem verursachen könnten? Also kann es sein, dass er da überhaupt ein Problem hat, wenn er diese Adresse erkennt, dass er nicht weiß, welchen Treiber er hierfür überhaupt verwenden muss?


    In einem Buch habe ich nach der Installation der Sense HAT jedoch auch gesehen, dass UU statt 46 steht.


    Hier sehen wir aber auch, dass eine 46 bei richtiger Installation angezeigt werden sollte:

    https://personalpages.hs-kempt…/SenseHAT/web_report.html


    Mal schauen, muss da wohl noch ein wenig hin und her probieren. Es hat was mit der LED-Matrix und dem Treiber zu tun.

    Hi,


    die Raspberry Pi Sense HAT wird an meiner Raspberry Pi nicht richtig erkannt. Ich kann ein defekt auch nicht ausschließen. Ich habe sie an zwei Raspberry Pi`s angeschlossen und getestet. Mal mit Flachbandkabel und mal aufgesteckt. Also auch kein Problem der Kabel. Hardware-Probleme der Raspberry Pi`s schließe ich ebenfalls aus.


    Natürlich ist I2C aktiviert. Bei meiner Raspberry Pi wäre auch SPI aktiviert, aber für die Sense HAT an für sich benötige ich nur I2C meines Wissens. Da ich auch bereits einen Roboter mit der Sense HAT gebaut habe, denke ich, dass ich alles richtig gemacht haben dürfte. Die Pakete für die Sense HAT sind auch installiert.


    Für die Adresse 0x46 wird leider UU anstelle von 46 angezeigt. Ich denke dies ist der Indiz für den Fehler. An meiner zweiten Raspberry Pi hat das Problem zur Folge, dass weitere Geräte die über den I2C-Bus angeschlossen wurden, nicht funktionsfähig waren. Daher liegt eine Störung vor. I2C-Busse sind ja sehr sensibel. Wenn ein Kabel leicht geknickt ist, funktionieren bspw. Servomotoren nicht mehr, wie ich gemerkt habe, auch wenn sie nicht direkt betroffen wären. Egal, sollte nicht all zu sehr abschweifen. Nimmt man den Problemverursacher wieder raus, gehen die anderen Komponenten. Dadurch ist mir erst in den Sinn gekommen, dass die Sense HAT das Problem verursachen könnte.


    Hier die Informationen zur Sense HAT:

    https://pinout.xyz/pinout/sense_hat


    Hier das Ergebnis von meinem i2cdetect:


    Code
    $ i2cdetect -y 1
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
    10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- -- 
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    40: -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- 
    50: -- -- -- -- -- -- -- -- -- -- -- -- 5c -- -- 5f 
    60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- -- 
    70: -- -- -- -- -- -- -- --