Amazon, Apple, Google, and Zigbee Alliance have partnered to create Project Connected Home over IP (CHIP) working group aiming to develop a royalty-free, Smart Home standard to increase compatibility among products, and with security at the forefront.
The new standard will be separate from Zigbee 3.0 / Pro, and Zigbee Alliance board member companies such IKEA, Legrand, NXP Semiconductors, Resideo, Samsung SmartThings, Schneider Electric, Signify (formerly Philips Lighting), Silicon Labs, Somfy, and Wulian will also join the CHIP working group and contribute to the project.
The standard specified by Project Connected Home over IP will rely on existing technology from the networking layer including TCP/UDP transport protocol, IPv6 network and various physical & media standards such as WiFi, Ethernet, Bluetooth LE, Cellular, 802.15.4 and others.
Instead, it will define what happens at the application layer level with the following points of focus:
- End-to-end data security and privacy among in-home and mobile devices, and cloud services.
- A unified and standardized baseline set of out-of-box setup components.
- Platform and ecosystem-agnostic technology (any device, any ecosystem).
- Reducing one-off gateways and translators by building upon IP
- A consistent programming model for devices, mobile, and cloud.
Project CHIP will not attempt to standardize the user interface, only communication between devices to improve interoperability. The new Smart Home standard will eventually be implemented in Amazon’s Alexa Smart Home, Apple’s HomeKit, Google’s Weave and leverage the Zigbee Alliance’s Dotdot data models.
The first draft specification and a preliminary reference open-source implementation are expected in late 2020. You’ll find more details on the official website.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
zigbee, dead on arrival spec, designed by marketing folks, the most ugly spec I have seen which is why it never prevailed.
It is not just Zigbee – it is Wifi, Thread (802.15.4, Nest) and Bluetooth. Zigbee is a legacy piece.
My personal favorite is everything mains powered on wifi, battery devices on BLE. Then sprinkle in ESP32s to do the bridging. That is conveniently done with ESP32 based dimmers. Each dimmer can easily see the BLE devices in the room.
But still: Some kind of proprietary standard. Can we just stick to open standards by the IETF and IEEE? Btw: There is SenML. Should do the job and is not designed by these companies with their own interests. I don’t like when big companies trying to enforce their interests with standards.
Please not. How about implementing SenML? How about specifying something in the IETF. All these side organizations with their own interests. If you are not one of these big companies, they will never let you be part of this. Can we just agree on using IEEE and IETF standards? Not these crappy standards from these weird organizations.
IETF specs for this usecase are mostly from the CoRE group (https://datatracker.ietf.org/wg/core/charter/). This is mainly CoAP as application layer and DTLS/OSCORE for security.
The competition is probably Web of Things. W3C standard. I highly prefer a W3C standard over some Google crap.
IP is not the answer for IoT, over v4 or v6!
You are all missing the point here lack of security in this design.
You have just increased the attack vectors exponentially.
Real IoT talks direct only to a secure IoT/IT hub with hardware root of trust using a chip like the 608a.
IPv6 is very insecure and is not the correct way to go.
You can still use your hub design. Where is the problem? The interesting part is mesh networking behind the hub. What is the issue with security? Just use end to end encryption for your data.
I suspect his problem with ipv6 is that it requires filtering at the edge while ipv4 can be lazily “just natted” at the edge. But that’s irrelevant to the protocol’s intrinsic security, it’s more about what is developed on top of it.
On the contrary for home I prefer to have IP-based devices so that I *don’t* need a gateway that becomes a SPOF and that may rely on unmaintained proprietary stuff. Better fix/upgrade/replace one device at a time when issues are raise rather than lose access to everything simultaneously.
>IPv6 is very insecure and is not the correct way to go.
Examples? (Aside for issues where privacy extensions aren’t enabled)
He is referring to the ability to directly attach all of the IPV6 devices in your house to the Internet with all of them having an exposed IPv6 address. This allows the devices to be individually attacked. As opposed to the IPv4 model where there is a NAT/Firewall in the way. Of course you can hide the IPv6 devices behind a firewall too if you choose.
There is definitely an argument that exposing a single IP address for each house from a firewall/router is more secure. Especially if there is a company that continuously monitors and updates the firewall. And of course not very many firewalls are being monitored and updated.
There is a lot to be said for shutting off all of the ports on the home firewall and then maintaining an open SSL connection to a proxy server. Main IOT devices use this scheme.
BTW, I used to think the 608A was a high security solution. But then I started talking with the guys implementing ARM Trustzone. The 608A is pretty much useless. If the device gets compromised, the hostile program can simply ask the 608A to encrypt whatever it want. The hostile program does not need access to the the SSL key, it can simply instruct the 608A to use them. The only way to secure the 608A is to insert a UI challenge into the sequence where a human has to enter a code. Secure boot does not help, most of these attacks are RAM based.
Trustzone is vulnerable to the same type of attacks. So they are working on a way to enforce code signing on the program asking Trustzone to do things. This code signing would be reverified at run-time by the Trustzone hardware to thwart RAM based attacks.
My current position is to abandon the 608A and only use CPUs with Trustzone. Then rely on ARM to continually harden the Trustzone implementation.
Too little too late. A huge amount of products are already out there and now you’re asking them to add yet another thing aside from talking to AWS IoT or similar, their own local network protocol and/or homekit and so on and so on. All in an eco-system that struggles to get even TLS right.
Just define some cross boarder APIs so that devices from different vendors can be integrated into the “smart” part of other devices (i.e. providing sensor readings) and leave it at that.
Why is it too late? I don’t see a huge IoT industry yet. They are all talking about it, but people are not really buying these things. IKEA has a small success with it. Nest has also some customer in the US. But if we take a look worldwide. Nah, not really. Smart watches, but that’s mainly it.
>I don’t see a huge IoT industry yet
I’ve been getting a pay cheque from the IoT industry for 6+ years now. $DAYJOB has shipped hundreds of thousands of fairly expensive smart home devices already. The time to define a common device side framework/protocol was years ago.
Even if it was due years ago there is no common solution yet, so NOW is still good
It’s too late to make adoption work. Even if all new stuff uses this common standard you won’t be able to integrate with the stuff that’s on sale right now. Cross vendor communication is done on the server side now and that’s probably how it’ll stay.
I heard already normal people telling me that they don’t like these cloud solutions or additional boxes. People just want to have one box. One box where there can connect all their devices to. We need open and free solution for this. Standards by the IETF and IEEE. SenML, IPv6, 6LoWPAN, RPL, 802.11.4, CoAP. We have enough standards to make this work. Google and Co. are not helping. Not at all. They are trying to create a monopoly. People can then decide which devices they want to use. Like people choosing their Notebooks or PCs. You can also put Windows or a linux distro on your machine. You are free to choose. And it has to be the same situation in the IoT. Otherwise, all these companies will eventually die.
>I heard already normal people telling me that they don’t like these cloud
>solutions or additional boxes
I don’t think people care too much about the cloud part and it’s not going away either way. Almost all of the unique selling point of almost all smart home products depends on IP that is in the cloud and consumers aren’t really buying hardware anymore. They are paying for some cheap hardware + some software-as-a-service that’s in the cloud.
>People just want to have one box. One box where there can connect all their devices to.
AKA their wifi access point. It isn’t ideal but unless you need years of battery operation or long range it’s usable, everywhere and vendor neutral. If you do need years of battery operation etc then you probably have other requirements that mean a one fits all solution isn’t going to work anyways.
Instead of dicking around with yet another standard they should spend their spare cash on fixing the issues with components like lwip that everyone is using but not maintaining.
> I don’t think people care too much about the cloud part and it’s not going away either way.
In Europe, they do.
> They are paying for some cheap hardware + some software-as-a-service that’s in the cloud.
You can have both. Having it locally and paying for the service, updates etc.
> AKA their wifi access point. It isn’t ideal but unless you need years of battery operation or long range it’s usable, everywhere and vendor neutral.
True. There is just one issue: The ports are not open. It always means, the sensor has to push data. Not the best design. Would be nice to have a box which supports all the standards and can collect the data. People can have additionally the cloud service. For better access to their data on the go. etc. Security provided by the service provider etc. I think that is the future. Of course: Some people just don’t care and they are happy with some kind of web-based solution.
> Instead of dicking around with yet another standard they should spend their spare cash on fixing the issues with components like lwip that everyone is using but not maintaining.
I completely agree. There is already the Web of Things. Why don’t they just implement this and provide nice libraries for it? I guess, because they want to have all the users in their shitty standards. So, that they can keep them in their ecosystem forever. All these named companies are just trying to be Apple. This bullshit makes me really aggressive.
>In Europe, they do.
Do you have any references for that. I’m not trying to trip you up or anything. Just wondering what the great divide is between the US and EU. I know the EU government(s) are a lot stricter on the data side of things but I’m not sure about the consumer actually caring if stuff using the cloud or not.
>You can have both. Having it locally and paying for the service, updates etc.
I think homekit has proven the local part to mostly be novelty. For something to be “smart” you either need some sort of cloud based IP that does something or some sort of local ML or something that is a bit more than some logic and timers. A lot of the time the smart part comes from some external data. As soon as you go local you are limited to what the device can do on it’s own (usually not much as the whole model is SaaS) with the limited data it has. In the homekit case in a lot of ways you go from something that is a genuinely smart device to something that is a glorified relay or timer.
>True. There is just one issue: The ports are not open.
>It always means, the sensor has to push data.
Push is the only way to do it. I don’t want google or amazon connecting into my network especially into a device that can just about barely manage one TLS connection.
>Would be nice to have a box which supports all the standards and can collect the data.
Yes and you don’t need to track 10 different standards for local IoT to get that. Vendors just need to define a cross-border API at the cloud level with some sort of standardised data format. We already have cross-border APIs that allow stuff like IFTTT to work. That just needs to be formalised so vendors don’t need to write an integration for everything consumers want to plug together.
>Why don’t they just implement this and provide nice libraries for it?
Coming up with new shiny things that you can do a talk about and sell a book about is much more interesting than fixing all of the stupid DNS response handling bugs etc in libraries that are shipping out to consumers and putting them at risk.
> Do you have any references for that. I’m not trying to trip you up or anything. Just wondering what the great divide is between the US and EU. I know the EU government(s) are a lot stricter on the data side of things but I’m not sure about the consumer actually caring if stuff using the cloud or not.
Not all of them, of course. But you have a lot of big interest groups which speak for a better privacy protection. One result was GDPR. GDPR hurt EU companies more than US ones. Interestingly, all user, world wide now have better privacy protection, because of it.
Yes, there is a benefit of having some kind of ML. But people should start using stupid BI first. I worked for a big European analytics company. Everybody was talking about ML and AI. But actually they even had big issues with BI. ML is currently only used by the big players in the valley.
> Push is the only way to do it. I don’t want google or amazon connecting into my network especially into a device that can just about barely manage one TLS connection.
Collect everything at the gateway. Every sensor should be behind the Gateway. The firewall should protect them from the outside traffic.
> Yes and you don’t need to track 10 different standards for local IoT to get that. Vendors just need to define a cross-border API at the cloud level with some sort of standardised data format.
I want to have the option to keep my data locally. It is nice to have them additionally in some cloud. But I want to have the option. There are a lot of issues with these cloud only provider: If the company goes bankrupt, you cannot use your device anymore. You don’t own the data. Open source and open standards. Maybe I also don’t want to use the solution provided by the manufacture. Maybe I want to have some kind of specialized system for my industry/use-case. I want to have the freedom to choose. And this is currently the main issue.
>Collect everything at the gateway. Every sensor should be behind the Gateway.
That’s how it generally works for sensors isn’t it?
>I want to have the option to keep my data locally.
I think that goes against the business model for almost all IoT products. Again unless you are buying very dumb light bulb type things then doing something with your data + external data + some magic is the whole reason you’re meant to want the smart version of a thing.
>There are a lot of issues with these cloud only provider: If the company goes bankrupt
That’s my main issue too. I don’t think a lot of companies selling stuff into this space have actually considered what happens in 10 years time even if they happen to still be going. It’s not free to run the backend for these devices but a lot of them are sold at a fixed cost with N years of that baked in. If devices live a lot longer than expected or the cost to support them suddenly increases there are going to be a lot of issues.
I have four or five paperweights now from cloud companies going under. Devices between $50 and $200.
The idea of TCP/IP to battery powered sensors is ridiculous. Battery powered devices go to sleep. Something has to stay awake and maintain timers so that you know when the battery powered device is awake. Without this you don’t know when it is possible to send it packets. TCP/IP has no concept of intermittent device connectivity, it assumes a continuous connection.
@jon
You know when your battery powered sensor is awake over tcp/ip just like you would over lorawan: When it sends you something.
tcp/ip doesn’t actually care if the other side is ready to receive packets until you actually try to send something so if you never send anything to the device outside of a receive window, don’t lose the socket state while sleeping, don’t have nat and other junk working against you your socket could survive for a very long time. This is basically how push notifications work.
What if battery powered device configured only to send packet when sensor value changes? temp sensors might only send once every 30 minutes. Now say you want to send a packet to the device changing its configuration. How do you know when the device is awake to receive that packet?
BLE has this baked into the protocol. The two sides of the BLE connection run timers tracking when the receive window will be open. BLE can make these windows up to 10 minutes apart and only open them for a tenth of a second.
IP works ok for pushing notification out, it is locating the receive window to send something back that is missing.
My favorite model is wifi everywhere with AC power and then BLE for all battery devices. The BLE devices are proxied by the nearest wifi device. You can use TCP/IP to talk the the device proxy and then the proxy will sync to the device when the receive window is open. The proxy also shadows the device state so that it can be read any time. With right wifi hardware the proxy can even have its own IP address.
It’s called RPL in 6LoWPAN what you are looking for. You don’t use TCP/IP. You mostly use CoAP, which runs on UDP. If you miss one or two out of 4 temp data point, it is fine.
For everybody looking for an open standard: Web of Things. (W3C)