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] = {
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.
See the defines in `_Plugin_Helper.h`
They were already used in some plugins, but now made globally available since they make the source much more readable.
You can now name the physical USB port names (ini file in settings folder).
You can now download (and unzip) directly from GitHub (small "update" button in top right)
You will now receive announcements about ESP Easy (opt out) if we push a message.
The 'old' limit of 4294 seconds was 2^32 usec.
By casting it to an uint32, you may get unexpected results when multiplying it by 10^6 again.
So better to use uint64 as variable and work on that one, now the deepsleep functions support uint64.
Make deepSleep work again with Core 2.5.0. Changed ESP.deepSleep() to ESP.deepSleepInstant().
Refactor delay variable to dsdelay to avoid conflicts with the delay() function.
Added a delay(100) before going to sleep to give the node time to send the last log messages.
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,24 @@ 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,12 @@ 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.
- 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_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.
- xxx_core_260_sdk2_alpha -> core 2.6.0 alpha version (under development) using SDK 2.2.1
- xxx_core_260_sdk222_alpha -> core 2.6.0 alpha version (under development) using SDK 2.2.2
- xxx_core_260_sdk3_alpha -> core 2.6.0 alpha version (under development) using SDK 3.0.0-dev (under development too)
Chip can be:
- ESP8266 => Most likely option
@@ -31,13 +35,28 @@ Chip can be:
- ESP32 => Experimental support at this moment
MemorySize can be:
- 1024 => 1 MB flash modules (e.g. almost all Sonoff modules)
"MessageBody":"We are in need for support. Currently we need to do a whole lot of consulting to keep us floating. If we could get funding for at least 50% of our time we could make a lot more than with our current 10-15%. Ideal would be 100% funding but we're realistic :) <br><br>We will add extra goodies for those who support us through monthly payments using Patreon.<br><br><br>Thanks for your support (from TD-er and Grovkillen)!",
"MessagePicture":"",
"MessageWriter":"",
"MessageColor":"",
"MessageDate":"2018-12-12"
"MessageWriter":"Grovkillen",
"MessageColorBG":"",
"MessageColorFont":"",
"MessageDate":"2019-01-07",
"MessageType":"general",
"MessageLink1text":"Patreon",
"MessageLink1":"",
"MessageLink2text":"Ko-Fi",
"MessageLink2":"",
"MessageLink3text":"Paypal",
"MessageLink3":""
},{
"MessageTitle":"Test2",
"MessageBody":"",
"MessageTitle":"First announcement test",
"MessageBody":"We're planning on using the ESP Easy Flasher to push announcements to the users. Hopefully this will work out good and make more people aware of how things are evolving. This will be used as a channel for pretty much anything regarding the prject. Thanks for your support!",
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
---------------------
@@ -259,5 +311,5 @@ This allows to:
Since AES has a block size of 16 bytes (128 bit), the size of the data block is defined as a block of 16 bytes.
This allows up-to 1 MB of messages. (2^16 * 2^4 = 2^20)
An UDP datagram sent over IPv4 cannot exceed 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP header).
An UDP datagram sent over IPv4 cannot exceed 65,507 bytes (65,535 - 8 byte UDP header - 20 byte IP header).
In IPv6 jumbograms it is possible to have UDP packets of size greater than 65,535 bytes.
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.
As described already, each task can produced one or more events, one for each measured value. You should not name your devices and value names so that the combination equals to any of the below listed system events!
","
.. code-block:: html
on DHT11Outside#Temperature>20 do
GPIO,2,1
endon
"
"
``System#Wake``
Triggered after power on.
","
.. code-block:: html
on System#Wake do
GPIO,15,1
endon
"
"
``System#Boot``
Triggered at boot time.
","
.. code-block:: html
on System#Boot do
GPIO,2,1
timerSet,1,30
endon
"
"
``System#Sleep``
Triggered just before the ESP goes to deep sleep.
","
.. code-block:: html
on System#Sleep do
GPIO,2,0
endon
"
"
``MQTT#Connected``
Triggered when the ESP has connected to broker.
","
.. code-block:: html
on MQTT#Connected do
Publish,%sysname%/status,First message!
endon
"
"
``MQTT#Disconnected``
Triggered when the ESP has disconnected from the broker.
","
.. code-block:: html
on MQTT#Disconnected do
Reboot
endon
"
"
``MQTTimport#Connected``
Triggered when the ESP has connected to broker (the MQTT Import plugin uses a separate connection than the generic one).
","
.. code-block:: html
on MQTTimport#Connected do
Publish,%sysname%/status,MQTT Import is now operational
endon
"
"
``MQTTimport#Disconnected``
Triggered when the ESP has disconnected from the broker (the MQTT Import plugin uses a separate connection than the generic one).
Triggered when the ESP has changed to access point, will also trigger first time the unit connects to the Wi-Fi.
","
.. code-block:: html
on WiFi#ChangedAccesspoint do
Publish,%sysname%/status,AP changed
endon
"
"
``WiFi#ChangedWiFichannel``
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``
Triggered when the ESP has set the AP mode (access point) active.
This may happen when no valid WiFi settings are found or the ESP cannot connect to the set AP, but it can also be enabled via some command.
N.B. Sending a publish command may not be very useful on this event, since this will mainly happen when there is no WiFi connection.
","
.. code-block:: html
on WiFi#APmodeEnabled do
... // Some command
endon
"
"
``WiFi#APmodeDisabled``
Triggered when the ESP has disabled the AP mode (access point).
This can happen some time (default 60 seconds) after a WiFi connection has been made. Or disabled using some command.
","
.. code-block:: html
on WiFi#APmodeDisabled do
Publish,%sysname%/status,AP disabled
endon
"
"
``Login#Failed``
Triggered when (someone) has tried to login to a ESP unit with admin password enabled, but have failed to enter correct password.
","
.. code-block:: html
on Login#Failed do
Publish,%sysname%/warning,Intruder alert!
endon
"
"
``Time#Initialized``
Triggered the first time (after boot) NTP is updating the unit.
","
.. code-block:: html
on Time#Initialized do
Publish,%sysname%/Time,%systime%
endon
"
"
``Time#Set``
Triggered when the time is set by an update from NTP.
","
.. code-block:: html
on Time#Set do
Publish,%sysname%/Time,%systime%
Publish,%sysname%/NTP,Updated time at: %systime%
endon
"
"
``Rules#Timer=``
As described already, triggered when a rules timer ends (setting a timer to 0 will disable the timer).
","
.. code-block:: html
on Rules#Timer=1 do
GPIO,2,1
endon
"
"
``Clock#Time=``
Triggered every minute with day and time like: Mon,12:30 or Tue,14:45. You can define triggers on specific days or all days using 'All' for days indicator. You can also use wildcards in the time setting like All,**:00 to run every hour.
","
.. code-block:: html
on Clock#Time=All,12:00 do //will run once a day at noon
GPIO,2,1
endon
on Clock#Time=All,**:30 do //will run half past every hour
GPIO,2,1
endon
on Clock#Time=All,%sunrise% do //will run at sunrise (%sunset% is also available)
GPIO,2,1
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).
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.
ESPEasy release bot
Gijs NoorlanderandGitHub
Plebs
stefan
jimmys01
hennPiandGitHub
Grovkillen
Saverio Cisternino
Bartłomiej ZimońandGitHub
Toni
Victor AntonovichandGitHub
Hans-Rune Bue
Denys-ThreadPC
Maxim Prokhorov
Artem
ChrisandGitHub
Meek Home Automation
MrBenzim
Remco van Essen
okarasev
svmac
TungstenE2andGitHub
Bartłomiej ZimońandGitHub
nichu
ppisljar
olliwr
Jonathan Westerholt
Eduard Iten
chunter1andGitHub
