May I make a suggestion on version numbering? Ultimately you are obviously free to number how you like, but perhaps take a look at:
It takes about when to bump what part of the version number, and that helps people know when code they are using will break versus when you have introduced a new feature or just fixed a bug. So, for instance, when you changed the code so that show_icon was required, that’s a breaking change. That would indicate a need to bump the version to 2.0.0 (and include extra change log information). It alerts me as a person using the card to the fact that I should look through those notes to see what might break in my setup before I upgrade. When you add a new option (like the ability to hide the title) that doesn’t break anything, you can increment the second number (so in that case it might have been 1.3.0). Bug fixes and non-breaking changes to existing features are in the third number (so the one you just released to fix the bug I found would have been, perhaps 2.0.1). You can go past nine (I have stuff versioned like 1.13.26), so you don’t have to bump the first or second number just because you got to nine (or 99) in the one after it.
I was looking at the code again, and I think I see what HACS wants. You basically have to convert the version number into an integer for comparison. I think if you add a leading zero to the minor and maintenance versioning, you could do semantic versioning, albeit a little bit odd on display. So you’d use:
1.01.01
I think that will get you what you need in HACS. The only thing to look at is whether you have to bump the major version once to get to the new schema. 1.5.1 (151) is less than 1.05.02 (10,502), so I think you’d be OK without a major version bump, but I haven’t looked closely at HACS to know for sure. If this works at least that would give you 99 minor versions with 99 patch versions in each. For this kind of development, that will likely be plenty.
Can we do somehow “group parametrization” for all entities in dashboard?
I mean for all entities we have to add “tap_action…” but maybe can we do it ones for all entities ?
code would be much smaller
Just to mention that the new ‘icon templating’ is working great and reduces the icon conditions.
I have used it on the fan below for three steps and the washer+dryer to indicate it’s running.