fhemweb FW_Read zu langsam

[betateilchen]

und Rudi weiss immer noch nicht, wieviele entities martin im Einsatz hat 

[martinp876]

alles in allem nur 117 in diesem Setup (eigentlich wenig, meine ich)

was hat es mit der regexp auf sich? Die in FW_roomIdx?
Wenn ich es richtig sehe werden die räume mit '^$' eindeutig identifiziert - also nicht alles, was beispielsweise mit OG beginnt oder OG enthält. Dann wäre wohl kein Unterschied zu meiner Lösung - ausser, dass ich nicht suche, ob der raum aus sortRooms auch in FW_rooms existiert. Das halte ich nicht für notwendig.... wenn der user den einträgt... kann man aber auch einfach filtern, so man will.
Wo ist das Feature? Ich sehe es auch keine Beschreibung...

oder gibt es noch eine andere regexp?

ps: gut aufgepasst Udo - danke

[justme1968]

du hast recht. die doku lässt mal wieder zu wünschen übrig.

mit der aktuellen version kann man sehr wohl z.b. DG.* OG.* EG.* schreiben und es wird dann danach gruppiert und innerhalb der gruppierung automatisch alphabetisch sortiert und danach alles andere alphabetisch dahinter. oder auch 2.* 1.* 0.* um automatisch 2 2.1 2.2 2.3 1 1.1 1.2 1.3 0 0.1 0.2 0.3 zu bekommen.

[martinp876]

ah - ok. Der .* kommt aus dem Attribut... klar.

das wäre in der Doku gut  - sollte sicher heissen:

Code Auswählen Erweitern

sortRooms
Space separated list of rooms to override the default sort order of the room links. Example:
attr WEB sortRooms DG.* OG.* EG.* Keller.*

[justme1968]

Code Auswählen Erweitern

sortRooms
Space separated list of regex to override the default sort order of the room links. Example:
attr WEB sortRooms DG.* OG.* EG.* Keller.*

[martinp876]

das spart noch einmal die Hälfte zu Rudis Vorschlag - und sollte justme1968 auch genügen.
FW_roomIdx kann man löschen.

Sollte die roomListe nicht gleich in FW_updateHashes() generiert werden? Und das könnte man triggern, wenn attr room, group, model oder subType geändert werden. Und bei der Definition (wegen TYPE).

Wird boot evtl etwas langsamer - aber sonst wird es schneller.
Generell wäre das m.E. näher an einer echtzeit-anwendung - vorbereitende Berechnungen.

Code Auswählen Erweitern

  my @rlist;
  if(AttrVal($FW_wname, "sortRooms", "")) {
     my @sortBy = (split( " ", AttrVal( $FW_wname, "sortRooms", "" ) ),".*");
     my %sHash;                                                       
     my $index;
     foreach my $r(keys %FW_rooms){
       $index = 0;
       foreach(@sortBy){
         last if ($r =~ /^$_$/);
         $index++;
       }
       $sHash{$r} = substr("000$index",-3)."-$r";
     }
     @rlist = sort { $sHash{$a} cmp $sHash{$b} } keys %FW_rooms;
  } else {
    @rlist = sort keys %FW_rooms;
  }

[rudolfkoenig]

Hab kein Problem mit dem Code, wenn justme1968 auch seinen Segen dazu gibt.

Und das könnte man triggern, wenn attr room, group, model oder subType geändert werden. Und bei der Definition (wegen TYPE).

Das geht aber nur mit einem event beim Attribut-Aendern, und da bin ich noch dagegen.

Generell wäre das m.E. näher an einer echtzeit-anwendung - vorbereitende Berechnungen.

Ich bin nicht daran interessiert, FHEM "echtzeit-faehig" zu machen, mAn ist das sehr viel Aufwand um etwas zu loesen, was man viel einfacher auch erreichen kann, z.Bsp. mit einem separaten Prozess fuer die HM-ACKs oder mit "ordentlichen" Hardware (HMLAN statt CUL oder bessere CPU). Oder einfach damit leben, dass manchmal HM-Befehle kein ACK kriegen.

Wie sollte man z.Bsp. das SVG-Problem loesen? Fork fuer jeden der angeforderten SVGs auf dem Fritzbox laesst die Kiste abstuerzen, ohne Fork kann ich keine 100ms garantieren. Selbst wenn ich SVG (irgendwannmal) in JS nachgebaut habe, muss FHEM etliche MB lesen + komprimieren, das kann auch mehr als 100ms dauern.

[justme1968]

wenn justme1968 auch seinen Segen dazu gibt

ich weiss ja nicht ob man das segen nennen sollte aber für meine anwendungsfälle und tests funktioniert es.

Das geht aber nur mit einem event beim Attribut-Aendern, und da bin ich noch dagegen.

schau dir noch mal weiter oben den vorschlag mit dem timestamp beim ändern der attribute an. das geht ganz ohne events. und da nur timestamps gemerkt und verglichen werden sollte es auch recht effizient sein.

Wie sollte man z.Bsp. das SVG-Problem loesen?

man muss ja nicht für jeden plot forken sondern könnte auch ein mal nur für das ganze web frontend oder ein mal für alle plots.

[rudolfkoenig]

schau dir noch mal weiter oben den vorschlag mit dem timestamp beim ändern der attribute an.

Hardcoding in fhem.pl fuer ein spezielles Modul, damit auf lahmen Hardware und viel Peripherie unter Verwendung eines bestimmten Attributes ein Webaufruf 30ms schneller wird. Was an sich noch kein Problem loest. Sehr unsympatische Loesung.

man muss ja nicht für jeden plot forken sondern könnte auch ein mal nur für das ganze web frontend oder ein mal für alle plots.

Oder man nimmt ordentlichen Hardware. Oder man ignoriert das Problem

[justme1968]

Code Auswählen Erweitern

Hardcoding in fhem.pl fuer ein spezielles Modul

nein. nicht hard kodiert für ein modul. für alle globalen attribute. und an allen stellen verwendbar die attribute über alle devices zusammen suchen müssen.

wenn in CommandAttr ein $attrTimestamp{<attr>} gesetzt wird und im modul mit dem lokalen timestamp der hash erzeugung verglichen wird ist beides völlig entkoppelt.

Code Auswählen Erweitern

Oder man nimmt ordentlichen Hardware. Oder man ignoriert das Problem
ja. und vor allem keine fritz box

[martinp876]

Oder man nimmt ordentlichen Hardware. Oder man ignoriert das Problem

hm - ich denke keines von Beidem ist hinreichend. Oder seid ihr mit einem "manchmal - schaltet er" zufrieden? Da haben andere schon bei deutlich selteneren Fehlschaltungen Probleme (zurecht).

Ich bin nicht daran interessiert, FHEM "echtzeit-faehig" zu machen,

schade. Zumindest irgendeine Vereinbarung über timings wäre schon. Die Probleme steigen... Das system wird (zu recht) komplexer und langsamer.

Die Aussage ist also, dass man - will man ein Timing erzeugen - den echtzeit-anteil forken muss... das geht aber leider nicht on the fly - das dauert schon einmal zu lange... müsste man parallel laufen lassen....

Unschön ist z.B. auch, dass ein "totes" ethernet-IO ständig (alle 5 sec) gepollt wird (sinnlos, nichts probiert wird) und jede Min 3sec FHEM blocktiert... USB muss ich noch einmal ansehen...
Auch mit schnellerer HW sind die 3 sec hart kodiert. Eine IO Ersatzschaltung hat mit den 3 sec immer Probleme.

[Dr. Boris Neubert]

schade. Zumindest irgendeine Vereinbarung über timings wäre schon. Die Probleme steigen... Das system wird (zu recht) komplexer und langsamer.

Das halte ich für aussichtslos bei der Fülle an Systemen und Betriebsystemen.

M.E. ist der vorher schonmal angebrachte Vorschlag, die Verarbeitung der HM-Befehle nebenläufig zu fhem zu gestalten, für aussichtsreich. Ich meine damit einen Serverprozeß analog zu owserver, der die Kommunikation mit den HM-Geräten puffert, und über TCP-Sockets mit FHEM kommuniziert.

Viele Grüße
Boris

[martinp876]

Hallo Boris,

darauf läuft es wohl hinaus - alles ander ist hoffen.
Ich bin mir nicht sicher, ob OW diese timing-komplexität hat. Ich muss je HM device einen Kommandstack verwalten. Ein Device kann wahlweise zwischen IOs umschalten. Empfangssignale müssen die Sendesignale Triggern. Das IO device darf nicht beliebig senden sondern muss messages der unterschiedlichen HM-Devices sortieren und queuen.
Da müssen einige Teile aus CUL_HM in den Server-threat ausgelagert werden (und dann wieder zurückgegeben, damit man auswertungenmachen kann).
Ist ein größeres Projekt.

Natürlich müssen auch die IOs (CUL und HMLAN) 'ausgelagert' werden.

Gruss Martin

[rudolfkoenig]

wenn in CommandAttr ein $attrTimestamp{<attr>} gesetzt wird und im modul mit dem lokalen timestamp der hash erzeugung verglichen wird ist beides völlig entkoppelt.

Das ist natuerlich eine viel elegantere Idee. Leider reicht so noch nicht, weil auch Attribut loeschen, Geraet anlegen, Umbenennen, Loeschen, Modifizierern beachtet werden muss. Ich habe deswegen $lastDefChange eingefuehrt, was in all diesen Funktionen hochzaehlt. Es stellte sich raus, dass das auch noch nicht reicht, weil eine TCP-Verbindung auch ein Geraet erzeugt und loescht, damit war kein Caching-Effekt zu beobachten. Daraufhin habe ich TEMPORARY Geraete aus der Zaehlung ausgenommen.

Es scheint bei mir zu funktionieren, mit der etwas schalen Nachgeschmacks der "Viel Aufwand fuer was eigentlich?".
Hoffentlich gibt es noch weitere Nutzer der Variable.