ok thanks for your time and for your help @nickrout
hello,
its a custom_component from @musk95 and i have succeed to compile because i change spi.SPI_DEVICE_SCHEMA is now spi.spi_device_schema() (display.py, line 22) https://github.com/airy10/esphome-m5stickC/issues/4#issuecomment-699189420
and custom st7789v from @musk95 use bl_pin instead of backlight_pin of esphome st7789v from @OttoWinter but now it display the same 135x240 image and it boot loop…
I have post an issue 2 days ago but no response yet. If somehone could help, appreciate 
I fixed what I could for this @ https://github.com/deftdawg/Esphome-TTGO-T-Display-Weather merging the RGB565 code from the display and image custom_components with the latest code from ESPHome 1.17-dev components.
However, I’m getting grayscaled ghosting of the wind sock (default image when no valid weather data is configured)… Something is still not quite right and it’s a bit too low level for me to know how to fix it.
Perhaps @kbx81, @musk95 or @semenyak could look at it and offer some guidance.
Also it would be immensely helpful if anyone had a RGB24 or other non-RGB595 image we could try with to see if it’s the display or the image conversion custom_components that are doing the corruption.
There are no examples provided for any of the valid formats for image that I can find anywhere on the ESPHome.io website 
Images are converted by the Python Pillow library from whatever format they are in to the format required for display on the hardware before they are flashed onto the device. At this point, you need to specify the RGB24 format in your ESPHome yaml config for this TTGO device.
It is no longer necessary to use @musk95’s custom display component. Use the display component that is built into ESPHome: https://esphome.io/components/display/st7789v.html
Hopefully these tips are helpful. I can take a closer look if not.
Thanks for the for the clairification, I wasn’t sure which end of the beast I was looking at and I definitely had it backwards… 
The documentation @ ST7789V TFT LCD — ESPHome is wrong, it suggests using RGB565 in the examples which fails validation:
To bring in color images:
image: - file: "image.jpg" id: my_image resize: 200x200 type: RGB565 ... display: ... lambda: |- it.image(0, 0, id(my_image));
I was able to get things working with RGB24, however it required conflating some weather conditions together as the firmware binaries are much larger with 24-bit (RGB24) images inside them than they would’ve been with 16-bit (RGB565)…
Do you know if there’s any plan to bring RGB565 support into esphome?
24-bit image quality seems excessive for small displays even if it is much simplier to code (reading bytes, rather than slicing bits)
For those trying to get this going, go grab the latest from my repo, follow the readme and delete esphome/custom_components
How large is the binary? If these are all 128x128 images, that’s 16384 pixels per image. Multiply by 24 again because that’s what RGB24 is (24 bits per pixel) and you get 393216 bits per image. Divide by 8 because bytes and that’s a little under 50 KB per image. I see 15 images in the repo so that’s 737280 bytes for all the images. ESP32s have 4 or 8 MB of FLASH storage. I don’t see how you would be exhausting that with images here. I can’t imagine that the code itself is so large that it consumes the remaining 3 or 7 MB (depending on exactly what hardware you have). Am I missing something else here?
There’s been some discussion in the ESPHome community about optimizing storage use as it relates to buffering images (among other data structures). Yes, it would be more optimal to store the images in the native RGB565 format that this display uses, but that would only reduce the size by about 33%. It’s definitely a gain, but given how much storage these devices already have, it’s a problem that I rarely hear anybody complain about – unlike like, say, a '328 with 16 KB of FLASH. 
1 Like
With all 15 included in RGB24 we get a firmware that is 1775840 ttgo_tdisplay_weather.bin almost 1.8MB.
OTA rejects it as out of space, forcing it on with esphome-flasher makes the unit bootloop until flashing with a smaller build.
The T-display has 4MB, but maybe only half can be flashed at a time? I’m not familar with how things work at a low level.
I remove 4 of the 15 images to get it down to a size where it will go on… 1677488 9 Jan 16:20 ttgo_tdisplay_weather-14.bin; just under 1.7MB, so that 33% would be just the difference to squeeze them all on I’m guessing. 
I think that to use OTA you need enough space to hold the old firmware and the new, so the old is not overwritten before the update is done. So, in essence on a 4MB system you have a limit of 2MB firmware, if you want to OTA.
Some components take up too much room to be worthwhile. The web server is an example of something that can usually result in a good paring down 
1 Like
Yeah that makes sense.
Looks like disabling the web server (which I’m kind of fond of) would save about 68kb from the build. So that’s definitely an idea.
Hello, I am trying to compile a configuration for a TTGO T Display on a VM with Ubuntu, unfortunately I am receiving the error at compilation:
Platform not found: ‘display.st7789v’.
Could you tell me how to fix it?
What version of esphome are you on?
I received a warning about Python 2 not being supported and to upgrade to Python 3, so I guess it is an older version?
I really do not have so much knowledge about Linux, how do I upgrade Python or ESPHome?
The version is at the bottom of the ui.
esp32@esp32:~/Projects/esphome$ esphome version
WARNING You're using ESPHome with python 3.5. Support for python 3.5 is deprecated and will be removed in 1.15.0. Please reinstall ESPHome with python 3.6 or higher.
Version: 1.14.5
This is what I get.
I don’t know what UI you are talking about, I am running esphome in terminal, unfortunately the addon doesn’t compile on my RPi if you are reffering to that so I am not using it.
I am not referring to the addon, the UI is available without the addon. https://esphome.io/guides/getting_started_command_line.html#bonus-esphome-dashboard
Anyway, ST7789 was introduced in 1.15. https://esphome.io/changelog/v1.15.0.html
I did a pip3 download and install which shows that the newest version was installed but actually everything crashes after that, I think I first have to do the Python switch and then upgrade esphome.
Can anybody help with that?
Now I am trying to install the latest Ubuntu on a new VM, maybe that has the newest Python and I can install the last esphome without problems …
I finally made it work, after installing a newer Ubuntu in VM and reinstalling esphome.
Really nice. I borrowed your weather code. Big thank you, I you helped me a lot.
here is my take: