high load, device responsive, rules not updatable

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
obod0002c
Normal user
Posts: 119
Joined: 10 Aug 2019, 20:31

high load, device responsive, rules not updatable

#1 Post by obod0002c » 04 Dec 2021, 16:47

not sure, where this new challenge is located: hardware, software, soldering skills, ...

I do have three device up and running, more or less identical firm- and software.
Two device are as well 'identical' ones: https://internetderdinge.blog/produkt/t ... nteckdose/

However, device 'A' is showing a load of around 10% whereas device 'B' is lucky when showing <60% of load.

Updates to the rules for device 'A' are not a problem at all, 'Submitted' appears within a second.
Updates to the rules for device 'B' do most of the times do not work nor show this 'Submitted' hint.

However I was able to upload data to the rules 1 to 4, uploading 1,640+1,513+285+1,826bytes.
When now trying to e.g. delete one chapter, normally nothing happens. Sometimes it works.

Switching on or off one of the two GPIO's or the related LED's does work smoothly.

Do you have any idea what might be problem or where?

One note: when uploading the new firmware (ESP_Easy_mega_20211105_normal_ESP8285_1M) there seemed to be a soldering shortage that I needed to solve.

2nd note: both devices (Flash Chip Real Size: 1024 kB, Flash IDE Size: 1024 kB) show dramatically deviating RAM:
working device 'A':
Free RAM: 20768
Free Stack: 3696
problematic device 'B':
Free RAM: 2944
Free Stack: 3696

Do you have any idea what might cause this behavior?

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: high load, device responsive, rules not updatable

#2 Post by Ath » 04 Dec 2021, 16:57

- are the settings in the Advanced page the same for both devices, especially the WiFi related settings? And is ECO mode turned off on both devices?
- are the devices in the same area, with the same number of WiFi AP in sight, or is device B in an area with (very) poor WiFi RSSI (below -80; -70 or higher is usually fine)?
- is device B shielded by metal objects or thick walls, or close to a 2.4 GHz transmitter source?

Why would the soldering be poor, unless these devices are known to be poorly manufactured :o
/Ton (PayPal.me)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: high load, device responsive, rules not updatable

#3 Post by TD-er » 04 Dec 2021, 21:42

Try pinging to the devices from just any node in the network.
Preferably pinging for a longer time.

Are the ping statistics similar for all nodes?
Do you have lost pings?
Does simply pinging to a node make it act more responsive? (this may very well be happening)

The "slow" nodes, do they have lots of reboots, or WiFi reconnects?
Have you tried using "B/G only mode" ?
What brand of access point do you use?
Is WiFi mesh enabled on the access point?

obod0002c
Normal user
Posts: 119
Joined: 10 Aug 2019, 20:31

Re: high load, device responsive, rules not updatable

#4 Post by obod0002c » 05 Dec 2021, 11:48

The devices are connected to the same AP.
Sockets are close to FRITZ!Box (mesh active), exchanging devices or unplugging the good one does no change for the better.

Poor soldering: had to solder some cables for flashing firmware and those as well as the Dupont connector are still within the device.

Device B was 'cloned' from A using Tools->Setting->Load.

After almost 20h both devices are showing
Flash Writes:0 daily / 0 boot
Number Reconnects:0
Max WiFi TX Power:17.50

But as for the RAM, there's one more major difference:
Device A: Current WiFi TX Power:14.00
Device B: Current WiFi TX Power:4.00 (copied, so no digit missing)

Pings to follow..

obod0002c
Normal user
Posts: 119
Joined: 10 Aug 2019, 20:31

Re: high load, device responsive, rules not updatable

#5 Post by obod0002c » 05 Dec 2021, 13:00

with constant pings on, the device accepted all changes of its rules and load decreased to <15%
How come? Can I trust the device to operate reliable, also no extra - just give me one, only one - ping?

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: high load, device responsive, rules not updatable

#6 Post by Ath » 05 Dec 2021, 14:53

Is the ESP chip used actually an ESP8285 or did you just pick that build? (Couldn't find much on the hardware used, if you have a link available, please share)

If the chip is actually an ESP8266, (the ESP8285 is actually an ESP8266 with on-chip 1MB flash and a few GPIO pins bound to that), it might be possible to use one of the 1M builds that has 'alt_wifi', 'beta' or 'sdk3' in the name, as that has a different version of the Arduino libraries that may handle WiFi somewhat differently.
It is also very possible that the B unit is actually somewhat broken, on its hardware side, f.e. having a poorly performing power supply.
/Ton (PayPal.me)

obod0002c
Normal user
Posts: 119
Joined: 10 Aug 2019, 20:31

Re: high load, device responsive, rules not updatable

#7 Post by obod0002c » 05 Dec 2021, 16:23

I also see only details posted here by me a few 'days' ago:
TYWE2S, ESP8285

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: high load, device responsive, rules not updatable

#8 Post by TD-er » 05 Dec 2021, 19:31

obod0002c wrote: 05 Dec 2021, 13:00 with constant pings on, the device accepted all changes of its rules and load decreased to <15%
How come? Can I trust the device to operate reliable, also no extra - just give me one, only one - ping?
That's a very useful hint here (that's why I suggested it :) ) as this does eliminate quite a lot of possible issues.

What's left is probably related to:
- WiFi TX power -> Select to send with max. TX power
- WiFi sleep mode (sending pings to it, will prevent even short/light sleep) -> uncheck ECO mode if enabled.
- missing ARP requests -> Try with "Periodical send Gratuitous ARP" enabled. See: https://espeasy.readthedocs.io/en/lates ... uitous-arp

And since you mentioned the infamous "WiFi mesh", there are other parameters that may affect this too.
Almost all WiFi mesh networks try to send a disconnect request to connected clients if their RSSI value as seen on the access point gets below some defined strength. (typical default is -75)
Some WiFi mesh implementations do negotiate with other mesh nodes and if a specific client is seen with a stronger RSSI value on an AP to which the client is not connected, then it may disconnect the client.
However ESPEasy tries to reconnect to the last known AP when a connection is lost. This may result in some kind of ping-pong behavior.

If the ESP node does reconnect to "the other" AP in your mesh, then it may be unclear to the rest of the network how to reach that node.
An ESP may not always receive ARP requests and thus it will not reply to such requests and thus the switches and access points will not know how to route packets to that node.
For this, the "Periodical send Gratuitous ARP" was added.

Another issue which may happen on WiFi mesh nodes is that the mesh network itself is also occupied with forwarding traffic between other mesh APs.
This can result in the AP to sometimes skip a beacon interval. If the ESP will enter light sleep mode between beacon intervals, then it may miss the interval when the AP does send out its beacon.
The ESP is then not officially disconnected, but it may take quite a while before both the ESP and the AP get in sync again. The AP may then consider the ESP to be disconnected and thus refuse to forward packets, while the ESP does not know it is disconnected and thus does not try to reconnect.
Since it considers itself connected, attempts to send data will timeout and those timeouts are "blocking" code.
Thus in the computation of the CPU load, it may result in high CPU loads, where it actually is just "waiting for a timeout".

It is best not to use WiFi mesh along with ESP nodes (this probably applies to other 2.4 GHz only devices too)

obod0002c
Normal user
Posts: 119
Joined: 10 Aug 2019, 20:31

Re: high load, device responsive, rules not updatable

#9 Post by obod0002c » 05 Dec 2021, 23:05

I somehow got the impression of hickups that occurred during upload / processing the lengthy rules (5k) and resulting in high load and little RAM. Might be a wrong assumption though ..
Trying to understand the last post, thx ;)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: high load, device responsive, rules not updatable

#10 Post by TD-er » 06 Dec 2021, 00:26

Sure :)
Don't be afraid to ask for clarification on some parts (or all ;) ) of my reply.
I do have a tendency to dive in deep when answering, which may be a bit to much info at once to process.
So make sure your brain doesn't get too high of a CPU load :)

Post Reply

Who is online

Users browsing this forum: No registered users and 36 guests