-
-
Save itmaybeokay/bd5c7aa574e8ed517148cf9c4c267bdb to your computer and use it in GitHub Desktop.
| esphome: | |
| name: panel | |
| friendly_name: panel | |
| platformio_options: | |
| build_flags: "-DBOARD_HAS_PSRAM" | |
| board_build.arduino.memory_type: qio_opi | |
| board_build.flash_mode: dio | |
| board_upload.maximum_ram_size: 524288 | |
| esp32: | |
| board: esp32-s3-devkitc-1 | |
| variant: esp32s3 | |
| framework: | |
| type: esp-idf | |
| sdkconfig_options: | |
| CONFIG_ESP32S3_DEFAULT_CPU_FREQ_240: y | |
| CONFIG_ESP32S3_DATA_CACHE_64KB: y | |
| CONFIG_SPIRAM_FETCH_INSTRUCTIONS: y | |
| CONFIG_SPIRAM_RODATA: y | |
| # Enable logging | |
| logger: | |
| i2c: | |
| sda: GPIO08 | |
| scl: GPIO09 | |
| # scan: True | |
| id: bus_a | |
| ch422g: | |
| - id: ch422g_hub | |
| address: 0x24 | |
| # Of the CH422's twenty-four i2c addresses, 0x24 is the correct one to use in the setup here. | |
| # Still, wow, that's a lot of i2c addresses. | |
| # Enable Home Assistant API | |
| api: | |
| encryption: | |
| key: | |
| ota: | |
| - platform: esphome | |
| password: | |
| wifi: | |
| ssid: !secret wifi_ssid | |
| password: !secret wifi_password | |
| # Enable fallback hotspot (captive portal) in case wifi connection fails | |
| ap: | |
| ssid: "Panel Fallback Hotspot" | |
| password: | |
| captive_portal: | |
| psram: | |
| mode: octal | |
| speed: 80MHz | |
| # Define display | |
| display: | |
| - platform: rpi_dpi_rgb | |
| id: my_display | |
| auto_clear_enabled: false | |
| color_order: RGB | |
| pclk_frequency: 16MHZ | |
| dimensions: | |
| width: 800 | |
| height: 480 | |
| de_pin: | |
| number: 5 | |
| hsync_pin: | |
| number: 46 | |
| ignore_strapping_warning: true | |
| vsync_pin: | |
| number: 3 | |
| ignore_strapping_warning: true | |
| pclk_pin: 7 | |
| reset_pin: | |
| ch422g: ch422g_hub | |
| number: 3 | |
| enable_pin: | |
| ch422g: ch422g_hub | |
| number: 2 | |
| hsync_back_porch: 16 | |
| hsync_front_porch: 16 | |
| hsync_pulse_width: 8 | |
| vsync_back_porch: 16 | |
| vsync_front_porch: 16 | |
| vsync_pulse_width: 8 | |
| data_pins: | |
| red: | |
| - 1 #r3 | |
| - 2 #r4 | |
| - 42 #r5 | |
| - 41 #r6 | |
| - 40 #r7 | |
| blue: | |
| - 14 #b3 | |
| - 38 #b4 | |
| - 18 #b5 | |
| - 17 #b6 | |
| - 10 #b7 | |
| green: | |
| - 39 #g2 | |
| - 0 #g3 | |
| - 45 #g4 | |
| - 48 #g5 | |
| - 47 #g6 | |
| - 21 #g7 | |
| touchscreen: | |
| platform: gt911 | |
| id: my_touch | |
| # Uncomment below if you got the janky OTHER i2c address this time | |
| #address: 0x14 | |
| # Probably fixed by adding reset_pin via CH422 though | |
| interrupt_pin: GPIO4 | |
| # DEFINE RESET PIN for consistent i2c address selection | |
| # CTP_RST is wired to IO1 of CH422G | |
| reset_pin: | |
| ch422g: ch422g_hub | |
| number: 1 | |
| mode: OUTPUT | |
| on_touch: | |
| - lambda: |- | |
| ESP_LOGI("Touch", "Touch detected at x=%d, y=%d", touch.x, touch.y); | |
| # Define fonts | |
| font: | |
| - file: "gfonts://Roboto" | |
| id: roboto24 | |
| size: 24 | |
| bpp: 4 | |
| - file: "gfonts://Roboto" | |
| id: roboto18 | |
| size: 18 | |
| bpp: 4 | |
| binary_sensor: | |
| - platform: homeassistant | |
| id: demo_light_status | |
| entity_id: light.demo | |
| internal: true | |
| on_state: | |
| then: | |
| - lambda: |- | |
| if (id(demo_light_status).state) { | |
| lv_obj_add_state(id(lv_button_demo_light), LV_STATE_CHECKED); | |
| lv_label_set_text(id(demo_light_status_label), "On"); | |
| } else { | |
| lv_obj_clear_state(id(lv_button_demo_light), LV_STATE_CHECKED); | |
| lv_label_set_text(id(demo_light_status_label), "Off"); | |
| } | |
| lvgl: | |
| displays: | |
| - my_display | |
| touchscreens: | |
| - my_touch | |
| theme: | |
| button: | |
| bg_color: 0x333333 | |
| bg_grad_dir: VER | |
| text_color: 0xFFFFFF | |
| checked: | |
| bg_color: 0xcc9900 | |
| text_color: 0x000000 | |
| bg_grad_color: 0x664d00 | |
| pressed: | |
| border_color: 0xff6600 | |
| pages: | |
| - id: main_page | |
| layout: | |
| type: flex | |
| flex_flow: column_wrap | |
| width: 100% | |
| bg_color: 0x000000 | |
| bg_opa: cover | |
| pad_all: 5 | |
| widgets: | |
| - button: | |
| checkable: true | |
| id: lv_button_demo_light | |
| width: 140 | |
| height: 150 | |
| widgets: | |
| - label: | |
| text_font: roboto24 | |
| text: "Demo\nLamp" | |
| - label: | |
| id: demo_light_status_label | |
| text: "Off" | |
| align: bottom_left | |
| on_click: | |
| then: | |
| - homeassistant.service: | |
| service: light.toggle | |
| data: | |
| entity_id: light.demo | |
| interval: | |
| - interval: 20s | |
| #startup_delay: 15s | |
| then: | |
| - lambda: |- | |
| if (id(demo_light_status).state) { | |
| lv_obj_add_state(id(lv_button_demo_light), LV_STATE_CHECKED); | |
| lv_label_set_text(id(demo_light_status_label), "On"); | |
| } else { | |
| lv_obj_clear_state(id(lv_button_demo_light), LV_STATE_CHECKED); | |
| lv_label_set_text(id(demo_light_status_label), "Off"); | |
| } | |
I get occasional (a minute or two) glitches which look like something to do with screen refreshing. `
I was getting similar glitches upon touch input. I tweaked the setup a bit increasing clock speed to 16mhz and increasing the sync pulse width, and, while not totally eliminating the problem, it seems to have helped. I've updated the code above.
I don't think the glitches explicitly have to do with either Arduino GFX or espressif libraries - I think it's a signal sync issue. The image on the display appears to shift slightly because the signals for the pixels are coming in at slightly the wrong time.
Unfortunately, within ESPhome, we're kind of working with an abstraction of an abstraction, and the low level stuff isn't easy to access if it's accessible at all, so I suspect the root cause of some of these anomalies have to do with the way the low-level communications are set up in the rpi_dpi_rgb display platform in ESPhome, but, troubleshooting and or modifying this is a bit beyond my depth as well.
That said, you're using a slightly different display from me -- let me look at the waveshare example code for that, and see if there's a slightly different configuration suggested.
Interesting. I'm not sure it's helped for me. The shift seems greater and involve more of the screen. It doesn't seem to destroy the picture so much whilst it's happening but it's so quick it's hard to tell. It maybe happening less often too.
hey this is great. thanks. my 2 cents, i see the same glitch when doing OTA or something that spikes esp32 cpu.
EDIT: Experimental Reset Pin definition via CH422 I/O expander added.
I've identified an issue where the touchscreen fails intermittently, and tracked it down to the GT911 controller's i2c address selection behavior. The controller expects specific signals at specific timing on CTP_IRQ and CTP_RST to select between 0x5D and 0x14. Without a defined reset pin, it's unclear if the ESPhome GT911 component would properly instantiate the touchscreen - (actually it's fairly obvious that it would not since on random bootups I had seen 0x14 and no 0x5D and a big red "COMPONENT TOUCHSCREEN MARKED FAILED")
Confounding the situation, CTP_RST is not wired to the ESP32 on this board, and is instead wired to the CH422G's IO0 port.
I've attempted to define the reset pin for the touchscreen with the expander's port here -- from what I can see it is working, the address has been 0x5D, i'm not seeing errors, and the touchscreen works, but testing over some duration is required to ensure this is properly functional. It certainly doesn't seem to impede functionality though.
This is nice, thank you. We can implement even back light control with ch422, but i see the issue remaining. Try to do an ota update and check the display;)
@fdepalo You're right - I duplicated the issue as you suggested by OTA update.
Reviewing the component code again, there was a numbering misalignment. I think ESPhome maps CH422 IO0 to number: 1
Edit: No, I'm just a dingus, the CTP_RST is, was, and has always been IO1.
I changed the pin number and the i2c address. The CH422G has a whole pile of addresses that frankly I don't understand the significance of so I picked the first one, but all the examples I see are using 0x24 so lets just go with the flow, changing that too.
Digging deeper, I find that this has all been a solved issue for the past month or so. See also, this Merge. So, added enable and display reset pins for kicks while I'm in there.
build_flags: "-DBOARD_HAS_PSRAM -DCONFIG_SPIRAM_CACHE_WORKAROUND"
this seems to improve the response, try if you want
regarding the OTA maybe it's not an issue and we just need to disable the display when ota'ing :)
I realize I conflated two issues here
The changes I suggested were for the failed touchscreen issue.
As far as the visual distortion when OTA'ing -- not sure that's fixable -- the display expects signals with precise timing and the esp32 is handling that but also wifi, ota, whatever else. Basically once it gets overhwelmed and tasks start backing up the timing goes out of whack and the display goes haywire. In a perfect world, the display signalling would be handled by one core and everything else by the other but I'm not sure that's easily doable within ESPhome.
I'll try that workaround. I also found some updated display sync timings that I'll try in the commit that added the ch422g support. I wonder how much those will help with the sync glitching, but I will try.
I just updated espHome to 2024.10.0 and got an error with ch422g stating the "address" attribute is non existent. I commented it out and backlight switch seems to work but the touchscreen doesn't anymore; error communicating with gt911. Anybody else seen this? Any inspirational fixes!
@nottledim Looks like there was a breaking change for the ch422g module in espHome 2024.10.0
the address is used in a non-standard way for the ch422 so this is correct. i will look into how to make this work.
if you're getting the touchscreen issue, you might try the touchscreen address 0x14 - but that's a temporary workaround at best.
I'd just like to flag another possible issue. I just updated espHome to 2024.11.2 (ditto 2024.11.1) and recompiled my waveshare app. It refused to start. It connected to wifi but then did nothing (no display). It doesn't talk to HomeAssistant i.e. port 6053 is not responding. OTA updates still work though.
WARNING Can't connect to ESPHome API for gridish @ 192.168.46.226: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='192.168.46.226', port=6053))]: [Errno 111] Connect call failed ('192.168.46.226', 6053) (SocketAPIError)
INFO Trying to connect to gridish @ 192.168.46.226 in the background
When I reverted to 2024.10.3 and recompiled it sprung back to life.
My other espHome devices recompiled OK so I'm suspecting an esp32s3 issue. Any suggestions.
Curious if you folks have figured out the ch422g component yet. I have a use case where I want this display to serve as a wall mounted thermostat. Thusly, I will need to include a temperature sensor and some relays to trigger HVAC actions.
Do you happen to know if this possible using this I/O expander and if so, how do you wire up sensors to the bus?
Thank you so much for this! Do you know if this setup works with https://www.waveshare.com/wiki/ESP32-S3-Touch-LCD-4B ?
Any help would be much appreciated!
That's a useful piece of work. My ESP32-S3-Touch-LCD-7 is suddenly useful! Many thanks.
There's just one thing: I get occasional (a minute or two) glitches which look like something to do with screen refreshing. Others have seen this too. Here's an example with a screenshot showing clearly the effect.
https://forum.lvgl.io/t/screen-glitch-on-refreshing-gui-on-esp32-s3/14235The word seems to be that it's to do with Arduino GFX library but others have suggested it's to do with espressiv libraries.
https://www.esp32.com/viewtopic.php?f=12&t=26793&start=20#p95677. I don't know how espHome works so I'm well out of my depth but if there's anything you could do ....