Unterschied $hash->{CL}{canAsyncOutput} bei get- bzw. set-Kommando

Begonnen von DS_Starter, 03 August 2017, 19:46:39

Vorheriges Thema - Nächstes Thema

DS_Starter

Hallo Rudi,

vor kurzem habe ich ja die asynchrone Bildausgabe in SSCam erfogreich mit  "asyncOutput($hash->{CL}, "$htmlCode");" realisiert und läuft als get-Kommando einwandrei.

Jetzt hatte ich es ebenfalls in einen set-Kommandozweig implementiert und wunderte mich dass es nicht wie gewünscht funktionierte. Es kam keine Ausgabe.
Um das Problem einzukreisen habe ich den übergebenen Clienthash jeweils ausgegeben (gleich in SetFn bzw. GetFn)  und dabei festgestellt, dass beim Get-Kommando ($hash->{CL}{canAsyncOutput} gesetzt wird und bei set-Kommando dieser Key fehlt und sicherlich deswegen die asynchrone Ausgabe nicht abgearbeitet wird.

übergebener Clienthash beim Get-Kommando:
Zitat
2017.08.03 19:10:44.310 4: CamCP1 - snapGallery Clienthash: Authenticated -> 1
2017.08.03 19:10:44.313 4: CamCP1 - snapGallery Clienthash: PEER -> 192.168.2.10
2017.08.03 19:10:44.316 4: CamCP1 - snapGallery Clienthash: canAsyncOutput -> 1
2017.08.03 19:10:44.318 4: CamCP1 - snapGallery Clienthash: SSL -> 
2017.08.03 19:10:44.320 4: CamCP1 - snapGallery Clienthash: NR -> 5844
2017.08.03 19:10:44.322 4: CamCP1 - snapGallery Clienthash: SNAME -> WEB
2017.08.03 19:10:44.325 4: CamCP1 - snapGallery Clienthash: PORT -> 41049
2017.08.03 19:10:44.327 4: CamCP1 - snapGallery Clienthash: TYPE -> FHEMWEB
2017.08.03 19:10:44.329 4: CamCP1 - snapGallery Clienthash: FD -> 31
2017.08.03 19:10:44.331 4: CamCP1 - snapGallery Clienthash: BUF -> 
2017.08.03 19:10:44.333 4: CamCP1 - snapGallery Clienthash: LASTACCESS -> 1501780244
2017.08.03 19:10:44.335 4: CamCP1 - snapGallery Clienthash: helper -> HASH(0x394a338)
2017.08.03 19:10:44.337 4: CamCP1 - snapGallery Clienthash: CD -> IO::Socket::INET=GLOB(0xb8f6908)
2017.08.03 19:10:44.339 4: CamCP1 - snapGallery Clienthash: TEMPORARY -> 1
2017.08.03 19:10:44.340 4: CamCP1 - snapGallery Clienthash: NAME -> WEB_192.168.2.10_41049
2017.08.03 19:10:44.342 4: CamCP1 - snapGallery Clienthash: STATE -> Connected
2017.08.03 19:10:44.343 4: CamCP1 - snapGallery Clienthash: FW_ID -> 5728

übergebener Clienthash beim Set-Kommando:


2017.08.03 19:11:16.150 4: CamCP1 - snapGallery Clienthash: helper -> HASH(0x3ad28c8)
2017.08.03 19:11:16.153 4: CamCP1 - snapGallery Clienthash: LASTACCESS -> 1501780276
2017.08.03 19:11:16.155 4: CamCP1 - snapGallery Clienthash: FD -> 30
2017.08.03 19:11:16.157 4: CamCP1 - snapGallery Clienthash: BUF -> 
2017.08.03 19:11:16.159 4: CamCP1 - snapGallery Clienthash: STATE -> Connected
2017.08.03 19:11:16.162 4: CamCP1 - snapGallery Clienthash: SNAME -> WEB
2017.08.03 19:11:16.164 4: CamCP1 - snapGallery Clienthash: PORT -> 41176
2017.08.03 19:11:16.166 4: CamCP1 - snapGallery Clienthash: TYPE -> FHEMWEB
2017.08.03 19:11:16.168 4: CamCP1 - snapGallery Clienthash: PEER -> 192.168.2.10
2017.08.03 19:11:16.170 4: CamCP1 - snapGallery Clienthash: CD -> IO::Socket::INET=GLOB(0x8820e10)
2017.08.03 19:11:16.172 4: CamCP1 - snapGallery Clienthash: Authenticated -> 1
2017.08.03 19:11:16.174 4: CamCP1 - snapGallery Clienthash: NR -> 5854
2017.08.03 19:11:16.175 4: CamCP1 - snapGallery Clienthash: TEMPORARY -> 1
2017.08.03 19:11:16.177 4: CamCP1 - snapGallery Clienthash: NAME -> WEB_192.168.2.10_41176
2017.08.03 19:11:16.178 4: CamCP1 - snapGallery Clienthash: SSL -> 


Das Kommando wurde natürlich im selben Browserfenster abgesetzt, nur eben einmal get, bzw. set.

Nun stellt sich mir natürlich zunächst die Frage ob das Verhalten so designed wurde oder ob ein Bug vorliegt. Laut Wikieintrag sollte auch die set-Funktion unterstützt werden wobei auch darauf hingewiesen wird dass unter bestimmten Umständen keine asynchrone Übertragung möglich ist.  Was könnte das denn z.B. sein wenn man den Befehl doch im selben Browserfenster so wie beschrieben ausführt ?

In dem Zusammenhang stellt sich mir ebenfalls noch die Frage, ob man über die Auswertung der aktiven und connected FHEMWEB-Devices einen Clienthash zusammnebauen kann den man zur Abarbeitung  in asyncOutput übergibt wenn man zum Beispiel dieses Ausgabeverfahren mittels eines "at" oder "notify" realisieren will bei dem naturgemäß kein Clienthash per FHEMWEB übergeben werden kann. Möglicherweise ist dies aber überhaupt nicht möglich, auch weil verschiedene Werte in dem Clienthash dynamisch zu sein scheinen und sich jedesmal ändern (NAME, CD, PORT).

Vielleicht kannst du/ ihr etwas Licht in das Dunkel bringen.
Danke ! und VG,
Heiko 
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

- canAsyncOutput wird zwar von FHEMWEB und telnet gesetzt, aber bei der Ausgabe via asyncOutput nicht geprueft. Da wird die AsyncOutputFn von $cl aufgerufen, falls so eine Funktion existiert.

- ich habe 98_dummy.pm/dummy_Set temporaer erweitert mit:
  my $cl = $hash->{CL};
  InternalTimer(time()+2, sub(){ asyncOutput($cl, "Hello");}, 0);

und ein Dialog erscheint, wie bestellt. Beachte: ich verwende $cl, da nach dem Aufruf von SetFn $hash->{CL} entfernt wird.

Zitateinen Clienthash zusammnebauen kann den man zur Abarbeitung  in asyncOutput übergibt wenn man zum Beispiel dieses Ausgabeverfahren mittels eines "at" oder "notify" realisieren will
Das geht, alternativ kann man sowas mit "trigger TYPE=FHEMBWEB JS:alert('hallo')" machen. Allerdings bin ich der Ansicht, dass man als Modulautor nicht ungefragt Dialoge aufmachen sollte. Bei get hat der Benutzer explizit nach einem Wert gefragt, bei set finde ich es grenzwertig (direkte Fehlermeldung finde ich ok, sonst erwarte ich keine Rueckmeldung), und alles andere (Zeit/Eventgestuert) sollte nicht geben. Waere sogar geneigt, sowas explizit unterbinden zu wollen.

DS_Starter

Hallo Rudi,

herzlichen Dank für die Erläuterungen.

Ausgehend davon habe ich in meinen Code wiederholt gecheckt und eine Stelle gefunden an der ich auf $hash->{CL}{canAsyncOutput} prüfe und demzufolge natürlich nicht ausgeführt wird wenn canAsyncOutput nicht gesetzt ist. Zum Zeitpunkt der Übergabe setze ich mir $hash->{HELPER}{CL} = $hash->{CL} und arbeite damit weiter, klappt nun prima.

ZitatDas geht, alternativ kann man sowas mit "trigger TYPE=FHEMBWEB JS:alert('hallo')" machen.
Sehr gut ... versuche ich mal umzusetzen.

ZitatAllerdings bin ich der Ansicht, dass man als Modulautor nicht ungefragt Dialoge aufmachen sollte. Bei get hat der Benutzer explizit nach einem Wert gefragt, bei set finde ich es grenzwertig ...
Ich gebe dir völlig Recht. Nur ist das Anliegen in diesem speziellen Fall, dass der Nutzer die Möglichkeit haben soll, bei Eintritt eines Ereignisses sich z.B. eine kleine Gallerie der letzten x Schnappschüsse aufpoopen zu lassen. Wir können also davon ausgehen dass der Nutzer diesen Popup wünscht wenn er sich ein Notify dafür zusammenbaut.
Ich muß in diesem Fall nur schauen, dass ein entsprechender CL zusammengebaut werden kann oder eine alternative Möglichkeit  zu nutzen wie du vorgeschlagen/hingewiesen hast, da dieser Vorgang eben nicht über das FHEMWEB initiiert wurde.

ZitatWaere sogar geneigt, sowas explizit unterbinden zu wollen.
Das wäre schade ...

Danke Rudi und noch einen schönen Restsonntag,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter