Probleme mit CUL und Intertechno

frank · 16 Juli 2014, 19:24:58

hallo andre,

wie du hier http://forum.fhem.de/index.php/topic,25257.msg182706.html#msg182706 ja schon mitbekommen hast gibt es bei mir probleme mit meinem cul beim senden von intertechno befehlen. eventuell ist ein teil der probleme auf die erkenntnisse dieses threads http://forum.fhem.de/index.php/topic,25202.0.html zurückzuführen. trotzdem bin ich der meinung, dass das noch nicht alles ist.

zur weiteren eingrenzung habe ich jetzt mal einen cul433 im slowrf modus aktiviert, um probleme durch das umschalten der modi zu umgehen. beim empfangen eines temperatursenders und senden eines einfachen on befehls erhalte ich folgenden log (cul433 verbose 5, it02 loglevel 0 und verbose 5), der für mich soweit ok aussieht.

Code Auswählen

2014.07.16 17:17:15.858 5: CUL/RAW: /tA08F73073413
2014.07.16 17:17:15.861 4: CUL_Parse: cul433 tA08F73073413 -64.5
2014.07.16 17:17:15.865 5: cul433 dispatch TXA08F730734
#######################################################################
2014.07.16 17:17:37.524 0: IT set IT02 on
2014.07.16 17:17:37.531 5: SW: isFF00F0000FFF
2014.07.16 17:17:37.874 5: CUL/RAW (ReadAnswer): isFF00F0000FFF

mich würde interessieren, welches modul die zeile mit "SW:" auswirft. "CUL/RAW" kommt von 00_cul.pm?

nun habe ich versucht die ausgabe der "Unknown code...help me" logs zu provozieren. nach vielem probieren, habe ich festgestellt, dass ich durch das setzen des attributs ITrepetitions solche logeinträge permanent generieren kann.

Code Auswählen

2014.07.16 17:20:09.151 5: SW: isr10
2014.07.16 17:20:09.165 0: IT set ITrepetition: isr10 for cul433
2014.07.16 17:20:09.167 0: IT set IT03 on
2014.07.16 17:20:09.171 5: SW: isFF000F000FFF
2014.07.16 17:20:09.185 5: CUL/RAW (ReadAnswer): 10
2014.07.16 17:20:09.189 5: SW: isr6
2014.07.16 17:20:09.202 0: IT set ITrepetition back: isr6 for cul433
2014.07.16 17:20:09.730 5: CUL/RAW: /isFF000F000FFF
6
2014.07.16 17:20:09.733 4: CUL_Parse: cul433 isFF000F000FFF
2014.07.16 17:20:09.735 5: cul433 dispatch isff000f000fff
2014.07.16 17:20:09.817 3: cul433: Unknown code isff000f000fff, help me!
2014.07.16 17:20:09.819 4: CUL_Parse: cul433 6
2014.07.16 17:20:09.894 2: cul433: unknown message 6

den inhalt von cul/raw interpretiere ich jetzt mal als ein/ausgangsspeicher des cul. messages mit "/" sind über funk empfangen und mit "(ReadAnswer)" werden gesendete befehle gekennzeichnet. somit und im vergleich mit dem ersten log sind alle drei gesendeten befehle durch die cul/raw logs falsch dargestellt.

1. im ersten cul/raw müsste der inhalt vom ersten sw: wiedergegeben werden => isr10
2. im zweiten cul/raw sind 2 gesendete befehle in 2 zeilen enthalten, die komplett als empfangen gekennzeichnet sind. ausserdem wird der befehl "isr6" wieder verkürzt zu "6". das vertauschen von gesendet zu empfangen verursacht dann wohl die help me zeile.

eigentlich sind die gesendeten befehle korrekt mit is (intertechno senden) gekennzeichnet. da würde ich erwarten, dass dann auch danach geparst wird. sehr tricky die abfolge von culfw, 00_cul, 10_it und eventuell noch fhem.pl.

kannst du ein wenig licht ins dunkel bringen?

gruss frank

frank · 17 Juli 2014, 16:00:00

das echo problem mit plotfork aus dem anderen thread kann es nicht sein. dort wird beschrieben, dass ein abschalten von plotfork das problem behebt. das kann ich nicht bestätigen. mit

Code Auswählen

attr global nofork 1
attr WEB plotfork 0

erhalte ich die selben logs.

Code Auswählen

2014.07.17 15:38:02.036 5: SW: isr10
2014.07.17 15:38:02.049 0: IT set ITrepetition: isr10 for cul433
2014.07.17 15:38:02.051 0: IT set IT03 on
2014.07.17 15:38:02.054 5: SW: isFF000F000FFF
2014.07.17 15:38:02.067 5: CUL/RAW (ReadAnswer): 10

2014.07.17 15:38:02.071 5: SW: isr6
2014.07.17 15:38:02.084 0: IT set ITrepetition back: isr6 for cul433
2014.07.17 15:38:02.613 5: CUL/RAW: /isFF000F000FFF
6

2014.07.17 15:38:02.615 4: CUL_Parse: cul433 isFF000F000FFF
2014.07.17 15:38:02.618 5: cul433 dispatch isff000f000fff
2014.07.17 15:38:02.702 3: cul433: Unknown code isff000f000fff, help me!
2014.07.17 15:38:02.704 4: CUL_Parse: cul433 6
2014.07.17 15:38:02.770 2: cul433: unknown message 6

"sw:" kommt übrigens auch aus 00_cul.pm und wird dort durch die funktion simplewrite geschrieben. wahrscheinlich wäre ein verschieben nach "cul-entwicklung, fehlerberichte" angebracht.

edit: culfw update auf v1.61 ergibt nichts neues.

gruss frank

micomat · 17 Juli 2014, 18:32:45

sorry, ich versteh zwar nur bahnhof, aber ich sehe das problem derzeit nicht mehr.
wieso weiß ich auch nicht. ausser einem neustart des Pi habe ich weiter nichts gemacht. und den neustart auch nur wegen einer overclocking aenderung.

gruß
markus

topfi · 18 Juli 2014, 11:24:09

Das sieht doch aber wirklich sehr nach Schnittstellenproblem aus. Hast Du mal

Code Auswählen

stty -a < /dev/ttyACM0

eingegeben und geschaut, wie die echos definiert sind?

ITrepetition habe ich nie benutzt. Kann man dort einfach die Anzahl der Sendeversuche eintragen? Steht das standardmäßig auf Eins?

frank · 18 Juli 2014, 12:18:46

hallo topfi,

nach fritzbox reboot:

Code Auswählen

# stty -a < /dev/ttyACM0
speed 9600 baud;stty: standard input
 line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl echoke

dann geschaltet:

Code Auswählen

2014.07.18 11:51:07.600 5: SW: isr10
2014.07.18 11:51:07.613 0: IT set ITrepetition: isr10 for cul433
2014.07.18 11:51:07.614 0: IT set IT03 on
2014.07.18 11:51:07.617 5: SW: isFF000F000FFF
2014.07.18 11:51:07.630 5: CUL/RAW (ReadAnswer): 10

2014.07.18 11:51:07.635 5: SW: isr6
2014.07.18 11:51:07.648 0: IT set ITrepetition back: isr6 for cul433
2014.07.18 11:51:08.169 5: CUL/RAW: /isFF000F000FFF
6

2014.07.18 11:51:08.171 4: CUL_Parse: cul433 isFF000F000FFF
2014.07.18 11:51:08.174 5: cul433 dispatch isff000f000fff
2014.07.18 11:51:08.251 3: cul433: Unknown code isff000f000fff, help me!
2014.07.18 11:51:08.254 4: CUL_Parse: cul433 6
2014.07.18 11:51:08.326 2: cul433: unknown message 6

und dann:

Code Auswählen

# stty -a < /dev/ttyACM0
speed 9600 baud;stty: standard input
 line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl echoke

soweit ich das als windowsuser beurteilen kann, sind alle echo einträge unverändert. welche einträge betrifft es denn genau beim echo-problem, wie von dir beschrieben? soweit ich das bei deinen posts gesehen habe, meinst du wohl die einträge "echo.*" mit und ohne "-".

ZitatITrepetition habe ich nie benutzt. Kann man dort einfach die Anzahl der Sendeversuche eintragen? Steht das standardmäßig auf Eins?

habe ich auch erst jetzt entdeckt. ich denke keine sendeversuche, sondern fix eingestellte wiederholungen. nach dem log steht es wohl default auf 6.

ich habe die vermutung das sich das echo problem bei mir nur zeigt, wenn auf einmal echo-mässig permanent logeinträge wiederholt auftauchen.

gruss frank

topfi · 18 Juli 2014, 13:53:35

Nein, das sieht alles ok aus. Wichtig sind diese hier:

Code Auswählen

-echo -echoe -echok

davor muss immer ein Minus stehen. Am wichtigsten ist -echo. Das sah bei mir ganz anders aus.

Wie ist der CUL initialisiert? Stell doch mal spaßenshalber 38400 als Geschwindigkeit ein, obwohl das eigentlich nichts ändern dürfte. Aber der Teufel ist manchmal ein Eichhörnchen...
Hast Du mal einen aktiven USB-Hub dazwischen geschaltet? Was ist noch über USB dran? Bei dir läuft das doch auf einer Fritte?! Gibt es da irgendwelche Energiespareinstellungen für den/die USB-Port(s)?

frank · 18 Juli 2014, 17:15:08

ZitatStell doch mal spaßenshalber 38400 als Geschwindigkeit ein

keine änderung.

ZitatHast Du mal einen aktiven USB-Hub dazwischen geschaltet?

ja.

ZitatWas ist noch über USB dran?

im augenblick noch ein hm-usb-cfg2. war auch schon alleine dran. energieeinstellungen gibt es nicht.

komischerweise gibt es schon unterschiede im log, wenn einmal der set it befehl ausgeführt wird:

Code Auswählen

2014.07.18 16:39:26.788 0: IT set IT02 on
2014.07.18 16:39:26.792 5: SW: isFF00F0000FFF
2014.07.18 16:39:27.128 5: CUL/RAW (ReadAnswer): isFF00F0000FFF

oder set cul raw mit dem selben code:

Code Auswählen

2014.07.18 16:42:47.296 3: set cul433 raw isFF00F0000FFF
2014.07.18 16:42:47.298 5: SW: isFF00F0000FFF
2014.07.18 16:42:47.650 5: CUL/RAW: /isFF00F0000FFF

2014.07.18 16:42:47.654 4: CUL_Parse: cul433 isFF00F0000FFF
2014.07.18 16:42:47.656 5: cul433 dispatch isff00f0000fff
2014.07.18 16:42:47.734 3: cul433: Unknown code isff00f0000fff, help me!

sollte das ergebnis nicht gleich aussehen?
wie sieht denn dein log aus, wenn du mit itrepetition=10 ein set my_schalter on sendest? gibt das auch ein "help me"?

gruss frank

justme1968 · 18 Juli 2014, 19:29:34

das it modul verwendet get nicht set. es liest die antwort direkt. das ist die readanswer meldung.

beim set sollte meiner meinung nach nichts zurück kommen. wenn doch funkt das echo dazwischen. ich kann aber gerade nicht nachsehen.

wofür verwendest du die repetition?

die cul firmware sendet auf jeden fall drei mal pro senden. mit repetition wären das dann 30 mal und alles ist so lange blockiert.

verwendest du das normale it modul oder eines aus dem forum?

gruss
andre

frank · 18 Juli 2014, 20:53:31

Zitatbeim set sollte meiner meinung nach nichts zurück kommen. wenn doch funkt das echo dazwischen.

damit meinst du also set cul raw? woher kommt dann ein echo, wenn diese stty mitteilungen angeblich kein echo erlauben? vor und nach dem befehl habe ich das stty gemacht.

Code Auswählen

# stty -a < /dev/ttyACM0
speed 38400 baud;stty: standard input
 line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl echoke

Code Auswählen

2014.07.18 20:23:38.674 3: set cul433 raw isFF00F0000FF0
2014.07.18 20:23:38.677 5: SW: isFF00F0000FF0
2014.07.18 20:23:39.150 5: CUL/RAW: /isFF00F0000FF0

2014.07.18 20:23:39.152 4: CUL_Parse: cul433 isFF00F0000FF0
2014.07.18 20:23:39.154 5: cul433 dispatch isff00f0000ff0
2014.07.18 20:23:39.231 3: cul433: Unknown code isff00f0000ff0, help me!

Code Auswählen

# stty -a < /dev/ttyACM0
speed 38400 baud;stty: standard input
 line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl echoke

Zitatwofür verwendest du die repetition?

repetition brauche ich eigentlich gar nicht. nur für diese tests, wegen der help me mitteilung. jetzt werde ich mich auf set cul raw beschränken, weil gleiche mitteilung, aber direkter.

mein eigentliches problem ist ja, dass ich keinen cul (433 + 868) mehr zuverlässig nutzen kann. beide steigen irgendwann aus. jedesmal beginnt der zirkus mit einer "help me" mitteilung.

Zitatverwendest du das normale it modul oder eines aus dem forum?

Code Auswählen

# $Id: 10_IT.pm 5649 2014-04-25 22:44:27Z justme1968 $
das normale modul.

gruss frank

topfi · 22 Juli 2014, 20:35:37

Ich bin noch eine Information schuldig. Setze ich ITrepetition auf 10, passiert in der Tat Folgendes (upside down):

Code Auswählen


2014.07.22 20:30:11 2: CUL1: unknown message 6
2014.07.22 20:30:11 3: CUL1: Unknown code isf000f0ff0fff, help me!
2014.07.22 20:30:10 2: IT IODev device didn't answer is command correctly:   raw => 10

Das Licht geht aber an. Dito beim Ausschalten:

Code Auswählen


2014.07.22 20:32:05 2: CUL1: unknown message 6
2014.07.22 20:32:04 3: CUL1: Unknown code isf000f0ff0ff0, help me!
2014.07.22 20:32:04 2: IT IODev device didn't answer is command correctly:   raw => 10

Das passiert bei gesetztem Attribut ITrepetition, egal, was man da einstellt. Ich habe 1, 5 und 10 probiert. Ohne dieses Attribut: Alles paletti.

frank · 23 Juli 2014, 08:37:25

danke für deinen test. also genau wie bei mir. ich meine hier gibt es irgendwo einen bug.

welche einstellungen von verbose und loglevel hast du am schalter-device und am cul. diese art logeinträge bekomme ich nie. egal wie ich die dinger quäle.

Code Auswählen

2014.07.22 20:30:10 2: IT IODev device didn't answer is command correctly: raw => 10

für die echoproblematik habe ich jetzt übrigens ein notify definiert, dass das echo wieder ausschaltet. ich konnte bei mir allerdings immer noch keinen schuldigen finden. plotfork habe ich aktiviert.

gruss frank

topfi · 23 Juli 2014, 12:25:25

Ich habe außer

Code Auswählen

attr global verbose 3

nichts dergleichen definiert. Wie sieht denn Dein echo- notify aus? Hast Du plotfork wirklich "aktiviert"? Ist das nicht der Übeltäter?

frank · 23 Juli 2014, 15:31:01

ZitatWie sieht denn Dein echo- notify aus?

Code Auswählen

define n_cul433_unknown notify cul433:UNKNOWNCODE.\?.* {\
    my $usbCfg = `stty -a < /dev/ttyACM0`;;\
    system("stty -echo < /dev/ttyACM0");;\
    my $betreff = "FHEM: CUL433-ECHO";;\
    my $text = "$NAME $EVENT \n \n$usbCfg";;\
    Log 0,"----- CUL433-ECHO ----- $NAME $EVENT \r\n$usbCfg";;\
    FB_mail('xxxxxx@yyyyyy.de',$betreff,$text);;\
    fhem("setreading cul433 mail echo");;\
    fhem("set IT10 on");;\
}

durch versuche mit manuellem echo einschalten mit

Code Auswählen

stty echo < /dev/ttyACM0
über telnet an die fritzbox, erhalte ich sofort folgende events:

Code Auswählen

2014-07-21_14:14:48 cul433 UNKNOWNCODE 0016C721
2014-07-21_14:14:48 cul433 UNKNOWNCODE ? (0016C721 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x

immer erst eine 8 stellige hex-zahl, die sich von versuch zu versuch erhöht. muss wohl irgend ein timer hinterstecken. und als zweites die erklärung, dass die empfangene message unbekannt ist. auf "UNKNOWNCODE ?" triggere ich das notify.

im moment setze ich "blind" das echo zurück und logge vorher die usb parameter. da ich noch keine echte echoumschaltung analysieren konnte, muss man hier vielleicht noch prüfungen und weitere einstellungen einfügen. da kannst du bestimmt bessere lösungen anbieten. vielleicht kennst du ein kommando zum zurücksetzen der usb schnittstelle, falls das sinn macht?

auf alle fälle muss ich noch einen beliebiegen befehl absetzen,

Code Auswählen

fhem("set IT10 on");;\
da der erste befehl nach echo rückstellung noch nicht funktioniert. im culspeicher, steht immer noch die letzte meldung, die mit dem neuen befehl kollidiert. irgendwie ist beim cul da der wurm drinnen, zwischen empfangs- und sendespeicher. ich bin der meinung, da fehlt irgendeine speicherinitialisierung.

ZitatHast Du plotfork wirklich "aktiviert"? Ist das nicht der Übeltäter?

Code Auswählen

attr WEB plotfork 1
attr global nofork 0

ich kann dein prozedere leider nicht reproduzieren. bei mir muss das woanders herkommen, oder nicht immer.

gruss frank

topfi · 23 Juli 2014, 20:31:53

Ach Du schöner Mist, ist diese Perl-Syntax kompliziert.

Da lasse ich jetzt mal lieber das plotfork aus und lebe damit. Obwohl ich auch drei PRESENCE-Module am Laufen habe, die ja ach forken sollen. Die machen aber keinen Ärger.

Wie auch immer, ih habe mit zwei Maßnahmen mein FHEM sehr stabil bekommen:

1. plotfork deaktiviert --> keine CUL IT-Prbleme mehr
2. (hier OffT) die HMLAN-Disconnects wegbekommen mit

Code Auswählen


attr HMLAN1 hmLanQlen 3_normal
attr HMLAN1 respTime 4
attr HMLAN1 wdTimer 10

und dadurch, dass am Switch nur noch der Raspi und der HMLAN hängen. Meine Synology (24/7-Server für Exchange, Webseiten usw. ) dort ausgestöpselt und direkt an die Fritzbox gehängt. Letzteres und hmLANQlen 3 haben am meisten gebracht.

Jetzt brauche ich erstmal ein zuverlässiges System und lasse die Experimente mal ein paar Tage sein.

frank · 23 Juli 2014, 21:00:02

ZitatJetzt brauche ich erstmal ein zuverlässiges System und lasse die Experimente mal ein paar Tage sein.

ein mann, ein wort. aber ein paar tage sind schnell vorbei.

zum echo rückstellen brauchst du nur die "system"-zeile. dazu noch eine zeile mit einem beliebiegen schalt-befehl. der rest ist nur für email und log. das komplizierte sind eigentlich deine tty-befehle. die notify definition übernimmst du.

na dann, ruhige tage.

topfi · 23 Juli 2014, 21:21:35

Danke mache ich.

Es kribbelt sowieso in den Fingern. Aber vielleicht bleibt beim ruhigen Lesen auf der Terrasse mit einem Gläschen Martini mehr hängen als immer vor dem Bildschirm...

Danach ist erstmal die Problematik AES und Keymatic-FB dran. Aber erst, wenn der Martini alle ist.

topfi · 24 Februar 2015, 13:29:58

So, jetzt habe ich den Server umgezogen vom Raspi auf einen Banana Pi mit SSD. Einen neuen CUL zum späteren Herumexperimentieren mit IT-Empfang habe ich auch noch, dem habe ich zunächst mal (vorübergehend) die neueste offizielle Firmware verpasst.

Und was soll ich sagen: Das echo-Problem besteht weiter. Kaum habe ich Plotfork aktiviert und eine Grafik geladen, prompt sind die echos wieder aktiv und der CUL kommt aus dem Tritt, wenn er IT schalten soll. Das gibt es doch nicht.