openhabforum.de

Hallo zusammen,

ich habe eine Frage zum Verhalten der Location Cards im Semantic Model. Gefühlt seit den letzten größeren Updates (V4/V5) hat sich die Anzeige von Items verändert, wenn diese mehrfach im Modell verknüpft sind.

Die Ausgangslage: Ich nutze hin und wieder eine Struktur, bei der ein Item sowohl einem Equipment als auch direkt einer Location zugeordnet ist, um es in der UI an verschiedenen Stellen (Reiter „Geräte“ vs. „Eigenschaften“) griffbereit zu haben.
Das Problem: Bei einer flachen Hierarchie verschwindet ein Item nun aus einem der Reiter.

Beispiel A (flache Struktur): Haus -> UG -> Büro -> Lampe (Equipment) -> Switch (Point) (Zusätzlich ist der Switch direkt mit „Büro“ verknüpft). Ergebnis: Der Switch erscheint nur noch unter Eigenschaften, aber nicht mehr bei den Geräten.

Beispiel B (tiefere Struktur): Haus -> UG -> Büro -> Lampen (Group) -> Lampe 1 (Equipment) -> Switch (Point) Ergebnis: Hier funktioniert es weiterhin – der Switch ist in beiden Reitern (Geräte & Eigenschaften) sichtbar.

Meine Theorien dazu:

Redundanz-Filter: Kann es sein, dass die Main UI mittlerweile Dubletten auf derselben Ebene erkennt und wegfiltert, um die Karten übersichtlicher zu halten?

Semantische Distanz: In Beispiel A „besitzt“ das Equipment den Point. Durch die zusätzliche direkte Verknüpfung mit der Location scheint die UI nun eine Priorität zu setzen (vielleicht wird der Point bevorzugt, wenn er direkt an der Location hängt?).

Hierarchie-Logik: Dass es in Beispiel B noch funktioniert, könnte daran liegen, dass durch die zusätzliche Zwischengruppe die semantische Verbindung für den Filter-Algorithmus nicht mehr als „direkte Dublette“ erkannt wird.

Frage an die Experten: Wurde hier bewusst eine Logik implementiert, die verhindert, dass Items gleichzeitig als Teil eines Equipments und als direkte Eigenschaft einer Location angezeigt werden? Ist mein Ansatz, Points doppelt zu verknüpfen, „semantisch illegal“ geworden, oder handelt es sich um einen Bug in der UI-Logik?

Danke für die Info.
Gruß Lenschi

Moin,
eventuelle hilft Dir diese Diskussion ja
https://community.openhab.org/t/semanti ... nts/164216

Ich erhalte keinerlei Semantic Health Check Warnings. Im Modell-Baum sieht technisch alles sauber aus – das Item ist korrekt dem Equipment und der Location zugeordnet und das Equipment wiederum der Location. Trotz dieser validen Struktur, in meinen Augen, verschwindet das Item aus dem Geräte-Reiter, sobald es zusätzlich direkt mit der Location verknüpft wird.
Wie bereits erwähnt: Sobald ich die Struktur tiefer verschachtele (also eine zusätzliche Gruppenebene einziehe), ist das Verhalten wieder so, wie ich es von früher kenne, und das Item erscheint in beiden Reitern.

Ich konnte dazu leider keinerlei Dokumentation oder Foreneinträge finden, die eine solche Änderung der UI-Logik beschreiben.

Zusätzlich würde mich brennend interessieren, was die eigentliche Philosophie hinter dem Reiter „Eigenschaften“ in den Location Cards ist. oder was habt ihr da drin?

Ich habe das quasi dazu genutzt um einen Schnellzugriff auf wichtige Eigenschaften zu erhalten. z.B. in einem Equipment sind 10 Messwerte aber schnell will ich das Gerät nur ausschalten können und diesen Switch hab ich in die Eigenschaften gesteckt.

Es wirkt aktuell so, als würde die direkte Zuweisung eines Points zur Location die Equipment-Zugehörigkeit in der UI-Anzeige „ausstechen“. Ist das ein beabsichtigtes Feature oder ein Seiteneffekt in der Main UI?“

lenschith hat geschrieben: 20. Jan 2026 19:36 Ich erhalte keinerlei Semantic Health Check Warnings.

Das spielt keine Rolle. Ein Item darf maximal einmal im gesamten Semantic Model auftauchen. Punkt.
Du kannst es entweder als Member eines Equipments oder als Member einer Location einbauen, aber nicht beides gleichzeitig.
Ob die eingebaute Überprüfung diesen Fehler findet, oder nicht, ist unerheblich.
Es ist an vielen Stellen sowohl im englischen Forum als auch hier, und eines Wissens auch in der Doku klar beschrieben, dass nur das eine oder das andere geht.

Du kannst aber ein Item taggen (auch da gibt es strenge Regeln... jeder nur ein Kreuz, ähh... Tag) und damit sollte es dann in allen drei Kategorien auftauchen.

Non-semantic Groups darfst Du selbstverständlich beliebig viele nutzen, aber die tauchen im Semantic Model gar nicht auf (deswegen ja non-semantic).

vielen Dank für die ausführliche Erklärung! Dass ein Item nur einem Equipment angehören darf, war mir bewusst – mir war allerdings nicht klar, dass das Item dann nicht zusätzlich direkt in der Location sein darf. - das hat bisher ja funktioniert.

Bezüglich der Tags: Meine Geräte sind bereits getaggt und tauchen in den globalen Kategorien (Licht, Temperatur etc.) auch korrekt auf.

EDIT: oder verstehe ich das mit den Tags falsch? meine Items sind alles zugerodnet zu Semantic Point und Property

Mein Verständnisproblem lag eher an der Darstellung in der Location Card im Standortreiter der MainUI. Dort gibt es ja die zwei Reiter: Geräte: Hier tauchen alle Items auf, die über ein Equipment dem Raum zugeordnet sind. Das klappt wunderbar.

Eigenschaften: Hier hatte ich erwartet, die einzelnen Funktionen (Points) ebenfalls zu sehen. Nach euren Erklärungen verstehe ich nun: Hier werden nur Items gelistet, die direkt (ohne Equipment) der Location zugeordnet sind.

Da ich mein Modell so aufgebaut habe (Location → Equipment → Item), bleibt der Reiter "Eigenschaften" in der Raum-Ansicht logischerweise leer oder zeigt nur die direkt zugeordneten Items.

EDIT: Wenn der Reiter "Eigenschaften" leer ist, ist das eigentlich ein Zeichen dafür, dass mein Modell vorbildlich und streng nach Geräten (Equipment) sortiert ist. In einer perfekten "Equipment-Welt" sollte der Reiter "Eigenschaften" tatsächlich oft leer bleiben?
habe jetzt mal das Model komplett bereinigt damit das nach den vorgaben ist und keine Fehler mehr hat. Man könnte mit Proxy Items arbeiten falls man das möchte oder z.B. Gruppenschalter die alle Lichter im Raum schalten direkt in die Location. Oder sehe ich das nach längerer Betrachtung immer noch falsch?

oder habe ich noch weitere Möglichkeiten diesen Reiter als "Schnellzugriff" zu nutzen?

Irgendwie sehen Location-Cards anders aus als deine. Ich habe diese Überschrift "Geräte/Eigenschaften" nicht. Aber ich denke, dass das Garagentor, das Gerät(Equipment) ist und "Garagentor Status, Öffnen/Schliessen, etc., die Eigenschaften(Properties,Points) sind.

Bei mir sieht die Location-Card mit den Geräten so aus: und wenn ich dann ein Gerät aufklappe, sehe ich die einzelnen Eigenschaften: Meine Seiten-Einstellungen sind:

Hallo peter-pan,

ja, das ist grundsätzlich korrekt.
Sobald du jedoch direkt unter einer Location ein Item legst (z. B. einen Switch), erscheint automatisch der Reiter „Eigenschaften“ und zeigt den Inhalt bzw. Zustand dieses Items an. Wenn sich unter der Location hingegen kein Item befindet, wird dieser Reiter ausgeblendet.

In meinem Beispiel liegt unter der Location „Test“ direkt das Item „TestSwitch2“, weshalb es auch entsprechend in den Eigenschaften angezeigt wird. Dabei spielt es übrigens keine Rolle, ob du die Darstellung auf „Nested pages for sub-equipment (default)“ oder „Equipment items grouped as accordion cards“ eingestellt hast – das Verhalten bleibt in beiden Fällen gleich.

Gruß Lenschi

Ich konnte das Verhalten nachvollziehen.

Du kannst natürlich auch Points direkt in eine "Location" einbinden, dann wird dieser "Point" eben direkt im semantischen Modell unter dem Tab "Eigenschaften" angezeigt.
Dieser Tab entfällt, wenn du die Reihenfolge "Location -> Equipment -> Point/Property" einhältst. In diesem Fall werden dir die Eigenschaften unterhalb des Equipments (Accordeon) angezeigt. Ansonsten gilt das was Udo schon weiter oben beschrieben hat.
Ein Item darf nur einmal vorkommen und es darf auch nur in der "semantischen Verknüpfung" vorkommen, sonst bekommst du z.B. solche Warnungen
es gibt also nur Warnungen und keine Fehlermeldungen.
Also wie gesagt, wenn du die direkt Zuordnung deines Schalters weglässt, fällt auch der Tab weg.
Ich habe keine (normalen) Schalter, die kein Equipment wären, sondern nur "Testschalter", die aber "nonsemantic" sind. Die kann man auch zu Gruppen zusammenfassen.