Internet of Things using Netduino Plus 2 and Constrained Application Protocol - Project Showcase - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Internet of Things using Netduino Plus 2 and Constrained Application Protocol

IoT

  • Please log in to reply
8 replies to this topic

#1 vishnusmoke

vishnusmoke

    New Member

  • Members
  • Pip
  • 5 posts

Posted 26 September 2013 - 02:35 PM

This is a project that uses the Netduino Plus 2 board and implementation of "Constrained Application Protocol" (CoAP) to enable M2M communication. This is my first attempt to move towards Internet of Things world. CoAP is a protocol that was just published on the IETF site (https://datatracker....ietf-core-coap/) that enables RESTful message exchange between two resource constrained machines over UDP. For this project, you will need the following: 1. Two Netduino Plus 2 boards 2. A CoAP implementation library that works with Netduino (download from http://www.coapsharp.com) [coapsharp.dll] 3. NET Micro Framework 4.2 Here are the steps: 1. First create a simple CoAP server implementation. This server will be connected to a temperature sensor and will provide temperature values to a client. 2. Second, create a simple CoAP client implementation.This client will query the server at regular intervals and get the temperature. 3. The board that acts as a server, is connected to a DS18B20 temperature sensor. How it works: 1. The server is connected to a DS18B20 2. The server implements a CoAP server and listens on port 5683 (UDP) 3. The server exposes the temperature sensor as a RESTful URL with path as "sensors/temp" 4. The client creates a CoAP client socket 5. The client prepares a CoAP request for the URL "sensors/temp" 6. The client sends the temperature request every 10 seconds. 7. The server, when it receives the request, reads the temperature and prepares a JSON message. 8. Server packs that JSON message as a CoAP response and sends back. 9. Client socket receives the CoAP response and extracts the temperature. Please note, the two boards are connected to a network. The attached files have the client and server implementation. The red circle on top right indicates the temperature sensor. The red circle on bottom left indicates the ethernet connection. Ignore other items on the breadboard. Happy IoT! Note: How to work with DS18B20 is given here http://test.bergonli...om-DS18B20.aspx Disclaimer: I work for the company that has released the CoAPSharp library.

Attached Files



#2 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZürich / Switzerland

Posted 27 September 2013 - 07:15 AM

Interesting! Will there be commercial support for the library, and is there another license, apart from LGPL?

 

How large is the typical code and RAM footprint? Does the library dynamically allocate objects, or is it mostly static in its RAM consumption?

 

Cuno



#3 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 27 September 2013 - 12:05 PM

Your project looks nice, but...I'm sorry, but I'd like to know what are the advantages of the CoAP over a well-known yet used as the Modbus-TCP (or UDP) is. Moreover, any Modbus flavor is totally free as licensing.

If you mean IoT leveraging HTTP and AJAX or XML, I agree that's nice, but that's a refinement of a worldwide-used industrial protocol. The only interesting feature is the access via URI other than a numerical code, but -you know- a string is somewhat "expensive" in term of resources. Modbus started in '79, where the strings were affordable just on PCs, not MCUs.

Could you clarify that?

Many thanks.


Biggest fault of Netduino? It runs by electricity.

#4 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZürich / Switzerland

Posted 27 September 2013 - 01:06 PM

If you mean IoT leveraging HTTP and AJAX or XML, I agree that's nice, but that's a refinement of a worldwide-used industrial protocol.

That's pretty much the point. You may regard CoAP as a compressed form of HTTP, thus extending the REST architecture approach also to small embedded devices. In a way which allows to create fully generic gateways, with little or no "impedance mismatch" to the Web standards.



#5 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 27 September 2013 - 01:32 PM

That's pretty much the point. You may regard CoAP as a compressed form of HTTP, thus extending the REST architecture approach also to small embedded devices. In a way which allows to create fully generic gateways, with little or no "impedance mismatch" to the Web standards.

 

Again, where's the difference?


Biggest fault of Netduino? It runs by electricity.

#6 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZürich / Switzerland

Posted 27 September 2013 - 03:39 PM

Again, where's the difference?

If good Web integration is a key requirement for a system, then staying as close as possible to the HTTP REST semantics would make sense. In the end though, I guess it is not so much a question of technical differences, but whether the main drive for a project comes out of an "industrial culture" or out of a "Web culture". And of course there are also a number of other protocols in the running, for example MQTT, AMQP or the protocols of OPC UA. We had recent customer inquiries relating to the latter two.



#7 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 27 September 2013 - 04:12 PM

In the end though, I guess it is not so much a question of technical differences, but whether the main drive for a project comes out of an "industrial culture" or out of a "Web culture".

 

That's actually make sense to me. I've notice such a "big wall" between the abstract-web world and the real-life world. The majority of sensors telemetry/control users fall in the second class. However, I mean the pro-users, not the home's.

 

If good Web integration is a key requirement for a system, then staying as close as possible to the HTTP REST semantics would make sense.

 

Totally agree, but -again- the actual context of IoT usage is pretty much home/small offices. I'd try to find a solution for the integration with existent systems, first.

 

Anyway, it's just another grain of sand in the world beaches!...

Cheers


Biggest fault of Netduino? It runs by electricity.

#8 vishnusmoke

vishnusmoke

    New Member

  • Members
  • Pip
  • 5 posts

Posted 28 September 2013 - 04:49 PM

Interesting! Will there be commercial support for the library, and is there another license, apart from LGPL?

 

How large is the typical code and RAM footprint? Does the library dynamically allocate objects, or is it mostly static in its RAM consumption?

 

Cuno

This is the begining. For commercial support, you can contact them via the site. Look at www.coapsharp.com and visit "Contact Us" section. The DLL is about 60KB. The DLL does allocate objects and this is one area where further work is going on.



#9 vishnusmoke

vishnusmoke

    New Member

  • Members
  • Pip
  • 5 posts

Posted 28 September 2013 - 05:03 PM

Your project looks nice, but...I'm sorry, but I'd like to know what are the advantages of the CoAP over a well-known yet used as the Modbus-TCP (or UDP) is. Moreover, any Modbus flavor is totally free as licensing.

If you mean IoT leveraging HTTP and AJAX or XML, I agree that's nice, but that's a refinement of a worldwide-used industrial protocol. The only interesting feature is the access via URI other than a numerical code, but -you know- a string is somewhat "expensive" in term of resources. Modbus started in '79, where the strings were affordable just on PCs, not MCUs.

Could you clarify that?

Many thanks.

 

 

That's pretty much the point. You may regard CoAP as a compressed form of HTTP, thus extending the REST architecture approach also to small embedded devices. In a way which allows to create fully generic gateways, with little or no "impedance mismatch" to the Web standards.

 

 

Again, where's the difference?

 

 

That's actually make sense to me. I've notice such a "big wall" between the abstract-web world and the real-life world. The majority of sensors telemetry/control users fall in the second class. However, I mean the pro-users, not the home's.

 

Totally agree, but -again- the actual context of IoT usage is pretty much home/small offices. I'd try to find a solution for the integration with existent systems, first.

 

Anyway, it's just another grain of sand in the world beaches!...

Cheers

Wow, so many good questions...and I do not have a definite answer to all of them. Here is an attempt...

My understanding of protocols like MODBUS  (or DNP3) is limited. I was trying to do a few things around SmartGrid, which is when I got to know about protocols like MODBUS and DNP3. 

After reading them briefly, what I understood is that these protocols were designed, not by communications experts, but by H/W guys who also wanted their H/W to communicate...while I'm not that intelligent, but that's purely my understanding.

I come from a web background, and as stated by "Cuno" , CoAP is more of a web-world thing. Meaning, it suddenly has higher number of people who can easily understand this, bringing the entry barrier much lower. 

Additionally, CoAP "is" designed to integrate with web, and that is where, if you read the specifications, there is reference to "CoAP to HTTP" and "HTTP to CoAP" proxy. Therefore, I agree with Cuno that CoAP makes getting on to the "Internet" easier.

 

While currently IoT is more of home usage as righly pointed out by Mario, that isn't really IoT, its more of machine-2-machine communication. I do have a few use cases (can't disclose now :-() where the usage is for commercial aspects and not just home usage.

 

Finally, I agree that strings are still costly on an MCU, but on small 8-bit MCUs like Atmega8 and the likes. More people (read hobbyists) have now moved on to more powerful controllers (e.g. FTDI, ST32, Atmega UC), and for them, string handling is easy ( i have experience on FTDI Vinculum and that handles complex structures nice). 

 

My 10 cents to the discussion :-)







Also tagged with one or more of these keywords: IoT

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.