Manually Updating the Wink Hub

Let’s take a look at the steps required to manually install a firmware update to the Wink Hub.

The update works by booting into a separate linux image located on different flash partitions so that it can then download new images and flash them to the main application partitions.

So to update manually we are going to do the same thing, but first we need to root the updater before we boot into it.

Let’s mount the rootfs of the updater to /tmp/updater:

ubiattach -p /dev/mtd2
mkdir /tmp/updater
mount -t ubifs ubi2:rootfs /tmp/updater

We need to remove the root password on this image like before, copy over our ssh key, and remove the S99local script that runs the update process from /etc/init.d. Also make sure we have our wifi configuration saved properly to the database (see original root post). We may also want to save copies of other files we have modified such as from /var/www. For insurance let’s also unlock the bootloader:

fw_setenv bootdelay 5

The bootloader parameters are sometimes restored to defaults so we should also edit /database_default/u-boot.env here and each time we update the app-rootfs.

Once we are ready to boot over we can do:

echo "1" > /database/DO_UPDATE

Then we are ready to reboot.

Once we are booted into the updater image we can follow the example of the /root/platform/ script to manually download and flash the updates. So far only the application rootfs has been updated and can be downloaded from:

At this time the update is small enough that we can download it to /tmp and flash it using:

ubiformat /dev/mtd5 -f /tmp/app-rootfs.ubi

After they are in place, we will need to root again using the same process outlined above (except we are working with /dev/mtd5 now). Also pay attention to any changes that may be present in the update such as disabling the UART login (/etc/inittab), not starting dropbear, etc… And we should modify the S31platform script and block the cloud addresses again as we did in the original root post.

Once we are ready to boot back into the application we can do:

echo "0" > /database/DO_UPDATE

And reboot, fingers crossed.

PS – Let’s say we want to take a look at the rootfs before we update. To do so on a linux desktop, we can download the ubi image and:

modprobe mtdblock
modprobe ubi
modprobe nandsim first_id_byte=0x01 second_id_byte=0xf1 third_id_byte=0x00 fourth_id_byte=0x1d
dd if=app-rootfs.ubi of=/dev/mtdblock0 bs=2048
ubiattach /dev/ubi_ctrl -m 0 -O 2048
mkdir /media/ubifs
mount -t ubifs ubi0_0 /media/ubifs

The above assumes you have no other mtdblock devices on your system. It also simulates the actual flash chip used in the device which is larger than necessary for just playing with the rootfs.

Wink & Lutron

So as we know the Wink Hub supports Lutron Caseta devices.  That’s cool, but Lutron makes a lot of other automation devices.  It’s sad we can’t use some of them…

So let’s take a look around in the Lutron database located in /database/lutron-db.sqlite

If we look at the DeviceInfo table, we can see that there are 35 device types listed including many of the RadioRa2 devices, other types of shades, and more…  what’s a Super Pico?

Next, we see there is a table called SupportedDevices.  What’s this, a WHITELIST?!  And only 13 out of the 35 possible devices on it!?

Well, let’s find out.  First we try to add an RRD-6D dimmer using

aprontest -a -r lutron

Nothing happens.

Now let’s go back into the database and insert the DeviceInfoID for RRD-6D (which is 1) into the SupportedDevices table.  Reboot to adopt the changes.

So once again, …

aprontest -a -r lutron

Hold down the button on the RRD-6D and what do you know…. we have an RRD-6D dimmer paired to our wink hub.  It shows one attribute, level, and works just like we’d expect.

Well that is very promising.  We may be able to add keypads, aux repeaters, relay modules, etc…  with our modified whitelist.  Of course they aren’t exactly the cheapest devices to get a hold of and we may run into limitations since the software could be lacking for certain aspects of these unsupported devices, but can’t win ’em all.

What else do we see in the Lutron database?

Essentially, the Lutron subsystem inside the Wink Hub appears to be more or less a Caseta Smart Bridge (Pro) running on shared hardware.  And of course it is easy to guess what the difference between the Pro and standard Smart Bridge is (*cough*whitelist*cough*).  The Caseta Smart Bridge, then, appears to be based on the Clear Connect Gateway which Lutron makes for AMX and explains why all those RA2 devices descriptions exist in the database.

Another interesting table is BusinessRules.  Inside we find properties MaxNumberOfDevices 50 and MaxNumberOfRepeaters 1.  So maybe these could come in handy if we build a large network of Lutron devices assuming we don’t run into other memory constraints.

Until next time…