Dingtian: add inverted outputs and support shared PL/RCK pin

[baetzst]

Description:

Add support for the esp32_relay_x8_modbus (303E32DC812) board by
allowing inverted relay outputs and shared PL/RCK control pins in the
ESP32 Dingtian driver.

GPIO Mapping

GPIO	74HC595	74HC165	Tasmota
33	SIN	–	Dingtian SDI
25	RCK	!PL	Dingtian PL
26	SCK	CP	Dingtian CLK
27	–	Q7	Dingtian Q7
13	!OE	!CE	Dingtian OE

This fixes incorrect relay behavior caused by the board-specific GPIO
mapping.

Related issue (if applicable): n/a

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.8
• The code change is tested and works with Tasmota core ESP32 V.3.1.9
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[s-hadinger]

I don't like these kinds of compile time options that make overall firmware management a nightmare. This should be rather a parameter or a template option. I know nothing about MODBUS so I can't help

[baetzst]

This is not about Modbus. It is about adapting an already existing driver, xdrv_90_esp32_dingtian_relay.ino, to support the board mentioned above.

[Jason2866]

Still, the fact beeing ModBus or not. Make the feature non compile dependent would be more nice.

[meMorizE]

@baetzst

At tasmota\my_user_config.h there is already:

//#define USE_DINGTIAN_RELAY                       // Add support for the Dingian board using 74'595 et 74'165 shift registers
//  #define DINGTIAN_INPUTS_INVERTED               // Invert input states (Hi => OFF, Low => ON)
//  #define DINGTIAN_USE_AS_BUTTON                 // Inputs as Tasmota's virtual Buttons
//  #define DINGTIAN_USE_AS_SWITCH                 // Inputs as Tasmota's virtual Switches

I would suggest to add the

// #define DINGTIAN_OUTPUTS_INVERTED // Invert output states

there too and add it to the PR.

In my opion adding new pin functions as runtime-config for the existing driver is a kind of overkill.

[sfromis]

@meMorizE #define DINGTIAN_OUTPUTS_INVERTED was already exactly what baetzst suggested.

If the point is to avoid a build time setup, an existing approach for having options able to set at run time, without this taking up any code space, is to reserve a Option_A number. These are set on an unused gpio, and there are already 8 such numbers in use, up to a max of 32.

Also, there are already two SetOption bits for invert, and while these are created for a specific driver, very often it is unlikely that very different things are combined on the same hardware.
SetOption81 exists for PCF8574. SetOption133 exists for 74x595, and since this chip is already involved, it might make sense to use this option. Or are you even trying to do a similar thing in another way?

There are already cases where such numbers are reused for other setups, unlikely to be combined. These SetOption numbers are a single bit, but we still try to avoid adding a lot.

When it comes to supporting inverted pins on gpio multiplexer devices, a much more robust approach is now being used for PCF8574 and others. This is based on an extra template to assign standard component numbers (like for native gpios) to the multiplexed gpios. Of course, this is an approach for full flexibility, configured pin by pin, like maybe only inverting 2 of 4 outputs, etc. Docs already describes this here https://tasmota.github.io/docs/PCF8574/#mode-2 (but same for other multiplexers.

Not trying to say what "should" be done, merely adding some info for context. And to be clear, I don't know much about this specific case, hence some of the above may not even be a reasonable approach.

[baetzst]

@sfromis
I made some changes:

• SetOption133: Inverts 74HC595 shift register outputs at runtime
• SetOption81: Inverts 74HC165 shift register inputs at runtime
• Replaces compile-time DINGTIAN_OUTPUTS_INVERTED and DINGTIAN_INPUTS_INVERTED defines
• Uses Settings->flag5.shift595_invert_outputs for output inversion
• Uses Settings->flag3.pcf8574_ports_inverted for input inversion
• Adds debug logging to show current inversion settings on initialization

Would it make sense to remove the compile-time options entirely?

Inputs could always be treated as switches.
Buttons could then be handled using SwitchMode 3 or 4, and SetOption114 1 could be used to decouple the inputs from the relays.

This might simplify the configuration and reduce the need for different build options — what do you think?

[arendst]

The removal of this defines breaks legacy support (and current installation).

The "usual way" to handle this is adding a one time test in your new code for setting the correct SetOption based on this define.
This one time test should also set the other SetOption to it's default value before you made this change (as otherwise the legacy functionality would also be broken).

[baetzst]

@arendst How should I implement the one-time migration check? What's the recommended way to detect "first boot after flashing" so the SetOption migration from the legacy DINGTIAN_INPUTS_INVERTED define only runs once?

[arendst]

It's tricky and related to version number. It needs to be in the settings.ino file at the end.

I'll do it now based on your PR. Pls do not change anything anymore. Working on it.