Werte von Temperatursensor

[stf90]

Guten Abend!

Ich melde mich als IT-ler, der gerade ersten Kontakt mit KNX hat. Einerseits direkt über ein IP-Gateway, andererseits indirekt mit dem KNX-Techniker der Elektrofirma.
Das ist ein bisschen mühsam, da ich ihm sage/schreibe, was alles funktioniert bzw. nicht funktioniert bzw. was ich am Bus über das IP-Gateway mit Node-red oder XKNX sehe. Die Antworten sind dann auch nicht immer hilfreich, obwohl der Techniker bemüht ist.

Deshalb die Bitte um Hilfestellung in "KNX-Sprache", was ich dem Techniker weiterleiten könnte oder was ich bei der Verarbeitung der Daten falsch mache.
Ziel ist, die Medientechnik mit KNX zu verknüpfen (eine kleine GUI mit node-red funktioniert größtenteils), aktuell will ich einmal die Außentemperatur für eine Anzeige zugänglich machen. Mit Node-red habe ich einen REST-Endpoint definiert, der mit GET /tempAussen den aktuellen Wert der Adresse 1/0/200 zurückgibt.
Allerdings habe ich mit den Temperaturwerten ein Problem bzw. kann Verhalten/Programmierung des Temperatursensors nicht ganz nach vollziehen.
Wenn ich per XKNX über Python direkt den Sensor unter 1/0/200 anspreche, dann bekomme ich die aktuelle Außentemperatur zurück (aktuell ca. 7°C), das sind die unten angeführten GroupValueRead/GroupValueResponse-Einträge.
Zusätzlich wird jede halbe Stunde auf 1/0/200 ein Wert auf den Bus geschrieben (GroupValueWrite), der mit der aktuellen Temperatur gar nichts zu tun hat (im Bereich 20°C, wenn als Temperatur ausgewertet). Für mich stimmt da etwas nicht (eher mit dem alle 30 Minuten verbreiteten Wert).
Für mich wäre ideal, wenn die "aktuelle" Temperatur immer unter 1/0/200 abrufbar ist (ohne vorherige Abfrage der Adresse). Am besten mit einer automatischen Aktualisierung alle 3-5 Minuten oder einer Änderung um einen gewissen Wert (Größenordnung 0,5°C reicht).
Könnt ihr mir helfen, wo der Fehler der "falschen" Temperatur liegen könnte bzw. wie man die aktuelle Temperatur bequem ablesbar auf den Bus bekommt?

Danke!
Stefan

2023-12-26 20:53:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0xcc]" />" />" />
2023-12-26 21:23:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0xdb]" />" />" />
2023-12-26 21:23:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0x12]" />" />" />
2023-12-26 21:53:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0x17]" />" />" />
2023-12-26 21:53:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0x75]" />" />" />
2023-12-26 22:23:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0x12]" />" />" />
2023-12-26 22:23:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0x70]" />" />" />
2023-12-26 22:53:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0xac]" />" />" />
2023-12-26 22:53:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0x9f]" />" />" />
2023-12-26 23:23:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0xf9]" />" />" />
2023-12-26 23:23:42: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueWrite value="<DPTArray value="[0xc,0x56]" />" />" />
2023-12-26 23:42:28: T: <Telegram direction="Incoming" source_address="1.2.248" destination_address="1/0/200" payload="<GroupValueRead />" />
2023-12-26 23:42:28: T: <Telegram direction="Incoming" source_address="1.2.248" destination_address="1/0/200" payload="<GroupValueRead />" />
2023-12-26 23:42:28: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueResponse value="<DPTArray value="[0x2,0xd4]" />" />" />
2023-12-26 23:42:28: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueResponse value="<DPTArray value="[0x2,0xd4]" />" />" />
2023-12-26 23:42:29: T: <Telegram direction="Incoming" source_address="1.2.248" destination_address="1/0/200" payload="<GroupValueRead />" />
2023-12-26 23:42:29: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueResponse value="<DPTArray value="[0x2,0xd4]" />" />" />
2023-12-26 23:42:29: T: <Telegram direction="Incoming" source_address="1.2.248" destination_address="1/0/200" payload="<GroupValueRead />" />
2023-12-26 23:42:29: T: <Telegram direction="Incoming" source_address="1.2.200" destination_address="1/0/200" payload="<GroupValueResponse value="<DPTArray value="[0x2,0xd4]" />" />" />

[meti]

Hi 👋!
Weißt du was für ein Gerät 1.2.200 ist?
Hast du deine Projektdatei?

[Robby]

Ziel ist, die Medientechnik mit KNX zu verknüpfen

Vielleicht würdest du das noch ein wenig erläutern....welches System?

Was würde passieren wenn du mal die Firma verlassen würdest, bezogen auf deine Programmierung über node-red?

Mich würde jetzt auch mal interessieren was für zwei Geräte (1.2.200,1.2.248) die gleiche Gruppenadresse (1/0/200) senden. Ich nehme mal an das dort etwas falsch verknüpft ist.

Wie meti schon fragte, gibt es eine Projektdatei? Ich gehe ja bei einer phy. Adresse von 1.2.xx davon aus das auch Linienkoppler verbaut sind, da müsste ja auch ein Dummy in der ETS eingefügt werden, der die Filtertabellen anpasst.

[meti]

Robby 1.2.248 sendet nur Leseanfragen (von xknx oder NodeRed?) an 1/0/200. Und die Antworten kommen ja eh - dementsprechend würde ich nicht von einem Topologie/Filtertabellenproblem ausgehen sondern eher von einer Fehlparametrisierung von 1.2.200.

[Robby]

1.2.248 sendet nur Leseanfragen (von xknx - also über IP Gateway) an 1/0/200

Stimmt, sehe ich jetzt auch

[gbglace]

Wenn Due selbst keine ETS und nicht die Projektdatei hast, dann frage den Techniker folgendes:

a) welches Gerät verbirgt sich hinter der PA 1.0.200?
b) warum sendet das Gerät von sich aus zyklisch +/- 20°C und als Antwort auf eine Leseanfrage +/- 7°C mit der GA 1/0/200
c) sind womöglich zwei verschiedene Geräte im Projekt installiert mit der selben PA 1.0.200 die auch noch die gleiche GA 1/0/200 als sendende Adresse verknüpft haben?

Unabhängig davon, kannst Du in Deiner Software irgendwie ein Buslog nach der PA 1.0.200 filtern, werden von diesem gerät noch weitere GA gesendet? ggf lässt sich darüber dann schon einfacher von Deiner Seite aus feststellen das da zwei Geräte mit der selben PA im Bus angeklemmt sind.

Für mich wäre ideal, wenn die "aktuelle" Temperatur immer unter 1/0/200 abrufbar ist (ohne vorherige Abfrage der Adresse).

Das funktioniert ggf in Deiner Software hinter dem KNX aber nicht auf dem KNX. Die GA (Gruppenadressen x/y/z) sind keine Objekte sondern teil der flüchtigen Information die in einem Telegramm auf dem Bus versendet werden. Eine GA speichert keine Information und kann daher nicht abgerufen werden.
Am KNX-Bus sidn die Kommunikationsobjekte (KO) der jeweiligen physischen Geräte (physikalische Adresse PA x.y.z) die Informationen speichern.
Alle Telegramme auf dem KNX-Bus sind broadcast also alle KO am Bus bekommen immer alle Telegramme. Nur wenn eine GA an ein KO verbunden ist, dann wird das KO auf Telegramme mit dieser GA als Inhalt weiterverarbeiten. Wie ein KO ein Telegramm weiterverarbeitet entscheiden dann die Flags am KO.
Soll ein KO zu einem Event eine Telegramm verschicken, wird es immer genau ein Telegramm verschicken und es kann in jedem Telegramm immer genau eine GA referenziert werden. Also gilt ein KO sendet immer eine GA kann aber auf mehrere GA horchen. Man kann also 5 GA an ein KO verbinden aber es wird immer nur mit einer GA (der ersten verbundenen) ein Telegramm gesendet.

Wenn Du also mit Deiner Software per KNX-IP Tunneling auf dem KNX-Bus horchst und Dir in der Software jedes eingehende Telegramme nach den enthaltenen GA's durchsuchst und an Hand dieser ein internes Objekt mit dem Value im Telegramm befüllst, dann baust Du rein in der Software Dir ein Objekt welches Du ggf als GA x/y/z als ID referenzierst. Das ist dann aber nur in Deiner Software so zu verwenden / verstehen und kann dann entsprechend jederzeit ausgelesen werden. Es gibt Dir dann den zuletzt empfangenen Wert wieder. Du musst dann noch klären wie gut ist ein solcher zuletzt empfangener Wert, sofern die Software unbestimmte Zeit wegen Reboot offline war. Daher ergibt es meistens Sinn bei Reboot solche Werte aktiv auf dem Bus anzufragen (Readrequest) und sich mit der entsprechenden Antwort zu initialisieren. Im folgenden laufenden Prozess wird aber dann bei solchen Klimawerten aber auch sinnvoll der Sensor so parametriert das er bei Änderung um x und ggf zyklisch seinen Wert sendet.
Man muss nur aufpassen das man nicht zu viele solcher Werte sendet, da die Bandbreite des KNX nicht unendlich ist.

Bei jedem Verarbeitungsschritt in einer eigenen Software einen Readrequest abzusetzen und mit der Antwort zu arbeiten, sollte man natürlich ganz vermeiden, da solche Konstruktionen ganz schnell den Tod des KNX-bedeutet durch massive Telegrammflutung.

[stf90]

Vielen Dank für die raschen Antwort.

Hi 👋!
Weißt du was für ein Gerät 1.2.200 ist?
Hast du deine Projektdatei?

Laut einem Screenshot aus KNX ist das der Temperatursensor ("1.2.200 KNX GPS Wetterstation").
Projektdatei sollen wir nach Fertigstellung bekommen, auf den ersten Blick könnte es aber sein, dass sich von der Software die Home-Variante mit den 64 Geräten knapp nicht ausgeht und die Pro ist dann doch ein bisschen teuer. Oder gibt es einen reinen Viewer bzw. die Möglichkeit, irgendwas aus der Projektdatei auszulesen?

Vielleicht würdest du das noch ein wenig erläutern....welches System?
Was würde passieren wenn du mal die Firma verlassen würdest, bezogen auf deine Programmierung über node-red?

Grundsätzlich lässt sich alles "angreifbar" über Taster steuern, Medientechnik und Node-red-Zugriff sind einmal nur Spielereien. Medientechnik ist Q-SYS mit dem Plugin von SDS music verknüpft (erste Tests sind erfolgreich).
https://www.sdsmusic.ch/shop/alle-be...plugin-package
Ich will einmal alle Vorgänge auf "low level" (mit xknx oder Node-red) testen, bevor ich hier ein weiteres System dazwischen schalte. Das hilft bei der Fehlersuche (ist es KNX oder Q-SYS).
Wenn es mich hier einmal nicht mehr gibt, dann ist die Temperaturanzeige an einem Display mit den Busfahrzeiten das kleinste Problem . Meine Arbeit hier ist seit 20 Jahren ehrenamtlich und es haben mehrere Leute (unterschiedlich tief) Einblick ins System. KNX ist mit dem Umbau neu dazugekommen und wir probieren einfach einmal aus, was alles geht und eventuell sinnvoll verwendbar ist. Voraussetzung ist natürlich, dass KNX korrekt funktioniert.

Robby 1.2.248 sendet nur Leseanfragen (von xknx oder NodeRed?) an 1/0/200. Und die Antworten kommen ja eh - dementsprechend würde ich nicht von einem Topologie/Filtertabellenproblem ausgehen sondern eher von einer Fehlparametrisierung von 1.2.200.

Sowas in der Art wollte ich hören
Wie würdet ihr das mit dem Temperatursensor machen? Aktiv abrufen oder regelmäßig senden lassen (alle paar Minuten oder bei bestimmter Temperturänderung)?

Danke!
Stefan

[Robby]

Projektdatei sollen wir nach Fertigstellung bekommen, auf den ersten Blick könnte es aber sein, dass sich von der Software die Home-Variante mit den 64 Geräten knapp nicht ausgeht und die Pro ist dann doch ein bisschen teuer. Oder gibt es einen reinen Viewer bzw. die Möglichkeit, irgendwas aus der Projektdatei auszulesen?

Wie würdet ihr das mit dem Temperatursensor machen? Aktiv abrufen oder regelmäßig senden lassen (alle paar Minuten oder bei bestimmter Temperturänderung)?

So wie ich das sehe hast du doch mehrere Linien in deinem Projekt die durch Linienkoppler voneinander getrennt sind. Wie magst du denn die Filtertabellen und den Dummy pflegen ohne ETS?

Der Elektriker kann dir am Ende einen Report ausdrucken, da würdest du dann alle Geräte und Verknüpfungen sehen.

[gbglace]

Wie würdet ihr das mit dem Temperatursensor machen? Aktiv abrufen oder regelmäßig senden lassen (alle paar Minuten oder bei bestimmter Temperturänderung)?

Daher ergibt es meistens Sinn bei Reboot solche Werte aktiv auf dem Bus anzufragen (Readrequest) und sich mit der entsprechenden Antwort zu initialisieren. Im folgenden laufenden Prozess wird aber dann bei solchen Klimawerten aber auch sinnvoll der Sensor so parametriert das er bei Änderung um x und ggf zyklisch seinen Wert sendet.
Man muss nur aufpassen das man nicht zu viele solcher Werte sendet, da die Bandbreite des KNX nicht unendlich ist.

Bei jedem Verarbeitungsschritt in einer eigenen Software einen Readrequest abzusetzen und mit der Antwort zu arbeiten, sollte man natürlich ganz vermeiden, da solche Konstruktionen ganz schnell den Tod des KNX-bedeutet durch massive Telegrammflutung.

[meti]

Oder gibt es einen reinen Viewer bzw. die Möglichkeit, irgendwas aus der Projektdatei auszulesen?

Wenn du Python-fest bist kannst du `xknxproject` verwenden. Oder Home Assistant, aber da ist der Projekt-Viewer noch nicht released - das müsste man als custom component (knx-frontend) von Github laden.
Alternativ kann dir der KNX-Mensch auch Reports als pdf schicken. Da sollten auch alle GAs, KOs, DPTs etc. zu sehen sein.

Wie würdet ihr das mit dem Temperatursensor machen? Aktiv abrufen oder regelmäßig senden lassen (alle paar Minuten oder bei bestimmter Temperturänderung)?

Grundsätzlich am Liebsten bei Änderung. Allerdings gibts da ein paar Spezialexperten-Wetterstationen die die Höhe der Änderung nur relativ (%) einstellen lassen - was zur Folge hat dass dein Bus im Winter geflutet wird - weil bei 0°C eine Änderung um 5% schnell gemessen wird 🙄 Also wenn man das nicht Absolut einstellen kann (0,5K zb.) dann lieber doch alle 10 Minuten.
Wenn dus alle 5-10 Minuten per Read-Request abrufst, wird die Welt aber auch ned zusammenbrechen.

[Beleuchtfix]

Ich nehme gerne beides, 0,5° Änderung und alle 5 oder 10 Minuten. Das garantiert dir, dass nach einem einzelnen Gerätereset in jedm Fall nach einer Weile wieder alles stimmt.
Gruß Florian

[stf90]

Danke für die vielen Antworten!

So wie ich das sehe hast du doch mehrere Linien in deinem Projekt die durch Linienkoppler voneinander getrennt sind. Wie magst du denn die Filtertabellen und den Dummy pflegen ohne ETS?
Der Elektriker kann dir am Ende einen Report ausdrucken, da würdest du dann alle Geräte und Verknüpfungen sehen.

Ich mag an KNX aktuell selbst eigentlich gar nichts pflegen, dazu haben wir ja die Elektrofirma, die uns die Installation einrichtet. Grundsätzlich bin ich schon an Neuem interessiert, aber das ist aktuell der Senden und Empfangen von KNX-Daten über Node-Red/XKNX.
Einen Report mit allen GA habe ich, dann werde ich mich nach den anderen Reports umschauen.

Ich nehme gerne beides, 0,5° Änderung und alle 5 oder 10 Minuten. Das garantiert dir, dass nach einem einzelnen Gerätereset in jedm Fall nach einer Weile wieder alles stimmt.
Gruß Florian

Node-Red kann man so einstellen, dass bei einem Reset die Werte aktiv angefordert werden und ab dann nur am Bus gelauscht wird. So habe ich es bisher gemacht und bin auch auf das Problem gestoßen. Beim Deployen der Änderungen habe ich immer den richtigen Temperaturwert bekommen und alle halbe Stunden wurde der falsche Wert reingespült.
Dann werde ich mich demnächst mit dem KNX-Techniker in Kontakt setzen und um Nachforschung bzw. Konfigurationsanpassung bitten.

Danke!
Stefan

[Robby]

Ich mag an KNX aktuell selbst eigentlich gar nichts pflegen, dazu haben wir ja die Elektrofirma, die uns die Installation einrichtet. Grundsätzlich bin ich schon an Neuem interessiert, aber das ist aktuell der Senden und Empfangen von KNX-Daten über Node-Red/XKNX.
Einen Report mit allen GA habe ich, dann werde ich mich nach den anderen Reports umschauen.

Für das Senden und Empfangen von Daten ist es aber NÖTIG das du LINIENÜBERGREIFEND Daten schicken kannst. Alles was in der Linie 1.2 gesendet wird bleibt auch in der 1.2 und alles was in der 1.1 gesendet wird bleibt in der 1.1 usw. ODER dein Elektriker stellt die Linienkoppler auf Durchzug, dann brauchst du aber auch nicht mehrere Linien. Oder dein Elektriker muss den Dummy einrichten und nach deinen Wünschen an GA füttern.

[stf90]

Für das Senden und Empfangen von Daten ist es aber NÖTIG das du LINIENÜBERGREIFEND Daten schicken kannst. Alles was in der Linie 1.2 gesendet wird bleibt auch in der 1.2 und alles was in der 1.1 gesendet wird bleibt in der 1.1 usw. ODER dein Elektriker stellt die Linienkoppler auf Durchzug, dann brauchst du aber auch nicht mehrere Linien. Oder dein Elektriker muss den Dummy einrichten und nach deinen Wünschen an GA füttern.

Das sollte soweit funktionieren. Ich kann div. Komponenten im Haus bedienen (Status, Schalten, Dimmen, ...). Der Techniker hatte dazu extra einige Gruppenadressen nachgepflegt, die er sonst nicht gebraucht hätte. Ein 6-seitiges PDF mit allen Gruppenadressen aus ETS habe ich.

Stefan

[gbglace]

GA anlegen ungleich GA verbinden.

Ich habe einige tausend GA in meinem ETS Projekt. Aber nur einen Bruchteil davon an Aktoren usw. verbunden.

Also nochmal wenn es keinen Verbindungspunkt von GAs in allen Linien gibt, dann kannst Du zwar mit einer Software auf dem Bus irgendwo horchen aber wirst nur einen Teil der Telegramme abbekommen.

Hast alle GAs an einem entsprechenden Dummy oder die LKs auf Durchzug dann gehen zwar alle Telegramme auch auf alle Linien. Aber ob dann noch die Segmentierung der Anlage Sinn ergibt ist fraglich.