Bug: CometVisu vergisst manchmal Status

[Chris M.]

In Revision 637 ist jetzt mal für das switch-Widget das writeonly-Attribut implementiert.

=> Wenn die o.g. Config geändert wird in:

    <info>
      <label>Zentral</label>
      <address transform="DPT:1.001" readonly="false" variant="">12/0/0</address>
    </info>
    <info>
      <label>Schalten</label>
      <address transform="DPT:1.001" readonly="false" variant="">12/0/2</address>
    </info>
    <info>
      <label>Rückmeldung</label>
      <address transform="DPT:1.001" readonly="false" variant="">12/0/1</address>
    </info>
    <line/>
    <switch>
      <label>Zentral</label>
      <address transform="DPT:1.001" readonly="false" variant="">12/0/0</address>
    </switch>
    <switch>
      <label>Schalten</label>
      <address transform="DPT:1.001" readonly="true" variant="">12/0/1</address>
      <address transform="DPT:1.001" readonly="false" [B]writeonly="true"[/B] variant="">12/0/2</address>
    </switch>

sollte IMHO der Bug behoben sein.

Sehen andere das auch als Lösung?

Und wenn ja: sollte man dann die Config-Syntax nicht ändern von readonly="true/false" writeonly="true/false" in ein andere Attribut access="read/write/readwrite" (oder r/w/rw; und/oder anderer Name für's Attribut)

[Chris M.]

Genau das ist das Problem. Fraglich ist, ob so ein Switch genau eine GA haben sollte und alles andere doch in Logik gemacht werden müsste? Die alte Frage, wo hört Visu auf und wo fängt Logik an

Das Beispiel oben hat noch keinerlei Logik in der Visu. Das ist normales Verknüpfen von KNX um eine n:m Beziehung realisieren zu können...

Mein Lösungsansatz wäre neben dem "readonly"-Attribut auch noch ein "writeonly" zu haben.

Mögliche Lösungsansätze nach Makki wären:

1. writeonly für alles außer die designierte Rückmeldeadresse (die auch gleich Schaltadresse sein kann aber nicht muss) in der CV kann eine gute Lösung sein
2. der Dampfhammer, nicht einfach aber evtl. intuitiver und sauberer:
   - erst mal die eibd-API pimpen, das man an das age (c->recvtime) ran kommt
   -> das age mitsenden (zumindest beim initialen-read)
   -> in der CV entscheiden welcher Status aller nicht writeonly-GA's der jüngste ist und diesen verwenden
3. anders am Cache drehen (clear oder Max-Age bei der Abfrage angeben), aber auch dafür muss man wissen was Schalt-, Status- und Zentraladresse ist.

Wobei er 1+2 präferiert.

=> Ich denke ich werde mal was Richtung writeonly implementieren.
Und wenn das Backend in Zukunft irgendwann den Cache-Read nach Alter sortiert ausgibt, um so besser

[greentux]

Genau das ist das Problem. Fraglich ist, ob so ein Switch genau eine GA haben sollte und alles andere doch in Logik gemacht werden müsste? Die alte Frage, wo hört Visu auf und wo fängt Logik an

Ggf. bräuchte man ein "Ober sticht unter" - Attribut. irgendwie ist es ja da (der letzte sticht). Aber schöner wäre besser

[Chris M.]

Fehlerlokalisierung

Den Fehler konnte ich jetzt sauber und einfach reproduzieren. Man nehme:

• Schaltaktorkanal
  • GA 12/0/0 auf "Zentral An/Aus"
  • GA 12/0/1 auf "Statusrückmeldung An/Aus"
  • GA 12/0/2 auf "Schalten An/Aus"
  
  
• CometVisu Config:
  

      <info>
        <label>Zentral</label>
        <address transform="DPT:1.001" readonly="false" variant="">12/0/0</address>
      </info>
      <info>
        <label>Schalten</label>
        <address transform="DPT:1.001" readonly="false" variant="">12/0/2</address>
      </info>
      <info>
        <label>Rückmeldung</label>
        <address transform="DPT:1.001" readonly="false" variant="">12/0/1</address>
      </info>
      <line/>
      <switch>
        <label>Zentral</label>
        <address transform="DPT:1.001" readonly="false" variant="">12/0/0</address>
      </switch>
      <switch>
        <label>Schalten</label>
        <address transform="DPT:1.001" readonly="true" variant="">12/0/1</address>
        <address transform="DPT:1.001" readonly="false" variant="">12/0/2</address>
      </switch>

=> Mit dem rechen Switch schaltet man den Kanal ganz klassisch
=> Mit dem linken Switch kann man per Zetral An bzw. Aus schalten - und der rechte Switch wird (dank Rückmeldung) auch auf den richtigen Status gebracht.

Also eigentlich alles i.O. - oder?

Nun schaltet man mal mit rechts auf einen Status, dann mit links auf einen anderen. Rechts zeigt nun den richtigen Status an - aber nach einem Reload der Seite nicht mehr, dann ist der rechts falsch.

(Ursache: beim Laden der Seite werden alle GAs aus dem Cache abgerufen. Aber die Werte für den rechten Switch widersprechen sich - und der falsche (genauer: veraltete) kommt nach dem richtigen und überschreibt diesen)

[greentux]

Tja, dann vl. doch nicht auf alles hören, sondern aktive Status Messages... Dann sollte das nicht passieren?

[Chris M.]

Das kann schon zusammenhängen. Meine Visu läuft auf einem Notebook, was durchaus suspendiert. Genau dann hat man ja den Fall.
Ich kanns nur nicht reproduzieren.

Reproduzierbar ohne Suspend sollte ein Reload (z.B. per "F5") sein, am besten gemeinsam mit einem Check der Werte im Cache. D.h. bei Dir in einer Shell auf dem WireGate ausführen von

groupcacheread local:/tmp/eib 3/1/0

und

groupcacheread local:/tmp/eib 3/7/10

Wenn nun beide Befehle was anderes sagen => Volltreffer

[Chris M.]

Danke für die Links - damals war genau das Problem, dass man's nicht direkt reproduzieren kann. Aber evtl. können wie die Lösung dann dagegen verifizieren

Bei mir bin ich nun schon einen Schritt weiter und evtl. ist Dein Setup https://knx-user-forum.de/176306-post972.html da sehr ähnlich:

Das Problem bei mir scheint doch nicht der Cache zu sein - sondern eine Diskrepanz im Chache zwischen den beiden Werten auf die das Widget hört.
D.h. bei

<switch mapping="InvAutoOff" styling="InvRedGreen">
 <address transform="DPT:1.001" readonly="false">3/1/0</address>
 <address transform="DPT:1.001" readonly="true">3/7/10</address>
</switch>

wären im Chache für 3/1/0 und 3/7/10 unterschiedliche Werte gespeichert.

Wenn nun ein Reload alle Werte neu lädt (Bugy-Verhalten das gerade behoben wurde oder aber auch bei normalen (Re)load der Visu, z.B. per F5) dann gewinnt der Wert der GA die später kommt. Auch wenn's "falsch" ist.

=> Das ist dann doch kein Fehler der CometVisu und/oder des Backends und/oder des eibd - sondern der Programmierung des KNX-Systemes (wo auch immer...).

[greentux]

Das kann schon zusammenhängen. Meine Visu läuft auf einem Notebook, was durchaus suspendiert. Genau dann hat man ja den Fall.
Ich kanns nur nicht reproduzieren.

[Chris M.]

Bug: CometVisu vergisst manchmal Status

Auftrennung des Threads https://knx-user-forum.de/cometvisu/...t-timeout.html um beide Bugs genauer trennen zu können.

[greentux]

https://knx-user-forum.de/wiregate-b...oup-cache.html

Das war von einem dritten User mit Referenz auf mein Posting...

[Chris M.]

Das A und O beim Fehler finden ist das Reproduzieren und möglichst auch isolieren um ohne Rauschen drauf schaun zu können.

Bei meinem Setup ist mir jetzt zumindest ersteres gelungen und zweiteres vermutlich leicht möglich.

=> Jetzt können wir's angehen.

Hast Du einen Link auf das Posting von damals, damit wir mehr Infos beim Suchen haben?

[greentux]

Das mit dem kaputten Cache hatte ich schon mal vor Monaten erwähnt. Damals wurde allerdings gesagt, das das nicht sein kann. Na schön, wenns noch jemand beobachtet hat.