Installing Tasmota on GeekMagic SmallTV look alike device

[jkwim]

I purchased a GeekMagic SmallTV look alike device from Aliexpress:

https://vi.aliexpress.com/item/1005006895576912.html

It also has ESP8266 like the original SmallTV device but the PCB is different. It has a different PCB.

There is a built in CH340 USB-TTL chip also. So flashing this device is a breeze.

Here is what I have done so far:

1. Flashed Tasmota 14.1.0 display.bin

2. Configured the GPIO's based on following discussion about GeekMagic SmallTV:
   https://community.home-assistant.io/t/installing-esphome-on-geekmagic-smart-weather-clock-smalltv-pro/618029/3?filter=summary

UPDATE 2024/07/23 : There was an issue with Display Initialization during Power Up due to not setting GPIO 2 as Display Rst. See posts below for investigation of the issue

UPDATE 2024/07/25: Controlling brightness was not possible with GPIO Setting Brightness and command DisplayDimmer was not possible. Solution was to set GPIO5 to PWM_i and use Dimmer command

3. Adapted following display descriptor by removing the uTouch specific directives UTx:

https://github.com/arendst/Tasmota/blob/development/tasmota/displaydesc/ST7789_display.ini

4. Converted in to Rule3:

Rule3 :H,ST7789,240,240,16,SPI,1,*,*,*,*,*,*,*,40 :S,2,1,3,0,80,30 :I 01,A0 11,A0 3A,81,55 36,81,00 21,80 13,80 29,A0 :o,28 :O,29 :A,2A,2B,2C :R,36 :0,C0,00,50,00 :1,A0,50,00,01 :2,00,00,00,02 :3,60,00,00,03 :i,20,21 #

5. Configured the buttons for Display ON/OFF and Backlit ON/OFF

UPDATE 2024/07/25: Controlling brightness was not possible with GPIO Setting Brightness and command DisplayDimmer was not possible. Solution was to set GPIO5 to PWM_i and use Dimmer command

00:00:00.001 HDW: ESP8266EX
00:00:00.050 CFG: Loaded from flash at F7, Count 70
00:00:00.055 FRC: Some settings have been reset (2)
00:00:00.059 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
00:00:00.910 DSP: Configured display 'ST7789'
00:00:00.913 Project tasmota - Tasmota Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)

Observation:

Displaymode 1 showed the Time Stamp but whole screen gets utilized upside down, meaning that I have to keep the device upside down for text to appear correctly.

Definitely my Display Descriptor may have a flaw.

Need help to get it corrected.

Here is the device descriptor from the original file.

:H,ST7789,240,240,16,SPI,1,*,*,*,*,*,*,*,40
:S,2,1,3,0,80,30
:I
01,A0
11,A0
3A,81,55
36,81,00
21,80
13,80
29,A0
:o,28
:O,29
:A,2A,2B,2C
:R,36
:0,C0,00,50,00
:1,A0,50,00,01
:2,00,00,00,02
:3,60,00,00,03
:i,20,21
:UTI,FT6236,I2,38,-1,-1
RD A8
CP CD
RTF
RD A3
CP 36
RTF
RT
:UTT
RDM 00 16
MV 2 1
RT
:UTX
MV 3 2
RT
:UTY
MV 5 2
RT
#

[sfromis]

The DisplayRotate command can be used to change orientation, 0-3 in steps of 90°
As the default is 0, the value 2 is likely what you need.

[jkwim]

Thanks for that quick Answer.

20:11:12.483 CMD: displayrotate 2
20:11:12.703 RSL: RESULT = {"DisplayRotate":2}

It worked.

Anyway to make it part of either display initialization or startup of device?

[sfromis]

The setting is persistent, meaning that you do not have to do it again at startup.

[jkwim]

There are few more quirks in the device.

When you unplug and plug the device, it does not seem to complete the boot the first time. Second unplug/plug action boots the device but the display does not get turned on. When you execute a restart from GUI or command line then the display gets initialized and turns on.

I wonder what is going on. I cannot see any serial port output either.

[barbudor]

I wonder why the box is so empty
Thanks for sharing

[s-hadinger]

It's also a pitty they put an esp8266. At least an esp32c3 would have opened many possibilities

[sfromis]

The "pro" version does have ESP32, and a higher price.

I think that the reason for the relative emptiness of the box is that they wanted it to be a box as a visual "console" design choice, standing on a desk. When a base surface is needed, only a little bit more plastic by having the full cube-like shape.

[jkwim]

There is an issue with heating. Since all the elements are on the outside I can feel the temperature on the bottom surface. Probably needs to drill some holes on the sides at the very bottom.

[sfromis]

Still, I'd not consider an inside temperature/humidity sensor as a usable thing to have, unless carefully managing airflow and heat conduction. That's not done by drilling a few holes.

[jkwim]

Well for a start I managed to come up with this to be able to monitor my off grid solar system and EV charging status.

Next I will try to add a Buzzer for alarms and possibly a proximity sensor so that display gets turned on only when somebody is near.

Probably the ESP32 based device will be useful as the next device to make the PV generation graphs etc on this small screen.

Still need to figure out the weird initialization issue of the display.

ie. When powered up display does not get initialized. Once wifi is connected and restart command is given GUI/console the display gets initialized.

[Kaytec]

Hi,

Thank you for the progress made on this Geekmagic clone. However, I noticed the colors are reversed. Referring to the ST7789V documentation (page 190), it might be related to the INVON (21h): Display Inversion setting. Could you clarify where to place this in the descriptor?

It’s not a major issue as I can reinterpret the table, but I’d like to configure it correctly.

Thanks!

[sfromis]

Did you try the display.ini modification "trick" mentioned here? #21791 (reply in thread)

changing :i,20,21 into :i,21,20 did the trick

Another way could be to configure Tasmota with the command DisplayInvert 1

[Kaytec]

I actually missed that. DisplayInvert 1 works perfectly. I was looking for this command in the documentation under /docs/Displays/ instead of /docs/Commands/#displays. Thanks.

[jkwim]

I need a solution for the boot/initialization issue.

Here are the symptoms:

1. When the device is powered on it boots completely, WiFi gets connected, MQTT gets connected and the RULES start to work but display remains black (If the display gets initialized it should get drawn white as per my observation with this display).

00:00:00.001 HDW: ESP8266EX
00:00:00.050 CFG: Loaded from flash at F7, Count 370
00:00:00.054 FRC: Some settings have been reset (2)
00:00:00.058 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
00:00:00.909 DSP: Configured display 'ST7789'
00:00:00.982 Project tasmota - Tasmota Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)
00:00:02.001 WIF: Connecting to AP1 xxxxxx Channel 1 BSSId xxxxxx in mode 11n as tasmota-5681...
00:00:04.516 WIF: Connected
00:00:04.768 HTP: Web server active on tasmota-5681 with IP address 192.168.1.110
16:51:15.586 MQT: Attempting connection...
16:51:15.600 MQT: Connected
16:51:15.603 MQT: tele/tasmota/LWT = Online (retained)
16:51:15.605 MQT: cmnd/tasmota/POWER = 
16:51:15.612 MQT: tele/tasmota/INFO1 = {"Info1":{"Module":"Generic","Version":"14.1.0(release-display)","FallbackTopic":"cmnd/Tasmota_fb/","GroupTopic":"cmnd/tasmotas/"}}
16:51:15.653 MQT: tele/tasmota/INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-5681","IPAddress":"192.168.1.110"}}
16:51:15.695 MQT: tele/tasmota/INFO3 = {"Info3":{"RestartReason":"External System","BootCount":120}}
16:51:15.734 MQT: stat/tasmota/RESULT = {"POWER1":"ON"}
16:51:15.737 MQT: stat/tasmota/POWER1 = ON
16:51:15.739 MQT: stat/tasmota/RESULT = {"POWER2":"ON"}
16:51:15.740 MQT: stat/tasmota/POWER2 = ON
16:51:15.756 RUL: SYSTEM#BOOT performs 'Backlog Ruletimer1 1; Ruletimer2 10; DisplayText [izBi1Ci15]; DisplayText [z]'

2. If I issue a Restart 1 or use GUI button to restart then during the restart the screen becomes white and afterwards changes to black because of my instructions to change the background to black and everything works fine.

The log looks like this:

00:00:00.002 HDW: ESP8266EX
00:00:00.050 CFG: Loaded from flash at F6, Count 371
00:00:00.058 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
00:00:00.910 DSP: Configured display 'ST7789'
00:00:00.983 Project tasmota - Tasmota Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)

The log messages are same except for the following message which does not appear after doing Restart 1.

00:00:00.054 FRC: Some settings have been reset (2)

Also the CFG log entries are different F7 vs F6. I do not know what it means.

00:00:00.050 CFG: Loaded from flash at F7, Count 370
00:00:00.050 CFG: Loaded from flash at F6, Count 371

What could be getting wrong here?

I am not sure whether Display Descriptor has anything to do with it but then it works on the reboot.

[jkwim]

A typical issue when crash-restarting at that point is that the power needs of Wifi pushes it over the edge, which is not something the ESP8266 handles gracefully. Your image looks like there is a decent voltage regulator (unless "surprisingly crappy"), but one factor could be if there is sufficient decoupling capacitance to handle the peaks with Wifi activity.

Yes the board has the common AMS1777 LDO Regulator used in most ESP boards.
Just to be sure I changed the power source also tried but same outcome: power up doesn't initialize the display but a restart command will .
There could not be WiFi signal issue as the WiFi router is only 2-3m away from the device.

I will try the capacitor trick and see. That makes sense to handle a small peak. Have seen that suggestion for WiFi issues but I have never had an issue.

[sfromis]

With short distance, it makes sense to try if lowering WifiPower would make a difference. And since restarting makes a difference, that was why I also mentioned SetOption46.

[jkwim]

I soldered a 10uf capacitor to the pins of the AMS1117 regulator output as a quick test but there was no progress. Soldering to ESP pins need some precision so I will attempt later.

[jkwim]

Then I tried setting Setoption46 to 255 (max value).

Here is the old log during power on:

;d[00]dœŸ|[00]Œlà|[03][0C][04][04]Œ[0C]$ä[0C]b|�ƒ[03]ä[13]’;›cÄ[04]cÄûgoŸdgoÜãä[0C]#[1C]pŒ�ls${lxû'à[18][03][04][0C]Ã[04]l[0C]ÄÜ[0C][04][04]c[0C]'â|[02]äd‡[04]Ž#Œû'gç[00]$Œ‡$ [03]Ø[1B][1B]go[04]d`[03][07][03]g{‡›“o[04][04]c[03]$ [03][07];›“o[04][04]b[03]$`[03]Ü;dŒ�|à[0C]l$Ü[07]$üÃ'Ü[03]
00:00:00.001 HDW: ESP8266EX
00:00:00.050 CFG: Loaded from flash at F8, Count 385
00:00:00.054 FRC: Some settings have been reset (2)
00:00:00.055 CFG: CR 400/699, Busy 0
00:00:00.058 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
00:00:00.060 TYA: Active=0
00:00:00.062 DSP: Rule 3 descriptor used
>>>>> 00:00:00.910 DSP: Configured display 'ST7789'
00:00:00.911 SRC: Restart
00:00:00.992 Project tasmota - TasmotaNW22 Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)
00:00:01.215 WIF: Checking connection...
00:00:01.216 WIF: Attempting connection...

Driver config message is at 910 miliseconds

After changing the Setoption46 to 255

00:00:00.001 HDW: ESP8266EX
00:00:00.050 CFG: Loaded from flash at F4, Count 453
00:00:00.055 FRC: Some settings have been reset (2)
00:00:00.059 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
>>>>>>> 00:00:03.405 DSP: Configured display 'ST7789'
00:00:03.488 Project tasmota - Tasmota Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)
00:00:05.001 WIF: Connecting to AP1 xxxxxxxxxxxxxx Channel 1 BSSId xxxxxxxxx in mode 11n as tasmota-5681...
00:00:07.514 WIF: Connected
00:00:07.766 HTP: Web server active on tasmota-5681 with IP address 192.168.1.110
20:23:25.041 MQT: Attempting connection...
20:23:25.054 MQT: Connected

Driver config message is at 3.405 seconds.

So the effect of boot delay does not solve the problem.

Could it be that the SPI detection has a delay. In both above cases the SPI message comes around the same timestamp value.

[sfromis]

Soldering the capacitor on the voltage regulator defeats the purpose of having it at all, as a short distance is important for decoupling of spikes. To be clear, I'm not saying "weak decoupling is the reason", but if it is, fixing a bad board design can indeed get tricky.

Did you try lowering WifiPower ?

[jkwim]

Weblog 4 shows that SPI message comes before the delay starts

00:00:00.001 HDW: ESP8266EX
00:00:00.050 CFG: Loaded from flash at F7, Count 458
00:00:00.054 FRC: Some settings have been reset (2)
00:00:00.055 CFG: CR 400/699, Busy 0
00:00:00.058 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
00:00:00.059 INI: SO46 Wait 2550 msec
00:00:02.555 TYA: Active=0
00:00:02.558 DSP: Rule 3 descriptor used
00:00:03.405 DSP: Configured display 'ST7789'
00:00:03.406 SRC: Restart

[jkwim]

I observed the timing of the screen initialization on serial port to get an idea.
When the restart happens the white screen gets drawn and then immediately afterwards the wifi is attempted.

WiFi power was lowered to value 13 from 17.

PXL_20240721_190526635.2.mp4

During power up the screen backlit comes up but the white screen does not get drawn.

So issue seems to be hitting closer to WiFi activation indeed but it appears WiFi is attempted only after the screen is initialized.

Does the code behave differently when powered up and when restarted?

[sfromis]

I meant WifiPower significantly lower, not merely a small step down. On an ESP8266 relatively close to the nearest AP, the minimum of 2 still worked for me.

Of course, the screen going white is also going to draw some power, and when Wifi needs then come on top of that.... Using DisplayDimmer, you could try reducing brightness, hence power needs.

[jkwim]

Tried WifiPower 3. That was the lowest that worked. No Progress.

DisplayDimmer only works with 0 & 1 for this display. Just on and off. So I tried Power up while DisplayDimmer 0 and then manually issuing the command DisplayDimmer 1 once the WiFi is up. No luck.

If I do a restart with DisplayDimmer 0 and then later do DisplayDimmer 1 then it works.

[sfromis]

As DisplayDimmer works for me on a board with ST7789, I was expecting this to work for you too. However, my setup is ESP32 and I2C connection. On a device with a different SPI based display, I'm having a Backlight pin configured to manage brightness. The thread you linked seems to suggest that gpio 5 (which you have configured as a Relay) is backlight. You might get the brightness feature available if you config it as Backlight instead. The docs also suggests configuring Backlight for a SPI based ST7789.

But if it still fails when booting with 0 (I'm assuming that you mean having black screen), that does not seem to be it.

[jkwim]

As DisplayDimmer works for me on a board with ST7789, I was expecting this to work for you too. However, my setup is ESP32 and I2C connection. On a device with a different SPI based display, I'm having a Backlight pin configured to manage brightness. The thread you linked seems to suggest that gpio 5 (which you have configured as a Relay) is backlight. You might get the brightness feature available if you config it as Backlight instead. The docs also suggests configuring Backlight for a SPI based ST7789.

Tried changing GPIO5 as Backlit. Then screen does not work at all even after a Restart 1. Played with DisplayDimmer also.

[jkwim]

In the original firmware, the screen comes up immediately when power is connected. Then it shows a progress bar for few seconds and comes to the weather display. I guess there must be a significant delay between screen initialization and WiFi attempt.

I had a second identical device and decided to flash that unit also and check.

The results were identical.

Since I have minimal config on the second unit, I can clearly see timing wise that during Restart 1 the display comes up first and then WiFi is attempted. During initial power up the display does not come up.

00:00:00.001 HDW: ESP8266EX
00:00:00.050 CFG: Loaded from flash at FA, Count 26
00:00:00.056 QPC: Count 1
00:00:00.061 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
08:16:19: 00:00:00.912 DSP: Configured display 'ST7789'
00:00:00.915 Project tasmota - Tasmota Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)
<<<<<<<< THERE IS A PAUSE AFTER SCREEN BECOMES ACTIVE >>>>>>
08:16:21: 00:00:02.001 WIF: Connecting to AP1 xxxxxx Channel 1 BSSId xxxxxx in mode 11n as tasmota-A8E55C-1372...
08:16:24: 00:00:04.879 WIF: Connected

During power up also I can feel that there is a pause at the same message but hard to compare the timings except from the local time stamps from the terminal program that I use (Termite).

You can about two seconds between the DSP: .... message and WIF:... message.

08:16:19:                  >>00:00:00.912 DSP: Configured display 'ST7789'
                                00:00:00.915 Project tasmota - Tasmota Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)
<<<<<<<< THERE IS A PAUSE AFTER SCREEN BECOMES ACTIVE >>>>>>
08:16:21:                 >>00:00:02.001 WIF: Connecting to AP1 xxxxxx Channel 1 BSSId xxxxxx in mode 11n as tasmota-A8E55C-1372...

During power up also there is a pause visibly but the timestamp does not get printed by the terminal program. However if you go by the timestamp printed by Tasmota the delay seems to be comparable:

42:            ;l[00]$ÜŸ|[00]Ä$à|[03][0C][04][0C]„[0C]dì[04]c|�‚[03]ì[1B]“;“#Œ[04]#Œóo'Ÿdo'œãì[0C]#[1C]xä‡lsds$pònà[18][03][0C][04]ƒ[04]l[04]Œœ[0C][04][0C]c[04]oã|[03]älŽ[0C]Žc„û'oï[00]l„‡d`[03]˜[13][1B]'o[04]l [03][07][03]os�Û›g[04][0C]c[02]d`[03][0F]r›“n[0C][04]c[03]l`[02]Ü;dÄÇ<à[04]ldœ[0F]lüÃ'œ[03]
                00:00:00.001 HDW: ESP8266EX
                00:00:00.050 CFG: Loaded from flash at F7, Count 29
                00:00:00.055 FRC: Some settings have been reset (3)
                00:00:00.059 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
               >>00:00:00.910 DSP: Configured display 'ST7789'
                00:00:00.914 Project tasmota - Tasmota Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)
                <<<<<<<< THERE IS A PAUSE >>>>>>
45:           >>00:00:02.001 WIF: Connecting to AP1 xxxxxxxxxxx 1 BSSId xxxxxxxxxxxx in mode 11n as tasmota-A8E55C-1372...
46:           00:00:03.910 WIF: Connected

Is there a way to power up without WiFi?

[jkwim]

SUCCESS FINALLY!

I have made a petty mistake of ignoring the RST pin configuration from the snippet from the developer's comment

GeekMagicClock commented Sep 29, 2023

Hi, here for your reference.
#define TFT_BL 5 // LED back-light control pin
#define TFT_BACKLIGHT_ON LOW // Level to turn ON back-light (HIGH or LOW)
#define TFT_CS -1 // Chip select control pin D8
#define TFT_DC 0 // Data Command control pin
#define TFT_RST 2 // Reset pin (could connect to NodeMCU RST, see next line)
SCK 14
MOSI 13

I was trying to figure out where to connect the RES pin while trying to configure my standalone Display module with another ESP8266 as discussed below. Then I went back to my notes and noticed the #define TFT_RST 2 // Reset pin (could connect to NodeMCU RST, see next line) line above. It was a little cryptic comment to say NodeMCU RST.

So the following configuration worked.

{"NAME":"GeekMagicClone","GPIO":[800,1,1024,1,1,256,1,1,5730,704,736,768,1,0],"FLAG":0,"BASE":18}

Thanks a lot for your continuous engagement to solve my issue!

[jkwim]

One remaining issue that needed to be fixed was the Display Brightness Control.

Setting GPIO5 to Brightness and using DisplayDimmer command had no effect.

I had to set GPIO5 to PWM_i and then Dimmer command can be used for controlling brightness.

[sfromis]

I suppose that you mean "Backlight" config instead of "Brightness"....

When you have it working, you could then submit a template to https://templates.blakadder.com/ for the benefit of other users.

[jkwim]

I have this Display module from Aliexpress.
PCB says SPI but pin labels look like I2C.
Also this one has 12pin connector to the actual display (the display in above unit is 10pins)

Is this the same kind that you have?

I was thinking about connecting this to a Wemos D1 Mini to see whether same error occurs.

[sfromis]

Labeling of pins for SPI devices is often a mess, not indicating what type of interfacing is in use. I suppose that part of the reason for this is devices able to interface via both I2C and SPI, with same pins after selecting mode via another pin, jumper, or similar. When the PCB says SPI, you should look up data on your board to see where the SPI pins are.

https://www.reddit.com/r/AskElectronics/comments/d4fjjr/is_it_normal_for_some_spi_pins_to_be_named_sdasck/

... has often misused SDA for MOSI and SCK for CLK.

If "you" is referring to me, my device with ST7789 is very different, and was actually a PAR interface instead of I2C or SPI, and a much wider unlabeled connector to the display.

[jkwim]

You are correct!

I found the following also from Aliexpress product listing:

So will try the following mapping:

GND
VCC
SCK	SCLK	GPIO 14
SDA	MOSI	GPIO 13
RES		GPIO 4 (Display Rst)
DC		GPIO 0
CS	Not used
BLK		GPIO 5

[jkwim]

The above IO config and the Display Descriptor from previous posts worked fine with this display module.

01:44:37: s$[00]dÜŸ|[00]Œlà|[03][0C][04][04]Œ[04]dì[0C]#<Ž‚[03]ä[13]Û{“bÄ[04]cÄû'oŸdgoœãä[0C]#[1C]pŒ�ls$;lpòoà[10][03][0C][04]ƒ[0C]$[04]„œ[04][04][0C]c[04]'ã<[03]äl‡[04]ÇcÄûgoç[00]dŒ�d`[03]Ø[1B][1B]go[04]d`[03][07][03]g{‡›“o[04][04]#[03]d`[03][07]{“Ûn[04][0C]#[03]d`[03]œ{lÄŽ|à[0C]$dœ[07]düƒ'œ[03]
00:00:00.001 HDW: ESP8266EX
00:00:00.050 CFG: Loaded from flash at F7, Count 87
00:00:00.056 CFG: CR 400/699, Busy 0
00:00:00.058 SPI: Hard using GPIO14(CLK) and GPIO13(MOSI)
00:00:00.060 TYA: Active=0
00:00:00.062 DSP: Rule 3 descriptor used
01:44:38: 00:00:00.209 DSP: Configured display 'ST7789'
00:00:00.212 SRC: Restart
00:00:01.003 Project tasmota - Tasmota Version 14.1.0(release-display)-2_7_6(2024-06-03T11:53:04)
00:00:01.381 WIF: Checking connection...
00:00:01.382 WIF: Attempting connection...

[sfromis]

I got the "pro" ESP32 version of the device working, based on the info in this thread, and also
https://community.home-assistant.io/t/installing-esphome-on-geekmagic-smart-weather-clock-smalltv-pro/618029

Spotted 3 Github projects about the device, including from the original creator:
https://github.com/GeekMagicClock/smalltv-pro
https://github.com/clowrey/esphome-geekmagic-small-TV-pro
https://github.com/jo-m/smalltv-pro-esp-idf

Like posted earlier here, I used the ST7789 display descriptor sans the touch part, and this template:

{"NAME":"GeekMagic Smalltv Pro","GPIO":[1,1,800,768,1024,1,1,1,1,1,1,1,1,6210,736,1,0,1,1,704,0,448,1,1,0,0,0,0,5408,1,1,1,1,0,0,1],"FLAG":0,"BASE":1}

Gpio.02	IO  800 SPI DC1
Gpio.03	RX  768 SPI CS1
Gpio.04	IO 1024 Display Rst
Gpio.17	IO 6210 Option A3
Gpio.18	IO  736 SPI CLK1
Gpio.23	IO  704 SPI MOSI1
Gpio.25	IO  448 PWM_i1
Gpio.32	AO 5408 Button_tc1

The ESP32 version is sensitive to touching the top of the box, and TouchThres 100 worked fine for me with the Button_tc config. Setup for display:
Backlog DisplayRotate 2;DisplayInvert 1;TouchThres 100

Doing a rudimentary RGB color test worked, after the invert:
DisplayText [zf1s2x80y80Ci2]Red[x80y112Ci3]Green[x80y144Ci4]Blue

With the OG variant of the ESP32 and no PSRAM, there are strict limitations to how much headroom for fun, but a lot more than the ESP8266 version. I had no trouble running HASPmota with a small Berry program to plot the touch input levels on screen, without the heap shrinking to a catastrophic level.

Arguably, the price is a lot higher than the hardware cost, as the device is pretty simple. It makes very much sense to not have a temperature sensor inside the box, which gets noticeably warmer in use. As the version I got also has the RTC chip position unpopulated, it does not make much sense with words like "weather clock" in the name, but who cares....

The creator was agreeable about making a version with ESP32-S3 and PSRAM, but you could also replace the ESP32-WROOM-32E module with a similar ESP32-S3 based one, meaning that the product price would then be for the plastic box, a small display and yet another USB-C cable. Of course, you could also stick with the standard firmware, if you like that solution where the features are not "too bad".

[jkwim]

This is great info.

As you said the price for HW is steep but once you have it going the possibilities are endless.

BTW, I learned from @gemu2015 yesterday that Display Inversion can be included in the display descriptor:

changing :i,20,21 into :i,21,20 did the trick

[jkwim]

Could you add some pictures of the PCB please

[s-hadinger]

I'm interested in a PSRAM version, otherwise LVGL/HASPmota is too limited

[sfromis]

They're somewhat boring, but here. Oversharpened for better contrast.