Sonoff 4ch (Eachen DC in fact) on Tasmota

[Guz (Grzegorz)]

Hello, I new on that forum, started with OH2 few weeks ago.
After struggling for few evening with controlling the 4ch DC sonoff module (in fact produced by Eachen, however I bought it as a Sonoff) flashed with Tasmota I decided to ask your help. I have read many topics on mqtt setup to control sonoff. Generally it finally works for me now with one exclusion I can’t resolve up till now: the switch commanded by mqtt message or by keyboard input on Tasmota console “power1 on” switches on and in a second it switches back itself. This happenes on my two modules configured with mqtt and does not happen on the module which does not communicate on mqtt. Apart from that the modules are configured the same.
I have checked all Tasmota configuration options that seemed to relate to retention or pulse operation, eg. PulseTime (=0), SetOption65 (=1), PowerOnState (=0), SetOption0 (=0), SetOption63 (=1).
I cleared retained data on Mosquito by deleting its db, and checked that thare is no retained data on the module with mqqt-forget app.

mqtt-forget -t sonoff6260_106/#
found 0 retained topics

My OH2 version 2.5.0.M3

My things file:

mqtt:broker:mosquitto "Mosquitto" [ host="127.0.0.1", port=1883, secure=false, username="openhab", password="xxx" , clientID="Pi" ]

Bridge mqtt:broker:mosquitto "Mosquitto" [ host="127.0.0.1", port=1883, secure=false, username="openhab", password="xxx" , clientID="Pi" ]
{
    Thing topic sonoff6260_106 "Roleta1" {
    Channels:
        Type switch : Power1  [ stateTopic="stat/sonoff6260_106/POWER1", commandTopic="cmnd/sonoff6260_106/POWER1" ]
        Type switch : Power2  [ stateTopic="stat/sonoff6260_106/POWER2" , commandTopic="cmnd/sonoff6260_106/POWER2" ]
		Type number : rssi      "WiFi Signal Strength" [ stateTopic="tele/sonoff6260_106/STATE", transformationPattern="JSONPATH:$.Wifi.RSSI"]
      }
}

My items file:

Switch LivingRoom_Roleta1Up "Roleta 1 Up" <light> (gRoleta1, gMqttOut, GF_LivingRoom) { channel="mqtt:topic:mosquitto:sonoff6260_106:POWER1" }
            
Switch LivingRoom_Roleta1Down    "Roleta 1 Down" <light> (gRoleta1, gMqttOut, GF_LivingRoom) { channel="mqtt:topic:mosquitto:sonoff6260_106:POWER2" }       
Number LivingRoom_Roleta_RSSI      "WiFi Signal Strength [%d %%]"      <wifi>          (gRoleta1, GF_LivingRoom) { channel="mqtt:topic:mosquitto:sonoff6260_106:rssi" }

The Sonoff module is configured as generic (type 18).
Mqtt config page:

The other thing that I’m not sure of is that I need to link the above items to above channels in PaperUI otherwise messages are not send. Config files are not enough. However state works without the GUI link. Strange for me, however I’m new to OH, so perhaps it’s normal.
I will be grateful for any hint or idea where to look for.

[rossko57]

Make sure you don’t have simple mode set (creating extra Items to conflict with your manually added ones)

[Guz (Grzegorz)]

Yes, the simple mode is off.

Regarding the auto return of the relays I noted in Tasmota console on debug level, that the module was self triggering multi-press of a button continuously, twice a second, for ca. 2 minutes, mostly with the button which was really pressed, but random presses of other buttons were also included. Eg. below I pressed button 1:

23:09:02 APP: Button1 multi-press 1
23:09:02 SRC: Button
23:09:02 MQT: stat/sonoff6260_106/RESULT = {“POWER1”:“ON”}
23:09:02 MQT: stat/sonoff6260_106/POWER1 = ON
23:09:03 APP: Button1 multi-press 1
23:09:03 CFG: Saved to flash at F8, Count 14, Bytes 4096
23:09:03 APP: Button1 multi-press 2
23:09:04 APP: Button1 multi-press 1
23:09:04 APP: Button1 multi-press 1
…repeated
23:11:28 APP: Button1 multi-press 1
23:11:29 APP: Button1 multi-press 2
23:11:29 SRC: Button
23:11:29 MQT: stat/sonoff6260_106/RESULT = {“POWER1”:“OFF”}
23:11:29 MQT: stat/sonoff6260_106/POWER1 = OFF
23:11:29 APP: Button1 multi-press 1
23:11:30 CFG: Saved to flash at F7, Count 15, Bytes 4096
23:11:37 WIF: Checking connection…
23:11:37 WIF: Connected
23:11:57 WIF: Checking connection…
23:11:57 WIF: Connected
23:12:10 SRC: Button
23:12:10 CMD: Group 0, Index 1, Command “RESET”, Data “1”
23:12:10 MQT: stat/sonoff6260_106/RESULT = {“Reset”:“Reset and Restarting”}
23:12:11 CFG: Use defaults

Finally the module made the reset and restart itself.
Perhaps it’s a Tasmota’s bug or my misconfiguration of the module.

[rossko57]

@Guz

the module was self triggering multi-press of a button continuously

That sounds like the sort of thing you get with floating inputs, missing pull-up resistors kind of thing.

[Guz (Grzegorz)]

I have found explanations (partial) for both troubles.

1. self triggering of buttons occurs when the module is either inching or pulse mode. It is not described clearly in the manual but by pressing the 5th button the mode can be switched. And when the module is switched to a simple mode the relays behave normally, stable. In other modes some logic other than ESP is trying to trigger the button. There is an additional cpu on the board and I guess it is influencing the buttons. So, by trial and error I have switched the module and no ghost triggering appears any more.

2. Link between channel declared in the things file and this channel used in items file can be established by using the config files without Paper UI. Simply ensure the exact match of topic name in both files. I had lower case Power1 in things file and uppercase POWER1 in items file. Didn’t know this is a critical mismatch.

I have also flashed ESPEasy v. 120 on the module, but I encountered difficulties to use GPIO9 for the relay no. 2. Tasmota 6.6 or 6.7 has worked better so once I noticed the above solution I have reverted to Tasmota. Tasmota works with the configuration as below.

The wiring for flashing is pretty easy, no soldering needed.

For now, issue is closed for me.

[HounD]

I know this is a bit off topic but I need your help.

I tried the connections as you have indicated on my board but I simply cannot flash any firmware to it. Can you think of any thing I am missing? I am not even picking up the chip. I see TX attempts but no RX from what I can tell…

[Guz (Grzegorz)]

It’s difficult to say what you may be doing wrong reading a very general message. But perhaps the chip is not put into programming mode. Make sure K1 is connected to COM at least when powering up the module. Ie. keep K1 to COM with a whatever piece of wire and power up the module. After few seconds you may diskonnect K1 or keep it shorted to COM.
At the beginning I had to try few times to set up terminal app to talk to the module, mainly b’cause I’m on macos.
Are you sure your comms module is set to 3.3V?

[rpwong (Russ)]

@HounD: To protect your privacy, I recommend that you change your display name so that it’s not your email address.