derAngler

Danke, das hilft mir schon einmal weiter. Wie würde das mit dem Widerstand aussehen, will sagen wie errechne ich den?

Nabend, ich wollte fragen welches Bricklet ich nehmen muss um die Zustands LED's eines Mainboards auszulesen? Also zum einen die Power-LED und zum anderen die HDD-LED. Mein Plan war es die LED's direkt am Mainboard an den Steckerleisten abzugreifen. Ich denke ich brauche dazu wahrscheinlich das Digital-In-Bricklet oder doch das IO-4-Bricklet? Um sicher zu gehen wollte ich hier aber nochmal nachfragen.

Hallo, es gab ja schonmal das Thema den BrickD auf Android zu portieren. Was mich wundert das bisher keiner auf den Gedanken gekommen ist den BrickViewer zu portieren? Das würde jedenfalls mein Leben wesentlich leichter machen. Z.Bsp. könnte ich das Tablet mit ins Bad nehmen und dann testen wie und wo der Bewegungsmelder anschlägt, oder ich könnte den Distanzsenser einbauen und dann vor Ort mit einem Tablet "live" testen, und so weiter ... Meiner Meinung nach gibt es sehr viele sinnvolle Möglichkeiten eines "BrickViewer for Android" Technisch gesehen sollten auch keine großen Probleme anstehen, ist im Prinzip nichts anders als unter Linux. Und der fehlende USB-Stack ist auch kein Akt, dann gibt es eben keine Möglichkeit sich zu einem localhost zu verbinden, sondern ausschließlich zu Netzwerkadressen. Ist wirklich nicht weiter schlimm, localhost braucht man auf Android nicht um irgendwo im Haushalt die Sensoren zu überprüfen. Also was denkt Ihr, wäre so etwas möglich?

Hallo, ich habe gerade ein Gehäuse für das Motion-Bricklet in Verbindung mit dem Ambient-Light-Bricklet entworfen und würde dieses nur gerne ausdrucken lassen. Da ich leider (noch) keinen eigenen 3D-Drucker habe, hatte ich die Hoffnung das sich vielleicht hier jemand findet der sich bereiterklärt mit das Gehäuse möglichst günstig auszudrucken. Die Außenmaße betragen ca. 69x54x25 mm und das Gehäuse sollte aus weißem Kunststoff/Plastik bestehen. Anbei Bilder und die entsprechenden STL-Dateien. TeilA.stl TeilB.stl

so, habe mir mal die Mühe gemacht, falls jemand Interesse an den Modellen hat. Bilder und 3D-Daten anbei als Anhang. Ein perfektes Ergebnis würde man bekommen wenn man die Module mal kurz auf einen 3D-Scanner legt, haben ja die passende Größe für sowas. Leider habe ich sowas nicht, deshalb sind die Modelle sehr einfach 3d_daten.rar tf.dwg

Hallo, ich versuche gerade ein Gehäuse für den 3D-Drucker zu entwerfen. Zur besseren visuellen Darstellung habe ich mir z.Bsp. ein 3D-Modell des Raspberry Pi runtergeladen und in die 3D-Software eingefügt. Das macht mir die Arbeit etwas leichter da ich direkt sehen kann wo ich z.Bsp. Löcher für die USB-Buchsen & Co. brauche. Da ich in dem gleichen Gehäuse auch Tinkerforge-Module einbauen will wäre es extrem hilfreich wenn von den diversen Bricks & Bricklets 3D-Modelle existieren würden. Was denkt Ihr? Wäre das viel Arbeit? Und bin ich der einzige der Interesse daran hätte?

Das stimmt so nicht. Mit NetIO braucht er keinen extra Rechner, lediglich den schon angesprochenen RaspberryPi - der sollte aber fast immer dazu gehören (kostet auch mit WLAN-Stick weniger als die Wifi-Extension). Also RaspberryPi+WLAN, MasterBrick und PTC-Bricklet - mehr brauchts nicht. Auf dem RasPi läuft ein kleines python-Server-Script. Darauf greift dann NetIO über die Android-App zu. Geht alles relativ problemlos, habe ich selbst vor ein paar Monaten noch so gemacht.

Also wer lesen kann ist klar im Vorteil. Ein Klick auf den Link mit dem Beispiel und ein wenig lesen, dann würdest du folgendes finden: Da steht genau wie man ein python-Programm startet.

Zu früh gefreut Heute morgen war die Pflanzenlampe wieder aus, was eine Enttäuschung. Verstehe das Ganze einfach nicht, das ausschalten abends klappt ohne Probleme, auch das Einschalten per UI funktioniert jedes mal ... nur das automatische Einschalten klappt nicht. Von 5 Tagen war das Licht nur an einem morgen an - ich verstehe es nicht. An openhab und den Astro-Binding kann es laut openhab.log nicht liegen, dort wird der Switch korrekt ausgelöst. Bin so langsam am verzweifeln ... @Theo: Indirekt ja, habe meinen Stack mit einem Raspberry Pi verbunden und dieser ist über WLAN am Netzwerk. Allerdings habe ich keine WLAN-Reconnects im Log gefunden, gehe also davon aus das der Pi im Netz bleibt und es somit nicht daran liegen kann. Eine Fernbedienung oder Handschalter nutze ich nicht, zum ein-/ausschalten nutze ich ausschließlich openHAB (bei beiden Lampen). Das der RemoteSwitch den Zustand nicht abfragt ist mir klar, deswegen schalte ich ja auch nur mit openHAB. @stefan Ja, 2 x Buttons sind natürlich auch eine Lösung, aber nicht im Sinne des Erfinders wie man so schön sagt. Gerade bei einer Lampe finde ich es schon besser, praktischer und nicht zuletzt schöner mit einem Schalter zu arbeiten anstatt mit 2 Knöpfen. @theo Die Binding werde ich am Wochenende mal testen.

Danke, habe die Steckdose jetzt so umgestellt das openHAB 5x sendet und siehe da, heute morgen war die Pflanze auch automatisch an. Ich werde das jetzt noch einmal die nächsten 2 Tage beobachten, aber ich glaube das Problem ist beseitigt.

Ich habe dann doch noch einen Fehler gefunden. Und zwar beim RemoteSwitch - Typ C. Hiermit schalte ich eine Pflanzenlampe bei Sonneaufgang ein und bei Sonnenuntergang wieder aus. Dafür nutze ich eine Schaltsteckdose die ich über Typ C ansprechen kann. Das ausschalten klappt per openHAB-Regel ohne Probleme, nur das einschalten klappt dann nicht mehr automatisch. Laut openHAB-log müsste sich die Lampe aber wieder eingeschaltet haben - hat sich aber leider nicht. Per "Hand" über ein Switch in der Sitemap kann ich die Lampe anschalten, nur per Rules scheint es nicht zu funktionieren. Ich habe das jetzt 3 Tage lang getestet. Die Lampe geht jeden Abend zum Sonnenuntergang automatisch aus, aber niemals zum Sonnenaufgang an. Ich muss die Lampe jeden morgen per WebUI anschalten. Siehe events.log .... 2014-06-01 20:56:49 - Sunrise_Time state updated to 2014-06-01T05:19:00 2014-06-01 20:56:49 - Sunset_Time state updated to 2014-06-01T21:29:00 .... 2014-06-01 21:29:00 - Sunset_Event state updated to ON 2014-06-01 21:29:00 - Sunset_Event state updated to OFF 2014-06-01 21:29:05 - PflanzenLampe state updated to OFF 2014-06-01 21:29:05 - PflanzenLampe received command OFF .... 2014-06-02 05:18:00 - Sunrise_Event state updated to ON 2014-06-02 05:18:00 - Sunrise_Event state updated to OFF .... 2014-06-02 05:18:05 - PflanzenLampe received command ON 2014-06-02 05:18:05 - PflanzenLampe state updated to ON ..... hier meine rules: rule "Sunrise" when Item Sunrise_Event received update ON then sendCommand(PflanzenLampe, ON) end rule "Sunset" when Item Sunset_Event received update ON then sendCommand(PflanzenLampe, OFF) end und meine items: Switch KuechenLampe {tinkerforge="uid=jMj, subid=kitchen"} Switch PflanzenLampe {tinkerforge="uid=jMj, subid=plants"} und meine openhab.cfg: tinkerforge:rs1.uid=jMj tinkerforge:rs1.type=bricklet_remote_switch tinkerforge:rs1.typeBDevices=kitchen tinkerforge:rs1.typeCDevices=plants tinkerforge:rs_kitchen.uid=jMj tinkerforge:rs_kitchen.subid=kitchen tinkerforge:rs_kitchen.type=remote_switch_b tinkerforge:rs_kitchen.address=50 tinkerforge:rs_kitchen.unit=0 tinkerforge:rs_plants.uid=jMj tinkerforge:rs_plants.subid=plants tinkerforge:rs_plants.type=remote_switch_c tinkerforge:rs_plants.systemCode=A tinkerforge:rs_plants.deviceCode=1 Ich habe das Gefühl das bei Sonnenaufgang der Befehl nur 1 x gesendet wird, besser wäre aber 5x. Dazu habe ich aber schon gestern etwas geschrieben.

Hallo, ich habe zuhause einen sanften Übergang zwischen dunkel und hell mit dem LED-Strip-Bricklet programmiert und habe mich dabei an folgendes Beispiel gehalten: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "abc" # Change to your UID NUM_LEDS = 16 r = [0]*NUM_LEDS g = [0]*NUM_LEDS b = [0]*NUM_LEDS r_index = 0 from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_led_strip import LEDStrip # Frame rendered callback, is called when a new frame was rendered # We increase the index of one blue LED with every frame def cb_frame_rendered(led_strip, length): global r_index b[r_index] = 0 if r_index == NUM_LEDS-1: r_index = 0 else: r_index += 1 b[r_index] = 255 # Set new data for next render cycle led_strip.set_rgb_values(0, NUM_LEDS, r, g, b) if __name__ == "__main__": ipcon = IPConnection() # Create IP connection led_strip = LEDStrip(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Set frame duration to 50ms (20 frames per second) led_strip.set_frame_duration(50) # Register frame rendered callback to function cb_frame_rendered led_strip.register_callback(led_strip.CALLBACK_FRAME_RENDERED, lambda x: cb_frame_rendered(led_strip, x)) # Set initial rgb values to get started led_strip.set_rgb_values(0, NUM_LEDS, r, g, b) raw_input('Press key to exit\n') # Use input() in Python 3 ipcon.disconnect() Ansich funktioniert auch alles wie erwartet. Mir ist aber aufgefallen, das die Funktion "cb_frame_rendered" auch noch aufgerufen wird wenn keine Änderungen an den LED's mehr eintreten, bzw. das Programm von Anfang an (bevor ich das erste mal die LED's setze) die Funktion "cb_frame_rendered" aufruft. Ich dachte so, das ich im Callback eine Funktion angeben die immer dann aufgerufen wird wenn er einmal alle LED's gezeichnet hat. Dieser Aufruf, so dachte ich, würde immer nur dann kommen wenn vorher ein "setColor" der LED's kam. Sprich wenn ich mal einen "Endwert" erreicht habe (Bsp. RGB 0,200,0) wird die Funktion nicht mehr aufgerufen. Da habe ich mich aber wohl getäuscht. Nach ca. 3 Sekunden habe ich die gewünschte Helligkeit erreicht, die Funktion wird aber immernoch alle x ms aufgerufen. Das kostet doch zum einen Resourcen und zum anderen macht es das Programm unnötig langsam. Immerhin wird ständig eine Funktion aufgerufen obwohl es nicht mehr notwendig ist. Hier nochmal mein Source-Code #!/usr/bin/env python # -*- coding: utf-8 -*- import logging from time import sleep from tinkerforge.bricklet_led_strip import LEDStrip from tinkerforge.bricklet_motion_detector import MotionDetector from tinkerforge.ip_connection import IPConnection def cb_frame_rendered(arg): global led_zaehler if Motion_detected and led_zaehler < 101: farbwert_tmp = 1 * (rgb_faktor ** led_zaehler) farbwert = round(farbwert_tmp) logger.debug('Schritt %s von 100 -> RGB-Faktor: %s Farbwert: %s', led_zaehler, rgb_faktor, farbwert) set_color(farbwert) led_zaehler += 1 def motion_on(): global Motion_detected logger.debug('Jemand BETRITT das Bad') sleep(0.5) Motion_detected = True set_color(1) def motion_off(): global led_zaehler global Motion_detected logger.debug('Jemand VERLÄSST das Bad') Motion_detected = False led_zaehler = 1 set_color(0) def set_color(wert): var_led_RED = [0] * 16 var_led_GREEN = [0] * 16 var_led_BLUE = [wert] * 16 # LED's setzen LED_bricklet.set_rgb_values(0, 15, var_led_RED, var_led_BLUE, var_led_GREEN) LED_bricklet.set_rgb_values(15, 15, var_led_RED, var_led_BLUE, var_led_GREEN) LED_bricklet.set_rgb_values(30, 15, var_led_RED, var_led_BLUE, var_led_GREEN) LED_bricklet.set_rgb_values(45, 15, var_led_RED, var_led_BLUE, var_led_GREEN) if __name__ == "__main__": # Grundeinstellungen LED_status = 0 Motion_detected = False led_zaehler = 1 rgb_faktor = 60.0 ** (1.0 / 100.0) #distance_liste = [0, 0, 0, 0] # Logging initialisieren logger = logging.getLogger('raspi_server') logger.setLevel(logging.DEBUG) console_handler = logging.StreamHandler() console_handler.setLevel(logging.DEBUG) formatter = logging.Formatter('%(asctime)s : %(message)s', '%Y-%m-%d %H:%M:%S') console_handler.setFormatter(formatter) logger.addHandler(console_handler) logger.info('System startet ...') # Tinkerforge Verbindung erzuegen ipcon = IPConnection() # Bricklets initialisieren Motion_bricklet = MotionDetector("jX1", ipcon) LED_bricklet = LEDStrip("jGU", ipcon) # mit Tinkerforge verbinden ipcon.connect("192.168.127.81", 4223) # Callbacks einstellen LED_bricklet.set_frame_duration(25) LED_bricklet.register_callback(LED_bricklet.CALLBACK_FRAME_RENDERED,cb_frame_rendered) Motion_bricklet.register_callback(Motion_bricklet.CALLBACK_MOTION_DETECTED, motion_on) Motion_bricklet.register_callback(Motion_bricklet.CALLBACK_DETECTION_CYCLE_ENDED, motion_off) # eine Art von Endlosschleife raw_input('Press key to exit\n') ipcon.disconnect()

Ja sehr abstrus ... Ich würde nur ungern meine erste HE877 auf Typ C anlernen, da ich dort weniger Devices addressieren kann und ich Angst habe das ich danach nicht mehr auf Typ B wechseln kann. Bin aber selbst total verwundert über das Ganze ...

So, ich kam jetzt endlich dazu mit intensiver mit openHAB zu beschäftigen und will dann mal einen Zwischenbericht dazu abliefern. Wie schon gesagt muss ich mich herzlich bei dir bedanken Theo, nicht nur das du die Bindings geschrieben hast, nein mit deinem Beispiel und deiner Schritt für Schritt Anleitung habe ich es dann sogar geschafft openHAB in Verbindung mit TF zum laufen zu bekommen. Danke Derzeit habe ich folgende TF-Module in Verbindung mit openHAB am laufen: TemperatureBricklet, HumidityBricklet, BarometerBricklet,AmbientLightBricklet und das RemoteSwitchBricklet. Dafür nutze ich deine RemoteSwitch-Beta-Bindings. Wann kommen eigentlich deine neuen Bindings mit Beispielen auf die Seite von openHAB? Zunächst einmal funktioniert alles - wunderbar und prima Arbeit von dir Beim RemoteSwitchBricklet habe ich allerdings manchmal Probleme damit, das er sich den "Zustand" des Switch nicht merkt. Will heißen ich schalte per openHAB-WebUI eine Steckdose auf ON und gehe dann ein paar Stunden später wieder auf die openHAB-WebUI, dann ist der Switch wieder auf OFF, obwohl in Wirklichkeit die Lampe an ist und der Switch somit auf ON gestellt sein müsste. Das sorgt dafür das man nicht sicher sein kann ob der switch (bzw. die Lampe) auf on oder off steht, das führt wiederum dazu das man öfters "zweimal" auf off klicken muss. D.h. in Wirklichkeit ist die Lampe an, openHAB zeigt mir sie aber aus an. Beim ersten drücken sendet openhab dann den ON-Befehl (unnötig da ja schon an), beim zweiten drücken dann den erwünschten OFF-Befehl. Das ist ärgerlich aber kein Beinbruch. Ich hoffe das dies nur ein kleiner Fehler ist den du schnell bereinigen kannst. Außerdem wäre es eine gute Idee die Abfrage-Frequenz bei den Sensoren einstellen zu können. Ähnlich wie ich auch bei TF direkt die Zeit für die Callbacks einstellen kann. Als nächstes würde ich gerne noch beim RemoteSwitch die "Sende-Rate" einstellen, sprich wie oft er das on/off-Signal hintereinander sendet. Im BrickViewer steht das z.Bsp. standartmäßig auf 5 Aber ansonsten habe ich das Gefühl das deine Bindings klasse funktionieren. Ich werde demnächst noch das MotionDetectionBricklet testen und in Zukunft, sofern als Binding verfügbar, das LEDStripBricklet. Ansonsten habe ich zwar noch einige Probleme mit openHAB ansich und der Konfiguration, das hat aber nicht mit deinen Bindings zu tun.

Hallo erstmal, so dann will ich die Verwirrung zum Thema Elro mal komplett machen. Also ich besitze 2 x Steckdosenempfänger vom Typ HE877. Zusätzlich habe ich auch den entsprechenden USB-Dongle von Elro. Mit diesem Dongle und der entsprechenden Software habe ich unter Windows beide Steckdosen auf Kanal 50 und 51 angelernt - das war vor ca. 5-6 Monaten. Vor ca. 1-2 Monaten habe ich die erste Steckdose mit Hilfe des RemoteSwitch von TF in Betrieb genommen. Das war auch kein Problem, Typ B Schalter ausgewählt, auf Kanal 50 gestellt und siehe da, es lief. Ich konnte mit TF die Steckdose schalten. Gestern wollte ich dann die 2. Steckdose in Betrieb nehmen. Also das Remote Switch auf Kanal 51 gestellt und was passiert? Richtig - nichts Zuerst war ich am rätseln ob die Steckdose richtig programmiert ist, also das Ding in den "Lern-"Modus versetzt und über TF diverse Versuche gestartet die Steckdose auf Kanal 51 anzulernen - alles ohne Erfolg. Also habe ich wieder den USB-Dongle ausgekramt und damit versucht die Steckdose anzulernen. Das lief auch wunderbar, ich konnte die Steckdose dann über den Dongle auf Kanal 51 an- und ausschalten. Testweise habe ich auch die "alte" Steckdose auf Kanal 50 nochmal versucht - auch diese lies sich über den Dongle schalten. Ich halte fest, über den USB-Dongle und die Windows SOftware konnte ich beide Steckdosen schalten (Kanal 50 und 51). Optimistisch von diesem Erfolg habe ich das Ganze wieder mit dem RemoteSwitch versucht. Kanal 50 an-/ausschalten - klappt Kanal 51 an-/ausschalten - klappt nicht Jetzt kam langsam Frust auf, allerdings hatte ich diesen Thread irgendwie im Hinterkopf. Also flugs rein ins Forum und den THread komplett gelesen. Also die 2. "neue" Steckdose wieder in den Lernmodus versetzt und dann per RemoteSwitch mit Typ C und Devicecode 1 angelernt. Und siehe da, auf einmal ging auch die 2. Steckdose. Ich halte fest: Steckodse 1 Typ HE877 schalte ich mit Typ B auf Kanal 50 Steckdose 2 Typ HE877 schalte ich mit Typ C auf Device 1 Logik?!? Ich glaube aber das vor dem letzten Firmware-Update des RemoteSwitch noch beide Steckdosen funktioniert haben, bin mir aber nicht mehr sicher. Kann auch an Elro liegen. Auf jeden Fall hat es nicht unbedingt was mit dem Empfänger-Typ zu tun.

Da habe ich mich wohl zu früh gefreut. Nachdem ich das Projekt jetzt endlich mal wieder weiterführen wollte, musste ich feststellen das ich mit den Werten des DistanceIR immer noch nicht zurecht komme. Selbst gerundet habe ich immer noch "Sprünge" und "Aussetzer" drin, dadurch wird das LED-Licht dann ganz plötzlich dunkler oder heller - das sieht einfach nur unschön aus. Viel schlimmer ist aber wieder das Verhalten im "Ruhezustand". Je nach Lichtsituation zeigt er konstant 80cm an (damit könnte ich noch gut leben) oder er sprint wie wild im 10/100 Sekunden Takt von 70 auf 35 auf 47 auf 53 auf 33 .... Es ist dann unmöglich festzustellen ob überhaupt jemand davor steht. Siehe auch das Bild weiter unten. Ich versuche die ganze Zeit irgendeine Art von Filter zu programmieren: a) um zu erkennen wenn jemand davor steht (d.h. die ganzen Sprünge aussortieren) b) um eine schöne "runde" Kurve beim messen der Entfernung zu bekommen, sprich die Werte zu glätten (aus Treppe mache eine Kurve) Nur klappen tut zur Zeit weder das eine noch das andere. Welchen realistischen Zweck kann der DistranceIR haben wenn er so extrem empfindlich auf die Lichtsituation reagiert?

So, ich habe die Sensoren jetzt mal alle an lange Kabel gehängt und dann nebeneinander gelegt. Und siehe da, auf einmal sind es die gleichen Werte. Ich hätte nicht gedacht das die Abwärme des RasPi die Werte der Sensoren dermaßen verändern kann. Danke.

Nabend, war heute damit beschäftigt die TF-Hardware aus dem Bad zu erweitern und habe selbige deshalb mit ins Wohnzimmer genommen. Dort habe ich auch TF-Hardware verbaut, zum Großteil mit den gleichen Sensoren. So kam es das ich die Sensoren und die Werte im direkten Vergleich gesehen habe. Ich habe also 2 x Setups, beide mit Raspi, beide mit Temperature- und Humidity-Bricklet - Entfernung zwischen beiden ist ca. 50 cm. Trotzdem bekomme ich komplett verschiedene Werte. Temp1: 22.8 °C Temp2: 30.6 °C Humi1: 43.2 % Humi2: 32.4 % Wie kann sowas sein? Und vor allem, was läuft hier falsch?

Hallo, ersteinmal vielen Dank Theo, mit deinem Posting habe ich es geschafft Also ja, ich bin weitergekommen, momentan habe ich nur nicht genug Zeit. Also sammel ich ersteinmal etwas Erfahrung und Fragen und melde mich dann wieder.

Hallo, ich muss zugeben das ich nicht einmal verstehe wie ich anfangen soll, von daher steht in meiner test.items und test.sitemap nocht gar nicht drin - wie auch wenn man nicht versteht was ich wie darein schreiben muss. Von daher kann ich dir leider nicht meine Dateien posten - die gibt es noch nicht wirklich. Deswegen hatte ich gefragt ob du nicht einfach die .items und die .sitemap zu deiner Wetterstation posten könntest, das würde mir schon sehr helfen denke ich. Was ich für den Anfang erreichen will ist quasi 2 x Räume zu haben (Badezimmer + Aussen) in welchen mir jeweils die entsprechenden Sensordaten angezeigt werden (beispielhaft erstmal nur Temperatur und Luftfeuchtigkeit).

Nabend, ich wollte heute endlich loslegen und openhab testen ... leider habe ich nach einer Weile wieder frustriert aufgegeben. Ich finde einfach keinen Einstieg und komme mit der Anleitung nicht klar. Verstehe mich nicht falsch, es hat nichts mit deinen Bindings zu tun, ich verstehe den grundsätzlichen Aufbau der .items und .sitemap nicht richtig. openhab ansich habe ich auf dem pi zum laufen bekommen, aber ausser dem Demo bekomme ich nichts hin. Früher hattest du mal unter "http://m1theo.org/" deine Wetterstation veröffentlicht, nur diese Seite ist down. Daher jetzt meine große Bitte an dich: Könntest du hier mal eine ganz einfache .items und .sitemap posten? Z.Bsp. mit nur 2 x Bricklets: TemperatureBricklet und RemoteSwitchBricklet (A,B,C ist egal, einfach nen Schalter für on und einer für off) Ich brauche irgendwie einen Anfang, ein ganz einfaches Beispiel aus der Praxis - deine Wetterstation mit Anzeige auf dem Smartphone über openhab wäre perfekt. Dazu einfach die verschiedenen openhab Dateien posten und die Welt wäre für mich ein wenig schöner

Wäre nicht eventuell Bluetooth hier eine Möglichkeit? Immerhin wird genau das von den meisten "externen" Sensoren die ich bisher gesehen habe genutzt um die Daten zu senden. Also einen Bluetooth 4.0 Sende-/Empfangseinheit an den Bricklets und eine am Masterbrick?

Das finde ich echt gut von TinkerForge, wirklich ganz große Klasse Und auch nochmal an dich, Theo, vielen Dank. Freue mich schon tierisch auf das Ergebnis wenn alle meine Bricklets unterstützt werden.

Gute Idee, habe auch schon darüber nachgedacht Theo das Motion-Bricklet zu schenken, hmm, würde mich also auch daran beteiligen wenn möglich. Ansonsten würde mir nur noch das IR-Distance-Bricklet fehlen, dann könnte ich mit openHAB loslegen. VIelleicht sollte ich Theo dann einfach dieses Bricklet spendieren und das Motion-Bricklet kommt von Luxor?

Nutze python 3.2 und damit laufen die Beispiele.