Konnekting Dimmer Software

[MaKre]

Hallo Eugen,

ich versuche gerade einen Dimmer mit einem Arduino Pro Micro und deiner Lib Dimmer32u4 aufzubauen. Ich habe mal 2 Fragen dazu:
1.) Am Pro MIcro gibt es leider keinen Pin 11 daher fehlt mir ein PWM Kanal. Kann man den Pin 11 irgendwie auf den Pin 3 o. 6 Legen?
2.) Wenn ich über den Busmonitor bei einem DPT 5.004 sende, ist bereits bei einem Wert von 127 --> 100% PWM erreicht (mit Oszi getestet). Kann ich das iwie anpassen?

Gruß

[Albatros62]

Hallo MaKre,
DPT 5.004 ist definiert als 0%-255%. Demnach müsstest Du eigentlich bei 100-->100% PWM erreichen. DPT 5.001 wäre für 0%-100% (Bytewert 0-255).

Gruß
Frank

[Ing-Dom]

1.) Am Pro MIcro gibt es leider keinen Pin 11 daher fehlt mir ein PWM Kanal. Kann man den Pin 11 irgendwie auf den Pin 3 o. 6 Legen?

Der Pro Micro hat leider das Problem dass der Pin leider nicht herausgeführt ist. Musste ich selbst feststellen, daher setzte ich auf den Micro (ohne Pro) - ist etwas größer.

Am Pro Micro kann man mit etwas Geschick den passenden Pin mit Silberlackdraht kontaktieren...

Der Micro ist nicht so günstig und etwas schwieriger zu bekommen. Ich hätte noch einen original verpackt, würde ich abgeben da ich neue Projekte nur noch mit dem ItsyBitsy M0 mache.

[MaKre]

Hi,
alles klar könen wir machen ;-) !
schreib mir ne pn was de haben willst und wohin mit der kohle.

[Eugenius]

1.) Am Pro MIcro gibt es leider keinen Pin 11 daher fehlt mir ein PWM Kanal. Kann man den Pin 11 irgendwie auf den Pin 3 o. 6 Legen?

Leider nein. Das ist eine Hardware Einschränkung die ich nicht umgehen kann.

2.) Wenn ich über den Busmonitor bei einem DPT 5.004 sende, ist bereits bei einem Wert von 127 --> 100% PWM erreicht (mit Oszi getestet). Kann ich das iwie anpassen?

Evtl. stehe ich auf den Schlauch... oder es ist wirklich ein Fehler:

DPT	Min = AUS	Mittel = 50% PWM	Max = AN	Auflösung
5.001	0%	50%	100%	~ 0,4 %
5.001	00h / 0	7Fh / 127	FFh / 255	~ 0,4 %
5.004	0%	127%	255 %	1 %
5.004	00h / 0	7Fh / 127	FFh / 255	1 %

Somit soll bei dem Wert von 127 immer noch 50% PWM sein, auch wenn man 5.001 und 5.004 vermischt.

[Albatros62]

Hallo Eugen,

Evtl. stehe ich auf den Schlauch... oder es ist wirklich ein Fehler:

DPT	Min = AUS	Mittel = 50% PWM	Max = AN	Auflösung
5.001	0%	50%	100%	~ 0,4 %
5.001	00h / 0	7Fh / 127	FFh / 255	~ 0,4 %
5.004	0%	127%	255 %	1 %
5.004	00h / 0	7Fh / 127	FFh / 255	1 %

Somit soll bei dem Wert von 127 immer noch 50% PWM sein, auch wenn man 5.001 und 5.004 vermischt.

Wenn Du die einzelnen Zeilen betrachtest, so stimmt die Tabelle. Allerdings passt die Überschrift nicht dazu. Mir erschließt sich aber auch nicht so ganz, wozu ich einen Bereich (bei 5.004) bis 255% benötige. Bei mir haben Lampen bei 100% volle Helligkeit und Rollos sind bei 100% vollkommen geschlossen. Hier noch ein Auszug aus den DPT-Definition:

DPT5.png
Ich hoffe, die Konnektig-Device-Library macht den entsprechenden Unterschied, da ich mich demnächst an einem Rolloaktor versuchen werde. Aber wir sind ja noch in der Beta-Phase.

Gruß
Frank

[Eugenius]

Konnekting Lib macht da alles richtig:
Es kommt ein Byte (0..255) rein und es wird ein Byte (0..255) weitergebeben, da es durch 5.xxx definiert ist. xxx ist dabei egal.
Was man mit den Werten anstellt ist die Sache von dem Programmierer. dass man 255 als % bezeichnet ist doof, aber es ist halt so.
wenn du von 0..255 Werten auf 0..100% runter skalierst (dein Fall) hast du 0.4% Auflösung. D.h. jeder Wert von 0..255 entspricht 0.4%
Wenn du 0..255 direkt nutzt, muss man nichts umrechnen, da ist 1:1 Zuordnung.
Aber in beiden Fällen wird intern mit 0..255 gearbeitet. Somit darf man 5.001 und 5.004 vermischen.

[Albatros62]

DPT5 sagt ja eigentlich nur, dass ein 8-Bit-Wert gesendet oder empfangen wird. Wie dieser Wert zu interpretieren ist, also in Prozent, Grad, Tarif etc. oder in welcher Scalierung wird durch .xxx definiert. Ich habe noch nicht nachgesehen, wie DPT5 in Konnekting Lib definiert wird. Wenn zwischen 5.001 und 5.004 differenziert wird, dann sollte die Lib die Umrechnung übernehmen. D.h. bei 5.001 übergebe ich der Lib 100 und sie sendet 255. Oder bei 5.003 übergebe ich 360 und es wird 255 gesendet. Wichtig ist, dass Sender und Empfänger die selbe Sprache sprechen. Wenn der Sender mit DPT5.004 100% sendet, dann wird der Dimmer, der den Wert als DPT5.001 interpretiert, nur 40% Helligkeit einstellen. Vermischen funktioniert also nicht.

[Eugenius]

Sender sendet nicht 100% (DPT 5.001), sondern 0xFF=255.
Und Empfänger empfängt auch 0xFF. Und meine Lib nutzt 0xFF als "komplett an". Somit sind es 100% die du erwartest.

P.S. gerade in ETS getestet:
5.001 50% (Hälfte von 100) gesendet, im Monitor $80 (0x80)
5.004 128% (Hälfte von 256) gesendet, im Monitor $80 (0x80)

somit ist ja alles richtig, zumindest was DPTs angeht.


PWM ist aber nicht linear zu KNX Werten, sondern Logarithmisch:
https://github.com/Adminius/Dimmer_4CH_UFI/blob/master/Dimmer_4CH_UFI.ino#L73

Hier ein paar Infos:
https://knx-user-forum.de/forum/projektforen/konnekting/1258293-konnekting-dimmer-software?p=1259820#post1259820

[Albatros62]

Das was Du in der ETS getestet hast ist genau das, was ich geschrieben habe. 100% werden bei DPT5.001 anders auf dem Bus dargestellt als bei DPT5.004. Wenn ich in meiner Visu aber 100% einstelle und der Visu sage, dass das dazugehörige KO ein DPT5.004 ist, so wird sie den Wert 0x64 auf den Bus legen. Wenn der Dimmer das dann als DPT5.001 interpretiert, so ist das ein Wert von 40%. Wie der PWM-Wert dann aussieht ist ein anderes Kapitel. Es geht also nicht um das, was auf dem Bus liegt (das ist immer ein 8-Bit Wert), sondern darum, wie der Empfänger das zu interpretieren hat, damit der Rolloaktor bei 100% nur über mein Fenster fährt und nicht auch noch über das Fenster meines Nachbarn unter mir .

[Ing-Dom]

Da hast du ein Verständnisproblem was die Lib leisten muss.

100% werden bei DPT5.001 anders auf dem Bus dargestellt als bei DPT5.004

korrekt

Wenn ich in meiner Visu aber 100% einstelle und der Visu sage, dass das dazugehörige KO ein DPT5.004 ist,

Dann hast du hier den ersten Fehler gemacht - das Gerät, dass die Lib verwendet, erwartet DPT 5.001

Es geht also nicht um das, was auf dem Bus liegt (das ist immer ein 8-Bit Wert), sondern darum, wie der Empfänger das zu interpretieren hat

Richtig - und Falsch. Üblicherweise wird bei KNX-Geräten in der Entwicklung festgelegt, welches KO welchen DPT hat. Und wenn du die Lib nutzt, dann ist das halt festgelegt auf DPT 5.001. Nur so funktioniert es wie gedacht.

Eine Einstellmöglichkeit des DPT über die ETS, die sich dann auf das Verhalten des Geräts auswirkt, ist üblicherweise nicht vorgesehen und wenn dann, explizit über einen Parameter.

[Albatros62]

Da hast du ein Verständnisproblem was die Lib leisten muss.

Wenn ich in der Lib das KO als DPT5 deklariere, so erwarte ich als Ergebnis einen 8-Bit-Wert. Wenn ich aber das KO als DPT5.001 deklariere, erwarte ich einen Prozentwert zwischen 0 und 100. Also müssen entweder die Deklarationen oder die Ergebnisse geändert werden. Das Gerät insgesamt ist dann auf z.B. DPT5.001 festgelegt, egal ob der bereits korrekt interpretierte Wert von der Lib an die Applikation geliefert wird oder ob die Umrechnung in der Applikation erfolgt. Nur zur Klarstellung: Mir geht es nicht darum, dass ich zu faul zum Umrechnen bin. Mir geht es um Klarheit bei der Anwendung der Lib. Da die Lib-Entwickler die Umrechnung sicher aus dem linken Ärmel schütteln wäre es zwar kein Muss, aber sicher wünschenswert.
Übrigens erwarte ich nicht, den DPT eines KO über die ETS oder Suite umzustellen. Die Funktionen des Gerätes erfordern KOs mit bestimmten DPT. Alles Andere macht keinen Sinn.

[Eugenius]

Aus den Ärmel ist es leider nicht... da es viel zu viele DPTs gibt.
Und wenn man genau nimmt dann doch nicjt so viele, weil nämlich Dpt 5 als 8bit Wert definiert ist, 8bit werden auch zurückgegeben.

nehmen wir DPT232.600 was willst du da zurück haben? 3x byte, oder R,G,B oder evtl doch H,S,V...oder?

Beim DPT 1 ist noch lustiger, es ist komplett egal ob es Freigabe, True, Ein, Offen oder was auch immer heißt. Ein bit ist es trotzdem

[Ing-Dom]

Mir geht es nicht darum, dass ich zu faul zum Umrechnen bin. Mir geht es um Klarheit bei der Anwendung der Lib.

Die Anwendung der Lib ist in meiner Meinung nach glasklar:
die Applikation bekommt den Wert, wie er im KNX-Telegramm steht. Interpretation ist Aufgabe der Applikation.

[Albatros62]

Die Anwendung der Lib ist in meiner Meinung nach glasklar:

Wie Du weiter oben lesen kannst, scheint doch der Eine oder Andere damit Probleme zu haben.

die Applikation bekommt den Wert, wie er im KNX-Telegramm steht. Interpretation ist Aufgabe der Applikation.

Daher ist diese Klarstellung doch wichtig.