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:
1 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.
1 Like
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.
I’ve added to my configuration.yaml as below (that is the correct path, as it’s in the www folder which correlates to local inside HA), restarted and cleared the browser cache. I also tried changing the order like you suggested. I’m still seeing borders. Very strange. 
frontend:
extra_module_url:
- /local/community/lovelace-card-mod/card-mod.js
Hmm. The way vertical stack works is to look for the ha-card tag in the code and add some style elements to it to hide the borders.
There are 2 issues here therefore with schedule card.
-
Due to the different panels, the structure of the html is not what stack in card is expecting.
-
Having spent an hour or so playing with the code to present the expected structure, I have found another issue. That in, stack in card runs the js when the stack in card is loaded to remove borders. When the schedule card changes panel (ie list to edit etc) the schedule card is redrawn but stack in card does not then try to remove borders again. There is an open issue relating to borders after HA 2021.11 version which may or may not be related.
I’m not sure whether schedule card will ever work with such a function and maybe better to have an option to hide card borders on the schedule card itself.
Will put on the too list. @robertwigley could you log as github issue. Thx
2 Likes
Thanks for investigating and the detailed explanation. Makes sense as to why I am struggling to remove the borders no matter what I do, although it’s a mystery to me why @Duke_box is seeing different behaviour to me.
I’ll open a GitHub issue shortly. In the interim, I’ve discovered that you can embed the Schedule Card inside an entities card, which looks better to my eyes than how it is with the vertical-stack-in-card or the lovelace-canary in_card extension.
type: entities
entities:
- type: custom:wiser-schedule-card
You can fix this with card-mod (well sort of!). If you use the below as your yaml, it will hide the borders on the card, however, when you change view (ie click a schedule), you will see the border appear for a second or so before it disappears again.
As a note, I also see the markdown card adding back the border if I F5 refresh the browser. Reverts if I edit the card and save again. Looking at the various issues logged with multiple custom frontend mods, they all seem related to 2022.11 or 2022.12 and beyond versions. Lovelace-canary also has a borders not being removed issue logged, along with vertical-stack-in-card and stack-in-card.
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: ' '
card_mod:
style: |
ha-card {
border-width: 0px;
}
- 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
1 Like
That’s really interesting - Thanks
However I am running the native Vertical Stack card with card-mod and Canary HACS add-ins.
And if the schedule card is at the bottom of the stack, with the Canary “in_card: true” flag set, I don’t see the top border of the schedule card.
If I then select a room from the card’s list and click edit so the card expands and then back out to the default display, so the card collapses, the top border remains hidden.
There must be a difference between the custom “vertical stack in card” and the native card. And from your description you seem to use both names interchangeably, so I am not sure if you are only looking at the custom card. I’m confused.
I don’t understand why this doesn’t work for the bottom border of the card, if the schedule card is not at the bottom of the stack that border is visible whilst the top border is hidden, so being able to switch off the card’s external border would solve that.
And I don’t understand why @robertwigley doesn’t get the same results as I do when he uses the native vertical stack card with Canary installed.
I was just talking about the custom:vertical-stack-in-card as that is what @robertwigley was using. Also looked at the custom:stack-in-card as this is an updated version but works in same way.
I will have a look at native one later.
Brilliant! This has worked perfectly for me. Thank you! I’m not even seeing (maybe not noticing as I have a lot of cards on the dashboard and it takes a second for everything to readjust after changing view anyway) the display issues you’ve mentioned.
I have also added the same card_mod yaml to the markdown card, so maybe that’s helping.
card_mod:
style: 'ha-card { border-width: 0px; }'
Yes, 2022.11 completely broke stack-in-card that I was using previously for this. There have been a lot of breaking changes to the frontend in the last few months 
and not always for the better, but that’s another discussion. It’s not had any fixes applied to help deal with the issues, so I changed to using vertical-stack-in-card as that had some fixes in it for the 2022.11 release and works (although not perfectly) most of the time. I’m going to test lovelace-canary, now I am aware of it (thank you @Duke_box), side-by-side (in tandem with this card-mod fix in both) to see what works best in different situations.
Should I still open a GitHub issue for adding the option to not display the borders? I’m not sure it’s required, as this seems to be working reliably, at the moment anyway (time will tell). However, it’s always nice to have more options.
Given that I was only doing this to combine the Schedule Card with the new Passive Mode switches in one card, maybe it would be a better, more elegant solution, to add the Passive Mode switches as an option into the Schedule Card in the longer term? I guess that would need a bit of thought on how best to do that layout and design wise. However, it makes sense, to me at least, to have these all together in one card as they all affect how, when and at what temperature rooms are set.