ISE Crestron Home Tip of the Day #1 - Apple TV App Launching

Adding app launching was a huge step forward for our Apple TV IP driver, but you still needed to switch away from the source, open the app launcher tile and then switch back.

With this top tip, those days are over.

You'll need our Apple TV IP driver before you start: Click here for Apple TV

With a few simple steps you can now configure a room display to present commands.  This is normally used for selection of aspect ratios and so on, but you can also add Quick Actions to this list - and they can do ANYTHING.  So while this top tip is about Apple TV app launching, you could trigger a movie lighting scene with our Philips Hue or DMX controller or open the main gate with our Wildcard drivers, all without leaving the source page.

Step 1: Create some Quick Actions

Step 2: In the Display Settings, go to Commands and Enable the Quick Actions

Step 3: Select the Apple TV Source and - hey presto - you have App Launching under the display menu!  You can even re-order them so your favourite is at the top.

Follow us on Facebook, Twitter, Instagram and LinkedIn (@ultamation) for tip #2 and #3 during ISE 2022!  

The Ultamation Help Centre

We're very proud of the reputation Ultamation has for exemplary customer support.  As they say, talk is cheap, and it's not the fact that you say you provide first-rate support, it's whether customers get a quick response to their queries and how far you go to resolve the problem.  We work very hard, often responding to customers out-of-hours and walking them through configurations or diagnostics - usually without charge.

While we firmly hold that the human element to customer support is crucially important, it's important to make information as accessible as possible as this means that potential issues can be avoided without engaging with support at all at times and we can provide thorough responses to common problems without rewriting the same information out for the 10th time, simply by linking relevant, already documented, information.

To that end, we have introduced the Ultamation Help Centre which is a repository of documents that we will continuously update with useful info.  The information isn't public, and you will need to register on the portal to access the documents, but this is a property of the platform we're using and we do not use any personal information gleaned from creating an account.  Sadly, this account is not linked to existing Ultamation shop accounts.

We've also moved over to a new ticketing system for support tickets (generated by emailing This email address is being protected from spambots. You need JavaScript enabled to view it.) and the new system gives registered users a way to keep track of their cases.  If you email This email address is being protected from spambots. You need JavaScript enabled to view it., you will automatically have an account created by the platform to that you can track your case.

To access the Ultamation Help Centre, please follow the link below.

Ultamation Help Centre

As an incentive, we've already started writing up the new Apple TV control FAQ so if you're quick off the mark, you can get access to otherwise unreleased information about the new CompanionLink drivers for Crestron and Crestron Home.

We're also publishing recipes for the Crestron Home wildcard drivers which provide simple "hacks" for giving your clients capabilities that can't by offered by your competition.

Wildcard Recipe: Sending Commands to Display Endpoints

Problem

Your Crestron Home project is using a 3rd party AV switcher but you haven’t been able to use the full capability of sending commands to the displays to turn them on and off.

Solution

The Ultamation Wildcard modules can be used to send these commands to the AV switcher by integrating the commands into hidden quick actions which are triggered when a media zone is powered on or off.

1. Add the appropriate Ultamation Wildcard driver to Crestron Home - this will depend on the capabilities and communications model of your chosen AV switcher.

2. Configure your chosen commands for buttons or discrete commands (under Actions/Sequences) using the information in the table, and examples below. If you work out more commands, please let us know and we’ll add them to the table!

3. You’re in the 1-hour trial period window - give your new integration a test drive!

4. Once you’re happy everything is working, purchase a licence key for your processor for one of the wildcard drivers here… Home

5. Add the licence key to your Crestron Home configuration (under “Installer Settings”)

Command Table

Examples:

The following examples show you how format the the commands in the Installer Settings of the module.

The first element - “Label” - can be whatever you want to have displayed on the button. The other elements must be formatted exactly as shown.

Binary MoIP, using the TCP Wildcard, turn on TV on output 3

Playroom TV On|!CEC3,1\x0A

Binary MoIP, using the TCP Wildcard, turn off TV on output 3

Playroom TV Off|!CEC3,0\x0A

HDANYWHERE, using the HTTP POST Wildcard, turn off TV on output HDBT 'a'

Lounge TV Off|api/command/cecpass/a/1/|{"logicaladdress":"EF","command":"36","arguments":""}

Manufacturers vary greatly in their support for, and implementation of, CEC commands.

Kudos to Isaac Rosario of Voyager Home Systems Voyager Home Systems | Oklahoma City Metro Smart Home Installations for suggesting this really innovative integration solution and providing Binary MoIP data.

Updating Drivers In Crestron Home

Introduction

Crestron Home (Home from hereon) continues to be a great success, bringing a rich Crestron automation experience to homes that may have previously had to compromise for a more “consumer” automation solution.

However, we are still in the relatively early days for the product and many of the current installations are starting to reach the point where updates are desirable or required. The Home operating system is capable of automatic updates but the myriad device drivers, which provide the glue between Home and the 3^rd party components around the house, cannot currently be updated automatically. For the sake of clarity, we are discussing updates of the same driver to a new version – as opposed to changing one driver for an entirely different device or model.

In some circumstances this is an inconvenience. In others it can lead to unnecessary support calls. At worst, the driver update process can leave a Home system in a very sorry state requiring roll back to a known working state or – at its most extreme – a fresh install.

This document will first outline the process for safely updating a driver in Home, and then, for the more technically minded, explain why this is necessary.

The Safe Process

Before we start, there is no pretence here – this isn’t a convenient or streamlined process. For various reasons (outlined later) Home cannot, at the present time, simply replace a driver without some user intervention.

So, the first question to ask is, do I need to update the driver at all? Our advice here would be to get confirmation that a driver fixes some known issue or provides required functionality before updating. Simply updating because there is a new, higher, version number may not be necessary. However, if you do need to update your driver, these are the steps that Ultamation recommend:

Step 1: Save your config
I mean, what could go wrong?
You really want to do this before any driver changes – it’s quick and easy.

Step 2: Remove the original driver COMPLETELY.
Using the Home setup app, track down every, last instance of the driver you have configured on the system. For something like a projector driver this may be as simple as a single instance. For something like a lighting driver, you may have tens of instances. They ALL have to go. The downside here is that all routing, sequencing and programming will also be lost.

Step 3: Restart the Home system using the setup app.
You need to restart Home before you can safely pull in a new driver. There is a technical reason for this (see below) but, in a nutshell, this allows Home to tidy up references and ensure the system integrity in maintained.

WARNING: DO NOT reboot the processor by pulling the plug, or typing “Reboot” at the console, as this will restart the processor without any of the vital housekeeping. This is probably one of the best ways to ruin your Home configuration and can lead to all manner of oddness, such as a driver being loaded despite not being visible in the setup app.

Step 4: Confirm that the old driver is really gone!
This is just a verification that the previous steps were successful, but if you don’t do this you run the risk of thinking that you’re running the latest driver, when Home is actually still running the original. (see below for the technical “why”)
Unfortunately, there’s no “easy” way to do this and it involves looking at the Home processor’s file system to check that the driver isn’t shown under “user\data\UsedThirdPartyDrivers” as shown below:

Step 5: Load the new driver
Either grab the driver from the Crestron driver portal (which will appear in the Home setup app) or sideload the updated driver (covered elsewhere).

Step 6: Reconfigure the driver.
You will now need to recreate all routes and programming ties that were lost during driver removal.

You should now have the updated driver running correctly in Home.

There is clearly a lot of scope for addressing the current challenges of driver updates in Crestron Home and Ultamation have written this guide in response to the increasing number of questions we receive about updating drivers. As Home continues to grow and older systems receive maintenance updates then we expect Home will be enhanced to streamline the driver update process and, hopefully, make this guide redundant.

Why All The Pain? - The Technical Reasons

Why isn’t this automatic?
We’re going to brush aside the “but xyz have been doing it for years!” because it’s silly to compare apples and oranges. XYZ probably has a completely different driver architecture to Home so the rules/constraints are naturally very different. But specifically for Home, there are times where a driver could be updated, at least semi-, autonomously. The trouble is, there are numerous ways in which a driver update could break a configuration which would require manual intervention. The list includes:

• Deprecated features
  What does Home do with that command that just disappeared!?
• Changes to I/O config
  TV/CBL was just renamed to MEDIA – are they the same? Different?
• Programmable Operations/Events have been changed
  What does Home do with the actions that were programmed into sequences?

Now – those are some arguments as to why automatic updates are dangerous. But that doesn’t mean the situation couldn’t be better. Home should be able to flag that a driver update is available and perform some consistency checks to see if an update would create any configuration anomalies. If there are no issues detected, then a semi-automatic update process should be possible which would remove most of the inconvenience and fragility issues.

So many drivers for different models – They all seem the same!
That’s because they probably are. This is sadly a numbers game. If you have a driver database and you want to shout about how many drivers you have, the figure you quote is really the number of supported devices you cover, not the actual number of variations of code you have. If every Sony TV uses a protocol that is 98% consistent across all (for arguments sake, 500) models, that’s probably 1 driver, but we advertise it as 500 models – why? – because it means an integrator can verify that a specific model is supported, but also because is makes the driver database appear bigger. It’s not helpful when you’re searching for an elusive feature that doesn’t seem to work correctly on the driver you’re testing, but that’s the way it is. Hopefully there will be something in the future to allow us to see which drivers share a common base so integrators can test once; and move on.

Why do we have to remove the old drivers?
This one is a bit technical and we need to make a distinction between the driver information (the entry in the Home driver list) and the driver code (the running code once a driver has been “loaded” into the memory of the Home processor). This problem lies deep within the operating system (below Home itself). Once the code is loaded into memory, it is there for good. The underlying OS cannot (without architectural changes that Crestron have already considered and dismissed) load updated driver code “over” the original. If you leave a single instance of a driver around then, as soon as Home reboots, it will reload the original driver and you’re back to where you were. They ALL have to go.

Why do we need to reboot Home before loading the new driver?
Read the reason above. The only way to clear the Home processor’s memory of the old driver is to restart the Home process (i.e. a reboot, or program reset).
Additionally, you cannot always rely on drivers being cleanly removed when they are taken out of the setup app config (especially Platform drivers!). This isn’t only true for driver updates, but also when modifying driver properties through user attributes. If in doubt, after you’ve made changes to the Crestron Home configuration, check with a clean restart!

I think I’ve messed up the Home config. What are my options?
The safest bet is just to restore the config you made in step 1. On rare occasions Home may not even boot to the point where you can restore a cloud config though, more often than not, Home will revert to a factory state if it detects serious problems. If you really find yourselves at the edge of the world, call Ultamation and we can try to assist.

But Home says it’s updated and I didn’t do all of this nonsense.
It’s easy to think Home has updated your driver when it hasn’t. For the reasons already discussed, this is what can happen:

Because Home cannot replace code at runtime (i.e. without a restart) the old code is still running even though Home has processed and imported the new driver’s information. In the future, we hope that Home will flag this discrepancy and inform the integrator that the driver update is not complete until the system has been restarted.

Controlling Devices - The Good, The Bad and The Ugly

As you can see, we write a lot of device drivers.  To do this, we have to get intimately acquainted with the protocols that a device's manufacturer has implemented to provide control of their device.  In an ideal world, these protocols would be well designed, fit for purpose and fully documented.  We're not living in an ideal world, and depending on where you look you may well come to the conclusion that things are far from ideal - in fact, there are some truly horrible protocols and implementations out there.  This article describes some of the challenges we face when implementing a protocol handler for a driver.  It's also an offer to any manufacturer that perhaps doesn't have the expertise in house to define a well-designed control protocol; Ultamation can help.

What is a control protocol anyway?

In this context, We're talking about the language that a control system, such as a Crestron processor, speaks to communicate with another device; say, an amplifier or an intruder alarm panel.

Protocols come in all shapes and sizes (more on that later) and their job is to convey commands and feedback between two devices.  the design goals should encompass:

• Be unambiguous - the protocol has to be clear and unambiguous.  You tell the device what you want, and it should understand you without any trouble.  Likewise, when the device responds, or generates unsolicited feedback, you should be able to infer what the data relates to without prior knowledge.  It's surprising how many protocols make this simple mistake.
• Be efficient - if you want a device to perform well, you need to consider efficiency or message generation and parsing.  This is an important consideration for implementing a protocol handler as you many not be able to control how rapidly messages are thrown at you, and both ends of the conversation should handle being overwhelmed gracefully.
• Consider the lowest common denominator - some developers have their favourite language and libraries.  If you work with web technologies, the path of least resistance might be an HTTPS based protocol with OAuth.  Easy for you, hard for someone trying to implement a client on a microcontroller in a language that doesn't have native support for secure sockets, or a convenient way to gather an authentication token from the account holder.  It's worth bearing in mind that your device may be controlled by very simple device. 

Transports

It's worth mentioning that protocols and transports are very different.  A transport could be considered to be the road that the protocol messages we send travel along.  The optimal case is that a protocol doesn't care how its messages go from A to B.  There are many great examples of manufacturers who implement a protocol that is identical whether it uses a serial (e.g. RS232, RS485, RS422) transport or uses an IP (e.g. TCP, UDP) transport.  There are equally as many examples where manufacturers introduce transport specific elements into their protocols.  Give yourselves a D-

Where multiple transports are supported, not only should it be unnecessary to confuse the transport and protocol, it allows a developer to maintain a common code base, and this improves software quality and efficiency.

The general approach that a manufacturer choses for their control protocol's transport can have a big impact on how the control implementation performs.  As I mentioned above, the choice of technology can make implementation simple or complex, but some technologies are just inherently poor choices for certain types of control.

As an example HTTP/RESTful APIs are very common.  This is likely because they are so accessible, have ubiquitous support in web applications which will likely be implemented within the device already and are generally easy to understand.  However, they are stateless and generally pretty slow.  Each request must be received, handled by the HTTP server, and passed off to the handler.  This may be fine if all you want to do is switch a device on or off, or change an input, but when it comes to tracking a volume slider in real time, they just don't cut it.

When I'm designing and implementing a control protocol I would always favour better performance at the cost of implementation effort.

If I change the input from the front panel, how do we communicate this back to the controller?  With HTTP your only solution is to poll - which is a poor solution for all sorts of reasons or use hacks like HTTP long polling - did I mention that is a hack to get around the deficiency in the HTTP request/response model?

Web Sockets might provide "best of both worlds" solution, but if you don't already have Web Socket client support, you have a lot of work to achieve a result that perhaps might been better served with a simple TCP socket.  IT requires a deeper understanding of TCP and sockets, but - to be fair - you are implementing a machine-machine interface, so that's probably worth getting a grasp of anyway.

The Protocol

There are so many ways to design a protocol, and the correct approach is really down to application.  That could mean designing a message structure that is human readable (i.e. ASCII) so that you can communicate with the device via a terminal emulator, or you might want more efficiency with a pure binary payload.  Either way, messages must be expressed in such a way that a client can easily identify where they start and stop.  Error detection may also be a requirement, though remember that TCP handles this for you, so anything else you add is pointless if you ONLY support TCP.  If you may also use serial or UDP transports, this is where some error handling will be needed. 

JSON is another popular payload.  It's human readable, it's pretty concise, fairly easy to parse and there are lots of tools to help you validate syntax etc.  It's also very easy to create some pretty freakish structures that can make deserialisation into objects an absolute nightmare.  Just because it validates, it doesn't mean it's well designed, and it's well worth adding in some additional specificity into the structure to make it unambiguous (and deserialisable!) at the expense of some extra characters - if you're really on an efficiency drive, then you're barking up the wrong tree with JSON in the first place.

Google's Protobuf is an example of a very efficient, flexible and robust message payload - the trade off is it's complicated to implement message reader/writers.

At the other end of the scale there are formats such as SOAP.  Fine if you're writing web discoverable business services.  Not really suitable for M2M communications.

Documentation

Once we have a protocol designed, implemented and tested, it's ready to be released into the world.  But not until it has been documented.

I would suggest that at the VERY least, a public protocol specification should cover the following:

• Transport details - Serial comspec (9600-8N1, hardware pinout etc.) or TCP port for communication
• The general packet structure for the payload along with any additional notes that apply to transport specifics (authentication, handshaking, heartbeats etc.)
• Complete payload documentation describing all commands, values and valid ranges - this gets forgotten so often
  • If I'm setting volume, how am I to know if the protocol expects 0-100, -90-0, 1.0-50.0?
• An example for each command, including the possible expected, and error, responses

 The reality is we may get a spreadsheet with an incomplete table of messages that do specific things, but don't explain the structure, how checksums are calculated, the allowed values (which may need to be given for specific models) and no mention of valid responses or even whether one should be expected!  Yes, it can be used to reverse engineer a protocol, but this shouldn't be part of the driver development process.

It goes without saying that documentation should also be accurate.  I recently had to request the serial comspec for a device as it wasn't mentioned in the documentation.  After waiting too long, I broke out the logic analyser, measured the time between a pulse at 8.6us and established that we were using 115200 baud.  Then I received an email from the manufacturer telling me to use 192000 baud.  Wrong on so many levels ;)

If you need help pulling your device protocols into shape so that your device is easy to integrate, performs well and is reliable, we'd be pleased to offer our help based on many years of experience.