Equinox

Hallo Grobi, die Funksteckdosen, die man mit dem Remote-Bricklet schalten kann, sind im Prinzip nur "Funkempfänger ohne Rückkkanal". Man kann also den aktuellen Schaltzustand nicht abfragen und man kann sich auch nicht sicher sein, ob ein Schaltvorgang funktioniert hat. Um die Gefahr der Inkonsistenz zu minimieren, kannst du also Möglichst viele "Repeats" beim Schalten verwenden dafür sorgen, dass ausschließlich über dein Programm geschaltet wird (also verhindern, dass jemand den manuellen Ein-/Ausschaltknopf oder eine Fernbedienung der Dose benutzt) evtl. den aktuell gewünschten Schaltzustand periodisch schalten (wenn die Dose z.B. zwischen 10:00 Uhr und 10:30 eingeschaltet sein soll, dann schaltest du sie in dieser Zeit z.B. alle 2 Minuten ein, also um 10:00, 10:02, 10:04, usw. und davor und danach eben alle 2 Minuten aus.) Wenn das zu ungenau/umständlich ist, dann kannst du dir mit den TF-Bausteinen selbst so eine Dose "nachbauen" oder Funkdosen nehmen, die einen Smarthome-Funkstandard unterstützen (z.B. Z-Wave). Letzteres ist aber nicht mit TF kompatibel. Gruß Equinox

Hallo Tracker, prinzipiell ist das kein Problem. Allerdings musst du aufpassen, wenn du unterschiedliche Callbacks verwendest, da es nur eine Callback-Periode pro Callback gibt. Wenn also z.B. Prozess 1 eine Callback-Periode von 10 Sekunden setzt und Prozess 2 danach diese auf 1 Sekunde setzt, dann gilt auch für Prozess 1 die Callback-Periode von 1 Sekunde.

Hallo, ich finde den Vorschlag set_alarm(int8 month, int8 day, int8 hour, int8 minute, int8 second, int8 weekday, int32 interval) gut. Meiner Meinung nach deckt er alles ab, was hier gewünscht wurde. Gruß Equinox

Hallo, ich persönlich kann mit der Implementierung leben. Für mich geeigneter wäre allerdings ein periodischer Callback, z.B. alle 5 Sekunden (unabhängig von Tag/Uhrzeit). Also sowas wie setCallbackPeriod(<time in millis>) --> Man bekommt alle "<time in millis>" einen Aufruf.

Hallo, ehrlich gesagt war ich auch etwas verwundert über das Bricklet. Als ich "Real-Time Clock" gelesen habe, dachte ich an ein Bricklet, das die Uhrzeit über DCF77 (bzw. was es da sonst noch so gibt) holt/synchronisiert. Wenn ich das richtig verstanden habe, dann muss man die Uhrzeit selbst stellen und eine Kalibrierung vornehmen und selbst dann hat man im besten Fall "immerhin" eine Abweichung von 2,5 Sekunden pro Monat. Ich denke, wer wirklich eine genaue Uhrzeit für seine Anwendung braucht, dem ist das zu ungenau. Für einen Log reicht das aber völlig aus. Aber trotzdem meine Frage: Warum holt sich das Bricklet die Uhrzeit nicht über Funk? Wäre das soviel teurer geworden? Gruß Equinox

Hallo, irgendwelche Hinweise/Tipps? Gruß Equinox

Hallo, misst das Bricklet das gesamte Spektrum der UV-Strahlung, d.h. UV-A, UV-B und UV-C? ich nehme an, dass das Bricklet nicht wetterfest ist, oder? Da Glasscheiben einen großen Teil der UV-Strahlung filtern, macht eine Installation hinter Glas aber wenig Sinn. Habt ihr einen Tipp, wie man das Bricklet im Freien anbringen kann, so dass es die komplette UV-Strahlung misst, aber trotzdem vor Regen/Schnee geschützt ist? Gruß Equinox

Hallo, vor einiger Zeit habt ihr mal erwähnt, dass ihr eine Art "Gebrauchsanleitung" bzw. "Tipps und Tricks" für das "Dust Detector Bricklet" erstellen wollt. Gibt es die schon (und ich habe sie übersehen) oder seid ihr da noch dran? Ich meine mich zu erinnern, dass ihr z.B. erwähnt habt, dass das Bricklet in einem Luftstrom angebracht werden sollte. Gibt es noch weitere Dinge, die man bei dem Bricklet beachten sollte? Zum Anbringen im Luftstrom: Wie "stark" sollte dieser sein? Reicht ein bißchen Luftbewegung oder braucht man schon einen Lüfter/Ventilator? Ich hätte die Möglichkeit, das Bricklet hinter einen Lüfter (d.h. in den Ansaugbereich) zu platzieren. Wäre das gut? Wäre es vor dem Lüfter besser (also dort, wo er hinbläst)? Oder besser in die Nähe, also nicht direkt in den Luftstrom? Gruß Equinox

Hallo Westi, bei den Fernbedienungen/Steckdosen aus dem Baumarkt steht normalerweise eine Reichweite von 15m-30m. Ich gehe davon aus, dass das Remote Bricklet eine ähnliche Reichweite hat. 5m ist auf jeden Fall problemlos drin. Ich habe zwei Steckdosen, die beide mehr als 5m vom Bricklet entfernt sind (geschätzt 8m) und da funktioniert es meist problemlos. Hast du schon einmal versucht, die "Repeats" zu erhöhen? Ich kann im Moment nicht nachschauen, glaube aber, mit 7 zu arbeiten.

Hallo, Ich glaube nicht, dass dafür eine spezielle App notwendig ist, sofern die Nachricht im NDEF-Format auf dem NFC-Chip gespeichert ist (auch auf Android nicht). Allerdings passiert trotzdem nichts "automatisch". Android zeigt dir die Nachricht (d.h., die URL) an und dann kannst du "draufklicken". Gruß Equinox

Hallo, OK, verstehe. Bedeutet "neues" Protokoll bzw. "neuer Baukasten" dann, dass diese Bauteile nicht mehr kompatibel zu den alten sind, d.h., nicht mehr "zusammen" verwendet werden können oder heißt dies "nur", dass es neue Bauteile sind, die anders kommunzieren aber durchaus mit den alten Bauteilen Bricklets zusammen funktionieren? Idealerweise wäre Letzteres natürlich zu bevorzugen, aber ich könnte auch mit einem Bruch leben, also quasi eine "Low-Power"-Linie. Das mit dem Senden alle paar Sekunden ist auch so eine Sache. Für einige Sensoren (Temperatur, Luftfeuchtigkeit, usw.) ist das ausreichend, aber, wie hier schon erwähnt wurde, ist dies bei einem Bewegungsmelder eher suboptimal. Ich denke aber, 1000 Nachrichten pro Sekunde und Übertragungsraten im MBit-Bereich sind hier nicht notwendig (wobei es hier bestimmt Anwender gibt, die dies brauchen/möchten). Abschließend eine Frage: Glaubt ihr, dass es dafür (d.h., eine Möglichkeit, Sensoren mit geringem Stromverbrauch und Anbindung über Funk mit einigermaßen großer Reichweite(=min. ca. 3-5fache WLAN-Reichweite)) eine Lösung von euch in absehbarer Zukunft geben wird (d.h. in 6-12 Monaten)? Gruß Equinox

Hallo, Wenn ihr solche Bestellungen öfter habt, dann ist es natürlich sinnvoll, so ein Nugget anzubieten. Ein "neues" Baukastensystem muss nicht sein, es sei denn, die aktuellen Sensoren sind dafür völlig ungeeignet. Ansonsten würde ich sagen, "reichen" 2 neue Bauteile: [*]Eine Transceiver-Extension, die auf den Master, d.h. Stack, aufgesteckt wird und die Kommunikation mit den per Funk angebundenen Sensoren/Aktoren übernimmt. [*]Ein Transceiver-Modul (ich will es nicht Bricklet nennen), an das die Sensoren/Aktoren angeschlossen werden. Mit eigener Stromversorgung (über Batterie, die min. 1 Jahr hält) Vor kurzem habe ich mir einen Funk-Außensensor mit Temperatur und Luftfeuchtigkeit für meine Wetterstation gekauft. Der hat unter 20 € gekostet. Allerdings hat er auch nur eine geringe Reichweite. Mir ist klar, dass diese Preise mit TF nicht erreicht werden können. Für den Transceiver (also 1.) auf dem Stack sage ich mal aus dem Bauch heraus 40€. Für ein Transceiver-Modul sollten es meiner Meinung nach max. 15€ sein. Ich könnte mir aber vorstellen, das man an so ein Modul nicht nur ein, sondern auch 4 oder sogar 8 (Platz?) Bricklets anschließen kann. Dann darf es natürlich auch etwas teurer sein, sagen wir mal 25€. Gruß Equinox

Hallo Die Idee finde ich grundsätzlich nicht schlecht, aber ein Preis von 30€ - 40€ für das Nugget und dann noch ein Bricklet dazu, das wäre mir zu hoch. Wenn man nur die Luftfeuchtigkeit messen will, dann ist man da bei 47€ - 57€. Und man hat nur Strom für eine Woche. Aus dem Bauch heraus würde ich sagen, dass es dafür nicht viele Käufer gibt, aber ihr habt da vmtl. Zahlen, die anderes sagen, oder? Besser würde ich es aber finden, wenn das kein WiFi-Sensor, sondern ein Funk-Sensor wäre. Funk = Low-Cost, hohe Reichweite, geringer Stromverbrauch. Also wie nrg007 sagte: Ersetzen des Bricklet-Kabels durch Funk. Gruß Equinox

Hallo, Stimmt. Die Lösung mit einem Nugget ist natürlich flexibler. Ich würde dann aber darauf verzichten, auch einen "Master" auf das Nugget zu packen. Meiner Meinung nach reicht es, wenn das Nugget fähig ist, per Funk mit einem Master zu kommunizieren. Dadurch müsste es auch billiger werden, oder? Aus Programmiersicht wäre das dann auch transparent, d.h., gleicher Code, egal ob das Bricklet per Kabel oder per Nugget am Master hängt. Wenn "Master+WiFi=Nugget", dann wird die Programmierung ziemlich "unschön", wenn man einige Nuggets im Einsatz hat. Hmmm, habe ich das doch falsch verstanden? Das Nugget würde doch (bei eurer Lösung) nicht das Bricklet-Kabel ersetzen, oder? Das würde doch in die Richtung gehen, wie ich es mir auch vorgestellt habe, oder? Gruß Equinox

Hallo, Dieses neue Produkt ist eine Zusammenfassung mehrerer bestehender Produkte zu einem. Eine WIFI Bridge/Nugget ist eine Zusammenfassung von: - Master Brick - WIFI Extension in einer Platine, wobei der Master Brick Teil keine Stack-Funktion hat und nur einen Bricklet Port. Das Ziel des Ganzen ist es ein Bricklet möglichst einfach über WIFI erreichbar zu machen. Ich kann also nur ein Bricklet anschließen und das per Kabel? Hmm, da hält sich meine Begeisterung nun in Grenzen 30€ - 40€ Euro (plus Bricklet) sind mir zuviel dafür. Ich habe auf eine Lösung gehofft, bei der ich "nur" ein Bricklet/Nugget/Sensor irgendwo anbringen kann und dieses dann per Funk mit dem Master kommuniziert. Auf dem Master (Stack) kann ruhig eine Extension für den speziellen Funkstandard sein (Hauptsache, die Reichweite ist groß und das Nugget kann mit einer Batterie lange, d.h. min. 1 Jahr, arbeiten). D.h., das Nugget kommuniziert mit dem Master über die Extension. Um das Nugget über WLAN erreichbar zu machen, kann ja auf dem Master weiterhin die WIFI-Extension sitzen. Ich stelle mir also einen Stack mit Master + "Nugget-Extension" + "WIFI Extension" vor, wobei ein Nugget über die ""Nugget-Extension" mit dem Master kommuniziert. Das Nugget selbst ist sozusagen eine erweiterte Version eines Bricklets, enthält also einen Sensor (z.B. Humidity) + Kommunikationseinheit für Funk-Anbindung + Stromversorgung (mit Batterie). Die Nugget-Extension brauche ich also nur einmal auf dem Stack (kann dann auch 40 Euro kosten), und die Nuggets kann ich "weiträumig" verteilen. Der Preis für die Nuggets ist dann natürlich höher als für ein entsprechendes Bricklet. Gruß Equinox

Hallo, Zum Namen: Mein klarer Favorit ist "WIFI Nugget". Zur Idee: Ich bin mir nicht sicher, ob ich das richtig verstanden habe Was "enthält" das WiFi Nugget? Ist das die Funktionalität eines Bricklet (also z.B. des Humidity Bricklets), das aber nicht auf einem Stack angebracht wird, sondern per WiFi mit dem Stack/Master kommuniziert? Falls ja, dann finde ich die Idee grundsätzlich super, da sowas eindeutig noch fehlt. Ich würde gerne einige meiner Sensoren deutlich weiter als die 2m Kabel vom Stack entfernt anbringen. Und da sehe ich auch das Problem: Ich denke, dass WiFi eine zu kleine Reichweite hat. Auch der Stromverbrauch scheint mir zu hoch zu sein. Es gibt mittlerweile doch einige Funkstandards, die sehr große Reichweiten haben und das bei einem geringen Stromverbrauch (z.B. http://www.semtech.com/wireless-rf/lora.html). Gruß Equinox

Hallo TR61, hast du einfach deinen Text direkt auf den NFC-Chip geschrieben? Auslesen sollte trotzdem gehen, allerdings natürlich nicht als NDEF-Nachricht, wie du auch schon richtig festgestellt hast. Hast du dieses https://github.com/Tinkerforge/nfc-rfid-bricklet/blob/master/software/examples/python/example_write_ndef_message.py Beispiel probiert bzw. angeschaut? Hier steht auch ein Link auf die Spezifikation für NDEF: https://github.com/Tinkerforge/nfc-rfid-bricklet/raw/master/datasheets/specification_ndef.pdf. Ich finde die Spezifikation nicht einfach zu durchschauen, aber im Moment ist es der einzige Hinweis, den ich dir geben kann Hast du konkrete Fragen?

Hi mikew, if you connect your stack via USB, it won't connect via WiFi. So, you must do the setup of your WiFi extension while the stack is connected via USB. After the setup, you must disconnect USB. Then you should be able to connect via WiFi. Does it work then? If no, do you use a hidden SSID? If yes, try to connect with a visible (broadcasted) SSID.

Hallo, das ist (leider) wohl die normale Vorgehensweise. So machen es anscheinend alle Geräte, also z.B. auch Smartphones usw. @Tinkerforge: Gibt es keine Möglichkeit, die Firmware des NFC-Bricklets so zu ändern, dass das Bricklet selbst polled (einstellbar, wie oft) und wenn dann ein NFC-Chip in der Nähe ist, ein Event ausgelöst wird? Das wäre echt super!

Hallo FabianB, also ich hätte es auch so gemacht Alternative wäre eine eigene Klasse, die von "StateChangedListener" erbt, diese dann instaziieren und einer Variablen zuweisen. Wenn du in "stateChanged" aber nicht viel machst, halte ich das für Overkill.

Hallo Browserlauser, du brauchst auf jeden Fall noch einen Masterbrick. An diesen musst du die Bricklets anschließen. Meines Wissens versorgt der RED-Brick die anderen Bausteine. Bei diesem Aufbau solltest du also keine weitere Stromversorgung benötigen. Ich vermute auch, dass du bei einem Raspberry keine weitere Stromversorgung benötigst. Aber so ein Netzteil kostet ja nicht allzu viel und vielleicht hast du ja noch eins von einem Handy übrig.

Hallo BrowserLauser, sowas geht mit den Tinkerforge-Bauteilen auf jeden Fall. Du brauchst dafür: [*]einen Masterbrick [*]Dual Relay Bricklet [*]Bricklet für die Bewegungserkennung Außerdem benötigst du einen "Steuercomputer", auf dem die Steuerung/Auswertung der Bricklets läuft. Du kannst dafür den Tinkerforge RED-Brick nehmen oder einen Raspberry Pi (oder einen Rechner, den du sowieso schon hast). Falls der Rechner nicht im Schaufenster stehen soll, brauchst du noch eine Netzwerkverbindung zum Master-Brick. Dies kannst du entweder mit der Ethernet Master Extension oder mit der WIFI Master Extension machen. Zur Bewegungserkennung: Ich glaube nicht, dass das Distance US Bricklet durch die Scheibe erkennen kann, dass jemand vor dem Fenster steht. Ich vermute stark, dass es dir immer die Entfernung zur Scheibe anzeigen wird, da diese den Schall reflektiert (korrigiert mich, wenn ich hier falsch liege). Als Alternative dafür könntest du das Motion Detector Bricklet verwenden. Aber auch hier muss dieses vor(!) der Scheibe montiert sein, da es keine Bewegung durch Glasscheiben erkennen kann (wie alle PIR Bewegungsmelder).

Hallo brauki60, ja, funktioniert prima! Ich messe mit dem Voltage/Current-Bricklet die Spannung an den Akkus (bzw. Solarpanel). Wenn die zu niedrig ist, dann schalte ich mit dem Dual-Relay-Bricklet auf die andere Spannungsquelle um (also Netzbetrieb). Da sich die Spannung (d.h. die Leerlaufspannung) der Akkus relativ schnell erholt, warte ich mit dem erneuten Umschalten auf Akkubetrieb mindestens 5 Minuten, auch wenn in der Zeit die Spannung der Akkus hoch genug ist. Dadurch verhindere ich, dass ständig hin- und hergeschalten wird. Wenn nach 5 Minuten die Spannung der Akkus wieder/noch passt, schalte ich wieder auf Akkubetrieb um. Eine längere Zeitspanne ist aber vmtl. keine schlechte Idee.

Hallo, ich habe ein Sony Xperia Z Ultra. Dein Smartphone erkennt also, dass ein NFC-Chip in der Nähe ist und versucht diesen auszulesen, kann ihn auch lesen, aber erkennt nicht, dass es eine NDEF-Nachricht ist? Hast du evtl. ein anderes Smartphone zur Hand?

Hallo ojax, die erzeugte Nachricht von Dir scheint korrekt zu sein. Ich habe gerade einen Chip mit der URI "tinkerforge.com" beschrieben, und zwar mit folgenden Daten: Page 4: 03 14 D1 01 Page 5: 10 55 01 74 Page 6: 69 6E 6B 65 Page 7: 72 66 6F 72 Page 8: 67 65 2E 63 Page 9: 6F 6D FE 00 Mein Smartphone konnte die URL auch öffnen, d.h., hat die Nachricht erkannt. Auch meine Apps auf dem Smartphone haben die Nachricht als korrekte NDEF-Message erkannt. Hast du mal versucht, den Chip an dein Smartphone zu halten ohne dass die App "Tag Writer" läuft, d.h., einfach die "eingebaute" NFC-Funktionalität des Smartphones benutzt? Sieht so aus, als ob die App "Tag Writer" ein Problem hat.