- Argument number was incorrect
- did not set time source. (so you had to set NTP which defeats the purpose of this command
- Added documentation
- Moved the command call to the correct first letter of the alphabet.
Trying to make the parseSystemVariables function smaller
Moved time related functions to their respective .h/.cpp classes.
This will make the code a bit more clean and also reduces the build size.
Sometimes a unit may crash and is not able to connect to WiFi.
But time based rules or the cron daemon may not work when there is no concept of time.
This stores the last known system time in RTC memory to keep track of time.
It can also be used for some diagnostics while it is also sent to log what the last known time was before the crash/reboot.
Each normal reboot does cause a "shift" in time of roughly -1 second. Abnormal (warm) reboots may add more as those may have been the result of watchdog reboots.
Since there are not that much PRs open and in progress, this is maybe the least intrusive moment to cleanup some code using the given uncrustify.cfg
If there is a PR merge issue, checkout the PR and perform an uncrustify first before trying to merge.
Eco mode will call delay() from scheduler during idle loops. (significant energy reduction of up-to 0.25 Watt)
WiFi_NONE_SLEEP will keep wifi on continously (max energy consumption)
Gratuitous ARP will be sent to keep the MAC tables in switches know about the MAC of the ESP node.
The interval for sending ARP messages is dynamic. The interval between these ARP's is increasing up-to 60 seconds interval, so we're not flooding the network.
But on some occasions this interval time is reset to 100 msec (and doubled each next interval step), so we're announcing ourselves a bit more often.
Known issue:
- WiFi always on does seem to miss some packets (unstable RF due to heat?)
- UDP packets sent for ESPeasy p2p do seem to be missed more often as soon as the power consumption of the node is actually reducing.
- Eco mode may take some time to actually reduce power consumption of the node. It is like the underlying core library is dynamically increasing/decreasing the power consumption of the node. (core 2.6.0, SDK2.2.1)
This will reduce the loop counter and even cause some inverse effect. Higher loop count means the node has more work to do (less scheduled tasks which are not yet due for work)
Initial tests show a significant lower power consumption and thus hopefully a more stable wifi connection.
The average used delay during idle calls can be seen in the timing stats (likely around 2.5 msec per idle loop)
The CPU load (in %) is still the same as before this patch, but the node feels a bit more 'snappy' and the extremes in the timing stats are lower.
This commit is to cherry-pick all fixes in the reverted commits to make future GPIO related fixes be as easy as possible.
These also contain small fixes which were in the reverted commits, but not really related to the issues for which this revert is meant.
Implemented a GPIO timer for the scheduler to schedule a GPIO state change.
These will be stopped async:
- Tone > 50 msec duration
- Longpulse and longpulse_ms
Also implemented a frequency parameter for the `pwm` command.
`delay(0)` is a special case of delay, which also calls the system scheduler, `yield()` does not call.
It may interrupt a bit more than `yield()`
See #1950
And fix longpulse command
With other plugins active, like the OLED Framed, the set period of `longpulse_ms` may fluctuate and durations below 100 msec are quite useless.
However, when running just a few sensors, the set pulse width is quite accurate.
Must still check a few other plugins.
There is a problem with the PlatformIO builder since the last update of @mvdbro
It's an issue with the parsing of `#ifdef ESP32`.
It is very well explained here: [platformio/platformio-core#801 (comment)](https://github.com/platformio/platformio-core/issues/801#issuecomment-252447178)
In short, the event handling functions for the wifi have been moved to a separate .h file, since those files will be parsed properly by the Library Dependency Finder (LDF) in PlatformIO 3.x
Doing WiFi initialization in multiple steps, will reduce boot time a lot.
For deepsleep the Setup is waiting for wifi initialization to complete, but for normal use the wifi connection is initiated during setup and checked on regular intervals to see if it is available.
The same for WiFi reconnect, which will hopefully not affect the performance of the ESP module during reconnects.
Also added a check + event when connected to another accesspoint with different BSSID (MAC address of accesspoint). Also the last used BSSID is used to reconnect to try to connect to the same device over and over, which may be useful with WiFi repeaters.
See #727
And it only took 4 bytes extra storage :)
When initialized with an invalid setting for DST, (like fresh after flashing), it will use the CEST/CET setting.
* [Time] Moved time related code to separate file
* [AutoDST] Added Auto DST
Preliminary support for Auto DST, as requested in #569
Also did a little refactorin of time related code, with #698 in mind.
All time related code is split into a few files based on its function.
The currently selected DST will start on Last Sunday March 2am and end on Last Sunday October 3am.
This is the most frequently used DST, according to https://en.wikipedia.org/wiki/Daylight_saving_time_by_country
To change it, currently the code has to be changed in the function applyTimeZone(). Several examples are given right below that function.
Problem is where to store the information of the timezone, how to use it in the web interface and how convenient it is to set by hand.
The UTC offset in minutes still has to be entered and whether or not DST should be enabled.
Gijs Noorlander
Plebs
Saverio Cisternino