Ja, das hört sich schon viel besser an
ich hatte schon Befürchtungen, Du wolltest tatsächlich eine Raumtemperaturregelung aufbauen. Gegen eine Nachtabsenkung oder Frostschutz für Räume, die trotzdem "irgendwie" genug Wärme abbekommen ist natürlich nichts einzuwenden.
openHAB ist streng genommen weder eine Visualisierung noch eine Heimautomation, es ist in erster Linie mal ein Vermittler zwischen Welten. Man kann aber bequem sowohl Visualisierungen als auch Automationsfunktionen andocken (und die Rules DSL ist sogar fest mit an Board, zumindest für OH1 und OH2)
Die Philosophie von openHAB ist nicht, für jede Funktion etwas Fertiges vorzugeben. Es gibt Rollershutter Items, mit denen sich Rollläden kontrollieren lassen (Jalousien benötigen dann noch ein 2. Item für den Lamellenwinkel). Was braucht man an dieser Stelle mehr?
Man kann Items gruppieren und die Steuerung über die Gruppen lösen, wobei man normalerweise nur eine Rule für beliebig viele gleichartige Geräte braucht, solange sie auch gleichartig gesteuert werden sollen.
Ich habe zum Beispiel mehrere RTR, eben pro Raum einen. Die Betriebsart dieser RTR kommt über ein Byte in openHAB an (jedes Bit steht für eine bestimmte Betriebsart), während der RTR eine Zahl zum Setzen der Betriebsart erwartet (von 1 bis 4). Ankommende und abgehende Channel sind also zueinander inkompatibel. Ich habe nun eine Rule (!) welche immer dann triggert, wenn die Betriebsart für einen der RTR empfangen wurde. Die Rule setzt dann in Abhängigkeit der empfangenen Betriebsart das passende Item auf die korrekte Betriebsart (ohne den Befehl zu senden) so dass mein Steuerknopf in openHAB immer die gewählte Betriebsart anzeigt, egal, ob die Betriebsart in openHAB oder am RTR selbst verstellt wurde.
Oft wird moniert, dass es in der Oberfläche keine Timer gibt. Es gibt dazu in jedem openHAB Forum hunderte Posts, wenn nicht gar hunderte Threads. Aber es gibt a) eine Kalenderanbindung über die man Timer erstellen kann (z.B. als eigener Kalender in Google Calendar, dann kann man die Programmierung über das Handy erledigen und sogar anderen Personen Rechte geben) und b) ist der Ansatz eines Timers ein Hilfsmittel, welches vergleichsweise antiquiert ist.
Jemand kommt und will etwas hypermodern haben (Hausautomation) aber auf alte Bedienelemente zurückgreifen (Timer), obwohl es bessere Lösungen gibt. !?!
Abgesehen davon ist es in den seltensten Fällen sinnvoll, Zeiten in der Oberfläche auzuwählen. Beispiel Wecker: Wirklich minutengenau für alle 24 Stunden? In Wirklichkeit gibt es für mich (ich arbeite Schicht mit wechselnden Dienstzeiten) nur 5 verschiedene Zeiten, zu denen ich mich von einem Wecker wecken lassen möchte. Da wir Kinder im schulpflichigen Alter haben, kommen nochmal drei Zeiten für meine Frau dazu, fertig. Was ich also tatsächlich brauche, ist eine Auswahlliste mit 8 Zeiten.
Eleganter ist es aber, gar keine Auswahlliste zu haben und stattdessen die Weckzeit automatisch über den Dienstplan und den Stundenplan steuern zu lassen. Man muss nur noch einen Schalter vorsehen, die Wecker mal manuell zu überschreiben, falls der Unterricht in der ersten Stunde ausfällt.
Da openHAB mir auch die Schulferien sowie feste und bewegliche Feiertage berücksichtigt, vermisse ich keinen Timer in der UI.
Die Weihnachtsbeleuchtung wird bei uns automatisch mit der Adventszeit aktiviert und dann zu den interesanten Zeiten ein- und ausgeschaltet. am 7. Januar ist dann wieder Schluss, ohne dass ich einen Finger gerührt hätte. Ich muss allerdings die Lampen auf- und abhängen...
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
