Wert für Luftfeuchte ist falsch

[tallman]

Hallo,

ich habe einen KNX Feuchtigkeitssensor, der stellt den Feuchte Wert im Datentyp 9.007 bereit. Das sollte ja eine Anzeige von 0 .. 100 % ergeben.
Im KNX Busmonitor macht es das auch korrekt.
In Openhab wird aber 0,xxxx angezeigt , hat jemand eine Idee was ich falsch mache ?

Things:

    Thing device IO_Gaeste "LJ" @ "GZ" [
        address="1.1.16",
        fetch=false
    ] {
        Type number        : Gaeste_Feucht    "Gästezimmer" [ ga="9.007:<5/1/17" ]
    }

Item

Number Gaeste_Feucht "LJ Gäste Luftfeuchte [%.2f]"    { channel="knx:device:bridge:IO_Gaeste:Gaeste_Feucht" }

[udo1toni]

Du machst vermutlich nichts falsch. Die Umsetzung auf % wird hier einfach schief gehen. (es ist aber auch höchst fragwürdig, warum man eine Prozentzahl als 16 Bit Float darstellen will - mit einer Obergrenze von 670.760%... wer ist auf diese Definition gekommen? Und auch die Auflösung von 0.001% ist unrealisitisch, sogar unter Laborbedingungen.)
Du wirst wahrscheinlich zu einer rule und einem Proxy Item greifen müssen, um die Darstellung in einen korrekten Wertebereich umzusetzen. Evtl. ginge was mit einem Profile, aber das habe ich selbst noch nicht verwendet. Die Theorie ist, Du fügst hinter dem channel noch ein Profile hinzu, z.B. mit JavaScript. Dann kann das verlinkte Script die Werte korrigieren, bevor sie im Item landen, ungefähr so:

Number Gaeste_Feucht "LJ Gäste Luftfeuchte [%.2f]" { channel="knx:device:bridge:IO_Gaeste:Gaeste_Feucht" [profile="transform:JS", function="multiplyBy100.js", sourceFormat="%.4f"]}

und das Script multiplyBy100.js:

(function(i) {
    return i*100;
})(input)

Ich bin mir nicht sicher, ob die Umrechnung korrekt ist, ich bin mir noch nicht mal sicher, ob der Input nicht zuerst von String nach Number geparsed werden muss...

[tallman]

Hallo udo1toni,

danke für deine Antwort, warum man in KNX für eine Prozentzahl einen 16 Bit Float Wert nimmt, weiß ich auch nicht, ist aber nun mal leider so.
Bei der Temperatur wird ja auch 16 Bit Float genommen und da klappt es mit dem Datentyp 9.001.
Wenn ich den Datentyp 9.001 nehme oder ganz weglasse. führt das auch nicht zum Erfolg.
Komisch ist nur, das es im KNX-Busmonitor richtig angezeigt wird .
Mit der Transformation klappt es auch nicht, da habe ich es erstmal mit einem ProxyItem gelöst, aber unschön ist es trotzdem.

[BoobFrog]

Guten Abend / Morgen zusammen,

habe das gleiche Problem, gibt es dazu inzwischen eine Lösung?

Grüße

[udo1toni]

Du kannst versuchen, ein Dimmer Item zu verwenden. Ich habe das Problem bei mir nicht, meine aber, mich daran zu erinnern, dass man das als Workaround gefunden hat.

[tallman]

So geht es jetzt bei mir :

Type number        : Keller_Feucht    "Keller"     [ ga="9.001:5/1/31" ]

item:

Number Keller_Feucht "Keller Luftfeuchte [%.1f %%]"    <humidity>    (Keller, Heizung3)  ["Humidity", "Measurement"]  { channel="knx:device:bridge:IO_LJ:Keller_Feucht" }

[BoobFrog]

Danke werde ich nachher Mal testen und berichten!

[BoobFrog]

Vielen Dank! läuft!

[SirTobiIV]

Hallo,
stehe vor dem gleichen Problem. Leider funktioniert es bei mir nicht wie oben beschrieben.
Das Thing ist folgendermaßen defioniert:

Thing device temperatures [
        address=""
    ] {
        Type number : Temp_Wohnen "Wohnzimmer"     [ ga="<3/0/30" ]
       
        Type number : Hum_Wohnen "Luftfeuchte Wohnzimmer" [ ga="9.001:3/5/30" ]
    }​

Ich Log erhalte ich die Fehlermeldung:

2023-01-22 13:02:31.674 [WARN ] [nx.internal.client.AbstractKNXClient] - Error reading datapoint 3/5/30: DPT 9.007 Humidity: data length 1 < required datapoint type width 2
2023-01-22 13:02:31.678 [INFO ] [g.knx.internal.dpt.KNXCoreTypeMapper] - Translator couldn't parse data for datapoint type '9.001' (KNXIllegalArgumentException).
2023-01-22 13:02:31.683 [WARN ] [.internal.handler.DeviceThingHandler] - Ignoring KNX bus data: couldn't transform to any Type (destination='3/5/30', datapoint='command DP 3/5/30 'knx:device:bridge:temperatures', DPT 9.001, low priority', data='0x78')
​

[udo1toni]

Eigentlich ist die Meldung eindeutig. Das ankommende Datum passt nicht in den angegebenen Datentyp. Das bedeutet, die Gruppenadresse ist nicht mit einem Kommunikationsobjekt verbunden, welches DPT 9.001 liefert.

[SirTobiIV]

Naja, das hatte der Kollege oben ja extra so als Workaround empfolen. Ja, es ist richtig, dass die Luftfeuchte vom Typ 9.007 ist.

Wenn ich den Datentyp weglasse, dann kommt leider ebenfalls kein Wert an. Openhab zeigt "NULL" beim Item.

 Type number : Hum_Wohnen "Luftfeuchte Wohnzimmer" [ ga="<3/5/30" ]

Ebenso, wenn ich den korrekten Datentypen 9.007 eintrage.

 Type number : Hum_Wohnen "Luftfeuchte Wohnzimmer" [ ga="9.007:<3/5/30" ]

Das Log sagt in beiden Fällen.
Ich habe aber keine Ahnung, warum hier wieder der Datentyp 9.001 auftaucht?

2023-01-23 21:38:18.695 [INFO ] [g.knx.internal.dpt.KNXCoreTypeMapper] - Translator couldn't parse data for datapoint type '9.001' (KNXIllegalArgumentException).
2023-01-23 21:38:18.700 [WARN ] [.internal.handler.DeviceThingHandler] - Ignoring KNX bus data: couldn't transform to any Type (destination='3/5/30', datapoint='command DP 3/5/30 'knx:device:bridge:temperatures', DPT 9.001, low priority', data='0x80')
​

grafik.png

[udo1toni]

Was ist das denn für ein Gerät?

[SirTobiIV]

Also der Fehler scheint etwas tiefer zu liegen. Der Sensor ist eigentlich ein 1wire-Sensor, der auf den KNX-Bus sendet.
Laut KNX-Busmonitor kommen die Daten interessanterweise als Typ 5.001 (8bit Vorzeichenlos 0-100%-Wert) an, obwohl die Gruppenadresse vom Typ 9.007 in der ETS definiert ist. Aber auch ein 5.001 sollte doch von Openhab gelesen werden können?
Kann mir nicht vorstellen, dass das Openhab KNX-Binding beim Typ "Number" immer eine Temperatur vom Typ 9.001 erwartet?

[udo1toni]

Was in der ETS für ein Datentyp hinterlegt ist, ist abhängig davon, welche KO mit der GA verknüpft sind. 5.001 und 9.007 sind inkompatibel (8 Bit vs. 16 Bit) und eigentlich sollte die ETS das auch bemeckern. Prüfe die Konfiguration in ETS.

Der default DPT für Number ist 9.001, siehe https://www.openhab.org/addons/bindi...el-type-number. Deshalb muss ein abweichender DPT angegeben werden, sofern der Vorkommanteil abweicht ist das auch nicht optional.
Mit der aktuellen Version von knx ist auch UoM implementiert, das wiederum wird über den Nachkommaanteil gesteuert (abhängig vom Haupt-DPT, man muss das also im Zweifel genau nachschauen). Wenn Du DPT 5.001 angibst, sollte bei OH3.4.0 mit einem Link auf Numberimensionless automatisch der korrekte Wert in % angezeigt werden.

[SirTobiIV]

Der default DPT für Number ist 9.001, siehe https://www.openhab.org/addons/bindi...el-type-number. Deshalb muss ein abweichender DPT angegeben werden, sofern der Vorkommanteil abweicht ist das auch nicht optional.

Vielen Dank für diese Info.
Bekomme es mit Datentyp 9.007 trotzdem nicht ans laufen. Im Log erscheint immer die Fehlermeldung:

2023-01-28 17:29:39.243 [INFO ] [g.knx.internal.dpt.KNXCoreTypeMapper] - Translator couldn't parse data for datapoint type '9.007' (KNXIllegalArgumentException).
2023-01-28 17:29:39.249 [WARN ] [.internal.handler.DeviceThingHandler] - Ignoring KNX bus data: couldn't transform to any Type (destination='3/5/30', datapoint='command DP 3/5/30 'knx:device:bridge:temperatures', DPT 9.007, low priority', data='0x7A')

Interessanterweise zeigt aber auch meine VISU dann nur Mist für diesen Wert an. Vielleicht funktioniert schon die Transformation vom 1-wire Sensor auf den KNX-Bus im Fromat 9.007 nicht richtig. Vermutlich habe ich daher auf den Datentyp 5.001 umgestellt.

Mit Datentyp 5.001 kommen jedenfalls Daten in openhab an. Nur leider eben nicht als %-Wert sondern als "Zahl".
Weiß jemand, wie ich am geschicktesten die 0.56 als 56% angezeigt bekomme? Kann ich bei der Itemdefinition dies gleich umrechnen oder muss ich das in der Visu und in den Regeln, wo ich mit dem Wert weitermache jeweils machen?

grafik.png