Skip to content

Added incrementBrightness support for groups - #417

Merged
Foddy merged 3 commits into
Foddy:masterfrom
fjulian79:master
Nov 6, 2024
Merged

Foddy merged 3 commits into
Foddy:masterfrom
fjulian79:master

Conversation

@fjulian79

Copy link
Copy Markdown
Contributor

Hi folks ..

I have added the missing incrementBrightness support for groups which is reported in issue #380. In my opinion it is mandatory when huemagic shall be used to connect KNX switches to Philips Hue. I have done it in the following way:

  • When the user wants to dimm the lights, he has to presses and hold the KNX switch, this causes a message on the bus which is received by node-red.
  • A incrementBrightness (+/-100%, depending on the direction) command with a significant transitionTime (4 seconds) is invoked.
  • The lights start to dimm.
  • When the user wants to stop the process he releases the switch, this causes a further "stop" message on the bus which is also received by node-red.
  • A incrementBrightness (value = 0) command is invoked which stops the currently ongoing transition.

This is the best way to get this done because:

  1. Only two hue api calls are needed
  2. The brightness transition itself is flawless as is done inside of the hue system.

But for this approach incrementBrightness support is mandatory .. see also the official v1 api docs on the bri_inc argument. I have found it while searching for a proper way to get the task done as my other attempts have been suboptimal.

If there is a good reason to get the task done in a different way, let me know ;-)

br J.

@peterbaker

Copy link
Copy Markdown

Awesome! Thank you for doing this. Now how do we get @Foddy to merge it so we can get this in the easy Node Red installer?

@peterbaker

Copy link
Copy Markdown

@fjulian79 Could you implement decrementBrightness too?

@fjulian79

fjulian79 commented Mar 1, 2023 •

Copy link
Copy Markdown
Contributor Author

@peterbaker maybe the name is misleading but you can use negative values too:
incrementBrightness +10 --> 10% brighter
incrementBrightness -10 --> 10% darker

So what you request is already there, it would be just another name and inverse logic:
decrementBrightness -10 --> 10% brighter
decrementBrightness +10 --> 10% darker

So I think this would not add a lot but would bloat the code.

Finally .. there is a fork of this repo which is way more agile, see https://github.com/mauricedominic/node-red-contrib-huemagic.git I have filed my pull request over there as well and it has been accepted. So maybe switching to mauricedominic is a valid option.

@peterbaker

Copy link
Copy Markdown

I did notice that increment works both ways after I wrote that, but also I still think it'd be useful (maybe just to me) to have decrementBrightness as that was how HueMagic 3 worked and including it would maintain existing flows.

Either way, just glad to see a path towards actually being able to use HueMagic 4. Thank you!

@peterbaker

Copy link
Copy Markdown

Also, it would then mirror the commands for individual lights (which have both incrementBrightness and decrementBrightness).

@fjulian79

Copy link
Copy Markdown
Contributor Author

@peterbaker Ack, I agree! I have not had those background info's ;-) I will try to get it done in the next days.

@fjulian79

fjulian79 commented Mar 2, 2023 •

Copy link
Copy Markdown
Contributor Author

@peterbaker I'm done .. I have tested decrementBrightness with my lamps, works fine from my point of view.

@Foddy
Foddy merged commit 8b8b5fe into Foddy:master Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants