Contact info?

[mhlmhl]

What is our approach to maintenance contact info? And how do we use the ThingsBoard (TB) Tenant/Customer/Device hierarchy (or a custom version)?

By "maintenance contact info" I mean the person we call when we notice at the TB server that a Traffic Monitor (TM) has stopped sending data. It should be a person who can easily check the device itself and try to fix it.

Background: Matt and Mark have had a debate about where we should enter contact name/address/email/etc for individual Traffic Monitors (TMs).

Mark provided a way to enter this on the TM configuration screen. It then gets sent to the ThingsBoard (TB) server as device attributes, where it can be viewed in the TB dashboard.

Matt thinks this data should be entered via the TB dashboard as Customer or maybe Device information -- not on the TM side at all. He thinks this fits better with the TB design intent, and he says "the TM itself doesn't need and would never use this information."

Mark's comments:

• Setup of each TM absolutely requires someone at the device who sets up the zones. That person might as well enter the maintenance contact info since the maintenance person is likely to be the same person.
• Mark sees potential future scenarios where a single Customer has multiple TMs, each of which might need different contact info. For example, consider a business (Customer) that has multiple physical locations, each with a TM. To me, a Customer is the "owner" of a TM, and the name and address of the Customer are more relevant to business activities, such as billing, than to maintenance. (Alternatively, we could treat a business as a "Tenant" and make each TM a Customer + a Device. But Mark's past experience suggests that we reserve "Tenant" for the possibility of business services that support multiple "Customers".)

There seem to be different underlying visions here:

1. To the extent possible, all the data is entered centrally and managed centrally. For example, the device name and access key could be setup in a TM before the TM is sent to the installation location. This runs up against the fact that some aspects of the configuration must be managed locally. It can't all be managed centrally.
2. Another vision accepts that a fair amount of local installation/maintenance work is always required, and builds upon that to allow maintenance and contact information to be entered at the TM. The information is sent to the TB server, so it is available there for viewing.

There is also a technique for having it both ways, by using a TB rule chain to process incoming client-side attributes and updating what TB calls a "shared" attribute. See this discussion.