- Increase wifi retry time (#14394)
- Remove 1 second system hang on wifi re-connect (retry)
- Try to limit the number of seconds unresponsiveness due to wifi reconnect
- Add command ``SetOption139 0/1`` to switch between pressure unit "mmHg" (0) or "inHg" (1) when ``SO24 1`` (#15350)
- Change double constants to float constants saving 200 bytes
When the CM110x integration has been added, the decode-status.py
a_features array was not updated accordingly.
Signed-off-by: Roberto Bonacina <roby.bonacina@tutanota.com>
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.
- implemented as XDRV53
- user must configure GPIO pins "DLP Rx" and "DLP Tx" for serial communication
- emulates an additional RELAY by sending ON/OFF commands to Projector
- continually polls the Projector's state to update virtual RELAY state
- blocks RELAY1 in ON state while Projector is running (to protect the lamp)
- serial codes for NEC and OPTOMA, ready for more manufacturers
- tested with NEC V300W
Theo Arends
Cossid
Roberto Bonacina
sfromis
Barbudor
Arnold Niessen
RaphDaMan
Jan Bubík