August 2026

Backup and Restore to the Plans page

Your mowing plans are stored on the Yarbo itself. They are not in the Yarbo cloud, they are not in the robot's own map backups, and a firmware update wipes them, which is easy to miss: every schedule points at a plan by its number, so when a plan is gone the schedule still runs, tells the Yarbo to start a plan that is not there, and the Yarbo says nothing.

The Plans page now keeps copies on your own computer. One is taken automatically whenever Yardstick reads your plans, and you can save a named one whenever you like, before you accept a firmware update for instance. Named copies are kept; the automatic ones are a rolling window. Restore writes the missing plans back, each under the number it had, so your schedules keep working, and it leaves plans already on the robot alone. Everything is checked by reading the Yarbo back afterwards.

If plans do go missing you are told how many, and separately how many of them a schedule depends on. If there is no copy to restore from, it says so plainly.

Combine two zones into one

Yarbo has no way to merge two work areas, so a boundary you drew in the wrong place, or a strip you mapped separately and later wished was part of the lawn beside it, stays split for good. Now, in the map editor, select the zone you want to keep, press Combine, and click the zone to absorb into it. The two become one: the zone you kept holds on to its name and every one of its settings, and simply grows to cover both. The other one is gone.

The two have to touch along a shared edge, and it says plainly why when they do not: zones that do not meet at all, zones that meet at a single corner (the robot would have no width to drive through), and zones that touch in two separate places with a gap between them are all refused before anything is written. Corners a few centimeters apart still count as the same corner, which is usually what two zones drawn in separate sessions look like.

Everything that pointed at the absorbed zone is brought across with it: travel paths and patrol lines that ended there now end at the zone you kept, and any plan that mowed it now mows the combined zone instead, without listing it twice. A backup is taken on the robot before it starts, so it is one restore to undo, and the absorbed zone is not deleted until the enlarged outline has been read back off the robot and checked point for point.

0.9.111 was tagged but never published: the Windows CI build failed on a test added in that very release, and the notes moved to the next version rather than advertising a version nobody can install.

A dropped connection to your Yarbo account was left running

Yardstick keeps one connection to your Yarbo account for map editing and no-go zones. When that connection hiccups it makes a fresh one, and it was letting go of the old one without hanging up first, so the abandoned connection carried on trying to reconnect for as long as Yardstick ran. One was left behind every time the cloud went quiet for a moment. On one tester's machine 67 of the 92 running parts of Yardstick were these, three quarters of everything the program had going.

One bad GPS reading could redraw your whole map

The map is framed on the furthest north, south, east and west your robot has ever reported. That means a single impossible fix takes the frame with it: one reading claiming to be a fully locked-on position a kilometer away, one out of six hundred thousand, stretched a 95-meter property to 1,108 meters, and every map after that showed the yard squashed into a corner with no hint as to why. The frame now ignores fixes that are nowhere near the rest of your yard, keeps every one that is, and says in the log when it has ignored one. Long, thin properties are unaffected: real ground far from the middle is still real ground.

The aerial photo, the wall display and the map editor could disagree about where your yard is

They worked the frame out separately and did not all filter the same way, so the picture and the shapes drawn on it could be framed differently. They now ask the same question and get the same answer.

Correcting your recording did not correct your map

The coverage map is built up as it goes rather than redrawn from scratch each time, which is what keeps it quick on a big recording. But it only ever checked whether readings had been added, never whether older ones had changed. So if anything went back and altered your history, a bad reading removed, old sessions cleared out, the file compacted, the map carried on showing what it had already worked out, through restarts, with nothing to say why. It now notices and rebuilds itself.

A job that stopped for an unknown reason was sent back out, even after you stopped the robot yourself

When a job stops part way, Yardstick holds it and finishes it later. That was built for one situation, the robot goes home flat, charges, and carries on, but it was being applied to every stop, including ones nobody understands. A robot that stopped with a full battery was sent straight back to whatever had stopped it; and stopping the robot by hand looked, to Yardstick, exactly like a robot that was ready to go again, so it sent it out once more.

Now: a job is only picked up again when a flat battery explains why it was put down. Anything else says so and waits for you. And pressing stop, dock or pause anywhere in Yardstick cancels the held job outright, the program still runs at its next scheduled time, but nothing goes back out tonight because a timer said so.

Start, stop and restart Yardstick from a command

Everything else Yardstick does, it does through its own page, which is no help at all when it is not running and the page is not there to ask. A tester lost power, the machine came back up, Yardstick did not, and the only way he could think of to get it back was to reinstall. Now yardstick service start, stop, restart and status do it directly, on Windows, Mac and Linux, using whatever that machine actually uses to start Yardstick at boot. On Windows there is also a Restart Yardstick entry in the Start Menu, because somebody who cannot open the page is not going to be looking for a command line. status says which mechanism your machine uses and whether Yardstick is set to come back on its own, Windows starts before you log in, a Mac starts when you log in, and on Linux it depends how it was installed, so "why did it not come back after a power cut?" has a different answer on each.

A program set to run every few days did not say so

Its card in the Programs list showed seven weekday squares and a start time. A program that repeats on a cadence has no weekdays, so all seven sat unlit, which reads as "this never runs" when it is running every third day. The card now says how often it repeats.

A program set to all seven days was called "weekly"

In the upcoming list it now says daily, which is what seven lit day squares mean.

Every section on the Scheduler page folds away

The page had grown long enough to be a chore: on a real install the activity log alone was a quarter of it, and some panels are ones you set once a season. Click a section heading to fold it, and it stays folded next time. Everything starts open, Next run never folds, and a folded heading says what is inside it, so folding costs you the detail and never the fact: Quiet hours still shows its window, Weather rules still says a zone is closed right now.

A folded Activity log says how many problems are in it

Folding the log away used to leave a header showing the most recent thing that happened, which is only useful while the most recent thing is the problem. One ordinary run lands on top and the failure underneath it is gone. The folded heading now leads with the worst thing in the log rather than the newest, carries a count that stays true however many ordinary runs follow it, and turns the color the log itself would use. A log with nothing wrong in it reads as before.

On some Windows machines updates could never install, and said so in PowerShell

Yardstick installs an update by handing it to Windows as a background task. Creating that task needs administrator rights, which Yardstick has when it runs as the service the installer sets up, and does not have when it has been started by hand. On those machines every update since 0.9.98 failed, and what you got was four lines of raw PowerShell. Now: the update runs in a way Windows will allow and asks your permission on screen; if it still cannot, it says so in a sentence and points you at the installer; and the Settings page no longer offers to install updates on its own on a machine where that cannot work.

An automatic update that failed said nothing

It was recorded below the level anything is written at, so a machine that quietly stopped updating itself looked exactly like one that was up to date. Failures are now written to the log, and the daily check-in says whether this machine can install updates at all, so we can find the stuck ones instead of waiting to be told.

Yardstick could end up running in a way that could never update

Yardstick normally runs as a background service that starts with Windows. If that service went missing -- a security product removing it, a policy, a setup that did not finish -- opening Yardstick from its icon quietly started an ordinary copy instead. That copy worked: it recorded, drew maps and sent alerts, and gave no sign anything was wrong. It also could not install a single update, for as long as it ran. Opening Yardstick now puts the service back, asking your permission to do it, and if you say no it still runs but tells you plainly that it cannot update itself.

Yardstick tells you when your alerts have stopped arriving

Turning email or phone alerts on is not the same as them getting through, and until now nothing checked. An app password revoked by your mail provider, or a changed phone topic, meant alerts silently stopped: the Alerts page went on showing the switch turned on, because it was, and the first you knew was finding the robot stuck hours later. Pressing "Send a test" did not catch it, because that works -- you are standing there. Now, when a channel misses three real alerts in a row, it says so on your Yardstick home page, which is the one place that cannot fail to reach you, and the Alerts page says which channel is not arriving and why. It clears itself the moment an alert gets through again.

Every page was slow, and slowest on a small computer

Yardstick checks your license on every request a page makes, and a page makes about a dozen. That check re-read and re-verified a signed file each time. The verification is deliberately careful and it is not fast: a fifth of a second on a desktop, closer to two on a Raspberry Pi. So a single page could spend ten seconds or more doing nothing but proving to itself, over and over, that you had paid. On one tester's Pi it was using half the processor with nobody even looking at a page, and page loads took forty seconds.

The answer is now kept until the file itself changes, which is once a day at most. The signature is still checked in full every time it does, what is saved is the repetition, never the checking. On the machine this was found on it is the difference between two and a half seconds of work every five seconds, and none.

A warning when this computer cannot confirm your license

A licensed machine checks in with us periodically and carries on for a few days if it cannot. That few days used to pass in silence and then simply stop working. The License page now says how many days are left and what to check, and only once something is actually wrong.

With two cores, the one you picked did not stay picked

Choosing a core wrote it into the address bar and nowhere else, so going to Settings and coming back put you on whichever core sorts first, for an owner of a 2023 and a 2024, the older one. Every panel then described a robot you were not looking at, which is why "is there enough data yet" could say three days while Storage said thirteen. The choice is now remembered.

The Storage total says when it covers more than one core

It has always been the whole file while everything around it is one core, and on a two-core install that difference looked like a fault. It now says so, and only when you have more than one.

The address for a phone is the secure one, when you have it

If your box has its trusted certificate, that is the address you are already using and the only one that opens without a browser warning, so it is the one offered. Installs without it are unchanged.

Yardstick can install updates on its own

Off unless you turn it on, in Settings under Software and help. It follows the channel you pick, and it never interrupts a job: installing restarts the recorder, so it waits until the robot is not out working. Left off, you now get a small dismissible notice on the main page when a new version is out, instead of only finding out if you went looking.

A scheduled program could record a job as finished when it was half done, and then stop for the day

When the robot runs its battery down part way through a plan it suspends the job and drives home to charge. Yardstick read that as the plan finishing: it wrote "Finished" into the activity log, took a run time from it, and started the next plan in the chain at a robot that was already on its way to the dock. Six minutes later, having seen no mowing, it declared the program lost and stopped. On the run this was found on, half a driveway was uncut and the log said the program had run.

Yardstick now tells the two apart by how much ground was actually covered. A plan that stops short is recorded as suspended rather than finished, the program is held instead of abandoned, and once the robot has charged it carries on with the same plan from where it stopped rather than starting it again from the beginning. It still gives up when the robot genuinely cannot be accounted for, after six hours of waiting, or after four restarts of the same plan.

The trial-ended screen pointed at something that was not there

It said "everything below is on this computer", which reads as a pointer to a list that does not exist. The three figures under it are a summary of the recording, and the screen now says so plainly.

American spelling throughout

"License" rather than "licence", on every page, in every message and in the license agreement.

The main page could sit spinning for a minute after a restart

One panel -- the "how much of this can be believed yet" line -- was computed while the page waited for it, and computing it means reading every positioned sample in the recording. On a large recording on a Raspberry Pi that is most of a minute, and it happened at the worst possible moment: right after an update, when the page is reloaded precisely to see whether the update worked. The page now loads immediately and that line fills itself in when the reading is done. The same figures on the Settings page do the same, instead of showing an error if they were asked too early. And after deleting recordings, every panel now reports the post-deletion numbers immediately rather than quoting figures from before the deletion for up to ten minutes.

A reading from the robot could be lost while Yardstick was reclaiming disk space

Reclaiming space rewrites the database, and nothing else can write while that happens. Until now the recorder simply waited its turn. A change in the previous release stopped that wait blocking the rest of the program -- which was the point, because it used to freeze every page -- but it also meant the recorder stopped waiting at all: it tried to store a reading, found the database busy, and gave up on it. Seen once on a customer's Raspberry Pi, where reclaiming several gigabytes on an SD card takes minutes rather than seconds. It now waits, for as long as it takes. A reading arriving a few seconds late costs nothing; a reading thrown away cannot be recovered.

The update button went quiet instead of counting down

Installing an update used to show the seconds ticking by and then reload the page itself when the new version came up. That only ever happened on one of the ways Yardstick can update itself, so anyone on a packaged install pressed the button and then sat looking at a page that never changed, with no way to tell whether it had worked. Every kind of install now shows the same countdown and reloads itself when the new version answers.

With two robots, the page could show one machine's mowing over the other machine's aerial photo

When the address does not name a robot, Yardstick picks one for you, and it used to pick whichever had reported most recently. With two robots both running, that answer changed from second to second -- and a single page load asks the question nine separate times, once per panel. So one panel could resolve to one machine and the next to the other: refreshing showed the wrong robot, and the coverage grid was drawn over an aerial photo framed for somewhere else, which looked like the map had slipped out of register. On a browser with the old photo still cached it looked misaligned; on a fresh one the photo simply never appeared, because a new one was being fetched for a different patch of ground.

The robot is now chosen in a fixed order, so every panel on every load agrees. Picking a robot from the menu was always a reliable way round it, because that puts the choice in the address, and it still is.

Clearing out old messages stopped the recorder, froze every page, and sent an alert saying the robot had been lost

All of it was Yardstick getting in its own way. Deleting old messages was done in one enormous step that held the database for its whole duration, so nothing else could read or write; on a 7 GB recording on a Raspberry Pi that was minutes. Recording stopped for those minutes, every page hung rather than merely being slow, and the part of Yardstick that watches for a robot going quiet saw the gap it had just caused and messaged the owner at one in the morning about a machine that was sitting on its dock.

Old messages are now cleared a few thousand at a time, letting recording carry on in between. The alerting knows when Yardstick is busy with its own housekeeping and stays quiet about it. And the storage figures no longer repeat a number they know a clear-out has just made wrong, which is why somebody watched 1.6 GB come off their file while the page insisted nothing had changed.

Reclaiming the freed space still pauses recording briefly, and that part cannot be avoided: the database has to be rewritten and nothing else can touch it while that happens. It is now as short as it can be, and it no longer takes the whole interface down with it.

A new install now keeps the robot's original messages for 30 days rather than for ever

Yardstick stores the robot's raw messages alongside the readings it pulls out of them. Nothing you look at on any page comes from them; they exist so a reading we learn to interpret later can be filled into recordings already made. They are also about two thirds of the file, and until now a new install kept every one of them indefinitely, so the file grew without any bound and the owner only found out when the disk started hurting. One two-week-old install on a Raspberry Pi reached 7 GB that way.

If you already have Yardstick, nothing changes and nothing is deleted

Your setting stays exactly as it is, including "keep them all". Changing it would mean deleting your data because you had never picked a value, and that is not ours to decide. The storage page will now say how much of your file these are and suggest 30 days, next to the control that changes it, and the choice stays yours.

A machine updated through the rescue launcher slowly filled its disk

Installs healed by the 2026-08-28 rescue run a small launcher that fetches each new version, and it had no way to remove the version it replaced. On a Raspberry Pi with an SD card that is about 34 MB left behind per release, which surfaces months later as a disk with no room and looks like a new problem. Yardstick now clears out superseded copies when it starts, keeping the one it is running and the one before it, so there is still something to fall back on if a download ever fails.

Yardstick keeps the last few versions of your settings

The previous release closed the way a settings file could be lost -- an upgrade could write blanks over it and take the license key with them. That guard covers the cause we found; it cannot cover one we have not. So each time your settings are saved, the version being replaced is kept beside them as config.json.1, with the two before that as .2 and .3.

It is worth knowing what that file holds, because it is far more than the license: the seat this computer is registered on, your Yarbo sign-in, your Google Maps key, every schedule and its curfew, the smart no-go zones, mowing direction, your alert thresholds, the Home Assistant and weather settings, and the wall display. That is hours of setting up, and until now the only copy was the one being overwritten. If any of it ever goes missing, the previous version is sitting next to it and can simply be renamed back.

A settings file that is already damaged is never copied into the backups, since that would push the last good one out; and a backup that cannot be written for any reason is ignored rather than being allowed to stop you saving.

On a large recording, the battery page could take minutes to appear and slow the whole machine down with it

Three things compounded, and a Raspberry Pi install with a 7 GB recording on an SD card hit all three at once. Earlier in this release the battery panel was made to keep itself warm in the background, which fixed the four-and-a-half-second wait it used to have and introduced a worse problem on a big recording: it re-read every battery reading ever recorded, on a timer that did not wait for the previous read to finish, so on a recording big enough the reads piled up without limit and the box spent its whole life on them -- the battery page took five minutes, and everything else, down to the update check, crawled behind it. And the storage page summed the size of every archived message while holding the same lock the recorder writes under, so opening it stalled the recording too. Now the battery panel always answers instantly from the last computed history (a few minutes of staleness is invisible in a months-long chart), the recomputing happens in the background one at a time and paced by how long it actually takes, only the last month feeds the charts, and the storage page's census runs off to the side where it cannot block anything. Right after a restart the battery panel says it is reading the history rather than sitting empty.

A robot kept awake around the clock could quietly record sixteen gigabytes a month

Yardstick thins its recording to one sample every half minute while nothing is being mowed -- but two things could switch that thinning off entirely. A status field that never stops changing (a sensor dithering between two values) made every message look like an event, and a robot whose "working" flag stays on while it sits still -- a stale flag, a long stall, or a Home Assistant keep-awake policy holding it up all night -- was recorded at full rate for as long as it claimed to be busy. One install recorded 2.6 million samples in 13 days that way. A value that keeps flapping is now noise until it settles (its first change still lands immediately), and the full recording rate now requires the wheels to have actually moved in the last five minutes, not just a flag saying so. Real transitions -- faults, charging starting, work beginning -- are stored the moment they happen, exactly as before.

On installs healed by the bridge, the update button now takes the update instead of describing one

A healed install runs the same compiled build as everybody else, so it believed it was a system package: pressing install wrote a request for a root updater that does not exist there, told you it was installing in the background, and nothing happened until the machine next rebooted. The button now does the honest thing on those installs -- restarts Yardstick, which downloads and checks the new version on its way back up -- and the wording around it says that is what will happen. Every release from here on also publishes what those installs update from, as part of cutting the release rather than as something to remember.

The oldest Linux installs could not update at all, and are now brought onto the same footing as everybody else

Before Yardstick had a proper Linux package, it was installed from a source tarball. Those copies update by fetching a new tarball, and there is not one any more, so their update button stopped working and told them to download a file that answers "gone". Five installs were following that into a dead end.

Those copies now fetch the Linux package instead, check its checksum and its signature, and show the single command that installs it. That command is the whole job: the package itself now carries an older install's recording, settings and license over to where it keeps them, and stops the old service claiming the port. Nothing has to be copied by hand and nothing is deleted -- the original stays in place until you are satisfied.

It only does that onto a fresh install, never over an existing one, and it refuses rather than guessing if it finds two old installs on one machine. After it, the install is indistinguishable from one made from the package today, which is the point: there is one Linux Yardstick from here on, not a package one and a source one.

A scheduled mow was recorded as "a plan did not start" while the robot was out mowing it

Yardstick sent the start, waited two and a half minutes for the robot to begin, gave up, and wrote the run off. The robot began mowing forty seconds later and went on to finish the whole zone. Measured across 31 real starts, the mistake was asking one question where there are two: the robot takes the job almost instantly, releasing the charger within 14 seconds every single time, but it then has to wake up and work out its route before it moves, and that took anywhere from nothing to three and a half minutes. It is slowest exactly when a schedule needs it -- first thing in the morning, after a night on the dock -- which is the one case that never came up in testing. Yardstick now waits for the robot to come off the charger as its answer, then gives it as long as it needs to start mowing, and no longer prods a robot that is already on its way. Nothing is re-sent once the robot has answered.

A plan that was accepted and then never seen mowing used to start the next plan in the chain anyway

If Yardstick loses track of a job, the robot is somewhere out in the yard doing something, and firing a second job at it is the worst available guess. The chain now stops and says so.

The run times on the schedule page are measured from your robot's own recording instead of guessed

The bars used to start at a flat 22 minutes per area and only ever sharpen from runs Yardstick itself started and watched from beginning to end. Everything else taught it nothing: a plan you start from the Yarbo app, a run where the start was misread, and the entire history from before you built the schedule. On the machine this was written against it had learned 5 plans while the recording held finished runs for 10, going back three weeks.

It now reads the runs themselves, so every plan that has finished once has a real bar, whoever pressed go. It also separates what the time was spent on, because a single number would be a lie in both directions. One real run took ten hours: 5h 16m mowing, 1h 53m on the charger because that zone needs more than one battery, and 2h 54m stopped dead after it caught on something and waited for somebody to walk out and free it. The bar counts the mowing and the charging, since the robot is genuinely unavailable for both, and throws the stuck time away so one bad afternoon does not stretch every future bar. Plans that have not finished a run yet are still on the old guess, and the page now says which ones those are rather than showing a guess and a measurement the same way.

After entering your Google Maps key, the settings page went on saying you had not entered one

The key was saved correctly and was being used; the page simply could not see it, and kept showing the empty box until Yardstick was restarted. That was worth more than confusion: because the page believed there was no key, it would also refuse to switch the imagery to Google, so the only way through was to type the key in again every time. It now shows what is actually saved, and says so in the box the moment you save it rather than leaving you to guess.

While it is charging, a charge figure you can believe, and how long is left

The percentage your Yarbo reports climbs too slowly on the dock and then jumps: on the machine this was built from it read 60% at the moment the battery was physically full, then leapt 35 points to 100% a few minutes later. That is the battery's own gauge, not something Yardstick can correct at the source, so the battery panel now works it out from the pack voltage and the charging current instead, which do not have that fault. While it is on the dock you get roughly what the pack is really holding, roughly how long until it is full, and a plain Full the moment it actually is. The robot's own figure is still shown beside it. This appears only while charging: away from the dock the voltage moves about under load and the honest answer is that we do not know.

Motor and charger temperatures are now recorded

The blade motors and the charging coil report their own temperatures and run far hotter than the battery everyone watches. They are kept with everything else now, so a motor that starts running hotter than its neighbor has somewhere to show up.

Two alerts about charging

One for a machine that is on the dock and not actually taking charge -- whatever the cause, the result is that the next job starts late -- and one for a battery too hot to charge. Both explain in Settings exactly what makes them fire.

An upgrade could wipe your license key and settings

If the settings file could not be read at the moment Yardstick started, it carried on with blank settings and then saved them, writing the blanks over the real file. Everything in it went: the license key, the Yarbo sign-in, your robots and your alert settings. It needed nothing to be wrong with the file itself, only for something else to be holding it for a moment, which on Windows is ordinary behavior for antivirus and backup software and is most likely during an upgrade. Yardstick now waits and asks again rather than assuming the worst, and if it still cannot read the file it refuses to write over it, so nothing is lost and the file can be recovered. The same protection now covers the file that records which schedules have already run, where losing it could have sent the robot out a second time in a day. Most likely on Windows, where antivirus and backup software hold files briefly as a matter of course, but the same thing could happen on a Mac or a Linux box and it is fixed on all three. Reported by a beta tester who was right about something nobody else had seen.

The Yarbo account sign-in was filed under Map editing, and the page said map editing was the only thing that needed it

Two features need your Yarbo account, the map editor and scheduling, and the sign-in is the same one for both -- so it now lives in Your Yarbo, next to the robot it belongs to, rather than inside one of the features that happens to use it. Map editing points at it and explains what it is for. The sign-in prompts inside the map editor and the scheduler are unchanged: both still offer it the first time you open them, so nobody has to visit Settings first. Also stopped the sign-in screens offering to unlock a live camera, which the app no longer has.

It was too easy to leave the map editor without noticing you had unsaved changes

Save changes sits in the second row of a busy toolbar, while the way out sits in the bar along the top, so it was possible to make edits, press Back to map, and find out only from the browser's own warning that there was something to lose. A second Save changes now appears in the top bar, right beside Back to map, from the moment there is an unsaved edit until you have saved it, and it goes away again once you have. The original button has not moved: it is next to Undo and Redo, which is where your hand already is.

The Plans page had no way back to the map, and could tell you that you had no plans when it simply had not heard back yet

The navigation across the top offered the Controller, the Scheduler, the wall display and Settings, but nothing to return to the map -- and its leading arrow made it look like a back button when it was not. Reading your plans also asks the robot and waits up to twenty seconds for an answer, and while it waited the page sat empty; if the robot was asleep the wait ended with "No plans found. Build one in the Yarbo app first", which is exactly wrong when the plans are already there. It now says it is reading them while it waits, and if the robot cannot be reached it says so and offers to try again, rather than reporting an empty list it never received.

Minor bug fixes

Small corrections to wording on the settings pages, and to the update button on a Linux package install, which could sit at "downloading" without ever starting. Your recordings and settings are untouched; installing this version is all that is needed.

A safety notice on the controller

Driving the robot by hand moves a heavy machine with blades that may be running, so the controller now leads with a plain reminder to keep eyes on the robot the whole time, keep people, pets and obstacles clear, and be ready to press STOP -- and that you control it at your own risk.

The per-cell battery temperature bars now show the current reading, not a lifetime average

The six-cell bar graph plotted each cell's average over the entire recording, which barely moved as new readings arrived and read as if it were stuck. The temperatures were being read correctly the whole time; only the panel was showing the wrong number. The bars and the figures above them are now each cell's latest reading, so they move with the pack as it warms up working and settles on the dock. The sustained-imbalance warning underneath still uses the average, since a cell that runs hot over its whole life is the health signal that one is about.

The map could look cut off, with no way to see your whole property

Once an install has recorded some mowing, the map frames the mowed patch rather than the whole yard, so anything outside it -- a driveway not yet mowed on that machine -- clipped at the edge. The control that zooms back out to the whole property was built but never actually shown, so there was no way out of the clipped view. The "Whole property" button now appears whenever there is a yard to fit to.

The map editor could stay locked, saying Yarbo had a job in progress when it did not

A mow that stopped part way -- sent back to the dock before it finished -- left its progress numbers frozen at, say, "1% done", and the editor read those as a job still running and locked editing until some later job ran to completion. It now trusts those numbers only while they are still fresh, so a job that ended a while ago no longer holds the lock.

Mowing direction now learns each zone on its own, from the way it already mows

Until now, only zones that had been measured by hand would line up; a zone the software had never seen was left out, with no way for an owner to bring it in. Now every zone teaches itself. The first time the robot mows a zone on its normal schedule, Yardstick reads the stripe pattern the robot planned for it and works out that zone's direction from it, then keeps every following mow in line with the rest. Nothing is asked of you, and nothing changes about how the robot drives: this only watches the plan the robot already makes, and never sends it anywhere or starts a mow to measure. A zone that has not mowed yet shows "1st mow" on the direction card until it has, and falls into line on its own after that. Zones already mowing in a clear single direction are learned to within a couple of degrees; a zone with no consistent direction (an area still being set up, say) is left alone rather than pointed the wrong way.

Schedules and mowing direction now work per core

If your property has more than one Yarbo core, each one now keeps its own weekly schedule and its own mowing-direction setup, because two cores usually cover different parts of the yard and should not share a plan. Each core has its own master zone and its own heading, and the direction advances for each core on its own when that core mows its master zone. The curfew and the scheduling on/off switch stay property-wide, since those are about the whole yard. When you have two or more cores a small picker appears at the top of the Schedule page to choose which one you are looking at. If you have a single core, nothing looks or behaves any differently. Existing schedules and direction settings are carried over to the new per-core format automatically the first time you run this version, with no changes needed on your part.

Pressing "Check for updates" while an update was installing made the page contradict itself

Both were writing to the same line, so the messages overwrote each other and it looked as though something had gone wrong. Checking now waits until the install has reported, and says so.

Diagnostics now say how good your GPS is and whether the aerial photo can cover your map

When a map does not line up, that is almost always the answer, and the report used to say nothing at all about it, so working it out meant a long exchange of screenshots. It now shows how many positions were recorded at each fix quality, how much ground the map draws, how much the aerial photo covers, and says plainly when the photo cannot cover the map. Your coordinates are still left out: these are counts and distances in meters, which cannot be turned back into a location.

The settings page said the yard map could not be edited

That has not been true since the map editor arrived. It now says the map is read from your Yarbo and written back, that no-go zones and boundaries can be changed without opening the Yarbo app, and that a backup is taken before every save.

The mowing direction now advances when the master zone is mowed, not only when a whole plan finishes

The direction was stepped when a scheduled plan completed in full. But a plan can group the master zone with others, and if any of those did not finish, the plan never completed and the direction never moved, even though the master zone was mowed. On a property that has to be split across several days that was the normal case, so the rotation quietly stalled. It now steps the moment the master zone itself is mowed to completion, however the mow was started, and every other zone follows on its next run.

Restarting Yardstick while a job was running told you it had started again

Yardstick forgot which alerts it had already sent when it stopped, so coming back to a mow that was already underway looked like a brand new one and sent a second "Job started". Three arrived here in one afternoon for a single mow. It now remembers what it has already told you, so a restart says nothing about it. Anything that went wrong while it was stopped is still reported, and an alert you had already dismissed stays dismissed.

This mattered more than it looks: taking an update restarts Yardstick, so the update button made a false alert more likely rather than less. A reboot or a power cut did the same.

Yardstick runs on macOS

There is now a proper installer package, signed and notarized by Apple, so it installs by double-clicking it like any other Mac application and starts itself at login. It is for Apple silicon.

An install from a package can now take an update from inside Yardstick

Previously it found the new version, told you about it, and then printed a web address for you to copy out by hand, which is not an update path.

Download and install

now works on both a Mac and a Linux box installed from the package. Yardstick fetches the new package, checks it against its published checksum, checks it carries a valid Yardstick signature, and installs it. Your recordings and settings are kept.

On a Mac the system installer takes over and asks for your password, so you approve each install yourself. A Linux box usually has nobody at the keyboard, so it applies the update on its own, and will only ever apply a package signed with our own key. The part that does the installing ignores anything the rest of Yardstick tells it: it decides for itself which release service to ask and refuses a download hosted anywhere else, so a tampered-with settings file cannot point it somewhere bad.

When the secure address could not be set up, nothing said why

The setup happens in the background and it reported only its successes. If it failed, the log was silent about it, so the address never appeared and the only honest answer anybody could give was a guess. Failures are now recorded with the reason, once, along with whether it recovered. The status Yardstick reports to itself now also includes the secure address, whether the certificate is genuinely good, when it expires and what went wrong if anything did. The same applies to the address report that keeps the name pointing at the right machine after a router hands out a new one, which was equally silent and matters just as much.

A proper documentation set

Yardstick had a good user guide and a detailed changelog, and almost nothing an engineer could read. There are now three documents in docs/: an architecture overview of how the parts fit together and where data lives, an operations runbook covering health checks, the common failures and their fixes, backup and restore, and a reference listing every module, route, setting, telemetry column, table, alert and map layer. The reference is generated from the code and a test fails if it falls behind, so it cannot quietly go stale. All 96 settings now carry an explanation in the source as well, where previously 41 had none.

Zoom buttons on the map editor, and a Fit button

The map has always zoomed on the scroll wheel, which is only discoverable if you happen to try it and easy to miss on a trackpad. There are now +, − and

Fit

buttons at the bottom-right of the map, where every map you have ever used puts them. Fit returns you to the whole yard, framed the way it was when the map opened.

The Layers and Shapes list folds away

The arrow at the top of it hands 290 pixels back to the map. Because the toolbar wraps, that usually buys a row of toolbar as well, so the map gets taller as well as wider. Yardstick remembers which way you like it.

The help sheet had fallen behind the software

Ten controls had no mention in it, including per-zone Settings, Split, Delete shape, naming a shape and the Zone size buttons. All of them are now described, along with the Backups panel and what you can still do while editing is locked mid-job.

Alert emails were being filed as junk, and part of that was ours

When Yardstick connects to a mail server it has to introduce itself by name. Most Linux machines have a short name with no domain attached, and in that case the introduction fell back to an internal address that mail servers treat as suspicious. Microsoft was logging exactly that against our alerts on the way to scoring them as spam. Yardstick now works out a proper name automatically, and Settings has an optional field to set one by hand. If you sign in to your mail provider with a username and password, which is how Gmail and Outlook.com work, none of this affects you and the field can stay blank. It only matters when sending with no username, straight to your own company mail server.

Schedules can now repeat every so many days, the way a sprinkler timer does

Until now a program ran on the weekdays you ticked, which is the wrong shape for "mow the front every three days". A program can now repeat on an interval instead: pick how often and the date to start from, and it runs on that cadence. It is counted from the start date rather than from the last mow, so a run the weather or quiet hours prevents is missed rather than moved and the rhythm never drifts.

A schedule that cannot work is refused rather than saved

Yarbo mows one job at a time and does not queue, so two programs overlapping means one of them silently does not run. Saving a program now checks it against everything else for the next four months, and if they will collide the save is refused with the date they clash, both start times and how long each runs. The point is the clash you cannot work out in your head: a program every 2 days against one on Sundays looks fine all week and collides every fourteenth day. Choosing an interval when you already have weekday programs also now says, in the editor, that mixing the two is not recommended unless the times have been planned.

When two programs want the same minute, the interval one goes

Something has to win, and it used to be whichever was created first, which is not a rule anyone could predict. A weekday program comes round again on a known day next week; an interval is a rhythm, and dropping one shifts everything you set up. Between two intervals the rarer one wins, being the costlier to lose.

When two programs wanted the robot at once, one just did not run and nothing said so

Yardstick runs one program at a time and does not queue, so a program that comes due while another is still out is skipped for that day. That part is unchanged and is the safe behavior. What was wrong is that it happened in silence: you saw one program run, the other not, and there was nothing anywhere to tell you why. The activity log now says it plainly, naming both programs, the same way it already tells you when a run was missed because the robot was offline. Coming up flags the clash in advance too, so you can move a start time before it costs you a mow.

A Coming up list, showing the actual dates

The week planner is seven weekday rows, which suits a weekly program and cannot show a three-day cadence, since that lands on different weekdays each week. Underneath it there is now a plain list of the next eight runs in order, with their dates, what each one will mow, and how often it repeats. Interval runs also appear in the week grid, drawn as an outline rather than a solid bar, because they happen to fall on that day rather than every week.

Yardstick can now tidy up after itself, and you choose how

It records continuously, so the file only ever grew: 1.5 GB in seventeen days on the machine this was measured on, about 31 GB a year, with nothing to stop it. Settings now has a Storage section that offers this two ways, and explains what each one costs.

Automatically, with two separate windows, because there are two very different things in there. Delete recordings older than is your history: the maps, the coverage figures and the trouble spots. It is the one setting that actually puts a ceiling on the size of the file. Keep original messages for is the robot's raw messages, which you never see; they exist only so a later version can fill a newly understood reading into recordings you already have. They are two thirds of the file, which makes them the safer of the two to shorten. Both offer 30, 60, 90, 180 or 365 days.

Both start switched off, and nothing is deleted unless you choose it

, the invisible half included. The Storage page shows you what the recording is costing per month instead, so the decision is in front of you rather than made for you.

Turning one on works on what you already have, and starts straight away

Most people who switch this on will have been recording for months and are doing it to get the disk back, so a window applies to the recordings already on the machine, not just to new ones: choose 90 days on a machine holding a year and the older nine months go. It runs the moment you save rather than waiting for the next scheduled check, the file is rebuilt so the space actually returns to your drive, and the size on the page updates as it happens.

Or manually, whenever you like, with the one-off clear-out that shows you exactly what it will remove before anything goes.

Fixed along the way: the retention setting used to do nothing at all

It could be set and it was printed in the diagnostics report, and no code anywhere read it. Anyone who set it got the same unbounded growth as anyone who did not.

The start-up message no longer promises a padlock it has not checked for

It announced "trusted certificate, no browser warning" and printed the secure address whenever the feature was switched on, whether or not a certificate had ever arrived. A machine whose certificate had not come through was therefore telling its owner to use an address that could not work. It now says whether the certificate is in place, and while it is still being set up it says so and points at the plain address.

The mowing direction now steers by compass on any property, with nothing to configure

Converting between the robot's map and a true compass bearing turned out to be a reflection, not a rotation, which we proved from recordings already on disk: every planned route ever stored was paired with the GPS track that actually drove it, 14 clean sessions covering the whole range of angles, and the reflection fit every one to within a couple of degrees. The old formula carried a site constant that happened to be right at the one heading it had been checked at, so every mow to date came out correct and still does; the headings it steps to next would have drifted from the label. The constant is gone, the site needs no calibration, and this works the same on every property.

The explanation under each map layer is laid out rather than piled up

Picking a layer, Link to home base or RTK quality or any of the others, used to drop the whole explanation into one paragraph in a narrow column, so the layers with the most to say were the ones that read as a wall of text, and the part you actually wanted sat somewhere in the middle of it. Every word is still there. What is new is that each part is where you would look for it: the layer's name and its unit at the top, a sentence saying what it is, the measured figures laid out as figures, and then "How to read it" and "Worth knowing" side by side. Anything specific to your own recording, like how many squares were drawn, is now separated from the explanation of the layer itself, since one changes with your data and the other never does.

The table remembers whether you had it open

Health and battery both remembered; the table did not, so it closed itself on every load. It still starts closed on a first visit, because it is the raw rows rather than a summary anyone is looking for, but opening it now sticks.

The battery panel now opens by itself the first time you visit

It had been starting collapsed, which does not look like a closed panel, it looks like the battery figures are missing. This is what made the stats appear to vanish on the secure address: a new address is a first visit as far as your browser is concerned.

"Missed grass" was showing you the grass it did not miss

The covered part of the planned route was drawn boldly enough that, at any normal zoom, the stripes merged into one solid shape covering the whole area you had mowed. Press a button called Missed grass and get a large colored shape, and the shape is what you read as the answer. Covered route is now drawn faint, because it is context, and only the genuinely missed stretches are drawn in red, now with a light casing so a short miss is still findable against grass or gravel.

A missed stretch could be painted over by the covered stretch beside it

The two were drawn in the order the route ran, so wherever a missed segment was followed by a covered one close by, the covered line drew straight over it and the miss disappeared from the map, while still being counted in the figures underneath. Everything covered is now drawn first and the missed stretches go on top, so a miss can never be hidden by its neighbors.

The battery panel no longer tells you why your battery changed

It had been comparing your recent runs against your earliest ones and offering an explanation, aging pack included. That comparison moves with the weather, how heavy the grass is and how long each session ran, and we account for none of those, so it was a verdict the numbers could not support. The measurements stay and the diagnosis is gone.

Switching to the secure address no longer resets how you had things set up

Browsers keep preferences separately for each address, so moving from your machine's plain address to its secure one started you over: your theme, your units, your temperature scale, whichever panels you had open and every notice you had dismissed. Since we are the ones suggesting the move, the switch now brings all of that with you. Anything you have already set on the secure address is left alone.

How long your Yarbo actually runs on a charge

The battery panel now lists every run on battery: the charge it started and ended on, how much it used, how long it was cutting, and how much battery that cost per hour. Yarbo quotes 120 minutes of runtime for the Pro mower; the first property this was run against works out at closer to four hours of cutting on a full charge. A tester asked whether the data was in there. It was, in every recording already made, so this needed nothing new logged and your existing history fills it in immediately.

The figure is measured against cutting time rather than the clock, and that distinction is the whole feature. A session can span a whole afternoon while the blades turn for a fraction of it, so elapsed time flatters the number badly: one real run looked like six hours and forty-seven minutes and was a hundred and seventeen minutes of cutting. Both are in the table so you can see the difference. Runs with only a few minutes of blade time show no rate at all, because dividing a small drop by a small number produces confident nonsense.

You do not need to run the battery flat to get value from it. The rate comes out of any run with a quarter hour of cutting behind it, so ordinary mows count. The panel also says whether that rate is drifting, which is the thing worth watching: a pack using half again as much per hour as it did two weeks ago is telling you something, whether that is the weather, the grass, or the battery.

The secure address is no longer offered where it cannot work

The banner offering to switch you to the padlock address appeared whenever a certificate existed, without checking that the device you were using could actually reach it. Some routers refuse to look up an internet address that points back into your own home network, so people whose Yardstick was working perfectly followed the offer and landed on "server not found". The banner now quietly checks first from your own browser, and only appears when it will work. Settings tells you either way: it confirms the address works from the device you are on, or explains that your router is blocking it and how to allow it. There is a full write-up at yardstickhome.com/support/secure-address/, including the plain statement that the secure address is optional and that reaching Yardstick by localhost or by its address on your network is a perfectly good way to run it.

The secure address did not come up on some installs

A box publishes the address its certificate is issued for, and that report was being given thirty seconds to complete when it genuinely needs about a minute. When it ran out of time the box quietly never got its name published, so the secure page showed a certificate warning and there was nothing the owner could do about it. It now waits long enough. If your secure address was not working, it will sort itself out within a few minutes of updating.

Snow and sidewalk area settings showed the wrong values

Opening a snow area's settings read them through the leaf blower's command, which answers with a different but entirely plausible set of numbers, so what you saw was quietly not what the robot was using. Sidewalks had the same problem in a different form: read as an ordinary area, the robot returned a full, believable payload that ignored which sidewalk you asked for and disagreed with the Yarbo app. Both now use the commands that actually belong to them, so snow shows heavy-snow mode, roller speed and chute angles, and a sidewalk shows its real turning mode.

The wall map's completion ring closed at 75%

A bug in the ring's arc math drew every arc a third longer than the real progress, so the ring around a robot's dot wrapped fully closed when the job was only three quarters done, while the percentage in the strip beside it was right all along. The ring now agrees with the number. Caught by a beta tester who was checking the ring against his own completion tracking.

Draw which way the snow goes

Snow and leaf areas now take a throwing direction: pick the tool, click along the line you want the material thrown, and double-click to finish. It is drawn right on the aerial photo of your yard, on the area or pathway it belongs to, so aiming a chute away from the house or the flower bed is something you can see rather than something you guess at in a settings field.

Obstacle avoidance is settable per area

The robot's real-time obstacle detection (still beta on Yarbo's side) can now be turned on or off for each area from the map editor, instead of being all or nothing.

Reshape a boundary point by point

You can now add a point to a shape or remove one, rather than only dragging the points that were already there. A boundary that needs one more corner no longer means redrawing the zone.

One mowing direction for the whole property

Yarbo turns its mowing pattern a few degrees each time so the grass is not pressed down the same way twice, but it does that separately for every area and each one keeps its own count, so over a season the zones drift apart and you can see the seam wherever two of them meet. On the machine here, sixteen areas had settled at six different headings. Yardstick now holds a single direction and writes it to every area you choose before the robot goes out, so the lines carry straight across the yard instead of stopping at each boundary. Pick the area everything else follows, and pick how far to turn after each completed run (10, 15, 20, 30 or 45 degrees, or never); the whole property steps round together and stays in line. It is re-applied before every run, so an area the robot nudges is put back, and one click restores the angles you started with. In the scheduler, under Mowing direction.

The week-ahead timeline now shows how long each run takes

The scheduler's week view used to mark only when a run starts. It now draws each run as a bar from its start to its projected finish, so you can see the whole day's shape at a glance, where two programs overlap (shown in amber) and where a run would cross into quiet hours and be sent home early. Yardstick learns each program's real run time as it watches it run, so the bars start as an estimate from the areas covered and sharpen with every mow.

A one-command install for Debian, Ubuntu and the Raspberry Pi

Yardstick now ships as a system package (a .deb) for 64-bit Debian and Ubuntu and for the Raspberry Pi, alongside the Windows installer and the from-source script. sudo apt install puts it on with no Python to set up first; it runs as a background service that starts with the machine and keeps its recordings in one place, and sudo apt remove takes it off again. The package is built to run on every current release of those systems, so the same download works on an older Pi and a new mini-PC alike. A packaged install updates through apt, and the update panel now shows the exact command instead of the from-source steps.

A permanent secure address, so the secure page no longer warns

The secure page used to greet you with the browser's "your connection is not private" screen, because the certificate was self-signed. Now each box gets its own real, trusted certificate at a permanent <your-box>.box.yardstickhome.com address that resolves to it on your own network, so the secure page (and the live camera, which needs it) opens with a padlock and no warning, from your phone or any computer on the LAN. The address is fixed: it stays the same even when the computer's IP address changes, so a bookmark to it never breaks. You will find it in Settings, ready to copy and share to a phone, and if you open the box by its raw IP a banner offers to switch you to it. It is on by default and self-maintaining; if the box is offline it quietly falls back to the self-signed certificate, so HTTPS always comes up. The secure port is now settable in Settings too, in case another program on the machine already uses it.

Starting a plan took two presses

Pressing Start on the Plans page asked the robot to hand over control and waited for it to confirm before sending the start, but a robot sitting on the dock is slow to confirm, so the first press timed out with a "did not hand over control" message and only the second press actually started it. Starting a plan does not need that confirmation, so it now goes on the first press, with a "Starting…" message while the robot wakes off the dock. This also fixes the same two-press problem for scheduled starts.

The wall display called a docked robot "mowing."

A robot sitting on the dock charging could read as "mowing" on the fleet map, because one of the signals it reports while docked was not being counted as charging. It now reads as charging, or idle, when it is home.

The wall display flashed the stats view when it was turned off

With the machine-stats view switched off, the wall briefly showed it on first load before settling to the map. It now goes straight to the map and stays there.

A Scheduler

A new page that runs the plans you built in the Yarbo app on a weekly clock. Pick the days and the start time, chain several areas to run back to back, and set quiet hours the robot will never cross, when quiet hours begin while it is out working, it returns to the dock and stays put, overriding everything. Turning scheduling on switches your Yarbo app's own schedules off first, so only one thing is ever in charge of the robot. Schedules run only while the computer running Yardstick is on and connected, and this is not a substitute for Yarbo's own safety systems.

Schedule no-go zones by time of day

In the Scheduler, close off a no-go zone on a weekly window, a driveway while the car is out, a play area on weekends, and it opens itself again outside those hours. It flips the zone the robot already has; it does not redraw your map.

Close a no-go zone automatically after it rains

With a weather station connected, a low corner that gets too soft to work can close itself once rainfall passes a threshold you set, and reopen after a set number of days to dry out. You get a notification when rain closes a zone and when it reopens.

Live stats on the wall map

Each robot on the fleet-map view now carries a completion ring around its dot and a label with the stats you pick, battery, speed, time left, current area, blade RPM, satellites, and GPS signal percentage. Choose which to show, and the text size, in Settings under Wall display. The completion ring is always drawn; everything else is your choice.

A light theme, chosen once for the whole app

A Dark/Light toggle on the home page and in Settings now applies across every page, rather than each page deciding on its own. The default stays dark, and the wall display stays dark.

Notification emails now match the rest of Yardstick

Alert emails go out in the same branded layout as your license email, with the severity marked, instead of plain text.

Resize a no-go zone by a fixed amount, and see its real size

Select a zone in the map editor and it shows its true area and footprint, 477 ft², 22 × 22 ft, in your units. Two buttons then grow or shrink the whole outline by one inch at a time (one centimeter in metric), pushing every edge out or in by the same distance regardless of the shape, so a lopsided zone stays its own shape rather than being stretched from the middle. Nothing reaches the robot until you Save.

Sign in to Yarbo where you need it

The Scheduler and the map editor now show a sign-in panel in place when you are signed out, instead of sending you to Settings and back.

The map could rule straight lines across ground the robot never drove

To draw your yard the map simplifies the recorded track, and it did so by keeping every Nth point regardless of shape, so on a dense recording a run of dropped points could span a curve the robot drove around (a wooded island, a flower bed) and the line was ruled straight across it. On a machine with a long history, or two robots, the map filled with these phantom lines through places the robot never went. It now keeps the points that hold the path's real shape, so the line follows where the robot actually drove and never crosses ground it went around.

A freshly activated computer briefly showed as not licensed

After pasting a key on a new machine there was a short window, while it registered its seat and refreshed the license list, when the license card could flash "not licensed" before settling to Active. It now shows "Checking…" and settles straight to Active, with no scare.

"Release this computer" did not stick, and was missing on some machines

Releasing a license from the machine using it was undone seconds later, because a background task re-claimed the seat, so it never actually freed for another computer. A deliberate release now sticks (this machine keeps recording but stops holding the seat, so another can take it), and the "Release this computer" button shows on any licensed machine instead of waiting for the published list to catch up.

Set how long the robot has to be in trouble before each alert fires

The time-based alerts, cannot get back to the dock, stopped in the yard, robot stuck, left sitting out, GPS fix lost, can now be tuned on the Alerts page, so you decide whether to hear about it sooner or only after longer. The "cannot get back to the dock" default is now six minutes, since a Yarbo's homeward leg genuinely wanders before it settles.

Swapping a module set off a false "new firmware" alert

Taking the mower off and clipping the blower on, or putting the mower back, reported the attachment's own version as if the robot had updated its firmware, because the attachment was compared against whatever module happened to be on last. Each module's firmware is now remembered on its own, so only a genuine change to the module currently attached is reported. The alert names which firmware changed, and the first time a module is ever seen it says so, so a first attach is not mistaken for an update.

The map editor's area settings always showed the mower's controls

With the leaf blower or SAM attached, opening an area's settings still showed mowing options that did not apply to it. The settings now match the attached module, the mower, leaf blower, and SAM each get their own screen mirroring the Yarbo app, and a picker lets you edit any module's settings for an area whatever is physically on the robot, which the app itself cannot do. Going through them, the mowing height and obstacle-avoidance values were re-checked against the robot and corrected, and the mower gained the Boundary Obstacle Avoidance, Target Height, and Range/Step Offset controls it had been missing.

The wall board read "robots" with only one robot

The full-screen fleet board titled itself "Where your robots are" no matter how many machines an install had. It now reads "Where your robot is" for a single robot and keeps the plural only when there are two or more.

A confirmation when you send the robot to the dock

The controller's Send to dock button gave no sign the command had gone through, so on a slow start it looked as though nothing had happened. It now shows a brief confirmation, the command was sent and Yarbo will head back to the dock shortly, then clears itself, the same way the map editor shows a command being planned.

Clearer wording when the robot will not hand over control

Starting a plan while the Yarbo app still holds the robot now tells you to check whether the app is open, close it if so, and try once more, rather than flatly telling you to close it.

The fleet map on the wall could put the robots in the wrong place

The map drew each robot's dot against a slightly looser area than the aerial photo underneath it, so on an install with a few stray, non-fixed GPS positions the dots slid off the photo. For one tester with two machines it put both, docked by the house, out in the back woods. The dots now use the exact same area as the photo, so they land where the robots actually are.

The driven path could be ruled straight across the yard, through the woods

The line tracing where the robot has driven joined every recorded point end to end, so each time the robot jumped in the data, docking, crossing from one zone to another, or a momentary GPS glitch, a straight line was drawn across whatever lay between, including trees the machine never touched. A tester with several zones saw the map criss-crossed with impossible lines, most visibly after rebuilding measurements (which only re-draws the map; it does not change a single recorded position). The path is now split into separate strokes at those jumps, so it shows only ground the robot actually covered.

"Compact the database" now tells you what it did

It only ever reported the new file size, so on a database that was already tidy it looked like nothing happened. It now says how much space it reclaimed and how many stored routes it slimmed, or "already compact, nothing to reclaim" when there is genuinely nothing left to do.

Area labels in the map editor

Each work area can now be tagged with the attachment it is for, Snow Blower, Blower, Lawn Mower, or SAM, the same labels the Yarbo app keeps under Area Settings. Open a work area's settings and they sit just under Path offset; tap each to turn it on or off. They save straight to the robot and show up in the app, and every area's labels appear as small tags in the editor's list so you can see at a glance what each one is for. A tester noticed these were the one thing the editor could not yet do.

A Reconnect button for a core that has gone quiet

When a robot is reachable but its feed has fallen silent at the same address, the automatic recovery, which only goes looking when a robot moves to a new address, cannot help. The core's card now offers a Reconnect button in that state that drops the connection and re-opens it, without restarting anything else.

Watch your whole fleet on the wall

The wall display has a new map view: your property from above with a live dot for each robot as it works, whether you run one machine or several. Under Settings, Wall display, you choose which views the screen rotates through, the machine stats, the map, or both.

What the robot claimed against what it actually did

A new Missed grass view on the map colors the planned route green where the robot really drove it and red where it never came within a mower's width, and it tells you how much of the route was missed. It is exactly the gap between the job the robot reported and the ground it covered.

A heads up when the firmware changes

Yarbo runs several firmwares, system, body, attachment, chassis and Bluetooth, and updates them on its own. Yardstick now tells you the moment any of them changes, through the screen, your phone or email, with a switch for it in Settings, Alerts. A firmware change is also the most likely thing to alter how the robot reports itself, so it is worth knowing the day it happens.

Two more map layers, blade RPM and machine temperature

Both were already recorded; now you can color the yard by either. Temperature follows the same Fahrenheit or Celsius choice as the rest of the page.

Weather saved alongside the job

With a WeatherFlow Tempest station connected, its conditions are now recorded about once a minute, so the weather can be lined up against what the robot did rather than only shown live.

Resize a zone in the map editor without bending it

Hold Shift while dragging a corner and the whole shape scales about its center, so a square stays square. There is a reminder of it in the editor's help.

Every on and off control looks the same now

The settings pages and the map editor mixed plain checkboxes with toggle switches. They are all toggle switches now.

Dismissing a home-page alert now removes it

Pressing Dismiss used to leave the alert sitting there, dimmed and labeled "Dismissed." It now disappears.

The home-page date filter lines up

The From and To date boxes and the Apply button were shorter than the preset buttons next to them and sat low in the row; they are now the same height and aligned. The Sync map button also moved to the end of the toolbar, just after Fit.

Important notices from Yardstick

In a genuine emergency (say a Yarbo firmware update that breaks Yardstick's link to the Core), we can now show a short notice on the home page so you are not left guessing. It appears only when we raise one, you dismiss it once and it is gone, and an install nobody is looking at never contacts us for it.

Send your logs to us with one button

Settings now has "Send diagnostics to Yardstick" with a single field for your email or a ticket number. It gathers the diagnostics report and the full log and ships them to us directly, no terminal, no email client, no copy-and-paste, and hands back a reference code to quote when you reply. The copy, save, and email options are still there for anyone who prefers them.

Unexpected web-page errors now reach the log

An error inside a page or data request used to print to a place that goes nowhere on a headless Windows install, so a real bug could leave no trace. Those now land in the log file (and therefore in the diagnostics report), while ordinary browser disconnects stay out of it.

Tempest weather on the home page

The same WeatherFlow Tempest reading the wall display shows now sits in the top-right of the command center, right under the menu buttons. It only appears when a station is set up, and hides itself if the station goes quiet.

The "updated itself" notice can be dismissed

The banner that appears after an automatic update now has a dismiss button, and stays gone for that version instead of returning on every load. A later update shows it again.

The map's boundary layer is now called "Geofence."

It was labeled "Electronic fence"; "Geofence" is clearer and matches what the Yarbo app calls it. Same layer, same behavior.

The map editor now matches the rest of the app

It picked up the same polished glass look as the home and settings pages: gold accent, translucent panels floating over the map, soft shadows, pill buttons, and a

Light theme

that follows the same toggle (and remembers it across both pages). Every tool and control is unchanged.

A clear loading state in the map editor

Opening it used to show a blank canvas with a small "Loading" line in the corner, which read as broken. It now shows a centered spinner and "Loading your map…" until the map draws.

An unsaved-changes dot and an expandable backups panel

A red dot on the Save button means you have edits not yet sent to the robot. The backups panel can be widened (the « button) to read full backup names instead of them truncating. A new ? button opens a shortcuts-and-tips panel, and the sidebar gained per-layer counts and section dividers.

Signing in to the map editor failed on every installed build

The Yarbo SDK keeps its device definitions as data files (devices/*.json), scanned at start-up to build its device registry. The Windows and packaged builds bundled the SDK's code but not those data files, so the registry came up empty and every sign-in died with "Sign in failed: unknown device type: yarbo_Y". It worked only when running from source, which is why it slipped through. The build now bundles the SDK's data files. Reported by Alan S.

The map editor tab shows the Yardstick icon

It was falling back to the browser's generic globe; it now uses the same icon as every other page.

The command-center map re-syncs after a map edit

Saving a change in the map editor now re-fetches the yard map from the robot shortly afterward, so the home page reflects the edit on its own. Before this the startup fetch ran only once, so an edit never reached the home page until a reinstall.

A Fahrenheit toggle for the battery panel

A "Temp: °F" button beside the units toggle switches the cell temperatures and the cell spread between Fahrenheit and Celsius, and remembers the choice. Fahrenheit by default.

A "Sync map" button on the command center

It pulls the robot's current yard map on demand and redraws in place. Use it to bring in a change you made in the Yarbo app, or to re-ask when the robot was asleep the last time the map refreshed. It follows the core you are viewing on a multi-robot account.

The geofence layer starts hidden in the map editor

The geofence is a yard-sized boundary that covers everything inside it, so with it shown it was easy to grab the geofence by accident when reaching for a zone within it. It now starts unchecked in the editor's Layers panel; turn it on whenever you want to see or edit it.

A Pan tool in the map editor

A Pan button, or holding the Space bar, lets you drag the map around to reposition your view without any chance of nudging a zone by accident. Scroll to zoom as before.

Point snapping in the map editor

Dragging a corner now snaps it onto a nearby point, or into line with another point's position with a guide line, so straightening an edge or closing a gap is exact rather than done by eye. Hold Alt to place a point freely. The point markers are cleaner and sized right, too.

The map editor now works on a normal install

Signing in to your Yarbo account for map editing failed on installed copies with a "module not found" error, because the piece it needs to talk to Yarbo was left out of the build. It is now included, so map editing works on any install.

Faster: the map opens quickly after a restart, even on a large recording

The coverage grid is now saved to disk, so restarting Yardstick (an update, a reboot) reloads it instead of rebuilding it from the whole history. On a big recording that turns a minutes-long first load into a few seconds. The map itself is unchanged, and if the saved grid is ever missing or unreadable it simply rebuilds.

Pages no longer crawl when the robot is recording constantly

On a busy setup, more than one robot, or a robot kept awake so it never stops sending, the map and other pages could take minutes to load, because reading the recording had to wait its turn behind the constant writing. Reads now run alongside the recording instead of queuing behind it, so pages stay fast no matter how much the robot is sending. Nothing about what is recorded changes.

The map editor no longer shows the Auto-explore area setting

It exposed a Yarbo option that nobody, us included, can explain, so it has been removed from the area settings rather than left as a switch with no known effect.

The map editor works when you run more than one robot

If your account has more than one core, the editor now shows a picker at the top for which robot's map you are editing, and everything follows that choice: the geometry, the area and pathway settings, the backups, and the satellite layer. With a single robot nothing changes and no picker appears. Before this the editor always opened the first robot's map with no way to switch.

Edit your yard map from Yardstick

Yardstick can now open your Yarbo map and change it, the same map the robot mows. It stays off until you turn it on: under Settings, a new Map editing tab asks you to sign in with your Yarbo account and opt in, and an Edit map link appears once you have. From there you can draw and reshape no-go zones, work areas, travel paths and no-vision zones. Start a new zone as a square or a circle, drag its corners or the whole shape, split one zone into two, rename it, and turn any no-go or no-vision zone on or off. Each area, pathway and no-vision zone carries the same settings you see in the Yarbo app, mowing speed and height, route pattern, turning mode, obstacle avoidance and the rest, read from your robot and written straight back to it. A satellite photo of your yard sits under the map as a layer you can toggle.

Nothing reaches the robot until you press Save, and Yardstick takes a backup first, every time. A Backups panel lets you name, restore and delete those snapshots, and restoring puts the map back exactly as it was. Undo and redo cover your edits in between. Editing works through your Yarbo account, so it behaves the same whether you are standing at the robot or away from home.

The map shows trouble spots by default

The numbered pins that mark where the robot keeps struggling used to stay hidden until you switched them on. They are the first thing worth seeing, so they now show from the start, and the Trouble button turns them off if you would rather look at plain coverage. If you had already set that switch either way on a device, your choice is kept.

Faster: the map opens in a moment, even after months of recording

On an install with a long history the map page had grown slow, because every single load re-read and re-projected the whole position history from scratch. On this recording box, with about 388,000 positioned samples, that was over four seconds each time. Yardstick now keeps a running coverage grid and adds only the samples recorded since it last drew the map, so the first load after a restart still does the full pass but every load after it lands in about a tenth of a second. The map itself is unchanged, down to the cell: same coverage, same counts, same track.

Multi-core maps no longer try to blend your cores into one

If you run more than one Yarbo through a single Yardstick, the map now always shows one core at a time, and the picker simply switches between them. The old "All cores" choice tried to draw both machines on one map, which only made sense if they mowed the same ground and otherwise produced a smeared map with the satellite photo out of place. Adding a second core still just works: it starts recording the moment you add it and joins the picker once it has data.

Weather on the wall display

Point Yardstick at your own WeatherFlow Tempest station, under Settings then Weather, and the wall shows live conditions: temperature, feels-like, humidity, wind, UV and rain, updated about once a minute, in Fahrenheit or Celsius. It reads straight from your station on your own network, with no account of ours in the middle. The Weather tab links you to where WeatherFlow hands out a station id and a read-only token, and a Test button confirms they work before you save.

Home Assistant

Yardstick now speaks to Home Assistant over your own network, with no cloud in the middle. Point Home Assistant at this install and your Yarbo shows up as a device: its state, battery, position, blades and the rest as sensors you can read, and, once you turn manual control on in Settings, a mower you can drive, dock, start a plan on, and control from a dashboard or an automation. Settings has a new Home Assistant tab with a one-click "Add to Home Assistant" button and the address to paste in.

A license agreement on first launch

The first time you open Yardstick it now shows the End-User License Agreement and asks you to accept it before going further; existing installs see it once on this update. It does not change what Yardstick does or what it records, it is the plain statement of the terms you are already running it under.

A minor map fix

A small correction to how the map is drawn. Nothing about recording or your data has changed.

The Windows installer is now signed by North Lakes Consulting, LLC

Every earlier version was unsigned, so Windows called it out as coming from an unknown publisher and SmartScreen warned twice on the way in. With our signing identity now validated by Microsoft, the installer carries a real signature: the publisher shows by name, and those warnings ease as the signed builds earn reputation. The software itself is unchanged. (0.7.25 and 0.7.26 were tagged on the way here, but their builds could not write the signature over the binary while a smoke-test process still held it open, so neither shipped. This is the first signed release.)

The core names were invisible in the picker until you hovered them

On the dark map the Core dropdown drew its list as white text on a white background, so the names only showed when the mouse passed over each one. The options now carry a solid dark background, on both the map's Core picker and the core list on the plan-launch page.

A stray GPS reading drew long "shooting stars" across the map

Every so often the Core reports a position hundreds of feet from where it actually is. That point was plotted off in empty space, the trail drew a line out to it and back, and it dragged the whole map with it and shrank the real yard. Those jumps are now dropped before the map is drawn, so the trail stays on your property. The raw readings are untouched in the database, and a reading that was really valid still counts.

The daily check-in can now be switched off

It is still on by default (it is how we catch a firmware update that needs a change in Yardstick, and it only ever sends the anonymized fields shown on the settings page), but there is now a toggle to turn it off. Off means off: nothing is sent. It is there for anyone who would rather keep their install entirely to themselves.

The map no longer claims "everything merged" while showing one core

On an install tied to a single robot, the usual case, the map with nothing picked shows that robot, not a blend. The header still announced a merged view, though, and the core dropdown offered an "All cores" choice that did the same one-robot thing. Now the merged banner appears only when the view really is every core at once (a server not pinned to one robot), the "All cores" choice is offered only then, and the dropdown marks the core actually on screen. A tester with two cores was told his data was merged when it was not.

Remove a core you no longer have

Each robot on the settings page now has a "Remove this core" button that deletes it and purges everything Yardstick recorded from it, its samples, sessions and saved map. It shows how much that is and asks you to confirm first, because there is no undo. The one robot this computer is set up to record cannot be removed this way (it would just come back on the next restart); change the install for that one.

A docked robot is no longer reported as "off the map."

The dock sits on its own pad, a few feet off the nearest mowing edge, so the boundary check read a machine on its charger as being outside its own map and raised the alarm. A robot at its dock has not escaped anything, so the check now excuses it, the same way every other alert already excuses the dock. Reported by a tester whose docked machine was told it was five feet out of bounds.

Picking a core now filters the whole page, and works in Safari at last

The core dropdown was wired with an inline handler Safari quietly ignored, so choosing a core did nothing at all. And even where it worked, several panels, health, battery, readiness, the aerial photo and the live dot, ignored the choice and blended both machines. The dropdown is now wired properly, and every one of those panels shows the core you pick, or the one this computer records when you pick none, the same core the map is drawn for. The live dot no longer teleports between two docked cores either. Reported by two testers running more than one core.

The aerial photo no longer drifts out of place on a multi-core install

It was framed on the first core while the map was drawn for a different one, so the satellite image slid off the coverage, a row of bushes that belongs at the top of the plot ended up down in the middle. It now shares the map's core, so the two line up again. Reported by a tester whose aerial had wandered.

On-screen wording is now "License," not "License."

The American spelling throughout the setup page, the key email and the paywall, to match the rest of the product. Only what you read changed; keys, links and saved files are untouched.

The address you enter is the robot (Core), undoing a mislabel from 0.7.20

0.7.20 renamed the field "Data Center" and said Yardstick talks to the base station, not the robot. That was backwards. The Data Center (DC) is the home base the robot radios to; everything Yardstick connects to and records from is the Core, the robot itself. The field now reads "Robot / Core IP address" on the setup page, the first-run screen and the installer, and the yard's radio-coverage layers name the far end of that HaLow link the "home base" rather than confusing it with the address you connect to.

A second Yarbo no longer vanishes after a restart or update

The service names one robot on its command line, and that quietly replaced the whole list every time it started, so a second machine added in the settings page disappeared on the next restart. It now updates that one robot in place and leaves the others alone.

The installer can take just the robot's (Core) IP and find the serial

Give ./deploy/setup.sh 192.168.1.50 and it reads the serial from that address instead of making you paste it, the same lookup the web "enter the address myself" screen does. And when a network scan turns up nothing (your server on a different subnet from the robot, say), it now asks for the address rather than just giving up. yardstick discover --host <ip> does the lookup on its own.

Updates no longer fail silently on a Mac with no certificates

A Python installed from python.org comes without root certificates, so every HTTPS call Yardstick makes, the update check, the license refresh, the daily check-in, failed verification and was quietly swallowed, leaving "no updates" with no reason. Yardstick now carries its own certificate set and uses it for all of these, so they work regardless of how the machine's Python was set up.

The Mac installer now installs Python's certificates

When it has to fetch Python from python.org, it runs that Python's "Install Certificates" step afterwards, the one you were always meant to run, so a fresh Mac install can reach the update server from the start rather than looking dead until someone works out why.

Adding a robot by hand now asks for the Data Center's IP, not the robot's

The field said "Robot IP address," but Yardstick talks to the Data Center, the base station the robot reaches over its own radio, and never to the robot directly. It now reads "Data Center (DC) IP address" and spells out which device that is, on the setup page, the first-run screen and the installer. The serial-number box is gone: it did nothing (the serial is always found from the DC), and it wrongly suggested you could search by serial.

The "cannot get back to the dock" alert waits three minutes, not two

The homeward leg genuinely wanders, our own unit twice in one day drove about 95 ft over two minutes without closing on the dock, with the position fixed the whole time and no fault, and then docked fine a few minutes later. Two minutes cried wolf; three gives the robot room to take a winding route home before we say something is wrong.

"Check for updates" now installs on Mac and Linux, not only Windows

On a Mac or Linux install the update button was sending the machine to the Windows installer, which cannot run there, so it reported the update was "only for Windows" and did nothing. It now uses the source self-update those installs are built for and actually updates. This was a routing bug that had been there since 0.7.15. There is now a test that runs the real update on each platform, end to end, before any release can ship, so the update button cannot break this way again without a release failing first.

A yardstick update command

One plain terminal command that updates to the newest version on your channel, the source swap on Mac and Linux, the signed installer on Windows. So there is always a supported one-liner, whatever happens, and "update by hand" never again means a command you have to be talked through.

These two changes were tagged as 0.7.18, but that build failed on a test that only broke on the Windows CI runner and never reached a channel, so they ship here, in 0.7.19.

The robot shows up live on the map

A green dot marks where the robot is right now. It pulses while the robot is awake and reporting, so you can watch it move, and sits still once it goes quiet on the dock. It reads the robot's own GPS fix and places it in the same frame the map is drawn in, so it lands where the robot actually is rather than off in the odometry frame.

The map says when the aerial photo is coming

Until the robot has recorded enough of its own position to place your yard, there is no photo to show, so both the map and the Map imagery settings now say so plainly: the aerial fills in automatically after a job or two, once Yardstick can work out where the yard is, with no address to type and no pin to drop. The note on the map takes itself away the moment the photo appears.

The Blade Load map now reads in real amps

The robot reports its cutting-motor current in milliamps, but the map keyed it straight through as amps, so a reading of about a fifth of an amp showed up as "234 A," a hundred times what any blade actually draws. It now converts to amps, so the Blade Load layer lines up with the wheel load beside it and with the current figures on the rest of the machine. Caught by a tester who knew the walking motors only pull a few amps and rightly called the number impossible.

The three panels under the map now match their buttons

The Health, Battery, and Table buttons open sections that are now headed with exactly those words, the health panel used to say "Robot health," and the table had no heading at all. The table also carries a one-line note saying what it is: every cell on the map, most degraded first.

The "Middle blade motor" light is gone

The deck has two blade motors, left and right, there is no middle one, and its health light sat permanently green for a motor that does not exist. The firmware carries the channel but never drives it (a flat zero in every sample we have), so it was only ever a source of confusion. Removed from the health panel; still recorded, in case a future head ever uses it.

The table's column headers stay put while you scroll

On a wide table with a lot of rows the header row used to scroll off the top, leaving bare columns of numbers with no labels. The header row is now pinned in place as the rows scroll under it, the way a locked header row works in a spreadsheet. Suggested by a tester.

HTTPS on by default now actually works on a fresh install

The certificate library it needs was never declared as a dependency, so a clean machine quietly fell back to plain HTTP. It comes down with everything else now, so the secure address is there from the first run.

The Linux installer no longer stops halfway on Ubuntu

It found a usable python3 but Ubuntu ships venv support as a separate package (python3-venv), so building the environment failed part way and no service was ever installed, leaving nothing on the port and no clear reason why. The installer now checks that Python can actually build an environment, offers to install the missing venv/pip packages when it cannot, and rebuilds a half-finished environment left by an interrupted run instead of reusing one that has no pip.

The Linux installer keeps the recorder running after you log out

A systemd user service stops at logout unless "lingering" is switched on, so a headless machine or a VM looked dead, with nothing on its port. The installer now offers to turn lingering on (asking first) instead of only mentioning it.

A daily check-in, so we can support what you're running

A licensed install now reports its version, channel, platform and basic health once a day. It never sends your coordinates, your recordings, your robot's serial, or your license key, Settings → Software → Daily check-in shows the exact payload before you take our word for it, and the README's Privacy section spells out the whole of it.

The HTTPS, installer, lingering and check-in changes just above were tagged as 0.7.16, but that build failed on a Windows-only test and never reached a channel, so they ship here, in 0.7.17, alongside the rest.

Check for updates now works on Windows, Mac and Linux alike

Updating from inside Yardstick works on every platform.

Choose which core you are looking at

Running more than one Yarbo? The map, the Plans page and the Controller each have a core selector now, so you pick which machine you are viewing or driving. With a single machine nothing changes, the selector only appears when there is more than one to choose between.

Set how long the wall display holds each machine

The television view rotates between machines; Settings → Wall display now lets you set how many seconds it holds on each one before moving to the next.

Aerial imagery under the map

The yard map can now sit on real satellite imagery, lined up to the ground so the robot's path lands where it actually drove. It defaults to USGS imagery, public domain, free, no key, covering the United States, and turns on by itself, nothing to set up. If you are outside the US or prefer Google's imagery, Settings → Map imagery takes a free Google Maps key of your own (there's a link to get one, and it costs nothing) and lets you switch the source. A control on the map turns the imagery on and off.

Yardstick also serves over HTTPS, with its own certificate

Alongside the usual address it now answers on a second, encrypted one, https://… on the next port up (8478 by default), for when you want the connection secured. The certificate is self-signed and generated on the machine, for the machine, so the browser warns once that it is not from a public authority: that is expected for a device on your own network, choose Advanced and proceed, once per browser. It is on by default, so updating switches it on with nothing to configure, and the Settings page shows the secure address to use. Plain HTTP keeps working exactly as before.

Some settings saved to disk but did not take effect until a restart

Pressing Save on the settings page wrote everything to disk correctly, but the running server only refreshed a hand-picked subset of those values in memory. Anything left out of that list, and every setting added since it was written, looked like it had not saved at all: the page reloaded showing the old value, because the page reads what the server is actually using, not what is on disk. The server now applies all of them the moment you press Save.

The Start-a-plan command was silently ignored

Starting a saved plan sent {"planId": ...}, but the robot's key is id, so the command did nothing, in the usual silence. Now it sends the key the robot actually reads.

The wall said the wrong thing about what the robot was doing

Two problems. It always said "mowing", even with a leaf blower on the front, the verb now follows the attachment: a mower mows, a leaf blower blows, a snow blower clears snow. And it read "mowing"/"blowing" while the robot sat parked and idle, because it trusted working_state, which only means "awake". A verb now needs real evidence, a running plan, or awake and actually moving. Parked and still with no plan reads as idle.

A Plans tab

A new page lists every plan you have built in the Yarbo app, by name, with the zones each covers, and starts any one of them with a button. It leaves the dock and runs the plan exactly as the app would, with no Yarbo account and no internet. While a plan runs, the page shows which one, how far along, and time left, and offers Pause, Resume, and Stop. Building new plans stays in the Yarbo app, that needs its map editor, but running the ones you have is now here.

The controls now match whatever is bolted on

The control page reads which attachment the robot is carrying and shows only the controls that belong to it, blades and cut height for a mower, speed and head height for a leaf blower, the chute for a snow blower, and names the attachment in plain words. Nothing that would command a tool the robot is not wearing appears: a chute control on a mower is how an interface tells you nobody checked.

The blade controls were sending commands the robot threw away

Blade height and blade speed went out under names copied from community notes, set_blade_height and set_blade_speed, that this firmware does not recognize. Every press did nothing, in complete silence, so the controls looked dead. The names Yarbo's own software uses are mower_target_cmd and mower_speed_cmd; with those, blade height now moves the deck (measured on the machine: 50 → 95 mm on command). There was a second reason nothing ran: the blades only spin while the command is re-sent several times a second, so a single press could never have worked even under the right name.

Blades on and off, at the speed Yarbo runs them

One button to start, one to stop, no speed slider. "On" runs the blades at about 2,800 rpm, the same speed the Yarbo app uses, held by re-sending the command five times a second the way manual driving already is. Let go of it, close the tab, lose the network, press Stop, or send the robot to its dock, and the blades stop within a couple of seconds on their own: a spinning blade must not outlive the browser holding it. There is deliberately no speed setting. What an arbitrary speed does to the motors is a guess, and running them harder than the maker does is not a guess worth shipping.

Leaf blower support, speed and head height

Attach a leaf blower and the control page now runs the blower at Low, Medium, or High, and raises or lowers the head. The blower holds until you press Off, and stops on its own if the browser goes away, the same dead-man that protects the blades.

This one was hard-won. The blower command is blower_speed, but the payload key is vel, not speed, which is what the community's tools tried and what made everyone, us included, conclude the blower simply could not be driven locally. The robot reports nothing back when the fan runs, so every wrong guess looked identical to a dead command. The real answer is blower_speed {"vel": N} (0–2000), and the head is a push rod (push_rod_target), not the snow blower's chute. Low, Medium and High are 40 / 70 / 100 % of full.

Send to dock is back, and this time it works

The robot drives itself home and charges, from a button on the map, with no Yarbo account and no internet, measured on a real machine: 4.5 m under its own power, decelerating, turning to line up, stopping 7 cm from the dock.

It was removed in 0.7.9 with the explanation that no local docking command existed. That was our mistake, and the changelog entry has been corrected. The command had been sent with an empty payload; the firmware ignores a malformed command in complete silence, exactly as it ignores one it has never heard of. Eighteen silent attempts read as proof, and a working feature was deleted on the strength of it.

You can drive the robot off its dock now

The firmware locks the wheels while the robot is charging, so a drive command on the dock did nothing, the wheels reported zero and it sat there. The missing step is to pause charging first, and the dock is a wireless charger: wireless_charging_cmd {"cmd": 0} pauses it (and {"cmd": 1} resumes), which releases the wheels. The drive pad now does this automatically on the first press when the robot is charging, so it simply rolls off, no more moving it by hand.

Backup and restore, for moving to another computer

Settings → Storage will write everything to a file: every recording, your robots, the alert address and the app password that goes with it, the yard map and your alarm sound. Download it, or write it straight to a memory stick or a network drive, the recordings are usually too big to want going through a browser. On the other computer, choose the file and restart; it is put in place before anything opens, which is the only moment a database can safely be replaced.

Recordings are optional: settings alone are a few kilobytes and instant.

The machine's identity deliberately does not travel

The new computer asks for the license in its own name, so restoring the same file twice cannot put one key on two machines. Release the license on the old computer, in Settings, or at yardstickhome.com/license, and register it on the new one.

Keep the file somewhere you would keep a password. Your mail account's app password is inside it, because a backup that loses it leaves somebody rebuilding a mail setup on a bad day.

0.7.12 was tagged and built but never published to a channel, so it changed nothing for anybody; everything in it is here.

Yardstick tells you when it has updated itself

Updates install quietly and the program restarts, which is right, and completely invisible. Nobody remembers which version they were on, so a line now appears on the map saying what it updated to, with a link to what changed. It says it once, and goes away when you have looked.

Your license key is shown on the License page

People go there to find it again, for a second computer, or because the email is long gone, and it was the one thing the page would not tell them. It is there now, with a button to copy it.

A four-digit port lost its last digit

The web page port read 847 instead of 8477, with the 7 hidden under the edge of the box. The field was sized for the digits and not for the arrows the browser draws inside it.

Yardstick asks about updates once a day instead of once an hour

The hourly check was per open browser tab rather than per install, so a wall display left on a kitchen screen asked twenty-four times a day to learn nothing. Checks are also spread out at random, so a hundred machines that started together do not all ask at the same second. Pressing check in Settings still asks immediately.

The license email said it could activate on a computer it cannot reach

Its button only works when the email is read on the machine running Yardstick, not a phone, not a laptop, not a server in the garage. It says so now, with the key underneath either way. Every message we send also carries the date and identity headers it was missing, which is the difference between arriving and arriving in spam.

The email alerts guide is linked from Settings

Notifications now points at the full guide, every provider's app password, what each error means, and what to do when a work mailbox refuses to send at all.

A license runs on one computer, and you can move it yourself

When a key is activated it registers to that machine. Pasting it into a second one is refused there and then, with a link to yardstickhome.com/license, paste the key there, press Release, and it is free to register somewhere else straight away. If the key is still on the machine you are sitting at, Settings → License now has a Try again button, so there is nothing to paste.

Rebuilt a computer, or moved to a new one? That is the whole procedure, and it does not involve us. Recording never stops while a key is registered elsewhere.

Releasing a license needs proof it is you

Releasing takes a license off the machine somebody is using, so holding a copy of the key is not enough on its own. On the website you enter the key, we email a six-digit code to the address that bought it, and the code releases it. On the computer that holds the license there is no code, Settings → License has Release this computer, and being that computer is the proof.

The License section now says Registered to this computer while it holds the key, with the two steps for moving spelled out and a Copy key button so the key comes with you.

A support page

at yardstickhome.com/support, linked from the front page, where to send diagnostics, how to move a license, and what to do about a lost key.

An install that could not reach us while activating held no registration at all

, which is exactly the license that could then be shared. Every install now registers itself once a day as well as at activation. Being unable to reach us still never blocks an activation, our outage must not become yours.

"Registered to this computer" could take a day to appear

The signed list of licenses was only fetched daily, so the one line telling somebody to release a key before moving machines showed up long after they needed it. An install with a key it cannot yet account for now checks every few minutes, and goes back to daily once it is settled.

The license email over-promised

Its Activate button only works on the computer that runs Yardstick, which for anyone reading mail on a phone, or running Yardstick on a server or a NAS, it never could. It says so now, and points at the key to paste instead.

A license that never expires said "your subscription renews every year."

Keys issued to testers and staff do not renew and never lapse, and the email now says that instead.

The company name is written properly

, North Lakes Consulting LLC, not Northlake, everywhere it appears.

Yardstick is becoming a paid product, and this build is where that starts

There is a License section in Settings showing what state your copy is in, a trial that begins the first time it runs, and prices. Nothing is limited during the trial, and subscriptions are not open yet.

Recording never stops, whatever the license says

If a trial or a subscription ends, the machine carries on being recorded and nothing is deleted, what pauses is reading it: the map, the trouble spots, the health history and the wall display. All of it comes back the moment there is a valid license, including everything recorded while it was locked.

The settings page has been rebuilt

It was one long column of twelve cards, and a tester with a legitimate question could not find the answer in it. Now there is a list down the left, Your Yarbo, Recording, Storage, Alerts, Notifications, Manual control, Access and login, Wall display, License, Software and help, and each screen holds one subject. Every setting is a title, one line saying what it does, and a switch; the full explanation is still there, one click down, because for most of these settings that text is the only documentation there is.

The wall display says which zone it is cutting

Under the square footage it now reads "Currently in Zone 1 and 2", using the names from your own yard map. Blank while it drives between areas.

Alert email to Gmail always failed, and said nothing useful about why

Google refuses ordinary passwords for mail and wants a 16-character app password. That was written on the page, inside a collapsed section, which is not where somebody looks when a thing has just failed. The error now explains it in words, with the address to create one, and covers Outlook's SMTP AUTH being switched off by an administrator as well.

Reporting a problem no longer goes through GitHub

It opens an email to [email protected] with the diagnostic report already on your clipboard. The old route needed a GitHub account, was public, and truncated the report to fit in a web address, the end of the log, which is the part worth reading.

Left and right were reversed on the drive pad

Pressing left turned the machine right. The sign convention was taken from the documented one rather than from a robot, and the robot disagrees.

A docked robot could never be driven off the dock

Driving was refused outright while charging, reverse included, so the only way off was the direction that was blocked, and the message told you to take it off the dock first. Charging is now something the page mentions rather than something it enforces, which also matters for anyone charging from a wall socket rather than a dock.

The machine stopped every time the network hiccupped

The wheels only turned while the browser kept re-posting every fifth of a second, so a wifi stutter, a busy laptop or a phone throttling its timers stopped the robot. The velocity is now held and re-sent by the recorder itself. The dead-man is unchanged: let go of the button, close the page or lose the connection and it still stops within a second.

The reason a control was refused was hidden while you held a button

, the one moment you would be looking for it. Press and hold, wonder why nothing is happening, and the explanation was suppressed until you let go.

Removed: Send to dock

It was published to a real machine eighteen times in one evening without a single acknowledgment or an inch of movement, so it was taken out rather than left to fail in silence. (That diagnosis was wrong, see the entry above. The command works; the payload we sent did not.)

Updates now come from yardstickhome.com

They used to be fetched from GitHub, which stopped answering when the account behind it was locked, every installed copy went from "up to date" to a silent failure, with no way to be told a new address by a build it could not download. Updates now come from our own host.

This is the one setting a copy cannot be told remotely

, so an existing install has to be moved across once by hand: either install this version over the top, or point it at the new address in Settings. Everything it has recorded is untouched either way.

Three health indicators were permanently red and always wrong

DNS, Cloud broker and NTRIP corrections each showed as failing on every install, on every day. Across 737 samples not one of them has ever reported anything but zero, and the corrections that "NTRIP corrections" called failing were arriving less than a second old and holding a fixed RTK position 99.4% of the time. A service cannot be down while you are visibly using it. The fields are simply not filled in by this firmware, and a zero from a field nobody writes is not a fault. All three are gone, along with "LTE signal", which always read 0 dBm for the same reason.

The green dots that remain are real: the battery pack and attachment links use the same rule on the same firmware and do report healthy.

Saving the settings page could delete a second robot

The page posts back the copy of the settings it loaded with. Opened before a second machine was added and saved afterwards, it wrote that older one-robot list over the stored one and the second robot was gone from the settings, the wall and the alerts. It carried on recording throughout, the recorder was already running, and its samples are filed under the robot's own serial, so it still appeared in the map's filter list, which is what made this look like a display fault rather than a deletion. Reported by a tester whose wall "used to rotate between the two". The robot list is no longer something that form can write; robots are added by their own route, which changes one and touches nothing else.

If you lost a robot this way, add it again under Find another robot, its recordings were never affected and will reattach to it.

The settings page came apart in Safari

Cards were scattered down the page at unrelated heights with whole columns left empty, so sections, "Where alerts go" and "Who can open this" among them, ended up so far from where anyone would look that they read as missing. They were always being sent to the browser; Safari simply could not lay out the CSS multi-column layout they sat in. Chrome and Edge were unaffected, which is why it lasted this long.

The two columns are now filled by Yardstick rather than by the browser, which is the only arrangement that both packs tightly and lays out the same everywhere. CSS grid was tried in between and looked worse than the bug: it aligns rows, so every card shorter than the tallest one beside it left a hole underneath. - Fixed: a second robot added by address alone appeared on neither the wall nor the alerts. The serial box on the manual form is optional and discovery does not always fill it in. The recorder copes, it files that machine's samples under whatever serial the robot itself publishes, but the wall and the alert engine both read the serial from the settings, so a machine added that way recorded perfectly, appeared in the map's filter list, and was invisible everywhere else. It is now found by its recordings when the settings have no serial for it.

"Cannot get back to the dock" fired while the robot was turning round

A job ends where the last stripe ended, usually pointing the wrong way, and the machine then turns, works out a route and sets off. From the far end of a property that first stretch need not get any closer to the dock in a straight line, it is driving, which this alert takes as proof it is trying, and gaining nothing, which it read as failing. So it fired 142 seconds into the leg, the first instant it possibly could.

What the robot actually did, minute by minute in feet from the dock: 365, 364, 353, 323, 271, 198, 140, 125, home. The alert landed on the third of those, seconds before it got going properly.

There is now three minutes of grace after a job finishes before the leg is judged, so the earliest possible alert is five minutes in. The incident this alert was built for, ten and a half minutes to cover eighty feet of blacktop, would still have been reported with five minutes to spare. - Fixed: the "Job stopped early" alert was always wrong, and is removed. It fired whenever the robot was between zones, believing that state to be a pause. It is not, measured minute by minute against distance actually covered, the machine is moving in 99% of those minutes, and faster than when it is mowing. On a large property one drive between zones outlasts the ten-minute timer, so you were told the job had stopped while watching the robot drive past. Every one of these that has ever fired on the recording here was false: three of them, each while the robot covered 115 to 190 meters.

Nothing is lost by removing it. Stopped in the yard already reports a job that has genuinely given up, four minutes sooner, and as a critical alert, and it checks that the wheels have actually stopped rather than guessing from the plan. Replayed across 54 hours, every other alert is unchanged.

The wall display had the same misreading and was corrected a while ago. This one survived because a test asserted the wrong behavior, so the suite agreed with it. There is now a test that no rule may key off that state at all. - Added: two map layers for the radio link back to the Data Center. Your Core is not on your home network, it reaches the Data Center over a HaLow radio, and everything sent to it goes that way. Link to the Data Center shows how well it could hear the DC from each patch of ground; Fell back to cellular shows where it gave up and used the mobile network instead.

The second is the one to act on. Each fallback is roughly half a minute during which nothing can reach the machine, not the Yarbo app, not this recorder. Across this recording every one of them happened between 127 and 680 ft from the Data Center, median 604 ft, and about -75 dBm is where the link starts to give way: ground that never dropped it averages -56 dBm, ground that did averages -78.

It is drawn in red and left blank where the link held, so the map shows the places it happened rather than washing the whole yard in a color. On this recording that is 13% of the ground covered.

It is a radio map, not a navigation one. Position accuracy is unaffected, checked, and RTK stays fixed through 99% of these, because the corrections survive the change of transport. What it costs is reachability and mobile data, not accuracy. - Added: the wall display shows signal quality, not just a satellite count. The GPS tile read "28 satellites" and nothing else, which turns out to say very little: this machine sees a full sky whether or not it can use it. The count barely moves between a good day and a bad one, 29 when healthy, 28 when struggling. Neither does HDOP, nor the dual-frequency count.

What does move is the RTK Quality score: 92% while the machine is coping and 10% while it is not. That now sits beside the satellite count and turns amber below a strong lock. It is the same figure Yarbo's own app shows, so the two can be read against each other.

This catches a case the tile previously could not show at all. On 39% of the samples where the position was RTK-fixed, the signal quality was poor, the fix is good while the machine still cannot trust which way it is pointing. The wall said "RTK" and looked perfectly healthy through every one of them.

The satellite count stays, because people expect it and it is honest context. It just is not the health figure it looks like.

A new install found the robot and then recorded nothing

Setting up through the new welcome screen saved the robot, connected to it, fetched the yard outline and reported itself as connected, but never actually started recording, so the map went on saying "no georeferenced samples found yet" indefinitely. Introduced in 0.7.2 with the welcome screen; installs set up before that were unaffected. If you hit it, updating is enough, the robot you already chose starts recording on its own.

Settings

, one link away, for whenever you go looking for it. - Trouble spots stop calling everything RTK. Every degraded fix was reported as "lost a fixed RTK solution", including the ordinary case of simply dropping to plain GPS. Those are two different problems with two different repairs, and running them together sent people to check a base station over what is usually a tree. Findings are now grouped by what you would actually do about them:

GPS reception

, sky view. Trees, rooflines, walls. Answered by moving the route or clearing what is overhead.

RTK corrections

, the correction stream, not the satellites. Answered at the base station, the radio link or the subscription. - Trouble spots now watch the heading, which is the failure people actually hit. On 102,000 samples from a real machine the position fix was degraded on 0.45% of them; the dual-antenna heading was untrustworthy on 21.6%, about fifty times as often, and just as clustered. Of 254 patches with enough data to judge, 67 were under 5% and 35 were over 50%, the worst at 98.4%. That is a map of the sky, and it was the one thing the map could not show you. A place that keeps losing its heading now says so, with a count of the visits it happened on, instead of being described as a vague shortfall against the rest of the yard. - Fixed: the trouble list could fail to load entirely. Neighboring patches are merged into one finding, and they need not have gone wrong the same way. When a patch reported for weak signal touched one reported for a fault, the merge raised an error and the whole panel came back empty. It needed real ground to happen on and appeared on none of the test data. - The download link now downloads the installer. It went to the release page instead, which opens with the changelog and leaves the installer below the fold, a first-time reader had to know that "Assets" was the part they wanted. Each release now also publishes the installer under the fixed name Yardstick-Setup.exe, so a single link can point straight at the current stable build. - Release pages lead with the download. The installer, what it needs, and the SHA-256 are at the top; the changelog is one link at the bottom instead of several screens above the thing people came for.

The documentation says so too

The README stated flatly that there is no login, which stopped being true with this release. It now says both halves: what leaving the default alone means, and what switching a login on gets you, along with the limit, which is that a password over plain HTTP defends against a guessed password and not against anyone who can watch the network. The startup banner no longer announces "no authentication" at an install that has just switched one on.

An optional login, with an optional authenticator app

Off by default and staying that way: a fresh install behaves exactly as before, and an existing one updating is not suddenly asked for a password it was never given. Switch it on under Settings, choose a username and password there, and add a second factor if you want one.

Passwords are stored as PBKDF2-SHA256 over a per-password salt at 240,000 iterations, never written down, never recoverable. The second factor is standard TOTP, so Google Authenticator, Microsoft Authenticator and the rest all work; it is checked against the published RFC 6238 test vectors, which means no authenticator had to be trusted to find out whether it agrees. Ten single-use recovery codes are issued when it is switched on, shown once, stored hashed.

Guessing is throttled with a widening wait. Six digits is a million combinations, which on a home network is minutes of trying, so without that a second factor would be decoration.

The wall display is exempt

A television has a remote rather than a keyboard, and what that screen shows is the machine's state, never the map, the coordinates, the settings, or anything that can move it. There is a switch to lock it too, for a screen that faces somewhere public.

Forgotten it?

yardstick reset-login on the machine itself clears the username, password and second factor. It grants nothing new, anybody with a shell there can already read the recordings, it just means a lost password is not a lost install. It restarts the service as part of doing so, because the running copy holds its own settings and would otherwise keep asking for the password and write the old one back at the next save.

Recording is untouched by any of this. The recorder and the alert loop talk to the robot and the database directly and never pass through the web server; checked on a live machine with the login on, which carried on recording at its usual rate without a restart.

Signing out

A session lasts twelve hours, so without a way to end it the only way off a shared computer was to wait. Sign out sits in the top right beside Settings, where people look for it, and also on the settings page itself. It ends that browser's session and nothing else.

Both appear only once a login is actually required. Setting a username and password does not switch the login on by itself, that is a separate tick, so an install with credentials configured but the login left off has nothing to sign out of, and says so rather than offering a button that does nothing.

Fresh recovery codes on demand

The stored ones are hashed and cannot be read back, so losing the paper had no remedy short of re-enrolling the app.

The enrollment code is a picture you scan

That needed a QR encoder, and this project ships no dependencies, so there is one now, about three hundred lines of standard library.

Writing one is easy; being sure it is right is not, and a QR that is subtly wrong either fails to scan or scans to a different secret and locks somebody out of their own recorder. So every symbol was read back by two independent decoders, and compared module-for-module against an independent encoder wherever the specification leaves no room for choice. A sweep of every error correction level at every length from 1 to 199 characters round-trips 668 out of 668.

That caught two real faults, both of which produced symbols that looked perfectly well formed: pad codewords that restarted their alternation, and a version chooser that assumed two bytes of overhead at every size, half a byte short from version 10, where the character count indicator widens, so a payload that just fitted was silently truncated. Overflowing now raises instead of truncating.

The README now states plainly that nothing is protected

It was mentioned in the privacy notes as two bullets about the map having no password and not port-forwarding it, which understates it. Only manual control can be guarded, and only if a password is set, which it is not by default. Everything else answers anyone who can open the port: the settings page, the maintenance actions that delete recordings, and the one that starts a software update.

A new section says what somebody on your network can do without being asked for anything, why it is that way, what to do if that is more than you want, and that a VPN, not a forwarded port, is how to reach it from outside.

"PC" is now "computer" where it means the machine running Yardstick

It runs on Windows, on a Mac and on a headless Linux box, and calling the host a PC in the setup page, the discovery help and the storage estimate quietly told two thirds of users the text was not about them. The phrase stays where it is genuinely Windows, the "Windows protected your PC" dialog, and the sleep warning in the Windows install section.

A morning of watching a real robot, and everything it turned up

All of this came from one machine having a bad day while somebody stood over it, not from replaying recordings, which had already been done and had found none of it.

The sequence: the robot drove off the edge of its own map, stopped, reported a fault, cleared the fault, and sat outside for fourteen minutes. Nothing was said. Fixing that exposed two more holes in the alerting, and the fixes themselves then produced two false alarms of their own. All five are below.

It now notices when the robot leaves its own map

A machine drove nine feet past the edge of the map it carries, stopped, reported a planning fault and then cleared it, and sat outside the boundary for fourteen minutes. Leaving the map was the cause; everything else was a consequence.

The robot's map and its coordinates share a frame, so this is a point-in-polygon test with nothing to project and nothing to get out of step. Mowing areas, pathways and sidewalks all count as inside, the machine crosses them to get between zones. No-go zones do not, since they sit within the property.

Off the map

raises at once, with no dwell. Every other rule waits to be sure; a machine heading off the property at half a meter a second covers ten meters while a twenty-second dwell makes up its mind. Certainty comes instead from believing the position only on a fixed RTK solution, a float fix can be a meter out, which is the same size as the thing being measured.

Optionally, it can stop the robot. Off by default, and the only setting in this project that acts on the hardware rather than describing it, for two reasons stated on the settings page: a wrong position stops a robot that was working perfectly, and this has never been exercised against a real machine in the situation it exists for. The alert works either way.

The settings page says plainly what it is not. It cannot prevent the machine leaving, only react once it already has, and it says so, along with every way it can fail to react: checks run every twenty seconds, so the stop can be that late, about ten meters at full speed; it acts only on a fixed RTK solution; the stop is a message over a network that is known to drop; and if the recording computer is asleep, nothing is watching. It also points at the robot's own no-go zones as the real answer, because those run on the machine. This is a net underneath them, not a substitute.

Measured across 88,283 fixed positions from two days: 0.6% ever more than two feet outside, none ever more than ten, and every one of those from the single excursion this was built for. Normal work rides the edge by about a foot.

"Stuck" now has to mean stuck

The flag is momentary, all fifteen spells of it in the recording lasted under ten seconds, and the longest was a single sample, but the rule fired on the first one, so a morning of the machine catching and freeing itself woke somebody nine times in ten minutes while it carried on working. It now waits five minutes, which is longer than any blip ever recorded and short of anything that could be called free.

Nothing is lost by waiting. The morning's real incident began with a two-second stuck flag, and off the map had already raised it three seconds earlier, for the right reason.

What the blips were actually saying is now its own note: struggling repeatedly, three or more catches inside a quarter of an hour. One or two an hour is ordinary work; ten in one hour is the machine having a hard time somewhere. It fires once across the whole recording.

It is filed as information rather than a warning, and deliberately: the wall display sounds its alarm on warnings as well as criticals, so a first attempt at this set off a siren about a robot that was mowing perfectly well. A machine that frees itself every time deserves to be written down, not shouted about.

And when the alarm does sound, an uploaded file now keeps sounding

loop only keeps a playing element going, it does nothing if the first play was refused for autoplay, if the element stalled, or if an error dropped it. The repeat check asked if (customSound()) return, treating "a sound exists" as "a sound is playing", and building a fresh element as a side effect of the question. The result was a siren that went quiet and stayed quiet on a screen nobody is standing in front of. It now checks whether the file is actually running and starts it again if not.

### Why the false alarms happened

Worth stating plainly, because both were self-inflicted and the pattern is instructive.

A field was trusted for its name rather than its behavior

The stuck rule fired the moment the flag went up, and its description said "cannot free itself", which the flag has never meant on a real machine. Fifteen spells of it across three days, every one under ten seconds, longest a single sample. It means I hit something, and the robot drives on. This is the same mistake as plan_state = 3 being read as "paused" while the machine drove down the driveway at 1.1 mph. Both rules were written from what a field is called.

And a fix shipped without checking what it set off

The rule added to quieten the stuck noise was filed as a warning, and the wall display sounds its alarm on warnings as well as criticals, so it replaced one siren with another, about a robot that was mowing perfectly well.

The lesson taken: a rule's severity is not a label, it is a decision about whether somebody gets out of a chair.

### What the alarms were pointing at

They were tuned wrong, but they were not wrong. Catches per hour worked ran 0.0, then 0.7, then 4.2 across the three days, six times the previous day's rate on the morning this was all found, alongside a boundary excursion and a planning fault that stranded the machine for fourteen minutes. The rules now describe that as one pattern instead of shouting about each symptom.

The robot stopped 330 ft out and nothing was said for eleven minutes

Reported live: the machine halted, the Yarbo app showed Track Slippage, the speed read 0.0 mph, and neither an alert nor the wall display mentioned it.

Two separate reasons, both now fixed.

planning_status was not read by the alerting at all. A negative value is the machine's own report that it cannot work out a route, three codes appear in the recordings, -41, -43 and -58, none documented, and every sample carrying one has the wheels at rest. There is now a rule for it. The code is reported as a number rather than translated: -41 was seen once alongside "Track Slippage" in the app, which is an observation, not a decoded table.

And stopped in the yard, the rule built for precisely this, declined to look. It required a plan to be running or paused, but when planning fails the plan does not pause or finish, it vanishes, so a robot stranded mid-yard reported no open job. It now also accepts the machine's own working_state.

Replayed across the whole recording, the two rules produce ten alerts in forty-seven hours, every one a real event, and the planning fault reliably arrives about three minutes before the stall it causes. Today's would have fired at 09:11, ninety-eight seconds after the machine stopped, and nine minutes before it was noticed.

A third rule covers what happens next. Both earlier faults cleared themselves while the robot stayed exactly where it was, once for 65 minutes at 466 ft, once for 136 minutes at 140 ft, so an alert tied to the fault code alone would have gone quiet with the machine still sitting outside. Left sitting out in the yard fires when it has stood down, stopped moving, is not charging and is nowhere near the dock. It occurs twice in forty-seven hours of recording, both times real.

Reading a file without saying which encoding is now a test failure. It works everywhere except Windows, where the platform default is cp1252 and the first em dash or curly quote in the file being read raises. It cost a build: a test added the same morning read a module containing smart quotes. Fifteen call sites across the project had the same latent fault, one of them the database lock. The check parses the source rather than grepping it, a regex reported four false positives on the first attempt, including a JavaScript window.open inside a Python string.

One false alarm was found and removed in the same pass: a machine that undocked, sat six feet away for thirty-six minutes with the battery draining, then docked itself again. Real behavior, nothing for an owner to do, and six feet from the charger is not "the yard". The rule now knows the difference.

A fresh install now says what it is

A beta tester installed this on a Mac, saw a complete-looking map of his own property with nothing on it, and reasonably concluded it did not work.

The cause is worth naming: the yard outline comes free from the robot and needs no mowing, so the tool looks finished the moment it is installed. An empty one therefore reads as broken rather than new. Nobody expects a word processor to arrive with a novel in it, but we were handing people a beautifully typeset blank page.

A notice on first run, shown once per installation, dismissed with a button, now says four things: the outline is real and already here; everything else is recorded from today, because there is no history inside the robot to import; the same ground needs covering about three times before a pattern stops being a coincidence; and, set apart in bold because missing it costs somebody a week of nothing, this computer has to stay on and awake to record.

That last sentence is written per platform, because the truth differs and being wrong either way is expensive. Windows runs a boot-time task and can be locked and logged out of; a Mac runs a login agent and stops when you log out or close the lid; Linux runs a service and needs nobody present.

The readiness line beneath the tiles has been rebuilt to match: a bar with a figure that moves and the actual blocker for your install in plain words. It is loud while the recording is young and quiet once it is not, it used to do the opposite, dimming itself exactly when it had the most to say.

Tells you when the robot cannot get back to its dock

A Yarbo finished a job eighty feet from the barn charger and took ten and a half minutes to cover it, stopping and reversing the whole way. Nothing failed: no error code, no stuck flag, the machine reporting itself as working throughout. Yardstick recorded every second of it and showed none of it.

When a job has finished and the robot spends two minutes driving without getting any closer to the charger, you are now told, with the numbers: "Drove 77 ft in 3.1 minutes without getting closer to the dock, 29 ft short of it." Replayed against the recording it fires once, five minutes into the failure, while somebody can still act, and stays silent across the clean daylight run the day before and a full day of ordinary work.

Deliberately narrow. It says nothing about struggle during mowing, because a mowing robot is supposed to double back and turn in place; every attempt to detect that from motion produced fifty-nine "episodes" in two days, nearly all of them the job being done properly. The homeward leg is the one case where the robot has a single destination and failure needs no interpreting.

A telemetry blackout is explicitly not a stall. Switching the cameras on from the Yarbo app takes the machine off the network for a minute or more, and the first version of this analysis read one of those silences as a two-and-a-half minute stall. "Nothing was reported" is not "nothing moved".

Two things the recordings settled along the way. Yarbo's own obstacle field is empty, six non-null values in seventeen hundred samples, every one a zero, so whatever the app means by "navigating obstacles" is not published. And during the longest hesitation the ultrasonic sensors reported clear on every one of seventy readings, which makes them a poor explanation for a fault that only appears in the dark; an ultrasonic sensor cannot tell day from night.

Trouble now shows on the map, and every row leads to a place

The list says things like "a 15 ft patch about 791 ft north of the dock rarely gets a strong signal lock", which nobody can turn into a location by looking at their yard. Clicking any row centers the map on the spot, zooms in and drops a crosshair on it. Clicking the map puts the crosshair away again. The coordinates were already in the payload and had never been used for anything.

Marks are drawn behind a Trouble switch that is off until you turn it on, and that appears only once there is something to mark. Small numbered pins, nothing else, the number keys into the list below, and clicking a pin takes you to the row that explains it. The map says where; the list says what.

Two kinds: where the robot could not get home, and where something is always in the way, found in the same place on four or more separate visits. The second is the one worth acting on. If it is a car parked in the same spot every day, the map now says so and you can move it. What the object is cannot be read from here, the robot reports a distance, not an identity, so it does not guess.

Repeated detections are grouped into one pin per object rather than one per grid square, by real distance rather than grid adjacency: the first attempt gave seventeen pins at a one-meter cell size and four at three meters, so the yard appeared to grow objects when a setting changed. Only the five seen most often are pinned, and the page says how many were left out.

The wall display no longer says PAUSED while the robot is driving

It was reporting the machine's own plan_state of 3, which this project has called "paused" since the display was written. It is not a pause: across two days, every one of the sixteen spells spent in state 3 had the wheels turning between 90% and 99% of the time, one of them a 320 ft run from the dock to the first mowing area. It means "not executing the mowing plan", which mostly means going somewhere.

The state now reads the wheels rather than the number: travelling when they are turning, paused when they are not. There is also a planning route state for the gap between waking and setting off, where the machine sits still for up to 78 seconds working out where to go, the wall used to call that "mowing", because plan_state is never cleared between jobs and still held the previous one's value.

A departure now reads as what it is: charging, planning route, travelling, mowing. Slowing to turn no longer reads as stopping, either; the state uses the fastest wheel reading of the last twenty seconds, after a real departure showed a ten-second dip to 0.04 m/s flipping the word to PAUSED and back mid-drive.

### Fixes

Trouble spots were drawn in the wrong coordinate frame

The map measures east and north from the south-west corner of the data; the trouble-spot code measured from the first row of its own query. On this property that is 50 m east and 101 m north apart, on a map only 73 m wide, so a crosshair landed well off the side of the yard. There is now a single origin, taken across the whole recording rather than the rows in view, because a date filter would otherwise move it and drag every marker along.

Markers grew with the zoom

They sit in the group that scales with the map, so at 5x a 13-pixel ring became a 65-pixel target sprawling across the yard. They are now placed at their spot and scaled back by the same factor.

Three CSS variables were used that nothing defined

var(--gold) appeared in ten places and has never existed, the name is --accent, along with --line and --line-2. Two predate this release. A misspelled custom property throws nothing, warns nothing and fails no test that checks markup; it falls back to the initial value, which for stroke is none and for fill is black. The selected robot's pill had been drawing near-black text on a near-black background since it was written, and of three new navigation icons one drew in black on a black bar and two did not draw at all. Every page is now checked for variables it uses but does not define, in both themes.

The links to the other views were easy to miss

Drive, Wall display and Settings & storage were 13px muted gray, the same weight as a date chip, on a page carrying a map, tiles, alerts and a table, and they are the only route to the drive pad and the television view. They now have full-contrast text, solid glass, a larger tap target and an icon apiece, drawn as inline SVG because this page has to work from a phone on a network with no route out. Still quieter than an alert, which stays the loudest thing on the page.

Look at one day, or one week, instead of everything at once

The map has always shown the whole recording, which is right for judging a yard and wrong for answering "what happened yesterday". There is now a date picker above the map: All time, Today, Yesterday, 7 days, 30 days, This year, or a pair of dates you choose.

The map, the headline figures and the coverage table all follow the filter, and a filtered page says so at the top with a link back to everything. The range travels in the address, so a narrowed view can be bookmarked or sent to somebody. Switching robots keeps the dates and picking dates keeps the robot, they are separate questions.

Two panels deliberately ignore the filter and say so on the page. Trouble spots needs a place to go wrong repeatedly across separate visits before it will name it, and readiness is a count of how much history exists at all. Neither can be answered from a single day, so both keep reading the whole record.

Picking a period with nothing in it gives a page that says so and offers the way back, rather than the "waiting for the robot" screen, which would have been both wrong and a dead end.

yardstick map takes the same filter, --range yesterday, or --from and --to, so a page you send somebody can be one day's work rather than the whole record.

Also: this file

Every release from 0.5.2 on is written up below, and the suite now refuses to pass without an entry for the version in the code, so a release cannot reach anybody undocumented. The notes on each GitHub release are taken from this file rather than written separately, because two accounts of the same release drift.

Carries 0.6.24, which did not ship: the date labels were built with %-d, a format code that strips a leading zero on Linux and raises on Windows, so every custom range failed on the build runner and nowhere else. The whole family of those codes is now grepped for in the test suite.

A wall display noticed it was running yesterday's page

An alarm sound that had been fixed went on being wrong, because the fix was in a page a television had loaded hours earlier. The server was serving the corrected version the whole time, and nobody sits in front of a television to refresh it.

The wall display now reads the build token with its data and reloads itself when it changes, automatically, since there is nobody there to accept an offer, and never during an alarm, so it cannot clear something somebody is being shown.

One recorder per database, enforced by the operating system

Two copies ran on a test machine for hours. Nothing crashed, which is why it lasted: every log line appeared twice, two sessions opened on every start, the database grew at double the rate, and each instance offered its own update, which from outside looked like an update that would not finish.

The old guard asked whether the port was free and then, separately, bound it. Two processes starting 0.4 seconds apart both passed. Exclusion now happens on the database itself, before anything else, with an exclusive lock the kernel arbitrates, no gap between asking and being answered, and a lock that dies with the process holding it, so a crash never blocks the next start.

The alarm sound you chose stopped being chosen

Send a test alarm played your uploaded MP3 the first time and the built-in beep every time after. The audio element was created once and marked broken on any error, permanently, and stopping an alarm rewinds it, which throws while it is still loading. One hiccup and every later alarm was the beep, silently. It now falls back for the alarm in hand and forgets, rebuilding next time.

Carries 0.6.19, which did not ship: the database lock failed on Windows, where locks are mandatory rather than advisory, so locking the first byte made the owner's process id unreadable, the very thing written there to be read.

The "Report it on GitHub" button had never worked, and would have leaked

It gave your request URL is too long. The report was trimmed to 5,500 characters, but URL encoding roughly triples that, every newline becomes %0A, so any real report produced a URL GitHub refused. It now trims by encoded length.

Worse was what it would have published. The report carries the tail of the log and is meant to be pasted into a public issue. A failed phone alert logs the ntfy URL, and the topic in it is a password in all but name; a failed email logs the address. Both are now scrubbed alongside coordinates and serial numbers, and the report says so at the end.

MacOS install confirmed working end to end

, on a real Mac rather than reasoned about.

The last obstacle was macOS asking whether Terminal may reach the local network, attributed to the terminal, not to Yardstick, and asked exactly when the first scan runs. Until it is answered the scan finds nothing, which is indistinguishable from an empty network, so the install ended with "no Yarbo found" and no hint that a dialog was the whole story.

The installer now warns the dialog is coming and what to click, before the scan that triggers it, and looks again afterwards, the scan that raises the prompt is itself doomed, so without a retry, clicking Allow still left the install failed.

Uninstall instructions for Mac and Linux are now in the README rather than only in the installer's closing output. Neither registers with a package manager, so there is no Add/Remove Programs to fall back on.

Say why no robot was found on a Mac

"No Yarbo found" is fine on Linux and close to useless on macOS, where the most likely cause is a permission dialog you have not answered. It now names that first, with where to switch it on, then the two ordinary causes, then how to skip discovery by passing the address and serial.

One command sets up a Mac or a Linux box

Installing meant four commands, and the first failed on a stock Mac with a message about a missing setup.py. The real cause is that macOS ships Python 3.9, too old for this, and carrying a pip too old to install a project that has no setup.py at all.

deploy/setup.sh does the lot on both platforms: finds a Python 3.10 or newer, offers to install one when there is none, builds the environment, updates pip, installs Yardstick, then hands over to the platform's installer. Homebrew where it exists, apt/dnf/pacman/zypper on Linux, and the official python.org package otherwise, checked against its Apple signature before anything runs with sudo. It asks before touching anything system-wide, and treats no answer as no.

The release smoke test now loads every page from the frozen binary. It used to run --help and two offline commands, so nothing in the alerting, wall display or control code was exercised in the form that actually ships.

Replaces bootstrap-mac.sh from 0.6.14 with one script covering both platforms.

One command to set a Mac up, and a useful error if not

Installing on a Mac by following the steps in order produced ERROR: File "setup.py" or "setup.cfg" not found, which is true and explains nothing. The real cause is that macOS ships Python 3.9: too old for this, and carrying a pip too old to install a project that has no setup.py. The version check existed but ran afterwards, so the confusing message came first and the useful one second.

deploy/bootstrap-mac.sh did the whole thing in the order that fails usefully. 0.6.15 generalised it to both platforms as deploy/setup.sh.

Typing a name no longer fights the page

A tester reported that naming his Core took many attempts, "it times out or something very fast". It was not a timeout: the status poller rewrote the robot card every ten seconds, and the name field lives inside it, so anything half-typed was destroyed mid-word.

The poller now leaves that block alone while you are typing in it, and only touches the page when the markup has actually changed. Pressing Enter saves.

Documentation that matches the software

Four things the README claimed that had stopped being true, found by checking its assertions against the code.

Manual control was described as off by default in four places; it has shipped on since 0.6.1, including in the privacy notes. "Nothing routed through anyone's servers" was written before phone alerts existed, it now says recordings never leave your machine, which is what was meant and is still true. The Updates section now describes what happens when you switch channels.

A way back off a testing build

Trying a testing build was a one-way door. An update check only ever offers something newer, so a copy ahead of its channel was told "no updates available, you are on the current version", true, useless, and indistinguishable from everything being fine.

The page now says what is going on, you are on 0.7.0, stable is on 0.6.10, and offers to install the channel version over the top. Guarded on the database: an older build can refuse to open recordings written by a newer schema, so a rollback that would cross a schema change is refused with the numbers in the message.

Tagged builds now publish as pre-releases, so the repository never advertises an untried build as the download, and promotion to stable clears the flag.

Stop waiting five minutes for the CDN

Manifests are served with a five-minute cache, so a release that had already been promoted stayed invisible and pressing Check for updates again changed nothing. The check now defeats the cache, so a promoted release is visible immediately.

The channel switch actually switches

Selecting Testing saved the setting and then reported no update. A copy of the stable manifest URL was sitting in update_manifest_url, and that field wins by design, so the channel changed and where it looked did not. A pinned copy of one of the two channel URLs is now treated as the leftover it is.

Also: a Mac user is told their Python is too old before pip is, and an environment already built with one that is too old is refused rather than failing at run time.

A source install can update itself

Mac and Linux copies are git checkouts, and now update from the same button Windows uses: pull, reinstall, restart.

What makes it safe to put behind a button is what it refuses to do. It will not touch a dirty working tree. The pull is fast-forward only. The reinstall must succeed before anything restarts, so a failed install leaves the old code running. And it installs with the running interpreter rather than whatever pip is on PATH, which would otherwise update a different environment and look exactly like nothing happening.

Carries 0.6.7, which did not ship: restart_command builds a launchd target from the user id, and os.getuid is absent on Windows rather than merely unused, so the lookup raised there.

MacOS support

A launchd user agent and an installer for it, so a Mac runs the recorder at login rather than in a terminal somebody has to leave open. Same shape as the Linux install: discovers the robot, fills in the paths, needs no root.

The agent restarts on failure but not on a deliberate stop, and writes its log beside the recording rather than somewhere only Console can find.

Two honest notes in the installer output rather than left to be discovered: a Mac that sleeps stops recording and will leave gaps, and a source install cannot replace itself with a downloaded build.

Carries 0.6.4 and 0.6.5, neither of which shipped, both failed on the Windows build runner on tests of mine that assumed a Unix machine.

A wall display worth looking at

Four tiles stretched across a television left the numbers stranded in tall empty boxes with a dead third at the bottom. Six tiles in two rows fills the screen, and the two extra readings, area cut so far against the job's size, and how long it has been running, are ones people actually want.

The drive page said "Unknown attachment attached" and "offline" on first load, before the first snapshot arrived. Both now say what is true while waiting.

README carries real screenshots of the wall display and the drive pad.

Say plainly what the local connection does not offer

Three things get asked about repeatedly and none is missing work on this side: cameras are not reachable on the local network, the yard map can be read but not written back, and the attachment's current settings are not published at all, so the control page can set a cut height but cannot show you the one in force.

Written up in the README and given a card of its own in Settings. Each says what was observed rather than asserting a limit: switching a camera on took every local connection down for two minutes, and an independent PHP control panel hit the same wall on map upload. Stated as firmware decisions rather than permanent ones.

Updates that say when they are done

An update looked as though nothing had happened: the page waited for the server to answer and then reloaded, but the old copy is usually still serving when the first poll lands, so it reloaded into the version it started on. It now waits for the reported version to change, says what it is waiting for, and gives up with an explanation after four minutes rather than spinning.

Manual control now ships on

A control center whose controls have to be found and switched on first is a poor greeting. With no password set, anything that can reach the port can drive the machine, the password field is there for anyone who wants it, and the safety properties are unchanged: control is taken deliberately, a charging robot will not move, and the dead-man stops it when the browser goes quiet.

Alerts, wall display and manual control

The release that turned a recorder into something you watch.

Alerts

Nine rules over what the robot already records, each switchable, each dwell time chosen by replaying real recordings rather than invented. The one that matters is stopped in the yard: a Yarbo that loses its RTK fix stops with stuck at zero, no error code and a plan still reading as running, so nothing else notices. Replaying a real day gives twelve alerts in twenty-eight hours, every one a real event.

Delivery is on-screen, a Windows toast, ntfy, or your own SMTP. Nothing routes through this project, so it costs nothing at any scale.

Wall display

at /wall for a television: progress, speed, battery and time left in type readable across a room, rotating between machines and holding on whichever needs attention. Alarms fill the screen with a repeating sound and a Dismiss button sized for a remote. Built-in beep by default, or upload an MP3, OGG or WAV, validated by header, not by extension.

Manual control

at /control. Hold-to-move with a 0.7-second dead-man stop, refusing to drive while charging or with the stop button pressed. Controls follow the attachment using Yarbo's own compatibility table, so a mower does not offer chute angle.

The recorder is unchanged and still never transmits; control lives in its own module so that stays checkable.

Also recorded now: power_fault_state and the wheel motor currents, after a machine reported a power fault for seven minutes while Yardstick said nothing, the field was arriving on every snapshot and being discarded.

Fixes a startup path that rebuilt the robot from --robot-host and dropped the owner's chosen name on every restart.

Let the update helper run on battery too

The service task had been fixed for this and the update's own helper task had not, one layer down, so an update could do everything it promised and change nothing: it checked, downloaded, verified the checksum, wrote the helper and scheduled it, and then Windows quietly declined to start that helper, because schtasks had set start only on AC power on it as well. No installer ran, no files changed, no log was written. From the outside the update simply did not happen.

Registered through PowerShell now, with the battery conditions off, matching the service.