Dynamic fields in HTTP Route URL field

Notehub.io
9

First, many thanks for @dsepulvedara and @bsatrom for their inputs.

CONCLUSIONS:

  1. Don’t get confused
    As you are reading the documentations you come across:
    https://industrial.api.ubidots.com/api/v1.6/devices/{DEVICE_LABEL}
    https://industrial.api.ubidots.com/api/v1.6/devices/[device]
    https://industrial.api.ubidots.com/api/v1.6/devices/[device-name]/
    https://industrial.api.ubidots.com/api/v1.6/devices/sensor-data/

There are multiple ways to successfully land your data in Ubidots and it’s very convenient if you know what to expect and how to achieve it, but you can easily put yourself into a pretty dizzying tailspin. As it happened to me, even though this wasn’t the first time I used Ubidots.

  1. What works
    Ubidots automatically initializes (creates) a unique device label, identical to the {DEVICE_LABEL}, which is the very last member of the endpoint URL.
    The {DEVICE_LABEL} can be:
    A. an arbitrary character string, like sensor-data, OR
    B. one of the field names [device], [sn] ,[product] that Notehub can identify, and dynamically substitute with the sending Notecards’ DeviceUID, Serial Number or ProductUID.
    Anytime you create a route with a URL that contains a {DEVICE_LABEL} that is different from the existing device labels , Ubidots will initialize a new device.
    This is where things might become a bit tricky and you need to factor in the scope of the route exaction (see the next point)

  2. What doesn’t work
    While a manually set {DEVICE_LABEL}, like sensor-data perfectly identifies the device in Ubidots, the Notehub has no clue to which Notecard you meant by sensor-data, devG1_b32 or whatever that character string might be, even if you put the deviceUID, Serial Number or ProductUID in place of the {DEVICE_LABEL}.
    While the Notehub can recognize the [device] , [sn] , [product] fields and substitute them with the particular Notecard’s information that is sending the data, it cannot go the other way. Putting a deviceUID or a Serial Number in the URL will not tell the Notehub which Notecard’s data you want to include in the route execution.
    If you set the {DEVICE_LABEL} manually, the only thing that determines what data will be forwarded under that label is how you set the Filters in the route configuration.

To illustrate this with a theoretical example, let’s say you have ten Notecards with Serial Numbers (sn) from sens00 to sens09 and all of them monitor temperature and humidity data which is put in the sensor.qo notefile and updated every 10 minutes. Now, let’s see two routing scenarios with one {DEVICE_LABEL} being the serial number field [sn] and another the actual serial number.

A - https://industrial.api.ubidots.com/api/v1.6/devices/[sn]
B - https://industrial.api.ubidots.com/api/v1.6/devices/[sens00]

In scenario ‘A’ you’ll see ten devices appearing in Ubidots labeled with your ten Notecards’ serial number, in the order of their data update. Anytime, any of your sens00-sens09 devices sends the humidity and temperature information, it will be associated with the corresponding device label (serial number) in Ubidots.

In scenario ‘B’ however, you will see only one device in Ubidots, labeled as sens00 but it might display all the humidity and temperature data arriving from your entire fleet or project. You’ll see the last update as humidity and temperature values, regardless of which Notecard the data is coming from.
In this scenario the FILTERS configuration will determine the scope of the route execution which has nothing to do with the serial number you manually inserted in the URL.

2 Likes