6 ms·

Dear Apple, please use industry standards. BACnet is a ISO, ASHRAE and ANSI protocol.

CHY872 12y ago
That's fantastic, but says nothing about the relative merits of BACnet. It's an industry standard, yes, as I understand it typical of a modern business unit, but that does not mean that it should be the one used by any new adopter. Indeed, BACnet's been around for so long now (and has such poor takeup in the consumer space) that one might wonder whether a newer protocol is necessary. As I understand it, BACnet has a number of drawbacks that make it unsuitable for this kind of thing. In particular, BACnet is not really plug-and-play (and is not designed to be), supports a relatively small number of transport protocols (one could imagine this Apple system eventually encompassing BlueTooth, ZigBee etc). Furthermore, it's not really a secure standard as I understand it - access to the WiFi network would essentially give control of all the devices. Current solutions aren't really much better, but it needs to be the primary concern (and I suspect that Apple have considered it). As one example, BACnet best practice is currently to have parts of the network that have to be in userspace (temperature sensors, door sensors (as opposed to lifts, aircon)) is to place them on separate physical networks. Even moreso, it's kinda usually implemented right above the link layer (which violates the hourglass principle, if nothing else), and there are issues that will come up in the near future with the alternatives (BACnet/IPv6 being an issue (i.e. most BACnet/IP devices will stop working as networks switch to IPv6)). BACnet is probably fine in the enterprise domain, where everything is installed at building construction time, there are people who manage this stuff for a living, and things like airgaps are desirable as well as necessary. In the home domain, it's at least overkill, and makes things incredibly difficult for users. It's entirely fair for Apple to go their own way. Trying to do a standards-based approach at the moment would be a horrendous idea - firstly I know a large number of companies to be trying to come up with their own solution at the moment, but secondly it would just end up being a standard by committee (with no real implementers). Let the competitors hash it out for a few years, and then standardise the best one.
- Frozenlock 12y ago
  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/Overview.aspx 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?

That's fantastic, but says nothing about the relative merits of BACnet. It's an industry standard, yes, as I understand it typical of a modern business unit, but that does not mean that it should be the one used by any new adopter. Indeed, BACnet's been around for so long now (and has such poor takeup in the consumer space) that one might wonder whether a newer protocol is necessary. As I understand it, BACnet has a number of drawbacks that make it unsuitable for this kind of thing. In particular, BACnet is not really plug-and-play (and is not designed to be), supports a relatively small number of transport protocols (one could imagine this Apple system eventually encompassing BlueTooth, ZigBee etc). Furthermore, it's not really a secure standard as I understand it - access to the WiFi network would essentially give control of all the devices. Current solutions aren't really much better, but it needs to be the primary concern (and I suspect that Apple have considered it). As one example, BACnet best practice is currently to have parts of the network that have to be in userspace (temperature sensors, door sensors (as opposed to lifts, aircon)) is to place them on separate physical networks. Even moreso, it's kinda usually implemented right above the link layer (which violates the hourglass principle, if nothing else), and there are issues that will come up in the near future with the alternatives (BACnet/IPv6 being an issue (i.e. most BACnet/IP devices will stop working as networks switch to IPv6)). BACnet is probably fine in the enterprise domain, where everything is installed at building construction time, there are people who manage this stuff for a living, and things like airgaps are desirable as well as necessary. In the home domain, it's at least overkill, and makes things incredibly difficult for users. It's entirely fair for Apple to go their own way. Trying to do a standards-based approach at the moment would be a horrendous idea - firstly I know a large number of companies to be trying to come up with their own solution at the moment, but secondly it would just end up being a standard by committee (with no real implementers). Let the competitors hash it out for a few years, and then standardise the best one.

Frozenlock 12y ago
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/Overview.aspx 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?