At some point (not urgent), it would be nice to get a 4.0 build that adapted to the new addon metadata change that went into core recently (i.e. addon.xml vs binding.xml).
I have that actually sitting in my current merge to pull in. If I pull this back and make it googletv vs. shieldtv it will have that on the first rev. I just haven’t committed it yet as I have a relatively large and major amount of code changes to pull over with the addition of the googletv protocol.
Is it causing you problems? The binding I have posted is running on my 4.0.0 system which has been updated to the new addons.xml and it seems to work just fine.
Not currently. But Jan said bindings in the addons directory that used binding.xml would not work. Maybe I misread what he said… And if it’s working for you, then there’s no rush at all.
Mine’s been just fine. If it breaks please let me know and I’ll spin off a jar to fix it while I work on the googletv bits. That shouldn’t take too long.
Confirming that the binding still works. The only issue I’ve seen (and it’s a very minor one) is that the UI doesn’t show that the binding is installed (and therefore you can’t manually create a thing through the UI). So from my perspective no need to do anything right now.
FOR ANYONE TRACKING THIS THREAD - READ THIS POST
I’ve made several major (and breaking) changes to the binding. The first and most major, this is now the AndroidTV binding, not just the ShieldTV. You MUST rebuild your things as androidtv:shieldtv instead of shieldtv:shieldtv. You MUST also rerun the PIN process (just as you did before, it just needs to be rerun because of all the changes). Otherwise, this should work just the same as the last ShieldTV release (minus a few bug fixes).
Also, thanks to @hilbrand and his compile magic trick, the attached jar will now work on all releases from 3.2.0 through 4.0.0 (or it should, please report if they aren’t working). I’ll be killing the other thread since I don’t have to maintain two versions now.
Please report success/failure with the new binding changes. Next step, adding the googletv protocol which I’m actively working on. This was the first major step in that direction. Also, with any hope, this binding should start to cover a large variety of AndroidTV devices.
1 Like
I have installed the new binding, but I get the following message:“No thing types can be added with this binding.” I am running Openhab 3.4.0 and the previous ShieldTv binding was working just fine.
I am running Opnhab in a container on a Qnap Nas.
EDIT: I just realised that the INBOX shows a thing to add so will try that later and report back. I am still discovering how things work, No pun intended 
Well thats different. Can anyone on 3.4.0 confirm the same? I don’t have a 3.4.0 running to check.
Both of mine are running on a 4.0 SNAPSHOT.
I confirm that the new Android Tv binding works on Openhab 3.4.0 with a 2019 Shield TV (P3430).
One thing I am curious about is if there is any way of being able to keep the last command sent active. I give an example. When you select a command such as KEY_RIGHT then it is necessary to re-select the same command from the command slection menu. It would be nice to have the possibility of simply re-press the same command that appears in the string rather than running through the menu selection process.
Glad to hear that 3.4.0 is working. Ill keep doing these single jar releases then. Easier on everyone!
As far as the command, I don’t have any issue with it as long as I can figure out what’s causing the issue. @mhilbush any idea why its happening? It looks like its going back to null immediately after the command is sent.
Let’s make sure I understand correctly…
You’re saying that after sending a keypress string (e.g. “KEY_RIGHT”) to the keypress channel, the binding correctly handles the command (i.e. sends it to the android tv), but that the state of the channel is NULL?
I guess I’m confused about what @Norixone means by “menu selection process”.
Thank you for looking into this request of mine. Actually the KEYPRESS command line does not revert back to null. I’ill try to expalin what I was asking for to the best of my writing capabilities 
When you press on the key press function you get a sort of pop-up menu that lists the available commands to send to the Shield such as
KEY_UP
KEY_DOWN
KEY_RIGHT
KEY_LEFT
KEY_ENTER
…
Let’s say that I press KEY_RIGHT. After I have selected the command and it has been executed, the pop-up menu closes leaving me with only KEY_RIGHT visible in the command line. If I want to perform another key press, I click / tap on KEY_RIGHT which brings up the pop-up menu once again, I then re-select / press KEY_RIGHT and once the command has been executed, the command list closes showing me the last selected value wihich is KEY_RIGHT. This procedure has to be repeated until you are on the app or function you want to launch.
What I was asking for is if there is a way to keep the pop-up list available until I decide to close it.
Maybe I have done something wrong when I copied the available commands into the metadata command field.
Ok, I think I’m getting there now…
Your question pertains to the UI, not the binding. But which UI are you referring to? Main UI, HABpanel, Basic UI?
Main UI. The situation is the same if using the android app or the web interface
By the way. You have the same situation with any other THING that usally relies on a remote control to be operated (i.e. OPPO bluray player).
I went back and checked my logs and I’m seeing some inconsistency that could be related but I’m not sure. It may be tied to the specific channel. Notice below my keypress predicted properly but the pincode predicted to become NULL. Can you confirm in your logs if it’s going to NULL or if it’s staying as what you expected?
2023-01-31 07:28:01.039 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'ShieldTV_LIV_KEYPRESS' received command KEY_HOME
2023-01-31 07:28:01.040 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ShieldTV_LIV_KEYPRESS' predicted to become KEY_HOME
2023-01-31 07:28:01.049 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ShieldTV_LIV_KEYPRESS' changed from NULL to KEY_HOME
2023-01-31 07:28:11.866 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'ShieldTV_LIV_KEYPRESS' received command KEY_RIGHT
2023-01-31 07:28:11.867 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ShieldTV_LIV_KEYPRESS' predicted to become KEY_RIGHT
2023-01-31 07:28:11.868 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ShieldTV_LIV_KEYPRESS' changed from KEY_HOME to KEY_RIGHT
2023-01-31 07:30:12.836 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'ShieldTV_PINCODE' received command REQUEST
2023-01-31 07:30:12.836 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ShieldTV_PINCODE' predicted to become NULL
I’ve posted a new version with a few updates. Most notably, volume control. KEY_VOLUP, KEY_VOLDOWN, KEY_MUTE. I’ve not really had a good test candidate on my side, I do volume in the receiver so the most I see is an attempt to raise/lower on my OSD. If someone can confirm that they are working that would be awesome. Also to note, the message handler has been significantly optimized. As always please report both success and failure so I know things are working out there! Thanks!
EDIT: One small bug snuck in with the volume buttons. Jar is updated. Correct version is 94ebc2f.
Same here, unfortunately. But I’ll still install the new jar in case there are any regressions to be found.
BTW, I cannibalized the ConnectionManager in your binding for another binding I’m working on. (I realize you also cannibalized it from another binding 
). The socket reader/writer model (without all the SSL stuff) worked perfectly for what I needed. Thanks!