Closed onlinux closed 11 months ago
Thanks for the suggestion! I like the feature and it seems to be a quite local change.
However, I feel, there is still a bit of redundancy in the code that should be reduced:
typeof
?return
statements and if
blocks that could be written in a more compact form.How about adding a function like this and then just re-use it:
function getObjectAttr (obj, path) {
let res = obj;
path.split('.').forEach(function (key) {
res = typeof res === 'object' && res ? res[key] : undefined;
});
return res;
}
We might have to adjust the style to the mini-graph-card habits a bit.
Also, there is some housekeeping to be done:
package-lock.json
can probably be ignored. (My setup also changes the lock file all the time, but you don't use any new dependency.)dev
branch.What do you think?
This functionality is very useful. Are these usecases possible?
Can be tested with a weather entity.
Are these usecases possible?
I would keep it simple for a start:
[]
notation will be more difficult to parse and does not give an advantage over .
notation.listattr[2]
will thus likely not be possible, but listattr.2
could be added in a next step, once we have this feature in place. It will just be a matter of converting the string '2'
to the number 2
...I suggest to get this merged as simple as possible first. And then extend.
When devices have attributes defined as attr1.attr2.attr3 etc... you can define the attribute as attr1.attr2.attr3 etc
Ex: for RPI monitor :
type: custom:mini-graph-card entities:
This will prevent the need to create numerous virtual sensors for each sub-attribute you wish to access.