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

[Peedy]

Hallo,

> Du bist wirklich zaeh :)
... sagt meine Frau auch immer zu mir ... ;-)

>Siehe auch FHEM/11_FHT.pm/doSoftBuffer().
hab ich schon entdeckt. Trotzdem Danke.

Ich werd sicher demnächst ein paar Versuche machen (auch mit eigener, ausgelagerter Routine).
Dann lass ich nochmal was von mir hören.

Bis denne ... Peedy

[Dietmar63]

Hast du in diesem Zusammenhang etwas fertig gestellt?

[Dietmar63]

Hallo Rudi,

ich habe das Modul Heating_Control geschrieben und wie nicht anders zu erwarten, bekommen wir bei umfangreichen Installationen mit vielen FHT(Gunther) LOVF.
Link

Ich habe diesen Thread gelesen und anschließen aus Neugier "Buffering für CUL" in
11_FHT und 00_CUL eingebaut, so wie es hier im Thread und in anderen Threads für MAX beschrieben wurde.

Ich habe komplett softbuffering für fht-Befehle gewählt, so dass ich immer zunächst den Puffer untersuche,
ob sich schon ein Befehl darin befindet, wenn nicht wird das verfügbar credit geprüft und mit dem Attribut "FHT_necessaryCredit" verglichen. Nur dann wird der FHT-Befehl an das CUL übergeben und 120 Sekunden gewartet wenn im Softbuffer noch weitere Befehle warten.
Nebenbei überschreiben neuere desired-temp Kommandos ältere. So werden viele Befehlsübermittlungen eingespart, wenn Anwender verzweifelt immer neue desired-temps absetzen.

Bei mir läuft das Ganze problemlos - ich habe aber auch nur 2 FHT.
Gunter hat derer 12 und wird bei sich einen Test durchführen.

Darf ich diese Änderung dann einfach einchecken oder wie handhabt ihr das.
Ich habe gesehen, dass du und Martin diese beiden Module geändert habt.

Code in fht:

Code Auswählen Erweitern


    $io->{SOFTBUFFER}{$key} = \%h;
    if($io->{TYPE} eq "CUL") {
       doSoftBufferCUL($io);
    } else {
       doSoftBuffer($io);
    }

...
#####################################
# Check the softwarebuffer and send/resend commands
sub
doSoftBufferCUL($)
{
  my ($io) = @_;

  my $necessaryCredit = AttrVal($io->{NAME}, "FHT_necessaryCredit", 850);
  my $ll              = GetLogLevel($io->{NAME},5);
  my $now             = gettimeofday();
  my $waitTime        = 0;

  # a second command of "desire-temp" overrides a previous one
  my %doppelt  = ();
  foreach my $key (keys %{ $io->{SOFTBUFFER} }) {
     my $h    = $io->{SOFTBUFFER}{$key};
     my $name = $h->{HASH}->{NAME};
     my $cmd  = $h->{CMD};

     if ($cmd =~ /^desired-temp.*/) {
        if (defined( $doppelt{$name}{DESIRED})) {
            my $dkey = $doppelt{$name}{DESIRED};
            Log 2, "FHT_CUL_SendQueueHandler: New $cmd for $name overrides old value in softbuffer!";
            delete($io->{SOFTBUFFER}{$dkey});
        }
        $doppelt{$name}{DESIRED} = $key;
     }
  }

  # is still a command in the buffer
  my ($buffer) = (CommandGet("","$io->{NAME} raw T02") =~ /[^ ]* [^ ]* => (.*)/);
  $waitTime = 30 if ($buffer ne "N/A");

  # check enought credit to avoid LOVF
  if ($waitTime==0) {
      my ($credit10ms) = (CommandGet("","$io->{NAME} credit10ms") =~ /[^ ]* [^ ]* => (.*)/);

      $waitTime = ($necessaryCredit - $credit10ms);
      $waitTime  = 0 if ($waitTime < 0);
      $waitTime += 5 if ($waitTime > 0);   # five credits more, to be sure to have enought credits after wakeup
      if ($waitTime > 0) {
         Log 2, "FHT_CUL_SendQueueHandler: Not enough credit! credit10ms is $credit10ms, but we need $necessaryCredit. Waiting $waitTime seconds.";
      }
  }

  # put first command from softbuffer into CUL buffer
  if ($waitTime==0) {
    foreach my $key (sort keys %{ $io->{SOFTBUFFER} }) {

       my $h    = $io->{SOFTBUFFER}{$key};
       my $name = $h->{HASH}->{NAME};

       IOWrite($h->{HASH}, "04", $h->{ARG});
       Log GetLogLevel($name,2), "FHT set $name $h->{CMD}";

       delete($io->{SOFTBUFFER}{$key});
       $waitTime = 120;                # next command in 115 + 0.5*(last fhtid-nibble 5 Sek.) Sekunden
       last;
    }
  }

  if(keys (%{$io->{SOFTBUFFER}}) && !$io->{SOFTBUFFERTIMER}) {
    $io->{SOFTBUFFERTIMER} = 1;
    InternalTimer($now+$waitTime, "softBufferTimer", $io, 0);
  }
}


 
 

[rudolfkoenig]

Hallo Dietmar, ich habe Probleme mit Deinem Patch:
1. das "alte" doSoftBuffer hat bereits CUL spezifisches Code.
2. auch Dein Code wuerde nur dann funktionieren, wenn beim CUL das Attribut fhtsoftbuffer aktivierbar waere, das ist aber nicht.

>  Darf ich diese Änderung dann einfach einchecken ...

Lieber nicht. Ich moechte die erwaehnten Widersprueche vorher noch klaeren.

[Dietmar63]

@Rudi:

Hallo Dietmar, ich habe Probleme mit Deinem Patch:
 1. das "alte" doSoftBuffer hat bereits CUL spezifisches Code.

Code Auswählen Erweitern

ist im Falle eines CUL nicht aktiv - hast du selbst geschrieben, weiter oben in diesem Thread. Grund war wohl, dass cul und fhz anders funktionieren. Cul versucht immer wieder zu senden und die alte Logik vom fhz hat lt. deiner Aussage mehr Probleme erzeugt als gelöst. Ich sende deshalb immer nur einen Befehl in den Puffer des CUL, warte 120 Sekunden undn sende den nächsten Befehl. Es  wird also alles im FHEM gepuffert.

 2. auch Dein Code wuerde nur dann funktionieren, wenn beim CUL das Attribut fhtsoftbuffer aktivierbar waere, das ist aber nicht.

Code Auswählen Erweitern

00_CUL.pm habe ich auch angepasst - dort ist es nicht viel. Ich habe auf die Veröffentlichhung hier verzichtet.

FHT_necessaryCredit habe ich zusätzlich als Attribut aufgenommen.

define CUL_0 CUL              /dev/ttyACM0@96 1234
attr   CUL_0                  fhtsoftbuffer 1
attr   CUL_0                  FHT_necessaryCredit 800



 > Darf ich diese Änderung dann einfach einchecken ...

 Lieber nicht. Ich moechte die erwaehnten Widersprueche vorher noch klaeren.

Code Auswählen Erweitern

ich hoffe ich konnte die Widersprüche aufklären.
Mit Gunther bin ich noch in der Testphase - er hat 12 fht und noch andere Dinge, die traffic erzeugen.
Die Test haben aus meiner Sicht jetzt aufgedeckt, dass bei ihm viel traffic erzeugt wird, wir aber nicht erkennen können woher der traffic kommt - kann man den traffic irgendwie ins log loggen?


Link

Einchecken werde ich erst dann wenn wir Gunthers Problem gelöst haben.

[Dietmar63]

Gib mir bitte eine kurze Antwort wenn du mit meiner Erklärung einverstanden bist und ob ich dann ggf. einchecken kann.
http://forum.fhem.de/index.php?t=msg&goto=72967&rid=405#msg_72967

[rudolfkoenig]

Ich will es einchecken, aber ich muss es vorher testen/verstehen, und dazu brauche ich mehr Freizeit am Stueck.

[Dietmar63]

Wenn es fertig ist kann ich dir die fertige Version der beiden Module geben.
Ich kann es aber auch selbst machen.

[rudolfkoenig]

>  Wenn es fertig ist kann ich dir die fertige Version der beiden Module geben.

Ich dachte die Patches unten sind komplett.


> Ich kann es aber auch selbst machen.

Ich moechte Aenderungen fuer FHT selbst einchecken. Ich will langsam einfuehren, dass fuer einzelne Module genau ein Author zustaendig ist (und das am besten mit SVN erzwingen). Ich habe auch kein Problem Module abzugeben (siehe CUL_HM oder EnOcean), aber dann komplett.

[Dietmar63]

ok - ich werde dir dann wenn es ok ist, die Änderung als Patch schicken.

Ich bin inzwischen der Meinung, dass die Änderung vielleicht nicht ganz so wichtig ist.
Gunthers Problem mit den FHT gehen vermutlich aus der Mengean FHT, die er betreibt und derer teilweise schlechten Signalstaerken (3 unter -85) zurück.

Den Codeauszug hatte ich zur Verdeutlichung geschickt, damit du beurteilen kannst, ob meine Gedankengänge und Lösungen in Ordnung sind.

Das einchecken hätte ich dann selbst erledigen können.

Ich moechte Aenderungen fuer FHT selbst einchecken. Ich will langsam einfuehren, dass fuer einzelne Module genau ein Author zustaendig ist (und das am besten mit SVN erzwingen). Ich habe auch kein Problem Module abzugeben (siehe CUL_HM oder EnOcean), aber dann komplett.

Ist dann schwierig, wenn bei Änderungen mehr als ein Modul geändert werden muss.

Gibt es denn schon eine Liste mit Modulverantwortlichen?