[Solved] How to map deviceIDs

#1

Hi,

I can’t find a way to solve my issue, maybe someone has an idea…

So:

  • I am testing a Sigfox device
  • I created a device on Losant to represent it, so I got the deviceID created by Losant
  • want to trigger a Losant webhook from Sigfox server when it receives data from the device
  • but the Sigfox device has a hardcoded id
    And I have no clue on how to match the webhook with the right Losant device.
    Well, I could of course introduce an intermediate layer who would do the mapping but this is not elegant.
    I could also use a tag to store the Sigfox id, but I call on regular basis the patch tags API and for some reason such a call deletes all tags before storing the tags passed by the caller, so my Sigfox id would be lost.
    The only option I see, but again not elegant, is to use a tag and get all tags before each invocation of tag patcher, so I could pass back the sigfox id tag…

Any smart advise ?

Actually the solution could be a feature request : when creating a device, next to the device id assigned by Losant, we should be able to assign a second device id.

0 Likes

#2

This article does provide a solution for this problem:

Essentially you add a tag to each Losant device with the Sigfox ID. Then in the workflow, you can use the Losant API node to find the matching Losant device based on the incoming Sigfox ID.

0 Likes

#3

Hi Brandon, and thank you.

Well, this is what I had in mind (that’s the last part of my message).
My problem is that I use the Patch API on a device (basically, I am using this API to set some threshold that the device is validated against), and this Patch function deletes all the device tags, and writes the one passed by the Patch API only.

In other words,

Before patch call: AttrA=“A”, AttrB="B"
Call patch with AttrA="C"
After patch call: AttrA="C"
but AttrB=“B” is gone !

Not sure if this is a bug or deliberate, but this is quite blocking for me.

Thanks

0 Likes

#4

Ah, I see!

You could do a GET on the device to grab the current set of tags before using the PATCH to update them. This way you could keep existing tags when you send the new tag. The PATCH is designed so that you’d send the entire set of desired tags on each request.

If you’re unable to change how the new tags are sent, a quick workaround could be to set the mapping in the workflow globals. This is a good option for a few number of devices, but gets a little tedious to maintain as you scale up. Essentially create an entry for each device where the key is the Sigfox ID and the value is the Losant ID. The template to get the result would then look like {{ lookup globals data.body.device }}.

Here’s a workflow that demonstrates using the globals:

global-id-map.flow (757 Bytes)

0 Likes

#5

Thanks for the suggestions. Not sure I want to go down first path, since this would make the operation unatomic (first get tags, then update them).
Will dig the second option :slight_smile:

Thank you !

0 Likes