Add the time domain (time entities) to the list of standard configuration actions #808

pdcastro · 2024-03-25T22:19:41Z

This PR addresses issue #807. Please check that issue’s description for background information (use cases, justification).

Screenshots of what this PR achieves

Scheduler Card Configuration — Included Entities
Before this PR, time entities were not listed — there wasn’t a ‘time’ row in the screenshot below. After this PR, the ‘time’ row is listed, allowing time entities to be selected.

New Schedule - Entity Editor - Time Entity

New Schedule - Time Editor - Time Entity - Set Value

New Schedule - Time Editor - Time Entity - Make Scheme

Scheduler Card - Configured Entities - Time Entity

pdcastro · 2024-03-25T22:36:34Z

src/editor/scheduler-editor-time.ts

+    let timePickerHeader = '';
+    if (!this.timeslots) {
+      timePickerHeader = this.hass.localize('ui.dialogs.helper_settings.input_datetime.time');
+      if (this.entities?.[0].id.startsWith('time'))
+        timePickerHeader += ` (${localize('ui.panel.common.title', getLocale(this.hass))})`;
+    }


This timePickerHeader logic changes the section title from "TIME" to "TIME (SCHEDULER)" to help disambiguate between the two time sections — see red arrows in the screenshots below. This only applies when the selected entity is a time entity. If the user selected a different entity, say switch, the section title remains as before, i.e. simply "TIME".

Without the timePickerHeader logic:

With the timePickerHeader logic:

pdcastro · 2024-03-25T22:39:11Z

src/editor/scheduler-editor-time.ts

+          let header: string = variable.name || PrettyPrintName(field);
+          if (header.toLowerCase() === 'time') {
+            const entity = this.entities?.[0];
+            if (entity) header += ` (${PrettyPrintName(this.getEntityName(entity))})`;
+          }


This header logic changes the section title from "TIME" to "TIME (<entity name>)" to help disambiguate between the two time sections — see red arrows in the screenshots below. This only applies when the selected entity is a time entity. If the user selected a different entity, say switch, the section title remains as before (not including the entity name).

Without the header logic:

With the header logic:

pdcastro · 2024-03-25T22:46:38Z

src/components/variable-picker.ts

+    return html`
+      <ha-time-input
+        .enableSecond=${variable.enable_seconds}
+        .value=${value}
+        .locale=${this.hass.locale}
+        @value-changed=${this.listVariableUpdated}
+      ></ha-time-input>
+      <div class="key">${variable.enable_seconds ? 'Hours:Minutes:Seconds' : 'Hours:Minutes'}</div>
+    `;


The choice of the <ha-time-input> component can be argued. My reasoning for not using the <time-picker> component (which is used to set / edit the scheduler time) was simply to visually differentiate between the two time sections (see other comments). Users would be used to the <time-picker> component for setting the scheduler time and they would also be used to the <ha-time-input> component for editing HA time entities.

nielsfaber · 2024-03-26T20:06:50Z

I'm impressed with your efforts, the PR looks pretty good to me.
Sadly, the fact that you had to touch 20+ files to implement this feature only emphasises that the code is in need of optimisation.
As said, I am currently working on a rewrite of the code.
For this reason I think we have to park this PR for a while (I am not adding new features to the current code base anymore).
I am hopeful that it can be 'ported' to the new version without too much extra effort.
The new version should be 'feature-complete' within the next month, we can continue from there.
A general comment (for future contribution): I think it's helpful to open a feature request to discuss/align on a new feature before starting on the implementation. This reduces the risk of writing code that may not be adopted in the project.
My apologies for putting your contribution on hold.

pdcastro · 2024-03-26T22:21:18Z

[…] For this reason I think we have to park this PR for a while […]

That’s all right. I take comfort in knowing that you seem happy to incorporate this feature in principle. I had originally planned to discuss it before any implementation, 😇 and I thought it should include “photoshopping” what the time editor screen might look like. But then I thought: “Why don’t just do a quick hack of the time editor screen on its own, just to load a <ha-time-input> component there?” “Would that even be possible?” “Do custom cards have the ability of instantiating just any HA frontend component?” ”How would I even go about hacking it?” I actually had so many questions as I had never worked on a frontend project before, and I was really curious. So I just started playing with the code a bit, not planning on any large implementation, but each small step led to more questions and further small steps to answer those questions... “Now I’ve come this far, might as well finish it!” I had no idea that the final solution would involve touching so many files, honestly I initially thought I’d have to change “just a few HTML templates” — because that’s what a custom card is, right? 😄 How hard could that possibly be? 😅

By the way, I now appreciate so much more the effort that you put in creating this custom card. There is so much logic in it that end users are just oblivious to. On behalf of clueless end users, thank you! 🙏

Meanwhile, I am already using this feature through my fork of your repo, so in any event I am already benefiting from it. 🙂

github-actions · 2024-04-26T00:43:37Z