Yeah, it'll never get commercially distributed as I made that decision a number of years ago, and have published multiple articles on why I will take this one to my grave with me.
But let me tell 'ya -- sometimes, as a coder, you just sort of scratch your head.
This was one of them.
The codebase that runs the house here hasn't been updated since I bought the place; that's about a year and a half. No real reason to; it's been working just fine. But, I decided I'd go ahead and roll forward the OS version in question.
So I grab my test box (to boot the new one and make sure it works), do the cross-build (the target is an ARM processor), stick the resulting SD card in the test machine and..... it doesn't boot.
So off I go to find that the upstream U-Boot was updated and it renumbered the MMC slots, putting the SD card outside of the ones checked for a bootable operating system. Sort of like the old-style DOS machines that could boot two drives; you could attach more disks, but only one of the first two could boot.
How long has this been undetected in said upstream? A couple of months! Who the hell is checking this stuff? Nobody, apparently. Thanks guys.
So I put the older u-boot code back and now it starts and then fails to boot again. Some more head-scratching ensues and I remember that between 12.0 and 12.2 this bit me on AMD64 code too as the OS folks stopped updating the old "Boot1" style loader for EFI and thus it could not identify a bootable partition. That one was not hard to fix; find the loader that is being kept up to date in the object tree and make sure that gets copied into the EFI partition so it gets loaded.
Ah, now the OS boots and runs. All done, right?
The various battery-powered sensors I have around the house do not fully initialize on a cold start for about an hour, because they have to "check in"; they're not listening all the time for battery consumption reasons, so you can't poll them until they do check in. The first time they check in the system is unaware of all their capabilities so it has to perform a series of queries and set the device's configuration. By the time it has done this the unit has probably gone back to sleep, so it requires two intervals before you get good data. Not a big deal and these units do immediately respond to stimulus (e.g. motion detectors); it's just the periodic reporting of things like temperature that don't get added into the stack of maintenance requests until the system has the manufacturer-specific ID and thus knows exactly what the device is (and can do.)
Well, about an hour later it's 85F outside, the outside temperature sensors have checked in and the HVAC system goes into heating mode. It doesn't heat, obviously, as the setpoint is way below the room temperature but..... what the ****?
Putting that particular event test in debugging mode (where it logs everything as it performs the tests) says that...... the ambient test for outside temperature < 55F indeed passed. Uh, how, given that said sensor is reporting 85.6F?
Much head-scratching ensues along with code-staring.
I did find and fix it -- a dangling (not properly initialized) result variable in one of the test stanzas which then propagated through the tests and, since it was "True" that's what came back even though it wasn't.
For how long has this code been there and run perfectly-well in this state? I looked back at the git log: I hadn't touched this section of the software for more than three years!
File it away as "old bug but one that never stung me before."
Yeah, you think you didn't miss anything.... and most of the time you're right. This one time, however, well.....
Such is the life of a coder....