getCachedState() returns null, failing the requests

The below code fails for me with

Cannot read property 'modelid' of null

so it’s clear that the getCachedState() function returns null in my case.

This was at the very first setup. I don’t know which exact situation is needed to reproduce this, but I got this error as soon as the Hue API started working for me for the first time.

I hope this is enough indication for you to find the bug in the code. null errors should be simple enough to fix.

[benbucksch]

I have recent Hue bridge, IIRC late 2018. I think that’s version 2.

FYI, when I tested, it was blowing up only at this one spot. With the hacky patch, it worked as expected. I could enumerate lights and rooms, and switch them on and off. However, it’s possible that this does unnecessary work on startup.

I perfectly understand the need to test the fixes. If you need me to test something specific with master, I can do that. However, I’m currently only vacation, and otherwise have to run 2 companies, so I cannot guarantee it.

Re: axing axios (pun intended): Yay! Thanks!

(replying by email)

Am 17. August 2020 10:12:23 MESZ schrieb Peter Murray [e-mail]:

Your fix that you suggest just pushes problems further down and other stuff will blow up later in use (I cannot see how we don’t get a cache loaded). The cache is a requirement to load the known configuration and to store things like the lights that are known so that various validations can be performed later, getting past this current check just stores up later failures that will happen if you call certain functions in the API.

This ticket was closed as I provided some changes to get feedback to narrow down as to the problem at hand. There was no response from that and those changes added that I asked for feedback on.

If I cannot reproduce an issue, I cannot test it. If I cannot reproduce and test it, I cannot release a fix to it that I am confident in it not impacting other users.

Signify has ended software updates for the v1 of the bridge, so the need for this check is goign to go away as people retire the older bridges, removing the divergence in the API parameters.

I am currently working on a 5.0 release of the library which is removing axios for a fetch based implementation (to better support browser use cases and remove some of the bloat and proxy support issues of axios).

– You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/peter-murray/node-hue-api/issues/172#issuecomment-674732094

– Sent from my cell phone. Please excuse the brevity.

[peter-murray]

Your fix that you suggest just pushes problems further down and other stuff will blow up later in use (I cannot see how we don’t get a cache loaded). The cache is a requirement to load the known configuration and to store things like the lights that are known so that various validations can be performed later, getting past this current check just stores up later failures that will happen if you call certain functions in the API.

This ticket was closed as I provided some changes to get feedback to narrow down as to the problem at hand. There was no response from that and those changes added that I asked for feedback on.

If I cannot reproduce an issue, I cannot test it. If I cannot reproduce and test it, I cannot release a fix to it that I am confident in it not impacting other users.

Signify has ended software updates for the v1 of the bridge, so the need for this check is goign to go away as people retire the older bridges, removing the divergence in the API parameters.

I am currently working on a 5.0 release of the library which is removing axios for a fetch based implementation (to better support browser use cases and remove some of the bloat and proxy support issues of axios).