I thought (and did…) the same until Marius mentioned in a few other threads that some of the stuff still worked.
I thought andrey stopped developing it when Lovelace came around.
Yes, those are really good tools. I really hated that there were things that stopped working in the custom-ui until I saw he had implemented functional replacements for the things I was missing. And for that reason I decided to just not use the custom-ui any more and stick with custom cards/tools. One less thing to have to maintain and update when HA changes.
I don’t have an example and I’m not going to write one from scratch. There are examples in that thread that do exactly what you are looking for with the state. I, just like you, have to work through it and ask questions specific to your needs if you get stuck. That’s what I did and you learn a lot more that way instead of being spoon fed.
Hi David, thanks.
Gees you have a point there. Trying to be as ‘thin’ as possible is always a good thing.
Though you must admit the configurations with this card are hardly simpler than a small customization in the backend…
my biggest worry with using the config template card would be that one has to do so in each location in the frontend configuration files. It might even go straight against the design philosophy of Lovelace, aimed at separating the front end from the back end better than with regular HA. Customizing an entity makes that separation a lot easier. And makes those cards a lot easier too, end less error prone. You must admit, some of these examples are quite the works…
Of course, creating a state dependent front-end representation is dearly needed in Lovelace, and I am still hoping it will be made available in regular jinja templates anytime soon. Or Javascript. I dread having to ‘learn’ yet another templating syntax, each custom cards seems to develop techniques of their own (markdown , custom compact header, config template card, etc etc)
I’m experiencing rather a sad time, having invested some serious development in the regular Tiles card., which now is slowly or abruptly being deprecated, and stripped of their functionality. I don’t want to experience that again, investing in setting up the frontend with the config template card, when Lovelace might just integrate that natively, and render the custom card useless…
Having said that, I have a few items the card may just be the right thing for now, so if only for reasons of keeping up, I will add it to the config.
Ha! I never said it was easy lol! However after doing the one I did for MQTT, it was a doddle doing the one for my iPxxx devices and also my ISP usage meter one… but yes… not easy at first. That’s also why I posted my finished code as there wasn’t much to go off when I started using it.
not sure what you mean by that…
yep!
Seems that is unlikely to ever happen but you never know…
I agree but it is what it is!
Understood and it seems to be holding you back from the latest versions of HA… Lots of things now will only work with later versions (iOS app v2 for instance). I get your grief but it’s best to try and keep up and adjust as you go.
I’m concerned about that as well… One card I use - the dev has just disappeared - at least someone else has picked it up but it’s an ever present danger a dev will just lose interest and move on to something else. The more of that custom stuff that finds it’s way into core the better but a lot of things seem to be at odds with the devs vision for core…
how exactly did you do that?
it’s always great to complement statement like that with your code if you would like the community to help as it’s just guesswork otherwise.
that’s exactly what I tried to convey earlier, you are creating a(n unnecessary ) template sensor for the exact same entity as the binary_sensor ping.
The picture you’re showing has 2 different Tv’s though, you’d best show us your group ?card definition
I remember you saying about 2 sensors this way but Im happy its working but now I have it working, if I can get it to 1 sensor per device, then thats even better
can only repeat my words: customize the binary_sensor, and you’re set. I’ve already provided you with a template example.
no need for a template sensor, no need to hide anything in that case.
that’s it.
btw, your spacing of the word sensors: and the rest is off, it should be:
binary_sensor:
- platform: template
sensors:
living_room_tv_power:
friendly_name: LG TV (Living Room)
icon_template: >
{% if is_state('binary_sensor.living_room_tv_status','on') %} mdi:television
{% else %} mdi:television-off
{% endif %}
device_class: power
value_template: >
{% if not is_state('binary_sensor.living_room_tv_status', 'off') and not
is_state('binary_sensor.living_room_tv_status','unavailable') %}
true
{% endif %}
you still have the unavailable test in your template. Given this is a binary sensor, either being on or off, why is that? Have you ever seen in being unavailable?
I advise you to enclose any HA code between a pair of 3 backquotes to prevent formatting.
Yes, it should do the trick and actually I can see no that binary_sensor on your screenshots.
If you provide all the relevant config and screenshots in one post, I’m pretty sure even you yourself will be able to solve the puzzle.
Let’s do it
