WIP: Multi light support

[cozybuild]

TODO:

• Fix pre-selection of saved IP
• Improve global events to trigger changes by device/ip to update only related actions (follow up: Backend - Upgrade plugin with latest StreamController.EventManager support #10 )

[istathar]

anything I can do to help?

[cozybuild]

Thanks, I think I can find some time next weekend to continue this. Then I would appreciate your help with testing

[Cfomodz]

Happy to help if needed 😃
Just ran into the changing the IP in 1 action changes the IP in all actions and was about to write some hack before finding out this was already mostly done it sounds.

[mathias-ewald]

Waiting for this eagerly :D If you need help, let me know. I just don't want to spend time on it that might just get merged as is tomorrow :D

[DavidVallaLope]

Hi there! I was testing the current work. So far the functionality works without major issue. I noticed that there are some settings overlap when changing one light configuration. This is originating from reading from the settings where the brightness, temperature and status of the light is saved "globally" instead per device.

{
    "file-version": "2.0",
    "settings": {
        "light_active": 0,
        "brightness": 21,
        "temperature": 236
    }
}

Does the settings allow to store config based on the IP/Device name? Something like this:

{
    "file-version": "2.0",
    "settings": {
        "10.0.0.1": {
            "device_name:": "KeyLight 1"
            "light_active": 0,
            "brightness": 21,
            "temperature": 236
        },
        "10.0.0.2": {
            "device_name:": "KeyLight 2"
            "light_active": 0,
            "brightness": 22,
            "temperature": 156
        }
    }
}

That way we can store device wise configuration without affecting other devices configuration

Edit: I just have checked the Singleton implementation to get the current configuration from the Keylight API. Then, is it possible to have the IP assigned over each knob?

[DavidVallaLope]

I believe if we switch from the Plugin_base configuration to action_base configuration we can achieve individual IP per action? Will try to implement it and push over here so it can be tested

[DavidVallaLope]

Hi there, I was able to implement the get_data_from_light method and use it to fetch and update the data of each light individually:

(Right now works for toggle and Brightness control)
So far the IP is stored per Dial and that allows to control each Light individually. Right now there is a race issue where if rotating the Dial is too fast, the request to update the brightness/temperature get overwritten with previous values.

I tried pushing the commits under the same branch so they can be tested but seems that I don't have access to modify the repository, therefore I have forked the project so you guys can review it

https://github.com/DavidVallaLope/StreamControllerElgatoKeyLight

[cozybuild]

Amazing, time flies, thank you very much for this. You should have an invite for accessing this repo

[DavidVallaLope]

Perfect, now changes should be on this repository. I will add through the day the remaining functionality for the Dial and check on the race thing with the requests.

For testing purposes, what works right now is the Dial Brightness and Toggle so if anybody wants to test it, please do

[DavidVallaLope]

I have added the temperature control and as well added the current_status properties to avoid calling the get_data_light method every time an update is needed.
Right now I see certain options to start optimizing the API calls to avoid the race situation with the Dial Requests.
On Toggle action for buttons I can see that the event request (GET) 3 times (to retrieve current configuration, which can be definitely optimized) and 1 (PUT) request to finally update the status of the light.
I can see the same behavior on Dial Rotation events.

On the other hand, I observed than on Dial Push the requests are pilling up. A lot of GET request and even 3 PUT requests (which have the same information). This could affect performance as well.

I will check that on tomorrow and as well to implement the Icon Update with the current_status class property (as we are not using local settings anymore)

Please feel free to test the changes and let me know anything you find

[DavidVallaLope]

I'm back with good news! I was able to reduce the requests per execution, which increased the performance on the Dials actions. I tried implementing a thread lock mechanism but it was not necessary after removing the unnecessary request being made. There are some occasions that requests get trapped and sent in bulk but the updates happens anyway.

As well included the original Temperature values from the Control Center software.

Currently there is a bug that was introduced with the change of how the updates were done in the Keylight, each type of Action acquires a different type of data for the current status of the keylight, which means that on press, it will affect the current configuration of the brightness, temperature or status. This happens due to how StreamController handles the objects assigned to each key and how we are handling the cached json value (object wise and not class wise), if we try to change it class wise it will affect others light configuration so we need to find a way to have one cached json for each IP regardless of which object is accessing for it

As well this bug overwrites the current configuration every time StreamController is restarted.

Will work on the bug after work, hopefully is something easy like implementing getter/setter or change the approach of cache configuration.

The issue with the icons is still happening, will try to check into that once the status bug is solved

Feel free to test the new changes

[DavidVallaLope]

Getting back into this before I lost this idea, I would write a REDIS based cache logic to store the current settings for all the buttons for specific IP. This should be faster than reading through a file and we would still be able to use the current implementation without affecting multiple lights at once. Will commit the implementation once done.
The previous approach wont work without a Redis server which is not possible.

If anyone has another idea please let us know so we can include that in the design for the json data manipulation

[DavidVallaLope]

Ended up adding a data dictionary with each IP associated to store locally all configurations making the gets and puts faster, right now almost all the interactions with the Dial feels really smoothly. So far only affected actions are: Toggle and Dial Brightness and Temperature. Tomorrow will add for the remaining 2 actions and call it a day

I notice a bug related to the IP's list where sometimes the action will take the first available IP instead of the stored one. We might need to refactor to take the dial settings IP and avoid the overwriting. Other than that I havent found any other bug related to implementation

TODO

• Add the request based settings to Increase/Decrease and Set Properties actions
• Fix the icons update process
• Fix the IP overlapping for actions
• Clean functions and unused code

Please let me know your thoughts and please test out the changes and let us know the bugs you find

CC. @cozybuild

[istathar]

I'd be happy to try testing this, but I'd probably need instructions of how to run this from a checkout as opposed to however the main app pulls in plugins.

[DavidVallaLope]

Hi @istathar! Thx for checking into this, in order to test the plugin you will have to do the following steps (you need to know the data folder of the StreamController, you can get that information going into StreamController > Open Settings > Developer > Data path, I will refer to this data path as $SC_DIR).

1. Uninstall the Control Center plugin (if you have it installed) through the store.
2. git clone the current repository into $SC_DIR/plugins (a folder named StreamControllerElGatoKeylight should be created)
3. cd StreamControllerElGatoKeylight
4. Run git checkout multi-light-support to switch to the current branch
5. Restart StreamController

After that you should get all the changes made on this branch

[DavidVallaLope]

Hi!
A quick update on this, the race situation referred on #7 was solved by changing the way method update_icon() was being invoked each time the update happened, now it is launching an Event() that calls the update_icon() for every child of class Core()

As per the IP functionality, seems intermittent to me, but there are times where the IP on the second device gets overwritten to the IP of the first device when trying to set up an action. Seems to me to be just a visual bug since its not affecting functionality but we will need to test more

[DavidVallaLope]

As of know I believe only code cleaning is necessary. If somebody test this and finds a bug please let me know

[cozybuild]

Thank you so much for all of your amazing work @DavidVallaLope! Really good stuff! I only have an issue (which is not really plugin-related) with the pre-selection of entries.

1. Have one light in the list
2. Create a new button action
3. The existing device is in the list and looks like it's selected, but the value is not used (button doesn't work)

So you have to select another entry in the list and switch back to the original entry. Can you reproduce the issue?
And the icon for the button is missing. Dial controller is fine.

[mike3nl]

Hi @cozybuild and @DavidVallaLope
Any news about this plugin?
I ask because i have three lights now and it would be amazing to get it running.

Amazing work until now.

[caesarakalaeii]

Thanks for merging my PR 💐
I've been using that version for quite some time now with two lights and haven't seen any issues, so I'd regard it safe. Anything you'd want changed before hand?

[cozybuild]

Perfect, thanks for testing! I'm rarely on my Linux streaming environment at the moment, sorry about that. But I'll boot into it this week, merge it, and build a new version.