2-Way communication between Mango M2M and remote sites having dynamic IP

Hi,

We have a setup where a number of embedded devices are installed at various sites across the city. Each embedded device is connected to the internet via GPRS modem (each one of the is assigned a dynamic IP).

There is a server in the office with static IP address which runs Mango M2M. All the sites connect and send data (various parameters of the site along with it's dynamic ip address) to Mango M2M at the specified static IP using HTTP Receiver protocol.

There is no problem till this point and all the sites are able to send data to server without any problem. Now we want to send some data back to the sites from Mango M2M server in the office to control certain relay outputs at sites.

Any suggestions/ideas how to do this (considering that each site has a dynamic IP but every time a new IP address is assigned to the site it updates it to the Mango M2M server)

Thanks,

Abhijit

Hi Abhijit,

That depends upon how your devices can receive data. There are two possible approaches, both of which require coding in Mango to implement.

1) Put a payload into the response to the HTTP request. When your equipment sends data to Mango, any messages that you wanted to send to it get queued, and returned in the response. This solves a great deal of internet routing issues and makes DHCP usage irrelevant, but means that field equipment needs to check in regularly for any queued messages, and so is not the most efficient use of bandwidth.

2) Send requests back to the field equipment from Mango on demand. This approach means that your field equipment needs to be accessible over the internet and listening on some known port for incoming messages. Additionally, Mango would need to know how to structure the message content so that your equipment can make use of it.

Hi,

Thanks for the reply.

I think that the 1st option seems to be simple and relatively easy to implement considering the fact that we need to send only small amount of data back to the units (relay status etc.).

Our field units already connect to the Mango server every 1 minute to update their status to the server. In our case this time delay of 1 minute is perfectly acceptable for updating the outputs in field units.

Can i get some sample code/reference to implement this functionality in the Mango code?

Thanks,

Abhijit

Sorry, you're kind of on your own with this. If there were sample code around it probably would have gotten done already...

Looks like a nice feature to me - settable data points in Http receiver

response with JSON or XML or plain format of get request?

Arne

I plan to use plain format of get request but do not have the expertise to modify mango code.

Will keep on updating as i progress.

Any help is most welcome.

Thanks,

Abhijit

This message was edited 1 time. Last update was at 18/12/2009 09:52:29

I gave this a bit of thought. The idea would be to make a queue in the point locator, and when a set point occurs add some sort of message to the queue. When a request arrives, add the contents of the queue to the response. There are a couple of issues though:

1) There is no concept of confirmation of receipt. To address this, items in the queue would need to be marked as "sent", but not yet "confirmed". The next request received from the device would provide the confirmation. (This would also provide a channel for error responses to be returned to Mango.)

2) A set point action becomes potentially long-running, and also interlaced with regular point reads. Let's say a point currently has the value 10. I set it to 15, causing a message to be queued for the device. (The little wrench icon is now indefinitely displayed beside the point, indicating a set in progress. This itself becomes a nuisance since everywhere else set points occur synchronously - this approach is asynchronous.) When the next request is received from the device, let's say the point value is 7. This value will presumably be saved first even though the set point of 15 was apparently issued earlier. This effect could cause non-intuitive behaviour from the data source.

Hi,

I am interested in the concepts discussed in this thread. Does anyone know if these ideas were developed further?

Sincerely,

James

Not that i know of. In any case, M2M2 would be the place to develop it now.