Neutrino über RS232 oder TCP/IP fernbedienen?

[Agent_Smith]

Hallo,

da ich die DBOX von einem PC aus fernbedienen muss (mit dem Programm EventGhost), habe ich das bisher mit der FB-Emulation über HTML Aufrufe an den Webserver der Box gemacht, was leider durch die hohe Latenz des Webservers nicht wirklich praktikabel ist.

Gibt es eine Möglichkeit, die Box über serielle Konsole, Telnet, oder TCP/IP Messages irgendwie fernzubedienen?

Habe schon mal gesucht, aber zu dem Thema nichts weiter in den Wikis oder HowTos gefunden.

Gruß

Agent_Smith

[DrStoned]

Du kannst die Box auch über das Webinterface bedienen, dazu gibst Du in Deinem Webbrowswer http://IP_der_Box ein, wobei IP_der_Box durch die IP-Adresse Deiner Box zu ersetzen ist. Mehr über direkte Befehle hier.

Greetz von DrStoned

[usul1]

Über die serielle Konsole oder Telnet "rcsim" benutzen!?
(Aber dann bedienst du sie blind. Wenn dir das reicht...)

BTW: Was hast du vor das die Latenz eine Rolle spielt?

cu
usul

[Agent_Smith]

Du kannst die Box auch über das Webinterface bedienen, dazu gibst Du in Deinem Webbrowswer http://IP_der_Box ein, wobei IP_der_Box durch die IP-Adresse Deiner Box zu ersetzen ist. Mehr über direkte Befehle hier.

Greetz von DrStoned

äh, du hast schon meine Frage gelesen? Da schrieb ich ja, dass ich diese Möglichkeit nutze, sie aber wegen der Latenz nicht ausreicht. Wenn man mal in der Programmliste ein paar Zeilen runterscrollen will, dauert das so ewig....

Über die serielle Konsole oder Telnet "rcsim" benutzen!?
(Aber dann bedienst du sie blind. Wenn dir das reicht...)

BTW: Was hast du vor das die Latenz eine Rolle spielt?

cu
usul

Da bei mir die ganze Anlage über eine Funkfernbedienung für den PC fernbedient und ein Simpad als Touchscreen bedient wird, muss ich halt auch die DBOX Fernbedienung dort einbinden. Das geht mit den Webserveraufrufen ja schon ein wenig bei einzelnen Befehlen. wenn man jedoch im Menue oder der Programmliste ein dutzend Zeilen herunterscrollen muss, ist das zu langsam.

Ich werde mal rcsim nachlesen und das versuchen. Was meinst du mit "blind"? Ich seh ja die Auswirkungen vorne auf der Leinwand....

Zur Not muss ich halt über den PC die Befehle als IR-Signal wieder an die Box senden, so mach ich das mit anderen Geräten, welche keine Seriellen oder Netzwerk-Fernbedienungsmöglichkeiten haben. IR wollte ich doch soweit es geht bei der ganzen Sache vermeiden.

Danke schon mal für den rcsim-tipp!

Gruß

Agent_Smith

[usul1]

Was meinst du mit "blind"? Ich seh ja die Auswirkungen vorne auf der Leinwand....

Mit "blind" meine ich das ein Programm natürlich automatisiert die rc Befehle für "1", "2" und "OK" über rcsim schicken kann um auf Kanal 12 umzuschalten. Aber das funktioniert nur wenn die Box sich in einen definierten Zustand befindet. Wenn z.B. der Teletext offen ist läuft das ins leere ohne das das Programm mitbekommt das dort was fehlgeschlagen ist.

In deinem Fall ist das natürlich kein Problem. Ich dachte du hast vor irgendetwas automatisiert zu steuern, deshalb der Hinweis.

cu
usul

[Barf]

Hallo Agent_Smith, ich kenne dich von Beisammen, willkommen zum Tuxbox Forum!

Das Einig vernünftige zum Auslösen von einigermasse atomäre Aktionen (Zapping, Radio/TV/SCART-Umschalten, Standby etc) ist das WEB-Api, wie DrStoned schon beschrieben. Z.B. http://dbox/control/zapto?name=ZDF (angenommen dass deine Hosts den Name "dbox" resolven kann). rcsim (sowohl vom Telnet als auch vom WWW) ist für Automatisierungsaufgaben absolut nicht geeignet, am höhstens als letzte Ausweg, oder z.B. zum blättern in schon aufgeklappte Menus. Es gibt dafür am mindestens zwei Grunden: TCP/IP-Kommandos in Event zu übersetzen ist wirklich so clever wie ein Mikrofon vor ein Lautsprecher zu stellen. Zweitens ist die Aktion der Box auf unterschiedliche Tasten extrem zustandsabhängig.

Es fehlen sicherlich Einiges in der web-api, lässt sich aber fixen...

[Agent_Smith]

hallo barf!

also heute mal rumprobiert, das ganze per telnet ist perfekt. tastenwiederholungen im ca. 100ms abstand sind gegenüber den webaufrufen (da brauchst ca. 0,5-1 sekunde) absolut ausreichend.

das ganze läuft schon ganz gut mit putty und scripten, wird jetzt wohl aber direkt in EventGhost integriert.

Das mit dem blind bedienen ist für mich kein problem, weil ich im grunde genommen ja wirklich nur die einzelnen fernbedinungstasten durchreichen will, von meiner pc-fernbedienung.

also vielen dank an alle, das mit rcsim ist für mich die lösung gewesen!

Gruß

Agent_Smith

P.S: nun muss ich die DBox nur noch dazu bringen, dem PC einen Formatwechsel des Bildes mitzuteilen, dann kann dieser den Beamer automatisch umstellen, aber das hab ich ja in einem anderen thread schon gefragt....

[Barf]

tastenwiederholungen im ca. 100ms abstand

Genau diese 100ms-Delay-Frickeln ist ein der Hauptgrunde NICHT Events und rcsim zu benutzen.

... den webaufrufen (da brauchst ca. 0,5-1 sekunde)

Ich kann dies nicht nachvollzeihen. Vielleicht ist dies ein Artefakt von andere Teile (netremote? ) Gibt es ein Problem, dann lösen wir es!

direkt in EventGhost integriert.

Werde mich demnächst auch mit EventGhost beschäftigen!

Das mit dem blind bedienen ist für mich kein problem, weil ich im grunde genommen ja wirklich nur die einzelnen fernbedinungstasten durchreichen will, von meiner pc-fernbedienung.

also vielen dank an alle, das mit rcsim ist für mich die lösung gewesen!

Wirklich automatisierung ist es aber nicht (wegen zustandsabhängigkeit).

P.S: nun muss ich die DBox nur noch dazu bringen, dem PC einen Formatwechsel des Bildes mitzuteilen, dann kann dieser den Beamer automatisch umstellen, aber das hab ich ja in einem anderen thread schon gefragt....

Genau, andere Thread. Ausserdem habe ich seit fast zwei Jahren das Problem mit LIRC gelöst: die dBox schickt mittels LIRC (16:9.lirc und 4:3.lirc) IR-Signale zum Projektor, siehe meine Heimkinoseite.

[Agent_Smith]

Wirklich automatisierung ist es aber nicht (wegen zustandsabhängigkeit).

Das stimmt, ich sehe aber ja immer, was der Tastendruck gerade bewirkt und in welchem Menue/zustand ich grade bin, also reicht das völlig. Was leider nicht geht, ist eine Art Autorepeat, aber das wäre gar nicht so schlimm, wenn ich im mneue 10 Zeilen nach unten will, tip ich halt 10 mal auf die Taste....

Ich kann dies nicht nachvollzeihen. Vielleicht ist dies ein Artefakt von andere Teile (netremote? ) Gibt es ein Problem, dann lösen wir es!

du meinst, dass ein Aufruf der Tastensimulation über die Web-API nicht langsamer sein sollte als in der Telnet Konsole? Hmm, das is bei mir anders, das muss ich dann nochmal gegenchecken.

Gruß

Agent_Smith

[Bitmonster]

Hallo Leute,

dann mische ich mich auch mal ein. Die Probleme mit der Fernbedienung der Box über Netzwerk hat Agent_Smith ja schon zusammengefasst:

1. HTTP ist einfach viel zu langsam. Keine Ahnung wieso, aber es dauert gerne mal eine Sekunde, bis der Request verarbeitet ist. Egal ob ich es von einem Browser aus mache oder durch ein Script gesteuert. Zudem dürfte dort wohl das gleiche Problem wie bei 2. entstehen, weil es wahrscheinlich auf der gleichen Funktionalität wie rcsim basiert.

2. rcsim ist wenn man die Telnet-Verbindung schon offen hat relativ schnell. Hier ist aber das Problem, dass wirklich jeder Aufruf in eine Warteschlange gesetzt wird. Sende ich also z.B. weil der User die Taste länger gedrückt hält, zehn Aufrufe von rcsim innerhalb einer Sekunde ab, wobei die Box gerade mehr als eine Sekunde braucht um eine Pfeiltaste zu verarbeiten (weil sie soviel Zeit braucht den Kanal zu wechseln), dann habe ich einen gewaltigen Nachlauf in der Bedienung. Das ist also auch nicht praktikabel.

Ich habe einen kurzen Blick in den Source-Code von rcsim geworfen und vielleicht ließe sich das Problem umgehen, wenn rcsim nicht bei jedem Aufruf zwangsweise ein KEY_RELEASED auslösen würde. Es wäre also vielleicht einen Versuch wert, eine spezielle Version von rcsim zu machen, bei der ich die Art des Events (KEY_PRESSED, KEY_AUTOREPEAT, KEY_RELEASED) angeben kann. Die Hoffnung ist dabei, dass bei diesem "Tastenfunktionen direkt durchreichen" die Box überzählige Autorepeats entsprechend ignorieren würde und durch den expliziten KEY_RELEASED-Event sich tatsächlich genauso verhält, als ob die Taste auf der FB für längere Zeit gedrückt wurde.

[Bitmonster]

Ich habe gerade mal etwas experimentiert und wie es aussieht würde eine geänderte Version von rcsim auch nicht helfen. Wenn ich nämlich sowas mache:
rcsim KEY_DOWN 1 20
dann wird rcsim ja einen KEY_PRESSED-Event senden, dann 50 KEY_AUTOREPEAT-Events innerhalb von einer Sekunde und abschließend einen KEY_RELEASED Event. Die Box verarbeitet aber tatsächlich jeden KEY_AUTOREPEAT Event und geht entsprechend rund 50 Kanäle weiter. Es findet also keine Filterung der KEY_AUTOREPEAT statt, wie man es von einer IR-Fernbedienung kennen würde. Und die Box ist eben nicht eine Sekunde beschäftigt sondern gleich 20 Sekunden.

Tja, sieht nicht gut aus.

[Barf]

Willkommen zu Tuxbox, Bitmonster!

Einige schnelle Kommentaren:

1. HTTP ist einfach viel zu langsam. Keine Ahnung wieso, aber es dauert gerne mal eine Sekunde, bis der Request verarbeitet ist. Egal ob ich es von einem Browser aus mache oder durch ein Script gesteuert.

Die Zeit bevor ein request fertig wird ist sehr unterschiedlich:

Code: Alles auswählen

$ time wget -q  -O /dev/tty  http://dbox/control/rc?lock
ok
real    0m0.016s
user    0m0.004s
sys     0m0.000s

$ time wget -q  -O /dev/tty  http://dbox/control/volume 
100
real    0m0.015s
user    0m0.000s
sys     0m0.004s


$ time wget -q  -O /dev/tty  http://dbox/control/setmode?tv    
ok
real    0m1.744s
user    0m0.000s
sys     0m0.004s

$ time wget -q  -O /dev/tty  http://dbox/control/zapto?name=ZDF
ok
real    0m0.492s
user    0m0.000s
sys     0m0.004s

Falls die längere Zeiten in den zwei letzteren in KO-Kriterium ist, sollte es möglich sein, dies zu lösen (z.B. fork etc). Wie sehen deine Anforderungen aus?

Zudem dürfte dort wohl das gleiche Problem wie bei 2. entstehen, weil es wahrscheinlich auf der gleichen Funktionalität wie rcsim basiert.

Nein. nhttp schickt Messages zu (z.B.) neutrino (das Programm /bin/neutrino) und zapit.

2. rcsim ist wenn man die Telnet-Verbindung schon offen hat relativ schnell.

Hast du ein Telnetverbindung ist es besser, sowas wie pzapit zum zappen zu benutzen, aus Grunde ich früher erwähnt habe.

[Bitmonster]

Ich galube wir missverstehen uns hier. "zapit" ist z.B. für diesen Fall völlig ungeeignet, weil es nicht ermöglicht genau die Funktionen der FB-Tasten zu emulieren, so wie die Bedienung mit der FB eben erfolgen würde. Und genau das wünschen sich die User hier. Ein gutes Beispiel dafür ist das Programm DboxRemote.exe, welches auch versucht eine FB als Programm auf dem Desktop zu emulieren. Aber es verhält sich eben nicht wirklich wie die FB, da es z.B. keinerlei Autorepeat unterstützt.

Nur yWeb hat über HTTP die entsprechenden Funktionen (z.B. über http://dbox/control/exec?Y_Tools&rcsim&KEY_DOWN). Aber hier kann man eben nicht dafür sorgen, dass der Tastendruck mit geringer Latenz sofort anfängt und dann solange erfolgt, bis der User das Signal zum Loslassen gibt. Und aus der URL läßt sich schließen, dass dabei auch auf rcsim zurückgegriffen wird.

Es ist also nicht nur ein Problem der Latenz, sondern eben auch ein Problem der Funktionalität, die sich über HTTP auch nicht sauber abbilden läßt.

[Barf]

Ich galube wir missverstehen uns hier.

Nicht wirklich. Ich sehe ein, dass es ein legitime Sache sein kann, die Fernbedienung zu emulieren. Ich kann mich durchaus vorstellen, dass die existierende Implementierung bzgl Echtzeitaspekte nicht "akzeptabel" ist. HTTP war auch niemals ein Protokoll für Echtzeitanwednungen -- natürlich kann mann Pragmatisch sagen, dass, in der Regel, bei nicht ausgelastete Servers, trotzdem Antwortzeiten in Millisekundberech zu erwarten ist.

Sicherlich ist hier Tuningmassnahmen denkbar. Vielleicht sogar ein andere Service?

Was ich sage ist dass für viele Aufgaben (z.B. "schalte um nach ZDF") IR-Signalen und deren Emulation eine "Mikrofon vor Lautsprecher"-Lösung ist. Du hast nicht vor, diese Aufgabe in Eventghost durch z.B. emulation der Tasten "Home, Home, Home, 1, delay 100ms, 1, delay 100ms, 5" zu lösen??

[Bitmonster]

Was ich sage ist dass für viele Aufgaben (z.B. "schalte um nach ZDF") IR-Signalen und deren Emulation eine "Mikrofon vor Lautsprecher"-Lösung ist. Du hast nicht vor, diese Aufgabe in Eventghost durch z.B. emulation der Tasten "Home, Home, Home, 1, delay 100ms, 1, delay 100ms, 5" zu lösen??

Nein, natürlich nicht. Hier geht es nur darum die FB zu simulieren, weil der User dieses auch als FB nutzen will. Es soll sozusagen der Übertragungsweg nur ein anderer sein.

Das HTTP nicht wirklich das passende Protokoll für dieses "Tasten-Durchreichen" ist, sehe ich auch so. Eine Applikation die per Telnet gesteuert wird, wäre wohl passender und ist nicht so aufwendig wie einen ganz neuen Netzwerkdienst zu schreiben. Aber da kann ich mich auch irren. Vielleicht ist es eigentlich eine leichte Übung einen neuen Dienst dafür zu implementieren.

Das Problem ist nur, wie man in den Verarbeitungsablauf der dbox eingreifen kann. Nach der Analyse von rcsim scheint es so zu sein, dass die dort verwendeten Events erst "hinter" den Autorepeat-Event-Filter-Funktionen von Neutrino landen. Und für diesen Fall müssten sie entweder davor ankommen, oder man müsste das ganze Autorepeat für diese Anwendung auf einem anderen Weg in Neutrino emulieren.

Oder siehst du noch andere Möglichkeiten?

[Barf]

Erstmals, das Telnetprotokoll ist genau so wenig für Echtzeitanwendungen gedacht und ausgelegt als HTTP. Meine vorletzten Beitrag hat gezeigt, dass die Fernbedienung über HTTP zu "locken" 16 millisekunden dauert; dies soll für die meisten Fälle ausreichen schnell sein.

Ich glaube eher, es wäre sinnvoll zu verstehen, genau was Zeit dauert, und evtl "tunen". Z.B. wird in rcinput.cpp Merkwürdiges gemacht. Mal sehen...

[Carjay]

KEY_AUTOREPEAT kann nichts mit dem Problem zu tun haben, da rcsim hier die gleichen Events auslöst wie der FP-Treiber selber. Eine Filterung findet dort nicht statt.

Das ist auch insofern leicht nachvollziehbar, da der Treiber nun einmal nicht voraussehen kann, ob die Anwendung die "prellenden" Events auswerten möchte oder nicht. Daher werden diese Events immer weitergereicht und die Anwendung filtert sie dann selber.

Ich weiß allerdings nicht, ob Neutrino da nicht irgendwelche eigenen Wege geht und das KEY_AUTOREPEAT geflissentlich ignoriert. Dann könnte es nämlich der unterschiedliche zeitliche Abstand sein, der das Filtern scheinbar fehlschlagen läßt.

Es ist übrigens wichtig, daß man die Reihenfolge
KEY_PRESSED, [KEY_AUTOPEAT], KEY_RELEASED
immer einhält, ansonsten kann das die Zustandsmaschine im InputEvent-Treiber (vom Linuxkernel) durcheinander bringen!

[Bitmonster]

Ich weiß allerdings nicht, ob Neutrino da nicht irgendwelche eigenen Wege geht und das KEY_AUTOREPEAT geflissentlich ignoriert. Dann könnte es nämlich der unterschiedliche zeitliche Abstand sein, der das Filtern scheinbar fehlschlagen läßt.

Aber irgendwas muss da sein. In der Regel baut man ja solche Filter mit der Bedingung "wenn Zeitabstand kleiner als X" und ein "rcsim KEY_DOWN 1 20" wird mit Sicherheit mehr Autorepeats generieren als die normale FB.

[Barf]

Ich habe testweise rcsim in den web-server integriert. Dabei habe ich "rcsim" in "rcem" umgenannt, weil, erstens, eine "emulation" mehr korrekt als "simulation" ist, zweitens weil ich die semantik für die rcsim Argumente sehr unlogisch finde, und eventuell möchte, bei eine Erweiterung, davon abweichen.
Syntax ist z.B.

Code: Alles auswählen

http://dbox/control/rcem?KEY_UP

Diese Version unterstützt erstmals nur ein Keypress, keine Repeats. Die Responseziten sind deutlich besser, typischerweise etwa 60ms (Yjogols Zeug braucht etwa das zehnfache.) Variert aber sehr.

Ich glaube nicht, dass damit das letzte Wort gesagt ist.

rcsim KEY_DOWN 1 20 (wie oben diskutiert) ist eigentlich eine kleiner DOS-Attacke ("Denial-Of-Service").

Patch hier. hier Binary von nhttpd. Bitte testen.

[Bitmonster]

Hi Barf,

super Sache. Jetzt musst du mir aber doch mal auf kurz die Sprünge helfen. Gibt es einen Weg den nhttp z.B. mit einer Version aus /var/bin/ zu ersetzen (killen und neustarten) oder muss ich ein YADD erstellen?

Ein Hauptproblem bei einer Tasten-Emulation ist aber, dass entweder der Sender oder der Empfänger auf die Dauer der Ausführung Rücksicht nehmen müssen. Es macht z.B. nicht wirklich Sinn eine feste Wiederholrate beim Sender zu implementieren, weil man in der Kanalliste zwar sehr schnell voran kommt und dort auf vielleicht 1/10s gehen könnte, aber beim direkten Kanalwechsel gerne mal 2 Sekunden und mehr braucht. Der Sender müsste also entweder wissen, wann die Taste vom Empfänger vollständig bearbeitet wurde oder der Empfänger muss eben nach einem Begin/End-Schema funktionieren.

[Barf]

Gibt es einen Weg den nhttp z.B. mit einer Version aus /var/bin/ zu ersetzen (killen und neustarten)

zum Testem ausreichend. Mittelfristig wurde ich ein jffs2-Image, z.B. dietmarw, empfehlen.

Selbst mache ich natürlich alle "Fummelein" in YADD-Umgebung.

Ein Hauptproblem bei einer Tasten-Emulation ist aber, dass entweder der Sender oder der Empfänger auf die Dauer der Ausführung Rücksicht nehmen müssen. Es macht z.B. nicht wirklich Sinn eine feste Wiederholrate beim Sender zu implementieren, weil man in der Kanalliste zwar sehr schnell voran kommt und dort auf vielleicht 1/10s gehen könnte, aber beim direkten Kanalwechsel gerne mal 2 Sekunden und mehr braucht. Der Sender müsste also entweder wissen, wann die Taste vom Empfänger vollständig bearbeitet wurde oder der Empfänger muss eben nach einem Begin/End-Schema funktionieren.

(Bei KEY_RELEASED Eventqueue leeren ) Kein einfaches Problem, ich weiss aber nicht wie zielführend. Zapping in DVB-Umgebung ist sowieso langsammer als analog TV (Iframes nur ein oder zwei per Sekunde); blättern in Listen, tja....

[Bitmonster]

Ich merke gerade, dass Neutrino selbst mit der FB wahrscheinlich genau den gleichen Bug hat. Drückt man lange auf den Abwärtspfeil, dann läuft Neutrino auch gigantisch nach. Also ein ziemlicher Designfehler.

zum Testem ausreichend. Mittelfristig wurde ich ein jffs2-Image, z.B. dietmarw, empfehlen.

Kannst du mir mal kurz die notwendigen Telnet-Shell-Kommandos sagen?
kill nhttp
/var/bin/nhttp

Geht das so?

[Bitmonster]

(Bei KEY_RELEASED Eventqueue leeren )

Ja genau das sollte Neutrino machen. Tut es offenbar aber nicht oder nicht immer.

[Barf]

Kannst du mir mal kurz die notwendigen Telnet-Shell-Kommandos sagen?
kill nhttp
/var/bin/nhttp

Erstmals mit ftp das Executable nhttpd irgendwie in schreibbare Bereich (/var/bin oder /tmp bieten sich an, in /tmp gibt es "immer" Platz; überlebt nicht aber ein Reboot). Danach ausführbar machen mit chmod +x nhttpd. Alte stoppen mit killall nhttpd (z.B.). Neue starten mit (z.B.) /var/bin/nhttpd.

Ja, Neutrino hat einige Designschwächen,... (Kuck dir den Eventloop in neutrino.cpp an, falls du starke Nerven hat.)

[Bitmonster]

Gerade mal ausprobiert. Ist wirklich rasend schnell im Vergleich zu dem alten nhttp.