Hexadecimal number > 0xffffffff non-portable

Begonnen von Dr. Boris Neubert, 09 Oktober 2010, 14:59:02

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

                                             

Hallo,

im fhem.log finde ich ab und zu folgende Meldung:

2010.10.09 04:48:17 3: Watchdog watchdog.1.wc.hzg triggered
2010.10.09 04:48:17 2: FHT set 1.wc.hzg report2 255
2010.10.09 04:52:17 2: FHT set 1.wc.hzg report2 255
2010.10.09 04:56:17 2: FHT set 1.wc.hzg report2 255
Hexadecimal number > 0xffffffff non-portable at
/data/Homeautomation/fhem/FHEM/11_FHT.pm line 633.
2010.10.09 05:09:17 2: FHT set 1.wc.hzg report2 255
2010.10.09 05:09:17 2: CUN: unknown message EOB
2010.10.09 05:13:17 2: 1.wc.hzg set report2 255: no confirmation after 4
tries, giving up

Es scheint nicht gefährlich zu sein, aber vielleicht deutet es auf ein
Problem in der culfw hin, das wir besser fixen.

Der watchdog

define watchdog.1.wc.hzg watchdog 1.wc.hzg 00:15:00 SAME set 1.wc.hzg
report2 255

wird ausgelöst, wenn vom FHT80b namens 1.wc.hzg 15 Minuten lang keine
Meldung gehört wurde. Empfänger ist ein CUN mit    

attr CUN fhtsoftbuffer 1.

perl ist  v5.10.0 built for x86_64-linux-thread-multi.

Die beanstandete Code-Stelle ist in getFhtBuffer:

  for(;;) {
    my $msg = CallFn($io->{NAME}, "GetFn", $io, (" ", "fhtbuf"));
    Log 5, "getFhtBuffer: $count $msg";
    return hex($1) if($msg && $msg =~ m/=> ([0-9A-F]+)$/i);        #
<--- hier 633
    return 0 if($count++ >= 5);
  }

Ich protokolliere mal mit, was da kommt, indem ich Log 5 durch Log 1
ersetze.

Grüße,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

                                                   

> Ich protokolliere mal mit, was da kommt, indem ich Log 5 durch Log 1
> ersetze.

Danke, das wuerde mir evtl. erklaeren wieso das passieren kann. Ich kriege
naemlich erst mit
  perl -e "use warnings; print hex('fffffffff')"
(9 mal f) die besagte Fehlermeldung, und die Ausgaberoutine in culfw wird mit
einem uint8_t Parameter definiert.

Trotzdem: es kann z.Zt passieren, dass dieser Wert negativ wird wenn der fht
Puffer voll ist, ich habe deswegen in culfw/clib/fht.c eine zusaetzliche
Pruefung eingebaut.
Das obige Problem sollte auch dann nicht auftreten, wenn man in fhem
  "attr CUL minfhtbuffer 1" setzt.

Hast Du FHTBUF_SIZE in Devices/CU*/board.h modifiziert?

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Dr. Boris Neubert

                                             

Hallo,

nachdem ich logge, was in getFHTbuf passiert, sieht man folgendes:

2010.10.10 01:27:01 1: getFhtBuffer: 0   fhtbuf => 04
2010.10.10 01:27:31 1: getFhtBuffer: 0   fhtbuf => 04
2010.10.10 01:28:01 1: getFhtBuffer: 0   fhtbuf => T5F4A00A0001104
2010.10.10 01:28:01 1: getFhtBuffer: 1   fhtbuf => 04
2010.10.10 01:28:31 1: getFhtBuffer: 0   fhtbuf => 04

2010.10.10 05:18:07 1: getFhtBuffer: 0   fhtbuf => 04[NUL][NUL]ë[~u010

2010.10.10 05:53:08 1: getFhtBuffer: 0   fhtbuf => 04
2010.10.10 05:53:38 1: getFhtBuffer: 0   fhtbuf => 04
2010.10.10 05:54:08 1: getFhtBuffer: 0   fhtbuf => T145300AA00EC04
2010.10.10 05:54:08 1: getFhtBuffer: 1   fhtbuf => 04
2010.10.10 05:54:38 1: getFhtBuffer: 0   fhtbuf => 04

getFhtBuffer frisst also manchmal die von CUN weitergeleiteten
Datagramme auf. Wenn diese mit F beginnen, handelt es sich um
Hex-Zahlen, die vom Code in gehtFHTbuf als Hex-Zahl ausgewertet werden
sollen und dann zu einer zu grossen Hex-Zahl fuehren.

Gruesse,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

                                             

Am 10.10.2010 08:44, schrieb Rudolf Koenig:
>> Ich protokolliere mal mit, was da kommt, indem ich Log 5 durch Log 1
>> ersetze.
>
> Danke, das wuerde mir evtl. erklaeren wieso das passieren kann. Ich kriege
> naemlich erst mit
>    perl -e "use warnings; print hex('fffffffff')"
> (9 mal f) die besagte Fehlermeldung, und die Ausgaberoutine in culfw wird mit
> einem uint8_t Parameter definiert.

siehe anderes Posting.

> Hast Du FHTBUF_SIZE in Devices/CU*/board.h modifiziert?

nein, plain vanilla firmware!

Gruesse,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!