Geänderte Readings während eigener Subroutine einlesen

Begonnen von siggi85, 07 Juli 2014, 18:00:39

Vorheriges Thema - Nächstes Thema

siggi85

Hallo,
ich möchte von einem XBMC Device die Wiedergabe stoppen, und das angegebene Video auf einem anderen XBMC wiedergeben. Das funktioniert auch soweit.
Sobald die Prozedur fertig ist, möchte ich die "Quell Episoden ID" und die "Ziel Episoden ID" miteinander vergleichen um im Erfolgsfall eine Nachricht auf dem beteiligten Fernseher auszugeben. Leider wird, trotz erfolgreicher Weitergabe des Videos, keine Ausgabe angezeigt weil die "Ziel Episoden ID" noch den Wert kurz vor der Videoweitergabe hat. Ich habe das Gefühl, dass während einer Subroutine die Readings eines Device eingefroren werden (zumindest aus Sicht der Subroutine) und quasi alle ReadingsVal etc. ausgeführt werden, und dann erst der Restcode. Da sich ein Wert im Programmverlauf aber ändert und ich das abprüfen möchte, stört dieser vermeintliche Zustand.

Mache ich etwas falsch oder habe einen Denkfehler? Oder ist das eine Eigenart von FHEM die ich bis jetzt noch nicht kennen gelernt habe?

Anbei der Code (verkürzt, dass er nur mit Episoden funktioniert):

##########################################################
# XBMC to XBMC
# Aktuelles Video von einem XBMC auf einem anderen XBMC wiedergeben
sub xbmc_to_xbmc($$) {
my ($qxbmc, $zxbmc) = @_;
fhem "set $qxbmc stop";
my $qtype = ReadingsVal("$qxbmc","type","nichts");
if ( $qtype eq "episode" ) {
  my $qid = ReadingsVal("$qxbmc","episodeid",0);
  fhem "set $zxbmc openepisodeid $qid"; # Durch diesen Befehl ändert sich das Reading "episodeid" auf dem $zxbmc Device
  fhem "set $zxbmc pause";
  sleep(2);
  my $zid = ReadingsVal("$zxbmc","episodeid",0); # Trotz geändertem reading auf dem $zxbmc Device wird hier der alte Wert ausgelesen
  fhem "set $qxbmc msg Weitergabe \"Q $qid  Z $zid\""; # Zum Troubleshooten des Problems, Ausgabe der IDs in XBMC
   if ( $qid == $zid ) {
    fhem "set $qxbmc msg Weitergabe \"Videoweitergabe erfolgreich\"";
   }
}
}

P.A.Trick

Ich stelle mal die Vermutung auf, dass das sleep 2 dein Problem ist! Vielleicht trennst du die beiden Aktionen durch ein Notify?
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

siggi85

Zitat von: P.A.Trick am 07 Juli 2014, 21:24:19
Ich stelle mal die Vermutung auf, dass das sleep 2 dein Problem ist!
Das sleep gehört schon zu meinem Testszenario, da ich dachte das Reading wird nicht schnell genug aktualisiert. Habe es auch ohne sleep und mit fhem sleeps probiert (sleep 2 quiet).
Was mich auch auf meine Vermutung bringt, ich hab das Skript mal mit mehreren sleep(3) Kommandos zwischendrin gebaut, dann ist die Summer aller Sleeps nichts passiert und dann wurde die komplette Abarbeitung aller FHEM Kommandos auf einmal durchgeführt. Zwischen dem ersten Stop und der Episodeübergabe müssten so mind 9 Sekunden liegen, aber es ist alles auf einmal passiert. Als wenn der gesamte FHEM Code erst nach der Ausführung aller Perlsegmente durchgeführt wird. (wie ein Cache, guck dir erst mal alle Bedigungen an, geh den Weg durch und danach werden alle gesammelten FHEM Kommandos hintereinander ausgeführt).

Zitat von: P.A.Trick am 07 Juli 2014, 21:24:19
Vielleicht trennst du die beiden Aktionen durch ein Notify?

Das könnte funktionieren. Das werde ich demnächst mal testen. :)

P.A.Trick

Denke daran das ein Perl sleep das gesamte fhem stoppt, da es "nur" ein Perl Skript im singlethreaded Modus ist!
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

siggi85

Zitat von: P.A.Trick am 07 Juli 2014, 21:36:57
Denke daran das ein Perl sleep das gesamte fhem stoppt, da es "nur" ein Perl Skript im singlethreaded Modus ist!

Achso, das macht Sinn. Guter Hinweis!

justme1968

fhem ist nicht multithreaded.

wärend deine sub läuft läuft nur diese und sonst nichts. fhem ändert im hintergund nichts asynchron.

du musst mit notifys auf das ändern eines readings reagieren. du kannst nicht aktiv darauf warten.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

P.A.Trick

Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

P.A.Trick

Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn