One problem my company faced on occasion, while working with legacy programs from other vendors, was receiving Crestron programs or modules that were password protected to prevent viewing and modification. Programs could still be compiled without the password, and protected modules could be added to other programs, but that was all.
I spent some time considering the design Crestron may have used for this. If it were my system to develop and there were no backwards-compatibility concerns, I’d probably use some sort of public key/private key encryption, with the private key hidden inside of the compiler.
As it turns out, the “encryption”, or rather, obfuscation was far simpler than that. Without going into details, it turns out the password for protection was included in effectively clear-text inside the protected file, always at a certain position. I wrote a small tool to parse a source file, look at the position, and output the password. (After all, it’s far simpler to allow the vendor’s tools to handle decryption.)
This script was hosted on the internal server and is still among the company’s set of tools. It has saved considerable time and effort on a few occasions.
Technologies: Crestron; Linux, Apache, PHP
Vidyo was referred to my company by a Crestron representative when they were looking to build a custom control module for integrating with their VidyoRoom line of dedicated codecs. Vidyo was happy to learn that we also provide AMX programming support, and so we set out to build both the AMX and Crestron modules that Vidyo would offer as standard for their products.
As with most projects, the most challenging part of this project was communication. We initially failed to understand their needs and also failed to communicate the timeline we anticipated. Much of the project was spent recovering from this mishap and rebuilding trust with Vidyo, while trying to negotiate a reasonable delivery criteria we each could agree upon. Fortunately, we met this goal and continued to build our relationship with Vidyo.
In terms of technical challenges, Vidyo needed a fairly straightforward conversion of their on-screen interface into the example programs shipping with the modules. Their on-screen interface had access to a wealth of internal state data and queries that the API didn’t yet offer, so we coordinated on improving the API with Vidyo to make these tools available. In addition, their UI included some patterns that we hadn’t yet implemented in the AMX or Crestron spaces. One particular example:
- User enters a string on touchpanel
- The controller calls a Vidyo API to determine what types of results are returned when this string is searched for on their portal
- When the results are returned, a further API call is made to determine the state of the endpoint in some conditions
- Finally accumulating the information, the correct API command can be issued to initiate the video session.
While this type of interaction would be simple and near-instant with modern programming (for example, making an SQL query or firing a library call) particularly with blocking calls while this processing occurs, Crestron and AMX have no such benefit. Neither system offers a blocking call per se, all inputs and outputs are asynchronous. As such, there is a lot of complex state maintenance in that code to understand what the results actually mean when they are returned. The AMX module in particular adds quite a lot of context information back to the main program when this type of exchange occurs, taking that burden off of the programmer.
The AMX module on AMX.com and the Crestron module on Crestron’s Application Market are the modules I developed and published during my time with Advanced Control Systems. The documentation was also produced by myself and my coworker Steve.
Technologies: AMX; Crestron; RS232/Serial; TCP/IP
Intelix approached my company to create a suite of modules for an upcoming line of hardware that would ease integration of Intelix products with AMX and Crestron systems. I was assigned to this project mainly because I had the appropriate skills for both ecosystems and I was already familiar with making modules from our prior engagement with Vidyo.
This project presented two main problems:
- Their internal API documentation we had was revised during our work, prior to receiving the products with which to test.
- The wide variety of products, with varying APIs and capabilities, made presenting a consistent interface difficult.
The FLX-series hardware had a particularly tricky design to model within the Crestron module, as the hardware itself is reconfigurable, and the module needed to provide a static all-encompassing command set due to language restrictions. We solved this by providing several sub-modules that could be cherry picked depending on hardware as configured.
The modules offered by Intelix on their website today are the modules I developed and published during my time with Advanced Control Systems. The documentation was also produced by myself and my coworker Steve.
Technologies: AMX; Crestron; RS232/Serial; TCP/IP