Choose IoT hardware before a platform

Choose IoT hardware around the operating job, not around a familiar board or a preferred platform. Public guides on IoT hardware agree on that order: define device requirements before selecting hardware design options (Telit), and start by identifying performance requirements and the operating environment (IBM). The platform choice is still consequential — platform selections can fail in practice, for example when the data model fits only one scenario or missing integration support blocks data exchange (IoT Analytics) — so it deserves the same requirement sheet, written after the hardware requirements.

Write the operating decision first

Before comparing boards, write down:

what must be measured or controlled, where, and under which operating conditions;
who uses the result, and what they will do with it;
what should happen when information is missing or delayed.

With the job written down, hardware selection becomes a comparison against that job. An illustrative example: a team wants to know whether a room needs intervention. Before selecting a sensor, it must decide which condition matters, where that condition should be observed, and who responds. A measurement that nobody can act on does not solve the original problem.

Check documented interfaces, not connector names

A connector name does not establish electrical compatibility, and a software library does not establish safe behaviour on installed equipment. For each candidate, look for three things: a documented electrical interface, a documented software interface, and evidence gathered on the actual target hardware. This is a selection method drawn from integration experience, not a claim about any specific product.

Compare complete installed responsibilities

Ask what happens during power loss, network loss and restart, and include mounting, power, cabling, interface hardware, commissioning and ongoing support in the comparison. Hardware cost includes ongoing operating costs such as power, maintenance and replacement, not only the initial outlay (IBM). A component price is therefore not the cost of an installed measurement or control function.

Ask the integration-evidence question

For each candidate, ask one question: is support demonstrated on the exact hardware and software revision? Integration effort differs by kind: adding another component of an existing type can be configuration, while a new component type or a new communication bus is a bigger engineering step. Off-the-shelf hardware suits straightforward use cases, while custom design carries integration difficulty across vendors and interdependent technologies (Telit).

Set the acceptance test before purchase

Decide what evidence would make the candidate acceptable — for example a representative bench test, its behaviour when communication is lost, and a documented replacement procedure. Keep the unknown answers visible in a shortlist with evidence, gaps and an owner for each unresolved question. That list, not a verdict that one board suits every project, is the useful output. Choose the platform and the hardware together against the same sheet.

That requirement sheet is also the input a platform needs. As we state on our Platform page: "Hardware integration depends on accessible interfaces, documentation and test access. Software changes are tested and accepted before reaching production." Your hardware remains your choice, and the code generated for your system stays available to you. Manna adapts it to your hardware, processes and goals.

If you have a requirement sheet or a hardware list for a real project, bring it to a project discussion with Manna.

Prepared with AI assistance for Manna Insect Oy.