Get current RGBA value and set it

[quarcko]

When controlling gateway from Homekit, this implementation correctly updates state (on/off)
but does not update brightness and color (if it is set from homekit)

this patch adresses that and parses incoming value.

[cadavre]

Hi @quarcko, no idea how, but I missed your pull request. :o

I'll review it soon, probably make one method extraction (calculation on rgba struct), test and merge.

[quarcko]

So, any progress on this merge?

[cadavre]

@quarcko got one question. I haven't implemented setting HA color state from gateway data (Homekit or HA itself) because I had problem with finding right struct. Sometimes there was 1 byte shift and on edge settings for R, G or B (can't remember now) the color was totally different that is suppose to be.

Can you check it for 100% R, 100% G and 100% B? Confirm if value set is the same as displayed in HASS.

[quarcko]

@cadavre As far as i tried this modification until now it always gave me good values,
because i have my gateway added to HA twice, one via Homekit and second via your library.
So some automations from old times still do it via Homekit, and color is normally updated to your library also... did not spot any misbehaviour so far.

[cadavre]

I've made my testing based on previous implementation attempts.

Look what I test:

1. R (255, 0, 0) with 100% brightness – {"method": "set_rgb", "params": [1694433280]}.
2. G (0, 255, 0) with 100% brightness – {"method": "set_rgb", "params": [1677786880]}.
3. B (0, 0, 255) with 100% brightness – {"method": "set_rgb", "params": [1677721855]}.

I set above values via HA, then I wait for gateway to response with rgb.

RED:
Sending data:
b'{"id": 7, "method": "set_rgb", "params": [1694433280]}'
Received data:
b'{"id":545,"method":"props","model":"lumi.gateway.mieu01","params":{"from.rgb":",,,","rgb":1694433280}}\x00'

GREEN:
Sending data:
b'{"id": 10, "method": "set_rgb", "params": [1677786880]}'
Received data:
b'{"id":554,"method":"props","model":"lumi.gateway.mieu01","params":{"from.rgb":",,,","rgb":1677786880}}'

BLUE:
Sending data:
b'{"id": 9, "method": "set_rgb", "params": [1677721855]}'
Received data:
b'{"id":552,"method":"props","model":"lumi.gateway.mieu01","params":{"from.rgb":",,,","rgb":1677721856}}\x00'

• R is correct.
• G is correct.
• B is not correct. It differs in (decimal) 1.

Now, if we take this test script:

import binascii
import struct

# Using algorithm from @roth-m
def raw2rgba(rgba_raw):
    rgbhexstr = "%x" % rgba_raw
    if len(rgbhexstr) <= 8:
        rgbhexstr = rgbhexstr.zfill(8)
        rgbhex = bytes.fromhex(rgbhexstr)
        rgba = struct.unpack('BBBB', rgbhex)
        brightness = rgba[0]
        rgb = rgba[1:]
        print(brightness)
        print(rgb)

print("Sent: red (255, 0, 0)")
raw2rgba(1694433280)
print("Received")
raw2rgba(1694433280)
print("")
print("Sent: green (0, 255, 0)")
raw2rgba(1677786880)
print("Received")
raw2rgba(1677786880)
print("")
print("Sent: blue (0, 0, 255)")
raw2rgba(1677721855)
print("Received")
raw2rgba(1677721856)

This is what we will get:

Sent: red (255, 0, 0)
100
(255, 0, 0)
Received
100
(255, 0, 0) # OK

Sent: green (0, 255, 0)
100
(0, 255, 0)
Received
100
(0, 255, 0) # OK

Sent: blue (0, 0, 255)
100
(0, 0, 255)
Received
100
(0, 1, 0) # very NOK

Result:
Blue sent by gateway to HASS will be converted to 100% brightness green. <= NOK

I found no way to fix this. :/ That's why I abandoned receiving and parsing rgb from gateway. :/

Can you confirm this above? What you're saying is that you have Gateway with Homekit version? Maybe they've fixed it and we can find to patch it?

[quarcko]

Okay, now clearer for me what to test, so i tried and got same results as you... there is 1 difference.
So i thought - easy peasy, just lets do -1 always (it wont hurt anyway) and voila, but, there are situations where this difference is larger:

1694498641 -> 1694498688

And some others, did not wrote them down, but it is even worse than just -1 difference....

So my only thoughts are - maybe when you "want" to set specific color you set it,
but gateway returns you back "what really was set" ? so you just take it and parse as it is?
and yeah... -1 always :)

Also yes, my gateway is "lumi.gateway.aqhm01"
hackable in similar way, just a little bit harder because there is no preinstalled dropbear binaries
and you have to get them from debian armhf repos and send them over serial line during rooting.

[cadavre]

-1 was my first try to fix it, but no – it doesn't work. :/

On miio_gateway component init I don't ask for current rgb on purpose because of this error.

In most cases – if you can set rgb color only via HASS (hass itself, homekit bridge, google assistant etc.) – I'm leaving set and not updating rgb on response from gateway. This was color is always up-to-date within HASS UI.

Have you thought on moving from gateways' Homekit integration to HASS Homekit bridge? I actually use it this way, so there's only one single-source-of-truth for gateway to be set (via hass).

I would prefer for this to work properly in case described above but not broke things to work 50% everywhere.

We should think of fixing this responses, because in Miio Home app they've managed it somehow. :)

[quarcko]

It is indeed much muhc worse than just -1... here are results whem R & G are 255 const. and B {0-255}:

1694498560 | 1694498560
1694498610 | 1694498560
1694498619 | 1694498560
1694498630 | 1694498688
1694498640 | 1694498688
1694498649 | 1694498688
1694498660 | 1694498688
1694498669 | 1694498688
1694498680 | 1694498688
1694498689 | 1694498688
1694498700 | 1694498688
1694498710 | 1694498688
1694498719 | 1694498688
1694498730 | 1694498688
1694498739 | 1694498688
1694498750 | 1694498688
1694498759 | 1694498816
1694498770 | 1694498816
1694498780 | 1694498816
1694498789 | 1694498816
1694498800 | 1694498816
1694498809 | 1694498816
1694498815 | 1694498816

It looks like it only can report "B" in 3 levels total....

[quarcko]

OK, i give up. This is nuts.

The only possible way i can think of, is modifying "miio_client" binary, so it does not pass this command to the "gw.mi" binary (which i watched in terminal, it is source of bad data)
but read the real values of

/sys/class/backlight/lumi_r/actual_brightness
/sys/class/backlight/lumi_g/actual_brightness
/sys/class/backlight/lumi_b/actual_brightness

compose correct struct & send it back, but this is nuts, and not worth it,
and anyway it will give some deviation which just might be intolerable.

[cadavre]

Unfortunately with #1 (comment) – it seems that there's nothing we can do.

Or maybe any updates since then?