openhabforum.de

Moin moin zusammen.

Ich bin Max und habe in unserem Eigenheim zunächst eine Heizungssteuerung über Homematic realisiert. Genutzt habe ich die CCU3. Was mir wichtig ist, keine Cloud Dienste zu nutzen.

Über die CCU3 war mir die Web Bedienung dann aber zu umständlich und ein Arbeitskollege hat mich auf OpenHab gebracht. Des Weiteren möchte ich einiges an OpenHab Funktionalität von unterwegs über das Smartphone steuern können.
Hier stehe ich gerade am Anfang von allem. Geringfügige Linux Kenntnisse sind vorhanden. In Punkto Code schreiben für OpenHab stehe ich gerade am Anfang.

Mein Vorhaben habe ich derzeit aufgrund der guten Dokumentation gem. der ausführlichen Anleitung von Klaus Rogall https://raspberry.klaus-rogall.de/index.html auf einem Rasppi zum laufen bekommen (Homegear und Openhab auf einem Pi, zusätzlich ein Zigbee Gateway). Hier und da waren einzelne Abweichungen von der Anleitung notwendig. Eine kurze Doku (die ich auch für mich selbst nutze) zum Einrichten findet ihr weiter unten.

Ganz oben im Thread schreibe ich zunächst mal meinen aktuellen Systemstatus und die aktuelle Fragestellung zum derzeit zu bearbeitenden Meilenstein.

Status: Aufbau Hard und Software (Homegear + Openhab) auf RaspPi abgeschlossen

next To/Do: Heizungssteuerung meiner betagte HM-CC-VD bzw. TC's von CCU3 nach Homegear und weiter nach Openhab übernehmen. Ziel ist es nicht die CCU3 zu nutzen, sondern alles auf einem RaPi laufen zu haben - wenn es geht. Ziel ist, dass ich in OpenHub z.B. die Option "Arbeitstag" oder "Frei" oder aber "Wintergarten an" oder aber "Wohnzimmer aufwärmen" aktivieren/deaktivieren kann. Später soll dann noch Steuerung weiterer Sensoren dazukommen (Bewegungsmelder, Licht etc....)
Hier frage ich mich insbesondere, wie die Zeitprogramme aus der CCU3 in OpenHub 3 realisiert werden können, oder ob hierzu ggf. eine Programmierung/Steuerung der alten Module über Homgear oder Raspmatic oder sogar meine CCU3 sinnvoller ist.

Frage: Das Anlernen der HM-CC-VD Heizungsregler ging in der Homegear Konsole problemlos.
Dazu habe ich die HM-CC-VD gem. Anleitung zurückgesetzt und Anschließend synchronisiert. Meine Annahme wäre, dass nur ein Device auftaucht. Nun ist aber immer zusätzlich ein weiterer Device zugekommen - Type String ist HM-CC-TC , also eine Art virtueller Wandthermostat? Es geht um die als heizregler_xCh2 bezeichneten Einträge.
Muss ich evtl. die Stellantriebe zunächst an die Wandthermostate verknüpfen und anschließend die Wandthermostate an Homegear verknüpfen?
In Openhab 3 bekomme ich aber zumindest die Werte für Valve State angezeigt und als Things sind die Wandregler auch aufgeführt.

viewtopic.php?t=236 hier habe ich ein paar Anhaltspunkte zur Konfiguration der Heizungsstuerung gefunden, aber wie ich das Verstehe, arbeitet Seppy hier mit einer Konfigurationssoftware für den Win Rechnuer und einem USB Stick für Homematic - korrekt?

Dokumentation - Teil 1 -Vorbereitung des Systems

Ich habe bewusst auf Gebrauchtteile zurückgegriffen. Dies gilt für alles weiter unten beschriebene bis auf das RaspPi Gehäuse.

ich habe mich für einen Raspberry Pi 3B+ entschieden. Hier funktioniert gem. Anleitung das Booten von SATA über USP problemlos und er fällt auch günstiger aus, als der Pi4.

Für HomeMatic/Homegear habe ich das empfohlene https://shop.codm.de/automation/homegea ... modul-v0.3 Modul für die Steckleiste übernommen. Warum welches Modul genommen wird, steht in Teil eins der oben genannten Quelle von Klaus Rogall.
Hinweis: Ich hoffe, dass die Empfehlung für meine Zwecke auch gilt

wie in der Anleitung beschrieben habe ich ein RaspBee Gateway zusätzlich zum Homematic eingesetzt. Es handelt sich bei mir allerdings um das RaspBee I. Da dies zukünftig für Indoor Bewegungsmelder und Fensterkontakte genutzt wird, kommt die Doku später.

Weitere Hardware gem. Guide (SD, Gehäuse) wurde übernommen, und ich bin sehr zufrieden damit.

Installiert habe ich das ganze aus Linux heraus mit SSH. Wer es lieber unter Windows mag, die Anleitung arbeitet auch mit Windows und Putty.

Teil 2 - Basiskonfiguration

hier habe ich auf das optimieren des Benutzerkontos unter 4 für die bash und vi verzichtet.
Auch auf das Einrichten von WLAN habe ich verzichtet
Tricky wurde es erst bei der Einrichtung des Reverse Proxy. Der Vorteil hier ist, dass ich kein SSH Port öffne und zum einen Zugang zum OpenHab und zum Anderen auch ins Terminal des RaspPi komme. Hier wird gem. Anleitung der Dienst Dataplicity genutzt, der sich auf Reverse Proxy spezialisiert hat. Das läuft dann mit Hilfe von Python. Die von Dataplicity zur Verfügung gestellten Ressourcen nutzen noch Python 2.7 -mein System hat schon 3.x installiert gehabt. Ich habe den einfachsten Weg gewählt und habe einfach Python 2.7 zusätzlich installiert. Danach lief der Dienst wie am Schnürchen.

Teil 3 - Ausbau zum Home Automation System

abgeschlossen, hier folgt die Doku, wo ich vom Guide von Klaus Rogalla abweichen musste

Danke und willkommen im Forum!

Was die Zeitprogramme betrifft, so ist die Philosophie in openHAB, dass es keine schnöden Zeitsteuerungen braucht
Es gibt verschiedene Optionen, mit dem Fehlen einer Zeitschaltuhr umzugehen:

• Schimpfen (bringt aber nix, haben schon Hunderte vor Dir gemacht)
• das iCal-Binding nutzen und die Zeitsteuerung über einen Kalender erledigen (entweder über Cloud, oder z.B. mit nextCloud oder OwnCloud zuhause gehostet - nur dafür evtl. etwas oversized)
• eine mehr oder weniger aufwändige Oberfläche programmieren und mit einer Menge Beschränkungen leben (für jede zusätzliche Zeitschaltung muss Code angepasst und erweitert werden)
• Erkennen, dass Zeitprogramme, wo man sie denn nutzen will, meist einmal eingestellt werden und danach allenfalls noch ein-, zweimal leicht korrigiert werden. Es braucht also im Grunde kein Interface "für jeden", sondern nur eine Möglichkeit, Zeitschaltungen zu erstellen, und das geht durchaus über die Rule engine.

Hallo udo1toni,

also den Fortschritt habe ich hier dokumentiert: https://forum.homegear.eu/t/homegear-un ... 021/4128/7

Sobald ich Zeit habe, bringe ich das hier auch auf Stand.

Ich finde deine Einwände recht interessant.

D.h. du würdest eher von Zeitprogrammen absehen, und z.B. eher einen Status definieren, z.B.

a) Personen zu Hause Schlafen
b) Personen zu Hause Homeoffice
c) Personen zu Hause Feierabend
d) Personen außer Haus

Darauf abgestimmt wären dann Regeln zu generieren die den Status entsprechend durch einen Kalendereintrag (caldav) oder locationtrackin oder was auch immer (z.B. bluetooth beacon) setzen. korrekt?

Du hast recht, die gesetzten Zeitprogramme erfordern dann ein ständiges anpassen. Daher wäre es glaube ich tatsächlich besser, die Wandthermostate im Status "Zentralengesteuert" zu lassen.

Ggf. könnte man eine zusätzliche Rule einsetzen wie "Party"

Verstehe ich dich richtig?

Gruß
Max

Ja, so ungefähr. Es gibt ja verschiedene Anwendungsfälle einer Zeitsteuerung.
Beispiel Wecker: Du kannst einen Wecker auf 6:45 Uhr stellen, weil Du da aufstehen musst. An einem anderen Tag musst Du um 7:30 aufstehen.
Statt nun eine Einstellmöglichkeit für Stunde und Minute zu schaffen, könntest Du auch ein Dropdown Feld definieren, in dem diese Wckzeiten auswählbar sind.
Und weil diese Zeiten vielleicht davon abhängen, wann Deine Kinder in die Schule müssen, wäre es sinnvoll, das Feld automatisch nach dem Stundenplan zu setzen, der als Kalender verfügbar ist. Vielleicht Bist Du im Schichtdienst. Du hast dann z.B. 5 verschiedene Schichtzeiten. Dann reichen also diese 5 Zeiten (plus eine Zeitspanne für die Zeit, die Du bis zur Arbeit brauchst) als Auswahl, oder auch eine Anbindung an den Dienstplan.

Rolllädensteuerung ist auch ein typischer Fall für Zeitsteuerung, dabei sollen die Dinger eigentlich viel eher Helligkeitsgesteuert fahren, aber mit bestimmten Ober- und Untergrenzen. Das kannst du bequem mit dem Astro Binding erledigen und brauchst keinen Helligkeitssensor, der z.B. bei schlechtem Wetter komplett andere werte liefern wird als bei Sonnenschein (was aber nur sehr eingeschränkt Einfluss auf die Rollläden haben sollte).

Oder (tagesaktuell) die Weihnachtsbeleuchtung. Die sollte natürlich am Montag nach Totensonntag einschalten und (abhängig vom Bundesland) bis 6. Januar oder evtl. auch bis Mariä Lichtmess - zu bestimmten Zeiten ein- bzw. ausschalten. Solche Steuerungen sind mit konventionellen Schaltuhren nicht realisierbar, auch solchen, die über Software abgebildet werden. Es ist aber kein großes Problem, die entsprechenden Zeitpunkte automatisch zu ermitteln.

Anwesenheitserkennung (und auch die Vorhersage einer nahenden Ankunft - Stichwort Geofencing) können einen Großteil anderer Anforderungen sehr elegant erledigen, genau wie z.B. (letztens erst hier im Forum aufgetaucht) geplante Abfahrzeiten und das Laden eines Elektroautos auf den Punkt, damit die Akkus schon warm sind, wenn man los fährt. Man kann sich gar nicht vorstellen, was alles realisierbar ist, ohne eine konventionelle Schaltuhr zu bemühen. Man muss dafür aber über den Tellerrand hinaus schauen. Und natürlich ist das nicht unbedingt endanwenderfreundlich, das wird es aber, wenn der Anwender tatsächlich gar nichts mehr tun muss.