FHT softbuf

[Guest]

Originally posted by: <email address deleted>

Tag zusammen,

mir ist gerade FHEM abgestürzt, weil wohl der Buffer für FHT voll war
(CUL: unknown message EOB). In der Doku steht, dass man deswegen einen
fhtsoftbuf einbauen kann. Allerdings steht das Attribut bei FHZ, die
ich aber nicht habe. Muss die FHZ ein Hardware Gerät sein - oder muss
das Attribut an der CUL stehen? Ich stehe gerade etwas auf dem
Schlauch

Vielen Dank,
Matthias

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> mir ist gerade FHEM abgestürzt, weil wohl der Buffer für FHT voll war
> (CUL: unknown message EOB).

Wenn das stimmt, dann waere das ein Bug. Bist Du _sicher_, dass fhem deswegen
abgestuertzt ist? Wenn ja, dann haette ich gerne eine genauere Fehlermeldung.


> In der Doku steht, dass man deswegen einen fhtsoftbuf einbauen kann.

fhtsoftbuffer war eine Zeit lang fuer das CUL aktiv, ich habs aber
ausgebaut, da es da eher schaedlich als nuetzlich ist:
- das CUL entfernt (im gegensatz zum FHZ) FHT Befehle nicht aus seinem Puffer
- fhtsoftbuffer schickt die Befehle nochmal los, wenn diese nach eine Weile
  noch nicht vom FHT bestaetigt wurden.
D.h. wenn Du mit aktivierten fhtsoftbuffer ein Befehl sendest, und das FHT die
Daten nicht schnell genug bestaetigt, dann landet das Befehl 3-mal im CUL
Puffer.

Nachteil der Ausbau: mehr als 34 (unbestaetigte) Befehle kann man nicht im CUL
Puffer halten.  Hier wuerde helfen, Einzelbefehle zusammenzufassen (set myfht
cmd1 arg1 cmd2 arg2 ... cmd8 arg8, damit kann man bis zu 72 Befehle aussenden),
oder darueber nachdenken, ob wirklich so viele Befehle notwendig sind. Oder Du
sendest an nicht angelernte FHTs Kommandos.  Siehe auch get CUL raw T02 bzw.
fhemwiki.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Rudi,

eine genaue Fehlermeldung steht leider nicht im Log. Es war nur so,
dass das Web Interface sowie das Socket nicht mehr erreichbar waren.
Nach ein paar Minuten habe ich es nochmal probiert, da ging es
seltsamerweise wieder. Ich habe dann mal ein get für den FHT Buffer
abgesetzt, worauf ich 01 zurück bekam.

Vielleicht ist tatsächlich die Kopplung zwischen CUL und FHT verloren
gegangen. Ich probiere das mal.

Vielen Dank,
Matthias

On 20 Jan., 14:03, Rudolf Koenig wrote:
> > mir ist gerade FHEM abgest rzt, weil wohl der Buffer f r FHT voll war
> > (CUL: unknown message EOB).
>
> Wenn das stimmt, dann waere das ein Bug. Bist Du _sicher_, dass fhem deswegen
> abgestuertzt ist? Wenn ja, dann haette ich gerne eine genauere Fehlermeldung.
>
> > In der Doku steht, dass man deswegen einen fhtsoftbuf einbauen kann.
>
> fhtsoftbuffer war eine Zeit lang fuer das CUL aktiv, ich habs aber
> ausgebaut, da es da eher schaedlich als nuetzlich ist:
> - das CUL entfernt (im gegensatz zum FHZ) FHT Befehle nicht aus seinem Puffer
> - fhtsoftbuffer schickt die Befehle nochmal los, wenn diese nach eine Weile
>   noch nicht vom FHT bestaetigt wurden.
> D.h. wenn Du mit aktivierten fhtsoftbuffer ein Befehl sendest, und das FHT die
> Daten nicht schnell genug bestaetigt, dann landet das Befehl 3-mal im CUL
> Puffer.
>
> Nachteil der Ausbau: mehr als 34 (unbestaetigte) Befehle kann man nicht im CUL
> Puffer halten.  Hier wuerde helfen, Einzelbefehle zusammenzufassen (set myfht
> cmd1 arg1 cmd2 arg2 ... cmd8 arg8, damit kann man bis zu 72 Befehle aussenden),
> oder darueber nachdenken, ob wirklich so viele Befehle notwendig sind. Oder Du
> sendest an nicht angelernte FHTs Kommandos.  Siehe auch get CUL raw T02 bzw.
> fhemwiki.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com