Logik: Wie 4 unterschiedliche Befehle abhängig von 2 Werten ausführen?

[rdeckard]

Hallo
Da ich eher der Script-Typ bin, habe ich manchmal Mühe, eine Logikaufgabe mit dem Logikeditor umzusetzen.

Ich bekomme von einem vorgeschalteten LBS zwei Werte zurück (jeweils 1 oder 0). Von diesen Total 4 Kombinationen möchte ich dann jeweils einen Befehl (Sequenz) ausführen. In einem Script wäre das ungefähr folgender Pseudo-Code:

Wenn Wert 1=[COLOR=#FF0000]0[/COLOR] und Wert 2=[COLOR=#FF0000]0[/COLOR] dann Befehl 1
Wenn Wert 1=[COLOR=#FF0000]0[/COLOR] und Wert 2=[COLOR=#FF0000]1[/COLOR] dann Befehl 2
Wenn Wert 1=[COLOR=#FF0000]1[/COLOR] und Wert 2=[COLOR=#FF0000]0[/COLOR] dann Befehl 3
Wenn Wert 1=[COLOR=#FF0000]1[/COLOR] und Wert 2=[COLOR=#FF0000]1[/COLOR] dann Befehl 4

So siehts im Logikeditor aus. Aber welche Logik muss ich zwischen links und rechts einfügen, damit jeweils nur ein Befehl ausgeführt wird? logik.png



Vermutlich völlig einfach, aber ich sehe es einfach nicht...

[gaert]

Naja, prinzipiell z.B. ein UND-Gatter

Das Problem ist aber: EDOMI arbeitet event-getriggert, d.h. es gibt u.U. gewisse Timing-Probleme - denn die Frage ist ja: *Wann* ist der z.B. Wert1=0? Ist Wert2 dann bereits gesetzt oder trudelt der neue Wert "irgendwann" ein?

Einen IF-THEN-ELSE-Logikbaustein im engeren Sinne kann es also prinzipbedingt nicht geben, denn im Gegensatz zu einem Script werden Logiken in EDOMI *nicht* einfach sequentiell abgearbeitet.

Ich hoffe das war einigermaßen verständlich

[jonofe]

Man könnte es auch wie folgt machen:

Screenshot from 2017-04-22 23-35-21.png
Aber wie schon von Christian angedeutet, ist wichtig zu wissen, dass bei jedem Ändern von A oder B der entsprechende Ausgang gesetzt wird.

Statt der Klemme am Ende müsstest du natürlich 4 Ausgänge "=1" dranhängen.

Insbesondere die Initialisierung könnte interessant sein, denn diese Logik würde bei nicht initialisierten Werten A und B zunächst den Fall A=0 und B=0 auslösen.

Vielleicht hilft das ja weiter ....

[rdeckard]

Die Werte 1 und 2 kommen "gleichzeitig" von einem LBS links (sind Ausgänge von diesem LBS) und bleiben auch während der Logikabfrage konstant.
Somit werde ich vermutlich kein Timing-Problem damit haben.

Bei der Hilfe zum Und-Gatter steht:
"Dieser Baustein bildet ein UND-Gatter nach. Wenn alle(!) Eingänge mit einem Wert ≠0 belegt sind, wird A1=1 gesetzt. Ist einer der Eingänge =0 wird A1=0 gesetzt."

Die Variante 1+1 wäre kein Problem (da ist dann A1=1)
Aber wie unterscheide ich zwischen 1+0 und 0+1? Die Variante "ist einer der Eingänge=0" hilft mir ja nicht.

Oder muss man die kaskadieren?

[rdeckard]

jonofe
Danke, das könnte ich mal testen.

Das Ganze sieht eigentlich so aus:
logik2.png

Die 2-fach Klemme ist nur zum Testen da. Getriggert wird der linke LBS über die GA 3/7/0.

Dabei geht es um die Abfrage von 2 Multiroom-Lautsprechern, ob sie an oder aus sind. Abhängig davon werden dann 4 vordefinierte Sequenzen gestartet, bei denen dann der jeweilige Lautsprecher (Kanal im Verstärker) eingeschaltet und am Ende wieder ausgeschaltet wird. (Es geht um eine Durchsage-Funktion bzw. Türklingel)

[jonofe]

Ein Timing Problem kann es ggf. trotzdem geben, denn die LBS werden sequentiell abgearbeitet und nicht gleichzeitig. So könnte es in deinem Beispiel sein, dass zuerst der LBS 404, dann der LBS 405, dann LBS 406 und dann wieder LBS 405 ausgeführt wird. Wenn 405 jetzt ein UND Gatter wäre, dann könnte das natürlich ungewünschte Effekte haben. So ist zumindest mein Verständnis. Christian, kann mich gerne korrigieren, wenn ich da falsch liege.

[rdeckard]

Hab vorhin deine Variante mal eingebaut, aber leider (noch) keine korrekten Ergebnisse erhalten. Es wurden nicht alle Varianten in der 4fach-Klemme erzeugt. Nur A und B waren (2x) auf 1. C und D waren immer auf 0.
Aber vielleicht habe ich auch einen Fehler gemacht. (Es ist ja schon spät...)
Werds morgen nochmals 1:1 nachbauen.

[rdeckard]

jonofe
Habs heute Vormittag nochmals nachgestellt. Jetzt funktioniert es!
Hatte im Multiplikator noch die 10 vergessen...

Irgendwie brauchen solche Logiken schon viel Platz für relativ einfache Abfragen. Da wünschte man sich einen speziellen, sehr einfach gehaltenen "Script-Baustein", wo man einfache Logiken in einer Pseudo-Script-Sprache eingeben könnte. Ein Mittelding zwischen fertigen Bausteinen und einer PHP-Programmierung.
Der Befehlssatz könnte ja am Anfang aus ganz wenigen Befehlen bestehen und dann später langsam wachsen. (Darf aber nie zu komplex werden.)

[Brick]

meinst du sowas ? LINK

Gruß Martin

[rdeckard]

Jein. Wenn ich diesen Baustein anschaue, dann gehts hier vorallem um einzelne PHP-FUNKTIONEN und weniger eine Logik umzusetzen. (Natürlich könnte man den Baustein missbrauchen, aber das wäre nicht sehr komfortabel und auch gefährlich.)

Meine Idee könnte sowieso nur Christian umsetzen. Ich dachte eher an einen speziellen Baustein, der wie die Textbox ein grosses Fenster (Editor, Inhalt scrollbar) öffnet, in dem man dann einfachen Logik-Code eingeben könnte. Als Befehle könnte ich mir am Anfang die wichtigsten integrierten Basis-Bausteine vorstellen.
Die Funktionalität würde von den bestehenden Bausteinen übernommen. Es wäre einfach eine andere (text/scriptbasierende) Darstellung der gleichen Bausteine.
Dieser Script-Baustein sollte auch nicht den Logikeditor ersetzen, sondern wirklich nur für spezielle, platzsparende Funktionen dienen. Eine Art flexible "Blackbox", die einen sehr begrenzten Sprachbefehlssatz kennt. (Die Problematik mit der event-gesteuerten Funktionsweise muss natürlich berücksichtigt werden. Entweder vom User oder durch den Baustein selber.)
Ich weiss nicht, ob das technisch wirklich umsetzbar wäre. Aber ich könnte mir vorstellen, dass man sowas so nebenbei ganz langsam integriert und immer wieder etwas erweitert. Es gäbe Edomi auf längere Zeit ein sehr starkes Logik-Werkzeug, dass sich natürlich an die "advanced"-User richtet, aber noch vor der eigentlichen LBS-Programmierung (in PHP) stünde.

[jonofe]

Aber das alles würde doch auf dasselbe hinauslaufen, was heute mit der LBS Erstellung möglich ist. Du müsstest Eingänge definieren, Ausgänge definieren, es sollte dokumentert werden, usw.

Ich sehe da keinen wirklichen Vorteil gegenüber dem PHP basierten LBS Konzept. Einfach LBS wie zum Bespiel deer Anwendungsfalls oben sind in wenigen Minuten fertig geschrieben. Stattdessen nun eine neue Logiksprache zu entwickeln mit allem was dazugehört (Scanner, Parser, etc.) wäre aus meiner Sicht Overkill. PHP ist für solch einfache Anwendungsfälle nicht wirklich kompliziert. Only my 2 cents ...

[gaert]

Richtig - im Grunde *ist* genau dies schon längst verfügbar: Der LBS-Editor in der GUI Und in der kommenden Version wird dieser auch ein wenig komfortabler und mitteilungsfreudiger sein...

[rdeckard]

jonofe Wahrscheinlich hast du recht. Mir fehlt halt manchmal ein Zwischenstück zwischen visuellen Logikbausteinen und ein PHP-Programm. Aber der Aufwand würde dies wohl nie rechtfertigen.
Vielleicht fehlt auch nur ein IF-THEN-ELSE bzw. SELECT-CASE Baustein, der diese (imho) "Ungetüme", wie du es mir hier gezeigt hast (und auch funktioniert!), unnötig macht. Aber egal, ist ja auch nur ein einmaliger Mehraufwand. (So viele Logikbausteine baut man ja auch wieder nicht. Und sonst kann man ja das Gerüst kopieren.)
Ich wäre einfach nicht sofort auf deinen Workaround mit Multiplikationen und Additionen gekommen.

Eine andere Frage zu meinem hier verwendeten PHP-Baustein:

Ich habe 12 Ausgänge, welche jeweils über eine Variable abgefüllt werden:

// Outputs:
$LB_LBSID_OUTPUT_StatusChannel01 = 1; // Status Channel/Keypad 01 (; delimited)
$LB_LBSID_OUTPUT_StatusChannel02 = 2; // Status Channel/Keypad 02 (; delimited)
$LB_LBSID_OUTPUT_StatusChannel03 = 3; // Status Channel/Keypad 03 (; delimited)
...
$LB_LBSID_OUTPUT_StatusChannel10 = 10; // Status Channel/Keypad 10 (; delimited)
$LB_LBSID_OUTPUT_StatusChannel11 = 11; // Status Channel/Keypad 11 (; delimited)
$LB_LBSID_OUTPUT_StatusChannel12 = 12; // Status Channel/Keypad 12 (; delimited) 

Mit den folgenden Befehlen (fixe Variablezuweisung) funktioniert alles:

LB_LBSID_sendByChange("LB_LBSID_OUTPUT_StatusChannel01", $Name.";".$PowerStatus.";".$SourceStatus.";".$VolumeStatus.";".$MuteStatus);
LB_LBSID_sendByChange("LB_LBSID_OUTPUT_StatusChannel02", $Name.";".$PowerStatus.";".$SourceStatus.";".$VolumeStatus.";".$MuteStatus);
LB_LBSID_sendByChange("LB_LBSID_OUTPUT_StatusChannel03", $Name.";".$PowerStatus.";".$SourceStatus.";".$VolumeStatus.";".$MuteStatus); 

Da ich aber die Werte in einer FOR-Schleife auslese, würde ich gerne die Schleife nutzen, um die Ausgänge dynamisch abzufüllen. Also in dieser Art:

$countPadded=str_pad($count, 2, '0', STR_PAD_LEFT);
LB_LBSID_sendByChange(${'LB_LBSID_OUTPUT_StatusChannel'.$countPadded}, $Name.";".$PowerStatus.";".$SourceStatus.";".$VolumeStatus.";".$MuteStatus); 

D.h. die Variable $LB_LBSID_OUTPUT_StatusChannel01 soll dynamisch zusammengesetzt werden. (rot kommt vom FOR Counter).
In einer externen PHP-Datei funktioniert dieser Befehl. Im Edomi sind die Ausgänge aber leer.

Workaround wäre die Werte in der FOR-Schleife in einem Array zwischenzuspeichern und dann nach der FOR-Schleife wieder fix den 12 Ausgängen zuweisen.
Aber trotzdem würde es mich interessieren, was ich hier falsch mache?

[jonofe]

Für mich wäre ein Array kein Workaround, sondern die präferierte Lösung.

Zu deinem Problem:

LB_LBSID_sendByChange("LB_LBSID_OUTPUT_StatusChannel01", $Name.";".$PowerStatus.";".$SourceStatus.";".$VolumeStatus.";".$MuteStatus); 

und

LB_LBSID_sendByChange(${'LB_LBSID_OUTPUT_StatusChannel'.$countPadded}, $Name.";".$PowerStatus.";".$SourceStatus.";".$VolumeStatus.";".$MuteStatus); 

sind doch was anderes. Beim ersten übergibst du einen String an die sendByChange Funktion. Beim zweiten interpretierst du es vorher schon als Variable und übergibst den Inhalt. Dann müsste sich die sendByChange() Funktion in beiden Fällen unterscheiden, damit das funktionieren kann.

Das Äquivalent zur erste Version wäre doch:

LB_LBSID_sendByChange('LB_LBSID_OUTPUT_StatusChannel'.$countPadded, $Name.";".$PowerStatus.";".$SourceStatus.";".$VolumeStatus.";".$MuteStatus); 

[rdeckard]

Super! Vielen Dank! Damit hats jetzt geklappt.

Da ich noch nie mit dynamisch zusammengesetzten Variablen gearbeitet habe, suchte ich im Internet danach und fand dies als Lösung:

${'a'.$n} gives you $a2 if $n is 2 

'LB_LBSID_OUTPUT_StatusChannel'.$countPadded wäre eigentlich naheliegender gewesen, dachte aber nicht, dass dies so funktioniert.