Upgrade to 20200426 causes device to hang waking from sleep

[dampa]

WeMos D1 Mini
ESP_Easy_mega-20200310_normal_ESP8266_4M1M
ESP_Easy_mega-20200426_normal_ESP8266_4M1M

BACKGROUND:
I have a set of rules that are working fine with the 20200310 release. On System#boot it disables controller 1 and 2 then checks to see if a dummy device variable (control#coldboot) is a zero. (on a cold boot it will be 0 but if it is set to something, on a wake from deepsleep it will still hold the value it was set to). If it is a coldboot, it sets some values (including setting a value in control#coldboot so it won't do it when waking from sleep).

When WiFi#connect occurs, it grabs the first two octal's of the IP and compares them to '192.168' and compares %ip4% to the %unit% to decide which controller to activate. I have my router assign IP address based of the MAC address so %ip4% will be the same as the unit number I assign to the divide. This is done to run on my local network or at my daughter's using BeeBotte.

When MQTT#Connected occurs, if the email indicator is set, it turns it off and sends a mqtt msg to Node-RED which will send me an eMail with the IP address. It then published another message saying 'awake' and sets a timer for 10 seconds t allow devices to publish their readings.

Then I have some rules for turning on and off a gpio pin which causes a circuit - by dynamicdave - to turn off/on power to the I2C line for some sensors).

This all works great on 20200310.

THE PROBLEM
When I flash to ESP_Easy_mega-20200426_normal_ESP8266_4M1M and boot, it runs the first cycle and goes to sleep but when it wakes it just hangs.

I've narrowed it down (after beating my head against the wall for several days) to having a device for a BMx280 defined but not having it connected or not having power to the I2C line. It looks like it loops looking for the device. the log gets flooded with

Code: Select all

May  1 11:27:45 node28 EspEasy: BMx280 : Unable to detect chip ID
May  1 11:27:46 node28 EspEasy: BMx280 : Unable to detect chip ID
May  1 11:27:46 node28 EspEasy: BMx280 : Unable to detect chip ID
May  1 11:27:47 node28 EspEasy: BMx280 : Unable to detect chip ID
May  1 11:27:47 node28 EspEasy: BMx280 : Unable to detect chip ID
May  1 11:27:48 node28 EspEasy: BMx280 : Unable to detect chip ID
May  1 11:27:48 node28 EspEasy: BMx280 : Unable to detect chip ID

messages.

As I said, this was not an issue with 20200310 (which I have dropped my other devices back to)

If there is any other information I can provide, please let me know.

[TD-er]

Hmm that sounds like a serious bug as it probably also may affect other plugins.

I guess the only recent change that may be related is how to handle the "interval = 0" setting (which will be shown as "60" to make it even more complex).

Can you also make an issue for it on GitHub, as I am really terrible in finding things back here on the forum.

[dampa]

will do, first thing tomorrow (east coast US) I'm done in right now

[TD-er]

I think the logs about the chip not being found is not something that has been changed recently.
It is generated from the PLUGIN_ONCE_A_SECOND call and that has not changed.

Not sure what may cause the unit to remain awake though, that's still under investigation.

[dampa]

Ok, I did some more testing and it is NOT related to the BME280 or any of the devices. I deleted all my devices except one generic dummy devices I use to store variables in. I've been stripping out my rules to see if I can narrow it down. I flash with 20200310 to see f it works, then with 20200426 to test.

Alas something went wrong and I bricked the wemos so I'm off to flash a new one. Fortunately I've been backing up the wemos so it won't take too long to get back to testing it.

[dampa]

Well I didn't brick the WeMos after all!! The USB cable I was using only has the power lines in it, using another cable I was able to flash it again.

So I've narrowed it down to to one dummy device and the below rules. With the 20200310 release it runs fine, with the 20200426 release after the first sleep cycle, it never allows you to access the device. I have to unplug it and quickly disable the dummy device.

Screen Shot 2020-05-03 at 8.28.17 AM.png (45.25 KiB) Viewed 7466 times

Code: Select all

on System#boot do  //runs on cold boot, reset or wake from sleep
      TaskValueSet,1,1,1    //set sleep on (control#gotosleep)
      TaskValueSet,1,2,30   //sleep time (control#sleeptime)
endon

on MQTT#Connected do
   publish wsremote/msg/%sysname%/log,'{"time":"%unixtime%","status":"awake"}'
   timerSet,1,10  // Wait 10 secs for AUX devices to take a couple readings   
endon

on goToSleep do  //only comes from NR
   TaskValueSet,1,1,1    //set sleep on (control#gotosleep)
   publish wsremote/msg/%sysname%/log,'{"time":"%unixtime%","status":"gotosleep"}'
   timerSet,1,10  // Wait 10 secs for AUX devices to take a couple readings   
 endon

on wakeUp do  //only comes from NR
   publish wsremote/msg/%sysname%/log,'{"time":"%unixtime%","status":"iamawake"}'
   TaskValueSet,1,1,3 // turn sleep off (control#gotosleep)
   timerSet,1,20  // Wait 10 secs for AUX devices to take a couple readings   
endon

on Rules#Timer=1 do  //
   publish wsremote/msg/%sysname%/log,'{"time":"%unixtime%","status":"sleep","sleep":[control#sleeptime]}'
   timerSet,2,1  // Wait 5 secs to send sleep msg  
endon

on Rules#Timer=2 do  //
   if [control#gotosleep]=1
//      deepsleep,[control#sleeptime]
   endif  
endon

Let me know if there is anything else I can do.

[TD-er]

So the dummy device is taking lots of resources then?
I will have a look at it on one of the nodes I can connect to the PC to see what's going on.

[dampa]

I don't know what is taking the resources. I have syslog being sent out to a Pi, but after the first deep sleep nothing ever shows on the log even though the WeMos led is flickering. Here is what shows in SYSlog - I have it set to 'info' but could change it if you want. Note there is nothing connected to the WeMos and a single jumper from D0 to RST

May 3 13:29:01 node28 EspEasy: firstLoopConnectionsEstablished
May 3 13:29:02 node28 EspEasy: NTP : NTP replied: delay 101 mSec Accuracy increased by 1.018 seconds
May 3 13:29:02 node28 EspEasy: Time set to 1588526942.018
May 3 13:29:02 node28 EspEasy: Current Time Zone: DST time start: 2020-03-01 02:00:00 offset: -240 min STD time start: 2020-10-25 03:00:00 offset: -300 min
May 3 13:29:02 node28 EspEasy: Local time: 2020-05-03 13:29:02
May 3 13:29:02 node28 EspEasy: EVENT: Clock#Time=Sun,13:29
May 3 13:29:02 node28 EspEasy: EVENT: control#=0.00
May 3 13:29:02 node28 EspEasy: MQTT : Intentional reconnect
May 3 13:29:02 node28 EspEasy: MQTT : Connected to broker with client ID: node28_28
May 3 13:29:02 node28 EspEasy: Subscribed to: wsremote/command/node28/cmd/#
May 3 13:29:02 node28 EspEasy: EVENT: WiFi#ChangedAccesspoint
May 3 13:29:02 node28 EspEasy: EVENT: WiFi#ChangedWiFichannel
May 3 13:29:02 node28 EspEasy: EVENT: WiFi#Connected
May 3 13:29:02 node28 EspEasy: EVENT: Time#Initialized
May 3 13:29:02 node28 EspEasy: EVENT: MQTT#Connected
May 3 13:29:02 node28 EspEasy: ACT : publish wsremote/msg/node28/log,'{"time":"1588526942","status":"awake"}'
May 3 13:29:02 node28 EspEasy: Command: publish
May 3 13:29:02 node28 EspEasy: ACT : timerSet,1,10
May 3 13:29:02 node28 EspEasy: Command: timerSet
May 3 13:29:13 node28 EspEasy: EVENT: Rules#Timer=1
May 3 13:29:13 node28 EspEasy: ACT : publish wsremote/msg/node28/log,'{"time":"1588526953","status":"sleep","sleep":30}'
May 3 13:29:13 node28 EspEasy: Command: publish
May 3 13:29:13 node28 EspEasy: ACT : timerSet,2,1
May 3 13:29:13 node28 EspEasy: Command: timerSet
May 3 13:29:15 node28 EspEasy: EVENT: Rules#Timer=2
May 3 13:29:15 node28 EspEasy: ACT : deepsleep,30
May 3 13:29:15 node28 EspEasy: Command: deepsleep
May 3 13:29:15 node28 EspEasy: EVENT: System#Sleep
May 3 13:29:15 node28 EspEasy: SLEEP: Powering down to deepsleep...
May 3 13:29:16 node28 EspEasy: MQTT : Connection lost, state: Disconnected
pi@fastpi:/var/log $

p,s, anyway to edit the thread title to remove 'with BMx280 not connected'?

[TD-er]

I removed the BME280 part from the title.