Max. duration of longpulse/PCFLongpulse

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Max. duration of longpulse/PCFLongpulse

#1 Post by TheTrumpeter » 17 Jun 2021, 08:26

What is the maximum duration of the longpulse/PCFLongpulse command?

As per commandref it's 999 seconds, but I have it currently running properly with 3600 seconds. (Did it before checking the commandref 8-) )

Now I'd like to switch on and off a filter pump which would need a runtime of 6h or 7h (up to 25200 seconds).

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

Re: Max. duration of longpulse/PCFLongpulse

#2 Post by TD-er » 17 Jun 2021, 08:39

I think this 999 is a left-over from old limitations.

However I don't think it is wise to use such a long timer for a "pulse" controlling a pump.
Maybe it is better to have it slightly more failsafe by setting a timer to turn it off.
What if the ESP reboots inbetween? The GPIO will return to logic 0, so I assume the pump is off then.
Is that bad?

If the start/stop time is fixed, I would use the rules to start/stop at a specific time.

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#3 Post by TheTrumpeter » 17 Jun 2021, 10:52

Currently I have no logic on the ESP but do it completely with FHEM.

For the intended use of my ESP (watering) it is important that a relay is switched off properly. It does not matter a lot if it's switched off too early, but it should not be kept on much longer than planned.
These relays are connected via PCF8574, so they should remain "on" even if there is a reboot.
  • Unfortunately they would never be switched-off then as the remaining runtime from "longpulse"-command is lost when a reboot happens during that?
  • As far as I could see during a quick test, the "timer" is also lost during reboot, so it would not improve the behavior.
So I do not see any difference in using "longpulse" or setting a timer?

For the filter pump it's not that difficult as it has fixed start/stop-times which could simply be controlled via rules. This relay is directly steered via gpio, so would be switched-off during reboot.


Unfortunately I still face stability issues with WLAN-connection of the node that I could not solve yet. Therefore I need a mechanism that works properly or at least does not cause big troubles.
What I could simply do is set all relays for watering to 0 during init, so at least the watering does not run infinite.
And I could set the filter pump to 1 during init, so it would just run a little longer than desired but would not be an issue either.


Any better ideas?

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

Re: Max. duration of longpulse/PCFLongpulse

#4 Post by TD-er » 17 Jun 2021, 11:06

Can you try a newer build (and the testing/experimental web flasher :) ) https://td-er.nl/ESPEasy/
The WiFi stability should be improved.

If you are worried about not turning off, you could add a command acting to the boot event to disable the pump at boot.

You can store the intended state (or switch off time in seconds of the day) in a dummy task.
Those will be recovered at boot from RTC.
But that does make the rules rather complex.

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#5 Post by TheTrumpeter » 17 Jun 2021, 11:30

Tried to update to latest official release some days ago but could not get WiFi connected then any more with the ESP32. ESP8266 had no issues after the update.
Eventually I got to run it on a ESP32 test-node 2 days ago, so I'll give it another try.

Any improvements in the latest build from your link there? (Don't want to bring the node to a computer or vice versa, so I'd only try it if there are further changes inside.)

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

Re: Max. duration of longpulse/PCFLongpulse

#6 Post by TD-er » 17 Jun 2021, 11:52

The link is not showing the download links of the bin files.
If you want to OTA flash them, you can browse them here: https://td-er.nl/ESPEasy/static/

I did fix some things regarding WiFi, but it is hard to tell if it is related to what you were seeing, or if it may be a fix for the ESP32 as I don't know when you built it.
Maybe better test it on a node you can (and want) to connect to the PC :)

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#7 Post by TheTrumpeter » 17 Jun 2021, 16:16

I've updated to the official build from 03.05.2021 during lunch break.

Unfortunately there still seem to be an issue with runtime increases that seem to be because of problems with the network connection:
Every now and then I see that runtime increases (with new build from 20 to 70%, with build from 12.2020 it goes from 15 to 60-90%).
Currently the device only reports its load/rssi/runtime to FHEM once a minute, the 2nd configured device is a switch that only reports on change (interval 0), which happens 6 times a day. No more devices are configured, no rules processed.
The FHEM-controller is configured to 150ms, queue-depth 5 and retries 5, timeout 50ms, no acknowledgement. Further I let the entries "expire" and "de-duplicate". As no other nodes face problems with FHEM-connection I do not think the root-cause of the problem is the FHEM-server.

I also had a look into the WLAN-AP. What is strange to me is that for this one node
  • the rssi that is shown in the AP is much lower than the one shown on the node (-89dBm vs. -60dBm)
  • the node is only connected with 1 Mbit/s
For all the other nodes the rssi shown in the AP and on the node are rather the same & data-rate is at least 10MBit for uplink and 50Mbit for downlink even for nodes with very weak rssi.

I will again change the antenna in the evening to check if that has an impact. (I already did that once, but did not have a look at rssi or data-rate in the AP then.)
(I've already changed the nodes itself, started with a new one, blanked it, and so on...)


For ESP32 it is not possible to deactivate 802.11 "n"-suffix as the setting is deactivated? Maybe that could improve stability also. (All the ESP8266 I run with deactivated "n".)

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

Re: Max. duration of longpulse/PCFLongpulse

#8 Post by TD-er » 17 Jun 2021, 16:29

The code for ESP32 does not allow to switch to "b/g" only, as at the moment I implemented it, it did not work on ESP32.
I may have to re-test to see if it now will work.

Not sure why you switched to the "03.05.2021" build, as the build I linked to was from 2 days ago with a lot of fixes regarding WiFi.

Another issue I see with your controller settings.
A timeout of 50 msec is not really practical I guess.
Even on a local network, a reply to a WiFi packet may on average take half of the WiFi beacon interval, which is almost always 102.4 msec.
So unless both devices (ESP and host running FHEM) are either connected via ethernet instead of WiFi, or have a very active communication via WiFi, the timeout of 50 msec is way too short to be practical.

Which reminds me, I should make the timeout of the controller dynamic as it often leads to a wrong setting, especially if the host to connect to is somewhere online.
The default timeout of 100 msec is already a bit on the edge, and maybe 150 or 200 should be a better default.

I don't know what you mean by "runtime" in percentage.
Is it the system load?

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

Re: Max. duration of longpulse/PCFLongpulse

#9 Post by Ath » 17 Jun 2021, 16:35

TheTrumpeter wrote: 17 Jun 2021, 16:16 I've updated to the official build from 03.05.2021 during lunch break.
Please re-do your tests with a matching .bin downloaded from here: https://td-er.nl/ESPEasy/static/
That's a much more recent build with many WiFi related fixes, that 03-05 release seems to have a somewhat troublesome WiFi performance on many boards.
/Ton (PayPal.me)

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#10 Post by TheTrumpeter » 17 Jun 2021, 16:58

Sorry, "runtime" means "load", for the devices I treat in my job we use the term "runtime" instead of "load".

I took the build from 03.05.2021 as it is the last official release, I'll try the other one today in the evening.

Regarding timeout setting of the controller I've read that the system is blocked during that time, so I tried to lower it as I thought the load-issue is from the controller.

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

Re: Max. duration of longpulse/PCFLongpulse

#11 Post by TD-er » 17 Jun 2021, 17:22

TheTrumpeter wrote: 17 Jun 2021, 16:58 Sorry, "runtime" means "load", for the devices I treat in my job we use the term "runtime" instead of "load".

I took the build from 03.05.2021 as it is the last official release, I'll try the other one today in the evening.

Regarding timeout setting of the controller I've read that the system is blocked during that time, so I tried to lower it as I thought the load-issue is from the controller.
Could very well be, but then more like retrying to deliver the packet due to timeout ;)

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#12 Post by TheTrumpeter » 17 Jun 2021, 19:52

Did the update at 5pm, lost connection right after 6pm and could not reconnect yet.

If I connect directly to the node and do wifiscan, it shows my network with -61dBm, but does not reconnect. Tried DHCP and static IP, no change. Periodic scan is enabled, it shows up to 12 different wifis, none on the same channel as mine.

When I'm directly connected, load is at approx 80%, when connected to the wifi it's approx. 20%.

Changed FHEM-controller-timeout to 120ms now, of course that does not influence the current behavior.

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

Re: Max. duration of longpulse/PCFLongpulse

#13 Post by TD-er » 17 Jun 2021, 19:59

Is this on an ESP8266 or ESP32?

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#14 Post by TheTrumpeter » 17 Jun 2021, 20:10

ESP32

marstu
Normal user
Posts: 37
Joined: 29 May 2021, 02:15

Re: Max. duration of longpulse/PCFLongpulse

#15 Post by marstu » 17 Jun 2021, 20:32

TD-er wrote: 17 Jun 2021, 11:52 The link is not showing the download links of the bin files.
If you want to OTA flash them, you can browse them here: https://td-er.nl/ESPEasy/static/
Hi TD-er,

I am happy to test one of these builds as well, because one of my ESP 8266 is also having issues with connecting to WLAN. Did you include only fixes on WIFI or as well these new variables %m_sunset% %m_sunrise%?

KR marstu
--
ESP8266, ESPEasy (always latest mega release in use :D ), and Domoticz (only beta versions :) )

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

Re: Max. duration of longpulse/PCFLongpulse

#16 Post by TD-er » 17 Jun 2021, 21:02

https://github.com/letscontrolit/ESPEasy/pull/3661 was merged 17 days ago, so yes it is in the build I linked.

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

Re: Max. duration of longpulse/PCFLongpulse

#17 Post by TD-er » 17 Jun 2021, 21:03

TheTrumpeter wrote: 17 Jun 2021, 20:10ESP32
OK, will have to test with ESP32 a bit more, as I mainly tested with ESP8266

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#18 Post by TheTrumpeter » 17 Jun 2021, 21:49

Did an experiment with my wifi today. I use a mesh with same SSID for router and extender.
Yesterday I noticed that some of the nodes are connected to the device with weaker rssi which I could not change with /setup-page.
So I changed the SSID for the extender earlier this evening to be able to manually connect to the stronger signal.
In both ESP8266 I entered the stronger SSID into the config and the weaker one into fallback-SSID, then I did the change on the extender.

First ESP8266 I then checked was still connected to the weaker signal with old SSID although it was only fallback. wificonnect did not change anything, so I removed the fallback-SSID from the config. Since then the node is not accessible any more, not per direct connection via AP-mode nor does it connect to the wifi. Powercycle did not change anything.
Second ESP8266 was also connected to the weaker signal with new SSID, but instead of removing the fallback-config I just rebooted it. Since then it uses the stronger signal and seems to work properly.
(Both nodes run on last official release from May this year.)

The problematic ESP32 still has no connection to the wifi. I can directly connect to its AP as written earlier, but reconnect does not work. I don't want to reboot/powercycle it right now, as I don't want to stop the filter pump at the moment. I guess it will connect automatically later tonight as it did last night and some days ago.

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

Re: Max. duration of longpulse/PCFLongpulse

#19 Post by TD-er » 17 Jun 2021, 21:59

If the node didn't connect to the stronger AP when they were configured with the same SSID, and also did not want to connect to it when only the SSID of the stronger AP was configured, then I guess there is some issue between that AP and the ESP as you have now encountered.

Of course setting the 'weaker' AP to the SSID of the AP you cannot connect to will probably make the ESP available again.

So maybe you should check for specific settings like "B/G only" and maybe the AP is configured for "N only".

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#20 Post by TheTrumpeter » 17 Jun 2021, 22:13

TD-er wrote: 17 Jun 2021, 21:59 Of course setting the 'weaker' AP to the SSID of the AP you cannot connect to will probably make the ESP available again.
I guess this will work; I'll try tomorrow if it does not reappear during the night.
But why does the node not switch to AP-mode as it does not get connected to the wifi?
TD-er wrote: 17 Jun 2021, 21:59 So maybe you should check for specific settings like "B/G only" and maybe the AP is configured for "N only".
Both devices allow b+g+n and ac, the ESP8266 is configured for b+g only.

Maybe I'll also try to deactivate n for my whole wifi to see if this has an positive effect on the problematic ESP32.

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

Re: Max. duration of longpulse/PCFLongpulse

#21 Post by TD-er » 17 Jun 2021, 22:39

ESP32 does not obey (can it even be set??) the "B/G only" setting right now.
So ESP32 will always use '802.11n' (with the current code)

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#22 Post by TheTrumpeter » 18 Jun 2021, 07:03

As expected, the ESP32 reappeared last night and behaves normal at the moment.

The ESP8266 is still not there, so I'll have to try changing the SSID-names to get it connected.

Regarding b/g/n:
I understand that the EPS32 currently does not support to deactivate "n", but if I deactivate "n" in my wifi-router, maybe it has a positive effect?

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

Re: Max. duration of longpulse/PCFLongpulse

#23 Post by TD-er » 18 Jun 2021, 08:51

Well if "positive" means "ESP32 cannot connect", then you might be right :)
No just kidding... I do expect the ESP32 to also allow to connect to 802.11g as it is not set to "n-only".
Please let me know if that assumption is correct.

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#24 Post by TheTrumpeter » 18 Jun 2021, 09:59

After deactivating "n" in the router, the ESP32 on my desk still connected and had no issues.
The problematic one also connected as per status-page of my router, but was only there for few seconds.

After again activating "n" in the router, there is no change, the problematic ESP32 gets not connected.
I had a deeper look into the info-page then and saw that the TX-power varies, once I've seen just 2dBm, sometimes 15 and sometimes 17. After setting to "always max. TX power" it seems to be at 17. Independet from that it always shows my wifi with -61dBm, but does not connect.

I've now taken the ESP32 from my desk near to the "problematic one", after some minutes it got connected, rssi of the node and my router are similar (-68 vs -71dbM), downlink is at 128Mbit/s and uplink at 42MBit/s.
Just to remind: the one from my desk was initially outside, I replaced it some days ago as it made troubles there. :twisted:

I will now exchange the antennas of the both nodes...


PS: The ESP8266 which lost connection during rename of the SSID of the wifi-extender still did not connect, even not after renaming the SSID in the router. Further it does not start AP-mode, so looks like I have to reflash it via cable. (It runs on 20210503.)

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

Re: Max. duration of longpulse/PCFLongpulse

#25 Post by TD-er » 18 Jun 2021, 10:16

Power cycle may also help, as that clears cached information.

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#26 Post by TheTrumpeter » 18 Jun 2021, 11:31

TD-er wrote: 18 Jun 2021, 10:16 Power cycle may also help, as that clears cached information.
I did that several times, also after changing the SSID again. Nothing brought it back or started AP-mode.

After changing the antennas on the ESP32 I see a strange behavior:
As written before, the node from my desk showed similar rssi (approx. -68 dBm) also outside near the problematic node on the node itself and the router with the "small antenna" (3 dbi). Now with the "big antenna" (8 dbi) I see 20 dBm less on the router (-56 dBm on the node, -76 dBm as per router). Still it gets high down- and uplink rates. (Of course the reason could also be that after changing the antenna it's not exactly the same position as before as I had to place the big antenna slightly different.)
The problematic node got connected with the small antenna, router still says -88 dBm whereas the node shows -62 dBm. It says current tx power is 15 although max is set to 17 and send-with-max-flag is true. As per ESP32-datasheet max is 20,5 dBm for b and 18 dBm for n (page 27). Downlink slightly improved to 2 Mbps.

I deactivated "n" again on the router:
Node from the desk now has approx -70 dBm as per router and -60 dBm as per node, downlink 54 Mbps (max), uplink 35Mbps.
Problematic node still has -88 dBm vs. -63 dBm, downlink varies between 2 to 10 Mbps, uplink goes up to 3 Mbps. But it looks like this varies a lot, I also see only 1 Mbps.


So to sum it up it seems that
  • the wifi-signal the router sends is received from the nodes rather good (-66 dBm up to -56 dBm)
  • the router receives rather weak signals sent by the nodes. Especially the antenna position from the "problematic" node seems to be bad wrt targeting the router.
  • deactivating "n" suffix has no impact, at least not if it's only deactivated on the router
  • "send-with-max-power" does not work properly on ESP32
      • different SSID for extended wifi does not have an impact

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

Re: Max. duration of longpulse/PCFLongpulse

#27 Post by TD-er » 18 Jun 2021, 12:11

You appear to have an ESP which allows for an external antenna.
I don't know all ESP32 modules from experience, so I wonder if there are modules out there that both have a PCB antenna and an UFL connector.
For example the "Wemod D1 mini pro" (16M versions) have this.
With this board there is a 0 Ohm resistor between the ESP and the PCB antenna.
In order to actually use the UFL connector, you need to rotate this 0 Ohm resistor 90 degree to connect the UFL connector.

Can this be something that's happening on your boards too?

The max. TX power I allow to set is based on what I added in the code.
So it could very well be that I messed up there.
See: https://github.com/letscontrolit/ESPEas ... #L690-L709


Another thing you should realize about "antenna gain".
It is very well possible that a 3 dBi antenna performs better than an 8 dBi.
To understand this, you must know what is meant by this antenna gain.
The most elementary (and impossible) antenna is one that radiates the same in every direction.
Thus the energy is evenly distributed on a sphere (3D) where the energy per cm^2 attenuates the further you get from the antenna.
Just like the rubber of a baloon is stretched and thus there is less rubber per cm^2 if further inflated, so is the amount of energy per cm^ getting less the larger this sphere becomes (the further away from the antenna)

So how do we "increase" the energy per surface on this sphere?
You can increase the amount of power you put into sending (the TX power, measured in dBm)
Or you can decrease the surface you radiate to.
That's exactly what a "high gain antenna" does.
It puts a small band over the sphere and tries to send all the energy to only this band.
So if the receiver is not in this 'band' area, then the reception is ideally 0. In practice the 'edge' of this band is not so strict, so it will still receive something, but a lot more attenuated.

Another way to increase "gain" of an antenna is not to radiate in a planar field, but aim directly at the receiver.
A good example of this are those "Pringles Can-tennas" that were popular roughly 10 years ago, where you placed an USB WiFi module in an empty Pringles cylinder and could reach several km distance.

So to get back to the paradox observation you made of using a high gain antenna and getting worse results.
For high-gain antennas it does matter even more to aim the antenna to the AP.
Or actually the antenna should be the normal of a plane that crosses both the ESP and the AP.

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#28 Post by TheTrumpeter » 18 Jun 2021, 13:05

If I look at line 607ff of the file you've just shared it seems that the max. power you set is 19,5 dBm?

I had another try with switching off "n" and had a look into the one ESP32 that's currently responding: It still shows an "n" connection on "info"-page, max-power-flag is set, configured max-power is 20,5 but current used power is 15. Even after a reboot this remains the same. It does not change if I activate "n" again.

When I look at line 630 in the code 15 dBm is only used when the configuration is below 16 dBm, but mine is set to 20,5 dBm so line 642 should be the one setting to 19,5 dBm.
I'm not sure what line 690ff later does, I would assume it limits power to 14 in case of an "n"-connection, but as I see 15 on an "n"-connection my understanding might be wrong.


Regarding my ESP32: Yes, I have an external antenna, but it does not need to rotate the resistor (I know that from my Wemos D1-pro-clones). It simply uses the ESP32-WROOM-32U which has the UFL-connector directly on it; in my case the board is the DevKitC without PCB antenna.

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

Re: Max. duration of longpulse/PCFLongpulse

#29 Post by TD-er » 18 Jun 2021, 13:42

See here for the available enums for TX power on ESP32:
https://github.com/espressif/arduino-es ... #L111-L124
There is no enum value for more power.
Based on the values, I could try to send "80" to it, but no idea what that may do.
It is clear you can't use every value, so maybe the integer value represents some different stages in the WiFi circuit of the ESP32. I don't know.

You have to realize the dBm value is already clipped before based on the WiFi mode. This is done in the function GetRSSIthreshold: https://github.com/letscontrolit/ESPEas ... #L690-L709

This does clip it to "14" and the code for ESP32 does use a < (not a <=) so it is correct the TX power is then set to 15.
Whether it is a good limit for ESP32 is another question.
So you could try to set the max. TX power to slightly less than 14 to see if that stabilizes things as I don't know what the ESP32 code does if you set it to an invalid value for the current WiFi mode.
What if "15" is invalid. Does it do nothing? Does it enter some undefined state?

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#30 Post by TheTrumpeter » 21 Jun 2021, 12:47

TD-er wrote: 17 Jun 2021, 11:06 You can store the intended state (or switch off time in seconds of the day) in a dummy task.
Those will be recovered at boot from RTC.
But that does make the rules rather complex.
Is there a different behavior in case it's a reset triggered by user?
I just created a dummy device and put a value via TaskValueSet into it.
After clicking "reboot" via web-interface the value is gone (set to 0).

Strange thing is, that the info-page says it's a "cold boot" (20210503), I feel I've seen other values there when triggering a manual reboot with older/other releases?

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

Re: Max. duration of longpulse/PCFLongpulse

#31 Post by TD-er » 21 Jun 2021, 13:49

Do you test this on ESP8266 or ESP32?
I've seen that most ESP32 boards perform a reset by toggling the ESP_EN pin.
This pin does also clear RTC memory, therefore I call it a cold boot in the last boot description.
RTC support for ESP32 has been added very recently and I am still struggling to interpret the boot reasons on ESP32 as they are not always consistent to what is happening.

A reboot via the web interface should not clear the RTC, not even on ESP32. (at least not on the boards I tested here)

TheTrumpeter
Normal user
Posts: 29
Joined: 02 Dec 2020, 15:30

Re: Max. duration of longpulse/PCFLongpulse

#32 Post by TheTrumpeter » 21 Jun 2021, 15:16

TD-er wrote: 21 Jun 2021, 13:49 Do you test this on ESP8266 or ESP32?
ESP32
TD-er wrote: 21 Jun 2021, 13:49 A reboot via the web interface should not clear the RTC, not even on ESP32. (at least not on the boards I tested here)
It does, at least at the board I've tested. It's a DevKitC-clone from AliExpress, no peripherals connected, powered via USB.
SW-version is 20210503.

I've also tried triggering the reboot via FHEM, same there. (Did not expect a difference as it will most likely call the same function than the web-interface.)

When I press the "EN"-button, it also says "cold boot", but the reset reason is different:
for EN: button: CPU0: RTC Watch dog reset digital core and rtc module CPU1: for APP CPU, reseted by PRO CPU
Reboot via web-interface: CPU0: Software reset CPU CPU1: Software reset CPU


EDIT: Did the same on an ESP8266, there it behaves as you say:
Dummy-value remains stored after reset, Reset-reason is "Manual reboot" and reset reason is "Software/System restart"

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

Re: Max. duration of longpulse/PCFLongpulse

#33 Post by TD-er » 21 Jun 2021, 15:48

I guess the ESP32 does need some extra attention then regarding RTC.
Like I said it was only added recently for ESP32 and it really is hard to tell based on the reboot flags set in RTC why it rebooted.
I do check if the stored data is valid, so it will not load random data into the taskvalues.

Post Reply

Who is online

Users browsing this forum: No registered users and 28 guests