Hallo, wie vielleicht einige bereits mitbekommen haben (Artikel der Woche), gibt es ein neues IRMP-Projekt, nämlich Remote IRMP. Dies soll der dazu gehörende Diskussions-Thread werden. Hier verschaffen wir unserem Mikrocontroller nicht nur einen IR-Sender und Empfänger, sondern auch noch einen Netzwerkanschluss. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte IRMP-Codes an den gewünschten µC. Dieser strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten. Außerdem ist eine Erweiterung von IRMP um Funksender geplant, damit zukünftig auch Funksteckdosen bequem vom Handy aus geschaltet werden können. Der Artikel ist noch nicht ganz fertig, aber man kann damit schon mal arbeiten. Ich werde den Artikel natürlich in Zukunft weiter vervollständigen und pflegen. Viel Spaß! Gruß, Frank
Angehängte Dateien:
Joachim B. schrieb im Beitrag Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" > PS ob es auch mal möglich wäre den Code in gcc auf den raspberry PI zu > bringen ? Das wird schwierig bis unmöglich, da Linux nun mal kein Echtzeitsystem ist. Aber ich hätte da einen Vorschlag: Man hängt den ATmega328 samt IR-Empfänger/Sender an den UART des Raspberry PI. Dann kann man das Remote-IRMP-Programm fast unverändert übernehmen. Es empfängt/sendet dann die Daten nicht über den W5100, sondern über den UART. Auf dem Raspberry wird ein kleiner Daemon installiert, welcher alle Daten vom IP-Port 10001 auf den UART umlenkt und umgekehrt - fertig! Die Remote-IRMP-Clients (z.B. unter Android) können dann unverändert arbeiten. Auch der IP-Bootloader könnte so funktionieren. Dann kann man den ATmega auch über das Netzwerk flashen. Ich werde mir mal einen Raspberry bestellen und das so implementieren. Mit Linux-TTYs habe ich genügend Erfahrung, das Programmieren des Daemons ist für mich eine Kleinigkeit.
:
Bearbeitet durch Moderator
Torsten C. schrieb im Beitrag Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" > Macht es Sinn das ganze mit netio von davideickhoff zu kombinieren? Ja, warum nicht? Sollte nicht allzu schwierig sein. > Weil sich im Consumer-Bereich immer die Lösungen duchsetzen, die (bei > ansonsten vergleichbaren Eigenschaften) um ein paar Cent billiger sind, > würde ich mein Remote-IRMP gern mit mehreren NRF24L01+ umsetzen. Das sind 2,4GHz Transceiver, nicht wahr? Wir bekommst Du diesen an Dein Android-Handy? ;-) Klar kann man die Transceiver mit IRMP koppeln. Wenn Du mir noch sagst, wie und mit welcher Plattform Du mit den Dingern kommunizierst, können wir da bestimmt was zusammen auf die Beine stellen. > Aber ich befürchte, dass man dabei wenig aus dem > Internet-Prtokoll-orientierten Remote IRMP übernehmen kann. Oder wie > seht Ihr das? Man muss nur den IP-Teil durch ein anderes Modul ersetzen. Das ist eine Kleinigkeit. Gruß, Frank
Hi, zunächst einmal schön, Gratulation zu deinem nächsten Projekt ;). Ich finde es schön, dass in Sachen IRMP wieder ein wenig Wind in die Sache kommt - vor allem in Bezug auf Funktionalität. IRMP scheint ja in dieser Beziehung "fertig" entwickelt zu sein. Inwiefern die Leute von Remote IRMP Gebrauch machen, werden wir sehen. Viele Android Geräte bieten ja (mittlerweile wieder) IR Dioden, insofern wahrscheinlich nicht für jeden zu gebrauchen. Ich fände eine "Relay" Funktion auch ganz interessant, d.h. das empfangene Signale woanders wieder ausgestrahlt werden. Ich persönlich bin auch kein allzugroßer Freund von Arduino (oder vergleichbar "schwachen" Mikrocontrollern) und Geschichten im Netzwerk. Ein ordentlicher Netzwerkstack (inkl. TCP, DHCP, NTP) nimmt doch etwas mehr Platz in Anspruch als üblicherweise zur Verfügung steht. Die "All-in-One" Hardware-Module überzeugen mich auch nicht sonderlich. Aber für solche "trivialen" Protokolle reicht es wohl dann doch. Überhaupt besteht ja zukünftig scheinbar auch die Möglichkeit etwas "Vernünftiges" (in Sachen Netzwerk) wie z.B. einen Raspberry Pi zu verwenden. Ein "standardisiertes" Protokoll finde ich aber äußert praktisch. Es gibt ja schon einige Consumer-Produkte in diesem Bereich, die meines Wissens allesamt untereinander inkompatibel sind. Insofern wäre es schön, wenn die Hersteller hier etwas aufgreifen würden bzw. sich einbringen würden (natürlich eine reine Wunschvorstellung ;)). Was die Android Applikation angeht: Sind die Quellen öffentlich zugänglich? Wir hatten die Diskussion schon im Wordclock Thread geführt. Ich bin nach wie vor der Meinung, dass du Gebrauch von github & Co. machen solltest, um die Entwicklung voranzutreiben. Die App schaut noch sehr rudimentär aus (kein Vorwurf!), insofern gibt es bestimmt ein paar Leute, die da gerne weiterhelfen würden. Des Weiteren wäre es sehr hilfreich, wenn die App auch im Play Store verfügbar gemacht würde. Damit spart man sich das Herunterladen von apk's (und insbesondere die Umgehung der Sicherheitseinstellungen). Außerdem gibt es dann automatisch Updates. Nochmals, Gratulation zu deinem nächsten Projekt und viel Spaß bei der zukünftigen Weiterentwicklung! Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Hi Karol, Karol Babioch schrieb: > zunächst einmal schön, Gratulation zu deinem nächsten Projekt ;). Danke :-) > Ich > finde es schön, dass in Sachen IRMP wieder ein wenig Wind in die Sache > kommt - vor allem in Bezug auf Funktionalität. IRMP scheint ja in dieser > Beziehung "fertig" entwickelt zu sein. Ab und zu kommt mal noch ein neues Protokoll hinzu (die Dreambox-FB reizt mich da noch), aber sonst ist IRMP eine stabile Software-Bibliothek, welche auch schon auf verschiedenste Mikrocontroller portiert wurde. > Inwiefern die Leute von Remote IRMP Gebrauch machen, werden wir sehen. > Viele Android Geräte bieten ja (mittlerweile wieder) IR Dioden, insofern > wahrscheinlich nicht für jeden zu gebrauchen. Das Problem ist da, dass man nur Geräte desselben Herstellers ansprechen kann. Soviel ich weiß, kann man mit einem Samsung S4 lediglich Samsung-Geräte (wie Fernseher) steuern... lasse mich da aber gern eines Besseren belehren. Der Reiz an Remote IRMP ist aber gerade die Netzwerkfähigkeit. Bei den Lösungen mit integrierter IR-Diode im Handy musst Du unmittelbar vor dem Gerät stehen. Ausserdem ist ja - wie erwähnt - noch die Erweiterung auf Funksteckdosen-Sets geplant. Das bekommst Du auch mit einem S4 so nicht hin. > Ich fände eine "Relay" > Funktion auch ganz interessant, d.h. das empfangene Signale woanders > wieder ausgestrahlt werden. Eben. Dafür ist IP (über LAN oder WLAN) prädestiniert. > Ich persönlich bin auch kein allzugroßer Freund von Arduino (oder > vergleichbar "schwachen" Mikrocontrollern) und Geschichten im Netzwerk. > Ein ordentlicher Netzwerkstack (inkl. TCP, DHCP, NTP) nimmt doch etwas > mehr Platz in Anspruch als üblicherweise zur Verfügung steht. Die > "All-in-One" Hardware-Module überzeugen mich auch nicht sonderlich. Aber > für solche "trivialen" Protokolle reicht es wohl dann doch. Ja, für so eine Anwendung reicht ein WizNet-Modul vollkommen und verbraucht auch so gut wie keine CPU-Ressourcen. Der Netzwerkstack läuft stabil. > Überhaupt > besteht ja zukünftig scheinbar auch die Möglichkeit etwas "Vernünftiges" > (in Sachen Netzwerk) wie z.B. einen Raspberry Pi zu verwenden. Ja, mit der Gateway-Funktion Client <-> (W)LAN <-> Embedded Linux <-> UART <-> ATmega <-> IR ist der Phantasie keine Grenzen gesetzt. Ich habe hier auch noch ein paar BeagleBones rumfliegen. Auch darauf ist eine Portierung geplant. > Ein "standardisiertes" Protokoll finde ich aber äußert praktisch. Es > gibt ja schon einige Consumer-Produkte in diesem Bereich, die meines > Wissens allesamt untereinander inkompatibel sind. Insofern wäre es > schön, wenn die Hersteller hier etwas aufgreifen würden bzw. sich > einbringen würden (natürlich eine reine Wunschvorstellung ;)). Ich könnte mir da ein XML-basiertes Protokoll als Standard vorstellen. Ich werde mal meine Fühler ausstrecken und ein Konzept entwickeln. > Was die Android Applikation angeht: Sind die Quellen öffentlich > zugänglich? Wir hatten die Diskussion schon im Wordclock Thread geführt. > Ich bin nach wie vor der Meinung, dass du Gebrauch von github & Co. > machen solltest, um die Entwicklung voranzutreiben. Die App schaut noch > sehr rudimentär aus (kein Vorwurf!), insofern gibt es bestimmt ein paar > Leute, die da gerne weiterhelfen würden. Die Quellen der Android-App sind momentan nicht öffentlich zugänglich. Ich werde aber noch darüber nachdenken, ob ich sie veröffentlichen werde. Dank des dokumentierten Protokolls ist es jedoch eine Kleinigkeit, einen komplett anderen Client anzubinden. Die Code-Passagen für die UDP-Kommunikation (in Java) sind minimal. Diese kann ich gern noch kurzfristig in die Dokumentation - sprich Artikel - aufnehmen. Ja, die App wirkt etwas rudimentär. Ich habe da bei der Entwicklung aber auch nur ein paar Stunden reingesteckt, um überhaupt etwas vorweisen zu können. Ich bin schon immer bei Projekten - wie fli4l oder eisfair - so vorgegangen, dass ich erstmal einen lauffähigen Prototypen vorgestellt habe. Bei guter Dokumentation finden sich dann immer einige Interessierte, die sich mit ins Projekt einbringen wollen. So bestand das fli4l- und eisfair-Entwickler-Team in der Blütezeit der Projekte aus mehreren dutzend Entwicklern. Auch hier könnte etwas ähnliches entstehen. Dabei ist die Dokumentation fast noch wichtiger als der eigentlich Code. Aus diesem Grund ist der IRMP-Artikel auch mittlerweile viele viele Seiten lang. Die fli4l- und eisfair-Dokumentation ist sogar noch um einiges ausführlicher und wird von mehreren Entwicklern gepflegt. > Des Weiteren wäre es sehr hilfreich, wenn die App auch im Play Store > verfügbar gemacht würde. Damit spart man sich das Herunterladen von > apk's (und insbesondere die Umgehung der Sicherheitseinstellungen). > Außerdem gibt es dann automatisch Updates. Sobald die Sache einen größeren Rahmen annimmt, wird die App (in einer weiterentickelten Form) durchaus auch im Play Store auftauchen. Verstehe bitte die aktuelle Version erstmal als Prototyp und Fallstudie. Viele Grüße, Frank
Frank M. schrieb: > Das Problem ist da, dass man nur Geräte desselben Herstellers ansprechen > kann. Soviel ich weiß, kann man mit einem Samsung S4 lediglich > Samsung-Geräte (wie Fernseher) steuern... lasse mich da aber gern eines > Besseren belehren. Ne, eine solche Beschränkung ist mir nicht bekannt. Im Bekanntenkreis kann man z.B. mittels einem S4 Galaxy Zoom ein LG Gerät steuern. Das hängt wohl mehr von der verwendeten App ab. Kann sein, dass die vom Hersteller mitgelieferten beschränkt sind. Frank M. schrieb: > Ja, mit der Gateway-Funktion > > Client <-> (W)LAN <-> Embedded Linux <-> UART <-> ATmega <-> IR > > ist der Phantasie keine Grenzen gesetzt. Ich habe hier auch noch ein > paar BeagleBones rumfliegen. Auch darauf ist eine Portierung geplant. Das macht den Aufbau halt etwas größer. Prinzipiell wäre es schön(er), wenn man IR-Empfänger bzw. Sender direkt an das Linux-Board hängen könnte. Wird in der Praxis wohl, wie du schon erwähnt hast, problematisch (Echtzeitfähigkeit, etc.). Frank M. schrieb: > Ich könnte mir da ein XML-basiertes Protokoll als Standard vorstellen. > Ich werde mal meine Fühler ausstrecken und ein Konzept entwickeln. (Valides) XML ist schon mit sehr viel Overhead verbunden. Deine bisher recht wenigen Bytes sind dann z.B. schnell verfünfacht. Ein XML Parser auf einem Mikrocontroller macht vermutlich auch wenig Sinn. Allerdings wüsste ich auch nicht was es für (offene) Alternativen gibt. JSON bzw. YAML sind in dieser Hinsicht auch nicht wirklich besser :(. Frank M. schrieb: > Die Quellen der Android-App sind momentan nicht öffentlich zugänglich. Schade ;). Frank M. schrieb: > Dank des dokumentierten Protokolls ist es jedoch eine > Kleinigkeit, einen komplett anderen Client anzubinden. Die Code-Passagen > für die UDP-Kommunikation (in Java) sind minimal. Diese kann ich gern > noch kurzfristig in die Dokumentation - sprich Artikel - aufnehmen. Wegen mir gerne! Frank M. schrieb: > Ich bin schon immer bei Projekten - wie fli4l oder eisfair - so > vorgegangen, dass ich erstmal einen lauffähigen Prototypen vorgestellt > habe. Ist auch richtig so. Wie gesagt, dass mit der rudimentären Version war keineswegs vorwurfsvoll gemeint. Irgendwo muss man ja anfangen ;). Frank M. schrieb: > Sobald die Sache einen größeren Rahmen annimmt, wird die App (in einer > weiterentickelten Form) durchaus auch im Play Store auftauchen. Ok, super. Diesen Schritt halte ich für durchaus wichtig. Gründe hierfür habe ich bereits oben genannt. Sofern du du das Ganze zukünftig doch unter einer FOSS Lizenz veröffentlichst, denke der Vollständigkeit halber bitte auch an F-Droid [1] ;). Mit freundlichen Grüßen, Karol Babioch [1]: https://f-droid.org/
Die Einteilung in Adresse und Daten (je 16 bit) beim ipclient macht Sinn. Aber wie Teilt man z.B. die 16 Bit von JVC/NEC16-Befehlen auf diese 32 bit auf? Leider fehlt zum zu fraglichen Gerät (JVC SEA-M770) eine Fernbedienung und handelsübliche vorprogrammierte All-in-one brachten auch keine Reaktion. Deshalb wollte ich einfach mal die komplette palette an 16bit-Befehlen über Ostern auf den IR-empfänger des Geräts Ballern in der Hoffnung, Da bewegt sich was. Aber wie bilde ich die 16 bit (0000-ffff) in "ipclient <IP> <port> AAAA DDDD F" ab? Gruß Andy
Andy P. schrieb: > Die Einteilung in Adresse und Daten (je 16 bit) beim ipclient macht > Sinn. Aber wie Teilt man z.B. die 16 Bit von JVC/NEC16-Befehlen auf > diese 32 bit auf? Sämtliche unterstützten Protokolle sind im IRMP-Artikel beschrieben. Hier zum Beispiel das NEC16/JVC-Protokoll: http://www.mikrocontroller.net/articles/IRMP#NEC16 Oder auch: http://www.sbprojects.com/knowledge/ir/jvc.php Das heißt, es werden 8 Bit für die Adresse und 8 bit für das Kommando verwendet. Du müsstest also die Adresse von 0x00 bis 0xff und für jede dieser Adressen die Kommandos 0x00 bis 0xff durchprobieren. > Leider fehlt zum zu fraglichen Gerät (JVC SEA-M770) eine Fernbedienung > und handelsübliche vorprogrammierte All-in-one brachten auch keine > Reaktion. Deshalb wollte ich einfach mal die komplette palette an > 16bit-Befehlen über Ostern auf den IR-empfänger des Geräts Ballern in > der Hoffnung, Da bewegt sich was. > Aber wie bilde ich die 16 bit (0000-ffff) in "ipclient <IP> <port> AAAA > DDDD F" ab? Siehe oben: ipclient <IP> <port> pp aa cc 0 Wobei pp = 27 ist und aa und cc jeweils von 00 bis FF laufen. Vergiss bitte nicht, IRSND_SUPPORT_NEC16_PROTOCOL auf 1 zu setzen. Standardmäßig sind nur die gebräuchlichsten Protokolle freigeschaltet. NEC16 gehört nicht dazu. Was macht Dich so sicher, dass Dein Gerät genau dieses Protokoll verwendet?
:
Bearbeitet durch Moderator
Frank M. schrieb: > Sämtliche unterstützten Protokolle sind im IRMP-Artikel beschrieben. Das habe ich schon vor einiger Zeit gelesen (Sehr gut erklärt). > Du müsstest also die Adresse von 0x00 bis 0xff und für jede dieser > Adressen die Kommandos 0x00 bis 0xff durchprobieren. > Siehe oben: ipclient <IP> <port> pp aa cc 0 > Wobei pp = 27 ist und aa und cc jeweils von 00 bis FF laufen. Ah, das war der Punkt, an dem ich nicht weiterkam: IPclient->irsnd-Parameterübergabe. Danke. > Vergiss bitte nicht, IRSND_SUPPORT_NEC16_PROTOCOL auf 1 zu setzen. > Standardmäßig sind nur die gebräuchlichsten Protokolle freigeschaltet. > NEC16 gehört nicht dazu. Danke für den Hinweis, ist geschehen. > Was macht Dich so sicher, dass Dein Gerät genau dieses Protokoll > verwendet? nichts, aber ein JVC-Gerät aus Mitte der 80er Jahre wird wohl eher kein Kaseiko sprechen ;). Ich bin mir noch nicht mal sicher, ob es überhaupt ein mit heutiger Standardtechnik (36-38KHz) abbildbarer Code ist. Ich teste es einfach mal durch. Wenn's nicht klappt, ist das auch nicht tragisch: erstens lässt es sich problemlos vollständig per Frontplatte bedienen und das ist selten notwendig, zweitens sind da auch mehrere große One4All und andere derartige dran gescheitert, die alle behaupteten, sie können jedes Gerät steuern.
Andy P. schrieb: > zweitens sind da auch mehrere > große One4All und andere derartige dran gescheitert, die alle > behaupteten, sie können jedes Gerät steuern. Und du bist dir sicher, dass auf Empfangsseite noch alles in Ordnung ist? Meiner Erfahrung nach funktionieren die Basisfunktionen (An/Aus, etc.) der Universalfernbedienungen ganz gut und zuverlässig. Im Autosuch-Modus machen die Dinger ja auch nichts anderes als alle (eingespeicherten) Kombinationen durchzugehen. Würde mich wirklich wundern, wenn mehrere solcher Fernbedienung dein Gerät nicht ausgeschaltet bekommen. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Würde mich wirklich > wundern, wenn mehrere solcher Fernbedienung dein Gerät nicht > ausgeschaltet bekommen. Da denke ich doch gleich wieder an Zabex' Lösung: http://www.zabex.de/site/tvaus.html :-)
Andy P. schrieb: > nichts, aber ein JVC-Gerät aus Mitte der 80er Jahre wird wohl eher kein > Kaseiko sprechen ;). Stimmt auch wieder. Wenn es mit dem NEC16-Protokoll nicht klappt, könntest Du noch das Standard-NEC-Protokoll ausprobieren. Das hört sich erstmal mit 16 Bit-Adresse und 16 Bit Daten nach einer Menge Möglichkeiten an, aber das ist nur mit dem Extended-NEC-Protokoll so. Im Standard-NEC-Protokoll ist es auch nur eine 8-Bit-Adresse und ein 8-Bit-Code - wie beim NEC16-Protokoll. Da aber IRMP und IRSND das Extended-NEC-Protokoll "sprechen", musst Du selber dafür sorgen, dass es Standard-NEC wird: Beim Standard-NEC ist jeweils das 2. Byte invertiert - als Sicherung gegen Fehlübertragungen. Das heisst, Du benutzt jeweils 16 Bit Daten für Adresse und Kommando, aber invertierst das obere Byte. Beispiel: 1. Adresse: p = 2 a = FF00 c = FF00 p = 2 a = FF00 c = FE01 p = 2 a = FF00 c = FD02 ... p = 2 a = FF00 c = 00FF 2. Adresse: p = 2 a = FE01 c = FF00 p = 2 a = FE01 c = FE01 p = 2 a = FE01 c = FD02 ... p = 2 a = FE01 c = 00FF usw. Das heisst, es sind genauso viele Möglichkeiten wie beim NEC16-Protokoll, Du musst nur das höherwertige Byte invertieren und die Möglichkeiten von 00 bis FF durchspielen. Viel Glück!
Hallo Frank, sieht gut aus. Mit was proggst Du für Android? LG Rudi ;-)
R. W. schrieb: > Mit was proggst Du für Android? Die APK lässt darauf schließen, dass das alles - wie für Android üblich - in Java programmiert ist. Was die Veröffentlichung von Quellcode angeht, so hat Frank bereits etwas zu gesagt: Frank M. schrieb: > Die Quellen der Android-App sind momentan nicht öffentlich zugänglich. > Ich werde aber noch darüber nachdenken, ob ich sie veröffentlichen > werde. Dank des dokumentierten Protokolls ist es jedoch eine > Kleinigkeit, einen komplett anderen Client anzubinden. Die Code-Passagen > für die UDP-Kommunikation (in Java) sind minimal. Diese kann ich gern > noch kurzfristig in die Dokumentation - sprich Artikel - aufnehmen. Mit geeigneten Werkzeugen (z.B. dex2jar) lässt sich das Ganze - gerade aufgrund der noch überschaubaren Funktionalität - relativ gut auseinander nehmen ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > R. W. schrieb: >> Mit was proggst Du für Android? > > Die APK lässt darauf schließen, dass das alles - wie für Android üblich > - in Java programmiert ist. Hi Karol, ty, sorry - ich hab nicht richtig nachgefragt, ich meinte eigentlich ob er Eclipse, RTE3, DelphiDroid, Basic4Android oder ganz was anderes verwendet... ... das nehm ich meistens her..für Libs, Grafik, Pascal Routinen und schnelle Vorzeige APP.. > > Was die Veröffentlichung von Quellcode angeht, so hat Frank bereits > etwas zu gesagt: > > Frank M. schrieb: >> Die Quellen der Android-App sind momentan nicht öffentlich zugänglich. >> Ich werde aber noch darüber nachdenken, ob ich sie veröffentlichen >> werde. Dank des dokumentierten Protokolls ist es jedoch eine >> Kleinigkeit, einen komplett anderen Client anzubinden. Die Code-Passagen >> für die UDP-Kommunikation (in Java) sind minimal. Diese kann ich gern >> noch kurzfristig in die Dokumentation - sprich Artikel - aufnehmen. ... is klar.. ... socket halt aber ich meinte halt welche IDE... ;-) achso.. das war ja franks zitat .. egal.. ;-)... > > Mit geeigneten Werkzeugen (z.B. dex2jar) lässt sich das Ganze - gerade > aufgrund der noch überschaubaren Funktionalität - relativ gut > auseinander nehmen ;). Da gibt es ApkTools die das noch einfacher handlen... ;-) ...und AES Tools .. die das verhindern... ;-) ... > > Mit freundlichen Grüßen, > Karol Babioch Lieben Gruss Danke für Deine Zeit und Hilfestellung.. meinte welche IDE.. Rudi ;-)
R. W. schrieb: > Danke für Deine Zeit und Hilfestellung.. meinte welche IDE.. Es ist Eclipse. Da der App-Source auch kein großes Geheimnis ist, werde ich ihn irgendwann diese Woche zum Download bereitstellen. Gruß, Frank
Ich habe die Sources der App nun hochgeladen, sie liegen unter: http://www.mikrocontroller.net/articles/Remote_IRMP#Downloads Viele Grüße, Frank
Frank M. schrieb: > Ich habe die Sources der App nun hochgeladen, sie liegen unter: Vielen Dank schon einmal hierfür. Werde ich mir bei Gelegenheit mal genauer ansehen. Irgendeinen Grund warum du nur die *.java Dateien selbst hochgeladen hast, und nicht etwa das ganze Eclipse Projekt (inkl. Layouts, usw.)? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Vielen Dank schon einmal hierfür. Werde ich mir bei Gelegenheit mal > genauer ansehen. Irgendeinen Grund warum du nur die *.java Dateien > selbst hochgeladen hast, und nicht etwa das ganze Eclipse Projekt (inkl. > Layouts, usw.)? Was da alles an Zeugs in so einem Eclipse-Projekt rumfleucht, wollte ich Euch jetzt nicht antun. Meinetwegen kann ich aber auch den ganzen Baum einpacken. Layouts verwendet diese App nicht. Die graphischen Objekte/Dialoge werden per Code generiert. Daher müsste es eigentlich reichen, in Eclipse ein neues Projekt aufzumachen und die *.java unter src/.../ reinzukippen.
Frank M. schrieb: > Layouts verwendet diese App nicht. Die graphischen Objekte/Dialoge > werden per Code generiert. Daher müsste es eigentlich reichen, in > Eclipse ein neues Projekt aufzumachen und die *.java unter src/.../ > reinzukippen. Ok, habe das um ehrlich zu sein nur überflogen und war etwas über die flache Struktur verwundert. Danke jedenfalls für deine Mühen, das ist keineswegs selbstverständlich! Mit freundlichen Grüßen, Karol Babioch
Hallo Frank, tolles Projekt. Nachdem ich bereits IRMP nach Ethersex portiert habe wollte ich mir nun auch noch Remote IRMP vornehmen, um das ganze abzurunden. Die APP RemoteButtler habe ich auf einem Android 4.2.1 installiert und einen Server konfiguriert. Beim Drücken eine Taste erscheint für kurze Zeit "Socket exception!" über den Tasten. Was mache ich falsch?
Hi eku, E. K. schrieb: > Die APP RemoteButtler habe ich auf einem Android 4.2.1 installiert und > einen Server konfiguriert. Beim Drücken eine Taste erscheint für > kurze Zeit "Socket exception!" über den Tasten. Du hast eine bestehende WLAN-Verbindung und hast Netzwerkverbindungen für die App zugelassen? Hast Du mal die Test-Server-Funktion ausprobiert? Ich bekomme dieselbe Meldung, wenn ich keine Netzwerkverbindung (WLAN) habe.
:
Bearbeitet durch Moderator
Hallo Frank, ich warte sehnsüchtig auf ein Update Deiner Android App, die die Codes in Hex anzeigt und auch entgegennimmt.
Hi, auch ich möchte Dich zu dem tollen Projekt gratulieren. Ich hatte vor kurzem auch die Idee, bei mir SamrtHome einzurichten und war überrascht, was es im Internet alles so gibt. Super! Ich habe alles erledigt, wie in Deiner Anleitung beschrieben - und nach nur ein Paar Tagen (ich kann nur Abends was machen) kann ich bereits über mein Handy den Fernseher und Sat-Receiver steuern. Unglaublich :-) Nun plane ich, deine Quellcodes weiter auszubauen. Bei interesse kann ich mein Projekt, dass wahrscheinlich einige Jährchen in Anspruch nehmen wird, näher erklären. Dazu hätte ich eine kleine Bitte an Dich. Mit Atmel Studio kenne ich mich soweit aus. Aber das Android App schreiben ist komplett neu für mich (aber etwas Erfahrung mit Java habe ich schon). Ich habe zwar geschafft, deinen Java-Code zu kompilieren (übrigens sowohl mit Android Studio als auch Eclipse), aber die App läuft nicht richtig: Sie hat einen weißen Rahmen, kein Menü, die xml-Dateien im Ordner RemoteButler werden nicht gelesen und das Netwerk funktioniert auch nicht. Du hast zwar geschrieben, die layout-XML-Dateien und Co. braucht man nicht, aber ich glaube es liegt doch an denen. Z. B. wurde bei mir die Variable R.id.viewpager nicht erkannt, bis ich entsprechde Zeilen in die mainactivity.xml reingeschrieben habe. Wäre es deshlab möglich, dass Du doch den ganzen Projektordner öffentlich machst oder zumindest mir zur Verfügung stellst. Ich danke Dir. Viele Grüße, Grigorij G.
Hallo Grigorij, Grigorij G. schrieb: > Wäre es deshlab möglich, dass Du > doch den ganzen Projektordner öffentlich machst oder zumindest mir zur > Verfügung stellst. Schicke mir bitte eine PN, dann sende ich Dir das komplette Projekt. Viele Grüße, Frank
Da in meiner Bastelkiste weder einen Arduino noch ein Ethernet-Modul zu finden war, habe ich als Ersatz einen PC bzw. Raspberry in Verbindung mit Python (3.x) genutzt. Python stellt den UDP-Server, mit dem die App 'RemoteButler.apk' kommuniziert. Der Server reicht die empfangenen Daten via serieller Schnittstelle an einen ATMega8 mit der 'normalen' IRMP-Software weiter und liefert eine Quittung an den Server zurück. Vom Server wird die Quittung an die App weitergereicht, so dass dort eine Meldung erscheint, wenn das angeforderte Sendeprotokoll nicht verfügbar ist. Ein Ping von der App wird vom Server erkannt und beantwortet. Weiterhin lassen sich IR-Fernbedienungen genauso anlernen wie bei IRMP-Remote: Den Button 'Anlernen' betätigen und dann eine Taste auf der Fernbedienung drücken ... Eine Vorgabe im Protokoll muss berücksichtigt werden: Bei jeder seriellen Übertragung (zwischen Server und Microcontroller) wird ein Startbyte '0x7E' vorangestellt. Außerdem wird jede Sendeanforderung vom Microcontoller quittiert: Die Quittung beginnt mit dem Startbyte '0xE7', es folgt genau ein weiteres Byte. Ist dieses '255', dann wurde das Sendeprotokoll erkannt. Jeder andere Wert gibt die Protokollnummer eines nicht verfügbaren Protokolls zurück. An die App wird als Quittung nur "S+" oder "S-" zurückgegeben. In der beigefügten 'irmp_main.c' und 'rs232.c' kann nachgeschaut werden, welche Definitionen eingebaut sind. Das Programm läuft sowohl auf dem PC als auch auf dem Raspberry. Auf dem Smartphone habe ich den RemoteButler V.1.0 benutzt. Die Version 1.1 wollte nicht installiert werden, vermutlich wird Android 2.3 nicht mehr unterstützt. Mit etwas Fantasie kann man die App aus dem "RemoteIrmp-Projekt" für allerlei andere nützliche Spielchen einsetzen, einen schönen Dank daher an den Autor - auch für das IRMP-Projekt. mfg Michael S.
Michael S. schrieb: > Da in meiner Bastelkiste weder einen Arduino noch ein Ethernet-Modul zu > finden war, habe ich als Ersatz einen PC bzw. Raspberry in Verbindung > mit Python (3.x) genutzt. Sehr schön! Dieser Port sollte auf jeden Fall mit in den Artikel. > Auf dem Smartphone habe ich den RemoteButler V.1.0 benutzt. > Die Version 1.1 wollte nicht installiert werden, vermutlich wird Android > 2.3 nicht mehr unterstützt. Hm, das sollte ich wohl in Ordnung bringen. Wenn ich mich richtig erinnere, habe ich dort das Übertragungsprotokoll minimal geändert. Wäre dumm, wenn das jetzt nicht mehr 1:1 kompatibel wäre. Gruß, Frank
Frank M. schrieb: > Hm, das sollte ich wohl in Ordnung bringen. Wenn ich mich richtig > erinnere, habe ich dort das Übertragungsprotokoll minimal geändert. Wäre > dumm, wenn das jetzt nicht mehr 1:1 kompatibel wäre. Die Installation der App wurde sofort abgebrochen, das Protokoll selbst wird wohl nicht die Ursache sein. Auf einem anderen Smartphone mit aktuellem Android konnte die Version 1.1 installiert werden. mfg Michael S.
Hallo miteinander, bevor ich selbst Hand anlege frage ich besser: Gibt es schon eine Android App oder Bibliothek, die per IRSND über eine in der Audiobuchse steckende IR-Diode IR-Codes sendet? Wie aufwändig wäre es, IRSND WAV generieren zu lassen? Grüße,
E. K. schrieb: > bevor ich selbst Hand anlege frage ich besser: Gibt es schon eine > Android App oder Bibliothek, die per IRSND über eine in der Audiobuchse > steckende IR-Diode IR-Codes sendet? Nicht, dass ich wüsste. Es gibt nur eine App, die IR-Codes über eine eingebaute IR-Diode senden kann. > Wie aufwändig wäre es, IRSND WAV generieren zu lassen? Für Android? Keine Ahnung, habe ich mich noch nicht mit beschäftigt. Aber eine sehr nette Idee :-)
Frank M. schrieb: > E. K. schrieb: >> bevor ich selbst Hand anlege frage ich besser: Gibt es schon eine >> Android App oder Bibliothek, die per IRSND über eine in der Audiobuchse >> steckende IR-Diode IR-Codes sendet? > > Nicht, dass ich wüsste. Es gibt nur eine App, die IR-Codes über eine > eingebaute IR-Diode senden kann. Ist an mir vorbei gegangen. Wo gibt's die denn? >> Wie aufwändig wäre es, IRSND WAV generieren zu lassen? > > Für Android? Keine Ahnung, habe ich mich noch nicht mit beschäftigt. > Aber eine sehr nette Idee :-) http://www.aliexpress.com/store/product/2016-Hot-Sale-Universal-IR-Infrared-Remote-Control-TV-STB-DVD-for-Smartphone-Samsung-HTC-LG/1187163_32620041076.html Den Quellcode von IRSND von C nach Java zu wandeln stellt kein Problem dar - führt aber nicht direkt zum Ziel. https://developer.android.com/reference/android/media/AudioTrack.html Das IR-Signal in 36kHz modulieren - gibt's dafür schon eine Bibliothek? Kann das IRSND irgendwie?
E. K. schrieb: > Ist an mir vorbei gegangen. Wo gibt's die denn? Hier erklärt: Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" Hier ein Update: Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" Und hier die letzte Version: Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" mit Copy&Paste-Funktionalität. Die Software ist die RemoteButler-App erweitert um das Senden über eine eingebaut IR-LED. Getestet mit Samsung Galaxy S4. Ja, ich weiß, ich müsste mal den Remote-IRMP-Artikel erweitern.... ;-) > http://www.aliexpress.com/store/product/2016-Hot-Sale-Universal-IR-Infrared-Remote-Control-TV-STB-DVD-for-Smartphone-Samsung-HTC-LG/1187163_32620041076.html Witzig. > Den Quellcode von IRSND von C nach Java zu wandeln stellt kein Problem > dar - führt aber nicht direkt zum Ziel. Der ist schon portiert, siehe oben :-) > https://developer.android.com/reference/android/media/AudioTrack.html > > Das IR-Signal in 36kHz modulieren - gibt's dafür schon eine Bibliothek? Nein. > Kann das IRSND irgendwie? IRSND verwendet dafür HW-PWM. Und bei Android kann man die Modulation auch per Software einstellen. Das macht das Android-Gerät dann selbst.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Und hier die letzte Version: > > Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" > > mit Copy&Paste-Funktionalität. > > Die Software ist die RemoteButler-App erweitert um das Senden über eine > eingebaut IR-LED. Getestet mit Samsung Galaxy S4. > > Ja, ich weiß, ich müsste mal den Remote-IRMP-Artikel erweitern.... ;-) Vor allem interessiere ich mich für den aktuellen Quellcode. Gerne auch per PM.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.