Tasmota flashen – leicht gemacht

Unser Haus wird nach und nach immer weiter “automatisiert”, bzw. smart. Ein Großteil der automatisierten Steuerung von Heizung, Licht, etc. wird bereits von FHEM auf einem Raspberry Pi (Affiliate-Link) gesteuert. Inzwischen auch die Weihnachtsbeleuchtung. Anstatt nun alle Lichter per Hand oder Zeitschaltuhr zu steuern habe ich diese Beleuchtungssteuerung auf Wifi-Steckdosen umgerüstet. Kostet nur minimal mehr wie Zeitschaltuhren, bringt aber u.a. den Vorteil mit dass man dank FHEM zum Beispiel den Ausschaltzeitpunkt am Morgen dem Sonnenaufgang anpassen kann oder, wenn man mal tagsüber das Licht anknipsen will das zentral mit einem Befehl an Alexa (Affiliate-Link) erledigen kann.

Nun kocht ja jeder Hersteller sein eigenes Süppchen und liefert für seine Geräte eigene Apps und eigene Cloud-Dienste. Hat man dann aber diverse Hersteller im Haus, benötigt man auch deren Apps und ist von deren Cloud-Diensten abhängig.
Gottseidank sind in fast allen Steckdosen und Schaltern ESP8266 Chips verbaut und die kann man mit etwas Löten und nem Programmierer auf ein alternatives Betriebssystem namens Tasmota flashen

Tasmota werkelt dann im eigenen WLAN ohne Cloud und wird per MQTT gesteuert.
Details dazu erspare ich mir an dieser Stelle, die findet man alle auf der Tasmota-Seite. Ebenso alle unterstützen Hardware Komponenten wie Sonoff, Shelly (Affiliate-Link) oder sogar die billigen Baumarkt-Steckdosen von OBI.
Ich gehe ebenfalls nicht darauf ein wo man welche Pins zum flashen findet, das ist bei jeder Komponente anders, aber auf der Projektseite ziemlich genau erklärt.

Was dort aber etwas umständlich beschrieben steht ist wie man Tasmota auf den ESP8266 drauf bekommt. Ich habe früher mit der Arduino IDE herum gewerkelt, dann mit diversen Programmern mit unzähligen Einstellmöglichkeiten und bin schließlich beim NodeMCU PyFlasher geblieben.
3 Einstellungen anpassen, flashen, fertig.

Und das geht so:
Programmer (Affiliate-Link) mit dem ESP8266 verbinden (findet man auf der Tasmota Seite welche Pins wo sitzen), beim Einstecken des USB-Programmers (Affiliate-Link) den ESP in den Flash-Mode setzen (dazu wird in der Regel der Pin GPIO0 mit Ground beim Einstecken verbunden und kann dann getrennt werden), Das Programm starten, (1) COM-Port auswählen , (2) Firmware auswählen (die man vorher auf der Tasmota-Seite geladen hat), (3) Baud-Rate wählen (115200), (4) Flash-Mode auf “Dual Output (DOUT)” stellen, (5) “Erase Flash” auf “yes” und (6) “flash NodeMCU” klicken.
Nach 2-3 Minuten ist das Flashen erledigt und man kann beginnen Tasmota zu konfigurieren.

Auch das ist kinderleicht. Das Device neu starten (GPIO0 kann jetzt offen bleiben) und ein offenes WLAN namens “tasmota”, gefolgt von einer Nummer, suchen und verbinden. Man wird aufgefordert das Netzwerk zu bestätigen und wird auf die erste Konfigurationsseite von Tasmota gelenkt. Dort gibt man die Zugangsdaten seines WLAN-Netzwerkes ein, startet das Device neu und kann ab dann das Device neu aufsuchen und konfigurieren.
Aber das alles zu erklären sprengt diesen Rahmen, man findet alle möglichen Einstellungen auf der Tasmota-Webseite.

FHEM – Homematic Heizkörperthermostat mit externem Temperatursensor peeren

Homematic Heizkörperthermostat HM-CC-RT-DN

Vor einiger Zeit habe ich angefangen unser Haus “smart” zu machen. Für die Automatisierung habe ich mich für das Projekt FHEM entschieden welches auf einem kleinen Raspberry Pi 3 werkelt und daher ohne Hersteller-Clouds klar kommt. FHEM arbeitet mit sehr vielen Hersteller-Protokollen zusammen und ist umfangreich editierbar. Allerdings setzt es einen gewissen Grad an Programmierkenntnissen voraus. Und manchmal findet man die Lösung für seine Probleme nicht immer sofort sondern über mehrere Quellen verteilt.
So erging es mir z.B. als ich meine Homematic Funk-Heizkörperthermostate HM-CC-RT-DN nachträglich mit externen Temperatursensoren verbinden wollte. Die Homematic-Sensoren lassen sich zwar unabhängig von FHEM mit den Thermostaten peeren, kosten aber ne Menge. Und da XIAOMI seine Aquara Sensoren für sehr schmales Geld anbietet stand für mich schnell fest: die sollen es werden.
Die nun folgende Prozedur funktioniert aber auch mit anderen externen Sensoren so lang sie in der Lage sind ihre Werte an FHEM zu übermitteln.

XIAOMI Aqara SensorEin Blick ins FHEM-Wiki verspricht: kinderleicht. *hust*
Dort wird das Peering nur “husch-husch” beschrieben. Allerdings gibt es ein paar Klippen zu umschiffen bis alles so läuft wie gewünscht. Nachdem ich über mehrere Quellen mir alle Informationen zusammen getragen habe schreibe ich sie hier mal nieder. In erster Linie für mich für weitere Sensoren, aber vielleicht hilft es dem ein oder anderen ebenfalls.

zum peeren mit externen Sensoren muss man sich in FHEM ein virtuelles Homematic-Device (in meinem Fall fürs Wohnzimmer) anlegen. den Teil <Homematic-Id> ersetzt man durch eine beliebige, 6stellige Zahl die in Zukunft als eigenständige “Adresse” des Device dient.

define Wohnzimmer_virt_Temperatur CUL_HM <Homematic-Id>

Dem Device einen virtuellen Kanal hinzufügen:

set Wohnzimmer_virt_Temperatur virtual 1

Da das kein virtueller Knopf sondern ein Sensor ist benennen wir das mal um:

rename Wohnzimmer_virt_Temperatur_Btn1 Wohnzimmer_virt_Temperatur_Sensor1

Ich füge das Device nun dem Raum “Heizung” hinzu (ist aber nicht erforderlich)

attr Wohnzimmer_virt_Temperatur_Sensor1 room Heizung

Das Device muss nun noch wissen mit wem es die Daten kommuniziert, in meinem Fall ist das ein nanoCUL

attr Wohnzimmer_virt_Temperatur IODev nanoCUL

Das Attribut “expert” bitte löschen.

deleteattr expert

Nun wird das virtuelle Device mit meinem Thermostat gepeert. Bei den Thermostaten macht man dies über den Kanal 01 Weather

set Wohnzimmer_virt_Temperatur_Sensor1 peerChan 0 Wohnzimmer_Heizung_Weather single set

 

Bevor man nun weiter macht sollte man (nein, man muss) dringend warten bis das Peering abgeschlossen ist. Man erkennt es daran dass im Status des Thermostat CMDs_done steht und mit dem Befehl

set hm peerXref

das Peering in beide Richtungen eingetragen ist. das sieht dann so aus:

 

 

Sollte das Peering in beide Richtungen nicht abgeschlossen sein dann den letzten Schritt

set Wohnzimmer_virt_Temperatur_Sensor1 peerChan 0 Wohnzimmer_Heizung_Weather single set

so lang wiederholen bis beide Richtungen zu sehen sind.
Im Grunde genommen kann man nun schon überprüfen ob Daten vom virtuellen Device ans Thermostat übermittelt werden.
Mit

set Wohnzimmer_virt_Temperatur_Sensor1 virtTemp 30

sollte nach kurzer Zeit in FHEM beim Thermostat im Weather-Channel bei state  nach kurzer Zeit die 30 angekommen sein.

Gut, nun müssen wir aber noch die Werte vom XIAOMI (oder anderem) Sensor automatisiert zum Thermostat bekommen.
Das macht man per “at”
In meinem Fall sieht das so aus:

define at_Wohnzimmer_virt_Temperatur at +*00:05 { my $T=(ReadingsVal("Sensor_Wohnzimmer","temperature",20.0));; fhem "set Wohnzimmer_virt_Temperatur_Sensor1 virtTemp $T";;}

Damit wird alle 5 Minuten der gemessene Temperaturwert vom “Sensor_Wohnzimmer” (mein XIAOMI Aqara) an das virtuelle Device (welches wir gerade erstellt haben) übergeben und schlussendlich dank Peering ans Thermostat übergeben.
Ich verschiebe nun noch das at in den Raum “Zeitschaltuhren”

attr at_Wohnzimmer_virt_Temperatur room Zeitschaltuhren

 

Der Übersichtlichkeit wegen nun noch mal alle Schritte ohne Erklärung und mit verkürzten Namen nacheinander:

define wz_vTemp CUL_HM&nbsp;<Homematic-Id>
set&nbsp;wz_vTemp virtual 1
rename&nbsp;wz_vTemp_Btnl&nbsp;wz_vTemp_Sensor1
attr&nbsp;wz_vTemp_Sensor1 room Heizung
attr&nbsp;wz_vTemp IODev nanoCUL&nbsp;
deleteattr expert
set&nbsp;wz_vTemp_Sensor1 peerChan 0 WZ_Heizung_Weather single set
define at_wz_vTemp at +*00:05 { my $T=(ReadingsVal("Sensor_WZ","temperature",20.0));; fhem "set wz_vTemp_Sensor1 virtTemp $T";;}
attr at_wz_vTemp room Zeitschaltuhren

Nun sollte alles laufen.