Zusammenfassende Doku: Samsung TV und FHEM

Begonnen von KölnSolar, 17 Januar 2018, 11:20:20

Vorheriges Thema - Nächstes Thema

KölnSolar

#15
Sicherlich ist die im vorherigen Post beschriebene Bildschirmnachrichtenausgabe die für viele wichtigste Form der Medienausgabe auf dem Bildschirm. Letztendlich ist es aber nur eine Sonderform der allgemeinen Medienausgabe per DLNA mit dynamischer Mediengenerierung per RSS-Modul.

Tatsächlich lassen sich mit DLNA alle Medien, ob Video, Audio, Foto, die auf einem Medien-Server gespeichert sind,  auf den TV "pushen". Das eröffnet dann für die Hausautomatisierung unendlich viele Anwendungsmöglichkeiten. Ich zähle nur mal ein paar Ideen als Anregung dazu auf:
- es klingelt an der Tür --> Kamera nimmt Bild auf --> Bild wird auf dem TV angezeigt
                                   --> Video- oder Audio-Konserve werden abgespielt

- Einbruchalarm wird ausgelöst --> TV einschalten --> dem Einbrecher wird per Konserve gezeigt, dass sein Einbruch registriert wurde

- sonstiger Alarm --> Info auf dem Bildschirm mit konkretem Auslöser des Alarms per Video-, Audio-, Foto-Konserve
- Termin --> Terminerinnerung per per Video-, Audio-, Foto-Konserve
.
.
.
.

Für die praktische Umsetzung in FHEM bedarf es nur der ereignisgesteuerten Nutzung des DLNAClient-Moduls(sobald DLNARenderer für Samsung funktioniert, natürlich dieses offizielle Modul). Die Voraussetzungen wurden im vorherigen Post beschrieben.  ;)

Mit der optionalen Definition stellt das SamsungAV-Modul ein paar Readings mit Informationen zum TV zur Verfügung. Es gibt einen zusätzlichen Befehl sayText, über den eine TTS-Funktion realisiert ist. Ein weiterer Befehl ist volume, welcher das einstellen einer absoluten Lautstärke ermöglicht.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

#16
Was DLNA eigentlich heißt und ist, habt Ihr doch hoffentlich bereits hier gelesen.  ::)
Der DLNARenderer ist also eigentlich ein DMC. Er verknüpft Ausgabegeräte(z.B. Samsung TV) mit Mediendateien(Medienserver), übernimmt die Steuerung dieser Verbindung. Was einfach klingt, ist technisch recht komplex. Deshalb ist das Modul in der Handhabung auch etwas außergewöhnlich für FHEM.

Man definiert als erstes ein Masterdevice. Das ist dann später die Zentrale, wo auch gewünschte oder notwendige Attribute definiert werden. Nach dessen Definition und dem save der .cfg ist zwingend ein shutdown/restart erforderlich. Erst und nur dadurch werden manche Attribute wirksam ! Beim restart wird dann das define nebst Attributen durchlaufen und die Zentrale hat sich konfiguriert. Konfiguriert heißt, dass das Modul 3 weitere Systemdevices automatisch im room hidden angelegt hat. Außerdem werden alle DLNAdevices aufgefordert sich zu melden. Geben Sie eine Rückmeldung(können natürlich nur die, die on sind  ;)), werden sie automatisch im room unsorted oder im room des Attributs defaultRoom angelegt. Die Fähigkeiten der devices werden in der Zentrale gespeichert. Das FHEM device des physischen devices dient der User-Steuerung. Dabei bedient es sich der Informationen der Zentrale.. Auch werden  Veränderungen(z.B. Lautstärkeänderung per Fb) des physikalischen devices in Readings und events umgesetzt.

Wie funktioniert das und welche Rolle spielen die 3 Systemdevices dabei ?
Jedes der Systemdevices lauscht auf einem Port und verarbeitet eingehende Daten entsprechend seines Zwecks:
Das Masterdevice setzt EINMALIG bei dessen Definition einen Search-Request ab, auf den dann alle physischen Geräte, die online sind, auf dem mitgegebenen Port antworten können(und das in der Regel auch tun). Die Antworten werden von Systemdevice Nr. 1 empfangen und wie oben beschrieben verarbeitet. Danach erfolgt NIE wieder ein "search" bis zum nächsten FHEM-Start. Deshalb haben Veränderungen der Attribute .....IP oder env.... auch keine Auswirkung im laufenden Betrieb.

Warum werden später trotzdem neue Geräte erkannt ?
Weil auch jedes physische device bei Ein-,Ausschalten eine Broadcast-message sendet, nach dem Motto: Hallo hier bin ich bzw. ich bin dann mal weg. (Funktioniert natürlich nicht, wenn man, wie ich, hart per Funksteckdose abschaltet  ) Diese Nachrichten werden an Port 1900 "verschickt". Sie empfängt das System-device Nr. 2. Ist das device noch nicht vorhanden, wird es angelegt. Wurde es abgeschaltet, bekommt es den state absent. Nachteilig dabei ist, dass auch nicht DLNA-UPnP-Geräte solche messages auf Port 1900 schicken, z.B. Access Points. Das kann zu Problemen führen, weshalb sich der Ausschluss per ignoredIP empfiehlt.   

Bliebe noch System-device Nr. 3. Hier macht das Modul einen eigenen Port auf, teilt dem physischen device mit, dass es auf diesem Port lauscht, um Mitteilungen über Zustandsveränderungen am device zu erfahren. Das ist dann der subscription-process. Dabei wird auch vereinbart wie lange diese Vereinbarung Gültigkeit hat. Diese muss dann natürlich auch immer wieder erneuert werden, renewal halt. Über diesen Weg bekommen wir dann die Readings-Aktualisierung, events in FHEM.

Nochmal weil wichtig zum Verständnis von Problemen:
- Attribute werden nur beim start von FHEM interpretiert. Bei deren Änderung: save/shutdown/restart erforderlich !
- Es ist ein Universalmodul für alle devices, die den DLNA-Standard unterstützen. Theoretisch.
- Master-, 3 System- und das Userdevice(=physischem device) arbeiten verzahnt zusammen.
- Nicht jedes physische device unterstützt dieselben services und actions
- Die physischen devices haben in der Regel nur einen eingeschränkten und unterschiedlichen Umfang von zulässigen Mediendateiformaten
- Manche devices erfordern Spezialattribute beim Master device(s.o.). Es kann aber nur genau ein Masterdevice konfiguriert werden. Der User kann möglicherweise daher nicht alle seiner Geräte in einer FHEM-Installation nutzen. Wahrscheinlich gibt es daher auch Probleme, wenn andere Module dieselben UPnP-Perlmodule nutzen, auf denen das DLNA_Renderer-Modul aufbaut, z.B. das SONOS-Modul.


Das Beispiel für die Definition für Samsung TV und ein Anwenderbeispiel findet Ihr hier
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

#17
Es gibt immer wieder Verwirrung, mit welchen RC-Befehlen sich der TV aus- oder gar einschalten lässt.

Bei den TVs/firmware älteren Datums wird der Befehl poweroff für das Ausschalten des TV unterstützt. In der Regel hat der Befehl poweron keine Funktion, auch wenn sich das syntaktisch ableiten ließe. :-X

Bei neueren Modellen/firmware muss man den Befehl power zum Abschalten nutzen. Auch hier gibt es in der Regel keinen Einschaltbefehl. Bei wenigen TVs(ich denke, dass das in der Regel nur auf Q-Serie zutrifft) kann man den power-Befehl auch zum einschalten benutzen.

Obwohl also in der Regel kein RC-Befehl das Einschalten unterstützt, lässt sich das über folgende Möglichkeiten lösen:
1. Hartes Aus-/Einschalten über eine Funksteckdose. Der TV startet so, wie er im Ausschaltzustand war, also On und vorheriger Kanal, wenn der TV on war. Standby, wenn er im standby war. Ich hab das 5 Jahre praktiziert, ohne dass der TV das übel genommen hat. Aber wer weiß....
2. über das WOL-Modul. Zumindest bei neueren Modellen ist dies möglich. Bei mir sogar bei einer WLAN-Verbindung(obwohl es nicht zuverlässig funktioniert) Ich habe das device wie folgt definiert
define WOL_TV_device WOL MACdesTV IPdesTV UDP
u. falls man per poweron mit dem TVdevice schalten möchtedefine TV_poweron notify  TVdevice:poweron set WOL_TV_device on
Ob die Schnittstellen überhaupt WOL-fähig sind, sollte man außerhalb FHEM testen(z.B. Netzwerkverbindungen im FritzBox-Menü).
3. Falls ein Linux-Gerät(z.B. Raspberry ) via HDMI am TV angeschlossen ist , mittels echo 'on 0' | cec-client -s -d 1einschalten. cec-client ist im Paket libcec enthalten.

Und bevor jemand schreibt, dass bei ihm das Einschalten funktioniert, es gibt noch eine Besonderheit der neueren TVs: Sie lassen sich noch ca. 1 min. nach dem Abschalten mit power wieder Einschalten. Aber eben auch nur für diesen kurzen Zeitraum. :-X
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

Hier findet Ihr die Info zur Vorgehensweise zum debugging des TV.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

#19
Die Funktionalität von DLNAController mit UPNPController ist identisch mit dem  DLNARenderer.

Technisch hat sich einiges verbessert. Technische Funktionen wurden nun getrennt in den universellen UPNP-Teil und die spezifischere DLNA-Funktionalität.

Dadurch hat man im UPNP-Teil nun zusätzlich eine Übersicht sämtlicher devices mit UPNP-Funktionalität mit deren services und weiteren Informationen, wie z.B. den on-/offline status dieser devices und services.

Im Augenblick befindet sich das Modulpaket in der Entwicklung. Hier findet Ihr den Sourcecode und weitere Erläuterungen.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar


WIP

Dies ist ein Dokuthread. Bitte keine posts !v
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt