Most of this can be tamed with competent software, which libre software can converge on in a way that throwaway proprietary embedded stuff generally does not. For example, failure of your outside temperature sensor should have just resulted in your furnace acting like it was very cold, using a bit more energy and creating a bit larger temperature swing. Furthermore, an alert of the failure through open protocols would allow for lightweight notifications through software you already use, as contrasted with the currently common commercial surveillance rigmarole.

Except the outside sensor was reporting that it was something like 75 degrees F rather than the 20 degrees F it actually was. And the microcontroller was basically going “Why doesn’t the idiot just open a window?” Not sure what the failure mode of a completely dead sensor would be.

Certainly there not necessarily anything wrong with open source controller software but it’s no Panacea either.

And what surveillance? My heating system isn’t networked at all.

The firmware could see that the value was stuck at a constant, compare your outside temp to a local forecast, see that your internal temp continued to drop, or employ other strategies for determining bad sensor data. There's little incentive for Honeywell to add such functionality (cf the paradigm where you just call a professional who diagnoses your problem), but with libre software it might just scratch someone's itch at which point the functionality would be available to all. Libre software certainly isn't a panacea, but rather seemingly a necessary condition for embedded devices to not get stuck at whatever simplistic version of zip-source-control crapware they're shipped with.

By surveillance I'm referring to what would pass for "remote notifications" of system status (after the possible bad sensor was detected). The IoTrash solution would be to backhaul your system's data to a surveillance cloud, require you to sign up for email spam, install a bespoke app that would spam you with useless notifications, faux-consent to a ridiculous anti-privacy contract, etc. Whereas in the libre world, user-focused incentives are allowed to define functionality and that notification could be a simple single email.

Making the point in general, in order for complex software to not be some terrible black box, it needs to expose its internal state to users who want to see it. Libre software tends to do that (as many users are developers), while non-libre software tends to lock all that up and thus severely limits reliability xor complexity.

I do not want my furnace second guessing the outside temperature based on a potentially unreliable local weather forecast. Yes I would generally prefer to trust verified industrial controller code from the manufacturer that trained service people are familiar with for what’s a critical system in many parts of the world.

Individuals are of course welcome to hack together what they want using Arduinos or whatever.

Again I very deliberately do not have a smart thermostat or other network connections to my heating so no surveillance is going on. I do have network-connected temperature sensor but it’s purely passive.

That's not really addressing the core of my point. Sure, you personally can choose to be conservative and not adopt something promising the world based on "libre". And you probably shouldn't unless you want to tinker. But if it becomes common and shows to be more flexible and reliable, perhaps you will change your view.

I too critically rely on heating. As system complexity increases with things like outside temperature sensors, I would much rather have visibility into their workings than not. In the middle of the night, that could be the difference between a quick ten minute diagnose and override, or waiting some hours for an emergency service call.

Suppose the furnace gets the temperature wrong, what's the worst outcome? Surely the furmware should not allow absurd values like -100 or over 100?

I honestly don’t know. And honestly for 99% of people being able to look at the code to examine what would happen is irrelevant. In this case the false reading was within basically normal parameters. It was just about 50 degrees too high which meant the house was barely being heated (was about 45 degrees inside) on a very cold day.

The function of the external temperature sensor is so that the furnace can put out a lower amount of (instantaneous) heat when it's less cold out, so that it can operate more efficiently. On cold days, it puts out a larger amount of heat to keep up with the larger heat loss requirements.

I had a similar failure with my hot water boiler, where an older solid state control failed such that when the circulator would kick on the burner would shut off. This allowed it to limp along heating, until a day when it was too cold out and I realized it wasn't keeping up.

re: libre software, my point isn't really about being able to audit the code, but rather about having a cross-device software-maintainer-maintained codebase that users choose to use.

FWIW another, probably better, way to mitigate this particular external temperature sensor failure mode would be a second larger control loop. When the indoor temperature is more than a few degrees below the setpoint (not as a result of a scheduled change), the furnace should be less-efficiently creating a larger amount of heat to get back up to the setpoint quicker. Which is funnily enough how people think most thermostats work when they ineffectively turn it up higher to get things warmer faster.