@firstof9 thanks for the reply. I was able to fix it by just going back to the normal vertical-stack instead of the custom one.
1 Like
Is this issue going to be addressed in a dot release or the next major?
Because I’m still seeing it in 0.105.5
Hey @frenck, thanks for the hard work, the integration is working very well 
I’m wondering whether there is a modification I can make somewhere to make it poll faster? I used the old Spotify implementation to turn on my speakers, for instance. I used to have the old version poll every 2 seconds in order to have a decent response time.
Do you know where I might make a modification in order to achieve the same thing?
Thanks!
Great work!
105 also broke my zwave network. I reverted back to a snapshot in the 103 series to recover, but am now unable to upgrade to 105.
Since 105.5 large camera images (opened full screen when tapped on as ‘more-info’) can’t be scrolled anymore, which is rather awkward. Can this be solved in a next update?
With 0.105 bluetooth has stopped working. Is anyone else experiencing the same problem?
Switchbot and Xiaomi bluetooth temperature sensor have stopped working.
It looks like the auto-generated Lovelace UI created cards based on groups?
When groups are gone, what will happen if the UI config is deleted and auto-generated again?
Might be worth mentioning as a breaking change that regenerating from scratch will be more manual reorganising work than it is now - as I suspect many of us have legacy groups.
And also a special announcement for anyone who doesn’t yet have a Lovelace config that now is the time to get one, or they’ll have to set up all their cards manually.
what are you going on about? Groups aren’t deprecated, group options are.
Groups as a frontend construct has been retired the moment we introduced Lovelace. Groups can still be used as a target in any service that takes in entities (turn on, etc).
If I am misinterpreting that and frontend UI will still be auto-generated from groups, then that’s great.
No, they won’t, you have to make areas if you’re still using auto-generated lovelace.
As discussed elsewhere, Areas are only assignable to Platforms that have been updated to work as Integrations, which for now is not most Platforms.
And that’s also changing.
Great!
Would it be worth considering holding back on removing groups until Area has that feature parity?
I don’t know why you would remove the groups… Groups are still useful for service calls and grouping entities.
Discussion above says groups are no longer being used to define the frontend, so whilst configuration might remain it won’t be used when Lovelace auto-generates itself.
Yes, but that doesn’t mean you have to remove the groups… It seems like you have a black and white version of this in your mind. Just keep the groups, it hurts nothing. There will most likely be a migration method and if there isn’t, you have the grouping to use to create the areas. Not to mention, if you remove the groups you risk breaking automations that use groups.
EDIT:
Sorry just re-read the above comments. When I said ‘remove the groups’ I meant ‘HomeAssistant remove the feature where Lovelace uses groups as part of auto-generation’, not ‘user remove their group configuration yaml’. Sorry I was unclear.
I think it might be worth considering keeping the ‘Lovelace uses groups config when generating UI’ functionality until Areas are user-configurable enough to get the same functionality.
I think you are ignoring some of my posts. I told you they were adding the functionality, it just so happens they released it in 106.