LBS(Sammlung) Squeeze

[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]

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]

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]

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?

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

[jonofe]

Es scheint nur der letzte Befehl zu überleben. Könnte sein, dass EDOMI erst die Ausgänge nach dem komplette Durchlauf des LBS übernimmt und dann die geänderten Ausgänge für die weitere Logik berücksichtigt. Würde dazu passen, dass nur "play stop" ausgeführt wird.

Mit dem Workarounds eines Verzögerers vor dem "power" Eingang funktioniert es zwar. Dies aber auch nur, da ein Play Kommando die Squeezebox auch gleichzeitg einschaltet. Wäre dies nicht der Fall, dann würde vermutlich Play ignoriert und nur Power ausgeführt.
2016-03-05 14_47_49-EDOMI · Administration.png

[jonofe]

Herr Lehrer, der André schreibt ab!

Lach ... hatte nur deinen letzten Post, aber nicht den vorletzten gelesen. aber schön, dass wir das genauso sehen.

[wintermute]

Es scheint nur der letzte Befehl zu überleben.

Herr Lehrer, der André schreibt ab!

[jonofe]

Zu 1) kannst du vllt mal ein Bild davon machen? Dann versuche ich das nachzustellen, ich kann mir das grad nicht vorstellen...

Ich habe eine Vermutung bzgl. meines Problems: Da ja durch ein KO zwei Befehle in einem Durchlauf getriggert werden, wird der Ausgang bei einem LBS-Durchlauf ja zweimal gesetzt zuerst auf den Befehl "xx:xx:xx:xx:xx:xx power 0" und danach auf "xx:xx:xx:xx:xx:xx play stop". Es scheint nur der letzte Befehl zu überleben. Könnte sein, dass EDOMI erst die Ausgänge nach dem komplette Durchlauf des LBS übernimmt und dann die geänderten Ausgänge für die weitere Logik berücksichtigt. Würde dazu passen, dass nur "play stop" ausgeführt wird.

[wintermute]

Ich hab übrigens im Trace-Log auch immer wieder solche Einträge:

Wie gesagt, das ist normal, diese Meldungen sind keine Fehler... ich sammel damit Meldungen die der Baustein noch nicht kennt. Das sollten von Version zu Version immer weniger werden.
Und ja, auch "externe" Aktionen erzeugen mitunter solche Eintraege, denn auch die externe Aktion fuehrt zu einer Ausgabe vom LMS an den Server-Baustein.
Und ja, "sync" kennt er (ganz bewusst ) noch nicht
Und wie ich das mit dem Syncen am besten abbilde muss ich mir dann mal ueberlegen, vor allem weil es ja (wie du auch geschrieben hast) verschiedene Arten gibt die Player zu syncen...

Freut mich, dass Dein Wechselrichter wieder lebt

[wintermute]

Hi André,

Das habe ich gemacht (s.u.). Der Effekt bleibt aber gleich. Wenn dieselbe GA auf "Stop" und auch "Play" liegt, dann wird beim Senden einer 0 der Player zwar gestoppt aber nicht ausgeschaltet.

Ich habe das mal nachgestellt und kann den Effekt auch beobachten. Dann hab ich mal ein wenig rumdebugged und folgendes rausfinden koennen:
-der Kommando LBS bekommt mit, dass beide Eingaenge refreshed wurden
-aufgrund dessen arbeitet er auch beide Eingaenge ab (allerdings in der Reihenfolge wie sie im Code stehen, also erst power, dann play)
-er schickt auch zwei Kommandos an den Ausgang
-ABER: das zweite Kommando ueberschreibt das erste (deswegen kommt immer nur play/stop an, aber nie power)

Jetzt brauch ich dazu mal den Christian
gaert wenn ich in einem Baustein (in einem Durchlauf) zunaechst ein setLogicLinkAusgang($id,1,"Erste") mache und dann (also im selben Durchlauf) ein setLogicLinkAusgang($id,1,"Zweites") aufrufe, dann wird das erste komplett ignoriert und nur das zweite interpretiert. Zumindest sieht mir das gerade danach aus.
Frage: ist das so beabsichtigt? Oder nicht? Oder vertue ich mich grad komplett?

gruesse :: Michael

[rdeckard]

OK, wie erwartet. Das Problem lag am LMS!

Die beiden Player hatten unterschiedliche Synchronisierungs-Settings. Dann ist's logisch, dass es zu einem komischen Verhalten kommen kann, je nach dem, welchen Player man grad ansteuert (über die MAC-Adresse).

Hier noch zur Veranschaulichung, auf was man im LMS achten sollte (in diesem Fall bei nur zwei synchronisierten Playern):
squeeze9.png
squeeze10.png

Natürlich kann es manchmal Sinn machen, wenn man die Lautstärke getrennt steuern möchte. Aber dann wirds mit einer zentralen Visu bald sehr kompliziert, weil man dann auf jeden einzelnen Player wechseln müsste und nicht nur auf die Gruppe.

[jonofe]

2016-03-05 12_08_47-EDOMI · Administration.png


Der Binärauslöser (s.o.) ist natürlich Unsinn, habe nicht richtig die Beschreibung gelesen. Es sollte natürlich ausreichen, die GA einfach nur auf "Power" und auf "Play" zu legen, da sowohl der Play als auch der Stop Eingang ja "Play/Pause/Stop" unterstützen. Das habe ich gemacht (s.u.). Der Effekt bleibt aber gleich. Wenn dieselbe GA auf "Stop" und auch "Play" liegt, dann wird beim Senden einer 0 der Player zwar gestoppt aber nicht ausgeschaltet.


2016-03-05 12_46_05-EDOMI · Administration.png

[rdeckard]

So, ich bin wieder wach....und viel wichtiger, mein Wechselrichter auch! (Scheinbar braucht der WR gewisse Spannung von der DC-Seite, damit ein Firmware-Update durchgeführt werden kann. Und jetzt, wo die Panels wieder etwas Leistung bringen - es regnet zwar - läuft das Ding wieder normal. Uff!)

Habe jetzt im LMS wieder mal meine beiden Player zusammengefasst (synchronisiert), wie ich es vor den LBS eigentlich verwendet habe.
Jetzt ist mir aber aufgefallen, dass die Volume-Steuerung nicht synchronisiert wird. Stop/Pause etc. reagiert auf beide Player. Aber Volume nur auf einen der beiden.
Das war vorher mit der HTTP-Steuerung nicht der Fall.

Aber es kann auch sein, dass das Problem nicht vom LBS, sondern vom LMS kommt. Denn wenn ich im LMS die Lautstärke ändere, dann bezieht sich diese auch nur auf einen Player. (Obwohl sie synchronisiert sind)
Muss das noch etwas weiter testen, um die Ursache rauszufinden. (Werde temporär wieder meine HTTP-Befehle in die Visu nehmen, um zu sehen, obs da anders ist.)

Ich hab übrigens im Trace-Log auch immer wieder solche Einträge:

[COLOR=#393930][FONT=EDOMIfontMono][SIZE=10px]LBSLBSID(126): UNKNOWN PLAYER OUTPUT: b8%3A27%3Aeb%3A28%3A91%3Ad9 play[/SIZE][/FONT][/COLOR]

Ah..wart...hab grad das im Trace-Log gesehen:

[COLOR=#393930][FONT=EDOMIfontMono][SIZE=10px]LBSLBSID(126): UNKNOWN PLAYER OUTPUT: b8%3A27%3Aeb%3A28%3A91%3Ad9 [/SIZE][/FONT][/COLOR][COLOR=#FF0000][FONT=EDOMIfontMono][SIZE=10px]sync -[/SIZE][/FONT][/COLOR]
[COLOR=#393930][FONT=EDOMIfontMono][SIZE=10px]LBSLBSID(126): UNKNOWN PLAYER OUTPUT: b8%3A27%3Aeb%3A01%3A28%3A02 [/SIZE][/FONT][/COLOR][COLOR=#FF0000][FONT=EDOMIfontMono][SIZE=10px]sync[/SIZE][/FONT][/COLOR][COLOR=#393930][FONT=EDOMIfontMono][SIZE=10px] b8%3A27%3Aeb%3A28%3A91%3Ad9[/SIZE][/FONT][/COLOR]

Somit stammen diese UNKNOWN PLAYER OUTPUT Meldungen von extern, d.h. wenn ich direkt auf der LMS Seite den Player gesteuert habe. Das würde in etwa hinhauen.
Vorallem habe ich vorher ja mal den Sync getrennt und anschliessend neu synchronisiert. Das zeigt wohl die letzten beiden Einträge. (Denn der LBS weiss ja noch nichts von Synchronisieren)

[jonofe]

Zu 1) kannst du vllt mal ein Bild davon machen? Dann versuche ich das nachzustellen, ich kann mir das grad nicht vorstellen...

2016-03-05 12_08_47-EDOMI · Administration.png