Skip to content

Data Model Basics for YenGear IoT Cloud ​

Welcome! This guide explains the core concepts you will see in YenGear IoT Cloud: Organization, Project, Device, and Point. It is written for first-time users with no technical background.

Why these concepts matter ​

  • Keep your data organized as your fleet grows.
  • Control who can see or edit data.
  • Connect sensors once, then reuse their data in dashboards, alerts, and exports.

The hierarchy at a glance ​

Organization
  └── Project  (one per site or scenario)
        └── Device  (one per physical gateway or controller)
              └── Point  (one per measurement channel)

Every piece of sensor data belongs to a Point, which lives on a Device, which lives in a Project, which belongs to an Organization.

Organization ​

  • Think of an organization as your company or team workspace.
  • Every user belongs to one or more organizations. Organization admins invite teammates and manage access.
  • Settings at this level — such as access tokens and data forwarding profiles — apply across all projects.

Project ​

  • A project is a logical container for devices that belong to the same site or use case (e.g., "Greenhouse A", "Cold-Chain Warehouse #3").
  • Use projects to separate data by location, customer, or business line.
  • Each project has a unique project_id that appears in URLs and API calls.

Device ​

  • A device represents a physical gateway, controller, or sensor node that sends data to the cloud.
  • Each device has a serial_number (hardware identifier stamped on the unit) and an agri_id (platform-assigned string used in API calls and telemetry routing).
  • Devices live inside a project; moving a device to another project transfers all its future data to the new project.

Point ​

  • A point is a single data channel on a device — for example, temperature on channel 1, humidity on channel 2, or a relay output status.
  • Each point maps to a specific Modbus register (slave ID + address) and defines how raw register values are converted to engineering units (via data_scale and data_delta).
  • Points also carry a type (the_type) that tells the platform which icon, unit, and alert logic to apply.
  • A point has its own agri_id — a compact string like d-1000-abcd-1-000 — used in telemetry payloads and API paths.

How data flows (simple view) ​

Physical sensor
  → Device reads Modbus register
  → Device gateway sends payload to YenGear IoT Cloud
  → Platform matches agri_id to a Point
  → Value is stored and displayed under the Project dashboard
  → Optionally forwarded to your own systems (MQTT, HTTP, InfluxDB…)

Typical setup steps ​

  1. Create an Organization — Your workspace; invite teammates later.
  2. Create a Project — One per site or customer.
  3. Bind a Device — Enter the serial number and safe code to link the hardware.
  4. Configure Points — Define each measurement channel: register address, data type, scale, and name.
  5. View Data — Open the project dashboard to see live values and history.

Tips for new users ​

  • Keep names simple and human-readable (e.g., "North Field Gateway", "Indoor Temp CH1").
  • Use one project per physical site to avoid mixing data across locations.
  • Configure points right after binding a device so charts show friendly names instead of raw register addresses.
  • Want to push data to your own tools? Use Forwarding Profiles in the Organization settings to set up webhooks, MQTT, or database exports.

Where to manage these items ​

In the YenGear IoT Cloud web app:

  • Organization settings → Member access, access tokens, forwarding profiles.
  • Project view → Device list, charts, alert rules, data download.
  • Device detail → Point list, real-time readings, history, control commands.

Need help? Email [email protected].