Philips TV (2016+) Binding

Its running on the tv with version 8.

GoogleTV is an app loaded on top of AndroidTV. You need both for it to work.

Ah, will try that then, thanks.

Edit: i see in google play store that its already installed on the tv.

Awesome, can you connect to the tv with the googletv app on your phone?

Not at home at the moment, but will try when im at home.

Yes, i can connect to the tv with the google tv app on my phone.

Interesting. I’ll send you a direct message so we don’t flood everyone watching this thread.

Just in case someone else wants to follow my approach:
Based on the binding and the (ridiculously bad documentation JointSpace API Documentation) I created a small Node.js service that helps me handle the use cases I need to cover:

  • Muting: /audio/volume
  • Power: /powerstate (undocumented but used in the binding)
  • Ambilight: /ambilight/cached (accepts RGB)

While I got my scenarios covered for now, I would still appreciate someone taking this binding over to OH 4.

I did a recompile of the binding for OH4. Only a small test was performed: it starts on my OH4 test server and the volume channel, mute channel, ambilight power are working. My “production environment” is still on OH 3.4.

I did not test for a long time, but it seems to work as it does for me in OH3.4. The 3.3.0 binding didn’t work at all in OH4.0, so it seems an improvement.

You can download from github:
philipstv binding OH4.0

Please note (for the programmatically interested):
I only had to change the copyright text of all the sub-files contained in the project (was 2010-2021, needed to become 2010-2023) and add an addon.xml to be able to recompile.
As it is simply a recompile, it does not mean that I made any changes to make it fully compatible with OH4.0 or java17. It now contains some deprecated code and still may throw “null”. In that way it is not really compliant with OH4.0 programming. (disclaimer!!!).

1 Like

Its a start!
Will try it as soon as im home.

@Chiuaua79 was faster, but I also built the binding for OH4.
My version has the following additions:

  • Changed power, mute, volume and player to system channel type
  • cancel pairing when PIN is wrong
  • added challengeHeader to digestAuth (realm, nounce, …) when grant PIN

You can download from github:
org.openhab.binding.philipstv-4.0.0-SNAPSHOT.jar

3 Likes

Hi @NorbertHD, I just downloaded your version and it looks good so far for my needs.
Thanks for providing a solution so fast!

1 Like

Excellent work! improvements are always good.

I’ll skip the fork from Benny and fork yours.

1 Like

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 Philips TVs are all AndroidTV based. Thoughts from the users of this?

1 Like

Hello @morph166955, I have no intention of developing this binding further, so please take over.

Seems reasonable.

I’ve begun the work to pull this in. I do not have a working model yet that compiles clean, but I’m getting close. Eventually I’ll need someone (or multiple someones) who can test the jar and tell me if anything broke between the current release and what has been pulled in. Once I know the code is good I can work on adapting it tighter to the binding and remove duplication.

I’ve made the first stab at pulling this into ATV. I would love if someone could test to make sure I didn’t break anything. In theory, it should work the same as the existing.

EDIT: Replaced below

Configuration would be androidtv:philipstv:devicename instead of philipstv:tv:devicename. The one thing to note, there is a thing configuration now added called gtvEnabled. Please set this to false so that we don’t stomp on the GTV protocol. Everything else should be identical in terms of channel names, thing configs, pin, etc. I tried to leave as much code alone as I could so we know it works before I try to normalize it to the binding.

If anyone is willing to give this a shot, please let me know success/failure. THANK YOU!

1 Like

I can definitively help. I will do some tests this weekend.

Awesome. I had some dependency issues when trying to build a jar for 3.x compatibility so please let me know what happens. I may have to have separate jars, not sure as I dont have a 3.x here to test on.