Fix tuya custom attributes types.

[Ten0]

As per their documentation, those are u8, not u16: https://developer.tuya.com/en/docs/connect-subdevices-to-gateways/tuya-zigbee-lighting-access-standard?id=K9ik6zvod83fi#title-7-Color%20Control%20cluster

I have a TS0505B and:

• I can only read 0 from tuyaRgbMode
• I get UNSUPPORTED_ATTRIBUTE from tuyaBrightness.

Not sure if the PR matches the symptoms but at least it should respect the doc now.

I'm not sure how I can get ember to log frames so that I can check that the data type matches what we get from the protocol when reading the attribute. (Spec, section 2.5.2.1.5.
I'll let you decide if you're confident enough that this should be merged anyway.

---

Side note: it would be nice if from the dev console we could read attributes from their IDs, manually specifying cluster ID, attribute id, and output type, bypassing the hardcoded values. This is especially relevant when trying to read non-standard attributes (whose type may differ from one manufacturer to the other), or when trying to set attributes with directly the manufacturer's datasheet at hand.
Same for commands. Is there a tool that already allows doing that?

Context: With my Tuya light when I ask it to turn on with a specific RGB value it first sends a command to turn on, which brings back the state before turn off, then transitions to new color (in 0.1 seconds at best). That is an issue for night lights, that will first turn on to day-color light before transitioning to red. I'm trying to debug this, hopefully by casting a command that will do both. Scene restoration instantly puts it in the correct mode so I assume there's a way to do that, maybe by registering a scene then instantly applying it, maybe by something like this. However direct scene insertion currently seems to only create scenes with {"currentHue":253,"currentSaturation":254} although it respects brightness, so it may be broken as well to some extent, since Tuya scene data is suposed to be able to store HSV.

---

Side note 2: I can see that Tuya isn't necessary the best at respecting the standard and not having such weird quirks. Who is? Thanks! 🙏😊

[Nerivec]

Ref impl in #237

It also looks like tuyaRgbMode is also not quite the proper name for it since values appear to be:

    0: White light
    1: Colored light
    2: Scene
    3: Music

Could this stem from a spec change on Tuya's side which modified attributes in more recent versions (PR above is from 2020)?

[Ten0]

Could this stem from a spec change on Tuya's side which modified attributes in more recent versions (PR above is from 2020)?

I'm not 100% sure, that's why it might be worth having a way to know what type the attributes are when sent back, since the protocol gives back the type when it gives an attribute.

[Koenkk]

Thanks!

[Koenkk]

@Ten0 would you mind making a follow up PR to rename the attribute to tuyaColorMode ? There are a few occurrences in zhc that would need to be updated too: https://github.com/search?q=repo%3AKoenkk%2Fzigbee-herdsman-converters%20tuyaRgbMode&type=code

[Nerivec]

Probably should be DataType.ENUM8 too, since according to the mentioned docs, it has specific values attached, it's not just a plain uint8.