I suppose the ability to just clone a template then be able to customize the clone and not the seed template?
I agree with the comments on being able to customize the template on a per tile basis. I’m using contact devices to report states of other non Z-Wave devices and it would be nice to customize the colors and icons individually to better represent what they are reporting.
More flexibility in what info is presented on a tile would also be good. So when a template is selected you can check off which data points to display. This would have to be on a per tile basis.
Since there can’t be user created templates maybe there is a way to have a universal template that contains every typical parameter. Then with the above noted ability to select what data it displays on a per tile basis you essentially get a custom template.
Please add support for the Fabaro Smart Implant. It’s such a great device and super tiny which is awesome for integrating into other devices.
Please add support for the EnvisaLink EyezON so we can integrate more alarm systems.
I also think you guys need to consider having a system of UI themes for dashboards that makes it easy to graphically change the dashboard to something more slick with background images and color combinations etc. Maybe even the icon sets used for templates can change unless you’ve customized them. There could even be a way to create new themes and save them and even share them with others. It’s just too time consuming and cumbersome to do currently and discourages new users when they see the slick layouts of other systems.
You guys also need to incorporate a news feed option that’s simple but good looking. Just add your source and go type of thing. Needs to be easy unlike the all the steps required to get a weather tile to display simple info.
That brings me to the weather integration. This also needs some love. It’s a lot of steps to get a pretty crappy weather display. This should be baked right in where you only need to input your zip code and you get a nice sexy tile with current weather and slick icons and then a separate tile with the week long forecast.
Finally, keep adding more devices!
I’ve been thinking more about the template question as I continue to add generic contacts to different kinds of non Z-Wave devices to report on their state. They all have to report the same way even though that’s not how the devices operate. Some of my devices use a normally open contact and some a normally closed. Therefore either state can be normal or an alarm condition. With only one type of contact temple I’m stuck with some normal states showing a red tile and some alarm states showing as grey. It defeats the purpose.
Maybe an easier short term solution would be to provide several duplicates of existing templates. Let’s say three versions of each so you would have a ‘contact 1’, ‘contact 2’, and ‘contact 3’ for example. They are all functionally the same but this gives users the opportunity to customize each one three different ways.
Maybe this is something that can even be implemented pretty swiftly as opposed to a redesign of the template system.
@patrick Love to see
- a blank icon, i.e. no icon so that a link to an image can be used
- the ability to store images directly on the HE
- the ability to change the header or footer of individual dashboard elements either in the tile editor or the json layout json
Any progress being made regarding editing or adding new templates?
Yes I agree with this. Having bought a hub recently due to the flexibility of being able to code your own apps and devices only to find this isn't possible is really frustrating.
You would think it is relatively easy to add given how they have implemented apps. I want to use hubtita as a link for all manner of things. e.g pulling in local train / bus time table alongside the weather, local traffic, health, fitness, etc.
I would like templates for AVR's to control inputs, zones, sound mode, etc. The only template currently available allows me to control volume, but that doesn't help when there are multiple things hooked up to the receiver and I need to be able to switch between inputs.
I also agree that it would be greatly appreciated if we could create our own custom templates...
Yup, just messing w/ this on a IKEA contact sensor hacked to take relay input from a current sensor on a well pump wire.
I know what closed vs open means in this case..... but not being able to turn the tile blue for other users when the well is pumping makes the dash less intuitive.
And there are other multi-sensors on the dash that I have now messed up in my experimentation cause I can't "remove & save" the template back to the default colors,
I am very impressed with Hubitat - particularly the ability to write custom applications and devices. The weak link in Hubitat seems to be the inability to customize dashboards on par with custom applications and devices. A few times now, I have authored a new device only to find the available dashboard device templates insufficient to present the new device. This situation leads to refactoring a new holistic user device into something more fragmented that the dashboard can render (e.g., instead of one user device a parent user device with multiple child devices that better correspond to available device templates).
To @patrick's (Mar '19) offer to address template gaps ...
I believe there is an interim step - short of user-provided dashboard templates - that would help significantly. Specifically, I recommend reconciling Hubitat's device capabilities with Hubitat's device templates - perhaps through small documentation tweaks. Such a reconciliation would be immediately beneficial to User device authors AND serve as a baseline for discussing new capabilities (attributes and commands) that require corresponding device templates (whomever provides these templates).
The Driver Capability List offers drill downs like capability.switchLevel, where we see the attribute level is a NUMBER and the command setLevel expects one or two NUMBERs. [The level argument is required, the duration argument is optional.]
Currently, the capability list does not indicate (but perhaps should indicate) which available Device Templates correspond to each capability.
A device template like Level (see image below) seems like a natural fit for capability.switchLevel.
In general, device template documentation does not indicate the corresponding capability(ies) (expected device attributes and commands) the template is designed to render/manage.
[Currently, the Level template is not listed on the Device Templates page; but, this is a side point.]
Through experimentation with the Level template: The template number reflects the attribute level. The up and down arrows on the template expect a single argument version of the setLevel() command - i.e., setLevel(level) as opposed to setLevel(level, duration).
The Level template includes (hard coded?) quirky behavior wherein the up/down arrows request a level that is 10 units higher or 10 units lower than the current level.
[There does not appear to be any facility for adjusting the default increment/decrement levels for the template.]
The Benefits of Reconciling Capabilities to Templates
Reconciling the Capability List to the Device Templates would clarify where there is great fit, a partial fit or a gap between the two.
By associating specific capabilities with specific templates, the dashboard editor could present a filtered list of viable device templates (i.e., Pick a Template) for a selected device (i.e., Pick a Device) based on the capabilities the device advertises.
For preceding example, reconciliation would tell us:
(1) The Level dashboard template is a partial fit for capability.switchLevel
(2) The template displays the current level attribute
(3) Devices need to include the one-argument version of the Level() command
(4) Limitations: The dashboard template will request new up/down levels with a fixed increment of 10 units.
(5) Workaround(s): A user device can (at the author's discretion) ignore the specific requested level (up 10 units or down 10 units) - for example increment by 1 or decrement by 1. A user device can enforce levels more constrained than the specification (e.g., n..m vs 0..100). The dashboard template will reflect the actual level attribute implemented by the user device.
Device Decomposition Example
Device author's can come up with an infinite list of things they would like to see in the dashboard. Here is one relatively simple example to discuss available/prospective options.
There are several posts wherein a prospective user device author wants to display a time and solicit changes from a user. He/she may begin to author a standalone user device solution like SettableTimeDevice.groovy with the expectation of locating or writing a corresponding single dashboard template - e.g., EditableTimeTemplate.
Absent the ability to write a custom dashboard template, device authors face two options.
Refactor their holistic device into a parent device with child devices that collectively better match the available dashboard templates. [See example to follow.]
Abandon writing a new user device and instead pursue a Rule Machine Global Variables (@bravenel) which includes a time (--:-- --) option which can be presented on a dashboard via a connector.
Option 1 works, but it can get ugly fast. For example: Instead of a holistic SettableTimeDevice.groovy with a single dashboard tile, the following image illustrates a refactored SettableTimeDevice.groovy (as parent device) that leverages two child devices HourSelectorDevice.groovy and MinuteSelectorDevice.groovy.
Instead of one clean tile on the Dashboard, there are four tiles:
The left-most tile operates on an instance of the parent SettableTimeDevice named 0sod. It presents the custom attribute timeTwoWays (am/pm and 24-hour).
The two middle tiles operate on instances of HourSelectorDevice.groovy and MinuteSelectorDevice.groovy, respectively. The custom devices enforce appropriate constraints on the value of the level attribute. Increment/decrement behavior are constrained to 1 for hours and 5 for minutes - overriding the default of "10 units" in the device template (see prior discussion).
The right-most tile leverages the Variable String template which passes a free-text string to the parent device via the command void setVariable(String). [The parent parses the string accepting time representations in 12 or 24 hour mode with flexibility on spaces, capitalization, etc. Note: There is no attribute whereby the device author can update the data presented in the Variable String template; so, communications is one-way from the dashboard to a device.]
Standardizing on Capabilities is a Better Option
As a step toward custom dashboard templates, there are benefits to documenting new capabilities.
Consider the existing dashboard template that displays a Rule Machine time Global Variable with a Connector.
More clearly linking device templates (like this one) to published device capabilities would give User Device authors better architectural targets.
Perhaps this template corresponds to a new, unpublished capability like capability.settableTime that expects a single String/regexp attribute time and a single command setTime(time).
A slightly improved dashboard editor would allow User device author's that implement capability.settableTime to leverage the (in this case existing) built-in device template.
Formalizing the capabilities of all existing dashboard templates - like Variable String in the prior example - would clarify the expected attributes (device to dashboard) and commands (dashboard to device) each template supports.