ESP32 and 74HC165 and TASMOTA Berry setup or driver

[hhorigian]

Hi Everyone - I came here as a suggestion of another member.

I have a board with a 74HC565, 74HC165 and ESP32.
565 is running after compiling and having enabled SHIFT565, perfect and thanks for everyone that contributed for that driver.

Now - I need to make the 74HC165 work with TASMOTA. As it is not natively supported, I would like if possible some help (I do not have any scripting knowledge, though I have been last 48hrs trying to learn Berry and figure to do this on my own before coming over here and asking for help).
They suggested this other article: https://www.reddit.com/r/esp8266/comments/6d979i/problems_connecting_74hc165_piso_shift_register/
but honestly I did not understand much.
Any help on how to add this via Berry script to my board, I would really appreciate it.
The board documentation on github link: https://github.com/dtlzp/relay-dev-demo/tree/main/gpio/main

Any ideas?
Thanks!!

sn74hc165.pdf

[barbudor]

Before having a native HC595 driver, the 1st one was written in Berry
You will find the code here: https://github.com/arendst/Tasmota/blob/development/tasmota/berry/drivers/Shift595.be
That can give you some ideas

However I assume that, the HC165 would be used for input ?
If this is the case, just forget anout using that for Button or Switches
But you can create JSON events like in the PCF8574 or MCP230xx drivers that can be published to MQTT or by Rules
Or just do anything proprietary

Hope this helps

[barbudor]

Thanks
So the 2nd test confirm there is a bad interaction between. The 595 and the 165
I will double check his code but I don't understand how this could work
If needed, can you put me in touch with the vendor?

By the way, your FullTopic is out of specs. It should include both %prefix% and %topic%
As you have none, I don't know how the mqtt integration could work and if tasmota can receive properly commands. I see a risk of loops while tasmota publishes something that it interpret back as a command
It may be the reason why you don't get the CHG messages

I won't be able to make more progress today. I'll be back on this tomorrow evening

[hhorigian]

Thank YOU!

Of course I can share his contact, the website of the vendor is: https://www.dingtian-tech.com/en_us/index.html.
I talk with him via wechat, as in china is the most used app, wechatid: l404288892.
If you use whatsapp, you will find his contact in the website, his name is Stephen.
Hope he explains something, but for what I tried - he won't explain much, and will refer you to the code in his repo. But hopefully you have better luck.

Btw. I will fix the FullTopic. tks.

Let me know when you have any news! Waiting anxious! Thanks ONCE AGAIN!!!!

[barbudor]

I've sent an email to Stephan, you are in copy
Let's see what he says

Personnaly I pretty sure that the problem is related to GPIO32 controlling both the tri-state output of the 595 and the latch of the 165.
For me, the /OE pin of the 595 should not be connected to a GPIO (at least not the same as PL) and should continuously connected to GND to insure proper continuous output of the 595.

It may be possible that doing the driver in C is faster and would not show the problem. As you can see on the diagram, PL is high for 1,5ms. I may need to rewrite the driver in C.

Alternatively a change of the hardware, disconnecting pin 13 (/OE) of the 595 from the GPIO and connecting it directly to GND, would be my prefered solution. However I can understand that if you plan to use that in a professional environment, especially if you plan to use many boards, this is not an option.

[hhorigian]

Hi - I saw your dedicated and long email to him and cc me.
I just messaged him over wechat and asked please to check and requested someone from his technical team to please try and help us understand your doubts and concerns. Let's see.

My idea was to make the 8 channel work with Tasmota first - once I had it running, I was going to do the same with the 16 and 32 channel boards they have, and start offering those boards here already flashed with Tasmota ready (many boards project). So the hardware route might not be the best one I believe as it might be not only risky (my knowledge is not as much to do that), and the time and quantity would not be an option. Hopefully we can figure something out before that !
Hope you have a good night and let's wait for his reply.
Thanks!

[barbudor]

Hi
So we had an response that Read and Write should be done simultaneously
As I fear that speed is also a concern I will rewrite the driver in C, following his/her advice of managing R+W in the same call
Unfortunately I won't be able to work on that before the week-end

Are you using a standard binary for tasmota32 ? Or are you building/compiling your own ? If compiling, are you doing that with VSCode/Gitpod or using TasmoCompiler ?

[hhorigian]

Hi,
Yes, I talked to him over wechat and he finally helped!!
You are the expert, so whatever you suggest is what we will do.

I compiled my own as I needed the #define USE_SHIFT595. I used GitPod.

Let me know how can I help, somehow.

[barbudor]

Here is my fork with the Dingtian native driver (branch dingtian_driver): link removed
If you want a quick test, here is a tasmota32.bin compiled with the driver in it: tasmota32-dingtian.zip (link removed as driver is now part of Tasmota)
Otherwise, pull my fork and compile with #define USE_DINGTIAN_RELAY (you don't need USE_SHIFT595 anymore)
Configuration is as below: for the 8-relay board


template:

{"NAME":"DingtianRelay","GPIO":[1,1,1,1,1,1,1,1,1,9632,9600,9728,9664,1,1,1,0,1,1,1,0,1,1,1,0,0,0,0,9696,1,1,1,1,0,0,1],"FLAG":0,"BASE":1}

The index (1..4) on the right of CLK is the number of shift registers (1 for the 8-relay board, 2 for 16, 3 for 24 and 4 for 32 relays)

Web GUI :

SENSOR message at Teleperiod:

21:46:07.760 MQT: sonnaz/esp32dev3/tele/SENSOR = {"Time":"2022-10-29T21:46:07+02:00","DINGTIAN":{"IN1":1,"IN2":1,"IN3":1,"IN4":1,"IN5":1,"IN6":1,"IN7":1,"IN8":1}} (retained)

Message on change of input:

21:46:50.665 MQT: sonnaz/esp32dev3/tele/DINGTIAN_CHG = {"Time":"2022-10-29T21:46:50+02:00","DINGTIAN_CHG":{"IN1":0,"IN2":0,"IN3":0,"IN4":0,"IN5":0,"IN6":0,"IN7":0,"IN8":0}}

You can have rules trigger on an input change such as

on DINGTIAN_CHG#IN1 do POWER1 %value% endon

I still have to do some tests with the real 595 and 165, but if you have access to your board during the week-end you may have tested that before I do

[hhorigian]

Hi!! There are definitely no words to thank you enough!!!
I went to the office yesterday night just to get the board, and today morning flashed with your bin.
And this time, it worked PERFECT! All the inputs and relays are working, adding a rule on nthe change, worked perfect too.
The mqtt is working excelent too! Tested on home assistant via mqtt on manual rules, and I'm controlling the board 100%.
I will try the ethernet port tomorrow as I don't have anything to test here.
Again, don't know how to thank you for all your time, effort, and help on getting this working.
THANK YOU.

I will receive a 16 and 32 port board this week, and try to flash and based on your instructions on the index (1...4).

[barbudor]

Super cool you went to the office on a weekend.
And super happy that it is working. Should have gone this way from the beginning

I'll let you test a little more and will PR to Tasmota around mid week

[barbudor]

A few comments:

• Polling of inputs and setting the relays is performed every 250ms. This function is called here:
  https://github.com/barbudor/Tasmota/blob/f861e8330a8ee314573cb0e1a5c01063f35ee54d/tasmota/tasmota_xdrv_driver/xdrv_90_dingtian_relay.ino#L189-L192
  => If you think the inputs are not reactive enough (too much delay from activation to action), you can change the comments like below:

      case FUNC_EVERY_50_MSECOND:           // <= uncomment for more reactive inputs
      //case FUNC_EVERY_250_MSECOND:      // <= comment if you uncomment above line
        DingtianLoop();
        break;

• If you are ok with the inputs but you find the relay not reactive enough, you can try to uncomment the last line of this function:
  https://github.com/barbudor/Tasmota/blob/f861e8330a8ee314573cb0e1a5c01063f35ee54d/tasmota/tasmota_xdrv_driver/xdrv_90_dingtian_relay.ino#L135-L141

void DingtianSetPower(void)
{
  // store relay status in structure
  Dingtian->outputs = (XdrvMailbox.index >> Dingtian->first) & ~(0xFFFF << Dingtian->count);
  //AddLog(LOG_LEVEL_DEBUG_MORE, PSTR("DNGT: outputs=0x%08X"), Dingtian->outputs);
  DingtianLoop();     // <= Uncomment for more reactive relays
}

[barbudor]

Hi @hhorigian
How is your testing so far ?
Are you happy ?
Nothing to change ?
Can I PR this into Tasmota ?

[DaniilMir]

@barbudor Thank you for your efforts in implementing this tasmota extension.
I ordered 4 and 8 relay boards to integrate them with homeassistant.
Unfortunately the 8 relay board is failing with a firmware tasmota32-dingtian.zip
It throws the following error in the console log :

`rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)

flash read err, 1000

ets_main.c 371

ets Jun 8 2016 00:22:57`

It looks like something is incompatible with this board.
Chip is ESP32-WROOM-32D

[Jason2866]

Changes will be "in" the next Tasmota Core release.
Until that time the described changes in platformio_override.ini are needed.
This is no problem, since it is all the same, just the additional PHY driver is added.

[hhorigian]

@Jason2866 Thank you very much !!!!! It worked now. I grabbed the latest develop branch, configured Platformio as per your advise and now it is working just great with Ethernet connection. Template : {"NAME":"DingtianRelay","GPIO":[5536,1,1,1,1,1,1,1,1,9760,9728,9856,9792,1,5600,1,0,1,1,5568,0,1,1,1,0,0,0,0,9824,1,1,1,1,0,0,1],"FLAG":0,"BASE":1,"CMND":"EthClockMode 3|EthType 7,EthAddress 0"}

Hi @DaniilMir - does your Ethernet "LINK" Led turn on? I got everything working too, with your and @Jason2866 awesome help, but the Ethernet LINK led does not turn on, only the status traffic led blinks. Let me know when you have a chance?
Thanks!

[DaniilMir]

@hhorigian Just checked it - I have only green LED blinking. Orange is not.

P.S.
Router says that link is 100M-Full

[Jason2866]

@DaniilMir Latest development uses a updated core. The new core supports now this PHY too. No need to use an different framework build. Standard development precompiled firmwares are now working.

[DaniilMir]

Latest development uses a updated core. The new core supports now this PHY too. No need to use an different framework build. Standard development precompiled firmwares are now working.

Yesterday I had a chance to test it.
It worked with Tasmocompiler.
The only thing was to delete docker container and re-load it. Update source code did not work.

[Jason2866]

@hhorigian The way to include is described above. It only makes sense to do for someone who can test the changes. I don’t have the device. Can’t buy everything ;-)

[DaniilMir]

@hhorigian @barbudor
Did you have any relay noise ?

I just tested bot options with FUNC_EVERY_250_MSECOND and function FUNC_EVERY_50_MSECOND
there is a silent clicking noise when a relay is on.
It may even be measured on the relay contacts :

Adding a 2-10 uF capacitor in parallel with relay coil helps to fix it.
I'm wondering if we can fix it programmatically.

[barbudor]

@hhorigian @barbudor Did you have any relay noise ?

I just tested bot options with FUNC_EVERY_250_MSECOND and function FUNC_EVERY_50_MSECOND there is a silent clicking noise when a relay is on. It may even be measured on the relay contacts :

I don't have the hardware so I can't hear anything 🤣

What are you exactly showing ? Which signal ? Is that the output of the 595 ?
Where is the GND level on your capture ?
Which board do you have 8 ? 16 ? 32 ?

From my point of view those boards have a great design flaw as the 595's OE pin is connected to the same signal as the 165's PL
As we have to drive the PL pin high in order to sample the Inputs and shift them in, the OE pin of the 595 are in tr-state/floating during htat time.
It would be interresting to see on the same capture an output of a 595 and the the GPIO connected to PL/OE

Take care of having proper grounding because your signals seems to damaged to be true.

[DaniilMir]

@barbudor My bad. I should be more specific.
Signal was captured at the transistor - relay connection.
There is a noise because I'm using an unshielded AUX cable and an external audio card to capture the signal.
Board is 8X

[DaniilMir]

@barbudor I gave up on fighting with this noise.
Since I don't need the inputs section - I just complied a new firmware with Ethernet and #define USE_SHIFT595
When use outputs only - there is no noise at all

GPIO13 -> 74x595 SER
GPIO14 -> 74x595 SRCLK
GPIO15 -> 74x595 RCLK
GPIO32 -> 74x595 OE

[barbudor]

Hi @DaniilMir

The pure '595 driver do not change the stats of the OE pin, it remains alway LOW.
As I explained, I believe there is a design error in this board and that the '595 OE should NOT be connected to a GPIO, and especially not to the one that we need to put High to read the inputs.

One workaround is to desolder the OE pin of the 595 and connect it directly to GND

@hhorigian Do you have any noise like DaniiMir ?

[barbudor]

@DaniilMir @hhorigian
I have now added support for Virtual Buttons/Switches in the Dingtian driver
So Inputs can be used as Buttons or Switches with full support as the native Buttons/Switches
See PR : #18223

[hhorigian]

Wow @barbudor !! That's an Amazing change!!
I am at the airport and read your post! I will definitely try it next week when get back to the office!

Thanks for that!
Cheers!
(I willl send you the update on how did it go).

[barbudor]

That was easy once Theo has implemented everything that was needed to support Virtual Buttons and Switches

[hhorigian]

Thanks to @arendst as always, and you too!

[hhorigian]

Hi @barbudor @Jason2866 how are you!
Today I got back to this project.
I just compiled a new .bin to try the native buttons and switches.
I can confirm is working perfect!!! Thanks @barbudor !
The only thing, for some reason my ethernet is not working - now i got lost in our message exchange about the PHY driver if it's included in this development or not, or should add the framework build.
Can you let me know? And if it's included what might be wrong in my compile or what should be checked to include that driver?
Thanks!

BTW:
I am using the Development 12.4, and settings using
EthClockMode 3|EthType 7,EthAddress 0

[stefdewilde]

@hhorigian I assume you did this with a Dingtian that wasn't preprogrammed?

[hhorigian]

Hi @barbudor - how are you so long?
I am coming back to this project, and decided to compile new bins.
One for each model of board (8ch, 16ch, 32ch), with the templates ready, and even pre-configured if will be using Switch or Buttons.

The issue that I am having:
I am getting a fresh development file, and just adding the
#define USE_DINGTIAN_RELAY
#define DINGTIAN_USE_AS_BUTTON

Everything else is as default.
But compiling (always using gitpod), tasmota32, I get the bin created, and after sending to the board - the board gets into a loop, as the bin did not work. Even removed the Dingtian definition, and same thing when uploading the fw. But the board runs ok if I upload via web installer, development esp32. What might me going on? Any thoughts?

Thanks!

[sfromis]

How exactly are you "sending to the board"? For wired flashing of ESP32, you need to use the .factory.bin file from the build, for upgrade via the web UI or Tasmota command, you need to instead be using the .bin file.

[barbudor]

My 2c : The lazy method:

• Install standard tasmota32 using Web installer (select erase flash)
• configure wifi
• upgrade to your custom build using "Upgrade by file upload" (tasmota32.bin, not factory.bin)
• let the magic happen
• finalize the configuration

[hhorigian]

How exactly are you "sending to the board"? For wired flashing of ESP32, you need to use the .factory.bin file from the build, for upgrade via the web UI or Tasmota command, you need to instead be using the .bin file.

@sfromis Used to do this a couple of months ago, I don't know if some config file changed.
After compiling with Gitpod (platformio run -e tasmota32), downloading the tasmota32.bin, and uploading OR
a) Via ESPHOME Flasher via USB Tool

• Here it keeps in the infinite loop if I see the serial(usb) log.
  b) Or even after installing as @barbudor sugested. Having Tasmota running, and then upgrading firmmware file tasmota32.bin via web, it fails.
  There is something in the compile (even it runs ok) - that is not compatible with the ESP32 of the Dingtian board or some setting missing I believe (which I had before when doing this same process). But the regular build or development build is actually uploading just fine.

As we send the boards ready to the customers, I would like to create a bin file to upload to the boards with template ready and setup ready to plug and be welcomed to setup wifi, etc as a new board.

[sfromis]

Do check serial logs during the boot loop, especially at the start. And if you used tasmota32.bin for wired flashing, that's a fail.

[Jason2866]

a) Via ESPHOME Flasher via USB Tool

Do not use tools made for other projects for flashing Tasmota. Most of the time this ends in problems

[Jason2866]

Download the *.factory.bin and flash it for example with my Web Flasher by drag and drop in the firmware update area. That's all.

[hhorigian]

@barbudor @Jason2866
I am working with a Dingtian Board, 16ch, already with V2 of the board (3.6.1, with OE instead of PL).
Working Ok with Tasmota, everything perfect showing via web control.

I enabled the Hue Bridge, for Alexa integration. Alexa discovers 15 channels, and controls perfectly 15 channels, but never discovers channel #16. Tried to remove all, changed names, reset the board and names, included in another amazon account. Always the same result: Channels 1 to 15 added ok, but channel 16 is left out as it didn't exist, but it shows in tasmota web control, tasmota api, mqtt. Only Alexa integration is not picking it up.
Any ideas?

[barbudor]

I never dig into Hue/Alexa so I can't tell if there is a limit to 15 but what happens if you configure the driver for 24 I/O?
Are you still limited to 15 or up to 23?

[hhorigian]

Hi @barbudor - I did a test with your idea, and setup the the clck for 24 i/o.

Alexa is still recognizing the 15.
Though all the documentation online, they mention the limit is for 50 for Hue - so there might be something going on between the Hue Bridge emulation inside Tasmota and Alexa? Do we have any variable there or any limits inside the emulation?

[s-hadinger]

Detail of encoding is here

Tasmota/tasmota/tasmota_xdrv_driver/xdrv_20_hue.ino

Line 626 in b5d1109

// Bits:

Hue Emulation supports up to 31 (or maybe 32) relays

[hhorigian]

So what do you think can be the problem @barbudor ? Any ideas?

[barbudor]

@hhorigian I think if you can locally change that value to 32 and compile your binary, then report after some tests
If you confirm it to be working, we may change that in the code base

[hhorigian]

Once again @barbudor you are THE MAN!!
Tried first with MAX_HUE_DEVICES = 16, as my board is 16ch, so did't want to force it.
Alexa recognized the 16 lights perfect.
Then tried increasing MAX_HUE_DEVICES = 32, and tried with same results, everything is performing ok until now.
I will try to do the same test with MAX_HUE_DEVICES = 32, and upload to a 32ch board, and see how it responds, and bring feedback so we can have that documented here too. If @s-hadinger agrees, and there is no known reason, I believe it is safe to change the value to at least 32 in a future code base.
Thanks again @barbudor !

[barbudor]

@hhorigian is everything OK with the change?
Is that OK I push a PR?

[hhorigian]

Hi @barbudor
Worked perfect
You can push a PR.

[barbudor]

Done : #19820

[hhorigian]

Hi @barbudor - I have been testing all day the board.
Apparently is ok - but I noticed it's responding really slow to commands via web, and even tried some commands over console and it's sluggish or even not accepting the commands. It even reseted 2x.
I believe the tasmota file is too big for this board (and I don't need even half of all the amazing features for this project, just basic hue and web integration).
Though look:

I Followed your advice. Flashed tasmota32 via webinstaller, then compiled a new version (removing everything I didn't want, adding the Dingtian relay definition, the hue limitation change), and upgraded using "Upgrade by file upload" using the compiled tasmota32.bin from gitpod I compiled.
Anything I might do to reduce this?

Thanks!

[Jason2866]

Have you tried without mDNS? I have that in none of my builds. It is by design a mess. The use case is not performance hungry. Never tested Hue Emulation with such many Relais. Maybe it scales not nice?

[hhorigian]

HI @barbudor how are you! Hope you are doing well!
Still working with these boards.

I discovered an issue, that only happens when I flash with Tasmota (does not happen with their original firmware).
Let me try to explain and show the setup.
8CH Board (8 input / 8 output).
Tasmota Dev. 13.3.0.1 running, perfect.
Enabled:
#define USE_DINGTIAN_RELAY
#define DINGTIAN_USE_AS_BUTTON (as I am using momentary buttons, like doorbell, even for testing using one cable touching the other).
Switchmode 0 (default)

Normal function via Web, Turning On/Off - on all relays. Response ok.
The issue comes when doing a manual toggle via the input.
The FIRST time I toggle the input, there is no reaction on the relay. I need to toggle again to the relay do the toggle. After that, I can do toggle as many times I want, that it works ok. If you leave the input with "inactivity" for a couple of minutes, the situation repeats, the first toggle doesn't work, but the second and every other one after does. Is like there is a "Sleep" (sounds crazy) but it activates the input and the toggle.
This does not happen if you use "DINGTIAN_USE_AS_SWITCH" with mechanical toggle switches. It behaves ok.

Any ideas?
Thanks!

[hhorigian]

Discovered via the debug.

22:24:56.262 BTN: Button1 multi-press 1
22:24:56.708 CFG: Saved, Count 33, Bytes 4096
22:25:36.845 RSL: RESULT = {"Reset":"Reset and Restarting"}
22:25:37.455 CFG: Use defaults

1. It was being considered as a "multi-press 1"
2. For some reason is resetting the board and restarting.

[sfromis]

When a Button input is registering as "pushed" for 40 seconds, this triggers a Tasmota recovery feature to force a board reset. Assuming that you are not doing the pushing, that implies either that there is something bad about how that input is connected, or the Button should've been defined as Button_i for "inverted" instead of Button (or vice versa).

[hhorigian]

@sfromis - Yes, that was a cable doing the problem for the pushed. Solved.

After changing to:
SetOption11 0
SetOption13 1

The Setoption13 solves the problem, definitely.
But discovered that after some time, there is something changing the "SetOption13" back to OFF.

[sfromis]

If you enable Weblog 3, you can get an indication of where the command is coming from.

Anyway, if the "problem" is the 40-second push, using SetOption13 is not really any solution, as the Tasmota design around an input configured as a "Button" is that it is a momentary push, not staying engaged for longer than you push it. Of course SetOption13 can still make sense, if you do not want to use the multi-press or long press features.

[barbudor]

Your device needs an exorcists 🤣
With Weblog 3 you could see if a command changes that

Regarding your initial problem with Buttons which lead you to use Setoption13, there's may be an issue with the the type of button generated by the driver (non-inverted vs inverted)

Could you please try a binary with neither AS_BUTTON/AS_SWITCH (the old mode)
And provide me with a screen shot of the main web page when no buttons are pressed
and/or a copy of the sensor message
If the value are all "1" for the inputs, you need to add in your user_config_override.h

#define DINGTIAN_INPUTS_INVERTED

At rest, inputs should be 0

[hhorigian]

LOL!
@barbudor you were right, once again!

The "#define DINGTIAN_INPUTS_INVERTED" was not enabled !
That solved the issue!

Thanks!! Have a nice christmas.

[hhorigian]

Hi @barbudor ! How have you been!? Hope everything is well!

As usual, working with the Dingtian boards. It's been a long time since I don't setup Tasmota in one of them, and this time I got a new batch. I am trying to setup a 32CH board with Tasmota.

The problem: Relays are not switching on/off PHYSICALLY, nothing is happening on the board. No relays are being activated, though in the console and in the web interface, everything looks ok when switching on/off.
The amount of Relays, show ok on the web console and console.

I did a custom bin firmware for it using a development branch, but as usual.
Enabling Dingtian Relay and type of Buttons mainly.

#define USE_DINGTIAN_RELAY
#define DINGTIAN_USE_AS_BUTTON

Here are some console logs.

17:58:13.256 RSL: STATUS = {"Status":{"Module":0,"DeviceName":"Dingtian","FriendlyName":["MolSmart","MolSmart2","MolSmart3","MolSmart4","","","",""],"Topic":"MolSmart_7EF8A4","ButtonTopic":"0","Power":"00000000000000001110000000101100","PowerLock":"00000000000000000000000000000000","PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0,"StatusRetain":0}}
17:58:25.854 CMD: state
17:58:25.865 RSL: RESULT = {"Time":"2024-10-14T17:58:25","Uptime":"0T00:01:42","UptimeSec":102,"Heap":124,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":39,"MqttCount":0,"Berry":{"HeapUsed":4,"Objects":45},"POWER1":"OFF","POWER2":"OFF","POWER3":"ON","POWER4":"ON","POWER5":"OFF","POWER6":"ON","POWER7":"OFF","POWER8":"OFF","POWER9":"OFF","POWER10":"OFF","POWER11":"OFF","POWER12":"OFF","POWER13":"OFF","POWER14":"ON","POWER15":"ON","POWER16":"ON","POWER17":"OFF","POWER18":"OFF","POWER19":"OFF","POWER20":"OFF","POWER21":"OFF","POWER22":"OFF","POWER23":"OFF","POWER24":"OFF","POWER25":"OFF","POWER26":"OFF","POWER27":"OFF","POWER28":"OFF","POWER29":"OFF","POWER30":"OFF","POWER31":"OFF","POWER32":"OFF","Wifi":{"AP":1,"SSId":"2G_TRATO","BSSId":"60:22:32:57:32:1D","Channel":6,"Mode":"HT40","RSSI":100,"Signal":-33,"LinkCount":1,"Downtime":"0T00:00:05"}}

[barbudor]

Hi @hhorigian
nice to see you back

Unfortunately it's hard to diagnose without hte board.
I would suspect a change in the schematics which is using different GPIOs
May be you should ask them

If you have an oscilloscope, you could try to see if the signal are changing on the pins of the 74HC595
If I remember correctly, the read+write cycle is performed continuously so you should see activity on the clock and the ohter pins
If you set 1 output on every 2 output, you should also see a clock-like signal on the data pins

You can also try to use an continuity tester/ohmmeter to check for the continuity between the ESP32 GPIO (is reachable) and the 74HC595

[hhorigian]

Hi !!! @barbudor
I have been doing all kind of tests, with older versions, and even talked with them - nothing changed.
I don't have good tools to do that kind of testing unfortunately - but I was able to figure something out.

The 32CH board, needs to be set up with DINGTIAN CLK = 4 in GPIO14.
When doing that, it correctly shows in the web interface, and console, the 32 relays/inputs, but no effect when turning on/off.
Though - if for example, I set up the DINGTIAN CLK = 3 in GPIO14, I get some relays working (completely wrong order, but they work), and only showing 24 relays in web interface.
So apparently there is something missing or we are not considering in the in tasmota development driver/function for Dingtian when using the 32CH = 4CLK.

Can we check that?

[barbudor]

I see actually 2 versions of the 32CH board here:
https://github.com/dtlzp/relay_dev_demo/blob/main/gpio_pinout/32ch.png
https://github.com/dtlzp/relay_dev_demo/blob/main/gpio_pinout/32ch_v2.png

From a quick look it seems the only difference is tha GPIO0 is no more connected to 74HC165's SH/LD pins
That should not impact the relays however but I wonder how the inputs can work reliably if it is no more possible to latch the inputs before shifting.

I don't have much time to spend on Tasmota these days and without the board in hand, it's hard to make a real analysis.
I wil try to have a look again to the code but I can't promise you much

[hhorigian]

Hi my friend.
In the last months, we were able to use Tasmota in the old version of Dingtian boards, and in the v2 boards too. Always in 4, 8 and 16channel boards. Even the 16ch v2 runs ok (v2 has PL in GPIO0 ).

I talked to Dingtian guys last week -
They mention that there were no changes in the board.
And that the 16 and 32ch boards are the same, just change the number of clcks, so it should work the same.

We even tried to download tasmota in an OLD 32ch (v1), but the result was the same - could not control the relays.

Whenever you have some time - can you check if there is anything in the code that would change for the 32CH specially?
Let me know if I can help somehow.

Thanks as always!

[hhorigian]

Hi @barbudor and team! How are you! Hope you have a great 2025!

I have a really wired behavior with Dingtian boards 16CH.
I am creating a new build from development branch, and just enabling the Dingtian setup, to make sure there is nothing else conflicting:

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

Everything is working perfect except Alexa Hue integration.

Alexa seems to recognize some devices, but not all of them. Seems that the problem is on the NAMING when sent to Alexa, for what I can see in the Console.
I believe that the ones that are not getting any names " ", are not being named in Alexa, maybe? Where is that name being pulled from in Tasmota? AS dome are being brought from the Friendly names, other are made up, as from the console you can see the "-6" name.

Did anything change on the emulator
Any ideas?

Thanks!