CometVisu - (interner) Beta-Test

[Micha]

Das anders bezog sich darauf :

• DPT1.009 (DPT_OpenClose)
• 0 = Open
• 1 = Close

• DPT1.019 (DPT_Window_Door)
• 0 = closed
• 1 = open

und die daraus folgende mögliche Verwirrung

Für mich ist " 0 = gefahrloser Zustand " die einheitliche Regel beim Beschalten von Aktoren

[netzkind]

Wenn man sich mal Applikationen anschaut, ist es eigentlich anders :

Die "0" gesendet führt immer in einen gefahrlosen Grund-Zustand

- Tür, Fenster zu
- Rolladen, Jalousie hoch
- Licht, Antrieb u.a. AUS

Die "1" gesendet führt die Aktion aus, die aus dem Grundzustand in einen gewünschten Zustand wechselt

- Tür, Fenster auf
- Rolladen, Jalousie herunter
- Licht, Antrieb u.a. EIN

Das entspricht doch dem was ich geschrieben habe, oder?
0 = öffnen = Rolladen hoch-fahren
1 = schließen = Rolladen herunter-fahren

Oder ich steh auf dem Schlauch und versteh grade nicht worauf sich das "eigentlich anders" bezieht ...

Grüße,
Julian

[Micha]

Wenn man sich mal Applikationen anschaut, ist es eigentlich anders :

Die "0" gesendet führt immer in einen gefahrlosen Grund-Zustand

- Tür, Fenster zu
- Rolladen, Jalousie hoch
- Licht, Antrieb u.a. AUS

Die "1" gesendet führt die Aktion aus, die aus dem Grundzustand in einen gewünschten Zustand wechselt

- Tür, Fenster auf
- Rolladen, Jalousie herunter
- Licht, Antrieb u.a. EIN

So machen beide DPT Sinn, definieren also den Beginn einer Aktion und nach Beendigung der Aktion den Status des Objektes

Gruß Micha

[netzkind]

Hi,

Wenn ich im Standard mal nachsehe, dann gilt offiziell:

• DPT1.009 (DPT_OpenClose)
• 0 = Open
• 1 = Close

Also ist die Demo-Config-Datei, bzw. das OpenClose Mapping eigentlich falsch, das 0=zu und 1=offen setzt.

Andererseits könnte man auch DPT1.002 (DPT_Bool) verwenden und seine GA mit Dachfenster_Offen benennen, und da gilt:

• DPI1.002
• 0 = False
• 1 = True

Oder man ließt im Standard weiter, und findet den noch besseren Datentyp:

• DPT1.019 (DPT_Window_Door)
• 0 = closed
• 1 = open

So gesehen ist die Demo-Config-Datei wieder richtig...

mich verwirrt es auch regelmässig in der Visu, ist aber eigentlich ganz klar:
DPT1.009 sind Verben, also "öffnen" und "schließen"
DPT1.019 sind Zustände, also "geschlossen" und "offen"
Beide bilden das gleiche ab:
0 = Zustand: geschlossen, mögliche Aktion: öffnen
1 = Zustand: offen, mögliche Aktion: schließen

Die Frage ist was von beidem man in der Visu haben will: Zustand oder auszuführende Aktion? Das dürfte für INFO und SWITCH/TOGGLE unterschiedlich sein.

Grüße,
Julian

[netzkind]

Um mal kurz wieder ein Lebenszeichen zu geben:
ich bin leider nicht wie erwartet über Weihnachten zur Anpassung des Editors an den aktuellen SVN-Stand gekommen. Ich hab den Editor aber noch nicht aufgegeben, und hoffe da in den nächsten Tagen wieder etwas mehr zeitlichen Freiraum zu haben um dann auch das Einfügen multipler GAs pro Widget etc. umzusetzen.

Da der aktuelle Source aber im SVN liegt wäre ich niemandem böse der sich auch daran versuchen will. Dann bitte kurze Info, nicht dass da mehrgleisig Energie verwendet wird

Grüße,
Julian

[makki]

Ich hab in der /visu-svn/ Demo mal den Wasseralarm als CloseOpen eingetragen, letztlich reicht es das Mapping in der config einzutragen wie Chris schon schrub.. Wäre dann eher ein Feature für den Editor, einfach die Mappings und Styles zu bearbeiten/erweitern..

Andere Frage, DPT14: beim coding-style bin ich noch sehr wackelig:
ist ja ne rechte sauerei mit dem DPT14, ich hab eine kleine Klasse gefunden die man aber mittelfristig vermutlich an mehr Stellen als nur dem transform_knx brauchen kann.
Nur den Teil in transform_knx reinwuschteln oder separat das ganze Ding?
Würde es Sinn machen, für universellen Kleinkram eine allgemeine helper.js (die dann auch gleich compatibility.js enthielte) zu machen?
Es sollen ja möglichst wenig Files geladen werden..
Fertig isses je nachdem comitte ich das dann..

Makki

[Chris M.]

Meine Fensterkontakte als (dpt1.001) sind im geschlossenen Zustand "offen" und daher grün. In Wirklichkeit sind Sie aber "geschlossen" und sollten grün sein. (grün = geschlossen & rot = offen)

Wenn ich im Standard mal nachsehe, dann gilt offiziell:

• DPT1.009 (DPT_OpenClose)
• 0 = Open
• 1 = Close

Also ist die Demo-Config-Datei, bzw. das OpenClose Mapping eigentlich falsch, das 0=zu und 1=offen setzt.

Andererseits könnte man auch DPT1.002 (DPT_Bool) verwenden und seine GA mit Dachfenster_Offen benennen, und da gilt:

• DPI1.002
• 0 = False
• 1 = True

Oder man ließt im Standard weiter, und findet den noch besseren Datentyp:

• DPT1.019 (DPT_Window_Door)
• 0 = closed
• 1 = open

So gesehen ist die Demo-Config-Datei wieder richtig...

Da man zwar den DPT ziemlich frei wählen kann, kommt allerdings verschärfend hinzu, dass man ja diesen Wert durchaus als Sperrobjekt (für Rollladen, um sich nicht auszusperren) oder zur Sicherheit (Einfrierschutz bei Heizung) verwenden will und dort die Aktoren teilweise eine festgelegte Bedeutung von 0 und 1 verlangen.

=> Egal was jetzt offiziell richtig ist, es muss funktionieren. Ändere daher einfach das Mapping in der Config-Datei, so wie Du es brauchst.
So wie es ein RedGreen und ein GreenRed gibt, kannst Du natürlich zum OpenClose noch ein CloseOpen hinzufügen

Wäre nicht eine checkbox zur Invertierung der Darstellung sinnvoll?

Ne, das macht keinen Sinn - genau dafür ist das Mapping da.

=> Evtl. könnte das auch im "mapping" hinzugefügt werden.
(OpenClose und CloseOpen)

Das ist die richtige Lösung, s.o. - aber das ist etwas für Deine Config-Datei.
Leider kann der eingebaute Editor diese Einträge nicht ändern, aber mit einem beliebigen Text-Editor kannst Du natürlich selber die Config-Datei anpassen. (Wir sind hier im internen Beta-Test, da können wir das von den Anwendern locker erwarten )

Hallo Chris,
bin neu in Forum und sehr begeistert was bei Euch so los ist....

Habe am Wochenende die Cometvisu aufegsetzt und einmal Übersichten zu Fensterkontakten und Temperaturen erstellt. Soweit erstmal sehr schick!


Frage bzgl. dem "info" widget.

Meine Fensterkontakte als (dpt1.001) sind im geschlossenen Zustand "offen" und daher grün. In Wirklichkeit sind Sie aber "geschlossen" und sollten grün sein. (grün = geschlossen & rot = offen)

Wäre nicht eine checkbox zur Invertierung der Darstellung sinnvoll?
=> Evtl. könnte das auch im "mapping" hinzugefügt werden.
(OpenClose und CloseOpen)
=> sowie im styling:
(RedGreen und GreenRed)

Gruß Tim

[Chris M.]

Trotzdem sendet er noch, direkt beim laden,

Das Initialisieren ist noch nicht optimiert.

Eigentlich sollten alle internen Zustände abgefragt werden und erst dann das Widget aktiv werden. Aktuell scheren die sich einen feuchten Kehricht darum, ob sie initialisiert wurden - wenn der neue Wert (der die Initialisierung sein kann) ungleich dem internen ist, wird der neue geschickt.
Das ist zwar nicht perfekt, aber in 99% der Fälle ausreichend.

Ich mach mal ein Bug-Report.

Komisch, ist immer genau eins weniger, ich würde nicht ausschliessen (bzw. halte ich das sicher für die Ursache) das das an unterschiedlichen Umrechnungen des DPT5 - gerne auch im Backend liegt.

Die SVN Version nutzt keine Umrechnung im Backend mehr. D.h. wenn, dann ist da ein Fehler in transform_knx.js - dem übrigens noch ein Encode für DPT 14 fehlt... (In der Datei dürfen sich auch lieben gerne andere verewigen und neue DPTs hinzufügen!)

Trotzdem denke ich, schreiben sollte jegliches Widget nur wenn es beklickt wurde, egal was der Bus sagt, gesagt hat oder sagen wird

Das ist grundsätzlich richtig - aber nicht immer leicht umzusetzen.

[makki]

Im Code war doch klar ersichtlich, dass der Slider kein Readonly kennt... )

Deswegen dachte klein doofy: das wird wohl hier woanders stehen
Das scheint jetzt jedenfalls zu passen. Damit ist auch das vormals angemerkte gezappel des Sliders weg..

Außerdem wird jetzt die zu sendenden Variablen verglichen

Trotzdem sendet er noch, direkt beim laden, gleich nach dem empfangen eines Wertes (r?1/6/2=>B4 -> w?1/6/2=B3) usw.

Komisch, ist immer genau eins weniger, ich würde nicht ausschliessen (bzw. halte ich das sicher für die Ursache) das das an unterschiedlichen Umrechnungen des DPT5 - gerne auch im Backend liegt.
Trotzdem denke ich, schreiben sollte jegliches Widget nur wenn es beklickt wurde, egal was der Bus sagt, gesagt hat oder sagen wird

Makki

[Chris M.]

Ja mit beide meine ich die zweite, Statusrückmeldeadresse mit readonly="true"

Bug ist jetzt gefixt (eigentlich war's nur ein fehlendes Feature. Im Code war doch klar ersichtlich, dass der Slider kein Readonly kennt... )

Dürfte ja aber auch garnicht schreiben, solange ich lokal den slider nicht anfasse -> in der /visu-svn/ (welche aktueller Stand ist) sollte man das sehen..

Außerdem wird jetzt die zu sendenden Variablen verglichen (und nicht nur die interne Representation) um vermeintliches doppeltes Senden zu verhindern. (Wenn 0.8 als 0x81 und 0.9 als 0x81 gesendet worden wäre, dann hätte eine Slider-Änderung von 0.8 auf 0.9 einen Wert gesendet - jetzt nicht mehr)

Schau mal, ob's jetzt besser ist.

[makki]

Ja mit beide meine ich die zweite, Statusrückmeldeadresse mit readonly="true"
Dürfte ja aber auch garnicht schreiben, solange ich lokal den slider nicht anfasse -> in der /visu-svn/ (welche aktueller Stand ist) sollte man das sehen..

Makki

[Chris M.]

Die Slider schreibt zwischendurch immer wieder beim Empfang einer Wertänderung auf beide Adressen zurück die aktuellen Werte (oder ich hab irgendwas in der config falsch)

Hm, was meinst Du mit "beide Adressen"?

Schreibt Dein Slider auf mehrere Adressen gleichzeitig (was die CometVisu - im Gegensatz zu normalen KNX Geräten - kann)?
Oder hast Du gleichzeitig eine hörende Adresse mit angelegt?? (Dabei im <address> Element das readonly="true" auch nicht vergessen?)

[makki]

Der colorchooser alleine fühlt sich jetzt gut an, aber jetzt weiss ich wo das Problem herkommt: Die Slider schreibt zwischendurch immer wieder beim Empfang einer Wertänderung auf beide Adressen zurück die aktuellen Werte (oder ich hab irgendwas in der config falsch)

Makki

[Chris M.]

Der colorChooser hat z.Zt. noch keine Telegrammraten-Begrenzung drinnen

Im aktuellsten SVN ist's jetzt drinnen - bitte mal testen