OpenHAB sendet keine Temperaturwerte an den KNX Bus an mein Dummy-Device

[PascalTurbo]

Hi Leute,

nach einer Migration von OpenHAB 1.X nach 2.4 läuft größtenteils alles prima. Nur ein paar Temperatur-Items wollen nicht richtig funktionieren.

Wenn ich an den Switch "IsDay" ein command schicke (smarthome:send IsDay ON) , sehe ich auch, dass 5/0/2 auf dem Bus ankommt (auch wenn er im OpenHAB Log meckert, dass er eine negative Antwort von 1.1.99 bekommen hat).
Wenn ich aber ein Command an das Temperatur-Item schicke, passiert einfach nichts. Weder im Log eine Fehlermeldung noch auf dem Bus ne Antwort: smarthome:send Kitchen_Temperature_2 22.3


knx.things:

Thing device dummy "Dummy Device" [
        address="1.1.99",
        fetch=false
    ] {
        Type switch  : is_day                  "Tag"                      [ ga="5/0/2" ]
        Type switch  : is_night                "Nacht"                    [ ga="5/0/3" ]
        Type number  : temperature_kitchen     "Temperatur Küche"         [ ga="4/0/2" ]
    }

kitchen.items:

Number:Temperature  Kitchen_Temperature_2   "Temperatur (Tür) [%.1f °C]"      <temperature>  (GF_Kitchen,gTemperature)  {channel="knx:device:bridge:dummy:temperature_kitchen"}
Switch IsDay { channel="knx:device:bridge:dummy:is_day" }

Hat irgendjemand ne Ahnung, was da kaputt sein könnte?

Viele Grüße
Pascal

[PascalTurbo]

Noch ein Hinweis: Mit meiner alten Installation (läuft dann jetzt wieder) sehe ich über den Gruppenmonitor fröhlich die Temperaturwerte auf besagter Adresse eingehen.

[udo1toni]

Du nennst das Device dummy. Ist das jetzt ein echtes Device, welches tatsächlich diese physikalische Adresse hat, oder hast Du die einfach eingetragen? Du kannst die physikalische Adresse jederzeit weg lassen, auch bei echter Hardware, die ist nur interessant, um ein paar zusätzliche Informationen zu bekommen, wenn fetch auf true gesetzt ist. Damit können aber nicht alle Devices umgehen. Wenn es kein echte Hardware ist, ist aber ein physikalische Adresse komplett verboten, das bringt openHAB (bzw. das knx2 Binding) durcheinander.

Was das Number-Problem betrifft: Hast Du mal den korrekten DPT dazu geschrieben? Hast Du schon versucht, number-control zu benutzen?

[PascalTurbo]

Danke @udi1toni. Wusste nicht, dass man die HWAdresse auch weglassen kann.

Die Lösung des Problems ist eine andere: Man hat mal wieder ein Feature eingeführt (Units Of Measurement - UoM) ohne sich Gedanken über die Konsequenzen zu machen. Statt die Unit nur transparent hinzuzufügen hat man gleich den ganzen Typ von "Number" in "QuantityType" geändert. Das führt nicht nur in Regeln zu unnötig kompliziertem Rumgecaste sondern killt auch das KNX Binding, weil das noch nichts von UoM weis. Gott geht mir dieses unkontrollierte Weiterentwicklung von OH auf den Keks.

[trant]

PascalTurbo hast du eine Lösung oder geht das nun einfach nicht mehr?

[udo1toni]

Das geht ganz einfach man muss es nur richtig konfigurieren.

1. knx2 beherrscht (noch?) kein UoM (Units of Measurement). Entsprechend darf man knx2 Channel auch nicht mit Items koppeln, die mit UoM angelegt sind (erkennbar an Number:<Messgröße>)
2. Wenn ein Sensor die Daten schon mit UoM anliefert, muss man den Wert z.B. per Rule von seiner Einheit befreien, bevor man ihn an knx weiter leitet.

Number:Temperature myTempSensor "Temperatur [%.1f %unit%]" { channel="irgendein channel mit UoM" }
Number myKnxTempSink "Temperatur [%.1f °C]" { channel="knx:device:bridge:thing:channel wo die Temperatur hin soll" }

rule "send temp to knx"
when
    Item myTempSensor changed
then
    if(myTempSensor.state instanceof Number)
        myKnxTempSink.sendCommand((myTempSensor.state as Number).floatValue)
end

Wenn man mehrere Sensoren gleichartig umsetzen muss, sollte man die Itemnamen so wählen, dass man aus dem Quellitemnamen den Zielitemnamen errechnen kann, dann reicht eine Rule, um alle Items abzudecken.

[trant]

Danke.

Dann liegt mein Problem wo anders, denn ich verwende gar keine UoMs.

Habe ein Item, welches ich über http befülle:

Number Temperature_AUSSEN_Heizung        "Aussentemperatur [%.2f °C]"                <temperature>        (Heizung, Temperatur)                { http="<[http://192.168.137.48:8080/heizung/heizung.php?REST=/system/sensors/temperatures/outdoor_t1:60000:JS(km200.js)]", channel="knx:device:bridge:SmartTaster_Wohnzimmer_Tuere:Temperature_AUSSEN_Heizung",autoupdate="false"}

    Thing device SmartTaster_Wohnzimmer_Tuere [
        //address="1.0.21",
        fetch=false
    ] {
        Type number        : Temperature_EG_WZ_Taster_Tuere        "Temperature"                             [ ga="9.001:<6/0/122" ]
        Type number        : Temperature_AUSSEN_Heizung            "Temperature"                             [ ga="9.001:6/0/220" ]
    }

Ich bekomme jedoch nichts auf die 6/0/220 geschrieben

Bin auf 2.5.0 Snapshot #1522

[trant]

Hab mal als temporäre Lösung (hoffe die brauch ich nicht für immer) ein zweites Item erstellt, welches dann bei Änderung des Originalitems mittles sendCommand upgedated wird.

[udo1toni]

Welche Version läuft denn bei Dir?

[trant]

2.5.0 Build #1522

[smarthausen]

Hallo zusammen,

dieser Thread spricht mich an: mit viel Zeit und Verrenkungen habe ich unter 2.3 Sensoren eingebunden und diese auf den KNX Bus gesendet. Dann wechselte ich zu 2.4 mit KNX2 und MQTT2 und das ganze Gerödel ging wieder los. Und das Hautproblem dabei war: zuviele neue Konzepte, zu wenig Beispiele. Genau das hat PascalTurbo oben ausgedrückt.

Da ist die Hilfe von udo1toni immer phantatisch! Wobei ich mich immer frage: Woher weißt Du immer solche Details und kannst so klare Aussagen machen? Ich fische im Trüben und errate über die spärliche/nicht vorhandene Dokumentation und verstreute, oft sehr gute, Forenbeiträge eine funktionierende Lösung. Das ist aber keine besonders gute Methode. Und macht auch keinen Spass. Ja, dieses Smarthome mag nicht ganz einfach sein. Aber OpenHAB war schon mal einfacher zu bedienen.

Wenn man mehrere Sensoren gleichartig umsetzen muss, sollte man die Itemnamen so wählen, dass man aus dem Quellitemnamen den Zielitemnamen errechnen kann, dann reicht eine Rule, um alle Items abzudecken.

Das würde mich interessieren: derzeit konvertiere ich mehrere Sensorwerte und schreibe für jeden Sensor dafür eine eigene Rule. Geht das auch schlanker? Ich kann auch einen neuen Thread dafür eröffnen.

An trant ich glaubte optimistisch daran durch eine Flucht in neue Versionen Fehlern zu entrinnen. Nein, dem ist nicht so. Verwende lieber 2.4. Und manchmal denke ich sogar daran, wieder alte Bindings zu verwenden.

OpenHAB macht gerade eine harte Zeit durch, ich bin mir sicher das wird aber wieder. :-)

Viele Grüße an Euch!

[udo1toni]

Das würde mich interessieren: derzeit konvertiere ich mehrere Sensorwerte und schreibe für jeden Sensor dafür eine eigene Rule. Geht das auch schlanker? Ich kann auch einen neuen Thread dafür eröffnen.

Wir können das auch hier abfeiern.

Nehmen wir folgende Items an:

Group gTempIn
Group gTempOut
Number:Temperature TempI_01 "Temperatur 1 [%.1f %unit%]" <temperature> (gTempIn)  { channel="irgendein UoM Temperatur Channel" }
Number             TempO_01 "Temperatur 1 [%.1f °C]"     <temperature> (gTempOut) { channel="knx:device:bridge:thing1:channel" }
Number:Temperature TempI_02 "Temperatur 2 [%.1f %unit%]" <temperature> (gTempIn)  { channel="irgendein anderer UoM Temperatur Channel" }
Number             TempO_02 "Temperatur 2 [%.1f °C]"     <temperature> (gTempOut) { channel="knx:device:bridge:thing2:channel" }

Die Channel habe ich jetzt mal so sortiert, dass In und Out beieinander liegen.

Eine generelle Übersetzungsrule sähe jetzt so aus:

rule "send Temp In to Temp Out"
when
    Member of gTempIn changed
then
    val index = triggeringItem.name.split("_").get(1)
    if(triggeringItem.state instanceof QuantityType<Number>) {                        // Wert ist gültig
        val Number temp = (triggeringItem.state as QuantityType<Number>).floatValue   // Temperatur umsetzen
        gTempOut.members.filter[ i |
            i.name.split("_").get(1) == index
        ].head.sendCommand(temp)
    }
end

Die Rule bestimmt zuerst den Index des Items und speichert ihn in einer Konstanten.
Anschließend prüft sie, ob der neue Wert als gültige Zahl interpretiert werden kann.
Ist das der Fall, interpretiert die Rule den Wert und schreibt das Ergebnis in eine Konstante.
Danach filtert die Rule die OutGruppe nach den Items, deren Index identisch mit dem des Items ist, welches die Rule ausgelöst hat.
Der Filter gibt eine Liste zurück, welche aber nur einen Eintrag enthält.
Das erste Item auf der Liste wird anschließend mit dem Wert befüllt.

Ich habe versucht, die Regel möglichst leserlich zu gestalten, damit auch Nicht-Programmierer eine Chance haben, zu verstehen, was da passiert.
Man kann aber auf die Umsetzung von Index und Wert in eine Konstante verzichten und aus den fünf Zeilen eine Zeile machen

gTempOut.members.filter[ i | i.name.split("_").get(1) == triggeringItem.name.split("_").get(1) ].head.sendCommand((triggeringItem.state as QuantityType<Number>).floatValue)

Man kann auch beide Gruppen in einer Gruppe zusammenfassen, allerdings muss man dann zum einen prüfen, ob das auslösende Item eines der Sensor Items ist (Name enthält TempI) und zum anderen muss man den Filter dergestalt erweitern, dass ausschließlich Items enthalten sind, deren Name TempO enthält.

Der Index muss nicht zwingend numerisch sein, aber In und Out Item müssen an dieser Stelle identische werte stehen haben. Der Index muss nicht zwingend am Schluss des Namens stehen, aber er muss bei allen Items einer Gruppe an der gleichen Stelle stehen.
Die Funktion string.split(string) trennt den String in mehrere Substrings auf, und zwar an der Stelle, wo der übergebene String auftaucht. Der Trennstring taucht in den Substrings nicht mehr auf, aus ("Dies_ist_ein_Test").split("_") wird also eine Liste ["Dies","ist","ein","Test"]. Mit der Funktion get(Int) erhält man den entsprechenden Substring, wobei die Zählung mit 0 beginnt, ("Dies_ist_ein_Test").split("_").get(2) liefert also "ein" als Ergebnis.

[udo1toni]

2.5.0 Build #1522

Hast Du mal versucht, den DPT einfach weg zu lassen? Hast Du mal die Reihenfolge der Binding Definitionen getauscht? also

Number Temperature_AUSSEN_Heizung "Aussentemperatur [%.2f °C]" <temperature> (Heizung, Temperatur) { channel="knx:device:bridge:SmartTaster_Wohnzimmer_Tuere:Temperature_AUSSEN_Heizung", http="<[http://192.168.137.48:8080/heizung/heizung.php?REST=/system/sensors/temperatures/outdoor_t1:60000:JS(km200.js)]", autoupdate="false" }

[trant]

Alles probiert ;-),. Naja, es funktioniert mal, und mal sehen wie es mit einem neueren Build aussieht

[PascalTurbo]

So allgemein zu den OH2 Problemen. Ich glaube die sind auch bei kai kreuzer angekommen, wenn man sich seine Ideen zu OH3 anschaut: https://community.openhab.org/t/dire...penhab-3/67372