Distributed Computing or Lighting Control?

With his provocative post, Karl S. Jónsson of Tridonic sparked a good discussion on the future role of a lighting grid in office buildings. Setting Bitcoins aside, The whole idea of fitting a ceiling with high performance (and high power / heat dissipating) computer nodes "just because" where are lights, there is power, does not have legs (as explained in the comment by Nicolai Eggert). Ideas of hijacking a lighting grid to power highly dense computing network come fairly often, but I really doubt anyone would be doing that.

Lets face it: the power at lighting sockets is not any cheaper than the power at a regular socket. Somebody has to pay the bill in the end. Dissipating heat at a ceiling is not what we want either. Heat goes up, so the hot nodes there will not be able to heat the rooms. There is already too much heat in the plenum space and nobody wants to increase the already high fire hazard there.

But the fundamental observation that there is computing capacity at smart lighting nodes is correct. The good news is we can put it to work without generating heat and consuming more energy. Actually we can put it to work to reduce energy bills, costs and increase the robustness of the lighting control system.

The classical approach to lighting control involves sensors, reporting to a controller and light fixtures responding to the controller. The controller is usually a "box" or a "panel" and (depending on the size of the lighting grid) may occupy a decent size room. There is a network (wired or wireless) configured to deliver sensory information to the controller and to deliver control commands to the light fixtures. Messages keep going back and forth on that network, often over multiple "hops" (in case of a mesh or a hybrid network).

The controller is a computer running lighting control software. The software takes input signals from sensors and switches, adds local "logic" (time-based schedules, setpoints, scenarios) and computes output signals that usually tell each light what lumen output it should be generating.

Now, it is not unconceivable to run (a copy of) this lighting control software on each microcontroller (MCU) in a fixture driver. These MCUs are capable enough to be doing that (while not increasing their power draw) - lighting control is orders of magnitude "lighter" than mining crypto currencies.

This is how Bluetooth mesh works when configured for lighting control. Each mesh node runs its own copy of the control algorithm. The central controller is no longer needed. The system architecture is radically simplified. The single point of failure is gone. And the network load is much lower, as the sensors publish messages directly to the lights and the lights subscribe to them and act upon receiving them. Pure peer-to-peer, fully decentralized computing architecture. Reduced cost (less hardware), reduced energy bill (the hardware that is now gone does not draw power), maximum redundancy (if any node fails, the others keep working without any disruption and can even compensate the lumen output for the lost node, if needed), increased network capacity (less traffic) and simplified setup.

This is disruptive. The distributed computing grid put to work addressing a number of very low hanging smart lighting fruits, without trying to reach for such elusive gains as crypto mining. Significant cost reductions, contributing to much higher ROI and shorter paybacks. We are happy to launch the first lineup of partners who deliver interoperable lighting components enabling this next generation system. Come visit us at L+B on March 18-23 (E80 in hall 9.1) to experience this live.