Zwei kurze Fragen (EXEC Daemon/Ausgangsbox)

[wintermute]

Hi Christian,

beim Rumwerkeln an aelteren Bausteinen sind mir zwei Dinge aufgefallen zu denen ich mal Nachhaken muesste

a) Wenn in einem EXEC Daemon schnell hintereinander Ausgaenge gesetzt werden, koennen (je nach Frequenz) einige davon verloren gehen - was ja wohl der Unabhaengigkeit des Daemons und Edomi selbst geschuldet ist. Abhilfe schafft es, nach Setzen eines Ausgangs eine gewisse Zeit zu warten (hier jetzt zB 500ms), aber der Stein der Weisen kann das ja nicht sein, denn wenn:
a.1) Edomi aus irgendwelchen Gruenden in der Zeit nicht reagieren kann oder will, gehen die Infos ja trotzdem verloren und
a.2) das ja eigentlich unnuetzes Vertroedeln von Zeit ist
Daher die Frage: kann man aus dem Daemon heraus irgendwie einen Durchlauf der Logik-Engine erzwingen oder zumindest irgendwie eine (positive) Rueckmeldung abwarten? Ich habs schon mit Eingaengen auslesen und aehnlichem probiert, hat aber alles nicht geholfen...

und b) Wenn ich einen Ausgang zB auf den Wert "blah" setze und per Ausgangsbox einem KO zuweise funktioniert das wie erwartet (Ueberraschung ). Wenn ich nu aber den Wert auf einen Leerstring setzen moechte, dann wird das von der Ausgangsbox ignoriert, egal welchen Eingang ich waehle. Kann ich nur umschiffen wenn ich statt eines Leerstrings ein Leerzeichen (zB) setze. Das ist ja aber auch irgendwie nicht so 100%ig sauber.

Eventuell steht die Loesung dazu sogar in der Hilfe, aber ich habs nicht gefunden
Waere das also best-practice oder seh ich irgendwas nicht?

gruesse :: Michael

[Winni]

und b) Wenn ich einen Ausgang zB auf den Wert "blah" setze und per Ausgangsbox einem KO zuweise funktioniert das wie erwartet (Ueberraschung ). Wenn ich nu aber den Wert auf einen Leerstring setzen moechte, dann wird das von der Ausgangsbox ignoriert, egal welchen Eingang ich waehle. Kann ich nur umschiffen wenn ich statt eines Leerstrings ein Leerzeichen (zB) setze. Das ist ja aber auch irgendwie nicht so 100%ig sauber.

Das hatte ich schonmal bemängelt und hätte auch gerne eine x-fach Ausgangsbox ohne jegliche Filter.....
Aktuell gebe ich halt immer &nbsp aus

[wintermute]

eine x-fach Ausgangsbox ohne jegliche Filter.....

Ja, das waer der Bringer: vorne 16 Eingaenge, hinten 16KOs, einfach durchgereicht. Christian meinte aber schonmal das waere nicht so trivial umsetzbar wie es scheint...

[jonofe]

zu a) ich hatte es immer so verstanden, dass beim Setzen unterschiedlicher Ausgänge nichts verloren geht. Nur kannst du in der Hauptlogikschleife nicht davon ausgehen, dass alle Ausgänge schon gesetzt sind.
Wenn du im EXEC einen Ausgang mehrfach innerhalb kurzer Zeit setzt, dann können Informationen verloren gehen, da du nicht vorhersagen kannst wann die Hauptlogikschleife die Ausgänge abarbeitet. So war zumindest bisher meine Erfahrung.
Man könnte das ggf. über eine Message Queue lösen, d.h. die Infos (Ausgänge setzen) des EXEC in der message an den LBS senden und dort die Ausgänge setzen. Ist natürlich etwas Overhead in der Hauptlogikschleife. Müsste man sehen wie lange dass msg_receive() dann braucht.

war jetzt so meine spontane idee in der Sonne Gran Canarias

[wintermute]

Jaaa... ich erinner mich, dass Du mal ein aehnliches Problem hattest, mit Steckdosen... oder so...
Ich auch, und zwar bei der Kommunikation zwischen LBS und EXEC-Teil des Squeeze-Daemons, das habe ich durch eine Pipe geloest. Meine momentane Konstellation ist aber schwieriger, denn da geht es um bidirektionale Kommunikation zwischen dem Daemon und mehreren LBS wobei der Daemon eigentlich immer Broadcast spricht und der betreffende Client sich der Sache dann annimmt. Wuerde ich das also nu alles in eine Pipe stecken, dann koennte die "verstopfen" wenn der adressierte Client aus irgendwelchen Gruenden die Daten nicht aus der Pipe holt - ich muesste also fuer jeden Client ne dedizierte Pipe haben, was aber dieses Problem auch nicht loest... einfacher waere dann vermutlich irgendeine Socket-Kommunikation, vermutlich am besten UDP...

Das fuehrt jetzt aber alles zu weit bevor ich damit anfange, vertraue ich weiterhin auf das bewaehrte usleep

[gaert]

Alles richtig

zu a)
Da EXEC unabhängig von der "Hauptschleife" der Logikengine läuft, erfolgt auch das Setzen eines Ausgangs vollkommen "asynchron". Daran kann ich auch nichts ändern, denn eine "Ausgangsqueue" ist nicht vorgesehen - und für normale LBS auch nicht notwendig, denn hier werden die Logiken quasi rekursiv abgearbeitet. Da bleibt also nur eine eigene Implementierung, z.B. den LBS-Teil entsprechend mitnutzen (und wie auch immer mit EXEC kommunizieren).

zu b)
Rischtisch... Das Setzen von "Nix" per Ausgangsbox ist nicht möglich. Dies kann ich aber natürlich noch nachreichen (evtl. eine zweite Art von Ausgangsbox speziell für diesen Zweck - oder ich ergänze noch einen Eingang). Muss ich mal drüber nachdenken...

Eine x-fach-Ausgangsbox ist tatsächlich konzeptionell nicht so einfach zu implementieren, steht aber bereits seit einiger Zeit uff der Liste

EDIT/PS:
Willkommen nahe bei meiner Heimat, Andre Genieße die Sonne!

[wintermute]

Dann, lieber Weihnachtsmann, wuensche ich mir zum naechsten Update eine solche Ausgangsbox.
Ich war auch seit dem letzten Update super-lieb... echt...

[jonofe]

Jaaa... ich erinner mich, dass Du mal ein aehnliches Problem hattest, mit Steckdosen... oder so...
Ich auch, und zwar bei der Kommunikation zwischen LBS und EXEC-Teil des Squeeze-Daemons, das habe ich durch eine Pipe geloest. Meine momentane Konstellation ist aber schwieriger, denn da geht es um bidirektionale Kommunikation zwischen dem Daemon und mehreren LBS wobei der Daemon eigentlich immer Broadcast spricht und der betreffende Client sich der Sache dann annimmt. Wuerde ich das also nu alles in eine Pipe stecken, dann koennte die "verstopfen" wenn der adressierte Client aus irgendwelchen Gruenden die Daten nicht aus der Pipe holt - ich muesste also fuer jeden Client ne dedizierte Pipe haben, was aber dieses Problem auch nicht loest... einfacher waere dann vermutlich irgendeine Socket-Kommunikation, vermutlich am besten UDP...

Das fuehrt jetzt aber alles zu weit bevor ich damit anfange, vertraue ich weiterhin auf das bewaehrte usleep

ich hab das in den HUE Bausteinen so gelöst: es gibt einen Bridge LBS, der die Kommunikation mit der HUE Bridge koordiniert. Dazu kann es viele Instanzen des HUE Light Bausteins geben. Alle kommunizieren mit der Bridge und die Bridge mit allen Lights und das über zwei message queues. Eine von Bridge in Richtung Lights. Man kann beinder message queue den message type angeben, den man sendet und den man empfangen will. So holt jedes light nur die messages raus, die für sie bestimmt sind. Vielleicht würde das ja auch in deinem Fall funktionieren. Wenn natürlich viele Messages kommen und ein Ende abraucht, dann kann das natürlich auch voll laufen.

@Christian: Jetzt verstehe ich auch woher deine Ideen kommen. Ist ja echt traumhaft hier. Ich frage mich nur, wie du die Zeit findest das alles auch zu implementieren.

[wintermute]

usleep
Ausserdem bist Du im Urlaub... kusch Dich :P

EDIT: momentan sieht das bei mir zum Beispiel so aus... toll ist irgendwie anders
ohne worte.png

[gaert]

wintermute
Naja gut... Dein Wunschzettel wird berücksichtigt - aber Weihnachtsgeschenke gibt es wann? Na?

Ich habe gestern mal ne entsprechende Ausgangsbox "programmiert" (ist ja nur eine kleine Änderung), allerdings ist diese dann wirklich nur für Spezialfälle sinnvoll einsetzbar: Der Eingang wird ja dann bei jedem "Telegramm" getriggert (eben auch bei einem leeren String) - und das verträgt sich nicht mit anderen LBS (z.B. Klemme), denn diese reagieren nicht auf NULL. Aber das ist ja nicht mein Problem

Du kannst ja spaßeshalber mal die vorhandene Ausgangsbox entsprechend modifizieren und testen, ob Du damit glücklich wirst. Also einfach E2 entsprechend auf

if ($E2['refresh']==1) {... 

reduzieren.


EDIT:
Für die andere Geschichte (Queue beim Ausgang-Setzen) versuche ich gerade eine Lösung zu finden (der Gedanke ist ganz einfach eine Queue zu implementieren - die existiert ohnehin, wird jedoch zu diesem Zweck noch nicht genutzt). Schau'n wa ma...

[gaert]

Sieht nicht übel aus für die "Ausgangs-Queue": Zähler von 0..1000 in der EXEC-Schleife führt zu diesem Ergebnis (A1=ohne Queue, A2=mit Queue):
Bildschirmfoto 2016-07-16 um 10.25.57.png


EDIT:
Diese neue Funktion wird dann (etwas sperrig) "setLogicLinkAusgangQueued($elementid,$ausgang,$va lue)" heißen...

BTW: Historisch bedingt haben sämtliche Logikfunktionen ziemlich dämliche Namen. Gerne würde ich dies abändern, jedoch müssten dann natürlich alle LBS angepasst werden. Ich werde daher wahrscheinlich bald mal entsprechende "Alias"-Funktionen ergänzen - mit kompakten Funktionsnamen

[wintermute]

Ich weiss nicht, wie ich da angemessen drauf antworten soll... ich sag mal einfach nix

[gaert]

Ok... Ich habe die Funktionen umbenannt - die alten Funktionsnamen bleiben natürlich (bis auf Weiteres) ebenfalls gültig.

Vorläufiges amtliches Endergebnis:

Funktion	Erläuterung
logic_getInputs($elementid) Alias: getLogicEingangDataAll	Liefert die aktuellen Daten aller Eingänge der LBS-Instanz $elementid zurück. Rückgabe: ARRAY[Eingang]['value';'refresh'] (im Fehlerfall wird FALSE zurückgegeben) Eingang: Nr. des Eingangs (1..∞) 'value': aktueller Wert am Eingang 'refresh': 1=Eingang wurde aktualisiert 0=Eingang wurde nicht aktualisiert Achtung: Die 'refresh'-Eigenschaft kann in einem EXEC-Script nicht zuverlässig ausgewertet werden, da das Script nicht im Kontext der Logik-Engine ausgeführt wird.
logic_getState($elementid) Alias: getLogicElementStatus	Liefert den aktuellen Status der LBS-Instanz $elementid zurück. Rückgabe: INTEGER (im Fehlerfall wird NULL zurückgegeben) 0=LBS läuft nicht 1=LBS läuft
logic_setState($elementid,$status,[$delay],[$interval]) Alias: setLogicElementStatus	Aktiviert oder deaktiviert das zyklische Aufrufen der LBS-Instanz $elementid durch die Logik-Engine. $status: 0=nicht zyklisch aufrufen 1=LBS zyklisch aufrufen (mit kleinstmöglichem Intervall) Hinweis: $status=0 hat stets Priorität ($delay wird dann ignoriert) $delay (optional): Verzögerung des nächsten zyklischen Aufrufs in Millisekunden ($status muss =1 sein, ansonsten wird $delay ignoriert) $delay=0 ist nicht erlaubt (in diesem Fall wird $delay ignoriert und $status hat Priorität) $delay=1: nächster automatischer Aufruf mit kleinstmöglicher Verzögerung $delay=2..∞: nächster automatischer Aufruf mit dieser Verzögerung (ms) Hinweis: $delay erwartet einen INTEGER-Wert (ms) Achtung: Das Timing ist nicht unbedingt präzise, $delay ist daher als Mindestverzögerung zu verstehen! $interval (optional): false: $delay nur einmalig(!) anwenden (nach dem verzögerten Aufruf wird der LBS weiterhin zyklisch aufgerufen, jedoch mit kleinstmöglicher Verzögerung) true: $delay immer wieder anwenden (nach dem verzögerten Aufruf wird der LBS immer wieder mit der Verzögerung $delay aufgerufen) Hinweis: wird $interval nicht angegeben, wird $delay nur einmalig angewendet (entspricht $interval=false)
logic_setOutput($elementid,$ausgang,$value) Alias: setLogicLinkAusgang	Setzt einen Ausgang der LBS-Instanz $elementid auf einen Wert. $ausgang: Nr. des Ausgangs (1..∞) $value: zu setzender Wert Hinweis: Intern wird nicht der Ausgang auf einen Wert gesetzt, sondern alle Eingänge, die mit dem Ausgang verbunden sind. Wichtig: Die Verwendung dieser Funktion in einem EXEC-Abschnitt führt bei einem sehr häufigen Aufruf in kurzer Zeit u.U. dazu, dass einzelne Aufrufe unwirksam bleiben (der EXEC-Abschnitt wird asynchron ausgeführt). Ggf. ist daher die Funktion logic_setOutputQueued() im EXEC-Abschnitt zu verwenden.
logic_setOutputQueued($elementid,$ausgang,$value) Alias: setLogicLinkAusgangQueued	Wie logic_setOutput(), jedoch wird das Setzen des Ausgangswertes in einer Queue zwischengespeichert. Wichtig: Die Verwendung dieser Funktion ist ausschließlich für den EXEC-Abschnitt (bei Bedarf) einzusetzen, z.B. wenn ein Ausgang sehr häufig in kurzer Zeit auf einen Wert gesetzt werden soll. Der Aufruf dieser Funktion ist zwar weniger performant, jedoch wird jeder Aufruf garantiert wirksam umgesetzt.
logic_getVars($elementid) Alias: getLogicElementVarAll	Liefert ein Array mit den aktuellen Werten aller Variablen der LBS-Instanz $elementid zurück. Rückgabe: ARRAY[Variablen-ID]
logic_getVar($elementid,$varid) Alias: getLogicElementVar	Liefert den aktuellen Wert einer Variable der LBS-Instanz $elementid zurück. $varid: Nr. der Variable (1..∞) Rückgabe: Variant oder NULL (Fehler)
logic_setVar($elementid,$varid,$value) Alias: setLogicElementVar	Setzt eine Variable der LBS-Instanz $elementid auf einen Wert. $varid: Nr. der Variable (1..∞) $value: zu setzender Wert
logic_callExec(LBSID,$elementid) Alias: callLogicFunctionExec	Startet ggf. das EXEC-Script der LBS-Instanz $elementid. LBSID: Platzhalter für die LBS-ID (nicht verändern!) Hinweis: Der LBS wartet nicht(!) auf die Ausführung des EXEC-Scripts.
logic_sqlKeepalive() Alias: setLogicKeepAlive	Dummy-Funktion zur Aufrechterhaltung der mySQL-Verbindung (u.U. wichtig für EXEC-Logikbausteine). Erläuterung: Die o.g. Funktionen greifen intern auf eine mySQL-Datenbank zu. Die mySQL-Engine trennt jedoch die Verbindung, sobald länger als 8 Stunden keinerlei Zugriff erfolgt - der Aufruf der o.g. Funktionen innerhalb eines EXEC-Scripts(!) wird dann u.U. scheitern! Es ist daher ggf. dafür zu sorgen, dass z.B. stündlich ein mySQL-Zugriff erfolgt, um die Verbindung aufrecht zu erhalten. Die kann z.B. durch einen zyklischen Aufruf (z.B. alle 60 Minuten) dieser Funktion erfolgen.

[gaert]

Soooo. Ich habe dann mal 3 Ausgangsboxen hinzugefügt: Die ersten beiden (neuen) Ausgangsboxen verhalten sich wie die gute alte Ausgangsbox (nur quasi aufgespalten in einzelne LBS). Die dritte Ausgangsbox ("Telegramm") verhält sich wie gewünscht, d.h. es wird bei jedem Telegramm (auch bei "nix") getriggert.

Ausserdem wird jetzt die deutsche Grammatik berücksichtigt (1 Befehl, 2 Befehle) image_51217.png

Um es vorwegzunehmen: Nein, die alte Ausgangsbox bekommt keinen E3 verpasst - denn das Verhalten "bei nix triggern" passt i.d.R. nicht zu den Werks-LBS und stellt daher eine Ausnahmesituation dar für einige spezielle User-LBS.

[panzaeron]

Ok... Ich habe die Funktionen umbenannt - die alten Funktionsnamen bleiben natürlich (bis auf Weiteres) ebenfalls gültig.

Das finde ich gut, TOP!
Der Mix aus Englisch und Deutsch ist auch irgendwie nicht schön gewesen...