Konnekting DeviceLib: Ko schreiben ohne senden

[Ing-Dom]

Wenn ich aus meinen Sketch ein KO schreiben will, ohne es direkt auf den Bus zu senden (sondern es nur zum Lesen bereitzustellen), gibt es dafür eine vorgesehene Lösung?
Klar könnte ich das S Flag wegnehmen und write nutzen, aber dann kann ich aus dem Sketch gar nicht mehr senden.

Von vielen kommerziellen Sensoren kennt man das Verhalten, dass KO zyklisch oder nur bei Änderung von x% gesendet werden, man aber jederzeit den aktuellen Wert Lesen kann. Sowas wollte ich realisieren, und denke aber, dass dies aktuell nicht möglich ist.

[tuxedo]

Hmm, das ist ein sehr guter einwand. Kannst du das bitte als Ticket bei Github aufmachen? Dann können wir das sicher noch einplanen. https://github.com/KONNEKTING/KonnektingDeviceLibrary


[update]
Hab gerade nochmal über den Code geschaut:

And a telegram is sent on the KNX bus if the com object has communication & transmit attributes

Eigenltich musst du nu das Transmit-Flag weglassen:

https://support.knx.org/hc/en-us/art...03188089-Flags

T-flag

The device will for this object transmit any updated object value, i.e. it will send a GroupValueWrite telegram to the bus. For a push button object this e.g. means that a rocker representing this object was manipulated.

Jetzt müsste man nur mal die Flags bei anderen Geräten checken, also ob da auch ein T Flag fehlt.

[update2]
In der Tat: Andere Devices haben alle das T bzw. Ü Flag, obwohl sie auf "nur zyklisch senden" eingestellt sind:
Bildschirmfoto vom 2018-12-19 10-08-15.png

Klingt so, als ob man der Lib noch ein write() beibringen muss, das nicht gleich sendet. Sollte kein Hexenwerk sein. Bitte wie gesagt ticket hierfür aufmachen.



[update3]
Denke da ist in der Tat ein konzeptionelles Problem in unserer Lib:

Normalerweise wird auf den Bus gesendet, wenn man auf das KO schreibt.
Und man kann über den Bus lesen was im KO drin steht.
Wenn ich nun aber die möglichkeit hinzufüge in das KO vom Sketch aus zu schreiben OHNE zu senden (writeWithoutSend()), dann müsste ich für das zyklische Senden auch noch eine Funktion einbauen die einfach das sendet was bereits im KO steht (sendWhatYouHave()).

Müsste man mal überlegen ob das nicht noch weitere Auswirkungen haben könnte...

[Ing-Dom]

Eigenltich musst du nu das Transmit-Flag weglassen:

ja, natürlich. Da bin ich beim Tippen durcheinandergekommen, ich meinte natürlich das T bzw Ü Flag.
So hab ich das auch in meinem aktuellen XML drin, hab es aber noch nicht getestet ob die Lib das auch korrekt umsetzt (also das Senden unterbindet, wenn das T flag fehlt).

ein writeWithoutSend wäre das was ich brauche. Ein sendWhatYouHave könnte man ja mit write umsetzen wenn man vorher das ko liest oder den wert sowieso im sketch hat.


https://github.com/KONNEKTING/Konnek...rary/issues/62

[Sonnengruesser]

+1
hab gedacht ich bin der einzige der sowas braucht.
Man könnte auch das flag während der Laufzeit ändern - aktuell in der Lib auch nicht möglich.

[tuxedo]

Mag da jemand einen Pull-Request für machen? Isse ist ja mittlerweile bei Gitlab gehostet:

https://gitlab.com/konnekting/Konnek...ry/-/issues/62

[tuxedo]

Ich roll das Thema nochmal auf, da ich da gerade dran bin.

Hab nochmal im Code nachgesehen:

Bei einem write() wird eine "txAction" angelegt. Mit dem nächsten Knx.task() wird das dann erkannt und der neue Wert ins KO abgespeichert. Nur wenn das T-Flag am KO gesetzt ist, sendet er die Daten aus dem Write bzw. der txAction auch auf den Bus. Fehlt das Flag, updatet er quasi nur das KO und mehr nicht.

Sprich: Lässt man das T-Flag weg, ist ein write() aufruf quasi ein "writeWithoutSend()". Hat das jemals jemand getestet?


Das die Thematik aber schon länger her ist: Kann mir jemand auf die Sprünge helfen was ich damit noch ergänzend gemeint haben könnte?

[update3]
Denke da ist in der Tat ein konzeptionelles Problem in unserer Lib:

Normalerweise wird auf den Bus gesendet, wenn man auf das KO schreibt.
Und man kann über den Bus lesen was im KO drin steht.
Wenn ich nun aber die möglichkeit hinzufüge in das KO vom Sketch aus zu schreiben OHNE zu senden (writeWithoutSend()), dann müsste ich für das zyklische Senden auch noch eine Funktion einbauen die einfach das sendet was bereits im KO steht (sendWhatYouHave()).

Müsste man mal überlegen ob das nicht noch weitere Auswirkungen haben könnte...

Ich denke nicht dass das hier ein konzeptionelles Problem ist. Vom Code muss das funktionieren: T-Flag weglassen und schon wird nicht mehr von alleine auf den Bus gesendet wenn ich das KO mit einem Knx.write() updaten will.
Das zyklische Senden das ich hier gemeint hatte, bezieht sich sicher auf die ansynchronität mit txAction und Knx-task()... Aber das ist irrelevant mit der T-Flag-Lösung.

Würde ich eine separate "writeWithoutSend()" Funktion bauen, müsste ich entweder direkt ins KO den neuen Wert abspeichern (von der Struktur her schlecht), oder eben wieder über die txAction-Liste gehen und hier eine neue Action einführen die schreibt, aber nicht sendet. Aber eben genau das macht das T-Flag. Siehe: https://gitlab.com/konnekting/Konnek...evice.cpp#L198

Lange rede kurzer Sinn: Wenn mir jemand schlüssig darlegen kann warum das mit dem T-Flag keine gute Lösung ist, dann bauen wir da was ein. Aber bis dahin müsste ich das Problem als "bereits gelöst" ansehen.

Any comments?

[Ing-Dom]

Die Lösung mit dem Flag lässt einen Use-Case außer Betracht:

Ein KO (z.B. Temperaturwert) soll zyklisch gesendet werden (z.B. alle 3min). Es soll aber auch jeweils der aktuelle Wert per Read gelesen werden können.

Hier wäre das setzen des T-Flag notwendig, weil man es ja ab und zu senden will.
Somit würde das "updaten" des KO per write (das ist nötig, damit beim Read aktuelle werte vorliegen), auch immer ein bustelegram auslösen.


=> Schön wäre das Feature schon.
Aber soo wichtig ist es auch wieder nicht, und eine Änderung nach einer V1.0 wäre auch ohne weiteres möglich.

=> Ich würde es zurückstellen.

[tuxedo]

Ich versuche immer zu überlegen: Wie machen das käuflich zu erwerbende Geräte.

Ich kann das Szenario nachvollziehen, halte es aber auch für nicht sooo wichtig.
Im Grunde lässt sch das sicherlich auch hinbiegen. Letztendlich hat man ja Zugriff auf alle KOs und könnte mit mit setIndicator() die Flags zur Laufzeit auch temporär verändern. Man muss nur über _comObjectsList das passende KO holen und setIndicator() aufrufen.

Also wer's wirklich braucht, bekommt das mit Bordmitteln hin, denke ich.

Bin mir unsicher ob es dazu wirklich eine separate Methodik bräuchte. Sollte man mal vorher genau recherchieren wie käuflich zu erwerbende Geräte das wohl machen/gelöst haben.

[Ing-Dom]

Ich versuche immer zu überlegen: Wie machen das käuflich zu erwerbende Geräte.

mein UseCase ist aus käuflichen Geräten.
z.B. die MDT Wetterstation.

Wie die das intern lösen? Keine Ahnung.
in der selfbus lib ist z.B. ko wert schreiben und ko senden entkoppelt.

[Ing-Dom]

Letztendlich hat man ja Zugriff auf alle KOs und könnte mit mit setIndicator() die Flags zur Laufzeit auch temporär verändern. Man muss nur über _comObjectsList das passende KO holen und setIndicator() aufrufen.

probier ich bei Gelegenheit mal aus...

[mumpf]

Hi,

ich bin zwar kein KONNEKTING Nutzer, hab aber eine Meinung .

Als Programmierer der Firmware würde ich erwarten, dass ich ein KO beschreiben kann und selber bestimmen kann, ob dieses KO seinen Wert sofort sendet oder nicht. Da ein KO von Außen (also über den Bus) jederzeit gelesen werden kann, möchte ich vielleicht aktuelle Werte drin haben, ohne dass sie sofort gesendet werden, aber ab und zu auch einen aktualisierten Wert senden. Das ist das Szenario, dass Ing-Dom beschreibt und das scheinbar über die temporäre Änderung von Flags funktioniert.

Ich frage mich aber, ob Flags das richtige Medium sind. Flags dienen ja dazu, per ETS (der im KONNEKTING-Fall über euer Parametrisierungswerkzeug) das Kommunikationsverhalten vom KO zu bestimmen. Ich kann also (als User, nicht als Programmierer) das Ü-Flag wegnehmen, wenn ich nicht wünsche, dass der Bus aktualisiert wird. Wenn man das also programmatisch ändern will, muss man immer erstmal schauen, ob das Flag überhaupt gesetzt ist, es dann entfernen, was ins KO schreiben und es dann wieder setzen (ich kenne jetzt nur die ETS-Flags, aber ich gehe davon aus, dass das T-Flag bei euch dem Ü-Flag entspricht).

Ein "writeNoSend" (das vielleicht die Schritte oben selbst macht) ist IMHO robuster und hilft Anfängern, Fehler zu vermeiden.

Gruß, Waldemar

P.S.: Es gibt derzeit ein gutes Beispiel für ein verrissenes Kaufgerät, dass writeNoSend nicht kann: der Steinel TP! Der schreibt nur seine Sensorwerte ins KO, wenn er auch sendet. Also Luxwert zyklisch alle 5 Minuten, nach 4:30 das KO lesen, man bekommt einen Wert, der 4:30 Minuten alt ist. Finde ich für ein Kaufgerät peinlich!