Skip to main content
P
ptc-62919751-Visitor
1-Visitor
January 23, 2014
Question

Sample design reference on device communicating through TCP/IP

  • January 23, 2014
  • 3 replies
  • 3162 views

Hi,

I am having a design scenario whereby the device to be communicating to ThingWorx server will be communicating through GPRS connection and TCP/IP (example: a GSM modem that take sensor reading and send data to backend system through GPRS & TCP/IP). No device side code change is possible as we don't own the device but we DO have the device specific communication protocol/specification. EMS and LUA is NOT possible to be deployed in the device.

My guess is we could approach the system design in this case whereby:
1. Deploy ThingWorx server, EMS and LUA all under one server/cloud server instance.
2. Create a TCP/IP listener that could route the incoming message to LUA & EMS, so that these data can be channeled back to ThingWorx platform.
3. Configure LUA scripts for it to 'talk' to the TCP/IP listener / daemon and route data through.

Can you please advise if this approach is OK, or ThingWorx do recommend any other approach for such scenario?

Also, is there any sample LUA script, TCP/IP listener daemon code etc and sample implementation that could be provided for reference which is directly applicable for this scenario?

Thanks in advance for your prompt support!

3 replies

P
ptc-62919751-VisitorAuthor
1-Visitor
January 24, 2014

Hi there,

Seems there is no response at all on my question here.... I am not sure if my question is too trivial/dumb (maybe?) that not deserve any attention/reply here...

Would anyone in the community that is kind enough to point me to the right place to study further or if any of you that did such a design before that can share some knowledge on? In my personal opinion I found the coverage of edge connectivity and Lua tutorial is rather limited in ThingWorx community (I might be wrong though...).

Appreciate any of you could enlighten me on this.

Thanks in advance!

P
paic1-Visitor
1-Visitor
January 24, 2014

Hi Yew,

I'm so sorry nobody has responded so far. Andy from our end had mentioned he would write you a response, but he has just returned from Vacation. I myself am not in the country as you know, doing a training overseas in Europe.
I am pretty sure Andy will be able to give his input on this soon.

A
abalousek11-Garnet
11-Garnet
January 24, 2014

Yew, apologies for not responding immediately, and no question is trivial/dumb - in fact your question is a good one and actually quite technical therefore I wanted to make sure we respond appropriately.

We discussed the potential system design that you've outlined above while you were here for training and while it is a potentially viable option, LUA scripting and a 'local' TWEMS deployment on the ThingWorx platform server itself would not be suitable for anything more than prototyping or small scale deployments. As you're needing to 'code' a communication solution to the TCP/IP protocol, a better option will be to create a custom 'native' application built leveraging the forthcoming ThingWorx Edge SDK's (Java, .NET) that we discussed, allowing for deployment on any system(s) as needed to handle production scaling. We can discuss this option further directly across the next couple weeks prior to availability.


As for examples, I can send to you an very simple LUA script that parse IP port traffic but it likely will not be quite applicable to your scenario.



P
ptc-62919751-VisitorAuthor
1-Visitor
January 25, 2014

Hi Andy,

Thanks for the reply. Yes I agree that by writing custom 'native' application using forthcoming ThingWorx SDK will be a more suitable solution and I am eagerly waiting for next release of ThingWorx.

In the meanwhile, in order for us to not further delay the real device demo to customer, we are OK to use any possible existing solution even if it is only good enough for prototyping/small scale development. We wanted to show customer this can certainly be done in ThingWorx with just 1 or 2 device connected.

Looking forward your LUA sample that parse IP port traffic and let's see how we could move further from there.

Thanks in advance for your prompt support!




J
jserrano1-Visitor
1-Visitor
August 3, 2016

Yew, It seems to be an old post nowadays, but now I am looking for an exact solutions as yours. Is there any way for me to have a talk with you and maybe share the experience of the developement of this solution?

Pai Chung​ - Do you have knowledge of this solution?

Grettings.

P
PaiChung22-Sapphire I
22-Sapphire I
August 3, 2016

Not sure if this solution was created in the end or not.

But if the device has only a single standard method of sending its information, then you will have to create some 'listener' application.

Either as an extension to Thingworx (like the MQTT extension for example) or if you need a much larger deployment, some 'extension' or application to our Thingworx Agent in either the EMS/LUA form or using the SDK and deploy that on Connection Servers to handle the anticipated concurrency/load.

or completely independent in whatever language you are comfortable with, that in turn invokes the Thingworx REST API to transfer the information to Thingworx either directly or through a connection server.

Terms & ConditionsAccessibility statement