Buffering für CUL

[Peedy]

Hallo Leute,

Ich arbeite gerade an einem Tool, dass mir die Zeiteinstellungen aus eine Konfigdatei situativ auf die FHTs überträgt.
Natürlich werden Werte, welche in den FHTs schon eingestellt sind, nicht noch einmal in den Äther geblasen.
Jedoch fällt trotzdem einiges an Daten an, welche zu übertragen sind.

Jetzt meine Frage:

Puffert FHEM die Daten zur CUL, da diese bekanntlich ja nur 74Bytes als Buffer verfügt, oder muss ich selbst dafür sorgen, dass bei der CUL kein Buffer-overflow passiert?

Bis denne ... Peedy

[Dirk]

Hi Peedy,

das ganze Nennt sich Softbuffer

Gruß
Dirk

[Peedy]

Oh man,

danke für den Gibbs-Klapps! :-))

Bis denne ... Peedy

[rudolfkoenig]

Der Klapps geht voll daneben, da softbuffer nur fuer FHZ aber nicht mehr fuer CUL aktiv ist.
Btw.:
- CUL V1/V2 hat 74 Bytes Puffer, V3&V4 174 Bytes.
- das FHT lazy Attribut verhindert das Aussenden bereits identisch gesetzter Daten.

Softbuffer ist fuer das FHZ noetig, da es bei einer abgebrochener Uebertragung die Daten nicht erneut sendet, und sowas haeufig vorkommt. Das CUL loescht erst die Daten, wenn diese vom FHT bestaetigt wurden. Nachteil: mann kan das CUL Puffer vollstopfen, indem an nicht gepaarte oder nicht erreichbare FHT's Daten sendet. Weiss inzwischen nicht mehr genau, was besser ist.

[Peedy]

Wäre es nicht sinnvoll, den Softbuffer für größere Datenmengen bei den FHTs zu implementieren?
Ich bin sicher nicht der erste, welcher bei einer Änderung z.B. des Anwesenheitsstatus div. Geräte auf einmal ansteuert.

Und das Prob mit nicht gepairten Geräten hatte ich auch schon bei fehlern mit der Kommunikation.
Da wäre doch ein Watchdog mit CUL-cleanup hilfreich, bevor wieder der ganze CUL steht. Bemerkt wird das "fehlen" von FHEM erst dann, wenn es grad gar nicht passt ... Murphy eben.


Naja ... ich werde dann erst mal eine eigene Abfangroutine schreiben müssen ...



Bis denne ... Peter

[Dirk]

Der Klapps geht voll daneben

Mist das Hab ich überlesen. Ich nehme alles Zurück :)

[rudolfkoenig]

>  Wäre es nicht sinnvoll, den Softbuffer für größere Datenmengen bei den FHTs zu implementieren?

Ich meine nicht. Wenn man groessere Datenmengen an FHTs uebermitteln muss (und als erstes sollte das ueberlegt werden), dann sollte man die FHTs gegen was besseres austauschen, weil das vermutlich weniger Kopfschmerzen verursacht, siehe die FHT Eintraege in fhemwiki.

[Peedy]

Das ist Ansichtssache ...

Meiner Ansicht nach "sage" ich FHEM was zu tun ist.
Geht nun von FHEM das Ergebnis über ein Gerät, so sollte hier alles (auch Softbuffering, Abfangen von Gerätespezifischen Un-/Eigenarten) von dem Gerätemodul erledigt werden.

Alles andere würde zu einem "zerfransen" einer modularen Struktur führen.
Auf die Dauer kann sich ein Projekt sehr verwachsen und unübersichtlich werden.

Bis denne ... Peedy

[rudolfkoenig]

>  Meiner Ansicht nach "sage" ich FHEM was zu tun ist.

Nur aus Neugierde: kennst Du das FHT Protokoll _genau_? Ich wollte damit nicht implizieren, dass die FHT Implementation in fhem/CUL perfekt ist, nur dass der Aufwand sich mAn(!) nicht lohnt. Ich habe aber nichts gegen sinnvolle Patches einzuwenden.

[Peedy]

Kenntnisse des FHT-Protokolls sind hierfür nicht von Nöten.

Softbuffer: Array-Variable als Buffer die nach Verfügbarkeit des Restspeichers geleert wird (T03 liefert Restspeicher)
Zombies im Puffer: Puffer auslesen, Inhalt prüfen/korrigieren, CUL reset, Puffer korrigiert zurückschreiben.

... also betrifft es nur das Processing innerhalb des Moduls.


Hasta ... Peedy

[rudolfkoenig]

>  Kenntnisse des FHT-Protokolls sind hierfür nicht von Nöten.

Ich gebe auf.

[Peedy]

Wirf doch nicht so schnell die Flinte ins Korn ... :-))

Was hab ich denn nicht verstanden?
Ich lerne gern dazu! :-)

By the way ... ich hab nochmal die Doku gelesen:

Bei FHT ist doch das attr retrycount beschrieben, mit dem Hinweis, das hierfür der Softbuffer aktiviert sein soll.
Also doch Softbuffer bei FHT alias fhtsoftbuffer?

Bis denne ... Peedy

[rudolfkoenig]

Meiner Ansicht nach ist das FHT Protokoll so fehleranfaellig, dass man es ab eine bestimmte Fehlerrate nicht mehr korrigieren sollte, sondern gleich lassen, entweder die Geraete, oder die massenhafte Uebertragung. Klar ist das _theoretisch_ egal, man kann ja theoretisch auch auf einem C64 einen Internet-Browser haben.

Bitte vor der weiteren Diskussion unbedingt:
- alle FHT80b relevanten fhemwiki Artikel lesen
- mehrere CUL<->FHT Datenuebertragungen per X61 mitverfolgen

> By the way ... ich hab nochmal die Doku gelesen:
Nicht gruendlich: alle softbuffer Attribute sind nur im Zusammenhang mit einem FHZ aktiv.

[Peedy]

Tja, ist dann wohl doch schon 'ne alte Kiste ...
... aber ich hab nun mal den ganzen Haushalt schon ausgerüstet.

was ist deine Meinung zum folgenden Ansatz:
das ich in meinem Util per T03 den Reststand abfrage, ca. 10 Bytes als spare rechne und so dann ein Array bei mir häppchenweise leere?
Natürlich werden Duplikate und bisherig gesetzte Variablen berücksichtigt, um den Traffic auf das notwendigste zu minimieren.

Und ... danke für deine Geduld! :-)


Greets ... Peedy

[rudolfkoenig]

Du bist wirklich zaeh :)

- Das FHZ "vergisst" ein Befehl, falls die FHT-Kommunikation abbricht. Aus diesem Grund wurde softbuffer eingebaut: dieser ueberwacht die ACK's der FHT, und falls nach X Minuten kein ACK, dann sendet es erneut. Als Nebeneffekt ueberwacht auch das Puffer des FHZ, und steckt nur soviel rein, wie moeglich, den Rest speichert es in fhem.
- Beim CUL ist das anders, dieser vergisst (leider?) ein Befehl erst nach einem FHT-ACK, das anfaenglich aktivierte softbuffer war kontraproduktiv, da das gleiche Befehl von fhem immer wieder an das CUL geschickt wurde, deswegen haben wir de das Attribut in CUL.pm einfach rausgenommen. Das dazugehoerige Code ist aber in 11_FHT.pm nach wie vor vorhanden.
- Ich sehe gerade, dass eine CUL-Puffer-Ueberpruefung vorhanden ist, kann mich aber nicht mehr daran erinnern, das selbst gemacht zu haben, und ob es je aktiv war.

Also falls Du was aendern willst, schlage ich vor die notwendigen Attribute (fhtsoftbuffer & minfhtbuffer) in 00_CUL.pm wieder zu aktivieren (oder Du erlaubst die per "global userattr"), und zu testen, welche Probleme fhtsoftbuffer mit einem CUL loest bzw. erzeugt.

Siehe auch FHEM/11_FHT.pm/doSoftBuffer().