INPUT LED lookup

[wtgee]

Add an LED lookup for each of the possible INPUTs in case the encoder and home sensor are not wired to default pins.

[lspitler]

LGTM

[AnthonyHorton]

I think there is a more elegant way of doing this using an IntEnum for the Automation HAT GPIO pinout, e.g.

class HAT_io(IntEnum):
    INPUT_1 = 20
    INPUT_2 = 21
    INPUT_3 = 22
    ...

The user can then specify which inputs the encoder & home switch are connected to by human-readable name e.g. encoder_input = 'INPUT_1', then

self._encoder = DigitalInputDevice(HAT_io[encoder_input], bounce_time=bounce_time)
self._encoder.when_deactivated = lambda: self._change_led-state(0, leds=[LED_Lights[encoder_input]])

etc.

This is fine for now, though.

[wtgee]

I think there is a more elegant way of doing this using an IntEnum for the Automation HAT GPIO pinout, e.g.

class HAT_io(IntEnum):
    INPUT_1 = 20
    INPUT_2 = 21
    INPUT_3 = 22
    ...

The user can then specify which inputs the encoder & home switch are connected to by human-readable name e.g. encoder_input = INPUT_1, then

self._encoder = DigitalInputDevice(HAT_io[encoder_input], bounce_time=bounce_time)
self._encoder.when_deactivated = lambda: self._change_led-state(0, leds=[LED_Lights[encoder_input]])

etc.

This is fine for now, though.

I like that more. I'll get it switched now otherwise it probably will get lost.

FYI @fergusL

[wtgee]

I started on this and then realized that the way I would want to do it would take slightly more work so I thought I'd check. Basically what I as a user want to do is:

dome = Dome(encoder_input=1, home_sensor_input_2, rotation_relay=1, direction_relay=2)

Alternatives would be to pass a string, .e.g encoder_input='INPUT_1' (could be lowercase too) or to pass the enum object. The latter requires me as a user to import the enumeration, which isn't terrible but is a bit annoying. The string is okay I suppose.

What I propose with an integer referring to the name as labelled on the hat itself would require more parsing and checking than the others but is a bit more intuitive and friendly (IMHO).

Thoughts?

[wtgee]

I gave the above a little more thought and think import the enum makes the most sense. One can imagine us replacing the AutomationHat with our own custom board in which case the mappings might not be the same but all you would need was a different enum.

[fergusL]

Before we were discussing having a yaml config file #22, I feel like maybe it makes more sense to push a user towards specifying everything in the yaml file and loading the settings as part of the Dome initialisation. Passing in a bunch of keyword args seems like itd be quite prone to typos etc

[wtgee]

Before we were discussing have a yaml config file #22, I feel like maybe it makes more sense to push a user towards specifying everything in the yaml file and loading the settings as part of the Dome initialisation. Passing in a bunch of keyword args seems like itd be quite prone to typos etc

Ideally you just do both. The dome constructor can accept all the keyword arguments and you give them sensible defaults, but normal practice would be to load a config file and use that to pass the arguments into the constructor.