Actions should be able to request extensions of the timeout interval (ideally repeatedly) or specify an increased timeout duration

[jswalden]

Is this a feature relevant to companion itself, and not a module?

• I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

Companion times out actions after 5s right now. Unlike "learn" operations that can be statically with learnTimeout, action timeouts can't be extended.

A callbackTimeout: number action property would suffice, but it would require specifying tens of seconds or maybe minutes of time. So perhaps it makes more sense to either allow an action to increase its own timeout by, say, context.extendTimeout(), or to add another callback to actions that Companion can invoke to ask something like, "Hey, you still churning away?"

Usecases

The ptzoptics-visca module includes functionality to recall camera presets: the pan/tilt/zoom position of a camera, focus/exposure/etc. settings, and the speed the camera should move from whatever its current position is to its final position. This is implemented by sending a short TCP command to the camera; the camera responds with a short ACK message upon initiating the move, then responds with a Completion message when the move completes (or is superseded by initiation of another camera movement). All camera commands follow this pattern, but most respond ACK/Completion without delay.

Presently module actions are nonblocking and don't defer completion until ACK/Completion messages are received. (This is deliberate, in order that recalling a preset not block aborting that preset recall to recall a different one -- as might happen if, say, you had separate Companion buttons for each and you fat-fingered the wrong button.) Action execution is still sequenced because every action writes into one TCP stream to the camera.

If I want to change the module to support sequential actions -- to allow recalling a preset and then performing an action only after it's recalled -- I would make actions not resolve until the Completion is received. But I can't do that for preset recalls that take more than 5s, which is possible for a slowest-speed 359° rotation recall.

[dnmeid]

Basically I agree. With the new sequential groups there should be a possibility for actions to run longer than 5s.
I think we still should have some reasonable hard limit, I'm not sure about the duration though. The concern is that a module may be faulty and just claims that it needs more time but this may take forever. As a user I'd consider maybe 90 seconds would be a time I could stand when a module halts on error.
For even longer running actions I think we would need to find a new workflow where the user has the ability to abort it.

[Julusian]

An idea I am wondering about is whether the duration of this timeout should be specified by users?
The module could declare an action as needing longer timeouts, which would enable a field in the ui for the user to choose the timeout duration.

My reasoning for this is that it makes the user aware that this action can be slow and lets them choose how long they are willing to wait. For cases like the PTZ, this would let them put in an appropriate time for the move they specify.

There would definitely be a high risk of user confusion and error though, so I am not sure this is a good idea.

Maybe this works in conjunction with the module requesting more time, as a cap on the duration. Probably with a sensible default provided by the module.

The concern is that a module may be faulty and just claims that it needs more time but this may take forever.

I share this concern

[dnmeid]

An idea I am wondering about is whether the duration of this timeout should be specified by users?

Yes, that's what I mean with a new workflow.
I'm thinking of three different stages:

• a default timeout when neither the module nor the user cares about it
• a longer but not excessive long timeout that the module can declare
• an unrestricted timeout by request of the user

I'm not sure about the best option to offer this to the user. For the scope of this issue I'd say we stick with the middle solution.

Another related idea would be to give the module the possibility to continously report a progress of an action.

[jswalden]

The various concerns about faulty actions, desire to abort (I have thought briefly about how to allow users to enable some kind of module/action-specific aborting behavior), maybe it being user-configurable or maybe not and that being possibly confusing, or maybe requiring modules to continually report progress (maybe it's a 5s timeout but if the module indicates progress in shorter time the timeout is reset?), are reasonable. 🙂

(Although for this PTZ case specifically, the action would have to send additional, periodic, presently-unnecessary inquiries to track its interpolated position in order to report progress. I wouldn't relish coding this. But it could be done.)

I don't have the cameras in front of me to test, but I did recently test panning at slowest programmable speed and it appeared that it could take definitely tens of seconds to pan 359° and tilt somewhere 90-180° and zoom from closest in to furthest out, and at least very close to a minute if not longer. I don't know if 90 seconds would be enough time or not off top of my head. But it does seem unlikely that PTZ cameras, as the first reported use case for this, would also coincidentally have the most extreme timeout requirement.

[dnmeid]

the action would have to send additional, periodic, presently-unnecessary inquiries to track its interpolated position in order to report progress

The PTZ is your usecase, we need to deal with all possibly long running actions.
I consider continous progress reporting related, but independent from a timeout. It would just be a possibility to let the user know that this action is still running and everything is fine.

[jswalden]

The PTZ is your usecase, we need to deal with all possibly long running actions.

Certainly. Just saying, progress may be difficult or expensive or even impossible to acquire for some use cases.

I consider continous progress reporting related, but independent from a timeout. It would just be a possibility to let the user know that this action is still running and everything is fine.

For only a five-second timeout, some kind of periodic progress notice probably isn't necessary, so timeout expansion is a prerequisite to progress notification.