OH 4.x: Umstellung der Items auf UoM

[nw378]

Hallo Mitstreiter,

ich habe die meisten meiner Items um UoM ergänzt.

An zwei Stellen komme ich nicht weiter:

1) Ich habe letztes Jahr einen neuen Stromzähler bekommen. Um den Verbrauch in der Datenbank fortlaufend darzustellen, addiere ich in einer Rule zum Zählerstand den letzten Stand des alten Zählers.

Zuvor sah das so aus:

Code: Alles auswählen

rule "" when ... then 
Stromzaehler_kWh.postUpdate(Stromzaehler.state as DecimalType + 1234)

Seit die beiden Items UoM haben, wird der Wert für Stromzaehler_kWh nicht mehr angepasst. (aber auch keine Fehlermeldung)

Augenblicklich bin ich soweit gekommen, ein weiteres Item mit dem alten Zählerstand zu nutzen, und dies mittels dieser Regel zu verrechnen:

Code: Alles auswählen

Stromzaehler_kWh.postUpdate(Stromzaehler.state as QuantityType<Number> + Zaehler_alt.state as QuantityType<Number>) //für influxdb Zählerstand_alt addieren

Sieht nicht schön aus, klappt aber irgendwie.
Jedoch mäkelt VSC dies als Error an und im Log erscheinen zunächst auch Fehlermeldungen, irgendwann geht's dann trotzdem.
Kann also nicht richtig sein. Wie also tun?

2) Meine Wetterstation (KNX) misst den Wind in m/s. Alle anderen KNX-Werte (Temperaturen,...) funktionieren als UoM. Die Windgeschwindigkeit leider nicht.
Ich habe .things als Number mit DPT9.005 angelegt.

Sobald ich das Number-Item um ":Speed" ergänze, wird mir als state UNDEF angezeigt.

Code: Alles auswählen

Number:Speed Wind_ms       "Wind [%.2f m/s]" {channel="knx:device:bridge:wetterstation:wind", unit="m/s", stateDescription=""[pattern="%.1f %unit%"]}

Wo steckt hier der Fehler?

[udo1toni]

Code: Alles auswählen

Stromzaehler_kWh.postUpdate(Stromzaehler.state as QuantityType<Energy> + 1234|kWh)

sollte funktionieren, alternativ

Code: Alles auswählen

Stromzaehler_kWh.postUpdate(Stromzaehler.state as QuantityType<Energy> + 1234|"kWh")

Was die Sache mit der Geschwindigkeit betrifft,, es gibt entsprechende Tests, die automatisch beim Build ausgeführt werden, was bedeutet, dass irgendwas in Deiner Konfiguration nicht korrekt ist. Kannst Du den Channel mal zeigen?

EDIT:

Du könntest spaßeshalber mal das knx Log auf TRACE stellen und schauen, was passiert, wenn der Channel einen Wert empfängt. TRACE wirft einiges mehr an Informationen aus, speziell, wenn es um UoM geht.
Allerdings könnte es auch passieren, dass Du von den Meldungen erschlagen wirst, dann müsstest Du im Zweifel alle knx Things "pausieren" bis auf das mit DPT 9.005, damit Du noch eine Chance hast, die betreffenden Zeilen zu finden.

[nw378]

Besten Dank, beide Probleme gelöst.

Bei der Geschwindigkeit sieht das .things so aus:

Code: Alles auswählen

Type number           : wind           [ ga="9.005:<0/3/0"  ]

Ein Neustart von openHAB hat's hier gebracht. Zuvor hatte ich nur das Binding neu gestartet.

Der Stromzähler: QuantityType<Energy> hat zum Ziel geführt.
EDIT: klappt immer noch nicht ganz. VSC spuckt folgende Fehlermeldung aus, bezogen auf das postUpdate:

Code: Alles auswählen

Ambiguous feature call.
The extension methods
	postUpdate(Item, State) in BusEvent and
	postUpdate(Item, Number) in BusEvent
both match.(org.eclipse.xtext.xbase.validation.IssueCodes.ambiguous_feature_call)

[udo1toni]

Ja, sehr nervige Fehlermeldung. Der Punkt ist, dass es zwei Methoden gibt, die die angebotenen Daten verarbeiten können, und die daten können so oder so interpretiert werden.
Gewöhnlich nutze ich dann eine lokale Konstante:

Code: Alles auswählen

val Number sum = Stromzaehler.state as QuantityType<Energy> + 1234|kWh
Stromzaehler_kWh.postUpdate(sum)

Tatsächlich ist QuantityType ein Teil von Number, sollte also funktionieren. Kann aber sein, dass der ambiguos feature call bleibt, dann muss man halt etwas mit den Datentypen experimentieren Mein Tipp dabei: reduziere die Rule auf das absolute Minimum, so dass Du nicht durch eventuell an anderer Stelle auftretende Fehler die Lösung beim Ausprobieren verpasst.

[nw378]

Der Workaround zum workaround mit der Number klappt.

Klar, ist das eine feine Sache mit den UoMs, gerade was das Umrechnen von Watt in kW und m/s in km/h anbelangt; für die rules ist es aber nicht der smarteste Weg. Vielleicht bessern da ja OH 4.1 oder 4.2 mal nach...

[udo1toni]

Nein, ich fürchte, das wird so bleiben, dieser pita besteht ja schon seit OH2.4 und wurde rege beklagt.
Das Problem ist hier, dass niemand auch nur den leisesten Schimmer hat, wie man es eleganter lösen könnte (also vor allem mit vereinfachter Syntax).