Ewoud

Eventually it turned out we removed leds from effect functions all together and only have leds under the hood in sPC and gPC. So using fastled code into WLED requires...

Yeah, good point, on the other hand you could save on the short help texts which are now stored on esp. What problems you will encounter if you increase size...

That’s a good idea 👍 ! why oappend uses stack anyway? Isn’t malloc a better idea? Or is it 8266 related?

Could we minimise stack buffer by shortening the names of the functions and also shortening the names of the fields: addDropdown -> aD addOption->aO addInfo->aI addInfo('AudioReactive:dynamics:limiter'... -> ai('ar:dyn:limiter'... etc that...

Okay found the solution building on [Usermod level up](https://mm.kno.wled.ge/moonmodules/merge-history/#usermod-level-up) : Instead of building the pages for all usermods in one go only build it for one usermod at the time....

👍 What do you want to do with the remaining content in menu option 'Usermod'. Npw only the globals will stay there, nothing more: In MoonModules we left it there...

> would propose adding another helper function `addHB()` so that `oappend` does not need to contain button HTML or the `https://kno.wled.ge/usermods/` link root. That way, e.g. the super short `oappend(SET_F("addHB('PIRsensorSwitch');"));`...

If you want us to do, happy to do so. Will just pull the usermods info we already made in mm.kno.WLED.ge to up

Same applies for (HW_PIN_DATASPI, HW_PIN_MISOSPI, HW_PIN_CLOCKSPI)

I saw the placeholder functionality. It's info only, not assigned to anything I would say setting hw_pin_sda/scl (or not setting) determines if gpio should be allocated or not. Might be...