You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

132 lines
5.4 KiB

Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
Introduced a HUB component + front panel IRQ handling A HUB component was introduced. This HUB component has all the knowledge about the Yeelight Bedside Lamp 2 hardware. It known what pins are used, that PWM frequencies to use, what pins to switch in binary mode, etc. etc. No configuration is required for this HUB component. It's automatically loaded when the light component is loaded. The light component will use the HUB component to access the pins that are required for driving the LED circuitry. Note that this simplifies the configuration by A LOT. There's no need anymore to configure the pinouts in the YAML file. This is a logical route to take, since we're talking about a factory-produced PCB with a soldered on ESP32 chip, which uses the same GPIO's and settings on all produced devices (I presume). It would be quite redundant to force every user into configuring these pinouts themselves. ** Beware to update your device yaml configuration ** There are a few pinouts left to move into the HUB. I will do that in the next commit. Your device yaml configuration can be simplified along with these changes. Some of the keys in the existing light configuration block will no longer work and will have to be removed (red, green, blue, white). ** Further development ** The HUB will be extended make it the central component that also handles the I2C communication. This way, there is a central place to regulate the traffic to and from the front panel. We will be able to build upon this by implementing extra, fully separated components that handle for example the front panel light level, the power button, the color button and the slider. ** Interrupt handler for the I2C IRQ trigger pin ** One requirement for the I2C communication has already been implemented: an interrupt handler for the GPIO that is used by the front panel to signal the ESP that a new touch or release event is avilable to be read. It doens't do anything functionally right now, but if you watch the log file, you will see that touch events are detected and that they trigger some log messages.
3 years ago
  1. import esphome.codegen as cg
  2. import esphome.config_validation as cv
  3. from esphome import pins
  4. from esphome.components.ledc.output import LEDCOutput
  5. from esphome.components.gpio.output import GPIOBinaryOutput
  6. from esphome.components.i2c import I2CComponent, I2CDevice
  7. from esphome.core import coroutine
  8. from esphome.core import CORE
  9. from esphome.const import (
  10. CONF_RED, CONF_GREEN, CONF_BLUE, CONF_WHITE, CONF_TRIGGER_PIN,
  11. CONF_SDA, CONF_SCL, CONF_ADDRESS, CONF_PLATFORM
  12. )
  13. CODEOWNERS = ["@mmakaay"]
  14. CONF_HUB_ID = "yeelight_bs2_hub_id"
  15. CONF_RED_ID = "red_id"
  16. CONF_GREEN_ID = "green_id"
  17. CONF_BLUE_ID = "blue_id"
  18. CONF_WHITE_ID = "white_id"
  19. CONF_MASTER1 = "master1"
  20. CONF_MASTER1_ID = "master1_id"
  21. CONF_MASTER2 = "master2"
  22. CONF_MASTER2_ID = "master2_id"
  23. CONF_FP_I2C_ID = "front_panel_i2c_id"
  24. CONF_LIGHT_HAL_ID = "light_hal"
  25. CONF_FRONT_PANEL_HAL_ID = "front_panel_hal_id"
  26. CONF_ON_BRIGHTNESS = "on_brightness"
  27. AUTO_LOAD = ["ledc", "output", "i2c"]
  28. yeelight_ns = cg.esphome_ns.namespace("yeelight")
  29. bs2_ns = yeelight_ns.namespace("bs2")
  30. LightHAL = bs2_ns.class_("LightHAL", cg.Component)
  31. FrontPanelHAL = bs2_ns.class_("FrontPanelHAL", cg.Component, I2CDevice)
  32. def make_config_schema():
  33. schema = cv.COMPONENT_SCHEMA.extend({
  34. # RGBWW Light
  35. cv.GenerateID(CONF_LIGHT_HAL_ID): cv.declare_id(LightHAL),
  36. cv.GenerateID(CONF_RED_ID): cv.declare_id(LEDCOutput),
  37. cv.Optional(CONF_RED, default="GPIO13"): pins.validate_gpio_pin,
  38. cv.GenerateID(CONF_GREEN_ID): cv.declare_id(LEDCOutput),
  39. cv.Optional(CONF_GREEN, default="GPIO14"): pins.validate_gpio_pin,
  40. cv.GenerateID(CONF_BLUE_ID): cv.declare_id(LEDCOutput),
  41. cv.Optional(CONF_BLUE, default="GPIO5"): pins.validate_gpio_pin,
  42. cv.GenerateID(CONF_WHITE_ID): cv.declare_id(LEDCOutput),
  43. cv.Optional(CONF_WHITE, default="GPIO12"): pins.validate_gpio_pin,
  44. cv.GenerateID(CONF_MASTER1_ID): cv.declare_id(GPIOBinaryOutput),
  45. cv.Optional(CONF_MASTER1, default="GPIO33"): pins.validate_gpio_pin,
  46. cv.GenerateID(CONF_MASTER2_ID): cv.declare_id(GPIOBinaryOutput),
  47. cv.Optional(CONF_MASTER2, default="GPIO4"): pins.validate_gpio_pin,
  48. # Front panel I2C
  49. cv.GenerateID(CONF_FRONT_PANEL_HAL_ID): cv.declare_id(FrontPanelHAL),
  50. cv.GenerateID(CONF_FP_I2C_ID): cv.use_id(I2CComponent),
  51. cv.Optional(CONF_SDA, default="GPIO21"): pins.validate_gpio_pin,
  52. cv.Optional(CONF_SCL, default="GPIO19"): pins.validate_gpio_pin,
  53. cv.Optional(CONF_ADDRESS, default="0x2C"): cv.i2c_address,
  54. cv.Optional(CONF_TRIGGER_PIN, default="GPIO16"): cv.All(
  55. pins.validate_gpio_pin,
  56. pins.validate_has_interrupt
  57. ),
  58. })
  59. return schema;
  60. CONFIG_SCHEMA = make_config_schema()
  61. @coroutine
  62. def make_gpio(number, mode="OUTPUT"):
  63. yield from cg.gpio_pin_expression({ "number": number, "mode": mode });
  64. @coroutine
  65. def make_gpio_binary_output(id_, number):
  66. gpio_var = yield make_gpio(number)
  67. output_var = cg.new_Pvariable(id_)
  68. cg.add(output_var.set_pin(gpio_var))
  69. yield from cg.register_component(output_var, {})
  70. @coroutine
  71. def make_ledc_output(id_, number, frequency, channel):
  72. gpio_var = yield make_gpio(number)
  73. ledc_var = cg.new_Pvariable(id_, gpio_var)
  74. cg.add(ledc_var.set_frequency(frequency));
  75. cg.add(ledc_var.set_channel(channel));
  76. yield from cg.register_component(ledc_var, {})
  77. @coroutine
  78. def make_light_hal(config):
  79. r_var = yield make_ledc_output(config[CONF_RED_ID], config[CONF_RED], 3000, 0)
  80. g_var = yield make_ledc_output(config[CONF_GREEN_ID], config[CONF_GREEN], 3000, 1)
  81. b_var = yield make_ledc_output(config[CONF_BLUE_ID], config[CONF_BLUE], 3000, 2)
  82. w_var = yield make_ledc_output(config[CONF_WHITE_ID], config[CONF_WHITE], 10000, 4)
  83. m1_var = yield make_gpio_binary_output(config[CONF_MASTER1_ID], config[CONF_MASTER1])
  84. m2_var = yield make_gpio_binary_output(config[CONF_MASTER2_ID], config[CONF_MASTER2])
  85. light_hal = cg.new_Pvariable(config[CONF_LIGHT_HAL_ID])
  86. yield cg.register_component(light_hal, config)
  87. cg.add(light_hal.set_red_pin(r_var))
  88. cg.add(light_hal.set_green_pin(g_var))
  89. cg.add(light_hal.set_blue_pin(b_var))
  90. cg.add(light_hal.set_white_pin(w_var))
  91. cg.add(light_hal.set_master1_pin(m1_var))
  92. cg.add(light_hal.set_master2_pin(m2_var))
  93. @coroutine
  94. def make_front_panel_hal(config):
  95. trigger_pin = yield make_gpio(config[CONF_TRIGGER_PIN], "INPUT")
  96. fp_hal = cg.new_Pvariable(config[CONF_FRONT_PANEL_HAL_ID])
  97. yield cg.register_component(fp_hal, config)
  98. cg.add(fp_hal.set_trigger_pin(trigger_pin))
  99. # The i2c component automatically sets up one I2C bus.
  100. # Take that bus and update is to make it work for the
  101. # front panel I2C communication.
  102. fp_i2c_var = yield cg.get_variable(config[CONF_FP_I2C_ID])
  103. cg.add(fp_i2c_var.set_sda_pin(config[CONF_SDA]))
  104. cg.add(fp_i2c_var.set_scl_pin(config[CONF_SCL]))
  105. cg.add(fp_i2c_var.set_scan(True))
  106. cg.add(fp_hal.set_i2c_parent(fp_i2c_var))
  107. cg.add(fp_hal.set_i2c_address(config[CONF_ADDRESS]))
  108. def to_code(config):
  109. # Dirty little hack to make the ESPHome component loader inlcude
  110. # the code for the "gpio" platform for the "output" domain.
  111. # Loading specific platform components is not possible using
  112. # the AUTO_LOAD feature unfortunately.
  113. CORE.config["output"].append({ CONF_PLATFORM: "gpio" })
  114. yield make_light_hal(config)
  115. yield make_front_panel_hal(config)