Just put up to beta v0.0.25 with a feature request from @Techman

Added a field called Last Command Executed which upon startup is populated with None then moves to {Open, Close, Stop, or My Position} based on the command given.

Note that if the RTS shade is moved manually with the remote or even from the Tahoma app, there is no feedback here, this is purely as a memory for your programs ; careful as you use it.

Feedback welcome as we tweak this plugin.

## 0.0.25

- Shade Last Command Executed (GV8): new status alongside Last Command (GV7); reports Open, Close, Stop, or My Position when sent; starts as None on node startup; GV7 still tracks Pending / Completed / Failed from the gateway

Nice. Did you give some thought to the timed open/close, to allow a command to open or close a certain percentage?

@Guy Lavoie ,

I did , then I forgot, good reminder. I'll put it in my todo list, yours is a bit more complicated.

Last bit has been busy with life, when I had plugin time I did a bunch of spring cleaning and got some of the older plugins common on the backend. Was slowing me down when everytime I switched work to a plugin the workflow was so different.

Edited yesterday at 11:57 AM1 day by sjenkins

@Guy Lavoie , (and anyone else who has 2c to give),

The way I see it this is just an RTS shade function (shouldn't be needed in the new positional based ones).

1. The user enters a time to fully raise/lower, Total Span Move Time

2. We add a command with parameters Move by %

3. This command is Activate with parameters of Move %(1-99), Direction (up,down)

4. The program sends a up/down command, then Stop after x seconds. x being: Move % x Total Span Move Time

5. Thinking now of status. As the shade can be moved manually I don't think keeping a % position has any value. I think the Sade Last Command would be something like Move%

Does the above meet your vision?

1 hour ago, sjenkins said:

@Guy Lavoie , (and anyone else who has 2c to give),

The way I see it this is just an RTS shade function (shouldn't be needed in the new positional based ones).

1. The user enters a time to fully raise/lower, Total Span Move Time

2. We add a command with parameters Move by %

3. This command is Activate with parameters of Move %(1-99), Direction (up,down)

4. The program sends a up/down command, then Stop after x seconds. x being: Move % x Total Span Move Time

5. Thinking now of status. As the shade can be moved manually I don't think keeping a % position has any value. I think the Sade Last Command would be something like Move%

Does the above meet your vision?

Yes, sounds right!

Here is the description of this functionality in the Somfy plugin:

In order to provide a shade position in the ISY, the time it takes for the shade to travel from fully closed to fully open is used. If the shade travels for half of this time, it's assumed to be at 50%.

• Each shade's travel time can be specified in the polyglot configuration.

  • For each shade, create a key corresponding to its address seen in the admin console. For example, if the shade's address is shown as 'n001_01_01_01', create a key '01_01_01'. It's value can be a number corresponding to the shade's travel time.

• If no travel time is specified, the node will use a default value of 8 seconds. The time can also be specified in the ISY using a command, but note that this will not persist across node server reboots.

24 minutes ago, Guy Lavoie said:

• If no travel time is specified, the node will use a default value of 8 seconds. The time can also be specified in the ISY using a command, but note that this will not persist across node server reboots.

@Guy Lavoie ,

ok, can do a default time as well (just timed my outdoor Phantom blinds and they take almost 26s to raise). Looks like the old plugin used configuration variables. In the new EISY api the retention across boots and installs is not an issue. the problem with doing it in a config is you don't know the node number until the first boot anyway and this node number can change with a rediscover. I think I would implement with a settable value which is stored as a persistent value. Sound Kosher?

2 minutes ago, sjenkins said:

@Guy Lavoie ,

ok, can do a default time as well (just timed my outdoor Phantom blinds and they take almost 26s to raise). Looks like the old plugin used configuration variables. In the new EISY api the retention across boots and installs is not an issue. the problem with doing it in a config is you don't know the node number until the first boot anyway and this node number can change with a rediscover. I think I would implement with a settable value which is stored as a persistent value. Sound Kosher?

Yes. Personally I was setting the time values in programs, and not as plugin configuration parameters. It was just easier and more visible.