Core: Rflink support for milight

[aequitas]

milight support (https://community.home-assistant.io/t/support-for-rflink-gateway/996/49?u=aequitas)

from: https://github.com/home-assistant/home-assistant/issues/5965

[aequitas]

https://community.home-assistant.io/t/add-rflink-sensor-switch-value-template-attribute/17876

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[olskar]

This is not resolved in latest version, still needs to be implemented

[olskar]

This requires pairing, right? Perhaps that can be done with #8020 ?

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[olskar]

This is not resolved in latest version, still needs to be implemented @aequitas

[djm300]

Did some research today and there are 2 issues blocking Milight implementations. These issues both stem from the fact that RFLink expects a different command structure for Milight: instead of the normal 10,,,ON, RFLink expects another id field for Milight. The first id is taken as the group, the second as the button number.

This functionality does not work according to my tests in the python-rflink (the underlying python lib) written by @aequitas according to me (I posted an issue on his github (https://github.com/aequitas/python-rflink/issues/7) and a partial pull request (https://github.com/aequitas/python-rflink/pull/6). That's the first issue.

The second issue is that HA is not passing additional id values right now so even if the python-rflink library is adapter, HA still needs to pass the right parameters. I still need to look in the code but if the author wants to put in the effort, adding color support would be useful as well. In short, HA should be able to support standard klik-aan-klik-uit lights which require 1 id, Milight on/off command with 2 id's and Milight color change commands which would have 2 id's AND a color value.

[Redferne]

Just to add some more wood to the fire 🔥 There are more of these quirks in the RFLink firmware. The protocol is terrible and poorly documented.

For Command type there are a plethora; ON/OFF/ALLON/ALLOFF/UP/DOWN/STOP/PAIR/CHIME/TOGGLE

Extended receive types;
CHIME=02/SMOKEALARM=ON/RGBW=3c00/BAT=LOW

These are just examples. Maybe it's worth investigating on adding support for the general few missing bits not just milight? 😉

[djm300]

Agreed - just discovered that RFLink, even with the proper command issued directly, cannot control the milights in my case. RFLink has some issues to resolve before we can start solving/testing upwards in the stack.

[aequitas]

@Redferne don't get me started about it :D But trial and error gets you a long way.

@djm300 if needed I can help you get the Milight code in python-rflink and HA. I don't have Milight devices so it's hard for me to test and debug code for this.

[djm300]

@aequitas Sure thing. I don't want to mess up your library but if OK to you, I'll start by adapting the rflink CLI tool to take multiple formats separated by underscores so could be 0909 (simple ID) or 0909_1 (button value) or 0909_1_45e6 (for button & color value), just like the 4 templates. Once we have that flowing well though the python lib, we can look at HA. Agreed?

[olskar]

I have milight devices if testing is needed :)

[aequitas]

@djm300 best is indeed to focus on python-rflink first to get a minimal viable working implementation. But keep in mind that in the HA implementation currently uses underscores as well for serialisation of the packet id/device id. While this problem can be fixed later we might already keep it in mind to not get into trouble when adopting this for HA.

[Gratizzz]

Hi guys any roadtrip on this one? Looking forward to have it working (I can also test if you want!)

[thazlett]

I'm trying out homeassistant as a replacement to my domoticz set up at the moment. I have milights all over the place so this is sort of a deal breaker for me. I would love to see this working. I can also help with testing if need be.

[djm300]

Hi, my fork contains a working fix but struggling with fixing the tests cases. Happy to accept any help here!

[aequitas]

@djm300 where specifically are you stuck with the test cases?

[djm300]

@aequitas Hi, I spent some time on the test cases. I believe the test cases itself are not properly designed but would like confirmation.

Background

Referring to the protocol spec (http://www.rflink.nl/blog2/protref), it appears that all messages starting with 10 are messages being sent and messages starting with 20 are being received.
(I'm ignoring echo messages with 11 for now)

Sending messages are a bit different from receiving messages: sending messages typically do not contain key/value pairs delimited by '=' whereas received messages do. For example:

RECEIVED message:
20;D4;NewKaku;ID=000005;SWITCH=2;CMD=ON;

SENT message:
10;MiLightv1;F746;01;34BC;COLOR;
10;RTS;1b602b;0123;PAIR;

Hence, it follows that decoding of received messages is different from receiving sent messages.

Tests

If you follow the structure of the code, you would see that decode_packet (rflink.parser.decode_packet) is only called for received messages hence looking for '=' delimiters along the way.

Now, the tests failing are the following:

• 10;MiLightv1;F746;00;3c00;ON; -> no valid packet
• 10;NewKaku;0cac142;3;ON; -> no valid packet
• 10;MERTIK;64;UP; -> no valid packet
• 10;DELTRONIC;001c33; decoded as {'node': 'master', 'protocol': '001c33'}

The invalid packet actually makes sense since they don't have sequence numbers (the D4 in 20;D4;NewKaku;ID=000005;SWITCH=2;CMD=ON;) and don't have '=' delimiters.

The wrong decoding of DELTRONIC is actually due to the parser dropping the second delimited field as a sequence number and not decoding it as the protocol ID.

Conclusion

I have not tested how your codebase compared but I believe the failing tests are wrong tests. I agree that there should be other tests which is something to look into, but for now, I care more about getting the right tests in there.

Best regards
Joris

[djm300]

On writing this, I realise there is no harm in ensuring that even sent commands are passing the valid_packet check but in the code, this code path will never be taken for sent commands (starting with 10).

[aequitas]

@djm300 thanks for the investigation. Decoding of 'sent' packets is supported because the Rflink device might echo back these kind of packets.

If what you say it true there is an error in the decoder as it should be smart enough to distinguish both kind of packets and act accordingly (ie: don't expect field 2 to be a sequence number).

I need to familiarize myself with this part of the codebase again, let me get back on this to you before end of the week.

[stuntteam]

The second field on received RF data is a continuity counter. It is optional to do anything with it..
The first field is always 20..
The continuity counter field is not present on commands that you send to RFLink. The first field is always 10 on these packets.

Messages starting with 11 are "internal-use" for domotica software. Its basic use is "container". The idea is that you send 11; followed by a command that starts with 20; the 20 part then gets "echoed" back.
The use is that you could create a popup where users can enter the 20 command as obtained from logs..the software should then add the 11; and send to rflink.. rflink echos the 20 command 'as if' it was received over the air. The idea behind thi sis that rather than making a complex 'manual create device' function you can re-use any auto-detect mechanism you already have in place.

Milight indeed follows a modified packet layout due to the fact that you need to be able to send and receive RGB data.

[aequitas]

If that is the case we could maybe treat a milight packet as a separate protocol in the parser, rather than putting it under the normal packet logic, that might work.

[patatman]

I’ve just switched from Domoticz to HASS and just sharing the way they implemented Milight with the RFlink.

Basicly what you need to do is pair the bulb with the Rflink code you send, so the bulb will accept the commands send by the RFlink. (This is basicly the same with the normal hub)
They use the following module:
https://github.com/domoticz/domoticz/blob/development/hardware/RFLinkBase.cpp

10;MiLightv1;1234;01;5566;ON;     => protocol;address;unit number;color&brightness;action (ON/OFF/ALLON/ALLOFF etc)

Ideal situation would be to have a button to pair the bulb, and the hang it inside HASS.
Will try to make a solution, still learning python so it might not be the prettiest.

[olskar]

Is there a way to use the fix from your fork @djm300 and not have to wait until included in home assistant?

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[marcinello]

Unfortunately problem is still present in the latest HA version (0.71.0).
I use RGBW light bulb.

When I add MiLight with Rflink using following code:

rflink:
  port: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0022_85460318838951F0B1A3-if00  
light:
  - platform: rflink
    device_defaults:
      fire_event: true
      signal_repetitions: 2
    devices:
      milightv1_2560_01:
        name: "MiLight Living Room"

I get these errors:

[rflink.protocol] sending command: {'id': '2560', 'switch': '01', 'command': 'off', 'protocol': 'milightv1'}
[rflink.protocol] writing data: '10;milightv1;2560;01;off;\r\n'
[rflink.protocol] waiting for acknowledgement
[rflink.protocol] received data: 20;0C;CMD UNKNO
[rflink.protocol] received data: WN;
[rflink.protocol] got packet: 20;0C;CMD UNKNOWN;

But I can get MiLight to work by sending commands manually (without light.rflink), with following code:

input_boolean:
  milight_switch:
    name: MiLight switch
    initial: off
    icon: mdi:refresh
automation:
  - alias: 'Milight switch automation on'
    trigger:
      - platform: state
        entity_id: input_boolean.milight_switch
    action:
      - service: sensor.update_speedtest
      - service: rflink.send_command
        data_template:
          device_id: 'milightv1_2560_01'
          command: >
            3500;{{ trigger.to_state.state }}

And it works properly as you can see in the logs:

[rflink.protocol] sending command: {'id': '2560', 'switch': '01', 'command': '3500;on', 'protocol': 'milightv1'}
[rflink.protocol] writing data: '10;milightv1;2560;01;3500;on;\r\n'
[rflink.protocol] waiting for acknowledgement
[rflink.protocol] received data: 20;0D;OK;
[rflink.protocol] received data: 
[rflink.protocol] got packet: 20;0D;OK;

Unfortunately with this workaround there's really really long delay between clicking and light bulb reaction.

So as you can see absence of RGB/RGBW parameter is causing command to fail (3500 in my case).

Following example from Rflink FAQ (http://www.rflink.nl/blog2/faq#Milight):
20;17;MiLightv1;ID=2560;SWITCH=01;RGBW=3500;CMD=ON;
does not work, but this one works properly:
10;MiLightv1;2560;01;3500;ON;

Is there any chance it will get fixed in HA light.rflink component?

[Unthred]

Any movement on this? I would love to buy an rflink device. I have a lot of milight bulbs

[internet-conception]

I'm not a python writer but it looks like @marcinello done a huge progress...
Is @aequitas can try a "blind" integration ? Or if you want I paid you a bulb and remote... it's quiet cheap !

[marcinello]

I found some workaround for my use case.
Following config will let me turn light bulb ON and OFF, but won't let me change RGB colors:

rflink:
  port: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0022_85460318838951F0B1A3-if00  
light:
  - platform: rflink
    automatic_add: false
    device_defaults:
      fire_event: true
      signal_repetitions: 2
    devices:
      milightv1_2560_01;3500:
        name: "MiLight Living Room"
        aliases:
          - milightv1_2560_01

Basically I set my device ID to: milightv1_2560_01;3500

BTW: if you want to test commands by going to Services > rflink.send_command and typing:

{"device_id":"milightv1_2560_01", "command":"3500;ON"}

[internet-conception]

Yes I'm going to test the service "trick" especially since I'm using nodered a lot ;) should work like a charm in fact !
Thanks for your pugnacity ;)

[internet-conception]

tks a lot @marcinello the service > rflink.send_command work very well :)

I'll need a basic input_binary to keep a track of the state (I only have a xiaomi toggle switch) and add the right behaviour in nodered... but it will be simple now

I didnt digg yet but why we cant change the color ? the service method seems fexible ?

Ps: I did use "jeedom" in past and it was possible to change color and set "mode, speed, effect, etc" on this bulb (via rflink of course)

[Tontze]

Very nice, looking forward for this 👍

[MartinHjelmare]

I'm closing this as it's not a bug report. You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum. Thanks!