New error after updating bridge software about node-hue-api HOT 25 CLOSED

There is nothing in the update that appears to have broken any of the tests that I have for my bridge. I am running the latest update which is version 1.7.0. Can you please confirm your software version?

I took a copy of your code (there are some missing pieces for the lsNotify and lsNotify2 states, but I substituted something in my testing that allowed me to run it.

One thing that I did notice was that I managed to generate an error, but not a 404, that was to do with the hue value attempting to be set on a light bulb that was in the off state.

Can you provide me with more details so that I can try to reproduce it.

Thanks,

from node-hue-api.

Thanks Peter, I just left for a week's travel this morning - will follow up upon my return.

Chris

from node-hue-api.

Hello Peter,

Here's what I have for my version:

C:\jobs>npm install node-hue-api
[email protected] node_modules\node-hue-api
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected] ([email protected])

C:\jobs>npm update node-hue-api

C:\jobs>

Also my npm ls shows this:

─┬ [email protected]
 ├── [email protected]
 ├── [email protected]
 ├── [email protected]
 ├── [email protected]
 └─┬ [email protected]
   └── [email protected]

Here are my lsNotify and lsNotify2 variables.

var lsNotify = lightState.create().on().hsl(290, 100, 100);
var lsNotify2 = lightState.create().on().hsl(230, 100, 100);

from node-hue-api.

A little more information, when it throws the error, I'm emitting the error message and the light and state passed to setLightState:

param 1 - '4'
param 2 - { on: true,
bri: 254,
hue: 14910,
sat: 144,
effect: 'none',
xy: [ 0.4596, 0.4105 ],
ct: 369,
alert: 'none',
colormode: 'ct',
reachable: true }

then the error: Api Error: Internal error, 404

from node-hue-api.

Thanks for the extra information, I will take a look into this tonight and hopefully get to the bottom of the error.

Could you possibly provide me with the software and firmware versions of the bridge itself, as that will reveal any differences between your bridge and what I am testing on. You can use the api.getConfig() function to get this, or use the hue iOS or Android application.

Thanks,

from node-hue-api.

Sure, here it is:

{
  "name": "Bridge 1",
  "zigbeechannel": 11,
  "mac": "00:17:88:15:c5:de",
  "dhcp": true,
  "ipaddress": "192.168.1.42",
  "netmask": "255.255.255.0",
  "gateway": "192.168.1.1",
  "proxyaddress": "none",
  "proxyport": 0,
  "UTC": "2015-06-18T14:00:12",
  "localtime": "2015-06-18T10:00:12",
  "timezone": "America/New_York",
  "whitelist": {
    "eTJpTZbCNWf5EISl": {
      "last use date": "2015-06-18T14:00:12",
      "create date": "2014-03-30T03:06:39",
      "name": "philips.lighting.hue#iPhone3"
    },
    "356fabf32a56334f3256eeb262e7ac7": {
      "last use date": "2015-06-18T05:36:55",
      "create date": "2014-03-30T03:09:42",
      "name": "SharpHue"
    },
    "000000007d0d31b60540928905409289": {
      "last use date": "2014-11-09T04:51:10",
      "create date": "2014-05-03T03:10:40",
      "name": "PhilipsHueAndroidApp#Samsung SCH-I535"
    },
    "PRDDefzO5KydtWqZ": {
      "last use date": "2014-06-29T04:29:54",
      "create date": "2014-05-22T01:59:04",
      "name": "iPhone3"
    }
  },
  "swversion": "01023599",
  "apiversion": "1.7.0",
  "swupdate": {
    "updatestate": 0,
    "checkforupdate": false,
    "devicetypes": {
      "bridge": false,
      "lights": [],
      "sensors": []
    },
    "url": "",
    "text": "",
    "notify": true
  },
  "linkbutton": false,
  "portalservices": true,
  "portalconnection": "connected",
  "portalstate": {
    "signedon": true,
    "incoming": true,
    "outgoing": true,
    "communication": "disconnected"
  }
}

from node-hue-api.

Ok, I made some progress in investigating this. The errors are surfacing on the restoration of the state(s) of the lights for me.

I am getting the message Internal Error 404, and on looking at the code in a debugger, the type of error is 901 which according to the bridge API documentation; "This will be returned if there is an internal error in the processing of the command. This indicates an error in the bridge, not in the message being sent."

I have not managed to determine the exact conditions for this, and have only managed to reproduce this error when I have a mixture of Hue Lux and Hue Bulbs in a Group or Hue GU10 and normal Hue light bulbs in a Group.

If I use a group with just normal Hue light bulbs, then the error is not created and the code completes.

Could you please confirm the types of bulbs you have in the group that you are running this on? Are the all the same type of bulb, or a mixture?

from node-hue-api.

Hi Peter,

They're all BR30 bulbs for me. The thing that stands out in my mind is that this same code worked for months until I did a particular Hue upgrade.

I try to grab current bulb state, cycle a few color changes, then return to the previous state. I suspect it is the return to previous state where the error occurs?

Thanks
Chris

from node-hue-api.

Ahh, if I'd read your message more thoroughly, I would have seen that you already noted that the error is occurring at the point of returning to prior light state.

from node-hue-api.

The problem appears to be coming from the "extra" data that you are capturing from the light states at the beginning.

After removing the effect and alert states from all the initial light states that you capture in the code, I cannot get the bridge to error, irrespective of the bulb combinations that I have in a group.

I suspect that the bridge itself has some quirky state or validation checking when you set an alert and/or effect modes, which is causing it to be slow to process the incoming requests (as it is the bridge that is having issues here, as it is generating the 901 type error).

I have tested this against the 1.7.0 apiversion and the latest update 1.8.0 apiversion that Phillips have just released for the bridge.

from node-hue-api.

Thanks Peter, this makes sense - I'll remove those and see how it goes.

from node-hue-api.

Setting both of those states to "none" when capturing current light state seems to take care of the issue for me. Thanks Peter!

from node-hue-api.

Hello Peter,

I spoke too soon - as I looked at my logs, I see this problem continuing. Thankfully, I'd forgotten and left code in place to dump out the light state that I was attempting to set when an error occurred. Here are three consecutive light states that produced an error. Let me know if you see anything that would be a definite cause of the setLightState() error.

'2'
{ on: true,
bri: 254,
hue: 16074,
sat: 69,
effect: 'none',
xy: [ 0.4151, 0.3953 ],
ct: 299,
alert: 'none',
colormode: 'xy',
reachable: true }
Jun 29 2015 21:21:10: Error changing lightstate : Api Error: Internal error, 404

'3'
{ on: true,
bri: 254,
hue: 52225,
sat: 253,
effect: 'none',
xy: [ 0.3084, 0.1193 ],
ct: 153,
alert: 'none',
colormode: 'xy',
reachable: true }
Jun 29 2015 21:21:10: Error changing lightstate : Api Error: Internal error, 404

'4'
{ on: true,
bri: 254,
hue: 47126,
sat: 253,
effect: 'none',
xy: [ 0.1684, 0.0417 ],
ct: 500,
alert: 'none',
colormode: 'xy',
reachable: true }
Jun 29 2015 21:21:10: Error changing lightstate : Api Error: Internal error, 404

from node-hue-api.

Please remove the alert and effect values from the states you are trying to set, that should stop the error from occurring. That is, do not set them to anything at all. Use the 'delete' keyword on the object to remove them.

What is happening is that the bridge seems to be triggering some logic that generates this error when you set these with other values (it's the actual bridge failing here, not the library). Even though the values are to disable an alert and effect, it still seems to trigger this failure to respond correctly from the bridge.

In reality setting these values to none will only stop whatever process you have already got running, e.g. a current alert. In your case though, setting a light state to an actual state of colour/hue/brightness etc would cancel any effect or alert if currently running anyway.

from node-hue-api.

Hi Peter,

Gave that a shot. Here's the error occurring with those two properties removed.

'4'
{ on: true,
  bri: 254,
  hue: 51478,
  sat: 254,
  xy: [ 0.2876, 0.1069 ],
  ct: 153,
  colormode: 'hs',
  reachable: true }
Jun 30 2015 21:47:52: Error changing lightstate : Api Error: Internal error, 404

from node-hue-api.

I think the bridge is still being overloaded with requests in your case. I cannot reproduce this any more when I strip out the alert and effect parameters using the code you gave me.

You could try rebooting the bridge and see if that helps, I can occasionally get it into a bad state when testing.

The other thing that you need to consider here is that setting all the values for the light state is not actually practical. The lights work in a priority of ordering if you attempt to set all the values as you are doing. This snippit from the Hue API documentation makes it clearer;

There are 3 methods available to set the color of the light – hue and saturation (hs), xy or color temperature (ct). If multiple methods are used then a priority is used: xy > ct > hs. All included parameters will be updated but the ‘colormode’ will be set using the priority system.

The colormode value indicates which of the three states (if the light supports it) that the light was in. I would suggest that instead of setting all the values, as in currently the case, you check that the light is on/off, if off, you just send that. If on, then you send only the parameters that correspond to the colormode that was active (you would not need to specify the colormode attribute, just the associated parameters, e.g. xy, hue and saturation or ct). The light will switch colormode based on the parameters set.

If you can do that, then you should be in a place where you are only sending a specific command and the bridge should not get overloaded and fail to service the requests.

With the latest firmware update, there are a number of changes/additions that I need to make to the API, and I am going to clean up the API Errors to reveal the underlying errors in the bridge when it happens.

from node-hue-api.

I think you're right, Peter. I am cycling through a number of color changes, and it's on the third or fourth iteration that the error normally occurs. It's as though the bridge can't handle the queue of requests. Apparently it throws a 404.

As far as what I'm setting for LightState, my approach was simply to 'remember' the previous light state and then reapply it after cycling colors. So I wasn't intentionally setting all those properties of the LightState; rather I am just showing what I had captured at the outset and then attempted to reapply.

from node-hue-api.

Based on the code you originally gave me, you were setting those values, and if I do attempt to set all the values that have been captured from the request to get an initial light state then I can reproduce this issue.

Based on the findings and that this is a problem with he underlying bridge not being able to process the commands (and there is a work around, as specified above), I am going to close out this Issue.

from node-hue-api.

I think the bridge is still being overloaded with requests in your case.

@peter-murray How many would you expect to overload it? We are trying to send 10 messages per second so light change can respond to surrounding environment noise level.

from node-hue-api.

It really depends on the request, payload you are sending. I have seen different results from different combinations of light changes.

For simple states you can send more, but if you are sending three values, like a brightness, on and color, then the number of requests you can send goes down.

There is a second issue currently open, issue #53, that is currently present with node.js 0.12, 4.x and 5.x that I am currently looking into.

What types of state are you sending to the bridge?

from node-hue-api.

I am currently having the same issue. has this ever been resolved rather than just closed?

I have a 3 range sliders that changes either h,s or b but if I move it too fast I get this error.

My code looks something like this

var setHue = function(id,hue){
   hueUserApi.setLightState(id, state.hue(hue))
    .then(noop)
    .done();
}

I have two lights. It also happens if I only use one light.
adding a flag to block the input and resolving it on .then also doesn't help.

from node-hue-api.

What version of the library and Node.js are you using? Also what type of bridge (the old round one or the new squarer one) and software versions of the bridge do you have?

The problem was not able to be reproduced under version 4.x of Node.js and there have been a large number of changes that have occurred to the library (like swapping our request with axios) that has resulted in massive improvements.

The bridge is still limited in the number of requests it can serve (not my library), you can DoS your bridge quite easily in some cases.

If you have a slider and are storming the poor bridge with requests to change on each increment when you move it, then that could explain your issue. The bridges are not particularly highly powered devices and they do a lot of checking of certain parameters that can slow down the number of requests they can serve.

Do you know how many requests you are sending to the bridge when you manifest the issue? If you turn on debug, it will print out the requests it is sending which should give you a good indication if you are not certain, although it will slow things down, it should give you some more insight.

from node-hue-api.

old bridge v1.10.0
node 4.2.1

do you think the old bridge could be the issue?
Is there a recommended way to live update the values when moving a control?

I'm pretty sure the app on my android does something similar. Not sure if they are limiting the requests though.

from node-hue-api.

Sliders are always a bit tricky, but normally in cases like this you might want to delay sending the request until the slider has say not changed in period of time, so that you prevent storming the bridge.

An example might be that you don't send a request until the slider value has not changed for at least 300ms, but it really depends on what kind of action you are performing here.

I did notice that when I transitioned to the new style bridge it did manage to process my test suite a little quicker, but I think that the internals are fairly similar, so I could probably create a test case to simulate this issue, but I don't see a way of solving it from the library side as this is more a user use case issue here and anything I could put in place would potentially slow down other use cases.

I would suspect that the android app (if you are referring to the Hue app) would cater for this kind of activity, and limit the number of requests. I can see this in the Hue App for iOS, in cases where colours are being set, if you drag around quickly, it jumps in colours rather than constantly changing, but if I move more slowly the colours change more or less as I move my finger.

from node-hue-api.

I don't really need this live update anyways. If the number of request is the issue then I should be fine with what I'm trying to make.
It is only interesting when setting colors from a colorpicker but in that case I will just debounce the event as suggested.

from node-hue-api.