Habpanel items

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Antworten
jeanhenry3
Beiträge: 40
Registriert: 10. Feb 2019 11:07

Habpanel items

Beitrag von jeanhenry3 »

Hallo,

gibt es eine Möglichkeit, im habpanel im Bearbeitungs-Modus die Anzeige zu erweitern?
wetter 7.JPG
Zum Beispiel gibt es bei openweathermap für jedes item noch 8 Vorhersagen. Die alle gleich anfangen. Im Screenshot z.b. Die Temperatur:
Bevor man die Vorhersagezeit identifizieren kann, endet die Zeile in dem Fenster.
Ich habe keine Möglichkeit gefunden, mir die ganze Zeile zeigen zu lassen (z.B. rechte Maustaste).
Wie kann ich das item zuordnen. Versuch und Irrtum?
Da hätte ich tagelang zu tun, weil es ja über zehn items sind mit je 8 Vorhersagen ... und ob die Zuordnung dann stimmt, ist auch noch fraglich.

VG
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Benutzeravatar
udo1toni
Beiträge: 13864
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Habpanel items

Beitrag von udo1toni »

Andersrum wird ein Schuh draus: Schalte den Simple Mode aus (Paper UI -> Configuration -> System -> ... (findest Du)) und erzeuge die Items von Hand (ja, das ist über Paper UI kein Spaß bei der Menge). Beim manuellen Erzeugen der Items hast Du dann freie Wahl, wie die Items heißen.

Du kannst die Items auch mit Textdateien erzeugen, wenn Du VSCode mit openHAB Plugin verwendest, geht das sogar extrem komfortabel (4 Klicks für alle (!) Channel), eine Textdatei kann man dann auch sehr bequem bearbeiten, also z.B. aus openweathermap_weather_and_forecast_3a88941e_forcast1Hour einfach WeatherHomeForcast1h machen, und zwar an allen Stellen. Immer noch lang genug um zu verstehen, aber kurz genug für die Anzeige.
Ich achte eigentlich immer darauf, meine Itemnamen kurz zu halten, nicht wegen HABpanel, sondern wegen der Rules.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

jeanhenry3
Beiträge: 40
Registriert: 10. Feb 2019 11:07

Re: Habpanel items

Beitrag von jeanhenry3 »

Danke für den Tipp, das Prinzip 'items anlegen in PaperUI' habe ich hoffentlich verstanden.
- simple-Modus ausschalten
- configuration/things: es werden die channels und ihre 'linked items' angezeigt
- 'linked items' gibt es, wenn man (z.B. oder nur dann?) im Habpanel ein 'widget' angelegt hat, das den entsprechenden channel nutzt
- vorhandene items kann man editieren, aber nicht den Namen verändern
- um den Namen selbst zu bestimmen, muss man das item noch einmal anlegen: unter '+'/'link channel'/'create a new item' wird ein (deutscher) Name für das item vorgegeben, den man jetzt nach seinem Gusto verändern kann
- als Ergebnis hat man unter dem zugehörigen thing das selbe item noch einmal mit einem anderen Namen
- im Habpanel kann man nun das 'widget' bearbeiten und das item mit dem eigenen (kürzeren) Namen nehmen

Das ursprüngliche item sollte man - vermute ich mal - besser nicht löschen, wenn man es in items/sitemap-Dateien für Basic UI verwendet hat.

Wie man das nun mitttels VS-Code macht? Da habe ich noch gar keinen Plan.

Benutzeravatar
udo1toni
Beiträge: 13864
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Habpanel items

Beitrag von udo1toni »

Wenn der Simple Mode aktiv ist, erzeugt openHAB automatisch für jeden Channel ein passendes Item. Dabei ist es unerheblich, auf welchem Weg der Channel erzeugt wird (also ob über das Hinzufügen eines per autodiscovery gefundenen Things, per Paper UI/HABmin/REST API/karaf oder auch als Konfiguration über Text File)
Dieses Item wird - logisch - auch unmittelbar mit dem Channel gelinkt und taucht entsprechend in der Liste gelinkter Items auf, die es pro Channel gibt.
Wenn man den Simple Mode ausschaltet, bekommt man Zugriff auf die Item-Sektion in Paper UI -> Configuration. Man kann Items auch direkt aus dem Channel-Link Menü erzeugen, man kann sie aber anschließend nicht bearbeiten :) (bis man den Simple Mode ausgeschaltet hat)
Jedes Item ist ein Unikat. Man hat also weder das selbe noch das gleiche Item. Natürlich kann man die Items identisch konfigurieren (bis auf den Namen, der muss ja eindeutig sein), das ändert aber nichts daran, dass diese Items komplett eigenständig sind.

Sofern Du alle Verweise auf das vom System erzeugte Item auf Dein eigenes Item abänderst, kannst Du das automatisch generierte problemlos löschen (Du musst aber zuerst den Link entfernen, es also aus dem Channel löschen).

Das große Problem mit openHAB2 ist, dass es wegen autodiscovery einen anderen Weg verwendet, um seine Konfiguration zu speichern. Das ist auch der Grund, warum es keine Konfigurationsdateien gibt, wenn man etwas über Paper UI konfiguriert.
Genau genommen liest openHAB beim Systemstart (und bei jeder Änderung) die Text Konfiguration ein und übersetzt sie in ein internes Format, welches dann aber nur im Speicher gehalten wird - jedenfalls was items und things betrifft.

VSCode erleichtert die Arbeit mit den Textdateien erheblich, denn mit dem zugehörigen Plugin werden alle Formate aller relevanten Dateien hübsch bunt angezeigt. Es gibt Kontexthilfe und Fehler werden auch markiert. Ebenso gibt es Templates für Vieles. Leider ist damit aber nicht alles abgedeckt.
Man kann über VSCode alles konfigurieren, was man auch mit Paper UI konfigurieren kann, nur in Textform. Aber man muss zumindest eine grobe Ahnung haben, welche Schlüsselworte zu verwenden sind.
Die Schlüsselworte kann man übrigens über die REST API herausfinden, falls die Online Doku da streikt. Dazu legt man dann das Thing über Paper UI an, geht in die REST API und lässt sich das Thing anzeigen (Die UID ist der Name des Thing). In der Antwort (wenn ich mich richtig erinnere JSON Format) stehen alle Felder drin, ob sie nun einen Parameter haben oder nicht.
Das grundsätzliche Format der *.things Datei ist für alle Things und Bridges gleich:

Code: Alles auswählen

Bridge binding:bridge-part:bridgeUID "Label der Bridge" @ "Tab in Paper UI Control" [
// Parameterliste für die Bridge
] {
 Thing thing-part thingUID "Label des Thing" @ "Tab in Paper UI Control" [
 // Parameterliste für das Thing 
 ] {
Channels:
  Type channeltype : channelUID "Label des Channel" [
  // Parameterliste für den Channel
  ]
 }
}
Dieses Konfigurationsmodell hat einen Haken, nämlich, dass alle Things gemeinsam mit ihrer Bridge in einer Datei liegen müssen. Deshalb gibt es alternativ noch eine zweite Schreibweise. Diese findet auch Verwendung, wenn ein Thing keine Bridge braucht (dann lässt man den Bridge-Teil weg):

Code: Alles auswählen

Bridge binding:bridge-part:bridgeUID "Label der Bridge" @ "Tab in Paper UI Control" [
// Parameterliste für die Bridge
] 
Thing binding:thing-part:bridgeUID:thingUID "Label des Thing" (binding:bridge-part:bridgeUID) @ "Tab in Paper UI Control" [
 // Parameterliste für das Thing 
 ] {
Channels:
  Type channeltype : channelUID "Label des Channel" [
  // Parameterliste für den Channel
  ]
 }
Dieses Konfigurationsmodell kann also alle Things wild über Dateien verteilen. Nachteil ist, dass man bei jedem Thing die zugehörige Bridge angeben muss.

Das Schlüsselwort Bridge kann auch durch das Schlüsselwort Thing ersetzt werden. Mindestens das Schlüsselwort Channels: kann auch wegfallen.

Bei den Items sieht es besser aus, weil openHAB die "schon immer" über Textdateien konfigurierbar hat.

Code: Alles auswählen

Itemtyp itemname "Itemlabel[Darstellung des Status]" <icon> (Gruppe) [ Tags ] {bindings} 
Es sind im Laufe der Zeit ein paar Spezialitäten dazu gekommen (z.B. UoM - Unterkategorien für den Itemtyp Number oder auch die Festlegung des Gruppentyps), aber auch diese Spezialfälle sind mit dem Format abgedeckt.

VSCode erlaubt übrigens, automatisch Items in Textform zu bestehenden Channels oder kompletten Things zu erzeugen. Ebenso können die Items automatisch in Sitemaps eingefügt werden. Dabei ist es irrelevant, auf welche Weise die Things/Items entstanden sind. :)

Der große Unterschied zur UI wird dann sichtbar, wenn man die Namen vieler Items (oder Ähnliches) anpassen muss,beisßielsweise weil einem die von VSCode erzeugten Namen nicht gefallen, das geht in einem Texteditor halt viel schneller als über eine UI, selbst falls diese den Zugriff auf den Namen erlaubte ;)
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Antworten