Cannot get the lights to change

[tomhah]

First of all, awesome work on this!

But my lights won't seem to change. I've tried the basic example and everything seems to work, apart from my lights actually changing color 🙁

Am I the only one with problems? Any tips?

[JakeBednard]

Thanks tomhah! I'm assuming your using the basic example as is, so it should be set to go (should just need to set the IP and groupId). I'm wondering if the socket is failing to stay open. In #3, I pulled the "Socket Closed" exception as it really shouldn't throw during a normal close. The issue occurs when the socket closes unexpectedly and doesn't alert to the frontend (hence everything looks fine, but the socket's actually closed). I'm regretting removing log4js from the library now as it was a clean way to debug. I might have to reimplement so we can pin down these issues.

I'm not saying the above is it, as theres an array of other possibilities. Like is the group you're using an entertainment group? Is your firmware the correct version? etc.

If you feel comfortable, feel free to clone the library and throw a few console statements in "phea-engine.ts" and and recompile. This might be the fastest route until I have some time in the upcoming weekend to attach logging again.

--Jake

[tomhah]

Thanks for a quick reply! The group I'm using is definitely an entertainment group, I've tried two different entertainment groups with different lights too. The bridge config gives me "apiversion": "1.34.0", and entertainment works fine in the Philips Hue Sync app for desktop. It even tells me that my app is syncing with the entertainment room when I'm running the script. (I have also tried closing the Sync app)

I logged out the lights in the phea-engine, and it does look like the lights there is updating with the correct RGB values.

So everything seems correct, the lights just won't change 😄

I'll try to dig a bit more :)

[JakeBednard]

No problem. Everything sounds fine on your end. I really think the socket is the culprit here. I'd need to verify, but I think streaming goes active when the HTTP request is made to the bridge to enable DTLS streaming. That HTTP request flips the state, but it doesn't mean that the socket has connected. You may also want to try increasing the dtlsTimeout option to 3000 or so to see if the socket creation may be racing (seen this happen a few times in the past, but I thought it would throw a socket error). Keep me posted if you find a fix and we'll work on merging it in. :)

[JakeBednard]

I'm not on my dev box currently, but the following is a CURL command to enable DTLS streaming for a group over the HTTP API. If you have CURL installed, run the following and see if your app says that entertainment mode is active for about 10 seconds or so after you run the command. We can use this show that the socket isn't responsible for changing that state within the app.

curl -d '{"stream": {"active": true}}' -H "Content-Type: application/json" -X PUT http://<your_bridge_ip>/api/<your_username>/groups/<group_id>

[tomhah]

Thank you so much for helping me! 😄

Running that command gave me same message in the hue sync app.

I've tried logging out messages, errors, close and connected events from the socket. It does successfully connect, I receive no errors or close and no messages.

It does seem to fire off messages as well, by logging out the values before the the this.socket.send in phea-engine.

Increasing the timeout made no difference 🙁

[JakeBednard]

Interesting. Can you output the buffer that is being sent? I'll take a look if you can pass on the hex. If the socket is open (I need to track this better), then if the message is correct is should fly.

[tomhah]

This? <Buffer 48 75 65 53 74 72 65 61 6d 01 00 00 00 00 00 00 00 00 01 e2 e2 64 64 dc dc 00 00 02 e2 e2 64 64 dc dc> 🙈 I'm on deep water now

This is a msg.toJSON(): (They're not from the same message)

msg {
  type: 'Buffer',
  data: [
    72, 117, 101, 83, 116, 114, 101, 97, 109,
     1,   0,   0,  0,   0,   0,   0,  0,   0,
     1, 153, 153, 93,  93,  80,  80,  0,   0,
     2, 153, 153, 93,  93,  80,  80
  ]
}

[JakeBednard]

Thanks, message looks correct assuming your using 2 lights (verify the below):

48 H 75 u 65 e 53 S 74 t 72 r 65 e 61 a 6d m 01 Major Version 00 Minor Version 00 Sequence Number (not used) 00 Reserved 00 Reserved 00 Color Mode RGB 00 Reserved 00 Type: Light 00 Light ID-A 0x00 (Light ID is 16-bits so add the line below) 01 Light ID-B 0x01 (so 0x0000 + 0x01 = 0x01. By chance are your light ids greater than 255?) e2 R-A (colors are 16 bit) e2 R-B 64 G-A 64 G-B dc B-A dc B-B 00 Type: Light 00 Light ID-A 0x0000 02 Light ID-B 0x02 (0x0002) e2 R e2 R 64 G 64 G dc B dc B

---

So it has to be the socket. It appears everything else is correct. Still processing next steps in my head here.

Edit: [Note to self] This limitation of light id's above 255 should be fixed. I don't think Hue supports them yet, but it's simple enough.

[tomhah]

Two lights is correct :-)

I think the light ID's are 8 and 9:

{
    "name": "Entertainment area 2",
    "lights": [
        "9",
        "8"
    ],
    "sensors": [],
    "type": "Entertainment",
    "state": {
        "all_on": true,
        "any_on": true
    },
    "recycle": false,
    "class": "TV",
    "stream": {
        "proxymode": "auto",
        "proxynode": "/bridge",
        "active": true,
        "owner": ***
    },
        ...
}

[JakeBednard]

Woot. You nailed the issue. :)

The code assumes that you're going to be always starting with id "1" then sequentially to numOfLights. I'll have to make a commit to get this behavior fixed. Let me take a peak to see what it's going to take.

[tomhah]

Haha, I was just going to comment, that when logging out the lights inside Phea, they seem to have ID 1 and 2.

Thanks man! It's 03:45 here, but I am sooo looking forward to play with this! 😄 Going to integrate it with a racing simulator 🙂

[JakeBednard]

Great idea, I'm looking forward to seeing it. I'm going to take the stab at the bug tonight. I think it should be a minor change, Essentially, the current method to create the light object takes the number of lights and assumes the ID is sequential. So instead of passing in a light count, I'll have to pass in the array of light id's from the bridge API (which is already fetched to get light count). Give me 24 hours or so to get this pushed to git/npm. It shouldn't take along (but buffer room :) ). Take care, I'll let you know when it's pushed.

[tomhah]

Thanks man! You're my hero! 😄 Looking at the code I think I'll be able to put something temporary up, so I can have something to play with in the meantime!

Thanks for super quick responses and fixes! 🎈

[JakeBednard]

Hey. Fix is inbound. I want you to test it if you're awake.

[tomhah]

I'm awake and ready 🙂 Will test now

[JakeBednard]

Just pushed 1.0.4. Give it a try.

[JakeBednard]

I'm curious to see if this causes any side-effects. Everything seems to be working fine on my end. I'll likely have to clean things up a bit next refactor session, but I believe this patch should solve things.

[tomhah]

Woooop, it works! 🍾 🎈 Thank you soooooo much!

[JakeBednard]

No problem Tomhah. Let me know how it goes (Open issues, good or bad. It'll allow us to follow progress on stability). I appreciate you using the library. Its the only way we can pin down the edge cases I missed :). Take care.