Stairwell Foot Lighting System

When getting back into electronics, one of the projects I had in mind was to revamp our stairwell lighting system. In 2010, we renovated our stairwell. I took the opportunity to design in a foot-lighting system that was motion controlled. It has worked faultlessly for the last six years. But who can stop at revision 1.0 when there is so much more can be done? This entry is about working out a new stair well foot lighting controller.

Fixing What is Not Broken

If it has worked faultlessly for six years, then what is there to fix? The basic driver was the size of the original solution. Like the doorbell project, the original was put together with what I could obtain with what I understood at the time. I have no regrets about that and would take that approach again since it solved the problem. However, since day-one, I had always had it in mind that I would like to rework this with my own Micro-Controller solution. Now with what I have learned in nearly two years, it’s time.


This initial solution comprised of an electro mechanical timer – that I have to manually set for Summer time and Winter time. It has three PIR13 modules from ELV as the motion detection sensors and three sets of PIR13 timers (also from ELV but now obsolete) connected to a LED driver from SLV that can drive up to eight high power LEDs each. In my system, I have only a maximum of four in each bank.

Initial Ideas – to the big picture

lcu1sI had envisaged using a small embedded device with an inbuilt touch display. This device the LCU1 was released by EQ3 through ELV. It has a tool set for UI development with direct interfacing to analogue inputs and four relays. I was attracted to this device because of the the embedded Linux and the size. I imagined having this positioned in place of the existing control system. Instead of the mechanical timer, the timing would be internal and possibly supported by “Astro” calculation. Any additional changes to the set up could be done by using the touch screen. I also have the thought that this could be eventually expanded as a burglar alarm. I had got as far as a rudimentary graphical user interface. There was still a lot to sort out with regard to interfacing with the motion sensors and eventually the connection to LED foot lighting. This is where I seemed to reach my limit and the project was put in a drawer. …In the mean time, the Raspberry Pi arrived!

The Raspberry Pi, with its huge support network, inspires and enables new ideas to be realised. After EQ3 brought out their Homematic transponder for Raspberry Pi, I was inspired to get this project back on the table.  In our house we have the Homematic system from EQ3. This is a Home Automation system that has a rich set of sensors and actuators using a bi-direction wireless protocol. It also has provision for a wired solution too, for larger, more complex installations. The beauty of this system is that it can be built upon. Starting only with, say, one heater regulator, then perhaps adding a wall thermostat and eventually adding in the Central Control Unit (CCU) to handle more complex relationships between the sensors and actuators. For a couple of years now EQ3 released their CCU2 firmware for Raspberry Pi. This now opens an exciting new world of possibilities that goes beyond a simple foot lighting controller

I realised that even though the touch display would be a cute feature, it was not actually essential to the solution. From a user point of view, any changes to the system would be better made by simply picking up a tablet and making the changes over a browser rather than having to go down into the basement each time – which is how changes are currently made.

So the plan is that the Raspberry Pi will be taking over the operation of the CCU2 with the lighting controller connected to the Raspberry Pi via the I²C bus and a Web User Interface enabling remote control of the lighting system and Homematic installation. I need to stress that I have no big interest in accessing this outside the home. The possibility is still there with the Raspberry Pi as the “back bone”.


I modelled the complete set of ideas as a SysML block “context” diagram. The idea here is that the new Lighting Controller is type of I²C device connected to a Home Server. The Home Server is an abstract description that is modelled as one or possibly more Raspberry Pis. The CCU2 and a web server is envisaged to run on the Pi.

The diagram below is similar to the context diagram but only contains the components relevant to the stairwell foot lighting. Taking this one level further I modelled the internal block diagram for Lighting Controller to start to explore the different power domains that the system will have to deal with. I have decided from the start that I will be trying to work solely with 3.3Volts and not the 5V/3V3 mix that I had with the Clock Project. However, I have found it prudent that 3V3 is suitable for micro controller but 12V is probably better for driving the relays and the motion detectors.



The Timed LED Lighting Controller (TL2C) has four basic parts. A Power System a Controller , three banks of LEDs including their drivers (I will be still using the drives from SLV) and three motion detectors (PIR13 modules).

The original intention for the Power System was to pass through 240V to the LED drivers and also provide the 3V3 for the controller and 12V for the relays.


A short discussion with my tutor, Chris Gammell of Contextual Electronics hinted that the design of an off-line power converter would probably shift the focus of this project to power supply design. This could certainly be tackled but maybe in parallel or at a later stage. It would be quicker to simply use a “Wall Wart” for the 240V to 12V conversion. A simple LDO  regulator can then be used for the 12V to 3V3 conversion.

As the larger context block diagram indicates, there will be more components to this final project than just a single micro controlled device. I will need to move the existing CCU2 set up I have to the Raspberry Pi, build some type of Web User Interface to be able to interface and configure the Stairwell Foot Lighting system and finally see if it is possible to integrate the astro timer of the CCU2 to the foot lighting system. My initial thought is through the XML-API offered by the CCU2. This will be confirmed in a future post.

To be honest, I am not sure how the web interface will work between the lighting controller and the Homematic CCU2. I figure I will let that piece evolve as I learn more about website deign, CGI and Python or what other scripting language I will choose to interface the I²C bus with Web front end.

In the next entry, I will be talking about the design I will come up with for the Timed LED Lighting Controller and the parts selected.


Back to the Drawing Board

Well, not exactly back to the drawing board for everything… What has developed since doing the actual schematic is that the display module was treated as a black box. Now it is time to open this up and understand how this is to work. The beauty of this approach is that not knowing anything about the display module has not held me up on the other, simpler aspects of the project. This module is possibly going to be the most challenging. There are several dynamic elements to it and it is also going to be the module that will draw the most current. So far I have indicated that this module will be supplied by Vbb i.e. +5V and will be interfaced with the controller via a SPI bus.

The first challenge is which direction to take this. I find myself at a bit of a cross roads. Searching the internet for a suitable example as a starting point, I see there are already 7-segment display driver from Maxim i.e. Display module - MaximMAX7221. The advantage here is that it provides many features that make the implementation of a clock display relatively simple.  I have quickly put together the block diagram that shows the intended implementation. It seems I could use the fourth and fifth digits to drive the colon and auto-time and alarm enabled indicators. The implications on the driving current need to be ratified.

The down side is the cost and the power consumption. It would mean rethinking my use of the MCP1703T-5002E/CB as the main regulator since this is limited to 250mA only. In reality, for practical purposes, even 250mA is to high for an appliance that is expected to be running 24×7 such as a digital alarm clock.

The alternative to using the display driver is to implement this myself. The advantage there is I am free to introduce what behaviour I need for the module to work within this project. The disadvantage is additional complexity in firmware updates. There will be two micro-controllers to contend with. At this stage, I have not done any calculations to see if there would be a saving in cost or power drawn by going the home-made route.

Display module - Controller

The block diagram for the micro controller based display module is very similar. The micro controller is used to replace the behaviour of the display driver chip. Although an ATMega88 is depicted here, any suitable i.e. low powered micro controller would suffice. As long as the duty cycle on the LED segments and indicator lamps is enough to provide a clear display.

Where to now?

Since I am at a cross road, the best way forward is to try things out. This is probably not good SysML practice since the design is not actually complete. But prototyping must be considered a part of design. I don’t have enough information to make a sensible decision as to the direction. The best way forward is to implement a prototype of the two possibilities and make the best choice from there. In this case I will be able to measure physical performance and power consumption and not relay on theoretical calculations.

Wired for Action – almost

In the last post, I presented the initial ideas for powering the project. Now it is time to move on and start looking into the individual modules. I was impressed as to how quickly this part progressed since I had done the up-front thinking of the pin and port allocation. So much so, that before I knew it I had most of the schematic done making it unnecessary to span the development over several blog posts.

sch-top-02The high level diagram is now looking more complete with the use of hierarchical sheet pins to connect the respective module. This clearly demonstrates the communication between the modules and again, looks very similar to the initial block diagram. It should be iterated that the up-front work of the block diagram contributed significantly to the creation of this section of the schematic. Since I had previously thought out the pin and port allocation, it was a simple matter of aligning the labels on the sheets so that it is concise and descriptive.


The controller chosen for this project is the ATMega88p. I have to admit for no good reason other than I have a development board for this processor and have used the ATMega8 before. Unless there is a significant reason to re-think this decision, I will be staying with the ATMega.


The controller diagram, at this stage, describes the connection of the Serial Peripheral Interface (SPI) bus and interrupts using hierarchical labels. I have also added a pin header for on-board programming. I do need to clarify this further to be sure that this is the correct connection/mechanism for programming the chip on-board.

RTC Module

It has been mentioned often enough that a pre-fabricated module will be used for the Real-Time-Clock (RTC). This is the RTC-DCF from ELV. This module implements a RTC with built in calendar and has also a module to receive the DCF77 signal. When all things are working, then there is no need to set the time on the final clock appliance. It is envisaged that there will be a manual mode for the clock in cases where the signal is not received.

IMG_1054The symbol for the RTC in KiCad is a custom symbol for this module. Though the original kit is mounted in an Arduino shield type form factor, the module itself can be punched out and either soldered onto the application board or, as I envisage, connect it to the application board via a set of 2×6 pole pin headers.


This schematic implements the level shifter mechanism to shift the +5V signal from the controller to a 3V3 signal that the RTC requires. The RTC supports a couple of different mechanisms for communication. In this case, I am opting for SPI. The usage of the signal lines look to double up. This is only because when one communication mechanism is chosen (programmed via a DIP switch on the module) the other lines are used to support the extra interrupt features of the module. For the implementation and features I require, not all connections are necessary. The Tx line, for instance will not be required in this case.

Thinking back on the SysML block diagram, the level-shifter was not clearly visible on the block diagram. It was certainly defined in the model and was specified as the type of port on the 3V3 SPI bus. What is also not clear not the SysML model is that the SPI 3V3 bus requires both Vbb and Vcc to operate since it has to convert the signal between the two.

What’s next

I am quite satisfied with the schematic so far. More needs to be done on the controller. The interface buttons and switches need to be added. Also some thought needs to go into the housing since four buttons and a switch are already available. What I am proposing requires some additional buttons for the extra features. I am sure my refurbishment of this appliance can include some modifications. At this stage, I don’t see it a major problem to add these at the back of the housing.

The next significant module is the display module. I have some initial thoughts on this but will save that for a future post.