thinger-io/thinger-server

Add Project Properties so devices can inherit

Opened this issue · 6 comments

It would be very important to have functionality to define Project properties that can be inherited to devices. It would be a similar functionality to what already exists for Asset Type Properties.
Documentation Link:

Asset Type Properties
Properties created in an Asset Type will be inherited by every associated device. This establishes a scalable way to configure large networks of devices in a short time and easily. The properties allow you to enter configuration parameters or any other context information you want to make available to the devices or other resources of the platform.
To create a new property on an Asset Type, go to Asset > Types section of the main menú, then acess the Type profile to be modified and select the properties tab on the right-side menu of the configuration panel. Then, creating a property only requires to press on +Add button and implement a Json file format to structure the data that wants to be included on the property.

Justification:
In projects, we need to define general properties for the devices (specific to each of our clients' projects), such as information to notify via email, SMS, WhatsApp... Or specific properties (calibration, parameters, configuration...) of devices. a project to be used by all devices.
We are currently working around this shortcoming by using File Store, storing a JSON file that is found and read by NodeRED.

Currently, our system's hierarchy is structured as Product > Asset Group > Asset Type > Device. To address your needs, consider using Asset Groups. They function similarly to Asset Types and can be tailored for each customer's settings. This approach allows for diverse settings across different device groups within each project.

Managing these settings at the project level can be tricky, especially when devices are shared across projects, leading to potential conflicts in properties. Asset Groups simplify this by segregating settings per group, avoiding the complexities of overlapping project properties and ensuring devices receive the correct configurations.

What do you think?

It's an option, but it's not adherent.
Thinger's documentation suggests that "Asset Type" be used to identify the type of device (e.g. temperature sensor, humidity sensor, current sensor...) and "Asset Group" be used to identify the location that o device was installed (e.g. kitchen, living room, bedroom, bathroom...).

We use the Project ID to identify our client (e.g. "Numéro d’identification fiscale (NIF)" (Europe) or "Employer Identification Number" (USA)).

And it was this architecture that we followed when we structured the registration of device information.

Therefore, using "Asset Group" to link properties of the same customer across a set of devices is not suitable for us. Furthermore, when using the "Asset Group" as NIF or EIN, we lose space to identify the location where the device is installed.

Therefore, we suggested that Projects have properties that could be inherited by devices.

In any case, if Thinger aims to be a B2B and B2C platform, how can we structure Projects so that we can use the equivalent of NIF or EIN as an ID, and link properties to devices (customer name, phone number, WhatsApp number, telegran number, email, mailing address...)? We use this information to send notifications and reports via NodeRed.

Currently, we store this information in a file (JSON) in the FileStore.

As a last alternative, would it be possible for the information stored in the file (JSON) in the FileStore to be data sources for widgets? That would be a viable solution.

With issue 6, we would be able to view the information stored in the file (JSON) in the FileStore in the HTML widget.

With this, we could store customer information in the file (JSON) that is in the FileStore and use it in notifications and reports via NodeRed.
And we could visualize the data on Dashboard with HTML widget

[Dashboard Screen] - Allow “JSON” files from FileStorage to be data sources for HTML Widget

If "Property Forms" can change the information of files (JSON) stored in the FileStore, that would be REALLY GOOD!

Another possibility is to define that each project will have only one (1) property and that the property ID will be the same as the Project ID.
This means there is no clash/colission between the names of properties of different projects.

In this property, the User could register all Project information that would be inherited by the device.

What do you think?

Hi @alvarolb

In relation to this suggestion, the possibility of defining properties for the project would already solve the problem, without the need for the devices to inherit the properties.
Devices do not need to inherit these properties.

But it would be very important to be able to define properties for the project.
A screen where we can register a JSON with various information about the project, just like we do with devices.

What do you think?

image