Closed mchaker closed 2 years ago
What you are seeing here is an artifact of the busylight_api
class checking to see if there have been any new lights added to the USB bus(es) since the last endpoint was serviced. The busylight_api
instance will call update
which then calls USBLight.all_lights()
which calls the all_lights
class method for all supported lights. The busylight_api
instance has a list of lights that it currently knows about and are held open to disallow another process from writing to them while they are under control of busylight_api
. So when the update happens and we try to open the light a second time, open_path
will fail. This lets us know that it isn't a new light we have to initialize in the update. In the output above:
2022-07-17 14:11:06.733 | INFO | busylight.lights.usblight:all_lights:195 - USBLight found 1 lights total
...
2022-07-17 14:17:38.505 | INFO | busylight.lights.usblight:all_lights:195 - USBLight found 0 lights total
The first line indicates one light was found, the second indicates that no new lights were found. Which is expected if you haven't attached any new lights in the interval between the two calls.
The light/N/status
endpoint is doing the best it can :)
Most USB lights are essentially "write-only" and all but a few return zeros when read. The info
section of the status response is the initial information read from the device via hid.enumerate
. The USB standard(s) have a list of possible values that devices "should" implement but are not strictly required. So the empty fields in info
are fields the manufacturers decided not to populate.
All the other information in the status
response is state maintained in busylight_api
(one reason to keep all the lights open exclusively is to keep other processes from modifying the state of the light, causing state information of the light to become incomplete).
One thing I could do here is reduce the default logging level for the webapi which will hide some of these distressing messages, but given the output you provided I don't see any evidence of a bug.
Ah, I understand now. Thanks for explaining! This is not a bug - closing the issue.
I appreciate you giving it a work out and calling me on anything that's confusing. I've spent so much time looking at this stuff that it's difficult for me to see how this code looks from a fresh perspective.
I'm glad to help! I've just published a repository called busylight-docker
which is a way to run busyserve
in a Docker container (I have all my lights connected to a single server on my desk :) )
Software Versions:
General Type of Problem
Describe the Problem
When starting the web API, a
DEBUG
message appears stating:and then, when attempting to access any API endpoint, the following error appears:
Light commands seem to work (on/off, at least), but not much information about the light returns in
/light/0/status
(missingserial_number
,manufacturer_string
,usage
, perhaps?):Perhaps the
open_path
error is limiting the information obtained from the light? Unsure.Expected Behavior
No errors to occur.
Error Output
Full log from
busyserve
start: