Apple has proven me wrong about HomeKit | Hacker News Reader

Apple has proven me wrong about HomeKit

theverge.com

187 pointstambourine_man71 comments

I've been contracting with a major iot company for a couple years and their new product for the past year has been working on becoming homekit compatible. I can't say so far that I've been impressed with how things work on the Apple side. The concept of device vs service has been creating confusion for both our custom app as well as how devices are displayed in the Home app.

The review process is very cumbersome as well, the company I work for wants users using the Home app, but apple requires we create a homekit compliant app to certify the hardware. I don't understand why Apple can't certify the products with their own Home app.

Lastly there is no way to make our hub present itself for remote connections in Homekit, despite Apple requiring us to use chips certified to their standard. The user has to have an ipad or apple tv in the house to act as a gateway. This is a confusing concept to explain to users if they've been using our protocol for the last 2 years and now want to migrate to Homekit.

This! I made my entire house HomeKit, only to rip it all out and replace it with SmartThings. An expensive mistake but HomeKit is terrible; slow, expensive, limited functionality and compatibility and a massive lack of devices that connect to it.

I never tried HomeKit (not really in Apple's ecosystem), but I do like SmartThings. I won't say I "love" SmartThings, there are many things I can complain about it, but the bottom line is SmartThings provided a very powerful platform, you can write Groovy code to achieve most of the goals you have, even though the process of writing such code might be painful (for example, their web IDE is, let's just say, not the best). You can even add incompatible devices into SmartThings (for example I added my MyQ garage door control into SmartThings with customized device handler).

> you can write Groovy code to achieve most of the goals you have, even though the process of writing such code might be painful

Perhaps SmartThings needs to provide another scripting language besides Apache Groovy, one that's pleasurable to write, not painful. Gradle 3.0 added Kotlin, which works seamlessly with the IntelliJ IDE -- SmartThings could do the same!

It's not the problem with Groovy language itself. I think Groovy is good enough (and simple enough) for SmartThings' use case. It's just that you have to do things in SmartThings' web IDE (of course you can use some local IDE/editor and then copy paste to the web IDE in the end), and also work with SmartThings' APIs. The web IDE and the API documents are kind of hit or miss.

You shou

You wha

I'm confused. Despite this line in the article:

At WWDC in May, Apple quietly announced that it planned to relax some of those restrictions. The biggest change was the introduction of software-based authentication. In other words, you won’t have to replace your stuff to make it Apple-compatible going forward, and you’ll get HomeKit’s lauded security thrown in for free — provided the device maker actually goes in and implements it.

The linked HomeKit FAQ says that software authentication is only for non-commercial devices, and that commercial/shipping products are still required to use the hardware authentication chip. So Apple's own docs clearly refute the notion that non-HomeKit hardware can receive a software update to become HomeKit compatible.

Ikea Tradfri is an exception here. They plan to add HomeKit support via a software update, but they do in fact already ship their hardware with an MFI HomeKit authentication chip.

It is possible to add a software authenticated device to a HomeKit network, though you get warned when doing so. This is not new (though official support for it is). But it still sounds like commercial products can't just add HomeKit compatibility via software without breaking Apple's terms.

I'm pretty sure they just haven't updated the FAQ because all this stuff is coming with fall updates and is not live yet.

I don't think there was ever a mention of non-hardware authentication in the FAQ in the past (or even an FAQ at all). There was also never a public PDF of HAP until this year's WWDC, and the link to that PDF also explicitly states that it is for non-commercial products:

https://developer.apple.com/homekit/specification/

Edit: also confirmed this in the WWDC video at 28:20 https://developer.apple.com/videos/play/wwdc2017/705/?time=1...

And let's say you come up with a really cool prototype? And now, you want to develop a HomeKit accessory for commercial sale. You need to join the Apple MFi Program. You need to join the Apple MFi Program and go through self-certification before you can begin your manufacturing or sale of your accessories. And this is really exciting.

works well if you're living the iLife in Apple's walled garden. and here i am hoping for https://www.openhab.org/ to become bigger and better. i want automation without vendor lock-in (hardware or software), and without relying on closed-source and third-party services for the pleasure.

i was doing some research recently about having wifi-connected smoke alarm/CO listening device that can recognize [1] off-the-shelf alarm beeps (which are standardized) and send me an SMS & email. this turned out to be surprisingly difficult to achieve. ideally, i could hook up a microphone to a BeagleBoard of Raspberry Pi, run some daemon that monitors audio, does beep recognition and lets me hook into notifications.

instead, there are proprietary listening devices (ok, fine) that all work by sending notifications via third-party service (not fine) to some android or iphone app (not fine).

[1] https://github.com/benjaminchodroff/alarmBeepDetect

Why not just monitor the actual beeper's voltage and alert when its going off? It seem's a lot more difficult to analyze audio and listen for specific sounds and patterns than it is to just trigger an interrupt when a beeper turns on. Program an ESP8266 to fire off a message whenever the interrupt pin is driven high [1]. You might even have enough room to fit the thing inside the alarm and power it using the onboard power supply. The alarm might even have a signal that is always active when the alarm is going off versus pulsing to active the beeper. It might be cheaper and more adaptable to have just one device listening for any beeps but it's going to be much more complex than just adding modems to all your devices that you care to listen to that fire off messages to a home server that would forward alerts if need be. You could even just make the modems use all the same code and refer to them by MAC address when they are sending out alarm messages to your server ("alarm a0:b1:c2 is activated").

[1]: https://techtutorialsx.com/2016/12/11/esp8266-external-inter...

hmmm, i wonder if i can MITM a Roost Smart Battery, so i dont have to use their apps or servers. i guess IFTTT would be okay, and it does support this.

Here in Ontario, it seems the government doesn't think too kindly of modifying smoke detectors[0], not sure about CO detectors. I suspect that wiring directly to the beeper is grey or black in many places. I guess you could do it if it's a redundant detector.

[0]: http://www.mcscs.jus.gov.on.ca/english/FireMarshal/MakeitSto...

The listening approach is, perhaps, more complex overall, but most of the complexity is in software. The hardware is simple commodity hardware.

The put an ESP8266 in each device approach puts the complexity in hardware, and in interfacing the hardware to the smoke detector. If you ever replace a smoke detector with one from a different manufacturer you may have to change the interface method.

In addition to that, the ESP8266 approach is harder to manage. Whenever you change your wifi network in a way that requires updating login parameters you have to update the firmware on all your smoke alarm monitors.

With the listening approach, you just have to change login parameters on the device that is doing the listening (if it is using wifi...I'd probably actually have it on ethernet)

Furthermore, the listening approach can be expanded to listen for other things besides smoke detectors just be changing software. You could add listening for your doorbell, or your telephone, or your dog barking, or glass breaking.

> Furthermore, the listening approach can be expanded to listen for other things besides smoke detectors just be changing software. You could add listening for your doorbell, or your telephone, or your dog barking, or glass breaking.

Or a whistling gas kettle, which is an actual use case for me.

Generally, I very like the approach of listening and trying to recognize sounds. It's much more flexible than trying to put a brain in every other thing you have at home.

I was originally considering openhab, but then I discovered Home-Assistant (https://home-assistant.io/) and I've been hooked since. It ticks off a bunch of check-boxes that made it a great home OSS solution:

Pro's

- No internet required, can run entirely on a Rasberry Pi

- Integrates with most everything thanks to the huge component library (https://home-assistant.io/components/)

- Easy to write your own Python component to integrate with new stuff

- Can use existing SmartThings/etc hubs or Z-wave usb stick to talk to most anything

- Fairly easy to write automations

- Well written Python 3 code-base that's fairly easy to read and see what's going on yourself

Con's

- Definitely more for the DIY tinkerer

- Need to write YAML for the automations, though a new GUI makes this easier for many cases

Setting up an SMS to me when a motion sensor tripped was pretty easy, my automation was:

    - alias: Alerting on bedroom motion
           initial_state: False
           trigger:
             platform: numeric_state
             entity_id: sensor.bedroom_burglar
             above: 0
           action:
             - service: notify.aws_sns
               data: 
                 message: "Bedroom alarm sensor has been tripped!"
                 target: HassAlert

I've had it running for over a year now, and it's been quite nice.

sounds pretty nice. thanks, i'll check it out.

I second the Home Assistant suggestion - I've also been running it for a while now, and it's pretty easy to get the hang of once you've been using it for a while.

Admittedly I'm definitely a tinkerer myself, but I honestly like the config just being a bunch of YAML files. It's really easy to back up that way.

Home-assistant also has a great homebridge plugin (https://github.com/home-assistant/homebridge-homeassistant) to easily bridge devices to HomeKit. I got home-assistant talking to zwave and zigbee with a Linear HUSBZB-1 stick (new version does both) and finally threw my wink hub in the garbage. Even through Home app -> homebridge -> home-assistant, everything is super fast and 100% local, unlike most of the commercial hubs.

What would be the steps you'd take when you receive the SMS "Bedroom alarm sensor has been tripped!"?

HomeKit has been great for us at home. It was a saving grace for Hue because even their revamped software is god awful. Personally I'll take security over openness any day. Not saying you can't have both, just not today with current offerings by anyone.

FWIW, I'm working on an Arduino/Particle port [1] of the HAP protocol, trying to emulate the Home client using 32-bit C/C++ crypto libraries from the OSS WolfSSL [2]. The folks from Apple Home have been supportive, although their spec needs some help [3]...

[1] https://github.com/moflo/homekit-accessory-emulator [2] https://github.com/wolfSSL/wolfssl [3] https://developer.apple.com/homekit/

HomeKit is amazing with Hue lights, with easy control, dimming, and color changing from the Control Center. With Siri, changing the lights works very reliably, which was not the case with the original non-HomeKit Hue lights.

Disclosure: Ex-Apple employee, but had no interaction with HomeKit.

Thanks to HomeKit, my dumb window AC units are now smart. Based on several HomeKit temperatures and humidity sensors in my home, they now turn on and off as desired.

I've been wanting to do the same thing! Mind sharing which sensors/devices you used to accomplish this?

I have two HomeKit temperature sensors, and a humidity sensor from the Ecobee thermostat I have (we have central heater, but not central AC).

But you can just pick up a standalone sensor like: https://www.apple.com/shop/product/HL232LL/A/ihome-control-i...

For the two dumb window AC units, I plugged them into a HomeKit smart plug like: https://www.apple.com/shop/product/HKEH2VC/A/elgato-eve-ener... With that plug you also get actual energy use and cost in real-time/historical as well.

Since they are all HomeKit all that sensor and state data is shared with all other HomeKit devices. So I created a HomeKit Automation that triggers the start of the window A/C units when temp triggers a certain threshold and during a certain time of day. Similar trigger to turn the AC off.

I found this HomeKit app to offer much more fine grained automation rules: https://itunes.apple.com/us/app/home-smart-home-automation/i...

Can I implement the HomeKit protocol for my own Raspberry Pi gadget?

Yes. Check out Homebridge - it's already been done for you.

Apple got the fundamentals correct from the beginning and I've always been mystified by the hot takes claiming it was a failure.

It's designed with security in mind, so your HomeKit fridge isn't going to take part in a DDOS attack [1], and it doesn't require an internet connection. Some people viewed this as the same ol' Apple focused on devices while the world moves on to cloud services, but it turns out that's a big advantage too [2].

[1] https://arstechnica.com/information-technology/2016/10/doubl...

[2] http://www.businessinsider.com/nest-thermostats-go-down-2016...

For me, the details matter. HomeKit means that Siri can answer a question like "Are my lights on?" whereas the Amazon Echo can only send commands like "turn off" or "turn on" (with no knowledge of system state) to my lights. It's a very minor detail, but it makes me appreciate the HomeKit protocol that much more.

I don't follow. I just tested with my Google Home and it correctly told me my Coffee Maker was "off". Is this just a limitation of Echo?

Might depend on the light maker and how they maintain their Skills/Actions. It was a quick add to development after initial release.

Can you trick the Google Home by turning the coffee maker on yourself? i.e. is it just remembering the last state it set, or is it able to query a device for current state?

I don't have a coffee maker, but I just tried this with my Philips Hue lights and it was able to get the right state even after I turned the lights off manually through the Hue app.

Try:

1) turn off a light in the app

2) physically disconnect and reconnect power to a light (e.g. unplug and plug in)

3) note that light is on by default (at least for Hue lightstrips, not sure about others)

4) note that you cannot turn the light off without turning it on in the app

3) is true with all hue lights, so that you can easily override using the good old physical switches.

However, are you sure about 4?

I had power outages sometimes, when the power comes back, all the hue lights gets on (Not cool when it's 4 am by the way), but then I'd just press "Off" on my hue light app and they'd all turn off.

If I remember the Hue API, you can send a new state to the lights not matter what the previous state was, so I'm not surprised this works correctly, which is why I'm confused about your step 4).

Are you trying to turn them off via a Echo command specifically?

I'm using my own CLI script to control Hue lights[0] and I confirm that you can set the state of your lights directly, without referring to or even knowing the previous one. The API is pretty straightforward.

I suspect that even the vanilla Hue app on Android does that - given the way I often manage to switch the lights before the app UI figures out what's their current state.

[0] - https://github.com/TeMPOraL/hju

This is not true with my Hue light bulbs on iOS. I can do those steps and turn the bulb off in both the Hue app as well as via HomeKit.

3) is the desired behavior.

4) is not true, I just tested it. If I leave the app open it does take a few seconds to sync. If I close the app and reopen it, it displays the correct status. This is using the official Phillips app. Some other apps may not read the status, but they clearly could.

It could be. Most of the time I notice it with the hue light system and telling lights to turn "off" or "on." Because the Echo can't get state or maybe doesn't implement it, it frequently says "okay" but fails to do the action. I can only assume this is because it mishears "off" and "on" and it has no way of inferring that I mean "the inverse of whatever state it is."

Failure is a safe hot take, because most things fail. It's the cold reading of tech news or business news.

I'm not really convinced they got the fundamentals correct in the beginning, though. From a designer's perspective, the hardware requirement alone is a fatal error - it's a totally unacceptable level of initial lock-in and expense. Fixing that actually looks like a major change to the merits of the device.

Fundamentals from the perspective of a consumer: if you buy a HomeKit-certified device, you'll be getting something pretty good. There might not be any HomeKit-certified devices because the development process is/was onerous, but that's a separate question from what consumers get in the end from the devices that do make it through that obstacle course.

Yeah, agreed. The one other issue, though, is that I think it's wrong to evaluate the quality of each device in isolation. From Apple's viewpoint HomeKit will be a success iff there are a wide range of quality products for it. They're trying to sit at the center of an ecosystem, and that means not just offering quality but hitting critical mass.

A lot of IoT stuff is complete junk, though. People make complaints about Apple products being overpriced but the expectation is reverse of reality. This is what it costs for a quality product. Sure you can make things cheaper, but you have to cut somewhere. Is having your living room lights being part of a botnet worth saving 10% off the purchase price?

Just because item 1 is cheaper than item 2 doesn't mean item 2 is overpriced.

I'm sure that people are well aware that Chinese knockoffs do exist and that they are stereotypically of lesser quality than it's authentic counterpart. I think the only thought process going on for most people thinking is overpriced is the fact that Apple is in the name. On computers they'd be wholly correct. On phones it's debatable. On watches they might be worth it depending on your usage. But that's the best case scenario for Apple, your usage might necessitate that quality. By and large people don't need that kind of quality because they'll never come close to that usage.

In that respect many apple products are very overpriced for many people.

It's not only subjectively overpriced, it is overpriced, objectively, as far as the BOM is concerned. What Apple does is to compromise on the most expensive core hardware but make it up on by having (1) a complete and latest set of ancillary hardware (e.g. sensors, connections, etc.) and (2) great software. Ultimately (1) and (2) are things that don't cost that much. They choose to spend the least to get the most bang, and not everybody has the sense to do that. Most other manufacturers go for the complete opposite.

Not sure what you consider "core hardware" but iPads and iPhones have the best cpus/gpus, among the best (if not the best) displays, and among the best (if not the best) cameras.

I also would not say that "great software" does not cost that much. It costs Apple billions of dollars annually to create that software.

Displays is the easiest point to argue there. It's subjective, of course, but flagship Android phones have had spectacular (and at the bare minimum, competitive) displays for a couple of generations now.

True, but Android flagships typically aren't much less expensive than iPhones...

This is most assuredly not what it costs for a quality product, but it is what they can charge for a quality product given no competitors in that tier. Plus, signaling, etc.

This is exactly what I hate about all the internet arguments about Apple in general. When an anti-fanboi screams that they can get the exact same computer for $1000 cheaper because of the "Apple tax", I abandon the conversation completely because they've clearly either never used an Apple device or they're completely ignoring the fact that their $1000 cheaper device has cut corners somewhere whether that's in build materials, features (like the keyboard backlight or display), or just general quality of experience. Things aren't just more expensive because Apple wants them to be more expensive. They'd be forced to shut down shop by all the competitors that could undercut them. Instead, they're one of the most valuable companies in the world because people that actually do spend the extra money agree that it's not just an "Apple tax" but a higher-quality product.

I agree with your general sentiment, but please let's not be naive about Apple's business practices - last time I checked (2 years ago?) Apple's company wide profit margin was about 30 - 40%. So yes, Apple's products are superior and you definitely get something in return for the higher price, but the Apple Tax itself is definitely real.

True but only to a point. Apple's scale gives them a price advantage from suppliers, which increases their relative margins.

Also note that not all parts that seem comparable are. For some parts like LCD panels that have more variance in quality, Apple has deals with suppliers to get the best panels while Dell and others have to buy the ones that don't hit quite as stringent QC.

Both of these are why looking at margins alone doesn't give you a complete picture.

While that's true, I've also read years and years of stories about how virtually every PC maker other than Apple is dancing on a razor's edge due to paper-thin margins. Dozens of manufacturers in the last two decades have gone under, been bought out or left the market; PC laptops used to be (and may still be, in some cases) crapped up with bloatware and festooned with stickers because each sticker you have to peel off and each bit of software you don't want is necessary extra revenue; the survivors like HP and Dell seem to bring in more profit through enterprise-level service contracts than hardware. And in the smartphone business, there have been quarters where Apple and Samsung together are making more than 100% of the profits because everyone else lost money.

...so, it at least seems plausible to me that Apple may be setting the prices for their PCs and "post-PC" products more correctly than most of their competitors. Even if that's true, the Apple Tax could still be a thing -- but the premium may be magnified by the "lose money on every unit and make it up in volume" tactic so many PC makers seem to have had through the 2000s.

Is there anything wrong about making a profit on a product you sell? How are they supposed to grow their business otherwise?

Sorry, but the Apple Tax is very real on their computers. Laptops, eh, it's probably not that bad compared to the other high end PC brands. But it's still there. Desktops are Apple Taxed to hell and back.

Not just hating here either. I've owned numerous Apple machines, and still use a Macbook (with Ubuntu).

If that's the case, then why haven't other PC manufacturers come in and swept that market from them? People still buy iMacs and MacBooks in droves and they gladly pay those costs. If there was nothing more than an arbitrary Apple Tax (instead of something more real like R&D costs, build costs, etc.) then it should be easy for a company to ape what Apple has done, charge slightly less, and completely remove them from the market. They haven't and they won't for precisely the fact that it's not just an arbitrary markup.

I don't object on consumer price. Most IoT stuff is priced at "can't possibly be any good".

My concern with requiring a specific hardware solution was that it leaves you utterly at the mercy of Apple; if you get rejected by their program (which they do quite capriciously with apps) then you're completely sunk by having committed to an Apple-specific expense. Allowing a software security solution lets people justify a good product by appealing to Apple without being quite as beholden to their opaque decision making.

Using high level encryption standards seemed to be the sticking point in early devices. Standard chips ran the authentication protocols too slowly.

http://appleinsider.com/articles/15/07/22/homekit-market-hel...

However, getting the fundamentals correct definitely includes using high level encryption protocols, and we've seen what happens with devices that do not do so.

spot on - I feel they could have used more of that cash hoard to actually sponsor more consumer products. Frankly surprised they didn't go after more hardware partners from the initial launch date. Despite being a "kit" its almost a second tier one compared to others.

Just part of "apple needs to connect more with its (3rd party) devs" I guess.

If the article is accurate in stating that homekit devices do not require an internet connection to work, that's big. That's what iot should be, IMO. There should be zero dependence on any hardware out of my house, except electricity of course.

All your house are belong to us. - Apple.

Being tied to a cloud service is unacceptable. Cloud services only have lives of a few years before they disappear or change incompatibly. Houses need 20 to 50 years of support.

It's like everyone forgot http://uk.businessinsider.com/googles-nest-closing-smart-hom...

I don't understand why IoT and home automation has to be so complicated. Why don't we just make devices consume/expose some semantic description of the state of the world, and call it a day?

Below is an example using RDF, SPARQL, and some made-up ontologies.

Here's my kitchen light.

    @prefix rdf:       <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
    @prefix lightBulb: <http://example.org/models/lightbulb/> .

    <http://example.org/people/9876543210> _:me
    <http://example.org/things/0123456789> _:kitchen-light

    _:kitchen-light rdf:type <http://example.org/models/lightbulb>
    _:kitchen-light lightBulb:hasOwner _:me .
    _:kitchen-light lightBulb:hasName "Kitchen light" .

Let's turn it on.

    _:kitchen-light lightBulb:isOn true .

Which of my lights are turned on?

    SELECT ?light ?name
    {
        ?light rdf:type <http://example.org/models/lightbulb> .
        ?light lightBulb:hasOwner _:me .
        ?light lightBulb:isOn ?isOn .
        ?light lightBulb:hasName ?name
    }

Now make it work remotely in NATed environments.

And make it work for low power/battery driven electronics which don't have the power budget for WiFi.

Oh and they don't have a whole lot of RAM and CPU cycles to spare, so pulling in an XML library isn't really the option of choice.

And how should authentication work, including initial setup?

It's a lot more complicated when you drill into the details. You might be willing to accept a bunch of trade-offs, but that will limit this to a niche product.

> You might be willing to accept a bunch of trade-offs, but that will limit this to a niche product

Several years ago I was helping a guy that had a home automation product with a scriptable interface. This was when X10 was prevalent.

He was very proud of it and described all the behaviors he'd coded in loving detail. But one stuck out in my mind: "When I get into bed, the lights go out!" "But", I said, "what if you wanted to read in bed?" He glared at me: "The Bed is for SLEEPING."

These systems need to work for us, and not require us to bend to what they're capable of.

This is why I ended up writing my home automation software. I want it to do what I want, what makes my life easier. Not what makes a better product.

The schema for representing device state is only one small piece of the problem.

Congratulations. You "solved" the easy part.

Reply on news.ycombinator.com