Roku Support

Indeed. However, I wouldn’t use that as the sole reason why a binding shouldn’t be built. There are a few good reasons why a Roku binding, particularly a 2.x version binding would be a good fit with OH. These include

  • automatically discover and keep up with the IP address of the Roku, see Roku Integration · openhab/openhab1-addons Wiki · GitHub for some scripts to show how to do this

  • automatically set up relevant Things and Channels

  • hides the XSLT/XPATH stuff which might be daunting to non-programmer type users

I really like the example and, as the original author of the wiki article linked to above, I’m very appreciative. I do have some recommendations which could make the rules a bit easier to manage (I’m guessing at least a 50% reduction in the number of lines).

I do have some suggestions that might work to make the above a little more flexible. Note that some of these suggestions may be incompatible with each other.

  • Use the script I linked to linked to an Exec binding Item or executeCommandLine to get the IP addresses of the Rokus and save them to the appropriate Items. If you configure your DHCP or the Roku to use a static IP feel free to skip this step.

  • Use Design Pattern: Associated Items to locate and populate the correct Item to populate with the information pulled from the XSLT

  • Use XPATH instead of the XSLT transform. That will eliminate the need to maintain a separate xslt file for every piece of data and is much easier to deal with. The line for deviceid would be replaced with
    ROKU<SERIALNUM>_deviceid.postUpdate(transform("XPATH","//device-id",deviceinfo))
    I only recommend XSLT when you need to do some more transformation of the data beyond simply extracting the value of an element or attribute

  • Use the HTTP cache configuration in place of the cron triggered rule. This could also replace the System started rule so long as you are using restoreOnStartup for those Items

  • I’m a big fan of DRY. Consider using a lambda for the DEVINFO case and call that lambda from your System started Rule and your DEVINFO case in the navigation Rule.

  • A Thread::sleep(1000) is probably getting close to too long. Consider using a Timer

  • To minimize the amount of find and replace one has to do and another application of DRY, consider making only one call to sendHttpPostRequest in your rules and use the switch statements to build the URL.

    val url = "http://" + ROKU<SERIALNUM>_ip.state + ":8060/keypress/"
    var key = ""
    switch(receivedCommand){
        case "BACK": key = "back"
        ...
    }
    if(key == ""){
        switch(receivedCommand){
            case "DEVINFO": {
                ...
            }
           ...
    }
    else {
        sendHttpPostRequest(url + key)
    }
   ...
  • In addition, your keyboard rule could be reduced to the following two lines
    sendHttpPostRequest("http://"+ROKU<SERIALNUM>_ip.state + ":8060/keypress/Lit_" + receivedCommand)
    ROKU<SERIALNUM>_keyboard.postUpdate("EMPTY")

The Same approach could be used to drastically reduce the length of the navigation rule using something like:

    val url = "http://" + ROKU<SERIALNUM>_ip.state + ":8060/keypress/"
    var key = ""

    switch(receivedCommand){
        case "DEVINFO": {
            ...
        }
        case "APPINFO": {
            ...
        }
        case "DTVNOW": key = "140474"
        ... // all other apps
        default: key = receivedCommand.toString.toLower
    }
   ...
  • For those who have more than one Roku, use lambdas for the Rules, do not copy paste the rules. DRY.

  • To get to more of an OH 2.x type experience, one could write these rules to use the OH REST API to automatically generate the Items for you. Unfortunately, this will not help much with the Sitemap, but it would make the .items easier to deal with and potentially the Rules as well. Though ultimately I do think a new binding would be the better way to go, and I’m usually the one arguing against new bindings.

Don’t get me wrong, what you posted is great work! Thanks for the contributions to the community.