YET another time controlled cover (RFLink)

Hello There,

I’m also interested in this kind of feature.
I just setup a new Hass.io distrib on a mini chinese computer (ACute), and plugged in my RfLink Arduino.

The RfLink is working well by itself with the default HA RfLink plugin… UP/DOWN/STOP commands are corectly taken into account.
I followed the installation steps :

  • create the /config/custom_components/rts_rflink folder
  • add the 3 files
  • update the configuration
  • trigger a script reload + configuration reload + restart HA instance

here is my configuration :

# RfLink configuration
rflink:
  port: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0042_55732323630351114181-if00
  wait_for_ack: false

# RfLink Somfy RTS device configuration
cover:
  - platform: rts_rflink
    devices:
      RTS_0F0FF0_0:
       name: SomfySalon
       aliases:
        - rts_31e53f_01

But on HA startup, I get an error message in the logs :

Logger: homeassistant.components.hassio
Source: components/hassio/__init__.py:269
Integration: Hass.io ([documentation](https://www.home-assistant.io/integrations/hassio), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+hassio%22))
First occurred: 23:33:51 (1 occurrences)
Last logged: 23:33:51

Platform error cover.rts_rflink - Integration 'rts_rflink' not found.

I will try to restart the full Hass.io supervisor to ensure the changes are taken into account.

Anyway thank you for the job ! :+1:
It is very pleasant to see people involved to improve this plugin… I did the exact same thing on OpenHAB (on another Home Automation system based on Java)
[https://github.com/cyrilcc/org.openhab.binding.rflink/issues/48] and I was sad to revert to some basic features.
Hopefully you are there :sunglasses:

Hi,
on HA restarting you should see a trace like the following:

2020-03-30 02:56:57 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for rts_rflink which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.

It is there?

All your config seems good to me.

Can you try to set the debug level for this integration. This must be done at your config (configuration.yaml) if we want to catch some init logs:

logger:
  default: warning # <- Or whatever you want
  logs:
    rflink: info
    homeassistant.components.rflink: info
    # homeassistant.components.rflink.sensor: info
    # custom_components.rflink.cover: debug
    # custom_components.rflink: info
    custom_components.rts_rflink: debug

I updated the configuration.yaml with this content :

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

From a terminal on the host machine (so outside the Hassio component, so it is mapped to /config/custom_components/rf_link from within HA container), I can check all the configuration seems OK :

cartemere@acute:/usr/share/hassio/homeassistant/custom_components/rts_rflink$ ls -l
total 20
-rw-r--r-- 1 root root 11461 avril  3 23:28 cover.py
-rw-r--r-- 1 root root   227 avril  3 23:28 manifest.json
-rw-r--r-- 1 root root   219 avril  3 23:28 services.yaml

But after restarting the HomeAssistant, I still get this single line in the logs :

2020-04-04 21:23:23 ERROR (MainThread) [homeassistant.components.hassio] Platform error cover.rts_rflink - Integration 'rts_rflink' not found.

I see in the manifest there is a dependency on the xknx plugin.
It seems embedded in the HA installation. Do we need a specific version ?

I will perform some more tests…

SO… here is the explaination, and the solution :partying_face:

For a stange reason, I only get the full logs while restarting with the standard “rflink” plugin configuration.
It behaves like if Home Assistant supervisor (in Hass.io ) was checking the config file grammar before restarting the instance, and was then cancelling the restart as it was not able to validate the config…
and as the configuration changes are invalid without the new plugin loaded, it fails !

So, to get the plugin working FOR HASS.IO USERS :
1- follow the rts_rflink plugin installation procedure (i.e copy the 3 files in the expected directory)
2- keep the legacy rflink embedded plugin configuration (i.e. do NOT touch the config for now)
3- click the “restart HA” button… wait a few seconds (or minutes if you run on a small hardware)
4- after the restart, you should have a WARNING entry in the logs :

You are using a custom integration for rts_rflink which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.

5- update the configuration to the match the new plugin requirements. (+ I HIGHLY recommend to set the debug flag on custom_components.rts_rflink as follow) :

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

6- perform a new ‘HA restart’… wait again…
7- check the logs after the restart, you should now have a trace of the new plugin init :

2020-04-04 21:45:13 INFO (MainThread) [homeassistant.components.rflink] Initiating Rflink connection
2020-04-04 21:45:13 INFO (MainThread) [homeassistant.components.rflink] Connected to Rflink
2020-04-04 21:45:13 DEBUG (MainThread) [rflink.protocol] connected
2020-04-04 21:45:14 DEBUG (MainThread) [rflink.protocol] received data: 20;0
2020-04-04 21:45:14 DEBUG (MainThread) [rflink.protocol] received data: 0;Nodo RadioFrequencyLin
2020-04-04 21:45:14 DEBUG (MainThread) [rflink.protocol] received data: k - RFLink Gateway V1.1
2020-04-04 21:45:14 DEBUG (MainThread) [rflink.protocol] received data: - R48;
2020-04-04 21:45:14 DEBUG (MainThread) [rflink.protocol] got packet: 20;00;Nodo RadioFrequencyLink - RFLink Gateway V1.1 - R48;
2020-04-04 21:45:14 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'unknown', 'hardware': 'Nodo RadioFrequencyLink', 'firmware': 'RFLink Gateway', 'version': '1.1', 'revision': '48'}
2020-04-04 21:45:14 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'rflink', 'hardware': 'Nodo RadioFrequencyLink', 'firmware': 'RFLink Gateway', 'version': '1.1', 'revision': '48'}
2020-04-04 21:45:14 DEBUG (MainThread) [homeassistant.components.rflink] event of type unknown: {'id': 'rflink', 'hardware': 'Nodo RadioFrequencyLink', 'firmware': 'RFLink Gateway', 'version': '1.1', 'revision': '48'}
2020-04-04 21:45:14 DEBUG (MainThread) [homeassistant.components.rflink] unhandled event of type: unknown
2020-04-04 21:45:26 DEBUG (MainThread) [custom_components.rts_rflink.cover] async_added_to_hass :: oldState <state cover.somfybureau=open; assumed_state=True, friendly_name=SomfyBureau, supported_features=11 @ 2020-04-04T21:32:28.863732+02:00>

the last line should be printed for each cover configuration

8- enjoy :sunglasses:

So the strange behavior was only caused by some preventive checks on the configuration.
(the Hass.io should be more verbose about this behavior, like a popup warning “could not restart HA instance due to inconsistent configuration”…)

Hi @cartemere, I’m glad you were able to solve the problem.

Just ine comment, this config can be VERY verbose (especially if you have sensors configured):

I recommend deactivating it once the environment is stable

Yes, the logger is mainly there to ensure the rts_rflink plugin starts as expected.
It was also usefull for me to identify the ids from the existing remotes (the “alias” in the configuration).

Thank you again for the job, you rock ! :clap:

Hi Javicalle,
I wanted to use your scripts, but I can’t see covers available in lovelace view.
I well have the message:
You are using a custom integration for rts_rflink which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
also with:
CoverDevice is deprecated, modify RTSRflinkCover to extend CoverEntity

And when I use “platform: rflink” everything works.

I also ask, I don’t know, but in your script there isn’t the property “type: standard” to invert position of cover ?

Cdlt.

Hi @Cyrildu31,
I have done some quick & changes to migrate my class to the CoverEntity. I hope I haven’t broken anything along the way.

I’m not sure if it’s due to the previous change, but note that to make it available in Lovelace view you must add it first. Have you checked if the cover it’s available in the developer tab?

Not it isn’t. This property will define the cover class like an InvertedCover. Not an attribute to modify the direction behavior.
I can try to implement something similar, but it will take some time because these days I am too busy to find free time.

In any case, tell me if with this change you have been able to make it work. I will try to help you in what I can.

Im somewhat confused - not sure if I’m being an idiot or not, apologies.

I get that the custom_component tracks the position far better, but is it supposed to allow a timed or ‘my’ position to be given; I cant get this bit of the functionality working if it is.

Hi @macrowe,
the “MY” position is a functionality of the physical RTS blinds (a.k.a. Somfy cover), it is not a functionality of the cutom_component.
It has been included to control the cover position, but if your cover does not have that functionality, it is useless.

Cheers.

Sorry I should have clarified better, yes my cover has my position support - its just a standard Somfy RTS remote and it works on the controller. However, I can’t get it to work by pressing the stop button on the custom component.

Thanks for the answer though - ‘it should work’ - ive just got to keep debugging why its not.

Understood.

Does it work correctly with the RFLink implementation?
That is, without using the custom_component, does the cover respond to pressing the stop button moving to the “MY” position?

And, with the custom_component, what is your configuration?
Have you configured the values rts_my_position, travelling_time_down and travelling_time_up?

Hello,

I do what you said and it’s working very well now.
I only have 1 cover which is inverted, I use the previous origin platform only for this one.

I have a little delay when I launch command in hassio compared when the cover moves.
So maybe I’ll take a look at the code to see if I can manage that ? :roll_eyes:

Thank your for your contribution and reply :wink:

Do you have configured the wait_for_ack: false attribute? If not, there’s a lot of delay. If yes, there is a little delay :man_shrugging:

You can take a look at this part:

In my opinion the problem is not the implementation, it is the behavior of the RFLink that introduces a quite random delay difficult to handle.

Thanks for your words. I appreciate it.

I just added the attribute to configure the cover as inverted.
I haven’t tested the behavior, but it should work. You just have to replace your local copy of the cover class with the latest version from my repository
If you were so kind to try it and tell me if it works properly, I would appreciate it.

Hi,
So I tested the cover with inverted attribute and it’s working now, thank you.

And regarding the delay I already use wait_for_ack: false. I took a look on internet about this delay and yes it’s the rflink system with arduino bringing this issue.
So when I press Up or Down the counter start immediatly and the blind start after…I see this behaviour when I want to manipulate many covers.
I’ll look later if I can add a delay time in your code just for testing.

And if I’ll use wait_for_ack: true it’s only to wait rflink sending the acknoledgment to home assistant?

Nope, neither works with yours or the RFLink implementation - I was assuming it wasnt supposed to though tbf.

Config is:

platform: rts_rflink
devices:
  rts_d4c82a_01:
    name: Office Blind
    rts_my_position: 50
    travelling_time_down: 14
    travelling_time_up: 14

In my tests there was also a delay between RFLink sends the signal (my RFLink blinks when sending or receiving a signal) and the signal ACK is received in HA.

Despite being the same software, each RFLink can be built with different hardware, so I cannot generalize the behavior it will have for everyone. In my case (and my use cases) it was worse with wait_for_ack: true.
It is best that each one make their own tests to obtain the best results.

Playing around with several covers at once can be difficult also. Set position for 3 covers will came with concurrency problems.
That is, you move cover1, then you move cover2 and when you are going to move cover3 one the stop command comes for some of the other covers. That will cause some command to run substantially later than scheduled and the behavior may appear erratic.

In these cases, I recommend creating a new cover in HA and pairing it with multiple covers, so that with just one HA command you can operate different covers. If this is not possible you can also use the MY position to (with a single command) bring the blinds to the desired position (no need to move & stop)

If none of these options works for you, in your automations you can add a delay > max (traveling_time) between cover operations.

1 Like

My CC does nothing special with the stop command.
If it doesn’t work normally with the official RFLink implementation, it won’t work with this CC either.
Sorry.

Thank you very much tacking time to reply.
I’ll try with wait_for_ack or not.

In these cases, I recommend creating a new cover in HA and pairing it with multiple covers, so that with just one HA command you can operate different covers. If this is not possible you can also use the MY position to (with a single command) bring the blinds to the desired position (no need to move & stop)

So doing this I need to pair rflink system with another id on many covers ? I don’t know if it works, I tried to pair lot of covers with one rflink id, and randomly some covers are well paired and other not. And it changes when I try to pair again.
Do you think that we can pair many covers one by one on the same id in rflink ? Or the last one is paired? I’ll try also !
Thank you.