Anzeige Status Heizungspumpen

[crsp]

Hallo,

ich wollte mal nachfragen ob es eine elegantere Möglichkeit gibt, den Status eines Gerätes anzuzeigen (ON/OFF) als über ein Switch Item.
Konkreter Fall, Vitogate (Viessmann) sendet u.a. den Status der diversen Pumpen auf den Bus.
Im Moment habe ich das wie gesagt über Switch Items visualisiert, was ja aber unsinnig ist, da muss ja nichts geschaltet werden.

Gruss, Rico

[thoern]

Natürlich. Einfach in der Sitemap das entprechende Item z.B. auf Text umdefinieren.

Beispiel:

Items:

Switch sonybravia  "Sony Bravia TV"  <network>  (Netzwerk)  { nh="sonybravia" }

Sitemap:

 Text item=sonybravia label="Sony Bravia TV [MAP(network.map):%s]" icon="network"

Gruß,
thoern

[crsp]

Ah! Tatsächlich!

So hatte ich das auch schonmal. Allerdings zeigte es mir dann das Label komplett an, mit mapping.

Also aus dem Beispiel

Text item=sonybravia label="Sony Bravia TV [MAP(network.map):%s]" icon="network"

erschien im Webfrontend als Label:

Sony Bravia TV [MAP(network.map):%s]

o.O

Egal. Wahrscheinlich half der Reboot zwischendurch das Problem zu beheben. Auf jeden Fall gehts jetzt.

Vielen Dank thoern!

[thoern]

Egal. Wahrscheinlich half der Reboot zwischendurch das Problem zu beheben. Auf jeden Fall gehts jetzt.

Vielen Dank thoern!

Ich glaube eher weniger, dass das am Reboot lag. Vielleicht hattest du bei deinen ersten Version irgendwo ein Sonderzeichen zu wenig oder zu viel...

[tuxedo]

Das Thema ist zwar schon ein wenig älter, aber ich stehe vor ähnlichem Problem. Hab noch keine große Installation und bin am testen..


Was mich jetzt aber verwirrt, ist der hier vorgeschlagene Lösungsansatz.

Ist doch Käse wenn ich in Items das Item als "schaltbar" definieren muss, es aber gar nicth schaltbar haben will und dann in Sitemaps das Item NOCHMAL eintragen muss, nur um es von SCHALTBAR auf NUR-ANZEIGEN umzudefinieren .

Ein normales Switch-Item muss ich ja nur in den Items definieren und in der Sitemap reicht es dann übergeordnet die Gruppe anzugeben.

Wäre es nicht sinnvoll gleich von vornherein ein reines Status-Item zu haben? Ich meine: Ein Status ist ja nicht allzu abwegiges und wird wohl in jedem Projekt gleich mehrfach auftauchen.

Mal davon abgesehen: Wie und wo würde ich denn das Item (Status_EG_Bad) in der Sitemap umdefinieren?

Beispiel:

items:

Group gEG       // ( ALL ) Gruppe Erdgeschoss
Group gDG       // ( ALL ) Gruppe Dachgeschoss


Group           EG_Schlafzimmer "Schlafzimmer"  <bedroom>       (gEG)
Group           EG_Bad          "Bad"                           <bath>          (gEG)
Group           EG_Technik      "Technik"                                               (gEG)
Group           EG_Kueche       "Küche"                         <kitchen>       (gEG)
Group           EG_Essen        "Essen"                                                 (gEG)
Group           EG_Wohnen       "Wohnen"                        <sofa>          (gEG)
Group           EG_Flur         "Flur"                          <corridor>      (gEG)

Group           DG_Bad          "Bad"                           <bath>          (gDG)
Group           DG_Kind1        "Spielzimmer"           <child1>        (gDG)
Group           DG_Kind2        "Kinderzimmer"          <child2>        (gDG)
Group           DG_Gast         "Gast"                          <guest>         (gDG)
Group           DG_Buero        "Büro"                          <office>        (gDG)
Group           DG_Flur         "Flur"                          <corridor>      (gDG)


// Licht
Switch          Licht_EG_Bad            "Licht Bad"                     (EG_Bad)                {knx="1/1/10+1/4/10"}
Switch          Status_EG_Bad           "Belegt"                        (EG_Bad)                {knx="5/0/2"}

sitemap:

sitemap my label="Hauptmenü"
{
        Frame label=Haus {
                Group item=gDG  label="Dachgeschoss"    icon="firstfloor"
                Group item=gEG  label="Erdgeschoss"     icon="groundfloor"
        }
}

[udo1toni]

Ist doch Käse wenn ich in Items das Item als "schaltbar" definieren muss, es aber gar nicth schaltbar haben will und dann in Sitemaps das Item NOCHMAL eintragen muss, nur um es von SCHALTBAR auf NUR-ANZEIGEN umzudefinieren.

Warum sollte man sich künstlich beschränken?
Items sind generell erstmal richtungsunabhängig. Bei Switchen und Dimmern erzeugt openhab als Standard ein Element mit Bedienelementen, bei anderen Items (z.B. Number) wird als Standard nur eine Anzeige erzeugt. Wenn man eine andere Ansicht wünscht, muss das in der Sitemap definiert werden. Da es durchaus normal ist, an einer Stelle eine reine Anzeige zu haben, und an anderer Stelle (vielleicht sogar in der selben sitemap) das Item zu steuern, muss ohnehin die Möglichkeit bestehen, das zu konfigurieren.
Falls Du einen Kontakt hast (Fenster, Tür, Klingelknopf usw.), kannst Du das Contact-Item verwenden, das hat dann keine Schaltmöglichkeit.

Die Group-Funktion in der Sitemap verstehe ich ohnehin eher als "schnell was sehen"-Funktion, schon wenn ich die Reihenfolge der Items beeinflussen will, komme ich um ein Ausformulieren nicht herum.

[tuxedo]

Warum sollte man sich künstlich beschränken?
Items sind generell erstmal richtungsunabhängig. Bei Switchen und Dimmern erzeugt openhab als Standard ein Element mit Bedienelementen, bei anderen Items (z.B. Number) wird als Standard nur eine Anzeige erzeugt.

Das leuchtet ja auch alles ein. Mich wundert es nur, dass man neben "Number" und "String" nicht auch "Boolean" kennt/implementiert hat.
Wäre das wirklich so eine schlechte Idee?!

Wenn man eine andere Ansicht wünscht, muss das in der Sitemap definiert werden. Da es durchaus normal ist, an einer Stelle eine reine Anzeige zu haben, und an anderer Stelle (vielleicht sogar in der selben sitemap) das Item zu steuern, muss ohnehin die Möglichkeit bestehen, das zu konfigurieren.

Leuchtet auch ein. Aber Elemente die man in gar keinem Fall steuer kann und möchte, muss ich so _immer_ "umdefinieren". Das meinte ich mich "ist doch käse".

Falls Du einen Kontakt hast (Fenster, Tür, Klingelknopf usw.), kannst Du das Contact-Item verwenden, das hat dann keine Schaltmöglichkeit.

Ist kein Fenster-Kontakt und auch kein Klingelknopf, aber das geht doch genau in diese Richtung: Anzeige eines Status (Fenster offen/zu, Kontakt offen/geschlossen ----> Pumpe an/aus).

Werd' ich mir mal anschauen ob das das ist wofür ich es halte.

Die Group-Funktion in der Sitemap verstehe ich ohnehin eher als "schnell was sehen"-Funktion, schon wenn ich die Reihenfolge der Items beeinflussen will, komme ich um ein Ausformulieren nicht herum.

Okay, das ist ja auch eine Aussage. Wenn es "gang und gebe" ist dass man in der Sitemap alles _nochmal_ aufführt... Dachte aber die Reihenfolge wird aus der Items-File übernommen? Zumindest ist das meine bisherige Beobachtung.

[thoern]

Das leuchtet ja auch alles ein. Mich wundert es nur, dass man neben "Number" und "String" nicht auch "Boolean" kennt/implementiert hat.
Wäre das wirklich so eine schlechte Idee?!

Du siehst das nur verkehrt: Dein Boolean-Item heißt hier "Switch". Wenn du möchtest, kannst du das auch als Statusitem betrachten, das über die reine Statusanzeige hinaus sogar noch "schaltbar" ist . Als anzeigendes Element wird per Default ein Switch dargestellt. Du musst aber keinen Switch anzeigen lassen -> Sitemap

Leuchtet auch ein. Aber Elemente die man in gar keinem Fall steuer kann und möchte, muss ich so _immer_ "umdefinieren". Das meinte ich mich "ist doch käse".

Ab einem gewissen Grad musst du das sowieso, oder wie soll denn, um beim Boolean-Item zu bleiben, ein solches dargestellt werden? Was soll es anzeigen:

"Ein - Aus" oder "0 - 1" oder "aktiv - passiv" oder "oben - unten" oder "offen - geschlossen" oder "open - closed" usw.

Die Darstellung und Beschriftung richtet sich danach wofür das Item verwendet wird, nicht danach ob es technisch "boolean" oder sonst etwas ist. Openhab gibt dir genau diese Freiheiten. Was auf den ersten Blick vielleicht etwas verwirrend ist, eröffnet dir tatsächlich äußerst komfortable Gestaltungsmöglichkeiten.

[tuxedo]

Okay, ich muss mein Problem umformulieren:

Ich finde es "ungeschickt", dass ich zum einen ein Item anlegen muss, dort das Item benennen kann, ihm ein Icon verpassen kann, es in eine Gruppe stecken kann und innerhalb der Gruppe sortieren kann, nur um dann später in der Sitemap einen Teil davon zu wiederholen, es aber diesmal nicht als Switch, sondern als String etc. definieren muss, nur damit das Item, das per se nicht gesetzt, sondern nur gelesen werden kann, korrekt abzubilden.

Was soll es anzeigen:

"Ein - Aus" oder "0 - 1" oder "aktiv - passiv" oder "oben - unten" oder "offen - geschlossen" oder "open - closed" usw.

Das Problem ist nicht das was es anzeigen soll, sondern dass ich es 2x konfigurieren _muss_. Zumindest für den einfaches Fall einer simplen Status-Anzeige.

Kurz gesagt: Warum kann ich das nicht bei der Definition des Items angeben (abgeschlossene Definition), sondern _muss_ es in der Sitemap angeben?

Wenn ich jetzt 200 Statis anzeigen will, dann reicht es nicht diese 200 Einträge in der items-File zu machen, sondern ich muss auch noch weitere 200 Einträge in der Sitemap machen, obwohl es ein grundlegendes Instrument namens "Gruppe" schon gibt, ich es aber nicht verwenden kann weil ich jedes der 200 Items nochmal "umdefinieren" muss?
Oder hab ich etwas übersehen?

Erklärt das meine Problematik nun besser?

[thoern]

Das Problem ist nicht das was es anzeigen soll, sondern dass ich es 2x konfigurieren _muss_.
....
Oder hab ich etwas übersehen?

Erklärt das meine Problematik nun besser?

Ich habe deine Sichtweise schon verstanden. Das ist der Trennung zwischen Presentation- und Datenlayer (such mal nach MVC) geschuldet.

Die Darstellung steuerst du über die Sitemap.
Die Definition der Items erfolgt im Items-File.

Das sind erst einmal zwei paar Schuhe. Strenggenommen ist das Problem eigentlich, dass du auch im Items-File, Darstellungelemente wie Icons definieren kannst. Gemäß MVC gehört so etwas da eigentlich nicht hin. Aber es macht es halt etwas einfacher, um auch mit einfachen Sitemaps relativ schnell zu einem halbwegs brauchbaren Ergebnis zu kommen.

Gruß,
thoern

[udo1toni]

Strenggenommen ist das Problem eigentlich, dass du auch im Items-File, Darstellungelemente wie Icons definieren kannst. Gemäß MVC gehört so etwas da eigentlich nicht hin. Aber es macht es halt etwas einfacher, um auch mit einfachen Sitemaps relativ schnell zu einem halbwegs brauchbaren Ergebnis zu kommen.

Und hat nebenbei den Vorteil, dass man eine Standard-Ansicht definieren kann, aber bei Bedarf davon abweichen kann.
Man stelle sich eine Sitemap vor, in der das selbe Item mehrfach vorkommt.

Ich habe z.B. in jeder Raumansicht meine Leuchten. Dann habe ich noch eine Gruppe, die aber nur die eingeschalteten Leuchten anzeigt (mit visibility=item.state), ähnliches gilt auch für Rollläden usw., da spart eine Standardansicht samt Label und icon einiges an Tipparbeit.

[tuxedo]

Ich habe deine Sichtweise schon verstanden. Das ist der Trennung zwischen Presentation- und Datenlayer (such mal nach MVC) geschuldet.

Das MVC Prinzip ist mir als Softwareentwickler durchaus bekannt ;-)

Das sind erst einmal zwei paar Schuhe. Strenggenommen ist das Problem eigentlich, dass du auch im Items-File, Darstellungelemente wie Icons definieren kannst. Gemäß MVC gehört so etwas da eigentlich nicht hin.

Das ist genau der Punkt der sich hier "beisst".

Aber es macht es halt etwas einfacher, um auch mit einfachen Sitemaps relativ schnell zu einem halbwegs brauchbaren Ergebnis zu kommen.

... mit dem "Nachteil" dass man da ggf. als Neuling drüber stolpern kann.
Um die Einstiegshürde weiter zu senken wäre ein "Wie gehe ich Schritt-für-Schritt vor und wohin führt das" Artikel im Wiki nicht schlecht. Noch überblicke ich das System zu wenig um hier einen fundierten Artikel beisteuern zu können :-(

[thoern]

... mit dem "Nachteil" dass man da ggf. als Neuling drüber stolpern kann.
Um die Einstiegshürde weiter zu senken wäre ein "Wie gehe ich Schritt-für-Schritt vor und wohin führt das" Artikel im Wiki nicht schlecht. Noch überblicke ich das System zu wenig um hier einen fundierten Artikel beisteuern zu können :-(

Also ich würde dir auf jeden Fall empfehlen, die Demo zu installieren. Dort kannst du dir dann die demo.items und demo.sitemap anschauen und siehst auch, wie das in der Oberfläche aussieht. Dann sollte eigentlich vieles klarer werden. Ich habe auf meinem System sowieso immer 2 Openhab-Umgebungen installiert (in der gleichen Version): Produktion und Demo.

Produktion befindet sich bei mir unter:
/opt/openhab/

Demoversion unter
/opt/openhab-demo/

Die Demo-Version hört bei mir auf einen anderen Port und startet nicht automatisch. Ich fahre sie nur bei Bedarf hoch. Überdies hat die zus. Installation eines Demo-Openhab auch den Vorteil, dass du schnell mal was in den Demo-Konfigs nachschauen kannst, wenn du auf Anhieb nicht die Syntax kennst.

Gruß,
thoern