search

letscontrolit / ESPEasy

Easy MultiSensor device based on ESP8266/ESP32
http://www.espeasy.com
Other
3.23k stars 2.2k forks source link

One WEMOS device crashes keeps rebooting wirh 20193005 #2393

Closed berbergh closed 4 years ago

berbergh commented 5 years ago

Checklist

I have...

Steps already tried...

If you self compile, please state this and PLEASE try to ONLY REPORT ISSUES WITH OFFICIAL BUILDS!

Summarize of the problem/feature request

I have several WEMOS D1 mini devices. They all work fine with ESP_Easy_mega-20190311_test_core_242_ESP8266_4M.bin Except for one, It simply keeps rebooting with ESP_Easy_mega-20190305_test_core_242_ESP8266_4M.bin and later.

ESP_Easy_mega-20190227_test_core_242_ESP8266_4M.bin wors okay.

Expected behavior

Update should work fine

Actual behavior

Device keeps rebooting

Steps to reproduce

  1. have ESP_Easy_mega-20190227_test_core_242_ESP8266_4M.bin
  2. upload ESP_Easy_mega-20190311_test_core_242_ESP8266_4M.bin

System configuration

Hardware: WeMos D1 with MHZ19 and OLED

ESP Easy version: ESP_Easy_mega-20190305_test_core_242_ESP8266_4M.bin

ESP Easy settings/screenshots:

Rules or log data


wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vbb28d4a3
~ld
5⸮U80 : 

INIT : Booting version: mega-20190311 (ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 PUYA support)
81 : INIT : Free RAM:25304
81 : INIT : Warm boot #32 - Restart Reason: Hardware Watchdog
84 : FS   : Mounting...
109 : FS   : Mount successful, used 76053 bytes of 957314
513 : CRC  : program checksum       ...OK

 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
TD-er commented 5 years ago

What plugins/controllers are active on that node?

berbergh commented 5 years ago

Only Gases - CO2 MH-Z19 with Softserial and Display - OLED SSD1306/SH1106 Framed

TD-er commented 5 years ago

Can you please check the power supply and USB cable of that unstable node? That CO2 sensor may need quite a peak current as will the ESP at boot.

berbergh commented 5 years ago

5 Volt, 1Amp. Same power supply works fine with other devices and this device works fine with older releases. I tested the device with other power supplies, with the same result.

Verzonden vanuit Mail voor Windows 10

Van: Gijs Noorlander Verzonden: donderdag 14 maart 2019 20:24 Aan: letscontrolit/ESPEasy CC: berbergh; Author Onderwerp: Re: [letscontrolit/ESPEasy] One WEMOS device crashes keeps rebootingwirh 20193005 (#2393)

Can you please check the power supply and USB cable of that unstable node? That CO2 sensor may need quite a peak current as will the ESP at boot. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

TD-er commented 5 years ago

Did you also exchange the USB cable, just to be sure? It's so strange it is only 1 that's failing.

Have you also tested with the plugins disabled? What are the differences between that node and the rest (output controllers, wifi location/reception quality, used plugins)

berbergh commented 5 years ago

To be honest, more devices are behaving weird. I have a Wemos with only the Nextion and MQTT Plugin that keeps failing. I started it today with a new cable, a new power supply and the web logging on, For a while it runs fine, but then :

8133929: EVENT: MQTT1#RFLWsTH_h=24.00 8162196: WD : Uptime 136 ConnectFailures 6 FreeMem 12088 WiFiStatus 3 8192187: EVENT: Clock#Time=Sat,17:43 8192236: WD : Uptime 137 ConnectFailures 6 FreeMem 10808 WiFiStatus 3 8222196: WD : Uptime 137 ConnectFailures 6 FreeMem 12088 WiFiStatus 3 8252186: EVENT: Clock#Time=Sat,17:44 8252233: WD : Uptime 138 ConnectFailures 6 FreeMem 12088 WiFiStatus 3 8282196: WD : Uptime 138 ConnectFailures 6 FreeMem 12088 WiFiStatus 3 8312185: EVENT: Clock#Time=Sat,17:45 8312233: WD : Uptime 139 ConnectFailures 6 FreeMem 12088 WiFiStatus 3 8319851: IMPT : [MQTT1#RFLWsTH_t] : 10.90 8319852: EVENT: MQTT1#RFLWsTH_t=10.90 8319928: IMPT : [MQTT1#RFLWsTH_h] : 24.00 8319930: EVENT: MQTT1#RFLWsTH_h=24.00 8342196: WD : Uptime 139 ConnectFailures 6 FreeMem 12088 WiFiStatus 3 8372186: EVENT: Clock#Time=Sat,17:46 8372233: WD : Uptime 140 ConnectFailures 6 FreeMem 12088 WiFiStatus 3

NetworkError when attempting to fetch resource. << NetworkError when attempting to fetch resource. << NetworkError when attempting to fetch resource. << NetworkError when attempting to fetch resource. << NetworkError when attempting to fetch resource. << NetworkError when attempting to fetch resource. << NetworkError when attempting to fetch resource. << NetworkError when attempting to fetch resource. <<

Verzonden vanuit Mail voor Windows 10

Van: Gijs Noorlander Verzonden: zaterdag 16 maart 2019 17:51 Aan: letscontrolit/ESPEasy CC: berbergh; Author Onderwerp: Re: [letscontrolit/ESPEasy] One WEMOS device crashes keeps rebootingwirh 20193005 (#2393)

Did you also exchange the USB cable, just to be sure? It's so strange it is only 1 that's failing. Have you also tested with the plugins disabled? What are the differences between that node and the rest (output controllers, wifi location/reception quality, used plugins) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

TD-er commented 5 years ago

Does it have the first MQTT controller enabled? Can you as a test let some plugin communicate to that controller?

Another thing you may test is to let a host send continuously ping to that node. It happens to be that receiving pings does something in the ESP to keep the wifi connection stable.

berbergh commented 5 years ago

Also tested with devices disables, without success.

Verzonden vanuit Mail voor Windows 10

Van: Gijs Noorlander Verzonden: zaterdag 16 maart 2019 17:51 Aan: letscontrolit/ESPEasy CC: berbergh; Author Onderwerp: Re: [letscontrolit/ESPEasy] One WEMOS device crashes keeps rebootingwirh 20193005 (#2393)

Did you also exchange the USB cable, just to be sure? It's so strange it is only 1 that's failing. Have you also tested with the plugins disabled? What are the differences between that node and the rest (output controllers, wifi location/reception quality, used plugins) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

TD-er commented 5 years ago

Any other parameter is the same as the other (stable) nodes?

Especially the wipe is something I would suggest to try.

On top of that, you can try to add a capacitor between the 3V3 and GND line. Something like 10uF + 100 nF

berbergh commented 5 years ago

The device with the Nextion and the MQTT plugin was very stable with previous versions for a long time. The MQTT plugin get information from the MQTT broker via a controller on the first position in the ESPEasy device. The Nextion plugin uses that information the display values.

I have set Domoticz to ping the faulty devices.

Verzonden vanuit Mail voor Windows 10

Van: Gijs Noorlander Verzonden: zaterdag 16 maart 2019 18:26 Aan: letscontrolit/ESPEasy CC: berbergh; Author Onderwerp: Re: [letscontrolit/ESPEasy] One WEMOS device crashes keeps rebootingwirh 20193005 (#2393)

Does it have the first MQTT controller enabled? Can you as a test let some plugin communicate to that controller? Another thing you may test is to let a host send continuously ping to that node. It happens to be that receiving pings does something in the ESP to keep the wifi connection stable. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

berbergh commented 5 years ago

I have just started with a wiped WeMos. Unfortunately it was not possible to restore the config due to

Update: config.dat sleep disable ................................ERROR[10]: Magic byte is wrong, not 0xE9 Update: config.dat sleep disable ................................ERROR[10]: Magic byte is wrong, not 0xE9

This is an issue.

For now it is running again. Let’s see how it behaves over time.

Verzonden vanuit Mail voor Windows 10

Van: Gijs Noorlander Verzonden: zaterdag 16 maart 2019 22:36 Aan: letscontrolit/ESPEasy CC: berbergh; Author Onderwerp: Re: [letscontrolit/ESPEasy] One WEMOS device crashes keeps rebootingwirh 20193005 (#2393)

Any other parameter is the same as the other (stable) nodes? • Complete wipe of the flash + reinstall (blank files included in the ZIP download) • wifi reception • sending ping to the node from some computer • switched power supply • switched USB cable Especially the wipe is something I would suggest to try. On top of that, you can try to add a capacitor between the 3V3 and GND line. Something like 10uF + 100 nF — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

berbergh commented 5 years ago

Seems I made a mistake with uploading the config. It works fine now. Nevertheless, it is kind of an issue to first completely wipe the ESPEasy devices, before loading a new release, as some of them are hard to get at.

TD-er commented 5 years ago

I know and I have not yet found a way to remove the parts where the core libraries store their WiFi config. This is not in a region where we normally write stuff. It would be ideal to perform a factory default including a full wipe of every spot where the sketch itself is not stored.

berbergh commented 5 years ago

It seems the completely wiping and programming action only works for a short period of time. Within a couple of days, the devices stop responding and working.

TD-er commented 5 years ago

Hmm, that's an interesting observation. Wiping the flash could help if it was having an incorrect configuration somewhere. But if it is "back to instability" after a few days, then it isn't just a wrong setting.

berbergh commented 5 years ago

I can imagine it is a bit of a puzzle. I just went back to 20181004 with two devices and the stay alive for quite some time now.

Verzonden vanuit Mail voor Windows 10

Van: Gijs Noorlander Verzonden: zondag 24 maart 2019 17:58 Aan: letscontrolit/ESPEasy CC: berbergh; Author Onderwerp: Re: [letscontrolit/ESPEasy] One WEMOS device crashes keeps rebootingwirh 20193005 (#2393)

Hmm, that's an interesting observation. Wiping the flash could help if it was having an incorrect configuration somewhere. But if it is "back to instability" after a few days, then it isn't just a wrong setting. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

berbergh commented 5 years ago

The same problem occurs with later releases, but it is spurious. Some WeMosses work, but the majority is not stable de. Do you think i should try one the Alpha,s? If this problem is not solved i cannot benefit from the goodies of later development.

TD-er commented 5 years ago

The core 2.6.0 will probably not work for last night's build. (only last night's build) See https://github.com/esp8266/Arduino/issues/5974

berbergh commented 5 years ago

@td-er Regarding your reference to #5974, do you recommend me to try it again with the latest release? Which one? 242 OR 260?

TD-er commented 5 years ago

The last build should work again for core 2.6.0 A fix has been merged in PlatformIO to make it generate a complete binary again. So the last nightly should work.

berbergh commented 5 years ago

Problem is narrowed down to domotica mqtt.

TD-er commented 5 years ago

@berbergh Can you be a bit more specific? I think you mean domoticz and not just any MQTT based controller? And what are your last findings?

Can you also test with core 2.5.2 builds? That's a core version which has a number of rather nasty network related issues fixed.

berbergh commented 5 years ago

To be more specific: I run this on a Wemos D1 with two controllers enabled: Domoticz HTTP and Domoticz MQTT.

Build:⋄ 20103 - Mega System Libraries:⋄ ESP82xx Core 2.6.0-dev, NONOS SDK 3.0.0-dev(c0f7b44), LWIP: 2.1.2 PUYA support Git Build:⋄ mega-20190607 Plugins:⋄ 80 [Normal] [Testing] Build Time:⋄ Jun 7 2019 02:29:06 Binary Filename:⋄ ESP_Easy_mega-20190607_test_core_260_sdk3_alpha_ESP8266_4M.bin

With the MQTT on the controller page enabled, the Wemos stops working or being visible in the web page, within minutes to hours. With the MQTT on the controller page disabled, it keeps working for several days now.

This happens with and without having a MQTT Import device active or even installed.

I will try with 2.5.2.

TD-er commented 5 years ago

With MQTT there will be quite a bit more network traffic to the node, since it is receiving other messages from the broker too. Domoticz lets the units subscribe to the same topics, and thus your unit does receive the MQTT messages of other too.

Another test you may want to try is running a ping (from whatever computer on the network) continuously to the node you're testing. I expect the unit to be more stable when also handling ICMP packets. And the frustrating part is that I have no clue why....

jimmys01 commented 5 years ago

Domoticz MQTT (C002) has been updated with the new JSON that won't use dynamicaly allocated memmory. Perhaps you can give it a try.

berbergh commented 5 years ago

I loaded mega-20190626 a couple of hours ago. Still running

Op za 29 jun. 2019 15:43 schreef jimmys01 notifications@github.com:

Domoticz MQTT (C002) has been updated with the new JSON that won't use dynamicaly allocated memmory. Perhaps you can give it a try.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/letscontrolit/ESPEasy/issues/2393?email_source=notifications&email_token=AA4CMGCCLWOOCS4ANGKRK73P45RJVA5CNFSM4G53HVJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY3ZBFY#issuecomment-506957975, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4CMGD26KJTYDG34YS56A3P45RJVANCNFSM4G53HVJA .

TD-er commented 5 years ago

@jimmys01 I don't expect it to be a memory allocation issue with the Domoticz MQTT controller. It sounds more like a network thing, of which 2 issues were fixed right before releasing core 2.5.2.

berbergh commented 5 years ago

At first 2.5.2 seemed to be more stable, but it only takes a little longer to stop. Devices without mqqt, are more reliable.

TD-er commented 5 years ago

I have some setup here that allows me to trigger these reboots and at least in my setup here it is always crashing at a WiFi reconnect cycle. It is always crashing when it is about to receive the IP-address (N.B. the same phase for static IP setups) I can reproduce it here by forcing a disconnect from my AP for that specific node. Sometimes (when there was no traffic at all) the unit doesn't even seem to know it was disconnected (I don't see the disconnect event) and it always crashes when there is traffic or traffic starting to happen within a few seconds from the moment of disconnect.

So statistically speaking, it makes sense there is more likely to be a crash when MQTT is enabled, since that's causing a lot more traffic.

berbergh commented 5 years ago

Right

And now the solution ...

Op vr 5 jul. 2019 16:46 schreef Gijs Noorlander notifications@github.com:

I have some setup here that allows me to trigger these reboots and at least in my setup here it is always crashing at a WiFi reconnect cycle. It is always crashing when it is about to receive the IP-address (N.B. the same phase for static IP setups) I can reproduce it here by forcing a disconnect from my AP for that specific node. Sometimes (when there was no traffic at all) the unit doesn't even seem to know it was disconnected (I don't see the disconnect event) and it always crashes when there is traffic or traffic starting to happen within a few seconds from the moment of disconnect.

So statistically speaking, it makes sense there is more likely to be a crash when MQTT is enabled, since that's causing a lot more traffic.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/letscontrolit/ESPEasy/issues/2393?email_source=notifications&email_token=AA4CMGDVDV6AATUOQJUGNT3P55NDZA5CNFSM4G53HVJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZJWKRI#issuecomment-508781893, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4CMGAV3DRPSCILLWBCYOLP55NDZANCNFSM4G53HVJA .

TD-er commented 5 years ago

That would be nice indeed :) At least I'm already happy to have some setup that will crash predictably. So we're closer to a solution than we've been in the last year.

berbergh commented 4 years ago

Unfortunately, there is no chance in behaviour, so far. Also release 296 does not prevent the Wemos from crashing.

Am I the only one whose MQTT connection is virtually unusable?

TD-er commented 4 years ago

Have you tried one of the latest builds? I have recently made some (huge) progress in WiFi stability. It appeared one of the main reasons for WDT reboots was when the WiFi needed to reconnect. That issue is now fixed (finally!!!!!, looked for over a year to fix it), but there are still others left. MQTT is running fine on my nodes. (running builds from the last week)

berbergh commented 4 years ago

I just came back from a holiday. I tested tis release imediately last night:ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support. Mega-20190817 It worked well for a number of hours, but I found it irresponsive this morning. On this device I connect via Domoticz MQTT and Domoticz HTPP. It seems the troubles aren't over yet.

Note: I just loaded this release over the previous version, mega-20190731. Do I have to kind of factory reset it?

TD-er commented 4 years ago

If such a node becomes unresponsive, can you check and see if it shows up as a AP with the name of the unit as SSID? I've had 2 nodes here that also disappeared from my network after a few days and I have not yet found what has happened. Last night, I noticed a lot of my nodes were showing up as AP, so I'm now working on that problem, which will be merged today. Do you have a fixed channel on your AP, or is it allowed to change channels? If so, it could be the active AP mode (which is not supposed to happen) is forcing the node on one channel and thus it may be unable to scan for a network or switch to another WiFi channel.

berbergh commented 4 years ago

I will check AP mode after a crash. My AP has forced working channels.

TD-er commented 4 years ago

You can already see the AP mode before the crash. I've been working on the WiFi code today and it makes perfect sense why it cannot reconnect if AP is active. So I'm working through all this code and try to remove all the checks and fall back code that entered the WiFi code in the last year to find out what caused it to be so unstable. But that's also quite some change, so even if I manage to 'fix' it before the nightly build, I will not yet merge it. I will first make a test build to see if I made some obvious mistakes.

berbergh commented 4 years ago

I am sorry to say that the device crashed again. It did not enter ap mode.

TD-er commented 4 years ago

What build do you run? Normal 4M?

berbergh commented 4 years ago

night:ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support. Mega-20190817, the 4M test core.

TD-er commented 4 years ago

test build Only flash this if you have easy access to the node. It is working fine on my breadboard, but I have still some issues when starting with a clean setup.

berbergh commented 4 years ago

I just flashed my WeMos with your code.

berbergh commented 4 years ago

A second device with the 4M Mega-20190817 test core. crashed. It does act as an AP now. I am going to reboot it and flash your special firmware. The device I flashed with that firmware yesterday, is still alive :-)

TD-er commented 4 years ago

I have made a build last night, I will upload it so you can test that one. It has some more improvements since the build I linked 14h ago.

ESPEasy_mega-20190817-21-PR_2559.zip

berbergh commented 4 years ago

Okay, thanks. As for now, the majority of my devices run on the mega-20190817 ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support build. Two exceptions: named Nextion and Dust. Nextion now runs for almost 14 hours on your upload of yesterday. So far, so good. (this is a duration record) Dust has been flashed with that release earlier today, but it crashed nevertheless. Dust wil now be flashed with your newest upload.

TD-er commented 4 years ago

What plugin is "Dust" using? And can you also have a look at the "timing stats" page. Load it once after boot, to clear stats and then again after some time. Preferably an interval in which at least 5 reads of the "dust" plugin have been processed.

berbergh commented 4 years ago

All right. Dust uses:

Display - OLED SSD1306/SH1106 Framed | OLED |   |   | GPIO-4GPIO-5 | Edit | 2 | ✔ | Gases - CO2 MH-Z19 | CO2 | SoftwareSerial | ❶ (1) | GPIO-2GPIO-0 Edit | 3 | ✔ | Dust - PMSx003 | Dust | HW Serial0 swap | ❶ (513) | GPIO-13GPIO-15GPIO-14

Timing stats of Dust just after reboot: (hope this is what you require)

P_36_Display - OLED SSD1306/SH1106 Framed READ 2 0.11 106.220 118.282 130.345
P_36_Display - OLED SSD1306/SH1106 Framed ONCE_A_SECOND 16 0.85 0.609 1.234 2.645
P_36_Display - OLED SSD1306/SH1106 Framed TEN_PER_SECOND 133 7.08 0.015 0.019 0.123
P_36_Display - OLED SSD1306/SH1106 Framed WRITE 3 0.16 0.123 0.176 0.231
P_36_Display - OLED SSD1306/SH1106 Framed EVENT_OUT 3 0.16 0.027 0.044 0.058
P_36_Display - OLED SSD1306/SH1106 Framed FIFTY_PER_SECOND 622 33.13 0.014 0.018 0.116
P_49_Gases - CO2 MH-Z19 READ 1 0.05 32.746 32.746 32.746
P_49_Gases - CO2 MH-Z19 ONCE_A_SECOND 16 0.85 0.038 0.041 0.064
P_49_Gases - CO2 MH-Z19 TEN_PER_SECOND 133 7.08 0.023 0.027 0.077
P_49_Gases - CO2 MH-Z19 WRITE 3 0.16 0.236 0.325 0.378
P_49_Gases - CO2 MH-Z19 EVENT_OUT 3 0.16 0.038 0.052 0.072
P_49_Gases - CO2 MH-Z19 FIFTY_PER_SECOND 622 33.13 0.026 0.028 0.116
P_53_Dust - PMSx003 READ 1 0.05 0.140 0.140 0.140
P_53_Dust - PMSx003 ONCE_A_SECOND 16 0.85 0.015 0.020 0.046
P_53_Dust - PMSx003 TEN_PER_SECOND 133 7.08 0.076 0.100 0.149
P_53_Dust - PMSx003 WRITE 3 0.16 0.010 0.037 0.076
P_53_Dust - PMSx003 EVENT_OUT 3 0.16 0.022 0.032 0.039
P_53_Dust - PMSx003 FIFTY_PER_SECOND 622 33.13 0.011 0.015 0.054
C_1_Domoticz HTTP CPLUGIN_PROTOCOL_SEND 1 0.05 1.527 1.527 1.527
Load File   44 2.34 1.075 2.423 18.915
Loop   45599 2428.84 0.210 0.373 985.461
Plugin call 50 p/s   622 33.13 1.273 1.582 6.516
Plugin call 10 p/s   133 7.08 1.346 1.619 3.772
Plugin call 10 p/s U   133 7.08 0.121 0.176 0.276
Plugin call 1 p/s   16 0.85 2.595 6.751 32.943
SensorSendTask()   4 0.21 8.531 118.596 205.611
sendData()   3 0.16 3.173 57.633 165.719
Compute formula   3 0.16 0.023 0.036 0.057
setNewTimerAt()   930 49.54 0.073 0.205 0.310
Delay queue C001   1 0.05 11.296 11.296 11.296
try_connect_host() (TCP)   1 0.05 6.091 6.091 6.091
hostByName()   2 0.11 0.102 0.120 0.139
connectClient()   2 0.11 4.529 4.578 4.627
LoadCustomTaskSettings()   1 0.05 46.289 46.289 46.289
WiFi.isConnected()   136216 7255.57 0.018 0.024 0.235
WiFi.isConnected() (fail)   75 3.99 1.034 1.099 1.961
LoadTaskSettings()   28 1.49 3.242 3.945 6.366
TryOpenFile()   54 2.88 0.315 0.849 9.238
rulesProcessing()   9 0.48 17.512 39.537 91.890
sendGratuitousARP()   9 0.48 0.549 0.635 0.760
backgroundtasks()   90400 4815.17 0.019 0.063 267.832
handle_schedule() idle   44684 2380.10 0.087 0.097 2.324
handle_schedule() task   915 48.74 0.326 2.702 308.339
TD-er commented 4 years ago

Timing stats of Dust just after reboot: (hope this is what you require)

Well no, the stats will be cleared every time you load that page. So rather I would like to see stats not including the boot, but the 2nd load of that page. Preferably with some time in between so the stats cover a longer time. This looks like 16sec after boot :)

I want to see the rows with READ to show at least 5 in the 3rd column. (do not leave out rows, this is just an indication what minimal time I need)

So if you get the stats right now (when no reboot has happened inbetween) that would be great.

berbergh commented 4 years ago
Description Function #calls call/sec min (ms) Avg (ms) max (ms)
P_36_Display - OLED SSD1306/SH1106 Framed READ 483 0.10 106.943 117.578 138.591
P_36_Display - OLED SSD1306/SH1106 Framed ONCE_A_SECOND 4589 0.95 0.577 0.684 3.411
P_36_Display - OLED SSD1306/SH1106 Framed TEN_PER_SECOND 45606 9.46 0.011 0.017 0.066
P_36_Display - OLED SSD1306/SH1106 Framed WRITE 110 0.02 0.169 0.185 0.270
P_36_Display - OLED SSD1306/SH1106 Framed EVENT_OUT 573 0.12 0.022 0.037 0.059
P_36_Display - OLED SSD1306/SH1106 Framed FIFTY_PER_SECOND 225129 46.69 0.010 0.018 0.068
P_49_Gases - CO2 MH-Z19 READ 80 0.02 9.759 25.095 34.586
P_49_Gases - CO2 MH-Z19 ONCE_A_SECOND 4589 0.95 0.030 0.038 0.058
P_49_Gases - CO2 MH-Z19 TEN_PER_SECOND 45606 9.46 0.023 0.028 0.072
P_49_Gases - CO2 MH-Z19 WRITE 110 0.02 0.309 0.340 0.458
P_49_Gases - CO2 MH-Z19 EVENT_OUT 573 0.12 0.034 0.042 0.063
P_49_Gases - CO2 MH-Z19 FIFTY_PER_SECOND 225129 46.69 0.022 0.028 0.074
P_53_Dust - PMSx003 READ 80 0.02 0.039 0.088 0.344
P_53_Dust - PMSx003 ONCE_A_SECOND 4589 0.95 0.011 0.016 0.035
P_53_Dust - PMSx003 TEN_PER_SECOND 45606 9.46 0.075 0.101 2.058
P_53_Dust - PMSx003 WRITE 110 0.02 0.023 0.034 0.051
P_53_Dust - PMSx003 EVENT_OUT 573 0.12 0.018 0.030 0.050
P_53_Dust - PMSx003 FIFTY_PER_SECOND 225129 46.69 0.010 0.015 0.062
C_1_Domoticz HTTP CPLUGIN_PROTOCOL_SEND 90 0.02 1.439 1.493 1.727
Load File   5880 1.22 1.225 1.868 20.756
Loop   14779909 3065.02 0.210 0.301 30156.398
Plugin call 50 p/s   225129 46.69 1.444 1.606 7.254
Plugin call 10 p/s   45606 9.46 1.513 1.642 6.804
Plugin call 10 p/s U   45606 9.46 0.110 0.168 0.287
Plugin call 1 p/s   4589 0.95 2.608 56.175 30155.793
SensorSendTask()   643 0.13 6.314 121.126 409.171
sendData()   573 0.12 3.829 27.914 399.762
Compute formula   573 0.12 0.018 0.022 0.034
setNewTimerAt()   327510 67.92 0.195 0.216 0.361
Delay queue C001   90 0.02 10.256 14.131 54.354
try_connect_host() (TCP)   90 0.02 5.196 7.257 38.057
hostByName()   95 0.02 0.107 0.385 2.678
connectClient()   184 0.04 3.823 6.237 36.707
WiFi.isConnected()   44120316 9149.55 0.018 0.012 3.083
LoadTaskSettings()   5790 1.20 3.395 3.949 11.322
TryOpenFile()   6239 1.29 0.299 0.636 4.430
rulesProcessing()   359 0.07 17.554 717.922 30152.496
sendGratuitousARP()   920 0.19 0.323 0.636 0.769
backgroundtasks()   29237064 6063.10 0.053 0.067 567.098
handle_schedule() idle   14452488 2997.12 0.087 0.120 567.744
handle_schedule() task   327421 67.90 0.275 2.718 30156.137
Start Period: 2019-08-23 15:02:20
Local Time: 2019-08-23 16:22:42
Time span: 4822.13 sec
TD-er commented 4 years ago

Can you also post the rules here? It seems one run of the rules took a whoppin' 30+ seconds. And on average 717 msec is also way too long. Are you using delay in the rules?

If some URLs contain private info, you may also replace those with URL