Allow setting specific states / getting current status to allow integration into OctoApp (automatic lights)

[AB-274]

Hi, OctoApp supports activating lights via supported plugins in case the webcam is activated inside the app automatically. According to this link OctoHue is currently nut supported because it's not possible to set specific states (only toggle is possible) or to retreive the current status of the light.

It would be great to be able to use OctoHue in this context by adding those functionalities. Thanks in advance!

[crysxd]

OctoApp dev here, I'm happy to assist on this change.

All that needs to happen is to add 2 API commands for get_state and set_state:

• https://github.com/entrippy/OctoPrint-OctoHue/blob/fff104daa3854b270ab5a68490d20c1b2fe403d1/octoprint_octohue/__init__.py#L120
• https://github.com/entrippy/OctoPrint-OctoHue/blob/fff104daa3854b270ab5a68490d20c1b2fe403d1/octoprint_octohue/__init__.py#L126

[entrippy]

I'm trying to fix an irritating bug from way back that prevents users from removing/modifying the default states. As soon as thats done I'm happy to get this done.

Sorry for being gone so long (years).

Sit tight

[entrippy]

ok, saving settings bug fixed in 0.4.4 (be warned, you either need to remove statusDict from config.yaml or do a reinstall of octohue including a settings clean up due to a change in how settings are persisted.

I can now open a branch to look at this enhancement

[entrippy]

@AB-274 @crysxd , can you give me a little more details on how this would work ideally, Octohue currently tells a light to transition to a state (colour, brightness, off etc) when an event occurs (toggle, connected, insert octohue event here).

there is a fair bit of maths for converting rgb into the xy data needed for the lights that goes into build_state that if i just exposes set_state you'd need to replicate on your end. the code is there if desired though.

Would you prefer to duplicate the logic and just set the state, or would "octoapp" support in octohue be preferred.

[crysxd]

@entrippy There is really not a lot required, OctoApp doesn't support RGB values but only a simple on/off state.

I'd need a getstate commands available over HTTP in addition to togglehue which returns something like {"on": false}. OctoApp offers "turn on", "turn off", and "toggle" as commands (in addition to the automatic webcam control). Having the gestate is already enough to make everything work because OctoApp can query the current state, if the light is supposed to be on and already on, nothing is done. If it's supposed to be on but off, I can use togglehue to toggle the state.

If you'd also offer a dedicated turnon and turnoff commands that have this logic on the plugin side....that would save one extra request but I don't think this is essential.

[entrippy]

@crysxd am releasing 0.6.0 with : getstate - returns ("on": true|false) turnon - optional "colour" parameter accepting the hex code for a desired colour e.g #FF0000 for red turnoff - turns off.

Not essential, but if you do add a feature, a small plug for the plugin would be appreciated, but not required :)

[crysxd]

Added for today's update, thanks! (1.17.133 if anyone watches this ticket :D)

OctoHue 0.5.0	OctoHue 0.6.0

[AB-274]

Thank you both, @crysxd and @entrippy! Really looking forward for 1.17.133 beeing available on Google Play (1.17.132 currently showing up as latest). Love the automatic light option...

[crysxd]

@AB-274 The update was rejected due to WearOS "compliancy" issues. Will take me a few days to resolve.....

[entrippy]

@AB-274 @crysxd , I'm on a local dev install at home and it doesn't appear to detect that octohue is installed. Definitely a me problem.

But I was hoping that either of you could confirm that this is all working as intended so I can close this issue out as done if so?

[crysxd]

I don't have a Hue bridge unfortunately. But I do have unit tests for the entire API of OctoHue....so I'd be surprised if it would not be working.

Would still be great if @AB-274 or another user with OctoApp and OctoHue could confirm!

@entrippy would suggest closing the ticket in 7 or 14 days regardless of feedback – in case something doesn't work we can reopen it. Most likely it would also be an issue on my side :D

[entrippy]

@crysxd , all good. And good tip. I've managed to test this myself So I'm closing this one off now. Thanks for all your help