-- Production delays --
I waited almost a year longer than expected to get my unit. Because I just wanted to tinker I wasn't bothered. Ninja Blocks say their units are manufactured, just waiting for the enclosures. This might not be a problem for them.
-- Battery eaters --
Twine eats batteries like nobodies business. Two AA batteries last about two weeks. On the forums this seems like the typical experience. Ninja Blocks looks as if the central 'Ninja Block' can be mains powered. But will the wireless sensors have a short battery life?
-- Web app --
Twine has a website that the device must communicate with to report data and push rules to it. There's no (out-of-the-box) way to get it to talk to a local server via a clean API.
This was a big disappointment for me mainly because their web app is very limited:
- No data logging (just reports the latest figure)
- Rules can just be triggered over thresholds (ie when temperature reaches 20c then X) not when temperature changes
- For moisture the actual resistance isn't reported, just a wet or dry condition. This renders it useless for plant watering.
Twine can make a HTTP request when a rule is tripped. I plan to play with this but it's not that useful if it can't just HTTP request every time a value changes as I wanted to log temperature (plus it's a GET!).
The Ninja Blocks apps look better and appear to fill the gap between reading something then doing something. Twine can really only report something (twitter/sms/email/HTTP supported). But I'd caution that until you get your hands a device like this you don't know of its true limitations.
-- Sensors --
I didn't up my kickstarter amount when they announced new sensors. I wish I had, as only the temperature sensor is nearly useful. The other built in sensor is orientation... ? IMHO they should've thrown in the other sensors and maybe upped the price to increase satisfaction.
I prefer the sensor pack that ships by default with Ninja Blocks.
In spite of the above I'm optimistic about Twine as it really is early days. This space has massive potential if it can break out of communities like ours into the mainstream. I just hope Supermechanical doesn't get distracted and focusses squarely on their flagship product.
Ninja Blocks? I won't be ordering but will keep a close eye on what those who receive the first units think. Their approach so far seems to be a better path to market than Twine's crowdfunding and their presentation superior.
hey @drism - we are still waiting for our twines here in Aus. You make some excellent points.
-- Production delays -- this is our second go around, we had a kickstarter back in March and it was late (and not a great product to be honest). We learnt a lot this time around and ponied up for a small run. We were "sure" we would ship in December when started taking orders on the 11th (of Dec). Alas, Murphy hates us. Final assembly http://www.youtube.com/watch?v=ZQKQw-YXyjA is happening now. Bleeding into the holidays has cost us a couple of weeks, 15th Jan is about as iron clad as anything can ever be thats outsourced to Shenzhen.
-- Battery eaters -- the block (a beagle bone + arduino cape) ships with a 3A switching power supply - no messing around. The 433 sensors are off the shelf items you find in low end security systems. They use most of their power when they transmit (which isn't that often) and (whilst not tested) we estimate the batteries will last a long time.
-- Web app -- We have a web app that lets you see live data and make simple rules. As you have probably figured out with Twine. Whilst that is fun and sometimes useful but pretty limiting. We think making your devices available to third party apps via OAuth is going to make things much more interesting!
We have mountains left to do, but we already have:
- inbound and outbound webhooks, which enable simple integrations with stuff like Zapier or Tasker no code affairs.
- a fully featured API that we use for everything, i.e. not an afterthought- see http://docs.ninja.is - separate interfaces for creating user land apps and devices
- OAuth2
- Open source client (currently being refactored to support third-party modules a la npm/gems/etc) - see the "release-two" branch https://github.com/ninjablocks/client
-- Sensors - lol re-orientation, we had an accelerometer in our kickstarter block which was removed precisely because no one used it. Pretty much the first time I found an real world use was for our friday afternoon rube goldberg machine http://youtu.be/jPE_M0ciCYI (beware shaky cam, but we weren't doing another take)
We really wanted to support remote controlling power sockets as soon as possible, but at a reasonable price. That eventually led us down the path of 433 as the only globally available option. Insteon, Z-wave, even Zigbee are "better" technically - but they are 50-100 per socket vs 10-20. We've secured a CE certified supplier for Europe and Australia and will be reselling soon for $12 a piece. There are ok options on Amazon for the US and we are lining up something for the UK - we can't justify the MOQ just yet.
We opted for off the shelf sensors the second time around for a whole bunch of reasons (see above). Cost, availability, but mostly because hardware is hard and oh so slow - especially for software guys. Note that we think the value is in wrapping everything, especially all these awesome kickstarter/indiegogo wifi devices that will probably have average APIs (no offense, but hardware guys just don't seem to grok APIs or auth - think wemo ... LAN only undocumented SOAP, really?)
There are important things we need to tick off - the huge one being severing the link to the mother ship. Currently all logic lives in AWS, thats not acceptable long term. Unlike some of the people in this space, we want our users to connect to our service because it adds awesome value through an ecosystem, not because you dropped a bundle on their hardware which requires it.
Important note - you can already make your own devices. We've got an Arduino Ethernet library that runs on a 328p (that's 2k of memory for the uninitiated) https://github.com/ninjablocks/arduino-ninja-blocks. There is even a browser implementation that uses cors https://github.com/ninjablocks/browser-ninja-blocks. Of courese you can run our official client (git link above) on anything that supports Node.js or just use the REST interface to make anything with http a device.
Sorry about the verbal diarrhoea - midnight Saturday in Sydney :/. I certainly don't want to suggest that the Ninja platform is all sunshine and lollipops today. However, if you a software hacker and want a real API for things. That's where we are going and we'd love for you to come along for the ride ;)
" Zigbee are "better" technically - but they are 50-100 per socket vs 10-20. "
Again - way off base here - please do your homework. A plug-in on-off socket can be had for under $30 (http://www.ebay.com/itm/Wayne-Dalton-HA-02WD-Wireless-Small-...). The cheap 433MHz argument goes out the window very quickly if you know what you're doing.
I've said it multiple times in this thread - you get what you pay for. The 433MHz (not Mhz) gear is non-mesh. If you don't currently have home automation I wouldn't expect someone to realize how much of a key this is to a reliable and useful system. But, go ahead - try running more than a dozen 433MHz devices on a controller - it's going to be unreliable and have restrictions based on proximity to the controller which will depend on the NinjaBlocks RF design as well of each of the individual plugs RF design. For $3, I bet it's stellar!
-- Production delays -- I waited almost a year longer than expected to get my unit. Because I just wanted to tinker I wasn't bothered. Ninja Blocks say their units are manufactured, just waiting for the enclosures. This might not be a problem for them.
-- Battery eaters -- Twine eats batteries like nobodies business. Two AA batteries last about two weeks. On the forums this seems like the typical experience. Ninja Blocks looks as if the central 'Ninja Block' can be mains powered. But will the wireless sensors have a short battery life?
-- Web app -- Twine has a website that the device must communicate with to report data and push rules to it. There's no (out-of-the-box) way to get it to talk to a local server via a clean API.
This was a big disappointment for me mainly because their web app is very limited: - No data logging (just reports the latest figure) - Rules can just be triggered over thresholds (ie when temperature reaches 20c then X) not when temperature changes - For moisture the actual resistance isn't reported, just a wet or dry condition. This renders it useless for plant watering.
Twine can make a HTTP request when a rule is tripped. I plan to play with this but it's not that useful if it can't just HTTP request every time a value changes as I wanted to log temperature (plus it's a GET!).
The Ninja Blocks apps look better and appear to fill the gap between reading something then doing something. Twine can really only report something (twitter/sms/email/HTTP supported). But I'd caution that until you get your hands a device like this you don't know of its true limitations.
-- Sensors -- I didn't up my kickstarter amount when they announced new sensors. I wish I had, as only the temperature sensor is nearly useful. The other built in sensor is orientation... ? IMHO they should've thrown in the other sensors and maybe upped the price to increase satisfaction.
I prefer the sensor pack that ships by default with Ninja Blocks.
In spite of the above I'm optimistic about Twine as it really is early days. This space has massive potential if it can break out of communities like ours into the mainstream. I just hope Supermechanical doesn't get distracted and focusses squarely on their flagship product.
Ninja Blocks? I won't be ordering but will keep a close eye on what those who receive the first units think. Their approach so far seems to be a better path to market than Twine's crowdfunding and their presentation superior.