Oszillatorbaustein

[saegefisch]

Danke Christian! Aber mach erst mal wichtiges, die paar fehlenden Trigger schafft man auch gerade noch selber...

[gaert]

Ich habe mal zwei Beispiele vorbereitet - damit man diese neue Funktionalität besser verstehen kann:

Beispiel 1:
Ein ganz einfacher Oszillator (High/Low-Periode gleich lang, keine Zyklusanzahl, etc.):

    if (($E=getLogicEingangDataAll($id)) && ($V=getLogicElementVarAll($id))) {

        if (getLogicElementStatus($id)==0) {
            if ($E[1]['value']==1 && $E[1]['refresh']==1) { //Start

                setLogicElementVar($id,1,1);     //High-Periode
                setLogicLinkAusgang($id,1,1);
                setLogicElementStatus($id,true,$E[2]['value']);    //### 
                
            }
        } else {

            if ($E[1]['value']==0 && $E[1]['refresh']==1) {

                setLogicLinkAusgang($id,1,0);
                setLogicElementStatus($id,false); //Stop

            } else {

                //"High"-Periode fertig
                if ($V[1]==1) {
                    setLogicElementVar($id,1,0);    //Low-Periode                
                    setLogicLinkAusgang($id,1,0);
                    setLogicElementStatus($id,true,$E[2]['value']);    //###
                } else {
                    setLogicElementVar($id,1,1);    //High-Periode                
                    setLogicLinkAusgang($id,1,1);
                    setLogicElementStatus($id,true,$E[2]['value']);    //###
                }

            }


        }
    } 

Beispiel 2:
Das gleiche in grün, allerdings wird die "Verzögerung" jetzt nicht einmalig(!) gesetzt wie oben, sondern als Interval. Es genügt also ein einziger Aufruf von setLogicElementStatus() - natürlich genügt dies hier nur, weil die Periodenlänge von High und Low gleich groß sind:

    if (($E=getLogicEingangDataAll($id)) && ($V=getLogicElementVarAll($id))) {

        if (getLogicElementStatus($id)==0) {
            if ($E[1]['value']==1 && $E[1]['refresh']==1) { //Start
​
                setLogicElementVar($id,1,1);     //High-Periode
                setLogicLinkAusgang($id,1,1);
                setLogicElementStatus($id,true,$E[2]['value'],true);    //### true=als Intervall
                
            }
        } else {

            if ($E[1]['value']==0 && $E[1]['refresh']==1) { 

                setLogicLinkAusgang($id,1,0);
                setLogicElementStatus($id,false); //Stop

            } else {

                //"High"-Periode fertig
                if ($V[1]==1) {
                    setLogicElementVar($id,1,0);    //Low-Periode                
                    setLogicLinkAusgang($id,1,0);
                } else {
                    setLogicElementVar($id,1,1);    //High-Periode                
                    setLogicLinkAusgang($id,1,1);
                }

            }


        }
    } 

[WagoKlemme]

Unterschied jetzt mit 1.20, sonst alles wie #48:

Edomi_Last3.png

[WagoKlemme]

Aber wofür könnte man noch mehr Trigger im Haushalt brauchen? Sicher gibt es bestimmte Logiken, die hier und da vielleicht noch eine spezielle Lösung mit einem Timer brauchen. Alles was flackern oder blinken soll, geht über Animationen. Ich lasse mich gerne inspirieren. Oder ich habe den Zweck eine Oszillators - im Kontext der Haussteuerung (!) - noch nicht verstanden?

Wenn Du beispielsweise zusätzliche (zu KNX) Hardware einbinden willst/musst. Bei mir ist das die Wago und 1-wire dann brauchst Du viele Oszillatoren. Die kann ich nur reduzieren wenn ich, was ich schon mache und noch weiter ausbauen möchte, die Werte auf den KNX-Bus schreiben lasse.

[wintermute]

Wenn Du beispielsweise zusätzliche (zu KNX) Hardware einbinden willst/musst.

Im Audio-Steuerungs-Bereich auch: zB um regelmaessig die aktuelle Abspielposition abzufragen (wenn das in der Visu als "Fortschirttsbalken" oder so angezeigt werden soll). Das laesst sich bestimmt auch irgendwie ueber CSS aus "Anfangsdaten" volldynamisch erstellen, ich weiss aber nicht wie

[gaert]

Das wäre relativ einfach per CSS zu lösen: Animation erstellen (in EDOMI natürlich) und dann im Feld "Dauer" (Design) des Visuelements den Platzhalter {#} für's KO eintragen (ggf. noch mit Umrechnungsformel). Sofern das KO z.B. die Titellänge in Sekunden enthält, würde die Animation dann entsprechend lange laufen. Stop/Pause etc. sind so natürlich nicht ohne Weiteres möglich...

Ich persönlich bin kein Freund von zyklischen Geschichten - erstrecht nicht bei KNX (mit Aussnahmen wie Watchdog, Wetterstation, usw.). Die geringe KNX-Bandbreite möchte ich nicht mit irgendwelchen "Blinkeffekten" ausreizen, dafür ist KNX einfach nicht designed. Intern (KOs) ist's natürlich was anderes, aber auch hier versuche ich nach Möglichkeit immer andere Wege zu finden (CSS zum Beispiel).

[wintermute]

Die geringe KNX-Bandbreite möchte ich nicht mit irgendwelchen "Blinkeffekten" ausreizen, dafür ist KNX einfach nicht designed. Intern (KOs) ist's natürlich was anderes, aber auch hier versuche ich nach Möglichkeit immer andere Wege zu finden (CSS zum Beispiel).

Da sind wir einer Meinung

[gaert]

Ausgezeichnet

Es ist ausserdem ja so, dass die Visu je nach Einstellung max. Sekündlich aktualisiert wird (bei mir sind's 3 Sekunden). Und dies natürlich asynchron... Um also ein Visuelement blinken zu lassen, wäre ein Oszi etc. vollkommen ungeeignet - dies muss per CSS erfolgen (und ist auch um einiges sinnvoller und flexibler). Um Deinem Beispiel mit der Abspielposition zu folgen: Ich würde einfach bei "Delta-X" im Design eine KO-Formel {#...} eintragen - und schwupp wird das Visuelement (ein Zeiger oder so) rein per CSS/JS an die berechnete Stelle verschoben. Und das ganze stufenlos und ohne Logik etc...

Ich "fürchte", dass viele noch im HS-Schema denken - da gibt es solche CSS/JS-Geschichten ({#...}) nicht.

[wintermute]

Um Deinem Beispiel mit der Abspielposition zu folgen:

Vielleicht koennte jemand der den Squeeze Baustein testet mal aufschreiben wie man sowas macht. Der (optionale) Oszi dadrin stoert mich naemlich auch noch ein wenig
Überhaupt brauch ich so langsam mal ne Visu o\

[rdeckard]

Alles, was unter 1-2 Sek. blinken sollte, ist meiner Meinung eh viel zu nervös. Egal, mit oder ohne CSS

Aber eben...die Geschmäcker sind verschieden oder ist gibt mal plötzlich eine Design-Anwendung, an die man vorher nie gedacht hätte...ich kann mir aber im Moment keine vorstellen...

[gaert]

wintermute
Das ist eigentlich ganz einfach: Dein LBS müsste ein KO setzen (also zunächst einen Ausgang natürlich), das die aktuelle Position z.B. in Prozent enthält. In der Visu kann man dann im "Design" mit diesem KO arbeiten, also z.B. die X-Position (Pixel) dynamisch verändern (oder auch zig andere Eigenschaften).

Die Umrechnung von Prozent in Pixel hängt natürlich von der Visu-Gestaltung etc. ab, daher kann man diese "Formel" *hust* direkt in dem Visuelement angeben.

Beispiel:
Im Design trägst Du im Feld "Delta-X" (also X-Translation quasi) den Wert {#} ein. Dies ist ein Platzhalter für das KO, das dem Visuelement zugeordnet ist. Dies hat zur Folge, dass das Visuelement um diesen Betrag (in Pixeln) verschoben wird - bei jedem Refresh. Am Besten wäre es daher, wenn Dein LBS die Abspielposition in Prozent ausgibt, denn dann kann man die reelle Position des Visuelement am Ende besser berechnen: Wenn das Visuelement z.B. um 200px (=100% Abspielposition) maximal verschoben werden soll: {#*2} Voila

[wintermute]

Dein LBS müsste ein KO setzen (also zunächst einen Ausgang natürlich), das die aktuelle Position z.B. in Prozent enthält. In der Visu kann man dann im "Design" mit diesem KO arbeiten, also z.B. die X-Position (Pixel) dynamisch verändern (oder auch zig andere Eigenschaften).

Haben wir
Die Vorgehensweise ist auch prinzipiell (also in der Theorie) klar, aber um die % zu refreshen brauchts halt den Oszi... das ist kein Weltuntergang, es reicht ja einer fuer alle Clients zusammen.
Zumindest fuer den Anfang wird das so ausreichen, denke ich...

gruesse .. Michael

[gaert]

Du meinst einen internen Oszi (aka Schleife) in Deinem LBS - oder braucht Dein LBS einen externen "Taktgeber"? Nur zur Sicherheit: Visu & Co. braucht keinen Oszi. Wenn Dein LBS zyklisch den entsprechenden Ausgang setzt genügt dies vollkommen.

[wintermute]

Du meinst einen internen Oszi (aka Schleife) in Deinem LBS - oder braucht Dein LBS einen externen "Taktgeber"? Nur zur Sicherheit: Visu & Co. braucht keinen Oszi. Wenn Dein LBS zyklisch den entsprechenden Ausgang setzt genügt dies vollkommen.

Momentan ist er auf einen externen angewiesen... da das optional ist (fuer die eigentlich Funktionalitaet absolut nicht erforderlich) war es fuer mich einfacher das erstmal so zu loesen. Halte ich auch eigentlich fuer besser, vor allem weil - je nach Haushalt - da locker nen Dutzend Client-Bausteine zusammen kommen koennen. Irgendwie hab ich ein ungutes Gefuehl dabei wenn die alle, jeder fuer sich, vor sich heroszillieren
Obwohl das im Endeffekt vermutlich eh alles auf dasselbe rauskommen wuerde... O(n) und so...

gruesse :: Michael

[gaert]

Richtig... Ich denke sogar, dass das "vor sich hin oszillieren" (EXEC) am Ende performanter wäre - schließlich entfällt dann der ganze "Overhead" (Eingang => DB => LBS => EXEC....).