If you’ve ever tried to manage equipment maintenance with ordinary phone reminders or a general-purpose to-do app, you already know how quickly it becomes awkward. Those tools can remind you that something is due, but they don’t really understand the equipment, its service history, what was done last time, what parts or supplies it uses, or when the next service should actually be calculated from. ServiceTag is built specifically for that problem. Instead of maintaining a separate collection of reminders and checklists, each piece of equipment keeps its own maintenance schedule, history, documents, measurements, and service information together, and ServiceTag works out what is due and when. You spend less time managing reminders and more time simply doing the maintenance when it needs to be done.
I’ve been building ServiceTag, an Android app built around a simple idea: put an NFC tag on the things you own, tap it with your phone, and go straight to that item’s digital service record — maintenance schedules and history, manuals, parts and supplies, photos, serial numbers, and other information you normally end up hunting for when something needs attention. Think of it as putting a little digital service binder on a furnace, generator, hot tub, mower, appliance, or just about anything else you maintain.
Until now, ServiceTag mostly knew what you explicitly told it: the pellet stove is back in service for the winter, this hot tub is entering its summer season, and so on. That already lets maintenance schedules behave differently depending on whether equipment is actually in use. The Home Assistant integration adds an outside source of context: instead of manually telling ServiceTag that heating season started, irrigation season ended, or the snowblower is back in service, an automation you already trust in HA can make that decision and ServiceTag’s maintenance schedule follows along automatically.
I’ve just added the first Home Assistant integration. ServiceTag can link an Asset to a dedicated HA boolean such as input_boolean.pellet_stove_in_season. Your existing Home Assistant automations decide when that helper is on or off, and ServiceTag uses it to automatically move the equipment in or out of its operating season. That matters because ServiceTag’s maintenance schedules can follow the equipment’s season: when heating season begins, for example, the relevant in-season maintenance cycle becomes active; when the season ends, ServiceTag records that transition and its maintenance policies respond accordingly. It’s deliberately the season state, not whether the appliance happens to be running at that moment.
The integration is outbound REST only — no HA custom component or add-on. You can Follow Home Assistant, Force in season, or Force out of season, manually Sync now, and choose checks every 12 hours, daily, weekly, or monthly with daily as the default. It also supports private HA installations: you can restrict ServiceTag to your chosen home Wi-Fi and optionally allow background checks there, while keeping the integration foreground-only if you don’t want to grant the additional Android permission. If HA is unreachable or reports something other than a valid on/off state, ServiceTag simply leaves the current season unchanged and shows the sync status.
Configuration Instructions
the user creates one persistent boolean in Home Assistant specifically for ServiceTag to read. The intended setup is concrete:
-
In Home Assistant, create the season boolean. Go to Settings → Devices & services → Helpers → Create helper → Toggle and name it something meaningful, e.g. Pellet Stove In Season. HA will give it an entity ID such as
input_boolean.pellet_stove_in_season. A Toggle helper is persistenton/offstate, which is exactly what ServiceTag expects. -
Make your HA automation own that boolean. Whatever logic determines “heating season has started” calls
input_boolean.turn_on; whatever determines the season has ended callsinput_boolean.turn_off. ServiceTag does not care how you make that decision—temperature, dates, another automation, a manual dashboard button, etc. Its contract is simply:
on= in season,off= out of season. Home Assistant supports those turn-on/turn-off actions directly for Toggle helpers. -
Create the credential ServiceTag will use. Ideally make a dedicated non-admin HA user for ServiceTag, log in as that user, then under User profile → Security → Long-lived access tokens, create a token and copy it. ServiceTag uses that token for authenticated REST reads.
-
In ServiceTag, configure the HA connection once. The intended UI is Settings → Utilities → Home Assistant. Enter the HA server address and access token, choose the polling cadence—12 hours / daily / weekly / monthly, daily by default—choose Any network or Only on this home Wi-Fi/local network, optionally enable background home-network checks, and press Test connection. ServiceTag tests the HA REST API and stores the credential securely.
-
Then bind an individual ServiceTag Asset to the HA helper. Open, say, your Pellet Stove Asset → its operating-season section → Link to Home Assistant. Enter/select the exact entity ID:
input_boolean.pellet_stove_in_seasonand choose Follow Home Assistant. That is the actual connection between the two objects:
ServiceTag Asset: Pellet Stove ↓ HA entity: input_boolean.pellet_stove_in_season ↓ on = in season off = out of season
After that ServiceTag constructs the REST request itself—conceptually GET /api/states/input_boolean.pellet_stove_in_season—so the user does not configure API paths, JSON fields, or response parsing. HA’s REST API returns the entity state, authenticated with the bearer token.
So the end-user story is quite clean: create one Toggle in HA, have your automation maintain it, give ServiceTag the HA connection once, then tell each ServiceTag Asset which Toggle represents its season.
And importantly, this means you could have several ServiceTag Assets mapped independently:
Pellet Stove → input_boolean.pellet_stove_in_season
Snowblower → input_boolean.snow_equipment_in_season
Irrigation → input_boolean.irrigation_season
Pool Pump → input_boolean.pool_season
Each one can have completely different HA automation logic, while ServiceTag only ever needs the resulting on/off decision.