Neues Modul 70_SamsungAV

Begonnen von KölnSolar, 06 Februar 2019, 13:45:13

Vorheriges Thema - Nächstes Thema

KölnSolar

Auf dem Wege die Modifikationen des 70_STV offiziell per update zu verteilen, gibt es nun das 70_SamsungAV. Es "ersetzt" das 70_STV und sollte alle AV-Geräte von Samsung seit A-Serie unterstützen.

Nähere Informationen zur Historie des Moduls und den Besonderheiten von Samsung-devices je Serie findet Ihr hier. Dort gibt es dann zukünftig auch immer die letzte Entwicklungsversion des 70_SamsungAV.
Grüße Markus
Edit: seit 5.4. werden Änderungen per update verteilt  ;)
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

gloob

Hallo,

Vielen Dank für die Arbeit. Hast du schon eine Idee, wann das 70_SamsungAV Modul offiziell über das FHEM Update kommt?

Gruß
Stefan
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

KölnSolar

nicht konkret, aber noch diesen Winter, wenn nicht dazwischen kommt. Da es mein erstes einchecken sein wird, weiß ich nicht, was da noch alles auf mich zukommt.  :-\
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

ch.eick

Hallo Markus,

fyi ich bin bereits umgestiegen (H-Serie).

Gruß
   Christian
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

efelon

#4
Hallo Zusammen,

leider spricht mein Samsung TV nicht mit mir :'(. Bin seit kurzem Besitzer eines Samsung UE55KU6179 und schon länger glücklicher FHEM Nutzer. Nachdem sich schon mein Kodi und auch mein Verstärker mit FHEM unterhalten, wollte ich den TV auch noch dazu holen. Bei der Suche bin ich auf das neue Modul SamsungAV gestoßen, mit dem ich jetzt erste Gehversuche mache. Ich habe mich auch soweit an die Anleitung https://forum.fhem.de/index.php/topic,82890.msg750392.html#msg750392 gehalten und konnte  mich initial mit dem TV verbinden.

Was ich bis jetzt sehe:

  • state absent und on funktionieren
  • in den Internals sehe ich unter helper->app: Einige aufgelistet (z.b. RedBullTV  3201602007756, WebBrowser org.tizen.browser, ...)
  • in den Settings des Samsung unter Netzwerk->Experteneinstellungen->Mobilgerätemanager->Mobilgeräteliste wird FhemRemote angezeigt und ist Erlaubt
  • TV Version laut settings: 1231
  • delayRC habe ich schon ohne Erfolg für folgendes Problem mit Werten: 10, 100 und 500 getestet

Leider werden keine der angebotenen Kommandos ausgeführt. Beim ersten Verbinden kam die Meldung um einen Zugriff zu erlauben, danach gibt es augenscheinlich keine Reaktion mehr am TV.
Nach einstellen von Verbose 5 für das SamsungAV Modul, hier die Ausgaben beim Senden eines Kommandos:

Zitat
2019.02.11 22:01:34 5 : [SamsungAV] Dev.SamsungAV command VOLUP parameter
2019.02.11 22:01:34 4 : [SamsungAV] HTTP socket-connection to Dev.SamsungAV. SSL_Reply:
2019.02.11 22:01:34 4 : [SamsungAV] HTTP socket-connection to Dev.SamsungAV successful.
2019.02.11 22:01:34 5 : [SamsungAV] Dev.SamsungAV send to TV: GET /api/v2/channels/samsung.remote.control?name=RkhFTVJlbW90ZQ== HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: 192.168.0.169:8002 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13
2019.02.11 22:01:34 5 : [SamsungAV] Dev.SamsungAV first websocket response: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
2019.02.11 22:01:34 5 : [SamsungAV] Dev.SamsungAV Statusbytes of second websocket response: 817e00fa
2019.02.11 22:01:34 5 : [SamsungAV] Dev.SamsungAV data of second websocket response: {"event":"ms.channel.connect","data":{"id":"53d38220-1dd3-11b2-bce6-33ec2b094008","clients":[{"id":"53d38220-1dd3-11b2-bce6-33ec2b094008","connectTime":537411,"attributes":{"name":"RkhFTVJlbW90ZQ=="},"deviceName":"RkhFTVJlbW90ZQ==","isHost":false}]}}
2019.02.11 22:01:34 4 : [SamsungAV] Dev.SamsungAV sending VOLUP
2019.02.11 22:01:34 5 : [SamsungAV] Dev.SamsungAV send payload: {"method":"ms.remote.control","params":{"Cmd":"Click","Option":"false","TypeOfRemote":"SendRemoteKey","DataOfCmd":"KEY_VOLUP"}}
2019-02-11 22:01:34 SamsungAV Dev.SamsungAV volumeUp
2019.02.11 22:02:14 4 : [SamsungAV] Dev.SamsungAV online with 192.168.0.169:8001 - HTTP-Response: 404

Hier noch die Ausgabe von /api/v2/:

{
  "id": "uuid:482d60ae-5d59-40f8-b12c-d3680c1fcdb8",
  "name": "[TV] Samsung 6 Series (55)",
  "version": "2.1.0",
  "device": {
    "type": "Samsung SmartTV",
    "duid": "uuid:482d60ae-5d59-40f8-b12c-d3680c1fcdb8",
    "model": "16_JAZZL_UHD_BASIC",
    "modelName": "UE55KU6179",
    "description": "Samsung DTV RCR",
    "networkType": "wired",
    "ssid": "",
    "ip": "192.168.0.169",
    "firmwareVersion": "Unknown",
    "name": "[TV] Samsung 6 Series (55)",
    "id": "uuid:482d60ae-5d59-40f8-b12c-d3680c1fcdb8",
    "udn": "uuid:482d60ae-5d59-40f8-b12c-d3680c1fcdb8",
    "resolution": "3840x2160",
    "countryCode": "DE",
    "msfVersion": "2.1.0",
    "smartHubAgreement": "true",
    "VoiceSupport": "false",
    "GamePadSupport": "true",
    "wifiMac": "d8:e0:e1:df:fa:1e",
    "developerMode": "0",
    "developerIP": "",
    "OS": "Tizen"
  },
  "type": "Samsung SmartTV",
  "uri": "http://192.168.0.169:8001/api/v2/",
  "remote": "1.0",
  "isSupport": "{\"remote_available\":\"true\",\"remote_fourDirections\":\"true\",\"remote_touchPad\":\"true\",\"remote_voiceControl\":\"false\",\"DMP_available\":\"true\",\"DMP_DRM_PLAYREADY\":\"false\",\"DMP_DRM_WIDEVINE\":\"false\",\"EDEN_available\":\"true\"}"
}


Über eine Hilfestellung für ein weiteres Vorgehen würde ich mich sehr freuen und bin gerne bereit weitere Informationen nachzuliefern. Es fühlt sich so an als fehle nur noch eine Kleinigkeit. An DLNA bin ich im Moment gar nicht interessiert, fernbedienen würde mich schon glücklich machen.

Liebe Grüße
Martin

KölnSolar

Hallo Martin,
erst einmal Kompliment an die mustergültige Fragestellung und Eigeninitiative.  :-* Würd ich mir häufiger so wünschen.  8)
Zitatleider spricht mein Samsung TV nicht mit mir :'(
Doch tut er. Sieht eigentlich super aus. Dass Du Apps ermitteln konntest beweist, dass FHEM u. TV kommuniziert haben. Dann müsste doch eigentlich wenigstens 0_App_Start und 0_App_Status funktionieren. Ebenso der statusrequest.
Dann hört es aber leider auf  :'(
Zugriffsberechtigung im Geräteverbindungsmanager steht auf "Nur beim ersten Mal" ? Ich vermute ja, sonst müsste das Log anders aussehen.  :'(
Und sonst hab ich bei dem herrlichen Log leider keine weitere Idee.  :'(
Guck Dir den Thread mal an. Vielleicht finden wir über das debugging etwas.
Ich kanns mir zwar nicht vorstellen(weil andere "Symptome"), aber Du könntest auch den Weg mit einer gleichzeitig angemeldeten App ausprobieren(Ist dann auch in dem Thread beschrieben).
Viel Glück
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

efelon

#6
Hi Markus,

danke für die Schnelle Antwort...
Zitat von: KölnSolar am 11 Februar 2019, 23:55:51erst einmal Kompliment an die mustergültige Fragestellung und Eigeninitiative.  :-* Würd ich mir häufiger so wünschen.
Ich hoffe, dass dadurch auch andere mit ähnlichem Problem besser die Informationen finden und auch gut nachvollziehen können.

ZitatDann müsste doch eigentlich wenigstens 0_App_Start und 0_App_Status funktionieren. Ebenso der statusrequest.

Du hast Recht. 0_App_Start und 0_App_Status funktionieren tatsächlich. Der statusrequest auch, wobei ich annehme, dass der das selbe macht wie das Modul um den Status des Fernsehers zu kriegen?!

Hier die Ergebnisse der ersten Runde "Samsung Debug Modus" deiner Hinweise. Ich habe zwei Logs mitgebracht. Ein Log vom Senden eines normalen Fernsteuerkommandos (KEY_VOLUP) was nicht angenommen wird und ein Log vom Senden eines funktionierenden 0_App_Start. Zu lesen von oben (ist jeweils die älteste Nachricht):


  • "KEY_VOLUP" log
DEBUG "[RemoteControl ] RemoteControl Client has connected" {}
SILLY "eventbus published : channel:client:session:start" {}
SILLY "[Device] notifyRemoteNumbers" {}
VERBOSE "[Plugin : Tizen] notifyRemoteNumbers" {}
DEBUG "IPC transceive called : " { "method": "application.setRemoteNumbers", "params": { "clientNumber": 1, "deviceName": "RkhFTVJlbW90ZQ==" }, "id": "2af8ad30-1dd3-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
VERBOSE "[Device] requestACLPairing" { "clientIp": "192.168.0.50", "deviceName": "RkhFTVJlbW90ZQ==" }
VERBOSE "[Plugin : Tizen] requestACLPairing" {}
DEBUG "IPC transceive called : " { "method": "application.aclPairing", "params": { "clientIp": "192.168.0.50", "deviceName": "RkhFTVJlbW90ZQ==" }, "id": "2af97080-1dd3-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}
DEBUG "ipc client on data" {}
DEBUG "ipc data = 60,{\"id\":\"2af97080-1dd3-11b2-8c27-5f90252762f6\",\"result\":true}\n" {}
DEBUG "ipc on data : cPos : 2" {}
DEBUG "ipc on data : len : 60" {}
DEBUG "ipc on data : result : {\"id\":\"2af97080-1dd3-11b2-8c27-5f90252762f6\",\"result\":true}\n" {}
DEBUG "ipc on data : data left : 0" {}
DEBUG "IPC callRPC : result : true" {}
SILLY "[RemoteControl ] 2af85f10-1dd3-11b2-8c27-5f90252762f6 is authorized" {}
SILLY "[Device] createTizenAddon" {}
SILLY "[Device] requestRemoteControl" { "TypeOfRemote": "CreateRemoteDevice" }
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}
SILLY "[RemoteControl ] message from (2af85f10-1dd3-11b2-8c27-5f90252762f6) : {\"params\":{\"Option\":\"false\",\"Cmd\":\"Click\",\"DataOfCmd\":\"KEY_VOLUP\",\"TypeOfRemote\":\"SendRemoteKey\"},\"method\":\"ms.remote.control\"}" {}
SILLY "[Device] requestRemoteControl" { "Option": "false", "Cmd": "Click", "DataOfCmd": "KEY_VOLUP", "TypeOfRemote": "SendRemoteKey" }
SILLY "[Device] notifyRemoteNumbers" {}
VERBOSE "[Plugin : Tizen] notifyRemoteNumbers" {}
DEBUG "IPC transceive called : " { "method": "application.setRemoteNumbers", "params": { "clientNumber": 0, "deviceName": "RkhFTVJlbW90ZQ==" }, "id": "2b046d00-1dd3-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
DEBUG "[RemoteControl ] Destroy Tizen Addon Process because of no client." {}
SILLY "[Device] destroyTizenAddon" {}
SILLY "eventbus published : channel:client:session:end" {}
DEBUG "[RemoteControl ] RemoteControl Client has disconnected" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}

  • "0_App_Start" log
DEBUG "[RemoteControl ] RemoteControl Client has connected" {}
SILLY "eventbus published : channel:client:session:start" {}
SILLY "[Device] notifyRemoteNumbers" {}
VERBOSE "[Plugin : Tizen] notifyRemoteNumbers" {}
DEBUG "IPC transceive called : " { "method": "application.setRemoteNumbers", "params": { "clientNumber": 1, "deviceName": "RkhFTVJlbW90ZQ==" }, "id": "885aed30-1dd3-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
VERBOSE "[Device] requestACLPairing" { "clientIp": "192.168.0.50", "deviceName": "RkhFTVJlbW90ZQ==" }
VERBOSE "[Plugin : Tizen] requestACLPairing" {}
DEBUG "IPC transceive called : " { "method": "application.aclPairing", "params": { "clientIp": "192.168.0.50", "deviceName": "RkhFTVJlbW90ZQ==" }, "id": "885b8970-1dd3-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "ipc client on end" {}
DEBUG "ipc client on data" {}
DEBUG "ipc data = 60,{\"id\":\"885b8970-1dd3-11b2-8c27-5f90252762f6\",\"result\":true}\n" {}
DEBUG "ipc on data : cPos : 2" {}
DEBUG "ipc on data : len : 60" {}
DEBUG "ipc on data : result : {\"id\":\"885b8970-1dd3-11b2-8c27-5f90252762f6\",\"result\":true}\n" {}
DEBUG "ipc on data : data left : 0" {}
DEBUG "IPC callRPC : result : true" {}
SILLY "[RemoteControl ] 885a29e0-1dd3-11b2-8c27-5f90252762f6 is authorized" {}
SILLY "[Device] createTizenAddon" {}
SILLY "[Device] requestRemoteControl" { "TypeOfRemote": "CreateRemoteDevice" }
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}
DEBUG "ipc client on close" {}
SILLY "[RemoteControl ] message from (885a29e0-1dd3-11b2-8c27-5f90252762f6) : {\"method\":\"ms.channel.emit\",\"params\":{\"TypeOfRemote\":\"SendRemoteKey\",\"event\":\"ed.apps.launch\",\"to\":\"host\",\"data\":{\"metaTag\":\"\",\"appId\":\"3201412000679\",\"action_type\":\"DEEP_LINK\"}}}" {}
VERBOSE "[Plugin : Tizen] emitToRCR : ed.apps.launch" {}
VERBOSE "[Plugin : Tizen] Creating eden data link" {}
DEBUG "IPC transceive called : " { "method": "ed.apps.launch", "params": { "metaTag": "", "appId": "3201412000679", "action_type": "DEEP_LINK" }, "id": "8866d410-1dd3-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
DEBUG "IPC client connected : /tmp/eden" {}
DEBUG "ipc client on data" {}
DEBUG "ipc data = 60,{\"id\":\"8866d410-1dd3-11b2-8c27-5f90252762f6\",\"result\":true}\n" {}
DEBUG "ipc on data : cPos : 2" {}
DEBUG "ipc on data : len : 60" {}
DEBUG "ipc on data : result : {\"id\":\"8866d410-1dd3-11b2-8c27-5f90252762f6\",\"result\":true}\n" {}
DEBUG "ipc on data : data left : 0" {}
DEBUG "IPC callRPC : result : true" {}
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}
SILLY "[Device] notifyRemoteNumbers" {}
VERBOSE "[Plugin : Tizen] notifyRemoteNumbers" {}
DEBUG "IPC transceive called : " { "method": "application.setRemoteNumbers", "params": { "clientNumber": 0, "deviceName": "RkhFTVJlbW90ZQ==" }, "id": "88fa6180-1dd3-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
DEBUG "[RemoteControl ] Destroy Tizen Addon Process because of no client." {}
SILLY "[Device] destroyTizenAddon" {}
SILLY "eventbus published : channel:client:session:end" {}
DEBUG "[RemoteControl ] RemoteControl Client has disconnected" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}
SILLY "[Router] Incoming Request" { "ip": "::ffff:127.0.0.1", "port": "8001", "method": "POST", "url": "/remoteControl/touchEnable/enable", "body": {} }
VERBOSE "[Plugin : RemoteControl] TV touch Available staus is changed to enable" {}
SILLY "[Router] Incoming Request" { "ip": "::ffff:192.168.0.50", "port": "8001", "method": "GET", "url": "/", "body": {} }


Ich überlasse sie erstmal Deinem geschulten Auge. Ich sehe auf Anhieb keine großen Unterschiede, außer dass das erste DEBUG "ipc client on close" {}bei dem nicht angenommen Kommando früher kommt als beim 0_App_Start. Mit dem SamsungAV Attribut "delayRC" 5 ist die besagte Ausgabe aber wieder an der gleichen Stelle wie beim 0_App_Start. Jedoch immer noch keine Reaktion auf "normale" Befehle.

Sobald ich wieder Zeit finde mache ich mich in dem Thread auf die Suche nach "gleichzeit angemeldete App".

Viele Grüße
Martin

P.S.: Hier noch die Versionsinformation aus der Debug Config:

ZitatMultiScreen Service
Service Information
VERSION   2.1.0
PORT   8001
SECUREPORT   8002
APIVERSION   2.0
REMOTEVERSION   1.0

efelon

Hi,

noch ein schneller Nachtrag. Habe aus dem Playstore die erste Samsung Remote Control App (https://play.google.com/store/apps/details?id=ir.remote.smg.tv) auf meinem Androiden installiert die ich gesehen habe, die auch per Netzwerk steuert, was funktioniert. Da ich eh noch das Debug Fenster offen habe, hier die komplette Kommunikation vom ersten Verbinden, über ein paar Tasten drücken (Vol Up/Down, Mute), bis hin zum Trennen der Verbindung. Trennen bedeutet in dem Fall schon zurück auf den Android Home Screen zu gehen:


DEBUG "[RemoteControl ] RemoteControl Client has connected" {}
SILLY "eventbus published : channel:client:session:start" {}
SILLY "[Device] notifyRemoteNumbers" {}
VERBOSE "[Plugin : Tizen] notifyRemoteNumbers" {}
DEBUG "IPC transceive called : " { "method": "application.setRemoteNumbers", "params": { "clientNumber": 1, "deviceName": "U2Ftc3VuZyBUViBXaUZpIHJlbW90ZSBhcHA=" }, "id": "0cb497f0-1ddb-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
VERBOSE "[Device] requestACLPairing" { "clientIp": "192.168.0.219", "deviceName": "U2Ftc3VuZyBUViBXaUZpIHJlbW90ZSBhcHA=" }
VERBOSE "[Plugin : Tizen] requestACLPairing" {}
DEBUG "IPC transceive called : " { "method": "application.aclPairing", "params": { "clientIp": "192.168.0.219", "deviceName": "U2Ftc3VuZyBUViBXaUZpIHJlbW90ZSBhcHA=" }, "id": "0cb53430-1ddb-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}
DEBUG "ipc client on data" {}
DEBUG "ipc data = 60,{\"id\":\"0cb53430-1ddb-11b2-8c27-5f90252762f6\",\"result\":true}\n" {}
DEBUG "ipc on data : cPos : 2" {}
DEBUG "ipc on data : len : 60" {}
DEBUG "ipc on data : result : {\"id\":\"0cb53430-1ddb-11b2-8c27-5f90252762f6\",\"result\":true}\n" {}
DEBUG "ipc on data : data left : 0" {}
DEBUG "IPC callRPC : result : true" {}
SILLY "[RemoteControl ] 0cb449d0-1ddb-11b2-8c27-5f90252762f6 is authorized" {}
SILLY "[Device] createTizenAddon" {}
SILLY "[Device] requestRemoteControl" { "TypeOfRemote": "CreateRemoteDevice" }
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}
SILLY "[Router] Incoming Request" { "ip": "::ffff:192.168.0.219", "port": "8001", "method": "GET", "url": "/api/v2/", "body": {} }
VERBOSE "[Plugin : ApiV2] getServiceInfo" {}
SILLY "[RemoteControl ] message from (0cb449d0-1ddb-11b2-8c27-5f90252762f6) : {\"method\":\"ms.remote.control\",\"params\":{\"Cmd\":\"Click\",\"DataOfCmd\":\"KEY_VOLUP\",\"Option\":\"false\",\"TypeOfRemote\":\"SendRemoteKey\"}}" {}
SILLY "[Device] requestRemoteControl" { "Cmd": "Click", "DataOfCmd": "KEY_VOLUP", "Option": "false", "TypeOfRemote": "SendRemoteKey" }
SILLY "[RemoteControl ] message from (0cb449d0-1ddb-11b2-8c27-5f90252762f6) : {\"method\":\"ms.remote.control\",\"params\":{\"Cmd\":\"Click\",\"DataOfCmd\":\"KEY_MUTE\",\"Option\":\"false\",\"TypeOfRemote\":\"SendRemoteKey\"}}" {}
SILLY "[Device] requestRemoteControl" { "Cmd": "Click", "DataOfCmd": "KEY_MUTE", "Option": "false", "TypeOfRemote": "SendRemoteKey" }
SILLY "[RemoteControl ] message from (0cb449d0-1ddb-11b2-8c27-5f90252762f6) : {\"method\":\"ms.remote.control\",\"params\":{\"Cmd\":\"Click\",\"DataOfCmd\":\"KEY_MUTE\",\"Option\":\"false\",\"TypeOfRemote\":\"SendRemoteKey\"}}" {}
SILLY "[Device] requestRemoteControl" { "Cmd": "Click", "DataOfCmd": "KEY_MUTE", "Option": "false", "TypeOfRemote": "SendRemoteKey" }
SILLY "[RemoteControl ] message from (0cb449d0-1ddb-11b2-8c27-5f90252762f6) : {\"method\":\"ms.remote.control\",\"params\":{\"Cmd\":\"Click\",\"DataOfCmd\":\"KEY_VOLDOWN\",\"Option\":\"false\",\"TypeOfRemote\":\"SendRemoteKey\"}}" {}
SILLY "[Device] requestRemoteControl" { "Cmd": "Click", "DataOfCmd": "KEY_VOLDOWN", "Option": "false", "TypeOfRemote": "SendRemoteKey" }
SILLY "[Router] Incoming Request" { "ip": "::ffff:192.168.0.50", "port": "8001", "method": "GET", "url": "/", "body": {} }
SILLY "[Device] notifyRemoteNumbers" {}
VERBOSE "[Plugin : Tizen] notifyRemoteNumbers" {}
DEBUG "IPC transceive called : " { "method": "application.setRemoteNumbers", "params": { "clientNumber": 0, "deviceName": "U2Ftc3VuZyBUViBXaUZpIHJlbW90ZSBhcHA=" }, "id": "25c8e1b0-1ddb-11b2-8c27-5f90252762f6" }
DEBUG "Stringifying message" {}
DEBUG "[RemoteControl ] Destroy Tizen Addon Process because of no client." {}
SILLY "[Device] destroyTizenAddon" {}
SILLY "eventbus published : channel:client:session:end" {}
DEBUG "[RemoteControl ] RemoteControl Client has disconnected" {}
DEBUG "IPC client connected : /tmp/msf" {}
DEBUG "ipc client on end" {}
DEBUG "ipc client on close" {}


Hoffentlich hilfreich...

efelon

... meine Neugierde hat mich nicht los gelassen und ich habe den von dir verlinkten Thread etwas vorwärts gelesen (hätte ich gleich machen soll). Die tatsächliche Lösung war dann dieser Hinweis: https://forum.fhem.de/index.php/topic,57595.msg855084.html#msg855084, der mich darauf gestoßen hat, dass ich die Zeiteinheit in der Moduldoku zum SamsungAV nicht genau genug gelesen hatte. Ich dachte die ganze Zeit es wird dort in Millisekunden angegeben. Nachdem ich, wie in dem oben verlinkten Thread beschrieben, 600000 bei "delayRC" eingetragen habe gehen die Kommandos.

Ich hoffe die ganzen Infos der letzten beiden Antworten waren trotzdem nicht ganz umsonst.

Vielen Dank jedenfalls für Deine Mühe mit dem Modul Markus. Kannst gerne den "UE55KU6179" auch als getestet bei den K-Modellen mit aufnehmen.

Viele Grüße
Martin

KölnSolar

Prima, dass es geklappt hat.
ZitatIch hoffe die ganzen Infos der letzten beiden Antworten waren trotzdem nicht ganz umsonst.
Keineswegs. Und zukünftig weiß ich, dass ein "tolles" Log nur mit dem delayRC zu tun haben kann. Auch wenn der Fragesteller schreibt, er hätte es probiert.  ;) Zu meinem Glück steht in der commandref: microsec.  ;D
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

gloob

Schon eine Idee, wann das Modul übers Update kommt?
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

TM4889

Mir ist aufgefallen das eine sinnvolle Funktion in dem Modul noch fehlt. Die Funktion "power" bzw. "poweron" funktioniert leider nur so lange, wie das TV Geräte im Netzwerk aktiv erreichbar ist. Bei meinem Samsung Q6 Modell ist dies leider nur maximal 1 Minute nach "power"/"poweroff" der Fall. Danach ist er "absent" und lässt sich nicht mehr per Modul einschalten, dass fand ich eher nicht angebracht.

Mein Q6 lässt sich jedoch per WOL wieder einschalten. Somit habe ich das Modul um die WOL-Funktion erweitert und mit der "power"/"poweron" Funktion verknüpft. Test bvei meinem Q6 war erfolgreich.
Da für das WOL die Mac des Gerätes notwendig ist, habe ich im Define-Sub eine Automatik eingebaut welche die Mac automatisch ausliest und als Internal "Host_MAC" speichert (Gerät muss beim erstmaligen Define eingschalten sein).  Um Verwirrungen zu vermeiden wurde das Internal "MAC" in "MyMAC" geändert.

An den Entwickler: Bitte Funktion prüfen und offiziell ins Modul aufnehmen.
Geänderte Codeabschnitte sind mit ##edit_by_TM## gekennzeichnet.

R1k4rd

Guten Abend,

die Idee hatte ich ihm auch schonmal unterbreitet, allerdings hatten wir es verworfen weil es dann unter Umständen natürlich nicht bei allen Modellen funktioniert und somit teilweise Fragen von Nutzern entstehen könnten bei denen die WOL Funktion eben nicht vorhanden ist. Hast du es zufällig so implementiert das es nur bei Modellen verwendet wird die auch wirklich WOL unterstützen? Und die nächste Frage in der Hinsicht wäre, dass mit den 60 Sekunden ist bekannt, was passiert allerdings wenn ich sagen wir mal ausversehen den Fernseher ausschalte und im Anschluss direkt wieder einschalten möchte? Dann müsste das Modul unterscheiden wenn ich innerhalb der 60 Sekunden nach ausschalten wieder einschalten will, dann über den "normalen Befehl" und alles nach den 60 Sekunden über den power on WOL Befehl. ???

BTW @KölnSolar: Hast du eigentlich das direkte Aufrufen eines YouTube Videos noch implementiert für die neueren Modelle? War bis jetzt noch zu faul auf das SamsungAV-Modul umzusteigen und habe noch das "alte" STV, daher die Frage ob es vielleicht mit dem neuem geht :D

KölnSolar

ZitatHast du eigentlich das direkte Aufrufen eines YouTube Videos noch implementiert für die neueren Modelle?
Nein, weil es nicht geht. Mir war erst beim Versuch es über 0_text_line umzusetzen klar geworden, dass das ja leider auch ab K-Serie nicht mehr geht.  :'(

Und WOL als power/poweron wird natürlich aus den bekannten Gründen nicht ins Modul implementiert....
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

TM4889

#14
Zitatdie Idee hatte ich ihm auch schonmal unterbreitet, allerdings hatten wir es verworfen weil es dann unter Umständen natürlich nicht bei allen Modellen funktioniert und somit teilweise Fragen von Nutzern entstehen könnten bei denen die WOL Funktion eben nicht vorhanden ist. Hast du es zufällig so implementiert das es nur bei Modellen verwendet wird die auch wirklich WOL unterstützen?
Und die nächste Frage in der Hinsicht wäre, dass mit den 60 Sekunden ist bekannt, was passiert allerdings wenn ich sagen wir mal ausversehen den Fernseher ausschalte und im Anschluss direkt wieder einschalten möchte? Dann müsste das Modul unterscheiden wenn ich innerhalb der 60 Sekunden nach ausschalten wieder einschalten will, dann über den "normalen Befehl" und alles nach den 60 Sekunden über den power on WOL Befehl. ???



sub SamsungAV_Set($@)
...
if (defined $hash->{helper}{featureWOL} && defined $hash->{Mode}) {
if ($hash->{helper}{featureWOL} eq "1") {
if ( ReadingsVal($name,"state","not found") ne "disabled" && ReadingsVal($name,"presence","not found") eq "absent" && ($cmd eq "power" || $cmd eq "poweron" ) ){
return if ( WakeOnLAN($hash,$cmd) );
}
}
}


Vorraussetzung für aktivierung der WOL-Funktion:

  • Attribut "featureWOL" muss auf 1 gesetzt sein
  • das Modul muss mit einem DLNARenderer definiert sein um das Reading "presence" zur verfügung zu haben
  • die WOL-Funktion selbst prüft vor Ausführung erst ob die angegebene IP erreichbar ist


Wenn das Reading "presence" "absent" ist wird nur das WOL ausgeführt. Hat das Reading einen anderen Wert wird das WOL nicht ausgeführt. Kurz gesagt muss das Gerät erst komplett abschaltet sein um ein WOL abzusetzen.




Es müsste noch eine Überwachung in das Modul eingepflegt werden, für den Fall das es mit einem DLNARenderer definiert wurde und dieser während dem Betrieb gelöscht wurde. Fehlt der Renderer während dem Betrieb, stürtz FHEM spätestens beim nächsten "statusRequest" ab.






Zitates dann unter Umständen natürlich nicht bei allen Modellen funktioniert und somit teilweise Fragen von Nutzern entstehen könnten bei denen die WOL Funktion eben nicht vorhanden ist

Dann müsste das "power" und "poweron"/"poweroff" ebenfalls angepasst werden. Da diese Befehle auch nicht bei allen Modellen gleich sind und somit ebenfalls Fragen von Nutzern entstehen können ;)