Studio Site Management

The Site management page maintains Watchdog connections, gateway access, runtime status and backup operations. Management connectivity and business data synchronization are configured and verified separately.

For the illustrated installation, enrollment, deployment and data workflow, follow Center and edge deployment.

This page covers connections, remote maintenance and batch program updates across sites. Projects owns local validation, deployment and retrieval; Watchdog owns project application, logs and process supervision at one site.

Before connecting

Prerequisites

• Confirm that the Studio server can reach Watchdog Web and obtain its host, port and valid account.
• Enable the required remote-management and deployment permissions before uploads, restores or process controls.
• Identify the target site before applying a project or backup, especially when sites have similar names.

Page entry

Menu path: Studio Web > Site management.

Use the site’s operation menu to open Watchdog through Site operations, or to edit or delete the connection. Gateway and Watchdog use separate accounts.

Meaning of Status

Connect and test a site

Enroll a site

1. Add a site and choose Edge connects to center. Enter the reachable center hostname, local Watchdog and Gateway ports, and Watchdog credentials.
2. Save and select Generate enrollment code from the site’s operation menu.
3. Open Watchdog → Tunnel management → Connect to center. Enter the center HTTP/HTTPS URL and code.
4. Verify that both management tunnels are connected and bound, then test the site and open its gateway UI from Studio.

The code expires after ten minutes and can be used once. Regenerating it, editing or deleting the site, or restarting Studio revokes an unused code. No management package needs to be transferred. LAN deployments can use direct connections. TLS is optional; see Management certificates for private-CA trust and renewal.

Add or edit a site

Click Add site, or select Edit from an existing site’s operation menu.

After saving, it is recommended to click “Test” immediately. A successful test only means Studio can access Watchdog; Whether the target TGateway can run properly depends on the gateway status and Watchdog logs.

Studio uses the saved Watchdog account to log in automatically and encrypts the login password. It handles login verification for connection tests, status updates, project transfers, and backup management. After a Watchdog restart, Studio logs in again and retries once.

Connection Test

Check in order when tests fail:

1. Can the browser or server access http://<watchdog-address>:<port>?
2. Can Watchdog Web log in with the same account and password?
3. Whether the firewall allows Watchdog ports.
4. Whether the Watchdog service is activated.
5. If accessed through the tunnel, confirm that both Studio Broker and Watchdog Client have been successfully bound.

Back up and transfer projects

Back up and restore site connections

Before backing up or moving the site connections saved in Studio, stop Studio and save both Data/watchdog_configs.json and Data/studio_credentials.key from its runtime directory. To restore them, place both files in the destination Studio’s Data directory before starting the service. Keep the key with the connection configuration so that saved passwords and site access details can be restored.

If the key is lost or the saved connections cannot be decrypted, stop Studio and move the original Data/watchdog_configs.json to a backup location. Start Studio and add the sites again with their Watchdog credentials. For sites using Edge connects to center, generate a new enrollment code and enroll again from Watchdog.

Backup Management

Click “Backup” in the Watchdog card or list operation to open the backup drawer.

Before confirming restoration, check the site, backup name, project, and scope. Project backups keep the installed program; project program packages overwrite their packaged program files; complete snapshots restore the project and the entire gateway program. On-site caches remain unchanged.

The backup panel shows the name, type, project, creation time, size, and actions. Long names wrap. In a narrow window, scroll horizontally to inspect the columns; Restore and Delete remain fixed on the right.

Allow a maintenance window for program restoration and check the scope in the confirmation dialog.

After restoring, verify the gateway and business data path. The Studio local copy is unchanged; download the project again when needed.

Linking with Project Upload

When uploading a project from “Projects”, the target gateway list comes from the Watchdog services saved on this page.

Use the project deployment checks for backup, platform matching and data acceptance. This page maintains the target connection; an online test still needs to be followed by collection and forwarding checks on the site TGateway.

Integration with Project Download

When clicking “Download from Gateway” in “Projects”, the source gateway also comes from the Watchdog services saved on this page.

Downloading supports site configuration retrieval, fault reproduction, and version comparison. The current project returns its latest live content; non-current projects return saved content. Stop a same-name local project before overwriting it; its local identity, creation time, and Web port are retained. Open and edit the downloaded project in Studio, validate it locally, and upload it again. See Projects for project content and overwrite rules.

Web responsibilities and data synchronization

Watchdog Web responsibilities

Configure center-edge data synchronization

At the site, select Data synchronization. Enter the center Gateway management URL and separate credentials for both Gateways. Gateway and Watchdog accounts are independent; passwords are cleared when the panel/page closes.

1. Choose GatewayMqtt or SyncBridge and enter the center data host/port reachable from the site. Management URLs and data ports are separate endpoints.
2. Optionally enable Use TLS; it is off by default. Studio issues and installs the data certificates. The center retains the CA signing key and server certificate; the site receives the public CA, and SyncBridge also receives a per-site client certificate with its private key.
3. Select Connect both Gateways to sign in, check the plugins and read the edge’s enabled forwarding groups. Create a group at the edge first if none exists, then reconnect.
4. Select the edge forwarding group. Its existing variable scope and trigger remain; this does not automatically include every edge variable.
5. Select Configure and enable. Studio saves center and edge settings and checks the real data link. GatewayMqtt applies the center variable plan after the first snapshot. The panel reports each stage; completed stages remain after a failure so that you can repair and retry.

GatewayMqtt deploys a GatewayMqttCollectServer at the center and a MqttClientProducer at the edge. Sites sharing a center address/data port share the listener, preserving existing sources and credentials. Repeating the operation reuses objects and passwords. External-Broker deployments use GatewayMqttCollectClient in the Gateway plugin editor.

SyncBridge deploys HubServer and EdgePublisher for the selected configuration and current values. TLS uses mutual certificate verification; non-TLS retains identity/token validation. Automatically issued private certificates do not publish online revocation information, so that lookup is disabled while chain, validity, hostname and Peer identity checks remain. New links have reverse writes/RPC disabled.

All sites sharing a listener must use the same TLS mode. To change it, use a different data port or maintain the whole link in Gateway. Manage issued certificates in each Gateway; conflicting names, expired certificates and invalid purposes are rejected rather than overwritten. Studio management HTTPS trust remains separate from data TLS.

Both configurations saved confirms persistence at both ends. Data connection confirmed additionally requires the first MQTT snapshot and applied variable plan, or a connected SyncBridge Peer with its applied configuration revision. MQTT conflicts/type changes stop automatic application for review in the center collector’s debug plan. Check fresh values afterwards; management connectivity does not prove data synchronization, and current-value synchronization does not prove complete history backfill.

Verify the connection

1. Test the saved site and confirm Watchdog is online with a readable version.
2. Check TGateway status; inspect Watchdog logs if stopped or unknown.
3. Open the backup drawer and confirm that the list belongs to the intended site.
4. Confirm that this site is available in project upload/download selectors with the correct host and name.

An online management test still requires the project deployment checks on the target TGateway and data path.

Batch update gateway programs

1. Select sites in the card or table view and choose Batch update gateway program. Mobile cards also support selection.
2. Wait for the current release and site states. Check the site names, latest gateway version, and target platform. Each batch requires online sites with the same platform; update different platforms in separate batches.
3. Confirm the update. Studio downloads the complete official site package for that platform, verifies it, and uploads its gateway program to Watchdog. The site platform can differ from the Studio computer.
4. Review every site’s result. Open each updated gateway and check its version, project, collection, and forwarding. Resolve partial failures using their individual errors.

On a phone, select the checkbox at the upper-left of each site card before choosing a batch action. Filtering and changing views preserve valid selections. Check every target name in the update panel before submitting.

Leaving Sites closes the update panel and prevents an unfinished confirmation from submitting. Updates already submitted continue running. When you return, refresh site states and check the actual gateway version and operation before submitting another update.

This updates the gateway program while retaining the Watchdog host, current project, configuration, databases, scripts, custom nodes, rules, certificates, and PluginCache. Running gateways restart; manually stopped gateways remain stopped. Watchdog creates a safety backup before replacement. To roll back, confirm the Project and gateway program snapshot scope in the backup list.

Download or verification failure does not submit files to sites. The target Watchdog owns program replacement, health checks, and recovery. Verify the actual business data path after completion.

If checking for updates fails, check the network connection from Studio to the download service, then choose Check for Updates in the same panel. Your selected sites remain unchanged. No release package is available means the catalog was loaded successfully but has no release. A missing platform package is reported only after the catalog loads successfully.

If the catalog request times out, check again later. For repeated timeouts or HTTP 502 errors, record the time and complete error message and ask the download service maintainer to inspect upstream request logs. A failed catalog query does not submit a program to any site.

Frequently Asked Questions