Neue Bricklets

[batti]

Wir wollen neue Bricklets entwickeln. Dazu gehört ein Ersatz für das alte Analog In Bricklet (siehe hier). Da wir mit dem bisherigen Moisture Bricklet nicht zufrieden sind entwickeln wir dafür auch einen Ersatz. Wie genau dieser aussieht steht noch nicht fest. Wir testen in den nächsten Wochen verschiedene Möglichkeiten.

 

Beim durchgehen vom Wiki oder vom Forum habe ich mal folgende Wünsche zusammengetragen und möchte erklären warum wir diese zur Zeit nicht entwickeln:

 

Chibi Ersatz

Dieser steht auch auf unserer Liste. Allerdings ist die Entwicklung hiervon überhaupt nicht mit einem Bricklet zu vergleichen. Wir gehen davon aus, dass wir ein halbes Jahr benötigen um dieses zu entwickeln.

Da wir momentan hauptsächlich am RED Brick arbeiten ist dies keine Option.

 

Solar Stromversorgung

Oft wurden Stromversorgungen über Solar gewünscht. Vielleicht verstehen wir diese Wünsche falsch, aber zur Stromversorgung von Aufbauten mit WIFI o.ä. sind schon sehr große Solarzellen notwendig, wie sie z.B. im Caravan-Bereich eingesetzt werden (Kostenpunkt 200€). Ist das sinnvoll? Die Kosten für ein solches Produkt wären recht hoch, da es recht aufwendig ist. Demgegenüber erwarten wir wenig Bedarf für dieses Produkt.

 

GSM Master Extension

Durchaus sinnvoll aber auch einiges an Entwicklungsaufwand. Mit dem RED Brick gibt es eine Lösung für diese Probleme quasi frei Haus.

 

Schnittstellen Bricklet/Extension

Diese wurden öfters gewünscht. Als Beispiel ein Tinkerforge nach I2C Bricklet um "beliebige" andere I2C Geräte ansprechen zu können. Dies ist in der Theorie sehr toll, in der Praxis allerdings sehr schwer in unser System zu integrieren. Dazu kommt, dass man dafür auch einiges an technischen Know-How haben müsste. Den Gedanken, den wir mit Tinkerforge Verfolgen, Dinge einfach nutzbar zu machen ist zumindest mit so einem Produkt nicht umsetzbar.

 

Kamera Brick/Bricklet

Hier sehen wir auch das RED Brick als die vernünftigste Lösung. Zusammen mit einer Webcam und einer Bildverarbeitungsbibliothek hat man eine deutlich leistungsfähigere Plattform als irgendein Brick oder Bricklet mit einem 8 oder 32 Bit Mikrocontroller.

 

Ich würde mich freuen von euch Vorschläge zu bekommen. Bedenkt aber bitte, dass wir zur Zeit keine Produkte entwickeln werden, die großen Aufwand benötigen. Es geht vielmehr darum, die Chance zu nutzen, um zusammen mit dem neuen Analog In Bricklet und dem Moisture Bricklet vielleicht ein paar weitere Bricklets zu entwickeln.

 

Grüße,

 

Bastian

[Stefan]

Ich fände ein IR-Fernbedienungs-Bricklet würde gut in euer Sortiment passen.

[Loetkolben]

Hallo batti,

 

auch wenn es nicht so populaer ist: Ich faende das ic2 Bricklet immer noch toll.

 

Neben neuer Hardware    finde ich immer noch die Idee SEHR spannend die bishereigen Bricklets zu "erweitern", insbesondere das Remote Bricklet als Empfaender fuer die Outdoor Temperaturmodule.

Alternativ eine eigene Hardware um von aussen die Werte ins Haus zu bekommen, also kleine autonome Module.

 

Es dreht sich also viel hier um die Outdoor/Standalone Situtation, entweder per Solar, per Fremdfunkmodul oder Eigenfunkmodul.

 

 

Ansonsten koennte ich mir ein IR Fernbedienungsbricklet noch sehr gut vorstellen um damit z.B. bei der Hausautomation (mit der Fernsehfernbedienung) gleich das Licht schalten zu koennen.

 

 

Vielleicht ist die Ueberarbeitung von Modulen auch ein Thema? So koennte so manches Sensormodul ggf. mit einer LED als Feedbacksignal ausgestattet werden?

 

Vielleicht auch eine Idee, die Kaskadierbarkeit von Modulen? Z.B. fuer ein Daisychain beim neuen Moisturebricklet?

 

 

Soweit erstmal meine Ideen. 

 

 

Der Loetkolben

 

 

 

[jan]

Ich fände ein IR-Fernbedienungs-Bricklet würde gut in euer Sortiment passen.

Aber bitte Senden und Empfangen (auch zum Anlernen).

[Equinox]

Hallo,

 

für mich am wichtigsten ist im Moment eine Möglichkeit, die TF-Infrastruktur flexibler zu machen, was den Standort angeht. Sprich: Eine einfache, kostengünstige Möglichkeit, die Bricklets per Funk anzubinden.

(Siehe http://www.tinkerunity.org/forum/index.php/topic,2511.0.html)

Das geht zwar in Richtung Chibi-Extension, aber (wenn ich es richtig verstanden habe), ist mir das zu "oversized".

Ich stelle mir ein "Transceiver-Brick" vor (mit Batterie?), an das ich beliebige Bricklets anschließen kann. D.h., ich habe einen Stapel mit Master-Brick und Transceiver-Brick (und evtl. weitere Bricklets) und viele weitere Stapel, die nur aus Transceiver-Brick und Bricklets bestehen (also ohne Master) und per Funk mit dem Master-Stapel kommunizieren.

[derAngler]

Nabend,

 

also bei mir würde auch eine Art "Funksteuerung" für die Sensoren an erster Stelle stehen.

Irgendeine Lösung um die Sensoren überall einzel anbringen zu können und sie gleichzeitig mit Batterien laufen zu lassen.

 

Wäre schon schön wenn man an verschiedenen Punkten die Temperatur (oder was auch immer) messen und diese dann per Funk an einen Master senden könnte.

[raphael_vogel]

Ja wie schon in anderen Threads von mit erwähnt bin ich auch für eine batteriebetriebene Funk Lösung wie Equinox, Lötkolben, derAngler.....

 

Das ganze Thema IoT (internet of things) steht und fällt mit der Möglichkeit Sensoren batteriebetrieben per Funk an eine Basisstation anbinden zu können.

 

Viele Projekte scheitern doch daran, dass man keine Möglichkeit hat Kabel zu verlegen (Woman Acceptance Factor spielt hier auch eine Rolle).

 

 

 

[raphael_vogel]

Das mit dem Solarbricklet kommt sicher aus dem Wunsch heraus im Outdoorbereich kein Kabel verlegen zu müssen/können.

 

Es ist klar, dass Master Brick + Wifi Extension viel zu viel Strom ziehen.

Daher auch die stromsparende Funklösung, die viele hier wollen.

 

[thunderbird]

Moin moin,

ich würde mich sehr über Erweiterungen für die Wetterstation freuen.

 

Luft/ Gas Sensoren

General Air Quality - z.b. TGS 2600

NO2 Concentration - z.b. MICS-2710

CO Concentration - z.b. MICS-5525

 

Diese Sensoren würden noch gut zur Wetterstation passen.

 

VOC Sensor

CO2 Sensor

 

Ich denke das sind alles Sensoren, die nicht so einen hohen Aufwand bedeuten würden.

[remotecontrol]

Outdoor Sensoren über das RemoteBricklet abfragen steht bei mir auf der Wunschliste (oder einfach mehr mit dem RemoteBricklet steuern können als nur Steckdosen, gehört auch zum Kabel-Thema).

 

Richtung Stromversorgung wäre eine Art USV toll: z.B. gibt es für Odroid-Rechner eine zum aufstecken, das funktioniert auch gut. Wenn man einen SoC dauerhaft betreibt hat man recht schnell das Problem, dass der Strom übers Jahr öfter mal aussetzt und immer ist der Rechner abgestürzt. Das betrifft den RED später auch mal.

[luxor]

Ich fände ein IR-Fernbedienungs-Bricklet würde gut in euer Sortiment passen.

Aber bitte Senden und Empfangen (auch zum Anlernen).

 

das fände ich auch toll. Mit OpenHAB wäre das sicher cool!

[FlyingDoc]

Ein Differenzdrucksensor Bricklet.

 

Aso. Das bastle ich gerade selber. hab gestern meinen Sensor bekommen.

[batti]

Danke euch für die vielen Vorschläge. Ich verstehe den Wunsch nach einem Chibi Ersatz (Funklösung). Aber wie am Anfang geschrieben ist dies für diese Runde ersteinmal nicht möglich. Der Entwicklungsaufwand ist zu hoch (siehe oben). Es ging darum möglichst einfache Bricklets, die momentan noch fehlen zu finden.

 

Die Infrarot Bricklet Geschichte ist bisher daran gescheitert die Trägerfrequenz von z.B. 38kHz direkt mit dem Mikrocontroller zu generieren. Das ist mit unseren Firmwares aus zwei Gründen nicht möglich: 1) Man könnte so etwas mit Timer/Countern machen, diese stehen aber nicht für jeden Brickletanschluss zur Verfügung. 2) Man könnte dieses Signal per Software generieren. Da die Bricks aber ganz viele verschiedene Dinge machen müssen, hat jedes Bricklet nur begrenzt viel Zeit um verarbeitet zu werden. Eine Sequenz aus Daten die mit 38kHz modelliert wird kann somit nicht per Software generiert werden. Wir müssen also mal gucken ob wir nicht einen IC finden, der Daten z.B. per I2C entgegennimmt und diese mit 38kHz verschickt. Dann wäre dieses Bricklet machbar.

 

Das Remote Switch Bricklet so zu erweitern, dass man damit auch Dinge empfangen kann ist aus dem gleichen Grund bisher nicht möglich gewesen. Dafür benötigen wir eine Art Coprozessor.

 

Die Gassensoren benötigen meist 5V. Beim TGS 2600 sind z.B. minimal 4.8V zulässig laut Datenblatt. Das ist sehr knapp je nach verwendeter Stromversorgung (USB Hub etc.) und USB Kabel. Gucken wir uns mal an.

 

So koennte so manches Sensormodul ggf. mit einer LED als Feedbacksignal ausgestattet werden?

Ist zum Teil für eine neue Fassung von gewissen Produkten geplant. Wir führen Listen mit Verbesserungsideen. Es dauert aber immer bis alle Leiterplatten bestückt sind bevor wir das umsetzen.

 

Vielleicht auch eine Idee, die Kaskadierbarkeit von Modulen? Z.B. fuer ein Daisychain beim neuen Moisturebricklet?

Das musst du mir mal in einer ruhigen Minute erklären wie das gehen soll

 

 

 

[Equinox]

Hallo,

 

eine Idee für ein (einfaches?) Bricklet:

Wie wäre es mit einem Bricklet zum Messen von Füllständen von Flüssigkeiten (Wasser, Öl, etc.)? Ich stelle mir hier ein Bricklet vor, an das ein Messstab angeschlossen wird, der in eine Flüssigkeit getaucht werden kann. Das Bricklet gibt dann den Wert z.B. in Millimeter zurück, wie tief der Stab in der Flüssigkeit eingetaucht ist.

Dies könnte man z.B. dazu verwenden, die Regenmenge (für die Wetterstation) oder seinen Heizölverbrauch zu messen. Auch für Zisternen sehr sinnvoll.

Auf Parties könnte man den Stab in ein Bierfass stecken. Damit könnte man den Bierkonsum messen und bei niedrigem Füllstand rechtzeitig für Nachschub sorgen. Die Gäste wären dann auch ständig informiert, wieviel an flüssiger Nahrung noch da ist 

[Loetkolben]

Die Infrarot Bricklet Geschichte ist bisher daran gescheitert die Trägerfrequenz von z.B. 38kHz direkt mit dem Mikrocontroller zu generieren. Das ist mit unseren Firmwares aus zwei Gründen nicht möglich: 1) Man könnte so etwas mit Timer/Countern machen, diese stehen aber nicht für jeden Brickletanschluss zur Verfügung. 2) Man könnte dieses Signal per Software generieren. Da die Bricks aber ganz viele verschiedene Dinge machen müssen, hat jedes Bricklet nur begrenzt viel Zeit um verarbeitet zu werden. Eine Sequenz aus Daten die mit 38kHz modelliert wird kann somit nicht per Software generiert werden. Wir müssen also mal gucken ob wir nicht einen IC finden, der Daten z.B. per I2C entgegennimmt und diese mit 38kHz verschickt. Dann wäre dieses Bricklet machbar.

 

Irgendwie habe ich einen Denkfehler und wuerde mich freuen, wenn mir das jemand erklaeren kann. Jeder noch so kleine Prozessor kommt mit IR Signalen klar. Zum Teil am Parallelport eines DOS PC. Wo hakt es da beim Brick? Geben die Bausteine nicht schon ein demoduliertes Signal aus?

Muss man beim Senden die 38kHz selbst erzeugen oder kann man die auch per NE555 erzeugen lassen und nur die Bits vom µC rueberschieben?

 

Entweder ich bin auf dem Holzweg oder irgendwo gibt es einen Haken den ich nicht verstehe.

 

Vielleicht auch eine Idee, die Kaskadierbarkeit von Modulen? Z.B. fuer ein Daisychain beim neuen Moisturebricklet?

Das musst du mir mal in einer ruhigen Minute erklären wie das gehen soll

 

Zum Beispiel beim Tilt-Bricklet koennte man x-1 IOs auf einem 2. Stecker am Bricklet zu einem weiteren Tilt-Bricklet weitergeben. So koennte man bis 4 Bricklets hintereinanderschalten. Entweder durchs Platinenlayout oder vielleicht durch ein passendes Zwischenkabel wird dann der passende IO Port von jeweils naechsten Bricklet belegt. (Hardware Port Shifting)

 

Beim Moisturebricklet geht es ja nicht so einfach, weil nur ein AD Wandler vorhanden ist, oder? Hier koennte man mit Transistoren an den 3 anderen IO Ports aber auch bis zu 8 Zustaende auswaehlen und somit von den weiteren Moisture-Bricklets den Ausgang jeweils auf den einen AD Wandler multiplexen?! Schaltfrequenz vernachlaessigbar.

 

An dieser Stelle kommt fuer mich immer mehr die Frage auf, ob die Bricklets nicht einen Minimini Co-Prozessor bekommen sollten. Dann koennte man vieles leichter realisieren.

 

 

Bitte das Thema Funkbricklets nicht aus den Augen verlieren, nein ich/wir meinen nicht Chibi. 

 

 

Der Loetkolben

[luxor]

Ach hier ich hab da noch was.

Kein Bricklets sondern eher ein Adapter.

Es gibt ja das LED Strip Bricklet. Dieses kann ja nur Digitale Strips Steuern. Die Günstigen Analogen Strips sind leider nicht ansteuer bar.

Wie wäre eine kleine Platine auf der ein ws2801 sitzt und dazu drei große Mosfet für die RGB Kanäle.

So eine kleine Platine sollte kein großes dinge sein und so wären die Anlagen Strips wieder drin. Und durch das verbinden der Adapter Platinen können man auch 10 Analoge LED Strips steuern. Je nach dem wie viel man braucht.

 

So etwas in dieser Richtung:

http://longhornengineer.com/category/appnotes/ws2801/

 

 

 

[thunderbird]

Mir würde zur Wetterstation noch ein Regenmesser sowie Windmesser / Windrichtungssensor einfallen. Im Moment löse ich das über IO4 Bricklets und Analog In Bricklets. Der Umbau wäre also sehr einfach. Wenn man z.B. die Sensoren von Davis nimmt, sind also nur wenige Teile anzupassen.

[batti]

Muss man beim Senden die 38kHz selbst erzeugen oder kann man die auch per NE555 erzeugen lassen und nur die Bits vom µC rueberschieben?

Die Software jedes Bricklet wird mit einem Takt von 1kHz (Ticktask) aufgerufen. Pro Durchlauf hat jedes Bricklet dann 200µSek Zeit. In dieser Zeit wird zum Beispiel vom Temperature Bricklet der I2C Sensor ausgelesen. Wenn man sich die Protokolle ansieht (z.B. hier), dann sieht man, dass die zu sendenen Sequenzen schnell länger wie mehrere Millisekunden werden. Das heißt, dass diese niemals in dem 200µSek Zeitslot vom Brick gesendet werden können. Eine Aufteilung auf mehrere Zeitslots ist aber nicht möglich, da das Bricklet erst in einer Millisekunde wieder dran ist und dementsprechend eine Millisekunde nichts senden kann. So mal eben mit "rüberschieben" ist leider nicht... Ihr müsst bedenken dass verschiedenste Timings vom System eingehalten werden müssen und das geht halt nur wenn jede Komponente einen definierten Slot zur Verfügung hat.

 

Um so einen IR Sender zu realisieren benötigen wir also ein IC oder CoProzessor, der die Daten entgegennimmt und diese dann in der notwendigen Zeit sendet (Natürlich könnte der Mikroprozessor für sich alleine Betrachtet locker mal eben so eine Sequenz senden).

 

 

Zum Beispiel beim Tilt-Bricklet koennte man x-1 IOs auf einem 2. Stecker am Bricklet zu einem weiteren Tilt-Bricklet weitergeben.

Ich weiß gar nicht wo ich da anfangen soll. Irgendwie ist mir aber gerade danach das mal durchzugehen. Nimms mir bitte nicht übel:

Du kannst pro Bricklet Port immer nur ein EEPROM auslesen, da nur eins selektiert werden kann. D.h. du kannst nur das EEPROM des ersten Bricklets auslesen. Dies gilt auch für alle I2C ICs. Das heißt Temperature, Barometer etc. ließen sich nicht kaskadieren. Dinge die SPI sprechen, wie z.B. Remote Control Bricklet, sind als 1:1 Bus ausgeführt (nicht mehr Pins zur Verfügung) und lassen sich auch nicht selektieren, somit sind diese auch nicht kaskadierbar. Was übrig bleibt sind IO Bricklets die nicht alle 4 Pins ausnutzen. Pro Bricklet Port gibt es nur einen Pin der Spannungen messen kann, d.h. das zum Beispiel das Ambient Light Bricklet auch nicht kaskadierbar wäre. Damit dies ginge müsste jedes Ambient Light einen "Analog Switch" oder ähnliches drauf haben, der über die noch freien Pins selektiert wird um ein anderes Ambient Light die Kontrolle über den Analog Pin zu geben... Das Tilt Bricklet oder das Hall Effect Bricklet wären für diese Kaskadierung wohl die einfachsten Bricklets. Aber wie sollte das in der Praxis aussehen? Haben die dann 2 Bricklet Anschlüsse? An diese Anschlüsse dürfte ich dann nur Bricklets vom selben Typ anschließen und müsste dann noch vorher definieren das da zum Beispiel 3 Tilt Bricklets angeschlossen sind. Sorry, aber unser System ist so schon recht komplex, damit würde es imho eine Katastrophe. Abgesehen davon gibt es noch einige Probleme in der Softwareumsetzung, die ich jetzt nicht angehen wollte. Glaube mir, das ist nicht umsetzbar, wäre für Nutzer nur schwer nachvollziehbar und wäre imho auch nicht sinnvoll.

 

Wie wäre es mit einem Bricklet zum Messen von Füllständen von Flüssigkeiten (Wasser, Öl, etc.)?

Die Idee finde ich sehr gut. Es dürfte nur kein Bricklet sein das per eingetauchter Leiterplatte misst. Besser wäre da vll. eine Lösung per Differenzdrucksensor und getauchtem Schlauch. Werde das mal ausprobieren. Habt ihr andere Ideen?

 

Wie wäre eine kleine Platine auf der ein ws2801 sitzt und dazu drei große Mosfet für die RGB Kanäle.

Notiert

 

Mir würde zur Wetterstation noch ein Regenmesser sowie Windmesser / Windrichtungssensor einfallen.

Wäre sehr toll wenn wir so etwas hätten. Wir haben vor einiger Zeit uns nach so etwas umgesehen. Die Davis Dinger sind recht teuer (100$ für einen Regensensor). Kennt jemand kabelgebundene Alternativen?

[BorgelMorgel]

Ich fände eine USV auch eine feine Sache, vor allem in Hinblick auf das RED.

 

http://www.pimodules.com/index.html

 

Die bieten sowas für den Pi an und mit der haben wir gute Erfahrung gemacht. Bei der Größe hätte ich so an das LCD gedacht. Gerade bei Messstationen sind Stromausfälle sehr ärgerlich und führen immer zu Datenverlust. Der Akku mit 2600mAh ist ausreichend. Es soll ja kein Dauerbetrieb gewährleistet werden, nur eine kurzzeitige Überbrückung. Ein paar Einstellungen muss es auch bieten, also Grenzen festlegen und automatische Abschaltefunktion usw.

 

Ein weiterer Punkt ist die Verbesserung des Hall-Bricklets, sodass man damit höhere Drehzahlen messen kann und eine hohe Aufnahmegeschwindigkeit hat (ähnlich dem Industrial 20mA Bricklet).

 

Längere Kabel  wären auch gut.

 

PS: Ach ja, da ich ja aus dem Fahrzeugbereich komme, wäre ein CAN-Bricklet nach wie vor schön.

[Equinox]

Hallo,

 

 

Wie wäre es mit einem Bricklet zum Messen von Füllständen von Flüssigkeiten (Wasser, Öl, etc.)?

 

Die Idee finde ich sehr gut. Es dürfte nur kein Bricklet sein das per eingetauchter Leiterplatte misst. Besser wäre da vll. eine Lösung per Differenzdrucksensor und getauchtem Schlauch.

 

Stimmt. Ein flexibler "Messstab" ist besser. Eine starre Stange kann nicht überall eingesetzt werden.

[Nic]

Einen "Transceiver-Brick" haben wir eigentlich schon mit dem RemoteBricklet, wenn dieser vergrößert würde zwecks CoProzessor, wäre der Aufwand immer noch zu hoch ?

 

Wenn ein es dann so ein "Transceiver-Brick" gäbe, würde die Chibi Ext. erstmal obsolet, für mich und viele andere auch, ist der Wunsch beliebige Bricklet-Sensoren einfach kabellos im System zu verwenden, grösser.

Alternativ oder ergänzend dazu, bietet sich an, die alte Chibi-Extension in einer limitierten Neu-Auflage nochmals unverändert rauszubringen.

 

Was ist mit einem PowerBrick im Formfaktor Brick-Extension, ev. so eine Mischung aus LipoRider http://www.exp-tech.de/Shields/Seeedstudio-LiPo-Rider-USB-Charger-Power-Booster.html und integr. Akku ? Ev. so ausgelegt, dass mehrere PowerBrick stackbar sind um die Akku-Kapazität zu erhöhen ? Oder scheitert das an der Größe von LiPo Zellen ?

 

Ganz praktisch wären Gas Sensoren zur Messung von Wasserstoff (https://www.sparkfun.com/products/10916)/Methan (https://www.sparkfun.com/products/9404/CO2/Propan/Butan etc. Z.B. Wasserstoff Gehalt in Raumluft beim Ausgasen von Solarakkus.

 

Display-Bricklet

Der LCD 20x4 ist manchmal zu groß, der Seg.Display4x7 ist mir zu simpel, (keine Trennzeichen, kein °Grad), ein neues 16x2 wäre eine Ergänzung wie z.B. https://www.sparkfun.com/products/9395 oder ein überarbeitetes 7-Segm. wie z.B. https://www.sparkfun.com/products/11442.

Für den RED wäre ein adäquates Display (ohne Touch) eine prima Ergänzung, mir sind die HDMI-Display im Vergleich zum RED einfach zu teuer.

 

SchnittstellenBricklet

Nun, es würde auch erstmal nur eine Schnittstelle reichen, mir persönlich die RS-232 

Dazu kommt, dass man dafür auch einiges an technischen Know-How haben müsste. Den Gedanken, den wir mit Tinkerforge Verfolgen, Dinge einfach nutzbar zu machen

Es gibt aber genügend Beispiele im Sortiment, wo das zusammenstecken zwar einfach ist, aber die Erfassung und Auswertung bzw. sinnvolle Interpretation der Daten doch jede Menge knowhow erfordert. Letztendlich sind die Zielgruppen nicht nur der interessierte Laie sonder auch der PowerUser oder Bastler.

 

PS: Bitte denkt an das internationale Publikum, d.h. diese Umfrage auch im Engl-Forum stellen.

[thunderbird]

Hi batti,

 

ja ich gebe dir Recht, die Davis Sensoren sind recht teuer. Aber ich habe hier schon einige ausprobiert die alle nicht so zuverlässig und gut arbeiten.

 

Preise von vor ca. einem Jahr:

Anemometer Art.NR. DAV-6410 beträgt 105,04 €

Raincolletor Art.NR. DAV-7852M beträgt 63,03 €

[Bralph]

Mir würden noch ein kapazitiver Näherungssensor und ein Radioaktivitätsmessgerät (z.B. für Radon) einfallen. Auch ein Bluetooth bricklet speziell für iBeacon wäre interessant.

[luxor]

 

Wie wäre es mit einem Bricklet zum Messen von Füllständen von Flüssigkeiten (Wasser, Öl, etc.)?

Die Idee finde ich sehr gut. Es dürfte nur kein Bricklet sein das per eingetauchter Leiterplatte misst. Besser wäre da vll. eine Lösung per Differenzdrucksensor und getauchtem Schlauch. Werde das mal ausprobieren. Habt ihr andere Ideen?

 

 

 

Ohhh das fände ich auch gut! Noch besser als mein WS2801 Adapter

[Nic]

Einen 2Achsen Beschleunigungs- oder Lagesensor (ADXL345), z.B. für eine digitale Wasserwaage http://blog.simtronyx.de/digitale-wasserwaage-adxl345-tft-hy-1-8-spi-und-ein-arduino/