Module für XBMC

Begonnen von Dennis B., 06 Januar 2013, 22:32:24

Vorheriges Thema - Nächstes Thema

vbs

Eine Idee wäre, das über einen Watchdog zu machen. Also du würdest da so definieren, dass er nur die Lampen einschaltet, wenn nicht innerhalb von x Sekunden von Stop wieder Play kommt.

Eine andere Idee wäre, dass du ein "at" erzeugst sobald Stop passiert. Das at schaltet dann nach x Sekunden die Lampen an. Du müsstest dann jedoch noch in dem Play-notify gucken, ob das at exisitiert und dann ggf. löschen, weil es ja in dem Fall nicht greifen soll.

Nur Ideen... muss nicht funktionieren  ;)

Jumbo

das mit dem watchdog könnte funktionieren aber wie baust du den dann hier mit ein :


   if (ReadingsVal("NUC", "playStatus", "") eq "playing"){\
       fhem("set HUEDevice1,HUEDevice2,HUEDevice3 off");;\
    }\
    if (ReadingsVal("NUC", "playStatus", "") eq "paused"){\
       fhem("set HUEDevice1,HUEDevice2, HUEDevice3  on");;\
    }\
   if (ReadingsVal("NUC", "playStatus", "") eq "stopped"){\
       fhem("set Stuff1,Stuff2 100 0 10");;\
    }\
   if (ReadingsVal("NUC", "playStatus", "") eq "stopped"){\
       fhem("set HUEDevice1,HUEDevice2,HUEDevice3 on");;\
    }\

vbs

Die beiden stop-Ifs komplett rausnehmen und dann ein watchdog definieren in der Art:

define watchNuc watchdog NUC:playStatus.stopped 00:00:05 NUC:playStatus.playing set Stuff1,Stuff2 100 0 10

Jumbo

funktioniert nicht habe es jetzt so gemacht :

define notify_XBMC_status notify NUC:playStatus.* { if (ReadingsVal("NUC", "type", "") eq "movie"){\
   if (ReadingsVal("NUC", "playStatus", "") eq "playing"){\
       fhem("set Stuff1,Stuff2 0 0 7");;\
    }\
   if (ReadingsVal("NUC", "playStatus", "") eq "playing"){\
       fhem("set Stuff3,Stuff4 off");;\
    }\
   if (ReadingsVal("NUC", "playStatus", "") eq "playing"){\
       fhem("set HUEDevice1,HUEDevice2,HUEDevice3 off");;\
    }\
    if (ReadingsVal("NUC", "playStatus", "") eq "paused"){\
       fhem("set HUEDevice1,HUEDevice2,HUEDevice3  on");;\
    }\
   if (ReadingsVal("NUC", "playStatus", "") eq "stopped"){\
       fhem("set PIONEER listeningMode pureDirect");;\
    }\
   }\
}

define watchNuc watchdog NUC:playStatus.stopped 00:00:05 NUC:playStatus.playing set Stuff1,Stuff2 on

Johannes_B

Hi,

habe bei mir das Problem, dass - trotz fork:enable - FHEM nach einer nicht definierbaren Zeit hängen bleibt.
Nun versuche ich bei der Methode "XBMC_Ready" durchzublicken, was mir aber nicht so recht gelingen mag.  :o

Könnte mir mal jemand erklären wie die funktionieren soll?


Gruß,

Johannes
FHEM Control - an iOS app - available on the App Store:
https://itunes.apple.com/app/id936674170

Schlimbo

Hallo Johannes,

bei fork:enable bitte beachten, dass es dadurch zu Problemen beim speichern der fhem.cfg Datei,  bzw. durch das dadurch angetriggerte "rereadcfg" kommen kann.

Siehe hierzu: http://forum.fhem.de/index.php/topic,30633.0.html

vbs

#261
Benutzt du die Version hier aus dem Thread oder die "offizielle" aus fhem? Ich meine, ich hatte diese fork-Geschichte schonmal behoben in der Thread-Version. Bitte einmal damit testen... Da XBMC keinen Maintainer mehr hat, werden Bugs leider nicht mehr im fhem-Repo gefixt. Sämtliche Anfragen von mir dazu blieben leider bislang unbeantwortet.

@Johannes:
Also die Grobfassung ist so:
Wenn kein fork verwendet wird, dann wird versucht die Verbindung im Hauptthread mit Timeout aufzumachen (blockierend). Easy.

Wenn fork verwendet wird:
Beim ersten Aufruf von Ready wird der Prozess geforkt. Bei allen weiteren Aufrufen wird nur geguckt, ob der geforkte Prozess noch lebt. Wenn er noch lebt, dann wird nichts gemacht (also weiterhin Ready aufgerufen). Wenn er nicht mehr lebt, dann ist das das Zeichen, dass der geforkte Prozess die Verbindung öffnen konnte (und sich beendet hat). Nun wird im Hauptprozess die Verbindung normal (blockierend) geöffnet.
Der Fork-Prozess versucht einfach nur in einer Schleife, die Verbindung aufzubauen. Wenn es geklappt hat, dann schließt er sie jedoch sofort wieder und beendet sich. Das Beenden ist das Zeichen für den Hauptthread, dass er es jetzt versuchen soll.

Weiß nicht, ob ich das jetzt verständlich rüberbringen konnte :D

Rince

@vbs

ZitatThe source of this project is hosted on sourceforge, if you wish you can get
the latest version with the following command:

  svn co https://svn.code.sf.net/p/fhem/code/trunk/fhem

If you wish to contribute to the project, then
- create a sourceforge account
- send an email to the project manager to add you as developer to the project
  (right know this is r dot koenig at koeniglich dot de)
- check out the source
- if it is already checked out, it makes sense to do an update before
  implementing your changes:
   % svn update
- make your changes
- test if it is working (Really !!!)
- make an entry in the CHANGED file, giving your changes a "title".
- describe your changes in the file HISTORY, and dont forget to mention your
  name and the date of change
- it makes sense to do a "svn diff" before checking in the stuff with
  svn commit

Ich würde sagen, sourceforge Account erstellen und Rudi ne eMail schicken :)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

vbs

Ok, werd ich wohl nächstes Jahr nochmal einen Versuch starten ;)

Schlimbo

Hallo vbs,

danke für die Info, nutze die "offizielle" fhem Version, dachte bis heute, dass diese aktuell ist. Werde heute Abend mal die "Thread" Vesion testen.

Ist die Version aus diesem Post die aktuellste? http://forum.fhem.de/index.php/topic,10075.msg223863.html#msg223863

und gibt es irgendwo ein Changelog was alles zwischen der "offiziellen" und der "Thread" Version geändert/erweitert/gefixt  wurde?


vbs

Ja, das sollte der letzte Stand sein. Changelog gibt es nur im Thread verstreut. Änderungen waren von siggi und mir. Es war aber nicht viel. Aus dem Stehgreif fällt mir ein: das Verhalten bei fork und das Erkennen von Disconnects und das Abspielen von Datenbank-Einträgen (oder so ähnlich).

Schlimbo

So, habe gerade mal die 70_XBMX.pm hier aus dem Thread getestet und das "fork Problem"  ist damit behoben.
Dankeschön nochmal.

Gruß Schlimbo

siggi85

Changelog verteilt im Thread hier wie vbs schon geschrieben hat. Die Änderungen sind aber natürlich auch im html Teil des Moduls dokumentiert.
Ich drück dir die Daumen vbs, dass du die Version ins offizielle SVN bekommst. :)

hillbicks

Zitat von: siggi85 am 05 Juli 2014, 09:40:38
Anbei eine aktualisierte Version des XBMC Moduls (Quelle war die bereits editierte Version aus diesem Thread von vbs, als mit zusätzlichen Logfunktionen)

Neue Funktionen:
- openepisodeid oder openmovieid: startet den gewählten ID Eintrag aus der XBMC Datenbank. Kann aus dem Reading "episodeid" oder "movieid" abgelesen werden. Falls ein Resumepunkt vorhanden ist, wird die Wiedergabe automatisch ab diesem gestartet. Sollte keiner vorliegen, startet die Wiedergabe vom Start an.
set xbmc_device openepisodeid 123
- jsonraw: Hier können JSON Requests RAW abgesendet werden
set xbmc_device jsonraw {"params":{"item":{"episodeid":123},"options":{"resume":true}},"jsonrpc":"2.0","method":"Player.Open"}

Tester sind gerne willkommen.

EDIT: Getestet habe ich sowohl mit TCP als auch HTTP Konfigurationen.

Waerst Du so nett Deine config zu posten. bzw. zu beschreiben wie die Uebergabe von einem ans andere Mediacenter funktioniert? Mir ist leider nicht ganz klar wie man das am besten umsetzen kann :)

Tommy82

Hat sich in der zwischenzeit eigentlich etwas wegen dem MT für das XBMC Modul getan?
Fhem Cubitruck  Armbian Buster with Linux 5.3.9-sunxi
HM-CC_RT-DN, HM-Sec-RHS,HM-Sec-SD, HM-Sec-SCo,IT1500,1xIT GRR-3500 Fritz!Dect200,Powerline546E,Enigma2 Modul mit 3 Vu+,Wol Modul für WinServer2016 und WinServer 2019,FB6590
Allnetl Wandtablett mit FTUI