Enabling specifying pin values as external configuration

[dotnet]

Enabling specifying pin values as external configuration

[joperezr]

Interesting, I suppose obviously that the variable name parameter would be optional

[richlander]

Yes. For the config, I think we need to decide if we will support a more general config system or make it GPIO-specific. As worded, it is general. That's one of the design points to nail down.

[joperezr]

This will be needed for our testing story in the lab. I don't expect this infrastructure to be built-in the library itself, but instead some extra infrastructure we have for our testing strategy. If no-one picks it up, I'll take a look at this soon.

[joshfree]

@MichaelSimons do you have any thoughts on this from the docker side of things?

[krwq]

We currently have IGpioController where user can define mapping for the pins and whatever other additional logic - perhaps we could add an example with that or create a separate library which shows how to do that?

[krwq]

[Triage] Can we provide specific use case for why do we need this class? This currently seems to have a low priority and we're considering closing this issue.

[joperezr]

I'm fine with closing. The main use case for this was in case you have an application that you want to run in many devices (for example you run it via docker containers on many different raspberry pis which are all in a lab) but they might have sensors connected to different pins each, and currently we hardcode the pin number on the application so you would require to wire all those pis exactly the same using the same pins. The idea here was to provide an extensibility class that would check to see if there was a configuration file (xml or json) near the app for different pins to use, or a default.

All that said, I'm fine with having that issue pushed to folks that need this for now, and if we see that a lot of people want it we can consider adding it to our bindings in the future.

[pgrawehr]

If you need something like that, it would probably be better yet to test which board has what attached completely in hardware, like using some GPIO pins as hardware revision inputs (pulling them high or low, depending on the attached hardware).

[Ellerbach]

[Triage] Regarding this issue, you can always use environment variables for that.

it via docker containers on many different raspberry pis which are all in a lab) but they might have sensors connected to different pins each, and currently we hardcode the pin number on the application

The pattern with container is to use environment variables, you'll just read them in your code. So this can be achieved in a very simple way.