Control device development

To register as a developer of control devices:

1. Sign in to your Realer account.
2. Click at the top right of any Realer page and select Account.
3. Click on Register as control device developer.
   If you are already registered as developer, you will see Control device developer account.
4. Provide your developer account details e.g. business name, logo, and website.
5. Click Register as developer.

To get control device API keys:

1. Go to your developer account page on Realer.
   You need to register as a control device developer.
2. From your developer account page, click New device license.
3. Choose the subscription plan for the control device that you want to develop and click the corresponding button with the price.
4. Follow the on-screen instructions to make the payment.

After checkout, Realer redirects you to the control device page containing the generated API keys. Keep the client_id and client_secret secure; firmware uses them at the OAuth token endpoint to obtain access tokens for device API calls.

Plan the integration first, then build firmware against the Realer API documentation. API Docs define the exact OAuth client-credentials authentication, runtime bootstrap, catalog, desired-state, feed-data, MQTT payload, field, and response-code contracts.

Use the integration planning guide to confirm the runtime path: HTTPS polling or MQTT broker messaging over TLS. Then use the API Docs getting started page when you are ready to implement.

Before writing firmware, decide what the device physically controls or observes, how it connects to the Internet, which Realer control-device record it belongs to, and which runtime capability it will use.

• Create or select the control-device record and get API keys for firmware provisioning.
• Confirm the runtime path assigned to the device. A device uses one runtime path: HTTPS polling or MQTT broker messaging over TLS. Use the API Docs runtime page for the exact split.
• Plan OAuth token handling early. The firmware authenticates as the device through OAuth client credentials, then reads the runtime bootstrap descriptor before protected API work.

The integration planning guide covers the decision path. Use the API Docs getting started page when you need exact implementation references.

Design the device contract before coding the firmware loop. Decide which outputs are commands, which inputs are sensors, how Realer desired-state requests should be applied, and which values the device must report back.

• Use runtime bootstrap at startup and the device catalog API Docs to understand how Realer represents command and sensor definitions.
• Use feed-data API Docs to distinguish command state reports from sensor readings.
• Choose meaningful measurement units and quantity contexts for numeric values.
• Keep UI text separate from firmware identifiers: resource and dashboard rows use row labels, while a sensor description is extra UI detail. Firmware should rely on technical catalog fields such as kind, quantity context, measurement unit, and pin or port.

Keep command, sensor, desired-state, and feed-data design at the guide level. Use field semantics for retry, ordering, correlation, expiry, and result-handling rules.

Test firmware in a controlled environment before connecting it to live equipment or exposing it to other users. A Realer control device can affect physical actuators, sensors, and safety-critical systems.

• Keep API keys out of public repositories, logs, client-side code, and shared screenshots.
• Use isolated hardware, simulated loads, or disabled outputs when validating command handling and feed-data reporting.
• Verify local fallback behavior for lost Internet, expired credentials, rejected API responses, and broker disconnects before production use.

For the safety baseline, read developer responsibility before live testing.

Firmware should treat Realer as a cloud control plane that can be temporarily unavailable, reject invalid data, or stop accepting cloud operations when the subscription or credentials are no longer active.

• For rejected HTTPS results, use response codes and field semantics to decide whether to retry, ignore, reconcile, or enter local safe behavior.
• For authentication, bootstrap, and MQTT runtime failures, renew OAuth tokens and short-lived MQTT credentials through the flows documented in authentication and MQTT flow.
• For subscription or entitlement loss, expect cloud API access to stop and follow the subscription ending guide.

The API failure handling guide covers firmware behavior. Use API Docs for exact request, payload, and response contracts.

The measurement-unit reference helps when a numeric command or sensor value needs the right engineering unit.

The quantity-context reference helps when a numeric value needs the right physical or domain meaning.