infotrigger: zeigt Wert nicht an, wenn mehr als eine GA definiert

[mivola]

Hallo zusammen,

ich benutzte die git-Version der CV und habe folgendes Fehlverhalten des infotrigger festgestellt: Sobald 2 unterschiedliche GAs in der Address-Liste auftauchen wird kein Wert in der UI angezeigt. Beim drücken der beiden Buttons wird allerdings der korrekte Wert gesendet.

        <infotrigger uplabel="wärmer" upvalue="1" downlabel="kälter" downvalue="-1" align="center" infoposition="middle" format="%.1f °C" change="absolute" min="15" max="25">
          <label>Ferien-Temperatur</label>
          <address transform="DPT:9.001" mode="write">1/6/22</address>
          <address transform="DPT:9.001" mode="read">1/5/22</address>
        </infotrigger>

Ich habe letzte Woche seit langer Zeit mal wieder ein Update gemacht. Ich weiß also nicht, seit wann es nicht mehr funktioniert, aber mit meiner Backup-Version vom Mai 2015 geht es noch.

VG
Micha

[Chris M.]

Wie aktuell ist die Git Version? Bzw. ist Pull-Request https://github.com/CometVisu/CometVisu/pull/246 schon drinnen?

Ich hab zwar nicht versucht das Problem nachzustellen - aber ich hatte wo anders ein ähnliches Problem und das war damit gefixt.

[mivola]

Wie aktuell ist die Git Version? Bzw. ist Pull-Request https://github.com/CometVisu/CometVisu/pull/246 schon drinnen?

Ich hab zwar nicht versucht das Problem nachzustellen - aber ich hatte wo anders ein ähnliches Problem und das war damit gefixt.

OK, ich habe gestern abend nochmal ein Update gemacht. Das oben beschriebene Problem ist damit anscheinend behoben. Allerdings habe ich nun ein Problem mit dem Formatieren der Werte. Im "format"-Attribut stand bisher "%.0f °C" drin. Dies führt jetzt zu "sprintf Error". Die Formatierung in einem diagram_info funktioniert mit genau derselben Anweisung aber weiterhin. Wenn ich das format-Attribut in infotrigger leer lasse, dann wird auch der korrekte Wert angezeigt...

Was allerdings auch sein könnte: es war auch vorher schon ein Problem mit der Formatierung (statt mit dem infotrigger an sich), nur wird der entsprechende Fehler jetzt auch angezeigt und vorher einfach nichts angezeigt. Ich habe auch schon diverse Formatierungsvarianten ausprobiert, leider alles ohne Erfolg...

Ideen?

Danke,
Micha

[Chris M.]

Kann es sein, dass Du ein Codierungs-Problem hast, d.h. dass die Config-Datei kein reines UTF-8 ist?

Im Zweifel: bau mal eine Minimale Config die das Problem zeigt und häng die hier an.

[mivola]

Hi,

lt. Editor liegt die Datei in UTF-8 vor. Anbei mal eine Minimal-Config und Screenshot.

<?xml version="1.0" encoding="UTF-8"?>
<pages xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" lib_version="8" design="pure" xsi:noNamespaceSchemaLocation="../visu_config.xsd">
  <meta>
    <plugins>
    </plugins>
    <mappings>
    </mappings>
    <stylings>
    </stylings>
    <statusbar>
      <status type="html"><![CDATA[
          <img src="icon/comet_64_ff8000.png" alt="CometVisu" /> by <a href="http://www.cometvisu.org/">CometVisu.org</a>
          - <a href="manager.php">Config-Manager</a>
          - <a href=".?forceReload=true">Reload</a>
        ]]></status>
      <status type="html" condition="!edit" hrefextend="config"><![CDATA[
          - <a href="editor/">Edit</a>
        ]]></status>
      <status type="html" condition="edit" hrefextend="config"><![CDATA[
          - <a href=".">normal Mode</a>
        ]]></status>
      <status type="html"><![CDATA[
          - <a href="?config=demo">Widget Demo</a>
        ]]></status>
      <status type="html" hrefextend="config"><![CDATA[
          - <a href="check_config.php">Check Config</a>
        ]]></status>
    </statusbar>
  </meta>
  <page name="Start">
        <infotrigger uplabel="wärmer" upvalue="1" downlabel="kälter" downvalue="-1" align="center" infoposition="middle" format="%.0f °C" change="absolute" min="15" max="25">
          <label>mit format</label>
          <address transform="DPT:9.001" mode="write">1/3/12</address>
          <address transform="DPT:9.001" mode="read">1/2/12</address>
        </infotrigger>
        <infotrigger uplabel="wärmer" upvalue="1" downlabel="kälter" downvalue="-1" align="center" infoposition="middle" change="absolute" min="15" max="25">
          <label>ohne format</label>
          <address transform="DPT:9.001" mode="write">1/3/12</address>
          <address transform="DPT:9.001" mode="read">1/2/12</address>
        </infotrigger>
        <infotrigger uplabel="wärmer" upvalue="1" downlabel="kälter" downvalue="-1" align="center" infoposition="middle" format="%.0f °C" change="absolute" min="15" max="25">
          <label>mit format, mit readwrite</label>
          <address transform="DPT:9.001" mode="readwrite">1/3/12</address>
        </infotrigger>
  </page>
</pages>

infotrigger.png

Danke,
Micha

[Chris M.]

Jetzt kann ich's nachvollziehen. Ist ein Bug der durch den Code kam mehrere GAs in einem Widget anzeigen zu können

Workaround bis zum Fix: tausche die Reihenfolge der beiden <address> Elemente, so das dass read zuerst kommt.

[mivola]

OK, danke für die schnelle Info. Falls ich irgendwann etwas testen soll, lass es mich wissen. Der Workaround funktioniert aber problemlos.

Danke!
Micha

[jolt]

Chris M. Mir scheint es kommt hier zu Seiten Effekten von Workarounds. Im aktuellen develop mit der Demo Config von mivola wird sprintf wie folgt aufgerufen:

sprintf("%.4f °C", "<UNDEF>", 20.86)

Ohne deinen PR246 würde der Aufruf sein:

sprintf("%.4f °C", undefined, 20.86)

Das ist beides natürlich kompletter Unfug und somit sehe ich auch erst einmal kein Problem mit dem Ergebnis

Fixen kann man das jetzt auf zwei Arten:

1. Reverten von PR246 und dann im sprintf Wrapper undefined Argumente aus der Argumente Liste löschen (quick + dirty)
2. Reverten von PR246 und alle Caller von sprintf fixen, damit gar nicht erst undefined übergeben wird (mehr Arbeit + sauberer)

Ich persönlich wäre für Variante 2, daher hatte ich auch gar nicht erst versucht mit undefined umzugehen, sondern das Ergebnis fix auf "<UNDEF>" verdrahtet. Das fällt nämlich sofort auf.

[Chris M.]

Ich glaube wir müssen das ganz anders angehen:
Erweitern der <address> Elemente um einen Parameter wie "formatposition" der einen Integer Wert aufnimmt und sagt wo im Format-String der Wert eingebaut wird (bzw. an welcher Parameter-Position der Wert übergeben wird).

Denn die aktuelle Lösung dürfte auch scheitern, wenn man bewusst mehrere GAs per read aboniert hat, was mit hörenden GAs ja ganz üblich ist.

[jolt]

Wenn man statt "%.4f °C" einfach einen Index benutzt kann man schon jetzt einen beliebigen Parameter adressieren: "%2$.4f °C" (2$ = 2. Parameter). Ein zusätzlicher Index Parameter bei den Adressen würde meiner Meinung nach die Sache nur verkomplizieren.

Das ursächliche Problem scheint sich in der Tat durch meinen Multi Adressen Umbau eingeschlichen zu haben. Da write only Werte nie aktualisiert werden, ist logischer weise auch kein Wert im Cache, daher kommt dann ein undefined im sprintf an. PR für den Fix habe ich bereits geöffnet. Es werden nun keine Write Only Adressen mehr an sprintf übergeben.

@Chris M. kannst du mal bitte bei dir PR246 reverten und schauen ob deine Probleme durch meinen Fix auch behoben sind?

[mivola]

Wenn man statt "%.4f °C" einfach einen Index benutzt kann man schon jetzt einen beliebigen Parameter adressieren: "%2$.4f °C" (2$ = 2. Parameter).

Das funktioniert tatsächlich :-) Das sollte also noch entsprechend in die Doku und in eine Beispiel-Config oder?

Die Frage mMn wäre nur noch: sollte der Index die "nicht-lesenden" Adressen mitzählen oder eher nicht?

VG
Micha

[Chris M.]

Wenn man statt "%.4f °C" einfach einen Index benutzt kann man schon jetzt einen beliebigen Parameter adressieren: "%2$.4f °C" (2$ = 2. Parameter). Ein zusätzlicher Index Parameter bei den Adressen würde meiner Meinung nach die Sache nur verkomplizieren.

Der zusätzliche Parameter hätte halt den Vorteil universell zu sein und nicht mehr von der Reihenfolge der Address-Elemente abzuhängen.
Wir hatten z.B. früher auch nur die Adressierung der Seiten durch die ID - und die hängt von der Position ab. Wenn man dann eine Seite eingefügt hatte, war im Zweifel alles weiter unten kaputt.

@Chris M. kannst du mal bitte bei dir PR246 reverten und schauen ob deine Probleme durch meinen Fix auch behoben sind?

Vermutlich nicht, da ich das in einem anderen Zusammenhang hatte:
Ich bin gerade an einem Plugin dran, dass mehrere GAs braucht und die per "variant" unterscheidet, also ähnlich wie der colorchooser mit r/g/b. Hier gab es quasi das gleiche Problem.
Wenn man da ein "Mach-mich-Wert-1" setzen kann, wäre das gelöst.

Und, wir haben immer noch das Problem mit den hörenden GAs. Also wenn z.B. ein Switch auf mehrere GAs hören muss um auch ein Alles-Aus korrekt darstellen zu können. Das ist bei KNX absolut normal - würde aber beim Schreiben der GA-Werte in getrennte sprintf-Parameter eine korrekte Darstellung unmöglich machen.

Ein zusätzliches Attribut im Address-Element könnte das lösen (und implizit wird dafür immer 1 angenommen, wenn es nicht gesetzt ist, wegen der Abwärtskompatabilität). Aber evtl. gibt's ja noch bessere Lösungen?

Das funktioniert tatsächlich :-) Das sollte also noch entsprechend in die Doku und in eine Beispiel-Config oder?
[...]
Die Frage mMn wäre nur noch: sollte der Index die "nicht-lesenden" Adressen mitzählen oder eher nicht?

Lass uns erst mal die richtige Lösung finden und dann können wir die dokumentieren.

[Chris M.]

Im Pull-Request https://github.com/CometVisu/CometVisu/pull/281 habe ich nun ein zusätzliches, optionales Attribut "format-pos" im <address>-Element eingebaut. Setzt man dort eine Zahl, so wird diese GA an der entsprechenden Stelle für den Format-String übertragen.

So geht nun:

     <info format="1: %.2f">
        <label>Nur der erste</label>
        <address transform="DPT:9.001" mode="read">12/7/91</address>
        <address transform="DPT:9.001" format-pos="2" mode="read">12/7/92</address>
        <address transform="DPT:9.001" format-pos="3" mode="read">12/7/93</address>
      </info>
      <info format="2: %.2f %.2f %.2f">
        <label>Alle getrennt</label>
        <address transform="DPT:9.001" mode="read">12/7/91</address>
        <address transform="DPT:9.001" format-pos="2" mode="read">12/7/92</address>
        <address transform="DPT:9.001" format-pos="3" mode="read">12/7/93</address>
      </info>
      <info format="3: %.2f">
        <label>Alle auf einen</label>
        <address transform="DPT:9.001" mode="read">12/7/91</address>
        <address transform="DPT:9.001" mode="read">12/7/92</address>
        <address transform="DPT:9.001" mode="read">12/7/93</address>
      </info>

(Ich wüsste nicht, wie diese Flexibilität - wo jeder Fall seine Anwendung hat - ohne extra Parameter gehen würde)