omg - I like this idea so much. For a few reasons:
- I’ve been wanting to clean up the internal structure of the device code with a very clear delineation between the mesh vs the other system code vs the GUI app that understands text/GPS messages.
- That cleanup would make it easier to have the concept 'it is easy to link in your own small code as an app on the mesh node and you can do what you want with hardware and send/receive messages (using the regular ‘arduino’ api)
- Your idea would be an ideal first other ‘co-resident app’. And it is pretty clean and easy to do
- @Anelito’s comment about remote settings makes me think we should generalize this into “every node can have a set of named attributes that can be read/written by other nodes”. Initial usage of this named attribute concept would be for remote settings management, and this new remote-gpio module.
Slight restatement for the idea (for the github bug I’m about to make):
- Make a ‘remote-gpio-module’ (and it will use the new ‘remote attribute API’)
- Let the android/python clients have a mechanism to list, view and change named attributes
- The gpio-module would publish all of the free GPIOs on a board as named attributes available for setting, reading and direction control
- This new module could be a great small example for how others could write/add new modules of their own
Alas - I’m trying to stay super focused on getting 1.0 finished (and stable 
) with the original planned set of features. So I don’t think I’ll have time to work on this until 1.0 ‘ships’ (a few weeks?). But I’m super eager to make this happen (and it sounds fun). If no one does it before then, I’ll happily do so.