Lighting control (Organic Response)

Description: This case study describes the development of an IOT based lighting control solution developed by Melbourne-based company Organic Response. It describes early models of their distributed intelligence technology and the drivers behind developing it into a full IOT solution, which have been demonstrated in a major pilot.

Source: The material for the case study comes from a webinar presented to Engineers Australia’s Applied IOT Engineering Community on 20 Sept 2016.

Presenter: Dean Campbell-Smith, Technical Director, Organic Response. After studying at ANU in Canberra, Dean began his career in 2000 developing embedded electronics devices - often with a wireless focus. While he has worked for several large organisations, his passion is in the highly innovative start-up space.

Introduction:

Organic Response was founded by Danny Bishop and Chris Duffield in 2011, both Australian National University alumni. The company is headquartered in Melbourne with our engineering operations here, but we have also had staff Europe and North America. The technology team is made up of a mix of hardware and software engineers.

Organic Response really grew from Danny working in the field of energy consulting. He was working with commercial building clients to help them reduce their energy consumption. Buildings, in general, use 60% of the world's generated electricity, and lighting alone consumes 19% of the global energy production.

In specifying lighting control solutions to try and minimize energy consumptions, he found that traditional lighting control solutions were expensive to install, complex to set up, and difficult to maintain. Lighting control solutions can vary a great deal from your typical wall switch, which is very simple but often ineffective in terms of reducing energy consumption, right through to a complex network lighting control solution that involves sensors deployed within the field that are wired back to a centralized controller which then applies a control solution to a number of luminaires within the space.

Danny found himself specifying complex lighting control solutions which required technically skilled staff to operate and maintain. An unintended consequence is that the end customer, being a tenant, is often unsure of how the system operates and unable to make adjustments to the system.

Danny saw a large opportunity to provide a more elegant lighting control solution by decentralizing the control. Traditional lighting control systems use luminaires that are essentially dumb devices that can simply accept commands, typically from a centralized control or a room-based sensor. This results in an installation which is costly to install, costly to commission, and normally a less than optimal solution for lighting control.

In this decentralized approach, Danny envisaged a small amount of intelligence and sensing ability in each luminaire that would enable those luminaires to operate autonomously, each making their own decisions about the amount of light that is required in their space.  Additionally, if these luminaires were provided with the means to communicate with their neighbours, then a more optimal solution could be attained.

Prototyping

Organic Response had this theory, so all that was left to do was actually to try and implement that. They went ahead and built some hardware and software (pictured).

An early prototype.

The current model showing its main functions.

The infrared communication between luminaires was something that was developed in-house. Essentially, the system creates a flooding network for the sensors so that each sensor, when it senses occupancy, it broadcasts an infrared message saying, "I've seen occupancy."

Its neighbours see that message and rebroadcast that message onto their neighbours in turn, each time incrementing a notion of level within the messages so that at any one time, any sensor on a floor will have a concept of how far away it is from the nearest occupant. That's the basis on which the lighting control solution. is built up.

In addition to the control messages, the system also has the ability to send out configuration messages through the mesh, by using a flooding mechanism whereby each message is rebroadcast until it's propagated throughout the installation.

The core product Organic Response has developed and delivered so far is the wireless lighting control sensor. We've deployed roughly 60,000 of these through Australia and North America and Europe. In the process, we've had to make a bunch of other stuff to support this product, predominantly a control unit which powers the sensor node, an interface to the luminaire drivers, and mains power control. We built wall switches, wired link modules, IP gateways, and remote mounting nodes.

Testing

When Organic Response first deployed the sensors into an environment that was large enough to test, it was very difficult to say what was actually happening, so the company created a jig that was able to wire to each of the sensor nodes so that they could in real time watch the state of each of the lights and how they responded to the algorithms. This obviously wasn't a sustainable way of testing, and so since then, they developed a virtual environment, which enables them to put virtual sensor nodes into an environment. The system now has the ability to lay that in the floor plans and have different physical attributes to the environment. That enables Organic Response to actually test the real firmware that's running on the device in a virtual environment and see how feature upgrades or what fixes apply, and how they affect the system.

An early version of the virtual test environment with smart phone app.

User Interface

The client can interact with the system is through a smartphone application, which can set something we call a personality. This essentially determines how the luminaires react to the level messages they see.  For example, it is possible to set a more aggressive personality and the lights then become more tightly defined around the occupant so that the client can achieve a higher energy efficiency. This is achieved through the configuration messages that are sent throughout the mesh.

Future requirements

Beyond these initial products, there are some emerging requirements that have started to really focus us on getting the nodes connected more broadly. The key driver here the need to use a building's space as efficiently as possible. One of Organic Responses' clients recently calculated it costs them $10,000 per year to provide a worker with a desk in the Melbourne CBD. This has led to the rise of hot-desking to use the environment more efficiently.

Organic Response’s lighting control solution has suited this type of work arrangement but what the company found was that the information being generated in terms of the lighting control solution could actually then be fed back to the customer, telling them how their space is being used. That was the key requirement that came about.

There were also some sub-requirements around live power monitoring. This speaks to situations where you'd like to apply specific control of the lights at a specific time, such as evenings in a hospital space where you don't want the lights automatically coming on in a patient's room. Another requirement was around system integration with AV systems, VMS, heating and cooling within a building.

There was also the need to provide some indication of maintenance issues, not just telling people when there may be a problem with the lights, but also trying to provide some kind of indication as to when maintenance may be required based on the previous history.

Organic Response also wanted the ability to firmware upgrade without physically touching the device. You can imagine the difficulty in upgrading the firmware in sensor nodes that have been deployed across the world into the built environment. It's a key roadmap feature for the company to be able to upgrade firmware over the year. 

Networking options

Organic Response certainly toyed with the idea of expanding its IR communications to facilitate these requirements, but they quickly ran into bandwidth and range limitations of the IR network and it was really being pushed past the limit of what we designed it initially to do.

RF was the logical replacement and the built environment, especially the way that luminaires are laid out within a building, lends itself to a meshing topology, and that's naturally where we went. So we considered three technologies.

ZigBee was an obvious option, in terms of it had a proven mesh networking capability, but on the downside, it had no native handset connectivity, which was key for us. It also had a non-ideal reputation in the lighting industry for being difficult to configure and having some latency issues in wireless installations with centralized control.

We also looked at Thread, which is based on 6LoWPAN, but it had the same issue with the lack of handset connectivity and immaturity of the technology at the time. So it really didn't provide a path to a sure solution.

Bluetooth was very attractive and felt like the right choice at the time. It had natural handset connectivity, high over-the-air data rates, and small packet sizes which is appealing to us.  At the same time, it was immature and the Bluetooth low-energy mesh standard had not been released.

That left us in a little bit of limbo, but we met a company that was heavily involved in developing the Bluetooth low-energy mesh standard. In fact they had a proprietary Bluetooth LE mesh ready to use. This really tipped us over the line and we chose Bluetooth as the mesh technology that we will use for our communications. We really leveraged this company's experience and expertise in terms of the wireless stack and for the RF design.

We initially decided to develop a hybrid communications system, not completely replacing the IR from our solution, and layering on top an RF communications network. This meant we could essentially leave our current hardware as it was and plug in an additional module.

Essentially what we were after was a serial to Bluetooth type device, very simple and hopefully low cost, but we couldn't find a suitable device off the shelf, and so we developed a small board (pictured) which consists of some power conditioning, serial conversion, and off the shelf Bluetooth module.

This enabled us to connect directly into one of our existing devices and speak directly to our sensor nodes, so this is where we went. We used a pre-certified module but it's important to realize that pre-certified doesn't mean no problems in certifications and that's been a bit of a challenge.

Software development

In parallel to producing the hardware, we've deployed a lot of resources on the software side getting everything from our gateway into the cloud. We've developed what we call the portal, which handles data ingestion and storage, and management of users. It provides users with the ability to query the data sets based on presence, light output, ambient light, and lamp status. It also has a functionality to provide timed control so that users can apply specific control to their lights at specific times. It provides interfaces to configure and manipulate the RF network, and it also provides an external API to third-party systems.

IOT Pilot

At the time we were doing this, we had no evidence of a large scale Bluetooth mesh installation. Our own office was not large enough to be a representative pilot so we looked among our existing customers. What we really wanted was an engaged tenant, someone who was not just going to have the system operate in the background, but someone who was going to be engaged with the process and who was keen to understand what we were doing and provide feedback on the information we were providing.

We found that with a large company with seven floors of Organic Response installation in the Melbourne CPD, with multiple hundred sensor nodes per floor and a mix of workspaces, so open offices, meeting rooms, open atriums, kitchen areas etc.

They were keen to have us retrofit in our connected solution which we did over a couple of weekends. At the moment we have 1500 connected nodes there, and as far as we know, that's one of the largest Bluetooth low-energy meshes around at the moment.

An image of the output from the organic response portal on one of the floors at the pilot site.

In the portal (pictured) you can see on the left the occupancy as it's building up over a workday. What the heat map is really representing is just the amount of presence or occupancy at a specific place averaged over the day. You can see that it's very busy in the lift lobby, the corridor, and the entrances to the main working spaces are the most busy.

This is early days for us and we're really trying to build up a large data set so that we can work with our clients and understand what might be valuable and actionable insights that we can provide that to them. For example, some initial findings are that the corridor spaces are over-lit, with too long a dwell time on their lights in the corridors and the maximum trim for the lights is too high. There's a large amount of energy that can be saved there.

There is some meeting room under-utilization and we've recently integrated with the client's meeting room booking system. If a meeting room has been booked and the system senses that there's no occupancy in the meeting room, then the booking will be re-released after a specific time. We've also found some faulty lights within the system, and people stay late on Thursdays for some reason.

Challenges

RF integration has been a significant challenge. Luminaires are metal boxes and they're very unfriendly environment for RF. So at the moment we're going through a process with our luminaire partners to integrate the connected hardware, in terms of the position of the node and how the device is mounted within the luminaire, to ensure the performance will be okay.

This is a process of validation we've been through before with our IR communication and PIR sensor. Both are very susceptible to EMI and so it's a process that we previously put in place with our partners and that's worked really well for us in the past.

Another challenge is getting our gateways within an installation connected to the internet. Dealing with IT departments within large companies to get an internet connection within a building is not trivial.

Following the pilot, we are now working on our generation three hardware suite, which will fully integrate the RF component of the design onto the sensor node and this will allow us to reduce the cost of the product and reduce the size, so it makes the barrier to integration much smaller.

Questions and Answers

·         All questions by members of the webinar audience

·         All answers by Dean Campbell-Smith, Technical Director, Organic Response

Question: “In regards to RF and radio communications, how do you manage non-deliberate and deliberate interference, disruption or EMI/EMC?"

Answer: The way we manage the non-deliberate in terms of EMI is by validating each luminaire that comes through. This is a process by which we manage what hardware is installed within the luminaire, and we ensure that it doesn't degrade the performance of our device, at least as far as we can test.

More generally, the messaging that we use RF for is not critical to the system's performance in terms of control.

Bluetooth LE is broadcast on three channels and the receiver's essentially listening on the lowest noise channel, so there's a little bit of in-built resilience with Bluetooth as well.

Question: “Can you give some idea of the costs of typical lighting systems versus your system and typical savings?"

Answer: The cost of our system in terms of the hardware compared to traditional lighting control is not particularly different. Where the cost difference comes is really in terms of installation and commissioning.

You can imagine a wired DALI (Digital Addressable Lighting Interface) system whereby each luminaire gets mains wired into it, but also a two wire dimming interface, and that must be wired to every luminaire as well. For a large installation, several weeks normally have to be programmed into a building program for commissioning the lighting control system to do anything but turn on and off. The cost of that installation is a significant amount more than the Organic Response system.

Also, the energy savings and the amount of user comfort we can provide out of the box is significant, and what a lot of people speak to in terms of the attractiveness of the system.

Question: "You said that you used a pre-certified module but still had certification problems. What were these?"

Answer: We used a module that was pre-certified module and when that certification is done, it is done with a specific antenna. An antenna of the same type and the same gain must be used and we used the same type of antenna that in fact had less gain. However, the issue was we hadn't had the antenna fully qualified and we had to go through a larger amount of testing than I was imagining because we didn't have a qualified antenna.

In addition to that, we had some high limits in the second harmonic of the center transmission, so we had to reduce the power with which we're transmitting to pass a bunch of tests. This really affected our previous test data because we had to go and change the power setting for our devices to meet regulatory standards.

Question: "What steps have been taken to ensure the security of the system from external cyber attack?"

Answer: That's a very interesting question and one that's really been developing. It gets a lot of its security from the actual Bluetooth standard, so we rely on a lot of the implicit Bluetooth security in terms of its encryption.

The connection from the gateway to the cloud and the management of that service, we use Amazon Web Services for all the message brokering and the dealing with data in the cloud. Essentially, we're then relying on third parties for that side as well.

What we really need to do is do a security audit. That will then provide comfort to customers to ensure that that's the case. At the moment, we're in a pilot phase, so we're building this up, but we're also building up functionality, so there is no control of the network that's available to any external sources at the moment. It's simply collection of the data.

Question: "What is required to integrate the sensor nodes into an existing old style fluorescent Batten fitting?"

Answer: It depends a little bit on the terms of what hardware is in there at the moment. The ideal retrofit case for us is retrofitting into an existing network's control solution, where the luminaires already have dimmable drivers that are either dimmable via a DALI interface or an Analog 1 to 10 interface.

If that's the case, all that's required is what we call a detached sensor node, which is a remote. It's similar to a down light that would sit beside the luminaire. Our control device would sit beside that and plug into the dimmable driver.

If the driver for the luminary wasn't dimmable, that would have to be replaced as well, but essentially it's a very attractive retrofit because again, none of the wiring is required.

Question: "Do you install your own network for the lighting system and then connect to the building corporate network for external internet connectivity?"

Answer: It's something we have to work with as a case by case basis. At the moment we're provisioning the wireless network ourselves and then working with the client to get internet connectivity. But this will work differently in different situations. In fact, some early install clients that we're speaking to now would like to have our portal locally hosted, without an internet connection.

Question: "What is the cost of Bluetooth LE modules? Have you interfaced them to the processor? Serial bus?"

Answer: I can't give you a cost of the current module we're using because it's a commercial agreement we have with our technology partner, Silver. We have an agreement with them where we pay not just for the hardware, but for a stack that sits on the hardware, so we pay for their software and their support.

When I was looking, you could get a module for somewhere in the US$5 mark. That would give you a bare module and then you'd need obviously some power and interface to it. Really it's because the volume of information we're talking about is very small, but the number of messages you might see in an installation is quite high. That's why we came for a Bluetooth solution that has a higher over-the-air data rate, where our message length is typically about 400 microseconds per message.

Question: “Have you considered whether you can extend the capabilities of your sensing system to encompass other workplace management functions? For example, hot desking?”

Answer: We do some work with Serraview, that’s the meeting room allocation stuff I was talking about earlier. However, to support hot desking we need to be looking at the desk level resolution, which is not possible with a PIR sensor. You’d need a sensor that's going to give you that kind of information. There are various sensors that can do this now, but not at the cost point we're looking at. It's very much on our road map, and it may be a variant of our sensor in the future, but at the moment our focus is on producing now a low cost RF-based sensor.

Question: “In relation to the applicability of the system for controlling other functions beyond lighting such as air-conditioning”.

Answer:  We were talking to a large energy company in Germany recently, and really, they wanted to know when someone was on the floor so that they could use that as an input to their heating and cooling. That's an incredibly simple output for us, but something that they were finding challenging to get. All they really wanted from us was an output to say, "Someone's now on the floor," or, "The floor is vacant." That's very much something that we're looking to integrate with heating and cooling, but building management systems in general, especially when you look at the energy you can save from heating and cooling versus lighting. Lighting now is mostly LED-based, so we have a lot of energy efficiency gain from that, and so now the value in our system is not just controlling the lights, but providing inputs to optimize other systems.

Question: “Is there any smartphone app to override the standard control, which you have, if a user wants to manually activate a specific function?”

Answer: We have a couple of smartphone apps available on the app store. We use LinkedIn authentication to control user management on this. At the moment they need to buy an IR dongle from us, which enables the phone to transmit and receive IR messages to the nodes. This is how you can, for instance, dim up and down the light to change the output of it from its automatic operation.

With more training, a facilities manager can change the configuration settings and apply different settings over the top of the automatic operation. In addition to that, we have a wall switch which is often used in meeting rooms or board rooms where you may want to watch a video or dim the lights to a specific level for a presentation, and so we have seam control via a wall switch, which is essentially the same thing as the remote application. The remote application just has more functionality for configuring.

Question: "What processor do you use on a controller?"

Answer: We're moving to a NORDIC system on chip for our next generation of controller hardware. It will integrate the RF module onto our control device and will do our processing.