Add support for Yagusmart 1, 2 ad 3 gang switches

[MelanieT]

https://www.amazon.co.uk/gp/product/B086MV5MC8

These don't come with an esp8266 anymore, but can be trivially converted
as the new chip is pin compatible. Note, GPIO15 needs to be connected to
GND on 1 and 2 gang switches in order to enable the ESP to boot.

Older versions and some US models may still ship with ESP8266.

Caution, do NOT solder a serial port while the board is connected to the mains baseboard, it will blow your fuse and your USB! If you need to flash with a programmer, use a bench power supply on the logic board only!

[mcspr]

Thanks!
I included the comment above in the header, plus modified the changelog

[MelanieT]

I have another thing that has come up in hacking these switches: They have relays in them that click even if all you wnt is to use it as a controller for, say. a smart bulb. I would suggest that, under switches, there be a checkbox that would tell espurna to not actually toggle a relay gpio, but only pretend, so that on a button action, a relay/x/set message is sent without an actual relay being energised. That would allow an easy choice between having a smart switch as a pure control device, or an actual switch. I could envision what can be done in the switch module to facilitate that, but I have no idea how to surface something like that in the web UI. However, it seems to be a vaild use case, at least for openhab. Do you have any pointers on how to do that?

[mcspr]

I would suggest that, under switches, there be a checkbox that would tell espurna to not actually toggle a relay gpio, but only pretend, so that on a button action, a relay/x/set message is sent without an actual relay being energised.

The way Xose originally implemented this is by introducing DUMMY switches and a global PROVIDER build flag so we could have RFBRIDGE toggle virtual relays on RF code arrival, and also send some RF codes when relay toggles. dev right now replaced global 'providers' with a per-switch settings that may change it's configuration.

espurna/code/espurna/relay.cpp

Line 463 in 0344260

return getSetting({"relayProv", index}, build::provider(index));

espurna/code/espurna/relay.cpp

Lines 408 to 421 in 0344260

	template <>
	RelayProvider convert(const String& value) {
	auto type = static_cast<RelayProvider>(value.toInt());
	switch (type) {
	case RelayProvider::None:
	case RelayProvider::Dummy:
	case RelayProvider::Gpio:
	case RelayProvider::Dual:
	case RelayProvider::Stm:
	return type;
	}
	return RelayProvider::None;
	}

espurna/code/espurna/relay.cpp

Lines 582 to 596 in 0344260

	// No-op provider, available for purely virtual relays that are controlled only via API
	struct DummyProvider : public RelayProviderBase {
	const char* id() const override {
	return "dummy";
	}
	void change(bool) override {
	}
	static RelayProviderBase* sharedInstance() {
	static DummyProvider provider;
	return &provider;
	}
	};

current setting is a simple RelayProvider enum <-> integer cast e.g.

set relayProv0 1
reset

will no longer do anything with the associated GPIO

edit
or, there are always build flags

espurna/code/espurna/relay.cpp

Lines 194 to 205 in 0344260

	constexpr RelayProvider provider(size_t index) {
	return (
	(index == 0) ? (RELAY1_PROVIDER) :
	(index == 1) ? (RELAY2_PROVIDER) :
	(index == 2) ? (RELAY3_PROVIDER) :
	(index == 3) ? (RELAY4_PROVIDER) :
	(index == 4) ? (RELAY5_PROVIDER) :
	(index == 5) ? (RELAY6_PROVIDER) :
	(index == 6) ? (RELAY7_PROVIDER) :
	(index == 7) ? (RELAY8_PROVIDER) : RELAY_PROVIDER_NONE
	);
	}

[MelanieT]

But how to surface that in the UI? Sure, a telnet command is a good start, it means the groundwork is in place, but all the nontechnical users woudln't know about it.

[mcspr]

For the setting, see existing <select> code in the .js & .html? List of available options is missing atm, but the relay's provider key-value is already sent to the UI.
DEBUG panel is both log and terminal interface btw