gibt es noch ein passenderes Board als „allgemeine Disk.“ für IR-Trans-Fragen?
Ich habe gestern mein IR-Trans (Ethernet) Modul bekommen und in Betrieb genommen.
Testweise mal ein paar Geräte angelernt, funktioniert auch soweit - sowohl mit der IR-Trans-GUI, als auch per Script im IPS.
Nun wollte ich auch meine Audionet-Vorstufe (MAP1) steuern, da traten aber Probleme auf.
Ich habe ein paar Funktionen mit IR-Trans gelernt (Power, lauter, leiser, etc.).
Diese Funktionen lassen sich auch per „Befehl senden“ der IR-Trans-GUI problemlos ausführen.
Nur über IPS (Event Script) geht das nicht, es kommt offensichtlich kein Befehl an.
Das Problem besteht wie gesagt nur mit der Audionet, andere Geräte lassen sich problemlos sowohl über die IR-Trans-GUI als auch über IPS-Scripte problemlos steuern.
Hat jemand eine Idee wo ich da anfangen kann zu suchen?
Es ist ein und das selbe Script, die ersten beiden Zeilen mit Sende-Befehlen werden problemlos verarbeitet, der nächste mit einem Befehl für die Audionet nicht…
neuer Tag, neues Glück
Hab heute nochmal wieder probiert und es scheint zu helfen wenn man zwischen den Befehlen eine kleine Pause setzt (mit IPS_Sleep) - nun scheint es relativ zuverlässig zu funktionieren.
Ist aber tatsächlich nur für die Audionet-Befehle notwenig, die Befehle für die anderen Geräte werden problemlos direkt hintereinander durchgerappelt.
Bestimmte geräte bauen einem ‚fenster‘ ein wobei nach empfang einem complettes telegram dem empfang kurz gedisabled wird. (Oder der CPU braucht zeit um aus zu fuhren - oder die disablen um gespiegelte doppelt telegramma aus zu schliessen)
Meinstenns brauchte ich eine pause ein zu bauen innerhalb eine ‚macro‘ telegramm. Mehrere commando’s auf einem gerät. Zb ./… (10-er numero’s) + ‚2‘ + ‚2‘ -> kanal 22. hier brauchte ich ‚erfahrungwert‘ 400ms zu warten
bei mir waren es ja Befehle für verschiedene Geräte:
1 x Beamer an
1 x HDMI-Switch Eingang 1
1 x Audionet power on
1 x Licht aus
Wenn ich alle direkt hintereinander ausführe, dann werden alle ausgeführt, bis auf den Audionet power on. Wenn ich vor dem Audionet-Befehl eine Pause einfüge, dann geht es.
Das fand (und finde ich) merkwürdig.
ich finde, Vergleiche zwischen Computer- und menschlicher Kommunikation hinken immer ziemlich
Ich möchte nur verstehen wo da was verloren geht und was für Lehren ich da für zukünftige Scripte draus ziehen kann.
Also wo vergallopiert sich das Gesamtsystem?
[ul]
[li]IPS „vergisst“ bei der Abarbeitung des Scriptes den Befehl auszuführen? (halte ich für eher unwahrscheinlich)
[/li][li]Bei der Übergabe des IR-Befehls von IPS zu IR-Trans?
[/li][li]IR-Trans bekommt den Befehl ordnungsgemäß von IPS übergeben, „vergisst“ ihn dann aber. (halte ich auch für eher unwahrscheinlich)
[/li][li]Das/die angesprochene(n) Geräte ignorieren den ordnungsgemäß gesendeten Befehl (halt ich auch für unwahrscheinlich)
[/li][/ul]
Ich halte den 2. Punkt für am Wahrscheinlichsten.
Trotzdem stellt sich mir die Frage warum ausgrechnet bei der MAP1 vor dem Befehl eine Pause notwendig ist. Für die MAP1 ist es ja der einzige Befehl, der kommt, die anderen Befehle die vorher kommen, sind ja auch für andere Geräte bestimmt.
Logisch finde ich das immer noch nicht.
Und was für Lehren ziehe ich nun daraus? Vorsichtshalber vor jedem Steuerungsbefehl in einem Script eine 1000ms Pause zu setzen?
Kann ja eigentlich auch nicht sein, oder?
Wenn das die Lösung ist, kann ich damit leben - ich gehe den Dingen nur gerne auf den Grund und versuche aus Fehlern zu lernen
es gibt kein Infrarot-Protokoll an dass sich alle Hersteller halten müssten.
du sendest beispielsweise folgendes:
047E 5F09 8014 0B86 AA5C 11
Gerät 1 erkennt hier einen Einschaltbefehl 047E 5F09 8014 0B86 AA5C 11
Gerät 2 hier eine Lautstärkeänderung auf X
047E 5F09 8014 0B86 AA5C 11
und gerät 3 erkennt hier garnichts 047E 5F09 8014 0B86 AA5C 11
weil vielleicht nur der Teil 0B86 AA5C 11 für es bestimmt war und 11 ne ungültige Checksumme für 047E 5F09 8014 0B86 AA5C ist. Für 0B 86 AA 5C ist 11 aber gültig.
vielleicht bedeutet für Gerät 1 der Code 047E ja auch „ON“ und gleichzeitig für Gerät 2 „OFF“. Dann könnten Gerät 1 und 2 nicht vernünftig bedient werden. Das ist zwar recht selten, kann aber vorkommen.
ein viertes gerät erkennt hier
047E 5F09 8014 0B86 AA5C 11
vielleicht fälschlicher Weise einen Befehl, obwohl das nur der zweite Teil eines ersten befehls und der erste Teil eines zweiten Befehls ist.
Und dann gibts noch Geräte die verwenden ne Art rolling Code. Ein und der selbe Befehl sieht immer anders aus. Aber das ist ein anderes Thema.
Ah OK - Du meinst also durch das zu schnelle Senden von Befehlen hintereinander könnten eigentlich getrennte gemeinte Befehle zu einer langen Folge von IR-Codes verschmelzen und damit den einen oder anderen Empfänger verwirren?
Ich hatte jetzt gedacht dass ein Gerät Befehle, die gar nicht es bestimmt sind, einfach ignoriert (bzw. gar nicht erst erkennt).
Ja, das macht es auch. Aber zuerst muss das Gerät das überprüfen. Vielleicht blockiert der IR Empfänger für eine Zeitspanne den Empfang und wartet bis es wieder ein Signal auffangen kann.
Versuch’ mal die Reihenfolge zu ändern und dein AudioNet an die erste Stelle zu setzen. Dann kann es zu diesem Problem gar nicht kommen.
OK.
An die erste Stelle setzen ist zwar eine Lösung, aber nicht praktikabel wenn ich mehrere Befehle absetzen möchte (z.B. erstmal „power on“ und Auswahl eines Eingangs.
Aber das Einfügen einer Pause im Script ist ja OK, damit kann ich leben.
Ich hatte nur nicht verstanden warum das Problem überhaupt auftritt.
Jetzt aber schon
Tun sie ja auch… Es passiert in der Regel garnichts. So wie bei deinem Audionet. Das heisst aber nicht, dass es auch mal anders sein kann. Das hängt von Pufferzeiten, Latenzen und Toleranzen ab und ist von Hersteller zu Hersteller und Gerät zu Gerät unterschiedlich. Ladezustand der Batterien in der Fernbedienung und die Toleranz des Gerätes diesbezüglich, verwendetes Protokoll, etc… spielt unter Umständen alles eine Rolle… Manchmal aber eben auch nicht.
Mit anderen Worten: Kann man nicht wissen. Mach einfach einige hundert Millisekunden Pause zwischen den Befehlen. Die meissten Geräte sollten damit klar kommen.
