home
erste Version am 05.10.2015
letzte Änderung am 03.12.2016

Rollotron Schwenkwickler ansteuern


Bei diesem Projekt werde ich mal von Anfang an meine Überlegungen in HTML erfassen und Zwischenschritte sowie ggf. auch Irrwege dokumentieren.

Im ersten Schritt werden die Signale einer IR-Fernbedienung für Rollladen-Motoren eingelesen bzw. gemessen.
Danach wird dann eine Schaltung und ein Programm entwickelt, um diese IR-Signale programmgesteuert ausgeben zu können - mit dem Ziel, fünf Rollläden zu definierten (und über das Jahr wechselnden) Zeiten rauf- bzw. runterzufahren.

Inhalt

Motivation
Schritt 1 - Einlesen der IR-Fernbedienung
Schritt 2 - Ausgeben der IR-Signale
    Analyse bzgl. Verbesserungsmöglichkeiten
    Erkenntnisse ins Programm einbauen
Schritt 3 - Zeitsteuerung zufügen
Schritt 4 - weitere Überlegungen...
    ...zum Stromverbrauch
    ...zum Stellen der Uhr
Schritt 5 - ESP8266 (vor der Lieferung)
Überlegungen zur Kommunikation mit der Rollladensteuerung
Schritt 6 - die ESP8266-Module sind da
Grundeinrichtung des ESP8266
das Programm ist quasi fertig
Rückschläge und Erweiterungs-Ideen
die Pegelwandler sind da
3.3V Festspannungsregler
Schritt 7 - die finale Schaltung
der erste Arbeitstag
Schritt 8 - letzter Schliff vor dem Einsatz
Schritt 9 - Gehäuse-Bau und Dauerbetrieb
Nachlese
Nachlese 2
Ideen für eine mögliche nächste Version
ein Jahr Dauerbetrieb

Weil das Dokument am Ende doch etwas größer geworden ist, habe ich es nachträglich auf mehrere Seiten verteilt.

Motivation

Wir haben im Wohnzimmer fünf Rollläden, die alle mit jeweils einem "Rademacher Rollo Tron Schwenkwickler Comfort 9540" rauf- bzw. runtergefahren werden.
Diese Schwenkwickler können ihre Aufgabe zeitgesteuert erledigen oder manuell am Gerät als auch mit einer IR-Fernbedienung bedient werden.
Seit der Anschaffung vor gut zwei Jahren laufen die Dinger hier primär zeitgesteuert. Das klappt auch ganz passabel (und die Uhren laufen sogar nach einem ca. viertelstündigen Stromausfall korrekt weiter).
Trotzdem stören mich zwei Dinge:
  1. die Uhren lassen sich nicht auf die Sekunde genau synchronisieren. Somit fahren die Rollläden bestenfalls alle in der selben Minute rauf oder runter. Aber nie so richtig schön "exakt zeitgleich". Vier der fünf Rollläden sind direkt nebeneinander angebracht...da sähe es viel hübscher aus, wenn sie sich alle zu jedem Zeitpunkt auf der selben Höhe befinden würden.
  2. über das Jahr muss ich die Zeiten zum Runterfahren mehrmals der Jahreszeit anpassen. Im Sommer erst um 23:00 Uhr, im tiefsten Winter aber schon um 18:00 Uhr - mit mehreren Zwischenschritten bzw. -zeiten über die Monate. Das nervt total.

Außerdem habe ich seinerzeit die fernbedienbaren Versionen (die damals pro Stück etwa 30€ teurer als die nicht fernbedienbaren Modelle waren) samt IR-Fernbedienung extra deswegen gekauft, um genau dieses Projekt irgendwann mal realisieren zu können. Und nun habe ich gerade mal wieder Lust auf ein Hardware-Projekt :-)

Ziel soll sein, dass ein Arduino (oder final eher ein nackiger ATmega328P-PU) die Kontrolle über die Rollläden übernimmt und diese mit Hilfe einer Echtzeituhr (RTC DS1307) Jahreszeit-abhängig ansteuert.
Die Tabelle mit der Relation "Monat zu Tageslicht" wird voraussichtlich frühestens in einem Jahr fertig sein.

Schritt 1 - Einlesen der IR-Fernbedienung

Das Einlesen einer IR-Fernbedienung habe ich beim Projekt Glotzregulator ja schon üben können.
Die Schaltung ist trivial:
Arduino mit TSOP     oder auch     Foto Arduino mit TSOP


Allerdings ging es beim Glotzregulator nur um das eindeutige Erkennen der unterschiedlichen Tasten einer IR-Fernbedienung.
Leider hat sich gezeigt, dass das hier nicht langt.
Der dort verwendete Befehl pulseIn() eignet sich nicht, wenn die Zeiten zwischen zwei unmittelbar aufeinander folgenden Flanken gemessen werden sollen.

Daher also ein neuer Ansatz, der in dem Programm getRollotronIRcode.ino umgesetzt ist.
Sobald ein Wechsel von HIGH nach LOW (an einem TSOP31240) erkannt wurde, werden die Zeiten zwischen allen folgenden HIGH-LOW- und LOW-HIGH-Wechseln protokolliert. Und zwar bis zu einer definierten Maximal-Anzahl von Wechseln.

Werden an der IR-Fernbedienung alle elf Tasten je einmal kurz betätigt, liefert das Programm (bei #define DEBUG 1) eine Ausgabe, die ich wegen deren Länge in dieses eigene Dokument ausgelagert habe.

An der Ausgabe ist zu erkennen, dass primär zwei Zeiten vorkommen.
Ein kurzes Signal ist ca. 600µs lang, ein langes Signal ist ca. 3.700µs lang.
Bei Bit 34 wird eine Pause von ca. 29.000µs eingelegt. Danach wiederholt sich das Signal einmalig.
Ebenfalls ist zu erkennen, dass ein Signal offenbar 71 Flanken lang ist.

Werden nur die Zeiten zwischen Flanken betrachtet, dabei ein kurzes Signal mit 0 und ein langes Signal mit 1 dargestellt, ergibt sich folgendes Bild:
01010101010101010101010101010101010-01010101010101010101010101010101010---- A
10100101010101010101010101010101010-10100101010101010101010101010101010---- 1
01011010010101010101010101010101010-01011010010101010101010101010101010---- 2
01010101101001010101010101010101010-01010101101001010101010101010101010---- 3
01010101010110100101010101010101010-01010101010110100101010101010101010---- 4
01010101010101011010010101010101010-01010101010101011010010101010101010---- 5
10100101010101010101010110101010010-10100101010101010101010110101010010---- up
01011010010101010101010101011010101-01011010010101010101010101011010101---- down
10100101101001010101010101010101101-10100101101001010101010101010101101---- +
10101010010110100101010101010101010-10101010010110100101010101010101010---- -
01011010101001011010010101010101010-01011010101001011010010101010101010---- stop
Mit dieser Erkenntnis kann nun ein Programm erstellt werden, das diese Signale ausgibt.

Schritt 2 - Ausgeben der IR-Signale

Das Programm zur Ausgabe der in Schritt 1 gemessenen Signale ist in Version 1.0 erstmal send40KHz.ino.
Es funktioniert - jedoch ist mir noch nicht ganz klar, warum ich die Zeiten (BIT_SHORT und BIT_LONG) korrigieren musste, um die oben ermittelten Werte (BIT_0 und BIT_1 in getRollotronIRcode.ino) zu erhalten.

Mit folgender Schaltung funktioniert das Programm sowohl an einem Arduino mit getRollotronIRcode.ino, als auch an den echten Schwenkwicklern.
Allerdings eignet sich die Schaltung noch nicht, um das gesamte Wohnzimmer von einem Punkt aus mit dem IR-Signal zu fluten ..... und somit alle Schwenkwickler sicher zu erreichen.
Vielleicht hat ja die IR-Fernbedienung nicht umsonst zwei Sende-LEDs eingebaut.....und ein TV-B-Gone sogar vier.

Schaltplan IR Sender V1

Der Transistor an Pin3 schaltet 40KHz auf die LED, der Transistor an Pin4 schaltet das Signal.

Analyse bzgl. Verbesserungsmöglichkeiten

Nun soll mal getestet werden, wie schnell der tone()-Befehl aus der Arduino-CoreLib einschwingt - um ggf. den zweiten Transistor einsparen zu können.
Das Progrämmchen dazu sieht folgendermaßen aus:
void setup() {
  pinMode(2, OUTPUT);
}

void loop() {
  tone(2, 40000);
  delayMicroseconds(77);
  noTone(2);
  delayMicroseconds(33);
}

Es liefert an Pin2 diese Ausgabe (bei 10µs pro Kästchen):
Ozzi-Frequenz

40KHz bedeutet eine Periodendauer von 25µs - hier also 2.5 Kästchen.
Das kommt schon mal recht gut hin.

Nun noch etwas rauszoomen, um das Einschwingverhalten beurteilen zu können:
Ozzi-Einschwingen

Auch das sieht passabel aus.......zumindest bezüglich des Einschwingverhaltens.

Aber bezüglich der Signal- und Pausen-Dauern stimmt das ja vorne und hinten nicht.
Statt 77µs dauert das Signal ca. 200µs und die Pause statt 33µs eher 100µs.

Baue ich das Programm etwas um und ersetze tone() durch digitalWrite():
void setup() {
  pinMode(2, OUTPUT);
}

void loop() {
  digitalWrite(2, HIGH);
  delayMicroseconds(77);
  digitalWrite(2, LOW);
  delayMicroseconds(33);
}

bekomme ich folgendes Bild:
Ozzi-ohneTone

Das passt schon deutlich besser zu den 77µs / 33µs - auch wenn eine Periode eher 120µs als 110µs dauert.
Also verfälscht der tone()-Befehl offenbar den delayMicroseconds()-Befehl.

Schnell noch ein Zweit-Test mit tone() auf einem anderen Pin:
void setup() {
  pinMode(2, OUTPUT);
  tone(4, 40000);
}

void loop() {
  digitalWrite(2, HIGH);
  delayMicroseconds(77);
  digitalWrite(2, LOW);
  delayMicroseconds(33);
}

Liefert wieder Mist:
Ozzi-tonePin4

Tja....damit wäre der Beweis erbracht, dass tone() den delayMicroseconds() stört.
Um so höher die Frequenz von tone(), um so größer die Abweichung bei delayMicroseconds().
So ein Murks...warum steht das nicht GROSS und fett in der Referenz zu tone() oder delayMicroseconds() ???

Aber immerhin wäre damit nun auch erklärt, warum in send40KHz.ino nicht die selben Signal/Pausen-Zeiten wie in getRollotronIRcode.ino verwendet werden konnten.

Erkenntnisse ins Programm einbauen

Das mit der Abweichung von delayMicroseconds() ist zwar unschön, lässt sich aber relativ einfach Workaround'en (siehe send40KHz.ino).
Daher bleibt das vorerst so. Aber der zweite Transistor in der Schaltung wird nicht gebraucht, weil ebenso gut mit mit tone() und noTone() gesendet werden kann.
Für mehr Sendeleistung kommt stattdessen ein deutlich kleinerer Widerstand rein.
Der jetzt durch die IR-LED fließende Strom muss gepulst kommen - sonst wird die IR-LED wahrscheinlich noch einmal ein kurzes Rauchzeichen abgeben und sich dann ins Nirvana verabschieden.
Die neue Version der Schaltung sieht so aus:

Schaltplan IR Sender V2     oder auch      Foto Sender V2

Die Version 2 des Sende-Programms heißt konsequenterweise send40KHz-v2.ino. Und die v2.1 send40KHz-v2.1.ino.
Mit obiger Schaltung steuert sie erfolgreich vier von fünf Schwenkwicklern von einem Standpunkt aus.
Der von diesen am weitesten entfernte Schwenkwickler hatte ca. fünf Meter Abstand zur IR-LED.
Für den fünften musste ich die IR-LED lediglich neu "ausrichten" bzw. die Schaltung etwas drehen.
Dann wurde auch der fünfte ca. sieben Meter entfernte Schwenkwickler erreicht.
Das deutet für mich darauf hin, dass diese IR-LEDs ziemlich gerichtet strahlen.
Voraussichtlich werde ich mindestens zwei Sende-Einheiten bauen und strategisch platzieren.

Da sich auch ein paar IR-Dioden vom Typ CQY-99 in meinen Beständen befanden (und diese laut Datenblatt weniger gerichtet strahlen), habe ich noch etwas damit rumgetestet.
So ganz zufriedenstellend war das aber immer noch nicht.
Deshalb habe ich dann noch etwas "Strom nachgelegt".
Weil der nun aber nicht mehr vom ArduinoUNO kommen konnte, habe ich ein Akku-Pack angeschlossen.
Sah dann so aus:
Foto Sender V3    oder auch    Schaltplan Sender V2a
Nun endlich.... :-)
Alle fünf Schwenkwickler können von einer Position aus angesprochen werden, ohne die IR-LED zwischendurch neu ausrichten zu müssen.
Unter der Annahme, dass über der IR-LED 1.7V abfallen und das Akku-Pack 5.4V liefert, fließen bei einem Vorwiderstand mit 4.1Ω durch die IR-LED (5.4V-1.7V)/4.1Ω=0.9A.
Das ist zwar neun mal mehr als dauerhaft erlaubt, aber noch deutlich unterhalb des für 100µs lang erlaubten Stroms von 1.5A.
So rein theoretisch bzw. nach Datenblatt müsste ich bis (5.4V-2.7V)/1.5A=1.8Ω runtergehen dürfen, wenn ich das maximal 100µs lang mache.
Aber ich will die IR-LED ja nicht am äußersten Limit betreiben....und lieber länger was davon haben.
BTW: der MJE3055 ist ein bischen Overkill. Der schafft 6A. Aber weil ich von dem ein paar rumliegen habe, ist es der geworden.


 nächste Seite