close-issue-app[bot]
commented
4 years ago This issue has been automatically closed because the issue template is missing or incomplete. Filling the template is required so standard questions don't need to be asked again each time. Our ability to provide assistance is greatly hampered if few minutes are not taken to complete the issue template with the requested information. The details requested potentially affect which options to pursue. The small amount of time you will spend completing the template will also help the volunteers, providing assistance to you, to reduce the time required to help you. Please, could you be so kind on completing the issue template in order to have more information so as to properly help you? Thank you for taking the time to report, hopefully it can be resolved soon. Support Information Wiki for more information. Chat for more user experience. Community for forum. Code of Conduct Contributing Guideline and Policy
Hello guys, I have discovered some strange issues that have raised some questions and would very much appreciate help in this direction.
The story: I have build 8
Wemos D1 Miniwith 1WS2812, 1 invertedBuzzerand 1PN532card reader. I've made o custom image from Tasmota 8.1.0.10(lite), built it withUSE_PN532_HSUandUSE_PN532_CAUSE_EVENTS. Took out all the emulation and stuff I did not need.All the boards connect to a MQTT server. I also developed an app to listen to the MQTT and watches for cards that have been read and sends a
Backlog color 4bf20e; dimmer 100; delay 8; Power OFFover MQTT to the device that read the card. This makes the neopixel green and buzzes a bit to send a notification the card has been read and accepted.The idea is simple and works...most of the time.
The requirements: I don't care about power consumption. I want it to be reliable, work snappy and reconnect to the Wifi and MQTT as soon as possible after a disconnect. I don't want it to sleep or idle. It should just look for cards that are read and send them to MQTT.
Image and device details:
The setup: I'm logging everything in the serial console with PlatformIO on VSCode so I keep an eye on what happens.
I also go on my router and simulate a Wifi failure buy turning off the AP I'm connected to the turning it back on.
For stress testing I've let the card on top of the reader so every 1 second, 2 seconds a reading pops up.
I first light up the neopixel with the
Rule1when a card is read, then I expect the neopixel to change color and the buzzer to buzz when my MQTT program sends the command back to the device thru MQTT.This way I can see if the card is read, not read or if the card is read and also getting feedback on MQTT.
I also watch the logs on my app that's connected to MQTT and watches for Tasmota read cards.
The tasmota setup: Template:
{"NAME":"MyTemplate","GPIO":[255,255,255,255,7,161,255,255,138,139,255,255,255],"FLAG":15,"BASE":18}This is:Rule for lighting up the neopixel briefly when a card is read(so I know Tasmota is aware of the card):
Rule1 ON EVENT#PN532_UID DO backlog color 0728fc; delay 1; power off ENDONOther settings I use:
SetOption34 10; Delay 4; TelePeriod 20; Sleep 0; SetOption0 0; SetOption36 0; Rule1 1The problem: Seems the connection of my Wemos D1 Mini is not reliable and it takes a long time for Tasmota to figure out what is going on and maybe reset the device.
What I've noticed:
After a disconnect from the Wifi(I turn wifi off, then I turn it back on), Tasmota sees I have no wifi and tries to reconnect. After it does, it waits for a while(I guess the MQTT timeout) and then tries to connect to MQTT. This mostly works!
After working a while, it just drops the wifi connection, tries to reconnect and then it always times out even if the wifi is on. This goes into a loop and the device needs reset. Strange behavior and hard to understand why it does not see the wifi anymore.
Some other strange situation that arises is that Tasmota thinks it's connected to Wifi but it actually isn't or is in a state that it cannot use the network. I have no ping from the network to Tasmota either. But it thinks it's connected and tries to reconnect to MQTT and guess what, that fails with rc:-2. This also creates a loop!
I've also noticed sometimes the loop is:
and then it crashes with an error similar to the one at the bottom. Then the device restart.
For 2. and 3. sometimes one reset(from the button) is not enough as it gets back into the same loop. The second reset seems to work. Also issues 2. and 3. happen out of the blue(i don't mess with the wifi), after the devices has been active for a while.
The strange things: Out of the 8 Wemoses I've flashed one did not connect to the Wifi from the get go. Check out the behavior on
What I've noticedpoint2.Other stuff I've done: I thought this might be a power issue and the whole esp8266 gets confused and doesn't work properly. So I strapped a 10000uF electrolytic cap over the Wemos's 3.3V and ground terminals. Seems it works more stable now but this may only be in my head as the same software issues as described happen again. Seems after a bit longer than without the cap.
My questions:
After a WIFI failure, how can I make Tasmota reconnect instantly to MQTT after it has reconnected successfully to the WIFI? (And not wait the timeout for MQTT). I guess I want the same behavior Tasmota has when it boots up. First it looks for Wifi, then instantly for MQTT.
How can I restart the device after 5 consecutive WIFI reconnect failures?
How can I restart the device after 5 consecutive MQTT reconnect failures?
How can I prevent Tasmota to retain any type of state and assume it starts fresh on each reboot?
PS. I'd willingly go after these things in the code myself but unfortunately I don't have any experience with C, low level stuff, hardware programming, etc so I'm hopping my post yields some results, tips, pointers, maybe some additional rules to Tasmota or maybe even some bug fixes?
What I also guess is that most people use Tasmota for low power usage, sensors that send data every 10 minutes or something like this. This way this type of behavior may not even show up. But when I started stress testing it this it came up.
As I was writing my request, this error popped up in my serial console and the device restarted(don't know if this is of any help to anyone):