Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DDF clone and fixes for Tuya Smart Knobs (_TZ3000_* TS004F) #7904

Merged
merged 7 commits into from
Sep 30, 2024

Conversation

chishm
Copy link
Contributor

@chishm chishm commented Aug 26, 2024

This follows on from the work of @manup in #6242, to add device clones of the Tuya Smart Knob and to extend the current capabilities of the DDF.

Each way of pressing and turning the knob is now indicated by a different button code. There are 2 modes ("command" and "event") and two distinct rotations in command mode (just rotate vs press down and rotate). E.g. rotating clockwise in command mode will give button code 1030, pressing and rotating in command mode gives code 2030, and rotating in event mode gives code 3030 (there is no press and rotate for event mode).

There is now a resources item (config/mode) to discover the current mode ("command" or "event").

The state/angle value is now a relative angle for the current rotation event. It didn't make sense to have a single absolute angle when the device can be twisted in multiple ways.

The device will now send commands to the correct group address. This is achieved using the Add Group command in the Group cluster. Having to do so is a quirk of this device (and possibly other Tuya devices).

NB: The group add command is performed using a script in the DDF. To support this, the C++ code was modified to allocate "auto" groups before calling any write function in the DDF.

Extending the implementation detail of @manup's work, the state/ct item is used to parse the Color Control cluster for pressed-down rotations. The item is set to "public": false and is not exposed to the REST-API.

TODO: The battery level is not being reported for some reason.

A lot of this work drew upon knowledge provided by others. I'd like to thank:

* Add manufacturername values for more Tuya Smart Knobs
* Generate unique button events for each mode of pressing and rotating
  the knob
* Provide attribute (config/mode) to discover current mode (command vs
  event)
* state/angle is now a relative angle for the current rotation event
* ZigBee bindings now performed using group membership (commands are no
  longer sent to group 0)
It's handled as an attribute change, and the extra code caused issues for
the rest of the javascript file.
Copy link
Contributor

github-actions bot commented Aug 26, 2024

Hey @chishm, thanks for your pull request!

Tip

Modified bundles can be downloaded here.
Relative expire date

DDB changes

Modified

  • tuya/_TZ3000_TS004F_smart_knob.json : Smart Knob (TS004F) ✔️

Validation

Tip

Everything is fine !

🕡 Updated for commit c1b67eb

@Smanar
Copy link
Collaborator

Smanar commented Aug 26, 2024

Nice, so much work on thoses device, I realy like your JS scripts with all comments, but I have a doubt, how the JS core will handle them, it will ignore them, or use memory for nothing ? On my side I make shorter code possible, but less instructive/reusable than yours.

TODO: The battery level is not being reported for some reason.

Yeah, good question, I don't see the problem too, still nothing after a time ? if the binding don't work, you can have the poll. If you try to read the attribute in deconz it update the value in the API (take care you can test that only 1 time ^^)

    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0000"
    },

You are sure this part is usefull ?

BTW the bot that validate DDF need to take some holidays, embittered bot ....

@manup
Copy link
Member

manup commented Aug 26, 2024

Nice, so much work on thoses device, I realy like your JS scripts with all comments, but I have a doubt, how the JS core will handle them, it will ignore them, or use memory for nothing ?

Currently the comments are read and "processed" by DucktapeJS, but that can be changed in future so they are ignored when loading the JS files and not even processed then compiling the Javascript byte code.

So imho I think it's fine to keep them, especially if they help other devs to understand the script.

@chishm
Copy link
Contributor Author

chishm commented Aug 27, 2024

Nice, so much work on thoses device, I realy like your JS scripts with all comments, but I have a doubt, how the JS core will handle them, it will ignore them, or use memory for nothing ? On my side I make shorter code possible, but less instructive/reusable than yours.

Thank you. I found the comments necessary for my own understanding. With all the magic constants used it was becoming hard to follow what I'd written a few days earlier. As @manup said, it'd be better if the comments could remain but be ignored during loading of the scripts.

    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0000"
    },

You are sure this part is usefull ?

No, it's not necessary. I'd left it in after trying to debug a problem I had with retrieving the firmware version number (turned out I'd forgotten to include tuya_swversion.js in my DDF). I've removed it now, tested, and everything seems fine.

TODO: The battery level is not being reported for some reason.

Yeah, good question, I don't see the problem too, still nothing after a time ? if the binding don't work, you can have the poll. If you try to read the attribute in deconz it update the value in the API (take care you can test that only 1 time ^^)

BTW the bot that validate DDF need to take some holidays, embittered bot ....

Turns out the bot was being helpful after all. It'd put " eval" instead of "eval" for the parse script of config/battery, and this was causing my battery reporting problem. I've also removed the polling, as the device reports its battery level correctly.

@Smanar
Copy link
Collaborator

Smanar commented Aug 27, 2024

From the bot you miss

        {
          "name": "cap/color/ct/max"
        },
        {
          "name": "cap/color/ct/min"
        },

But here I don't understand the problem, on my side I will remove all this part.

Error: Unrecognized key(s) in object: 'buttons', 'buttonevents'

@Zehir
Copy link
Collaborator

Zehir commented Aug 27, 2024

Error: Unrecognized key(s) in object: 'buttons', 'buttonevents'

They should be on the subdevice no the root level of the DDF

https://github.com/dresden-elektronik/deconz-rest-plugin/pull/7904/files#diff-683a795de9d78e2e89d35aa871936863fc4cf25618c96426688c1c88c8659d52R24-R84

Added to satisfy the DDF validator. The values originally came from the
STEP_COLOR_TEMPERATURE command sent by the device.
@chishm
Copy link
Contributor Author

chishm commented Aug 28, 2024

Thanks, @Smanar and @Zehir for your help with getting the DDF syntax right. I couldn't find devcap1.schema.json in the repo, so I've been using existing DDF files as examples, and obviously got a few things wrong there.

@chishm
Copy link
Contributor Author

chishm commented Sep 13, 2024

Hi @Smanar and @manup,

Is there anything else I need to do before this can be merged?

@Smanar
Copy link
Collaborator

Smanar commented Sep 16, 2024

For me there is no problem, and you have the device to make test, perhaps the c++ part need a special Milestone ?

@manup
Copy link
Member

manup commented Sep 23, 2024

Good work 👍 I think the PR is fine now. One question since I don't understand every detail of it, is this a breaking change REST-API wise how the modified devices work?

@chishm
Copy link
Contributor Author

chishm commented Sep 26, 2024

@Smanar: That makes sense that the maintainers might be waiting for the next release to merge this.

@manup: It is a breaking change for two items: the state/angle value is now relative, and state/buttonevent has some more values reported for the different ways that the knob can be pressed and turned.

@manup
Copy link
Member

manup commented Sep 30, 2024

Thanks for clarification I think the change is fine in order to make the device more usable.

@manup manup added this to the v2.29.0-beta milestone Sep 30, 2024
@manup manup added Device Improvement Additional tag to attach to a existing issue. Breaking Change labels Sep 30, 2024
@manup manup merged commit f3129fb into dresden-elektronik:master Sep 30, 2024
1 check passed
Copy link
Contributor

This pull request is now merged. The new DDB files have been uploaded to the store.

DDB Files

Modified

  • tuya/_TZ3000_TS004F_smart_knob.json : Smart Knob (TS004F) : with hash (79b0ae6878)

🕠 Updated for commit f3129fb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Device Improvement Additional tag to attach to a existing issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants