Remove AR pin default assignments (Fix #4352)

[kilrah]

Avoid instances using old default AR pins as LED outputs being blocked from updating settings

#4352

[DedeHai]

much appreciated, this has to go into 0_15 release IMHO.
@softhack007 what is the reason to have fixed default pins assigned?

[blazoncek]

Some of the (long) existing WLED controllers with AR support have those GPIO wired to microphone pins.
This legacy is documented in KB, I think.

AR was much requested usermod to be included by default (and also enabled by default) so IMO removing default assignment will cause as much frustration to new users as is inability to set LED output. I would suggest not to merge this PR.

[netmindz]

Official builds having the pins defined (in platformio) and the code itself having a default value when there is no define aren't the same thing, so I would agree that we should use a single approach.

I.e if we merge this change, then we also need an audit of the current build flags.

The ultimate impact of this would not however be removing the default pins from the releases, but only to provide consistent behaviour where if you do not set a pin at build time that none is defined

[blazoncek]

The ultimate impact of this would not however be removing the default pins from the releases, but only to provide consistent behaviour where if you do not set a pin at build time that none is defined

That's the most sensible approach.

However, most usermods were submitted by users that originally created the HW solution (that needed a usermod) and hence had default values (for their HW) built in. So changing just one usermod is still not consistent enough and not adding build flags for every usermod will render those usermods inoperable by default when compiled. It would require editing usermod's readme files for every usermod.

[netmindz]

As AR is one of few ( only ? ) mods included by default, then I think it's ok to hold that to a higher standard than expecting consistency for every usermod

[softhack007]

@blazoncek @netmindz @kilrah

I think this PR is not a good way to solve the problem. We actually added default pins to avoid a flood of support requests like "what pins should I use for my new INMP441".

I think the general approach of "all pins are allocated at startup, even when a feature is disabled" is the problem. I see two possible solutions:
a) early exit out of audioreactice::setup() when the usermod is disabled - so pins are only blocked when really needed, or
b) add a new MIC type "network only", and make this the default. Don't allocated pins when in "network only" mode.

Both options would allow to keep defaults in the UI, while avoiding to "steal pins" when audioreactive is not enabled at startup.
(The MoonModules fork implements solution b), so I could bring the code into upstream AC if needed).

[softhack007]

as stated above, I don't agree to merge this change.
We should find a better solution that still provides good defaults for people who want to use audioreactive.

[blazoncek]

I also do not agree with the proposed approach.

One thing to consider, though, is that GPIOs are "reserved" even though not allocated or used. If some configuration item assigned a GPIO and saved it, it becomes "reserved" and hence unusable by other things. There is no way around this as usermods (and future settings pages in work by Aircoookie) will read configuration items from cfg.json itself and not from runtime variables.

[netmindz]

To play devil's advocate - only trying to claim pins when enabled is something we have visibility issues over. Most users do not have serial logging and we don't have a way to surface such errors to the UI. The "initialisation failed, check pin config" in the info pane is better than just saying silence, but is specific to AR usermod and doesn't tell you which pins with what

[netmindz]

B feels like the natural choice. Unless you say you have a mic, assume you are recieving from elsewhere

[blazoncek]

The issue here is GPIO reservation (or lack of good explanation in UI why GPIO cannot be selectd, i.e. for LED output), not microphone type.
Unfortunately constructing LED output configuration (sub)page is already complex and adding GPIO dropdown is difficult. Other GPIO fields on the same page do have GPIO dropdown where users can see those reservations.