Time Series data for controllers connected to other devices
I just did a basic calculation: assuming a row size of 200Byte, you'll create more than one TB raw data per year, 3GB per day.
This raised a few questions:
What is your strategy for data compression (e.g. get the min/max values per day/month, store it separately and remove/archive the raw data)?
How will the data be used (what kind of queries, how often)?
How often will controllers be added or removed?
What is the data distribution of devices per controller?

These are the key question in order to modify the (normalized) design concept, if needed.

In a normalized form I'd go with the following design:
tables:
Controllers (ControllerId, ConSerialNumber,ConDescription,...)
Installations (InstallId, ControllerId, InstLocation, InstInstallDate, InstRemovedDate,..) -- to allow a reuse of controllers at different locations
Devices (DeviceId, DevSerialNumber,DevDescription,...)
Device_per_Installation (DpIId,InstallId,DeviceId,DevInstallDate, DevRemovedDate,...)
DeviceData (DpIId, SendDate, Param1, Param2,...) -- I assume you'll shred the JSON data to get the actual values instead of the JSON file as a whole in order to save overhead

Add a controller can be done automatically (without any manual code or even data manipulation): the new data can be inserted in the controllers and installations tables if the information does'n already exist.
In order to deal with the data volume I'd use horizontal partitioning (per Installation, most probably)

Alternatively, you could use a separate table per controller,
But this would either force you to use dynamic SQL or to modify the code whenever a new controller is added. This will reduce the size per table to about 30GB per year, but the overall data volume will still be about 1TB.

Your idea to have one column per device indicates that you're not planning to "shred" the JSON data.
If you ever plan to query those columns to aggregate the values of a specific parameter, it'll take a significant amount of time, since all rows have to be scanned and "shredded" to get the values.
But if you don't plan to query the data anyway, I'd question the need to store it in a database in the first place. Store it on the file system instead...

To summarize:
The database design might be influenced by the specific business case due to the data volume. I recommend to get a database expert involved to help you design the best performing solution, not only for the table design, but for the code to insert/query/aggregate/archive the data as well as database maintenance, too. Otherwise you'll end up with major performance or maintainability issues sooner or later.