bitfocus
[Feat] Variables for each connection indicating if it's connected
Is this a feature relevant to companion itself, and not a module?
- [X] I believe this to be a feature for companion, not a module
Is there an existing issue for this?
- [X] I have searched the existing issues
Describe the feature
Use Case: A device was not on when Companion started so it is in Error status. The corresponding device module does not check occasionally to see if the device is now active. If a person knows of this state, they can disable/enable the connection and the module functions as expected.
Current workaround: Test the number of connections (N) that are OK as a guess that all connections are active. If not toggle the problematic connection incase the device is up.
Improved the workaround by adding a generic HTTP module to the device's admin web site of the device every 10 seconds. This works if the number of connections goes from N-2 to N-1, which then triggers the action to disable/enable the problem connection.
Usecases
Use Case: A device was not on when Companion started so it is in Error status. The corresponding device module does not check occasionally to see if the device is now active. If a person knows of this state, they can disable/enable the connection and the module functions as expected.
See the work around above.
It would be better if the workaround could be revised based on the connection status of the particular module's connection status rather than just blindly disabling/enabling the connection when the "OK" value is less than the expected max.
Should this be a variable or a boolean feedback?
If it is a variable, the current status values are null | 0 | 1 | 2, which I guess should be converted to some better strings disabled | ok | warning | error?
Good questions. Initial preference is a variable with 4 values.
As you noted the strings are better than the status values.
Side note: Trying to understand how folks determine if a connection status of Error means "Have been communicating but recently toggled from OK to a state of Error." Vs "Connection has been in the Error state since Companion started, and has never been in the OK state".
It will be perfect for triggers. I want to achieve that if some connections are lost (like my atem get disconected) i want to push some notifications to the external clients (like websocket connection) via triggers, but is not possible, because "Internal: Connections: Atem" allow only "change color of buttons" but not triggering any kind of triggers.
So maybe this can be pushed little bit futher and add connections triggers like "Internal: Connections: Atem: State" and Action will be like common (do something, like set button color, send websocket message and so on...)
Thank you. I hope that make sense.
+1 for this! Would be hugely useful. Also for software instances such as Reaper ie if Reaper quits
+1 for this! Just googled while trying to add as a quick status indicator on all connections - would be super useful.
+! - have a temporary PTZ camera only used on occasions - would be excellent to disable common functions for that camera when not available and not just change a button status
This is now supported in the betas.
Each variable can have a value of good, warning, error or disabled
The meaning of each of these can vary across modules. For example, since 3.0 modules are encouraged to treat being disconnected as an error, but many treat it as a warning.
This is all great - thank you. I’ve downloaded the latest beta to my Mac (ARM 64) and I’m struggling to use the variables - I see them but they won't allow me to use them in, for example, changing the Current Step of a button.
In V3.1, I can do quite a bit of work at home, disconnected from the actual hardware, and then take it on site and test it. With 3.2, for me to be able to code using these variables, do I need to be connection to, for example, the camera? I know that was the case with some ATEM commands - has it extended in 3.3?
Kind regards,
Chris
On 17 Dec 2023, at 8:19 pm, Julian Waller @.***> wrote:
This is now supported in the betas. Each variable can have a value of good, warning, error or disabled
The meaning of each of these can vary across modules. For example, since 3.0 modules are encouraged to treat being disconnected as an error, but many treat it as a warning.
— Reply to this email directly, view it on GitHub https://github.com/bitfocus/companion/issues/2029#issuecomment-1859272858, or unsubscribe https://github.com/notifications/unsubscribe-auth/BA2KHP7RVG66AIYVG2F4STTYJ5HUHAVCNFSM5WVUU7E2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBVHEZDOMRYGU4A. You are receiving this because you commented.
@Julusian - What is the target for moving this to a stable build? Also, is there some method that I could track this myself so I don't need to ask in a post?
Thank you for the guidance.