Homematic Firmwareupdate

Viele der Homematic Geräte können mit neuer Firmware "OverTheAir" versorgt werden. Manchmal werden neue Features eingebaut (Steckdose Verhalten nach Spannungswiederkehr), manchmal Fehler ausgebügelt (Thermostat Hysterese war nicht einstellbar). Ob man das Firmware Update braucht muss jeder selbst wissen. Alle Einstellungen, Peerings und Register bleiben erhalten.
Das Firmwareupdate erzeugt kein Werksreset!

FHEM hat eine fwUpdate Funktion eingebaut, wie man die verwendet will ich hier kurz schildern. Bei meiner Installation waren über die Jahre doch ca. 8 Geräte auf altem Stand.

Versionsprüfung

Zunächst mal muss man wissen, dass es neue Firmware gibt. Im Wiki ist dafür die Einrichtung eines HTTPMOD Devices beschrieben. So sieht dann das Ergebnis aus:

Wie man sieht, wird damit täglich nach neuer Firmware geschaut und die angelernten Geräte überprüft.
Da hier ziemlich selten Updates erfolgen habe ich das Zeit Interval auf 518400 (6 Tage) hochgesetzt und über das Attribute alignTime einen Zeitpunkt in der Nacht gesetzt. Damit wird der Server bei eq3 nicht so sehr oft abgefragt.
Über reread kann der Vorgang manuell gestartet werden, Die Gerätenamen sind direkt klickbar um die Geräte dann zu bearbeiten. Zuvor kann man die roten Versionsnummern klicken und die neue Firmware herunterladen. Für das Update müssen die Dateien auf dem FHEM Server lokal vorliegen.

Vorbereitung der Firmware Dateien

Die Firmwaredateien werden gepackt geliefert, sicher gibt es viele Wege, ich gehe so vor:
Mit WinScp werden die Dateien nach /home/pi übertragen.
Mit Putty verbinden und im Terminal eingeben:

tar -xvzf /home/pi/<Dateiname>.tar.gz
sudo cp *.eq3 /opt/fhem/FHEM/firmware/

Man kann natürlich auch direkt ins firmware Verzeichnis entpacken:

sudo tar -xvzf /home/pi/<Dateiname>.tar.gz -C /opt/fhem/FHEM/firmware/

Der user fhem muss nur lesen können, dies sollte mit den vorhandenen Berechtigungen funktionieren.

Vorbereitung in FHEM

Sollte man mehrere IOs haben sind weitere Vorbereitungen notwendig. Hat man nur ein FHEM mit einem IO der fwUpdate beherrscht, kann man direkt loslegen.
Ich habe zusätzlich zu meinem produktiven System mit einem HMLAN und einem RPI Modul noch ein Test System mit einem RPI Modul.
Um zu vermeiden, dass das Testsystem stört habe ich den IO mit set <> close geschlossen und mit dem attr <> dummy 1 komplett aus dem Rennen genommen.
Der HMLAN kann kein fwUpdate, ich bin mir nicht sicher ob das alle wissen. Deshalb müssen wir dafür sorgen, dass nur ein IO das Update durchführt.
Ich habe eine VCCU im Einsatz, deswegen habe ich bei den Geräten wo ich ein Update durchführen will einfach den preferred IO gesetzt:

attr <> IOGrp VCCU:HMUART1

Update durchführen

Unbedingt die RSSI Werte kontrollieren, die sollten wenigsten so bei Mitte 60 liegen. Bei schlechteren Werten muss der IO temporär näher an das Gerät gebracht werden.
In der Weboberfläche können wir jetzt das Update starten, den Dateinamen kann man zur Sicherheit mit kompletten Pfad angeben. Dazu einfach in WinScp mit der rechten Maustaste auf die Datei und dann Dateiname/Kopieren mit Pfad den kompletten Namen kopieren und in der Box einfügen:

set <> fwUpdate </Pfad/Dateiname>

Die LED (falls sichtbar) am Gerät sollte jetzt wild anfangen mit blinken, der Vorgang dauert etwas.
Als Quittung wird ein Reading fwUpdate done erzeugt.
Allerdings steht in den Readings und dem Attribute nach wie vor die alte Firmware. Den neuen Eintrag (und damit die Erfolgsquittung) erhält man nur mit einer Anlernmessage:

set HMUART1 hmPairSerial <Serial des gerade aktualisierten Gerätes>
set <> getConfig

Alternativ, oder falls das nicht funktioniert, kann man die Configtaste drücken.

Zum Abschluss wird mit hmInfo configCheck alles nochmal kontrolliert.
Vor dem nächsten Update in kurzer Folge schauen ob der IO sich im overload befindet.

Fehler

Es sind unterschiedliche Fehler möglich:
In den Readings wird eine Fehlernachricht angezeigt, Update ist nicht gestartet. Da stimmt wahrscheinlich irgendeine Grundlage nicht.
Das Gerät landet im Bootloader / Bootloop
Da hat was mit der Firmware nicht gestimmt oder der Vorgang wurde vor dem Ziel abgebrochen. Nicht ganz so schlimm, allerdings braucht man jetzt mit Sicherheit ein paar Versuche. fwUpdate versetzt das Gerät als erstes in den Bootloader, kontrolliert und startet dann den Datentransfer. Man muss es schaffen, dass das Gerät sich mit dem Bootloader meldet wenn fwUpdate es erwartet. Andernfalls bricht er mit einem Fehler ab.
Ich hatte Erfolg mit dieser Reihenfolge:
Gerät ausschalten.
fwUpdate starten und danach sofort das Gerät mit Strom versorgen/Bootloader starten.
Bei overload vom IO einfach warten bis der overload vorbei ist.

Raspberry Pi als einfacher Router

Man kann den Raspberry mittels USB Adapter mit zusätzlichem Netzwerk Interfaces ausrüsten Wlan oder auch Ethernet. Der Raspberry Pi 3 hat schon eine Wlan Schnittstelle an Board.
Folgende USB Adapter habe ich im Einsatz, die werden auf Anhieb ab debian wheezy erkannt und lassen sich problemlos betreiben.
- i-tec USB 2.0 Advance 10/100 Fast Ethernet LAN Network Adapter USB 2.0
- TP-Link TL-WN725N WLAN Nano USB-Adapter (150 Mbit/s, Soft AP)

Vorbereitung 

Seit debian jessie hat die Konfiguration der Netzwerkschnittstellen etwas geändert. Einfach etwas in der /etc/network/interfaces eintragen ist nicht mehr. Über diese Seite habe ich die entscheidenden Hinweise gefunden. Der Dienst DHCP Client Deamon übernimmt die Konfiguration der Schnittstellen, eine Ethernet Schnittstelle die nicht über einen DHCP Server konfiguriert wird, bekommt von ihm eine Adresse aus dem Pool 169.254.0.0 zugewiesen.
Eine statische Konfiguration erfordert nicht mehr die Veränderung der Datei /etc/network/interfaces, diese bleibt unbedingt Original! Stattdessen wird die Konfiguration in der Datei /etc/dhcpcd.conf durchgeführt. Dabei sind die Einträge ähnlich der alten Methode.

sudo nano /etc/dhcpcd.conf

Minimal wird dort die IP Adresse für das Interface eingetragen:

interface eth1
static ip_address=192.168.1.1/24

Ein ifdown eth1 && ifup eth1 sollte die Änderung im laufenden Betrieb ausführen.

Router einrichten

DHCP

Der Router wird mit einem Interface an den vorhandenen Netzwerk/Internetanschluss angeschlossen und erhält von dort per DHCP seine Konfiguration.
Das zweite Interface  soll selbst mit einem DHCP Server versorgt werden.
Ziel ist es den Router einfach in ein bestehendes Netzwerk einfügen zu können.

In Frage kommt sicher isc-dhcp-server aber der dnsmasq schein noch etwas besser für diese Aufgabe zu sein. Die Anregung stammt von hier.

sudo apt-get update && sudo apt-get install dnsmasq

In der Datei /etc/dnsmasq.conf enthält die gesamte Doku und am Ende werden die Parameter eingetragen:

interface=eth1
no-dhcp-interface=eth0
dhcp-range=interface:eth1,192.168.1.100,192.168.1.200,12h

Manchmal startete der Deinst dsnmasq mit Fehlern, da muss ich noch etwas tun. Verzögern?

Portweiterleitung und NAT

Zwei Einstellungen führen dazu, das sich unser Router auch wie erwartet verhält und sämtlichen Traffic aus dem Netzwerk eth1 zum Netzwerk eth0 "routet".

Mit diesem Befehl wird IP-Forwarding sofort aktiviert

sudo sysctl -w net.ipv4.ip_forward=1

Um das IP-Forwarding dauerhaft zu aktivieren muss die Datei /etc/sysctl.conf editiert werden.

sudo nano /etc/sysctl.conf

Entweder suchen wir nach der Stelle und entfernen das #

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

Oder wir  fügen am Ende einfach die Zeile hinzu

net.ipv4.ip_forward=1

Man kann auch die Datei editieren und mit sudo sysctl -p die Änderung sofort wirksam werden lassen.

Jetzt können wir zwar in das andere Netzwerksegment pingen, aber der Internetrouter wird keinerlei Anfragen aus dem eth1 wirklich beantworten. Damit dies ohne Neukonfiguration im bestehenden Netzwerk funktioniert brauchen wir NAT:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Allerdings müssen diese Einstellungen noch gespeichert werden, sonst sind sie beim nächsten Neustart weg.

Speichern in eine Datei iptables-save > /etc/iptables_01.save
Um diese beim Start zu aktivieren:

nano /etc/network/interfaces

Unterhalb von iface lo inet loopback einfügen

pre-up iptables-restore < /etc/iptables_01.save