Homematic E-Paper-Display in Betrieb nehmen

Homematic E-Paper Display in Betrieb nehmen

Das HM-Disp-EP-WM55 habe ich mir als Bausatz gekauft. Der Zusammenbau ist sehr einfach. Leider sind einige Dinge falsch beschrieben: das Aufsetzen der Displayscheibe ist um 180° verdreht und verdeckt die LED, also aufpassen und mit gesundem Menschenverstand handeln.
Die Funktion ist schnell erklärt:

• die Taster sind wie alle Homematic Taster oben und unten zu belegen, um Aktoren ein- oder auszuschalten.
• Die ganz obere und ganz untere Zeile können variabel aber mit festen Texten belegt werden, je nachdem was man mit der Schaltwippe schalten möchte.
• Die mittleren drei Zeilen (Zeile 2, 3, 4) können programmatisch über ein CCU Programm komplett dynamisch belegt werden. Ferne könnte man feste Icons verwenden.

Mein Anwendungsfall für die dynamischen drei Zeilen ist, die Außentemperatur, den Luftdruck vom wiffi-wz und die CO2 Luftqualität anzuzeigen. Ich schreibe alle drei Zeilen alle 10 Minuten mit einem Homematic Programm.

Das Programm selbst habe ich aus dem Homematic Forum und leicht an meine Bedürfnisse angepasst. Danke an DrTob und Thialf.

Das Ergebnis sieht dann so aus:

Es werde Licht!

Die Idee: Beleuchtungsstärke aus einer Mobotix T25 auslesen und den Medianwert der letzten Messungen als Homematic Variable speichern, um damit Beschattung zu kontrollieren oder Bewegungsmelder-gesteuerte Lichter zu schalten.

Die meisten Mobotix Kameras erfassen die Beleuchtungsstärke als Meßwert in Lux. Meine T25 Türstationskamera zum Beispiel liefert den Messwert auf dem "rechten" Sensor mittels der Variable $(SEN.LXR) unter folgender URL:

http://<ip-adresse>/control/rcontrol?action=gettext&message=$(SEN.LXR)

Die Meßwerte werden zeilenweise in eine temporäre Datei geschrieben, in der maximal die letzen 10 Meßwerte gespeichert bleiben.
Um bei schwankenden Lichtverhältnissen die Ausreißer Meßwerte zu eliminieren, möchte ich von den letzten 10 Messungen den Median bilden. Dazu nutze ich das GNU Werkzeug datamash. Datamash liest die Daten aus der der ersten Spalte der temporären Datei. Das ist robust, egal wie viel Meßwerte bereits vorliegen.
Schließlich wird der Median per XMLAPI Aufruf in eine vorher angelegte Systemvariable geschrieben und steht damit in Homematic Skripten zur Auswertung zur Verfügung.

Hier ist der Quelltext meines Bash Skriptes, welches jede Minute als cronjob auf einem Server aufgerufen wird.

---

---

Nachtrag: Unterschied zwischen Helligkeitsmesser in eine Bewegungsmelder (HM-Sen-MDIR-O-2) und dem von der T25 gemessenen Helligkeitswert:

Homematic CCU2 virtualisiert

Virtualisierung einer Homematic CCU2

Die Motivation war ein notwendiges Firmwareupdate der CCU2 wegen eines neuen Schaltaktors, welcher nur ab einer bestimmten Version unterstützt wird. An und für sich laufen Firmwareupdates bei Homematic unspektakulär ab. Diesmal leider nicht. Die Ursache ist mir völlig unklar aber nach zig maliger Neuinstallation verschiedener Firmwareversionen, das Rückstellen auf Werkseinstellung und nachfolgendes Einspielen des Backups konnte ich die CCU2 nicht mehr in eine stabilen Zustand bekommen. Die Web-UI und der rfd-Deamon stürzten ab. Selbst ein Fallback auf die vorherige Firmware 2.15.7 brachte keine Beruhigung.
Auf der Suche nach Alternativen stieß ich im Homematic-Forum auf das Projekt YAHM. Eine Weiterentwicklung der LXCCU.
Man nutzt einen RaspberryPi mit Raspian Jezzy und installiert dort in einem LXC Container die aktuellste CCU2 Firmware.
Bach der Installation von Raspbian sollte man folgende Aktionen durchführen:

• sudo raspi-config
• einstellen aller Parameter vom Übertakten bis zur Lokalisation.
• Sudo apt update, sudo apt upgrade
• Bei mir werden IPv6 Adressen vergeben, diese machen bei der Update Servern von Debian Probleme. Deswegen einstellen, dass IPv4 präferiert werden soll:
• /etc/gai.conf:  precedence ::ffff:0:0/96  100
• einspielen der von YAHM Installer benötigen Module
• sudo apt install sendmail bash-completion wget dos2unix python git lxc liblzo2-dev bridge-utils python-lzo patch gzip openssl
• danach erst der Aufruf der YAHM Installation, geht dann viel schneller.

wget -nv -O- https://raw.githubusercontent.com/leonsio/YAHM/master/yahm-init | sudo -E  bash -

und anschließend:

sudo yahm-lxc install
sudo yahm-network -w create_bridge
sudo yahm-network attach_bridge

Mein dnsmasq DHCP Server vergibt dann für den RaspberryPi eine IP Adresse und der neue Container bekommt eine eigene IP Adresse zugewiesen. Unter dieser neue Adresse ist dann auch schon die virtuelle (nackte) CCU2 erreichbar.

Mit sudo yahm-ui kann man ein grafisches Werkzeug starten, mit dem man komfortabel die Installation noch nach bearbeiten oder zusätzliche Module wie den CUxD nachinstallieren kann.

Man benötigt letztendlich für die Funkkommunikation noch ein Funkmodul. Dafür kann man entweder das Funkmodul für den RaspberryPi kaufen oder - meine Entscheidung - einen Homematic Funk LAN Gateway, quasi eine "Homematic Antenne mit Ethernetanschluss".

Die Web-UI der virtuellen CCU2 lässt sich nun richtig schnell und flüssig bedienen. kein Vergleich zur echten CCU2.

SMS Server einrichten

SMS Server einrichten

Auf einem Ubuntu 16.04 Server soll ein SMS Server Dienst zur Alarmierung über SMS eingerichtet werden. Dazu soll das Paket "gammu" eingesetzt werden.

Als Hardware dient ein Huawei E1552 web'n'walk Stick Fusion II USB stick.

Zunächst soll sicher gestellt werden, dass der Stick im richtigen Modus (Modem) arbeitet und immer die selbe Device Bezeichnung zugewiesen bekommt.

Udev Regel zur Umschaltung von Storage in Modem Funktion

USB ModeSwitch muss installiert werden und folgende Regeln werden in /etc/udev/rules.d/ eingefügt:

# eigene udev-Regeln für UMTS-Sticks 

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 1446 -M '55534243123456780000000000000011062000000100000000000000000000'"

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1436", RUN+="/bin/bash -c 'modprobe option && echo 12d1 1436 > /sys/bus/usb-serial/drivers/option1/new_id'"

Eindeutiger Device Name festlegen

Damit der USB Stick auch immer den selben Namen bekommt, muss man eine weitere Regel in /etc/udev/rules.d einfügen:

SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1436",  SYMLINK+="mytty-huawei-stick"

Beim erneuten Einstecken wird der Stick nun immer als /dev/mytty-huawei-stick angemeldet.

Gammu installieren und konfigurieren

$ apt get install gammu gammu-smsd 

Eine Konfigurationsdatei anlegen /etc/gammu-smsdrc

# Configuration file for Gammu SMS Daemon
# Gammu library configuration, see gammurc(5)
[gammu]
# Please configure this!
port = /dev/mytty-huawei-stick
connection = at115200
# Debugging
logformat = textall

# SMSD configuration, see gammu-smsdrc(5)
[smsd]
service = files
logfile = syslog
PIN = 'xxxx'
# Increase for debugging information
debuglevel = 0

# Paths where messages are stored
inboxpath = /var/spool/gammu/inbox/
outboxpath = /var/spool/gammu/outbox/
sentsmspath = /var/spool/gammu/sent/
errorsmspath = /var/spool/gammu/error/

Der gamu-smsd Service kann nun aktiviert und gestartet (systemd) werden

$ sudo systemctl enable gammu-smsd

$ sudo systemctl start gammu-smsd

Prüfen kann man die Funktion mit

sudo gammu-smsd-monitor -n 1 -d 1
Damit man in einem cron job den Stick überwachen kann - ohne root zu sein - ist es anzuraten, dem Binary das Setuid Bit zu setzen, dann kann jeder unprivilegierte User das Kommando (als root) ausführen:

$ chmod u+s /usr/bin/gammu-smsd-monitor

Versenden von SMS

Zuerst sollte man die Spool Directories für alle schreibbar machen sonst kann nur ein Benutzer senden:
$ chmod -R o+rwx /var/spool/gammu/

Jetzt kann die erste Textnachricht versendet werden:

echo "Testnachricht" | gammu-smsd-inject TEXT +4917XXXXXX

Option

Wer noch mag, kann sich noch Kalkun installieren, der mittels einer SQL Datenbank einen kompletten SMS Server, vergleichbar mit einem Email Server realisiert.

pull or push Google Drive files

drive is a tiny program to pull or push Google Drive files.

find drive sources here: https://github.com/odeke-em/drive

Installation unter Ubuntu 14.04

Um sich die Mühe der Installation von Go etc zu ersparen kann auch ein PPA hinzufügen:
/etc/apt/sources.list.d/twodopeshaggy-drive-trusty.list 

deb http://ppa.launchpad.net/twodopeshaggy/drive/ubuntu trusty main

Das installiert drive in der Version 0.3.7-0

drive 0.3.7-0  i386 Google Drive tool written in Go language

Initialisierung

$ drive init ~/gdrive
$ cd ~/gdrive

Benutzung: Daten herunterladen, Daten hochladen

$ drive pull

$ drive push

Home Server auf Intel NUC Basis

Home Server auf Intel NUC Basis

Hardware:

• Intel BB NUC5i3RYH Rock Canyon i3 High Mini-PC

• Transcend MTS400 M.2 SSD 128GB SATA III, MLC

• 2x Kingston KVR16LS11/4 Arbeitsspeicher 4GB (DDR3L Non-ECC CL11 SODIMM 1,35V, 204-pin 1,5V)

• Samsung Momentus 1TB HD SATA oder Ähnliches

Die Einzelteile

Das leere Chassis 

Das bestückte Chassis mit Speicher und mSATA SSD

Betriebssystem

Ubuntu 16.04 Server Edition.

Plattenaufteilung

Folgendes Design soll angewendet werden:

Bootdisk (128 GB):

• 500MB /boot, ext2
• 8,5 GB swap
• Rest /, ext4

Datendisk (1 TB):

• komplette Disk eine Partition für Logical Volume Manager (LVM)
• Eine LVM Volume Group
• ein logical volume 500 GB /home, btrfs
• ein logical volume 500 GB, /export, btrfs

So sieht es dann rein physikalisch aus:

Modell: ATA ST1000LM024 HN-M (scsi)

Festplatte  /dev/sda:  1000GB

Sektorgröße (logisch/physisch): 512B/4096B

Partitionstabelle: msdos

Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags

 1      1049kB  1000GB  1000GB  primary               LVM

Modell: ATA TS128GMTS400 (scsi)

Festplatte  /dev/sdb:  128GB

Sektorgröße (logisch/physisch): 512B/512B

Partitionstabelle: msdos

Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ       Dateisystem     Flags

 1      1049kB  511MB   510MB   primary   ext2            boot

 2      511MB   9010MB  8500MB  primary   linux-swap(v1)

 3      9011MB  128GB   119GB   extended

 5      9011MB  128GB   119GB   logical   ext4

Modell: Linux device-mapper (linear) (dm)

Festplatte  /dev/mapper/majestix--vg-majestix--lg1:  500GB

Sektorgröße (logisch/physisch): 512B/4096B

Partitionstabelle: loop

Disk-Flags: 

Nummer  Anfang  Ende   Größe  Dateisystem  Flags

 1      0,00B   500GB  500GB  btrfs

Modell: Linux device-mapper (linear) (dm)

Festplatte  /dev/mapper/majestix--vg-majestix--lg2:  500GB

Sektorgröße (logisch/physisch): 512B/4096B

Partitionstabelle: loop

Disk-Flags: 

Nummer  Anfang  Ende   Größe  Dateisystem  Flags

 1      0,00B   500GB  500GB  btrfs

Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf

/dev/sdb5      114279016 1968800 106482120    2% /

/dev/sdb1         481959  103510    353566   23% /boot

/dev/dm-1      488476672   16896 486361856    1% /export

/dev/dm-0      488280064   16928 486165248    1% /home

Stromverbrauch

Im Leerlauf ohne Last: ca. 8 Watt und im Betrieb ca 10,5 Watt.

Eigener DHCP und DNS Dienst hinter Fritz!Box betreiben

Eigener DHCP und DNS Dienst hinter Fritz!Box betreiben

Mit dnsmasq kann man auf dem eigenen Server einen DHCP und DNS Server betreiben, der im LAN die Adressen vergibt und Domainnamen auflöst. Das ganze soll im Dualstack Betrieb also IPv4 und IPv6 funktionieren.
Meine Umgebung:

• Fritz!box 6360 mit einem KabelBw (unitymedia) Kabelanschluß, DualStack also IPv4 mit NAT und ein IPv6 Präfix (/56) für das hinter dem Router liegende LAN.
• Server: Ubuntu 14.04

Die Motivation ist eigentlich, dass man die Rechner im LAN automatisch mit den korrekten IP Adressen per DHCP versorgen kann und auch die interne Domain (fritz.box) korrekt aufgelöst wird.

dnsmasq ist schnell installiert mit

sudo apt install dnsmasq

Ganz wichtig war eine Einstellung in /etc/default/dnsmasq

# If the resolvconf package is installed, dnsmasq will use its output 

# rather than the contents of /etc/resolv.conf to find upstream 

# nameservers. Uncommenting this line inhibits this behaviour.

# Not that including a "resolv-file=<filename>" line in 

# /etc/dnsmasq.conf is not enough to override resolvconf if it is

# installed: the line below must be uncommented.

IGNORE_RESOLVCONF=yes

Solange man resolvconf nicht ignoriert, funktioniert die Weiterleitung der DNS Anfragen an die Fritzbox nicht.

Hier sind die Einstellungen, die ich in der /etc/dnsmasq.conf machen musste.

# Configuration file for dnsmasq.

#

# Never forward plain names (without a dot or domain part)

domain-needed

# Never forward addresses in the non-routed address spaces.

bogus-priv

# Add local-only domains here, queries in these domains are answered

# from /etc/hosts or DHCP only.

local=/localnet/

local=/local/

local=/fritz.box/

# If you want dnsmasq to listen for DHCP and DNS requests only on

# specified interfaces (and the loopback) give the name of the

# interface (eg eth0) here.

# Repeat the line for more than one interface.

interface=eth0

# Set the domain for dnsmasq. this is optional, but if it is set, it

# does the following things.

# 1) Allows DHCP hosts to have fully qualified domain names, as long

#     as the domain part matches this setting.

# 2) Sets the "domain" DHCP option thereby potentially setting the

#    domain of all systems configured by DHCP

# 3) Provides the domain part for "expand-hosts"

#domain=thekelleys.org.uk

domain=fritz.box

# Uncomment this to enable the integrated DHCP server, you need

# to supply the range of addresses available for lease and optionally

# a lease time. If you have more than one network, you will need to

# repeat this for each network on which you want to supply DHCP

# service.

#dhcp-range=192.168.0.50,192.168.0.150,12h

dhcp-range=192.168.178.100,192.168.178.150,2h

# Enable DHCPv6. Note that the prefix-length does not need to be specified

# and defaults to 64 if missing/

#dhcp-range=1234::2, 1234::500, 64, 12h

dhcp-range=2a02:8070:4bc:e300::, ra-stateless, ra-names

# Do router advertisements for all subnets where we're doing DHCPv6

# Unless overriden by ra-stateless, ra-names, et al, the router 

# advertisements will have the M and O bits set, so that the clients

# get addresses and configuration from DHCPv6, and the A bit reset, so the 

# clients don't use SLAAC addresses.

enable-ra

# Override the default route supplied by dnsmasq, which assumes the

# router is the same machine as the one running dnsmasq.

#dhcp-option=3,1.2.3.4

dhcp-option=3,192.168.178.1

dhcp-option=option:dns-server,0.0.0.0,192.168.178.1

# Send DHCPv6 option for namservers as the machine running 

# dnsmasq and another.

#dhcp-option=option6:dns-server,[::],[1234::88]

dhcp-option=option6:dns-server,[::]

# Ask client to poll for option changes every six hours. (RFC4242)

dhcp-option=option6:information-refresh-time,6h

dhcp-option=option6:domain-search,fritz.box

# Set the NTP time server address to be the same machine as

# is running dnsmasq

dhcp-option=42,0.0.0.0

dhcp-option=option6:42,[::]

# Log lots of extra information about DHCP transactions.

log-dhcp

Dazu müssen in der Fritz!Box noch folgende Änderungen vorgenommen werden: 

Heimnetz-> Netzwerk -> IPv4-Adressen und IPv6 Adressen

IPv4-Adressen: hier schaltet man den DHCP Server aus.

IPv6-Adressen: da ich vom Internetanbieter ein IPv6 Präfix zugewiesen bekomme, soll die Fritz!box weiterhin die IPv6 Adressen vergeben. Aber alle anderen Konfigurationen sollen von dnsmasq kommen. Dazu wählt man "O-Flag" aus. Weiterhin habe ich mir ULA Adressen erzeugen lassen und benutze zusätzlich zu den offiziellen IPv6 Adressen noch interne ULA Adressen falls mal das Internet nicht funktioniert.

Nun habe ich mir noch die LAN Konfiguration aller Geräte in eine separate Konfigurationsdatei geschrieben und in /etc/dnsmasq.d/ abgelegt. Das Format sieht so aus:

dhcp-host=00:1a:22:03:f4:16,hostname,192.168.178.11,infinite

Dort definiere ich für bestimmte Geräte (MAC Adressen) feste Hostnamen und feste IP Adressen, welche dann auf Anfrage korrekt verteilt werden.

Nach einem Neustart des Dienstes sollte alles soweit funktionieren und nach einem halben Tag sollten so langsam alle IPs erneuert worden sein.

Interessant ist die Datei /var/lib/misc/dnsmasq.leases wo immer die jeweils den Geräten zugewiesenen IPs aufgelistet sind.

Die DHCP Anfragen werden in /var/log/syslog mit protokolliert.