Validation

Validation settings screenshot

The validation feature currently supports the grouping of read events between START/STOP events which can be by command or by sensor trigger (GPI). Upon receiving the STOP event, the grouped events are validated and the selected rules are applied. Currently, the existing rule is the validation of a single product code, for example, a single GTIN. One possible processing of the validation rule is an advanced GPO action available in Reader Settings which in a tunnel use case for example could direct an error box to an audit process.

Background Service

Validation is implemented as a hosted background service that caches SKU reads and their associated EPCs while validation is enabled. Each cache entry records the most recent observation time so duplicate EPCs can be suppressed across the configured validation window.

Cache lifecycle and cleanup cadence

• Time-to-live (TTL): The cache lifetime defaults to 300 seconds. The service reads this default from ValidationCacheOptions.CacheTtlSeconds, which maps to the ValidationCache:CacheTtlSeconds setting in appsettings.json.

• Runtime overrides: When reader settings include a positive validationCacheTtlInSec value (set via the Reader Settings UI, the /api/settings endpoint, or /customer/appsettings.json), the background service hot-reloads the TTL and immediately applies the new expiration horizon to subsequently processed reads.

• Cleanup interval: A maintenance loop runs every 60 seconds to evict EPC and SKU entries whose LastSeen timestamp is older than the active TTL. This keeps the cache size bounded and ensures pending validations operate on fresh data. After each sweep the service publishes a ValidationCacheSize metric with the remaining EPC and SKU counts for observability.

Manual cache clearing

The DELETE /api/validation/clear maintenance endpoint instructs the same background service to flush all cached SKUs and EPCs immediately. Manual clears are useful when operators want to start a new validation batch before the TTL-based cleanup cycle runs. Once cleared, the periodic cleanup loop continues to run on the refreshed cache and applies the latest TTL value.

Configuration guidance

Use the following settings to tune cache retention for your deployment:

• ValidationCache:CacheTtlSeconds (base configuration): Defines the default TTL applied when the reader boots. Update this value in SmartReaderStandalone/appsettings.json when building a custom image, or in /customer/appsettings.json on a deployed reader to persist site-specific defaults.

• validationCacheTtlInSec (runtime setting): Overrides the default TTL while the application is running. Configure this value through the Reader Settings UI or by sending a PATCH to /api/settings. A value of 0 or an empty field falls back to the base configuration.

• Operational tip: Align the TTL with the expected duration of a validation session. Shorter TTLs (for fast conveyor or tunnel operations) minimize stale reads, while longer TTLs benefit manual workflows where operators take additional time between START/STOP events. Remember to coordinate manual cache clears with TTL adjustments when performing workflow changes mid-shift.