- 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.
The plugin was assuming the values stored in UserVar were correct.
After a cold boot, or when the NTP time (or via GPS) was not yet set, these values for last time or next time could be just about any value.
This means it was possible the Cron task would never fire an event if the next time was computed far in the future.
Also restructured the code a bit, to make it more readable.
Also removed ProtocolIndex from the event struct as it is redundant information which can easily be forgotten to set.
Sorted the described commands in the documentation and added a few missing commands.
It appears the events called from rules must be run immediately, but there are some use cases where it can be useful to have async events.
So changed back the behavior for events called from rules, to be executed immediately.
Added the new command AsyncEvent.
Until now a lot of ways to handle a command were handling the pre-processing of the command differently.
So the source of the command can make a difference whether system variables can be used for example.
Now all use the same function to pre-process the commands.
Store the last used BSSID and channel in the RTC and use it for initial WiFi connect attempt.
This does speed up the WiFI connection to about 1.8 sec after boot.
Old situation was connected at about 3.9 sec after boot.
When booting from cold boot, the strongest known RSSI is chosen first.
MQTT controller queue handling is now more aggressive in trying to get rid of buffered packets.
It also now accepts the MQTT messages before it is connected to WiFi (or when not yet reconnected)
See #2650
The counter wifi_connect_attempt is being used to determine whether the fallback SSID should be tried.
It is also used to determine whether a "quick reconnect" is possible using the BSSID and channel of the last successful connection.
If the connection is unstable, (last connection was active for over 5 minutes) then the connect attempt counter can be reset.
Also add some caches to find task-value names.
Fix some minor issue when referring [var#n] variables. These were always rounded to 2 decimals.
Also added [int#n] to address the same variables as with [var#n] but rounded to integer values, to be used in rules for more reliable comparing.
The parsetemplate function was almost always shown as function with the lowest free memory when called.
The function did make a lot of memory re-allocations and was very hard to read.
This commit is about reducing the memory allocations and speed up the parsing.
Will also fix [this issue reported on the forum](https://www.letscontrolit.com/forum/viewtopic.php?p=39219#p39219)
The WiFi setup page does set a flag to indicate the connect attempt was initiated from the setup.
But the flag was only reset when the setup page reloaded..
If that did not happen, the node could retry forever to (re)connect to the AP if the channel was changed or the node cannot see the old BSSID anymore (e.g. out of reach when using repeater)
Also the first attempt after changing WiFi settings would also (initially) fail due to retrying with old BSSID/channel combination.
Move WiFi/Network related functions into separate files to keep them organized and easier to locate.
Also added lots of comments and some documentation on the state machine handling WiFi connect and reconnects.
For LoRa, it may take a while to send out samples of different plugins.
This makes it hard to match samples belonging to the same set after receiving them.
The Sample Set Initiator is a task index which should always be considered as the first of a set samples sent to the controller.
For example when triggering to send a set of samples from rules, its order can be always the same.
Setting the initiator to the first one of the sequence, the same sample set counter will be sent along with the samples.