For I2C UART an I2C clock of 400 kHz is needed to be able to handle continuous streams of data.
But the default was still 100 kHz, unless you selected a plugin that may have set the I2C frequency to 400 kHz like the Framed OLED plugin.
- 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.
This does include almost all needed for a plugin.
So it will make intellisense highlighting useful as otherwise almost each line in a plugin file will be marked red.
ESP32's WebServer class has the same name as our global object had.
So you could only define it in ESPEasy.ino.
Now it is renamed to `web_server` and now ESP32 and ESP8266 will happily build with the global object defined in .h/.cpp.
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.
The TXBuffer is a "header only" implementation.
This means it may be compiled "inline" and thus takes quite a bit of compiled code.
This makes the binary larger and slows the ESP down.
Now it is even possible to make core 2.6.3 builds using "minimal OTA".
The "Dev" build is roughly 55k smaller.
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.
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.
The sensor cannot output useful values after the IAQ init.
So we now keep track of the last known baseline values and restore them after the sensor is initialized.
For example after a reboot or a crash.
Also the values of TVOC = 0 and eCO2 = 400 will be ignored as new values right after sensor init.
The sensor was performing IAQ init for every read, while it should only be done at init of the sensor.
The IAQ measurement should be performed every second.
See also #2886
This does make sure the initial network connection can transfer data.
On some nodes it took a lot of attempts to get a connection established right after boot.
The functions used to call CPlugins are now part of an enum.
This also means the compiler can help to detect when some functions are not dealt with in a switch statement.
As suggested by @uzi18 should the plugin function defines be an enum instead of defines.
This will allow to do compile time checks and also check whether all cases are handled.
The calls to the existing library were blocking, so they could take a long time to send a message (over 2 seconds)
Now the library is using a state machine and the handling can be dealt with by calling the ...loop functions frequently.
The extra padding to a minimal line length does only make sense for use on displays and some special formatting.
So the majority of the uses of parseTemplate now uses 0 as minimum line length.
Fixes: #2866
Closes: #2867 (superseeds PR)
This was rather messy code and no checks.
It is now somewhat similar to the code for plugins defining the relation between:
- Plugin ID
- Task Index
- Device Index.
* substring
* strtol (useful for converting hex or binary numbers)
* 100ths division
in eventvalue parsing.
Using this modification I am able to handle the messages sent from Opentherm Gateway ( http://otgw.tclcode.com/ ) and to set variables of a dummy device in rules.
Example:
* Message coming from the serial interface: T101813C0
** The B denotes that the message is from the boiler.
** The next 4 bytes (actually 2bytes hex encoded) denote the status and type of the message.
** the last 4 bytes (actually 2bytes hex encoded) denote the payload.
* Message that ends up in rules when using ser2net (P020) and Generic handling: !Serial#BT101813C0
The room temperature in this sample is 19.75°C
Rule used to parse this and set a variable in a dummy device:
// Room temperature
on !Serial#T1018* do
TaskValueSet 2,1,[strtol:16:[substring:13:15:%eventvalue%]].[div100ths:[strtol:16:[substring:15:17:%eventvalue%]]:256]
endon
Now the variable can be used in the rules/controller/log/whatever.
See this issue where the changes in behavior for wificlient.connected() is discussed: https://github.com/esp8266/Arduino/issues/6701
A change dating back to April 2018 ( https://github.com/esp8266/Arduino/pull/4626 ) does have some implications on how to interpret the client.connected() result.
It is very well possible there is still data in the buffers waiting to be read.
So the loop() function of pubsubclient should first try to empty the received data and then decide what to do with the connected state.
So reading is fine, if there is data available, but writing needs an extra check.
Some JSON was invalid, for example when the closing entry of a list was optional (WiFi scanner)
The generated JSON for the I2C scanner was a bit useless, so made it more useful by only outputting addresses which have some device and included the list of supported devices.
I added a very basic JavaScript line to the rules page, where it appends the length of the rules.
Only problem is that the length in JavaScript is with a newline counted as \n and it outputs to the node with a newline as \r\n, so there is an offset of 1 byte per line.
But still gives me a good indication whether data is lost, which happens quite a lot when you cross the 1600 bytes
Known issue:
If you try to save and it fails, then the stored rules will be shown (not the one you just tried to submit)
The web arguments may get corrupted sometimes.
This can be due to another request mangling the already parsed arguments, or lack of memory to split the sent arguments into parsed ones.
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.
A lot of people were running into issues with some commands no longer working after the changes of strict rules parsing.
This flag in the advanced settings may help out a bit.
Also the logs are made a bit more elaborate to describe the issue.
We already had a EventBuffer, which was mainly used by received events from a controller.
This was only 1 element long, so events could be missed.
This is now changed into a queue, which will be processed in the 10/sec call.
Events will now be stored in the queue, unless there is a need for them to be executed immediately (for example if the source is waiting for a reply)
Events generated in the rules by the event command will also be executed immediately.
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.
The WiFi.disconnect() ensures that the WiFi is working correctly. If this is not done before receiving WiFi connections,
those WiFi connections will take a long time to make or sometimes will not work at all.
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)
These builds (especially the custom ones) take quite some time to build and Travis was constantly exceeding max. build time.
Also the 16M builds (14 MB SPIFFS) are hardly useful, since they are way too slow to be practical.
New ASAIR brand DHT11 can support decimal and negative values.
Change conversion coding As same as DHT12.
Old type DHT11 also OK.
DHT11 datasheet. 2017-03-31 V1.3
4. 5.2 temperature parameter list to update the tabular form, measuring
range is 0 to 50 to - 20 to 60 .
CHG: Using a calculation to reduce line content for scrolling pages instead of a while loop
CHG: Using SetBit and GetBit functions to change the content of PCONFIG_LONG(0)
CHG: Memory usage reduced (only P036_DisplayLinesV1 is now used)
CHG: using uint8_t and uint16_t instead of byte and word
CHG: Each line can now have 64 characters (version is saved as Bit23-20 in Settings.TaskDevicePluginConfigLong[event->TaskIndex][0]))
FIX: Overlapping while page scrolling (size of line content for scrolling pages is now limited to 128 pixel)
Create a file named "pio_envlist.txt" next to the Custom.h for Vagrant with the selected env names in it, one per line.
Vagrant will then build all named PIO environments.
The timer to disable AP mode should be set as soon as the AP is started, to make sure it will be disabled.
It only will be increased when a client connects to the AP mode.
When disabling the AP mode, it needs a check to see if the AP mode was actually disabled before clearing the AP off timer.
1. Display commands:
oledframedcmd display [on, off, low, med, high]
turns display on or off or changes contrast (low, med or high)
2. Content commands:
oledframedcmd <line> <text> <mode>
displays <text> in line (1-12), next frame is showing the changed line, mode not implemented yet
CHG: Header content only changed once within display interval. before every second
CHG: more predefined constants to understand the meaning of the values
Set a compile time option to send the String representation of the IR signal back to the conrroller.
Defaults to the old behaviour so it does not brake anything.
CHG: Page scrolling based on Timer (PLUGIN_TIMER_IN) to reduce time for PLUGIN_READ from 700ms to less than 80ms (not as smooth as before but non-blocking!)
[P036] Added pagination to customized header
[P036] Time can be always selected in customized header, even if the time is diplayed by default for 128x68
Fixes: #2704
This is quite a serious bug in comparing values.
The compare was using the wrong values on a compare line when multiple compares had to be made. (with multiple and/or)
[P036] NEW more OLED sizes (128x32, 64x48) added to the original 128x64 size
[P036] NEW Display button can be inverted
[P036] NEW Content of header is adjustable, also the alternating function
[P036] CHG Parameters sorted
event->BaseVarIndex is set only at a few places in the code, so adding checks there is enough to make sure all uses of event->BaseVarIndex are safe.
Especially when computing a userVarIndex from event values (user input) the range should be checked before using it to access an element in the UserVar array.
After finding a number of calls to toString() with only a single parameter, the value would be converted into a bool and then printed.
This will yield in unexpected results without a compiler warning.
Fixed a bug 1 year old (in my own code) in P009 and P019 that was returing a state of 255 instead of -1 in case of state=offline.
The reason of the bug was that the Read function was forced to a byte variable instead of a int8_t variable.
This could generate a loop (and eventually a crash) if the monitor command was set to a pin that was offline. Infact the state returned was 255 and the current state was -1, so they never matched and a new event was created every 1/10 seconds.
This was actually a bug, since only the toString(bool) was forward declared.
Meaning the conversion of a float to a string was not performed as expected when called from a .cpp file instead of a .ino file.
When enabling the FEATURE_SD, something with the define of __FlashStringHelper is not correct anymore.
This needs a lot of changes which were needed anyway.
But also arrays of __FlashStringHelper must be changed.
All done so far, only need to have a look at
static const __FlashStringHelper *gpMenu[8][3] = {
Command format is IRSEND,{"protocol":"<protocol>","data":"<data>","bits":<bits>,"repeats":<repeat>}
It is backwards compatible with the old one (IRSEND,<protocol>,<data>,<bits>,<repeat>)
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.
See #2650.
As long as a client is connected to the node in AP mode, no automatic reconnect should be attempted since it will make it very hard to get connected or remain connected to the AP mode.
The WiFi channel will change during scan which will disconnect the user.
The ESP could sometimes experience a crash when saving the rules.
This was caused mainly on fragmented file systems and a bit longer rules files.
Now the same saveToFile function is used as being used in all other settings file access.
Also the rules were copied in memory, which is useless since they are already present in memory (LWIP code) and passed by const reference.
The changed rules parsing may have added some spaces in replaced variables.
Adding a trim() call to the parseString does remove any existing or added spaces in the parameter.
When using settings containing configuration for a certain plugin which is not included in the actual build, then the plugin must be displayed as "not supported" and not possible to edit.
Also show some indication about the consequences of trying to edit such a task. It will then present a dialog equal to adding a new device to a task.
See #2676
The use of DeviceIndex was not consistent, which may lead to strange issues.
DeviceIndex is the translation between the vector of included plugins and IDs of plugins available.
Rules parsing starts with 2 steps:
- Reading line from rules file
- If read line is no comment line, see if it does match the event block we're looking for.
This second part is done in the ruleMatch function.
This function was doing a bit more than strictly needed.
This optimization is mostly about trying to exit as soon as possible and using less memory allocations in Strings.
Fixes: #2642
Problem was in the conversion to int, which may add a leading space.
The parsing of int and float string values should be able to handle leading spaces, so fixed that.
When starting the ADC plugin at boot, the WiFI connection attempt is already started.
This may offset the average value quite a bit.
This fix will exclude those samples from the values used to compute the average while oversampling.
The check in the code was for #ifndef BUILD_NO_DEBUG.
But even when it is defined as 0, it is still defined.
So the code was still included in the binary.
Specify only a subset of PIO envs to build, to make sure it will build within the 50 minutes time limit, even when the caches are cleared by PlatformIO.
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 clean step may no longer be needed, which makes it more useful to have the last built directories restored from the cache and hopefully reduce build times.
Does not yet act on the new errors, but at least it should be possible in the plugins to detect whether any data was received to see if a device is present.
See also https://github.com/letscontrolit/ESPEasy/issues/2616
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)
Added support for MITSUBISHI KJ series heatpumps / remote control type SG161.
Also added a IR_DEBUG_PACKET define to be able to feedback and debug the IR packet as added text output to a browser, curl or other http request tool.
The conversion was staring after the reading of the temperature
also there was effectively no delay after the conversion for the sensor to do its thing. This 2 factors combined made the ESP report the previus measurment and not the current
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.
Do not declare static functions in a header file, since everywhere the function signature is called, it will call a copy of the function and thus the function in the header file where it is defined, is never called.
The MemAnalyzer tool was not able to perform a proper analysis of the current builds, since we introduced the `USES_P001` syntax of defines to determine what should be included and what not.
As stated in LWIP documentation:
https://www.nongnu.org/lwip/2_1_x/multithreading.html
"When running in a multithreaded environment, raw API functions MUST only
be called from the core thread since raw API functions are not protected
from concurrent access (aside from pbuf- and memory management
functions). Application threads using the sequential- or socket API
communicate with this main thread through message passing."
https://www.nongnu.org/lwip/2_1_x/netifapi_8h.html
Is not present in current esp-idf / arduino-esp32 builds.
Using existing "private" TCPIP API, create a minimal struct to pass a message
to the LWIP thread instead of calling etharp_gratuitous directly.
Trying to reduce size of the compiled binaries by excluding certain parts of the code if not needed.
See definitions at the end of 'define_plugin_sets.h'
Currently done:
- Casting all controllers that are not included
- Casting all MQTT related code
- Casting all Domoticz related code
The last page of the wizard now shows the network info, just like in the sysinfo page and has a button at the bottom which links to the IP address of the node on the normal network
This last page of the setup also has the menu bar at the top and also the default template now shows a warning when you're connected via AP mode.
This allows for easier setup, since you don't have to switch networks anymore
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.
Simplified the WiFi connect state machine.
Fixed setup of initial WiFi configuration.
AP mode is now kept as long as client is connected.
AP mode will be started immediately if there are no valid WiFi credentials, or after 20 seconds of no wifi connection.
AP mode will be disabled 60 seconds after starting it, or after the last client disconnected from the AP.
This makes it easier to adapt settings, since platform and build_flags both depend on the same variable section.
Thus it makes sense to have them on consecutive lines.
Makes the rest of the decoder.js a lot simpler.
Also changed the GPS lat/long into 3 bytes again, saving 2 bytes in the packet length.
GPS outputs now 7 values using 18 bytes (incl. header)
This does allow uploading even more parameters than the 4 supported by ESPeasy, since encoder and decoder can be tailored to the specific plugin.
For example the GPS plugin can now upload 7 parameters in only 20 bytes.
Still to do: Why can the decoder not handle encoding per 24 bit? (lat/lon do fit perfectly fine in 24 bit).
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.
Normally a controller uses a hostname or IP to connect to.
But a LoRa node does not connect to any specific host, but does broadcast messages using its own unique dev addr.
This will be shown as host description in the Controller overview page.
Move loading and saving of controller settings to separate functions per item.
Also string generation is now done in a function to keep internal strings in sync.
The flag to signal a successful boot was only set when there was a successful WiFi connection.
But this can lead to step by step disabling of plugins when the accesspoint is unreachable for a long time.
Some plugins and controllers were writing to TXBuffer.buf directly.
This should not happen, since then the memory usage of that buffer will increase and never decrease again.
Also C011 Generic HTTP advanced was not using existing functions for displaying config page.
The node delivering the data for a plugin is now shown on the device page in the "Port" column.
Also added a fix to only allow updates from 1 node to a remote node.
Previously it was possible to have several nodes writing to the same remote p2p shared plugin.
This could lead to very strange results.
This also means that a remote installed plugin must now be deleted and re-installed to allow receiving data from a remote host if the remote host unit id has changed.
For example a stream at 38400 bps can fill up the serial buffer over 27x a second.
This means that receiving data strings over 128 bytes (buffer size) may already be corrupted when reading at 10x a sec.
Just an initial skeleton to build the new Serial Proxy plugin.
It will fetch data and move it to a controller.
This will be the first plugin to handle something other than float values.
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
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.
The Dallas 1wire sensor can get into some error state.
To signal an error state, a NaN was ouput, but that may be hard to use in rules.
This selector allows to set a fixed value to signal an error state.
Also removed a lot of redundant code and make sure no data is shared among other active instances of the same plugin.
Auto gain will switch on/off the gain to extend the range of the sensor.
The 16x gain will be turned on below 10 Lux.
It will be off at 1/16th of the full range of the ADC.
On top of that there is also an option to extend the range of the sensor to about 130'000 lux.
The ratio ch1/ch0 will be stored as long as no ADC is clipping. This ratio will be applied to the measured ch1 (IR part) of the measured data when the ch0 value is clipping.
For example meauring direct sunlight may give upto 130'000 Lux of light intensity, but the sensor itself can only handle upto about 30'000 Lux without clipping.
Saturation level of the CH0 and CH1 ADCs is not at 65535 for all integration time settings.
For an integration time less than 178 msec, the max ADC value is less. This fix does detect those saturation levels.
The Uncrustify package in VS code does look in the project dir for a config file.
When it is present, there is hardly any configuration needed. Therefore I moved it and updated it a bit to behave more uniform than the cfg file we already had.
Just for testing/debugging purposes, the last executed task from the scheduled is logged into RTC memory.
This decoded string is also logged at boot and shown in the system info page.
It still demands quite some expertise to interpret but maybe we can find some pattern to where the crashes occur most often.
-Extended command example:
IRSENDAC,"protocol":"GREE","power":"off","mode":"heat","temp":21,"fanspeed":"max","swingv":"middle","swingh":"off"}
-Refactored and simplified code based on new libary updates
-1M IR build does not support Extended AC commands
-Usage instructions added
-Also added back the ability to have arbitrary bits to the IR send command. Reflected that also in the received signal decoding. Using 0 bits as an argument the ir send command will still use the default protocol bits
ref: https://www.letscontrolit.com/forum/viewtopic.php?f=4&t=6452&p=37373#p37373
Core 2.5.2 does contain a lot of fixes.
If this core version does seem to appear stable in the next few weeks, we will use it as the standard core for nightly builds.
Since Release mega-20190215, the plugin “ P065_DRF0299_MP3.ino “ wasn’t functioning on GPIO16.
With this small change, it’s operational once again and also available to connect other serial (non-critical) devices on GPIO16.
It is now possible to select different values for output.
A new output will be given when either the Interval time has passed, or a set minimal traveled distance is exceeded.
This can then be used in rules to trigger other samples.
There was still a hard-coded delay left in the process modbus command function.
Now it returns as soon as a valid reply is received.
This will make the PLUGIN_READ call of SenseAir S8 take 45.1 msec instead of 59.1 msec on average.
The calibration is now presented more clear.
Added an option to clear the logged data in the AccuEnergy sensor
Fixed an inconsistency in reported Watt and Wh.
Added display of imported/exported/net/total energy.
For example the SysInfo plugin should be made more flexible in the number of outputs.
Also the SenseAir plugin now supports multiple outputs to be able to get CO2 and sensor temperature for example. (temp reading is not yet correct)
Debouncing was no real debouncer before, this is fixed now.
Instead of setting a delay after a change occured during this the counter is "blind" the counter now waits for the next edge in the pulse signal and calculates then the time that the last state was active.
Only if the debounce threshold is exceeded the counter will be increased.
The SPIFFS may become fragmented, so it is possible a file cannot be appended to even though there is room on the file system.
So there has to be a proper check to see if writing fails and also delete oldest file(s) when needed + call to the garbage collector.
See also https://github.com/esp8266/Arduino/issues/5987
- hook for CPLUGIN_GOT_CONNECTED placed correctly
- hook for CPLUGIN_GOT_INVALID placed + added log
- fixed return values
- some log fixes
- cleaned up code
issues
I Think MQTTclient_should_reconnect=true does not reconnect if there is a working connection. In case of CPLUGIN_GOT_INVALID success a MQTTDisconnect(); function added.
The last read values were only saved when the device enters sleep mode, not when new values are read.
So after a reboot (as a result of a crash) the values were at their initial values.
P016_TIMEOUT is set now to 50 instead of 90 as a compromise between stability of decoding and accomodating large IR signals.
Also added breaks to mitigate unstability with long operations that might starve the ESP from backround tasks
Reverted and made compatible and optional the old style of the irsend command that supported also repeats
Both commands
IRSEND,NEC,ASDF123
and
IRSEND,NEC,ASDF123,0,0
will produce the same result.
to repeat the signal 1 time the command is
IRSEND,NEC,ASDF123,0,1
Create a much bigger CSV using 12*4 value columns with all labels on top.
6000 samples takes about 35 - 80 seconds depending on the number of 0.0 values (more zeroes, less time, smaller size)
The size of the CSV ranges between 900 and 2600 kByte for 6000 samples.
Export speed is 70 - 160 samples per second.
Calling `/dumpcache' will generate a CSV file of all logged data.
This may block the ESP for a while, since it outputs about 250 samples per second.
So 480'000 bytes of flash storage takes roughly 70 seconds to dump to a 1.6 MByte CSV. (20'000 samples)
Some settings have char arrays. Make sure these are 0-terminated when stored or loaded.
For example the ExtraTaskSettings were used without these checks
Use a state to process reading temp and hum or keep error.
The state is handled in the 10/sec call and when a new measurement is ready it will schedule itself to read the new values.
See #2407
There may be some unexpected responses after the reset.
So do not reset the sensor unless > 10 unknown responses were seen and also do not reset within 3 minutes after sensor reset.
Apparently the last update broke handling of unexpected response to commands.
According to the datasheet, the sensor should not give a response to some commands, but it does.
These responses should not lead to a reset of the sensor.
This will allow to reduce code duplication, reduce strings used in binary and makes code better readable.
This is a project which may take some time to cover all code.
Saves 20K of flash memmory. They provide no functionality other than giving log stirngs of that short:
"Mesg Desc.: Power: On, Fan: 5 (AUTO), Mode: 3 (HEAT), Temp: 22C, Zone Follow: Off, Sensor Temp: Ignored"
When using 'Oversampling' the Analog input plugin is simply summing all samples and upon calling the read function it will divide this sum by the number of samples.
This added filtering is keeping track of the lowest and highest value measured in this loop and excludes these extremes.
This makes the reading a lot more stable, since it is often only a single extreme value which causes noise in the reported values.
Also added a note to the setup page near the calibration points to make it easier to add calibration values. It shows the current raw value + its calibrated equivalent (if enabled).
Saves 20K of flash memmory. They provide no functionality other than giving log stirngs of that short:
"Mesg Desc.: Power: On, Fan: 5 (AUTO), Mode: 3 (HEAT), Temp: 22C, Zone Follow: Off, Sensor Temp: Ignored"
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.
In the backgroundtasks and also for a number of other network related operations there was no check for connectivity.
This could lead to various timeouts and maybe hanging processes. (Hardware watchdog resets)
Also:
- included core 2.6.0 alpha build with SDK2.2.1
- included core 2.6.0 alpha build with SDK3.0.0-dev
- Made memory size in bin filenames consistent (_4M instead of _4096)
- 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)
load index.htm if it exists
If for some reason this is not working well (error in the index.htm) you can go to /filesystem
or /devices
or any other page, and it will load the old ui
Then go to /filesystem and delete index.htm
Core 2.5.0 is out, but this gives instability issues serving web pages.
For now the builds of core 2.5.0 are not included in the nightly builds until this is fixed.
The RX/TX pins are defined in the init. So no need to hand them to the begin function call again and set some default when not used.
This will lead to issues where the TX pin is not working when using HW serial.
Reading the sensor data will now only accept data starting with 0xFF.
This should improve reading stability.
Also added indicator showing checksum pass/fail and the model detected (MH-Z19 A or B)
Fixed several compile errors which occurs in case of active FEATURE_SD.
errors:
(1) #if with no expression
(2) converting to 'const String' from initializer list would use explicit constructor 'String::String(char)'
(3) no matching function for call to 'serialPrintln(uint32_t, int)'
The internal buffer was a char* array, but all it needed was just the same as being already available in the `String` class.
So it has been changed to be a String.
Not using the Plugin_task_data, since it is using interrupts and callback functions.
Not sure what will happen if we store these volatile variables in the same global array.
Exclude debug logs from C001, C002, C005, C008, C009, C013 and P001, P026, P033 which are compiled in by default in the PLUGIN_BUILD_MINIMAL_OTA set.
Reduces sketch about 1k.
Add BUILD_NO_DEBUG in define_plugin_sets.h to PLUGIN_BUILD_MINIMAL_OTA.
This makes commit #316691ad07731798687ada096907c5ccb61fb1b6 included and active in 1M minimal OTA build.
Decouple PLUGN_BUILD_MINIMAL_OTA in define_plugin_sets.h from other #defines in source code, otherwise either plugin set from Custom.h gets overriden by PLUGN_BUILD_MINIMAL_OTA from define_plugin_sets.h or #define's in code (eg. WebServer.ino) are not included.
Also name is misleading, as eg. WebServer is not a plugin..
- Call delay(0) unconditionally after plugin calls as they can take quie some time, even if they fail
- add some more log output in various places for WiFi info
- add some ()/{} to make groupings clear
- add all possible statuses in case statement after WiFi.begin() call
- test for layer 2 availability independent of valid IP (can happen that IP is still valid, but layer 2 is lost)
See:
- https://github.com/esp8266/Arduino/issues/2111
- https://github.com/esp8266/Arduino/pull/5395/files
Hopefully it will help for modules which have a hard time to connect to WiFi, which may be caused by weak power supply.
It will also not start unintended DHCP-client services which lead to strange issues when using static IP configuration.
Tests should reveal if it will also help to lessen the chaos which may happen now the 'May deal' is off, so please perform some tests and we'll see the coming days.
At least it will save some peak power at startup.
The internal buffer was a char* array, but all it needed was just the same as being already available in the `String` class.
So it has been changed to be a String.
Not using the Plugin_task_data, since it is using interrupts and callback functions.
Not sure what will happen if we store these volatile variables in the same global array.
For ways to *support* us, see [this announcement on the forum](https://www.letscontrolit.com/forum/viewtopic.php?f=14&t=5787), or have a look at the [Patreon](https://www.patreon.com/GrovkillenTDer), [Ko-Fi](https://ko-fi.com/grovkillentder) or [PayPal](https://www.paypal.me/espeasy) links above.
@@ -12,7 +12,6 @@ Introduction and wiki: https://www.letscontrolit.com/wiki/index.php/ESPEasy#Intr
**MEGA**
:warning:This is the development branch of ESPEasy. All new untested features go into this branch. If you want to do a bugfix, do it on the stable branch, we will merge the fix to the development branch as well.:warning:
Next stable branch: https://github.com/letscontrolit/ESPEasy/tree/v2.0 (bug fixes only, since oct 2017))
Check here to learn how to use this branch and help us improving ESPEasy: http://www.letscontrolit.com/wiki/index.php/ESPEasy#Source_code_development
@@ -21,24 +20,28 @@ Check here to learn how to use this branch and help us improving ESPEasy: http:/
Every night our build-bot will build a new binary release: https://github.com/letscontrolit/ESPEasy/releases
The releases are named something like 'mega-20180102' (last number is the build date)
The releases are named something like 'mega-20190225' (last number is the build date)
Depending on your needs, we release different types of files:
@@ -22,8 +22,9 @@ Build type can be: (differ in included plugins)
There is also a number of special builds:
- normal_IR => "Normal" + IR receiver/transmitter plugins and library
- hard_xxxxx => Special builds for some off-the-shelf hardware.
- normal_core_241 => "Normal" using core 2.4.1, since 2.4.2 has issues with PWM
- minimal_ESP82xx_1024_OTA => Minimum number of plugins and a limited set of controllers included to be able to perform a 2-step OTA on 1 MB flash nodes.
- minimal_ESP82xx_1M_OTA => Minimum number of plugins and a limited set of controllers included to be able to perform a 2-step OTA on 1 MB flash nodes.
- normal_core_xxx => "Normal" using core xxx (e.g. 2.4.1)
- normal_beta => "Normal" using the staged (beta) branch of the esp8266/Arduino repository.
Chip can be:
- ESP8266 => Most likely option
@@ -31,13 +32,28 @@ Chip can be:
- ESP32 => Experimental support at this moment
MemorySize can be:
- 1024 => 1 MB flash modules (e.g. almost all Sonoff modules)
It is possible to share the data collected by a plugin on one node so it can be used on another node.
This data can be used as if it is actually being run on the second node.
For example, a Dallas DS18b20 sensor on Node-1 is shared using the ESPeasy p2p controller.
This plugin can then automatically be setup on Node-2 and using the data collected by Node-1.
This is a rather non-intuitive process to setup.
Prerequisites
^^^^^^^^^^^^^
* Same UDP port must be setup on both nodes. (preferrably UDP port 8266) This can be done in Tools -> Advanced -> UDP port
* Nodes must be rebooted after UDP port has changed.
* Each node must have an unique unit number. This must not be 0 and not 255, but anything inbetween is fine.
How to share a plugin
^^^^^^^^^^^^^^^^^^^^^
* Check to see if all nodes can see eachother. This will be visible on the main page showing a list of all nodes.
* Enable p2p networking controller on receiving node
* Make sure the receiving node has the spot free which is being used on the 'sending' node (For example slot 12)
* Enable p2p networking controller on sending node
* Set the plugin you want to share to use the p2p controller
Any node that is setup to receive data like this will see a plugin being added if the spot in the device list was still free.
Builds made after 2019/08/08 will show in the device overview page from which unit the shared plugin does get its data.
This also means the plugin must be removed and re-created if the sending node is changed. (e.g. another node or change of unit number)
In later builds there will be added an option to update this node number.
Some tips on trouble shooting
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* Make sure to reboot the node after changing the UDP port.
* Make sure all nodes have an unique unit number and share the same UDP port.
* If you have ArduinoOTA enabled, use another port for ESPeasy p2p UDP (port suggested in most OTA examples use port 8266)
* Ping the nodes from some other host to keep their WiFi awake.
* Disable "Eco mode" in the advanced settings.
* Sharing a plugin to be auto installed on another node is only sent right after the plugin is set to use the p2p controller. So if you don't see it appear on the other node, save it again on the source node.
* Make sure the same plugin is available in the build on both nodes. (e.g. both supporting Dallas DS18b20, if that's the one you want to share)
* When using the "Guest" feature of an access point, some will not allow direct communication between clients on the same AP. This will also prevent this p2p protocol to share data.
* If updating from builds before 2019/08/08, you may need to remove and add again a plugin receiving data from a remote node.
Sending & Known Nodes
---------------------
@@ -123,13 +175,7 @@ The entire message processed as a command like this:
This controller connects to a MQTT Server providing auto-discover information and a communication protocol according to the Homie convention 3.0.1 and the future development version 4.0.0.
For more information head over to `Homie convention <https://homieiot.github.io/>`_
Idea is to provide an easy way to include ESPEasy in modern home automation systems without any or with as less effort as possible. Imagine your device pops up in openHAB 2.4 or higher as a new device and you only have to pic the values you are interested in. You can immediately see measurements or switch GPIOs without a single line of code.
When a MQTT connection is established after (re-)boot the controller sends auto-discovery information for system services like commands, basic GPIO functions and for all configured devices and there values. When all messages where sent successfully a homie compatible home automation server/hub or other compatible controllers should be able to detect the unit and establish two way communication.
The :ref:`P086_page` plug-in can be used to set values and trigger actions / rules.
MQTT topic scheme
-----------------
A homie topic scheme always starts with the root topic homie followed by the **unit name** (homie uses the term **device**), **device name** (**node** in homie) and a **value name**.
``homie/%unitname%/%devicename%/%valname%``
updates or commands can be sent by appending ``/set`` to the topics for values which can receive data.
``homie/%unitname%/%devicename%/%valname%/set``
Prequesites
-----------
A MQTT server capable of storing messages sent with ``retain=true`` when ``QoS=0``. Due to limitation (intentional not implemented due to low memory footprint and performance considerations) of the MQTT library (pubsubclient) used in ESPEasy it is only possible to send messages with ``QoS=0`` which basically means `fire and forget`. The current MQTT specification says that the server SHOULD store these messages when they arrive via ``QoS=0``. Some servers like the MQTT server currently build into openHAB 2.4 (moquette) is configured to ignore the retain flag and drop the message after delivery to the currently subscribed clients when ``QoS=0``. Mosquito on the other hand store messages when retain flag is set even when they are sent with ``QOS=0``.
Check with a MQTT client like MQTTspy or MQTTfx if the auto-discover messages are stored (retained).
A home automation server/controller capable talking Homie like openHAB since 2.4. (Be aware there are issues in the Homie implementation 2.4 including 2.5M1 milestone release not working as expected after restart). Recent snapshot builds should work.
Setup
-------------
- add the Homie **Homie MQTT (Version 4.0.0 dev)** or **Homie MQTT (Version 3.0.1 dev)** controller to your controller lists depending on your build.
- insert your broker address
- and user credentials if necessary
- the publish scheme is fixed to meet the homie requirements to ``homie/%sysname%/%tskname%/%valname%``
- the subscription scheme can be modified. Current defaults to ``homie/%sysname%/+/+/set`` to reduce incoming traffic to a minimum. Homie only expects messages via the ``homie/%sysname%/%tskname%/%valname%/set`` topic.
- last will topic (LWT) should set to ``homie/%sysname%/$state``
- LWT Connect Message to ``ready``
- LWT Disconnect Message to ``lost``
- save and reboot, best with connected serial monitor or syslog server with debug set to 4 (debug) or greater (alternatively use a MQTT client and subscribe to ``homie/%sysname%/#`` - replace %sysname% by the unit-name shown on the top of the webpage).
..image:: C0014_Setup_0.png
-``homie/%sysname%/$nodes`` enumerating all devices will be sent as final message of the auto-discover header.
- The final event log should look like this:
..code-block::html
5584 : EVENT: MQTT#Connected
5754 : C014 : autodiscover information of 4 Devices and 6 Nodes sent with no errors! (26 messages)
Troubleshoot
------------
The auto-discover information is sent through a big number of messages (usual more than 20). If your controller software not recognize your device or shows errors during the auto-discover process try the following steps:
- For testing purposes start with a basic setup with none or only one device configured and enabled.
- More devices can be added or (re-)enabled later.
- Disable already configured devices (devices without the enabled box ticked will be ignored)
- Check with a MQTT client if all messages are sent. The last message sent is ``$nodes`` attribute listing minimum the ``SYSTEM`` node if no other devices are enabled.
- check your WIFI connection. Perhaps bring your device nearer to your access point. (only necessary during the setup process because the messages should be stored by the broker)
- check via syslog or serial console if the messages are sent successful (you normaly can't see the log output in the web log)
- use the `mqqt-forget <https://www.npmjs.com/package/mqtt-forget>`_ tool to delete unused retained messages from your broker via wildcards
Features
--------
The controller currently supports these features
- send auto-discover nodes for all sending and enabled plug-ins to ``homie/%unitName%/%deviceName%/%valueName%``
- receive commands through the ``homie/%unitName%/SYSTEM/cmd/set`` topic.
- switch GPIOs through ``homie/%unitName%/SYSTEM/gpio#/set`` topic. The GPIO port must be set to **default low** or **default high** in the hardware tab to be included during auto-discover.
- send updates of GPIO ports to ``homie/%unitName%/SYSTEM/gpio#`` regardless from where the change is triggered (to be fully tested).
- in conjunction with :ref:`P086_page` actuators can be used according to the Homie convetion using rules.
- receive values for dummy devices via ``homie/%unitName%/%dummyDeviceName%/%valueName%/set``. From there the values can be processed further by using rules.
- handle ``$state`` attribute (for complete list see attribute table below)
-``init`` during boot process
-``ready`` during normal operation and as a heartbeat every 30sec (to be tested)
-``alert`` currently only if auto-discover fails. But if sending the auto-discover messages fails it is more than likely that sending the alert message will fail to. (ToDo: inform about other error states like low ram or stack available, repeating reboots or failed sensors)
-``sleeping`` sent before deep sleep
-``lost`` configured as LWT
-``disconnected`` sent to the old topic if the unit name changes to inform that the old topic is not valid any more. Auto-discover messages are sent automagically to the new topics afterwards.
- acknowledge received message by the ``homie/%unitName%/%deviceName%/%valueName%/set`` topic to the corresponding value ``homie/%unitName%/%deviceName%/%valueName%`` even if the value was changed by a different source like HTTP or rule to keep the state in your home automation system allays up to date. (Needs further testing)
Future / planned features
-------------------------
- a special Homie Plugin is in devolopment to pass ``\set`` messages to rules for further handling. Here ``$datatype`` and ``$format`` attributes for ``$setable`` values can be specified there. This will enable ESPEasy to handle direct inputs to plug-ins like dimmers (%,0:100), colors (RGB & HSV, 255,255,255), enum devices like remote controls (Play, Pause, Vol+, Vol-, ...). :yellow:`Testing` see :ref:`P086_page`
- Further in field testing with different MQTT brokers and home automation systems.
- Handling units via the ``$unit`` attribute. As ESPEasy is currenty "unitless" this needs a global concept within ESPEasy
- Handling ``$datatype`` attribute. Currenly all values (except cmd and gpio) are defined as ``float``. :yellow:`Testing` see :ref:`P086_page`
- Prepare some "working examples".
Under the hood
--------------
Auto-dicover information is sent by several $attributes
currently the following attributes will be sent during boot
"``$name``", "Friendly name of the device", "EPSEasy#1", "YES", ":green:`required`", "YES", ":green:`required`"
"``$homie``", "The implemented Homie convention version", "4.0.0", "YES",":green:`required`", "YES", ":green:`required`"
"``$state``", "See chapter features", "ready", "YES",":green:`required`", "YES", ":green:`required`"
"``$localip``", "IP of the device on the local network", "192.168.2.10", "YES", ":green:`required`", "NO", ":red:`void`"
"``$mac``", "Mac address of the device network interface.", "A1:B2:C3:D4:E5:F6", "YES", ":green:`required`", "NO", ":red:`void`"
"``$fw/name``", "Name of the firmware running on the device.", "ESPEasy mega", "YES", ":green:`required`", "NO", ":red:`void`"
"``$fw/version``", "Version of the firmware running on the device.", "20103 - Mega", "YES", ":green:`required`", "NO", ":red:`void`"
"``$nodes``", "Nodes which the device exposes separated by commas. Sent at the end for performance reasons.", "SYSTEM,SysInfo", "YES",":green:`required`", "YES", ":green:`required`"
"``$implementation``", "An identifier for the Homie implementation.", "ESP8266", "YES", ":green:`required`", "NO", ":red:`void`"
"``$stats/interval``", "Interval in seconds at which the device refreshes.", "60", "YES", ":green:`required`", "NO", ":red:`void`"
"``$stats/uptime``", "Time elapsed in seconds since the boot of the device.", "12345", "YES", ":green:`required`", "NO", ":red:`void`"
"``$stats/signal``", "Signal strength in %.", "75", "YES", ":blue:`optional`", "NO", ":red:`void`"
"``$name``","Friendly name of the property.","Command", "YES",":green:`required`", "YES",":green:`required`"
"``$datatype``","Describes the format of data. integer/float/boolean/string/enum/color","float", "YES",":green:`required`", "YES",":green:`required`"
"``$settable``","Specifies whether the property is settable (true) or read-only (default false). True for cmd, GPIO and dummy device values.","true", "YES",":yellow:`required true` for settable values", "YES",":yellow:`required true` for settable values"
"``$retained``","Specifies whether the property is retained (true) or non-retained (false).","false", "NO",":green:`required`", "NO",":blue:`optional`"
"``$unit``","A string containing the unit of this property.","°C", "NO",":blue:`optional`", "NO",":blue:`optional`"
"``$format``","Describes what are valid values for this property.","-30:40", "NO",":blue:`optional`", "NO",":blue:`optional`"
`The Things Network (TTN) <https://www.thethingsnetwork.org/>`_ is a global open LoRaWAN network.
LoRaWAN allows low power communication over distances of several km.
A typical use case is a sensor "in the field" which only has to send a few sample values every few minutes.
Such a sensor node does broadcast its message and hopefully one or more gateways may hear the message and route it over the connected network to a server.
The data packets for this kind of cummunication have to be very short (max. 50 bytes) and a sender is only allowed to send for a limited amount of time.
On most frequencies used for the LoRa networks there is a limit of 1% of the time allowed to send.
Such a time limit does also apply for a gateway. This implies that most traffic will be "uplink" data from a node to a gateway.
The analogy here is that the gateway is often mounted as high as possible while the node is at ground level ("in the field")
There is "downlink" traffic possible, for example to notify some change of settings to a node, or simply to help the node to join the network.
In order to communicate with the gateways in the TTN network, you need a LoRa/LoRaWAN radio module.
The radio module does communicate via the LoRa protocol. On top of that you also need a layer for authentication, encryption and routing of data packets.
This layer is called LoRaWAN.
There are several modules available:
- RFM95 & SX127x. These are LoRa modules which needs to have the LoRaWAN stack implemented in software
- Microchip RN2384/RN2903. These are the modules supported in this controller. They have the full LoRaWAN stack present in the module.
Nodes, Gateways, Application
----------------------------
A typical flow of data on The Things Network (TTN) is to have multiple nodes collecting data for a specific use case.
Such a use case is called an "Application" on The Things Network.
For example, a farmer likes to keep track of the feeding machines for his cattle.
So let us call this application "farmer-john-cattle".
For this application, a number of nodes is needed to keep track of the feeding machines in the field.
These nodes are called "Devices" in TTH terms.
For example a device is needed to measure the amount of water in the water tank and one for the food supply.
Such a device must be defined on the TTN console page.
There are two means of authenticating a device to the network (this is called "Join" in TTN terms):
- OTAA - Over-The-Air Authentication
- ABP - activation by personalization
With OTAA, a device broadcasts a join request and one of the gateways in the neighborhood that received this request,
will return a reply with the appropriate application- and network- session keys to handle further communication.
This means the device can only continue if there is a gateway in range at the moment of joining.
It may happen that a gateway does receive the join request, but the device is unable to receive the reply.
When that's happening, the device will not be able to send data to the network since it cannot complete the join.
Another disadvantage of OTAA authenticating is the extra time needed to wait for the reply.
Especially on battery powered devices the extra energy needed may shorten the battery life significantly.
With OTAA, the device is given 3 keys to perform the join:
- Device EUI - An unique 64 bit key on the network.
- Application EUI - An unique 64 bit key generated for the application.
- App Key - A 128 bit key needed to exchange keys with the application.
The result of such an OTAA join is again a set of 3 keys:
- Device Address - An almost unique 32 bit address of your device.
- Network Session Key - 128 bit key to access the network.
- Application Session Key - 128 bit key to encrypt the data for your application.
The other method of authenticating a device is via ABP.
ABP is nothing other than storing the last 3 keys directly on the device itself and thus skipping the OTAA join request.
This means you don't need to receive data on the device and can start sending immediately, and even more important, let your device sleep immediately after sending.
A disadvantage is the deployment of the device. Every device does need to have an unique set of ABP keys generated and stored on the device.
Updating session keys may also be a bit hard to do, since it does need to ask for an update and must also be able to receive that update.
Hybrid OTAA/ABP
---------------
TODO TD-er.
Configure LoRaWAN node for TTN
------------------------------
A LoRaWAN device must join the network in order to be able to route the packets to the right user account.
Prerequisites:
- An user account on the TTN network.
- A TTN gateway in range to send data to (and receive data from)
- Microchip RN2384 or RN2903 LoRaWAN module connected to a node running ESPeasy. (UART connection)
On the TTN network:
- Create an application
- Add a device to the application, either using OTAA or ABP.
In order to create a new device using OTAA, one must either copy the hardware Device EUI key from the device to the TTN console page,
or generate one and enter it into the controller setup page in ESPeasy.
The Application EUI and App Key must be copied from the TTN console page to the ESPeasy controller configuration page.
Using these steps, a device address is generated.
Such an address looks like this: "26 01 20 47"
Also the Network Session Key and Application Session Key can be retrieved from this page and can even be used as if the device is using ABP to join the network.
But keep in mind, these 3 keys will be changed as soon as an OTAA join is performed.
Device configuration with solely an ABP setup are more persistent.
@@ -57,8 +61,12 @@ before WiFi connection is made or during lost connection.
-**Max Queue Depth** - Maximum length of the buffer queue to keep unsent messages.
-**Max Retries** - Maximum number of retries to send a message.
-**Full Queue Action** - How to handle when queue is full, ignore new or delete oldest message.
-**Client Timeout** - Timeout in msec for an network connection used by the controller.
-**Check Reply** - When set to false, a sent message is considered always successful.
-**Client Timeout** - Timeout in msec for an network connection used by the controller.
-**Sample Set Initiator** - Some controllers (e.g. C018 LoRa/TTN) can mark samples to belong to a set of samples. A new sample from set task index will increment this counter.
Especially useful for controllers which cannot send samples in a burst. This makes the receiving time stamp useless to detect what samples were taken around the same time.
The sample set counter value can help matching received samples to a single set.
Sample ThingSpeak configuration
@@ -71,6 +79,7 @@ ThingSpeak only allows a message every 15 seconds for the free accounts.
-**Max Queue Depth** - 1 (only report the last value)
The files and directories in the ESPEasy file repository are organized in folders.
Some of the choices for folder structure may not look very logical at first sight and may need some explanation to understand.
ESPEasy Project Directories
===========================
Below a list of the most important directories and files used in this project.
*``.pio/`` Working dir for PlatformIO (Ignored by Git)
*``dist/`` Files also includd in the nightly builds (e.g. blank flash files and ESPEasy flasher)
*``docs/`` Documentation tree using Sphinx to build the documents.
*``hooks/`` Used for the continous integration process, used by Travis CI.
*``include/`` PlatformIO's suggested folder for .h files (not yet used)
*``lib/`` Libraries used in this project. Some have patches which make them different from the maintainers version.
*``misc/`` Additional files needed for some use cases, like specialized a firmware for some boards or decoder files for the TTN project.
*``patches/`` Patches we apply during build for core libraries.
*``src/`` The source code of ESPeasy
*``static/`` Static files we use in ESPEasy, like CSS/JS/ICO files.
*``test/`` Test scripts to be used in the continous integration process.
*``tools/`` Tools to help build ESPeasy.
*``venv/`` Directory to store the used Python Virtual Environment. (Ignored by Git)
*``platformio.ini`` Configuration file for PlatformIO to define various build setups.
*``uncrustify.cfg`` Configuration file for Uncrustify, to format source code using some uniform formatting rules.
*``pre_custom_esp32.py`` Python helper script for building custom ESP32 binary
*``pre_extra_script.py`` Python helper script for building custom ESP8266 binary
*``requirements.txt`` List of used Python libraries and their version (result of ``pip freeze`` with Virtual env active)
*``esp32_partition_app1810k_spiffs316k.csv`` Used partition layout in ESP32 builds.
*``crc2.py`` Python script used during nightly build to include the environment name in the build and compute checksums.
ESPEasy src dir
===============
In order to compile the project using PlatformIO, you need to make sure the ``platformio.ini`` file is in the
root of the project dir opened in the editor.
The ``src/`` directory has the source files of the project.
In this directory, there is another ``src/`` dir, which is needed by ArduinoIDE in order to find files in sub-directories.
Arduino IDE also demands include directives to be relative compared to the file they are used in.
For example: ``#include "../DataStructs/Settings.h"``
We are currently working on converting the core ESPeasy code from .ino files into .h/.cpp files. (see PR #2617 and issue #2621)
The header and source files are organized in a few directories in ``src/src/``.
*``Commands`` Functions to process commands.
*``ControllerQueue`` Mainly macro definitions for the queue system used by controllers.
*``DataStructs`` Data structures used in ESPEasy. Note that some of them are stored in settings files, so take care when changing them.
*``Globals`` Declaration of global variables. Declare them using ``extern`` in .h files and construct them in .cpp files or else you may end up with several instances of the same object with the same name.
*``Static`` C++ encoded version of objects which have to be included in the binary. N.B. JS and CSS files are minified.
The Arduino based .ino files are still in the ``src/`` directory. (and some .h files, which are not yet moved)
In the end, there should be only .ino files left for the plugins and controllers and ``ESPEasy.ino``
All other .ino files used in the ESPEasy core should be converted to .h/.cpp.
This conversion is needed to have full control over ``#define`` statements used to determine what is included in a binary and what not.
This also allows for more flexible control over user defined builds.
Triggered when the ESP is connected to the AP on a different channel, will also trigger first time the unit connects to the Wi-Fi.
This has been added in build mega-20190910
","
.. code-block:: html
on WiFi#ChangedWiFichannel do
Publish,%sysname%/status,channel changed
endon
"
"
``WiFi#APmodeEnabled``
@@ -219,3 +232,27 @@
endon
"
"
``GPIO#N``
If the command 'Monitor' is used to monitor a given pin you will receive an event for that GPIO as soon as it's state changes. As seen in the example you can always use the square brackets together with the task/value name of ``Plugin#GPIO#Pinstate#N`` to get the state, but to trigger events you need to add the monitor command (preferably at boot).
The TSL2561 are light-to-digital converters that transform light intensity to a digital
signal output. First targeted to accompany LCD and OLED displays in order to dim them
if the ambient light is lower, making the battery life better for the unit its a part of.
The unit can also be found in illuminated keyboards and digital cameras.
The TSL2561 sensor is a luminosity sensor. It's spectral sensitivity approximately meets
the human eye sensitivity. The gain of the sensor can be set to a 16x gain mode with the settings.
It is connected to the ESP via I²C so connecting even with several sensors and a display is easy to do.
Specifications:
* Output: 0.1 - 40 000+ Lux
* Temperature (-30 to +70C but best readings between +5 to +50C)
* Humidity (0 - 60 % rel. humidity)
Wiring
------
..image:: P015_TSL2561_2.jpg
..code-block::html
ESP TSL2561
GPIO (5) <--> SCL
GPIO (4) <--> SDA
ADDR (not used = 0x39)
Power
3.3V <--> VCC
GND <--> GND
The ADDR pin can be used if you have an i2c address conflict, to change the address.
Connect it to GND to set the address to 0x29.
Connect it to VCC (3.3V) to set the address to 0x49.
Leave it floating (unconnected) to use address 0x39.
Some boards have soldering pads or jumper selectors for the ADDR.
..image:: P015_TSL2561_wiring_1.jpg
Setup
-----
..image:: P015_Setup_TSL2561_1.png
Task settings
~~~~~~~~~~~~~
***Device**: Name of plugin
***Name**: Name of the task (example name **Light**)
***Enable**: Should the task be enabled or not
Sensor
^^^^^^
***I2C Address**: Default 0x39 is used.
***Integration time**: 13 msec is the default, works in normal lit areas. Increase the integration time for low light areas, it will collect light longer if set to longer time.
***Send sensor to sleep**: Have it checked in order to save the unit from wear, especially good if you do measurements with long intervals in between.
***Enable 16x Gain**: Have it checked in order to get higher readings in low light areas.
Data acquisition
^^^^^^^^^^^^^^^^
***Send to controller** 1..3: Check which controller (if any) you want to publish to. All or no controller can be used.
***Interval**: How often should the task publish its value (5..15 seconds is normal).
OLED displays will age quite fast, so it is not adviced to run them continously at max brightness.
Some displays do not accept all brightness levels and some also make a quite high pitch coil whine noise when running on some brightness levels.
So different levels of brightness can also be of help on those displays.
The display controller itself does support more brightness levels, but these are chosen to give noticable change in brightness levels and also to help in chosing the best values for the 2 brighness control registers.
As there are 2 brighness control registers, there is some overlap in their range, but some combinations may lead to issues like coil whining noise or sometimes not even working displays as not all of these displays are wired to support both controls to be used.
"
"
``oledframedcmd,<line>,<text>``
","
The <line> parameter coresponds with the same lines as the plugin configuration has.
The <text> parameter must be a single command parameter.
Meaning, it must be wrapped in quites when using a space or comma as text.
If double quote characters are needed, wrap the parameter in single quotes or back quotes.
The updated line text is not stored in the settings itself, but kept in memory.
After a reboot the stored plugin settings will be used.
All template notations can be used, like system variables, or reference to a task value.
Given a cron expression and a date, you can get the next date which satisfies the cron expression.
Supports cron expressions with seconds field.
Based on implementation of `CronSequenceGenerator <https://github.com/spring-projects/spring-framework/blob/babbf6e8710ab937cd05ece20270f51490299270/spring-context/src/main/java/org/springframework/scheduling/support/CronSequenceGenerator.java>`_ from Spring Framework.
For a given cron expression, the plugin will send out an event every time the expression matches the current time.
The last execution time is stored as plugin output value and therefore it is also stored in RTC memory.
This means the node is able to deduct whether the last matching time was already executed or not in case of a reboot or crash.
Cron Expression Format
----------------------
The cron expression requires 6 positional arguments.
Most cron implementations only have 5 argumnets and thus can only per minute be set to trigger an event.
The extra argument handles seconds.
See also `Wikipedia - Cron <https://en.wikipedia.org/wiki/Cron>`_ for more detailed information.
..code-block::html
┌───────────── seconds (0 - 59)
│ ┌───────────── minute (0 - 59)
│ │ ┌───────────── hour (0 - 23)
│ │ │ ┌───────────── day of the month (1 - 31)
│ │ │ │ ┌───────────── month (1 - 12)
│ │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
│ │ │ │ │ │ 7 is also Sunday)
│ │ │ │ │ │
│ │ │ │ │ │
* * * * * *
For some arguments it can be useful to define a repeating pattern or a range.
*``*/15`` Whenever the field modulo 15 == 0 (e.g. for seconds 0, 15, 30, 45)
*``57/2`` for seconds or minutes equals ``57,59``. e.g. ``57,59 * * * * *`` == ``57/2 * * * * *``
A screenshot of a later relase of the plugin. The use of hardware serial communication
makes the transfer between the GPS and ESP a LOT more stable:
..image:: P082_Setup_1.png
Task settings
~~~~~~~~~~~~~
@@ -67,8 +72,8 @@ Sensor
***GPIO <-- TX**: Used to communicate with the GPS unit.
***GPIO --> RX**: Not used (optional), to push commands back into the GPS unit.
***GPIO --> PPS**: Experimental (optional), used to let the GPS unit update the time of the ESP.
***Dropdown**: ``SoftwareSerial`` lets you select any GPIO pin, ``HW Serial0`` is the preferred (most stable),``HW Serial0 swapped`` is similar to Serial0, ``HW Serial1`` is only able
to receive data from the GPS unit.
***Dropdown**: ``SoftwareSerial`` lets you select any GPIO pin, ``HW Serial0`` is the preferred (most stable),
``HW Serial0 swapped`` is similar to Serial0, ``HW Serial1`` is only able to receive data from the GPS unit.
..warning:: It's highly recommended you use either the ``HW Serial1`` or ``HW Serial0`` for stable reading of the GPS unit. But also remember to disable the serial in the
advanced settings page, if not the ESP will interfere with the GPS unit.
A screenshot of a later relase of the plugin. The use of hardware serial communication
makes the transfer between the GPS and ESP a LOT more stable:
..image:: P082_Setup_1.png
Task settings
~~~~~~~~~~~~~
@@ -69,8 +74,8 @@ Sensor
***GPIO <-- TX**: Used to communicate with the GPS unit.
***GPIO --> RX**: Not used (optional), to push commands back into the GPS unit.
***GPIO --> PPS**: Experimental (optional), used to let the GPS unit update the time of the ESP.
***Dropdown**: ``SoftwareSerial`` lets you select any GPIO pin, ``HW Serial0`` is the preferred (most stable),``HW Serial0 swapped`` is similar to Serial0, ``HW Serial1`` is only able
to receive data from the GPS unit.
***Dropdown**: ``SoftwareSerial`` lets you select any GPIO pin, ``HW Serial0`` is the preferred (most stable),
``HW Serial0 swapped`` is similar to Serial0, ``HW Serial1`` is only able to receive data from the GPS unit.
..warning:: It's highly recommended you use either the ``HW Serial1`` or ``HW Serial0`` for stable reading of the GPS unit. But also remember to disable the serial in the
advanced settings page, if not the ESP will interfere with the GPS unit.
This generic Device work together with the Homie controller (C014) :ref:`C014_page` and helps to handle incoming data. According to the `Homie convention <https://homieiot.github.io/>`_ every value can be announced as "setable" when the ``$setable`` flag is true.
ESPEasy initially designed as a sensor firmware receive data via commands. If you need to send data from your controller to a device you have to prepare the command in your controller software and send it to ESPEasy via ``cmd=`` or trigger rules by ``event=`` and send the command from there. To send values directly this plug-in can be used. It "only" defines the necessary parameters and the Homie controller sends the auto-discover information to the MQTT broker. To translate and direct this information to one or several commands a rule is used.
Setup
-----
The :ref:`C014_page` must be installed and enabled. Multiple instances of the plug-in are possible. One instance of the plug-in can define 4 different values / events.
..include:: P086_settings.repl
After reboot the controller should receive auto-discover information. Depending on the controller software used correct settings should be selected by default.
Define a rule for every value defined. Every rule should end with the ``HomieValueSet`` command to acknowledge the value back to the controller. The value must not necessarily be the same as the sent value (i.e. after extra limit checks). Numeric values are stored in the device. Due to RAM limitations String values are not saved.
For some controllers or dataset types it is not necessary to acknowledge the new value. They simply assume that the value arrived and processed correctly. Sometimes it could be useful not to acknowledge the value i.e. for slides sending updates frequently. The value can already be renewed when the acknowledgement arrives causing undesirable results or only to process values faster. For Switches it is essential to acknowledge the set state to keep the user aware of the real state and not the assumed state.
Example Rules for every value / event type
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
..code-block::html
// The "homie controller" schedules the event defined in the plug-in.
// Does NOT store string values or arrays in the "homie receiver" plug-in.
// Use homieValueSet to save numeric value in the plugin.
// This will also acknowledge the value back to the controller to get out of "predicted" state.
// Adjust device and event number according to your configuration
On eventInteger do
// insert your code here
homieValueSet,1,1,%eventvalue1%
endon
On eventFloat do
// insert your code here
homieValueSet,1,2,%eventvalue1%
endon
On eventBoolean do
// insert your code here
homieValueSet,1,3,%eventvalue1% // true or false (0/1 is stored in uservar)
endon
On eventString do
// insert your code here
homieValueSet,1,4,"%eventvalue%" // quotation requited for Strings!
endon
On eventEnum do
// insert your code here
homieValueSet,2,1,%eventvalue2% // name of picked item (number in %eventvalue1% and stored in uservar)
endon
On eventRGB do
// insert your code here
NeoPixelAll,%eventvalue1%,%eventvalue2%,%eventvalue3% // example for NeoPixel
- A sprinkler system switches 8 valves via relays. The relays are connected by PCF8574 port expander.
- Color LED using NeoPixel RGB & RGBW (WS2812B or SK6812)
Under the hood
--------------
The Homie convention defines several value types and some parameters for every value to enable the controller software to send standardized values to Homie enabled devices. Therefore the device has to send ``$datatype`` and ``$format`` attributes to describe the value type, format and range. This is all done for you by the :ref:`C014_page` according to the settings in this plug-in.
When a message arrives to the ``.../%deviceName%/%eventName%/set`` topic an event is triggered. From there commands can be used to perform certain actions. The parameters are passed by %eventvalue% variables:
- %eventvalue1% holds the numeric values for ``float`` and ``integer``
- %eventvalue1% holds the string value for ``string`` datatypes
- %eventvalue1% holds the number of the selected item of a enumerating list where %eventvalue2% holds the item name
- %eventvalue1%, %eventvalue2%, %eventvalue3% holds the intensity values of rgb or hsv ``color`` datatypes
Use the command ``homieValueSet,deviceNr,eventNr,value`` similar to ``TaskValueSet`` or ``DummieValueSet`` to acknowledge the received or new value back to the controller.
"``enum``","One item out of a comma seperated list","drop down list", "option 1,option 2,option 3",":red:`required`"
"``color``","Color value defined by rgb or hsv values. ``$fomat`` attribute required defining if ``rgb`` or ``hsv`` values are expected.","color picker", "255,255,255",":red:`required`"
"``min:max``","Range from min to max for numeric vaues.","gauges and sliders","0:100", ":yellow:`optional`"
"``rgb``","Colour value defined by red, green and blue values. Good to have direct control over each LED intensity of an RGB light.","colour picker", "255,255,255",":red:`required`"
"``hsv``","Color value defined by hue, saturation and value / intensity. Intuitive description of colours independent of the technology producing the colour. Good to drive RGBW LEDs","colour picker", "360,100,100",":red:`required`"
"**event name**","Name of the event which should be triggered as soon as a value arrives on the ``.../%eventName%/set`` topic ",":green:`all`",":red:`required`"
"**minimum**","Minimum limits of the value. Suitable for sliders and gauges. If min and max both are 0 no limits will be send.",":blue:`integer` :blue:`float`",":yellow:`optional`"
"**maximum**","Maximum limits of the value. Suitable for sliders and gauges. If min and max both are 0 no limits will be send.",":blue:`integer` :blue:`float`",":yellow:`optional`"
"**decimals**","As every data is sent over MQTT is sent as string a number of valid decimals can be specified",":blue:`integer` :blue:`float`",":yellow:`optional`"
"**enum values**","Comma separated list of possible states, or default text for string values",":blue:`enum`", ":red:`required for enum`"
One can also get `premade pigtails <http://www.usastore.revolectrix.com/Products_2/Cellpro-4s-Charge-Adapters_2/Cellpro-JST-PA-Battery-Pigtail-10-5-Position>`_.
Example using D1 mini PRO
~~~~~~~~~~~~~~~~~~~~~~~~~
..image:: P093_1.jpg
There is a good tutorial on how to do `soldering <https://chrdavis.github.io/hacking-a-mitsubishi-heat-pump-Part-1/#soldering>`_ and
Message is send every time a change is detected (i.e. one changes settings using IR remote control) and every X seconds, as set in the settings (60 seconds in above screenshot).
Commands
--------
..include:: P093_commands.repl
.. Events
.. ~~~~~~
..include:: P093_events.repl
Example
-------
A full working example using openHAB can be found `here <https://community.openhab.org/t/mitsubishi-heat-pump/91765>`_.
Special thanks
--------------
* to SwiCago and other maintainers and contributors of the *Arduino library to control Mitsubishi Heat Pumps* from https://github.com/SwiCago/HeatPump/,
* to Chris Davis for his great `blog <https://chrdavis.github.io/hacking-a-mitsubishi-heat-pump-Part-1/>`_,
* to Hadley from New Zealand for his *hacking* https://nicegear.co.nz/blog/hacking-a-mitsubishi-heat-pump-air-conditioner/,
* and all others that contributed on this subject.
.. |P052_shortinfo| replace:: The Senseair plugin can be used for multiple gas sensors from the company Senseair. The mostly used sensor is the S8 but other sensor units that work is tSense (K70), K30, K33, S8 (and soon LP8).
.. |P052_shortinfo| replace:: The Senseair plugin can be used for multiple gas sensors from the company Senseair. The mostly used sensor is the S8 but other sensor units that work is tSense (K70), K30, K33, S8, S11. (LP8 soon)
Sets the last byte(octet) of the IP address to this value, regardless of what IP is given using DHCP (all other settings received via DHCP will be used)
So if you receive 192.168.1.234 from your DHCP server and this value is set to "10",
then the used IP in your node is 192.168.1.10.
But since you're receiving more information from the DHCP server,
like subnet mask / gateway / DNS, it may still be useful.
This allows a somewhat static IP in your network (N.B. use it with an 'octet' outside the range of the DHCP IPs) while still having set to DHCP.
So if you take the node to another network which does use 192.168.52.x then you will know it will be on 192.168.52.10 (when setting this value to "10")
-`ESPeasy wiki - Basics: The I2C Bus <https://www.letscontrolit.com/wiki/index.php/Basics:_The_I%C2%B2C_Bus>`_
WD I2C Address
^^^^^^^^^^^^^^
The Watchdog timer can be accessed via I2C.
What can be read/set/changed must still be documented.
Use SSDP
^^^^^^^^
Is disabled for now since it is causing crashes.
SSDP can be used to help auto discovery of a node.
For example Windows uses it to find hosts on a network.
Connection Failure Threshold
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Number of failed network connect attempts before issuing a reboot (0 = disabled)
A side effect is that trying to reach some server which is offline, may also result
in reboots of the ESP node.
Force WiFi B/G
^^^^^^^^^^^^^^
Force the WiFi to use only 802.11-B or -G protocol (not -N)
Since the 802.11 G mode of the ESP is more tolerant to noise, it may improve link
stability on some nodes.
Restart WiFi on lost conn.
^^^^^^^^^^^^^^^^^^^^^^^^^^
Force a complete WiFi radio shutdown & restart when connection with access point is lost.
Force WiFi no sleep
^^^^^^^^^^^^^^^^^^^
This option will set the WiFi sleep mode to no sleep.
This may cause the node to consume maximum power and should only be used for testing purposes.
It may even lead to more instability on nodes where the power supply is not
sufficient or the extra heat cannot be dissipated.
Since changing the mode back to the default setting may lead to crashes in some core versions, this option is only enabled when starting the node.
To activate a change of this setting, a reboot is required.
Periodical send Gratuitous ARP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ESP node may sometimes miss ARP broadcast packets and thus not answer them if needed.
This may lead to the situation where a packet sent to the node cannot be delivered,
since the switch does not know how to route the packet.
To overcome this, the ESP node may send a *Gratuitous ARP* packet, which is
essentially an answer to a request which hasn't been made.
These gratuitous ARP packets however may help the switch to remember which
MAC address is connected via what port.
By default the ESP will send out such a gratuitous ARP packet every time it
receives an IP address and also when it was unable to make a connection to a host.
It could be the other host was replying, but the packet was not routable to the ESP node.
This *Periodical send Gratuitous ARP* option will send these kind of ARP packets
continuously with some interval.
This interval is defined in the source code in ``TIMER_GRATUITOUS_ARP_MAX`` (e.g. 5000 msec)
CPU Eco mode
^^^^^^^^^^^^
Will call delay() from scheduler during idle loops.
This will result in a significant energy reduction of up-to 0.2 Watt.
However, it is no guarantee the power consumption will be reduced.
For example when the host is receiving continuous ping requests, it will never activate the power save mode.
If the power save mode is active, the node may miss some broadcast packets.
For example the ESPeasy p2p packets will be missed every now and then, so do not
activate this mode when response time on received packets is important.
If the node is only sending packets (e.g. only a sensor connected and sending to some server),
then this is a great way to save energy and also reduce heat.
Show JSON
=========
Timing Stats
============
The timing stats page is a diagnostics tool to help pinpoint possible causes for issues a user may experience.
Throughout the code timing statistics are collected.
These can be represented in one big table with these columns:
- Description - Name of the function/plugin/controller being monitored
- Function - For plugins and controllers, the function call of that item
- #calls - Number of times seen.
- call/sec - Number of calls per second.
- min (ms) - Minimum duration in msec.
- Avg (ms) - Average duration in msec.
- max (ms) - Maximum duration in msec.
Please note that every time the timing stats page is loaded, the statistics will be reset.
So the statistics in the table reflect the period mentioned at the bottom of the page.
Interpret Statistics
--------------------
All timing values over 100 msec will be marked in bold.
To further help pinpoint some of these extremes, any row containing a bold timing is also given a green hue.
These are just some indicators where actions may take longer than optimal,
but it should not be considered as faulty when some value exceeds 100 msec.
Sometimes there is a perfectly fine explanation, like when a host is contacted on the other side of the globe.
Some function names give a good indication on how frequent they should be run.
For example ``FIFTY_PER_SECOND`` or ``TEN_PER_SECOND`` should be run at 50x/sec, resp. 10x/sec.
If these values differ substantially, something may be keeping the unit occupied.
Please note that if multiple instances of the same plugin are active, the number of calls per second should also be higher.
Also the number of samples should be large enough to be able to be useful.
For example if the ``ONCE_A_SECOND`` function is only observed once over a time interval of 1.99 second, it will be shown as a frequency of about 0.5 calls/sec.
That would seem much less than expected, but it fact it is perfectly fine.
As noted, it is to be preferred if no scheduled action on the node takes over 100 msec.
Some plugins, like OLED Framed may take more to update the display. Especially when scrolling is enabled.
But for other plugins it may deserve some attention if a plugin (almost) always takes over 100 msec to perform an action.
For example when minimum, average and maximum timing values are very close to each other,
then there may be reason to look into the plugin (or controller) to see if things can be improved.
For stable WiFi connection, every now and then a call to ``yield()`` or ``delay()`` should be made.
The time between such calls should be less than 10 msec.
So if some code execution does take longer than 10 msec, it must also make sure to call yield() every now and then.
When some entries in the timing stats happen frequently and take over 100 msec,
then they will for sure affect other plugins and controllers active on the same node.
This is also a very good reason to try and keep the timing stats values as low as possible.
Typical Outliers
----------------
Some of the timing stats are "nested".
For example the ``loop()`` function is probably the row with the largest maximum timing value, since all other functions are called from the loop.
The same applies for the two ``handle_schedule()`` functions. These either call scheduled actions to do, or things to be done when idle.
Both the ``loop()`` and the ``handle_schedule()`` functions are called very often.
Given enough time, their count value will be high, or even overflow since they are a 32-bit integer.
When this happens, the values for calls/sec or avg will be no longer useful.
A really busy node (CPU load > 75%) may drop a few scheduled calls in order to keep up.
This will be noticable in low values for calls/sec of the most frequently called functions like ``FIFTY_PER_SECOND`` or ``TEN_PER_SECOND``.
Tweaking Timeout using Timing Stats
-----------------------------------
As an example to tweak timing settings, take the time needed of one of the active controllers.
Lets assume the average time needed to contact such a controller is 30 msec.
Then it does not make sense to have the client timeout of that controller set to 1000 msec.
2x - 3x the average time is often a perfectly fine value to use as a timeout.
System Variables
================
@@ -31,10 +217,10 @@ The Factory Reset allows just that, and more.
Pre-defined module configurations help to setup the following:
- GPIO connected to button => plugin switch configured
- GPIO connected to relais => plugin switch configured
- GPIO connected to relay => plugin switch configured
- If there is a conflict with default I2C pins, then those are set to no pin assigned for I2C
- Status LED GPIO
- Added rule to combine button and relais.
- Added rule to combine button and relay.
..image:: images/FactoryReset_screenshot.png
@@ -43,3 +229,64 @@ For example, the Sonoff POW modules will not be selectable on a module with 1 MB
and the Sonoff Basic cannot be selected on a board with 4 MB flash.
..warning:: Pressing the red "Factory Reset" button will immediately perform the reset with the set selection.
Settings Archive
================
(Only available for core 2.5.0 and newer)
ESPeasy does not support an "undo" when it comes to settings.
Also cloning the settings of a node can be a lot of work.
The Settings Archive is an initial step to help cloning settings or reverting to an older version of the settings.
To revert to an older version, one still has to have a backup of the settings stored on some server which is accessible via HTTP.
Later the (automatic) upload of settings will be added, including encryption.
Download Settings
-----------------
..image:: images/SettingsArchive_download1.png
In order to download settings files, one has to select which ones to download and from where.
In the example shown here, the notification settings and rules were cloned from another ESPeasy node.
This other node is protected using a login, just to show basic authentication is also allowed.
Due to the needed memory resources, it is not possible to download from HTTPS.
This also meand the settings file and credentials are sent in plain text.
So do not use this to download settings with sensitive information directly from the internet.
On some nodes the remaining free space on the SPIFFS filesystem may be too small to keep the original file and a downloaded version.
For example on 1MB nodes, there is only 120k SPIFFS, which means it is not possible to have the ''config.dat'' file stored twice on the filesystem.
For these, the "Delete First" checkbox should be used.
But be aware that the file is deleted first, even if the host holding the files to download is unavailable.
Better try first with a smaller file on such nodes.
Especially if the node is hard to reach for a proper clean setup.
..image:: images/SettingsArchive_download2.png
After downloading the files, a summary is given.
A returned error can be something like 404 (file not available) or 401 (not authorized).
These are the standard HTTP error codes.
If ''config.dat'' or ''security.dat'' was downloaded, it is very important to do a reboot and not try to change (and save) anything on the ESPeasy node.
The old settings are still active in memory and if something will be saved, only the changed part may be saved.
This would corrupt the settings file.
Side Effects on cloning
-----------------------
Please note that cloning settings from another node may have some side effects.
For example the host name and unit number will be the same.
But also the controllers will be active and may start sending incorrect data.
Controller credentials may also be used on multiple nodes, which may also lead to various issues.
If the original node is configured to use static IP, the clone will use the same IP address.
This can render both inaccessible.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
TD-er
Michael Schröder
Bartlomiej Zimon
tonhuisman
Michael SchröderandGitHub
Bartłomiej ZimońandGitHub
borisk
Artem
Grovkillen
GrovkillenandGitHub
jimmys01
Toni
stefanandGijs Noorlander
Claas Anders Rathje
ESPEasy release bot
Baubau-LabandGitHub
uwekaditz
Florin
Florent Kilchoer
Plebs
uwekaditz
Yannick
hennPiandGitHub
Saverio Cisternino
BrainHunter
Victor AntonovichandGitHub
Hans-Rune Bue
Denys-ThreadPC
Maxim Prokhorov
ChrisandGitHub
Meek Home Automation
MrBenzim
Remco van Essen
okarasev
svmac
TungstenE2andGitHub
nichu
ppisljar
olliwr
Jonathan Westerholt
Eduard Iten
chunter1andGitHub
