* Fix some Tuya devices not handling commands sent without delay
* Also do not report WiFi status if MCU does not support it
* Support Tuya MCU 0x1c command (obtain local time)
* Use #ifdef USE_TIME to handle optional dependency on RTC
* Rename Tuya clock config variable to time to be consistent with the codebase
* Add tuya time configuration to test4
* setup ili9341 framework
used epaper-waveshare as start
* first version working
* added models for now only M5Stack
* get_buffer_length is huge
* fill, low/high watermark, buffer tests failed.
RAM is to small for ili9341 16 bit color mode
* removed high/low watermark debug log
* added standard 2.4" TFT model
* code cleanup
* make ledpin optional
busy pin is not needed
* make bufer 1 byte to avoid the
buffer allocation error
* gitignore
* added backlight pin to dump_config
* huge speed increase
8bit color framebuffer (256 colors)
lo and high watermark for drawing to screen
* fix for images
* higher spi data rates
* Set spi data rate to 40Mhz Experimental
* fixed: formatting
fixed: the last row and column being trimmed
fixed: namings
* Update the code to use Color class
* fixed minor color things
* fixed linting
* #patch minor fixes
* fix gitignore too
* Update esphome/components/ili9341/ili9341_display.cpp
Co-authored-by: Oleg <epushiron+github@gmail.com>
* reverting the changes as it's being fixed in PR-1241
Co-authored-by: Michiel van Turnhout <qris.online@gmail.com>
Co-authored-by: Michiel van Turnhout <m.vanturnhout@exxellence.nl>
Co-authored-by: Oleg <epushiron+github@gmail.com>
* Hbridge Christmas light component
Can be used for Christmas lights that use 2 wires to run 2 different strings of lights using a hbridge driver.
* Add Test
NOTE: I am unable to test this via the docker image
* Update hbridge_light_output.h
* Update hbridge_light_output.h
* Update hbridge_light_output.h
* Update light.py
* Fixed duty as white value bug fixed
* lint changes
* Name case change
* thanks lint
The Tuya MCU keeps its own internal minimum brightness setting. This value may
not match the minimum brightness setting for ESPHome, leading to some issues:
1. Dimming is limited--on some devices the default minimum is as high as 10%,
meaning the dimmest ESPHome will go is still quite bright.
2. HA will allow a user to set a value below the MCU minimum, but the MCU will
reject it and keep the previous setting, so the UI is confusing.
This PR adds a setting to configure the datapoint for setting the MCU minimum
brightness. If the setting is set, then ESPHome will synchronize the MCU's
minimum brightness with the one configured for ESPHome on startup.
* WIP: Advanced commands for portisch firmware
* Fix string code sending
* clang formatting
* Add new rf_bridge functions to test
* Add advanced code received trigger
* Fix copy-paste mistake in the advanced sending
* Fix log message to be consistent
* clang
* Remove extra +
* fix: FastLED SPI_DATA_RATE being truncated to 8 bits
FastLED expects SPI_DATA_RATE as an uint32_t, but we had it as uint8_t.
Fix that to avoid the data rate being truncated.
* fastled: allow specifying data rate
Previously, we've just taken the default data rate from FastLED.
However, that does not always work properly. In my case, I had a
slow level shifter that couldn't keep up with the 1 MHz data
rate default for WS2801. Long cabling might also be a reason why
one might want to reduce the data rate.
This will add a new optional "data_rate" config option where one
may specify the desired data rate as a frequency:
light:
- platform: fastled_spi
chipset: WS2801
data_pin: GPIO23
clock_pin: GPIO22
data_rate: 500kHz
num_leds: 178
* Add support for WPA2-EAP enterprise WiFi to ESP8266s.
This is fundamentally the same as on ESP32s only with different function names.
Update config checker to remove requirement for ESP32 for EAP authentication.
* Fix indent for clang
* Move pn532 -> pn532_spi
Add pn532_i2c
* Update i2c address
* Always wait for ready byte before reading
* Generalise the pn532 a bit more so less code in i2c and spi implementations
* clang
* Add pn532_i2c to test1
* Try to get setup working
* Fixes
* More updates
* Command consts
* A few upgrades
* Change text back to include 'new'
* Fix data reading
* Added tmp102 temperature sensor support
* Added sensor to test3.yaml
* Moved docstring to component root
* Tweak formatting from clang-format script
* Removed extra newline at the end of the file to satisfy pylint
* Update schema to match that of other single-value sensors
In ESPHome, sensors that only expose one value do not put the sensor under another key.
* Add missing import
* Fix test after structural change to component
* removed unused setting
* Update esphome/components/tmp102/tmp102.cpp
Co-authored-by: Otto Winter <otto@otto-winter.com>
Co-authored-by: Guillermo Ruffino <glm.net@gmail.com>
Co-authored-by: Jesse Hills <3060199+jesserockz@users.noreply.github.com>
* Incorrect time delay conversion breaks remote_transmitter_esp8266.cpp
I'm unsure why the conversion from microseconds into whole millseconds and remaining microseconds is done using a value of 16383, rather than 1000. This breaks the "on", "off" times, as well as the repeat wait_time if the period is more than 16383 microseconds.
I have confirmed behaviour with an oscilloscope. See https://community.home-assistant.io/t/infrared-remote-transmitter-not-working/232825
* Update esphome/core/helpers.cpp
Co-authored-by: Guillermo Ruffino <glm.net@gmail.com>
Co-authored-by: Guillermo Ruffino <glm.net@gmail.com>
* fix config check in OnlyWith configuration helper
OnlyWith configuration helper check now verifies whether a component
is configured in any of the packages not only in raw configuration
* fix C0301(line-too-long) pylint in imports
* fix flake8 (E127) over-indented line
* Fix Xiaomi merged packet parsing
solves #1500
* renamed variables and updated payload and value checking
* renamed function and parameter
* add function to header
* changed log message
This patch fixes faulty behaviour when both, invert and min_power/max_power
are set for a float output (e.g. PWM). The current code scales the output
level to the range [min_power, max_power] and subsequently inverts the value.
This leads to values that are outside the range [min_power, max_power].
This patch fixes the problem by inverting the requested level first and then
scaling it to the interval [min_power, max_power].
Co-authored-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
