Skip to main content

Tools Reference

This page documents every card in EmberCORE, in the order the category carousel presents them. Each entry covers what the tool is for, what you can actually do once it is open, and which roles see it.

Cards you do not have permission for are not rendered at all, so your grid may be shorter than this page. Tenant users only ever see their own tenant's data regardless of which card they open.

How the page is arranged​

EmberCORE is three stacked blocks:

BlockHolds
MetricsThe live metric strip. Category tabs drive which metrics appear. See Metrics & Monitoring
ToolsEmberNet's own tooling. Everything in this page except the last section
Subscribed ToolsThird-party products your tenant subscribes to. Ignition and Ignition Edge today. Hidden entirely when neither applies

Cards can be dragged into whatever order suits you, and the arrangement is remembered per user. The category you last selected is remembered too.

Zero Trust Network​

Flux Console​

The control plane for the Flux zero-trust mesh. Opens a hub with three sections:

  • Flux: the overlay mesh itself.
    • Identities: every enrolled device, service, and user identity, with enrollment state and last-seen time.
    • Services: the services published onto the mesh, their addresses, and whether they currently answer.
    • Edge Routers: the routers carrying traffic, their health, and the links between them.
    • Service Policies, ER Policies, SERPs: which identities may dial which services, which routers may carry them, and how the two are bound.
    • Configs and Config Types: reusable configuration attached to identities and services.
    • Posture Checks: device conditions that must hold before a dial is permitted.
    • Auth Policies: how identities authenticate to the mesh.
  • ArcNET: the alternative transport, for sites where the overlay is not the preferred path.
  • Plasma: mesh telemetry and link quality.

Service rows show live reachability from a periodic dial probe, not just the controller's opinion. A service the controller has not listed for 24 hours is removed rather than left reading offline forever.

Industrial Automation​

AnvilMQ​

The platform's MQTT broker and protocol bridge. See AnvilMQ for the service itself.

  • Overview: broker health, connected client count, message throughput.
  • Topics: the live topic tree with retained values and last-publish times.
  • Protocol Drivers: the PLC and fieldbus drivers bridging into MQTT, their connection state, and tag counts per driver.
  • Connections: currently connected clients, their subscriptions, and session state.
  • Users / ACL: broker credentials and per-topic publish and subscribe rules. You can create users here.
  • Config: broker-level settings.

App Deployment​

App Store​

Browse and deploy curated industrial apps to your edge nodes. See App Store.

  • Catalog: the apps available to your tenant, filtered by what your role may deploy. Each entry carries its chart, version, and target requirements.
  • Running: what is actually deployed, where, and its health. Each running app exposes a LAUNCH button that frames the app's own web interface inside EmberCORE.

An app publishing more than one web interface gets a port picker in the launch overlay, so an Ignition gateway serving a console on one port and an SSL console on another can be switched between without leaving the console or losing the tab. Extra interfaces also appear as their own buttons beside LAUNCH, each with a new-tab option.

Uninstalling is restricted to apps EmberNet deployed. Pre-existing infrastructure in the same namespace is refused rather than removed.

Edge Infrastructure​

Ops​

Fleet and cluster operations for downstream deployments.

  • Fleet: the Fleet agent's view of your clusters and what is assigned to them.
  • Cluster: per-cluster detail and health.
  • GitRepos: the Git sources Fleet reconciles from.
  • Bundles: the deployed bundles and their per-cluster rollout state.
  • App Store / Deploy to fleet: push a catalog app to every cluster matching a selector, rather than one at a time.

Clusters​

External tenant clusters reachable through EmberNet.

Each row carries the cluster's display name, its node count, and its live agent state. A cluster whose agent has stopped checking in is shown as offline with how long it has been gone, rather than being reported ready on stale data. A cluster that has never checked in shows as pending. When the upstream cannot be reached the node count reads unknown, never 0.

Cinder​

Block storage orchestration. See Storage.

  • Dashboard: capacity, used and free, across the storage fleet.
  • Device: the physical disks backing the pool, per node.
  • Volume: every volume, its replica health, and what it is attached to.
  • Recurring Job: scheduled snapshot and backup jobs.
  • Backup and Snapshots: point-in-time copies, and restore from them.
  • Settings: replica counts and guardrails. When the storage API cannot be reached, default guardrails are used and the condition is reported rather than silently assumed.

Cloud Storage​

Edge-to-cloud object storage sync, to AWS S3 or Azure Blob.

  • Pick the provider, supply the bucket or container and credentials, and choose which paths sync.
  • Deploy / Update rolls the sync agent out to the selected tenant.
  • Run sync now triggers an immediate run instead of waiting for the schedule.
  • Customize exposes the per-path include and exclude rules.

Credentials are written to a secret on the target cluster, never held in the browser.

Edge Provisioning​

Deploy bring-your-own-device edge nodes into any tenant site.

  • Deploy: pick the site, generate the enrollment material, and copy the one-line install command for the target machine.
  • Provisioned Nodes: what has enrolled, when, and its current state.
  • IP Pool: the addresses available for assignment to new nodes.

Device Management​

Device Monitor​

The device registry and hardware health for non-EmberNet equipment. See Device Monitor.

  • Monitor: live health for registered devices.
  • Registry: register, edit, and retire devices one at a time.
  • Bulk Import: import many devices from CSV or Excel, with a downloadable template.

Network Devices​

Inventory, remote configuration, and topology for network equipment at your sites. See Network Devices.

Monitoring & Diagnostics​

Site Topology​

A live digital twin of a site's network, built from discovery rather than hand drawing.

  • Topology: the discovered map of devices and the links between them.
  • Live Probes: the discovery probes themselves, what they found, and when they last ran. Probes can be added, edited, and deleted here.

Live Diagnostics​

Real-time cluster diagnostics for the selected tenant.

  • Overview: nodes, control planes, deployments, and pods, each as ready over total.
  • Process Status: what is running, pending, or failing right now.
  • Infrastructure: the underlying resources behind those numbers.

Deployment counts are read in pages from the cluster API's cache, so a large cluster reports real numbers instead of timing out and falling back to zero.

Alerts​

Active alerts, history, and the rules that raise them. See Alerts & Notifications.

  • History: what has fired, when, and who acknowledged it.
  • Rules: the conditions that raise an alert and where notifications go.

The card's badge shows the live active count, and the header bell mirrors it.

Sites​

Sites​

Your physical hierarchy: plants, buildings, zones, and the assets in each. Drill from a site down to an individual building and on to a device, with the metric strip re-scoping as you go.

Compliance & Reporting​

Audit Dashboard​

Search, filter, and export the audit trail.

Filter by actor, action, target, and date range, then export the result for compliance evidence. Platform staff see every tenant; everyone else sees their own tenant's entries plus anything they personally did.

Scheduled Reports​

Generate compliance reports on a schedule and email them out.

  • Generate Report produces one immediately.
  • Create Schedule sets up a recurring report with its recipients.

Activity Timeline​

A chronological feed of recent changes and events.

Selecting a specific client narrows the feed to that tenant. The feed is queried per tenant, so a customer's history is shown in full rather than being crowded out by platform-wide traffic.

Platform​

Settings​

Users, tenant configuration, and integrations, scoped to what your role manages.

  • Users: accounts and role assignment.
  • Tenant Members and External Users: who belongs to the tenant, and guests from outside it.
  • Create Tenant (platform staff): stand up a new tenant.
  • Activity: recent administrative actions.
  • Email / SMTP: the outbound mail profile, with a Send Test Email button that proves it before you rely on it.
  • Legal: terms and retention settings.
  • Billing: subscription tier and usage.

Documentation​

Opens the platform guides and API reference, which is this site.

Manifest​

Version-controlled tenant code, configuration, and infrastructure manifests. Opens the repository backing your tenant's declared state.

Subscribed Tools​

This block only renders when your tenant actually subscribes to something in it. Platform staff always see both cards.

Ignition​

Your tenant's Ignition cloud gateway, whatever the tenant's Ignition connection names. The gateway loads framed inside EmberCORE at full size.

Where the gateway publishes more than one web interface, a port picker in the modal header switches between them without closing the modal, and a new-tab button opens whichever one is showing. The port you last used is remembered.

Sign-in is the Ignition gateway's own. EmberNet does not sit in front of it and passes no identity through, so the gateway's user accounts govern access. Gateway accounts are provisioned from your tenant's role-based access control model, so the login id you use on the gateway is the one your RBAC record carries.

Ignition Edge​

Every Ignition Edge gateway running at your tenant's sites, in one modal: pick the site, pick the gateway, pick the port.

The gateway list is built from the running ignition-edge apps, each of which already carries its site, its node, and every GUI port with the address that reaches it, so nothing is typed by hand or derived twice.

The same sign-in rules apply as for the cloud gateway, and the same RBAC model supplies the accounts, so a user's login id is the same on both tiers.

note

A port only answers if the gateway is actually listening on it. An Ignition gateway that has an SSL port configured but SSL not enabled will offer that port and fail to connect, because nothing is bound to it. Enable SSL on the gateway, or use the plain port, which is already served over HTTPS to your browser by EmberCORE's own tunnel.

Next steps​