Just while thinking of it, maybe attributes is not the best way to accomplish remote configuration of the devices.

A new type of communication may be introduced, a settings one, allowing just that:

• The device may advertise its settings, their names, types, values etc.
• The server will display these settings, and allow changing them.
• On change on the server the device will be notified.
• The settings may be exported to file, or a settings file may be imported, allowing configuring multiple settings at once, or backing up previous settings.

What do you think?

I'm busy setting up shared attributes one device by one device manually for tens of devices. 😭

Yes this is bad. But my use case is worse, since we don't even know the attributes of each device...

The user has to configure the device, according to his needs, and then the device has to notify the server about the actually supported features. This is not possible currently.

@fotis400 I disagree that this is not possible. We try to make TB as generic as possible. Of course, something always will not be available out-of-the-box, but you can easily add this functionality. I suggest following idea based on existing functionality:

1. Devices report it's current state of attributes in the client-side attributes.
2. Optionally devices can report a special attribute that describes which attributes may be changed and how
3. Custom widget is developed to analyze (2) and show (1) in a user-friendly way.
4. Once administrator or customer see (3) he is able to interact with this widget and set new values as shared attributes with same name + prefix/suffix.
5. Devices monitor changes to (4) using existing APIs.
6. Once devices receive the update of (4) they apply the update(new configuration) and report the current value in (1).

Using this flow you have some benefits:

1. You always know the current state of device,
2. You always know the current state of device configuration.
3. You are able to tell when (1) and (2) mismatch.

Unless you or someone disagree I am going to close this soon.

P.S. @jakocoo you can use REST APIs to automate the process you have described.

I understand your generic approach, but device remote configuration is a common problem faced by most embedded systems.

Although there is a work-around as you stated, it seems to be just this, a work-around. Lot's of work, for a standard necessity. And of course there is always the case not to have a widget for this, and let the tenant administrator directly manipulate the attributes, just as it is already happening with the shared attributes.

Are there any plans for more powerful remote configuration? Or at least for the moment why not just let the device create the shared attribute, what's wrong with that?

Hi @ashvayka
Is there REST APIs for set/get shared attributes of a device? Could you share me the document link?
Thank you.

To implement the approach proposed by @fotis400 we need a rest API to create a shared attribute.
I didn't find this API in SWAGGER (any reference?)
I tried to hack the procedure implemented in the Web interface of thingsboard. The resource http://localhost:8080/api/plugins/telemetry/DEVICE/<dev_ID>/values/attributes/SHARED_SCOPE is referenced. I tried to access such resource with no succcess.

Any Help is very appreciated!

hey @andreavitaletti @jakocoo
I'm facing the same problem rn. Did someone find a solution for that?

@jakocoo @andreavitaletti @zimmele2 please see #731 for also with manipulating shared attributes, instead of just creating them, and let us know what you thing.

I also have the same problem. How can the equipment update the attribute problem?

Well the answer is here:
https://groups.google.com/forum/m/#!topic/thingsboard/hzD25fDShbg

So if somebody wants to update device attributes in shared scope. one needs to send POST request to http://{thingsboardUI:port}/api/plugins/telemetry/{deviceID}/values/attributes/SHARED_SCOPE . Request body should contain json with attribute name and value, for example, {"testValue" : "111"}

And for version 1.3 and on that URL needs to be:

http://{thingsboardUI:port}/api/plugins/telemetry/DEVICE/{deviceID}/SHARED_SCOPE

You can update multiple shared attributes at once, by doing a post request on the above with the parameters in json encoding....

As per ThingsBoard documentation only client attributes can be updated from the device, shared attributes can only be sent to the device, and service attributes can only be changed with the application and not device itself.
Solutions proposed here talk about updating shared attributes from other means like API and not from the device.

@yefimov-andrey Indeed I have read the documentation, and indeed there are ways to automate shared attributes creation.

But the problem persists. Since it is a "shared" attribute, and the device has access to it (read and write), it should be also able to create it. It seems that many people have the same request.

Shared attributes can be updated from the rule engine, the type of attribute saved can be changed in a corresponding attribute. In version 2.5/3.0 shared attributes can be edited from UI. Or is this different from what you wanted to see?

Hi @yefimov-andrey

Well... Yes and no...

You can indeed choose the type of the attributes to be saved. However the current API does not allow to distinguish between shared and client attributes. They are sent all together.

Thus it is impossible for the rule engine to know which attributes are to be saved as client attributes, and which as shared ones. Everything arrives in a single packet, and handled together.

Since they cannot be distinguished you are effectively forced to use only one type of the two. And since they originate from the device, I can only assume that they are client attributes.

Thus the device cannot create shared attributes (in theory it can, but effectively not).

Hi , thanks in advance.
I am kind of lost , so I need some guidance, please.
Lets say I create a shared attribute in Device menu. I can change it in Dashboard. so far so good.
Now I want to read that update from de device ( ESP32) to set a variable... or so.
How do I do that? How can I make the device aware of that change/update? Please.
Thanks a lot for your help

Well the answer is here:
https://groups.google.com/forum/m/#!topic/thingsboard/hzD25fDShbg

So if somebody wants to update device attributes in shared scope. one needs to send POST request to http://{thingsboardUI:port}/api/plugins/telemetry/{deviceID}/values/attributes/SHARED_SCOPE . Request body should contain json with attribute name and value, for example, {"testValue" : "111"}

And for version 1.3 and on that URL needs to be:

http://{thingsboardUI:port}/api/plugins/telemetry/DEVICE/{deviceID}/SHARED_SCOPE

You can update multiple shared attributes at once, by doing a post request on the above with the parameters in json encoding....

@AnoxySoftware @ashvayka

Hey there, is this format still valid? I'm trying to send a simple attribute for creation/update. Here is the data I'm sending:

{'fooAttribute': 'fooValue'}

I keep getting status:405 error:"Method not Allowed" message:(empty):

{'timestamp': '2021-08-07T01:34:35.906+00:00', 'status': 405, 'error': 'Method Not Allowed', 'message': '', 'path': '/api/plugins/telemetry/DEVICE/{theDeviceId}/SERVER_SCOPE'}

I am able to successfully GET the attributes, however I can't POST and update them. Tried with server, shared and client attributes and with no success... tried with several options listed on the Swaggerui (specifically, saveEntityAttributesV1,saveEntityAttributesV2, and saveDeviceAttributes) but no success... (to be honest, It's a bit confusing for me, no indication of how the body should be sent).

My successful GET looks something like this:

curl -X GET 'https://{myDomain}/api/plugins/telemetry/DEVICE/{theDeviceId}/values/attributes/SERVER_SCOPE'   -H 'x-authorization: Bearer {myToken}'   -H 'content-type: application/json' 

And yes, I'm passing the jws token, just as I do with the GET and am able to see the attribues. I would greatly appreciate any guidance or pointers on this one, thanks.

Never mind guys, my dumb a** mind was sending a GET instead of a POST with python requests library... :o) so yes, the format is still the same. Again don't forget the "Bearer" and the Token