Zwischenstand und Überlegungen, wie's weitergehen soll

Manul · October 31, 2016, 8:23pm

Das ist quasi der Folgethread zu meinem Starthilfe-Thread - ich möchte einfach mal kurz für mich selbst sammeln, wo ich derzeit stehe und wo ich noch hin will. Kommentare und Anregungen dazu sind sehr gerne gesehen, vielen Dank im voraus! Also:

Wo stehe ich?

Vorhandene Geräte: Je 1 x Wandthermostat HM-TC-IT-WM-W-EU, Heizkörperthermostat HM-CC-RT-DN, Fensterkontakt HM-Sec-SCo, neun Stück Rauchmelder HM-Sec-SD-2
Heizungsgeräte erfolgreich wechselseitig aneinander angelernt
Rauchmelder erfolgreich zu Gruppe verbunden
Jessie und Homegear auf dem Pi3 installiert
Heizungsgeräte an Homegear angelernt - Direktverknüpfungen blieben erhalten
Möglichkeiten, die Geräte zu konfigurieren: HomeMatic-Konfigurator, HomeMatic-Manager, Homegear RPC - keine dieser Möglichkeit unterstützt Gruppen
zwei Rauchmelder an Homegear angelernt. Hierbei ging der Kontakt zu den anderen RM verloren. Keine Möglichkeit gefunden, die RM über Homegear miteinander zu verbinden.
MQTT für Homegear aktiviert, Mosquitto auf dem Pi installiert
mit der heißen Nadel eine Aufzeichnung der per MQTT gesendeten Werte für Luftfeuchte, Ist- und Solltemperatur, Heizungsventilöffnung sowie Fensterzustand in eine RRD-Datenbank gestrickt und in meine selbstgebastelte Kellerlüftungslösung integriert.

Was hätte ich gerne noch:

Eine komfortable Möglichkeit, die Geräte zu konfigurieren, möglichst mit Gruppenfunktion
Eine Möglichkeit, Ist-Zustand und Verlauf anzusehen und Einstellungen (Manueller Modus, Auto-Modus, Party-Modus, Solltemperatur etc.) vorzunehmen
Eine Möglichkeit, die Rauchmelder zu integrieren und auf Alarme reagieren zu können, ohne die Verknüpfung der RM untereinander aufzuheben
Die Möglichkeit, komplexere Ereignisse/Abläufe zu programmieren, als die Direktverknüpfungen zulassen. Dafür wäre mir eine wie auch immer geartete Skriptsprache lieber als ein Klick-Interface. Die Möglichkeit, externe Skripte einzubinden, wäre ein Bonus.
Schön wäre es, wenn sich diese Wünsche mit möglichst wenig verschiedenen Systemen realisieren ließen. Idealerweise also eine Bedienoberfläche für alles außer das Skripten.
Schön wäre außerdem eine Möglichkeit, meine Kellerüberwachung in die Oberfläche zu integrieren.
Wenn ich eine Lösung habe, würde ich gerne die Heizungssteuerung und Klimaüberwachung auf drei weitere Räume ausdehnen. Weitere Automatisierungen sind vorerst nicht geplant, wie ich mich kenne, fällt mir aber bestimmt mit der Zeit noch was ein.

Welche Optionen sehe ich:

OpenHAB

Habe ich versuchshalber installiert, Integration der Homematic-Komponenten relativ problemlos. Konfigurierbare Oberfläche für Ist-Zustand und einfache Einstellungen. Komplexere Konfigurationen der Geräte (bspw. Wochenprogramme) scheinen nicht möglich. Möglichkeit von Speichern und Ansehen des Verlaufs/der Historie ist mir noch unklar.

Node-Red Dashboard

Habe ich mir noch nicht näher angeschaut. Wenn ich das richtig verstehe, recht frei konfigurierbares Dashboard. Programmierung durch Zusammenklicken von Ablaufdiagrammen? Ist hier auch eine Skriptprogrammierung möglich? Bedienoberfläche für die Geräteeinstellungen müsste ich mir vermutlich selber basteln. Aufzeichnung der Historie/des Verlaufs müsste ich wohl extern realisieren. Darstellungsmöglichkeiten dafür dann wohl wieder vorhanden.

FHEM

Würde, wenn ich es richtig verstehe, bedeuten, Homegear nicht mehr zu verwenden. Scheint mir in der Oberfläche etwas spartanisch. Wohl flexible Programmierung möglich, Unterstützung einer Vielzahl von Komponenten, recht ausgereift.

YAHM

Bringt quasi die CCU-Oberfläche auf den Pi. Vermutlich die beste Integration mit HomeMatic, dafür vermutlich eingeschränkte Erweiterbarkeit und wenig Unterstützung anderer Systeme.

Mischlösung

Ich könnte natürlich auch mein eigenes System fürs Monitoring und das Setzen von Parametern ausbauen. Restliche Konfigurationen dann über den HM-Konfigurator. Programmierung entweder über eigenes Skript, das MQTT auswertet, oder über Homegear. Könnte ich natürlich am genauesten auf meine Bedürfnisse zuschneiden, wäre aber vermutlich auch die meiste Arbeit. Auch, wenn neue Komponenten/Bedürfnisse dazukämen, müsste ich alles selbst implementieren.

Weitere Optionen: iobroker, PiMatic, was weiß ich noch alles

Habe ich mir noch nicht angeschaut. Ich bin jetzt schon ausreichend verwirrt. Falls nicht noch ein ganz überzeugendes Argument für eine weitere Lösung kommt, denke ich, ich sollte unter den obigen Lösungen eine finden, die ich an meine Bedürfnisse anpassen kann.

Jetzt seid Ihr dran: Gedanken, Anregungen, Anmerkungen Vorschläge zu meinen Überlegungen? Habe ich irgendwas komplett falsch verstanden? Was habe ich übersehen? WIe gesagt, ich bin erschlagen von der Vielfalt der Optionen und tue mich mit der Entscheidung, wie’s weitergehen soll, sehr schwer. Daher schon jetzt herzlichen Dank für alle Beiträge! Ich bin gespannt…

pmayer · November 21, 2016, 12:31pm

Hi @Manul,

danke für den wirklich ausführlichen Post und großen Respekt für deine Kellerlösung.

Ich möchte kurz eine Lanze für node-red brechen, da du glaube etwas falsch verstanden hast. Node-red ist eine Oberfläche um Abläufe im Internet der Dinge zu automatisieren. “Wiring the Internet of things” nennt es IBM, die es als open-source programmieren. Damit kannst du jegliche Schnittstellen (REST-JSON, SOAP, etc.) sowie HTTP-Requests jeglicher Art ansprechen und das Ergebnis dieses Requests weiter verarbeiten (Message Flow). Wenn es für irgend etwas noch keinen fertigen Node geben sollte, kann man auch in einem function-node mit Javascript programmieren.
Fertige Nodes gibts es für tausend Sachen: http://flows.nodered.org/

Node-red-dashboard ist nur ein weiterer Node, der eben ermöglicht die Daten des Message Flows auszugeben. Natürlich kannst du die verarbeiteten Daten auch in eine Datei, an eine Datenbank oder wohin auch immer geben und später wieder laden.

Hier mal ein Beispiel ein fix zusammen gebauten Steuerung für einen Enigma2-Satellitenreceiver:

oder ein Beispiel für eine Temperatur mit Persitenz und Data-Logging in mysql:

Allerdings wirst du glaube bei keiner Lösung die von dir gewünschte Gerätekonfiguration finden. Vielleicht bei der CCU, die kenne ich nicht - bisher immer nur homegear verwendet.
Die Frage wäre aber, ob du das ausser bei der initialien Einrichtung brauchst.
Wochenprogramme sind natürlich ein Thema. Da bin ich dazu übergegangen die Thermostate im Standardprogramm laufen zu lassen oder sie auf manuell zu schalten und per node-red zu steuern (Partytaste)

Ich arbeite momentan - soweit es meine Zeit zulässt - am Webinterface für homegear, was für diese Konfigurationsaufgaben genutzt werden soll. Die Gruppierung der Geräte, sofern ich das mit meinen Max!-Devices hier testen kann, steht ganz oben auf der Liste.
Leider ist es da noch nicht soweit wie es sein soll um @sathya’s karge Freizeit steht, wissen wir ja

Scripten kannst du mit PHP in homegear selbst. Ich für meinen Teil - obwohl ich PHP-Entwickler bin - hab die Logik aber gerne an einer Stelle zentral oder im Gerät.
Mit der PHP-Funktion addLink() kannst du auch zB über ein homegear-script die Devices miteinander verbinden.

Nur das, was mir gerade alles dazu einfiel. Gibts mit Sicherheit noch mehr

so long,
p

Manul · November 1, 2016, 7:31pm

Hallo p,

vielen Dank für die Ausführungen zu Node-Red - so ähnlich hatte ich das durchaus verstanden, habe ich vielleicht nicht so glücklich ausgedrückt. Die Bilder, die Du gepostet hast, sind das was ich mit “Zusammenklicken von Ablaufdiagrammen” meinte. Werde ich mir aber auf jeden Fall mal anschauen.

Die Möglichkeit, die Geräte zu konfigurieren, wäre mir schon wichtig. Deine Lösung der Steuerung komplett über Node-Red möchte ich ungern übernehmen, ich hätte schon gern, daß das Programm auch weiterläuft, wenn meine “Zentrale” mal ausfällt. Wenn die HM-Geräte diese Möglichkeit schon bieten, möchte ich sie auch nutzen: So viel wie möglich autonom in den Geräten und die Zentrale greift nur in Fällen ein, die die Geräte nicht allein gebacken bekommen.

Zur Not kann ich die Konfiguration aber sicher über den HM-Konfigurator vornehmen und mir halt ein Skript schreiben, daß zumindest das Wochenprogramm vom Wand- zu den Heizkörperthermostaten überträgt.

Zum addLink() habe ich im Rauchmelderthread geantwortet - das hat’s zumindest für die Rauchmelder nicht gebracht. Andere Geräte kann ich vermutlich sowohl darüber als auch über HM-Konfigurator oder HM-Manager pairen.

Schönen Abend noch,

Manuel

pmayer · November 1, 2016, 10:53pm

Hey @Manul,

da bin ich völlig bei dir. Aber was spricht dagegen mit node-red (oder jeder anderen Automatisierung) eine Logik zu schreiben, die die Programme in den Geräte ändert?

Beispielweise könnte ich bei den von mir verwendeten Max!-Thermostaten einfach in node-red-dashboard ein paar Buttons und Einstellmöglichkeiten vorsehen, die die Werte auf den im Gerät hinterlegten Programmwerten ändern: https://www.homegear.eu/index.php/MAX!_BC-RT-TRX-CyG-3_Reference (TEMPERATURE_MONDAY_1, TEMPERATURE_MONDAY_2, etc.)

Oder habe ich falsch verstanden, was du erreichen willst?

so long,
p

Manul · November 2, 2016, 8:25am

Dagegen spricht gar nichts, so hatte ich Deine Lösung nur nicht verstanden. Ich wollte lediglich sagen, daß das hier

für mich keine Lösung ist, da ich auf jeden Fall die Wochenprogramme nutzen und auch anpassen möchte. Wie ich das mache, ist mir letztlich egal…

Wie ist denn der Stand beim Webinterface? Gibt’s da schon eine Beta oder so, die ich mir mal anschauen könnte? Wird das auch Open Source werden?

pmayer · November 2, 2016, 10:29am

Das muss @sathya entscheiden - soweit ich weiß open source. Übersicht über die devices, benennen von devices und pairing geht darüber schon.

trilu · November 7, 2016, 3:02pm

Habe mir gerade eine interessante Lösung angeschaut - home-assistant.io
Sieht gar nicht so schlecht aus und eine homegear Verbindung gibt es auch.
Das mit den Config Scripts in Yaml ist etwas gewöhnungsbedürftig, geht aber recht schnell.
Systemlast ist minimal über idle auf dem Raspberry
Muss mal versuchen ob ich damit eine einigermaßen frauentaugliche Oberfläche hin bekomme…
Viele Grüße
Horst

pmayer · November 7, 2016, 3:06pm

Sers @trilu,

home-assistant.io ist wirklich schick und hat vor allem sehr viele Module (https://home-assistant.io/components/#all). Mir ging die Programmierung nicht recht von der Hand und für mich fiel es leider aus, da es keine Max!-Geräte über das homematic Modul anbinden kann sondern eben NUR homematic.

Zum Zeitpunkt als ich es mir angeschaut hatte, auch nur 3 Komponenten. Das sind aber mittlerweile mehr geworden: https://home-assistant.io/components/homematic/

Funktionierte über homematic-RPC aber einwandfrei mit homegear.

so long,
p

trilu · November 7, 2016, 3:39pm

Die MAX Geräte müssten doch relativ leicht einzubinden sein, Homegear macht ja keinen Unterschied ob Max oder Homematic Thermostat und die Datenpunkte sind ja auch die selben Dank Sathya.
Wie ich gelesen habe bist Du gerade dran was Eigenes mit Sathya zu proggen - kennt ihr das https://www.behance.net/gallery/9080423/HEIMA-Smart-Home-Automation-UI
Finde ich total schick!

pmayer · November 7, 2016, 3:55pm

Nene, ich bin da nichts eigenes am proggen. Ich unterstütze @sathya nur ein wenig beim Webinterface.

Ich habe es in einer Testinstallation nicht hinbekommen die Max!-Geräte mit home-assistant zu schalten, ausser über mqtt - dann aber eben nicht mit dem homematic-modul von home-assistant.

trilu · November 7, 2016, 4:30pm

Sehe gerade - Max über Homegear sollte gehen - siehe ganz unten im file…

github.com

danielperna84/pyhomematic/blob/master/pyhomematic/devicetypes/thermostats.py

import logging
from pyhomematic.devicetypes.generic import HMDevice
from pyhomematic.devicetypes.sensors import AreaThermostat
from pyhomematic.devicetypes.helper import HelperValveState, HelperBatteryState, HelperLowBat, HelperLowBatIP

LOG = logging.getLogger(__name__)


class HMThermostat(HMDevice):
    """
    HM-CC-RT-DN, HM-CC-RT-DN-BoM
    ClimateControl-RadiatorThermostat that measures temperature and allows to set a target temperature or use some automatic mode.
    """
    def __init__(self, device_description, proxy, resolveparamsets=False):
        super().__init__(device_description, proxy, resolveparamsets)

        # constante
        self.AUTO_MODE = 0
        self.MANU_MODE = 1
        self.PARTY_MODE = 2

This file has been truncated. show original

pmayer · November 7, 2016, 4:33pm

Ah, tatsächlich. Super! Das war damals noch nicht. Ist aber auch locker ein halbes Jahr her…

Manul · November 7, 2016, 8:39pm

Danke Euch beiden! Da ich im Moment nicht so viel Zeit aufwenden kann, wie ich gerne würde, gibt’s nicht allzu viel Neues von mir. Trotzdem ein kurzes Update:

Ich habe mir zwischenzeitlich Node-Red installiert. Das geht irgendwie gar nicht an mich. Ich glaube nicht, daß das mein Weg wird.
Über Home Assistant bin ich zwischenzeitlich auch gestolpert. Hat mir auf den ersten Blick gut gefallen, zumal ich eine gewisse Python-Affinität habe. Werde ich mir auf jeden Fall genauer anschauen bzw. testweise installieren.
Ich überlege, doch noch YAHM statt Homegear auszuprobieren. Da hätte ich Gruppen und könnte vermutlich auch meine Rauchmelder anlernen, ohne ihre Gruppierung aufzulösen. Anbindung an Home Assistant ginge nach meinem Verständnis damit auch, MQTT ließe sich nachrüsten. Außerdem ist es - da letztlich die Software, die auch auf der CCU2 läuft, weiter verbreitet. Dementsprechend ist auch der Personenkreis, der Support leisten kann, größer.

Das letzte bitte nicht falsch verstehen: @pmayer und @sathya leisten hier einen tollen Job, der weit über das hinausgeht, was man unentgeltlich erwarten - geschweige denn fordern - kann. Aber sie sind eben im wesentlichen zu zweit und Sathya hat, verständlicherweise, derzeit nicht so viel Zeit fürs Forum. Ich habe jetzt drei unbeantwortete Threads seit 6-10 Tagen hier im Forum stehen: Das ist - auch wenn, wie gesagt, voll in Ordnung - trotzdem suboptimal…

pmayer · November 7, 2016, 9:17pm

Will dich jetzt nicht hinhalten aber habe heute mit @sathya gesprochen und ihn auf die unbeantowrteten Posts hingewiesen. Der ist grade einfach zu sehr im Stress…

Manul · November 8, 2016, 11:43am

Das ist ja auch völlig okay. Wie geschrieben habe ich derzeit auch nicht beliebig viel Zeit. Ich schau jetzt einfach mal, wie’s weitergeht. Wenn ich irgendwann demnächst Zeit habe und die Themen dann nach wie vor unbeantwortet sind, probiere ich vielleicht erst mal was anderes aus. Ist ja auch keine Einbahnstraße…

pmayer · November 8, 2016, 11:47am

Richtig… und homegear gilt ja in erster Linie der Hardwareanbindung.

Schreib auf jeden Fall was du herausfindest. Vielleicht können wir das ja mal in irgend nem Guide zusammen tragen. Weil die (w/r)ichtigen Fragen werden ja oft genug gestellt.

Andreas.Fink · November 21, 2016, 12:08pm

Ich setzte ich mehreren Umgebungen auf OpenHAB in Kombination mir Homegear, die Skripting-/Rules-Engine von OpenHAB ist sehr mächtig. Aber in der Tat ist es nicht sonderlich gut zur Konfiguration von HomeMatic-Komponenten geeignet. Das ist dem generischen Ansatz des OpenHAB-Cores bzw. jetzt ja (Eclipse Smarthome) zuzuschreiben.

Ich verstehe, dass man sich wie @Manul nicht allein auf eine zentrale Steuerung verlassen möchte und die Steuerung lieber den Komponenten selbst überlassen möchte. Mir war der Umfang der Einflussnahme-Möglichkeiten die die HomeMatic-Komponenten mit sich bringen allerdings zu gering und so musste ich mich auf eine zentrale “Intelligenz” einlassen.

Nach einigen Abwägungen ist es nach einer ersten Realisierung mit FHEM dann die Kombination aus OpenHAB und Homegear geworden, die auf einem USV-gepufferten zentralen Server (bei mir Zuhause ein ESX-Server auf MacMini-Basis mit einer Linux-VM für Homegear und OpenHAB / bei kleineren Installationen Banana Pi`s oder LeMaker HiKey/Guitar mit Batteriepufferung) und Homematic LAN-Gateways, die über einen batteriegepufferten Switch per PoE+PoE-Splitter mit Strom versorgt werden.

Die Stärke von OpenHAB ist, neben der äußerst mächtigen Skript-/Rules-Engine auf XText-Basis, sicherlich die Kompatibilität zu 100ten von Herstellern/System/Diensten. So ist unsere private Hausautomation z.B. abhängig von unseren Google-Kalendern (z.B. für die Heizungsplanung / “wann muss angefangen werden zu heizen, damit es warm ist wenn ich oder meine Freundin heim kommt”), Anwesenheit/Standort mittels IFTTT und der Geofencing-Funktion der IF-App, Wetter, Feiertagen, … So könnte OpenHAB auch mit dem Harmony-Binding, mit entsprechenden Lichteinstellungen, darauf reagieren, wenn ich mit meiner Logitech Harmony z.B. den Fernseh einschalte, was meiner Freundin allerdings sicherlich “to much” wäre, oder umgekehrt den TV einschalten, wenn ich in OpenHAB das “Fernsehen”-Szenario auswähle.

In einem gewissen Maße wäre es auch möglich Regel-/Skriptbasiert die Einstellungen der HM-Wand/Heizungsthermostate zu modifizieren, so dass diese im Automatik-Modus laufen und nur deren Zeit-/Temperaturpläne durch OpenHAB so gesetzt werden wie es voraussichtlich gewünscht wird. So dass diese auch noch sinnvoll arbeiten, wenn einige Zeit die OpenHAB- oder Homegear-Instanz ausfällt.

Aber leider kommt man schon bei der Lichtsteuerung mit HomeMatic Wandtastern und Schaltaktoren schnell an die Grenzen was deren interne Steuerung beherrscht, da kann man auch mit “hochkreativer” Programmierung der HM-Komponenten nichts machen.
Beispiel: Unsere Wandtaster für das Schlafzimmerlicht schaltet bei einfachem Drücken oben die Deckenlampe ein und unten wieder aus (normales Lichtschalterverhalten), bei längerem Drücken oben wird die eine Nachtischlampe getoggelt (also wenn sie an ist ausgeschaltet und wenn die aus ist eingeschaltet) und bei längerem Drücken unten die 2. Nachttischlampe getoggelt. Diesem Sinn entsprechend verhalten sich auch die Schalter an beiden Seiten des Bettes: Kurzes drücken oben/unten schaltet die eigene Nachtischlampe an/aus, langes Drücken unten toggelt die Nachttischlampe auf der anderen Bettseite und langes Drücken oben toggelt die Deckenlampe). Das habe ich auch nach längerem Überlegen nicht in den HomeMatic-Komponenten selbst abgebildet bekommen.

Auch in der Firma setze ich eine OpenHAB-Instanz ein um komplexe-Steuerungsaufgaben zu realisieren, so das im Brandfall (Serverraum Brandlöschanlage löst Alarm aus + zusätzlicher Temp-Anstieg-Erkennung in den Racks/dem Serverraum) nach einer Wartezeit die virtuellen Maschienen und danach die Virtualisierungsserver und Storage-Systeme geregelt heruntergefahren werden und zuletzt die Stromversorgung des Serverraums unterbrochen wird und die USVs abgeschaltet werden. Natürlich geht parallel dazu eine Brandmeldung per eMail/Push-Notification/SMS(über einen LTE-Router) raus. Der Versand der eMails beginnt schon mit einem Voralarm (1 Melder der BLA lößt aus) und es wird ein Screenshot der Serverraum-Video-Überwachung angehängt. Die eMails werden, solange möglich, in regelmäßigen Abstängen versendet. Den Shutdown-Vorgang kann man natürlich nach Erhalt der ersten eMail noch innerhalb der Wartezeit eingreifen bzw. den Shutdown vorab deaktivieren wenn man schon während des Voralarm sieht, dass es ein Fehlalarm ist oder ein Shutdown nicht nötig ist (z.B. kleines Feuer bereits mit CO2-Handlöscher gelöscht).

Wenn Ihr Fragen zu solche Realisierungen habt, lasst es mich wissen, ich unterstütze da gerne.

Gruß Andreas

pmayer · November 21, 2016, 12:43pm

Hi @Andreas.Fink,

erst mal WOW! Danke für die ausführliche Erklärung.

Du beschreibst genau das Problem, was ich mit der “eigenen Intelligenz” auch sehe. Für einfache Schaltaufgaben sicher ausreichend und autark einsetzbar aber wenns dann doch komfortabler/komplizierter wird… dafür hat ja sogar eq-3 die CCU eingeführt.

Durch deine Absicherung mit der USV ist man ja schon ein ganzes Stück weiter - auch wenn es keinen Sinn macht ein Licht einzuschalten, wenn kein Storm da ist. Un die Heizung läuft ja mittlerweile auch nicht mehr ohne Interessanter ist es da den Fall abzusichern, wenn mal die Sicherung des “Technikraumes” raus haut.

Ich denke mit den HA-Softwaresystemen verhält es sich momentan so wie mit jeder Software: Man muss sich das passende für seinen Anwendungsfall raus suchen.
Node-red tut bei mir alles was ich will und noch einiges mehr. openHab hat mittlerweile mit der 2beta einen Stand erreicht der sehr gut zu funktionieren scheint. Vor allem was, wie du schon sagst, die Interoperabilität angeht.
Ein Freund von mir ist gerade völlig begeistert von io.Broker weil er dort wenig programmieren muss und trotzdem ans Ziel kommt. Für die nicht versierten liegt nämlich da bei openhab und node-red genau der Nachteil.

Fänd es super, wenn du dich hier ein wenig einbringen kannst. Irgendwie wir die Idee eines “Starter-Guide” immer naheligender

so long,
p

Manul · November 21, 2016, 2:31pm

Auch von mir vielen Dank @Andreas.Fink für die ausführliche Schilderung. Ich bin aus Zeitmangel noch nicht wirklich weiter, lese aber nach wie vor interessiert hier mit.

Da ich fürs erste keine wirklich komplexen Dinge plane, würde ich vorerst gerne beim Ansatz “so viel wie möglich auf den Komponenten autark, Eingriffe durch die Zentrale nur, wo das nicht ausreicht” bleiben - aber natürlich trotzdem möglichst flexibel bleiben und mir den Weg für zukünftige Erweiterungen nicht verbauen.