Tasmota: MQTT TLS issue

Created on 28 Oct 2020  路  27Comments  路  Source: arendst/Tasmota

PROBLEM DESCRIPTION

00:00:46 MQT: Attempting connection...
00:00:56 MQT: TLS connection error: -1002
00:00:56 MQT: Connect failed to 192.168.20.27:8883, rc -2. Retry in 10 sec

if im doing a complete erase it worrks for 1-2 days, and after that it is not working again.
after that its possible to reflash, but it work not work anymore. only after erasing flash. tested with 3 devices. same behavior.

REQUESTED INFORMATION

_Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!_

  • [ ] Read the Contributing Guide and Policy and the Code of Conduct
  • [ ] Searched the problem in issues
  • [x] Searched the problem in the docs
  • [x] Searched the problem in the forum
  • [ ] Searched the problem in the chat
  • [x] Device used (e.g., Sonoff Basic): Sonoff Basic
  • [ ] Tasmota binary firmware version number used: 9.0.0.0.3, or 8.5.1

    • [ ] Pre-compiled

    • [x] Self-compiled

    • [x] IDE / Compiler used: visual studio code

  • [x] Flashing tools used: OTA
  • [ ] Provide the output of command: Backlog Template; Module; GPIO 255:
  Configuration output here:


  • [ ] If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
  Rules output here:


  • [ ] Provide the output of this command: Status 0:
  STATUS 0 output here:


  • [x] Provide the output of the Console log output when you experience your issue; if applicable:
    _(Please use_ weblog 4 _for more debug information)_
    ```
    Console output here:

00:00:46 MQT: Attempting connection...
00:00:56 MQT: TLS connection error: -1002
00:00:56 MQT: Connect failed to 192.168.20.27:8883, rc -2. Retry in 10 sec

TO REPRODUCE

1., compile 9.0.0.03 (or 8.5.1) with TLS support
2., tasmotizer:flash the firmware
3., set the parameters,
4., wait 1-2 days

  1. vo谩l谩...

EXPECTED BEHAVIOUR

working TLS

SCREENSHOTS

_If applicable, add screenshots to help explain your problem._

ADDITIONAL CONTEXT

_Add any other context about the problem here._

(Please, remember to close the issue when the problem has been addressed)

awaiting feedback stale troubleshooting

Most helpful comment

I run also my devices all with TLS. Sometimes I have temporary problems that the device cannot connect to the MQTT server. I found that my FritzBox causes the issue because a reboot of the router fixes the problem. Also, it helps in many cases just wait. Not sure what went wrong. The power supply is an interesting hint, but as mentioned I only have the issue very rarely and also only on devices I boot very often because these are on my desk. I do not have issues with the 50+ always-on devices in the house. My shellys use the shelly cloud. No issues there.

All 27 comments

Error -1002 means "Cannot connect to TCP port". This is not a tls issue.

What are you connecting to?

Thanks for the quick feedback. I can connect to the Sonoff from the PC, and from the PC i can connect over TLS to the mosquitto server. So it is strange, if its a TCP issue. The second issue is: why its visible after 1-2 days, and why is it gone, after reflashing the device.

Could be a ARP treatment issue. Try SetOption41 <x> see docs https://tasmota.github.io/docs/Commands/#setoptions
Which router or APs do you have?

i have got Linksys APs. (LAPAC 2600c)
one more information: if i disable TLS it works again...

Not a easy issue to solve. Could be a problem with wifi equipment and the ESP82XX

i do not think. im using tasmota with the same APs since the beginning of tasmota without problems. now, i changed to TLS, and its not working stable anymore

Which device?

sonoff basic.
after your comment i tried something: AP rebooted, and it works! (without reseting the Tasmota) it recovered automatically
do you have a new idea?
02:04:42 WIF: Connecting to AP2 FamilyBoros-IoT in mode 11N as sonoff004...
02:04:47 WIF: Connected
02:04:49 MQT: Attempting connection...
02:04:51 MQT: TLS connected in 2010 ms, max ThunkStack used 2548
02:04:51 MQT: Connected

also the second one without setoption41

Wifi problems occur when power supply is weak. Since TLS needs a lot of MCU performance
the MCU draws more current. If it is a wemos mini it is quit sure that the onboard 3.3v vreg is to blame

Ahh, sonoff basic. It is known for a very weak power supply. I am for 99% sure that is the problem!

i have got limited space avaiable. is the shelly power supply better?

Shelly has no known problems

ok thanks for the answer. i will make a 1week test run, and i will close the issue, if the problem is not avaiable anymore

I run also my devices all with TLS. Sometimes I have temporary problems that the device cannot connect to the MQTT server. I found that my FritzBox causes the issue because a reboot of the router fixes the problem. Also, it helps in many cases just wait. Not sure what went wrong. The power supply is an interesting hint, but as mentioned I only have the issue very rarely and also only on devices I boot very often because these are on my desk. I do not have issues with the 50+ always-on devices in the house. My shellys use the shelly cloud. No issues there.

Thanks Stefan for the hint. for me to restart the router (self made pfsense router with 12 core intel atom) is not a solution. For that time i do not have VPN, and my complete family (living not only in Germany) are connected to the internet over my router (firewall) to be on the safe side. i will start to investigate the power supply issue. As i am electrical engineer, it will be easy to find out how ESP8266 reacts on load steps (this is the idea, that the power supply can support the current in general, but its to slow to react on load steps, especially if the TLS calculation begin)

Hello guys, i have got bad news... after 2 days, the first Shelly is also failing with the same problem... So its most probably not the power supply of Sonoff. Do you have an idea?

today all of the 3 shellys failed, and the 2 sonoffs. the forst one after 6hours, the last one after 10 hours. 2 sonoffs are working now, both are equipped with BME280 sensors. The other tasmotas without sensors are failed. hopefully they can survive this night.

hello everybody. the problem is not solved. What i found out, the problem is coming, if the AP is changing the channels

Dont change channels ;-)

Dont change channels ;-)

that is what i will try today in the night. I switched off the auto channeling, and tomorrow i will come back with the result. stay tuned :-)

hello guys,
i have bad news again. Tasmota is failing without auto channeling. with auto chanelling i can force the failure, the probability is higher, but without this, its not solved. im nearly sure, that is a tasmota issue. what is very interesting, additionally yesterday i compiled a "minimal" version without anything, (all of the not needed stuff disabled) only switching, mqtt, tls, and its stable since 10 hours. Is it possible that we have got here a runtime issue?

Hello guys again,
i have got the same feedback, like yesterday. The own-compiled Tasmota with nearly minimum configuration is stable, but the others, in the same environment are failing. im sure, it will be a runtime issue. Whats your oppinion?

Which LoadAvg do you have? Compile a version with 160Mhz.

Which LoadAvg do you have? Compile a version with 160Mhz.

LoadAvg: 19

i have got the same behavior since days:
1., same access point
2., shellys, sonoffs are connected to this AP.

  1. 1 Shelly is equipped with the "nearly-minimal" compile. Working fine.
  2. all of the other devices are failing. Some device after 2 hours, others after 10 hours, but within 2 days every device with the original firmware is failing.

i will use the own compiled version, and i will deny the all of the communication (expect to the MQTT server) on the firewall. In that case i do not need the updates, and i will stick for 9.0.0.3. Its not a nice solution, because the problem is not solved, but for me, its a local workaround.

Im sure, its not an issue in the network, its a tasmota issue.

This issue has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

This issue was automatically closed because of being stale. Feel free to open a new one if you still experience this problem.

This issue is not solved. Its easy to reproduce, and there is no solution until now. This cant be closed

Was this page helpful?
0 / 5 - 0 ratings