Custom measure capabilities

[Baldhor]

Is your feature request related to a problem? Please describe. Homey "built in" capabilities are somewhat limited: https://apps-sdk-v3.developer.homey.app/tutorial-device-capabilities.html Duration, length, angle, weight, ... and probably a few other measure* capabilities are missing. The user expect and want an icon that match the meaning of the measure* capability.

Describe the solution you'd like No choice, need to add some custom capabilities with dedicated icons. ...

As a fallback, a generic capbility could be usefull.

[Baldhor]

(and yes, it's a subject discussed with RoadXY a few weeks ago, I just changed my mind lol)

[RoadXY]

Maybe make use of the Material Design icons? Ronny already uses for his capabilities. This was added in version 0.2.0 of his app. This is a diff of version 0.1.9 and 0.2.0 https://github.com/RonnyWinkler/io.home-assistant.community/compare/0.1.9...0.2.0

[Baldhor]

Those were just exemple icons, I will check Ronny implementation when the time come (need finish improved-ui first :) )

[Baldhor]

Maybe make use of the Material Design icons? Ronny already uses for his capabilities. This was added in version 0.2.0 of his app. This is a diff of version 0.1.9 and 0.2.0 RonnyWinkler/io.home-assistant.community@0.1.9...0.2.0

So I took a look, yes it could be a good source of default icon for custom capabilities. And providing a way to choose your icon in this big open source library is great. I will create a separate enhancement for it.

[Baldhor]

So I tried to implelent a "measureduration" capability. By default, because it starts with "measure", it will propose:

As expected, the other esphome triggers are there too:

This problem is explained in another thread!

By default, Homey doesn't propose a "value changed" trigger, I need to add it at the driver level, And then the same constraints as the 4 above will happen, the trigger will appear for all ESPhome virtual device, even if the measure_duration capability is not used ...

The best I could propose is to reuse those 2:

Maybe I can even make it works for Homey standard capabilities! If so, it means that for exemple considering a measure_humidity capability:

The 5 first triggers will works, but not the last 2!

[Baldhor]

For a custom measure capability (duration, length and so on), we will end up with:

The last 2 being useless, they just appear because of homey limitation ...

[Baldhor]

@RoadXY Point of view?

[Baldhor]

Those 2 have a value of type "string", so the user will need to be carefull :)

Meaning I will need to handle the conversion from text to number

Maybe later I can send a notification if the user input a text value when a number is expected ...

[Baldhor]

Either I go a generic way, or I need go a specific way. And if I go a specifc way it means poissibly hundreds of cards will appear but should not ...

So I decided to do as I explained in the previous posts => The custom capability esphome_text will actually support ALL the capabilities excepted list of values (enum). I will test how it work out for float, I'm unsure above the behaviour if the user input . (dot) or , (comma).

[Baldhor]

So I have been working around the subject, and I so I implemented the following:

1/ esphome_select triggers, condition, and action are deprecated, in the meatime it will works as esphome_text (see next points)

The ESPhome enum capabilities are not deprecated, just their flow cards!

2/ ESPhome_text triggers, condition and action will propose ALL capabilities, whatever their types!

The action card will not propose the capabilities which are readOnly

3/ esphome triggers, condition and action will propose values dynamically based on the type of the capability selected!

Default values for specific capabilities will also be proposed

• windowcoverings_set, windowcoverings_tilt_set, dim and volume_set will propose the values "open" and "close"
• windowcoverings_set, windowcoverings_tilt_set, dim and volume_set will propose the value 0.5 (middle) as a default if no valid input
• boolean will propose "true" and "false"
• list of values (enum) will propose the valid list of values :)

A few screenshot:

ALL capabilities are proposed in the trigger and condition cards

Only the writable capabilities are proposed in the action card

By default, the 0.5 value is proposed for windowcoverings_set, windowcoverings_tilt_set, dim and volume_set

The Open and Close values are also proposed for windowcoverings_set, windowcoverings_tilt_set, dim and volume_set

If the user input a wrong value, the default 0.5 is still there to tell him he is doing something wrong

The 0.5 value is not proposed when the user start input a valid value

Instead, the value he input is proposed to show it is valid!

List of values (enum) are working the same as with the ESPhome select cards!

Hence why they are deprecated!

For free text capability, the value the user input will be proposed in the list of available value, making his value valid!

I think that one worth a few beers lol

[Baldhor]

@RoadXY @denstol @Nettopp Opinion?

Can help me test it out if I publish a test version?

[Baldhor]

Published as test version, I have good hope it doesn't break anything! https://homey.app/fr-fr/app/nl.inversion.esphome/ESPhome/test/

[Baldhor]

Implemented custom capabilities: measure_angle, measure_length, and measure_weight (not published).

I start to think in the wizard, the default values for precision, min, max, units, ... should appear. Otherwise, it is confusing ... need to add it to the constant file and implement it.

Annoying part is that even for standard capabilities, it's like repeating all the conf from Homey in my own file, just cannot access the default manifest from an app ...

[RoadXY]

@RoadXY Point of view?

I'm sorry, I don't understand what you're asking.

[Baldhor]

@RoadXY Point of view?

I'm sorry, I don't understand what you're asking.

@RoadXY Yeah in the meantime, I implemented the "context aware" cards which I think solve the problem fully (excepted custom enum which still require custom capabilities to obtain a picker)

[Baldhor]

Published, certification will probably be monday. I close!