Samsung TV integration - we need to talk!

Development
1

I want to start by saying that a hell of a lot of fantastic work has been done around the HA Samsung TV integration (www.home-assistant.io/integrations/samsungtv/) and I applaude the work of the numerous contributors who have worked extremely hard in getting it to where it is to date.

But… as an observer, there are currently numerous functionality issues, directions and as a result, confusion for numerous users. Currently there is the official integration, 3 HACS versions and numerous forks on Github. Some work well, some sort-of work and some work for no one. In my own case, the official version reported states for me until it was switched from YAML to the integration version. Now I get a “not supported” error so I need to use a pre HA 0.94 version as a custom component (to keep me ticking over).

Putting that aside though, I am appealing to the hard-workers on these integrations to come together and see how all can pull the individual efforts tighter together and utilize the community (inc. myself) in supporting improved documentation and a compatibility table. There was somewhat a useful TV compatibility list previously on the official integration page but has since been mysteriously removed. This was extremely useful instead of users scrawling through forums for a solution that may (or may not) be out there for their Samsung TV model!

Below are some links which I think would be useful in putting this documentation together. In particular this link at https://developer.samsung.com/smarttv/develop/specifications/tv-model-groups.html which lists all the Samsung TV (Tizen) Models and the Tizen OS version(s) associated with each TV model(s).

What do Samsung TV model numbers actually mean? Why are they so long?

Samsung TV - Tizen OS (2015 - present)

Samsung TV Launches (yearly)
https://wiki.tizen.org/Devices#Smart_TV

Samsung TV - Orsay OS (2011 - 2015)
https://emby.media/community/index.php?/topic/9869-samsung-orsay-smarttv-2011-2015-community-app-install-instructions/

I would be interested in seeing what people think. Its important to note that I do not want this post to be seen as a criticism to all the excellent work done to date. I understand this integration is far from straight forward due to Samsung constantly shifting things around. I hope this post is of some use in how this integration can be even more refined for our community!

CC:
@Screwdge
@jaruba
@roberodin
@piitaya
@xchwarze
@Ollo69
@escoand
@kylehendricks
@tulindo
@xchwarze

(apologies if I left anyone out!)

7 Likes
2

Applaud the initiative, couldn’t agree more! Until I found @jaruba’s component I was struggling a lot and very disappointed by what the component could do. Now I have full control by voice via Google assistant which I love and use daily (turn on/off, change channel, volume/mute, playback state in any app).

My view:
I have noticed the complexity mainly stems from the various ways/interfaces these TVs can be controlled and all the options and difference in support this brings (SOAP (old)/websocket (more recent) local control vs. smartthings cloud integration (newest)).

It seems to me the smartthings integration is the most capable, extensive, easiest to configure and probably the most future proof. The only downside is that it has a cloud based interface.

Would it not be an idea to bring this part of the media player support to the smart things component and separate it out from the local control and then keeping the samsung tv component to local control only? Since Samsung keeps a list of smartthings supported TVs (https://support.smartthings.com/hc/en-us/articles/210765826-Is-my-Samsung-TV-Compatible-with-SmartThings-) anyone that would accept smartthings would have a lot easier of a time in their configuration and figuring out whether or not it supports their tv.

Question here is: is the supported feature set of smartthings consistent across tvs? Does anyone have any experience with this?

I’d also need to have a look at the current smartthings component to see if that is any good and how it fits to current smartthings implementation inside the tv component.

Would be interested in your views on this!

Other than that happy to contribute to any feature table for my Samsung TVs, but I’ll tell you the table will be very complex with all the different integration methods and features of the variety of components…

2 Likes
3

Honestly I don’t think that put all work together to have “the best samsung TV” plugin is really possible, at least not until a coordinator (like HA) will take in charge this.
Let me clarify, as example, how my component version born. I start trying HA default component, but with my TV model (QF7) the component didn’t work at all. So I start searching on internet for custom component, and after some very bad experience I found JAruba version that was not perfect but fine. So I start with some PR on JAruba version, but after some time JAruba stop working on the component (this is not a critic, just a fact). So I continue to work on it by myself and considering the good progress I choose to public it on HACS to make it available for more person. But at this moment, after about 6 month, the code in my version is totally different from JAruba version and PR my version will totally overwrite the original. And why J. should accept this?
Also consider that probably my version work really fine on some model and not on others, same for J. version. But I have only 1 TV, I’m not able to say which model my component support.
What should be useful, from my point of view, is a review of the main component version used by the community, with a clear indication of feature / pro / cons that every version provide, enriched by the list of supported model based on users declaration. This would probably help in define which is the best version at this moment, that may be in the future will remain the only used. But this should be supported by the good will of the user that should test all the component versions to provide a real feed-back for supported model. Is the community interested on this?

2 Likes
4

Well said @ollo69, you’ve hit the nail on the head. Success requires someone from the main component laying out a definitive roadmap that contributors like yourself can get behind. It can be difficult when great, fellow contributors drop-off projects for what are generally, understandable, legitimate reasons.

Off the top of my head, here are some suggestions below. Place note that I may have not full grasped the technical challenges so apologies if I’ve got this wrong.

The first key goal potentially would be to focus on baseline reliability & compatibility. I wonder is there a pattern to the current compatibility and/or reliability challenges? i.e. Tizen version (2/2.5/3/4/5/5.5)? Firmware version? etc.

Second is “Communication Methods”. These include:
Ping:??
ctl: Default HA protocol.
Websocket (ws): For 2016+ TVs models.
ctl_beta: Last beta version of samsungctl.
ctl_qled: Only for latest TV QLED models and similar.
smartthings (cloud):
legacy: (Added as suggested by @escoand 20200922)

Below is a rough sample mock up table for users to test compatibility/reliability:

Compatibility/testing Table (DUMMY SAMPLE)

Model OS Year Tested Tested HA Ver. Protocol State OK Controls OK
QTQ6SC Tizen 5.5 2020 Y 0.101 ctl_qled Y N
URU7470 Tizen 5.0 2019 N N/A N/A N/A N/A
UNU7400 Tizen 4.0 2018 Y 0.97 WS N N
UMU6400 Tizen 3.0 2017 Y 0.94 CTL Y Y

Because I’m the outsider here, I’m not sure whats the next logical step. Would be interested to hear from more of the community. Happy to help if I can be of assistance :smiley:

2 Likes
5

@ollo69 I never really stopped working on the component, but the immense number of constant community questions fulled up the free time I had dedicated to the component. I actually burned out at some point due to the flood of constant community discussions about it, but never stopped working on it. I have to say it saddened me when you decided to fork out, as working together would of led to a better component overall.

As for integrating all the work into the main Samsung component, this is not the first time this is proposed, the current official Samsung TV component was rewritten based on the last attempt to pull together all the code from all the community projects. I was invited and took part in long discussions regarding that rewrite, I pulled out of the discussions at some point because the HA dev that was overseeing the rewrite decided to remove a lot of comments from the discussion, wrongly marking them as “off-topic”. He was also extremely against adding many vital parts to the official component, believing that SmartThings should stay a separate component and not be part of the Samsung TV component, he was against SOAP also, etc. which in the end led me to believe that it simply won’t end up as anyone would of hoped.

I’m here to stay though, and even if I’ll be inactive for some time, I’ll always try to go through PRs and discuss / merge them. I have a 2017 TV and a 2019 TV for testing, which ensure the component works across different Tizen models.

IMO, my component and ollo69’s are the better ones, and they are extremely similar even now (i went through ollo69’s code). If he wouldn’t of decided to fork out, Samsung TV Tizen would of probably been the ultimate component with no good alternative. Regarding supported models, I get a lot of comments of what TVs work or not with my component, but it’s hard to keep track, especially because in many cases they might not work due to user / network issues.

There’s no real way of fixing the Samsung TV confusion between the many components out there. I don’t think anyone is willing to just remove their own component in favour of a different one. And working together is simply impossible also, as everyone is focused on their own thing. I personally try to go through the many components available, keep track of their commits, check if there’s anything worth salvaging from them and make the changes to mine too. ATM my component seems to be the most popular and also gets the most PRs, I have a few ideas about new features to implement also…

My guess is that in time the Samsung predicament will solve itself, as new TV models will come out and the components that don’t support the new models will probably die out. So just maintaining a component for long enough might be the key to this.

7 Likes
6

Hi @jaruba nice to hear you here. Just want to say that from my point of view there are no problem to merge back my component version in your and work togheter on this, let me know if you want to move in this direction.

3 Likes
7

@jaruba Sincere thanks for sharing your experience with the official component team. It’s disappointing to hear your experience but it hasn’t dampened you, @ollo69 and others in persevering and continuing to develop and support the mass of users who simply can’t get the official component to work (inc. me)!

@ollo69 it sounds like both yourself and @jaruba have a lot in common and i’m thrilled to read you will both initiate a discussion on how to move forward collectively with both your combined expertise… V EXCITING :smiley: Afraid my Python is basic to be of any help but happy to help out with the documentation if that’s any good? I’ve a UE55MU6400 so happy of course to do testing for it in the future.

I look forward to your joint efforts in putting the ‘official’ component further to shame :wink:

1 Like
8

@ollo69 I added you as a collaborator to ha-samsungtv-tizen

4 Likes
9

Thanks, I will start creating a PR from my fork on next days, than we will continue discussion directly there.

4 Likes
10

Hi guys.

First, I was in the last years probably the most active part for the build-in samsungtv integration but my last PR shows my current problem. I can only progress really really slow because of my private life. So to be honest I would like to open the way for somebody else. I’ve added myself as codeowner but it seems most people think I’m now responsible for fixing all existing bugs and add new feature, and of course in time. The only reason to add me as the codeowner was to be up to date with the development.

Anyway, I’ve also looked at some of the custom components but got lost in all the different implementations. I’ve no official information of the used protocols but in my case there is even one more nobody else mentioned yet: it’s called legacy in the code. It’s a simple socket connection with a pretty limited protocol for just sending key codes, nothing more.

In the initial post there was also the question who and why the old supported TVs list has removed: it was me! The list is per definition out-of-date with every PR and no one will ever be able to test if a once not working TV is now working. In my opinion this does confuse more than it helps. But I have to admit with all the different used protocols we maybe need some kind of feature matrix. But I would say this should not base on a specific TV model but maybe the platform version of https://developer.samsung.com/smarttv/develop/specifications/tv-model-groups.html, not sure.

Don’t know it all the custom component editors are up to date of the recent developments in the component. @tulindo was so brave to implement an abstraction layer and added the samsungtvws library to support WebSocket devices: https://github.com/home-assistant/core/pull/31537
This could be the ground work to add even more protocols. And here comes the point @jaruba mentioned: the core developers team wants to use external libraries but not implement some protocol directly, otherwise your PR will get blocked or denied.

I’m pretty sure I’ve forgotten some of my points but I will finish this first reply with a statement of approach: The problematic situation was created by Samsung and it’s annoying for everybody but it’s getting worse if we create more and more custom components and not upstream (maybe as different components?) our work.

3 Likes
11

Hi @escoand,

Thanks for reply. Thank you for the great work you have been doing with the official Samsung TV integration. It can be a thankless job sometimes but there are many who appreciate the work you and many others have been doing. I appreciate as well that you have enough going on in your life already with work, family and everything else. It can be a ‘double edge sword’ when taking the initiative to lead on open source projects like this because everyone then levitates to you as the ‘go-to-guy(s)/gal(s)’! But yes, the root issue here fundamentally is Samsung (my next TV will be LG).

I appreciate your feedback regarding the compatibility table, its omission and it being outdated. Yes, there must be some pattern with issues, whether its Tizen OS version or Firmware version etc. Its difficult to know whether the platform version (Tizen OS version) is the common denominator here because personally I have a 2017 Premium TV (UMU6400 - listed as Tizen 3). However a firmware update I installed a few months back put an end to the components functionality! It could be perhaps that the Tizen OS version was updated… I don’t really know?

Is it worth reaching out to the community to try and identify what users are having the most success so far? Just a thought.

On another note, has anyone used the Samsung SDK with the Tizen TV emulator to see if some of the issues can be replicated?

PS: I’ve updated my post above to include “legacy” communication method.

12

@rosscullen Thanks for the summary. As the core team enforces the usage of external libraries we should add the best library with support for this protocol. For legacy it’s samsungctl and for websocket it’s afaik samsungtvws.

Somebody of the core team has to decide if separated components are allowed…

1 Like
13

@escoand Isn’t samsungctl (or “legacy”) used only for pre-Tizen TVs? Many components (including mine) choose to not work for pre-Tizen TVs. In my case, I choose to not support them because they are old tech (pre-2016) and just add complexity to an already excessively complex project. (complex because Samsung)

14

@jaruba Yes, you’re right. And yes, my TV is old tech, but still working. :grinning: I think all this complexity was the reason to only allow external libraries in components and not implement it directly. With the already mentioned abstraction layer it would be no problem to add support for new protocols. But for more advanced libraries we definetly have to extend the abstract class: https://github.com/tulindo/home-assistant/blob/0ac95fbed3e38378f1c4212f889af1fd47d4c1d7/homeassistant/components/samsungtv/bridge.py#L33-L123

15

@escoand

“I think all this complexity was the reason to only allow external libraries in components and not implement it directly.”

^ there are other issues to consider here, for example: if you allow setting up SmartThings (requires an API key) on a component that also supports non-Tizen TVs you’re going to have a lot of confused users

And in general, there will be a lot of features that will only work with Tizen TVs, and a lot of users with non-Tizen TVs asking about them. I think it’s generally cleaner to support current / future tech over old tech to alleviate user confusion in the long run. But heck, you have an old TV, so I know I won’t convince you. :upside_down_face:

16

Judging by the TV model groups link from earlier ( https://developer.samsung.com/smarttv/develop/specifications/tv-model-groups.html ) that ‘pre-Tizen’ Samsung TV’s were 2012-2014 (3 year period). Tizen based TV’s are 2014 - 2020 (almost 7 years). Would it be worth considering a separation of the integration to “Samsung TV (legacy)” or “Samsung TV (Tizen)”, considering the underlying OS of both are somewhat different?

I can appreciate @escoand that you’re using a legacy Samsung TV and the integration works very well in that instance. The concern going forward (personally) is that there is a lot of confusion out there already for the broad spectrum of Tizen OS users and currently no definitive pattern on why the integration works for some users and not for others. Then in some cases, you have legacy users saying “works fine for me” without understanding the full picture! Its a tough one :thinking:

17

As long as the legacy is still working (in any way) I’m fine with a separation. But there are a few questions:

  • Is there only one Tizen solution, or do we need more?
  • Is this separation into legacy and post-legacy (or even more) allowed by the HA core team? @balloob
  • What should be used as a basis for this new integration? The code of the chosen custom components needs to be extracted into an external library.
  • Who feels responsible? Not me. I can’t help with testing and my time is pretty limited.
  • When is the right time to deprecate and remove the legacy integration?

And maybe more…

18

All very valid questions. Any thoughts peeps: [mass notifications removed by moderator]

Is there an appetite to split the integration to Samsung TV (Legacy) and Samsung TV (Tizen)? It appears that the legacy is somewhat reliable and stable. But for Tizen users, its very much a mixed bag with no apparent pattern that I’m aware of. Even for basic features (state, on/off, volume/channel up/down, mute etc). Is there a willing group out there to support this project? Personally, I’m able to manage documentation and testing if its of any help (my Python isn’t up to standard unfortunately). Don’t be shy, drop a constructive comment :blush:

19

@rosscullen It is limited to 10, because there is in general no need to have more. One should not go and start tagging people randomly.

See point 16 of: https://community.home-assistant.io/t/how-to-help-us-help-you-or-how-to-ask-a-good-question/114371

Please adjust your message and remove the mass tagging. Thanks.

1 Like
20

Apologies @frenck, duly noted with thanks. Everyone tagged has had input previously on this integration. Look forward to reading further feedback from the community. Thanks :slight_smile: