Error fetching scenes since upgrading to v4

[jk1993]

When calling api.scenes.getAll() on version 4.0.4 (have also tested downgrading to all other v4 versions) I get the following error message:

Error: The number of entries for the list, "0" is less than required minimum of 1
at ListType.getValue (C:\users\jack\desktop\hue-project\node_modules\node-hue-api\lib\types\ListType.js:48:13)
at LightScene.setAttributeValue (C:\users\jack\desktop\hue-project\node_modules\node-hue-api\lib\model\BridgeObject.js:46:48)
at C:\users\jack\desktop\hue-project\node_modules\node-hue-api\lib\model\BridgeObject.js:133:16
at Array.forEach ()
at LightScene._populate (C:\users\jack\desktop\hue-project\node_modules\node-hue-api\lib\model\BridgeObject.js:131:25)
at Object.module.exports.createFromBridge (C:\users\jack\desktop\hue-project\node_modules\node-hue-api\lib\model\index.js:306:12)
at C:\users\jack\desktop\hue-project\node_modules\node-hue-api\lib\api\http\endpoints\scenes.js:76:25
at Array.forEach ()
at buildScenesResult (C:\users\jack\desktop\hue-project\node_modules\node-hue-api\lib\api\http\endpoints\scenes.js:71:23)
at C:\users\jack\desktop\hue-project\node_modules\node-hue-api\lib\api\http\Transport.js:81:39

I thought that it could mean there aren't any scenes available but on v3 everything was working perfectly. Any suggestions?

Cheers

Jack

[peter-murray]

There are multiple scene types in the hue bridge;

• GroupScene
• LightScene

The LightScene is not valid (as per the Hue documentation) if it does not have any lights in it, whereas the GroupScene can have an empty list. of assoicated lights.

I would suspect that we may have a case of your bridge containing a LightScene that has an empty list of lights, or alternatively there is a bug in the type validation system, but I think there should be a test in place for that already.

You can turn on debug for the requests for the library and it will dump out the data it is requesting and getting back from the bridge, which should reveal the payload coming back from the bridge that is failing to get processed here. If you post that request I can look over it.
To turn on debugging, consult the docs: https://github.com/peter-murray/node-hue-api#debug-bridge-communications

If you do post anything from the debug, be aware of the fact your API key is exposed in the output, do redact that first.

[jk1993]

Thanks for the response, will take a look when I get a chance. I didn't realise I could get debug the requests to the bridge, that's a pretty useful feature! I suspect then I've probably sent some dodgy data to the bridge which has created a scene with no lights or something, so hopefully if I can identify that, then I can delete it using its ID. Will update when I've had a look.

Cheers

[jk1993]

That did the trick. There wasn't anything obvious in the debug log but running the GET query api/{apiKey}/scenes returned a bunch of JSON. Looking through that JSON I could see two scenes of type 'LightScene' with no lights in the array. They both had the name 'Wake Up Init' and neither had been updated since 2017. I'm assuming they must have been created by some third party android app but not sure.

I used node-hue-api to delete the two offending scenes and the node-hue-api scenes getAll() api call started working again! I'm guessing the previous version must not have failed when the light array was empty since I only started experiencing the issue after upgrading from v3 to v4 so might be worth validating the checks that are in place.

Thanks for your help and appreciate all the work you've put into this library.

[peter-murray]

The 4.x versions of the library adopted the type system that I was using in the http calls to the bridge object model, this means I can validate data earlier, rather than submitting it to the bridge and hope it comes back with a meaningful error message (usually not), or have to put in multiple checks for type/payload validation all over the place.

According to the models and restrictions are based on the documentation provided by Signify for the api, but as you have noted, these were from a long time back, where those restrictions were not necessarily in place.

The model object you get back from the library are the same ones you create in code to build these objects on the bridge, so I cannot relax these requirements, otherwise when you miss a value you will get a cryptic message back about invalid payload from the hue bridge.

The only thing I could think of with respect to validating you’re complete internal data state on an existing bridge would be to load every object (lights, groups, scenes, sensors, resource links, etc...) and then catch the errors indicating an invalid object. Whilst it could be useful, it would still require an end user to clean up the data objects.

I think the error you provided should be improved to better report the field on the object that failed, which would make resolving issues a little easier.

[odedd]

I just came across this (still happens in the v5 beta), and I'm pretty sure I found the root cause - this happens when fetching scenes, when there's a room that has no scenes, which is a valid case - at least the iOS app manages to function like that (and create that situation).

[SamDecrock]

Removing rooms with no lights (and thus no scenes) fixed it for me