Best practice for managing "fingerprinting" of an AEP conduit

[Chris Friedel]

Hi all,

I have one last question around thoughts on a best practice for fingerprinting the conduits.

For our application, each conduit identifies itself by a unique identifier and a license key in order to send its data back to our IoT platform.

Currently, we are setting these early in a node in the node-red flow. The problem with this is that this identification information now gets downloaded identically to all conduits on remote downloads of the node-red app as new versions are available.

Ideally we need to store these values separately from the node-red app, and these values should not be lost on node-red app (re)deployments, and ideally not even upgrades to firmware would wipe them out (but that might be wishful thinking).

Also, the *perfect* solution would also allow us to set these values not only from a direct connection, but via DeviceHQ as well (via remote configuration change… but I’m not sure if it is possible to granularly control configuration in this way).

If I understand the architecture of the conduit API and the db.json file, I think storing the information here would meet the ideal solution, but I’m not sure how or if it is safe to store “extra” properties in the db.json file, or if these settings are as resilient and independent per conduit as I believe they are. I did try implementing this myself, but all of my calls to the conduit api return with “not authenticated” errors, and I haven’t been able to find an API reference as of yet.

Thanks again in advance for all of the assistance and suggestions this community is providing. You guys are amazing, and its really appreciated.

Cheers,
Chris

[Jeff Hatch]

Chris,

What about a configuration file outside of Node-RED that is downloaded onto the Conduit with these values in a location that is persistent through firmware upgrade?

Jeff

[Chris Friedel]

Thanks Jeff.

I’ve added a credential json file into /etc which does the trick (and we cache these credentials in the global node-red context)

There is still one little snag in that there doesn’t seem to be a way through node-js flow to change the topic for the incoming MQTT messages (there is no input into this node of course).

I think possibly we will try and have the flow make an http request to the node-red admin ui, and dynamically update that mqtt listener node with the correct topic (since the device identifier is part of the topic).

I’ll let you know how that goes.

Thanks again for the help.

Chris

[Author]

Posts