OpenKNX und DPT 7.007

[alanz]

Hallo zusammen,

ich lese hier schon eine Zeit lang mit und habe auch schon verschiedene OpenKnx Geräte im Einsatz. An dieser Stelle einmal vielen Dank an alle die OpenKnx zu dem gemacht haben und machen was es heute ist. Es ist überaus beeindruckend was ihr hier geschaffen habt und wie viel Zeit ihr hier investiert! 👍

Aktuell bin ich dabei eine eigene Applikation / Firmware auf Basis von OpenKNX zu entwickeln, um unsere Hoval Lüftungsanlage an den KNX-Bus zu bekommen. Das Hoval CAN Protocol habe ich mittlerweile weitgehend verstanden und auch schon den Grundstock implementiert, um das ganze auf den Bus zu bekommen. Die ersten Werte werden bereits erfolgreich übertragen. Wenn das ganze einmal weiter gediehen ist und die initialen Bugs weg sind, werde ich das ganze auch veröffentlichen und hier im Forum mal vorstellen.

Nun zu meinem Anliegen / Problem. Ich verwende unter anderem einen DPT vom Typ 7.007 (Zeit in Stunden) um die aktuelle Restzeit des Wartungszählers auf den Bus zu bekommen. Dabei stoße ich auf ein paar Hürden und frage mich, ob die Knx Implementierung an der Stelle fehlerhaft ist, oder ich zu Blöd dafür bin 😉. Ich komme aus der Java Welt und mein C++ Wissen ist teilweise begrenzt.
Mein Problem, ist das, "egal" wie ich den Wert übergebe auf dem Bus immer eine 0 ankommt.

Im ersten Schritt hatte ich es naiv so versucht:

GroupObject &groupObject = knx.getGroupObject(comObject);

KNXValue value = KNXValue((uint16_t)5);
groupObject.value(value, DPT_TimePeriodHrs);

Dann hatte ich mir valueToBusValueTimePeriod in dptconvert.cpp angeschaut und gesehn das hier ein tm struct verwendet wird. Also verschieden Varianten damit versucht:

tm time = {0};
time.tm_hour = 5;
KNXValue value = KNXValue(time)
groupObject.value(value, DPT_TimePeriodHrs);​
...
gmtime_r(0, &time);
time.tm_hour = 5;​
...
localtime_r(0, &time);
time.tm_hour = 5;
...
time_t hrs = 5;
gmtime_r(&hrs, &time);
...
localtime_r(&hrs, &time);
...
Diverse weitere Varianten...

Ich habe dann in valueToBusValueTimePeriod Log Ausgaben hinzugefügt und festgestellt das timeSinceEpoch (hier https://github.com/OpenKNX/knx/blob/...nvert.cpp#L997) in allen Fällen negativ ist - in den meisten von mir getesten Fällen um 3600 gegenüber meinem Wert.
Ich habe es jetzt aktuell so am laufen und bekomme korrekte Werte auf den Bus

time_t hrs = 5 + 3600; // Offset von 3600s / 1h
tm time;
gmtime_r(&hrs, &time);
KNXValue value = KNXValue(time);
groupObject.value(value, DPT_TimePeriodHrs);​

Sinnvoll erscheint mir das allerdings nicht.

Die Frage ist für mich erstmal, ist die Implementierung von valueToBusValueTimePeriod überhaupt korrekt / sinnvoll. Für mich erscheint es wenig sinnhaft hier ein tm struct zu verwenden. Am Ende des Tages soll ja kein Zeitpunkt übertragen werden sondern nur ein Zeitraum. Ich würde hier also ein einfaches uint16_t erwarten. Aber möglicherweise liegt das auch an meinem fehlenden Verständnis
Falls das wirklich so beabsichtigt ist stellt sich mir die Frage was ist der Sinn dahinter und wie kann das ganze korrekt verwendet werden.

Beste Grüße

[Ing-Dom]

und festgestellt das timeSinceEpoch (hier https://github.com/OpenKNX/knx/blob/...nvert.cpp#L997) in allen Fällen negativ ist

Darstellungsproblem?
große uint als int interpretiert werden negativ.. ?

in den meisten von mir getesten Fällen um 3600 gegenüber meinem Wert.

negativ gegenüber verstehe ich nicht.
Bei 3600 = 1h fällt mir spontan Zeitzone ein...

Die Frage ist für mich erstmal, ist die Implementierung von valueToBusValueTimePeriod überhaupt korrekt / sinnvoll.

auf den ersten Blick verstehe ich nicht was der ursprüngliche Autor sich dabei gedacht hat...
evtl die fehlannahme dass die daten als sekunden übertragen werden.. aber selbst da macht es wenig Sinn über time_t zu gehen.

evtl schaut unser Zeitexperte mgeramb mal drauf

[coko]

Empfehlung: Nutze beim Senden/Schreiben ins KO den DPT 7.001 (DPT_Value_2_Ucount) auf dem Bus macht das keinen Unterschied. Da kannst Du direkt uint16_t eingeben.

Nach History wurde die DPT-Konvertierung vor 7 Jahren (noch vor Beginn von OpenKNX) aus knxd-Implementierung umgesetzt und es ist durchaus möglich, dass das ganze schlicht und einfache eine Implementierung ist die ursprünglich mal erstellt wurde mit dem Ziel alle definierten DPTs mit abzudecken. Ich häte hier zumindest auch eine Fallunterscheidung nach Subtyp erwartet.

festgestellt das timeSinceEpoch (hier https://github.com/OpenKNX/knx/blob/...nvert.cpp#L997) in allen Fällen negativ ist - in den meisten von mir getesten Fällen um 3600 gegenüber meinem Wert.

Ohne das weiter geprüft/analysiert zu haben, vermute ich das dies auf die gesetzte deutsche Zeitzone (Standardeinstellung in Common) zurückzuführen ist.

[mumpf]

Ich weiß auch nicht, ob und wie der DPT7.007 implementiert wurde, fand das aber schon immer überflüssig (außer 5.001, damit da einheitlich gerechnet wird).
Der DPT7.007 sagt ja nur, wie Du die Zahl, die da ankommt, zu interpretieren hast. Es sagt nur, dass die 17, die über den Bus gesendet wird, 17 Stunden meint. Gesendet wird trotzdem nur eine 17. Und wenn Du in der ETS den DPT auf 7.006 stellst (Zeit in min), bleibt die Zahl 17 und es wird daraus nicht irgendwie magisch 17*60=1020.
Mach es also so, wie von coco vorgeschlagen und sende mit DPT7.*. In der knxprod gibst Du (für die ETS) normal 7.007 an und alle sind glücklich.

Gruß, Waldemar