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?
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.
I absolutely doubt that Apple will. Look at AirPlay. Look at AirDrop. Look at iMessage and Facetime. Even their original content formats were not all that portable.
Some of those are for technical/licensing reasons, but many are not.
If you feel compelled to mention Google Hangouts, you should note that Google abandoned XMPP federation after 8 years (2005 - 2013) since other companies built walled gardens and leeched users instead.
Yeah, that doesn't matter. They continued to use XMPP so long because it was still profitable for them to, not because of some implied ethical stand on open software. Android is "open" because it is more profitable for Google to give it away and make the ad/Play/certification money than it is for them to personally get into the hardware market like Apple.
> They continued to use XMPP so long because it was still profitable for them to
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.
- XMPP is deprecated as far as Google is concerned.
- 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).
I can't imagine in what situation using XMPP could be construed as "profitable". Maybe for paying Google Apps users, but I don't think too many of them depended on XMPP integration (either they have their own enterprise chat solution or they're just using Google's. Or they're not allowed chat)
How can the word "ethical" ever describe a company that gets all of its money from advertising, the business of deception and manipulation, and then deepens its pact with the Devil by trading all of our privacy for more profit and control, a company whose CEO says things like, "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place."?
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
Well I'm downvoting you for your edit, which is simultaneously childishly whiny and quite funny in its lack of awareness: read your original again, and then ask yourself if you don't think you might be coming across as a bit of an ideologue yourself.
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.
I'm agreeing with the parent. Neither of us subscribes to the commonly held belief around these parts that Google is special and lives by its "Don't be evil" tag line. I don't understand why you call my point a straw man.
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]
You didn't make an actual point. You just spouted Slashdot-esque vitriol.
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.
"How can the word "ethical" ever describe a company that gets all of its money from advertising, the business of deception and manipulation" is not a legitimate point? Are you saying just because it's anti-Google it is vitriol? Did you even read the comments i linked to?
Your whole statement assumes advertising is "the business of deception and manipulation", and you've not proven that at all. Maybe you take it as a given, but I don't. Sure, advertising can be manipulative and deceptive, but it can also be instructive and helpful.
Tell me honestly what you think of the quality and independence of news today? Why are Nielsen Ratings so important? Is news driven more by journalistic principles and pursuit of the truth, or by the profit motive?
If the truth is oxygen of democracy, then journalism is the lifeblood and distorting the truth for increased revenue is unethical.
People that still believe in google's good will and use it as a measure for the industry are really too big an amount. That's embarrassing for a community with this level of knowledge and deep understanding of IT matters.
Whether you believe it or not, companies like Facebook, Google, Dropbox etc. have so much lose by deceiving the user than Apple or Microsoft and so much to gain from the good will of the user that they will weigh doing good more than bad to keep their business running.
And yet, they do deceive their users, just in subtle ways with plausible deniability (e.g. Facebook profile options related to privacy that are poorly named. Is it just a mistake, or a purposeful decision?)
Indeed. I feel a lot more deceived by the companies you named than by Apple or Microsoft.
With them I know I am paying for a service or product and I clearly know where they take their profit.
With Google and Facebook? Not so much. With them I feel used, induced to some behaviors because that way they can profit more and so on.
I guess that's a lot more deceptive than selling high priced closed products that you can simply decide not to buy.
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.
Funny how proprietary technologies Apple make can be copied by Google if they take off? (And vice versa.) Personally I expect this to be like browser wars initially -- you'll just have to write code twice until a common standard (or wrapper) can be agreed upon.
Yeah, but many devices support both AirPlay and DLNA or whatever else. I bet we'll see devices that support both Google and Apple. Or someone will reverse-engineer the API, like they always do.
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.
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.
An ios house, connected to an ios house platform. I can imagine the conversations, i bought a Samsung home or how to jailbreak your ios home or android malware popping up on your bathroom mirrors as you brush your teeth.
The MP3 codec already existed, and touchscreens have nothing to do with a "common protocol", unless you count being a human with a capacitance as a protocol.
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
Strategically it looks smarter to interoperate with Google here. Not doing so will probably lock Google out ofthe USA to some extent but it'll surely lock Apple out of anywhere Android dominate and scrap any growth ideas from emerging markets.
I'm looking forward to things like the Almond+, which will use Z-Wave. I don't hold out hope for Apple opening anything up after the Darwin components started disappearing and after the broken FaceTime promise.
Darwin is fair enough, but FaceTime was due to a patent held by another company. The fight cost them something like $500 million but in the end there's nothing apple could do about it.
Dear "zmmmmm", it was Apple who kept inviting Google to every party they had. Default Google search in Safari, default Google Maps and YouTube on iPhone and so on and so on.
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.
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.
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.
> 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."
(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.)
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.
It appears that you're being downvoted, but I've found Wendell Berry to be one of the most insightful writers about the weaknesses of technological advances, despite the fact that he doesn't use a computer. Reading his essays would be worth the time of a lot of young programmers, if only to learn why old people scowl at their newfangled gizmos.
"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).
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.
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/).
3 and 9 do not contradict, they just aren't universally consistent.
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.
3 doesn't require that the thing replaced be good. So both 3 and 9 allow you to replace something bad with something good. I only claimed that there are examples where you can satisfy 3 and 9, not that you can always satisfy 3 and 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.)
How is technology not an aspect of people's lives? Not to mention, some aspects of people's lives might be good, but could be better. Should they not be improved? Well, not according to 9.
But this isn't really a huge leap in technology. It's existing technology being supported by Apple. It makes adoption more likely, but still far from guaranteed.
The problem is, people have been saying that about HA for the last 20 years. Home Automation has a long history of not being able to generate a large enough market.
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.
Or "I'm going to bed early, turn off all the lights". Or, "I'm having a party outdoors, turn on all the exterior lights." Or, "I'm done listening to music, turn off the audio." There are lots of use cases.
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. ;-)
I still have a bit of wireless X10 I use for a couple of rooms that never got totally rewired :-)
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.
No, it won't be a huge deal initially, but incremental changes will come with time and investment in the field.
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.
I think that there is a real opportunity for accessibility options here. For some people verbal access to changing the air conditioning or lights or whatever might make a huge difference and the more people use it for convenience the more the price will drop for everyone.
How about turning a few lights on remotely when one is unexpectedly caught working late? Now it looks like someone is home instead of looking like a big dark burglary target.
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?
It's cool if you actually replace the switches. If you don't, now you have two switches for one control, and they don't know about each other. If you do something crazy like switch off the wall switch, your fancy home automation is dead.
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'.
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.
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/), 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).
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.
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...
"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?
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 - 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.
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/
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!
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).
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'.
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.
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.
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?
Unfortunately the software API isn't very informative. As you'd expect, it's a pretty high level model, with a home object, that contains rooms, that contain "accessories", that have actions. So it's sufficient to write a home control app, but gives no info on how iOS interfaces with the devices themselves.
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.
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.
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.
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
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....
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.
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.
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.
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.
Sometimes you don't want to shrink your clothes and are looking for like 4% moisture left or something. There are tons of options left for more granular washing/drying of clothes that haven't been explored yet.
Our dryer, which wasn't very expensive, has loads of options - including to what level of dryness you want clothes done to - there are about 10 levels all the way from "completely dry" to "still a bit damp" (not the terms used).
> You can even buy locks that will unlock with bluetooth but that makes me paranoid.
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.
Every software developer in the world should read Christopher Alexander's A Pattern Language, and learn the relevance of the appearance of security versus actual security. A lock is only as strong as its context. Better lock? Did you upgrade the door frame as well?
If you liked A Pattern Language, I also recommend How Buildings Learn, by Stewart Brand. I read both of those books during a few months of unemployment suffered in the old dotcom crash of 2001, and they completely changed my way of thinking about software. I recommend them to all programmers.
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.
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.
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.
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.
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.
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.
