ESP8266 readout by Domoticz stops

[Ton_vN]

In my configuration Domoticz@Raspberry3 as controller reads the ESP8266s-with-ESPEasy.
Till approx. 2 weeks ago without problems related to continuity.
But now every day (rather randomly) at the side of Domoticz the read-out stops.
When directly calling the ESP8266s at their IP-addresses, I get response, telling me that the problem apperently is not at the side of the ESPs.
Practical remedy is simple, but rude:
when visually detected that read-out has stopped, via Putty I command to Domoticz@Raspberry a reboot.

Other people with comparable experience?
What could be the cause?
Better remedy available than manual reboot?

[toffel969]

In my configuration Domoticz@Raspberry3 as controller reads the ESP8266s-with-ESPEasy.
Till approx. 2 weeks ago without problems related to continuity.
But now every day (rather randomly) at the side of Domoticz the read-out stops.
When directly calling the ESP8266s at their IP-addresses, I get response, telling me that the problem apperently is not at the side of the ESPs.
Practical remedy is simple, but rude:
when visually detected that read-out has stopped, via Putty I command to Domoticz@Raspberry a reboot.

Other people with comparable experience?
What could be the cause?
Better remedy available than manual reboot?

Did you maybe by mistake assign the same IDX to multiple tasks on the ESPs? Does a restart of the domotics session also fix the problem (other than reboot) ?

Regards

[Ton_vN]

IDXes are nowhere doubled.
Restart of Domoticz (such as after an Upgrade) is not a 100% sure remedy for a 'stuck' read-out.
Reboot 'on purpose' sometimes helpts, but not 100% either .......

[Ton_vN]

Looking slightly longer, the reason may be simple [but solution may be different story].

For the ESP8266s the Wifi RSSI has some variation over the day, but for the 'weak' ESP8266s the Wifi RSSI is reported to be < -85dB.
That may be too low for reliable Wifi-contact with the router in an environment which is crowded with Wifi-communication.
The ESP8266-controller (= Raspberry3) sits (for optimal positon of the RFLinkGateway relative to the 433MHz-network) also remote from the router, and for the ESP8266s it communicates over WiFi (through the router).
The Wifi-repeater should fill the 'holes' between ESP8266s, Raspberry-controller and router, but apparently that is a weak element in the WiFi-network.
That reboot of the Raspberry usually re-establises communication between the Raspberry and the ESP8266s may be a sign that the Wifi-route between Raspberry and router is the 'weak link'.
Possible remedies[?]:
1) Reposition the Wifi-Repeater and/or the ESPs and Raspberry (least effort, but try-and-error & compromisses)

• Result 170730: shifting the repeater => improved some ESPs + Raspberry, but lost other ESPs => present positions seem best-available (compromis)

2) Switch the Repeater's function to 'extra WAP' (connecting to the router by cable, allowing much longer distance to the router than by Wifi, and not decreasing the throughput due to the repeater-function)

• Result 170730: whether Repeater or WAP, the position of the device determines the coverage.
  Adding an extra Wifi-device as WAP at remote position improves/extends/shifts the coverage, but still try&error/compromis.

3) Connect the Raspberry-controller to the router by cable (to completely avoid the mutual WiFi-interface)

• Conclusion 170730: Equivalent is the addition of a Raspberry (Zero) directly cable-connected to the router for handling of the ESPs and linked to present Raspberry-controller as Slave. Minor cabling change which eliminates the wifi-route between router and ESP-controller. "Work in progress"

4) Fit the present Raspberry-controller with a real Wifi-antenna (most complicated solution, with only advantage that in the setup/configuration nothing else is changed)

• Conclusion 170730: 'if nothing else helps', but probably 3) already is most effective.

[Ton_vN]

I see a coincidence that when the read-out of the ESPs stops also at almost the same time in Domoticz the operation of certain lua-scripts stops.
More reason to look at the Domoticz @ Raspberry3 and not at the ESPs, and to look as in idea 3) whether fitting an extra Raspberry specific for ESP-readout is a remedy.

[Ton_vN]

After latest update of Domoticz to v3.8734 2 of the connected ESPs cannot be tricked to start again by reboot of the Raspberry-with-Domoticz.
The ESPs are not to blame, because in direct read-out I see them happily generating values.

Just a bright flash: check the IP-address on which that Raspberry communicates over WiFi with the ESPs!
And indeed, due to the update and related reboot, apparently the Raspberry had changed it's WiFi IP-address.
Re-aligned, and now they happily talk to each other.

Question now concentrates on a Raspberry-aspect: how to keep it operation on a fixed IP-address for WiFi.
[The cabled IP-address is not a problem].

[papperone]

After latest update of Domoticz to v3.8734 2 of the connected ESPs cannot be tricked to start again by reboot of the Raspberry-with-Domoticz.
The ESPs are not to blame, because in direct read-out I see them happily generating values.

Just a bright flash: check the IP-address on which that Raspberry communicates over WiFi with the ESPs!
And indeed, due to the update and related reboot, apparently the Raspberry had changed it's WiFi IP-address.
Re-aligned, and now they happily talk to each other.

Question now concentrates on a Raspberry-aspect: how to keep it operation on a fixed IP-address for WiFi.
[The cabled IP-address is not a problem].

Use your router rules to reserve a specific(fixed) IP to the MAC addr of the Raspberry WiFi

[Ton_vN]

Certainly helps to reduce the 'problems' by making a preset link in the router between MAC and IP:
thanks for the tip!

[Ton_vN]

Further improvement by fitting an extra WiFi-AP:
cable running from the main router to the AP covers the physical gap between the main router and the remote WiFi-AP
=> better spatial coverage and less effect to capacity than with WiFi-repeater at that distance 'listening-over-air' to the main router.