[FEATURE] Spin `busyserve` command off into its own package.

[JnyJny]

The busyserve command shipped by busylight-for-humans[webapi] adds complexity to the project which makes it difficult to modify and test.

I propose spinning busyserve off into it's own package and removing it from busylight-for-humans in an upcoming release.

[Jaharmi]

Will this continue to use FastAPI and/or use the same API?

[JnyJny]

I am considering using Starlite instead of FastAPI and keeping the RESTful interface previously presented relatively intact.

Now is a great time to give input since I haven't completely made up my mind about any of this (other than this functionality needs to be it's own package rather than an enhancement to busylight). Input is welcome!

[Jaharmi]

I’m still considering some way to better integrate into Home Assistant. The REST API seems to be the best way.

I have Busylight and the API installed on a Raspberry Pi. My RPi has two lights connected via USB. I’m muddling by right now by using HA’s REST API integration to make some individual calls to:

1. turn on my lights and set a specific color (each call sets a different color, I haven’t set any variables or enabled any selection of color from the HA UI)
2. turn off my lights

For an integration, I was using the Busylight Swagger to create a module that I could potentially import into a new HA integration. I’m still learning / figuring things out — very slowly.

I’m also running an older version atm. I only check in once in a while and update my Raspberry Pi on occasion. Today was one such day.

I’ve thought it would make sense to create a HA Add-On (a Docker container, I think) that runs Busylight. That is something else I’d have to learn more about to accomplish. I still think the HA to BLFH communication would be over the API in this case. (The drawback, at least in my setup, is that my USB lights wouldn’t physically connect to my HA server.)