[Frage] Speicherung der 1-Wire-Messwerte

[EarlBacid]

Hallo Juri,

wie du schon siehst kommen die Werte aus deinen beiden SQL Abfragen aus zwei unterschiedlichen Datenbanken.

Laut Datenblatt liegt die Auflösung des Sensors bei 9 Bit. Der Datentyp 5.001 hat jedoch nur 8 Bit. Der eigentliche Messwert (der so jedoch aber auch korrekt in die TS00018 geschrieben wird) wird entsprechend gerundet bevor er auf den KNX Bus gesendet wird (und hiervon dann wieder in der Datenbank unter KNX_LINE1" ein weiteres mal gespeichert wird. Dementsprechend hast du aber in der Datenbank eben auch nur die Werte, wie sie auf dem KNX Bus gesendet wurden und nicht die Rohwerte des Sensors.

Wie du bei den Werten aus dem KNX sehen kannst, gibt es dort auch z.B. nur den Wert 70,588234 (8 Bit Wert für 180 Dezimal) und 70,980392 (8 Bit Wert für 181 Dezimal). Es gibt dazwischen also keine weiteren Abstufungen, weil 8 Bit diese nicht hergeben.

Die Rohwerte des Sensors können mit 9 Bit aber eben deutlich mehr zwischenschritte als Ergebnis liefern, die dann aber alle auf einen der Beiden möglichen 8 Bit Werte im KNX auf- oder abgerundet werden müssen.

---------

jetzt warst du mit deiner Antwort zwischenzeitlich schneller

Ja, du hast das richtig verstanden. Wobei es eben nicht nur eine Formatierung ist, die sich unterscheidet, der der zugrunde liegende Datentyp.
Wichtig ist erst einmal: Beide Werte sind richtig, es ist keiner davon Falsch. Sie sind nur unterschiedlich gut aufgelöst, sprich der TS Messwert ist präziser als der KNX Messwert. Der KNX Wert kann maximal auf 0,39 % genau auflösen. Dementsprechend würde es sinn machen, dass du z.B. deine Regel hierfür abänderst, dass erst bei einer Änderung von 0,5% der Wert erneut gesendet werden soll. Damit verhinderst du, dass der selbe Wert permanent wiederholt wird (mal davon abgesehen was du mit der Information überhaupt anfangen willst ob du nun 70,4% oder 70,5% rel. Luftfeuchte in einem Raum hast.

Da der Messwert jedoch durch den Sensor und der KNX Wert durch den von KNX vorgegebenen Datentyp bestimmt wird, wirst du die beiden nich auf exakt den selben Wert bekommen.

Was ich mich aber dabei Frage ist, wozu benötigst du das überhaupt?

VG
Earl

[StefanW]

Hallo Juri,

ich bin mir nicht sicher, ob ich das Problem verstehe?

Geht es um die Unterschiede in den Nachkommastellen? Das können wir nicht beeinflussen. Die Fließkommakodierung ist abhängig von der Technologie.

Die Fließkommadarstellung ist bei 1-Wire eine andere als im Dispatcher und diese mag anders sein als in der Zeitserien-DB und diese ist auf jeden Fall anders als bei KNX. Aus den Umrechnungen ergeben sich Unterschiede und das ist technisch bedingt und lässt sich auch nicht ändern, weil wir nur die Genauigkeit im Dispatcher beeinflussen können, aber nicht in den Subsystemen bei denen wir von der Technologie abhängen. Speziell KNX hat ein teils recht sparsames Fließkommaformat (es gibt dort die beiden Versionen 16 Bit und 32 Bit)


Wikipedia schreibt dazu:

Gleitkommazahlen warten besonders für den mathematischen Laien mit einigen Überraschungen auf, die auch oft das Ergebnis von Taschenrechner- und Computerrechnungen beeinflussen. Am wichtigsten sind außer Kraft gesetzte geläufige mathematische Rechenregeln. Wer intensiv mit einem Rechenhilfsmittel arbeitet, muss diese Eigenschaften kennen. Sie gehen auf die begrenzte Genauigkeit zurück, mit der Mantisse und Exponent gespeichert werden. Die Konsequenz dieser Begrenzung wird klar, wenn man sich überlegt, dass die unendlich vielen reellen Zahlen durch endlich viele Ziffernkombinationen dargestellt werden sollen. Man kann sich die Gleitkommazahlen im Definitionsbereich eines Systems als lange Tabelle diskreter Werte vorstellen. Eine Gleitkommafunktion ordnet dann jedem Wert dieser Liste einen anderen Wert zu. Analoges gilt für zwei- und mehrstellige Operationen. Im Artikel Minifloats sind die entsprechenden Wertebereiche grafisch dargestellt.

Daraus resultiert die leichte bis absolute Ungenauigkeit der Rechnungen und die außer Kraft gesetzte Gültigkeit geläufiger mathematischer Rechenregeln.

Beispiele und weitere Erklärungen hier: https://de.wikipedia.org/wiki/Gleitkomm ... arithmetik

Wenn es nach mir geht, würde ich die Werte nach den Kommas ohnehin abschneiden, weil so genau ist eine Feuchtemessung ja gar nicht bzw. wird man an zehn Stellen im Raum auch zehn verschiedene Werte haben.

lg

Stefan

[gbglace]

Ich versuche jetzt zusammen zu fassen was ich verstanden habe.

Unter 1-Wire habe ich eine Regel für TS00018 mit einem Trigger definiert.
Der Trigger wird ausgelöst, wenn die Temperaturdifferenz den Wert 0,005 überschreitet und schreibt gleichzeitig den neuen Wert in die TS0018

Bis dahin korrekt.

Wenn Du an der gleichen 1-wire Regel neben der TS auch noch dein KNX-KO verbunden hast, dann ja dann wird das KO beschrieben und der Wert auf den KNX-Bus gesendet.

Eine Unterschiedlichkeit in der Granularität der Nachkommastellen kann es geben aber dann würde ich da nicht 70,5x vs 70,7x erwarten, das kann kein Problem von Rundungen sein, vor allem weil die KNX-Telegramme auch noch mehr Nachkommastellen haben.

Zum Ablauf noch. Sofern ein Telegramm auf den Bus gesendet wurde, bekommt der TWS-KNX-Logger das natürlich auch horchend wieder rein und befüllt damit den Ringspeicher.

Wie verhält sich das System wenn du an der bestehenden 1-wire Regel das KNX-Ko abkoppelst und dafür eine eigene Regel mit abweichenden Triggerzeiten definierst?

[Sensej]

Hallo Earl,
nochmal vielen Dank für die zahlreichen Tipps und Erklärungen.

wie du schon siehst kommen die Werte aus deinen beiden SQL Abfragen aus zwei unterschiedlichen Datenbanken.

die Datenbank ist die gleiche, timeseries_db. Als Default ist bei mir auch "timeseries_db"-Datenbank fest gelegt.
Es sind unterschiedliche Timeseries: TS00018 und KNX_LINE1

Damit verhinderst du, dass der selbe Wert permanent wiederholt wird

Sehr guter Tipp, Danke

Da der Messwert jedoch durch den Sensor und der KNX Wert durch den von KNX vorgegebenen Datentyp bestimmt wird, wirst du die beiden nich auf exakt den selben Wert bekommen.

ok, alles klar

Was ich mich aber dabei Frage ist, wozu benötigst du das überhaupt?

das war eine Verständnisfrage.
Ich habe vor meine TWS-Einstellungen in der nächsten Zeit zu optimieren und das ist fast unmöglich ohne zu wissen wie das Grundsystem funktioniert

Wer aufhört zu lernen, hört auf zu leben

MfG Juri

[Sensej]

Hallo Juri,

Wenn es nach mir geht, würde ich die Werte nach den Kommas ohnehin abschneiden, weil so genau ist eine Feuchtemessung ja gar nicht bzw. wird man an zehn Stellen im Raum auch zehn verschiedene Werte haben.

Hallo Stefan,

vielen Dank für einen weiteren guten Tipp

MfG Juri

[Sensej]

Zum Ablauf noch. Sofern ein Telegramm auf den Bus gesendet wurde, bekommt der TWS-KNX-Logger das natürlich auch horchend wieder rein und befüllt damit den Ringspeicher.

Danke Göran

MfG Juri

[EarlBacid]

Eine Unterschiedlichkeit in der Granularität der Nachkommastellen kann es geben aber dann würde ich da nicht 70,5x vs 70,7x erwarten, das kann kein Problem von Rundungen sein, vor allem weil die KNX-Telegramme auch noch mehr Nachkommastellen haben.

Hallo Göran,

doch, in dem Fall ist es genau so "brutal".

Die DTP 5.001 definiert 8 Bit (Dezimal also 0-255), die als 0-100% interpretiert werden. Daraus ergibt sich eine Schrittweite von 100/255 = 0,392156862745098.

Ergo:
0 = 0 %
1 = 0,392156862745098 %
2 = 0,7843137254901961 %
3 = 1,176470588235294 %
[...]
180 = 70,58823529411765 %
181 = 70,98039215686275 %
[...]
255 = 100 %

Eine Rundung erfolgt also auf genau einen der beiden Werte 70,58823... oder 70,9803...
und das obwohl die einzelnen Prozentwerte sogar richtig viele Nachkommastellen haben.


Wenn du auf ganze Prozentwerte Runden möchtest, dann verwende einfach den DTP 5.004. der hat ebenfalls 8 Bit, aber einen gültigen Wertebereich von 0% bis 255% wodurch die Schrittweite nicht bei 0,39... sondern exakt bei 1 liegt.

VG
Earl

[StefanW]

Sehr richtig Earl, danke sehr!

Dieses spezielle 8 Bit Prozent-Format in KNX produziert besonders heftige Abweichungen.


Beispiele aus dem Bereich 1-Wire:

Bei 1-Wire funktioniert das "Fließkommaformat" mit Dezimalbrüchen, hier am Beispiel für Temperaturen:

• 9 Bit: Die ersten 8 Bit sind steht für die ganze Zahl (1/1), das 9. Bit für den Bruch 1/2. Mithin eine Auflösung von einem halben Kelvin
• 10 Bit: Die ersten 8 Bit sind steht für die ganze Zahl (1/1), das 9. für den Bruch 1/2 und das 10. Bit für 1/4. Mithin eine Auflösung von einem viertel Kelvin
• 11 Bit: Die ersten 8 Bit sind steht für die ganze Zahl (1/1), das 9. für den Bruch 1/2, das 10. Bit für 1/4 und das 11. Bit für 1/8. Mithin eine Auflösung von 0,125 K
• 12 Bit: Die ersten 8 Bit sind steht für die ganze Zahl (1/1), das 9. für den Bruch 1/2, das 10. Bit für 1/4 und das 11. Bit für 1/8 und das 12. Bit für 1/16. Mithin eine Auflösung von 0,0625 K
• 13 Bit (nur DS2438): Die ersten 8 Bit sind steht für die ganze Zahl (1/1), das 9. für den Bruch 1/2, das 10. Bit für 1/4 und das 11. Bit für 1/8 und das 12. Bit für 1/16 und das 13. Bit für 1/32. Mithin eine Auflösung von 0,03125 K

Speziell diese 13 Bit Auflösung bei der Temperatur aus dem DS2438 ist diskussionswürdig. Eine Auflösung auf 1/32 Kelvin bis zur fünften Nachkommastelle bei einer Grundgenauigkeit von nur +/- 2 K ist eigentlich technischer Unsinn, bei diesem Baustein aber nicht konfigurierbar.

Bei Fließkommaformaten muss man immer genau hinsehen, insbesondere wenn diese mit sehr wenigen Bits gemacht werden, weil die "Stufigkeit" im Nachkommabereich (bzw. auch bei großen Zahlen im Dezimalbereich) kann durchaus enorm werden.


Ausblick auf Modbus:

Im Bereich Modbus wird neben verschiedenen Fließkommaformaten auch oft mit Festkommaformaten gearbeitet. Eine Temperatur von 50,000 °C wird bei Modbus zumeist als 500 oder 5000 oder 50000 gesendet (je nach Register), Da muss man ganz genau hinsehen im Datenblatt und den richtigen Teiler zu konfigurieren. Dafür implementieren wir hier auch mehr ´Kontrolle (d.h. Einstellmöglickeiten) für den Nutzer hinsichtlich Rundungen und Nachkommastellen sowie eine integrierte Werteprüfung (Plausibilitätskontrolle).

Wer sich mit Modbus beschäftigen will und auch bereits Modbus Geräte hat, die er in einigen Wochen am Timberwolf Server nutzen wird, mag sich vielleicht bereits vorbereiten: Datenblatt des betreffenden Modbus Gerätes besorgen und solange durchlesen, bis man es verstanden hat. GGfls. recherchieren. Auf diese Weise kann man die Lernkurve schon hinter sich haben und versteht dann auch wie man etwas konfigurieren muss.

Hinweis: Die Modbus-Extensions für die TWS sind bereits in Produktion und werden rechtzeitig lieferbar sein

lg

Stefan

[CHD]

@StefanW Ich bin verwirrt. Bei den Bitangaben ab 11Bit und weiter müssen doch jeweils die von dir angegeben Werte noch halbiert werden, oder?

Aber bei sooo vielen Bits kommt man ja auch ganz durcheinander .

Hinweis: Die Modbus-Extensions für die TWS sind bereits in Produktion und werden rechtzeitig lieferbar sein

Ich freue mich

VG, Christian

[StefanW]

Hallo Christian,

Ich bin verwirrt. Bei den Bitangaben ab 11Bit und weiter müssen doch jeweils die von dir angegeben Werte noch halbiert werden, oder?

Jep, dann hat es wenigstens einer genau gelesen, hab es korrigiert, Danke.

Ich freue mich

Yeah, wir uns auch

lg

Stefan