OH3/OH4 Standard-Item-Seite/Default Sitemap

[Brn]

Hallo,

ich nutze noch OH2 und will jetzt doch mal auf OH3 oder OH4 umsteigen. Was mir aber aufgefallen ist:
bei OH2 gibt es diese, nennen wir sie, default View/Sitemap mit allen Items gruppiert nach things.
Tatsächlich habe ich die letzten Jahre OH2 so genutzt, dass ich gar keine eigenen Views/Sitemaps erstellt habe sondern nur mit der DefaultView/Sitemap gearbeitet habe. Bei einem ersten Test mit OH3 habe ich diese aber nicht gefunden. Gibt es diese Standardseite nicht mehr?

Danke und Gruß.

[udo1toni]

Du denkst dabei an die Paper UI Configuration Ansicht? Die war nie als Bedienoberfläche gedacht
Paper UI wurde nie großartig weiterentwickelt, weil der Programmierer ausgestiegen ist. Entsprechend wurde dieses Interface auch nicht nachgebildet.

Es gibt stattdessen die Main UI. Wenn Du ohne weitere Konfiguration arbeiten möchtest, musst Du über die Adminstration und die Items arbeiten, was aber nicht mehr so gut funktioniert wie in OH2 (aber wie gesagt - diese Schnittstelle ist nicht dazu gedacht, damit Items zu bedienen)

In openHAB3 ist das Konzept des Semantic Model integriert worden. Unter der Voraussetzung, dass Du die Items in das Semantic Model integrierst, bekommst Du eine weit fortschrittlichere Standardansicht (bzw. deren drei), sortiert nach Standorten, Geräten und Eigenschaften (also z.B. alles im Wohnzimmer - alle Lichter - Alle Temperaturen), die Anzeige erfolgt über die drei Karteireiter am unteren Rand der Anzeige.
Ansonsten musst Du entsprechende Ansichten konfigurieren, unter openHAB3 führt da kein Weg mehr vorbei.
Hättest Du allerdings die einzige "eingebaute" UI (Basic UI) schon unter openHAB2 konfiguriert, hättest Du diese unverändert übernehmen können - und unter openHAB3 kannst Du diese sogar komfortabel über die Main UI Administration anlegen.

[Brn]

Ja, ich meinte in der PaperUI die Ansicht unter <host>/paperui/index.html#/control. Aber auch die BasicUI hatte so eine Default-Ansicht.

Bezüglich der Semantic Models komme ich in OH3 nicht ganz zurecht. Ich habe die Things und items aus OH2 importiert (Textdateien im passenden Ordner abgelegt) und in der Models Übersicht wird nur 1 Raum angezeigt. Obwohl ich alle Things und Items in OH3 habe. Keine Ahnung, warum die Anderen "Räume" (Things) nicht als Modell sichtbar sind.

Okay, ich nehme also mit, dass ich Sitemaps bauen muss. OH3 erschlägt mich ehrlich gesagt etwas.
Vermutlich kann man die Textfiles wie früher nutzen. Dann gibt es aber auch die Möglichkeit in der Gui etwas zu bauen, was vermutlich in einer DB gespeichert wird. Wenn man im Laufe der Jahre von OH Version X zu OH Version Y und Z wechselt, fühlen sich Textdateien zur Konfiguration aber besser an, als alles in irgendeinem DB Format vorzuhalten ohne zu wissen, ob es zukünftig die Migrationspfade zwischen den DB Typen und OH Versionen geben wird.
Aber irgendwie gibt es im Gestaltungskontext ja nicht nur die Sitemap-Dateien, sondern auch die Developer Sidebar, Widgets und Layouts. Und vermutlich noch mehr und sicher haue ich hier einiges Durcheinander. Und jeder dieser Menüpunkt ist eine eigene Welt.
Mein Favorit sind die Textdateien. Aber:
Things und items aus Textdateien sind in der OH Web-GUI read-only.

Und dann gibt es noch die Möglichkeit, Items von einer Text-Definition zu übernehmen. Hat vermutlich nix mit Layout zu tun, aber würde vermutlich dazu dienen, wenn ich meine OH2 Textdateibasierten Items in die DB Version bringen möchte.
Vermutlich muss ich mir dann die Frage stellen, ob ich den Textdatei-Kontext verlassen möchte. Seit Java aber deutlich kürzere LTS Releases hat und OH4 vor allem wegen des Java Wechsels eine Version 4 ist und nicht 3.5, steht für mich die Frage im Raum, ab zukünftig schneller mit neuen OH Versionen zu rechen ist, was die Wichtigkeit des Migrationsthemas (der Items und Sitemaps) auf den Plan ruft.

..gabs nicht mal den Ansatz, dass das OH-KNX Plugin die Items aus der ETS Projektdatei erstellt? Baut das Plugin daraus vielleicht auch gleich eine View?

[udo1toni]

Ja, ich meinte in der PaperUI die Ansicht unter <host>/paperui/index.html#/control. Aber auch die BasicUI hatte so eine Default-Ansicht.

Das wäre mir neu.

Bezüglich der Semantic Models komme ich in OH3 nicht ganz zurecht. Ich habe die Things und items aus OH2 importiert (Textdateien im passenden Ordner abgelegt) und in der Models Übersicht wird nur 1 Raum angezeigt. Obwohl ich alle Things und Items in OH3 habe. Keine Ahnung, warum die Anderen "Räume" (Things) nicht als Modell sichtbar sind.

Das Semantic Model nutzt Group Items. Diese müssen allerdings getaggt sein. Das geht auch über die *.items Dateien, aber die Tags sind exakt definiert, Du kannst sie also nicht frei wählen. https://community.openhab.org/t/oh3-...s-files/112520 liefert alle Informationen. tldr: Lade dir die aktuelle Tag-Liste von https://github.com/openhab/openhab-c...manticTags.csv oder nutze sie direkt online. Achte auf Groß/Kleinschreibung, jedes Zeichen zählt. Gewöhnlich wird man nur ein Tag pro Item setzen. Beispiel:

Group gIndoor            "drinnen"                     <house>                    ["Indoor"]
  Group gAltEG           "Altbau EG"                   <groundfloor>   (gIndoor)  ["GroundFloor"]
    Group gAEGWozi       "Altbau Wohnzimmer"           <sofa>          (gAltEG)   ["LivingRoom"]
      Group gAEGWShutter "Rollläden Wohnzimmer Altbau" <rollershutter> (gAEGWozi) ["Blinds"]

Rollershutter RsAWoziHof  "Wozi Hof"  <rollershutter> (gAEGWShutter) ["Control"] {channel="mqtt:topic:mymqtt:sonoffT1_1:ch1"}
Rollershutter RsAWoziWest "Wozi West" <rollershutter> (gAEGWShutter) ["Control"] {channel="mqtt:topic:mymqtt:sonoffT1_2:ch1"}
Rollershutter RsAWoziOst  "Wozi Ost"  <rollershutter> (gAEGWShutter) ["Control"] {channel="mqtt:topic:mymqtt:sonoffT1_3:ch1"}

Die Einrückung der Group Items dient hier natürlich nur der optischen Abgrenzung. Das jeweilige Tag steht in den eckigen Klammern in Anführungszeichen. Es gibt also im Semantic Model eine Ebene "drinnen", unterhalb der sich ein Gebäudeteil "Altbau EG" befindet, in dem sich ein Raum "Altbau Wohnzimmer" befindet, zu dem eine Gruppe Geräte "Rollläden Wohnzimmer Altbau" gehören. Innerhalb dieser Gerätegruppe gibt es drei Rollershutter Items, die als "Control" definiert sind, weshalb sie dann zum einen im Semantic Model direkt angezeigt werden und zum anderen auf der entsprechenden Seite automatisch auftauchen.

Okay, ich nehme also mit, dass ich Sitemaps bauen muss.

Zumindest wenn Du eine grafische Oberfläche zum Steuern haben willst, wirst Du entweder mindestens eine Sitemap oder mindestens eine Page anlegen müssen.

OH3 erschlägt mich ehrlich gesagt etwas.

Willkommen im Club Im Ernst: mit openHAB3 kamen halt sehr viele Neuerungen, nicht zuletzt die komplett neu gestaltete UI, aber wenn Du Dich etwas eingearbeitet hast, wirst Du feststellen, dass Vieles sehr viel einfacher und sinnvoller gestaltet ist, als das in openHAB2 der Fall war. Natürlich hat jemand, der lieber per Textdateien konfiguriert (ich auch...) nicht so viel von dem "modischen Schnickschnack", aber selbst zum "nur gelegentlich mal was nachschauen" ist die Main UI wesentlich aufgeräumter als Paper UI je war.

Vermutlich kann man die Textfiles wie früher nutzen.

Ja.

Dann gibt es aber auch die Möglichkeit in der Gui etwas zu bauen, was vermutlich in einer DB gespeichert wird.

Ebenfalls ja, das war in openHAB2 aber auch schon so.

Wenn man im Laufe der Jahre von OH Version X zu OH Version Y und Z wechselt, fühlen sich Textdateien zur Konfiguration aber besser an, als alles in irgendeinem DB Format vorzuhalten ohne zu wissen, ob es zukünftig die Migrationspfade zwischen den DB Typen und OH Versionen geben wird.

openHAB verwendet für die interne Speicherung aller Konfigurationen eine jsondb (bzw. mehrere kleinere, die jeweils Teile der Daten enthalten). Das Backend wurde in den frühen 2er-Versionen umgestellt, weil die jsondb um Faktor 100 schneller war (wenn ich mich richtig erinnere...) Vermutlich wird sich da aber in nächster Zeit nichts ändern, das ist im Core und schon seit etwa 5 Jahren stabil.

Aber irgendwie gibt es im Gestaltungskontext ja nicht nur die Sitemap-Dateien, sondern auch die Developer Sidebar, Widgets und Layouts. Und vermutlich noch mehr und sicher haue ich hier einiges Durcheinander. Und jeder dieser Menüpunkt ist eine eigene Welt.

Sitemap -> Konzept aus OH1, weitgehend unverändert, lediglich die Umsetzung in das Layout wurde von Classic UI auf Basic UI modernisiert
Developer Sidebar -> Du kannst Dir Objekte anpinnen, um während der Entwicklung Zustände im Blick zu behalten (z.B. wenn Du eine Sitemap baust...)
Widgets -> gibt es verschiedene. In der Sitemap gibt es eine fixe Liste von Widgets, die Du exakt so verwenden kannst, wie das System es vorgibt. HABPanel bietet ebenfalls Widgets, die über HABPanel erstellt oder geladen werden. Diese sind weitreichend konfigurierbar, so das man das Aussehen eines HABPanels stark nach eigenen Vorstellungen anpassen kann. Die Main UI Pages verwenden ebenfalls Widgets, und auch diese sind anpassbar und man kann selbst Widgets entwickeln und auch mit der Community teilen. Es gibt inzwischen hunderte Widgets, die teilweise hochgradig spezialisiert sind (z.B. eines für Dein Auto, falls dieses online verwaltbar ist, mit verschiedenen Ansichtes des Fahrzeugs und Informationen darüber, welche Türen oder Fenster offen oder geschlossen sind usw. Ansicht des Fahrzeugs selbstverständlich mit Rundumansichten in passender Ausstattung und Farbe (so der Hersteller diese Ansichten zur Verfügung stellt...)
Layouts -> Teil der Pages. Man kann über das Semantic Model die Ansichten automatisch generieren lassen. Dennoch kann man das Aussehen dieser Ansichten beeinflussen, z.B. mit Bildern der Räume.
Was Du z.B. nicht erwähnt hast: Charts. Aber im Unterschied zu den in openHAB1 und openHAB2 eingebauten nun in dynamisch, weitgehend konfigurierbar und deutlich besser in der Darstellung - ob man hier allerdings das Adjektiv "hübsch" verwenden will, ist Ansichtssache

Mein Favorit sind die Textdateien. Aber:
Things und items aus Textdateien sind in der OH Web-GUI read-only.

Ja, auch das war schon in openHAB2 so.

Und dann gibt es noch die Möglichkeit, Items von einer Text-Definition zu übernehmen. Hat vermutlich nix mit Layout zu tun, aber würde vermutlich dazu dienen, wenn ich meine OH2 Textdateibasierten Items in die DB Version bringen möchte.

Genau. Du kannst halt die *.items Definitionen in die jsondb übernehmen, damit Du zukünftig über die UI konfigurieren kannst. Für Things steht das nicht zur Verfügung, vermutlich haben die Entwickler sich überlegt, dass jemand, der Things in Textdateien verwaltet hat, dies auch unter openHAB2 schon "aus Gründen" getan hat und davon nicht abweichen wird. (warum auch? funktioniert ja prima, wenn man weiß wie...)

Vermutlich muss ich mir dann die Frage stellen, ob ich den Textdatei-Kontext verlassen möchte.

Das einzige, was Du zwingend über die UI anlegen musst, sind Pages, die sind erst mit openHAB3 dazu gekommen und es gibt keine Textkonfiguration dafür. Allerdings verwendet openHAB hier das yaml Format, man kann die Pages also auch über Text definieren oder zumindest in dieser Form z.B. im Forum teilen (diese Option, die Konfiguration als reinen Text zu zeigen ist auch nicht ganz unwichtig, wie ich finde - items haben in openHAB3 keine Code Ansicht - leider).

Seit Java aber deutlich kürzere LTS Releases hat und OH4 vor allem wegen des Java Wechsels eine Version 4 ist und nicht 3.5, steht für mich die Frage im Raum, ab zukünftig schneller mit neuen OH Versionen zu rechen ist, was die Wichtigkeit des Migrationsthemas (der Items und Sitemaps) auf den Plan ruft.

openHAB1 lief bei mir bis V1.8.xx , das waren also etwa vier Jahre, dann kam openHAB2 bis V2.5.12, also knapp drei Jahre und nun bis V3.4.4, also etwa zweieinhalb Jahre.
Bei openHAB2 muss man erwähnen, dass durch die Umstellung auf Eclipse (und wieder zurück) etwa ein Jahr Entwicklungsarbeit drauf ging, außerdem wurde das Developer-Backend mehrfach komplett umgekrempelt, was ebenfalls etwa ein Jahr gekostet hat. Dies hat aber dazu geführt, dass nun relativ stabil entwickelt werden kann, sowohl die Dokumentation als auch alle offiziellen Builds (zip-Pakete für die verschiedenen OS, debian Pakete, openHABian Images, Docker Images...) vollautomatisch generiert werden, was die Entwickler entlastet und somit Kapazität für die "eigentliche" Arbeit freischaufelt. Der Veröffentlichungszyklus ist aber seit Jahren gleich, alle 6 Monate gibt es ein stable Release (Ziffer hinter dem ersten Punkt wird erhöht), es gibt monatliche Milestones (viele Neuerungen, recht gut getestet) und quasi täglich die Snapshots (ungetestet, aber mit allen Neuerungen. Jede Neuerung durchläuft ein mehrstufiges Audit, Codeänderungen werden also selbst beim Snapshot nicht "einfach so" auf die Anwender losgelassen.

..gabs nicht mal den Ansatz, dass das OH-KNX Plugin die Items aus der ETS Projektdatei erstellt? Baut das Plugin daraus vielleicht auch gleich eine View?

Das war mal angedacht, wurde aber nie vollendet. Das letzte Mal habe ich davon vor etwa fünf Jahren gelesen - und ehrlicherweise muss man sagen, dass knx nur eines unter über 300 Addons ist - und ein Großteil der Anwender verwendet kein knx (auch wenn es das mit Abstand beste Bussystem am Markt ist...).

[Brn]

Wow, vielen Dank für die Aufklärenden Worte. Das ist viel Input. Ich bin mir nicht ganz sicher, ob sich das Puzzle langsam zusammensetzt, ob ich das nur glaube und/oder das in ein paar Tagen, wenn ich für den nächsten Umsetzungsschritt Zeit habe, nicht schon wieder alles entfallen ist.

Das wäre mir neu

Habe mich getäuscht. Es war die Classic UI.

Habe ich das richtig verstanden, dass ich Tags in den items Dateien einbauen kann und dann das Semantic Model "erzeugt" habe und daraus ein Layout generieren lassen kann? Dann müsste ich diese Layouts "nur" noch (irgendwie) in pages zusammen fassen?
Ist pages das, was früher sitemaps waren?
Ich habe vor einiger Zeit mit Pages etwas getestet und festegestellt, dass ich Pages habe, die eine Sitemap sind, Pages habe, das ein Chart ist, eine Page habe, die ein Layout ist und eine Page heißt nur Home. :-/ Die Testpages sind über 1 Jahr her. Ich weiß gar nicht mehr, das dahinter steckte, aber es fühlt sich verwirrend an.

Einen Vorteil von Sitemaps waren für mich, dass diese in der OH App eingebunden werden konnten. Das lief irgendwie fluffiger als die OH Webseite. Wie ist das bei OH3? Kann ich da was bauen, dass sowohl im Browser funktioniert, als auch in der App sichtbar ist?

Was wäre denn deine Empfehlung, wenn ich aus meiner jetzigen Welt (items-Dateien und automatisches Sitemap über PaperUI) möglichst schnell eine nutzbare Umgebung in OH 3 haben möchte?
...die man dann bei freier Zeit stück für Stück tunen machen kann...

Widgets haben mir in der PaperUI dann halt doch an einigen Stellen gefehlt, etwa ein Color-Picker. Ich habe dazu einiges in CometVisu gebaut, aber zukünftig würde ich gerne davon weggehen, noch eine Subprojekt einbinden zu müssen. Zumal dies an 1,5 Entwicklern hängt und an einer älteren Java-PHP Brücke. Da ist mir irgendein zentrales Schwergewicht in der Liste der OH3 eigenen Oberflächen lieber.

Die Main UI Pages verwenden ebenfalls Widgets, und auch diese sind anpassbar und man kann selbst Widgets entwickeln und auch mit der Community teilen. Es gibt inzwischen hunderte Widgets, die teilweise hochgradig spezialisiert sind (z.B. eines für Dein Auto, falls dieses online verwaltbar ist, mit verschiedenen Ansichtes des Fahrzeugs und Informationen darüber, welche Türen oder Fenster offen oder geschlossen sind usw. Ansicht des Fahrzeugs selbstverständlich mit Rundumansichten in passender Ausstattung und Farbe (so der Hersteller diese Ansichten zur Verfügung stellt...)

Ja, das klingt alles sehr spannend und interessant. Aber erstmal muss ich das Haus in OH3 rein bekommen. Dann können solche Dinge wie Wallbox und Auto kommen. Bei der Wallbox geht da bspw. vieles über MQTT. Wieder ein neues Thema, was sich (wie ich finde) schwer debuggen lässt. Das macht die Einarbeitung recht schwer.

[udo1toni]

In der Administrationsoberfläche sind unter dem Begriff "Pages" die verschiedenen UI-Funktionen zusammengefasst, mehr nicht. Du kannst Dir Maps erstellen lassen (z.B. um anzuzeigen, wo sich Dein Auto befindet, incl. verschiedener fixer Punkte wie Deine Heimatadresse und Dein Arbeitsplatz). Du kannst Charts anlegen, PAges, und natürlich auch Sitemaps, das geht alles über die Pages in der Administration. Ic hdenke mal, man wollte nur ungern drölf Überschriften für etwas ganz ähnliches auflisten, nur weil es eigentlich unterschiedliche Dinge sind.

Was die openHAB Apps betrifft, so können alle offiziellen Apps (iOS, Android, Windows) sowohl Sitemaps als auch Pages rendern.
Aber nochmal: Es gibt keine "automatische" Sitemap, die musst Du schon erstellen. Das ist aber auch nicht weiter schwer. Wenn Du mit Textdateien arbeitest, möchte ich Dir VS Code empfehlen, das bringt ein openHAB Plugin mit. Mit dem Plugin kannst Du komfortabel aus Things Items erzeugen, Items in Rules einfügen und genauso aus Items Sitemaps erstellen. Das genaue Aussehen musst Du aber schon von Hand anlegen, aber auch das ist eigentlich keine große Sache (es sei denn, man hat sich zehn JAhre davon gedrückt, dann vielleicht schon)

Inwiefern erscheint Dir mqtt schlecht zu debuggen? Du installierst Mosquitto mit den Standard Einstellungen. Du trägst die Standard Einstellungen in den mqtt Clients ein (auf allen Clients identisch, die IP vom Mosquitto Broker, Port 1883, kein User, kein Passwort), ebenso richtest Du den MQTT Explorer als Client ein (z.B. im Microsoft Store). Der MQTT Explorer zeigt Dir genauestens, welche Daten an Mosquitto gesendet werden. Genauso kannst Du beliebige Topics und beliebige Payloads an Mosquitto senden, viel mehr Debugging geht gar nicht.

In openHAB selbst bekommst Du alle Daten in openhab.log und events.log ausgegeben, also auch keine große Sache. Die Daten selbst liegen im weit überwiegenden Teil im Klartext Format vor, entweder als Plain Text oder als JSON Objekt, wobei der MQTT Explorer JSON automatisch formatiert ausgeben kann, so dass sogar die Datenstruktur nachvollziehbar wird.
Da ist wirklich nichts mit "schwer einzuarbeiten".

[Brn]

Die Semantic Models beschreiben die Struktur der Items, oder?
Wenn man die Pages, also die optische Anordnung der Items, nicht auf den semantic models aufbaut, sondern auf den klassischen Items...
...fällt einem das dann irgendwann auf die Füße?
Also: spricht was dagegen, die semantic models nicht zu definieren?

Inwiefern erscheint Dir mqtt schlecht zu debuggen?

Ich hatte mich kürzlich mal versucht, zwischen Tür und Angel dort einzuarbeiten und einen Mosquitto Container gestartet in der Hoffnung ad hoc die Infos der Wallbox in Openhab angezeigt zu bekommen. Aber es kam keine Info an und ich war mir nicht sicher, wo die Information untergegangen ist und ob sie überhaupt auf den Weg ging.
Aber ich werde das erstmal zurückstellen und an den pages bauen.

[udo1toni]

Das Semantic Model beschreibt die gesamte openHAB Instanz (nur die Items betreffend), die Aufteilung der Räume und eben die Eigenschaften der Items, also wozu ein bestimmtes Item gut ist. Diese Daten verwendet openHAB, um die drei erwähnten Ansichten zu generieren. Für die Funktion von openHAB spielt das Semantic Model aber keine Rolle - in dem Sinne, dass irgendwas nicht funktionieren würde, wenn Du kein Semantic Model anlegst.

MQTT ist ein zentrales Protokoll, das heißt, es gibt den Broker als Zentrale und alle anderen Devices sprechen ausschließlich mit dem Broker. Dazu müssen natürlich in jedem Device die Zugangsdaten zum Broker korrekt hinterlegt werden.
Man kann jegliche Kommunikation z.B. mit dem MQTT Explorer monitoren - Microsoft Store, kostenlos, ebenfalls ein MQTT Client, der sich ganz normal am Broker anmeldet und einfach alle Topics abonniert.