Raspberry Pi Backup jetzt mit Mailbenachrichtigung

Im Beitrag zum automatisierten Backup vom Raspberry Pi tauchte irgendwann mal die Frage auf ob man nicht eine Mailbenachrichtigung einbauen könnte die einem Bescheid gibt sobald das Backup gelaufen ist.

Ich hab mir einige Methoden angeschaut und mich für die simpelste entschieden: sSMTP.
Um das zu installieren loggt man sich per SSH ein und installiert wie folgt:

sudo apt-get update && sudo apt-get install ssmtp mailutils

Nach der Installation muss das noch mit dem Editor nano konfiguriert werden.

sudo nano /etc/ssmtp/ssmtp.conf

Hier trägt man dann seine Daten für den SMTP-Mailversand ein. Im Beispiel zeige ich mal die Einstellungen für GMAIL. Bei anderen Providern kann das aber anders aussehen.

root=postmaster
mailhub=smtp.gmail.com:587
hostname=raspberrypi
FromLineOverride=YES
AuthUser=DEINEMAILADRESSE@gmail.com
AuthPass=DEINPASSWORT
UseSTARTTLS=YES

Du nutzt GMX?
Dann nimm folgende Einstellungen:

root=postmaster
mailhub=mail.gmx.net:465
hostname=raspberrypi
FromLineOverride=NO
AuthUser=DEINEMAILADRESSE@gmx.DE
AuthPass=DEINPASSWORT
UseTLS=YES

Es gibt dort noch eine weitere Option namens # rewriteDomain=your.domain. Damit kann man eine andere Domain als Absender erscheinen lassen, aber wir wollen das hier ja nur zum Versand an sich selber nutzen. Also einfach so lassen.

Natürlich kann man das Ding noch viel weiter konfigurieren, aber um ganz simpel ne vordefinierte Mail nach dem Backup raus zu jagen langt das hier.
Details findet man auf der Entwicklerseite.

Kurzer Test ob der Mailversand vom Raspberry (Affiliate-Link) funktioniert und dann kann es schon los gehen. Einfach mal folgendes in die Konsole eintippen:

echo “Dies ist eine Testnachricht” | mail -s “Betreffzeile Testnachricht” DEINETESTMAILDRESSE@BEISPIEL.de

Wenn das geklappt hat kannst Du auch schon die Mailfunktion in das Backup-Script einbauen.

Ich gehe mal davon aus dass Du das Backup-Script wie in meinem Beispiel aufgesetzt hast, dann rufst Du es mit dem nano Editor auf.

sudo nano /usr/local/bin/Backup.sh

Dort fügst Du ganz unten folgende Zeilen ein:

# Mail versenden
echo "Dein Backup war erfolgreich" | mail -s "Raspi-Backup" DEINEMAIL@ADRESSE.com

Oder eben was bei Dir stehen soll. Sogar HTML wäre im Nachrichtentext möglich.
Dann den Editor mit STRG+X schließen, das Speichern mit Y und ENTER bestätigen und ab sofort bekommst Du ne Mail sobald das Backup abgeschlossen wurde.

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.

Der “Notfall”-Taster – eine FHEM-Spielerei

Für “spezielle” Notfälle

Nachdem ich in unserem Bad einen Abluftventilator eingebaut und die Steuerung feuchtigkeitsabhängig mit FHEM in die Hausautomation eingebunden habe kam mir die “Schnapsidee”: Was ist eigentlich wenn man auf dem “Thron” hockt und ein Notfall eintritt? (Muss ich das wirklich näher erläutern 😉 ) Das ließe sich doch bestimmt mit Trick 17 und FHEM lösen…

Die erste Idee versuchte meine Frau dann niederzuschmettern mit dem Argument “Dafür haben wir doch dieses Raumspray Brise One Touch“.
Aber ich wäre nicht ich wenn ich dafür nicht eine Gadget-Lösung erfinden könnte. Und das Argument meiner Frau brachte mich auf eine noch größere Idee – eine Verbindung aus beidem!!!. Also ran ans Werk!

mit Fritzing zusammen gepfuscht

Zuerst habe ich mir Gedanken gemacht wie ich überhaupt ein Signal absetzen kann damit die Hausautomation den Lüfter aktivieren kann. Da bei mir bereits MQTT auf dem Raspberry läuft wollte ich auf das System setzen. Im Keller lagen noch ein paar Bauteile wie Taster und ESP8266 herum mit denen man das realisieren könnte. Ähnlich einem Dash-Button von Amazon habe ich dann einen WLAN-Taster gebaut der eine MQTT-Message absetzt. Anregungen dazu findet man zu Hauf im Netz, ich habe mich für die allereinfachste Variante entschieden: Ein ESP8266 der im Deepsleep schlummert, auf Tastendruck auchwacht, eine bestimmte Message absetzt und wieder in den Deepsleep zurück fällt. Bevor jetzt gemault wird “warum denn der ESP8266 12e? Der ESP-01 langt doch vollkommen!”: Ja, der langt, aber ich hatte aus einer Falschlieferung noch ne Menge 12e übrig und da musste ich auch keine Stifte auslöten 😉  (Pinouts für den 12e und den ESP-01)
Die Schaltung ist nicht zu 100% perfekt (man könnte am Taster noch nen PullDown-Widerstand einsetzen), für meinen Anwendungszweck aber ausreichend und bisher hatte ich noch keine Ausfälle. Ebenso könnte man die Batterie durch eine andere Variante tauschen, aber auch hier wollte ich es so einfach wie möglich haben und habe mich für 2 AAA-Batterien entschieden. Aktuell habe ich einen Satz seit rund 7 Monaten in Betrieb und die Spannung langt immer noch für die Schaltung.

Nun zur Software auf dem ESP. Grundlage hierfür war ein Script von Andy Wolff welches ich für meine Zwecke etwas “ausgedünnt” habe (Ich brauche nicht alle Funktionen).

Was macht das Script? Durch Tastendruck den ESP aus dem Deepsleep aufwecken, MQTT-Message mit Schaltzustand und Batteriespannung absetzen, ESP wieder in den Deepsleep setzen. (Moment, hatte ich das nicht schon erwähnt?)

Script auf den ESP flashen, testen, weiter geht es.

Natürlich würde das jetzt schon langen um den Lüfter zu aktivieren. Aaaaber: meine Frau sprach ja was von “Raumspray”. Das muss natürlich auch mit integriert werden.
Also ein Gehäuse entwerfen wo Batterien, der ESP nebst Taster und so eine Brise One Touch Kartusche rein passen UND auch noch zusammen aktiviert werden können!
Gemessen, gemessen, gemessen und in Fusion360 konstruiert. Nach einiger Zeit war dann die Grundplatte fertig und mit dem 3D-Drucker gedruckt. Schaltung eingebaut, Deckel gedruckt, Taster etwas “feingetunt” (Ich hab ein Stück Zellkautschuk drüber geklebt um den Druck etwas abzufangen) und ausprobiert: fertig.

 

 

 

 

 

Ist nicht schick aber funktional. Die Dateien für den 3D-Drucker könnt ihr bei Thingiverse downloaden (ihr findet dort auch einen Deckel ohne Schriftzug).

In FHEM wird die MQTT_Message  mittels eines MQTT-Device ausgelesen und in meinem Fall mit einem DOIF ein Watchdog-Timer gesetzt der den Badlüfter für 5 Minuten aktiviert (hier: Fall ## 1)

## 1
([Paniktaster] eq "ON" )
(set Watchdog_Paniktaster on-for-timer 300)
(set Bad_Luefter on)
## 2
DOELSEIF
([Sensor_Badezimmer:humidity] > 70)
(set Bad_Luefter on)
## 3
DOELSEIF
([Watchdog_Paniktaster] eq "off" and [Sensor_Badezimmer:humidity] < 70)
(set Bad_Luefter off)

Fertig!

 

 

 

 

 

Nachtrag 17.10.2023

Damit ich mich selber wieder dran erinnern kann wie ich das oben genannte Script angepasst habe.
Ja, ich hab heute echt lang dran gesessen (weil ich es vergessen habe wie ich das gemacht habe) das für einen Umzug auf einen anderen MQTT-Broker zu ändern.
Also kopiere ich mir die angepasste Version hier noch mal her:

 

#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <WiFiClient.h>
//###########################################################################
#define button 12 // Pin for Webupdate
#define mqtt_user “MQTTUSERNAME” //MQTT Broker User
#define mqtt_password “MQTTPASSWORT” //MQTT Broker Password
//###########################################################################
// Wifi
const char* ssid = “WLAN-NAME”; //WLAN SSID
const char* password = “WLAN-PASSWORT”; //WLAN Password
// MQTT
const char* mqtt_server = “127.0.0.1”; //IP Address MQTT Broker
const char* mqtt_clientId = “dashbutton1”;
const char* outTopicMsg = “dashbuttons/dashbutton1/message”;
const char* outTopicVCC = “dashbuttons/dashbutton1/vcc”;
// Misc
char msg[50]; // message for mqtt publish
//###########################################################################

ADC_MODE (ADC_VCC); // VCC Read

WiFiClient espClient;
PubSubClient client(espClient);

void setup(){
pinMode(button, INPUT_PULLUP);
Serial.begin(115200);

// Setup Wifi
setup_wifi();

// Setup MQTT
client.setServer(mqtt_server, 1883);
}

void setup_wifi() {
int wifiCounter = 0;
delay(10);
// We start by connecting to a WiFi network
Serial.println();
Serial.print(“Connecting to “);
Serial.println(ssid);
WiFi.begin(ssid, password);

while (WiFi.status() != WL_CONNECTED) {
if(wifiCounter < 10){
delay(500);
Serial.print(“.”);
}else{ESP.deepSleep(0, WAKE_RFCAL);}
wifiCounter++;
}
}

void reconnect() {
// Loop until we’re reconnected
while (!client.connected()) {
Serial.println(“Attempting MQTT connection…”);
// Client ID connected
if (client.connect(mqtt_clientId, mqtt_user, mqtt_password)) {
Serial.print(mqtt_clientId);
Serial.println(” connected”);
// Once connected, publish an announcement…
client.publish(“outTopic”, “connected”);
} else {
Serial.print(“failed, rc=”);
Serial.print(client.state());
Serial.println(” try again in 5 seconds”);
// Wait 5 seconds before retrying
delay(5000);
}
}
}

//###########################################################################

void loop(){
// MQTT Client
if (!client.connected()) {
reconnect();
}
client.loop();
// Read the VCC from Battery
float vcc = ESP.getVcc() / 1000.0;
vcc = vcc – 0.12; // correction value from VCC

if(digitalRead(button == HIGH)){
client.publish(outTopicMsg, “ON”);
delay(50);
client.publish(outTopicMsg, “OFF”);
delay(50);
dtostrf(vcc, sizeof(vcc), 2, msg);
client.publish(outTopicVCC, msg);
delay(50);
ESP.deepSleep(0, WAKE_RFCAL);
}

}

Backup des Raspberry Pi im laufenden Betrieb

Auf meinem Raspberry Pi läuft die Hausautomatisierung FHEM. Diese kann von Haus aus schon Backups von sich selbst anlegen, allerdings laufen auf meinem Raspberry noch weitere Dinge im Hintergrund die ich garantiert bei einem Wechsel der SD-Karte vergessen würde neu aufzusetzen. Und dann sitz ich wieder da, mache dicke Backen und weiß nicht warum der Quark nicht läuft.

Also habe ich für mich beschlossen dass ich liebe die komplette SD-Karte als Backup ablege. Das kann man nun mit verschiedenen Methoden veranstalten. Einerseits könnte man mit Software wie Win32 Disk Imager an einem Windows PC die Karte klonen wozu ich aber jedes Mal den Raspberry herunter fahren müsste, die SD-Karte raus pfriemeln und ins Lesegerät stecken müsste.
Praktischerweise kann so ein Raspberry mit dem “dd Kommando”  sich auch selber klonen und das Backup auf einen externen USB-Stick, oder wie in meinem Fall, dieses auf ein externes NAS legen.

“dd” würde ein Image auf der SD-Karte anlegen was aber totaler Quatsch wäre, wie käme man bei einem Defekt dann an die Daten? 😉
Also müssen wir ein externes Laufwerk “mounten”. Das bedeutet, wir gaukeln dem Raspberry vor dass das externe Laufwerk, welches wir beim Mounten verknüpfen ein Verzeichnis auf dem Raspberry sei.

Und das geht so:
Mit Putty auf dem Raspberry einloggen.
Als erstes legen wir nun das Verzeichnis an welches als Verbindungspunkt laufen soll.

sudo mkdir /backup

Als nächstes folgt die Verknüpfung mit dem externen Laufwerk. In meinem Fall ein externes NAS im Keller welches Benutzername und Passwort benötigt, die Backups sollen später im Verzeichnis “backup” abgelegt werden (muss schon existieren):

sudo mount -t cifs -o user=meinBenutzername,pass=MeinBenutzerPasswort //192.168.178.123/backup //backup

Dabei muss dann entsprechend Benutzername, Passwort und IP-Adresse bei Euch angepasst werden.

Damit bei jedem Neustart des Raspberry das Laufwerk auch wieder neu gemounted wird muss noch per Crontab ein Job angelegt werden. Dazu gehe ich aber später ein, wir müssen eh noch im Crontab einen Job anlegen.

Nachtrag vom 16.12.2020:
Das mit dem Crontab kann man sich getrost schenken wenn man den Mount-Prozess in fstab einträgt. Dazu weiter unten mehr.

Um einen USB-Stick zu mounten muss man etwas anders vorgehen, da hängt es unter anderem davon ab welchen Typ man benutzt. Da verweise ich auf dieses Tutorial, es würde hier zu lang werden.

Nun benutzen wir ein Script welches recht komfortabel die Backups erstellt und, wenn eine bestimmte Anzahl an Backups vorhanden ist, das älteste löscht.
Dazu einfach den Editor nano starten:

sudo nano /home/pi/Backup.sh

Hier nun das Script (Quelle:  Raspberry-tips) hinein kopieren und folgende Variablen anpassen:

  • BACKUP_PFAD – Pfad zum verknüpften Laufwerk (in unserem Fall /backup)
  • BACKUP_ANZAHL – Wieviele Backups sollen aufbewahrt werden?
  • BACKUP_NAME – Name der Sicherung
  • DIENST_START_STOP – Dienste die vor dem Backup gestoppt und dann wieder gestartet werden. Das ist zum Beispiel ziemlich wichtig wenn u.a. ein MySQL-Server mit drauf läuft, es gibt sonst korrupte Datenbankeinträge. Hat man keine wichtigen Dienste laufen kann man die Zeilen 11 und 17 mit einer Raute auskommentieren.
#!/bin/bash
 
# VARIABLEN - HIER EDITIEREN
BACKUP_PFAD="/pfad/zum_backup_order"
BACKUP_ANZAHL="5"
BACKUP_NAME="RaspberryPiBackup"
DIENSTE_START_STOP="service mysql"
# ENDE VARIABLEN
 
# Stoppe Dienste vor Backup
${DIENSTE_START_STOP} stop
 
# Backup mit Hilfe von dd erstellen und im angegebenen Pfad speichern
dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB
 
# Starte Dienste nach Backup
${DIENSTE_START_STOP} start
 
# Alte Sicherungen die nach X neuen Sicherungen entfernen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd

Abspeichern mit STRG+X, Y und Enter. Das Script muss nun ausführbar gemacht und verschoben werden:

sudo chmod 755 /home/pi/Backup.sh
sudo mv /home/pi/Backup.sh /usr/local/bin/Backup.sh

Kommen wir nun zum Crontab. Mit Crontabs können zeitgesteuert Prozesse gestartet werden.
Dazu den Crontab-Editor öffnen mit:

sudo crontab -e

Unter der letzten Zeile einen neuen Job anlegen mit

00 01 * * * /usr/local/bin/Backup.sh

Damit wird jeden Tag um 1 Uhr früh ein Backup gestartet.
Wer sich selber andere Zeiten oder nur für bestimmte Tage die Woche ein Backup anlegen möchte schaut sich mal den crontab guru an, da kann man sich seinen Zeitplan recht komfortabel zusammenstellen und dann die Zeile kopieren.

Nun noch speichern mit STRG+X, Y und Enter und schon laufen zur gewünschten Zeit die Backups.
Für meine 8 GB SD-Speicherkarte dauert ein Backup etwa 9 Minuten. Ich lasse die Backups 2x wöchentlich laufen jeweils morgens um 3 Uhr.
Mein Job dazu sieht dann wie folgt aus:

00 03 * * 1,5 /usr/local/bin/Backup.sh

Ich sprach ja vorhin davon dass wir bei den Crontabs noch einen weiteren Job wegen des Mounts anlegen müssen. In eine weitere Zeile fügt ihr folgendes ein:

@reboot mount -t cifs -o user=meinBenutzername,pass=MeinBenutzerPasswort //192.168.178.123/backup //backup

Passt auch hier wieder ggf. Eure IP, Pfade und Name/Passwort an.

Nachtrag vom 16.12.2020:
Ich erwähnte ja weiter oben schon dass man sich den Quatsch mit dem mounten per Crontab schenken kann. Dazu muss der Mount nur in die Datei /etc/fstab eingetragen werden. Dann wird der Mount bei jedem Neustart ausgeführt.

sudo nano /etc/fstab
dort in die unterste Zeile folgenes eintragen:
//192.168.178.xx/Backup /Ordner/fuer/NASVerbindung cifs username=HorstKevin,password=meingeheimesPasswort,uid=1000,gid=1000,dir_mode=0700,file_mode=0600,nounix,vers=1.0 0 0

Achtung! Diese Zeile passt nur für mein System, bei Euch müssen ggf noch Änderungen vorgenommen werden wie IP, Dateipfad, Username, Passwort, Filetyp etc.
Das hier ist auf ein Sambashare auf meinem Synology-Laufwerk ausgelegt. NFS würde vermutlich komfortabler laufen, funktioniert bei mir derzeit nur nicht so recht. Da bin ich noch auf der Fehlersuche.
Um das mit dem fstab besser zu verstehen verweise ich auf eine deutschsprachige Hilfeseite zum Thema:
https://wiki.ubuntuusers.de/fstab/ 

 

 

Und was macht man nun im Fall des Falles um das Backup zurück zu spielen?

Einfach das Image vom NAS mit dem Programm Win32 Disk Imager (oder einer anderen Software zum Bespielen von Images auf SD-Karten) auf eine frische Speicherkarte spielen, einstecken, Rasperry booten, fertig.

 

+++++++++++++++++++++++++++++++++++++++++++++
Update vom 26.12.19
Vor einiger Zeit hat jemand nach der Möglichkeit der Mailbenachrichtigung gefragt. Ich hab das mal hinzugefügt. Wie das geht findet man in diesem Artikel.
+++++++++++++++++++++++++++++++++++++++++++++
Und noch ein Update:
Wer seine Archive gezippt ablegen möchte tauscht einfach die Zeile

dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB


gegen diese aus:

dd if=/dev/mmcblk0 bs=1MB status=progress | gzip > ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img

Zurückspielen kann man das mit:

gunzip -c ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d).img | dd of=/dev/mmcblk0

+++++++++++++++++++++++++++++++++++++++++++++
Update vom 16.12.20
Ich hab den Beitrag etwas editiert, das Mounten per Crontab ist Unfug. das kann man besser per fstab erledigen.

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.

Anet A8 – mein neues Spielzeug

Mein Schätzelein

Schon seit einiger Zeit beschäftigte ich mich mit dem Thema 3D-Druck. Aber bisher war immer nur Gucken und Stöbern angesagt, solche Geräte sind zum “Herumspielen” einfach zu teuer. Dann entdeckte ich am Black Friday 2016 dass Gearbest der Anet A8 (Ein Prusa I3-Clone) massiv im Preis gefallen war: unter 150 Dollar! Ok, das ist zum Basteln akzeptabel! Und da Gearbest über “Germany Priority Line” versendet entfallen zum einen die Einfuhrumsatzsteuer (bereits inkl) und die Versandzeit liegt bei etwa 2 Wochen.

Nun mus man aber wissen dass da ein Bausatz kommt. Nix mit “Auspacken, Einschalten, Geht” (Halt, das war doch mal ein Werbeslagan…). Man muss das echt große Puzzle anhand einer fiesen Anleitung aus chinesischer Hand zusammenbauen. Aber: man bekommt das hin. Ich habe mir etwas Zeit gelassen und 3 Tage später stand das Schätzelein fertig auf dem Schreibtisch. Die ersten Probedrucke waren schon echt super. Was mir aber sehr gefällt ist dass es eine große Fan-Community drumherum gibt und man sich auch viele der Verbesserungsteile wie Rahmen und Zubehör für den Drucker selber ausdrucken kann was die Druckergebnisse deutlich erhöht.

Eine nicht ganz ernst zu nehmende Warnung sei aber gesagt: Preislich wird es nicht bei der Anschaffung für den Drucker bleiben. Einige Teile wie z.B. Kugellager für die Filamentspulen, Gleitlager, besseres Netzteil, Ersatzdüsen usw. werden dazu kommen. Aber jedes Upgrade verbessert die Qualität. Auf die Ersatzteile gehe ich später ein.

Was aber unbedingt zu erwähnen ist:
Die chinesischen Hersteller haben es in Sachen Elektrik nicht ganz genau und man liest immer wieder von Verschmorungen bis hin zu Bränden. Das habe auch ich schon gesehen und man muss da zwingend an einigen Stellen nachbessern, sonst raucht einem ratzfatz die Bude ab. Dazu gehören u.a. Adernendhülsen, bessere Schraubklemmen, Power-Mosfets oder SSR und ein vernünftiges Netzteil. Das verhindert zwar immer noch keinen Brand, aber es gibt einem mehr Ruhe. Denn was da an Strömen fließt und welche Temperaturen herschen ist nicht zu unterschätzen und sollte nicht auf die leichte Schulter genommen werden.

Was habe ich nun alles schon geändert?

in der Ecke werkelt ein Raspberry Pi

Angefangen bei den Adernendhülsen, die Schraubklemmen habe ich bei mir weg gelassen weil ich sowohl fürs Heizbett als auch den Extruder die Mosfets eingesetzt habe. Dann kann man die Klemmen auf dem Mainboard belassen. Da ich mit dem Original-Netzteil angefangen habe kam noch ein Netzschalter dazu. Die passende Abdeckung kann man drucken. Für den Austausch liegt hier aber schon ein Servernetzteil herum welches man 1a dafür umbauen kann. Dazu schreibe ich in einem anderen Artikel mehr. Sucht einfach bei ebay nach dem HP DSP-600, das gibt es in gebraucht schon ab 15,-.
Als nächstes habe ich einen Raspberry Pi 3 hinzugefügt. Der ist nicht zwingend erforderlich, der Drucker kann auch von der SD-Karte aus drucken, aber auf dem Raspberry läuft bei mir die Software Octoprint zur komfortablen Verwaltung des Druckers nebst einer Webcam so dass ich auch vom Sofa aus bequem schauen kann was der Drucker macht. Zusätzlich kann die Software die gesamte Elektrik per Funk nach dem Druck ausschalten (Steckdose & Funkmodul f. Raspberry).
Außerdem habe ich einen Autolevelsensor verbaut. Der erleichtert zwar das Ausleveln des Heizbettes ungemein, aber dazu muss man zwingend die Firmware auf dem Mainboard neu flashen. Dabei ist allerhand zu beachten. Ich verweise dazu auf die deutschsprachige Facebook-Gruppe, dort findet man alles dafür benötigte und alle Fragen werden i.d.R. kompetent und freundlich beantwortet. Trotzdem zu meiner Konstruktion: durch das Glasbett benötigte ich einen kapazitiven Sensor, wer mit BlueTape arbeitet braucht einen anderen.

Dank Schrank herrscht Ruhe

Damit ich meine Ruhe habe (ja, der rappelt schon ein wenig) habe ich den Drucker in einen STUVA Schrank von Ikea eingebaut. Für den gibt es ne passende Glastür und Ruhe ist. Und um noch ein wenig mehr Ruhe zu haben steht der Drucker auf ner Dämmmatte.
Es gibt diverse Bauanleitungen wie man sich aus 3 Ikea LACK Tischen und allerhand Plexiglas einen Schrank bauen kann, aber schlussendlich ist das genauso teuer wie mit STUVA und man hat deutlich mehr Aufwand.
Zu guter Letzt habe ich noch die minderwertigen Kugellager gegen IGUS Gleitlager ausgetauscht, damit flutschten die X & Y-Achse und man muss nix ölen. Achtung, für X und Y benötigt man insgesamt 7 Stück.

Das Filament wird von oben zugeführt

Auf dem Heizbett liegt bei mir eine Glasplatte die ich aus einem billigen Bilderrahmen zurecht geschnitten habe. Die meisten schwören auf BlueTape oder Borsilikat, aber ich habe mit dem billigen Bilderrahmen bisher immer gute Erfahrungen gemacht.

Es gibt noch viiiele Dinge die man verändern könnte, aber mir langt das bisher.
Gut, was ich mir noch zusätzlich auf Halde gelegt habe sind ein paar Düsen und Extruderröhrchen. Naja, und halt Filament in einigen Farben. Ich habe mit dem PLA-Filament von eSun angefangen. Das ist vom Preis her ganz ok und liefert mir bisher gute Ergebnisse.

Zum Schluss liste ich noch mal die Teile auf die ich mir als Verbesserungen gedruckt habe. Auch da gibt es noch viel mehr, aber eins nach dem anderen. 😉

Ich werde diese Liste die Tage noch erweitern weil einiges von mir konstruiert wurde und noch nicht bei Thingiverse verfügbar ist.

Was gibt es noch anzuklicken?

Auch diese Liste werde ich die Tage noch erweitern.

 

 

 

Treiber für Arduino Nano Clones

469521107_1280x720Wer sich beim “Chinamann” (z.B. Aliexpress oder Banggood) Arduino Nano Clones kauft steht recht flott vor dem Problem dass diese Clones nicht vom PC erkannt werden.
Das liegt daran dass dort statt der FTDI-Chips die deutlich preiswerteren CH340G USB 2 Serial Chips verbaut wurden.
Dies führt beim Upload von Sketches auf den Arduino zu Fehlermeldungen.
Die Clones benötigen einen eigenen Treiber. Diesen findet man kostenlos im Netz unter dem Namen CH340SER.EXE oder auch unter dem Namen CH341SER.EXE.

Ich habe für mich den Treiber hier im Blog als Backup gespeichert. Dieser funktioniert bei mir hervorragend, ich übernehme dafür allerdings weder Garantie noch Haftung. Der Download erfolgt auf eigenes Risiko.

Bevor man den Arduino mit dem PC verbindet:

  • Treiber downloaden (und ggf entzippen)
  • Setup starten
  • Die Software fragt dann nach ob sie den Treiber CH341SER.INF für den Chip CH340 (Version 11/04/2011, 3.3.2011.11) installieren darf, ‘INSTALL’ klicken
  • Nach Installation erfolgt noch eine Windows-Meldung dass der Treiber erfolgreich installiert wurde
  • Den Arduino Nano per USB verbinden
  • Im Gerätemanager findet man dann den Eintrag “USB-SERIAL CH340 (COM XX)” bei XX steht dann welcher COM-Port benutzt wird
  • In der Arduino Software entsprechend den COM-Port einstellen, fertig

Raspberry Pi – der neue “Freund des Hauses” zieht bei mir ein

Raspberry Pi LogoNachdem Junior bei den Projekttagen von Jugend hackt voller Begeisterung erst von einem Raspberry Pi sprach und kurze Zeit später sein Taschengeld dafür zusammen kratzte habe ich mich auch mal dafür interessiert. Aber wie das so ist, beim “nur mal für interessieren” bleibt es ja meist nicht…

 

Weiterlesen