set mit ganzzahligem Wert auf dpt9

[Xcoder]

Hallo,

Ich sende die von meine Wärmepumpe gemessenen Werte auf den KNX Bus:

Code Auswählen Erweitern

define KNX_00ff KNX 0/0/255:dpt9.001
define SWC_170_tout DOIF ([SWC_170:ambientTemperature]) (set KNX_00ff value [SWC_170:ambientTemperature])

Leider gibt es aber bei ganzzahligen Werten einen Fehler:

Code Auswählen Erweitern

2016.12.05 21:07:39 2: SWC_170_tout: set KNX_00ff value -2: invalid value: -2

Grund scheint die sehr restriktive Definition des Pattern für dpt9 zu sein: [+-]?\d{1,6}[.,]?\d{1,2}

Wieso so restriktiv? Würde [+-]?\d{1,6}[.,]?\d{0,} nicht genügen?


Gruss, Xcoder

[Andi291]

Servus!

Wird ne Weile dauern. Schau ich mir gerne mal an...

[Xcoder]

Danke. Eilt nicht. Mit etwas PERL kann man alles zurechtbiegen 

Code Auswählen Erweitern

define SWC_170_tout DOIF ([SWC_170:ambientTemperature]) (set KNX_00ff value {sprintf("%.2f",[SWC_170:ambientTemperature],0)})

[Xcoder]

Hmm, das funktioniert nun nicht mehr. Offenbar wird der Perl-Ausdruck gar nicht ausgewertet und einfach die erste Zahl zugewiesen. Nun ist es immer 2.0 °C warm...

Gruss, Xcoder

[Andi291]

Blöd, dann war die restriktive Behandlung wohl doch ganz gut

Ich machs mal rückgängig...

[Andi291]

Probier mal:

[+-]?\d{1,6}([.,]?\d{1,2})?

Sag bitte Bescheid, ob es funktioniert...

[Xcoder]

Ich habe mir noch mal die DOIF Doku im Detail angeschaut. Es funktioniert korrekt wenn man folgendes beachtet:

Berechnungen können in geschweiften Klammern erfolgen. Aus Kompatibilitätsgründen, muss die Berechnung unmittelbar mit einer runden Klammer beginnen. Innerhalb der Perlberechnung können Readings, Stati oder Internals wie gewohnt in eckigen Klammern angegeben werden.

Daher

Code Auswählen Erweitern

define SWC_170_tout DOIF ([SWC_170:ambientTemperature]) (set KNX_0019 value {(sprintf("%.2f",[SWC_170:ambientTemperature]))} )

Keine Ahnung wieso es vorher funktioniert hat. DOIF ist manchmal echt ein Biest

Gruss, Xcoder

[Xcoder]

Das Letzte Update klemmt wieder mehr ab. Irgendwie hat es vorher doch funktioniert und ich hatte den Perl-Bastel rausgenommen. Ich kann nicht ganz verstehen wieso der Filter da so restriktiv ist...

Der Filter im Beitrag oben ist schon mal besser. Wobei etwas in der Art [+-]?\d\d*([.,]\d*)? doch auch gehen würde.

Und wenn wir schon dabei sind: für dpt14 sind 3 Kommastellen auch etwas knapp (Zeile 1480). Da sollten doch eher 6-8 Stellen signifikant sein.

Gruss, Xcoder

[Andi291]

Servus!

Das AUfweichen des Filters hat andere User unglücklich gemacht. Deshalb hab ich es wieder reingenommen.
Das mit dem DPT14 schau ich mir mal an. So wirklich überzeugt bin ich von 6-8 Stellen nicht

Grüße, Andi

[Xcoder]

Hallo Andi,,
Ja, 6-8 ist wohl schon etwas viel. Habe kurz geprüft wieviel das letzte Bit ausmacht. Ein dpt14 kann ja etwa 6-7 signifikante Stellen enthalten. Wenn die in KNX_decodeByDpt weggerundet werden, sind sie verloren. Bei mir sind es GPS Koordinaten wo halt die 4 - 5 Kommastelle relevant ist.

Das mit dem strengen Filter kann ich ja schon verstehen. Aber wieso eine ganzahlige Zahl nicht einem DPT9 zugewiesen werden können soll, leuchtet mir nicht ein.

Gruss, Xcoder

[JoeALLb]

Das AUfweichen des Filters hat andere User unglücklich gemacht. Deshalb hab ich es wieder reingenommen.

Kann man nicht einfach eine ".0" im Modul bei dpt9 anhängen, wenn er keine Nachkommastellen enthält?
Ich habe das selbe Problem...

[Andi291]

Das könnte gehen...

[JoeALLb]

Das könnte gehen...

Ich habe einiges getestet: Dieser
Regex sollte funktionieren, auch bei den Werten aus dem anderen Thread.
Als Änderung habe ich die Klammer hinten in eine "non capturing group) geändert,
damit sie die Nachkommastellen nicht extra herausfiltert.

Code Auswählen Erweitern

[+-]?\d{1,6}(?:[.,]\d{1,2})?

schöne Grüße
Joe