deepsleep does not goes down when connection is lost to mqtt

[roblad]

Hi,

Is it possible to change deepsleep function according to lost connectivity to mqtt. I noticed that, when mqtt conection was lost because of mqtt server error, the ESP did not gone to sleep mode and the battery has gone empty after 8 h trying to connect to mqtt.

Rgs, RL

[stefanbode]

Oh, definitely yes. I got the same problem during my last holiday and all of my remote devices build for last at least a year or two got empty. Yes, it is a bug.

[roblad]

Hi,

Could you extend time after wake up ? Or add parameter to set keep alive after wake upe SHT wants a fiew sec to start measuring I have 12 sec alive but I want 15-17 sec.

Rgds

[stefanbode]

I have a similar problem with the SR04. I need to do some investigations if it is better to do a redo, if the value is invalid or just add a configurable delay. The delay is easier because already DECREASED the time to the minimum. I just had to undo this.

[stefanbode]

Added a fix to ensure deepsleep, if MQTT or SSID is not available. Regarding the starttime I will need some time again.

[stefanbode]

I checked something and the starttime before measuring can already be influenced. There is no additional parameter required. First, you have to set deepsleep to 0. Then after a restart, the "normal" teleperiod is 10 when using the battery. This does the measuring as fast as possible. If you want more time before the measuring just increases teleperiod to 15 or 20 seconds. Then deepsleep back to 3600 or what ever you prefer. Works for me. The uptime is much longer.

[roblad]

Hi,

I do not undarstand that " just increases teleperiod to 15 or 20 seconds." and "irst, you have to set deepsleep to 0. Then after a restart, the "normal" teleperiod is 10 when using the battery."

haw it works ?

When my deepsleep is 300, I should set also teleperiod as well ? it will increase a measurement time when will wake up ?

I have the same

tele/wemeos/UPTIME_S {"Time":"2018-01-21T17:27:13", "Uptime_s":12}

[stefanbode]

0c066fb fixed

[stefanbode]

No just change the teleperiod to 20 for example to ensure at least 10 seconds UPTIME on top. The only problem is: You cannot change it as long as the device has a deepsleep defined. you need to disable it first to set a new value

[roblad]

Hi,

the same

tele/wemeos/UPTIME_S {"Time":"2018-01-21T23:03:27", "Uptime_s":12}

I have Teleperiod set to 20, I did 0 > restart > set 20 > deepsleep 300

[stefanbode]

if your UPTIME is 12s with teleperiod 20, please try teleperiod 30 to see, if there is a change. it works on my side.

[roblad]

The same

tele/wemeos/UPTIME_S {"Time":"2018-01-22T13:02:10", "Uptime_s":12}

I changed to 30 TELEPERIOD - I do not know why it hapened, that it not working as you said.

[stefanbode]

more than strange. Can you send a "teleperiod" after reboot to check what is the value. If everything is ok it should be 30.

[roblad]

stat/wemeos/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":3,"SysLog":0,"LogHost":"","LogPort":514,"SSId1":"robert_private","SSId2":"robert_private2","TelePeriod":30,"SetOption":"00000029"}}

tele/wemeos/STATE = {"Time":"2018-01-22T13:27:18","Uptime":0,"POWER":"ON", "Wifi":{"AP":1, "SSId":"robert_private", "RSSI":100, "APMac":"84:16:F9:C8:85:E6"}, "DeepSleep":0, "Heap":24640}

[roblad]

now is tele/wemeos/UPTIME_S {"Time":"2018-01-22T13:35:06", "Uptime_s":14}

[stefanbode]

Agree. now have the same behavior.... strange

[stefanbode]

Sorry, I tricked myself. Now it should work.

[roblad]

tele/wemeos/UPTIME_S {"Time":"2018-01-22T17:29:50", "Uptime_s":12}

there is maybe yield(); function that cause it - I use it in xsns_20_chirp_mois

[stefanbode]

Please double check that in sonoff.ino there is the following change:

//STB mod
  if (LocalTime() > 100) {
    tele_period = 8 ;
  } else {
    tele_period = 1 ;
  }
  //end

[roblad]

I have

//STB mod if (LocalTime() > 100) { tele_period = Settings.tele_period -2; } else { tele_period = Settings.tele_period -9; }

[stefanbode]

old version. please update

[roblad]

hmm, I took fom GIT latest one

[roblad]

Hi,

tele/wemeos/UPTIME_S {"Time":"2018-01-22T20:33:41", "Uptime_s":34}

it was set on 30 but uptime have 34

[stefanbode]

yes this is normal because measure start at ~30sek and then it takes some time also MQTT takes some time and so on. It is nothing you can predict. But this now looks ok.