Ungewöhnliche Nachkommastellen und "krumme Werte" bei Sensorwerten und an anderen Stellen der WebUI

[Baxxy13]

Describe the issue you are experiencing

Mir ist in letzter Zeit aufgefallen das Sensoren manchmal Werte mit ungewöhnlichen Nachkommastellen liefern.
Das sieht man in der WebUI normalerweise nicht weil die Anzeige der Nachkommastellen begrenzt ist, aber das Lovelace-Dashboard von HA zeigt das dann auch.
Liest man die Datenpunkte per Script aus kommen da Werte zum Vorschein die die Sensoren nicht liefern (können).
(im Beispiel liefert der Sensor maximal eine Nachkommastelle)

Apr  2 10:44:16 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-1 Luftdruck: 1013.500000
Apr  2 10:47:53 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-3 Luftdruck: 1013.599999
Apr  2 10:49:30 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-1 Luftdruck: 1013.700000
Apr  2 10:52:56 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-3 Luftdruck: 1013.700000
Apr  2 10:54:43 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-1 Luftdruck: 1013.599999
Apr  2 10:58:00 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-3 Luftdruck: 1013.599999
Apr  2 10:59:57 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-1 Luftdruck: 1013.599999
Apr  2 11:03:04 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-3 Luftdruck: 1013.599999
Apr  2 11:05:11 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-1 Luftdruck: 1013.700000
Apr  2 11:08:07 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-3 Luftdruck: 1013.700000
Apr  2 11:10:24 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-1 Luftdruck: 1013.799999
Apr  2 11:13:11 RM-Live-OVA-26 daemon.info cuxd[838]: CUX2801001:1 Uni-3 Luftdruck: 1013.799999

Dachte ich erst an ein Problem in meinem System kann man das Phänomen in ähnlicher Form auch auf frischen RaspberryMatics ohne Geräte (aber mit Funkmodul) sehen.

Zum Einen bei einer frisch angelegten IP-Gruppe im Kanal:2 bei der Hystereseeinstellung...
(Beispielscreenshot aus dem Hauptsystem, aber identisch mit neuer leerer IP-Gruppe)

zum anderen bei der maximalen Ventilöffnungsposition von eTRV's wo "krumme Werte" in der Liste sind...

Describe the behavior you expected

Das System sollte korrekte unverfälschte Werte zurückliefern.
Auch wenn (für mein Beispiel) eine Abweichung von 0.000001 eher wenig Relevanz hat dürfte m.E. sowas nicht vorkommen.

Steps to reproduce the issue

1. frische RM aufsetzen (getestet mit .ova / Pi3B / TinkerS) mit Funkmodul aufsetzen
2. eine IP-Heizgruppe anlegen (es müssen keine Geräte hinzugefügt werden)
3. Die Hystereseeinstellungen in Kanal:2 des Gruppengerätes "aufklappen"
4. alternativ bei eTRV's die "maximale Ventilöffnungsposition" "aufklappen"
   ...

What is the version this bug report is based on?

3.63.8.20220330

Which base platform are you running?

rpi3 (RaspberryPi3)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

-

Additional information

Ich dachte erst es hat eventuell was mit der .ova bzw. der 64bit Version zu tun weil ich ähnliches schon bei CUxD (Link Homematic-Forum) gesehen hatte.
Aber auf dem 32bit TinkerS kann ich das genauso (Hysterese / Ventilöffnungsposition) reproduzieren.

"Gefühlt" ging das mit den Nightly's nach der offiziellen 3.61.7.20220226 los. Wenn ich Zeit finde gehe ich nochmal zurück und verifiziere das.

Getestet Systeme: 3.63.8.20220330 .ova / Pi3B+ / TinkerS

[jens-maus]

Wäre super wenn du das mit einer älteren version in der tat verifizieren könntest.

[Baxxy13]

Gesagt... getan.
Die erwähnte Hystereseeinstellung kann ich nicht prüfen, die gibt es ja in dieser Form so noch nicht.
Die "maximale Ventilöffnungsposition" des eTRV kennt wieder korrekte 5% Schritte (von 0% - 100%).
Die Sensorwerte zeigen aber weiterhin Abnormalitäten.

Apr  2 14:02:55 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-2 Luftdruck: 1013.500000
Apr  2 14:06:49 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-2 Luftdruck: 1013.599999
Apr  2 14:07:08 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-2 Luftdruck: 1013.700000
Apr  2 14:07:56 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-2 Luftdruck: 1013.599999
Apr  2 14:08:14 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-2 Luftdruck: 1013.599999
Apr  2 14:10:54 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-2 Luftdruck: 1013.500000
Apr  2 14:15:31 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-2 Luftdruck: 1013.599999
Apr  2 14:20:45 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-2 Luftdruck: 1013.500000

Apr  2 13:56:46 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-3 Luftdruck: 1013.500000
Apr  2 14:01:50 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-3 Luftdruck: 1013.500000
Apr  2 14:02:42 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-3 Luftdruck: 1013.599999
Apr  2 14:03:47 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-3 Luftdruck: 1013.599999
Apr  2 14:08:51 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-3 Luftdruck: 1013.500000
Apr  2 14:13:55 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-3 Luftdruck: 1013.500000
Apr  2 14:18:59 RM-Live-OVA-26 daemon.info cuxd[931]: CUX2801001:1 Uni-3 Luftdruck: 1013.500000

Komisch...

[Baxxy13]

Wenn man sich das Systemprotokoll an der WebUI "vorbei" anschaut... (watch HistoryBuffer.csv - außerhalb der WebGUI (CCU2)), braucht man auch kein Logging Script.
WebUI Systemprotokoll:

14:57:54 | 02.04.2022 | Klima Sensor WZ: UNISENS001:1 - Klimadaten | Luftdruck 1013.80hPa
14:59:29 | 02.04.2022 | Klima Sensor BX: UNISENS003:1 - Klimadaten | Luftdruck 1013.90hPa
15:02:35 | 02.04.2022 | Klima Sensor FL: UNISENS002:1 - Klimadaten | Luftdruck 1013.80hPa
15:03:18 | 02.04.2022 | Klima Sensor WZ: UNISENS001:1 - Klimadaten | Luftdruck 1013.90hPa

externe Systemprotokollabfrage:

02.04. 14:57:54 | Klima Sensor WZ: UNISENS001:1 - Klimadaten | AIR_PRESSURE:1013.799999
02.04. 14:59:29 | Klima Sensor BX: UNISENS003:1 - Klimadaten | AIR_PRESSURE:1013.900000
02.04. 15:02:35 | Klima Sensor FL: UNISENS002:1 - Klimadaten | AIR_PRESSURE:1013.799999
02.04. 15:03:18 | Klima Sensor WZ: UNISENS001:1 - Klimadaten | AIR_PRESSURE:1013.900000

[Baxxy13]

Weitere Erkenntnis:
Im rfd kommen die Werte korrekt an:
Apr 2 17:30:22 RM-Live-OVA-26 user.debug rfd: Event: UNISENS002:1.AIR_PRESSURE=1014.800000

In der ReGa dann nicht mehr:
02.04. 17:33:22 | Klima Sensor BX: UNISENS003:1 - Klimadaten | AIR_PRESSURE:1014.799999

[Baxxy13]

Hinweis aus dem Forum... "nicht jeder beliebige float Wert kann in der binary representation auch exakt darstellt werden"
Mit dem Hinweis und diesem Float-Converter ergibt sich dann folgendes:

Sensor-Wert > Converter-Wert           -> ReGa-Wert
1013.50         > 1013.5               -> 1013.500000
1013.60         > 1013.5999755859375   -> 1013.599999
1014.70         > 1013.70001220703125  -> 1013.700000
1014.80         > 1013.79998779296875  -> 1013.799999

Es wird also irgendwie gerundet? Aber nicht immer?

[Baxxy13]

Bin jetzt mal mit einem Sensor auf original CCU3 3.57.5 zurück.
Selbes Verhalten mit den teils komischen Nachkommastellen.

Damit betrachte ich diesen Teil mit "war schon immer so" als für mich erledigt.

Es bleiben aber die "krummen Werte" bei der Hystereseeinstellung sowie der "maximale Ventilöffnungsposition".

[jens-maus]

Nachdem sich aus #1782 ja ergeben hat das dies ein tcl_precision problem zu sein scheint vermute ich, das die hier beschriebenen Probleme zumindest teilweise damit auch zu tun haben. Ich würde daher vorschlagen mit dem nightly snapshot von morgen nochmal entsprechend zu testen ob/welche probleme aus diesem issue hier noch da sind, dann könnte man schauen ob man hier ggf noch etwas optimieren/fixen könnte bzgl krumme nachkommastellen.

[Baxxy13]

Falsch verlinkt, aber ich habe deine Ausführungen zu floating point precision tcl 8.2 vs. 8.6 gelesen.
Ich hatte auch im Forum darüber gefachsimpelt, da mir das ja primär bei den Luftdruck-Werten eines Selbstbau-Sensor's auffiel.
War ganz interessant und aufschlussreich. Link Homematic-Forum

Ich gucke mir das dann demnächst mit dem Nightly nochmal an.

[Baxxy13]

kurzes Feedback:
Die beiden WebUI - Stellen "Hysterese Kanal:2 in Gruppengeräten" und "maximale Ventilöffnungsposition" beim eTRV zeigen mit dem heutigen Nightly 3.63.8.20220405-d2a744 keine krummen Werte mehr.
Somit ist das Thema eigentlich erledigt.

Meine Luftdrucksensoren zeigen weiterhin "krumme Werte" aber das war abzusehen da du die TCL-Precision ja auf den Wert der 3.61.7.20220226 gesetzt hast (tcl_precision: 12) und das dort auch schon zu sehen war.

Ich würde gerne ein bisschen mit der Precision experimentieren, weiß aber nicht wo ich ansetzen muss.
Ist der Wert "hart codiert" oder gibt es eine Konfigurations-Datei dafür?
Vielleicht kannst du mir ja einen Hinweis geben wo die ReGa den vom rfd übermittelten Wert empfängt und für die WebUI aufbereitet.

[jens-maus]

Meine Luftdrucksensoren zeigen weiterhin "krumme Werte" aber das war abzusehen da du die TCL-Precision ja auf den Wert der 3.61.7.20220226 gesetzt hast (tcl_precision: 12) und das dort auch schon zu sehen war.

Ich würde gerne ein bisschen mit der Precision experimentieren, weiß aber nicht wo ich ansetzen muss. Ist der Wert "hart codiert" oder gibt es eine Konfigurations-Datei dafür?

Die tcl_precision ist in der Tat hart in tclsh kodiert, kann aber in einer laufenden tcl session (aber eben nur für diese) via set tcl_precision X abgändert werden. Im Grunde ist/war die neue tcl_precision von tcl 8.6.x aber eigentlich "besser" bzw. richtiger als hier hart "12" zu setzen wie jetzt wieder. Das Problem ist jedoch, das eben an vielen WebUI Stellen die eQ3 Entwickler leider arithmetische Operationen durchführen die man eigentlich anders machen müsste damit diese mit neueren tcl versionen und der darin geänderten tcl_precision (dort gibt es eine autoerkennung) noch korrekt funktioniert. Deshalb war es bzw. ist es momentan noch der bessere Ansatz die tcl precision wie in vorherigen Versionen auf 12 zu fixieren um eben das gleiche arithmetische Verhalten wieder herzustellen.

[Baxxy13]

Das Problem besteht sicher schon lange, nur wird es halt gut in der WebUI verschleiert.
Problematisch wird es erst wenn man auf die angezeigten Werte per WebUI-Programm triggern will.

Um mal einen Beispielwert von oben zu nehmen...
= 1013.80 wird in einem WebUI-Programm niemals wahr da der verschleierte tatsächliche Wert eben 1013.799999 ist.

Da wäre eine saubere Rundung der Nachkommastellen schon wünschenswert.

[stale]

Thanks for your contribution!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of RaspberryMatic and tell us. Also check that all relevant details,

---

Vielen Dank für die Unterstützung!
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüfen Sie, ob das Problem auch in der aktuellsten Version von RaspberryMatic noch relevant ist, und teilen Sie uns dies mit. Überprüfen Sie auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind oder aktualisiert werden müssen.

[stale]

This issue has been automatically closed because of inactivity. Please open a new issue if still relevant and make sure to include all relevant details, logs and reproduction steps.

---

Dieses Problem wurde aufgrund von Inaktivität automatisch geschlossen. Bitte öffnen Sie ein neues Issue, falls dies noch relevant ist und stellen Sie sicher das alle relevanten Details, Logs und Reproduktionsschritte enthalten sind.