openhabforum.de

Hallo
ich habe einen Thermostat welcher in OH4 eingebunden ist. Dieser funktioniert soweit und die Temperatur wird in OH angezeigt bzw. der Thermostat regelt. Was nicht funktioniert ist die Anpassung des Sollwertes in OH. Das heisst wenn ich einen neuen Sollwert in OH eingebe bekomme ich in der ETS folgendes:
Der Thermostat in der ETS hat:

Der Sollwert ist aber immer der gleiche.... Hat jemand eine Idee was hier falsch sein könnte?

Besten Dank

Da fehlen essenzielle Daten angefangen mit der Konfiguration mindestens des Channels...
Aber anhand der Bildchen wäre meine erste Vermutung, dass da außerdem noch eine Gruppenadresse fehlt.
Merke: knx Kommunikation ist grundsätzlich gerichtet, ein RTR hat für die Solltemperatur mindestens zwei Kommunikationsobjekte, das eine sendet den aktuellen eingestellten Wert auf den Bus, das andere KO wertet Befehle aus und ändert die Solltemperatur entsprechend. Deshalb hat der passende Parameter des Channels auch immer zwei GA zugeordnet, die erste zum Senden des Absolutwerts, die zweite um den Status abzurufen bzw. zu empfangen (für Abruf muss das Status-KO dann das L-Flag gesetzt haben und in openHAB die GA mit < markiert sein)

udo1toni hat geschrieben: ↑1. Okt 2024 20:00 Nun ich habe zwei GA in OH (siehe unten) bzw. die Stellgrösse konfiguriert. Kann es sein dass die GA für den Ist-Wert kein "<" benötigt?

Zur Vollständigkeit: Ich habe die Channels für den Raumthermostat in OH wie folgt:

Code: Alles auswählen

 - id: Chn30_51
    channelTypeUID: knx:switch
    label: Stellgroesse Heizen
    description: null
    configuration:
      ga: 7/1/2
  - id: Chn54
    channelTypeUID: knx:number
    label: Bad Raumtemperatur Sollwert
    description: Ein Kanal zur Verwaltung einer generischen Gruppenadressen mit
      einem DPT (Datenpunkttyp) kompatibel mit Number Items
    configuration:
      ga: <7/1/3
  - id: Chn55
    channelTypeUID: knx:number
    label: Bad Raumtemperatur Istwert
    description: Ein Kanal zur Verwaltung einer generischen Gruppenadressen mit
      einem DPT (Datenpunkttyp) kompatibel mit Number Items
    configuration:
      ga: <7/1/4

die zweite um den Status abzurufen bzw. zu empfangen

Mit "Status" meinst du hier den Ist-Wert welches die ETS schickt?

Nein, der Istwert ist der Istwert (und logischerweise nur lesbar -> eine GA
Der Sollwert hingegen benötigt 2 GA, die erste für das Setzen des Sollwertes, die zweite für den Status des Sollwertes.

Schau Dir die Liste der KO des RTR an, dort gibt es mit Sicherheit zwei KO für den Sollwert, einmal Status, einmal Setzen.

Nun ich sehe bei den KO's noch tatsächlich einen Status mit der ID 61. Wie bzw. wo in OH muss ich diesen noch verbinden? Muss dies mit einer (neuen) GA noch verbunden werden?

Beim OH Thermostat Widget sehe ich zwei Einträge (Items) die man machen muss: Zum einen der Istwert Item (dieser wird auch angezeigt) und den Setpoint Item (Solltemperatur).

Danke

Moin,

so sieht meine Konfiguration aus, vllt. kannst Du Dich ja daran orientieren und entlang hangeln.

* In der ETS, der Temperatursensor
* ETS, Heizaktor (vgl. dein Thermostat, bei mir sind Sensor und Aktor aufgeteilt)
* OH, Temp.sensor:
* OH, Heizaktor
Alles nicht zwingend notwendige, wie Stellwerte, Modi, etc habe ich hier mal weggelassen.

Du benötigst definitiv - wie Udo bereits geschrieben hat - 3 GAs : den Messwert der Isttemperatur, sowie Sollwert und Rückmeldeobjekt des Raumthermostats.
Und dann jeweils die Temperaturitems für Soll- und Ist-Wert in OH.

Die KNX GA musst Du auf Deine Werte anpassen.

Um es noch "etwas" zu vertiefen:

Jedes KO, welches exklusive Werte sendet (z.B. ein Messwert, eine Rückmeldung eines Zustands des Geräts, zu dem das KO gehört...) benötigt eine eigene GA (wenn der Wert irgendwo verwendet werden soll - schließlich muss man sicherstellen, dass die Zuordnung des Werts eindeutig ist).

In jeder GA darf es nur maximal ein KO geben, welches auf Leseanfragen antwortet (d.h. neben dem K- und dem Ü-Flag ist noch das L-Flag gesetzt und die betreffende GA ist die erste eingetragene GA auf diesem KO).

nw378 hat geschrieben: ↑3. Okt 2024 08:45 Moin,

Code: Alles auswählen

  - id: EG_Essen_Temp_Soll
    channelTypeUID: knx:number
    label: EG Essen Temperatur Soll
    description: Ein Kanal zur Verwaltung einer generischen Gruppenadressen mit
      einem DPT (Datenpunkttyp) kompatibel mit Number Items
    configuration:
      ga: 9.001:4/4/1+<4/5/1

Hallo
ich hätte noch folgende Fragen zu dieser GA von dir: ga: 9.001:4/4/1+<4/5/1[/code]
Wieso steht hier die 4/4/1 und nicht die 4/4/0 wie du für den Sollwert angegeben hast?

Für was steht am Anfang der ga die "9.001"? Ist diese Adresse notwendig?

Gruss

Da hat sich der Fehlerteufel eingeschlichen. Ich bin beim Kopieren beim falschen Channel gelandet (konkret: Esszimmer, statt Wohnzimmer).

ga: 9.001:4/4/0+<4/5/0 ist korrekt.

9.001 ist ein KNX-Datenpunkttyp und sagt aus, dass es sich um einen Temperaturwert handelt.
Ist meines Wissens hier nicht zwingend erforderlich, schadet aber auch nicht. Es gibt/gab Fälle, in denen die Angabe des DPTs für die Kommunikation zwischen OH und KNX erforderlich ist.

Ein Übersicht der DPT findest Du hier: https://support.knx.org/hc/de/article_a ... 2631105682

Inzwischen ist der DPT in openHAB tatsächlich nicht mehr so ganz unwichtig...
Sämtliche von openHAB offiziell unterstützte DPT kannst Du auch direkt in der Dokumentation von openHAB finden: https://www.openhab.org/addons/bindings ... nhab-types und dort siehst Du auch die Zusammenhänge zwischen DPT und openHAB Datentyp.
Insbesondere wenn man UoM bzw. QuantityType verwendet (das sollte man unbedingt implementieren, weil es in kommenden Versionen von openHAB irgendwann verpflichtend sein wird) sind die DPT zwingend, falls der DPT vom default DPT des jeweiligen Channels/Parameters abweicht.

Der Haupt-DPT (links vom Dezimalpunkt) beschreibt das Datenformat, - Bit, Byte, Float, String usw.
Der Sub-DPT (rechts vom Dezimalpunkt) beschreibt, wie der Wert zu interpretieren ist - Volt, Meter pro Sekunde, °Celsius usw.

Solange man kein UoM nutzt, kann man den Sub-DPT oftmals ignorieren, der Haupt-DPT muss aber unbedingt passen. Manchmal gibt es auch kompatible DPT, z.B. 17 und 18 entspricht im Grunde 5.005 (Integer 0-255), nur dass bestimmte Gültigkeitsgrenzen gelten (17: 0-63, 18: 0-63,128-191).

Man sollte dennoch immer versuchen, den korrekten DPT auszuwählen, auch wenn dies auf Protokollebene irrelevant ist - der DPT steht nicht mit im Datentelegramm, das ist auch der Grund, warum man ihn konfigurieren muss...