Having a switch trigger multiple times when told to turn on?

I have a Tasmota controlled Switch that triggers a standard style Garage Door Opener remote.

This remote actually opens our gate, which is not in view of the house.

I have programmed Tasmota to press the remote to “ON” for 1 second whenever it is triggered, then immediately toggle itself off. This is because holding it for over 10 seconds will put the remote into programming mode, and I obviously do not want that.

When I need to trigger the gate, I find myself hitting the gate open button multiple time because the gate itself cannot return state, I can only trigger the remote.

What I would like to do, is that whenever the gate is told to open, this action presses the button about 10X over 30 seconds so I can be sure that the signal reached the gate. Given that there are trees between the line of sight to the gate, the reliability varies by weather conditions - wind can make the signal very erratic as the trees move.

This way, when guests are arriving or leaving, I can be sure that the gate has opened for them, even though I cannot see them.

I have converted the switch to a gate like so:

- platform: template
  covers:
    garden_gate:
      device_class: gate
      value_template: "{{ is_state('switch.gate', 'true') }}"
      friendly_name: "Garden gate"
      open_cover:
         service: switch.turn_on
         target:
           entity_id: switch.gate
      close_cover:
         service: switch.turn_off
         target:
           entity_id: switch.gate

What is the best way to ensure that the gate opens for guests, even when we cannot see it?

Why not place a door sensor on the gate, so you know the state? then you can automate the open way better, prevent that the remote keeps sending open while it is already open, or worse, when you wanted it to close after use? Then you can also make a template cover that truly represents the door state.

As for your original question, instead of actually operating the switch, I would call a script to do the real work. That script can contain the logic. It can be as simple as a couple of open/close commands with a delay inbetween. So create a script “Open gate”:

alias: Open gate
sequence:
  - repeat:
      count: '10'
      sequence:
        - service: switch.turn_on
          target:
            entity_id: switch.gate
        - delay:
            hours: 0
            minutes: 0
            seconds: 3
            milliseconds: 0
mode: single
icon: mdi:gate-open

and for the action, put this in the template:

      open_cover:
         service: script.open_gate

Thanks!

That will work!

I would love to put a door sensor on the gate, but it is very far away, and through trees. I would need to set up a point-to-point wifi bridge to be able to properly communicate with the gate as nothing else would really have the range. The 400mhz remote works most of the time because I placed it in the one tiny corner of the house where you can almost see the gate. I usually need to use binoculars from that one room to see if the gate is actually open, and at night, it is impossible to tell.

Getting state back from the gate would be great if I could figure out how to do it.

Don’t know if garage door controllers can also be used on gates?

Other long range z-wave should be released at some point too, so who knows…

I have tried various z-wave devices around my property, and they don’t even reach 1/4 of the distance to the gate. They simply go dark.

The gate itself is shared, and the power isn’t from our house, otherwise I would use ethernet over powerline to get a signal. As near as I can tell, my only real option for getting state would be to get a project box, put a raspberry Pi in it with a gate sensor, and maintain a point-to-point wifi connection with something like a Ubiquiti Nanobeam setup.

z-wave long range is not ‘just’ z-wave, but it remains to be seen how far this new technology will go.
Are there lights on your driveway that are powered from your home, and could place a ethernet zigbee controller close enough?

My guess is that anything working in that way would need to be constantly powered, as the inverse square law would rapidly drain the batteries unless the signal was somehow targeted.