ESP8266 unaccessible / out of range?

[Ton_vN]

My configuration has a number of ESP8266-with-ESPEasy interfacing to 2*RPI-with-Domoticz through (W)LAN under application of Domoticz_HTTP
All OK till latest upgrade of Domoticz to stable release 2020.2

Now ESP8266s 'strike' for communication to 1 RPI3B-with-Domoticz.
Other clients incl. Luftdaten-NMCU have no problems, which seems sign that WLAN in principle is OK.
At same (W)LAN a RPI3A+-with-Domoticz has no problems communicating with ESP8266es.
With ESPEasy v2.x and it's capability for multiple Controller easy to solve.
However not all ESP8266es yet having v2.x (but R146 or R147) and now all not accessible by IP-call to check & shift settings to other Controller.

Anybody with similar experience and hint to revive the communication between ESP8266es and Domoticz?

[TD-er]

Just to be sure, what recent update broke this?
Domoticz or ESPEasy?

Last update I made on Domoticz here was roughly around January and then I also had to upgrade the Debian on it as it refused to work anymore and no proper way of downgrading Domoticz.

[Ton_vN]

@TDer

In my view the problem started after upgrade of Domoticz on both RPIs.
Before upgrade both running same Debian Buster and same Domoticz. stable 2020.1
Upgrade was towards Domoticz 2020.2

Not knowing where to look, perhaps non-essential info, but
# RPI3B with problems is well-loaded with software and (>10) ESP8266es.
# RPI3A+ without problems has very low functional load and less ESP8266es
[this RPI3A+ has an ethernet USB-plug and in this way for (W)LAN-interfaces equivalent to the RPI3B]

Because RPI3B has problem, but RPI3A+ not, tend to think that the Domoticz-upgrade is culprit,
but an interface has two sides, therefore interaction with ESP8266-side always an aspect to consider.
ESP8266es all stayed unchanged at same location, but access through (W)LAN by IP-call seems more difficult, which is also bewildering.

[TD-er]

This is the Domoticz I'm running here:

Code: Select all

Version: 4.11665
Build Hash: ec3292db7
Compile Date: 2020-01-28 08:45:51
dzVents Version: 2.5.7
Python Version: None

If yours is newer, I will make sure to have a backup and install an update of it.

[Ton_vN]

Meanwhile Domoticz at 12004, running OK at my cabled 'test'-RPIs.

The subject (W)LAN-segment consists of:
a) = 1* WiFi-router & ethernetswitch feeding WLAN + LAN
b) = 2* Wifi AccessPoint connected by LAN
c) = 1* WiFi-repeater nearest to 1)

c) is just listening to a) and transmitting in relais
b) are independently cloning a) at a remote location

WLAN has erratic behaviour, while LAN-component seems OK.
Just speculation (perhaps brainwave):
- if Wifi of a) is faulty, then c) has trouble as well to communicate with related ESP8266es
- the Wifi of the WAPs of b) is then 'differing' from a) and c), which may cause/explain other problems in the WLAN
- disabling the Wifi of a) also disables c)
Perhaps worth the test to disable the Wifi of a) and replace by another WiFi-router mimicking the Wifi of present a) with the settings of b):
with 3* cabled WAP possibly then Wifi-access again (incl. via c) to various ESP8266es and RPIs.
Seems prudent to change c) to a cabled WAP or via interface by Dataplug over 230V:
then identical to b), all WAPs under full control via cable or via dataplug => WLAN should be synchronuous.

Anybody comments or better ideas?
Work for tomorrow .......

[TD-er]

If possible, try to set the repeater to use a different SSID.

For example your router has SSID "foo", then the repeater connects to "foo" and sends out its own SSID as "bar".

This way you know for sure what device is connected via what route.
Problem with repeaters is that they not only cause a delay and more than double the use of the ether, but they also introduce other issues.
One of those issues is that they may be busy relaying a message and thus causing interference on the next message sent by the sender.
This is particularly bad on traffic that doesn't expect an acknowledgement, like UDP or ARP packets.
But also when a connection is kept open between server and client to keep sending updates (e.g. AJAX page updates).
This is used quite often in modern web UI tools as you can send updates much faster as you don't need to periodically poll and also don't need to make a new connection.

If ARP packets are lost, then you could enable sending periodical Gratuitous ARP packets by ESPEasy (Tools => Advanced => Right at the bottom of the page)

[Ton_vN]

@TDer

Exactly my reasoning to change the WiFi-repeater to cabled WAP:
- repeater = 2* Wifi-path, in both paths with 'uncertainty/capacity-limit' related to load & interference + repeat delay
- WAP = max. speed cable-transfer + 1*Wifi-path

Never sure that the ESP8266 always takes the most direct Wifi-channel for communication.
Something possible with MAC-filtering?
Argument 'against' is that now automatic change is possible between WAPs with same SSID.

Technically, cabled interfaces safest and fastest (but limited WAF compared to wireless devices)!

No experience, but may the exchange-protocol between ESPEasy and Domoticz make a difference?
Now Domoticz_HTTP.
Somewhere a trade-off available, with description of actions required for change?

[TD-er]

MQTT is by far the better option as it does keep the connection open (unless the connection is really bad)

ESPEasy does have some memory when it comes to re-establish a wifi connection.
The first attempt when loosing a connection is to re-connect to the last known BSSID on the last known channel.
By using the same BSSID, you will reconnect to either the repeater or the access point, whatever was used the last time.

If the channel has changed, or a reconnect attempt failed for whatever other reason, then the strongest one will be picked with a known SSID.

[Ton_vN]

@TDer

MQTT keeps the connection open (unless the connection is really bad)

Question for understanding 'what-if'
How to combine MQTT with Sleep-mode (in which the ESP periodically on purpose closes the connection)?

[TD-er]

@TDer

MQTT keeps the connection open (unless the connection is really bad)

Question for understanding 'what-if'
How to combine MQTT with Sleep-mode (in which the ESP periodically on purpose closes the connection)?

Well that's not too uncommon

When you connect to MQTT, you do set a LWT (last will and testament) in the broker.
So if your node is no longer connected to the broker (e.g. when no keep-alive ping was received), then the broker will publish your LWT messages to the set topics.

This way, the other clients that may have subscribed to these topics, will get a notification about the absence of that node.

As soon as ESPEasy boots, it does try to attempt to connect to the broker. But that's also happening when the connection was broken for whatever other reason.