How to debug
When importing data from an existing GEC installation, it is possible that the initial sync fails. This is because of inconsistent data, that might be stored on the configurator. Firmware versions before 2049 also created many empty data entries by default, that cannot be imported into the CareSuite.
If an error during syncronization occurs, open the brower's developer tools and switch to the network tab. Also open the console. If you run the sync again, you will see details about the error:
In this case, some entity is referencing the call source with the number 86 that does not exist. The
Proxy -> target value contains all relevant information about the sync action.
callSourceByNumber object contains all data known to the CareSuite (either from the already imported database or the currently imported CSV).
You can also inspect the last few requets in the network tab and see what data has been imported that might have triggered an error.
This problem is now handled by the CareSuite automatically
Starting from Version 5.64, the CareSuite automatically ignores all empty values (call sources and positions) while syncing data.
A common problem are empty records in an existing GEC configuration. These might show up like this:
These values cannot be imported into the CareSuite since they are invalid (a position without a name, for example). The following entites need to be checked for empty values:
- Call sources
- Display groups
- Positions (checkpoints)
- Templates (schedules)
The empty data can be removed via the configurator's web interface. If there are many empty values present, you can cleanup the data as follows:
- Export a CSV backup from the configurator
- Open the CSV file in a text edtior
- Search and remove any empty values
- Save a copy of the file (
- Wipe the data via the configurator's web interface
- Load your
config_fixed.csvinto the configurator
Once the config is fixed, try to sync again. If the sync still fails, try to make out what action failed by looking at the network tab in the browser's developer tools. The failed request is usually the 2nd or 3rd to last request in the list.
Example of empty values
# call source without a name SRC,1, , # position without a name (call source >= 100 are positions) SRC,100, # Display group without a name GRN,0, # Display group config without values (everything is 255) GRP,0,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255 # Flightprofile without a name PRN,0,
Example of an invalid config:
SRC,2,*Terminal, SRC,3, SRC,4, SRC,5,*LCD, SRC,6, SRC,100, SRC,101,Eingang SRC,102, PRN,0, PRN,1,Alles gesprerrt PRN,2,
Example of the fixed config:
SRC,2,*Terminal, SRC,5,*LCD, SRC,101,Eingang PRN,1,Alles gesprerrt
This problem no longer results in a sync error
Starting from Version 5.64, the CareSuite no longer cancels the sync process because of missing relations and shows the missing values as "gets only" changes when syncing data instead.
You still have to fix the data on the configurator directly or send the complete configuration from the CareSuite to the Gets system to override the inconsistent data.
If a device, button or indicator references a no longer existing call source, a data cleanup is required. In case of devices, the reference to the call source can be fixed by editing the device via the configurator's web interface.
Buttons or indicators usually need some more work.
A bug in the configurator's webinterface makes it possible that buttons/indicators exist in the csv export, that are not visible in the web interface. These buttons usually reference a call source that no longer exists (and therefore leads to a unsyncable change).
You will notice these invisible values in the sync view of the CareSuite: There will be a button/indicator that is always present, even after a successful sync. If you search for the button on the configurator's web interface you cannot find it as the call source it belongs to does no longer exist.
The Button in this screenshot belongs to call source 88. But call source 88 does not exist in the configurator's web interface:
There are two ways to fix this issue:
First method: Create a call source with the number the button/indicator references to on the configurator's web interface (
88 in the example above). The button/indicator will now be visible again under the newly created call source and can be deleted. The temporarily created call source can now be deleted again.
The button will now no longer be displayed as a pending change in the CareSuite's sync view.
Second method: Another way to fix this problem is to export the CSV config from the configurator and fix it manually. You will also need to look at the output in the browser's developer console to find the missing button/indicator call source.
Open a CSV export in a text editor and search for the offending
BTN line. The
BTN lines are followed by the referenced call source number and the button ID:
BTN,501,XYZ # call source 5, button 1 BTN,1001,XYZ # call source 10, button 1 BTN,1002,XYZ # call source 10, button 2 BTN,1201,XYZ # call source 12, button 1
If the CareSuite sync process logs the error
Missing relation (call source 12), this means all
BTN,12xx lines need to be removed, since they reference a call source that no longer exists (in this case there should be no call source
12 in the web interface or a
SRC,12 line in the CSV).
Save your fixed configuration as
config_fixed.csv, wipe the configurator config and re-import the fixed configuration.
Default values are not synced
The GEC configurator stores some default values as either
11111111), depending on the firmware version or how data was first created.
When importing data from an existing GEC system, the CareSuite will always save default values as
255. If the configurator has the value stored as
0, this leads to the problem that the CareSuite will always show some values as not in sync.
The problem usually occurs with indicators or buttons. Click on the changelog entry to see what values differ.
- indicates a
Another problem that can occur is that a flight profile has every possible position allowed, even those, that don't exist. In this case, the
Denied checkpoints value of a flight profile contains many more checkpoints IDs than are actually in use:
To fix this issue, check the
Send full configuration after import option and switch all values to
Send. Then start the sync process.
CareSuite will now normalize all default values on the configurator to use the
255 value. It also rewrites the flight profile to only use existing checkpoints.
After this process has finished, there should be no more changes be displayed to sync.
It is not required to commit the new configuration to the GEC hardware devices since no meaningful values have actually changed.