A note about security
Although security was not at the forefront, as it is today, when I started designing the QualColor RF protocol in 2007 I made some small effort. I had read a comment online that said unless you were an expert in cryptography and computer security then you shouldn't try to implement something so I decided that my effort would be to secure a system from casual hackers (e.g. be able to prevent someone with one of my remote controls from controlling a system that had been secured) but not from experienced hackers (who, today, would be able to sniff the system using a SDR). The wireless variant of the protocol includes both a 8-bit Network code that modifies the Nordic Radio addresses and a 32-bit key that must match for packets to be validated. These are communicated between a control device and the device being configured by a special SetAddrRf packet that should only be transmitted during a provisioning step when the system is installed. Of course this packet could also be snooped by a sophisticated hacker. The RF modules initially had a provision to reduce the output power of the radio to a minimum value with the idea to make it harder to "listen in" to the provisioning activity but I never implemented control software to take advantage of this feature. Initially configuration and parameter values in any device could be changed by packets addressed to the device but I eventually changed the system to require that the link button be pressed before any changes could be made to a device to at least require a physical interaction with the device. This makes it difficult, however, for someone to modify a device's configuration when it is installed in a physically inaccessible location or to change devices remotely.
The wired protocol has no specific security capability other than the need to press the "link" button to make any changes to a device. I debated adding a key but ultimately decided that if someone gained physical access to a network then they would have the capability to snoop the key.
Some of the implementations of my system that interface with TCP/IP networks include more sophisticated security up to the Electric Imp controller that used HTTPS. The home control program requires any user accessing its web interface from an IP address outside the local address (e.g. 10.X.X.X) enter a user id and password. The control program at Solid State Depot requires this for web access (which means users from the local network just immediately get a virtual control panel but we can also control the lights remotely. However it also exposes a simplified packet interface for hacking with absolutely no security on the local network (depending on our firewall to prevent remote access).
One of the things I think about in releasing my system as either hardware modules or as open source is the level of security. I think that re-implementing the architecture on more modern micro-controllers and with higher-performance radios than the Nordic devices might allow for a much higher level of security. But perhaps, considering the advice I read so long ago, that ultimately isn't that important as long as the external interfaces are protected.
My current plans for my own system include the following
- Finish the environmental sensor and replace the stand-alone temperature sensors (move them to the makerspace)
- Modify the control software to include predictive control of both the HVAC and lighting system based on sensor data
- Add a scene control module that includes both preset scenes and randomly generated lighting effects as well as the ability to trigger scenes based on environmental control (for example lighting based on the external light levels)
- Write an authoring program to create the configuration files including system topology, predictive control rules and scene descriptions
- Include some additional sensor data including power monitoring and video feeds into the control program
- Include the ability to record environmental/video/security data for review and activity for use in simulated occupancy
- Deisgn and build a proper Triac-based dimmer (both firmware for the existing controllers and a power board with the Triac - or a relay for simple on/off control) that fits some existing plug-in boxes..
- Redesign the thermostat and controller boards to be more general. For example the thermostats to work with more types of HVAC systems and the controller boards to be more general to work with devices like watering systems and other relay controlled devices.
Ultimately I have to decide what to do, if anything, with this technology. I have invested a lot of effort and can certainly use this for my own projects in the future but I am not sure if this is something that other people might find interesting. If it is I am not sure what is the best way to deliver it. From a somewhat selfish perspective it seems difficult to see the benefit of releasing it as open source hardware (other than the value of sharing it with others). On the other hand it is a lot to try to productize (when one thinks about things like FCC/CE testing, and manufacturing a whole set of boards) and there are certainly no end to the number of other lighting and automation systems that exist. I have thought of simply providing pre-programmed micro-controller and RF-modules for people to incorporate; software for them to use and protocol specifications if they want to roll their own software but that leaves them with a lot of work to do. Part of the reason I created this hackaday.io project was to see if anyone else was interested and if they had ideas of the best way to make good use of this stuff. Perhaps someone who reads this will have some good ideas. Or perhaps it will just be a look into one guy's home automation system.