Modul für Kodi (ehemals 70_XBMC)

[ivor]

Die kann ich über Fhem/siri antriggern und kodi fährt dann automatisch hoch. Nur beim Abschalten muss man ne Pause einbauen, also erst kodi runterfahren, 50s warten, dann SD aus.

Bei mir ähnlich, ich schalte den Strom vom Monitor und Raspi (Kodi) via Esera Modul an. Das ausschalten wollte ich jedoch kontrolliert machen, da ich im Raspi keine SD Karte will, sondern der bootet via PXE und NFS. Damit ich das kontrolliert runter fahren kann, pinge ich den Raspi regelmässig an und wenn der Strom auf ON ist und der Raspi keine Antwort auf Ping gibt, setze ich den Strom auf OFF (das Ein/Ausschalten erfolgt bei mir via Verstärker):

Code Auswählen Erweitern

# Kodi definieren
define RaspiMM01_KODI KODI 10.4.11.20 tcp

# Ping definieren
define RaspiMM01_ping PRESENCE lan-ping 10.4.11.20

# Kodi ausschalten
#   wenn Ping nicht reagiert und
#   wenn der Strom eingeschaltet ist von Kodi (Raspi) und
#   wenn der Verstärker ausgeschaltet ist
define RaspiMM01_off DOIF ([RaspiMM01_ping:presence] eq "absent" and \
                           [esera_sw_altb_eg_raspi_tv:out] == 1 and \
                           [esera_dio_altb_eg_stube_verstaerker_status:in] == 0) (set esera_sw_altb_eg_raspi_tv off)

# Kodi einschalten
#   wenn Ping nicht reagiert und
#   wenn der Strom ausgeschaltet ist von Kodi (Raspi) und
#   wenn der Verstärker eingeschaltet ist
define RaspiMM01_on DOIF ([RaspiMM01_ping:presence] eq "absent" and \
                           [esera_sw_altb_eg_raspi_tv:out] == 0 and \
                           [esera_dio_altb_eg_stube_verstaerker_status:in] == 1) (set esera_sw_altb_eg_raspi_tv on)

# Kodi herunterfahren
#   wenn Ping reagiert und
#   wenn der Verstärker ausgeschaltet ist
define RaspiMM01_shutdown DOIF ([RaspiMM01_ping:presence] eq "present" and \
                           [esera_dio_altb_eg_stube_verstaerker_status:in] == 0) (set RaspiMM01_KODI shutdown)


gruss ivo

[beaune]

Hallo,

ich hätte mal ne Verständnisfrage: Wie kriegt fhem eigentlich mit, wenn der Kodi-Rechner ausgeschaltet war und dann wieder kommt? Fakt ist: es funktioniert irgendwie. Vermutlich durch zyklischen Ping oder so. Kann man machen, aber so richtig mag ich so einen Netzwerktraffic nicht. Ist zwar nicht viel, aber summiert sich auch alles, und wenn man zu selten pingt, dauert die Reaktion eben auch.

Meide Fragen/Ideen dazu:

• Macht das Modul in dieser Frage einen Unterschied zwischen http und tcp-Verbindung?
• Könnte nicht Kodi beim Start irgendeinen Broadcast aussenden, den dann alle im Subnetz bekommen und entsprechend reagieren?
• Oder könnte man dafür Bonjour benutzen, wo es zwar etwas ergleichbares wir pings gibt, die aber verwaltet und auf ein minimales Maß reduziert werden?

Gruß
Beaune

[ivor]

Wie kriegt fhem eigentlich mit, wenn der Kodi-Rechner ausgeschaltet war und dann wieder kommt?

Salü Beaune

Das sollte eigentlich in meinem obigen Beispiel ersichtlich sein:

Code Auswählen Erweitern

# Ping definieren
define RaspiMM01_ping PRESENCE lan-ping 10.4.11.20

Funktioniert prima.

[vbs]

ich hätte mal ne Verständnisfrage: Wie kriegt fhem eigentlich mit, wenn der Kodi-Rechner ausgeschaltet war und dann wieder kommt?

Das Modul versucht sich alle 60 Sek. zu Kodi zu verbinden. Das ist ein Standardverhalten von FHEMs DevIO-Modul soweit ich weiß.

Gibt sicherlich auch viele Möglichkeiten, das ohne Polling zu realisieren. Die Lösung sollte dann aber plattform- und hardwareübergreifend robust funktionieren und muss dann sowohl in Kodi als auch in FHEM eingebaut und gepflegt werden. Im besten Fall über Subnetzgrenzen hinweg funktionieren und per (HTTP-)Proxy routbar sein.

Meiner Meinung nach ist da aber kein Blumentopf mit zu gewinnen. Der Traffic der verursacht wird, wenn alle 60 Sek. versucht wird, eine TCP-Verbindung aufzubauen liegt sehr nahe an 0. Spannend fände ich aber, wenn eben FHEM augenblicklich mitbekommen würde, wenn Kodi verfügbar ist und nicht (wie im Worst-Case) erst nach 60 Sek.

[beaune]

Irgendwie störts mich halt in meiner "Ingenieursehre", dass so viele unnütze Anfragen durchs Netzwerk gehen und suche irgendwie nach der optimalen Lösung. Wenn es nur das Kodi-Device alle 60s wäre, wär das sicher kein Problem. Aber solche Verbindungsüberwachungen machen andere Devices auch, und zur reinen Netzwerklast kommen ja auch Interruptlast , Contextswitch etc. dazu. Wenns nicht anders geht - ok, aber ich meine es müßte besser gehen.

Hab jetzt mal spaßeshalber einen zeroconfServiceBrowser auf meinem PC installiert. Und siehe da: schaut man sich damit an, welche Remote Audio Output Protocol-Teilnehmer bekannt sind, findet man dort auch meinen Kodi-Raspi. Schaltet man Kodi ein-/aus, ist diese Info nach spätestens 5s auch hier sichtbar, ohne dass ich auf der Kodi-Seite irgendwas installiert hätte, außer Airplay einzuschalten. Übrigens genauso schnell merken auch andere Apple-Geräte, dass ein Airplay-Device dazu gekommen oder ausgefallen ist. Das scheint mir schon ziemlich gut und auch effizient gelöst zu sein, und genau von dieser Info könnte auch das Kodi-Modul partizipieren.

Die Frage ist nur, wie man aus fhem heraus so eine Abfrage realisieren kann, bzw. eigentlich will man ja einen Event von zeroconf/bonjour haben. Wenn das ginge, könnte man ja gezielt das Kodi-Device mit set quit beenden oder mit set connect die Verbindung wiederherstellen, bzw. andere Aktionen initiieren.

Vielleicht ist das ja auch tatsächlich eher was, was man im PRESENCE Modul als eine neue Option zur Verbindungsüberwachung unterbringen könnte. Aktuell hilft dieses Modul meiner Meinung nach nicht, denn pollen kann das Kodi-Modul ja auch.

[vbs]

Eigentlich will man man doch aber nicht wissen, ob ein bestimmtes Gerät online ist, sondern eigentlich ist ja relevant, ob der Kodi-Prozess läuft. Das mag manchmal Hand in Hand gehen, aber das muss nicht zwingend so ein (wie z.B. bei mir). Darum bin ich nicht sicher, ob zeroconf der richtig (im Sinne von "allgemeingültige") Ansatz ist.

Wenn das in deinem Fall aber so ist, dass "Rechner online" -> "Kodi online", dann kannst du dir da sicherlich was basteln mit zeroconf.

[beaune]

Du hast völlig Recht: die Frage ist nicht, ob der Rechner an ist, sondern ob der Kodi-Prozess läuft. Da hab ich mich unklar ausgedrückt, denn genau das hab ich auch getestet:

• Laufender Raspi mit offener Shell
• Kodi aus der Shell gestartet -> erkennt der zeroconfservice-Browser in < 5s
• Kodi menügesteuert beendet -> erkennt der zeroconfservice-Browser in < 5s
• ...

Also der Raspi war immer an und immer erreichbar, nur der Kodi-Prozess wurde gestartet und beendet. Also genau das, was Du auch rauskriegen möchtest. Für mich wär das insbesondere auch deshalb interessant, weil ich zusätzlich noch mehrere Airplay-Lautsprecher betreibe, die ich mit Hilfe von forked-daapd über Kodi ansteuere. Da stellt sich dieselbe Frage, ob die verfügbar sind, und ob also eine Bedienung/Einlesen des Istzustands in fhem möglich ist. Das kann ich zur Zeit auch nur zyklisch Pollen durch den Aufruf der forked-daapd JSON API rauskriegen und hätte hier auch viel lieber einen über zeroconf generierten Event.

Also ich hätte schon Interesse da mal ein bisschen zu forschen, mir fehlt nur der Ansatz. Gab es vielleicht schon mal irgendwelche Ansätze mit fhem und zeroconf? Oder irgendein anderes Beispiel, an dem ich mich orientieren könnte? Hier wär ich für jede Hilfestellung dankbar!

[MadMax-FHEM]

Allerdings sind die (ganzen) "Discovery-Dienste" Multicast...

Von der Netzwerkbelastung:

Broadcast -> ganz schlimm

Multicast -> "schlimm"

Unicast ("normale" Anfrage) -> wenig

Also ist es doch fraglich, was ist "schlimmer":

Geräte die "ständig" multicasten (was ich bie MIR soweit es geht deaktiviere! Und auch zwischen VLANs blocke) oder mal eine "unnötige" Anfrage per TCP, die dann eben "leer läuft"...

Nur so als Anmerkung bzgl. Netzwerklast etc.

Gruß, Joachim

[vbs]

Also der Raspi war immer an und immer erreichbar, nur der Kodi-Prozess wurde gestartet und beendet. Also genau das, was Du auch rauskriegen möchtest.

Ohh das ist super, gefällt mir. War mir so nicht klar.

Leider kann ich da inhaltlich nicht weiterhelfen, da ich da zu wenig Ahnung von habe 

Für mich spielt die Netzwerklast in beiden Variante nicht so die große Rolle, aber wenn FHEM praktisch sofort bemerken würde, ob Kodi erreichbar bzw. nicht erreichbar ist, anstatt alle 60 Sek. zu pollen, dann wäre das aus meiner Sicht ein echter Mehrwert.

EDIT:
Also nur zum Verständnis:
Kodi schickt aktuell also schon solche zeroconf-Events von sich aus oder musstest du da noch irgendwas für machen?

[MadMax-FHEM]

Ich denke unter Einstellungen: Zeroconf aktivieren...

(was ich deaktiviert habe   / bzw. nicht weiß was "Standard" ist   )

P.S.: bzgl. Netzwerklast war ja nur, weil eben @beaune genau das "angemerkt" hatte

Gruß, Joachim

[beaune]

Hab gerade nachgeschaut: ja zeroconf habe ich wohl unter Einstellungen/Dienste in Kodi aktiviert, und Airplay auch. Sonst hab ich aber nichts besonderes gemacht.

Hinsichtlich der Netzwerklast muß ich eingestehen, dass ich auch nicht ganz sicher bin, wie zeroconf ganz genau funktioniert. Mein bisheriges Verständnis war aber, dass sich die Services "an-/ und abmelden", also eben Kodi von sich aus beim Start etwas sendet, was dann alle zeroconf-fähigen Geräten im Netzwerk mitkriegen und für sich speichern. Genau diese vorhandene Information würde ich gerne lokal abholen, und eben nicht zyklisch eine Discovery starten. Es mag sein, dass es Situationen einer höheren Netzwerklast gibt, z.B. beim Einschalten, wenn sich alle Services melden. Aber es sollte eigentlich nicht zu einer zyklischen Kommunikation im Sekundenbereich kommen. Genau die würde mich ja stören, und führt letztendlich dazu, dass ich eher mit langen Reaktionszeiten a la 60s lebe. Bin ich da auf dem falschen Dampfer?

[MadMax-FHEM]

Naja brauchen wir "hier" nicht im Detail ergründen

Aber es müssen ja auch zyklisch Pakete gesendet werden (und das halt Multicast -> "höhere" Belastung als Unicast -> z.B. ping), weil:

entweder der Server broadcastet -> wie kriegt ein "Interessierter" mit, wenn er das erste (und einzige) Paket nicht mitbekommen hat

oder der Client/"Interessierte" ruft/frägt ab und an: was ist denn so an Diensten da: es kann ja später ein Server/Dienst angeschaltet werden

Vermutlich ist es eine Mischung aus alldem
EDIT: evtl./vermutlich nicht "so zyklisch" wie ein "zyklischer Ping"... aber eben Multicast statt Unicast... (also letztendlich [fast] egal)

Eine Anmerkung noch: Nessus (Netzwerk-Security-Check-SW) "meckert" zumindest wenn ein Gerät zeroconf "hat"

Wie geschrieben: alles nicht (wirklich) schlimm und hat nat. schon Vorteile (für "Noobs" bzgl. Netzwerk / oder wenn man Apple ist und es seinen Anwendern einfach machen will: "geht halt")

"Profis" richten das Netzwerk ein und haben dann eben optimale Performance (und nehmen norm. "Abstand" von Broadcast und eigentlich soweit möglich auch Multicast)...

Und wie ebenfalls geschrieben: ich habe es nur angesprochen, weil eben der "Ursprung" war, dass ja zyklische Pings etc. (aber die sind "Unicast" -> wenigste Belastung) das Netzwerk (unnötig) "belasten"

Und nun bin ich ruhig 

Gruß, Joachim

[Frank_Huber]

Hi,

Ich habe das Kodi Modul auf mehreren Instanzen am laufen.
überall unauffällig ausser auf einer. Hier kommt bei jeden FHEM Start folgendes im Log:

Code Auswählen Erweitern

2021.02.22 08:04:25 1: PERL WARNING: Prototype mismatch: sub main::encode_json ($;$) vs ($) at /usr/share/perl/5.28/Exporter.pm line 66, <$fh> line 645.
2021.02.22 08:04:25 1: PERL WARNING: Prototype mismatch: sub main::decode_json ($;$$) vs ($) at /usr/share/perl/5.28/Exporter.pm line 66, <$fh> line 645.
2021.02.22 08:04:25 1: PERL WARNING: Prototype mismatch: sub main::encode_json ($) vs ($;$) at ./FHEM/70_KODI.pm line 18.
2021.02.22 08:04:25 1: PERL WARNING: Prototype mismatch: sub main::decode_json ($) vs ($;$$) at ./FHEM/70_KODI.pm line 18.

Die Exporter.pm und FHEM sind überall auf der gleichen Version.
Das einzige dass ich als Unterschied sehe ist dass hier ein RPI4 für Kodi werkelt. Die anderen KODIs laufen auf RPI3 und zwei auf LePotato.

Jemand ne Idee wo das herkommt?

/Frank

[vbs]

De geht es ja um Funktionen, die aus dem JSON-Modul importiert werden. Ich vermute, dass du da unterschiedliche Versionen verwendest?

Oder Perl ist irgendwie anders und meckert das nur auf dem einen System an.

[Frank_Huber]

Raspian, Perl und Kodi sind alle auf der gleichen Version.
Hab auch die Exporter.pm verglichen, gleiche Größe, gleiches Datum.

auch Libreelec ist auf der gleichen Version. nur eben RPI3 vs RPI4. Die LePotatoe haben ne noch ältere Libreelec, aber auch de keine Warnings.

Mich stört es nicht wirklich. aber wer weis was daraus noch wird.