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.
As described by @davidgraeff openHAB is supporting Home Assistant MQTT convention, so C005 should have Home Assistant in name.
Arguments:
openHAB is following HA convention
this will help new users (like me) to setup ESPEasy with Home Assisnant
- There were some unicode characters
- JPG file had wrong image type
- Documented the needed packages to build LaTeX documentation in Linux (still fails to build PDF dus to chapter count overflow)
Grovkillen
TD-er
Florin
Toni
Misiu
Christian Meinert