In Australia, central heating/cooling is rare and high-end - in most places cooling matters much more than heating. The most common climate control method by far are split system airconditioners. We are working on a retrofit device specifically for these, though it will work on any IR controlled appliance.
pros
- You can retrieve folded historical data for sensors from the api (min/max/avg/interval etc)
- You can set a callback that POSTs every reading (every 45s)
- cheap, additional temp/humidity sensors are $15
cons
- range could be a real problem. Manufacturer states 100m open air 30 inside, which is inline with our experience (with a fully extended antena). Apartment walls could be a showstopper.
How about a raspberry pi with a bunch of DS18B20 1-wire temp sensors - stupidly cheap if you can handle the wiring.
I'm sketching out the design for a raspberry pi-based central heating controller with a web interface, mix of sensors and an lcd display - should cost around 75-85UK pounds, including the pi
AFAICT Iris is a zigbee/zwave hub? We have experimented with a zigbee via a usb dongle - not production ready but its doable. We'd love to support Z-wave, but its a longer term feature with licensing issues and bandwidth pushing it down the backlog somewhat. Does Iris have an API that could be wrapped?
IP cams (especially the ultra cheap ones with pan and tilt) are way up on our list. It will be one of the first client modules off the shelf in the new year.
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!
Totally agree in principal @frozenlock. 433 was simply the path of least resistance for us. It gave us very cost effective off the shelf sensors, and critically, remote control power sockets in all regions. Its not super elegant, however, it gives software developers (most of our customers atm) hardware with an API for peanuts compared to the established options.
The Ninja is a meta-platform that offers a normalized API for disparate hardware. See my reply above for the long winded answer. The short version is - we aim to provide OAuth for your all stuff ;)
Hey @windexh8er, from the sounds of it you are already well automated! I'm not sure how much NB offers you today, however ...
Ninja is ultimately (read: not yet) a meta-platform for connecting stuff. As you point out, there are plenty of different approaches and technology with advantages/disadvantages. We think the thing what is really missing in the landscape today is interoperability. Say you want to give access to your security system's motion detectors to a third-party app that helps you save energy, that is nigh on impossible with an OTS offering. That kind of thing is exactly what we enable (albeit a little crippled) today.
Its early days and we have a metric-shiton of stuff to do, some of which includes:
* making the webservice fully or partially optional - current cloud driven architecture is for expedience
* supporting lots more sidebands than just 433 - again chosen for expedience and cost. Z-wave is better, no doubt, but its not really justified in the mega premium per device i.e. $70 for z-wave PIR vs ~$15 for 433. BTW we have proof-of-concept support for Zigbee Light Link via a USB dongle on a block.
* publishing a public repository of local modules to make it easy to wrap (and share wrappers) for proprietary/lan based offerings (think wemo, philips hue, etc)
Another thing to note is that we are a hardware company by necessity not choice. You can run our (node.js) client on an RPi, beagle bone, media centre pc, etc.
Anyhoo, I digressed. We hope to have something that you can get excited about one day in the not too distant future ;)
I think the NinjaBlocks folks are missing the point here...
Interop is key in an automation / security / energy platform. Saving energy, as you state, is fully baked into the MiCasaVerde platform (and others I'm sure) today - see ERGY (http://www.ergyenergy.com/). So, please don't make that assumption that it's not there in others.
I still don't get your target market. It seems to me it's the people who don't really mind a half-baked solution, or is it geared towards people that will go the remaining 80% (there are a lot of things missing the more I look at this platform for a serious contender in full HA). Your cost estimates are way off base here - I've never paid $70 for a PIR with Z-Wave - try more along the lines of $35 and the cost of these controllers is coming down. And, again, you can't take 433MHz seriously. You do realize that your entire system is proximal to the RF of your 1 controller, right? Whereas in my Z-Wave system I can fully extend out into a huge building and take full advantage of a self-healing, self-routing mesh network. As I stated before - 433MHz stuff is junk, and if you're even paying $10 for a similar PIR controller, you're getting what you pay for - something that doesn't work well. This is why I'm not a fan of WiFi only devices such as SPARK. Think very large home or business - unless you have great WiFi coverage everywhere (since these little devices generally have crappy radios / antenna) . This is something people who don't actually use home automation won't think about - because they don't actually use it. But in my mind 433MHz in an HA system is akin to Internet banking without encryption - sure, you can do it, but it's going to break quick once you really want to take it seriously.
So with the system I have implemented today:
* Control Insteon
* Control Z-Wave
* Control IP devices
* Local API access
The things that are missing are:
* Control Zigbee (this is the biggest miss and I applaud SmartThings for picking this up)
* Better UAC
This isn't a dig, but instead of making a lot of the assumptions you've put forth in your response, you should potentially team up with people who are seriously using it today and look at how they're extending it in their homes. You'd learn a lot I feel, and actually put out a product that addresses the same pitfalls everyone who's trying to play in this space is making. I know a lot of people who are using this stuff today - and we all have the same sentiment for all the new "players" - but at the end of the day the products are all still not serious contenders and I'm baffled by how SmartThings pulled $1M+ from Kickstarter by reinventing a prettier wheel.
Good luck on your attempt here - and you may want to look at what's out there in the mean time.
@windexh8er we are not as naïve as it probably seems to someone of your experience ;) We are taking a different approach to the established players and definitely the other startups - who we aren't directly trying to compete with anyway.
Would love to chat offline if you were interested in hearing our take and/or brain dumping on us - pete at ninjablocks com
We do remote control sockets today. Not elegant but at $10-15 a piece best priced laziness available.
We are cooking up something for IR controlled heating/cooling.