Everything you own is waiting for something

01 / Fragment

Four things, four versions of what is going on

A resident reporting a problem may need to attach photos, give permission to enter, and suggest a time for the visit. AppFolio’s official resident-portal guide describes that process, along with messages and request status.05 It is built around a resident and a property manager.

Connected vehicles organize their information differently. Tesla’s official Fleet API uses permission scopes to separate vehicle data, location, commands, charging, and service information.07 Booking service is a separate process, with estimates, messages, approvals, and visit history.08

Some RV systems provide selected coach controls and status information. Winnebago’s Connect documentation also spells out limits around models, connectivity, compatibility, and accounts.06 Sea-Doo offers connected navigation, while maintenance guidance for each model still lives in separate owner documentation.0910

These systems were built for different jobs, with different owners, manufacturers, risks, and permissions. Some of the separation is frustrating. Some of it reflects differences that a shared manager would still need to respect.

02 / Obligation

An issue is not just a red dot

“The AC is broken” sounds like a fact, but it may begin as an owner report. A controller might later add an error code. A technician may record a diagnosis. A receipt may establish what was replaced. Those statements belong together, but they are not interchangeable.

A useful record lets you follow what happened: the first observation, later checks, and the person who needs to act next. Dates and sources belong beside those notes. Marking a task done should not quietly turn an owner’s update into proof that the fault has gone.

Home Assistant’s Repairs feature shows one way to keep a problem attached to the system it affects. It surfaces problems inside a Home Assistant installation—outdated firmware, a retiring API, an unsupported configuration—and can sometimes guide a fix from the same interface.04 That is not a network for arranging physical repairs, but it is a useful example of keeping the issue and its context together.

03 / Time

Everything you own keeps a different clock

A building ages by seasons, inspections, occupancy, and repair history. A vehicle ages by time, distance, software state, use, and environment. An RV adds storage periods, trips, weather exposure, plumbing, batteries, appliances, and a vehicle chassis. A watercraft may spend most of its life out of the water while a few hours of use determine the next maintenance step.

One health score would hide too much. “Good” can hide a service campaign. “Needs attention” can blur the difference between your reminder and a detected fault. Show the last known state, its source and date, and who needs to act next.

ISO’s asset-management standard connects care over an asset’s life to an organization’s objectives, rather than treating repairs as isolated jobs.11 A household is not an industrial asset manager, but the longer view is useful here too. Buying something, using it, repairing it, and eventually selling or retiring it all leave records you may need later.

04 / Provenance

The panel has to say how it knows

A status without a source is just a label. “Battery 68%” might be a live reading. “Roof inspected” might come from a dated invoice. “Winterize soon” might be your own reminder. “Valve replaced” might be a contractor update copied into the record. Put them on one screen, but keep their sources and dates attached.

Standards offer some groundwork. The W3C Web of Things Thing Description provides a standard way to describe a thing’s metadata, properties, actions, events, forms, and security requirements.01 The companion Discovery recommendation describes how Thing Descriptions can be found, including through directories.02 These standards help describe different devices in a common format. They do not create a household ledger or decide who is responsible for a repair.

Home Assistant’s Device Registry groups entities into device records, assigns devices to areas, connects them to hubs, and shows manufacturer, model, firmware, and related information when integrations provide it.03 The official documentation also notes that the same physical device configured through two integrations can become two device records. A shared manager would need to recognize when two records refer to the same thing.

05 / First version

It should be useful before anything connects

The sources here describe separate systems, not one shared service. They do not establish a universal consumer hub connecting property, vehicles, RVs, and watercraft. The future version imagined here would have to bring those records together without losing their dates, permissions, or limits.

Start with a list you can understand. Add a thing. Write down the problem and where the information came from. Keep sensitive identifiers out, and don’t let the app claim more than you know. If a provider later offers a suitable connection with your permission, its updates could join the record without replacing your notes.

A future connected version should remain useful when a connection stops working. An API change should not make the thing disappear from your list. A subscription ending should not erase the meaning of its service history. And if a system cannot connect at all, you should still be able to write a note. That is a useful fallback, not a failed version of automation.

Manager for Your Things starts with that smaller question. It is a browser-only study with fictional examples, not a connected service. It sends no issue anywhere. Try it to see whether the record helps you understand what happened and choose what to do next.