A software company building a farm platform often wants field hardware, rather than another mandatory dashboard. The important question is the complete data route: where measurements and images go, who controls access, and what happens if a network or service is unavailable.
Describe the whole route
Draw the route from sensor or camera to gateway, network, receiving server and application. Identify which part supplies device identity, timestamps, measurements and image storage. A cloud dashboard, a device protocol and an open API are different layers. An API that only reads a manufacturer cloud does not meet a requirement for data to bypass that cloud.
Define a delivery contract
An HTTPS push specification should name the endpoint path, method, content type, authentication scheme and response codes. Decide whether the image is uploaded as binary or multipart data, or whether a JSON message carries an accessible image link. If using links, agree ownership, access authorization and expiry. Never assume that a link visible inside a vendor dashboard is available to your server.
Keep units and identity stable
Agree a versioned schema with device ID, event ID, timestamp and units. Specify UTC or an explicit timezone offset and distinguish measurement time from upload time. A gateway may batch several samples after an outage. A stable event identifier allows the receiver to reject duplicates without discarding valid late data.
Test security and recovery
Use HTTPS and a project-approved authentication method. An HMAC-SHA256 design needs an agreed canonical message, secret provisioning, timestamp window and replay protection. Do not place production secrets in a public inquiry form. Test lost connectivity, timeouts, repeated messages, rejected credentials and image-download failure. Record the retry and local-buffer limits for the selected firmware.
Match the protocol to the device
Modbus can expose register data; MQTT can carry telemetry and event metadata; ONVIF and RTSP apply to compatible camera and video systems. LoRaWAN requires the correct regional plan and a network server. These protocol names are not interchangeable, and availability must be confirmed for each model and firmware. Full-resolution image delivery requires its own bandwidth and power assessment.
Our current starting point
Our existing collection gateway uploads images and data over HTTP to our server. A standard public pull API or general export service is not currently available. Direct delivery to your receiving system can be developed for an agreed device configuration. The integration development charge is quoted separately as a one-time scope; hardware, connectivity and any optional hosting are separate. Reuse with another device depends on matching its firmware, fields and data contract and passing compatibility tests.
Before requesting a quotation
Send a clear project brief.
- Receiving-system specification and a non-production example endpoint
- Sample measurement and image payloads, timestamps and units
- Authentication, retries, buffering and duplicate handling
- Written acceptance criteria and supported device/firmware list
Continue your project
Customer-platform integration options ↗
Raw images for your own pest AI ↗
Ask Icey about your configuration ↗