Almost always inaccessible...

[djdirty60]

Good day,

He is almost always unreachable, has to refresh the page 20 times before it does it again. Homey can never find him because of this.

Bèta 8 Android 11 Chrome

[TD-er]

IP-address of 192.168.178.x suggests you're using Fritzbox as a router. Do you also have WiFi mesh configured? Or a guest network?

[djdirty60]

I have a ziggo router, and just used the wifi setup of the system.

[TD-er]

OK, so not WiFi mesh related.

If you continously ping the node from just any computer in the network, do you get a stable ping or reported ping losses? You may need to add the -t option on Windows to send continous pings instead of just 4.

For example:

ping 192.168.178.40 -t

If the ping is returning relatively stable results and no lost pings, please check if the node is better reachable while such a ping is running.

[djdirty60]

[TD-er]

If you Ctrl-C the running ping, you will get some statistics, including the nr. of failed pings.

Just based on the nrs in your photo it doesn't look like a bad connection.

Have you tried to see if the node does appear to be better reachable while the ping is running? N.B. running continuous pings to an ESP node does change the WiFi behavior, so it might actually appear to be more responsive to other types of communication too.

[djdirty60]

[TD-er]

As I asked in (2) previous posts:

Have you tried to see if the node does appear to be better reachable while the ping is running?

[djdirty60]

Oh sorry, I can log in for now. Without any problems

[TD-er]

That's with the ping running from some host in your network to the node?

This does indicate a few possible issues:

• The ESP may enter some "light sleep" mode in which the WiFi radio is not turning on every period to listen if it is being addressed by the access point (DTIM setting in the access point, which you probably cannot set in those Ziggo modems) Sending pins to the ESP will prevent the node to enter light sleep.
• If using several access points in your network with the same SSID, it may happen the ESP is disconnected from one AP and reconnected to another. However if the MAC tables in the switches do not get updated on this, packets to the ESP may never get delivered to the correct switch port.
• (related to the previous one) The ESP may not receive ARP requests and thus never answers to them => Switch may "forget" where to route packets to for the ESP.

By sending pings continuously, you somehow magically "fix" all these issues. Or at least you make the symptoms disappear.

So for Arjen there are 3 things to look into:

• Periodically send Gratuituous ARP packets from the ESP (aka. answers to ARP questions nobody asked ;) )
• Limit the options for the ESP to enter light sleep mode by either perform busy wait calls instead of calling delay() or add an option to set the WiFi into STA+AP mode instead of just STA. (you don't need to actually run an AP service, but make sure to set the AP channel the same as the AP your ESP connects to)
• Add an option to connect with forced 802.11b or 802.11g mode to have a more stable connection with poor RSSI.

[djdirty60]

Okay this is too complicated for me, but hope the upcoming update will fix the bug if arjen can fix the problem, thanks in advance for your effort and time. And I'll wait and see if the problem can be solved

[roblomq]

For the record, I also have a Ziggo Connect Box and have no connecting problems at all.

[TD-er]

For the record, I also have a Ziggo Connect Box and have no connecting problems at all.

Not al Ziggo modems are the same and also the environment does have an effect on the modems behavior.

One thing for sure that makes quite a difference is having a fixed (2.4 GHz) channel set. Preferrably channel 1, 6 or 11 as all other channels have overlap from twice as many APs in the neighborhood.

Another thing that really makes a difference is whether or not you're using a TV box via WiFi or Ethernet (not coax) The Multicast traffic may do very strange things on some switches and on the ESP. Some switches allow to have IGMP snooping enabled, which shields other ports from Multicast traffic if there is no device on such a port asking for multicast traffic. But when using a switch which doesn't know about such settings, then you can get very strange behavior on your network on some devices.

This to illustrate that even though you may be paying the same ISP a monthly fee, the issues may be completely different. Also there is still a "former UPC" region, which is still a completely different network compared to "former Ziggo" (or @home) region.

[arjenhiemstra]

Thanks for your analysis Gijs! I'll work on it once I'm back from holiday and in the process I might ask a question or 2 Gijs ;-). @djdirty60 that will be somewhere late aug.

Limit the options for the ESP to enter light sleep mode by either perform busy wait calls instead of calling delay()

In your experience, could calling vTaskDelay cause the esp32 to go into (light) sleep? I cannot find anything about it in the esp-idf documentation.

[TD-er]

In ESPEasy I have an option called "ECO" mode. What this does is every time there is nothing to do, I call delay() for the amount of msec until I have something else to do. The side effect is that the ESP will significantly reduce energy consumption, by entering light sleep and automatically changing the DTIM (the nr of beacon intervals it will sleep before listening again) This DTIM setting should (IMHO) remain constant, or at least only be changed when intended. But this may have annoying side effects if the access point does not expect this.

With WiFi, the AP controls everything. It will send out a beacon every beacon interval (most common interval is 102.4 msec). Such a beacon packet may also contain information telling a connected node to ask the AP for new data. If there is a continuous flow of data, the client will of course ask for new data more frequently, but to reduce energy consumption the client may enter some kind of low(er) power mode where it only listens to such beacon packets and only reply when asked for. The DTIM setting allows the client to perform longer sleeps and thus skip a number of beacon interval periods. However the AP must know (and accept) this DTIM as it needs to store packets longer before it can deliver them to the client.

If the AP doesn't know the client is taking a longer sleep, it just assumes it is no longer in range or maybe no longer connected. Anyway the packet may timeout and is removed from the buffers.

For some types of communication, this may result in timeouts but the next attempt may succeed. However for replying to ARP requests ("Who has 192.168.178.40?" for example), the consequences may be more serious. A host configured to use that IP who sees such an ARP request must reply with its MAC address ("AA:BB:CC:DD:EE:FF has 192.168.178.40") Since such ARP requests (and the reply) are layer 2, each switch in the network can also see these packets. The switch (and AccessPoint) will update its MAC tables accordingly by keeping track of the port the ARP reply came from.

But this info in the MAC tables will eventually be flushed and thus an AP or switch may no longer know to which port the packet for that MAC address should be sent to. By sending a Gratuitous ARP packet, you're giving an answer to the question nobody asked (yet). But this may help switches and APs to populate or update their MAC tables.

Now the actual problem.... The ESP may not get out of this low power mode unless it has to do a number of network packets for a longer period, or by replying to a ping. You can see this by looking at the current consumption of a node. The first ping to it (after a few minutes idling) may take several 100s of msec to get a reply, but then the power consumption will immediately rise and remain high as long as pings are being sent to the host. Another way to prevent the low power mode is to have the ESP run with AP mode active.

By not calling delay() in the code, but just do the next loop(), the ESP is also less likely to enter the low power mode.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.