Closed illperipherals closed 8 years ago
What exactly would you want to achieve?
My initial thoughts were (for example), if the user is not intending to use a hardware button/leds/etc in the buildout, those pins should not be addressed in the code to interfere with other devices. Some method to select/deselect "modules" on install (and perhaps pin management) could prove useful. This way the user does not have to dig into the code for pin collisions.
You can easily set pin numbers in the config file now. With #30 merged, we'll have device platforms so people can further tweak their devices. Also, there will be a dummy platform that won't touch the device at all. Is that sufficient for you or did you have something else in mind?
I actually just got an email about this project, which I think outlines what I am wanting to avoid: https://www.hackster.io/youness/amazon-alexa-gui-4c2141
"Step 3: Include display states in original AlexaPi code Duplicate original main.py cp main.py gui.py"
(no disrespect to that project by any means, I simply don't want to see fragmentation of the main base for plugin integrations)
This is exactly what you would use device platforms (#30) for. Currently in that PR we're missing the busy state, which is kind of a bug and we need to bring that back.
Have a look at the PR and if it satisfies your need then close this.
Looks good. Closing down.
Have you folks put thought into some type of module system for expanding AlexaPi? For example, I use an oled display on some builds, an rfid read/writer on others. I do not want to pullute the effort going into the refactor right now, I just wanted to put the topic up for discussion.
Thoughts?