expose: allow setting the label for Lock()

[sjorge]

For devices with multiple locks or for devices that have a lock function, allow setting of a label.
e.g. for TRV's with a keypad_lockout it is now called keypad_lockout instead of state which is confusing if there are multiple switches/locks all called 'state'

[Koenkk]

I remember now why the name is always state. This allows to determine what feature indicates the state of the lock which breaks when we set the name (https://www.zigbee2mqtt.io/information/exposes#lock)

allow setting of a label.

Where did you plan to use this label?

[sjorge]

Before it was state instead of keypad lockout, having one is fine but the danfoss uses a few binary sensors so you end up with a few list labeled state, which is confusing.

Perhaps keypad_lockout should not be a use Lock() but just Binary() as there is no lock_state for those just one property keypad_lockout that is unlock, lock1(, lock2, lock3, ...) as its a property of the TRV not a seperate Lock device?

Switch() has a similar problem, if a device has a multiple Switch() and Lock() exposes it gets confusing.

I think switching e.keypad_lockout() away from Lock() seems the better solution here?

[Koenkk]

@nurikk what about using the property as the label in the frontend instead of name?

[nurikk]

@nurikk what about using the property as the label in the frontend instead of name?

It might be better to add a label property, instead of relying on property key

[nurikk]

Currently we don't have a clear definition of what is
feature.name
feature.type

[sjorge]

I think just not using e.Lock() here is the correct way to resolve this... it really isn't a 'Lock' Device but a extra feature on a Climate device. And that should work fine without any changes to the frontend.

[Koenkk]

@sjorge what if it is exposed as a switch?

[sjorge]

@sjorge what if it is exposed as a switch?

Same issue

zigbee-herdsman-converters/lib/exposes.js

Line 68 in fea5c35

const feature = new Binary('state', access, value_on, value_off).withProperty(property).withDescription(description);

[Koenkk]

@sjorge what if we use:

keypad_lockout: () => new Binary('keypad_lockout', access.STATE_ALL, 'lock1', 'unlock').withDescription('Enables/disables physical input on the device'),

[sjorge]

keypad_lockout: () => new Binary('keypad_lockout', access.STATE_ALL, 'lock1', 'unlock').withDescription('Enables/disables physical input on the device'),

That was my suggestion when i wrote

I think just not using e.Lock() here is the correct way to resolve this... it really isn't a 'Lock' Device but a extra feature on a Climate device. And that should work fine without any changes to the frontend.

That would indeed fix it.

[sjorge]

🤔

[sjorge]

nvm :) I copied your line but it has an error in it, state.ALL is the right one, resting...

[sjorge]

Looks good now and /get and /set still work

[Koenkk]

Thanks!