Alain Pannetrat – Building a Wired IoT Platform for Makers

Transcript

Peter Dalmaris: Hi, everyone, and welcome to this session in which I'm joined by Alain Pannetrat, maker and founder of Omzlo.

Peter Dalmaris: I'm Peter Dalmaris, an online educator and maker, author of Maker Education Revolution, and founder at Tech Explorations. My mission is to help people learn electronics, programing, printed circuit board design, and lots more. Most importantly, I want to help as many people as possible to enjoy the technology education adventures.

Peter Dalmaris: In this session, I'm excited to introduce Alain Pannetrat, a maker, cryptographer, and entrepreneur. Alain is the founder of Omzlo, a company that designs, manufactures, and sells open-source hardware with a focus on wired Internet of Things.

Peter Dalmaris: He previously worked as an IT expert for the French Data Protection Authority and as a smart-card security consultant in the banking industry. He holds a PhD Applied Cryptography, but discovered a passion for electronics the day he bought his first Arduino Uno.

Peter Dalmaris: Alain's presentation focuses on NoCAN, a platform that he designed and developed. NoCAN makes it super easy to build Internet of Things applications using Arduino compatible nodes and a Raspberry Pi master module, all connected via a CAN bus. A single cable provides power and data, making it a particularly good option for cases that radio communications are not up to the task.

Peter Dalmaris: Without further ado, I'm excited to introduce Alain. Alain, it's great to have you with us. How are you today?

Alain Pannetrat: I'm good. Thank you. I'm very happy to be here.

Peter Dalmaris: Awesome. It's, like, very early here where I am and it's very late there, I guess that is a good match because I'm a morning person and you tend to work late at night. Is that right?

Alain Pannetrat: Absolutely. Yes. Like a true hacker, you know.

Peter Dalmaris: That's how it is. So, I'm eager to dive into your presentation and learn about the amazing work that you've done in NoCAN. But just before we do, I've got a question. Now, your background is in cryptography in which you have a PhD. Professionally, your work is mostly software-driven, you're a programmer, software developer. At some point you started playing with Arduinos and, eventually, you started the development of NoCAN. Why did you do that? Why did you develop NoCAN?

Alain Pannetrat: Well, actually, I will basically start giving you my presentation because I'm going to tell you exactly what motivated me to do NoCAN.

Peter Dalmaris: Awesome. Motivation is so important. So, yeah, take it away. Show us why, and then what is NoCAN and how it works.

Alain Pannetrat: Okay. Well, to understand NoCAN, let's just imagine you want to water your plants automatically. I think a lot of people would like this kind of hardware project. And this is something that really interested me, myself. And, generally, I like the idea of having sensors and collecting information in the environment. And, you know, in the age of big data and analytics, I find this very interesting in general.

Alain Pannetrat: So, what I built is a system - shown on the screen - where you have the Raspberry Pi controlling an Arduino compatible module. We call it the CANZERO. And in the case of plant watering, this little module would control a valve, and it can switch on and off the valve, and you can program it to water your plants every day or every other day. And since you have a Raspberry Pi, you can even do smart things like that, like collect weather information and then adjust how you water the plants. There's really no limit.

Alain Pannetrat: One special thing about this is that it's based on CAN bus. So, you might not know what CAN bus is, but it's a wired protocol. And as you were starting to ask, what is NoCAN and why CAN bus. So, I will tell you why - actually, I went in that direction - and how I got to build this.

Alain Pannetrat: So, CAN bus, Why? What? As I said, I wanted to build a network of Arduinos. So, imagine that you want to have plenty of Arduinos and you don't want them just doing one thing. You want them to communicate with each other, and potentially even communicate with the internet, with your phone in your pocket, with a web server collecting data. So, you probably have a gateway somewhere.

Alain Pannetrat: So, the vague idea at the beginning is something like this on the screen, you know, a bunch of Arduinos talking to each other and, potentially, also talking to the internet. So, how do you do that? How do you build a project like that? An application that you can call Internet of Things?

Alain Pannetrat: Well, the first solution that everybody takes is the ESP8266, and today, the ESP32. These are amazing little devices. They're super cheap. They're Arduino compatible. And they're multi-master. What I mean by multi-master is that these devices, you can have plenty of them and they can talk whenever they want. They can connect anywhere, wherever they want.

Alain Pannetrat: One problem they have when you start building projects is that the project is nice, it works, but then you're going to probably power it with battery and it's good to last - well, it's good to last just a couple of days, best case. And then, you're going to have the other problem is that, WiFi doesn't go everywhere. If you're controlling your heating system in your basement, maybe the WiFi won't get there. So, signal and battery life are not going to be optimal for some applications.

Alain Pannetrat: So, it's going to be nice for a maker faire demonstration. But for a real project at home that is supposed to sit in a box for months in winter, in the dark place, it won't work. It won't cut it.

Alain Pannetrat: So, the next thing you start looking at is alternative wireless platforms. And there's much better stuff like Zigbee, Bluetooth, LoRa. You can find projects where these little sensors that run on these more modern protocols can run on a coin cell battery for a year. But when you dig in a bit, you find they're using little tricks. For example, they're making the device sleep for five minutes before waking up. It means that the device cannot really communicate whenever it wants. So, this limits the application scope.

Alain Pannetrat: And the other thing is - let's go back to the example of the valve I was talking about before - you have this little device, it has maybe a battery, and it's controlling the valve. But the valve itself, it's going to take, let's say, 200 milliamps. There's no way you're going to power that with a coin cell battery. And then, you're going to go back to the same problem you had again, is that, battery life won't cut it.

Alain Pannetrat: And then, again, you will have the same problem of single issue. Some of these protocols do much better than WiFi, but not all. You're going to have to make tradeoffs. And, again, in some cases, it's not just the right solution. Don't get me wrong. These wireless things are amazing. I mean, I love playing around with these little devices. But for the application I had in my mind, it was just not the right thing.

Alain Pannetrat: So, I looked at maybe a more classic thing, a wired protocol. Think of USB. I mean, you use it every day, you plug things in USB. In a way, it's a wired network that brings power and networking. You could say it's not exactly a network, but you get the idea. It's super simple. You plug something, it's recognized by the computer, and then it works. It's powered, in most cases, on its own. So, I thought, "Let's design something that works the same way but with Arduinos."

Alain Pannetrat: So, what do you look at? Today, you have a lot of choice, actually, if you want to do wired. Power over Ethernet, you might have heard of. Actually, the Raspberry Pi has recently added Power over Ethernet shield that had a lot of problems, actually, hardware problems. And I'm saying this to underline that it's great because it's fast. It uses TCP/IP. But it's complicated. It's expensive, if you look at the price of that shield. And it's a bit bulky, it has transformers on it. So, I wanted something below the $25 mark, basically, so that was out of the question.

Alain Pannetrat: The other thing is what every maker uses, when you start going past Arduino blinking an LED, you start to look at I2C, SPI, and UART, and it's basically free. It can't beat the price. It's simple. The problem is that you're typically limited in distance. You know, it will go one or two meters. So, again, not ideal for the project I had in mind.

Alain Pannetrat: The next step is called RS232, which is also very simple, very cheap, but it's only two nodes. Then, you move ahead one more step, it's RS485. Now, this is starting to get interesting. It's still cheap and you can cover some pretty big distances. It's pretty good. The only downside I saw at that time is that it's not truly multi-master.

Alain Pannetrat: What I mean again is that, there's basically one device that tells which device will speak. So, you kind of proceed in an order of the way. You have to say, "Device 1, you speak now. Device 2, you speak now."

Alain Pannetrat: There are hacks around it, and they make communication less reliable. You can try to design around that, but it's not ideal. It's great for industrial systems. But, again, for the application that I had in mind of, you know, a more loose set of nodes communicating and cooperating with each other, it wasn't perfect. It could have worked maybe, but it wasn't there.

Alain Pannetrat: And then, I heard about CAN bus. CAN bus is used in the automobile industry and it's actually pretty similar to RS485. It's also cheap. But it's considered as very reliable. So, I thought that was interesting. And it is truly multi-master. It knows it can speak at any time. The network takes care of giving priority to one node over the other, managing collisions. So, that is really interesting.

Alain Pannetrat: The only downside is the data rate. It's a bit slower actually than RS485. In theory, it's about the same. But in practice, because it adds a lot of overhead for reliability, it's about half as fast, let's say. I like the idea of reliability. If you are going to switch on and off a valve, you want this. You want the message to get across. You don't want your plans to be drowned in water because the message that's told your valve to shut off did not get there.

Alain Pannetrat: So, I start looking into CAN bus. And I will tell you a bit more about CAN bus because I thought it was a very interesting protocol the more I dug in there.

Alain Pannetrat: So, first, to give a more general picture, CAN bus is a bus, as the name indicates. Which means that it's not a network like WiFi where everybody speaks in every direction. You have to put the nodes on a bus. Basically, you daisy chain the nodes, so you have Arduinos on one single line. Which means also that when one node speaks, all the other nodes can hear what that node is saying.

Alain Pannetrat: So, you have to design around that constraint, is that you put everything in a daisy chain. And then, still, you can plug it into the gateway. And the gateway will allow you to access the internet or vice versa, allow your phone to control these devices. At least that was the goal.

Alain Pannetrat: So, how do you do this daisy chain? Well, basically, you put just one cable that brings power and networking, again, like a USB cable. You will have four wires, and that's what we used in NoCAN.

Alain Pannetrat: Two wires for power. One that gives you the 12 or 24 volts, typical. You could even go down to 6 volts. But, you know, usually it's a good idea to have these 12 or 24 volts to be able to cover very long distances. And ground, of course, references.

Alain Pannetrat: And two cables for the network that are called CAN High and CAN Low. And in most cases, you talk about CAN H and CAN L. It's called a differential signal. And it's very interesting from the point of view of reliability.

Alain Pannetrat: And, again, this is why the CAN bus is used in the automobile industry. Think you're driving a car and you hit the brakes, the electronics that control your brakes and everything, they need to arrive to the brakes. You need to be sure this happens. So, in general, it was invented by Bosch, a big supplier of automobile electronics.

Alain Pannetrat: So, what do I mean by differential signals? How it works is, basically, you have on CAN High and CAN Low, when nothing happens, the voltage sits at 2.5 volts approximately. When you want to send a zero, you pull the CAN H about 1 volt, approximately, and you pull the CAN Low down 1 volt. So, instead of sitting at 2.5 volts, the CAN H signal sits at 3.5 and the CAN L sits at 1.5. And when you want to transmit the 1, you don't do anything, you just leave things as they are around 2.5 volts. So, that's what you transmit.

Alain Pannetrat: Then, the receiver will take those two signals and Invert can load the L signal. And then, it will add the two signals together to reconstruct something, like shown on the screen, where 0 is a high and 1 is a low.

Alain Pannetrat: You might look at this and say, "But this is a bit silly, Alain, because we only need one signal to do this. The top one, the CAN H." The thing is, look what happens when a noise spike happens.

Alain Pannetrat: Let's imagine this scenario, you have a brutal noise spike because a motor starts or something like that, your neighbors are starting their microwave oven, whatever. This will create a spike both on CAN Low and CAN H. The spike will be the same on both signals. When the receiver gets the signal, it will invert the lower one and sum them up. And then, here, something magic happens. Because you invert the lower signal and sum it, it will cancel out the voltage spike.

Alain Pannetrat: Of course, there is a limit to how much. I mean, this is theory. And in reality, I mean, when the voltage spike gets too high, even CAN bus cannot handle it. But this makes CAN bus really strongly immune to interferences, which is, again, extremely important in some harsh environments. This is really something cool.

Peter Dalmaris: Alain, just a quick question, if I may here. Do we have aclock reference or do we even need a clock? How does it work?

Alain Pannetrat: The nodes need to agree on the speed. For example, in NoCAN, we select 125 kilobits per second. So, you configure -

Peter Dalmaris: Like, in RS232 then, we need to pre-select the speed. Unlike, say, I2C where there is a dedicated clock line so they can figure it out without us having to do anything particularly.

Alain Pannetrat: You're absolutely correct. Yes.

Peter Dalmaris: Okay. Thanks.

Alain Pannetrat: There are some algorithms to do volt detection. But we didn't use them in NoCAN because, basically, there's a compromise you have to make between the speed and the distance you want to cover. And with 125 kilobits per second, you can cover 300 meters or 1,000 feet, approximately, which is great for the application.

Alain Pannetrat: The second really interesting thing about CAN bus is what happens when two nodes want to speak exactly at the same time. Because like in most protocol, when a node wants to speak, it listens to the network. And if nothing is happening, it will start speaking. If another node is already speaking, it will wait. But if nobody's saying anything, it will send a message. But two nodes could have the idea exactly at the same time. And this happens a lot in Ethernet protocols.

Alain Pannetrat: How does it work on CAN bus? Well, it's very neat because what happens, you have an example on the screen here. Let's say, Node 1 sends a 0 and a 1, and Node 2 sends two 0s. Well, for the first bit they're going to send, they're sending the same thing. They will both push apart CAN Low and CAN High. And, basically, nobody will be able to see that anything is happening.

Alain Pannetrat: However, when we get to the second bit, the first node is doing a 1, but the second node is doing a 0. The second node will pull the two signals apart by 1 volt, as I said. Node 1 won't do anything. But the end result is that Node 2 will prevail. And when Node 1 detects that what it's sending is different what it's reading, it will stop immediately.

Alain Pannetrat: And by simply applying this rule, the nodes kind of get a priority of each other automatically. There's no need to send something, discover that it didn't go through, and resend it again, and send a message giving an acknowledgement, or the opposite, a negative acknowledgement. It's taken care directly on the network level. It's really clever when you think about it.

Peter Dalmaris: Will Node 1 detect that another node has taken over the bus and, therefore, retransmit later.

Alain Pannetrat: Absolutely.

Peter Dalmaris: So, nodes know that they need to retransmit because another node has taken over. But the network itself doesn't have to worry about figuring out who's got priority.

Alain Pannetrat: Exactly. And, actually, if you look at the screen, you will see that nodes that tend to have the more zeros at the beginning automatically gain priority. And if you take the car analogy again, you will give your brakes zeros as an identifier. And your radio or your CD player in the car will get a lot of ones because you don't care if it's delayed by half a millisecond.

Peter Dalmaris: So, while we're still talking about this, if the node with an address that has more zeros wins, does that mean that numerically lower addresses have higher priority?

Alain Pannetrat: Absolutely. That's exactly it.

Peter Dalmaris: Awesome. Thanks.

Alain Pannetrat: So, just to give you a simplified view of a CAN bus packet, it's got an identifier. And, actually, this identifier is exactly what you described. This is the number you give to every node. And since they first start by transmitting their number, this is where the battle for access to the network happens. You know, the ones who has the identifier with the lowest number wins. And by the time the identifier has, basically, been transmitted, we know who's the master of the bus for that packet.

Alain Pannetrat: Then, there's a data length field and then there's the data itself, which is surprisingly little. It's zero to 8 bytes, which means that if you want to transmit more than 8 bytes, you need to break down your message into several packets.

Alain Pannetrat: There is a new version of CAN bus called CAN FD that goes up to 64 bytes. But we didn't use it in NoCAN because the silicon, especially at the time when we did the design, was not mature yet. Maybe in a couple of years, when we revise NoCAN, we might adopt that bigger packet length. But we found tricks to, in any case, transmit packets that are more than 8 bytes.

Alain Pannetrat: Then, after the data, there's a CRC, which is a kind of a code to check to make sure that there's been no corruption in the data. So, think, despite the fact that it's a differential signal that there is this collision avoidance system, there is also a CRC.

Alain Pannetrat: And then, there is also an extra packet called an ACK. It allows nodes to say, "Oh, I received that packet. They put a special mark in the packet." Giving an extra way to check that everything has been transmitted correctly.

Alain Pannetrat: So, as you see, I mean, it's a bit simplified here on the screen, but there's a strong emphasis on reliability.

Peter Dalmaris: It is simple as you said, but maybe that is another component to it being reliable. There's not much that can go wrong here.

Alain Pannetrat: Yes. Absolutely. It's very interesting. But as you see, there's a lot of overhead. To transmit 8 bytes of data, you have an identifier, you have a length, you have a CRC, which reduces the bandwidth available to the actual payload.

Peter Dalmaris: How long is the identifier? How many devices can you put on the bus?

Alain Pannetrat: So, there's two possibilities. You can adopt a short identifier that is 11 bits, so that's 2,000 devices. And you can go to 29 bits. But in practice, sometimes you just don't give devices just a number, you may also divide your identifier into family of devices. You know, you can have a more sophisticated identifying -

Peter Dalmaris: Like, a subnet -

Alain Pannetrat: Exactly. And in NoCAN, we use only 7 bits to identify the device. But we put some extra data in the identifier to mark the beginning and the end of a packet and several other things. So, we use this identifier actually for network management as well.

Alain Pannetrat: So, I wanted to basically introduce the CAN bus to just also show people that, in general, it's something that is very interesting and that makers don't necessarily think of when they're building a project. But there's a lot of hardware today that is compatible with CAN bus. So, it's something that you might want to add to your toolbox, something interesting.

Alain Pannetrat: We used it to build the NoCAN IoT framework. So, the idea is that we created a network, just as I said, with nodes that are Arduino compatible, and a gateway which is a Raspberry Pi. So, it looks like this basically. The minimum you need to create a network would be a Raspberry Pi with - what we call - the PiMaster HAT. It's a hat that goes on top of the Raspberry Pi and is capable of understanding and speaking CAN bus, if I may say.

Alain Pannetrat: And then, you have a node on the other side of the screen, which we call the CANZERO. And you hook these two with a four wire cable. And as I said, four wires because you need two wires for power and two wires for networking, the differential pairs. And that's all you need to create the most simple network. This is how it looks.

Alain Pannetrat: So, why did we call it the CANZERO? Because, basically, it uses a Cortex M0, which is now the new trend in Arduino systems. And it's the same form factor as the Arduino MKR Zero. The PiMaster, we call it PiMaster because it's the master of the network. It acts as a gateway between a world where nodes communicate on the bus with CAN bus. And the external world, which is the internet, TCP/IP, and everything.

Alain Pannetrat: So, actually, if you're sitting on a PC at home, you can connect to the Raspberry Pi and control your network. But you can also use a phone and things like that. Of course, this is a bit boring what I show you on the screen, a network with one node. You don't have to limit yourself to that. Again, it's a bus, so you can daisy chain them so you can have something.

Alain Pannetrat: This is something similar to what what I actually have at home here. So, your PiMaster with Raspberry Pi connected to one first node that is connected to a relay and it switches on and off a light. A second node that is measuring temperature and humidity, and even pressure in my case here. And maybe a third node that has an infrared sensor to detect if somebody is actually trespassing in your house or something like that.

Alain Pannetrat: And the chain can be pretty long. As I said, the span of the network can be approximately 300 meters or 1,000 feet. So, this is where you can put cables in places that are impossible to reach with a WiFi signal, or in general with a wireless signal.

Alain Pannetrat: So, to compare, if you've ever used an Arduino MKR, the CANZERO is really very similar. It's similar in shape and everything. It means that if you have a shield or if you have an application that is compatible with the Arduino MKR, it also works with the Omzlo CANZERO.

Alain Pannetrat: And, actually, I had this idea of adopting the MKR format at the Maker Faire in Rome - which is happening in a few days here again in Rome - a guy who is working in industrial system, was telling me, you know, if you create your own Arduino thing, it's best to adopt format that is existing already so that people feel familiar and feel comfortable. And that you can, you know, re-use what has been created out there.

Peter Dalmaris: Yeah. That's good advice.

Alain Pannetrat: Yes. And so, with this setup, you can actually write code on your computer, your Arduino sketch and your familiar Arduino environment, and you can upload it through the Raspberry Pi to any node.

Alain Pannetrat: And this is very important if you're going to build a system like this because you're going to end up putting these little CANZERO nodes into boxes, or in a garden, or maybe in the basement, behind a wall, or something that you don't want to go there with a USB cable, plug it in, and program it. You need to be able to remotely update the software. So, we put this very strong emphasis on this possibility.

Alain Pannetrat: And I can show you maybe now on the screen, I will switch.

Peter Dalmaris: This is the equivalent of reprogramming or flushing over the air for WiFi modules, right? You did over wire without having to go out there looking for the node and physically connect something to it to refresh it.

Alain Pannetrat: Yes. Exactly. If you're in the Arduino and you click on Tools, and you go down on the boards, you will select, for example, the CANZERO. But more importantly, if you look at Port, you will see directly in the menu the nodes you have in your network. So, if I want to upload a new firmware to a node, I just select a node and then I just click upload. It's as simple as that.

Peter Dalmaris: So, now your Mac is connected to the Master, to the Raspberry Pi, how does it know which nodes are available in the network at the moment, in the bus?

Alain Pannetrat: So, we created a small piece of software that runs on the Raspberry Pi. And there was a recent change in the Arduino environment that allows you to also run a small tool on the Arduino side, and you can ask that tool to query another machine to get information on available devices. This is something very new, and I helped debug it actually. Maybe it was two releases ago in the Arduino IDE. It's really new.

Peter Dalmaris: The effect of that is, right now, we're looking at the nodes in your home NoCAN bus. Those nodes are directly connected through the CAN cable to the Raspberry Pi Master. Then, through the tool that is running on the Raspberry Pi, your Arduino IDE working on your computer can check for nodes with the Raspberry Pi and then present those under the port menu.

Alain Pannetrat: Exactly.

Peter Dalmaris: What's happening? So, these are not local ports that we're looking at now in the Arduinoe IDE. Not local ports. They are ports that are physically existing on a Raspberry Pi, which are remote device. And how you connect it to your Raspberry Pi, is that wirelessly or you have a network?

Alain Pannetrat: Yes. I have a network.

Peter Dalmaris: Right. So, through the WiFi?

Alain Pannetrat: Yes. It could be WiFi, absolutely. Right now I'm in my office, and the Raspberry Pi is sitting in a box actually outside the house, in a sealed box. So, this is really awesome. It makes it super easy to update software and program it. So, [inaudible].

Peter Dalmaris: The other way to do this, to re-flush the nodes, is to run the Arduino IDE on the Raspberry Pi itself. In which case, the Arduino IDE running on the Raspberry Pi would directly know who the nodes are. You'll be able to use the same technique to re-flush them. But this is the extra step now. You don't need to be on the Raspberry Pi, which means that Raspberry Pi can be anywhere and you can be in the comfort of your own desk and in your lab and do whatever you want with the nodes.

Alain Pannetrat: Yeah. That's exactly it.

Peter Dalmaris: That is very cool.

Alain Pannetrat: Yes. It's really cool. So, as I said, you can upload software directly from your desk. You can also control or communicate with the nodes with your mobile phone. I will not demo this here, but this is actually a screenshot from my own phone which shows me wherever I am, I can get in real time the temperature and humidity in my garden. It's not necessarily super useful, but when I'm away from home travelling, I know better the weather in my garden than the weather outside my hotel.

Peter Dalmaris: Is that like a Blink app running?

Alain Pannetrat: Absolutely. It's Blink. It's based on Blink. We wrote like a translator, at an adapter, for Blink. Exactly.

Peter Dalmaris: Wow. So, that's how you can then use mobile devices. And I guess all the features that Blink offers so that you can access in your NoCAN network.

Alain Pannetrat: You can access individual pins on any board in your NoCAN network.

Peter Dalmaris: So, your Blink app would allow you to select a node and then enable or disable the pin or get a measurement from one of the sensors individually?

Alain Pannetrat: Absolutely. Exactly. Yes.

Peter Dalmaris: Amazing.

Alain Pannetrat: And another thing maybe more classic is that, the NoCAN platform comes with a built-in web server. So, the Raspberry Pi itself, you can launch a web server that gives you a view of what's happening in your network.

Alain Pannetrat: I will switch now to my own home again. So, here, this is actually a web page showing what's happening now in real time in my own home. And you can see, as you saw in the Arduino environment, I have three nodes numbered three, four, and six. And I have here seven channels numbered from zero to six.

Alain Pannetrat: One specific thing about NoCAN is that you don't communicate with another node by saying I'm sending the message node number five or I'm sending a message from node number 2 to number 3. You actually create channels and publish information on the channel. And any node that is interested in information about a specific channel will subscribe to it. It's like MQTT, if you're familiar with that.

Alain Pannetrat: The great thing about this is that you can actually write apps while the nodes are not even deployed yet. So, you have a node that is measuring temperature. And later, you decide that you want to do something about the temperature, like for example, start the heater. The code that you need to write, you don't need to go back to the first node and change the code. You can then plug in the new node and it will subscribe to the temperature channel and start adapting its behavior to that.

Alain Pannetrat: So, it's very easy to build IoT applications with this principle because you don't have to worry about the address management and things like that. You can really design with concepts, like I'm interested in temperature, I'm interested in humidity, and stuff like that.

Peter Dalmaris: Right. So, that means that when you want to broadcast something, you just create that channel and then subscribe all the nodes to that channel. It's not about addresses then, it's about this is going to anyone who wants to listen to this channel, they will all receive a message regardless of their ID.

Alain Pannetrat: Exactly. Yes.

Peter Dalmaris: And can nodes individually write to those channels as well? So, the nodes themselves will be able to control other nodes through this mechanism?

Alain Pannetrat: Yeah. Absolutely. And with the web interface, you can also control things. So, watering has two channels. There's one called Valve. If I changed the value to one, it opens the valve. If I put it back to zero, it closes it. There's also a timer.

Alain Pannetrat: So, if I click on the channel 2, which is watering timer, and I press, let's say, 30 and I hit enter, it will start opening the valve for 30 seconds. So, now, if I go back home, you will see here, the watering time is 2:30. And as we speak, if you wait a few seconds, the valve is at one, the timer now is at 20. And when it reaches zero, the valve will close.

Alain Pannetrat: And this is also available as a REST API. So, if you're also more comfortable with, you know, a web-based approach, you can also play with your network this way. You can send from a web application messages to your nodes to open the valve, close a valve. So, you can do stuff with JavaScript and things like that. That opens more possibility of integration.

Alain Pannetrat: Another thing you can do is also integrate NoCAN with MQTT, because actually when you think about it, the MQTT protocol, which is very popular in IoT, is very similar to the concept of channels we have here. So, you can actually translate channels into MQTT messages and send them to data collecting platforms.

Alain Pannetrat: One that I like very much is the Adafruit IO platform. I don't know if you've heard about it. But you can actually collect data and show it in nice graphs. And, again, this is - on the screen - what is happening in my home right now. It's only been running for 20 minutes, so a bit more actually. And you can see the temperature over the last 40 minutes, let's say. The real time temperature here and the humidity changes with time.

Alain Pannetrat: But I could have this running for weeks and have nice graphs about the environment in the home. I pick the garden because it's a fun thing. But you can also use it for more serious things, like, you know, for safety reasons in an environment where you want to monitor gases and stuff like that, there are sensors that can do that, and you can graph everything and see how things change through time.

Alain Pannetrat: So ,again, this is built in the platform. All of this based on CAN bus.

Peter Dalmaris: That's amazing. Sorry, Alain. Just one thing, as I was looking at the web interface, so I can see at the top of the web page coming from your Raspberry Pi, there is the voltage and the current. There's probably a current sensor. So, that allows you to monitor the power distribution and usage at this point in time?

Alain Pannetrat: Absolutely. Yes. Current sense is not directly translated. It's not 17 million or something like that. It's a number that gives you kind of a feel of how much current is being drawn. What you worry about is when you suddenly see big numbers, basically, because it's potentially a short circuit or something like that.

Alain Pannetrat: The NoCAN PiMaster has built-in security mechanism that will normally shut off current when you go over 3 or 4 amps. Sometimes it's not good enough to avoid a shutdown of the Raspberry Pi. Sometimes it's good enough. But it's good enough to protect the electronics, in general, is what you're worried about. Because you can actually plug nodes live and, you know, it can happen that you accidentally short ground and power, and this would automatically cutoff the network.

Peter Dalmaris: Of course, yeah. What are some guidelines here? Like, I can see where a 12 or 24 volts, which are possible in a CAN bus, quite decent voltages. You can drive large motors with that. What are the guidelines of what you can do with this power or what you shouldn't even try to do?

Alain Pannetrat: Well, I told you, the limitation is roughly sitting at 3 or 4 amps. Motors might go over that. And when you have inductive loads like that, you have to worry also about the spikes that happen when you start a motor. Or even a valve, actually, you have to be careful.

Alain Pannetrat: In our setup here, the valve is actually powered directly by the CAN bus network because it only draws about 200 milliamps. There's a bit of a spike at the beginning, but it works. If we had, like, four, five, six valves that would open simultaneously, we might consider having a separate power supply for the valves just to avoid any issues.

Peter Dalmaris: Isolate. All right. So, for larger loads, just common sense, isolate them with some local power supply so that they don't interfere with the network.

Alain Pannetrat: Yes. Absolutely. So, just a summary, I mean, you can basically interact with your CAN bus network with MQTT, the web. Something that is not very sexy to show on screen, but you can do stuff with the command line. You can send messages directly simply with the command line. So, if you're a Linux guru, this is perfect. You have a REST API, Blink, and we're working on the Python interface also so you could write code that way.

Alain Pannetrat: I just wanted to show you, though, usually I'm being told never show code in a presentation, it's bad. It's not clear, but I want to show how simple it is. You know, if you've done ever Arduino sketch, there are two parts. There's a setup part and there is a loop part.

Alain Pannetrat: The setup here, if you see on the screen, there's just two things you do. You connect NoCAN, you register a channel. This is an example of a relay controlling a lamp. You register to a channel called Relay and you subscribe to a channel. Of course, the relay is controlled by a pin on the CANZERO. So, you also configure the pin as an output, put it to low.

Alain Pannetrat: Then, in the loop, you just wait for messages. And when you receive a message, if the message is one, you put the pin too high. If the message is zero, you put the pin too low. And that's all you need to control a relay with a NoCAN application.

Alain Pannetrat: I've removed some of the codes you would normally put, like checking, return values. And, you know, a proper program would also check that the messages, actually, more than or has at least 1 byte and things like that. But I wanted to show how simple it is.

Alain Pannetrat: To finish, typical applications was built here, temperature, humidity, and pressure sensor. So, this is connecting a CANZERO to a BME280. We've put it in the box in the garden, and this is how we get the temperature and humidity and pressure in real time all the time. The sensor is actually outside the box, while the electronics are inside the box.

Alain Pannetrat: Here, the infrared sensor detecting if somebody is in the garden, very simple again. It's powered directly off CAN bus because it's 12 volts and our CAN network is using 12 volts. Again, very simple.

Alain Pannetrat: And to finish, the plant watering system I started with, which is basically a Raspberry Pi, the CANZERO, and the CANZERO connects to the valve. And it all sits in a box like you see on the screen. And I mean, it works. Some of the sensors we've had here have been in their boxes and working for over a year without interruption.

Peter Dalmaris: You didn't ever change any batteries, right?

Alain Pannetrat: I didn't have to change any batteries. So, that's it. I mean, if you want to learn more, you can go to omzlo.com, our website. And just omzlo.com/the-nocan-platform, and you will see a lot more code examples and things like that. And that's pretty much it.

Peter Dalmaris: That was amazing. First of all, I really enjoyed the presentation. I'm stricken by how simple it is. Like, things tend to normally get more complicated in the world of IoT and DIY making and engineering in general. But you've taken an approach to simplify things. You went for wires.

Peter Dalmaris: You chose a protocol that is, I wouldn't say traditional because we are talking about something very, very capable. But it prioritize simplicity and reliability of other things that are, as you said, more sexy, like speed. Just bells and whistle. So, I really enjoyed learning about NoCAN. Thank you, Alain.

Alain Pannetrat: Thank you very much.

Peter Dalmaris: Thank you, Alain. That was amazing. I just have three concluding questions for our audience. So, first question, very important, in your opinion, what are the three or four key learnings that our listeners, our audience should take away from your presentation?

Alain Pannetrat: Well, first is to consider CAN bus. It's not something that is super popular. But even if you have no interest in NoCAN, add it to your set of skills. The chips that allow you to interface with CAN bus are getting very cheap. And it's used way beyond the automobile industry. I've seen it in pick and place machines. So, it's an interesting option, a tool to look into if you're designing distributed system.

Alain Pannetrat: And, also, if you're a bit of a hacker, it's interesting because, precisely, it's used in cars and there is a growing community of people who are plugging Arduinos, Raspberry Pis into their car and seeing what's happening. And it can be a lot of fun.

Peter Dalmaris: That's very true, because NoCAN - sorry to interrupt you - it's something that I'm considering doing. Lack of time, actually I should have done it. Because in the CAN network, devices just broadcast things that are published into channels, which means that information flows in the bus. So, you plug something onto the bus, it can read that information. You can see what's happening without actually interfering with the operation of the car, right? Is that how it works?

Alain Pannetrat: Absolutely. Yes. Well, the other thing is that, when you're building an IoT system, it's important to consider your requirements, and not necessarily go for the most popular device. As I said at the beginning of the presentation, these little WiFi chips or Bluetooth chips are absolutely fantastic and offer amazing possibilities for makers.

Alain Pannetrat: But don't hesitate to consider other options and to think more of the long term costs of using a specific technology. And I think those will be the main takeaways I would give from the presentation.

Peter Dalmaris: Perfect. Now, you already have given us a resource for anyone that wants to learn more about NoCAN. You've got a lot of documentation on your website. Is there any other place or other resource that you would recommend? Not necessarily just about NoCAN, but other things that you find interesting that makers watching this presentation might be also interested in.

Alain Pannetrat: Well, it's a bit different from everything, but I read the Hackaday every day. And some of the ideas I got there was from reading articles about people hacking cars, about people exploring technologies in different ways. So, I mean, if you're a maker and you don't go at least once in a while to that website, you're really missing something.

Peter Dalmaris: And learn from others.

Alain Pannetrat: Exactly. Yes.

Peter Dalmaris: So many things come through. "Oh, yeah. That looks like a good idea," look what somebody else has done. So, it makes sense. Awesome. Thanks. All right. And how can people get in touch with you?

Alain Pannetrat: You can contact me, so alain, A-L-A-I-N, @omzlo.com. Or on Twitter, OmzloElec, that's my handle.

Peter Dalmaris: Got it. I will have that as well in the page where this presentation is posted on. Alain, thank you for your presentation. It was like an eye opener for me. I learned so much about the CAN bus, the network, and, of course, NoCAN. It's just amazing how the project has evolved over the last year or so since launching. It is just a really good platform. And thank you for taking the time to teach us how to use it.

Alain Pannetrat: Thank you for having me. It was actually very nice to sit down and think ahead of this presentation, how am I going to present things, it was very helpful and very nice. Thanks.