Data Table Keeping Track of Gateway Information Redundant?

data-table
#1

Setting up automatic device creation/registration based on the blog: https://www.losant.com/blog/how-devices-can-register-themselves-in-losant.

My high level business process currently looks like this:

  1. Purchase gateway and flash custom firmware to this gateway.
  2. Manufacturing will record the serial number of each gateway that is sold to a customer into a data table called “Gateways” as gatewaySerialNumber.
  3. When device starts, it checks to see if the gateway has a deviceID and SecretKey to communicate with Losant via MQTT.
  4. If it doesn’t have this it sends a POST request {“gatewaySerialNumber” : “ABC123”} to /register.
  5. /register kicks off a workflow to check the “Gateways” data table for gatewaySerialNumber ABC123.
  6. If the gatewaySerialNumber does not exist in the table it returns an error to the POST request sender.
  7. If the gatewaySerialNumber does exist, it checks the row of the same table for a deviceID and secretKey.
  8. If the deviceID and secretKey do not exist they are created, stored in the data table and returned.
  9. If the deviceID and secretKey do exist they are returned to the POST request sender…

Does this approach use the Losant Framework as intended? Or is using the data table to track this a redundant method of tracking information? In other words, should I instead be tracking this information using device tags or some other method that I am overlooking?

Thanks!
-Leo Bach

1 Like

#2

Hello @Leo_Bach1,

I think this is a great use of Data Tables, and a great use of Losant! Device Tags can be used to do some of these things, but a problem could arise as the device would have to exist first, so the deviceId and serial number would be created simultaneously. Thus, there would be some changes to step 2, 3, and 8 (and a couple others as well). Essentially, the deviceId would be created by manufacturing recording the serial number, so you would have to change some of your conditionals to only check if the secretKey exists. The devices will exist in Losant before they are registered by a customer. This could be useful in your use case, but data tables (in my opinion) are great for visualizing and keeping track of this kind of data.

Thanks!
Julia

0 Likes

#3

Brilliant! Thanks, Julia.
So once I check the device has been entered by manufacturing by validating the data table.
I have the accessKey and accessSecret set to null (because they will not generate these values)…
They will be created by the workflow…
I do see one potential issue in attempting to pass the gatewayDeviceID, gatewayAccessKey and gatewayAccessSecret back to the gateway it seems that Losant automatically redacts the gatewayAccessSecret when returning it from the data table query:

Any ideas on bypassing this? Without it, I don’t see a way for my gateway to connect via MQTT and pass the required data for authentication to connect to the Losant broker.

1 Like

#4

Hi Leo,

I just double checked on this but we will automatically redact values named with “Secret,” “Token,” or “Password.” This is a front-end redaction, so the value is still available, just not visible to the user on the payload. The value is still held by gatewayAccessSecret and can still be passed through the workflow, it’s just hidden from view for security.

Let me know if you are unable to access it!
Thanks,
Julia

0 Likes

#5

Seems like you guys thought of everything. :grin:
Moving forward, thanks a bunch!

1 Like

#6

Julia,
Please ignore this post… I found in the returned values from creating the key both the “key” and the “secret”.
Apologies… still working through the learning curve inherent in picking up a new framework.

The following section of this post is irrelevant because when creating a key through the losant API node the key and secret values are returned in the payload.
So I am trying to create the gatewayAccessKey and gatewayAccessSecret for the device that has checked in via HTTP POST, verified that it is listed in the data table for gateways, and was created within the Losant application through the workflow.

The example I was following used the Losant API node to request generation of a key for the device.
It seems that Losant API does not provide the ability to get the secret.
I was hoping to return the values of gatewayDeviceID, gatewayAccessKey and gatewayAccessSecret to the device that checks in so that the middleware on the gateway can configure its own MQTT connection credentials. Now it seems I may have hit a road block. Do you see any other way to accomplish this task?

1 Like