Homeassistant automations will not move shades when triggered

[hyperfive]

Hello

I'm having a very strange issue that I've tried everything to resolve. From both the MQTT and HACS integration in home assistant, by calling the shades from the cover open/close or esp somfy open/close service the same result happens.

When I operate the shades from the Lovelace UI or entity screen the shades work perfectly. Additionally when I am configuring an automation to call the shades when a button is pressed it works when I press the "Run" menu in the automation screen. However, when the automation is actually triggered the motor does not move. The strange thing is if you open the entity it shows the shade is either opening / closing but it doesn't move the motor.

This happens via both integrations (MQTT & HACS). I've tried just about everything including creating a script that calls the open/close command and having the automation trigger that script and it is the same result. Works from the browser when pressing run but when the automation runs it does not move the motor, just the UI in HA and ESPSomfy shows the motor moving.

I've updated to the latest firmware/software and hacs versions. This is the only thing holding me back from finally getting rid of our somfy mylink and having an awesome integration.

Attached is my ESPSomfy backup.

ESPSomfyRTS 2023-11-04T21_52_48.backup.zip

Thank you so much in advance for your help.

Dan

[rstrouse]

That is very odd. From every direction except one the motor responds correctly. Let's make sure we are working from only one interface so please go into the Network section and uncheck the Enable MQTT client checkbox. One other thing. Please set the TX power back to 10dBm on the radio config. I am pretty sure the E07 modules max out at 10dBm.

Which service are you using? There are two that simply change the position of the motor but do not send the command to move it. These are for things like gate positioners and sensors that trigger an absolute closed position.

[finder39]

I have had a similar issue. My current solution is to set the shades to a "different" location, delay for a second, then go to the intended location. See my code below:

  - service: cover.set_cover_position
    target:
      entity_id: cover.bedroom_shade
    data:
      position: 2
  - delay:
      seconds: 1
  - service: cover.close_cover
    target:
      entity_id: cover.bedroom_shade
    data: {}

[rstrouse]

That is so weird are there any errors in the HA logs?

[finder39]

What I noticed was that cover.bedroom_shade would already shown as "closed" if i tried to call it without that, causing nothing to happen. I never checked HA logs. It seemed like it would send it but nothing would happen?

Unless i did the above

edit: Just tried now with a very basic automation based on a time trigger and it worked. Its possible new versions of have fixed it? Will try removing this from my automation for now and seeing

Side note: I was actually having this issue in a script too

[finder39]

OK it just happened again! Yeah it doesn't seem to like working in this script:

goodnight:
  alias: "Goodnight"
  description: "Turns off most things in the house when. Takes guests into consideration."
  icon: "mdi:moon-waning-crescent"
  mode: restart
  fields:
    transition:
      description: "The transition time for lights"
      example: "2"
      default: 2
      selector:
        number:
          min: 0
          max: 60
    blinds:
      description: "Close blinds"
      example: false
      default: false
      selector:
        boolean:
    thunderstorms:
      description: "Start bedroom thunderstorms"
      example: false
      default: false
      selector:
        boolean:
    guests_override:
      description: "Guests override"
      example: false
      default: false
      selector:
        boolean:
  variables:
    transition: "{{ transition | default(5) }}"
    guests: "{{ guests_override | default(bool(states('sensor.guest_mode'))) }}"
    blinds: "{{ blinds | default(false) }}"
    thunderstorms: "{{ thunderstorms | default(false) }}"
  sequence:
    - parallel:
      - service: script.dining_room_lightstrip_daily_plan
      - service: light.turn_off
        data:
          entity_id:
            - light.bedroom_lights
            - light.bathroom_lights
            - light.closet_lights
          transition: "{{ transition }}"
      - service: fan.turn_off
        data:
          entity_id: fan.bedroom_ceiling_fan
      - service: media_player.turn_off
        continue_on_error: true
        target:
          entity_id: media_player.bedroom_sony_bravia_tv
      - if:
          - alias: "Close blinds"
            condition: template
            value_template: "{{ blinds }}"
        then:
          # - service: cover.set_cover_position
          #   target:
          #     entity_id: cover.bedroom_shade
          #   data:
          #     position: 2
          # - delay:
          #     seconds: 1
          - service: cover.close_cover
            target:
              entity_id: cover.bedroom_shade
      - if:
          - alias: "Start thunderstorms"
            condition: template
            value_template: "{{ thunderstorms }}"
        then:
          - parallel:
            - service: script.sonos_bedroom_thunderstorms
      - if:
          - alias: "No guests"
            condition: template
            value_template: "{{ not guests }}"
        then:
          - parallel:
            - service: light.turn_off
              data:
                entity_id: light.goodnight_lights
                transition: "{{ transition }}"
            - service: fan.turn_off
              data:
                entity_id: group.all_fans
            - service: media_player.turn_off
              continue_on_error: true
              target:
                entity_id:
                  - media_player.x_denon_avr_x3500h

And here is what the integration looks like, even though my shade is still fully open:

There is also nothing in HA logs about this

[rstrouse]

What is this in the log. This entire sequence is going on within about 6 seconds but the transition from Homekit is likely still occurring.

EDIT: Do you have conflicting schedules in Homekit?

[finder39]

The log has no entries related to this.

And I don't have any other conflicting schedules. For this test I ran the script directly from Developer Tools -> Services

[rstrouse]

So why is there a reference to Homekit calling set_cover_position? I circled it in the picture above. I do not see an open prior to that close and the final state on the screen is closed.

[finder39]

OH I get your question now. So I have this shade/cover exposed to Homekit/Siri via HA and ESPSomfy. While was running this test via 'Developer Tools -> Services' I would just use Siri to open it back all the way to rerun the test. So they were run in sequence (and manually) to make sure the cover was fully open (both in real life and in HA) before the next test.

[rstrouse]

Its weird because Homekit actually closed the shade not open it. It sent 100% to ESPSomfy RTS. There is some goofiness with that integration when it comes to covers. I have seen it say that it was closing in Homekit when HA said it was opening. Then if you reverse it in the code it open when it is closing. Removing it from Homekit and adding it back fixed it. I don't know if this is Homekit or the integration that is goofy.

[finder39]

Gotcha, weird. Yeah I mean I found this happening regardless of how I "opened" it, I just happened to use HomeKit this time, that is strange though.

In addition, when opening with HomeKit or other ways, its only when using a script that I have this issue of closing it and it not working

[rstrouse]

I'm just trying to figure out why this is happening to you and not me. It is very odd that any movement would be registered from the component since HA does not have any control over the entity. This is all controlled by ESPSomfy RTS and positions come directly from that. There should be no way that HA would change the position without being notified by it. I'll set up and try your yaml to see if I can make it happen.

[finder39]

Yeah I agree, its very strange. Happy to try more things if you send my way. Or if there is something I can add to configuration to make more logs appear let me know

[rstrouse]

Yes turn on debug logging for the integration. This will add any exceptions and messages to the homeassistant.log.

[finder39]

This is all I get with it on:

2023-11-07 17:04:03.425 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:03.435 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:03.637 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:03.852 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:04.092 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:04.275 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:04.485 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:04.713 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:04.909 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:05.141 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:05.338 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:05.547 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:05.762 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:05.969 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:06.032 ERROR (MainThread) [homeassistant.components.braviatv.coordinator] Command error: 
2023-11-07 17:04:06.188 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:06.393 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:06.606 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:06.828 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:07.033 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:07.246 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:07.454 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:07.673 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:07.880 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:08.094 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:08.303 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:08.520 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:08.727 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:08.944 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:09.193 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:09.365 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:09.589 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:09.794 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:10.000 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:10.212 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:10.422 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:10.637 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:10.846 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:11.075 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:11.271 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:11.484 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:11.718 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:11.907 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:12.119 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:12.333 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:12.545 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:12.759 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:12.968 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:13.178 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:13.393 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:13.603 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:13.816 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:14.026 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:14.242 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:14.450 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:14.664 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:14.874 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:15.088 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:15.301 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:15.533 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:15.723 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:15.937 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:16.149 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:16.357 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:16.571 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:16.784 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:16.997 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:17.231 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:17.421 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:17.629 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:17.845 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:18.059 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:18.305 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:18.477 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:18.712 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:18.901 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:19.167 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:20.788 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:20.789 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:20.803 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:20.804 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:20.804 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:20.811 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:20.857 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:20.860 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:21.021 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:21.235 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:21.445 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:21.667 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:21.873 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:22.083 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:22.294 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:22.510 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:22.718 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:22.932 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:23.145 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:23.358 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:23.569 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:23.783 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:23.992 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:24.203 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:24.416 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data
2023-11-07 17:04:24.630 DEBUG (MainThread) [custom_components.espsomfy_rts.controller] Manually updated espsomfy_rts data

And heres the latest stuff it's done:

[rstrouse]

Yeah that's not much help other than it is receiving the socket information to update the state. I assume the shade was moving during that period.

[finder39]

Nope, it was stationary and stayed open the whole time. This was me trying to run it via the script

[rstrouse]

Did it move in the ESPSomfy RTS UI?

[finder39]

Here is a video of me running the script, its popup in the UI, an the ESPSomfy RTS UI.

Notes:

• The first two times I run close via the script and even thought the UI in HA and in ESPSomfy RTS both show it closing it is not actually closing.
• The third time I tap the close button on the middle screen (which is the HA UI) and it does actually close.

[rstrouse]

Oh you need to go to the virtual remote and send the sensor command to clear the windy condition. The warning symbol indicates that it is windy and will make the shade operate to protect the shade.

[finder39]

Gotcha! I appreciate that, couldn't figure out what it was 😅

The same issue persists once thats cleared, but yeah, good to know!

[rstrouse]

It will exist for about 40 minutes.

[finder39]

Just gave it another go (about 70 minutes later) and same result

[rstrouse]

I just realized that I do not have a backup from you. I have one from @hyperfive but not yours.

Also, lets restate the issue since I see in the video the response sent over the socket where it emitted the command for down out of the radio when the automation is triggered.

1. Is this a mains or battery powered motor?
2. Does the motor move reliably and correctly when you press up, down, and my from the ESPSomfy RTS UI?
3. Does the motor move reliably and correctly when you press up, down, and stop on the HA entity?
4. Is there any other hub, link, or integration connected to the motor?

Please supply a backup file and click the reboot button on ESPSomfy RTS. Let's make sure that windy condition was actually cleared. When one of these sensors exist it sends that frame repeatedly after the wind condition clears. Go into the virtual remote, select the motor from the dropdown, ensure the checkboxes are not checked, then press the Sensor button about 10 times at a 1 second interval.

[hyperfive]

wanted to resurface this with answers in line. I’m dying to use this integration and get rid of mylink once and for all. If I can just get the shades to move when triggered from automation or script we will be golden.

I just realized that I do not have a backup from you. I have one from @hyperfive but not yours.

Also, lets restate the issue since I see in the video the response sent over the socket where it emitted the command for down out of the radio when the automation is triggered.

1. Is this a mains or battery powered motor?

battery

2. Does the motor move reliably and correctly when you press up, down, and my from the ESPSomfy RTS UI?

yes it works perfectly

3. Does the motor move reliably and correctly when you press up, down, and stop on the HA entity?

yes it works perfectly

4. Is there any other hub, link, or integration connected to the motor?

yes the mylink is still connected. I had to leave it in place to keep the buttons working in the house. I tried removing the integration and unplugging the device with no luck

Please supply a backup file and click the reboot button on ESPSomfy RTS. Let's make sure that windy condition was actually cleared. When one of these sensors exist it sends that frame repeatedly after the wind condition clears. Go into the virtual remote, select the motor from the dropdown, ensure the checkboxes are not checked, then press the Sensor button about 10 times at a 1 second interval.

[rstrouse]

For obvious reasons the transceiver cannot talk to more than one motor at a time. It is only one radio and even if you had more than one radio the signal would be clobbered by each of the radios talking at the same time. If you have your automation to run in parallel then this is a problem and you should not do this when triggering the device. HA will simply call each of the services without waiting for the last one to finish sending on the radio.

For the device activation on the same device do not set them to be parallel as HA does not honor the await on the call to the device before sending the next one. It will not wait for the movement to finish it only waits until it has sent all the bits it needs to send to the motor ~170ms.

[hyperfive]

I'm only doing this on one shade at a time. It's a single shade button for a single room :( I just tried it again after updating firmware and it still doesn't work from automations / scripts. works perfectly from the ESPSomfy UI / Homeassistant Lovelace but will not work from being called as a service / automation / script.

I would be willing to pay for this to be fixed. Please let me know anything I can possibly do to get this resolved.

Thanks

Dan

[rstrouse]

@hyperfive I have to be missing something here. The other user here had something understandable as the wind protection was turned on from the virtual remote. This does not allow the motor to close until the windy condition is cleared or the command is repeated within the cooling off time for the motor.

However, in your case I installed you backup, created a time trigger to close the bedroom shade and the shade obeyed the command by sending the appropriate radio signals to close the bedroom shade. Here is what I set up but perhaps I am looking in the wrong place or I don't have a clear understanding of what is going on. At exactly 9:53 the bedroom shade closed and the signal was picked up by all the other receivers on my network.

[joneshf]

I just happened to stumble on this issue, but I think I might have another case of it. I had assumed it was because the one blind I have setup is the furthest from the device (about 40-50 feet as the crow flies, but like 4-5 interior walls in the way). That blind has always had troubles due to how far it is from the devices (the ESPSomfy-RTS is supposed to replace a Bond Bridge right next to it).

In any case, the symptoms seem similar in that it works from the ESPSomfy-RTS/Homeassistant UI, but doesn't work from the automations. I'll try setting up some of the other blinds in the house on ESPSomfy-RTS and check back when I get a minute.

[hyperfive]

@hyperfive I have to be missing something here. The other user here had something understandable as the wind protection was turned on from the virtual remote. This does not allow the motor to close until the windy condition is cleared or the command is repeated within the cooling off time for the motor.

However, in your case I installed you backup, created a time trigger to close the bedroom shade and the shade obeyed the command by sending the appropriate radio signals to close the bedroom shade. Here is what I set up but perhaps I am looking in the wrong place or I don't have a clear understanding of what is going on. At exactly 9:53 the bedroom shade closed and the signal was picked up by all the other receivers on my network.

All signs point to it should be working. I’ve tried everything on multiple blinds and it has the same response.

Everything shows that it’s functioning except the blind doesn’t receive the command.

If we can do a FaceTime or screen share for 10 minutes I can show you everything in real time including logs. As well as everything I tried to fix it.

To confirm I will pay you for you time. I want to contribute to this incredible project. All I need to do is get it to work from my keypads around my house.

[hyperfive]

I just happened to stumble on this issue, but I think I might have another case of it. I had assumed it was because the one blind I have setup is the furthest from the device (about 40-50 feet as the crow flies, but like 4-5 interior walls in the way). That blind has always had troubles due to how far it is from the devices (the ESPSomfy-RTS is supposed to replace a Bond Bridge right next to it).

In any case, the symptoms seem similar in that it works from the ESPSomfy-RTS/Homeassistant UI, but doesn't work from the automations. I'll try setting up some of the other blinds in the house on ESPSomfy-RTS and check back when I get a minute.

Thank you, Please do! I have tried everything to resolve this and I’m sure it’s something simple.

[rstrouse]

Have any of you tried the simple case that I created above where the service is not called from another script? It is odd that when I create this automation from the HA UI it uses UUID for the device and entity ids.

alias: New Automation
description: ""
trigger:
  - platform: time
    at: "09:53:00"
condition: []
action:
  - device_id: 8dfd516b6dd1e8fec2dc29da68673e1b
    domain: cover
    entity_id: abc4b5b8a2bb7a2cff4d5ea2f70f33e0
    type: close
mode: single

[joneshf]

Have any of you tried the simple case that I created above where the service is not called from another script?

I tried both ways. Neither made a difference.

It is odd that when I create this automation from the HA UI it uses UUID for the device and entity ids.

alias: New Automation
description: ""
trigger:
  - platform: time
    at: "09:53:00"
condition: []
action:
  - device_id: 8dfd516b6dd1e8fec2dc29da68673e1b
    domain: cover
    entity_id: abc4b5b8a2bb7a2cff4d5ea2f70f33e0
    type: close
mode: single

This example, however, might have been the thing I was missing. I was using the "Call service" action. The automations didn't work with the "Call service" action. Seeing that YAML example above, I switch it to "Device" action. And now the automation seems to work.

in YAML, the diff was something like:

  alias: New Automation
  description: ""
  trigger:
    - platform: time
      at: "09:53:00"
  condition: []
  action:
-   - service: cover.set_cover_tilt_position
-     data:
-       tilt_position: 50
-     target:
-       device_id: 01e73960c23837dbede25c376410b9ad
+   - device_id: 836b9207cb6035b4d6288dd174bb97bf
+     domain: cover
+     entity_id: 013b65d62424e3808c7b2b28753a3713
+     type: set_tilt_position
+     position: 50
  mode: single

The device_id changed in this diff. Maybe that was the whole problem (using the incorrect device). But, it was the same behavior whether I used the Area with the blind, the Device of the blind, or the Entity of the blind.

Perhaps said in a different way that might be clearer to others, the change that got things to work for me was moving from calling a service on the cover.<whatever> to using the ESPSomfy RTS device and selecting the appropriate blind. I'm not sure why or how it's different, but this has worked in my limited testing so far. I'll try to update after living with it for a while.

[joneshf]

Just setup four more blinds. So far it seems okay. I'll let it go for a few days, and check back.

[hyperfive]

Hi, so I tested this and it works :) It is still not working from the Lutron Pico switches but I will go and attempt to identify why this isn't working. Will post back results shortly.

Do you happen to know what the issue is why they are not working from the esp somfy custom service? As well as from the default service by calling the alias (eg "cover.bedroom") I'm wondering if it has something to do with HA looking for a device versus an entity.

Here is the code that I used that worked

alias: Debug ESP Somfy Shade
description: ""
trigger:
  - platform: time
    at: "17:45:00"
condition: []
action:
  - device_id: 331990c4581d85b6915d1ff618d59e2f
    domain: cover
    entity_id: f7c89277194b705c6c6edebb7ac6bfe2
    type: open
mode: single

[rstrouse]

The issue for this is simple now that you figured it out. While the service exists on the device, the entity is always the target. There is no such thing as open or closed on the device since there are many entities on that device it needs to know which one.

While it is understandable the services are attached to the hub (aka Device) and the targets are always the entity in the hub model.

[hyperfive]

Unfortunately it’s not working except from the time trigger. It seems to be something the way the integration is being triggered. There is definitely something unusual with your specific driver as I have hundreds of devices and automations and I’ve never had this issue.

Here is an example of log event of what isn’t working. It shows in the rts ui that it works but the shade doesn’t move.

Bedroom Shade RTS is opening triggered by automation Pico - Bedroom Shade triggered by event 'lutron_caseta_button_event'

[rstrouse]

I didn't get the attachment. Perhaps you forgot to include it. Anyhow, I will try to replicate this by triggering from another event. To be certain, you are not calling any of the set_current* services as these are designed to not move the motor. I am not that well versed in the automations side of HA and I set the services up using the half-documented services.yml example. It was a trial with lots of errors.

[rstrouse]

Can I get the yml for the automation Pico - Bedroom Shade. Messed around with triggering based upon the state of other items but had success triggering the close_shade and open_shade services and device commands with everything I did. We have to be missing something here.

Unfortunately, there are multiple issues being discussed in this thread. So far we have the following.

1. One user had the windy override set on their shade. This of course (depending on the motor function) raises the lift of the shade no matter what. It also requires sending the command more than once in a period to get the motor to respond (override)
2. Another user was calling the service without specifying the entity. This will not work as the device does not have an implementation of the services. Odd that HA allowed that to be configured but I suspect there is some generic implementation on the base cover device because it is not always a hub implementation.
3. Then there is your case where it almost appears that the set_current_position service is being called. In this instance the expectation is to change the position in ESPSomfy RTS without engaging the radio. This is for things like gate limits or locks where the state is changed based upon an endstop device as well as timing. Endstop commands will also be received when a wind or sun sensor is linked to the motor.

I think I need to try to set up your sequence with a generic device since I do not have a pico to try it with. I have tried it by calling the service from the devtools and triggering it from another device and it worked fine.

[joneshf]

Just setup four more blinds. So far it seems okay. I'll let it go for a few days, and check back.

This is me checking back. Using the ESPSomfy RTS device and selecting the appropriate blind has been working great. There's some other unrelated thing, but I'll do some searching to figure that part out (I swear I saw an issue about it the other day).

[rstrouse]

I am closing this for now. There have been a lot of updates since this was opened some of them focused on the services. If this is still an issue lets start over with a new issue.

[anthorou1]

Hi, I hope this might help others. I also had issue only if using an automation triggered by Pico Remote. Every other Trigger were working fine. I simply add a 500ms delay before calling the service to open/close the shade and now everything seems to work fine. Maybe they are on similar RF frequency that might cause interference.

[rstrouse]

The pico does transmit in the 433 range. This can make the motor receiver wait for inter frame silence. Another way to combat this is to add a repeat command for the ESPSomfy shade definition.