Empfang in letzter Zeit ohne erkennbaren Grund unzuverlässig.

[Zrrronggg!]

                                                     

Zwischenbericht:

Heute ausführlich Stundenlang zu diversen Tageszeiten diverse
Testscenarien durchgejubelt und den FHT Buffer gequält bis LOVF.

Und was ist? Alles funktioniert BESTENS. Das schlimmste war noch, das
eine FHT Tempänderung mal 6 Minuten gedauert hat.

Mist.



On 19 Jan., 12:49, "Zrrronggg!" wrote:
> Softbuffer ist aus (hatte ich nie an und die Diskussion hier
> mitgelesen. Ich hatte es trotzdem nochmal gecheckt, weil mich das
> Phänomen sofort an die softbuffer Diskussion erinnerte)
>
> Das erstaunliche war, DAS die Änderung umgesetzt wurde! In jedem Fall
> war der buffer heute morgen knack voll, nur noch 4 Bbyte frei, knapp
> an EOB vorbeigeschrammelt.  Minütliches abfragen pber nacht zeigte,
> das über stunden nichts passiert ist. In der ganzen Zeit waren aber
> munter reichlich FHT und FHTTK Meldungen eingetroffen, eine massive
> funktsörung liegt also eher nicht vor.
>
> Irgendwas ist faul aber ich werde jetzt erstmal bischen testen um ein
> klareres Bild zu bekommen, z.b. kann ich das reproduzieren, wenn ja
> wie sieht die Kommunikation dann genau aus, kann ich vielleicht
> einzelne defekte FHTs isolieren etc.
>
> On 19 Jan., 08:56, Rudolf Koenig wrote:
>
>
>
> > > Erstmal Buffer leer gemacht (B00)
>
> > B00 (== reboot) geht auch, nach T01 ist aber der Puffer auch leer.
>
> > > Nur im Buffer steht leider immer noch:
> > > fhem> get CUL1 raw T02
> > > CUL1 raw => 060E:4127
>
> > Ein FHT-Befehl wird erst dann aus dem culfw Puffer entfernt, wenn das FHT die
> > letzte Bestaetigung abgeschickt hat (genannt "end-xmit", siehe auchhttp://fhemwiki.de/index.php/Maximal_nutzbare_Ger%C3%A4te). Meine FHT's setzen
> > die Temperatur nicht um, falls die Uebertragung vorher abbricht.

--
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.

[Zrrronggg!]

                                                     

So,

umfangreiche Tests gemacht.

- das FHT Problem habe ich erstmal ausgeblendet, es ist bisher auch
nicht mehr aufgetaucht, der Puffer leert sich idR. normal.

- ich habe das Verhalten systematisch und mit Logauswertung
untersucht, 1-2 Dinge mögen früheren unsystematischen Beobachtungen
wiedersprechen, da misstraue ich aber eher den alten Beobachtungen.

- das CUL stellt den Empfang sporadisch ein, SENDET in diesen
Situatione aber weiter.

- das Einstellen des Empfang korreliert nicht gut mit der Zeit: alles
zwischen 2 Stunden und über 30 Stunden ist drin. Der Ausfall
korreliert auch nicht mit der Tageszeit.

- wenn das Empfangsproblem akut ist, hilft: FHEM resetten, set raw
B00, set raw X21 (hier schienen frühere eher unsystemtische Versuche
was anderes zu zeigen) Neu abspeichern der Config über die
Weboberfläche hilft auch, jedoch nicht FHEM>rereadcfg. Macht die
Weboberfläche beim Speicher der Config. was anderes als reread?

- Das Phänomen korreliert NICHT mit dem Buffer Füllungsgrad. In der
Regel ist der Buffer sogar leer, manchmal enthält er ein paar
Kommandos (die natürlich ohne Empfang nicht mehr abgearbeitet werden).
Voller Buffer scheint die Wahrscheinlichkeit des Eintritts nicht zu
erhöhen. Auch durch stundelanges Buffer-zumüllen lässt sich der
Zustand nicht erzwingen. Leeren des Buffers bendet die Empfangsstörung
nicht.

- sehr gut korreliert aber der Fequenzwechsel. Über 90% aller
Empfangsstörungen  traten unmittelbar nach einem Frequenzwechsel auf.
Gleichzeitig führt aber nicht JEDER Frequenzwechsel zu der Störung,
insbesondere waren meine Versuche durch wildes Wechseln der Frequenz
per mehrmaligem set CUL1 freq xy den Ausfall zu provozieren erfolglos.

- das Auslösen des folgendesn Scripts erzeugt den Zustand aber so gut
wie immer:

define act_on_Einfahrt_TAST notify Einfahrt_TAST { if ("%" ne "off")
{ fhem("set CUL1 freq 868.80 ;; set tor_sw off ;; set tor_sw on-for-
timer 1 ;; set CUL1 freq 868.35 ;; set tor_sw on-for-timer 1 ;; set
Einfahrt_TAST off ;; set Einfahrt_ZU off ;; set Einfahrt_AUF off") } }

Steht in dem Script irgendwas drin, was besonders bescheuert ist oder
dumm gedacht war von mir?



Nächste Schritte:  CULs tauschen um zu sehen, ob's nur an diesem CUL
liegt.

Vermutlich ist das ganze Thema in CUL Fans besser aufgehoben, ich
weiss aber nicht. ob man das dahin verschieben kann.











On 19 Jan., 21:44, "Zrrronggg!" wrote:
> Zwischenbericht:
>
> Heute ausführlich Stundenlang zu diversen Tageszeiten diverse
> Testscenarien durchgejubelt und den FHT Buffer gequält bis LOVF.
>
> Und was ist? Alles funktioniert BESTENS. Das schlimmste war noch, das
> eine FHT Tempänderung mal 6 Minuten gedauert hat.
>
> Mist.
>
> On 19 Jan., 12:49, "Zrrronggg!" wrote:
>
>
>
> > Softbuffer ist aus (hatte ich nie an und die Diskussion hier
> > mitgelesen. Ich hatte es trotzdem nochmal gecheckt, weil mich das
> > Phänomen sofort an die softbuffer Diskussion erinnerte)
>
> > Das erstaunliche war, DAS die Änderung umgesetzt wurde! In jedem Fall
> > war der buffer heute morgen knack voll, nur noch 4 Bbyte frei, knapp
> > an EOB vorbeigeschrammelt.  Minütliches abfragen pber nacht zeigte,
> > das über stunden nichts passiert ist. In der ganzen Zeit waren aber
> > munter reichlich FHT und FHTTK Meldungen eingetroffen, eine massive
> > funktsörung liegt also eher nicht vor.
>
> > Irgendwas ist faul aber ich werde jetzt erstmal bischen testen um ein
> > klareres Bild zu bekommen, z.b. kann ich das reproduzieren, wenn ja
> > wie sieht die Kommunikation dann genau aus, kann ich vielleicht
> > einzelne defekte FHTs isolieren etc.
>
> > On 19 Jan., 08:56, Rudolf Koenig wrote:
>
> > > > Erstmal Buffer leer gemacht (B00)
>
> > > B00 (== reboot) geht auch, nach T01 ist aber der Puffer auch leer.
>
> > > > Nur im Buffer steht leider immer noch:
> > > > fhem> get CUL1 raw T02
> > > > CUL1 raw => 060E:4127
>
> > > Ein FHT-Befehl wird erst dann aus dem culfw Puffer entfernt, wenn das FHT die
> > > letzte Bestaetigung abgeschickt hat (genannt "end-xmit", siehe auchhttp://fhemwiki.de/index.php/Maximal_nutzbare_Ger%C3%A4te). Meine FHT's setzen
> > > die Temperatur nicht um, falls die Uebertragung vorher abbricht.

--
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.

[rudolfkoenig]

                                                   

> Steht in dem Script irgendwas drin, was besonders bescheuert ist oder
> dumm gedacht war von mir?

Eigentlich war die Frequenzumstellung nicht fuer sowas gedacht. Probleme:

- beim Wechsel werden die Werte in eeprom gespeichert (mit 3
  Schreiboperationen). Das eeprom soll "nur" 100.000 Schreiboperationen
  aushalten.

- Es kann sein, dass eine Umstellung nicht fehlerfrei durchlaeuft, evtl aber
  nur dann wenn man direkt danach was sendet. Um das zu sehen, koennte man die
  CC1101 register dumpen (C99), und die mit einem "normalen" Fall vergleichen.
  Achtung: manche der hinteren Register sind nicht konstant, da sie die
  Ergebnisse der CC1101 internen Feintuning sind nach dem Frequenzwechsel.  Da
  muss man das beruehmte PDF ausgraben und Einzelwerte vergleichen.

Insgesamt moechte ich dieses Modus-Operandi nicht unterstuetzen, lieber
einen zweiten CUL besorgen oder die Bandbreite ausreichend erhoehen.

--
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.

[Zrrronggg!]

                                                     

Okay. Das das ins  eeprom geschrieben wird wusste ich nicht, ich ging
davon aus, dass man das noch extra veranlassen müsse.
Dann werd ich das mal ausbauen und anders lösen.
Obwohl rein aus Neugierde werd ich  mir vielleicht doch die Register
ansehen.



On 22 Jan., 08:10, Rudolf Koenig wrote:
> > Steht in dem Script irgendwas drin, was besonders bescheuert ist oder
> > dumm gedacht war von mir?
>
> Eigentlich war die Frequenzumstellung nicht fuer sowas gedacht. Probleme:
>
> - beim Wechsel werden die Werte in eeprom gespeichert (mit 3
>   Schreiboperationen). Das eeprom soll "nur" 100.000 Schreiboperationen
>   aushalten.
>
> - Es kann sein, dass eine Umstellung nicht fehlerfrei durchlaeuft, evtl aber
>   nur dann wenn man direkt danach was sendet. Um das zu sehen, koennte man die
>   CC1101 register dumpen (C99), und die mit einem "normalen" Fall vergleichen.
>   Achtung: manche der hinteren Register sind nicht konstant, da sie die
>   Ergebnisse der CC1101 internen Feintuning sind nach dem Frequenzwechsel.  Da
>   muss man das beruehmte PDF ausgraben und Einzelwerte vergleichen.
>
> Insgesamt moechte ich dieses Modus-Operandi nicht unterstuetzen, lieber
> einen zweiten CUL besorgen oder die Bandbreite ausreichend erhoehen.

--
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.