You need to enable the socket on the TV itself.
@olivier - Two things:
-
Make sure you follow the setup instructions at:
HubitatActive/Installation.pdf at master · DaveGut/HubitatActive · GitHub -
To get it to work consistently you may need to assign the TV a static IP in the router settings
-
Mine worked fine for months, then came up with this exact same error last week. The fix for me was to go into the device and click "Save Device" and "Save preferences" several times...
Thank you. I did follow the instructions (As far as I can tell).
- I turned on the "IP remote" and "Power On with Mobile" settings on the TVs
- Installed the drivers, created device, etc. (That part is ok it seems)
- Added Fixed IP address in the device preferences and saved.
The "Allow" pop up on TV never showed up at all.
Maybe am I not doing the step 6 from install instructions correctly?
Thanks. I did 2 and tried 3 quite a few times.
Based on my TV (2020 non-Frame Art), I would try the following
open menu Then
Menu -> General -> External Device Manager -> Device Connect Manager
Make sure "Access Notification" is set to "First Time Only"
I had done that earlier from reading the thread, but no dice 
From HE logs, I can tell that HE is able to communicate with the TV as it gets what kind of TV, etc...
So it is puzzling for sure.
I think that I have an idea of what is going on. It seems that the TV doesn't like the remote to be on a different subnet according to some other forums online. Will try that and report.
My TV is reporting as a 2021 model: modelYear: 2021
I lowered the SmartThings poll interval to 1 minute, and it seems to be picking up the changes every minute now, but not locally and not via an event? Not sure if that's expected?
The art_mode status is not in the SmartThings data interface. The status should come only as an event and should only occur if the status has changed via the Websocket interface.
Should I fix this problem by removing all ART MODE functions from the driver? It is a major thorn in my side.
@djgutheinz
Not trying to throw a grenade into this, but I went back to your previous driver before the addition of the art mode and it works great... Been using it for a few months on 10+ Samsung TVs. The frame addition and more reliance on SmartThings just caused too many issues for me. In the end, its working the way I want which is reporting when off and on so it properly triggers other events. You have done great work on this and spent quite a bit of your time... I'm not saying remove anything, but letting you know your older version is still in use. 
Hi @djgutheinz - first of all, thank you for your work on this driver and and responses. I think a lot of my confusion might be due to my just not understanding how the driver works and unrealistic expectations.
I had actually given up on using the art_mode status and instead settled on using trackDescription as it seemed to be updating more consistently (or at least whenever the SmartThings poll job ran).
I took another pass through the documentation and found this page, which coupled with your response above does seem to be in line with what I'm seeing:
- Only power on/off is local (which doesn't really help with The Frame where normal usage is switching modes, not powering on/off)
- Everything else is via ST and requires polling at the frequency of the SmartThings Poll interval (there is no event subscription?)
- ...except for the art_mode which is WS - and that is only updated for a short period after a message from Hubitat via WS (i.e., if you use Hubitat as a remote for the TV, which I currently do not do)
So, my current solution is actioning off trackDescription and setting the SmartThings poll interval to 1 minute.
Last night I also quickly tried the replica app here:
But didn't see trackDescription getting refreshed either without polling...if that is supposed to work with a subscription and might be better for my use case, I can give it a try again.
As far as removing art_mode, for my current use case (only monitoring status via Hubitat, not controlling) being there doesn't help me at all. But maybe there are other use cases where people do control it via Hubitat but still find it useful to get the art_mode status?
As noted above, Hubitat is logging an off then an immediate on signal from the TV at exactly 8:33 pm every night, setting off the routine that should run only after the TV is actually turned off by a human....no one is turning it off, no one is messing with the remote. Hubitat is just logging this, the TV does not actually go off. If you were watching the TV you would have NO IDEA this off /on got logged in Hubitat.
From 2/18 & 2/19:
From 2/20:
I made no new rules. I checked the rules associated with the TV and they are the same as they have been. I have not edited the rules associated with the TV.
What could be causing this, and, far more pressing, HOW DO I STOP THIS?
Any ideas appreciated...
Reading the "[switch: xx, powerState: yy] lines indicates works as specified. for powerState, NC means no connection (not on wifi), standby the wifi on but the display off, and on is the set on. All data comes directly from the 8001 port interface of the TV. You can see this yourself in you browser using YOURIP:8001/api/v2.
In other words, there is nothing I see in these logs I can fix. Something is happening EXTERNAL to Hubitat that is causing your issue. Essentially, the off is triggered by Hubitat not being able to reach the TV set for about 30 - 35 seconds. There are two possibilities:
- The Lan Interface from your router is resetting. I don't know, but this may happen if you do not have a Static IP Address assigned. (not a router expert.)
- The TV itself is busy running some communications process (checking for updates????). I have experienced the disconnect - but rarely.
Question: When this is happening, are on Antenna or wifi based channels?
Update: You might also check Logs, Scheduled Jobs tab and see if there is a job that runs around 8:33 PM every day. If there is, then something in that job may be interfering with Hubitat communications.
It should work if the track title changes in SmartThings; I will check the code over there and make sure to set track description to null on power off and send a refresh on power up. But this would rely on the ST's "switch" state changing - so just using the source would be better.
Driver works great for me, but I don't have any of my Samsung TV's connected to (un)smartthings, only my soundbar as I have it switch inputs and default to a specific volume when the connected TV turns on, as does my fireplace via my Logitech harmony IR hub. All work 100% reliably with on/off TV triggers.
The (un)smarthings hub is a nightmare with anything as an intermediary relay hub in my experience. I only keep it for my Arlo cameras, and it regularly fails to update motion triggers correctly, getting stuck on "Active" for hours when the actual Arlo camera is reporting motion as inactive. I've actually had to write a webcore failsafe for the cameras to prevent my outside lights (activated by Arlo motion alerts via Hubithings Replica) being stuck on for hours. In my completely uneducated experience, (un)smartthings is a POS and the less devices that have to use it to integrate with Hubitat the better.
Dave, thanks for all your hard work on this driver, and for sorting the driver for my soundbar, both work perfectly and my vote would be to leave dump the art mode and leave well alone. 
Thank you for your response and your patience with me. Regarding the status:
Reading the "[switch: xx, powerState: yy] lines indicates works as specified. for powerState, NC means no connection (not on wifi)
TV is supposed to always be on intranet wifi. I'm not sure how I can check this. I think you saying that if the TV loses wifi connection while it is on, Hubitat recognizes the TV as off and executes the commands it should execute when the TV is turned off? The portion of that I don't understand is that on 2/20 when TV was physically turned off via its remote control, it reported "Switch Off (as it should) and PowerState: NC" Was this NC a coincidence? If it had gone NC sooner, it would have done the off/on thing?
standby the wifi on but the display off,
As you can see, I rarely get that one
and on is the set on.
That seems to work.
All data comes directly from the 8001 port interface of the TV. You can see this yourself in you browser using YOURIP:8001/api/v2.
I put my that in my browser (substituting "YOURIP" with my actual IP) but I only get this message:
[the less than symbol then the word, then the greater than symbol: html- body - 404 -body
-html
There are two possibilities:
- The Lan Interface from your router is resetting. I don't know, but this may happen if you do not have a Static IP Address assigned. (not a router expert.)
Both the Hubitat and the TV are assigned a static IP via the router.
- The TV itself is busy running some communications process (checking for updates????). I have experienced the disconnect - but rarely.
The TV is blocked from the internet at the router, so it can't check for any updates.
Question: When this is happening, are on Antenna or wifi based channels?
On 2/18, 2/19 & 2/20 when it did this at exactly 8:33 PM, the tv was playing content from a physical Roku (not the Roku app) which is connected to the TV via HDMI.
Today, 2/21, it happened again but at 5:25 pm. The TV was playing music from a connected USB drive.
Update: You might also check Logs, Scheduled Jobs tab and see if there is a job that runs around 8:33 PM every day. If there is, then something in that job may be interfering with Hubitat communications.
Thank you; that is an interesting list. I expected to see the things I have scheduled associated with time (shades & lights). However, I learned most of the entries are for the many devices that have scheduled "sendping" "onPoll" "UpdateDevices" "sendBPUPKeepAlive" and "refresh" Had no idea any of this was happening. However, nothing is scheduled for 8:33 pm, or for 5:25 (time the tv did this today). Bizarrely, a bunch of things are scheduled to run at 9:54 pm..
I am out of any options on local polling. Anything periodic (i.e., 833PM) is some interference outside the driver. There is no scheduled tasks in this driver that occur at that regular a time every day. Nothing I can do except getting away from local on/off determination.
Try setting the perference "Power Polling Method" to "SmartThings" and save preferences.
Try setting the perference "Power Polling Method" to "SmartThings" and save preferences.
Done.
And thank you so much for both this driver and for your ongoing patience and support. Both are very much appreciated as I learn about the nuances of Hubitat. It makes total sense that there is no scheduled task on the driver - I would not expect there to be. I just can't figure out what causes the TV to report to the Hubitat that the switch is off when it is not really off, and then in less than a second report that it is back on. I'm trying to figure out if perhaps the TV reports it was switched off when perhaps for some reason it just does not have a wifi connection.
Also, I've thought of another way to address the issue of the automations running when this switch on/switch off sequence runs within a fraction of a second. I will try to add a condition to the automations associated with the TV that they will only run if the TV switch = OFF and it has not changed in 2 seconds. The inevitable 2 second lag should not be much of an issue, because when the TV is normally turned off via its remote, the automations associated with that have a lag anyway, which I think that may be because I have Power Polling Interval set to 60 seconds.
The 60 second polling is another reason this switch off/switch on sequence all within a fraction of a second is so confusing.
I already require two off indications from the TV, 5 seconds apart, to declare the TV off. Same reason as you state. That is why I suggest using the SmartThings status (Samsung wrote the ST driver and it may(?) be better in detecting on/off. They have access to more information on the device than I do.
Dave
Thanks. Interesting info. Maybe my TV is just slow...
I realized that changing the Power Polling Method to SmartThings would not take, so I also changed the "Connect to SmartThings for added function" to blue (True?). That caused the change to the Power Polling method to stay after the Save Preferences.
