Strange twinkly

[michalk-k]

Recently I was looking at my twinkly lights (250 led Christmas tree: TWS250STP-B)
They draw current in extraordinary ways.

At first glance, consumption does not vary on light intensity.
But measurement results were even more shocking:

• The more intensity the lower consumption.

for average effect, 22.65W for 1% while 22.15 for 100%.

But that's not all. for 100% white it's only 18.8W. For 100% red it's 22.3W
Just so you know, the string is RGB only.

It means that providing close-to-reality measurement is impossible.

to know: The Twinkly device has a memory, and a user can upload effects into, and then switch between them. A user, with use of Twinkly app can download a variety of effects/animations or create their own.

What do you think? I think it's better to have any measurement rather than none.

It might be follow-up to the discussion found at #2724

[bramstroker]

Recently I was looking at my twinkly lights (250 led Christmas tree: TWS250STP-B) They draw current in extraordinary ways.

At first glance, consumption does not vary on light intensity. But measurement results were even more shocking:

• The more intensity the lower consumption.

for average effect, 22.65W for 1% while 22.15 for 100%.

Are these results reproducable?
With average effect you mean you tested several effects?
How many built-in effects are there in total?

But that's not all. for 100% white it's only 18.8W. For 100% red it's 22.3W Just so you know, the string is RGB only.

It means that providing close-to-reality measurement is impossible.

The hs measure should capture these values just fine.

to know: The Twinkly device has a memory, and a user can upload effects into, and then switch between them. A user, with use of Twinkly app can download a variety of effects/animations or create their own.

We can obviously not support that. But we might set a config_flow_discovery_remarks in model.json which some warning / explanation about this.
So the user gets noticed that the power might be off when using custom memory effects and he/she should consider making a custom profile.

What do you think? I think it's better to have any measurement rather than none.

Yes I think we can include the profile to support 90% of the cases. For the custom uploaded effects see my suggestion above.

[michalk-k]

Are these results reproducable?

Yes

With average effect you mean you tested several effects?

Correct. I've tested several classic effects I like to see on Christmas tree. Not measured not fitting animations.

How many built-in effects are there in total?

Theer are 15 slots in the TWS250STP-B model. A user can overwrite them with his ones (or downloaded from Twinkly db)

[michalk-k]

BTW entering a highest value for the lowest brightness is impossible.
Are you sure that it will work properly with measurement?

[bramstroker]

Correct. I had such a plan. However

• not sure the tool samples all possible combinations or just some of them and then interpolates. (hence worry related to the limitation exposed in GUI)

The measure tool takes a lot of samples (different brightness levels, color temperatures and sat, hue) levels. During calculation it interpolates. We cannot take al samples as it would be millions and measure session would take weeks.
Please read it up here: https://docs.powercalc.nl/strategies/lut/

The GUI dialog you are refering to is for the linear strategy: https://docs.powercalc.nl/strategies/linear/. It's a completely different way of calculation so the "limitations" here do not apply to the LUT strategy.

• tbh not sure if sampling Christmas lights in RGB mode does make any sense. Nobody uses flat colors on such lights.

Which color modes do the light have?

• Another model got the profile with a fixed consumption value (see Add Twinkly 600 #2724). I found we could go more precise based on brightness, but it results in a negative brightness-to-consumption relationship

I see what you mean. You mean with the negative brightness-to-consumption relationship the linear mode you used now. Could you elaborate. I don't fully understand. How were you able to set up linear mode correctly when it gave the validation error.

• In the meantime I tried to set it up using GUI, being curious about how it would cope with this relationship

Same as above, I don't fully grasp how exactly you have set it up now.

not sure if it's worth such detail though, since every user will use different animation/effect

We could maybe also have a look into providing 15 different "sub profiles" and dynamically switch them based on selected effect.
Each sub profile can then just have a linear configuration for the specific effect.
See: https://docs.powercalc.nl/library/structure/#sub-profiles
And for example:
https://github.com/bramstroker/homeassistant-powercalc/blob/master/profile_library/lifx/LIFX%20A19%20Night%20Vision/model.json
Similarly to entity_state matcher there is also an attribute matcher.

{
        "type": "attribute",
        "entity_id": "effect",
        "map": {
          "effect1": "effect1",
          "effect2": "effect2",
        }

Or we might also use composite mode. There is no library profile currently using that, but I added support for that a few weeks ago.
https://docs.powercalc.nl/strategies/composite/

[michalk-k]

Which color modes do the light have?

We still talking about Twinkly Strings. It provides RGB only, but... nobody uses those lights this way. We use effects/animations. Thus the only practical approach is to provide measurements for various brightnesses (or linear one between 1 and 100%).
In mentioned PR you accepted fixed consumption though, right? So it would be an improvement.

Could you elaborate? I don't fully understand. How were you able to set up linear mode correctly when it gave the validation error.

In the OP I provided measurements that prove, that the energy consumption for 1% of brightness is higher than for 100% of brightness for the Twinkly device (I have to confirm that for Icicle, but my bet is all of them will behave this way)

Here is how the GUI behaves, when trying to add
(BTW the edit fields could be rather named: power for minimal and maximal brightness).

We could maybe also have a look into providing 15 different "sub profiles"

If it ever makes sense. Because users can create their own effects or download them. So once they upload the effects to the device, measurements will be off anyway.

The only idea is to assume, that most users use built-in animations. Then LUTs or Linear measurements for exact effects (by name) could be some way. Until users don't upload other animations with the same name as the original effect ;)

[bramstroker]

Which color modes do the light have?

We still talking about Twinkly Strings. It provides RGB only, but... nobody uses those lights this way. We use effects/animations. Thus the only practical approach is to provide measurements for various brightnesses (or linear one between 1 and 100%). In mentioned PR you accepted fixed consumption though, right? So it would be an improvement.

Yes I agree, linear mode is an improvement over this.

Could you elaborate? I don't fully understand. How were you able to set up linear mode correctly when it gave the validation error.

In the OP I provided measurements that prove, that the energy consumption for 1% of brightness is higher than for 100% of brightness for the Twinkly device (I have to confirm that for Icicle, but my bet is all of them will behave this way)

Still find this very strange and hard to believe, don't have these lights myself to verify. Do you actually see the brightness go up and down?
@brianegge Could you do same measurement for your Twinkly and see if you get similar results?

Here is how the GUI behaves, when trying to add (BTW the edit fields could be rather named: power for minimal and maximal brightness).

Yes you already indicated that before that you got this validation error.
That's why I asked how you were able to set it up, as the config flow should prevent you from going further as you input a higher value in the min power than max power.
When we actually have verification that the Twinkly lights are indeed consuming less power when brighter than we need to see how we can allow to set this up. But I'm hestitant to remove the validations.

We could maybe also have a look into providing 15 different "sub profiles"

If it ever makes sense. Because users can create their own effects or download them. So once they upload the effects to the device, measurements will be off anyway.

The only idea is to assume, that most users use built-in animations. Then LUTs or Linear measurements for exact effects (by name) could be some way. Until users don't upload other animations with the same name as the original effect ;)

I think it would make sense to provide 15 profiles for the built-in effects, as most users want take the time and effort to setup custom effects.
We can put discovery flow remark in model.json to notice the user the profile can only be used for built-in effects. When a custom effect is choosen the power sensor will just to unavailable.
Yes there is still a change user name the same as original effect, but there is not much we can do in that way. Just no way to know.

[michalk-k]

Still find this very strange and hard to believe, don't have these lights myself to verify. Do you actually see the brightness go up and down?

Yes, it's surprising. Not only for you. Yes, brightness changes reflect in actual light brightness.
I measured another twinkly: Icicle TWI190SPP. It behaves the same. See the video

The difference is about 3%, right? Is it significant enough it should be reflected in the profile?
And if so, is it safe to do it this way (looks awful btw ;) )?

"linear_config": {
    "min_power": 22.65
    "max_power": 22.15
  },

cc: @brianegge

[bramstroker]

"linear_config": {
    "min_power": 22.65
    "max_power": 22.15
  },

@michalk-k Yes seems fine by me. Did you try if this was working using linear_config in model.json like this?
Or does it also complain about validation that max must be higher than min?

[brianegge]

In my PR for the strings 600, the power curve was effectively flat across the brightness range. Any effect was within a few percentages of the power for anything else. I don’t recall the power curve being inverted, but the graph is probably still in my PR. After all that we decided it was simpler just to have a fixed value. Even effects can be customized with color, brightness and speed, and I couldn’t make any of them move the power usage much. My guess is the twinkly light has some sort of fourth resistor which helps keep the brightness even across the string.

[brianegge]

[michalk-k]

Just a heads up to my answer above (it's threaded so maybe it's missed)
there is proof of lower consumption when more intense light.
#2855 (reply in thread)

BTW my colleague says it's not something unusual. PWM modulators disperse energy during modulation. It's the question of their effectiveness.

[bramstroker]

Thanks for sharing! we learn something new every day ;-)