[00:00.000 --> 00:13.400]  Good morning, everybody. I'm happy to see such a large crowd here. I hope I can stand
[00:13.400 --> 00:22.840]  up for that. So, I will talk a little bit today about, a little bit about matter and
[00:22.840 --> 00:29.240]  threat as a connectivity solution for embedded here. So, the agenda I have, I mean, giving
[00:29.240 --> 00:34.040]  a little bit of a scope for the talk, then give you an overview about matter. So, I don't
[00:34.040 --> 00:38.040]  know how is Temmler with that, how is Temmler with open threat and so on. So, we'll start
[00:38.040 --> 00:44.480]  a little bit with that. Then, how I'm using it or what we are doing using it on Yachto
[00:44.480 --> 00:51.160]  as well as on Zephyr. And then, also how we are using matter on top of open threat. Talking
[00:51.160 --> 00:56.520]  about the more generic mesh capabilities that threat is offering you and the border router
[00:56.520 --> 01:01.520]  that is needed to get it all hooked together. And then, about one more detail that has just
[01:01.520 --> 01:08.640]  have been introduced about like multicast DNS discovery proxy, as well as service integration
[01:08.640 --> 01:13.360]  protocol. And then, how I tied it together for our use cases as a transparent gateway
[01:13.360 --> 01:19.800]  blueprint. So, I only have 20 minutes. So, if I'm rushing it a little bit, don't worry.
[01:19.800 --> 01:24.400]  The slides are available. There's also like a lot more slides after the, as a appendix,
[01:24.400 --> 01:29.640]  we can look them up later on as well. So, for the scope here, my goal and my ideas have
[01:29.640 --> 01:34.840]  been like going, we need to do something for low power, it should be wireless. I wanted
[01:34.840 --> 01:39.720]  to have IP version 6 end-to-end connectivity. I want to look for the, for power budget.
[01:39.720 --> 01:44.840]  So, having for example, small sensor devices that can run on a coin cell battery for whatever,
[01:44.840 --> 01:50.320]  six months, a year, maybe two years, depending on the use cases and the usage. And having
[01:50.320 --> 01:54.680]  mesh capabilities that don't have only like direct connections, but we like being able
[01:54.680 --> 02:01.280]  to extend the network over time by adding more devices and so on. And for the situation
[02:01.280 --> 02:04.960]  with the power budget, sleepy end devices that really only wake up if they are being
[02:04.960 --> 02:09.760]  interrupted for a specific use case or only waking up for a short amount of time to querying
[02:09.760 --> 02:14.640]  the parent to get data that is also something I considered here. All the stuff I'm talking
[02:14.640 --> 02:20.920]  about here are obviously open source solutions. Thread as well as Meta have consortiums around
[02:20.920 --> 02:27.080]  them to like do products and do like testing and verification, as well as getting a certification
[02:27.080 --> 02:30.920]  and so on. This is definitely something different. So, if you want to build a product, you might
[02:30.920 --> 02:34.920]  need to pay for some specific parts, but all the software side or the engineering side
[02:34.920 --> 02:40.800]  that is open source here and that's what I'm going to talk about. So, Meta. Some people
[02:40.800 --> 02:45.440]  might have heard about it before. It was formerly known as connected home of IP or ship, in
[02:45.440 --> 02:53.320]  short. It is part of the now so-called CSI, connected with standard alliance. That, on
[02:53.320 --> 02:56.520]  the other hand, was called Zigbee alliance before. I think that is something that rings
[02:56.520 --> 03:05.680]  the bell with more people than CSA. They have an open source SDK for Meta. It's an application
[03:05.680 --> 03:10.840]  layer. So, you're basically like not doing any of these. So, it's built on top of IP version
[03:10.840 --> 03:16.080]  6 and then does all the talk about like how devices access, how the data is expressed
[03:16.080 --> 03:20.000]  and so on, what kind of device types are there. It's more like they call it like the language
[03:20.000 --> 03:24.000]  for IoT. I don't know if I sign off on that, but that's like the basic idea we're having
[03:24.000 --> 03:31.640]  here. So, the 1.0 release for the spec as well as the SDK was done in October last year.
[03:31.640 --> 03:35.840]  And one of the interesting part why it got so much hype is like this industry was that
[03:35.840 --> 03:40.000]  a lot of the big players are sit together and doing that here. So, getting like groups
[03:40.000 --> 03:44.440]  like Google, Apple, Amazon and so on in one room and working together on this standard
[03:44.440 --> 03:50.680]  to actually try to get all the devices to talk together even by keeping their own platforms.
[03:50.680 --> 03:54.920]  That is like a very interesting part. And that could be something that a lot of smaller
[03:54.920 --> 04:02.040]  companies could take as a leverage to get into these kind of platforms to be supported
[04:02.040 --> 04:07.040]  instead of working with each and every platform individually and get it enabled. So, you don't
[04:07.040 --> 04:13.280]  need to get your device, work with home kids and with Google Home or what Amazon have their
[04:13.280 --> 04:18.840]  accounts on. So, you can just do it as a meta device and then it should work in all of them.
[04:18.840 --> 04:23.360]  They also have a feature called multi-admin, which is something that would allow you to
[04:23.360 --> 04:28.600]  have like an, for example, you have an Android device and your wife has an iPhone or whatever
[04:28.600 --> 04:34.000]  and both could control the same IoT devices in the same network running the native platforms
[04:34.000 --> 04:38.000]  they are using. So, this is something you can share the devices by using on different
[04:38.000 --> 04:48.040]  platforms as well. So, meta in Yocto and open embedded. So, the meta SDK, the way they
[04:48.040 --> 04:53.840]  are building that and so on, it's not so, I'm not so familiar with that before I started
[04:53.840 --> 04:57.720]  it. So, they are using something called GN, which is just generate ninja. So, basically
[04:57.720 --> 05:02.080]  just does a whole run and then generate all the ninja files to get it all built. And they
[05:02.080 --> 05:06.680]  have something called PickWeep that they, it's like their abstraction, how you get
[05:06.680 --> 05:11.240]  like all different kind of vendor SDKs supported and like different cross-compiled two-chains
[05:11.240 --> 05:17.400]  and so on. This is like difficult to get that into something like Yocto open embedded which
[05:17.400 --> 05:23.080]  just focus on the cross-compiling part here. So, that was quite a bit of work. So, we had
[05:23.080 --> 05:28.280]  to do like a GN base class to get it supported and do a lot of like work around here. But
[05:28.280 --> 05:32.920]  in any way, we got that part working. So, we have the core libraries building. We have
[05:32.920 --> 05:38.880]  the examples that are part of the SDK building. We have that all in the, in our Neo layer.
[05:38.880 --> 05:45.400]  But there's also a different layer from NXP meta meta meta which does it a little bit
[05:45.400 --> 05:48.680]  differently. But in the end, you're getting the same result. You have like integration
[05:48.680 --> 05:54.240]  to run that on a, on a Linux system. So, this is, that is all there. You can, you can take
[05:54.240 --> 06:00.600]  that and then build on top of the library and take the examples devices to like do whatever
[06:00.600 --> 06:06.600]  you want there. On the meta, on the Zephire side. So, on here is a project that runs not
[06:06.600 --> 06:10.680]  only on Linux, but we also run it on the Zephire side. So, we have like multiple kernels there.
[06:10.680 --> 06:15.120]  So, we all those need to make sure that we want to have the integration part there as
[06:15.120 --> 06:19.800]  well. I'm, I have been working on a proof of concept to get meta as a, as a sub module
[06:19.800 --> 06:27.600]  or as a Zephire module integrated. So, the build system would, inside the meta SDK, there
[06:27.600 --> 06:32.400]  is like a platform abstraction for Zephire which is based on two SDKs from I think Nordic
[06:32.400 --> 06:38.120]  and T-Link. The SDKs are based on Zephire as well. And they have like a generic Zephire
[06:38.120 --> 06:43.800]  abstraction now. And then we have the integration part where we have a CMake file and so on
[06:43.800 --> 06:49.200]  to hook that into the Zephire build system. We are an external module. And you have like
[06:49.200 --> 06:54.720]  a specific module, a jumble file that just tells where the CMake file is, how is the
[06:54.720 --> 06:59.680]  setup, how the build set up is and so on. And then you are setting things like open
[06:59.680 --> 07:03.600]  thread with dependencies on. This is not ready yet. So, that's why I have no link here.
[07:03.600 --> 07:08.440]  I'm still working on that. I hope to get it ready, but as always takes a bit more time
[07:08.440 --> 07:12.760]  than expected. But that's definitely something that could be interesting to get that running
[07:12.760 --> 07:16.520]  on the Zephire side as well. So technically, it's possible. I saw it working in the different
[07:16.520 --> 07:21.360]  other SDKs. But for our use case, we wanted to have it working with Zephire upstream without
[07:21.360 --> 07:29.400]  any specific silicon vendor at on and so on. So, this is why we are going this approach.
[07:29.400 --> 07:34.320]  So meta devices. So, the device types that are available in the SDK coming from the 1.0
[07:34.320 --> 07:37.920]  release are very limited. I think they only have like five device types specified right
[07:37.920 --> 07:42.560]  now. There are definitely a lot more coming and will come in the next upcoming releases.
[07:42.560 --> 07:47.280]  So, meta is doing like two releases per year in spring and autumn. So, there should be
[07:47.280 --> 07:52.680]  a lot more going on there. They are using the Zikbi cluster library. So, in case you
[07:52.680 --> 07:55.880]  are familiar with that from all the projects or something. So, they are basing their device
[07:55.880 --> 08:01.280]  types and destruction on that one, extending it a little bit and then using it. But it
[08:01.280 --> 08:06.760]  should be a very good base for your own devices. It doesn't mean it cover all the nitty details
[08:06.760 --> 08:10.240]  you have maybe on your product or something. But it could be a good entry point for cover
[08:10.240 --> 08:16.360]  the basic functionality and then for details you might leave that out and have like an
[08:16.360 --> 08:21.160]  out of band situation. Or you go to the meta working group and work with them to extend
[08:21.160 --> 08:28.080]  that over time. As usual like set up is the QR codes you might know from other devices
[08:28.080 --> 08:34.120]  already like HomeKit and so on. You can also use a pin and then you have NFC that is upcoming
[08:34.120 --> 08:39.680]  that you can use that as well. So, in terms of connectivity layers, what they are supporting
[08:39.680 --> 08:45.080]  in the beginning. That is Ethernet and Wi-Fi. There is no much need to like adapt it or
[08:45.080 --> 08:49.800]  anything. For Wi-Fi they are working on a better software. So, right now it is a soft
[08:49.800 --> 08:54.640]  API set up if you want to bring a device in. But that means you would need for example
[08:54.640 --> 08:59.840]  if you do the soft API with your phone and then you leave the connectivity to your normal
[08:59.840 --> 09:04.800]  data. So, they are working with a Wi-Fi alliance to change that as a neighboring service. So,
[09:04.800 --> 09:12.320]  that is good. Brutal store energy is also available for device onboarding. It is not a connectivity
[09:12.320 --> 09:17.560]  layer they are using on for data transmission but it is just only for onboarding. And as
[09:17.560 --> 09:23.200]  I mentioned before they have like these, if your device supports more than the device type
[09:23.200 --> 09:27.320]  expressions they are doing, you either need to work together with them to extend that
[09:27.320 --> 09:31.760]  or you need to find a way to have that as an out of bound connectivity. But here comes
[09:31.760 --> 09:36.920]  the beauty of being IPv6. You have like end-to-end connectivity to the device. And if you for
[09:36.920 --> 09:40.880]  example have like a mobile application or something that would control this, you could
[09:40.880 --> 09:45.520]  still do all the work with this method to support the basic functionality and then hand
[09:45.520 --> 09:52.280]  over to the IP to the end device over IPv6 and then control the device for like an extended
[09:52.280 --> 09:59.480]  API you might offer on the device. But Ethernet and Wi-Fi are not really the ones I was looking
[09:59.480 --> 10:05.160]  into when looking at the power budget and designing devices that are really power budget
[10:05.160 --> 10:08.960]  friendly and can run for like a year or so on a battery. So, I was looking into Thread
[10:08.960 --> 10:15.200]  for that. So, Open Thread is the open source implementation of the Thread specification.
[10:15.200 --> 10:21.440]  Thread group is the governance body again. Membership, you have to pay fee if you want
[10:21.440 --> 10:24.680]  to get certified and so on. But you don't have to do that if you are just going for
[10:24.680 --> 10:31.640]  the implementation with Open Thread. It's BST3 license. So, that's all easy for you
[10:31.640 --> 10:37.800]  to integrate in your products and so on. It's mostly driven by Google and formerly Nest
[10:37.800 --> 10:42.360]  and it has a very established code base already in products and running in the millions of
[10:42.360 --> 10:49.480]  in the world already. So, Thread is a mesh network. So, what does it cover here? So,
[10:49.480 --> 10:54.000]  you have like different types of devices that are part of the mesh network. You have full
[10:54.000 --> 10:58.240]  Thread devices which are normally devices that have like a good amount of power budget
[10:58.240 --> 11:03.720]  being either line powered or having like a big battery that they can operate on. These
[11:03.720 --> 11:07.760]  are like often like routers that can like take the packet forward to another one and
[11:07.760 --> 11:11.240]  make sure that everything, the whole data keeps flowing. And then you have like router
[11:11.240 --> 11:17.040]  eligible devices which is something that will become a router if the mesh network needs
[11:17.040 --> 11:21.520]  them later on to make sure that the data keeps flowing or if they are like in a corner of
[11:21.520 --> 11:27.960]  the mesh network where they need to increase the quality for all the other nodes available.
[11:27.960 --> 11:31.960]  Or there could be just a simple full end device which is just operating there not doing any
[11:31.960 --> 11:36.760]  routing or something but still being a full end device. And then for the power constraint
[11:36.760 --> 11:41.440]  devices you have like minimal Thread devices which are minimal end devices and they can
[11:41.440 --> 11:47.440]  be sleepy devices. So, basically they would like spend most of their lifetime just being
[11:47.440 --> 11:53.040]  asleep not drawing or drawing as little power as possible and only wake up if they are getting
[11:53.040 --> 11:56.480]  an interrupt like when you open your window or something like that you want to send the
[11:56.480 --> 12:02.240]  notification out for that or you call, you just have a short poll to a parent and ask
[12:02.240 --> 12:08.640]  if there is any data left for you. So, they are using 15.4 as a base layer, a file layer
[12:08.640 --> 12:13.200]  and they have a functionality where you send out a packet to if there is any data available
[12:13.200 --> 12:17.600]  for you and even in the egg frame already you have like a bit set where it says, oh,
[12:17.600 --> 12:21.600]  there is data waiting for you, don't go to sleep, call me again and then you are getting
[12:21.600 --> 12:26.520]  all the data and if not you can fall asleep already again. You can also have like in the
[12:26.520 --> 12:31.680]  newer specifications you have something that is like synchronized schedules but that would
[12:31.680 --> 12:36.720]  mean you need a newer type of like ships available not all of them do that so you would have
[12:36.720 --> 12:43.840]  to be like 15.4, the 2015 release for that so you need to find like the silicon ships
[12:43.840 --> 12:52.840]  that actually support that and then you can get that running as well.
[12:52.840 --> 12:57.680]  Okay I talked about the router things before, you have router devices, you have end devices
[12:57.680 --> 13:01.760]  and then you have a leader of the threat network. This one is in charge of making sure that
[13:01.760 --> 13:06.840]  all the key material for example is distributed to all the networks, all the keys are getting
[13:06.840 --> 13:11.000]  wrote over if they are running out of frame counter and so on that really makes sure that
[13:11.000 --> 13:16.240]  all the stuff is available and all the devices get the need information and then you obviously
[13:16.240 --> 13:20.120]  have like a standby leader if the leader is like running out of battery or like someone
[13:20.120 --> 13:23.760]  tripped over the power cable or something like that so you have all of that covered
[13:23.760 --> 13:29.800]  in the mesh functionality as well and the other important device that is available in
[13:29.800 --> 13:35.040]  such a network is the border router because you want to have these kind of things obviously
[13:35.040 --> 13:39.520]  connected to at least your home network, maybe even to the internet that's up to you but
[13:39.520 --> 13:43.760]  you want to have like more devices than only within the threat network and that is where
[13:43.760 --> 13:47.600]  the border router comes in. I will talk about that a little bit later because that's also
[13:47.600 --> 13:50.960]  relevant to the matter part for the integration.
[13:50.960 --> 13:55.920]  In terms of addressing, there's like three different types of addresses, you have like
[13:55.920 --> 14:01.400]  the link local, what you can reach directly within your range, in your wireless receiving
[14:01.400 --> 14:06.400]  range or transmitting range and then you have mesh local addressing which is like available
[14:06.400 --> 14:11.160]  in the whole mesh network and then you have like the global addresses, it's all IPv6
[14:11.160 --> 14:16.120]  addresses and they have like allow you to like individually target specific parts of
[14:16.120 --> 14:20.400]  the mesh and so on. I'm rushing through that a little bit because it's too much to go into
[14:20.400 --> 14:25.240]  all the details here in 20 minutes but it's a little bit more in the slides.
[14:25.240 --> 14:29.640]  So in terms of the software, they're having there available, there's the OpenStreet core
[14:29.640 --> 14:33.640]  library which is used for all of them, then you have abstractions for like all the different
[14:33.640 --> 14:39.240]  silicon vendors integrating with their SDKs and so on, so you can see them all there listed.
[14:39.240 --> 14:43.480]  If you have a specific device for example, running that you could, you'll burn metal on
[14:43.480 --> 14:48.640]  that as well or you could go and run it for example as an OpenStreet module on that fire
[14:48.640 --> 14:54.640]  being supported. And on the link side, they have like two basic services that are running,
[14:54.640 --> 14:59.560]  there's the OT daemon which is like the basically only a full enterprise which could operate
[14:59.560 --> 15:04.080]  as a normal enterprise in the network and then you have the OpenStreet border router
[15:04.080 --> 15:09.800]  POSIX, how they call it, that is the full border router set up that you would run on
[15:09.800 --> 15:15.680]  your Linux device if it's the border router and engaging there.
[15:15.680 --> 15:21.160]  So talking about all the power constraints you are having, so there are two advancement
[15:21.160 --> 15:26.400]  that have been happening driven by meta mostly but falling back to thread to make it even
[15:26.400 --> 15:31.560]  more power efficient. So this is a multicastiness discovery proxy and the service registration
[15:31.560 --> 15:40.080]  protocol. So I talked before, the border router is like the central part here to shield the
[15:40.080 --> 15:45.400]  mesh network from the rest of the network or the other way around.
[15:45.400 --> 15:50.480]  And this is, so if you look at a lot of the IoT devices you have maybe in your home or
[15:50.480 --> 15:54.760]  you know about, these are often like vendors where you have like one specific hub for your
[15:54.760 --> 15:58.880]  specific device types and so on. Then you have the next hub for the other types and
[15:58.880 --> 16:06.160]  so on. This is all crowded and so on. And for the border router, this is often more software
[16:06.160 --> 16:11.920]  components that can be updated in devices that are already available. So the 15.4 radios
[16:11.920 --> 16:15.560]  they are used for threads that are the same radios that are used for ZigBee. That means
[16:15.560 --> 16:20.480]  all the hubs that you might have, already have ZigBee support, it is up to the hardware
[16:20.480 --> 16:25.000]  vendor if they want to change that over to a different firmware and then all the other
[16:25.000 --> 16:29.000]  software around it to make sure they can also support thread. It's also possible to run
[16:29.000 --> 16:33.480]  like both of them in parallel if you do like multi-protocol on the firmware level where
[16:33.480 --> 16:37.080]  you have like ZigBee device support as well as thread device support. That's a bit more
[16:37.080 --> 16:41.560]  complicated but it is possible as well.
[16:41.560 --> 16:46.800]  But nowadays, one of the problems I saw when I worked with thread the first time was like
[16:46.800 --> 16:51.200]  everybody needs to get like another device being the hub and so on. But if you look around
[16:51.200 --> 16:56.280]  now, there's tons of devices already available that offer border router functionality. All
[16:56.280 --> 17:00.880]  the Apple devices like the HomePod, the HomePod mini, Apple TV, all the Google Nest devices,
[17:00.880 --> 17:04.960]  Echo and so on. All these things are like the, if you have them in your house already
[17:04.960 --> 17:08.960]  or like people, your target audience have them in the house already, it's already sorted
[17:08.960 --> 17:13.680]  out. And then there's a lot more hubs doing the support as well. The Ikea, the new Ikea
[17:13.680 --> 17:18.080]  hubs have support for it. I think that the smart things hub is going to plan support
[17:18.080 --> 17:22.040]  for it and so on. Then a lot of the smaller vendors as well are coming out hopefully over
[17:22.040 --> 17:26.120]  the years. So that means if you bring home an open thread device or a thread device,
[17:26.120 --> 17:29.240]  you shouldn't be worried to get it on board as long as you have some of these. So it's
[17:29.240 --> 17:37.120]  not as easy support as Wi-Fi for example right now but it's good in get traction there.
[17:37.120 --> 17:41.840]  But coming back to the situation about the discovery proxy. So this kind of wireless
[17:41.840 --> 17:46.760]  networks, they don't have any multicast support right? So they, whatever you send in as a
[17:46.760 --> 17:51.680]  multicast there will end up as a broadcast in the whole mesh network. Which is obviously
[17:51.680 --> 17:56.120]  not a good thing if you want to be like, if you're constrained in power and need to listen
[17:56.120 --> 18:00.360]  in and wonder what's going on. I mean the sleepy end device for them, it's not too difficult
[18:00.360 --> 18:03.760]  because they would sleep and the parents would just discard whatever they have for them
[18:03.760 --> 18:08.160]  if it's not targeted directly for the specific device. But all the other ones would still
[18:08.160 --> 18:12.680]  like draw on the batteries they're having to do that. So on the other hand multicast
[18:12.680 --> 18:17.400]  DNS discovery is something that is very much used in the industry for all kind of services
[18:17.400 --> 18:22.720]  discovery in networks. So we want to have that support as well. So there's a component
[18:22.720 --> 18:27.920]  now that has been specified as an ITF RC draft which is sitting there and doing basically
[18:27.920 --> 18:31.880]  the proxy what the name suggests right? On the one hand if you have like Wi-Fi or ethernet
[18:31.880 --> 18:37.600]  you do multicast DNS and on the other hand you do a unicast DNS service discovery and
[18:37.600 --> 18:42.440]  so on. So that is like basically proxy and back and forth. That doesn't mean depending
[18:42.440 --> 18:46.720]  on the border you're using you don't, you're not forced to that. So the end to end principle
[18:46.720 --> 18:55.800]  of IPv6 still stands but it's like an optimization you maybe don't want to miss out on. And on
[18:55.800 --> 18:59.560]  the other hand so that is mostly covering the side where you have like Wi-Fi and ethernet
[18:59.560 --> 19:03.280]  flooding into in the threat network. But on the threat side you also want to make sure
[19:03.280 --> 19:07.520]  that you announce the device that are available and so on. That is like the service verification
[19:07.520 --> 19:13.040]  protocol where you go and say I have the service available as DNS. So this is like what I'm
[19:13.040 --> 19:18.240]  offering here and they can register on the border router service for that. So that would
[19:18.240 --> 19:27.640]  mean and would distribute that again as multicast DNS on the Wi-Fi ethernet side. So that is
[19:27.640 --> 19:31.860]  like how I knit all the things together. So we have a blueprint that is like you know
[19:31.860 --> 19:36.360]  near how we talk about like proof of concept demos we are doing and we have a layer where
[19:36.360 --> 19:39.960]  we do all the integration parts here, all the open thread stuff. I upstreamed already
[19:39.960 --> 19:46.720]  they are in meta or E networking and the meta stuff that is still very much work in progress
[19:46.720 --> 19:50.680]  going on as well as the ZFIA side. But if you're interested in that, I mean it's not,
[19:50.680 --> 19:54.440]  I'm not hiding anything here. It's just not ready to show but if you're interested we
[19:54.440 --> 19:59.080]  can talk about like where these things are. So this is like an old example I had where
[19:59.080 --> 20:02.960]  I had like just a threat device being onboarded so it could like go ahead, have like secure
[20:02.960 --> 20:07.760]  code for this specific device and then you have even have an Android application to onboard
[20:07.760 --> 20:12.200]  on the network and so on and do all the stuff and then in the end with all the components
[20:12.200 --> 20:17.440]  together you have like IP version 6 connectivity. And on top of that this meta you would have
[20:17.440 --> 20:22.920]  like real device abstraction and offering all kind of platform integration and so on.
[20:22.920 --> 20:27.920]  And with that I'm done and I should have like a few minutes for questions.
[20:27.920 --> 20:57.600]  Hi there, thank you very much for that. We're currently looking at developing a matter
[20:57.600 --> 20:58.600]  device.
[20:58.600 --> 21:20.840]  So what I'm trying to understand is if I buy a matter device, it might be a matter device
[21:20.840 --> 21:27.680]  that supports Wi-Fi or it might be a matter device that supports threadover 802.15.4 which
[21:27.680 --> 21:32.680]  to my mind feels like it's going to be really confusing for people. And I'm asking as we
[21:32.680 --> 21:38.320]  go to develop this border router should we focus on supporting sensor like devices that
[21:38.320 --> 21:43.200]  are Wi-Fi devices or 802.15.4 devices or is it not that simple?
[21:43.200 --> 21:48.680]  I think you, I think it's sensible to make sure that you have at least a 15.4 radio in
[21:48.680 --> 21:54.120]  the device because I think all the sensor devices you will see coming are most likely
[21:54.120 --> 21:59.280]  to use thread. Because just power budget wise, I mean at least the feedback I saw in the
[21:59.280 --> 22:02.320]  working groups and so in the feedbacks I got in the working groups.
[22:02.320 --> 22:08.960]  Excuse me, if you're moving in or out of the room can you please do that quietly whilst
[22:08.960 --> 22:14.600]  we're doing the Q&A and try and keep the noise down to a minimum because it's getting
[22:14.600 --> 22:19.600]  very difficult to be heard here. So please be considerate to others.
[22:19.600 --> 22:29.480]  Okay, so I think you really need to make sure that you have that available because all the
[22:29.480 --> 22:33.320]  companies that are looking into that they want to like be conservative in power or something
[22:33.320 --> 22:38.960]  they are definitely going for that. So and I mean if you do the hardware setup make sure
[22:38.960 --> 22:43.440]  you have the radio available. If you enable that by default from the beginning it's up
[22:43.440 --> 22:48.240]  to you, right? I mean you can always have like the firmware available and then ship
[22:48.240 --> 22:52.920]  the device and then enable it later on. I've seen tons of devices doing that but having
[22:52.920 --> 22:57.560]  it available for the hardware to sacrifice I would not ditch that. It's like yes it's
[22:57.560 --> 23:02.920]  like a few euro maybe depending on the volume and so on but I'm pretty sure that most of
[23:02.920 --> 23:06.200]  the device will come with that. So okay.
[23:06.200 --> 23:13.240]  Hey I've got a question from online here. I'm over here. Online we have a question.
[23:13.240 --> 23:17.520]  What's the rationale for a non-router end device if it doesn't have any power management
[23:17.520 --> 23:18.920]  requirements? Can you repeat that?
[23:18.920 --> 23:25.280]  What's the rationale for a non-router end device if it doesn't have any power management
[23:25.280 --> 23:30.680]  requirements? Okay, I mean the thing is it could be a router. Normally in that case it
[23:30.680 --> 23:35.080]  would be like a read like a router, a leisure device but you maybe you don't need all the
[23:35.080 --> 23:38.440]  routers available in your network, right? I mean you have like if you have a mesh network
[23:38.440 --> 23:43.960]  and depending on how the topology is and like maybe your house or your how the environment
[23:43.960 --> 23:49.440]  is basically you have maybe enough routers available at that point. So all of the full
[23:49.440 --> 23:55.200]  end devices can do that but you might don't choose for that so.
[23:55.200 --> 24:13.400]  Okay. Okay, any more questions? Yes sir. Hi.
[24:13.400 --> 24:15.840]  So one of the most controversial parts of the spec.
[24:15.840 --> 24:19.040]  Can you a little bit louder? Sorry it's very noisy.
[24:19.040 --> 24:23.600]  So one of the most controversial parts of the spec when it was released was they were
[24:23.600 --> 24:31.440]  talking about authentication onto the network like onboarding via blockchain. Can you discuss
[24:31.440 --> 24:34.200]  that a little bit? Okay, so what I think what you reference to
[24:34.200 --> 24:39.280]  is like the distributed ledger. So having so one of the ideas that is like work around
[24:39.280 --> 24:43.680]  in the meta-working group is like the distributed ledger where you can authenticate the devices
[24:43.680 --> 24:48.240]  that are like so you're basically not getting fake device in the network and so on. That's
[24:48.240 --> 24:53.560]  definitely something that could be problematic for if you want to like do your own device
[24:53.560 --> 24:59.120]  in your own home for example and get them onboarded. I still have to see if that is really
[24:59.120 --> 25:03.040]  enforced or not. That is really depending on the platform and so on. How are you using
[25:03.040 --> 25:10.320]  that together? Yeah, but I need to hear some microphone or something.
[25:10.320 --> 25:16.560]  Have you managed to get a DIY device onto an actual Google matter network yet?
[25:16.560 --> 25:20.360]  Not on a Google network now. I was able to like getting all working together on my own
[25:20.360 --> 25:24.560]  setup but I didn't work against the platforms and so on.
[25:24.560 --> 25:26.840]  Yeah, that sort of seems like one of the problems.
[25:26.840 --> 25:32.120]  Well, we have to see. I wouldn't rule it out right now but I can confirm that it's possible
[25:32.120 --> 25:38.560]  but it really depends on how you do it. But it's definitely the concern, you're right.
[25:38.560 --> 25:42.480]  It's possible? Okay, so here someone said it's possible here.
[25:42.480 --> 25:47.200]  Okay, thank you everybody. Okay, thank you very much.
[25:47.200 --> 25:54.360]  I want to check the chat room. There's one more question on the chat room you could answer.
[25:54.360 --> 26:21.120]  Okay, I will have a look. Thank you.