vorschlag: (optionale) asynchrone ausgabe von get kommandos

justme1968 · 18 November 2015, 20:37:43

wie gesagt: den (kosmetischen) prompt kann man wieder herstellen wenn man am ende der telnet AsyncOutputFn einfach noch mal einen prompt ausgibt.

ZitatIch vermute, du tippst kein <return> in einer leeren Zeile.

niemals absichtlich und wenn es aus versehen passiert beende ich schnell und starte eine neue session

. der prompt ist bei copy&paste nur im weg.

ach so. die select meinst du

. das sind aber nicht wirklich 'echte' select sondern nur warten mit timeout und eigentlich kaum besser als blockieren da nur auf einen filedescriptor gewarnt wird. da passiert nichts wirklich asynchron. der rest vom system schläft ja.

mit dem patch könnte man die problematischen get vielleicht auch asynchron machen. auch programm intern oder zwischen modulen wenn man in $hash->{CL} ein 'privates' device oder auch nur einen hash übergibt der einem dann später über asyncOutput wieder aufruft. das würde dann wie eine art callback funktionieren. das ist zwar nicht so schön wie in node.js mit closueres und bind funktioniert aber trotzdem.

rudolfkoenig · 20 November 2015, 23:12:04

Habe zwei Probleme gefixt, die mit dem Patch reinkamen:

1. http://forum.fhem.de/index.php/topic,44357.msg
Lag an direktem Zugriff mit $FW_id, ohne Pruefung. Mein Fix hat vermutlich keine Nebenwirkungen, aber bitte testen.

2. http://forum.fhem.de/index.php/topic,44360.msg
Lag an escapen der < in dem get Antwort, komischerweise nur einmal, und nur <, nicht aber > usw. Das habe ich jetzt komplett entfernt, auch wenn ich nicht weiss, was du damit bezweckt hast. Lustig: der Code zum umwandeln von Geraetenamen in Links stammt auch von dir

justme1968 · 21 November 2015, 00:11:46

die 1. verstehe ich nicht ganz. könnte passieren wenn eine longpoll verbindung rein kommt bevor das erste mal eine browser seite aufgebaut wurde. aber eigentlich auch dann nicht weil die id über die longpoll verbindung mit geschickt wird...

ich glaube es würde reichen $FW_id am anfang einfach auf 0 zu initialisieren. deine version sollte aber auch gehen.
die 1. war mein fehler und passiert wenn die verbindung nicht aus dem browser kommt. dein fix passt.

die 2. hat einen grund den ich weiter oben kurz erklärt habe. wenn ein text kommt in dem ein < vor kommt wie z.b. wenn das get mit einer 'usage: get ...<wert>' meldung antwortet erscheint nur ein leerer dialog ohne text.

laut html spezifikation ist es eigentlich so das > nur dann eine spezielle bedeutung hat wenn davor ein < auf gleicher ebene kommt. d.h. wenn man das < durch < ersetzt hat das > danach keine spezielle bedeutung mehr und wird einfach angezeigt. vermutlich wäre es aber sauberer das > auch noch durch > zu ersetzen.

eine ursache für das problem ist glaube ich das es in 01_FHEMWEB vier stellen gibt an denen daten an den browser geliefert werden und alle vier werden unterschiedlich behandelt. die erste ist der FW_jsonp fall. hier wird nur neweline escaped. der zweite ist kurz darunter, hier werden mit FW_addLinks links eingefügt. der dritte ist der andere aufruf von FW_addLinks, hier wird auch noch FW_htmlEscape ausfgerufen und kurz darüber der vierte an dem eine mit html markierte rückgabe unverändert durchgereicht wird.

die korrekte lösung ist vermutlich wie an anderen stellen auch die rückgabe mit den ergänzten links durch ein umschliessendes <html>...</html> zu markieren. und nur in dann in fhemweb.js das ersetzen bleiben zu lassen.

A.Harrenberg · 29 November 2015, 12:35:42

Hi Rudi,

Zitat von: rudolfkoenig am 18 November 2015, 20:08:08
Ueberall, wo ich meine Finger drin hatte (00_CUL.pm, 00_FBAHA, 00_ZWDongle) wird get mit einem lokalen select realisiert. Das es nicht gut ist, daemmert mir auch , deswegen ja die Frage. Im ZWave ist es am schlimmsten, weil es inzischen auch programmatisch verwendet wird, um von der Gegenseite secNonce zu holen, und mein Co-Autor weigert sich vom get Abschied zu nehmen. Aber auch im CUL ist das stoerend (get RFR ccconf), ist nur bisher nicht so stark aufgefallen.

hab' das erst jetzt entdeckt...

Ich kann jetzt nicht sagen das ich die Diskussion hier überblicke, dafür stecke ich (noch) nicht tief genug drin, vor allem "select" mit Filehandle sagt mir jetzt gerade nicht sehr viel, außer das man damit das System durchaus blockiert...

Meine "Weigerung" get abzuschaffen bezieht sich ja erst mal nur auf die Unterscheidung der Befehle in SET und GET um zu wissen ob eine Antwort erwartet wird oder nicht. Die momentane Bearbeitung der get-Befehle mit dem Aufruf der "ReadAnswerFn" in ZWDongle (dort passiert dann ja das select) brauche ich eigentlich nicht für die SECURITY Sachen. Wenn Du also an der Stelle umbauen möchtest sollte das eigentlich keine weiteren Konsequenzen für SECURITY haben.

Ich seh' aber schon das ich mich hier doch noch deutlich tiefer mit den internen Abläufen von FHEM beschäftigen muss.

Gruß,
Andreas.

rudolfkoenig · 24 Februar 2017, 10:14:18

Das $hash->{CL} wird jetzt auch by define/modify gesetzt.
Im at wird damit bei einem wiederkehrenden at die Pruefung vermieden.
Auch wenn ein at in einem notify definiert wird, wird nicht geprueft.

FHEM Forum

vorschlag: (optionale) asynchrone ausgabe von get kommandos

justme1968

rudolfkoenig

justme1968

A.Harrenberg

rudolfkoenig