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.

310 lines
12 KiB

  1. < [Installation guide](installation.md) | [Index](../README.md) | [Flashing guide](flashing.md) >
  2. # Configuration guide
  3. I think, the best starting point for creating your own yaml configuration, is to
  4. look at the [example.yaml](example.yaml) file from the project documentation.
  5. This configuration was written with the functionality of the original firmware in mind
  6. and it makes use of all available options. This configuration guide can be used to
  7. fill in the blanks.
  8. The `xiaomi_bslamp2` platform provides various components that expose the core functionalities of the lamp.
  9. In the following table, you can find what components are used for exposing what parts of the lamp.
  10. | Part | Component(s) |
  11. | -------------------------- |--------------------------------------------------------|
  12. | ESP32 pinouts | [platform xiaomi_bslamp2](#platform-xiaomi_bslamp2) |
  13. | RGBWW LEDs | [light](#light) |
  14. | Front Panel Power button | [binary_sensor](#binary_sensor) |
  15. | Front Panel Color button | [binary_sensor](#binary_sensor) |
  16. | Front Panel Slider | [binary_sensor](#binary_sensor) (touch/release) |
  17. | | [sensor](#sensor) (touched slider level) |
  18. | Front Panel Illumination | [output](#output) (on/off + indicator level) |
  19. | Light mode propagation | [text_sensor](#text_sensor) |
  20. ## Platform: xiaomi_bslamp2
  21. At the core of the hardware support is the `xiaomi_bslamp2` platform, which provides two
  22. hub-style hardware abstraction layer (HAL) components that are used by the other components:
  23. one for driving the GPIO's for the RGBWW leds and one for the I2C communication between
  24. the ESP32 and the front panel.
  25. I do mention it here for completeness sake, but generally you will not have to add the
  26. following configuration option to your yaml file. It is loaded automatically by the
  27. components that need it, and the GPIO + I2C configurations are fully prepared to work
  28. for the Bedside Lamp 2 wiring out of the box.
  29. Therefore, you will not find this piece of configuration in the [example.yaml](example.yaml).
  30. Having said that, here are the configuration options:
  31. ```yaml
  32. xiaomi_bslamp2:
  33. # Options for the RGBWW LEDs HAL.
  34. red: "GPIO13"
  35. green: "GPIO14"
  36. blue: "GPIO5"
  37. white: "GPIO12"
  38. master_1: "GPIO33"
  39. master_2: "GPIO4"
  40. # Options for the Front Panel HAL.
  41. sda: "GPIO21"
  42. scl: "GPIO19"
  43. address: 0x2C
  44. trigger_pin: "GPIO16"
  45. ```
  46. The only reason that I can think of for adding this platform configuration to your yaml
  47. file, would be if you blew one or more or the ESP32 pins, and need to rewire functions
  48. to different pins.
  49. ## Component: light
  50. The light component creates an RGBWW light. This means that it can do colored light and
  51. cold/warm white light based on a color temperature.
  52. ```yaml
  53. light:
  54. - platform: xiaomi_bslamp2
  55. name: My Bedside Lamp
  56. id: my_bedside_lamp
  57. default_transition_length: 0.5s
  58. effects:
  59. - random:
  60. name: Randomize
  61. transition_length: 3s
  62. update_interval: 3s
  63. on_brightness:
  64. - then:
  65. - logger.log: The brightness changed!
  66. presets:
  67. my_color_presets:
  68. red: { red: 100%, green: 0%, blue: 0% }
  69. green: { red: 0%, green: 100%, blue: 0% }
  70. blue: { red: 0%, green: 0%, blue: 100% }
  71. yellow: { red: 100%, green: 100%, blue: 0% }
  72. purple: { red: 100%, green: 0%, blue: 100% }
  73. randomize: { effect: Randomize }
  74. my_white_presets:
  75. cold: { color_temperature: 153 mireds }
  76. chilly: { color_temperature: 275 mireds }
  77. luke: { color_temperature: 400 mireds }
  78. warm: { color_temperature: 588 mireds
  79. ```
  80. ### Configuration variables:
  81. * **name** (**Required**, string): The name of the light.
  82. * **id** (*Optional*, ID): Manually specify the ID used for code generation. By providing an id,
  83. you can reference the light from automation rules (e.g. to turn on the light when the power
  84. button is tapped)
  85. * **default_transition_length** (*Optional*, Time): The transition length to use when
  86. no transition length is set in a light call. Defaults to 1s.
  87. * **effects** (*Optional*, list): A list of [light effects](https://esphome.io/components/light/index.html#light-effects)
  88. to use for this light.
  89. * **presets** (*Optional*, dict): Used to define presets, that can be used from automations.
  90. See [below](#light-presets) for detailed information.
  91. * **on_brightness** (*Optional*, Action): An automation to perform when the brightness of the light is modified.
  92. * All other options from [the base Light implementation](https://esphome.io/components/light/index.html#config-light),
  93. except for options that handle color correction options like `gamma_correct` and `color_correct`.
  94. These options are superceded by the fact that the light component has a fully customized
  95. light model, that closely follows the light model of the original lamp's firmware.
  96. ### Light presets
  97. The presets functionality was written with the original lamp firemware functionality in mind:
  98. the user has two groups of presets available: one for RGB light presets and one for white light
  99. presets (based on color temperature). The color button (the top one on the front panel) can be
  100. tapped to switch to the next preset within the active preset group. The same button can be
  101. held for a little while, to switch to the other preset group.
  102. In your light configuration, you can mimic this behavior (in fact: it is done so in the
  103. [example.yaml](example.yaml)) by means of the presets system. This system consists of two
  104. parts:
  105. * Defining presets
  106. * Activating presets from automations
  107. **Defining presets**
  108. Presets can be configured in the `presets` option of the `light` configuration.
  109. Presets are arranged in groups. You can define as little or as many groups as you like.
  110. The example configuration uses two groups, but that is only to mimic the original behavior.
  111. If you only need one group, then create one group. If you need ten, go ahead and knock yourself out.
  112. The general structure of the presets configuration is:
  113. ```yaml
  114. light:
  115. presets:
  116. group_1:
  117. preset_1: ...
  118. preset_2: ...
  119. ..
  120. group_2:
  121. preset_1: ...
  122. preset_2: ...
  123. ..
  124. ..
  125. ```
  126. *Note: duplicate template names are ok, as long as they are within their own group.
  127. If you use duplicate preset names within a single group, then the last preset will override the
  128. earlier one(s).*
  129. A preset can define one of the following light types:
  130. * **RGB light**
  131. * **red** (**Required**, percentage): the red component of the RGB value.
  132. * **green** (**Required**, percentage): the green component of the RGB value.
  133. * **blue** (**Required**, percentage): the blue component of the RGB value.
  134. * **brightness** (*Optional*, percentage): the brightness to use (default = current brightness).
  135. * **transition_length** (*Optional*, time): the transition length to use.
  136. * **White light**
  137. * **color_temperature** (**Required**, mireds): the color temperature in mireds (range: "153 mireds" - "588 mireds")
  138. * **brightness** (*Optional*, percentage): the brightness to use (default = current brightness).
  139. * **transition_length** (*Optional*, time): the transition length to use.
  140. * **Light effect**
  141. * **effect** (**Required**, string): the name of a light effect to activate.
  142. **Activating presets from automations**
  143. Once presets have been configured, they can be activated using the `preset.activate` action.
  144. The following options are available for this action:
  145. * Switch to next preset group (and after the last, switch to the first):
  146. ```yaml
  147. preset.activate:
  148. next: group
  149. ```
  150. * Switch to next preset within currentl preset group (and after the last, switch to the first):
  151. ```yaml
  152. preset.activate:
  153. next: preset
  154. ---
  155. * Activate a specific preset group by specifying the group's name:
  156. ```yaml
  157. preset.activate:
  158. group: rgb
  159. ```
  160. * Activate a specific preset by specifying both the preset's name and group name:
  161. ```yaml
  162. preset.activate:
  163. group: white
  164. preset: warm
  165. ```
  166. Shorthand definitions are available for all these actions:
  167. ```yaml
  168. preset.activate: next_group
  169. preset.activate: next_preset
  170. preset.activate: rgb
  171. preset.activate: white.warm
  172. ```
  173. **Handling of invalid input**
  174. When a group or template is specified that does not exist, or if next group/preset
  175. is used while no presets have been defined at all, then the action will be ignored
  176. and an error will be logged.
  177. This is of course validation at run time. It would be better to validate the
  178. names at compile time more strictly, so the firmware won't compile when invalid
  179. names are in use. [Issue #15 was created for implementing this](https://github.com/mmakaay/esphome-xiaomi_bslamp2/issues/15).
  180. ## Component: binary_sensor
  181. Binary sensors can be added to the configuration for handling touch/release events
  182. for the front panel. On touch, a binary_sensor will publish `True`, on release it
  183. will publish `False`. The configuration of a binary_sensor determines what part
  184. or parts of the front panel are involved in the touch events.
  185. ```yaml
  186. binary_sensor:
  187. - platform: xiaomi_bslamp2
  188. id: my_bedside_lamp_power_button
  189. part: POWER_BUTTON
  190. on_press:
  191. then:
  192. - light.toggle: my_bedside_lamp
  193. ```
  194. For specifying specific parts of the front panel in the upcoming configuration variables,
  195. the following identifiers are available:
  196. * POWER_BUTTON (or its alias: POWER)
  197. * COLOR_BUTTON (or its alias: COLOR)
  198. * SLIDER
  199. ### Configuration variables:
  200. * **name** (*Optional*, string): The name of the binary sensor. Setting a name will expose the
  201. binary sensor as an entity in Home Assistant. If you do not need this, you can omit the name.
  202. * **id** (*Optional*, ID): Manually specify the ID used for code generation. By providing an id,
  203. you can reference the binary_sensor from automation rules (e.g. to retrieve the current state
  204. of the binary_sensor).
  205. * **part** (*Optional*, part identifier): This specifies what part of the front panel the binary sensor must
  206. look at. Valid options are: "any" (the default) or one of the abovementioned part identifiers.
  207. * All other options from [Binary Sensor](https://esphome.io/components/binary_sensor/index.html#config-binary-sensor).
  208. ## Component: sensor
  209. The sensor component publishes touch events for the front panel slider. The published value
  210. represents the level at which the slider was touched.
  211. *Note: This sensor only reports the touched slider level. It cannot be used for detecting release
  212. events. If you want to handle touch/release events for the slider, then you can make use of
  213. the [binary_sensor](#component-binary_sensor) instead.*
  214. ```yaml
  215. sensor:
  216. - platform: xiaomi_bslamp2
  217. - id: my_bedside_lamp_slider_level
  218. range_from: 0.2
  219. range_to: 0.9
  220. on_value:
  221. then:
  222. - light.turn_on:
  223. id: my_bedside_lamp
  224. brightness: !lambda return x;
  225. ```
  226. ### Configuration variables:
  227. * **name** (*Optional*, string): The name of the sensor. Setting a name will expose the
  228. sensor as an entity in Home Assistant. If you do not need this, you can omit the name.
  229. * **id** (*Optional*, ID): Manually specify the ID used for code generation. By providing an id,
  230. you can reference the sensor from automation rules (e.g. to retrieve the current state
  231. of the binary_sensor).
  232. * **range_from** (*Optional*, float): By default, published values vary from the range 0.01 to 1.00,
  233. in 20 steps. This option modifies the lower bound of the range.
  234. * **range_to** (*Optional*, float): This option modifies the upper bound of the range.
  235. * All other options from [Sensor](https://esphome.io/components/sensor/index.html#config-sensor).
  236. ## Component: output
  237. The (float) output component is linked to the front panel illumination + level indicator.
  238. Setting this output to value 0.0 will turn off the frontpanel illumination. Other values,
  239. up to 1.0, will turn on the illumination and will set the level indicator to the requested
  240. level (in 10 steps).
  241. ```yaml
  242. output:
  243. - platform: xiaomi_bslamp2
  244. id: my_bedside_lamp_front_panel_illumination
  245. ```
  246. ### Configuration variables:
  247. * **id** (**Required**, ID): The id to use for this output component.
  248. * All other options from [Output](https://esphome.io/components/output/index.html)
  249. ## Component: text_output
  250. < [Installation guide](installation.md) | [Index](../README.md) | [Flashing guide](flashing.md) >