HB-UNI-Sensor1 - Neuauflage

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

Benutzeravatar
Baxxy
Beiträge: 5910
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 355 Mal
Danksagung erhalten: 1098 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Baxxy » 02.04.2022, 18:01

Hmm interessant, aber was bedeutet das jetzt.
Das das so "normal" ist?
Dann dürfte ja keiner der Werte "glatt" dargestellt werden, es sei denn es findet noch irgendwo intern eine Rundung statt:

Code: Alles auswählen

1013.50 > 1013.5 -> ReGa: 1013.500000
1013.60 > 1013.5999755859375 -> ReGa: 1013.599999
1014.70 > 1013.70001220703125 -> ReGa: 1013.700000
1014.80 > 1013.79998779296875 -> ReGa: 1013.799999
Kurios :shock:

Grüße, Baxxy

Der rfd zeigt's jedenfalls noch korrekt...

Code: Alles auswählen

Apr 2 17:30:22 RM-Live-OVA-26 user.debug rfd: Event: UNISENS002:1.AIR_PRESSURE=1014.800000
Die ReGa dann nicht mehr:

Code: Alles auswählen

02.04. 17:33:22 | Klima Sensor BX: UNISENS003:1 - Klimadaten | AIR_PRESSURE:1014.799999

jp112sdl
Beiträge: 10420
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 674 Mal
Danksagung erhalten: 1618 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von jp112sdl » 02.04.2022, 18:17

Baxxy hat geschrieben:
02.04.2022, 18:01
Der rfd zeigt's jedenfalls noch korrekt...
Die Binary ist recht statisch, da wird/wurde schon lange nichts mehr verändert.
Baxxy hat geschrieben:
02.04.2022, 18:01
Die ReGa
hingegen schon und ist somit aus meiner Sicht der kleinste gemeinsame Nenner, wenn sich an allem anderen ringsum in der Vergangenheit nicht verändert hat.

War das mit der 3.61 auch schon so mit den krummen Werten?

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
Baxxy
Beiträge: 5910
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 355 Mal
Danksagung erhalten: 1098 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Baxxy » 02.04.2022, 18:24

jp112sdl hat geschrieben:
02.04.2022, 18:17
War das mit der 3.61 auch schon so mit den krummen Werten?
Ja, das hatte ich vorhin noch getestet und da trat das auch auf (3.61.7.20220226).

Schwer zu sagen ob das "schon immer" so war, oder irgendwann anfing. In der WebUI sieht man's ja nicht.
Ist mir erst aufgefallen als ich die Sensoren im HA-Dashboard hatte, die absurden Nachkommastellen sprangen sofort ins Auge.

Wenn ich mal Muße habe setze ich mal eine ältere Version auf und lerne dort einen der UNIsensoren an.

Grüße, Baxxy

TomMajor
Beiträge: 1714
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 162 Mal
Danksagung erhalten: 365 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 02.04.2022, 22:13

Baxxy hat geschrieben:
02.04.2022, 18:01
Hmm interessant, aber was bedeutet das jetzt.
Das das so "normal" ist?
Dann dürfte ja keiner der Werte "glatt" dargestellt werden, es sei denn es findet noch irgendwo intern eine Rundung statt:

Code: Alles auswählen

1013.50 > 1013.5 -> ReGa: 1013.500000
1013.60 > 1013.5999755859375 -> ReGa: 1013.599999
1014.70 > 1013.70001220703125 -> ReGa: 1013.700000
1014.80 > 1013.79998779296875 -> ReGa: 1013.799999
Kurios :shock:

Grüße, Baxxy
Hi Baxxy,

das bedeutet dass nicht jedes floating point value in den IEEE-754 Formaten exakt darstellbar ist, schon gar nicht im Single Format was 32bit breit ist.
Daran ist nichts zu ändern.

Die Unterschiede die du siehst liegen m.E. daran dass unterschiedliche HM Entwickler bei Log-Ausgaben in den internen Module verschiedene Formatier- bzw. Rundungsoptionen verwenden, ggf. erledigen dass auch Bibliotheken die sie verwenden, im Hintergrund ohne dass der Entwickler sich darum zu viele Gedanken macht.
Und je nach Programmiersprache/Bibliothek/Formatieroptionen der Zahl kommen dann unterschiedliche Ausgaben in den einzelnen Modulen zustande - wenn die Zahl nicht exakt in das IEEE-754 Format passt.

z.B. 1013.5 passt exakt, 1014.8 nicht
https://www.h-schmidt.net/FloatConverter/IEEE754.html

Lohnt sich imho nicht, da zu viel Zeit für "Fehlersuche" zu verwenden.
Viele Grüße,
Tom

Benutzeravatar
Baxxy
Beiträge: 5910
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 355 Mal
Danksagung erhalten: 1098 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Baxxy » 02.04.2022, 23:48

Danke soweit für die Erklärungen.

Fest steht das es kein Problem des HB-UNI-Sensor1 oder des zugehörigen HB-TM-Devices-AddOn ist.
TomMajor hat geschrieben:
02.04.2022, 22:13
Lohnt sich imho nicht, da zu viel Zeit für "Fehlersuche" zu verwenden.
Stimmt.
Da ich aber bei solchen Dingen nicht gerne klein beigebe werde ich zumindest nochmal eine ältere RM testen.
Irgendwie ist das unschön das der Eingangswert korrekt ist, dann aber vom System "verfälscht" wird.

RM selbst zeigt diese Problematik übrigens in der aktuellen Version auch an anderen Stellen. :wink:
RM_Rundungsprobleme_IP-Gruppe.jpg
Grüße, Baxxy

TomMajor
Beiträge: 1714
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 162 Mal
Danksagung erhalten: 365 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 03.04.2022, 00:09

Baxxy hat geschrieben:
02.04.2022, 23:48
Danke soweit für die Erklärungen.

Fest steht das es kein Problem des HB-UNI-Sensor1 oder des zugehörigen HB-TM-Devices-AddOn ist.

Da ich aber bei solchen Dingen nicht gerne klein beigebe werde ich zumindest nochmal eine ältere RM testen.
Irgendwie ist das unschön das der Eingangswert korrekt ist, dann aber vom System "verfälscht" wird.

RM selbst zeigt diese Problematik übrigens in der aktuellen Version auch an anderen Stellen. :wink:
RM_Rundungsprobleme_IP-Gruppe.jpg

Grüße, Baxxy
Leider scheinen meine Erklärungsversuche nicht auszureichen, dass du verstehst dass die Sache Systemimmanent beim verwendeten IEEE-754 Format ist. :(
Diese "Verfäschungen" treten immer auf wenn man mit floating point numbers hantiert, mal weniger, mal mehr. Abhilfe schafft sinnvolles Runden vor der Ausgabe des Wertes.
Viele Grüße,
Tom

Benutzeravatar
Baxxy
Beiträge: 5910
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 355 Mal
Danksagung erhalten: 1098 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Baxxy » 03.04.2022, 13:55

Hallo TomMajor,
ich hatte das schon verstanden auch wenn es vielleicht nicht so rüber kam.
Bin aber trotzdem mal 1 Jahr (3.57.5) zurück um zu gucken ob da was anders war, also ob vielleicht ein...
TomMajor hat geschrieben:
03.04.2022, 00:09
sinnvolles Runden
... stattfand. Dem ist nicht so. Also war es wohl doch "schon immer so" und fiel nur nie auf.

Warum RM im Gegensatz zu CCU3 (bei gleichem Firmwarestand) solche "krummen Dinger" anzeigt müsste dann @jmaus klären.

Auf jeden Fall wieder was gelernt, danke dafür und Sorry für die "Aufregung". :wink:

Grüße, Baxxy

TomMajor
Beiträge: 1714
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 162 Mal
Danksagung erhalten: 365 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 03.04.2022, 15:34

Baxxy hat geschrieben:
03.04.2022, 13:55
Hallo TomMajor,
ich hatte das schon verstanden auch wenn es vielleicht nicht so rüber kam.
Bin aber trotzdem mal 1 Jahr (3.57.5) zurück um zu gucken ob da was anders war, also ob vielleicht ein...
TomMajor hat geschrieben:
03.04.2022, 00:09
sinnvolles Runden
... stattfand. Dem ist nicht so. Also war es wohl doch "schon immer so" und fiel nur nie auf.

Warum RM im Gegensatz zu CCU3 (bei gleichem Firmwarestand) solche "krummen Dinger" anzeigt müsste dann @jmaus klären.

Auf jeden Fall wieder was gelernt, danke dafür und Sorry für die "Aufregung". :wink:

Grüße, Baxxy
kein Problem und es freut mich dass es doch verstanden wurde und mein Erklärungsversuch nicht ganz für die Katz war :D

Und so was
ich habe seit längerer Zeit 3x den HB-UNI-Sensor1 mit BME280 + MAX44009 auf der HB-UNI-SENS-BATT unauffällig am laufen.
hört man als Entwickler auch gern und def. lieber als Fehlerberichte :wink:
Viele Grüße,
Tom

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“