-
Notifications
You must be signed in to change notification settings - Fork 41
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
DeepSleep not working, when building from source 2.9.2019 #181
Comments
Yes, sorry for this. Messed up with rules. Already see this on my side. Fix will come soon |
Please check and close if fine |
Hi, i have a question about the deepsleep mode. (GPIO 16 was set to DeepSleep) But how can i check if deepsleep working? Ping was always answered. i use the latest code. Thanks for help. |
take a look on the console. also webconsole is fine. set teleperiod 10 and deepsleep 60. |
I used the code from 15 minutes ago.
I can't see that the deepsleep mode was active. Must i connect GPIO 16 with RST ? Or is it enough to put the GPIO16 on deeplseep? |
Here is an example of how it should look like. GPIO16 and RST must be connected for the wakeup. Otherwhise your device will sleep very very long... Anyhow your problem is, that is does not go into deepsleep. Can you set seriallog 5. maybe we see more information. MQTT must be up. but this is your case.
|
Ahh I see the mistake. DO NOT SET GPIO16 to DEEPSLEEP !! This is for the easy wakeup. |
The DEEPSLEEP pin (preferred GPIO16) is to PREVENT deepsleep with a small switch without reconfigure the device. |
But i must connect the GPIO16 with RST - right? |
Yes. Best directly with a wire to have a wakeup. GPIO16 is sending a HIGH to RST (Reset) that then trigggers the wakeup. |
OK. Now i have connected the GPIO16 with RST and the deepsleep mode is working. |
Hi Stefan, I checked the fix. Unfortunately it didn't work. Could it be that the prerequisites for deepsleep changed? |
@hermann1514 look at #174 - Stefan already answered this, when I had the same question. |
Hi @thomas-lentz yes I changed some prerequisites to ensure that data is send during wakeuptime. The roundtrip through all takes between 6-10 seconds (4-8 seconds to establish wifi). I changes behavior because a measurement WITHOUT sending the data to MQTT does not make sense. Also I think it is a good advise to have a correct time sending with the data. Therefore all these checks. Please can you give it a try with the following settings: Depending on wificonnect the online time will b something about ~7sec. |
Updated the wiki: https://github.com/stefanbode/Sonoff-Tasmota/wiki/Deepsleep |
Hey Stefan, |
Hi Stefan,
The device won't wake up after that... Another idea could also be, that there is a problem when the new (absolute) Wakeuptime, after Deepsleep seconds after the previous WakeUp, falls into the "still awake" time of the this previous WakeUp period. |
Hi, |
Okay, I'm glad I'm not the only one experiencing this problem. Reset also helps. |
Yes, this is correct. I got some trouble with negative values on unsigned int variables. A new current version is already in final testing. |
The new deepsleep behaviour improved. now better meets intervall after some time.
I still have the problem that the WEMOS does not wake up again. |
this is very strange. I have no more issues at my side. D0 and RST are connected? So it wake up most times but not all times. Correct? Can you send some log files. Maybe from syslog or from serial |
The latest Message was: {"Time":"1970-01-01T00:00:20","Epoch":20,"DS18B20":{"Temperature":20.12},"TempUnit":"C"} Time Problem? |
Thanks this is a good hint. I will check what it calculates if there is no timeserver reporting a correct time |
Yes, your guess was absolutely correct. if the time was not gathered correctly this causes the system to do a deepsleep 0 which in the end is = endless. My current assumption on the new code is that this now never can happen again. |
Hi Stefan,
As you can see MQTT server is connected, everything is fine and and some data is sent via MQTT but STATE is shown as RSL. Only one sensor:
Two Sensors:
It is compiled from your newest #181 fix source (8.9.2019). I tried with core 2.5.0 & 2.5.2 |
Hmm, i do no5 see this at my devices. And my messages are for sure longer than yours. I‘m not aware on any changes that could effect this. I assume sensor is working without the deepsleep. |
Why is your state message RSL. This is MQTT on my side. I use the TLS version, enabled in my-config, but unlikely this make a change. |
I just went through your log and yes all messages a bit longer are RSL and not mqtt. This will give a hint to a length problem. Maybe you search in the original tasmota for hints. Because STATE is also effected like INFO1 you should not be the first one. |
This looks very similar to yours |
Yes in fact it was the same problem and I spent my night to solve it. I already posted it in the other thread, but just to not leave this "issue" here open, I repost it: The problem is an old "PubSubClient-EspEasy". A 128 characters are by far not enough!
So if you have the "RSL:" instead of "MQT:" check the version of your "PubSubClient-EspEasy". |
BUG DESCRIPTION
Setting DeepSleep via command will not set Device into DeepSleep
REQUESTED INFORMATION
status 0
:correct behaviour;
TO REPRODUCE
Just enter DeepSleep 60 and TelePeriod 60 at console
EXPECTED BEHAVIOUR
Should go to deepsleep after some time...
ADDITIONAL CONTEXT
It is working with the Source files from 28.08.2019. No "personal" configuration has been made to both versions.
Personal guess: somebody deactivated the function for testing purposes and forgot to reactivate it, before putting it into git.
Status 0 of working complied sources 4 days ago
The text was updated successfully, but these errors were encountered: