Up until a couple of days ago, the only thing I was using colors for was an ili9341-based display.
Several simple color definitions were provided in the custom component for that display. With ESPhome 1.16.0, that display is supported as a standard component, and the predefined colors are gone (except for COLOR_BLACK and COLOR_WHITE, which have been around for a long time).
Well, you don’t want to hear more of my story. I started thinking about ways to provide reusable color definitions without resorting to C++ code. I wanted them to be easily reusable by anybody in an efficient way. Here they are, and can be used by adding a few lines to your existing YAML file. The README gives usage examples. There is a named color definition for everything in the extended colors list of the CSS spec (~140 colors).
Hopefully the last problem: How do I get the background that is all WHITE, to be BLACK, so that I have the letters DRY (green) and WET (red) on a BLACK background?
You’re using the st7735 driver that’s now included in esphome and your device is an M5Stick-C, right? That st7735 driver isn’t right for colors on that device. I opened an esphome issue about it (https://github.com/esphome/issues/issues/1863) but haven’t seen any response from the developer.
As a workaround to get a black background before the driver is fixed, you can fill the background with COLOR_WHITE.
Produces a black circle in a white area rather than the other way around as it should be. Medium Blue comes out a yellowish green and Tomato comes out as a mid-blue.
I’m using a board type of m5stack-core-esp32. Latest version of esphome (not using HA).
Update: It looks like this is an error in the ili9341 display definition. It is inverting the display when it doesn’t need to. Apparently newer versions of the M5stack boards need the display inverting but older ones don’t
I’m still trying to work out how to change the definition. I can see where it is doing the invert but I can’t get it to change.
Yes, I also think it’s a bug, or rather an omission, in the esphome driver for that display. I’m hoping the person who integrated the driver fixes it. You can see a patch here for the M5StickC, though it might not apply smoothly to the current code. I imagine something similar would work for the device you are using.
There is probably some simple RGB transformation of the values I created to deal with an inverted display, but I don’t know what it would be. Some kind of color theory thing.
Unfortunately, the ILI9341 driver doesn’t expose the invert flag. Still that gives me another avenue for a fix.
My main problem at the moment is that I can’t work out how to override the driver. If I can work that out, I’ll at least be able to use it. It would be fantastic to have a single build type for all my ESP8266 and ESP32 devices.
I’ll keep plugging away at working out how to provide an overridden driver. Worse case is that I have to swap to the dev build.
UPDATE: Well, that took a while! I finally worked out that you have to edit the code in the place that pip installs it. Probably obvious to most people but I’m a node.js person not really a Python dev. So next problem was finding that location.
As I’m using Windows 10 with the UWP (app store) version of Python 3.8, this location is far from obvious. Eventually worked out that pip3 show esphome would tell me where it actually lives.
From there, I could simply replace line 227 of ~\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\esphome\components\ili9341\ili9341_display.cpp with:
this->invert_display_(false);
Instead of true. Recompile and now the colours are correct! I’ll see if I can come up with something more robust by exposing some more flags and then I’ll update the Issue, maybe even do a PR.
Besides editing the code in place, which is a bit fragile since it could be undone in an esphome update, there is a mechanism in esphome for defining “custom components”. It works quite well for components not in the esphome code base. I’ve had mixed success with making my own definitions of things that are already in the esphome code base (possibly due to mistakes I am making).
To create a custom component is a fairly simple process. In your case, download the source code for the ili9341 component (https://github.com/esphome/esphome/tree/dev/esphome/components/ili9341) or make a copy from your local esphome installation. It’s about a half dozen files. Put them all in a “custom_components/ili9341/” subdirectory of wherever you are storing your YAML config files. esphome should then automatically pick up your driver instead of the one it has in its own code base.
(As I said, I’ve had mixed success. If what I just described doesn’t work for you, you can have your money back. . Or someone who knows more about esphome innards can provide better advice.)
Thanks Bill, I discovered the custom components feature but I put the output c files in there rather than the actual component. As I say, I found it hard to actually find the component but I’ve got that now. I’ll have a go with the custom component when I get a chance.
At the moment I’m still struggling with some other esphome concepts so I’ll circle back to this when I have more time (probably when it breaks on the next update! ).
ESPHome is great but it certainly has a nasty steep learning curve!
If it helps and you haven’t be able to get ‘custome_components’ option working, for those on Linux supervised homeassistant the files should be found under /usr/share/hassio/homeassistant/esphome or there may be a number between ‘share’ and ‘hassio’ e.g. /usr/share/a8483744eedefef/hassio/homeassistant/esphome/components/li9341/ili9341_display.cpp
But as pointed out this could get over written if an update is released in the future
Hi Barry, thanks for the reply. Sorry, I should have updated this thread (I think I did update another related thread). I did eventually get the custom component method working.