lutron-spy needs an installer or to be installable via a package manager

[evq]

lutron-spy currently requires 3 files to be copied to the device (soon to be 4 once there is an init script #4) and one file to be modified. Additionally, one of those files requires a cross-compilation environment (slsnif) as there is no hosted pre-compiled version.

Perhaps more generally, I think the Wink hub itself needs a package manager. It seems like opkg would be a logical choice. Ideally then the lutron-spy package would have a dependency on the slsnif package.

Such a system might also be useful for other projects like @nashira's blink api.

[JustinAiken]

I went to try using chef to provision my winkhub today, but looks like chef doesn't work with the dropbear SSH daemon the winky uses :(

[evq]

I was able to cross compile opkg for the wink. I've created packages for slsnif and lutron-spy, and also played around with making a python package :)

I need to setup some hosting so I can make an opkg repo and host a bootstrap script, but things are looking promising!

[evq]

Success! I have a working bootstrap script for opkg and have set up a repository that currently has lutron-spy, slsnif, and vim. Any chance you would be interested in taking a gamble and trying it out on your hub? :) It should be fairly safe, it makes backups of the two existing files it modifies.

curl -s http://wink.7pr.xyz/bootstrap.sh | bash

It was a little tricky (although some of that was my own doing), it seems the default libcurl is missing a reference to symbols from rt, also ldconfig is not present on the wink. Besides fixing those two issues, most of the script is mucking around to install the opkg without using opkg.

I wonder if we'll see an influx in rooted hubs as a result of the ssl certificate screwup...

I have a partial implentation of the Philips Hue API that is pretty heavily abstracted from the protocol for the LEDs. In my mind there's nothing stopping it from running on the Wink hub at this point. There's some interesting potential for reverse engineering the various radio protocols to replace the cloud based API. Blink seems to be something toward this direction, but it uses aprontest as it's backend which is somewhat limited. The nifty thing would be that no real client work would be needed if the implementation is true to spec. Not sure how much interest there would be for something like this, I myself am only using the wink with these lutron switches at this point :P

[JustinAiken]

Sweet! I'm just heading away from home for a week (RailsConf), but I'll cross my fingers and give it a run when I get back.

[nashira]

Just caught this thread, very exciting. I've been working on Blink a little to make it compatible with a Hue hub and was thinking it would be very cool to have a Hue-compatible api on the Wink, with some extensions for the other device types it supports. I bet there would be interest in making the Wink more capable offline, but it's clear aprontest is not going to cut it. I believe someone was able to interface with the zigbee radio directly using vendor-supplied reference code for the chip it uses. It would be great to start to define some open api or protocol for home automation.

[JustinAiken]

@evq - It looks like one of the URL's referenced by the bootstrap script is down... http://wink.7pr.xyz... was going to give it a try.

Besides the bootstrapping, I've been thinking about ways to automate provisioning of the box:

• Chef - My preferred solution, but it doesn't work w/ the dropbear SSH client.
• Puppet - No... just no. I'd rather run bash commands one by one manually :p
• ansible - If we can get python installed via your opkg, would be a perfect fit
• salt - Haven't looked too close, but I don't think this one looks very likely...

[evq]

Hey @JustinAiken

I just checked and all the downloads in the script worked for me. Another person who was helping me test said it was his IDS flagging the ldconfig download as ELF and blocked it. Can you check which file it failed at? I may have to change the bootstrap script slightly to download and extract a tar'd version.

The opkg bootstrap script worked for me on a 0.86 hub rooted via the NAND short, I was worried about newer versions but it has been smooth sailing on there. My current efforts have been on reverse engineering the ZigbeeHACord unix socket protocol so that I can put my Philips Hue compatible API on the wink hub. At this point though, it is feeling like it is harder to work with the existing wink binaries then just start from scratch. The serial protocol for talking directly to radio is actually well documented. At this point I am planning on making a custom alternative firmware :)