Obi 2 - Random Toggle at Startup

schuenep commented 5 years ago

Describe the bug I've got Tasmota running on Obi Socket version 2. Currently I am using (as suggested) version 6.4,1.6 compiled against 2.5.0-beta2 core (directly from http://thehackbox.org/tasmota/020500/). I often had wifi/Mqtt disconnects using the current release version. The below described behavior is the same as in the current release version.

Default behavior at startup by default is "Turn relay(s) on as last saved". This however is inverted: If the socket was on before it is off afterwards and vice versa. Even if I set PowerOnState to 0 or 1 the behavior is inverted. I do not have retained messages in the mqtt broker.

What I noticed is that the Relais immediately turns on if I connect power and half a second afterwards it switches to the "final" state as described above. I think this should not happen and maybe is a hint on the error which (maybe) does only appear on the "new" Obi 2 socket.

I did not have a look in the code yet as I am fairly new to this project and the hardware.

Note: I set PowerOnState to 1 for now, as this keeps the socket off by default.

17:11:47 MQT: stat/FernseherTest/STATUS = {"Status":{"Module":18,"FriendlyName":["Fernseher"],"Topic":"FernseherTest","ButtonTopic":"0","Power":0,"PowerOnState":1,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":1}}
17:11:47 MQT: stat/FernseherTest/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/020500/sonoff.bin","RestartReason":"Power on","Uptime":"0T00:01:35","StartupUTC":"2019-01-05T16:10:12","Sleep":50,"BootCount":73,"SaveCount":395,"SaveAddress":"F4000"}}
17:11:47 MQT: stat/FernseherTest/STATUS2 = {"StatusFWR":{"Version":"6.4.1.6(4135100-sonoff)","BuildDateTime":"2019-01-05T17:12:16","Boot":31,"Core":"2_5_0_BETA2","SDK":"3.0.0-dev(c0f7b44)"}}
17:11:47 MQT: stat/FernseherTest/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["42",""],"TelePeriod":300,"SetOption":["00008029","55C180C0","00000000"]}}
17:11:47 MQT: stat/FernseherTest/STATUS4 = {"StatusMEM":{"ProgramSize":547,"Free":456,"Heap":20,"ProgramFlashSize":1024,"FlashSize":2048,"FlashChipId":"XXXXXX","FlashMode":3,"Features":["00000809","0FDAE794","000383A0","23B617CE","00003BC0"]}}
17:11:47 MQT: stat/FernseherTest/STATUS5 = {"StatusNET":{"Hostname":"FernseherTest-2272","IPAddress":"192.168.178.52","Gateway":"192.168.178.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.178.1","Mac":"XX:XX:XX:XX:XX:XX","Webserver":2,"WifiConfig":4}}
17:11:47 MQT: stat/FernseherTest/STATUS6 = {"StatusMQT":{"MqttHost":"raspberrypi","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_XXXXXXXX","MqttUser":"foobar","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
17:11:47 MQT: stat/FernseherTest/STATUS7 = {"StatusTIM":{"UTC":"Sat Jan 05 16:11:47 2019","Local":"Sat Jan 05 17:11:47 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+01:00","Sunrise":"08:43","Sunset":"17:07"}}
17:11:47 MQT: stat/FernseherTest/STATUS10 = {"StatusSNS":{"Time":"2019-01-05T17:11:47"}}
17:11:47 MQT: stat/FernseherTest/STATUS11 = {"StatusSTS":{"Time":"2019-01-05T17:11:47","Uptime":"0T00:01:35","Vcc":3.462,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"OFF","Wifi":{"AP":1,"SSId":"foobar","BSSId":"XX:XX:XX:XX:XX:XX","Channel":6,"RSSI":90}}}

To Reproduce Use a Obi 2 socket in default configuration, switch it on, unplug and replug it.

Expected behavior Relais state is the same as before.

ascillato commented 5 years ago

Hi

Please, go to the console and type weblog 4 for more debug information. Then restart your device and post all what is coming from your console.

There you will see SRC: MQTT or SRC: SWITCH to see where your turn on is coming from.

schuenep commented 5 years ago

Ok, I'll have a look tomorrow, thanks.

schuenep commented 5 years ago

Hi,

seems like the device detects multi-press on the button..? Note: I switched Poweronstate to 3 again beforehand.

00:00:00 CFG: Loaded from flash at FB, Count 420
00:00:00 SRC: Restart
00:00:00 Project sonoff Fernseher Version 6.4.1.6(4135100-sonoff)-2_5_0_BETA2
00:00:00 APP: Button1 multi-press 1
00:00:00 WIF: Checking connection...
00:00:00 WIF: Attempting connection...
00:00:00 WIF: Connecting to AP1 foobar in mode 11N as FernseherTest-2272...
00:00:00 SRC: Button
00:00:00 RSL: stat/FernseherTest/RESULT = {"POWER":"OFF"}
00:00:00 RSL: stat/FernseherTest/POWER = OFF
00:00:00 CFG: Saved to flash at FA, Count 421, Bytes 3584
00:00:01 WIF: Checking connection...
00:00:01 WIF: Attempting connection...
00:00:02 WIF: Checking connection...
00:00:02 WIF: Attempting connection...
00:00:03 WIF: Checking connection...
00:00:03 WIF: Attempting connection...
00:00:04 WIF: Checking connection...
00:00:04 WIF: Connected
00:00:04 HTP: Web server active on FernseherTest-2272 with IP address 192.168.178.52
00:00:04 UPP: Multicast (re)joined
00:00:05 HTP: Main Menu
00:00:06 UPP: Multicast disabled
00:00:06 MQT: Attempting connection...
00:00:06 MQT: Connected
00:00:06 MQT: tele/FernseherTest/LWT = Online (retained)
00:00:06 MQT: cmnd/FernseherTest/POWER = 
00:00:06 MQT: Subscribe to cmnd/FernseherTest/#
00:00:06 MQT: Subscribe to cmnd/sonoffs/#
00:00:06 MQT: Subscribe to cmnd/DVES_XXXXXXXX_fb/#
00:00:06 MQT: tele/FernseherTest/INFO1 = {"Module":"Generic","Version":"6.4.1.6(4135100-sonoff)","FallbackTopic":"cmnd/DVES_XXXXXXYX_fb/","GroupTopic":"sonoffs"}
00:00:06 MQT: tele/FernseherTest/INFO2 = {"WebServerMode":"Admin","Hostname":"FernseherTest-2272","IPAddress":"192.168.178.52"}
00:00:06 MQT: tele/FernseherTest/INFO3 = {"RestartReason":"Power on"}
00:00:06 MQT: stat/FernseherTest/RESULT = {"POWER":"OFF"}
00:00:06 MQT: stat/FernseherTest/POWER = OFF (retained)
00:00:06 UPP: Multicast (re)joined
00:00:06 APP: (UTC) Sat Jan 05 23:06:38 2019, (DST) Sun Mar 31 02:00:00 2019, (STD) Sun Oct 27 03:00:00 2019
00:06:39 HTP: Main Menu
00:06:40 HTP: Console

schuenep commented 5 years ago

Someone in a German Forum wrote that he has also problems with this socket at startup. He describes the behaviour as random, though. Maybe the pin is floating/at undefined level at system start?

If I restart the socket from the web interface it keeps the state the same as before the restart, as is correct. Only thing to note is, that in the "On" case, the Relais goes off for a brief moment and then on again.

ascillato2 commented 5 years ago

Ok, Thanks for sharing your test.

You are having a hardware issue with the button.

Have you modified the hardware? have you attached a switch or something? Have you solder or unsolder any component?
Can you post the output of the command GPIO ?

schuenep commented 5 years ago

I did not modify the hardware in any way, unfortunately. Do you mean to catch the output with an oscilloscope during the startup? I do not have the required hardware at home :/

I will flash a second socket tomorrow so I can compare. But what makes me really curious is that I appear not to be the only one with such issues...

From the second paragraph of https://m.heise.de/forum/c-t/Kommentare-zu-c-t-Artikeln/WLAN-Steckdose-aus-dem-Baumarkt-mit-alternativer-Firmware-Tasmota/Re-Neues-Modell-bei-OBI/posting-33506218/show/

"My socket is switching without any problems. Although the socket is acting in curious ways after disconnecting it from power. The settings of 'PowerOnState' is not correctly evaluated and no pattern can be recognised. Sometimes there appears to be an inversion, sometimes it is on and sometimes it has the correct value (PowerOnState=4 Turn relay(s) on and disable further relay control). "

ascillato2 commented 5 years ago

Hi,

by:

Can you post the output of the command GPIO ?

I was trying to say to write the command "GPIO" in the console and to post the output that gives you the console of that command. That was to see if you have any other GPIO configured for another thing or if you have it by default.

Anyway, as it is a hardware issue, we can "invent" a startup delay for your own case. As we haven't had issues like yours with OBI, it seems that is just a problem in your hardware or a batch of them.

A workaround could be:

1- Select Generic Module 2- After restart, select:

LED1 as GPIO04
RELAY1 as GPIO05
LED2 as GPIO12
SWITCH1 as GPIO14

(the switch instead of button is the only difference with the original template, so we can "detach" the switch from the relay at boot time by using rules)

3- Go to the console and type:

switchmode1 3
rule1 1
rule1 on power1#boot do ruletimer1 2 endon on Rules#Timer=1 do var1 1 endon on switch1#state=1 do delay endon on switch1#state=0 do event checkenabled=%var1% endon on event#checkenabled=1 do power1 2 endon

Please, try this and tell us if it works. Thanks

schuenep commented 5 years ago

Thank you for your help. I will try tomorrow. But I like to repeat that I have the new Obi 2 socket which is relatively new and maybe not in wide use at the moment. As I get from the gpio settings you posted you maybe seem to believe I am using the "old" one. But anyways, it could be just a faulty batch, I guess time will tell.

For completeness the output of gpio command:

01:01:23 MQT: stat/FernseherTest/RESULT = {"GPIO0":"0 (None)","GPIO1":"0 (None)","GPIO2":"0 (None)","GPIO3":"0 (None)","GPIO4":"21 (Relay1)","GPIO5":"17 (Button1)","GPIO12":"0 (None)","GPIO13":"52 (Led1)","GPIO14":"0 (None)","GPIO15":"0 (None)","GPIO16":"0 (None)"}

ascillato commented 5 years ago

hehehe, I believe you are using Obi 2. Don't worry. I believe you :+1:

schuenep commented 5 years ago

Hi,

your workaround works perfectly! As I understand the normal button configuration has also longpresses defined, will they work using the workaround (e.g. reset of the settings)?

schuenep commented 5 years ago

Hi,

I flashed my second Obi 2 socket today. It shows the same behavior. I checked the switch with a multimeter and did not detect any problems (it is a simple button anyway). I think there is a capacitance on the data line to the MCU. It discharges very slowly if the device is disconnected from power (voltage dropping to zero takes ~30 seconds). As I mentioned, I did not look in the code yet. But can you tell me if there is a delay between initializing the button gpio (and activating its pull-up) and the first readout of the button? If not, is it possible that the pin is read before the signal is high on the data line for the first time? Just speculations, but maybe you can point me to the right code so I can have a look and maybe try a short delay of a few milliseconds.

Thanks again for your help :)

ascillato2 commented 5 years ago

workaround works perfectly!

Great to know. Now we know exactly how to overcame this hardware issue.

As I understand the normal button configuration has also longpresses defined, will they work using the workaround (e.g. reset of the settings)?

with switches as a config in the generic module, you can't reset the device, but you can do single press and hold. Double press and multi-press are only available for buttons (buttons are configured in module config)

wiki: https://github.com/arendst/Sonoff-Tasmota/wiki/Rules#16-using-an-external-button-with-single-press---double-press-and-hold

I think there is a capacitance on the data line to the MCU. It discharges very slowly if the device is disconnected from power (voltage dropping to zero takes ~30 seconds).

ok, that explains the issue.

can you tell me if there is a delay between initializing the button gpio (and activating its pull-up) and the first readout of the button?

There is not a delay for that.

ascillato2 commented 5 years ago

@arendst

What do you think of adding a button mutex of 2 seconds for OBI sockets at Tasmota Startup to avoid this hardware issue? The proposed workaround with rules have work, but what about adding it in the code?

arendst commented 5 years ago

Will look in to it. There is already a power-up delay specifically for GPIO0 (and Wemos). I might add a it to all to tackle the Obi too.

Will investigate.

arendst commented 5 years ago

@hrbrgr if you compile yourself you might want to change line 1778 in sonoff.ino from

        if (!((uptime < 4) && (0 == pin[GPIO_KEY1 +button_index]))) {  // Block GPIO0 for 4 seconds after poweron to workaround Wemos D1 RTS circuit

into:

        if (uptime > 3) {  // Block GPIO for 4 seconds after poweron to workaround Wemos D1 / Obi RTS circuit

and let me know if it solves the issue.

ascillato commented 5 years ago

@hrbrgr

If you can't self-compile, here is the latest Tasmota 6.1.4.6 on core 2.5.0 with the code change from Theo.

sonoff.zip

Remember to disable the workaround rule using command rule1 0 in order to test just the code. Thanks.

Please, let us know if this works for you.

arendst commented 5 years ago

The fix is also in the latest dev version

schuenep commented 5 years ago

Hi guys,

thank you very much, the fix is working perfectly! And thank you very much for building the version for me, otherwise I could have tested it tomorrow evening at the earliest.

I'll take the opportunity to thank you very much for all your time and effort you're putting into this open source project!

ascillato2 commented 5 years ago

Closing this issue as it has been added.

Support Information

See Wiki for more information. See Chat for more user experience.

oliverschmidt commented 5 years ago

I just wanted to add that I have six Obi 2 sockets and they all behave in the very way described above.

BTW: It would be nice to have the second, green LED supported.

schuenep commented 5 years ago

Hi Oliver, the support for the second LED is already added on the development branch and is working, too. You don't have to worry as they now added an Obi 2 setting in tasmota. They do a really great job here.

For me the version from http://thehackbox.org/tasmota/020500/ is working quite good and it has the latest code from development branch. But be careful as they could be unstable (no official releases).

oliverschmidt commented 5 years ago

Thanks for the feedback - and the good news :-)

I added some content to the Wiki page - incl. a link to this conversation - https://github.com/arendst/Sonoff-Tasmota/wiki/OBI-Socket-2/_compare/0a3050e8702bd3ee975c926201d1bc8c6368198a...7ac5fb8932820d5f7215510fa967834e870d4e6a

Beside the issue discussed here I have the problem of about every tenth power cycle resulting in the socket having switched back to the 'Basic Module' while everything else being still configured correctly (WiFi AP, host name, friendly name, ...) ?!? I'm of course very curious to learn if that problem is solved too...

tbone2k-git commented 5 years ago

@oliverschmidt

I have the problem of about every tenth power cycle resulting in the socket having switched back to the 'Basic Module'

I get that too and the OBI2 sockets also crash quite often for me (I see tasmota uptime being reset), I can't use these sockets like this, they are far from reliable. I already tried to add 2 additional capacitors to the 5v and 3.3v rail. Unfortunately it does not help. The problem might not occur if the socket is without any load, but with a 60W light bulb plugged in, it will crash 100% after several quick on/off cycles.

Does anyone have an idea on what causes this? And maybe even another idea on how to fix it? o) Thank you! o)

ps: Should I open a dedicated issue for this?

ascillato2 commented 5 years ago

Please, address this to the Tasmota Support Chat. The chat is a better and more dynamic channel for helping you. Github issues are meant for Tasmota Software Bug Reporting.

Please check the Contributing Guideline and Policy and the Support Guide).

Thanks.

Support Information

See Wiki for more information. See Chat for more user experience. See Community for forum. See Code of Conduct

Ixtalo commented 5 years ago

@oliverschmidt

I have the problem of about every tenth power cycle resulting in the socket having switched back to the 'Basic Module'

I get that too and the OBI2 sockets also crash quite often for me (I see tasmota uptime being reset), I can't use these sockets like this, they are far from reliable. I already tried to add 2 additional capacitors to the 5v and 3.3v rail. Unfortunately it does not help. The problem might not occur if the socket is without any load, but with a 60W light bulb plugged in, it will crash 100% after several quick on/off cycles.

Does anyone have an idea on what causes this? And maybe even another idea on how to fix it? o) Thank you! o)

I can confirm this observation (with 6.5.0.9(b800db4-sonoff)). Without any load the Obi Socket v2 behaves and Tasmota 6.5.0.9 behave normally (most of the time). With load (e.g. small ventilator) "it will crash 100% after several quick on/off cycles".

Why has this issue been marked as closed? What is the solution? Any hints welcome.

Thanks!

tbone2k-git commented 5 years ago

Hi Ixtalo,

I guess what we experience is not exactly what this issue was about (startup status issues). We suffer from ESP crashes due to low voltage or voltage spike or some other interference (I assume). I recently visited the tasmota discord chat room because of the problem described and I was told to try another tasmota core and provide more log output. The latter is difficult of the device crashes all the time, log console will be empty/restarted. Regarding another core version, I have yet to find out what they meant with that. What difference would another tasmota version/core make? Is it less power hungry or do they expect older cores to run more stable because of fewer bugs or something?

I don't know! o)

meingraham commented 5 years ago

@tbone2k-git

Brief explanation of ESP Core differences - https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting#arduino-core-differences

Logging alternatives to capture additional information: Turn on syslog and set to level 4 - https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting#syslog

tbone2k-git commented 5 years ago

Thank you! o) I will get back to the discord channel (or here if nobody minds) with my findings. Will try the syslog thing. I already got a raspi running, as far as I understood, it will catch output from tasmota? Not sure yet how this work, but I will give it a go and some further research. Thanks again. o)

This seems a good start: https://www.sigmdel.ca/michel/ha/rpi/syslog_en.html

Medel commented 5 years ago

The solution that works for me:

100nF from the reset pin to the GND near the reset pin (WROOM). 10nF at the Reset switch (from reset to ground) 2,2kOhm at the backside from the reset via to the 3,3V via nearby Short connections No other wires (to program)

tbone2k-git commented 5 years ago

Hello Medel,

thanks for providing your solution, what problem does it solve? The ESP crashing when switching with a load attached or something else? And unfortunately I don't understand your steps 100%, so let me ask:

1) I think I understand at least the first step correctly(?). Add 100nF between reset pin of ESP WROOM and GND. What's the reason to add the cap here?

2) What about the 10nF, where did you put it exactly? What do you mean with reset switch? The OBI v2 seems to have 2 switches, do you mean one of these? What's the reason to add the cap here?

3) Again, I'm not sure what you did. I don't understand your sentence: "..from the reset via to the 3.3v via nearby short connections". Could you explain in more detail?

Maybe you can use these pictures here to help explain? https://github.com/arendst/Sonoff-Tasmota/wiki/OBI-Socket-2

Thank you in advance! o)

Medel commented 5 years ago

Hello, here two pictures for my solution

back front

tbone2k-git commented 5 years ago

Aha, thank you, this helps a lot. o) And with this modification, the ESP won't crash anymore when switching?

Medel commented 5 years ago

It works with me several days. I can also switch an inductive load (transformer) without a reboot.

Ixtalo commented 5 years ago

Thanks @Medel. Unfortunately the given instructions do not work for me.

I followed your suggestion to the point:

The solution that works for me:

100nF from the reset pin to the GND near the reset pin (WROOM). 10nF at the Reset switch (from reset to ground) 2,2kOhm at the backside from the reset via to the 3,3V via nearby Short connections No other wires (to program)

The pictures were really helpful.

Still, no success. Random toggle at startup. When there's no load then the toggle works fine and reliable. When there is a load (small ventilator, max. 23 W) then it's the described effect. Toggling switches the relay on-off-on-off really fast, then the Obi Socket V2 reboots.

Does anyone else have this problems?

Program Version 6.6.0(release-sonoff) Build Date & Time 2019-07-06T13:10:20 Core/SDK Version 2_3_0/1.5.3(aec24ac9)

joba-1 commented 5 years ago

@Ixtalo

did not read the whole issue, only your last reply. That sounds like the load drops the 230V (maybe supported by long cable or bad connection in the socket). This in turn drops voltage of the ESP below a stable level (it is a bit picky about this). A big capacitor - like 470uF or more - between GND and VCC of the ESP might help then.

Ixtalo commented 5 years ago

@joba-1

Thanks a lot! I'll try. I assume that this 470uF is additonal to the 2 capacitors (100nF, 10nF at RST) from the @Medel Solution.

joba-1 commented 5 years ago

yes, it has nothing to do with other approaches. It is just to stabilise voltage for the ESP. It definitely wont hurt or interfere with anything else.

Medel commented 5 years ago

I have 6 OBI v2 sockets with this solution. I tested it with different loads with long and short lines. I use ceramic capacitors. Have you soldered the 100nF capacitor at right position between RST and GND. The connecting wires must not be longer than necessary.

Tasmota Version: 6.5.0(sonoff) Core-/SDK-Version: 2_4_2/2.2.1(cfd48f3)

Ixtalo commented 5 years ago

@joba-1 OK, I'll try, thanks.

@Medel, thanks for quick response. Yes, 10nF at the reset button, 100nF at the ESP-WROOM-D2 (RST, GND; 4th pin from left/right), and the 2,2kOhm. Measured no shorts.

Obi Socket bought 02/2019. At the bottom it says (identical to yours):

51864X36.01-13 
FLF 2018-04-11

See here (looks like yours): https://ibb.co/z6Hqypc
https://ibb.co/PD2XLrN

Maybe this one is broken? I'll try another new Obi Socket v2 laying around...

jonasromer commented 4 years ago

Hi all! I know it's a hardware problem (not a Tasmota bug) but I'll leave my findings here to maybe help some frustrated OBI v2 owners. I had the same problems with the OBI v2 resetting when the relay switched specific loads (i.e. a fan). Unfortunately none of the suggestions here worked for me. (Cheap?) fans seem to cause some interference on the reset line to the controller. Here is what I tried:

Putting a line filter between the Obi socket and the fan seems to solve the problem. But it's probably more feasible to get a different wifi socket instead :)
According to the datasheet of the controller, there should be an RC delay circuit at the reset pin. They recommend R=10kΩ and C=0.1uF. I cut the PCB track close to the controller reset pin and connected an RC delay circuit between the reset switch and the reset pin. It worked most of the time (maybe I put it too far from the reset pin?)
In the end I just cut the PCB track close to the reset pin, without adding the RC delay circuit. I didn't have any resets since then (tried with 4 sockets). However, this completely disconnects the reset switch from the controller, but I can live with that.

obi2_mod2

Best Regards Jonas

tbone2k-git commented 4 years ago

Thank you Jonas/Medel etc. for providing fixes for the reset problem! Will try them once I get back to these lamps - appreciate your help! o)

Some additional findings: A Sonoff Basic R2 also fails to switch my desk lamps reliably and the little round wifi-plug from Blitzwolf fails as well (not that often though). So, some devices seem to be a general problem for some of these wifi-plugs. Here is a photo of the transformers and types of lamp which raise the sudden reset issues for me.

P1640555_800x600

nagyrobi commented 4 years ago

The worst is that the socket can stay booted for weeks, it "only" fails to operate correctly when you operate the switch (either by web interface, or by MQTT or whatever). It randnomly reboots right after operating the relay, and what's worse is that after it boots up, the relay state is not consistent. Sometimes it remembers the state before reboot (and switches the relay back on or off depending on how it was) sometimes it doesn't. Also it doesn't always save the settings. This makes the unit completely unreliable to use.

None of the suggestions above succeeded on the long term. Tried them all - same problem re-appeared sooner or later. I have two such Obi2 sockets (bought the second one because I thought maybe the first one was faulty - turned out all of them are like this).

But i finally found the perfect solution: replace the shitty electronics in this socket with a Sonoff Mini. It accomodates perfectly in the casing of Obi2, no modifications of any sort needed: kép

I won't throw away the original Obi2 board though. I plan to remove the relay and the buttons, and use it as a sensor aggregator. I'll connect some DS18B20, AM312 or BH1750FVI to the GPIO pins freed up and feed them with Tasmota in my Home Assistant setup. Since no more switching will be done with it, I expect stable operation like this.

I'd suggest to update the wiki with some basic information that this harware is not the best choice for reliable operation.

tbone2k-git commented 4 years ago

The Mini seems to be a nice fit! o) Getting the button and led of the original OBI v2 to work with this would be a thing. But if it switches reliable, it surely is a win - even without button/led! o) You did not mention how long you were running this modification, maybe you can share some long term experience with us.

I had the same idea, fitting a Sonoff-Basic PCB into the OBI v2 housing, unfortunately it doesn't really fit in there without modding and as it turned out in the precautionary tests, Sonoff-Basic did not behave much better with my desk lamps, so I stopped right there.

Thanks for sharing your solution! o)

nagyrobi commented 4 years ago

Finished installing Christmas lights on the 27th of November, Sonoff Mini running inside Obi2 casing outdoors in negative temperatures - still working super-stable. I don't need button and LED accessible from outside - even better because it's not disturbing (earlier I covered with tape so it won't attract the eyes). The socket is integrated with Home Assistant, and placed somewhere accessible only using a ladder - the button is completely useless.

I really like the Sonoff Mini:

it has its own insulated plastic casing, so placed inside Obi2 casing creates double-insulation which is always welcome
it has an external antenna - excellent WiFi signal, a lot better than PCB antennas on any previous Sonoff model
much tougher terminal and screws for connection. Previous Sonoff model terminals were quite weak

Edit: another discovery related to the original Obi2: completely removed the relay. Physically unsoldered. Powered the board only with 3.3V from the USB/TTL adapter. Uploaded the latest 7.1.2 Tasmota. Still the same symptoms - randomly reboots after toggling on the web interface. This is not at all related to any interference from high voltage circuits, or any noise picked up or whatever. The board behaves bad when such noise sources are not even close. This is bad by design.

oliverschmidt commented 4 years ago

Today I implemented what Jonas suggested in https://github.com/arendst/Tasmota/issues/4829#issuecomment-554624296: Cutting the PCB track close to the reset pin makes my 5 sockets work like a charm - thanks Jonas! I think I can judge that as I have a load which made the sockets before reboot on every single toggle.

Given that similar sockets don't have a reset button in the firs place and that recent Tasmota versions nicely support both LEDs I now consider the devices interesting ones after all :-)

nagyrobi commented 4 years ago

I also tried this, but I didn't get stability on long term.

ghwaldo commented 3 years ago

I also purchased those plugs. I used a RC-Filter parallel to the load, pulled-up reset pin, put 2 capacitors (470µ + 100nf) to 3v3 to gnd near the ESP.

Today i finally cut RST near by ESP as mentioned here. Now it is much better. But not perfect. I think, the only thing to get rid off this is to throw it away and replace with other plugs. I used an emylo wifi switch, putted into a surface-mounted junction box, cutted a socket strip and connected everything in the box. That works more stable.

Sven21279 commented 4 days ago

I just add a 100nF to GND and 3V3. This fix all my problems with this device. I use the pins at bottom the SoC. (see picture from Medel with the resistor from 3V3 to reset)

arendst / Tasmota

Obi 2 - Random Toggle at Startup #4829

Support Information

Support Information