[DISKUSSION] [V4.0 IP2] Funktion Logik Dim-Aktor

[maggyver]

Die bisherigen Postings haben gezeigt das es ein verdammt guter Baustein werden wird.

Robert, so war das jetzt auch nicht zu verstehen.

Es geht halt um einen virtuellen Dimmaktor, der bestimmte Funktionen von KNX auf ein anders "System", "universell" in grenzen anpassbar, zu übersetzen vermag ohne unnötig komplex zu werden.

Dabei darf und sollte man sich schon die Fragen stellen dürfen, wie wir es bisher getan haben.
Es ist wichtig den Mittelweg zu finden.
Vielleicht muss man auch nur einige Beispiele dem Dimmaktor Logikbaustein als visuelle Unterstützung beilegen.

Robert, fangen wir doch mal klein an und konzentrieren uns nur mal auf die Umsetzung, mit Dimmausgang, Statusausgang, Rückmeldeeingang, Begrenzungsaktivierungseingängen, allen dazu nötigen Parametereingängen (Zykluszeit, Schrittweite, Vorgabe Mindestdimmwert (Begrenzung), Vorgabe Maximaldimmwert (Begrenzung)).

Also Baustein nach Funktionsbeschreibung wie in Beitrag 29 beschrieben ohne Schalteingang Ein/Aus für Dimmausgang oder Schaltausgang für Ein/Aus bei Dimmvorgang.

Die Funktion "Ein/Aus-Schalten über Dimmen zulassen" heben wir uns für später auf, wenn das wirklich benötigt wird.

[Robert_Mini]

Hallo zusammen!

Ich werde da mal zeitnah was zaubern.
Beitrag 29 wird die Arbeitsbasis. Ein/Aus über Dimmen und zusätzlicher Ein/Aus-Eingang heb ich mir als Add-on auf.

lg
Robert

[maggyver]

Hallo Robert,

wir lassen uns mal einfach überraschen womit der "godfather of custom logic" bei der umsetzung uns überraschen wird.

[Robert_Mini]

@maggyver
Deckt die „Spezifikation“ im Thread 29 eigentlich den Umfang ab, den deine Freundin in NodeRed umgesetzt hat?

Wenn sie Interesse hat, damit den Schritt zu Custom Logiken zu machen, könnte ich das wieder als Schritt für Schritt Anleitung gestalten…

Lg
Robert

[maggyver]

@Robert_Mini

Deckt die „Spezifikation“ im Thread 29 eigentlich den Umfang ab, den deine Freundin in NodeRed umgesetzt hat?

Wenn sie Interesse hat, damit den Schritt zu Custom Logiken zu machen, könnte ich das wieder als Schritt für Schritt Anleitung gestalten…

Ich habe mich mit Ihr gerade vorhin ausgetauscht und Sie hat sich mit der "Custom Logik" noch nicht befassen können. Ich habe Ihr von dir erzählt und deinem "Angebot in Form einer Schritt für Schritt Einleitung/Anleitung". Sie meinte, dass Sie sich sehr darüber freuen würde, wenn du das machen könntest, aber nur wenn es dir keine Umstände macht.

Ich denke das die "Spezifikation" im Beitrag 29 den grundlegenden Umfang abdeckt den meine bessere Hälfte in NodeRed umgesetzt hat. Es gibt zwar noch einen zusätzlichen Parameter, der bei der Anpassung dieses speziellen Shellys benötigt wird. Das kann Sie ja dann selbst noch zusätzlich realisieren ... sozusagen als erste Übung ... in Sachen "Custom Logik".

Nachtrag:

Sie meinte noch, wenn der absolute Dimmwert aus dem TWS Logikbaustein "Virtueller Dimmaktor" kommt, dann ist die Ansteuerung des Shellys anders und zudem wesentlich einfacher. Der zusätzliche Parameter, speziell für den Shelly, könnte dann sogar entfallen ...

Schalten KNX ----> an Shelly über MQTT
Relatives Dimmen mit Stopptelegramm KNX ----> über TWS Logikbaustein "Virtueller Dimmaktor" Ausgang "Absoluter Dimmwert" ----> an Shelly über MQTT

Status Shelly über MQTT ----> an Schalten KNX, wenn Einflächenbedienung vorliegt und/oder für eine "richtige" Statusanzeige
Status Shelly über MQTT ----> an den TWS Logikbaustein "Virtueller Dimmaktor"

[StefanW]

Hi,

es gibt da ein Thema mit Dimmern, das beschäftigt uns gerade hinsichtlich der Timberwolf Visu und da gibt es einen Gedanken, den ich mit Euch teilen möchte, weil evt. ist das auch hier beachtenswert. Es geht um die "überschreibende Dimmkorrektur" durch einen anderen Teilnehmer (ich nenne es mal so).

Übliches Szenario für das überschreibende Dimmkorrektur: Baby- / Kinderzimmer (eigentlich auch Schlafzimmer / Bad / Gang) sollen in der Nacht natürlich nicht auf 100% hochgedimmt werden, wenn der Bewegungsmelder eine Bewegung erkennt. Ob moderne BM / PM das heute besser können, weiß ich nicht, aber früher war es so, dass dann eine Logik (wo auch immer diese läuft) erkannte, dass das Haus auf "Schlafen" steht und das Licht weit geringer gedimmt werden sollte. Der BM / PM konnte damals nur die 100% (oder den binären Befehl für Licht an) und deshalb hat diese Logik dann einen neuen Dimmbefehl "hinterher gesendet".

Das Dimmen von 0 auf 100% (angefordert durch den BM / OM) wird vom Dimmer üblicherweise in 1 bis 2 Sekunden umgesetzt. Wenn eine Logik hier schnell genug eine Korrektur hinterher sendet, z.B. 10%, dann kann der Dimmer das abbrechen, wenn er den neuen Befehl in ein bis zwei Zentel Sekunden erhält.


Gedanken zur Timberwolf Visu (formerly known as "Instant Visu"):

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
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)

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.


Bezüglich dieses virtuellen Dimmers:

Auch hier besteht das grundsätzliche Möglichkeit, dass "irgendeine andere Logik" einen anderen Wert sendet, der womöglich auch eine autoritative Korrektur sein soll. 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.

lg

Stefan

[maggyver]

Hallo StefanW,

dafür dachte ich hätten wir den optionalen Eingang Dimmwertvorgabe (Integer) vorgesehen.

Zumindest hatte ich das so in Erinnerung (Beitrag 27).

Dann kann man von extern einen Wert schicken, der dann wiederum einen Dimmvorgang auslöst bzw. ein Nachführen ermöglicht.
Zusätzlich die optionalen Eingänge für Setzen des Dimmausgangs auf Min/Max-Dimmwerte über Parameterwerte.

Damit sollte doch alles erfüllt sein oder nicht?

Nachtrag:

Wir benennen verschiedene Funktionen anders, meinen aber sicherlich das absolut Gleiche.

[gbglace]

Ja bei der Verwendung dieses Dimm-Logikbausteins als virtuellen Dimmer, würde man dann alle anderen Intelligenzen in den Geräten ausbauen, da man durch diese Dimmwertgrenzen, die per Objekt getriggert aus einer (Morgens/Tag/Abends/Nacht)-Logik/Status gesetzt werden.

Der Baustein bekommt auch einen Statusausgang, wobei der dann zumindest im KNX quasi neben dem des Aktors existieren würde. im DMX wäre dies der relevante Status-Dimmwert. er ist aber glaube dann derzeit so geplant umzusetzen das dieser am Ende des Dimmvorgangs einmalig sein Ergebnis zurück liefert, und nicht jeden einzelnen Absolutwert während der Dimmrampe.

Nach meinem Urlaub werde ich auch meine KNX-Anlage um einige Geräte erweitern und dann auch mal einige alte recht "dumme" PMs per OpenKNX-VPM Modul aufrüsten. Da kommen dann auch all solche Überlegungen zum tragen.

Wenn der Dimmer schon solche Intelligenz hat, dann erleichtert das auch die ganze manuelle Bedienung auch neben den PM's per Taster um Automatiken überstimmen zu können. Wobei wir da bei der Ausgestaltung eine effektiven Schalt-Eingangs noch das richtige verhalten ausknobeln.

[maggyver]

Der TWS Logikbaustein "Virtueller Dimmaktor" soll ja zusätzlich zur Umsetzung des "KNX Relativen Dimmen mit Stopptelegramm" und Anpassung an andere Welten auch noch die vereinfachte Einbindungsmöglichkeiten von Wertgebern und Binärgebern gepaart mit der nötigen Intelligenz vereinen, um Vorgaben von Grenzwerten auch von extern über die Parametereingänge zuverändern, usw.

Das mit dem Schalteingang muss man separat betrachten, aber ich denke das wird sich zeigen was dann dabei sinnvoll ist. Auch ob man optional einen zweiten Statusausgang benötigen oder den vorhandenen Statusausgang nur erweitert um dessen Verhalten umschaltbar zu machen, werden wir sehen.

Ich denke wir sind auf einem guten Weg, jetzt machen wir einen Schritt nach dem Anderen.

[StefanW]

Hi René,

dafür dachte ich hätten wir den optionalen Eingang Dimmwertvorgabe (Integer) vorgesehen.

Diese nachträgliche Korrektur kommt eben im Nachhinein, wenn der virtuelle Dimmer schon gestartet ist, dies wäre zu berücksichtigen, dass er ggfls. abbricht.

Worauf ich hinaus wollte, dass es eine zeitliche Sache ist.

lg

Stefan