Skip to content

Conversation

@ebaauw
Copy link
Collaborator

@ebaauw ebaauw commented Feb 5, 2024

Fixes parsing the State attribute of the Hue Effects cluster, see #7551

  • Add support for mode 0x0007 with values for on, bri, and ct;
  • Make sure to return value for on, also for unsupported modes.

(Dunno why it lists all these commits, but only one changed file).

ebaauw added 30 commits March 3, 2023 12:47
Additional clusters for IKEA Vindstyrka, see #6756.
Fix `numtostr` and add debug log message.
Validator nonsense.
More validator nonsense
And even more validator nonsense
And even more validation nonsense
Remove workaround for GUI bug #6832.
Fix indentation.
Refine definitions of:
- _Hue Capabilities_ command in _Basic_ cluster;
- _Hue Button_ cluster.
@ebaauw ebaauw requested review from SwoopX and manup February 5, 2024 16:50
@ebaauw ebaauw linked an issue Feb 5, 2024 that may be closed by this pull request
2 tasks
@manup manup added this to the v2.25.3 milestone Feb 5, 2024
@manup
Copy link
Member

manup commented Feb 5, 2024

Looks fine but I wouldn't include the eslint comments.

@ebaauw
Copy link
Collaborator Author

ebaauw commented Feb 6, 2024

I would, obviously, but removed the comment.

I would hope the JS is parsed and compiled only once? Or is it compiled at every invocation (in which case, we might want to remove white space, comments, use short variable names, etc)?

@manup
Copy link
Member

manup commented Feb 6, 2024

Thanks, imho such things better go into a $EDITOR /eslint user.preferences or we provide a global one.

I would hope the JS is parsed and compiled only once? Or is it compiled at every invocation (in which case, we might want to remove white space, comments, use short variable names, etc)?

Right now it is actually parsed, compiled and executed on each invocation. I've looked into DuktapeJS docs and it is indeed possible to safe/reload the generated bytecode which would safe the repeated parsing and compile steps (still much slower than a V8 engine JIT, but safes a few cycles). I'm planning to test this out more but first some other refactoring needs to be done to cut more drastic bottle necks.

You can get a feeling on the performance by enabling MEASURE and JS debug logging. Even with the non optimized approach it's surprisingly fast on average and mostly uses less than 250 KB on RAM in total. We currently have a lot of other more heavier performance hogs in the C++ side of the code base.

But as said earlier for me JS should be kept to a minimum and really boring noob safe code :)
The main purpose is to do things like Item.val = Attr.val * 10. It's not always possible but 95% of our JS code should be like this and not much more complex, until a better solution is found for the remaining 5%.

From my point of view the more complex JS scripts we have are only temporary to figure out generic ways later on to tackle the tasks they do in a declarative way.

@manup manup changed the title Bug fix handling Hue Effects state attribute Fix handling Hue Effects state attribute Feb 7, 2024
@manup manup merged commit 8bedc9f into dresden-elektronik:master Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Philips Hue White Ambiance (LTW001) change state to „on“ automatically

2 participants