Letztes Jahr habe ich damit begonnen eine Heimautomatisierung auf Basis von TinkerForge Bauteilen umzusetzen. Inzwischen läuft das System ganz gut und ich möchte hier einen ersten Bericht vorstellen. Ich werde diese Reihe mit der Zeit noch erweitern. Es lohnt sich also hin und wieder mal vorbeizuschauen

230V?!

Mein Hauptkriterium war dabei nicht an 220/230V zu spielen. Also entschied ich mich dazu dies auf der Basis von Handelsüblichen Funksteckdosen umzusetzen. Ich hatte zwei verschiedene Systeme, die ich ansteuern wollte. In meiner ersten Bestellung bestellte ich also unter anderem zwei Industrial Quad Relay Bricklets, mit denen es möglich ist die Schalter solcher Fernbedienungen zu überbrücken und diese so steuerbar zu machen. Ich hatte allerdings nicht daran gedacht, dass ich zwei verschiedene Fernbedienungen mit je 4 Empfängern hatte, wobei ich jedoch je einen Ein und einen Aus Schalter hatte. Das bedeutete, dass ich pro Fernbedienung 2 dieser Bricklets brauchte, weshalb ich vorerst nur eine dieser Fernbedienungen anschließen konnte. Die Steuerung funktionierte und ich konnte mich schon dem nächsten Thema widmen.

Das Herzstück

Als Herzstück der Steuerung kommt ein Raspberry Pi zum Einsatz. Die wichtigen Komponenten, also die Fernbedienungen sind direkt per USB mit dem Pi verbunden, sodass auch  bei einem Netzwerkausfall sichergestellt ist, dass die Beleuchtung und andere Geräte noch angesteuert werden können.

Wie es weiterging…

Auch wenn das nicht ganz der Reihenfolge entspricht, möchte ich es trotztem für die bessere Verständlichkeit hier einfügen. Meine zweite Bestellung ging dann bei TinkerForge Anfang diesen Jahres ein. Inzwischen war das Remote Switch Bricklet erschienen, mit dem es möglich wurde die zweite, noch nicht angeschlossene Fernbedienung zu ersetzen. Es kann die Funksteckdosen direkt ansteuern, sodass die Fernbedienung weiterhin (als Notknochen) verwendet werden kann.

Programmierung

Da die Funkempfänger keinen Status zurückliefern, musste ich eine andere Lösung finden, damit der Pi weiß, ob er einen Empfänger Ein oder Aus schalten soll. Ich entschied mích dazu alles in einer MySQL Datenbank abzuwickeln. Dort ist zum einen der Typ des Empfängers gespeichert zum anderen aber auch der anzuzeigende Name, die Empfängernummer sowie der Status. Da die Empfänger sehr zuverlässig schalten ist es problemlos möglich diese Werte in einer Datenbank abzulegen. Daraus resultieren keinerlei Probleme.

Die Hauptlogik beim Schalten wird von einer zentralen Python Klasse aus abgewickelt. Sie stellt unter anderem sicher, dass es beim Senden nicht zu Überlagerungen kommt. Würden nämlich zwei Signale gleichzeitig gesendet werden, dann wäre kein Schaltvorgang mehr möglich. Deshalb wartet die Python Klasse so lange, bis alle Ausgänge der Quad Relay Bricklets auf Aus stehen und das Remote Switch Bricklet fertig ist, bis ein weiterer, eventuell von einem anderen Programm gesendeter Befehl wirklich ausgeführt wird. Die Klasse hat dabei ihre eigene Warteschlange, sodass für eigene Applikationen wie z.B. eine Zeitsteuerung über Crontab keine Aufwändige Programmierung mehr vorgenommen werden muss. Der erforderliche Code beschränkt sich dafür auf wenige Zeielen. Nach dem Schaltvorgang wird der aktuelle Status noch in die Datenbank geschrieben.

Steuerung

Insgesamt habe ich für die Steuerung 2 IO16 Bricklets und insgesamt 10 beleuchtete Taster verbaut. Es gibt zwei Steuerungspanels. Zum einen eins mit den absoluten Basifunktionen für Licht an / aus und zum anderen ein umfangreiches mit LCD Display.

Hauptlichtschalter

Dieser Schalter befindet sich direkt an der Tür. Die Taster leuchten während der Schaltvorgänge bzw. blinken während der Wartezeit
Dieser Schalter befindet sich direkt an der Tür. Die Taster leuchten während der Schaltvorgänge bzw. blinken während der Wartezeit

Der Hauptlichtschalter verfügt über zwei Taster. Er ist über eine Ethernet Master Extension mit dem Netzwerk verbunden, um eine weite Entfernung zum Raspberry Pi zu ermöglichen. Der erste Taster schaltet den Deckenfluter ein, falls alle Empfänger auf aus stehen. Sollte nur ein Empfänger eingeschaltet sein, werden beim drücken dieses Tasters aller eingeschalteten nacheinander ausgeschaltet. Der andere Taster ist zurzeit nur mit einer zeitverzögerten Ausschaltfunktion belegt. Wird er betätigt, wenn mindestens ein Empfänger an ist, wartet er 15 Sekunden bis alle eingeschalteten Empfänger ausgeschaltet werden.

Außerdem hängt am selben Masterbrick auch ein Hall Effect Bricklet sowie ein Ambient Light Bricklet. Auf diese Weise kann bei einer Türöffnung bei Dunkelheit automatisch das Licht eingeschaltet werden.

Bedienpanel

Des weiteren habe ich direkt am Bett ein umfangreiches Bedienpanel angebracht. Es verfügt über ein 20×4 LCD Display sowie ein Steuerkreuz und 4 Taster für Schnellwahlen. Auf dem Display wird ein grafisches Menü zur Verfügung gestellt, dass unter anderem zur Steuerung der Funkempfänger oder des Internetradios genutzt werden kann. Auch das Anlernen der Funkempfänger ist über dieses Menü möglich. Durch einen modularen Aufbau ist es in der Python Anwendung möglich neue Komponenten schnell und unkompliziert hinzufügen. Das Panel benutzt außerdem die gleiche Klasse zur Steuerung der Funkempfänger wie der Hauptlichtschaler. Dadurch wird der Programmieraufwand deutlich reduziert.

In Zukunft plane ich unter anderem noch Minispiele auf diesem Panel laufen zu lassen, die als Wecker benutzt werden sollen. Werden sie nicht gespielt, soll ein schriller Alarmton ertönen. Dazu wird es hier noch einen Artikel geben. Das folgende YouTube Video zeigt die bisherigen Funktionen. Mit neuen Funktionen wird hier sicher noch das ein oder andere Video folgen.

Das Panel ist direkt per USB Kabel mit dem Pi verbunden. So ist sichergestellt, dass ich morgens vom Bett aus auch bei einem Netzwerkausfall das Licht noch einschalten kann. Bei mir Schlafmütze ist sowas wichtig ;). Außerdem habe ich das LCD Display mit einem Analog Out Bricklet dimmbar gemacht. Wenn alle Funkempfänger auf Aus stehen, und das Licht unter einen bestimmten Wert sinkt, wird automatisch das Display gedimmt und die LEDs in den Tastern am IO16 Bricklet nicht mehr per Output High eingeschaltet sondern per Input Pull Up. Dadurch glimmen die LEDs noch leicht, was es grade bei Dunkelheit sehr angenehm macht, das Panel zu bedienen. Auch hier übernimmt eine Zentrale Klasse die Steuerung, sodass alle hinzugefügten Module nur auf diese Klasse zurückgreifen müssen.

Zukunftsaussichten

  • Zurzeit habe ich meine Stereoanlage mit dem Raspberry Pi verbunden. Es findet jedoch noch keine Steuerung per Infrarot über den Pi statt. Sobald ich das umgesetzt habe, könnte ich meinen eigenen Radiowecker entwickeln.
  • Die Zeitsteuerung bzw. der Wecker sollen über das Bedienpanel möglich werden. Bisher erfolgt das noch alles über die Crontab Datei
  • Die Heizung soll ebenfalls automatisch gesteuert werden
  • Die Daten des Temperatur- und Luftfeuchtigkeitssensors sollen erfasst und abgespeichert werden. Eventuell gibt es dann auch eine Anwendung für das Panel mit dem Ziel einer “Klimaberatung”
  • Der Raspberry Pi soll zusammen mit den anderen Komponenten in einem Universalgehäuse untergebracht werden
  • Der Raspberry Pi soll einen automatischen Abschaltmechanismus bei zu hoher Chiptemperatur erhalten (sicher ist sicher)

Es bleibt also noch einiges zu tun, worüber ich auch hier berichten werde. Solltet ihr noch Ideen oder Fragen haben, könnt ihr gerne die Kommentarfunktion benutzen.

 

9 thoughts on “Heimautomatisierung mit TinkerForge”

  1. Sehr schönes Projekt und sehr gut gemacht, mein Lob hast du.

    Wie wäre es wenn du deinen python Source-Code hier zum Download anbieten würdest?
    Damit könntest du einigen Leuten (wie mir) helfen und man müsste das Rad nicht immer wieder neu erfinden.

    Ich arbeite derzeit selbst an meiner Heimvernetzung, kann mich aber noch nicht entscheiden ob ich selbst etwas mit python und NetIO entwickle oder auf openHAB, bzw. FHEM zugreifen soll.
    Bei mir steht vor allem die Bedienung über Desktop/Tablet/Smartphone im Fokus.

    Ich werde dein Projekt aber auf jeden Fall weiter verfolgen.

    1. Danke für deinen Kommentar. Mal sehen, ob ich es schaffe den Code hier zur Verfügung zu stellen. Der ist schließlich sehr stark an meine Bedürfnisse angepasst und zurzeit auch noch sehr unordentlich.

      Die Fertigen Möglichkeiten waren mir zu wenig Herausforderung und vorallem zu unflexibel. Bei OpenHAB hatte ich zudem mit der Java Umgebung Bedenken.

      Die Steuerung per Smartphone ist auch geplant, wobei ich dafür noch am Apache rumspielen muss, damit er den Python Code ausführt. PHP exec gefällt mir da nicht.

    2. Ich habe den Code der light.py – also der Ansteuerung der Funkempfänger hier online gestellt. Wenn du noch Fragen hast oder gerne mehr Code hättest kannst du dich gerne nochmal über die Kommentare melden.

  2. Ich habe mir auch die Bausteine von Tinkerforge gekauft und möchte es auch über ein Raspberry steuern, mein Ziel ist jedoch die Heimautomation über den fhem zu machen. Leider hat es bis jetzt noch nicht geklappt.

    1. Tut mir leid, aber das wird auch vorerst nichts werden da die Tinkerforge Bauteile derzeit nicht von FHEM unterstützt werden.
      Dazu müsstest du dir schon die passenden perl-Bindings für FHEM selbst schreiben.

      1. @MarkusH Als Alternative könntest du dir noch OpenHAB ansehen. Da gibt es immerhin halbfertige Bindings im Forum. Die sind allerdings nicht von TinkerForge erstellt, weshalb auch nicht alle Bricklets unterstützt werden.

        1. Ich habe es jetzt mit Python realisiert.
          Im Python Programm habe ich den Wert mit:
          os.system(“/opt/fhem/fhem.pl 7072 ‘set temperature
          {}'”.format(temperature))
          an den fhem Übergeben, und in der fhem.def folgendes angelegt.
          define temperature dummy
          attr temperature room Wetterstation

          Jetzt fehlt mir noch der umgekehrte Weg vom fhem einen Wert ausgezugen und im anderen Programm einzulesen.

          1. Ich denke mal das geht deutlich sauberer, wenn du das direkt mit den offiziellen TinkerForge Perl Bindings machst anstatt über python und du die verwendest um ein eingeschränktes Binding für FHEM zu erstellen. Je nachdem müsstest du dich natürlich ein wenig mit Perl beschäftigen, aber ich denke gerade beim umgekehrten Weg wirst du mit dem os.system Aufruf deutliche Geschwindigkeitseinbußen hinnehmen müssen. Schließlich wird ja wieder eine neue Datei + Bindings geöffnet, in den Interpreter eingelesen und dann erst ausgeführt. Ich habe die Erfahrung gemacht, das sowas gerade auf dem Raspberry Pi die Geschwindigkeit einer Anwendung sehr stark runterziehen kann.

            An sich sollte das doch nicht so schwierig sein. Du scheinst dich ja schon mit der Datenübergabe an FHEM beschäftigt zu haben. Ich könnte mir vorstellen, dass auch in der TF Community Interesse an diesen Bindings besteht.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.