Request Traffic Monitor configuration file (for Node-RED)

[glossyio]

Problem

Is your feature request related to a problem? Please describe. As a developer, it is hard to manage and create parameters, configuration, and variables for the Traffic Monitor. Presently, most variables are implemented within the UI, and it requires a lot of manual work with potential inconsistencies to develop.

As an implementer or tenant admin, it would be nice to have a single file where unattended changes may be made, for say backup/restore purposes.

In addition, a user has no consistent, single place to configure all their settings. Settings that could use it include:

• ThingsBoard URL/Port
• Deployment Location (UI may still valid, but single place to pre-populate)

Proposed Solution

Describe the solution you'd like I think a better solution would be to work completely off a single config file, similar to Frigate's Configuration.

This could be exclusive to Node-RED, since that's where most of the logic is based, and other applications have their own configuration.

Two options I can think of, not sure which is the best:

• Node-RED Settings file - saving them as Javascript settings, and then it just requires Restarting Node-RED to implement.
• System service environment file ~/.node-red/environment is also a possibility, but I think the whole systemctl service needs to be restarted in this case, which is more prohibitive.

Alternative Solutions

Describe alternatives you've considered A completely custom solution might also be desirable, such as a YAML file that can be read/written to directly in Node-RED. These could read variables into global (or flow) context.

Additional Info

Additional context Add any other context or screenshots about the feature request here.

[mhlmhl]

The solution should support four more scenarios:

• Archiving the configuration to ThingsBoard for potential analytics and/or problem analysis.
• Backup/restore of the configuration from a central site. An individual TM's access key, WIFI SSID, and WIFI access key would have to be entered locally in order to remotely load from a central backup, but all other parameters could be restored from a previous backup. That would save time-and-effort in situations where a TM is being recovered after a failure. (I assume the TB URL would be defaulted to a standard value.)
• Central configuration management where some configuration parameters are defined in ThingsBoard and then sent to a TM when it comes online. The device name and location could be defined centrally and shipped to the TM on request. Again, the access key and WIFI parameters would still have to be entered locally.
• If we are willing to write custom images for each device, and have the WIFI information available, we could setup the entire configuration in advance before installing a TM. This would minimize the on-site effort.

The goal of the ideas listed above is to shift more of the TM installation effort from custom on-site support to a scenario where much of the work is done centrally, in advance. This should reduce cost and make a difference when we are installing and supporting many units.

None of these ideas add significant new requirements to the original goal stated by this issue. They do reinforce the value that we get from capturing all the configuration parameters in one (or at least a small number of) places.

I do not suggest that these scenarios should be implemented with this issue. I just want to raise the future directions that we may want to go, and that are simplified by capturing all the configuration parameters in one place.