The current Color Picker will close the moment you select a color, or (obviously) if you click/tap Apply (with or without the “Apply on change” option selected).
Could this behavior be modified so that the color picker remains open until Apply is tapped? My reason in asking is that I often cannot know precisely which color or brightness I want to set a currently-on light to, meaning I’d have to revisit the Color Picker a dozen times.
Whereas if it remained open, I could efficiently tweak the Color controls until I’m satisfied, and click Apply. Maybe “Apply” should become “Done”?
I’m back to lend some clarity, but first some baseline observations:
- “Apply on Change” resets itself to checked after each use.
- Clicking the “Apply” button updates device and dismisses dialogue.
- “Apply on Change” (when checked) does the same.
To offer users the opportunity to “tweak” color and brightness settings (or any pop-up dialogue where “Apply on Change” will tend to be the default), could the Apply button simply update the device attribute but leave the dialogue open whenever the “Apply on Change” checkbox is unchecked?
Just so I’m clear, I don’t need the device to continuously update as I fiddle with the control(s). (Not looking to raise bandwidth here.) I can hit APPLY as often as needed. It’s more about not closing the dialogue if so desired.
Grant replied: “Needs a bit of thought before changes are made, but 100% onboard with this as its a good observation and idea.”
While playing around with Edit > Styles > Tile Overrides, I got to wondering whether it’s possible to define multiple possible match values using “Contains”.
I’m guessing the answer is “Nope” but really didn’t wanna thrash my hub by pushing buttons unnecessarily just for testing purposes. Figured I’d ask here instead.
Grant replied: “Not with Contains, but I can easily add AnyOf that will check for any of the values separated by a comma. Will add to the list of enhancements”
Wouldn’t it be cool if a tile could briefly signal a changed value (or other condition) by showing a color glow around its border?
I picture the glow happening either momentarily (pulse), ongoing (flash) --both with adjustable intervals – steady on, or alternatively turned off in response to Properties.
Kind of useful as a “Don’t forget to lock the door” reminder or “Press to play message” notification. Lots of uses!
Grant replied: “I’d rather do this as a Tile Override - where you decide the override (icon, style etc) and the override condition is just Value Changes”
There are times you might prefer that a Tile remain in its precise location on the grid regardless, such as Dash or Label tiles.
Could the Edit fly-out menu include Lock/Unlock to electively render a Tile ineligible for “moving out of the way” as others get shuffled around?
Took me a couple extra days to finally get my thinking straight on this request, which I believe makes practical sense:
Q: Can we get ‘Name’ (device attribute) as another option under Label Override?
You will ask:
Q: Why does this matter?
A: Because if I change the device name on HE, it would be nice to have it auto-update in HV.
Q: But in day-to-day use…?
A: You already do this with Lower Right and Lower Left when a new Tile gets created. I’m simply suggesting the “Override”/default for Top be treated similarly.
Q: Any edge cases to consider?
A: Maybe someone wants to show Device Name on a different Label. This makes the swap easy and consistent.
This topic relates indirectly to [1.2.9] Feature enhancement: Allow substitute text as new Label Override method](https://community.hubivue.com/t/1-2-9-feature-enhancement-allow-substitute-text-as-new-label-override-method/295).
Grant replied: “Have added to the list of future enhancements.”
I hope this constitutes a single request, although admittedly it has three distinct parts:
Just as one does in Google Photos and other environments where you have a lot of distinct objects to act upon, I’d love the ability to “Select” a Tile, and then select several others, before proceeding with an Edit that affects them all.
For instance, if I could select a Tile along with several of its neighbors, the MOVE action could then be used to move them all at once.
Similarly, if I could “lock” two or more tiles together, such that they move as a single unit when selected – and can later be ungrouped, if desired – it would make large-scale rearrangement of one’s Dash all the easier. This is the kind of feature one finds in Google Draw and other drawing apps where multiple small components get “Grouped” or assembled as a unit, forming part of a larger layout.
Finally, if we had configurable rectangular templates onto which Tiles could be attached – almost like parking them into a sub-grid contained by this new object – then the act of selecting/grouping those empaneled tiles easier still. In this way, you could construct a dash-within-a-dash, with a consistent visual look and feel for each of the Panels.
Whether the Panels themselves would be limited to custom colors, shapes and borders only, or might also be granted their own Labels and conditional styling remains open for discussion. But I doubt Panels would have any Actions associated with them, as they are not in themselves clickable entities.
This might not make much practical sense, but imagine if you could glance at your “Default” dash and see whether a light has been left on somewhere in the house, without clicking through to each “Room”.
If the “Room” tiles themselves could be assigned to reflect the status of a Room Lighting app’s Activator (dimmer / switch / etc.) – maybe even function (if selected) as a means of activating said Activator (think: I can “tap” the entire Dining Room “On” or “Off” using the “Dining Room” tile right on the main page … this could be a step too far?).
At base, I’m imagining just a quick visual “status check” on individual rooms, using the Room tiles themselves.
IMPORTANT: But I’m not suggesting that additional logic be generated within the hubiVue app just to bring about that functionality. I assert that should remain the purview of RL Activators (particularly, those set to “Indicate” in the manner a users prefers) … and that the RLA could somehow then be “assigned” to the Room tile.
Grant replied: "All very possible - just requires some thinking about what is the best/most sensible approach to achieving this - be that indicator or action to turn off lights etc.
Adding the logic to hubiVue to check the insides of each room isn’t too complex (as not everyone will want or can be bothered to setup the RLA correctly etc).
Giving this some thought and will circle back as ideas come to mind."
And add images to pick list in Tile > Edit > Styles area.
Currently, unless I’m missing something obvious, I believe “Tile Style Override” only allows you to alter a few styling elements, as shown…
…but not the content of the Tile’s Labels.
I feel this would be a useful addition at times, for example:
For a tile linked to a Presence device, its customary values will be either “Present” or “Not Present”, and these are tested against with the various conditionals offered, e.g.:
IF presence == ‘not present’ THEN style → ‘Alert’, or icon → ‘Rabbit’, etc.).
I’d like to take that a step further so that this, too, is an option:
IF presence == ‘not present’ (which gets truncated inside a 1x1 tile, anyway)
THEN middle label → ‘Away’
tl;dr Sometimes the default alphanumeric values spit out by HE don’t match the meaning or aesthetic we prefer on our dashboards.
Grant replied: “Right you are! Something to consider.”
IF (condition) THEN image → bunny.jpg
I realize this potentially poses a bandwidth and/or caching issue, so would understand if a strict limit on image size/quantity/swap rate were imposed.
What I mean here would be the ability to add a Dash to your own account once someone sends you its invite Token. (Could be in addition to the Login screen method of accessing it.) Picture doing Edit > Pencil > [New] > (from Token) > Enter Token… > OK.
This would allow you to semi-permanently have the Dash within one or two clicks without having to Log out. Kind of like when someone shares a Google Docs file with you and it remains accessible via Shared.
Increasingly, text-based things like messaging, system reports, parsed JSON, status annunciators and what-not are entering the Hubitat ecosystem. I think it would be nice if we had a straightforward way for multi-line** text to be displayed within a Variable Tile…
…instead of the text just being truncated after the first several characters, as shown.
**Multi-line will mean different things to different users and in different environments. Since we’re playing with Monopoly money, here’s the stretch goal I’m laying down… It would be sweet if linebreaks could be introduced in a variety of ways (either automagically or by a user overriding that by indicating a specific delimiter character), such as:
- the traditional endline \n and newline \l RegEx control symbols;
- the break <br> and paragraph <p> tags familiar to HTML coders;
- inline carriage returns (also known as CTRL-L in the olden days);
- user-specified delimiter character (e.g. pipe |, caret ^ or whatever);
- absent any of these, simple word-wrapping at whitespace, if any.
UPDATE: Took me a minute, but I managed to ascertain that such Tiles already DO permit multiple lines, so long as they are properly formatted using hard carriage returns:
That’s actually one of the tougher characters to introduce, since it requires setting a local RM variable first and then copying that value into a Hub Variable for eventual use with HV. The delimiter approach and/or acceptance of keywords like <br> would ease that hurdle.
- Add Markdown syntax interpreter (like this Forum has)?
e.g. So italics and bold and easy tables like…
Grant replied: “Easy to add a ‘filter X into a carriage return’ option. All possible. Markdown is how What’s New is created.”
Does hubiVue offer a style of Tile that looks and behaves like the one shown at left?
SLIDER: I’d like to be able to visually present things like Volume, Dimmer Level and other discrete values with a (optionally user-defined) minimum and maximum value. Bonus points for being able to choose colors, styles, overrides, tick shapes, and/or (most important of all) orientation.
GAUGE: Think clock face, tachometer, pressure dial, etc. with configurable range, ticks, colors, and so on.
Grant replied: “Not yet, but can add this without too much hassle. Adding it to the list.”
I’m not talking here about simply making a Copy of a Dash tile (which simply navigates to the same dashboard as before)…
… I’m wondering if we can create a verbatim clone of an entire dashboard layout. After which we might restyle, rename or reassign items as necessary.
Grant replied: “This will be added to the enhancement list.”
What if there were a special app (let’s call it hubiVue Helper™ All Rights Reserved (c) 2022 LibraSun) that one would install on the controller that could augment/enhance/enable certain functions and features that a Maker API-connected appliance like hubiVue may not otherwise enjoy.
Think of it as “the inside man” handing out goodies through the window, as it were, such like:
- A “round-trip in ms” gauge whereby hubiVue could ‘Ping’ the hub and get back a timed response, to assess overall bandwidth and speed;
- Maintaining the ‘State’ of certain assigned devices across reboots and reconnects;
- Access to otherwise-hidden on-board parameters (Logs? File Manager? Childless apps? Pause/resume rules? Z-Wave details?) that Maker API doesn’t share natively;
- Specifically, user preferences and location/regional info like F / C, Time Zone, Hub Name, etc.
- “Server-side themes” (yes, having hubiVue skin items change/react based on hub conditions**!), or even ss-scripting, but that’s surely too advanced a concept.
Anyhoo, always looking for the ultimate value-add, so . . . discuss?
**example of hub activity one might wish to see on a Dashboard = when an Update becomes available, but you don’t see the Notification.
Back-burner thought: In the olden days, Vera/ezlo’s implementation of “the Alexa skill” introduced a tabular view of all devices intended to be passed to Alexa. The purpose of the table was to allow you one last chance to rename each device, not unlike (but pretty clearly not the same as) how we can give Devices a Label in HE that overrides the name given at inclusion.
I think such a facility would greatly enhance hubiVue if implemented on the “Helper” app side. Users would be allowed to give each included Device a “hubiVue Label” which would automatically populate (or, only when Override > Top Label > Use hubiVue Label is invoked in Tile Edit mode) that tile element.
Here’s the hierarchy as well as I understand it:
Physical device included or Virtual device added
HE assigns hard-coded and obfuscated DNI for DB
HE assigns soft-coded and human-readable Dev #
Device driver assigns default Device Name
User assigns optional Device Label
hubiVue Helper lets user assign Tile Label
On [+] > Device tile add, hubiVue designer defaults to Tile Label value (if present)
On Tile > Edit > Top Label > Override > designer offers  HH Tile Label along with other drop-down options
Why is this even a thing?
Well, back in the early Vera/Alexa days, the manual renaming feature offered (a) a way to avoid naming conflicts (mainly) with other voice-assistant enabled ecosystems/Skills; (b) shorter, voice-command friendly renditions of devices with long or cryptic names (common); and, (c) the last chance to remove disallowed characters (e.g. underscore or apostrophe) that Amazon doesn’t want in Alexa’s list of Smart Home devices (rare).
With what I’m recommending here, for hubiVue, it’s all about maintaining “state” across multiple installations or wipes/restarts of hubiVue, allowing a user to quickly rebuild his/her entire Dash structure with names and perhaps other considerations intact.
Grant replied: "Absolutely agree… there is a benefit to building a HE App that does the same thing as MakerAPI but in a more efficient and dedicated way. MakerAPI is very verbose, and the payload sizes and inefficient polling of all devices (even if they don’t have anything to update) makes it a less than ideal performing integration connector, but alas it is the only one available unless one if built from scratch.
This, plus the things you mention above, are reasons why eventually a hubiVue Hub App will probably be developed at some point - not sure when, but probably when the list of enhancements to the dashboard app become less important."
(4) * Might be cool to see the Time on some of my Dashes
(3) * Heck yes, I want a Clock tile (digital and analog faces, too!)
(1) * Don’t care either way about Clock tiles
(0) * Meh, it’s not something I have much need for