Berechnung Temperaturdifferenz in OpenHab 2.4 + weitere Probleme mit Temperaturwerten

[wknx]

Nabend zusammen,

eigentlich will ich nur was ganz einfaches machen: Die Differenz von zwei Temperaturwerten berechnen.

Normalerweise sollte das nicht schwer sein, aber ich suche inzwischen seit Wochen immer mal wieder nach einer Lösung und die Beispiele die man im Internet (u.A. auch in der OpenHAB) so findet funktionieren allesamt nicht und liefern nur verschiedene Fehlermeldungen im Log beim Umwandeln Item-States in einen numerischen Wert. Das ist ziemlich frustrierend :-(

Offensichtlich wurde beim Umgang mit einheitenbehafteten Größen immer mal wieder was geändert zwischen den OpenHab-Versionen, was auch erklären könnte dass alle Beispiele die vor 2.4 herauskamen nicht mehr funktionieren. Nur wo finde ich ein aktuelle und vollständige Dokumentation für die DSL der Rule-Engine und zum Umgang mit dem Typensystem; bevorzugt als ein anständiges Referenzwerk.

Beim Versuch Soll-Temperaturwerte über Paper-UI zu ändern gibt es auch Fehler:
[WARN ] [ematic.handler.HomematicThingHandler] - Can't convert type QuantityType with value '17.5 °C' to FLOAT value with DecimalTypeConverter for 'OEQxxxxxxx:4#SET_TEMPERATURE', please check the item type and the commands in your scripts

Könnt Ihr mich da erleuchten?

Gruß
Wilhelm

[broccoli]

Die einfachste Lösung ist, die Items weiterhin als Number und nicht als Number:Temperature zu definieren. Kommt das für dich in Frage?

[wknx]

tems weiterhin als Number und nicht als Number:Temperature

Wo würde sich das denn bemerkbar machen?

[broccoli]

Du könntest die Werte eben so eingach wie früher verwenden, also z. B.

var wert = WohnzimmerIstTemperatur as Number

...oder wie immer du das bisher gemacht hast. So hab ich es auch gelöst. Die QuantityTypes haben mir nur Ärger gemacht, insbesondere bei Werten mit Dezimalstellen, ohne dabei irgendeinen Vorteil gebracht zu haben.

[wknx]

broccoli vielen vielen Dank. Jetzt funktioniert es endlich! Erinnere mich nun sogar dunkel dran, dass ich Number:Temperature sogar zur Fehlerbehebung für das Problem beim Einstellen der Temperatur eingestellt hatte

So schaut das ganze nun aus:

rule "temperature_12_delta"
when
    Member of gRtr12sollIst changed
then
    val ist  = temp12ist.state  as Number
    val soll = temp12soll.state as Number
    val Number delta = ist - soll
    rtr12delta.postUpdate(delta)
end

Für Vorschläge wie es besser geht bin ich offen. Da die Berechnung mehrfach erfolgen soll schaue ich auch noch mal ob man das nicht eine Funktion zusammenfassen kann…

[broccoli]

Freut mich, dass ich helfen konnte. Deinen Code müsste man eigentlich so vereinfachen können – wobei ich das aber nicht ausprobiert habe:

 
 rule "temperature_12_delta" when     Member of gRtr12sollIst changed then     rtr12delta.postUpdate(temp12ist.state - temp12soll.state) end

Wobei ich das Delta andersrum rechnen würde – also Soll minus Ist, aber das vielleicht Ansichtssache.

[wknx]

Deinen Code müsste man eigentlich so vereinfachen können

Die Möglichkeit hätte ich tatsächlich auch gesehen, will mir aber auch gerne noch die Option offen halten eine Log-Ausgabe zu schreiben (hätte ich erwähnen sollen).

Das würde sich eben alles durch die Zusammenfassung in einen Funktionsaufruf sauber zentral einmalig abbilden lassen:

// Beispiel in Pseudocode
static private Number deltaTempUpdate(Item ist, Item soll, Item delta, String label) {
    val Number tDelta = (ist.state as Number) - (soll.state as Number)
    delta.postUpdate(tDelta)
    // write log
    return tDelta
}

Die Berechnung hatte ich zunächst auch erst anders herum durchgeführt, für den vorgesehenen Anwendungsfall scheint es mir allerdings in der aktuellen Form allerdings doch intuitiver:
postiver Wert = zu warm
negativer Wert = zu kalt

[wknx]

Funktionsaufruf werde ich wohl auch eher vertragen, falls nicht noch eine spontaner Vorschlag zur Lösung kommt.

Die Lösung die ich unter https://community.openhab.org/t/rule...approach/46603 gefunden hatte scheint zwar von der Funktionsdefinition her zu funktionieren. Beim Aufrufversuch zeigt mir VSCode allerdings schon eine Fehlermeldung :-|

Funktionsdefinition:

val Procedures$Procedure4<NumberItem, NumberItem, NumberItem, String>
deltaTempUpdate = [ thisTempIstItem, thisTempSollItem, thisTempDeltaItem, thisLabel |
    val ist  = thisTempIstItem.state  as Number
    val soll = thisTempSollItem.state as Number
    val Number delta = ist - soll
    thisTempDeltaItem.postUpdate(delta)
    logInfo(logName, "temp"+thisLabel+"delta: " + delta + "  ist:"+ist + " -> soll:"+soll)
]

Aufruf mit

deltaTempUpdate(temp12ist, temp12soll, rtr12delta, "12")

zeigt den Fehler

"Invalid number of arguments. The field deltaTempUpdate is not applicable for the arguments (NumberItem,NumberItem,NumberItem,String)"

[udo1toni]

Ich nutze selbst keine Lambdas als Funktion, soweit ich mitbekommen habe, gibt es aber in der aktuellen Version von openHAB eine einfachere Möglichkeit, ide Funktion zu definieren. Ansonsten müsste man noch einen Import machen, damit man diese Art Definition nutzen kann.

[wknx]

Ich nutze selbst keine Lambdas als Funktion, soweit ich mitbekommen habe, gibt es aber in der aktuellen Version von openHAB eine einfachere Möglichkeit, ide Funktion zu definieren. Ansonsten müsste man noch einen Import machen, damit man diese Art Definition nutzen kann.

Danke für die Idee. Müsste ich mir bei Gelegenheit mal anschauen. Falls man dort dann direkt Java nutzen kann wäre mir das auch gar nicht mal so unrecht, da mit der DSL der Ruleengine irgendwie bislang nicht so richtig warm werde, vor allem wenn man den Umfang der Dokumentation und dauerhafter Stabilität so anschaut…

[udo1toni]

Ehrlich gesagt ist bisher die DSL der stabilste Teil von openHAB (im Sinne von Nachhaltigkeit). Nicht, dass nicht immer mal wieder was dazu gekommen wäre.

Direktes Java geht aber nicht. Die einzige Alternative zur DSL wäre JSR232 (oder natürlich die neue Rule Engine).