Control4 Driver Migration

Background: Control4 is a proprietary home automation system, installed at the customer by 3rd party installers. Devices (TVs, lighting systems, HVAC...) need drivers in order to be supported by the system. Many drivers are provided by Control4, others come from 3rd party companies. Installers can program devices using a simple graphical programming interface, depending on what operations the device driver offers (e.g. if switch_1 is pressed, set lights_TV to 50%). Our company was one of these 3rd parties writing drivers (i.e. Lua code accessing Control4's interfaces called "proxies") for Control4. The problem: Control4 kept changing proxies or added new, better ones. Sometimes they even changed the way the "programming language" of the proxies worked. They didn't provide a migration tool, though. Every time we updated our drivers in order to make use of the new features, installers needed to delete the old drivers, install the new ones, configure and reprogram them. Imagine doing this for 100+ devices in a large house... Since it is a proprietary product, only the interface of the proxies is documented (badly), but nothing else, especially not how everything is stored internally.
1 answer

This one is the BEST answer!

I wrote a web tool in Java EE, performing the following subtasks:

  • Reverse engineer the project file (zip-File with an XML describing the project and folders containing the device drivers)
  • Reverse engineer the XML file representing the entire project (i.e. house)
  • Reverse engineer the XML structure representing programs the installers wrote for old and new proxy versions
  • Create models for old and new proxies
  • Create a mapping between these models
  • Provide an online tool where installers can upload a project which is then migrated to the new versions:
    • replace the old drivers with new ones
    • configure them accordingly
    • automatically re-implement programs using the new interfaces
    • clean up invalid parts of the project file
    • be as fault-tolerant as possible: migrate as many drivers/devices as possible; inform the installer about parts that failed to migrate
  • Iterative process: based on failed migrations, learn more about the internal workings of the project file and improve the migration tool accordingly