wer weiss wie die VCCU ihre IOList behandelt ?

[Wzut]

als alter MAX User (und nun auch noch Maintainer) habe ich schon lange neidisch die VCCU bewundert mit ihrer Fähigkeit der IOList.
Ich würde gerne das eine oder andere bei MAX nachbilden, aber dazu müsste ich besser verstehen wie die VCCU tatsächlich mit ihren Multi IOs umgeht,
denn ich befürchte das ich (bzw. auch andere User) vllt. da etwas ableiten was mehr Wunschdenken als Realität ist. Mein erster Versuch war natürlich ein Blick ins Modul, aber ich habe z.Z. genug damit zu tun die internen Abläufe MAX Module zu verstehen, da muss ich nicht noch ein HM Guru werden

Also konkret jetzt :
Empfang : Gibt es mehr als ein IO sorgt FHEM ja mittels attr global dupTimeout ja schon selbst dafür das nicht ein und das selbe Packet mittels Dispatch an das Client Modul weitergegeben wird. Soweit ok, aber was wenn das zweite nun verworfene Paket den deutlich besseren RSSI Wert hat ? Berücksichtigt das die VCC bei einem nachfolgenden Senden ja oder nein ? wenn ja : wie kommt sie an diesen von fhem.pl unterdrückten Wert ?

Senden : Schickt die VCCU ein Paket gleichzeitig oder mit zeitlichem Abstand an alle IOs die in IOList stehen ?
Bzw. wird hier eine Unterschied gemacht in Verbindung mit den eigentlichen Device Parametern IODev & IOgrp ?
Gerade das Verhalten von  IODev & IOgrp und deren möglichen Schreibweisen (VCCU alleine bzw. VCCU:CUL) war mir schon immer unklar.

[justme1968]

nur kurz zum verwerfen von doppelten paketen: die routinen die entscheiden ob ein paket verworfen werden soll wird für jedes empfangene paket einzeln aufgerufen und die entscheidung wird nur auf grund des gerade aktuellen pakets getroffen.

d.h. wenn ein paket kommt und akzeptiert wird bleibt nichts anderes übrig als alle danach zu verwerfen wenn man keine duplikate erzeugen möchte.

rein theoretisch könnte man sich die pakete vermutlich in der fingerprintFn merken, immer verwerfen zurück melden und nach zeit x das beste von hand weiter verarbeiten.

normalerweise sollten die daten in der luft aber über eine checksume gesichert sein und pakete mit besserem rssi enthalten keine besseren oder mehr daten. wenn die prüfsumme stimmt sind dir daten valide. egal wie schlecht der rssi ist. kaputte daten werden schon vor der duplikat prüfung verworfen. ich gehe davon aus das dies auch bei max so ist.

zum senden: hm sendet über das bevorzugte io oder wenn keines als bevorzugt eingetragen ist über das mit dem besten empfangs rssi.

gleichzeitig senden ist glaube ich keine gute idee. die signale würden sich gegenseitig stören.

für fs20 gibt es noch einen sendpool um  das senden bzw. nicht gleichzeitig senden zu managen. ich erinnere mich aber nicht mehr an die details

ansonsten ist hm nicht unbedingt immer das beste beispiel weil einiges (mit gutem grund oder nicht) an der fhem infrastruktur vorbei in einer eigenen implementierung gemacht wird.

aber dazu kann martin mehr sagen.

[Wzut]

@Andre, THX j,mit dupTimeout habe ich gespielt und hatte auch extra Log Ausgaben drin. Die default 0.5 Sekunden sind absolut ausreichend bei meinen zwei USB CULs,
ich musste da bis auf 0.01 Sekunden runtergehen damit ein Paket nicht mehr als doppel erkannt wird, d.h. passt so schon. Wenn es aber mal USB/LAN oder gar WLAN/LAN wird könnten die 0.5 Sekunden zu kurz sein, mal schauen bis ich soweit bin das zu testen. Und ja eine simple Prüfung der Pakete gibt es auch bei MAX.

Über den Sendpool hatte ich mich auch schlau gemacht, (Stichwort Palm-Beach Resort Effekt) kommt aber bei MAX nicht zum Zug, u.a. weil ich auch nicht vorhabe gleichzeit über mehr als einem IO Pakete raus zuhauen.
   

[Otto123]

Zum Empfang bei HM und rssi hat Frank letztens das gesagt: https://forum.fhem.de/index.php/topic,106432.msg1003179.html#msg1003179
Zum senden bei HM habe ich das schon genauso beobachtet wie André sagt: Einer sendet, empfangen tun alle. Der Eintrag IOgrp ist für das senden der VCCU verantwortlich, gibt es den nicht, sendet die VCCU nicht.

[Wzut]

Otto , die von dir verlinkte Aussage von Frank ist mir da nicht genau genug. In 00_CUL wird u.a. für MAX der aktuelle RSSI Wert an die dmsg mittels addvals angepappt und Dispatch liefert aus (in dem Fall an 14_CUL_MAX) dort kann ich den Wert ja verwursteln. Mir geht es aber um Pakete die vllt. einen besseren RSSI Wert gehabt hätten, es aber nie zu Dispatch geschafft haben weil sie als Zwilling verworfen wurden.
 

Zum senden bei HM habe ich das schon genauso beobachtet wie André sagt: Einer sendet, empfangen tun alle. Der Eintrag IOgrp ist für das senden der VCCU verantwortlich, gibt es den nicht, sendet die VCCU nicht.

das Thema "alle empfangen" habe ich IMHO schon fast gut umsetzen können. OK , kein Eintrag - kein senden, soweit auch verstanden.

[frank]

ist es wirklich wichtig, die rssi der dupes zu kennen?

ich behaupte jetzt mal, dass die "bessere" msg als erstes in fhem eintrudelt. besser bedeutet eine kombination aus rssi und latenz.

bei vergleichbaren latenzen wird der bessere rssi gewinnen, da dieser sicherlich auch eine kürzere funkstrecke hatte.

bei gleichem abstand zweier io zum device aber deutlichen latenzunterschieden, zb einer über wlan an fhem angebunden, gewinnt die kleinere latenz.

schlecht abschneiden könnte eine msg, die nahe dem wlan io empfangen wird (sehr guter rssi), wenn ein zweites io mit deutlich besserer latenz die selbe msg mit sehr viel schlechterem rssi empfängt.
aber in solchen fällen hilft ja zb ein prefered io.

wie gesagt, nur behauptungen. so ein test wäre aber interessant. 

edit: mir fällt gerade ein, dass die selben messages aber durch unterschiedliche io empfangen auch separat für jedes io gezählt werden. dupes sind dann scheinbar "echte" wiederholungen der original msg. zumindestens bei homematic.

[Wzut]

@frank , THX
was den Test mit verschieden IO Typen betrifft (USB/LAN), da bin ich auch gespannt vllt. komme ich ja die Tage dazu das mal zu machen.
Aber ich sehe in meinen Logs gerade das ich unter Umständen doch gedanklich auf dem Holzweg bin

mir fällt gerade ein, dass die selben messages aber durch unterschiedliche io empfangen auch separat für jedes io gezählt werden

Bingo , ich sehe zweimal <dev>_MSGCNT, RAWMSG,RSSI & TIME und RAWMSG & TIME sind identisch ! D.h. obwohl garantiert eine durch dupTimeout unterdrückt wurde, hat  00_CUL doch beide im Clients Device verewigt (aber Parse wurde  zu der Zeit nicht zweimal aufgerufen) , ergo habe ja bereits den besseren RSSI Wert

[Wzut]

ist es wirklich wichtig, die rssi der dupes zu kennen?

ich behaupte jetzt mal, dass die "bessere" msg als erstes in fhem eintrudelt. besser bedeutet eine kombination aus rssi und latenz.

- IMHO ja
- Beispiel , CUL ist ein USB Device , CUL2 ein Cube via LAN
bei allen Geräten ist USB immer zuerst da und bei den meisten Geräten hat der USB CUL auch den besseren RSSI Wert, aber es gibt bei mir zwei sehr weit entfernte Geräte die über USB grottenschlechte Werte haben (< -95 und auch entsprechend viele Wiederholungen) aber sehr gute via dem LAN  Cube ( > -47 mit fast keinen Wiederholungen) Wenn ich nun die Wahl habe zu einem dieser zwei etwas zu senden dann bevorzuge ich den LAN Weg.
Seit der heutigen 00_CUL.pm habe ich nun die Werte zum vergleichen auch wenn sie später durchs dupTimeout Raster fallen.       

[justme1968]

rssi hat nichts mit dem empfangszeitpunkt zu tun. und ist noch nicht mal 1:1 zwischen unterschiedlichen systemen vergleichbar.

prinzipiell wertet fhem die erste korrekt empfangene nachricht aus. unabhängig vom rssi wert.  das ist auch ok so. auf eine eine ebenfalls vollständige nachricht mit besserem rssi wert zu warten bringt nichts. das verzögert nur die reaktion. und dir daten sind nicht besser.

je nach protokoll und io ist das sogar kontraproduktiv. ein hm lan sendet z.b. selbständig ein ack. wenn fhem auf ein späteres signal mit einem eigenen ack reagieren würde kommt auch das in die quere.


ja rssi ist eine gute info um empfangsprobleme zu diagnostizieren und zu beheben.

daran festzumachen welches signal man auswertet bring aber nichts. das ,bessere' signal enthält nicht mehr informationen. immer vorausgesetzt das protokoll ist vernünftig per crc abgesichert.

das ist so wie der hifi voodoo mit besonderen kabeln für digitale signale. die daten sind entweder da oder nicht. wenn sie da sind ist alles ok. egal wie schlecht der rssi wert ist. wenn sie nicht da sind hilft der rssi wert eventuell die aufstellung zu verbessern.

[Wzut]

auf eine eine ebenfalls vollständige nachricht mit besserem rssi wert zu warten bringt nichts.

das tue ich auch nicht und habe es auch nicht vor.
Mir geht es darum wenn zu einem späteren Zeitpunkt X die Zentrale etwas an das Gerät senden möchte, dann kam sie :
a. einfach mit allen IOs senden
b. nur das eine IO verwendetn das sich der User zuvor mittels Attribut ausgesucht hat
c. oder halt nachschauen wie den die Empfangsverhältnisse zuletzt waren und das IO selbständig wählen.

und genau dieser Punkt c ist es warum ich eigentlich diesen Thread aufgemacht hatte, weil ich hoffte zu erfahren wie die VCCU das macht.
Aber da martinp876 schweigt wird es wohl (s)ein Geheimniss bleiben, schade 

[justme1968]

meine antwort war auch für frank gedacht

ja. beim senden ist es in der tat sinnvoller.

mit allen gleichzeitig senden ist glaube ich keine gute idee. du kommst dir selber in die quere. das geht nur nacheinander.

ich meine die vccu nimmt das beste bzw. das bevorzugte wenn angegeben.