5 ms·

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 Ne

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.

nwah1 9y ago
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_thread_in_bid_to_win_iot_standards_war/ https://www.theregister.co.uk/2016/05/11/google_open_sources...
- pxlpshr 9y ago
  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. :)
  - jotux 9y ago
    OpenThread is an open source implementation of Thread, which is an open standard based on 6LoWPAN with 802.15.4 for mesh networking.
    - wil421 9y ago
      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/ https://xkcd.com/927/
      - bipson 9y ago
        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
        wil421 9y ago
        What about Thread and OpenThread? Zwave? Edit: What about Zigbee? Google Home? WeMo? And new to me, Bluetooth Mesh.
        afishisafish 9y ago
        Exactly, here I was thinking Zwave & Zigbee are the non-proprietary industry standard for wireless communication in home automation?
        bipson 9y ago
        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.
- osteele 9y ago
  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.
  - oflannabhra 9y ago
    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.
    - hedora 9y ago
      Sweet. Where’s the link to the reference server implementation, and how do I point a nest thermostat at it instead of google? /s
      - Godel_unicode 9y ago
        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/ https://nest.com/weave/
      - oflannabhra 9y ago
        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 https://www.threadgroup.org/ThreadSpec [2] - https://github.com/openthread/openthread https://github.com/openthread/openthread
Andrex 9y ago
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.
- osteele 9y ago
  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.
  - JeremyBanks 9y ago
    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.
- gumby 9y ago
  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.
woolvalley 9y ago
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 https://www.npmjs.com/package/homebridge-nest
sofaofthedamned 9y ago
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.
- pxlpshr 9y ago
  I don't follow. I use Spotify's native app on CarPlay.
  - djchen 9y ago
    He's referring to Maps/Google Maps. You can't use Google Maps on CarPlay
- wlesieutre 9y ago
  Spotify is on CarPlay https://support.spotify.com/us/listen_everywhere/in_the_car/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.
deleted 9y ago
[deleted]
ClassyJacket 9y ago
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.
- neon_electro 9y ago
  This is no longer true as of iOS 11.3: https://www.cnet.com/news/apple-confirms-homekit-software-authentication-for-ios-11-3/ https://www.cnet.com/news/apple-confirms-homekit-software-au...
  - gumby 9y ago
    How much security did they sacrifice when they made this change?
- pxlpshr 9y ago
  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.
randomfool 9y ago
From: https://developer.apple.com/homekit/ 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 https://mfi.apple.com/MFiWeb/getOnLineNDA.action Take some wild guesses what you must agree to in order to get accepted to MFi.

nwah1 9y ago

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_thread_in_bid_to_win_iot_standards_war/ https://www.theregister.co.uk/2016/05/11/google_open_sources...

pxlpshr 9y ago
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. :)
- jotux 9y ago
  OpenThread is an open source implementation of Thread, which is an open standard based on 6LoWPAN with 802.15.4 for mesh networking.
  - wil421 9y ago
    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/ https://xkcd.com/927/
    - bipson 9y ago
      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
      - wil421 9y ago
        What about Thread and OpenThread? Zwave? Edit: What about Zigbee? Google Home? WeMo? And new to me, Bluetooth Mesh.
        afishisafish 9y ago
        Exactly, here I was thinking Zwave & Zigbee are the non-proprietary industry standard for wireless communication in home automation?
        bipson 9y ago
        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.
osteele 9y ago
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.
- oflannabhra 9y ago
  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.
  - hedora 9y ago
    Sweet. Where’s the link to the reference server implementation, and how do I point a nest thermostat at it instead of google? /s
    - Godel_unicode 9y ago
      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/ https://nest.com/weave/
    - oflannabhra 9y ago
      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 https://www.threadgroup.org/ThreadSpec [2] - https://github.com/openthread/openthread https://github.com/openthread/openthread

Andrex 9y ago

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.

osteele 9y ago
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.
- JeremyBanks 9y ago
  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.
gumby 9y ago
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.

woolvalley 9y ago

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 https://www.npmjs.com/package/homebridge-nest

sofaofthedamned 9y ago

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.

pxlpshr 9y ago
I don't follow. I use Spotify's native app on CarPlay.
- djchen 9y ago
  He's referring to Maps/Google Maps. You can't use Google Maps on CarPlay
wlesieutre 9y ago
Spotify is on CarPlay https://support.spotify.com/us/listen_everywhere/in_the_car/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.

deleted 9y ago

[deleted]

ClassyJacket 9y ago

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.

neon_electro 9y ago
This is no longer true as of iOS 11.3: https://www.cnet.com/news/apple-confirms-homekit-software-authentication-for-ios-11-3/ https://www.cnet.com/news/apple-confirms-homekit-software-au...
- gumby 9y ago
  How much security did they sacrifice when they made this change?
pxlpshr 9y ago
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.

randomfool 9y ago

From: https://developer.apple.com/homekit/ 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 https://mfi.apple.com/MFiWeb/getOnLineNDA.action Take some wild guesses what you must agree to in order to get accepted to MFi.