Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

[callidomus]

Hallo,

DPT 5.001 hat tatsächliche ein Auflösung von 0,4 %. Die Prozent (bei der Auflösung) sind hier aber nur als Einheit zu sehen, die sich nicht auf den Wert sondern auf die generellen Wertebereich von 0-100% bezieht.
Daher kann auf eine Nachkommastelle gerundet werden.
Ist in develop für 5 und 5.001 umgesetzt.

EDIT: diese komischen Werte kommen von Fließkomma-Arithmetik. Das ist ein gängiges Programmierproblem wenn man Fließkommanzahlen kodiert bzw. dekodiert.

Bis bald

Marcus

[greentux]

Bei 9 ging es mir um 9.001, der ja schon gefixt ist:
9.001 DPT_Value_Temp 0,01 °C

Wunsch wäre, das da max 2 Nachkommastellen ankämen oder?
Wie gesagt, ich sehe halt im RRD scheinbare Genauigkeit Zu lösen wäre es an verschiedenen Stellen, deshalb habe ich ja alle mal angeschaut.

Vl. wärs auch ne Lösung, jedem Item die Anzahl Nachkommstellen mitzugeben (geht heute schon via eval denke ich).

[Robert]

Quelle
http://www.knx.org/fileadmin/downloa...07.00%20AS.zip

Dort bei 5.001 Resolution. Ebenso bei DPT9 Resolution. (das scheint ja schon gefixt).

Seite 26 in DEINEM Dokument gelesen?

5.001
DPT_Scaling
[0…100]
%
≈ 0,4 %
PDT_SCALING (alt.: PDT_UNISIGNED_CHAR)
G

gleiches Seite 33, DPT 9.007 - 0,01%, also 0,0001.

Um bei 5.001 zu bleiben: Was genau wäre jetzt dein Wunschverhalten? Die Resolution ist halt nicht exakt 0,4% - sondern 0,39xxx% - ergo ist der korrekt umgerechnete Wert nach Vorschrift doch auch nicht in Mehrfache von 0,4% zu quetschen. Ich sehe daher an dieser Stelle ein Runden als Fehler an! Und selbst wenn, dann doch nicht auf 0,01 (also ganze %) sondern 0,1%?

[greentux]

Quelle
http://www.knx.org/fileadmin/downloa...07.00%20AS.zip

Dort bei 5.001 Resolution. Ebenso bei DPT9 Resolution. (das scheint ja schon gefixt).

[Robert]

DPT5.001 ist definiert mit einer Auflösung von 0,01
Das sieht mir auf dem Bus auch noch so aus. Im sh.py halt dann leider nicht mehr.
Auch bei den Temperaturen (DPT9) habe ich manchmal mehr Stellen, als die defnierte Resolution von 0,01

Warum braucht man denn da dann ein Round?
Wo kommen die "Mehrstellen" denn her?

Gruß

Wo "definiert"? Quelle?

Wenn 0-100% mit 256 Stufen aufgelöst werden beträgt die Auslösung halt ca. 0,4% (oder eben 0,004). Sieht auch Tapko so: Tools - Tapko

Und bei einem 2 Byte breiten Datenpunkt (DPT 9) wäre das noch trauriger.

[greentux]

DPT5.001 ist definiert mit einer Auflösung von 0,01
Das sieht mir auf dem Bus auch noch so aus. Im sh.py halt dann leider nicht mehr.
Auch bei den Temperaturen (DPT9) habe ich manchmal mehr Stellen, als die defnierte Resolution von 0,01

Warum braucht man denn da dann ein Round?
Wo kommen die "Mehrstellen" denn her?

Gruß

[JuMi2006]

Ich denke Du willst sowas:
https://github.com/mknx/smarthome/co...0a2fd581d11219

Ich hatte das damals beim DPT9 irgendwo hier gemeldet.

[Robert]

Neee, das Originalproblem war die Inkonsistenz der Umwandlungen. Wenn ein DPT5 in den Wert gewandelt wurde, und dieser dann wieder in DPT5 gewandelt wurde kam ein anderer Wert raus. Das wiederholte sich dann beliebig oft. Zusammen mit dem Damals vorhandenen Echo auf dem KNX-Bus gabs dann Gemüse. Das ist alles behoben.

Bei dir sehe ich gar keinen Fehler? Vielleicht solltest du zumindest deine Erwartung beschreiben? Einzig falls die Werte zusammengehören sieht die Rundung etwas seltsam aus. Ansonsten ist doch alles ok?

[greentux]

Auch wenn der Thread komplett aus dem Titel Ruder gelaufen, ich hoffe, es gehört hier her:

Ich habe derzeit folgende Werte:

sensor.bad.temp = 23.5
sensor.bad.hum = 52.94117647058823

Aus folgender Config:

      [[bad]]
        [[[temp]]]
            visu_acl = rw
            type = num
            knx_dpt = 9
            knx_listen = 3/2/71
            sqlite = yes
        [[[hum]]]
            visu_acl = rw
            type = num
            knx_dpt = 5.001
            knx_listen = 3/2/72
            sqlite = yes

Der hum Wert hat mir definitiv zu viele Nachkommastellen für DPT5.001
Gehört das zum hier besprochenen Problem?

Im Log steht zu der Zeit:

2013-12-09 22:40:47,959 DEBUG    Main         knx: 0.0.0 set 3/2/72 to 52.15686274509804 -- __init__.py:parse_telegram:190
2013-12-09 22:40:47,964 DEBUG    Main         Item sensor.bad.hum = 52.15686274509804 via KNX 0.0.0 3/2/72 -- item.py:__update:363

Über den KNX läuft zu der Zeit:

2013-12-09 22:37:53.133,A_GroupValue_Write,0.0.0,3/2/72,85,52.2,DPT_Scaling,5.001,0,low,7,T_DATA_XXX_REQ,0

[marsellus]

Hi,

ich muss Niko an dieser Stelle zustimmen und werde es bis auf Weiteres auch so machen müssen, dass ich nach einem Update die Zeile "if caller != 'KNX'" wieder reinnehme.

Das Argument von Marcus, dass sh sich wie ein Aktor verhalten soll kann ich nachvollziehen...ist aber technisch so nicht umgesetzt. Ein Aktor übermittelt seinen tatsächlichen Schaltzustand - nachdem er einen "Änderungswunsch" erhalten hat. Sh macht einfach einen "Autoreply" ohne dass das den tatsächlichen Schaltzustand des "Sh-Aktors" unbedingt widerspiegeln muss.
Ein regulärer Aktor erlaubt es den Schaltzustand und Status zu trennen. Sh mischt diese wieder zusammen über knx_listen und knx_send, was ja durchaus sinnvoll ist und ich auch für die SmartVisu benötige. Die Items in sh sind für mich eher die Schnittstelle(ndefinition) zu den technischen Komponenten, die möglichst wenig Eigenleben haben sollte.

Für mich ist sh in erster Linie ein Integrationssystem zwischen den Welten, wo ein Forwarden von Informationen zwischen den Welten gewollt/erwünscht ist und über die Items einfach konfiguriert werden kann. Soll sh ein aktives Verhalten á la KNX-Aktor haben, würde ich das gern explizit über Logiken machen wollen.

Einen Anwendungsfall, wo ich das benötige, habe ich mit meiner Tag-Nach-Umschaltung die sowohl über KNX-Taster, die Visu und zeitgesteuert erfolgen kann. Dafür habe ich mir jetzt aber genau EINE Logik geschrieben die Änderungen für ein Item auf knx_listen via knx_send (auf eine andere GA) weiterleitet. Bei Bedarf hänge ich an das watch_item der Logik einfach weitere Items an. Die Logik liest dann für das betreffende Item einfach die knx_send-GA aus und schickt den Wert weiter.

Hier kann aufgehört werden zu lesen, ich beschreibe einfach mal kurz warum "if caller != 'KNX'" bei mir nicht funktioniert:
Ich habe eine Tag-Nacht-Umschaltung bei der Nachts die Beleuchtung in Bädern und Dielen reduziert wird. In sh habe ich ein Item das die GA des Schaltzustand des Dimmaktors (Ein/Aus) mit der GA für das Schalten des Dimmers verbindet. Brauche ich so für die SmartVisu und ist ja eigentlich auch so gewollt.
Das ist dann der Ablauf:
-> PM im Bad sendet Nachts 30% auf den Bus an die entsprechende Dimm-GA
-> Dimmer geht auf 30%
-> Dimmer sendet auf die Schaltzustand-GA (die ich auch in sh verwende) ein "EIN"
-> Dimmer sendet auf eine andere Status-GA seinen Dimmwert
-> Sh registriert die Änderung auf der Schaltzustand-GA (="EIN")
-> Sh macht ein "Autoreply" mit Wert "EIN" an die Schalt-GA des Dimmers
-> Dimmer schaltet die Beleuchtung daraufhin auf 100%

Das Autoreply des "EIN" auf die Schalt-GA des Dimmers ist an dieser Stelle eben nicht das gewünschte/erwartete Verhalten.


/Marcel

[2ndsky]

man braucht das wenn man SH.py als KNX-Aktor betrachtet und den Zustand zuätzlich z.B. die Visu ändert.

Also wenn ich quasi über KNX das Item setzen möchte und im KNX erfahren möchte, ob der Wert tatsächlich gesetzt wurde? Am Beispiel Russound, es gibt eine GA zum Einschalten einer Zone und eine GA die mir den Status der Zone mitteilt. Verstanden.

Allerdings ist der Anwendungsfall so nicht abzubilden. Denn das einzige was ich durch die Antwort weiß, dass sh.py den Wert empfangen hat und somit ob sh.py läuft. Ob sh.py es tatsächlich geschafft hat, die Zone zu aktivieren oder ob es Fehler bei der Kommunikation mit dem Russound gab weiß ich dann ja wieder nicht.

Um das dann tatsächlich abbilden zu können bräuchte man schon etwas das ein klein wenig mächtiger ist. Damit sh.py den Status eines Items nur dann ändert, wenn andere angebundene Plugins diese Änderung auch durchsetzen konnten.

[callidomus]

Hi Niko,

Wie gesagt, ich versteh nicht warum ihr das braucht... ich brauch es nicht und ich finde auch keinen Anwendungsfall. Bisher hat es bei mir reibungslos funktioniert, mit der Änderung habe ich Probleme bei meiner Installation. Wenn wir keine gute Lösung dafür finden, werde ich bei mir nach jedem Update das Statement einfach wieder einbauen und gut ist. Für mich zwar keine optimale Lösung (da ich denn Sinn nicht sehe), aber dann ist es halt so.

man braucht das wenn man SH.py als KNX-Aktor betrachtet und den Zustand zuätzlich z.B. die Visu ändert.
Wir werden aber eine Lösung finden die Deinen und den anderen gerecht wird.

Bis bald

Marcus

[2ndsky]

Nur so ist es ja auch möglich, z.B. ein Plugin (z.B. Onewire) das Plugin updaten zu lassen und es dann "automatisch" über das KNX-send_item raussenden zu lassen. Wie soll jetzt sh.py unterscheiden, ob das send_item bei einem Item-Update aktualisiert werden soll oder nicht?

Da kann ich dir jetzt nicht folgen. Wenn man die Quelle der Änderung prüft (caller != KNX), dann kann ich über 1Wire geänderte Werte doch auf den KNX schreiben, weil der Aufrufer ist dann ja nicht KNX.

Die Abfrage auf "knx" ist zu KNX-zentriert und führt zwangsweise ins Nirvana wenn man sh.py als Technologie-agnostische Logikengine positionieren will.

Da kann ich dir nicht folgen. Kannst du mir das bitte im Detail erklären, warum das zu Problemen führt, am besten mit Beispiel. Wenn ich verstehe, warum ihr das unbedingt braucht, vielleicht kann ich mich dann auch besser an einer Lösung des Problems beteiligen.

Möglich wäre also nur, eine Spiegelung generell zu verhindern, also nie auf das caller-Medium zurückzuschreiben. Aber auch das wäre ggfl. für Umrechnungen etc fatal.

Aber das würde caller != KNX doch machen, eine Spiegelung auf das Empfangsmedium verhindern, oder? Wenn nein, bitte Erklärung. Und warum wäre das für Umrechnungen fatal?

Die Zusammenführung zweier GAs (Vorgabe und Status) gibt irgendwo ja auch den Sinn eben dieser Trennung auf. Dann könnte man auch vielfach bereits im KNX eine GA für beides verwenden - mit allen Nachteilen.

Okay, dann soll ich quasi ein Item für Status und eins für das Senden definieren, richtig? Dann brauchen wir diese Trennung aber auch in der smartVISU. Wie soll ich sonst in der Visu den Status meiner Lampe getrennt von einer Wertänderung in der Visu machen?

Mit der bisherigen Abfrage caller != KNX hat das alles bestens und einwandfrei funktioniert.

Eine richtig gute Lösung weiß ich auch nicht - allerdings denke ich, dass oben geschriebener Grundsatz halt immer zwangsweise gelten sollte und eben auch von sh.py sichergestellt werden sollte (notfalls eben per GA-write).

Evtl. könnte man ein "lazy-update" Attribut einführen (default = False!), was das Schreiben für gleiche Technologien (Plugins) verhindert. Allerdings wird dann auch z.B. von Visu auf Visu verhindert... Da bohrt man sich schnell logische Löcher...

Wie gesagt, ich versteh nicht warum ihr das braucht... ich brauch es nicht und ich finde auch keinen Anwendungsfall. Bisher hat es bei mir reibungslos funktioniert, mit der Änderung habe ich Probleme bei meiner Installation. Wenn wir keine gute Lösung dafür finden, werde ich bei mir nach jedem Update das Statement einfach wieder einbauen und gut ist. Für mich zwar keine optimale Lösung (da ich denn Sinn nicht sehe), aber dann ist es halt so.

[Robert]

@Marcus: wenn ihr das verhalten so haben möchtet, das über den Bus empfangene Werte auch wieder auf den Bus gesendet werden, dann brauchen wir separate Attribute.

Was mir allerdings nicht klar ist, wozu ihr das braucht. Wenn ich am Russound die Lautstärke per App auf 20 setze, sh.py den Wert vom Russound empfängt, dann braucht sh.py die Lautstärke ja nicht nochmal auf 20 setzen... die ist ja schon 20. Bei KNX sehe ich das genauso. Wozu also dieses Verhalten?

Hi Niko,

ich kann mal versuchen meine Sicht zu erklären:

Ein Item - ein Wert - egal woher dieser kommt (KNX, Onewire, Plugin x, ...)

Nur so ist es ja auch möglich, z.B. ein Plugin (z.B. Onewire) das Plugin updaten zu lassen und es dann "automatisch" über das KNX-send_item raussenden zu lassen. Wie soll jetzt sh.py unterscheiden, ob das send_item bei einem Item-Update aktualisiert werden soll oder nicht? Die Abfrage auf "knx" ist zu KNX-zentriert und führt zwangsweise ins Nirvana wenn man sh.py als Technologie-agnostische Logikengine positionieren will. Möglich wäre also nur, eine Spiegelung generell zu verhindern, also nie auf das caller-Medium zurückzuschreiben. Aber auch das wäre ggfl. für Umrechnungen etc fatal.

Die Zusammenführung zweier GAs (Vorgabe und Status) gibt irgendwo ja auch den Sinn eben dieser Trennung auf. Dann könnte man auch vielfach bereits im KNX eine GA für beides verwenden - mit allen Nachteilen.

Eine richtig gute Lösung weiß ich auch nicht - allerdings denke ich, dass oben geschriebener Grundsatz halt immer zwangsweise gelten sollte und eben auch von sh.py sichergestellt werden sollte (notfalls eben per GA-write).

Evtl. könnte man ein "lazy-update" Attribut einführen (default = False!), was das Schreiben für gleiche Technologien (Plugins) verhindert. Allerdings wird dann auch z.B. von Visu auf Visu verhindert... Da bohrt man sich schnell logische Löcher...

Grüße
Robert

[2ndsky]

Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

Hallo Udo,

die Schleife und damit dein Hauptproblem wäre behoben, ja.

@Marcus: wenn ihr das verhalten so haben möchtet, das über den Bus empfangene Werte auch wieder auf den Bus gesendet werden, dann brauchen wir separate Attribute.

Was mir allerdings nicht klar ist, wozu ihr das braucht. Wenn ich am Russound die Lautstärke per App auf 20 setze, sh.py den Wert vom Russound empfängt, dann braucht sh.py die Lautstärke ja nicht nochmal auf 20 setzen... die ist ja schon 20. Bei KNX sehe ich das genauso. Wozu also dieses Verhalten?