SiteLink/tools/SiteConfigMerge/README.md

SiteConfigMerge

Decodes TeslaConsole .siteconfig files and merges multiple sites' configs into a single master.siteconfig for the central console that commands the fleet during a SiteLink event.

The .siteconfig files themselves are not stored in this repo — they change over time; sites hand them over as <siteName>.siteconfig when an event is being set up.

Usage

SiteConfigMerge dump <file.siteconfig> [...]

Decode and print each file: squads, pods, IPs, MACs, host types, key presence, and the TeslaConsole assembly identity that serialized it.

SiteConfigMerge merge -o master.siteconfig FSA.siteconfig Pharaoh.siteconfig [...]

Merge sites into one config:

• The site name is taken from each input's file name (FSA.siteconfig → FSA).
• Every squad is renamed <siteName>-<original squad name> (FSA-bay1); unnamed squads become <siteName>-squadN.
• Pod records are copied byte-for-byte from the inputs — GUIDs, IPs, MACs, keys, art paths all pass through untouched. Only the squad records (which carry the name) are re-serialized.
• The output declares the TeslaConsole assembly identity captured from the first input, so the console accepts it as its own.

Consistency checks

Under the SiteLink IP plan, none of these should ever fire. They are tripwires for plan drift, checked for free at the natural checkpoint (merge time, right before an event):

• same IP at two sites — a site hasn't renumbered into its 10.0.<site>.0/24 yet (e.g. still on legacy 200.0.0.x or flat 10.0.0.x);
• duplicate pod GUID or MAC — orthogonal to the IP plan: GUIDs are minted at provisioning and MACs are burned into NICs, so a hit means stale inventory — the same physical pod recorded in two site files (pod changed hands without re-provisioning, or a siteconfig was copied as a template).

The master is still written, but the exit code reflects the result so event scripts can gate on a clean merge:

Exit code	Meaning
0	clean merge
1	usage error
2	hard error (unreadable file, duplicate post-rename squad name — same site file given twice)
3	merged, but with warnings — resolve before the event

Build

dotnet build -c Release

Targets .NET Framework 4.8 (same toolchain as TeslaSuite); output at bin\Release\net48\SiteConfigMerge.exe, runs on any Windows 10/11 box.

File format (from TeslaSuite\Console\TeslaConsole\Site.cs)

int32 squadCount
per squad:
    BinaryFormatter(TeslaConsole.Squad)     mGuid, mName, mOnline
    int32 podCount
    podCount × BinaryFormatter(TeslaConsole.Pod)
        mId, mIPAddress, mGateway, mDns, mSubnet, mHostName,
        mKey, mMacAddress, mName, mPodArtPath, mHostType, mOnline

The tool uses stand-in types with a SerializationBinder mapping TeslaConsole.* both directions, so it has no build dependency on the TeslaSuite repo.

Verification status (2026-07-10)

• Decoded a real local.siteconfig (squad bay1, TeslaConsole 4.11.4.1 identity).
• Merged two simulated sites; duplicate-GUID and IP-overlap warnings fired correctly.
• The real TeslaConsole.exe (4.11.4.1) loaded the merged output through its own Site.LoadFromFile — squads renamed, pods intact (reflection harness).

Deploying to the central console

TeslaConsole loads local.siteconfig from its common-appdata directory at startup (Site.Load()). To arm the central console for an event: back up its existing local.siteconfig, drop master.siteconfig in its place under that name, restart the console. Restore the backup after the event.