Hacker News Reader

Comment by pxlpshr | Hacker News Reader

I really wish Google/Nest would end their corporate beef with Apple and integrate with HomeKit. What happened with the openness of Google?

Instead of buying Nest's entire line to outfit the house I'm building, I'm avoiding them completely even though I think their products are at the top of their class.

Nest isn't unique anymore... neither are their cameras... and they are late to the party with the doorbell. Do I think they are great products? Absolutely!! But they aren't in a position of leverage, the market is becoming commoditized, and forcing consumers to use only your app is a poor strategy. Especially considering it wasn't until a few weeks ago did Nest's app support iPhone X's new format, MONTHs after it was available to the public.

View on HN

HomeKit is not using open standards. Google and Nest are. Your question should be reversed. Why doesn't Apple just use OpenThread or one of the competing open source IoT frameworks?

https://www.theregister.co.uk/2016/05/11/google_open_sources...

Google open-sourcing their proprietary standard classifies it as an industry standard?

I think most home automation purists would provide a contrarian argument that points to z-wave or zigbee. :)

OpenThread is an open source implementation of Thread, which is an open standard based on 6LoWPAN with 802.15.4 for mesh networking.

Come on man. I don’t even need to link the xkdc comic but I will.

How do you force companies to play nice without regulation?

https://xkcd.com/927/

Nobody, you got that all wrong. 802.15.4 and 6LoWPAN are established, quite mature standards. HomeKit is the (proprietary) challenger, that adds nothing but an ecosystem for Apple to profit from

What about Thread and OpenThread? Zwave?

Edit: What about Zigbee? Google Home? WeMo? And new to me, Bluetooth Mesh.

Exactly, here I was thinking Zwave & Zigbee are the non-proprietary industry standard for wireless communication in home automation?

Zwave is proprietary. Zigbee is "not really" open. There is no open implementation AFAIK, the application library (cluster library) is standardized and everyone is allowed to develop and sell compatible devices, yet you won't be able to fetch the code and deploy on the platform of your choice, AFAIK. In this regard Zwave and Zigbee are quite similar.

Almost all the mentioned standards are based on IEEE 802.15.4.

The difference between 6LoWPAN and and the rest of the mentioned "standards": 6LoWPAN is IPv6 "adapted"/compatible. Thread is based/extends on 6LoWPAN, and adds several missing features or replaces some parts, because similar to conventional Internet devices, you need something more than IPv6 to get things going.

HomeKit was announced in June 2014, and released September 2014.

Thread was developed at Nest. The Thread Group was announced July 2014, far into HomeKit's R&D cycle. There wasn't much, or obvious, commercial support for for years. (Although to be fair, HomeKit has taken forever to get traction, too.)

I believe that at the time Apple was also concerned about the quality and security considerations of a Thread-like system. I can't prove or cite this, but having worked with Apple engineers who worked on MFi (ironically, I worked with them at Nest, not Apple), I'm skeptical of the narrative that it was devised as a revenue source. My sense from the culture of Apple when I was there (90s) and everything I see coming out of there more recently is that Apple tries to maintain standards of peripheral quality, security, and compatibility and that have been difficult to find in the Android ecosystem, say, although this has been detrimental in the case of HomeKit adoption and they've finally backed off.

Thread was developed in the Thread Group, and like any standardization body, was (and is) open for any company to join at a variety of membership levels.

All members had input in the specification, and subsequent specs.

Sweet. Where’s the link to the reference server implementation, and how do I point a nest thermostat at it instead of google? /s

You seem not to be aware that thread is a networking protocol, not an application protocol. Are you perhaps thinking of weave?

Edit: also, homekit uses either IP (usually WiFi) or Bluetooth LE. It's very different than thread.

https://nest.com/weave/

I know you're being sarcastic, but for folks who are actually interested, you can request access to the Thread 1.1.1 specification here [1], and you can contribute to Nest's open-source implementation of Thread here [2]

[1] - https://www.threadgroup.org/ThreadSpec [2] - https://github.com/openthread/openthread

This is something of an absurd argument when Apple's modus operandi is to, for example, enforce Apple Music as the only native HomePod music service.

And as a sibling comment mentions, HomeKit is not as open as what Google and Nest already use. The onus is on Apple.

Apple's playbook is to launch with APIs for internal use and then, frequently, open them. Examples include iOS support for third-party apps, third-party access to a number of watchOS 2.0 APIs, and third-party access to iOS APIs such NFC, Touch ID, camera overlays, etc. etc. Apple is also ruthless about omitting features (copy/paste, anyone?) from 1.0 releases.

This is in contrast to hardware support, which has tended to contract (floppy drives, CD drives, Ethernet cables, USB jacks, iPhone headphone jack).

It also makes sense to many of us who have done platform development and/or supported public APIs.

I'd want more evidence before concluding that HomePod's initial limitations are an M.O rather than an MVP.

They have had internal support for voice-controlling your music since iOS 1. They had a cross-application API that let you voice control arbitrary music apps on Mac OS since at least 10.4, probably earlier. Music has been a core feature of the iPhone since they day it launched.

It isn't an accident that they've failed to extend voice support to third parties after ten years. If they did plan to add it any time soon, they would have easily been able to get that to market before HomePod. They decided they'd rather continue trying to shove users into their subpar Music service, instead of supporting what users actually want and use.

Conclusion: Don't Buy unless the only audio service you ever use is Apple Music.

a small quibble:

> Apple's modus operandi is to, for example, enforce Apple Music as the only native HomePod music service.

(emphasis mine). I think you mean "natively support". You can send anything you like via their proprietary airplay service (like chromecast). "Enforce" is appropriate for, say, their requirement that iOS apps come only via their app store.

Historically Apple, like others, play nice with standards when they are the underdog (the NeXT, and thus MacOS X.<small-integer>) was all about open standards like JPG, though they also paid the danegeld for things like the RTF and GIF licenses. The iPod not only supported mp3 but they openly encouraged ripping CDs. Hell, Steve Jobs paid us actual money to make gcc & objective-C++ gret on the NeXT (though he had a really good team already in place as well). Then as they gained more power they cared about openness less.

Google was similar; they have a better committment to open source than Apple does but also try to use their market muscle to do things like their own mobile page format.

In case I sound like an apologist, I also prefer open interoperability. But I am realistic about looking at the landscape.

Not true.

For similar - see Android Auto / Apple Carplay, where Android can use any music/map service, but the Apple version is limited to theirs.

I have my issues with Google but they're like night and day when it comes to interoperability.

I don't follow. I use Spotify's native app on CarPlay.

He's referring to Maps/Google Maps. You can't use Google Maps on CarPlay

Spotify is on CarPlay https://support.spotify.com/us/listen_everywhere/in_the_car/...

The thing Apple limits music-wise is Siri. You can't use voice control to tell Spotify what tracks to play.

Integrating with HomeKit requires adding a HomeKit specific chip to each device. It would require them to reengineer all their products and drive up the cost - it's Apple being closed here, not Google.

This is no longer true as of iOS 11.3: https://www.cnet.com/news/apple-confirms-homekit-software-au...

How much security did they sacrifice when they made this change?

I agree it was a very poor decision that lost them a lot of ground to Alexa – but that was HomeKit 1.0. Apple dropped that requirement last year at WWDC.

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

"If you're interested in developing or manufacturing a HomeKit accessory that will be distributed or sold, your company must enroll in the MFi Program."

Then see the NDA you must sign just to apply to the MFi program: https://mfi.apple.com/MFiWeb/getOnLineNDA.action

Take some wild guesses what you must agree to in order to get accepted to MFi.

I find homebridge easier to use than I thought. I know it's not the real solution, but it is the geek solution.

Using homebridge with the smartthings plugin is more responsive than smart things itself ironically enough.

https://www.npmjs.com/package/homebridge-nest

Reply on news.ycombinator.com