Https on dash pro


#1

My application will depend, unfortunately, on a device that can’t be reverse engineered. Its modus operandi is having a dongle/app combo that acts like a proxy, getting (Bluetooth) messages from the device, sending to the server, getting a response from the server, sending that to the device. This is the only way I know to keep the device synced to their proprietary database, and our organization is committed to this device/vendor. The connection from the dongle/app to their proprietary server is SSL (https, but not REST). Messages are small and few, then the session shuts down. Number of sessions per day is low, so it’s a good Dash candidate.

My question is this, how to get the Dash to act like this proxy app? It’s unclear reading the docs that this is a good fit for the proposed API. So is the only alternative to write my own server that is a proxy, encapsulate into REST communication, and then use the Konekt API to do REST with my server? My server would have to extract the data and establish a session to the device’s normal server (with appropriate credentials) in order to obtain the needed response for the REST transaction.

Is my understanding correct, or is there some way to directly make an HTTPS connection (tcp/ip to port 443) without having to write my own server?


#2

This is a great question. I’m going to answer it with several available options, the first being the one that seems to answer the question asked most directly, and the last being the most flexible and cost conscious.


Methods for sending data to the Internet using our hardware:

  1. Direct HTTPS from Dash Pro to their server - this will be possible on the Dash Pro thanks to hardware HTTPS support, and means that you do not need to run your own proxy server
  2. HTTPS from Dash Pro to the Konekt Cloud, then to their server
  3. TCP/IP (with or without SSL) from Dash or Dash Pro to Konekt Cloud, then to their server

The benefit of Option 1 over Options 2 and 3 is that you do not need to proxy communications (as you mentioned in your question). Options 2 and 3 require either native support for our Konekt Cloud on the third-party receiving server, or what we call an integration translator (typically hosted on a web server) that can receive a webhook from us and proxy the data to the third-party server.

The benefit of Options 2 and 3 over Option 1 are that: (a) you can log data in our persistent datastore if you wish, (b) you can monitor device communications and see that devices are sending data properly, © firmware programming on our hardware is very simple, and (d) you can reroute (and/or retranslate) that data to a different third-party server or different protocol possibly without firmware update, making deployments future-proof.

The benefit of Option 3 over Options 1 and 2 is that Option 3 is the most data-conscious—why send HTTP headers over cellular with every device message when you can deduplicate the sent data and build those headers in the Konekt Cloud?


In your application, where it sounds like extra data consumption isn’t a huge deterrent, and where you wish to avoid proxying the data, it might make sense to choose Option 1 on the Dash Pro. We’re all about providing options to suit the various needs of different applications, and I just wanted to iterate over the different possibilities here in case this answer can help others who need to make a similar decision.


#3

Hi Pat,

I’ve got a Dash Pro Beta now. I doubt if the first option (Direct HTTPS from Dash Pro to their server) is implemented. Option 2, going through the Konekt Cloud, might work but I can’t tell from the example scenario you have in the webhooks doc (https://content.konekt.io/blog/route-iot-device-data-with-api-webhooks/) whether or not it has reverse flow: does it allow for a response to come back from the third part POST that will be relayed and received on the Dash Pro Beta. Is such a facility now present in the Dash Pro Beta?

Thanks, Ted.


#4

More insight into this question is now available on this thread: Dash Beta Experiences and Troubleshooting


#5