In 1999, NASA lost the Mars Climate Orbiter because one piece of ground software calculated thruster impulse in pound-force seconds while the navigation software consumed it as newton-seconds. The mishap report calls it "the failed translation of English units into metric units." The spacecraft, part of a $327.6 million program, passed just 57 kilometers above Mars, far below its planned altitude, and disintegrated. Sixteen years earlier, an Air Canada 767 ran out of fuel at 41,000 feet because its fuel load had been computed with the pounds-per-liter factor instead of kilograms.
Multiplying by 1.8 and adding 32 is easy, unless the components disagree about what those numbers really mean.
If you build connected products, you are running that system every day. A single temperature reading crosses your firmware, a radio protocol, your cloud, and at least one app before a human sees it, and every hop is a chance to convert twice, round wrong, or obey the wrong preference. Unit conversion looks like a display detail. It behaves like a distributed-systems problem.
The same failures show up in smart-home support forums year after year. A thermostat app that reverts to Celsius after a restart. A device screen showing both units at once. Changelogs quietly noting fixes for "wrong celsius/fahrenheit calculation."
A famous consumer example is the iPhone's Weather app. For a stretch of iOS 14, it would not display 69°F. The widely accepted explanation: the app consumed whole degrees Celsius and converted at display. 20°C gives 68°F; 21°C gives 69.8°F, which rounds to 70. No integer Celsius value lands on 69, so the number couldn't exist on screen. The data was right, the formula was right, and users still saw a wrong number.
Apple's underlying architecture was the correct one.
The consensus pattern is to store one canonical unit and convert only at display. Google's Nest API accepts setpoints exclusively in Celsius, with display scale as a separate trait; Matter and Zigbee transport temperature as an integer in hundredths of a degree Celsius. Blynk's unit conversion works the same way: the raw value stored on the server is always the value the device sent, and historical data, the API, and exports stay in the device's original unit.
The alternative, storing whatever unit each component happens to use, ends the same way every time: the formula gets duplicated in firmware, backend, and dashboard code with slightly different rounding in each, and eventually a rounded display value feeds back into logic and fires a threshold that shouldn't. The firmware copies are the expensive ones: fixing those means an over-the-air update to the fleet, not a server-side change.
But canonical storage is necessary, not sufficient. Two more layers need deliberate design.
Some devices stream the same measurement in two units on two separate virtual pins: an ESP32 publishing °C on V1 and °F on V2, say. Most platforms don't model this. They see one formula and apply it regardless, so switching to Fahrenheit means recalculating from V1 even though V2 already holds the device's own conversion, often with calibration the server-side formula can't reproduce. Two conversions now disagree, and the platform confidently shows the wrong one.
Blynk's answer is a "Convert using" control in the unit conversion config: Formula (default, applies the conversion as before) or Datastream (reads a selected datastream directly, no formula). Point it at V2, and Fahrenheit mode reads V2, full stop. Same principle as canonical storage, one level down: sometimes the right value isn't computed, it's already sitting on a different pin.
One degree Celsius is 1.8 degrees Fahrenheit. Any product that lets users adjust a setpoint has to decide what a "step" means in each unit, and the two step ladders never align.
A building-automation vendor called 75F (that really is the company's name, after the temperature) hit this in production: their devices stepped setpoints by 0.5°F, and the equivalent steps in Celsius mode broke their dual-setpoint heating/cooling logic. The fix they published is a rounding policy: explicit rules for which decimal ranges round up, down, or to the half-degree.
The formula is one line. The rounding policy, the step sizes, and the agreement about who converts where: that's the actual feature.
When the device has a physical °C/°F button, the user has an app preference, and the account belongs to an organization with its own standard, which one wins?
Real deployments need all of those layers at once. A manufacturer shipping a hardware unit switch needs the app to follow the device; a US company with European sites needs organization defaults users can still override. And the layers need an explicit priority order: the forum threads about apps "stuck in Celsius" are usually two preference layers fighting.
This is the part most platforms never model, and it isn't hypothetical: Blynk customers from Windmill (consumer smart ACs) to Raypak (heating equipment since 1947) ship products where every one of those layers is real at once. Blynk's shipped answer is a four-level hierarchy with a documented priority: a device-level unit conversion switch (keeping a physical button and the app in sync, in both directions) overrides the user's preference, which overrides the organization's, which overrides the template default. Org admins set the organization-wide default in organization settings; users can override it from the app's settings, or stay on a default that follows whatever the organization is set to. "Imperial everywhere, but Celsius for temperature" is a setting, not a support ticket.
Temperature is only the most visible case. In industrial products, the units often aren't on any standard picker at all. Water treatment sizes softeners in grains per gallon while quality reports arrive in mg/L. Brewers configure equipment in degrees Plato. Refrigerant pressure reads in psi in North America, bar in Europe, and kg/cm² on plenty of gauges in India.
A platform can keep appending to its built-in unit list, and they all do: Blynk added pH as a datastream unit in December 2025. But industrial customers always have one more unit no list anticipated. The only end state is letting customers define their own.
This is why Blynk rebuilt its unit system over the past few months: a redesigned conversion engine, user- and organization-level presets, Smart Unit Scaling (2.5 kg instead of 2500 g), and Custom Units: define your own units and use them across datastreams, metafields, dashboards, and widgets. Data Converters cover the devices already in the field: a unit baked into shipped firmware can be translated by a script at ingestion, no firmware change required. And unit handling is still an active area of improvement, particularly for multi-user deployments and devices with their own unit conventions.
If you're building a connected product, or evaluating an IoT platform to build on, the checklist that falls out of decades of expensive unit bugs is short:
None of this is glamorous work, so it gets skipped, and the same bug that took out a Mars mission keeps shipping in thermostat apps. It's also the kind of infrastructure that has no business consuming your roadmap: on a low-code platform where the unit system is already built, your effort goes into the product your customers pay for. The formula was never the hard part.
Building a connected product with users on both sides of the metric line? Get started with Blynk. The unit system is already done.
.png)
