http://forum.infiniteautomation.com/forum/posts/list/1.page JForum - http://www.jforum.net
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]]> http://forum.infiniteautomation.com/forum/posts/preList/259/1183.page http://forum.infiniteautomation.com/forum/posts/preList/259/1183.page GMT
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.

]]> http://forum.infiniteautomation.com/forum/posts/preList/259/1186.page http://forum.infiniteautomation.com/forum/posts/preList/259/1186.page GMT
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]]> http://forum.infiniteautomation.com/forum/posts/preList/259/1191.page http://forum.infiniteautomation.com/forum/posts/preList/259/1191.page GMT http://forum.infiniteautomation.com/forum/posts/preList/259/1192.page http://forum.infiniteautomation.com/forum/posts/preList/259/1192.page GMT
response with JSON or XML or plain format of get request?

Arne]]> http://forum.infiniteautomation.com/forum/posts/preList/259/1193.page http://forum.infiniteautomation.com/forum/posts/preList/259/1193.page GMT
Will keep on updating as i progress.

Any help is most welcome.

Thanks,

Abhijit

]]> http://forum.infiniteautomation.com/forum/posts/preList/259/1196.page http://forum.infiniteautomation.com/forum/posts/preList/259/1196.page GMT
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.]]> http://forum.infiniteautomation.com/forum/posts/preList/259/1197.page http://forum.infiniteautomation.com/forum/posts/preList/259/1197.page GMT
I am interested in the concepts discussed in this thread. Does anyone know if these ideas were developed further?

Sincerely,

James]]> http://forum.infiniteautomation.com/forum/posts/preList/259/4563.page http://forum.infiniteautomation.com/forum/posts/preList/259/4563.page GMT http://forum.infiniteautomation.com/forum/posts/preList/259/4565.page http://forum.infiniteautomation.com/forum/posts/preList/259/4565.page GMT