# An Incorrect Temperature Conversion Lookup Table in Home-Automation Code

DevFeed: [An Incorrect Temperature Conversion Lookup Table in Home-Automation Code](<https://devfeed.tech/articles/codesod-heating-up-28508.md>)

Original publisher: [Read original article](<https://thedailywtf.com/articles/heating-up>)

Author: Remy Porter

Published: 2026-09-03T06:30:00Z

Content type: opinion

Language: en

Sources: [The Daily WTF](<https://devfeed.tech/sources/the-daily-wtf.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [floating-point](<https://devfeed.tech/topics/floating-point.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [codesod](<https://devfeed.tech/tags/codesod.md>), [errors](<https://devfeed.tech/tags/errors.md>), [floating-point](<https://devfeed.tech/tags/floating-point.md>), [open-source](<https://devfeed.tech/tags/open-source.md>)

## AI overview

The article examines home-automation code that uses a floating-point lookup table to convert Celsius to Fahrenheit. It explains that several mappings are incorrect and that using floating-point values as map keys can also cause lookup failures because of rounding errors.

## Source excerpt

A common option for retrofitting heating and cooling into older homes is a mini-split, frequently tied to a heat pump. They're (relatively) cheap to install, energy efficient, and can be added without substantial modifications to the home. They also, annoyingly, are mostly controlled via IR remotes, making them challenging to wire up to home automation or even a household thermostat. People have made solutions, and today's code comes from one of those solutions. Which, I want to stress, this code comes from an open source project for home automation, so it's not the code that's wrong, here. At first I thought it was, and had a moment of, "I'm not going to pick on some hobby project," but then I realised the hobby project points at a deeper issue. // temperature helper these are direct mappings based on the remote float toFahrenheit(float fromCelsius) { // Lookup table for specific mappings const std::map<float, int> lookupTable = { {16.0, 61}, {16.5, 62}, {17.0, 63}, {17.5, 64}, {18.0, 65}, {18.5, 66}, {19.0, 67}, {20.0, 68}, {21.0, 69}, {21.5, 70}, {22.0, 71}, {22.5, 72}, {23.0, 73}, {23.5, 74}, {24.0, 75}, {24.5, 76}, {25.0, 77}, {25.5, 78}, {26.0, 79}, {26.5, 80}, {27.0, 81}, {27.5, 82}, {28.0, 83}, {28.5, 84}, {29.0, 85}, {29.5, 86}, {30.0, 87}, {30.5, 88} }; // Check if the input is in the lookup table auto it = lookupTable.find(fromCelsius); if (it != lookupTable.end()) { return it->second; } // Default conversion and rounding to nearest integer return roundf(fromCelsius * 1.8 + 32.0); } Okay, I am going to pick on their code a little bit; using float as a key in a map is asking for trouble, because rounding errors are going to surprise you. But honestly, failing to find the key you're looking for is better than the opposite, since that actually does the correct thing. Because if you look carefully at the table, you'll see that it's wrong. 18C, for example, should be 64F. Well, 64.4F, but we're rounding to an integer. The choice here is to roughly map every 0.