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

brightness/power limit #352

Merged
merged 8 commits into from
Jun 28, 2020
Merged

brightness/power limit #352

merged 8 commits into from
Jun 28, 2020

Conversation

zomfg
Copy link

@zomfg zomfg commented Jun 5, 2020

This is for #342, which reminded me of a similar thing implemented on WLED, both are good ideas, so I added them:

  • brightness cap (in device tab): to limit brightest LEDs as per request
    image

  • power supply limit (in device wizard): inspired by WLED, the idea is to put current requirements per LED and whatever current the power supply can provide and if the estimated current requirement for a given frame goes over the limit readjust the colors to fit within the limit
    image
    The caveat is that IRL it's not linear and depends on different things, but it's a start.

@psieg
Copy link
Owner

psieg commented Jun 20, 2020

Thanks, I'll take a look when I have some time (hopefully next week). (I didn't forget it, it's just more time needed to review)

Copy link
Owner

@psieg psieg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks mostly solid, thanks.
I would add a question mark with explanation for the brightness cap to explain how it's different from the brightness multiplier and what's the use-case (most people will want to leave it at max, while adjusting overall brightness should be more common), WDYT?

}
namespace AlienFx
{
static const QString NumberOfLeds = "AlienFx/NumberOfLeds";
static const QString LedMilliAmps = "AlienFx/LedMilliAmps";
static const QString PowerSupplyAmps = "AlienFx/PowerSupplyAmps";
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AlienFX has no power supply AFAIK, it's part of the PC. But special-casing it is probably not worth the effort.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point (unless repurposed!). I'll have to take that into consideration while looking into devices (see below)

}
namespace Lightpack
{
static const QString NumberOfLeds = "Lightpack/NumberOfLeds";
static const QString LedMilliAmps = "Lightpack/LedMilliAmps";
static const QString PowerSupplyAmps = "Lightpack/PowerSupplyAmps";
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering whether this needs to be stored separately per device. Users normally have only one device, and if the defaults are identical across devices, what's the value of having separate keys for this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's consistent with NumberOfLeds which has the same "issue". But I was thinking about looking into a way to have multiple devices, which would also mean multiple devices of the same type, and that'll probably make current device settings storage inadequate anyway, so I'll leave that as is for now.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, NumberOfLeds has different defaults and limits across devices, but yeah.

else if (field("isVirtual").toBool())
device = SupportedDevices::DeviceTypeVirtual;
else if (field("isAlienFx").toBool())
device = SupportedDevices::DeviceTypeAlienFx;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider putting this block in a helper function (for readability and to avoid going out of sync)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I don't like the current way of handling device types and grabbers. I'm sure it was fine at the start, but as both lists grow you have to duplicate tons of stuff all over the place and have this kind of redundancies.
Since the addition of UDP stuff I wanted to take a look at that, probably before multidevice thing. So I'll leave that for a future PR.
If you already have some ideas on both subjects I'm all ears.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some issues can be solved through the inheritance (as already is the case) but especially at the intersection with the UI some manual switching/selecting will be necessary I think

@zomfg
Copy link
Author

zomfg commented Jun 24, 2020

I was hoping the name would be enough to get the basic purpose, and people who are savvy enough to worry about power and heat would probably naturally look for a setting like that (like the person asking for the feature), but eh, it's simple enough to add, sure :)

@psieg psieg merged commit 3a085dd into psieg:master Jun 28, 2020
@zomfg zomfg mentioned this pull request Aug 3, 2020
@zomfg zomfg deleted the feature/power-limit branch August 13, 2020 16:52
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.

2 participants