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)