Hallo,
Ich sende die von meine Wärmepumpe gemessenen Werte auf den KNX Bus:
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:
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
Servus!
Wird ne Weile dauern. Schau ich mir gerne mal an...
Danke. Eilt nicht. Mit etwas PERL kann man alles zurechtbiegen :o
define SWC_170_tout DOIF ([SWC_170:ambientTemperature]) (set KNX_00ff value {sprintf("%.2f",[SWC_170:ambientTemperature],0)})
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
Blöd, dann war die restriktive Behandlung wohl doch ganz gut :-)
Ich machs mal rückgängig...
Probier mal:
[+-]?\d{1,6}([.,]?\d{1,2})?
Sag bitte Bescheid, ob es funktioniert...
Ich habe mir noch mal die DOIF Doku im Detail angeschaut. Es funktioniert korrekt wenn man folgendes beachtet:
ZitatBerechnungen 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
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
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
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
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
Zitat von: Andi291 am 01 Februar 2017, 18:51:51
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...
Das könnte gehen...
Zitat von: Andi291 am 03 Februar 2017, 19:43:13
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.
[+-]?\d{1,6}(?:[.,]\d{1,2})?schöne Grüße
Joe