Ha-date-range-picker howto?

Hello everyone,

I’am trying to improve an add-on where I have to enter the time on an input-box. It’s not very efficient nor friendly.

I want to change that with a date and time picker and I saw this one < ha-date-range-picker> I guess that’s the one used for the History page.

I’am struggleing to use it maybe someone can give me a hand?

thanks in advance!

1 Like

The ha-date-range-picker is specifically for a range of dates times from a to b, but most importantly its not loaded on the dashboard, so you CAN’T use it (unless you have navigated to the history page before you visit the dashboard since its a single page app the element will still be loaded)

There’s an time selector for selecting time, and a datetime selector for selecting dates + time
you can load any of the built in selectors from Selectors - Home Assistant by passing a struct into ha-form.

            <ha-form
                .hass=${this.hass}
                .data=${this._config}  <!-- needs to be the object that has my_time -->
                .schema=${[{name: "my_time", selector: { time: {} }}]}
                .computeLabel=${this._computeLabel}
                @value-changed=${this._valueChanged} <!-- will return mutated object passed in "data" as ev.target.value -->
            ></ha-form>

if you specifically need the ha-date-range-picker this is how you “would” use it, provided you could make sure its loaded. There are probably some hacks you can use to force that component to load, or manually load it, or duplicated it for your component and rename it.

            <ha-date-range-picker
                .hass=${this.hass}
                ?disabled=${false}
                .startDate=${new Date()}
                .endDate=${new Date()}
                .ranges=${{
                    // key is name that appears in  list, array is start/end date time obj. Omit this whole object to not see that list of shortcuts
                    "today": [new Date(), new Date()]
                }}
                @change=${
                     //bubbles from the inner date-range-picker control that ha-date-range-picker wraps, value is {startDate: Date, endDate: date}
                    this._dateRangeChanged
                }
            ></ha-date-range-picker>

notice that the customElement is not defined but after I navigate to the history page, it is loaded.

image

The built in components of home assistant aren’t really intended to be used by custom cards, but most of the developers certainly use the selectors for ha-form. If ha-form doesn’t happen to be loaded you can force it to load with the hack

    if (!customElements.get("ha-form")) {
        (customElements.get("hui-button-card") as any)?.getConfigElement();
    }
    //^^^ borrowed from lovelace-mushroom.

But again, technically they don’t provide an api to load the elements you might need from the UI, you can just use them if you know where to find them.

That’s kinda hacky and brittle (read - prone to breaking) though. If the HA devs change anything about it, your component is going to break.

There are lots of nice and simple free JS date/time pickers out there you can use without depending on undocumented HA stuff. Or you can code your own, it’s not exactly rocket science.

absolutely hacky, but most of the community does it. its a lose-lose.
I’m not suggesting anyone do it, just explaining to the OP why they are probably having a hard time with it.

The custom card development docs are basically, hello world + an example and they release you into the world. No one really knows the best practice.

Yeah the custom frontend component development docs are terrible. When I first started my custom component I was really surprised by the lack of docs or best practices in general, even for an open source project. After trawling through a ton of other custom and core card sources and witnessing coding practices that made me want to rip my eyes out - it seemed like everybody was just copying everybody elses super hacky stuff - I decided to keep the dependencies on HA to an absolute minimum. 1.5 years later the only two breakages I ever got were due to changes in the REST and later websocket APIs and they were easily fixed.

Better pull in dependencies I control than rely on HA’s undocumented stuff that can break on a whim outside of my control. Not a good thing for consistent UI/UX though.