Bug: CometVisu vergisst manchmal Status

[JNK]

Browsercache.

Gruß,

der Jan

[MicHau]

Seit Rev 759 (22.04.2012) heisst es

mode="readonly"
mode="writeonly"
mode="readwrite"

wobei "readwrite" der Standard ist.

Hierüber bin ich gerade gestern gestolpert und hätte eine kleine Verbesserung der XSD-Datei (visu-config.xsd) beizusteuern, um die erlaubten Einträge für "mode" kenntlich zu machen.
In Zeile 72

  <xsd:attribute name="mode" type="xsd:string" />

ersetzen durch

  <xsd:attribute name="mode">
    <xsd:simpleType>
        <xsd:restriction base="xsd:string">
          <xsd:enumeration value="disable" />
          <xsd:enumeration value="read" />
          <xsd:enumeration value="write" />
          <xsd:enumeration value="readwrite" />
        </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>

Da ich nur lesend auf SVN zugreifen kann, hoffe ich, dass es hier jemand aufgreift und einfließen lässt. Beiliegend die Patch-Datei.

[larsknx]

Also ich habs gerade bei mir genau so probiert, (mit anderen GA): das funktioniert einwandfrei. Das r sieht auch ganz ok aus, für den Status wird ja eine 0 geliefert, dass die writeonly mit abgefragt wird, sollte eigentlich keine Rolle spielen.

Cache gelöscht?

Gruss,

der Jan

Danke Dir Jan, aber bei mir gehts leider trotz Löschen des Browsercaches nicht, hab ebenfalls Opera ganz neu installiert, dort wird ebenfalls der Slider auf einer falschen Position angezeigt.

Wie gesagt, der Status wird mit 0 richtig in der read-Abfrage ausgelesen, er wird aber beim Status für die Position des Sliders nicht berücksichtigt, sondern der writeonly Wert für GA 2/6/134

Ich finds trotzdem komisch, das betrifft alle Lampen mit Dimmfunktion bei mir.
<slide min="0" max="85" >
<label><icon name="licht_regelung" />Dimmen Decke</label>
<address transform="DPT:5.001" mode="writeonly" variant="">2/6/134</address>
<address transform="DPT:5.001" mode="readonly" variant="">2/4/134</address>
</slide>

Und es ging wie gesagt zwischenzeitlich bei mir.

Kann man das nicht trotzdem so programmieren, dass er bei der readabfrage writeonly GA's einfach gar nicht ausliest, das wäre doch auch für Performance und Ladezeiten viel besser, denn den writeonly Wert für die GA's brauchen wir doch bei der cgi-bin/r?....... Abfrage überhaupt nicht ?

Hab gerade in Revision 744 mal das writeonly beim Slider nachgerüstet. (Allerdings nur kurz auf allgemeine Funktion getestet)

Und ganz sicher, dass Chris Änderungen auch in den SVN Version eingeflossen sind ?

[JNK]

Mein Fehler, es heisst nicht readonly, writeonly sondern:

read
write
readwrite
disable

Sorry.

Gruss,

der Jan

[JNK]

Hierüber bin ich gerade gestern gestolpert und hätte eine kleine Verbesserung der XSD-Datei (visu-config.xsd) beizusteuern, um die erlaubten Einträge für "mode" kenntlich zu machen.

Rev. 1023:

Patch by MicHau to better check mode-attributes in address-elements

[larsknx]

Mein Fehler, es heisst nicht readonly, writeonly sondern:

read
write
readwrite
disable

Sorry.

Gruss,

der Jan

Danke dir, aber es bleibt trotzdem dabei. Ich denke, man kann mir hier nur helfen, wenn write(only) Adressen einfach nicht in die Readabfrage reinkommen.

Es bleibt dabei, nach jedem Refresh hat er für die Adresse 2/6/136":"3A" einen Wert, der anscheinend für den Status der Sliderstellung mitberücksichtig wird.

Denn der Status des Dimmwertes für den Slider ist nach jedem Refresh richtig und korrekt "2/4/136":"00" . Nur Leider wird anscheinend für die Position des Sliders nicht der Wert von der Status GA herangezogen, sondern von der 2/6/136 für den absuluten Dimmwert.

Nochmal: wenns nach mir geht, bitte GA, die nur für write deklariert sind, bitte aus der Read Abfrage rausnehmen.


Wenn ich den Slider manuell wieder auf den Wert 0 schiebe , ist alles korrekt, auch nach einem Reload. Ist ja auch klar, denn dann wird für die GA 2/6/136 der Wert auch auf wirklich auf 0 gesetzt.


Refreshe ich jetzt die Seite,

[JNK]

<switch mapping="m_anaus" styling="s_greenred">
  <label>Esstisch</label>
  <address transform="DPT:1.001" variant="">1/0/152</address>
  <address transform="DPT:1.001" mode="read" variant="">1/6/152</address>
  <layout colspan="3" />
</switch>
  <slide>
    <address transform="DPT:5.001" mode="write" variant="">1/2/152</address>
    <address transform="DPT:5.001" mode="read" variant="">1/7/152</address>
    <layout colspan="5" />
 </slide>

1/7/152 ist dabei der Status, 1/2/152 die Dimmen-Absolut-GA.

Also so sieht das bei mir aus, und die aktuelle SVN Version reagiert bei mir im Iceweasel(=Firefox) und Chrome exakt so, wie sie soll. Ich habs mir auch im Debugger angeguckt, Update wird definitiv nur aufgerufen für die als "read" definierte Adresse. Ich habe in den Code geguckt, das sieht alles richtig aus.

Ich würde vorschlagen, Du sicherst Deine visu_config.xml (und evtl. die custom-Dateien für Design und widgets, wenn Du da was geändert hast) und danach das komplette Verzeichnis löscht und aus dem SVN neu installierst. Ich kann mir nur vorstellen, dass beim Update irgendwas nicht richtig übernommen wurde.

Gruss,

der Jan

[larsknx]

Der Tip war Gold wert. Ich hatte definitiv Revision 1023 installiert. Es ging einfach nicht. Dann Ordner gesichert, gelöscht, mit

svn co https://openautomation.svn.sourcefor...ometVisu/trunk visu_svn

ganz neu installiert, config rübergebügelt, siehe da, es funktioniert . Hurra !

Sorry, dass ich hier so viele Mühen gemacht habe, aber da wäre ich nie drauf gekommen.

Eine Frage habe ich noch

 <switch mapping="m_anaus" styling="s_greenred">
  <label>Esstisch</label>
  <address transform="DPT:1.001" variant="">1/0/152</address>
  <address transform="DPT:1.001" mode="read" variant="">1/6/152</address>
  <layout colspan="3" />
</switch>

Ist das Absicht, dass bei

<address transform="DPT:1.001" variant="">1/0/152</address>

kein Mod steht bzw. wenn nichtts da steht, heisst es ja readwrite, aber hier würde doch auch nur write ausreichen , oder ?



Danke dir ganz .-)))))++


Gruß Lars

[JNK]

Gern geschehen. Dann bitte Haken dran, damits nicht so aussieht als ob die CV voller Bugs wäre.

Gruss,

der Jan

[makki]

Gern geschehen. Dann bitte Haken dran, damits nicht so aussieht als ob die CV voller Bugs wäre.

Danke Jan, das kaast mich eh ein bisschen an, das es gefühlt manchmal so aussieht als würde nix gehen - obwohl 99% funktionieren, wo andere Visus nichtmal 50% der DPT's richtig verarbeiten können aber dank "hippem Look" dann auf den ersten Blick mehr "likes" bekommen

Makki

[greentux]

Das liegt schlicht daran, das "hipper look" eben auch eine Anforderungen der Anwender ist. Das kann man ignorieren, klar.

Man sieht ja sehr schön, wie groß der "Ansturm" seit "metal" geworden ist. Da versuchen selbst non-linux-gurus sich an der Installation, die finden das einfach "hip".

Mit nem Release könnte man vermutlich sogar Marktanteile holen mittlerweile... Der fehlende Editor fällt interessanterweise nicht so auf. Vermutlich nehmen die Leutz das in Kauf, mal eben nen XML Editor anzuwerfen und dafür ne hippe Visu zu erhalten.

[larsknx]

jetzt schlagt micht nicht, aber ich kann kein haken setzen ? das kann doch nur der threadersteller oder ?