RFLink, NEXA (NewKaku) and group commands

I’m using HA version 0.117.5 with RFLink Integration.
I have one NEXA-Remote which can control all my lights in the house.
The remote has 4 Individual buttons and one Group-ON/OFF-button. The group button works great for controlling all the lights on or off.

But when I configure the 4 lights in HA, and press group on or off, HA does not treat this as a group command and change the state of all the lights.

It works great in both ways (to HA and from HA) for the individual buttons 1-4 but not for group.

My config for the lights/buttons are:

light:
  - platform: rflink
    automatic_add: true
    devices:
      newkaku_006d7076_1:
        name: Main Button 1
        group: true
      newkaku_006d7076_2:
        name: Main Button 2
        group: true
      newkaku_006d7076_3:
        name: Main Button 3
        group: true
      newkaku_006d7076_4:
        name: Main Button 4
        group: true

When I press the group-button on the remote I get the following log:

[rflink.protocol] received data: 20;01;NewKaku;ID=006d7076;SWITCH=0;CMD=ALLON;
[rflink.protocol] got packet: 20;01;NewKaku;ID=006d7076;SWITCH=0;CMD=ALLON;
[rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'newkaku', 'id': '006d7076', 'switch': '0', 'command': 'allon'}
[rflink.protocol] got event: {'id': 'newkaku_006d7076_0', 'command': 'allon'}
[homeassistant.components.rflink] event of type command: {'id': 'newkaku_006d7076_0', 'command': 'allon'}
[homeassistant.components.rflink] entity_ids: []

So it’s clearly receiving the commands, but it does not connect the command to the lights 1-4.

As a reference, here is the log when I press button 3, which is affecting the button in the frontend.

[rflink.protocol] received data: 20;01;NewKaku;ID=006d7076;SWITCH=3;CMD=ON;
[rflink.protocol] got packet: 20;01;NewKaku;ID=006d7076;SWITCH=3;CMD=ON;
rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'newkaku', 'id': '006d7076', 'switch': '3', 'command': 'on'}
[rflink.protocol] got event: {'id': 'newkaku_006d7076_3', 'command': 'on'}
homeassistant.components.rflink] event of type command: {'id': 'newkaku_006d7076_3', 'command': 'on'}
[homeassistant.components.rflink] entity_ids: ['light.main_button_3']
[homeassistant.components.rflink] passing event to light.main_button_3

I see that there is a difference in the log, that the event is forwarded to main_button_3.

What am I missing ? How can I make HA understand that the lights are a part of the NEXA-group?
I have tried to find an example of this config but have not found any good example.

Hi,
can you test removing the group config from your lights?
Default value already is True (in CamelCase).

No, sorry, the result is exactly the same.

light:
  - platform: rflink
    automatic_add: true
    devices:
      newkaku_006d7076_1:
        name: Main Button 1
      newkaku_006d7076_2:
        name: Main Button 2
      newkaku_006d7076_3:
        name: Main Button 3
      newkaku_006d7076_4:
        name: Main Button 4


2020-11-14 20:53:15 DEBUG (MainThread) [rflink.protocol] received data: 20;01;NewKaku;ID=006d7076;SWITCH=0;CMD=ALLON;
2020-11-14 20:53:15 DEBUG (MainThread) [rflink.protocol] got packet: 20;01;NewKaku;ID=006d7076;SWITCH=0;CMD=ALLON;
2020-11-14 20:53:15 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'newkaku', 'id': '006d7076', 'switch': '0', 'command': 'allon'}
2020-11-14 20:53:15 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'newkaku_006d7076_0', 'command': 'allon'}
2020-11-14 20:53:15 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {'id': 'newkaku_006d7076_0', 'command': 'allon'}
2020-11-14 20:53:15 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: []

I’m not sure why is not working.

Can you do another test, please?
Add the aliases conf to any light:

light:
  - platform: rflink
    automatic_add: true
    devices:
      newkaku_006d7076_1:
        name: Main Button 1
        aliases:
          - newkaku_006d7076_0

It shouldn’t be necessary, but it can make your settings work.

Yes, now it looks like it’s working. It’s forwarding to alias’ed buttons.

2020-11-14 23:11:52 DEBUG (MainThread) [rflink.protocol] received data: 20;01;NewKaku;ID=006d7076;SWITCH=0;CMD=ALLON;
2020-11-14 23:11:52 DEBUG (MainThread) [rflink.protocol] got packet: 20;01;NewKaku;ID=006d7076;SWITCH=0;CMD=ALLON;
2020-11-14 23:11:52 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'newkaku', 'id': '006d7076', 'switch': '0', 'command': 'allon'}
2020-11-14 23:11:52 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'newkaku_006d7076_0', 'command': 'allon'}
2020-11-14 23:11:52 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {'id': 'newkaku_006d7076_0', 'command': 'allon'}
2020-11-14 23:11:52 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['light.main_button_1', 'light.main_button_2', 'light.main_button_3', 'light.main_button_4']
2020-11-14 23:11:52 DEBUG (MainThread) [homeassistant.components.rflink] passing event to light.main_button_1
2020-11-14 23:11:52 DEBUG (MainThread) [homeassistant.components.rflink] passing event to light.main_button_2
2020-11-14 23:11:52 DEBUG (MainThread) [homeassistant.components.rflink] passing event to light.main_button_3
2020-11-14 23:11:52 DEBUG (MainThread) [homeassistant.components.rflink] passing event to light.main_button_4
2020-11-14 23:11:52 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=light.main_button_2, old_state=<state light.main_button_2=off; brightness=255, friendly_name=Main Button 2, supported_features=1 @ 2020-11-14T23:11:28.481479+01:00>, new_state=<state light.main_button_2=on; brightness=255, friendly_name=Main Button 2, supported_features=1 @ 2020-11-14T23:11:52.663862+01:00>>
2020-11-14 23:11:52 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140575029574288] Sending {"id": 2, "type": "event", "event": {"event_type": "state_changed", "data": {"entity_id": "light.main_button_2", "old_state": {"entity_id": "light.main_button_2", "state": "off", "attributes": {"brightness": 255, "friendly_name": "Main Button 2", "supported_features": 1}, "last_changed": "2020-11-14T22:11:28.481479+00:00", "last_updated": "2020-11-14T22:11:28.481479+00:00", "context": {"id": "1f97edca8d8cbf7c383873cf669b5ea7", "parent_id": null, "user_id": null}}, "new_state": {"entity_id": "light.main_button_2", "state": "on", "attributes": {"brightness": 255, "friendly_name": "Main Button 2", "supported_features": 1}, "last_changed": "2020-11-14T22:11:52.663862+00:00", "last_updated": "2020-11-14T22:11:52.663862+00:00", "context": {"id": "92fd11c25273ca82822049d97fc50e7c", "parent_id": null, "user_id": null}}}, "origin": "LOCAL", "time_fired": "2020-11-14T22:11:52.663960+00:00", "context": {"id": "92fd11c25273ca82822049d97fc50e7c", "parent_id": null, "user_id": null}}}

Does it work internally like this ? To automatically add aliases to devices with same id ?
Please tell me if there is some more debugging that I can help you with ? Would be interesting to know why it does not work with standard config.

I think I have already seen the full picture of how the aliases and groups full thing works in RFLink.

First we must know that in RFLink there is 2 kinds of ‘command signals’: entity and group commands.
At the moment the group signals are: allon and alloff.
The entity command are for any kind of device: on, off, open, close, toggle, …

Ok, let’s suppose that we have a configuration like the yours:

light:
  - platform: rflink
    automatic_add: true
    devices:
      newkaku_006d7076_1:
        name: Main Button 1
        aliases:
          - newkaku_006d7076_0
        group_aliases:
          - newkaku_33333333_0
        no_group_aliases:
          - newkaku_33333333_1

The several RFLink configurations have the following behavior:

  • group: defines if your RFLink device will change its state if a ‘group signal’ is received for that device. This will define the behavior in HA if a signal like this is received:
[rflink.protocol] received data: 20;01;NewKaku;ID=006d7076;SWITCH=1;CMD=ALLON;
  • aliases: defines if your device will react to signals from other device. The typical example is when you want that your HA device state changes with signals from a physical remote control. Your device will react to entity and group commands. In our example, the HA state for newkaku_006d7076_1 will change with any entity or group command from newkaku_006d7076_0.
  • group_aliases: this is for when your device must reacts to group commands but not for entity commands for another device. In our example, the HA state for newkaku_006d7076_1 will change with a allon command from newkaku_33333333_0, but not if a entity command is received.
  • newkaku_33333333_1: the opposite one. Device newkaku_006d7076_1 will react to entity commands from newkaku_33333333_1 (and not for group commands)

As you can see, the parameters only serve to model the behavior in HA to the external signals for the diverse combinations of entity group commands.
In most cases, it is enough to correctly define the alias of our device since (for example) it is not likely that you will receive an on signal from the newkaku_006d7076_0 device.
For most people this is enought. All the other people can play with all this parameters.

You can test what is in your case the behavior of your device and model it according to your needs, making use of the utility services in the developer tools.

Cheers.

1 Like

Thank you so much. Your clear description of the different configurations is great. Now I understand the different options.
The official doc should be updated with your config descriptions !

How do I activate a group command from an HA script or automation, to both send out a group command (allon/alloff) and set the corresponding light entity status (Button 1-4 in my case)

I think there is no direct way to do it with the current RFLink because only on/off commands are implemented, but we can try a couple of approaches to see what we can do.

The first thing I would like to try is to configure the newkaku_006d7076_0 also as a light in HA and see how the rest of the lights (which have it as aliases) behave when the state changes. It is not expected that the changes in HA will turn on or off the physical devices, but I am interested in knowing what behavior it has in HA and if the other lights status change when the alias status change.

Would you be kind enough to do this test?

  • configure newkaku_006d7076_0 in HA as another light (without any aliases)
  • from HA, turn on and off the newkaku_006d7076_0 light
  • see if the other lights status change
    Also will help me a lot if you can attach your current configuration and the logs from your tests.

Thanks in advanced.

Ummm, try it if you want but I don’t think it will work …

I have done some testing and I think that what I originally intended is not going to work.

But, I think adding a little functionality to the current implementation, it should be trivial to make it work.
Let’s see if I get some spare time and create a PR with the implementation that I have tested.

I will keep in touch

I did try it out and it did not work. It send the correct group-signal to the Rflink-transceiver but it does not update buttons 1-4.

So I fixed it with another solution. I don’t really have a Rflink-board, but I have my own ESP32-based 433-transceiver which talks over UDP to an Integration-SW on my server which translates the messages to Rflink-format and sends over TCP to the HA-Integration. So what I did was to echo back the same group-command (if it was a group-command) that HA send to the transceiver back to HA, and voila, it sets the state of Button 1-4

In the picture below, HA is to the right of the picture and the fakeHAbackData-queue sends data back to HA. And this seams to work very well :slight_smile:

It’s funny, it’s more or less the same approach that I want to implement in RFLink for the send_command service.

PS: nice setup.

The PR had been created, but these things sometimes get stuck:

Super @javicalle, I will try out your commits.
Great job, thanks. Much cleaner than my outside solution.

PR has been merged, so change is expected to be in v2021.04.

1 Like