-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shutters hang + reset #21453
Comments
I have a similar problem with a Shelly Plus 2PM with 14.0.0. In the ShutterSetup process the Shelly restarts when the shutter reaches the top position. |
@maltic42 Don't know details, but it seems like a different issue. This happens on properly configured device after several weeks of usage and is not caused by top/bottom position. |
I can confirm that i see an issue in the mqtt connection after 3-4 hours, update to 14.0.0.4 seems to solve the problem. @JosefRypacek maybe try the update to beta on one device to confirm. |
You are right I'm using MQTT and HA integration, but in my case it take ~ 1-2 months before hang and it affects MQTT, buttons in Tasmota UI and physical switch buttons. After "hang" whole web UI seems working, you "only" can't move with shutters and after multiple clicks to DOWN or UP button device is reseted. |
The shutter setup is a completely different animal. It is known that restart could happen here. I still haven figured out how to catch the crash. It is issued by frequent reading of the current measure to find the right time where the shutter stop. There is NO known crash on normal operation |
I checked with current version to "force" a crash by frequent pushing the DOWN button or by frequent using the WebUI DOWN button. I was not able to get one crash. Therefore very difficult to analyze. |
I am a little confused because I do not see the MQTT message? Here the log how it should look like. Maybe you have an MQTT server issue:
|
Yes, it can't be crashed by the mentioned steps anytime. The device has to be in some "bad" state which occurs at the same time for all devices (so I think it's related to Wi-Fi restart, MQTT restart or some spikes in power). In the mentioned output I didn't used MQTT, but just WebGUI to verify it's not caused by MQTT server. |
We see frequently with some Chinese devices that the LDO doing the 3.3V is quite noisy and not powerful enough. Sometimes it helps to put a 470microFarad capacitor between GROUND and 3.3V. The Shelly normally do not have these problems. I have many of them without any problem. The Sonoff I would not advertise. |
Might be a power problem. I added to all my shutter ESPs a 6700µF 6V capacitor and never had any problems. Might be oversized but works. |
@jtauscher : Please can you close the issue as it looks like this was an electrical problem we cannot address with a software change. THX |
@stefanbode I'll close the task, but want to note that this is probably NOT related to electrical problem. Only devices with shutter configured are affected, other devices of the same type with non-shutter configuration are OK. But agree it's difficult to diagnose. |
I have been experiencing the same issue every few weeks/months, the last occurrence was 2 days ago. So maybe I can add a few bits and pieces that possibly help troubleshooting this sporadic bug. The problem appears to be only on the devices running shutters: the shutterposition is apparently lost as well as rule activation (rules are disabled after the event). Devices affected: Devices NOT affected: Assuming the "survival" of that single Dual R2 is not pure coincidence: |
It happened again on 14.0.0... It still seem like shutter related functionality to me, but I have to admit it's weird that all devices with enabled shutter functionality are hit at the same time. I tried
I probably have another 2 devices in this state (not sure how long they will remain) if you would need any additional data. |
Hi @JosefRypacek . I can see with the Exception1 that this is definitely something in the TASMOTA firmware that causes the boot and restart. The observed missing response in the browser is most likely the reboot that the system is doing after receiving the shutterposition command. I need following information to reproduce the error here:
Please provide the output. If there are additional rules defined that might have an influence please also share these:
I do see that in the inital report of the case you already provided some info like this on: It is very important that we get the information of an effected shutter. In the past we had an overflow with long run times like 36sek. But this was fixed years ago. Therefore it is very important to have the exact parameters of the shutter that causes problems I have ordered a dual R3 on amazon. should be there tomorrow. maybe something special with the measurement function of the power and current. |
Hi, yes there is nothing changed in the configuration and there are no rules.
Also please note that my devices are R3 (v1) and there seems to be v2 already. Now the important information which may actually resolve this issue. If you look into my first report, the device reports uptime just above I also found that first call of |
I now have a flashed sonoff dual R3 v1.6 to test 1:1. I have configured the device same as you und currently I do not see any problem. There is no load on the relay. No Motor connected. Testing several DOWN do not show any issue. shutterposition and shutterposition1 also execute excellent with direct report to the UI. I will now add it with MQTT. Theo shared some images with devices up and running 289days. Therefore this is not the reason |
You probably won't be able to reproduce it earlier than after 50 days. So leave it connected. :) At the end of May my device was working correctly in the morning (with uptime approx. 49 days and 12 hours). In the evening (50 days and 1 hour) I found it's stuck. I realized that it happened at least 1 time few months earlier. I sometimes need to turn off the power or update devices, so next occurrence won't be exactly after 50 days, but if this task won't be solved until then, I will update with next occurrence. |
I already fixed one issue this morning that can cause an overflow. But will check later on if any Millies() have the potential either. It is not unlikely because I do use this quite extensivly. |
Ok, now we are getting close. I submitted a new fix #21966 and this looks more promising for the case. There is a function that ensure you give the motor a small time to rest before operating e.g. in the other direction. Here we store the last motorstoptime as a 2^32 variable. If the online time if above 49days first nothing happens UNTIL you operate the shutter again. Then millis() is very low and the code expected it to be slightly higher than the last stop time. This causes an infinite (49days) loop and before that happen the crash detection of TASMOTA reboots all the things. Thanks for bringing this up and help to make it more reliable. @arendst : This i very likely the issue. Thanks for guiding me into the right direction |
That seems exactly like my observation - Tasmota won't crash on first shutter operate command (e.g. button down), but on second or third. Thanks for fixing it and make my home more reliable. |
PROBLEM DESCRIPTION
I have several devices and few times a year all my devices with shutter function enabled hangs at once. Other devices without shutters works fine at the same time.
Today I found I can't control my blinds using HA and MQTT and it seems Tasmota got stucked again. I connected to the Tasmota web GUI, enabled debug level, opened console in separate tab and pressed DOWN button multiple times. (If I would press in only once, nothing will happen and device won't be restarted.) I copied console log before and after the reset.
This device is not on the newest firmware, as it's hard to reproduce.
I would like to know it provided output is enough to analyze and possible fix, or I should do something more next time.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255
:Backlog Rule1; Rule2; Rule3
:Status 0
:weblog
to 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Not known.
EXPECTED BEHAVIOUR
Not hang.
SCREENSHOTS
N/A
ADDITIONAL CONTEXT
N/A
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: