The Schedules Live on the Devices

This week I read a sentence on the website of a ten-euro smartphone app that is a better description of good system design than anything I found in the robotics press.

The schedules live on the devices themselves, so they fire with the phone off and without any server.

The app is called TasmoShelf. It solves a small, specific, unglamorous problem: there is a large amount of cheap smart-home hardware running open firmware called Tasmota, and getting it to talk to Apple Home has historically meant running a server — a Home Assistant box, or a message broker, or both. Somebody has to keep that server alive. TasmoShelf gets rid of it. It scans your network, works out which devices can join Apple Home directly and which need one of the newer chips to act as a translator for the older ones, and hands you the pairing code.

Useful, narrow, and not the interesting part. The interesting part is that its author chose to lead with what happens when everything above the device stops working.

The Question People Ask, and the Question That Matters

When somebody is considering a monitoring system for their building, the question I get is almost always about accuracy. Will it catch the failure? How often is it wrong? What's the false alarm rate?

Those are fair questions and I answer them. They are also not the question that determines whether the thing works in your building for the next five years.

The question that determines that is: which layers have to be alive for this system to keep doing its job?

Every monitoring system is a stack. Something senses. Something decides. Something notifies. Something stores history. Those four jobs can live in four different places, and each place you put one is a thing that can be down at three in the morning in February.

An accuracy number describes the system on its best day. The layer question describes it on its worst one, and buildings fail on their worst days. That is essentially the definition of a worst day.

What Goes Wrong When Deciding Lives Somewhere Else

Here is the failure that motivates all of this, and it is not exotic.

A sensor in a mechanical room reports to a cloud service. The cloud service runs the analysis and sends the alert. This is a completely standard architecture and there is a lot of it in the field, because it is much easier to build than the alternative.

Now the building's internet connection drops for two hours on a Saturday night. The sensor is fine. The pump is not fine — it is drawing more current than it should and running longer to move the same water. Nobody is deciding anything, because the part that decides is in a data center that cannot hear the sensor.

The connection comes back Sunday morning. And here is the part that actually costs you: from the outside, those two hours look exactly like two hours in which nothing happened. Silence is what the system produces when everything is normal, and silence is also what it produces when it has gone blind. The customer cannot tell those apart, and often the vendor cannot either.

That distinction is worth being precise about, because "keep everything local" is a slogan and not a design.

The Counterexample, Which Is Also Correct

On the same day I read that TasmoShelf line, a chip company called BrainChip announced a partnership with an inspection company in Atlanta. The inspection company took BrainChip's models, retrained them on its own photographs of real defects from tire plants and semiconductor packaging lines, and put the result into production. It runs in four to six watts, which is roughly a night light.

The feature BrainChip highlighted is over-the-air model updates. The deployed system gets better over time without anybody driving to the factory.

That is a remote dependency, proudly announced, in the same week that TasmoShelf is proudly announcing the absence of one. Both companies are right, and the reason they are both right is that they are talking about different layers.

Read down the third column and the design falls out of it. An outage in the bottom three rows is an inconvenience. An outage in the top two is the system not existing. So the top two go in the building and the bottom three can go wherever is cheapest.

A detector that has not been updated in six months is a slightly worse detector. A detector that cannot see anything is not a detector.

How This Actually Sits in My Basement

My sump pump monitor watches a fifteen-dollar smart plug. The plug reports how much power the pump is pulling. The code that decides whether that pattern is normal runs on hardware in the house, about thirty feet from the pump.

I did not do that because I had a philosophy. I did it because the first version was a script on a machine I already owned and putting it in the cloud would have been extra work. The philosophy arrived later, when I noticed what the arrangement was quietly buying me.

There is a piece of that system I want to describe specifically, because it is the least impressive code I have written and it does the most work.

The monitor tracks how long it has been since it last heard from the plug. Five minutes of silence is a warning. Thirty minutes is critical. Those two numbers exist because a sensor that has stopped reporting produces exactly the same output as a pump that is behaving perfectly — which is to say, nothing — and I wanted the system to be able to tell the difference between calm and deaf.

That is the whole feature. Two constants and a timer. It is the part I would keep if I had to throw out everything else.

Five Questions, No Technical Background Required

If somebody is trying to sell you monitoring for your building, you do not need to evaluate their architecture. You need five answers, and every one of them is a plain-English question you can ask on a phone call.

1. If my internet goes out for two hours, does the system still notice a problem during those two hours? If the answer is no, or if it takes more than one sentence, deciding happens somewhere else.
2. When the connection comes back, do I find out what happened while it was down? Buffering is the difference between a gap and a hole.
3. How do I tell the difference between a quiet month and a month where the system was not watching? If there is no answer, you are paying for a service you cannot verify.
4. What happens to my equipment if your company stops existing? Sensors that only work against one vendor's servers become landfill on the day that vendor is acquired.
5. Where does the alert come from — the building, or your data center? Not a trick question. Just make them say it.

None of that requires you to know what an inference engine is. It requires you to be curious about which parts of the system are in the room with the machine you care about.

The Report That Answers Question Three

Question three is the one I have been failing.

My system knows when it has lost sight of the equipment — that is what the two timers are for. But knowing is not the same as saying, and until now the customer report has not carried that number. A month with no alerts and a month with a six-hour blind spot have looked identical on the page I hand over, which is precisely the thing I just told you to be suspicious of.

So that changes. Starting with this month's reports, the coverage number goes in: what percentage of the period the system actually had eyes on the equipment, every gap itemized with its duration and cause, and an explicit line about whether detection continued locally during the gap.

I expect the number to be boring, and boring is the point. A dull, honest 99.4% with two itemized network hiccups is what makes the rest of the report believable. It is also the only real evidence for everything I said above — anyone can claim their system works without the cloud. A coverage table showing a fifty-one minute outage during which the monitor never stopped watching is the claim with the receipt attached.

Ten Euros, Once

One last thing about TasmoShelf, which has nothing to do with architecture.

It is free for three devices, with nothing held back — not a crippled demo, the real product. Past three devices it costs €9.99 one time. That price is printed on the page.

I have been reading physical AI announcements every week for months. The enterprise products almost never publish a price. A wireless platform for robotics launched this week with no price. A sensor gateway last week, no price. BrainChip described its cost as a multiple of an unnamed alternative. All of that is normal and none of it is dishonest — those things are sold through a conversation with a procurement department, and the conversation is where the price gets decided.

Small buildings do not have procurement departments. They have an owner who wants to know what it costs before they spend an hour on a call. Which is why mine says $99 to $199 a month on the page, and why the ninety-day baseline you get at the end is yours whether or not you stay.

The guy who wrote the app understood his customer well enough to put a number where they could see it, and to make the free version genuinely useful right up until the point where you have a real installation. That is a better lesson than most of what I read this week, and it cost me nothing to learn because he published it.