Edge App Academy · 1 / 5

Name the incoming state handler

Create the portable definition and a named entry point for plant messages.

YOUR TASK

Make this happen

2 steps

Build plant-monitor with a receive handler loading scripts/receive.lua.
Check the complete solution, then inspect any unmet requirements.

THE IDEA BEHIND IT

What this step adds

Build plant-monitor with a receive handler loading scripts/receive.lua.

Files to work in

handlers.cococo. Other files are the working baseline. New files include named resource skeletons and TODO guidance. Complete their fields and connect them using the objectives, schema completion and reference guide.

Work near the equipment

An Edge App runs on a controller with access to local protocols. A platform Integration coordinates tenant resources; the two products have different responsibilities.

Definition before installation

This definition is reusable. It does not select a controller or install anything. The handler returns the received payload; it is not yet connected to a message source.

Checks validate authored native models and lesson connections. No controller, MQTT broker, protocol request, handler or installation is executed.

Files to change: handlers.cococo

What you’re building: Build a portable plant-state listener whose broker settings and secrets belong to each controller installation.

Read the starter files

main.cococo

edge_app_document "main" {
  format = "1"
  handle = "plant-monitor"
  name = "Plant monitor"
  handlers = [edge_app_handler.receive]
}

handlers.cococo

edge_app_handler "receive" {
  name = "receive"
  # Source file supplied for this field: scripts/receive.lua
  # TODO: attach it with source = file(...).
}

scripts/receive.lua

bridge.log.info(params.topic)
return params.payload

Supplied supporting files

Reference: edge-apps · getting-started edge-apps · definitions edge-apps · scripts-triggers edge-apps · mqtt-opcua edge-apps · industrial edge-apps · exec-http edge-apps · diagnostics edge-apps · reference