[hue] Brightness handling is inconsistent for some devices

[jlaur]

Another variation of #15905 is when the same state information as merged in that PR is sent in two separate messages (in this case having an existing dimming value of 0):

[
	{
		"creationtime": "2023-11-30T22:41:08Z",
		"data": [
			{
				"id": "00000000-0000-0000-0000-000000000001",
				"id_v1": "/lights/40",
				"on": {
					"on": true
				},
				"owner": {
					"rid": "00000000-0000-0000-0000-00000000000",
					"rtype": "device"
				},
				"type": "light"
			}
		],
		"id": "00000000-0000-0000-0000-000000000009",
		"type": "update"
	}
]

and:

[
	{
		"creationtime": "2023-11-30T22:41:25Z",
		"data": [
			{
				"dimming": {
					"brightness": 100.0
				},
				"id": "00000000-0000-0000-0000-000000000001",
				"id_v1": "/lights/40",
				"owner": {
					"rid": "00000000-0000-0000-0000-000000000000",
					"rtype": "device"
				},
				"type": "light"
			}
		],
		"id": "00000000-0000-0000-0000-000000000009",
		"type": "update"
	}
]

When processing the first message, on is changing from off to on, but dimming is still 0. This is a conflict, and currently the binding will interpret that as off/0:

Another variation of this scenario is when the same device is off, and then dimmed to a low value on its physical button. In that case we received on=on, but we don't receive any brightness value, so it will stay 0. Therefore it will also stay off. In the Hue app it will turn on with brightness 1%. The device does not have any defined minimum dimming level.

The logic applied on the inconsistent data is here:

openhab-addons/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/api/dto/clip2/Resource.java

Lines 169 to 188 in b490b56

	/**
	* Get the brightness as a PercentType. If off the brightness is 0, otherwise use dimming value.
	*
	* @return a PercentType with the dimming state, or UNDEF, or NULL
	*/
	public State getBrightnessState() {
	Dimming dimming = this.dimming;
	if (Objects.nonNull(dimming)) {
	try {
	// if off the brightness is 0, otherwise it is dimming value
	OnState on = this.on;
	double brightness = Objects.nonNull(on) && !on.isOn() ? 0f
	: Math.max(0f, Math.min(100f, dimming.getBrightness()));
	return new PercentType(new BigDecimal(brightness, PERCENT_MATH_CONTEXT));
	} catch (DTOPresentButEmptyException e) {
	return UnDefType.UNDEF; // indicates the DTO is present but its inner fields are missing
	}
	}
	return UnDefType.NULL;
	}

Expected Behavior

The latest received values should take precedence. If some information is missing in the received event, we should try to extrapolate.

Current Behavior

When receiving on=on, the brightness will stay 0% and effectively it will still be off.

Possible Solution

See discussion here: #15905 (comment)

Steps to Reproduce

Currently I have only reproduce this with an LK Wiser Dimmer which is based on Tuya technology, which means it is not fully Zigbee compliant.

Context

The consequence of this behavior is the same as described in #15700.

Your Environment

• Version used: 4.1-SNAPSHOT