Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix Philips Hue and clean up code #2109

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Massimo53
Copy link
Contributor

Philips Hue was not working, or sometimes would only work for a single light. This refactors the update cycle to correctly handle Philips Hue API calls. Tested with 5 lights and a variety of colors/effects, played for 7 hours and worked well (as well as Hue can, that is - it certainly isn't DMX). Cleaned up old code and debugging comments/logs.

Separated from my voice fix PR so daid can decide whether to include it or not.

Philips Hue was not working, or sometimes would only work for a single light. This refactors the update cycle to correctly handle Philips Hue API calls. Tested with 5 lights and a variety of colors/effects, played for 7 hours and worked well (as well as Hue can, that is - it certainly isn't DMX). Cleaned up old code and debugging comments/logs.
auto resp = setLights.request("PUT", APIEndpoint, postData);
if (resp.status == 200) // OK
{
lights[n].dirty = false;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By moving this here, and removing the lock, you created a race condition, which is likely why you needed the 2nd dirty check construct.


if (lights[n].dirty)
{
sp::io::http::Request setLights(ip_address, port);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tabs vs spaces. Please use 4 spaces instead of tabs.


if (lights[n].dirty)
{
sp::io::http::Request setLights(ip_address, port);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By re-creating the sp::io::http::Request for each call, it makes a new tcp connection per call. If you reuse the same object it should keep a single connection open, which is better for performance.

Did you run into some kind of bug why you needed to move this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is actually what sent me down this whole rabbit hole... it would sometimes work for the first light, but not additional lights. Wireshark packet captures showed that after the first light call, it would malform all the subsequent calls, putting the json payload before the api call. Like:

{"on":true, "sat":254, "bri":254,"hue":19660, "transitiontime": 1}put /api//lights/3/state

instead of (when Wireshark capturing Postman):
PUT /api//lights/2/state HTTP/1.1
Content-Type: application/json
User-Agent: PostmanRuntime/7.38.0
Accept: /
Postman-Token: 7780f271-cf4f-40c3-8bd4-220a074b80ba
Host: 192.168.1.104
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 45

{"on": true, "bri": 254, "transitiontime": 1}

So I pulled it out to make a separate connection each time and that did the trick, no more malformed API packets after that. I'm not sure why that is the case, I was on a bit of a time crunch when I was working on it (had a game scheduled) so I was certainly in "just make it work" mode.

I don't know how many people even use the Hue feature, I just happen to already have them in my game space so might as well. I'll tinker with and clean it up some more but I can't promise any kind of timeline for it, so feel free to reject for now if you'd like and I can open a new PR if I make it any better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants