RFLink, RTS Somfy wind/sun sensor

Hi! I got some Somfy RTS covers and it works great in HA using RFlink!

However i do also have a Somfy RTS sun/wind sensor which I’m struggling to integrate.
If i look into Supervisor / System / Core logger get the below log which i suspect to be the sun sensor(?) i.e. the rts_14ccca0_01

2021-05-28 15:15:14 DEBUG (MainThread) [rflink.protocol] got packet: 20;18;RTS;ID=14ccca0;SWITCH=01;CMD=DOWN;
2021-05-28 15:15:14 DEBUG (MainThread) [rflink.protocol] decoded packet: {‘node’: ‘gateway’, ‘protocol’: ‘rts’, ‘id’: ‘14ccca0’, ‘switch’: ‘01’, ‘command’: ‘down’}
2021-05-28 15:15:14 DEBUG (MainThread) [rflink.protocol] got event: {‘id’: ‘rts_14ccca0_01’, ‘command’: ‘down’}
2021-05-28 15:15:14 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {‘id’: ‘rts_14ccca0_01’, ‘command’: ‘down’}

To me this looks like it should be a RFlink command sensor, right?

I then implement the below code in configuration.yaml

sensor:
  - platform: rflink
    automatic_add: true
    devices:
      rts_14ccca0_01: sensor_type: command
        name: RTS_Sunsensor

The RTS_Sunsensor shows up in HA but it is always undefined, not UP, DOWN, etc?
Where do i go wrong?

Btw. I believe I do have the Soliris RTS Sun and Wind sensor

I’m testing if the Soliris RTS works better as an binary sensor and switch and now I do get some progress since data is being passed, see below low where data is being passed both to the binary sensor and the switch.

However in HA the state of the binary sensor defined but always “OFF” and never change??
The switch never change as well?

2021-05-29 18:10:27 DEBUG (MainThread) [homeassistant.components.rflink] unhandled event of type: unknown
2021-05-29 18:10:27 DEBUG (MainThread) [rflink.protocol] got packet: 20;0C;RTS;ID=14ccca0;SWITCH=01;CMD=DOWN;
2021-05-29 18:10:27 DEBUG (MainThread) [rflink.protocol] decoded packet: {‘node’: ‘gateway’, ‘protocol’: ‘rts’, ‘id’: ‘14ccca0’, ‘switch’: ‘01’, ‘command’: ‘down’}
2021-05-29 18:10:27 DEBUG (MainThread) [rflink.protocol] got event: {‘id’: ‘rts_14ccca0_01’, ‘command’: ‘down’}
2021-05-29 18:10:27 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {‘id’: ‘rts_14ccca0_01’, ‘command’: ‘down’}
2021-05-29 18:10:27 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: [‘binary_sensor.rts_sunsensor_binary’, ‘switch.rts_sunsensor_switch’]
2021-05-29 18:10:27 DEBUG (MainThread) [homeassistant.components.rflink] passing event to binary_sensor.rts_sunsensor_binary
2021-05-29 18:10:27 DEBUG (MainThread) [homeassistant.components.rflink] passing event to switch.rts_sunsensor_switchv

binary_sensor:
 - platform: rflink
   automatic_add: true
   devices:
     rts_14ccca0_01: 
       name: RTS_Sunsensor_binary  
switch:
  - platform: rflink
    automatic_add: true
    devices:
      rts_14ccca0_01:
        name: RTS_Sunsensor_switch

Any input is welcome :slight_smile:

From what I can interpret from the logs, it appears that the “wind sensor” directly sends a RTS DOWN command. This makes the cover react to events, but IMHO as a ‘sensor’ it doesn’t makes sense.
The point is that only RFLink cover type devices respond to DOWN type events. Neither the binary_sensor nor the switch handle that command value:

Also, I don’t think that the sensor will send other types of commands (eg: a UP command) that allows resetting the sensor/switch status. It is true that the binary_sensor allows to define an off_delay to reset the sensor state, but considering that you cannot handle the command as a binary_sensor it is not useful for its purpose.

Surely at this point, I think the most practical thing would be to handle it as an event rather than as a binary_sensor. I think that if you configure the device with fire_event: true you should be able to capture the button_pressed type events and do some kind of automation with it. The downside is that it forces you to define a useless device just to propagate the event.

1 Like

I have looked at RFLink binary_sensor PRs and a time ago the allon and alloff commands were added to binary_sensor:

Maybe the up and down commands can also be considered here…

1 Like

From the manual you posted I can see that sensor will send both up and down commands, so modify the binay_sensor can be a good approach.

1 Like

Hi javicalle,
Many thanks for the elaborate info and feedback, I really appreciate it!
Yes, i do have 5 covers and one Soliris sun/wind sensor. For different reasons i would like to individually control the covers and still keep an eye on the Soliris sun/wind sensor.

I would obviously be interested in a PR as you described!
I checked the PR you referred to and I´m very interested to help out the process but not sure how to do it properly?

Btw below is the log when there is no sun, i.e. it actually says CMD=STOP and not DOWN…for some reason.

2021-05-29 19:51:17 DEBUG (MainThread) [homeassistant.components.rflink] unhandled event of type: unknown
2021-05-29 19:51:17 DEBUG (MainThread) [rflink.protocol] got packet: 20;76;RTS;ID=14ccca0;SWITCH=01;CMD=STOP;
2021-05-29 19:51:17 DEBUG (MainThread) [rflink.protocol] decoded packet: {‘node’: ‘gateway’, ‘protocol’: ‘rts’, ‘id’: ‘14ccca0’, ‘switch’: ‘01’, ‘command’: ‘stop’}
2021-05-29 19:51:17 DEBUG (MainThread) [rflink.protocol] got event: {‘id’: ‘rts_14ccca0_01’, ‘command’: ‘stop’}
2021-05-29 19:51:17 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {‘id’: ‘rts_14ccca0_01’, ‘command’: ‘stop’}
2021-05-29 19:51:17 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: [‘binary_sensor.rts_sunsensor_binary’, ‘switch.rts_sunsensor_switch’]
2021-05-29 19:51:17 DEBUG (MainThread) [homeassistant.components.rflink] passing event to binary_sensor.rts_sunsensor_binary
2021-05-29 19:51:17 DEBUG (MainThread) [homeassistant.components.rflink] passing event to switch.rts_sunsensor_switch

Ummm, that is interesting…
So when there is ‘high wind’ an DOWN command is triggered, but when there is no sun the command triggered is STOP.
What is the behavior that causes that STOP command in your case?

I don’t know how that case should be handled with a binary_sensor.
It’s clear what it would be like for UP and DOWN commands, but I don’t know how the STOP command should be treated with a binary_sensor.
The RFLink cover’s implementation has as possible states open and closed, where closed corresponds to the cover fully closed and open everything else. The command STOP generates an open state, since if you have stopped it halfway, it should not be ‘totally closed’. For the ‘MY position’ the same criteria apply.

Right, the STOP command makes the cover open up. As i see it i do get a DOWN commands when it senses sun and the cover is closing. When the sensor do not sense the sun anymore it gives STOP commands and the cover is going up.
Unfortunately it has not been to windy yet so I do not yet have any experience what it will give, if it is a STOP or an UP command?
If the binary sensor does not work out, any chance you could use some ‘regular’ sensor instead where you could read out the command in text format and then you could decide in HA what to do with it?
I have very little knowledge how HA work internally :slight_smile:

Without modifying the RFLink binaty_sensor implementation there is no way that any sensor could ‘read’ this kind of events.

The RFLink integration is in charge of ‘translating’ the events of the devices to HA entities (sensors and binary_sensors).
Currently the only implementation that understands the UP, DOWN and STOP commands is the cover.

So either the binary_sensor implementation is modified, or you can try the event approach from post #4

A PR for binary_sensor modification maybe is not accepted due to the requeriments that the integration must meet (and currently does not).

The event approach consist in create a coverconfiguration with the sensor ID and configure the fire_avent attribute, something like:

cover:
 - platform: rflink
   devices:
     rts_14ccca0_01: 
       name: RTS_Sunsensor_cover
       fire_event: true

This device is not intended to be added to the dashboard or used. But you can catch the fired events to be used in automations.

This is a theoretical approach, but one that I have not validated.
You can see the events that are generated from the HA developer tools. You should have button_pressed type events available to listen to. The event will be something like:

{entity_id: rts_14ccca0_01, state: UP|STOP|DOWN}
1 Like

javicalle, wow first class feedback! For some strange reason I was focused to use the different RFLink sensors, lights, switch etc…but not the cover? Your proposal works just fine and as a bonus i learned the really good event handler in the HA developer tools.
Again, many thanks :slight_smile:

Hi again, late reply, but the unfortunately cover: does not catch the STOP state from the Somfy RTS sun/wind sensor.

As a work around I’m using the logger

logger:
  default: error
  logs:
    rflink: debug
    homeassistant.components.rflink: debug

with the below command_line grep sensors to catch the STOP and DOWN events

sensor:
  - platform: command_line
    command: 'grep "14ccca0;SWITCH=01;CMD=STOP" /config/home-assistant.log | tail -1'
    name: Soliris_STOP
  - platform: command_line
    command: 'grep "14ccca0;SWITCH=01;CMD=DOWN" /config/home-assistant.log | tail -1'
    name: Soliris_DOWN 

and then a couple of automations that take action and control the covers.
Not very elegant but It works pretty good.

removed by the author

Hello,
I am a bit lost on this topic.
I had understood that you were making use of the fire_event property and the dummy cover, but then you have commented that the STOP command does not work and that you are reading the events from the logs.
Your last reply I don’t know if it refers to the first method or the second

To try to help you, I would need to know the following information:

  • the relevant part of your configuration (fire_event? rflink.cover?)
  • the traces generated by the events (“Fired bus event for% s:% s”). The problem is that this requires the debug level and it can be too noisy to maintain it for a long time

I can’t see any reason why the STOP command would be diferent from the UP or DOWN commands.

Hi javicalle,
Thanks and sorry, my last email was confusing and i will remove it (i actually saw an UP command in the log for the first time got excited but i did not check if the cover: RTS_Sunsensor_cover caught the event).

My configuration.yaml looks like below (although i do have some more covers not showed here)

cover:
  - platform: rflink
    devices:
      rts_14ccca0_01: 
        name: RTS_Sunsensor_cover
        fire_event: true

In the logger see the below for DOWN that the cover: RTS_Sunsensor_cover catches

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] received data: 20;7C;Debug;RTS P1;a0e400024ccca0;

20;7D;RTS;ID=14ccca0;SWITCH=01;CMD=DOWN;

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] got packet: 20;7C;Debug;RTS P1;a0e400024ccca0;

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'debug', 'rts_p1': 'a0e400024ccca0'}

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'raw', 'value': None, 'tm': None, 'pulses': None}

2021-08-17 18:36:10 DEBUG (MainThread) [homeassistant.components.rflink] event of type unknown: {'id': 'raw', 'value': None, 'tm': None, 'pulses': None}

2021-08-17 18:36:10 DEBUG (MainThread) [homeassistant.components.rflink] unhandled event of type: unknown

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] got packet: 20;7D;RTS;ID=14ccca0;SWITCH=01;CMD=DOWN;

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'rts', 'id': '14ccca0', 'switch': '01', 'command': 'down'}

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'rts_14ccca0_01', 'command': 'down'}

2021-08-17 18:36:10 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {'id': 'rts_14ccca0_01', 'command': 'down'}

2021-08-17 18:36:10 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['cover.rts_sunsensor_cover']

2021-08-17 18:36:10 DEBUG (MainThread) [homeassistant.components.rflink] passing event to cover.rts_sunsensor_cover

2021-08-17 18:36:10 DEBUG (MainThread) [homeassistant.components.rflink] Fired bus event for cover.rts_sunsensor_cover: down

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] received data: 20;7E;Debug;RTS P1;a0e4

2021-08-17 18:36:10 DEBUG (MainThread) [rflink.protocol] received data: 00024ccca0;

…and the below for STOP that the cover: RTS_Sunsensor_cover do not catches

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] received data: 20;4E;Debug;RTS P1;a0e600004cc

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] received data: ca0;

20;4F;RTS;ID=14ccca0;SWITCH=01;CMD=STOP;

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] got packet: 20;4E;Debug;RTS P1;a0e600004ccca0;

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'debug', 'rts_p1': 'a0e600004ccca0'}

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'raw', 'value': None, 'tm': None, 'pulses': None}

2021-08-17 18:19:31 DEBUG (MainThread) [homeassistant.components.rflink] event of type unknown: {'id': 'raw', 'value': None, 'tm': None, 'pulses': None}

2021-08-17 18:19:31 DEBUG (MainThread) [homeassistant.components.rflink] unhandled event of type: unknown

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] got packet: 20;4F;RTS;ID=14ccca0;SWITCH=01;CMD=STOP;

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'rts', 'id': '14ccca0', 'switch': '01', 'command': 'stop'}

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'rts_14ccca0_01', 'command': 'stop'}

2021-08-17 18:19:31 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {'id': 'rts_14ccca0_01', 'command': 'stop'}

2021-08-17 18:19:31 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['cover.rts_sunsensor_cover']

2021-08-17 18:19:31 DEBUG (MainThread) [homeassistant.components.rflink] passing event to cover.rts_sunsensor_cover

2021-08-17 18:19:31 DEBUG (MainThread) [homeassistant.components.rflink] Fired bus event for cover.rts_sunsensor_cover: stop

2021-08-17 18:19:31 DEBUG (MainThread) [rflink.protocol] received data: 20;50;Debug;RTS P1;a0e600004ccca0;

20;51;RTS;ID=14ccca0;SWITCH=01;CMD=STOP;

…i will see if i can get the traces from the event handler in the HA developer tools as well.

Please, could you include all the rflink part? something like:

rflink:
  port: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0

Please, also wrap the log with the ``` code format.

In your traces I can see all two events get fired:

2021-08-17 18:36:10 DEBUG (MainThread) [homeassistant.components.rflink] Fired bus event for cover.rts_sunsensor_cover: down

2021-08-17 18:19:31 DEBUG (MainThread) [homeassistant.components.rflink] Fired bus event for cover.rts_sunsensor_cover: stop

So, what do you mean when you say that the cover does not catches the command?
I was assuming you were going to try to capture the events and run automations based on the captured command, don’t you?

Ok,fixed the ```` for the log file!

Yes, in the log file it says that the “Fired bus event for cover.rts_sunsensor_cover: stop”

But i do not see it show up in the cover.rts_sunsensor_cover entity and then i cannot use it for automations.

I was able to catch the below in the event handler

Händelse 141 utlöst 19:07:
{
    "event_type": "button_pressed",
    "data": {
        "entity_id": "cover.rts_sunsensor_cover",
        "state": "stop"
    },
    "origin": "LOCAL",
    "time_fired": "2021-08-17T17:07:46.879793+00:00",
    "context": {
        "id": "1b041cf6f369d4a8ca461f7074227063",
        "parent_id": null,
        "user_id": null
    }
}

I will try to catch a DOWN tomorrow…but looks like it will be cloudy so not sure i will make it in a couple of days.

If i look into the events, it also show last time it was changed to closed (DOWN). It does not recognize the above event that you can see was fired later?
image

…and here is more of the configuration.yaml

rflink:
  port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
  wait_for_ack: false

Thanks for fixing the format.

Once you have the cover configured, it would be used only for fire events, then these events can be used in automations, for example (not tested):

alias: RFLink event
description: ''
trigger:
  - platform: event
    event_type: button_pressed
    event_data:
      entity_id: cover.rts_sunsensor_cover
condition: []
action:
  - choose:
      - conditions:
          - condition: template
            value_template: '{{ trigger.event.data.state == ''stop'' }}'
        sequence:
          - service: light.toggle
            target:
              entity_id: light.desk_light
      - conditions:
          - condition: template
            value_template: '{{ trigger.event.data.state == ''up'' }}'
        sequence:
          - service: automation.trigger
            target:
              entity_id: automation.antimosquitos_on
      - conditions:
          - condition: template
            value_template: '{{ trigger.event.data.state == ''down'' }}'
        sequence:
          - service: light.turn_off
            target:
              entity_id: light.bedside_lamp
    default: []
mode: single

Replace actions (the sequence part) with your owns, but I think that trigger and conditions must be fine.

Through the events it would also be the best way to manage it if it could be integrated as a sensor (and not with the workaround of the cover).

1 Like

Hi javicalle,
Really great, this looks very promising and I’m now able to catch the ‘stop’ event for the first time! :smiley:
Hopefully (i cannot see why not) it will catch ‘down’ events as well. Just very cloudy and no sun today…
Will get back with update soon!

update: and just like that, the sun decided to show up and i can confirm that it is working great!
Many thanks for the support :smiley:

1 Like