Installing ESPhome on GEEKMAGIC Smart Weather Clock (smalltv/pro)

[nickrout]

@breti

display:
  - platform: st7789v
    model: Custom
    height: 120 # 240
    width: 120 # 240

The pro version states it is 240x240, so not sure that 120x120 will work. I cannot see the resolution mentioned in the non pro advertising. I assume that the pro and non pro hardware use the same screen (noting meantime that assumption is the mother of screwups)

And then we come to this, from the esphome docs.

Note
Displays larger than the 135x240 pixel display on the TTGO T-Display shown require a significant amount of RAM to operate correctly. Some ESP devices, such as the ESP8266, do not have sufficient memory to support this display. If you attempt to use this component and experience repeated crashes, this is likely the cause of the issue.

I know the screen works with esp8266 in the author’s native c++ code, but maybe esphome is not memory efficient enough?

Has anyone got a pro to play with? (just ordered one, but ali being ali, it won’t be here for a while)

[breti (Jens Bretschneider)]

@nickrout

The pro version states it is 240x240, so not sure that 120x120 will work.

See this note in the ESPhome st7789v docs:

Note

On memory-constrained devices, it may be possible to use part of the display area by specifying a smaller height and/or width than that of the actual display.

[nickrout]

missed that bit.

Without a device I can’t play, but keep trying

[rletendu]

Finally got some progress today.
Comparing the SPI waveforms between the functional native firmware versus the EspHome generated, figured out the SCL line idle state was different…
Somehow CPOL:1 and CPHA:1 on the functional firmware (suspecting it could be related to the none usage of the CS pin).

Implementing a custom SPI setting in a custom st7789v component got the display behaving properly but still facing display size limitation probably due to not enough RAM in the ESP8266 and its implementation in ESPHome

Using 120x120 display is fine, but when trying with higher resolutions device has some spurious reboot suspecting memory leak or watchdog reset due to too long time spent in display update.
Still need to wok on it…

sharing my esphome fork with fixed st7789 component (st7789v_noCS branch) in case someone would like to investigate this also…

external_components:
  - source:
      type: git
      url: https://github.com/rletendu/esphome.git
      ref: st7789v_noCS
    components: [st7789v]

[breti (Jens Bretschneider)]

Wow, that’s great! Did you try the eightbitcolor option?

[rletendu]

Yes and unfortunately the eightbitcolor option does not help…

Googling about this specific ST7789 with no CS and ESPhome looks like this a known issue:

Standalone ST7789 TFT not working with ESPHome

I bought an 1.3" ST7789 TFT display from AliExpress (like this one) and I’m trying to get it to work with ESPHome but running into boot loop issues. I cut the config file way back with this SUPER simple yaml: esphome: name: attictemp1 platform: ESP8266 board: d1_mini logger: level: DEBUG spi: clk_pin: D5 mosi_pin: D7 font: - file: "comic.ttf" id: my_font size: 22 display: - platform: st7789v backlight_pin: D0 cs_pin: D3 dc_pin: D1 reset_pin: D2 la…

Somehow other members end up with same fix changing the SPI mode as I did., they came up with same screen size limitation.

[breti (Jens Bretschneider)]

So the “smalltv pro” with ESP32 is the better choice…

[nickrout]

Well clearly…

Esp32 can be used for other things like bluetooth proxy.

[rletendu]

Yes the pro version and its ESP32 is easier and offers some extra features.
Though since I have a couple of those cheaper versions I am trying to get a software fix.

Definitely the ESPHome display component implementation is not suitable for ESP8266 with 240x240 screens since this display requires ~50kB of RAM usage for buffer that we cannot afford on this SOC.
So I have been starting to implement a version without frame buffer that makes the display refresh significantly slower but usable.

I am still working on it and I’ll share my branch later on, but I am now able to get the 240x240 display being functional with so far the limitation of getting the refresh rate being very slow (about 2.5s).
But I think that I can accommodate this for my usage and I am also expecting to improve this to be in the range of <1s.

[rletendu]

For the ones still interested in using the st7789 with 240x240 display and ESPHome here’s my updated version that will make it compatible with :

• Hardware not using CS pin (like the GEEKMAGIC Smart Weather Clock)
  – If no cs_pin is declared the drivers will switch SPI to mode 3

• ESP8266 and screen larger than 120x120
  – The ESP8266 does not have enough RAM to implement frame buffer
  – The implementation detects automatically if buffer ca be allocate (max 80% of heap) and deals with direct screen memory access instead without frame buffer allocation.

This implementation obviously adds some latency and the screen refresh being visible but still usable for most of my usage of this little unexpensive gadget with ESP home…

You’ll have to declare this external component version from my github fork

external_components:
  - source:
      type: git
      url: https://github.com/rletendu/esphome.git
      ref: st7789_no_frame_buffer
    refresh: 0s
    components: [st7789v]

And use it for example

font:
  - file: 'OpenSans-Regular.ttf'
    id: font1
    size: 30

color:
    - id: color_green
      red: 0%
      green: 100%
      blue: 0%

spi:
  clk_pin: GPIO14
  mosi_pin: GPIO13
  interface: hardware
  id: spihwd


output:
  - platform: esp8266_pwm
    pin: GPIO05
    frequency: 1000 Hz
    id: pwm_output

light:
  - platform: monochromatic
    output: pwm_output
    name: "Backlight"

display:
  - platform: st7789v
    model: "Custom"
    spi_id: spihwd
    height: 240
    width: 240
    offset_height: 0
    offset_width: 0
    dc_pin: GPIO00
    reset_pin: GPIO02
    backlight_pin: GPIO05
    id: disp

        
    lambda: |-
      static int num_executions;
      it.rectangle(0,  0, it.get_width()-1, it.get_height()-1, id(color_green));
      it.printf(0, 0, id(font1), id(color_green),"Uptime %f",id(my_uptime).state);
      it.printf(0, 40, id(font1), id(color_green),"Refresh count %i",num_executions);
      num_executions++;

Just in case it could help some of you landing on this page…

[edit] : The commit with modifications : Comparing esphome:dev...rletendu:st7789_no_frame_buffer · esphome/esphome · GitHub

[breti (Jens Bretschneider)]

Wow, that’s great!

I tried this code and it works, but the display flickers every 5s. Is this because of the missing frame buffer?

# GEEKMAGIC SmallTV
# https://community.home-assistant.io/t/installing-esphome-on-geekmagic-smart-weather-clock-smalltv-pro/
# https://www.youtube.com/watch?v=CEeD7_jAdUc

substitutions:
  devicename: az-smalltv
  friendly_devicename: "Az SmallTV"

esphome:
  name: ${devicename}
  friendly_name: "${friendly_devicename}"

esp8266:
  board: esp12e

# https://community.home-assistant.io/t/installing-esphome-on-geekmagic-smart-weather-clock-smalltv-pro/618029/19
external_components:
  - source:
      type: git
      url: https://github.com/rletendu/esphome.git
      ref: st7789_no_frame_buffer
    refresh: 0s
    components: [st7789v]

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: !secret api_enc_key 

ota:
  password: !secret api_ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${friendly_devicename} AP"
    password: !secret ap_wifi_password

#web_server:
#  port: 80

captive_portal:

time:
  - platform: homeassistant
    id: homeassistant_time

# Button entities
button:

  # Restart button
  - platform: restart
    name: "Neustart"

  # Restart button (safe mode)  
  - platform: safe_mode
    name: "Neustart (abgesicherter Modus)"

# Sensors with general information
sensor:

  # Uptime sensor
  - platform: uptime
    name: "Uptime"

  # WiFi Signal sensor
  - platform: wifi_signal
    name: "WiFi Signalstärke"
    update_interval: 60s

spi:
  clk_pin: GPIO14
  mosi_pin: GPIO13

display:
  - platform: st7789v
    model: Custom
    height: 240
    width: 240
    offset_height: 0
    offset_width: 0
    dc_pin: GPIO0
    reset_pin: GPIO2
    backlight_pin: 
      number: GPIO5
      inverted: True
    lambda: |-
      auto red = Color(255, 0, 0);
      auto green = Color(0, 255, 0);
      auto blue = Color(0, 0, 255);
      auto white = Color(255, 255, 255);
      it.rectangle(20, 50, 30, 30, white);
      it.rectangle(25, 55, 30, 30, red);
      it.rectangle(30, 60, 30, 30, green);
      it.rectangle(35, 65, 30, 30, blue);
      it.rectangle(0,  0, it.get_width()-1, it.get_height()-1, green);

[rletendu]

Yes the flickering is coming from the missing frame buffer…

Without frame buffer each time the display needs to be updated we have to load the entire screen memory with blank, then let the lambda update the screen memory with the content we want to display and write this content for each and every pixel in the memory screen.
The flickering is coming from the those 2 sequential write screen operations and the delay in between …
With frame buffer there is one single write operation to the screen…

To reduce flickering you can specify different ‘update_interval’ value (default is 5s) in the display configuration and/or request the update only on demand from another component with component.update: my_display or lambda 'lambda: ‘id(disp).update();’

[breti (Jens Bretschneider)]

Ah, i see. Thanks for the explanation.

@rletendu

To reduce flickering you can specify different ‘update_interval’ value (default is 5s) in the display configuration and/or request the update only on demand from another component with component.update: my_display or lambda 'lambda: ‘id(disp).update();’

There seems to be no option to disable the update_interval. So setting a very high amount of seconds does the trick.

[rletendu]

Refresh can be disabled using

update_interval: never

[breti (Jens Bretschneider)]

Oooops, you’re right. Thanks again!

Do you want to send a pull request to the ESPhome project?

[rletendu]

Yes I’ll share this, but in two different proposals.

The no CS pin with spi mode change will be useful for other hwd implementations and no compatibility or performance concerns .

But the no frame buffer implementation a bit more questionable since its performance is not optimal…

[rletendu]

Hello everyone,

Just received today a pro version. In case it could be useful, I performed some probing to identify the signals.

The programming connector has same assignment.

For tbe screen the signals are:
DC: gpio02
Sck: gpio18
Mosi: gpio23
Rst: gpio14
Backlight: gpio25

Cs is tight to gnd meaning we’ll have to SPI mode 3 as well to get it working.
Think the previously shared fork of the driver should work. I’ll give a trial tomorrow now…

The touch button is mapped on gpio32

[edit] Pins assignment confirmed as well as functionality with forked drivers. Since heap since is huge on ESP32, frame buffer is kept activated by default and no flickering effect…

[rletendu]

FYI, PR raised here for SPI mode fix st7789 using mode3 when no cs pin by rletendu · Pull Request #5541 · esphome/esphome · GitHub

[breti (Jens Bretschneider)]

Great, thanks!

[nickrout]

My plus arrived today. Will update any progress.