[Gelöst] [V4.0 IP5] Timberwolf VISU BETA - Verhalten von Info-Widget unklar (war KNX Programmierung)

[fuzzi]

Hallo Nils,

Allgemein empfiehlt es sich, wenn so etwas unklar ist, in der Visu den Wert anzeigen zu lassen. Das wird ja direkt angezeigt (Instant). Anschließen kann man entsprechend anpassen und den Wert ausblenden.

Habe ich jetzt mal gemacht, da steht jetzt:
"true"

Ich habe jetzt auch mal Stefans Vorschlag aufgegriffen, das KNX-Objekt direkt in eine separate Zeitserie schreiben zu lassen:


Danach habe ich über node-red zweimal den string "0" bzw "1" geschickt, dann noch zweimal die Zahl 0 bzw 1 (und als letzten Versuch noch true bzw false):


Der KNX-Busmonitor zeigt mir die Telegramme (wie üblich 4x - das gibt es einen anderen Thread dazu):


Wenn man die Zeitstempel mit den node-red debug messages abgleicht, sieht man, dass es egal ist, ob strings, 0/1 oder true/false geschickt werden - auf dem bus kommt das alles als true/false an wie erwartet.

In der oben angelegten Zeitserie kommt aber nichts an? Die ist nach all den Versuchen immer noch leer? Ich muss mir das wohl morgen noch mal anschauen, wenn ich frischer im Kopf bin...

[gbglace]

Wenn man die Zeitstempel mit den node-red debug messages abgleicht, sieht man, dass es egal ist, ob strings, 0/1 oder true/false geschickt werden - auf dem bus kommt das alles als true/false an wie erwartet.

Nein denn die Anzeige im Busmonitor ist schon nach Formatierung durch den TWS, der zu der GA eben die DPT aus dem ETS-Projekt kennt.
Dein NR hat aber bestimmt keinen ETS-Projektimport erhalten um zu wissen mit welchem DPT diese GA "erwartet" wird. Insofern wird NR da einfach nur 0/1 aussenden was am Ende auch nur wie ein Bitwert 0 und 1 aussehen sollte. Aber es kann eben auch einfach eine Float-Zahl sein die dann der TWS da interpretiert.

Ist das alles so in der Form direkt so eingerichtet worden? oder gibt es da ggf. noch eine Phantomerinnerung aus einer Reorganisation der TWS-KOs?

[fuzzi]

Hallo Göran,

die 3/3/6 habe ich mir neu in der ETS erzeugt, um den Klingelstatus zu überwachen. Ich behaupte mal, die war vorher noch nie vergeben... Werte kamen (zumindest heute) auch nur über den Tunnel, den Node-RED verwendet...

[gbglace]

Aber auch das KO#58 neu verwendet und vorher war das ggf. mit einer anderen GA verbunden?

[fuzzi]

Hallo Göran,

danke - da scheint tatsächlich ein Problem vorzuliegen, aber wie ich das löse, ist mir nicht klar...

Wenn ich mir die KNX-Objekte im Timberwolf ansehe, sieht das so aus:


Wenn ich mir dagegen den Objektmanager ansehe, sehe ich folgendes:


Die Zuweisung von GA zu Kommunikationsobjekt mache ich ja in der ETS - kann schon sein, dass da vorher das Kommunikationsobjekt anderweitig vergeben war. Heisst das dann, dass ich die Objekte nur einmal vergeben kann und dann nie wieder ändern?

Oder ist da nur was beim Programmieren schiefgelaufen? Das werde ich gleich noch mal probieren...

[Cepheus73]

Nein denn die Anzeige im Busmonitor ist schon nach Formatierung durch den TWS, der zu der GA eben die DPT aus dem ETS-Projekt kennt.

Das läßt sich beheben, indem man auf die Raw-Anzeige des Busmonitors umstellt. Dann sieht man auch noch die einzelnen übertragenen Bytes - und damit auch die Länge der Payload. Würde wirklich ein Float übertragen, dann müssten es mehrere Bytes sein.

Dein NR hat aber bestimmt keinen ETS-Projektimport erhalten um zu wissen mit welchem DPT diese GA "erwartet" wird.

Im Sendeobjekt des NodeRed-Flows muss der DPT konfiguriert werden.
Außerdem kann man ins NodeRed-Flow die Gruppenadressen aus der ETS importieren.
D.h. NodeRed sendet da nicht einfach nach "Gutdünken".

Insofern wird NR da einfach nur 0/1 aussenden was am Ende auch nur wie ein Bitwert 0 und 1 aussehen sollte. Aber es kann eben auch einfach eine Float-Zahl sein die dann der TWS da interpretiert.

Das NodeRED-Objekt sendet das so, wie der DPT konfiguriert ist, führt also ggf. eine Konvertierung vom Eingangswert im Flow durch.
Es kann also nicht eben einfach eine Float-Zahl sein, wenn ein 1.* DPT konfiguriert ist. Float geht nur, wenn es ein 9.* DPT ist.

Das kann man leicht überprüfen:
a) im Busmonitor anhand der Raw-Daten: bei 1.* ist es nur ein Byte, bei Float mindestens zwei
b) natürlich auch in den Eigenschaften des NodeRed-Objekts (ich vermute aber, dass es da ein 1.* ist).

Viele Grüße

Bernhard

[Cepheus73]

Die Zuweisung von GA zu Kommunikationsobjekt mache ich ja in der ETS - kann schon sein, dass da vorher das Kommunikationsobjekt anderweitig vergeben war. Heisst das dann, dass ich die Objekte nur einmal vergeben kann und dann nie wieder ändern?

Die Programmierung scheint mir richtig zu sein. Das KO #58 zeigt ja den korrekten DPT 1.002 im TWS bei den KNX Objekten.
Warum der Objekt Manager da einen Float-Wert anzeigt ist aber tatsächlich die Frage.

Am besten kontrollierst du nochmal im NodeRED im KNX-Sendeobjekt den DPT.
Dann aktivierst du im Busmonitor "Raw Data" und schaust, was an Raw Daten angekommen ist.

Und natürlich muss man den DPT eines TWS-KOs nachträglich ändern können.

Viele Grüße

Bernhard

[StefanW]

Hallo,

ich nehme an, dass im Objekt-Verteiler einfach ein vorher gespeicherter Wert (hier ein Float) aus einem vorherigen Telegramm vorhanden ist.

An einen solchen Fall kann ich mich nicht erinnern, aber wenn man ein TRUE oder FALSE drüber schreibt, dann sollte das wieder passen.

lg

Stefan

[fuzzi]

Hallo Bernhard,

Eine gerade durchgeführte Neuprogrammierung (sowohl das individuelle KO als auch das gesamte Applikationsprogramm) in der ETS hat am Verhalten nichts geändert...

Am besten kontrollierst du nochmal im NodeRED im KNX-Sendeobjekt den DPT.
Dann aktivierst du im Busmonitor "Raw Data" und schaust, was an Raw Daten angekommen ist.

Das scheint mir auch ok zu sein - mit Node-RED mache ich gerade meine ersten Gehversuche, aber der KNX-Node scheint korrekt eingestellt zu sein:


Busmonitor mit Raw Data zeigt auch, dass da ein boolean ankommt:

[fuzzi]

Hallo Stefan,

ich nehme an, dass im Objekt-Verteiler einfach ein vorher gespeicherter Wert (hier ein Float) aus einem vorherigen Telegramm vorhanden ist.

An einen solchen Fall kann ich mich nicht erinnern, aber wenn man ein TRUE oder FALSE drüber schreibt, dann sollte das wieder passen.

Das Problem scheint beim drüberschreiben zu liegen - da kommt irgendwie nichts an, auch wenn ich auf die korrekte GA den richtigen Wert mit richtigem DP schreibe?