Potential another WiFi issue ?

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
mackowiakp
Normal user
Posts: 527
Joined: 07 Jun 2018, 06:47
Location: Gdynia/Poland

Potential another WiFi issue ?

#1 Post by mackowiakp » 07 Aug 2019, 12:20

Configuration of nodeMCU:

- 7 seg 4 digit display
- internal analog input
- 2 relays
- 2 additional GPIO`s outputs
- DS18b20 temp sensor
- Domoticz as host controller

If Domoticz is off, nodeMCU reboots itself. The reason of the Domoticz is off was making ISO copy backup of SD card in RPi. The info about reason is:

Code: Select all

Reset Reason:	Software/System restart
Last Task:	Const Interval timer, id: 3
SW WD count:	0  
Timer 3 is responsible for reconnect nodeMCU to Wi-Fi AP each 50 min.
Is it issue or not?

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

Re: Potential another WiFi issue ?

#2 Post by TD-er » 08 Aug 2019, 17:38

That id: 3 is rather cryptic, but it is for sure not one of the timers in the rules.

Code: Select all

#define TIMER_20MSEC                        1
#define TIMER_100MSEC                       2
#define TIMER_1SEC                          3
#define TIMER_30SEC                         4
#define TIMER_MQTT                          5
#define TIMER_STATISTICS                    6
#define TIMER_GRATUITOUS_ARP                7
....
See here for the complete list of interval timers used in the Scheduler: https://github.com/letscontrolit/ESPEas ... #L246-L270

I didn't want to create strings of them yet, since it is merely a test to see if I can use this to decode what's going on at a reboot.
And the strings for it may increase the binary quite a bit, so for now it is a bit more work to look for the meaning of it.

But more importantly.
Did you set the "Connection Failure Threshold:" in the advanced tab?
If a host is offline, it may trigger a reboot based on the number of failed connection attempts.

mackowiakp
Normal user
Posts: 527
Joined: 07 Jun 2018, 06:47
Location: Gdynia/Poland

Re: Potential another WiFi issue ?

#3 Post by mackowiakp » 09 Aug 2019, 07:47

Connection Failure Threshold is set to 0. Restart WiFi Lost Conn - empty check-box.

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

Re: Potential another WiFi issue ?

#4 Post by TD-er » 09 Aug 2019, 22:15

What (client) timeout do you have in the Domoticz controller?
If it is on a local network, you should set it to around 100 msec, or 200 - 300 if the host you're connecting to is really slow or very busy.

mackowiakp
Normal user
Posts: 527
Joined: 07 Jun 2018, 06:47
Location: Gdynia/Poland

Re: Potential another WiFi issue ?

#5 Post by mackowiakp » 10 Aug 2019, 18:31

Client timeout is set to 100 ms. Domoticz is installed on 4 core 1 GB RPi, with graphic chip turn off (X are not started), So it not busy. But reboot of nodeMCU occurs when RPi is off for longer time for example - making ISO image backup copy of SD Card.

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

Re: Potential another WiFi issue ?

#6 Post by TD-er » 10 Aug 2019, 23:28

Does the ESP do other things with the R'pi?
For example is the Pi also serving as a DHCP server to the ESP?

mackowiakp
Normal user
Posts: 527
Joined: 07 Jun 2018, 06:47
Location: Gdynia/Poland

Re: Potential another WiFi issue ?

#7 Post by mackowiakp » 11 Aug 2019, 04:37

Yes. RPi acts as DHCP/DNS server (via lightweight dnsmasq) and NTP server for whole home LAN (including nodeMCU`s). But whole Ethernet nodes with "fixed location" (like desktop PC`s, TV sets, refrigerator, vacuum cleaner, washing machine, satellite receivers etc) in my home LAN have static IP configuration (nodeMCU`s too). Domoticz server is resolved by nodeMCU`s by IP address not by name. "Top" command on RPi shows 1 to 4% of occupation for each core (X server is not running). Domoticz on this RPi is installed on attached USB SSD HDD. To increase performance of whole system and increase lifespan of SD card and SSD, whole system and Domoticz temporary files (including "killer files" like temporary SQLite DB files of Domoticz) are moved to /dev/shm that is to RAM. InfluxDB and Grafana are installed on 4 core/8GB RAM QNAP NAS (64 bit Intel ver), not on RPi. So RPi has very few work to do and most I/O operations is done in RAM. (/dev/shm).

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

Re: Potential another WiFi issue ?

#8 Post by TD-er » 11 Aug 2019, 20:43

mackowiakp wrote: 11 Aug 2019, 04:37 Yes. RPi acts as DHCP/DNS server (via lightweight dnsmasq) and NTP server for whole home LAN (including nodeMCU`s). But whole Ethernet nodes with "fixed location" (like desktop PC`s, TV sets, refrigerator, vacuum cleaner, washing machine, satellite receivers etc) in my home LAN have static IP configuration (nodeMCU`s too). [...]
My question was just to narrow down the possible causes for the reboot of the ESP nodes, not as an definite "see, that's the cause".

Is ESP easy configured to use a specific NTP server, or does it only have the "use NTP" checkbox enabled?
If so, it does try to contact the regular NTP servers in pool.ntp.org. Sadly I've not yet been able to collect the NTP-server config from a DHCP reply, which means you have to explicit set an internal NTP server if you want to use that one.

mackowiakp
Normal user
Posts: 527
Joined: 07 Jun 2018, 06:47
Location: Gdynia/Poland

Re: Potential another WiFi issue ?

#9 Post by mackowiakp » 12 Aug 2019, 07:45

NTP server located on RPi is resolved by nodeMCU by IP address not by name. In my case it is 192.168.0.25, entered to nodeMCU NTP configuration. It works correctly with time dependent rules defined in EasyESP. All other nodeMCU IP related configs are resolved by numbers too (including static WiFi IP config and Domoticz controller). This RPi located NTP server is configured as "stratnum 0" and RPi is equipped in hardware RTC. Four times per day, RTC and RPi system clock is corrected according to Internet time from server ntp.icm.edu.pl (the fastest in my Country). The purpose of such solution was idea that home automatics should work even without Internet connection working and/or power failure. The house in my meaning should not be controlled by any overseas located server/cloud.

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

Re: Potential another WiFi issue ?

#10 Post by TD-er » 12 Aug 2019, 10:27

mackowiakp wrote: 12 Aug 2019, 07:45 The purpose of such solution was idea that home automatics should work even without Internet connection working and/or power failure. The house in my meaning should not be controlled by any overseas located server/cloud.
That's also the main idea of ESPeasy.
Too bad there are still bugs somewhere that prevent achieving that goal.

I will look at the NTP related code to see if I maybe somehow missed adding a timeout to the UDPClient.
I do know that for other network related code I have added timeouts to the client objects.

One "flaw" in the design could be that it only checks for WiFi connectivity before engaging a network connection, but in this case the network is available but a host is not.
I once had added a ping-check but that resulted in other problems so that has been reverted.
Maybe I can do some background ARP requests too, to hosts contacted frequently (on ESPeasy it's a relatively short list in practice).
If no reply was given, a connection to that host should not be tried.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 26 guests