Hallo,
ich musste mein Modul 70_NEUTRINO.pm für bestimmte Sat Receiver Boxen auf HttpUtils_BlockingGet umstellen. Leider kann es in bestimmten Situationen zu einen Crash auf den boxen führen wenn die Anfragen über HttpUtils_NonblockingGet kommen. So wie es sich aktuell zeigt hat die Box wohl ein Problem mit der asynchronen Verarbeitung mit solchen Anfragen.
So jetzt zu meiner Frage. Gibt es eine Möglichkeit das HttpUtils_NonblockingGet so einzusetzen dass ich meine Anfrage in eine art Warteschlange stelle und diese wieder synchron abgearbeitet wird?
Gruß
Michael
Klar. Du musst nur die Warteschlange und die Abarbeitung selbst implementieren.
Hast Du mir da eventuell eine Vorlage dafür an der ich mich orientieren kann?
Schau dir mal YAMAHA_BD an. Da ist sowas relativ simpel implementiert.
Zitat von: Markus Bloch am 19 Juli 2017, 08:09:42
Schau dir mal YAMAHA_BD an. Da ist sowas relativ simpel implementiert.
Hallo Markus,
die YAMAHA_BD Vorlage hat mir geholfen. Was mir allerdings aufgefallen ist, ist dass der Speicherverbrauch meines Modules extrem angestiegen ist. Wenn ich ein "list devicename" durchgeführt habe ist hier folgendes aufgefallen:
helper:
ADDRESS 10.10.0.113
PORT 80
RUNNING_REQUEST 0
CMD_QUEUE:
HASH(0x69b8b88)
HASH(0x693ee30)
HASH(0x4f4c858)
HASH(0x69b8498)
HASH(0x4f882a8)
Je länger der FHEM Server läuft um so mehr HASHes sammeln sich hier an. Eigentlich habe ich deinen Code fast 1:1 umgesetzt, von daher gehe ich davon aus dass dein Modul sicherlich dasselbe Problem hat.
Ich habe jetzt in meinem Modul in der ReceiveCommand Funktion noch folgenden Eintrage gemacht, und damit ist dann auch der Speicherverbrauch wieder normal.
delete($hash->{helper}{CMD_QUEUE});
Zitat von: michael.winkler am 19 Juli 2017, 22:11:54
Ich habe jetzt in meinem Modul in der ReceiveCommand Funktion noch folgenden Eintrage gemacht, und damit ist dann auch der Speicherverbrauch wieder normal.
Das kann ich so nicht bestätigen. Hier mal ein list <name> meines BD-Players mit YAMAHA_BD:
Internals:
CFGFN
CHANGED
DEF 192.168.179.36
FIRMWARE 1.387M0101
MODEL BD-S677
NAME BD_Player
NR 186
STATE off
TYPE YAMAHA_BD
READINGS:
2017-07-19 22:13:22 contentType video
2017-07-19 22:13:22 currentChapter 4
2016-01-23 15:01:49 currentMedia SETUP
2017-07-19 22:13:22 currentTitle 4
2017-07-19 22:13:22 currentTrack 0
2017-07-19 22:13:22 discType DVD
2017-07-19 22:13:22 error none
2017-07-19 22:13:22 input Mediacenter
2017-07-19 22:13:22 playStatus play
2017-07-19 22:13:22 playTimeCurrent 00:41:17
2017-07-19 22:13:22 playTimeTotal 00:00:00
2017-07-19 22:13:22 power off
2017-06-18 22:30:35 presence present
2017-07-19 22:13:22 state off
2017-07-19 22:13:22 totalTracks 0
2017-07-19 22:13:22 trayStatus close
2017-07-19 22:13:22 trickPlay Normal
helper:
ADDRESS 192.168.179.36
AVAILABLE 1
DISABLED 0
OFF_INTERVAL 30
ON_INTERVAL 30
RUNNING_REQUEST 0
CMD_QUEUE:
Attributes:
Licht Gesamte_Wohnung
alias BD Player
event-on-change-reading state
group Multimedia
icon scene_scene
model BD-S677
room Wohnzimmer
userattr Licht Licht_map structexclude
webCmd on:off:play:pause:skip forward:statusRequest
Das wichtige dabei ist die Zeile 607 in der Funktion YAMAHA_BD_HandleCmdQueue($) (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/71_YAMAHA_BD.pm#L607):
my $request = pop @{$hash->{helper}{CMD_QUEUE}};
Die Perl-Funktion pop() gibt das letzte Element eines Arrays zurück und
löscht dieses aus dem Array. => https://perldoc.perl.org/functions/pop.html
Wichtig sei dabei: Die Funktion YAMAHA_BD_HandleCmdQueue() MUSS IMMER am Ende von YAMAHA_BD_ParseResponse() aufgerufen werden, damit weiter Commands, die in der Queue sich befinden anschließend als nächstes sofort gesendet werden. Genauso muss YAMAHA_BD_HandleCmdQueue() ebenfalls IMMER am Ende von YAMAHA_BD_SendCommand() aufgerufen werden, da dort die Queue befüllt wird.
Gruß
Markus
Danke für die schnelle Antwort.
Die letzte Zeile in der Response Funktion ist mir nicht aufgefallen.
Hätte ich Grundsätzlich hier dasselbe erreicht, oder lösche ich mir dadurch alle noch anstehenden Querys?
delete($hash->{helper}{CMD_QUEUE});
Gruß
Michael
Damit wird die gesamte Warteschlange gelöscht und anstehende Queries oder Set-Kommandos vom User sind damit weg.
Gruß
Markus