Closed HorizonKane closed 4 years ago
The error that is coming from the node-hue-api
library there is from an old version of this library, that still had Q promises in place. It is not clear from the error there as to what version of the library it is, other than it will be an old one for sure as I migrated off of httpPromise.js
a couple of major versions ago.
The code that is actually erroring is something in the Node RED usage of my library, but it not clear what API endpoint are being called from Node RED. I would say that you would be better looking at the Node RED module you are using for the Hue integration, it may need updating to a later version.
I cannot tell which version of the node-hue-api it is, but you might get some more output as to the endpoint that is being called on the Hue side of things if you set a NODE_DEBUG="node-hue-api"
environment variable before you run the script, as that was something that I have had in place for a while now, and it will expose some details on the API calls being made to the hue bridge.
I just ran into this myself. It's this request that dies:
{
"debug": true,
"headers": {
"Accept": "application/json"
},
"timeout": 10000,
"method": "GET",
"url": "https://www.meethue.com/api/nupnp",
"ssl": true
}
The URL 404s and seemingly should now be https://discovery.meethue.com/
So I hacked 2 files:
# edit discovery host around line 31 to "discovery.meethue.com"
node_modules/node-hue-api/hue-api/bridge-discovery.js
# edit the path around line 23 to "/"
node_modules/node-hue-api/hue-api/commands/discovery.js
All is working again. It's really unfortunate they didn't just do a redirect or something on that URL :(
Thank you for the details, I will get a fix released tomorrow for this.
I’m not sure what the nodered package is pinned at. It’s not been updated in a while so depending on how strict the pinning is it may require a point release going back a ways for that specific use case. I’ll go dig around and see what I can find to see how strictly it’s versioned.
Yeah, this is unfortunate for the Node-RED
people anyway:
"dependencies": {
"node-hue-api": "1.0.2"
},
Probably near impossible to get that updated (given the project hasn't been updated in years) but I suppose we can reach out and see..
I have just realised that this problem is just due to the older version being used inside Node RED, I fixed this even in the 2.x versions of the library over 13+ months ago, where I have been using the discovery.meethue.com endpoint ever since.
I am closing this ticket as it is another project's use of an out of date version of this library.
I don't see the user updating the library on the Node-RED module referenced above...
There is an alternative that covers similar functionality; https://github.com/jdomeij/node-red-contrib-node-hue which whilst using an older version of this library (so is slower than what the 3.x, 4.x versions will run at) does include the change for the N-UPnP endpoint.
Yeah there are alternatives, it’s just disruptive to folks who used. I for example still haven’t converted everything to: https://flows.nodered.org/node/node-red-contrib-huemagic which is what I would recommend as an alternative.
Hi,
I updated my hassio and Node-RED to the latest version and since then Node-RED keeps restarting all the time with this log:
Is there a way to fix this or at least to deactivate the node-hue-api so it can start again?