Ankündigung

**makki** · 29.11.2011, 21:04

Ich muss vorwegschicken, ich hab nur ein serielles irtrans (Sparfuchs) und das aus der "pre-WG" Zeit ganz wild mit Shell-Skripten, lirc&Co eingewurschtelt.
Heisst: es geht zwar aber sicherlich das brauch ich keinem erklären wie

Das LAN kenne ich daher nur theoretisch..

Nun die guten Nachrichten: Es gibt bereits seit mitte 2009 Pakete für den irserver/irclient fürs WG ->also bitte keinesfalls der Installationsanleitung für Linux im IRtrans-Handbuch folgen (ich vermute aber stark, den brauchen wir beim LAN-Modell mit IRDB garnicht!).

Irgendwie hats aber bisher noch keinen interessiert und es gibt mehrere Möglichkeiten, damit ins Ziel zu kommen. u.a. xAP(xPL) aber auch dafür gabs bisher kein Interesse.

Also, wenn ich das so auf die schnelle richtig lese, richtet man im IRT ein:

Die UDP Broadcastfelder werden nur bei Modulen mit IR Datenbank genutzt. Sie geben an,
zu welchem Host/Port formatierte Empfangsdaten geschickt werden. Das Format dieser ..

Dann noch ein Plugin das auf diese UDP-Broadcasts horcht und fertig ist die Laube. Bei dem Plugin kann ich assistieren aber es nicht testen; mal so als "Start" (abgeleitet von dem DMX-Plugin, das auch Broadcasts verwendet)

Code:

# Plugin UDP-Broadcasts (IRtrans)
# Version: 0.0 2011-11-29

##################
### DEFINITION ###
##################

my $socknum = 106;                # Eindeutige Nummer des Sockets +1

# Eigenen Aufruf-Zyklus setzen (Initialisierung/zyklisches prüfen)
$plugin_info{$plugname.'_cycle'} = 300;

my $send_ip = "192.168.2.91"; # IP IRTrans 
my $send_port = "21000"; # Port IRtrans
my $recv_ip = "255.255.255.255"; # Broadcast-IP Empfang
my $recv_port = "6600"; # Empfangsport 

#######################
### ENDE DEFINITION ###
#######################

# Hauptverarbeitung
if (!$socket[$socknum]) { # socket erstellen
    if (defined $socket[$socknum]) { #debug
        if ($socket[$socknum]->opened) { $socket[$socknum]->close(); }
        undef $socket[$socknum];
    }  #debug
    $socksel->remove($socket[$socknum]);
    $socket[$socknum] = IO::Socket::INET->new(LocalPort => $recv_port,
                              Proto => "udp",
                              LocalAddr => $recv_ip,
                              PeerPort  => $send_port,
                              PeerAddr  => $send_ip,
                              ReuseAddr => 1
                               )
	     or return ("open of $recv_ip : $recv_port failed: $!");
    $socksel->add($socket[$socknum]); # add socket to select
    $plugin_socket_subscribe{$socket[$socknum]} = $plugname; # subscribe plugin
    return "opened UDP-Socket $socknum";
} 

if ($fh) {
    my $buf;
    recv($fh,$buf,255,0);
    my $bufhex = $buf;
    $bufhex =~ s/(.)/sprintf("0x%x ",ord($1))/eg;
    return "received: $buf, HEX: $bufhex";
}

return "cycle";

So oder so ähnlich, wenn da etwas im Plugin-Log ankommt wäre das schon die halbe Miete

Makki

P.S.: Ich wär froh wenn wir so eine BDA hätte

**Patholog** · 01.12.2011, 00:17

Hallo Makki,

habe intensiv getestet und dank deiner Hilfe mit dem Plugin bin ich auch schon sehr weit gekommen. Nach Druck auf die Fernbedienung (ok-Knopf) erscheint folgendes Plugin-Protokoll:

2011-11-30 22:08:07.605,Irtrans,received: kathrein-ufs,ok , HEX: 0x6b 0x61 0x74 0x68 0x72 0x65 0x69 0x6e 0x2d 0x75 0x66 0x73 0x2c 0x6f 0x6b 0xd ,0s
Es geht also prinzipiell schon mal!

Aber: die notwendigen UDP- und Port-Einstellungen im IRTrans gehen gleich wieder verloren (trotz flashen auf die Datenbank), wenn man beim GUI Client mal einen anderen Reiter anklickt. Habe im IRTrans-Supportforum mal eine Anfrage plaziert. Halte dich und dieses Forum auf dem Laufenden. Oder hast du inzwischen eine geniale Idee?

Gruß
Harald

**makki** · 01.12.2011, 00:30

Ja (sehr gut, genau so sollte es laufen!) und nein: ich habe wiegesagt kein IRT-LAN zur Hand (sollte sich aber mit einem seriellen+irserver auch simulieren lassen)
Das "kathrein-ufs" und "ok" zu parsen ist nur noch eine Fleissaufgabe fürn halbschlaf

(das Hex habe ich da nur dringelassen, falls gülle kommt..pures ASCII, ganz einfach)

Irgendwo vor dem wechseln des Reiters speichern drücken? Mehr sachdienliche Hinweis hab ich dazu jetzt erstmal nicht..

Aber ein gewisses Interesse daran, das es (sicher! irgendwie..) funktioniert, wenn ich mir die grottige Anleitung fürn HS ansehe, hey, echt, das geht schon auch besser und einfacher + anwenderfreundlicher.. Ein bisschen Code hin oder her

Makki

**Patholog** · 07.12.2011, 19:56

Hallo Makki,

sorry, dass ich mich nicht schon eher gemeldet habe. Viel Arbeit eben.

Dein irtrans-Empfangs-Plugin geht schon sehr gut. Manchmal werden bei mir einfach keine IR-Befehle in irtrans empfangen, da bin ich aber mit dem irtrans-Support drüber.

der Experimentiertrieb hat mich nun zu einem weiteren Phänomen gebracht, der Fehler dürfte im Plugin liegen (oder doch im irtrans?).

Wenn ich eine Taste auf der eingelernten Fernbedienung drücke, dann zeigt die Status-LED des irtrans den korrekten Empfang an, das Plugin scheint aber nicht zu starten. Drücke ich nach ca. 1 Sekunde die gleiche Taste noch einmal, dann quittiert das irtrans wieder den korrekten Empfang, jetzt startet auch das Plugin. Das ist reproduzierbar. Ich habe das dokumentiert, indem ich einen knx_write-Befehl ins Plugin implementiert habe und das Logfile studiert habe: bei zwei Tastendrucken auf der Fernbedienung löst das Plugin regelmäßig nur beim zweiten Mal eine Aktion aus:

2011-12-07 19:44:32.192,A_GroupValue_Write,1.1.254,10/0/18,01,,,,0,low,7,T_DATA_XXX_REQ,0
2011-12-07 19:44:52.242,A_GroupValue_Write,1.1.254,10/0/18,01,,,,0,low,7,T_DATA_XXX_REQ,0

Ich habe um 19:44:30 das erste mal gedrückt, kurz darauf ein zweites Mal. Gleiches Vorgehen um 19:44:50. Die GA wird aber nur jeweils einmal abgesetzt (nur das zweite Mal).

Ursache? Lösung? Kann ich noch was testen, um diesem Fehler auf die Spur zu kommen?

Danke!

Harald

**swiss** · 07.12.2011, 20:14

Hmm.. Geschieht nix, wenn du eine Taste drückst und mal länger als eine Sekunde wartest? Vieleicht klemmt bei dir ein andere Plugin? Die werden der Reihe nach abgearbeitet und wenn eines davon noch in der Ausführung ist, wird die Verarbeitung deiner IR Befehlen eben zurückgestellt.

**makki** · 07.12.2011, 21:45

Habs grad nochmal durchgeschaut, so falsch sollte das nicht sein; (das Plugin kann zwar verzögert reagieren wenn grad was anderes ansteht aber verpassen kanns eigentlich nichts..)

eventuelle Ursache: die Angabe des Absenders (Port/IP), solange wir aus diesem Plugin nichts ans IRT senden wollen auch sekundär, kommentiere doch mal die beiden zeile mit # aus

Code:

#                              PeerPort  => $send_port,
#                              PeerAddr  => $send_ip,

Eine finale Antwort, obs nicht sendet oder das Plugin taub ist liefert ein Wireshark (Hub! dazwischen oder Mirror-Port) bzw. ein
tcpdump -s 0 -vv -AX "port 6600"
auf der ssh-Konsole.
Davon ggfs. die exakte Ausgabe, was noch möglich wäre ist das es wegen dem CR/LF knatscht, ich hab hier (simuliert!) nen 0X0A in dem Posting oben ists ein 0X0d

Makki

**Patholog** · 12.12.2011, 21:41

Toggle-Bit ursächlich für Kommunikationsstörung

So, jetzt ist das Problem lokalisiert und gelöst:

meine Kathrein-Fernbedienung sendet beim Infrarot-Code ein Toggle-Bit mit. Das heißt, pro Taste gibt es 2 Codes, die sich an einer einzigen Stelle unterscheiden und abwechselnd gesendet werden. Ich habe beim Einlernen des irtrans die Taste natürlich nur einmal gedrückt, so wurde nur ein Code gespeichert. Das irtrans hat nur jedes zweite Mal den Befehl auf das Ethernet geschickt, das Plugin konnte nur jedes zweite Mal reagieren.

Im irtrans gibt es mehrere Möglichkeiten, dieses Toggle-Bit auszublenden. Ich halte sie aber für gefährlich, weil dann möglicherweise andere Fernbedienungen nicht mehr korrekt gehandelt werden. Deshalb habe ich zunächst jede Taste der Fernbedienung zweimal angelernt (z.B. als stop u. als stopx). Beim wiederholten Drücken z. B. der Stop-Taste wird jetzt ein stop und stopx abwechselnd auf das Ethernet gelegt. Im Plugin kann man beide Befehle durch eine or - Logik auffangen, dann läuft alles zuverlässig. Das Plugin von Makki ist also perfekt!

Über eine http.....-Anweisung kann ich das irtrans auch umgekehrt über ein plugin steuern. Hier jetzt noch eine Frage: irtrans empfiehlt das UDP-, nicht das http-Protokoll, weil es deutlich schneller verarbeitet werden kann. Der Empfang der irtrans-Befehle über UDP durch ein Plugin (siehe oben) funktioniert schon klasse, wie aber geht es mit UDP umgekehrt?

In der Bedienungsanleitung steht nur folgende Syntax für UDP:

snd<remote>,<command>

oder

sndccf<ccf hexstring> CCF Hexstring als ASCII-String.

Benutzt wird der UDP-Port 21000.

Gruß

Harald

**makki** · 12.12.2011, 22:31

Jaja, das Toggle-Bit, da hat uns alle schonmal in den Wahnsinn getrieben (seis mit irtrans, lirc, X10-Funkfernbedienung..)

Muss grad noch 50 threads aufholen, aber senden->IRTrans ist natürlich auch möglich und sogar schon halb im Plugin vorgesehen:
Das war das oben auskommentierte mit send_ip/port.
Kann man sich im Prinzip bei den Plugins CUL/CUN oder DMX abgucken, wenn mal mehr Zeit ist: sind nur 10 Zeilen mehr..

Makki

**Patholog** · 13.12.2011, 22:49

Hoffentlich ist bald mehr Zeit. Mit dem Abgucken wird das bei mir leider nichts. Außerdem hätten wir dann in diesem Thread die gesamte irtrans-Kommunikation abgehandelt. Ich habe natürlich größtes Verständnis, wenn du dafür Zeit brauchst!

Harald

**makki** · 13.12.2011, 23:10

Naja, das ist nicht mehr als eine Fingerübung, ein elsif ($msg.. ein syswrite und ein plugin_subscribe

-> Das aufwändigere ist das Design, also was es am Ende des Tages tun soll?

GA->spezifische remote/command mit 0/1; statisch, GA-Wert, z.B. 0-255 a la Szenenabruf -> unterschiedliche remotes/commands, ganz anders (absolute Werte, Lautstärke, ... von bestimmten GA's)

Alles zusammen sinds dann schon 4 Fingerübungen

Makki

P.S.: Klar ist das einarbeiten nicht unbedingt leicht aber am Ende des Tages glaube ich wenns mal klick gemacht hat, bringt einem die Schnitzeljagd&Erkenntnis mehr, als ein fertiges "Schnipsel" das man nur kopiert. Das Thema Heimautomatisierung ist leider immernoch sehr individuell und teils komplex, umso mehr man weiss, umso einfacher wirds

**Patholog** · 14.12.2011, 23:54

Das aufwändigere ist das Design, also was es am Ende des Tages tun soll?

Das gleiche, was ich schon mit
http://<Ip-Adresse Irtrans>/send.htm?remote=<remote>&command=<command>
gelöst habe. Irtrans empfiehlt aber das UDP-Protokoll.

Noch einmal konkret: mit Hilfe eines Plugins bringe ich das Irtrans dazu, einen Infrarot-Code zu senden und damit z.B. eine Multimedia-Komponente zu steuern.

bringt einem die Schnitzeljagd&Erkenntnis mehr, als ein fertiges "Schnipsel" das man nur kopiert.

Kann ich prinzipiell nur zustimmen. Ich glaube nur, dass ich bei meinem Kenntnisstand bei dieser Schnitzeljagd vollkommen untergehe, kenne ich ja noch nicht einmal die Spielregeln! Aber ich will's tapfer versuchen!

Das ist doch der Befehl zum Empfangen von UDP-Daten, oder?
recv($fh,$buf,255,0);
Also suche ich jetzt das Gegenstück. Passt Folgendes??
print $fh $data; $fh steht für den Socket, $data für den Irtrans-Befehl?

Danke!
Harald

**makki** · 15.12.2011, 00:48

Ok versuchen wir es mal weiter pädagogisch wertvoll (eigentlich wollte ich ja wissen was es genau&wie beim Empfang einer GA tun soll!)

z.B. hier
schreibt man einen simplen ASCII-String mit

Code:

$socket[$socknum]->send($MEINTEXT) or return "send failed: $!";

$MEINTEXT ist zu ersetzen, eine lokale Variable oder simpel als Text
"snd<remote>,<command>"

Makki

P.S. print $fh .. wäre so falsch auch garnicht, $fh existiert aber leider nur, wenn das Plugin durch ein eintreffendes UDP-Telegramm aufgerufen wurde.. Das wollen wir hier ja nicht beim Versand..

**Patholog** · 15.12.2011, 20:51

Hallo Makki,

danke, ich habe gleich wieder was gelernt, deine pädagogischen Versuche bringen also was!. Das $fh ist also notwendig für das Empfangen der UDP-Daten, nicht für das Senden. Deinen Vorschlag mit $MEINTEXT werde ich gleich mal ausprobieren.

eigentlich wollte ich ja wissen was es genau&wie beim Empfang einer GA tun soll!

Und Frust: ich dachte, ich hätte verständlich gemacht, was es genau tun soll bzw. können soll:

Noch einmal konkret: mit Hilfe eines Plugins bringe ich das Irtrans dazu, einen Infrarot-Code zu senden und damit z.B. eine Multimedia-Komponente zu steuern.

Also noch ein Versuch: eine GA schmeißt ein Plugin an. Nach Verarbeitung von irgendwelchen Logiken (welche tut eigentlich nichts zur Sache, weil ich das Problem prinzipiell lösen will) sendet das Plugin via UDP über Ethernet einen Befehl (z.B. Receiver einschalten) an das IRtrans. Das IRtrans verarbeitet diesen Befehl und sendet ein Infrarot-Signal: hurra, der Receiver schaltet sich ein!

Nachdem der Ethernet-UDP-Empfangsweg dank deiner Hilfe bereits funktioniert, wollte ich zur Komplettierung dieses Threads auch noch den UDP-Sendeweg von dir herauskitzeln und für die Nachwelt erhalten.

Der Sendeweg (Plugin sendet Befehl an IRtrans, das wiederum eine Anlage über Infrarot steuert) funktioniert schon über das http-Protokoll. In der IRtrans Bedienungsanleitung wird aber ausdrücklich darauf hingewiesen, dass http Irtrans-intern deutlich langsamer und komplexer verarbeitet wird als UDP, deshalb überhaupt mein Anliegen. Ich melde mich wieder nach dem Testen.

Gruß

Harald

**Patholog** · 15.12.2011, 21:50

Hallo Makki,

getestet und es klappt! Eigentlich braucht man Makkis Code-Schnipsel gar nicht testen, die klappen praktisch immer!

In das eingangs angeführte Plugin einfach
$socket[$socknum]->send('$MYTEXT') or return "send failed: $!";
einfügen.

$MYTEXT steht für den UDP-Befehl:
snd <remote>,<command1>;<command2>;

Nach snd ein Leerzeichen, remote und command1 durch ein Komma trennen ohne Leerzeichen; mehrere commands durch einen Strichpunkt trennen ohne Leerzeichen.

Nicht getestet: sndr: sendet Befehle, deren IR-Codes Wiederholungscodes enthalten.

Klappt! Danke!

Harald

Ankündigung

- √ - Kommunikation irtrans und Wiregate

[wiregate] - √ - Kommunikation irtrans und Wiregate

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar