[Release] Roku Connect integration App and Roku TV Device Handler

So I’ve been playing with the integration and have it triggering a scene when the status is changed to paused or stopped - awesome stuff!

Would you mind explaining the difference between the two refresh values? Which do I need just to refresh the status?

Could I also make a suggestion: the ability to increase the refresh rate based on a switch being toggled. I’d imagine my use case wouldn’t necessarily be too unique and triggering actions based on the status is something that would be valuable to those using the app. Although increasing the refresh rate makes me nervous having experienced issues with apps that are too chatty. Having the ability to increase the refresh time value based on a switch being toggled would mean that this could be increased when its more time critical e.g, in my case I have my movie scene activated but decreases back to something less frequent when its less time critical. This way there is less activity from the app when its not really needed…


Soon there will be three.
First refresh, described as, "Refresh the status at least every [...]" is the full device refresh. It will call the following operations:

Return XML data consisting of all the device information for the Roku. This is the most intensive operation, and the only operation used to determine if the TV is on or off.
(truncated sample)

Returns data about the media player. This is used to determine play, pause, stop state. This can also provide current position in the stream, the size of the stream (in milliseconds), and various codec details. The response if rather light weight.

Returns a very lightweight response of just the currently running app. When the TV is off, the current app returns to Roku (The name of the home-screen app)

Return XML of all the installed apps. This is used to know what apps are available for installing as a child app, and what the app ID numbers are to active that app.

Second Refresh, described as, "Refresh the current application at least [...]" is for determine what the current app is, and does nothing else. This calls the function
query/active-app which as shown above is rather light weight. I set my main refresh to every 30 seconds, and my app refresh to every 5 seconds.

You can always ask, but in this case, I cannot deliver. It would run counter to the design goals. Device drivers should be simple. Any integration type logic should appear within the rules, not the device driver. Failure to keep things simple and focus strictly on control logic, results in overly complex and less adaptable solutions.

To solve achieve what you want, just create a rule in Rule Machine that calls refresh every 2 seconds, if the TV is in a Media Player state, like this:

After my next update, I will expose each of the refresh methods as commands, so you can call just the refresh for the media player. For now, this will work, and it should not be too taxing, since it will only enforce the aggressive refresh during media playback. But in addition, I will have logic for the 3rd (media player) refresh that when enabled as a separate refresh, allows the media player to refresh on its own schedule. And the refresh will only take place if the app is already active.

Thank you for bringing this up, as it exposed some more limitations in the driver that need updating.

I have a quick question, if i press a button on the roku remote does the event show in the app???

No. The API I use is a public interface created by Roku called, ECP or External Remote Protocol.

This protocol allows developers to create remote control apps, which is what I did. This is not a true integration, in that I cannot listen for TV events, so there is no way to know what keys where pressed on the remote.

1 Like

Ok thanks :+1:

Should have read the last couple of posts as that seems to be doing what i want to do when pause is pressed turn some lights on, when play is pressed turn them off, Using a harmony remote.

1 Like

FYI, @ogiewon's Harmony integration can pick up Home Control Buttons.

1 Like

Is anyone else having problems upgrading this from HPM? The Roku TV driver fails, and if I try manually it also fails on line 83.

Metadata Error: Capability 'MediaTransport' not found. on line 83

This requires the lates Hubitat firmware. I will reconsider if using the capability was a good idea, but I expected everyone would be upgrading.

1 Like

Tried installing using the HPM, not sure what is happening. How do I start it? Should there be an APP in my "apps" list? I don't see one but I see it in the "apps code" section. Please note that I'm an HE n00b and this is actually the first "install" with HPM. Saw that you had created a Roku app and as I have several ROKUs this was a no brainer to install.

Thanks for whatever assistance you can provide.


Under Apps, install User apps, and select Roku Connect.

1 Like

Thanks, that makes sense. I always wait for a bit to upgrade. If I don't have an issue, I wait to upgrade, look at all the threads of issues on 226.

Sorry about that. They added support for the capability and I jumped on using it for the play, pause stop feature. I will always prefer a standard interface when available. I should update the minimum firmware version level to a real version.

After the latest update, I tried to mess around with this further, and only one of my three streaming stick + devices was showing up right. I deleted all three and re-added them, but when I do, I no longer see child devices for the apps. Also when I click on the device, I'm getting the following error:

An unexpected error has occurred trying to load the app. Check Logs for more information.

Error: Cannot invoke method sort() on null object

Any Idea what's going on? Thanks

Edit: Also seeing this over and over in the logs: (x'd out my IP, and app 1256 is Roku Connect)
2021-03-29 10:45:09.737 pm errorjava.lang.NullPointerException: Cannot get property 'name' on null object on line 383 (ssdpHandler)

This appears to be a behavior change in Hubitat, or maybe a long standing bug the was never exposed. I make a call to device.getChildDevices() which should return a list of devices. Instead of an empty list, it started returning a null value. I made the list optional, so now the sort() works even on a null list, instead of an empty list.

Apparently, at one time I had a variable called "device" which conflicts with the built-in device reference, so I renamed it to "roku" but left a log message referring to "device". This one was not likely to ever show up in testing, because it only ever gets called when a roku changes IP addresses. It is recommended to always use static IP addresses, or DHCP reservations for Roku devices (this is a router config) to ensure there is never a break in communications. With a dynamic IP address the integration will still work, but there could be up to a 5 minute period where the device is unreachable. This is because the SSDP discovery only runs every 5 minutes in my driver, when not actively trying to find and add a new device. The auto-detection of IP address changes can only occur when the SSDP discovery runs.
It is up to you if you want to leave the Roku w/o a permanent IP address, but I recommend learning how to setup a DHCP reservation to ensure the Roku is always on an unchanging address.

Thanks for reporting. These were important bugs to squash.


This is expected. The device are component devices that belong to the Roku Connect app. And the Channel, and button device are component devices that can only exist if the parent Roku device exists. So, if you delete a TV device, all child device are deleted. This is normal for Hubitat.

1 Like

Thanks for the detailed reply. I did figure out children components. I'll also add reservations for the three Rokus.

As far as writing rules for the Roku's I'm assuming it would be using custom attributes. I'm trying to do this with the app "Event Engine", and I can choose a Roku, an attribute (Using TransportStatus), but in Event Engine, it makes you set two custom attributes. I was expecting to only use one "paused" for example.
Does anyone use EE for rules, or should I just use Rule Machine? Not a fan of RM....

Edit: In RM, I can just choose paused from the list and it is working. Right now slowly when from a remote, I'll keep looking just getting started.


1 Like

This appears to be a limitation in Event Engine's Cogs. I installed the app to check it out, and what I see if you need to define the on or off states with value 1 and value 2. So I defined it as playing and paused. I think this is a limitation, since this is a tri-state attribute, and they only support two states.

1 Like

Thanks, great work on this. I'm floored that we have the ability to do Roku based automations. Much appreciated!

I recently installed the new Roku skill on my Alexa devices. If you are trying to use Roku with Alexa, the new skill provides a much better interface overall than is possible with the HE Amazon Echo Skill. The reason is that the Roku devices appear as switches to Alexa, so the controls are very limited. With the new Roku skill, you have to refer to you roku as "Roku", but you can associate each one to a specific echo device, so from each room you can say things like, "Alexa, watch Hulu on Roku" and it will turn on your Roku TV, and launch the Hulu app.

When coupled with my updated Roku TV drivers, you can check for current application, or play/pause state with more aggressive schedules (I have defaults built into the app for 2 seconds for media info, and 5 seconds for current application check. So integrations will still trigger while using lightweight API calls to keep the system load rather low in comparison to what was being implemented before.

The current roku code does require HE 2.2.6 to be installed. She the top post for details of what changed.

1 Like

I am just wondering if it is just me, but it looks like the Roku devices are a much larger part of my device activity as of late. My 3 Roku's are the top 3 devices in my Device stats, and by a huge margin.

When I say a huge margin i mean they are over 90% of the busy time for all of my devices.