Noticed a small inconsistency of the default light WebColor palette not fully matching the light palette example in my_user_config.h and the docs WebUI page. The color for COLOR_BUTTON_OFF was a long time ago changed from dark blue #08405e to the better-working pale blue #a1d9f7 without this being reflected in the defaults used in the absence of another #define value.
Of course, this normally makes no difference as the standard my_user_config.h defines a full dark palette anyway, but still....
PR https://github.com/arendst/Tasmota/pull/15468 to "simplify drivers" caused a breaking change to this specific one, as it will instantiate the class without arguments. This fails https://github.com/arendst/Tasmota/discussions/24380
Removing the empty argument list allows `import Shift595` (suggested in the code block) to work, and do the class instantiation there. Ok with this minimal fix, @s-hadinger or should more refactoring be done?
Command pointer table broken after refactoring https://github.com/arendst/Tasmota/commit/3a28938b9153d01e7ccef0a03d981251ced56123
The error with a comma before an entry instead of after, to match the other pointers, looks very obvious to me. Hence, I'm submitting this PR without having the hardware, and thus not able to do a runtime test.
I observed that the definition of command names became mangled with commit https://github.com/arendst/Tasmota/commit/2bc5f682b04ab8fb0a7975763c1a4c2f4a8d54b5 due to vertical bar not being placed where it should. With no bar after `D_CMND_CPU_FREQUENCY`, the command name became concatenated with the next `D_CMND_SETSENSOR` with the "funny" effect that command name `CpuFrequencySetSensor` got matched with `&CmndSetSensor`
The reason for it not being matched with `&CmndCpuFrequency` is that there is a bar too many before the `Info` command name, as previous command name lines all finish with `"|"`. Hence an extra command table entry was created, meaning that the mismatch "only" affected command names `Info`, `TouchCal`, `TouchThres`, `CpuFrequency` and `SetSensor`.
Issue is only for ESP32, as both mishaps happened in a block conditional on `#ifdef ESP32`.
Arguably, it could make sense to have all the lines with command names start with `"|"` as a consistent way of formatting the lines without the special case of ending `"|"` to be omitted for the very last command name line, but I wanted to only make minimal changes
RGB565 value for pink was same as magenta. This is obviously wrong, hence correcting to the "pink" value from the docs.
While I'm far from certain about the "right" shading of color nuances, the correction does "reasonably pink" in my eyes (on a ST7789), and assuming that the value from the docs was sourced from something relevant to the small displays used with Tasmota, I consider the change to be at least a move in the right direction.
Still, the corrected value (FF80C0 in RGB888) does have the name "tea rose" when using HTML color codes as a reference, but "some people" may have more interest in long discussions like what pink "really" is.
On ESP32, with `#define JPEG_PICTS` without the scripter, build fails due to the function `Draw_jpeg` being defined after use. Order swapped to satisfy the compiler.
Change tested to compile without errors, but not being 100% sure of when/how it is supposed to work, no verification of this.
Adding SetOption references for a few `#define`, to make the relation clear, and in the common searchable format like `[SetOption147]`. Also added that since some time now, this option covers both `SSerialReceived` and `IrReceived`.
Changing default for DisplayMode from 1 to 0. Users are getting confused by the display doing something they did not ask for (and not being aware of DisplayMode). This got worse with LVGL/HASPmota displays becoming common, with users having much less reason to dive into the old DisplayXxxxx commands. And it may even be hard to see that it is even a display of time/date causing the display to flicker.
Changing default for DisplayDimmer from 10% to 50%. The low brightness of 10% is not always easy to see, especially in daylight. 50% is generally better, while not going "full blast" with 100%.
Uses mktime to calculate the epoch value from the broken-down time structure, could potentially be tuned if deemed too inefficient in case of the caller already having the epoch value nearby.
Not all flag names were updated to match updates to Tasmota source in `support_features.ino`. I assume the changes to be uncontroversial, with the possible exception of:
While `USE_TUYA_DIMMER` arguably is a more descriptive name than `USE_TUYA_MCU` the former name is not found anywhere in Tasmota code, which has
```
#if defined(USE_LIGHT) && defined(USE_TUYA_MCU)
feature2 |= 0x00008000; // xdrv_16_tuyadimmer.ino
#endif
```
My assumption is that the actually used names "wins", to avoid user confusion, even if you could say that the name `USE_TUYA_MCU` is too broad for the actual feature. In principle, it would be more logical to create a new "real" `#define` name, but backwards compatibility and all that.... Makes sense?
I'm ok either way....
Output of decode-status.py lacks information about the latest two new sets of feature bits, due to the constant for array size not being updated when the array was expanded. Code changed to avoid this magical number, but instead check size of array with texts, and array with features from the JSON format in Status 4, using the lowest number to provide as many bits as both Tasmota version and Python code supports. A warning is printed if the number of feature bits from Tasmota is higher than supported in the current iteration of Python code.
Based on history, I'm assuming that updates are first done in arendst/Tasmota development, later replicated to tasmota/Tasmota-decode-status. If wrong, I can move the change there.
Output of decode-status.py lacks information about the latest two new sets of feature bits, due to the constant for array size not being updated when the array was expanded. Code changed to avoid this magical number, but instead check size of array with texts, and array with features from the JSON format in Status 4, using the lowest number to provide as many bits as both Tasmota version and Python code supports. A warning is printed if the number of feature bits from Tasmota is higher than supported in the current iteration of Python code.
Based on history, I'm assuming that updates are first done in arendst/Tasmota development, later replicated to tasmota/Tasmota-decode-status. If wrong, I can move the change there.
sfromisandGitHub
