* 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
* 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>
