Currently, we vaguely track the lending and returning of tools in make, but we can do a lot better. The idea; a new type of Core that handles access to tools instead of equipment.
At pair time, a Core identifies itself as an Equipment or Tool Core. This then lets it access the websocket API endpoints for each of these.
There are not huge differences between the APIs, the most notable changes to a Tool API is that;
- States of a tool controller are different (Available, Unavailable, Pending Staff Check-In, etc.)
- The hardware can be the source of truth for the state that a channel is (i.e. a key tracker knows if its key is there or not)
- The Tool Core can both ask to authorize release of an equipment to a person, and state the return of equipment by a person (or returned by no person if the tool controller doesn't do that).
- The Core can ask the server who has a piece of equipment checked out. That state is maintained until the equipment is returned.
The hardware would likely used the 15 pin interface but have different uses for the logical pins. For instance, we don't need the concept of an Interrupt or an Access line for loaning tools.
Currently, we vaguely track the lending and returning of tools in make, but we can do a lot better. The idea; a new type of Core that handles access to tools instead of equipment.
At pair time, a Core identifies itself as an Equipment or Tool Core. This then lets it access the websocket API endpoints for each of these.
There are not huge differences between the APIs, the most notable changes to a Tool API is that;
The hardware would likely used the 15 pin interface but have different uses for the logical pins. For instance, we don't need the concept of an Interrupt or an Access line for loaning tools.