scheduler-card: a Lovelace card for scheduling Home Assistant devices without YAML

The card is the front end, the component does the work

scheduler-card is a Lovelace card for Home Assistant that can be used to create a time schedule for your smart devices. You can create new rules, modify existing rules and temporarily disable rules.

The dependency is stated without ambiguity. The card works on top of the scheduler custom component, and the README says you will need that as well. It is a separate repository, and the installation section repeats the requirement: install the scheduler component and add the integration in order for the scheduler to work properly.

That division is the thing to understand before evaluating the project. The card is a browser-side user interface that talks to Home Assistant's websocket API and renders a scheduling editor. The component is the server-side piece that owns the schedules, evaluates them, and triggers the entities. If you install only the card, the Lovelace resource loads and the card renders, but there is nothing behind it.

Why the split exists is a reasonable inference from the architecture. The scheduler component is a Home Assistant integration, and Home Assistant integrations are Python and versioned with Home Assistant itself. The card is a front-end bundle that is loaded as a Lovelace resource, cached by the browser, and updated independently. Coupling them into one repository would have meant the front end and the integration could never be released separately, and a card that has to be reinstalled whenever the integration changes is a bad deal for users.

The audience is therefore a Home Assistant user who wants a graphical schedule editor, and who is willing to install a second custom component. The topics list gives the rest: assistant, automation, card, custom-card, home, home-assistant, homeassistant, lovelace, schedule, scheduler, sunrise, sunset, week, weekly, which is the vocabulary of that ecosystem rather than a general-purpose project.

The primary language is TypeScript, and the repository is not archived with a last push on 2026-09-16, with releases v4.0.19, v4.0.18 and v4.0.17 in 2026.

Installing it, and the www folder that silently breaks HACS

The HACS route is the normal one, and the README leads with a warning that has caught people out. Note: ensure you have a www folder created as in config/www or the installation will succeed but fails silently. The HACS badge in the README marks it as a HACS custom integration.

The steps are: open the HACS panel in Home Assistant, go to the Frontend section, search for scheduler-card, click download, and follow the instructions provided to complete the installation. Then, separately, install the scheduler component and add the integration.

The manual route is more explicit about the file layout. Download the latest release of scheduler-card.js from the releases page and place it into www/scheduler-card, then follow the Home Assistant frontend documentation on registering resources to add the card, with the example URL given as /local/scheduler-card/scheduler-card.js?v=0. Finally, add the card to the view where you want it by editing ui-lovelace.yaml or using the card editor:

type: custom:scheduler-card
domains:
  ...
entities:
  ...

The type custom:scheduler-card is what tells Lovelace to load the custom element, and the domains and entities keys are the card's own configuration surface.

The v=0 query parameter is there for a reason that the updating section explains. Since most browsers will cache the Lovelace card code, you can force a refresh by editing the entry in the Lovelace resources section and updating the URL to ?v=(n+1), where n is the current value. Manual installations update with git pull, and HACS is supposed to remind you in the HACS tab when an update is available.

That caching detail is worth internalising before you start, because a stale card bundle after an update looks exactly like a broken card, and the fix is a query string rather than a reinstall.

The scheduling wizard, and how a rule is actually built

The usage section is a step-by-step description of the editor, and reading it tells you what the data model looks like.

You start by clicking the add item button at the bottom of the card. The first view is for choosing an entity and an action. The card scans the entities in your Home Assistant configuration and suitable candidates automatically show up. Clicking an entity automatically shows the actions you can program for it.

What counts as an entity is broader than a device. Typically an entity is a device in your house, but you can also control an automation, a script, an input_boolean and similar. All the entities you want to control go in the include list. And the actions are usually turn on or turn off, but some entities have more capabilities, and if you are missing an action you can add it yourself using the customize configuration.

Actions can contain a variable setting, for example turning on a lamp at a specific brightness or changing the setpoint for a thermostat, and these are defined on the next page. That is the interesting part of the design, because it turns the card from a simple on/off scheduler into something that can carry a payload.

The days view comes next. Every day is the default, and the schedule performs the action every day at the specified time. Workdays performs the action only on Monday to Friday, and if you have the workday integration installed you can use it to define your own set of workdays, with the integration and its settings automatically detected if it is installed, and holidays you define excluded from workdays. Weekend performs the action only on Saturday and Sunday, and with the workday integration installed the weekend is considered as the inverse of workdays, so holidays and your fixed day off are included in the weekend setting. Custom gives you a list of all days of the week and you select one or more by clicking them.

The time view uses a time picker showing the current setting with arrow buttons to increase or decrease the hour and minutes, and you can infinitely loop through time. The step size for minutes is 10 minutes by default but can be configured. If you have the AM/PM option enabled, 12-hour format is used, and you can switch between the two on a button.

Then there is the sunrise and sunset mode. If you have the sun integration in Home Assistant, a button with a sun and moon icon shows up on the right, and it is the mode button.

Time schemes, the options panel and the conditions

The table of contents lists a second half of the feature set beyond the simple entity-and-time schedule, and this is where the card stops being a convenience wrapper.

A time scheme is the more expressive object. Under it there are timeslots and a time scheme editor, and the options panel below that holds the condition editor, the period, behaviour after completion and the name. So a scheduler card entry can be more than a single trigger: it can be a window of time, with conditions attached, and with something specified to happen when the window completes.

The condition editor is the piece that makes this a scheduler rather than a timer. A condition is a test that has to hold for the rule to fire, which is how you express a schedule that depends on state, for example a lamp that comes on at dusk only if nobody is already home. The period setting is presumably the window over which the condition is evaluated, and behaviour after completion is what happens once the period ends.

The configuration section then covers the card's own options, a standard configuration, and adding entities through the include and exclude lists. Include is the list of entities you want to control, and exclude removes them again.

Schedule discovery is the other configuration topic, and it is a feature rather than a setting. Rather than only managing schedules you created in this card, the card can find the schedules that already exist in the scheduler component, including ones created by other means. For a user who has been configuring schedules by hand in the component's own UI or through YAML, that means the card adopts the existing state rather than presenting an empty list.

The Customize section goes deeper still, with options, actions, a numeric action variable and a list action variable. The variable types are worth noting: a numeric variable is for a single numeric payload such as a brightness or a percentage, and a list variable is for a multi-value payload. The Conditions subsection rounds out the customisation surface.

The display options and the tags feature are the last two pieces of the card's own UI, and the tips and tricks section gives two worked examples: triggering multiple actions on a schedule, and customizing built-in actions.

The build: Lit, Rollup and a browser cache

The package.json describes a small, modern front-end toolchain, and it is worth understanding because the card ships as a single file into a browser.

The package is named scheduler-card, the main entry is dist/scheduler-card.js, and the version field reads 4.0.19, matching the latest release. The build script chains three steps: npm run lint, which runs eslint over src/**/*.ts with --fix, npm run format, which runs prettier over the TypeScript files, and npm run rollup, which runs rollup -c. There is a start script, rollup -c --watch, for development.

The runtime dependencies are the interesting part. lit at 2.7.4 is the component library, and it is the reason the card is small: Lit produces web components, and a Lovelace custom card is exactly a custom element that Home Assistant renders. The Home Assistant side uses home-assistant-js-websocket, which is the client for the websocket API the card talks to, and @mdi/js is the Material Design Icons package, which is the icon set Home Assistant uses. @formatjs/intl-utils handles internationalisation, and fecha is a date library.

TypeScript 5.8.3 is a runtime dependency rather than a dev dependency, which is unusual and is the standard pattern for shipping a library whose consumers compile it, though here the shipped artefact is the bundled file. The dev dependencies are the Rollup plugin set: node-resolve, commonjs, typescript, terser, json, alias, and dynamic-import-vars, plus rollup-plugin-visualizer for bundle analysis, and Parcel with its transformer-inline-string, which is present for handling inlined strings in the build.

On the ESLint side there is a .eslintrc.js at the top level, a .prettierrc, a .gitignore and a scripts/ directory, and a hacs.json file, which is the metadata HACS reads to present the card in its store. The dist/ directory is committed, which is the standard practice for a custom card distributed as a downloadable file, and it is also why the browser caching issue exists.

Where scheduler-card is the wrong tool

There are three limits, and the first one is the dependency on the second component.

You cannot use this card alone. The README says it plainly, twice, and the installation instructions repeat it. If you install only the card, either the Lovelace resource fails to load or the card renders with nothing to configure, and the README's own note about the www folder warns of a neighbouring failure mode where the installation succeeds but fails silently. A user who has installed only the frontend piece will spend time debugging the front end for a problem that is in the back end.

The second is that the scheduler component is where the actual scheduling semantics live, and this repository does not document them. The card's own options panel covers conditions, periods and behaviour after completion, and the Customize section covers the action variables, but the scheduling behaviour itself belongs to the component, not to this card. The card is the interface; the component is the specification.

The third is that this is one card in a large ecosystem of Home Assistant cards, and the Lovelace resource model has real consequences. The card has to be registered as a resource, it lives under www/ rather than in a config directory where a package manager would put it, and browsers cache it aggressively enough that the maintainer has to document a query string trick to force a refresh. That is the cost of the Lovelace custom card model in general, not a defect here, but it is a real difference from a Home Assistant integration, which is installed through the UI and updated with Home Assistant itself.

There is also a licensing point to check, and it is worth checking rather than assuming. One declaration names GPL-3.0, while the package.json declares the licence field as ISC, and the repository has a LICENSE file at the top level. The two declarations do not match, and for a project distributed as a browser bundle that people copy into their Home Assistant configuration, the terms matter. Read the LICENSE file and establish which terms apply to the code you are running and to anything you modify.

Editorial conclusion

Adopt scheduler-card if you run Home Assistant, want a graphical way to create and edit device schedules, and you already have, or will install, the separate scheduler custom component that does the actual scheduling. Do not adopt it as a replacement for Home Assistant's own time trigger, since it depends on that component and cannot act alone. Verify first that the www folder exists in your configuration directory before installing through HACS, since the README notes the installation will otherwise succeed but fail silently, and that the licence file in the repository matches the ISC field in package.json.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. nielsfaber/scheduler-card on GitHub
4. README
5. Releases