Pages | Sitemap (für App) | Read-Only Items nicht r/o

[./mf]

Ist ein Item über "Metadata: stateDescription" auf Read Only gesetzt, wird offenbar zwischen Sitemap und Main UI unterschieden.

Nehmen wir an, es gibt einen Schalter, der aber vor unbefugter Benutzung geschützt werden muss. Ihn aus der Overview oder Sitemap zu entfernen aber keine Option ist.

In der Overview wird mit der Status als "ON/OFF" angezeigt, kann diesen aber (so soll es ja sein) nicht ändern.

Habe ich das Item in einer Sitemap, kann ein Sitemap User diesen Schalter auch umlegen und damit das verbundene Gerät jederzeit ein- und ausschalten. Aus meiner Sicht wäre dies doch ein Fehler, oder?

[peter-pan]

Bin mir zwar nicht sicher, aber hast du es schon mal mit dem Text-Widget in der Sitemap probiert ?

[./mf]

Aktuell habe ich nur das Model aus der Main UI als Group drin zum Testen.

Dieses Setting als "Text" einzustellen wird klappen. Das habe ich in OH2 auch so gemacht, für "Status" Schalter. Also ob ein Device gerade bestimmte Dinge aktiv hat, oder nicht.

Ich dachte halt, dass es durch die Metadaten so ebenfalls einfach einzustellen wäre. Der Versuch missglückte nur.

Die Metadaten sollten doch für das Item gelten. Unabhängig wo es genutzt wird. Davon war ich zumindest ausgegangen.

[peter-pan]

...das hab ich wohl falsch verstanden. Sprichst du von der Overview-Seite (Übersicht) in der Main-UI ?

[./mf]

In der Overview, wird es korrekt als nicht schaltbar angezeigt. Eben so wie gewollt.

Das gleiche Item, halt eben über die Modell "Gruppe" in der Sitemap eingebunden, lässt sich über die App schalten.

[peter-pan]

Also, wir sprechen schon über die "xxx.sitmap" aus OH2 und dem "Group"-Widget (Element Typ "Group") und der darin enthaltenen Mitgliedern (Items).

Wenn ja, dann hat das gar nichts mit OH3 zu tun. Es wurde/wird ja immer darauf hingewiesen, dass man das Group Widget(Element) in OH2 nur "sparsam" einsetzen soll und besser mit Frames oder anderen Untergruppierungen arbeiten soll, auch wenn das etwas mehr Arbeit bedeutet, aber unter Strich mehr Sicherheit und auch mehr Gestaltungsmöglichkeiten bietet.

Edit: Wenn du aber nur das Group-Item in der Sitemap anzeigen willst (und nicht die Einzelwerte), dann lege es einfach als "Text"-Widget an

[./mf]

In OH2 waren die Groups ja super, so konnte man diverse Elemente zusammen packen und eine Raum- oder Property-Struktur aufbauen. Letzteres für zB alle Temperatur Sensoren, oder eben Battery Level.

Mir war nicht klar, dass man diese Gruppe sparsam einsetzen sollte.

Nun mit OH3.2 ist das Modell ja selbst eine Group. Der Einfachheit halber habe ich diese in die Sitemap gepackt, bevor ich dann demnächst diverse Items einzeln und manuell einer Sitemap hinzufüge. In diesem Zuge kann ich diesen Switch auch als Text einbinden. Das wäre kein Problem.

Wie gesagt, ich "dachte" , dass die Meta-Daten dennoch für alles gelten.

[peter-pan]

Das mit dem sparsam Einsetzen, ist jetzt nicht so Ernst gemeint, wie ich das geschrieben habe, aber halt doch nicht das Optimum in Bezug auf Sicherheit und Gestaltung.

Wie gesagt, ich "dachte" , dass die Meta-Daten dennoch für alles gelten.

Leider nein, "Sitemap" ist OH2 und da gabs die Metadaten noch nicht(zumindest für die Sitemap). "Pages" sind OH3

[udo1toni]

Die Sitemap gibt es vor allem aus Kompatibilitätsgründen. Mir wäre jetzt nicht bekannt, dass diese abgekündigt ist, aber bis openHAB 4 sind es ja auch noch ein paar Jahre (hoffentlich).
Der Punkt ist aber: Eine Sitemap funktioniert zu 100% so, wie schon unter openHAB2 und sogar openHAB1. Die Dinge müssen also auch genauso konfiguriert werden, wie schon unter OH1 und OH2.
Das Group Widget war schon immer eine Krücke, die nur minimale Funktion bot - eben automatisches Generieren einer Default Ansicht einer Gruppe und ihrer Untergruppen. Aber man hatte noch nie Kontrolle über den Inhalt, ob mit Frames oder ohne, spezielle Icons, Label, Farben, bedingte Ansichten... nicht mal die Reihenfolge oder das Widget waren darüber zu bestimmen. Deshalb habe ich meine Sitemaps nach den ersten Gehversuchen konsequent von Hand gebaut (was im Übrigen mit VSCode super komfortabel funktioniert).