bitfocus
IP Address of specific Connection as variable
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
Would love to be able to call the IP address of each connection via a variable. This would be under "internal", and could be something like $(internal:atem_ip) or $(internal:playoutbee_ip).
Usecases
Mainly, this would be useful to pass the IP address into batch scripts. For example, I use several batch scripts which can upload images to my ATEM mini, which I call from Companion. These scripts require the IP address of my ATEM. I could hardcode them within the .bat files themselves, but each time I change locations/networks, I'd need to edit each of my (many) scripts. It would be way easier to just change the IP of the ATEM in Companion, and then pass that as a variable to the script when I run it as a Shell Path button in Companion.
This could also be used for quickly glancing at a device's IP on a button, or passing it to some other connection so they can communicate directly.
I am considering saying that this is something that should be implemented by each module.
The reason being that modules define what the config fields look like, so that ip address field may is often called ip, host or address, but could also be something completely different or they may not even have one because they talk to a cloud service. So while we may capture the correct value for 90% of the modules, I think it will be rather brittle and will end up with a bunch of edge cases to handle certain modules being weird. Perhaps a module is using ip to define a default input or something unrelated. Or if they have an ip and a host field, which should we use?
I think the only way we could do this cleanly would be to expose every config field of a module as a variable, but I am not convinced that is a good idea as that will 'leak' any secret config fields as variables. It is not uncommon for there to be usernames & passwords in the config, and once we have proper authentication do we really want to be forcefully exposing these secrets to anyone who can access the variables? (access to variables may not always be behind authentication)
This isn't a no, but some thought is needed on how to approach this before deciding.
I am not sure if specific modules have already implemented something like this. In the meantime, I'll open an issue on the ATEM's module page, since this is what I need for my use case. Thanks.
Just as a follow up, it looks like the ATEM module has this under variables. $(atem:device_ip)
I like the concept of the module making sure they integrate the IP feature into the module itself, however, doesn't companion require modules to establish the ip address when editing the connection? Couldn't that be used to establish a variable?
This is quite funny, the ATEM just implemented that function because of the issue I opened four months ago, in reference to this issue 😂
In regards to it being universal, I understand the concerns about not exposing every field. The use case was to be able to pass the IP to other non-related modules or actions that might need it. I can’t think of a use case where a username or password would be necessary, but if there’s a limitation in the companion core that means it isn’t able to target only the IP, I understand the onus being on the individual modules to expose it.