OpenKNX-Sensormodul release

[Alloc]

Hi, hab gerade den Präsenz-Multisensor von AB-SmartHouse aufgebaut und mal im Testbetrieb. Beim Vergleich der Sensorwerte ist mir aufgefallen, dass der Luftdruck vom BME680 scheinbar mit der falschen Einheit ausgegeben wird? Aktuell meldet er 999,68 Pa. Passend wäre hier hPa, das bietet die ETS/KNX DPT aber natürlich nicht. Da das KO nun aber von Haus aus auf Pa steht, sollte der Wert nicht entsprechend gesendet werden, sprich 99968 Pa?

PS: Ich bin mir nicht ganz sicher, ob das der richtige Thread ist oder eher der Thread zur HW. Aber da das ja denke eher eine FW-Frage ist hab ich mal diesen hier genommen

[mumpf]

Du hast zwar Recht, aber ich hab es trotzdem mit Absicht gemacht. Der Punkt ist, dass so große Werte als DPT9 nur sehr ungenau dargestellt werden können. Deswegen hab ich mich damals entschieden, den Wert kleiner und dafür genauer auszugeben. Deswegen steht da auch "Luftdruck (in mBar)".

Derzeitiger Workaround, wenn Du wirklich Pa haben willst: Multipliziere den Wert im Logikmodul * 100. Dann wirst Du auch erkennen, warum ich nicht diesen Weg gegangen bin.

Gruß, Waldemar

[Alloc]

Ah, hab hier im Forum gesucht und in der App in den Kontexthilfen. Die Beschreibung des KO ist mir durch die Lappen gegangen
Aber die Aussage zum DPT9 verstehe ich nicht. Es wird ja als Float kodiert, also bleibt die Mantisse - und somit der "Detailgrad" der Zahl - immer auf 11 Bit (+ Sign-Bit) beschränkt. Wie weit der Wert dann durch den Exponent verschoben wird spielt dabei doch keine Rolle?

[mumpf]

Hi Chris,

es ist ja kein 10er Exponent, sondern ein 2er Exponent.
Probiere es einfach aus... wenn Du in der ETS eine Zahl mit DPT9 sendest, sieht man sehr gut die Abweichungen zwischen der eingegebenen und gesendeten Zahl.

Nachtrag: 2 Beispiele...

• 999,98 auf den Bus geschrieben, angekommen ist 999,68
• 99998 auf den Bus geschrieben, angekommen ist 100024,3

Gruß, Waldemar

[Alloc]

Naja, klar gibt es beim Kodieren von Dezimalzahlen aus dem Dezimalsystem im Binärsystem Abweichungen. Deine Beispiele zeigen das aber auch schon recht gut: Wenn wir einen Ausgangswert von 99998 Pa zugrunde legen und in beiden Varianten senden wollen:
- 999,68 -> Abweichung von 999,98: -0,030%
- 100024,3 -> Abweichung von 99998: +0,026%
Das ist halt das Problem bei Floats: Die Auflösung wird nur durch die Mantisse bestimmt. Abweichung hat man also bei Zahlen, bei denen die signifikanten Stellen größer als der Wertebereich der Mantisse sind, immer. Und bei dem 2 Byte Float mit 11 Bit Mantisse gilt das eben ab 2048.
Man gewinnt hier also nichts durch die "falsche" Verwendung des DPT, aber man schafft Verwirrung und ärgert zum Beispiel auch externe Systeme, die die DPT aus der ETS zur weiteren Interpretation hernehmen.

Wenn es wirklich weniger Abweichung vom Messwert geben soll müsste man halt entweder auf 14.058 ausweichen - mit entsprechend höherer Buslast (wobei wir hier von 88 zu 104 Bits reden, also "nur" ein Overhead von 18% bei Telegrammen, die tendenziell eher selten auf den Bus kommen, da der Luftdruck nun nicht gerade alle 3 Minuten anders ausfällt).

Letztlich kann ich mich natürlich auch mit dem aktuellen Stand arrangieren - und wie du schon sagtest auch den Wert in der Logik konvertieren. Aus meiner Sicht ist das hier aber wirklich ein Bug der niemandem einen Vorteil bringt

[Ing-Dom]

beim THPSensor, also SEN-UP1, hab ich das korrigiert. Wir hatten das ja auch schonmal diskutiert Waldemar. Ich seh das nämlich wie Chris..
die absolute Abweichung ist zwar größer, aber relevant ist die prozentuale Abweichung, und die ist unabhängig und nur von der Mantisse bestimmt.

[henfri]

Ich sehe das auch so. Vor allem wäre aber auch Konsistenz wichtig.

[korpa]

Ich hatte das beim SEN-UP1 damals reportet (https://github.com/OpenKNX/SEN-UP1-8xTH/issues/4), da man das entweder mit einer Logik korrigieren musste (wie Waldemar auch damals schon angemerkt hatte) oder aber irgendwie in Dritthersteller-Software, die sich an den Standard halten und beim DPT9 halt einfach hPa erwarten.
Ich bin froh, dass Dominik das nun korrigiert hat. Denn für eine so kleine prozentuale Abweichung den Standard zu brechen, finde ich unglücklich.

[mumpf]

Ich werde das ja anpassen. Ich wollte ja nur den aktuellen Workaround schreiben.

Gruß, Waldemar

P.S.: Kommt im nächsten Release...

[junibart]

Hallo in die Runde,
ich hab auch zwei Raum-Sensormodule am laufen. Danke an dieser Stelle an mumpf und alle anderen, die hier entwickeln!
Ich bastel schon seit Jahren mit verschiedenen VOC-Sensoren herum, die bei dicker Luft in Bad oder Küche die Lüftung hochdrehen sollen. IAQ Core, CCS811, BME680 ... richtig zufrieden war ich nicht.
Jetzt habe ich mal (mit ESPHOME, das diesen Sensor schon kennt) den Sensirion SGP40 getestet und bin von den Ergebnissen positiv überrascht. Der Sensor liefert einen Qualitäts-Indexwert zwischen 0 und 500, wobei 100 dem Durchschnittswert einer definierten Zeitspanne entspricht. Das erscheint mir für die Lüftungssteuerung oder eine Luftgüteampel gut geeignet.
Wäre es denkbar, diesen Sensor der Firmware/Applikation als Auswahlmöglichkeit hinzuzufügen? Ich stelle auch gern einen Sensor für die Entwicklung zur Verfügung.
Grüße,
Gunnar

[henfri]

Hallo Gunnar,

das klingt interessant.
Hast du mal Vergleichsdiagramme für uns?

Ich versuche mal deine Frage zu beantworten:
- Die Frage ist, welcher Energiebedarf. Da hab ich die gefunden:

Versorgungsspannung	1.7 - 3.6	V
Durchschnittlicher Versorgungsstrom	2600	uA
Max. Versorgungsstrom	3000	uA
Schnittstellen	I²C

- Dann ist natürlich auch die Frage, ob die Breakout-Boards Pin-Kompatibel zu einem vorhandenen Anschluss sind
- Und die Frage, ob eine bestimmte Library nötig ist --> GitHub - Sensirion/arduino-i2c-sgp40: The SGP40 is Sensirion’s new digital VOC

Gruß,
Hendrik

[Masifi]

Dann ist natürlich auch die Frage, ob die Breakout-Boards Pin-Kompatibel zu einem vorhandenen Anschluss sind

Für die Zwischenplatine gibt es passende Boards vom SPG40 bei Ali. Steckbar möglich wäre eine Kombination aus BME280/680 + SCD40 + SPG40.

[junibart]

Ich zeichne gerade Daten auf. Der Sensor wird heute sicher noch Zeuge einiger olfaktorischer Ereignisse sein, und dann liefere ich hier die Diagramme im Vergleich zum BME680. Die Kombination mit dem BME280 wäre sicher sinnvoll, denn die Qualität der Messung kann man wohl durch die Erfassung von Temperatur und Feuchtigkeit noch verbessern. Allerdings müssen diese Werte dem SGP40 über den i²c-Bus zugeführt werden, was dann Aufgabe der Firmware wäre.

[junibart]

So, ich hab hier mal zwei Diagramme von Hand zur Deckung gebracht, der BME680 gibt ja einen ppm-Wert aus, der SGP40 einen Indexwert (im Diagramm 0-500). Der Wertebereich ist allerdings vergleichbar. Beide Sensoren befinden sich in demselben Raum, ca. einen Meter voneinander entfernt.
Jetzt ist die Frage, welche Werte sind richtig... meine subjektive Einschätzung ist, dass der SGP40 den Wahrnehmungen meiner Nase weitaus mehr entspricht. Ich würde die Überschreitung der 100 direkt zur Erhöhung der Lüftungsleistung verwenden.

SGP40-bme680.png

[mumpf]

Hi,

grundsätzlich kann ich mir vorstellen, den Sensor auch mit aufzunehmen. Kommt aber etwas auf Deine Zeitvorstellung an. Wenn Du so einen Sensor zur Verfügung stellen willst, könnte ich die Funktionalität implementieren. Wie gut die Werte dann verwertbar sind, kannst Du ja dann testen...

Gruß, Waldemar