Prozentwert / KNX 5.001 geändert mit Openhab4?

[Bkkm]

Hallo,

nach einem Update ist mir folgendes Verhalten aufgefallen: Meine KWL sendet die aktuelle Lüftungsstufe in Prozent (DPT 5.001). Im Busmonitor sehe ich:

DPT: 5.001Prozent (0% .. 100%).
Info: %7F | 50%

Thing / Item in Openhab sind

Thing: Type number:lueftungsstufe [ ga="5.001:<5/2/4" ]
Item: Number KwlLueftungsstufe { channel="knx:device:bridge:kwl_1_0_29:lueftungsstufe" }

In Openhab kommt der Wert 49.80392156862745 an (Vermutung: 0x7F / 0xFF = 127 / 255 = 0,4980...)

Erweiterung des Item mit Unit macht keinen Unterschied.

Number:Dimensionless KwlLueftungsstufe{ channel="knx:device:bridge:kwl_1_0_29:lueftungsstufe", unit="%" }

In vorherigen Versionen kam da noch die exakte 50% an.

Hat sich was geändert? Muss ich was ändern? Hab ich nen Bugf gefunden?


Grüße
Björn

[udo1toni]

Die Frage ist, ob die in ETS gemeldeten 50 % tatsächlich korrekt sind. Aus der knx-Definition:

ID:	Name:	Range:	Unit:	Resol.:	PDT:	Use:
5.001	DPT_Scaling	[0…100]	%	≈ 0,4 %	PDT_SCALING (alt.: PDT_UNISIGNED_CHAR)	G

Schon die ≈ 0,4 % stimmen halt nur näherungsweise. rechnerisch (Anzahl Nachkommastellen und nächstgelegener Wert zu 50 %

	1	2	3	4
1	0,4 %	0,39 %	0,392 %	0,3922 %
127	50,8 %	49,53 %	49,784 %	49,8094 %
250	100 %	97,5 %	98 %	98,05 %
255	102 %	99,45 %	99,96 %	100,011 %
256	102,4 %	99,84 %	100,352 %	100,4032 %
257	102,8 %	100,23 %	100,744 %	100,7954 %
50%	125	128 (49,92 %)	128 (50,176 %)	127 (49,8094 %)

Die 50 % erscheinen also einfach grundsätzlich falsch jedenfalls wenn man mathematisch korrekt an das Problem herangeht.
Also mag ETS hier 50% anzeigen, per EIBA-Definition ist das aber nicht korrekt.
Die Diskussion ist eher akademischer Natur, da man die Lüfterstufe besser mit einem Dimmer Item verbindet (es sei denn, es handelt sich um eine reine Anzeige).
Am einfachsten begrenzt Du die Anzeige der Nachkommastellen auf 0 (State Description Pattern auf %.0f % einstellen)

[Bkkm]

Hallo,

Deine Ausführungen zur ETS kann ich nachvollziehen. Meines Erachtens werden in der ETS bei dem 5.001 nur Ganzzahlen ausgegeben. 0x7F wird zu 50%, 0x80 auch, 0x81 zu 51%.

Trotzdem bin ich der Meinung, dass sich das Verhalten in OpenHab beim Umsteig auf die Version 4 verändert hat.

Bisher wurde der Wert 0x7F (aka 50%) in OpenHab zu 0,5. Das habe ich sowohl in der Visualiserung gesehen als auch in Grafana. In der Sitemap habe ich zur Darstellung den Wert mit 100 multipliziert, dann wurde er mit 50% dargestellt.

In der aktuellen Version wird wie gesagt 49,... empfangen. Kann ich mit leben, würde ich dann halt mathematisch runden.

Aber in rules ist das ja schon ein Problem, da man eventuell Berechnungen ändern muss. Insofern macht es mich stutzig, dass sich da anscheinend das Verhalten geändert hat. Auch bei anderen Datentypen?

Grüße
Björn

[holgerf]

Hallo Bkkm,
für OH Version 4 haben wir die KNX Integration stark überarbeitet. Zu DPT 5.001 gibt es auch noch einen Eintrag in der README wg. des Datentyps:

> Attention: With the introduction of Unit of Measurement (UoM) support, some data types have changed (see number channel below):
Data type for DPT 5.001 (Percent 8bit, 0 -> 100%) has changed from PercentType to QuantityTypefor number channels

Generell wurde vermieden, eingehende Werte zu Runden - sowohl in Binding als auch im openHAB core. Da gab es schon Probleme, dass auf den Bus gesendete Werte von den empfangenen Werten abwichen.
Mit geeigneter State Description sollte es klappen (hoffe, die rundet auch richtig 🙈).

Umstellung der Datentypen in OH4 betrifft des Weiteren 5.004, 6001, 9.007.
Wie es mit der Rundung der Werte aussieht, kann ich gerade aus dem Stand nicht mehr sagen. V.a. bei Berechnung von Farbwerten hat sich da einiges getan.
VG

[netzlaff]

Habe mit dem Update von 4.2.x auf 4.3.2 auch Probleme mit den Ganzzahl-%-Werten. Ich habe ein paar Rules, welche auf 0, 50 und 100% reagieren, nun aber nicht mehr funktionieren, da anstatt 50 nun 50,196 und für 100 nun 99,608 ankommt.

Wie könnte man hier die Werte wieder als Ganzzahl ablegen, bzw. abfragen?

Danke

[udo1toni]

Das kann ich hier nicht nachvollziehen. Um welchen exakten DPT handelt es sich denn?

Grundsätzlich: z.B. DPT 5.001 ist 0% - 100 %, wobei es sich um 256 Schritte handelt. 0 -> 0 %, 255 -> 100 %
oder als Formel WertP = WertI / 2,55 und umgekehrt WertI = WertP * 2,55.
Daraus ergibt sich, dass es keine "geraden" Prozentwerte geben kann, außer 0 %, 20 %, 40 %, 60 %, 80 % und 100 %. Wenn der Wertgeber die 255 nicht nutzt, ist das mutmaßlich ein Fehler des Wertgebers.
Ansonsten ist es vermutlich sinnvoller, statt auf Gleichheit, auf einen Bereich zu testen. Du kannst den Wert auch vor dem Vergleich runden.

[netzlaff]

5.001 nutze ich für den Status meines Garagentors. Habe Rules für 0% und 100%, seit dem Update wie geschrieben gibt es keine 100% mehr. Daher mein Post hier.

[udo1toni]

Wie sehen die Rules aus?

[netzlaff]

Habe die Rule nun erstmal dementsprechend abgeändert, dass ich einen Item Change abfrage mit value>=99:

configuration: {}
triggers:
- id: "1"
configuration:
itemName: ACT1_1_111CH4
type: core.ItemStateChangeTrigger
conditions:
- inputs: {}
id: "4"
configuration:
itemName: ACT1_1_111CH4
state: "99"
operator: ">="
type: core.ItemStateCondition
actions:

Vorher war der Trigger change to value=100 ohne Bedingung.

Nur nicht so schön mehr, dass beispielsweise auf meinen Wand-Panel der Status vom Garagentor nun 99% zeigt :/

[udo1toni]

Wie kommt denn der Wert überhaupt zustande? Also, was ist das für ein Torantrieb, der einen knx-Anschluss hat? Oder handelt es sich bei dem knx-Anschluss um ein Modul, welches nachgerüstet wurde?

[netzlaff]

Den Wert schreibe ich per Arduino auf den Bus, habe meine eigene Steuerung für den Antrieb gemacht. Der kennt drei Zustände, 0%, 50% und 100%. Der Arduino hängt am Taster-Interface vom Antrieb, bildet also eine Schnittstelle zwischen KNX und Antrieb.

[udo1toni]

Dann ist der Code im Arduino falsch 50% gibt es per Definition bei 5.001 übrigens nicht (habe ich oben erläutert)..

[netzlaff]

Auf einmal sendet mein Arduino was falsches? Ähm ja.. vermutlich sendet er den gleichen Wert wie vorher auch. Wobei 50% für mich keine Rolle spielt, das Problem ist eher die 100%. Geschrieben werden 128 für 50% und 254 für 100%
Aber gut, anscheinend wurde was in OpenHAB geändert, was nun zu diesen "Phänomen" führt. Muss ich sehen, an welcher Stelle ich was ändere, damit es wieder läuft.

[udo1toni]

Ja, 100 % ist eben nicht 254, sondern 255. Dein Arduino hat noch nie 100 % gesendet, sondern immer ~99,607 %, nur hat openHAB es bisher nicht feiner als in vollen % aufgelöst und entsprechend gerundet.

[netzlaff]

Das wollte ich hören, also wurde doch was an der internen Verarbeitung in OpenHAB geändert. Gut, dann ist dir Ursache ja soweit klar.
Dann werde ich den Code vom Arduino mal ändern und schauen, was passiert.
Danke.