Closed Lurker00 closed 3 months ago
Why not add a condition in brightness to ensure the brightness is not None
?
https://github.com/xZetsubou/hass-localtuya/blob/cdc12573967e7db6dbfb5fbcf4cb711ab7536807/custom_components/localtuya/light.py#L189-L195
With condition:
def brightness(self):
"""Return the brightness of the light."""
if self._brightness is not None and (self.is_color_mode or self.is_white_mode):
return map_range(
self._brightness, self._lower_brightness, self._upper_brightness, 0, 255
)
return None
edit: do mind posting the device diagnostics I want to take a look to the device properties.
Why not add a condition in brightness to ensure the brightness is not None?
For two reasons:
None
". As I understand, the whole code (both HA abstraction level and the integration) was written presuming that all the propeties were initialized by querying the bulb initially.do mind posting the device diagnostics
If I understand you correctly, I've attached it. You can see that I forced all the properties to be "cloud pull". localtuya-944c1616039a1d1ec6b9745179bff74e-КЛ1_ LED BULB B5K-1ae4e56ffcf36ae73a5bd7ddf02dd49e (2).json
The calls will made every time the status updated, so I think adding the condition is better and it won't update the brightness unless the brightness defined which is will do if the device later sent an update for brightness DPID.
A tip you may want to try is rather than using non-existing DPIDs such as 101 or so. is putting only "0" on manual DPS this will ignore the handshake and later I can changed it so it will restore old cached states in HA, so on the next times you connect to the device it restore the old states rather then waiting for the device to reports.
So here Is what I want to test:
OK, I'll do the tests you asked for and report.
But one more wish then: could you please document these "magic" numbers - +100 (to force cloud pull) or 0 for manual DPS! It took me a while until I found +100 in issue #90, and I never saw about 0.
It does kinda exists in IR Remote FAQ because this was made for IR Remote purpose. 😅 The FAQ page has been added recently.
So here Is what I want to test:
- Add a condition as I suggest in [Bug]: Exception with BLE bulbs #190 (comment)
- Re-add the device and insert only "0" in manual DPS field.
It works: bulbs were added, they are active, no exceptions after I controlled them using scene switch buttons. I can control them from automation.
This issue was closed because it was resolved on the release: []()
LocalTuya Version
3.2.5.1
Home Assistant Version
2024.03.1
Environment
What happened?
I have some BLE bulbs, and experience the problems discussed in issue #90. Probably I'll create another issue later, but, for now, I ask you to make a small change in the source code: https://github.com/xZetsubou/hass-localtuya/blob/master/custom_components/localtuya/light.py
class LocaltuyaLight(LocalTuyaEntity, LightEntity)
, remove lineself._brightness = None
(currently 146).self._brightness = self._upper_brightness
I.e. initialize
self._brightness
with a suitable integer value instead ofNone
.Explanation: The bulbs don't allow to connect to their datapoints, but sometimes they report something, including brightness change. In the event handler,
brightness
method is called, which callsmap_range
withself._brightness
as the 1st parameter (=None
), causing an exception whenNone
is used in the arithmetic expression.I believe you understand that this change does not hurt! The second one I've made you've already implemented in 3.2.5.1 (
self._scenes = {}
instead ofNone
). It caused me exceptions as well when a BLE bulb reported mode change.Thanks in advance!
Steps to reproduce.
You need to have a BLE bulb and change its parameters by Smart Life automatition. So please just trust me :)
Relevant log output
Diagnostics information.
No response