Devolo Thermostat mit HomeAssistant steuern

ich weiß ich bin ein bisschen „Late to the Party“ – aber egal.

Wer unter Ubuntu ZWave-Geräte via HomeAssistant steuern möchte, muss erst mal selber hand anlegen.

Folgende pakete müssen via apt-get nachinstalliert werden:

  • libudev-dev
  • libopenzwave1.5

Anschließend muss man noch via pip das Paket python-openzwave installieren. Den Rest sollte HomeAssistant selber nachinstallieren, sobald man zwave in der Config aktiviert hat.

zwave:
  usb_path: /dev/ttyACM0
  network_key: "SecretKey" 

Die Installation der meisten Z Wave sticks läuft problemlos. Anstecken und ein device wird angelegt, meist irgendwas mit ttyACM. Gegenbefalls muss man noch an den Berechtigungen schrauben aber das ist trivial. Im HomeAssistant COnfigMenu sollte unter ZWave jetzt der Controller gelistet sein.

Zuerst muss man das Thermostat montieren. Danach versetzt man via HomeAssistant den Z Wave Adapter in den Suchmodus. Auf dem Thermostat die mittlere Bedientaste zur Bestätigung drücken (ca 1sek) und nach kurzer Zeit sollte im HomeAssistant eine neue ZWave Node auftauchen.

„Aus Gründen“ wird das Thermostat als Cooling Unit erkannt. Die Temperatur wird zwar korrekt ausgelesen, aber man kann keine Ziel Temperatur setzten. Um das zu beheben muss muss man warten bis die Node im ZWave Dialog als „Complete“ gelistet wird. Anschließend den HomeAssistant geregelt runter fahren, damit die ZWave Config raus geschrieben wird. Nun diese Config bearbeiten und den Eintrag „Heating 1“ hinzufügen.

<CommandClass id="67" name="COMMAND_CLASS_THERMOSTAT_SETPOINT" version="1" request_flags="4" innif="true" base="1" typeInterpretation="B">
  <Instance index="1" />
  <Value type="decimal" genre="user" instance="1" index="1" label="Heating 1" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="21.00" />
  <Value type="decimal" genre="user" instance="1" index="2" label="Cooling 1" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" />
</CommandClass>

Jetzt noch unter Climate ZWave aktivieren:

climate:
  - platform: zwave

Nach dem start des HomeAssistant sollen 4 neue „devices“ verfügbar sein:

  • climate.danfoss_unknown_type_0005_id_0175_cooling_1… – kann man ignordieren
  • climate.danfoss_unknown_type_0005_id_0175_heating_1… – Steuerung des Thermostat
  • sensor.danfoss_unknown_type_0005_id_0175_temperature… – Das Thermometer des Thermostat
  • zwave.danfoss_unknown_type_0005_id_0175… – Das zwave device selber, braucht man für die Batterieanzeige

Um einen Sensor für die Batterie zu haben muss man folgendes machen:

sensor:
  - platform: template
    sensors:
      zwave_devolo_batt:
        value_template: '{% if states.zwave.danfoss_unknown_type_0005_id_0175 %} {{ states.zwave.danfoss_unknown_type_0005_id_0175.attributes.battery_level }} {% else %} Unknown {% endif %}'
        unit_of_measurement: '%'

Hat man mehrere Thermostate wird allen litereals ein Nummerierung via Unterstrich angehängt. (zwave.danfoss_unknown_type_0005_id_0175_2, climate.danfoss_unknown_type_0005_id_0175_heating_1_2 …)

Jetzt kann man das Thermostat im HomeAssistant nutzen und steuern.

Was funktioniert nicht:
COMMAND_CLASS_CLOCK – Der HomeAssistant scheint die Uhrzeit noch nicht auf das Device zu schreiben. Die wird gebraucht, dass das Thermostat einmal eine „Justierungsmessung“ Des Ventiels macht
COMMAND_CLASS_CLIMATE_CONTROL_SCHEDULE – Laut Beschreibung sollte man dem Thermostat hier eigenen „Schedule“ verpassen können. Das kann man über den HomeAssistant lösen, was heir auch gehen sollte, ist den Temperatursensor mit einem Offset zu versehen.

Kleine Anmerkung für die Leute die die Bedienungsanleitung suchen. Devolo hält es nicht für Notwendig die vollen Funktionen des Thermostates zu beschreiben. Da es sich aber um ein Gebrandetes Danfoss handelt, kann man sich da die nötigen Daten ziehen. Als Spezjalservice, das wichtigste hier:

  • Full Reset: Batterien raus, und beim einlegen die Mittlere Taste gedrückt halten biss Symbole im Display aufleuchten.
  • Wenn man die Mittlere Taste gedrückt hält, erscheint ein „stilisiertes“ M, drückt man nochmal die Taste wird das Ventiel gelöst und man kann das Thermostat demontieren.
  • Wenn man bei dem M mit den Pfeiltasten steuert, kann in weitere Modi wechseln Li und Pb
  • Li = Linktest = Blingt nach der Wahl die Glocke und die Antenne, dann stimmt was mit dem ZWave Link nicht
  • Pb = „Raumdimensionierung“ = P1 Radiator zu gross, P2 Radiator passt, P3 Radiator zu klein

Razer Huntsman unter Linux

Unter Linux gibt es den openrazer Treiber um Razer Geräte anzusteuern. Leider hat Razer bei neueren Geräten das „Protokoll“ gewechselt und betreibt jetzt wohl mehr „Software Based Lightning“. Lange Rede – kurzer Sinn: der openrazor Treiber aus den aktuellen quellen funktioniert noch nicht.

Wenn man nicht alles selber bauen will sollte man sich erst mal das Frontend installieren. Unter KDE bietet sich Polychromatic an. Dazu muss man auch den Treiber „schon mal“ installieren.

Anschließen hohlt man sich die Openrazer-Quellen von hier: https://github.com/sumpster/razer-drivers.git

Danach der üblich Weg:

make
sudo make driver_install
sudo make setup_dkms
sudo make udev_install
sudo make daemon_install

danach noch den openrazor_daemon aus /usr/lib/python3.x nach /usr/lib/python3/dist-packages kopieren, durchstarten und schon kann man die Huntsman unter Linux steuern.

Wichtig: nutzt !!nicht!! die abkürzung über ubuntu_install. Die ist fürs pakaging gedacht und zerschießt euch das System.

kolab_smtp_access_policy exit status 1

Wer einen Kolabserver auf einem Ubuntuserver hochzieht, wird aktuell irgendwann (beim Versand oder Empfang von Mails) auf den Fehler „kolab_smtp_access_policy exit status 1“ stoßen. Alle Maßnahmen das logging aufzudrehen, greifen ins leere und man ist verzweifeln …

In diesem Fall sollte man doch einfach das script per hand aufrufen. Wichtig dabei, postfix verwendet pyhton2.7…

python2.7 /usr/lib/postfix/kolab_smtp_access_policy

Mit hoher Warscheinlichkeit kann das Module pymysql nicht geladen werden. Einfach das Modul nachinstallieren und schon kann es mit dem Mail-Empfang losgehen.

apt-get install python-pymysql

Änderungen bei LVM

Wer wie ich regelmäßig einen Raid 1 (Mirror) mit LVM aufbaut/betreibt, wird seit neusten (zu mindestens wenn er auf den aktuellen Ubuntu LTS setzt) in folgendes Problem laufen. Der bisher gültige Befehl führt nicht mehr zum gewünschten Ergebnis:

lvconvert -m 1 volumeGroup/logicalVolume  --corelog
  Insufficient free space: 1 extents needed, but only 0 available

Das ganze liegt daran, dass sich die art wie LVM jetzt einen Raid aufbaut wohl geändert haben soll. Ich bin da nicht tiefer hinabgestiegen. Schlussendlich muss man einfach noch den Typ mit angeben, dann klappt es wieder.

lvconvert -m 1 volumeGroup/logicalVolume  --corelog --type mirror
  volumeGroup/logicalVolume: Converted: 0,0%
  ...
  volumeGroup/logicalVolume: Converted: 100,0%

CineS2 Treiber „OnTheFly“ laden

Wer wie ich eine CineS2 6.5 im einsatz hat, ist unter Ubuntu ein bisschen gekniffen. Der Treiber wird noch nicht mit dem offizjellen Kernel ausgeliefert. Das führt dazu das man leider auf einem Produktivsystem etwas selber bauen muss. Besonders nach einem Kernel Update nerft das ganze, da man den Treiber im laufenden Betrieb überschreiben muss.

Als erstes brauch man git. Via git clone oder gut pull von https://github.com/DigitalDevices/dddvb die neusten Sourcen downloaden.

Erst mal den alten Treiber „entladen“ (fals man noch weitere DVB-Karten hat müssen deren Treiber auch entladen werden)

sudo rmmod ddbridge
sudo rmmod dvb_core
sudo rmmod cxd2099 

anschließend geht es ans bauen

make clean
make -j 8
sudo make install

Treiber wieder laden …

depmod -a
modprobe ddbridge

So geht es auch ohne Neustart …

Kodi und „fehlende“ Visualisierung

Im neuen Kodi Pakage,das über das PPA des XBMC/Kodi Team verteilt wird, sind die Visualisierungen in eigene Sub-Pakages ausgelagert. Will man also die Balken während des Abspielens von Musik, muss man erst mal die fehlenden Pakages nachinstallieren.

apt-get install kodi-visualization-spectrum
apt-get install kodi-visualization-projectm
apt-get install kodi-visualization-goom
apt-get install kodi-visualization-shadertoy
apt-get install kodi-visualization-waveform

Wenn man nun Kodi startet und die Visualisierungen auswählbar sind, aber nicht dargestellt werden muss man ins log schauen. Dort taucht dann folgende Meldung auf:

ADDON: Could not locate visualization.spectrum.so
...
ADDON: Could not locate visualization.projectm.so
...
ADDON: Could not locate visualization.goom.so

Die Addon-Pakages werden nicht mehr in den Kodi-Path entpackt, sondern nach „/usr/lib/x86_64-linux-gnu/addons“. Kodi selbst prüft diesen Pfad nicht. Nun kann man mit der Path-Variable rummspielen oder einfach ein Symbolik Link setzten …

ln -s /usr/lib/x86_64-linux-gnu/addons/* /usr/lib/kodi/addons/

network-manager speichert Passwort nicht

Eine kleine Unschönheit beim Upgrade hab ich beim NetworkManager unter xubuntu festgestellt.

Ich nutze Zertifikate um mich an meinem WLAN anzumelden (Radius). Diese setzen ein Password vorraus (anders lässt es der NM eigendlich nicht zu). Leider war das NM-Applet partou nicht in der Lage, eine ordentliche Config-File zu erzeugen, bei der das Password so hinterlegt wurde, dass das WLAN noch vor der Anmeldung verbunden werden konnte.

Dem konnte ich nur manuell beikommen. Unter /etc/NetworkManager/sysem-connections/ liegen die Config-Files. Die entsprechende Datei öffnen und manuell den passenden Parameter setzten
private-key-password=SuperSicher;)

HTPC mit Ubuntu 14.04

In den letzten zwei Wochen hab ich alle meine Rechner auf Ubuntu 14.04 umgestellt. Eine richtige Bruchlandung hab ich dabei nur bei meinem HTPC (auf Basis XBMC) erlebt. Hier eine kurze Zusammenfassung.

Da mein HTPC minimal aufgesetzt ist und keine unnötigen Dienste enthält hab ich erst mal versucht ein einfaches Upgrade aus dem System heraus zu machen. Die hätte den Vorteil gehabt, dass ich mir die folgenden 4 Stunden sparen hätte können. Das nvidia-337 Package hat das „zunichte“ gemacht. In den Trusty Sources zieht das gleich eine ganze Gnome Installation nach sich, die mir dann mein NoDM-Setup zerschossen hat und gleichzeitig die Platte gesprengt hat.

Danach folgte eine Neuinstallation. Eine stunde ging für ein fehlerhaft erstelltes USB-Image drauf, geschenkt, das ist Murphey, aber danach wurde es haarig. Unter Trusty fehlen einigen Paketen schlicht Abhängigkeiten. Ich hab 30 Minuten rumgefriemelt bis ich gemerkt habe, dass ein nodm kein xserver mehr mitinstalliert. Fehlende libraries werden auch nicht im Log erwähnt. Wozu auch ?

Hier meine manuell installierten Pakete:

  • xinit – wird von nodm benötigt
  • alsa-base/alsa-utils – für den sound
  • consolekit, pm-utils – für den shutdwon/suspend aus xbmc herraus.

Nachdem ich XBMC am laufen hatte, hat mich dann noch der „Shutdown/Suspend“ geärgert. Zum einen sind die oben erwähnten Pakete nicht installiert zum anderen wurde etwas an der Struktut geändert, so dass die Beispiele auf xbmc.org einfach nicht mehr passen.

Die korrekte polickit file sieht wie folgt aus:

[Actions for some-user]
Identity=unix-user:some-user
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*;org.freedesktop.udisks.*;org.freedesktop.login1.*
ResultAny=yes
ResultInactive=no
ResultActive=yes

Wichtig ist die Angabe org.freedesktop.login1.*. Die kann auf Suspend udn Hibernate auch eingeschränkt werden.

Danach lief mein HTPC wieder wie vor der Migration.

Erste Schritte im neuen Ubuntu 14.04 Server

Seit dieser Woche laufen bei mir die Updates auf das neue Ubuntu 14.04. Den Anfang machte gestern mein Server (nach „langer“ Vorbereitung). Nach diversen Problemen bei den letzten Updates hatte ich diesmal alle Vorbereitungen getroffen um die Ausfallzeit so „unauffallig“ wie möglich zu gestellten.

  • Wichtige Dienste wie Kerberos, Radius usw sind mittlerweile auf eigene Maschinen ausgelagert worden.
  • Der Server läuft mittlerweile auf einer „echten“ Serverhardware, inklusive Remote-Shell um im Fehlerfall eine lokale Anmeldung durchführen zu können.

Das größte Problem stellt der DNS-Server (Bind9) dar, der leider nicht auf einen meiner EdgeMax-Router zum Laufen zu bekommen ist. Fällt er längere Zeit aus, geht in meinem Heimnetzwerk nicht mehr viel.

Die Installationsroutine ist mittlerweile geübt. Manuell den aktiven Root-Raid 1 aufbrechen (Festplatte im laufenden Betrieb ausbauen). Anschließend wird die Platte direkt an eine VM weiter gereicht und das neue OS installiert. Die Installation verlief Problemlos, danach traten jedoch die ersten fehler auf. Wenn GRUB von einem RAD-Device starten soll, wirft er einen Fehler, bootet dann jedoch anstandslos weiter. Nach dem (erfolgreichen) Booten wird jedes „sudo“ von einer „memory leak“-Meldung begleitet. Diese wird durch das lib-pam-smb Paket verursacht. Nach dessen Deinstallation lief alles ohne Probleme weiter.

Einzig die Vergabe der Netzwerk-Interface Namen führte noch etwas zu Verwirrung. P4P1 hab ich so noch nie als Namen gesehen. Dem kann man aber mit einer passenden UDEV-Rule beikommen.

Der Tausch der Platten (diesmal bei ausgeschalteten Server) und der folgende „First Boot“ brauchten keine 5 Minuten. Bind und MySQL verrichtete sofort wieder ihre Dienste. Das mounten der XFS Laufwerke ging hingegen sofort auf die Bretter. Ein Blick ins „dmesg“ verrät, dass die Parameter „sunit“ und „swidth“ jetzt nicht mehr stillschweigend ignoriert werden, sondern der mount einfach abgebrochen wird. 5 Minuten später war das Storage gemountet und NFS (inkl. Kerberos) verrichtete seinen Dienst. Ab hier merkten die Endanwender (Familie) von den Arbeiten nichts mehr. Mit zwei Ausnahmen (Logitech Media server/Samba) liefen alle externen Dienste nach ca. 20 Minuten wieder.

Mehr Aufwand machte nur der neue Apache. Konfigfiles müssen immer auf „.conf“ enden, sonst werden sie ignoriert. Blöd das man das nur indirekt mitgeteilt bekommt. Nach einer Stunde rummbasteln ging mir dann ein Licht auf. Eine weitere Stunde später liefen wieder alle internen Monitoring Sites.

Richtig übel hat mir jedoch der Logitech Media Server mitgespielt. Der war am Abend gar nicht mehr zur Zusammenarbeit zu bewegen. Alle Squeezeboxen mussten manuell auf den Server von Logitech umgestellt werden. Da das Logging des Logitech Media Servers nicht sehr ergibig ist, konnte ich erste nach ein bisschen rumm probieren raus finden, dass die aktuelle Version 7.7.3 einfach nicht auf Ubnntn 14.04 lauf kann (Perl Version). Erst das Installieren des Nightly-Builds brachte Besserung,

Samba verrichtete zwar tadellos seinen dienst, jedoch waren die angeschlossenen Windows-Instanzen nicht mehr dazu zu bewegen sich an der Domäne anzumelden. Genauer gesagt konnte keine „Vertrauensstellung hergestellt werden“. Ein „rummfrickeln“ in den Untiefen der WindowsEinstellungen (regedit und policykit) brachten keine Besserung. Da ein Anmelden (Aufnehmen) in die Domäne klappt und auch ein Zugriff von Windows auf Samba hab ich nach 2 Stunden rumprobieren meine arbeiten eingestellt.

Kurzfazit: Ich hatte mehr „Ärger“ als erwartet. Gefühlt hab ich von 10.04 auf 14.04 aktualisiert. Das lag aber weniger an Ubuntu, als an den verwendeten Software-Paketen, bzw. hat 12.04 damals schon veraltete Pakete verwendet und der Sprung war jetzt merklich. Jetzt muss sich das System im Langzeittest beweisen. Da hab ich nun weniger Bedenken. Mahl sehen ob ich eine Uptime > 6 Monate hinbekomme.

Servergespeicherte Profile mit unison

Da CSync leider nicht meine Erwartungen erfüllt hat bzw. nicht im Ubuntu-Repository versorgt wird musste ich mich vor ein Weile nach Alternativen umschauen.

Dabei bin ich auf Unison gestoßen. Installiert man es auf Client und Server kann man via ssh sehr schnell große Datenmengen in beide Richtungen abgleichen. Man kann sogar eine Konfliktlösungsstrategie angeben, falls es sowohl auf Server als auch Clients zu Änderungen kam.
Mittels Exclude-List kann man gezielt steuern was übertragen werden soll. Sogar via Regex.

Beispielconfig:

root = /home/myuser
root = ssh://myuser@myserver.local//path/to/storage
batch = true

ignore = Path .unison
ignore = Path .kdevduchain
ignore = Path .kde*/cache-*
ignore = Path .kde*/socket-*
ignore = Path .kde*/tmp-*
ignore = Path .kde/share/apps/amarok/albumcovers
ignore = Path .kde/share/apps/nepomuk
ignore = Path .kde/share/apps/akregator/Archive


ignore = Regex [^\.].* # alle Dateien die nicht mir . beginnen werden ignoriert.

Das ganze kann man ohne Probleme über ein Skript beim Start oder Login automatisieren:

/usr/bin/unison sync_homedir -silent -prefer newer -times

Bleibt nur noch das Problem wie man den ssh-Daemon auf der Server-Seite dazu bekommt ohne weitere Passwortabfrage eine Verbindung zuzulassen. Da gibt es verschiedene Varianten wie z.b. das Public-Key-Verfahren (wobei der keyring automatisch aufgemacht werden muss) oder GSSAPI. Letztere ist relativ bequem einzusetzen, wenn man mal einen Kerberos eingerichtet hat. Dann muss man einfach folgende Konfiguration im SSH Daemon vornehmen.

# Kerberos options
KerberosAuthentication yes
KerberosGetAFSToken yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Anschließend akzeptiert der SSH Daemon nach einem Neustart auch Kerberos Tickets anstatt ein Password abzufragen.