Optimierung der Hausabschaltung: Raumbezogene Steuerung?

[Proton]

Hallo zusammen!
Ich habe bisher beim Schlafengehen immer mit der groben Kelle das gesamte Haus ausgeschaltet (alle Lichter aus, alle Geräte aus usw.). Das würde ich jetzt gerne etwas feingranularer machen um Schaltungen zu verringern. Deswegen und habe mir überlegt, dass ich für jeden Raum ein Switch-Item anlege, ebenso wie eine Regel für jeden Raum. Beim ersten Ausführen der Regel wird der Zustand des Items gewechselt, so dass die Regeln, für die Räume die bereits ausgeführt wurden, nicht nochmals ausgeführt werden, wenn am Schluss alles ausgeschaltet wird.

Bevor ich das umsetze dachte ich mir, ich frage mal nach wie das andere machen bzw. ob das eine gute Idee ist.

Schönen Gruß

[mad-mike]

Moin,

Ich schreibe mal nur von meiner Lampensteuerung.

Ich habe alle Lampen in eine Gruppe gepackt und mir einem Tasten Druck werden nur die ausgeschaltet (bzw bekommen ein "OFF" Command) welche auch aktiv sind. Udo1Toni hatte mir damals bei der Geschichte geholfen bei der Erstellung einer Rule.

Könnte dir sowas zusagen?

[Proton]

Hallo Mike,
und danke für deine Antwort. Das hatte ich in der Tat auch schon mal mit Udo besprochen, aber wieder verworfen, weil ich mir bei der Namensgebung der Räume ein bisschen ins Knie geschossen habe. Ich habe die nicht einheitlich gemacht und deswegen gibt halt Namen wie Flur_EG und Wohnzimmer was das Splitten am Unterstrich verkompliziert weswegen ich das noch nicht gemacht habe.
Ich bin auf die Idee mit den Räumen gekommen, weil ich für jedes Familienmitglied Schalter für schlafen und abwesend erstellt habe und aus den sich dabei ergebenden Kombinationen sollen unterschiedliche Szenarien ausgelöst werden. Durch eine Regel für jeden Raum, kann man (so denke ich zumindest) feiner bestimmen wann was passiert und über die Items für die Räume kann man halt verhindern, dass Aktionen mehrfach ausgeführt werden. Zum Beispiel die Frau geht schlafen, Schlafzimmer wird "deaktiviert", aber auch ihr Arbeitszimmer. Dann gehe ich schlafen, Schlafzimmer ist schon deaktiviert, deswegen passiert da nichts, aber alle anderen Räume die wir nicht brauchen werden deaktiviert. Noch gehen die Kinder vor uns ins Bett, aber das wird sich noch ändern und ich hoffe dem Ganzen so eine gewisse Flexibilität zu geben. Das ist jedenfalls der Plan

Schönen Gruß

[udo1toni]

Das A und O sind vernünftige Namen für die Items hab ich damals bestimmt auch schon erwähnt. Wenn das bedeutet, dass Du Items neu anlegen musst, dann ist das halt so, da mussten (und müssen) wir alle durch.
ok, ich habe gut reden, denn ich habe meine Items alle über Textdateien definiert, d.h. ich ändere die Itemnamen einfach ab und gut ist. Tatsächlich wird das alte Item gelöscht und ein neues erstellt, das ist mir aber gleich. Mit etwas zusätzlichem Aufwand kann man sogar die Persistence Daten erhalten - natürlich nur mit manuellem Eingriff in die Datenbanken...

Ansonsten kann man jederzeit vor dem Absetzen eines Befehls prüfen, welchen Zustand das Item hat:

Code: Alles auswählen

...
var soll = ON
if(blah) soll = OFF
if(meinItem.state != soll) meinItem.sendCommand(soll.toString)

Der Befehl (hier ON oder OFF) wird nur gesendet, wenn dies auch notwendig ist, um den Sollstatus zu erreichen.

[Proton]

Okay, dann werde ich wohl oder übel die Items nochmal neu anlegen, aber ich muss dazu sagen, dass die Benennung von openHAB da nicht einheitlich war und ich nicht darauf geachtet habe.

2024-11-26_13-26.png

Mal wurden Unterstriche zwischen den Worten benutzt und mal nicht. Das wirft für mich jetzt noch folgende Frage auf: Wie benennt man Items den "richtig"? Macht man ein FlurEG (oder FlurEg?) oder flur_eg? Bzw. ist Groß- und Kleinschreibung überhaupt relevant?

Dennoch löst das ja nicht das Problem, dass ich unterschiedliche Räume zu unterschiedlichen Zeitpunkten "ausschalten" möchte, oder?

[udo1toni]

Okay, dann werde ich wohl oder übel die Items nochmal neu anlegen, aber ich muss dazu sagen, dass die Benennung von openHAB da nicht einheitlich war und ich nicht darauf geachtet habe.

openHAB generiert die Itemnamen automatisch, wenn Du über das Semantic Model oder innerhalb des Things Channel auf ein neu generiertes Item verlinkst. Der Name wird dabei aus den Thing/Channel Daten errechnet. Der von openHAB generierte Name ist allerdings lediglich ein (meist schlechter) Vorschlag, den Du nicht annehmen musst oder auch nur solltest.

Mal wurden Unterstriche zwischen den Worten benutzt und mal nicht.

Genau, das ist ein Stück weit abhängig davon, wie UID und Label des jeweiligen Channels und die anderen Metadaten gestaltet sind.

Das wirft für mich jetzt noch folgende Frage auf: Wie benennt man Items den "richtig"? Macht man ein FlurEG (oder FlurEg?) oder flur_eg?

Tatsächlich kannst Du die Namen so gestalten, wie es Dir passt. Meine allgemeinen Tipps wären:
- Group Items mit einem kleinen g starten (reicht als Unterscheidungsmerkmal)
- Itemanmen hierarchisch aufbauen (z.B. gEG... für alles im Erdgeschoss, gOGSchlaf... für das Schlafzimmer im Obergeschoss usw.)
- Den Unterstrich nur dann verwenden, wenn Du innerhalb Rules Teile des Itemnamens verwenden willst. Erklärung weiter unten...

Bzw. ist Groß- und Kleinschreibung überhaupt relevant?

Es ist insofern relevant, als dass für openHAB MeinItem und Meinitem zwei unterschiedliche Items sind, openHAB ist grundsätzlich case sensitive, es gibt ein paar Stellen, wo das nicht so ist, das Einfachste ist aber, man geht davon aus, dass es immer case sensitive ist
Wie oben erwähnt, kannst Du die Namen komplett selbst wählen,

Dennoch löst das ja nicht das Problem, dass ich unterschiedliche Räume zu unterschiedlichen Zeitpunkten "ausschalten" möchte, oder?

Na ja, doch, irgendwie schon, zum Teil...
Der Punkt ist ja, Du musst über diverse Items rotieren, um zu entscheiden, ob das Item ausgeschaltet werden muss. Dabei musst Du im Zweifel den aktuellen Status anderer Items genauso berücksichtigen, wie den Status der einzelnen Items. Ein ausgeschaltetes Item muss nicht erneut ausgeschaltet werden, ein eingeschaltetes Item darf nur ausgeschaltet werden, wenn es bestimmte Kriterien erfüllt. Und je nachdem, wie Du Deine Items organisierst, kannst Du den Itemnamen oder auch Gruppenzugehörigkeiten hierfür heranziehen.

Nehmen wir an, Du hast Deine Räume in der Art g<Stockwerk><Raum> benannt, also z.B. gOGKind1, gEGKueche usw., und alle diese Räume sind in einer Gruppe gRaeume zusammengefast (dieses Group Item ist außerhalb des Semantic Model), dann kannst Du innerhalb einer Rule z.B.

Code: Alles auswählen

val GroupItem gRaum = gRaeume.members.filter[g|g.name.endsWith["Kind1"]].head
gRaum.members.filter[j|j instanceof SwitchItem].forEach[i|
  if(i.state != OFF)
    i.sendCommand(OFF)
]

Die erste Zeile wählt ein Group Item, in dem der Teilstring "Kind1" am Ende steht. Beachte, dass man hier auch mittels einer Schleife hintereinander mehrere Räume abarbeiten könnte. Die jeweiligen Teilstrings könnten aus einer separaten Liste kommen.
Die zweite Zeile erzeugt zunächst eine Liste aller Items, die dem Group Item gRaum angehören. Die Liste enthält lediglich die Switch Items des Raum.
Anschließend wird für jedes Item auf der Liste (forEach) der Status überprüft, und falls dieser nicht OFF ist, wird der Befehl OFF an dieses Item gesendet.
Das kann man beliebig erweitern, je nachdem, wie die Abhängigkeiten sind (bzw. sein sollen).

[Proton]

Also ich habe das so verstanden: Eine Gruppe gRaume und in dieser Gruppe hat jeder Raum eine eigene Gruppe gEGKueche etc.
Diese Gruppen müssen dann doch die Items enthalten die geschaltet werden sollen, korrekt?

Kann ich dann nicht auch durch meine bestehende Gruppenstruktur iterieren?

2024-11-26_22-13.png

Natürlich nur, wenn die Namen der Items angepasst wurden.

[udo1toni]

Ja, unter der Voraussetzung, dass Du die passenden Eigenschaften aus den Items heraus lesen kannst.
Und deshalb sollten die Group Items passend benannt sein.
gRaeume ist nicht Teil des Semantic Model, weil alle Räume direkt diesem Group Item zugeordnet sein sollen (zusätzlich).

Alternativ könntest Du natürlich auch über "Lichter alle" iterieren, dann müsstest Du halt mit allMembers arbeiten, damit alle . In der Folge musst Du allerdings extrem tief graben, um rückwärts pro Item abzufragen, zu welchen Group Items sie gehören, möglich, aber sehr viel aufwändiger. Du könntest noch über das Label gehen, z.B. if(Item.label.contains("Schlafzimmer") - immer vorausgesetzt, dass alle Items als Teil des Labels den exakten Raum benennen.

[Proton]

Ja, unter der Voraussetzung, dass Du die passenden Eigenschaften aus den Items heraus lesen kannst.
Und deshalb sollten die Group Items passend benannt sein.
gRaeume ist nicht Teil des Semantic Model, weil alle Räume direkt diesem Group Item zugeordnet sein sollen (zusätzlich).

Das würde ich mal ausschließen, da ich zum einen keine Textdateien mag, die nicht geparst werden und zum anderen kann ich dadurch vermeiden wirklich alles neu machen zu müssen.

Beim zweiten Teil habe ich wie immer nur die Hälfte verstanden.

Alternativ könntest Du natürlich auch über "Lichter alle" iterieren, dann müsstest Du halt mit allMembers arbeiten, damit alle .

Wobei es dieses Mal nicht ausschließlich mein Unvermögen ist.

In der Folge musst Du allerdings extrem tief graben, um rückwärts pro Item abzufragen, zu welchen Group Items sie gehören, möglich, aber sehr viel aufwändiger.

Das ist der Teil den ich nicht verstanden habe, der aber für mich interessant ist. Derzeit ist es so, dass bei Sonnenuntergang alle Rollladen herunterfahren. Jetzt würde ich gerne in allen Räumen die Präsenzsensoren abfragen um in dieser Räumen das Licht einzuschalten.
Wie wäre hier das genaue vorgehen?

Du könntest noch über das Label gehen, z.B. if(Item.label.contains("Schlafzimmer") - immer vorausgesetzt, dass alle Items als Teil des Labels den exakten Raum benennen.

Ich habe bei allen Things den Raumnamen vorangestellt, damit diese dort gruppiert sind.

SCR-20241127-lusn.png

Was ich dann im Semantic Model übernommen habe.

SCR-20241127-lvkm.png

Das sollte ja für eine Suche über Label reichen, nicht wahr?

[udo1toni]

Das würde ich mal ausschließen, da ich zum einen keine Textdateien mag, die nicht geparst werden und zum anderen kann ich dadurch vermeiden wirklich alles neu machen zu müssen.

Ähm, nein?

1. Es ist völlig egal, ob Du mit Textdateien oder über die UI konfigurierst. Vorteile der Textdateien gegenüber der UI:
   • Man kann sie super hier im Forum posten
   • - Man kann die Namen von Items ändern
   Es geht hier also nicht so sehr darum, dass Du nun die Items per Textdatei konfigurieren sollst, die Form ist halt wesentlich einfacher im Forum zu teilen (und außerdem sehr sparsam...)
2. Du musst lediglich die vorhandenen "Raum Group Items" einer weiteren Gruppe hinzufügen, das geht mit wenigen Klicks in der UI:
   • Main UI->Administration->Einstellungen->Items
   • Add Item (rechte untere Ecke weißes Plus in blauem Kreis...)
   • Group Item erstellen
   • Item in der Liste der Items selektieren
   • Direct Group Members->Change
   • in der Itemliste alle "Raum Group Items" selektieren
   • Schließen
   • Apply

Und schon hast Du alle Räume gemeinsam in einer Gruppe zusammengefasst, wie gesagt, dieses Group Item darf nicht Teil des Semantic Model sein, da jeder Member des Semantic Model nur einmal im Model auftauchen darf. Das ist aber egal, weil wir das Group Item nicht im Model benötigen, es dient ja nur der Steuerung innerhalb der Rules.

Die Aussage über den Code gilt im Übrigen auch für DSL Rules. Da gibt es zwar wenigstens eine vollständige Codeansicht in openHAB, so dass man hier mit relativ geringem Aufwand eine vollständige Rule "kopierfreundlich" teilen kann. Allerdings baut der Parser die DSL gerne etwas um (Änderung der Zeilenumbrüche) und in der Konsequenz ist der Code oftmals nur schlecht lesbar. Das kann man meist schnell korrigieren, ist aber trotzdem hässlich.

Deshalb bevorzuge ich auch hier die "original" Textversion.
Beispiel für Dein beschriebenes Problem:

Code: Alles auswählen

rule "Rollläden schließen"
when
    Item shutters changed to 100
then
    gLichter_alle.allMembers.filter[i|i instanceof SwitchItem].forEach[j|
        val room = j.label.split(" ").get(0)                                   // erstes Wort des Labels
        val presence = gPresence.members.filter[k|k.name.contains(room)].head  // zugehöriges Presänzitem
        if(presence.state == ON && j.state != ON)                              // Präsenz aktiv aber Licht aus
            j.sendCommand(ON)                                                    // einschalten
    ]
end

Immer vorausgesetzt, Du hast ein gemeinsames Group Item gPresence, in dem alle Präsenzmelder enthalten sind, es gibt nur ein Präsenzitem pro Raum und diese Items tragen den Raumnamen in identischer Form im Label.
Der Trigger der Rule ist hier nur stellvertretend eingetragen, den Code würde man vermutlich in die Rollladen-Schließ-Rule integrieren.
Das Ding ist halt, die Lichter werden (raumübergreifend) in irgendeiner Reihenfolge eingeschaltet werden, und zwar logischerweise jeweils alle Lichter in den Räumen mit Präsenz.
Sollte es Dimmer in den Gruppen geben, so werden diese hier nicht berücksichtigt, man könnte diese aber natürlich ebenfalls ansteuern - mit einem separaten Codeblock mit ähnlichem Aufbau.