[miio] Improve yeelight RGB with brightness, introduce substitutions

[marcelrv]

Main changes

• Introduce substitutions to allow to send commands containing current timestamp, deviceId or values from existing channels.
• Allow more complex conversions to use values from other channels (in this case used for yeelight rgb channel)
• Use generic way to call the asyncCommunication module
• Fix mapping of yeelights color channel
• Fix unit for yeelight delay

Signed-off-by: Marcel Verpaalen marcel@verpaalen.com

[marcelrv]

Note: the String sender is used in the next coming PR. already adding it to avoid merge issues while completing the development of the PR.

[mesetka]

Did the same changes in my fork few hours ago and tested with Yeelight lightstrip plus, worked properly. But i'm still in doubt, if there is a different logic in methods and status report.
And a question about Color mode channel - as I see it's supposed to run a method "set_power", "on", "smooth", "$value", so Yeelight device should react to channel switch by powering on in that color state? It doesn't. The channel is changing value only when i send rgb or ct commands.

[marcelrv]

Did the same changes in my fork few hours ago and tested with Yeelight lightstrip plus, worked properly. But i'm still in doubt, if there is a different logic in methods and status report.
And a question about Color mode channel - as I see it's supposed to run a method "set_power", "on", "smooth", "$value", so Yeelight device should react to channel switch by powering on in that color state? It doesn't. The channel is changing value only when i send rgb or ct commands.

Yes, the command is send as that is according the yeelight spec ( https://www.yeelight.com/download/Yeelight_Inter-Operation_Spec.pdf begin page 12), and (prior this PR) I don't know the values for the color/temperature when I just switch mode. Now with this PR in place, indeed we may change the logic and indeed use the set_rgb / set_ct_abx methods instead if that solves the issue

[marcelrv]

different logic in methods and status report

note the strange part in the spec regarding the mode... according the spec, you switch on with these values:
1: Turn on and switch to CT mode.
2: Turn on and switch to RGB mode.

however, in status and other commands it is actually reported as 1: RGB, 2: CT. which is why I fixed the mapping in this PR

[marcelrv]

NOTE: Jenkins build error is unrelated to the PR

[mesetka]

different logic in methods and status report

note the strange part in the spec regarding the mode... according the spec, you switch on with these values:
1: Turn on and switch to CT mode.
2: Turn on and switch to RGB mode.

however, in status and other commands it is actually reported as 1: RGB, 2: CT. which is why I fixed the mapping in this PR

Tested! No errors in docs - it's indeed like described! In method power_on 1 is for CT and 2 is for RGB, and in status report 1 is for RGB and 2 is for CT. I guess you should apply some further changes to fix mapping for power_on method.
Why I am adressing this - I try to adopt community-made widget for Yeelight control and have some issues trying to switch between RGB and CT modes. I had to create an unlinked Color mode item - then this widget works properly, switching between modes and just sending RGB or CT values to Yeelight through your binding, but I think it's not a totally correct way.

[marcelrv]

@mesetka I pushed now a change that works for me locally using the alternative commands.
The number now corrosponds with the right text and is switching when clicked

[fwolter]

LGTM