FHEM -> Samsung TV mit Tizen

Begonnen von Florian_GT, 12 September 2016, 00:15:35

Vorheriges Thema - Nächstes Thema

alru

Zitat von: KölnSolar am 10 Juni 2020, 17:29:08
...Wenn Dir der zeitnahe Status wichtig ist, dann kannst Du es mit dem DLNARenderer probieren. ...

Das trifft sich gut, denn der DLNARenderer ist ohnehin die nächste geplante Aktion. Danke auch hier für den Tipp.
Gruß,

Stefan
(Raspi 3B - Stretch / HM-LGW / HomeMatic / MySensors)

KölnSolar

Ich überlege gerade, dass es Sinn mache könnte die DLNRenderer-Info per notify zu übernehmen. Evtl. könnte ich es sogar per notifyFN ins Modul einbauen. Ich denke, dass einige den eventgesteuerten use case TVoff->Aktion bzw. TVon->Aktion haben. Was meint ihr(Daumenklick genügt  ;))
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

Ich habs dann schon einmal testweise implementiert. Klappt eigentlich prima.

ABER: bisher hab ich den Status weder beim S.AV-device, noch beim DLNA-device genau beobachtet. Es passiert leider folgendes im DLNA-device:
- TV ausschalten -> sofort Status offline -> reproduzierbar 56s später geht er wieder online -> weitere 83s später ist er endgültig offline
- TV einschalten -> sofort Status online

So also nicht zu gebrauchen. Warum auch immer versetzen die Koreaner den TV in eine Art "pre-standby"  :o, wo der Bildschirm(und Ton) ausgeschaltet sind, die Netzwerkverbindung u. -dienste aber aufrecht erhalten oder gar neu aufgebaut werden.

Könnt Ihr mal über das DLNA-device die timestamps beobachten, ob sich das bei Euch zeitlich ähnlich verhält.
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

alru

Zitat von: KölnSolar am 11 Juni 2020, 12:32:48
Könnt Ihr mal über das DLNA-device die timestamps beobachten, ob sich das bei Euch zeitlich ähnlich verhält.

Ich habe noch kein DLNA Device erstellt, aber ich kann dieses Verhalten auch so bestätigen.
Eine Leistungsmessung an der Steckdose zeigt, dass es den von dir beschriebenen "pre-standby" gibt. Mein TV schluckt in diesem Zustand noch knapp 30W. Die angeschlossene HDD läuft da noch, aber bei der Leistungsaufnahme müssen auch noch andere Dinge passieren. Im endgültigen Standby werden dann < 1W aufgenommen.
Die Netzwerkverbindung hat da sicherlich auch Einflüsse. Exakt zum Zeitpunkt der Aktualisierung meiner DSL-IP ist der Status vom TV-Device für kurze Zeit auf "on" gegangen.
Gruß,

Stefan
(Raspi 3B - Stretch / HM-LGW / HomeMatic / MySensors)

alru

Moin,

hier noch mal eine Beobachtung zum on/absent Verhalten im Standby Modus (Samsung Q80T):
Alle 5Min (!) startet er irgendetwas, der Status im Device geht auf on. 30s lang benötigt er dazu ca. 10W. Nach den 30s geht er wieder auf 0,4W.
Und 5Min später geht wieder alles von vorne los.
Die dabei entstehenden Stromkosten halten sich noch in Grenzen (ca. 2,50€/pro Jahr für die 10W Phasen), aber den Status des Devices kann man nicht nutzen.
Gruß,

Stefan
(Raspi 3B - Stretch / HM-LGW / HomeMatic / MySensors)

KölnSolar

Dank Dir für die Info. Damit wäre auch mein Ansatz es doch irgendwie hinzubekommen hinfällig.
Ich selber kann das gar nicht beurteilen, da ich hart über die Funksteckdose ein-/ausschalte.  8) Standby gibt es also bei mir eigentlich nie(außer ich bin eingeschlafen u. er geht automatisch in standby  ::))
Ich guck mal, dass ich ne Messsteckdose dran hänge. Zumindest im Logging kann ich bei MEINEM dieses Verhalten(also status-Änderung) nicht erkennen. Vielleicht ist das nur bei einem QT ? Das ist aber jetzt nicht ein "Frame", oder ?
Grüße Markus
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

alru

Zitat von: KölnSolar am 12 Juni 2020, 13:51:05
Vielleicht ist das nur bei einem QT ? Das ist aber jetzt nicht ein "Frame", oder ?
Nein, kein Frame, die genaue Bezeichnung ist "GQ65Q80TGTXZG".
Gruß,

Stefan
(Raspi 3B - Stretch / HM-LGW / HomeMatic / MySensors)

alru

Zitat von: KölnSolar am 11 Juni 2020, 12:32:48
...
Könnt Ihr mal über das DLNA-device die timestamps beobachten, ob sich das bei Euch zeitlich ähnlich verhält.
...
Da ich inzwischen auch das DLNA-Device für den Samsung TV erstellt habe (auch wenn da noch nicht alles funktioniert...https://forum.fhem.de/index.php/topic,39706.msg1064520.html#msg1064520), hab ich mir dort mal den Status angesehen. Und siehe da, hier wird online/offline korrekt angezeigt. Meine Lichtsteuerung im Wohnzimmer funktioniert jetzt damit wieder.
Gruß,

Stefan
(Raspi 3B - Stretch / HM-LGW / HomeMatic / MySensors)

KölnSolar

Hi Stefan,
also nicht so
ZitatABER: ...Es passiert leider folgendes im DLNA-device:
- TV ausschalten -> sofort Status offline -> reproduzierbar 56s später geht er wieder online -> weitere 83s später ist er endgültig offline
- TV einschalten -> sofort Status online
?
Grüße Markus
OT: zu Deinem DLNARenderer-Problem hab ich leider keine Lösungsidee.  :(
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

alru

Moin,
ja, der Status wird beim Ein- und Ausschalten sofort korrekt angezeigt, ohne dass es noch mal einen Wechsel gibt.
Gruß,

Stefan
(Raspi 3B - Stretch / HM-LGW / HomeMatic / MySensors)

flolee

Bei meinem Q70T wird uA keine App-Liste geladen, sonstige befehle funktionieren aber:


2020.10.29 10:34:08 3: [SamsungAV] SamsungTV timelag to reach all json data for app list might be too small


Weiß evtl jemand weiter?

ch.eick

Zitat von: flolee am 29 Oktober 2020, 10:40:40
Bei meinem Q70T wird uA keine App-Liste geladen, sonstige befehle funktionieren aber:

2020.10.29 10:34:08 3: [SamsungAV] SamsungTV timelag to reach all json data for app list might be too small
Gibt es eventuell ein Attribut für einen timeout im Device?
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

KölnSolar

Nö.
2020.10.29 10:34:08 3: [SamsungAV] SamsungTV timelag to reach all json data for app list might be too small sagt, dass der TV oder FHEM wohl zu langsam ist(oder zu viele Apps installiert sind ;D). Aus performance-Gründen wird nur für 0,5s gewartet, da FHEM so lange blockiert ist.
Ich spekuliere(wo ist das Log mit verbose=5 ?  :(), dass das beim Systemstart ist. Evtl. hilft ein späteres set SamsungTV statusRequest

Grüße Markus
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

flolee

#808
hey,

danke für die antwort :)

nein, ist immer so und hat leider nichts mit dem systemstart zu tun.

verbose 5:

DEBUG: .../IO/Socket/SSL.pm:3010: new ctx 22597624
DEBUG: .../IO/Socket/SSL.pm:762: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:764: socket connected
DEBUG: .../IO/Socket/SSL.pm:787: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:832: not using SNI because hostname is unknown
DEBUG: .../IO/Socket/SSL.pm:880: set socket to non-blocking to enforce timeout=2
DEBUG: .../IO/Socket/SSL.pm:894: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:897: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:907: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:917: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:937: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:894: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:897: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:907: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:917: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:937: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:894: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:897: done Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:952: ssl handshake done
2020.10.29 12:24:10 4: [SamsungAV] HTTP socket-connection to SamsungTV. SSL_Reply:
2020.10.29 12:24:10 4: [SamsungAV] HTTP socket-connection to SamsungTV successful.
2020.10.29 12:24:10 5: [SamsungAV] SamsungTV send to TV: GET /api/v2/channels/samsung.remote.control?name=RkhFTVJlbW90ZQ==&token=15066855 HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 192.168.1.14:8002
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13


2020.10.29 12:24:10 5: [SamsungAV] SamsungTV first websocket response: HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

2020.10.29 12:24:11 5: [SamsungAV] SamsungTV Statusbytes of second websocket response: 817e0115
2020.10.29 12:24:11 5: [SamsungAV] SamsungTV data of second websocket response: {"data":{"clients":[{"attributes":{"name":"RkhFTVJlbW90ZQ==","token":"15066855"},"connectTime":1603970650115,"deviceName":"RkhFTVJlbW90ZQ==","id":"fea69b9f-2b53-4afb-a1c5-23b9676bcf23","isHost":false}],"id":"fea69b9f-2b53-4afb-a1c5-23b9676bcf23"},"event":"ms.channel.connect"}

2020.10.29 12:24:11 5: [SamsungAV] SamsungTV send payload: {"params":{"event":"ed.installedApp.get","TypeOfRemote":"SendRemoteKey","to":"host"},"method":"ms.channel.emit"}

2020.10.29 12:24:23 5: [SamsungAV] response SamsungTV to write_payload: ‰
2020.10.29 12:24:23 3: [SamsungAV] SamsungTV timelag to reach all json data for app list might be too small
2020.10.29 12:24:23 3: Netatmo: poll (ACCOUNT)
2020.10.29 12:24:25 4: [SamsungAV] SamsungTV online with 192.168.1.14:8001 - HTTP-Response: 401



Lg

Edit: Was mir noch auffällt, ist, dass die Statusabfrage eigentlich ewig lange dauert, fhem reagiert da erst > 10 sekunden wieder.

KölnSolar

ZitatWas mir noch auffällt, ist, dass die Statusabfrage eigentlich ewig lange dauert, fhem reagiert da erst > 10 sekunden wieder.
Im Log ist nichts besonderes zu erkennen. Ausser der Langsamkeit. So sind die Zeiten "normalerweise"
2020.10.29 17:45:53 5: [SamsungAV] Fernseher send to TV: GET /api/v2/channels/samsung.remote.control?name=RkhFTVJlbW90ZQ==&token=myToken HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: myIP:8002
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13


2020.10.29 17:45:53 5: [SamsungAV] Fernseher first websocket response: HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=


2020.10.29 17:45:53 5: [SamsungAV] Fernseher Statusbytes of second websocket response: 817e0113
2020.10.29 17:45:53 5: [SamsungAV] Fernseher data of second websocket response: {"data":{"clients":[{"attributes":{"name":"RkhFTVJlbW90ZQ==","token":"53913370"},"connectTime":1603989953414,"deviceName":"RkhFTVJlbW90ZQ==","id":"e9556782-e21-44de-955c-ea94d353d99f","isHost":false}],"id":"e9556782-e21-44de-955c-ea94d353d99f"},"event":"ms.channel.connect"}

2020.10.29 17:45:53 5: [SamsungAV] Fernseher send payload: {"method":"ms.channel.emit","params":{"event":"ed.installedApp.get","TypeOfRemote":"SendRemoteKey","to":"host"}}
2020.10.29 17:45:53 5: [SamsungAV] response Fernseher to write_payload: {"data":{"data":[{"appId":"org.tizen.browser","app_type":4,"icon":"/opt/share/webappservice/apps_icon/FirstScreen/webbrowser/250x250.png","is_lock":0,"name":"Internet"},{"appId":"111299001912","app_type":2,"icon":"/opt/share/webappservice/apps_icon/FirstScreen/111299001912/250x250.png","is_lock":0,"name":"YouTube"},......]},"event":"ed.installedApp.get","from":"host"}

2020.10.29 17:45:53 5: [SamsungAV] ARRAY found
2020.10.29 17:45:53 5: [SamsungAV] Application: Internet  Id: org.tizen.browser
.
.


Könnte es sein, dass Du ein Berechtigungs-pop-up auf dem TV übersehen hast ?  :-\ Anders lassen sich 10s von mir nicht  erklären.

Grüße Markus
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