HM virtual CCU

[martinp876]

macht es vieleicht auch Sinn, IODevs mit "schlechter" RSSI (konfigurierbar, default um 80?) komplett auszulassen?

warum? Wenn das der beste Empfangswert ist muss man es nehmen - garnicht senden ist nicht wirklich eine option.

Was passiert, wenn kein IODev mit leerer/kurzer queue da ist?

das mit der Q habe ich gerade entfernt (war unklar?)

Verbessern könnte man in der Tat, wenn kein IO ausgewählt werden kann, eine neue Q zu ertellen (in der vccu). Das macht aber nur begrenzt sinn (wie es aktuell schon bei IOs passiert). Sollte kein IO lange Zeit nicht zu Verfügung stehen darf man m.E. nicht mehr senden. Es könnte sonst passieren, dass alte schaltkommandos, die Minuten, Stunden oder länger nicht gesendet wurden plötzlich ausgeführt werden.

[geek]

warum? Wenn das der beste Empfangswert ist muss man es nehmen - garnicht senden ist nicht wirklich eine option.

Wenn die Empfangsqualität volkommen unzureichend ist, braucht man nicht senden. Erzeugt nur Funklast und treibt ggf. den nächsten HMLAN in einen overload (worst-case). Klar, normal heißt "unzureichend" überhaupt kein Empfang. In der Praxis scheitert das aber auch schon vorher. Mit einem entsprechenden Grenzwert ließe sich das je nach Situation optimieren.

das mit der Q habe ich gerade entfernt (war unklar?)

Hab erst nach Lesen des Diffs kapiert, daß die Queuelänge nun überhaupt keine Rolle mehr spielt. Für meine Situation (mehrere HMLANs ausschließlich für Reichweitenverlängerung) ist das perfekt - ebenso bei failover. Lastverteilung (wenn sie denn vorgesehen ist/war) fällt so aber weg, oder?

Rainer

[hexenmeister]

Zum thema queue und resend. Es ist in der tat nicht einfach. Manche befehle machen nur kurzfristig einen sinn, andere sind stundenlang gültig. Das weiß fhem aber nicht. Evtl. pro device konfigurierbar machen? Oder ein grenzwert als komprpmiss? Sagen wir eine Minute? Nur ein Vorschlag 

[geek]

BTW: muß Zeile 6643 nicht auch auf XmitOpen != 1 pruefen?

also... statt:
          || InternalVal($iom,"XmitOpen",1) == 0){# HMLAN/HMUSB?
etwa:
          || InternalVal($iom,"XmitOpen",1) != 1 ){# HMLAN/HMUSB?

sonst kommen die Daten doch nicht bei deiner Änderung in CUL_HM_sndIfOpen an, oder?

Rainer

[martinp876]

nun - die meisten meiner Devices empfangen auch noch bei -90dB. Manche haben Probleme - evtl sogar schon früher. Einen harten Pegel werde ich also nicht vorgeben.
Ob es wirklich viel Funklast erzeugt - evtl in machen anwendungen.
Ich könnte mir einen Parameter in der vccu vorstellen, der eine min-rssi festlegt - für alle Devices. Zu beachten ist, dass es doch etwas komplex ist.
1) berücksichtigt wird ausschließlich der letzte rssi-Wert. Wenn der nicht passt wird nicht gesendet.
2) der rssi-wert wird beim prefered-io ignoriert
3) wenn kein IO gefunden wird (zu schlechte IO) wird nicht gesendet
=> so etwa? Zu komplex sollte es nicht werden, es wird sehr oft ausgeführt.
das mit XmitOpen ist so schon korrekt. Du vergisst CUL (kein XmitOpen) und die Änderung in 00_HMLAN

Das resend von device abkängig machen halte ich für ungenügend. Richtig ist, dass es kommandos gibt, die irgendwann ausgeführt werden sollten und andere nicht. Das hängt m.E. nicht nur am Device sondern am Channel (der ist an der stelle nicht bekannt) und am Kommando.
In jeden Fall (auch hier) sollte der User die Protokoll-readings beachten. Er könnte ein notify erstellen und hier seine Aktionen selbst festlegen. Nachdenken kann man darüber, dem User die gelöschten Messages zugänglich zu machen. Dann kann er es wieder abschicken - das könnte man aufbereiten...

[geek]

nun - die meisten meiner Devices empfangen auch noch bei -90dB. Manche haben Probleme - evtl sogar schon früher. Einen harten Pegel werde ich also nicht vorgeben.

Klar, deswegen die Idee, das optional zu machen. Inzwischen zweifel ich aber auch an dem Sinn. Denn irgendwie hast du Recht. Das ist viel Komplexität und neue Fehlerquellen nur für nen Sonderfall.

Lass erstmal schauen, wie sich die heutigen Änderungen bewähren. Bisher sieht's gut aus.

Wird der RSSI Wert eigentlich gelöscht wenn ein Device an nem IO nicht mehr zu sehen ist? Könnte zu interessantem Verhalten führen wenn ein Device bewegt wird und am neuen IO immer noch ne schlechtere RSSI hat als am alten. Ok auch n Sonderfall. Fällt mir auch nich ein, wie man das behandeln kann. Denke, das bringt einen auch nicht um wenn man's weiß.

das mit XmitOpen ist so schon korrekt. Du vergisst CUL (kein XmitOpen) und die Änderung in 00_HMLAN

Ich Ahne was du meinst.

Danke für die Änderung und die Nachhilfe
Rainer

[automatisierer]

Das Update von Heute hat bei mir keine wesentliche Änderung gebracht, aber ich hab mal den hmLanQlen auf 3 gestellt. Damit klappts nun ganz gut, alle Devices haben den pref IO in den internals stehen und es gibt keine Missing ACK, ich werds mal weiter beobacheten.
Vielleicht wäre es sinvoller den queuewert der VCCU veränderbar zu machen, der bestimmt ab welcher queue länge die VCCU sendeaufträge an ein anderes IOdev oder auch nicht pref. IODev weiter zugeben. Da ich ja nun auf hmLanQlen 3 gestellt hab dürfte die queue ja schneller abgearbeitet werden, weswegen die VCCU auch bei xy sendeaufträgen nicht auf ein anderes IODev ausweichen will. falls ich mit hmLanQlen 3 keine probleme habe ist dieses ja auch ok, andernfalls müsste halt der Queue-Wert der VCCU verlängert werden. Als alternative könnte ich auch noch nen weiteren HMlan anschließen, sehe ich allerdings bei den paar Devices die der eine HMlan verarbeiten muss für übertrieben an.

Gruß
Ingo

[martinp876]

@Rainer,

es wird immer der letzte rssi genommen - von der letzten Nachricht. damit sollten "bewegte" devices abgedeckt sein (hoffe ich einmal).

@Ingo,

der update ist noch in SVN - und du brauchst auch 00_HMLAN dazu.
QLen 3 kann zu wiederholungen führen. Ich habe einst einiges getestet - manchmal geht es deutlich schneller... manchmal nicht. 1 ist konservativ.
Q-wert in der vccu macht keinen sinn. Es ist die Q des HMLAN. Man darf dies bei jeden einges einstellen. eine CUL hat dieses feature garnicht.
Wenn die vccu die Aufträgen ach Q-laenge verteilen soll - sollen dann prefered und rssi nachrangig sein? Im Übrigen war es dann fast genau das, was wir hatten.

Da ich ja nun auf hmLanQlen 3 gestellt hab dürfte die queue ja schneller abgearbeitet werden

wenn es nicht zu kollisionen kommt, schon. zum testen bietet sich ein HMInfo autoReadReg an (hohe Last ) und ein Blick auf die protokoll-events in HMInfo.

weswegen die VCCU auch bei xy sendeaufträgen nicht auf ein anderes IODev ausweichen will.

nicht wirklich.

andernfalls müsste halt der Queue-Wert der VCCU verlängert werden

die vccu hat keine Q

Als alternative könnte ich auch noch nen weiteren HMlan anschließen, sehe ich allerdings bei den paar Devices die der eine HMlan verarbeiten muss für übertrieben an.

auch das hilft nicht unbedingt. wenn 2 Devices auf das gleiche IO deuten bist du an der gleichen Stelle wie vor.

Es ist etwas komplexer, als du es darstellst (oder vielleicht besser 'einfacher')

[geek]

es wird immer der letzte rssi genommen - von der letzten Nachricht. damit sollten "bewegte" devices abgedeckt sein (hoffe ich einmal).

Mein Gedanke war folgender:

• device schickt was, IO1 empfänt das mit RSSI 60, IO2 mit schlechterer RSSI oder garnicht
• device wird aus dem Empfangsbereich von IO1 komplett entfernt, nur IO2 sieht das device noch mit RSSI 70.
• IO1 sieht jetzt rein garnichts mehr von dem Traffic des devices - die RSSI wird also nicht mehr aktuallisiert (oder?).
• die VCCU nimmt weiterhin IO1, weil dort die bessere RSSI 60 gesehen wurde

Ist nur Theorie. Und ein Extremfall.

Sollte IO1 noch (zu schlechten) Empfang haben und das Gerät (noch) keine zyklischen Nachrichten schicken, würde ich erwarten, daß das erste Kommando nach dem Umzug von der VCCU ins leere geht - dabei wird aber (hoffentlich?) die RSSI aktuallisiert. Folgende Kommandos sind dann erfolgreich.

[martinp876]

Hallo Rainer,

wie gesagt, es wird der RSSI der letzten Nachricht genommen. Wenn diese von einem IO nicht empfangen wurde ist dieses IO nicht in der Liste, wird also nicht berücksichtigt. Hatte ich schon so verstanden und auch beantwortet.

daß das erste Kommando nach dem Umzug von der VCCU ins leere geht - dabei wird aber (hoffentlich?) die RSSI aktuallisiert

wie soll das gehen? Wenn du ein Device umziehst vom Bereich IO1 nach IO2 (beide im Funkbereich nicht überdeckend) kann es Probleme geben. Also
- letzte message empfangen aus IO1, dev jetzt im Bereich IO2.
- FHEM will senden - wählt IO1 => kein Empfang.
- =>FHEM kann den RSSI nicht erneuern, da kein IO etwas empfangen hat.

i.a. ist das aber kein Problem. Ein bewegliches Device ist meist eine remote. Da läuft es so ab, dass die remote etwas sendet (trigger) und damit die IOs in reichweite empfangen, die RSSI also erneuern. Folgende Details sind zu berücksichtigen
1) man will einer RC19 ein Kommando schicken nach Umzug in den neuen Bereich - ohne dass diese einen Trigger vorher gesendet hat
2) sendet eine remote und braucht eine Antwort wird auf den ersten Empfang der Message geantwortet. Zu diesem Zeitpunkt haben die anderen IOs noch nichts empfangen - also auch keinen RSSI, können also nicht berücksichtigt werden.

Zu 1) ist ein sehr seltener Fall, kann aber vorkommen. man müsste ein "searchTestIo" anstossen. Dann müsste eine test-message auf allen IOs gesendet werden - mal sehen, wer empfängt. Automatisch werden ich das eher nicht einbauen. Wenn es tatsächlich gebraucht werden sollte kann man es bauen.
Zu 2) man könnte den Empfang der letzten UND der vorletzten Message berücksichtigen. Wenn sich das dev bewegt hat stimmt es also wieder nicht. => ich denke, das jetzige ist ok: es wird auf jeden Fall über ein IO gesendet, dass auch empfangen hat.

Ich sehe also keinen wirklichen Problemfall. Falls du einen hast, beschreiben ihn noch einmal

Gruss Martin

[geek]

Hi Martin,

aktuell habe ich keinen Problemfall. Sorry wenn das so rüber gekommen ist. Ich versuche nur die Grenzen zu verstehen.

wie gesagt, es wird der RSSI der letzten Nachricht genommen. Wenn diese von einem IO nicht empfangen wurde ist dieses IO nicht in der Liste, wird also nicht berücksichtigt. Hatte ich schon so verstanden und auch beantwortet.

Wie wird die RSSI bei einem IO aktuallisisert, wenn eine Nachricht dort garnicht ankommt? Wird die RSSI bei allen IOs aktuallisiert wenn eine Nachricht nur bei einem IO ankommt?

Ich hätte angenommen, daß nur die letzte auf dem IO gesehene Nachricht für die RSSI genommen wird.

wie soll das gehen? Wenn du ein Device umziehst vom Bereich IO1 nach IO2 (beide im Funkbereich nicht überdeckend) kann es Probleme geben.

Ja, meine Annahme war Unsinnig: Das wäre nur der Fall, wenn Empfang IO1 -> neuem Platz funktioniert, vom neuen Platz aber nix bei IO1 ankommt.

Rainer

[martinp876]

Ich versuche nur die Grenzen zu verstehen.

kein Problem. Ich versuche auch, mögliche Problemfälle zu erkennen.

Wie wird die RSSI bei einem IO aktuallisisert, wenn eine Nachricht dort garnicht ankommt?

wenn sie nicht ankommt wird der wert gelöscht. Das passiert, wenn ein IO die Nachricht empfängt. Sollte kein IO etwas empfangen wird auch nichts gelöscht.

Wird die RSSI bei allen IOs aktuallisiert wenn eine Nachricht nur bei einem IO ankommt?

ja (bzw gelöscht)

Ich hätte angenommen, daß nur die letzte auf dem IO gesehene Nachricht für die RSSI genommen wird.

ja, die letzte Nachricht. Aber von jeden IO. Die Nachricht wird von jeden IO gemeldet und bearbeitet. Wenn eine Nachricht schon verarbeitet wurde wird nur die neue Info (also z.B. RSSI über diesen Weg) verarbeitet.

Gruss Martin

[frank]

push, push, ... 

hallo martin,

die vccu hinterlegt in den readings ja meldungen, die von unbekannten devices stammen. wenn man neue devices anschafft, sind die ersten meldungen dieser geräte bis zum pairen ja auch erstmal von unbekannten devices.

könnte man nicht einen befehl "verifyUnknownDevices" spendieren, der bereits entstandene unknown-readings auf aktuell bekannte devices überprüft und die entsprechenden unknownreadings wieder löscht? somit würden nur noch die readings von weiterhin unbekannten devices mit vielleicht neuem timestamp übrig bleiben.

weiterhin könnte man anschliessend, mit einem noch zu erstellenden befehl "ignoreUnknownDevices", die restlichen unbekannten devices automatisch zusammen mit einem ignore-attribut definieren.

oder gleich eine kombination aus beidem. wobei eine doppellösung vielleicht sicherer und nachvollziehbarer ist.

gruss frank

[martinp876]

löschen passt gun nach "clear".
ein clear unknownDev habe ich eingebaut.

Kombiniert ... hm - automatisch einrichten...
das ist immer ein Problem - es kommt immer zu leichten Problemen wie z.B. einrichten von logfiles...

[frank]

hallo martin,

löschen passt gun nach "clear".
ein clear unknownDev habe ich eingebaut.

ich bekomme leider kein neuen befehl angezeigt. fehlt eventuell noch eine ergänzung in HMConfig.pm. dazu bietet svn nur v6231 an.

wenn ich das richtig verstehe, löscht der neue befehl aber alle readings "unknown_...", egal ob mittlerweile bekannt oder nicht. sehe ich das richtig? schön wäre ja gerade eine prüfung, die dann garantiert eine liste unbekannter devices übrig lässt, um sie weiter zu behandeln.

vielleicht 2 clear befehle? "clear unknownDev", "clear knownDev".

gruss frank