Closed ghost closed 2 years ago
We need to discuss this internally on how to proceed. Main goal would still be to support as many devices as possible. Implementing this would encourage users to use this module instead of creating a new one. Regarding to the Bounty I know the person who posted it, so I'm sure we can work it out to split it according to work. Further on I see @Julusian has self assigned, so there will be a good solution for this.
Note for myself (Ember+ is a bit the same)
@abebeos some modules are created for a bounty most are made in free time. Regarding to bitfocus-companion; there is a rewrite going on for that by the core team. No bounties for that, in the past we did some if there was an issue we could not solve. If you would like to help growing Companion and make the product better, please let us know, of course contribution on modules is already very helpful. I'll close this issue and see if I can merge your pull-request. If all ok and with no further comment I'll give Austin a go for the bounty
@abebeos thanks for your work, I've had no time to test but the code looks good. I'll let Austin know
@abebeos it would be good to discuss this further on slack. Are you on slack? You can find the link in the software.
I noticed that rewrites are ongoing since 2 years.
Kind of, but we decided to do it post 2.2. And then we started fresh with it the other week. The other work was abandoned prototyping, so not entirely relevant
Is there an example of how this can be leveraged or used? I have an application that I can query its REST API for state of a given feature being enabled or disabled, and I would like Companion to set a custom variable to that value, which then in turn I could use said value to set button text, background color, etc. via feedback.
When it is posible to use variables in a text box just copy paste the variable you want to use where you want to use it
(subjects issue #24. Text here is updated during ongoing work.)
Requirements
generic-http
UI, see commentTasks
NO VARIABLE
selectionsSolution Path
My RA so far (= non-code work result) leads to this:
http module
http GET
action with a custom-variable drop-down fieldThen:
internal module
fulfilled within: https://github.com/bitfocus/companion-module-bitfocus-companion/pull/50
JSONPath query should possibly happen at this location (core code): https://github.com/bitfocus/companion-module-bitfocus-companion/blob/fcaedc0b857b3d42377b7dfb60ca1126522b1628/index.js#L786
This solution path should provide high flexibility (including prototyping etc.) whilst providing full backwards-compatibility and good maintainability, as there is not much new core code.
Follow-up Tasks
@JeffreyDavidsz , @Julusian , @estilles, @haakonnessjoen
$2.500 bounty
There is a bounty on this issue #24, see
(https://app.bountysource.com/issues/105114232-add-the-ability-ability-to-set-custom-variable-values-with-an-http-request).
I started work on this a week ago and planned to deliver until 15th Feb. My current (unpublished) result is similar to this within #25 (by @mertmit, another bounty-worker, independent of me).
See above for my work-progress
Core Team Matter
During my in-parallel implementation-work and further requirements-analysis, I get more and more the feeling that providing this new generic functionality to the
generic http module
is something that the core-developers should do, simply because it can be implemented in different ways (and places), which would affect the overall usability of the companion product.Please verify if any of the core-developers would like to do the work and claim the bounty.
Though I've invested already many time (mostly Companion work-in) and a bit money, too (should receive my Streamdeck today), I would back-off from the bounty and leave it to a core-team-member.
If no team-member wants to claim the bounty, I would continue my work.