openhabforum.de

Hallo,

ich hatte HM und HM-IP geräte und Pivccu für steuerung. hm und hmip geräte kann man nicht direkt verbinden; deshalb habe ich einige ccu-programme auch.

Nun habe ich einige tasmota-geräte und en Paar echo-dot. Ich habe openhab installiert, damit die untereinander kommunizeren können. Alles hat schon geklappt.

Was schlagt ihr vor? ccu-programme behalten oder löschen und alles über openhab steuern?

Ich denke, ccu programme sind schneller und stabiler (weil es nicht mit openhab kommunizieren muss. Aber ich verzweifle stark daran, dass dadurch Konflikte vorkommen kann.

Hat jemand schon erfahrung? Was ist euren vorschlag?

Ich habe auch eine ccu3 und openHAB laufen. Auf der ccu3 habe ich meine Fenstersensoren und ein Aussenthermometer laufen. von der ccu-Programmierung habe ich überhaupt keine Ahnung und mich bisher auch nicht damit befasst. In diesem Fall nutze ich OH nur zur Visualisierung der Sensoren und der Temperatur. Es spricht ja nichts dagegen die Steuerung der HM/HMIp-Geräte untereinander in Homematic abzuwickeln, im Gegenteil, dadurch muss ja OH weniger tun.
Allerdings habe ich auch AVM-Heizkörperthermostate im Einsatz und da nutze ich die HM-Werte (auf/zu) um die Thermostate in OH an- und auszuschalten. Und das ist ja auch die Stärke von OH. Du kannst hier verschiedene "Insellösungen" zusammenfassen und miteinander kommunizieren lassen.

Viene Dank für die Antwort.

Openhab und Pivccu sind in einem raspberryPi4; also entlastung von eine ist belastung für andere.

Wenn OH-Programme kein nachteil haben, dann bevorzuge ich Openhab. Denn Ich werde programme für tasmota sowieso in OH schreiben. Wenn alles in inem Platz sind, dann habe ich besseren Übersicht.

Ich habe mich dafür entschieden, alle Programme ins Openhab zu übertragen.

..wie gesagt ich kenn die Homematic-Programmierung nicht. Aber ich könnte mir vorstellen, dass es einen gewissen Charme haben kann Programme in der ccu laufen zu lassen, z.B. wenn du openHAB herunterfahren möchtest/musst, dann läuft deine ccu einfach weiter.

Vielleicht beteiligen sich noch mehr an dieser Diskussion und bringen ihre Erfahrungen ein.

Es ist immer sinnvoll, eine Mischung zu machen. Alles, was ausschließlich homamatic betrifft, solltest Du, soweit möglich, in Homematic programmieren. So fällt möglichst wenig aus, falls openHAB mal ein Problem hat.

Ich nutze knx, die Grundfunktionen laufen allesamt autark. Sobald es aber um Automation geht, greift openHAB ein. Natürlich liegt das auch daran, dass ich keine Lust hatte, noch extra Logikmodule für knx zu kaufen aber die Aufteilung ist in meinen Augen sinnvoll. openHAB macht es "nett", das"Überlebenswichtige" funktioniert aber auch komplett ohne openHAB - z.B. fahren die Läden vollautomatisch. Wenn openHAB steht, habe ich aber einen Wandtaster, mit dem ich alle Läden im ganzen Haus auf einen Schlag öffnen oder schließen kann.

Ich kann mich udo nur anschließen: was sich in einem System - hier CCU - sauber formulieren lässt, sollte man dort erledigen. Ich habe ca. 10 Heizkörper-Thermostaten mit HM-Aktoren. Die Steuerung erfolgt lokal im Thermostaten und in der höheren Ebene in der CCU. Gleiches gilt für die Lichtschalter und die Rollläden. Erst wenn zwischen Systemen vermittelt werden muss, setze ich auf openHAB.

Grüße, Kurt

Hallo in die Runde,

ich bin neu im Forum, da ich hoffe, hier eine Antwort zu finden.

Auch ich befasse mich mit dem Thema ccu oder openhab.

Zunächst mal kurz ein Blick auf mein System.
Ich benutze schon seit vielen Jahren ein Homematic-System für meine Heizkörpersteuerung, erst eine CCU2, seit wenigen Jahren RasperryMatic auf einem Pi3.
Da meine Frau Lehrerin ist mit unterschiedlichen Tagesabläufen, habe ich Zeitprogramme für jeden Tag und jeden Raum in der CCU hinterlegt. Die Zeitprogrammierung mache natürlich ich, meine Frau wäre da überfordert.

Mein Gedanke war, wie kann ich es meiner Frau auf einfache Weise möglich machen, auch eine Zeitsteuerung vorzunehmen?
Ein Stöbern im Internet ergab dann teure Spezialsoftware, Apps (mit eingeschränkten, eigentlich nur Monitor- Funktionen), ...
Dann stieß ich u.a. über Artikel in der Computerzeitung ct auf Openhab und auch Node Red bzw. Redmatic.

Nach etlichem Probieren mit Redmatic bin ich dann bei Openhab eingestiegen. Habe mir das Buch "Smart Home mit openHAB 2" von Marianne Spiller besorgt und durchgearbeitet.
Heraus kam dann eine ansehliche Sitemap, über die ich alle Informationen meiner Heizkörperregelung darstelle.

Was mir jetzt leider fehlt, ist eine "ansehliche" Zeitprogrammierungsmöglichkeit über das Openhab-Interface. Ich meine hier nicht die Programmierung von Rules im "Source Code".

Darüber habe ich bisher vergeblich versucht, was zu finden. Entweder ich habe nicht die richtigen Begriffe verwendet, oder es ist nicht möglich.

Weiß hier jemand, ob das prinzipiell möglich ist oder ob das Openhab-Interface hierfür nicht vorgesehen ist?

Schon mal herzlichen Dank im Voraus für Eure Zeit, mein Problem zu lesen und darauf zu antworten.

Lustig, das Thema ist ein totaler Dauerbrenner...

Also zunächst mal sollte ein smartes Haus eine solche Zeitsteuerung eigentlich obsolet machen und openHAB hat hier schon Einiges zu bieten.
Wer aber trotzdem (notfalls auch übergangsweise...) unbedingt eine Zeitsteuerung haben möchte, für den ergeben sich mehrere Möglichkeiten:

1. Steuerung über Kalender.
   openHAB bindet z.B. über das iCal Binding einen Kalender ein, der dann als Quelle für Schaltbefehle verwendet werden kann. Da der Kalender auch im Handy erreichbar ist, ist das eine auch für Laien bedienbare Option.
2. Eigene Auswahlfelder für Stunde und Minute z.B. für jeden Wochentag.
   Allerdings muss man sich darüber im Klaren sein, dass man dort viele Items anlegen muss, damit die simulierte Schaltuhr über die UI bedienbar wird. Ohne Rules geht hier gar nichts, aber der Endanwender merkt davon in der Theorie nichts. Für diese Art Schaltuhren gibt es in allen mir bekannten Foren etliche Beispiele.
3. Ein anderes Bedienkonzept.
   Es geht in Wirklichkeit nicht darum, zig Ein- und Ausschaltzeiten pro Tag minutengenau zu definieren. Stattdessen gibt es eine überschaubare Liste an möglichen Schaltterminen (Ich bin Schichtdienstler mit ehemals sehr weitem Einsatzbereich - es gab Zeiten, da hatte ich zwanzig verschiedene Dienstzeiten, täglich ohne festes Schema wechselnd - jetzt sind es nur noch sieben) zu denen bestimmte Schaltereignisse passieren müssen. Es wäre also vermutlich am sinnvollsten, in der UI ein Auswahlfeld zu definieren, welches dann entsprechende Möglichkeiten bietet (z.B. 1. Stunde, 2. Stunde, ...) und die Auswahl des entsprechenden Werts wird dann von einer Rule genutzt, um die passenden Aktionen zu bestimmten Zeiten auszuführen.
   Für den Anwender ergibt sich eine extrem einfache Bedienung mit maximalem Komfort. Der Admin muss sich nur darum kümmern, dass die Auswahl die korrekten Aktionen ausführt.

openHAB bietet von sich aus aus gutem Grund keine Schaltuhr-Funktion, aber es ist mit vertretbarem Aufwand kein Problem, so etwas über die UI und ein oder zwei Rules zu bauen, dafür gibt es die Rules.

Ja beim Schaltprogramm war ich am Anfang auch. [emoji3]

Unsere Lüftungsanlage habe ich über Modbus an OpenHab angebunden.
Die Anlage kann man über ein Wochenprogramm fahren. Und für jeden Tag kann man über das Bedienteil verschiedene Schaltzeiten einstellen. Das ergibt 224 Modbus Register welche ich in OpenHab abbilden müsste. Das wäre ein immenser Aufwand usw.

Ich habe tatsächlich nur vier feste Zeitpunkte innerhalb 24h die für die Anlage sind.
Das geht sehr einfach über Time Cron.
Ansonsten gibt es eine Rule welche die Anlage nach unserem Nutzerverhalten steuert. (Hier ein Danke an Tokamak).
Hier ist eine Führungsgröße die Luftfeuchtigkeit im Haus sowie auch die Außentemperatur.

So ein Konzept ist mit wenigen Items und ein paar Rules darstellbar und es muss kein riesen Timer Klotz gebaut werden.

Gruß Peter

Danke für die Rückmeldungen.
Schaltuhrprinzip ist z.Z. notwendig, da ich nur Heizkörper-Ventile/Thermostate und Raumthermostate als Sensoren habe.
Werde mich mal mit dem iCalendar Binding befassen. War ein guter Tip!

Wenn diese Projekt (mal) abgeschlossen ist, werde ich mich auch mit anderen Sensoren und IoTs befassen. Das kann sich aber noch ne gute Weile hinziehen.