Default relayBoot/Pulse/TimeN settings with many switches

[mcspr]

espurna/code/espurna/relay.ino

Lines 479 to 498 in 1874f28

	void _relayBackwards() {
	byte relayMode = getSetting("relayMode", RELAY_BOOT_MODE).toInt();
	byte relayPulseMode = getSetting("relayPulseMode", RELAY_PULSE_MODE).toInt();
	float relayPulseTime = getSetting("relayPulseTime", RELAY_PULSE_TIME).toFloat();
	if (relayPulseMode == RELAY_PULSE_NONE) relayPulseTime = 0;
	for (unsigned int i=0; i<_relays.size(); i++) {
	if (!hasSetting("relayBoot", i)) setSetting("relayBoot", i, relayMode);
	if (!hasSetting("relayPulse", i)) setSetting("relayPulse", i, relayPulseMode);
	if (!hasSetting("relayTime", i)) setSetting("relayTime", i, relayPulseTime);
	}
	delSetting("relayMode");
	delSetting("relayPulseMode");
	delSetting("relayPulseTime");
	}
	void _relayBoot() {

3 of these settings are recreated every boot. Boards like RFBridge with 20+ switches result in EEPROM corruption, see #262 (comment)

[xoseperez]

This was added more than one year ago (b333687) so I guess it is mostly save to delete, but:

1. why is it recreating the settings on every loop? the hasSetting check should return false and do nothing...
2. it could be enough to test if hasSetting("relayMode") and exit the method if false in the very begining.

[mcspr]

I meant that they persistently come back when deleted, because loop is executed every time. Checking if old key exists does sound like a solution. BTW, can cfg be used more extensively for such cases? i.e. bump it every time any config key is changed and wire ...Backwards-like methods right after settings storage is loaded so they can do the migration.

Another thing - web will send them back and fill the settings again! On the same multi-switch board, getData($(".form-settings")) will gather the same keys as relay...N=0. Now I remember f59d747 trying to add 'original' protection, but it added another bug so most of inputs have empty 'original' 😨

• OnStart methods can be marked somehow and reset attrs only in that case, repeating the original intent and avoiding resets on weblog / status updates / etc.
• since 'original' value now can be trusted, getData can filter out based on 'hasChanged' attribute and only send small diff instead of whole config

[xoseperez]

Yes, we surely could be updating cfg more often. It will also require centralizing all migrations in a single module (migrate.ino?).

[mcspr]

Nah, I think just passing the cfg value should be enough. So the flow can be
setup() calls settingsSetup(), gets the cfg value, records it
every other setup() calls backwards(settingsConfigVersion()), migrates based on that
setup() calls settingsConfigVersion(CFG_VERSION) (or some hypothetical scheduler calls it implicitly just before first ever loop(), only once)

As for the issue - partially done in dev...mcspr:relays/less-cfg. rfbridge handling should probably do groups too, I hadn't noticed that rfcodes are a special case. Most likely solution is to have rfbOn / rfbOff keys instead