LattePanda IOTA – eeCLOUD Demo Project (Community Preview)

Question

Hi everyone,

I’d like to share an upcoming demo project built around "LattePanda IOTA", focused on a real-world usage scenario using "eeCLOUD".

The goal of this project is to provide a practical, hands-on example that shows how LattePanda IOTA can be used as an edge device within a cloud-connected architecture, covering both development and deployment aspects.

At the moment, the project is being developed openly on GitHub and should be considered an "early preview / work in progress".
The demo will be finalized and validated on real LattePanda IOTA hardware once it becomes available.

🔗 GitHub repository:
https://github.com/PETRUS749/eeDEMO

The repository will include:
- source code
- configuration examples
- documentation and setup notes
- updates as the demo evolves

I’ll personally follow this topic and the LattePanda community channels to:
- answer technical questions
- clarify design choices
- gather feedback or ideas from anyone interested in the project

If you have suggestions, use cases you’d like to explore, or questions about the approach, feel free to jump into the discussion.

More updates coming soon.

Giovanni.Petruzzellis · Answer

Part 3 of 5 - The Device Agent

Hi everyone 👋

In the previous parts we introduced the architecture and completed the project setup.

Now it’s time to move into the core runtime component of the demo:

the Device Agent running on LattePanda IOTA.

This service is responsible for:

- registering the device

- fetching desired configuration

- applying runtime changes

- reporting device state

- publishing telemetry

At this point, the system starts behaving like a real edge/cloud platform.

1. What is the Device Agent?

The Agent is a lightweight .NET background service running directly on LattePanda IOTA.

Its role is simple:

- eeCLOUD → desired configuration
- LattePanda Agent → applies configuration
- LattePanda Agent → reports telemetry + state

The Agent continuously synchronizes with eeCLOUD while remaining completely independent from the dashboard.

This separation is important because:

- devices can continue operating even if the dashboard is offline

- multiple dashboards or services can interact with the same backend

- the edge device remains autonomous

2. Device registration

On startup, the Agent registers itself inside the devices memory.

Example payload:

{
  "deviceId": "LP-001",
  "group": "lab",
  "name": "LattePanda IOTA Demo"
}

This allows the Admin Dashboard to automatically discover active devices without any manual provisioning step.

One of the goals of this demo is minimizing infrastructure friction:

- no schema creation

- no manual database setup

- no device pre-registration

The device simply starts and begins interacting with eeCLOUD.

eeCLOUD automatically creates the required storage structures when needed.

3. Fetching desired configuration

The Agent periodically checks eeCLOUD for configuration updates.

The flow is intentionally simple:

- Try device-specific configuration

- Fallback to group configuration

- Apply runtime changes

The configuration is fetched using indexed reads through the SDK.

Conceptually:

await client.ReadByIndexAsync<DeviceConfig>("desiredConfig", deviceId);

This allows the dashboard to publish configuration updates centrally while devices remain loosely coupled.

4. Runtime configuration

One interesting aspect of the demo is that configuration changes are applied live.

For example:

- telemetry interval

- log verbosity

- sampling settings

can all be updated remotely without restarting the Agent.

A simple protection layer is also used:

samplingMs = Math.Clamp(samplingMs, 100, 60000);

This prevents invalid or dangerous runtime values from breaking the device loop.

5. Reported state

The Agent not only receives configuration, it also reports its current state back to eeCLOUD.

This is stored in the reportedState memory.

Example payload:

{
  "deviceId": "LP-001",
  "appliedConfigVersion": 3,
  "lastSeenUtc": "2026-05-24T10:15:00Z"
}

This pattern is very common in IoT systems because it separates:

- desired state

- actual applied state

The dashboard can therefore verify whether a device has successfully applied the latest configuration.

6. Telemetry publishing

The Agent periodically pushes telemetry data to the telemetry memory.

Example payload:

{
  "deviceId": "LP-001",
  "cpu": 22.4,
  "memory": 41.1,
  "timestampUtc": "2026-05-24T10:15:01Z"
}

The current demo intentionally keeps telemetry simple and easy to understand.

The focus is not on creating a full monitoring platform, but on demonstrating:

- the edge/cloud communication flow

- the remote configuration model

- the eeCLOUD integration pattern

7. Why this architecture?

The interesting part of this approach is that the backend stays extremely lightweight.

eeCLOUD acts as:

- persistence layer

- synchronization layer

- configuration distribution layer

without requiring:

- custom database schema

- ORM mapping

- message broker setup

- complex infrastructure

This keeps the demo small while still reflecting patterns commonly found in real production IoT systems.

8. What’s next

In Part 4 we’ll move to the Blazor Admin Dashboard:

- device list

- telemetry visualization

- remote configuration publishing

- auto-refresh patterns

That’s where the system becomes interactive from the operator side.

GitHub repository:
https://github.com/PETRUS749/eeDEMO

As always, feedback and ideas are welcome.

Giovanni.Petruzzellis · Answer

Remote Config & Telemetry on LattePanda IOTA with eeCLOUD

Part 2 of 5 - Setup, eeCLOUD Application & First Local Run

Hi LattePanda community 👋

In Part 1 we introduced the architecture of a small remote configuration and telemetry system for LattePanda IOTA using eeCLOUD as the data layer.

In this second part we'll set up the eeCLOUD side, configure the local .NET projects, and run the demo locally with:

a Device Agent that simulates the edge device workloada Blazor Admin Dashboard to monitor devices and publish configuration

The goal is practical: get the system running end-to-end without creating a custom backend, database schema, or server infrastructure.

What we need before running the demo

For this part you need:

- .NET SDK installed - An eeCLOUD account - An eeCLOUD Application and API key - The demo repository cloned locally

The repository is organized into three projects:

Shared/
Agent/
Admin/

Shared contains the common C# models used by both the Agent and the Dashboard.

Agent is the device-side .NET worker. This is the part that would run on the LattePanda IOTA.

Admin is the Blazor Server dashboard used to inspect devices, telemetry, state, and publish configuration.

Step 1 - Create an eeCLOUD Application

Go to:

https://eecloud.io

Create an account or sign in, then create a new Application.

For this demo, the Application is the isolated data space used by both:

- the Device Agent - the Admin Dashboard

After creating the Application, copy its API key.

You'll use the same API key in both local projects.

No manual memory creation required

This is an important point.

You do not need to create database tables, schemas, migrations, or collections manually before running this demo.

The code uses eeCLOUD memories directly through the SDK. A memory is selected by name when the application reads or writes data.

The current project uses four memories:

MemoryWhat it storesMain index used

`devices`	registered device identity	`deviceId`
`configurations`	desired configuration for devices or groups	`deviceId` or `group`
`states`	latest reported device state	`deviceId`
`telemetry`	telemetry points from devices	`deviceId`

The memory names above are the actual names used in the code.

Real eeCLOUD usage from the code

Here is a real example from the Device Agent.

When the Agent starts, it registers or updates the device in the devices memory:

var existing = await _ee.Memory("devices").ReadByIndexAsync(deviceId);

if (HasRows(existing))
{
    await _ee.Memory("devices").UpdateAsync(existing!.area![0]!.address, device);
    return;
}

await _ee.Memory("devices").WriteAsync(group, deviceId, device);

The pattern is simple:

- Select a memory by name- Read by index- Update if the record exists- Write a new record if it does not exist

Telemetry is written in a similar way:

await _ee.Memory("telemetry").WriteAsync(deviceId, new TelemetryPoint(
    DeviceId: deviceId,
    TimestampUtc: DateTime.UtcNow,
    Metrics: metrics
));

So the Agent does not call a custom backend API. It writes directly to eeCLOUD using the SDK.

Configuration flow

The Admin Dashboard publishes configuration into the configurations memory.

The Agent checks configuration in this order:

- device-specific configuration using deviceId- group configuration using group

The relevant code is:

var deviceConfig = await ReadConfigByIndexAsync(deviceId);

if (deviceConfig is not null)
    return deviceConfig;

return await ReadConfigByIndexAsync(group);

This means you can publish configuration for a single device, or publish a fallback configuration for a whole group.

The Agent only applies a configuration if its Version is greater than the version currently applied.

After applying it, the Agent reports the applied version through the states memory. The Dashboard can then show whether the device actually applied the change.

Giovanni.Petruzzellis · Answer

# Remote Config & Telemetry on LattePanda IOTA with eeCLOUD
## Part 2 of 5 - Setup, eeCLOUD Application & First Local Run

Hi LattePanda community 👋

In Part 1 we introduced the architecture of a small **remote configuration and telemetry system** for LattePanda IOTA using **eeCLOUD** as the data layer.

In this second part we'll set up the eeCLOUD side, configure the local .NET projects, and run the demo locally with:

- a **Device Agent** that simulates the edge device workload
- a **Blazor Admin Dashboard** to monitor devices and publish configuration

The goal is practical: get the system running end-to-end without creating a custom backend, database schema, or server infrastructure.

### What we need before running the demo

For this part you need:

- .NET SDK installed
- An eeCLOUD account
- An eeCLOUD Application and API key
- The demo repository cloned locally

The repository is organized into three projects:

```
Shared/
Agent/
Admin/
```

**Shared** contains the common C# models used by both the Agent and the Dashboard.

**Agent** is the device-side .NET worker. This is the part that would run on the LattePanda IOTA.

**Admin** is the Blazor Server dashboard used to inspect devices, telemetry, state, and publish configuration.

### Step 1 - Create an eeCLOUD Application

Go to:

https://eecloud.io

Create an account or sign in, then create a new **Application**.

For this demo, the Application is the isolated data space used by both:

- the Device Agent
- the Admin Dashboard

After creating the Application, copy its **API key**.

You'll use the same API key in both local projects.

### No manual memory creation required

This is an important point.

You do **not** need to create database tables, schemas, migrations, or collections manually before running this demo.

The code uses eeCLOUD memories directly through the SDK. A memory is selected by name when the application reads or writes data.

The current project uses four memories:

| Memory | What it stores | Main index used |
|---|---|---|
| `devices` | registered device identity | `deviceId` |
| `configurations` | desired configuration for devices or groups | `deviceId` or `group` |
| `states` | latest reported device state | `deviceId` |
| `telemetry` | telemetry points from devices | `deviceId` |

The memory names above are the actual names used in the code.

### Real eeCLOUD usage from the code

Here is a real example from the Device Agent.

When the Agent starts, it registers or updates the device in the `devices` memory:

```csharp
var existing = await _ee.Memory("devices").ReadByIndexAsync(deviceId);

if (HasRows(existing))
{
await _ee.Memory("devices").UpdateAsync(existing!.area![0]!.address, device);
return;
}

await _ee.Memory("devices").WriteAsync(group, deviceId, device);
```

The pattern is simple:

1. Select a memory by name
2. Read by index
3. Update if the record exists
4. Write a new record if it does not exist

Telemetry is written in a similar way:

```csharp
await _ee.Memory("telemetry").WriteAsync(deviceId, new TelemetryPoint(
DeviceId: deviceId,
TimestampUtc: DateTime.UtcNow,
Metrics: metrics
));
```

So the Agent does not call a custom backend API. It writes directly to eeCLOUD using the SDK.

### Configuration flow

The Admin Dashboard publishes configuration into the `configurations` memory.

The Agent checks configuration in this order:

1. device-specific configuration using `deviceId`
2. group configuration using `group`

The relevant code is:

```csharp
var deviceConfig = await ReadConfigByIndexAsync(deviceId);

if (deviceConfig is not null)
return deviceConfig;

return await ReadConfigByIndexAsync(group);
```

This means you can publish configuration for a single device, or publish a fallback configuration for a whole group.

The Agent only applies a configuration if its `Version` is greater than the version currently applied.

After applying it, the Agent reports the applied version through the `states` memory. The Dashboard can then show whether the device actually applied the change.

### Step 2 - Configure the Admin project

Do not commit real API keys to the repository.

For local development, use .NET User Secrets.

From the repository root:

```bash
cd Admin
dotnet user-secrets init
dotnet user-secrets set "eeCLOUD:ApiKey" "YOUR_API_KEY"
```

This gives the Blazor Dashboard access to your eeCLOUD Application.

The Admin project uses the API key to:

- read registered devices from `devices`
- read latest reported state from `states`
- read telemetry from `telemetry`
- publish configuration into `configurations`

### Step 3 - Configure the Agent project

Open another terminal from the repository root:

```bash
cd Agent
dotnet user-secrets init
dotnet user-secrets set "eeCLOUD:ApiKey" "YOUR_API_KEY"
dotnet user-secrets set "Device:DeviceId" "LP-001"
dotnet user-secrets set "Device:Group" "lab"
dotnet user-secrets set "Device:Name" "LattePanda IOTA - Demo"
```

For the tutorial, these values are enough:

| Setting | Example value |
|---|---|
| `Device:DeviceId` | `LP-001` |
| `Device:Group` | `lab` |
| `Device:Name` | `LattePanda IOTA - Demo` |

In a real project, these values could come from device provisioning, environment variables, or a local configuration file.

### Step 4 - Run the Admin Dashboard

From the repository root:

```bash
cd Admin
dotnet run
```

Open the URL printed by ASP.NET Core, usually something like:

```text
https://localhost:xxxx
```

At this point the dashboard may not show any devices yet. That's expected: the Agent has not registered a device yet.

### Step 5 - Run the Device Agent

Open a second terminal from the repository root:

```bash
cd Agent
dotnet run
```

The Agent will start its background loop.

On each cycle it will:

- register or update the device in `devices`
- read configuration from `configurations`
- write reported state into `states`
- write telemetry into `telemetry`
- wait for the current sampling interval
- repeat

Now go back to the Admin Dashboard.

Open the **Devices** page. You should see `LP-001`.

Open **Telemetry**, select the device, and press **Load**. You should see recent telemetry points and a simple SVG chart.

---

### Step 6 - Publish a configuration change

In the Admin Dashboard, open **Publish Config**.

Try this configuration:

```json
{
"samplingMs": 500,
"logLevel": "Debug"
}
```

Use:

```text
Target: device
Target ID: LP-001
Version: 1
```

Then click **Publish**.

The Agent will read the new configuration from `configurations`, apply it, and report the applied version back through `states`.

You can confirm this in **Device Details**, where `AppliedConfigVersion` should match the version you published.

### Why this matters

This example is intentionally small, but the pattern is useful.

A hardware or embedded developer can focus on:

- device behavior
- sensors and local logic
- telemetry generation
- runtime configuration
- reported state

eeCLOUD provides the API-based data layer used by both the Agent and the Dashboard.

That means the first version of an IoT project does not need to start with a custom backend, database setup, or infrastructure work.

### What's next

In **Part 3** we'll go deeper into the **Device Agent**.

We'll look at:

- the .NET worker lifecycle
- device registration
- configuration polling
- device vs group fallback
- telemetry generation
- reported state updates

The full source code is available on GitHub:

https://github.com/PETRUS749/eeDEMO

Questions, suggestions, or use cases you'd like to see covered? Drop them in the replies.

*Giovanni Petruzzellis - Nextsys / eeCLOUD*

Giovanni.Petruzzellis · Answer

Remote Config & Telemetry on LattePanda IOTA with eeCLOUD

Part 1 of 5 — Introduction & Architecture

Hi LattePanda community 👋

This is the first post in a series showing how to build a remote configuration and telemetry system for LattePanda IOTA using eeCLOUD, a developer-first Data-as-a-Service platform for .NET.

By the end of this series you'll have a fully working system: a .NET Device Agent running on the IOTA that publishes telemetry and applies remote config, and a Blazor Admin Dashboard where you can push config changes and monitor your devices in real time.

No servers to provision. No database to manage. Just code.

What problem are we solving?

Once you move beyond a single device, edge projects start to share the same pain points:

How do I change a parameter (sampling rate, log level, feature flag) on a running device without redeploying?How do I know a device is alive and what config it's currently running?How do I store and query telemetry without setting up a backend from scratch?

This demo tackles all three with a simple, readable architecture that you can clone and adapt to your own projects.

The three components

The system is built around three pieces that talk to each other through eeCLOUD:

[ LattePanda IOTA ]        [ eeCLOUD ]        [ Admin Dashboard ]
Device Agent (.NET)   ←→   Data layer    ←→    Blazor Server App

1. Device Agent (.NET Worker)

Runs on the LattePanda IOTA (Windows or Linux). It:

- Registers the device identity (deviceId, group, name) - Periodically reads the latest desired config from eeCLOUD - Applies config changes live (e.g. adjusts samplingMs at runtime) - Writes telemetry (CPU, memory, custom metrics) and reported state back to eeCLOUD

2. eeCLOUD (Data layer)

Acts as the shared data backbone. It stores everything, devices, config versions, telemetry, reported state, and exposes a simple REST API that both the Agent and the Dashboard use. No backend code required on your end.

3. Admin Dashboard (Blazor Server)

Runs on your laptop or a server. It:

- Lists all registered devices and their last-seen status - Lets you publish a new desired config (per device or per group) - Shows telemetry in a live SVG chart - Confirms which config version each device has applied

Data model — four collections

eeCLOUD organises data into Memories (think: tables or collections). For this demo we use four:

MemoryWhat it stores

`devices`	deviceId, group, name, metadata, createdAtUtc
`configurations`	targetType (device/group), targetId, version, config payload, publishedAtUtc
`states`	deviceId, lastSeenUtc, appliedConfigVersion, runtime info
`telemetry`	deviceId, timestampUtc, metrics payload

The design is intentionally minimal. desiredConfig uses a targetType field to support both device-level and group-level config with the same structure.

The Agent always checks for a device-specific config first, then falls back to the group config.

The demo flow in ~2 minutes

Here's what the finished system looks like in action:

- Open the Admin Dashboard → Telemetry page, select device LP-001, press Load → see live chart updates arriving from the IOTA.

- Go to Publish Config → change samplingMs from 1000 to 250 → increment version → click Publish.

- Return to Telemetry → data points arrive 4× more frequently → Device Details confirms appliedConfigVersion has updated.

That's the core loop: publish → detect → apply → confirm.

What's next

In Part 2 we'll cover:

- Creating an eeCLOUD Application and API key - Defining the four Memories in the dashboard - Setting up the .NET solution structure

The full source code is already available on GitHub if you want to explore ahead: 🔗 https://github.com/PETRUS749/eeDEMO

Questions, suggestions, or use cases you'd like to see covered?

Drop them in the replies — I'll follow this topic throughout the series.

Giovanni Petruzzellis — Nextsys / eeCLOUD