I just released version 2023.4.0 of the firmware component. The main reason being compile errors when using a recent version of ESPHome (either errors about a riscv32 toolchain package not being available, or errors about esp_mac.h missing).
If you have these compile errors, then the new release should fix them.
All the LEDs in the front control panel can be controlled individually. I use that on my lamp in combination with a mwave presence sensor to turn on the power button LED when movement is detected. So doing something like always having that LED on is certainly possible.
I don’t have code ready to go for this, but I’ll take a look at what I can find or write for this.
In the packages: section, remove or comment out the reference to that config package: packages/behavior_default.yaml
If you wouldn’t comment this out, there would be duplicate definitions resulting in errors.
Now you have the default behavior configuration in your device config and can change the update_front_panel script. For example:
script:
- id: update_front_panel
mode: restart
then:
- front_panel.turn_off_leds: ALL
- front_panel.turn_on_leds: [ POWER ]
# In rgb or white light mode, turn on the front panel illumination,
# and show the current brightness level.
- if:
condition:
or:
- text_sensor.state:
id: my_light_mode
state: rgb
- text_sensor.state:
id: my_light_mode
state: white
then:
- front_panel.turn_on_leds: [ COLOR ]
- front_panel.set_level: !lambda return id(current_brightness);
- front_panel.update_leds:
So the script will always enable the power button, no matter the light mode or brightness.
packages:
bslamp2:
url: https://github.com/mmakaay/esphome-xiaomi_bslamp2
ref: dev
files:
- packages/core.yaml
# - packages/behavior_default.yaml
- packages/ota_feedback.yaml
- packages/activate_preset_svc.yaml
refresh: 0s
# ------------------------------------------------------------------------
# Behavior: default
#
# * Presets that resemble the original Xiaomi firmware
# (one group of RGB colors, one group of white light colors)
# * Tapping the power button, toggles the light
# * Holding the power button, turns on night light mode
# * Tapping the color button, activates the next preset
# * Holding the color button, activates the next preset group
# * Touching the slider sets the brightness level and turns on the lamp
# * When the light is on, the front panel illumination is on
# * When the night light is on, only the power button is illuminated
# ------------------------------------------------------------------------
# A global variable to keep track of the brightness level. This one is
# used by the update_front_panel script to represent the brightness level
# using the front panel illumination.
#
# This variable is used instead of querying the light component directly,
# because that brightness level may vary during a light transition. The
# behavior that I want: when you touch the front panel slider at 75%, then
# the illumination rises directly to that level, while the light might do
# a smooth transition.
globals:
- id: current_brightness
type: float
initial_value: "0.0"
# This script updates the front panel illumination.
script:
- id: update_front_panel
mode: restart
then:
- front_panel.turn_off_leds: ALL
- front_panel.turn_on_leds: [ POWER ]
# In rgb or white light mode, turn on the front panel illumination,
# and show the current brightness level.
- if:
condition:
or:
- text_sensor.state:
id: my_light_mode
state: rgb
- text_sensor.state:
id: my_light_mode
state: white
then:
- front_panel.turn_on_leds: [ COLOR ]
- front_panel.set_level: !lambda return id(current_brightness);
# In night light mode, turn off the front panel illumination, except
# for the power button.
# - if:
# condition:
# - text_sensor.state:
# id: my_light_mode
# state: night
# then:
# - front_panel.turn_on_leds: [ POWER ]
- front_panel.update_leds:
Did you disconnect the GPIO0 to GND connection after flashing? Otherwise, the device would stay in flashing mode after powering it up again.
When it does flash (and likely still does), it would be interesting to see if there is any logging on the serial output terminal. A booting ESP32 ought to spit out at least a few lines of logging, possibly showing why it won’t boot through.
Hello, I made a custom pcb with esp32 and WS2812B leds that is inspired by the xiaomi bedside lamp and I would like to use the touch input sensor to control the brightness and color. Could you please help with understanding how it is controlled and how to program it with c++?
How could I activate the log? I click in the LOGS link in ESPHome dashboard, but there is no info, just this:
INFO ESPHome 2024.3.1
INFO Reading configuration /config/bedside-lamp-xxx.yaml...
INFO Updating https://github.com/mmakaay/esphome-xiaomi_bslamp2@dev
INFO Starting log output from 172.16.x.x using esphome API
INFO Successfully connected to bedside-lamp-xxx @ 172.16.x.x in 0.034s
INFO Successful handshake with bedside-lamp-xxx @ 172.16.x.x in 0.113s
@internscb : I documented my reverse engineering of the bslamp2. This documentation can be found in my GitHub repository for storing this effort. Specifically the i2c_font_panel directory.
How to program it with C++ can be found in the main GitHub repository that holds the production code for my bslamp2 implementation. Most of the interesting code can be found in front_panel_hal.h (link)
@zorrua More extensive logging can be accomplished in the standard ESPHome way. All you have to do is add a log level in a logging: section in your YAML configuration file, e.g.:
Mind to tune down the log level once you’re done with looking at those logs. This device uses a single-core ESP32 chip, and busy logging can now and then get in the way of the device operating correctly.