
HomeKit - taylorbuley
https://developer.apple.com/homekit/
======
zmmmmm
Dear Apple, please for the love of god and the good of everyone, get together
with Google and iron out a common protocol for this stuff. Don't make this one
of your competitive technologies designed to fragment the world into Apple and
not-Apple. Home automation is just dying to take off and there's a pile of
gold for everyone if you just show a tiny bit of cooperation to get it started
... And you can all still sue each other afterwards if you like about the
design of the light switches or whatever turns you on, but can we please just
let the industry move forward first?

~~~
prawn
Wonder if we'll see futures houses advertised for sale as being Apple, Google
or whatever other brand supported properties. Not too keen on that concept.

~~~
wting
That's happening in the auto industry. Many cars feature Apple integration
while Google is leveraging Android:

[http://www.theverge.com/2014/1/6/5279116/google-open-
automot...](http://www.theverge.com/2014/1/6/5279116/google-open-automotive-
alliance-android-car-announcement)

[https://www.apple.com/ipod/car-
integration/#mercedes](https://www.apple.com/ipod/car-integration/#mercedes)

~~~
_djo_
Not quite the same thing. iOS's CarPlay integration is just a mechanism for
mirroring your iOS device in-car and using the car media controls. The Open
Automotive Alliance is about trying to get Android into the embedded car
systems market.

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.

------
untog
Shrug. Maybe I'm stuck in the past, but am I the only one not really excited
for this kind of thing? Turning lights, air conditioning on and off isn't
exactly a huge problem in my life.

~~~
general_failure
This is a very myopic view. Technology needs to advance in all fronts. Once
these things are integrated as part of your daily life you wont notice them
anymore and will take them for granted.

These things will actually end up conserving energy in great amounts.

~~~
wwweston
> This is a very myopic view. Technology needs to advance in all fronts

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](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.)

~~~
rwallace
That list of standards is ridiculously unreasonable and unrealistic. If we had
consistently followed them, we'd still be arguing about whether to start
banging the rocks together. Anything as daring as the printing press or
electricity would be utterly unthinkable.

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.

~~~
noblethrasher
Well, that was largely the state of affairs for computers for a while: From
1998–2007, I could reasonably expect 1, 2, 3, 4, 6, 7, and 8 with respect to
both desktops and laptops.

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/](http://www.oldversion.com/)).

------
gergles
Here's hoping the "common protocol" they mentioned in the keynote is Z-Wave
(strongly suggested base on Tim's use of the word "scenes" and the vendor list
they put up) and not some Apple proprietary garbage. I'm still bitter about
FaceTime being an 'open standard'.

~~~
jasonpbecker
Many are bitter about that, myself included. But it was an intellectual
property issue, out of Apple's control.[0]

[0]:
[http://www.bbc.com/news/technology-20236114](http://www.bbc.com/news/technology-20236114)

~~~
judk
A patent (troll, btw) doesn't stop Apple from letting other clients connect to
the network. Those clients could decide if they want to deal with the risk of
infringement judgments.

And Apple could have chosen to use one of many existing alternative session
initiation algorithms.

------
tdrnd
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/](http://revolv.com/)), SmartThings
([http://www.smartthings.com/](http://www.smartthings.com/)), WigWag
([http://www.wigwag.com/](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/](http://relayr.io/)) and Thingsquare
([http://www.thingsquare.com/](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).

~~~
United857
Yes, any mention of Nest was conspicuously absent during the WWDC keynote.

~~~
cr3ative
They went as far as to use a competing smart thermostat in their visuals -
arguably a slight

~~~
X-Istence
They used the thermostat of a company that is partnered with them... not a
slight. Nest isn't a partner, thus wasn't used in their visuals.

------
Frozenlock
Dear Apple, please use industry standards.

BACnet is a ISO, ASHRAE and ANSI protocol.

~~~
CHY872
That's fantastic, but says nothing about the relative merits of BACnet. It's
an industry standard, yes, as I understand it typical of a modern business
unit, but that does not mean that it should be the one used by any new
adopter. Indeed, BACnet's been around for so long now (and has such poor
takeup in the consumer space) that one might wonder whether a newer protocol
is necessary.

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.

~~~
Frozenlock
_Indeed, BACnet 's been around for so long now (and has such poor takeup in
the consumer space) that one might wonder whether a newer protocol is
necessary._

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...](http://www.zigbee.org/Standards/ZigBeeBuildingAutomation/Overview.aspx)
"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?

~~~
CHY872
Security is incredibly important. If I give someone my WiFi password, I'd
really rather they didn't have the ability to open/close my windows, turn off
my heating, turn on my lights etc. Introducing such a system to the consumer
domain would be _the_ most socially irresponsible thing Apple could do. Now
when your kid downloads dodgy porn and gets a virus, you don't just get a
slower computer demanding your cash, your central heating stops working
pending payment!

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](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.

~~~
Frozenlock
Yes, security is important. What I asked was if the BACnet layer should have
its own security, or if we should rely on the network security. (My router at
home already gives me a 'guest' wifi with restricted access.)

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/](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!

~~~
CHY872
All your points have contradicted my most important one.

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).

~~~
Frozenlock
Your criticism of addendums to standard is warranted, except the standards we
use are continuously upgraded. This week's news? HTTP/1.1. How about IPv6?
HTML5? CSS3? Every time something new needs to be added, we must ask ourselves
if it's worth it to start from scratch.

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'.

------
julianpye
The critical part here is not standards and not even the usability from a
graphical UI perspective, but who is put in control by the technology. Home
automation has always faced this difficult hurdle. In most families, the
lightswitch, a thermostat, etc belong to everyone who wants to use it and who
is near it. I like Siri being in control, but she will have to be like a
Butler that can bridge conflicts if this is to make it beyond single-person
households into family homes.

~~~
r00fus
I don't see (initially) any conflict here except for where the switch or
manual control doesn't allow for state-independent operation (e.g.: manual
slider for dimmer switch). In that case, I imagine upgrades being required in
order to play nicely (e.g.: [1])

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...](http://www.amazon.com/Lutron-MAW603RH-WH-Electronics-Maestro-
Dimmer/dp/B000BQMVXC)

------
tmuir
Does anyone have any shred of information about this at all? Since when do
placeholder pages completely devoid of any details whatsoever make it to the
top of HN?

~~~
logn
On that page, there are links to both the API reference and a beta SDK.

~~~
bsilvereagle
To get to the relevant hardware information you have to have an Apple Dev
account, unfortunately.

~~~
MrBuddyCasino
And where do I find that? All I see is a "please contact us" form for hardware
makers. As someone who might want to do some experiments with an Arduino, this
isn't helpful.

------
rblatz
From what I've seen, it looks like you will modify your existing iOS app to
register with the HomeKit subsystem. This will give HomeKit hooks into the
existing control functionality that is in the app. IE Nest will register that
they have a thermostat and this is how to turn the temp up down.

------
logn
HealthKit. HomeKit. I think we need to resolve the ethical and regulatory
issues in our industry regarding government/marketing use of this data before
it's prudent to use any product based on these technologies or similar ones.

------
dmritard96
don't mean to spam, but can the opensource world just do something better?
clearly apple is going to use some super apple only thing...and always will

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](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....

~~~
burkaman
Well "we" aren't waiting, lots of people set this kind of thing up themselves
with a few Raspberry Pis and software like the one you linked.

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.

~~~
dmritard96
[http://cmusphinx.sourceforge.net/](http://cmusphinx.sourceforge.net/)

[http://jasperproject.github.io/](http://jasperproject.github.io/)

agreed though on the nice packaging/ease of use. i'm hoping the hardware
revolution can change that though.

------
bennyg
Now if a ton more hardware manufacturers would start designing around
automation - like a washing machine that automatically started drying your
clothes next, and an app that could see how dry they are and ask if you want
to keep going, etc.

Or an oven I could preheat from my couch.

~~~
fatbob
There are already washing machines that dry clothes - they are common in the
UK. There are also dryers that sense moisture - they are common in the USA.

~~~
digikata
I wish more combined washer/dryer models were imported into the US. Here the
only combos seem to be geared towards small living spaces or RVs. I'd love to
throw a load of wash into a machine, and have it come out washed and dry.

~~~
stephenr
I've used two different washer dryer combos.

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

------
twothamendment
I've been working on my own pile of HA scripts, hacks and controls - just for
the fun of it. When I heard Google was buying nest and a security camera
company and now Apple is jumping in - I'm glad I'll have my own. I don't care
for either company to know exactly what is going on in my house. I do want my
house to yell at me when the A/C is running and windows are open or the garage
door is left open when I leave. There will always be a market for the big
names, but this is one cloud I'll keep out of my hosue.

~~~
mkal_tsr
Exactly. Considering how much data they have on your phones, through web
activity, etc, adding in direct home access with video, audio, and pattern
recognition I'd imagine ... I wouldn't feel comfortable jumping in considering
who may or may not be looking at that data / data-feed.

------
joezydeco
So is this another MFI-type program? Am I going to need to design in some
Apple-authorized chip to enable the handshake?

If it's bluetooth LE, can I expect to get decent range across the footprint of
a home?

~~~
cma
The idea is if you switch to Android next time your contract with your carrier
expires, you won't be able to open your front door anymore.

~~~
beat
Sure, you can open your front door. Just use a crowbar. Old-school hardware
solution ftw!

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.

------
kosei
I hope this is not just handled through Bluetooth, but can be accessed via
wireless as well. The idea of being able to leave air conditioning off in my
house until I'm leaving the office, or to turn off all lights while outside of
my home sounds incredible (or check to make sure that they're off). But if I
have to be within my home to do everything, it'll turn this from a must-have
for me to a nice-to-have very quickly.

------
collypops
HomeKit, for the authentic "lock-in" experience

------
stripe
Building automation is already available for all your automation needs. Quite
expensive but working well. I cannot see what Apple brings to the table other
than control devices. Big automation vendors will probably just write a
wrapper for that custom Apple protocol and be done with it.

------
intothev01d
favorite new feature by far. just awesome.

~~~
Navarr
Have you heard of Android@Home?

~~~
runako
Sounds interesting, but a Google search for me doesn't link to any product
information that's recent. Could you share a link?

~~~
guyzero
That's the point. It's dead.

~~~
runako
Thats's what it looked like to me, but the prior poster seemed to have other
data.

------
chiph
It'd be interesting to tie this in with geofencing, so that I'd know I left
the garage door open before I get too far away.

------
h00k
... AllJoyn, anyone?

[https://www.alljoyn.org/](https://www.alljoyn.org/)

------
quackerhacker
Wow!!! Whoever did the write up for Homekit had to have seen the MIT
workaround for using Siri and an audrino to open a garage door. What a nice
subtle "props," from Apple.

[0]
[https://news.ycombinator.com/item?id=7542985](https://news.ycombinator.com/item?id=7542985)

