Proton hat geschrieben: 26. Nov 2024 14:47
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.
Proton hat geschrieben: 26. Nov 2024 14:47
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.
Proton hat geschrieben: 26. Nov 2024 14:47
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...
Proton hat geschrieben: 26. Nov 2024 14:47
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,
Proton hat geschrieben: 26. Nov 2024 14:47
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).
