Autor Thema: Unterschied $hash->{CL}{canAsyncOutput} bei get- bzw. set-Kommando  (Gelesen 214 mal)

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1624
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 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
DbLog/DbRep mit MariaDB auf Synology 415+,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16902
Antw:Unterschied $hash->{CL}{canAsyncOutput} bei get- bzw. set-Kommando
« Antwort #1 am: 06 August 2017, 12:09:56 »
- 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.

Zitat
einen 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.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1624
Antw:Unterschied $hash->{CL}{canAsyncOutput} bei get- bzw. set-Kommando
« Antwort #2 am: 06 August 2017, 14:12:15 »
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.

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

Zitat
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 ...
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.

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

Danke Rudi und noch einen schönen Restsonntag,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
DbLog/DbRep mit MariaDB auf Synology 415+,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN