search

bramstroker / homeassistant-powercalc

Custom component to calculate estimated power consumption of lights and other appliances
MIT License
1.01k stars 262 forks source link

Lidl firmware bug #2598

Open RubenKelevra opened 2 weeks ago

RubenKelevra commented 2 weeks ago

Checklist

Describe the issue

Due to a firmware bug in many if not all lidl lamps, which will likely affect power calc profiles too:

I've noticed while profiling the Lidl desk lamp (https://github.com/bramstroker/homeassistant-powercalc/pull/2585) that it flickers off after sending the first turn on command with brightness=1.

So I investigated that further as I noticed a lot of flickering and not turning off properly on this and other lamps.

Turns out there is a firmware bug in all of my Lidl lamps, plus a couple that I don't own:

If you try turning them off with brightness values 1 or 2 they will report back, that they are off but instead will stay on.

If you turn them on again then, they will turn on (with brightness value 3 or above) they will flicker on and turn off again.

Here's the full description: https://github.com/Koenkk/zigbee2mqtt/issues/21286#issuecomment-2419551421

How does this affect powercalc?

I think not everyone will notice the flickering when measuring, so the profile data could be wrong for the first values of HS/Color Temperature, like it was for me. So it makes sense to recheck them to make sure none of the brightness=1 or brightness=2 values is like the standby power.

bramstroker commented 2 weeks ago

hmm that's a pity. There is also a setting in .env for the measure script to start with another brightness level MIN_BRIGHTNESS. So it makes sense to set this to 3 for the lidl lights. I have made a quick script to list the values for LIDL models:

lidl/14156506L
colorMode: color_temp standby:0.2 min: 1.18 max: 1.73
colorMode: hs standby:0.2 min: 0.33 max: 0.87

lidl/14158704L
colorMode: color_temp standby:0.6 min: 0.8 max: 3
colorMode: hs standby:0.6 min: 1.3 max: 2.9

lidl/14158804L
colorMode: color_temp standby:0.7 min: 0.96 max: 1.38
colorMode: hs standby:0.7 min: 0.88 max: 1.47

lidl/HG06104A
colorMode: color_temp standby:0.34 min: 1.94 max: 2.03
colorMode: hs standby:0.34 min: 0.33 max: 0.45

lidl/HG06106A
colorMode: color_temp standby:0.36 min: 0.45 max: 0.82
colorMode: hs standby:0.36 min: 0.26 max: 0.46

lidl/HG06106B
colorMode: color_temp standby:0.29 min: 0.79 max: 1.02
colorMode: hs standby:0.29 min: 0.27 max: 0.53

lidl/HG06106C
colorMode: color_temp standby:0.36 min: 1.14 max: 1.39
colorMode: hs standby:0.36 min: 0.27 max: 0.54

lidl/HG06462A
colorMode: brightness standby:0.2 min: 0.75 max: 0.85

lidl/HG06463A
colorMode: brightness standby:0.3 min: 0.81 max: 0.84

lidl/HG06467
colorMode: hs standby:0.47 min: 9.92 max: 18.96

lidl/HG06492A
colorMode: color_temp standby:0.45 min: 0.87 max: 0.95

lidl/HG06492B
colorMode: color_temp standby:0.31 min: 0.69 max: 0.94

lidl/HG06492C
colorMode: color_temp standby:0.31 min: 1 max: 1.1

lidl/HG07834A
colorMode: color_temp standby:0.28 min: 0.28 max: 0.42
colorMode: hs standby:0.28 min: 0.27 max: 0.45

lidl/HG07834B
colorMode: color_temp standby:0.38 min: 0.36 max: 0.63
colorMode: hs standby:0.38 min: 0.33 max: 0.76

lidl/HG07834C
colorMode: color_temp standby:0.42 min: 0.31 max: 0.47
colorMode: hs standby:0.42 min: 0.28 max: 0.64

lidl/HG08007
colorMode: hs standby:0 min: 0.4 max: 1

lidl/HG08008
colorMode: color_temp standby:0.2 min: 2.13 max: 2.38
colorMode: hs standby:0.2 min: 0.3 max: 0.77

lidl/HG08010
colorMode: color_temp standby:0.58 min: 0.7 max: 1.31
colorMode: hs standby:0.58 min: 0.67 max: 0.88

lidl/HG08383A
colorMode: color_temp standby:0.36 min: 0.26 max: 0.56
colorMode: hs standby:0.36 min: 0.01 max: 0.26

Most of them seem fine, but the following models are problematic on first glance: Especially the models starting with HG07834 (A to C) have similar issues.

Similar or lower value than standby: HG07834A (https://github.com/bramstroker/homeassistant-powercalc/pull/1464) HG07834B (https://github.com/bramstroker/homeassistant-powercalc/pull/598) HG07834C (https://github.com/bramstroker/homeassistant-powercalc/pull/662) HG08383A (https://github.com/bramstroker/homeassistant-powercalc/pull/1540)

Standby power of 0. Unsure why this has gone past QA checks. HG08007 (https://github.com/bramstroker/homeassistant-powercalc/pull/2444)

Some profiles were submitted 2 years ago, so it would be rather difficult to contact all the different contributors, ask them to remeasure etc. So best thing we can do imo is to remove the 1 brightness values from the concerning models. In this case the profiles will start with brightness level 6. Whenever someone puts the light on level 3-5 it will just take the value for level 6. But not a big chance someone puts the light on such a low brightness, and the power value will be close enough. Anyway better than the erronous value it will give now.

RubenKelevra commented 2 weeks ago

I think you missed a couple (if I understand your output correctly):

HG06104A:

hs standby:0.34 min: 0.33

HG06106A:

hs standby:0.36 min: 0.26

HG06106B:

hs standby:0.29 min: 0.27

HG06106C:

hs standby:0.36 min: 0.27

And HG08008 is suspicious, as it's just 0.1 W away from standby:

hs standby:0.2 min: 0.3
RubenKelevra commented 2 weeks ago

So best thing we can do imo is to remove the 1 brightness values from the concerning models. In this case the profiles will start with brightness level 6.

Maybe the best solution (for the future) is to modify the script, and add brightness=3, as that's 1% (as 2.56 will be rounded to 3) as a step. That's probably used much more often than brightness=1 by most people. Not saying we should drop measuring brightness=1, but maybe add an additional test for 1%, so we don't have to interpolate this value.

Some profiles were submitted 2 years ago, so it would be rather difficult to contact all the different contributors, ask them to remeasure etc.

I mean, we could try? :)

There is also a setting in .env for the measure script to start with another brightness level MIN_BRIGHTNESS. So it makes sense to set this to 3 for the lidl lights.

Yeah I saw that. But there's no documentation yet anywhere about this firmware bug, so nobody measuring would know that there's an issue. And since the users give away the control to the script, its rather challenging to understand that the flickering is not part of the measuring process.

So I expect future tests to be affected as well.

Maybe we could either check if the user entered "Lidl" or "Livarno" and let them confirm that it's a Lidl/Livarno lamp and just skip to 3 then?

Also a generalized sanity check for measurements would be good. Maybe check if one measurement is similar or lower than standby at the end makes sense. And if detected the profile isn't saved. Instead the user is asked to confirm the value. If he taps "enter" the script selects each of the low values and let the user confirm, that the light is on, before adding those values to the profile. Something like that.

RubenKelevra commented 2 weeks ago

I'm also in contact with Lidl, but yet no luck (yet) in getting someone past the front desk customer support, which wants to send me more lights as replacements.

https://github.com/Koenkk/zigbee2mqtt/issues/21286#issuecomment-2423789901

RubenKelevra commented 2 weeks ago

Maybe we could either check if the user entered "Lidl" or "Livarno" and let them confirm that it's a Lidl/Livarno lamp and just skip to 3 then?

Also a generalized sanity check for measurements would be good. Maybe check if one measurement is similar or lower than standby at the end makes sense. And if detected the profile isn't saved. Instead the user is asked to confirm the value. If he taps "enter" the script selects each of the low values and let the user confirm, that the light is on, before adding those values to the profile. Something like that.

Now when I'm thinking about it, the best solution would probably to turn the light for measurements on with the highest brightness setting, twice. Meaning sending two turn_on commands to the light, with transition: 0 and never turn the lights back off.

This would avoid both issues and would work regardless if the lights are in a weird state or not and I mean we need to turn the LEDs on before measurement for a while anyway, so they can stabilize. So it could be a generalized solution.

Dimming them down always works, lights will always report the right state etc. Granted, they might flicker once at the beginning before the second command is sent, if they are in those odd double off state. But this wouldn't matter, as we would dim them down again.

I recommend 2 seconds delay between the first and the second turn_on commands, so ZigBee and can properly process the response before the second command is set.

bramstroker commented 2 weeks ago

I think you missed a couple (if I understand your output correctly):

Yes I missed a few ;-)

bramstroker commented 2 weeks ago

Maybe we could either check if the user entered "Lidl" or "Livarno" and let them confirm that it's a Lidl/Livarno lamp and just skip to 3 then? Also a generalized sanity check for measurements would be good. Maybe check if one measurement is similar or lower than standby at the end makes sense. And if detected the profile isn't saved. Instead the user is asked to confirm the value. If he taps "enter" the script selects each of the low values and let the user confirm, that the light is on, before adding those values to the profile. Something like that.

Now when I'm thinking about it, the best solution would probably to turn the light for measurements on with the highest brightness setting, twice. Meaning sending two turn_on commands to the light, with transition: 0 and never turn the lights back off.

This would avoid both issues and would work regardless if the lights are in a weird state or not and I mean we need to turn the LEDs on before measurement for a while anyway, so they can stabilize. So it could be a generalized solution.

Dimming them down always works, lights will always report the right state etc. Granted, they might flicker once at the beginning before the second command is sent, if they are in those odd double off state. But this wouldn't matter, as we would dim them down again.

I recommend 2 seconds delay between the first and the second turn_on commands, so ZigBee and can properly process the response before the second command is set.

Sound like a plan. I don't like solutions like checking for lidl/livarno specific and than ask further questions. This would also complicate the code more. So a generic solution would be nice.

Are you able to implement and test if this is working correctly? I don't have any of this lights so it's rather hard to implement and verify.

bramstroker commented 1 week ago

@RubenKelevra Did you see my comments above? Are you able to implement this?