Philips Hue LBW010 teardown

Why Hue?

I’ve been thinking about some how automation for a while but have been wondering how the best way to go about it would be. I was thinking of a mesh network of battery powered switches using Sub-1GHz 6LoWPAN – hence the recent mucking about with Contiki OS. However, I decided to go for a couple of Amazon Echo Dots in a recently Black Friday promo and decided that I should get an off-the-shelf solution working whilst I spend the next couple of years making the “perfect” one.

After a little research I decided on the Philips Hue system. These are Zigbee controlled bulbs that you leave permanently powered. The system isn’t perfect – but better than the others on the shortlist. Z-Wave is proprietary. LightwaveRF leeches power through the bulbs and you can’t tell if the device heard your command or not.

Philips did get some grief for locking out other Zigbee devices but seem to have reversed that. Obviously other devices don’t quite get the love that Philips products do, but they’re OK. On the plus side, Philips have documented a nice API at the hub level that allows you control their bulbs from the outside of the Zigbee network. They are however understandably protective of things on the inside.

On the negative side, Philips do not have a device that can control an arbitrary light. I’ve got a floodlight and some track lighting in the workshop. Can’t do those. My bathroom has about 9 GU10 bulbs in the ceiling – possible but 9 x £25 is an unpleasant £225.

What’s the plan?

My plan is threefold.

  • Firstly, I want to take one of the cheaper £15 single colour bulbs apart and see what’s what.
  • Secondly, I want to extend the Hue ecosystem but by “gently” hacking it – i.e. buying a Philips Hue product, leaving their hardware and code more or less intact but adding what I want to it.
  • Thirdly, I’d like to do some Zigbee work. Maybe make a slightly more feature rich switch that those they supply. Maybe vreate a Zigbee light that Philips are happy to work with

Anyway, I’ll start with the simplest so I have something working and take steps from there.

What’s inside then?

img_20161209_174552Before I start, let me say that I was greatly helped by the work of others such as Colin O’Flynn. I’m not the first to tear open a Hue bulb, but it turns out my UK spec bayonet fitting LBW010 is a bit different to those before.

First you have to remove the plastic top. I used a small hacksaw, but it eventually came away in one piece when the glue gave way. I think a little bit of squeezing in the vice might have been all that’s needed. It’s not like I’m going to put it back together anyway so not too important.

img_20161209_174841It opens up to reveal the LED board (with metal heatsink) which is attached with a couple of screws and more glue. I tried a heat gun to soften the glue but that didn’t help. In the end just some levering with a small screwdriver did the trick. The LED board separates nicely from the logic board and has a simple 0.1″ pitch SMT header for this. Very useful. Some quick measurements show the LEDs have a voltage of 24.4V and a current of 350mA. I assume there’s a constant current supply on the PCB but I’ve not taken the time to track that down yet.

One thing worth noting on the B22 bulbs is that the two main contacts for mains power are actually solder. Before pulling the PCB out you should melt the solder on these. I didn’t and ripped on of the 15Ω resistors that are used as fuses from the PCB. Easily replaced, but annoying that I was heavy handed with this.

hue-pcb-bottomOther bulb teardowns revealed an Atmel ATMega2564 (AVR microcontroller with Zigbee) and a ST HVLED815PF (LED driver) but my bulb seems to be different. Inside is an Atmel SAM21R21E18A – the same ARM microcontroller with Zigbee as found in the Bridge. I couldn’t find a LED driver IC so this is perhaps constructed using discrete components. I didn’t look very hard though. I will try to get a better photo later.

There are a number of test pads. Careful probing a track tracing shows they are as follows:

TP1 – GND
TP2 – PA30 on the microcontroller. This is SWCLK for debugging
TP3 – PA31. This is SWDIO for debugging
TP4 – Serial TX (more on this below)
TP5 – Serial RX
TP6 – main output to the LED
TP7 – 3.3V. This is the output from the 3.3V regulator and input to the microcontroller. It can be used to power the board but you’re better off using TP25.
TP8 – RESET for the microcontroller
TP11 – GND
TP25 – Power in to the LM2204 VLDO regulator. It takes about 24V when powered from the mains but is happy when powered with 5.1V from USB for hacking about.

What was most interesting initially was the output on TP4. It contains debug messages from the Atmel Zigbee stack and on power up you get something like this. Output is 115200 8N1 and line endings are CR only.

[Log,Info,S_LightConfiguration,Configuration Data OK, crc=0x60083D2F]
[Log,Info,S_DeviceInfo,Default Flux table]
[Log,Info,S_DeviceInfo,ProductId: Philips-LWB010-1-A19DLv3, ModelId: LWB010]
[Log,Info,S_DeviceInfo,ZLLDeviceId: 256(DimmableLight), PwmChnl: 1]
[Log,Info,ConfLightLamp,devsig=0x10010318]
[Log,Info,S_DeviceInfo,Booting into normal mode...]
[Log,Info,S_DeviceInfo,DeviceId: ConfLight]
[Log,Info,N_Security,LIB4.6.135]
[Log,Info,N_Security,KeyBitMask,0x0012]
[Log,Info,AL_OTAUpgrade,containerVersion=0x01000B00]
[Log,Info,ConfLightLamp,errs=0,lastErr=RST@0]
[Log,Info,ConfLightLamp,Platform 0.85.0: r19111, BC_V3.3.0_2.4_M: r19111]
[Log,Info,ConfLightLamp,Product version ConfLight fw_ver: 1.15.0_r18729,built by LouvreZLL]
[Log,Info,A_Commissioning,NwkAddr: 0x32BE, Ch: 20, Pan: 0x5DE4, NwkUpdId: 0, ExtPanID: 8D80F343023D3B9E]
[SYS,Info,Transmit buffer full]
[TH,Ready,0]
[Log,Info,N_Connection,Starting discovery for updated networks]
[Log,Info,N_Connection,Discovery for updated networks completed]

This is interesting and my initial thoughts were that I could capture any output when light levels are set and make use of these. Unfortunately, there’s nothing interesting once the bulb is connected and running.

hue-pwmI decided that there must be some more useful output from the microcontroller going to the LED drive circuitry so decided to probe the pins whilst changing output. Bingo! It seems that we have a nice PWM output on PA17 with the duty cycle representing the brightness.You need to move a large electrolytic capacitor out of the way to get to the IC and it’s pin 18 (the second one up from the bottom on the RHS). I haven’t traced it to a test point or other more accessible location yet, but I will.

Advertisements

6LoWPAN part 2 – Building Contiki on Windows

Getting started

Following on from my previous post about wanting to experiment with 6LoWPAN and Contiki, I suppose I’d better do something. First things first. I needed to download Contiki and get it building. I’ve got a few options.

A Linux VM

The official guide pointed me towards using a pre-configured “Instant Contiki” Ubuntu VM and that certainly works. I needed to install and setup VMWare but that wasn’t too bad. It’s probably time I played around with Linux a bit more, so I also installed Linux Mint (easier for newbies) in a VM too.

Cygwin

There was also a guide on Sun May Sky about using Cygwin on Windows. I’m sure this works as described and I was about to give it a try, but then I though “Cygwin? Isn’t that a little outdated for Windows 10?”

Bash on Ubuntu on Windows

ubutntu-on-windows-10-logo-bannerWhen I first wrote this guide, the version of Windows was the 1607 “Anniversary Update” and the Bash shell was available but as a slightly hidden developer-only feature. I’ve updated it for the latest (at time of update) Windows 1709 “Creator’s Update”. To get things working in 1709 just install Ubuntu from the Windows store and type “ubuntu” to run.

The only thing worth mentioning is that your C drive will appear as /mnt/c rather than Cygwin’s /cygdrive/c.

YaKai Chen’s Cygwin guide mentioned installing the ARM GNU Compiler toolchain and adding the installation folder to the path. The default Windows installation path with spaces and (x86) is awkward to use in Linux and it turns out it isn’t even necessary.
I went to build a Contiki component with a make command and was told that it wasn’t installed. “sudo apt-get install make” solved that.

build-error-1-armYou’ll notice the make failed with arm-none-eabi-gcc not found, so I tried just entering arm-none-eabi-gcc. A very helpful prompt told me that apt-get install gcc-arm-none-eabi might solve my woes. And it did.

build-error-2-srecordTime to try that make again… OK, this time srec_cat was the missing culprit, but just typing srec_cat told me what needed to be installed. Simply apt-get install srecord and I was ready for attempt #3… and success.

build-error-3-successThat seemed easy! Don’t tell anyone, but I might get to like this new Bash shell. Now to get something meaningful working…

6LowPAN (part 1) – discovering sub 1GHz mesh networking

What?

So, party inspired by my not particularly successful Tado teardown I’ve decided to play around with 6LowPAN. “What’s 6LowPAN?” you may ask. Well, it IPv6 networking over Low power Wireless Personal Area Networks. That’s what Tado uses to communicate between its components and I thought I might re-purpose their gateway for this. Unfortunately it uses a slightly out of data Stellaris microcontroller and getting this working was awkward. I got bored with it.

6lowpan_mesh

Why?

The ultimate goal would be to have drop-in smart light switches that link up in a mesh and can be controlled remotely home-automation style. Ideally I’d like something that:

  • can report its status back (unlike some commercial offerings)
  • is battery powered so that there’s no need for a neutral connection in the switch
  • doesn’t leech power through the load – that’s cheating and won’t work well with LED lighting
  • can operate as a separate manual switch in case the network is down

How far will I get with this? Who knows. Let’s see.

How?

6LoWPAN can sometimes be over a 2.4GHz network (like Zigbee) but I’m going to go with Sub-1GHz for better range through walls and hopefully as far as my garden office / workshop. TI do a nice range of Sub-1GHz ARm microcontrollers. I got myself some CC1310 launchpads and a CC1350 launchpad too for good measure.

As far as software goes, it looks like Contiki is a good place to start. It’s a RTOS designed exactly for 6LoWPAN. It looks pretty good, but despite the best efforts of the creators I must admit it doesn’t seem easy to get started with. There is some helpful stuff over at Sun May Sky which I believe is maintained by YiKai Chen who you’ll also find helping out over on the TI E2E Community.

Getting started

First things first. I needed to download Contiki and get it building. The official guide pointed me towards using a pre-configured “Instant Contiki” Ubuntu VM and that certainly works. There was also a guide on Sun May Sky about using Cygwin on Windows. I had some minor trouble with that so thought I’d try out the new Ubuntu bash shell that’s (a hidden) part of the latest Windows 10 builds. That seemed to work well, so I thought I’d add my own guide.

Electric motorcycle test ride

The latest object of my gadget lust is just a battery. A big battery. A big battery with a couple of wheels attached.

2012_zero-s_studio_black-ra_777x555_gallerySometime around 2012 I took a test ride on a Zero S electric motorbike. I was really impressed by the power delivery and handling, but I seem to remember the price at the time was about £12,000 and the range was (at best) 114 miles. Power isn’t quoted, but I believe you can ride these on a UK learner licence, so not that much on paper. The style was OK but ordinary. It wasn’t really ready to be a replacement for a petrol bike. It was definitely something I was going to keep an eye on though. Electric bikes were the future, but not quite the present.

2016_zero-sr_studio_ra_777x555_galleryFast forward a couple of years. Things have improved a fair bit. The same bike dealer – 21st Moto in Swanley, Kent – had a 2016 Zero SR available for test so I had to give it a go. It has more power – 66hp for the ZF13 version but feels like more. It had more range – 161 miles city, half that on the motorway. The styling is better. There are various charging options but the main use case is the same – plug it in to a normal household supply overnight or whilst you’re at work and fuel is near enough free. The list price had until recently been £11,500 for the larger batteried version but a recent price hike and poor Sterling exchange rate had increased that to £13,000. Still tempting…

The SR may be the flagship model but I have always liked supermotos since the days were you had to make your own. Over the years I’ve had a home converted Honda XR650, lethal Yamaha YZ250, KTM Duke and currently an Aprilia Dorsoduro. The electric model that really appealed to me was a Zero FXS. The ZF6.5 version has less power (44bhp) less range (90 miles) but with less weight it had the potential for more fun on my short commute to work. List price had increased to £10,500.

wp-image-1160847413jpg.jpg

wp-image-394273140jpg.jpg

21st Moto didn’t have a demo one. Daytona Motorcycles did, but due to the fact they lost their trade plate (literally – it fell of a bike) it took me about 5 weeks to try one out. It was worth the wait. I was impressed! It really didn’t feel like it only has 44hp. Electric motors deliver all their torque from zero rpm so there is as much as you need from low revs. In fact the power delivery needs to be restricted low down the rev range so that you don’t flip the bike. It feels like a much larger engine, only running out of puff a bit as you get to higher speeds. The handling is great.

A had a good 45 minute test ride covering high-ish speeds (85mph) and deliberately filtering through awkward and annoying traffic too. Hooked! It’s not a motorway or long distance bike but that doesn’t appeal to me anyway. It’s a great backroad and commuting tool. I had a quick 15 minute go back-to-back with their DSR. It’s a dual sport with trailie wheels but has the same engine as the SR I was considering. Whilst the extra power and range is of course nice, it’s not worth the extra to me.

So the big question – am I going to buy one. The answer is yes, but not just yet. The 2017 models are about to be announced. When I rode it the UK zero emission plug-in grant was still “almost here” as it had been for years. This could be a few thousand pounds so worth waiting for if it wasn’t too far off. Also, we might be moving house soon and a bike purchase might have to be bumped down the list.

Since my test ride the grant has actually been announced! It’s as part of the £35m zero emission package but it should mean £1500 off the list price of a Zero. Zero will have to register for this, so no exact date when it will actually happen. Maybe with the new 2017 models. A zero FXS will definitely be my next bike, but probably sometime in 2017.

UPDATE: The long-awaited UK plug-in motorcycle grant is finally happening. From January 2017 (and for just the 2017 models) there is a grant which takes £1,500 off the price of a new Zero. I think it’s going to happen…

ANOTHER UPDATE: 17 Dec – I just ordered one! It seems that the grant starts in 2017 but doesn’t just apply to 2017 models. The FXS hasn’t changed much and with Zero giving another £1500 off the last of the 2016 models, out was an offer I couldn’t pass up. The full list price is £11,390 but £8,390 is far more reasonable. Should have it by mid January.

Hacking the Tado (part 3 – Thermostat)

So, parts 1 and 2 showed that the Tado gateway could be debugged and re-purposed. What about the main Thermostat unit? That contains a MSP430F5659 rather than a Tiva. It also has a CC1101 sub-1GHz radio. There’s 2 Panasonic DK series latching relays to switch the heating and hot water – DK1a1b-L2-3V to be precise. Along with that is what I assume to be a switching power supply so it is powered by the mains and a 1.0F supercapacitor – probably to keep it working if this is briefly switched off. Finally there’s a Sensirion SHT21 temperature and humidity sensor – no thermostat would be complete without a temperature sensor! Whilst the MSP430s have an on-board temperature sensor these get heated by the processor itself so aren’t really much use.

Connecting a debugger

wp-1468699428814.jpgWell, just like the gateway, there was a very inviting 12 pin header – this time 0.1″ pitch through hole. It turns out this is a standard 14 pin MSP430 JTAG header with the unused pins 13 and 14 missing. Another result. Adding the header and connecting this up to a MSP-FET was all that was needed. Not the missing pins on the new header (on the RHS). That’s just to remind me to align it properly with the 14 pin ribbon cable.

wp-1468699453123.jpgThe MSP430 is actually on the reverse of the device, but to be honest that’s the only interesting thing there. Want a look anyway? OK then. Here it is.

The first thing I did was use MSP Flasher to verify it could connect to the MSP430 and then dump the sections of the ROM that I might want to put back. There’s MAIN (code), INFO (configuration and calibration), BSL (this was all 0xFFs anyway). I dumped the RAM too just in case. These need to be backed up to separate data files. Apart from one tiny bit of plastic that needs to be trimmed you can even get it back in the case with the header in place. Same with the Gateway.

CC1101, relays, buttons, LEDs

Next I need to work out what pins connect to the peripherals..

 

Hacking the Tado (part 2 – gateway)

Well, in part 1 I worked out that I could connect to the Gateway with a debugger. Now I need to work out a little bit about the board. It’s a 4-layer board, so tracing the signals isn’t that easy. Writing some simple code seemed to be the best way to determine what’s connected to what.

LEDs

The easiest bit. I just toggled all the pins until i found out that the three green LEDs are all on port H. The link LED is bit 5, router is bit 6 and internet is bit 7. All are active high.

Switches

One switch is reset, so not much happening there. I can’t seem to determine what the other is doing yet. It doesn’t appear to be directly connected to a pin and may have circuitry between that and the reset button. I can’t  remember what function it had on the Tado.

CC1101 radio, Ethernet, USB type A jack

Still to come.

Getting started with StellarisWare

I thought the easiest approach to getting somethings going was to try some sample code from StellarisWare – perhaps even some Ethernet code. Unfortunately the examples seem to only cover specific evaluation boards and I seem to hit a hard fault at some point running adapted code. Not getting really anywhere right now.

Hacking the Tado (part 1)

Tado’s v1 connector. This connects the system to your router and Tado’s servers

I’ve been a fan of the Tado smart thermostat for a while. I didn’t quite make it onto the UK beta test, but bought one as they were first available. Way before Nest, Hive and the others. It’s a nice device. It knows when you’re home and what the weather is, so adjusts your heating to be warm by the time you get home.

Of course, I couldn’t resist a peek inside even before I installed it. It was great to find that the internals involved a TI Stellaris ARM microcontroller in one of the three components, MSP430s on the other two, and all three were linked with CC1101 sub-1GHz radios. The developers were also really helpful. When I had problem with my Sky Broadband’s rubbish DNS, they created and remotely deployed firmware for me within 24 hours. They also told me that it used 6LoWPAN (i.e. IPv6 over a mesh network) to communicate between the components.

Fast forward a couple of years and i decided to upgrade my Tado v1 to a v2. Whilst there was some discount of the list price for returning my v1 device, it seemed far more fun to play around with the hardware. I’m going to hack it. Nothing devious or underhand, of course. I’m just going to make use of this nice piece of hardware.

First the connector. This contains a LM3S9997 microcontroller. This has now been superseded by TI’s Tiva range – and Tado now use a STM32 in the v2 connector. However, there’s nothing wrong with this device. It does the job. A bit of snooping showed a couple of unpopulated SMT headers on the top – and similar large pitch versions on the underside. I traced the ICDI (debugging) pins on the LM3S and discover not only that the go to one of these headers, but that it is even in a standard ARM JTAG header format. Result! Thank you Tado. Hardware developers that care! You’ll see my new 10-pin addition in the photo above, along with the still unpopulated 8-pin header.

wp-1468447005484.jpgAll I needed to do was solder on a header and connect an ICDI to it. Unfortunately I couldn’t find the proper debugger – they’re a bit old for what I work with. The newer XDS110 on my CC2650 LaunchPad wouldn’t play with the older LM Flash programmer software. Whilst the really helpful Bluehash over on 43oh.com kindly offered to send me the correct debugger, I decide to see if I could hack something together. A bit of ribbon cable and some iffy soldering and my old Stellaris LaunchPad was called into action. Now I could dump the flash contents – so that I can revert to if needed – and program new firmware.

All I’ve done so far is dump the Tado firmware and take a peek. Nothing too revealing in all those bytes – other than a reference to Contiki 2.6. Whilst I don’t know much about Contiki yet, I know it’s TI’s preferred route to getting 6LoWPAN working to provide an edge router for newer devices like the CC1310 – an ARM microcontroller with a Sub-1GHz radio built in. Anyway, that’s enough for now. We have a vague plan…