My directory tree structure:
I saw your question and the response here: https://github.com/airy10/esphome-m5stickC/issues/4#issuecomment-782873723
You need to have your YAML file one level above the custom_component directory. That’s probably why it couldn’t find the axp192 component. I’m not having any problems with axp192 with the custom_component files that same github repo.
It looks like there are significant differences between the st7735 component from airy10’s github repo and the official support for st7735 that’s now included in esphome. That official support is not very well documented, so I’m fooling around with trial and error and poking around in the code to try to figure out what’s needed.
I’ve got it working in black-and-white, though with the colors reversed (that is, the whole screen is white and drawing with COLOR_WHITE shows up as black on the screen). I assume that’s just some internal setting or init or something that needs a tweak. In other words, the display in M5Stick-C might not yet be directly supported.
Still fiddling. Here is what I have so far:
display:
- platform: st7735
model: INITR_MINI160X80
rowstart: 0
colstart: 0
devicewidth: 0
deviceheight: 0
cs_pin: GPIO5
dc_pin: GPIO23
reset_pin: GPIO18
rotation: 90
I also modified the lambda in the display configuration to only use COLOR_BLACK and COLOR_WHITE since the definitions of the colors from the custom component are no longer available.
I’m still confused as to the directory structure needed for axp192. My m5stickc3.yaml file is in the esphome directory along with all my other *.yaml files. I’ve tried compiling with the axp192 directory inside the custom_components and got an error. I move the axp192 directory up one level as you suggested and get the same error.
Here is my current structure:
Can you post the changes you made in your “lamda” ? I have mine commented out to get it to compile for now. Thanks.
I wasn’t suggesting you move your axp192. It should be directly under custom_componts. I was saying to move your YAML file up, which you have now done.
You just have to change all of the colors (ST77XX_WHITE, ST77XX_RED, ST77XX_BLUE) to COLOR_WHITE. That will show up as black on a white screen since it’s inverted on this device. If by some miracle you are seeing things on a black screen, then use COLOR_BLACK instead of COLOR_WHITE. I know that’s confusing, but it’s temporary until the display is working properly.
1 Like
That fixed my errors in the “lamda” section. The only existing error now is with the missing sensor.axp192
I’ve now got this display running correctly on my M5Stick-C, including colors. However, I had to make some modifications to the C++ and python code to get it working. I’ve opened an issue to see if the maintainer will make the same needed changes (or equivalent) so it will be simple to use the M5Stick-C.
The issue thread: https://github.com/esphome/issues/issues/1863
@MisterTFM Once you solve your axp192 problem, you should be able to use the display with either white-on-black or black-on-white with the current esphome release (1.16.2). To get other colors is a little more trouble, and the colors will show up incorrectly on the M5Stick-C until the issue is resolved.
But, if you would like to use some pre-defined colors (the sample config uses white, red, and blue), you could use some of the definitions that I have created. Read about them here: Here are some color definitions for use with ESPhome
1 Like
For the record, here’s my locally-working configuration.
display:
- platform: st7735
model: INITR_MINI160X80
rowstart: 0
colstart: 26
devicewidth: 0
deviceheight: 0
cs_pin: GPIO5
dc_pin: GPIO23
reset_pin: GPIO18
rotation: 270
usebgr: true
invert: true
The invert parameter doesn’t exist in the ESPhome release, but it’s needed to make the colors correct. The usbgr parameter is in the ESPhome release, but it’s not documented as far as I could find.
From what I’ve seen in the st7735 component in the dev branch, there will be some spelling changes for some of the parameters at some point in the future.
SOLVED: Got all my errors resolved when compiling my *.yaml file using ESPhome, that includes missing axp192, st7735 and lamda.
NOW I need some help setting up a new M5Stickc to be used with ESPhome. I can connect to it via USB cable and download examples using Arduino, but not sure what the next step is to compile and upload from HA using ESPHome.
I tried downloading *.bin file using ESPHome-Flasher 1.3.0, but also got an error. I’m guessing the USB 2.0 port on my computer might not be able to go at the fast baud rate that ESPHome-flasher uses:
Using ‘COM4’ as serial port.
Connecting…
Detecting chip type… ESP32
Connecting…
Chip Info:
- Chip Family: ESP32
- Chip Model: ESP32-PICO-D4 (revision 1)
- Number of Cores: 2
- Max CPU Frequency: 240MHz
- Has Bluetooth: YES
- Has Embedded Flash: YES
- Has Factory-Calibrated ADC: YES
- MAC Address: 94:B9:7E:8D:92:28
Uploading stub…
Running stub…
Stub running…
Changing baud rate to 460800
Changed.
Unexpected error: Reading chip details failed: Timed out waiting for packet header.
UPDATE: (2/28/21)
I reverted to another flasher, NODEMCU PyFlasher and am able to download *.bin files from the ESPHome complilations. However I can’t then download OTA from ESPHome the very same file:
ERROR Connecting to 192.168.1.230:3232 failed: timed out
If I download a WiFi test program using Arduino, I can then see the M5Stickc on my router, and can PING the address and get a valid response.
I’m trying to get this to work and the first time I tried to compile it files display.py had an error about importing st773_ns. But the code below worked
display:
- platform: st7735
model: "INITR_MINI160X80"
rowstart: 0
colstart: 26
deviceheight: 0
devicewidth: 0
cs_pin: GPIO5
dc_pin: GPIO23
reset_pin: GPIO18
rotation: 270
eightbitcolor: true
usebgr: true
# invert: true
after I found a file that I had overlooked before, I had to do this to get the files to compile
display:
- platform: st7735
# model: "INITR_MINI160X80"
# rowstart: 0
# colstart: 26
#deviceheight: 0
#devicewidth: 0
cs_pin: GPIO5
dc_pin: GPIO23
reset_pin: GPIO18
rotation: 270
#eightbitcolor: true
# usebgr: true
# invert: true
The file I missed was int.py
the code in this file
import esphome.codegen as cg
st7735_ns = cg.esphome_ns.namespace('st7735')
any thoughts on what I am missing?
Thanks
Bill, any idea how to set\control the brightness of the ST7735, using ESPHome and yaml?
I’m not sure, but I think theoretically that it’s possible via esphome.
By coincidence, I was recently trying to figure out how to do it with C++ code outside of esphome. For most TFT displays, you would use PWM on the backlight pin to affect the brightness. esphome provides the “ledc” component for doing that with the ESP32 native LEDC PWM capability.
However, in the M5Stick-C, the backlight is not wired to an ESP32 pin. Instead, it’s controlled by a pin on the AXP192 (the power controller). I haven’t yet figured out if there is more available than simply on/off. The AXP192 is interfaced to the ESP32 as an I2C device, and esphome has lots of support for I2C.
There is a datasheet for the AXP192 available here on the manufacturer’s site: http://www.x-powers.com/en.php/Info/product_detail/article_id/29. It’s 53 pages, so lots of detail. But it’s also mostly in Chinese, so I’m not really sure about most of those details.
I just had another look at the Water Leak Detector project, which uses an M5StickC and esphome. The YAML only describes sensing the battery level, but the code is their custom component for AXP192 does have a control for display brightness.
I only looked at the code just now. I didn’t try any experiments, but there’s a reasonable chance it works (at least in native C++ code … how to interface to esphome? dunno).
Here’s the Google Translate of the part of the datasheet describing the bits in AXP192 register 0x28.
I had a chance to experiment with brightness via M5’s arduino library for the M5StickC. They provide an AXP192 method for setting the brightness. (It’s called DisplayBreath(). Beats me why.) It sets the appropriate register values in the AXP192 to control the voltage supplied to the ST7735 backlight.
- Although it’s a 4-bit value in the AXP192, giving 16 levels, the API limits the value to a maximum of 12. Anything higher is reduced to 12. I suppose that has something to do with the voltages that the display will tolerate, but that’s just a guess.
- On my particular M5StickC, I could not see anything on the display with a value of 7 or below. It was completely dark to my human eyeballs.
So, the usable range of values is 8 - 12. There was a very noticeable difference at each step in that range.
I was updating the code for one of my m5stick-c’s and got this error
/status_binary_sensor.cpp.o
src/esphome/components/st7735/st7735.cpp: In member function 'virtual void esphome::st7735::ST7735::draw_absolute_pixel_internal(int, int, esphome::Color)':
src/esphome/components/st7735/st7735.cpp:275:25: error: 'struct esphome::Color' has no member named 'to_rgb_565'
auto color565 = color.to_rgb_565();
^
*** [/data/hotwater_heater_leak_sensor/.pioenvs/hotwater_heater_leak_sensor/src/esphome/components/st7735/st7735.cpp.o] Error 1
========================= [FAILED] Took 56.04 seconds =========================
I can get my yaml to compile but the upload fails on the “auto color565 = color.to_rgb_565();” I thought I saw a fix for this but cannot find it anymore. Anyone?
Thanks for the help with the 7735 and the M5stickC (not Cplus, which uses a st7789v I think)
For the record (16Dec2022) the parameters now have underscores:
- use_bgr (Optional, boolean): Use BGR mode. Default is false.
-
invert_colors (Optional , boolean): Invert LCD colors. Default is false.
ST7735 Display — ESPHome
My colours [UK spelling of ‘color’] are now fixed
display:
- platform: st7735
model: "INITR_18BLACKTAB"
reset_pin: GPIO18
cs_pin: GPIO5
dc_pin: GPIO23
rotation: 0
device_width: 128
device_height: 160
col_start: 0
row_start: 0
use_bgr: true
invert_colors: true