Repository navigation
Replies: 3 comments 8 replies
|
OK, the "show_debug" variable does seem to work. so my problem (ok the problem with seeing debug) is working... now to figure out what it doesn't like. Still not sure why the debug didn't get passed along as if it was a variable, but I can live with this. |
|
Glad the variable trick got you going. That's the right way to do it for now: The same thing applies to variables, and I think that's what's actually breaking your camera. A nested card only gets the variables written in its own Passing them through explicitly should sort it: cam_backup:
card:
type: vertical-stack
cards:
- type: custom:decluttering-card-plus
template: camera
variables:
- camera_entity: '[[camera_entity]]'
- frigate_name: '[[frigate_name]]'
- live_provider: '[[live_provider]]'
- go2rtc: '[[go2rtc?]]'
- weather_show: '[[weather_show]]'
- light_switch_show: '[[light_switch_show]]'
visibility:
- condition: state
entity: '[[camera_entity]]'
state_not: unavailable
- type: custom:decluttering-card-plus
template: camera
variables:
- camera_entity: '[[direct_camera_entity]]'
- frigate_name: '[[frigate_name]]'
- live_provider: '[[live_provider]]'
- go2rtc: '[[go2rtc?]]'
- weather_show: '[[weather_show]]'
- light_switch_show: '[[light_switch_show]]'
- card_mod_style: '[[backup_card_outline_style]]'
visibility:
- condition: state
entity: '[[camera_entity]]'
state: unavailable
grid_options:
columns: fullThe On the list elements, yes, that works. A list item that's nothing but |
|
Thanks, that makes total sense. So, couple of questions...
|
|
On 1, I meant pass them straight through, no On 2, you don't need an decluttering_defaults:
car_element_def:
type: conditional
# ...exactly what detect_car_element has now
# in camera:
elements:
- '[[light_switch_element?]]'
- '[[detect_car_element?]]'
- '[[detect_person_element?]]'
# in cam_backup, on both inner cards:
- detect_car_element: '[[detect_car_element?]]'
# on the dashboard card:
variables:
- detect_car_element: '[[car_element_def]]'A card that sets |
|
Thanks, that also makes sense... though in my example I should have said something like: elements:
- [[detect_car_element|if{detect_car_entity}?]]
- [[light_switch_element|if{light_switch_entity}?]]
- ...
go2rtc: '[[go2rtc|if:live_provider="go2rtc":go2rtc_block?]]
So, I would also not need the "detect_*_show" var, but woudl also not need to pass car_element_def var either, if there is a entity defined to watch, then show it, if not, dont... Similarly, the go2rtc section doesn't need to be there unless the live_provider is set to "go2rtc". you way makes sense, and is one that I'm probably going to do at this point, but in the spirit of reducing the needed config, it would be nice to have it be smart enough to be able to build the card based on what the vars are. To take that a step further, you could even allow for custom javascript functions... for example: A user could put a file called "declutter_card_custom_funcs.js" in the config directory (or even have a config key pointing to a file) const custom_dcc_funcs = {
// passes everything after the "|" to the next "|"
substr(inputString){
// expects variable|substr:new_var:10:15,
// with "new_var:10:15" being passed as inputString.
const parts = inputString.split(':');
// Extract components based on the pattern "string:start_index:end_index"
const text = parts[0];
const startIndex = parseInt(parts[1], 10);
// Check if an end index was provided in the pattern
if (parts.length > 2 && parts[2] !== '') {
const endIndex = parseInt(parts[2], 10);
return text.substring(startIndex, endIndex);
}
// If no end index is passed, slice to the end of the string
return text.substring(startIndex);
}
then, if that exists (or is configured), you can load it, and pass everything after the keyword to the custom function. |
|
Both of those make sense, and they're two different sizes of ask. The conditional one fits how the card already works. A step like Custom JS functions I'm going to hold off on. Loading a script from the config folder means the card running whatever code is there, and templates that call functions only you have would break silently for anyone you share them with. If there's demand I'd rather do it as a hook a Lovelace resource can add to, so it goes through HA's normal resource loading, but not for now. |
|
Makes sense... (honestly I didn't actually expect the js functions... would be nice, but I'm not sure I'd actually put the work into writing them myself anyway). |
|
so... is the debug flag supposed to work with element templates? I tried it and could not get it to work. I would not expect it to work if used directly in a card since it would probably break what it's in. so I tried making an element template, and a card template that used the element template, which I got to work, but when I turned on debug, it shows the element section as the decluttering card. (I had debug:true in BOTH decluttering cards) (what I was trying to figure out was, can I create an element template, then assign that template to a variable, then use that variable in a card template (using the [[element_template|if:check_var?]] approach.) that was not working, but the errors were not useful, so I was trying to get a debug string to see what it was rendering. ) |
|
It does work with element templates, but debug only ever shows one level, the card it's written on. It replaces whatever that card would have drawn with the config it built. That's why having it on both cards didn't help. The outer card shows its debug text instead of the camera card, so nothing inside it is ever created, including the decluttering element, and the inner debug never gets to run. In the outer card's output an element that comes from a template will always appear as So put debug on one level at a time. For what you're checking, the outer card's debug is the one to look at: its Debug on only the inner element does show what the element built, but I found a bug there while testing this. An element is centred on its position and clipped by the card, so the debug text got cut off at the top, and a longer element config would lose more with no way to scroll. That's fixed on main (#163) and will be in the next release: the element's debug view now covers the card from the top-left and scrolls. I tested your approach on my test setup with advanced-camera-card: an element template, a default holding |
|
OK, I got it working... (at least, I got the templates working), I still haven't figured out how to see the debug of just the element object, but I got the element in a variable working... turns out that I was defining the element as a list (with a "-" in front) so was trying to have a list of lists when I included in them in the card. (grrr) yaml is annoying in how it identifies lists. |
|
Glad you found it. That one catches everybody, a stray For next time, the outer card's debug would have shown it. In the JSON the item comes out as On seeing the element on its own, that's the clipping bug from my last reply. In 1.12.0 the element's debug text is drawn centred on the element's position, so the card cuts off the top of it, and more of a longer config, with no way to scroll. Once the next release is out, |
Uh oh!
There was an error while loading. Please reload this page.
I have a template that is extended from a template, that contains several decluttering cards... which isn't working right now, so I put in
debug: trueon the last decluttering card, to try to see what is happening. but that one just shows the other decluttering cards as cards, it does not render those with debug.Example:
(defaults section is at the bottom of this since I don't think they are related to the reported issue)
returns this output:
if I put the
debug: truein the one or both of the two decluttering cards that are part of the camera_w_backup template, it does work (though of course it shows the debug everywhere that I am using that template)What I was expecting was that if I put the debug in the last level, it would propagate through all of the levels.
could I treat debug as a variable? (`debug: '[[show_debug]]')
(BTW, the initial error was a problem with the initial element item, am I not able to pass list elements in this manner?)
(here is the initial defaults section for reference if needed)
All reactions