In FHEM ein Homematic Gerät neu anlegen lassen

Wenn man der Meinung ist, dass ein Homematic Gerät in FHEM falsch oder unvollständig angelegt ist, kann man es relativ leicht "neu machen". Wichtig ist, dass das Gerät schon gepairt ist.
Sind selbst gesetzte Attribute vorhanden sollte man diese sichern. Peerings gehen nicht verloren, sie sind im Gerät gespeichert.

Arbeitsschritte

1. Bei Bedarf Raw definition des Gerätes und der Channels kopieren und sichern (unterste Zeile unter der Gerätedefinition) 
2. Die Seriennummer des Gerätes kopieren -> D-serialNr!
3. Alle Definitionen die mit dem Gerät zu tun haben (also auch die Channels) einfach löschen -> delete this device (ganz unten neben Raw definition).
4. Mit einem set <io> hmPairSerial <D-serialNr> sollte das Gerät neu angelegt werden. 
5. Eventuell noch ein set <Gerät> getConfig absetzen.
6. Je nach Gerät muss die Datenübertragung ausgelöst werden (Anlerntaste, Aktion)
7. Das Gerät bei Bedarf umbennen, alle HM Definitionen kennen den Befehl set <> deviceRename. Damit werden auch die Channels umbenannt.

Hat man mal aus Versehen ein Gerät gelöscht, oder will alles neu aufbauen: Wenn die autocreate Funktion in FHEM aktiv ist und man die Anlerntaste am Gerät drückt, wird die Definition neu angelegt. Man kann dann ab Punkt 4 einsteigen und alles perfekt machen.

Wenn man mit dem Vorgehen größere Sachen macht: Unbedingt mit hmInfo configCheck die "Lage" von Zeit zu Zeit prüfen.

Flashen eines Arduino nano direkt vom Rasberry

Liegt der Code für einen Arduino nano schon im hex File vor, ist es relativ simpel ihn am raspberry direkt zu flashen. Man braucht lediglich das Tool avrdude, Port über welches der Arduino nano angeschlossen ist. Die Bitrate mit der geflashed wird ist 57600 bit/sec.

Installation

Als Erstes muss man avrdude installieren:

sudo apt-get update && sudo apt-get install avrdude

Man benötigt keine besonderen Berechtigungen zum Start von avrdude.

Port ermitteln

lsusb -t 

liefert die Anzeige mit Port in einer Baumstruktur. Daraus lässt sich meist das Device (Chipsatz) und die Portnummer direkt ablesen. Wenn man mehrere gleiche USB Chips angeschlossen hat und die Portbezeichnung seines Gerätes nicht kennt, muss man den Arduino nano abziehen und wieder anstecken und in beiden Situationen lsusb - t ausführen.

ls -l /dev/serial/by-path/

liefert die Anzeige mit Port und logischer Zuordnung (ttyUSB*)

Aus beiden Angaben lässt sich zuverlässig die Portbezeichnung ablesen. Am einfachsten wird das Port in der Form /dev/ttyUSBx angegeben.

Das hexfile ist entweder relativ zum aktuellen Pfad oder besser mit absolutem Pfad anzugegeben.

Programmaufruf

avrdude -p atmega328P -b57600 -c arduino -P [PORT] -D -U flash:w:[HEXFILE]

ESP8266 12F

Ein 32 bit Prozessor, 4MByte Speicher, digitale GPIO und ein ADC Eingang und WLAN - das alles auf 2 cm². Dazu einfachste Programmierung - fast zu einfach!?

Das eigentliche kleine Modul ist natürlich erstmal schwer zu handhaben. Man braucht 3,3 Volt Betriebsspannung, USB Serial Wandler.
Aber es gibt ja fertige Boards, ich habe verschiedene ausprobiert. Die kann man einfach mit micro USB Kabel anschließen und es kann sofort losgehen. Aber wie? Je nach dem welches Modul man kauft hat man eine bestimmte Firmware vorinstalliert. Welche genau ist nicht immer vorhersehbar, vielleicht auch nicht wichtig.
Die Basisversion auf dem Modul kann mit einigen AT Befehlen gesteuert werden.

Ich würde das Wemos D1 mini bevorzugen und mit ESP Easy oder NodeMcu LUA arbeiten. Aber da muss ich mich noch ein wenig einarbeiten. ESP Easy ist aber wirklich ganz easy und vor allem auch schnell an FHEM angebunden.
Wahrscheinlich kann man mit ESPEasy ganz leicht ein paar Sensoren und unterstützte Geräte anbinden aber mit LUA die Dinge tun die darüber hinausgehen.

Verschiedene Module

Ich habe folgende Module ausprobiert:
ESP12E DEVKIT V2 von doit.am obwohl dort ESP12E dran steht ist ein ESP12F Modul drauf. Vorinstalliert ist eine LUA Firmware. Leider ist mein Modul eventuell kaputt. Es lässt alles mit sich machen, aber bei ESP Easy überlebt es den Power Reset nicht.
Wemos D1 mini von wemos.cc auch dies kommt mit NodeMcu Lua Firmware vorinstalliert. Außerdem liegen dem Modul zwar alle Stift- und Steckerlisten bei, sie sind aber nicht verlötet. Das Modul erscheint mir die zweckmäßigste Version zu sein!
LoLin NoneMcu V3 von wemos.cc wobei man auf der Seite nicht zu diesem Modul findet. Vorinstalliert ist eine AT Firmware. Es ist mechanisch gesehen das größte Modul meiner Serie - und damit fast unbrauchbar: Auf dem typischen Breadboards mit 2 x 5 Pins in Reihe belegt es die komplette Breite und begräbt die freien Kontakte unter sich. Damit kann man nichts mehr anschließen, man braucht eine großes/breites Breadboard.
Witty Board für die "witzige Wolke". Dieses Board ist zweiteilig gestapelt, auf dem Hauptmodul ist nur der ESP12F und der Stromanschluss angebracht. Als kleines Spielzeug ist in den Ecken eine RGB LED und ein Photowiderstand verbaut. Damit ist der ADC Anschluss schon belegt und 3 GPIO Pins. Auf der zweiten Platine ist USB Adapter untergebracht. Mann kann also die Hauptplatine nach dem Flashen/Programmieren trennen und mit 5 Volt Spannungsversorgung betreiben.
Das Modul hat eine Gizwits APP Firmware installiert, die ist aus meiner Sicht zu nichts zu gebrauchen.

Alle Module haben einen Reset Knopf um das Modul neu zu starten.
Nur das Wemos D1 mini hat keinen Flashtaster, den man aber eigentlich sowieso nie braucht.
Der ADC Eingang ist teilweise mit einem Spannungsteiler 3:1 beschaltet.

Die Module haben alle einen Spannungsregler AS1117 an Board. Soweit ich das verstanden habe, wird auch der USB-Seriell Chip CH340 mit 3,3 Volt gespeist. Damit sind alle Module eventuell sehr tolerant an VIN bzw VCC und es müssen nicht exakt 5 Volt anliegen wenn man nicht über die USB Schnittstelle speist. Zumindest bei den beiden großen Boards habe ich auch Angaben gefunden 4,5 - 10 Volt, theoretisch kann der AS1117 bis zu 15 Volt.
Das ESP12F Modul an sich ist nicht tolerant -> nur 3,3 Volt anschließen!

Firmwareversionen

AT Firmware

Geholfen hat mir diese Seite
Dazu braucht man das Flash Download Tool von ESPRESSIF und die aktuelle AT Firmware in Form des NONOS SDK von dieser Seite. Die latest Version auswählen un dann findet man das Download ganz unten auf der Seite unter Attachments.
Hat man das SDK entpackt wechsel man in den Pfad .\bin\at\ dort befindet sich eine Readme welche Datei auf welche Speicheradresse zu flashen ist. Für einen ESP-12F wählt man 4(5) Dateien aus:

eagle.flash.bin           -> 0x00000
eagle.irom0text.bin       -> 0x10000
blank.bin                 -> 0x7e000
blank.bin                 -> 0x3fe000
esp_init_data_default.bin -> 0x3fc000

Defaultwerte lassen, aber FLASH-SIZE auf 32 Mbit stellen. COM Port richtig einstellen!
Mit wenigen Befehlen ins Netzwerk:

AT
AT+GMR
AT+CWMODE=1
AT+CWJAP="SSID","Password"
AT+CIFSR

Diese Einstellung wird sofort auch gespeichert und überlebt ein Power Reset.

NodeMCU Firmware

Die Firmware NodeMCU bringt eine LUA - Scriptsprache basierte Umgebung.
Die Firmware und alle Tools kann man von dieser Seite beziehen. Man muss sich die Firmware aber aktuell immer "bauen" lassen. Der Einstieg für diesen unkomplizierten und vollautomatischen Prozess findet sich hier.
Für den Umgang und das Handling der Programme gibt es eine Java basierte Software namens ESPlorer. Den Umgang mit diesem Tool fand ich irgendwie sehr fremd.
Dieser Artikel hat mir dabei geholfen. Der NodeMCU Flasher ist relativ einfach zu bedienen und kann wie alle anderen Flasher natürlich auch andere bin Dateien flashen.
Die NodeMCU Firmware formatiert beim ersten Start den FLASH Speicher, so das alle alten Reste entfernt werden.
Mit wenigen Befehlen ins Netzwerk:

wifi.setmode(wifi.STATION)
wifi.sta.config("SSID","Password")
ip = wifi.sta.getip()
print (ip)

Diese Einstellung wird nicht gespeichert, dazu müsste man einen Datei init.lua anlegen. Dies ist ein Init Script welches beim Neustart abgearbeitet wird. Hier finden sich viele Beispiele im Netz.

ESP Easy

Von Let's Control It gibt es die wohl am einfachsten zu bedienende Firmware. In dem verlinkten Wiki Artikel findet man alles, inklusive der Firmware. Die Firmware ZIP Datei enthält auch einen Flashtool, die Datei flash.cmd wird einfach gestartet und fragt drei Parameter ab: COM Port, Speichergröße in MByte und zu flashende Version.
ESP Easy startet eine Webserver, man konfiguriert die Verbindung zum eigene Wlan und nach einem Neustart kann man beginnen.
Achtung:  Bei diesem Flashvorgang werden die Einstellungen für das WLAN nicht überschrieben! Fehlerhafte Konfigurationen kann man damit nicht löschen!
Die Entwicklung dieser Software und auch der Webseite schreiten offenbar sehr dynamisch voran. Falls die Links nicht funktionieren: http://www.letscontrolit.com/ und dann zu ESP Easy scrollen und dort Wiki klicken. Download oder Software Links sucht  man auf der Homepage vergebens.
Mit wenigen Schritten ins Netzwerk:
WLAN mit der SSID ESP_0 suchen (manchmal auch ESP_0xxx)
Browser öffnen falls dies nicht automatisch geschieht, man landet sofort auf auf einer Webkonfigurationsmaske. SSID und Passwort eintragen.
Nach dem Neustart des Moduls kann man sich auf die IP Adresse oder auf http://newdevice verbinden.
Will man das Ganze in den Ursprungszustand versetzen (Reset) dann muss man sich mit einem seriellen Monitor verbinden und "blind" Reset (reset) eintippen. Man darf bei putty ctrl+m ctrl+j (CR LF) nicht vergessen.
Man hat leider kein lokales echo.
Es kann einen Moment dauern, bis der Vorgang mit FLASH:  Erase Sector: ... quittiert wird.
Nach dem Abschluss des Löschens erfolgt ein normaler Boot im AP Modus.

GizWits Firmware

Das sogenannte Witty Modul bringt eine eigene Firmware mit. Hier habe ich ein paar Infos dazu gefunden. diese Firmware ist dafür gedacht sich mit einer App zu verbinden und dann über eine Cloud etwas zu konfigurieren/programmieren. Aus meiner Sicht "witzlos". Das Modul ist offenbar für den chinesischen IoT Markt gedacht. man sieht ein paar Konsolen Ausgaben bei 115200 bps aber bedienen lässt sich nichts. Das Modul spielt selbständig etwas mit seiner RGB LED.

Tipps und Tricks

Firmware flashen

Der Speicher des ESP8266 ist in bestimmte Bereiche aufgeteilt und die Firmware ist auch OTA flashbar. Damit wird beim flashen nicht automatisch alles überschrieben. Also nicht wundern wenn die WIFI Konfiguration noch im Flash steht, obwohl man per USB geflashed hat und gehofft hat damit alles zu überschreiben.

Speichergröße

Zu allen Angaben zu Speichergrößen muss man beachten, dass manchmal von Mbit und manchmal von MByte gesprochen wird. Die kleinsten ESP hatten 4 Mbit= 512kByte Speicher. Der ESP8266 12F hat 32 Mbit=4MByte Speicher. Also nicht fälschlicherweise die Anleitung für 4 Mbit lesen obwohl man 4 MByte hat.

Wiederbelebung

Wen man sich mal "verflashed" hat - hilft die Baudrate der Schnittstelle auf 74880 bps (ich habe auch Angaben zu 76800 bps gefunden) zu stellen.
Dies ist die Baudrate vom "first bootloader".
Offenbar gibt es Situationen wo sich das Programm zum flashen nicht mehr auf eine Baudrate mit dem ESP Baustein einigen kann.
Der Nodemcu Flasher kann das im Dialog (Advanced).

Serielles Terminal

Womit kann man jetzt ganz einfach mal über die COMx Schnittstelle mit dem ESP kommunizieren?
Nicht besonders komfortabel geht es auch über putty. Ich habe das Programm ja ständig beim Wickel als ssh Konsole für meine Himbeeren.
Also bei der Verbindung die serielle Schnittstelle auswählen. Dabei neben der Geschwindigkeit vor allem darauf achten: Flow control auf none zu stellen.
Will am AT Befehle eingeben müssen die mit ctrl+m (CR) und ctrl+j (LF) abgeschlossen werden. Enter würde ctrl+m bringen, ctrl+j müssen man manuell nachlegen.
Das zu automatisieren ist für die Eingabe leider nicht vorgesehen, nur bei der Ausgabe ist das konfigurierbar (Terminal Einstellung).
Als Standardgeschwindigkeit haben alle meine Boards mit 115200 bps gearbeitet.

Treiber

Alle Boards sind mit dem CH340xx Chip ausgestattet. Beim ersten Anstecken an den Windows Rechner wird zwar ein USB2 serial Chip erkannt aber kein Treiber gefunden. Einfach auf dieses Gerät klicken, Treiber aktualisieren ausführen und den vorher lokal entpackten Pfad verweisen.
Die Seite ist in chinesisch, aber den download Button kann man erkennen: http://www.wch.cn/download/CH341SER_ZIP.html

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

Ferrariszähler abtasten - ein Experiment

Mit ein paar Widerständen zwei LEDs und einem Phototransistor durch eine Scheibe aus gebührenden Abstand zuverlässig die nur Millimeter starke, rotierende Scheibe abtasten und dabei einen roten Punkt erkennen? Kann das funktionieren? Ich habe es nach dieser Anleitung ausprobiert und tatsächlich - es funktioniert! Dank eines Arduino nano und einer cleveren Software.

Der schnelle Aufbau

In einen kleinen Plastestreifen von 15 x 50 mm habe ich ziemlich mittig zwei 3 mm Löcher im Abstand von 5mm gebohrt. Diese dienen als Aufnahme für IR LED und Phototransistor. Mit einem 4 adrigen ungeschirmten Kabel, knapp 1 meter lang, habe ich beide Elemente über einen 4 poligen Pfostenverbinder mit dem Breadboard verbunden.
Auf dem Breadboard ist der Arduino nano mit den Widerständen und der Status LED platziert. Also alles in wenigen Minuten zusammengebaut.
Den Sketch habe ich direkt vom Github heruntergeladen und mit der Arduino IDE auf den nano aufgespielt.
Nun wird es spannend: wird die Schaltung funktionieren?
Der serielle Monitor der IDE lässt uns einen ganz schnellen Test machen. Der nano meldet sich mit der aktuellen Einstellung
Trigger levels: 50 100
Mit einem großen C schaltet er in den Command Mode und meldet sich mit einem Prompt >
Mit einem großen D zeigt er anschließend fortlaufen die Messwerte.
Mit einem Stück weißen Papier oder einem glänzenden Gegenstand als Reflektor kann sollten die Messwerte irgendwie zwischen 5 und 200 schwanken.
Ok, das funktioniert, jetzt muss der Sensor eingestellt werden.

Montage und Einrichtung

Ich habe den Strich für die Bohrungen gleich in die Oberfläche geritzt, diesen Strich verwende ich jetzt um den Sensor möglicht exakt mit der Ferraris Scheibe auszurichten. Die im Bild gezeigte Methode mit Panzertape verändert ihre Lage innerhalb weniger Stunden! Also nur als schnelle Probe geeignet!
Der Sensor wird mit dem Breadboard verbunden und der nano mit meinem im Schaltschrank vorhandenen Raspberry. Um die Messwerte mitzuschreiben um später die Triggerschwellen festzulegen verwende ich minicom.

sudo apt-get update && sudo apt-get install minicom

Mit minicom kenne ich mich erstmal gar nicht aus, aber das Programm ist interaktiv bedienbar:

minicom -s

startet minicom im Setup Mode. Wir müssen folgendes einstellen:

• Serial port setup
• Serial Device /dev/ttyUSB1
• Bps/Par/Bits 9600 8N1
• Hardware Flowcontrol No
• Exit

Jetzt mit C und D in die kontinuierliche Datenausgabe versetzen, die Messwerte scrollen durch. Wenn nicht die Einstellung überprüfen!

Mit CTRL-A und Z öffnen wir den Hilfemodus öffnen, von diesem kann man das Programm auch weiter bedienen. L öffnet den Capture Modus, wir müssen bloß noch den Dateinamen bestätigen und schon zeichnet minicom die Messwerte auf, per default ins aktuelle Verzeichnis mit dem Namen minicom.cap. Wir müssen jetzt ein 3-4 Runden der Ferrarisscheibe aufzeichnen. 

Mit CTRL-A (Z) und L kann der Capturemodus anschließend mit close und damit die Datei geschlossen werden.

Mit WinScp kann man die Datei auf den PC kopieren, in minicom.txt umbenennen und anschließend in Excel oder Google Tabellen importieren (beide weigern sich eine Datei mit der Endung .cap zu importieren!?).
Jetzt markiert man die Spalte mit den Werten und fügt über das Menü / Einfügen / Diagramm eine Kurve ein.
Die Kurve kann man etwas aufzoomen und ganz leicht die beiden Trigger Punkte bestimmen. Im Anzeigemodus des Diagramms der Google Tabelle kann man mit der Maus die einzelnen Punkte anzeigen lassen.
Beispielauswahl 130 175

Zurück zu minicom und wieder mit C in den Command Modus wechseln. Jetzt geben wir mit S 130 175 die Triggerschwellen ein. Nun wechseln wir wieder in den Trigger Mode mit T.

Fertig!

Ich habe jetzt einfach den Ausgang mit der Status LED (D12) mit einem Pin meines ArduCounter nano verbunden ein neues Pin definiert und schon habe ich den Zähler in FHEM eingebunden. 

Mein Zähler liefert 75 Impulse pro kWh (Zählerkonstante). 

Der Zählerwert (kWh) ergibt sich damit aus: Impulsanzahl/75 

Für die Momentanleistung braucht man die Impulsdauer (Zeit für 1 Umdrehung) damit kann man daraus allgemein ableiten:

Leistung im Watt = 3.600.000 / (Zählerkonstante * Anzahl der Sekunden für eine Umdrehung)

Damit steht in meinem Beispiel eine Runde für 48.000 Ws 

Momentanleistung (Watt) = 48000/Impulsdauer (sec)

Ideen zur endgültigen Umsetzung

Der eigentliche Sensor ist störunempfindlich, man kann ihn also wirklich vom Arduino absetzen und damit einen kleine Sensor machen der einfach mit Klebepads auf der Zählerfront befestigt wird.
Neben der hier gezeigten einfachen Variante der Kopplung mit dem ArduCounter, will ich versuchen alles in einem Arduino unterzubringen. Mal sehen ob mir das gelingt.

Mein erstes Arduino Projekt

Ständig taucht beim Lesen dieser Name "Arduino" auf, der wie ein kleiner Italiener klingt. Und die Leute schreiben dafür einen Sketch - was für mich bisher ein gespielter Witz war.
Sicher ging es auch lustig zu, in der Bar von Ivrea wo vor über 10 Jahren von zwei Italienern diese Technologie entwickelt wurde.
Es interessierte mich und ich suchte schon eine Weile ein simplere Lösung um die S0 Schnittstellen meiner Zwischenzähler endlich mal auswertbar zu erfassen. Die seinerzeit gekaufte PM2 von Allnet (ALL3691) war nur als Mäusekino zu gebrauchen und hatte zu viele Macken. Da tauchte beim Stöbern im FHEM Forum der Begriff ArduCounter auf, das wird es doch!
Die kleinen Platinen des Arduino nano gibt es in vielen Ausführungen, sie kosten wenige Euro, man kann sie direkt aus China holen - aber letztendlich brauchte ich erstmal was zum probieren, was auch sofort funktioniert! Ich habe mich etwas belesen und dann den bei Amazon bestellt: Aptotec Nano V3.0 Pro mit Org.ATmega328P/ FT232RL Chip. Ein FTDI Chip sollte er haben, damit die USB Anbindung erstmal ohne große Probleme läuft!
Wobei scheinbar alle Probleme mit dem CH340 Chip behoben sind, auch ein solcher Arduino Nano läuft ohne Probleme. Allerdings, wenn man mehrere USB Geräte betreiben möchte: siehe Abschnitt am Ende "Probleme".

Was braucht man noch?

• Ein USB Kabel passend zum Board (USB mini). Bei meinem Board war ein Kurzes dabei.
• Ein Breadboard, das ist kein Brettchen fürs Brot sondern ein Steckbrett auf dem man sich elektronische Schaltungen einfach zusammenstecken kann.
• Den FTDI USB Treiber falls der Arduino nicht beim anstecken sofort erkannt wird.
• Die IDE für den Arduino um einen Sketch zu schreiben. Es empfiehlt sich die von der arduino.cc Webseite obwohl die derzeit eine niedrigere Versionsnummer (1.6.12) trägt. Die Alternative von arduino.org ist unvollständiger.

Hardwareinstallation und Vorbereitung

Den Arduino auf Steckbrett, USB Kabel dran und los geht es. Zunächst leuchtet nur die Power LED. 

1. Zuerst im Gerätemanager schauen ob der Treiber installiert ist, es sollte eine neue COM Schnittstelle da sein, ohne Ausrufezeichen! Die Nummer merken (bei mir COM3).
2. Die IDE in ein Verzeichnis entpacken und die Arduino.exe starten. Wir benötigen keine erweiterten Rechte.
3. Die Konfiguration der IDE - Im Menü: Werkzeuge->Board "Arduino nano" wählen, dann Werkzeuge->Port "COM3" wählen.
4. Das Fenster zeigt einen leeren Sketch, so etwas wie der Grundrahmen. Für einen kleinen Funktionstest öffnen wir: Datei->Beispiele->01.Basisc->Blink
5. Jetzt einfach den Pfeil nach rechts in der Symbolleiste oder Menü->Sketch->hochladen oder Strg-U drücken. Wenn keine Fehlermeldungen erscheint wird nach wenigen Sekunden die LED des Arduino im Sekundentakt blinken. Der Arduino nano hat eine "Signal" LED die mit PIN D13 on Board verbunden ist. Neben der Power LED zeigen noch zwei LEDs die Datenübertragung der seriellen Schnittstelle an.

Meine Zähler sind schon mit RJ11 Kabeln beschaltet, für einen schnellen Test muss ich meinem Arduino nur noch ein "Interface" verpassen. Ich habe mir ein altes RJ45 Netzwerkkabel zerschnitten und die Leitungen an einen Pfostensteckverbinder gelötet. Dieses Kabel kommt aufs Steckbrett und mit zwei Drahtbrücken wird die Verbindung zu Pin 4 und 5 hergestellt. Hier muss man auf die Polung achten, viele Zähler S0 Schnittstellen sind "Open-Collector" und mit + und - bezeichnet. Das sieht alles nicht spektakulär aus, ich habe trotzdem mal ein Foto gemacht.

Zähler programmieren

Die IDE legt im Dokumente Ordner des Benutzers einen Arduino Ordner als Arbeitsverzeichnis an.

Dahin kopieren wird den Sketch "ArduCounter.ino" entweder vom contrib/arduino Ordner unsere FHEM Installation oder direkt vom github. 

Mit Datei öffnen wird die ArduCounter.ino geladen und anschließend auf den Arduino hochgeladen. Wenn keine Fehler angezeigt werden sind wir fertig, wir können den Arduino von der USB Schnittstelle abziehen.

Am FHEM Server anschließen

Bisher haben wir alles am Desktop jetzt müssen wir kurz überprüfen ob der Arduino am FHEM Server erkannt wird. Mit Putty loggen wir uns am Raspberry ein und haben den Arduino noch nicht angesteckt! 

Mit ls /dev/ttyUSB* schauen wir uns die Liste der seriellen/USB Schnittstellen an und merken die uns. Wenn bisher keine vorhanden ist wird eine Meldung ausgegeben
ls: cannot access /dev/ttyUSB*: No such file or directory. 

Jetzt stecken wir das USB Kabel mit dem Arduino und warten einen Moment. Jetzt sollte die Ausgabe mindesten eine Schnittstelle zeigen, werden mehrere gezeigt ist die neue unsere Schnittstelle, bitte wieder die Nummer merken, bei mir /dev/ttyUSB0.

Das RJ11 Kabel vom Zähler verbinde ich einfach mit einer RJ45 Kupplung mit meinem Kabel zum Steckbrett.

Einbindung in FHEM

Seit Januar 2017 ist ArduCounter Bestandteil vom normalen FHEM, vorher war es ein "contrib" Modul. Die ersten beiden Schritte sind also obsolete:
Mit putty am raspberry:

sudo cp /opt/fhem/contrib/98_ArduCounter.pm /opt/fhem/FHEM/

Auf diese Weise gehört die Datei zwar root aber es darf jeder lesen und fhem sollte damit zurecht kommen. Man kann auch noch die Rechte gerade ziehen:

sudo chown fhem:dialout /opt/fhem/FHEM/98_ArduCounter.pm

Jetzt in der Kommandozeile im Browser das Gerät anlegen:

define AC ArduCounter /dev/ttyUSB0@38400 

Jetzt noch den Messeingang definieren:

attr AC pinD4 rising pullup

Wenn alles richtig lief (Logfile) steht das Gerät auf opened und die Readings für pin4 und power4 sollten sich füllen. Mit get AC info könnte man eine Zwischenabfrage starten (Ergebnis -> Logfile).

Feintuning

Das power Reading liefert den momentane Leistung am Zähler. Damit die stimmt muss auch der Faktor stimmen. 

• Mein Zähler SMD630 liefert 400 Impulse pro 1 kWh. 
• 1 Impulse entspricht also 0,0025 kWh.
• Um den Zählerstand in kWh zu ermittteln, muss man einfach die Anzahl der Impules durch die Zahl Impulse/kWh dividieren. 
• ArduCounter ermittelt den Wert für die momentane Leistung in Impulsen/h ((delta count) / (delta time) * factor). Liefert der Zähler 1 Impuls pro 1 W/h, dann erhält man mit dem Faktor 1000 den Wert in kW angezeigt. Da mein Zähler 1 Impuls pro 2,5 W/h liefert, muss ich 2500 (statt Standardwert 1000) als Faktor einstellen.

Der folgende Abschnitt muss überarbeitet werden.

attr AC factor 2500

Ich will ja eigentlich meinen Zählerstand abbilden. Dazu definiere ich ein userReadings

attr AC userReadings Zaehler {ReadingsVal("AC","pin4",0)/400 + gggg.gg }

gggg.gg ist der Grundwert. Es ist der Zählerstand der bei Start der Zählung der S0 Impulse auf dem Zähler stand. Damit kann jederzeit der echte und der ermittelte Zählerstand abgeglichen werden.

Wenn der Arduino mal vom Strom genommen wird, dann sind die gespeicherten Impulse natürlich gelöscht. Damit man einfach den Zählerstand wieder setzen kann, habe ich mir noch einen Dummy gebaut dem ich einfach meinen aktuellen Zählerstand gebe und der rechnet dann sofort den Grundwert aus:

define ZStart dummy
attr ZStart userReadings Grundwert {ReadingsNum("ZStart","state",0)- ReadingsNum("AC","pin4",0)/400 }

Man stellt sich also einfach vor den Zähler und tippt den abgelesenen Wert in das set vom Dummy. Der Grundwert wird sofort ermittelt und das veränderte userReading von oben liest dann den Grundwert direkt aus:

attr AC userReadings Zaehler {ReadingsVal("AC","pin4",0)/400 + {ReadingsNum("ZStart","Grundwert",0) }

Fertig

Nachdem das alles ziemlich einfach war und gut läuft, muss das Ganze noch weg vom Provisorium. Es soll ja einfach so in der Verkabelung verschwinden. Also muss ein Arduino nano ohne Beinchen her. Habe ich ich doch überall gesehen und die meisten haben sich beim Kauf aufgeregt, dass sie selbst noch löten mussten. Das war dann aber doch gar nicht so einfach, vor allem stimmen denn die Produktfotos? 

Ich habe den Nano 3.0 Arduino kompatibel ATmega328P-AU 16MHz Mini USB mit CH340G V3.0 5V ICSP bei ebay bestellt, der war zumindest innerhalb ein paar Tage lieferbar. Er kam wirklich ohne Beinchen. Allerdings hat dieser eine unschöne Eigenheit: Am Ende des Hochladens des Sketches meldet er ein paar Fehler:  

avrdude: verification error, first mismatch at byte x....  0xf1 != 0xb1

avrdude: verification error; content mismatch

Sieht irgendwie aus als wäre ein bit Fehlerhaft. Es passiert offenbar beim Kontrolllesen, scheint aber kein wirkliches Problem zu sein. Das aufgespielte Programm läuft ohne Probleme. 

Ich habe eine Weile alles mögliche probiert und im Internet dazu gefunden: man könnte die Firmware tauschen, die ist eventuell fehlerhaft. Dazu bräuchte ich einen ISP Programmer. Aber außer das es "philosophisch" vielleicht interessant ist, stört es mich erstmal wenig. Ich habe einfach ein Stück RJ45 Kabel an das Board gelötet, zwei Stück Isolierschlauch drüber gezogen und fertig!
Nachtrag: Dieser Nano war wirklich defekt! Die serielle Kommunikation mit dem FHEM Modul brachte immer mal wieder unsinnige Zeichen zu Tage. Mit einem anderen Nano lief es sofort alles Fehlerfrei. An der Firmware lag es jedenfalls nicht, das USB-Seriell Chip war defekt. Ich habe mir einen neuen CH340G bestellt und diesen getauscht. Jetzt läuft auch dieser Nano wieder ohne Fehler! Klar auch das war rein Interessehalber: die Reparatur eines Nano Wert 4,49€ mit einem CH340G für 1,12 € lohnt unter wirtschaftlichen Gründen nicht wirklich. Aber ich wollte wissen ob ich den SMD Chip tauschen kann und es geht! 
Beinchen am besten mit einem kleinen Seitenschneider einzeln trennen, Reste mit dem Lötkolben herunter "wischen", neuen Chip an einer Ecke fixieren und genau positionieren, alle Pins anlöten, zuviel Zinn und Brücken sind nicht schlimm. Anschließend mit Entlötlitze großzügig "absaugen" - dabei passiert bei einigen Pins erst der wirkliche Lötvorgang!

Probleme

Die Zählung der Impulse funktionierte bei mir nicht auf Anhieb. Ich habe im laufenden Zustand den Resetknopf am Arduino gedrückt. Danach funktionierte alles wie gewollt. Das war aber ein Bug im Modul, der ist inzwischen behoben.
Hat man versehentlich falsche Pins definiert bleiben die Readings erhalten. Mit deletereading AC xxx kann man diese Readings löschen.

Sollte die USB Schnittstelle des Arduino nicht sofort erkannt werden, hilft nochmaliges Ab- und Anstecken. 

Mit lsusb kann man schauen ob die Schnittstelle überhaupt erkannt wird. 

Mit dmesg | grep FTDI könnte man schauen ob ein FTDI Chip erkannt wurde.

Es gibt wohl generell, dass Problem, dass die USB Sticks unter Linux einfach durch nummeriert werden, in der Reihenfolge wie sie erkannt werden. Was zunächst mal interessant war: Den ersten Arduino nano ab und den neuen dran - er bekommt auch wieder USB0. Bei einem einzelnen Stick kann das ja schick sein, aber bei mehr als einem?

Dazu gibt es offenbar eine Lösung "/dev/serial/by-path".
Mit ls /dev/serial/by-path/ kann man sich die gesteckten USB Stick mit kompletten Pfad anzeigen lassen.

platform-3f980000.usb-usb-0:1.2:1.0-port0
platform-3f980000.usb-usb-0:1.5:1.0-port0

Die :1 ist der interne USB Hub des Pi, die folgende Ziffer nach dem Punkt der Port (siehe unten). Steckt an Port 3 (0:1.3) noch ein Hub, kommen dessen Anschlüsse als weitere Punkt dazu (0:1.3.1:). Man kann dann meist die Ports am Hub mechanisch / logisch zuordnen.

Mit ls -l bekommt man die Info ausführlicher und sieht die Verbindung auf USBx. Die USB Nummerierung ist abhängig von der Reihenfolge der Erkennung!

Mit lsusb -t bekommt man die Port Zuordnung im Klartext.
lsusb liefert hingegen nur die Device Auskunft, die ist abhängig von der Reihenfolge der Erkennung!

 /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
        |__ Port 5: Dev 6, If 0, Class=Vendor Specific Class, Driver=ch341, 12M

Spätestens wenn noch ein USB Hub verwendet wird ist diese Auskunft auch nicht mehr "logisch", da hilft nur probieren (abziehen/stecken).

Portnummerierung am Raspberry Pi 3

ist simpel zu merken: Wie "man schreibt", die Ethernetschnittstelle ist USB Port 1. In der Mitte ist oben USB Port 2 und darunter USB Port 3, naja und klar Rechts oben ist USB Port 4 und unten USB Port 5.
   2  4
1  3  5

Um festzulegen, dass der USB Stick in einem bestimmten Port (Port 2) genommen wird, muss das define im FHEM so aussehen:

define AC ArduCounter /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0-port0@9600

FHEM in wenigen Schritten

Vorbemerkung

Achtung! Es gibt zu diesem Thema immer wieder neuere Artikel in meinem Blog!
Bitte zuerst nach diesen suchen!

Ich habe diesen Artikel immer mal wieder an aktuelle Veränderungen angepasst, trotzdem wird dieser Beitrag immer einen bestimmten Zustand repräsentieren und alle Quellen für die Installation können sich jederzeit ändern!
Das aktuelle Raspbian gibt es hier -> https://www.raspberrypi.org/downloads/raspbian/
Bitte unbedingt die "Lite" Version ohne Desktop verwenden! Der Desktop bringt unter Umständen (immer neue) nette Enduser Features mit, die später für Probleme sorgen.
Eine aktuelle Anleitung für Debian Systeme gibt es hier -> https://debian.fhem.de/
Die aktuelle allgemeine Anleitung zur Installation von FHEM findet man hier -> http://www.fhem.de/#Installation

Meine Installation

In möglichst wenigen Schritten zu einer funktionierenden FHEM Installation auf dem Raspberry Pi3 zusammen mit dem HM-MOD-RPI-PCB.
Zusammenfassung:

1. Schritt: Aktuelles Jessie Lite herunterladen. Es sind aktuell ca. 300 MB und das dauert je nach Internetverbindung. Bei mir sind es ca. 8 min und damit fast die Hälfte des gesamten Prozesses!
2. Schritt: Image entpacken (1,3 GB) und dann auf SD Card schreiben. Ich mache das immer unter Windows und nehme Win32DiskImager. Aufpassen, dass man den richtige Laufwerk erwischt! Dauert bei mir 1:48 min. Die Setup Scripts mit eigenem Inhalt (Siehe nächsten Abschnitt) bitte gleich auf die SD Card ins /boot Volume kopieren. 
3. Achtung Nachtrag: Ab Jessie 2016-11-25 ist ssh per default nicht mehr aktiv. Damit man "headless" installieren kann, muss im /boot Volume eine leere Datei mit dem Namen ssh erzeugt werden. Für den Raspberry Zero W kann man eine angepasste Datei wpa_supplicant.conf ebenfalls in das /boot Verzeichnis kopieren. Damit klappt dann headless über Wlan.
4. Schritt: Karte in den Rasberry stecken und booten. ca. 30 sec.
5. Schritt: mit ssh (putty) auf dem Raspberry anmelden und als erstes auf sudo schalten -> "sudo su" oder die Scripte in Schritt 6 jeweils mit sudo /boot/SetupX.sh aufrufen.
6. Schritt: Scripte starten /boot/Setup1.sh mit Grundkonfig und HMUART dauern inklusive einem Neustart ca. 21 sec. Die eigentliche Installation /boot/Setup2.sh dauert aus dem Repository je nach Umfang an Debian Paketen etwa 3 bis 9 min.
7. Schritt: Jetzt noch finales update, das dauert aktuell ca. 2 min mit einem Neustart von FHEM.

Alles in allem hat man nach ca. 16 Minuten einen frisch installierten Raspberry Pi. 

Mit allen Handgriffen und Wartezeiten habe ich 17:45 min gestoppt.

Hinweis: Seit der Version Raspbian Jessie vom 27.5.2016 wird "Expand Filesystem" automatisch beim ersten Start ausgeführt. Man braucht diesen Punkt also nicht mehr manuell über raspi-config ausführen. Die SD Card wird komplett genutzt (siehe weiter unten Feintuning).

Man kann mit verschiedenen Methoden FHEM installieren:

• Manual - die supportete Variante: Diese Version sollte die Standardvariante sein und ist für jeden geeignet.
• Repository - schnell und ohne Update aktuell: Wer es in einem Rutsch einfach aktuell haben will, der installiert die "Repository Version" und spart ca. 2 min. Wenn es mit dieser Variante Probleme gibt: dann unbedingt Standard installieren!
• SVN - zeitlich nahe am Entwickler: Für alle die immer ganz aktuell sein wollen, ist die "SVN Version" gedacht.

Ich habe die einzelnen Installationsschritte in den Scripten kurz kommentiert.

Scripte Setup1.sh und Setup2.sh erstellen

Mit den Script Code-Schnipseln kann sich jeder sein bevorzugtes und angepasstes Script zusammenstellen. Bitte unbedingt darauf achten mit einem Editor zu arbeiten, der im "Unix Code" abspeichern kann (nur lf als Zeilenende). Alle Scripts müssen wegen einfacher direkter Ausführbarkeit mit folgender Zeile beginnen:

#!/bin/bash

Am Ende kommt man mit zwei Scripts aus: 

• eines für die Grundkonfiguration welches mit einem reboot endet -> Setup1.sh,
• ein zweites für die Installation und Konfiguration von FHEM -> Setup2.sh.

SetupGrundkonfig

Ein paar Dinge die man auch mit raspi-config erledigen kann.

# Zeitzone
echo "Europe/Berlin" > /etc/timezone
dpkg-reconfigure -f noninteractive tzdata

# Konfigurieren lokale Sprache deutsch
sed -i -e 's/# de_DE.UTF-8 UTF-8/de_DE.UTF-8 UTF-8/' /etc/locale.gen
dpkg-reconfigure -f noninteractive locales
update-locale LANG=de_DE.UTF-8

# Hostname
h=<neuer Name>
sed -i s/raspberrypi/$h/ /etc/hosts
echo $h >/etc/hostname
/etc/init.d/hostname.sh

# Kamera aktivieren
echo "start_x=1" >> /boot/config.txt
echo "gpu_mem=128" >> /boot/config.txt
echo "disable_camera_led=1" >> /boot/config.txt

# Wlan bei Bedarf einrichten
# wpa_passphrase '<WLAN SSID>' '<WLAN Passwort>' >> /etc/wpa_supplicant/wpa_supplicant.conf
# sed -i /#psk/d /etc/wpa_supplicant/wpa_supplicant.conf 
# sed -i '/iface wlan0/a \\tpre-up iw dev wlan0 set power_save off' /etc/network/interfaces

SetupHMUART

Dieser Abschnitt ist speziell für den Einsatz des Homematic Moduls HM-MOD-RPI-PCB gedacht. Dafür muss die serielle Schnittstelle aktiviert werden und die Wechselwirkung mit Systemdiensten und dem Bluetooth Service behoben werden. Siehe auch hier.

# serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen
echo "enable_uart=1" >> /boot/config.txt 
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt 
echo "core_freq=250" >> /boot/config.txt 
sed -i 's/\bconsole=serial0,115200 //' /boot/cmdline.txt
systemctl disable serial-getty@ttyAMA0.service
reboot

Also für den Raspberry PI3 und Jessie lite kann man, wenn man es genauso will, die oberen beiden Schnipsel kopieren und in eine Textdatei Setup1.sh packen.  Dabei sind bei Bedarf die Zeilen für Kamera oder HMUART einfach wegzulassen oder auszukommentieren.

Setup FHEM

Die beiden nächsten Varianten sind auf  debian.fhem.de beschrieben.
Man kann sich entscheiden: will ich einfach ganz schnell ein aktuelles FHEM haben oder die freigegebene Version installieren und dann aktualisieren.
Wer noch nicht weiß was er mit FHEM alles anstellen will und möglichst schnell ein aktuelles FHEM installieren will, der kopiert die Zeilen aus dem folgenden Abschnitt SetupFhemRepository in eine Textdatei Setup2.sh.
Ich empfehle allen, die jetzt nicht genau wissen was sie tun sollen, die Zeilen aus dem Abschnitt SetupFhemManual zu kopieren und in eine Textdatei Setup2.sh zu packen.
Die Spezialisten können auch die SVN Version installieren. Auch hier gilt: Einfach die Zeilen aus dem Abschnitt in die Setup2.sh packen.

SetupFhemManual

Offiziell wird in größeren Abständen (ca. einmal Jährlich) ein Paket vom Entwicklerteam freigegeben. Um dies zu installieren müssen ein paar Installationsvoraussetzungen geschaffen werden. Diese Voraussetzungen können sich bei jedem neuen Paket ändern. Fehlen Software Pakete erfolgt eine  Fehlermeldung und das Paket wird nicht installiert. Die erforderliche Pakete stellen die Grundvoraussetzung dar. Je nach später eingesetzten Modulen können weitere Pakete erforderlich sein.
Die Installation mit dpkg erfordert eigentlich nur zwei Befehle. Es ist zu überprüfen ob sich die Versionsnummer zwischenzeitlich geändert hat. Ich empfehle immer die neueste Version.

Man muss neben Perl (in raspbian vorhanden) die grundlegenden Pakete für FHEM vorher selbst installieren.

# Allgemeine Pakete installieren 
#minimale Basis FHEM sind diese Pakete 
apt-get update && apt-get install libcgi-pm-perl libdbi-perl libdbd-sqlite3-perl libdevice-serialport-perl libjson-perl libwww-perl libio-socket-ssl-perl libtext-diff-perl sqlite3
#Ich benötige derzeit zusätzlich diese Pakete
apt-get install avrdude bluez libcrypt-rijndael-perl libdigest-sha-perl libgd-graph-perl libgd-text-perl libimage-info-perl libimage-librsvg-perl libjson-xs-perl liblwp-useragent-determined-perl libmime-base64-perl libnet-ssleay-perl libnet-telnet-perl libnet-telnet-perl libnet-upnp-perl libsoap-lite-perl libsoap-lite-perl libxml-parser-lite-perl mplayer mp3wrap msttcorefonts samba samba-common-bin sendemail telnet
wget http://fhem.de/fhem-5.8.deb
dpkg -i fhem-5.8.deb

Man kann mit diesem Zustand zwar arbeiten, aber unter Umständen hat man damit die Entwicklung von FHEM für einen langen Zeitraum verpasst. Um auf einen aktuellen Stand zu kommen ist ein update unerlässlich. Als nach der ersten Anmeldung gleich

update

in der Kommandozeile eingeben.

SetupFhemRepository 

Installation eines aktuellen FHEM vom letzten Tag. Hierbei werden die im vorhergehenden Abschnitt offiziell empfohlenen Pakete für FHEM automatisch alle mit installiert.
Ich habe hier im Prinzip nur die nötigen Befehle von der Original Seite kopiert. Bitte unbedingt dort nachschauen ob sich Änderungen ergeben haben!
Die sources.list wird für den Installationsvorgang angepasst und das Setup von FHEM entfernt den unnötigen Eintrag wieder (Hintergrund: FHEM ist über apt-get nicht Update fähig).

# von debian.fhem.de installieren - siehe aktuelle Anleitung dort https://debian.fhem.de/
wget -qO - http://debian.fhem.de/archive.key | apt-key add -
echo "deb http://debian.fhem.de/nightly/ /" >> /etc/apt/sources.list
apt-get update
apt-get install fhem

SetupFhemSvn

Installation der "Entwicklerversion" - aktueller geht es nicht.
Diese Variante stammt ursprünglich aus dem FHEM Forum. Ich habe lediglich entsprechend der svn Seite von FHEM den svn checkout aktualisiert. Ich beobachte diese Variante nur sporadisch. Ich fand diese Variante interessant und habe sie für mich für besseres Auffinden hier dokumentiert.

# Erstmal die empfohlenen Pakete inklusive svn
apt-get update && apt-get install perl-base libcgi-pm-perl libdevice-serialport-perl libwww-perl libio-socket-ssl-perl libcgi-pm-perl libjson-perl sqlite3 libdbd-sqlite3-perl libtext-diff-perl libtimedate-perl libmail-imapclient-perl libgd-graph-perl libtext-csv-perl libxml-simple-perl liblist-moreutils-perl ttf-liberation libimage-librsvg-perl libgd-text-perl libsocket6-perl libio-socket-inet6-perl libmime-base64-perl libimage-info-perl libarchive-extract-perl libusb-1.0-0-dev git subversion
# SVN Version holen
cd /opt && svn co https://svn.fhem.de/fhem/trunk/fhem fhem
# Benutzer manuell hinzufügen und Rechte setzen
useradd --system --home /opt/fhem --gid dialout --shell /bin/false fhem
chown -R fhem:dialout /opt/fhem
# Init Script kopieren, einrichten und bearbeiten
cp /opt/fhem/contrib/init-scripts/fhem.3 /etc/init.d/fhem
sed -i /noaptmark/d /etc/init.d/fhem
sed -i /hold/d      /etc/init.d/fhem 
sed -i /^fi$/d      /etc/init.d/fhem
chmod a+x /etc/init.d/fhem
update-rc.d fhem defaults
# Update Alias einrichten und System starten
echo 'define alias_update cmdalias update AS { `svn update /opt/fhem/` }' >> /opt/fhem/fhem.cfg
systemctl start fhem

Feintuning

Partionierung

Wer nicht die gesamte SD Card nutzen will, also die Partition für Raspbian selbst definieren will, kann die automatische Vergrößerung (seit Jessie vom 27.5.2016) abschalten:
Nachdem das Image auf der SD Card ist, aber vor dem ersten Start, wird die Datei /boot/cmdline.txt editiert. Sie sieht aktuell so aus, der rot markierte Teil ist zu löschen:
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh
Bitte nicht von hier kopieren, sondern die Original Datei editieren und die Datei im Unix Format (nur lf) speichern!

FHEM Grundkonfiguration

Unabhängig vom eigentlichen FHEM Installationsverfahren gibt es noch ein paar Dinge auf die man achten muss.
Der initialUsbCheck der beim Start von FHEM die angeschlossenen USB Geräte erkennen soll führt manchmal auch zu Problemen. Wenn man ihn nicht braucht kann man ihn auch gleich abschalten.

# Der USB Check macht manchmal Probleme
echo 'attr initialUsbCheck disable 1' >> /opt/fhem/fhem.cfg

User fhem weiter Gruppenberechtigungen geben, z.B. für lokale Tonausgabe.
sudo usermod -aG audio fhem

Am Ende der gesamten Installation kann man auch noch das Raspbian System auf den aktuellsten Stand bringen.

#Finales Upgrade kann man auch weglassen oder später machen
apt-get update && apt-get -y upgrade

Seit August 2017 braucht man die folgende Maßnahme nicht mehr, der wirkliche Sinn war sowieso umstritten.
Beim Pi3 gibt es irgendwie ein Timing Problem beim Start, unter Umständen erzeugt fhem dann sofort 100% CPU Last. Dagegen hilft es den Start von fhem vom Netzwerk oder dem ntp Dienst abhängig zu machen.

# Den Systemstart von ntp abhängig machen
sed -i s/'# Required-Start:       $local_fs $remote_fs/# Required-Start:       $local_fs $remote_fs $ntp/' /etc/init.d/fhem
systemctl daemon-reload

Man kann auch quick&dirty im Startscript /etc/init.d/fhem ein "sleep 10" einfügen (von mir nicht empfohlen).

sed -i s/'        perl fhem.pl fhem.cfg/        sleep 10\n        perl fhem.pl fhem.cfg/' /etc/init.d/fhem

Attribute die nicht fehlen dürfen

attr global backup_before_update 1
attr global title FHEM-Name
attr global sendStatistics onUpdate
attr global latitude
attr global longitude
attr global motd none
attr global language de
attr WEB JavaScripts codemirror/fhem_codemirror.js
attr WEB codemirrorParam { "theme":"blackboard", "lineNumbers":true }
attr WEB plotfork 1

Und wenn man in FHEM ein Update gemacht hat, kann man auch von einer kleinen "Entwicklungsumgebung" profitieren. Näheres im Wiki.

define Import dummy
attr Import group Entwicklung
attr Import room Entwicklung
attr WEB menuEntries CodeImport,/fhem?detail=Import#

Wer nicht so viel tippen oder zeilenweise in die Kommandozeile kopieren will, kann auch diesen Teil in eine Script packen. So wird FHEM über Terminal per Script bedient:

perl /opt/fhem/fhem.pl 7072 'attr global title '$(hostname)
perl /opt/fhem/fhem.pl 7072 '
attr initialUsbCheck disable 1
attr global backup_before_update 1
attr global latitude 51.xxxxxxxxxxxxx
attr global longitude 12.xxxxxxxxxxxxx
attr global motd none
attr global language de
attr global sendStatistics onUpdate
attr WEB JavaScripts codemirror/fhem_codemirror.js
attr WEB codemirrorParam { "theme":"blackboard", "lineNumbers":true }
attr WEB plotfork 1
define Import dummy
attr Import group Entwicklung
attr Import room Entwicklung
attr WEB menuEntries CodeImport,/fhem?detail=Import#
save
'

Ein paar Tricks für den Raspberry

Onboard LEDs

Jeder Raspberry, also egal welcher Typ hat mindestens zwei LEDs eine rote für Power und ein grüne für Aktivität.
Die Grüne ist per Software ansteuerbar, man könnte damit Signale an die Außenwelt geben.
Die folgende Information ist von hier übernommen:

Die Steuerung übernehmen

echo none >/sys/class/leds/led0/trigger

Die Steuerung wieder Original setzen

echo mmc0 >/sys/class/leds/led0/trigger

Die LED steuern

echo 1 >/sys/class/leds/led0/brightness
echo 0 >/sys/class/leds/led0/brightness

Oder die LED über Python steuern

#!/usr/bin/python

import RPi.GPIO as GPIO
from time import sleep

# Needs to be BCM. GPIO.BOARD lets you address GPIO ports by periperal
# connector pin number, and the LED GPIO isn't on the connector
GPIO.setmode(GPIO.BCM)

# set up GPIO output channel
GPIO.setup(16, GPIO.OUT)

# On
GPIO.output(16, GPIO.LOW)

# Wait a bit
sleep(10)

# Off
GPIO.output(16, GPIO.HIGH)

Eingänge mit Pull UP oder Pull Down Widerstand beschalten

Will man mit einfachen Tastern etwas eingeben, muss der Eingang zunächst einen definierten Zustand haben. Entweder einen Widerstand nach Plus - PullUp oder einen nach Masse - PullDown.
Sicher ist sicher wenn man eine externen Widerstand verwendet, aber die Himbeere hat auch schon welche eingebaut. Diese 50 kOhm Widerstände kann man aktivieren.

Mit dem GPIO Tool

Mit verschiedenen Sprachen

Nur mit der Shell geht es offenbar nicht.

Mit Python (Quelle)

import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
GPIO.setup(23, GPIO.IN, pull_up_down = GPIO.PUD_DOWN)
GPIO.setup(24, GPIO.IN, pull_up_down = GPIO.PUD_UP)
while True:
if(GPIO.input(23) ==1):
print(“Button 1 pressed”)
if(GPIO.input(24) == 0):
print(“Button 2 pressed”)
GPIO.cleanup()

Anwendungsbeispiel

Mit einem Taster den Raspberry starten bzw. herunterfahren, quasi ein Soft Power Switch.
Zwischen Pin 5 (GPIO3) und Pin 9 oder Pin 6 (Masse) des GPIO Connectors schalten wir einen kleinen Taster. Oder wir verwenden nur einen Jumper (Pin 5 - 6) falls nichst weiter am GPIO Connector steckt.
Wird Pin 5 bei herunter gefahrenem Pi (sudo halt) kurz!!! auf Masse gelegt, startet der Pi ohne die Stromversorgung unterbrechen zu müssen.
ToDo Schaltbild

Das Geniale dabei ist: Den gleichen Taster kann man verwenden um den Pi genau in diesen Aus (Halt) Zustand zu bringen.
ToDo Programm beim Systemstart zum konfigurieren des Eingangs mit PullUp und Abfrage und Einbindung in den Systemstart.
Zunächst also mal die Abfrage der Taste und den Pi herunterfahren.
Diese Python Script zum Herunterfahren habe ich von hier.

#! /usr/bin/env python
import os
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
# GPIO3 (pin 5) set up as input. It is pulled up to stop false signals
GPIO.setup(3, GPIO.IN, pull_up_down=GPIO.PUD_UP)
try:
    while True:
        # wait for the pin to be sorted with GND and, if so, halt the system
        GPIO.wait_for_edge(3, GPIO.FALLING)
        # shut down the rpi
        os.system("/sbin/shutdown -h now")
except:
    GPIO.cleanup()

Um eine Quittung zu bekommen, dass der shutdown Prozess eingeleitet wurde lassen wir die grüne LED zweimal blinken.
ToDo Programm um die grüne LED umzukonfigurieren und blinken zu lassen
http://www.forum-raspberrypi.de/Thread-python-aufruf-von-shell-script-in-python
http://www.python-kurs.eu/os_modul_shell.php

Raspberry Pi HomeMatic-Modul

Der Artikel ist mittlerweile über 4 Jahre alt. Ich bin dazu übergegangen die aktuellen Anpassungen im Wiki und auf GitHub vorzunehmen. Wesentlich ist die Vorbereitung der UART Schnittstelle. Mein Setup Script erledigt alle notwendigen Schritte.

Dieser Artikel hat nur noch historischen Charakter.

Für die Himbeere gibt es seit einiger Zeit eine Homematic Modul HM-MOD-RPI-PCB. Der Bausatz ist simpel aufgebaut, es ist nur eine Buchsenleiste und zwei Platinen mit Pfostenverbinder zusammenlöten.
Der HM-CFG-USB Adapter ist schon nicht mehr lieferbar, den HM-CFG-LAN soll es bald nicht mehr geben. Damit wird diese Modul und die Implementierung in FHEM zunehmend interessant!

Seit 18.7.2016 ist das Modul direkt in FHEM und das CUL_HM Modul ist angepasst. Damit ist die Installation schon einen Schritt einfacher.

Es gibt einen Thread der alles beschreibt, im Wiki findet man zunehemend entsprechende Infos.
Ich schreibe mal wieder auf wie es bei mir funktioniert hat:

Zutaten:

• Raspberry PI B, B+, B2 oder B3
• Image Jessie-Lite vom 27.05.2016 oder aktueller
• System Grundkonfiguration: Zeitzone, Hostname, Kamera etc...

Serielle Schnittstelle vorbereiten:

Die folgenden Schritte kann man vor dem ersten Start auf der SD Karte (nach dem Image schreiben) ausführen oder aber nach dem ersten Start im Terminal.

• In der Datei /boot/cmdline.txt diesen Eintrag löschen: console=serial0,115200 
• Die Datei /boot/config.txt um diese Zeile ergänzen: enable_uart=1 
• Bei dem PI 3 muss die UART und die miniUART getauscht werden. Die Datei /boot/config.txt insgesamt um diese Zeilen ergänzen:

enable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250

Statt core_freq kann man auch force_turbo=1 gesetzt werden. Wichtig ist hierbei, dass dei Taktfrequenz konstant bleibt.

Nach dem ersten Start den serial-getty Dienst deaktivieren:

sudo systemctl disable serial-getty@ttyAMA0.service

Jetzt unbedingt neu starten!

Zusammenfassung

Falls man die Dateien im Image nicht vor dem ersten Start manipuliert hat, also nach dem ersten Start im Terminal:

sudo su
echo "enable_uart=1" >> /boot/config.txt 
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt # Nur beim Pi3 notwendig
echo "core_freq=250" >> /boot/config.txt 
sed -i s/'\bconsole=serial0,115200 //' /boot/cmdline.txt
systemctl disable serial-getty@ttyAMA0.service
reboot

In jedem Fall braucht man einen Neustart. man kann also die obigen Zeilen auch in das Script zur Grundkonfiguration des raspberry einbinden und läuft nicht Gefahr die Dateien im /boot durch den falschen Windows Editor unbrauchbar zumachen.

Setup von FHEM

Ganz nach persönlicher Vorliebe!
Interessant ist auf alle Fälle das Script von Betateilchen. Allerdings installiert dies die SVN Version. Der normaler User sollte in Standard Setup verwenden.

Beim PI 3 wegen Timingproblemen muss man noch eventuell die /etc/init.d/fhem um sleep 10 am Anfang ergänzen

Nach Neustart in FHEM einfach die Definition

define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx

Firmware flashen

Das frische Modul sollte noch mit neuer Firmware geflasht werden, die Originalversion war 1.2.1 empfohlen ist derzeit die 1.4.1 von eq3.
Laut Wiki  ist jetzt auch das flashen der Firmware von FHEM aus möglich.
In der FHEM Kommandozeile:

"wget -O FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3"

Etwas warten das die Datei geladen wurde (LogFile prüfen) dann diesen Befehl eingeben und warten bis das Modul sich wieder meldet.

set myHmUART updateCoPro FHEM/firmware/coprocessor_update.eq3

Falls das nicht funktioniert, hier noch die händische Methode:
Am Besten FHEM beenden, damit keine Zugriffe auf das Modul erfolgen!

sudo su
apt-get update && apt-get install libusb-1.0-0-dev build-essential git
systemctl stop fhem
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb/
make
# Firmware runterladen
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3
# eigentliches flashen:
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3

Bei der letzten Zeile kamen mehrere Fehler. Ich habe es einfach mehrfach wiederholt und irgendwann ging es.

Sollten beim Firmwareupdate hartnäckig Fehler auftreten (oder einfach nichts passieren) muss das Modul mal vom Strom getrennt werden, neustart reicht nicht!

Hintergrundinformationen 

Man kann die Grundkonfiguration mit raspi-config machen:

• Zeitzone
• Hostnamen ändern
• Kamera aktivieren
• Serielle Schnittstelle aktivieren
• usw.

Das raspi-config Tool ändert immer mal seinen Aufbau, ich will das deshalb hier nicht bildlich beschreiben.

Man kann aber auch alles per Script machen:

# Zeitzone
echo "Europe/Berlin" > /etc/timezone
dpkg-reconfigure -f noninteractive tzdata
#Hostname noch testen!!!
hostname -b raspib
sed -i s/raspberrypi/raspib/ /etc/hosts
nano /etc/init.d/hostname.sh
nano /etc/hostname
rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
#Kamera
echo "start_x=1" >> /boot/config.txt
echo "gpu_mem=128" >> /boot/config.txt
echo "disable_camera_led=1" >> /boot/config.txt

Achtung: Scripte immer unbedingt im Unix Code (nur LF) abspeichern!!!

Die Sache mit den Rechten auf /dev/ttyAMA0

Der Start des Dienstes serial-getty@ttyAMA0.service setzt offenbar die Rechte auf.

crw--w---- 1 root tty 204, 64 Jul 15 20:36 /dev/ttyAMA0
Ein Beenden des Dienstes ändert daran nichts.

Wird der Dienst nicht gestartet stehend die Rechte auf
crw-rw---- 1 root dialout 204, 64 Jul 18 09:51 /dev/ttyAMA0

So müssen die Rechte auch aussehen! Und der User fhem muss in der Gruppe dialout sein!

Die Sache mit dem Dienst serial-getty@ttyAMA0.service

Ein systemctl disable serial-getty@ttyAMA0.service verhindert zwar den automatischen Start aber nicht den manuellen Start bzw. den Start durch andere Prozesse. Erst der Befehl systemctl mask xxx verhindert jeglichen Start.

Der Eintrag console=serial0,115200 in der /boot/cmdline.txt ist offenbar dafür verantwortlich, dass der Dienst trotz disable gestartet wird. Löscht man diesen Eintrag, wird der Dienst auch nicht gestartet. Unterm Strich kann man den Start des Dienstes auf zwei Arten verhindern:

sudo sed -i s/'\bconsole=serial0,115200 //' /boot/cmdline.txt
sudo systemctl disable serial-getty@ttyAMA0.service

oder

sudo su
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
chmod g=rw /dev/ttyAMA0

Eigentlich würde ich ein systemctl mask serial-getty@ttyAMA0.service bevorzugen um den Dienst generell auszuschließen.

Wenn Bluetooth beim Pi 3 funktionieren soll: ttyAMA0 und ttyS0 tauschen

Der Eintrag dtoverlay=pi3-miniuart-bt in der Datei /boot/config.txt sorgt dafür, dass die Ansteuerung des BT Moduls jeweils über den Alias serial1 erfolgt.
Eine Änderung wie früher beschrieben in der Datei /lib/systemd/system/hciuart.service ist nicht mehr notwendig!

Im laufenden Betrieb kann  man auch so vorgehen

sed -i s/ttyAMA0/ttyS0/ /lib/systemd/system/hciuart.service
daemon reload
systemctl restart hciuart

Man kann die korrekte Ansteuerung mit ls -l /dev/ser* überprüfen:
Mit dtoverlay=pi3-miniuart-bt (BT an ttyS0)
lrwxrwxrwx 1 root root 7 Jan  1 18:48 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Jan  1 18:48 /dev/serial1 -> ttyS0

Ohne dtoverlay=pi3-miniuart-bt (BT an ttyAMA0)

lrwxrwxrwx 1 root root 5 Jan  1 19:02 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Jan  1 19:02 /dev/serial1 -> ttyAMA0

Alternativ könnte man BT deaktivieren.

FHEM Setup

Die Einbindung in FHEM passiert mit dem Modul HMUARTLGW. Das HM-MOD-RPI-PCB hat einen eigene hmId.

define HMUART1 HMUARTLGW /dev/ttyAMA0

Im praktischen Betrieb muss man aber die eigene hmId setzen. Ohne das Attribute hmId empfängt das Modul scheinbar nichts.

attr HMUART1 hmId xxxxxx




Das attr qLen spielte bei mir nach einiger Zeit eine Rolle (Meldung im Log: queue is full, dropping packet), ich habe den Wert auf 60 gesetzt.

Um AES-CBC  nutzen zu können (Rauchmelder SD-2) muss das Paket libcrypt-rijndael-perl installiert werden.

Das UART Modul merkt sich die hmId und die AES Schlüssel bis zur nächsten Änderung.
Das Modul HMUARTLGW unterstützt auch die Remoteanbindung des Raspberry mit socat. Näheres siehe Commandref.

Probleme

FHEM startet mit knapp 100% CPU wenn das HM-MOD-RPI-PCB Modul einfach gesteckt wird.
Es hilft wenn man vor dem Stecken die Erkennung von FHEM ausschaltet.

attr initialUsbCheck disable 1

oder unmittelbar nach der Neuinstallation!

echo 'attr initialUsbCheck disable 1' >> /opt/fhem/fhem.cfg

Notizen

Eventuell braucht man mit der original Firmware (1.2.1) noch das:

echo 18 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio18/direction
echo 1 >/sys/class/gpio/gpio18/value

Damit wird das Reset Pin am Modul definiert gesetzt