meine vds haben alle fw 2.0.
Hmm, jetzt weiss ich natürlich noch nicht, ob nur das ACK nicht vom CUL empfangen wurde.
da bin ich mit 3 unterschiedlichen io, sicher im vorteil. im internal LASTInputDev vom vd habe ich bisher den cul zb noch nicht gesehen, aber hmuart und hmlan. die latenz zum cul über usb vermute ich daher mal deutlich grösser.
@mgernoth ermittelt zb für den hmuart im HMUARTLGW modul alle 15s ein "roundtrip delay", um msgs nicht zu früh zu senden. mein hmuart, der im pi auf dem gpio steckt, zeigt hier ziehmlich konstant knapp 3ms. über lan angebundene hmuarts liegen da so um 6-7ms. für über usb angebundene hmuarts habe ich noch keine daten gesehen.
die latenz des jeweiligen io sehe ich näherungsweise bei halbem roundtrip delay.
Die Frage die mich beschäftigt, ist, wie geht es bei mehr Misses am Besten weiter.
Für einen Shift des Sendeintervalls spricht übrigens rein technisch prinzipiell noch, dass das Intervall nur von den 2 unteren Bytes der HMID bestimmt wird. Wenn zwei TCs mit gleichen 2 unteren Bytes in der HMID in Reichweite eines VDs wären, dann würden sie immer mal wieder langsam (je nach Uhrunterschied) gegenseitigstörend "aneinander vorbei ziehen" können. Gleiches gilt für andere regelmäßig sendende devices, wie Temperatursensoren mit gleichen unteren 2 Bytes. Unter der Betrachtung wäre es sinnvoll, wenn ein TC bei fehlenden Acks sein Sendeintervall verschieben würde.
nach meinen beobachtungen sind die letzten 2 stellen der 6-stelligen hmid in der regel unterschiedlich, wenn man gleiche devices zusammen kauft. am extremsten sieht es bei mir bei einem 3er pack sec-sd aus: 52BB90,52BB9D,52C4DF.
"überholungen" habe ich aber auch schon bemerkt, haben bei mir aber (bisher?) keine probleme gemacht. ich habe aber noch einen hinweis von dir an martin im ohr, der hier eventuell passt:
Edit: Ich habe gerade gesehen, dass Du Zeile 426 gelöscht (virtThSens sollten damit wieder laufen) aber nicht nach if ($hash->{helper}{fkt} eq "vdCtrl"){ umgezogen hast. Eventuell erzeugt das mal ein Problem mit zwei laufenden Timern für einen vdCtrl. Das hängt davon ab, ob der erste set für den vdCtrl vor der ersten Ausführung von CUL_HM_valvePosUpdt ausgeführt wird oder werden kann.
allerdings sind es ja immer auch batteriegeräte, die ihren zyklus erst beim einlegen der batterie starten, wodurch sie erst einmal eigentlich nicht zu dicht bei einander liegen sollten. auszuschliessen ist es natürlich nicht.
für ein shift zur "entzerrung", um solche möglichen kollisionen zu umgehen, wäre sicherlich nach einem lost ein guter zeitpunkt. da ist der vd ziehmlich lange wach, vielleicht 10 min, aber jetzt nur geraten.
meine misses, egal von welchem io, sind, geschätzt zu 98%, immer einzelne misses. das darauf folgende meeting ist also in der regel wieder erfolgreich.
die ursache hierfür sehe ich als "zufällig und kurzzeitig" an. zb: fhem freezes, funkkollisionen, verlorene funkmessages durch externe störungen, sendeverzögerungen durch nicht systematische serverdelays, .... .
"ständig wechselnde" shifts von meeting zu meeting bei aufeinander folgenden misses halte ich daher für nicht so zielführend.
die verbleibenden 2% misses sind da schon interessanter.
davon sind die meisten 2-fache misses. je mehr misses aufeinander folgen, desto seltener. am seltensten sind fehler von miss_1 bis lost.
das schlechteste scenario ist sicherlich, wenn der vd sich bei einer zufällig verzögerten msg, die garade noch ins fenster trifft, synchronisiert und das ack nicht in fhem ankommt. je grösser das fenster zu diesem meeting war, um so fataler das ergebnis.
im letzten versuch vor lost könnte man vielleicht noch versuchen, die msg mehrfach zu senden. so eine art "streufeuer".
ein echter tc kann bis zu 4 vd betreiben, muss also auch damit klar kommen.
apropo "sinn der ack vom vd": der tc zeigt im display funkstörungen zu den vd an, wenn die acks zu lange ausbleiben. wenn zur vollen stunde eine funkstörung zu einem vd vorliegt, piept er sogar ein paar mal.
ps: ich habe gerade festgestellt, dass es auch noch ein bug geben muss, siehe screenshot.
der letzte miss_1 ist viel zu lang, fast 5min. eventuell wird hier der miss zähler nicht auf 2 gestellt. das scheint auch häufiger zu passieren.
gruss frank
