What's new
PreStartGo now has one pre-start timer and one operator timeout, set in the console and sent to the Interlock with every unlock. The API follows:
checkValidityMinutes(1–1440) on equipment, sites and groups is the pre-start timer: how long a passing pre-start stays valid. Use it when you create or update them.operatorTimeoutMinutesreads as 0–180, where 0 means the operator confirms after every key-off. Writes still take 1–180 in this release; a later release accepts 0. Handle 0 when you read it.- A passing pre-start always has a
validUntil. Equipment with no timer set anywhere uses the 11-hour default, and older passes recorded without one have been given one. - On an equipment record, both timers are the values in force, taken from the machine, its site, its group or the organisation, or the defaults of 11 hours and 15 minutes. They are never null.
- Compliance counts the timer only. A machine is compliant while its last passing pre-start's
validUntilis in the future. There is no "since midnight" cut-off.
Deprecated
checkValidityHoursis still returned for one more release, computed fromcheckValidityMinutesand rounded up to whole hours. It will then be removed. Move your integration tocheckValidityMinutesnow.- Creating or updating equipment, a site or a group still accepts
checkValidityHoursfor that release, and PreStartGo stores it ascheckValidityMinutes. Organisation settings takedefaultCheckValidityMinutesonly. - On sites and groups,
deviceCheckValidityMinutesanddeviceOperatorTimeoutMinutesnow repeatcheckValidityMinutesandoperatorTimeoutMinutesfor that release, then go. - The Interlock-level
checkValidityMinutesandoperatorTimeoutMinuteson/api/v1/devicesno longer set the timers. They now report the limits every Interlock should hold, 1440 and 180 minutes. Set the timers on the equipment, its site or group, or the organisation.
Unchanged
lastCheckValidUntilon/api/v1/equipmentstill comes from the machine's latest pre-start, whichever organisation recorded it.