On the Making of Bespoke Devices [/ɔn ðə ˈmeɪkɪŋ əv ˈbespoke dɪˈvaɪsɪz/] n - A custom device begins as a question. A rack runs too hot in one corner. A vendor sensor costs too much. An old chiller speaks a protocol nothing else understands. The work is to turn that question into a small, reliable, documented thing that dwells in the rack and leaves the operation better than it found it.

1. Of the Question Itself

Write down, in one sentence, what the device is meant to do. Then put the harder questions:

• What problem does this solve? [/ˈwhæt ˈprɒblɛm ˈdɒɛs ˈthɪs ˈsɒlvɛ/] n If the answer is “we want to monitor X,” ask what decision changes once X is known. A sensor no one acts upon is only more noise.
• Who owns it? [/ˈwhɒ ˈɒwns ˈɪt/] n A device without an owner becomes a ghost. Name the person who will notice when it falls silent.
• Is there a commercial option? [/ˈɪs ˈthɛrɛ ˈæ ˈkɒmmɛrkɪæl ˈɒptɪɒn/] n If a vendor already sells it, buy it. Custom work is for gaps, not for reinventing wheels.
• What is the safety boundary? [/ˈwhæt ˈɪs ˈthɛ ˈsæfɛti ˈbæʊndæri/] n Whatever touches mains power, fuel, or moving machinery passes into qualified-person territory. Keep to the low-voltage, signal side unless you hold the training and the approval.

2. Of Procurement

The bill of materials for a small device is usually trivial; the decisions around it are not:

• Compute. [/ˈkɒmpʌtɛ/] n A Raspberry Pi serves when you need Linux and networking. An Arduino or a smaller microcontroller suits simple, low-power, real-time tasks better. See Single-board computer for the trade-offs.
• Sensors. [/ˈsɛnsɒrs/] n A Temperature sensor is never merely a temperature sensor; you must choose accuracy, range, response time, and whether it asks for calibration. For power, a Current transformer can measure load without cutting the conductor.
• Connectivity. [/ˈkɒnnɛktɪvɪti/] n Ethernet is reliable but wants a cable. LoRaWAN reaches farther yet adds gateway complexity. Power over Ethernet carries power and data in a single cable.
• Enclosure and mounting. [/ˈɛnklɒsʌrɛ ˈænd ˈmæʊntɪng/] n A device in a rack needs a box, strain relief, and a way to keep its place. 3D-printed brackets suffice for prototypes; metal or DIN-rail mounts are fitter for production.
• Documentation budget. [/ˈdɒkʌmɛntætɪɒn ˈbʌdgɛt/] n Every custom device wants a one-page record: what it does, what it connects to, who owns it, and how to replace it. If you cannot write that page, the device is not ready.

3. Of Prototype and Trial

The first version should be ugly and swift. Its purpose is to answer the question, not to be admired.

• Breadboard first. [/ˈbrɪːdbɒærd ˈfɪrst/] n Prove the sensor and the microcontroller can speak to one another before you contrive any permanent mount.
• Log everything. [/ˈlɒg ˈɛvɛrithɪng/] n During testing, record raw values, timestamps, and every anomaly. You will want that baseline to spy out drift later.
• Stress the edge cases. [/ˈstrɛss ˈthɛ ˈɛdgɛ ˈkæsɛs/] n What befalls the device when the network drops? When the sensor is unplugged? When it reboots? A device that works only on the bench is not finished.
• Run it in parallel. [/ˈrʌn ˈɪt ˈɪn ˈpærællɛl/] n Set the custom device beside the existing monitor for some weeks and compare the readings. If they disagree, learn why before you trust the new one.
• Harden it. [/ˈhærdɛn ˈɪt/] n Move from SD card to industrial storage, add a watchdog, wrap the cables, and label it. Then write the runbook.

4. Of Deployment and Retirement

A deployed device must be visible in the monitoring system, the asset management system, and the on-call rotation. It wants, too, a plan for the day it is no longer needed: a documented power-down, an export of its data, and the recovery of its parts.

The best custom devices are those that at last become needless, because someone upstream finally built the feature you required.

See Bespoke Devices for the Datacenter for the broader context and Raspberry Pi in the datacenter for a concrete example. For how these devices feed into monitoring, see On Early Detection.