GCCAPCold chain. Clear evidence. Confidence.

Sensor and gateway pathway

Hardware architecture built around evidence, not isolated readings.

GCCAP is prepared around a Teltonika EYE EN12830 to FMC150 to GCCAP pathway. Matthew Thomsen confirmed Basic Configurator delivery for temperature, battery percentage, sensor identifier, humidity, magnet/door and movement events. RSSI requires Advanced Mode and must be parsed server-side when present.

Discuss Hardware Validation View Technical Integration

StatusRepresentative demo available now. Live pilot reporting activates after hardware validation, site approval, first payload proof and agreed data governance controls.

GCCAP
Sensor
Gateway
Evidence
Watchdog
Journey intelligenceRepresentative demo
Trial interval5 minutes target
Gateway pathEYE to FMC150 to MQTT
Open gateAutomatic stored record recovery
Scale modelValidate before rollout

Operational layer

The hardware path GCCAP is preparing.

The public story should be simple: sensors collect, gateways transmit, the server receives, GCCAP filters and separates, clients see their own evidence.

Sensors installed to carts

Cart sensors capture temperature behaviour during the approved pilot journey.

Gateways installed across the operation

Gateway positions are validated around facility, truck, return or other approved capture points.

Server receives data

Incoming payloads are preserved and then normalised for GCCAP processing.

GCCAP filters and separates

Events are separated by client, site, cart, sensor, gateway and journey stage.

Daily site understanding

Dashboards and reports build a continual view of site performance after enough validated data exists.

Multiple clients scale from the same model

Each client remains separated while GCCAP uses one evidence operating model.

Governance

Validation gates before live pilot activation.

These gates make the system credible before any client data is relied on.

  1. Sensor identity and cart mapping confirmed.
  2. Gateway capture confirmed.
  3. Payload format understood.
  4. Recorded timestamp preserved.
  5. Raw data stored.
  6. Normalised event created.
  7. Duplicate handling tested.
  8. Offline/backfill behaviour validated where available.
  9. Evidence report generated.
  10. Client governance approved.

Decision clarity

Teltonika EYE/FMC150 readiness gates

The technical blocker list is now smaller. GCCAP controls the broker, parser and mapping. Trial activation depends primarily on client approval and hardware arrival.

Payload fieldsPASS - Temperature, battery percentage, sensor identifier, humidity, magnet/door and movement fields confirmed from Matthew Thomsen email.
AVL IDsPASS - temperature 10800-10803; humidity 10804-10807; magnet/door 10808-10811; movement 10812-10815; low battery 10820-10823; voltage 10824-10827.
RSSILOW PRIORITY - Advanced Mode required and server-side parsing needed when present. Not required for Stage 1 temperature evidence.
MQTT brokerGCCAP CONTROLLED - Mosquitto can run on the same VPS as the GCCAP runtime using mqtt://localhost:1883.
Gateway identityGCCAP CONTROLLED - FMC150 IMEI is registered against client, site and gateway zone.
Sensor identityGCCAP CONTROLLED - EYE sensor name and MAC address should both be stored for usability and traceability.
Dishwasher survivabilityOPEN - still the highest hardware uncertainty and must be physically tested before permanent through-wash deployment claims.