Strange Automation behavour RF Switches and Motion Sensors

Yes I will try that

I have posted this on other forum to get help but here is my thoughts so far:

Guys I’ve just started using that platform: rpi_rf too for automation and switching RF wall switches. I had to do whole day troubleshooting as I can’t get it working properly. So my thoughts:

  1. Problem is - the signal sometimes refuces to be sent and sent with unknown parameters as I’m analyzing transmitted signal with separate arduino-RF receiver over serial and very rare I see transmitted signal - RC-Switch is not even recognizing the type of transmitted signal, where motion sensor signal and signal from other platform - rflink using the same hardware is recognized very well.
  2. There is problem with signal repetition, despite defining in the yaml - signal_repetitions: 30 Only 1 command sent (my signal analizer sometimes catch it.
  3. I think the problem is also with delays as if for instance, Like I’m doing, you use 433mhz motion sensor and transmitter also works on the same frequency to send command to the wall switch, then repeated several times signal from motion sensor interfere with signal sent to the wall switch. I have implemented 2sec delay and things got little better - working some time, but not constantly.

Did anyone got this protocol, platform working with constant results?

I have added delay 1sec and then command to switch on 5 times, but no looks like you were right, it does not repeat same command twice if state is already ON

By the way did you use capital/uppercase letters in defining switches like “Toilet_Light01” or “LAB_Light01”, then it could create issues. Always use small letter/lower case letters in such config. Change all such uppercases except in the name field and try. This could have been an issue.

And secondly to achieve repeated triggering there is a way around for this. But you have to change the config like below.

 - platform: rpi_rf
    gpio: 17
    switches:
      lab_light01_on:
        code_on: 1020001
        code_off: 0
      lab_light01_off:
        code_on: 1020018
        code_off: 0

In this way you will get two switches for a single device so that you can turn off the switch without turning of the light. and automation. you can do this.

  - repeat:
      count: '5'
      sequence:
        - service: switch.turn_on
          data: &ref_0 {}
          entity_id: switch.lab_light01_on
        - &ref_1
          delay: '00:00:01'
        - service: switch.turn_off
          data: *ref_0
          entity_id: switch.lab_light01_on
        - *ref_1

But that is going to be 2 separate switches? I need one switch, I’m using it to control light from UI too

Try this and check

If I go that way, I have rflink, I’m using it to receive signals from motion sensors. I’d rather use that then. It works great exept it has just like the way you showed me, separate switches for ON and OFF, I couldn’t get it learning (bug with it’s firmware) but repeating is OK and it works both to transmit and receive signals
Maybe there is a way to get rflink working?

My code is below:

  - platform: rflink
    devices:
      ev1527_00f906_01:
        name: My LAB light 02
        signal_repetitions: 5

      ev1527_00f907_09:
        name: 2nd_F_Stairs_Light01On_Code
        signal_repetitions: 5
      ev1527_00f907_0a:
        name: 2nd_F_Stairs_Light01Off_Code
        signal_repetitions: 5
      ev1527_00f907_0b:
        name: 2nd_F_Stairs_Light02On_Code
        signal_repetitions: 5
      ev1527_00f907_0c:
        name: 2nd_F_Stairs_Light01Off_Code
        signal_repetitions: 5

As I said it created separate switch for each command and switching On and OFF those switches just repeat the same signals

Can two switches consolidated into one using automation?

we can consolidate two switches into one using a template switch.

Like this

switch:
  - platform: template
    switches:
      2nd_f_stairs_light01:
        turn_on:
          service: switch.turn_on
          data:
            entity_id: switch.2nd_f_stairs_light01Oon_code
        turn_off:
          service: switch.turn_off
          data:
            entity_id: switch.2nd_f_stairs_light01off_code
1 Like

Thanks will try that!

Appreciate that mate, works perfect now. So to finalize:
This solution is not simple and requires 2 transeivers:

  • List item
  1. First one hooked to GPIO17(TX) and GPIO27(RX) for sending simple fixed codes (8digit)
  2. Second one is homemade RFLINK (arduino mega pro + 2nd transeiver for instructions on how to assemble refer to documentations). This one is both sending and receiving 433(315 or any other) Mhz fixed codes.

I have created switches.yaml file (must include reference to it in configuration.yaml file i.e. !include switches.yaml)
here I have:

  - platform: rpi_rf
    gpio: 17
    switches:
      2nd_Floor_Stairs_Light01:
        pulselength: 320
        protocol: 1       
        code_on: '1020025'
        code_off: '1020026'
        signal_repetitions: 5
        
      2nd_Floor_Stairs_Light02:
        pulselength: 320
        protocol: 1      
        code_on: '1020027'
        code_off: '1020028'
        signal_repetitions: 5

This above for sending RF signal in simple format (24bit fixed code). It works, but not perfect, signal repetition does not work even if you put 1800 times there, signal is very strange and RC-Switch arduino sketch struggles to identify signal nature, but wall switch surprisingly accept and actions BUT only if switch hit manualy in HASSOS WEB UI, automations works but there are issues written above in conversation.
There for…

Below is taken from entity register - registered RFLINK codes when activated above simple codes.

  - platform: rflink
    devices:
      ev1527_00f907_09:
        name: 2nd_F_Stairs_Light01On_Code
        signal_repetitions: 5
      ev1527_00f907_0a:
        name: 2nd_F_Stairs_Light01Off_Code
        signal_repetitions: 5
      ev1527_00f907_0b:
        name: 2nd_F_Stairs_Light02On_Code
        signal_repetitions: 5
      ev1527_00f907_0c:
        name: 2nd_F_Stairs_Light01Off_Code
        signal_repetitions: 5

Below is template to consolidate 2 commands from 2 switches into one switch

  - platform: template
    switches:
      2nd_f_stairs_light001:
        turn_on:
          service: switch.turn_on
          data:
            entity_id: switch.2nd_f_stairs_light01On_code
        turn_off:
          service: switch.turn_off
          data:
            entity_id: switch.2nd_f_stairs_light01Off_code

All said above sounds “super simple” isn’t it? But for now this is how to get below automations to work:

Binary Sensors (codes from motion sensors received using RFLINK:
binary_sensor.yaml file:

  - platform: rflink
    devices:
     ev1527_0ffaae_00:
        name: Sensor Motion StairsOff
        device_class: motion
        off_delay: 5


automations.yaml file:

- id: '1611304514042'
  alias: New Automation Light ON
  description: ''
  trigger:
  - platform: state
    entity_id: binary_sensor.sensor_motion_stairson
    to: 'on'
  condition: []
  action:
  - delay: 00:00:01
  - service: switch.turn_on
    data: {}
    entity_id: switch.2nd_f_stairs_light001
  mode: single
- id: '1611304642082'
  alias: New Automation Light OFF
  description: ''
  trigger:
  - platform: state
    entity_id: binary_sensor.sensor_motion_stairson
    to: 'off'
    for: 00:01:00
  condition: []
  action:
  - delay: 00:00:01
  - service: switch.turn_off
    data: {}
    entity_id: switch.2nd_f_stairs_light001
  mode: single

If you have better solution using RF switches and peripheral please share your way.

If you have already your switches in RFLink, why do you continues using the rpi_rf integration?
If I understand correctly, you can now control the lights from RFLink

Also, you can use the rflink.send_command service to trigger your lights. This way you don’t have to worry about the lights state.

This could be something like (not tested):

- id: '1611304514042'
  alias: New Automation Light ON
  description: ''
  trigger:
  - platform: state
    entity_id: binary_sensor.sensor_motion_stairson
    to: 'on'
  condition: []
  action:
  - delay: 00:00:01
  - service: rflink.send_command
    data:
      command: 'on'
      device_id: ev1527_00f907_09
  mode: single
- id: '1611304642082'
  alias: New Automation Light OFF
  description: ''
  trigger:
  - platform: state
    entity_id: binary_sensor.sensor_motion_stairson
    to: 'off'
    for: 00:01:00
  condition: []
  action:
  - delay: 00:00:01
  - service: rflink.send_command
    data:
      command: 'on'  # <-- not sure wich command (on/off) goes here 
      device_id: ev1527_00f907_0a
  mode: single

I believe that the automation part can be done without the 2nd_f_stairs_light001 template.
The template will still be necessary to show (and control) in the UI of the state of the light, but not to use it in automation.

Thanks, rpi_rf is used to transmit code, which is programmed to the wall switch, not sure if rflink can generate random or given command and transmit it, maybe yes, but not sure… Lts say I want 10200012 to be transmitted protocol 1, 24bit Fixed code, how I’m suppose to do it using pure rflink through Home Assistant?

Your automation is triggering the switch on/off for the template device (switch.2nd_f_stairs_light001).
This template is using 2 devices for switch on/off:

  • switch.2nd_f_stairs_light01On_code
  • switch.2nd_f_stairs_light01Off_code

According to your configuration, these are RFLink devices. I don’t see that you are using the rpi_rf integration (at least for the automation part).

I’m not sure about this part, but from what you’ve put forward, it appears to be a simple decimal to hex conversion:

code_on: '1020025' --> F9079 --> 00F907 09 --> ev1527_00f907_09
code_off: '1020026' --> F907A --> 00F907 0A --> ev1527_00f907_0a

code_on: '1020027' --> F907B --> 00F907 0B --> ev1527_00f907_0b
code_off: '1020028' --> F907C --> 00F907 0C --> ev1527_00f907_0c

For 10200012 it could be 9BA3CCev1527_09ba3c_0c, don’t you think?

2 Likes

yes, you are absolutely right! Thanks

Coming here from another thread — the problem in @elik745i’s earlier post was that the trigger included attribute: mode, which meant it was watching for that likely non-existent attribute to change, rather than the state.

Seems to be user error exacerbated by the GUI automation editor design.