Is this a feature relevant to companion itself, and not a module?
Is there an existing issue for this?
Describe the feature
Companion times out actions after 5s right now. Unlike "learn" operations that can be statically extended 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.
Is this a feature relevant to companion itself, and not a module?
Is there an existing issue for this?
Describe the feature
Companion times out actions after 5s right now. Unlike "learn" operations that can be statically extended with
learnTimeout, action timeouts can't be extended.A
callbackTimeout: numberaction 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-viscamodule 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.