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.

146 lines
5.1 KiB

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. #pragma once
  2. #include "../common.h"
  3. #include "../yeelight_bs2_hub.h"
  4. #include "color_instant_handler.h"
  5. #include "color_transition_handler.h"
  6. #include "esphome/components/ledc/ledc_output.h"
  7. namespace esphome {
  8. namespace yeelight {
  9. namespace bs2 {
  10. /**
  11. * A LightOutput class for the Yeelight Bedside Lamp 2.
  12. *
  13. * The function of this class is to translate a required light state
  14. * into actual physicial GPIO output signals to drive the device's LED
  15. * circuitry. It forms the glue between the physical device and the
  16. * logical light color input.
  17. */
  18. class YeelightBS2LightOutput : public Component, public light::LightOutput {
  19. public:
  20. /** Sets the Yeelight BS2 hub component. */
  21. void set_hub(YeelightBS2Hub *hub) { hub_ = hub; }
  22. /**
  23. * Sets the first GPIO binary output, used as internal master switch for
  24. * the LED light circuitry.
  25. */
  26. void set_master1_output(gpio::GPIOBinaryOutput *master1) { master1_ = master1; }
  27. /**
  28. * Set the second GPIO binary output, used as internal master switch for
  29. * the LED light circuitry.
  30. */
  31. void set_master2_output(gpio::GPIOBinaryOutput *master2) { master2_ = master2; }
  32. /**
  33. * Returns a LightTraits object, which is used to explain to the outside
  34. * world (e.g. Home Assistant) what features are supported by this device.
  35. */
  36. light::LightTraits get_traits() override
  37. {
  38. auto traits = light::LightTraits();
  39. traits.set_supports_rgb(true);
  40. traits.set_supports_color_temperature(true);
  41. traits.set_supports_brightness(true);
  42. traits.set_supports_rgb_white_value(false);
  43. traits.set_supports_color_interlock(true);
  44. traits.set_min_mireds(MIRED_MIN);
  45. traits.set_max_mireds(MIRED_MAX);
  46. return traits;
  47. }
  48. void add_on_state_callback(std::function<void(light::LightColorValues)> &&callback) {
  49. this->state_callback_.add(std::move(callback));
  50. }
  51. /**
  52. * Applies a requested light state to the physicial GPIO outputs.
  53. */
  54. void write_state(light::LightState *state)
  55. {
  56. auto values = state->current_values;
  57. // The color must either be set instantly, or the color is
  58. // transitioning to an end color. The transition handler will do its
  59. // own inspection to see if a transition is currently active or not.
  60. // Based on the outcome, use either the instant or transition handler.
  61. GPIOOutputs *delegate;
  62. if (transition_handler_->set_light_color_values(values)) {
  63. delegate = transition_handler_;
  64. } else {
  65. instant_handler_->set_light_color_values(values);
  66. delegate = instant_handler_;
  67. }
  68. // Note: one might think that it is more logical to turn on the LED
  69. // circuitry master switch after setting the individual channels,
  70. // but this is the order that was used by the original firmware. I
  71. // tried to stay as close as possible to the original behavior, so
  72. // that's why these GPIOs are turned on at this point.
  73. if (values.get_state() != 0)
  74. {
  75. master2_->turn_on();
  76. master1_->turn_on();
  77. }
  78. // Apply the current GPIO output levels from the selected handler.
  79. hub_->red->set_level(delegate->red);
  80. hub_->green->set_level(delegate->green);
  81. hub_->blue->set_level(delegate->blue);
  82. hub_->white->set_level(delegate->white);
  83. if (values.get_state() == 0)
  84. {
  85. master2_->turn_off();
  86. master1_->turn_off();
  87. }
  88. this->state_callback_.call(values);
  89. }
  90. protected:
  91. YeelightBS2Hub *hub_;
  92. esphome::gpio::GPIOBinaryOutput *master1_;
  93. esphome::gpio::GPIOBinaryOutput *master2_;
  94. GPIOOutputs *transition_handler_;
  95. GPIOOutputs *instant_handler_ = new ColorInstantHandler();
  96. CallbackManager<void(light::LightColorValues)> state_callback_{};
  97. friend class YeelightBS2LightState;
  98. /**
  99. * Called by the YeelightBS2LightState class, to set the object that can be
  100. * used to access the protected LightTransformer data from the LightState
  101. * object.
  102. */
  103. void set_transformer_inspector(LightStateTransformerInspector *exposer) {
  104. transition_handler_ = new ColorTransitionHandler(exposer);
  105. }
  106. };
  107. /**
  108. * This custom LightState class is used to provide access to the protected
  109. * LightTranformer information in the LightState class.
  110. *
  111. * This class is used by the ColorTransitionHandler class to inspect if
  112. * an ongoing light color transition is active in a LightState object.
  113. */
  114. class YeelightBS2LightState : public light::LightState, public LightStateTransformerInspector
  115. {
  116. public:
  117. YeelightBS2LightState(const std::string &name, YeelightBS2LightOutput *output) : light::LightState(name, output) {
  118. output->set_transformer_inspector(this);
  119. }
  120. bool is_active() { return this->transformer_ != nullptr; }
  121. bool is_transition() { return this->transformer_->is_transition(); }
  122. light::LightColorValues get_end_values() { return this->transformer_->get_end_values(); }
  123. float get_progress() { return this->transformer_->get_progress(); }
  124. };
  125. } // namespace bs2
  126. } // namespace yeelight
  127. } // namespace esphome