dummy bei 00_CUL

[martinp876]

Hallo,

für die CUL gibt es das attribut dummy - ich habe im code nicht wirklich gesehen wer es alles nutzt.

Ich würde mir vorstellen, dass , wenn dummy gesetzt ist, alles verarbeitet, aber nicht gesendet wird.
Beim Empfangen (was mir wichtiger wäre) könnte man alles parsen aber dann eben nicht dispatchen. Dann könnte man die CUL also monitor nutzen.

Aktuell ist dummy wohl nur ein dummy-attribut in 00_CUL ohne Bedeutung/Wirkung

Gruss Martin

habe gerade gesehen, dass dummy in fhem.pl genutzt wird - wenn ich es richtig sehe, wird nur das schreiben verhindert. Empfangene messages werden aber weiter gereicht.
das ist ziemlich exakt das Gegenteil eines monitors.
Kann man da etwas machen?

[rudolfkoenig]

Urspruenglich war dummy in CUL, um das Schreiben zu vermeiden. Das ist irgendwie im Laufe der Zeit rausgeflogen, hat aber nicht  gestoert, weil man mit "none" als device de-facto sowas simulieren konnte. Ein komischer Rest->Effekt blieb noch: CUL mit dummy hat per FHEM2FHEM-RAW keine Daten gesendet.

Ich habe IOWrite und Disptach geaendert: mit dummy wird ab sofort weder geschrieben, noch per Dispatch was verteilt. So richtig verstehe ich aber nicht, wieso Letzteres sinnvoll ist: wenn ich debuggen will, kann ich es an einem zweiten FHEM-Instanz.

[rudolfkoenig]

Apropos CUL:

1. wozu ist $hash->{helper}{HMnextTR} gut? Wenn ich es richtig sehe, wird es nicht verwendet.
2. $dmsg .="::$rssi:$name" macht die Duplikat-Erkennung in Dispatch() (CheckDuplicate()) unwirksam. Wozu braucht man RSSI im HM Modul?
3. CUL_XmitLimitCheckHM prueft nicht, wie der Name suggeriert, auf die 1% Grenze, sondern verhindert, dass man in weniger als 100ms einem Sender eine Antwort schickt. Sie laegt sich dabei "aktiv" schlafen, obwohl fuer Verzoegerungen schon im aufrufenden CUL_SendFromQueue ein besseres Mechanismus mit InternalTimer existiert.

[martinp876]

mit einem dummy kann man den funk monitiren, wenn z.B. eine CUNO wieder probleme macht und geprüft wird, ob sie zu langsam - oder timingweise  zu unpräzise ist.
Ein einfacher monitor, den user einbauen können - funktioniert recht gut, wenn die CUL nur nichts weiter sendet.

1) korrekt - kann raus
2) ist mir alles klar. Duplicate-erkennung muss ich eh selbst machen - da kann es auch zu wiederholungen kommen. RSSI anzeige bietet HM auch mehr, das du anzeigst. Die Eerte brauche ich daher - passernd zu der message in CUL_HM  um RSSI komplett auswerten zu kommen. Sollte also so bleiben
3) ist mir auch klar. Deine aussage mit dem Delay wundert mich - hattest du nicht active-wait von permanent 300ms eingebaut oder zugestimmt - was ich dann entfernt habe?
wasich brauch ist ein präzises warten von 100ms. Alles, was in der zwischenzeit passiert versuche ich abzuarbeiten. Wenn ich es mit InternalTimer machen befürchte ich zu grosse schwankungen - das timing kann nicht gehalten werden. So etwas mache ich nur, wenn kleiner 100ms gewartet werden muss.
Sonst verwende ich den internalTimer.

[rudolfkoenig]

RSSI: das kann man in ParseFn auch per $iodev->{RSSI} / $iodev->{NAME} auslesen.

hattest du nicht active-wait von permanent 300ms eingebaut

Ist aber laenger her, und wurde mit CUL_SendFromQueue auf InternalTimer umgebaut.

Wenn ich es mit InternalTimer machen befürchte ich zu grosse schwankungen

Diese Routine selbst wird von InternalTimer aufgerufen.

[justme1968]

hallo martin,

hast du dir schon mal die aktuelle duplikat erkennung mit der fingerprintFn angeschaut?

damit solltest du auch deine sonderfälle wie den hm repeater richtig behandeln können.

gruss
  andre

[martinp876]

Hallo Rudi,

korrekt, ist eine weile her. Ich werde einmal an einem Umbau basteln. Kritisch ist, dass es keine priorität gibt - und mich dann ein anderer Task verdrängen könnte, der kurz vor Ablauf des timer gestartet wird. Ist eine Frage der Wahrscheinlichkeit und des delay.
Ich werden einmal die Präzision und den delay ausmessen, den InternalTimer mit sich bringt. Hast du schon Daten?
Wie ich damals schon anmerkte tun mir aktive delays immer weh...

Aktuell sollte ein typische Wartezeit kleiner 70ms liegen - und wohl im wesentlichen beim verzögern von  ACKs. Nicht bei jeder message - klar.



Hallo Andre,

habe ich nicht - werde ich einmal.
Beachte, dass duplicate nicht immer verworfen werden dürfen. HM-protokol wiederholt messages, wenn der Absender das ACK nicht erhalten hat. Dann muss ggf. das ACK wiederholt werden. Das wird in CUL_HM gemacht (ok, muss ich noch einmal nacharbeiten).
CUL_HM behandelt doppelte messages von repeatern sowie wenn mehrere IOs in betrieb sind. Ein Problemhabe ich dabei nicht.
Dispatch darf doppelte messages nicht verwerfen, da geprüft werden muss, ob das ack wiederholt werden muss. Protokol-definition.
Das wiederholen in das IO device hinunter zu ziehen halte ich für ungünstig.
Ein weiterer Grund, doppelte messages nicht zu verwerfen ist, RSSI zu protokollieren. Auch von repeatern und mehrfach IO-devices. In CUL_HM ist das eingebaut. In HMinfo auch eine tabellarische Darstellung mölich

Doppelte messages zu verwerfen mag für andere Familien ok sein - CUL_HM muss sie sehen.

FingerprintFn habe ich gerade durchgesehen. Könnte ich umbauen. Vorteil besteht wohl darin, dass dispatch nicht falsch zählt. Hmm  stellt sich die Frage, was dispatch eigentlich zählt. MSGCNT würde dann nicht erhöht - obwohl dispatch dies je IODevice darstellt. Gleiches gilt für alle IOdevice related readings. Halte ich für unsauber oder mindestens nicht konsequent.
Auf der anderen seite ist Internal eh überladen. Es wäre eh schön, wenn einige der Variablen aus "internals" 'hidden' wären. <IOdev>_RAWMSG, <IOdev>_MSGCNT,NR mindestens - über TYPE kann man diskutieren. Sagen dem User eh nichts - und Zeilen sind kostbar hier.

- schade, dass generelle parameter wie "Match" im header nicht beschreiben werden.
- warum wird es 2-mal geprüft - in dispatch und in computeClientArray?

Gruss Martin

[justme1968]

der grund den aufruf ein mal auf iodev und ein mal auf client ebene machen zu können ist das es bei manchen protokollen erst nach dem dekodieren der nachricht möglich ist zu entscheiden ob es ein duplikat ist. das dekodieren des protokolls gehört aber in den client und nicht ins iodev. das iodev sollte so 'dumm' wie möglich sein und unterstütz ja potentiell mehr als einen client.

gruss
  andre

[rudolfkoenig]

Ich kann gerne Prio ins InternalTimer einbauen, das hilft aber nur begrenzt, da wir Langlaeufer nicht verdraengen koennen. Wg. delay: ich habe bisher keine Messungen durchgefuehrt, und weiss auch nicht, wie lang im Durchschnitt die Warteschlange ist. Haengt wohl vom Anzahl der Geraete und dem eingesetzten Protokoll ab, bei mir sind es 9xat, 1xFHEMWEB, 1xholiday, 1xwatchdog und 3xHM. Gelistet mit

Code Auswählen Erweitern

{ join("\n", sort map { $intAt{$_}{FN} } keys %intAt) }

Wg. Duplikats-Erkennung: das ist hauptsaechlich fuer den Empfang der gleichen Daten ueber mehrere IODevs gedacht. Wenn die gleichen Daten ueber das gleiche IODev zweimal reinkommen, dann wird das nicht gefiltert.
RSSI wird auch beim Empfang der gleichen Nachricht ueber mehrere Geraete protokolliert, aber nur mit last und nicht mit min/max/avg/last, sow wie HM das macht.

warum wird es 2-mal geprüft - in dispatch und in computeClientArray?

Verstehe die Frage nicht: computeClientArray fuegt es zur Liste hinzu, Dispatch prueft es.

[martinp876]

@andre
klar braucht man mehrere ebenen des parsens. HMLAN bietet deutlich mehr infos (jedenfalls bei HM) als eine CUL. Die Protokoll-Ebene FHEM-HMLAN muss komplett im IODev behandelt werden. Der Message-Inhalt  sollte so gering wie nötig dekodiert werden.
Das gleiche gilt für CUL. Da interface muss identisch - nun zumindest kompatibel - sein.

Ich denke wir stimmen überein hier - so ist es auch realisiert.

@rudi
bei HMLan laufen immer ein paar Messungen mit (um das überleben zu sichern...) Aktuell sieht es bei mir nicht so schlecht aus. Und wenn einer einmal zu spät kommt bricht es auch nicht gleich zusammen. Was ich noch ausmessen werde - vor dem Einbau (oder dem Vorschlag zum Einbau) - ist, wie lange es min dauert, bis der timer wieder zurück kommt ( min latenz).

Wg. Duplikats-Erkennung: das ist hauptsaechlich fuer den Empfang der gleichen Daten ueber mehrere IODevs gedacht. Wenn die gleichen Daten ueber das gleiche IODev zweimal reinkommen, dann wird das nicht gefiltert.
RSSI wird auch beim Empfang der gleichen Nachricht ueber mehrere Geraete protokolliert, aber nur mit last und nicht mit min/max/avg/last, sow wie HM das macht

leider fehlt mir dann die Zuordung für eine Auswertung. Habe ich schon probiert. HM bietet auch RSSI werte aus dem Device - diese kann fhem garnicht auswerten.
Wenn ein repeater eingesetzt werden kann dies fhem nciht unterscheiden. Es wird ein zufallswert ausgegeben. Blöder weise kann es CUL_HM auch nicht korrekt aus "last" lesen, da es bereits überschrieben sein kann. Alles schon probiert (ich baue solche Sachen nicht einfach so ein...)
Für meinen Geschmack ist die Standartauswertung in FHEM ungenügend
- zu wenig info
- keine Repeater differenzierung
- keine Auswertung der device-RSSI werte

Da dies "Familien-spezifische" auswertungen (die Platform KANN die Tiefe nicht leisten) sind habe ich sie in CUL_HM realisiert.
Das ganze ist mehr also nur average/min/max-berechnung (die könnte die Platform schon...)

ich meine diesen Code - habe ich etwas übersehen?
# $Id: fhem.pl 4371 2013-12-13 08:15:43Z rudolfkoenig $
Dispatch($$$)
{
...
  $clientArray = computeClientArray($hash, $module) if(!$clientArray);

  foreach my $m (@{$clientArray}) {
    next if($dmsg !~ m/$modules{$m}{Match}/i);

   
computeClientArray($$)
{
...
        push @a, $m if($modules{$m}{Match});
...
  return \@a;
}
ps - ok, computeClientArray prüft nur das vorhanden sein des MATCH... nicht das MATCH matched

Gruss Martin

[rudolfkoenig]

Ich habe IOWrite und Disptach geaendert: mit dummy wird ab sofort weder geschrieben, noch per Dispatch was verteilt.

Das ist hiermit wieder eingeschraenkt:
Dispatch muss auch Daten von Geraeten, die dummy sind, verteilen koennen, da dies von FHEM2FHEM benutzt wird.
Habe die ueberpruefung aus Dispatch wieder entfernt.

[martinp876]

ok - hätte ich lesen können:
Dummy: empfangen, aber kein senden (seltsame Wortwahl dummy kann empfangen und triggern?)
ignore: keine empfangen oder senden, eingeschränkte sichtbarkeit

sollte man attribute, die allgemeingültig sein sollten auch zentral beschreiben? Dann ist es einfacher den 'Geist' des Attributs zu übernehmen.

einen Monitor-mode gibt es demnach nicht (ok, ausser mir braucht es evtl keiner), und ein ignore auch nicht? Also abschalten des sendens und empfangens?