The versatile custom Swiss Army Knife card for Home Assistant allows you to create your unique visualization using several graphical tools, styling options and animations.
The bar tool is actually a sparkline variant: it displays only the bar values, nothing more.
Adding min/max value labels (positioning is free) would add value to the chart.
Enabling min and max labels using a flag, or only their relative position.
Position is relative to center of chart. This makes it possible to move the chart, and keep the labels in place.
Assuming:
min label at lower left corner:
Update @2020.11.10:
The number of decimals is determined by the decimals value for the entity
Styling is done in the usual way: using a style.
For this, the styles section should be extended to be able to format the bar and the labels. Labels can be styled at once, or individually. This means that text-anchor can be set (start, middle, end), which might come in handy!
styles:
bar:
<values>
label:
<values>
label_min:
<values>
label_max:
<values>
label_ave:
<values>etc.
The fill and stroke flags in the colorstops/colorlist are not yet supported by the segmented arc: the segarc always uses the color to fill a segment.
It would be nice if these colorstop flags are supported, as it makes the segarc consistent with other tools that do support these flags.
Note:
Segemented arc was already implemented before these colorstop flags where introduced.
Since issue #48 is created/updated, there are two - non breaking - implementations:
Currently there are two types of coordinates used: one for tools and one for assemblies (of tools):
At first, percentages, ie relative coordinates seemed the best way to position tools and groups/assemblies. But after creating a lot of examples and building the software, it seems not the best solution:
Use the same - default svg viewbox - to specify positions.
The group will use the same default svg viewbox 0..100 grid (svg is 200x200) reference.
This means that in a 2/1 viewbox (svg 400x200), the group grid range is 0..200x0..100.
Changes are not very difficult...
After using the slider on many views, the incidents where the slider is touched unintentionally is growing 😄
Setting the brightness of a light is not a problem, but changing the thermostat to 23 degrees Celsius is not nice!
Preventing such unintentional interactions would be a nice feature.
The nicest solution would be a configurable lock of the thumb of the slider where the user should first unlock the slider, before he/she can interact with it.
This solution could be implemented as follows:
There are enough javascript examples on the internet to recognize a swipe on an element:
Enable only the thumb for touch input. In that case most touches don't do anything, as the user has to move the thumb to the required position.
some setting could be:
input: slider / thumbThe touch area should adapt to the thumb. Default is slider...
If already using the tap_action dragging, then only the thumb should respond. If there are two actions, also a click, then clicking anywhere on the slider also works...
So the user can determine how the slider wil interact...
Integrate LGTM into the build / PR pipeline.
Can be done only after public release. The repository should be public, and not private.
Add a list of custom fields to the sak card which can be set using JS Templates.
Users can make there own calculations and evaluations, and use those custom fields in tools, just as the standard entities.
Maybe this can also be used in the animations part. No idea...
Practical things that can be solved with this:
I have no idea how to implement this, but I know that it is possible.
Should look at Home Assistant source code & custom cards, as some of those use javascript expressions to evaluate or calculate sensor and style values.
Will be a lot of javascript fu I have to learn...
I assume the expression can use:
A small test seems to work for getting brightness from a light.
Using a new variable that is calculated using javascript.
Now the point is how to exactly implement this.
custom_value: >
[[[
if (typeof(entity) === 'undefined') return;
if ('brightness' in entity.attributes)
{
if (entity.attributes
&& (entity.attributes.brightness <= 255)) {
var bri = Math.round(entity.attributes.brightness / 2.55);
return (bri ? bri : '0') + '%';
}
}
]]] // testing calculated value
if (this.config.custom_value) {
const someValue = new Function('states', 'entity', 'user', 'hass', `'use strict'; ${this.config.custom_value.slice(4, -4)}`).call(
this,
this._parent._hass.states,
this._parent.entities[this.config.entity_index],
this._parent._hass.user,
this._parent._hass,
);
console.log("BaseTool::set value contains CUSTOM VALUE", this.config.custom_value, someValue);
localState = someValue;
}If this can be defined as a real entity, it can be used as a normal entity, so with name, units, etc.
Used within a single card, or toolset?? Putting it in a toolset makes it re-usable, User can use toolset template and get the custom variables for free. Doesn't have to declare them if toolset (template) is used in a card. Much simpler!
custom_entities:
- entity: brightness
value: >
[[[
if (typeof(entity) === 'undefined') return;
if ('brightness' in entity.attributes)
{
if (entity.attributes
&& (entity.attributes.brightness <= 255)) {
var bri = Math.round(entity.attributes.brightness / 2.55);
return (bri ? bri : '0') + '%';
}
}
]]]
name: "bright it is"
unit_of_measurement: "%"
icon: mdi:brightness
trigger_entity: 0 #the defined entity that triggers this evaluation. Good for performance?!?!?!?!Add to toolset which calculates these values on every update, and sets the value for the tools that are using that special custom value?? Or is there a better way??
While observing the animation on the segmented-arc, it appears that the gap between the arcs is partially filled while going from one arc part to the next arc part and vice-versa.
It is not that the full gap is filled temporarily, but just a part of the gap. Must be some calculation going wrong.
Will be a difficult thing to fix, I'm afraid...
None.
Add generic polygon tool. This tool can generate multiple kinds of polygons (regular ones!) using Schläfli symbol to describe and generate the regular polygons:
These are the possible figures made by Ana Tudor (https://codepen.io/thebabydino/pen/WbjdRq):
Integrate the function into a tool class, and ready!
Using this yaml definition:
layout:
toolsets:
- toolset: polytest
position:
cx: 100
cy: 50
tools:
- type: regpoly
cx: 0
cy: 50
radius: 45
side_count: 6
side_skip: 1
styles:
regpoly:
fill-rule: nonzero
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
transform: skewX(30deg)
- type: regpoly
cx: 0
cy: 50
radius: 35
side_count: 6
side_skip: 1
styles:
regpoly:
fill-rule: nonzero
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
fill: gray
stroke: gray
opacity: 0.05
filter: url(#nm-2)
- type: regpoly
cx: 0
cy: 50
radius: 25
side_count: 6
side_skip: 1
styles:
regpoly:
fill-rule: nonzero
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
opacity: 0.9
filter: url(#nm-2)
- type: regpoly
cx: 0
cy: 50
radius: 15
side_count: 18
side_skip: 6
styles:
regpoly:
fill-rule: nonzero
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
opacity: 0.5
filter: url(#nm-2)
####
- type: regpoly
cx: 100
cy: 50
radius: 45
side_count: 6
side_skip: 1
styles:
regpoly:
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
- type: regpoly
cx: 100
cy: 50
radius: 45
side_count: 6
side_skip: 2
styles:
regpoly:
fill-rule: nonzero
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
opacity: 0.3
filter: url(#nm-2)
- type: regpoly
cx: 100
cy: 50
radius: 35
side_count: 6
side_skip: 2
styles:
regpoly:
fill-rule: nonzero
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
opacity: 0.3
filter: url(#nm-2)
- type: regpoly
cx: 100
cy: 50
radius: 25
side_count: 6
side_skip: 2
styles:
regpoly:
fill-rule: nonzero
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
opacity: 0.3
# filter: url(#nm-1-reverse)
filter: url(#nm-2)
- type: regpoly
cx: 100
cy: 50
radius: 15
side_count: 6
side_skip: 2
styles:
regpoly:
fill-rule: nonzero
fill: var(--primary-background-color)
stroke: var(--primary-background-color)
opacity: 0.3
filter: url(#nm-2)
Add colorstops, colorstopgradients and linear gradients to the segmented-arc, just as the horse-shoe already is capable of.
This will be a lot of work, as you can also color the scale with this.
ColorList
Colorstop
Colorstop, segmentcolor = curvalue
Colorstop gradients (single color displayed!)
SimpleGradient (single color displayed!)
Take the horseshoe as an example, but also check other sources for examples around this. Maybe there are better and easier solutions as the segmented-arc is completely different implemented compared to the horseshoe.
The segmented arc is constructed using separate path's for each segment. This probably means you can't use any gradient solutions that exactly follow the path:
One alternative to a full gradient are segmented gradients as shown below in the third arc (CPU 31 %):
And with the scale added, and filled using the same color list:
In this case a list of 10 colors is defined in the segmented arc with also 10 segments (must be changed, colorlist defines number of segments) for example.
Each segment gets its own 'fixed' color. Depending on the chosen colorlist, this can look like a nice gradient...
2020.10.13:
First results with some hacking in the creation and rendering of the segmented arc with a colorstop:
Number of segments is the number of colors in the colorlist. Simple.
The full arc (ie all segments) get the color according to the colorstop. This requires rewriting of the all the segments if a new colorstop is reached or, and that is easier, setting the fill color to the colorstop value.
When using a colorstop list for the creation of the segments, each segment can have its own color. This might already be usable for CPU load, temperature, battery percentage, disk/ram percentage, etc.
In this case the segments can be of different size. Unknown if current implementation can handle this.
But using a separate color for each segment is no problem, as the fill color can be specified using javascript.
Example:
Segment value ranges are
Depending on the size of the full segmented arc (degrees), these segments can be calculated.
Say the arc is 90 degrees, then the segments are:
When using this option, the scale will have the colors according to the colorstops.
If we use a separate structure under segments for each style, then there is a 1:1 link between them
segments:
fixedcolor:
dash: 36
gap: 1
color: 'red'segments:
colorlist:
colors:
- color1
- color2
- color3
gap: 1segments:
colorstops:
colors:
- 00: color1
- 40: color2
- 80: color3
gap: 1segments:
simplegradient:
colors:
- color1
- color2
dash: 10 (degrees) OR count: 10 (nr of segments)
gap: 1// als je ook een colorstop list als segmenten wilt laten zien, dan zul
// je bijv. net als d3 een lijst van segmentgroottes moeten opbouwen.
// standaard dus [20,20,20,15] bijv. zoals in de for loop al gebeurd, maar dan in een array.
// dan dat array laten plotten met gegevens.
//
// dan kun je ook van de colorstop een array maken [40,20,10] bijv. voor kleuren groen, geel, rood bijv.
// dan kun je een schaal neerzetten en zien hoever de waarde eigenlijk is. al bijna in het rood bijv.
SAK uses a very compact colorstop/colorlist definition. That definition is inherited from the Flexible Horse Shoe custom card.
Other cards use a more verbose implementation.
The SAK implementation (coming from FH):
colorstops:
fill: true
colors:
0: '#A8E05F'
51: '#FDD74B'
101: '#FE9B57'
151: '#FE6A69'
201: '#A97ABC'
301: '#A87383'This is very compact and easy to understand!
The initial idea was to change this definition, but that is a big breaking change and requires changing all the existing views and examples.
Additionally: it hinders the quick release of the public release candidate.
So, the suggested solution is one that is listed below and used for the lines tool (see issue #55 ), but instead of changing the current colorstop and colorlist types, these extended definitions are implemented in the colorstopex and colorlistex types!
Meaning:
Merging animations doesn't seem to work. See also #41
This happens only with the switch tool, as this one defines default animations.
Problem is caused by:
This problem can be solved at two locations:
There is no way yet to display random text. It was in the flexible horeseshoe card.
So add this tool and see what functionality can be added to this tool to make it nice:
Look here, https://www.hongkiat.com/blog/scalable-vector-graphics-text/ for examples:
stroke and setting fill to none)Shouldsupport inline styling also, with <tspan> elements as implementation?
And of course: the delta y, to move the next line below the current line. Always in em units.
tool:
type: text
lines:
line1:
- content: "this is a test"
line2
- dy: 1.2
- content: "another line"
- content: "and this is on the same line"
- content: ", but how would I style each part of this line???"
line3
- path: "d = ....."
- content: "this is a test on a path"
styles:
lines:
default:
font: xyza;
line1:
font: xyza;
line2:
font: xyzb;
line3:
font: xyzc;
text-size: 845739;
<for second part of the line ??????? How ???????>In other words: a line is always an array of tspans. Styling works also: use an array. This conflicts with other tools: styling is NOT an array, but a map. Is inconsistent. Maybe things like line1.1, line1.2 for different lines of content??
If templates are implemented, and thus toolsets can be re-used, it would be nice if the toolset could be scaled by a certain percentage.
SVG support scaling, although you have to pay attention to the coordinate system: (0,0) is the upper left corner, and not the center of the svg!
Additional info:
This also means that the toolset must be configured in the tools list. This is now a list of tools, and the group properties (xpos, ypos, scale etc.) are 'injected' into the separate tool/widget.
However, to use the svg feature to scale and translate the whole toolset, the toolset must return in the structure of the tools/widgets:
Each toolset is drawn within an svg group <g> ...tools... </g>
Using a hack to get a <g> extra in a toolset, I can scale/transform/skew the group using the Chrome inspector:
After some hacking, two versions are required: one for Safari and one for other browser 😬
Would I have expected something else...
Both versions are not yet fully consistent, but that is something for later...
Scaling & rotating seems to work, although rotating is different on Safari and other browsers. Will be fixed later. Scaling is the most important feature. Rotating is more a gimmick...
Big things are underway for the SVG engine in Safari that should solve ALL problems!
Januari 19, 2023: Status of the new SVG engine in WebKit
Since late 2019, Igalia has been working on a new SVG engine, dubbed Layer-Based SVG Engine (LBSE), that will unify the HTML/SVG rendering pipelines in WebCore. This will resolve long-standing design issues of the “legacy” SVG engine and unlock a bunch of new exciting possibilities for Web developers to get creative with SVG. Hardware-accelerated compositing, driven by CSS transform animations, 3D perspective transformations for arbitrary SVG elements, CSS z-index support for all SVG graphics elements, and proper coverage rectangle computations and repaints are just a few highlights of the capabilities the future SVG engine will offer.
In this article, an overview is given about the problems that LBSE aims to solve, and the importance of a performant, well-integrated SVG engine especially for the embedded market. Finally, the current upstreaming status is summarized including an outlook for the year 2023.
If this change lands in Safari (maybe 17.x at the end of this year??), this means:
Rendering icons. must calculate position on client window
2020.10.22. Discord via Bram Kragten.
Icons are async loaded. This might be the problem with Safari: a not loaded icon can't be calculated.
Testing shows that after the third render, the icon path can be queried for the path.
Possible Solution:
This should mean that svg stacking is working, scaling is working, and that the icon is not in front anymore of a slider or anything else that should be in front of the icon!!!!
Could it be possible to simply use this: https://www.sitepoint.com/how-to-translate-from-dom-to-svg-coordinates-and-back-again/ to get the Safari client coordiantes. Already used for clicks in slider, so use also for this stuff to place icon not on svg coordinates, but xlated to client coords?? Or are these the whole screen, and not the card size coordinates????
use other object, circle or rect behind icon. change color and icon is rendered.
Getting fontsize. NOw using 12
const fontSize = window.getComputedStyle(el).fontSizeSee previous solution for foreignObject. This could also solve this issue I assume
If an animation is stopped/removed on for example an icon, Safari remembers the current position of the icon, where other browsers reset the icon position to the start.
Add a basic switch tool as a very compact button to switch and show on/off values.
This can also be done using existing tools and adding animations depending on the on/off state like `transform: translateX()' to move the thumb, but it is not very user friendly.
The solution uses standard svg objects, and a predefined animation:
This means that one can also style rectangle tracks and thumbs. Default is round as the default switch.
on and off to move the thumb and switch the color for the track and thumb.If a user wants to change the styling and more, he/she should define the full animation to overwrite the default animation.
There is still a bug in Merge.mergeDeep() which simply concatenates arrays, ie also animations. And the animations stop when a match is found, ie the first animation in the array...
This can be solved either by:
The tap_action is currently defined under the entities section of the card. This works, but causes some problems for tools attached to these entities (using entity_index: ), but wanting different actions when clicking the tool.
Currently this is solved by using the same entity more than once.
By moving the actions/tap_action to the tool, this problem disappears and makes it very explicit what action a tool results in.
# ------------------------------------------------------------
- type: circle
entity_index: 0
#
# Circle is used as button to switch light on/off
#
user_actions:
tap_action:
haptic: light
actions:
- action: call-service
service: light.toggleClimate example
- type: slider
entity_index: 1
#
# Slider only specifies tap_action in this case. Dragging
# does not imply any action.
#
user_actions:
tap_action:
haptic: light
actions:
- action: call-service
service: climate.set_temperature
parameter: temperature
service_data:
# Override entity_id. Otherwise entity_index is used...
entity_id: climate.calentaSlider with both a click and a drag action.
Slider without a click action only responds to the dragging of the thumb.
- type: slider
entity_index: 0
#
# Slider is used to set brightness percentage
#
user_actions:
drag_action:
update_interval: 200
haptic: selection
actions:
- action: call-service
service: light.turn_on
parameter: brightness_pct
tap_action:
haptic: light
actions:
- action: call-service
service: light.turn_on
parameter: brightness_pctThe most logical place when moving this to the tools.
The click handler should process the new config and fill the service_data with the right info depending on the specified entity_index, or service_data.
Templating tools makes re-use of toolsets possible. This already shortens the yaml files with a large amount.
It would be nice if the same can be done for colors (colorstops, colorlists)...
Of course, re-use is much better if global sak-templates are implemented, so re-use can take place over cards, instead of (currently) only within a card.
Example:
templates:
- type: tools
name: tools-segarc-icon-state
tools:
- type: colorstops
name: colorstops-lux
colorstops:
colors:
0: 'grey'
50: 'var(--theme-gradient-color-01)'
75: 'var(--theme-gradient-color-02)'
100: 'var(--theme-gradient-color-03)'
125: 'var(--theme-gradient-color-04)'
150: 'var(--theme-gradient-color-05)'
175: 'var(--theme-gradient-color-06)'
- type: colorstops
name: colorstops-pressure
colorstops:
colors:
980: 'lightgrey'
990: 'var(--theme-gradient-color-01)'
1020: 'var(--theme-gradient-color-05)'
And in the definition of the tool:
- toolset: lux
template: segarc-icon-state
position:
cx: 175
cy: 50
scale: 1
variables:
- entity: 3
- show_scale: false
tools:
- type: segarc
id: 0
show:
style: 'colorstops'
scale: true
scale:
min: 0
max: 200
segments:
colorstops:
gap: 0
# Can we use template colorstop lists? For easy re-use??
template: colorstops-lux
The current implementation uses 1:1 css style syntax, which requires an ';' at the end of each line.
This is also required for the styles: section in yaml.
As any other configuration doesn't need that, it is error prone, especially using templates.
So remove this!
Use the styleMap from lit-element: https://lit-element.polymer-project.org/guide/styles
This is a big overhaul, as it requires that:
and:
and:
Add to start of card:
import { styleMap, StyleInfo } from 'lit-html/directives/style-map';Nope -> (if using the above, js contents is added as the style?!?!?!?!?!?!)
import { styleMap } from 'https://unpkg.com/lit-html/directives/style-map.js?module';Note: StyleInfo might not be needed using plain js... Just use the styleMap record definition, which is almost the same as the current definitions used, except for the trailing ';' 😄
And oh yes, you can still use the normal syntax: font-family, but use quotes. In that case you don't need the camelCase syntax, which I find confusing to use...
And the example:
<button style=${styleMap({
'background-color': 'blue',
'border': '1px solid black'
})}>A button</button>constructor() {
super();
this.classes = { mydiv: true, someclass: true };
this.styles = { color: 'green', fontFamily: 'Roboto' };
}
render() {
return html`
<div class=${classMap(this.classes)} style=${styleMap(this.styles)}>
Some content
</div>
`;
}😄
Add card to HACS for easy finding, installation and updating
Must look at the documentation to make PR for HACS to get it into the default repository.
Overall Steps:
Required changes:
HACS can add files that are located in the /dist folder. This requires structural changes of the system templates SAK is using
/dist folder and test current implementationLast step:
Verify that everything works. So this can be done only after the card is added to HACS. If the configuration changes won't work, another solution must be created...
According to ludeeus, this solution should work though!
Some tools can be colored depending on their linked entity state using animations (operators to be precise).
This could also be done - I think - using colorstop lists.
If such a list is attached to for instance a line, icon, state, etc. this list can be checked if the state changes.
In those cases it saves defining an animation with an operator list. Seems easier for the end user??
And if colorstops can be templated (see #14 ), it becomes much easier to implement and use consistently in sak cards.
No 100 lists which must be synchronized with every change...
As the sak kan include custom svg's, it would be possible to use them on any card.
This might include partial animations & color settings.
Some of these sites have also very nice animations. Saves a lot of work to see what keyframes they used to get that sort of animation.
By using groups within the svg, parts can be animated and colored.
Large collection:
Interesting Sites:
Stunning free design resources for designers and developer! Stop hitting your head down on a desk anymore 👌
For more, click here or hit this.
Made with 🤘 by @d__raptis
Currently all widgets are maintained in separate lists per type. This takes a lot of code to maintain.
Furthermore, as the widgets are drawn per type, it is not easy to force a certain drawing order to make sure that some objects are layed out on top of other objects.
Using assemblies to group tools makes this possible. For this, the existing widgets must be changed to classes.
The following widgets (tools) should be migrated to classes:
Create base class and separate classes per type of tool that can be displayed on the screen.
Each class takes care of its own initialization, configuration, updates and rendering.
Events must be forwarded to these tool objects.
After the first implementation of local templating (see #1), this issue will implement global templating using files. This makes it possible to share templates between cards. The local variant could not do that.
Templating has still the same goal: minimize maintenance and creating a complex card with repeated tools is a lot easier.
If done right, sak templates can be combined with decluttering templates!
Make templates in:
The current slider implementation is just a demo-like implementation of a mobile friendly slider.
It has no relation yet with a state entity, has no initial value, nor can it update and configure itself.
Make a full tool out of this slider:
configuration in yaml
runtime stuff
The min/max values of the segmented arc are not displayed. It would be nice if this would be possible, of course free placement, and styling.
This could be extended with extra labels like 20%, or 50%.
Label positioning:
show:
labels: true
labels:
min:
rx: 0
ry: -10
style:
fill: 'red'
max:
rx: 100
ry: -10
50:
rx: 10
ry: 20
value: 'Half way'
highpres:
rx: -10
ry: 10
value: 'High Pressure'
The thumb of the slider is not correctly positioned if the slider is not set to (50,50) as position.
A (50,50) position leads to a cx/cy of (0,0).
So the actual thumb position seems to assume (0,0) and doesn't calculate the right thumb position in any other situation.
Adjust thumb position for the actual center position...
The current svg tool supports state images.
Extend the possibilities with:
Some changes are necessary to support these different functions. Some can't be mixed probably, as it gives problems with the animation configuration.
Using a map and array. Should be map. Why is an array used??
animations:
- state: 'on'
styles:
- fill: var(--theme-gradient-color-08);
- opacity: 0.9;
- state: 'off'
reuse: true
styles:
- fill: var(--theme-gradient-color-01);
- opacity: 0.7;
styles:
font-size: 1.5em;
text-anchor: start;The units of measurement are always added/shown next to the state value.
In some cases this is not desired: the uoms should either not be displayed, or above or below the state.
Makes this a configuration 'show' option, where default = the old situation.
uom positioning:
show:
uom: default
uom: above
uom: below
uom: noneEvery tool can be styled using the styles section.
The segmented arc uses two sections:
styles for the segmented arc itselfstyles_bg for the background of the arcOther tools also will need multiple styles sections to be able to style each part. Some tools already have multiple subsections for styles, so need not to be changed.
Using a zillion style_** sections is not an option.
This must be implemented for all tools. Lot of work, as the yaml views/templates must be changed also:
The general proposed solution is to make the styles section a map of styling parts. Easy to extent & process.
styles:
front:
fill: red;
background:
fill: black;but also:
styles:
bar:
fill: red;
label_min:
fill: black;
label_max:
fill: black;Grouping tools within toolsets might by handy to control a complete group.
Situations:
Something for next year??
Implementation with svg groups to control a bunch of tools??
Integrate the functionality of the horseshoe part of the horseshoe card as a widget/tool in this card.
Reasons:
But before that is possible, more functionality must be integrated here, such as the animations!
Create class for this. Migrate all the stuff from setConfig and more to this class, just as with the other classes...
Create initial documentation for public release, so first time users understand the basics
Look at horseshoe documentation, and see what can be re-used...
The current animations handling assumes the current entity_index as the state that is processed for getting different animations/styles per state.
In some situations it is very handy if another entity's state can overrule/adjust the styling/animations of the current entity tool.
Examples:
Adding an optional entity_index: to the animations is enough.
Note:
Must check the reuse flag. TThat flag takes care of re-using the current/previous state, but was made assuming there is only ONE animation that can determine the styling, which is not true anymore if more than one entity_index can format the styling.
So should the extra state be able to:
Current for entity_index = 0:
animations:
- state: 'on'
styles:
circle:
fill: darkorange
transition: 'all .8s ease'
- state: 'off'
styles:
circle:
fill: lightgray
transition: 'all .8s ease'Extend with:
animations:
- state: 'on'
styles:
circle:
fill: darkorange
transition: 'all .8s ease'
- state: 'off'
styles:
circle:
fill: lightgray
transition: 'all .8s ease'
- state: 'on'
entity_index: 1
reuse: true
styles:
circle:
opacity: 1
pointer-events: auto
- state: 'off'
entity_index: 1
reuse: true
styles:
circle:
opacity: .1
pointer-events: noneThere is currently a discrepancy between the toolset and tool configuration.
The toolset specifies a separate position map with position & dimensions, where the tool uses inline configuration.
Refactor this to use the position map for tools too.
Easy peasy:
- tool: some example
type: circle
position:
cx: 50
cy: 40
radius: 45Instead of:
- tool: some example
type: circle
cx: 50
cy: 40
radius: 45Lights show the brightness percentage.
On iOS this value is NOT updated if that value is changed. It IS updated as expected on Chrome.
None.
In hass 0.98 everything is rendered perfectly, but since hass 0.110 (change in icon rendering), there are problems.
Problem is described here: home-assistant/frontend/issues/7224, assuming this is a hass frontend issue, and not something that should be changed in this card.
Issue is worse for Safari.
The current slider tool implementation has two orientations: horizontal and vertical.
Add another option to make a circular / ellipse slider.
The track is round in this case, with an start and stop angle.
Add track options like progress/activetrack
Color the progress/activetrack part of the track, ie from start to up to the thumb position
Add scale
Add labels
Additions can be done in the current slider stuff, it is just an extra switch in the case statements...
The slider is then composed of:
The horse shoe contains animations: if an entity changes from state, you can run an animation on some of the objects (icon, lines circles) using default css animation functionality. This can be defined in the card yaml.
The idea is to implement animations on the swiss army knife also!
The horse shoe implementation looks like this:
animations:
entity.1:
- state: 'on'
circles:
- animation_id: 10
styles:
- fill: var(--theme-gradient-color-08);
- opacity: 0.9;
- animation: jello 1s ease-in-out both;
- transform-origin: center;
icons:
- animation_id: 0
styles:
- fill: black;
- state: 'off'
circles:
- animation_id: 10
reuse: true
styles:
- transform-origin: center;
- animation: zoomOut 1s ease-out both;
icons:
- animation_id: 0
styles:
- fill: var(--primary-text-color);
The objects look like this:
icons:
- id: 0
animation_id: 0
xpos: 50
ypos: 55
entity_index: 1
icon_size: 3.5
styles:
- color: white;
circles:
- id: 0
animation_id: 0
xpos: 50
ypos: 50
radius: 35
styles:
- fill: var(--primary-background-color);
- id: 1
animation_id: 10
xpos: 50
ypos: 50
radius: 30
entity_index: 1
styles:
- fill: var(--primary-background-color);
You can see how the objects, animations, and entities are linked together:
So:
The sak card uses separate tool objects for each object: the idea is that each object itself handles operations on the object. This means that animations should also be handled by the object/tool itself.
For this:
tool.value = function..value function, the tool can calculate the animation styles itself. These styles will be added to the styles used to redraw the tool during a render action initiated by a changed entity.The animation config could look like this:
type: "circle"
entity_index: 1
animations:
- state: 'on'
styles:
- fill: var(--theme-gradient-color-08);
- opacity: 0.9;
- animation: jello 1s ease-in-out both;
- transform-origin: center;
- state: 'off'
reuse: true
styles:
- transform-origin: center;
- animation: zoomOut 1s ease-out both;Not sure, but are things like state values already supported now:
animations:
- state: 40
operator: '>'
styles:
- fill: var(--theme-gradient-color-08);
- state: 20
operator: '>'
styles:
- fill: var(--theme-gradient-color-01);The default operators is '='
Evaluation stops after a match is found!
If this is extended for icons and text, these can change color depending on the state. Would be nice??
There is a simple line tool which can draw a single line. But what about a polyline, or using multiple lines as ONE tool? By supporting the svg polyline, it is easy to also support multiple lines as one object.
So add this tool and see what functionality can be added to this tool to make it nice:
If lines can be made of different parts, one could also style the parts differently. This makes the tool much more usable. However, what about colorstop etc.: they are not yet configured for multi-part tools, which should be if you want to do this. Animations do support multi-part tools already, so for now one should use those...
- type: lines
position:
one:
- line:
cx: 50
cy: 50
length: 190
orientation: horizontal
- points:
- x: 10
y: 20
- x: 20
y: 30
two:
- points:
- x: 200
y: 200
- x: 20
y: 40
close: true
styles:
one:
stroke: lightgray
stroke-opacity: 0.7
stroke-width: 5
two:
stroke-opacity: 0.7
stroke-width: 7Colorstops should then support multiple parts.
And this format still doesn't make it possible to have different colors for fill and stroke for instance. The fill and stroke should go into the colorstops itself. Hmmmmmmm. Colorstops with styles and classes??
colorstops:
one:
fill: true
colors:
0: '#A8E05F'
51: '#FDD74B'
101: '#FE9B57'
151: '#FE6A69'
201: '#A97ABC'
301: '#A87383'So this way seems better if made consistent with animations, and styles/classes, a colorstop should be defined as follows:
colorstops:
colors:
- stop: 0 # The stop
styles: # Styles / Classes
one: # The part
fill: '#A8E05F'
stroke: '#A8E05E'
- stop: 51
classes:
one:
myClass: true #'#FDD74B'
- stop: 101
styles:
one:
fill: '#FE9B57'
- stop: 151
styles:
one:
fill: '#FE6A69'
- stop: 201
styles:
one:
fill: '#A97ABC'
- stop: 301
styles:
one:
fill: '#A87383'
In which case things like stroke-width, opacity, etc can also be specified!
Currently each tool can define styles in the styles section. These are then defined as inline styles for the SVG element. Those styles overwrite class settings defined in the css stylesheet.
Due to the implementation of the classes section (#49), users can define classes to style a tool.
This requires the tools also to use classes, as otherwise the default (inline) styles keep overwriting the classes!
Use BEM naming convention.
So for the switch or other compound tools, the classes become:
sak-switch for the switch toolsak-switch__track for the track part of the switchsak-switch__thumb for the thumb part of the switchThat is really consistent with the way the styles are organized as switch.track and switch.thumb in yaml/javascript!
sak_templates.yaml file.See #49 for this.
These css definitions are added to the default css definitions, ie they can overwrite the system/default sak css definitions.
Both font-size and icon-size is currently not consistent with the percentages used for all the other tools.
To make matters worse, some css is also specifying font-sizes, sometimes % font sizes. This results in inconsistent yaml specifications.
For instance:
The font-size for the Name is larger than for the Area, however in the yaml spec this is the opposite:
# Name of entity
- type: name
cx: 5
cy: 81
id: 4
entity_index: '[[entity_light]]'
styles:
name:
font-size: 1.8em
font-weight: 700
text-anchor: start
# Area of entity
- type: area
entity_index: 0
id: 5
cx: 5
cy: 91
styles:
area:
font-size: 2.4em
text-anchor: startThis is caused by css definitions!
It is not very difficult, but takes some time to change all the yaml definitions & code:
entity__name and entity__area definitionsJavascript templates are currently only supported to implement the custom_value / derived_entity for a tool to process the incoming state value to something else.
Adding javascript templates to the animation section would:
Animations are 'run' from the tools baseclass set value() method , which is processing the data coming in through set hass().
By implementing javascript templates in this method for animations, makes it fairly easy to implement, as it doesn't impact any other methods and results in generic template support for ALL tool animations.
The current static tool styling and animations sections use a styles section to define css and svg styles. This works ok.
However, one need to specify every single css style for each part, where css/html already defined classes to make this a lot easier.
So add this classes option to:
animations:
- state: 'on'
styles:
circle:
fill: darkorange
transition: 'all .8s ease'
- state: 'off'
styles:
circle:
fill: lightgray
transition: 'all .8s ease'
- state: 'on'
entity_index: 1
reuse: true
classes:
circle:
sak-enabled: true
sak-disabled: false
- state: 'off'
entity_index: 1
reuse: true
classes:
circle:
sak-enabled: false
sak-disabled: truestyleMap functionalityThis one can enable (true) and disable (false) classes. That should be ease to add using some small code refactoring in the render methods.
The system /card classes get a sak- prefix, so no user can overwrite them...
So users can define there own classes. These are then added to the styles section.
That is also required for svg filters and other stuff. Not yet done!!!!
NOTE:
The css_extra_definitions section can also define @keyframes for defining own animations!
css_extra_definitions:
- descr: class for whatever
content: |
.whatever {
fill: orange-01;
stroke-width: 2;
stroke: yellow;
opacity: 0.2;
}
- descr: class for whoever
content: |
.whoever {
color: green;
align-text: middle;
}And remember: (inline) styles overwrite the class specifications!!! ALWAYS!!!
This also means that the current inline styles for all tools should be moved to css, as otherwise the class definitions won't work, as they will be overwritten by the predefined inline styles!
Use new naming schemes. Must rename a lot of structures & yaml files...
SAK uses toolsets with tools, so rename groups and widgets to this:
The opts structure for each tool is actually the configuration. Just as the card, give it that name. More consistent
Just as a card has a cardId, each tool should have a toolId. Much better readable than just id
Maybe it is possible to have a variable list of entitiesthat can be displayed by extending the card vertically.
In this case one would have to know the size of a single entry and expand the SVG viewBox dynamically.
Situations:
Something for next year??
??
Describing all the elements of a SAK card, ie all the toolsets and tools can be a lot of yaml. To minimize this makes maintenance and creating a complex card with repeated tools a lot easier.
So the problem to be solved is not on a card level, but on a deeper level. The decluttering template card can't be used for templating assemblies and tools.
The decluttering card shows how templates can be implemented. The idea is to use that format to be able to template sak-tools as part of sak-toolsets.
A simple test (2020.09.30) shows that this is possible:
if (this.config.templates) {
if (this.config.toolsets) {
let tools= Templates.replaceVariables(this.config.toolsets[1].variables,
this.config.templates[0]);
console.log('template, tools are: ', tools);
}
}with the following yaml to define the card templates:
templates:
# Define template for an assembly with 3 tools
- template: template1
defaults:
- entity0: 0
- entity1: 1
- entity2: 2
tools:
- tool: state
id: 4
entity_index: '[[entity0]]'
- tool: state
id: 5
entity_index: '[[entity1]]'
- tool: state
id: 6
entity_index: '[[entity2]]'
toolsets:
# Both toolsets use the first template
- toolset: toolset1
template: template1
position:
xpos: 25
ypos: 60
- toolset: toolset2
template: template1
position:
xpos: 12.5
ypos: 60
variables:
- entity0: 3
- entity1: 4
- entity2: 5Sometimes the colorstops shows a black color at the end of the range although the colorstop value is larger then the maximum value.
The following colorstop should work for a value of 60: it should show orange, but shows black in the segmentedarc. It should even work with an end value of 55: that color should be used for any value larger than 55...
Screenshots are from example view-sake10.yml
But it doesn't work for some reason
colorstops_boiler_water_blue2orange:
template:
type: colorstops
defaults:
- thegap: 1
- theFill: true
- theStroke: false
colorstops:
gap: '[[thegap]]'
fill: '[[theFill]]'
stroke: '[[theStroke]]'
colors:
0: '#0094ff'
5: '#1793e7'
10: '#2e92d0'
15: '#4591b9'
20: '#5c91a2'
25: '#73908b'
30: '#8b8f73'
35: '#a28e5c'
40: '#b98e45'
45: '#d08d2e'
50: '#e78c17'
55: '#ff8c00'
65: '#ff8c00'Still going strong just above 55 degrees:
And at 60 degrees, full range of segarc:
It seems that the setting lastcolor is the culprit: it doesn't calculate the segment/entry in the colorstop in the correct way...
There were two rendering paths for Icons: one for Safari (SVG) and one for Chrome (ForeignObject/SVG). Due to longstanding ForeignObject bugs in Safari, Safari used a different rendering path.
But as the Safari rendering path also works on Chrome, the separate rendering paths become obsolete, so use one and remove all the other stuff...
Do not only remove Chrome's path, but also all the tests, comments and checks that are now obsolete.
Will be a nice code cleanup!
Note that this issue: home-assistant/frontend#7441 shows the problem, and how to get to the SVG path of the icon, without getting it directly from the database.
Check how performance can be made a bit better. It seems from data from the Chrome inspector that some of the calls are expensive and might result in better overall view switching performance if these parts can be optimized.
For large views with lots of tools small optimizations can result in snappier performance from the users point of view.
Totals from sake2 @2020.11.27:
Not all scripting time is from this card of course, but as you can see, the client-width fetch is with 115ms already 4% of the 2835ms scripting time for home assistant, chrome extensions, etc.,
If we look at the urls, we see a better picture, this is detail from the air-quality view:
Here you see this card takes 462ms, so the client-width fetching is about 25% of this time. The other parts, like the stringify's and spread operator also seem relative more expensive now 😬 !
The well known stringify:
The spread operator:
Client size:
The very expensive client rec call used in Icon rendering. This seems hard to cache, as a change in clientwidth (landscape/portrait modus for instance, or changing the client window on a PC) should be detected in that case (an Observer??).
Most parts are always rendered/calculated even if the data is not changed. This applies - I think - in most cases for the styling of a tool. So a changed flag or something might win some performance.
Most of the stringify calls for styles might not be needed in every render() call.
This call seems to work faster than several spread operator calls.
But this also relates to the fact: has data been changed, so do we need to merge this data AGAIN!
Is this call still required, if all icons are displayed with their svg path?? If not, this would greatly enhance performance!
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.