LBS(Sammlung) Squeeze

[wintermute]

aber schön, dass wir das genauso sehen.

Aber so oder so wuerde das an Deiner Problemstellung wenig aendern. Angenommen es wuerden beide Befehle ausgefuehrt werden, dann haettest Du bei
Licht an:
-power on
-play
und bei Licht aus:
-power off
-stop

Ich glaube zwar nicht, dass der Player beim "stop" wieder angeht (weiss ich aber grad nicht), aber korrekterweise muesste da ein Flankendetektor vor, so dass nur "power off" getriggert wird (da ist das "stop" dann bereits inkludiert - quasi )

[wintermute]

Mit dem Workarounds eines Verzögerers vor dem "power" Eingang funktioniert es zwar.

Ja, das hatte ich auch ausprobiert... wenn man das mit Logik abbilden moechte, so dass es korrekt funktioniert, kaemen da ein paar externe LBS hinzu. Einfacher waers dann den Kommando LBS um entsprechende Funktionen zu erweitern (also stop/off bzw on/play) - was aber auch nur gaenge wenn ich die Ausgaenge mehrfach triggern kann...

gaert ich kann grad nicht so ausgiebig testen aber kann es sein, dass dieses "Ausgang ueberschreiben" nur im LBS-, aber nicht im EXEC-Teil passiert?

[rdeckard]

Bis jetzt habe ich ja die Logikseite nur mit einem Client (=Player) getestet. Da ich jetzt in meiner Visu mal einen 2. und 3. Player eingefügt habe, müsste ich diese ja auch mit Werten versorgen.
Ich nehme an, ich muss für jeden Client jeweils eigene KO's definieren? (Also die Kommando und Status KO's)

Wie soll ich aber jetzt die LBS genau verknüpfen?

So siehts im Moment aus: squeeze11.png


Muss der Squeeze Command Baustein für jeden Client dupliziert werden oder kann der mit dem Setzen von PlayerID durch ein KO generisch gehalten werden? Dann müsste der Command Ausgang an mehrere Clients verbunden werden? Aber wie gibt man dann bei einem Steuer-Befehl die PlayerID mit?

Zudem habe ich jetzt in diesem Beispiel auch Verständnisprobleme mit den KommandoKO und StatusKO

Ich werde vermutlich am Ende sicher auf ca. 10 Player kommen. Das wird dann schon eine grosse Logikseite. (Auf der leider die Bausteine noch nicht gruppiert werden können).

So sieht im Moment die (Test) Visu aus:
squeeze12.png

Oben soll eine Liste aller Player angezeigt werden. Mit Infos über On/Off, Player-Status und Volume.
Unten wären dann Details und die Steuerung, welche sich aber ja nur auf ein Player beziehen kann. D.h. vermutlich läuft es auf ein Popup heraus (muss dann für jeden Player ein eigenes Popup für diese Control/Info-Elemente erstellen).

[wintermute]

Ich nehme an, ich muss für jeden Client jeweils eigene KO's definieren? (Also die Kommando und Status KO's)

Nein, KommandoKO und StatusKO sind global und jeweils nur einmal vorhanden.

Wie soll ich aber jetzt die LBS genau verknüpfen?

Alle gleich (also so wie Du es auch beim ersten gemacht hast). Fuer jeden Player einen Client LBS, wo die playerID entsprechend konfiguriert ist, und da das globale KommandoKO und das globale StatusKO anschliessen.
Im Kommando LBS darf keine playerID vergeben werden solange er mit einem Client LBS verbunden ist. Nur wenn der Kommando LBS ohne Client LBS benutzt wird, muss dort die playerID angegeben werden (siehe ein irgendein vorheriges Posting von mir).

Muss der Squeeze Command Baustein für jeden Client dupliziert werden oder kann der mit dem Setzen von PlayerID durch ein KO generisch gehalten werden? Dann müsste der Command Ausgang an mehrere Clients verbunden werden? Aber wie gibt man dann bei einem Steuer-Befehl die PlayerID mit

Siehe dasselbe "vorherige Posting"
Du kannst einen Kommando LBS direkt mit dem globalen KommandoKO verbinden, dann die playerID vorgeben und einen Befehl absetzen. Oder als playerID "FF:FF:FF:FF:FF:FF" vorgeben, dann wird der Befehl an alle Player geschickt.
Aber wenn du Status-Ausgaben pro Player haben willst, musst du trotzdem einen Client LBS pro Player haben...

Ich werde vermutlich am Ende sicher auf ca. 10 Player kommen. Das wird dann schon eine grosse Logikseite. (Auf der leider die Bausteine noch nicht gruppiert werden können).

Ich wuerde eine Logikseite fuer den Server LBS, eine fuer globale Geschichten (zB globale Kommando LBS und was da noch kommen mag) und dann eine Seite pro Player empfehlen - so bleibt es am uebersichtlichsten.

So sieht im Moment die (Test) Visu aus:

Cool

[rdeckard]

Ich habs jetzt mal zum Laufen bekommen (mit 2 Clients, siehe Logik unten).

Dabei verhält sich aber das Ganze etwas zäh und teilweise falsch. Ich habe vorallem grosse Verzögerungen bei den Status-Werten.
Schicke ich z.B. Vol -3 an den Client (ich steuere nur einen der beiden Clients, da sie ja synchronisiert sind), so hört man sofort (auf beiden Playern) die Veränderung. Ca. 3-4 Sek. später wird es bei EINEM Client dann auch angezeigt und nochmals ca. 30 (!) Sek. später erhält auch der 2. Client die Info.

squeeze13.png

Dasselbe ist auch, wenn ich z.B. Pause drücke. Die Musik stoppt sofort (auf beiden Playern), aber der Status benötigt wieder 2-3 Sek., bis er beim ersten angezeigt wird und 34 Sek. bis zum zweiten Player. Dann haben beide Player den Pausen-Status und plötzlich hat der eine Player den Stop-Status, obwohl ich nichts gemacht habe (auch nicht extern).
squeeze14.png

squeeze15.png

Habe ich bei der Verdrahtung noch einen Fehler drin? (Auch wenn es ja grundsätzlich funktioniert. Nur sehr langsam und dieser Stop-Status ist definitiv falsch.)
Die Zeiten sind übrigens nicht immer gleich. Manchmal geht es auch etwas schneller.

Was immer schnell geht, ist der eigentliche Befehl an dem LMS schicken.

[wintermute]

Habe ich bei der Verdrahtung noch einen Fehler drin? (Auch wenn es ja grundsätzlich funktioniert. Nur sehr langsam und dieser Stop-Status ist definitiv falsch.)

Ich kann jetzt nicht in jedes KO (und jede Ausgangsbox) gucken, aber prinzipiell sieht das ok aus. Alledings steuerst Du mit dem Kommando LBS beide Player parallel an (so wie es ausschaut). Also schickst du die Kommandos gleichzeitig an beide Player. In der Theorie sollte das auch funktionieren, ich werde spaeter mal versuchen das mit zwei Softwareplayern nachzustellen...
Es taete mich aber nicht wundern, wenn das irgendwie mit der Synchronisation zu tun hat...

Sobald ich Zeit finde probier ich Deine Verkabelung mal aus, ich meld mich dann nochmal.

[wintermute]

Sooo... nachgebaut, getestet, stümmt...
Das mit den verzögerten Aktualisierungen zumindest, wieso das mit dem stop passiert weiss ich noch nicht - so weit hab ich mich nicht getraut

Problem ist, dass Edomi scheinbar KO Wechsel verwirft wenn diese "quasi-parallel" oder zumindest sehr sehr schnell nacheinander auftreten, aehnlich dem Problem, das André weiter oben ausgefuehrt hat (ich glaube nicht aehnlich, sondern sogar identisch).
In deinem konkreten Fall ist es jetzt so, dass 2 Client LBS quasi "zeitgleich" in dasselbe KO schreiben, in den allermeisten Faellen kommt aber nur einer davon wirklich durch, wenn man die LBS einzeln debugged, kann man das gut sehen (so sieht das zB bei dem nachgebauten Szenario von Dir aus):

016-03-05 23:46:31 --- LBS19000201(34:15:9e:8e:de:22): sending player command '34:15:9e:8e:de:22 mixer volume 50'
016-03-05 23:46:31 --- LBS19000201(00:88:65:3e:2b:34): sending player command '00:88:65:3e:2b:34 mixer volume 50'
016-03-05 23:46:32 --- LBS19000200(127): Received external command: 00:88:65:3e:2b:34 mixer volume 50
016-03-05 23:46:32 --- LBS19000200(127): Sending '00:88:65:3e:2b:34 mixer volume 50'

Also: zwei unterschiedliche LBS (die 201er) schreiben quasi zur selben Zeit in dasselbe KO und wer zuletzt kommt, behaelt da die Oberhand (in obigem Beispiel wird also nur das letzte Kommando tatsaechlich zum Server LBS transportiert).
Anders gesagt: scheinbar arbeitet Edomi da nicht sobald sich der Status eines KOs aendert (also nicht ereignis-getriggert), sondern arbeitet eine Schleife ab und nimmt die Werte die zu dem Zeitpunkt grad in den KOs stehen (Christian, bitte entschuldige wenn das inkorrekt ist, aber so scheint mir das grad).

Kurzum: weiss ich jetzt nicht, was ich dagegen machen soll... an bestimmten Stellen zu warten hilft vielleicht, kann aber auch nicht der Stein der Weisen sein. Vielleicht hilft es auch, den Client LBS als EXEC-Variante auszulegen, denn da schien es mir bisher zumindest so, dass auch schnelle KO-Wechsel tatsaechlich einzeln abgearbeitet werden. Weiss ich aber nicht wirklich, ich hab zu wenig Wissen bzgl der Internals.

Ich hab schon zweimal angefragt, jetzt nochmal

gaert ist das so korrekt und beabsichtigt? Weil wenn, dann muss ich hier nicht mehr weitermachen...

gruesse :: Michael

[rdeckard]

Danke für die Tests!
Schade, jetzt wo es eigentlich schon richtig gut laufen würde. Aber ich hoffe, Christian wird da schon noch eine Lösung finden.

[gaert]

Nee nee Da wird nix verschluckt... Allerdings betrifft dies nur den LBS-Teil - der EXEC-Teil läuft ja quasi asynchron vor sich hin.

Und wichtig in diesem Kontext: Vor 1.20 (oder war's 1.21?) könnte tatsächlich etwas verschluckt werden, wenn die KOs schnell hintereinander eintreffen. Aber dies habe ich korrigiert in der aktuellen Version, bzw. in 1.20/1.21

[jonofe]

Nee nee Da wird nix verschluckt... Allerdings betrifft dies nur den LBS-Teil - der EXEC-Teil läuft ja quasi asynchron vor sich hin.

Und wichtig in diesem Kontext: Vor 1.20 (oder war's 1.21?) könnte tatsächlich etwas verschluckt werden, wenn die KOs schnell hintereinander eintreffen. Aber dies habe ich korrigiert in der aktuellen Version, bzw. in 1.20/1.21

Es ging in meinem Fall nicht um zu schnell eintreffende KO's, sondern darum, wenn dasselbe KO an mehreren Eingänge eintrifft und ein LBS Durchlauf aufgrund der implementierten Logik denselben Ausgang in diesem Durchlauf zweimal mit unterschiedlichen Werten belegt. Dann scheint nur das letzte Setzen des Ausgangs berücksichtigt zu werden. Es ist also die Frage ob SetLogicLinkAusgang() Aufrufe gequeued werden oder ob am Ende des LBS Durchlaufs geschaut wird, welchen Zustand sie haben und dann damit die weitere Logik getriggert wird. Im Moment sieht es eher nach letzterem Verhalten aus.

[gaert]

Das Setzen eines Wertes an einem Ausgang wird sofort erledigt, sobald die Funktion aufgerufen wird. Eine Queue gibt es durchaus, allerdings nicht innerhalb EINES Aufrufs des Bausteins! Der Baustein wird ja (hier mal abgesehen von Timern etc.) immer dann aufgerufen, wenn an einem oder mehreren Eingängen etwas passiert. Dies entspricht quasi genau einem Durchlauf des Bausteins (also der Hauptfunktion im LBS-Teil). Auch wenn mehrere(!) Eingänge quasi gleichzeitig refreshed werden, wird der Baustein nur einmal aufgerufen - sonst würde schnell ein ziemliches Chaos entstehen

Wenn Du also einen Ausgang mehrfach während eines "Durchlaufs" setzt, wird natürlich nur der letzte Wert berücksichtigt. Die Logik-Verkettung simuliert schließlich keine elektronische Schaltung Natürlich wäre es prinzipiell auch möglich, dass bei JEDEM Setzen eines Ausgangs ein entsprechendes Event getriggert wird - aber dann wird's u.U. sehr schnell sehr "rekursiv"...

Das Prinzip ist also:
1. irgendwas kommt rein (Eingänge)
2. dies wird verarbeitet (1 Durchlauf)
3. irgendwas kommt raus (Ausgänge)

[wintermute]

Wenn Du also einen Ausgang mehrfach während eines "Durchlaufs" setzt, wird natürlich nur der letzte Wert berücksichtigt.

Ja, so hatte ich das gemeint.
Passiert das auch um EXEC-Teil? Vermutlich nicht, denn sonst taete ein Daemon ja prinzipiell nicht funktionieren, richtig?
Also koennte man das Verhalten umgehen, indem man aus dem "konventionellen" LBS eine EXEC-Variante macht?

gruesse :: Michael

[gaert]

Im EXEC-Teil ist es quasi Glückssache, da asynchron. Der Ausgang wird natürlich immer gesetzt, sobald man die Funktion aufruft - aber man kann nicht vorhersagen, wann genau darauf reagiert wird: Es werden in Wirklichkeit nämlich keine Ausgänge gesetzt (die gibt es garnicht), sondern die Eingänge, die mit den Ausgängen verbunden sind. Wenn also im EXEC ein Ausgang gesetzt wird und "unmittelbar" danach der Ziel-Eingang von einem anderen LBS gesetzt wird, gewinnt u.U. der andere LBS.

EXEC-LBS sind also eher für spezielle Dinge wie... naja, ist ja bekannt... geeignet. Eher weniger für typische Logikaufgaben. In den meisten Fällen spielt das aber vermutlich keine Rolle.

[jonofe]

wäre es nicht sinvoller jedes Beschreiben eines Ausgangs in einer Queue zu puffern und somit auf jeden Fall abzuarbeiten? Das wäre aus meiner Sicht zumindest die deterministischere Lösung. Man wüsste somit zumindest dass jedes "Senden eines KO's" (Setzen eines Ausgangs) abgearbeitet wird. Ich verstehe dass die Reihenfolge dann nicht deterministisch ist, aber das ist auch okay.

Zusätzliche Frage dazu:
Was würde denn passieren wenn ich statt einem Ausgang mehrmals in einem LBS Durchlauf einen Wert zuzuweisen, mehere Ausgänge hätte, jedem einen Wert im Zuge des LBS Durchlaufs zuordnen würde und alle Ausgänge demselben Eingang eines andere LB zuordnen würde. Würden dann alle Werte sequentiell abgearbeitet?
Konkret: in einem Durchlauf werden die squeeze-Kommandos "play 0" und "power 0" generiert. jedes wird auf einen separaten Ausgang gelegt, dieser aber mit demselben Eingang am SqueezServer LBS verbunden. Werden dann beide Befehle abgearbeitet?

Wenn nein, wie würde man das Problem lösen?
Könnte ich den LBS irgendwie dazu bringen für jeden geänderten Eingang erneut durchzulaufen? Bsp. Eingang 1 und 2 haben sich geändert. LBS läuft einmal durch und arbeitet den Wechsel von Eingang 1 ab. Außerdem wird festgestellt, dass sich Eingang 2 auch geändert hat, also müsste er dafür nochmal getriggert werden. Geht das irgendwie?

[gaert]

Der EXEC-Teil arbeitet naturgemäß asynchron, also völlig losgelöst von der Logikengine. Daran ist nix zu rütteln, denn das wäre im Detail zu "unsicher" (der EXEC-Teil nimmt nicht(!) an der "Verkettung" von Bausteinen teil, sondern darf halt mal dazwischenfunken).

Zu Deiner anderen Frage:
Man kann nicht 2 Ausgänge mit einem Eingang verbinden... Da gehört immer ein LBS dazwischen - und von diesem hängt natürlich auch das Verhalten ab

Könnte ich den LBS irgendwie dazu bringen für jeden geänderten Eingang erneut durchzulaufen?

Puh... Naja, mal abgesehen von irgendwelchen Verzögerungs-Bausteinen am Eingang (irgendwie unsauber) bleibt hier nur eine eigene Implementierung mit Variablen etc... Vielleicht wäre es an dieser Stelle sinnvoller, das Design Deines LBS zu überdenken (und an das EDOMI-Logikkonzept anzupassen).


Nochmals zum besseren Verständnis:
Ein LBS ist so konzipiert (und auch zu implementieren), dass bei jedem einzelnen Aufruf genau 1 eindeutiges "Ergebnis" resultiert. Das Ergebnis kann natürlich mehrere Ausgänge setzen - aber nach dem Durchlauf werden die "Ausgänge" erst alle zusammen verarbeitet.