-
Notifications
You must be signed in to change notification settings - Fork 503
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
DDF clone and fixes for Tuya Smart Knobs (_TZ3000_* TS004F) #7904
Conversation
* 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.
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.
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 ^^)
You are sure this part is usefull ? BTW the bot that validate DDF need to take some holidays, embittered bot .... |
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. |
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.
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
Turns out the bot was being helpful after all. It'd put |
From the bot you miss
But here I don't understand the problem, on my side I will remove all this part.
|
They should be on the subdevice no the root level of the DDF |
Added to satisfy the DDF validator. The values originally came from the STEP_COLOR_TEMPERATURE command sent by the device.
For me there is no problem, and you have the device to make test, perhaps the c++ part need a special Milestone ? |
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? |
@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 |
Thanks for clarification I think the change is fine in order to make the device more usable. |
This pull request is now merged. The new DDB files have been uploaded to the store. DDB FilesModified
🕠 Updated for commit f3129fb |
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: