Alte Junkers Gastherme smart machen

Allgemein

Achtung: Änderungen als Heizungsanlagen sollten nur von Fachbetrieben durchgeführt werden! Alle Angaben ohne Gewähr!

Zum Beginn der Adventszeit möchte ich mich einem Thema beschäftigen das mich schon lange genervt hat: Die Dummheit meiner Heizung. Während sich fast alle meine anderen Geräten mehr oder wenige smart verhalten war mir mein Junkers TR 21 schon lange ein Dorn im Auge. Es kann nur fix auf eine Temperatur eingestellt werden und ist nichtmal in der Lage nachts weniger zu heizen geschweige denn sich z.B. am Wochentagen anders zu verhalten.

Alternativen wären neuere Versionen von Junkers wie das TR 100 das immerhin eine Zeitschaltuhr besitzt oder TR 200 bei dem man sogar mehrere Zeiten pro Tag einstellen kann: Beides für unter 100€ kaum zu bekommen. Oder man investiert das doppelte und bekommt z.B. mit Tado* eine intelligente Lösung die sich automatisch an Wetter oder Anwesenheit orientiert.

Mit der ersten Lösung war ich aufgrund des geringen Funktionsumfang unzufrieden, mit der anderen wegen des hohen Preises und dem Zwang zu Cloud. Ich wollte eine günstige Lösung die nicht abhängig von einem Hersteller oder dem Internet ist. Am Beispiel von der Junkers TR 21 möchte ich euch erklären wie meine Therme so schlau wurde wie mit Tado für ein Zwanzigstel des Preises (Kosten zum Zeitpunkt des Schreibens: Tado 199€)

Mein Thermostat arbeitet mit einer 1-2-4 Schaltung von Junkers die recht simpel ist:

  1. + / 24V
  2. PWM / Signal
  3. – / GND

1 und 4 versorgen das Thermostat mit Strom und wenn geheizt werden soll, trennt es die Verbindung von 2 und 4 und die Gastherme geht an. Es wird also nur ein Relais benötigt das sich klug verhält!

Nachdem ich erst Sonoff* als Idee hatte, fiel meine Wahl ziemlich schneller auf den Shelly 1. Zum einen muss s nicht erst geflasht werden um ohne Cloud zu funktionieren und zum anderen kann es direkt mit 24-60V betrieben werden und braucht somit keine externe Stromversorgung! Kostenpunkt: 9,90€ beim Hersteller oder für ein paar Euro mehr von Amazon, dafür schneller und ohne Versandkosten.

Sicher ist sicher: Vorher messen ob die Spannung stimmt

Auf meiner Schaltung lag etwas mehr auf als erwartet, ist für das Shelly 1 aber kein Problem. Wie oben direkt beschrieben arbeitet es mit einer Spannung zwischen 24 und 60 Volt.

Damit wäre auch schon die Hardware fertig. Zum Thema Software gibt es natürlich zig Möglichkeiten der Steuerung, bei mir kommt Home Assistant zum Einsatz. Da gibt ein fertiges Addon für die Integration von Shelly und ein „Generisches Thermostat“ was auf Basis eines Sensors (Bei mir ein Xiaomi Bluetooth Thermometer) eine Heizung regelt bis eine bestimmte Temperatur erreicht ist. Toleranzen lassen sich genau konfigurieren wie ein Abwesenheitsmodus. Eingebunden in Automatisierungen wie z.B. das Verlassen der Wohnung entfaltet die Heizung nun ihr volles Potential!

Beispiel für die Konfiguration in Home Assistant:

climate: 
platform: generic_thermostat
 name: Heizung
 heater: switch.gastherme
 target_sensor: sensor.mitemp_bt_temperature
 away_temp: 17Code-Sprache: YAML (yaml)
Shelly 1 angeschlossen
Shelly in Aktion mit Siri

Synology Surveillance Station Kamera mit Alexa nutzen

Smart Home

Eine ganze Reihe von Smart Home Kamera ist ja schon mit Amazons Alexa kompatibel*. Aber ich denke ich bin nicht der einzige der ungern seine Kamerastreams über irgendwelche Server von ausländischen Firmen laufen lässt, sondern sowas gerne im Intranet behält. Bei mir zuhause nutze ich dafür ein NAS von Synology mit der Surveillance Station und ein paar billige Xiaofang Kameras von Xiaomi (16€ bei Gearbest*).

Nun wäre es natürlich irgendwie cool, wenn man die Kamera Streams auch auf Alexa Geräten sehen könnte. Jaja, Alexa in der Cloud und Kameras im Intranet? Ja, das geht! Ähnlich wie z.B. dieser Skill* Alexa eure lokalen Medien abspielen lässt, könnt ihr mit Monocle eure internen Kameras auf kompatiblen Geräten* wie dem Echo Show, Echo Spot, Fire TV (Sticks) und Fire Tablets anschauen.

Anleitung

  1. Loggt euch auf eurem Synology NAS in die Surveillance Station ein, öffnet „IP-Kamera“
  2. Klickt mit der rechten Maustaste auf eure Kamera und wählt „Stream-Pfad freigeben“ aus
  3. Wählt im Dropdown-Menü „Gültigkeitsdauer“ den Wert „dauerhaft“ aus
  4. Klickt auf „ok“, und führt Schritt 2 erneut aus, sonst wird kein neues Passwort erzeugt…
  5. Kopiert den Link aus dem Feld „RTSP“:Tipp: Testet z.B. im VLC Player, ob der Link auch wirklich funktioniert
  6. Registriert euch beim Portal von Monocle
  7. Legt einen neuen Kamera-Feed an. Die Felder sind eigentlich alle selbsterklärend, falls ihr nicht sicher, seid welche Auflösung oder Codecs im Stream stecken, nutzt z.B. die Funktion „Medien-Informationen“ vom VLC Player. Wichtig ist, dass ihr im Feld „Tags“ den Wert „@Proxy“ eingebt, dazu mehr in Schritt 8. Hier sind meine Einstellungen bei Monocle und meine Medien-Informationen aus dem VLC:

    Hinweis: Laut Wikipedia entspricht A-law der G.711 Richtlinie.

  8. Installiert das Monocle Gateway. Hinter dem Link findet ihr alle Downloads und gut dokumentierte Anleitungen für Windows und Linux (macOS ist in Arbeit), es gibt auch Builds für ARM damit ihr es z.B. auf einem Raspberry Pi laufen lassen könnt. Ich habe das Monocle Gateway zum Zeitpunkt dieses Artikels in der Version 0.4.4 am Laufen.
  9. Aktiviert den Alexa Skill von Monocle und verknüpft euren Amazon Account mit dem Monocle Account*
  10. Lasst Alexa nach Geräten suchen und startet dann die Anzeige, indem ihr „Alexa, zeige [Kamerabezeichnung]!“ sagt. Ergebnis:

Das ganze ist immer noch in Beta. Teilweise musste ich das Gateway mehrmals neustarten bis alles klappt, manchmal muss ich Alexa auch mehrmals bitte die Kamera anzuzeigen.

IFTTT Actions im Intranet mit Adafruit IO & MQTT

IoT

Ich freue mich immer wenn Entwickler von IoT Geräten Möglichkeiten einbauen auf Ereignisse zu reagieren. Bestes Beispiel ist der Echo*, dem Amazon mit IFTTT ein paar nette Trigger spendiert, z.B. wenn der Timer ausläuft oder ein Wecker losgeht.

Worüber ich nicht besonders freue, ist das diese Trigger meistens nur mit IFTTT funktionieren. Klar, Amazon versucht damit einer größere Zielgruppe von Bastlern zu erreichen als wenn Sie z.B. HTTP Requests einbauen würden. Dafür erreiche ich meine Smarthome Geräte nicht mehr, die alle hinter meiner FRITZ!Box im Intranet stehen. Während ich darauf warte das Amazon für mich diese Trigger einbaut, hab ich mich nach Übergangslösung angeschaut, wie ich (möglichst sicher) IFTTT Actions in meinem Intranet auslösen kann.

Der erste Gedanke ging natürlich an den IFTT Maker Channel, Portfreigabe im Router und ein nginx o.ä. der die Requests entgegen nimmt und Skripte ausführt. Ehrlich gesagt war mir immer etwas mulmig bei dem Gedanken Zugriff von außen in mein Intranet zu ermöglichen… Klar, mit fail2ban etc kann man vieles verhindern aber am liebsten war mir eine Möglichkeit in die andere Richtung.

Danke es sehr guten Tipps von Nils (Danke!) habe ich mir mal MQTT angeschaut, ein offenes Protokoll für M2M Kommunikation. Der häufigste Anwendungsfall im Bereich MQTT wird vermutlich sein, das Sensoren oft und ohne Aufwand Werte an einen Server schicken sollen, und Clients diese Auswerten und reagieren. Für mich besonders interessant war aber die Möglichkeit das Clients sich mit dem „Broker“ verbinden, und die Nachrichten dann in Echtzeit gepusht bekommen, es gibt kein Polling. Ein paar Sekunden Verzögerung könnte viele Aktionen schon unnütz werden lassen.

Ich habe im ersten Versuch einen MQTT Server bei CloudMQTT gemietet, und über den IFTTT Maker Channel einen PHP Datei aufgerufen die MQTT Events erstellt hat. Beim Basteln bin ich dann auf Adafruit IO getoßen. Adafruit IO bietet sogenannte Feeds. Die können auch vielen verschiedenen Quellen beschrieben werden und z.B. mit MQTT ausgelesen werden, Außerdem hat es eine native IFTTT Integration und war in meinen Tests noch ein paar Sekundenbruchteile fixer als mit PHP. Ein Applet für Alexa könnte z.B. so aussehen:

 

 

Damit wäre der Broker auch schon fertig. Als Client kann theoretisch alles fungieren; Es gibt für viele Programmiersprachen fertige Bibliotheken. Bei läuft die komplette Hausautomation auf einem C.H.I.P., und dort fast alles über Node.js. Ich hab mich deshalb auch entschieden den Client in JavaScript zu schreiben, die passende Bibliothek für Node.js trägt den passenden Namen mqtt.

So sieht mein Code im Moment aus:

var mqtt = require('mqtt');
var request = require('request');
var exec = require('child_process').exec;
var url = 'mqtts://io.adafruit.com';
var options = {
	username: 'pattyland',
	password: '*******',
};
var client = mqtt.connect(url, options);
client.on('connect', function() {
	console.log("connected");
	client.subscribe('pattyland/feeds/alexa-timer');
})
client.on('message', function(topic, message) { 
	console.log(new Date().toJSON() + " " + topic);
	switch (topic) {
	case "pattyland/feeds/alexa-timer":
		exec("/home/chip/pause-fire-tv.sh");
		request({
			url: 'http://localhost:8465/api/username/lights/4/state',
			method: 'PUT',
			json: {
				on: "true"
			}
		});
		break;
	}
})Code-Sprache: JavaScript (javascript)

Kurz erklärt:

Verbinde dich über MQTT mit io.adafruit.com und abonniere (subscribe) meinen Feed „alexa-timer“. Hier können beliebig viele Feeds abonniert werden.  Spanned wird’s dann beim Listener. Hier warte ich bis eine „message“ ankommt und schaue in welchem Feed diese gepostet worden ist, die eigentliche Nachricht ignoriere ich im Moment. Da ist hier im Intranet bin, stehen mir alle Möglichkeiten offen: In meinen Fall weise ich meine ha-bridge die Lampe Nr. 4 einzuschalten, was dazu führt das mein selbstgebautes Ambilight rot blinkt. Außerdem starte ich ein Skript dass sich via ADB mit meinem Fire TV verbindet und die Pause-Taste simuliert, damit ich den Timer nicht aus Versehen verpasse weil ein Film oder Musik läuft.

Hier ist nochmal eine kleine Grafik die den Weg von Alexa zum IoT Gerät beschreibt:

So könnte sieht das ganze dann im Ergebnis aus:

Hyperion mit Alexa steuern

IoT

Schon seit ein paar Tagen habe ich nun auch ein paar LED-Streifen hinter meinem Fernseher, die dank Hyperion auf einem Raspberry Pi* mich in den Genuss von Philips Ambilight kommen lassen. Eine Demo davon gibt’s zum Beispiel hier.

Nun steht seit kurzem auch ein Echo Dot* auf meinem Wohnzimmertisch, und ich habe natürlich direkt geschaut, welche Geräte man noch mit Alexa steuern kann, die nicht im Standardrepertoire enthalten sind.

Der „normale“ Weg über AVS, bei dem ich extern einen Dienst mit SSL-Zertifikat usw. hosten muss, kam für mich erstmal nicht in Frage. Viel besser fand ich den Ansatz der ha-bridge. Diese emuliert eine Bridge für Philips-Hue-Geräte für Alexa und lässt einen für diese beliebige Aktionen festlegen. In Kombination mit hyperion-remote, das netterweise direkt mit Hyperion ausgeliefert wird, lässt sich das ganze sehr einfach mit Alexa steuern:

  1. ha-bridge downloaden und starten (Wichtig: Java 1.8. Wenn ihr kein Google Home habt, nehmt einen Port > 1024, damit ihr keine Root-Rechte braucht)
  2. Shellscript erzeugen, das sich via SSH auf dem Computer einloggt, auf dem Hyperion läuft und mit hyperion-remote die gewünschte Farbe/Effekt einstellt. Beispiel
    #!/bin/bash ssh pi@hyper "hyperion-remote --effect 'Knight rider'"
  3. Gerät in ha-bridge anlegen, das das Skript beim gewünschten Event aufruft

DDanach muss man Alexa nur noch sagen, dass sie neue Geräte suchen soll, und nach ein paar Sekunden sollte Alexa in der Lage sein: