Könnt ihr mir sagen, was das ist?
2013.06.08 09:43:15 2: CUL1: unknown message ? (? (K71705173F9 isF3CC3D1398A1B is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:43:52 2: CUL1: unknown message ? (? (? (K71705173F9 isFAK013402473E is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:44:56 2: CUL1: unknown message ? (? (? (? (K7170517C MK71719173F8 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:46:49 2: CUL1: unknown message ? (? (? (? (? (K717K013402473C is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:49:46 2: CUL1: unknown message ? (? (? (? (? (? (K7K013402473C is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:50:43 2: CUL1: unknown message ? (? (? (? (? (? (? (K71725173F8 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:52:43 2: CUL1: unknown message ? (? (? (? (? (? (? (? K0134024740 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:53:28 2: CUL1: unknown message ? (? (? (? (? (? (? F288201212120 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:53:37 2: CUL1: unknown message ? (? (? (? (? (? (? A G M R T V W X 28820121211E is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:53:37 2: CUL1: unknown message ? (K71736172FA is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:55:15 2: CUL1: unknown message ? (? (? (oW X e f m F28820120211C is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:55:20 2: CUL1: unknown message ? (? (? (? (oW X e f A G M R T V W X 28820120211B is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:55:22 2: CUL1: unknown message ? (? (? (? (? (oW one of B C F i F3cc32800 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.06.08 09:55:40 2: CUL1: unknown message ? (? (? (? (? (? (oWF K013402473A is unknown) Use one of B C F i A G M R T V W X e f m l t u x
Hallo,
ZitatKönnt ihr mir sagen, was das ist?
Klar. Oder zumindest kann ich es versuchen.
Dein CUL empfängt sowas
ZitatK71705173F9 isF3CC3D1398A1B
(und div. andere Daten) und kann damit nichts anfangen.
Daher die Meldungen.
Grüße
ich hatte solche meldungen schon wenn die usbschnittstelle nicht richtig initialisiert/konfiguriert ist. z.b. geschwindigkeit,echo,...
gib mal mit @38400 die geschwindigkeit noch mit an.
gruss
andre
Konnest du die USB Schnittstelle neu installieren?
Geht es jetzt?
Das hat nichts gebracht.
Davon abgesehen, hat es ja auch die ganze Zeit ohne das "@38400" funktioniert. Erst mit dem letzten Update fing der Mist an.
> Erst mit dem letzten Update fing der Mist an.
Mag sein, liegt aber daran, dass bei der USB-Schnittstelle echo aktiv ist.
Insb. Linux Distributionen aendern gerne solche defaultwerte, deswegen ist eine Verbindung ohne @38400 (oder irgendeine andere gueltige Baudrate) ein Gluecksspiel.
Den Cul habe ich seit heute Morgen mit define CUL1 CUL /dev/busware_cul@38400 1234 in der fhem.cfg eingetragen.
Aber das hat nichts geändert. Die Fehlermeldungen sind noch genau so da, wie vorher.
Selbst eine Baudrate von 2400 funktioniert nicht. Wie kann ich denn sonst noch das Echo abschalten?
Oder soll ich wie Splash vorgeschlagen hat die USB-Schnittstelle neu installieren?
Wenn ja, wie geht das?
Hallo Jörg,
konntest Du das Problem inzwischen lösen? Bei mir tritt der gleiche Fehler auf...
Klaus
Hi Klaus,
tut mir leid, aber das Problem besteht immer noch.
Ich kann nur sagen, dass ich noch einen CUL getestet habe, mit dem Ergebnis, dass der auch so reagiert. Also kann man davon ausgehen, dass es nicht am CUL liegt.
Mein CUL empfängt zwar, aber kann nicht senden.
schau mit 'stty -F <device>' nach ob das lokale echo ein oder aus ist. es muss aus sein.
gruss
andre
Hi Andre,
das Ergebnis ist:
speed 9600 baud; line = 0;
-brkint -imaxbel
es sollte etwas in der art sein:speed 9600 baud; line = 0;
min = 1; time = 0;
-cread
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
vor allem die -echo sind wichtig.
versuch die mal mit stty zu setzen.
gruss
andre
stty -F /dev/ttyACM0 -echo
scheint nicht zu gehen.
Und mit stty -F /dev/ttyACM0
bekomme ich nur
speed 9600 baud; line = 0;
-brkint -imaxbel
was genau bedeutet scheint nicht zu gehen ?
versuch mal die andere syntax zum setzen:
stty -echo < /dev/ttyACM0
gruss
andre
Auch mit der anderen Syntax ändert sich nichts.
Wenn ich das eingebe, sollte dann eine Bestätigungsmeldung kommen, oder sieht man da nichts?
man sieht nichts.
mit der abfrage kann man prüfen ob es gesetzt wurde.
gruss
andre
Mit
stty -a < /dev/ttyACM0
bekomme ich das hier:
speed 9600 baud; rows 0; columns 0; 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 = 1; 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
und genau das ist das problem. das lokale echo ist eingeschaltet. es muss mit -echo ausgeschaltet sein.
gruss
andre
Das hier scheint er zu akzeptieren:
stty < /dev/ttyACM0 -echo
Denn jetzt zeigt stty -a < /dev/ttyACM0
speed 9600 baud; rows 0; columns 0; 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 = 1; 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
Aber die CUL1: unknown message sind immer noch da.
hast du fhem neu gestartet und geschaut ob danach das echo immer noch aus ist ?
gruss
andre
Hmm - dann ist echo wieder an. :(
werden die werte auch wieder zurueckgesetzt wenn du directio beim cul verwendest ?
gruss
andre
Mit /dev/ttyACM0@directio scheint es nun zu gehen. Das echo bleibt ausgeschaltet und die unknown messages sind verschwunden !!!
Nachher werde ich noch einmal einen kompletten Neustart des Servers machen und hoffe, dass das echo dann auch noch aus ist.
Was mich nur wundert ist, dass ich hinter /dev/ttyACM0 nie etwas stehen hatte und es hat immer funktioniert.
Auf jeden Fall vielen Dank für Deine Hilfe !!!
das stty übersteht einen reboot nicht.
je nach linux distribution sollte es aber irgendwo eine stelle geben wo die seriellen schnittstellen initialisiert werden. da kannst du die änderungen einbauen damit sie nach dem reboot noch da sind.
gruss
andre
> Mit /dev/ttyACM0@directio scheint es nun zu gehen
das bedeutet dass die in fhem/FHEM/DevIo.pm programmierten Einstellungen der seriellen Schnittstelle wirkungslos sind. Das Workaround besteht aus sowas wie
sleep 30 < /dev/ttyACM0 &
stty -echo -echoe -echok < /dev/ttyACM0
perl fhem.pl fhem.cfg
Ich wuesste gerne was das fuer eine Hardware/OS/Distribution Kombination ist, und wieso die eingebauten Routinen nicht funktionieren. Steht in fhem-log was ueber "Can't load Device::SerialPort" ?
Das ist ein ASUS eeePc
Betriebssystem Ubuntu Linux 12.04.1
Kernel und CPU Linux 3.2.0-48-generic-pae auf i686
Prozessorinformation Intel Atom CPU N450 @ 1.66GHz, 2 cores
Reichen die Infos?
Zitat von: rudolfkoenig schrieb am Fr, 14 Juni 2013 10:45> Steht in fhem-log was ueber "Can't load Device::SerialPort" ?
Nein
Hallo,
mit Ubuntu 12.04 habe ich auch dieses Problem. Konnte ich gestern Abend wieder nach einem Rechner Neustart mehrmals nachvollziehen. Ich habe dann hartnäckig den Buffer des CUL so lange immer wieder gelöscht, bis es endlich läuft. Seit gestern Abend läuft es jetzt ohne Echos durch.
Mein CUL ist mit /dev/ttyACM0@9600 1034 definiert. Als Kernel läuft bei mir aber 3.5.0-34-generic (SMP) i686.
Dirk
Auch habe das Problem bei meiner Fritzbox 7390. Mein Logfile bläht sich mit den Fehlermeldungen auf:
2013.06.16 09:44:53 2: CUL_0: unknown message ? (? (? (? (? (? B C F i A Z E G MT260T370800A600DA is unknown) Use one of B C F i A Z E G
M R T V W X e f m l t u x
2013.06.16 09:44:58 2: CUL_0: unknown message ? (? (? (? (? (? (Use oTC188740118 is unknown) Use one of B C F i A Z E G M R T V W X e f m
l t u x
2013.06.16 09:44:58 2: CUL_0: unknown message ? (? (? (? (? (? TC188748119 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.16 09:45:31 2: CUL_0: unknown message ? (? (? (? (? (? (?F5116E51003 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u
x
2013.06.16 09:45:41 2: CUL_0: unknown message ? (? (? (? (? (? Z E G M K4174016011 is unknown) Use one of B C F i A Z E G M R T V W X e f
m l t u x
2013.06.16 09:45:44 2: CUL_0: unknown message ? (? (? (? (? (? T461B00AA0029 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t
u x
u.s.w. ....
Betrieben wird eine Fritzbox 7390 mit Fritz!OS 05.55-25409 BETA, angeschlossen sind ein CUL und ein Huawei webstick.
Bis vor 2 Wochen funktionierte alles tadellos, nach einem Update o.g. Probleme.
Hat schon jemand eine Lösung ?
Meine config:
----------------------------------------
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
telnetPort has no password/globalpassword attribute.\
Running with root privileges.\
Restart fhem for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
attr global sendStatistics onUpdate
attr global statefile ./log/fhem.save
attr global uniqueID ./FHEM/FhemUtils/uniqueID
attr global userattr Schalter Schalter_map devStateIcon devStateStyle fp_Dach fp_Erdgeschoss fp_Etage1 fp_Keller fp_UEBERSICHT icon sortby structexclude webCmd
attr global verbose 3
#
# pgm2 / autocreate configfile. Take a look at the other examples for more.
#
### define fbaha FBAHA 192.168.115.49:2002 Für Direkt ohne Beta
define fbaha FBAHA UNIX:SEQPACKET:/var/tmp/me_avm_home_external.ctl
.
.
.
-------------------------------------------------------
Ich hänge mich dran.
Raspberry Pi, mit wheezy;
Zitatpi@raspberrypi ~ $ stty -a < /dev/ttyACM0
speed 9600 baud; rows 0; columns 0; 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 = 1; 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
fhem.cfg Eintrag:
Zitatdefine CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456
Edit 1:
Und das Logfile sieht auch sehr merkwürdig aus:
Zitat2013.06.17 02:30:56 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.06.17 02:30:56 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is No answer, but we need 113. Waiting 113 seconds.
2013.06.17 02:30:56 3: Setting CUL0 baudrate to 9600
2013.06.17 02:30:56 1: /dev/ttyACM0 reappeared (CUL0)
2013.06.17 02:30:57 3: CUL0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.17 02:32:46 2: CUL0: unknown message ? (21 900 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.17 02:32:46 2: CUL0: unknown message ? (? (21 900 is unk m l t u x is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.17 03:12:30 2: CUL_HM set OG_fl2_WS_LICHT on-for-timer 30
2013.06.17 03:30:56 2: CUL0: unknown message ? (? (? (21 900 iZ E G M R T V W 0E3Z0B1600021234560511Z0B90000212 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.17 03:30:59 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.06.17 03:31:00 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is No answer, but we need 113. Waiting 113 seconds.
2013.06.17 03:31:00 3: Setting CUL0 baudrate to 9600
2013.06.17 03:31:00 1: /dev/ttyACM0 reappeared (CUL0)
2013.06.17 03:31:00 3: CUL0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.17 03:32:50 2: CUL0: unknown message ? (21 900 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.17 03:32:50 2: CUL0: unknown message ? (? (21 900 is unkn m l t u x is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.17 03:32:53 2: CUL_MAX_SendQueueHandler: Missing ack from 065b19 for 0f160403123456065b19000d110360b1
2013.06.17 04:31:00 2: CUL0: unknown message ? (? (? (21 900 is uZ0B1600021234560511DZ0B900002123456062Z0B1E000 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.17 04:31:03 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.06.17 04:31:03 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is No answer, but we need 113. Waiting 113 seconds.
2013.06.17 04:31:03 3: Setting CUL0 baudrate to 9600
2013.06.17 04:31:03 1: /dev/ttyACM0 reappeared (CUL0)
2013.06.17 04:31:03 3: CUL0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.17 04:32:53 2: CUL0: unknown message ? (21 900 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.17 04:32:53 2: CUL0: unknown message ? (? (21 900 is unkno m l t u x is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
Edit 2:
ZitatFhem info:
Release : 5.4
Branch : DEVELOPMENT
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.14.2
uniqueID : 69551e643834205d5d7b111c45c0527e
Defined modules:
CUL : 1
CUL_HM : 20
CUL_MAX : 1
DbLog : 1
FB_CALLMONITOR : 1
FHEMWEB : 6
FileLog : 14
HMLAN : 1
LightScene : 1
MAX : 11
PRESENCE : 1
autocreate : 1
dummy : 6
notify : 13
telnet : 1
Defined models per module:
CUL_HM : HM-LC-Bl1PBU-FM,HM-LC-DIM1T-PL,HM-LC-SW1-PL2,HM-LC-Sw1PBU-FM,HM-PB-2-WM55,HM-RC-4-B,HM-SEC-MDIR,HM-SEC-SD,HM-Sen-MDIR-O
Transmitting this information during an update:
onUpdate (Note: You can change this via the global attribute sendStatistics)
Hallo,
wenn ich den folgenden Wert setze:
define CUL_0 CUL /dev/ttyACM0@directio
##define CUL_0 CUL /dev/ttyACM0@9600 1034
erscheint diese FEhlermeldung:
wrong syntax: define CUL {none | devicename[@baudrate] | devicename@directio | hostname:port} ELROA1: unknown IODev specified ELROA2: unknown IODev specified ELROA3: unknown IODev specified ELROA4: unknown IODev specified ELROA5: unknown IODev specified ELROA6: unknown IODev specified Please define CUL_0 first Please define CUL_0 first
Jemand eine Idee ?
Zitat von: Sebastian schrieb am Mo, 17 Juni 2013 12:41Hallo,
wenn ich den folgenden Wert setze:
define CUL_0 CUL /dev/ttyACM0@directio
##define CUL_0 CUL /dev/ttyACM0@9600 1034
...
Jemand eine Idee ?
Versuche das mal: ;-)
define CUL_0 CUL /dev/ttyACM0@directio 1034
Ich schätze mal, dass Rudi bei Gelegenheit die
DevIo.pm so abändert, dass es wieder geht.
Hi,
das setzen hat zumindest ohne Fehlermeldung geklappt:
Im Log steht folgendes:
2013.06.17 13:15:28 0: Server started with 59 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3236 2013-06-01 17:13:50Z rudolfkoenig $, pid 8650)
2013.06.17 13:17:52 2: FHT set FHT_280c desired-temp 16.0
2013.06.17 13:17:52 2: CUL_0: unknown message EOB
2013.06.17 13:19:35 2: FHT set FHT_280c desired-temp 17.0
2013.06.17 13:19:35 2: CUL_0: unknown message EOB
Der Actuator zeigt sowas an :
actuator unknown_69: 67% 2013-06-17 13:17:59
Ich kann das Problem weder auf einem Ubuntu 12.04.2 noch auf einem 10.04.4 nachvollziehen.
Die mAn korrekte Definition lautet
define CUL_0 CUL /dev/ttyACM0@9600 1034
wobei man 1034 aendern sollte. Die Zahl nach dem @ (9600) sollte eine gueltige Baudrate sein, und es kann fuer USB beliebig gewaehlt werden. Die Zahl bewirkt hier nur, dass die Steuer-Bits (echo/etc) von FHEM gesetzt werden. Bei COC/CSM ist das anders, hier ist die Baudrate auch wichtig, da eine echte serielle Schnittstelle verwendet wird. Beim Start erscheinen folgende Meldungen im log:
2013.06.17 16:12:36 3: Opening CUL_0 device /dev/ttyACM0
2013.06.17 16:12:36 3: Setting CUL_0 baudrate to 9600
2013.06.17 16:12:36 3: CUL_0 device opened
2013.06.17 16:12:36 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
Die Zeile "Setting CUL_0 baudrate to 9600" zeigt an, dass fhem die echo-bits setzen will, pruefen kann man es mit "stty -a < /dev/ttyACM0". Dabei muss fhem laufen, und das Ergebnis sollte alle echo Varianten mit "-" (d.h. inaktiv) anzeigen. Sonst schickt das OS die gerade empfangenen Zeichen richtung CUL/culfw zurueck, was culfw zu den o.g. Fehlermeldung veranlasst.
Mit @directio statt @9600 setzt FHEM keine Bits, d.h. die defaults der OS werden uebernommen. Diese stimmen manchmal, haeufig aber nicht.
Das Problem kann ich also nur dann korrigieren, wenn man mir genau zeigt, wie ich es nachstellen kann.
Habe dieselben Meldungen ab und zu (Debian Squeeze). Angefangen hats vor über einem Monat. Und zwar zu Hauf, bestimmt 20 Einträge im Log pro Sekunde.
Reinitialisiern des USB-Ports hat bei mir geholfen (alternativ ab / anstecken).
Der Code den ich benutzt habe:
echo suspend > /sys/bus/usb/devices/1-1/power/level
Die 1-1 muss evtl. angepasst werden. Den CUL findet man z.B. mit
cat /sys/bus/usb/devices/1-1/product
Hier muss man die 1-1 durchprobieren. Der CUL antwortet bei mir mit
CUL868
Grüße!
PS:
Meine CUL Definition (schon immer so):
define CUL_0 CUL /dev/ttyACM0@9600 1034
Hallo,
wenn ich das setze:
define CUL_0 CUL /dev/ttyACM0@9600 1034
Dann kommt folgendes:
2013.06.17 16:41:05 3: Opening CUL_0 device /dev/ttyACM0
2013.06.17 16:41:05 3: Setting CUL_0 baudrate to 9600
2013.06.17 16:41:05 3: CUL_0 device opened
2013.06.17 16:41:05 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
Setze ich die desired-temp:
2013.06.17 16:41:06 0: Server started with 59 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3236 2013-06-01 17:13:50Z rudolfkoenig $, pid 13787)
2013.06.17 16:42:39 2: FHT set FHT_280c desired-temp 21.0
2013.06.17 16:42:39 2: CUL_0: unknown message EOB
Ist ein Debian:
root@fhem:~# uname -a
Linux fhem 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686 GNU/Linux
root@fhem:~# stty -a < /dev/ttyACM0
speed 9600 baud; rows 0; columns 0; 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 = 1; 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
Das hat mit der Diskussion hier nichts zu tun: EOB zeigt nur, dass das FHT Puffer voll ist, vmtl. weil das FHT mit FHEM nicht gepaart ist, oder weil die Kommunikation staendig abbricht. Bitte dafuer separates thread oeffnen.
Wie du den Fehler nachstellen kannst, weiß ich nicht.
Aber du kannst gerne eine ssh und eine ftp Verbindung bekommen, wenn du dir es live und in Farbe ansehen willst.
Nachtrag: auf einem FB7390 konnte ich das Problem mit dem aktuellen FHEM Version auch nicht nachstellen.
Weder unter der FRITZ!OS Version 84.05.55-25409, noch mit 84.05.55-25667
Hallo,
ich hänge hier mal einen Ausschnitt aus meinem Log vom letzten Rechner Neustart. Wie man sieht, startet der CUL wohl ganz normal und will dann aus dem HC Modul die Temperaturen an die FHT senden. Doch damit fängt alles an. Dies geht soweit, bis alle FHT Befehle im Buffer stehen. Dann habe ich begonnen, den Buffer immer wieder zu löschen. Irgendwann ging dann alles. Nun läuft es seit dem ohne Probleme durch. Es gab auch Neustarts von FHEM wegen Updates, aber nicht vom Rechner. FHEM Neustarts machen also keine Probleme, nur der Neustart des PC.
EOB und LOVF gehören wohl doch dazu. Diese Meldungen hatte ich auch schon. Aber wie man im Log sieht, beim letzten Mal nicht.
Vielleicht hilft ja der Auszug.
Beste Grüße.
2013.06.14 23:03:54 0: Server shutdown
2013.06.14 23:05:30 1: Including fhem.cfg
2013.06.14 23:05:32 3: telnetPort: port 7072 opened
2013.06.14 23:05:32 3: WEB: port 8083 opened
2013.06.14 23:05:32 3: WEBphone: port 8084 opened
2013.06.14 23:05:32 3: WEBtablet: port 8085 opened
2013.06.14 23:05:33 3: Opening CUL_0 device /dev/ttyACM0
2013.06.14 23:05:33 3: Setting CUL_0 baudrate to 9600
2013.06.14 23:05:33 3: CUL_0 device opened
2013.06.14 23:05:33 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.14 23:05:35 1: Including ./log/fhem.save
2013.06.14 23:05:35 0: Server started with 84 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3236
2013-06-01 17:13:50Z rudolfkoenig $, pid 1305)
2013.06.14 23:06:04 2: FHT set FHT_Flur desired-temp 16.0
2013.06.14 23:06:57 2: CUL_0: unknown message ? (S030276011E0000FF2C00010DD3FC004830276011E0000FF58F177812E is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.14 23:07:19 2: CUL_0: unknown message ? (? (S0302unknown) Use one043700A60032 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.14 23:07:22 2: CUL_0: unknown message ? (? (? (S0302uC F i A Z E G M 004F0069A6FE is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.14 23:07:30 2: CUL_0: unknown message 3257:4120 4442:00A6,0022 3257:4120 532F:00A6,0011 532F:0069,A611 E581:AE02,FA E581:AE82,FA 360E:00A6,0020 360E:0069,A620 3257:00A6,00FC 004F:00A6,00FE 1B61:00A6,00FA
2013.06.14 23:07:33 2: CUL_0: unknown message 3257:4120 4442:00A6,0022 3257:4120 532F:00A6,0011 532F:0069,A611 E581:AE02,FA E581:AE82,FA 360E:00A6,0020 360E:0069,A620 3257:00A6,00FC 004F:00A6,00FE 1B61:00A6,00FA
2013.06.14 23:07:38 2: CUL_0: unknown message ? (? (? (? (? (? (S0e one of B 6,00FC 004F:00A6T444200A60022 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.14 23:07:41 2: CUL_0: unknown message 3257:4120 4442:00A6,0022 3257:4120 532F:00A6,0011 532F:0069,A611 E581:AE02,FA E581:AE82,FA 360E:00A6,0020 360E:0069,A620 3257:00A6,00FC 004F:00A6,00FE 1B61:00A6,00FA
2013.06.14 23:07:43 3: set CUL_0 raw T011034
2013.06.14 23:07:50 3: set CUL_0 raw T011034
2013.06.14 23:07:53 0: Server shutdown
2013.06.14 23:07:53 1: Including fhem.cfg
2013.06.14 23:07:53 3: telnetPort: port 7072 opened
2013.06.14 23:07:53 3: WEB: port 8083 opened
2013.06.14 23:07:53 3: WEBphone: port 8084 opened
2013.06.14 23:07:53 3: WEBtablet: port 8085 opened
2013.06.14 23:07:53 3: Opening CUL_0 device /dev/ttyACM0
2013.06.14 23:07:53 3: Setting CUL_0 baudrate to 9600
2013.06.14 23:07:53 3: CUL_0 device opened
2013.06.14 23:07:53 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.14 23:07:53 1: Including ./log/fhem.save
2013.06.14 23:07:53 0: Server started with 84 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3236 2013-06-01 17:13:50Z rudolfkoenig $, pid 3351)
2013.06.14 23:07:55 1: Including fhem.cfg
2013.06.14 23:07:55 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.
2013.06.14 23:08:23 2: FHT set FHT_Flur desired-temp 16.0
2013.06.14 23:08:27 3: set CUL_0 raw T011034
2013.06.14 23:08:29 0: Server shutdown
2013.06.14 23:08:29 1: Including fhem.cfg
2013.06.14 23:08:29 3: telnetPort: port 7072 opened
2013.06.14 23:08:29 3: WEB: port 8083 opened
2013.06.14 23:08:29 3: WEBphone: port 8084 opened
2013.06.14 23:08:29 3: WEBtablet: port 8085 opened
2013.06.14 23:08:29 3: Opening CUL_0 device /dev/ttyACM0
2013.06.14 23:08:29 3: Setting CUL_0 baudrate to 9600
2013.06.14 23:08:29 3: CUL_0 device opened
2013.06.14 23:08:29 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.14 23:08:30 1: Including ./log/fhem.save
2013.06.14 23:08:30 0: Server started with 84 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3236 2013-06-01 17:13:50Z rudolfkoenig $, pid 3421)
2013.06.14 23:08:31 1: Including fhem.cfg
2013.06.14 23:08:31 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.
2013.06.14 23:08:51 3: set CUL_0 raw T011034
2013.06.14 23:08:57 3: set CUL_0 raw T011034
2013.06.14 23:08:59 2: FHT set FHT_Flur desired-temp 16.0
2013.06.14 23:09:28 3: set CUL_0 raw T011034
2013.06.14 23:10:02 3: set CUL_0 raw T011034
2013.06.14 23:10:02 2: CUL_0: unknown message ? (4442:00A6,0021 4442:0069,A621 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.14 23:10:07 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.06.14 23:10:07 3: Setting CUL_0 baudrate to 9600
2013.06.14 23:10:07 1: /dev/ttyACM0 reappeared (CUL_0)
2013.06.14 23:10:11 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.14 23:16:01 3: set CUL_0 raw T011034
2013.06.14 23:16:06 2: CUL_0: unknown message ? (532F:00A6,0011 3682,FA 58F1:7701,T532F00A60010 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.06.14 23:16:08 2: CUL_0: unknown message 532F:00A6,0011 360E:00A6,0020 360E:0069,A620 E581:AE02,F9 E581:AE82,FA 58F1:7701,2E 58F1:7781,2D 3257:00A6,00FD 0437:00A6,0031 0437:0069,A631 1B61:00A6,00F9 1B61:0069,A6FA 004F:00A6,00FE 004F:0069,A6FE 6024:00A6,002E 4442:00A6,0022 4442:0069,A621
2013.06.14 23:16:14 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.06.14 23:16:14 3: Setting CUL_0 baudrate to 9600
2013.06.14 23:16:14 1: /dev/ttyACM0 reappeared (CUL_0)
2013.06.14 23:16:14 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.14 23:16:20 3: set CUL_0 raw T011034
2013.06.14 23:16:23 0: Server shutdown
2013.06.14 23:16:23 1: Including fhem.cfg
2013.06.14 23:16:23 3: telnetPort: port 7072 opened
2013.06.14 23:16:23 3: WEB: port 8083 opened
2013.06.14 23:16:23 3: WEBphone: port 8084 opened
2013.06.14 23:16:23 3: WEBtablet: port 8085 opened
2013.06.14 23:16:23 3: Opening CUL_0 device /dev/ttyACM0
2013.06.14 23:16:23 3: Setting CUL_0 baudrate to 9600
2013.06.14 23:16:23 3: CUL_0 device opened
2013.06.14 23:16:23 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.06.14 23:16:23 1: Including ./log/fhem.save
2013.06.14 23:16:24 0: Server started with 84 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3236 2013-06-01 17:13:50Z rudolfkoenig $, pid 4112)
2013.06.14 23:16:25 1: Including fhem.cfg
Wenn ich bei mir das presence deaktiviere kommen die Meldungen nicht mehr.
Mit aktiven presence wird echo immer wieder aktiv.
> Wenn ich bei mir das presence deaktiviere kommen die Meldungen nicht mehr.
Danke, das war der entscheidende Hinweis.
Neuerdings schliesst BlockingCall nach dem fork() (auf draengen von justme1968 :) alle seriellen Schnittstellen.
Leider meint die close() Routine aus Device::Serialport zu gut, und restauriert alle Einstellungen.
Ich habe jetzt DevIo.pm und BlockingCall.pm modifiziert, und hoffentlich damit das Problem gefixed.
Workaround (ungetestet): alle PRESENCE Instanzen vor den seriellen Geraeten definieren.
Hallo,
Bei mir hat ein set CUL raw B00 vorerst geholfen. Mein fht geht vorerst wieder.
>Ich habe jetzt DevIo.pm und BlockingCall.pm modifiziert, und hoffentlich damit das Problem gefixed.
Ich habe das mal bei mir eingespielt, funktioniert.
>Workaround (ungetestet): alle PRESENCE Instanzen vor den seriellen Geraeten definieren.[/quote]
Hat hier nicht geholfen.
Zitat von: RudolfIch habe jetzt DevIo.pm und BlockingCall.pm modifiziert, und hoffentlich damit das Problem gefixed.
Habe vor 40 Minuten das Update eingespielt.
Bis jetzt noch keine Fehlermeldungen im Log :)
Kann mich der Sache nur anschließen. Nach dem Update werden wieder alle echos abgeschaltet.
Danke für den Fix!
---------------------------------------------
speed 9600 baud; rows 0; columns 0; 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
---------------------------------------------
Ich muss diesen thread leider wieder aus dem Grab holen. Bei meinem Raspi mit CUL 868 habe ich exakt dieses Problem wieder:
Symptome: Nach einem Rechnerneustart läuft zunächst alles ordnungsgemäß, aber nach kurzer Zeit führt der CUL die Intertechno-Befehle nicht aus und schreit die ganze Nacht "help me!". Die Lott-Rolläden und den Energiemonitor im 868-Band betätigt er komischerweise.
Diagnose: auf der Schnittstelle werden die Echos zunächst nach einem fhem-Neustart ordnungsgemäß deaktiviert:
stty -a < /dev/ttyACM0
speed 38400 baud; rows 0; columns 0; 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
aber nach einiger Zeit wieder aktiviert:
stty -a < /dev/ttyACM0
speed 9600 baud; rows 0; columns 0; 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 = 1; 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 geht der Zirkus los.
Ich kann das wie folgt reproduzieren: sudo fhem Service stop/start --> Zustand 1 (Echos aus)
Wenn ich nun auf der Weboberfläche den room wechsle, springt der Raspi auf Zustand 2 (Echo an)
Mit dem nächsten Intertechno-Befehl, schreit der CUL dann Hilfe, führt den Befehl NICHT aus und macht nichts mehr. Irgendwann (bei einem der nächsten Intertechno-Befehle, die auch nicht ausgeführt werden) setzt er sich zurück und das System läuft normal durch. Es wird auch kein Echo mehr aktiviert. Das Zurücksetzen mit "Normalisieren der Echo-Einstellungen" kann man manchmal (leider klappt das nicht immer) durch aufeinanderfolgendes
set CUL1 T0 0000
set CUL1 raw B00
auslösen.
So, und nun schreie ich mal: "... help me!" :-X
Eben konnte ich das etwas eingrenzen:
Nach einem reboot des Raspi steht das Echo richtig auf off. Bis ich eine Seite (einen room auf der Weboberfläche) aufrufe, auf dem es einen Plot gibt (egal, welchen). Dann springt das echo auf on. Setze ich dann von der fhem-Oberfläche MIT einem Plot den CUL zurück mittels raw B00, dann stellen sich die Echos auf off und bleiben bis zum nächsten reboot auch da.
Setze ich den CUL von einer Seite OHNE Plots aus zurück, werden die Echos auf off gestellt, stellen sich aber wieder auf on, wenn ich auf eine Seite mit einem SVG-Plot wechsle.
Lange Rede, kurzer Sinn: Nach jedem Reboot muss ich auf eine Seite mit SVG-Plots wechseln und set CUL raw B00 machen.
Aber welches Modul mir die Schnittstelle verkehrt setzt, und warum es das nur nach einem reboot tut, weiß ich leider nicht.
Hat sonst niemand Probleme mit dem CUL nach einem reboot?
Ich habe plotfork soeben als Übeltäter ausgemacht. Ein Aktivieren von plotfork bewirkt, dass die Kommunikation mit dem CUL gestört wird. Nochmal zum Verständnis:
* Raspberry mit CUL V3
* reboot des gesamten Raspi (nicht nur shutdown restart)
* FHEM arbeitet zunächst normal.
* Nachdem irgendeine FHEMWEB-Seite mit einem SVG_PLOT aufgerufen wurde, werden die Eigenschaften der USB-Schnittstelle /dev/ttyACM0 derart geändert, dass die Cefehle zum CUL ein lokales Echo bewirken.
* Damit kann der CUL nichts anfangen, das log füllt sich nach mindestens einem Schaltbefehl mit Einträgen der Art:
2014.07.05 12:18:17 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:17 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:17 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:16 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:16 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:16 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:15 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:15 3: CUL1: Unknown code isff0f0000ff0f, help me!
2014.07.05 12:18:14 3: CUL1: Unknown code is0f0000ff0ff0, help me!
2014.07.05 12:18:14 3: CUL1: Unknown code is0f0000ff0fff, help me!
2014.07.05 12:18:14 3: CUL1: Unknown code is0f0000ff0ff0, help me!
2014.07.05 12:18:13 2: IT IODev device didn't answer is command correctly: raw => is0F0000FF0FFF
2014.07.05 12:18:13 2: IT set Ambiente_Treppe off
2014.07.05 12:18:13 3: CUL1: Unknown code is0f0000ff0fff, help me!
2014.07.05 12:18:13 3: CUL1: Unknown code is0f0000ff0fff, help me!
2014.07.05 12:18:13 3: CUL1: Unknown code is0f0000ff0fff, help me!
2014.07.05 12:18:12 2: IT set Ambiente_Treppe on
*Manuelles Abstellen des Echos: "stty < /dev/ttyACM0 -echo" hilft nur so lange, bis wieder eine Seite mit einem Plot angeschaut wird.
*Reset des CUL mittels "set CUL1 raw B00" beseitigt das Problem und sellt das Echo dauerhaft aus. Aber nur dann, wenn der Fehler vorher bereits aufgetreten ist.
Das passiert übrigens auch, wenn plotfork zum Zeitpunkt des reboots disabled war und später von der Weboberfläche aktiviert wird. Der erste Wechsel auf eine Seite mit Plots löst das Problem aus.
Was kann ich tun, um plotfork wieder benutzen zu können? Das hat mir nämlich die timeouts beim Heartbeat des HMLAN-Adapters beseitigt. Kann man die Schnittstelle beim Raspi während des Boot-Prozesses bereits dauerhaft so setzen, dass das echo off bleibt?
Um mein Selbstgespräch hier abschließen zu können: Eben habe ich auf dem Raspi ein "apt-get upgrade" gemacht und seitdem ist das Problem verschwunden. Hätte ich das mal gleich getan... Der war allerdings auch ein großer Service, hat den ganzen Kernel ausgetauscht.
Vielleicht hat ja der nächste was davon.
Und nun doch wieder >:( >:( >:(
Also plotfork ausgemacht, dann geht es. Aber dass sonst keiner die Probleme hat, ist schon merkwürdig. Oder bin ich etwa komplett verkehrt in diesem Unterforum?!
...nein bist du nicht. Gestern habe ich wegen wegen leichter Freezes beim Plotaufbau auch Plotfork aktiviert und nun auch eine Unknown Message vom CUL im Log. Diese Meldung kannte ich bisher gar nicht.
In der FHEMWEB.pm wurde vorgestern plotfork wieder auf 0 gesetzt da es massiv Probleme mit z.B. DbLog gab.
Zitat von: rudolfkoenig am 17 September 2014, 20:56:14
Man sollte mit dem Wort Fehler vorsichtig umgehen, da es Entwickler automatisch in schlechte Laune versetzt.
Die Ursache des Problems mAn ist, dass neuerdings in FHEMWEB plotfork dann greift, falls das Attribut gesetzt ist (auch bei 0, was vorher nicht der Fall gewesen ist, und was vmtl. in deiner Konfiguration der Fall ist).
Nachdem (im neuerdings geforkten Prozess) das Plot erstellt ist, beendet sich das Kindprozess, und die DB-Bibliothek ist der Ansicht, dass die im Kind vom Papa geerbte DB-Verbindung auch im Server zuzumachen ist. Papa-FHEM kann danach nicht mehr mit der DB kommunizieren. Das ein Restaurieren der SVG.pm das Problem behebt, liegt daran, dass mit dem alten SVG.pm plotfork deaktiviert ist, da das Modul sich nicht mehr als "FORKABLE" bewirbt.
Ich habe erstmal das alte plotfork-Verhalten in FHEMWEB restauriert: "attr WEB plotfork 0" schaltet plotfork aus. Man koennte ueberlegen im Kindprozess die Db-Verbindung auf InactiveDestroy zu setzen, das muss aber von jemandem mit DbLog getestet werden, bevor ich es einbaue.
VG
Frank
Danke für den Hinweis. :)