Dpt 6.010

[Robert_Mini]

Hallo zusammen!

Denke hier gibt es einen Bug in der CV =>
https://knx-user-forum.de/forum/öffe...lue-hilfeeeeee

Schicke ich mittels Trigger mit dpt 5.010 den Wert 50 kommt im Gruppenmonitor $32 an => ok, schicke ich das gl. per dpt 6.010, kommt $50 an => falsch, den bis +127 sollte dpt 5.010 und 6.010 das gleiche liefern, darüber liegen die negativen Werte für signed value 8bit bei 6.010

Lg
Robert

[peuter]

Kann ich irgendwie nicht reproduzieren, wenn die die Funktion die diese Werte berechnet direkt aufrufe (in der Browser Console) kommt bei beiden dasselbe raus.

templateEngine.transformEncode('DPT:6.010', 50)
"8032"
templateEngine.transformEncode('DPT:5.010', 50)
"8032"

Mehr macht der Trigger auch nicht.

[Chris M.]

Unter https://github.com/CometVisu/CometVisu/pull/317 ist ein Fix.

Die Frage ist, ob es reicht den in Develop zu mergen, oder ob so etwas außerdem ein neues Bugfix-Release rechtfertigt? (Einerseits ist's gavierend, andererseits ist's bisher niemanden aufgefallen...)

[peuter]

Zusammen mit einigen optischen Fixes im Bereich Infoaction in der Navbar (wenn ich mich recht erinnere sind die im letzten Release noch nicht drin?), würde ich da schon für ein Bugfix Release plädieren.

Im Idealfall findet sich vorher ein Freiwilliger, der die KNX-Transforms mal komplett mit Unittests versieht um eventuelle weitere Probleme zu finden. Ich hab das bei den openHAB Transforms bereits gemacht und dabei auch noch ein paar Fehler gefunden. Ich kenne mich aber mit den Ganzen DPT-Umwandlungen nicht aus, daher macht das wenig Sinn wenn ich die Tests schreibe.

Der PR ist übrigens gemerged.

[Chris M.]

Kann mir ein Git[Hub] Profi (starwarsfan? jolt?) helfen, wie ich nun die entscheidende (= letzte) Änderung des https://github.com/ChristianMayer/Co..._transform_knx nach https://github.com/CometVisu/CometVi.../release-0.9.1 (oder müsste das Ziel https://github.com/CometVisu/CometVisu/tree/master sein?) bekomme?

[peuter]

Den Branch in den das rein soll auschecken und dann cherry-picken (mit der richtigen commit-id):

git cherry-pick 3c001c15d120e145c0865b3350645bffbb580f19

Müsste master nicht momentan == release-0.9.1 sein. Und müssten wir dann nicht einen neuen release-0.9.2 branch machen (vom master) und dass dann darein picken, Version anpassen und daraus den Build erstellen? Man möge mich korrigieren, wenn ich falsch liege.

[starwarsfan]

Jap, so wie peuter hätte ich das nun auch gesagt. Um detailiert einzelne Changes zu holen, wird unter Git Cherry-picking verwendet:

1. Sicherheitshalber den Branch mit den gewünschten Changes lokal updaten (auschecken und pullen)
2. Den Branch auschecken, auf den die gewünschten Changes gelangen sollen
3. Via Cherry-pick unter Angabe des Commit-Hash den Change auf den aktuellen Branch holen:
   

   git cherry-pick <commit-hash>

[Chris M.]

So, ich hab mal mein Glück probiert:
0.9.2 vom 0.9.1 in upstream gebrancht. Davon einen weiteren branch in origin und da dann der cherry-pick. Für den gibt's nun einen Pull-Request nach 0.9.2.

[Chris M.]

Release 0.9.2 ist soeben online gegangen mit dem Fix für das Problem aus diesem Thread