Cover service call is not always working, depending on the specific call context

Configuration
1

Hi there,

I have a relatively minimal proof-of-concept script that moves a zwave-based shade cover up (by sending a cover.open_cover command to the corresponding zwave entity), and for some reason the script executes fine when I run it in the UI (by hitting the “Run” button in the Configuration>Scripts view), but it seems to execute slightly differently when run as part of an automation (specifically, mapped to a physical WiFi button that otherwise works well and I’ve tested extensively).

In both cases I can see that the state of the cover changes (from 0 to 255 and vice versa) when going to the state inspector, but when run from within an automation, the physical cover doesn’t move. The physic It’s almost like there is some state caching/magic that tries to prevent the physical shade from moving, but that magic is only in place when the script is running from within an automation. When hitting the “Run” button in Configuration>Scripts that magic is not in place, and the physical shade seems to reliably move every single time.

Might anyone have any idea what could be happening here?
Thanks!

2

what about showing us your automation and script in question dont forget to format correctly

3

Yes, good point. Sorry I should have done this to begin with. I tried to isolate this a bit more, and it turns out that I’m observing odd behavior even without automation.

Starting with a simple script, running the following works fine as expected – my zwave js controlled shade goes down:

covercloseonly:
  alias: coverCloseOnly
  sequence:
  - service: cover.close_cover
    target:
      entity_id: cover.z_wave_to_rts_interface_virtual_node_2
  mode: single

However, surprisingly, as soon as I also turn on a light in the same sequence, the cover does not close anymore. The light turns on reliably, but the shade won’t move:

lightonandcoverclose:
  alias: lightOnAndCoverClose
  sequence:
  - service: light.turn_on
    target:
      entity_id: light.dining_room_chandelier
  - service: cover.close_cover
    target:
      entity_id: cover.z_wave_to_rts_interface_virtual_node_2
  mode: single

No luck when swapping the order of light and cover. The following results in the same surprise – the shade won’t move either, but the light still turns on reliably:

covercloseandlighton:
  alias: coverCloseAndLightOn
  sequence:
  - service: cover.close_cover
    target:
      entity_id: cover.z_wave_to_rts_interface_virtual_node_2
  - service: light.turn_on
    target:
      entity_id: light.dining_room_chandelier
  mode: single

However, if I issue the cover.close_cover service call twice in a script, then the shade will go down again reliably:

coverdownandlightonandcoverdown:
  alias: coverDownAndLightOnAndCoverDown
  sequence:
  - service: cover.close_cover
    target:
      entity_id: cover.z_wave_to_rts_interface_virtual_node_2
  - service: light.turn_on
    target:
      entity_id: light.dining_room_chandelier
  - service: cover.close_cover
    target:
      entity_id: cover.z_wave_to_rts_interface_virtual_node_2
  mode: single

I tested each statement here 5-10 times in order to rule out any wireless transmission flakiness. All effects I’m describing here occur with out a single fluke. Prior to each script invocation, I’m manually (with an external controller) putting the shade to 50% down, and I’m turning the light off.

My conclusion is that a cover.close_cover service call, at least when sent to my to zwavejs setup, may or may not result in the physical device moving, and whether or not it does depends on the specific circumstances the service call occurs. I assume that this is also what made my more complex example in my first post go awry. But I don’t understand why this would be the case.

(I’m slightly rephrasing the topic title now that I reduced this to a simpler example)