No problem. I just wanted to clarify that this binding is still maintained on a ‘keep the lights on’ level.
I would assume that AndroidTV based Sony TVs are the majority. The rollout of the AndroidTV platform started in 2015, and this bindings supports models that were released from ~2011 on.
However, it might be that the most recent models come without support for the used protocols (notably ScalarAPI), thus wouldn’t work with this binding.
I’ll take that as good news then.
@mhilbush You’ve been tracking both bindings for a while now. The only thing I really get from the ShiledTV protocol is the appdb and app control (minus some metadata). Is there a (small) piece of this binding we could pull in to AndroidTV that would accomplish those goals? I really don’t want to try to integrate the whole protocol stack, it’s EXTENSIVE from what I can see. I think the only “other thing” if I’m remembering our conversations was control/information about the specific input (HDMI1/HDMI2/etc).
Honestly, I know very little about the binding. I used only a tiny percentage of it (basically, power, volume, mute), and other than compiling it for 4.0, I know virtually nothing about the internals.
Yes, it would be nice if the androidtv binding had a way to select the input source. OTOH I can’t recall if the Sony binding let you select the input source.
Thanks for the code. My Sony is a later model (google/android). I think I’ll migrate to that. I really only use the binding to trigger the living room lights when the TV goes off/on. Of all my home automations, that is the only one my wife really likes 
1 Like
The input source can be directly selected with the scalar thing via the channel ‘avContent#tm_source-main’.
1 Like
Is that the same protocol thats not working on newer models?
The direct selection of the input source is possible with the SimpleIP and the Scalar/REST protocol.
I actually don’t know whether the newer models still support these protocols.
I’ve looked up the web manual of a fairly recent model, and the fact that the networks settings still have an ‘enable remote control’ option might indicate that this is still the case.
My hope was that the compatibility existed using the keycodes on the GoogleTV protocol. In the 240s there are ones calling out inputs. Unfortunately they don’t seem to work from the testing done so far. If anyone wants to jam at it please let me know if you have any success.
As far as knowing what input you’re on, that’s going to be sony specific. From what I can tell from the testing @mhilbush did, all of the TV bits seem to exist inside a Sony app, not at the OS where they’re exposed.
Before I go down the development road and burn some time, is there anyone here who is picking this up to maintain it long term and/or get it merged in? If not, I’m strongly considering pulling the existing code into the AndroidTV binding similar to how the Nvidia ShieldTV exists. If no one otherwise has any issues with it, and no one is otherwise standing up to take ownership of this, I think this fits somewhat cleanly inside AndroidTV as it seems that the majority of the current Sony TVs are all AndroidTV based. Thoughts from the users of this?
I’m comitted to maintain this binding and to offer it on the marketplace as long as there is a demand from the community. Although I’ve tried to follow the OH coding practices when adopting the code, I think it would not worth the effort to merge it into the offical sources because of the somehow idiosyncratic implementation, its complexity, and the foreseeable end of life of the supported devices or protocols.
But this shouldn’t stop you from trying to pull code from this into the AndroidTV binding (possibly/likely with refactoring) to offer a ‘full service’ solution. If you decide for it and need help or support just let me know.
Would you be willing to partner up? I don’t mind doing the leg work to merge it in if you continue to maintain the Sony piece of the ATV after that point. The design of the ATV binding allows me to add this basically as a separate protocol stack, or what I call a connection manager. The handlers and such are abstracted off already so it reduces the complexity.
Yes, in principle I would be willing to partner up. I’d suggest to clarify this possibility when the migration plan becomes more concrete.
Sounds fun. I’m working on pulling the philipstv protocol in right now as there is no active development or maintenance there at all.
The basic concept would be to modify the binding so that the Handler is a ConnectionManager in the ATV structure. At that point I still retain the handler bits like handleCommand and postUpdate in the CM, they are just passed back to the main handler. The only real changes could/maybe be making the channel names all the same and things like that. Once the build is clean we submit it as a PR for review. Assuming we can get through the review cycle it would then get merged in. At that point, features/bug fixes/etc for the ConnectionManager would be your responsibility unless it’s something dealing with the main handler or something along those lines. I have a PR pending right now where the GoogleTV protocol can be disabled in the thing configuration, so in theory the binding would run identically in that mode as it does now.
@andan have you seen the current issues with httpClient leaking? I had to patch the neeo binding. It looks like this may also be subject to the same issues, a few people noted the sony binding in other posts.
Not until yet. From what I understand it seems to be very likely that the Sony binding has the same HTTP issue. I will further analyze this and provide a fix if necessary.
Follow clientBuilder through the code it should point the way. internal.net.HttpRequest will definitely need to get reworked. The neeo binding is setup very similarly, lots of code reuse. The PR for that should be very informative. You may not need to do the Stack at all, we only had to do it in one place that was load intensive. Otherwise the built in jetty client was sufficient.
Snapshot 3659 and above may resolve this. There was an upstream big fixed. Neeo has been stable for me on the newest snapshot.
Thank you for this hint. I will do a test when I’ve upgraded my dev environment.
Neeo finally crashed on me under load. It still needs the patch to the jetty client