5 ms·

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 o

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?

CHY872 12y ago
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 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.

CHY872 12y ago

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 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.