CLI response speed

[Zamaroht]

Question:

Hello! I'm just trying out the CLI before integrating the Kotlin SDK into an android app (which would eventually run on a Meta Quest 3 VR headset).

After doing discover and authorize I can interact with the bridge perfectly. However, I notice there is a 5 seconds delay between sending a command from the CLI, and the light updating. Adding --debug shows that the PUT REST request is done instantly, and it takes 5 seconds to receive the 200 response. The light updates at the exact moment the 200 response arrives.

I was wondering if this is expected or usual. Using the official Philips android app gives me no delays, I also have no delays when using the iOS HomeKit integration. Maybe it's outdated firmware in my bridge? Should I expect the same delays when using the Kotlin SDK? Any configuration I can play with to find the cause of the delay?

Thank you!

[ReneeVandervelde]

No, it should be relatively instant. I'll look into this, it's possible something changed, been a while since dependencies were updated on here.

[Zamaroht]

Hello, thank you for the quick response! I've just tested by using Postman that if I send the PUT request manually, I get an instant 200 response and the light responds immediately. Using the CLI I keep getting the behaviour I described: The request is sent instantly, but it takes 5 seconds to receive the 200 response and for the light to update.

[ReneeVandervelde]

Which CLI tool are you running? Is it the one attached to the release artifact? Also which OS platform are you running on?

[Zamaroht]

I'm executing the shade.bat inside the shade.zip file here: https://github.com/InkApplications/Shade/releases/tag/2.1.0

I'm running on Windows 11 Pro 22H2

The exact command I'm executing is as follows:

.\shade.bat update-light [light-id] --host=192.168.0.15 --insecure --key=[application key] --power on --debug

[ReneeVandervelde]

Digging into this a bit - I'm able to reproduce this. It seems like this is caused by the warmup time in Ktor. Subsequent request calls don't appear to have this performance hit when using the SDK in an application.

However, for the CLI, since only a single request is made for a command, we see the performance hit each time, which is unfortunate.

I'm planning on moving off of ktor internally to something else to speed up the performance here, which may take some time. Just wanted to provide an update in the meantime and clarify the impact.

[ReneeVandervelde]

Actually, Looks like I may have a quicker fix ready. I'm about to do a 3.0 update, since the kotlin version was upgraded to 2.0 and will update this when it's released so you can test it out.

[ReneeVandervelde]

If you would like to verify, there is a release candidate with the binaries attached here

I plan on publishing this next week.

[Zamaroht]

Hello! Yes, that's perfect! The response is pretty much instant now when executing the command in my side. Thank you!

[ReneeVandervelde]

Was able to do this without a breaking change. So the fix has been released in 2.2.0