Beiträge von jeas

    Ich habe heute versucht, ein Adafruit USB Power Gauge Mini-Kit (http://www.adafruit.com/products/1549) mit einem (ebenfalls Adafruit) Serial Console Cable (http://www.adafruit.com/products/954) zu verheiraten, weil die Beschreibung des Mini-Kits eigentlich recht vielversprechend klang, was die Unterstützung des seriellen Ausgangs für verschiedene Arten von seriellen Kabeln angeht ("Connect an FTDI friend, USB console cable, microcontroller, XBee, whatever you want that can read 9600 baud TTL serial data for datalogging, plotting or display.").

    Funktioniert hat's zumindest an einem Windows-PC mit Putty (9600 baud) trotzdem nicht. Mit der Kombi kann ich mich aber bspw. problemlos auf die serielle Konsole eines RPi verbinden. Allerdings in diesem Fall mit 115200 Baud.

    Daher meine Frage: Weiß jemand, oder hat es schon erfolgreich ausprobiert, ob das Mini-Kit und das Serial Console Cable grundsätzlich miteinander sprechen können sollten oder nicht? Kann das Kabel ausschließlich 115200 baud oder stört es sich daran, dass vom Mini-Kit ausschließlich TX=> RX und GND=>GND verbunden werden (das Mini-Kit hat nur einen TX)? Habe ich nur etwas falsch gemacht oder muss ich mir noch ein anderes Kabel für das Auslesen des seriellen Ausgangs des Mini-Kits bauen oder beschaffen? FTDI?

    Ist evtl. eine direkte Verdrahtung mit dem seriellen Port des RPi ohne Umweg über ein Serial to USB-Kabel möglich? Oder wird zwingend ein Kabel und/oder Breakout Board benötigt?

    Edit: Ach Mann, ungefähr drei Sekunden nach dem Absenden des Beitrags ist mir die Lösung dann selbst eingefallen... :) Ich muss natürlich beim Serial Cable auch an die weiße und nicht an die grüne Ader dran. Kaum macht man's richtig, geht's auch...

    Ich dachte mir schon, dass diese Antwort irgendwann kommt, aber gut... :D

    Kurze Antwort: Ja, ich habe mir im Voraus darüber Gedanken darüber gemacht, ob ich unbeaufsichtigte Updates auf den Systemen einspielen will oder nicht. Ich habe diverse Vorkehrungen getroffen, um zu verhindern, dass ein fehlerhaftes Update auf einem der RPis zu einem ernsthaften Problem wird.

    Damit überwiegt der Nutzen (voll-)automatischer Updates auf den Clients, um die ich mich nicht dann fast nicht mehr kümmern muss, deutlich das Risiko eines Updates, welches mir einen der RPis platt macht.

    Falls ich der einzige bin, dem es so geht, muss ich halt selbst weitersuchen, falls nicht, bin ich nach wie vor für Tipps zu meinem Ausgangsproblem dankbar.

    ---------------------------------------

    Und hier noch die lange Antwort, falls das wirklich jemand lesen will:

    Alle zu patchenden Systeme hängen am Internet und ich habe ein gesteigertes Interesse daran, dass diese auf dem jeweils aktuellen Patchstand sind.

    Alle Systeme werden per Nagios überwacht und ich merke innerhalb von fünf Minuten, wenn eins davon nach einem Update platt ist.

    Alle Systeme werden automatisch gebackupt und im schlimmsten Fall kann ich ein komplettes Systembackup wieder einspielen, das maximal eine Woche alt ist. Das reicht bei diesen Systemen vollkommen aus, da sich inhaltlich nicht so oft etwas darauf ändert.

    Bei zwei der betroffenen Systeme ist es nicht kriegsentscheidend und zeitkritisch, wenn irgendwas beim Update schief geht. Und bei den anderen beiden handelt es sich um Failover-Systeme, die jeweils mit 12 Stunden Versatz gepatcht werden. D.h. wenn das Update auf einem schief geht, springt automatisch der zweite ein und ich habe 12 Stunden Zeit, das automatische Update auf dem Failover-System abzudrehen, um zu verhindern, dass dieses ebenfalls "totgepatcht" wird.

    Der für mich entscheidende Punkt ist jedoch der: Ich kann ohnehin nicht beurteilen, ob ein zum Update angebotenes Paket mein System platt macht oder nicht. Ich habe ehrlich gesagt nicht die Zeit, das vorher für jedes Paket zu recherchieren und ich habe nicht die Zeit, hinterher alle Funktionalitäten der Clients zu verifizieren. Also ist es letztlich egal, ob ich selbst auf den Knopf drücke oder das automatisch morgens um Sieben passiert. In den vergangenen zwei Jahren habe ich immer - Augen zu und durch - auf den Knopf gedrückt. Dabei ist tatsächlich ein einziges Mal ein Update eingespielt worden, dass mir bestimmte Funktionalitäten zerschossen hat, und zwar das Firmware-Update, bei dem der Device Tree-Support plötzlich per Default eingeschaltet war und mir diverse Schnittstellen (i2c, 1wire, etc.) weggeflogen sind. Das habe ich trotz manuellem Update trotzdem erst gemerkt, als es schon zu spät war.

    Hmmm...

    Aktualisiert ihr eure RPis alle von Hand? Ich hätte gedacht, dass ich nicht der einzige hier bin, der gern ein aktuell gepatchtes System auf seinen Raspis hätte, ohne die ständig alle manuell überprüfen zu müssen. ;)

    Oder benutzt ihr alle was anderes als das Unattended Upgrades-Paket?

    Hallo zusammen,

    ich versuche seit einiger Zeit (erfolglos) dem Unattended Upgrades-Package beizubringen, auch die Pakete aus der Komponente "rpi" mit zu aktualisieren.

    Mit meiner bisherigen Konfiguration werden jedoch die Pakete aus dieser Komponente regelmäßig ausgelassen und warten darauf, manuell aktualisiert zu werden. Also zum Beispiel raspberrypi-bootloader, libraspberrypi-bin, libraspberrypi-dev, etc.

    apt-cache policy sagt zu diesen Paketen das hier:

    Code
    500 http://mirrordirector.raspbian.org/raspbian/ wheezy/rpi armhf Packages
         release v=7.0,o=Raspbian,a=stable,n=wheezy,l=Raspbian,c=rpi
         origin mirrordirector.raspbian.org

    Nachdem, was ich verstanden habe, würde ich also erwarten, dass "o=Raspbian,a=stable,c=rpi" in der u.a. Konfig dafür sorgt, dass auch diese Packages beim Upgrade erfasst werden. Obwohl der Eintrag eigentlich nur eine "Spezialisierung" von "o=Raspbian,a=stable" sein sollte, aber vielleicht habe ich auch das System für die Angabe der Patterns noch nicht ganz verstanden:

    Jedenfalls funktioniert es nicht, egal ob mit oder ohne explizit angegebenes "c=rpi", also scheint der Fehler noch woanders zu liegen:

    Code
    2015-04-07 11:54:06,567 INFO Skript für unbeaufsichtigte Upgrades wird gestartet.
    2015-04-07 11:54:06,569 INFO erlaubte Ursprünge sind: ['o=Raspbian,a=stable', 'o=Raspbian,a=stable-updates', 'origin=Raspbian,archive=stable,label=Raspbian-Security', 'o=Raspbian,a=stable,c=rpi']
    2015-04-07 11:54:18,111 INFO Es wurden keine Pakete gefunden, von denen ein unbeaufsichtigtes Upgrade durchgeführt werden kann.

    Hat jemand eine Idee, was ich in die Konfig eintragen muss, damit auch die "rpi"-Komponenten automatisch aktualisiert werden?


    Es würde mich auch interessieren wie gut das mit dem Multiplexer klappt. Hatte mir den Multiplexer auch mal für I2C gekauft, allerdings hatte ich noch keine Notwendigkeit ihn einsetzen zu müssen. Freue mich schon auf deinen Erfahrungsbericht ;)

    Der Mulitplexer könnte ja wirklich eine "billige" Lösung des Problems werden. Ich werde das auf jeden Fall ausprobieren. Mit dem Erfahrungsbericht könnte es aber noch ein paar Wochen dauern. Ich muss erst einmal wieder Zeit finden für umfangreichere Installationen. :) Und außerdem muss ich erstmal wieder eine etwas längere Teileliste für eine Bestellung zusammenbekommen, damit sich die Versandkosten wenigstens lohnen. :)


    Du könntest statt einer festen Lötbrücke den Pin mit je einem Transistor schalten, oder mit dem Ausgang eines Schieberegisters. Dann reagiert der ausgewählte Chip auf eine andere Adresse als alle nicht gewählten Chips. Schieberegister kannst du kaskadieren und somit fast beliebig viele Chip-Select-Signale aus 4 Steuerleitungen generieren.

    Auch noch eine gute Idee. Für meine Zwecke werde ich dann aber mit 16x3 Sensoren tatsächlich auskommen. Ggf. kann ich den zweiten I2C-Port ja auch noch aktivieren und vermutlich geht ein einzelner RPi bei einer solchen Bestückung plus Nagios dann ohnehin langsam in die Knie. :D

    Wenn ich das Prinzip richtig verstehe, ließen sich die Multiplexer im Ernstfall wohl auch noch kaskadieren. (?) Wahrscheinlich wird das Signal bei zu vielen Stufen irgendwann zu "unsauber" oder bekommt eine zu große Latenz bei durchgezogener SCL-Leitung, aber mit zwei Multiplexer-Stufen könnte man ja fast schon eine ganzes Bürogebäude (wenn man mal die erforderlichen Leitungslängen ignoriert) überwachen. :)


    Mein Fehler, hab von drei Lötpunkten auf 3 Bit geschlossen. Dann wirst Du wohl doch einen I2C HUB oder etwas Ähnliches brauchen. Benötigst Du denn einen genauen Helligkeitswert oder würde eine hell / dunkel Info reichen?

    Ich brauche nicht für jeden Sensor zwingend genaue Werte, für mehr als drei aber mittelfristig schon.

    Simple analoge Sensoren (wo ich jetzt grob vereinfachend auch alles hinzuzähle, was lediglich "high" oder "low" liefert) sind mir natürlich auch schon in den Sinn gekommen, aber das ist dann immer so ein Gefrickel, die vernünftig abzufragen bzw. anzusteuern.

    Ich will da, wo es geht, Sensoren einsetzen, die ein (serielles) Protokoll mit einer gewissen Transaktionssicherheit zur Datenübertragung verwenden. In den allermeisten Fällen funktionieren die entweder oder sie tun es nicht. Die Grauzone dazwischen ist im Vergleich zur Anbindung analoger Sensoren extrem klein. Und da sind dann wohl aktuell 1wire oder I2C die Protokolle der Wahl.

    Zum Stichwort I2C Hub habe ich allerdings bisher immer nur passive Elemente gefunden, die einfach die vier Leitungen für den I2C-Bus duplizieren. Sowas hilft mir nicht weiter - Leitungen zusammenstecken kann ich auch auf dem Breadboard. :) Hast du da evtl. noch einen konkreten Tipp für einen "aktiven" I2C Hub, der I2C-Clients tatsächlich unabhängig und separat behandeln und weiterreichen kann?


    Was mir grad noch einfällt, einfacher wäre es wohl die SDA Leitung zu multiplexen, z.B. mit dem hier http://www.watterott.com/de/Analog/Digital-MUX-Breakout

    Über diese Idee bin ich bei meiner Recherche auch schon gestolpert. Ich habe nur noch nicht ganz verstanden, wie das praktisch funktioniert.

    Was ich mir zusammengeraten habe: Ich verbinde ich GND, 3,3V und SCL bei allen I2C-Clients direkt durch bis zum RPi. Die SDA-Leitungen aller Clients kommen auf C0 bis C15 des Multiplexers (bzw. in meinem Fall bis zu drei Sensoren auf einen Pin). Die SIG-Leitung des Multiplexers kommt als SDA-Leitung an den RPi. Und dann steuere ich über vier GPIO-Pins des RPi, welche der 16 Signalleitungen "durchverbunden" wird und kann dann jeweils immer die gerade verbundenen Sensoren abfragen. Ist das soweit richtig gedacht?

    Ich kann mich in diesem Zusammenhang erinnern, irgendwo gelesen zu haben, dass SCL ggf. ebenfalls über einen Multiplexer gehen sollte, weil es sonst nicht funktioniert. An eine Begründung dafür kann ich mich allerdings nicht erinnern. Was meint ihr?


    Dir ist hoffendlich auch bewußt, daß man nicht nur eine Lötbrücke als Adresse pro Sensor setzen kann, oder?

    Was meinst du damit? Das Adafruit TSL2561 Board hat drei Lötpunkte für die Wahl der Slave-Adresse. Lässt man sie offen, meldet sich der Sensor auf Adresse 0x39, verbindet man den mittleren mit einem der beiden anderen (Masse oder 3,3V), meldet sich der Sensor auf Adresse 0x29 bzw. 0x49. Mehr geht bei dem Board m.W. nicht.


    du meinst 3 Lötbrücken ? = 2 ^ 3 gibt 8, jede Lötbrücke kann offen oder zu sein

    [...]

    Addressänderung gilt für (fast) alle I2C, zeig mir deine Wahl und ich schau mal

    Nein, leider keine drei "Bits" - wirklich nur drei Zustände :)

    Es geht um folgende zwei Boards:

    https://www.adafruit.com/products/439 (TSL2561)
    http://www.adafruit.com/products/466 (VCNL4000)

    Das TSL2561 Board hat einen ADDR Pin, der entweder offen gelassen werden kann, oder gegen Masse bzw. 3,3V verbunden werden kann. Also maximal drei mögliche Zustände.

    Und das VCNL4000 Board hat überhaupt keine Möglichkeit zur Wahl der Slave-Adresse. :(

    Tut mir leid, aber entweder ich verstehe nicht, worauf du hinaus willst oder ich konnte meine Frage bisher nicht verständlich genug formulieren.

    Mir ist bewusst, dass beim MCP23017 die Slave-Adresse geändert werden kann. Aber was dann? Ich möchte mehrere Helligkeitssensoren an den RPi bringen, von denen ich an einem I2C-Master nur drei betreiben kann, weil die Slave-Adresse des Sensors nur auf 0x29, 0x39 oder 0x49 gesetzt werden kann (per Lötbrücke). Und ich möchte mehrere Entfernungssensoren einbinden, deren Slave-Adresse fest auf 0x20 eingestellt ist und nicht änderbar ist.

    Ich brauche also vermutlich mehrere I2C-Master. Hilft mir der MCP23017 dabei weiter? Und wenn ja, wie?

    Bei meinen Recherchen ist der MCP23017 zwar desöfteren aufgetaucht, aber ich habe noch nicht verstanden, wie ich über diesen dann die weiteren I2C-Sensoren einbinden würde.

    Werden einfach die Datenleitungen der Sensoren an die GPIO-Pins des ICs geschaltet? Der MCP23017 ist doch "nur" ein Allzweck-GPIO Extender, dem man erst einmal beibringen müsste, I2C-Master für weitere Sensoren zu spielen, oder?

    Und falls ich die Sensoren dazu bekomme, mit dem MCP23017 zu kommunizieren, wie geht es dann weiter? Ich habe verstanden, dass der MCP23017 als einzelnes Device am I2C-Bus des RPi auftaucht, aber wie kommuniziere ich dann mit den eigentlichen Sensoren dahinter?

    Oder habe ich einfach nur noch nicht das grundlegende Prinzip dieses ICs verstanden? :)

    Ich möchte einen RPi mit verschiedenen Sensoren ausstatten, u.a. mit einigen Lichtsensoren. Ich habe bereits einen Adafruit TSL2561 per I2C angebunden. Das klappt mit einem Sensor auch sehr gut, aber aufgrund der maximal drei möglichen Slave-Adressen dieses Boards ist nach drei Sensoren Schluss.

    Einen Proximity-Sensor (VCNL4000) werde ich ebenfalls noch anschließen, aber da dieser überhaupt keine Möglichkeit zur Änderung der Slave-Adresse hat, wird er wohl ohne weitere Hardware auch allein bleiben.

    Ich habe bereits versucht, auszugooglen, was allgemein als best practice angesehen wird, eine größere Anzahl gleichartiger I2C-Sensoren mit dem RPi zu verbinden, aber scheinbar hat kaum jemand einen Bedarf daran oder ich suche falsch.

    Kann mich vielleicht jemand von euch auf die richtige Spur bringen? Gibt es vielleicht ein Stück Hardware o.ä., mit dem ich den RPi um weitere I2C-Ports erweitern kann? Oder etwas in der Art eines NAT, mit dem ich die Slave-Adresse eines I2C-Devices ändern kann?

    Oder sollte ich in meinem Fall eher nicht auf I2C setzen?

    Ich habe auch fünf 1Wire Temperatursensoren an dem RPi hängen. 1Wire ist mir in der Hinsicht sehr sympatisch, da es praktisch nicht zu Adresskonflikten kommen kann. Jedes Device hat eine einmalige ID und alle Sensoren müssen einfach nur über drei Leitungen elektrisch miteinander verbunden werden. Langsam aber ziemlich robust. Nachteil bei 1wire ist die begrenzte Auswahl an verschiedenen Sensoren bzw. vor allem deren softwareseitige Unterstützung seitens des RPi.

    Also: Habt ihr vielleicht Ideen, wie ich mehrere gleichartige I2C-Sensoren an den RPi bekomme?