Forum: Projekte & Code Remote IRMP - IR übers Netzwerk


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Karol B. (johnpatcher)


Lesenswert?

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
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Karol B. (johnpatcher)


Lesenswert?

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/

von Andy P. (bakaroo)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Andy P. (bakaroo)


Lesenswert?

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.

von Karol B. (johnpatcher)


Lesenswert?

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

von Konrad S. (maybee)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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!

von R. W. (Gast)


Lesenswert?

Hallo Frank,

sieht gut aus.

Mit was proggst Du für Android?

LG
Rudi
;-)

von Karol B. (johnpatcher)


Lesenswert?

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

von R. W. (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ich habe die Sources der App nun hochgeladen, sie liegen unter:

  http://www.mikrocontroller.net/articles/Remote_IRMP#Downloads

Viele Grüße,

Frank

von Karol B. (johnpatcher)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Karol B. (johnpatcher)


Lesenswert?

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

von E. K. (eku)


Lesenswert?

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?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von E. K. (eku)


Lesenswert?

Hallo Frank,

ich warte sehnsüchtig auf ein Update Deiner Android App, die die Codes 
in Hex anzeigt und auch entgegennimmt.

von Grigorij G. (Gast)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Michael S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Michael S. (Gast)


Lesenswert?

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.

von E. K. (eku)


Lesenswert?

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,

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von E. K. (eku)


Lesenswert?

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?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von E. K. (eku)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

E. K. schrieb:
> Vor allem interessiere ich mich für den aktuellen Quellcode.

Du hast Post :-)

von Tom K. (xpac)


Lesenswert?

Hallo Frank,

Ich nutze deine RemoteButler app zum fernsteuern meines Homeservers.

funzt wunderbar ;)

Jetzt wollte ich doch ein paar Funktionen hinzufügen.

Ob es wohl möglich ist mir deinen letzten Stand des Anroid Projectes
mal zuzumailen.
(werde es nicht weitergeben)

besten Dank

mfg Thomas

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Tom,

Tom K. schrieb:
> Ob es wohl möglich ist mir deinen letzten Stand des Anroid Projectes
> mal zuzumailen.

Ich habe den Source seit damals nicht mehr geändert. Du findest den 
Source hier: 
https://www.mikrocontroller.net/articles/Remote_IRMP#Downloads

Die Version 1.0 ist von mir, die Version 1.1 ist von User Rafael.

Ich nehme mal an, dass zumindest meine Original-Version an heutige 
Android-IDEs angepasst werden müsste.

: Bearbeitet durch Moderator
Bitte 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
Noch kein Account? Hier anmelden.