HomeKit
developer.apple.com
developer.apple.com
Some of those are for technical/licensing reasons, but many are not.
http://www.zdnet.com/google-moves-away-from-the-xmpp-open-me...
What would be the revenue source there?
https://news.ycombinator.com/item?id=7767811
--
EDIT: At least two downvotes within a minute of posting! If you're going to downvote this comment, at least have the honesty and guts to reply with a counter-argument. I wish HN gave us transparency into votes, such Quora does.
But sigh... I expect these cowardly downvotes. HN seems to be dominated by Google apologists. Furthermore, much of the web is ad-supported, and as Upton Sinclair said so well, "It's difficult to get a man to understand something when his salary depends on him not understanding it."
HN is going downhill because those interested in reasonable discussion are overwhelmed by ideologues and religious fanatics. It's like the tech community has its own version(s) of the Tea Party to contend with
I disagree with your original argument because it's a straw man. 'Ethical' was used by the parent to refer to the consideration to use XMPP, not to Google as a corporation. The parent simply posited that Google's decision to use XMPP was not motivated by ethical concerns. Supporting, in a way, your own point.
Tell me why I come across as an ideologue? My opinion is strong and critical, yes, but it is not rooted in zealotry. Are people who decry the NSA's lying to Congress about its illegal collection of private data ideologues?
Why is my comment childish? Is it not childish to name-call a legitimate argument "childish" rather than addressing the point?
Is it possible that Upton Sinclair's words apply to you?
[I think it's hilarious that I keep getting new downvotes (at least 3) and upvotes to match. Sad really. Downvotes should be used to bury junk, not legitimate replies. Instead of an intelligent discussion, we have this. Maybe it could turn into an intelligent discussion on intelligent discussion. :P]
This is the exact same reason most anti-Goog comments are heavily downvoted. No cogent point, no interesting questions, just "lolz dae M$ and Goog is le devil" - often including a whiny edit accusing HN of being Google apologists.
FWIW I think Google is making a serious effort to deal with the huge conflict of interest created by their defacto monopoly position. However it would be impossible for Goog to escape all negative consequences, nor are they without flaws, so intelligent discourse is welcome.
If the truth is oxygen of democracy, then journalism is the lifeblood and distorting the truth for increased revenue is unethical.
More like, they continued to use XMPP for 8 years at enormous loss, watching while it acted as a massive sink hole of users to their competitors who exploited it ruthlessly ...
I too wish they hadn't ended federation, but do note that to this day XMPP clients continue to work just fine. They did not abandon XMPP as everyone loves to imply.
- Google Hangouts (non-XMPP) replaces Google Talk (XMPP) on Android.
- Apparently I always appear online in Google Hangouts even when I'm signed out of Google Talk leading to people messaging me and being confused that I don't respond, or never got the message (apparently it just goes into the aether, or maybe only shows up if I switch over the Google Hangouts).
Saying "look XMPP still works!" doesn't prove much as it's a second-class (or even third-class) citizen in Google's ecosystem.
As someone that remembers the constant battle between AOL and third-party IM clients, I'll note that Google's handling of XMPP feels similar to AOL transitioning from TOC to OSCAR[1]. The parallels are there. They provide a way for third-party clients to connect to their service, but make sure it's never as fully-featured as the 'official' client which uses an entirely different protocol.
[1] The OSCAR protocol was more fully functional than the TOC protocol (e.g. 'buddy icons' didn't exist in TOC, nor the ability to directly connect and send images to a buddy), but AOL pointed to the TOC protocol when third-party IM clients wanted to connect to AOL's IM service. At one point, the OSCAR protocol would start doing things like requesting random binary chunks AOL's official IM client to assert that a third-party wasn't connecting to the service (i.e. working around this would mean distributing a copy of AOL's IM client, which allows AOL to sue).
There's the rub. The business of both Apple and Microsoft is lock-in. Unlike Google, their lifeblood is you buying their next device or next software release. So they are under constant temptation to take away your freedom to choose. Hence iMessage, hence Facetime, hence proprietary locked down exclusive App store, hence massive integration between OSX and iOS. Hence proprietary office formats, file systems that don't interoperate, etc etc. So sacrifice your information and privacy or sacrifice your freedom ...
If you want to be cynical enough nobody is clean, probably not who or whatever generates your income either.
If they come up with a compelling product there will be competitors and standardization.
Apple made out like a bandit from that ecosystem since it was the original reason to own an iPod.
http://www.theverge.com/2014/1/6/5279116/google-open-automot...
The CarPlay integration can be served just as easily by embedded Android as it can by any of the other in-car systems. The two approaches are not mutually exclusive.
Who fucked it up? Google.
The whole world sees Google has rock solid services and technology and the whole world sees Nest has some great ideas going. But Google's historical behavior shows they use all this goodness to (pardon my French) surprise-buttfuck their partners again and again.
Point the fingers at Google.
They won't. Please, if you're developing on iOS don't do this. Apple is hungry and looking for another market segment to lock out the slow, but good, innovation taking place. Today I happily control 70% of my house with full access to scene programming and enjoy no vendor lock-in other than the protocols my choice of controller supports. The biggest things here is I have access to a local API, I don't need to rely on Internet connectivity - something most everyone gets wrong.
Home automation is huge. Apple mindlessly taking it down to simplistic "Xfinity home automation levels" but making it pretty doesn't help.
SmartThings, WigWag, Revolv - all suck. They lock the smart home user out by not exposing an API. Why? They want to collect sit in the middle and collect data. None of these companies seem to get that there's a middle ground and the initial users are not all ones that trust a start-up 1) with their data and 2) to be around next year. There's only a few that get it right and they're not the prettiest by far or they'd, likely, rule the landscape.
I've been running home automation for over 3 years now on the same platform - nothing today is anything new or different. If I want my phone to be a piece of my HA system I'll use applications specific that help me make those tie-ins, but I don't want Google, Apple or some other fly-by-night-startup to get in the middle of that. It's my home, that's personal.
http://www.bloomberg.com/news/2013-01-11/apple-google-deal-f...
Which is funny because two years before that, Google was absolutely outraged that Apple and Microsoft would band together in a clearly anti-competitive move to deny Google a collection of patents
These things will actually end up conserving energy in great amounts.
Citation, please.
Or at least a clarification of what you mean by "advance."
If you like, here's an example from writer Wendell Berry:
"To make myself as plain as I can, I should give my standards for technological innovation in my own work. They are as follows:
1. The new tool should be cheaper than the one it replaces. 2. It should be at least as small in scale as the one it replaces. 3. It should do work that is clearly and demonstrably better than the one it replaces. 4. It should use less energy than the one it replaces. 5. If possible, it should use some form of solar energy, such as that of the body. 6. It should be repairable by a person of ordinary intelligence, provided that he or she has the necessary tools. 7. It should be purchasable and repairable as near to home as possible. 8. It should come from a small, privately owned shop or store that will take it back for maintenance and repair. 9. It should not replace or disrupt anything good that already exists, and this includes family and community relationships."
http://home.btconnect.com/tipiglen/berrynot.html
(I don't expect everyone would necessarily share all these standards -- I suspect 10 in particular might be an issue for HN participants, for example --but they serve as an example and all of them have some merit.)
1. I don't care for change, everything is terrible as long as I can pick at least one problem.
3 and 9 clearly contradict! This is garbage.
Something that achieves 3 without sacrificing 9 is probably better (or at least more likely to be adopted) than something that achieves 3 but sacrifices 9.
But also, I think this thread entirely misses the point and intended use-case for this list.
When you cannot satisfy all criteria, the list does not become a justification for the status quo. Instead, it is a useful mechanism for elucidating the exact conflicts which a good designer must reason through and ultimately resolve (perhaps even leading to an alternative, "win-win" or "win-less lose" solution. Or not. Either way, the list helped think things through.)
9 is talking about aspects of people's lives.
"But what could someone who never uses a computer know about computers!?!" They could know what is lost when you use a computer, and, in general, you can't get that perspective from the Hacker News crowd (or nearly anyone under 30 or so). I don't agree with everything he writes (especially not the religious stuff), but he's very wise, I think.
If intrigued, one might try "The Unsettling of America" (1977), "What Are People For?" (1990) or "Sex, Economy, Freedom, and Community" (1993).
Opinions don't require citation.
Your list of requirements for technological innovation is somewhat suspect considering you're discussing it via a tremendously expensive international network of computers, which is mostly powered by coal-generated electricity, who you likely paid a multinational telecommunications company to access.
I don't know whether home automation will take off, but I think the deciding factor will be the same as it was with most of the other things we've invented since we came down from the trees: whether the benefits on the whole exceed the costs.
We do seem to have regressed because of the phenomena of “worse hardware through software”, and the over-dependence on cloud services.
I'm also much more skeptical that software version n is unambiguously better than version n-1, having been burned a few too many times (that's also why sites like this exists: http://www.oldversion.com/).
I live in a 1200 sq foot condo, 1 floor, with limited natural light. Automated lighting activation via Bluetooth LE (Tasker on my Android phone) is very handy when I come home late at night, because walking through ~15 feet in the dark to a light switch isn't fun (yes, first world problem).
More importantly, my Nest thermostat. Am I lazy for changing the house temp from my bed? Most definitely. But that's not the point. I have saved quite a bit in utilities with its auto-away functionality, as well as its airwave cooling function (detects how long it can keep cooling the home from residual coolness in the air exchanger coils after the compressor has shut down).
Energy efficiency plays (Google buys Nest for $3.2 billion) turns tech companies into utility MVNOs. And almost everyone needs some form of power or HVAC.
But, all of this nifty tech does rely on tapping in to home infrastructure (switches and devices that understand the protocol), so it's a long haul.
These devices are wired in and have 50-year design lives. The life of these protocols seems to be significantly less than 50 years, which is a pretty big mismatch.
Yes, I'm still sore about the ~10 useless X-10 switches I put in in the 2000s. ;-)
But you're absolutely right. It's hard to sell incrementally useful capability when it requires spending a fair bit of time and money to upgrade components that are doing a decent job today and probably will for years to come.
Case in point. Would I buy a Nest if I needed a thermostat today? Probably. Will I buy one to replace a perfectly good programmable thermostat that's already installed and working? Probably not.
Or maybe one might want to lock the font door from the office when one left in a hurry to get to the meeting on time?
Blinds that automatically open/shut based on time of day and internal/external temperatures to prevent against heat loss during winter. I'd be keen on that as it's not something my wife ever considers. At the front of the house, we have six windows in two rooms, all with separate blind controls. What I'd give to automate the process of opening those in the morning and closing them at night...
Microwaves that switch off standby (ultimately uses more power than actually cooking something) once it learns which hours you tend to use it. Garden lighting systems, irrigation systems that can check the weather via your phone and adjust schedules if it's going to rain, etc.
edit: comma removal
And Apple could have chosen to use one of many existing alternative session initiation algorithms.
more info: http://m.electronicdesign.com/communications/what-s-differen...
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).
BACnet is a ISO, ASHRAE and ANSI protocol.
As I understand it, BACnet has a number of drawbacks that make it unsuitable for this kind of thing. In particular, BACnet is not really plug-and-play (and is not designed to be), supports a relatively small number of transport protocols (one could imagine this Apple system eventually encompassing BlueTooth, ZigBee etc). Furthermore, it's not really a secure standard as I understand it - access to the WiFi network would essentially give control of all the devices. Current solutions aren't really much better, but it needs to be the primary concern (and I suspect that Apple have considered it). As one example, BACnet best practice is currently to have parts of the network that have to be in userspace (temperature sensors, door sensors (as opposed to lifts, aircon)) is to place them on separate physical networks.
Even moreso, it's kinda usually implemented right above the link layer (which violates the hourglass principle, if nothing else), and there are issues that will come up in the near future with the alternatives (BACnet/IPv6 being an issue (i.e. most BACnet/IP devices will stop working as networks switch to IPv6)).
BACnet is probably fine in the enterprise domain, where everything is installed at building construction time, there are people who manage this stuff for a living, and things like airgaps are desirable as well as necessary. In the home domain, it's at least overkill, and makes things incredibly difficult for users. It's entirely fair for Apple to go their own way.
Trying to do a standards-based approach at the moment would be a horrendous idea - firstly I know a large number of companies to be trying to come up with their own solution at the moment, but secondly it would just end up being a standard by committee (with no real implementers). Let the competitors hash it out for a few years, and then standardise the best one.
Or one could consider that only very recently technology has become cheap enough to be a viable option. In fact, I'm still not convinced it's cheap enough to interest the average consumer. Tho Apple's team probably disagree.
What do you mean by not plug-and-play? Any BACnet device can be connected to a network and announce itself with a WhoIs, being instantly recognized by all the other devices.
(...) supports a relatively small number of transport protocols (...) BACnet has many official transport protocols, the 3 most popular being MS/TP, Ethernet and IP. Furthermore, nothing prevents the BACnet packets from being embedded into some other protocol.
And because you mentioned ZigBee: http://www.zigbee.org/Standards/ZigBeeBuildingAutomation/Ove... "The ZigBee Alliance joined forces with BACnet, the leading global building automation and networking protocol for building automation, to fully support BACnet over ZigBee Building Automation networks. Soon it will be possible to easily expand your wired BACnet-based building systems to new areas by using wireless ZigBee Building Automation products."
You are right about security, BACnet was not designed with security in mind (nor was the Internet). But this brings other questions:
1. Does the consumer space need security for thermostats?
2. If it does, why shouldn't this be handled by the network security?
3. If there's really a need for separated security, why not add the required changes in the next protocol version?
(i.e. most BACnet/IP devices will stop working as networks switch to IPv6)). No. No they won't. Firstly because most BACnet network are to remain inside the enterprise own intranet which will remain IPv4 for a long time. (Forever?) Secondly because IPv4 is a subset of IPv6.
BACnet is probably fine in the enterprise domain, where everything is installed at building construction time(...) Which is simply not true. Most buildings are many decades old. They are a (horrible?) mess of pneumatic systems, first generation electronics control with relays panel, and what we could call recent technology controls with micro-controllers.
In the home domain, it's at least overkill, and makes things incredibly difficult for users. I fail to see how using existing technology is 'overkill'. Was it overkill to bring Ethernet and IP to home users? Should we have come up with a different standard?
(...) Trying to do a standards-based approach at the moment would be a horrendous idea - firstly I know a large number of companies to be trying to come up with their own solution at the moment (...) How is many companies trying to come up with their own solution an argument against standard-based approach?
(...) but secondly it would just end up being a standard by committee (with no real implementers). You mean without the worldwide HVAC industry, right?
Personally, I find the BACnet protocol to be bloated. But is it a good enough reason to throw away everything?
So what you're saying is that you'd make a new version of BACnet to make it suitable? A new standard? Were I Apple, I'd refuse to let my devices connect to any insecure devices - it'd lead me open to many horrible 'I got a virus and it unlocked my door' online stories which would be horrible for business and stop the process in its tracks - and so the new standard would not be backwards compatible. So, if we had a new standard, there'd be loads of BACnet devices that did not support my stuff (consumer confusion), huge trouble negotiating the standard with all the current stakeholders, and a lot of cruft that I'd have to implement that I don't really want to implement (lift controls etc).
What I meant by the IPv6 comment was that consumer networks are switching to IPv6 at a high rate, and IPv6 only networks might become a reality in 10-15 years (with an external ISP 6to4). It's ok for businesses to stay on IPv4, but most in the consumer space use their ISP provided routers. In this case, we'd likely see large incompatibilities with most of the BACnet devices - we'd end up with this weird split standard.
In this case, we have this interesting situation where we have many BACnet branded devices, but only a few are relevant for the average consumer.
The reason that home users have ethernet and IP is because of the hourglass model. The reason that most services just work is that they talk TCP/UDP - anything below that they can ignore - so if we use a new hardware layer, if we use FDDI etc we can still use TCP because everything talks in IP. BACnet kinda breaks that - you mentioned ZigBee adding BACnet support - ZigBee has supported IP for ages - had BACnet followed the hourglass model (as literally every other internet service I have ever seen has done) then support for BACnet would have been immediate and unnecessary to trumpet.
Re overkill - again, it's about the hourglass principle. http://named-data.net/wp-content/uploads/hourglass.png - the idea is that we all achieve massive interoperability by using IP. BACnet doesn't quite fit into that, mostly because it replaces IP for (as I understand it) no particularly good reason.
You want standards when you have a mature market and you want to prevent lockin. Standards in an emerging market can lead to stagnation and reduced innovation, as each change must be agreed by the stakeholders (who might have opposing visions) - like what happened with OAuth 2.0. This is why (say) new programming languages typically have a few years of backwards incompatibilities before they get standardised.
And no, by adding new stuff I don't mean a new standard.
It's called an addendum. Which, I'm surprised I overlooked, some were made especially to address the security issues: http://www.bacnet.org/Addenda/
If security really is a big issue, the LAST thing I want is give access to the secured network to my PHONE. Is your phone secure? Would you store your bitcoins on it?
The reason that home users have ethernet and IP is because of the hourglass model. The reason that most services just work is that they talk TCP/UDP - anything below that they can ignore - so if we use a new hardware layer, if we use FDDI etc we can still use TCP because everything talks in IP. BACnet kinda breaks that - you mentioned ZigBee adding BACnet support - ZigBee has supported IP for ages - had BACnet followed the hourglass model (as literally every other internet service I have ever seen has done) then support for BACnet would have been immediate and unnecessary to trumpet.
And by supporting IP, it was also (indirectly) supporting BACnet. You just explained how services using TCP/UDP could ignore everything below... I don't understand why you don't understand it's the same thing for BACnet. Those 'official' transport layers offer you alternatives. But guess what, by supporting Ethernet and IP, BACnet can already use pretty much all the network architecture around..
BACnet doesn't quite fit into that, mostly because it replaces IP for (as I understand it) no particularly good reason. Ok, this might be the source of the confusion. Yes, the BACnet network layer needed to be defined, because at the time IP wasn't everywhere like it is today. BUT, you can easily embed this into other protocols. That's exactly how you talk about your hourglass model: BACnet devices don't care if they are connected by MS/TP, Ethernet, IP, Arcnet... They just look at the BACnet level. Just like many services look at the TCP level, not at the IP or Ethernet level.
About IPv6 for new networks, if they become required, I see no real obstacle into extending the standard for IPv6. IPv6 is itself an example of a standard changing with time. Would you prefer to throw away IP a start from scratch because IPv4 devices might not be able to communicate with IPv6?
You want standards when you have a mature market and you want to prevent lockin. Standards in an emerging market can lead to stagnation and reduced innovation(...)
But why do you consider the consumer domain to be an emerging market? For all intended purposes, you still have lighting, HVAC, access... those all already exist in bigger organizations!
There's nothing new here!
We should never allow the situation in which someone who has been given access to the network (a guest, a child, ...) can be allowed to either control the BACnet components themselves, or install a trojan that can. By having no security built in, BACnet can be controlled by any device that has unrestricted access to the network - whether it be a compromised computer, a guest, etc. You can say that giving someone access to your wifi is some cardinal error, but people do it every day, and ignoring it would just give Apple a headache. In an enterprise this is manageable, in a home it is not - because Apple will have bad pr from people getting their central heating hacked, but will not be able to supervise the installation themselves. My phone is not particularly secure, no. But good sandboxing means that I can ignore the majority of network threats. If Apple programmed this in their computers as a system level program, then it would be at least as secure as (say) the keychain, which already contains enough to leave me in big trouble if it got leaked.
BACnet can use all of the network architecture around, but generally needs it to be supported in some way. For example, had BACnet used TCP - it would have been fairly trivial to get BACnet to use TLS as well, and then the security issue would have gone away.
I'm sure that all of the critical flaws with BACnet (and don't be confused, they are critical flaws) can be fixed with addendums to the standard. The problem is that then we have much BACnet compatible software that doesn't support BACnet as implemented by Apple. Again, were I Apple, I'd
- Refuse to use any BACnet device that didn't provide a minimum level of security, because it could lead to bad PR.
- Refuse to use any BACnet device that didn't operate on top of TCP at a minimum (because using TCP allows me to use (say) TLS).
- Refuse to use any BACnet device that wouldn't support both IPv4 and IPv6.
- Have to work with all the BACnet stakeholders.
- Have to make all of my software backwards compatible.
- Have to find some way of agreeing with all the stakeholders to market their Apple-compatible devices in such a way that Apple customers won't have to spend days poring over spec sheets to find out which BACnet devices are compatible with the Apple software.
BACnet is just a protocol, and a complex, bloated one - if it's flawed such that to fix it we must change it drastically, it's probably easier to just replace it. It's already clear that almost all of the devices on the market currently would not be compatible with whatever a reasonable Apple might do. Given that this might require many changes to the standard, why should they bother with all the politics when they can just do it themselves?
These flaws (believe it or not) actually negate the rest of the BACnet standard. It's a standard, yes, but it's an old one, and we can do better with the benefit of both hindsight and modern hardware. From a hardware point of view, it's probably better to use the standard - from a software or UX point of view, the standard adds nothing, but takes many things away.
As a pure point of history, BACnet became an ISO standard in 2003, work having started in 1987. TCP has been a standard since 1974, and a new standard was published in 1989. The problem for BACnet is obviously that every time a new physical transport is announced, BACnet as a standard has to add support - much effort on the part of anyone who wants to get things moving faster.
Addendums to a standard don't really hold much water, by the way. If you can just add something to a standard whenever the standard doesn't do what you want, then you lose the standardisation. Indeed, if you add anything to a standard, it ceases to be that standard (it becomes a new standard).
About security, your opinion is that the private network should be considered insecure for HVAC control. IMO someone changing the setpoint of your air conditioned is the least of your worries if someone gets in your network. But you might be right, perhaps there's a need for yet another level of security. If that's the case, then we can evaluate if we can use what's in the standard, or if we need something brand new.
These flaws (believe it or not)(...)
You can keep your snarky comments, thank you very much. A year ago I was the only one on the BACnet mailing list saying BACnet should get its shit together or a giant like Google or Apple would come and eat its lunch. I know these are flaws. I also know there are ways to patch them. The question is whether it's worth starting from scratch. You know how many Apple's engineers asked info on the BACnet mailing list? Oh right, NONE.
This smells a lot like young software developers looking at a complex software thinking they can do better... only to realize later that heck, some of these complexities were there for a reason.
Some other times, it might be 'cleaner' to start anew, but the shear effort to shift an entire industry ins't worth it. Make no mistake, it's an entire industry, and a huge one!
--
Again, were I Apple, I'd
- Refuse to use any BACnet device that didn't provide a minimum level of security, because it could lead to bad PR.
- Refuse to use any BACnet device that didn't operate on top of TCP at a minimum (because using TCP allows me to use (say) TLS).
- Refuse to use any BACnet device that wouldn't support both IPv4 and IPv6.
- Have to work with all the BACnet stakeholders.
- Have to make all of my software backwards compatible.
- Have to find some way of agreeing with all the stakeholders to market their Apple-compatible devices in such a way that Apple customers won't have to spend days poring over spec sheets to find out which BACnet devices are compatible with the Apple software.
--
In other words, make your own walled garden where you can do what you want. That's pretty much the history of Apple, unfortunately. Sad days for those yearning for more open protocols.
BACnet is just a protocol, and a complex, bloated one - if it's flawed such that to fix it we must change it drastically, it's probably easier to just replace it.
MAYBE, but I've yet to see Apple (or anyone else) opening a discussion with the HVAC industry asking what's going on, what are the needs, etc.
What I do see, is a company on the brink of disregarding a standard in 3 of the biggest standard organizations, just 'because'.
In the case where all controls for a resource allow state-independent operation, it's simply resolved with "last-in wins", and possibly more elaborate permissions models as automation adoption matures.
[1] http://www.amazon.com/Lutron-MAW603RH-WH-Electronics-Maestro...
I tried a while back, and it looks awfully similar to what apple is doing... I use it all the time, manages my lights, my server, my IR electronics, through the UI or on a schedule. Has macros, etc. doesn't have the fancy detection features although at the time those were just starting to be talked about. Wouldn't be a hard extension. https://github.com/dandroid88/webmote
There are better ones out there, but my main point is that is some recent grad can hack this out on some nights and weekends, why are we waiting for apple , and verizon, and att and comcast and google....
The reason people wait for commercial alternatives is obviously ease of installation, support, etc., but there are also some features the big guys can offer that open source just can't compete with. Voice recognition is one, what if you want to talk to your TV or set your alarm while you're lying in bed? Open source speech recognition is passable, but there is no open source package that lets you do a hands-free "OK Google" trigger word type of thing. You'd have to pay thousands for that, in which case maybe you'll just wait for Google or Apple to integrate it into their home automation products.
http://jasperproject.github.io/
agreed though on the nice packaging/ease of use. i'm hoping the hardware revolution can change that though.
Or an oven I could preheat from my couch.
I tried to use fldigi to decode this - sadly wasn't able to.
Never again. It's terrible at both tasks, is ridiculously slow and never dries things completely
There is a reason the inside of washers and dryers look different
You can even buy locks that will unlock with bluetooth but that makes me paranoid.
http://www.amazon.com/Kwikset-925-Cylinder-Bluetooth-Deadbol...
Honestly, locks are so easy to pick that something with Bluetooth would probably be much more secure. A lock stops people from randomly walking into your house but anyone who actually cared about getting in would have no trouble.
And the windows?
I strongly second _A Pattern Language_. It's significantly augmented my sense of what in a living space works and what doesn't.
If it's bluetooth LE, can I expect to get decent range across the footprint of a home?
But yeah, one of the biggest problems - perhaps the biggest problem - that the Internet of Things faces is devices growing obsolete in short order. Connector conspiracies via proprietary APIs is just a subset of that broader issue. I wouldn't want a chip-only door lock for the same reason I wouldn't want a chip in my body.