Info-Werte "zusammensetzen" ??

[tuxedo]

Meine Wärmepumpe gibt den Wert der Wärmemenge für's Heizen über 3 GAs raus:

Heizung Wärmemenge Heizen 1-4
Heizung Wärmemenge Heizen 5-8
Heizung Wärmemenge Heizen 9-12

Der Wert kann 12-stellig werden. In der ersten GA findet man Stelle 1-4, in der zweiten 5-8 und in der dritten 9-12.

Wie krieg ich die 3 Werte in der Anzeige zu einem 9-stelligen Wert zusammengebaut?

Sprich: Wie kann ich im Info-Widget die Werte die da ankommen zu einem Wert zusammenkonkatenieren?

Ich weiß, ich muss da die führenden 0en berücksichtigen...

Any ideas?

[coolrunnings]

Ich würde es mit dem Logikprozessor Plugin von Fry probieren und dann eine vierte GA erstellen die den kalkulierten Wert ausgibt. Wäre das eine Möglichkeit?

Gruß

[tuxedo]

Öhm, setzt das nicht ein Wiregate voraus?

Eine Logik-Engine hab ich selbst (siehe Signatur), aber ich kann die Logik nicht explizit nach einer "virtuellen" GA fragen (zumindest noch nicht). Die Logiken werden eigentlich durch Änderungen von Daten die über den Bus gesendet werden ausgelöst. Und da sich die Wärmemengenzähler der Wärmepumpe nur seeeeeeeeeeeehr langsam ändern, hab ich da ein Problem.

Scheint so als würde ich hier ein Widget brauchen, oder eines anpassen/erweitern müssen.

[stBorchert]

Moin.
Vor dem gleichen Problem stand ich auch bei meinen Fensterkontakten.
Ich habe z.B. in einem 2-flügligen Fenster 4 Sensoren verbaut (links oben/unten, rechts oben/unten), so dass ich von jedem Flügel den Status geschlossen, gekippt, geöffnet abfragen kann. Anzeigen wollte ich jedoch für das gesamte Fenster den Status über die vorhandenen Icons ("fts_window_2w*").

Also habe ich mir einfach zu den einzelnen Kontakten ein neues Item definiert ("Group" und "SUM" wäre nachträglich betrachtet gar nicht notwendig, ein einfaches Number-Item hätte auch ausgereicht. Naja, nächste Version ):

Group:Number:SUM                            WindowCorridor        "Fensterkontakt Flur [%d]"          (Status, FF_Windows)

// Sensors
Contact Window_FF_Corridor_TL         "Fensterkontakt links oben [MAP(de.map):%s]"       (FF_Corridor, FF_Windows, WindowCorridor)   { knx="<1/3/6" }
Contact Window_FF_Corridor_BL         "Fensterkontakt links unten [MAP(de.map):%s]"      (FF_Corridor, FF_Windows, WindowCorridor)   { knx="<1/3/7" }
Contact Window_FF_Corridor_TR         "Fensterkontakt rechts oben [MAP(de.map):%s]"      (FF_Corridor, FF_Windows, WindowCorridor)   { knx="<1/3/8" }
Contact Window_FF_Corridor_BR         "Fensterkontakt rechts unten [MAP(de.map):%s]"     (FF_Corridor, FF_Windows, WindowCorridor)   { knx="<1/3/9" }

Dazu dann noch eine kleine Rule, die den aktuellen Wert für "WindowCorridor" berechnet (siehe Anhang).
Damit kann ich dann in der Visu einfach den Status von "WindowCorridor" verwenden und das entsprechende Icon über ein Styling anzeigen.

<mapping name="WindowStatus2w">
  <entry value="0" default="true">
    <icon flavour="white" name="fts_window_2w"/>
  </entry>
  <entry value="1">
    <icon flavour="white" name="fts_window_2w_tilt_l"/>
  </entry>
  <entry value="3">
    <icon flavour="white" name="fts_window_2w_open_l"/>
  </entry>
  <entry value="4">
    <icon flavour="white" name="fts_window_2w_tilt_r"/>
  </entry>
  <entry value="5">
    <icon flavour="white" name="fts_window_2w_tilt_lr"/>
  </entry>
  <entry value="7">
    <icon flavour="white" name="fts_window_2w_open_l_tilt_r"/>
  </entry>
  <entry value="12">
    <icon flavour="white" name="fts_window_2w_open_r"/>
  </entry>
  <entry value="13">
    <icon flavour="white" name="fts_window_2w_tilt_l_open_r"/>
  </entry>
  <entry value="15">
    <icon flavour="white" name="fts_window_2w_open_lr"/>
  </entry>
</mapping>
<!-- ... -->
<group name="Flur">
  <info align="right" mapping="WindowStatus2w">
    <address transform="OH:Number" mode="read">WindowCorridor</address>
  </info>
</group>

Ich denke mal, so in etwa liesse sich das mit Deinem Status auch lösen.

[tuxedo]

Setzt wohl OpenHAB voraus.

Werde es wohl über meine LogikEngine (als teil meines eigenen CV Backends) lösen.

[Chris M.]

Meine Wärmepumpe gibt den Wert der Wärmemenge für's Heizen über 3 GAs raus:
[...]
Wie krieg ich die 3 Werte in der Anzeige zu einem 9-stelligen Wert zusammengebaut?

Gar nicht - denn das ist Aufgabe einer LogikEngine und nicht die einer Visu. (Aber das ist doch sooo simpel. Und dann kommt der nächste der nur mal schnell aus Temperatur und Luftfeuchte den Taupunkt berechnen und anzeigen lassen möchte. Etc. pp.)

Was Du machen kannst (aber halt nicht solltest...) wäre höchstens 3x in Info-Widget hintereinander. Führende Nullen sollten sich per Mapping einbauen lassen.

[tuxedo]

Gar nicht - denn das ist Aufgabe einer LogikEngine und nicht die einer Visu.

Darüber kann man streiten.

Was Du machen kannst (aber halt nicht solltest...) wäre höchstens 3x in Info-Widget hintereinander.

Nur rein aus interesse:

wenn ich 3x ein Infowidget benutze, dann passt das doch vorne wie hinten nicht (weil jeweils Rahmen etc. pp. drum herum).
Und 3x in einem Infowidget: Wie soll das gehen?

[coolrunnings]

wenn ich 3x ein Infowidget benutze, dann passt das doch vorne wie hinten nicht (weil jeweils Rahmen etc. pp. drum herum).

Das lässt sich aber relativ leicht mit einer eigenen css Klasse regeln.

[jolt]

Gar nicht - denn das ist Aufgabe einer LogikEngine und nicht die einer Visu. (Aber das ist doch sooo simpel. Und dann kommt der nächste der nur mal schnell aus Temperatur und Luftfeuchte den Taupunkt berechnen und anzeigen lassen möchte. Etc. pp.)

Taupunkt ist für mich klar eine Aufgabe der Logik Engine. Da sind wir uns sicher einig. Aber alles was zur (reinen) Darstellung sollte IMHO von der Visu unterstützt werden. Die Logik Engine für Formatierungen zu missbrauchen ist aus meiner Sicht genauso falsch wie die Visu (Taupunkt)Berechnungen machen zu lassen.

Das Fenster Beispiel oben ist sicher ein prima Beispiel dafür, wo es Feature mäßig noch Ausbaupotential gibt. Fenster mit mehreren unabhängigen States sollten über entsprechend viele Eingänge verfügen, damit man eben nicht vorher in der Logik Engine basteln muss. Im Gira HS Quadclient ist das übrigens auch so gelöst.

Die andere Baustelle sind Format Strings mit mehreren Variablen. Es wäre extrem praktisch, wenn man hier nicht immer über die Logik Engine gehen müsste, sondern einfach mehrere GA's listen könnte und die dann format spezifisch zusammen angezeigt (aber nicht verrechnet) werden. Da ich das selbst nutzen könnte, würde ich mir das mal angucken falls Interesse besteht?

[tuxedo]

Da ich das selbst nutzen könnte, würde ich mir das mal angucken falls Interesse besteht?

*interesseanmeld* Hab zur Zeit noch genug andere Baustellen, so dass es toll wäre wenn sich das einer mit entsprechendem KnowHow anschaut.

[Chris M.]

Ich wollte v.a. darauf raus, dass man sich immer Gedanken machen muss, ob etwas in eine LogikEngine gehört oder in der Visu gemacht werden kann. Vieles ist eindeutig (auch wenn von Anwendern viel mehr in der Visu gesehen wird als logisch Sinn macht...), manches ist Streitfrage.

Wenn ein Widget zwingend mehrere GAs braucht um zu funktionieren (wie z.B. der ColorChooser) dann kann man dass natürlich machen. Das ist aber eine große Ausnahme.

Zum Thema zurück: was ich mir vorstellen könnte, wäre das Info-Plugin um mehrere GAs zu erweitern (das Attribut variant würde dann einen Integer-Index oder einen ID-String bekommen) um die in einem komplexeren Format-String in dynamischen Text übersetzen zu lassen.
Aber auch da wird dann irgendwann jemand kommen der nun auch noch ein Mapping (für jede GA natürlich getrennt) haben möchte...

=> Ich finde immernoch, dass das bereits ein Thema für eine LogikEngine ist.

Übrigens: im Zweifel ist das eine super Anwendung für ein Custom Widget

[jolt]

Ich habe das Thema nun etwas näher angeschaut. Um das Info Widget Multi Adressen fähig zu machen sind zwei Änderungen nötig:

1. defaultValueHandling Funktion muss die Werte aller Adressen an die Format Funktion übergeben. Dazu braucht es einen Cache in den widgetData, da die Funktion nur den neuen Wert einer der betroffenen GA's übergeben bekommt. Alle nicht geänderten Werte müssen aus dem Cache besorgt werden. Das Diff sieht so aus:

 [FONT=Monaco][SIZE=10px]diff --git a/src/structure/pure/_common.js b/src/structure/pure/_common.js[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]index 6cbd8db..8f165a0 100644[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]--- a/src/structure/pure/_common.js[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+++ b/src/structure/pure/_common.js[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]@@ -152,6 +152,8 @@ function VisuDesign() {[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     } else {[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]       var thisTransform = '';[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]       var value = data;[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+      widgetData["formatValueCache"] = {};[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     }[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     [/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     widgetData.basicvalue = value; // store it to be able to supress sending of unchanged data[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]@@ -162,8 +164,15 @@ function VisuDesign() {[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     // #3: format it in a way the user understands the value[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     if( widgetData.precision )[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]       value = Number( value ).toPrecision( widgetData.precision );[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]-    if( widgetData.format )[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]-      value = sprintf( widgetData.format, value );[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+    if( widgetData.format ) {[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+      widgetData.formatValueCache[ga] = value;[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+      var argList = [widgetData.format];[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+      for (var addr in widgetData.address)[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+        argList.push(widgetData.formatValueCache[addr]);[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+      value = sprintf.apply(this, argList);[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]+    }[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     widgetData.value = value;[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     if (undefined !== value && value.constructor == Date)[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]     {[/SIZE][/FONT]

2. Die aktuell in CV genutzte sprintf Funktion (von hier) unterstützt keine Index Angaben. Ich habe daher diese Version verwendet. Geht aber auch jede andere Implementierung mit Index Support.

Mit diesen beiden Änderungen können nun in der Config beliebig viele GAs gelistet und per Format String referenziert werden. Die Reihenfolge der GA's in der Config entspricht dann dem im Format String zu verwendenden Index. Der Index kann auch mehrfach genutzt werden, wenn die gleiche Wert mehrfach dargestellt werden soll.

<info format="%1$.2f Bar / %2$.1f °C / %1$04d%2$04d">
  <layout colspan="12"/>
  <label><icon name="measure_pressure_bar"/>Druck</label>
  <address transform="OH:number">WP_DruckHeizkreis</address>
  <address transform="OH:number">WP_VorlauftemperaturIST</address>
</info>

[jolt]

Ein Bild sagt mehr als 1000 Worte
info.png


Oben in der Nav Bar nutze ich das Feature um beim Licht die Anzahl der eingeschalteten Lampen pro Etage darzustellen. Unten beim Druck sieht man wie zwei Werte dargestellt werden und zusätzlich dahinter noch einmal als eine Zahl bestehend aus verschiedenen GA (was ja die Ursprungsanforderung aus dem Thread hier war).

[tuxedo]

Coole Sache und sehr flexibel einsetzbar. Danke. Werd's bei Gelegenheit gleich ausprobieren.

[Chris M.]

Sehr schön!

Mit diesen beiden Änderungen können nun in der Config beliebig viele GAs gelistet und per Format String referenziert werden. Die Reihenfolge der GA's in der Config entspricht dann dem im Format String zu verwendenden Index.

Ich weiß gar nicht ob die Reihenfolge der Addressen so stabil ist, dass man sich darauf verlassen darf. Nicht dass z.B. der Editor die durcheinander würfelt...
=> Sollten wir nicht das Attribut variant dafür nutzen? Es ist eigentlich für solche Fälle da (vgl. ColorChooser)