#👋 Is there a channel to ask about

1 messages · Page 1 of 1 (latest)

arctic silo
#

I suppose I will explain my issue and see what I get.
So I'm trying to add a quirk, and as as part of that quirk I wanted to expose one of the attributes as a sensor:
.sensor( SomeCluster.AttributeDefs.some_attr.name, SomeCluster.cluster_id, device_class=SensorDeviceClass.ENUM )

#

some_attr is in turn defined as:
some_attr = ZCLAttributeDef( id=0x1234, type=SomeStatus)

#

ANd SomeStatus is a t.enum8

#

In HA however, I'm not seeing the enum values, but what it looks like a float (1.0) instead of (SomeStatus.ONE)

#

And the id of the sensor is sensor.some_attr_none (i.e., the attr name plus _none)

#

Am I missing something?

carmine cargo
#

The name is None because the translation key is missing in HA. Normally, it's added to HA when we bump ZHA with new quirks in HA. For now, you either have to modify your translation files or just rename the entity in HA.

#

For the sensor part, we support .enum for the select entity platform. Not sure that's what you want though.

#

If you want more advanced entities, you may need to add them directly to ZHA for now.

arctic silo
#

Ok, I can live with the _none for now

#

But I'm still not sure why the enum is not being used and I'm getting a float value instead

carmine cargo
#

It's a number internally.

arctic silo
#

Right, I meant why is not displayed as a string in HA. Or are my expectations wrong?

#

Also, re translation_key, if I define that and also device_class, validation fails.

#

So how am I suppose to do it?

carmine cargo
#

Regarding the enum, only the internal attribute value (a number) is passed to HA.

arctic silo
#

Is it expected that setting the translation_key when defining the sensor fails validation if device_class is also set?

carmine cargo
#

Which validation are you talking about?

arctic silo
#

EntityMetadata has a _validate method that errors out if device_class and translation_key are defined

carmine cargo
#

Ah, I wonder if that implementation is a bit strong. Generally, a device class in HA will already set a default name for the entity.

arctic silo
#

Giving that the zha code in some places define both without issues makes me think it shouldn't fail

carmine cargo
#

Yeah, seems that way

#

Quirks v2 wasn't tested a lot yet

arctic silo
#

Yeah, that was my follow up question

#

I see almost no use of quirks v2

#

Is it ready for prime time?

#

Or should I wait?

#

I really like the API, so much better than copying the endpoints that you want to replace

#

But there is no much info or RL docs to get you going

#

(and by RL docs I mean real uses that I can have a peek at, no just documentation)

carmine cargo
arctic silo
#

Yeah, I thought those but they only add automation triggers

carmine cargo
# arctic silo I see almost no use of quirks v2

It still has a few limitations, but if you're able to do what you want with it, feel free to use it already.
If the issue is with custom entities being too limited, you can still use quirks v2, but directly add the entities in ZHA.

arctic silo
#

Right, I was hoping I could do everything directly in a single place but I can live with that for now

#

I mean, the unique_id_suffix is not available either

carmine cargo
#

It's the attribute name by default, for quirks v2. It shouldn't be needed.

arctic silo
#

among other things

#

yeah, but in some cases you might want to have a different ones, like having 2 sensors showing different things depending on the value of the same attribute

carmine cargo
#

In that case, yes, but it's not possible to parse attribute values with quirks v2 entities at the moment.

arctic silo
#

Ok, thanks for your help

#

Early adopters need to pay the price, I suppose 😬

carmine cargo
#

It's mostly intended to expose simple on/off configuration switches, for example. For more advanced sensors, ZHA still needs to be modified, yeah.

arctic silo
#

Ah, that's a good and valid point. I didn't consider the target to be simple configurations.

ashen pilot
#

The not mixing device class + translation key is intended. Existing entities do it but it was requested that we don’t do that moving forward. IIRC this was a call out from core folks

ashen pilot
arctic silo
#

@ashen pilot the enum stuff you are mentioning is different

#

I want to be able to see the values for an attribute whose type is a t.enum8

ashen pilot
#

Maybe I misunderstood what you were trying to do

arctic silo
#

Actually, I did try with enums but I might have missed something

#

Let me try that

#

Yay! That did it. Thank you!

ashen pilot
arctic silo
ashen pilot
#

Ok bitsets… yeah we will have a similar situation when we solve tamper sensors on the IASZone cluster as well

#

Feel free to drop any additional observations here for us… always looking for feedback

arctic silo
#

I wonder if there is any way to achieve the same using the Quirks v2 approach

#

Not directly related though

ashen pilot
#

There will be… just have to build it 😄

arctic silo
#

Also, does it make sense to convert existing quirks to the v2 api?

ashen pilot
#

At some point… not high up on the list atm

arctic silo
#

One more question. What's canonical way to test if a quirk matches with the quirk builder?

#

Is there an example I can look at? I haven't been able to find one on a rather quick search

carmine cargo
#

It’ll match if the manufacturer and model are the same, there’s nothing really to test in that regard. It was more complicated with quirks v1, as it used the whole device signature.

ashen pilot
#

It’s matched purely on manufacturer / model rn

#

You can also define filters too

#

There is an example using the signature matching from V1 in the zha lib tests

arctic silo
#

Ah, ok. Makes sense. Ty

ashen pilot
#

Lots of v2 quirks examples in here too