Wink Hub Teardown

[cmonroe]

I was grabbing a few things at HD the other day and ran across the Wink hub. For the price I figured the least I could do was tear one apart and post some pictures

Boot log is also linked (the UART port is fully functional @ 8/N/1/115200 however it’s password protected). It’s interesting to me that the left access to JTAGs for all chips on the board; maybe a first run only type deal? It looks like you can easily connect up to the SPI bus and likely snoop and/or control the Z-wave chip. The SmartThings hub is far more simple but it’s been a long time since I’ve seen a board on the market with such a simple/clean layout, especially given the cost. CPU is a Freescale i.MX28 @ 454Mhz, 64MB DRAM and 128MB NAND flash. Amazingly it runs U-boot as well. The hardware folks seemed to do a good job here, can’t say the same for the software. I also find the 2 433Mhz radios to be a huge waste as 433Mhz signal doesn’t travel that far in the first place nor do I have any intention of using Lutron or Kidde products (or this hub; I just grabbed it to do a teardown and share).

Really they probably could have got away with Zigbee, Z-Wave, BT, and WiFi and covered 90% of the same ground. The processor is a bit overkill, but considering this is their entry point with hopes of people buying more gadgets I’m sure they care less about margins here and more on other products.

So far, chips I’ve been able to ID are:

433Mhz (Kidde): PIC16F883 Microcontroller w/TI CC1101 RF Transceiver
433Mhz (Lutron): STM32L100R8 (ARM Cortex M3 @ 32Mhz w/64Kb Flash) w/same TI CC1101 RF Transceiver
Z-Wave: Sigma Designs SD3502A
Zigbee: Ember EM357 (Cortex M3 based SoC w/192Kb Flash and 12Kb RAM)
WiFi/BT: Unknown; Chip with markings “5408E3 E423B1”
Host CPU: Freescale i.MX28 @ 454Mhz
Ethernet: Part of PCB layout but not populated

Hub Front

Hub Back

UART

Zigbee

Z-Wave

WiFi + BT Combo

433Mhz (Kidde)

433Mhz (Lutron)

Anyway, no plans to switch from SmartThings by any means but it’s always interesting to see what’s out there and thought I’d share. I still have the hub if anyone bumps into the root password while browsing online and am more than willing to answer any questions!

Also, you can find the console boot log here.

[geko]

@cmonroe

I also find the 2 433Mhz radios to be a huge waste as 433Mhz signal doesn’t travel that far in the first place

Actually, 433 MHz propagation is better than 915 MHz or 2.4 GHz. The only downside is you need a bigger (and more expensive) antenna.

Including Lutron and Kidde radios is clearly a marketing trick to get wider industry support behind Wink. I think it’s a smart move. Combined with Home Depot distribution network this will give Wink a good chance to succeed in increasingly crowded Smart Home space.

[cmonroe]

Right, lower frequency, better penetration of solid objects (e.g. 5Ghz wireless won’t shoot through a canopy of trees but 900Mhz will just fine). I suppose it could be all of the 433Mhz equipment I’ve dealt with in the past; it was poorly made and range was junk (some devices barely made it 10ft while others made it 40-50 if you were lucky). The 433Mhz antennas are built well on this board though so coupled with the TI CC1101 transceiver maybe the range is ok.

Either way 1-2 technologies is plenty. I have almost all needs covered with Zigbee and Z-Wave alone… BLE would be nice but it’s still a new technology as far as I’m concerned. At the end of the day what’s important is the software; anyone can fry up a quick board and slap a bunch of radios on it; Quirky is a good year or more behind SmartThings in that realm (though ahead of many others who have tried so good for them for putting the effort in; it’s always nice to see choices).

[geko]

@cmonroe

Quirky is a good year or more behind SmartThings in that realm (though ahead of many others who have tried so good for them for putting the effort in

True, but ST may lose their advantage if they keep moving at snail’s pace. Wink definitely has more resources on both h/w and s/w development side and may close the gap rather quickly. In this field industry partnerships are going to be the key to success. Unfortunately, despite all the media attention ST got around CES early this year, I have not seen any major announcements.

[troykelly]

@geko

True, but ST may lose their advantage if they keep moving at snail’s pace

ST is loosing their advantage. For all the hot air @Ben expelled when I raised some issues, I’ve seen no progress in months.

[Ben (Ben Edwards)]

And here I was just going to send you a nice note, @troykelly Just because we don’t share our progress on many fronts doesn’t mean we are working at a snail’s pace. We are probably much faster than any other company in this space in innovating and adding product support to the platform. That is also bolstered by the openness of the platform that allows all of you to also extend the device support and rules (SmartApps) that suit your needs. If you really want to break it down, unless you want to use Vera, only Revolv has made headway in the rules engine space. Nest uses IFTTT, Wink doesn’t have rules. They are not legitimate options for home automation yet. I have no doubts they are moving in our direction but they will encounter all of the hurdles and challenges we have. Also if anything, we will be widening that gap very soon.

[geko]

@Ben

Also if anything, we will be widening that gap very soon.

That’s what I like to hear! Openness of ST’s cloud and rapidly growing device support are the most valuable propositions to me personally. On the other hand, to be relevant in the marketplace, ST needs to appeal to a wider audience who for the most part don’t care about ability to write their own apps. This is where ST is falling behind, IMHO.

[Ben (Ben Edwards)]

@geko

ST needs to appeal to a wider audience who for the most part don’t care about ability to write their own apps.

This will also be addressed soon.

[brianlees (Brian Smith)]

@Ben

This will also be addressed soon.

Me smells an announcement…hopefully soon!

[troykelly]

@Ben

And here I was just going to send you a nice note

@Ben, you should know me better than that I don’t need nice notes - I just need to know I am not wasting my energy.

I think what I am still yet to see is some of the engagement that we discussed offline. There was a brief period of responsiveness from ST, but it has dropped back to next to nothing.

I can’t see a community revolt on the horizon - but there is a growing pile of unanswered questions that really do need some attention.

[brianlees (Brian Smith)]

Although I was not party to @troykelly and @Ben 's “romantic dinner”, I can say that I have emailed support several times over the past two weeks or so and I get very, very quick responses. I realize you are talking about “other things”, but I don’t think it has dropped to next to nothing. Granted, I would like some more update posts on things. But, I know they are also going through a growth spurt, so I can understand having gone through the same craziness where I work!

Now, wasn’t this topic about a teardown or something?

[troykelly]

@brianlees

Now, wasn’t this topic about a teardown or something?

It was, and it was great!

Our romantic dinner was about a bunch of things - sockets, libraries etc. Most importantly it was about ST involvement in the forum. I completely agree support is typically very helpful - but we need more involvement here.

Sincere apologies to @cmonroe for my part in hijacking his thread. Thank you so much for taking the time to post this!

[brianlees (Brian Smith)]

Hopefully you at least got a good dinner out of it!

[cmonroe]

No worries @troykelly - part of this was about the ecosystem as a whole anyway. I agree with @Ben - consider what so many other home automation companies have claimed they are going to release or “demo’d” somewhere yet it’s never materialized. While I (myself as a consumer) don’t like being kept in the dark (e.g. Apple dark) I do appreciate the fact that SmartThings has a PR filter. At most companies the PR/marketing folks are dreaming up things the engineers laugh at (or even better, find out about by reading the companies own news feed).

Here when something is announced it’s usually ready or close to ready and it’s reasonable to say it will work well albeit a quirk or two. There are A LOT of devices out there and I (myself as an engineer) believe it’s better to support a subset of devices and do it damn well than support every device you can get your hands on. Already have support for 2-3 temperature sensors (and not just SmartThings sensors of course)? Great- move on to another category where there’s a void to be filled. You could spend months supporting 45 different temperature sensors to say you support the most number of devices but it’s not R&D money well spent. Are there holes in the ST lineup? Yes (heck there’s a thread about it right above this asking about device support not offered today with tons of input from SmartThings).

Irrigation controllers come to mind. I have my own built from a Spark Core and controlled from ST; would I have rather spent $30 on a pre-made one? Sure… point being updates come out incrementally here which is actually good (as in oh we support device X today and device Y two weeks later).

The reason people expect companies to move at more than a “snails pace” is 100% about perception in this case. If SmartThings held back every minor update for 1yr (like a new iPhone) you’d go nuts the day those updates hit the streets. Because they trickle out when ready it may feel like not a lot is happening. Sort of like the old analogy: throw a frog in boiling water and he’ll jump out; throw it in cold water and slowly warm it up and it never even notices. Either way work is being done (and at quite an astounding pace)… think of where we were 1yr ago. Could barely get the IDE and basic devices working. Flash forward to today where the IDE blows everything else out of the water and most every device I find a need to use works.

Make smart purchasing decisions when it comes to devices and it’s an amazing platform. It’s absolutely stupid to put a Lutron dimmer on 433Mhz in one room and an Aeon Micro (Z-Wave) in another. The look and feel of your house is not only out of whack but you are using two technologies and 2 products to do the same damn thing. Have a bug? Fix 2.

I made a conscious choice to utilize Aeon plug in modules as well as in-wall micros (40+ in my home). Guess what: they all use the same driver. Last time I had an issue it was as single 1-line fix, publish, bam problem fixed. Same concept applies to any line of devices. If you like 433Mhz Lutron gear or had it already, stick to it. It may be the engineering side of me talking but you’ve got to keep it simple or it will fail. Period.

[troykelly]

I am in violent agreement with you @cmonroe. The automation / intelligent home hardware sphere is full beyond the brim of people promising all sorts of things. ST are one of the few (only that I know) that actually deliver what they promise.

I’ve invested heavily in several platforms, most importantly of those was Ninja. Ninja is viciously guilty of (I am being polite) over promising and under delivering. I have giggled to myself a few times seeing complaints here about short lived outages. Over in NinjaBlocks land - these types of outages last days. (That said - the status and monitoring of ST could do with some love)

My core problem is integration. I’m happy to write and contribute, but I am working with both my hands tied behind my back. Not having sockets access is frustrating, but what makes it infuriating is not being able to get clear answers from ST.

I would dearly like to integrate with Elk/Ness M1, BitWise BC1, NuVo Amp’s, and a few other bits and pieces. But - not a single step can be taken towards any of this until there is some Hub based sockets access.

[cmonroe]

I couldn’t agree more @troykelly - on one hand I completely understand why SmartThings is designed the way it is but it drove me nuts the first time I wrote an app. I’m a simple guy… I write embedded C, maybe some Python… if you ask me to look at the world of all the web kits and toolkits and Java garbage there is out there today I just cringe. I’ve done more with a 50k line C daemon than guys who’ve duct taped together 14 different “awesome” libraries (which they know nothing about) and added 200k lines of glue code between them.

Point being I was pretty blown away when I got funny looks for asking if I could open a raw socket none the less I do understand it and who knows, maybe ST is working to improve this. On one hand it’s what appeals to me about the Spark Core: I’ve given them to hard core C guys (some of which defined many of the RFCs we follow today) and they instantly pick up and program cool stuff on the Spark. My learning curve was nil. They laughed when I showed them groovy, but started to come around slowly after seeing how powerful it is even crippled. That’s not a bad thing, just an observation. Both have different purposes and reasonings behind them.

ST is much more friendly to the end user; it was probably harder for me to learn to program for ST than it was to learn a new language like Ruby, but it is what it is and even with restrictions ST is very powerful. Maybe they could come up with some sort of either tiered system (e.g. like the old unix sysadmin days where you slowly get more rights over time as the admin trusts you not to rm -Rf / haha)… something where each account can be granted permissions to do certain things. Basic accounts do basic things, others are allowed to manipulate sockets, etc… more management overhead but I guarantee there’d be a lot more coming out of the community as it would widen the audience appeal.

On the other hand ST has to stay safe and stable… you mentioned Ninja being down for days; that would be catastrophic if it happened here. It’s all stuff that can be built in over time and I have no doubt they are likely working on improvements but I do share the common thread here and that’s the necessity for deeper access into the system to perform more complicated integrations.

[Mbhforum (Marc)]

I agree with @Ben. My co worker has a Vera and is extremely frustrated with the lack of innovation and their controller is DOUBLE the price. The Revolv is TRIPLE the price. I am happy with ST’s pace and do like the direction they are headed. I have recently given up my Wemo’s and Kevo lock and have gone all in with zWave stuff as the point solutions weren’t innovating enough.

[lbarrosoneto (Luiz O Neto)]

I get slightly different boot messages and no prompt in the end
Could also not find how to show u-boot prompt.
Hub was already initialized, added to account and upgraded…

" 
U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)

CPU:   Freescale i.MX28 rev1.2 at 454 MHz
BOOT:  NAND, 3V3
DRAM:  64 MiB
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   FEC0 [PRIME]
Hit any key to stop autoboot:  0 
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=3"
UBI: MTD device size:            8 MiB
UBI: number of good PEBs:        64
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             6
UBI: total number of reserved PEBs: 58
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 3/2
UBIFS: recovery needed
UBIFS: recovery deferred
UBIFS: mounted UBI device 0, volume 0, name "database"
UBIFS: mounted read-only
UBIFS: file system size:   5459968 bytes (5332 KiB, 5 MiB, 43 LEBs)
UBIFS: journal size:       1015809 bytes (992 KiB, 0 MiB, 6 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root:  269835 bytes (263 KiB)
Loading file 'DO_UPDATE' to addr 0x42000000 with size 1 (0x00000001)...
Done
Total of 1 word(s) were the same

NAND read: device 0 offset 0x2b00000, size 0x400000
 4194304 bytes read: OK
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   Linux-2.6.35.3-flex-dvt
   Created:      2014-04-30   3:15:35 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1928460 Bytes = 1.8 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.35.3-flex-dvt (saurabh@localhost.localdomain) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #32 PREEMPT Tue Apr 29 23:15:31 EDT 2014
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Freescale MX28EVK board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60784k/60784k available, 4752k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xfde00000 - 0xffe00000   (  32 MB)
    vmalloc : 0x84800000 - 0xf0000000   (1720 MB)
    lowmem  : 0x80000000 - 0x84000000   (  64 MB)
    modules : 0x7f000000 - 0x80000000   (  16 MB)
      .init : 0x80008000 - 0x80027000   ( 124 kB)
      .text : 0x80027000 - 0x803b6000   (3644 kB)
      .data : 0x803b6000 - 0x803deec0   ( 164 kB)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
	RCU-based detection of stalled CPUs is disabled.
	Verbose stalled-CPUs detection is disabled.
NR_IRQS:288
Console: colour dummy device 80x30
console [ttyAM0] enabled
Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
regulator: core version 0.5
NET: Registered protocol family 16
regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal 
regulator: vdddbo: 800 <--> 1575 mV fast normal 
regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal 
vddio = 3380000, val=10
regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast normal 
regulator: overall_current: fast normal 
regulator: vbus5v: 
regulator: mxs-duart-1: fast normal 
regulator: mxs-bl-1: fast normal 
regulator: mxs-i2c-1: fast normal 
regulator: mmc_ssp-1: fast normal 
regulator: mmc_ssp-2: fast normal 
regulator: charger-1: fast normal 
regulator: power-test-1: fast normal 
regulator: cpufreq-1: fast normal 
i.MX IRAM pool: 124 KB@0x84820000
Initializing GPMI pins
bio: create slab  at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Calling CRDA to update world regulatory domain
Switching to clocksource mxs clock source
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
Bus freq driver module loaded
mxs_cpu_init: cpufreq init finished
Slow work thread pool: Starting up
Slow work thread pool: Ready
fuse init (API version 7.14)
msgmni has been set to 118
alg: No test for stdrng (krng)
cryptodev: driver loaded.
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
mxs-duart.0: ttyAM0 at MMIO 0x80074000 (irq = 47) is a DebugUART
mxs-auart.0: ttySP0 at MMIO 0x8006a000 (irq = 112) is a mxs-auart.0
Found APPUART 3.1.0
mxs-auart.1: ttySP1 at MMIO 0x8006c000 (irq = 113) is a mxs-auart.1
Found APPUART 3.1.0
mxs-auart.2: ttySP2 at MMIO 0x8006e000 (irq = 114) is a mxs-auart.2
Found APPUART 3.1.0
mxs-auart.3: ttySP3 at MMIO 0x80070000 (irq = 115) is a mxs-auart.3
Found APPUART 3.1.0
mxs-auart.4: ttySP4 at MMIO 0x80072000 (irq = 116) is a mxs-auart.4
Found APPUART 3.1.0
loop: module loaded
i.MX GPMI NFC
NFC: Version 1, 8-chip GPMI and BCH
Boot ROM: Version 1, Single-chip boot area, block mark swapping supported
Scanning for NAND Flash chips...
NAND device: Manufacturer ID: 0x01, Chip ID: 0xf1 (AMD NAND 128MiB 3,3V 8-bit)
-----------------------------
NAND Flash Device Information
-----------------------------
Manufacturer      : AMD (0x01)
Device Code       : 0xf1
Cell Technology   : SLC
Chip Size         : 128 MiB
Pages per Block   : 64
Page Geometry     : 2048+64
ECC Strength      : 4 bits
ECC Size          : 512 B
Data Setup Time   : 10 ns
Data Hold Time    : 5 ns
Address Setup Time: 10 ns
GPMI Sample Delay : 6 ns
tREA              : Unknown
tRLOH             : Unknown
tRHOH             : Unknown
Description       : S34ML01G1
-----------------
Physical Geometry
-----------------
Chip Count             : 1
Page Data Size in Bytes: 2048 (0x800)
Page OOB Size in Bytes : 64
Block Size in Bytes    : 131072 (0x20000)
Block Size in Pages    : 64 (0x40)
Chip Size in Bytes     : 134217728 (0x8000000)
Chip Size in Pages     : 65536 (0x10000)
Chip Size in Blocks    : 1024 (0x400)
Medium Size in Bytes   : 134217728 (0x8000000)
------------
NFC Geometry
------------
ECC Algorithm          : BCH
ECC Strength           : 8
Page Size in Bytes     : 2112
Metadata Size in Bytes : 10
ECC Chunk Size in Bytes: 512
ECC Chunk Count        : 4
Payload Size in Bytes  : 2048
Auxiliary Size in Bytes: 16
Auxiliary Status Offset: 12
Block Mark Byte Offset : 1999
Block Mark Bit Offset  : 0
-----------------
Boot ROM Geometry
-----------------
Boot Area Count            : 1
Boot Area Size in Bytes    : 3145728 (0x300000)
Stride Size in Pages       : 64
Search Area Stride Exponent: 2
Scanning device for bad blocks
Boot area protection is enabled.
Creating 6 MTD partitions on "gpmi-nfc-main":
0x000000000000-0x000000300000 : "gpmi-nfc-0-boot"
0x000000300000-0x000000700000 : "updater-kernel"
0x000000700000-0x000002300000 : "updater-rootfs"
0x000002300000-0x000002b00000 : "database"
0x000002b00000-0x000003300000 : "app-kernel"
0x000003300000-0x000008000000 : "gpmi-nfc-general-use"
cmdlinepart partition parsing not available
UBI: attaching mtd5 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd5 to ubi0
UBI: MTD device name:            "gpmi-nfc-general-use"
UBI: MTD device size:            77 MiB
UBI: number of good PEBs:        616
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 616
UBI: number of PEBs reserved for bad PEB handling: 6
UBI: max/mean erase counter: 5/1
UBI: image sequence number: 1715806998
UBI: background thread "ubi_bgt0d" started, PID 922
 ubiblka: unknown partition table
mice: PS/2 mouse device common for all mice
MXS RTC driver v1.0 hardware v2.3.0
mxs-rtc mxs-rtc.0: rtc core: registered mxs-rtc as rtc0
mxs watchdog: initialized, heartbeat 19 sec
mxs-mmc: MXS SSP Controller MMC Interface driver
__mxs_reset_block(f0010000): timeout when resetting
__mxs_reset_block(f0010000): timeout when resetting
__mxs_reset_block(f0010000): timeout when resetting
__mxs_reset_block(f0010000): timeout when resetting
__mxs_reset_block(f0010000): timeout when resetting
mxs-mmc mxs-mmc.0: mmc0: MXS SSP MMC DMAIRQ 82 ERRIRQ 96 
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
lib80211: common routines for IEEE802.11 drivers
mxs-rtc mxs-rtc.0: setting system clock to 1970-01-01 00:00:05 UTC (5)
mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
mmc0: queuing unknown CIS tuple 0x80 (6 bytes)
mmc0: new high speed SDIO card at address 0001
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: file system size:   75550720 bytes (73780 KiB, 72 MiB, 595 LEBs)
UBIFS: journal size:       9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: zlib
UBIFS: reserved for root:  0 bytes (0 KiB)
VFS: Mounted root (ubifs filesystem) on device 0:11.
Freeing init memory: 124K
Starting logging: OK
Initializing random number generator... done.
Starting bluetooth...
Loading modules backported from Linux version v3.13.2-0-gfd82174
Backport generated by backports.git v3.13.2-1-0-gaef13bc
Bluetooth: 83f6bf04
NET: Registered protocol family 31
Bluetooth: 83f6bf04
Bluetooth: 83f6beec
Bluetooth: 83f6bedc
Bluetooth: 83f6beec
Bluetooth: 83ff1f04
Bluetooth: 83ff1eec
Bluetooth: 83ff1eecDone setting line discpline
Starting system message bus: done

UBI: attaching mtd3 to ubi1
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd3 to ubi1
UBI: MTD device name:            "database"
UBI: MTD device size:            8 MiB
UBI: number of good PEBs:        64
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             6
UBI: total number of reserved PEBs: 58
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 3/2
UBI: image sequence number: 0
UBI: background thread "ubi_bgt1d" started, PID 1004
 ubiblkb: unknown partition table
UBI device number 1, total 64 LEBs (8126464 bytes, 7.8 MiB), available 6 LEBs (761856 bytes, 744.0 KiB), LEB size 126976 bytes (124.0 KiB)
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 1, volume 0, name "database"
UBIFS: file system size:   5459968 bytes (5332 KiB, 5 MiB, 43 LEBs)
UBIFS: journal size:       1015809 bytes (992 KiB, 0 MiB, 6 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: lzo
UBIFS: reserved for root:  257887 bytes (251 KiB)
app_boot=run appboot_args && nand read ${loadaddr} app-kernel 0x00400000 && bootm ${loadaddr}
app_boot_bad=run updater_args; setenv bootargs ${bootargs} badapp; nand read ${loadaddr} updater-kernel 0x00400000; bootm ${loadaddr}
boot_app=run app_boot || run app_boot_bad
cat: can't open '/database/cf_url': No such file or directory
Starting network...
Starting wifi network...
DHD: dongle ram size is set to 524288(orig 524288) at 0x0
dhd_bus_init: enable 0x06, ready 0x06 (waited 0us)
dhd_wlfc_init(): successfully enabled bdcv2 tlv signaling, 79
wlan0: Broadcom Dongle Host Driver

Dongle Host Driver, version 1.88.64 (r447771)
Successfully initialized wpa_supplicant
rfkill: Cannot open RFKILL control device
Starting dropbear sshd: + FILE=/tmp/isalive
+ sleep 90
OK
Starting lighttpd: OK
Starting Zigbee...Starting lutron-core...Reset info: 11 (SOFTWARE)
ezsp ver 0x04 stack type 0x02 stack ver. [5.1.0 GA build 49]
Ezsp Config: set max end device children to 0x0006:Success: set
Ezsp Config: set binding table size to 0x0002:Success: set
Ezsp Config: set source route table size to 0x0064:Success: set
Ezsp Config: set security level to 0x0005:Success: set
Ezsp Config: set address table size to 0x00FA:Success: set
Ezsp Config: set TC addr cache to 0x0004:Success: set
Ezsp Config: set stack profile to 0x0002:Success: set
Ezsp Config: set MAC indirect TX timeout to 0x1E00:Success: set
Ezsp Config: set max hops to 0x001E:Success: set
Ezsp Config: set key table size to 0x0000:Success: set
Ezsp Config: set tx power mode to 0x8000:Success: set
Ezsp Config: set supported networks to 0x0001:Success: set
Ezsp Policy: set binding modify to "allow for valid endpoints & clusters only":Success: set
Ezsp Policy: set message content in msgSent to "return":Success: set
Ezsp Value : set maximum incoming transfer size to 0x000000FF:Success: set
Ezsp Value : set maximum outgoing transfer size to 0x000000FF:Success: set
Ezsp Config: set Fragmentation RX window size to 0x0001:Success: set
NCP supports maxing out packet buffers
Ezsp Config: set packet buffers to 89
Ezsp Config: set Fragmentation RX window size to 0x0001:Success: set
Ezsp Endpoint 1 added, profile 0x0104, in clusters: 3, out clusters 19
Ezsp Policy: set TC Key Request to "Deny":Success: set
Ezsp Policy: set App. Key Request to "Allow":Success: set
Ezsp Policy: set Trust Center Policy to "Allow preconfigured key joins":Success: set
Found 0 files

main: flxOs Initialize success!
zbServer_Initialize: Ipc Server Initialization success! 
zbServer_Initialize: Ipc Server Open success! 
main: zbServer Initialize success!
EMBER_NETWORK_UP 0x0000
IpcServerSendMessage: send error
emberAfStackStatusCallback: error on IPC send 
emberAfStackStatusCallback: send complete 
The app framework is handling the stack status.
FlexCI>[ OK ]
Starting aprond...wlan0 (WE) : Wireless Event too big (65306)
wlan0 (WE) : Wireless Event too big (65306)
wlan0: Trying to associate with  (SSID='xxxxx' freq=2422 MHz)
wlan0: Associated with 
wlan0: WPA: Key negotiation completed with  [PTK=CCMP GTK=CCMP]
wlan0: CTRL-EVENT-CONNECTED - Connection to  completed [id=0 id_str=]
+ IFACE=wlan0
+ EVENT=CONNECTED
+ case $EVENT in
+ echo 'Received event: CONNECTED'
Received event: CONNECTED
+ set_rgb 127 83 0 0 0 0 flash 500000
+ udhcpc -i wlan0 -t 15 -b
udhcpc (v1.22.1) started
+ exit 0
Sending discover...
Sending select for 192.168.15.115...
Lease of 192.168.15.115 obtained, lease time 86400
dhd_aoe_hostip_clr failed code -23
aoe_update_host_ipv4_table failed
deleting routers
adding dns 8.8.8.8
adding dns 8.8.4.4
adding dns 192.168.15.3
15 Jul 03:10:16 ntpdate[1174]: adjust time server 128.10.19.24 offset -0.003747 sec
Got Z-Wave version: Z-Wave 3.79
[ZWAVE OK]


1195.1] main() (Main|apron.c:48): APRON Home Automation Gateway version 1.2.7038 Starting ...
IpcServerAcceptLoop: accept() success!
IpcServerAcceptLoop: Ipc Server running in event-loop mode
Starting Wink...Starting monit...-----Ipc Server Received message-----
seqNum: 0
msgType: C
Processing ZB_NETWORK_STATUS_CMD
-----Ipc Server Received message-----
seqNum: 1
msgType: C
Processing ZB_FIND_UNUSED_NETWORK_CMD
zbUtil_FindUnusedNetwork: network form success!
Starting monit daemon
hub[1201]: NOTICE: (hub.c:298) hub-dev started up by User: 0
hub[1201]: INFO: (ConfigHandler.c:92) Reading Congif from: /root/config/hub.conf
hub[1201]: INFO: (hub.c:331) oauth exists, sleeping for 1
hub[1201]: INFO: (hubCurl.c:383) Token: xxxxxx
hub[1201]: INFO: (hubCurl.c:299) curlGet: https://hub-api.winkapp.com:8080/socket
hub[1201]: INFO: (hubCurl.c:300) token Authorization: Bearer xxxxxx
hub[1201]: INFO: (hubCurl.c:311) Connecting With Cert: /root/config/ca1-cert.pem
> GET /socket HTTP/1.1
User-Agent: curl/7.32.0
Host: hub-api.winkapp.com:8080
Accept: */*
Content-Type: application/json
Authorization: Bearer xxxxxxx

< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 87
< Date: Tue, 15 Jul 2014 03:10:20 GMT
< Connection: keep-alive
< 
hub[1201]: INFO: (hubCurl.c:364) 87 get bytes retrieved
hub[1201]: DEBUG: (hubCurl.c:109) Read Socket Memory {"accessToken":"}
hub[1201]: INFO: (hubCurl.c:399) Authentication: 
Connected with AES256-SHA encryption
Server certificates:
Subject: /C=US/ST=NY/L=New York/O=Wink/OU=Wink Hub Agent/CN=hub-api.winkapp.com/emailAddress=ca@winkapp.com
Issuer: /C=US/ST=NY/L=New York/O=Wink/OU=Wink Certificate Authority/CN=ca.winkapp.com/emailAddress=ca@winkapp.com
hub[1201]: INFO: (hub.c:170) Connected to Socket
connect() failed: No such file or directory
connect() failed: No such file or directory
hub[1201]: INFO: (hub.c:193) Setting up Threads
hub[1201]: INFO: (hub.c:208) Threads Setup
hub[1201]: DEBUG: (hub.c:143) nonce: 4294967280
Inside runRadioThread
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: authenticate
Run Command Line Thread Thread
hub[1201]: INFO: (readThread.c:10) Running Read Thread
hub[1201]: INFO: (writeThread.c:34) Spooled up Radio Thread
hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: authenticate Size: 61
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (pingSocketThread.c:34) Running Ping Thread
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 8, 3, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 8
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: receipt
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: receipt
hub[1201]: INFO: (mainThread.c:37) Received Receipt With Topic:4294967280
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 24, 2, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 24
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: status
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 6, 21, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 6
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: subscribeToType
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 6, 21, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 6
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: subscribeToType
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: status
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 6, 21, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 6
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: subscribeToType
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 6, 21, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 6
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: subscribeToType
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 6, 34, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 6
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: getVersionInfo
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 8, 5, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 8
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: get_devices
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 18, 29, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 18
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: ping
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967281
hub[1201]: INFO: (mainThread.c:30) Received Status: Authenticated Code: 200 Topic: -16
hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: receipt Size: 28
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: subscribeToType
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967282
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: subscribeToType
hub[1201]: DEBUG: (radioThread.c:1093) Cassette in Radio Thread: subscribeToType
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967283
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: subscribeToType
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967284
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: subscribeToType
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967285
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: getVersionInfo
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967286
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: get_devices
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967287
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: ping
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967288
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Entered Subscribed...
Done Sending Cassette

hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: receipt Size: 28
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: receipt Size: 28
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: receipt Size: 28
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully


1201.1] apronRegisterCallback() (SdkClient|sdk.c:829): SDK Registering callback...
Error writing to client: Bad file descriptor
Done Sending Cassette

hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: receipt Size: 28
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: receipt Size: 28
hub[1201]: INFO: (radioThread.c:719) wkp_subscribe: subscribed to device type: 0
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: receipt Size: 28
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: receipt Size: 28
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967289
hub[1201]: DEBUG: (radioThread.c:1093) Cassette in Radio Thread: subscribeToType
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: status
Entered Subscribed...


1201.1] apronRegisterCallback() (SdkClient|sdk.c:829): SDK Registering callback...
hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: status Size: 59
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

Error writing to client: Bad file descriptor
hub[1201]: INFO: (radioThread.c:719) wkp_subscribe: subscribed to device type: 1
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967290
hub[1201]: DEBUG: (radioThread.c:1093) Cassette in Radio Thread: subscribeToType
Entered Subscribed...


1201.1] apronRegisterCallback() (SdkClient|sdk.c:829): SDK Registering callback...
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: status
hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: status Size: 59
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

Error writing to client: Bad file descriptor
hub[1201]: INFO: (radioThread.c:719) wkp_subscribe: subscribed to device type: 2
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967291
hub[1201]: DEBUG: (radioThread.c:1093) Cassette in Radio Thread: subscribeToType
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: status
Entered Subscribed...


1201.1] apronRegisterCallback() (SdkClient|sdk.c:829): SDK Registering callback...
Error writing to client: Bad file descriptor
hub[1201]: INFO: (radioThread.c:719) wkp_subscribe: subscribed to device type: 3
hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: status Size: 59
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967292
hub[1201]: DEBUG: (radioThread.c:1093) Cassette in Radio Thread: getVersionInfo
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: status
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (VersioningUtil.c:81) Reading Versioning from: cf_build
hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: status Size: 59
hub[1201]: INFO: (VersioningUtil.c:81) Reading Versioning from: cf_fver0
hub[1201]: WARNING: (VersioningUtil.c:90) Could not open: cf_fver0
hub[1201]: INFO: (VersioningUtil.c:81) Reading Versioning from: cf_fver1
hub[1201]: WARNING: (VersioningUtil.c:90) Could not open: cf_fver1
hub[1201]: INFO: (VersioningUtil.c:81) Reading Versioning from: cf_fver2
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (VersioningUtil.c:81) Reading Versioning from: cf_fver3
hub[1201]: DEBUG: (radioThread.c:1045) Version: 00.01,0,0,00.01,00.19,34:23:BA:EB:0A:C1,192.168.15.115
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967293
hub[1201]: DEBUG: (radioThread.c:1093) Cassette in Radio Thread: get_devices
Get Deveice Recieved

There are 1 devices
	Device Index: 1 Device Name: New POWER_SWITCH_BINARY
hub[1201]: DEBUG: (MessageSystem.c:217) nonce: 4294967294
hub[1201]: DEBUG: (radioThread.c:1093) Cassette in Radio Thread: ping
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: versionInfo
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: devices
hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: versionInfo Size: 83
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: INFO: (writeThread.c:14) Writing Cassette to Socket: devices Size: 62
hub[1201]: DEBUG: (writeThread.c:20) Cassette Sent Successfully
Done Sending Cassette

hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 8, 3, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 8
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: receipt
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: receipt
hub[1201]: INFO: (mainThread.c:37) Received Receipt With Topic:4294967289
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 8, 3, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 8
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: receipt
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 8, 3, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 8
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: receipt
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 8, 3, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 8
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: receipt
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: receipt
hub[1201]: INFO: (mainThread.c:37) Received Receipt With Topic:4294967290
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: receipt
hub[1201]: INFO: (mainThread.c:37) Received Receipt With Topic:4294967291
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: receipt
hub[1201]: INFO: (mainThread.c:37) Received Receipt With Topic:4294967292
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 8, 3, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 8
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: receipt
hub[1201]: DEBUG: (hubSocket.c:279) Read Struct Bytes 20
hub[1201]: DEBUG: (hubSocket.c:287) Header size: 8, 3, 0
hub[1201]: DEBUG: (hubSocket.c:299) Body Bytes 8
hub[1201]: INFO: (readThread.c:28) Read Cassette From Socket: receipt
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: receipt
hub[1201]: INFO: (mainThread.c:37) Received Receipt With Topic:4294967293
hub[1201]: DEBUG: (mainThread.c:122) Cassette in Main Thread: receipt
hub[1201]: INFO: (mainThread.c:37) Received Receipt With Topic:4294967294
set state to: 0x0B04
security init TC: 0x70
Forming on ch 15, panId 0xB89B
Form error 0x70 aborting
Scan error 0x70
Network find complete (scan error).
Setting non-canonical mode
Startup complete.
" 
 

[vitamincm (Christopher Masiello)]

Any chance that SmartThings could control this hub in the same way they do the Phillips Hue and TCP hubs? This would be a quick way to get BlueTooth capabilities into SmartThings. There are so many cool BT devices coming out that would augment my Slightly Above Average Intelligence home into and actual Smart Home.

[voltagex (Adam Baxter)]

http://dc22.gtvhacker.com/index.php/Wink_Hub​​