Jump to content

Gruenauge

Members
  • Gesamte Inhalte

    17
  • Benutzer seit

  • Letzter Besuch

Gruenauge's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Hi, ist eigentlich im Prinzip eh "besser" (bzw. sagen wir mal "eleganter", weil "besser" ist auch relativ ....) das so zu machen, dann hat man auch kein Problem, wenn man ein Bricklet auswechselt oder ggf. Bricklets nur zeitweise oder optional angeschlossen sind. Ok, es ist natürlich etwas aufwändiger. Und man hat natürlich ein kleines Problem, wenn man mehrere gleiche Sensoren (z.B. Temperatur) hat, aber die ihren Orten zuordnen muss, um die entsprechende Funktionalität sinnvoll verwenden zu können (da müsste man dann halt auch noch ein wenig tun). Aber man kann zum testen auf Vorhandensein natürlich auch einen Wert des Bricklets abfragen, und wenn man dann eine Exception bekommt, dann wird es vermutlich nicht vorhanden sein. Elegant geht zwar anders, aber kommt halt drauf an, was man für Erwartungen etc an die Sache setzt bzw. wie weit die eigenen Programmierfähigkeiten (oder der Wille dazu) genau gehen Gruß, Holger
  2. Hi, das passiert wohl durchaus, das sich bei so einem Produkt mal der Chipsatz intern ändert, ohne das man das großartig sehen kann (zumindest nicht als normaler Käufer). Klar, Windows-Treiber ist dabei, aber das hilft einem unter Linux nicht so wirklich. Möglicherweise würde der Linux-Treiber sogar leidlich funktionieren, fühlt sich aber nicht angesprochen, weil die ID des Gerätes nicht mehr stimmt. Holger
  3. Hi, das hört sich für mich dann aber so an, als ob man das dann nicht mehr kombinieren könnte (also die Bricklets, beim Prototypen kann man ja einfach irgendein Bricklet rantun - ggf. muss man auch Programmierung für diese Neu-Sensoren explizit anpassen?), was natürlich irgendwie schade wäre. Wenn man diese WIFI-Bridge mit mehr als einem Bricklet-Port vesehen könnte, wären ja ggf. schon einige Bedenken weg (weil man halt mehr als 1 anschliessen iwill). Deine o.g. Powersave-Magie scheint ja nicht viel zu bringen, wie du sagst, und wenn ihr fertige "Sensorpakete" (im Gehäuse) verkaufen wollt, geht das ja im Prinzip auch mit einer Bridge, wo (z.B.) drei Anschlüsse brach liegen - d.h. man kann z.B. 4 anschliessen, muss aber das Gehäuse halt selbst zusammenbasteln. Und wer das nicht will, kauft ein fertiges Paket bei euch (mit Brigde und einem Bricklet halt). Diese API-Idee mit der Tiefschlafphase würde dann vielleicht auch einiges bringen - klar, nicht bei jedem Bricklet. Beim Temperatursensor kann ich auch 5 Minuten Pause machen, beim Bewegungsmelder ist das sicher kontraproduktiv Aber dann muss man den Tiefschlaf ja nicht nutzen. Gruß, Holger
  4. Hi, nun ja, da sind halt RBG-LEDs drin verbaut. Da muss man sich sein Weiß halt zusammen mischen (was ja keine wirkliche Herausforderung ist, außer man möchte sich noch seine Wohlfühl-Farbtemperatur zusammenbasteln ) Klar, wenn man ganz nah heran geht, sieht man zwangsweise die roten, grünen und blauen Pünktchen (es sind halt keine weißen LEDs), aber weiter weg mischt sich das schon. Holger
  5. Hallo Borg, danke für die Info hallo Markus, ich habe davon auch noch eines da, welches ich verwursten kann. Das reicht also erstmal. Ich hatte halt nur, weil ich dabei ggf. noch etwas anders gebrauchen könnte, im Shop schonmal nach Ersatz geschaut (Porto reicht ja einmal) und da ist mir das dann aufgefallen. Aber danke für das Angebot Gruß, Holger
  6. Hi, früher gab es im Shop für das Multi-Touch-bricklet eine Art Zahlenblock. Der Link https://www.tinkerforge.com/de/shop/key-pad-3x4.html geht aber inzwischen ins Leere (und taucht auch in der Shopübersicht nicht auf). Gibt es das tatsächlich nicht mehr, oder hat der Shop das nur "verschluckt"? Gruß, Holger
  7. also, wenn ich das nicht falsch verstanden habe, dann ist es in beiden Fällen folgendes Szenario: a) Stapel mit Step-Down-PS, Master Brick und allerlei Kram (bekommt Strom vom Step-Down natürlich) b) Raspberry, der den Strom über den 5V-Ausgang des Step-Down-PS bekommt c) USB-Kabel, welches dann vom Raspberry zum Stapel geht (zur Steuerung halt) Also im Grunde läuft immer alles, nur scheint es (nach den Texten oben von Ulrich) ein Problem zu geben, das in der ganzen Hochlaufprozedur der Master nicht merkt, das der Raspberry da am Start ist. Ichmuss zugeben, das ich auch nicht weiß, ab wann der Raspberry da Power auf die USB-Ports gibt (also ob die Power quasi kommt, wenn der Raspberry mit Strom versorgt wird, oder ob die erst durch Kerneltreiber (oder Raspberry-Firmware oder was weiß ich) aktiviert werden müssen. Bei meinem oben beschriebenen Gerät habe ich aktuell keine Probleme, aber die Firmware von dem Master Brick ist auch etwas älter, da war die Hotplug-Erkennung auf jeden Fall drin. Ich will aber natürlich nicht probieren, ob ich Probleme kriegen würde, wenn ich da die aktuellste Firmware auf die Master Bricks drauf tue Ich hoffe mal, ich habe Ulrichs Text da nicht missverstanden, ansonsten ziehe ich alles zurück und gehe schämend in meine Ecke Gruß, Holger
  8. finde ich auch etwas schade, so ein Szenario (Stapel mit Step-Down unten und Raspberry, der dann gleich den Saft vom Step-Down mitbekommt) ist ja nicht völlig exotisch (habe ich bei einem Konstrukt hier auch ) Wäre es denn nicht vielleicht eine Möglichkeit, die USB-Hotplug-Erkennung zeitlich gesteuert abzuschalten? Also sagen wir 30 Sekunden oder so nach dem rest des Master Brick laufen zu lassen (so lange, bis der Raspberry bzw. das Linux da drauf sich soweit gestartet hat, so dass die USB-Verbindung soweit erkannt ist, das das Ganze funktioniert) und dann erst (dann bis zum reset) zu deaktivieren? Weil ich meine mich doch so dumpf dran zu erinnern, das dieser Effekt mit der falschen Erkennung erst so im Laufe der Zeit auftaucht. Oder notfalls eine Version der Firmware für den Master Brick zusätzlich zu veröffentlichen, das die Hotplug-Erkennung mit drin ist (denn so häufig kannn das Problem auch nicht sein, ich habe bei meinem Zeug hier - mit soweit älterer Firmware, das die Erkennung da auf jeden Fall noch drinsein muss) bislang nie Probleme) Gruß, Holger
  9. Hi, da unter Linux, habe ich die Karte "standesgemäß" mit dd beschrieben. Mein Vorrat an Micro-SD-Karten ist etwas beschränkt (SD-Karten fliegen hier ohne ende herum, aber Micro ...), aber ich habe noch eine aufgetan und die beschrieben. Der Einschub am Brick ist mit dieser Karte zumindest ähnlich empfindlich, ich musste da auch ein paar Mal die Karte einschieben, damit das Gerät bootet. Den Effekt mit dem plötzlich auftretenden "read-only"-Filesystem habe ich bislang nicht bemerkt, aber das muss ich natürlich noch etwas beobachten. Etwas empfindlich scheint der SD-Slot ja zu sein. Ich muss das also noch beobachten und ggf. nochmal die andere Karte versuchen. Da das Beschreiben unter Linux immer ohne Fehler durchgelaufen ist, kann ich eigentlich nur schwer glauben, das die Karte einen Schuss hat, aber man hat ja schon Pferde kotzen sehen Erstaunlicherweise habe ich mit dem WLAN immer noch Probleme, aber das kann ja eigentlich nicht an der SD-Karte liegen. Ich bin zur Zeit wieder auf dem Image 1.2, wo ich zuvor mit dem Edimax problemlos an meiner Fritz-Box angedockt bin, IP-Adresse per DHCP erhalten. Aber nun klappt das mit dem DHCP nicht mehr, was ich jetzt sehr komisch finde. Es kommen immer folgende Einträge: Dec 29 17:00:59 red-brick dhcpcd[3418]: wlan0: broadcasting for a lease Dec 29 17:00:59 red-brick dhcpcd[3418]: wlan0: offered 192.168.55.138 from 192.168.55.1 Dec 29 17:00:59 red-brick dhcpcd[3418]: wlan0: received NAK: (null) Konfiguriere ich die vorgesehene IP-Adresse (das ist ja auch die, die oben steht) statisch, dann klappt es. Da würde ich mir ja normalerweise keinen Kopf machen, wenn das nicht vorher ganz normal funktioniert hätte. Gruß, Holger
  10. Hi, ich habe irgendwie den Verdacht, das mein RED-Brick ein Problem mit dem SD-Karten-Slot hat. Kurz das Szenario: SD-Karte mit Image 1.2, läuft soweit, auch mit WLAN (über einen EDIMAX EW-7811UN USB Adapter) Dann wollte ich 1.3 draufmachen. Also SD-Karte in einem Linux-Laptop beschrieben (wie das 1.2 auch), wieder in den RED-Brick, und ... nix Die LEDs gehen kurz alle an, dann geht rot und gelb aus, und das bleibt dann auch so. Gut, zuerst gedacht, Fehler im Image oder Fehler beim Schreiben. Altes Image drauf gemacht, bootet aber auch nicht. Wenn die SD-Karte nicht im Slot steckt, bleiben beim Anstöpseln alle LEDs an (klar, ist ja auch Murks). Somit scheint der Brick die SD-Karte zu erkennen. Aber er bootet nicht davon. Die Karte wird beim Einstecken in den Laptop aber immer erkannt und im "Explorer" (hier das Ding von Ubuntu) das auf der Karte befindliche Filesytem mit dem ganzen Kram (/bin, /etc etc pp) angezeigt. Im Laufe der Zeit hatte ich dann plötzlich den Effekt, das nach einigen Ein- und Ausstecken der Karte der Brick plötzlich (mit Image 1.2) gebootet hat .... Nun ja, man kann alles essen, muss aber nicht alles wissen ... Also wieder 1.3 drauf gemacht, und bootet wieder nicht..... Aber diesmal habe ich dann direkt die Karte einige Male hin- und hergesteckt, bis der Brick gebootet hat. Dann dachte ich "ok, vielleicht doch alles gut", obwohl dieses Verhalten natürlich etwas unstabil ist .... War aber dann doch nicht alles gut, weil ich das Ding nicht ans WLAN bekommen habe (was vorher ja ging). Im Logfile (/var/log/message) stand was davon, das er eine Adresse über DHCP bekommen hätte (in der Fritz-Box konnte man auch sehen, das der WLAN-Adapter sich angemeldet hat), hat dann aber ein NAK rausgehauen und das ganze wieder versucht, was mich etwas verwirrt hat. Im weiteren Verlaufe hatte ich im Filesystem etwas geschaut und wie gehabt die unter Linux (bzw. bash) übliche Filenamenexpansion mit TAB verwendet, und dabei hat die bash dann plötzlich die Meldung "-bash: cannot create temp file for here-document: Read-only file system" rausgebracht (urgs). Auch der brickv hat sich zwischenzeitlich auf der Network-Seite beschwert, das er die Konfigurationsdateien für das Netzwerk ("error reading wired settings file" und dann nochmal mit wireless) nicht (mehr) lesen kann. Es macht also den Anschein, als ob der Brick Probleme mit der Karte hat, wohl irgendwelche Kontaktprobleme (booten erst nach mehrfachem Einschieben, plötzlich ein angebliches read-only-filesystem (was vielleicht auch die Probleme mit dem WLAN erklärt, weil er vielleicht irgendwelche Einträge nicht machen kann). Da ich die SD-Karte (das ist die aus eurem Shop) unter Linux mehrfach problemlos beschrieben habe, tendiere ich ja dazu, das irgendwie der SD-Slot des Brick einen Hau hat :'( (Ich möchte hierbei auch erwähnen, das ich das fragile Konstrukt des RED-Brick auch als solches behandel und nicht die SD-Karte mit dem Hammer reinprügel, zumal Mikro-SD-Slots ja meist so fein sind) Irgendwelche Verhaltensmaßregeln? (schnüff) Gruß Holger
  11. Hi, ne, ich habe die Kalibrierung nicht gespeichert, da ja in der Doku steht, das man die auf die dort beschrieben Weise wiederherstellen kann (sofern man das Ding nicht selbst kalibriert hat). Ich werde nochmal die UID prüfen (allerdings wird sich der brickviewer wohl nicht vertun können, wenn man den "Werkskalibrierknopf" drückt, aber ich schau dennoch nochmal nach), und ggf. dann nächstes Jahr (das aktuelle Jahr ist ja nunmal irgendwie vorbei) das ggf. in Angriff nehmen. Danke für die schnelle Antwort, und einen guten Rutsch. Holger
  12. Hi, wegen des RED-Bricks hatte ich auf meinem (Spiel)IMU-Brick die Firmware auf 2.3.0 upgedated. Die Kalibrierung hatte ich nicht gespeichert, weil ich keine eigene gemacht hatte. Nach dem Flashen wollte ich über den brickv die Werkskalibrierung wieder einspielen, es kommt aber nur die Meldung "No factory calibration available". Auch wenn ich entsprechend der Doku zu "http://download.tinkerforge.com/imu_calibration/6xgvTG.txt" gehe, gibts da nur einen 404-Fehler. Kopfkratz ..... sollte das so nicht gehen? Oder gibts das nicht mehr? Oder oder? Gruß, Holger
  13. Hi, ich hatte heute kurzzeitig Probleme mit USB-Disconnects. Kurz mal zum Aufbau des Gerätes: Basiert auf der Wetterstation. Ergänzt um einige Bricklets (damit natürlich auch um einen weiteren Master Brick - beide Firmware Version 2.1.2). Im Gehäuse der Wetterstation ist dann noch ein Raspberry verbaut, an den der Master abgeschlossen ist. Stromversorgung läuft über einen Step Down Power Supply. Das Gerät ist eine Kreuzung aus eben der Wetterstation und einem MP3-Spieler. Auf dem Raspberry läuft ein Java-Steuerprogramm. Das Konstrukt läuft so schon einige Monate (natürlich nicht durchgehend). Heute hatte ich plötzlich (keine Änderungen an Hardware etc) USB-Disconnects. Es liefen dann auch die blauen LEDs der Master Bricks durch, als die Verbindung wieder gefunden wurde. Das hielt dann einige Sekudnen bis Minuten, dann ging das Spielchen wieder von vorne los. Der Raspberry selbst ist normal weitergelaufen. Im USB-Port des Raspi steckt auch noch ein Wlan-Dongle, über den ich eingeloggt war, um das Logfile anzuschauen. D.h. also, de USB-Hardware auf dem Raspberry hatte vermutlich kein Problem. Kurzer Ausschnitt aus dem Log: Jul 20 14:24:36 mp3station kernel: [ 295.035033] usb 1-1.3: Product: Master Brick Jul 20 14:24:36 mp3station kernel: [ 295.035047] usb 1-1.3: Manufacturer: Tinkerforge GmbH Jul 20 14:24:36 mp3station kernel: [ 295.035060] usb 1-1.3: SerialNumber: 68yZNR Jul 20 14:24:36 mp3station kernel: [ 295.152509] usb 1-1.3: reset full-speed USB device number 7 using dwc_otg Jul 20 14:24:46 mp3station kernel: [ 305.190867] usb 1-1.3: USB disconnect, device number 7 Jul 20 14:24:55 mp3station kernel: [ 313.872562] usb 1-1.3: new full-speed USB device number 8 using dwc_otg Jul 20 14:24:55 mp3station kernel: [ 313.975308] usb 1-1.3: New USB device found, idVendor=16d0, idProduct=063d Jul 20 14:24:55 mp3station kernel: [ 313.975338] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jul 20 14:24:55 mp3station kernel: [ 313.975355] usb 1-1.3: Product: Master Brick Jul 20 14:24:55 mp3station kernel: [ 313.975368] usb 1-1.3: Manufacturer: Tinkerforge GmbH Jul 20 14:24:55 mp3station kernel: [ 313.975381] usb 1-1.3: SerialNumber: 68yZNR Jul 20 14:24:55 mp3station kernel: [ 314.092458] usb 1-1.3: reset full-speed USB device number 8 using dwc_otg Heute ist es halt ziemlich war. Die Raumtemperatur betrug zu dem Zeitpunkt ungefähr 30-31 Grad. Nach einigen Versuchen (reboots etc) habe ich das Gerät dann in einen Raum gebracht, wo es einige Grad kühler war (25-27 oder so, die diversen Thermometer sind ja auch gerne mal Schätzeisen). Dort läuft das Gerät jetzt fehlerfrei, es gibt keine USB Disconnects und es spielt somit friedlich vor sich hin. (seit 1 oder 2 Stunden, kein Beweis, aber ein gutes Indiz ;-)) Da es im Gehäuse der Wetterstation, auch wenn die nicht komplett geschlossen ist, aber wegen der Enge sich doch etwas aufheizt, wäre es natürlich denkbar, das das ganze ein Wärmeproblem ist/war. Hat da jemand diesbezüglich vielleicht Erfahrung mit, bzw. könnte sich vorstellen, das dies in diesem Zusammenhang ein Problem sein könnte? (Das so nur anhand dieser Angaben keiner den exakten Grund raushauen kann, ist mir schon klar ;-)) Wie sind eigentlich z.B. die Grenzen für die Umgebungsbedingungen der Master Bricks? So auf die Schnelle habe ich da keine Angaben gefunden, was z.B. die Betriebstemperatur angeht. Der Raspi soll angeblich bis irgendwas um 70 Grad laufen, damit sollte er dann noch Luft haben. Wenn jemand da ein paar Gedanken oder Anmerkungen zu hat, immer her damit. Gruß, Holger
  14. Hi, du kannst ein USB-Kabel opfern. Ich habe beim Blinkenlight-Kit auch zuerst mit dem Wifi-Aufsatz experimentiert. Ich habe ein Mini-USB-Kabel abgeschnitten, die beiden Stromleitungen (da bitte selbst im Internet, z.B. Wikipedia, nach der Belegung gucken) genommen und an die entsprechenden Wago-Klemmen (hiessen die jetzt so?) angeschlossen (da ist ja noch etwas frei). Dann daran den Brick angeschlossen und gut. Inzwischen habe ich da einen Raspberry dran. Der bekommt seinen Strom genauso vom Netzeil (jetzt natürlich über einen Mikro-USB-Stecker), und der Brick (dann natürlich ohne die Wifi-Extension) hängt am USB-Port des Raspberry. Das es über Wifi ruckelt, liegt vermutlich daran, das die Daten nicht so schnell übertragen werden, wie es sein sollte (Störungen, schlecht gewählter Kanal etc). Gerade bei diesem LED-Feld fällt das dann natürlich auf. Deshalb habe ich ja jetzt einen Raspberry dran. Grüße Holger
×
×
  • Neu erstellen...