Claim codes, OEE, jobs, fuel, trips, and CO2

OEE, Fuel, and Trips are dashboard widgets and Solutions (PlantOee, FuelOps, TripOps). They are not left-bar menu items. Deep links /oee, /fuel, and /trips still open the expert pages when you need settings, purchases, drivers, or overspeed.

Claim code

A tenant admin can print a one-time claim code from Devices. The QR content is that code. It is not the device token. The board may poll POST /api/v1/device-claims/handoff before anyone redeems the code. Those polls do not use the code up. The Android app or the Devices page redeems the code, which creates the device in that tenant. The board then collects the token once. Success is HTTP 201 with deviceId and deviceToken. After that handoff, the code is dead. Creating a device by hand, with a token, stays. The ESP32 example that stores the token is sdk/examples/Claim_https. It does not print the token. That path is not board-verified.

A QA run must not create a normal device. Mint with "qa": true and a name that starts with QA (the letters QA and a space). The API rejects any other name when qa is true.

1. POST /api/device-claims with a signed-in tenant admin. Body: { "name": "QA claim board", "qa": true }. The response contains code. Do not print that code into a log you keep.
2. Poll POST /api/v1/device-claims/handoff with { "code": "<code>" } before redeem. The answer is 401, "This code has not been claimed". The code is still live.
3. POST /api/device-claims/redeem with the same admin and { "code": "<code>" }. This creates the device. The name starts with QA .
4. Poll handoff once more. Success is HTTP 201 with deviceId and deviceToken. Store the token. Do not print it.
5. Poll handoff again. The answer is 401, "This code is no longer available".

Mobile push

The Android app registers an FCM token for the signed-in user. Alarm create, the same path as mail and Telegram, also sends a push to users who registered. The tap opens the alarm. It does not acknowledge it. Quiet hours are left off. Push follows them only if you turn them on later. Delivery needs FCM_SERVER_KEY on the server. Without that key, the alarm is still stored and mailed. iOS is not in this release.

OEE

Open Solutions → PlantOee (Sample On) or add the OEE widget to a dashboard. It sits beside Machine Fleet Runtime. Availability is planned hours against time the machine was on load (machine_load_state = on_load). Performance uses shared attribute machine_expected_cycles_per_hour. Quality uses good_count and reject_count when both are sent. If they are absent, quality and OEE stay blank. No counts are invented. A downtime reason is a label you add, and an event you record while the machine is stopped. The Pareto is those events. Setup: Plant OEE.

Work orders

A work order is a shared job note on a device or asset: job to be done, who opened it, who closed it. It does not mail or Telegram anyone — alarms already do that for the shift. Open one by hand, from the alarm page, or from Service due when the hours run out. A tenant admin can delete a closed work order. An open job must be closed first. An alarm does not open a job by itself. The rule engine node Open work order opens one for a condition you choose. Profile alarm rules still run.

Fuel

Open Solutions → FuelOps or add the Fuel events widget. Fuel uses fuel_volume_l. On the device profile, set the rise in litres, the hold time, and the drain in litres. Those settings can be read back (expert page /fuel or the API). Stop speed is 1 km/h unless you set another value. The fuel page does not ask for it, so a saved row still shows speedMax 1. A rise that holds is a refill. A drop while speed is at or under that stop speed, or ignition is off, that holds for the same time, is a drain. The screen says drain — not theft. You can type a purchase in litres on /fuel. The report compares detected refill with what you typed. Setup: Fuel Ops. For tank fleet lists, use FuelFleet.

Trips and drivers

Open Solutions → TripOps (route map + Trips list) or add those widgets yourself. The route map keeps its on-screen stop count. The server stores a trip when speed, speed_kmh, or ignition says the vehicle moved, then stopped. Posted telemetry is queued before it is stored. The trip is recorded when that queued reading is accepted, in arrival order. A reading the plan interval does not store still counts for that trip. A rule-engine drop or hold does not. Each stored trip has start, end, kilometres, duration, and idle. Drivers, overspeed limits, CSV, and mail schedule stay on the expert page /trips and the Trips API. Harsh brake and acceleration are counted only when the device sends harsh_brake or harsh_accel. A mail schedule exists and stays off until you enable it. Monday energy mail stays off. Setup: Trip Ops. Live GPS fleets: SiteTrackingFleet.

CO2

Tenant Settings holds a grid factor and a diesel factor. You can change both. The defaults are 0.716 kg per kWh and 2.68 kg per litre, labelled as defaults. Saving those two numbers again clears a custom row, so the factors are defaults once more. Scope 2 is kilowatt-hours, last reading minus first, times the grid factor. Solar kilowatt-hours are tonnes avoided, using the same factor. Scope 1 is fuel_volume_l times the diesel factor. This is not a legal BRSR filing.

Trackers

A GT06 listener is off until TRACKER_GT06_PORT and TRACKER_GT06_TENANT_ID are set. The box is matched by IMEI. A new IMEI becomes a device in that tenant. Latitude, longitude, speed, and ignition are normal telemetry. Unknown frames are counted and dropped. Teltonika Codec 8 is a later release. HTTP and MQTT device APIs stay as they are.