Connected by TCP: Closed System Pitfalls
Today we take a detailed look at the downside of closed systems in the world of Smart Homes. Specifically at the lighting platform Connected by TCP. Thankfully though this story ends with a happy ending. Be warned this is a long read.
But first, a brief look at smart lighting history
A little while back we discussed Local Control. In that article, we looked at the dangers of putting control of your smart home in someone else’s hands. But in the world of DIY smart home, large scale options for total local control are relatively new. In the early 2010s, they were few and far between.
Phillips Hue was introduced in late 2012 and offered a pseudo local system. The bulbs connected to a local hub with Zigbee but generally needed internet access for advanced control. It set the gold standard for how most companies would approach smart lighting for the foreseeable future. While entry prices have come down it was and still is one of the most expensive options.
A Competitor Enters the Ring
While many competitors entered the fray one of the most promising was a product line from established lighting company TCPi. They had actually introduced a product line of controllable CFL bulbs in late 2011/early 2012 under the banner N:Vision Wireless Lighting System. It was also a pseudo local system using the 6loWPAN specification. 6loWPAN is closely related to Zigbee but included IPv6 support. But it was not widely used and has been rolled into the Thread protocol.
But as CFL was already being replaced by LED they quickly scrambled to update to LED bulbs. This “new” system was just the old system with new bulbs. It was re-launched as the Connected Automated Home Lighting System or Connected by TCP. It used the exact same gateway and the bulbs from either system were compatible with each other’s hubs.
One of the many reasons the TCPi product was attractive is that at the time of introduction it was nearly half the cost of Hue. At the time a 3 bulb Hue kit cost $200 while the same kit from TCP was $109 at Home Depot. Additionally, at the time Hue was an Apple store exclusive product.
The future was looking bright for the platform, Wink and SmartThings integrations were available. At Lightfair 2014 they had announced a major expansion to the product line. This included a new Wi-Fi hub, smart plugs, power strips, motion sensors and more bulb form factors. Unfortunately, most of the products never came to be and only the new hub and a few bulbs made it to market.
Dis-Connected by TCP
TCPi contacted registered customers in May 2016 announcing the shutdown of their cloud services as of June 1. This had the effect of removing all remote integrations and control. Leaving customers like myself with only the phone app to control lights within the home. For many, this meant we were de-commissioning equipment we had planned to use for many more years.
Enter a White Knight
Thankfully there are some very smart people in the world. In this instance, it’s a guy going by the moniker Bren1818. By mid-July 2016 he had launched a project called TCPLightingWebInterface. The goal was to recreate the local web interface that had previously existed on the Connect by TCP hub. He was achieving this by reverse-engineering the Android application. By November 2016 this functionality had been achieved and the project came to a standstill.
But in the background, we were having discussions about expanding the code further. November 2017 rolls around and a major update with an API is released. Tweaking and bug fixes and extensive documentation continued to early January 2018. Now considered functionally complete by Bren1818 the project also included an IFTTT webhook request generator, now suddenly you could control your lights with Alexa or Google Assistant.
But What About Local Control?
As I’ve talked about before I want local control when at all possible. While technically this was available by querying the API and sending it local POST commands. This didn’t integrate well into any home control system I was investigating. It was also very resource-intensive polling the API status.
So starting in May 2018 I set about MQTT enabling the project. Enter the fork TCPLightingWebInterface-MQTT. By September 2018 I had achieved a fully functioning MQTT implementation. The structure was implemented based on Home Assistant’s defaults for MQTT Lights. Devices had to be manually entered in configuration.yaml. At this point, I considered the project code complete as full local control had been achieved. Lights could be controlled by Home Assistant, Node-Red or any other MQTT client.
But as anyone who’s worked on a project like this knows. There’s always one more feature or tweak that could be done. I wanted to expand my installation of bulbs from 10 to 20 as well as do some renaming and location adjustment of existing bulbs. Manual configuration in Home Assistant made this very cumbersome. So a year to the day of the last code update, MQTT Autodiscovery implementation began. While most function has been in place since September 11, 2019, with V0.7.5 Alpha release. I am happy to say that V1.0.0 has been released with support for Home Assistant birth messaging as the trigger for updates rather than the more cumbersome custom script and automation that was needed in the Alpha.
So what’s the point?
First and foremost this once again demonstrates the pitfalls of closed systems. Without the hard work of bren1818, the rest of us would have been forced to dispose of our lighting systems and start from scratch. Once that ball is rolling anything can be achieved with hard work. Home Automation is still very much a hobbyist’s domain if not well thought out and executed.
Secondly, if you have some Connected by TCP lights sitting in a drawer gathering dust because you thought they could never be integrated. You may be happy to know that they can once again.
So if you are at all interested in getting Re-Connected by TCP check out the project TCPLightingWebInterface-MQTT. Detailed installation and configuration instructions as available in the wiki.
