Knx openhab 20.102 hvac

[bbcare]

Hallo,

kann mir jemand nen Tip geben wie ich 20.102 HVAC Werte in nen Mapping -Switch bekomme.

Möchte meine Heizung Steuern:
KNX-Werte:
$00 Auto
$01 Comfort
$02 Standby
$03 Eco

Im Moment ignoriert Openhab die Werte aus dem KNX

things

Type string : Betriebsartheizung "Betriebsart Heizung" [ ga="20.102:3/2/4" ]

item

String Betriebsartheizung { channel="knx:device:bridge:generic:Betriebsartheizung" }

sitemap

Selection item=Betriebsartheizung label="Betriebsart Heizung" mappings=[0="Automatik", 1="Comfort", 2="Standby", 3="Economy"]

Wie bekommt man das zum Laufen? Muss man die Werte erst umrechnen oder gibts mittlerweile ne direkte Unterstützung 20.102 ?

Danke.

[wknx]

Gibt es einen besonderen Grund warum Du String und nicht Numeric als Channel- und Item-Typ verwendest?

[udo1toni]

Number bitte
Und es ist besser, Code auch als Code zu kennzeichnen, da die Forensoftware sonst eigenmächtig allerhand Ersetzungen vornimmt.

Channel:

Type number : Betriebsartheizung "Betriebsart Heizung" [ ga="20.102:3/2/4" ]

Item:

Number Betriebsartheizung { channel="knx:device:bridge:generic:Betriebsartheizung" }

Das Selection Widget muss nicht angepasst werden. Vermutlich muss aber beim Label hinten noch ein [] ergänzt werden, damit der Zahlenwert nicht mehr angezeigt wird.

[atmon]

Hallo zusammen,

ich hoffe jemand kann mir Helfen.

Ich versuche auch die Betriebsarten Umschaltung hinzubekommen.
Habe wie oben folgendes test weise angelegt.

things:

Type number : Betriebsartheizung "Betriebsart Test central" [ ga="20.102:<3/0/0" ]

Item:

Number Betriebsartheizung "Betriebsartheizung " { channel="knx:device:bridge:central:Betriebsartheiz ung" }

Sitemap:

Number item=Betriebsartheizung label="Betriebsart Heizung" mappings=[0="Automatik", 1="Comfort", 2="Standby", 3="Economy"]

In den Eventslogs sehe ich auch Einträge:

2020-01-28 11:38:21.462 [ome.event.ItemCommandEvent] - Item 'Betriebsartheizung' received command 1
2020-01-28 11:38:21.466 [nt.ItemStatePredictedEvent] - Betriebsartheizung predicted to become 1
2020-01-28 11:38:21.470 [vent.ItemStateChangedEvent] - Betriebsartheizung changed from 2 to 1

Im ETS monitor kommt aber nichts an.

Aktor ist
MDT AKH-0800.2
Konfiguriert ist es als "HVAC Status" und nicht als "DPT 20.102 HVAC Mode"

Vielen Dank in Vorraus.

Mfg

Angelo

[udo1toni]

Auch hier wie immer die Bitte: markiere Code bitte immer als Code (das geht auch nachträglich durch Bearbeiten des Postings) Der richtige "knopf" ist im Editor unter dem unterstrichenen A versteckt, dort dann das Number-Symbol (#). Oder man schreibt die Code-Tags [_CODE_]hier der Code[_/CODE_] einfach per Hand (die Unterstriche habe ich hier eingefügt, damit der Text erscheint, die also weg lassen)
Ich sehe im Text oben an mehreren Stellen Leerzeichen, wo potentiell keine hingehören. Das kann allerdings der Tatsache geschuldet sein, dass der Code nicht als Code markiert ist.

Auch wenn es naheliegend scheint, ist es keine gute Idee, Items identisch zu Channels zu benennen. Das kann, muss aber nicht Ursache Deines Problems sein.

Im Events.log tauchen Item-Events auf. Die Kommunikation mit knx läuft aber über den Channel, der nicht in den Events auftaucht. Um die Kommunikation mit knx zu sehen, müsstest Du das Logigng für das Addon auf debug setzen (das flutet dann allerdings die logs...)

Hast Du Dir das Handbuch mal zu Gemüte geführt? https://www.mdt.de/download/MDT_THB_...gsaktor_02.pdf Seite 44 ist die ausschlaggebende Seite... Im KO11 (ich gehe mal davon aus, das ist auf den ersten Kanal des Aktors bezogen) kann die Rückmeldung auf Bitebene oder als DPT20.102 erfolgen. Wenn man das umschaltet, fehlen allerdings die weiteren Informationen, da ja nur die Betriebsart 0 bis 3 gemeldet wird.

Korrekt sollte der Channel zwei GA bekommen, eine zum Senden, eine zum Empfangen (die sendende GA geht dann auf KO10, die empfangende GA auf KO11 im Modus mit DPT20.102 - alternativ die empfangende GA über einene eigenen Channel mit einer Rule, die dann das sendende Item auf den korrekten Status setzt. Ich hab das mal hier gepostet, die Gira TS2plus bieten nämlich nicht die Option, den Modus des Rückmelde-KO zu ändern...

[atmon]

Hallo udo1toni,

danke für die Antwort.
Hab mein Batragformatierung, nochmals angepasst.

Ich habe mir das Handbuch angeschaut und verstehe auch was notwendig wäre.
Allerdings muss ich schamhaft zugeben, ich weis nicht wie ich es umsetzten soll.

Hab mich versucht durch das Openhab Handbuch durchzuwalzen, div. Tutorials und Foren Beiträge angeschaut. Resultat: bin verwirrter als zuvor.

Dummer Endanwender.


Hatte gehofft, das jemand das gleiche Setup hat und mir 1 Beispiel nennen kann, damit ich es adaptieren kann.


P.s muss nicht Geschenkt sein. Kasten oder ähnliches muss dafür schon drin sein

Fg
Angelo

[Intenos]

Also bei mir funktioniert es folgendermaßen:

things

Type number        : K1_H1_Modus   "Keller Flur"                 [ ga="5.010:3/2/40+<3/3/40" ]

items

Number        K1_H1_Modus   "Keller Flur"                               <heatingmode> (gHeizung_Modus) { channel="knx:device:bridge:generic:K1_H1_Modus" }

sitemap

Selection item=K1_H1_Modus mappings=[1.0="Komfort", 2.0="Abwesend", 3.0="Nacht", 4.0="Frost"]

Ich bin auch einer der die things und items gleich benennt . Hatte aber bislang keine Probleme damit.

[udo1toni]

Ich bin auch einer der die things und items gleich benennt . Hatte aber bislang keine Probleme damit.

War auch nur eine nicht weiter begründete Vermutung allerdings habe ich bei mir die Erfahrung gemacht, dass ich dann gerne mal Items und Channel durcheinander bringe.

atmon hast Du denn auf den KO 10 und 11 (jeweils an erster Stelle) eine exklusive GA stehen (also im Sinne von: der Aktor ist das einzige Device, welches auf dieser GA sendet bzw. empfängt)?

[atmon]

Vielen Dank euch beiden.

Es geht, ich kann über die Sitemap nun die Betriebsarten der Räume umschalten.

Neben meinem Fehler, hat der Elektriker, im ETS, nur in der Zentrale Gruppenadresse mit Objekten\Kanäle gefühlt, aber nicht in den Räumen-Gruppenadressen.

@Intenos

Hoffe ich strapaziere nicht dein Hilfsbereitschaft, hast du noch eine Funktionierende Regel für Betriebsarten Umschaltung?
Ich versuche grade per Cron die Betriebsart zu schalten.

rule "Betriebsart BAD "
when
  Time cron “0 0 6 * * ?”
then
  number Betriebsart_BAD = 1.0
end

[udo1toni]

Der Befehl zum senden eines Befels lautet sendCommand. Um in einer Rule quasi das Drücken eines Knopfes in der UI zu emulieren, musst Du also diese Methode verwenden. Betriebsart_BAD.sendCommand(1)

[atmon]

udo1toni

Vielen Dank.

Ein schritt weiter in der Hausoptimierung.

[Intenos]

Hi atmon,

falls Interesse besteht, könnte ich auch ein paar Zeilen Code listen mit welchen du die Betriebsart für eine ganze Gruppe (im Zweifel alle) umstellen kannst ohne diese alle einzeln aufzulisten. Bspw. falls du über eine Tag-/Nachtumschaltung nachdenkst.

Je nachdem was du für eine Heizung und Umgebungsbedingungen hast, würde ich das allerdings auch schon wieder in Frage stellen. Ich für meinen Fall (Wärmepumpe) habe schnell festgestellt, dass dies kein Schritt nach vorne ist. Deutlich zielführend ist es die Raumtemperaturregler durchlaufen zu lassen und die Nachtabsenkung über die Heizkurve der Wärmepumpe zu realisieren.

[atmon]

Hi atmon,

falls Interesse besteht, könnte ich auch ein paar Zeilen Code listen mit welchen du die Betriebsart für eine ganze Gruppe (im Zweifel alle) umstellen kannst ohne diese alle einzeln aufzulisten. Bspw. falls du über eine Tag-/Nachtumschaltung nachdenkst.

Je nachdem was du für eine Heizung und Umgebungsbedingungen hast, würde ich das allerdings auch schon wieder in Frage stellen. Ich für meinen Fall (Wärmepumpe) habe schnell festgestellt, dass dies kein Schritt nach vorne ist. Deutlich zielführend ist es die Raumtemperaturregler durchlaufen zu lassen und die Nachtabsenkung über die Heizkurve der Wärmepumpe zu realisieren.

Vielen Dank dafür.
Wie du schon angesprochen hast, macht es auch bei mir wenig sinn die FB, für das gesamte Haus, die Betriebsart zu ändern.
Ich habe es nur für die Badezimmer eingerichtet.

Was ich allerdings noch versuche, um die Akzeptants der Familie zu erhöhen, es per sprach befehl zusteuern.

[arnoldmich]

Hallo,

nachdem ich hier auch auf viele Probleme gestoßen bin und nirgends eine funktionsfähig Lösung gefunden habe, habe ich selbst geforscht und eine Lösung gefunden wie man den MDT HVAC Status im Openhab darstellt:

Leider verhält sich hier Openhab sehr komisch aus meiner Sicht:
Wenn DPT und KNX Item Type nicht ab der ersten Sekunde auf Number:Temperature und 5.005 sind, wird das Byte konsequent falsch interpretiert.
Da hilf auch kein neustart o.ä! Eventuell weis ja jemand man so einen Item wieder "resettet" ?

Hintergrundinformationen:
Number:Temperature in Kombination mit 5.005 interpretiert die 1 Byte Variable korrekt als INT, was einen korrekten Zugriff auf die einzelnen Bits zulässt.
Theoretisch könnte man auch den auf Base 100 basierenden Typen 5.001 verwenden, der für Prozente gedacht ist. Leider wir der aber auf 2 Nachkommstellen (also ganze Prozentwerte) gerundet was ein zurück rechnen auf den vollen Base 255 Wert unmöglich macht.

Dies Lösung ist theoretisch auch für alle anderen 1 Byte Telegramme anwendbar!

Die Lösung:

things

Type number : hvac1 "HVAC 1" [ga="5.005:<4/1/40"]

items

Number:Temperature HVACStatus1 "Betriebsart 1 [JS(convert-hvac-status.js):%f]" ["HVAC"] {channel="knx:device:bridge:hvacStatus:hvac1"}

JS Transformation Service file: (convert-hvac-status.js)

(function(param) {
    var retVal = "";
    var logger = Java.type("org.slf4j.LoggerFactory").getLogger("convert-hvac-status.js");
   
    var hvacStateBitKomfort = 0x01;
    var hvacStateBitStandby = 0x02;
    var hvacStateBitNacht = 0x04;
    var hvacStateBitFrostschutzHitzeschutz = 0x08;
    var hvacStateBitHeizenKuehlen = 0x20;
    var hvacStateBitFrostschutzalarm = 0x080;    
    //Bit0 Komfort 0x01
    //Bit1 Standby 0x02
    //Bit2 Nacht 0x04
    //Bit3 Frostschutz/Hitzeschutz 0x08
    //Bit4 0x10
    //Bit5 1=Heizen 0= Kühlen 0x20
    //Bit6 0x40
    //Bit7 Frostschutzalarm 0x080
  var number = parseInt(input);
  var knownBits = hvacStateBitKomfort + hvacStateBitStandby + hvacStateBitNacht+ hvacStateBitFrostschutzHitzeschutz + hvacStateBitHeizenKuehlen + hvacStateBitFrostschutzalarm
  if(param == 0 || param & (hvacStateBitKomfort + hvacStateBitStandby + hvacStateBitHeizenKuehlen + hvacStateBitFrostschutzHitzeschutz + hvacStateBitFrostschutzalarm) == 0 ){
      // unknown Flag set -> Add Binary Code
    logger.warn("Error Converting HVAC Status : Unknown HVAC State("+ number.toString(2)+")");
    retVal = param;
  } else if((param & knownBits ) != param){
    // unknown Flag set -> Add Binary Code
  logger.warn("Error Converting HVAC Status : unknown Flag set ("+ number.toString(2)+")");
  retVal = param;
} else {
    var bytes = [];
    if((param & hvacStateBitKomfort) > 0){
        retVal += "Komfort";
    } else if((param & hvacStateBitStandby) > 0){
        retVal += "Standby";
    } else if((param & hvacStateBitNacht) >0){
        retVal += "Nacht";
    } else if((param & hvacStateBitFrostschutzHitzeschutz) >0){
        retVal += "Frostschutz/Hitzeschutz";
    }if((param & hvacStateBitHeizenKuehlen) >0 ){
        retVal += " (Heizen)";
    }else if((param & hvacStateBitHeizenKuehlen) == 0){
        retVal += " (Kühlen)";
    }if((param & hvacStateBitFrostschutzalarm) >0){
        retVal += " Frostschutzalarm";
    }  
  }
  return retVal;
})(input)

Ich hoffe es hilft jemandem!
Michael

[udo1toni]

Das knx Binding kann mit UoM nicht umgehen. Das heißt, die Items dürfen nicht als Number:temperature definiert sein. Abgesehen davon ist mit Number:temperature tatsächlich ein Temperaturwert gemeint, nicht ein Item, was irgendwas mit einem Gerät zu tun hat, welches irgendwas mit Temperatur zu tun hat...
Ich habe hier Gira TS2plus als RTR im Einsatz, die haben unterschiedliche Zahlenformate für Modus Setzen und Rückmeldung. Sieht so aus:
Beispielhaft ein Thing:

    Thing device GiraTSplus1_1_100 "TS2plus Flur" @ "KNX" [
        address="1.1.100"
     ] {
        Type number : tempIs  "Temperatur ist"   [ ga="<2/7/23" ]
        Type number : tempSet "Temperatur soll"  [ ga="9.001:2/7/26+<2/7/50" ]
        Type number : opMode  "Betriebsart ist"  [ ga="5.005:<2/7/36" ]
        Type number : opSet   "Betriebsart soll" [ ga="5.005:2/7/28" ]
    }

die zugehörigen Items:

 Number TS2plusFlur_TempIs  "Flur ist"         (GHeat_Is,GTempEG) {channel="knx:device:bridge:GiraTSplus1_1_100:tempIs"}
 Number TS2plusFlur_TempSet "Flur soll"        (GHeat_Soll)       {channel="knx:device:bridge:GiraTSplus1_1_100:tempSet"}
 Number TS2plusFlur_OpMode  "Betriebsart ist"  (GHeat_Mode)       {channel="knx:device:bridge:GiraTSplus1_1_100:opMode"}
 Number TS2plusFlur_OpSet   "Betriebsart soll" (GHeat_Set)        {channel="knx:device:bridge:GiraTSplus1_1_100:opSet"}

Es gibt nun zwei Gruppen von Items, die eine für alle Sollzustände, die andere für alle Istzustände. Und eine Regel für alle RTR im Haus:

rule "Betriebsart RTR"
 when
    Member of GHeat_Mode changed                                                                  // IstModus eines RTR hat sich geändert
 then
    var Integer newMode
    val mode = (triggeringItem.state as DecimalType).toBigDecimal.toBigInteger                    // BigInteger wird gebraucht
    val iName = triggeringItem.name.split("_").get(0).toString                                    // Der erste Teil des Itemnamens bestimmt den RTR
    logDebug("rtr","Name is: {}, Mode is: {}",iName,mode)
    switch (mode) {                                                                               // wähle anhand der Wertes von mode
        case mode.testBit(0) : newMode = 1                                                        // Ist Bit 0 gesetzt?
        case mode.testBit(2) : newMode = 3                                                        // Ist Bit 2 gesetzt?
        case mode.testBit(3) : newMode = 4                                                        // Ist Bit 3 gesetzt?
        default : newMode = 2                                                                     // Anderenfalls nimm an, dass Bit 1 gesetzt ist.
    }
    var myItem = GHeat_Set.members.filter[ f | f.name.startsWith(iName) ].head                    // Suche das pasende Item aus der zweiten Gruppe
    var Integer oldMode = 0                                                                       //
    if(myItem.state instanceof Number) oldMode = (myItem.state as Number).intValue                // Lies den aktuellen Status
    if(oldMode != newMode) {                                                                      // Falls alter und neuer Status sich unterscheiden
        logDebug("rtr","Name is: {}, oldMode is: {}, newMode is: {}",myItem.name,oldMode,newMode)
        myItem.postUpdate(newMode)                                                                // Setze den neuen Status
    }
end

Ich habe die restlichen 4 Bits nicht ausgeweret, sie geben aber Auskunft über die Funktion Heizen, Kühlen und evtl. Alarmzustände also ähnlich wie beim MDT.
Gesteuert wird aber mit den Zahlen 1 - 4 für die vier Betriebsarten.
In der Sitemap (ja, ich habe hier noch OH2.5 produktiv) sieht das Item so aus:

Frame label="Heizung" {
    Default  item=TS2plusFlur_TempIs  label="Temperatur ist [%.1f °C]"
    Setpoint item=TS2plusFlur_TempSet label="Temperatur soll [%.1f °C]" minValue=7 maxValue=25 step=0.1
    Default  item=TS2plusFlur_OpMode  label="Betriebsart ist"
    Switch   item=TS2plusFlur_OpSet   label="Betriebsart soll" mappings=[1="Komf",2="Stby",3="N8",4="Frost"]
}

Wobei ddie Ist-Betriebsart nur eine optische Kontrolle für mich ist Man misstraut seinen Regeln ja gerne mal...