Neuerdings Probleme mit IR Empfang am CUNO

[mago0211]

Hallo zusammen,

bin mittlerweile etwas verzweifelt 

Ich betreibe hier einen CUNO V2 von Busware. U.a. verwende ich die IR-Diode des CUNO um Befehle von einer Logitech Harmony entgegen zu nehmen. Das hat bis letzte Woche auch ca. 1 1/2 Jahre wunderbar funktioniert.

Letzte Woche habe ich mal wieder ein Update gemacht (mach ich viel zu selten  ) Ich kann mir aber nicht vorstellen das es an dem Update liegt. Ich habe mit einem DIFF Programm geschaut ob sich die beiden Module 10_CUL_IR.pm und 00_CUL.pm geändert haben.
An 10_CUL_IR.pm hat sich durch das Update nichts verändert.
An 00_CUL.pm gab es Änderung durch das Update ich kann mir aber nicht vorstellen das das dort mit reinspielt. Ich habe es dann nochmal mit der "alten" 00_CUL.pm versucht. Ergebnis ist das gleiche es kommen keine IR-Signale mehr an   .

Die Diode selbst funktioniert noch, habe ich getestet mit einem IRSend und der Handykamera.

Vielleicht kann mir jemand weiterhelfen im Moment weiß ich nicht so recht wo ich weitersuchen soll, warum er keine IR-Signale annehmen kann.

Hier noch der Auszug aus der CFG

Code Auswählen Erweitern


define CUNO2 CUL 192.162.232.125:2323 1111
attr CUNO2 room 99sys_CUL/CUNO
[i]VERSION V 1.52 CUNO868[/i]

define CUNO_IR CUL_IR CUNO2
attr CUNO_IR ButtonA006 I07000A000100 set og_wz_licht_orange on
attr CUNO_IR ButtonA007 I07000A000200 set og_wz_licht_orange off
attr CUNO_IR ButtonA011 I07000A000300 set HTPC_WOL on
attr CUNO_IR ButtonA012 I07000A000400 set og_wz_steckerleiste_tv on
attr CUNO_IR ButtonA013 I07000A000600 set og_wz_steckerleiste_konsolen on
attr CUNO_IR ButtonA014 I07000A000700 set og_wz_steckerleiste_konsolen off
attr CUNO_IR ButtonA015 I07000A000800 set fernsehen_logitech on
attr CUNO_IR ButtonA016 I07000A000900 set fernsehen_logitech off
attr CUNO_IR ButtonA017 I07000A000500 set og_wz_steckerleiste_tv off
attr CUNO_IR ButtonA018 I07000A000000 set WiiU_logitech on
attr CUNO_IR ButtonA019 I07000A000A00 set WiiU_logitech off
attr CUNO_IR ButtonA020 I07000A006E00 set og_wz_Sideboardlampe dimup
attr CUNO_IR ButtonA021 I07000A003800 set og_wz_Sideboardlampe off
attr CUNO_IR irReceive ON_NR
attr CUNO_IR learncount 22
attr CUNO_IR learnprefix A
attr CUNO_IR loglevel 5
attr CUNO_IR room 99sys_CUL/CUNO


Grüße
Markus

[rudolfkoenig]

Hast du ein culfw update auch gemacht? Wenn nicht, bitte erstmal auch nicht.
Was ist das Problem denn genau?
Was landet mit "attr global verbose 5" im FHEM-Logfile, wenn man auf dem Harmony einen Knopf drueckt.

[mago0211]

Hallo Rudolf,

nein ein culfw update habe ich nicht gemacht.

Das Problem ist eigentlich das IR-Signale nicht mehr verarbeitet werden.

Der Log Eintrag:

Code Auswählen Erweitern

2015.02.24 11:08:14 5: CUL/RAW: /I07000A003800

2015.02.24 11:08:14 4: CUL_Parse: CUNO2 I07000A003800
2015.02.24 11:08:14 5: CUNO2 dispatch I07000A003800
2015.02.24 11:08:14 3: message "I07000A003800" to short!

Gruß
Markus

[mago0211]

Hallo,

ich habe nochmal gesucht wo die Meldung

Code Auswählen Erweitern

2015.02.24 11:08:14 3: message "I07000A003800" to short!

herkommt.

Diese Meldung kommt aus der 10_IT.pm Zeile 360.
Was hat die 10_IT.pm mit Infrarot Codes des CUNOs zu tun?

Ich habe die 10_IT.pm mit dem Backup von vor dem Update überschrieben und siehe da der IR-Empfang am CUNO Funktioniert wieder einwandfrei. Aber das kann ja nicht die Lösung sein das ich nach jedem Update das Modul zurückpatche?

Grüße
Markus

[StefanP]

Hallo Markus,
erstmal danke, deine Analyse hat mich gerettet.
ich habe seit gestern das gleiche Problem, alledings benutze ich statt einem Cuno die Raspi-Erweiterung von locutus (zum IR-Empfang, als 433-er-Cul und zum IT-Codes senden). Der Austausch der 10_IT.pm bringt auch bei mir Abhilfe. Da müssten doch eigentlich noch mehr User mit Problemen kommen.

Gruß StefanP

[StefanP]

Ich nochmal, anbei meine letzte IT.pm die noch funktioniert.

Gruß StefanP

[bjoernh]

Hallo Rudi,

sag mal, kann es sein, dass die 00_CUL.pm nicht auf die Groß- und Kleinschreibung achtet:

Code Auswählen Erweitern

    "D:CUL_IR"    => "^I............",
    "G:IT"        => "^i......",

Demnach würde immer das falsche ausgewählt.

Gruß
Björn

[rudolfkoenig]

Die Auswahl der Module bei einer Nachricht ist in FHEM historisch gewachsen und nicht sehr konsequent.

Erst wird $iodev->{Clients} nach ORDER (die Zahl vor dem Modulnamen) sortiert, und jedes Modul geprueft. Falls das Modul geladen ist dann mit $client->{Match} geprueft, ob die Nachricht passt. Falls passt, dann wird $client->{ParseFn} aufgerufen, und falls diese Funktion etwas zuerueckliefert, dann mit der Modulsuche aufgehoert. Die $client->{Match} Pruefung wird Case-Insensitive durchgefuehrt, da FHZ und CUL die HEX-Daten mit unterschiedlicher Klein-/Grosschreibung liefern haben, und ich das Problem (aus heutiger Sicht) an der falschen Ende gefixt habe (war deutlich einfacher).

Das war gut und ausreichend, bis autocreate kam. Leider haette FHEM mit diesem Verfahren alle Module laden muessen, falls eine Nachricht von einem noch nicht geladenen Modul eingetroffen ist. Deswegen wurde $client->{Match} zusaetzlich nach $iodev->{MatchList} kopiert, und damit die Nachricht geprueft. Falls die Pruefung positiv ausfaellt, dann wird das passende Modul geladen, und sein ParseFn aufgerufen.
Diese Methode wird aber nur dann verwendet, falls die vorher erwaehnte Schleife nichts zurueckgeliefert hat, also nur im autocreate Fall.

Das aktuelle Problem hat mehrere Ursachen:
a) die Case-Insensitive Sortierung
b) fhem sortiert die $cul->{Clients} Liste nur nach ORDER, und da sowohl CUL_IR, wie auch IT mit 10 anfangen, wird einer zufaellig ausgesucht, und das scheint IT zu sein.
c) IT->ParseFn sagt neuerdings nicht, dass er fuer das Paket sich nicht zustaendig ist (weil zu lang), sondern dass das Paket kaputt ist.

a) will ich nicht fixen, weil man dann zu viele alte Module ueberpruefen muesste.
b) habe ich geaendert, indem FHEM neuerdings nach <ORDER>Modulname sortiert. Das fixt das aktuelle Problem, allerdings nur zufaellig. Auf der anderen Seite will ich eine verlaessliche Reihenfolge haben.
c) koenntest du fixen, indem Parse undef zrueckliefert, falls e mit dem Paket nicts anfangen kann.

Alternative: in CUL.pm werden IT Nachrichten nach ITxxx und IR Nachrichten nach IRxxx gemappt, und beide Module passen sich an. Gibt es fuer IT.pm und fuer CUL_IR noch ausser CUL andere Lieferanten (== physikalisch Module)?

Und bitte "to short" in "too short" aendern :)

[bjoernh]

Hab den return undef im IT Modul eingebaut und eingecheckt.

[mago0211]

Habe gerade ein Update gemacht....

sieht gut aus die IR-Befehle werden wieder umgesetzt.
Danke für eure Hilfe   

Grüße

[mago0211]

Hallo zusammen,

so ganz scheint es doch noch nicht zu funktionieren. Es wird irgendwie immer komischer  .

Die IR Befehle werden jetzt wieder erkannt und auch umgesetzt. Ich habe jetzt aber Probleme mit notifys die hinter den Geräten hängen. Also z.B.:
Ich schalte mit dem IR-Befehl I07000A000800  -> den Dummy fernsehen_logitech on
In der Oberfläche wird der Dummy fernsehen_logitech auch auf on gesetzt und bei den Readings angezeigt mit aktueller Zeit.
LOG:

Code Auswählen Erweitern

2015.03.01 09:49:16 4: CUL_Parse: CUNO2 I07000A000800
2015.03.01 09:49:16 4: IR-Reception: I07000A000800
2015.03.01 09:49:16 4: dummy set fernsehen_logitech on

Auf dieses "on" sollte ein notify ausgelöst werden. Das passiert aber nicht?

Was jetzt das komische an dem ganzen ist, wenn ich den dummy fernsehen_logitech  über das Frontend auf on setzte wird das notify einwandfrei ausgelöst.

Ich weis nicht ob dieses Problem mit dem vorherigen zusammenhängt? Oder soll ich ein eigens Thema aufmachen?

Das notify

Code Auswählen Erweitern

fernsehen_logitech:on set og_wz_steckerleiste_tv on;
set og_wz_licht_orange on;
sleep 10;
set HTPC_WOL on;
sleep 20;
set HTPC_WOL off;

Gruß
Markus

[rudolfkoenig]

Ich gehe davon aus, dass das was voellig anderes ist.
Am besten verfolgt man in dem event Monitor, was so alles an Events generiert wird.

[mago0211]

Hallo,

habe ich gemacht.

Wenn ich den Befehl über das Frontend absetze also "set fernsehen_logitech on"

Steht folgendes im Event Monitor

Code Auswählen Erweitern


2015-03-01 15:17:24 FS20 og_wz_steckerleiste_tv on
2015-03-01 15:17:24 FS20 og_wz_licht_orange on
2015-03-01 15:17:24 dummy fernsehen_logitech on

Wenn ich das ganze über IR mache. Wird der state von fernsehen_logitech  auf on gesetzt

Code Auswählen Erweitern

state
on
2015-03-01 15:20:57

Und im Event Monitor passiert rein garnichts

Gruß
Markus

[rudolfkoenig]

Sorry, da weiss ich nicht mehr weiter, da muss der IR Maintainer dran.

[mago0211]

Hallo,

an wenn muss ich da wenden? 

Gruß
Markus