Sony Devices Binding

Oliverk · February 10, 2017, 8:50pm

from last try already sent by PM…

tmrobert8 · February 10, 2017, 8:56pm

The pcap from openhab was using an older version of the binding (still had the colons and the wolsupport parts in the registration). Sure you restarted with the latest version?

wolfram1A · February 10, 2017, 9:00pm

Thanks, i found “Sony Scalar”

tmrobert8 · February 10, 2017, 9:01pm

Yeah - that service not ready in the least bit. Stay tuned on that one (probably a few weeks to tell you the truth).

Oliverk · February 10, 2017, 9:02pm

i always deleted the thing and afterwards deleted the jar in the addon folder before deploying latest version.

not sure what you mean, pcap3 already registered with dash instead of colons:

> GET http://192.168.205.46:50001/cers/register?name=OpenHAB+%28openHAB-sony%3A00-11-22-33-44-55%29&registrationType=new&deviceId=openHAB-sony%3A00-11-22-33-44-55

or did i messed up something when uploading?

tmrobert8 · February 10, 2017, 9:04pm

Ack - think that was my fault and opened up the wrong one!

tmrobert8 · February 10, 2017, 9:09pm

Number 3 posted (do a pcap on this as well). If this one works - that’s kinda going to be a bad sign…

Oliverk · February 10, 2017, 9:24pm

sh** still timeout… pcap in PM

http://pastebin.com/aG4mvBfY

wolfram1A · February 10, 2017, 9:28pm

Thanks and a nice WE

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