vishnusmoke

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 :-)

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.