Porting this to other API for RGB LEDs

[dglaude]

I would like to write equivalent code for other RGB LEDs.

I have in mind the following:

• Blinkt! from Pimoroni
• Rainbow (the LED part is having a API similar to Blinkt!)
• Inspiring SPI controled APA102 stick from http://rasp.io/inspiring (API not release yet, but I have access)

The goal is to reuse your App without modification, but to offer more option to those not owning a mote.
I plan to do code duplication (copying under another name, then modify to use another API).
Potentially, I could create a sandwich API layer to avoid duplication, but that is a second step.

I know those API and have worked a lot on Blinkt! examples.

Let me know if I can start coding. :-)

[raruston]

Hi David, Thanks for getting in touch - I'll check out your pull request later but it shouldn't be a problem. With respect to the app - feel free to fork and make any changes you would like :) That said, I'm wondering if it would make sense to collaborate? One reason I say that is that I knocked the App code up fairly quickly, and based on what you described, I'm not sure the code currently on Git is a great starting point. The main issue is that it only supports a single device / endpoint, and under the covers this is reflected in the network code too. I started work on two new features which would provide a much better starting point. One was to allow multiple devices to be defined and stored (the intent was to use CouchDB Lite as the local storage mechanism) and the other was to refactor the network code (which calls the actual APIs) to be a more generic service. If I get those done, the app would be in a much better state to handle new device types. As part of the second piece, I was changing the app to use the example API provided by Pimoroni, rather than the one in my repository (which is actually from Pimoroni anyway and not that great). I had no further plans to modify the API in my repository once I had migrated to the Pimoroni one, thinking I could issue Pull requests if required. From an API perspective, the Pimoroni one for Mote would be a better starting point. Unfortunately I got distracted by Christmas and starting a new job this year so I put them on hold for a bit. If you know Android, it might be better to start fresh, if you don't, it might be better for me to complete these features ;) It sounds like that would be useful for you though and I like the idea of supporting a whole range of devices. With respect to the APIs, when I first developed the app I spoke to Sandy at Pimoroni and asked about their intent for the Mote API. I had considered writing my own, so I could add cool features like custom commands (to enable an ocean or rainbow effect from the app for example). That said I also thought it would be better if people could just install the Pimoroni software, start their example API and could then use the app with it - essentially leaving responsibility for the API with them, knowing I can make pull requests. For multiple vendor support though, this doesn't make sense. My own idea had been to have a base API that provided simple versioning and function for the Mote, and implement some kind of 'plugin' capability for the API where I could quickly add a new function by dropping a plugin file into a folder. It sounds like this might be a good structure for an API that supports multiple types of device - essentially one plugin for each type of device. The base API would provide an endpoint allowing the client to query which devices (Blinkt!, Mote, whatever) it has attached, and the app can then control all of them. There are a number of options we could pursue: 1. You could fork the projects and change things for your purposes, which is exactly why I posted the code :D 2. I can add you as a Collaborator to the existing projects, and we can work on those together to add the new functionality (possibly with a rename?) 3. We could fork the existing projects into something new, rename them and go from there 4. Something else if you have any suggestions? Apologies for the big brain dump, but let me know what you think and we can go from there :) Cheers, Richard

…

On 1 April 2017 at 20:49, David Glaude ***@***.***> wrote: I would like to write equivalent code for other RGB LEDs. I have in mind the following: - Blinkt! from Pimoroni - Rainbow (the LED part is having a API similar to Blinkt!) - Inspiring SPI controled APA102 stick from http://rasp.io/inspiring (API not release yet, but I have access) The goal is to reuse your App without modification, but to offer more option to those not owning a mote. I plan to do code duplication (copying under another name, then modify to use another API). Potentially, I could create a sandwich API layer to avoid duplication, but that is a second step. I know those API and have worked a lot on Blinkt! examples. Let me know if I can start coding. :-) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEkSDj0zX76bnHzCCfTqelD4q3JmnEiQks5rrpwcgaJpZM4Mwk9p> .

[dglaude]

For the app, I don't really have the skills and build system to work on the android side, that's why I wanted to work on the colorfull LEDs side.

For the options, the best is that I fork and show you stuff there rather than to mess in your copie.
Yes if it is not mote specific, another name might be good.

I am not fully interested in supporting simultaniously multiple hardware (on the same pi) or multiple hardware on multiple pi. That could be solved by making the android app more complex and accepting multiple destination... but a central server that control them all is an option.

Today, your code is mote minded and only require:

• init
• set all LEDs to one color
• turn on
• turn off

I will try to extract that from the code and make it modular,
Then provide equivalent for other hardware.

This will not fill the bill for effect as there you want to address individual LEDs.