search

JnyJny / busylight

Control USB connected presence lights from multiple vendors via the command-line or web API.
Apache License 2.0
226 stars 25 forks source link

[NEW LIGHT] Adafruit M4 Express / NeoTrellis #270

Closed andrewwatson closed 1 year ago

andrewwatson commented 1 year ago

If you would like BusyLight to support a new device, please provide as much of the following as possible.

I have one of these built and I've been writing some Circuit Python on it and I've started work on adapting the trinket code for the neotrellis. I opened this issue to start a discussion about whether any changes to busylight would be necessary

JnyJny commented 1 year ago

Interesting. Just skimming the docs for those devices, I imagine that BusyLight would be on the M4 controlling the lights which are either accessed via GPIO or I2C. BusyLight currently support USB HID and serial "backends" via busylight.lights.USBLight and busylight.lights.SerialLight. So I guess we would want to add busylight.lights.I2CLight and possibly busylight.lights.GPIOLight (I think your intent is support for NeoTrellis attached via I2C according to the docs, so GPIO might just be a nice to have but not necessary).

I think my biggest concern is light discovery; both HIDAPI and USBSerial have the ability to query available devices and I've spent a lot of time on abstracting the Light API to make it usable without having to know the specifics of a connected device. It might be that I2C/GPIO breaks some of that ease of use, but presumably people using the M4/NeoTrellis devices are a little more technically savvy and up to the task of knowing what lights are available a priori and what "flavor" of device is connected.

I'm not opposed to supporting this combination, but I'll have to spin up on I2C/CircuitPython/etc or have some really good pull requests to work with :)

andrewwatson commented 1 year ago

Well, I haven't really been able to dig into all the magic in busylight yet but I was thinking that on the M4 itself the code could be pretty much this https://github.com/freemansoft/Adafruit-Trinkey-CircuitPython or something similar. BusyLight would just have to be able to detect the device was present (HID) and send it signals over... serial console? I'm not sure, actually.

I've got CircuitPython on my M4/NeoTrellis now that plays animated 4x4 sequences when you press its own buttons and "types" things as if it was a keyboard. I just need to have some way of sending it messages from the host to trigger lights / sequences. It could be that it's not a great fit for the model you've already been working with but I'm curious to try and get something working.

JnyJny commented 1 year ago

I suspect, for your application, BusyLight is overkill as it is essentially "wallpaper" over the weirdness of talking to USB devices (HID and serial) and the wildly disparate command architectures of various commercial lights. I don't know how your NeoTrellis is connected physically to your M4, but my suspicion is via the I2C bus and not a USB connection. A brief survey of this article seems to indicate that scanning an I2C bus for devices and writing to them is relatively simple.

That said, I'm still willing to entertain the idea of adding I2C support to BusyLight. I've got a Feather lying around somewhere, just need to acquire a NeoTrellis to play with.

JnyJny commented 1 year ago

One thing just occurred to me. Most of the lights supported by BusyLight don't permit individual access to component lights and so the method busylight.light.Light.on((R, G, B)) turns the light on with color tuple (R, G, B). There is a precedent for specific lights supporting LED addressability; busylight.light.luxafor.Flag family of lights for instance have a leds attribute that controls which LEDs are turned on and off. IIRC the BlickStick family also has addressable LEDs, but BusyLight treats it as just one light as well.

All this to say, the BusyLight model might not give you the ease of use you were looking for (at least not right away).

andrewwatson commented 1 year ago

You're right, I didn't think about the discoverability aspect of it. This particular device probably isn't well suited for busylight because you'd have to have certain python running on it and configure the serial port etc. I'll keep tinkering with it separately.

Thanks!

Andy Watson https://www.linkedin.com/in/andrewwatson/

On Wed, May 31, 2023 at 5:54 PM Erik OShaughnessy @.***> wrote:

One thing just occurred to me. Most of the lights supported by BusyLight don't permit individual access to component lights and so the method busylight.light.Light.on((R, G, B)) turns the light on with color tuple (R, G, B). There is a precedent for specific lights supporting LED addressability; busylight.light.luxafor.Flag family of lights for instance have a leds attribute that controls which LEDs are turned on and off. IIRC the BlickStick family also has addressable LEDs, but BusyLight treats it as just one light as well.

All this to say, the BusyLight model might not give you the ease of use you were looking for (at least not right away).

— Reply to this email directly, view it on GitHub https://github.com/JnyJny/busylight/issues/270#issuecomment-1571013856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABMY6RW3OMKIX4TE2Y4LWDXI642VANCNFSM6AAAAAAYU2SYJU . You are receiving this because you authored the thread.Message ID: @.***>