Sony Devices Binding

Oliverk · February 10, 2017, 9:55pm

when comparing the http get requests, i noticed that your binding #3 uses a different parameter name “registrationType=new” instead of the SideShow app “registrationType=initial”

in your previous versions the binding trys both, but always starts with “new”

do you think this can matter?

###################### Sony SideShow
[GET /cers/getSystemInformation HTTP/1.1\r\n]
[GET /cers/register?name=iPhone%20796%20%28Video%20%26%20TV%20SideView%29&registrationType=initial&deviceId=MediaRemote%3Acf-88-42-2c-1e-17 HTTP/1.1\r\n]
	Request URI Query Parameter: name=iPhone%20796%20%28Video%20%26%20TV%20SideView%29
	Request URI Query Parameter: registrationType=initial
	Request URI Query Parameter: deviceId=MediaRemote%3Acf-88-42-2c-1e-17


####################### Sony binding #3
[GET /cers/getSystemInformation HTTP/1.1\r\n]
[GET /cers/getStatus HTTP/1.1\r\n]
[GET /cers/register?name=OpenHAB+%28openHAB-sony%3A00-11-22-33-44-55%29&registrationType=new&deviceId=openHAB-sony%3A00-11-22-33-44-55 HTTP/1.1\r\n]
	Request URI Query Parameter: name=OpenHAB+%28openHAB-sony%3A00-11-22-33-44-55%29
	Request URI Query Parameter: registrationType=new
	Request URI Query Parameter: deviceId=openHAB-sony%3A00-11-22-33-44-55

Oliverk · February 10, 2017, 10:08pm

looking at the SonyAPI and the pcap of the registration process with SideShow app, it seems the Sony STR-DN1030 is using RegisterMode 1 which requires parameter “registrationType=initial”

https://github.com/KHerron/SonyAPILib

            public bool Register()
            {
                _Log.AddMessage("Controlling Mac address: " + this.ServerMacAddress, false);
                string reg = "false";
                string args1 = "name=" + this.ServerName + "&registrationType=initial&deviceId=TVSideView%3A" + this.ServerMacAddress + " ";
                string args2 = "name=" + this.ServerName + "&registrationType=new&deviceId=TVSideView%3A" + this.ServerMacAddress + " ";
                if (this.Actionlist.RegisterMode == 1)
                {
                    reg = HttpGet(this.Actionlist.RegisterUrl + "?" + args1);
                    _Log.AddMessage("Register Mode: 2 Sony Device", false);
                }
                else if (this.Actionlist.RegisterMode == 2)
                {
                    reg = HttpGet(this.Actionlist.RegisterUrl + "?" + args2);
                    _Log.AddMessage("Register Mode: 1 Sony Device", false);
}

should we give it a try?

tmrobert8 · February 11, 2017, 12:45am

Yeah - I’ve already tried that (the latest binding should have ONLY tried ‘initial’ (I commented out the ‘new’ ones). Note: the SonyAPILib is the ONLY library that I looked at that had version 1 as ‘initial and version 2 as ‘new’ (all other libraries had the reverse - version 1 is ‘new’ and version 2 is ‘initial’). Prior versions tried initial’ then ‘new’ (or ‘new’ then ‘initial’) to cover that case - however, you were timing out on them regardless. So that last binding just simply tried ‘initial’

However, the latest pcap showed you were timing out on a totally different call - you were timing out on the ‘http://192.168.205.46:50001/cers/ActionList.xml’ request (didn’t even get to the actRegistry).

Could you power off your AV and try it again (btw - you are getting alot of tcp retries in the pcaps - could your network be at capacity at this point?

Oliverk · February 11, 2017, 7:35am

i have powered off/on the AV and tried it again with your latest binding Sony-binding-2017-02-10-3 but still the same result: timeout at the register request.
however, it seems that in your latest version you have commented out ‘initial’ and the binding only tries two times ‘new’ according to the logs/captures

[GET /cers/register?name=OpenHAB+%28openHAB-sony%3A00-11-22-33-44-55%29&registrationType=new&deviceId=openHAB-sony%3A00-11-22-33-44-55 HTTP/1.1\r\n]

maybe you could double check the register URI on you latest binding?

i also noticed that the ‘http://192.168.205.46:50001/cers/ActionList.xml’ seems to fail every 2-3 registration cycle with bad request error. at the next run everything is working fine again. (attache the logs and pcap including several registration cycles)

l
2017-02-11 07:57:15.276 [DEBUG] [nding.sony.internal.ircc.IrccHandler] - exception: Bad Request
java.io.IOException: Bad Request

the network shouldn’t have been at capacity, it’s a switched 10/100/1000 Ethernet and there was no load except one radio stream, openhab and our test. probably some side effect of the mirror port configuration on the netgear switch. not sure how this device is handling this, in the past i only had experience with cisco devices.

http://pastebin.com/shn0jRAn

andirs · February 12, 2017, 8:03am

Hello Tim, did you have time to look into this already?
I installed a newer version, but it is still happening:

2017-02-12 08:31:43.913 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:32:17.096 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:32:50.264 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:33:23.457 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:33:56.625 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:34:29.796 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:35:02.961 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:35:36.132 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:36:09.298 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:36:42.468 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:37:15.636 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:37:48.808 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:38:21.975 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:38:55.154 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:39:28.323 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:40:01.531 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:40:34.721 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:41:07.899 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:41:41.072 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:42:14.252 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:42:47.454 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:43:20.648 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:43:53.824 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:44:27.003 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:45:00.177 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:45:33.361 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:46:06.542 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:46:39.708 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:47:12.886 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:47:46.096 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:48:19.299 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:48:52.477 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:49:25.675 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:49:58.848 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:50:32.032 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:51:05.207 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:51:38.381 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:52:11.553 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:52:44.724 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:53:17.988 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:53:51.170 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:54:24.341 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:54:57.512 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:55:30.679 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:56:03.862 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:56:37.047 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:57:10.228 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:57:43.401 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:58:16.576 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:58:49.779 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring
2017-02-12 08:59:22.952 [INFO ] [y.internal.simpleip.SimpleIpProtocol] - Response took too long - ignoring

Thanks for your good job

Oliverk · February 12, 2017, 2:41pm

Hey Tim, after spending some hours on testing and troubleshooting I think I finally found the reasons why the registration fails with your current binding.

the deviceID in the URL of the register request must be in the following format:
MediaRemote%3Axx-xx-xx-xx-xx-xx
any other notation, e.g. openHAB%3A00-11-22-33-44-55 like in your current binding will let the registration process fail.
as supposed the registrationType must be registrationType=initial

with the following HTTP requests i’m able to manually register new MediaRemotes on my Sony AV Amp

http://192.168.205.46:8080/description.xml
http://192.168.205.46:50001/cers/ActionList.xml
http://192.168.205.46:50001/cers/getSystemInformation
http://192.168.205.46:50001/cers/register?name=openHAB%20Sony&registrationType=initial&deviceId=MediaRemote%3Ab8-27-eb-fb-3f-15

as previously noted, it’s important to start the registration mode for new Media Remote devices on the Sony AV first.

hopefully this information helps to finalize your binding for “Register Mode 1” Sony devices?
i’m happy to test any new version of your binding

thanks again for your great work and support in the last days, which is highly appreciated!

tmrobert8 · February 13, 2017, 2:38pm

Andi,

Sorry I haven’t address that yet - the next “testing” one that I post will have something that may fix that issue.

Tim

tmrobert8 · February 13, 2017, 2:52pm

Oliverk

(Sorry for the long post)

I’m next to positive the ID observation you made is not correct (but I absolutely may be incorrect since I don’t have an AV!). I’ve testing the device id with both the bravias and two blurays and they work fine. They don’t really care as long as the content follows “some name:xx-xx-xx-xx-xx-xx”. If you are running that register URL with the same deviceid as the remote AND you never cleared out the old registration on the AV - the register appears to work because it’s a renewal of an existing device id rather than a true register (again, that’s how the bravias/blurays work).

Now the one thing I’m unsure of is the “xx-xx-xx-xx-xx-xx” - that really should be a valid mac address of the device registering - however on your system I can’t seem to get the local mac address (weird in itself) - so I hardcoded the dummy 00-11-22-33-44-55. Again shouldn’t matter (works on both of my test beds).

Would your mind trying the following tests:

Go to the AV itself and delete all media remotes - try the register with the “MediaRemote%3Ab8-27-eb-fb-3f-15” type - success or not?
Delete all media remotes - try the register with “MediaRemote%3A00-11-22-33-44-55” - success or not?
Delete all media remotes - try the register with “openHAB%3A00-11-22-33-44-55” - success or not?
Delete all media remotes - try the register with “openHAB%3Ab8-27-eb-fb-3f-15” - success or not?

That would tell me alot about how the AV responds to the device id format

Note: your point #2 is ABSOLUTELY correct. I forgot that my current process is a two phase registration (request then approve) and I modified the “approve” part of that with the “initial” - forgetting the first part which has the “new”. That’s what you were encountering in this weekend. Once you run the above tests - I’ll make changes based on the results and hopefully have something today that will work.

Thanks for all your help!
Tim

Oliverk · February 13, 2017, 4:39pm

sorry that my previous post and capture was not clear, but i really tested many combination and finally could proof that any id other than MediaRemote%3Axx-xx-xx-xx-xx-xx will fail. i always deleted any previously registered device on the AV before the next test.

no, i created a “new” device ID based on the MAC adress of my openhab PI NIC: MediaRemote%3Ab8-27-eb-fb-3f-15

no, it also works with any valid MAC address, also with your hardcoded dummy 00-11-22-33-44-55.

anyway no problem to double check, i will do the tests you have requested in the next 30 minutes and sent you the results including the capture.

thanks!

Oliverk · February 13, 2017, 4:54pm

as expected, please find below the results of my tests.

MediaRemote%3Ab8-27-eb-fb-3f-15 --> success
MediaRemote%3A00-11-22-33-44-55 --> success
openHAB%3A00-11-22-33-44-55 --> no
openHAB%3Ab8-27-eb-fb-3f-15 --> no

In case of successfull device registration you’ll se a HTTP 200 OK response in the capture

glad that my information is of help! please let me know if you need any further tests.

thanks, Oliver

tmrobert8 · February 13, 2017, 5:46pm

Wow - can’t believe they actually enforce that. Good to know however - next version will will enforce that (blurays and bravias won’t care - so it’s compatible with them also). Also glad to see the dummy mac address works as well!

Thanks for doing those tests! I’ll post a new one shortly…
Tim

tmrobert8 · February 13, 2017, 6:15pm

Posted - give it a shot!

Oliverk · February 13, 2017, 6:53pm

great - openhab has registered successfully!

2017-02-13 19:42:19.404 [DEBUG] [inding.sony.internal.net.HttpRequest] - 19 * Sending client request on thread safeCall-1038
19 > GET http://192.168.205.46:50001/cers/register?name=OpenHAB+%28MediaRemote%3A00-11-22-33-44-55%29&registrationType=initial&deviceId=MediaRemote%3A00-11-22-33-44-55
19 > Connection: close
19 > User-Agent: OpenHab/Sony/Binding
19 > X-CERS-DEVICE-ID: MediaRemote:00-11-22-33-44-55
19 > X-CERS-DEVICE-INFO: OpenHab/Sony/Binding

2017-02-13 19:42:19.450 [DEBUG] [inding.sony.internal.net.HttpRequest] - 20 * Client response received on thread safeCall-1038
20 < 200
20 < Connection: close
20 < CONTENT-LENGTH: 0
20 < CONTENT-TYPE: text/xml; charset="utf-8"
20 < X-AV-Physical-Unit-Info: pa="STR-DN1030"
20 < X-AV-Server-Info: av="5.0"; cn="Sony Corporation"; mn="STR-DN1030"; mv="1.00"

and after removing RQST from the access code my Sony STR-DN1030 Thing became Online
so i will now start playing around with the channels and items…

thank you very much Tim for your great work!

and please let me know if you need any further support or testing of your binding.

tmrobert8 · February 13, 2017, 6:58pm

Woohoo! If you would could you post the output of the ircc transformation file that it created (should find it under the transform directory) and the response to the getStatus/getContentInformation urls (you’ll see it in the debug output)? For the bravia tvs, the only channels that work are power and ircc - the rest of the channels are unique to blurays. Be interesting to see what AVs support (getContentInformation may or may be implemented btw in avs)

tmrobert8 · February 13, 2017, 7:03pm

Actually - looking at your actionlist - you will only support the power, ircc command and text channel. I’m still interested in seeing what the transform file and the getStatus looks like however (see if there is any new information)

tmrobert8 · February 13, 2017, 7:12pm

And looking at the commands from the getRemote from your mediaremote pcap - there may or may not be an issue. Some of the commands have “STR:” prefixed to them and I’m not sure how the transform service handles those. Easiest thing to do is to try out a command in the PaperUI->Control->Click on the “-” under IRCC Command and enter “STR:TvMain” (press enter) and see if the AV switches over (or if you get an error or anything in the log)

Even if it works - I’m thinking that maybe I’ll just make a blanket policy to strip anything up to a colon if one is found (looking at the commands, there doesn’t seem any overlap if I do that). That way the commands are easier to deal with - thoughts?

tmrobert8 · February 13, 2017, 7:22pm

Actually - one more thing as well - restart the binding. I want to see if the AVs will handle the “registrationType=renewal” ok or not…

Oliverk · February 13, 2017, 9:35pm

sorry, had no time today for further tests…below the output from the logs

2017-02-13 20:40:42.057 [DEBUG] [ding.sony.internal.ircc.IrccProtocol] - getContentInformation is not implemented
2017-02-13 20:40:44.063 [DEBUG] [inding.sony.internal.net.HttpRequest] - 2545 * Sending client request on thread ESH-thingHandler-3
2545 > GET http://192.168.205.46:50001/cers/getStatus
2545 > Connection: close
2545 > User-Agent: OpenHab/Sony/Binding
2545 > X-Auth-PSK: 0
2545 > X-CERS-DEVICE-ID: MediaRemote:00-11-22-33-44-55
2545 > X-CERS-DEVICE-INFO: OpenHab/Sony/Binding

2017-02-13 20:40:44.646 [DEBUG] [inding.sony.internal.net.HttpRequest] - 2546 * Client response received on thread ESH-thingHandler-3
2546 < 200
2546 < Connection: close
2546 < CONTENT-LENGTH: 146
2546 < CONTENT-TYPE: text/xml; charset="utf-8"
2546 < X-AV-Physical-Unit-Info: pa="STR-DN1030"
2546 < X-AV-Server-Info: av="5.0"; cn="Sony Corporation"; mn="STR-DN1030"; mv="1.00"
<statusList><status name="viewing"><statusItem field="source" value="TV" /><statusItem field="zone2Source" value="SOURCE" /></status></statusList>

and attached the transform file ircc-5f9ec1b3-ed59-1900-4530-5453edf73098.map.xml (2.7 KB)

here also the output after restarting the bundle. registrationType renewal seems to work, but some strange error at the end “exception: Premature end of file.”?
http://pastebin.com/bK4qHXvR

will do the testing of the channels tomorrow…

tmrobert8 · February 13, 2017, 10:53pm

Interesting - has no issues with the renewal. Appears to support the viewing->source channel (in fact, has a viewing->zone2Source channel that I’ll add to support) - note those are readonly channels. The transform map is interesting - I’ll be removing the “STR:” parts on it in the next version also.

I don’t get the “premature end of file” - that’s saying it didn’t get the full chunk of data from the AV. I’ll do a little research on that.

BTW - if you try the IRCC channel, the channel is CASE SENSITIVE. So you’ll need to type “BLUETOOTH” to start bluetooth, “Left” to go left, “Confirm” to hit enter, etc

tmrobert8 · February 13, 2017, 11:34pm

I just posted number 2 for today:

Delete the ircc map file to allow it to recreate (should remove the “STR:” parts in the commands - let me know if it doesn’t)
Included a new channel - viewing#zone2source that should contain the source for zone2

Could you also reply with the exact directions to put the AV into pairing mode (want to include it in the documentation