Remote WebView shows HA web dashboard on ESP32-S3-based screen

Hi, this looks very promising, thank you very much, the solution works, but I cannot move from the HA login screen, no on-screen keyboard displayed when clicking on username/password fields.

What am I doing wrong?

Use Chrome DevTools.

Hi Julio,
I bought a similar screen and I have the same issue. Have you solved it? Can you pls share the config?

Thank you!

By the way, I’m waiting for the MaTouch ESP32-P4 TFT with Touch 7″ MIPI. If I can get ESPHome running on it, I’ll definitely try implementing hardware decoding.

1 Like

I got the GUITION JC1060P470C. There is LVGL support for ESPHome.

The colors look weird. Like a 16 colors pc from the 90ies. Elements are visible, but diffuse. Touch works fine.

Do you think missing hardware decoding is the issue?

Does LVGL work correctly on this display, and only RWV displays wrong colors? Hardware decoding is primarily about speeding up processing.

lvgl:
  color_depth: 16
  update_interval: 100ms
  buffer_size: 100%
  displays: my_display
  touchscreens: touchscreen_
  byte_order: little_endian

LVGL works. byte_order: little_endian was critical for correct colors.

Add the parameter big_endian: false to the remote_webview section.

This option was added recently as part of the fix for Add support for little_endian. It’s also listed in the Supported parameters table.

1 Like

Thank you! The colors look better, but still yellow and blue are exchanged.

Update: solved it. the display config was wrong. :see_no_evil:

@strange_v What is the best way to run several displays? Do I need several docker containers? Thank you!

Nothing special is needed. Just flash a few devices and use them :slight_smile:
The server already supports multiple devices, even with different screen resolutions and parameters.

1 Like

I should be working on other projects already, but how can I, if there’s an ESP32-P4 display waiting for me to test the hardware JPEG decoding…

1 Like

The hardware decoder speeds things up significantly (full-screen updates are about 3 times faster), but it produces weird artifacts: 1x32px black lines. Here’s the video: https://youtu.be/WUPgWaLaLvQ

I’m not sure about the root cause. I’ll need to test the hardware decoder in isolation, outside RWV.

If someone wants to try (only for ESP32-P4):

external_components:
  - source: github://strange-v/RemoteWebViewClient@hardware_jpeg
    refresh: 0s
    components: [ remote_webview ]

remote_webview:
  id: rwv
  device_id: matouch-e32p4mi71
  server: 172.16.0.252:8081
  url: http://172.16.0.252:8123/dashboard-mobile/0
  full_frame_tile_count: 1
  max_bytes_per_msg: 61440
  jpeg_quality: 85
  min_frame_interval: 50
  tile_size: 64 # not less

First things first. :laughing:

I got the same artifacts. It’s not related to your display only.

1 Like

@brix29 try again, please :slight_smile:

1 Like

Stripes are gone. Nice. :sunglasses:

Have you been successful in rotating the display to vertical mode?
Rotation seems to be ignored in my config.

remote_webview:
  id: rwv
  display_id: my_display
  touchscreen_id: my_touchscreen
  device_id: esp32-display-10inch
  server: 192.168.178.179:8081  
  url: http://192.168.178.75:8123/dashboard-10inch/home?hide_sidebar
  full_frame_tile_count: 1
  max_bytes_per_msg: 61440
  jpeg_quality: 70
  min_frame_interval: 150
  tile_size: 64
  big_endian: false
  rotation: 90

Yes. Have you updated the server? It is a software, server-side rotation.

By the way, your config is quite conservative. If the connection to the server is stable, you can lower min_frame_interval to 25 with HW decoding.

Also, the next release will include the max_bytes_per_msg fix; currently, it can’t be larger than 61440, which isn’t okay for boards with plenty of PSRAM.

I reduced the jpeg_quality and the min_frame_interval, because i have some screens with pictures. Scrolling them seems to be issue.
I will go back to min_frame_interval: 50

Unfortunately, restarting the docker didn’t help. Does rotation work on your new screen?
At which steps of the config do you add the rotation: 90? remote_webview:" should be sufficient, correct?

You should update the Docker image, not just restart the server. I’m not sure what your container update routine is, but I use a dedicated script for it

#!/bin/bash

docker compose pull --ignore-pull-failures
docker compose up --remove-orphans --force-recreate --build -d
docker image prune -af

UPD: You should use Remote WebView Server v1.1.1

1 Like