Was mir hier noch aufgefallen ist (als Info an alle): Die Von- und Bis-Felder in der ETS bei den Eingangskonvertern können keine Kommazahlen, sorry. Das bedeutet, ich kann keinen DPT9-Eingangskonverter von 0,25 bis 1,75 machen. Die minimale Auflösung ist 1. Ich werde da erst was machen, wenn wenn es wirklich gebraucht/gefordert wird, weil eine Änderung bisherige Intervalle für DPT9 kaputtmachen würde. (Das war nicht korrekt, wie weitere Tests ergeben haben!)
Es war nicht ein Fehler im Coding, sondern in der ETS-Applikation. Ich habe nur beim Differenzintervall und Differenzhysterese für DPT9 in der knxprod versehentlich Integer-Felder genommen (copy&paste-Fehler), für Wertintervall und für Hysterese aber korrekte Float-Felder.
Das kann ich nur in der Applikation korrigieren, indem ich korrekterweise Float-Felder auch bei Differenzintervall und Differenzhysterese verwende. Dies bedeutet aber, dass bisherige DPT9-Eingangskonverter mit Differenzintervall oder Differenzhysterese (und nur die für DPT9) beim Upgrade ihre Von-/Bis- bzw. Einschalt-/Ausschalt-Werte verlieren werden und manuell nachgetragen werden müssen!
Vorteil dieser Korrektur: Eigentlich soll es so sein und man kann doch DPT9-Eingangskonverter mit Kommazahlen (also z.B. von 0,25 bis 1,75) definieren.
Die restlichen Aussagen zu DPT9 sind aber korrekt und beachtenswert:
Der andere Punkt, den man immer bei DPT9 berücksichtigen muss, ist die Genauigkeit von 2-Byte-Float-Werten. Beachtet somit bitte bei euren Tests, dass DPT9 kein exakter Wert ist. Was aus einer Zahl x für ein Wert gemacht wird, kann man in der ETS sehen, indem man mit dem Gruppenmonitor einen DPT9-Wert sendet und dann beim gesendeten Telegramm nachschaut, was wirklich gesendet wurde.
DPT9-Ungenauigkeit.jpg
In dem obigen Beispiel sieht man, dass eine 99.0 als DPT9 auf dem Bus mit dem Wert 99.04 gesendet wird.
Ich habe an möglichst alles Stellen versucht, das "richtige" mit DPT9 zu machen, aber es gibt sicherlich noch Lücken (wie von Sönke gefunden). Meldet es mir einfach und ich sehe, was man dann machen kann.
Gruß, Waldemar
Es war nicht ein Fehler im Coding, sondern in der ETS-Applikation. Ich habe nur beim Differenzintervall und Differenzhysterese für DPT9 in der knxprod versehentlich Integer-Felder genommen (copy&paste-Fehler), für Wertintervall und für Hysterese aber korrekte Float-Felder.
Das kann ich nur in der Applikation korrigieren, indem ich korrekterweise Float-Felder auch bei Differenzintervall und Differenzhysterese verwende. Dies bedeutet aber, dass bisherige DPT9-Eingangskonverter mit Differenzintervall oder Differenzhysterese (und nur die für DPT9) beim Upgrade ihre Von-/Bis- bzw. Einschalt-/Ausschalt-Werte verlieren werden und manuell nachgetragen werden müssen!
Vorteil dieser Korrektur: Eigentlich soll es so sein und man kann doch DPT9-Eingangskonverter mit Kommazahlen (also z.B. von 0,25 bis 1,75) definieren.
Die restlichen Aussagen zu DPT9 sind aber korrekt und beachtenswert:
Der andere Punkt, den man immer bei DPT9 berücksichtigen muss, ist die Genauigkeit von 2-Byte-Float-Werten. Beachtet somit bitte bei euren Tests, dass DPT9 kein exakter Wert ist. Was aus einer Zahl x für ein Wert gemacht wird, kann man in der ETS sehen, indem man mit dem Gruppenmonitor einen DPT9-Wert sendet und dann beim gesendeten Telegramm nachschaut, was wirklich gesendet wurde.
DPT9-Ungenauigkeit.jpg
In dem obigen Beispiel sieht man, dass eine 99.0 als DPT9 auf dem Bus mit dem Wert 99.04 gesendet wird.
Ich habe an möglichst alles Stellen versucht, das "richtige" mit DPT9 zu machen, aber es gibt sicherlich noch Lücken (wie von Sönke gefunden). Meldet es mir einfach und ich sehe, was man dann machen kann.
Gruß, Waldemar
Kommentar