agrirouter 2.0
Complete changelog for the agrirouter 2.0 migration, covering new features, removed features, and migration notes
The agrirouter 2.0 release in September 2024 was a complete rebuild of the platform. This page covers the changes that matter for integration developers: removed features, new capabilities, and migration notes.
New User Interface
Changes in the 2.0 UI:
- Interactive routings view: visual management of message routes between endpoints
- Clear differentiation between onFarm-Software and onField-Devices in the UI
Removed Features
The following features were removed in agrirouter 2.0:
Account pairing allowed linking two agrirouter accounts. It was removed because it was rarely used and caused confusion.
EFDI no longer creates separate machine endpoints. Device descriptions are still required, but the machine endpoint concept is gone. Endpoints now represent the connected application or CU, not individual machines.
The groups concept for organizing endpoints has been replaced by managed routes, which handle routing configuration more flexibly and automatically.
DDI-based filtering for telemetry data has been replaced by simple telemetry routing. Instead of filtering on individual DDIs, telemetry is routed at the message type level.
Technical message types (TMTs) are no longer bundled into higher-level information types. Routes now operate directly on technical message types.
The MarketPlace has been replaced by the Solution-Finder, which is a more focused way to discover agrirouter-compatible software and services.
The metrics export functionality has been removed.
New and Changed Features
VCU Updates
Virtual CUs (VCUs) can now be updated through further PUT /endpoints/{externalId} calls. You can rename a VCU or change its configuration without creating a new endpoint.
External ID Uniqueness
External IDs are now scoped per tenant, not globally. The same external ID can be reused across different tenants, but within a single tenant an external ID cannot be used twice, even by different applications. See External IDs for the details.
Gateway Switching (MQTT to HTTP)
You can now switch an endpoint between MQTT and HTTP gateways, but data loss is possible during the switch. Messages in transit may be lost. Plan the switch during a maintenance window and make sure no critical messages are in flight.
Endpoints can switch their communication gateway between MQTT and HTTP without being re-created.
Multiple Redirect URLs
Applications can configure multiple redirect URLs for the authorization flow, which is handy for multi-environment setups (separate URLs for development, staging, and production).
Clarified Error Codes
Error codes VAL_000004 and VAL_000005 have been clarified on the legacy proto response:
- VAL_000004: all routes failed, no recipients received the message
- VAL_000005: some routes failed, partial delivery
Previously, the distinction between these two codes was ambiguous. On the current API, both conditions surface as HTTP 400 with a plain { "message": "..." } body. The numeric code is not returned on the wire, so branch on the HTTP status instead. See the Errors reference for full details.
Simplified Revoke Response
The revoke response now returns an HTTP status code with an empty body instead of a protobuf-encoded response.
Fast Route Updates
Route changes now take effect instantly. In agrirouter 1.0, route updates could take 2.5 to 5 minutes to propagate.
Managed Routes on Endpoint Creation
Managed routes are now created automatically when a new endpoint is created, so endpoints can communicate right away without manual route setup. You can turn this off if you prefer configuring routes by hand.
Router Device Names
Router devices can now have human-readable names, which makes them easier to spot in the UI and in routing configurations.
Faster Re-creation of Revoked Endpoints
Re-creating a previously revoked endpoint with the same external ID now has little or no waiting time. In agrirouter 1.0, there was a delay before a revoked endpoint's external ID could be reused.