ElabNET Technik Forum

Hallo Stefan!

Ich denke wir sollten das in einem getrennten Thread diskutieren - Forenregeln (ich trenne das ab, wenn für dich ok).

Zu den einzelnen Themen:

Die klassische Umsetzung im KNX ist, so wie von dir beschrieben, das hinterhersenden eines absoluten Dimmwertes auf einen EIN-Befehl oder einen 100% Befehl.
Aktuelle PWM haben ein Eingangsobjekt, das den Sollwert steuern kann, nutze ich aber nicht.

Das "Hinterhersenden" passiert in einer Logik, ohne dass etwas begrenzt wird. Damit kann man manuell jederzeit heller dimmen. Mit einem 2. Tastendruck wird auch auf 100% gedimmt (gibt es als Custom Logik hier: viewtopic.php?f=65&t=2479)

So etwas sollte meiner Meinung mach funktional in die Logik, dein Gedanke zur Anzeige gefällt mir aber.

StefanW hat geschrieben: ↑Sa Feb 25, 2023 5:46 pm Einer der Power Widget wird eine Dimmeransteuerung (plus Farbe und Szenen, aber das ist hier nicht relevant):
1. Wir wollen in der Visu anzeigen, dass ein Befehl "unterwegs" ist, es aber noch keine Rückmeldung gibt

Man muss hier zwischen Tasten und Slider unterscheiden.
Bei einem EIN-Taster braucht es keine Anzeige, ein 100% Trigger ist eventuell verwirrend, wenn nur 20% rauskommen. Da wäre eine Anzeige mittels weiterem Objekt denkbar, aber ich denke nicht nötig.

Beim Slider (in der CometVisu) funktioniert das so: Man setzt einen Dimmwert per Slider, das Rückmeldeobjekt setzt den Slider dann auf zb. 20% zurück. Die Nachtrigger-Logik erlaubt dann sehr wohl ein Dimmen auf 100%, wenn man erneut den Slider auf 100% zieht.

Irgendwie finde ich den Gedanken gut, das 20% Limit sichtbar zu machen, aber so richtig rund wir das im Kopf bei mir nicht.

StefanW hat geschrieben: ↑Sa Feb 25, 2023 5:46 pm 2. Wir wollen, sofern ein Dimmer dies laufend zurück gibt, auch die erhaltenen Zwischenwerte laufend anzeigen (sowas ist auch bei Garagentoren interessant, die länger benötigen um zu öffnen und zu schließen - sofern es hier auch Rückmeldungen gibt)

Sollte so angezeigt werden. In % oder mittels Slider Position. Cool wäre ein doppelter Slider. Der Knopf für den Sollwert, der Rahmen des Knopfes für die Rückmeldung. Nach dem Dimmvorgang liegen sie übereinander, beim Ziehen des Sliders bleibt der Rahmen stehen und wandert dann schrittweise bis zum Sollwert...

StefanW hat geschrieben: ↑Sa Feb 25, 2023 5:46 pm Unsere Diskussion war nun: Was ist mit "nachträglicher Dimmkorrektur"? Wir überlegen, dass wir im Widget ein Objekt dafür vorsehen, bei dem solche dynamischen Dimmkorrekturen eingespeist werden können, so dass man dies an der Visu anzeigen kann (da sich ein Bediener womöglich wundert, dass er 95% eingestellt hat, aber es einfach nicht heller als 15% wird, weil das eine dynamisch gesendete Korrektur (kann auch eine konkurriender Befehl durch eine andere Visu sein) ist.

Finde ich zu kompliziert. Das einen ist ein parallel abgesetzter Dimmbefehl (Sollwert), das andere eine Dimmgrenze (anderes Objekt).

StefanW hat geschrieben: ↑Sa Feb 25, 2023 5:46 pm Bezüglich dieses virtuellen Dimmers:
Es wäre daher nachzudenken, ob insbesondere bei der hochdimmenden Betriebsart durch "regelmäßige inkrementelle Vorgabewertaussendung" nicht ein Eingang vorgesehen werden sollte, der dymanische Nachkorrekturen von dritter Stelle entgegennehmen kann - on the Fly und daran den Dimmvorgang anpasst.

Ich nehm das so mit.

lg
Robert

Hallo,

ich sehe das wie Robert bezüglich des Einganges zur nachträglichen Dimmkorrektur. Das ist im Prinzip gesehen eine eigenständiger neuer Dimmbefehl mit einem neuem Dimmwert.

Gedanken dazu:

Eventuell muss das Verhalten dieses Dimmeinganges (Integer) im Bezug auf eventuell eingestellte Dimmgrenzen anpassbar sein, damit es eben möglich sein wird darüber den ganzen Dimmbereich ansprechen zu können, auch wenn Dimmgrenzen über Parametereingänge gesetzt wurden. Wie eine Art Übersteuerung der Handeingabe per Automatik ... wenn der Anwender den Eingang nicht zur Anpassung an eigener Wertgeber nützt ...

Das kann man ja mal im Hinterkopf behalten.

Wir reden außerdem von einem relativen Dimmbefehl als Eingangsgröße, d.h. ein Taster ist gedrückt.
Wenn da gleichzeitig jemand wo anders drückt, dann wird das am Aktor kurz überschrieben, bis der nächste Zyklus des Dimmbausteins wieder den nächsten Absolutwert sendet.

Das passt aus meiner Sicht.

Lg
Robert

Hallo,

habe uns mal eine kleine Skizze gemacht und ein wenig die Eingänge und Ausgänge beschrieben.

Nicht perfekt, aber ein Anfang.


Nachtrag:

Aufnahme der zurückgestellten Funktionen in Skizze.
Fehler in Wertebereich Inkremente behoben.

Servus Rene!

Hab grad mit dem Tutorial begonnen, da überholst du mich rechts

2 Fragen, damit es klar ist:
- Absoluter Dimmwert hatte ich noch nicht am Radar, sollte aber kein Problem sein.
- Schrittweite in %, also das Increment um das der Dimmwert je Zyklus erhöht wird
- Zykluszeit: Zeit für den gesamten Dimmvorgang 0-100% oder zwischen Inkrementen?

lg
Robert

Hallo Robert,

du mein Gaspedal ist digital und kennt daher nur folgende Zustände "AUS/EIN/KAPUTT" bzw. "0/1/-1" ...

Die Schrittweite ist die Inkremente, eigentlich von 1 bis 100 in Prozent (sollte ich noch ändern auf der Skizze --> erledigt), um den Dimmwert pro Zyklus zu verändern, je nach Dimmrichtung.

Absoluter Dimmwert als Eingang sollte den Dimmvorgang starten bzw. bei einem bestehenden Dimmvorgang das "Nachführen des Dimmwertes" über einen externen zugeführten Wert ermöglichen und zusätzlich die Intelligenz des "virtuellen Dimmaktors" gleich mitzubenützen für etwaige Begrenzungen Min/Max für den Dimmausgang.

Bezüglich der Zykluszeit ... gute Frage ... würde sagen das man hier am einfachsten die Zeit für den gesammten Dimmvorgang, also den kompletten Durchlauf der Rampe von 0 zu 100 bzw. von 100 zu 0 einstellen können sollte. Es gibt bestimmte Szenarien wo es von Vorteil sein würde die Zeit zwischen den Inkrementen vorgeben zu können ... was meinst du dazu Robert?

Hallo zusammen!

Es geht hier los: viewtopic.php?f=65&t=4128#p45905

Bitte um eifriges Mitmachen, damit wieder ein paar mehr auf den Custom Logik Zug aufspringen können!

lg
Robert