The effects of enabling or disabling automatic parameter configuration for Campbell data sources: Part 2

When configuring a Campbell PakBus data source, you have the option to enable or disable automatic parameter configuration. Either choice can result in complex outcomes which may not be initially obvious, so we will cover this in detail over two separate articles:

• Part 1 explains how this choice affects series-to-parameter mappings and parameter creation during the initial connection to the device. It also covers the effects of changing to manual configuration and editing the series-to-parameter mappings.
• Part 2 focuses on what happens when the logger program changes after a data source has already been configured based on the original program.

Lets assume our data source has already been configured using automatic parameter configuration. The logger program at the time contained one table, Logs, which defined the following 6 fields:

1. Batt_Volt
2. Rain_Accum
3. Temp
4. Flow
5. Latitude
6. Longitude

These fields result in the following series-to-parameter mappings:

And we end up with the following automatically created parameters in the workspaces tree:

So far, this has just been revision of what we learned in part 1. However, what happens when the logger program is changed? Let's make the following 3 changes to the logger program:

1. Remove the Batt_Volt field
2. Rename the Temp field to Temperature
3. Add a new field, Height

Note that the table name has not been changed, it is still Logs.

If the data source has automatic parameter configuration enabled, what happens when a connection is made between eagle.io and the logger for the first time after the logger program has changed? The documentation says the following 3 actions will occur:

1. Field names common between the old and new program will maintain existing parameter assignment
2. Field names absent from the new program will cause assigned parameters to be disabled (greyed out)
3. Field names newly defined will be associated with new parameters

Based on this, we would expect our program changes to have the following results:

1. The 4 field names which are unchanged between the old and new program will maintain their existing series-to-parameter mappings, and the corresponding parameters will be unaffected
2. The Batt_Volt field which is absent in the new program will be absent in the series-to-parameter mappings, and the corresponding Batt-Volt parameter will be greyed-out in the workspaces tree
3. The Temp field which was renamed in the new program will be absent in the series-to-parameter mappings, and the corresponding Temp parameter will be greyed-out in the workspaces tree
4. The Temperature field which is newly defined in the new program will be mapped to a newly created Temperature parameter
5. The Height field which is newly defined in the new program will be mapped to a newly created Height parameter

Let's confirm our expectations by disabling automatic parameter configuration so that we can see the series-to-parameter mappings:

As expected, the 6 series-to-parameter mappings are based directly on the 6 fields in the most recent logger program. To confirm what has happened to the parameters, lets look at the workspaces tree:

As expected, there are two new parameters, Height and Temperature. And two parameters, Batt-Volt and Temp, have been greyed-out to indicate they are no longer associated with any series.

This demonstrate the sort of changes that happen during automatic parameter configuration, but are they the changes we actually wanted to happen? For example, if the field name that changed from Temp to Temperature in the logger program still represents the same series of data from the same sensor, then we now have a problem: all the data from that temperature sensor acquired into eagle.io before the logger program changed is represented by the greyed-out parameter Temp, while all new data that is acquired after the logger program changed will be represented by the new parameter Temperature. Since this split in the data probably isn't desirable, we can go back into the series configuration and change the mapping of the series so that it is once again associated with the old Temp parameter:

After making this change, we can now see that the old Temp parameter is once again active, while the new Temperature parameter is inactive:

As a final step, we can delete the Temperature parameter, as it won't be needed any longer. We could optionally delete the Batt-Volt parameter if we have no further need of the historical voltage data that it still represents. The workspaces tree will now only contain active parameters which are all associated with the fields of the current logger program:

It's very important to note that the continuity of identically-named fields between old and new logger programs is only possible if the table name also stays the same. For example, if the new program had changed the name of the table from Logs to SensorLogs, then all existing parameters would be disabled, and all fields in the SensorLogs table would result in new parameters.

In summary, it's important to have an understanding of what changes will occur if you change the logger program while automatic parameter configuration is enabled. If not all changes are desirable, you can still alter the configuration as required afterwards. If you suspect most changes will not be desirable, or if you just want full control over any changes, you can disable automatic parameter configuration before changing the logger program. You will then have the responsibility of making any necessary changes manually.