Shorcut/alias for HTTP Remote Control

[mark-epstein]

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

First I apologize if this is already requested. I couldn't find it.

I would like to see alias HTTP controls, for example:
instead of /press/bank/page/bank
I'd like this: /press/startNuclearReactor
(and somewhere else I'd configure what page/bank startNuclearReactor resolves to)

Usecases

/press/bank/page/bank has several shortcomings:

1. the system sending that HTTP command has no obvious indication of what the command will do, and it might be easy for them to mix up the commands to stop, rather than start, the nuclear reactor.
2. if I want to move buttons around on Companion, I have to track down and adjust all the possible places that someone/something might be controlling it

This would solve both of those

[Julusian]

Half of this is a duplicate of #1676, but it sounds like you want to be the one to define the 'ids' used, so this is a bit different

[mark-epstein]

I agree! I didn't find that in my search. And yes ideally I'd like to be able to able to specify the IDs. But if you were only able to do 1676, someone like me with basic web skills could make their own web app on the Companion host could redirect "friendly" requests to more obscure IDs.

…

On Mon, Oct 3, 2022, 13:50 Julian Waller ***@***.***> wrote: Half of this is a duplicate of #1676 <#1676>, but it sounds like you want to be the one to define the 'ids' used, so this is a bit different — Reply to this email directly, view it on GitHub <#2138 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATEBQIECZMBL2ERIRNOSWTLWBMMFVANCNFSM6AAAAAAQ3EP6L4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Julusian]

I think this could be done before #1676, by giving the buttons a section to define 'aliases'.

New api endpoints could then be added to do things to buttons by the alias.
It would also make sense to duplicate some of the internal press/release actions to be able to reference an alias too.

Then as part of #1676, I would question whether we should expose the buttons at all by their internal ids, or if we should require buttons be 'exposed' to the apis by giving them an alias. This falls into some other ideas I have on rethinking the apis, and providing some kind of security in them.

[mark-epstein]

I also want to point out how useful this would also be in the log. Button 9.1 is a lot less meaningful when digging through the log than, for example, Button lighting-recall-preset-1

[Julusian]

I was going to make a start on this the other day, but I quickly realised that most of the complexity here is the ui to specify the alias.

The button editing panel is already pretty long. Should this be a new section at the bottom or top?
Called 'remote triggering' or something else? I will also be making alternate press button internal actions to allow referencing by this alias.
It is worth considering that perhaps we should allow for defining access controls for this alias, so that it is only valid for one of the protocols or internally. Maybe that should go here, or maybe that would be better off elsewhere.
It should probably be possible to assign more than 1 aliases to a button.

Some other things to think about:
should we allow the same alias to be used on multiple buttons at once? that could be a useful way to group them. it would be simpler to allow this, but harder to them remove it later.
perhaps each alias should have an enabled switch, so you can temporarily disable it

[mark-epstein]

Giving it more thought myself, I'd say the buttons I want to trigger (or have other buttons press) are < 10% of my total buttons, so if I'm average (which I can't know) then a separate page is probably the way to go. I personally would be very happy with a new page that listed two columns: alias name on the left, button bank/number on the right, and had an enable checkbox for each. Using a series of checkboxes, you could allow/disallow each alias on a per-protocol basis. If you can have a many to many relationship between aliases and buttons as I think you are suggesting, that would seemingly be the most versatile. Is there any risk of getting into some kind of endless loop by implementing this? I don't need the answer, just something that crossed my mind.

…

On Fri, Oct 21, 2022 at 3:00 PM Julian Waller ***@***.***> wrote: I was going to make a start on this the other day, but I quickly realised that most of the complexity here is the ui to specify the alias. The button editing panel is already pretty long. Should this be a new section at the bottom or top? Called 'remote triggering' or something else? I will also be making alternate press button internal actions to allow referencing by this alias. It is worth considering that perhaps we should allow for defining access controls for this alias, so that it is only valid for one of the protocols or internally. Maybe that should go here, or maybe that would be better off elsewhere. It should probably be possible to assign more than 1 aliases to a button. Some other things to think about: should we allow the same alias to be used on multiple buttons at once? that could be a useful way to group them. it would be simpler to allow this, but harder to them remove it later. perhaps each alias should have an enabled switch, so you can temporarily disable it — Reply to this email directly, view it on GitHub <#2138 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATEBQIB5UQ6T3BDR6W52MA3WELR5FANCNFSM6AAAAAAQ3EP6L4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Julusian]

Giving it more thought myself, I'd say the buttons I want to trigger (or
have other buttons press) are < 10% of my total buttons, so if I'm average
(which I can't know) then a separate page is probably the way to go.

I dont think a separate page is the way to go for now. Eventually it will be for some advanced configuration or seeing what aliases are used where, but I dont think it should be the first step.
My reason being that its by looking at the button edit panel that I will know what alias I want to give to a button. If its on another page, we likely wont be able to give any button names or anything, so youll have a list of:

• do something - 1.13
• do something else 1.12
  Looking at that list, can you tell that I got those inverted? or that 1.12 was just deleted? or I reconfigured the button, not realising it had an alias assigned.

The alias will internally live right next to the button style/actions/feedbacks and things, so it really does make sense to display it there too.

Is there any risk of getting into some kind of endless loop by implementing
this? I don't need the answer, just something that crossed my mind.

Probably. but no more risk than with the current internal actions or triggers.