options.timeout in httpPromise.js

[mwallnoefer]

httpPromise.js contains the following line for setting a HTTP request timeout:
options.timeout = 10000; //TODO make adjustable

I am using your library with Node-RED and under certain conditions the Hue hub is unable to answer in under 10 sec. This causes the whole Node-RED server to crash since the thrown TIMEOUT exception is not catched. For now I have commented out this line and have no issues anymore.
Hence I would make this setting strongly optional.

[peter-murray]

The error will bubble up the promise chain, so you can catch it and deal with it when you get it.

What are you querying that is taking more than 10 seconds for the bridge to respond? I have encountered issues like this on my bridge in the past, but a restart of the bridge cleared the issue and restored performance.

The timeout is in there to ensure that if/when there is a mistake with the parameters to the bridge that the connection will not hang forever.

I will look into some options for specifying this in a sensible way for end users and look to release an update to the library soon.

[mwallnoefer]

Indeed, a setting would be very fine: so we could increase or switch off this option.
Thank you!

[volkerrichert]

@peter-murray: I have the timeouts very often. One second it reacts instantly, the next second the bridge take more than 10 sec to react on the pressed button on the hue remote. I tried to deactivate my integrations but nothing helps. Restating the bridge does not help. atm I have 4 LED blubs, 3 osram plugs and a RGBW Controller (FLS-PP3) from Dresden electronic.

Any idea?

[peter-murray]

@volkerrichert there can be a number of reasons for load on your bridge and slow responses, but mostly it is either down to excessive polling or posting to the bridge. The bridge is a fairly lightweight device and it does not take too much to overload them, something like 10 light state changes posted separately over a second could easily do it.

You do not mention, which bridge you have, the older ones, they are circular are slower than the new rounded square pucks, so that might be something to consider. There is also a few things internally to do with scenes and groups that can require a bit of a clean up from time to time, especially when developing against them. The hue app on iOS has some options for cleaning up some of those. Also make sure you are up to date with the updates, these usually make things better, except for a few early mess ups from Philips.

Ideally you want to work in batches for changing states, I.e put all the changes, on, Color, brightness for each light into a request rather than post them all separately, and avoid polling the bridge heavily to discover states. I think also there are some state retrieval endpoints that are fairly heavy as they return all values of all things, which should be avoid being queried heavily.

Then there is also the possibility that there might be something wrong with the bridge, but you would have to be able to prove that using no integrations before you could engage with Philips on that one.

[volkerrichert]

I found the reason. Querying a bulb group cause this behavior. I don't know if this ist located in ths lib, in node-red-contrib-node-hue or the bridge (i have V2). After switching to one bulb from that group it runs like silk.

[peter-murray]

I doubt it will be this library, as I am merely a thin wrapper around the exposed api itself. I don’t do multiple queries except in extreme edge cases, and those are mainly for configuration.

It would probably be worthwhile raising an issue with node-red library developers so it can be resolved.