We'll talk about all things small and big. Big hand of applause.

Good afternoon. I am Benjamin Cabez. I work at the Eclipse Foundation. And you might or might not know that we have lots of cool open source projects for doing IoT. And today I want to talk about Light Web M2M. Who knows Light Web M2M? Who's heard of it? A few people. Well, a couple of people. Who's heard of Co-op? Maybe later, earlier this afternoon.

Okay. So, the idea is to talk about device management. And I don't have a remote it seems. Okay. Well, the thing is, of course, the IoT now we have all those cool protocols like MQTT and all those frameworks for home automation and so on and so forth. But how do you actually manage the device?

Like, when you have a fleet of devices, how do you reboot them? How do you set the settings like the cellular modem settings? How do you manage the software that's running inside the devices including maybe the firmware? How do you change the settings of the software that's running? How do you monitor that the device is communicating in a correct manner?

Like, you want to see how many bytes were sent and received and stuff like that. So, you need to do device management, right? So, usually what you will do is that you will have your devices on the field that run some sort of agent. Ideally, something that's built in the firmware and that will allow at any time from

a device management server that the device is talking to, to do actual device management. So, usually you will try to set up a secured communication, right? Either using certificates or using pre-shared keys. If your device is very constrained, that might be the best option.

But, yeah, the idea is that from the device management server, which might not actually be the server where you're, I mean, if you're doing a smart thermostat, you might not host the actual data, application data, might not live in the same server than the server that is being used for device management. But still, you need to have this infrastructure, right?

So, there are a few standards. Some of them have been around for many years. You might have heard of TR-069. OMADM is what is used basically in all your cellular, in your mobile handsets, right? This is how the carriers upgrade the radio module in your device.

And there's a new standard, a more recent standard called Lightweight M2M. It also comes from the Open Mobile Alliance, the guys who did OMADM. And, yeah, basically all those protocols are here to help you manage a fleet of devices. And no matter what is the actual software that you're running, you're really at a lower level. You want to manage the device, right?

So, Lightweight M2M is built on top of Co-op. OMADM, the previous version, was HTTP, SOAP, XML sort of stuff. I mean, there were other transports as well, but it was very heavy. And Lightweight M2M is really meant to be very lightweight.

The fact that it runs on top of Co-op means that, well, not only in terms of bandwidth, it's going to be very efficient. But it also means that actually you can have some funky ways of doing the actual transport of your device management packets in the form of short messages, like if you want to bootstrap your device over SMS, because, well, just the internet connectivity isn't there yet.

You may use SMSes for that, right? Oh, it looks like I have a duplicate. I knew I had it coming. So, yeah, basically the idea of Co-op is REST on top of UDP. You may or may not know now you know that.

So it's basically a very lightweight mechanism for doing REST. And basically what Lightweight M2M does is standardizing a set of resources, as in HTTP resources, basically that you can get, put, post to update them, query their values. And what Lightweight M2M standardizes is a set of objects, a set of resources,

if you will, that have well-known names and attributes for accessing the battery level of the device, accessing the number of SMSes you sent, the SMSes you received. And there are other initiatives actually to also standardize resources, like what is an acceleration, what is a temperature, what is a humidity.

So this would be something that the guys at Ipso are actually standardizing. So the features in a nutshell, maybe one of the most important, maybe the most impressive as well, in that it really allows with a very lightweight protocol to do firmware upgrade,

but in general you will use Lightweight M2M for doing everything, device monitoring, and you have also all the, it standardizes all the workflow to do the initial strapping of the device. Typical use case is you leave the factory, the device isn't ready just yet, right? So like you're working on the new super awesome Nest thermostat, the hardware is ready,

but the software stack, well, it's still full of bugs, and you don't even know, maybe you don't have all your server infrastructure yet, but you know that eventually there will be, there is a cellular modem, or there will be a way to reach the device, so you will be able to bootstrap the server credentials over SMS, maybe, or over other means.

So the standard objects, there is like seven of them, I think, the device, the server, you might have actually several servers, fallback servers, or everything related to connectivity, the GPS location would be available as part of Lightweight M2M as well,

the firmware, and we will see that in the demo later on, and they all have super short numerical identifiers, as in like if you were doing HTTP gets on resources that are very short numbers instead of being like huge URLs. So yeah, an object like say a location will actually have, may have several instances,

so that's how you would organize your resources hierarchy. If you're talking about a location, location is object number six, and it's very likely that there's only one instance of a location, right, on your device,

so slash six, slash zero, slash one, for example, will be attribute number one for your location, or attribute number two would be the altitude. What is nice with Lightweight M2M is that you can query either a specific resource, or you can query, or get, or update directly a complete object at once,

by issuing a request on the instance, and in that case you can retrieve a TLV encoded value, or since we are leveraging co-op in Lightweight M2M, could also be any kind of content type really, could be JSON as well. Although that might defeat the purpose of doing something that is Lightweight.

So in terms of open source implementations of Lightweight M2M, so this, I mean Lightweight M2M is an open mobile alliance specification, but it turns out that there are several companies actively working on providing open source implementations of Lightweight M2M,

licensed under the EPL and the BSD license, so those companies would be CR Wireless, they work on, I mean they do cellular modems basically, Bosch, they do tons of connected devices, Zebra Technologies, they do connect devices as well, Jim Malto starts getting interested, I mean all those players collaborate on open source implementations,

on the server side there is an implementation called Leshan, which is basically a Java stack for building Lightweight M2M servers, there is also a work in progress for doing clients as well, it's very simple, it's not like based on Spring or on any complex framework,

it's also providing a web UI for interacting with the devices, I mean the server devices connect to the server and then as an end user or someone wants to manage a fleet, you will interact with the devices using either the built-in web UI, using a web UI that you will build yourself or using the rest APIs that Leshan is providing.

So it implements most of the features of Lightweight M2M, the bootstrap, the encoding using the TLV system, it works well in OSGI containers, you have the security support, it's based on California,

which is a Java implementation of co-op, and it has the whole DTLS stack, so you can do certificate based, well not yet actually, but you can do pre-shared key, authentication, real public key, and yeah, that's basically, I mean it's very simple to build,

the source code is available, there is also a sandbox that's available, at Leshan.eclipse.org if you want to test Lightweight M2M, which we will do actually in the demo. I won't go through the code in details, but basically the API for building a server and for extending the server is really simple,

you get nice callbacks whenever a new client is registered, you have basically a handler to the client, and if you want to update a specific value on the client, then basically you will create a specific request, a write request, to update, in that case that would be resource number 13,

it seems that would be the date, resource number 13 on object number 3, instance 0, so that's very likely the device object, and you can perform the actual request. So that's Leshan, client support is under construction,

so you could also, if you are interested in running a Java Lightweight M2M client, you could do that as well. Project plan is, as I said, certificate-based authentication, the project is still in the process of moving to eclipse.org, doesn't support JSON just yet, doesn't support SMSes,

but these are features that are in the roadmap for the project. I have a similar slide at the end. On the embedded side, and this is where it gets really interesting, Whatcom is a C implementation of Lightweight M2M that runs on very, very constrained devices, as we will see in the demo.

It's a C client, it's not meant to be used as a shell library, it's a client, it's a set of files that you use to do a porting of Lightweight M2M for your specific device. Basically the only dependency is on sockets,

you need to be able to open, close the sockets, and then send and receive on the UDP socket. So it's actually pretty easy to do the porting on most devices, the API is very, if not POSIX, it's looking very much like POSIX,

maybe there is a different name for socket send, and you will just need to do a very simple porting. There's no built-in DTLS support in Wacama, you have to provide that yourself, but again, on many IoT devices, you do already have support for doing DTLS,

you have a hardware acceleration for encryption and stuff, so you're not that far from bringing your own DTLS implementation usually. Features that are supported, again, most of the Lightweight M2M features, no JSON support here neither, but you can read resources,

do the observe mechanism, I didn't mention observe before, but in co-op you can actually ask a resource to notify you whenever it changes, so you don't have to poll it regularly, right? And in terms of code, well, you do create instances of the objects by using the Lightweight M2M, the Wacama API,

so what are the answers you want to provide to the read method, to the write method, to the execute method, et cetera, et cetera. And then you basically mount the resources in all your objects and all your resources, you mount them in your Lightweight M2M client,

you establish the connection with the server, and if in your Lightweight M2M client stack, you have usually an infinite loop or a thread dedicated to making sure that, I mean, anything that is received on the UDP socket needs to be handled by the Wacama stack, right?

So what is in the roadmap for Wacama providing the bootstrap? They're working on more examples. There is one on GitHub for which we will actually see the demo, but the idea is to provide more portings to more devices. There is a testing server that's available as part of Wacama.

It's far from being production-ready. It's really just used for testing purposes, but, I mean, it might be interesting to have a C implementation of a Lightweight M2M server to make it more scalable and such.

And so, yeah, demo time, actually. There's been some work, I mean, the Bosch guys especially did work on porting Wacama on many different devices. Not only, I mean, they do port it on their devices, and I cannot show you those demos, but they also ported it to several open hardware platforms.

So today I want to demo Wacama running on the Embed. So the Embed is a Cortex-M0 Plus device, and the idea is that I exactly want to replicate the use case I sort of described earlier where I'm working on a new super cool IoT gadget.

The hardware is kind of ready, but the software isn't, so it's time to ship, it's time to leave the factory and to actually ship to the clients. So what's going to happen the first time the device connects, right? The software is still full of bugs or is maybe not ready just yet.

So what I'm going to show is the Lesion web UI, right? So that's the built-in Lesion web UI. It's nothing fancy. It's really just meant for interacting with your devices. If you really want to build your own device management infrastructure,

you will likely integrate Lesion in your own backend, right? But still, from this web UI, you can see all the connected clients. So this is the sandbox I was referring to earlier, right? Running on lesion.eclif.org. You see all the clients. You can configure the credentials of your clients as well, like if there's an appreciate key that your device is going to use,

you can configure the key or the keys from the web UI, or you could use an API as well. So that is my sandbox. That is my embed device. It's going to connect to the internet through my... I mean, I'm sharing the connection from my laptop. I could have used a Wi-Fi capable device as well.

So I'm going to turn it on. Just providing power. All right, device is turning on. And the only software that's running right now on the device is Wacama. There is only, as part of the firmware, if you will,

there is my Wacama-slash-lightweight M2M daemon. And at any time, I can use lesion to browse what are the standard resources, standard lightweight M2M resources that are available. So here we're talking about an embed device, an NXP micro, but it could be any other device, right?

They would always, they would all expose the same standard resources. So if I'm interested in reading the device object, then I can retrieve the name of the manufacturer, I can retrieve the model number of the device, the serial number, the power voltage, et cetera.

So here I did read the wall content, but I could also read attribute by attribute. There could also be, in this example, there are only three objects that are made available by the device, but there could be more, right?

If you remember the Ipso smart object stuff I mentioned earlier, you could decide that you are actually also exposing the temperature of the device as a standard resource, and you would know, I mean, it would allow anyone to actually discover the capabilities of the device easily because they conform to a standard description that is part of the lightweight M2M standard.

So what I'm really interested in, in the context of the demo, is the firmware object. The firmware object allows me to write either the package or the package URI resource. I will, I mean, most likely you will use the package URI, but the idea is to flush new firmware, right?

So you can do that in band, you can use UDP and co-op, not sure that would be a good idea, but you could try and directly write a new binary firmware into resource slash five slash zero slash zero, or you can flush and you change the value of the URI attribute to just provide the URI to a binary

that is available somewhere on the internet and downloadable through HTTP or FTP or whatever. So in my case, the name of the binary would be that one, it's hosted somewhere on the server. I want to update the value of the attribute.

Where am I? All right, I did update the value, but the update is going to happen as soon as I start clicking the exact method, right? So right now the device is actually downloading the new firmware, it's going to reboot when it's done, and we will see that, I mean, we're going to turn this device

into a more useful device in the form of a device. So in the meantime, it actually lost the connection with the server, right? That perfectly makes sense. And now we actually have a device that blinks an LED, but it's also now running a complete, a real application that allows me to control and to display the values

of the temperature of a demo that we have on the Eclipse Foundation booth, and I reach the temperature using MQTT. So I'm basically running at the lower level, I'm running a Wacom M2M stack for everything device management, but on top of that, I can do whatever I want. In my case, that is running an application that uses an MQTT embedded client

and updates the status of the LCD depending on what are the MQTT messages I receive. And for those who have a good visual memory, we can see that now that the device is back. If I ask for the device information again, the model number that is being reported is different from earlier.

Now I'm basically running a totally different application. So that's basically the demo. A few more examples of running Wacom on very constrained devices. The Spark Core, you might be familiar with the Spark Core.

It's an STMicro Cortex-M3. 20Ks of RAM, 128Ks of flash, and the Bosch guys, what they did is that they ported Wacom for the DTLS. For the security support, they ported tiny DTLS with pre-shared key support.

So they are not exposing a shitload of lightweight M2M objects. They just expose the device object, but that's still useful for retrieving battery level and the like. So an empty firmware, basically an empty app on the Spark Core,

would be 75Ks of flash, 13Ks of RAM, and adding the lightweight M2M example, that is Wacom plus tiny DTLS, is an overhead of only 3Ks of RAM, 32Ks of flash storage. The u-blocks, it's actually compatible with the embedded APIs,

only it also does GPRS. So in this case, they ported way more objects, they are exposing the server information, security information, firmware, etc. And the complete application is the real-time OS, plus a command line interface, plus lightweight M2M,

and it's in the range of 80Ks of flash, 22Ks of RAM. Yes, I'm actually through the presentation. So Arduino Mega, same sort of footprint, there is a Lua binding for easing the DTLS integration, you could do that using Lua APIs,

rather than providing DTLS at the C level. Mailing lists, report bugs, and questions that you can ask right now, if you have any. Yep, that is a good question.

Yes, the question is, is there support for M4 devices like the TI CC 3200? I did start to do the porting, I think it wouldn't be a big deal. I mean, when I was describing that on most platforms, porting the socket layer is actually very simple,

that's the case for the TI platform. All the socket methods are basically, instead of doing a socket send, that would be SL underscore socket send or something, SL being simple link, they are a network stack, so now that would be an interesting port to do, I'm sure this would fit in the CC 3200,

it's not that constrained as far as I remember, so if you do the porting, please just tell me, that'd be great. Are there other questions?

Is this possible to run on ESP8266? Well, I don't read Chinese, so I guess it could be possible, right? I just did, I mean, I was kind of joking, but that is true, right? It's kind of hard to find the proper support for the device,

but again, as far as I remember, the memory available and stuff would totally be in the range of what I described earlier, right? So that would be, yeah, that would actually be quite interesting to try that, and to try, yeah, yeah, yeah, yes, there is,

so that's what you may have seen in some slides, there is, in co-op, there is an extra layer for doing block transfers, like if you want to send large chunks of data,

you would need several co-op slash UDP packets, right? So that, yeah, that is supported by the protocol. Do we have time for one last question?