mirrors
/
Tasmota
mirror of https://github.com/arendst/Tasmota.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fixed some english

andrethomas 2018-11-26 19:58:25 +02:00
parent 015ae9e09c
commit 505f9d7edc
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
SetOption36.md

@ -2,15 +2,15 @@
The term CPU is used loosely here for the sake of making it easier to understand - When the term CPU is used it is actually referring to the ESP8266 SoC Micro Controller.
With the introduction of many new drivers, sensors and other functions as part of the Sonoff-Tasmota firmware it has become more important to pay specific attention to the amount of microcontroller clock cycles shared with the underlying SDK/Arduino ESP8266 Core.
With the introduction of many new drivers, sensors and other functions as part of the Sonoff-Tasmota firmware, it has become more important to pay specific attention to the amount of microcontroller clock cycles shared with the underlying SDK/Arduino ESP8266 Core.
The main application loop of the Sonoff-Tasmota firmware needs to visit each of the driver callbacks within the main loop to make sure all the required drivers and sensors receive the necessary processsing time whilst ensuring that the main loop does not overwhelm the need for processing time by the SDK / Arduino ESP8266 core.
The main application loop of the Sonoff-Tasmota firmware needs to visit each of the driver callbacks within the main loop to make sure all the required drivers and sensors receive the necessary processing time whilst ensuring that the main loop does not overwhelm the need for processing time by the SDK / Arduino ESP8266 core.
The highest priority drivers / sensors need to be called once per 50ms to operate as designed but most of the normal run of the mill drivers and sensors do not necessarily require this amount of intense polling. The 50 millisecond mark would normally considered to be an absolute minimum duty cycle for the main processing loop on ESP8266 boards whilst most Sonoff device derivatives will function perfectly well way above this default setting.
The highest priority drivers/sensors need to be called once per 50ms to operate as designed but most of the normal run of the mill drivers and sensors do not necessarily require this amount of intense polling. The 50-millisecond mark would normally be considered to be an absolute minimum duty cycle for the main processing loop on ESP8266 boards whilst most Sonoff device derivatives will function perfectly well way above this default setting.
To make this managable from device to device a new setting to has been introduced enabling the setting of the main loop target to a specific value in milliseconds.
To make this manageable from device to device a new setting to has been introduced enabling the setting of the main loop target to a specific value in milliseconds.
For default operation this will be set to 50 milliseconds as there are generally no drivers or sensors that need to be polled at a rate higher than this.
For default operation, this will be set to 50 milliseconds as there are generally no drivers or sensors that need to be polled at a rate higher than this.
To allow for power usage flexibility this value may also be increased to a value of up to 255 milliseconds which is very useful to reduce power and processing demand on non-time critical devices such as switches (which is what most of Sonoff-Tasmota is used for.)
@ -22,13 +22,13 @@ Let's assume the default value of 50 for SetOption36 and that a simple device su
In this case, the main firmware loop will iterate through all the drivers and sensors once per 50 milliseconds.
Current tests suggest that a simple device such as a Sonoff Basic requires only about 9.5 milliseconds to complete one itteration of servicing all the drivers and sensors enabled in the standard sonoff.bin firmware.
Current tests suggest that a simple device such as a Sonoff Basic requires only about 9.5 milliseconds to complete one iteration of servicing all the drivers and sensors enabled in the standard sonoff.bin firmware.
The time management functionality offered by SetOption36 will compute this time requirement automatically and allow the SDK / Arduino ESP8266 Core to service background tasks such as maintaining WiFi connectivity for the remainer of the time not spent in the main firmware loop - i.e. in the case of SetOption36 50 this would mean 50 milliseconds - ~9.5 milliseconds = ~40.5 milliseconds spent outside of the main firmware loop servicing SDK / ESP8266 Core functions which automaticaly consume less clock cycles when there is nothing intense for the SDK / ESP8266 Core to maintain or perform.
The time management functionality offered by SetOption36 will compute this time requirement automatically and allow the SDK / Arduino ESP8266 Core to service background tasks such as maintaining WiFi connectivity for the remainder of the time not spent in the main firmware loop - i.e. in the case of SetOption36 50 this would mean 50 milliseconds - ~9.5 milliseconds = ~40.5 milliseconds spent outside of the main firmware loop servicing SDK / ESP8266 Core functions which automatically consume fewer clock cycles when there is nothing intense for the SDK / ESP8266 Core to maintain or perform.
Sleep was previously the only option for Tasmota powered devices wishing to take advantage of power saving but it does have the disadvantage that the sleep would be a constant setting insofar that the entire firmware codebase would run at a pre-determined speed causing some drivers to run slower than expected and decreasing the speed at which services such as the WebUI is rendered (This varies between the various underlying cores depending on which version is used.)
Using SetOption36 instead of sleep has the advantage that CPU time will be given to any particular driver or process (lets say the WebUI) on demand as and when needed whilst spending most of its time waiting for the next main loop itteration to occur.
Using SetOption36 instead of sleep has the advantage that CPU time will be given to any particular driver or process (let's say the WebUI) on demand as and when needed whilst spending most of its time waiting for the next main loop iteration to occur.
During this time of waiting the ESP8266's power demand can go from 80mA all the way down to 20mA which yields great benefits for power saving vs. firmware responsiveness compared to the traditional sleep setting.
@ -50,13 +50,13 @@ In this example, 19% of 50 milliseconds would be 9.5 milliseconds (19/100*50), s
that there is sufficient headroom for the SDK / ESP8266 Arduino Core to do its background
work.
It is very important to remember that the sleep command will impact on this value negatively for all of the current Arduino Cores so in order not to distort the measurements it is recommended to use a sleep value of 0 when SetOption36 is being used to perform CPU/Power Load Management.
It is very important to remember that the sleep command will impact on this value negatively for all of the current Arduino Cores so in order not to distort the measurements, it is recommended to use a sleep value of 0 when SetOption36 is being used to perform CPU/Power Load Management.
On some devices which have many sensors connected you may observe the LoadAvg value exceeding 100 - This means that you have not set the value of SetOption36 high enough to accomodate all the sensors and drivers which need to be serviced.
On some devices which have many sensors connected you may observe the LoadAvg value exceeding 100 - This means that you have not set the value of SetOption36 high enough to accommodate all the sensors and drivers which need to be serviced.
In the latter case you have two options - either increase the value of SetOption36 to a higher one to maintain a load average well below 100, or use multiple devices to spread the load accross seperate Sonoff-Tasmota driven devices/boards.
In the latter case, you have two options - either increase the value of SetOption36 to a higher one to maintain a load average well below 100 or use multiple devices to spread the load across separate Sonoff-Tasmota powered devices/boards.
For the most part all Sonoff based products should perform well balanced with the default settting of 50 for SetOption36.
For the most part, all Sonoff based products should perform well balanced with the default setting of 50 for SetOption36.
### How to use SetOption36
@ -68,4 +68,4 @@ Where xx is the number of milliseconds you wish to target your main processing l
Should you set a SetOption36 value that is too low you will observe output on telemetry for the value of LoadAvg to be in excess of 100 - This is not ideal and should be avoided as it starves the Arduino Core / SDK of the needed processing time to take care of background tasks such as WiFi management.
For optimal operation of the Tasmota firmware it is recommended to keep your device running at a LoadAvg value of 75 or lower. If your device does not have any time critical drivers/sensors connected you are encouraged to increase the SetOption36 value to a higher value to gain from the power saving benefits thereof.
For optimal operation of the Tasmota firmware, it is recommended to keep your device running at a LoadAvg value of 75 or lower. If your device does not have any time critical drivers/sensors connected you are encouraged to increase the SetOption36 value to a higher value to gain from the power saving benefits thereof.