@msp1974 I’ve updated to v3.3.0 and played around a bit with passive mode
. I’ve enabled it in one room, looked for schedule integration (realised that bit is still in development) and disabled it. Seems like it resulted in stuck history card
I’ve indicated with arrows when it happened, but after disabling passive mode
it doesn’t seem to return to displaying current target temperature
. Maybe this will resolve once min/max is no longer visible in chart, but though to let you know anyway.
EDIT
My guess was correct - once min/max section happened more than 24h ago chart started to work again
@msp1974 I’m using the vertical-stack-in-card a lot in my dashboards to combine multiple cards together without borders. When using it with the Schedule Card, the borders remain.
You can see the rounded corners and the lines at the top, bottom and side of the embedded card. These disappear on all other cards. Do you have any idea why the Schedule Card behaves differently from other cards? The Passive Heating entry is an entities card using the collapsable fold-entity-row card and the title is using the Markdown card. Here’s the yaml:
type: custom:vertical-stack-in-card
cards:
- type: markdown
content: '## Schedules and Passive Heating'
- type: custom:wiser-schedule-card
admin_only: true
show_badges: true
theme_colors: false
display_only: false
view_type: default
name: ' '
- type: entities
entities:
- type: custom:fold-entity-row
head:
entity: binary_sensor.passive_trvs_heating_demand
name: Passive Heating
entities:
- entity: switch.sewing_room_climate_passive_mode
name: Sewing Room Passive Heating
- entity: switch.spare_room_climate_passive_mode
name: Spare Room Passive Heating
- entity: switch.garage_climate_passive_mode
name: Garage Passive Heating
state_color: true
I use vertical-stack with:
in_card: true
that gets rid of the borders.
I used to use the custom card but I thought it was now part of the lovelace UI hence me changing to vertical-stack
Here’s an example of my yaml using this
type: vertical-stack
title: Kitchen
in_card: true
cards:
- type: light
name: Dining
entity: light.kitchen_dining
icon: mdi:lightbulb-multiple
- type: horizontal-stack
cards:
- type: light
name: Sink
entity: light.sink_strip
- type: light
name: Oven
entity: light.oven_strip
- type: light
name: Island
entity: light.island_strip
view_layout:
grid-area: t1
and here is the result
maybe that helps?
EDIT: just tried this in the vertical stack and the wiser schedule card does not obey this command.
I should have done this before posting.
So I’m sorry for the red herring.
Thanks and no worries for the red herring. I’ll always use the native options if they will do what I’m after over a custom option, so it is really useful to know anyway!
When did that get added to the native vertical stack card? It’s not documented that I can see.
I’ve just tested it with a couple of cards and it looks like it doesn’t work if you’re mixing card types?
view_layout:
grid-area: t1
Also appears to be an undocumented option. What does that do?
You are probably correct, I don’t think I have mixed card types
If I remember correctly it was documented as part of the custom card you use - but that was moons ago, or maybe in a blog relating to it???
view_layout:
grid-area: t1
Its part of the grid layout view - where to place the card in the grid
again a red herring for your issue, I should have edited that out.
@jamiebennett Can this be used in place of a Room Thermostat? It seems to be suggested here that it can. This is exactly what we need, a small screenless sensor.
Wiser does support that Temperature sensor but not with the hubs sold in the UK unfortunately.
Looks like it’s only compatible with the second gen heat hub according to the french compatibility checker. I wonder if at some point the second gen hub might be introduced to the UK market…
Thanks. That’s a pity.
@robertwigley FYI - Regarding the borders in a vertical stack.
I have used your yaml modified to use entities I have and the
in_card: true
does work using your cards in a vertical-stack card. My confusion was caused by the internal borders within the wiser schedule card which must be hard coded.
Here is my test yaml
type: vertical-stack
in_card: true
cards:
- type: markdown
content: >-
The **Markdown** card allows you to write any text. You can style it
**bold**, *italicized*, ~strikethrough~ etc. You can do images, links, and
more.
For more information see the [Markdown
Cheatsheet](https://commonmark.org/help).
- type: custom:wiser-schedule-card
- type: entities
entities:
- type: custom:fold-entity-row
head:
entity: sensor.wiser_cloud
name: Wiser Cloud
entities:
- entity: sensor.time
- entity: sensor.date
- entity: sensor.local_time
and here is what it looks like:
That’s really weird. It is definitely not working for me. I thought it might be browser related for a moment there, but it’s the same in both Firefox and Edge. What am I missing? Using your yaml to make sure, displays like this, with cards completely separated.
I used the UI “show code editor” and I had to save the card before it worked properly but after that I could edit the yaml through UI no problem.
Edit:
It might be using the card mod module - I’ll check it out.
That’s how I edit all my cards anyway, in yaml. I don’t use the UI editor.
Ah, that would make sense. I’m pretty sure there has to be something more needing to be done. I’ve already got lovelace-card-mod installed and am using it in the odd place.
Thanks, if you are able to find what else I need to do, it would be appreciated, as the vertical-stack-in-card does sometimes need a browser refresh to remove the borders (i.e. it’s not overly reliable) and I would rather switch to the native method if possible.
Is it maybe lovelace-canary that you’re using that adds the in_card
extension to the standard vertical-stack? I’m just about to test this…
Yes I have that installed as well - I was going through all my community add ins.
You have probably beat me to it.
I’m not sure it’s lovelace-canary either, as this is what I get now using the yaml you supplied i.e. it’s still showing borders.
Weird. It has to be the canary card - its in the card’s documentation and it was the only reason I installed it if I remember correctly.
I assume you’ve restarted HA?
The only thing I can add is the order of the cards seems to make a difference. After I had posted the previous yaml and screenshot I noticed the border at the bottom of the schedule card re-appeared after I saved it and refreshed the view. But when I put the entities card with the fold-entity-row above the schedule card and below the markdown it worked as expected after the save and refresh.
So not perfect.
I note that the canary card readme/wiki suggests that card-mod should be loaded first.
Do you have this in your configuration yaml?
#
extra_module_url:
- /local/community/lovelace-card-mod/card-mod.js
###
Yes, it is in the documentation for lovelace-canary, that’s how I found it via search for:
home assistant “in_card”
I didn’t restart HA, but you shouldn’t need to for Frontend HACS repositories as it automatically prompts you to reload the browser.
No, it’s not in my configuration.yaml
, but I don’t think it appears there when you’ve loaded it through HACS. It shows under my loaded Frontend HACS repositories and I already had it installed and was using it here and there already.
I’ll try a restart and clear the browser cache too…
I suggested the restart because it would force a reload of the modules.
The card-mod installation page suggests this, hence the line in my configuration yaml.
Performance improvements
While card-mod can be installed as a lovelace resource, some functionality will benefit greatly from it being installed as a frontend module instead.
To do that, add the following to your configuration.yaml
file and restart Home Assistant:
frontend: extra_module_url: - /local/card-mod.js
You’ll need to adjust that path according to where you have installed card-mod.js
. If you installed through HACS, this is probably /hacsfiles/lovelace-card-mod/card-mod.js
.
Any resource definitions automatically added by HACS can be kept as is even after adding extra_module_url
.