HM-Overload strategie, conditional Burst (RT, TC und andere) sowie daten-update

[martinp876]

Hi,

an solchen konzepten arbeite ich - habe die ersten Versuche am Laufen. An den Optionen, was wählbar ist, muss ich noch arbeiten.
0) für alle mit Handbetrieb: keine Angst, man wird es komplett ausschalten können
1) Ich sehe beim "holen" 2 Kategorien: 'Status'  und 'Register/Config'.
1a) status: das ist ein weit kleinerer Teil. Aus meiner Sicht ist Status unverzichtbar. Es MUSS nach jedem neustart gelesen werden. Man kann es sich eigentlich nicht leisten, hier nicht aktuell zu sein. Gelesen werden muss i) nach neustart ii) nach pon des Device iii)in verschiedenen Fällen, wenn trigger das Device verändern
- man wird "nur status" wählen können
- status kommt in eine eigene Q.
- die Status-Q hat vorrang vor der config -Q
- die status-Q wird blockiert wenn "high-load" erreicht ist. Das lässt 10% puffer für schaltkommandos
2) config (register und peers) erhalten eine nachrangige Q.
- die Verarbeitung wird gestoppt wenn ein gewisser Level(einstellbar) erreicht ist. 40% als default sind angemessen - so kann man 2 restarts überleben. Die Sperre bei high-load steht sowieso
2a) modi
- aktuell werden immer alle Register gelesen(wenn das Attribut gesetzt ist).
- neu werden nach boot nur die Register gelesen, die nicht aus dem state-file kommen. Das reduziert die Last erheblich - bringt aber eine (erträgliche?) Unsicherheit
- weniger kritisch sind die weiteren Stufen: lesen nach power-on, nach config-schreiben. Kann man aber abschalten, wie bisher
- Ein weiterer Mode ist nach meiner Vorstellung der backgound-update. Beschränkt auf 2 Devices je Stunde. Man müsste die ältesten zuerst erneuern....

3) sonstige Queues: aktuell nur der command-stack. der wird parallel verarbeitet - und ohne "bremse", bis overload erreicht ist. manuell ausgelöste "getConfig" und "statusRequest" unterstehen nicht den oben erwähnten Einschränkungen.
Einbauen könnte ich, dass ein manueller getConfig einen möglichen Eintrag aus der "config-Q" löscht.

Einstellbar werden:
- level der Automatik (autoReadReg)
- level, wann config-Q gestoppt wird
- min wartezeit zwischen config-Q polling
- background-reading noch unklar.

Fehlt noch etwas?

Gruss Martin

[Billy]

Hallo Martin,

danke, sieht nach viel Arbeit aus ist aber logisch eingängig!

Mit Q im Text wie bei

- status kommt in eine eigene Q.

ist generell wohl queue/queues gemeint!
Billy

[martinp876]

korrekt - sind ein paar Tippfehler weniger drin

[unimatrix]

Hallo,

klingt alles sehr gut!

Wo das jetzt sowieso alles überarbeitet ist, noch eine weitere Anmerkung. Du hattest erwähnt, dass die Dinge im CommandStack nach einer Weile verworfen werden weil dann Schaltkommandos ggf. nicht mehr sinnvoll sind. Dies mag für viele Aktoren so stimmen, es gibt aber auch solche Aktoren, die ausschließlich von FHEM bedient werden, in meinem Beispiel z.B. meine Fussbodenheizung (normaler Schaltaktor an/aus). Im einfachsten Fall habe ich zwei ATs, eins zum Einschalten, eins zum Ausschalten. Wenn jetzt aus irgendwelchen Gründen der HMLAN genau um die Zeit, wo da eingeschaltet werden soll, im Overload etc. ist, dann wird ggf. einen ganzen Tag lang die Heizung nicht eingeschaltet. Ebeneso doof bei Aktoren, die ggf. nicht mehr oder NIE mehr ausgeschaltet werden.

Ggf. ist ja eine Option für einen HM-Kanal denkbar, die besagt, dass dort nie die Queue verworfen wird (ggf. ist das aber auch zu kompliziert?) ... wenn ich mir was wünschen dürfte hätte ich jedenfalls gerne Kanäle, bei dem ich per SET einen Sollzustand setze, und mich dann darauf verlasse, dass FHEM "alles tun wird" um diesen Zustand auch herbeizuführen, und notfalls auch eben erst ne Stunde später, so lange ich keinen anderen Sollzustand setze.

Im Moment kann ich das auch erreichen aber da muss ich dann mti anderen Scripten immer mal wieder den Status abfragen und mit vorgeschalteten Dummy-Devices arbeiten die den Sollzustand zwischenspeichern.

Danke für die Berücksichtigung dieser Idee

[justme1968]

das ist eine klasse idee. vileicht sogar noch mit der erweiterung angeben zu können wie lange so ein 'forced' kommando versucht werden soll. bis zum nächsten kommando oder für ein bestimmtes zeitfenster.

rollladen runter z.b. nur die nächsten x stunden oder bis eine andere einstellung kommt.


gruss
  andre

[martinp876]

guter Punkt - muss man aber erst einmal diskutieren,

Also aktuell habt ihr die Möglichkeit im Device msgRepeat zu setzen. Das legt fest, wie oft eine Nachricht wiederholt werden soll. Kann man auch 10000 eingeben....
Noch wird hierbei der Disconnect nicht "ausgeblendet" - vielleicht baue ich dies noch ein....

Nun zu den Details deines Requests
- soll dass für alle Kommandos zu einem Device gelten? jedes regSet... einfach alles? oder soll es eher als Parameter zu einem Kommando dazu kommen?
- wie oft soll es wiederholt werden? Beachte, dass dann nichts andere gesendet werden kann. Außerdem wird das HMLAN belastet- also alle paar Minuten?
- wenn ein Device dann ein NACK sendet soll auch das ignoriert werden?

vor solchen "blockieren" habe ich immer etwas respekt. Es wird der gesamte Verkehr beeinflusst.

Wenn ihr konkrete Vorstellungen habt....

Gruss Martin

[unimatrix]

Welche Gründe kann es denn geben, dass ein Device ein NACK sendet?

Gerade das regSet - da ist es ja klar dass ausser FHEM niemand dieser Werte schreibt. Wenn ich ein regSet mache will ich mich doch eigentlich darauf verlassen dass das Register auch irgendwann im Device "landet". Oder übersehe ich etwas? Wie oft man dann versuchen soll, neu zu schreiben, ist natürlich eine gute Frage. Wenn ich mal das Extrembeispiel annehme - für immer - oder zumindest für sehr lange - dann könnte ja vll. der Abstand zwischen den Versuchen immer weiter erhöht werden, nach jedem erfolglosen Versuch. Dass dann nix anderes an das Device geschickt werden kann, scheint mir auch klar - aber das ist ja sowieso schon so, wenn die Versuche ja erfolglos sind. Welche anderen Gründe, außer dass das Device "abgestürzt" ist oder ne gestörte Funkverbindung hat kann es geben?

Ich glaube um eine vernünftige Lösung zu bauen, müsste man sozusagen die Usecases mal durchgehen, die es alle geben kann - also vll aus der Perspektive "Warum kann ein Senden schief gehen". Ich kenne halt auch nicht alle möglichen Ursachen dafür. Relativ sicher bin ich mir aber, dass es interessant ist, zumindest im Falle von Overload und Disconnect des HMLAN diese Messages - für bestimmte Devices - nicht zu verwerfen.

Also wenn man es nicht so kompliziert machen will vll einfach:

- Attribut, dass bewirkt, dass eine zu sendende Nachricht nicht verworfen wird, nur weil der HMLAN nicht geht, sondern nur dann, wenn die Anzahl der tatsächlich vom HMLAN ausgesendeten Versuche msgRepeat überschreitet. Dann sollte auch eine Fehlermeldung im Log stehen, die so auswertbar ist, dass ich mich als User automatisch darüber informieren kann. Aber dann sollte das natürlich auch selten genug sein, man will ja keinen Email-Spam.

[martinp876]

hi,

demnächst kommen vorerst die angesprochene Änderung.

Der Einbau des "Wiederholen" hat ein paar Fallen:
ein register- schreiben besteht nicht aus einer sondern mindestens 3 messages. Wenn die letzte schief geht kann man die nicht wiederholen, man braucht alle...

das Wiederholen muss die Modi berücksichtigen - wakeup/config/burst/normal

z.B."set on" werde ich nicht ewig wiederholen - jedenfalls nicht ohne explizite Anweisung. Somit muss man also einen wiederhol-parser einbauen, der das ganze klassifiziert.

NACK kann es aus verschiedenen Gründen geben: nicht existente Register schreiben oder lesen, falsche peers löschen, Baustein noch nicht fertig, könnte später klappen. Die Liste ist nicht komplett und sicher nicht 100% einheitlich.

das mit dem langen wiederholen ist nicht ohne... so werde ich mein System nicht einstellen. Es wird - zumindest bei mir - immer einen Endpunkt geben - mit Alarm. Das sollten auch alle normalen User machen. Schon allein das Abbrechen sauber verständlich zu machen ist schwer.

Prinzipiell stimme ich zu, so ist es unbefriedigend.
Ich denke wir sollten stufig vorgehen. Nach der aktuellen Änderung kommt:
- Behandlung von IO-dev Problemen ändern: laufende Kommandos wieder in die Queue zurück.
- Benachrichtigung, was nicht übertragen wurde präzisieren. Die high-level Kommandos habe ich nicht

Mal sehen, wo wir hinkommen, wenn wir uns langsam vor tasten.
Gruss Martin

[martinp876]

so schritt 1:
Version 4053 mit folgenden details:

autoReadReg vertraut nach reboot den registerlisten aus dem state-file. Es werden ein paar checks gemacht, nur wenn etwas inkorrekt ist wird für dieses Device/channel gelesen.

status request wird bedingungslos durchgeführt (wenn autoReadReg mindestens 1 ist.)
man kann nur statusRequest durchführen lassen (option - register und peers werden dann nie automatisch gelesen.
das register-lesen ist in 2 Qs aufgeteilt. somit kann ich "normale" und "wakeup/config" devices unterscheiden/steuern. damit erschlage ich das Problem, dass wakeup devices sich auch der "sendeschwelle" unterwerfen.
Die Schwelle defautl für auto-config-lesen liegt bei 40% (kalkulierter!! wert)
Es kann jetzt eigentlich autoReadReg auch für Config devices gesetzt werden - FHEM wartet ab, bis jemand config drückt...

Eine Übersicht erhält man mit HMInfo
set hm protoEvents
(wide-screen)
oder
set hm protoEvents short
(normal-screen )

Gruss Martin

[martinp876]

bei den Umstellungen habe ich wie gewöhnlich Bug versteckt.
die ersten beiden habe ich jetzt entfernt:

setzen der Reglist 0 (z.B burstRx ) hatte Probleme.
conditional burst war nicht mehr zuverlässing - und hat ggf. den stack gelöscht. Sollte jetzt wieder korrekt funktionieren

[snoop]

Hallo zusammen,
ich möchte das doch sehr heiße/spanende und durchaus wichtiges! Thema nicht in den Threads versickern  lassen – daher mein Kommentar dazu.
Jeder der ein paar Monate in das Thema ,,Haus Automation" Zeit und das Geld investiert hat, macht sich mit der zunehmenden Anzahl an Komponenten Gedanken ,,wie weit komme ich mit der bisher gewählten Infrastruktur /Strategie(HM) (abgesehen der FW-Probleme/Qualität von HM)",,   

Mal querdenken: Es gibt ein System (offensichtlich/primär HMLAN/HMUSB) das Grenzen hat ,,man versucht aktuell technisch alles rauszuholen(Spagat)" - > zunächst alles unverwerflich ,, .
Frage lohnt sich der technische Spagat bei ,,den" HLMLAN/USB Preisen?
Frage: Lohnt es sich nicht den Aufwand in das eine unkomplizierte Handhabung von HMLAN/USB Cluster zu investieren – hmid -  Ohje... Probleme abgesehen?
Idee:  70€ investieren (zumutbar ab einen gewissen count an HM devices ) dafür aber ein unproblematischer Betrieb.
,,WIE ERWEHNT MAL QUERDENKEN?" (*GEFAHR: HIRNRISSIG=DISKUSSIONSWÜRDIG?!)
Viele Grüße
Arthur

[martinp876]

Hallo Arthur,

ich geben dir recht - ab einer bestimmten Anzahl Komponenten sollte/muss man über ein zweites HMLAN/USB nachdenken. Wenn man viel investiert hat ist der Preis sicher zu relativieren.
HMInfo erlaubt einen Einblick, wie start ein HMLAN belastet ist und ob man sich Gedanken machen sollte. Bei größeren Systemen sollte/muss man sich eh einen Überblick über Protokoll-unstimmingkeiten verschaffen.
Das Thema halte ich auch für extrem wichtig.
An der Optimierung des Performancebedarfs versuche ich weiter zu arbeiten - zusammen mit dem ebenso wichtigen Anspruch, dass die angezeigten Infos aktuell und akkurat sind

Gruss Martin

[unimatrix]

ist jetzt schon lange her aber bin hier zufällig gelandet. Hatte mir damals tatsächlich eine FS20 Steckdose an den HMLAN geklemmt.

Wenn der Overload getriggert wird mach ich das Ding für 5 Sekunden stromlos. Die Zeit reicht aus und danach geht es immer wieder.

Mag sicher viele geben die das für falsch halten, da man die 1% Regel ja hier nicht mehr einhält. Ich wohne allerdings so sehr auf dem Land dass ich mir sicher bin hier ist niemand anderes ....

[martinp876]

ich hoffe aber, dass es nicht oft vorkommt. Im normalbetrieb - auch bei updates  - sollte es keinen Probleme geben - auch bei größeren Installationen. Sollte es häufiger auftreten wäre zu untersuchen, warum (zu viele Abfragen...) . Die Messagestatistiken wären dann interassant.
Beim Testen ist es etwas anderes.

[Groby]

Hallo,

ich bekomme nach mehrfachen reboot's allerhöchstens einen highload.

Was versteht Ihr denn unter einer "größeren" Installation?

MfGroby