The latest updates look like they fixed all the log messages. Thanks!
1 Like
Hi @armand
Both of my TCL Roku TVs had their firmware updated today morning (6/25/2020). The new firmware is version 9.3.0, build 4182.
I am mentioning this because the new TV firmware has changed the XML returned when the Roku TV is powered off. Previously, when "Fast TV Start" was enabled, and the TV was powered off, the XML returned contained:
<power-mode>Headless</power-mode>
For the same condition (power off when "Fast TV Start" is enabled), the new firmware returns:
<power-mode>Ready</power-mode>
Because of this change in what is returned by the TV, the Roku TV driver may not detect when the TV is powered off. Presumably, this is a simple fix in the device driver by adding
case "Ready";
immediately above
case "Headless":
Cheers!
1 Like
My firmware also was updated. I added the change @aaiyar suggested and the power off now works again. Now I see the following in my log when I turn the TV off:
My questions are (1) why are there so many connect attempts so close together and (2) why after the TV has been shut off?
I have been on vacation. I will take a look tomorrow. The connection attempts happen for every refresh. What is you refresh interval?
1 Like
I believe I have it set for 10 seconds.
Small nitpick, but I think you wanted a : instead right?
1 Like
Turn off Logging on the TV device that is producing the errors and the errors will be surpressed. But the errors occur because your TV is refusing the connection, or cannot be found at the configured IP address. Do you have Fast Start turned on? This driver required Fast Start be turned on. I did a minor change to logging to support the TV being powered off not reporting errors, by linking the reporting of these errors to the log enabled switch.
If you don't want to see the errors, turn off logging, or enable fast start on the Roku TV.
Fixed in the master code branch. Thanks for the heads-up.
1 Like
Not at all. The driver wouldn't work with a semi-colon - good catch! I actually don't use this driver, but while figuring out why my mini Roku-TV on/off integration stopped working, I realized the same might happen for @armand's integration.
1 Like
I try to do the same. Thanks again for the notice.
1 Like
My use case may help things a bit. I have an AppleTV which turns the TV on and off. I'm not sure if that helps, but I did see where the log will indicate the executing PowerOn and PowerOff when the buttons are pressed, but not when the driver finds the power on or off due to a refresh.
The main reason I use the driver is to turn on and off a set of LED lights behind the TV. Those lights turn off within 3 seconds of the AppleTV turning off the TV itself. The lights turning off tell me the driver knows the device has switched off. That is why I'm asking about all the connect attempts after the TV is off.
With that said, the logging has been on since I installed the driver. The only time this started to produce debugs was after the firmware was updated. I do have fast start enabled as well. I may have misread your response, but I think my two questions are still unanswered:
- Why are there 3 connects in very rapid succession at the start of each refresh interval?
- Why does the driver reach out after the device has been turned off?
In addition, a third question would be why did this start after the firmware was updated?
The 3 connects are because there are three different operations to be performed.
The reason the driver reaches out after the TV is turned off, is because the TV does not send alerts when operations are performed.
If you turn the TV On using anything other than my driver, I will never know it was turned on, because there is no signal from the TV to state that it was turned on. Instead, I must ping the TV to see if it if on, and the only way to do this, is to issue a refresh, which pulls for all the pieces of information. I cannot use a network ping, because a powered off TV that is still on the network, would respond, but not necessarily be on. I also cannot rely on a failed ping to mean it is off, and just ignore the error, because it could also mean that the TV's IP address has changed, and without the error, there would be no indication of the this.
If you put your Roku in Fast-Start mode, then it will go to sleep (display will turn off) but the network will stay connected, and I can poll the TV for data. But if it is not connected to the LAN, it will never power on. That is that way the Roku system works. That is the way a lot of LAN/WIFI powered systems work. There is nothing I can do in my driver to change this behavior.
When I do a refresh, to try and determine the TVs state, the following three operations occur:
query/device-info
Polls the TV to determine the power on/off state of the TV, as well as other information returned by the call
http://<tv_ip_address>:8060/query/device-info
query/apps
Polls the TV to determine the current list of installed applications.
http://<tv_ip_address>:8060/query/apps
query/active-app
Polls the TV to determine what channel/app is currently in use.
http://<tv_ip_address>:8060/query/active-app
Neither of these can be reduced to a single query. I offer you the ability to tune this though. If you do not want to know about the installed apps, you can disable this query.
For one, you can turn on the "Refresh current application status separate from TV status". When you do this, the refresh operation will not perform the query/active-app operation except for the interval defined for that option. If you turn off "Automatic management of child devices" then the query/apps operation will not run unless you execute the "Reload Apps" function.
And again, all of this expects that you have "Fast-Start" turned on in your Roku device. Without it, you will always get exceptions when the Roku is turned off. If you don't want to see those exceptions, turn off logging.
1 Like
Thank you very much for that detailed explanation. That really helped me understand how your driver works. It also helped me understand that I am also not using your latest greatest. So I installed it seems to work. However, when I turn on the "Refresh current application status separate from TV status. *" I get the following errors:
I included a picture of my TV settings as I am not able to convey that I DO have the "Fast TV start" enabled:
At this point, I'm not sure if I am chasing one or two issues. I am thinking there was a change in the Firmware that your driver may not have caught and that's why I'm getting the errors reflecting the Fast TV Start being off.
I am also beginning to wonder if there might be an issue with the WiFi interface periodically shutting off. That would explain why I only see about 18 errors (6 refresh periods @ 3 connections per). If my Fast TV start wasn't enabled, my log files would be filled with those. I thought it was associated with turning the TV off, but that may not be the case.
Here is an update. With the new driver, I am have not seen the connect issues presented before. I will continue to monitor.
I am curious as to why I receive errors when I change the "Refresh current application status" even though the Fast start is enabled.
This is a known bug. I don't support times larger than 59 seconds (I don't know why I set the default to 60). Sorry. I will add a refresh units to the Current app refresh interval. The typical use case is the refresh the TV status every minute, and to refresh the Current app every few seconds. Because you power off your TV instead of putting it to sleep, and because you don't use the apps, your use-case is backwards from what I designed for. Doesn't mean it won't work, I just need to make another change.
Assuming everything is configured correctly, it is possible the timeout setting on your driver is too aggressive. If your TV is on a LAN, a timeout of 3 seconds (my old default) is sufficient to ensure the device is not hung waiting for a response while the TV is actually powered off. Since you have fast start, that is not the case, but network congestion can still be an issue. I changed the default from 3 seconds to 10 seconds to fix this. But if you have the old value already set, simply change the timeout to 10 seconds and see if this fixes the issue. If it does, it's not a reason to be alarmed about, it just means your network is congested on occasions, which is typical with WiFi.
If Fast Start is enabled, as you stated (I may have misread your prior posts, not sure.. very tired), then the IP must have changed, or is unreachable from the Hubitat. I see it states that it updated your MAC from the IP. The MAC address should never be updated, unless your device changed IP Addresses, and my code is picking up the MAC from another device on the IP address.
If IP address is correct, and then the other thing you need to do is to verify that Control by Mobile Apps is enabled (this is the ECP protocol setting that the driver uses).
Go to "Settings -> System -> Advanced system settings -> Control by mobile apps -> network access". Make sure the value is set to Default or Permissive. If default does not work you may need to change to permissive. The difference is subtle, but impact accessibility.
Additionally, if both devices are on WiFi, make sure your wireless access point does not have Wireless Client Isolation turned on. This feature prevents two or more WiFi devices from talking to each other, so it must be disabled for a home WiFi network to work. Hubitat ships with ethernet, but if you use a WiFi bridge to make it work over WiFi, then this becomes a possible issue.
Finally, the last thing I can think of for the failures to connect could be security devices. If you have a Firewalla, Ubiquiti Security Gateway, or some other IDS/IPS (Intrusion detection prevention system) then those are known to disrupt network traffic for various reasons. In the case of Firewalla, the firewall is very slow, and will absolutely cause network timeouts that exceed the 3 second default of the old driver.
My changes that might help out with the refresh interval have been pushed out.
Notice, if you Roku Media Player cannot turn your TV on/off, and it is connected via an HDMI cable, not all HDMI-CEC compatible cables work with Roku devices. I upgraded my Roku setup, by replacing an old HDMI 1.1 cable with a newer HDMI 1.3 cable (because I wanted to shorten the length), and I did not test the remote on/off feature until recently when I noticed my TV can no longer be controlled by my Roku. I replaced the new cable with my old one, and my Roku can now control my dumb TV again. Not all cables are created equal, and not all HDMI 1.3 cables are actually HDMI 1.3 cables apparently (or at least, not HDMI-CEC compatible). Lesson learned.
2 Likes
I am having an issue with the Hubitat Package Manager install of version 1.2.7. It keeps repeating. I have tried a repair in Package manager but that doesn't help. I have hit update at least 5 times and goe to the app and the children and resaved and it still tries to update the version.
Any thoughts?
LJ
Try removing, reboot, reinstall, match apps, and update.
Try going to "Drivers Code", select "Roku TV". Click Import, confirm the import, then upon completion, click save. HPM basically just does this for you. This may be enough the sync up your HPM with what is installed. I would not delete the Roku TV device type, unless you can uninstall your devices and re-install them without a lot of work.
First off, I want to reiterate how thankful I am for all the information, explanation and effort you put into this. I get I'm an outlier. I have been and always will be 
That said you have given beyond what I think anyone would think is reasonable in effort!!
So far the latest driver works very well. I think I'm using a wood chipper for what really needs a pair of hand clippers, but it does the job!!! I'll keep you updated if I run into any more issues.
