Inventory

A proposed inventory system for finding stuff at Hack Manhattan. Code is on Github.

Motivation

It's too hard to find things at Hack Manhattan. It will become harder and harder. We already have hundreds of different items and will probably have thousands of them soon. Even if you know which box an item is in, it may be hard to find that box.

Systems that don't involve tracking items and that are not searchable have limitations. You can try to organize things rationally, for example by having all electronics related boxes in the same area. However, there are usually multiple rational ways to sort and organize things. Does a Hall effect endstop belong in the sensors box, or the 3D printer box because it relates to 3D printers, or in the switches box because it will be used as a switch? Does a box of 3D printer electronics go in the electronics area or the 3D printer area? An inventory system should record how these questions have been answered.

Concepts

• Item: an individual item to be located. Smaller or trivial items, or very common items such as screwdrivers, may not be tracked for various reasons. Examples: "Radio Shack soldering station", "lead free solder" (any quantity), "red LEDs". Actually recording how many red LEDs are left is optional, but it is expected that some are available.
• Box: a box that contains items, including both tracked and untracked items. If a box contains untracked items, it should have some description of the types of untracked items that it contains, for example "resistor assortment".
• Location: an area in which it is easy to find boxes or items. Example: a stack of 5 boxes on the shelf known as "stack 1".
• Area: an area in which boxes or items are located. Example: "shelves near the entrance", "shelves next to Prusa 3D printer", "drawers under machine shop work table".
• Identifier: a bar code, RFID code, or similar. Shared namespace across all types.

Workflow

The system will be used when:

• an item or box is initially placed
• an item or box is moved
• you are looking for an item and you don't know where it is
• you are done with an item and you want to return it to its original location, and you don't know where that is, or a different location

The system will not be used when:

• you know where the item is
• you are done with an item and you know where it should go

Interface

Web app

A web app will be used for searching and for more complicated data entry tasks such as adding new items and descriptions.

BLE Tagging

The main community shelf has ~10 rows and 7 columns which is very difficult to search visually. If we could find a BLE tag with a +1 year battery life and a buzzer, we can develop a console next to the shelves. When a user enters what they are looking for, it will show the possible box results. Selecting a box can then trigger the tag to play a sound.

Physical terminal

The physical terminal will be used for moving items and printing labels. It will consist of a barcode reader (RFID in the future) along with a set of stock barcode commands. The physical terminal can be used to move an item to a new box, or to move a box to a new location.

The physical terminal will have a thermal printer attached that can print labels for items, boxes and locations, with the barcode.

Development notes

Fully hierarchical location structure with arbitrary depth, using PostgreSQL? Query would be:

with recursive tree
(location_id, parent_id, label, path) as (
    select location_id, parent_id, label, location_id::text as path, 1 as depth
        from locations where location_id = 5
    union
    select
        l.location_id, l.parent_id, l.label, l.location_id::text||'/'||p.path as path, p.depth + 1
    from
        locations l, tree p
    where
        l.location_id = p.parent_id
) select * from tree order by depth asc;