Endpoints & Devices

Endpoints & Devices is where your real-world data enters env-neqtoai-staging.kinsta.cloud. An Endpoint is the connection your hardware talks to. A Device is a single piece of equipment sending data. An Attribute is one measurement that device reports, such as temperature, humidity, or battery. Get these three right and everything else (dashboards, alerts, analytics, maps) just works.

Data reaches env-neqtoai-staging.kinsta.cloud in two ways. Most devices publish to a Device Endpoint, as shown above. A device can also be created from an Integration — data pulled in from an external cloud service, rather than published by the device itself. Either way it becomes a Device with auto-mapped Attributes. Every device is labelled by its Source (Endpoint or Integration) so you can tell the two apart; see the Source column on the Devices list below.

Quick Start

If you already know env-neqtoai-staging.kinsta.cloud, here is the short version.

• 1
  Open an application and go to Device Endpoints. Click Add Device Endpoint and pick a connectivity type: MQTT, HTTPS, or WSS.
• 2
  Copy the credentials shown on the final step (Stream ID, host/URL, port, username, password, and the CA certificate). Use Download details to save them all, or copy each value with its own copy button.
• 3
  Open How to connect a device and use the recommended neqtoai-std example or another supported JSON shape. No hardware yet? Create a Demo endpoint and use the built-in Simulator instead.
• 4
  Within seconds the Device appears (identified from the MQTT topic or payload) and its Attributes are auto-detected. Open the device to see live data, then build a dashboard or an alert.

Device Endpoints

An Endpoint is a secure inbound channel. It owns the connection settings and credentials, and the devices that publish to it are grouped underneath it.

Connectivity types

You choose the type when you create the endpoint, and it cannot be changed afterward.

Each type also has an Authentication Type. For MQTT the choices are “MQTT with TLS (Recommended)” (a security token over a TLS connection) or “MQTT with no TLS” (username and password). For HTTPS and WSS the choices are “Basic Authentication” (username and password) or “None”. The older fully unencrypted HTTP and WS variants have been retired, so only the secure HTTPS and WSS types are offered.

Create an endpoint

Click Add Device Endpoint. You first choose how to set it up: Create Device Endpoint (a new one), Create Demo Device Endpoint (for the Simulator), Use an existing Device Endpoint (shown only when you already have one), or Create Aruba Device Endpoint (the HPE Aruba integration). Choosing Create Device Endpoint opens the form below.

• 1
  Enter a Device Endpoint Name (required).
• 2
  Pick the connectivity type (MQTT, HTTPS, or WebSocket) and, where there is more than one option, its authentication type. The connectivity type is fixed once created. To change it, you create a new endpoint.
• 3
  If you have permission to manage applications, you can assign the endpoint to applications so the right teams can see it.

Sending Data: Payload Guidance

env-neqtoai-staging.kinsta.cloud accepts flexible JSON payloads and provides neqtoai-std as the recommended, most predictable envelope. Every endpoint has a built-in How to connect a device helper that shows this example tailored to your endpoint’s protocol, with supported alternatives, a field reference, and troubleshooting tips.

MQTT topic options

For an MQTT endpoint, the topic shown in the endpoint details is the recommended env-neqtoai-staging.kinsta.cloud topic. You can publish to that topic as before, or use one of the supported vendor-native topic shapes below. Use the same endpoint username and password or security token; you do not need to change the endpoint configuration.

Names in braces are placeholders: replace them with your values. For example, losant/{deviceId}/state could be losant/freezer-17/state. The trailing {...} shown for Azure means that an optional vendor suffix is accepted; do not publish the braces literally.

When a supported topic contains a device identifier, that value becomes the device’s External ID and takes precedence over device_id in the payload. Without a topic identifier, env-neqtoai-staging.kinsta.cloud can use a stable top-level or nested payload identifier, or the endpoint’s only linked device. Channel names are case-sensitive.

MQTT topics may be at most 512 characters. A device identifier captured from a supported topic may be at most 128 characters. Control characters are rejected in topics and topic-derived identifiers; printable vendor punctuation and Unicode are accepted.

Third-party names identify compatible topic formats only and do not imply affiliation with or endorsement by those third parties.

Recommended payload example

This neqtoai-std JSON is the recommended starting point. Equivalent supported JSON shapes are accepted. Reading keys are your own sensor names and may be top-level or nested under any object wrapper; you do not need to encode units into the names.

{
  "payload_format": "neqtoai-std",
  "timestamp": 1716806400000,
  "device_id": "AA:BB:CC:AA:BB:02",
  "data": {
    "temperature":     { "value": 22.4, "unit": "c" },
    "humidity":        { "value": 62.3, "unit": "%" },
    "battery_percent": { "value": 82,   "unit": "%" },
    "rssi_dbm":        { "value": -55,  "unit": "dBm" }
  }
}

Envelope fields

Envelope field names match case-insensitively, ignoring underscores and hyphens. Common device-id aliases include device, mac, serial, sn, dev_eui, imei, and external_id. Timestamp aliases include ts, time, datetime, reported_at, and epoch. Wrapper names are not special; nested objects are inspected recursively.

Reading fields

• Sensor reading: { "value": <number | string | boolean>, "unit": "<unit>" }.
• Unit: free-form text, up to 50 characters. Common units: °C, °F, %, hPa, V, A, W, dBm, m/s, kWh, lux, ppm. Use "state" for on/off or categorical values.
• Scalar / categorical: a plain string, number, or boolean, for example "status": "normal". env-neqtoai-staging.kinsta.cloud classifies it and infers a measurement unit or "state" when possible.
• Naming: field names are your own labels. You do not need to put the unit in the name; env-neqtoai-staging.kinsta.cloud classifies each reading automatically.
• Mixed: you can mix the reading and scalar forms in the same payload.

Multiple devices through one endpoint

One endpoint can carry many devices. Give each message a stable, unique device identifier in a supported MQTT topic or payload (for example, device_id, serial, or a strong nested identifier). Without an identifier, automatic fallback only applies when exactly one active device is linked to the endpoint.

Structured timestamp (neqtoai-std only)

With payload_format set to "neqtoai-std", you can use this object instead of an epoch timestamp. The offset uses the ±HHMM convention.

"timestamp": {
  "year": "2026", "month": "05", "day": "26",
  "hour": "14", "minute": "30", "second": "00",
  "offset": "+0900"
}

How to deliver it

Troubleshooting

Managing endpoints

Each row in the Device Endpoints table has an actions menu. Click the ⋮ (three-dot) icon in the Actions column on the right of the row to open it. This is where you reach Edit (to rename the endpoint) and, on demo endpoints, the Simulator.

• Search the list by endpoint name.
• View Details re-opens the credentials summary and lists every device currently publishing to the endpoint.
• Simulator opens the built-in Simulator (shown only for demo endpoints, inside an application, and only when you have the Simulator view and execute permissions). See below.
• Edit changes only the name and description. Connection settings stay fixed.
• Delete removes the endpoint after a confirmation. Devices that depended on it stop receiving data.

Devices

A Device is one physical thing reporting data. Most appear on their own when data arrives, but you can also add one manually, which is useful for pre-registering hardware before it ships or before it is powered on.

The list view

• Connectivity shows next to each device name: green Wi-Fi when connected, red when not.
• Source shows how each device entered env-neqtoai-staging.kinsta.cloud: an Endpoint badge for devices that publish to a Device Endpoint, or an Integration badge (with the integration’s name beside it) for devices pulled in from an external service through an Integration. This column is shown by default.
• Search by name, and filter by tag — either from the toolbar Tags filter or the Tags column header.
• Switch between Enabled and Disabled devices with the toggle. Disabled devices are ones you have soft-deleted.
• Sort by most columns, including Last connected to surface quiet devices.
• Choose your columns with the Columns control. Several (External ID, Vendor, Model, Account, Notes, Profiles) are hidden by default, and your choice is remembered per application.
• Profiles shows how each device’s data is parsed: EnOcean (with its EEP), BLE, or STD. This column is hidden by default.

Device Edit (device details)

Click a device row, or choose View Details or Edit from its actions menu, to open the device page. The page is now titled Device Edit — the one place you both review and edit a device. It has these tabs:

Connectivity: how “online” is decided

Organizing devices

• Tags are key:value labels (for example floor:3 or site:warehouse-A) you can filter the whole list by. See the Tags section for managing them.
• Vendor and Model are device metadata you can show as columns and sort by; use Tags when you want to filter or group devices.
• Add to application from a device’s actions menu (on the main Devices list) to control which teams see it.

Disabling, restoring, and deleting

Removing a device is a two-stage, reversible process. From an active device’s actions menu, Disable is a soft-delete: the device moves to the Disabled list. From there you can Enable it to bring it back, or Permanently Delete it to remove it for good. Switch the list toggle to Disabled to see disabled devices and these actions.

Attributes

An Attribute is a single measurement a device reports, such as temperature, humidity, battery, or occupancy. This is the part most platforms make you configure by hand. env-neqtoai-staging.kinsta.cloud does it for you.

What you can edit

You cannot change what gets detected, but you can make it readable. Open the row’s actions menu and choose Edit:

• Display Name: a friendly label (required, up to 255 characters), for example rename t1 to “Supply air temp”.
• Units: the unit shown with the value (up to 50 characters), for example °C, %, or hPa.

The underlying Attribute Name is fixed and shown read-only on the edit form.

Display Name and Units are account-scoped: a change applies everywhere that attribute appears across your account, for every user (the raw unit sent in the payload stays as the fixed mapping key — only the display unit shown in the UI changes). Permission to edit Attributes can be granted at the application level as well as the account level.

Demo Endpoints and the Simulator

No hardware? Create a Demo endpoint and drive it with the built-in Simulator to prototype dashboards, validate payloads, and test alerts and anomaly detection, all from a demo device endpoint.

• 1
  Create a demo device endpoint from within an application (Device Endpoints, Add Device Endpoint, Create Demo Device Endpoint).
• 2
  Open the endpoint’s Simulator action. Use Add Device and pick a Device Template, give it a Device Name, and set an Interval (s).
• 3
  Start Gateway to begin publishing. Devices auto-register and their Attributes auto-map, exactly as real hardware would. You can also use Send Raw Payload to post a specific JSON shape, or adjust each device’s value ranges.

Simulated values follow realistic daily curves. Temperature and humidity rise and fall over the day, and occupancy or people-counts peak during business hours, so dashboards and alerts behave as they would in production.

How many devices and how fast they publish depends on your plan.

Limits and Good to Know

The per-plan figures match the plan cards in Billing; your account’s live limits come from the billing service and an Enterprise plan is custom.

• Keep device identity stable. Use a supported topic identifier or payload field such as device_id. If the chosen identifier changes, env-neqtoai-staging.kinsta.cloud treats the hardware as a new device.
• neqtoai-std is recommended, not required. It selects the most predictable path directly; payloads without payload_format are detected and normalized automatically.
• Endpoint type is permanent. Decide MQTT, HTTPS, or WSS up front.
• Quiet devices look offline. Match each device’s connectivity timeout to how often it actually reports.
• Let auto-mapping work. Send clean, consistently structured JSON and your Attributes stay tidy with no manual setup.