Store semi-static attribute-esque arbitrary data with devices (in addition to tags)

Feature Request
1

Hello! @Dylan_Schuster this is to augment the request you already submitted regarding storage of JSON data with devices. Vis for @Heath.

We need to store static data with devices quite often. Our only option to do this currently is via tags. Unfortunately tags aren’t really up for the task of storing more complex data, and are themselves unable to be tagged. Thus I’m requesting storable semi-static device properties very similar to the way attributes are structured:

  • statically typed (string, number, bool, JSON)
  • taggable with key/value pairs

Here’s the example:
We want to render a table in an experience page. This table should pull all data from an array of devices and format them into columns…a unique column name for each unique property found. However, due to a large number of variable device properties, it doesn’t make sense to hard-code the column names…that would increase the operational requirements of the front-end. Instead, I’d like to dynamically create the columns based on the properties found on the device (such as name, id, etc). Any custom static properties are assigned via tags…this is awkward but workable as long as we keep it simple. However…now let’s say we only want certain properties to render in the table…perhaps there are some private properties. Ideally I’d assign a tag to this property…something like visibility:hidden or something. Using tags I’m forced to either explicitly filter hidden tags in the JavaScript of the table component, or if I want to do so dynamically I’d have to use a prefix or something in the tag name… hidden_someProperty for example…then perform pattern matching in the JavaScript (this is my current plan). What about setting the display name for the column? Either I split on a delimiter like my last example, then do some funny translation of the remaining key text…or I have to statically define it in the JavaScript with IF statements or something. Again the ideal solution: I’d assign a tag called displayName: Some Property Name…that way I could pull the property object and as I’m rendering the table, pull properties of that object for various fields.

In a completely different workflow, I have drivers I write for many of our devices. These drivers are defined in JSON and offer the instructions to various edge workflows on how to get data from a given device make/model. Currently I define these drivers in the globals of a Driver edge workflow, then assign that workflow to a device via tags (by the flowId). Much simpler would be to allow me to just store the JSON with the device itself. Tags on the JSON property would be very valuable too.

Perhaps this problem is best solved by creating server-side attributes and client-side attributes (ala thingsboard). Server-side attributes give us a place to statically define the attribute value instead of receiving it via via MQTT or otherwise. They should also be perpetual…and may not even need to be stored as time-series. Client-side attributes operate just like the current attributes do.

Hopefully this makes sense and I’m happy to meet with anyone to discuss the use cases further.
Happy Friday!

3

@Frederick_Loucks,

Thanks for the explanation for your use case, it makes perfect sense. But, to make sure that I’m with you, you’re looking for statically typed (as you mentioned) device tags that also have tags? Similar to how devices have attributes and attribute tags?

Is there ever a case where you may have more than 100 of these tags? Is this something that Data Tables could be used for? I.e. create a row for each device (and store its device id as a column value), and then create columns for the meta tagged data?

Data tables in Losant are certainly meant for this type of semi-static meta-like data, but may not provide the flexibility that you’re looking for here.

I’ll get this feature request to our engineering team and keep you in loop on what I learn!

Thanks,
Heath

5

Hey @Heath,

Essentially tags (with static types other than string) with tags…exactly like how attributes work.

I don’t think we’d need more than 100 for a given device…especially if we’re allowing a JSON type.

Tables aren’t much help because they’re still only storing string data, and continuity is broken as they’re not stored with the device itself. Now you have disjointed data stored in multiple places. Better to tie them together. Also different make/model of devices may have different properties. Now you have multiple tables (for each make/model) that you’re linking data to. There may be parts of this approach that might work, but it would still be a compromise from true server-side static attributes. I think server-side static attributes would also be much easier to maintain as you start looking at templating / inheritance…a recipe will have the default states for a device, but in the future as we try to implement inheritance for certain attributes, having them as part of the device should make that much easier to I’d think.

LMK if I can provide further feedback!