ACCEPTED SOLUTION
Accepted Solutions
Great. It sounds like you have one of these:
I don't have one, so all my knowledge comes from a quick read of their online documentation, looking for ways that device can communicate with the outside world.
It looks like the normal workflow is to connect your XDK110 Gateway to the XDK Workbench via COM (or JLink for debugging) and then write a short program to collect sensor data and send that data via various protocols to a network destination. Once you've debugged it, you load it into the XDK110, and enjoy the new connectivity.
The documentation tells me the XDK provides several protocols, but the ones that really jump out at me are HTTP and REST. Everything in your ThingWorx Thing model is exposed via REST, so I think writing a program in XDK Workbench that changes property values with a REST call is the easiest way to go.
Like I said, I don't have an XDK110 of my own, so I'll have to speak generally. On my local ThingWorx instance, I have a Thing Model that contains Vehicles. It's easy for me to set the VehicleSpeed property for one of my vehicles, Vehicle41, using a REST call. Here's the code for my REST call:
PUT /Thingworx/Things/Vehicle41/Properties/VehicleSpeed HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
appKey: aaannnan-nann-nnnn-aaaa-43bd95d50a65
x-thingworx-session: true
Cache-Control: no-cache
Postman-Token: 3f57nnna-nana-nnna-nnna-nnaaaaafd81
{
"VehicleSpeed":66.5
}
Here are the important ThingWorx-specific headers:
- Content-Type: application/json
- appKey: {{an app key generated in your ThingWorx instance}}
- x-thingworx-session: true (lets you authenticate with an appKey, instead of Basic Authentication)
There's a Postman-Token header because I use Postman to test all my REST calls. You don't have to worry about that header.
Here are the steps I'd take to visualize XDK110 data in a ThingWorx mashup:
- In ThingWorx, use Composer to build a Thing Model for the sensors connected to your XDK110. (Here's a page with links to more information on the ThingWorx steps.)
- Using your Thing Model, create a Thing that represents your specific XDK 110.
- Go to Security ... Application Keys in Composer, and generate an app key to authenticate your REST calls.
- Using Bosch XDK Workbench, write a program for your XDK110 to post to your ThingWorx instance. Make the call specific to the Thing and the property you want to update, using the example above. If you need a ThingWorx instance, head over to developer.thingworx.com, where you can get a 30 day hosted instance, or a 120 downloadable instance.
- Once you see the property updating on the Thing view in Composer, build a Mashup to show the data from your Thing in a useful way.
Once you're down the road a bit, and you have a bunch of XDK110s sending data, you may want to explore MQTT. You can write a program in XDK Workbench that posts to an MQTT broker, instead of an HTTP endpoint. There's a free extension in the ThingWorx Marketplace that enables ThingWorx to subscribe to messages on an MQTT broker.
Good luck with the XDK110. It looks like a really nice sensor package.
Great. It sounds like you have one of these:
I don't have one, so all my knowledge comes from a quick read of their online documentation, looking for ways that device can communicate with the outside world.
It looks like the normal workflow is to connect your XDK110 Gateway to the XDK Workbench via COM (or JLink for debugging) and then write a short program to collect sensor data and send that data via various protocols to a network destination. Once you've debugged it, you load it into the XDK110, and enjoy the new connectivity.
The documentation tells me the XDK provides several protocols, but the ones that really jump out at me are HTTP and REST. Everything in your ThingWorx Thing model is exposed via REST, so I think writing a program in XDK Workbench that changes property values with a REST call is the easiest way to go.
Like I said, I don't have an XDK110 of my own, so I'll have to speak generally. On my local ThingWorx instance, I have a Thing Model that contains Vehicles. It's easy for me to set the VehicleSpeed property for one of my vehicles, Vehicle41, using a REST call. Here's the code for my REST call:
PUT /Thingworx/Things/Vehicle41/Properties/VehicleSpeed HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
appKey: aaannnan-nann-nnnn-aaaa-43bd95d50a65
x-thingworx-session: true
Cache-Control: no-cache
Postman-Token: 3f57nnna-nana-nnna-nnna-nnaaaaafd81
{
"VehicleSpeed":66.5
}
Here are the important ThingWorx-specific headers:
- Content-Type: application/json
- appKey: {{an app key generated in your ThingWorx instance}}
- x-thingworx-session: true (lets you authenticate with an appKey, instead of Basic Authentication)
There's a Postman-Token header because I use Postman to test all my REST calls. You don't have to worry about that header.
Here are the steps I'd take to visualize XDK110 data in a ThingWorx mashup:
- In ThingWorx, use Composer to build a Thing Model for the sensors connected to your XDK110. (Here's a page with links to more information on the ThingWorx steps.)
- Using your Thing Model, create a Thing that represents your specific XDK 110.
- Go to Security ... Application Keys in Composer, and generate an app key to authenticate your REST calls.
- Using Bosch XDK Workbench, write a program for your XDK110 to post to your ThingWorx instance. Make the call specific to the Thing and the property you want to update, using the example above. If you need a ThingWorx instance, head over to developer.thingworx.com, where you can get a 30 day hosted instance, or a 120 downloadable instance.
- Once you see the property updating on the Thing view in Composer, build a Mashup to show the data from your Thing in a useful way.
Once you're down the road a bit, and you have a bunch of XDK110s sending data, you may want to explore MQTT. You can write a program in XDK Workbench that posts to an MQTT broker, instead of an HTTP endpoint. There's a free extension in the ThingWorx Marketplace that enables ThingWorx to subscribe to messages on an MQTT broker.
Good luck with the XDK110. It looks like a really nice sensor package.
I gone through the ThingWorx installation guide & I tried to install ThingWorx in my local system, for that PostgreSQL or H2 Database in required. So I installed PostgreSQl DB after that I was redirected to download the Thingworx.war file in PTC Software Downloads page. But i am not able to reach the PTC Software Downloads page.I am getting access denied msg. If i want to run the ThingWorx server in my local machine I have to purchase...?
Hi Stephen,
Happy new year...
I am unable to communicate with my MQTT broker. Thingworx server and MQTT broker both are running in my laptop only. I think some problem in my Thingworx MQTT configuration page. please guide me to resolve this. This is my configuration screen. (My laptop IP :192.168.1.89)
After configuration,
I have one more question,
During TCP communication I am getting Unable to Invoke Service SendTextTCPMessage on TCPsocketThing : Connection timed out , TCP server and Thingworx both are in same network. This is my Screen. I already spent more then 2 days in both cases, Please provide some support to resolve this.
Thanks in advance.
