Thingsquare

This is a few years old and leaves out 6LoWPAN[1], which wasn't yet commercially viable. 6LoWPAN is based on the same 802.15.4 hardware that ZigBee uses, but it has two significant advantages over ZigBee. First, it is TCP/IP that works on microcontrollers, so embedded devices running the protocol become first-class members of the internet with the addition of a very inexpensive router[2] to the network. This means that sensor nodes and embedded devices can seamlessly interoperate with traditional servers in a distributed computing environment and many programming techniques can be directly adapted.

Second, 6LoWPAN can be configured so that all nodes involved can sleep, whereas ZigBee requires always-on routing nodes in order to produce a true mesh. This means it isn't possible to use ZigBee to construct a mesh out of fungible battery-powered devices, which is a big problem for many applications.

If this interests you, there are a couple of very capable chips that have been released recently that are ideal for use with 6LoWPAN, namely TI's CC2538 [3] and Atmel's SAM R21 [4]. They both are supported by Contiki OS[5], which provides network stacks for extremely resource-constrained devices. It has been under development for ~10 years at this point as an open source academic/hobby project but in the last couple of years it has become significantly more professional and it is now used in many commercial applications. In addition, its core architects have launched a company…

Well sure, a hardware company isn't going to buy this. Check their pricing page.

http://www.thingsquare.com/start/

This is the Arduino business model-- easy introductory hardware for beginners. An actual hardware company wouldn't buy these for the same reason a router company wouldn't buy Cisco hardware and tape over the logos: there wouldn't be any margin.

I would characterize GGP's argument as more that this isn't unprecedented, and again, sure. Lithium cell-powered electronics have been around for decades, adding wireless isn't new. The point is that thingsquare is supposed to be easy. You buy their kit and press a button. You don't need to buy individual parts, or do assembly, or write glue code, or know what I2C is.

This is a common disease of the engineer's mind. "Why does anybody buy a car new? Just buy one used, and replace parts yourself when they break! Heck, why buy parts, when they're just metal and electronics? It should be easy enough to do your own aluminum casting, and wind your own electric motors." "You fool, you buy aluminum? Bauxite is everywhere! Just smelt it yourself, it's not hard." Etc etc.

This seems a lot like a response to Google's Nest acquisition.

Google and Apple are rapidly moving in to an area with a lot of activity. There has been a recent surge of home automation startups and platforms like Revolv (http://revolv.com/), SmartThings (http://www.smartthings.com/), WigWag (http://www.wigwag.com/). One of the problems they are addressing is how to marge multiple different home automation standards (Z-Wave, ZigBee, Bluetooth Smart, 6LoWPAN). Presumably the new Apple HomeKit will be based on a single standard, Bluetooth Smart, given the Apple / iBeacon rollout.

There are also a bunch of more generic development platforms around, like relayr (http://relayr.io/) and Thingsquare (http://www.thingsquare.com/), that are targeting the device manufacturers directly. Will be interesting to see what impact Apple will have on the growth of this market, and the technology choices. Apple isn't always right (and neither is Google).

Although this is pretty far away from the Arduino-style boards, you may want to have a look at the Sensortag from Texas Instruments: http://www.ti.com/sensortag

It is based on a single-chip wireless microcontroller that has both support for both BLE and IEEE 802.15.4 (6lowpan/ZigBee). It is supported by the Contiki OS (http://www.contiki-os.org/). The learning curve is probably quite a bit steeper than that of an Ardiuno, but the board and the chip can be readily included in commercial products. There are reference designs with design files, BOMs, schematics available from TI.

Since it has both BLE and 6lowpan support, you can do some pretty nice things with it, such as providing both quick discovery via smartphones and secure remote access: http://www.thingsquare.com/blog/articles/proximity-control/

> Also, why would you bother to handle it gracefully when the OS won't allow you to do it?

There are many situations where you can get an allocation failure even with over provisioning enabled.

> Just don't use VLAs if then? "Problem" solved.

Yes, just don't use that language feature that is visually identical to a normal array. Then make sure that your standard library implementation doesn't have random malloc calls hidden in functions that cannot communicate an error and abort instead https://www.thingsquare.com/blog/articles/rand-may-call-malloc/. Then ensure that your dependencies follow the same standards of handling allocation failures ... .

I concede that it might be possible, but you are working against an ecosystem that is actively trying to sabotage you.

Yes, a transmit-only approach would be the most power-saving approach here, but you'd lose the ability to adjust configuration on-the-fly, and firmware updates over the air (FOTA), among other things. LoRa has excellent long-range properties thanks to sub-GHz, modulation, and low bit-rate, but you can just barely send something back to it and certainly not FOTA it.

The device used in the example post (and here: http://www.thingsquare.com/blog/articles/sensortag-power/ ) doesn't route even if part of a mesh. Ie, it's powered down for the most part so won't route packets for others, but it can still be many hops away from the gateway.