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… Read more »
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… Read more »
>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… Read more »
> 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… Read more »
>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… Read more »
> 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… Read more »
>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… Read more »
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… Read more »
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)